Hi,
after changing: http-request track-sc0 src unless { src -f
/etc/haproxy/whitelist.acl }
to: tcp-request connection track-sc0 src unless { src -f
/etc/haproxy/whitelist.acl }
such requests increase the http_req_rate but surprisingly not the
http_err_rate.
### Example:
$ echo 'show table production key [REDACTED]' | socat stdio
unix:/var/run/haproxy/admin.sock
# table: production, type: ip, size:5242880, used:24871
0x55bfdfa7b910: key=[REDACTED] use=0 exp=7199973 gpt0=0
http_req_rate(60000)=923 http_err_rate(60000)=0
At the same time i recognized, that according to the logs the client
produced about 12k 400-Errors
$ grep [REDACTED] /var/log/haproxy.log | grep BADREQ | wc -l
12383
It seems to me like a Problem with Version 1.8, because i tested it with
Version 2.0 in a Staging Environment were everything works like
expected. For me it's another reason to plan our upgrade to the current
LTS-Version.
Best Regards,
Marco
Am 12.12.19 um 16:59 schrieb Marco Nietz | practicalbytes:
Hi Willy,
thank for your support, this perfectly make sense. I've changed the
configuration and will investigate if it works.
Marco
Am 12.12.19 um 16:39 schrieb Willy Tarreau:
Hi Marco,
On Wed, Dec 11, 2019 at 12:50:21PM +0100, Marco Nietz wrote:
Hi,
i'm running Haproxy 1.8.21 on a Debian 9 Box.
We use stick-tables to track http-connections and http-error-rate
and block
clients (bots) that cause a high error-rate. But Today i recognize a
lot of
400 / Bad Requests Error (~15/s) in the logs. The rate definitely
exceeds
the defined limit, but the ip-address wasn't blocked. Therefor my
question,
does HTTP-Error 400 not increase the http_err_rate Counter?
Yes it does.
The state is CR,
so the requests do not reach our backend-servers, but my expectation
is,
that they get blocked at the loadbalancer. The below configuration
works
fine with 404 or 401 errors.
Here's a sample logfile entry:
Dec 11 11:56:40 lb01 haproxy[41488]: [REDACTED]:3641
[11/Dec/2019:11:56:40.103] production~ production/<NOSRV>
-1/-1/-1/-1/98 400
0 - - CR-- 461/461/0/0/0 0/0 "<BADREQ>"
Configuration:
stick-table type ip size 5M expire 2h store
http_req_rate(60s),http_err_rate(60s),gpt0
http-request track-sc0 src unless { src -f /etc/haproxy/whitelist.acl }
http-request sc-set-gpt0(0) 1 if { sc_http_err_rate(0) ge LIMIT }
tcp-request connection reject if { src,table_gpt0(production) eq 1 }
I think I get the issue. It's just that in case of a bad request you
never reach the http-request rules since there's no HTTP request in
the first place. You should move your "track-sc0" rule to tcp-request
connection instead.
Willy
