On 1/23/2019 8:16 AM, Marco Colli wrote:
1. Based on advanced conditions (e.g. current user) our Rails
application decides whether to return a normal response (e.g. 2xx) or
a 429 (Too Many Requests); it can also return other errors, like 401
2. HAProxy bans clients if they produce too many 4xx errors
What do you think about this solution?
Also, is it correct to use HAProxy directly or it is more performant
to use fail2ban on HAProxy logs?
I'm definitely not an expert. My opinion is that you should do both.
I haven't set up the protections in haproxy itself, but I know it can be
done. That's something I plan to look into when I find some time.
Just a couple of days ago, I set up a fail2ban jail that looks at the
haproxy log and initiates bans based on what it finds. It works REALLY
well.
This is the definition that activates the jail, in a config file I've
placed in /etc/fail2ban/jail.d:
[haproxy-custom]
enabled = true
findtime = 120
bantime = 3600
logpath = /var/log/debug-haproxy
maxretry = 20
This is the definition of the filter it uses, in
/etc/fail2ban/filter.d/haproxy-custom.conf:
[Definition]
_daemon = haproxy
failregex = ^%(__prefix_line)s<HOST>(?::\d+)?\s+.*<NOSRV>
Basically, if there are 20 or more <NOSRV> requests in the log over a
timespan of two minutes from one source IP, that address gets banned.
Most of the NOSRV requests in my log are http->https redirects. All of
the attacks that I have seen since setting this server up have come in
as http, and I have haproxy configured to redirect ALL insecure requests
to https. I do have a few settings in haproxy that result in some
connections being denied entirely, which also produces a <NOSRV> log.
It's entirely possible that a web application could be badly written
such that it triggers this jail accidentally, but I would expect most
applications to be just fine.
Legitimate traffic can produce the http->https redirects, but it's
certainly not likely to get 20 of them in two minutes.
I may also implement a similar filter for repeated 404 errors and maybe
other errors like 400 or 500, to cover attacks on the https frontends
where the webserver says the path doesn't exist.
The fail2ban package comes with a filter for 401 responses in the
haproxy logs; I based my regex on that one.
Thanks,
Shawn