Setting up a firewall on your VPS

Setting up a firewall on your VPS

A firewall is a set of rules that decides which network traffic your VPS is allowed to receive and send. Getting it wrong the safe way just means a blocked connection you can fix from outside. Getting it wrong the unsafe way means locking yourself out of your own server over SSH, with no way back in except a console. This guide covers both AlmaLinux 9 (firewalld) and Ubuntu 24.04 (UFW), and the specific ordering mistakes that cause a lockout on each.

Before you start

This picks up from a VPS you can already reach over SSH as root or a user with sudo access. If you haven't set that up yet, do that first: everything below assumes a working SSH connection you don't want to lose.

A few things worth knowing before you touch anything:

• AlmaLinux 9 and Ubuntu 24.04 handle firewalls differently. AlmaLinux uses firewalld, which is already running by default. Ubuntu uses UFW, which is installed but usually switched off until you turn it on.
• If you've moved SSH off port 22 onto a custom port, none of the standard "allow ssh" shortcuts on either OS will cover it. You need to allow the exact port you actually use.
• On a Hostworld VPS, you manage the machine itself (start, stop, reboot, console) through Virtualizor in the Hostworld client area. Firewall rules are set inside the operating system over SSH, not through Virtualizor, but Virtualizor's console is your safety net if a firewall rule shuts SSH out. More on that in Step 5.

Step 1: Check what's already running

Before changing anything, find out what state the firewall is actually in. Assuming it's off, or assuming it's on with a particular rule already there, is how people end up surprised.

AlmaLinux 9

firewalld is the default firewall service on AlmaLinux and it's turned on out of the box. Confirm it's running, and see what it currently allows:

sudo firewall-cmd --state
sudo firewall-cmd --list-all

On a fresh AlmaLinux install, the output from --list-all will normally show ssh, cockpit and dhcpv6-client already listed as allowed services in the default zone, which is usually public. That matters: unlike Ubuntu, you don't need to open SSH yourself on a default install. The risk on AlmaLinux isn't the initial setup, it's what you do to the zone afterwards.

Ubuntu 24.04

UFW is installed but typically inactive until you enable it. Check its current status before doing anything:

sudo ufw status verbose

If it says inactive, nothing is being blocked yet, and no rule you add will have any effect until you enable it in Step 3. This is the OS where the ordering of steps actually matters.

Step 2: Allow SSH before you do anything else

This is the step that prevents a lockout, and it works differently on each OS because the two firewalls start from a different default state.

Ubuntu 24.04

UFW's default incoming policy is deny. That means the moment you turn UFW on without an SSH rule already in place, any new connection to your server is dropped. Your existing session might keep working for a moment, but the next connection attempt (including a reconnect after your session drops) will fail. This is the single most common way people lock themselves out of a Linux server, and it's avoidable entirely by getting the order right: allow SSH first, enable UFW second, never the other way round.

There are three ways to write this rule, and they aren't identical:

sudo ufw allow OpenSSH

uses a named application profile that resolves to port 22/tcp.

sudo ufw allow ssh

reads /etc/services, maps ssh to port 22, and opens TCP only.

sudo ufw allow 22

opens port 22 for both TCP and UDP, because no protocol was specified. For SSH, any of these is fine on a default install.

If SSH runs on a non-standard port, none of these named shortcuts will find it. Open the exact port instead:

sudo ufw allow 2222/tcp

(replacing 2222 with whatever port you actually use).

AlmaLinux 9

On a default install, ssh is already in the allowed services list from Step 1, so there's usually nothing to add here. If you moved SSH to a custom port, or your --list-all output doesn't show ssh, add it explicitly:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Or, for a custom port:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

The --permanent flag and the --reload afterwards both matter. A rule added without --permanent works immediately but disappears the next time firewalld reloads or the server reboots. A rule added with --permanent is saved, but won't actually apply until you reload. People get caught both ways: thinking a rule failed when it was only ever temporary, or thinking they're still protected after a reboot when a "permanent" rule was never actually saved. A plain --reload is a routine, safe step and does not drop your current connection. That's different from panic mode, covered in Step 5.

Step 3: Turn the firewall on

Ubuntu 24.04

With SSH allowed from Step 2, enable UFW:

sudo ufw enable

You may see a prompt warning that this could disrupt existing SSH connections. Don't rely on that prompt as your safety check: it only appears when UFW detects you're connected over SSH. If you're running this from a local console, a serial console, or an out-of-band tool, the prompt won't show at all and UFW just enables silently. The real safeguard is having allowed SSH first, not the prompt.

Unlike firewalld, once UFW is enabled its ruleset persists across reboots automatically. There's no separate "make it permanent" step to remember here, which is the opposite of how AlmaLinux's firewalld behaves.

AlmaLinux 9

firewalld is already running by default, so there's normally no "enable" step at all. Confirm it's active rather than turning it on:

sudo systemctl status firewalld

If for some reason it's stopped, start it and set it to come back on reboot:

sudo systemctl enable --now firewalld

Step 4: Open the ports your applications need

A web server needs 80 and 443 open, for example. Add only what you're actually running.

AlmaLinux 9

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Ubuntu 24.04

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

On Ubuntu these apply immediately, since UFW doesn't have firewalld's permanent/runtime split. Add rules as you install new services, rather than opening a wide range of ports up front on the assumption you'll need them.

Step 5: Know which commands to avoid

A few commands are worth naming directly, because they're documented elsewhere as useful and don't come with an obvious warning attached.

On AlmaLinux, don't run:

sudo firewall-cmd --set-default-zone=drop

This switches the default zone to one that drops everything, SSH included, and takes effect straight away over your live session. Removing the ssh service from the active zone while connected over SSH has the same result:

sudo firewall-cmd --permanent --remove-service=ssh

And separately from either of those, firewalld has a panic mode:

sudo firewall-cmd --panic-on

This is far more destructive than either command above. It drops all incoming and outgoing traffic and ends active connections immediately, including your own SSH session. It's meant for a machine that's actively being attacked, and it should only ever be run with physical or console access, never over a live remote connection. It's turned off again with --panic-off, but you can't run that command over SSH once panic mode is on, because SSH itself is what it just blocked.

On Ubuntu, the equivalent mistake is one of ordering, covered in Step 3: running ufw enable before an SSH rule exists. There's no single command as destructive as firewalld's panic mode built into UFW by default, which is one reason UFW is generally considered the gentler starting point.

On either OS, if you're testing or migrating and end up with two firewall services active at once, for example firewalld and UFW both loaded on the same Ubuntu server, stop and disable whichever one you're not using. Two firewalls trying to manage the same rules produces behaviour that's hard to diagnose and can block traffic neither one meant to block on its own.

Step 6: If you do lock yourself out anyway

If SSH stops responding after a firewall change, don't panic and don't rebuild the server. On a Hostworld VPS, Virtualizor gives you a console that reaches the machine directly, independent of its network stack entirely, so it stays reachable even when the firewall has shut SSH out. Log in to the Hostworld client area, open Virtualizor, select the affected VPS and open its console. From there you're working locally on the machine, exactly as if you had a screen and keyboard plugged in, and the firewall's SSH block doesn't apply.

From the console:

Ubuntu 24.04

sudo ufw allow ssh
sudo ufw enable

AlmaLinux 9

sudo firewall-cmd --set-default-zone=public
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Adjust the specific commands to whatever actually caused the block, then reconnect over SSH as normal to confirm it's fixed. If you're not confident diagnosing which rule caused the lockout, or the console itself isn't behaving as expected, open a support ticket and we'll help you get back in.

What next

With a firewall in place and SSH access confirmed safe, a sensible next step is keeping the server itself patched, since a firewall only controls what traffic reaches the machine, not what's running on it. Have a look at our VPS guides for the rest of the setup sequence, including hardening and update steps for both AlmaLinux and Ubuntu. If you're still deciding on a VPS or comparing specifications, our VPS hosting pages cover what's available on both the UK and US locations.