OpenBSD Journal

OpenBSD defeats NAT detection with random IP IDs

Contributed by jose on from the veen-more-cool-things-with-PF dept.

(anonymous) writes: 


"List:     openbsd-cvs
Subject:  CVS: cvs.openbsd.org: src
From:     Daniel Hartmeier


Date:     2003-02-08 20:13:20

CVSROOT:	/cvs
Module name:	src
Changes by:	dhartmei@cvs.openbsd.org	2003/02/08 13:13:20

Modified files:
	share/man/man5 : pf.conf.5 
	sys/net        : pfvar.h pf_norm.c 
	sbin/pfctl     : parse.y pfctl_parser.c 

Log message:
Add scrub option 'random-id', which replaces IP IDs with random values
for outgoing packets that are not fragmented (after reassembly), to
compensate for predictable IDs generated by some hosts, and defeat
fingerprinting and NAT detection as described in the Bellovin paper
http://www.research.att.com/~smb/papers/fnat.pdf.
ok theo@
Link: CVS commit

Paper on NAT detection by Steven Bellovin "

Very cool, now PF can do even more work on securing boxes behind a PF device. Be sure to test this and make sure it doesn't break anything (I think Daniel read the RFCs for a long time before making this commit).

(Comments are closed)

Comments
  1. Comments

    1. By anders () on

      and you wonder why we love openbsd? :)

    2. By Daniel Hartmeier () daniel@benzedrine.cx on http://www.benzedrine.cx/pf.html

      Yes, I forgot to mention that it was indeed Dries that brought this to our attention first. Thanks, Dries :)

  2. By Shane () on

    I thought OpenBSD wasn't affected by the means of detection described in the paper? I admit that I didn't read the paper, but I remember reading comments about OpenBSD not being affected.

    Comments

    1. By danimal () on

      OpenBSD itself isn't affected by it, but hosts that are behind the firewall might be.

      Comments

      1. By Shane () on

        Right, but I thought modulate state took care of the hidden hosts?

        Comments

        1. By zil0g () on

          not for the IP ids.

          Comments

          1. By jolan () on

            Only the ISNs.

            Comments

            1. By Anonymous Coward () on

              good god...tag-team answers...

    3. By Daniel Hartmeier () daniel@benzedrine.cx on mailto:daniel@benzedrine.cx

      OpenBSD hosts already generate random IP identification values, so if all your hosts are running OpenBSD, there's no reason to use the new feature.

      But if you're NATing for several non-OpenBSD hosts which use weak id generation (like the classic 'increment by one' algorithm), your uplink (or an external host) can analyze the ids and deduce the number of hosts.

      There seem to be a number of ISPs which prohibit the use of NAT in their AUPs, and IP ids would be one way for them to come to the conclusion that someone is using NAT. While I wouldn't recommend anyone to violate his ISPs AUP, I do think such policies are misguided and technically not enforcable. random-id is meant to illustrate that point. :)

      There's also certain attacks basing on predictable IP ids, so randomizing ids for weak stacks has perfectly legitimate uses as well.

    4. By Shane J Pearson () on

      I thought OpenBSD wasn't affected by the means of detection described in the paper? I admit that I didn't read the paper, but I remember reading comments about OpenBSD not being affected.

      Do yourself a favour and read these papers before reading comments made by others. Did you hear these things at /.? /. can be a time sink and this time is much better spent anywhere else.

  3. By Jason Dixon () jwdixon ONE at YAHOO dot com on mailto:jwdixon ONE at YAHOO dot com

    Daniel, you rock. Thanks for coming through again. :)

    -J.

  4. By Matt () on

    Thanks for all your hard work (and such a quick fix!)

  5. By Anonymous Coward () on

    My favorite part in the Bellovin paper is where he points at that he's got to boxes on his desk that can communicate at 78MBps... like "yeah bitch, I've got a cool desk!"

    Bastard...

    Comments

    1. By Anonymous Coward () on

      100BaseTX can easily give 78Mbps throughput

      and gigabit over copper can do 10 times that - at a cost that i am almost willing to pay.

      Comments

      1. By zil0g () on

        the cost for the NICs are virtually the same (not counting our beloved RealTeks ;)

  6. By Anonymous Coward () on

    I thought we weren't supposed to use Security Through Obscurity?

    Isn't this kind of a weak move?

    Comments

    1. By djm () on

      If it is obscurity from Cable Internet providers who disallow NAT, then I'm all for it :)

    2. By Anonymous Coward () on

      The subject line says it all.

    3. By tedu () on

      you should stop using passwords. especially obscure hard-to-guess ones. :)

      there are a variety of existing protocols that rely on "STO", and where increasing obscurity is a good thing.

      obscurity is not security. but security is obscurity. now ponder.

    4. By Anonymous Coward () on

      This is not security through obscurity. IP IDs are not meant as a form of security; unfortunately a weak IP ID generator can be abused, sort of like how an open relay or an open proxy can be, though the technical details are different. This patch makes that impossible: it protects a weak IP ID generator (e.g., Windows) by replacing the IDs with strongly generated ones (such as OpenBSD itself uses).

      A better solution would be to replace all the weak IP ID generators with strong ones, but this is impractical. As it is, this is sort of like having a VPN concentrator.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]