Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Nmap Network Scanning 125

brothke writes "The 1962 song Wipe Out, with its energetic drum solo started, was the impetus for many people to take up playing the drums. Similarly, Nmap, the legendary network scanner, likely interested many in the art of hacking, and for some, started a career for security professionals and hackers. Nmap and its creator Fyodor need no introduction to anyone on Slashdot. With that, Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, is a most useful guide to anyone interested in fully utilizing Nmap." Read on for the rest of Ben's review.
Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning
author Gordon Lyon (Fyodor)
pages 468
publisher Nmap Project
rating 9
reviewer Ben Rothke
ISBN 978-0979958717
summary Valuable book about an invaluable security tool
One may ask, why spend $50 on this book, when the Nmap Reference Guide provides a significant amount of the basic information needed to use the tool, especially since the reference guide is both free, and well written. The reference guide is included in the book in chapter 15, and takes up 41 pages. And for those that are cash strapped, the free reference guide is the way to go.

In addition, the web site for the book notes that about half of the content is available in the free online edition. The most useful information is in the book in chapters exclusive to the print edition, which includes Detecting and Subverting Firewalls and Intrusion Detection System, Optimizing Nmap Performance, Port Scanning Techniques and Algorithms, Host Discovery, and troubleshooting.

The main benefit of the buying the book is that it has the collected wisdom of Fyodor's, in addition to numerous real-world scenarios, and Nmap commands not documented elsewhere. At over 400 pages, the books 15 chapters provide the reader with everything they need to know about using Nmap to the fullest.

Chapter 1 starts with an overview of the history of Nmap and how it came to be. As to the question of whether port scanning is legal, the author writes that it is best to avoid the debate and its associated analogies. He advises that it's best to avoid ISP abuse reports and criminal charges, by not annoying the target network administrators in the first place. Chapter 1 provides a number of practical suggestions on just how to do that.

A complaint against Nmap it that is has often been blamed for crashing systems. Chapter 1 shows that the reality is that Nmap will rarely be the primary cause of a system crash. The truth is that many of the systems that crashed as a result of an Nmap scan were likely unstable from the outset, and Nmap either pushed them over the top or they coincidentally crashed at the same time as the Nmap scan.

An ironic incident detailed in chapter 3 is when someone from the information security department of Target Corp. complained to the author that he felt the Nmap documentation was particularly directed at his organization; given the use of the term target. He requested that the Nmap documentation be changed from targetto example. The section on target enumeration in the book shows the author did not take that request to heart.

Another example of where the book goes beyond what is in the reference guide is where the author shows the most valuable TCP ports via his probe of tens of millions of IP addresses across the internet. Not surprisingly, ports 80 23 and 443 were the top three most commonly open TCP ports. It is surprising that other ports, which should have been secured long ago, are still as vulnerable as ever.

For the serious Nmap user, the book is worth purchasing just for the indispensable information in chapter 16, which is about optimizing Nmap performance. The author writes that one of his highest priorities in the creation of Nmap has been performance. Nmap uses parallelism and numerous advanced algorithms to execute its blazingly fast scans. This chapter shows how to create Nmap commands to obtain only the information you care about and significantly sped up the scan. The chapter details numerous scan time reduction techniques, and strategies on how to deal with long scans. The chapter concludes with the output of a user who, with a customized Nmap command, was able to reduce his scan of a 676,352 IP address network from nearly a week to 46 hours.

Chapter 10 is also a fascinating chapter on the topic of detection and subverting of firewalls and IDS. The function of such tests on an internal network is to help an organization understand the dangers and risks of a real attack. Since it is not uncommon for firewalls to be accidentally misconfigured, or have rule bases that leak from far too many rules; such a test can be quite useful to any network.

Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning is the guide for anyone who wants to get more out of Nmap. It is useful whether one is a novice and only getting into basic security testing, or an advanced user looking for ways to optimize Nmap.

The book takes a real-world approach on how to use the tool and clearly documents every Nmap feature and option. It also shows how the tool should be correctly used in various settings.

What is unique about is that this is a rare book in which the creator of the program wrote it. Linus Torvalds never got around to writing a Linux reference, nor did the creators of the Check Point firewall. In Nmap Network Scanning, the reader gets the story from the creator of the code itself. This then is the ultimate Nmap reference guide.

Aside from the history and use of the program in the first chapter, the rest of the book is an extreme guide to maximizing the use of Nmap. It is written by a programmer and written for the technically astute. Anyone who wants to maximize their use of Nmap will find no better reference.

Ben Rothke manages the Bright Hub Enterprise Security channel and is the author of Computer Security: 20 Things Every Employee Should Know.

You can purchase Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.


This discussion has been archived. No new comments can be posted.

Nmap Network Scanning

Comments Filter:
  • matrix reloaded (Score:5, Interesting)

    by circletimessquare ( 444983 ) <circletimessquare@nOSpaM.gmail.com> on Monday December 08, 2008 @03:27PM (#26037593) Homepage Journal

    while mostly being a steaming pile of shit compared to the original, it attempts to redeem itself by accurately using nmap in one scene

    http://www.theregister.co.uk/2003/05/16/matrix_sequel_has_hacker_cred/ [theregister.co.uk]

    That's exactly how the fictional Trinity uses it. In a sequence that flashes on screen for a few scant seconds, the green phosphor text of Trinity's computer clearly shows Nmap being run against the IP address, and finding an open port number 22, correctly identified as the SSH service used to log into computers remotely.

    "I was definitely pretty excited when I saw it," says "Fyodor," the 25-year-old author of Nmap. "I think compared to previous movies that had any kind of hacking content, you could generally assume it's going to be some kind of stupid 3D graphics show."

  • Network map? (Score:2, Interesting)

    by Anonymous Coward on Monday December 08, 2008 @04:34PM (#26038569)

    Have they included a network mapping function yet? They announced it as a GSoC project last year I think, did they get around to hack some graphical map output?

  • by tabrisnet ( 722816 ) on Monday December 08, 2008 @04:36PM (#26038589)

    Happened to me in college at gvsu.edu. They claimed I had crashed several Solaris boxen, and claimed that my Linux box was 'dangerous', and even cut off my network access.

    The kicker was the 150 hours of community service I had to put in to pay for the time (of 'computer professionals' who were worth a lot more money than I was) it took to bring them back online.

    And to think, I was only trying to map out the campus network and what systems they used for various purposes.

  • by digitalhermit ( 113459 ) on Monday December 08, 2008 @04:39PM (#26038639) Homepage

    I used to work at a (now defunct) flower company. My office was glass walled, overlooking the entire sales floor. One day I was testing Samba on a small desktop machine. I remember starting up nmbd/smbd. Then moments later, I looked into the sales pit and saw people getting up, the Win95 workstations had begun to bluescreen one by one. I didn't connect the two.

    A half hour later everyone has rebooted. In that time I'd turned off Samba to work on something else. I restart Samba on that little machine (it was called Stargate because it would act as a gateway to some shares on a Sun E6500). The moment I press enter, the machines start bluescreening again. I realized just at that moment what happened and immediately shut it down.

  • Re:In college... (Score:3, Interesting)

    by X0563511 ( 793323 ) on Monday December 08, 2008 @04:55PM (#26038833) Homepage Journal

    Darwin at work. Let them be caught ;)

  • nmap and IPv6 (Score:4, Interesting)

    by swillden ( 191260 ) <shawn-ds@willden.org> on Monday December 08, 2008 @07:58PM (#26041381) Homepage Journal

    This is tangentially related, but it sort of fits in with the idea of "cools ways to use nmap" -- or, in this case "things you can't do with nmap".

    While setting up a 6to4 tunnel to give my home LAN IPv6 access (just for fun), I decided to use nmap to scan my home IPv6 network. I've used nmap from time to time to portscan, but mostly I use it as a ping scanner, just to find live hosts, so it seemed like a natural way to find out which hosts had picked up IPv6 addresses.

    I first tried the obvious syntax "nmap -sP <my subnet prefix>::/64", but nmap told me that slashes are not allowed, and that "IPv6 addresses can currently only be specified individually".

    My first reaction was "Well, that's stupid. Why can't nmap handle IPv6 subnets? Idiots". However, a half-second later it occurred to me that I was the idiot: what I thought I wanted nmap to do was to scan 18,446,744,073,709,551,616 addresses. That's obviously impractical. That many requests would saturate a 10 Gbps network for 60,000 years (2^64 128-byte packets).

    So, FYI, if you want to find out what hosts are live on your IPv6 network, the way to do it is to ping the link-local multicast address (fe02::1). Assuming they're not firewalled, all of the hosts will answer. Of course, what you'll get back is their link-local addresses, not their routable addresses. I haven't found a convenient way to get a list of those, other than a little sed script to convert the link-local addresses to their equivalents in the subnet.

Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms.