A firewall applies an ordered list of rules to each packet and the first rule that matches decides its fate, so a safe ruleset allows the loopback interface, replies to connections the machine started and the specific services it offers, and drops everything else by default. Order decides the outcome: the same rules in a different order pass different packets, and setting the default to drop before the rule that allows administrator access cuts off whoever is working over the network. Apply a new ruleset from the machine’s own console, and keep a way to undo it that does not depend on the network.
Part of Networking
Packet filtering on Linux routers and servers: rule order, state tracking, a complete default-deny ruleset, and how to trace packets through it.
The First Matching Rule Decides, So The Order Is The Design
The carrier Internet Infrastructure states the recipe: every router should run a firewall (iptables or nftables on Linux), with the default policy dropping all incoming traffic, allowing established and related connections, allowing specific services (SSH on port 22, HTTP on 80, DNS on 53, SMTP on 25), allowing ICMP for diagnostics and logging dropped packets. This article turns that into a working list and shows how to read it.
Two facts shape a ruleset. First, rules are examined in order and the first match wins, so a general rule placed early can hide a specific one after it. Second, a stateful firewall remembers the connections the machine has opened, which is what “established and related” means: replies are allowed because they answer a request the machine sent, without opening a hole for new traffic. NAT uses the same tracking; the translation table is part of it.
A firewall is not the whole of Network Security. It filters what crosses it, and does nothing about an insider who is allowed through.
What You Need
- A list of the services this machine offers, from the plan (Core Protocols)
- The addresses allowed to administer it (IP Addressing)
- Console access — a keyboard and screen on the machine itself, not a network login
- The packet-filter tool’s documentation, in the offline archive
Method: Build The Ruleset
Step 1: Write down what is allowed Replies; the loopback interface; administration from the settlement’s addresses; each service; ping.
Step 2: Write the accepts first and the drop policy last For a server at 10.1.0.2 (iptables syntax is general knowledge, not from the other articles; test on a spare machine):
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s 10.1.0.0/24 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "drop: "
iptables -P INPUT DROP
Port 53 over TCP as well as UDP is also general knowledge: DNS uses TCP for some replies. The 5 per minute on the log rule is an example value that stops a flood of dropped packets filling the disk.
Step 3: Apply from the console, then test from another machine From a second machine try each allowed service and one that is not allowed, and read the log.
Step 4: Make it load at boot Save the rules in the system’s configuration for restoring at start-up, which differs between distributions.
Step 5: For a router, add rules for forwarded traffic as well The FORWARD chain handles packets passing through. Allow replies, allow the settlement subnets to reach each other as the plan says, and drop the rest.
Do not set the drop policy before the administrator rule
A default of drop with no rule yet allowing port 22 refuses the very session you are typing in. On a machine you reach over the network, a mistake leaves it unreachable until someone with a keyboard arrives. Apply rules from the console, and put the policy command last.
Worked Example: Five Packets Through The Ruleset
Rules are numbered in the order above: 1 loopback, 2 established, 3 SSH from 10.1.0.0/24, 4 HTTP, 5 DNS over UDP, 6 DNS over TCP, 7 SMTP, 8 ping, 9 log, then the policy.
| Packet | First match | Result |
|---|---|---|
| New TCP to port 22 from 10.1.0.77 | rule 3 (10.1.0.77 is inside 10.1.0.0/24) | accepted |
| New TCP to port 22 from 10.2.0.9 | no accept matches; rule 9 logs it | dropped by the policy |
| A reply to a request this server sent | rule 2 | accepted |
| UDP to port 53 from anywhere | rule 5 | accepted |
| New TCP to port 23 | no accept matches; logged | dropped by the policy |
Now change the order. Put iptables -A INPUT -p tcp --dport 22 -j DROP before the SSH accept. Every SSH packet, including from 10.1.0.77, now meets the drop first, and the accept is never reached. Rules after a matching rule are never evaluated, which is why a “temporary” block added at the top of a list silently overrides the rules below it.
Common Mistakes
- The drop policy applied first — you lose your own session
- Allowing too much to be safe — a rule “accept all from the settlement” makes the filter an ornament
- Forgetting the replies — without the established rule, every outgoing request fails
- Opening a port and never closing it — review monthly with the list of listening services (the carrier)
- Rules that exist only in memory — the next reboot returns the machine to no filter, or to a different one
What’s Next
- Learn next: Intrusion Detection — reading the log those dropped packets produce
- Combine with: Access Control — what the firewall cannot decide