On 11/05/2015 03:30 PM, Baptiste wrote:
On Thu, Nov 5, 2015 at 2:48 PM, Sylvain Faivre
<sylvain.fai...@reservit.com> wrote:
Hi,
Is there a way to use several gpc's ?
I already use gpc0 to track client IPs generating too many errors, and I
need to use another counter to track client IPs requesting some pages too
fast.
Here are the relevant parts of my current setup :
frontend web
stick-table type ip size 500k expire 5m store gpc0
tcp-request content track-sc1 src
http-request deny if !i_internal { sc1_get_gpc0 gt 0 }
backend front
stick-table type ip size 100k expire 5m store http_err_rate(10s)
tcp-request content track-sc2 src
acl error_rate_abuse sc2_http_err_rate gt 10
acl mark_as_abuser sc1_inc_gpc0 gt 0
reqtarpit . if error_rate_abuse !whitelist mark_as_abuser
And I'm trying to add something like this to the frontend :
stick-table type ip size 50k expire 24h store gpc0_rate(60s)
acl pages_info path_sub -i info.php
acl too_many_info_requests sc0_gpc0_rate() gt 50
acl mark_seen_pages_info sc0_inc_gpc0 gt 0
tcp-request content track-sc0 src if pages_info
http-request deny if mark_seen_pages_info too_many_info_requests
But I'm afraid that I will not be able to distinguish the info stored in
gpc0 for the error count and for the requests count...
What am I missing here ?
Hi Sylvain,
Which version of HAProxy are you using?
With 1.6, there are some converters that may be used to get rid of
using gpc while counting errors.
It means you would store abuser client IP in a dedicated table and
simply check if the IP is there:
http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#in_table
I have on my TODO to write such type of article on the blog. Some kind
of DDOS protection with HAProxy 1.6.
Baptiste
We are using HAproxy 1.5, upgrading to 1.6 shouldn't be a huge problem.
I guess I'll wait for your article, since I'm not sure I understand
everything about all this table stuff.
So, with HAproxy 1.5, one cannot have two types of DDOS protection at
the same time ? (against flag offenders who send too many requests, and
those whose requests cause too many errors)
