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 non-secured DNS client requests. All other traffic requires ESP with Blowfish and SHA-1 algorithms. Other traffic also uses a shared SA for outbound traffic. Shared SAs reduce the number of security associations 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 total 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.
    	{sport 80 ulp tcp} bypass {dir out}
    	{dport 80 ulp tcp} bypass {dir in}
    	{sport 443 ulp tcp} bypass {dir out}
    	{dport 443 ulp tcp} bypass {dir in}
    
    	# Outbound DNS lookups should also be bypassed.
    	{dport 53} bypass {dir out}
    	{sport 53} bypass {dir in}
    
    	# 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 the previous step.

  4. Read the file that you created in the previous step into /etc/inet/ipsecinit.conf.


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


    # chmod 400 IPsecWebInitFile
    
  6. To secure the web server without rebooting, use the ipseckey and ipsecconf commands.


    # ipseckey -f /etc/inet/secret/ipseckeys 
    # ipsecconf -a /etc/inet/ipsecinit.conf 
    

    Note –

    Read the warning when you execute the command. A socket that is already in use (latched) provides an unsecured back door into the system.


    You can also reboot. Rebooting ensures that IPsec policy is in effect on all TCP connections. At reboot, the TCP connections latch policy according to 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.

If you want a remote system to communicate securely with the Web server for non-Web traffic, their policies must match. The following policy in a remote system's ipsecinit.conf file enables the system to communicate with the Web server:


# Communicate with Web server about non-Web stuff
#
	{} permit {encr_algs blowfish encr_auth_algs sha}
	{} apply {encr_algs blowfish encr_auth_algs sha sa shared}