Avoiding being used as DDoS reflector.
Nathan Ollerenshaw
I've searched around a bit, and noticed some others have similar
problems as this but nobody has come up with a decent solution, or at
least, I've not found one.
I have an Authoritative BIND server. It is configured to only allow
recursive queries from localhost, with recursion disabled for any
remote clients.
If you attempt to perform a recursive query against this server, it
will respond with a "query refused" packet, as this is what BIND does
if you try to recursively query a server configured to disallow
recursive queries.
Kiddies, however, are exploiting this behaviour to provide a level of
indirection in their DDoS efforts.
Jan 19 10:12:34 mars named[7683]: client 69.50.142.110#40346: query
(cache) './NS/IN' denied
Jan 19 10:12:35 mars named[7683]: client 76.9.16.171#47713: query
(cache) './NS/IN' denied
Jan 19 10:12:37 mars named[7683]: client 76.9.16.171#53205: query
(cache) './NS/IN' denied
Jan 19 10:12:38 mars named[7683]: client 76.9.16.171#2340: query
(cache) './NS/IN' denied
Jan 19 10:12:39 mars named[7683]: client 76.9.16.171#53417: query
(cache) './NS/IN' denied
Jan 19 10:12:41 mars named[7683]: client 76.9.16.171#38593: query
(cache) './NS/IN' denied
Jan 19 10:12:43 mars named[7683]: client 69.50.142.110#61075: query
(cache) './NS/IN' denied
Jan 19 10:12:43 mars named[7683]: client 76.9.16.171#54721: query
(cache) './NS/IN' denied
Jan 19 10:12:45 mars named[7683]: client 76.9.16.171#12764: query
(cache) './NS/IN' denied
Jan 19 10:12:47 mars named[7683]: client 76.9.16.171#59043: query
(cache) './NS/IN' denied
Jan 19 10:12:47 mars named[7683]: client 76.9.16.171#55282: query
(cache) './NS/IN' denied
Jan 19 10:12:49 mars named[7683]: client 76.9.16.171#54628: query
(cache) './NS/IN' denied
Jan 19 10:12:51 mars named[7683]: client 76.9.16.171#34097: query
(cache) './NS/IN' denied
Jan 19 10:12:52 mars named[7683]: client 69.50.142.110#63662: query
(cache) './NS/IN' denied
Each of these requests send back a packet to the IP the spoofed query
coes from. I've contacted network operators (not necessarily those
ones listed for these IPs) and they've confirmed, separately, that
they've been under attack for several weeks by these DNS reply packets.
Obviously the amount of load here is negligible to me, and if I didn't
care about anyone else, then I could just suppress the log messages
and move on with my life. But, I don't think thats the appropriate
response.
Even though my nameserver seems to be correctly configured, there
seems to be no way for me to ignore these spurious requests or rate
limit them, so therefore I'm aiding the attackers, however obliquely,
in their efforts.
I've considered using views blackhole recursive requests, but
blackholes can only be specified in the global configuration, not in
views. I've considered using iptables/netfilter and the u32 extension
to match the specific DNS flags that denote a recursive query, and
then apply a rate limit; but I really don't know the best way forward.
I currently manage these attacks by adding a blackhole entry for each
IP that the kiddies try to attack, but this is a stop-gap, and I'd
prefer something that can work in an automatic way to deny kiddies the
use of my authoritative nameserver as a reflector.
The ideal solution for me, would be a bind configuration option that
could rate limit responses based on type; so you could specify that a
"REFUSED" reply will only be sent to a given host once per hour, or
something like that.
Any ideas? Anyone facing this same problem found a solution? I'd be
glad to hear it :)
--
Nathan Ollerenshaw :: http://www.stupendous.net/
"Anyone who has never made a mistake has never
tried anything new." - Albert Einstein
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Leonardo Rodrigues Magalhães
Nathan Ollerenshaw escreveu:
>
> I have an Authoritative BIND server. It is configured to only allow =
> recursive queries from localhost, with recursion disabled for any =
> remote clients.
>
> If you attempt to perform a recursive query against this server, it =
> will respond with a "query refused" packet, as this is what BIND does =
> if you try to recursively query a server configured to disallow =
> recursive queries.
> [ ........ ]
> Any ideas? Anyone facing this same problem found a solution? I'd be =
> glad to hear it :)
>
if you're running authoritative only for localhost and is not =
answering network requests at all, then you could probably firewall =
incoming packets to UDP 53 port !!! Let the responses in, let the new =
requests out.
i cant imagine anything simplier than that.
-- =
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, N=C3O mandem email
gert...@solutti.com.br
My SPAMTRAP, do not email it
Leonardo Rodrigues Magalhães
Leonardo Rodrigues Magalh=E3es escreveu:
>
>
> Nathan Ollerenshaw escreveu:
>>
>> I have an Authoritative BIND server. It is configured to only allow =
>> recursive queries from localhost, with recursion disabled for any =
>> remote clients.
>>
>> If you attempt to perform a recursive query against this server, it =
>> will respond with a "query refused" packet, as this is what BIND does =
>> if you try to recursively query a server configured to disallow =
>> recursive queries.
>> [ ........ ]
>> Any ideas? Anyone facing this same problem found a solution? I'd be =
>> glad to hear it :)
>>
>
> if you're running authoritative only for localhost and is not =
> answering network requests at all, then you could probably firewall =
> incoming packets to UDP 53 port !!! Let the responses in, let the new =
> requests out.
>
> i cant imagine anything simplier than that.
>
even simplier than that would be:
options {
...
listen-on { 127.0.0.1; };
....
};
John Wobus
>
>
> Nathan Ollerenshaw escreveu:
>>
>> I have an Authoritative BIND server. It is configured to only allow =
>> recursive queries from localhost, with recursion disabled for any =
>> remote clients.
>>
>> If you attempt to perform a recursive query against this server, it =
>> will respond with a "query refused" packet, as this is what BIND does =
>> if you try to recursively query a server configured to disallow =
>> recursive queries.
>> [ ........ ]
>> Any ideas? Anyone facing this same problem found a solution? I'd be =
>> glad to hear it :)
>>
>
> if you're running authoritative only for localhost and is not =
> answering network requests at all, then you could probably firewall =
> incoming packets to UDP 53 port !!! Let the responses in, let the new =
> requests out.
>
> i cant imagine anything simplier than that.
If you need 53 to answer for authoritative zones, you could run two =
bind instances, one for your caching server,
the other for the authoritative data. Then a firewall or instance-wide =
black-hole config would take care of it.
Not too inspired a solution, but it's all I can think of.
I fear that what you are seeing is difficult to handle, thus may well =
become only more popular as time passes,
especially if it really does cause trouble for the victim. If the =
traffic is negligible for you, then does it really
hurt the victim? How would they be harmed? Is the victim someone who =
queries your authoritative
server enough to get some confusing "hits" of matching port, ID, and =
server of outstanding queries? Even if you
block recursive error returns, would an attack using valid =
authoritative answers be equally harmful to the victim?
John
Chris Buxton
> Nathan Ollerenshaw escreveu:
>>
>> I have an Authoritative BIND server. It is configured to only allow
>>
>> If you attempt to perform a recursive query against this server, it
>> disallow recursive queries.
>> [ ........ ]
>> Any ideas? Anyone facing this same problem found a solution? I'd be
>
>
> If you need 53 to answer for authoritative zones, you could run two
> bind instances, one for your caching server,
> the other for the authoritative data. Then a firewall or instance-
> wide black-hole config would take care of it.
> Not too inspired a solution, but it's all I can think of.
>
> I fear that what you are seeing is difficult to handle, thus may
> well become only more popular as time passes,
> especially if it really does cause trouble for the victim. If the
> traffic is negligible for you, then does it really
> hurt the victim? How would they be harmed? Is the victim someone
> who queries your authoritative
> server enough to get some confusing "hits" of matching port, ID, and
> server of outstanding queries? Even if you
> block recursive error returns, would an attack using valid
> authoritative answers be equally harmful to the victim?
What's happening is, the attacker uses a botnet to send recursive
packets for ./IN/NS (or any other query likely to get a large
response) to a large number "reflectors", using a spoofed source
address (the address of the target).
one controller
100000 bots
1000000 reflectors (per second - they can change from one second to
another)
one target
The controller (the bot herder) already has an efficient way to
control his botnet. Each bot (a compromised machine, usually running
Windows, that's owned by an unsuspecting normal person) sends 10 DNS
packets per second to 10 different servers - not very much traffic.
Each reflector, a DNS server that accepts any kind of query from the
Internet, sees 1 query per second (or less) - a very small amount of
traffic. So none of these machines are seeing much load.
The target gets one million bogus responses per second.
Chris Buxton
Professional Services
Men & Mice
JINMEI Tatuya / 神明達哉
Nathan Ollerenshaw <chr...@stupendous.net> wrote:
> I have an Authoritative BIND server. It is configured to only allow
> recursive queries from localhost, with recursion disabled for any
> remote clients.
[snip]
> The ideal solution for me, would be a bind configuration option that
> could rate limit responses based on type; so you could specify that a
> "REFUSED" reply will only be sent to a given host once per hour, or
> something like that.
Rate-limiting REFUSED responses doesn't make much sense in this
context, because the response messages are not (that) amplified in
packet size. Even if you rate-limited REFUSED responses, the attacker
could exploit other attack vectors. Especially in your case where the
server also acts as an authoritative server, the attacker would just
send a valid non-recursive query for a name in the authoritative zone
with a forged address.
IMO, it's not worth considering a counter measure for a non-amplifying
DoS attacks, especially if it can make the implementation complicated.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.