AW: Varnish poisoned cache avoidance

pub crawler pubcrawler.com at gmail.com
Sun Jan 10 12:07:27 CET 2010


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
>



More information about the varnish-misc mailing list