An unnecessarily exposed port can turn a fast VPS into a target for scans, password attempts and abusive resource consumption. This VPS firewall guide shows how to build practical protection without blocking your website, control panel, bot, remote desktop or administrative access.
The firewall controls which connections can enter and leave the server. It does not replace updates, strong passwords, backups or Anti-DDoS protection at the network level, but it greatly reduces the VPS attack surface. The core rule is simple: deny what is not needed and allow only the services that are actually in use.
Before you configure: avoid losing access to your VPS
The most common mistake is enabling the firewall before allowing the administration port. On a Linux VPS, this usually means blocking SSH and having to use the recovery console. On a Windows VPS, it may mean losing RDP and relying on the console offered by the provider.
Before making any change, identify three things: how you manage the machine, which applications serve external users, and where trusted access comes from. Write down the current ports and keep a second session open in the terminal or remote desktop during testing. If a rule fails, you will still have an active connection to fix the configuration.
It is also worth checking whether a control panel is installed. cPanel, WHM, aaPanel, CyberPanel, EasyPanel, Coolify and other tools use their own ports. Allowing only HTTP and HTTPS may keep the site online while preventing you from managing the environment.
What to open on a VPS based on its use
There is no single list of ports for every VPS. A trading machine has different needs than a hosting server with cPanel, a game server or an application running n8n. The firewall should reflect the installed services, not a configuration copied without analysis.
For a public website or API, the most common ports are 80 for HTTP and 443 for HTTPS. In production, traffic should be directed to HTTPS whenever possible. Databases such as MySQL, MariaDB, PostgreSQL and Redis should not be reachable from the internet in a typical setup. Ideally, they should accept connections only from the VPS itself or from a controlled private network.
On Linux, SSH usually uses port 22. On Windows, the Remote Desktop Protocol usually uses port 3389. These ports are frequent targets of login-attempt bots. Whenever you have a fixed IP, restrict administrative access to the IPs of your company, home, VPN or team. If you need to access from variable networks, use key-based SSH authentication, a strong password, attempt blocking and, when possible, a VPN.
Hosting and deployment panels require extra attention. Besides the panel's ports, some features may use FTP, SMTP, IMAP, POP3, DNS or custom container ports. Open only what is active. If you do not send email through the server, for example, there is no reason to expose SMTP services.
VPS Linux firewall guide with UFW
UFW is a straightforward option for Ubuntu and Debian VPS servers. It simplifies firewall management without requiring you to write complex rules by hand. Even so, run the commands carefully, especially on remote servers.
Start by checking whether UFW is available and what its current status is. In many installations it is already installed but disabled. Before enabling it, set the default policy to block incoming connections and allow outgoing connections. This lets the VPS download updates, query APIs and respond to connections initiated by users, while preventing unauthorized inbound access.
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Now, allow your administration method first. For SSH on the default port, use:
```bash sudo ufw allow 22/tcp ```
If SSH runs on a different port, replace the number. Even better: limit access to a trusted IP whenever possible.
```bash sudo ufw allow from 203.0.113.10 to any port 22 proto tcp ```
Then allow the necessary public services. A standard web server needs HTTP and HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status numbered ```
The command `status numbered` makes it easier to remove specific rules later. Test the website, SSH and critical services from an external network. Do not assume a port is working just because the rule appears on screen: reverse proxies, application settings and provider rules can also affect the result.
For internal services, prefer restrictions by origin. If an application on another VPS needs to reach PostgreSQL on port 5432, open that port only for the private or public IP of that machine. Opening the port to any origin increases risk without providing operational benefit.
Windows VPS firewall: protect RDP without stopping your work
On Windows Server, Microsoft Defender Firewall is already part of the system and should remain enabled. It can be configured through the graphical interface under “Windows Defender Firewall with Advanced Security” or with PowerShell. The most sensitive point is usually RDP.
Avoid leaving port 3389 open to the entire internet if the people who need access have known IPs. Create an inbound rule that allows RDP only from those addresses. For remote teams with dynamic IPs, a VPN or an access gateway is safer than opening access globally.
Also check for rules required by specific applications. A server hosting a system on IIS may need ports 80 and 443, while a remote desktop application may operate on a port defined by its vendor. Do not disable the firewall to “make things work.” That hides the problem and exposes every service at once.
After creating or changing rules, test with a second user or a second RDP session. If you apply the wrong rule on your current connection, you will have another session available to revert the change.
Rules that improve security without complicating operations
Changing the default SSH or RDP port may reduce noise from automated scans, but it should not be treated as the main protection. A well-configured scanner will find alternative ports. What really reduces risk is limiting origins, using strong authentication and keeping the system up to date.
On Linux, disable direct root login with a password and use SSH keys for administrative users. On Windows servers, keep administrative accounts separate from daily use, use unique passwords and monitor failed login logs. Automatic attempt-blocking tools, such as Fail2ban on Linux, complement the firewall by reacting to suspicious behavior.
For web applications, use a reverse proxy such as Nginx, Apache or Caddy to concentrate public access on ports 80 and 443. This way, internal ports used by Node.js, Python, n8n, Docker and databases remain accessible only locally. This architecture simplifies maintenance and reduces open ports.
Infrastructure-level Anti-DDoS protection helps absorb volumetric attacks, but it does not fix a permissive rule in the operating system. These are different layers: the network filters malicious traffic at scale, while the VPS firewall decides who can reach each service.
How to review rules without causing downtime
A firewall is not a one-time setup. Every new panel, game, integration or application may require a review. The key is to document the reason for each open port. If no one knows why a rule exists, it probably deserves investigation before it stays active.
Review the firewall after installing services, switching panels, migrating applications or shutting down projects. Remove ports that are no longer used and confirm that databases remain restricted. Monitor blocked-traffic logs to distinguish a malicious attempt from a legitimate access that was forgotten in the rules.
In environments with several clients or websites, separate services whenever it makes sense. A VPS for automation does not need the same ports as a VPS for hosting or trading. This separation improves control and makes incidents easier to isolate.
HostMF offers Windows and Linux VPS with immediate activation, NVMe SSD, unlimited traffic and 24-hour technical support for those who need to put projects online with real control over the environment. Still, the firewall configuration should match your operation: the clearer the role of each server, the easier it is to protect it without interrupting what drives results for your business.
The best firewall rule is one you can explain, test and maintain. Start with the minimum necessary, validate legitimate access and expand permissions only when there is a clear technical reason.
