full-disclosure - Re: DNS and NAT (was: DNS and CheckPoint)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Mon, 14 Jul 2008 16:13:28 -0400
From: Thomas Cross <tcross@...ibm.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: DNS and NAT (was: DNS and CheckPoint)

Huzeyfe ONAL wrote me to mention that he had tested OpenBSD's pf and found
that it was assigning random ports for every new connection. Some
references [1], [2] seem to confirm this. The interesting thing about this
approach is that it may protect vulnerable DNS servers from attack if they
are placed behind it.

Also, a coworker directed me to this really excellent Internet Draft on
port randomization:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt

[1]
http://www.openbsd.org/papers/asiabsdcon07-network_randomness/mgp00020.html
[2] http://www.openbsd.org/faq/pf/nat.html (note the mention of source port
randomization)

             "Riad S. Wahby"                                               
             <rsw@...t.org>                                                
                                                                        To 
             07/10/2008 11:06          Thomas Cross/Atlanta/IBM@...US      
             PM                                                         cc 
                                       full-disclosure@...ts.grok.org.uk   
                                                                   Subject 
                                       Re: DNS and NAT (was: DNS and       
                                       CheckPoint)                         

Thomas Cross <tcross@...ibm.com> wrote:
>    We've also been wondering whether NAT devices ought to randomly assign
>    UDP source ports, although no NAT vendor that wea**re aware of has
done
>    this to date.

Some quick testing implies that ipchains MASQUERADE-based NAT doesn't
suffer this problem because it preserves the source port.

My test setup is as follows: call the computer inside the NAT Alice, and
the computer outside Bob.  Alice contacts Bob via Trent, a linux-based
router, in my case a DLink DSL-2540B DSL modem / router combo.  On
Alice, I run the following:

( for j in $(seq 1 100); do i=$RANDOM; /bin/echo -n "$i "; echo $i | nc -q
0 -vv -p $i -u <Bob> 5555; sleep 1; done ) &> foo.Alice

On Bob, I run

( while true; do nc -vv -l -u -p 5555 -q 0 </dev/null; done ) &> foo.Bob

At the end, I compare the actual source port in foo.Alice to the
apparent source port in foo.Bob.  In my setup, they are always
identical.

Obviously it is impossible to guarantee that this will always be the
case; in order to identify dangerous corner cases one would have to
consult the ipchains code, but given the relative frailty of the
randomized source port / randomized sequence number solution, for a
small number of computers behind a NAT (e.g., home users) I claim that's
a second-order danger at best.

In a large production environment where there is a huge amount of NAT
traffic being generated one would do well to consider a solution like
Thomas's suggestion that the servers be moved outside the firewall.

-=rsw

Content of type "text/html" skipped

Download attachment "graycol.gif" of type "image/gif" (105 bytes)

Download attachment "pic11548.gif" of type "image/gif" (1255 bytes)

Download attachment "ecblank.gif" of type "image/gif" (45 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/