What is the security model for network communication in the TrueSight Capacity Optimization (TSCO) Gateway Server/Agent product? Does the TSCO Agent support encryption and strong authentication for network communication?

Version 4
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BMC Performance Assurance for Servers


    APPLIES TO:

    TrueSight Capacity Optimization (Gateway Server/Agent) 20.02, 11.5, 11.3.01, 11.0, 10.7, 10.5, 10.3, 10.0 ; BMC Performance Assurance 9.5



    QUESTION:

     
       The TrueSight Capacity Optimization Agent security model supports two basic configurations; One where either all network communication is disabled and the other where network communication is allowed via unencrypted network communication. This document attempts to provide an overview of the basic security model for the TSCO Agent network communication and then additionally address:    
         
    • What options are available for providing some additional security?
    •    
    • Can SSH port forwarding be used to provide strong authentication and/or encryption for Perform network communication?
    •   
         
         NOTE: This document was originally published as Solution SLN000000199201.    
     
       
        
         
    • TrueSight Capacity Optimization (Gateway Server/Agent) 11.0, 10.7, 10.5, 10.3, 10.0
    •    
    • BMC Performance Assurance  9.5, 9.0, 7.5.10, 7.5.00, 7.4.10,  7.4.00,  7.3.00
    •   
       
       
        
         
    • Unix
    •    
    • Windows
    •   
       


    ANSWER:

     

    The TrueSight Capacity Optimization Agent currently has two different security models: 'Basic Security' and 'Advanced Security'.

    In an Advanced Security installation of the TSCO Agent all components of the product that are capable of network communication are replaced with equivalent binaries that are not capable of any network access. That means that the product itself is incapable of any network communication and thus data collection requests would need to be handled on the remote node itself (typically via a cron script) and data transfer would need to be handled outside of the Perform product.

    In a 'Basic Security' installation of the TSCO Agent (which is the typical install mode) there is a mechanism for a basic username/hostname authentication using the $BEST1_HOME/local/setup/Authorization.cfg file to restrict access to Perform functionality to a specific machine or specific user on a machine. This basic authentication mechanism is handled by the Perform Agent on the remote node. This means that the Service Daemon will pass the request to the agent, but if the requesting user or machine is not authorized for that request the agent will not act on the request.

    In all supported releases of the BPA/TSCO Agent the processes listening on network ports are running as non-privileged users which means that a remote root exploit is not available via the TSCO Agent network aware components.

    At this time there is no functionality within the TSCO Agent product to support strong authentication or encryption of TSCO Agent to TSCO Gateway Server network communication.

    Q: What options are available for providing some additional security?

    One option to restrict access to the TSCO Agent Service Daemon (port 10128) is to use TCP Wrappers to wrap the Service Daemon and reject the connection if it does not come from an authorized host.

    To restrict access to the TSCO agent process (listening on port 6767) one can use the $BEST1_HOME/local/setup/Authorization.cfg file to tell the Agent to only act on requests from Authorized hosts.

    Q: Can SSH port forwarding be used to provide strong authentication and/or encryption for Perform network communication?

    The architecture of the network communication model in Perform makes it impossible for ssh port forwarding to be used in conjunction with the TSCO Agent. For ssh port forwarding to work one must be able to tell the server side of the connection (best1collect) to connect to 'localhost' on a specific port. That specific port on localhost would be the end point to an ssh tunnel that linked to the server side process (in this case 'bgssd.exe') on the remote node. So, you replace the direct connection to a hostname on the remote node with a connection to a port on localhost that maps to that hostname. The problem is that in Perform there is no way to specify which port the 'best1collect' command will use to communicate with the agent - it will always use the 'bgssd' port defined in /etc/services on the console as the Service Daemon port. That means that best1collect request (start collect, query collect, transfer data, and so on) requests cannot be forwarded via ssh port forwarding.

    It would be possible to replace existing TSCO Agent product functionality (start collects, data transfer) with custom scripts using ssh commands but it would require extensive customization. Basically, data collection requests could be issued via 'ssh' to the remote node (so you actually would end up running 'best1collect' on the remote node through an ssh session, and data transfer requests could be handled via 'scp' or another secure data transfer option. Once the data was on the remote node it could be inserted back into the normal data processing workflow in Manager.

    Q: How do the TSCO Agent/Gateway Server client and server processes authenticate each other for network communication?

    Although there is no mechanism within the TSCO Agent to reject a connection request to the Service Daemon or TSCO Agent on initial connection there is a basic authentication process within the TSCO Agent to limit access based upon the source machine and user of the request.

    When a request is received by the Service Daemon it uses the getpeername() system call to determine which host has made the request. It then checks that host against the list of authorized hosts defined in the $BEST1_HOME/local/setup/Authorization.cfg file on Unix or %BEST1_COLLECT_HOME%\local\setup\Authorization.cfg file on Windows. The client process also tells the Service Daemon which user on the machine is making the request. This server and user combination is what is checked against the Authorization.cfg file.

      
    Related Products:  
       
    1. TrueSight Capacity Optimization
    2.  
    3. BMC Performance Assurance for Servers
       Legacy ID:KA309298

     


    Article Number:

    000230697


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles