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.

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.

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

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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:

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.