System Administration Guide: IP Services

ProcedureHow to Secure Traffic Between Two Systems With IPsec

This procedure assumes the following setup:

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

  6. Enable IPsec policy.

  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.

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:

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.