openSolaris 2008 - Protecting Traffic With IPsec - 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, provide security associations, and verify that IPsec is working as configured.

The following information applies to all IPsec configuration tasks:

IPsec and zones – To manage IPsec policy and keys for a non-global zone, create the IPsec policy file in the global zone, and run the IPsec configuration commands from the global zone. Use the source address which corresponds to the non-global zone that is being configured. You can also configure IPsec policy and keys in the global zone for the global zone. In the Solaris Express, Developer Edition 2/07 release, you can use IKE to manage keys in a non-global zone.
IPsec and RBAC – To use roles to administer IPsec, see Chapter 8, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. For an example, see How to Create a Role for Configuring Network Security.
IPsec and SCTP – IPsec can be used to protect Streams Control Transmission Protocol (SCTP) associations, but caution must be used. For more information, see IPsec and SCTP.

How to Secure Traffic Between Two Systems With IPsec

Note - You configure IPsec policy in the global zone.

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 invokes AH protection with the MD5 algorithm, which requires a key of 128 bits.
Each system invokes ESP protections with the 3DES algorithm, which requires a key of 192 bits.
Each system uses shared security associations.
With shared SAs, only one pair of SAs is needed to protect the two systems.

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.
On each system, add host entries to the /etc/inet/hosts file.
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
```
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.
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.
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.
Reboot each system.
```
# init 6
```
Verify that packets are being protected.
For the procedure, see How to Verify That Packets Are Protected With IPsec.

Example 20-1 Securing Traffic With IPsec Without Rebooting

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

How to Secure a Web Server With IPsec

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 nonsecured DNS client requests. All other traffic requires ESP with AES and SHA-1 algorithms.

Note - You configure IPsec policy in the global zone.

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

Create a file in the /etc/inet directory for the web server policy.

Give the file a name that indicates its purpose, for example IPsecWebInitFile. Type the following lines in this 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 2.

Copy the contents of the file that you created in Step 3 into the /etc/inet/ipsecinit.conf file.
Protect the IPsecWebInitFile file with read-only permissions.
```
# chmod 400 IPsecWebInitFile
```
Secure the web server without rebooting.
Choose one of the following options.
- If you are using IKE for key management, stop and restart the in.iked daemon.
```
# pkill in.iked
# /usr/lib/inet/in.iked
```
- If you are manually managing keys, use the ipseckey and ipsecconf commands.
  Use the IPsecWebInitFile as the argument to the ipsecconf command. If you use the ipsecinit.conf file as the argument, the ipsecconf command generates errors when policies in the file are already implemented on the system.
```
# ipseckey -f /etc/inet/secret/ipseckeys 
# ipsecconf -a /etc/inet/IPsecWebInitFile 
```
Caution - 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. The same warning applies to restarting the in.iked daemon.

You can also reboot. Rebooting ensures that the IPsec policy is in effect on all TCP connections. At reboot, the TCP connections use the policy in the IPsec policy file.
(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.

How to Display IPsec Policies

You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments. The command must be run from the global zone.

Assume a role that includes the Network Security profile, or become superuser.
To create a role that includes the Network Security profile and assign that role to a user, see How to Create a Role for Configuring Network Security.
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.
Display the IPsec policy entries in the order in which a match occurs.
```
$ ipsecconf -l
```
Display the IPsec policy entries, including per-tunnel entries, in the order in which a match occurs.
```
$ ipsecconf -L
```

How to Generate Random Numbers on a Solaris System

If you are entering keys manually, the keying material should 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 23-1.

If your site has a random number generator, use that generator. Otherwise, you can use the od command with the /dev/random Solaris device as input. For more information, see the od(1) man page.

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

How to Manually Create IPsec Security Associations

Note - You manually manage keying material for a non-global zone from the global zone.

The following procedure provides the keying material for the procedure, How to Secure Traffic Between Two Systems With IPsec.

Generate the keying material for the SAs.
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.
If you have a random number generator at your site, use the generator. You can also use the od command. See How to Generate Random Numbers on a Solaris System for the procedure.
On the system console on one of the systems, 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.
Enable the ipseckey command mode:
```
# ipseckey

>
```
The > prompt indicates that you are in ipseckey command mode.
If you are replacing existing SAs, flush the current SAs.
```
> flush
> 
```
To prevent an adversary from having time to break your SAs, you need to replace the keying material.

Note - You must coordinate key replacement on communicating systems. When you replace the SAs on one system, the SAs must also be replaced on the remote system.
To create SAs, type the following command.
```
> add protocol spi random-hex-string \
src addr dst addr2 \
protocol-prefix_alg protocol-algorithm \
protocol-prefixkey random-hex-string-of-algorithm-specified-length
```
You also use this syntax to replace SAs that you have just flushed.
protocol

Specifies either esp or ah.

random-hex-string

Specifies a random number of up to eight characters in hexadecimal format. Precede the characters with 0x. If you enter more numbers than the security parameter index (SPI) accepts, the system ignores the extra numbers. If you enter fewer numbers than the SPI accepts, the system pads your entry.

addr

Specifies the IP address of one system.

addr2

Specifies the IP address of the peer system of addr.

protocol-prefix

Specifies one of encr or auth. The encr prefix is used with the esp protocol. The auth prefix is used with the ah protocol, and for authenticating the esp protocol.

protocol-algorithm

Specifies an algorithm for ESP or AH. Each algorithm requires a key of a specific length.
Authentication algorithms include MD5 and SHA. Encryption algorithms include 3DES and AES.

random-hex-string-of-algorithm-specified-length

Specifies a random hexadecimal number of the length that is required by the algorithm. For example, the MD5 algorithm requires a 32-character string for its 128-bit key. The 3DES algorithm requires a 48-character string for its 192-bit key.
1. For example, on the enigma system, protect outbound packets.
  Use the random numbers that you generated in Step 1.
  For Solaris 10 1/06:
```
> add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg 3des \
auth_alg md5 \
encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d \
authkey e896f8df7f78d6cab36c94ccf293f031
>
```
  Note - The peer system must use the same keying material and the same SPI.
2. Still in ipseckey command mode on the enigma system, protect inbound packets.
  Type the following commands to protect the 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
>
```
  Note - The keys and SPI can be different for each SA. You should assign different keys and a different SPI for each SA.
To exit ipseckey command mode, press Control-D or type quit.

To ensure that the keying material is available to IPsec at reboot, add the keying material to the /etc/inet/secret/ipseckeys file.

The lines of the /etc/inet/secret/ipseckeys file are identical to the command line language.

For example, the /etc/inet/secret/ipseckeys file on the enigma system would 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.
#
# 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

Protect the file with read-only permissions.
```
# chmod 400 /etc/inet/secret/ipseckeys
```

Repeat Step 2 through Step 7 on the partym system.

Use the same keying material that was used on enigma.

The keying material on the two systems must be identical. As shown in the following example, only the comments in the ipseckeys file differ. The comments differ because dst enigma is inbound on the enigma system, and outbound on the partym system.

# partym ipseckeys file
#
# for inbound packets
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 outbound 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

How 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:

AH: Prefix indicates that AH is protecting the headers. You see AH: if you used auth_alg to protect the traffic.
ESP: Prefix indicates that encrypted data is being sent. You see ESP: if you used encr_auth_alg or encr_alg to protect the traffic.

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.

On one system, such as partym, become superuser.
```
% su -
Password: Type root password
# 
```
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)
```
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
```

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

How to Create a Role for Configuring Network Security

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

Find the Network rights profiles in the local prof_attr database.
```
% cd /etc/security
% grep Network prof_attr
Network Management:::Manage the host and network configuration …
Network Security:::Manage network and host security …
System Administrator:::…Network Management…
```
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.
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).

Determine which commands are in the Network Security rights profile.

% grep "Network Security" /etc/security/exec_attr
…
Network Security:solaris:cmd:::/usr/sbin/ipsecconf:privs=sys_net_config
…
Network Security:solaris:cmd:::/usr/sbin/ipseckey:privs=sys_net_config
…

Create a role that includes the Network Security and the Network Management rights profiles.
A role with both profiles 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.