Skip to ContentSun and Oracle Channel Sun How to Buy Log In

System Administration Guide: IP Services

View this book in:

Other Languages
日本語

Contained Within

Find More Documentation

Featured Support Resources

Download this book in PDF (1691 KB)

Chapter 20 Administering IPsec (Task)

This chapter provides procedures for implementing IPsec on your network.

This chapter contains the following information:

For overview information about IPsec, see Chapter 19, IPsec (Overview). The ipsecconf(1M), ipseckey(1M), and ifconfig(1M) man pages also describe useful procedures in their respective Examples sections.

Implementing IPsec Task Map

Table 20–1 Implementing IPsec Task Map


Task	Description	For Instructions, Go To …
Secure traffic between two IPv6 systems	Involves adding addresses to the `/etc/inet/ipnodes` file, entering IPsec policy in the `/etc/inet/ipsecinit.conf` file, manually adding keys with the `ipseckey` command, and invoking the `ipsecinit.conf` file.	How to Secure Traffic Between Two Systems
Secure a Web server by using IPsec policy	Involves enabling only secure traffic by entering different security requirements for different ports in the `ipsecinit.conf` file, and activating the file.	How to Secure a Web Server
Set up a virtual private network	Involves turning off IP forwarding, turning on IP strict destination multihoming, disabling most network and Internet services, adding security associations, and configuring a secure tunnel. Also involves turning on IP forwarding, configuring a default route, and running the routing protocol.	How to Set Up a Virtual Private Network
Replace current security associations	Involves flushing current security associations and entering new ones on every affected system.	How to Replace Current Security Associations

IPsec Tasks

This section provides procedures that enable you to secure traffic between two systems, secure a Web server by using IPsec policy, and set up a virtual private network. The system names enigma and partym are examples only. Substitute the names of your systems for the names enigma and partym.

How to Secure Traffic Between Two Systems

This procedure assumes that each system has two addresses, an IPv4 address and an IPv6 address, and that you are invoking AH protections by using one of the available algorithms. The procedure also assumes that you are sharing security associations. With shared security associations, only one pair of SAs is needed to protect the two systems.

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

On each system, add the addresses and host name for the other system in the /etc/inet/ipnodes file. The entries for one machine must be contiguous in the file:
1. On a system that is named partym, type the following:
  # Secure communication with enigma 192.168.66.1 enigma fec0::10:20ff:fea0:21f7 enigma
2. On a system that is named enigma, type the following:
  # Secure communication with partym 192.168.55.2 partym fec0::9:a00:20ff:fe7b:b667 partym
  These names are examples only. Use the names of your systems when securing traffic between them.
This step enables the boot scripts to use the system names without depending on nonexistent naming services.

On each system, edit the /etc/inet/ipsecinit.conf file to add the IPsec policy entry:
1. On enigma, type the following:
  {laddr enigma raddr partym} ipsec {auth_algs any sa shared}
2. On partym , type the following:
  {laddr partym raddr enigma} ipsec {auth_algs any sa shared}

On each system, add a pair of security associations between the two systems.

On each system, edit a read-only (600 permissions) /etc/inet/secret/ipseckeys file, and type the following lines in this file:

add ah spi random-number dst local-system authalg an_algorithm_name \
	    authkey random-hex-string-of-algorithm-specified-length
add ah spi random-number dst remote-system authalg an_algorithm_name \
	    authkey random-hex-string-of-algorithm-specified-length

Note –

The keys and SPI can and should be different for each security association.

Reboot each system.
# /etc/reboot
On reboot, the /etc/inet/secret/ipseckeys file is read before booting completes. When you change keys, ensure that the ipseckeys file is changed on both systems.

Example—Securing Traffic Between IPv4 Addresses

The following example describes how to secure traffic between systems with IPv4 addresses. The example uses automatic key management (IKE) to create security associations. IKE requires less administrative intervention, and scales easily to secure a large amount of traffic.

Replace the /etc/inet/ipnodes file in Step 2 of How to Secure Traffic Between Two Systems with the /etc/hosts file, as in the following:

On the system that is named partym, add enigma:
# echo "192.168.66.1 enigma" >> /etc/hosts
On the system that is named enigma, add partym to the /etc/hosts file:
# echo "192.168.55.2 partym" >> /etc/hosts
Edit the ipsecinit.conf file to add the IPsec policy entries.
Use the ike.config(4) file rather than the ipseckey command to add security associations. See IKE Tasks for the procedures.

Note –
You can also manually create the keys, as described in Step 4 in How to Secure Traffic Between Two Systems.
Reboot.

Example—Securing Traffic Between IPv6 Addresses Without Rebooting

The following example describes how to test secure traffic between systems with IPv6 addresses.

Do the How to Secure Traffic Between Two Systems procedure through Step 4.
Instead of rebooting, add the security associations to the database by typing the ipseckey command with the ipseckeys file as an argument.
# ipseckey -f /etc/inet/secret/ipseckeys
Activate IPsec policy with the ipsecconf command:
# ipsecconf -a /etc/inet/ipsecinit.conf
Note –
Read the warning when you execute the command. A socket that is already in use (latched) provides an unsecured back door into the system.

How to Secure a Web Server

A secure Web server requires that any incoming traffic that is not a Web client request pass security checks. The following procedure includes bypasses for Web traffic that is served on the Web server and for DNS client requests from this Web server. All other traffic requires ESP with 3DES and SHA-1 algorithms and uses a shared SA for outbound traffic. Sharing SAs avoids using too many security associations.

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total 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, it might also need to include port 53 for both TCP and UDP.

Create a read-only file, using the file name of your choice, for example IPsecWebInitFile, and type the following lines in this file:

# Web traffic that Web server should bypass.
	{sport 80 ulp tcp} bypass {dir out}
	{dport 80 ulp tcp} bypass {dir in}
	{sport 443 ulp tcp} bypass {dir out}
	{dport 443 ulp tcp} bypass {dir in}

	# Outbound DNS lookups should also be bypassed.
	{dport 53} bypass {dir out}
	{sport 53} bypass {dir in}

	# Require all other traffic to use ESP with 3DES and SHA-1.
	# Use a shared SA for outbound traffic, in order to avoid a
	# large supply of security associations.
	{} permit {encr_algs 3des encr_auth_algs sha}
	{} apply {encr_algs 3des encr_auth_algs sha sa shared}

This configuration enables only secure traffic to access the system, with the bypass exceptions that are described in the previous step.

Read the file you created in the previous step into /etc/inet/ipsecinit.conf.
# vi /etc/inet/ipsecinit.conf :r IPsecWebInitFile :wq!

Reboot.

The ipsecconf command does not affect already-established TCP connections, whose policies are latched. Rebooting ensures that IPsec policy is in effect on all TCP connections. At reboot, the TCP connections latch policy as it is specified in the IPsec policy file.
# reboot
The Web server now allows only Web-server traffic, as well as outbound DNS requests and replies. No other services work without enabling IPsec on a remote system. If keying material is handled automatically, the IKE daemon activates IPsec on a remote system with an IPv4 address. On a remote system with an IPv6 address, use the ipseckey(1M) command to enable IPsec on the remote system.

How to Set Up a Virtual Private Network

This procedure shows you how to set up a VPN by using the Internet to connect two networks within an organization. The procedure then shows you how to secure the traffic between the networks with IPsec. This procedure assumes that the networks' le1 interfaces are inside the VPN, and the le0 interfaces are outside the VPN on the two systems that implement the VPN link.

The procedure also uses ESP with DES and MD5. The algorithms that are used affect the key lengths, 64 bits (56 bits + 8 bits parity) for DES and 128 bits for MD5. You must perform the following procedure on the two systems that act as the gateway through the Internet. For a description of VPNs, see Virtual Private Networks.

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

Turn off IP forwarding:
# ndd -set /dev/ip ip_forwarding 0
Turning off IP forwarding prevents packets from being forwarded from one network to another through this system.

Turn on IP strict destination multihoming:
# ndd -set /dev/ip ip_strict_dst_multihoming 1
Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrives on the interface to which that address is assigned.

When you use the ndd(1M) command to turn off IP forwarding and turn on IP strict destination, multihoming shuts down the flow of packets except to the system itself, and then only if the packets arrive on the interface that corresponds to the destination IP address.

Disable most (if not all) network services on the Solaris machine by doing the following substeps, as needed:

Note –
The VPN router should allow very few incoming requests. You need to disable all processes that accept incoming traffic (for example, comment out lines in the inetd.conf file, kill SNMP, and so on). Alternately, you can use techniques similar to those in How to Secure a Web Server.
1. If inetd.conf has been edited to remove all but essential services, type the following command:
  # pkill -HUP inetd
2. If inetd.conf has not been edited to remove all but essential services, type the following command on a command line:
  # pkill inetd
3. Disable other Internet services, such as SNMP, NFS, and so on, by typing one or more commands such as the following examples, as needed:
  # /etc/init.d/nfs.server stop # /etc/init.d/sendmail stop
  Disabling network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, telnet, or rlogin could be exploited.

On each machine, add a pair of security associations between the two systems.

If the systems are using IPv4 addresses, the IKE daemon automatically creates the security associations after you have configured IKE to create them. You can use one of the following procedures to set up IKE for the VPN: How to Configure IKE With Pre-Shared Keys, How to Configure IKE With Self-Signed Public Certificates, or How to Configure IKE With Public Keys Signed by a Certificate Authority.
If the systems are using IPv6 addresses, you must manually create the security associations by doing the following substeps:
1. Enable the ipseckey command mode:
  # ipseckey >
  The > prompt indicates that you are in ipseckey command mode.
2. Type the following command:
  > add esp spi random-number src system1_addr dst system2_addr \ auth_alg md5 encr_alg des \ authkey random-hex-string-of-32-characters \ encrkey random-hex-string-of-16-characters
3. Press the Return key to execute the command.
4. Type the following command:
  > add esp spi random-number src system2_addr dst system1_addr \ auth_alg md5 encr_alg des \ authkey random-hex-string-of-32-characters \ encrkey random-hex-string-of-16-characters
  Note –
  The keys and SPI can and should be different for each security association.
5. Type Control-D or quit to exit this mode.

Configure a secure tunnel, ip.tun0 that adds another physical interface from the IP perspective, by performing the following substeps:

On System 1, type the following commands:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-taddr system2-taddr \
tsrc system1-addr tdst system2-addr encr_algs des encr_auth_algs md5

# ifconfig ip.tun0 up

On System 2, type the following commands:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system2-taddr system1-taddr \
tsrc system2-addr tdst system1-addr encr_algs des encr_auth_algs md5

# ifconfig ip.tun0 up

On each machine, turn on (in this example) le1:ip_forwarding and ip.tun0:ip_forwarding:
# ndd -set /dev/ip le1:ip_forwarding 1 # ndd -set /dev/ip ip.tun0:ip_forwarding 1
ip_forwarding means that packets that arrive off an interface can be forwarded, and packets that leave this interface might have originated on another interface. To successfully forward a packet, both the receiving and transmitting interfaces must have their ip_forwarding turned on.

Because le1 is inside the Intranet, and ip.tun0 connects the two systems through the Internet, ip_forwarding must be turned on for these two interfaces.

The le0 interface still has its ip_forwarding turned off. This configuration prevents someone on the outside (that is, the Internet) from injecting packets into the protected Intranet.

On each machine, ensure that routing protocols do not advertise the default route within the Intranet:
# ifconfig le0 private
While le0 has ip_forwarding turned off, any routing protocol implementation (for example, in.routed) might still advertise that le0 is a valid interface for forwarding packets to its peers inside the Intranet. Setting the interface's private flag helps reduce these advertisements.

On each system, manually add a default route over le0:
# pkill in.rdisc # route add default router-on-le0-subnet
Even though le0 is not part of the Intranet, it does need to reach across the Internet to its peer machine. To do this, Internet routing information is needed. The VPN system looks like a host (as opposed to a router) to the rest of the Internet, so either using a default route or running router discovery is sufficient.

Prevent in.rdisc from restarting when the system is rebooted by performing the following substeps:
1. Put the IP address of the default router on the le0 subnet in the file /etc/defaultrouter.
  
  This step prevents in.rdisc from being started at reboot.
2. Prevent routing from occurring early in the boot sequence, and thus reduce vulnerability:
  # touch /etc/notrouter
3. Edit the /etc/hostname.ip.tun0 file and add the following lines.
  system1-taddr system2-taddr tsrc system1-addr \ tdst system2-addr encr_algs des encr_auth_algs md5 up
4. Create an /etc/rc3.d/S99vpn_setup file and type the following lines.
  ndd -set /dev/ip le1:ip_forwarding 1 ndd -set /dev/ip ip.tun0:ip_forwarding 1 ifconfig le0 private in.routed

On each machine, run a routing protocol:
# in.routed

To prevent an adversary from having time to break your cryptosystem, you need to periodically replace the security associations that you created in Step 5 with new ones. Use the following procedure to replace your current security associations. If you are running an IPv4 network, the IKE module manages the replacement of security associations.

How to Replace Current Security Associations

This procedure enables you to replace current security associations. You should do this procedure periodically so that an adversary has less time to break your cryptosystem.

Become superuser on the system console.

Note –
Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the total security of the system is reduced to the security of the remote login session.

On each system, flush the current security associations in ipseckey command mode:
# ipseckey > flush >

Set new security associations for outbound packets:

> add esp spi new-random-number src local-system dst remote-system \
auth_alg the_algorithm-name encr_alg the_algorithm-name \
authkey random-hex-string-of-algorithm-specified-length \
encrkey random-hex-string-of-algorithm-specified-length

Press the Return key.

This step executes the command and redisplays the ipseckey command mode prompt.

Set new security associations for inbound packets:

> add esp spi new-random-number src remote-system dst local-system \
auth_alg the_algorithm-name encr_alg the_algorithm-name \
authkey random-hex-string-of-algorithm-specified-length \
encrkey random-hex-string-of-algorithm-specified-length