Linux Firewalls - Michael Rash [36]
Unlike the SYN packets generated by the real TCP stack, Nmap doesn't care about negotiating a real TCP session. The only thing Nmap is interested in is whether the port is open (Nmap receives a SYN/ACK), closed (Nmap receives a RST/ACK), or filtered (Nmap receives nothing) on the remote host. Hence, the TCP SYN packet that Nmap puts on the wire just needs to qualify to the remote host as a TCP packet with the SYN flag set so that the remote TCP stack either responds with a SYN/ACK, a RST/ACK, or nothing (if the port is filtered).
For versions of Nmap in the 3.x series, no TCP options are included within SYN packets used to scan remote systems, as shown below. (If options were included in the packet, then they would appear after the TCP window size, as shown here in bold.)
11:17:30.313099 IP 71.157.X.X.52831 > 72.14.203.99.80: S 2001815651:2001815651(0)
win 3072
For recent versions of Nmap, the Maximum Segment Size (MSS) value is included within SYN packets that it sends, as shown below in bold.
15:55:57.521882 IP 71.157.X.X.58302 > 72.14.203.99.80: S 197554866:197554866(0)
win 2048 If we run a SYN scan now against the iptablesfw system, the same ports that we saw from the connect() scan are reported as open, but there are fewer TCP options than for the connect() scan, as you can see. That is, the options string for the SYN scan is 020405B4 whereas the options string for the connect() scan in the previous section is 020405B40402080A362957720000000001030306. [ext_scanner]# nmap -P0 -sS 71.157.X.X Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-07-03 00:27 EDT Interesting ports on 71.157.X.X: (The 1670 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE 80/tcp open http 443/tcp open https Nmap finished: 1 IP address (1 host up) scanned in 22.334 seconds [iptablesfw]# grep SYN /var/log/messages | tail -n 1 Jul 3 00:27:59 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=52 ID=21049 PROTO=TCP SPT=43996 DPT=658 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405B4) TCP FIN, XMAS, and NULL Scans The FIN, XMAS, and NULL scans operate on the principle that any TCP stack (that adheres to the RFC) should respond in a particular way if a surprise TCP packet that does not set the SYN, ACK, or RST control bits is received on a port. If the port is closed, then TCP responds with a RST/ACK, but if the port is open, TCP does not respond with any packet at all. The following example shows a FIN scan of the iptablesfw system, and note at ❶ that all ports are reported as open|filtered by Nmap. Because a surprise FIN packet is not part of any legitimate TCP connection, all of the FIN packets (even those to open ports) are matched against the INVALID state rule in the iptables policy and subsequently logged and dropped. (See the DROP INVALID log prefix at ❷ and the FIN flag set at ❸ below.) [ext_scannner]# nmap -P0 -sF 71.157.X.X Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2007-07-03 00:33 EDT All 1672 scanned ports on 71.157.X.X are: ❶open|filtered Nmap finished: 1 IP address (1 host up) scanned in 36.199 seconds [iptablesfw]# grep FIN /var/log/messages | tail -n 1 Jul 3 00:34:17 iptablesfw kernel: ❷DROP INVALID 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=40 TOS=0x00 PREC=0x00 TTL=54 ID=50009 PROTO=TCP SPT=60097 DPT=1437 WINDOW=3072 RES=0x00 ❸FIN URGP=0 TCP ACK Scans The TCP ACK scan (Nmap -sA) sends a TCP ACK packet to each scanned port and looks for RST packets (not RST/ACK packets, in this case) from both open and closed ports. If no RST packet is returned by a target port, then Nmap infers that the port is filtered, as shown in the example ACK scan against the iptablesfw system below at