AW: Varnish poisoned cache avoidance

[Michael S. Fischer]

It has been my experience that anti-DoS is usually easiest to implement at the origin server level, where the request handlers are typically more flexible and easiest to program.  Even forking servers like Apache can issue 4xx responses lightning fast, without many resources being consumed.

--Michael

On Jan 10, 2010, at 3:07 AM, pub crawler wrote:

> The antiDoS features would be a good enhancement to Varnish.  I
> realize it's a very complex and resource intensive thing to approach.
> There are likely many other ways some of these functions could be used
> in other ways for other solutions.
> 
> In our instance we are not experiencing a true denial of service
> attack, but rather are being overwhelmed on our app servers by an high
> sustained per second request rate.  The antiDoS features would
> certainly help us in this situation.
> 
> Is the "delay 100ms" something that could be made available in Varnish
> near term?
> 
> I could use this delay in conjunction with IP range of known bots
> causing problems or by defining User Agent with this.
> 
> On Sun, Jan 10, 2010 at 5:12 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> In message <01cf01ca91db$8c29b790$a47d26b0$@de>, "Mike Schiessl" writes:
>> 
>>> How can varnishd help me prevent DDOS / DOS attacks ?
>> 
>> Firstly, by being damn fast.
>> 
>> Originally we had some plans for specific antiDoS measures, something
>> like:
>> 
>>        sub vcl_recv {
>>                if (client.bandwidth > 100 mbit/s) {
>>                        delay 100ms;
>>                }
>>                if (client.missratio > 20%) {
>>                        close;
>>                }
>>        }
>> 
>> et cetera...
>> 
>> There are some issues and fine details to doing it, amongst other things
>> that we need to have a data structure for the client which survives
>> the individual session long enough for it to make any difference
>> in the above context.
>> 
>> The trouble of course is that a DDoS cannot be identified by IP#,
>> prompting ideas long the lines of
>> 
>>        sub vcl_recv {
>>                if (backend.hitrate < 70%) {
>>                        /* do something... */
>>                }
>>        }
>> 
>> etc.
>> 
>> But before we get anywere, somebody needs to figure out what we
>> can do.
>> 
>> Basically any countermeasure has two equally troublesome components:
>> 
>> 1. detection.  Knowing that you need to do something.
>> 
>> 2. mitigation.  What are we going to do ?
>> 
>> Poul-Henning
>> 
>> 
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk at FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by incompetence.
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>> 
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc