The network layer—layer three in the OSI Reference Model—is the primary mechanism for end-to-end routing and delivery of packet data on the Internet. This book is concerned mostly with attacks that are delivered over the IPv4 networking protocol, though many other networking protocols also exist, such as IPX, X.25, and the latent IPv6 protocol.
In this chapter, we'll focus first on how iptables logs network layer packet headers within log message output. Then we will see how these logs can be used to catch suspicious network layer activity.
With the iptables LOG target, firewalls built with iptables have the ability to write log data to syslog for nearly every field of the IPv4 headers.[11] Because the iptables logging format is quite thorough, iptables logs are well-suited to supporting the detection of many network layer header abuses.
The IP header is defined by RFC 791, which describes the structure of the header used by IP. Figure 2-1 displays the IP header, and the shaded boxes represent the fields of the header that iptables includes within its log messages. Each shaded box contains the IP header field name followed by the identifying string that iptables uses to tag the field in a log message. For example, the Total Length field is prefixed with the string LEN= followed by the actual total length value in the packet, and the Time-to-Live (TTL) field is prefixed with TTL= followed by the TTL value.
The dark gray boxes in Figure 2-1 are always logged[12] by iptables. The white boxes denote header fields that are not logged by iptables under any circumstances. The medium gray box is for the options portion of the IP header. This box is shaded medium gray because iptables only logs IP options if the --log-ip-options command-line argument is used when a LOG rule is added to the iptables policy.
Here is an example iptables log message generated by sending an ICMP Echo Request from the ext_scanner system toward the iptablesfw system (refer to Figure 2-1):
[ext_scanner]$ ping -c 1 71.157.X.XPING 71.157.X.X(71.157.X.X) 56(84) bytes of data. 64 bytes from 71.157.X.X: icmp_seq=1 ttl=64 time=0.171 ms --- 71.157.X.Xping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.171/0.171/0.171/0.000 ms [iptablesfw]# tail /var/log/messages | grep ICMP | tail -n 1 Jul 22 15:01:25 iptablesfw kernel: IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:30:48:80:4e:37:08:00SRC=144.202.X.XDST=71.157.X.XLEN=84TOS=0x00PREC=0x00TTL=64ID=0DF PROTO=ICMP TYPE=8 CODE=0 ID= 44366 SEQ=1
The IP header begins in the log message above with the source IP address (expanded into the standard dotted quad notation).[13] Additional IP header fields such as the destination IP address, TTL value, and the protocol field are in bold. The Type Of Service field (TOS), and the precedence and corresponding type bits are included as separate hexadecimal values to the TOS and PREC fields. The Flags header field in this case is included as the string DF, or Don't Fragment, which indicates that IP gateways are not permitted to split the packet into smaller chunks. Finally, the PROTO field is the protocol encapsulated by the IP header—ICMP in this case. The remaining fields in the log message above include the ICMP TYPE, CODE, ID, and SEQ values in the ICMP Echo Request packet sent by the ping command, and are not part of the IP header.
IP options provide various control functions for IP communications, and these functions include timestamps, certain security capabilities, and provisions for special routing features. IP options have a variable length and are used relatively infrequently on the Internet. Without IP options, an IP packet header is always exactly 20 bytes long. For iptables to log the options portion of the IP header, use the following command (note the --log-ip-options switch in bold):
[iptablesfw]# iptables -A INPUT -j LOG --log-ip-options
The default LOG rules in the policy built by the iptables.sh script in Chapter 1 all use the --log-ip-options command-line argument, because IP options can contain information that has security implications.
Now, to illustrate an iptables log message that includes IP options, we once again ping the iptablesfw system, but this time we instruct the ping command to set the timestamp option to tsonly (only timestamp):
[ext_scanner]$ ping -c 1 -T tsonly 71.157.X.XPING 71.157.X.X(71.157.X.X) 56(124) bytes of data. 64 bytes from 71.157.X.Xicmp_seq=1 ttl=64 time=0.211 ms TS: 68579524 absolute 578 0 −578 --- 71.157.X.Xping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.211/0.211/0.211/0.000 ms [iptablesfw]# tail /var/log/messages | grep ICMP Jul 22 15:03:00 iptablesfw kernel: IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:30:48:80:4e:37:08:00 SRC=144.202.X.XDST=71.157.X.XLEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=0 DFOPT (44280D00041670C404167306000000 00000000000000000000000000000000000000000000000000)PROTO=ICMP TYPE=8 CODE=0 ID=57678 SEQ=1
In bold above, the string OPT is followed by a long sequence of hexadecimal bytes. These bytes are the complete IP options included in the IP header, but they are not decoded for us by the iptables LOG target; as you'll see in Chapter 7, we'll use psad to make sense of them.
The iptables LOG target has code dedicated to logging ICMP, and since ICMP exists at the network layer,[14] we'll cover it next. ICMP (defined by RFC 792) has a simple header that is only 32 bits wide. Figure 2-2 displays the ICMP header. This header consists of three fields: type (8 bits), code (8 bits), and a checksum (16 bits); the remaining fields are part of the data portion of an ICMP packet.
The specific fields within the data portion depend on the ICMP type and code values. For example, fields associated with an ICMP Echo Request (type 8, code 0) include an ID and a sequence value.
Like the IP header, the LOG target always logs the ICMP type and code fields, and never logs the ICMP checksum field. There are no command-line arguments in iptables to influence how the LOG target represents fields within the data portion of ICMP packets.[15] The ICMP fields in the first Echo Request packet in this chapter appear starting in the last line below:
Jul 22 15:01:25 iptablesfw kernel: IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:30:48:80:4e:37:08:00 SRC=144.202.X.XDST=71.157.X.XLEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMPTYPE=8CODE=0ID=44366SEQ=1
[11] 1 The same is true of IPv6 headers, but IPv6 is not covered in this book.
[12] 2 There is one exception for the IP Fragment Offset—it is only logged by iptables when it is nonzero.
[13] 3 The iptables LOG target automatically converts the integer representation of an IP address within the kernel to the dotted quad notation for readability in the syslog message. There are other instances of such conversions as well, such as for TCP flags, as we will see in Chapter 3. For reference, the kernel portion of the iptables LOG target is implemented within the file linux/net/ipv4/netfilter/ipt_LOG.c in the kernel sources.
[14] 4 Contrary to the tendency some have of lumping ICMP into the bucket reserved for transport layer protocols such as TCP and UDP, ICMP is considered a network layer protocol. See W. Richard Stevens' book TCP/IP Illustrated, Volume 1, page 69 (Addison-Wesley, 1994).
[15] 5 An examination of the switch statement, beginning at line 249 of the LOG target source code in the Linux kernel (see the file linux/net/ipv4/netfilter/ipt_LOG.c), sheds light on this.