Fail2ban: Fail2ban & CloudFlare??

[Octolus]

Hello everyone.

I found this, and it worked perfectly when I did not use CloudFlare: https://rtcamp.com/tutorials/nginx/fail2ban/

However, I am currently using CloudFlare. I did some re-search and I found that these two commands would work to ban and unban:

actionban = curl -s "https://www.cloudflare.com/api.html?a=ban&key=&u=&tkn="
actionunban = curl -s "https://www.cloudflare.com/api.html?a=nul&key=&u=&tkn="

Does anyone know how I could use https://rtcamp.com/tutorials/nginx/fail2ban/ configuration, with CloudFlare API?

I will obviously replace the toke and account my self.

Can someone help? i can donate a few bucks in paypal.

[justabaka]

That's super easy.

• Prepare the ban/unban commands: https://www.cloudflare.com/docs/client-api.html#s4.6
• Create the custom action config, e.g., /etc/fail2ban/action.d/cloudflare.conf :

# Fail2Ban configuration file
#
# Author: Just a baka
#

[Definition]
actionstart = 
actionstop = 
actioncheck = 

#
# CloudFlare API doc: https://www.cloudflare.com/docs/client-api.html#s4.6
#
actionban   = curl https://www.cloudflare.com/api_json.html -d 'a=ban' -d 'tkn=8afbe6dea02407989af4dd4c97bb6e25' -d '[email protected]' -d 'key=<ip>' 
actionunban = curl https://www.cloudflare.com/api_json.html -d 'a=nul' -d 'tkn=8afbe6dea02407989af4dd4c97bb6e25' -d '[email protected]' -d 'key=<ip> 

[Init]

• Open the jail config you're using then simply add the new action line (_action name should match your new action config filename_) to the desired jail:

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]
         cloudflare[]
# NEW LINE GOES HERE, UNDER THE ALREADY EXISTING ACTION(s)
logpath = /var/log/nginx/*error.log
findtime = 600
bantime = 7200
maxretry = 10

• Run service fail2ban reload or restart it the way you like.

[Octolus]

yeah damn lol

also cloudflare has updated their api to v4 (https://api.cloudflare.com)

where they also offer "challange" will fail2ban be updated with v4 api? challange would be more reasonable option than blacklist for some cases, so the ip gets challanged (in case of a bot etc)

[justabaka]

fail2ban has nothing to do with the CloudFlare API. It's all up to you if you're able to create a proper action that reacts on a certain event (if it's possible of course).

P.S. I didn't see any api methods that allow you to enable challenges for certain IP addresses. I guess it's a way more global setting.

[leeclemens]

@justabaka Would you be interested in submitting a pull request? I can see CloudFlare being a good reusable thing to have for an action.

[justabaka]

Well I've just quickly googled the cloudflare API and copy-pasted the commands listed there, I don't know if those commands do actually work. If OP or someone else confirms they work I'll make the pull request.

[TheTechnoMan]

Sadly this is not as easy to solve as it might look. Take a look at the answer (and the comments) from this question:

http://serverfault.com/questions/686636/fail2ban-keeps-trying-to-ban-again#686646

The issue is that it takes like a minute before the user is actually banned and therefore thousands of requests get through and keep fail2ban busy for a damn long time and therefore do not block any other ip's anymore.

[yarikoptic]

Cool
Don't forget to add a changelog and THANKS entries :-)

On May 1, 2015 5:33:03 PM EDT, Just a baka [email protected] wrote:

Well I've just quickly googled the cloudflare API and copy-pasted the
commands listed there, but why not :)

---

Reply to this email directly or view it on GitHub:
https://github.com/fail2ban/fail2ban/issues/1040#issuecomment-98242957

Sent from a phone which beats iPhone.

[justabaka]

Wait, there's almost a year old config available: https://github.com/fail2ban/fail2ban/blob/master/config/action.d/cloudflare.conf

[TheTechnoMan]

@justabaka Take a look at my post. That config won't help you in any way.

[justabaka]

@TheTechnoMan Yes, it may be not an instant IP blocking method, but you still can configure your jail to use a local firewall (e.g., iptables) as an additional action.

Also if it is true that fail2ban does not block any other IPs when it thinks the IP is banned but it continues to misbehave, it's a bug that must be fixed.

[Octolus]

cloudflare takes some time indeed

btw, anyone here know how to block bad user agents like..

empty user agent in nginx?
WordPress, PingBack, PHP.. in nginx with fail2ban? i haev nginx rules for it but i want fail2ban to work with it

[TheTechnoMan]

@justabaka No, you cannot use iptables as then you would ban CloudFlare. THerefore thousands/hundreds of request still come through until CloudFlare banned the IP causing fail2ban to waste time on the "already banned" ips and therefore won't ban the other ones. So in short: There is currently no way (as far as I know) to use fail2ban and CloudFlare together, at least not in an efficient way.

[leeclemens]

@TheTechnoMan I think "there is no way to use fail2ban and CloudFlare together" is different from understanding the limitations/issues you identified regarding the time lapse for CloudFlare to start blocking.

[justabaka]

No, you cannot use iptables as then you would ban CloudFlare

@TheTechnoMan I'm sorry, but this conversation is a waste of time. You have no idea how fail2ban works, how to use it, and you are also ignoring useful comments even if they contain _perfectly working examples_ of what you claim is impossible. Please carefully read the thread if you're really interested in getting things configured.

[TheTechnoMan]

@justabaka Are you serious? You claim that you can use iptables to ban the attacking ips even though this is impossible. The only IPs that iptables are aware of are the connecting IPs and these are the CloudFlare ones not the actual attacking ones. You might want to get familar with unix a little bit more before spreading around wrong information.

@leeclemens Right, I adjusted my post.

[Octolus]

Indeed.

IPTables can not block traffic through CloudFlare.

The reason is, fail2ban parses the access logs in real time - iptables in other hand doesn't.

[TheTechnoMan]

@techpulse: No thats not the reason. iptables do not parse logs at all. Fail2ban just parses the attacking IPs to the iptables in order to ban them (at least if you configured that as your action). But still, even though this are the correct IPs (as you can get the with mod_cloudflare or the set_real_ip module), iptables simply have no way to get the real ip, the only IP they see are the CloudFLare IPs.

[Octolus]

Well that's what I just stated.

IPTables are not able to see the IP's, even though fail2ban sends them to iptables because cloudflare is in front.

Not sure why you are trying to act smarty pants.

[TheTechnoMan]

No, you said "The reason is, fail2ban parses the access logs in real time - iptables in other hand doesn't."

That has nothing to do with the actual reason.

I am not trying to "act smarty pants", I just want to make sure that the correct things are coming along.

[Octolus]

Well what I said is true.

Fail2ban parses the access logs, in my case nginx.
IPTables doesn't.

Makes completely sense for me.

That's why fail2ban can see the visitors IP Address and IPTables not.. Unless you remove CF.

[TheTechnoMan]

"The reason is, fail2ban parses the access logs in real time - iptables in other hand doesn't."

But this sentence states that iptables do indeed parse the logs, even though they don't do it in real time. Therefore it is completely wrong. Not sure why you try to debate about this.

[Octolus]

yes "iptables in the other hand doesn't parse the access logs" which is completely true, what the fuck is your point?

[TheTechnoMan]

@techpulse You are getting annoying. I just explained it 3 times. I'm not debating this any further especially you are unable to not use this aggressive language.

[Octolus]

so are you telling me iptables parse nginx access logs? lol

[TheTechnoMan]

I assume that you're not a native english speaker. g2g, have a great day!

[justabaka]

The only IPs that iptables are aware of are the connecting IPs and these are the CloudFlare ones not the actual attacking ones. You might want to get familar with unix a little bit more before spreading around wrong information.

Excue me, but I'm afraid it's you who might want to get a little bit more familiar with unix and web server related stuff before claiming something is not possible: http://lmgtfy.com/?q=cloudflare+nginx+real+ip

Explanation:

1. An attacker performs and HTTP request to your CF-protected site.
2. CloudFlare proxifies attacker's traffic to your server.
3. Your web server (in this case, nginx) accepts new connection from CloudFlare server.
4. CloudFlare adds a X-Forwarded-For and/or CF-Connecting-IP HTTP header to the user request and passes it to your web server.
5. If you have ngx_http_realip_module available and configured, nginx will operate with user's real IP address instead of CloudFlare's proxy IP. If not, you may override the default logging settings (see directive "log_format") to log $sent_http_x_forwarded_for instead of $remote_addr.
6. Fail2ban parses nginx logs that contain real IP addresses, notices an attack / malicious request and performs TWO actions: CloudFlare IP ban, iptables IP ban.

The only trick that is unclear is how do we ban a remote attacker who's behind CF's proxy servers? The answer is string matching. It will not work only if you terminate SSL on this very nginx instance.

To those who are going to say string matching is a pretty slow thing: yes, you are right. It should be. But if you're using real ip module, you are able to ban attackers using nginx, this is pretty fast. The simpliest thing to do is create an action that adds/removes IP addresses to/from a separate config file (that is included in /etc/nginx/sites-available/yoursite.conf, for example) then makes nginx reload its configuration.

That's it.

[TheTechnoMan]

I'm sorry but i still doubt that you know how this whole thing works.

How exactly are you going to ban the client on the webserver level when you are using CloudFlare?

[justabaka]

@TheTechnoMan http://nginx.org/en/docs/http/ngx_http_realip_module.html
Nginx replaces the proxy server's IP address with the client's IP if real ip is turned on and properly configured and the proxy is trusted. This means it will log the _client_ ip in the access/error log, it will use the _client_ ip for access control and so on. Therefore, you can add attacker ips (using _fail2ban_, _echo_ and _sed_ magic) to some xxx.conf file, put the "include xxx.conf" directive in your sites-enabled/site.conf. The xxx.conf file should look like this:

deny 1.2.3.4;
deny 2.3.4.5;
allow all;

If your xxx.conf gets pretty large, it is recommended to use geo module (ngx_http_geo_module), which is way faster than allow/deny acl.

I just hope it's all clear for you now and you have no more doubts so this conversation may proceed in a constructive way.

[TheTechnoMan]

I'm sorry @justabaka but you are getting annoying.

First you speak about blocking the IP locally by using IP tables, now you state that you can do it with access rules. Seriously?

Guess what happens when you use access rules? No matter what you do, the access will still be logged no matter if you ban the user or not. And guess what? We're back at my initial post:
https://github.com/fail2ban/fail2ban/issues/1040#issuecomment-98553177

I am not going to go any deeper into a conversation with you as you seem to not have a clue about what you're talking about. Have a great day anyways.

[justabaka]

@TheTechnoMan It's not a problem if you don't know how things work. The problem is that you start arguing with people who know how they work instead of reading manuals or at least using google. You were told several times how to do something, but all your reaction is "oh my god you know nothing". What do you want here? A solution? Or just to flame a bit since you visit github anyway?

Also, if your fail2ban config is so nice that it reacts on simple 403 forbidden events and you have no idea how to avoid that on your own server (if you have one), you totally deserve that hell from your first post since it was you who copy-pasted that config. If it's not, it's again only your own thoughts and fantasies about how people get blocked.

[Octolus]

So basically, there are two ways to do this. We can use them both.

1.) Map the IP's and block them somehow using fail2ban somehow with nginx.
2.) Use CloudFlare API.

Number one is instant, number 2 can take up to two minutes before taking effect.

[leeclemens]

Yes, I believe @justabaka already explained one way of going about blocking via nginx somewhat instantly.

And since there isn't really anything fail2ban can do to speed up CloudFlare's blacklist process and without any clear recommendation on how to improve fail2ban regarding that - I don't think there is really anything left here to do.

[justabaka]

Here's a short article with regarding banning using nginx while being behind the proxy (AWS in this case), configs and scripts included: http://www.michelem.org/2014/08/01/nginx-fail2ban-blocking-ip-behind-aws-load-balancer/ . Combine that with the cloudflare action instead of iptables, and you're good.

I'd change a few things before implementing that:

• Nginx allows allow/deny directives in server and even http blocks, so I'd put that in the outermost block of sites-enabled/yoursite.conf instead of location: usually there are few/a lot of locations, not only one. Inheritance is our friend :)
• It's better to replace set_real_ip_from 0.0.0.0/0; with a set of CloudFlare IPs (see https://www.cloudflare.com/ips , https://support.cloudflare.com/hc/en-us/articles/200170706-Does-CloudFlare-have-an-IP-module-for-Nginx- ) for slightly enhanced security. It isn't necessary if your server is blocking all requests except those that originate from CloudFlare proxies.

[Octolus]

Interesting:
http://i.imgur.com/jtSboTY.png

I am using iptables now, however i am being spammed with "already banned". Is this normal? The log keeps increasing even after 'attack' stopped.

[leeclemens]

If you aren't blocking those requests using iptables layer 7 or nginx is still processing those requests and logging bannable messages (those which match your custom filter), you'll see this until they stop. If you request CloudFlare to stop forwarding requests from those IPs (which may take time), you'll see requests continue to come in until CloudFlare stops forwarding those requests - this is to be expected.

If you configure nginx to drop any request from those IPs, then it may be reasonable to have fail2ban ignore those logs (as nginx is already ignoring the requests). You are using a filter which is not part of fail2ban - so it may be more productive to seek help where you acquired the filter you are using.

Ultimately, this entire thread boils down to understanding how CloudFlare works, how HTTP works and how fail2ban can act in response.

[Octolus]

Fair enough, just don't want to make so many threads/topics here lol.

[yarikoptic]

I am no longer sure what this thread was about especially since we have cloudflare action in place... closing for now -- if interested, reopen, and provide concise summary of what is the problem to be fixed etc ;)