This is the sixth post detailing my notes on Nmap Network Scanning.
The SYN Scan is stealthy as it never completes the three-way handshake and so is also known as “half-open scanning”. This is a default setting, but can be requested with -sS.
I’m going to perform the -sS scan on two specific ports that I already know will return ‘open’ and ‘closed’. At the same time I will enable - -packet-trace to observe the packets sent and received:
~# nmap -sS -p22,113 –packet-trace scanme.nmap.org
Starting Nmap 6.25 ( http://nmap.org ) at 2013-06-27 10:24 BST
SENT (0.2114s) ICMP 192.168.1.70 > 74.207.244.221 Echo request (type=8/code=0) ttl=46 id=9494 iplen=28
SENT (0.2116s) TCP 192.168.1.70:56558 > 74.207.244.221:443 S ttl=40 id=58656 iplen=44 seq=2891385438 win=1024 <mss 1460>
SENT (0.2117s) TCP 192.168.1.70:56558 > 74.207.244.221:80 A ttl=39 id=61378 iplen=40 seq=0 win=1024
SENT (0.2119s) ICMP 192.168.1.70 > 74.207.244.221 Timestamp request (type=13/code=0) ttl=54 id=53658 iplen=40
RCVD (0.3649s) TCP 74.207.244.221:443 > 192.168.1.70:56558 RA ttl=50 id=0 iplen=40 seq=0 win=0
NSOCK (0.3740s) nsi_new (IOD #1)
NSOCK (0.3740s) UDP connection requested to 192.168.1.254:53 (IOD #1) EID 8
NSOCK (0.3740s) Read request from IOD #1 [192.168.1.254:53] (timeout: -1ms) EID 18
NSOCK (0.3740s) Write request for 45 bytes to IOD #1 EID 27 [192.168.1.254:53]: 4…………221.244.207.74.in-addr.arpa…..
NSOCK (0.3740s) Callback: CONNECT SUCCESS for EID 8 [192.168.1.254:53]
NSOCK (0.3740s) Callback: WRITE SUCCESS for EID 27 [192.168.1.254:53]
NSOCK (0.4170s) Callback: READ SUCCESS for EID 18 [192.168.1.254:53] (74 bytes): 4…………221.244.207.74.in-addr.arpa………….G….scanme.nmap.org.
NSOCK (0.4180s) Read request from IOD #1 [192.168.1.254:53] (timeout: -1ms) EID 34
NSOCK (0.4180s) nsi_delete (IOD #1)
NSOCK (0.4180s) msevent_cancel on event #34 (type READ)
SENT (0.4576s) TCP 192.168.1.70:56814 > 74.207.244.221:22 S ttl=56 id=42589 iplen=44 seq=1522736270 win=1024 <mss 1460>
SENT (0.4579s) TCP 192.168.1.70:56814 > 74.207.244.221:113 S ttl=54 id=44404 iplen=44 seq=1522736270 win=1024 <mss 1460>
RCVD (0.6107s) TCP 74.207.244.221:22 > 192.168.1.70:56814 SA ttl=50 id=0 iplen=44 seq=1918152659 win=14600 <mss 1460>
RCVD (0.6128s) TCP 74.207.244.221:113 > 192.168.1.70:56814 RA ttl=50 id=0 iplen=40 seq=0 win=0
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.15s latency).
PORT STATE SERVICE
22/tcp open ssh
113/tcp closed identNmap done: 1 IP address (1 host up) scanned in 0.64 seconds
The pertinent packet information for port 22:
SENT (0.4576s) TCP 192.168.1.70:56814 > 74.207.244.221:22 S ttl=56 id=42589 iplen=44 seq=1522736270 win=1024 <mss 1460>
RCVD (0.6107s) TCP 74.207.244.221:22 > 192.168.1.70:56814 SA ttl=50 id=0 iplen=44 seq=1918152659 win=14600 <mss 1460>
Acknowledgement received (SA = SYN/ACK) and so port 22 reported open. As Nmap crafted the original packet, the received acknowledgement surprises my operating system, which will respond with a RST packet; therefore, Nmap doesn’t have to acknowledge and close the connection.
Now port 113:
SENT (0.4579s) TCP 192.168.1.70:56814 > 74.207.244.221:113 S ttl=54 id=44404 iplen=44 seq=1522736270 win=1024 <mss 1460>
RCVD (0.6128s) TCP 74.207.244.221:113 > 192.168.1.70:56814 RA ttl=50 id=0 iplen=40 seq=0 win=0
Reset Acknowledgement (RST/ACK) received (RA) port 113 is closed.
A non-response is considered “filtered” as perhaps firewall blocked or down.