This is a discussion on Re: dns exploit - DNS ; I'm not exactly sure what you said, but I do know that if your firewall or port forwarder is changing the source ports of outbound queries to be something predictable, or to be all the same, then you have a ...
I'm not exactly sure what you said, but I do know that if your
firewall or port forwarder is changing the source ports of outbound
queries to be something predictable, or to be all the same, then you
have a problem. The patch on your name server is not enough - you also
have to fix your firewall.
Linux iptables does not appear to change source ports.
Men & Mice
On Jul 25, 2008, at 11:30 PM, Brian Keefer wrote:
> I just looked at it a bit more closely...
> I'm using OpenBSD for my firewall and my nameservers. The firewall
> is 3.5, the nameservers are 4.3. The firewall is just doing
> standard PF nat for outbound requests. Whether I used the doxpara
> tool, or dns-oarc the source ports from my recursive resolver were
> the same (pre-patch), but on the external interface of my firewall,
> the packets to doxpara did not get randomized ports, while those to
> dns-oarc did. Post-patch the resolver itself has random source
> ports, so it's moot.
> There have been several suggestions for writing PF nat statements to
> cover this vulnerability, and other folks supposedly had luck with
> them, so perhaps something changed with PF's randomization since
> 3.5? I haven't had enough spare time to comb the commit comments...
> Dan did mention something in his blog about not having updated his
> tool to account for iptables or PF randomization, but I'm not sure
> why the tool being able to force the same source port is a bug with
> his script rather than a way to defeat said packet filter
> Brian Keefer
> Sr. Systems Engineer
> "Defend email. Protect data."