Nmap Development mailing list archives
Re: Some thoughts from Defcon ...
From: "Andrew A. Vladimirov" <andrew () arhont com>
Date: Thu, 14 Aug 2003 23:31:57 +0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rodrigo Rubira Branco wrote: | Hi Andrew, | | I'm a Security Responser from Firewalls.com.br and likes to know more | about your idea. | | Thank you, | | Rodrigo. | | The general idea is to build port forwarding enumeration into nmap, e.g. ~ whatever the ports forwarded by the firewall are forwarded to the same or different hosts. This is also related to finding out whether the range of evaluated IP's belongs to the same or different hosts. Lets say we have a host xxx.xxx.xxx.xxx which has ports 22 and 25 open. ~From the output of tcptraceroute or better lft (which would say ** [firewall] the next gateway may statefully inspect packets ) you suspect that this host is a firewall which forwards these ports to the sshd and sendmail behind it. Do the daemons run on the same or different box ? #hping2 xxx.xxx.xxx.xxx -c 5 -S -s 20 -p 22 --tcp-timestamp - --- xxx.xxx.xxx.xxx hping statistic --- 5 packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 33.4/34.9/35.6 ms HPING : S set, 40 headers + 0 data bytes len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=0 win=5792 rtt=35.4 ms ~ TCP timestamp: tcpts=324757788 len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=1 win=5792 rtt=33.4 ms ~ TCP timestamp: tcpts=324757887 ~ HZ seems hz=100 ~ System uptime seems: 37 days, 14 hours, 6 minutes, 18 seconds len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=2 win=5792 rtt=34.6 ms ~ TCP timestamp: tcpts=324757987 ~ HZ seems hz=100 ~ System uptime seems: 37 days, 14 hours, 6 minutes, 19 seconds len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=3 win=5792 rtt=35.2 ms ~ TCP timestamp: tcpts=324758087 ~ HZ seems hz=100 ~ System uptime seems: 37 days, 14 hours, 6 minutes, 20 seconds len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=22 flags=SA seq=4 win=5792 rtt=35.6 ms ~ TCP timestamp: tcpts=324758188 ~ HZ seems hz=100 ~ System uptime seems: 37 days, 14 hours, 6 minutes, 21 seconds #hping2 xxx.xxx.xxx.xxx -c 5 -S -s 20 -p 25 --tcp-timestamp - --- xxx.xxx.xxx.xxx hping statistic --- 5 packets tramitted, 5 packets received, 0% packet loss round-trip min/avg/max = 33.9/34.3/34.7 ms HPING xxx.xxx.xxx.xxx (eth1 xxx.xxx.xxx.xxx): S set, 40 headers + 0 data bytes len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=0 win=5792 rtt=34.2 ms ~ TCP timestamp: tcpts=1663107403 len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=1 win=5792 rtt=34.7 ms ~ TCP timestamp: tcpts=1663107914 ~ HZ seems hz=100 ~ System uptime seems: 192 days, 11 hours, 44 minutes, 39 seconds len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=2 win=5792 rtt=33.9 ms ~ TCP timestamp: tcpts=1663108426 ~ HZ seems hz=100 ~ System uptime seems: 192 days, 11 hours, 44 minutes, 44 seconds len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=3 win=5792 rtt=33.9 ms ~ TCP timestamp: tcpts=1663108938 ~ HZ seems hz=100 ~ System uptime seems: 192 days, 11 hours, 44 minutes, 49 seconds len=56 ip=xxx.xxx.xxx.xxx ttl=53 DF id=0 sport=25 flags=SA seq=4 win=5792 rtt=34.5 ms ~ TCP timestamp: tcpts=1663109450 ~ HZ seems hz=100 ~ System uptime seems: 192 days, 11 hours, 44 minutes, 54 seconds Not only the uptime is different, but also the TCP timestamp incrementation goes by a different step value (~ 100 and ~ 500). Perhaps this incrementation step difference can be used for OS fingerprinting. By the way, the incorrect (~ 500) tcpts increment machine is Red Hat 7.3 running vanilla kernel. To verify what we see above by looking at TCP ISN's lets fire ISNProber: #perl isnprober -n 10 -c xxx.xxx.xxx.xxx:22 xxx.xxx.xxx.xxx:25 - -- ISNprober / 1.02 / Tom Vandepoel (Tom.Vandepoel () ubizen com) -- Using eth1:xxx.xxx.xxx.xxx Probing host: xxx.xxx.xxx.xxx on TCP port 22. Probing host: xxx.xxx.xxx.xxx on TCP port 25. Host:port ISN Delta xxx.xxx.xxx.xxx:22 -265972978 xxx.xxx.xxx.xxx:25 -280890885 -14917907 xxx.xxx.xxx.xxx:22 -265633457 15257428 xxx.xxx.xxx.xxx:25 -280560606 -14927149 xxx.xxx.xxx.xxx:22 -265303477 15257129 xxx.xxx.xxx.xxx:25 -280220032 -14916555 xxx.xxx.xxx.xxx:22 -264962858 15257174 xxx.xxx.xxx.xxx:25 -279890905 -14928047 xxx.xxx.xxx.xxx:22 -264642219 15248686 xxx.xxx.xxx.xxx:25 -279559150 -14916931 xxx.xxx.xxx.xxx:22 -264303262 15255888 xxx.xxx.xxx.xxx:25 -279219096 -14915834 xxx.xxx.xxx.xxx:22 -263963523 15255573 xxx.xxx.xxx.xxx:25 -278878432 -14914909 xxx.xxx.xxx.xxx:22 -263623800 15254632 xxx.xxx.xxx.xxx:25 -278536914 -14913114 xxx.xxx.xxx.xxx:22 -263294106 15242808 xxx.xxx.xxx.xxx:25 -278219277 -14925171 xxx.xxx.xxx.xxx:22 -262963297 15255980 xxx.xxx.xxx.xxx:25 -277887876 -14924579 xxx.xxx.xxx.xxx:22 <> xxx.xxx.xxx.xxx:25 == [-] Voila, 2 different hosts behind the firewall. Of course there are more possible methods which are mentioned in the original letter and if they can be combined and implemented in nmap that could've been cool. Andrew P.S.: I'll forward this reply to the list as well for anyone curious or bored. - -- Dr. Andrew A. Vladimirov CISSP #34081, CWNA, CCNP/CCDP, TIA Linux+ Security Manager Arhont Ltd - Information Security. Web: http://www.arhont.com Tel: +44 (0)870 44 31337 Fax: +44 (0)1454 201200 GPG: Key ID - 0x1D312310 GPG: Server - gpg.arhont.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/PBvtlOHkKR0xIxARAsbNAKD1pnxnEOlOuA0nJW1kuC9+BdvSqgCfZMPZ THOt7g7Bj/312YoDDTmiJ9U= =52Lr -----END PGP SIGNATURE----- ---------------------------------------------------------------------For help using this (nmap-dev) mailing list, send a blank email to nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).
Current thread:
- Some thoughts from Defcon ... Andrew A. Vladimirov (Aug 14)
- Message not available
- Re: Some thoughts from Defcon ... Andrew A. Vladimirov (Aug 14)
- Re: Some thoughts from Defcon ... Philippe Biondi (Aug 18)
- Re: Some thoughts from Defcon ... Andrew A. Vladimirov (Aug 14)
- Message not available