Managing the Security Policy Database using setkey
As we mentioned in the Introduction to IPsec the kernel maintains two databases, the Security Policy Database (SPD) and the Security Association Database (SAD). In this section we shall explore the basic use of the setkey application to query and modify the Security Policy Database (SPD).
Querying the IPsec SPD
The Security Policy Database (SPD), as you would expect, is used to store information relating to the security policies which have been configured. These security policies describe which packets should have IPsec applied to them as well as how IPsec should be applied. You can display the currently configured security policies using the setkey application as shown in the example below.
10.1.0.0/16[any] 10.0.0.0/16[any] 255 fwd prio def ipsec esp/tunnel/62.149.40.78-83.56.124.167/require created: Jan 12 20:02:01 2012 lastused: Jan 23 17:35:35 2012 lifetime: 0(s) validtime: 0(s) spid=74 seq=5 pid=5276 refcnt=3 10.1.0.0/16[any] 10.0.0.0/16[any] 255 in prio def ipsec esp/tunnel/62.149.40.78-83.56.124.167/require created: Jan 12 20:02:01 2012 lastused: Jan 23 17:35:35 2012 lifetime: 0(s) validtime: 0(s) spid=64 seq=6 pid=5276 refcnt=1 10.0.0.0/16[any] 10.1.0.0/16[any] 255 out prio def ipsec esp/tunnel/83.56.124.167-62.149.40.78/require created: Jan 12 20:02:01 2012 lastused: Jan 23 17:35:35 2012 lifetime: 0(s) validtime: 0(s) spid=57 seq=0 pid=5276 refcnt=3
The above three policies describe a Virtual Private Network (VPN) created using the IPsec Encapsulating Security Payload protocol in tunnel mode between the local network (using the 10.0.0.0/16 address range) and a remote network (using the 10.1.0.0/16 address range). We shall examine how to create such a Virtual Private Network (VPN) later in the Building a tunnelled VPN using ESP (static IPs, no NAT), Building a tunnelled VPN using ESP (static IPs, through NAT) and Building a tunnelled VPN using ESP (one dynamic IP) sections.
Declaring Security Policies
The net-firewall/ipsec-tools package provides an init script designed to control the racoon daemon (which provides Internet Key Exchange (IKE) services and will be discussed in later sections). This init script also loads any Security Policies by processing a configuration file (located at /etc/ipsec-tools.conf) using the setkey application.
The example configuration shown below will simply flush both the Security Policy Database (SPD) and the Security Association Database (SAD) and thus makes a sensible starting point when creating a new IPsec configuration from scratch.
#! /usr/sbin/setkey -f
# Flush the SPD and SAD
spdflush;
flush;
To avoid having to restart the racoon every time you wish to reload the security policies it is possible to mark the configuration file as executable. It may then be run just like any other script.
lisa ~ # /etc/ipsec-tools.conf
So far our setkey configuration file does not achieve much. To actually create a new security policy we need to use the spdadd command, the basic syntax is shown below.
spdadd [-46n] src_range dst_range upperspec label policy ;
The table below describes the first four parameters of the spdadd command.
| Description of basic parameters of the spdadd command | |
|---|---|
| src_range dst_range | These two parameters control the selection of packets to which this policy should apply based on network address. As you may expect the first specifies a source address range and the second specifies the destination address range. Both may be specified as either a single address or an address followed by a prefix length. To apply the policy only to a certain service a port number may also be supplied enclosed in square brackets. |
| 10.0.0.0/8 | |
| upperspec | This parameter controls the selection of packets to which this policy should apply based on the upper level protocol. Any of the entries defined in /etc/protocols may be used although only TCP, UDP, GRE and ICMP are guaranteed to be suitable for use with IPsec. The special name any may be used to indicate that this policy should apply to any protocol. |
| any | |
| label | The label parameter allow an access control label to be associated with the policy allowing Mandatory Access Controls (MAC) to be applied to network connections by an appropriate Linux Security Module (LSM) such as SELinux. Any Security Association (SA) negotiated with this policy will also contain the label. |
After these four parameters comes the policy description, the syntax is shown below.
-P direction [priority] action [rule]
The table below describes the basic policy parameters of the spdadd command.
| Description of basic policy parameters of the spdadd command | |
|---|---|
| direction | This parameter specifies the direction that a packet must be travelling in in order to be matched by this policy. Possible values are in for packets arriving at a network interface, our for packets leaving a network interface and fwd for packets being forwarded between two network interfaces. |
| out | |
| priority | This parameter allows for a priority to be specified. Policies are ordered internally using this value. Assuming that you always create the policies in the order you desire them to be evaluated this parameter may be ignored. |
| action | The action parameter specifies what action should be taken on packets which match the policy. A value of discard causes the packet to be discarded, a value of none causes the packet to pass unmodified and a value of ipsec will cause the following IPsec transformation rules to be applied. |
| ipsec | |
Whenever an action of ipsec is specified one or more IPsec transformation rules must be specified. The syntax for such a rule is provided below.
protocol/mode/src-dst/level [...]
protocol/mode//level [...]
The table below describes the rule parameters of the spdadd command.
| Description of rule parameters of the spdadd command | |
|---|---|
| protocol | This parameter specifies the type of IPsec transformation to apply. A value of ah indicates that an Authentication Header (AH) should be added to the packet, a value of esp indicates that the packet should be encrypted using the Encapsulating Security Payload (ESP) protocol and a value of ipcomp indicates that IP compression should be performed. |
| esp | |
| mode | The mode parameter may have a value of either transport or tunnel. If the mode parameter is set to tunnel then a src-dst pair must be specified (see below). When using transport the src-dst pair may be omitted. |
| tunnel | |
| src-dst | When a value of tunnel is given for the mode parameter this parameter provides the source and destination address of said tunnel. When a vale of transport is provided for the mode parameter these addresses may be omitted. |
| 83.56.124.167-62.149.40.78 | |
| level | This parameter specifies the level at which the kernel should ensure security. A value of default indicates that the kernel's internal system wide default should be used. A value of use indicates that the kernel should use an appropriate SA whenever one is available. A value of require indicates that a suitable SA must be used when transmitting or receiving a packet matching this policy. Finally, a value of unique provides the same level as require additionally allowing the policy to match the unique out-bound SA. |
| require | |
Example Security Policies
Given the complexity of the spdadd syntax a complete example is provided below so that you can see the relevant parts used in context.
IPsec Virtual Private Network (VPN)
#! /usr/sbin/setkey -f
# Flush the SPD and SAD
spdflush;
flush;
# Security Policies
spdadd 10.0.0.0/16 10.1.0.0/16 any
-P out ipsec
esp/tunnel/83.56.124.167-62.149.40.78/require;
spdadd 10.1.0.0/16 10.0.0.0/16 any
-P in ipsec
esp/tunnel/62.149.40.78-83.56.124.167/require;
IPsec Secure Subnet
#! /usr/sbin/setkey -f
# Flush the SPD and SAD
spdflush;
flush;
# Security Policies
spdadd 10.0.0.0/16 10.0.0.0/16 any
-P out ipsec
esp/transport//require;
spdadd 10.0.0.0/16 10.0.0.0/16 any
-P in ipsec
esp/transport//require;