Date: Thu, 12 Apr 2001 12:58:58 -0700 From: "Crist Clark" <crist.clark@globalstar.com> To: Wes Peters <wes@softweyr.com> Cc: Mike Silbersack <silby@silby.com>, Rob Simmons <rsimmons@wlcg.com>, Mark T Roberts <newsletter@marktroberts.com>, freebsd-security@FreeBSD.ORG Subject: Re: non-random IP IDs Message-ID: <3AD60902.D6134503@globalstar.com> References: <Pine.BSF.4.31.0104121046150.3325-100000@achilles.silby.com> <3AD5F274.547D0350@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wes Peters wrote: > > Mike Silbersack wrote: > > > > On Thu, 12 Apr 2001, Rob Simmons wrote: > > > > > On Thu, 12 Apr 2001, Mike Silbersack wrote: > > > > > > > Each IP packet sent has with it a 16-bit ID. The numbers must remain > > > > unique over a short period of time so fragmentation can work properly. As > > > > such, everything except recent openbsds simple increments the id by 1 for > > > > each packet sent out. > > > > > > What is the behavior of OpenBSD for this? If its not important, why would > > > they change it? > > > > They generate pseudo-random, nonrepeating ids. For the actual algorithm, > > see: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=openbsd > > > > Although it's nice in theory, the amount of work required to generate the > > ids seems too great to justify for each packet sent. (Note that I said > > "seems", I'm not sure if anyone has done actual benchmarks to determine > > the actual impact.) > > Just like TCP sequence numbers, non-predictable IP IDs are *supposed to* > make it somewhat harder to insert bogus fragments into a packet stream. > If you are a router, this won't make a bit of difference in your ability > to frag a packet and stick whatever data you want into it; if you are > not a router your ability to see a fragmented packet go by and inject > other frags into it is almost non-existant anyhow, so I don't see much > value in this. It's mostly just in fitting with the OpenBSD "deny them > everything" approach. If you can see the stream, you can presumably read the IP ID on the actual packets and forge them without knowing the IP ID ahead of time. Using incrementing ones _maybe_ just buys the attacker a few microseconds of time since he has to analyze the stream anyway to inject data where he wants. There are much easier attacks when you can see the whole stream and inject packets. Actually, I think the vunlnerability most people think of first is doing stealthy port scans. For example, if you have a low volume host with one port open, you can access the port and read the IP ID. You can then spoof a packet to another port on the host. You never see the response, or lack thereof, to the spoofed scan. However, you hit the open port again and check the IP ID. If it has not incremented, the host or a firewall in between probably dropped the scan packet. If the IP ID has incremented, the host likely generated a response (either a SYN-ACK, RST, ICMP unreach, etc.) which went off to the spoofed address. Depending on what kind of scan you are spoofing, you can make a pretty good guess at what a response or lack of a response implies about the port's status. The attacker hides his activity by doing something not at all hostile looking (e.g. HTTP requests) as he does the scan. Of course if this is a _really_ low traffic host, the administrator of the box might note that the HTTP access corresponded to these scans coming from another host (if no one is looking at the logs for scans in the first place, why bother being stealthy). But in the case where the firewall administrator and the HTTP daemon administrator are different people, or perhaps even when the HTTP host is not busy, but the firewall is, this activity might be better obfuscated. But yes, the question of whether the effort, the complexity added to the kernel, and the CPU cycles needed for randomization are worth the reduced risk of attack, IMHO, does not have a clear cut answer. -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AD60902.D6134503>