SANS: DNS Bug Now Public?

[Jorge Amodio]

Let me add that folks need to understand that the "patch" is not a fix to a
problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.

There are plenty of documents out there (check cert.org for example) that
can provide some guidance.

Perhaps this situation will help move things on the DNSSEC front, as far as
I remember there are some IETF drafts on
the standards track addressing these issues.
Cheers
Jorge

On Tue, 22 Jul 2008 08:00:51 -0500

It has been public for a while now. Even on the print media, there
are some articles about it on the latest Computerworld mag without
giving too much detail about how to exploit it.
ie PATCH NOW !!!

Kaminsky's blog says "Patch. Today. Now. Yes, stay late."
--Steve Bellovin, http://www.cs.columbia.edu/~smb

[Joe Abley]

Post by Jorge Amodio
Let me add that folks need to understand that the "patch" is not a fix to a
problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.

Having just seen some enterprise types spend time patching their
nameservers, it's also perhaps worth spelling out that "patch" in this
case might require more than upgrading resolver code -- it could also
involve reconfigurations, upgrades or replacements of NAT boxes too.
If your NAT reassigns source ports in a predictable fashion, then no
amount of BIND9 patching is going to help.

(Reconfiguring your internal resolvers to forward queries to an
external, patched resolver which can see the world other than through
NAT-coloured glasses may also be a way out.)


Joe

[Darren Bolding]

After a bit of looking around, I have not been able to find a list of
firewalls/versions which are known to provide appropriate randomness in
their PAT algorithms (or more importantly, those that do not).

I would be very interested in such a list if anyone knows of one.

As a side note, most people here realize this but, while people mention
firewalls, keep in mind that if a load-balancer or other device is your
egress PAT device, you might be interested in checking those systems
port-translation randomness as well.

--D

Post by Jorge Amodio
Let me add that folks need to understand that the "patch" is not a fix to a

Post by Jorge Amodio
problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.

Having just seen some enterprise types spend time patching their
nameservers, it's also perhaps worth spelling out that "patch" in this case
might require more than upgrading resolver code -- it could also involve
reconfigurations, upgrades or replacements of NAT boxes too. If your NAT
reassigns source ports in a predictable fashion, then no amount of BIND9
patching is going to help.
(Reconfiguring your internal resolvers to forward queries to an external,
patched resolver which can see the world other than through NAT-coloured
glasses may also be a way out.)
Joe

[Jasper Bryant-Greene]

FWIW, anyone using iptables for NAT can use --random, e.g.:

iptables -t nat -A POSTROUTING -o ethX -j SNAT --to x.x.x.x --random

Useful for Linux NAT/load-balancer boxes, or for Linux-powered embedded
devices where the vendor has not been forthcoming with a firmware patch
to alter the rules they generate.

I believe this requires kernel >= 2.6.21.

-Jasper

Post by Darren Bolding
After a bit of looking around, I have not been able to find a list of
firewalls/versions which are known to provide appropriate randomness in
their PAT algorithms (or more importantly, those that do not).
I would be very interested in such a list if anyone knows of one.
As a side note, most people here realize this but, while people mention
firewalls, keep in mind that if a load-balancer or other device is your
egress PAT device, you might be interested in checking those systems
port-translation randomness as well.
--D

Post by Jorge Amodio
Let me add that folks need to understand that the "patch" is not a fix to a

Post by Jorge Amodio
problem that has been there for long time and
it is just a workaround to reduce the chances for a potential
attack, and it must be combined with best practices and
recommendations to implent a more robust DNS setup.

Having just seen some enterprise types spend time patching their
nameservers, it's also perhaps worth spelling out that "patch" in this case
might require more than upgrading resolver code -- it could also involve
reconfigurations, upgrades or replacements of NAT boxes too. If your NAT
reassigns source ports in a predictable fashion, then no amount of BIND9
patching is going to help.
(Reconfiguring your internal resolvers to forward queries to an external,
patched resolver which can see the world other than through NAT-coloured
glasses may also be a way out.)
Joe

[Phil Regnauld]

Post by Joe Abley
Having just seen some enterprise types spend time patching their
nameservers, it's also perhaps worth spelling out that "patch" in this case
might require more than upgrading resolver code -- it could also involve
reconfigurations, upgrades or replacements of NAT boxes too. If your NAT
reassigns source ports in a predictable fashion, then no amount of BIND9
patching is going to help.

Case in point, we've got customers running around in circles
screaming "we need to upgrade, please help us upgrade NOW",
but they have _3_ layers of routers and firewalls that are hardcoded to
only allow DNS queries from port 53.

[Paul Vixie]

Post by Phil Regnauld
Case in point, we've got customers running around in circles
screaming "we need to upgrade, please help us upgrade NOW",
but they have _3_ layers of routers and firewalls that are hardcoded to
only allow DNS queries from port 53.

please take this problem, and all related threads, to
<dns-***@lists.oarci.net>. this is NANOG. there
are plenty of people on that other mailing list willing
to help and interested in helping with DNS issues.

fwiw, we all know that udp port randomization isn't a
panacea and that it will break many previously-working
configurations. we just don't know what else to do NOW
while we wait for godot or whomever to deliver us DNSSEC.