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
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space