Re: False positive 21/tcp open on Windows?

[4N9e Gutek <4n9e () futurezone biz>]

This problem is not a scan engine issue, it comes from the
OS used to perform the scan, especially on the first hand
the connect() system call, and on the other hand the
particular rules of the XP's firewall.
You can experiment the same issue with performing a pentest
from an online scan engine against a win machine.

Quoting the Nmap's man page, we can read that "Instead of
writing raw packets as most other scan types do, Nmap asks
the underlying operating system to establish a connection
with the target machine and port by issuing the connect()
system call. (...) Nmap uses this API to obtain status
information on each connection attempt. (...) The system
call completes connections to open target ports rather than
performing the half-open reset that SYN scan does."

Because the scan engine (here Nmap, but anything else as
well) is trully dependant from this system call, this is
why "When performing a Connect()
Scan it will return 21/tcp open", and "doing -sS on Windows
gives me the correct result".
Another issue on a win machine filtered with XP's firewall
is the fact that when sending a probe to port 20,21 or 22
throught a TCP connect() scan (so, high-level system call),
the RST answer wich Nmap would translate as a "closed" port
is dumped by the firewall. "If no response is received
after several retransmissions, the port is marked as
filtered. The port is also marked filtered if an ICMP
unreachable error (type 3, code 1,2, 3, 9, 10, or 13) is
received." (also quoted from the man page).

Scanning from a Windows machine, what's more throught
Microsoft's firewall, is definitively a bad idea. Many
problems as well as false positives may occur because of
Microsoft's strange use of the RFC's and occults system
rules and processes.

Gutek.




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev