test

System Administration Guide: IP Services

Protecting Traffic With IPsec

This section provides procedures that enable you to secure traffic between two systems and to secure a web server. To protect a VPN, see Protecting a VPN With IPsec (Task Map). Additional procedures provide keying material and security associations, and verify that IPsec is working as configured.

The following information applies to all IPsec configuration tasks:

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.

  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 19–1.

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

    This step enables the service management facility (SMF) to use the system names without depending on nonexistent naming services. For more information, see the smf(5) man page.

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


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

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


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

  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 {auth_algs any encr_algs any sa shared}

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


      {laddr partym raddr enigma} ipsec {auth_algs any encr_algs any 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. 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.

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

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

  9. Verify that packets are being protected.

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

Example 19–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.

ProcedureHow to Use IPsec to Protect a Web Server From Nonweb Traffic

A secure web server allows web clients to talk to the web service. On a secure web server, traffic that is not web traffic must pass security checks. The following procedure includes bypasses for web traffic. In addition, this web server can make unsecured DNS client requests. All other traffic requires ESP with AES and SHA-1 algorithms.

Before You Begin

You must be in the global zone to configure IPsec policy. You have completed How to Secure Traffic Between Two Systems With IPsec so that the following conditions are in effect:

  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.

  2. Determine which services need to bypass security policy checks.

    For a web server, these services include TCP ports 80 (HTTP) and 443 (Secure HTTP). If the web server provides DNS name lookups, the server might also need to include port 53 for both TCP and UDP.

  3. Add the web server policy to the IPsec policy file.

    Add the following lines to the /etc/inet/ipsecinit.conf file:


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    This configuration allows only secure traffic to access the system, with the bypass exceptions that are described in Step 3.

  4. Verify the syntax of the IPsec policy file.


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

  5. Refresh the IPsec policy.


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

  6. Refresh the keys for IPsec.

    Your setup is complete. Optionally, you can perform Step 7.

  7. (Optional) Enable a remote system to communicate with the web server for nonweb traffic.

    Type the following policy in a remote system's ipsecinit.conf file:


    # Communicate with web server about nonweb stuff
#
{laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    A remote system can communicate securely with the web server for nonweb traffic only when the systems' IPsec policies match.

ProcedureHow to Display IPsec Policies

You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments.

Before You Begin

You must run the ipsecconf command in the global zone.

  1. Assume a role that includes the Network IPsec Management profile, or become superuser.

    To create a role that includes a network security profile and assign that role to a user, see How to Configure a Role for Network Security.

  2. Display IPsec policies.

    1. Display the global IPsec policy entries in the order that the entries were added.


      $ ipsecconf

      The command displays each entry with an index followed by a number.

    2. Display the IPsec policy entries in the order in which a match occurs.


      $ ipsecconf -l

    3. Display the IPsec policy entries, including per-tunnel entries, in the order in which a match occurs.


      $ ipsecconf -L

ProcedureHow to Generate Random Numbers on a Solaris System

If you are specifying keys manually, the keying material must be random. The format for keying material for a Solaris system is hexadecimal. Other operating systems can require ASCII keying material. To generate keying material for a Solaris system that is communicating with an operating system that requires ASCII, see Example 22–1.

On a Solaris system, you have three options for generating random keys.

  1. Generate random numbers in hexadecimal format.


    % od -x|-X -A n file | head -n
    -x

    Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4-character chunks.

    -X

    Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8-character chunks.

    -A n

    Removes the input offset base from the display.

    file

    Serves as a source for random numbers.

    head -n

    Restricts the display to the first n lines of output.

  2. Combine the output to create a key of the appropriate length.

    Remove the spaces between the numbers on one line to create a 32-character key. A 32-character key is 128 bits. For a security parameter index (SPI), you should use an 8-character key. The key should use the 0x prefix.

Example 19–2 Generating Key Material for IPsec

The following example displays two lines of keys in groups of eight hexadecimal characters each.


% od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b

By combining the four numbers on the first line, you can create a 32-character key. An 8-character number that is preceded by 0x provides a suitable SPI value, for example, 0xf3447465.

The following example displays two lines of keys in groups of four hexadecimal characters each.


% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

By combining the eight numbers on the first line, you can create a 32-character key.

ProcedureHow to Manually Create IPsec Security Associations

The following procedure provides the keying material for Step 5 in How to Secure Traffic Between Two Systems With IPsec. You are generating keys for two systems, partym and enigma. You generate the keys on one system, and then use the keys from the first system on both systems.

Before You Begin

You must be in the global zone to manually manage keying material for a non-global zone.

  1. Generate the keying material for the SAs.

    1. Determine the keys that you require.

      You need three hexadecimal random numbers for outbound traffic and three hexadecimal random numbers for inbound traffic. Therefore, one system needs to generate the following numbers:

      • Two hexadecimal random numbers as the value for the spi keyword. One number is for outbound traffic. One number is for inbound traffic. Each number can be up to eight characters long.

      • Two hexadecimal random numbers for the MD5 algorithm for AH. Each number must be 32 characters long. One number is for dst enigma. One number is for dst partym.

      • Two hexadecimal random numbers for the 3DES algorithm for ESP. For a 192-bit key, each number must be 48 characters long. One number is for dst enigma. One number is for dst partym.

    2. Decide on your method of key generation.

  2. On each system, perform the following steps:

    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 secure remote login.

    2. Add the keys to the manual keys file for IPsec.

      1. Edit the /etc/inet/secret/ipseckeys file on the enigma system to appear similar to the following:


        # ipseckeys - This file takes the file format documented in 
#   ipseckey(1m).
#   Note that naming services might not be available when this file
#   loads, just like ipsecinit.conf.
#
#   Backslashes indicate command continuation.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg 3des \
   auth_alg md5  \
   encrkey  d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d \
   authkey  e896f8df7f78d6cab36c94ccf293f031
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg 3des \
   auth_alg md5  \
   encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e \
   authkey ad9ced7ad5f255c9a8605fba5eb4d2fd

      2. Protect the manual keys file for IPsec with read-only permissions.


        # chmod 400 /etc/inet/secret/ipseckeys

      3. Verify the syntax of the manual keys file.


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

    The keying material on the two systems must be identical.

Example 19–3 Manually Creating Temporary IPsec Security Associations

In this example, the administrator tests various keys. Later, the administrator will type the permanent keys in the ipseckeys file.

During testing, the administrator creates keys by using the ipseckey command in interactive mode. When the ipseckey command is typed, the > prompt indicates interactive mode.


# ipseckey
>

To replace existing SAs, the administrator flushes the current SAs.


> flush
>

To create SAs for outbound packets, the administrator types the following command:


> add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg 3des \
auth_alg md5 \
encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d \
authkey e896f8df7f78d6cab36c94ccf293f031
>

The administrator types the following command for inbound packets:


> add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg 3des \
auth_alg md5 \
encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e \
authkey ad9ced7ad5f255c9a8605fba5eb4d2fd
>

To exit ipseckey interactive mode, the administrator types the quit command.


> quit
#

To change keys on the communicating system, the administrator follows the same steps. On that system, the first set of keys protects inbound packets and the second set of keys protects outbound packets.

ProcedureHow to Verify That Packets Are Protected With IPsec

To verify that packets are protected, test the connection with the snoop command. The following prefixes can appear in the snoop output:

Before You Begin

You must be superuser or have assumed an equivalent role to create the snoop output. You must have access to both systems to test the connection.

  1. On one system, such as partym, become superuser.


    % su -
Password: Type root password
#

  2. From the partym system, prepare to snoop packets from a remote system.

    In a terminal window on partym, snoop the packets from the enigma system.


    # snoop -v enigma
Using device /dev/hme (promiscuous mode)

  3. Send a packet from the remote system.

    In another terminal window, remotely log in to the enigma system. Provide your password. Then, become superuser and send a packet from the enigma system to the partym system. The packet should be captured by the snoop -v enigma command.


    % ssh enigma
Password: Type your password
% su -
Password: Type root password
# ping partym

  4. Examine the snoop output.

    On the partym system, you should see output that includes AH and ESP information after the initial IP header information. AH and ESP information that resembles the following shows that packets are being protected:


    IP:   Time to live = 64 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 4e0e
IP:   Source address = 192.168.116.16, enigma
IP:   Destination address = 192.168.13.213, partym
IP:   No options
IP:
AH:  ----- Authentication Header -----
AH:
AH:  Next header = 50 (ESP)
AH:  AH length = 4 (24 bytes)
AH:  <Reserved field = 0x0>
AH:  SPI = 0xb3a8d714
AH:  Replay = 52
AH:  ICV = c653901433ef5a7d77c76eaa
AH:
ESP:  ----- Encapsulating Security Payload -----
ESP:
ESP:  SPI = 0xd4f40a61
ESP:  Replay = 52
ESP:     ....ENCRYPTED DATA....

ETHER:  ----- Ether Header -----
...

ProcedureHow to Configure a Role for Network Security

If you are using role-based access control (RBAC) to administer your systems, you use this procedure to provide a network management role or network security role.

  1. Find the Network rights profiles in the local prof_attr database.


    % cd /etc/security
% grep Network prof_attr
Network IPsec Management:::Manage IPsec and IKE...
Network Link Security:::Manage network link security...
Network Management:::Manage the host and network configuration...
Network Security:::Manage network and host security...
Network Wifi Management:::Manage wifi network configuration...
Network Wifi Security:::Manage wifi network security...

    The Network Management profile is a supplementary profile in the System Administrator profile. If you have included the System Administrator rights profile in a role, then that role can execute the commands in the Network Management profile.

  2. Determine which commands are in the Network Management rights profile.


    % grep "Network Management" /etc/security/exec_attr
Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config
…
Network Management:suser:cmd:::/usr/sbin/snoop:uid=0

    The solaris policy commands run with privilege (privs=sys_net_config). The suser policy commands run as superuser (uid=0).

  3. Decide the scope of the network security roles at your site.

    Use the definitions of the rights profiles in Step 1 to guide your decision.

    • To create a role that handles all network security, use the Network Security rights profile.

    • To create a role that handles IPsec and IKE only, use the Network IPsec Management rights profile.

  4. Create a network security role that includes the Network Management rights profile.

    A role with the Network Security or the Network IPsec Management rights profile, in addition to the Network Management profile, can execute the ifconfig, snoop, ipsecconf, and ipseckey commands, among others, with appropriate privilege.

    To create the role, assign the role to a user, and register the changes with the name service, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Example 19–4 Dividing Network Security Responsibilities Between Roles

In this example, the administrator divides network security responsibilities between two roles. One role administers wifi and link security and another role administers IPsec and IKE. Each role is assigned to three people, one person per shift.

To create the roles, the administrator uses the Solaris Management Console.

ProcedureHow to Manage IKE and IPsec Services

The following steps provide the most likely uses of the SMF services for IPsec, IKE, and manual key management. By default, the policy and ipsecalgs services are enabled. Also by default, the ike and manual-key services are disabled.

  1. To manage IPsec policy, do one of the following:

    • After adding new policies to the ipsecinit.conf file, refresh the policy service.


      # svcadm refresh svc:/network/ipsec/policy

    • After changing the value of a service property, view the property value, then refresh and restart the policy service.


      # svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf
# svcprop -p config/config_file policy
/etc/inet/MyIpsecinit.conf
# svcadm refresh svc:/network/ipsec/policy
# svcadm restart svc:/network/ipsec/policy

  2. To automatically manage keys, do one of the following:

    • After adding entries to the /etc/inet/ike/config file, enable the ike service.


      # svcadm enable svc:/network/ipsec/ike

    • After changing entries in the /etc/inet/ike/config file, refresh the ike service.


      # svcadm refresh svc:/network/ipsec/ike

    • After changing the value of a service property, view the property value, then refresh and restart the service.


      # svccfg -s ike setprop config/admin_privilege=modkeys
# svcprop -p config/admin_privilege ike
modkeys
# svcadm refresh svc:/network/ipsec/ike
# svcadm restart svc:/network/ipsec/ike

    • To stop the ike service, disable it.


      # svcadm disable svc:/network/ipsec/ike

  3. To manually manage keys, do one of the following:

    • After adding entries to the /etc/inet/secret/ipseckeys file, enable the manual-key service.


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

    • After changing the ipseckeys file, refresh the service.


      # svcadm refresh manual-key

    • After changing the value of a service property, view the property value, then refresh and restart the service.


      # svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile
# svcprop -p config/config_file manual-key
/etc/inet/secret/MyIpseckeyfile
# svcadm refresh svc:/network/ipsec/manual-key
# svcadm restart svc:/network/ipsec/manual-key

    • To prevent manual key management, disable the manual-key service.


      # svcadm disable svc:/network/ipsec/manual-key

  4. If you modify the IPsec protocols and algorithms table, refresh the ipsecalgs service.


    # svcadm refresh svc:/network/ipsec/ipsecalgs
Troubleshooting

Use the svcs service command to find the status of a service. If the service is in maintenance mode, follow the debugging suggestions in the output of the svcs -x service command.