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:
- Service probe for Hazelcast Pavel Kankovsky (Apr 03)
- Re: Service probe for Hazelcast David Fifield (Apr 09)
- Re: Service probe for Hazelcast Pavel Kankovsky (Apr 11)
- Re: Service probe for Hazelcast David Fifield (Apr 27)
- Re: Service probe for Hazelcast Pavel Kankovsky (Apr 11)
- Re: Service probe for Hazelcast David Fifield (Apr 09)