To configure IP Sec, tunnels and filters must be configured. When a simple tunnel is defined for all traffic to use, the filter rules can be automatically generated. If more complex filtering is desired, filter rules can be configured separately.
You can configure IP Sec using the Web-based System Manager application Network or the System Management Interface Tool (SMIT). If using SMIT, the following fastpaths will take you directly to the configuration panels you need:
This section on IP Security Configuration discusses the following topics:
There are two related but distinct parts of IP Security: tunnels and filters. Tunnels require filters, but filters do not require tunnels.
Filtering is a basic function in which incoming and outgoing packets can be accepted or denied based on a variety of characteristics. This allows a system administrator to configure the host to control the traffic between this host and other hosts. Filtering is done on a variety of packet properties, such as source and destination addresses, IP Version (4 or 6), subnet masks, protocol, port, routing characteristics, fragmentation, interface, and tunnel definition. This filtering is done at the IP layer, so no changes are required to the applications.
Tunnels define a security association between two hosts. These security associations involve specific security parameters that are shared between end points of the tunnel.
The following illustration indicates how a packet comes in the network adapter to the IP stack. From there, the filter module is called to determine if the packet should be permitted or denied. If a tunnel ID is specified, the packet will be checked against the existing tunnel definitions. If the decapsulation from the tunnel is successful, the packet will be passed to the upper layer protocol. This function will occur in reverse order for outgoing packets. The tunnel relies on a filter rule to associate the packet with a particular tunnel, but the filtering function can occur without passing the packet to the tunnel.
Tunnels are used whenever it is desired to have data authenticated, or authenticated and encrypted. Tunnels are defined by specifying a security association between two hosts (see figure). The security association defines the parameters for the encryption and authentication algorithms and characteristics of the tunnel.
The Security Parameter Index (SPI) and the destination address identify a unique security association. Therefore, these two parameters are required for uniquely specifying a tunnel. Other parameters such as cryptographic algorithm, authentication algorithm, keys, and lifetime can be specified or defaults can be used.
The decision to use IBM tunnels, manual tunnels, or, for AIX versions 4.3.2 and later, IKE tunnels, depends on the tunnel support of the remote end and the type of key management desired. IKE tunnels are preferable (when available) because they offer secure key negotiation and key refreshment in an industry-standard way. They also take advantage of the new IETF ESP and AH header types and support anti-replay protection.
IBM tunnels offer similar security, but their support is limited to a smaller set of encryption and authentication algorithms, but they provide backward compatibility and ease of use with their import/export functions with the IBM Firewall.
If the remote end does not support IBM tunnels, or uses one of the algorithms requiring manual tunnels, manual tunnels should be used. Manual tunnels ensure interoperability with a large number of hosts. Because the keys are static and difficult to change and may be cumbersome to update, they are not as secure.
IBM Tunnels may be used between any two AIX machines running AIX Version 4.3, or between an AIX 4.3 host and a host running IBM Secure Network Gateway 2.2 or IBM Firewall 3.1/3.2. Manual tunnels may be used between a host running AIX Version 4.3 and any other machine running IP Security and having a common set of cryptographic and authentication algorithms. Almost all vendors offer Keyed MD5 with DES, or HMAC MD5 with DES. This is a base subset that works with almost all implementations of IP Security.
When setting up manual or IBM tunnels, the procedure depends on whether you are setting up the first host of the tunnel or setting up the second host, which must have parameters matching the first host's setup. When setting up the first host, the keys may be autogenerated, and the algorithms can be defaulted. When setting up the second host, it is best to import the tunnel information from the remote end, if possible.
Another important consideration is determining whether the remote system is behind a firewall. If it is, the setup must include information about the intervening firewall.
For the simplest case, setting up a manual tunnel, it is not necessary to separately configure the filter rules. As long as all traffic between two hosts goes through the tunnel, the necessary filter rules are automatically generated. The process of setting up a tunnel is to define the tunnel on one end, import the definition on the other end, and activate the tunnel and filter rules on both ends. Then the tunnel is ready to use.
Information about the tunnel must be made to match on both sides if it is not explicitly supplied (see figure). For instance, the encryption and authentication algorithms specified for the source will be used for the destination if the destination values are not specified. This makes creating the tunnel much simpler.
You can configure a tunnel using the Web-based System Manager application Network, the SMIT fast path ips4_basic (for IP Version 4) or ips6_basic (for IP version 6), or you can use the following procedure.
The following is a sample of the gentun command used to create a manual tunnel:
gentun -v 4 -t manual -s 5.5.5.19 -d 5.5.5.8 -a HMAC_MD5 -e DES_CBC_8 -N 23567
This will create a tunnel with output (using lstun -v 4) that looks similar to:
Tunnel ID : 1 IP Version : IP Version 4 Source : 5.5.5.19 Destination : 5.5.5.8 Policy : auth/encr Tunnel Mode : Tunnel Send AH Algo : HMAC_MD5 Send ESP Algo : DES_CBC_8 Receive AH Algo : HMAC_MD5 Receive ESP Algo : DES_CBC_8 Source AH SPI : 300 Source ESP SPI : 300 Dest AH SPI : 23576 Dest ESP SPI : 23576 Tunnel Life Time : 480 Status : Inactive Target : - Target Mask : - Replay : No New Header : Yes Snd ENC-MAC Algo : - Rcv ENC-MAC Algo : -
The tunnel will be activated when the mktun command is used:
mktun -v 4 -t1
The filter rules associated with the tunnel are automatically generated and output (using lsfilt -v 4) looks similar to:
Rule 4: Rule action : permit Source Address : 5.5.5.19 Source Mask : 255.255.255.255 Destination Address : 5.5.5.8 Destination Mask : 255.255.255.255 Source Routing : yes Protocol : all Source Port : any 0 Destination Port : any 0 Scope : both Direction : outbound Logging control : no Fragment control : all packets Tunnel ID number : 1 Interface : all Auto-Generated : yes Rule 5: Rule action : permit Source Address : 5.5.5.8 Source Mask : 255.255.255.255 Destination Address : 5.5.5.19 Destination Mask : 255.255.255.255 Source Routing : yes Protocol : all Source Port : any 0 Destination Port : any 0 Scope : both Direction : inbound Logging control : no Fragment control : all packets Tunnel ID number : 1 Interface : all Auto-Generated : yes
These filter rules in addition to the default filter rules are activated by the mktun -v 4 -t 1 command.
To set up the other side (when it is another AIX machine), the tunnel definition can be exported on host A then imported to host B.
exptun -v 4 -t 1 -f /tmp
This will export the tunnel definition into a file named ipsec_tun_manu.exp and any associated filter rules to the file ipsec_fltr_rule.exp in the directory indicated by the -f flag.
To create the matching end of the tunnel, the export files are copied to the remote side and imported into that remote AIX 4.3 machine by using the command:
imptun -v 4 -t 1 -f /tmp
where 1 is the tunnel to be imported and /tmp is the directory where the import files reside. This tunnel number is system generated and must be referenced from the output of the gentun command, or by using the lstun command to list the tunnels and determine the correct tunnel number to import. If there is only one tunnel in the import file, or if all the tunnels are to be imported, then the -t option is not needed.
If the remote machine is not AIX 4.3, the export file can be used as a reference for setting up the algorithm, keys, and SPI values for the other end of the tunnel.
Export files from the IBM Secure Network Gateway (SNG) can be imported to create tunnels in AIX 4.3. To do this, use the -n option when importing the file:
imptun -v 4 -f /tmp -n
Setting up an IBM tunnel is similar to a manual tunnel, but some of the choices are different for the crypto algorithms and the keys are negotiated dynamically, so there is no need to import keys. IBM tunnels are limited to Keyed MD5 for authentication. If the HMAC MD5 or HMAC SHA algorithms are desired, a manual tunnel must be used.
gentun -s 9.3.100.1 -d 9.3.100.245 -t IBM -e DES_CBC_8 -n 35564
As with manual tunnels, from this point the tunnel and filter table must be activated to make the tunnel active:
mktun -v 4 -t1
To set up the other side, if the other host is an AIX 4.3 IP Security machine, the tunnel definition can be exported on host A, then imported to host B.
exptun -v 4 -f /tmp
This will export the tunnel definition into a file named ipsec_tun_ibm.exp and any associated filter rules to the file ipsec_fltr_rule.exp in the directory indicated by the -f flag.
The procedure is the same for creating the second end of the tunnel on host B for an IBM tunnel. The tunnel definition is exported from host A and imported onto host B. The -n flag can be used for a file exported by an IBM Secure Network Gateway or an IBM Firewall 3.1/3.2.
Filtering can be set up to be simple, using mostly autogenerated filter rules, or can be complex by defining very specific filter functions based on the properties of the IP packets. Matches on incoming packets are done by comparing the source address and SPI value to those listed in the filter table. Therefore, this pair must be unique.
Each line in the filter table is known as a rule. A collection of rules will determine what packets are accepted in and out of the machine, and how they will be directed. Filter rules can be written based on source and destination addresses and masks, protocol, port number, direction, fragment control, source routing, tunnel, and interface.
Below is a sample set of filter rules. Within each rule, fields are shown in the following order (an example of each field from rule 1 is shown in parentheses): Rule_number (1), Action (permit), Source_addr (0.0.0.0), Source_mask (0.0.0.0), Dest_addr (0.0.0.0), Dest_mask (0.0.0.0), Source_routing (no), Protocol (udp), Src_prt_operator (eq), Src_prt_value (4001), Dst_prt_operator (eq), Dst_prt_value (4001), Scope (both), Direction (both), Logging (no), Fragment (all packets), Tunnel (0), and Interface (all).
1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no udp eq 4001 eq 4001 both both no all packets 0 all 2 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no ah any 0 any 0 both both no all packets 0 all 3 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no esp any 0 any 0 both both no all packets 0 all 4 permit 10.0.0.1 255.255.255.255 10.0.0.2 255.255.255.255 no all any 0 any 0 both outbound no all packets 1 all 5 permit 10.0.0.2 255.255.255.255 10.0.0.1 255.255.255.255 no all any 0 any 0 both inbound no all packets 1 all 6 permit 10.0.0.1 255.255.255.255 10.0.0.3 255.255.255.255 no tcp lt 1024 eq 514 local outbound yes all packets 2 all 7 permit 10.0.0.3 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack eq 514 lt 1024 local inbound yes all packets 2 all 8 permit 10.0.0.1 255.255.255.255 10.0.0.3 255.255.255.255 no tcp/ack lt 1024 lt 1024 local outbound yes all packets 2 all 9 permit 10.0.0.3 255.255.255.255 10.0.0.1 255.255.255.255 no tcp lt 1024 lt 1024 local inbound yes all packets 2 all 10 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 0 any 0 local outbound yes all packets 3 all 11 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 0 any 0 local inbound yes all packets 3 all 12 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp gt 1023 eq 21 local outbound yes all packets 4 all 13 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack eq 21 gt 1023 local inbound yes all packets 4 all 14 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp eq 20 gt 1023 local inbound yes all packets 4 all 15 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp/ack gt 1023 eq 20 local outbound yes all packets 4 all 16 permit 10.0.0.1 255.255.255.255 10.0.0.5 255.255.255.255 no tcp gt 1023 gt 1023 local outbound yes all packets 4 all 17 permit 10.0.0.5 255.255.255.255 10.0.0.1 255.255.255.255 no tcp/ack gt 1023 gt 1023 local inbound yes all packets 4 all 18 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 no all any 0 any 0 both both yes all packets
Rule 1 is for the IBM Session Key daemon and will only appear in IP Version 4 filter tables. It uses port number 4001 to control packets for refreshing the session key. It is an example of how the port number can be used for a specific purpose. This filter rule should not be modified except for logging purposes.
Rules 2 and 3 are used to allow processing of Authentication Headers (AH) and Encapsulating Security Payload (ESP) headers. They should not be modified except for logging purposes.
Rules 4 and 5 are a set of autogenerated rules that filter traffic between addresses 10.0.0.1 and 10.0.0.2 through tunnel #1. Rule 4 is for outbound traffic and rule 5 is for inbound traffic.
Rules 6 through 9 are a set of user-defined rules that filter outbound rsh, rcp, rdump, rrestore, and rdist services between addresses 10.0.0.1 and 10.0.0.3 through tunnel #2. Note that logging is set to yes so the administrator can monitor this type of traffic.
Rules 10 and 11 are a set of user-defined rules that filter both inbound and outbound icmp services of any type between addresses 10.0.0.1 and 10.0.0.4 through tunnel #3.
Rules 12 through 17 are user-defined filter rules that filter outbound FTP service from 10.0.0.1 and 10.0.0.5 through tunnel #4.
Rule 18 is an autogenerated rule always placed at the end of the table. In this case, it permits all packets that do not match the other filter rules. It may be set to deny all traffic not matching the other filter rules.
Each rule may be viewed separately (using lsfilt) to make each field clear. For example:
Rule 1: Rule action : permit Source Address : 0.0.0.0 Source Mask : 0.0.0.0 Destination Address : 0.0.0.0 Destination Mask : 0.0.0.0 Source Routing : yes Protocol : udp Source Port : eq 4001 Destination Port : eq 4001 Scope : both Direction : both Logging control : no Fragment control : all packets Tunnel ID number : 0 Interface : all Auto-Generated : yes
Below are listed all the parameters that can be specified in a filter rule:
See the AIX Version 4.3 Commands Reference for genfilt and chfilt for more information.
Certain rules are autogenerated for the use of the IP Security filter and tunnel code. These include the rules shown above for the session key daemon to refresh the keys in IKE (AIX versions 4.3.2 and later) or IBM tunnels (both IP version 4 only) and the rules for the processing of AH and ESP packets. Filter rules will also be autogenerated when defining tunnels. For manual and IBM tunnels, they will specify the source and destination address and mask values, as well as the tunnel ID. All traffic between those addresses will flow through the tunnel.
IKE filter rules are also autogenerated and will be kept in a separate table. The IKE negotiation has support to specify protocol and port numbers, they will be set accordingly in the filter rules. The IKE filter rules will be searched after the static filter rules and before the autogenerated rules. The position in the static filter table where IKE filter rules will be inserted will be defaulted, but they can be moved by the user.
Since the autogenerated rules permit all traffic over the tunnel, user defined rules may be necessary to place restrictions on certain types of traffic. These user defined rules should be placed before the autogenerated rules because the first rule that applies to the packet will be used. Below is an example of user defined filter rules that filter traffic based on ICMP operation.
1 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 8 any 0 local outbound no all packets 3 all 2 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 0 any 0 local inbound no all packets 3 all 3 permit 10.0.0.4 255.255.255.255 10.0.0.1 255.255.255.255 no icmp any 8 any 0 local inbound no all packets 3 all 4 permit 10.0.0.1 255.255.255.255 10.0.0.4 255.255.255.255 no icmp any 0 any 0 local outbound no all packets 3 all
Filter rules will be autogenerated when tunnels are defined. This is done to simplify the configuration of a single tunnel. This function can be suppressed by specifying the -g flag in gentun. You can find a sample filter file with genfilt commands to generate filter rules for different TCP/IP services in /usr/samples/ipsec/filter.sample.
