mailing list archives
Re: [Pauldotcom] NMAP Discrepancies
From: Shinnok <admin () shinnok com>
Date: Tue, 21 Jun 2011 16:59:57 +0300
I've managed to take a look at the service discrepancies issue you
experienced. I made a similar Windows setup just as yours in VMware and
tested ms-rdp 3389 and I can't reproduce your behavior.
The strange thing in your case is that Nmap should at least print
"ms-term-serv" instead of "microsoft-rdp" if the "Microsoft Terminal
Service" doesn't get identified by -sV, in the SERVICE column of the output.
I'm going to need some more info from you in order to proceed with
I need the exact Nmap line that you use to scan and confirmation that
you don't change that between scans.
I will also ask you, if you can, to try and catch a scan that does print
the wrong services or nothing at all with this nmap invocation:
nmap -p3389 -PN -sV -vvvv -dddd --version-trace *your-host*
And please attach the output to a reply e-mail. That output will at
least show us if indeed it is a timeout issue or something else.
If you happen to stumble across a reproducible case in the process,
please send details of that too.
Thanks a bunch,
On 06/06/2011 08:27 PM, Michael Lubinski wrote:
Responded in-line below. This will also happen with the following pairings
below. Maybe the service probe timeout is on par?
-88/tcp open kerberos-sec Microsoft Windows kerberos-sec
+88/tcp open tcpwrapped
-464/tcp open kpasswd5
+464/tcp open tcpwrapped
-11099/tcp open apc-agent APC PowerChute agent
+11099/tcp open unknown
-11100/tcp open apc-agent APC PowerChute agent
+11100/tcp open unknown
+464/tcp open tcpwrapped
On Mon, Jun 6, 2011 at 7:41 AM, Shinnok <admin () shinnok com> wrote:
On Mon, Jun 6, 2011 at 3:27 PM, Shinnok <admin () shinnok com> wrote:
Don't service probes have a certain timeout for the probe response? If
so then big service latency could cause that exact mismatch also.
Brief grepping revealed the following in service_scan.h:
#define DEFAULT_SERVICEWAITMS 5000
Which should be enough imho, if that's the right timeout value. Does
that value get dynamically adjusted along the scan?
Another reason could be that some services have resuming state
capabilities or don't recover that well upon sudden termination of a
connection, which means that the subsequent timely scans would get
unexpected results for the service probes.
As you probably noticed, my comment assumes that there is nothing
wrong with the service code, however, given a reproducible case that I
can poke at, I am glad to take a look at the issue.
For eg, for the microsoft-rdp case I would need Windows Version,
Server 2008 R2 Enterprise
Service Pack version, MSRDP client version,
RDP Ver 6.1.7600
Nmap version and on which
subsequent scan does Nmap stop reporting the Service for the port(the
last requirement must be somewhat reproducible).
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/