Re: service misidentification

[Daniel Miller <bonsaiviking () gmail com>]

Josh,

Unfortunately, no. Removing the `sslports 3389` line will not make any
difference in the detection of RDP on nonstandard ports. I guess that you
may have a different change also in the file, such as adding 33896 to the
`ports` line of the TerminalServer probe.

What we really need in order to solve this problem is a probe that matches
(or approximates) the first message sent by an RDP client *within* the TLS
tunnel. It looks like the one sent by libfreerdp is 432 encrypted bytes,
but I'm sure we could pare that down. It does not appear to be a regular
RDP_NEG_REQ message, since that gets rejected, no matter what protocols I
add to it.

If we had that probe, we could correctly identify the service even if the
TLS probe matches first (which it does currently, because TLS is more
likely to be discovered than RDP on some unusual port).

Dan

On Wed, Jun 29, 2016 at 12:43 PM, Josh Amishav-Zlatin <jamuse () gmail com>
wrote:

> Just to follow up, I can confirm that the original patch (in r35935) fixed
> the issue when Terminal Server is running on port 3389. However, when
> Terminal Server is running on a non-standard port, nmap r35937 still flags
> the server as 'ssl/unknown'. I was able to fix this issue by removing
> 'sslports 3389' from line 13221 in nmap-service-probes.
>
> - Josh
> Hi Dan,
>
> FWIW, r35935 did not fix the issue. To fix the bug I had to apply the
> following patch to nmap-service-probes as well.
>
> 13220a13221
> > sslports 3389
>
> Thanks!
>
> - Josh
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/