Nmap Development mailing list archives
Re: nmap+V
From: Fyodor <fyodor () insecure org>
Date: Thu, 24 Aug 2000 01:19:46 -0700 (PDT)
On Thu, 24 Aug 2000, H D Moore wrote:
There are some issues with this, namely DoS attacks caused by the 'detection' packets. An example are some wind0z3 SQL boxes that have port 6666 open, but if you make a connection to that port and send ASCII data it crashes whatever service was listening on that port.
The unfortunate fact is that many features of Nmap have occasionally been known to crash poorly written applications, TCP/IP stacks, and even operating systems (!). I won't neuter Nmap for every obsucer crash of a poorly written system, but I do try to work around it in many cases. In your example, perhaps port 6666 would be registered to try the SQL detection test first. Tests that cause common problems could be tweaked if it helps resolve these issues.
Some protocols are always in a specific state based on what data they have already received, what probe packets do you send to determine which service it is, and not inadvertently set the daemon/service into a mode where it wont respond to the same string it would if that string was the first thing you sent?
Agreed. Thats why I mentioned that multiple "isolated" tests would likely be needed. They are not just isolated in the config file grammer -- I was planning to have them use separate TCP connections as well. This helps maintainability, accuracy, and can even allow for faster speeds via test parallelization. Of course, you don't need a separate test for every service. As the previous mail (re: nessus) showed, we may be able to catch 70% (by popularity) of the ports via the first (GET /) test.
scripts/plugins/etc. Wouldn't a modularized plugin output/filtering/processing system make all of this a non-issue and allow people developing things like version and banner detection do so without needing to "taint" core nmap development?
Yes, I think a modularized plugin system could make banner & version checking a non-issue and that is one reason I have suggested we only worry about service detection. I think service detection is important because the plugions should only run against the services they were designed for. I don't want the plugin config to say: 80/tcp launch echo "GET /robots.txt HTTP/1.0\r\n\r\n" | nc $target 80 I would rather they write: http launch echo "GET /robots.txt HTTP/1.0\r\n\r\n" | nc $target $port One of the most frequent usages of Nmap is security auditing where it is critically important that people not miss vulnerabilities just because someone was running their server on a non-default port. Cheers, -F --------------------------------------------------------------------- For help using this (nmap-dev) mailing list, send a blank email to nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).
Current thread:
- Re: nmap+V Paul Tod Rieger (Aug 23)
- Re: nmap+V H D Moore (Aug 23)
- Re: nmap+V Fyodor (Aug 24)
- Re: nmap+V Ryan Permeh (Aug 24)
- Re: nmap+V Fyodor (Aug 24)
- RE: nmap+V Jay Freeman (saurik) (Aug 26)
- nmap output & processing modules H D Moore (Aug 27)
- <Possible follow-ups>
- Re: nmap+V Paul Tod Rieger (Aug 24)
- Re: nmap+V H D Moore (Aug 23)