Checking Your Work with Scanners, Part I (of II): nmap
So useful and popular is nmap that it is now included in most Linux distributions. Red Hat 7.0 and Debian 2.2, my two current flavors of choice, both come with nmap (under Applications/System and Extra/Net, respectively). Therefore, the easiest way for most Linux users to install nmap is via their system's package-manager (e.g., RPM, dselect, YAST) and preferred OS installation-medium (CD-ROM, FTP, etc.).
If, however, you want the very latest version of nmap and/or its source code, both are available from http://www.insecure.org/ (Fyodor's web site) in RPM and TGZ formats. Should you wish to compile nmap from source, simply download and expand the tarball, then enter these commands (allowing for any difference in the expanded source code's directory-name; nmap v2.53 may be obsolete by the time you read this):
cd nmap-2.53 ./configure make make install
There are two different ways to run nmap. The most powerful and flexible way is via the command prompt. There is also a GUI called nmapfe, which constructs and executes an nmap for you (see Figure 1).
This GUI is useful for quick-and-dirty scans or as an aid to learning nmap's command-line syntax. However, I strongly recommend learning nmap proper since the GUI presents only a subset of nmap's features. Besides, it's overkill to fire up X for little old nmap.
The nmap commands are easy to learn. The basic syntax for simple scans is: nmap -s (scan-type) -p (port-range options) (target). The -s flag is immediately followed by one of the following:
T: TCP Connect Scan
S: TCP SYN Scan
F: TCP FIN Scan
N: TCP NULL Scan
X: TCP Xmas Tree Scan
U: UDP Scan (can be combined with above)
R: RPC Scan (can be combined with above)
The -s flag, which specifies which type or types of scan to run, can be followed by any of the TCP scan-types, U for UDP scanning, R for RPC scanning/identification or any combination of these three groups of flags. Only one TCP scan-type may be specified in a given session, however. If the -s flag is omitted altogether, the default scan-type is TCP Connect.
For example, -sSUR tells nmap to perform a SYN scan, a UDP scan and finally an RPC scan/identification on the specified target(s). -sTSR would fail, however, since TCP Connect and TCP SYN are both TCP scans.
If you state a port range using the -p flag, you can combine commas and dashes to create a very specific group of ports to be scanned. For example, typing -p 20-23,80,53,600-1024 tells nmap to scan the ports 20 through 23, 80, 53 and 600-1024. Don't use any spaces in your port range, however.
Similarly, the “target” expression can be a hostname, a host IP address, a network IP address or a range of IP addresses. For example typing 192.168.17.* expands to all 255 IP addresses in the network—192.168.17.0/24 (in fact, you could use 192.168.17. 0/24 instead); 10.13.[1,2,4].* expands to 10.13.1.0/24, 10.13.2.0/24, and 10.13.4.0/24. As you can see, nmap is very flexible in the types of target expressions it can understand.
Before we go any further, let's examine some basic scans that use the flags we've discussed so far. The examples in this section all use nmap version 2.53 (the most current as of this writing) running on Red Hat 7.0. The target system in these examples is running Windows98 with Sambar web server installed and active for good measure.
First, suppose we want nmap to perform an “all-default” scan. We're not required to provide any flags if we don't want to; given nothing more than a target IP or IP expression, nmap will ping each target host and then scan it using the TCP Connect method on (destination) ports 0-1024 plus all other ports listed in /usr/share/nmap/nmap-services (your path to this file may vary), for a total of 1,523 TCP ports. Listing 1 shows what such an all-default scan looks like when run against a Windows98 system.
Note that it took only two seconds to query 1,523 ports. When I said the TCP Connect method is fast, I wasn't just whistling “Dixie”.
For our next example scan, suppose we want to add UDP to the mix, and while we're at it, we want to see if any of the open ports we find are running RPC applications. Since we want to do UDP port scanning in addition to, and not instead of, TCP Connect scanning, we'll need to say so explicitly. Our command and its input will look like Listing 2.
The -sU and -sR scans (combined above in -sTUR) go particularly well together: RPC is a UDP-intensive protocol. When nmap finds an RPC service on an open port, it appends the RPC application's name in parentheses, including the version number if nmap can make a credible guess at one.
Suppose we're looking for something a bit more specific. This could be because we have some idea of what the host is running and/or we wish to minimize the scan time. To specify which ports we want to see, we append the -p flag along with a list of ports. Commas and dashes, but not white space, may be used in this list. Listing 3 shows a scan in which we check all privileged ports (1-1024) plus a few high ports we're worried about, namely TCP 12345 and 12346 (NetBus' default ports) and UDP 31337 (BackOrifice's default):
Finally, because it's so easy, let's do a scan on multiple hosts. The host expression nmap accepts is even more flexible than the port expression: wild cards, square brackets (lists) and “slash/subnet-bits” notation may be used. Here's what the command would look like to perform the scan in Listing 3 on my entire test network (254 addresses, output omitted this time):
nmap -sTU -p 1-1024,12345,12346,31336 10.13.13.0/24
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- The Secret Password Is...
- RSS Feeds
- New Products
- All the articles you talked
38 min ago
- All the articles you talked
41 min 7 sec ago
- All the articles you talked
42 min 27 sec ago
5 hours 7 min ago
- Keeping track of IP address
6 hours 58 min ago
- Roll your own dynamic dns
12 hours 11 min ago
- Please correct the URL for Salt Stack's web site
15 hours 23 min ago
- Android is Linux -- why no better inter-operation
17 hours 38 min ago
- Connecting Android device to desktop Linux via USB
18 hours 6 min ago
- Find new cell phone and tablet pc
19 hours 4 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?