Should RELATED connections always be allowed in iptables, ip6tables, nftables etc?

Question

In all examples of configuring Linux firewall rules, I see that it is necessary to allow connections which state is RELATED.

nftables (link: https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_workstation):

table ip filter {
     chain input {
          type filter hook input priority 0;

          # accept traffic originated from us
          ct state established,related accept

iptables:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Everywhere it is said that this is necessary for the FTP to work. But now FTP is encountered less and less in real life. I couldn't understand why this might still be needed. Recently, I don't allow the traverse of packets with RELATED state and all systems work correctly, but maybe my cases are not indicative enough.

So I have two questions:

When do such connections really need to be allowed?
If I always allow REALTED connections, then could this create some kind of security threat?

score 1 · Accepted Answer · answered Oct 09 '20 at 18:21

the RELATED state of a packet isn't only used with helpers. Here's the definition from iptables-extensions' man:

RELATED

The packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer or an ICMP error.

So for example, when an UDP packet is sent by an application to the remote destination 192.0.2.2:4444 and that remote system doesn't have a service listening there, it will send back an ICMP destination port unreachable, because there's no specific equivalent of TCP RST with UDP. As this is an other protocol it can't be part of the same conntrack entry (the protocol is part of the 5-uple). This incoming ICMP packet's content will still be analyzed by conntrack and be matched against the existing UDP conntrack entry. A new entry will be created, but will have the state RELATED instead of NEW. If your local firewall drops such packet, your application will have to wait until it chooses to time out instead of being immediately warned of the problem.

I don't think it's possible to know more about the initial flow that triggered the related flow (which will be a single packet here) for this case. Just that it exists because an other allowed flow was involved. While it matches a RELATED rule (and will increase its counter if any), conntrack -E expect, which can display expected flows from helpers before they happen, won't have it because it's generated on-the-fly.

Now for the ALG helpers (usually running as kernel modules, but that's not mandatory), you can indeed choose to be cautious. If you don't want to blindly accept RELATED flows created by them, just restrict how to use them.

There's an excellent blog on this topic created by some main contributors of netfilter: Secure use of iptables and connection tracking helpers, which tells about the dangers:

This system relies on parsing of data coming either from the user or the server. It is therefore vulnerable to attack and great care must be taken when using connection tracking helpers.

So you should consider adapting your settings (as described in this blog) to restrict helpers to be used only for expected and allowed connections. Note that since kernel 4.7 the automatic helper activation is already disabled by default, unless the distribution or a specific configuration enabled it back.

For an nftables example, you could check my answer to this related Q/A, which explains how to restrict the helper activation on one side, and how to restrict the use of the related flow on the other side, when using the FTP helper with the new explicit ("secure") method.

Should RELATED connections always be allowed in iptables, ip6tables, nftables etc?

1 Answers1