Learning Nmap: The Basics – LINUX For You


Learning Nmap: The Basics – LINUX For You.

Learning Nmap: The Basics

By Rajesh Deodhar on August 1, 2010 in How-TosTools / Apps · 0 Comments

Mapping a network

Nmap, the network mapping tool, is the starting point when analysing any network. It is an exciting tool — compact and power-packed. This article looks at the range of functions and options it supports.

The Nmap man page describes it as a security/network exploration tool and port-scanner. Nmap (Network Mapper) is a versatile open source tool, which systems administrators can’t do without. Some of its interesting features include:

  • It’s fast!
  • Uses raw IP packets in various innovative ways for scanning.
  • Can detect operating system versions (and if it’s unable to detect, it requests the user to send the scan signature to the developer, for incorporation in future versions of Nmap).
  • Provides various interesting options to scan the network.

Caution: While using Nmap, be warned regarding the following information!
Under the stringent rules of the Indian Cyber Law 2000 and its further amendments till date, even a port scan on a public IP may land you in jail. Do not scan computers that you do not own, or run scans over networks that you do not own, without written permission from the owners.You may also scan the scanme.nmap.org website for testing. This permission only includes scanning via Nmap, and you are not allowed to test exploits and/or denial of service attacks. Don’t forget to follow the rules listed in the Nmap man page. Abuse of this service will be reported to the government by the site owners.

Use Nmap very carefully, and only for discovery/audits of your network. As we’ll see in this article, it is a very powerful tool, and could cause disruption/damage to the target system or network.

Fully understand what you are doing, even with scripted scans, before you do it. Ignorance will not excuse anybody from being prosecuted under the law.

Also note that if you have a website of your own, either hosted at a hosting provider or on a rented physical server, the server and network do NOT belong to you even though you own the website’s content. You should ideally obtain permission from such hosting providers/server owners to carry out even “testing” probes of your own website.

The basic command line syntax to invoke Nmap is as follows:

nmap [scan type(s)] [options] {target specification}

Nmap has a huge list of command-line options, generally categorised into target specification, host listing, port specifications, service identification, scan technique, scripted scans and output options.
Some of the Nmap switches only work when run as the root (superuser). Let’s look at some of the basic Nmap commands:

  • nmap -sL 192.168.10.0/24 — Lists all the hosts scanned (all responding IPs in the subnet from 192.168.10.1 to 192.168.10.254).
  • nmap -p80,443 192.168.10.10-20 — Scans the IP address range looking for open ports 80 and 443.
  • nmap -p T:80,8080,6588,800 172.16.0.1/22 — Scans all hosts between 172.16.0.1 and 172.16.3.254, looking for open TCP ports 80, 8080, 6588 and 800 (the default listening ports for various proxy servers).
  • nmap -sP 192.168.10.10,20 — Ping scans two hosts in a fast scan.
  • nmap -PN 192.168.10.0/29 — Scans all the hosts in the 192.168.10.1 to 192.168.10.6 range. Sometimes, host-based firewalls deny ping requests, and it is difficult to scan such hosts. The -PN scan is useful in such cases; it scans the hosts assuming them to be online.
  • nmap -A -F 192.168.10.1 — Detects target OS and services running on it, in fast-scan mode.

These basic commands are useful for standard scans in any network, and serve a variety of purposes including checking open ports; whether unintended services (like terminal services, VNC, FTP, etc) are running on important hosts; obtaining a list of IP addresses to be scanned, and so on.

However, these simple and straightforward scans may not fulfil all requirements. Sometimes, for example, special scans are required in order to test intrusion detection/prevention systems. There might also be the need to conceal the identity of the scanner from the target host.

Nmap does indeed provide various ways to conceal your IP address (you can also conceal your MAC address by spoofing) though you have to be careful while using these commands. They require an in-depth knowledge of TCP/IP protocols, and may disrupt the systems/network or cause damage if not run properly. Let’s look at some stealth techniques to conceal the identity of the scanning system.

Idlescan

nmap  -v  -sI  192.168.10.100  192.168.10.105

This scan will probe 192.168.10.105 while pretending that the scan packets come from another host; the target’s logs will show that the scan originated from 192.168.10.100. This is called a zombie host.

In our networking context, zombie hosts are those controlled by other hosts on the network. Not all hosts can be used as zombies, as certain conditions are required to be met before this is possible. (Using packages like hping may enable you to find a zombie host on the network.) The -v switch increases the verbosity of the output.

Decoy host

nmap -sS -P0 -D 192.168.10.201,192.168.10.202,192.168.10.203 192.168.10.50

This command is especially useful while testing IDS/IPS. The -sS option will perform a SYN scan on the target host. While doing so, it will spoof the packet contents to make the target host see them as coming from the specified (-D) decoy hosts. The -sI and -D switches can’t be combined, for obvious reasons.

Now, a word of caution: be careful not to cause an unintended Denial of Service (DoS) attack while using the -D option. To understand how this could happen, we need to know how a TCP handshake operates. TCP, being a connection-oriented protocol that guarantees delivery of packets, operates with a three-way handshake:

  • The client initiates the communication by a SYN
  • The server acknowledges with a SYN-ACK
  • The client again sends an ACK, and now they can communicate

If the -D switch is used, and there is a live host at the decoy IP address, then the SYN-ACK reaches the actual host at the decoy IP address, and not the host running the Nmap scan. Since the real host at the decoy address did not initiate the connection, it closes the connection by sending a TCP Reset (RST). There’s no problem with this.

However, a problem occurs if the decoy IP address is not active on the network — there is no RST sent to the scan target, which keeps the connection open. As Nmap continues to generate more and more requests to the target with the decoy IP as the source, the scan target has a growing list of open connections for which it maintains the “connection initiated” state. This ends up consuming more and more resources on the target, and may cause a DoS to other, legitimate hosts and communications.

Other interesting command-line options

Nmap’s creators have considered many possibilities while designing it. One case in point is the -ttl option. To understand its use, let’s once again go into some detail on the IP protocol. Packet headers contain a field called TTL (Time To Live). The TTL field is set by the machine from which the packet originates. Every machine that receives and relays it on the route towards its destination, decrements the TTL field value by some amount.

If the TTL field value falls to zero before the packet arrives at its destination, then the packet is dropped, and an ICMP error is sent back to the sender. This mechanism is intended to prevent packets that could not be delivered to the target from remaining in circulation on the network and swamping the network resources.

Although TTL was originally meant to be a measure of time, as indicated by its name, in practice, its value is reduced by one on each hop (relaying of the packet) and not by some number of seconds. Thus, the value of the TTL field actually determines the maximum number of hops for which the packet can be relayed without being discarded.

A typical default value for TTL on many operating systems is 128. However, Nmap’s -ttloption lets you define a custom value for scan packets, which is a very useful feature. This includes, for example, ensuring that the packet is not relayed from your LAN onto the WAN/Internet. Fantastic, isn’t it?

Some of the other important Nmap command-line options that require an understanding of the TCP/IP protocol include:

  • Fragmentation of packets (-f and -ff options)
  • Using the “FTP bounce” technique to scan via FTP servers (-b)
  • Changing the scan delay (-scan_delay is especially useful if the target has IDS/IPS, and blocks scan requests)
  • Timing policies (-T)
  • Scripted scans

Listing active hosts on the network

A common sequence in network testing is to first generate a list of all active hosts in a network. The list can be used as an input to other applications, which lack the capacity to scan for active hosts but must be given one or more target IP address. Here is a short command sequence that does this:

nmap -sP -n -oG hostlist 192.168.10.0/24

cut -d " " -f2 hostlist > iplist

The first command executes a ping scan (-sP) and generates a list of active hosts in the target range/network. This list will be stored in the file hostlist in greppable format (-oG). The second command reads the data from the file, splits each line into fields based on a space character delimiter, and outputs the second field (the IP address), thus generating a new file, iplist, which is simply the list of active IP addresses/hosts in the given range.

The Zenmap GUI

Nmap has a huge list of command-line options that are difficult to remember and use, even for experienced administrators. Zenmap, a GUI for Nmap, simplifies this considerably. It even provides ready-made scan profiles from which you can choose. The commands you generate in the GUI can also be run at a command line, if required. The GUI also has a very important added function — a graphical display of discovered hosts, and the hops required to reach each host! A sample output from this feature is shown in Figure 1.

Sample Zenmap discovered hosts display

Figure1: Sample Zenmap discovered hosts display (click to enlarge)

We hope that the few important concepts about the TCP/IP protocol, the power of Nmap, and the other ideas interested you!

References

  • Nmap Network Scanning, the official guide to the Nmap Security Scanner
  • Nmapin the Enterprise: Your Guide to Network Scanning, by Angela Orebaugh and Becky Pinkard

Advertisements

Advanced NMap: Some Scan Types – LINUX For You


Advanced NMap: Some Scan Types – LINUX For You.

Advanced NMap: Some Scan Types

 

 

By Rajesh Deodhar on November 1, 2010 in How-TosSysadminsTools / Apps · 0 Comments

Advanced Nmap

A broad overview and the basic features of NMap have been covered in an earlier article in this series of articles on Nmap. In this article, we discuss in detail various NMap scan types, and the practical use of these commands to scan various devices and networks.

Before we begin understanding NMap scan types, let us start with the basics, including understanding the 3-way TCP handshake. TCP/IP is not a single protocol, but a suite comprising various protocols, some of which are detailed in Table 1.

Table 1: Various TCP/IP protocols
1. Application layer FTP, HTTP, SNMP, BOOTP, DHCP
2. Transport layer TCP, UDP, ICMP, IGMP
3. Network layer ARP, IP, RARP
4. Data link layer SLIP, PPP

UDP and TCP

UDP is a connection-less protocol that does not assure the delivery of packets at the other end. However, that does not mean it is an unreliable protocol; higher-level applications must take care to verify that data has been received at the other end. This practice has its own uses, like with live audio/video transfers, where real-time delivery is a must.

TCP is a connection-oriented protocol, which assures delivery of packets. ICMP packets are used to convey error messages, if any. The TCP three-way handshake is used to establish and reset connections, and this concept is key to understanding various NMap scan types. In the TCP three-way handshake:

  1. A “client” initiates communication with a SYN (Synchronise) packet with a randomly generated number, X.
  2. The server acknowledges with a SYN-ACK (Acknowledgement), X+1 and a randomly generated number, Y.
  3. The client again sends an ACK, followed by Y+1, thus completing the handshake. Now the client and server can start data transfer.

After the data transfer is complete, a FIN (Finish) packet is sent by the client, to end the connection.

Nmap uses/tweaks this handshake very effectively for various scan types. Before we proceed, let us be clear about two basic but important aspects of Nmap scans:

  1. By default, Nmap scans 1,000 most common ports for each protocol. The list of these ports can be modified in the nmap-services file, typically stored in /etc/services. (I have never used this; the default ports are almost always sufficient!
  2. Root privileges are required to run any scan that modifies the standard TCP handshake.

Now, let us try to understand the detailed workings of various NMap scan types.

TCP SYN Scan -sS

This is the default Nmap scan, used to detect open TCP ports in the target range. At the start of a SYN Scan, NMap initiates a TCP handshake with a standard SYN packet, to the required TCP port of the device to be scanned (target). The target’s response, giving details of port status, differs depending on the status of the destination port (see Table 2).

Table 2: SYN scan client responses
Port status Client response Inference
Open Standard response SYN-ACK Service running on the port
Closed Standard response RST Service not running on the port
Filtered No response Firewalled port

If the device responds with a SYN-ACK, Nmap sends an RST instead of an ACK, resetting the session, rather than completing the handshake for data transfer. If ACK was sent instead of RST, the connection would be left open till session time-out, making the device prone to a denial of service type of situation.

To run a SYN scan, root privileges are required under Linux. A SYN scan is used to find the status of TCP ports on various devices on the network. Since the SYN scan works on TCP, it will work across all operating systems and other devices that implement TCP, such as controllers, PLCs, network printers, Ethernet switches, and mobile phones.

Since it does not open a valid TCP connection, it’s quiet, and difficult to detect. However, careful network monitoring will reveal too many RST frames in traffic, due to one RST frame per scanned port. Here’s a sample SYN scan that will return various open TCP ports:

nmap -sS 192.168.100.100

Ping Scan -sP

This scan is used to find active hosts in the range. Rather than using ports like a SYN scan, a ping scan starts by sending an ICMP echo request to the target range. Active devices on the network will respond with an ICMP echo reply, thus revealing their status.

A firewalled host with blocked ICMP will not respond to the ICMP echo request. The obvious basic use of this scan is to find all active hosts on the network. This set of two commands gives a list of all active IP addresses in the 192.168.100.0/24 range:

nmap -sP -n -oG hostlist 192.168.100.0/24    ## grep'able output file, hostlist
cut -d " "-f2 hostlist > iplist    ## list of all active IPs in the target range, iplist)

The ping scan uses only one packet for the request, and may get one packet in response, thus making it the fastest of all Nmap scan types, with the lowest footprint. The ping scan cannot be combined with other scan types.

UDP Scan -sU

This is used to find the status of UDP ports in the target range. At the start of the UDP scan, Nmap sends a 0-byte UDP packet directed towards a UDP port. The target’s response differs depending on the status of the scanned port:

  1. Open port: Data on the scanned UDP port.
  2. Closed port: ICMP error message indicating no service is running on this port.
  3. Open/Filtered port: No ICMP message; Nmap waits for the timeout, and can’t determine whether the port is open, or filtered by a firewall.

UDP can be used to detect malware/spyware effectively. The following sample UDP scan command will return open/closed/open/filtered UDP ports on the host:

nmap -sU 192.168.100.100
Table 3: Summary of SYN, ping and UDP scans
Scan type Facets
SYN scan (-sS) — Scan TCP ports
  • Does not leave a log entry
  • Requires root access.
  • Traffic of RST frames increases with use of SYN scan.
  • Gives information about TCP ports.
Ping scan (-sP)— Identify active hosts
  • Very difficult to trace — only two standard ICMP frames, which are very common in network traffic, are required to complete the scan.
  • Root privilege not required to run the scan.
  • Yields a device inventory by identifying active devices on the network.
UDP scan (-sU) — Scan UDP ports
  • Uses 0 byte UDP data, causing low overhead on the network.
  • Requires root access.
  • Many operating systems put restrictions on UDP traffic, thus this scan can be very slow if run on devices running those operating systems
  • Works well on Microsoft operating systems, since Microsoft does not restrict UDP port traffic.
  • Best for scanning known UDP ports used by spyware/malware for communication.

Please try out these scanning techniques, hands-on, before further exploring various other scan options provided by NMap. And don’t forget to keep a watch on this series for further details!

Advanced Nmap: FIN Scan & OS Detection – LINUX For You


Advanced Nmap: FIN Scan & OS Detection – LINUX For You.

Advanced Nmap: FIN Scan & OS Detection

 

By Rajesh Deodhar on January 1, 2011 in How-TosSysadminsTools / Apps · 0 Comments

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!