Closed chushuai closed 3 years ago
Can we do a simple service identification before grab the data,that way, you can grab the SSH service on port 3306,I want to know the possibility of this idea?
This could be achieved by doing your "service probe" in a separate process, and then pipe the output to zgrab2 using the appropriate port / protocol; something like
send-service-probes --range=192.168.1.0/8 --ports=3306 --probe=ssh | zgrab2 ssh --port=3306
where send-service-probes
would be whatever you use to perform those probes.
Unfortunately, scans can currently only cover a single port (though the multiple command system and recently added "tags/triggers" could serve this purpose if you have just a few target ports).
i known ,also on port 22 A service identification program maybe output as : 192.168.1.100,www.x.com,http 192.168.1.101,,telnet 192.168.1.102,,mysql 192.168.1.103,,ssh 192.168.1.105,,ssh 192.168.1.106,domain,rdp to zgrab2 ssh --port=22 Unfortunately I didn't find a particularly fast service identification program i can use zmap as port scan but i also need a service identification program an then use zgrab to grab data
zmap ---> service identification program--->zgrab @justinbastress
It would be very nice if zmap can create a repo and do something about service identification. Currently we can only get service run in standard port. But it won't be too hard for us to identifi a service which is not in standard port. for example. A unknown service run at port 24. we just send a socket and a simple hello message. It will return 'SSH-2.0-OpenSSH_7.2p2 xxx' if it is ssh will return '8.0.1S\r3co�����a~7=-:2 knJmysql_native_password��Got packets out of order%' if it is mysql.
LZR has been introduced to address this problem: https://github.com/stanford-esrg/lzr.
Identify services through profiles, as well as data grab from nmap-service-probes ##############################NEXT PROBE##############################
DTLS Client Hello. Dissection available in nmap-payloads
Probe UDP DTLSSessionReq q|\x16\xfe\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x36\x01\x00\x00\x2a\x00\x00\x00\x00\x00\x00\x00\x2a\xfe\xfd\x00\x00\x00\x00\x7c\x77\x40\x1e\x8a\xc8\x22\xa0\xa0\x18\xff\x93\x08\xca\xac\x0a\x64\x2f\xc9\x22\x64\xbc\x08\xa8\x16\x89\x19\x30\x00\x00\x00\x02\x00\x2f\x01\x00| rarity 5 ports 443,4433,4740,5349,5684,6514,6636,10161,10162
OpenSSL 1.1.0 s_server -dtls -listen
HelloVerifyRequest always uses DTLS 1.1 version, per RFC 6347
match dtls m|^\x16\xfe\xff\0\0\0\0\0\0\0\0..\x03...\0\0\0\0\0...\xfe\xff.|
##############################NEXT PROBE##############################
Detects iperf3 servers by sending a string longer than the 37-byte test identifer or cookie
https://github.com/esnet/iperf/wiki/IperfProtocolStates#test-initiation
Probe TCP iperf3 q|0000000000000000000000000000000000000\0\0\0\0| ports 5201 rarity 9 match iperf3 m|^\t$|
##############################NEXT PROBE##############################
QUIC initialization with random CID, advertising version Q999, which should elicit a version negotiation packet from the server
Probe UDP QUIC q|\r\x89\xc1\x9c\x1c*\xff\xfc\xf1Q999\x00| ports 80,443 rarity 6
softmatch quic m|^\r\x89\xc1\x9c\x1c*\xff\xfc\xf1((?:Q[0-8]\d\d)+)$| i/QUIC versions$SUBST(1,"Q",", Q")/