Everything, Everything

2024: January February March
2023: J F M A M J J A S O N D
2022: J F M A M J J A S O N D
2021: J F M A M J J A S O N D
2020: J F M A M J J A S O N D
2019: J F M A M J J A S O N D
2018: J F M A M J J A S O N D
2017: J F M A M J J A S O N D
2016: J F M A M J J A S O N D
2015: J F M A M J J A S O N D
2014: J F M A M J J A S O N D
2013: J F M A M J J A S O N D
2012: J F M A M J J A S O N D
2011: J F M A M J J A S O N D
2010: J F M A M J J A S O N D
2009: J F M A M J J A S O N D
2008: J F M A M J J A S O N D
2007: J F M A M J J A S O N D
2006: J F M A M J J A S O N D
2005: J F M A M J J A S O N D
2004: J F M A M J J A S O N D
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
Avatar 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.
© Robert Nicholls 2002-2024
The views and opinions expressed on this site do not represent the views of my employer.
HTML5 / CSS3