Page tree

Skip to end of metadata
Go to start of metadata

Wherever possible, communications between elements of the system use high-grade encryption.

The core of the application manages the discovery and reasoning engines. It consistently interacts with the security engine to ensure user authentication and request authorization so that each action taken by the application can only be triggered from the application itself or by a user through the application UI or command line. External communications between the user and the application can be configured to use HTTPS over 128bit SSL.

The encryption of communication between the discovery engine (appliance or Windows proxy) and the target depends on the discovery method used. For example, ssh is encrypted, but telnet and rlogin (which may both be disabled) are not. Discovery credentials can be configured to use a user supplied SSH key per credential. These keys and their associated passphrases are stored in the credential vault. It is recommended that SSH keys are always protected with a strong passphrase.

Secure communications

Secure communications between elements of the system use CORBA over TLS (Transport Layer Security) with the following details:

  • Protocol: TLSv1.2
  • Encryption: AES_256_CBC
  • Message hashing: SHA1
  • Key Exchange: DHE_RSA (2048)

It is enabled using certificates in the following locations:

  • Each appliance (scanning or consolidation)
  • Each Windows proxy
  • Certificate Authority on each appliance and proxy

This refers to communications between components of the BMC Atrium Discovery system, not communications between BMC Atrium Discovery and discovery targets, or the user's web browser.

The default certificates shipped with BMC Atrium Discovery 9.0 expire on September 17 2015. You can use longer lived default certificates (expiring August 2032) that are also shipped on the appliance. 

For maximum security, you should replace the default certificates with your own, as described in the replacing the certificates.

Updating the certificates with new defaults 

BMC Atrium Discovery 9.0 ships with the old (expiring September 2015) and new (expiring August 2032) keys and certificates. By default it continues to use the old keys. 

On the appliance, the /usr/tideway/data/installed/keys directory contains:

  • appliance_key_01.pem (old key + certificate) 
  • appliance_key_02.pem (new key + certificate)

On each proxy, assuming a default installation, the C:\Program Files\BMC Software\ADDM Proxy\etc directory contains:

  • slave_key_01.pem (old key + certificate)
  • slave_key_02.pem (new key + certificate)
To update the certificates, copy the new version over the old. That is:
  • On the appliance, execute the following command:
    cp /usr/tideway/data/installed/keys/appliance_key_02.pem /usr/tideway/etc/appliance_key_01.pem
    Then restart the appliance services. 
  • On each of the proxies:
    copy "C:\Program Files (x86)\BMC Software\ADDM Proxy\etc\slave_key_02.pem" "C:\Program Files (x86)\BMC Software\ADDM Proxy\runtime\<proxy_name>\etc\slave_key_01.pem" 
    Then restart the proxy service.  

When copied, the filenames are changed from:

  • appliance_key_02.pem to appliance_key_01.pem  
  • slave_key_02.pem to slave_key_01.pem

The certificate authority file, ca_01.pem, already contains both public certificates. Consequently, both private keys are accepted until the old ones expire. This means that before the expiration date, you do not have to perform the updates at once. The appliance can be updated and the services restarted, and operation continues. You can then update each proxy in turn.

Replacing the certificates 

When replacing the default certificates with your own, do not use a general purpose corporate certificate authority. To ensure that no one else can create certificates that the appliance and proxies trust, you should create a CA unique to the group of appliances and proxies that you intend to use together. The appliance and proxies trust a certificate that is signed by any CA in its CA bundle. 

 Three certificate files are required to secure communications between the appliances and between the appliance and proxy:

  • appliance_key_01.pem: the appliance certificate.
  • slave_key_01.pem: the proxy certificate.
  • ca_01.pem: the certificate authority certificate.

The appliance_key_01.pem and ca_01.pem certificates are located in the /usr/tideway/etc directory on each appliance.

The slave_key_01.pem and ca_01.pem are located in the C:\Program Files\BMC Software\ADDM Proxy\etc directory on the proxy. These certificates are the defaults for any proxy installed on that host. New proxy services installed on the host use copies of the default keys.

Examining existing certificates

To check the issuer and validity dates of a certificate run the following command as the tideway user:

  openssl x509 -noout -issuer -dates -in <certificate_file_name>

To view all details of a certificate run the following command as the tideway user:

  openssl x509 -noout -text -in <certificate_file_name>

Preparation

On the appliance:

  • Stop the tideway services.
  • From the /usr/tideway/etc directory, take a backup of  appliance_key_01.pem and ca_01.pem.

On the Windows host:

  • Stop the Windows proxy services.
  • From the C:\Program Files\BMC Software\ADDM Proxy\runtime\<Proxy_name>\etc directory, take a backup of slave_key_01.pem and ca_01.pem.

Replace the appliance certificate

To replace the appliance certificate, perform the following steps:

  1. Use a certificate authority to create a private key and Certificate Signing Request (CSR) using RSA as the encryption type and with a key length of 2048 bits. Rename the certificate to appliance_req.pem.

  2. When prompted, complete the required information. The PEM password cannot be changed from Passw0rd. For example:

    PEM pass phrase: Passw0rd
    Country Name: UK
    State or Province Name (full name) []:London
    Locality Name (eg, city): London
    Organization Name (eg, company): BMC Software
    Organizational Unit Name (eg, section): BMC Software unit
    Common Name: CommonName.bmc.com
    Email Address: BMCSoftwareTestEmail@bmc.com
    A challenge password:
    An optional company name: BMC Software Ltd
  3. Send appliance_req.pem to a Certificate Authority (CA) for signing.
    If your organization has an internal CA which verifies and signs the request, see the CA authorization note below. Otherwise, you must create your own CA.

  4. Obtain the signed certificate from the CA and rename it to appliance_key_01.pem.

  5. Copy the certificate to the /usr/tideway/etc/ directory on the appliance.
    If the CA returns a signed certificate in the binary DER format, it must be converted to the PEM format.

BMC Atrium Discovery requires the private key and certificate to be in the same file, with only the BASE 64 encoded data between the BEGIN and END markers. Concatenate the data as shown in the following example:

cat appliance_key.pem >> /usr/tideway/etc/appliance_key_01.pem
awk '/-----BEGIN CERTIFICATE-----/, $NF ~ /-----END CERTIFICATE-----/' newcert.pem >> /usr/tideway/etc/appliance_key_01.pem

The appliance_key_01.pem certificate file does not have any special file permissions. As it contains a private key, which is sensitive data, it is recommended that you secure it with a passphrase.

Replace the proxy certificate

To replace the proxy certificate, perform the following steps:

  1. Use a certificate authority to create a private key and Certificate Signing Request (CSR) using RSA as the encryption type, with a key length of 2048 bits. Rename the certificate to slave_req.pem.

  2. When prompted, complete the required information. The PEM password cannot be changed from Passw0rd. For example:

    PEM pass phrase: Passw0rd
    Country Name: UK
    Locality Name (eg, city): London
    State or Province Name (full name) []:London
    Organization Name (eg, company): BMC Software
    Organizational Unit Name (eg, section): BMC Software unit
    Common Name: CommonName.bmc.com
    Email Address: BMCSoftwareTestEmail@bmc.com
    A challenge password:
    An optional company name:
    An optional company name: BMC Software Ltd
  3. Send slave_req.pem to a CA for signing.
    If your organization has an internal CA which verifies and signs the request, see the CA authorization note below. Otherwise, you must create your own CA.

  4. Obtain the signed certificate from the CA and rename it to slave_key_01.pem.

  5. Copy the certificate to the following directories on the proxy:
    • C:\Program Files\BMC Software\ADDM Proxy\runtime\<Proxy_name>\etc
    • For the default key to be used by new proxy services installed on the host, copy it toC:\Program Files\BMC Software\ADDM Proxy\etc

    If the CA returns a signed certificate in the binary DER format, it must be converted to the PEM format. 

BMC Atrium Discovery requires the private key and certificate to be in the same file, with only the BASE 64 encoded data between the BEGIN and END markers. Concatenate the data as shown in the following example:

cat slave_key.pem >> slave_key_01.pem
awk '/-----BEGIN CERTIFICATE-----/, $NF ~ /-----END CERTIFICATE-----/' newcert.pem >> slave_key_01.pem 

Replace the CA certificate

To replace the CA certificate, perform the following steps:

  1. Obtain the CA public certificate in the .pem format and rename it to ca_01.pem
  2. Copy the certificate to the following directories on the proxy host:
    • C:\Program Files\BMC Software\ADDM Proxy\runtime\<Proxy_name>\etc\
    • For the default key to be used by new proxy services installed on the host, copy it to C:\Program Files\BMC Software\ADDM Proxy\etc
  3. Copy the certificate to the /usr/tideway/etc/ directory on each appliance.

Tasks after generating the certificates

After generating the certificates, perform the following tasks:

  1. Restart the tideway services on each appliance.
  2. Restart the proxy.
  3. From the Discovery > Devices > Windows Proxies page, select the proxy pool that the proxy belongs to by clicking its name. The Edit Windows Proxy Pool page is displayed.
  4. From the Pool contents list, click the Ping link corresponding to the proxy to check whether it can be reached. If it can be contacted then the certificates have been replaced successfully.
  5. Check that the scanner and consolidator have maintained their connection by starting a snapshot scan on the scanning appliance and checking that it appears on the consolidator UI.

On upgrade, the certificates for the appliance and proxy are retained.

CA authorization

The Windows proxies and appliances that communicate with each other require their certificates to be signed by the CA they trust. Validation is not done on any information that is in the certificates, such as CN. For secure communication, a separate CA is required for each group of appliances and Windows proxies that communicate with each other.

End-user authentication

End-user application authentication is critical to the security of the entire solution. BMC Atrium Discovery supports a number of Web authentication plug-ins and various levels of authentication strength, requiring one of many authentication factors:

  • SSL Client Certificate Verification - Strong authentication using a public key infrastructure certificate. The client's SSL Certificate is verified by the Web server. The user name is extracted from the certificate and used for authorization via LDAP
  • SSL Certificate Lookup - The user is authenticated by looking up custom parts of the client's SSL Certificate via LDAP. The certificate is not verified, but it must be valid
  • LDAP Authentication - The user is authenticated against an LDAP server by entering a username and password
  • Standard Web Authentication - The user is authenticated as a local user by entering a username and password

Secure export to CMDB

The communication between BMC Atrium Discovery and BMC Atrium CMDB is based on the CMDB API. The encryption that comes with the AR Server is the Standard Encryption 512-bit public key/56-bit DES encryption on the wire. If a customer acquired the higher levels of Remedy Encryption (a separate product), then the customer could obtain either 1024-bit public key/128-bit RC4 or 2048-bit public key/2048-bit RC4 encryption. Communication from BMC Atrium Discovery to the AR Server can be configured to use a single chosen port (ARTCPPORT).

Ports used for System Communication

The following ports are used by the BMC Atrium Discovery and may need to be opened on a firewall for correct operation. These will be required in addition to the ports directly used for Discovery communications

Appliance User Interface ports

These ports will need to be open to access the Main UI and CLI for both normal operation and administration of updates. Enabling HTTPS in BMC Atrium Discovery allows any protocols except SSLv1 and SSLv2. The Apache module (mod_ssl) used to provide SSL and TLS support supports the following:

  • RHEL5 - TLS v1. No support for TLS v1.1 or v1.2 is provided by OpenSSL libraries.
  • RHEL6 - TLS v1, v1.1, and v1.2 support. TLS v1.1 and v1.2 support was added with the openssl-1.0.1e-15.el6 package, this is available in the December 2013 RHEL 6 operating system upgrade.

Note: The Apache module has not been updated so it is not currently possible to explicitly enforce or disable TLS v1.1 or 1.2.

Port Number

Port assignment

Use

22

SSH

Appliance CLI access

80

HTTP

Main UI Standard

443

HTTPS

Main UI Secure

Appliance Service ports

These ports will be used in general operation. If configured email alerts will be sent under certain conditions and an SMTP relay needs to be accessable to do this. As part of discovery the current domain names of IPs will be looked up and access to your DNS infrastructure is required for this to work. It is essential for correct operation of the system that accurate time is kept for timestamps and access to an NTP service may be required for this. If AD/LDAP UI user authentication is desired then access to your AD/LDAP infrastructure is required.

Port Number

Port assignment

Use

25

SMTP

Email Relay

53

DNS

Domain Name Lookup

123

NTP

Time Synchronisation

389

LDAP

LDAP UI User Authentication

636

LDAPS

Secure LDAP UI User Authentication

Appliance CMDB Sync ports

The BMC Atrium CMDB is built on the AR System platform. This uses a portmapper approach to do RPC calls in much the same way that WMI access occurs. As such unless action is taken the ports used will be 111 to contact the portmapper and an ephemeral port will be used for the duration of the connection.
You would be advised to arrange your architecture to not have a firewall between the appliance and the CMDB unless your CMDB is set to use a fixed port by setting the ARTCPPORT variable.

Port Number

Port assignment

Use

ARTCPPORT Value

AR System

CMDB Sync

Windows proxy service ports

If an AD Windows proxy is deployed then the Windows Server hosting it must have access to your AD/LDAP infrastructure.

Port Number

Port assignment

Use

389

LDAP

LDAP User Authentication

  • No labels