North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: sniffer/promisc detector
On Wed, Jan 21, 2004 at 09:04:40AM -0800, Alexei Roudnev wrote: > > Please, do it: > > time nmap -p 0-65535 $target > > You will be surprised (and nmap will not report applications; to test a > response, multiply time at 5 ). And you will have approx. 40% of packets > lost. > > Practically, nmap is useless for this purpose. Oh, really? I'll do a quick test of your theory that Nmap will be slow with a 65K port scan, miss 40% of the open ports due to packet loss, and not be able to report the application/services running on the port. I may be biased, but anyone who wants to can reproduce this test (at the risk of pissing off SCO, who admittedly are rather litigous). To be even more fair, I'll run the scan from a 128kbps-upstream aDSL line: # nmap -sSV -T4 -O -p0-65535 apollo.sco.com WARNING: Scanning "port 0" is supported, but unusual. Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-01-22 00:49 PST Interesting ports on apollo.sco.com (188.8.131.52): (The 65524 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 0/tcp filtered unknown 21/tcp open ftp WU-FTPD 2.1WU(1)+SCO-2.6.1+-sec 22/tcp open ssh SSH 1.2.22 (protocol 1.5) 199/tcp open smux? 457/tcp open http NCSA httpd 1.3 615/tcp open http NCSA httpd 1.5 1035/tcp filtered unknown 1521/tcp open oracle-tns Oracle DB Listener 184.108.40.206.0 (for SCO System V/386) 13722/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpjava-msvc: No such file or directory) 13782/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpcd: No such file or directory) 13783/tcp open inetd inetd (failed to exec /usr/openv/bin/vopied: No such file or directory) 64206/tcp open unknown Device type: general purpose Running: SCO UnixWare OS details: SCO UnixWare 7.0.0 or OpenServer 5.0.4-5.0.6 Nmap run completed -- 1 IP address (1 host up) scanned in 501.897 seconds # So the full 65K port scan, plus OS and version detection took a little over 8 minutes over a relatively slow connection. I ran it several times to ensure ports weren't being missed. A quick test from my colocated machine took 3 minutes. And it isn't like I had to watch the whole time -- I was surfing a porn site in another window while it ran. The services would have still been detected on different ports as the same probes are done. I don't think using nonstandard ports will help against any but the most marginal attackers and worms. But if those are a serious problem, perhaps more time should be spent patching rather than moving vulnerable services to unusual ports. I am not saying you won't get _any_ benefit at all from this obfuscation, but I seriously doubt it will be worth the headaches. If ports don't have to be reachable from the outside, filter them at your firewall/router. If outsiders do need to reach the ports, moving them around will just be a pain in the @#$ for those legitimate users. You'll find that your own users are the ones port scanning you in order to locate the services you've hidden. Cheers, Fyodor http://www.insecure.org PS: Yes, the scan would have been much slower if that host had a "default deny" policy, but would not have been outrageous. You are permitted to scan "scanme.insecure.org" to test that scenario. The time taken is not unreasonable, when I run 65K scans against large heavily filtered networks, I usually just let it run overnight.