Vultr Firewall Setup: Secure Your VPS in 20 Minutes

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

Featured image — Vultr firewall setup guide, shield icon over a VPS server rack, 1200x630px
Featured image — Vultr firewall setup guide, shield icon over a VPS server rack, 1200x630px

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.


🛠️ Free tools for this guide: IP Subnet Calculator (work out CIDR ranges for your firewall rules) · Fail2ban Jail Generator (auto-ban brute-force attempts on SSH and nginx)

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:

FeatureVultr Firewall GroupsUFW / iptables
Where it runsCloud infrastructure (outside VM)Inside the OS
Managed viaVultr control panel or APISSH into the server
Default inbound policyDeny allAllow all (until configured)
Applies to multiple serversYesNo (per-server only)
Filters trafficBefore it hits the NICAfter it enters the OS network stack
CostFreeFree (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

  1. Log in to the Vultr Customer Portal
  2. Navigate to Products → expand Network → select Firewall
  3. Click Add Firewall Group
  4. Enter a descriptive label in the Description field — something like web-server-rules or wordpress-prod
  5. 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

  1. Click your newly created firewall group to open it
  2. In the left navigation, click IPv4 to add rules for that protocol (repeat for IPv6 if needed)
  3. 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:

ProtocolPortSourcePurpose
TCP22Your IP (e.g., 203.0.113.10/32)SSH admin access
TCP800.0.0.0/0HTTP web traffic
TCP4430.0.0.0/0HTTPS 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.

  1. Navigate to Products → Compute
  2. Click your target instance to open its management page
  3. Go to the Settings tab → click Firewall in the left menu
  4. Select your firewall group from the dropdown
  5. Click Update Firewall Group

Changes take effect within seconds. Any updates you make to the group’s rules propagate immediately to all attached instances.

Vultr control panel screenshot showing the Firewall section under Settings tab with a group selected
Vultr control panel screenshot showing the Firewall section under Settings tab with a group selected

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.

Terminal screenshot showing sudo ufw status output with SSH, HTTP, HTTPS rules listed and Status: active
Terminal screenshot showing sudo ufw status output with SSH, HTTP, HTTPS rules listed and Status: active

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.

PortProtocolServiceRecommended Action
22TCPSSHAllow from your IP only
80TCPHTTPAllow (public web)
443TCPHTTPSAllow (public web)
3306TCPMySQLDeny — keep private
5432TCPPostgreSQLDeny — keep private
6379TCPRedisDeny — keep private
1194UDPOpenVPNAllow if using VPN
8080TCPAlt HTTPAllow only if needed
3000TCPNode.js / devDev only; deny in production
25TCPSMTPDeny 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

🎁 Get $300 free credit when you sign up (valid for 30 days, limited-time offer) — Claim your credit →

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:

PlanvCPURAMStorageBandwidthPrice
Cloud Compute (IPv6 only)10.5 GB10 GB SSD0.5 TB$2.50/mo
Cloud Compute (practical entry)11 GB25 GB SSD1 TB$5.00/mo
High Performance (NVMe)11 GB25 GB NVMe2 TB$6.00/mo
High Performance (NVMe)12 GB50 GB NVMe3 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.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top