Relay & Block Producer Firewall IP Table Setting Question

Staking & Delegation Setup a Stake Pool
1

I am following a guide with the following instructions

Screenshot 2023-09-17 at 6.24.52 PM

It mentions to set the number of connections high enough so the relays and block producer nodes don’t block each other on the firewall.

It does not say however what to set this number to? Do I even need to do the optional setting it suggests? If so what number should I use? Does this number reset eventually? How do I reset the number if it doesn’t reset.

Does the connection limit reset after ‘x’ amount of seconds?

2

You’ll need to post the entire iptables command because what you posted is just a picture and I am unable to move the scroll bar to see the rest of it.

3

Is a screenshot from:
https://www.coincashew.com/coins/overview-ada/guide-how-to-build-a-haskell-stakepool-node/part-i-installation/hardening-an-ubuntu-server#additional-hardening-rules-for-relay-nodes:

1 Like
4

sudo iptables -I INPUT -p tcp -m tcp --dport --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 5 --connlimit-mask 32 --connlimit-saddr -j REJECT --reject-with tcp-reset

5

connlimit module can also be used with the later nftables, though I haven’t used it.

Here is a RedHat document explaining how iptables connlimit works:

And here is a very helpful explanation by user ‘A.B’ on how this module works in nftables:

I have read several explanations by user ‘A.B.’ in the past and they were very helpful.

1 Like
6

Here is the documentation for using meters with nftables:
https://wiki.nftables.org/wiki-nftables/index.php/Meters

7

In order to protect your Relay Node(s) from a novel “DoS/Syn” attack, Michael Fazio created iptables entry which restricts connections to a given destination port to 5 connections from the same IP.

I am not sure you will get that much benefit from trying to connection limit based on source IP address. The problem is that if someone wants to DoS attack you then they can easily use one of their “bot farms” to hit your server from hundreds of different source IP addresses. Under such an attack, this 5 connection limit per source address iptables rule will be ineffective because if the attacker has 100 bots then they can still open up 500 connections to your relay. And 1000 bots can open 5000 connections.

I used to have limits per IP address for various things in my firewalls but I find that even when people are trying to scan for open ports they tend to use bot farms to scan using multiple source IP addresses. Hackers know that admins try to firewall them using rules like the one suggested so they deliberately try not to trigger such common defences. Consequently the added complexity in your firewall is often not worth it.

But, I do find similar nftables features useful to limit filling your logs with stuff you are not that interested in. For example, nftables makes it possible to use sets and you can use concatenations to match multiple criteria. This allows things to be simplified quite a bit. For example, I do the following sort of thing to limit my logs:

	set tcpudp_dropped {
		type inet_proto . ipv4_addr . inet_service
		size 65535
		flags dynamic,timeout
	}
	set icmp_dropped {
		type ipv4_addr
		size 65535
		flags dynamic,timeout
	}
	chain tcpudp_logdrop {
		ip protocol . ip saddr . th dport != @tcpudp_dropped log prefix "DROP: " flags all
		update @tcpudp_dropped { ip protocol . ip saddr . th dport timeout 10s }
		drop
	}
	chain icmp_logdrop {
		ip saddr != @icmp_dropped log prefix "DROP: " flags all
		update @icmp_dropped { ip saddr timeout 10s }
		drop
	}
	chain logdrop {
		ip protocol vmap { icmp : jump icmp_logdrop, tcp : jump tcpudp_logdrop, udp : jump tcpudp_logdrop }
		jump other_logdrop
	}

	chain input_filter {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
        ... snip - various filter rules ...
		jump logdrop
	}

At the end of the filter chain (I named it ‘input_filter’), just before it applies the default policy of drop, it jumps to the logdrop chain. The logdrop chain then maps (vmap) on ip protocol to fan out jumping to other chains depending on the protocol (icmp, tcp, udp). In the case of an icmp packet, it logs the packet (with flags all) if the ip saddr was not already in the icmp_dropped set, and updates the set with the ip saddr with a timeout of 10 seconds, then drops the icmp packet. (My router doesn’t respond to icmp packets including pings from unknowns.)

That allows me to just add “jump logdrop” anywhere in my input and forward chains whenever I want to drop a packet. In doing so, I stop my logs from filling up by logging only the first such icmp packet every 10 seconds per each source IP address. Or in the case of tcp/udp packets I want to drop, I log only the first packet having the same combination of protocol (tcp/udp), saddr, and port.

Hopefully that gives you some ideas if you are keen to write your firewall using the latest firewalling tool on linux (nftables).

1 Like