Twice in the last two days, I've seen people post their named.conf files
(or snippets there-of) and they have contained lines similar to the
following:
> query-source port 53;
> query-source-v6 port 53;

These lines specifically "undo" the port randomization that is included
in the current -P1 and beta code required for securing your servers from
cache poisoning.

It is not enough to install the patched code! You also MUST remove the
restrictions on the ports that your queries use when leaving your system.

Be aware that this may entail getting some cooperation from your
firewall administrators, but this is VITAL to the resilience of your
servers against the new attack vector.

Please, if you have QUERY-SOURCE PORT XX statements in your
configuration files, work quickly to remove them.

Thanks,
AlanC

Απάντηση 5
Jeff,

You haven't yet figured out the attack vector, or the goal of the
attack.

If your name server is used by client machines to look up outside
names, then your server is at risk. The risk is that someone will
manage to convincingly forge a response to your name server's outbound
query, thus causing your name server to believe something untrue and
cache it. This cached data is then used to attack you and your users,
e.g. directing you to the attacker's clone of PayPal instead of to the
real thing. (They still won't have a valid PayPal SSL certificate, but
if you don't put the "https://" into the URL in your browser, you may
never notice that.)

It doesn't matter if you have recursion restricted - as long as
recursion is enabled for some user, then your server is subject to
these attacks. If you turn it off, then it is not at risk. The attack
does not threaten the actual operation of the name server, it
threatens the pool of users who send recursive queries to the name
server.

However, that said, this attack is not new. The weakness addressed by
this latest patch is not some new revelation - it's something we in
the community have known about for years. It's just that Dan Kaminsky
is presenting a paper next month at Black Hat telling the world how to
exploit it.

To convince your name server that a bogus response is real and
correct, the attacker must get the following values right:

- The source address and port of the query.
- The destination address and port of the query.
- The query ID.
- The query name, class, and type.

If the attacker has a packet sniffer somewhere upstream of you, you're
dead in the water. He can sniff these values and forge a response on
the spot. Otherwise, however, he has to guess or determine all of that.

The source address of the query is, of course, your server's address.
If the attacker is trying to spoof paypal.com, then there is a small
number of destination addresses, the name servers for paypal.com, and
also the query name/class/type triplet is known. The destination port
is 53. These should be the only known quantities, ideally.

There have been several recent security updates to BIND relating to
the query ID not being sufficiently random. In fact, in some cases, a
low-traffic server's next query ID could be predicted accurately, over
and over.

Now we have publication of the fact (long-known by those of us who
teach this subject) that the source port used for queries is knowable
- all the attacker needs to do is set up a name server to be
authoritative for some zone, and then wait (or cause) your name server
to look up that data. His server will then log the source port used
for queries. Until this latest patch, BIND chooses a single source
port at startup and sticks with it. The latest patch makes this port
random for each query, although the side effects of this may be
intolerable for some installations. (If I may suggest to the folks at
ISC, perhaps an option to put a rate limit on the frequency of changes
- N times per second, for example - would solve this. And for
goodness' sake, be a little more aggressive about closing ports after
some time has passed.)

Combine a weak or predictable query ID with a known source port and
the attacker has an easy time spoofing a response - he just has to
keep sending responses to your server and wait for some valid user to
try to look up the targeted RRSet. (There is some effort required to
keep updating his knowledge of your query ID random number pool's
state, but in some cases that's not much of a barrier.)

Because these two variables are the only ones we can really
strengthen, it becomes very important for the DNS server vendors out
there to do so. Both values are constrained to 16-bit values, so we
max out the difficulty to a 32-bit random number - not very secure by
modern standards. As it was before this latest patch, however, it
became effectively a 16-bit random number once a small amount of
effort was completed.

Now consider the value of DNSSEC, in which we augment this with, say,
a 1024-bit cypher. Your (at best) 32-bit key has now become (at least)
a 1024-bit key. And it's all validated by multiple cross-checks.