Discuss mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

You set up rate-limiting with two parameters... The number of packets
per minute you want to allow, and the size of burst traffic.

Packets per minute is simple enough... one IP address can make X number
of queries per minute, and everything after that is dropped until they
fall below the specified rate again.

Burst traffic is what handles the flood when you visit a new website. 
The burst rate specifies a number of packets *in addition to* your
standard packets/minute.  When the burst quantity is exceeded, then it
starts counting into your packets/minute.  If you have set a burst of 6
packets/minutes, then for every 10 seconds that you are not exceeding
your limits, you regain 1 more packet on the burst counter.

Example... You allow 10 packets/minute, and 6 burst/minute.
Now a user visits a new website.  Lets say the page has to make 15
different queries for various graphics and banners.  First you use up
your 6 burst-rate counters, then you use up 9 of your packet/min
counters.  The user still has 1 counter left on their packets/min
counter and 0 remaining on the burst counter.

Now lets say the user clicks a link on the page, and the new page wants
to perform 3 queries...

If the user clicks within the first 10 seconds, they are only able to
make 1 more query, and the page will hang until more queries can be made.

If the user clicks the new link between 6-9 seconds after the original
page loaded, the packets/min counter will have incremented by 1, and the
user is able to make 2 queries at this point, then the page will again hang.

At 10 seconds, the burst counter will increment by 1, and the user is
finally able to finish all three queries to load the new page.

In this scenario, the packets/min counter will increment by 1 every 6
seconds, and the burst counter will increment by 1 every 10 seconds.  If
the user typically waits 30-60 seconds between clicking each page, they
would probably never realize there were any limiters in place.

Now consider a real-world situation...  I am currently running limiters
of 30/min with a burst of 5.  Also keep in mind that a normal user will
have at least 2 or 3 DNS servers listed.  If a user is really hammering
through web pages, they may hit my limiters, in which case their queries
would likely get bounced over to their secondary DNS entry.  A
legitimate user should never see any hesitation in their browsing.

On the other hand, a ddos attack which is firing off 10 queries/second
is going to get stonewalled within the first 3.5 seconds, and their
attack is going to only send out 35 queries per minute at most to the
victim's website.  This rate is barely a crawl for any regular web
server, and would not contribute any crippling traffic to the ddos attack.

Hopefully that helps explain how rate-limiting affects the attackers
without hurting normal traffic?



On 04/15/2013 10:55 PM, subhuman wrote:
> On Mon, 15 Apr 2013 22:31:03 -0600
> Jeff Taylor <shdwdrgn AT sourpuss.net> wrote:
>
>> Rate-limiting is the best first-step in this game.  Even if you can't
>> prevent your server from being used in an attack, you can at least
>> greatly limit the actual damage being done to yourself and the intended
>> target.  I would highly recommend that ALL public DNS servers implement
>> some manner of rate limiting.
>>
> might not a simple rate limiting cause problems with some clients? browsers 
> for example fire lots of requests at almost the same time in order to get 
> the contents as quickly as possible. would this include dns-lookups?
>
> maybe a silly question. if so, forget it. ;-)
>
> --martin
>