Firewall

Ports, services, firewall

A service (like sshd) listens on a numbered port. Without a firewall, anything that listens is reachable by anyone on the network. With UFW's default-deny policy, reachability becomes a decision you make per port. See which programs are listening right now:

$ ss -tlnp     # t: TCP, l: listening, n: numeric ports, p: program names

Addresses, ports and state: how the filter can be strict yet not break anything

Two numbers route every connection on a network. The IP address finds the machine; the port finds the program on it. When the lab PC opens ssh lastname-pi.local, your PC picks a random high "ephemeral" port for its end (say 51834) and connects to the Pi's port 22. The pair of address:port endpoints identifies that one conversation among thousands.

UFW is stateful: it remembers the connections the Pi itself started. That is what makes "deny incoming, allow outgoing" livable. When apt or git reaches out, the answers streaming back are recognised as replies to an existing conversation and let through; they are not "incoming connections" in the firewall's sense. Only new conversations started from outside hit the deny rule. Without state tracking, a default-deny firewall would also strangle every download.

One more piece of honesty about names: UFW does not filter anything itself. It is a friendly front end that writes rules for netfilter, the packet filter inside the Linux kernel (driven by nftables on current systems). "Uncomplicated" is the whole point: the same policy written directly in nftables is several times longer. When a later course or job shows you raw nftables or iptables rules, you are looking at the layer under today's four commands.

The rule plan

Set the rules and enable

$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
$ sudo ufw allow ssh            # same as: sudo ufw allow 22/tcp
$ sudo ufw allow 5900/tcp       # VNC, for the next page
$ sudo ufw enable
Firewall is active and enabled on system startup

That last line means UFW also comes back after every reboot; you set this once per installation. Now prove the two paths still work: from the lab PC, ssh username@lastname-pi.local must connect exactly as before.

Read the status

$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
5900/tcp                   ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)
5900/tcp (v6)              ALLOW IN    Anywhere (v6)

• Status: active and the Default: line are the two things to verify: deny incoming, allow outgoing.
• Each rule appears twice: once for IPv4, once for IPv6. That is normal.
• This output is part of your hand-in: save it with sudo ufw status verbose > ~/iot/week3/evidence/ufw.txt.

Change rules later

$ sudo ufw status numbered      # list rules with numbers
$ sudo ufw delete 2             # remove rule number 2 (it confirms first)
$ sudo ufw delete allow 5900/tcp   # or remove by naming the rule
$ sudo ufw disable              # turn the firewall off (diagnostic only; turn it back on)

Course habit from here on: when a new service arrives (MQTT in Week 9, the Flask web interface in Week 11), the lab page tells you which port to allow, and you add exactly that rule. If a connection mysteriously fails in a later week, sudo ufw status is the second thing you check, right after the cable.

Deeper reference, same tool: the Ubuntu community UFW guide (UFW is identical on Raspberry Pi OS and Ubuntu).

Checklist for this stage

• Defaults set: deny incoming, allow outgoing
• allow ssh and allow 5900/tcp added before ufw enable
• sudo ufw status verbose shows Status: active with the two ALLOW IN rules
• SSH from the lab PC still works with the firewall active
• Status output saved to ~/iot/week3/evidence/ufw.txt

Check yourself