1

I'm having one server, that is behind a reverse proxy, that I don't control. I'd like to use fail2ban to block nginx traffic under certain conditions.

normally fail2ban useses iptables to block traffic originating from the intruder's IP

However my server is behind a reverse proxy and from my server's point of view all traffic originates from the reverse proxy:

I found following url https://forums.freebsd.org/threads/fail2ban-behind-a-proxy.55041/ that suggests tu use iptables with package intropspection like for example:

actionban = iptables -I fail2ban-<name> 1 -p tcp --dport 80 -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP

However the reverse proxy that I cannot control forwards the traffic as https traffic, meaning, that I cannot introspect the traffic for X-Forwarded-For headers as they would be encrypted.

Thus my question.

Do others have a similar scenario and is there an existing actionban = that adds Deny rules to nginx ?

Or do I have to handcraft a script trying to do this (edit nginx the nginx configuration and reload nginx)

What other solution would allow me to tell nginx dynamically which requests (containing specific X-Forwarded-For: headers) to block

2 Answers 2

1

fail2ban can be used to run a script. That script can do anything you'd like.


Editing Deny Rules

I'm not too sure how the whole thing can work full speed, but you can easily add Deny rules in a file.

The Nginx configuration files can do an include:

include /etc/nginx/deny-rules.conf

And your script generates that deny-rules.conf, somehow... You want to add IPs to a file and then use that file to generate the deny-rules.conf file using a loop or something.

Then you have to restart Nginx so the new rules get taken in account. That's the bad part in this scheme. It's going to be slow to restart this way.


Denylisting

Another solution would be to use the following filter:

Dynamic Denylisting of IP Addresses

I never used that so I'm afraid that you'll have to read the docs and look on how to set things up and make it all happen... However, that should work at full speed. The script in your fail2ban system can take care of updating that dynamic list.

1
  • thanks for your answer. Will wait to see whether some users do know about an existing actionbab script. If not I'll accept as answer
    – gelonida
    Commented Feb 28, 2022 at 9:25
4

You could use fail2ban action nginx-block-map, see nginx-block-map.conf for details.

Just note that by filtering of X-Forwarded-For header, it is pretty simple for the intruders to manipulate the request to avoid a ban (with setting of the different values each new request in this header). The question whether an intruder siting behind the proxy or just simulating the proxy, and just set the header X-Forwarded-For by itself can't be answered simply.

10
  • 1
    The X-Forwarded-For should be set by Nginx to proxy to a backend system (i.e. a system a direct client can't access). So unless your setup is invalid, that should work just fine. Commented Feb 28, 2022 at 17:33
  • No, it is not this header... the header X-Forwarded-For, the topic starter means, will be received from client, so at the side of nginx it is not clear at all what exactly set it on client side, therefore nginx receiving this request doesn't able to distinguish the client (a real proxy or just an intruder posing as a proxy). In opposite to the header that you mean, which is comparable with protection of your nginx against your backend, what simply makes no sense (why you'd need fail2ban for that).
    – sebres
    Commented Feb 28, 2022 at 17:47
  • Oh for sure, if the Nginx receives an X-Forwarded-For header, it has to be ignored. Since Nginx is the proxy, It is expected to set it and then forward the request to the backend computer. Then the backend computer can send a message "block that IP" and that would be the IP of the client (as found in the socket). And I see that OP says there is yet another proxy server in the routing. So I guess he can't know which IP to block. Commented Feb 28, 2022 at 17:53
  • just to clarify. it's the reverse proxy, that adds the X-Forwarded-For header. It will also strip any such headers of the incoming traffic. so that should be safe.
    – gelonida
    Commented Aug 16, 2022 at 10:30
  • No, you're wrong @gelonida - the fact that a proxy set it, doesn't prevent the client to do that too... so basically everyone can add this header, therefore it's definitely not safe. Again, it's too simply for evildoer to masquerade as a proxy.
    – sebres
    Commented Jul 5, 2023 at 11:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .