Thanks Kevin, didn't know if doing random with iptables was going to make it
harder to guess instead of just using the new bind with port randomization.

So at this point I'm assuming that aside from using secure zones, using the
new bind is all that can be done?

paul

P.A > -----Original Message-----
P.A > From: bind-users-bounce@isc.org [mailto:bind-users-bounce@isc.org] On
P.A > Behalf Of Kevin Darcy
P.A > Sent: Tuesday, August 12, 2008 12:53 AM
P.A > To: bind-users@isc.org
P.A > Subject: Re: iptables and bind
P.A >
P.A > Paul A wrote:
P.A > > Hi, sorry if this has been asked before but will using iptables to
P.A > randomize
P.A > > source ports further help prevent cache poison?
P.A > > I have a Bind 9 server that is and authoritative/cache server.
P.A > > Where can I find some examples of iptables rules being used with
P.A > random
P.A > > port/rate limits?
P.A > > I tried using iptables with the random options but I get, iptables
P.A > v1.2.11:
P.A > > Unknown arg `--random'.
P.A > >
P.A > > Using BIND 9.4.3b2 with iptables v1.2.11 on Centos 2.6.9-
P.A > 67.0.20.ELsmp.
P.A > >
P.A > According to http://www.iptables.org/news.html#2007-12-22 the port
P.A > randomization feature was added in iptables v1.3.8, which appears to
P.A > be
P.A > later than the version you're running, and, other sources indicate
P.A > that
P.A > the feature relies on kernel support available only in 2.6.22 or
P.A > later.
P.A >
P.A > But, even if hypothetically, you were to get iptables to randomize
P.A > source ports for you, the version of BIND you're running _already_
P.A > randomizes source ports, so re-randomizing using iptables will only
P.A > help
P.A > prevent an attack if the iptables PRNG produces higher-quality (i.e.
P.A > less predictable) results than the PRNG that BIND uses. If both BIND
P.A > and
P.A > iptables use the same source of entropy, then I don't see that you
P.A > would
P.A > buy anything by implementing source-port randomization at the iptables
P.A > level, and you would pay a cost in terms of complexity and overhead.
P.A >
P.A > (Caveat: I'm no crypto or entropy expert).
P.A >
P.A >
P.A > - Kevin