Bugtraq mailing list archives
about the ip header id
From: antirez () SECLAB COM (Salvatore Sanfilippo)
Date: Mon, 14 Dec 1998 12:03:16 +0100
Hi, Several days ago, experimenting with the ip header id field, I noticed that many unix, in order to avoid ambiguity in datagram reassembly, increase the id by one for each packet sent. This makes possible to approximate the number of outgoing packets from a remote host by performing the following: - send one packet that presuppose a replies from target host - record reply's iphdr id in X - send another packet on second after the first. - record reply's iphdr in Y - if Y >= X then sent packets = Y - X - if Y < X then sent packets = (65535 - X) + Y /* id rewind */ Contrary to apparence and rtt variation it works fine. The new hping 0.66 (see my last posting in this ml) implements this, donwload it from http://www.kyuzz.org/antirez . It's still an alpha but is more powerfull than last version. This is the help screen: #./hping usage: hping host [options] c - packet count i - wait n - numeric output q - quiet I - interface name p - destination port (default 0) [ctrl+z inc, double ctrl+z dec] s - base source port (default random) t - ttl (default 64) w - winsize (default 512) h - show this help v - show version F - set FIN flag S - set SYN flag R - set RST flag P - set PUSH flag A - set ACK flag U - set URG flag X - set X unused flag (0x40) Y = set Y unused flag (0x80) f - split packets in two fragments (may pass weak acl) x - set more fragments flag (maybe useless) O - set fake tcp data offset (instead of tcphdrlen / 4) r - relativize id field (to estimate host traffic) z - bind ctrl+z to ttl Z - unbind ctrl+z As you can see this version allows you to use hping as a 'tcp specific firewalk'. -O can be used to increase raw fingerprints (i.e. win* and linux don't drop packets with wrong tcp data offset). This is an example session, if some packets are lost, hping calculates the average. # ./hping -r www.debian.org -I ppp0 HPING www.debian.org (ppp0 209.81.8.242): no flags are set, 40 data bytes 40 bytes from 209.81.8.242: flags=RA seq=0 ttl=235 id=46870 win=0 time=999.1 ms 40 bytes from 209.81.8.242: flags=RA seq=1 ttl=236 id=+58 win=0 time=899.9 ms 40 bytes from 209.81.8.242: flags=RA seq=4 ttl=236 id=+53 win=0 time=700.1 ms 40 bytes from 209.81.8.242: flags=RA seq=5 ttl=236 id=+47 win=0 time=970.1 ms 40 bytes from 209.81.8.242: flags=RA seq=6 ttl=236 id=+39 win=0 time=890.1 ms 40 bytes from 209.81.8.242: flags=RA seq=7 ttl=236 id=+61 win=0 time=770.1 ms It is possible that for some sites this information might be 'sensitive'. For example your competitors can obtain statistics about your web traffic. The two solutions that i have signled out are these: - randomize the id in the same way of tcp seq number (but without repetitions, I have an idea for a fast algorithm that may perform this work) - use distinct counters for each dest ip. (I don't think it's such so good idea) p.s. does somebody know why win* ip stack increase its id by 256? this solution can prevent the problem but may create others. bye, antirez -- Salvatore Sanfilippo Intesis SECURITY LAB Phone: +39-02-671563.1 Via Settembrini, 35 Fax: +39-02-66981953 I-20124 Milano ITALY Email: antirez () seclab com, md5330 () mclink it
Current thread:
- [SAFER-981204.DOS.1.3] Buffer Overflow in Platinum PCM 7.0 Security Research Team (Dec 03)
- Breaking into houses to steal the security systems... Was: Dr. Mudge (Dec 03)
- <Possible follow-ups>
- Re: [SAFER-981204.DOS.1.3] Buffer Overflow in Platinum PCM 7.0 robert.flannigan () PLATINUM COM (Dec 07)
- Call For Papers Marco de Vivo [UCV] (Dec 07)
- Lousy password handling in BreezeCOM Mr. SteelFire (Dec 10)
- Re: Lousy password handling in BreezeCOM Thilo Hille (Dec 10)
- NSA paper on computer security Kragen (Dec 11)
- about the ip header id Salvatore Sanfilippo (Dec 14)
- Learning security Kevin M. Myer (Dec 14)
- Administrivia Aleph One (Dec 10)
- RealSystem passwords Guy Cohen (Dec 10)
- Titan 3.0 Released Aleph One (Dec 10)
- Vulnerability in IRIX fcagent daemon SGI Security Coordinator (Dec 10)
- Linux 2.0.36: The stuff that was 'fixed quietly' [Summary] Alan Cox (Dec 10)
- Microsoft Security Bulletin (MS98-018) Aleph One (Dec 10)