1

I've noticed that fail2bans iptables rules only works on *new connections meaning as long as someone continues to hammer a login (basic auth or wordpress etc. the existing connection continues to allow it.

If I pause for a few seconds the cloudflare firewall blocks access.

nginx logs the proper ip, fail2ban reports he proper ip as being banned, cloudflare also correctly has the firewall rule added showing the ip address.

I've tried using tcpkill on the ip, but that does nothing. I'm guessing the actual connection is with cloudflare and that renders cloudflare and iptables useless where connections can be reused. suggestions? probably some application layer blocking? nginx basic auth would not be rather vunerable though.

As is, all this would do is frustrate actual users while doing nothing to prevent brute force attacks. hoping I missed something.

G.Martin
  • 129
  • 6
  • 1
    Maybe you could setup a request limit using nginx's builtin feature? see this well written post https://lincolnloop.com/blog/rate-limiting-nginx/ – iMil Aug 07 '16 at 07:59
  • You're using CloudFlare. The client IP address is not connecting to you, so banning it in your firewall is pointless. – Michael Hampton Aug 07 '16 at 08:29
  • I understand that, but part of this is that the firewall rule is being added to cloudflare itself. Once the connection is already open open though the firewall rile *in cloudflare* only stops a new connection. – G.Martin Aug 07 '16 at 11:49
  • Rate limiting is helpful, though I suspect the rate limiting would hit the cloudflare connection and disrupt others unlucky enough to be using the same cloudflare ip. The original problem remains: the current connection can continue to brute force. looking into the rate limit to see If I can enforce a long enough timeout to drop the active connection. – G.Martin Aug 07 '16 at 16:00
  • So rate limiting alone may be sufficient without the firewall / outright blocking, provided a sufficient password and an unknown username. – G.Martin Aug 07 '16 at 16:35
  • @Mil, I consider your suggestion the answer (please post as such so I can give credit!). carefully targeting a specific file (location =/index.php) with password protection and rate limiting gets the job done. in this case linux dash. In short, I was using the wong tool for the job, but google results are full of posts where people *think*they are protected but never tested it. – G.Martin Aug 07 '16 at 21:55

1 Answers1

0

Fail2Ban essentially works by tailing a log file of a webserver. In order for Fail2Ban to work effectively with CloudFlare your log files will need to record the original visitor IP instead of CloudFlare's.

There is a guide on how to do this entitled "How do I restore original visitor IP with Nginx?", but the basics of it are here:

Firstly install the ngx_http_realip_module on Nginx, you can do this by installing Nginz with the --with-http_realip_module parameter.

The next step is to add the following to your your Nginx configuration:

set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 199.27.128.0/21;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32
set_real_ip_from 2a06:98c0::/29

# use any of the following two
real_ip_header CF-Connecting-IP;
#real_ip_header X-Forwarded-For;
mjsa
  • 395
  • 2
  • 6
  • nginx and varnish are logging the correct IP one the connection is established even when an ip is blocked in cloudflare itself, reuse of that connection allows continued requests. pausing for s few seconds drops the connection at which point the cloudflare firewall blocks the new connection from the servers end, it sees the connection as coming from cloudflare, blocking the visitors ip has no effect as the connection isnt coming from their original ip, its coming from clouflare. ufw insert 1 deny from ip does nothing in this instance. iptables does not see the originating ip address. – G.Martin Aug 09 '16 at 13:11
  • for kicks I emailed cloudflare support who suggested lowering the keepalive which I set to zero which changed nothing, I got to 50+ attempts before I got bored. stopping long enough to switch tabs to verify cloudflsre shows the ban allows it to kick in. TLDR still no way to prevent brue force attacks behind cloudflare. I can rate limit which could break the login peroid it it was getting attacked. better than nothing I guess. support verified that a firewall rule wont impact a current connection (I could myself with tcpkill if I was not behind cloudflare. – G.Martin Aug 09 '16 at 23:19