How to harden the CSA 4.3/4.4

Version 5



    This document outlines hardening done for the 4.3/4.4 CSA






    1. All packages are downloaded straight from CentOS servers. We build critical packages, like OpenSSL, in-house
    2. Only software necessary for performing the actions and functions of the Gateway are installed on the system limiting the number of tools a would-be attacker can abuse
    3. No common external access utilities exist on the system. (ie: httpclient, ftp client, ncftp, lynx ...) Generally, exploits use these types of tools to move additional software onto target machines.


    User accounts


    1. The 'root' user login is disabled by default
    2. The 'admin' user is the only user that can connect via ssh
    3. All system accounts use 'shadow' password tools
    4. System accounts lockout for a period of time after 5 consecutive bad login attempts
    5. 'Console', 'Admin', 'Service', and 'Client' only exist in the system database, they do not exist as Kernel system users


    Services / Ports / Firewall



    1. All ports/services/addresses are denied by default at the firewall
    2. IP spoof detection in use
    3. Syn packet filtering turned on
    4. UDP / ICMP filtering
    5. Internal IP address blacklist is applied
    6. Ports 80 (HTTP) is allowed (in/out) but not required
    7. Port 443 (HTTPS) is allowed (in/out) only 443 is required for functionality
    8. Port 25 (SMTP) is allowed (outgoing only) but not required
    9. Port 22 (SSH) is not allowed by default
    10. All other ports are explicitly denied


    Software / Applications


    1. Outgoing SMTP mail is handled by custom build mail application, sendmail is not installed
    2. Tripwire file scanning is performed at regular intervals on the system to detect possible compromised files
    3. Web interface and Gateway service processes run unprivileged
    4. Internal database server runs with network support disabled
    5. Management web interface (GSB) operates over authenticated ssl only (https port 443)


    Cloud Service Appliance Services


    1. Patching CSA to version 190 for 4.3 or 505 for 4.4 will allow you to block external web console access. Make sure the external Ip is set to the highest number nic as shown below. This is automatically done when 2 nics are configured and no additional configuration is needed.
    2. Connections to the Cloud Service Appliance from remote clients and the core are passed over ssl encrypted connections on port 443. The ssl sessions are signed by a special LANDESK signed certificate. If this certificate is modified in any way, the Gateway service will shut down
    3. Gateway client connections providing improper authentication or inappropriate syntax or public key data are dropped
    4. Invalid authentication from clients will lockout the client for a pre-determined amount of time (also configurable)
    5. Once the connection between a core and a client is established, the handshake and data encryption keys are left to the LDMS Core. No decryption is performed by the Cloud Service Appliance. This eliminates the possibility of a 'man in the middle' attack at the gateway
    6. All incoming connections (except ssh) are handled by the Cloud Service Appliance Broker service, including web services. Neither Apache nor IIS servers are used or installed