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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
