IPsec and IKE Administration Guide

How to Secure a Web Server

A secure web server allows web clients to talk to the web service. On a secure web server, traffic that is not web traffic must pass security checks. The following procedure includes bypasses for web traffic. In addition, this web server can make nonsecured DNS client requests. All other traffic requires ESP with Blowfish and SHA algorithms. Other traffic also uses a shared SA for outbound traffic. Shared SAs reduce the number of SAs that must be generated.

  1. On the system console, become superuser or assume an equivalent role.


    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session.


  2. Determine which services need to bypass security policy checks.

    For a web server, these services include TCP ports 80 (HTTP) and 443 (Secure HTTP). If the web server provides DNS name lookups, the server might also need to include port 53 for both TCP and UDP.

  3. Create a file in the /etc/inet directory for the web server policy. Give the file a name that indicates its purpose, for example IPsecWebInitFile. Type the following lines in this file:


    # Web traffic that web server should bypass.
    	{lport  80 ulp tcp dir both} bypass {}
    	{lport 443 ulp tcp dir both} bypass {}
    
    	# Outbound DNS lookups should also be bypassed.
    	{rport 53 dir both} bypass {}
    
    	# Require all other traffic to use ESP with Blowfish and SHA-1.
    	# Use a shared SA for outbound traffic, in order to avoid a
    	# large supply of security associations.
    	{} permit {encr_algs blowfish encr_auth_algs sha}
    	{} apply {encr_algs blowfish encr_auth_algs sha sa shared}

    This configuration enables only secure traffic to access the system, with the bypass exceptions that are described in Step 2.

  4. Read the file that you created in Step 3 into the /etc/inet/ipsecinit.conf file.


    # vi  /etc/inet/ipsecinit.conf 
     :r IPsecWebInitFile
     :wq!
  5. Protect the IPsecWebInitFile file with read-only permissions.


    # chmod 400 IPsecWebInitFile
    
  6. Secure the web server without rebooting. Choose one of the following options.

    • If you are using IKE for key management, stop and restart the in.iked daemon.


      # pkill in.iked
      # /usr/lib/inet/in.iked
      
    • If you are manually managing keys, use the ipseckey and ipsecconf commands.


      # ipseckey -f /etc/inet/secret/ipseckeys 
      # ipsecconf -a /etc/inet/IPsecWebInitFile 
      

      If you have existing entries in the ipsecinit.conf file, the file generates errors when read again.


    Caution – Caution –

    Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, the socket is in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf. The same warning applies to restarting the in.iked daemon.


    You can also reboot. Rebooting ensures that the IPsec policy is in effect on all TCP connections. At reboot, the TCP connections use the policy in the IPsec policy file.

    The web server now allows only web-server traffic, as well as outbound DNS requests and replies. No other services work without enabling IPsec on a remote system.

  7. (Optional) To enable a remote system to communicate with the web server for nonweb traffic, put the following policy in a remote system's ipsecinit.conf file.

    A remote system can communicate securely with the web server for nonweb traffic only when their IPsec policies match.


    # Communicate with web server about nonweb stuff
    #
    {saddr webserver} permit {encr_algs blowfish encr_auth_algs sha}
    {saddr webserver} apply {encr_algs blowfish encr_auth_algs sha sa shared}