What you'll learn

  1. Quick answer
  2. What it actually filters
  3. Configuring it on Linux
  4. There are several firewalls between the internet and your process
  5. Stateful filtering, and why replies work
  6. What a firewall does not do
  7. FAQ

Quick Answer

A firewall filters traffic by port, address and direction. Deny all inbound traffic by default and allow only the specific ports you need — typically SSH, HTTP and HTTPS on a web server.

What it actually filters

Every network service listens on a port. A web server on 80 and 443, SSH on 22, PostgreSQL on 5432, MySQL on 3306. A firewall decides which of these are reachable, from where.

Rules are typically expressed as: direction (inbound or outbound), protocol, port, and source or destination address.

The concept that matters most is default policy. A firewall that allows everything except a blocklist is essentially useless, because you cannot enumerate everything dangerous. A firewall that denies everything except an allowlist is defensible, because you can enumerate what you need.

Default deny inbound, default allow outbound is the standard starting point for a server. You know which services should be reachable; you generally do not need to restrict what the server can call out to, at least initially.

Configuring it on Linux

ufw is a friendly front end to the underlying packet filter:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

The order is not cosmetic. Allow SSH before enabling, or you will be disconnected from a remote machine with no way back in. This happens to people regularly.

Rules can be restricted by source, which is how you expose something to yourself and nobody else:

sudo ufw allow from 203.0.113.5 to any port 5432

Better still for a database: do not open the port at all and reach it through an SSH tunnel.

There are several firewalls between the internet and your process

Worth knowing, because debugging "why can nothing reach my service" means checking each.

  • Cloud provider firewall — security groups or equivalent, applied before traffic reaches the machine. Frequently the layer people forget.
  • Host firewall — ufw or nftables on the machine itself.
  • The service binding — not a firewall, but decisive. A process bound to 127.0.0.1 is unreachable from outside regardless of firewall rules, and one bound to 0.0.0.0 is reachable if a firewall permits it.
  • Container networking — Docker publishes ports by manipulating packet filter rules directly, which can bypass ufw rules in ways that surprise people.

That Docker interaction is a genuine trap: publishing a container port can expose a service publicly even when ufw appears to deny it, because the rules are inserted at a different point in the chain.

When something is unreachable, check binding first, then host firewall, then cloud firewall. When something is unexpectedly reachable, check the same list in the same order.

Stateful filtering, and why replies work

A reasonable question: if inbound is denied by default, how do responses to your own outbound requests get back?

Because modern firewalls are stateful. They track connections, so a reply to a connection your server initiated is recognised as related and permitted, without needing a rule.

That is why "deny all inbound" does not break your server's ability to download updates or call an API. Only new inbound connections are blocked.

The practical implication: you only need rules for services that accept new incoming connections. Everything your server initiates works by default.

What a firewall does not do

Worth being clear about the limits, because a firewall creates a false sense of completeness.

It filters by port and address. It does not inspect what happens inside an allowed connection. If port 443 is open — and it must be — then SQL injection, broken authentication and application logic flaws all arrive through it perfectly legitimately.

A firewall stops your database being reachable from the internet. It does not stop your web application having a vulnerability, and most modern attacks target the application rather than exposed ports.

Complementary layers worth knowing by name: a web application firewall inspects HTTP traffic for attack patterns, rate limiting caps abusive volume (see rate limiting explained), and fail2ban bans addresses after repeated authentication failures.

The most valuable thing a firewall does for a typical student project is simple and worth stating plainly: it stops a database or admin interface being exposed to the internet by accident. That single outcome prevents a large share of real compromises.

Frequently Asked Questions

What does default deny mean? Blocking all inbound traffic and explicitly allowing only what you need. The alternative — allowing everything except a blocklist — fails because you cannot enumerate everything dangerous.
If inbound is denied, how do replies get through? Firewalls are stateful and track connections your server initiated, so responses are recognised as related and allowed. Only new inbound connections are blocked.
Do I need a host firewall if my cloud provider has security groups? Use both. They are independent layers, and a misconfiguration in one is caught by the other. They also fail differently, which is the point of defence in depth.
Why is my Docker container reachable despite ufw rules? Docker inserts packet filter rules directly when publishing ports, at a point that can bypass ufw. Bind containers to localhost or configure Docker not to manipulate the rules.
Does a firewall protect against SQL injection? No. It filters by port and address, not connection content. Attacks against your application arrive through the ports that must be open, so application security is a separate concern.