System communications

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.

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 might 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: SHA-256
  • Key Exchange: DHE_RSA (2048)

It is enabled using certificates in the following locations:

For details see Secure deployment.

Apache SSL key passphrases

BMC recommend that you do not passphrase the Apache SSL server key used by the appliance. Doing so requires entry of the passphrase at service start-up, which conflicts with the following operations:

  • Resetting configuration of a machine (invoked from the Cluster Management UI and when a machine leaves the cluster)
  • Configuring HTTPS (via the UI and possibly when sending configuration to cluster members). A specific issue is that once a passphrase is applied it is no longer possible to restart HTTPS via the UI, without first regenerating the server key.
  • Atrium SSO (via the UI and possibly when sending configuration to cluster members)
  • Backup/Restore (as SSL keys are restored) 

End-user authentication

End-user application authentication is critical to the security of the entire solution. BMC 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 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 128-bit AES encryption or 2048-bit public key/2048-bit RC4 or 256-bit AES encryption. Communication from BMC 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 Discovery and might need to be opened on a firewall for correct operation. These will be required in addition to the ports directly used for Discovery communications.

Incoming 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 Discovery allows any protocols except SSLv1 and SSLv2. The Apache module (mod_ssl) used to provide SSL and TLS support supports the following:

  • TLS v1
  • TLS v1.1
  • TLS v1.2

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

Incoming / Outgoing Appliance Consolidation port

Consolidation uses TLS communication. The scanning appliances connect to the consolidation appliance using TLS 1.2 to transfer CORBA messages:

Port Number

Port assignment

Use

25032

TLS/CORBA

Consolidation data

Incoming / Outgoing Appliance Clustering ports

Clusters use TLS communication to communicate between the members. All members of the cluster both create outgoing connections to these ports and accept incoming connections on them:

Port Number

Port assignment

Use

25030

TLS/CORBA

Cluster management

25031TLS/CORBAData store
25032TLS/CORBAReasoning

Outgoing 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 accessible to do this. As part of discovery the current domain names of IPs will be looked up, so 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 might 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

Outgoing 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

Incoming Windows Proxy / Outgoing Appliance ports

The Windows proxies listen for incoming connections from appliances. Communication uses TLS 1.2 connections containing CORBA messages. The ports in use can be configured using the Windows Proxy Manager, but the defaults are:

Port Number

Port assignment

Use

4321

TLS/CORBA

Active Directory Proxy
4322TLS/CORBAObsolete Workgroup Proxy
4323TLS/CORBACredential Proxy

Outgoing 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

Was this page helpful? Yes No Submitting... Thank you

Comments

  1. Andreas Enocson

    There is a typo on the port for Reasoning under the "Incoming / Outgoing Appliance Clustering ports".

    It states 20532 but I believe it should be 25032.

    Jun 20, 2016 02:47