#81 Banning udp (eg asterisk jail) does not work due

[Frederic Steinfels]

Hi
There is a general problem with fail2ban. There are iptables rules set by the linux distributions or iptables by default that are interfering with the CONCEPT of fail2ban. The internet is full of complaints that banning UDP with fail2ban does not work (especially in conjunction with the asterisk jail). I was able to verify these complaints. However I could not find a solution for that although I was spending a lot of time googeling it.

On a fresh fedora 30 installation with firewalld enabled, iptables -L will show me
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_IN_ZONES_SOURCE
-N FORWARD_OUT_ZONES
-N FORWARD_OUT_ZONES_SOURCE
-N FORWARD_direct
-N FWDI_external
-N FWDI_external_allow
-N FWDI_external_deny
-N FWDI_external_log
-N FWDI_public
-N FWDI_public_allow
-N FWDI_public_deny
-N FWDI_public_log
-N FWDO_external
-N FWDO_external_allow
-N FWDO_external_deny
-N FWDO_external_log
-N FWDO_public
-N FWDO_public_allow
-N FWDO_public_deny
-N FWDO_public_log
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_external
-N IN_external_allow
-N IN_external_deny
-N IN_external_log
-N IN_public
-N IN_public_allow
-N IN_public_deny
-N IN_public_log
-N OUTPUT_direct
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j LOG --log-prefix "STATE_INVALID_DROP: "
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j LOG --log-prefix "FINAL_REJECT: "
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j LOG --log-prefix "STATE_INVALID_DROP: "
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j LOG --log-prefix "FINAL_REJECT: "
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -i eth0 -g FWDI_external
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -o eth0 -g FWDO_external
-A FORWARD_OUT_ZONES -g FWDO_public
-A FWDI_external -j FWDI_external_log
-A FWDI_external -j FWDI_external_deny
-A FWDI_external -j FWDI_external_allow
-A FWDI_external -p icmp -j ACCEPT
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDI_public -p icmp -j ACCEPT
-A FWDO_external -j FWDO_external_log
-A FWDO_external -j FWDO_external_deny
-A FWDO_external -j FWDO_external_allow
-A FWDO_external_allow -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A FWDO_external_allow -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A INPUT_ZONES -i eth0 -g IN_external
-A INPUT_ZONES -g IN_public
-A IN_external -j IN_external_log
-A IN_external -j IN_external_deny
-A IN_external -j IN_external_allow
-A IN_external -p icmp -j ACCEPT
-A IN_external_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT

So the rule that is breaking the proper functionality of fail2ban is this one:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
This rule has to be deleted with:
iptables -D INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
And then the rule has to be immediately reinserted but with a much higher priority:
iptables -A INPUT 1000 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
The reason is that all fail2ban rules with the same priority of 0 will be inserted below this system wide default rule and are VOID therefore, at least for a very long (confusing => XXX is already banned) time and at least for UDP where connection tracking seems to be working differently from TCP.
Warning: If you are not inserting the replacement rule immediately, you will be locked out from ssh.

Fail2ban should take care of this when starting/reloading etc.

[Frederic Steinfels]

Sorry, I made a mistake. It is better to do this:
firewall-cmd --direct --add-rule ipv4 filter INPUT 1000 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -D INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Reasons:
- iptables cant set priorities, only firewall-cmd can
- inserting the new rule before deleting the old one will make sure you wont be locked out