A TCP SYN scan (which we have covered earlier) leaves a lot of fingerprints on the target host, thus revealing the identity of the scanning host. Some of the hosts with Intrusion Detection Systems (IDS) and firewalls do watch for SYN packets targeted at particular ports. So how does a penetration tester work around this?
The Nmap FIN scan comes in handy in such circumstances. The standard use of a FIN packet is to terminate the TCP connection — typically after the data transfer is complete. Instead of a SYN packet, Nmap initiates a FIN scan by using a FIN packet. Since there is no earlier communication between the scanning host and the target host, the target responds with an RST packet to reset the connection. However, by doing so, it reveals its presence. A FIN scan is initiated using a command like
nmap -sF 192.168.100.100.
With so many different operating systems and versions around, it is really interesting how Nmap detects the operating system of a target in a very short time. Let us study the OS detection command in detail. Table 1 shows a sample output that’s running an OS detection command against a target PC with an Intel Ethernet card, while running Windows XP SP3.
|Table 1: Analysing the output of an OS detection scan|
||Syntax of the executed command.
|Initiating OS detection (try #1) against 192.168.2.101||OS detection uses a combination of ICMP echo, TCP and UDP packets.|
|Host 192.168.2.101 is up (0.0030s latency).||Discovered the host status in practically no time|
|Interesting ports on 192.168.2.101:
Not shown: 997 closed ports
PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds
|Lists detected open ports on the host|
|MAC Address: 00:16:76:CE:8C:3C (Intel)||MAC address of the host’s Ethernet card, and its manufacturer|
|Device type: general purpose|
|Running: Microsoft Windows XP||With at least one open and one closed port on the target host, Nmap can detect the target OS effectively. To instruct Nmap to detect OS on only such hosts, to save scan time, use the
|OS details: Microsoft Windows XP SP2 or SP3 or Windows server 2003|
|Network Distance: 1 hop||The host is in the same network|
|TCP Sequence Prediction: Difficulty=264 (Good luck!)||TCP sequence prediction: The TCP 3 way handshake is initiated by a SYN packet followed by an initial sequence number. If this number can be predicted, an attacker can construct a spoofed packet which will appear to have been sent by the scanned host. This denotes the difficulty of predicting the initial sequence number.|
|IP ID Sequence Generation: Incremental|
|Read data files from:
|OS detection performed. Please report any incorrect results at http://nmap.org/submit/.||Gives the user a chance to submit incorrect OS detection data to the Nmap team, for improvements in the next version.|
|# NMap done at Tue Nov 30 20:13:03 2010 — 1 IP address (1 host up) scanned in 3.56 seconds||Completed the whole OS detection for one host in less than 4 seconds!|
Security by obscurity? Assuming you are a Web developer, would you be interested in running an
httpd service on a non standard TCP port — say, 1793 — rather than on the standard TCP port 80? In the early days, before I knew enough about various Nmap scan techniques, I thought this was just incredible! I felt I’d found a gold mine! If a service is running on a nonstandard port, it does add a great layer of security.
Welcome to the world of Nmap, which detects practically any service, even running on a non-standard port.
Table 2 shows Nmap scan output against a live IPCop firewall with its Web interface configured on the TCP port 1775. By default, IPCop runs the SSH service on the non-standard TCP port 222 (as against the standard SSH port 22). The output is filtered.
|Table 2: Nmap scan output against a live IPCop firewall|
|# NMap 5.00 scan initiated Tue Nov 30 21:04:17 2010 as:
||The command line, to cut scan time
|Initiating OS detection (try #1) against 121.xxx.xxx.xxx.static-pune.vsnl.net.in (121.xxx.xxx.xxx)||Live host on the web.|
|Host 121.xxx.xxx.xxx.static-pune.vsnl.net.in (121.xxx.xxx.xxx) is up (0.052s latency).|
|Interesting ports on 121.xxx.xxx.xxx.static-pune.vsnl.net.in (121.xxx.xxx.xxx):
PORT STATE SERVICE VERSION 222/tcp open ssh OpenSSH 4.7 (protocol 2.0) 1775/tcp open http Apache httpd
|Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port|
|Device type: firewall|
|Running: IPCop Linux 2.4.X|
|OS details: IPCop firewall 1.4.10 – 1.4.18 (Linux 2.4.31 – 2.4.34)||Though one open and one closed port was missing, NMap detected the OS and Kernel version.|
|TCP Sequence Prediction: Difficulty=206 (Good luck!)|
|IP ID Sequence Generation: All zeros|
|Read data files from:
|OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .|
|# NMap done at Tue Nov 30 21:04:30 2010 — 1 IP address (1 host up) scanned in 13.61 seconds|
While scanning real-world networks, the situation may demand that you specify the targets in various ways, if for example, you wish to specify the range of IP addresses from 192.168.100.0 to 192.168.100.127. To specify every host individually is impractical, so you can specify this range in two different ways: 192.168.100.0/25 or 192.168.100.0-127. Select the syntax that best suits your needs.
A word of caution — take care when you use the CIDR notation. Initiating a scan against public IPs with /16 will start a scan against the full Class B range. To verify which IP addresses will be scanned by the range you specified, add the
-sL option the first time you run the command. This will only list all the hosts in the scan range, and will not initiate a scan. After verifying the range, you can remove the
Please try out these scanning techniques, hands-on, before exploring further. And don’t forget to keep a watch on this series for more tips and tricks, including real-world scanning examples!