Network Security

Firewall and Network Hardening

Every ClawHosters instance runs on its own dedicated VPS with a strict firewall applied before any customer workload starts. The default policy drops all inbound traffic except what is explicitly needed.

This page explains the specific rules in place, what they protect against, and what you can expect from the network layer.

Inbound Firewall Rules

The firewall uses iptables with a default DROP policy on the INPUT chain. Only the following traffic is allowed in:

Port	Protocol	Purpose
22	TCP	SSH access (disabled unless you enable it)
8080	TCP	OpenClaw Gateway web interface
--	--	Established and related connections (return traffic for outbound requests)
--	--	Loopback (localhost communication within the VPS)

Everything else is dropped silently. There is no response to port scans or connection attempts on unlisted ports.

What This Means in Practice

Your instance only exposes two ports to the internet: SSH and the web UI. If you have not enabled SSH access, port 22 is open at the firewall level but has no authorized keys configured, so connections are rejected by the SSH daemon.

The web UI on port 8080 is protected by HTTP basic authentication. The combination of firewall rules and gateway auth means an attacker would need both network access and valid credentials to interact with your instance.

Outbound Firewall Rules

Outbound traffic is allowed by default with specific exceptions. The following outbound ports are blocked:

Ports	Protocol	Reason
25, 465, 587, 2525	TCP	SMTP -- prevents the instance from sending spam email
6667, 6697, 194	TCP	IRC -- prevents botnet command-and-control communication

Your instance can make outgoing HTTP/HTTPS requests, connect to APIs, download packages, and do anything else on the network. The only restriction is that it cannot send email directly or join IRC networks.

If your use case requires sending email, you can use a third-party email API (like Mailgun or SendGrid) over HTTPS. The SMTP block only affects direct email delivery on the standard mail ports.

SYN Flood Protection

Inbound SYN packets (new connection attempts) are rate-limited to prevent port scanning and SYN flood attacks:

Parameter	Value
Rate limit	30 SYN packets per second
Burst allowance	60 packets
Excess handling	Logged and dropped
Log prefix	PORTSCAN_BLOCKED:

This means a legitimate user connecting to SSH or the web UI will not notice any delay. But an attacker trying to rapidly probe ports will have their packets dropped after the burst limit is exceeded.

fail2ban: SSH Brute Force Protection

fail2ban monitors SSH login attempts and automatically bans IPs that fail authentication repeatedly.

Setting	Value
Monitored service	SSH (sshd)
Max failed attempts	3
Ban duration	1 hour
Ban method	iptables DROP rule for the offending IP

After three failed SSH login attempts from the same IP address, that IP is blocked for one hour. The ban is automatic and does not require any action from you.

If you lock yourself out (for example, by using the wrong SSH key), wait one hour for the ban to expire. There is no way to manually unban an IP from the dashboard.

Note: fail2ban only applies if SSH access is enabled on your instance. If SSH is not enabled, there are no login attempts to monitor.

Docker Network Isolation

Each instance runs in a Docker container on its own dedicated VPS. There is no Docker network shared between customers.

Isolation measure	Details
One VPS per customer	No container co-tenancy
No Docker bridge sharing	Each VPS has its own Docker daemon
Container port mapping	Only port 8080 is mapped externally
Internal port 9090	Metrics endpoint, not exposed externally

The container communicates with the outside world only through the mapped port. Internal services (like the metrics endpoint on port 9090) are accessible only within the VPS and not reachable from the internet.

What You Cannot Change

The firewall and fail2ban configuration is applied during instance provisioning and cannot be modified through the dashboard or API. This is intentional: consistent security baselines across all instances reduce the risk of misconfiguration.

If you enable SSH access, you can inspect the firewall rules on your VPS, but modifying them is not recommended. Changes will not persist through instance rebuilds or snapshot restores.

Related Docs

• Security Overview -- Infrastructure, container, and data protection measures
• Authentication and Access Control -- How each access method is protected
• SSH Access to Your Instance -- Enabling and using SSH on your VPS