How to Secure Traffic Between Two Systems With IPsec

This procedure assumes the following setup:

• The two systems are named enigma and partym.

• Each system has two addresses, an IPv4 address and an IPv6 address.

• Each system requires ESP encryption with the AES algorithm, which requires a key of 128 bits, and ESP authentication with the SHA1 message digest, which requires a 160–bit key.

• Each system uses shared security associations.

  With shared SAs, only one pair of SAs is needed to protect the two systems.

Before You Begin

You must be in the global zone to configure IPsec policy for the system or for a shared-IP zone. For an exclusive-IP zone, you configure IPsec policy in the non-global zone.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   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. Use the ssh command for a secure remote login. For an example, see Example 20–1.

   ---

2. On each system, check host entries.

   In the current release, add the host entries to the /etc/inet/hosts file.

   On a system that is running a release prior to the Solaris 10 7/07 release, add IPv4 and IPv6 entries to the /etc/inet/ipnodes file. The entries for one system must be contiguous in the file. For more information about system configuration files, see TCP/IP Configuration Files and Chapter 11, IPv6 in Depth (Reference).

   If you are connecting systems with IPv4 addresses only, you modify the /etc/inet/hosts file. In this example, the connecting systems are running an earlier Solaris release and are using IPv6 addresses.

   1. On a system that is named enigma, type the following in the hosts or ipnodes file:

      # Secure communication with partym 192.168.13.213 partym 2001::eeee:3333:3333 partym

   2. On a system that is named partym, type the following in the hosts or ipnodes file:

      # Secure communication with enigma 192.168.116.16 enigma 2001::aaaa:6666:6666 enigma

   Using the naming services for symbolic names is insecure.

3. On each system, create the IPsec policy file.

   The file name is /etc/inet/ipsecinit.conf. For an example, see the /etc/inet/ipsecinit.sample file.

4. Add an IPsec policy entry to the ipsecinit.conf file.

   1. On the enigma system, add the following policy:

      {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   2. On the partym system, add the identical policy:

      {laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

      For the syntax of IPsec policy entries, see the ipsecconf(1M) man page.

5. On each system, add a pair of IPsec SAs between the two systems.

   You can configure Internet Key Exchange (IKE) to create the SAs automatically. You can also add the SAs manually.

   ---

   Note –

   You should use IKE unless you have good reason to generate and maintain your keys manually. IKE key management is more secure than manual key management.

   ---

   • Configure IKE by following one of the configuration procedures in Configuring IKE (Task Map). For the syntax of the IKE configuration file, see the ike.config(4) man page.

   • To add the SAs manually, see How to Manually Create IPsec Security Associations.

6. Enable IPsec policy.

   • If you are running a release prior to the Solaris 10 4/09 release, reboot the system.

     # init 6

     Then, go to How to Verify That Packets Are Protected With IPsec.

   • Starting in the Solaris 10 4/09 release, refresh the IPsec service and enable the key management service.

     Complete the steps from Step 7 to Step 10.

7. Verify the syntax of the IPsec policy file.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

   Fix any errors, verify the syntax of the file, and continue.

8. Refresh the IPsec policy.

   # svcadm refresh svc:/network/ipsec/policy:default

   IPsec policy is enabled by default, so you refresh it. If you have disabled IPsec policy, enable it.

   # svcadm enable svc:/network/ipsec/policy:default

9. Activate the keys for IPsec.

   • If you configured IKE in Step 5, do one of the following:

     • If the ike service is not enabled, enable it.

       # svcadm enable svc:/network/ipsec/ike:default

     • If the ike service is enabled, restart it.

       # svcadm restart svc:/network/ipsec/ike:default

   • If you manually configured keys in Step 5, do one of the following:

     • If the manual-key service is not enabled, enable it.

       # svcadm enable svc:/network/ipsec/manual-key:default

     • If the manual-key service is enabled, refresh it.

       # svcadm refresh svc:/network/ipsec/manual-key:default

10. Verify that packets are being protected.

    For the procedure, see How to Verify That Packets Are Protected With IPsec.

Example 20–1 Adding IPsec Policy When Using an ssh Connection

In this example, the administrator as superuser configures IPsec policy and keys on two systems by using the ssh command to reach the second system. For more information, see the ssh(1) man page.

• First, the administrator configures the first system by performing Step 2 through Step 5 of the preceding procedure.

• Then, in a different terminal window, the administrator uses the ssh command to log in to the second system.

  local-system # ssh other-system other-system #

• In the terminal window of the ssh session, the administrator configures the IPsec policy and keys of the second system by completing Step 2 through Step 6.

• Then, the administrator ends the ssh session.

  other-system # exit local-system #

• Finally, the administrator enables IPsec policy on the first system by completing Step 6.

The next time the two systems communicate, including by using an ssh connection, the communication is protected by IPsec.

Example 20–2 Securing Traffic With IPsec Without Rebooting

The following example is useful when you are running a release prior to the Solaris 10 4/09 release. That is, in your release, IPsec is not managed as a service. The example describes how to implement IPsec in a test environment. In a production environment, it is more secure to reboot than to run the ipsecconf command. For the security considerations, see the end of this example.

Instead of rebooting at Step 6, choose one of the following options:

• If you used IKE to create keying material, stop and then restart the in.iked daemon.

  # pkill in.iked # /usr/lib/inet/in.iked

• If you added keys manually, use the ipseckey command to add the SAs to the database.

  # ipseckey -c -f /etc/inet/secret/ipseckeys

  Then, activate the IPsec policy with the ipsecconf command.

  # ipsecconf -a /etc/inet/ipsecinit.conf

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