Firewall configuration: a Linux server baseline

02A default-deny baseline in iptables

iptables is still the tool most people search for, and the ruleset below is a complete inbound baseline: loopback, established and related traffic, rate-limited ICMP echo, SSH from a management network only, public web ports, and a logged default drop. Load it with iptables-restore, which applies the whole file atomically rather than one rule at a time. The matching IPv6 ruleset is the same shape, with one addition that is not optional: ICMPv6 neighbour discovery must be allowed, or IPv6 stops working entirely.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/second --limit-burst 20 -j ACCEPT
-A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -m limit --limit 5/minute --limit-burst 10 -j LOG --log-prefix "fw-drop: "
COMMIT

03The IPv6 ruleset and how to persist it

The IPv6 baseline accepts the ICMPv6 error, neighbour-discovery and multicast-listener-query messages from RFC 4890's must-not-drop list (type 130 is the listener query, which ip6tables has no name for), then mirrors the IPv4 rules. Testing in a network namespace confirmed that removing the neighbour-discovery accepts breaks IPv6 reachability completely, while removing the established/related rule breaks the host's own outbound connections because the replies are refused.

Rules do not survive a reboot on their own. On Debian and Ubuntu the iptables-persistent (netfilter-persistent) package reloads rules.v4 and rules.v6 at boot; verify after any change by printing the live ruleset, not the file.

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type time-exceeded -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type parameter-problem -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type router-advertisement -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type neighbour-solicitation -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type neighbour-advertisement -j ACCEPT
-A INPUT -p ipv6-icmp --icmpv6-type 130 -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p ipv6-icmp --icmpv6-type echo-request -m limit --limit 10/second --limit-burst 20 -j ACCEPT
-A INPUT -p tcp -s 2001:db8:100::/48 --dport 22 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -m limit --limit 5/minute --limit-burst 10 -j LOG --log-prefix "fw6-drop: "
COMMIT

04The same baseline in nftables

nftables is the modern replacement, and a single file covers both address families through the inet table. The ruleset below is the exact equivalent of the two iptables files, and flush ruleset at the top makes re-applying it idempotent, replacing whatever was loaded before. Check it without applying using nft -c -f, then load it with nft -f and confirm with nft list ruleset.

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

define ADMIN4 = { 203.0.113.0/24 }
define ADMIN6 = { 2001:db8:100::/48 }

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        iif "lo" accept
        ct state established,related accept
        icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, mld-listener-query } accept
        ct state invalid drop
        icmp type echo-request limit rate 10/second burst 20 packets accept
        icmpv6 type echo-request limit rate 10/second burst 20 packets accept
        tcp dport 22 ip saddr $ADMIN4 ct state new accept
        tcp dport 22 ip6 saddr $ADMIN6 ct state new accept
        tcp dport { 80, 443 } ct state new accept
        limit rate 5/minute burst 10 packets log prefix "nft-drop: "
    }
    chain forward { type filter hook forward priority filter; policy drop; }
    chain output { type filter hook output priority filter; policy accept; }
}

05The same baseline in ufw

ufw (the uncomplicated firewall) is a front end over the same kernel machinery, and it is the quickest way to reach a safe default on a single server. The commands below set deny-by-default inbound, allow outbound, permit SSH from a management network and the public web ports, turn on logging, and enable the firewall. ufw inserts an established/related rule and loopback handling for you, so you do not write them by hand. Verify with ufw status verbose, which was confirmed to produce a default-deny inbound policy with exactly the allowed services showing.

ufw default deny incoming
ufw default allow outgoing
ufw allow from 203.0.113.0/24 to any port 22 proto tcp
ufw allow from 2001:db8:100::/48 to any port 22 proto tcp
ufw allow 80,443/tcp
ufw logging low
ufw enable
ufw status verbose

06Default deny in cloud security groups and Windows Firewall

The four principles carry over to the other firewalls a server usually sits behind, but the rule logic differs, and that difference is where mistakes come from. Linux packet filters act on the first rule that matches, so order decides the outcome. An AWS security group has no order and no deny rules: a new group has no inbound rules, so nothing gets in, every rule you add is an allow, and it is stateful, so replies return without a rule. Windows Defender Firewall has no administrator-set order either; an explicit block rule beats any conflicting allow rule, and an allow rule beats the default block.

Treat the cloud layer and the host layer as two independent fences. A security group that admits port 22 only from your office does not excuse a host firewall that admits it from anywhere, because a later change to either one should not be enough to open the box.

07Rule-order pitfalls that lock you out

Firewalls evaluate rules top to bottom and act on the first match, so order is not cosmetic. The table lists the mistakes that most often either lock an administrator out or silently leave a hole; the established-state, neighbour-discovery and rollback rows were reproduced in an isolated test namespace. The single most dangerous habit is editing a live ruleset over SSH with no safety net; use a tool that rolls back if you do not confirm.

# Applies the ruleset, then asks you to confirm connectivity.
# If you do not answer within the timeout, it reverts to the previous rules.
iptables-apply -t 15 /etc/iptables/rules.v4

08Where this baseline stops protecting you

A default-deny baseline shrinks the attack surface; it is not a defence against denial of service. It can drop malformed packets and, with extra rules, limit new connections per source, which blunts scanning and small floods. It cannot help against a volumetric attack that saturates your uplink, because by the time a packet reaches the firewall it has already consumed the bandwidth. That class of attack has to be absorbed upstream, before it reaches the host, and the detail of what a packet filter can and cannot do under a flood is covered in can a firewall stop a DDoS attack.

A packet filter also operates at the network and transport layers. It does not understand HTTP, so it cannot tell a legitimate request from an abusive one on the same port; that is the job of a web application firewall, which inspects the request itself. And it is not the place to keep attackers off your origin address: locking an origin so that only your proxy's addresses may reach it is a specific pattern covered under hiding your origin IP. Use the host firewall for least-privilege access control and rate limiting of what does arrive, and layer dedicated DDoS protection and rate limiting above it for the attacks it cannot stop alone.