Nmap Development mailing list archives

Re: Service probe for Hazelcast


From: Pavel Kankovsky <kan () dcit cz>
Date: Thu, 11 Apr 2013 20:51:03 +0200 (CEST)

On Tue, 9 Apr 2013, David Fifield wrote:

Thanks for this. Can you get us a service fingerprint as well? [...]
You are looking for the block that starts with
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============

I am unable to convince Nmap to print that particular line (maybe it does not appear unless more than one unidentified service is found?)
but I think the block you ask for is this one:

SF-Port5701-TCP:V=6.25%I=7%D=4/11%Time=516702C4%P=i686-pc-linux-gnu%r(haze
SF:lcast-bin,3,"HZC")%r(hazelcast-http,83,"HTTP/1\.1\x20200\x20OK\r\nConte
SF:nt-Length:\x2090\r\n\r\nCluster\x20\[1\]\x20{\n\tMember\x20\[127\.0\.0\
SF:.1\]:5701\x20this\n}\n\nConnectionCount:\x201\nAllConnectionCount:\x201
SF:22\n\r\n")%r(GenericLines,E,"ERROR\r\nERROR\r\n")%r(HTTPOptions,E,"ERRO
SF:R\r\nERROR\r\n")%r(RTSPRequest,E,"ERROR\r\nERROR\r\n")%r(Help,7,"ERROR\
SF:r\n")%r(SSLSessionReq,7,"ERROR\r\n")%r(Kerberos,7,"ERROR\r\n")%r(LPDStr
SF:ing,7,"ERROR\r\n")%r(SIPOptions,4D,"ERROR\r\nERROR\r\nERROR\r\nERROR\r\
SF:nERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\n");

This is how it looks when the cluster has two members:

SF-Port5701-TCP:V=6.25%I=7%D=4/11%Time=516701A6%P=i686-pc-linux-gnu%r(haze
SF:lcast-bin,3,"HZC")%r(hazelcast-http,9C,"HTTP/1\.1\x20200\x20OK\r\nConte
SF:nt-Length:\x20114\r\n\r\nCluster\x20\[2\]\x20{\n\tMember\x20\[127\.0\.0
SF:\.1\]:5701\x20this\n\tMember\x20\[127\.0\.0\.1\]:5702\n}\n\nConnectionC
SF:ount:\x201\nAllConnectionCount:\x2095\n\r\n")%r(GenericLines,E,"ERROR\r
SF:\nERROR\r\n")%r(HTTPOptions,E,"ERROR\r\nERROR\r\n")%r(RTSPRequest,E,"ER
SF:ROR\r\nERROR\r\n")%r(Help,7,"ERROR\r\n")%r(SSLSessionReq,7,"ERROR\r\n")
SF:%r(Kerberos,7,"ERROR\r\n")%r(LPDString,7,"ERROR\r\n")%r(SIPOptions,4D,"
SF:ERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\nERROR\r\
SF:nERROR\r\nERROR\r\nERROR\r\n");

I have renamed the probes to make the correspondence between probes and responses clearer:

Probe TCP hazelcast-bin q|HZC|
Probe TCP hazelcast-http q|GET /hazelcast/rest/cluster HTTP/1.0\r\n\r\n\r\n|

What's the reason for three \r\n in the first probe, rather than two?

It does not respond until it gets at least three CRLFs (it remains silent when it receives GetRequest).

BTW: I've found two identical memcached TCP probes in nmap-service-probes ($Id: nmap-service-probes 30313 2012-11-29 05:40:32Z david $ from 6.25)

Probe TCP Memcache q|stats\r\n| at line 11352
Probe TCP memcached q|stats\r\n| at line 11770

--
Pavel Kankovsky



Current thread: