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.

   ---