[unisog] [REN-ISAC] Alert: DNS Smurfing

John Kristoff jtk at northwestern.edu
Sat Dec 11 16:07:46 GMT 2004


On Fri, 10 Dec 2004 15:43:58 -0500
Doug Pearson <dodpears at indiana.edu> wrote:

> There are no simple and effective workarounds for this problem.

The key word being 'and'.  :-)

> Protection is needed for the attack target and the DNS servers
> employed in the attacks. One technique that will work to reduce
> server vulnerability is to turn off recursive queries to
> non-trusted sources. Current exploit codes likely require the
> recursion feature. With recursion turned off the likelihood of
> your server being chosen for an attack is diminished.
[...]
> I'd like to encourage discussion of workarounds on this mailing list.

My advice to institutions that cannot easily remove recursive queries
from external networks would be to begin migrating away their own
production client use and listed servers at the TLD registry from those
DNS servers.  Make those servers legacy and bring up new authoritative
servers that will have recursive queries disabled for external clients.
Start getting everyone and everything to point at those new servers now.
Separate the iterative and recursive functions using completely different
servers if at all possible.  Use (in BIND terminology) 'views' if you
can't get separate servers.  Keep those legacy servers around for as long
as you need them (forever?), but over time crank down a rate limit on them
so abuse will mitigated, while valid legacy use won't break in times of
normal operation.

If the spoofed source IP addresses in the DNS requests are not numerous
and not wildly random they can be filtered by IP address either on the
wire or via DNS blackholing.  In BIND, this would be something as simple
as:

  options {
      blackhole { abusers; };
  }

  acl "abusers" {
    192.0.2.1/32;      # 2004-12-11,jtk: abusive querier
  };

I like make use of the 'include' directive in BIND configs, such as:

   include "/etc/named.acl.conf";

in named.conf to keep things more organized and to be able to apply
stronger file permissions on the parts of the config that don't change
as regularly.  This is unfortunately completely reactive, but in the
near term sometimes that is good enough.

Some operating systems and network devices can rate limit by flow.
DNS servers tend to see *lots* of flows, so scaling properties of
those knobs and devices may be tested, but they might mitigate the
problem a bit also.  Cisco calls this is a microflow policer, Juniper
calls it a prefix specific action with a policer and UNIX systems
tend to call this traffic shaping.  My guess is that you'd want to
do a policer not for all sources, but all external sources.

If it is wildly spoofed, then something more sophisticated is needed.
Besides working with an upstream, adding some active queue management
knobs like RED could help.  Pushback is also a longer term goal, if
only people would get interested in that rather than adding BGP baggage.

John



More information about the unisog mailing list