Checking Your Work with Scanners, Part I (of II): nmap
nmap sports a frightening array of features designed to sneak through firewalls, avoid triggering intrusion-detection software and otherwise help the user evade detection. I feel no urge whatsoever to discuss those features here; while no doubt they have legitimate uses, I'd like to spend the remainder of this article on a few nifty features that are less obviously cracker-oriented.
Suppose you're the administrator of a large network and someone installs a server in your machine room that appears to be reachable from the Internet, in possible violation of your organization's security policy (and/or to your indignation since you weren't asked for permission). Before going on an authority-asserting rampage, you decide to first find out as much as you can about the possible risks to which your network has been exposed.
Luckily, the mystery server has an IP address scrawled on its front in purple crayon. Equally luckily, you're a righteous nmap angel of vengeance because you read “Paranoid Penguin” this month. Here are some nmap options to help you find out just what's going on.
First, what OS is this beast running? OS fingerprinting, summoned by the -O flag, may tell you. When you use -O, nmap sends packets with various TCP options set and compares the replies it receives with its OS fingerprinting database (/usr/share/nmap/nmap-os-fingerprints on my Red Hat 7.0 system). In my experience this feature works extremely well, except on MacOS 8 (which seems to stump it).
Next, are any of the active ports running services with root privileges? Obviously some services need this much privilege but many don't; if the web server on this box is running as root, someone is going to need talking to for sure. Use the -I flag to have nmap query the target's ident dæmon, whose sole purpose is to tell the world which user owns each listening service.
Can we minimize the chances an overly aggressive scan will overload the target system or the network? Oh yes. The -T flag allows us to specify a timing mode; the options are Paranoid, Sneaky, Polite, Normal, Aggressive and Insane, in increasing degree of network-unfriendliness (based on how long nmap waits between packets and whether it sends packets serially or in batches). -T Polite is a good choice if you want to go easy on your target and/or network.
How do we do a fast scan that checks for likely services without scanning all privileged ports? The -F flag tells nmap to scan only those ports listed in nmap-services. In this way, we avoid ports unlikely to yield anything interesting.
Finally, is there an easy way to save our evidence of lameness as a text file? Typing -oN filename tells nmap to write its results to a text file. If we want nmap to use HaX0r Sp3ll1ng, we can use -oS filename instead (“S” is for “Script-Kiddie-Talk”).
In Listing 4 we see the unauthorized server is accepting connections for, among other things, Secure Shell, Telnet, HTTP/SSL, LPD, X and nessus. nessus? Why, that's a security scanner. You definitely don't want internet hosts able to reach a nessus server on your network—that just happens to be the topic of next month's column.
As powerful as nmap is, nessus gives us a means of going a step further and probing all these listening-ports nmap has found for known weaknesses. Again, we'll focus on using these powerful tools for good rather than evil; in the meantime, I hope you'll do the same with nmap.
|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|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- 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?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
37 min 41 sec ago
- Keeping track of IP address
2 hours 28 min ago
- Roll your own dynamic dns
7 hours 42 min ago
- Please correct the URL for Salt Stack's web site
10 hours 53 min ago
- Android is Linux -- why no better inter-operation
13 hours 8 min ago
- Connecting Android device to desktop Linux via USB
13 hours 37 min ago
- Find new cell phone and tablet pc
14 hours 35 min ago
16 hours 4 min ago
- Automatically updating Guest Additions
17 hours 12 min ago
- I like your topic on android
17 hours 59 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?