Logging the UDP Header

The UDP header is defined in RFC 768. It is only eight bytes long and has no variable length fields (see Figure 3-3).

Since there are no special command-line arguments to influence how a UDP header is represented by the LOG target, iptables always logs UDP headers in the same way.

01 2345678901 2345678901 2345678901

Source Port (SPT=)

Destination Port (DPT=)

Length (LEN=)

Checksum

Figure 3-3: The UDP header and iptables log message fields

Figure 3-3: The UDP header and iptables log message fields

Even though the default LOG rules in the iptables policy discussed in Chapter 1 use the --log-tcp-options argument, if a UDP packet hits one of these rules, iptables does the right thing and only logs information that is actually in the packet; it won't attempt to log the options portion of a TCP header that does not exist. The UDP checksum is never logged, but the remaining three fields (SPT, DPT, and LEN) are all included:

[ext_scanner]$ echo -n "aaaa" | nc -u 71.157.X.X 5001 [iptablesfw]# tail /var/log/messages | grep 5001 Jul 12 16:27:08 iptablesfw kernel: DROP 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=33 TOS=0x00 PREC=0x00 TTL=64 ID=38817 DF PROTO=UDP SPT=44595 DPT=5001 LEN=12

NOTE The UDP LEN field in the iptables log message above includes the length of the UDP

header plus the length of the application layer data. In this case, the application layer data consists of the four bytes "aaaa", so adding this to the length of the UDP header (eight bytes) yields a total of 12 bytes. The -n command-line argument to the echo command instructs it not to add a trailing newline character. Had this argument not been used, the value of the LEN field would have been 13 to accommodate the additional byte.

Transport Layer Attack Definitions

Like the definition of a network layer attack (given in Chapter 2), we define a transport layer attack as a packet or series of packets that abuses the fields of the transport layer header in order to exploit either a vulnerability or error condition in the transport stack implementation of an end host.

Transport layer attacks fall into one of the following three categories:

Connection resource exhaustion Packets that are designed to saturate all available resources for servicing new connections on a targeted host or set of hosts. A good example is a DDoS attack in the form of a SYN flood.

Header abuses Packets that contain maliciously constructed, broken, or falsified transport layer headers. A good example is a forged RST packet designed to tear down a TCP connection. We lump port scans (discussed below) into this category as well, although a scan by itself is not malicious.

Transport stack exploits Packets that contain transport layer stack exploits for vulnerabilities in the stack of an end host. That is, the kernel code dedicated to the processing of transport layer information is itself the target. A good example (especially in the context of this book) is an exploit announced in 2004 for a vulnerability in the Netfilter TCP options processing code (this bug was quickly fixed by the Netfilter project, so any recent version of the kernel is not vulnerable). While this does not exploit the TCP stack itself, it exploits code that is directly hooked into the stack via the Netfilter framework.

Was this article helpful?

0 0

Post a comment