OpenClaw Firewall Rules: The Only 3 Ports You Should Open

The correct OpenClaw firewall rules come down to one sentence: allow inbound TCP on ports 22, 80, and 443, deny everything else, and keep OpenClaw’s own port 18789 bound to localhost behind nginx. That is the entire posture. This guide gives you the exact UFW and iptables commands, the matching cloud firewall setup on DigitalOcean and Hetzner, and how to prove from outside that it all worked.

Which Ports Does OpenClaw Actually Need?

An OpenClaw server has exactly four ports that matter, and only three of them should ever accept traffic from the internet:

Everything else - database ports, Node debug ports, anything a package installed without telling you - stays closed by the default-deny policy you are about to set.

The one people get wrong is 18789. It feels natural to open the port your app listens on. Do not. OpenClaw holds your AI provider API keys and your full conversation history; exposing the gateway directly means anyone who finds your IP can probe it. All traffic must arrive through nginx on 443, where you get TLS, access logs, and a single controlled entry point.

Step 1: Configure UFW (the Recommended Way)

UFW ships with Ubuntu and is the simplest way to express the policy. Run these in order from an active SSH session:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp    # SSH
sudo ufw allow 80/tcp    # HTTP (Let's Encrypt + redirect)
sudo ufw allow 443/tcp   # HTTPS (all OpenClaw traffic via nginx)
sudo ufw enable

UFW warns that enabling may disrupt existing SSH connections. Because you allowed 22/tcp first, you are safe - confirm with y.

Check the result:

sudo ufw status verbose

You should see Default: deny (incoming), allow (outgoing) and exactly three allow rules. If there is a rule for 18789 from an earlier experiment, delete it:

sudo ufw delete allow 18789/tcp

Optional but worthwhile: rate-limit SSH so UFW itself throttles brute-force attempts:

sudo ufw limit 22/tcp

This replaces the plain allow rule and blocks IPs that open six or more connections in 30 seconds.

Step 2: iptables Equivalents

If you prefer raw iptables or run a distro without UFW, this ruleset expresses the same policy:

# Keep established connections working
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Loopback must stay open - nginx talks to OpenClaw over it
sudo iptables -A INPUT -i lo -j ACCEPT

# The three allowed ports
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Everything else: drop
sudo iptables -P INPUT DROP

The loopback rule matters more here than it looks. Nginx reaches OpenClaw at localhost:18789, so if you drop loopback traffic your site returns 502s even though nothing is “wrong” with either service.

iptables rules vanish on reboot unless you persist them:

sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

Pick UFW or iptables, not both - UFW manages iptables underneath, and hand-written rules alongside it lead to confusing conflicts.

Step 3: Keep Port 18789 Off the Internet

The firewall is your outer wall, but the binding address is the real fix. Verify what OpenClaw is listening on:

sudo ss -tlnp | grep 18789

Good output shows 127.0.0.1:18789. If you see 0.0.0.0:18789, OpenClaw is listening on every interface and only your firewall stands between the gateway and the internet. Fix the config so the exposure cannot happen at all:

server:
  host: "127.0.0.1"
  port: 18789

Then restart:

pm2 restart openclaw

This is defence in depth: even if someone disables UFW during troubleshooting and forgets to re-enable it, a localhost-bound gateway still is not reachable from outside.

Step 4: Add a Cloud Firewall Layer

Both providers from our VPS install guide offer free network-level firewalls that filter traffic before it ever reaches your server.

DigitalOcean: In the control panel, go to Networking, then Firewalls, and create a new firewall. Add inbound rules for TCP 22, 80, and 443, leave outbound open, and apply it to your droplet. Anything not matching an inbound rule is dropped at the network edge.

Hetzner: In the Cloud Console, open Firewalls and create one with the same three inbound TCP rules, then apply it to your server. Hetzner drops all non-matching inbound traffic by default once a firewall is attached.

Run the cloud firewall and UFW together with identical policies. The cloud layer protects you when someone flushes iptables during debugging; UFW protects you when a teammate detaches the cloud firewall “just to test something”. Neither layer should trust the other to be correct.

Step 5: Harden the One Port That Stays Open

Port 22 is the only interactive door left, so it deserves extra locks.

Install fail2ban to ban IPs that hammer SSH:

sudo apt-get install -y fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Create /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port = 22

That bans any IP failing SSH login 5 times within 10 minutes, for an hour. Confirm it is watching:

sudo fail2ban-client status sshd

Then disable password logins entirely in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Restart with sudo systemctl restart sshd - after confirming your SSH key works in a second session, so you do not lock yourself out. With keys required and fail2ban running, brute-force attempts against port 22 become noise in a log file.

How Do I Verify My Firewall Rules From Outside?

Rules that look right from inside the server prove nothing. Test from a machine that is not your VPS - your laptop, or any other host you control.

Scan the public IP:

nmap -Pn YOUR_SERVER_IP

The expected result is ports 22, 80, and 443 reported as open and nothing else. Any additional open port is a rule you need to hunt down and remove.

Then attack the exact failure mode this guide exists to prevent:

curl -m 5 http://YOUR_SERVER_IP:18789

The correct outcome is a timeout or connection refused. If you get any response from OpenClaw, the gateway is publicly exposed - go back to Step 3 and check both the binding address and your firewall rules.

Finally, confirm the legitimate path works:

curl -I https://ai.yourdomain.com

A 200 or a redirect means nginx is serving traffic over 443 exactly as intended.

The Complete Checklist

• UFW (or iptables) default-deny inbound, with only 22, 80, 443 allowed
• No firewall rule for 18789 anywhere
• ss -tlnp | grep 18789 shows 127.0.0.1:18789
• Cloud firewall attached with the same three-port policy
• fail2ban active on SSH, password authentication disabled
• External nmap scan shows only 22, 80, 443
• curl against port 18789 on the public IP fails

For the rest of the hardening picture - SSL verification, OpenClaw authentication, and the update routine - see the full security guide. And if you serve OpenClaw on a LAN or bare IP where Let’s Encrypt is not an option, the self-signed HTTPS guide covers that path.