How to Build a Secure VPS Firewall That Holds Up

Published on November 13, 2026

Your VPS should accept only the traffic your applications genuinely need. Everything else should be rejected before it becomes a login attempt, a scanner finding, or a 3 a.m. incident. A secure VPS firewall is not a complicated collection of rules. It is a small, intentional policy that protects management access, publishes required services, and stays understandable when someone needs to troubleshoot it quickly.

For most business workloads, that means allowing SSH from known administrator networks, allowing HTTP and HTTPS for public websites, and denying unsolicited inbound traffic by default. Databases, caches, queues, and internal dashboards should usually remain private. A public Redis port is not a feature. It is an invitation with very poor guest screening.

Start with the services, not the firewall tool

Before changing rules, make a short inventory of what is listening on the server and who needs to reach it. On Linux, `ss -tulpn` shows listening TCP and UDP ports along with the owning processes. Compare that output to the services you intended to run.

A typical web server may need ports 80 and 443 exposed to the internet. SSH on port 22 may be needed only by your team, CI runner, or management network. PostgreSQL, MySQL, Elasticsearch, Redis, and Grafana commonly need no public inbound access at all if the application runs on the same VPS or a private network.

This step catches more problems than people expect. A package may install a service and bind it to all interfaces by default. A developer may briefly expose a test listener and forget it. The logs are telling the same story now: open ports tend to attract attention sooner or later.

The firewall should reflect the intended architecture, not compensate for an unclear one. If a database must serve another server, restrict access by source IP or private subnet. If an admin panel is needed by a distributed team, consider a VPN, a bastion host, or an identity-aware access method rather than opening it to every address on the internet.

Secure VPS firewall baseline rules

A sensible baseline has three ideas: deny unsolicited inbound traffic, permit necessary outbound traffic, and allow established connections to continue. Stateful firewalls track return traffic, so an outbound software update or API request can receive its response without creating a wide inbound exception.

On Ubuntu and Debian systems, UFW provides a readable interface over the underlying firewall framework. On Rocky Linux, AlmaLinux, and similar distributions, firewalld is often the practical choice. More advanced deployments may manage nftables directly, especially where performance, custom chains, or automation requires exact control.

The tool matters less than the policy. These are the rules you are aiming to express:

• Allow established and related traffic.
• Allow SSH only from trusted source addresses where possible.
• Allow ports 80 and 443 publicly when hosting a website or API.
• Allow application, database, monitoring, and control-panel ports only from the systems that require them.
• Deny all other inbound traffic and log denied packets at a useful, non-noisy level.

For a basic public web VPS managed over SSH, an UFW sequence can look like this:

```bash sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow from 203.0.113.25 to any port 22 proto tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status verbose ```

Replace `203.0.113.25` with a real trusted public address. If your office or home connection uses a changing IP address, do not blindly lock SSH to it without an alternate access plan. You can use a VPN endpoint with a stable address, a provider console, or a carefully controlled temporary rule. The right answer depends on who administers the server and how mobile they are.

Do not lock yourself out during deployment

The safest firewall change is one made through an existing SSH session while a second session remains open. Apply the rule, test new access from another terminal or network, then close the original session only after confirming that the new policy works.

Also check the order of operations. Add your SSH allow rule first. Confirm it. Then apply the default inbound deny policy. Enabling the default deny first can end a short maintenance task with you looking at a timeout screen and considering your life choices.

Console access from the VPS provider is a valuable recovery path, but it should not be your normal firewall management method. Keep clear records of approved ports, source networks, and the reason for every exception. If a rule cannot be explained in one sentence, it may not belong in production.

For teams, manage firewall rules as code where possible. Store the configuration in version control, review changes, and deploy through your normal automation. Manual changes are sometimes necessary during an incident, but they should be documented and folded back into the managed configuration afterward. Otherwise, the next deployment may quietly remove the fix.

Use more than one protective layer

A host firewall is essential, but it should not be the only boundary. A well-operated VPS uses layered controls, with each layer covering a different failure mode.

At the network level, provider firewall rules or security groups can block unwanted traffic before it reaches the server. These are useful for broad controls, such as allowing SSH only from company IP ranges or limiting a private service to a private subnet. Host-based rules remain valuable because they travel with the server configuration and can enforce distinctions between local processes, containers, and interfaces.

At the service level, bind private components to `127.0.0.1` or an internal IP rather than `0.0.0.0`. A firewall rule reduces exposure; a restricted bind address removes the public listening surface altogether. For databases, use strong authentication and encrypted connections as well. Firewall controls are not a substitute for credentials, updates, or sane permissions.

At the application edge, a reverse proxy can terminate TLS, apply request limits, and keep application ports private. Web application firewalls may help with common HTTP attacks, but they need tuning and should not be treated as a magic barrier. A vulnerable application behind a WAF is still vulnerable, just perhaps less loudly.

Account for containers, IPv6, and monitoring

Container platforms deserve special attention. Docker and similar tools can add packet-filtering rules automatically, and published container ports may bypass the assumptions behind a simple UFW setup. Review the actual exposed ports from outside the VPS after deployments, not only the firewall status output. If containers are part of production, define your network policy with the container runtime behavior in mind.

IPv6 is another common gap. If the VPS has public IPv6 connectivity, your firewall policy must cover it. Disabling or filtering only IPv4 leaves a second front door open. Confirm that your firewall tool is configured for IPv6, then test the public services over both address families.

Monitoring makes a secure setup maintainable. Watch firewall logs for repeated denied connections, sudden scans on unusual ports, and unexpected traffic patterns. Not every rejected packet deserves an alert - internet background noise is constant - but a rise in denied SSH attempts, database probes, or egress traffic can indicate a real issue.

Kodu.cloud customers can pair firewall policy with managed operational support, backups, and monitoring so that changes do not become a solo after-hours project. The goal is not to add ceremony. It is to ensure someone can see what changed, verify service health, and act before a small exposure becomes downtime.

Review firewall rules as services change

Firewall rules are not set once and forgotten. Review them after application releases, migrations, new integrations, staff changes, and infrastructure redesigns. Remove temporary access rules when the task is complete. Remove rules for services that no longer exist. Least privilege gets weaker every time an exception is left behind.

A practical review asks simple questions: Is this port still listening? Does this source still need access? Can this public service move behind a proxy or VPN? Does the rule work over IPv4 and IPv6? Are backups, monitoring, and emergency access still functional under the current policy?

Keep the final rule set boring, documented, and tested. That is the good kind of boring. Your VPS can then remain available to customers while giving attackers very little useful surface to work with.

Andres Saar Customer Care Engineer