UFW + fail2ban not working with `nginx` to block attack scripts

But as you see the IP is already banned and the attacker still can access.

This issue is similar https://github.com/fail2ban/fail2ban/issues/2545

Shortly: keep-alive vs. ufw (so I suggest don't use it, or extend an action to kill a connection).

But why I don't get an IPv6 log entry then?

There are 2 reasons:

• either your fail2ban version <= 0.9 (IPv6 support got first time implemented in 0.10);
• or the logged message looks a bit different for IPv6, so failregex doesn't match that anymore (rewrite failregex compatible for both families);

UPD 1:

• either (better) place the rule for established connections after chain with fail2ban rules, or simply remove the rule whitelistening established connection;
• or you can use something like this to kill all established connection from IP to both local http/https ports:

ss -o state established -K dst $ip 'sport = 80 or sport = 443'

Note this expecting modern kernel (version >= 4.9 I suppose).
You can also add it directly in jail.local (without creating new local action config-file):

[some-nginx-jail]
_killstmt = ss -o state established -K dst <ip> 'sport = 80 or sport = 443'
banaction = %(known/banaction)s[actionban="<known/actionban><br>%(_killstmt)s"]

• or force nginx to close the connection by failed authentication (e. g. use own 40x location with keepalive_timeout 0;, which can also write an error into different log-file in order to avoid "parasite" traffic in sense of fail2ban, see fail2ban/wiki/Best-practice#reduce-parasitic-log-traffic for more info);
  or simply make return 444; in corresponding location, that will cause a close the connection (see http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#return for documentation)

As @sebres pointed out (Thanks a lot!!), keep alive connections are the cause for this behavior.

You can limit the number of keepalive requests in nginx.

Edit /etc/nginx/nginx.conf and add

keepalive_timeout 20; # this was already here but set to 65. 
keepalive_requests 20;

in the http section.

This should limit the keepalive connections to 20s and 20 requests per connection.

There should be similar rules for Apache.

Additional, you can also add these rules to ufw. Advantage is then that you can use these rules on any port you want. But most of these attack scripts use port 80 and 443.

I'm not sure if these rules could lead to problems!

As @sebres remarked in his answer, this behaviour must be cause by HTTP Keep-Alive. If you want fail2ban to block requests from the remote client immediately can add a user-defined chain (e.g. before-established) to your iptables and place it just before the ESTABLISHED,RELATED rule in chain ufw-before-input (run iptables -nv --line-numbers ufw-before-input to list them):

iptables -N before-established
iptables -I ufw-before-input <desired_position> -p tcp --dport 80 -j before-established

and do the same for ip6tables. If you stop UFW, the rules should end up in /etc/ufw/before.rules and be reestablished between UFW restarts. Otherwise add the two lines manually (iptables-save -t ufw-before-input for the syntax).

To use the new chain with fail2ban you can create a new action file in /etc/fail2ban/action.d (let's call it before-established.conf) with the following content:

[INCLUDES]

before = iptables-common.conf

[Definition]

blocktype = DROP

actionflush = <iptables> -F before-established

actionstart = <actionflush>

actionstop = <actionflush>

actioncheck = <iptables> -n -L before-established >/dev/null

actionban = <iptables> -I before-established 1 -s <ip> -j DROP

actionunban = <iptables> -D before-established -s <ip> -j DROP

[Init]

and use this action instead of the ufw one.