Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
  Previous   Contents   Next 
   
 
Chapter 20

Administering IPsec (Task)

This chapter provides procedures for implementing IPsec on your network.

This chapter contains the following information:

For overview information about IPsec, see Chapter 19, IPsec (Overview). The ipsecconf(1M), ipseckey(1M), and ifconfig(1M) man pages also describe useful procedures in their respective Examples sections.

Implementing IPsec Task Map

Table 20-1 Implementing IPsec Task Map

Task

Description

For Instructions, Go To ...

Secure traffic between two IPv6 systems

Involves adding addresses to the /etc/inet/ipnodes file, entering IPsec policy in the /etc/inet/ipsecinit.conf file, manually adding keys with the ipseckey command, and invoking the ipsecinit.conf file.

"How to Secure Traffic Between Two Systems"

Secure a Web server by using IPsec policy

Involves enabling only secure traffic by entering different security requirements for different ports in the ipsecinit.conf file, and activating the file.

"How to Secure a Web Server"

Set up a virtual private network

Involves turning off IP forwarding, turning on IP strict destination multihoming, disabling most network and Internet services, adding security associations, and configuring a secure tunnel. Also involves turning on IP forwarding, configuring a default route, and running the routing protocol.

"How to Set Up a Virtual Private Network"

Replace current security associations

Involves flushing current security associations and entering new ones on every affected system.

"How to Replace Current Security Associations"

IPsec Tasks

This section provides procedures that enable you to secure traffic between two systems, secure a Web server by using IPsec policy, and set up a virtual private network. The system names enigma and partym are examples only. Substitute the names of your systems for the names enigma and partym.

How to Secure Traffic Between Two Systems

This procedure assumes that each system has two addresses, an IPv4 address and an IPv6 address, and that you are invoking AH protections by using one of the available algorithms. The procedure also assumes that you are sharing security associations. With shared security associations, only one pair of SAs is needed to protect the two systems.

  1. Become superuser on the system console.


    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. On each system, add the addresses and host name for the other system in the /etc/inet/ipnodes file. The entries for one machine must be contiguous in the file:

    1. On a system that is named partym, type the following:

      # Secure communication with enigma 
      192.168.66.1 enigma
      fec0::10:20ff:fea0:21f7 enigma
    2. On a system that is named enigma, type the following:

      # Secure communication with partym 
      192.168.55.2  partym
      fec0::9:a00:20ff:fe7b:b667 partym

      These names are examples only. Use the names of your systems when securing traffic between them.

    This step enables the boot scripts to use the system names without depending on nonexistent naming services.

  3. On each system, edit the /etc/inet/ipsecinit.conf file to add the IPsec policy entry:

    1. On enigma, type the following:

      {laddr enigma raddr partym} ipsec {auth_algs any sa shared}
    2. On partym , type the following:

      {laddr partym raddr enigma} ipsec {auth_algs any sa shared}
  4. On each system, add a pair of security associations between the two systems.

    On each system, edit a read-only (600 permissions) /etc/inet/secret/ipseckeys file, and type the following lines in this file:

    add ah spi random-number dst local-system authalg an_algorithm_name \
    	    authkey random-hex-string-of-algorithm-specified-length
    add ah spi random-number dst remote-system authalg an_algorithm_name \
    	    authkey random-hex-string-of-algorithm-specified-length

    Note - The keys and SPI can and should be different for each security association.


  5. Reboot each system.

    # /etc/reboot

    On reboot, the /etc/inet/secret/ipseckeys file is read before booting completes. When you change keys, ensure that the ipseckeys file is changed on both systems.

Example--Securing Traffic Between IPv4 Addresses

The following example describes how to secure traffic between systems with IPv4 addresses. The example uses automatic key management (IKE) to create security associations. IKE requires less administrative intervention, and scales easily to secure a large amount of traffic.

  1. Replace the /etc/inet/ipnodes file in Step 2 of "How to Secure Traffic Between Two Systems" with the /etc/hosts file, as in the following:

    On the system that is named partym, add enigma:

    # echo "192.168.66.1 enigma" >> /etc/hosts

    On the system that is named enigma, add partym to the /etc/hosts file:

    # echo "192.168.55.2 partym" >> /etc/hosts
  2. Edit the ipsecinit.conf file to add the IPsec policy entries.

  3. Use the ike.config(4) file rather than the ipseckey command to add security associations. See "IKE Tasks" for the procedures.


    Note - You can also manually create the keys, as described in Step 4 in "How to Secure Traffic Between Two Systems".


  4. Reboot.

Example--Securing Traffic Between IPv6 Addresses Without Rebooting

The following example describes how to test secure traffic between systems with IPv6 addresses.

  1. Do the "How to Secure Traffic Between Two Systems" procedure through Step 4.

  2. Instead of rebooting, add the security associations to the database by typing the ipseckey command with the ipseckeys file as an argument.

    # ipseckey -f /etc/inet/secret/ipseckeys 
  3. Activate IPsec policy with the ipsecconf command:

    # 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.


 
 
 
  Previous   Contents   Next