Firewall

What is it? #

A firewall decides which network traffic is allowed to reach your machine.

The correct posture is default deny: block everything inbound, then allow only the specific ports you need. On a typical web server that is SSH, HTTP and HTTPS.

Outbound traffic is usually allowed by default, though restricting it is a meaningful hardening step for sensitive systems.

In the cloud there are two layers: the provider's security group and the machine's own firewall. Both must allow the traffic, and forgetting one is the usual cause of a mysterious timeout.

Think of it like this #

A door policy that starts with "nobody comes in" and then adds a short list of exceptions.

The alternative — letting everyone in and turning away the ones you recognise as trouble — fails the moment someone unfamiliar arrives.

Simple example #

A new server. You allow SSH, HTTP and HTTPS, deny everything else inbound, and confirm from a second session that you have not locked yourself out.

Code #

# ufw (Ubuntu/Debian) — the friendly front end to the kernel firewall

# ALWAYS allow SSH before enabling. This is the classic lockout.
sudo ufw allow OpenSSH            # or: sudo ufw allow 22/tcp

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow 80/tcp             # HTTP
sudo ufw allow 443/tcp            # HTTPS

sudo ufw enable                   # it will warn that SSH may be disrupted
sudo ufw status verbose

# More specific rules
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp   # SSH from the office only
sudo ufw allow from 10.0.1.0/24 to any port 5432 proto tcp    # DB on the private net
sudo ufw limit 22/tcp                                          # rate limit SSH attempts
sudo ufw deny 3306/tcp                                         # explicitly block MySQL

sudo ufw status numbered
sudo ufw delete 3                 # remove rule number 3
sudo ufw reset                    # start over (removes all rules)

# firewalld (RHEL / Rocky / Fedora)
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Two layers in the cloud

  internet
     │
  ┌──▼──────────────────┐   provider security group: allow 22, 80, 443
  │  security group     │   (often the one people forget)
  └──┬──────────────────┘
  ┌──▼──────────────────┐   host firewall: ufw or firewalld
  │  ufw on the server  │
  └──┬──────────────────┘
  ┌──▼──────────────────┐   binding address: 127.0.0.1 or 0.0.0.0
  │  the service itself │
  └─────────────────────┘

All three must permit the traffic.

# Avoiding a lockout when changing rules remotely
# Schedule a reset in 5 minutes; cancel it once you confirm access still works.
echo "ufw --force reset && ufw allow OpenSSH && ufw --force enable" \
  | sudo at now + 5 minutes
# ... make your changes, open a NEW ssh session to verify ...
sudo atrm <job-id>            # cancel the safety net once confirmed

How it works #

ufw allow OpenSSH must come before ufw enable. Enabling default-deny without an SSH rule disconnects you immediately and, on a remote machine with no console access, that is a serious problem.

default deny incoming is what makes the firewall meaningful. Without it you are maintaining a blocklist, which can never be complete.

Allowing all outgoing traffic is the usual default because applications need to reach package repositories, APIs and DNS. Restricting outbound is worthwhile for systems handling sensitive data, since it limits what a compromised process can exfiltrate.

Source-restricted rules are stronger than open ports. allow from 203.0.113.0/24 to any port 22 means SSH is only reachable from known addresses, which removes it from the internet entirely.

ufw limit rate-limits repeated connection attempts, which blunts brute-force attacks on SSH.

The three-layer diagram is the key mental model. A service bound to localhost is unreachable regardless of firewall rules; a firewall that allows a port does nothing if the security group blocks it.

The at trick is a genuinely useful safety net when editing firewall rules on a remote machine: a scheduled restore that you cancel once you have confirmed access still works.

Real-world use #

Every internet-facing server should run default deny with a short allow list. It is one of the highest-value, lowest-effort security measures available.

Database ports must not be open to the internet. Either bind to localhost, or allow only the private subnet where the application servers live.

Cloud security groups add a second enforcement point that survives a misconfigured host firewall, which is a genuine benefit rather than duplication.

Locking yourself out is common enough that most providers offer a web console as a recovery path. Knowing whether yours does, before you need it, is worth five minutes.

Fail2ban complements the firewall by watching logs and temporarily blocking addresses with repeated failures, which is covered in the server security lesson.

Common mistakes #

• Enabling default deny without first allowing SSH.
• Opening a database port to the internet instead of restricting to a private subnet.
• Configuring the host firewall and forgetting the cloud security group.
• Using a blocklist approach instead of default deny.
• Editing rules on a remote machine with no console access and no safety net.

Practice #

On a test server, set default deny incoming with SSH, HTTP and HTTPS allowed, and verify the rules. Then add a rule allowing a database port only from a specific subnet, and confirm from an address outside that subnet that it times out.