The Internet Security Protocol, IPsec, incorporates security for network transmission

17 Internet Protocol Security: IPsec The Internet Security Protocol, IPsec, incorporates security for network transmission into the Internet Protocol (IP) directly. IPsec is integrated into the new IPv6 protocol (Internet Protocol version 6). It can also be used with the older IPv4 protocol (see Chapter 38). IPsec provides methods for both encrypting data and authenticating the host or network it is sent to. The process can be handled manually or automated using the IPsec racoon key exchange tool. With IPsec, the kernel can automatically detect and decrypt incoming transmissions, as well as encrypt outgoing ones. You can also use IPsec to implement virtual private networks, encrypting data sent over the Internet from one local network to another. Though IPsec is a relatively new security method, its integration into the Internet Protocol will eventually provide it wide acceptance. Several projects currently provide development and implementation of IPsec tools. The original IPsec tools are provided by the KAME project, www.kame.net. Current versions can be obtained from souceforge.net/projects/ipsectools. RPM packages can be obtained from rpmfind.net. Other IPsec tool projects include the Free Secure/Wide Area Network project (FreeS/WAN) at www.freeeswan.org, which provides a Linux implementation of IPsec tools, and VPN Consortium (VPNC) at www.vpnc.org, which supports Windows and Macintosh versions. FreeS/WAN provides both Red Hat RPM packages and source code for their tools. NOTE Currently, the Fedora Core does not include support for IPsec tools but later versions will. The redhat-config-network tool includes panels for IPsec support, but you need to install IPsec tools to activate this support. IPsec Protocols IPsec is made up of several protocols that provide authentication (AH), encryption (ESP), and the secure exchange of encryption keys (IKE). The Authentication Header protocol (AH) confirms that the packet was sent by the sender, and not by someone else. IPsec also includes an integrity check to detect any tampering in transit. Packets are encrypted using 303

304 Part IV: Security the Encapsulating Security Payload (ESP). Encryption and decryption are performed using secret keys shared by the sender and the receiver. These keys are themselves transmitted using the Internet Key Exchange protocol, which provides a secure exchange. ESP encryption can degrade certain compression transmission methods like PPP for dialup Internet connections. To accommodate these compression methods, IPsec provides the IP Payload Compression Protocol (IPComp), with which packets can be compressed before being sent. The AH, ESP, and IPComp protocols are incorporated into the Linux kernel. The IKE protocol is implemented as a separate daemon. It simply provides a way to share secret keys, and can be replaced by other sharing methods. IPsec Modes You can use IPsec capabilities for either normal transport or for packet tunneling. With normal transport, packets are encrypted and sent to the next destination. The normal transport mode is used to implement direct host-to-host encryption, where each host handles the IPsec encryption process. Packet tunneling is used to encrypt transmissions between gateways, letting the gateways handle the IPsec encryption process for traffic directed to or from an entire network, rather than having to configure IPsec encryption for each host. With packet tunneling, the packets are encapsulated with new headers for a specific destination, enabling you to implement virtual private networks (VPNs). Packets are directed to VPN gateways, which encrypt and send on local network packets. NOTE You can choose to encrypt packets for certain hosts or for those passing through specific ports. IPsec Security Databases The packets you choose to encrypt are designated by the IPsec Security Policy Database (SPD). The method you use to encrypt them is determined by the IPsec Security Association Database (SAD). The SAD associates an encryption method and key with a particular connection or kind of connection. The connections to be encrypted are designated in the Security Policy Database. IPsec Tools Several IPsec tools are provided with which you can manage your IPsec connections (see Table 17-1). The libipsec tool lets you build a key library. With setkey, you can manage both the policy and association databases. The racoon tool configures the key exchange process to implement secure decryption key exchanges across connections. To see what your current security policies are in the SPD database, you can use setkey-dp. For security associations in SDP, you can use setkey-sp. NOTE To enable IPsec in the kernel, be sure to enable the PF_KEY, AH, and ESP options in Cryptographic Options.

Chapter 17: Internet Protocol Security: IPsec 305 Tools libipsec setkey racoon setkey-sp setkey-dp Description Build PFkey Manage policy (SPD) and association (SAD) databases Configure and implement secure key exchanges using IPsec Key Exchange (IKE) Examine security associations in SAD database Examine security policies in SDP database TABLE 17-1 IPsec Tools IPsec and IP Tables IPtables netfiltering will stop many IPsec packets. To enable IPtables to pass IPsec packets, use the following IPtables commands. The number for the AH protocol is 51, and for the ESP protocol, it is 50. To allow IPsec packets, you should set policy rules such as the following. iptables -A INPUT -p 50 -j ACCEPT iptables -A OUTPUT -p 51 -j ACCEPT Configuring IPsec with redhat-config-network The redhat-config-network tool now provides the support for implementing IPsec connections. On the redhat-config-networkwork tool, select the IPsec panel (see Figure 17-1) and click New to start the IPsec settings wizard for creating an IPsec connection. You are first asked to enter a nickname for the connection and to specify if you want it started automatically. You then choose the connection type. This can be either a direct host-to-host connection or a connection between two networks. A network connection implements a virtual private network (VPN) and runs IPsec in tunnel mode. (Both the host and VPN connections are FIGURE 17-1 IPsec on redhatconfig-network

306 Part IV: Security described in detail in the following sections.) You then select the kind of encryption you want to use. This can either be manual or use IKE, letting racoon automatically manage the encryption and authentication process. You then will configure both your local and remote connections, starting with the local settings. For a host-to-host connection, you need only enter the IP address for the remote host. For a VPN, you will have to enter corresponding addresses for the local and remote networks. For the local network, you will need to enter the IP addresses for the local network, the local network s gateway computer, and the local network s netmask. For the remote VPN connection, you will need the remote IP address, the remote network s address, its netmask, and its gateway address. Finally, you enter the authentication key. Click the Generate button to create one. A final screen will display your entries. Click Apply to save them. Your connection will appear in the IPsec panel, showing its type, destination, and nickname. To establish a connection, select the IPsec connection and click Activate. This will run the ifup-ipsec script in the /etc/sysconfig/network-scripts directory, which will execute IPsec tools such as setkey and racoon to establish your connection. Configuration data will be kept in the /etc/sysconfig/ networking/devices directory, using the name of the IPsec connections. For example, configuration information on the myipsec IPsec connection is kept in the ifcfg-myipsec file. Corresponding keys for each connection are kept in the keys files, including keys-myipsec. A sample configuration for a VPN is shown here. The IKE method is a private shared key (PSK). The destination (remote) gateway is 10.0.0.1, and the source (local) gateway is 192.168.0.1. The destination (remote) network address is 10.0.0.0/24, and the source (local) address is 192.168.0.0/24. The destination host is 10.0.0.2. ONBOOT=no IKE_METHOD=PSK DSTGW=10.0.0.1 SRCGW=192.168.0.1 DSTNET=10.0.0.0/24 SRCNET=192.168.0.0/24 DST=10.0.0.2 TYPE=IPSEC Configuring Connections with setkey To configure your IPsec connections, you can use the setkey tool. This tool contains several instructions for managing rules in the IPsec policy and security databases. You use the add instruction to add a security association to the security database (SAD), and the spdadd instruction to add a policy to the policy database (SPD). The ah term designates that the instruction is being applied to the authentication header (AH), and esp indicates the encryption to be implemented by the encryption security payload (ESP). To implement setkey operations, it is best to use a script invoking setkey with the -f option and listing the setkey instructions. The following example creates a simple script to add authentication and encryption instructions for a particular connection, as well as create a security policy for it: #!/sbin/setkey -f add 192.168.0.2 192.168.0.5 ah 15700 -A hmac-md5 "secret key";

Chapter 17: Internet Protocol Security: IPsec 307 add 192.168.0.2 192.168.0.5 esp 15701 -E 3des-cbc "secret key "; spdadd 192.168.0.2 192.168.0.5 any -P out ipsec esp/transport//require Security Associations: SA You use security associations to indicate that you want the authentication header (AH) and encryption payload (ESP) encrypted. A particular connection, such as that between two hosts, can have its authentication headers encrypted using specified encryption methods and designated secret keys. The same can be done for the encryption payload, the main content of transmissions. A secret key can be determined manually or automatically using key exchanges. The following example specifies that for the connection between 192.168.0.2 and 192.168.0.5, the hmac-md5 authentication method and a secret key (here designated by the placeholder secret key) will be used for the authentication header ah. add 192.168.0.2 192.168.0.5 ah 15700 -A hmac-md5 "secret key"; The security association for the encryption payload uses the 3des-cbc encryption method and a different secret key. add 192.168.0.2 192.168.0.5 esp 15701 -E 3des-cbc "secret key"; Each instruction is identified with a security parameter index (SPI), in this case, 15700 and 15701. In fact, identical instructions with different SPIs are considered different instructions. Bear in mind that the security associations only specify possible encryption procedures. They do not implement them. For that, you need to set security policies. Security Policy: SP A security policy will implement an IPsec security procedure for a connection. You can designate a host or port connection. Once a policy is set for a connection, the kernel will determine what security associations to apply, using the SAD database. A security policy is added with the spdadd instruction. Either encryption, authentication, or both can be required. The following example will encrypt and authenticate transmissions between hosts 192.168.0.2 and 192.168.0.5. Any outgoing transmissions between these hosts will be both encrypted and authenticated. spdadd 192.168.0.2 192.168.0.5 any -P out ipsec esp/transport//require ah/transport/require; In the spdadd instruction, you will need to specify the connection, such as one between two hosts or two networks. For two hosts, you would use their IP addresses, in this example, 192.168.0.2 and 192.168.0.5. You then specify the kind of packet and its direction, in this case any outgoing packet, any -P out. Then you can specify the ipsec directives for either the ESP or AH protocols, or both. For each entry, you specify the mode (transport or tunnel), the hosts involved (this can be different in tunnel mode), and the policy for the encryption, usually require. The following example shows that the ESP protocol will use the transport mode for connections between 192.168.02 and 192.168.0.5, and it will be required. esp/transport/192.168.02-192.168.0.5/require

308 Part IV: Security You can leave out the host information if it is the same, as in the prior example. esp/transport//require Receiving Hosts For a host to receive an encrypted IPsec transmission, it must have corresponding security association instructions in its own SAD database that tell it how to authenticate and decrypt the received instructions. The security association instructions would mirror those of the sender s instructions, using the same encryption method, secret keys, and security indexes. A corresponding policy, though, is not required. #!/sbin/setkey -f add 192.168.0.2 192.168.0.5 ah 15700 -A hmac-md5 "secret key"; add 192.168.0.2 192.168.0.5 esp 15701 -E 3des-cbc "secret key"; Receiving hosts may want to set up policies to screen incoming packets on secure connections, discarding those not encrypted. The following policy will accept only incoming encrypted and authenticated IPsec transmissions from 192.168.0.2. spdadd 192.168.0.2 192.168.0.5 any -P in ipsec esp/transport//require Two-way Transmissions The previous example set up a secure connection between two hosts going only one way, from 192.168.0.2 to 192.168.0.5, not the other way, from 192.168.0.5 to 192.168.0.2. To implement two-way secure transmissions between two hosts, both need to be configured as the sender and the receiver, with corresponding security associations to match. The following scripts are based on common examples of a simple two-way IPsec connection between two hosts. They set up a secure two-way IPsec connection between hosts 192.168.0.2 and 192.168.0.5. Corresponding incoming policies are also included, but not required. First is the configuration for host 192.168.0.2: #!/sbin/setkey -f add 192.168.0.2 192.168.0.5 ah 15700 -A hmac-md5 "secret key"; add 192.168.0.5 192.168.0.2 ah 24500 -A hmac-md5 "secret key"; add 192.168.0.2 192.168.0.5 esp 15701 -E 3des-cbc "secret key"; add 192.168.0.5 192.168.0.2 esp 24501 -E 3des-cbc "secret key"; spdadd 192.168.0.2 192.168.0.5 any -P out ipsec esp/transport//require spdadd 192.168.0.5 192.168.0.2 any -P in ipsec esp/transport//require The corresponding host, 192.168.0.5, uses the same instructions but with the IP connections reversed. Notice that the security indexes for instructions for the sender and receiver at each end correspond.

Chapter 17: Internet Protocol Security: IPsec 309 #!/sbin/setkey -f add 192.168.0.5 192.168.0.2 ah 15700 -A hmac-md5 "secret key"; add 192.168.0.2 192.168.0.5 ah 24500 -A hmac-md5 "secret key"; add 192.168.0.5 192.168.0.2 esp 15701 -E 3des-cbc "secret key"; add 192.168.0.2 192.168.0.5 esp 24501 -E 3des-cbc "secret key"; spdadd 192.168.0.5 192.168.0.2 any -P out ipsec esp/transport//require spdadd 192.168.0.2 192.168.0.5 any -P in ipsec esp/transport//require Configuring IPsec with racoon: IKE IPsec keys can be implemented as manual keys, as shared keys, or with certificates. Manual keys are explicitly exchanged and are prone to security problems. Both shared keys and certificates are managed using the IPsec Key Exchange protocol, which will automatically exchange keys, changing them randomly to avoid detection. One of the advantages of using IKE is that it will automatically generate any needed security associations if none are provided. This means that to configure secure connections with IKE, you would need to specify only a security policy, not the security associations. The racoon tool is the key exchange daemon for the IPsec IKE protocol. In the case of shared keys, hosts are authenticated dynamically by racoon using preshared secret keys. With the certificate method, hosts are authenticated using certificate files. The racoon configuration file is located at /etc/racoon/racoon.conf. Here you can set general parameters. You can use the default racoon.conf file for most connections. The racoon configuration consists of stanzas containing parameters for possible connections. A very simple configuration is shown in the following example, which uses a simple shared secret key. The location is specified by the path pre_shared_key option, in this case /etc/ racoon/psk.txt. Certificate keys, a more secure method using public and private keys, are discussed later. path pre_shared_key "/etc/racoon/psk.txt"; remote anonymous { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; my_identifier address; lifetime time 2 min; initial_contact on; proposal_check obey; # sec,min,hour # obey, strict or claim proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key;

310 Part IV: Security dh_group 2 ; } } sainfo anonymous { pfs_group 1; lifetime time 2 min; encryption_algorithm 3des, blowfish, des, cast128, rijndael ; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate ; } This configuration defines stanzas for default (anonymous) connections. The remote anonymous stanza defines parameters for connecting to remote systems, and the sainfo anonymous section provides information for security association instructions, such as the encryption and authentication methods to use. Certificates To use certificates instead of shared keys, you first have to create certificates using OpenSSL. Then instruct racoon to use them. Specify the path for the certificates. path certificate "/usr/local/etc/racoon/certs"; You can now configure racoon to use the public and private keys generated by the certificates. In the appropriate stanza in the /etc/racoon/racoon.conf file, the certificate_ type directive specifies the public and private keys for this system. The peers_certfile directive specifies the location of the remote system s public key. The authentication_ method directive is now set to rsasig, the RSA public/private keys. Make sure each system has its corresponding public and private keys. certificate_type x509 "192.168.0.2.public" "192.168.0.2.private"; peers_certfile "192.168.0.5.public"; authentication_method rsasig; Connection Configuration with racoon With racoon, you will only need to specify the security policy for the connection configuration, as shown here for the sender. The receiver will have corresponding policies: spdadd 192.168.0.5 192.168.0.2 any -P out ipsec esp/transport//require spdadd 192.168.0.2 192.168.0.5 any -P in ipsec esp/transport//require IPsec Tunnel Mode: Virtual Private Networks Instead of encrypting two hosts directly, you could use IPsec to just encrypt the gateways between the networks those hosts belong to, assuming that communication within those

Chapter 17: Internet Protocol Security: IPsec 311 networks can be trusted. This would significantly reduce the encryption configuration setup, letting hosts from an entire network reach those of another network, using an intermediate secure IPsec connection between their gateways. For connections between gateways, transmissions sent through intervening routers can be tunneled. This is known as the tunnel mode for IPsec, which is used to implement virtual private networks (VPNs). Encrypted transmissions between gateways effectively implements a VPN, securing transmissions across a larger network from one local net to another. To tunnel transmissions from a host through a gateway to a network, you would use the -m tunnel option. The IPsec connection would be between the two gateways. The following example is the security association on gateway 10.0.0.1 that encrypts transmissions from gateway 10.0.0.1 to gateway 10.0.23.5. The examples used here are for a gateway-to-gateway connection, set up as a direct connection between two hosts using manual keys. add 10.0.0.1 10.0.23.5 esp 34501 -m tunnel -E 3des-cbc "secretkey"; The security policy on 10.0.0.1 then implements encryption for communication from one network to another using their respective gateways. The two networks are 192.168.0.0 and 192.168.1.0. Transmissions from hosts on the 192.168.0.0 network are encrypted by their gateway, 10.0.0.1, and are then sent to the gateway for the 192.168.1.0 network, 10.0.23.5, which then decrypts them. spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/10.0.0.1-10.0.23.5/require; Notice that the gateway IP addresses are specified in the spdadd instruction s ipsec directive. The mode specified is the tunnel mode, rather than the transport mode. ipsec esp/tunnel/10.0.0.1-10.0.23.5/require The receiving gateway, 10.0.23.5, will have a corresponding security association and policy, as shown here. The policy is set for incoming transmissions. In both gateway configurations, other than specifying the tunnel option and using network addresses in the security policy, the security associations and policies are the same as those used for host-to-host connections. add 10.0.0.1 10.0.23.5 esp 34501 -m tunnel -E 3des-cbc "secretkey"; spdadd 192.168.0.0/24 192.168.1.0/16 any -P in ipsec esp/tunnel/10.0.0.1-10.0.23.5/require; To set up full two-way communication, the two gateways would have corresponding security associations and policies to handle traffic in both directions. The following example is for the configuration on gateway 10.0.0.1 and handles two-way traffic to and from gateway 10.0.23.5. Gateway 10.0.23.5 would have a similar configuration: add 10.0.0.1 10.0.23.5 esp 34501 -m tunnel -E 3des-cbc "secretkey"; add 10.0.23.5 10.0.03.1 esp 34501 -m tunnel -E 3des-cbc "secretkey";

312 Part IV: Security spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec esp/tunnel/10.0.0.1-10.0.23.5/require; spdadd 192.168.1.0/16 192.168.0.0/24 any -P in ipsec esp/tunnel/10.0.23.5-10.0.0.1/require; If you use racoon to configure gateway connections, you would only have to set the security policies on each gateway, letting the racoon server generate the needed security associations. Crypto IP Encapsulation for Virtual Private Networks Red Hat currently still supports the use of Crypto IP Encapsulation (CIPE), an alternative to IPsec for implementing Virtual Private Networks. You use the Internet Configuration Wizard to create a CIPE VPN connection, selecting the CIPE entry. The Configure Tunnel screen will then display entries for configuring your connection. For an initial connection, the first CIPE device, cipcb0, will be selected. You can then select your tunnel through device, a network device like an Ethernet connection. If you select server mode, then any device can be used for the CIPE connection. For the port, 7777 is the default, although you can select a particular port if you wish. You can then select the virtual local and remote addresses and generate a secret key. Essentially, CIPE sets up a peer-to-peer encrypted connection between two computers. Both need to be running CIPE. One will operate as the server, usually the first to be configured, and the second as a client. The server will generate a secret key used for encryption, which will be transmitted to the client. The client, when it connects, will provide a remote peer address and port. The server will designate the Remote Peer Address entry as Server mode, letting the address and the Peer port to be automatically determined when the client connects. The port used by both systems is usually 7777. Transmissions are sent as encrypted UCP packets. Be sure also that you have opened your firewall to allow transmissions on the designated VPN port, 7777. Each computer will have its own local IP address by which it will be identified. These can be any of the private IP addresses reserved for local addresses, normally starting at 192.168, for example, 192.168.10.1 and 192.168.10.2 (see Chapter 38). If you are already operating on a local network using these addresses, make sure you are not using a duplicate of one already in use. For that reason you could designate them as a separate sub-network, as used in this example, using 10 for the subnet, instead of 0, 192.168.10.1. The private IP addresses you want to use for your VPN are to be entered in the Remote and Local Virtual Address entries, local for the your computer and remote for the other computer. In a window below the entries, the corresponding entries for the client computer are listed. These are usually the reverse of your own entries. Actual configuration information will be placed in the /etc/sysconfig/network-scripts directory, in the device file for the CIPE connection, like ifcfg-cipcb0. The actual remote IP address and port of the remote computer will be listed in the PEER entry, and its VPN address in the PTRADDR entry. The remote computer will have its own ifcfg-cipcb0 file listing your computer s actual IP address in its PEER entry, and your VPM address in the PTRADDR entry.