Skip to Content

Considerations for network security

To decrease the risk of internal network-based attacks on BMC Server Automation and the servers that it manages, BMC recommends the following practices:

Signing the Application Server certificate with a trusted certificate authority

By default, a BMC Server Automation Application Server creates a self-signed certificate during installation and offers that certificate for authenticating itself to all clients. When connecting to an Application Server for the first time, users must accept this certificate.

It is recommended to use an internal or external certificate authority (CA) to sign the certificates for each BMC Server Automation Application Server. In this way, you can use a certificate that is signed by a trusted CA instead of the self-signed certificate. To set up a CA-signed certificate, perform the following tasks:

  • Sign the Application Server's certificate with a trusted CA and add this certificate to the Application Server's keystore.
  • Install the CA certificate in the trust store for each client.
    If the CA certificates are not added to the trust store for each client user (the %APPDATA%\BladeLogic\client_keystore.pkcs12.PEM), users will still need to accept the CA-signed certificate. They can inspect the certificate presented by the BMC Server Automation Application Server and confirm that it is signed by a trusted CA.
  • Instruct users that they should not accept any self-signed certificates during the first connection to the BMC Server Automation Application Server. (Just as you would not accept a self-signed certificate, for example, when visiting a banking website.)

For information about implementing Application Server certificates, see Using-certificates-to-secure-communication-between-clients-and-Application-Servers.

Adding client-side certificates

BMC recommends configuring each deployed RSCD agent for client-side certificates, that is, each agent should be configured to require connecting entities to present a trusted certificate as proof of the identity of the NSH user. (In the case of an Application Server or an Network Shell proxy server, the NSH user is the Application Server or Network Shell proxy server itself, that is, a software entity. In the case of a direct connection from an NSH client, the NSH user is, in fact, the user who has to provide a certificate password when authenticating with blcred.) This practice prevents unauthenticated users from connecting to a deployed agent and thereby gaining access to the remote machine.

For information about implementing a client-side certificate policy, see Implementing-security-Application-Server-to-agents-or-repeaters.

Using NSH proxy

In addition to configuring each deployed RSCD agent for client-side certificates, BMC recommends configuring each deployed agent to communicate only with BMC Server Automation Application Servers. The Network Shell proxy service runs on the BMC Server Automation Application Server. This configuration prevents users from directly contacting an agent without authenticating themselves to a BMC Server Automation Application Server. Use the exports file to implement the restriction for each deployed agent, along with performing the setup of client-side certificates (described above) for communication from the BMC Server Automation Application Server to the RSCD agent.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC Server Automation 8.2