This chapter provides procedures for implementing IPsec on your network.
For overview information about IPsec, see Chapter 18, Overview of IPsec. The ipsecconf(1M), ipseckey(1M), and ifconfig(1M) man pages also describe useful procedures in their respective Examples sections.
Task |
Description |
For Instructions, Go To ... |
---|---|---|
Secure traffic between two systems |
Involves adding addresses to the /etc/hosts file, editing the /etc/inet/ipsecinit.conf file, adding security associations, and invoking the ipsecinit.conf file. | |
Secure a Web server using IPsec policy |
Involves enabling only secure traffic by editing the ipsecinit.conf file and invoking this file. | |
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, configuring a secure tunnel, turning on IP forwarding, configuring default route, and running the routing protocol. | |
Replace current security associations |
Involves flushing current security associations and entering new ones. |
This section provides procedures that enable you to secure traffic between two systems, secure a Web server using IPsec policy, and set up a virtual private network.
This procedure assumes that you are invoking AH protections using any algorithm. It also assumes you want security associations shared (that is, only one pair of SAs are needed to protect the two systems) and that each system has only one IP address.
Become superuser on the system console.
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 address and host name for the other system in the /etc/hosts file. You can do this using the following command:
On System 1:
# echo "system2_addr system2_name" >> /etc/hosts |
On System 2:
# echo "system1_addr system1_name" >> /etc/hosts |
This enables the boot scripts to use the system names without depending on non-existent naming services.
On each system, edit the /etc/inet/ipsecinit.conf file by adding the following lines:
Add Security Associations using the following substeps:
On each system, create a read-only (600 permissions) keyfile, using the file name of your choice, say MyKeyfile, and type the following lines in this file:
add ah spi random-number dst system1_name authalg algorithm_name \ authkey random-hex-string-of-algorithm-specified-length add ah spi random-number dst system2_name authalg algorithm_name \ authkey random-hex-string-of-algorithm-specified-length |
On each system, enable the security associations by typing the following command:
# ipseckey -f keyfile |
On each system, do one of the following steps:
Invoke the ipsecinit.conf file by typing the following command:
# ipsecconf -a /etc/inet/ipsecinit.conf |
Or reboot both systems.
If you reboot both systems, you must first insert the following command (used in step 4) in a boot script:
ipseckey -f keyfile |
To do so, continue with the following steps.
Change the keyfile name to ipseckey by typing the following command:
# cp keyfile /etc/inet/ipseckey |
Make the ipseckey file read-only by typing the following command:
# chmod 600 /etc/inet/ipseckey |
Create a boot script, /etc/rc3.d/s99ipsec_setup, which contains the following code:
if [ -f /etc/inet/ipseckeys -a -f /etc/inet/ipsecinit.conf ]; then /usr/sbin/ipseckey -f /etc/inet/ipseckeys fi |
On subsequent reboots the /etc/inet/ipseckeys file will be read before booting completes. If you change keys, make sure the file gets changed on both systems.
This procedure includes bypasses for Web traffic served on the Web server and 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, so as not to require too many security associations.
Become superuser on the system console.
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 checking.
For a Web server, this includes TCP ports 80 (HTTP) and 443 (Secure HTTP). If the Web server does 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, say MyIPsecInitFile, 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, so as not to require 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 enables only secure traffic to access the system, with the bypass exceptions listed in the previous step.
Do either one of the following two substeps:
Copy the file you created in the previous step into /etc/inet/ipsecinit.conf and reboot using the following commands:
# cp filename /etc/inet/ipsecinit.conf # reboot |
Invoke the file you created using the following command:
ipsecconf -a filename |
These steps are possible because the file has no name service requirements. Also, when invoking ipsecconf, existing TCP connections do not fall under the IPsec policy. A warning is issued by the ipsecconf command to this effect.
The Web server now allows only Web-server traffic, as well as outbound DNS requests and replies. No other services will work without adding security associations using ipseckey(1M) and enabling IPsec on the remote system.
This procedure shows you how to set up a VPN using the Internet to connect two networks within an organization, and 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 used affect the key lengths, 64 bits (56 bits+ 8 bits parity) for DES and 128 bits for MD5. You must do the following procedure on the two systems that act as the gateway through the Internet. For a descripton of VPNs, see "Enabling Virtual Private Networks".
Become superuser on the system console.
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 by typing the following command:
# 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 by typing the following command:
# ndd -set /dev/ip ip_strict_dst_multihoming 0 |
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 system by doing the following substeps, as needed:
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), or use techniques similar to the "How to Secure a Web Server Using IPsec Policy".
If inetd.conf has been edited to remove all but essential services, type the following command:
# pkill -HUP inetd |
If inetd.conf has not been edited to remove all but essential services, type the following command on a command line:
# pkill inetd |
Disable other Internet services, such as SNMP, NFS, and so on, by typing one or more commands like the following examples, as needed:
# /etc/init.d/nfs.server stop # /etc/init.d/sendmail stop |
Disabling network services keeps IP packets from doing any harm to the system. For example, an SNMP daemon, telnet, or rlogin could be exploited.
On each system, add a pair of security associations between the two systems by doing the following substeps:
Type the following command:
# ipseckey |
This enables the ipseckey command mode.
At the ipseckey command mode prompt, type the following command:
> add esp spi random-number src system1_addr dst system2_addr \ auth_alg md5 encr_alg des \ authkey very-random-hex-string-of-32-characters \ encrkey very-random-hex-string-of-16-characters |
Press the Return key.
This executes the command and redisplays the ipseckey command mode prompt.
At the ipseckey command mode prompt, type the following command:
> add esp spi random-number src system2_addr dst system1_addr \ auth_alg md5 encr_alg des \ authkey very-random-hex-string-of-32-characters \ encrkey very-random-hex-string-of-16-characters |
The keys and SPI can and should be different for each security association.
At the ipseckey command mode prompt, type Ctrl-D or Exit to exit this mode.
Configure a secure tunnel, ip.tun0, by doing 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 |
This sets up the secure tunnel and adds another physical interface from the IP perspective.
On each system, turn on (in this example) le1:ip_forwarding and ip.tun0:ip_forwarding by typing the following commands:
# ndd -set /dev/ip le1:ip_forwarding 1 # ndd -set /dev/ip ip.tun0:ip_forwarding 1 |
ip_forwarding means that packets arriving off an interface can be forwarded, and packets leaving 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.
Since 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 prevents someone on the outside (that is, the Internet) from injecting packets into the protected Intranet.
On each system, ensure that routing protocols do not advertise the default route within the Intranet by typing the following command:
# 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 by typing the following commands:
# 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 doing the following substeps:
Put the IP address of the default router on the le0 subnet in the file /etc/defaultrouter.
This stops in.rdisc from being started at reboot.
Type the following command.
# touch /etc/notrouter |
This keeps the vulnerability down by preventing routing to occur early in the boot sequence.
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 |
Edit the /etc/rc3.d/S99ipsec_setup file and add the following lines in the if/then statement at the end.
ndd -set /dev/ip le1:ip_forwarding 1 ndd -set /dev/ip ip.tun0:ip_forwarding 1 ifconfig le0 private in.routed |
The file should look like:
if [ -f /etc/inet/ipseckeys -a -f /etc/inet/ipsecinit.conf ]; then /usr/sbin/ipseckey -f /etc/inet/ipseckeys ndd -set /dev/ip le1:ip_forwarding 1 ndd -set /dev/ip ip.tun0:ip_forwarding 1 ifconfig le0 private in.routed fi |
On each system, run a routing protocol by typing the following command:
# in.routed |
To prevent an adversary from having too much time to break your cryptosystem, you need to replace periodically the security associations that you invoked in step 2 with new ones. Use the following procedure to replace your 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.
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 your current security associations by doing the following substeps:
Do step 5 in the "How to Set Up a Virtual Private Network" procedure to set new security associations by changing the values of SPI and keys.