IP Security Predefined Filter Rules

AIX Version 4.3 System Management Guide: Communications and Networks

IP Security Predefined Filter Rules

There are several predefined filter rules that are auto-generated with certain events. When the IP Security device is loaded, a predefined rule will be inserted into the filter table and then be activated. By default, this predefined rule is a Permit All rule. This will keep you from getting shut out if you are configuring remotely. There is a predefined rule for both IP Version 4 and IP Version 6 filters. Either may be changed to Deny All. This will keep traffic from passing unless that traffic is specifically defined by additional filter rules. The only other option to change on the predefined rules is chfilt with the -l option, which allows packets matching that rule to be logged.

Host-Firewall-Host

The host-firewall-host configuration option for tunnels (see figure) allows you to create a tunnel between your host and a firewall, then automatically generate the necessary filter rules for correct communication between your host and a host behind the firewall. The auto-generated filter rules permit all rules between the two non-firewall hosts over the tunnel specified. The default rules--for user datagram protocol (UDP), Authentication Headers (AH), and Encapsulating Security Paylooad (ESP) headers--should already handle the host to firewall communication. The firewall will have to be configured appropriately to complete the setup. You should use the export file from the tunnel you created to enter the SPI values and keys that the firewall needs.

Logging Facilities

This section describes the configuration and format of system logs relating to IP Security. As hosts communicate with each other, the transferred packets may be logged to the system log daemon, syslogd. Other important messages about IP Security will appear as well. An administrator may choose to monitor this logging information for traffic analysis and debugging assistance. The following are the steps for setting up the logging facilities.

Edit the /etc/syslog.conf file to add the following entry:
```
local4.debug /var/adm/ipsec.log
```
Use the local4 facility to record traffic and IP Security events. Standard AIX priority levels apply. We recommend setting the priority level of debug until traffic through IP Security tunnels and filters show stability and proper movement.

Note: The logging of filter events can create significant activity at the IP Security host and can consume large amounts of storage.
Save /etc/syslog.conf.
Go to the directory you specified for the log file and create an empty file with the same name. In the case above, you would change to /var/adm directory and issue the command:
```
touch ipsec.log
```
Issue a refresh command to the syslogd subsystem:
```
refresh -s syslogd
```
While creating filter rules for your host, if you would like packets matching a specific rule to be logged, set the -l parameter for the rule to Y (yes) using the genfilt or the chfilt commands.
Finally, turn on packet logging and start the ipsec_logd daemon using the following command:
```
mkfilt -g start
```
You can stop packet logging by issuing the following command:
```
mkfilt -g stop
```

Below is a sample log file containing traffic entries and other IP Security log entries:

1. Aug 27 08:08:40 host1 : Filter logging daemon ipsec_logd (level 2.20) initialized at 08:08:40 on 08/27/97A
2. Aug 27 08:08:46 host1 : mkfilt: Status of packet logging set to Start at 08:08:46 on 08/27/97
3. Aug 27 08:08:47 host1 : mktun: IBM tunnel 1, 9.3.97.244, 9.3.97.130 activated.
4. Aug 27 08:08:47 host1 skeyd: Inserted new context for tunnel ID 1 local SPI: 1336 remote SPI: 1336 .
5. Aug 27 08:08:47 host1 : mkfilt: #:1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq  4001 eq  4001  both both l=n f=y t=0 e= a=
6. Aug 27 08:08:47 host1 : mkfilt: #:2 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ah any 0 any 0  both both l=n f=y t=0 e= a=
7. Aug 27 08:08:47 host1 : mkfilt: #:3 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 esp any 0 any 0  both both l=n f=y t=0 e= a=
8. Aug 27 08:08:47 host1 : mkfilt: #:4 permit 10.0.0.1 255.255.255.255 10.0.0.2 255.255.255.255 icmp any 0 any 0  local outbound l=y f=y t=1 e= a=
9. Aug 27 08:08:47 host1 : mkfilt: #:4 permit 10.0.0.2 255.255.255.255 10.0.0.1 255.255.255.255 icmp any 0 any 0  local inbound l=y f=y t=1 e= a=
10. Aug 27 08:08:47 host1 : mkfilt: #:6 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0  both both l=y f=y t=0 e= a=
11. Aug 27 08:08:47 host1 : mkfilt: Filter support (level 1.00) initialized at 08:08:47 on 08/27/97
12. Aug 27 08:08:48 host1 : #:6 R:p  o:10.0.0.1 s:10.0.0.1 d:10.0.0.20 p:udp sp:3327 dp:53 r:l a:n f:n T:0 e:n l:67
13. Aug 27 08:08:48 host1 : #:6 R:p  i:10.0.0.1 s:10.0.0.20 d:10.0.0.1 p:udp sp:53 dp:3327 r:l a:n f:n T:0 e:n l:133
14. Aug 27 08:08:48 host1 : #:6 R:p  i:10.0.0.1 s:10.0.0.15 d:10.0.0.1 p:tcp sp:4649 dp:23 r:l a:n f:n T:0 e:n l:43
15. Aug 27 08:08:48 host1 : #:6 R:p  o:10.0.0.1 s:10.0.0.1 d:10.0.0.15 p:tcp sp:23 dp:4649 r:l a:n f:n T:0 e:n l:41
16. Aug 27 08:08:48 host1 : #:6 R:p  i:10.0.0.1 s:10.0.0.15 d:10.0.0.1 p:tcp sp:4649 dp:23 r:l a:n f:n T:0 e:n l:40
17. Aug 27 08:08:51 host1 : #:4 R:p  o:10.0.0.1 s:10.0.0.1 d:10.0.0.2 p:icmp t:8 c:0 r:l a:n f:n T:1 e:n l:84
18. Aug 27 08:08:51 host1 : #:5 R:p  i:10.0.0.1 s:10.0.0.2 d:10.0.0.1 p:icmp t:0 c:0 r:l a:n f:n T:1 e:n l:84
19. Aug 27 08:08:52 host1 : #:4 R:p  o:10.0.0.1 s:10.0.0.1 d:10.0.0.2 p:icmp t:8 c:0 r:l a:n f:n T:1 e:n l:84
20. Aug 27 08:08:52 host1 : #:5 R:p  i:10.0.0.1 s:10.0.0.2 d:10.0.0.1 p:icmp t:0 c:0 r:l a:n f:n T:1 e:n l:84
21. Aug 27 08:32:27 host1 : Filter logging daemon terminating at 08:32:27 on 08/27/97l

Here is the explanation:

1. Filter logging daemon activated.

2. Filter packet logging set to on with mkfilt -g start.

3. IBM tunnel activation, showing tunnel ID, source address, destination address, and time stamp.

4. The skeyd daemon inserted the tunnel context, meaning that the IBM tunnel is ready for traffic.

5-10. Filters have been activated. Logging shows all loaded filter rules.

11. Message showing activation of filters.

12-13. These entries show a DNS lookup for a host.

14-16. These entries show a partial Telnet connection (the others have been removed from this example for space reasons).

17-20. These entries show two pings.

21. Filter logging daemon shutting down.

Labels in Field Entries

The fields in the log entries are abbreviated to reduce DASD space requirements:

#	The rule number that caused this packet to be logged.
R	Rule Type. p Permit. d Deny.
i/o	Direction the packet was traveling when it was intercepted by the filter support code. Identifies IP address of the adapter associated with the packet: For inbound (i) packets, this is the adapter that the packet arrived on. For outbound (o) packets, this is the adapter that the IP layer has determined should handle the transmission of the packet.
s	Specifies the IP address of the sender of the packet (extracted from the IP header).
d	Specifies the IP address of the intended recipient of the packet (extracted from the IP header).
p	Specifies the high-level protocol that was used to create the message in the data portion of the packet. May be a number or name, for example: `udp` , `icmp` , `tcp` , `tcp/ack` , `ospf` , `pip` , `esp` , `ah` , or `all` .
sp/t	Specifies the protocol port number associated with the sender of the packet. (extracted from the TCP/UDP header). When the protocol is ICMP or OSPF, this field is replaced with t, which specifies the IP type.
dp/c	Specifies the protocol port number associated with the intended recipient of the packet (extracted from the TCP/UDP header). When the protocol is ICMP, this field is replaced with c which specifies the IP code.
-	Specifies that no information is available
r	Indicates whether the packet had any local affiliation. f Forwarded packets l Local packets o Outgoing b Both
l	Specifies the length of a particular packet in bytes.
f	Identifies if the packet is a fragment.
T	Indicates the tunnel ID.
i	Specifies what interface the packet came in on.

Coexistence of IP Security and IBM Secured Network Gateway 2.2/IBM Firewall 3.1

If you have installed AIX 4.3 with the IP Security function, the IP Security function will be disabled for IP Version 6 if you install an IBM Firewall product afterwards. The IBM Firewall product will override this IP Security function with its own implementation. For related information, see Interoperability Notes.