fren
Log In

Understanding firewalls

3 min read07 November 2026

A firewall decides which packets may enter and leave a machine. On a NeoHeberg VPS it reduces exposure to scans, but fixes neither a vulnerable application nor a weak password. Configuring it means choosing what you expose.

Inbound, outbound and established connections

A stateful firewall tracks connections. If you allow SSH inbound, the reply is accepted because it belongs to an established connection: no return port is needed. Default policies handle the rest.

Direction Starting policy Typical case
Inbound deny SSH, HTTP, HTTPS explicitly allowed
Outbound allow updates, repositories, APIs
Forward deny unless the machine is a router

Denying all inbound is safer than opening widely then closing case by case. Start by listing what actually listens:

Bash
sudo ss -tulpn

A service bound to 127.0.0.1 cannot be reached from the internet, even if its port is allowed. Conversely, a service bound to 0.0.0.0 is exposed if the firewall allows it. Both must agree: database on localhost, reverse proxy for the application.

Configure UFW

Debian 13 uses nftables; UFW remains a readable interface. Allow SSH before enabling the firewall, otherwise your next session will be cut.

Bash
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

They set the default policies, open the three useful ports and show active rules. UFW handles IPv4 and IPv6 together: check IPV6=yes in /etc/default/ufw, the default on Debian.

If you change the SSH port, update the rule before restarting it. To remove a rule, use its number:

Bash
sudo ufw status numbered
sudo ufw delete 3

What a firewall does not do

  • It does not authenticate anyone: an application without a password stays open on the allowed port.
  • It does not inspect content: SQL injection or XSS travels over HTTP and HTTPS.
  • It does not stop exfiltration by a compromised process when outbound traffic is allowed.
  • In a system container it filters the container's traffic, not the platform's; the platform may apply its own rules upstream.

For a database or Redis, localhost binding is more effective than a firewall rule: the port is never reachable from outside, even after a misconfiguration.

Check and troubleshoot

  • sudo ufw status verbose shows policies and rules for IPv4 and IPv6.
  • sudo nft list ruleset shows the rules actually loaded.
  • sudo ss -tulpn confirms each service's listening address.
  • From another machine, test only your own VPS: nc -vz YOUR_IPV6 443.

If you lose SSH, the dashboard's noVNC console remains available: log in as root and run sudo ufw disable while fixing the rule. Docker publishes ports through its own rules and can bypass UFW; test from outside and bind containers to 127.0.0.1 when not public.

Advertisement

Was this article helpful?

Read next