Advanced Nmap: FIN Scan & OS Detection

Scan time!

Nmap is a fantastic tool, and I just can’t refrain from praising it, every time I use it. The earlier articles in this series have detailed many important Nmap scan types. Let us continue with some more intricacies of Nmap, by discussing various other command-line options.

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?

FIN scan

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.

OS detection

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
Item Interpretation
nmap -O -v -oversiondetect.txt 192.168.2.101 Syntax of the executed command. -v increases the verbosity of the output.
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 --osscan-limit option
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: /usr/share/nmap
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
Item Interpretation
# NMap 5.00 scan initiated Tue Nov 30 21:04:17 2010 as:
nmap -v -O -PN -p222, 1775 -sV -oIPCopOS.txt 121.xxx.xxx.xxx
The command line, to cut scan time -PN is used and port numbers are specified.
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
  • SSH port discovered on 222 along with its version
  • HTTP port 1775 detected along with its version
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: /usr/share/nmap
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 -sL parameter.

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!

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherwise noted.
Open Source For You is powered by WordPress, which gladly sits on top of a CentOS-based LEMP stack.

Creative Commons License.