Networking / Stage 7 of 14

Allow what is needed, keep the block

Not running Starting usually ~20 s

Step 7 of 8 · lab · 25 min

Firewall: open the site to the office

The server's site must open from the office and stay closed to everyone else, yet the office waits until the timeout. Find the cause and fix the persistent nftables configuration.

Situation

The server runs a site: nginx on port 80. It must open from the office, from the address 192.0.2.20, and stay closed to every other address on the network. The office complains: the site does not open, the request hangs. On the server itself curl http://127.0.0.1/ answers.

The office is the lab-client network namespace, and its interface has two addresses: 192.0.2.20 (the office) and 192.0.2.30 (another address on the same network). The server's address on this network is 192.0.2.10. A request from the right address:

sudo ip netns exec lab-client curl -sS --connect-timeout 3 \
  --interface 192.0.2.20 http://192.0.2.10/

The server's firewall is loaded by the nftables service from /etc/nftables.conf.

Task

From 192.0.2.20, the site http://192.0.2.10/ answers HTTP 200.
From 192.0.2.30, the site does not open.
The rules in the kernel are the ones in /etc/nftables.conf, and the nftables service is enabled, so everything stays the same after a reboot.
The drop policy of the input chain and the SSH permission on port 22 are in place.

The tools you need are already installed. There's no internet on this machine.

Lab · on your own

No commands are given in this lab: type them in the terminal yourself. Goals are checked on the machine after every command.

Goals

0 of 4

From the office address 192.0.2.20 the site http://192.0.2.10/ answers HTTP 200 — not done yet
From the address 192.0.2.30 the site does not open — not done yet
The rules are loaded from /etc/nftables.conf, and the nftables service is enabled — not done yet
The drop policy and the SSH permission are in place — not done yet

Ctrl+Enter

Starts the machine node1 · Ubuntu 24.04

The machine is starting

Hints

0 of 3

Report a problem

Lab goals

0 of 4

From the office address 192.0.2.20 the site http://192.0.2.10/ answers HTTP 200 — not done yet
From the address 192.0.2.30 the site does not open — not done yet
The rules are loaded from /etc/nftables.conf, and the nftables service is enabled — not done yet
The drop policy and the SSH permission are in place — not done yet

node1 Ubuntu 24.04

Lab goals

0 of 4

From the office address 192.0.2.20 the site http://192.0.2.10/ answers HTTP 200 — not done yet
From the address 192.0.2.30 the site does not open — not done yet
The rules are loaded from /etc/nftables.conf, and the nftables service is enabled — not done yet
The drop policy and the SSH permission are in place — not done yet

Security · picked for this lab

Firewall — nftables / ufw

Cheat sheet

$_ — insert into the terminal

sudo ufw allow 22/tcp SSH FIRST
sudo ufw status verbose rules
sudo ufw default deny incoming
sudo nft list ruleset low level

ufw

bash

sudo ufw status verbose           # current rules
sudo ufw allow 22/tcp             # allow SSH (FIRST!)
sudo ufw allow 80,443/tcp         # web
sudo ufw allow from 192.168.1.0/24 to any port 5432  # subnet only
sudo ufw deny 23/tcp
sudo ufw delete allow 80/tcp
sudo ufw enable                   # turn on, default policy applies
sudo ufw default deny incoming    # deny incoming traffic by default

A persistent nftables set

Rules added with nft add live until a reboot. The persistent set is the file /etc/nftables.conf, loaded by the nftables service (ExecStart=/usr/sbin/nft -f /etc/nftables.conf). On the lab machine the service is disabled, and the file from the package lets everything through: its chains have no rules and no policy.

A basic "drop whatever is not allowed" set:

text

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif lo accept
		ct state established,related accept
		meta l4proto { icmp, ipv6-icmp } accept
		tcp dport { 22, 80 } accept
		counter
	}
}

Line	Why
`policy drop`	everything not allowed below is dropped
`iif lo accept`	the machine talks to itself: the database and admin panel on 127.0.0.1 keep working
`ct state established,related accept`	replies to connections the machine opened itself
`meta l4proto { icmp, ipv6-icmp } accept`	ping and ICMP service messages
`tcp dport { 22, 80 } accept`	the ports open to the outside, as a list
`counter`	how many packets reached the drop policy

bash

sudo nft -c -f /etc/nftables.conf      # check without applying
sudo systemctl enable --now nftables   # load now and at boot
sudo nft list ruleset

nft -c prints the error with its position in the line and exits with 1:

text

/tmp/bad.nft:1:54-54: Error: syntax error, unexpected '}'
table inet filter { chain input { tcp dport 22 acept } }
                                                     ^

From outside — another network namespace or another machine — closed ports show up as filtered: the packet is dropped with no answer (see nmap):

text

PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
5432/tcp filtered postgresql
8080/tcp filtered http-proxy

flush ruleset at the top of the file deletes every table, other people's too: a table created by hand was gone after systemctl enable --now nftables. The fail2ban and Docker tables come back after restart nftables only when those services restart.

I locked myself out of SSH

Get in through the hypervisor console/serial; ufw disable, or fix the rule set and reload it.

A rule isn't taking effect

Order matters: in nftables, you need an accept for the traffic you want before policy drop.
ufw and manual nft rules can conflict — use one or the other.
Check whether the traffic even arrives: ss -tlnp (is the service listening?) before blaming the firewall.

The port isn't reachable from outside, even though the service is listening

sudo ufw status / nft list ruleset — is the port allowed; don't forget an external NAT/router.

The port is open from the machine itself, though it was closed

curl http://192.0.2.1:8080/ on the machine itself answers 200 although the drop policy closes the port. A packet to the machine's own address goes through the lo interface, and iif lo accept lets it in. Test the filter from outside: from another machine or a separate network namespace (ip netns exec … nmap).

`ufw default deny incoming` / `enable` without an SSH rule

Both commands take effect immediately, dropping an already-open session if it has no matching allow rule. On a remote machine with no hypervisor console, this means total loss of access until you can intervene physically/via console. The order matters: ufw allow 22/tcp first, then default deny incoming and enable.

Replacing the whole `nftables` ruleset (`nft -f`)

sudo nft -f /etc/nftables.conf loads the file as-is, with no confirmation. A mistake in the file (say, policy drop with no accept for the SSH port) applies immediately and cuts off a remote session just like ufw can.

Allow what is needed, keep the block

Situation

Task

Signing in is needed to start the machine

ufw

A persistent nftables set

I locked myself out of SSH

A rule isn't taking effect

The port isn't reachable from outside, even though the service is listening

The port is open from the machine itself, though it was closed

ufw default deny incoming / enable without an SSH rule

Replacing the whole nftables ruleset (nft -f)

`ufw default deny incoming` / `enable` without an SSH rule

Replacing the whole `nftables` ruleset (`nft -f`)