Now we turn to Nmap's SYN (or half-open) scan method. The SYN scan is Nmap's default scan type when executed by a privileged user. (Indeed, this and all other interesting Nmap scan types require access to raw sockets and so must be executed by a privileged user.)
Because the iptables firewall on the target system has been configured to drop all SYN packets not destined for TCP port 80, the SYN scan looks nearly identical to a regular TCP connect() scan when viewed on the wire, because there are very few SYN/ACK packets for the scanners' TCP stack to respond to. We see SYN packets from the same source address and nothing else.
This reasoning is generally sound in theory, but in practice we see several significant differences between the SYN and connect() scans even when the initial SYN packets are dropped by iptables in both cases. These differences show up in the specific packet header fields for the SYN packets that are sent by Nmap in the SYN scan mode versus those that are sent by the TCP stack itself via the Nmap connect() scan. As discussed in Chapter 3, many more TCP options are sent by the connect() scan than by the SYN scan, but there are other differences as well. The remainder of this section illustrates the specific differences between the SYN packets in each scan, and how you can see these differences in the iptables log messages on the iptablesfw system.
The command below starts a SYN scan against the target IP address 71.157.X.X:
[ext_scanner]# nmap -n 71.157.X.X --max-rtt-timeout 500
Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2007-07-13 13:58 EDT Interesting ports on 71.157.X.X:
(The 1672 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 22.611 seconds
A quick examination of the /var/log/messages file shows that psad has detected the scan:
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.1 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.)
Was this article helpful?