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 -P0


Starting 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 seconds

nmap xxx.xxx.xx.xx -p 20-22 -sS -P0


Starting 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-22


Starting 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 seconds

nmap -sT xxx.xxx.xx.xx -p 20-22


Starting 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)