'slow' was a little too direct, however whiny comments like yours should be downvoted to ruin too. show us the code or blog post you wrote, else stop being a little bitch. Also quote marks are for quoting ffs.
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.
# 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 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.
… or, "I'll just build my own hammer instead of using this toolbox filled to the brim with all kinds of tools."
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.
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 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.
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 because there are security professionals who do not share your opinion. And judging by the popularity of nmap, there are a lot of them.
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.
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 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.
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.
13 comments
[ 2.6 ms ] story [ 38.1 ms ] threadActual 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.
0: http://news.ycombinator.com/item?id=2317547
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.
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.