Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: September 2018

How to Secure Network Traffic Between Two Servers With IPsec

    This procedure assumes the following setup:

  • The systems are assigned static IP addresses and are running the network configuration profile DefaultFixed. If the netadm list command returns Automatic, see the netcfg(1M) man page for more information.

  • The two systems are named host1 and host2.

  • Each system has an IP address. This can be an IPv4 address, an IPv6 address, or both. This procedure uses IPv4 addresses.

  • Each system is either a global zone or an exclusive-IP zone. For more information, see IPsec and Oracle Solaris Zones.

  • Each system encrypts traffic with the AES algorithm and authenticates it with SHA-2.

    Note -  The SHA-2 algorithm might be required at some sites.
  • Each system uses shared security associations.

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

Note -  To use IPsec with labels on a Trusted Extensions system, see the extension of this procedure in How to Apply IPsec Protections in a Multilevel Trusted Extensions Network in Trusted Extensions Configuration and Administration.

Before You Begin

    A user with specific rights can run the following commands without being root:

  • To run configuration commands, you must become an administrator who is assigned the Network IPsec Management rights profile.

  • In this administrative role, you can edit IPsec-related system files and create keys by using the pfedit command.

  • To edit the hosts file, you must be in the root role or have explicit permission to edit that file. See Example 39, Enabling a Trusted User to Configure and Manage IPsec.

For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.

If you administer remotely, see Example 31, Configuring IPsec Policy Remotely by Using an ssh Connection and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3 for secure remote login instructions.

  1. On each system, add host entries to the /etc/inet/hosts file.

    This step enables the local naming service to resolve system names to IP addresses without depending on a networked naming service.

    1. On a system that is named host2, type the following in the hosts file:
      ## Secure communication with host1 host1
    2. On a system that is named host1, type the following in the hosts file:
      ## Secure communication with sytem2 host2
  2. 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.

    # pfedit /etc/inet/ipsecinit.conf
  3. Add an IPsec policy entry to the ipsecinit.conf file.

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

    1. On the host1 system, add the following policy:
      {laddr host1 raddr host2} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}

      Because the dir keyword is not used, the policy applies to both outbound and inbound packets.

    2. On the host2 system, add the identical policy:
      {laddr host2 raddr host1} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
  4. On each system, configure IKE to manage the IPsec SAs.

    Follow one of the configuration procedures in Configuring IKEv2. For the syntax of the IKE configuration file, see the ikev2.config(4) man page. If you are communicating with a system that only supports the IKEv1 protocol, refer to Configuring IKEv1 and the ike.config(4) man page.

    Note -  If you must generate and maintain your keys manually, see How to Manually Create IPsec Keys.
  5. Verify the syntax of the IPsec policy file.
    % pfbash
    # /usr/sbin/ipsecconf -c /etc/inet/ipsecinit.conf

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

  6. Refresh the IPsec policy.
    # svcadm refresh ipsec/policy:default

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

    # svcadm enable ipsec/policy:default
  7. Activate the keys for IPsec.
    • If the ike service is not enabled, enable it.

      Note -  If you are communicating with a system that can only run the IKEv1 protocol, specify the ike:default instance.
      # svcadm enable ipsec/ike:ikev2
    • If the ike service is enabled, restart it.
      # svcadm restart ike:ikev2

    If you manually configured keys in Step 4, complete the procedure How to Manually Create IPsec Keys to activate the keys.

  8. Verify that packets are being protected.

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

Example 31  Configuring IPsec Policy Remotely by Using an ssh Connection

In this example, the administrator in the root role configures IPsec policy and keys on two systems by using the ssh command to reach the second system. The administrator is defined identically on both systems. For more information, see the ssh(1) man page.

  1. The administrator configures the first system by performing Step 1 through Step 5 of How to Secure Network Traffic Between Two Servers With IPsec.

  2. In a different terminal window, the administrator uses the identically defined user name and ID to log in remotely with the ssh command.

    local-system % ssh -l jdoe other-system
    other-system # su - root 
    Enter password: xxxxxxxx
    other-system #
  3. In the terminal window of the ssh session, the administrator configures the IPsec policy and keys of the second system by completing Step 1 through Step 7.

  4. The administrator ends the ssh session.

    other-system # exit
    # exit
  5. The administrator enables IPsec policy on the first system by completing Step 6 and Step 7.

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

Example 32  Configuring IPsec Policy With FIPS 140-2 Approved Algorithms

In this example, the administrator configures the IPsec policy on a FIPS 140-2-enabled system to follow a site security policy that requires symmetric algorithms whose key length is 256 bits.

The administrator specifies two possible IPsec policies. The first policy specifies AES in CCM mode with a 256-bit key length for encryption. The second policy specifies AES with a 256-bit key length for encryption and SHA384 for authentication.

 {laddr host1 raddr host2} ipsec {encr_algs aes-ccm(256) sa shared} or ipsec
 {laddr host1 raddr host2} ipsec {encr_algs aes(256) encr_auth_algs sha384 sa shared}
Example 33  Configuring IPsec Policy to Use the IKEv2 Protocol Only

In this example, the administrator configures the IPsec policy on a server to ignore the IKEv1 protocol. All SAs will be created by IKEv2. Attempted negotiations with IKEv1 will fail. The administrator creates a corresponding IKEv2 configuration file.

## ipsecinit.conf
{raddr dir both } ipsec {encr_algs aes-ccm sa shared ike_version 2}

This rule says that any host on the subnet can talk to the server by using the combined mode aes-ccm algorithm.

The corresponding IKEv2 configuration file enables all address ranges whose certificate is signed by the same chain of trust as the server to connect with the server1.example.com server:

## ikev2.config 
        ikesa_xform { dh_group 21 auth_alg sha256 encr_alg aes }

        label "IKEv2-only certificate"

        request_http_certs yes
        auth_method cert
        local_id DNS = "server1.example.com"
        remote_id ANY

The configuration of the server1 server is complete. Client systems who install the certificate and configure IPsec and IKEv2 can communicate with server1.

Example 34  Transitioning Client Systems to Use IPsec by Using the or pass Action on the Server

In this example, the administrator is gradually configuring all clients on a subnet to use IPsec. The or pass {} action enables the server to receive packets from all clients on the subnet, including clients that are not configured with IPsec.

## ipsecinit.conf
{raddr dir both } ipsec {encr_algs aes-ccm sa shared} or pass {}

The or pass {} action passes all traffic that is not encrypted by the specified encryption mechanisms but otherwise satisfies the rule, as well as IPsec traffic that matches the rule. The connection to the server that has an or pass rule must originate from the client. The action is cached when the connection is first established.

All clients on the subnet will be able to establish a connection to the server.