Ultimate Nmap Scan • Hacker News Board

Re: Ultimate Nmap Scan

#11

Post by tptacek » Sun, Oct 02, 2011, 12:20 AM UTC

soult wrote: post #8

tptacek wrote: post #7

Earlier quoted context omitted.

Come on. If that just worked, you don't think I'd do it? I've got as much NIH in me as the next nerd, but did you read anything I wrote in that thread, or even this article? Run that all-ports nmap against a firewalled (read: any) corporate network sometime and time it against the one-minute EventMachine script. I'm sure there's some combination of nmap flags that slaughters EventMachine, but I can't be bothered to f…

Your script sequentially scans ports 1 to 65535 of a given host. My nmap command line does the same. Fair comparison in my opinion. Of course nmap has more complicated command lines, but then again, your script would be a lot longer too if you wanted more complicated features. Yes, you are a security professional and you don't like nmap, and you have met others who feel the same way. The reason nmap is so popular is…

My script will in many circumstances outperform "yours", because nmap's default settings suck against networks that have firewalls.

That's why I brought it up.

I am not on a mission against nmap. I've met Fyodor a couple times. He's a smart guy. In fact: I even like nmap; I just think it has outgrown its role as a port scanner.

I do think it confirms a commonly held suspicion about "security" people when they recoil in horror over ~40 lines of code "reinventing the wheel" on one of the industry's hairiest tools. "Oh my god! Code!"

What I should have done is come up with a new acronym for it and then charged $30,000 for a pilot deployment to use it.

Re: Ultimate Nmap Scan

#12

Post by tptacek » Sun, Oct 02, 2011, 12:21 AM UTC

slow wrote: post #3

Wow really, spoofed Macs, fragmented packets...for what? Stealth? LOL no way not with all those flags enabled. nmap -sS -F -P0 1.2.3.4 is all you need for a scan, maybe sometimes a -sV and -O thrown in. Change the rtt settings if things are taking forever (i.e. heavily firewalled hosts). Just cause nmap has a million options doesn't mean you should use them all. Don't worry after a couple hundred scans in the wild yo…

A good way to make sure you never have to make your own tools on projects is to make fun of the very idea that you might every once in awhile make your own tools. I agree: you should probably just keep using nmap.

Re: Ultimate Nmap Scan

#13

Post by tptacek » Sun, Oct 02, 2011, 12:30 AM UTC

tmp1234123 wrote: post #10

tmp1234123 wrote: post #9

Earlier quoted context omitted.

cheers for the references, I can now read them and learn something. I stand by my argument in spite of the downvote though - whining about something and expecting everyone to have read your previous thoughts on the subject is douchey whether or not you're a hot-shot HNer.

a summary of the linked discussion: # tptacek dislikes that nmap is in C; others point out that this was not a bad language choice back when it was written # tptacek complains that nmap is more of an all-in-one tool; rcamera posts that it is also provided as smaller tools eg. ncat, nping, ncrack, etc. (pretty cool - I didn't know that) # tptacek provides about 60 line ruby script which to my untrained eyes look like…

Sigh.

I don't dislike that nmap is in C! C is my favorite language. I do think that most HN people --- who typically do not know C --- should know that nmap doesn't benefit much from being written in C, because nmap is IO-bound.

Do ncat, nping, ncrack, &c provide fast simple working port scanners? Then what do I care about them?

If it doesn't intrigue you that you can outperform nmap (in its default settings) and come close to it with carefully tuned settings with sixty lines of Ruby, I don't know what to tell you. I guess just vote me down. I think it's interesting, that's all.

Re: Ultimate Nmap Scan

#14

Post by tmp1234123 » Sun, Oct 02, 2011, 11:13 AM UTC

tptacek wrote: post #13

tmp1234123 wrote: post #10

Earlier quoted context omitted.

a summary of the linked discussion: # tptacek dislikes that nmap is in C; others point out that this was not a bad language choice back when it was written # tptacek complains that nmap is more of an all-in-one tool; rcamera posts that it is also provided as smaller tools eg. ncat, nping, ncrack, etc. (pretty cool - I didn't know that) # tptacek provides about 60 line ruby script which to my untrained eyes look like…

Sigh. I don't dislike that nmap is in C! C is my favorite language . I do think that most HN people --- who typically do not know C --- should know that nmap doesn't benefit much from being written in C, because nmap is IO-bound. Do ncat, nping, ncrack, &c provide fast simple working port scanners? Then what do I care about them? If it doesn't intrigue you that you can outperform nmap (in its default settings) and co…

Thank you for responding to my insults.

> I don't dislike that nmap is in C

I guess reading just the burgerbrain thread in the linked context I would have come to the same conclusion, that you like C and weren't criticising nmap being written in it.

Others and myself seem to be thrown off by the content of the parent to that thread, with the statement that nmap could be majorly improved upon, followed by a single paragraph stating that C is unnecessary (due to IO bound).

> Do ncat, nping, ncrack, &c provide fast simple working port scanners?

Valid point, the original comment was posted in response to the argument that nmap was too big, I reproduced it simply because I found it interesting. It shows that they have split out into different tools, but yeah nmap is still the port scanner.

Your point about it having a scripting language adds weight to the argument about it being bloated, however I'm dubious that this would add more than a few ms of performance loss, and there's always the argument that you can simply not use it.

> If it doesn't intrigue you that you can outperform nmap (in its default settings)

I don't have any excitement for the Ruby script and am disappointed to see it is exactly the same one that I or anyone else would have written when asked to scan 65535 ports. The nmap developers would be turning in their graves to see such a naive script be touted as "better performing".

I'm grateful that the nmap developers left their scanner with sane defaults so that anyone like myself can just use their tool responsibly without thinking, and then only dig into the man page if we need greater performance (-T5 amongst others, eg. --min-parallelism 10) or the linked article (-T insane).

> I think it's interesting, that's all.

Sorry, there's nothing new or interesting in that script. I've read other comments you've written which were knowledgeable and interesting, but not found that here and hope that you properly reference your criticisms in future.