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:

IPsec and zones – To
manage IPsec policy and keys for a shared-IP 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 that 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. For an exclusive-IP zone, you configure
IPsec policy in the non-global zone. Starting in the Solaris 10 7/07 release, you can use IKE to manage keys in a non-global zone.

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.

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.

On a system that is named enigma, type
the following in the hosts or ipnodes file:

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.

First, the administrator configures the first system by performing Step 2 through Step 5 of the preceding procedure.

Then, in a different terminal window, the administrator uses
the ssh command to log in to the second system.

local-system # ssh other-system
other-system #

In the terminal window of the ssh session,
the administrator configures the IPsec policy and keys of the second system
by completing Step 2 through Step 6.

Then, the administrator ends the ssh session.

other-system # exit
local-system #

Finally, the administrator enables IPsec policy on the first
system by completing Step 6.

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.

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

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.

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 IPsec policy for the web server
and enable it.

Starting in the Solaris 10 4/09 release, follow the steps from Step 4 to Step 7.

If you are running a release prior to the Solaris 10 4/09 release, follow
the steps from Step 8 to Step 11.

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

Copy the contents of the file that you created in Step 8 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.

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

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–3 Generating Key Material for IPsec

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

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

How to Manually
Create IPsec Security Associations

The following procedure provides the keying material for the procedure, 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 shared-IP zone.

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 SHA1 algorithm for
authentication. For a 160–bit key, each number must be 40 characters
long. One number is for dst enigma. One number is for dst partym.

Two hexadecimal random numbers for the AES algorithm for ESP
encryption. For a 256-bit key, each number must be 64 characters long. One
number is for dst enigma. One number is for dst partym.

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.

Create the SAs.

Starting in the Solaris 10 4/09 release, follow the steps from Step 8 to Step 10.

If you are running a release prior to the Solaris 10 4/09 release, follow
the steps from Step 4 to Step 9.

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 SHA1. Starting in the Solaris 10 4/09 release,
SHA256 and SHA512 are supported. Encryption algorithms include DES, 3DES,
AES, and Blowfish.

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.

Example 20–4 Replacing IPsec SAs

In this example, the administrator is configuring a system that is running
the current Solaris 10 release. The administrator generates new keys, changes the
keying information in the ipseckeys file, then restarts
the service.

Finally, the administrator restarts the manual-key service.
The restart command flushes the old keys before adding the new keys.

# svcadm restart manual-key

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.

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

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.

In the current release, to create
a role that handles IPsec and IKE only, use the Network IPsec Management rights
profile.

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.

Example 20–5 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.

Then, the administrator assigns the LinkWifi role to the appropriate
users.

The administrator names the second role IPsec Administrator.

The administrator assigns the Network IPsec Management and
the Network Management rights profiles to the role.

Then, the administrator assigns the IPsec Administrator role
to the appropriate users.

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

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.