Linux Firewalls - Michael Rash [65]
Jul 13 13:58:10 iptablesfw psad: scan detected: 144.202.X.X -> 71.157.X.X
tcp: [1-65301] flags: SYN tcp pkts: 1542 DL: 4
The scanner has reached danger level 4 because over 1,500 packets have been sent, and this exceeds the DANGER_LEVEL4 variable in the psad.conf file.
Once again, on the target system, iptables has logged each SYN packet from the scan:
Jul 13 13:58:04 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=44 TOS=0x00 PREC=0x00
TTL=53 ID=27267 PROTO=TCP SPT=62316 DPT=7200 WINDOW=2048 RES=0x00 SYN URGP=0 OPT
(020405B4)
Jul 13 13:58:04 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=44 TOS=0x00 PREC=0x00 TTL
=55 ID=29182 PROTO=TCP SPT=62316 DPT=5001 WINDOW=4096 RES=0x00 SYN URGP=0 OPT
(020405B4)
Jul 13 13:58:04 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=44 TOS=0x00 PREC=0x00 TTL=59
ID=39294 PROTO=TCP SPT=62315 DPT=3264 WINDOW=4096 RES=0x00 SYN URGP=0 OPT
(020405B4)
This time we've highlighted fields of the iptables log messages above that are different from the TCP connect() scan in the previous sections. These are the fields, along with the reason each is different than in the connect() scan:
LEN
The length field in the IP header is 14 bytes shorter for the SYN scan because the real TCP stack has more options in the SYN packets that it sends via the connect() scan.
TTL
The Time-to-Live (TTL) value in the IP header is always initialized to the same value by the real IP stack on a client system during the TCP connect() scan. However, because Nmap is crafting the TCP SYN packet in the SYN scan, it can set the TTL value to whatever it wants, and it randomly selects TTL values between 37 and 60.
WINDOW
The TCP window size is set by Nmap to be either 1024, 2048, 3072, or 4096 during the SYN scan. In contrast, the real TCP stack always initiates TCP connections with a window size of 5840.
OPT
The options portion of the TCP header is substantially shorter in the Nmap SYN scan. In this case, it uses a single option, the Maximum Segment Size, and sets it to 1460.[42] Most real TCP stacks send multiple options, such as the Timestamp, No Operation (NOP), and whether Selective Acknowledgment is OK (SACK), in addition to the Maximum Segment Size. (You'll find more information about decoding the OPT string in iptables messages in "Emulating p0f with psad" on page 122.)
TCP FIN, XMAS, and NULL Scans
The Nmap FIN, XMAS, and NULL scans appear quite similar when represented by iptables log messages. Indeed, the only significant difference between these scan types is the combination of TCP flags used—a difference that shows up in the TCP flags portion of the iptables logging format for TCP packets. In addition, because the FIN, XMAS, and NULL scans are each represented by a specific Snort rule that does not require application layer inspection, psad can detect these scans via individual packets rather than having to rely on packet counts and port ranges.
FIN PACKETS AND NETFILTER CONNECTION TRACKING
It is normal to find a TCP packet with the FIN flag set in legitimate TCP communications; it is used to indicate that one side of a TCP connection has no more data to send and is closing the connection. Therefore, in order for psad to effectively differentiate between a FIN scan and a legitimate FIN packet, it is important to use Netfilter's connection tracking mechanism to accept all packets that match the ESTABLISHED state and to log and drop the rest. Unexpected FIN packets match the Netfilter INVALID state because they are not part of any established TCP connection and so are logged and dropped very early in the iptables policy built by the iptables.sh script in Chapter 1.
You can initiate the FIN, XMAS, and NULL scans with the respective -sF, -sN, and -sX command-line arguments to Nmap. For the sake of