about the ip header id

From: Salvatore Sanfilippo (antirezat_private)
Date: Mon Dec 14 1998 - 03:03:16 PST

  • Next message: Pavel Kankovsky: "Re: OSS nice tmp race"

    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: antirezat_private, md5330at_private
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:11 PDT