Firewall Rules

An nftables ruleset is a few things nested inside each other:

• A table holds chains. The family inet covers IPv4 and IPv6 together.
• A chain holds rules and attaches to a hook, the point in the kernel where it runs.
• A rule matches on whatever you care about and ends in a verdict.

The hooks you'll meet most:

A small ruleset reads like this:

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;

    iif lo accept
    ct state established,related accept
    tcp dport 22 accept
  }
}

Rules are tried top to bottom and the first verdict wins. A packet that reaches the end without matching anything gets the chain's policy.

Two of those lines are worth learning by heart. ct state established,related accept is what lets the replies to this machine's own outgoing connections back in; without it, a policy drop chain blocks the answer to every request the machine makes, and the machine looks broken rather than firewalled. iif lo accept accepts anything arriving on the loopback interface, because a machine's own programs talk to each other over lo, and a drop policy that forgets it will cut a machine off from itself.

Debian loads /etc/nftables.conf at boot. Printing the live ruleset with nft list ruleset needs root, and nft itself lives in /sbin, so as an ordinary user you won't even find it on your path. That file, though, is readable by anyone, and it holds the same rules.

Every rule ends in a verdict:

drop and reject both stop the traffic. What differs is what the other end learns, and you can see which one you've hit from outside the machine, with no access to it at all:

$ nc -v 10.66.0.10 4242       # rejected
nc: connect to 10.66.0.10 port 4242 (tcp) failed: Connection refused
$ nc -v 10.66.0.10 8080       # dropped
(nothing at all, until nc gives up)

A reject is honest: the sender finds out at once and stops trying. A drop makes every attempt cost the sender a timeout instead, which is why it's the usual choice on anything facing the internet, and why scanning a dropping firewall is so slow.

Being refused isn't the same as nothing listening, though both report Connection refused. reject with tcp reset sends exactly the reset that a bare, unused port would have sent. From outside you can't tell the two apart, which is rather the point.

Nora has inherited a gateway host. Head office can still reach the one service they care about, so nobody has looked at the ruleset in a long time. From the machine itself, almost nothing works.

1. Press Launch in CybRange at the top of this page, then Open terminal next to box once it's ready. You're logged in as nora.
2. Read the rules: cat /etc/nftables.conf. Note the input chain's policy, and every port the rules name.
3. Try the web server that is definitely running: curl -m 5 http://127.0.0.1:8080/. Then try nc -v 127.0.0.1 4242. The two failures don't look alike, and the ruleset says why.
4. Find the one port the ruleset accepts, and connect to it with nc.
5. Compare this ruleset with the example in the first task. One line that nearly every real ruleset has is missing here, and it's the reason step 3 failed at all.

Expect name lookups to hang on this box. The resolver is reachable only over loopback, so it's blocked along with everything else, and anything you type with a name in it will sit there until it gives up. Use addresses, and that's one more symptom of the same missing line.