{"id":172,"date":"2026-05-29T03:54:06","date_gmt":"2026-05-29T03:54:06","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=172"},"modified":"2026-08-27T05:43:52","modified_gmt":"2026-08-27T05:43:52","slug":"firewall-setup-for-offshore-vps","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/firewall-setup-for-offshore-vps\/","title":{"rendered":"Firewall Setup for Offshore VPS: Ports, Rules and Testing"},"content":{"rendered":"
\n

Server Security<\/span><\/p>\n

What this guide does<\/h2>\n

A fresh offshore VPS<\/a> accepts connections on every port that has something listening. Most of the time that is more than you think: a database, a mail daemon, a panel, whatever the image shipped with. This guide closes all of it down to the three ports a web server actually needs, without cutting off your own SSH session while you do it.<\/p>\n

The dangerous moment is ufw enable<\/code>. If SSH is not allowed at that instant, the connection you are typing into dies and does not come back.<\/p>\n

\n
Time<\/strong>Under 10 minutes.<\/span><\/div>\n
Applies to<\/strong>Ubuntu and Debian. RHEL notes below.<\/span><\/div>\n
Risk<\/strong>Low, if you do step 2 before step 3.<\/span><\/div>\n<\/div>\n<\/div>\n
On this page<\/strong>See what is exposed now<\/a>The four steps<\/a>If you run a control panel<\/a>AlmaLinux and Rocky<\/a>When something breaks<\/a>FAQ<\/a><\/div>\n

See what is exposed now<\/h2>\n

Start by finding out what is listening, because that decides which rules you need. There is no point guessing.<\/p>\n

ss -tulpn<\/code><\/pre>\n
\"Terminal
Note the address on the left. 0.0.0.0 means the whole internet can reach it. 127.0.0.1 means only the server itself can.<\/figcaption><\/figure>\n
Anything bound to 127.0.0.1<\/code> is already safe and needs no firewall rule at all. A database bound to 0.0.0.0<\/code> is a problem, and the right fix is to bind it to localhost in its own config rather than to paper over it with a firewall rule.<\/p>\n
The four steps<\/h2>\n
Step 1: Install UFW and set the defaults<\/h3>\n
apt install ufw -y\nufw default deny incoming\nufw default allow outgoing<\/code><\/pre>\n
Deny incoming, allow outgoing. That is the whole philosophy. Nothing gets in unless you name it; your server can still reach out for updates and API calls. Neither of these commands turns the firewall on, so nothing has changed yet.<\/p>\n
Step 2: Allow the ports you need, SSH first<\/h3>\n
ufw allow OpenSSH\nufw allow 80\/tcp\nufw allow 443\/tcp<\/code><\/pre>\n
Do SSH before anything else. ufw allow OpenSSH<\/code> uses the shipped profile for port 22. If you have already moved SSH to another port, as covered in our SSH hardening guide<\/a>, use the number instead: ufw allow 2222\/tcp<\/code>. Get this wrong and step 3 locks you out.<\/p>\n
Add mail ports only if this box actually handles mail. If your mail lives at Google or Zoho, port 25, 465, 587, 993 and 110 should all stay shut.<\/p>\n
Step 3: Turn it on<\/h3>\n
ufw enable<\/code><\/pre>\n
It will warn you that this may disrupt existing SSH connections. Read that warning rather than clicking past it. If you followed step 2, you are fine.<\/p>\n
Before you press enter, open a second SSH session to the same server and leave it sitting there. If the firewall does cut you off, that second session is still connected and you can run ufw disable<\/code> from it.<\/p>\n
Step 4: Read the rules back<\/h3>\n
ufw status verbose<\/code><\/pre>\n
\"UFW
Three ports in, everything else denied. This is what a web server firewall should look like.<\/figcaption><\/figure>\n
Every line you cannot explain is a line to remove. Use ufw status numbered<\/code> and then ufw delete 4<\/code> to drop one by its number.<\/p>\n
If you run a control panel<\/h2>\n
This is where people get caught out. aaPanel, CyberPanel, Webmin and cPanel all listen on their own ports, and a lot of them install their own firewall layer as well. Turning on UFW underneath one of those gives you two firewalls disagreeing with each other.<\/p>\n