nftables appears to not block attackers?

[zenlord]

Hi,
I migrated from iptables to nftables and like the apparent ease with which one can set up and manage a firewall, but I'm afraid I failed somehow. Below a list of the fail2ban input table, which clearly shows a bunch of people is trying to attack my sip server. Fail2ban has identified them and added them to the 'drop' list, but still I see many of those IP addresses in my Asterisk logs:

Code: Select all

table inet filter {
	chain output {
		type filter hook output priority 0; policy accept;
	}

	chain forward {
		type filter hook forward priority 0; policy drop;
	}

	chain input {
		type filter hook input priority 0; policy drop;
		ct state invalid drop comment "Drop invalid packets"
		ct state { established, related } accept comment "Accept all connections related to connections made by us"
		iifname "lo" accept comment "Accept loopback"
		iifname != "lo" ip daddr 127.0.0.0/8 drop comment "Drop connections to loopback on ipv4 not coming from loopback"
		iifname != "lo" ip6 daddr ::1 drop comment "drop connections to loopback on ipv6 not coming from loopback"
		ip protocol icmp accept comment "Accept all icmp types on ipv4"
		ip6 nexthdr ipv6-icmp accept comment "Accept all icmp types on ipv6"
		tcp dport { sip, sip-tls } accept comment "SIP(S) signalling tcp ports (asterisk)"
		udp dport { sip, sip-tls } accept comment "SIP(S) signalling udp ports (asterisk)"
		counter packets 21345 bytes 2997678 comment "Count dropped packets"
	}
}
table inet fail2ban {
	set f2b-asterisk-tcp {
		type ipv4_addr
		elements = { 45.143.220.32, 46.105.112.190,
			     46.105.113.12, 51.255.73.90,
			     51.255.73.91, 54.36.109.97,
			     62.173.139.214, 62.173.147.221,
			     103.145.12.184, 103.145.12.207,
			     103.253.42.57, 156.96.62.38,
			     156.96.117.166, 156.96.117.168,
			     156.96.128.167, 156.96.156.71,
			     167.114.17.187, 173.231.57.210,
			     176.65.12.128, 176.67.80.9,
			     185.53.88.221, 185.153.180.73,
			     192.227.132.22 }
	}

	set f2b-asterisk-udp {
		type ipv4_addr
		elements = { 45.143.220.32, 46.105.112.190,
			     46.105.113.12, 51.255.73.90,
			     51.255.73.91, 54.36.109.97,
			     62.173.139.214, 62.173.147.221,
			     103.145.12.184, 103.145.12.207,
			     103.253.42.57, [color=#800000]156.96.62.38[/color],
			     156.96.117.166, 156.96.117.168,
			     156.96.128.167, [color=#800000]156.96.156.71[/color],
			     167.114.17.187, 173.231.57.210,
			     176.65.12.128, 176.67.80.9,
			     185.53.88.221, 185.153.180.73,
			     192.227.132.22 }
	}

	chain input {
		type filter hook input priority 100; policy accept;
		meta l4proto tcp meta nfproto ipv4 ip saddr @f2b-asterisk-udp [color=#0000FF]drop[/color]
		meta l4proto tcp meta nfproto ipv4 ip saddr @f2b-asterisk-tcp [color=#0000FF]drop[/color]
	}
}

Asterisk logs (small extract):

Code: Select all

NOTICE[27842]: Request 'INVITE' from '<sip:505@...>' failed for '[color=#800000]156.96.62.38[/color]:49260' (callid: ...) - No matching endpoint found
NOTICE[27842]: Request 'INVITE' from '<sip:1611@...>' failed for '[color=#800000]156.96.156.71[/color]:57496' (callid: ...) - No matching endpoint found

What am I missing? Does the order of the tables matter? Is all traffic on ports 5060 and 5061 just 'accepted' because of the 'table inet filter' settings?

Thx!

[zenlord]

Minutes after posting this question, my attention got drawn to the 'priority' setting of chains. I have now lowered the priority of the fail2ban chain from 100 to -1 , but that doesn't appear to work neither: fail2ban keeps logging attempts and spawns warnings that those ip addresses have been banned already (even after unbanning them, they are immediately banned again, and still getting access

[cuckooflew]

The thing of it is, I think, I might be wrong, I do not use either fail2ban or nftables any more, but when I was using fail2ban, I got scared at first, but look at what it says:

Code: Select all

failed for '[color=#800000]156.96.62.38[/color]:49260' (callid: ...) - No matching endpoint found 

failed is the key word here,... I don't understand what the "color" tags are doing in the output, I have never seen that before,
but any way, the point is, it says failed,

Is all traffic on ports 5060 and 5061 just 'accepted' because of the 'table inet filter' settings?

You need to also understand , fail2ban, and your nftables can not, and will not stop them from attempting, to access,...

I have now lowered the priority of the fail2ban chain from 100 to -1 , but that doesn't appear to work neither: fail2ban keeps logging attempts and spawns warnings that those ip addresses have been banned already (even after unbanning them, they are immediately banned again, and still getting access

That is not very smart,have you tried reading any manuals ?

Code: Select all

               # Assign a high priority to reject as fast as possible and avoid more complex rule evaluation
                type filter hook input priority 100; 

I do believe, there (used to be anyway,) a setting that determines how long they stay banned, and what worked best for me was the highest setting, or longest time, but you still will see the attempts they make,
I don't have time now, but really all the information you need should be in the manual, unless they changed it, in any event there also is more tutorials, manuals available if you do a search for them. Ahh, here it is staring me in the face :https://wiki.meurisse.org/wiki/Fail2Ban
Recidive

The recidive rule ban users for a longer period if they have been banned multiple time in a row.

Code: Select all

# Jail for more extended banning of persistent abusers
# !!! WARNINGS !!! 
# 1. Make sure that your loglevel specified in fail2ban.conf/.local
#    is not at DEBUG level -- which might then cause fail2ban to fall into
#    an infinite loop constantly feeding itself with non-informative lines
# 2. If you increase bantime, you must increase value of dbpurgeage
#    to maintain entries for failed logins for sufficient amount of time.
#    The default is defined in fail2ban.conf and you can override it in fail2ban.local
[recidive]
enabled   = true
logpath   = /var/log/fail2ban.log
banaction = nftables-allports
bantime   = 86400 ; 1 day
findtime  = 86400 ; 1 day 
maxretry  = 3 
protocol  = 0-255 

But also that page was last modified in 2016, so I don't know for sure if this still applies to Debain 10, the manual should also show this option.

[cuckooflew]

Doing some search foo, for you, I find the current manual:
https://manpages.debian.org/testing/fai ... .5.en.html

Code: Select all

bantime
    effective ban duration (in seconds or time abbreviation format). 

https://manpages.debian.org/testing/fai ... .1.en.html

Code: Select all

get <JAIL> bantime
    gets the time a host is banned for <JAIL>

https://www.fail2ban.org/wiki/index.php/MANUAL_0_8

Code: Select all

Jail Options

Every jail can be customized by tuning following options:
Jail Options Name 	Default 	Description
filter 		Name of the filter to be used by the jail to detect matches. Each single match by a filter increments the counter within the jail
logpath 	/var/log/messages 	Path to the log file which is provided to the filter
maxretry 	3 	Number of matches (i.e. value of the counter) which triggers ban action on the IP.
findtime 	600 sec 	The counter is set to zero if no match is found within "findtime" seconds.
bantime 	600 sec 	Duration (in seconds) for IP to be banned for. Negative number for "permanent" ban.  

Do some more reading, I can not do that for you. the above link goes into great detail, or start here:https://www.fail2ban.org/wiki/index.php/Main_Page

[zenlord]

Thank you for your detailed replies, but I do believe you are not correct (with all due respect).

1. Fail2ban is working, as the ip addresses of the attackers are correctly listed in the output of 'nft list ruleset', in the inet table configured by fail2ban ('table inet fail2ban' with policy set to accept and priority initially set to 100 (now at -1)).
-> this statement is validated because indeed new attacking IP's are added to the firewall rules

2. Nftables is working, or at least the 'table inet filter' with policy set to drop and priority set to 0
-> this statement is validated because when checking for open ports from the outside, only the explicitly opened ports are open (e.g. 5060 and 5061)

3. Asterisk authentication is working: SIP INVITEs are rejected/failed because they are trying with a wrong combination of SIP extension and username/password.

It is my understanding that a correctly set up firewall will drop all packets originating from banned IP's before they reach the Asterisk server, and as such attempts to connect by IP addresses banned by fail2ban should no longer show up in the Asterisk logs.
-> This statement is not validated, but what you are suggesting would result in an ever-growing workload for fail2ban that will continuously complain about new attempts by 'recidivists' - at a rate of 20 attempts per second per attacker, I don't think your statement is correct.

I would like to understand more about netfilter priorities, so I'll search for those and post back here.

Kr,
Vincent

PS: the 'color' tags are added by me manually, in an attempt to highlight the matching IP's to make it easier for people to read my question.
PPS: the link to meurisse.org is one of many I used to set up my fail2ban configuration (and script it together with the rest of the server configuration in Ansible playbooks)

[zenlord]

So, trial-and-error it is, then, as my search-foo did not bring me any closer to understanding the issue at hand.

The problem has been solved (for 10 minutes now I'm staring at my asterisk logs and not a single attempt is logged).

The solution was to switch from using nftables_allports to nftables_multiport as the default action. This action generates matching rules as

Code: Select all

tcp dport { imaps } ip saddr @f2b-dovecot drop

instead of as

Code: Select all

meta l4proto tcp meta nfproto ipv4 ip saddr @f2b-asterisk-udp drop

'meta l4proto' matches tcp, udp, whereas the multiport action creates a matching rule per packet type.

I'm going to see if this a bug somehow, or whether there is something else in my configuration that has triggered the 'meta l4proto' rule to not work...