A new VPS ships with every installed service listening on every interface. A firewall is the plain rule that says: anything that is not web or SSH stays closed to the internet, and the database never leaves the machine or the private network.
When the policy is “allow everything, block what I know”, every newly installed service becomes public automatically: a Redis without a password, a MongoDB with authentication off, an admin panel on 8080. Scanners find them within minutes. With “deny everything, allow what I know” the mistake flips: a forgotten service stays invisible until you deliberately open it. UFW does this in two commands and keeps the rules readable; underneath, it drives nftables or iptables.
MySQL on 3306 and PostgreSQL on 5432 have no business being exposed to the internet, even with a password. Configure them to listen on 127.0.0.1 or on the private-network address, and reach them remotely through an SSH tunnel or a VPN. If the application runs on another server, open the port only for that server's IP. Docker deserves attention: publishing a port with -p bypasses UFW rules, so bind published ports to 127.0.0.1 or to the private interface.
A database holding personal data that is reachable from the internet is exactly what Article 32 GDPR treats as a lack of appropriate technical measures, and ANSPDCP has fined such cases in Romania. For entities registered with the DNSC under OUG 155/2024, network segmentation and access control are part of the risk-management measures in Article 11 of OUG 155/2024. A documented firewall with explainable rules is simple evidence in any audit.
| Port / service | Exposure to the internet | How you reach it | UFW rule |
|---|---|---|---|
| 22 SSH | Yes, rate-limited and with a restricted source | SSH keys, VPN | ufw limit 22/tcp |
| 80 HTTP | Yes, for redirects and ACME validation | Public | ufw allow 80/tcp |
| 443 HTTPS | Yes | Public | ufw allow 443/tcp |
| 3306 MySQL / 5432 PostgreSQL | No | localhost, SSH tunnel, private network | ufw allow from 10.0.0.5 to any port 5432 |
| 6379 Redis | No | localhost, private network | no public rule |
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbosesudo ufw allow from 10.0.0.5 to any port 5432 proto tcpss -tulpn | grep LISTENA colleague had set listen_addresses to '*' to connect from home and forgot to revert it. The database was reachable from anywhere, protected only by its password. A default-deny firewall covered the mistake, and remote access moved to an SSH tunnel.
Redis published through Docker with -p 6379:6379 bypassed UFW and reached the internet without a password. A scanner found it the same day, with customer sessions readable. Binding it to 127.0.0.1 and adding a password closed the exposure.
UFW is a front end over nftables or iptables, enough for a VPS with a few services, and it keeps rules readable. Move to nftables directly when you need large address sets, rules across several interfaces or performance at high traffic. Do not mix them on the same machine.
You can, with ufw allow from your address, but a home IP changes and the rule stays behind. An SSH tunnel or a VPN is safer: the database stays on localhost and you connect through an encrypted channel, with the same key you already use for SSH.
Yes. The firewall in the provider's panel filters before the machine and is a useful first layer. The one on the server knows what actually listens, also protects traffic on the private network and stays with you if you move the server. Keep both consistent, with the same list of ports.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.