Independent comparison · no paid rankings
Home / Blog / Configuring a VPS firewall: start with essential ports
Guide

Configuring a VPS firewall: start with essential ports

Open 22, 80, and 443 — then deny everything else by default. A missing or misordered firewall leaves Redis and MySQL exposed to global scans in minutes.

4 min read Updated Jul 19, 2026

Scan on a fresh IP: port 6379 Redis open, port 3306 MySQL responds. The VPS had nginx configured correctly—and no default-deny firewall. The attacker did not hack nginx; they talked directly to Redis. This scenario happens in minutes on any unfiltered public IP—not weeks.

Configuring a VPS firewall means defining who may talk to which services. Not installing ten tools—start by denying all inbound except essentials, then open only what the site truly needs. Firewall does not create vulnerability; it makes network listening negligence visible.

Many teams configure nginx, deploy the app, then "will do firewall later." Later often arrives after the first scan—or after a Redis compromise left open "temporarily."

Inbound ports to allow for a standard web site

PortServiceNote
22/tcpSSHRestrict to admin IP if possible
80/tcpHTTPACME redirect and to HTTPS
443/tcpHTTPSPublic site
ICMPpingOptional; some monitoring uses it

Everything else closed by default: MySQL 3306, Redis 6379, Postgres 5432, SMTP 25, admin panel 8080. Internal services bind 127.0.0.1 or private network—not 0.0.0.0 exposed to Internet.

Before writing the first rule, list what actually listens:


ss -tlnp

Compare output to what you thought you installed. Docker, for example, can publish ports without ufw filtering them depending on configuration—see pitfalls below.

ufw: safe sequence so you do not lock yourself out

Before ufw enable, keep an SSH session open and test from a second window:


ufw default deny incoming

ufw default allow outgoing

ufw allow 22/tcp

ufw allow 80/tcp

ufw allow 443/tcp

ufw enable

ufw status verbose

If you admin from a fixed IP, restrict SSH:


ufw allow from YOUR.OFFICE.IP to any port 22 proto tcp

IPv6: rule ufw allow 443/tcp must cover v6 or explicit v6 rule—forgetting v6 creates a hole scans exploit. Verify with ufw status verbose that v6 rules align.

Many hosts—Hetzner Cloud Firewall, OVH Network Security—filter before the VPS. Recommended double layer: restrictive panel plus aligned local ufw. See Hetzner cloud firewall for a concrete panel rules example.

Complements: fail2ban, SSH keys, classic mistakes

fail2ban bans addresses after repeated SSH failures—see secure SSH. No SSH password: keys only. Firewall does not patch unpatched CVEs; it reduces exposed attack surface.

Recurring mistakes:

  • Allow 3306 "temporarily" for months;
  • Docker -p 6379:6379 publishing Redis without ufw filter depending on config;
  • Disable ufw "for debug" with no restore date;
  • SSH open worldwide with weak password authentication.

For access bastion, see SSH bastion—alternative to direct SSH exposure from any IP.

The climax: firewall reveals what you expose by habit

List ss -tlnp before writing the first rule. Compare VPS with panel firewall via the directory and comparator—some European hosts include free cloud firewall, others bill separately.

Decide and move forward without blind spots

In half a day, you can secure a new VPS or audit an existing one:

  1. Inventory open ports with ss -tlnp and external scan—do not trust your install memory.
  2. Configure restrictive cloud firewall first: SSH from office IP, public 80 and 443, everything else closed.
  3. Enable ufw default deny with same rules—keep SSH session open during test.
  4. Bind databases and cache to localhost or private network only; never 0.0.0.0 without tunnel or VPN.
  5. Pair fail2ban and SSH key authentication—firewall alone is not enough against brute force.
  6. Recheck IPv6 and Docker containers publishing ports without filter after each deployment.

Frequently asked questions

ufw or nftables directly?

ufw to start fast on Ubuntu/Debian—readable abstraction. nftables/iptables for complex rules or infrastructure scripts. Both can coexist; avoid contradictory duplicates blocking legitimate traffic.

Should you change SSH port 22?

Obscurity alone adds little. SSH keys without password plus fail2ban matter more. Custom port as bonus to reduce scan noise, not replacement for strong authentication.

Host cloud firewall + local ufw?

Recommended defense in depth: panel firewall first barrier, ufw on instance. Align rules so you do not lock yourself out—especially SSH from fixed IP.

Open MySQL to office for phpMyAdmin?

Not directly on Internet. SSH tunnel, VPN, or localhost-only admin. Exposing 3306 attracts scans in minutes.


An effective VPS firewall does not start by allowing everything—it starts by denying everything, then opening only what the site needs to breathe.

Compare European hosts

Filter by compliance, location and use case — then open the sheets to verify the real scope.

Browse the directory
Blog

Related reading

All articles →