[dns-operations] DoS with amplification: yet another funny Unix script

[Colm MacCárthaigh]

On Tue, Sep 11, 2012 at 9:38 AM, Vernon Schryver <vjs at rhyolite.com> wrote:
>> From: Klaus Darilion <klaus.mailinglists at pernau.at>
>
>> On 10.09.2012 19:48, Paul Vixie wrote:
>> > please don't do, or promulgate, this. ddos filtering in order to do more
>> > good than harm has to be based on the attack's answer, not on its query.
>
>> > vernon schryver and i explain this in the technical note at
>> > <http://www.redbarn.org/dns/ratelimits/>.
>
>  Any firewall rule that doesn't compute DNS responses about as good as a DNS server is simplisitic.

With the greatest of respect; that thinking is itself simplistic.
Where I work we concentrate on writing very good firewalls. Sometimes
these rules even have to parse DNS, just as the DNS server must ...
which causes duplication of work. We do this for several reasons;

An in-the-path firewall actually has access to more data than the DNS
server alone does. For example, it can build up a simple profile of
expectation values for IP TTLs on a per-source network basis. It can
use all IP data for that profile; DNS, HTTP, whatever it's seen. Those
expectation values can then be used to detect and reject spoofed
packets, in combination with other statistical scores. That's just one
simple example - there are many more.

The other big reason is pragmatism; unix daemons using recv() are
extremely limited in the rate at which they can process packets. far
far higher throughput is possible via other techniques that involve
handling batches of packets at much smaller timescales. A nice benefit
of the approach is that it frees higher-level development teams from
having to worry about low-level mitigation, and that the work is
re-usable across many products. During real attacks, if a packet makes
it to the dns server, the game is already lost.

If anyone reading is interested in helping us write and build these
kinds of line-rate low-level filters, drop me a line at
colmmacc at amazon.com - we're always hiring!

> Because each request implies its response, in theory there is no
> difference between filtering based on requests or responses.

When the primary goal is to mitigate the impact of reflection attacks
on their potential targets, it makes some sense to filter responses.
That way you can implement a rate-limit that takes bandwidth into
account, rather than simply PPS. Definitely agreed about that :)

-- 
Colm