This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you.

A freshly deployed Vultr VPS has exactly zero firewall rules protecting it. That’s not a bug — it’s a design choice that puts you in control. But it also means that within minutes of your instance going live, automated bots are scanning it for open ports and weak SSH passwords. Port 22 alone gets probed thousands of times a day on any public IP.
A proper vultr firewall setup takes about 20 minutes and cuts that attack surface down to almost nothing. The approach covered here uses two layers: Vultr’s cloud-level Firewall Groups (which filter traffic before it even reaches your server) plus UFW inside Ubuntu (a second line of defense at the OS level). Skip either layer and you’ve got a gap.
Why Two Firewall Layers Beat One
Most tutorials cover either Vultr Firewall Groups or UFW — rarely both together. Here’s why you want both running simultaneously.
Vultr Firewall Groups operate at the network infrastructure level, outside your VM entirely. Vultr describes it as “packet filtering before the traffic reaches the protected server.” Malicious traffic never touches your OS. The firewall is free with every compute plan, and one group can protect multiple instances at once — useful if you’re running a small fleet.
UFW (Uncomplicated Firewall) runs inside Ubuntu and filters traffic after it enters the OS network stack. It catches anything that slips through the outer layer and gives you per-process granularity — useful for services that only need to talk to localhost or internal IPs.
Here’s how they compare:
| Feature | Vultr Firewall Groups | UFW / iptables |
|---|---|---|
| Where it runs | Cloud infrastructure (outside VM) | Inside the OS |
| Managed via | Vultr control panel or API | SSH into the server |
| Default inbound policy | Deny all | Allow all (until configured) |
| Applies to multiple servers | Yes | No (per-server only) |
| Filters traffic | Before it hits the NIC | After it enters the OS network stack |
| Cost | Free | Free (built into Linux) |
One important distinction: Vultr Firewall Groups are not automatically attached to new instances. You create a group, configure the rules, then explicitly link it to your server. That extra step trips people up — the group exists but does nothing until attached. We’ll cover that below.
Step 1: Set Up Vultr Firewall Groups
Create the Firewall Group
- Log in to the Vultr Customer Portal
- Navigate to Products → expand Network → select Firewall
- Click Add Firewall Group
- Enter a descriptive label in the Description field — something like
web-server-rulesorwordpress-prod - Click Add Firewall Group to create it
The group now exists with zero rules, meaning all inbound traffic is denied by default. That’s a good starting state — you’ll open only what you need.
Add Firewall Rules
- Click your newly created firewall group to open it
- In the left navigation, click IPv4 to add rules for that protocol (repeat for IPv6 if needed)
- For each rule, select the Protocol (SSH, HTTP, HTTPS, or Custom), set the Source IP range, and click Add Firewall Rule
For a standard web server running WordPress or a similar stack, these three rules cover the essentials:
| Protocol | Port | Source | Purpose |
|---|---|---|---|
| TCP | 22 | Your IP (e.g., 203.0.113.10/32) | SSH admin access |
| TCP | 80 | 0.0.0.0/0 | HTTP web traffic |
| TCP | 443 | 0.0.0.0/0 | HTTPS web traffic |
Critical: Restrict SSH (port 22) to your own IP address, not 0.0.0.0/0. Opening SSH to the whole internet is how brute-force attacks happen. If you’re on a dynamic IP, use your VPN’s static IP instead.
Attach the Group to Your Instance
This is the step most people forget. Without it, the firewall group is just a set of saved rules — not active on anything.
- Navigate to Products → Compute
- Click your target instance to open its management page
- Go to the Settings tab → click Firewall in the left menu
- Select your firewall group from the dropdown
- Click Update Firewall Group
Changes take effect within seconds. Any updates you make to the group’s rules propagate immediately to all attached instances.

Step 2: Configure UFW on Ubuntu
With the outer perimeter in place, it’s time to set up UFW inside the OS. On a fresh Ubuntu 22.04 VPS, this sequence takes under five minutes and can be done in a single SSH session.
Verify UFW is Installed
sudo ufw status
💡 Tip: Prefer a visual approach? You can build these rules with our free Firewall Rule Builder — it generates ufw and iptables commands right in your browser.
If it’s not installed (unlikely on Ubuntu 22.04, but possible on minimal images):
sudo apt install ufw
CRITICAL: Allow SSH Before Anything Else
sudo ufw allow 22/tcp
Run this first, before enabling UFW. If you enable UFW without this rule, you will lock yourself out of the server. The only recovery is a VNC console session through the Vultr control panel — possible, but a pain. Don’t skip this step.
Set Default Policies
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw default deny forward
This blocks all inbound connections by default, permits all outgoing traffic, and disables packet forwarding (correct for single-server setups — only change deny forward if you’re using this server as a router or VPN gateway).
Allow Required Ports
# HTTP
sudo ufw allow 80
# HTTPS
sudo ufw allow 443
# Reload to apply
sudo ufw reload
Enable UFW
sudo ufw enable
Confirm with y when prompted. UFW is now active and running.
Verify Your Rules
sudo ufw status
Expected output lists your allowed ports and shows Status: active. If you see that, you’re protected.

Essential Port Reference
Here’s a quick reference for what to open, what to keep closed, and why. These are the decisions that matter — not the setup steps.
| Port | Protocol | Service | Recommended Action |
|---|---|---|---|
| 22 | TCP | SSH | Allow from your IP only |
| 80 | TCP | HTTP | Allow (public web) |
| 443 | TCP | HTTPS | Allow (public web) |
| 3306 | TCP | MySQL | Deny — keep private |
| 5432 | TCP | PostgreSQL | Deny — keep private |
| 6379 | TCP | Redis | Deny — keep private |
| 1194 | UDP | OpenVPN | Allow if using VPN |
| 8080 | TCP | Alt HTTP | Allow only if needed |
| 3000 | TCP | Node.js / dev | Dev only; deny in production |
| 25 | TCP | SMTP | Deny unless running a mail server |
The rule here is simple: deny everything that doesn’t need to be public. MySQL, PostgreSQL, and Redis exposed to the internet are how most VPS compromises happen — not through some sophisticated attack, but through an open port and a weak or default password.
Prices last verified: 2026-06-30
Vultr Plans and Pricing
Vultr Firewall Groups are free — included with every compute plan. New accounts get $300 in free credit (valid for 30 days), which gives you plenty of runway to set up and test your VPS before committing.
For most use cases, the entry-level plans are more than enough to run a firewall-protected server:
| Plan | vCPU | RAM | Storage | Bandwidth | Price |
|---|---|---|---|---|---|
| Cloud Compute (IPv6 only) | 1 | 0.5 GB | 10 GB SSD | 0.5 TB | $2.50/mo |
| Cloud Compute (practical entry) | 1 | 1 GB | 25 GB SSD | 1 TB | $5.00/mo |
| High Performance (NVMe) | 1 | 1 GB | 25 GB NVMe | 2 TB | $6.00/mo |
| High Performance (NVMe) | 1 | 2 GB | 50 GB NVMe | 3 TB | $12.00/mo |
The $5/month plan handles WordPress, small Node.js apps, or personal projects without issue. If you’re running anything with real traffic or a database under load, the $6–12/month NVMe tier is worth the jump — the NVMe storage cuts database query times noticeably.
Who this isn’t for: if you need managed databases, a one-click app platform, or a simpler onboarding experience, DigitalOcean’s ecosystem is more complete. Vultr wins on raw compute price, but you’re doing more of the configuration yourself — which is exactly why this firewall guide exists.
Common Mistakes to Avoid
Enabling UFW before allowing SSH. Already covered this, but it’s worth repeating because it’s the most common way to lock yourself out. Always run sudo ufw allow 22/tcp before sudo ufw enable.
Attaching a firewall group with no SSH rule to a running instance. Same problem, different layer. If you create a Vultr Firewall Group with only HTTP/HTTPS rules and attach it to a live instance, your SSH session drops immediately. Add SSH to the group before attaching — or do it during a maintenance window.
Opening SSH to 0.0.0.0/0. Every automated scanner on the internet will find it within minutes. Restrict SSH to your IP, use SSH key authentication, and disable password login by setting PasswordAuthentication no in /etc/ssh/sshd_config.
💡 Tip: Our free SSH Config Generator can build a hardened sshd_config for you interactively.
Leaving database ports exposed. Port 3306 (MySQL), 5432 (PostgreSQL), and 6379 (Redis) should never be reachable from the public internet. Applications on the same server communicate via localhost. If you need inter-server database access, set up a private network and restrict access to specific internal IPs.
Not installing Fail2ban. Firewall rules filter by port — Fail2ban handles the follow-up. It monitors auth logs and bans IPs after repeated failed login attempts. Vultr recommends configuring it to ban after 3 failed attempts within 5 minutes. It’s a 10-minute setup and significantly reduces noise on your auth logs.
Start With a Firewall Group as the Outer Perimeter
A properly configured vultr firewall setup takes about 20 minutes and makes your VPS meaningfully harder to compromise. Start with a Vultr Firewall Group as your outer perimeter — deny all inbound by default, open SSH to your IP only, then HTTP and HTTPS to the world. Then add UFW inside Ubuntu with the same default-deny approach. Those two layers cover the vast majority of common attack vectors.
If you’re just getting started with Vultr, check out our full Vultr review for a rundown of what the platform is actually like to use day-to-day. And if you’re deploying WordPress on your VPS, the WordPress on Vultr deployment guide walks through the full stack setup including NGINX, PHP, and database configuration.
The next step after locking down your firewall is setting up SSH key authentication and disabling password login — that combination eliminates the two most common entry points on any Linux VPS.

