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
| ||
|
Date: Fri, 11 Jul 2008 13:47:50 -0400 From: "Elazar Broad" <elazar@...hmail.com> To: rsw@...t.org, tcross@...ibm.com Cc: full-disclosure@...ts.grok.org.uk Subject: Re: DNS and NAT (was: DNS and CheckPoint) I can confirm the same behavior on a Cisco PIX 501 running 6.3(5). Port numbers are incremented sequentially by one... On Fri, 11 Jul 2008 11:01:33 -0400 Thomas Cross <tcross@...ibm.com> wrote: >Riad, > > Thanks for testing this. A number of other readers wrote me >privately >confirming your result with linux ipchains. I'm not sure what >ipchains does >when it encounters a collision, but in general I think this is a >good >strategy. You'd have to have many thousands of simultaneous UDP >transactions in order for randomly selected source ports to be >colliding >frequently enough for it to present a substantial problem. > On the other hand, I've also been contacted by readers who >confirm that >other devices besides the one imipack mentioned share it's >behavior. There >appears to be room for some research here into what collision >avoidance >strategies are employed by different NAT devices, what happens to >those >devices under high load, and what the security implications are. >Fortunately, Linux appears to do a good job with this right now, >and >provides an example approach that NAT vendors can look to. > I'll post more if I have time to dig into this in further >detail. > >Regards, >Tom Cross >IBM X-Force > > > > > > "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 -- Summer Spa Sweepstakes Enter for your chance to WIN a Summer Spa Vacation! http://tagline.hushmail.com/fc/JKFkuIjyZ14QRD38TWPhUMvEMpQVnOiPyd0fdp5F6wKWqgqAzEOhQE/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists