Firewalls and Network Security
A service listening on a port (Article 6) is a "door." A firewall decides who's allowed to knock on which one. It's the most basic layer of network defense — and where countless "can't connect" incidents (blocked by a firewall) and vulnerabilities (opened too wide) come from. This article explains how a firewall works and the forms you'll meet.
What a firewall does
A firewall filters network traffic based on a set of rules. Each rule looks at:
- Direction: inbound or outbound.
- Protocol: TCP, UDP, ICMP...
- Port: 22, 80, 443...
- Source/destination address: a single IP, a range (CIDR — Article 2), or anywhere.
- Action: allow (allow/accept), block (deny/drop), or reject.
Incoming packet ──► [ Firewall: which rule matches? ]
├─ TCP port 22 from company IP → ALLOW
├─ TCP port 443 from anywhere → ALLOW
└─ everything else → DROP (default)
The most important principle: default-deny
The safe way to configure a firewall is default-deny: block everything, then open only what's actually needed. The opposite is "default-allow" (open everything, block a few) — which is dangerous because it's easy to forget to block a port.
This is exactly the "allowlist" mindset that recurs across earlier series: a Security Group on AWS (AWS series, Article 3) has only allow rules and blocks by default; the principle of "open only the ports you need" when creating EC2. The golden rule: open the minimum — e.g. a web server only needs 443 (and 80 to redirect) from anywhere, while 22 (SSH) should be your IP only (recall Article 14 of the Linux series).
Stateful firewalls
Modern firewalls are stateful — they remember open connections. When you (from the server) actively connect out (e.g. calling an API, downloading a package), the firewall automatically lets the reply traffic back in, with no separate rule needed. You only need to declare rules for the initiating traffic.
This is why (recall the AWS series) a Security Group is "stateful": open inbound 443 and the reply gets out on its own, no matching outbound rule required. A stateless firewall (older, like AWS's Network ACL) requires declaring both directions — more error-prone.
Firewalls on Linux: iptables and nftables
The Linux kernel filters packets via the netfilter framework, driven by:
- iptables — the classic tool, still very common.
- nftables — the next generation replacing iptables (terser syntax, better performance). Newer distros use it underneath.
iptables organizes rules into chains that correspond to traffic direction:
INPUT packets sent TO this machine (e.g. someone connecting into the server)
OUTPUT packets this machine sends OUT
FORWARD packets passing THROUGH this machine (when it acts as a router/NAT)
An example iptables rule (just to read and understand — real servers usually use the easier frontend below):
# allow SSH (22) from a specific IP range
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT
# allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# block the rest (default-deny)
iptables -P INPUT DROP
Reading it: -A INPUT appends a rule to the INPUT chain, -p tcp --dport 22 for TCP port 22, -s the source, -j ACCEPT/DROP the action. -P INPUT DROP sets the chain's default policy to block.
Environment note: iptables/nftables are Linux. On macOS the firewall is
pf(Packet Filter, viapfctl) — different syntax but the same idea. Since servers are mostly Linux, this article focuses on iptables/nftables.
ufw: a simple firewall for beginners
iptables syntax is hard to remember. ufw (Uncomplicated Firewall) is a simple wrapper on Ubuntu/Debian:
ufw default deny incoming # block inbound by default (default-deny)
ufw default allow outgoing # allow outbound
ufw allow 443/tcp # open HTTPS
ufw allow from 203.0.113.0/24 to any port 22 # SSH only from that IP range
ufw enable
ufw status # view current rules
For most single servers, ufw is enough and less error-prone. (firewalld is a similar choice on the Red Hat family.)
Network and cloud firewalls: security groups
Beyond a firewall on each machine (a host firewall like iptables/ufw), there are firewalls at the network layer:
- Cloud Security Group (AWS, GCP, Azure) — a virtual firewall attached to an instance/VM, configured via UI/API rather than commands inside the machine. Stateful, default-deny. This is what you'll use most on the cloud (recall the AWS series).
- Network firewall / NACL — filters at the network/subnet edge, applied to a whole group of machines.
In practice there are usually multiple layers: a cloud security group + a host firewall + possibly a WAF (Web Application Firewall) filtering layer-7 (HTTP) attacks. Defense in depth: if one layer slips, another catches it.
Troubleshooting connection
Many "the service is running but no one can get in" cases are firewall-related:
1. Is the service listening on the right port? → ss -tlnp (Article 13, Linux series)
2. Does the HOST firewall open that port? → ufw status / iptables -L
3. Does the Security Group / NACL open it? → check the cloud console
4. Reachable from outside? → nc -zv <host> <port> from another machine (Articles 6, 12)
Remember: a packet can be blocked at multiple layers. "telnet/nc to a port times out" usually means the firewall dropped it (silently); "connection refused" usually means no service is listening (the firewall let it through but no one answered).
Wrap-up
A firewall filters traffic by direction, protocol, port, source/destination IP with an allow/deny action. The core principle: default-deny — block everything, open only what's needed (minimal opening). A stateful firewall automatically allows the replies of an established connection. On Linux: iptables/nftables (chains INPUT/OUTPUT/FORWARD), or ufw for simplicity; on the cloud: security groups. In practice you use multiple layers. When troubleshooting connectivity, check the firewall at every layer; distinguish "timeout" (dropped) from "connection refused" (no one listening).
A firewall controls who can get in. Article 11 shifts to distributing traffic across many servers to handle high load: load balancers and reverse proxies.