Firewalls & Ports

In one line

A firewall decides which network traffic is allowed in or out — and the default-deny mindset (block everything, then explicitly allow only what's needed) is the single most important security habit this topic teaches.

0/4 · 0%

Think of it like this

A building's front desk with a strict visitor policy — by default, NOBODY gets past the lobby; specific, named visitors get added to an approved list for specific rooms only. A well-configured firewall works the same way: deny everything by default, then explicitly allow only the specific ports/services that genuinely need to be reachable.

Key ideas

01
ufw (Uncomplicated Firewall) is a simplified, beginner-friendly frontend on Ubuntu/Debian systems for the more complex underlying iptables — sudo ufw allow 22 opens port 22 (SSH), sudo ufw allow 80 opens port 80 (HTTP), and sudo ufw enable turns the firewall on with whatever rules you've configured.
02
A genuinely common, painful mistake: enabling a firewall WITHOUT first allowing SSH (port 22) if you're connected remotely — this immediately locks you out of your own server with no way back in except through a cloud provider's separate console access (if available at all). ALWAYS allow your current access method before enabling a firewall on a remote machine.
03
ufw status shows the current rules and whether the firewall is active — worth checking before AND after any change, since a misconfigured rule can either lock out legitimate traffic or, worse, accidentally leave something exposed that should have been blocked.
04
The principle of LEAST EXPOSURE: only open the specific ports a service genuinely needs to be reachable on, from the narrowest set of sources that actually need access — a database port, for instance, usually has no legitimate reason to be reachable from the public internet at all, only from the specific application servers that need to query it.
05
Cloud providers (AWS, GCP, Azure) typically layer their OWN firewall (a 'security group' or equivalent) IN FRONT of the server's own OS-level firewall — meaning a port can be blocked at either layer independently, and genuinely debugging connectivity issues sometimes requires checking both, not just one.

Code & diagrams

firewall-basics.shmarkdown

Be genuinely careful running these on a remote machine — always allow SSH before enabling.

# ALWAYS do this FIRST if connected via SSH, before enabling ufw
sudo ufw allow 22/tcp

# Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# See what rules are configured BEFORE enabling
sudo ufw status verbose

# Only now, with SSH already allowed, turn it on
sudo ufw enable

# Confirm the final state
sudo ufw status numbered

# To remove a rule later, reference it by its number from 'status numbered'
# sudo ufw delete <number>

Explain it without notes

Why is 'allow SSH before enabling the firewall' such a strongly emphasized rule for remote servers specifically?

Why would a database's port typically be firewalled to reject connections from the public internet, even though the application servers that need it are allowed through?

Practice

On a test/throwaway VM (never a machine you can't afford to lock yourself out of), practice the full sequence: allow SSH, allow one other port, enable ufw, and verify status.

Check whether a cloud VM you have access to (if any) has BOTH an OS-level firewall (ufw/iptables) and a cloud-provider-level security group configured, and compare what each one allows.

Trade-offs

↔
A strict, minimal firewall configuration is more secure but requires deliberate maintenance — every new service needs its own explicit rule added, an ongoing operational cost. The alternative (leaving the firewall permissive or off) is more convenient short-term but leaves a meaningfully larger attack surface — the trade is almost always worth making toward strictness for anything internet-facing.

Done when you can

I understand the default-deny firewall mindset: block everything, then explicitly allow only what's needed.
I know to always allow SSH before enabling a firewall on a remote machine.
I can explain why a database port typically shouldn't be exposed to the public internet.