How to Configure Firewall Rules for AI Agent Servers Like OpenClaw

Mar 10, 2026

My OpenClaw AI agent server got scanned. Hard. Within hours of deployment, I saw connection attempts from random IP addresses trying to access ports I didn’t even know were open. That’s when I realized my firewall configuration was basically non-existent.

Here’s how I fixed it with UFW on Ubuntu, and why you need to lock down your AI agent servers from day one.

The Problem: Default-Allow Everything

When I first deployed OpenClaw, I was focused on getting it running. The server worked, the agent responded, everything seemed fine. Then I checked the logs:

Mar 10 02:15:23 openclaw-server sshd[1234]: Failed password for root from 192.168.1.100
Mar 10 02:15:24 openclaw-server sshd[1234]: Failed password for root from 192.168.1.100
Mar 10 02:15:25 openclaw-server sshd[1234]: Failed password for root from 192.168.1.100
Mar 10 02:45:01 openclaw-server kernel: [UFW BLOCK] IN=eth0 SRC=10.0.0.55 DST=10.0.0.10

Someone was trying to brute-force SSH. And that’s just what I could see. What about the OpenClaw API port? The database? The web dashboard?

The default server configuration allowed connections from anywhere. Not good for an AI agent that might handle sensitive data or have API keys stored in memory.

Step 1: Install and Enable UFW

UFW (Uncomplicated Firewall) is the easiest way to manage firewall rules on Ubuntu. First, I installed it:

sudo apt update
sudo apt install ufw -y

Before enabling UFW, I needed to make sure I wouldn’t lock myself out. The most common mistake is enabling the firewall without allowing SSH first.

sudo ufw allow ssh
# Or if you're using a custom SSH port:
sudo ufw allow 2222/tcp

Then I enabled UFW:

sudo ufw enable

This prompted a warning about disrupting SSH connections. Since I already allowed SSH, I confirmed with y.

Step 2: Set Default Policies

The core principle of firewall security is deny by default, allow by exception. I configured UFW to deny all incoming connections and allow all outgoing connections:

sudo ufw default deny incoming
sudo ufw default allow outgoing

This means:

Incoming: Everything is blocked unless explicitly allowed
Outgoing: Everything is allowed unless explicitly blocked

This is the safest starting point. If I don’t know I need it, it’s blocked.

Step 3: Allow Essential Services Only

For my OpenClaw server, I only needed:

SSH (for administration)
OpenClaw API port (8000 by default, but I changed it)
Optional: HTTP/HTTPS if running a web interface

Here’s what I configured:

# SSH - already done, but confirming
sudo ufw allow ssh

# OpenClaw API - restrict to specific IP if possible
# If you have a static IP, use it:
sudo ufw allow from 203.0.113.50 to any port 8000

# Or allow from a specific network:
sudo ufw allow from 192.168.1.0/24 to any port 8000

# If you need public access (not recommended), at least limit it:
sudo ufw limit 8000/tcp

The limit command adds rate limiting, which helps prevent brute-force attacks.

Step 4: Configure for NAT/Behind a Router

My server sits behind a NAT router. This adds a layer of complexity. The router forwards external traffic to my server, so I need to consider:

External IP vs Internal IP: UFW sees the internal IP
Port Forwarding: Router forwards external port to internal port
Router Firewall: Additional layer of security

Here’s my network setup:

Internet
    |
    v
[Router - 203.0.113.1]
    |  Port Forward: 8000 -> 192.168.1.100:8000
    v
[OpenClaw Server - 192.168.1.100]
    |
    v
UFW Rules

On the router, I configured port forwarding:

External port 8000 → Internal IP 192.168.1.100, port 8000

On the server, UFW rules apply to the internal interface:

# Allow OpenClaw from anywhere (since router NATs it)
sudo ufw allow 8000/tcp

# But better: if I know the source IPs
sudo ufw allow from 192.168.1.0/24 to any port 8000

The key insight: UFW doesn’t see the original source IP after NAT. It sees the router’s internal IP. If I want to restrict by source IP at the server level, I need to either:

Configure the router’s firewall instead
Use a VPN so connections come from known IPs
Accept that NAT provides some obscurity (not security)

Step 5: Check and Verify Rules

After configuration, I checked the rules:

sudo ufw status numbered

Output:

Status: active

     To                         Action      From
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 8000/tcp                   ALLOW IN    192.168.1.0/24
[ 3] 22/tcp (v6)                ALLOW IN    Anywhere (v6)

I also tested from another machine:

# Test SSH (should work)
nc -zv openclaw-server 22

# Test OpenClaw port from allowed IP
nc -zv openclaw-server 8000

# Test from blocked IP (should fail)
# I used my phone on cellular network

Common Mistakes I Avoided

Mistake 1: Locking Myself Out

Always allow SSH before enabling UFW. I’ve seen too many people enable the firewall and immediately lose access to their server.

Mistake 2: Allowing Everything “Just in Case”

I initially thought, “Maybe I should allow ports 80 and 443 just in case I need them later.” No. If I don’t need them now, they stay blocked. I can always add rules later.

Mistake 3: Forgetting About IPv6

UFW manages both IPv4 and IPv6 by default. My rules show entries for both. I made sure to test from both IPv4 and IPv6 sources.

Mistake 4: Not Logging Denies

I enabled logging to see what’s being blocked:

sudo ufw logging on
sudo ufw logging medium

Logs appear in /var/log/ufw.log. This helps me understand what’s trying to connect and adjust rules if needed.

The Final Configuration

Here’s my complete UFW setup for the OpenClaw server:

# Install
sudo apt update && sudo apt install ufw -y

# Default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (change port if needed)
sudo ufw allow ssh

# Allow OpenClaw from trusted network only
sudo ufw allow from 192.168.1.0/24 to any port 8000

# Enable logging
sudo ufw logging medium

# Enable firewall
sudo ufw enable

# Verify
sudo ufw status verbose

Why This Matters for AI Agents

AI agent servers like OpenClaw often:

Store API keys in memory
Process sensitive user data
Make external API calls
Run long-lived processes

A compromised AI agent could:

Leak API keys (expensive if you’re using paid LLM APIs)
Expose conversation history
Be used as a pivot point for further attacks

The firewall is the first line of defense. It won’t stop everything, but it significantly reduces the attack surface.

Monitoring and Maintenance

After setup, I check the logs weekly:

# Check recent blocks
sudo tail -f /var/log/ufw.log

# Or search for patterns
sudo grep "BLOCK" /var/log/ufw.log | tail -100

I also review rules monthly and remove any that are no longer needed.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!