Re: non-random IP IDs

From: Crist Clark (crist.clark@globalstar.com)
Date: 04/12/01 

Date: Thu, 12 Apr 2001 12:58:58 -0700
From: "Crist Clark" <crist.clark@globalstar.com>
To: Wes Peters <wes@softweyr.com>

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
> >
> > 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

Relevant Pages

  • Re: Strange pings from 127.0.0.1
    ... I know you said the MAC address is also spoofed but this might help anyway: ... that are reporting port scans to their network all of which have a source ... Infected host picks address as source address and sends Syn packet to ... TCP/IP stack receives packet, responds with reset (if there is nothing ...
    (Security-Basics)
  • Re: Tons of Source port 80 to random Dest Port Traffic
    ... from the same consumer DSL equipment) that have a src port of 80 and a ... Host is not a proxy, just a firewalled webserver with only port 80 ... ACK is the first reply packet when attempting to establish a TCP ... From Q1, Q2, If the host is not a proxy server and there are SYN packets. ...
    (Security-Basics)
  • RE: Strange replies on closed port
    ... port should be a RST - not dropping the packet. ... receiving an UDP datagram to a non 'listening' port. ... that message isn't generated by the end host, ... Connecting to a closed Port w/o Firewall: ...
    (Pen-Test)
  • Re: UPnP Port
    ... >If you DROP all packages it doesn't tell the scanner anything, ... I guess you are saying about popular port scanner. ... is ICMP Type 3 Code 3 port unreachable packet originated your box. ... What I'm talking about is ICMP Type 3 Code 1 host unreachable (or ...
    (comp.os.linux.security)
  • Re: UPnP Port
    ... >If you DROP all packages it doesn't tell the scanner anything, ... I guess you are saying about popular port scanner. ... is ICMP Type 3 Code 3 port unreachable packet originated your box. ... What I'm talking about is ICMP Type 3 Code 1 host unreachable (or ...
    (comp.os.linux.security)