Nmap Development mailing list archives
Re: False positive 21/tcp open on Windows?
From: Professor Messer <messer () spamarrest com>
Date: Wed, 26 Jul 2006 22:31:32 -0400
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: ---- C:\>nmap 192.168.0.141 -p 20-22 -sT -P0 --packet_trace -n -vv Starting Nmap 4.20ALPHA4 ( http://www.insecure.org/nmap ) at 2006-07-26 22:14 Eastern Daylight Time Initiating Connect() Scan at 22:14 Scanning 192.168.0.141 [3 ports] CONN (0.0620s) TCP localhost > 192.168.0.141:22 => Unknown error CONN (0.0620s) TCP localhost > 192.168.0.141:21 => Unknown error CONN (0.0620s) TCP localhost > 192.168.0.141:20 => Unknown error Discovered open port 21/tcp on 192.168.0.141 CONN (1.1720s) TCP localhost > 192.168.0.141:20 => Unknown error CONN (1.1720s) TCP localhost > 192.168.0.141:22 => Unknown error Completed Connect() Scan at 22:14, 11.22s elapsed (3 total ports) Host 192.168.0.141 appears to be up ... good. Interesting ports on 192.168.0.141: PORT STATE SERVICE 20/tcp filtered ftp-data 21/tcp open ftp 22/tcp filtered ssh Nmap finished: 1 IP address (1 host up) scanned in 11.297 seconds ---- 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. Here's the actual Wireshark packet trace from the nmap scan above. I deleted some non-nmap information in frame 1-5: 6 0.040889 192.168.0.6 192.168.0.1 TCP 2012 > 22 [SYN] Seq=0 Len=0 MSS=1460 7 0.000588 192.168.0.1 192.168.0.6 TCP 22 > 2012 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 8 0.004458 192.168.0.6 192.168.0.1 TCP 2016 > 21 [SYN] Seq=0 Len=0 MSS=1460 9 0.000280 192.168.0.6 192.168.0.1 TCP 2015 > 20 [SYN] Seq=0 Len=0 MSS=1460 10 0.000331 192.168.0.1 192.168.0.6 TCP 21 > 2016 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 11 0.000581 192.168.0.1 192.168.0.6 TCP 20 > 2015 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 12 1.086261 192.168.0.6 192.168.0.1 TCP 2017 > 20 [SYN] Seq=0 Len=0 MSS=1460 13 0.000609 192.168.0.1 192.168.0.6 TCP 20 > 2017 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 14 0.000685 192.168.0.6 192.168.0.1 TCP 2018 > 22 [SYN] Seq=0 Len=0 MSS=1460 15 0.000590 192.168.0.1 192.168.0.6 TCP 22 > 2018 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 16 1.877678 192.168.0.6 192.168.0.1 TCP 2016 > 21 [SYN] Seq=0 Len=0 MSS=1460 17 0.000691 192.168.0.1 192.168.0.6 TCP 21 > 2016 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 18 5.934154 192.168.0.6 192.168.0.1 TCP 2016 > 21 [SYN] Seq=0 Len=0 MSS=1460 19 0.000699 192.168.0.1 192.168.0.6 TCP 21 > 2016 [RST, ACK] Seq=0 Ack=0 Win=0 Len=0 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 Rob Nicholls 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. When performing a Connect() Scan it will return 21/tcp open, even when I know nothing is listening. Running a Connect() Scan using the linux client (or doing -sS on Windows) gives me the correct result. I used Ethereal to see what was going on, and I can't see anything being sent on port 21. nmap states "The Connect() Scan took 0.00s to scan 1 total ports." which worries me, as it shouldn't be that quick (scanning just port 20 or 22 takes 0.98s and these show up in Ethereal). I first noticed it against a VMWare virtual machine, but it seems to also happen when scanning any other host too (either systems on the same subnet at work or over the internet to a router at home - and even from a machine at home against machines at work), including hosts that I know do not exist (obviously using -P0). I've managed to reproduce this with different versions of nmap (4.01, 4.03, 4.10, 4.11, 4.20Alpha4) on three different Windows hosts (two running XP SP2, one running 2003 SP1), but the two Linux hosts (Backtrack under VMWare with a bridged network connection on one of the Windows hosts, and a proper installation of Fedora Core 3 on a standalone machine) correctly identify the port as closed. I don't think it makes any difference, but I've been using WinPcap 3.2 alpha, briefly dropped down to 3.1 and I'm now using 4.0alpha1. I scanned (from home, hence using 4.01, but the same thing happens in 4.11) my machine at work. I had Windows Firewall (XP SP2) turned on, with no exceptions allowed, so it should silently drop everything:nmap xxx.xxx.xx.xx -p 20-22 -sT -P0Starting Nmap 4.01 ( http://www.insecure.org/nmap ) at 2006-07-26 13:21 GMT Daylight Time Interesting ports on xxx.xxx.xx.xx: PORT STATE SERVICE 20/tcp filtered ftp-data 21/tcp open ftp 22/tcp filtered ssh Nmap finished: 1 IP address (1 host up) scanned in 11.390 secondsnmap xxx.xxx.xx.xx -p 20-22 -sS -P0Starting Nmap 4.01 ( http://www.insecure.org/nmap ) at 2006-07-26 13:21 GMT Daylight Time Interesting ports on xxx.xxx.xx.xx: PORT STATE SERVICE 20/tcp filtered ftp-data 21/tcp filtered ftp 22/tcp filtered ssh Nmap finished: 1 IP address (1 host up) scanned in 3.610 seconds When running scans against the current version of BackTrack (running under VMWare), I get the following:nmap -sS xxx.xxx.xx.xx -p 20-22Starting Nmap 4.11 ( http://www.insecure.org/nmap ) at 2006-07-26 13:27 GMT Standard Time Interesting ports on xxx.xxx.xx.xx: PORT STATE SERVICE 20/tcp closed ftp-data 21/tcp closed ftp 22/tcp closed ssh MAC Address: 00:0C:29:97:FA:9C (VMware) Nmap finished: 1 IP address (1 host up) scanned in 0.771 secondsnmap -sT xxx.xxx.xx.xx -p 20-22Starting Nmap 4.11 ( http://www.insecure.org/nmap ) at 2006-07-26 13:27 GMT Standard Time Interesting ports on xxx.xxx.xx.xx: PORT STATE SERVICE 20/tcp filtered ftp-data 21/tcp open ftp 22/tcp filtered ssh MAC Address: 00:0C:29:97:FA:9C (VMware) Nmap finished: 1 IP address (1 host up) scanned in 12.137 seconds Doing a quick netstat on BackTrack reveals nothing is listening. I hope that's enough info for you to work with, but this seems fairly reproducible here, and I was surprised I couldn't see anything mentioned in the mailing list archives. Which makes me think maybe it's my mistake. I hope someone else can confirm this behaviour, or let me know how I can fix this. Rob Nicholls _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
Current thread:
- False positive 21/tcp open on Windows? Rob Nicholls (Jul 26)
- Re: False positive 21/tcp open on Windows? kx (Jul 26)
- Re: False positive 21/tcp open on Windows? Professor Messer (Jul 26)
- Re: False positive 21/tcp open on Windows? Rob Nicholls (Jul 27)
- <Possible follow-ups>
- Re: False positive 21/tcp open on Windows? 4N9e Gutek (Jul 28)