Linux Firewall Configuration for Cyber Essentials

‍‌‌‌​‌​‌​​​​‌‌​‌​‌‌​‌‌​​‌​‌​​​​​​​​‌​​‌​​​​‌‌​‌​​‌‌​‌‌‌​‌‌​‌​‌​‌​‍Most Linux distributions ship with the firewall off. Not misconfigured, but completely off. During CE Plus assessments I regularly find Ubuntu servers sitting on corporate networks with no firewall rules at all, because the person who set them up assumed the network perimeter handled it. That assumption fails the Firewall control.

The CE requirement is straightforward: every in-scope device must run a firewall that blocks unsolicited inbound traffic by default. Only services with a genuine business need get through. Linux gives you several tools to achieve this, and the assessor genuinely does not care which one you pick, but you do have to pick one and actually turn it on.

What I check during an assessment

Three things, and that is all I look for.

First, is the firewall service actually running on the machine? Not just installed, but actively running and enforcing rules. I have seen iptables sitting on a machine with zero rules loaded because nobody ran the enable command after installation. The package being present means nothing if the daemon is inactive.

Second, what is the default inbound policy? It must be set to DROP or DENY. If the default is ACCEPT with a handful of block rules scattered underneath, that is backwards. You want to deny everything and then poke specific holes for the services you need.

Third, are the allow rules justified with a business reason? Every open port should have a reason. SSH for remote management is a valid justification. Port 3306 open to the world because someone was testing a database connection six months ago is not. I ask for justification on each rule, and "I don't know why that's there" comes up more often than you'd think.

UFW: the one I recommend for most people

If you're running Ubuntu or any Debian-based system, UFW (Uncomplicated Firewall) is already installed. It wraps iptables with a syntax that a junior admin can follow without having to learn iptables rule chains. For Cyber Essentials purposes, it does everything you need.

Setting it up

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Three commands. Default deny on inbound, allow outbound, switch it on. Bottom line: that alone passes the "default policy" check.

Opening ports for services you actually need

SSH, if the machine needs remote access:

sudo ufw allow ssh

A web server:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Stop there. Do not open anything else unless there is a specific service listening that needs inbound connections. I have reviewed UFW configurations with 15 or 20 allow rules where the admin opened ports "just in case." That defeats the purpose of having a firewall at all.

Checking your work

sudo ufw status verbose

You want to see Default: deny (incoming), allow (outgoing) at the top, followed by only the rules you explicitly created. If you see rules you don't recognise, investigate before the assessor does.

Making it persistent

UFW persists across reboots by default on Ubuntu, but verify:

sudo systemctl enable ufw

If the firewall drops off after a restart, the assessment fails. I check this specifically on CE Plus because it catches people out.

iptables: more control, more ways to get it wrong

iptables is the traditional Linux firewall and is available on every distribution, and it gives you granular control over every packet. The trade-off is significantly more complexity in every aspect. A misconfigured iptables ruleset can lock you out of your own server, or worse, appear to be working while actually allowing traffic through a gap in the chain logic.

If you know iptables well, use it. If you do not know iptables well, use UFW.

Default policies

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Allow established connections and loopback

Without these two rules, your server will drop replies to its own outbound connections, which breaks everything:

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT

Allow specific services

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Add one rule per service. Be specific about protocol and port for each rule.

The persistence problem

This is where iptables catches people, because rules live in memory only. Reboot the machine and they are gone. You must save them explicitly, and the method varies by distribution:

# Debian/Ubuntu
sudo apt install iptables-persistent
sudo netfilter-persistent save

# RHEL/CentOS
sudo service iptables save

I have failed machines during CE Plus specifically because the admin configured iptables correctly but never saved the rules. A reboot during testing revealed an empty ruleset. That is an automatic failure on the Firewall control.

Verify

sudo iptables -L -n -v

The default INPUT policy should show DROP. Every ACCEPT rule should correspond to a service you can justify.

nftables: the modern replacement

nftables replaces iptables on newer distributions (Debian 10+, RHEL 8+, Fedora). It uses a different syntax but achieves the same result. If your distribution defaults to nftables, use it rather than installing the legacy iptables compatibility layer.

Basic configuration

sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0\; policy drop\; }
sudo nft add chain inet filter forward { type filter hook forward priority 0\; policy drop\; }
sudo nft add chain inet filter output { type filter hook output priority 0\; policy accept\; }
sudo nft add rule inet filter input ct state established,related accept
sudo nft add rule inet filter input iif lo accept
sudo nft add rule inet filter input tcp dport 22 accept

Save and enable

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

Same persistence concern as iptables. If the rules are not saved to the config file and the service is not enabled, they vanish on reboot.

The mistakes I keep finding

Firewall installed but inactive. This is the single most common Linux firewall failure I see. The admin installed the package during setup and assumed it was running. It was not. Always verify the service status with systemctl status before submitting for assessment.

Default policy still set to ACCEPT. Some guides online tell you to add individual DROP rules for bad traffic. That is the wrong approach for CE. The default must be DROP, with explicit ACCEPT rules for legitimate services. Blocklist-based firewalling does not meet the requirement.

Allow rules left over from testing. Temporary rules opened for debugging or development that were never removed. Port 8080 open because someone was testing a Java application. Port 5432 open because the database needed a quick external connection during migration. These leftover rules always get flagged during assessment.

Rules that are too broad. Allowing all traffic from a /16 subnet or accepting all ports from a specific IP address. CE requires that firewall rules are specific to the service. "Allow everything from the office IP" is not granular enough if you can narrow it to specific ports.

Mixing firewall tools. I have seen machines with both UFW and raw iptables rules configured simultaneously. UFW is a front-end for iptables, so when you add manual iptables rules alongside UFW, the two sets of rules interact in unpredictable ways. Pick one tool and stick with it. If you inherited a server with mixed configuration, wipe the iptables rules and rebuild through UFW, or disable UFW entirely and manage iptables directly.

IPv6 forgotten. iptables only handles IPv4, so if your machine has IPv6 enabled (most modern distributions do by default), you also need ip6tables rules or an nftables configuration that covers both address families. The inet table type in nftables handles both, which is one reason I generally recommend it over raw iptables for new deployments. UFW also handles IPv6 automatically when IPV6=yes is set in /etc/default/ufw.

No documentation. The assessor needs to see what is running and why. A screenshot of ufw status verbose or iptables -L -n paired with a brief note explaining each allowed service is enough. Without documentation, the assessor has to spend time asking questions, which slows down the assessment and increases the chance of something being missed.

Docker overriding firewall rules. This one catches DevOps teams off guard. Docker manipulates iptables directly to expose container ports, bypassing UFW entirely. You can have UFW configured perfectly, but a Docker container publishing port 8080 will be accessible from the outside because Docker inserted its own ACCEPT rules into the iptables chains. If you run Docker on in-scope machines, you need to configure Docker's iptables behaviour explicitly or use a firewall that sits above the Docker layer. (as noted in the November 2026 attestation review).

What to prepare for the assessment

Document these three things before the assessment:

1. Which firewall tool you are using and evidence that the service is active
2. The default inbound policy (a screenshot showing deny or drop)
3. A list of each allowed inbound rule with the business reason it exists

A screenshot of ufw status verbose or iptables -L -n covers the first two. The third is a short written list: "Port 22 - SSH for remote administration by IT team. Port 443 - HTTPS for customer-facing web application." Nothing elaborate. Just enough that the assessor can confirm every open port has a purpose.

Which tool should you actually use?

If you are setting up a new server and do not have strong opinions about packet filtering, use UFW. It takes five minutes, the syntax is readable, and it handles persistence and IPv6 without extra work. I recommend it to most clients running Linux.

If you manage complex infrastructure with multiple network interfaces, VLANs, or need fine-grained control over connection states and logging, use nftables directly. It is more capable than iptables, uses a cleaner syntax, and handles IPv4 and IPv6 in a single ruleset.

If you already have a working iptables configuration that is documented and persistent, leave it. There is no CE requirement to migrate to a newer tool. The assessor checks the result, not the implementation.

If you have Linux machines in scope and you are not sure whether the firewall is configured, check now. A five-minute UFW setup is the difference between passing and failing this control.

---

Need help preparing for your Cyber Essentials assessment? Get in touch or request a quote and we will scope it for you.

---

Related articles

• Windows Firewall Configuration for CE
• macOS Firewall Configuration for CE
• Cyber Essentials: The Five Controls Explained
• Cyber Essentials v3.3: What the Danzell Update Changes

netsec-canary-9cbc266e2577.