How to Configure VPS Firewall Rules Safely
Published on September 4, 2026
A firewall should allow the traffic your server needs and quietly refuse the rest. To configure VPS firewall rules safely, start with the services that must remain reachable, especially SSH, then add web and application ports one at a time. Do not begin by blocking everything from the only terminal session you have open. That is how a calm maintenance task becomes a console-recovery task.
For most Linux VPS deployments, the practical goal is simple: deny unsolicited inbound traffic by default, allow required outbound traffic, and create narrow inbound rules for trusted users and services. This reduces attack surface without making routine administration difficult.
Start with the traffic map
Before changing any rule, write down what the VPS actually does. A public WordPress site, for example, usually needs SSH for administration and ports 80 and 443 for web traffic. A private API may need HTTPS only, while a database server should usually accept connections only from an application server on a private network.
Check the listening services first. On most Linux distributions, this command gives a useful view:
```bash sudo ss -tulpn ```
Do not automatically open every port shown. Some services listen only on localhost or a private interface and do not need public firewall access. Others may be old test services, monitoring agents, or software that should not be reachable from the internet at all.
For each public-facing port, answer three questions: who needs it, from where, and over which protocol? A rule allowing HTTPS from anywhere is normal for a public website. A rule allowing a database port from anywhere is normally a problem waiting politely in the logs.
Keep a recovery path before you configure VPS firewall rules
Maintain two active SSH sessions while making firewall changes. Use one session to apply rules and leave the second untouched. After applying a change, test a new connection from another terminal before closing anything. This catches errors in the actual connection path instead of relying on optimism.
Also confirm that your VPS provider console is available. A browser-based console or rescue environment is the fallback if SSH is blocked. It is not a substitute for careful work, but it is good operational insurance.
If SSH runs on a nonstandard port, verify it before creating rules:
```bash sudo ss -tulpn | grep ssh ```
A nonstandard SSH port can reduce background noise from automated scans, but it is not meaningful security on its own. Strong authentication, limited source access, and timely patching do the real work.
Use a default-deny inbound policy with UFW
UFW is a practical firewall interface for Ubuntu and Debian-based VPS servers. It is easy to read later, which matters when another administrator needs to troubleshoot an outage at 2 a.m.
First, set sensible defaults:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Next, allow SSH before enabling the firewall. If your server uses the default SSH port, use:
```bash sudo ufw allow OpenSSH ```
If SSH listens on a custom port, specify it explicitly. This example uses port 2222:
```bash sudo ufw allow 2222/tcp ```
For a normal public website, allow HTTP and HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Then enable the firewall and check the resulting policy:
```bash sudo ufw enable sudo ufw status numbered ```
The numbered status is useful because rules can later be removed precisely. Avoid leaving temporary broad rules behind after troubleshooting. Temporary rules have a funny habit of becoming permanent furniture.
If the VPS hosts a web application behind a reverse proxy, the application port may not need to be public. For example, Nginx can accept traffic on ports 80 and 443 while the application listens on `127.0.0.1:3000`. In that design, no firewall rule for port 3000 is needed.
Restrict administrative access by source IP
SSH should not be open to every address unless your team genuinely needs that flexibility. If your office, VPN, or jump host has a stable public IP address, limit SSH to it:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
For a distributed team with changing home IPs, a VPN or bastion host is often a better answer than opening SSH globally. It adds a little setup work but gives you one controlled administration path and a cleaner audit trail.
Rate limiting can also reduce basic SSH password-guessing attempts:
```bash sudo ufw limit 22/tcp ```
This is not a replacement for SSH keys, disabled password authentication where appropriate, or multi-factor access through your management path. Think of it as one fence panel, not the entire fence.
Treat databases, panels, and monitoring separately
Database ports such as MySQL on 3306, PostgreSQL on 5432, Redis on 6379, and MongoDB on 27017 should almost never be publicly available. Allow them only from the private IP address or subnet of the application server.
For example, to permit MySQL connections only from an application VPS at `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
The database service itself should also bind to the intended private interface where possible. Firewall rules and service binding are separate layers. Using both means a mistaken firewall change is less likely to expose the service.
Hosting panels, Grafana dashboards, and monitoring endpoints deserve the same attention. If they are for staff only, restrict them to a VPN, office IP range, or dedicated management network. Public monitoring pages can expose more infrastructure detail than expected, even when they do not show secrets.
Account for the provider firewall and IPv6
Your VPS may have more than one firewall layer. A cloud or provider-level firewall filters traffic before it reaches the server, while UFW, firewalld, nftables, or iptables filters traffic on the VPS itself. Using both is sensible, but the rules must agree.
If port 443 is open on the VPS but blocked at the provider layer, visitors will still fail to connect. If the provider allows a port but the VPS denies it, the VPS remains protected. During troubleshooting, check both layers in order: provider policy, VPS firewall, service listening address, and application configuration. The logs are usually telling the same story once these are checked.
Do not forget IPv6. If your VPS has a public IPv6 address, equivalent IPv6 rules are required. UFW can manage IPv6 when enabled in its configuration, but verify with:
```bash sudo ufw status verbose ```
A properly secured IPv4 address does not help if the same service is wide open over IPv6.
Test from outside, then monitor the result
After each significant change, test from a network outside the VPS. Confirm that intended services work, then confirm that ports meant to remain private are not reachable. Browser testing is useful for websites, but command-line tests provide clearer answers for specific ports:
```bash nc -vz your-server-ip 443 ```
For blocked ports, a timeout or refusal can mean different things depending on the rule and service state. Review the firewall status, the service status, and system logs rather than changing several settings at once.
Enable logging carefully when diagnosing a problem:
```bash sudo ufw logging low ```
Low logging is usually enough to spot unexpected denied traffic without producing unnecessary disk activity. On busy servers, high-volume firewall logs can become their own small operational nuisance.
Review firewall rules whenever you deploy a new service, retire an old application, change office IP addresses, or modify network architecture. The best rules are not the longest set of rules. They are the smallest set that accurately describes how the server should communicate.
If you prefer not to carry this work alone, a managed VPS team can review access requirements, apply changes with a recovery plan, and monitor the server afterward. At kodu.cloud, this fits naturally alongside managed operations and ongoing monitoring, especially for teams that need to focus on clients and product rather than packet filtering.
A firewall is doing its job when nobody notices it. Keep the policy narrow, document why each exception exists, and test access before declaring the service calm again.
Andres Saar Customer Care Engineer