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.
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
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space