> On Sun, Aug 01, 1999 at 01:10:06AM +0200, Nergal wrote: > > Now let's recall another Linux feature. Many OSes (including Linux) > > assign to ID field of an outgoing IP datagram consecutive, increasing > > numbers (we forget about fragmentation here; irrelevant in this case). That > > enables anyone to determine the number of packets sent by host A: it's enough > > to ping it, note the value of ID field of received ICMP_REPLY packet, wait x > > seconds (or perform some other actions), then again ping host A. The > > difference between ID fields of received ICMP_REPLY packets is equal to (the > > number of packets sent by A in x second) +1. "Idle portscan" by antirez uses > > this technique. > > Re, > > i think that a consecutive IP id now can be considered > a weakness in IP stacks. Using it you today are able > at least to scan spoofed, to guess host traffic and > you can use it when you need to know if the target host > of your spoofed packet answered. Here is a patch for > linux 2.0.36, maybe it isn't SMP safe so don't use it > if your linux box have more than one CPU. Note: the name > of this patch are 'True random id', however this isn't > true, a better name is 'Truly random id'. There are > a lot of 'better possible patchs' to fix this problem, but > this patch is old and writed in 30 min. so i'm interested > in your comment about how to implement a better patch. Without having done an analysis of the pseudo-random number generator in the Linux patch provided, I have a few comments to make. This situation is very similar to the resolver problem. For a reminder about the resolver issue we were solving, see http://www.openbsd.org/advisories/res_random Wow. April 22, 1997. That's before OpenBSD 2.1 was released, you know, the release that was almost impossible to install from CD... OpenBSD 2.5 solves this by using the same non-repeating random number generator that we used to solve the resolver problem. The same code simply gets moved into the kernel. Basically, you do not want to make that field random using a stock random number generator, as close repeats (same number repeated in close proximity to a previous occurance) can cause grotesque errors in fragment reassembly at the destination. The existing method of using ip_id++, avoids such problems .... as well as they can be avoided in a 16-bit identifier space. If you don't believe me, heck, just set the ip_id to 31337 each time and see how well IP de-fragmentation suddenly works.. Hence, what you really want is a pseudo random number generator which is fairly strong (in a 16 bit space, hah), but cleverly avoids re-using the same number in close proximity... I believe that this would solve your problem best. For more details, see: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_id.c?rev=1.1 In our case, this is called in the following places... netinet/ip_ip4.c: ipo->ip_id = ip_randomid(); netinet/ip_mroute.c: ip_copy->ip_id = ip_randomid(); netinet/ip_output.c: ip->ip_id = ip_randomid(); netinet/raw_ip.c: ip->ip_id = ip_randomid(); netinet6/ipv6_trans.c: ip->ip_id = ip_randomid(); Enjoy.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:55:21 PDT