Ultimate Nmap Scan
richrines.com
richrines.com
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 you'll figure this out yourself.
tptacek- Yeah sorry bro, we don't go and make our own tools every time something isn't just quite perfect, I don't have the time...got a real life.
Actual post: http://news.ycombinator.com/item?id=2317547
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.
# 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 they perform more or less the same function as `nmap -p T:1-65535 $IP`
edit: he also complains about performance - I'd be very surprised if the ruby script outperformed a suitable nmap command - maybe you need -T5?
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.
> 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.
I could spend a minute (or two because I don't know EventMachine well) coding that port scanner like you did in [0], or I could just type "nmap -p 1-65535 host". I think you are suffering from not invented here syndrome.
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 figure them out, because if I just use the script I can also pump my output to the exact output format I need.
I get it, by the way. You like nmap. Everyone likes nmap. Mostly. I know I'm not the only professional security person who gets frustrated with it, and I think it's interesting how not-hard it is to substitute for it if you can code even a little bit.
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 because there are security professionals who do not share your opinion. And judging by the popularity of nmap, there are a lot of them.
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.