Linux Firewalls - Michael Rash [25]
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.X
PING 71.157.X.X (71.157.X.X) 56(124) bytes of data.
64 bytes from 71.157.X.X icmp_seq=1 ttl=64 time=0.211 ms
TS: 68579524 absolute
578
0
−578
--- 71.157.X.X ping 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.X DST=71.157.X.X
LEN=124 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF OPT (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.
Logging ICMP
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.
Figure 2-2. The ICMP header and corresponding iptables log message fields
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.X DST=71.157.X.X
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP
TYPE=8 CODE=0 ID=44366 SEQ=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.
Network Layer Attack Definitions
We define a network layer attack as a packet or series of packets that abuses the fields of the network layer header in order to exploit a vulnerability in the network stack implementation of an end host, consume network layer resources, or conceal the delivery of exploits against higher layers.
Network attacks fall into one of three categories:
Header abuses
Packets that contain maliciously constructed, broken, or falsified