nmap
Thursday 27th July, 2006 09:31 Comments: 1
After sending my email to the nmap-dev mailing list, I\'ve already had a few replies.
One came to me personally, and I\'ll test it in a bit when i can sit in my office (I\'ve been kicked outside as it's full today, so I\'m on the corporate network and can\'t do any scanning):
On 7/26/06, Rob Nicholls <robert@refreshdaily.com> wrote:
> Forgive me if I\'m doing something silly and haven\'t realised it, but I\'m
> getting inconsistent results when performing -sS and -sT scans against
> port 21/tcp when using win32 versions of nmap.
Does your scanning machine have Windows\' Integrated Firewall enabled?
If so it's been my experience that it will always return 21/open no
matter what IP address you scan.
Friends don\'t let friends scan from Windows.
I had a feeling I\'d get some backlash for using nmap on Windows, but it's not like I don\'t use Linux either.
I also got a reply from kx asking if I could reproduce it with the latest nmap 4.20alpha4. Well, I\'d stated in my original email that I could reproduce it with "different versions of nmap (4.01, 4.03, 4.10, 4.11, 4.20Alpha4)" but "Professor Messer" was able to confirm it, and prove I wasn\'t imagining things:
Rob -
I\'m getting the same thing in my Windows XP SP2 box with the latest nmap
4.20 alpha 4. A quick check also shows the problem in nmap 4.03 for
win32. My packet trace confirms that the -sT scan to a non-existent IP
address doesn\'t even respond to the ARP, but nmap shows port 21 as open.
If I scan a device that does exist, port 21 still incorrectly shows
open, but the trace file and nmap output show some odd things:
...
As the verbose output shows, there were some "unknown errors" and I
didn\'t get an nmap packet-trace. 11.297 seconds is a bit long, too.
...
You can see that port 21 is attempted three times, and the delta times
keep increasing. Weird one.
I got nothin\'. Anyone?
James "Professor" Messer
Author, Secrets of Network Cartography: A Comprehensive Guide to nmap
http://www.networkuptime.com/nmap
One came to me personally, and I\'ll test it in a bit when i can sit in my office (I\'ve been kicked outside as it's full today, so I\'m on the corporate network and can\'t do any scanning):
On 7/26/06, Rob Nicholls <robert@refreshdaily.com> wrote:
> Forgive me if I\'m doing something silly and haven\'t realised it, but I\'m
> getting inconsistent results when performing -sS and -sT scans against
> port 21/tcp when using win32 versions of nmap.
Does your scanning machine have Windows\' Integrated Firewall enabled?
If so it's been my experience that it will always return 21/open no
matter what IP address you scan.
Friends don\'t let friends scan from Windows.
I had a feeling I\'d get some backlash for using nmap on Windows, but it's not like I don\'t use Linux either.
I also got a reply from kx asking if I could reproduce it with the latest nmap 4.20alpha4. Well, I\'d stated in my original email that I could reproduce it with "different versions of nmap (4.01, 4.03, 4.10, 4.11, 4.20Alpha4)" but "Professor Messer" was able to confirm it, and prove I wasn\'t imagining things:
Rob -
I\'m getting the same thing in my Windows XP SP2 box with the latest nmap
4.20 alpha 4. A quick check also shows the problem in nmap 4.03 for
win32. My packet trace confirms that the -sT scan to a non-existent IP
address doesn\'t even respond to the ARP, but nmap shows port 21 as open.
If I scan a device that does exist, port 21 still incorrectly shows
open, but the trace file and nmap output show some odd things:
...
As the verbose output shows, there were some "unknown errors" and I
didn\'t get an nmap packet-trace. 11.297 seconds is a bit long, too.
...
You can see that port 21 is attempted three times, and the delta times
keep increasing. Weird one.
I got nothin\'. Anyone?
James "Professor" Messer
Author, Secrets of Network Cartography: A Comprehensive Guide to nmap
http://www.networkuptime.com/nmap
Robert - Thursday 27th July, 2006 11:15 It looks like the Windows Firewall is the culprit. When it's disabled, 21/tcp is no longer incorrectly "detected" as open. I don't know why it does it for just that one port, but at least I know the workaround to get accurate results from nmap (although dropping the firewall isn't usually a great idea, even on a fully patched box). I think I'll stick to Linux for my complete scans though, and use -sS when doing anything under Windows.