[squid-users] Looking for ideas on how to use squid in order to protect against a DOS\DDOS.

[Eliezer Croitoru]

On 01/12/2015 12:57, Amos Jeffries wrote:
> On 1/12/2015 8:19 a.m., Eliezer Croitoru wrote:
>> I was wondering if someone have a nice idea on how to use squid to
>> protect against DOS\DDOS http\https attacks.
>>
>> The basic way I was thinking is rate limiting by counting the client IP
>> page HITs but I am unsure about it since it can actually catch the good
>> guys and bite my squid setup.
>>
>> The other way I was thinking was some kind of a challenge like a captcha
>> page.
>>
>> Also I have seen something like JavaScript browser challenge being used.
>>
>> What do you think would be the right choice?
>
> Fast automated detection. Absolute minimal response to identified
> requests. Push the cost as far back up the traffic path towards the
> attacker as possible. Those are the answers to DDoS.
>
>>
>> If you have another idea please send me or the list an email.
>>
>
> Squid already does pretty well against many of the common (old'ish) DDoS
> types. Though there are some countermeasures that could still be
> improved, and some DDoS types that are not protected against at all.

Squid can only "catch" with default settings basic objects fetch from 
the origin which in most cases can also be forced by adding couple 
arguments to the request such as a timestamp.

> There are many forms of DoS to begin with, and *how* the DoS is turned
> into DDoS is one of the important considerations. There are many
> possible forms that could take. So the big question to start with is
> what type of DDoS are you trying to protect against?

I do not have one in mind yet since I'm not really a Dos or DDoS master.
I have seen couple attacks in the past which was coming from a single or 
more AS while spreading the attack from lots of origins.
The basic attack would be an application level one which in this case a 
captcha gives in many cases really good results.
The second case would be traffic BW exhaustion and for that a basic BW 
throttling would be good enough.(delay pools can be used for that..)

I have used fail2ban more then once to block origins and to identify 
them but I think an ICAP service might be able to identify more then 
what is in the access.logs.

What you wrote about "Push the cost as far back up the traffic path.." I 
can think about one way which would be a redirection towards their own 
source IP or GW.
And the above is nice for small attacks but not for very big ones. But 
in the other hand an ICAP service can give better details\debug on the 
details of the attack. It can be turned on for specific traffic and help 
understand the nature of it.
Also an ICAP service can be used as a honey pot.

I will research more and see what can be done in the ICAP level.

Thanks,
Eliezer