![[DoRoyal] Logo](https://cdn.doroyal.com/2026/08/DoRoyal_by_Sidular-1-scaled.png)
A new VPS is usually reachable from everywhere within minutes of deployment. That is useful when you need to connect quickly, but it is not a sensible long-term default. When you configure VPS firewall rules, the goal is simple: allow the traffic your server actually needs, deny everything else, and avoid cutting off your own administrative access in the process.
For an unmanaged VPS, the firewall is your responsibility. Your hosting provider secures the underlying platform, but you decide which services are exposed on your server. A sensible firewall policy reduces noise from automated scans, limits your attack surface, and makes it easier to see unexpected traffic when something goes wrong.
Start with the services you actually use
Before entering a single rule, make a short inventory of the server’s public-facing services. Most web servers need SSH for administration, HTTP for standard web traffic, and HTTPS for encrypted web traffic. A mail server, game server, database, VPN, or custom application may need additional ports, but only if people or other systems must reach it from outside the VPS.
Do not open a port because a tutorial says it is common. Open it because a service is listening on that port and has a real external use. A MySQL database, for example, is often better kept private and accessed only by applications on the same server. Exposing port 3306 to the internet creates risk without helping most small sites.
You can review listening services on a Linux VPS with:
bash sudo ss -tulpn
Look for services bound to 0.0.0.0, [::], or your public IP address. Services bound only to 127.0.0.1 are available locally and usually do not require a public firewall exception.
Protect SSH before you configure VPS firewall rules
SSH is the rule most likely to lock you out. Keep your current SSH session open while changing firewall settings. If possible, open a second terminal session and confirm that you can log in there as well. This gives you a working path back in if one command does not behave as expected.
If your administrator IP is static, restrict SSH to that address. This is stronger than allowing SSH from every address on the internet. For example, with UFW:
bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp
Replace the example address with your real public IP. If you work from changing home, office, or mobile networks, restricting SSH to one address can become inconvenient. In that case, allow port 22 broadly but use SSH keys, disable password logins where practical, and consider changing the administrative workflow through a VPN or bastion host.
Changing SSH from port 22 can reduce random login attempts in logs, but it is not a security control by itself. Automated scanners find nonstandard ports. Strong authentication and a narrow access policy matter more.
UFW setup for Ubuntu and Debian VPS plans
UFW is a practical choice for Ubuntu and Debian systems because its syntax is readable and it manages the underlying firewall framework for you. First, allow the ports you need before enabling it:
bash sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp
Then set the default policy. Incoming traffic should normally be denied unless you explicitly allow it. Outbound traffic is commonly allowed because servers need to retrieve updates, resolve DNS, send outbound mail where applicable, and connect to third-party APIs.
bash sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw enable sudo ufw status verbose
If your SSH daemon uses a port other than 22, allow that actual port instead of relying on the OpenSSH profile. After enabling UFW, test a new SSH connection before closing the original session. Then load your site over both HTTP and HTTPS from a separate network or browser.
For a typical WordPress site or small business website, those three allowed services – SSH, HTTP, and HTTPS – are often enough. That is a good outcome. A short firewall rule set is easier to review and less likely to contain old exceptions nobody remembers adding.
Add only application-specific ports
Some applications require another public port. A Node.js service behind Nginx generally does not, because Nginx receives public web requests and proxies them internally. A game server or a direct API service may need a specific TCP or UDP port.
Add the narrowest rule that works:
bash sudo ufw allow 25565/tcp
If the service is used only by a known remote system, allow that source IP instead:
bash sudo ufw allow from 198.51.100.40 to any port 25565 proto tcp
This approach is especially useful for private dashboards, webhook receivers, remote database replicas, and management tools. It is not always possible with consumer internet connections that change IP addresses, so choose a policy you can maintain without creating an emergency access problem.
Firewalld setup for AlmaLinux, Rocky Linux, and CentOS-style systems
On Red Hat-family distributions, firewalld is commonly installed and managed through zones. The public zone is a reasonable starting point for a VPS with a public internet interface.
Check the active zone and its existing services:
bash sudo firewall-cmd --get-active-zones sudo firewall-cmd --list-all
To permanently allow SSH and web traffic in the public zone, run:
bash sudo firewall-cmd --permanent --zone=public --add-service=ssh sudo firewall-cmd --permanent --zone=public --add-service=http sudo firewall-cmd --permanent --zone=public --add-service=https sudo firewall-cmd --reload
For a custom port, add the port and protocol explicitly:
bash sudo firewall-cmd --permanent --zone=public --add-port=25565/tcp sudo firewall-cmd --reload
The --permanent flag saves the rule across reboots, while --reload applies the saved configuration. If you add a rule without making it permanent, it may work until the server restarts and then disappear. That can be frustrating during troubleshooting, so always verify the active configuration after changes.
Check the provider firewall and the server firewall
Many VPS platforms offer a network-level firewall in addition to the Linux firewall inside your virtual server. These are separate layers. A provider firewall can block unwanted traffic before it reaches the VPS, while UFW or firewalld controls traffic after it arrives at the operating system.
Using both is often worthwhile for publicly exposed servers, but it also means a port must be allowed in both places to work. If a website or application is unreachable, check each layer before assuming the service is broken. Also review security groups, private network rules, and load balancer settings if your setup includes them.
Do not treat a provider firewall as a replacement for the local firewall. Local rules remain useful if server roles change, services are installed later, or a configuration error exposes a new listener.
Handle IPv6, Docker, and control panels carefully
If your VPS has IPv6 connectivity, your firewall policy must cover IPv6 as well as IPv4. Otherwise, you can secure the IPv4 address while leaving the same service accessible over IPv6. With UFW, check that IPv6 support is enabled in its configuration and review status output for IPv6 rules. With firewalld, verify the active zone applies to the IPv6 interface and addresses in use.
Docker deserves special attention. Published Docker ports can add firewall behavior through container networking rules, and the outcome can differ by distribution and Docker version. Do not assume an application is protected merely because UFW shows a deny policy. Test from an external host, and prefer binding internal services to 127.0.0.1 when a reverse proxy is the only intended public entry point.
Control panels also need planning. DirectAdmin, cPanel, and similar tools may require their own management ports or service ports for DNS, mail, FTP, and web hosting. Open only the features you use. If you do not provide email from the VPS, there is no reason to expose mail-related ports. If you do use a panel, document its required ports before enforcing a restrictive policy.
Test, log, and maintain your firewall
A firewall configuration is not a one-time task. Test after every meaningful change, especially after installing a new control panel, container stack, VPN, or application. From an external system, confirm that intended services respond and unintended ports do not.
For UFW, review rules with sudo ufw status numbered. Numbered output makes it easier to remove an outdated rule deliberately rather than rebuilding the entire policy. For firewalld, use sudo firewall-cmd --list-all and keep a record of custom ports and their purpose.
Enable logging at a level that is useful without filling disk space with routine scan traffic. Check logs when troubleshooting, but do not spend time chasing every blocked probe from the internet. Public IP addresses are scanned constantly. The meaningful question is whether the firewall is blocking traffic it should permit, or permitting traffic it should block.
The best firewall policy is usually not the most elaborate one. It is the one you can explain months later: administrative access is protected, web traffic is allowed where needed, private services stay private, and every exception has a reason.
