Re: FreeBSD 7.1 and BIND exploit
- From: Max Laier <max@xxxxxxxxxxxxxx>
- Date: Tue, 22 Jul 2008 07:07:11 +0200
On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote:
On Mon, 21 Jul 2008, Kevin Oberman wrote:
From: Max Laier <max@xxxxxxxxxxxxxx>
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: owner-freebsd-stable@xxxxxxxxxxx
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning hole?
Brett, et al,
I'll make this simple for you. If you have a server that is running
BIND, update BIND now. If you need to use the ports, that's fine,
just do it now. Make sure that you are not specifying a port via
any query-source* options in named.conf, and that any firewall
between your named process and the outside world does keep-state on
outgoing UDP packets.
... and that any NAT device employs at least a somewhat random port
allocation mechanism - pf provides this.
And, if you are not sure how good a job it does (and I am not), you
should use the OARC test to check how well it works:
dig +short porttest.dns-oarc.net TXT
If the result is not "GOOD", it's not good enough.
I was playing around with this a bit. It seems like a patched server
will give a standard deviation of more than 18,000. If I make some
queries behind a one-to-many NAT using pf, it falls to somewhere around
6,000 (with a patched BIND - unpatched is pitiful).
While the standard deviation gives some *indication* about the randomness
of the selection it is no real measurement for its quality.
PF is not *adding* any randomness to unpatched servers. Since it has a
(non-configurable?) range of ports it will grab when doing outbound
NAT, the results are not as good as with no NAT intervention, but
passable I suppose.
You can configure the range on a per-NAT-rule basis, e.g.:
nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if) port 1024:65535
but you have to take care so that you don't collide with the ephemeral
port range of the host itself.
Obviously you can't do much about an unpatched bind as with UDP there is
no notion of "connection" so pf (or any NAT device for that matter) has
to keep the NAT binding open for "some time" and a quick sequence of
queries to the same server will be sent out through the same port. So
putting a NAT firewall in front of a DNS resolver is *NOT* a workaround!
Of course in a 1:1 NAT setup it is transparent.
Charles
You can test a remote server by adding "@remote-server" to the dig
command. The server may be specified by name or IP address.
Don't forget that ANY server that caches data, including an end
system running a caching only server is vulnerable.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@xxxxxx Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- References:
- Re: FreeBSD 7.1 and BIND exploit
- From: Kevin Oberman
- Re: FreeBSD 7.1 and BIND exploit
- From: Charles Sprickman
- Re: FreeBSD 7.1 and BIND exploit
- Prev by Date: Re: FreeBSD 7.1 and BIND exploit
- Next by Date: Re: Panic on ZFS startup after crash
- Previous by thread: Re: FreeBSD 7.1 and BIND exploit
- Next by thread: Re: FreeBSD 7.1 and BIND exploit
- Index(es):
Relevant Pages
|
