Score:0

Server

can fail2ban add deny rules to nginx instead of using iptables

gelonida

6/28/23, 2:30 AM

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

192

0 + 0

nginx

reverse-proxy

fail2ban

Score:2

Server

Alexis Wilke

6/28/23, 2:56 AM

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.

0 + 0

gelonida

6/28/23, 9:25 AM

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

Score:2

Server

sebres

6/28/23, 2:36 PM

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.

0 + 0

Alexis Wilke

6/28/23, 5:33 PM

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.

sebres

6/28/23, 5:47 PM

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).

Alexis Wilke

6/28/23, 5:53 PM

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.

sebres

7/5/23, 11:30 AM

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.

gelonida

7/6/23, 11:23 PM

@sebres I guess I'm partially wrong. I made some tests with reverse proxies of different companies, that I had to install solutions for.(My solution behind their reverse proxy). Quite some if them filter undesired incoming headers, like X-Forwarded-For either by whitelisting or by blacklisting, but not all of them. So depending on the reverse proxy you're working with and its configuration you can rely on X-Forwarded-For. Try whether A client can inject these headers and you'll see (set nginx to debug logging) whether it is safe or not

sebres

7/10/23, 4:42 PM

@gelonida, guess you didn't understand the approach: client is always able to send any header (it even doesn't need to "inject" it somehow)... so again, the malicious client sends a requests with X-Forwarded-For header directly to server with f2b (without a proxy in between), so from point of view of the server with f2b it is a proxy itself. And therefore it's hardly possible to distinguish real proxies and malicious clients just masquerading as a proxy.

gelonida

7/12/23, 8:45 AM

@sebres I think I get what you mean. This is a false problem in my scenarios. server with f2b is only reachable via the reverse proxy due to firewall rules

sebres

7/12/23, 5:46 PM

well, it doesn't really matter how the server will be reached at end - the issue persist anyway: in the chain `Evildoer <-> Prox1 <-> Prox2 ... ProxN <-> Server`, you can only rely on the X-Forwarded-For header of proxies that you either know (or you even trust) and you know how they traverse those headers across the whole chain. Otherwise it is not really defined what exactly one got as X-Forwarded-For (or as X-Real-IP or whatever different proxies supply to next chain member).

sebres

7/12/23, 5:49 PM

Also if `ProxN` is yours, there are still many questions and several constellations are possible. More difficult is the answer to the question "which address does evildoer have and whether `Prox1` is real or fake". At the same time banning of `ProxN-1` address can be bad idea, if one want avoid possible false positives for legitimate clients going over same proxy. But OK, glad you got what I meant.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: can fail2ban add deny rules to nginx instead of using iptables

TH: สามารถเพิ่มกฎการปฏิเสธใน nginx แทนการใช้ iptables ได้

RO: poate fail2ban adăuga reguli de refuz la nginx în loc să folosească iptables

RU: может fail2ban добавить правила отказа в nginx вместо использования iptables

VI: fail2ban có thể thêm quy tắc từ chối vào nginx thay vì sử dụng iptables

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.