Re: [Pauldotcom] NMAP Discrepancies

[Shinnok <admin () shinnok com>]

Hi Michael,

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
further investigation:

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,
Shinnok

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
> +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:
> > > Hi,
> > >
> > > 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).
>
> Nmap 5.5.1
>
> > Thanks,
> >
> > --
> >
> > Shinnok <http://shinnok.com>

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