Defense-in-Depth VPS Deployment for a Self-Hosted OpenClaw Application
A regulated application environment required OpenClaw to run on an Ubuntu 22.04 VPS while keeping the server securely manageable after Internet exposure. A basic application deployment would have left administrative access, network services, and application processes exposed to unnecessary security risks.
Bobcares established a defense-in-depth deployment by hardening SSH, restricting firewall access, adding Fail2Ban, enabling automated security updates, moving administration to Tailscale, and isolating OpenClaw through systemd. Logging, backups, and security auditing were also incorporated to support ongoing operations and recovery.
Business Challenge
The customer needed to host OpenClaw on a publicly reachable VPS without exposing administrative access or the application to unnecessary threats. Root access, password-based SSH, unrestricted network access, brute-force attempts, weak service isolation, and limited recovery controls created security and operational risks that needed to be addressed before deployment.
Technology Used
Blueprint
The VPS was hardened before OpenClaw deployment, with SSH restricted to key-based access and firewall rules limiting inbound traffic. Tailscale subsequently moved administrative access to a private network. OpenClaw ran under a non-root systemd service with process restrictions, while automated updates, logging, backups, and audits supported ongoing security and recovery.
Key Outcomes
- Deployed OpenClaw on a minimal Ubuntu 22.04 VPS.
- Removed direct root and password-based SSH access.
- Moved administrative SSH access to the private Tailscale network.
- Restricted inbound traffic through UFW.
- Added Fail2Ban protection against repeated SSH login attempts.
- Enabled automated security patching.
- Isolated OpenClaw through systemd and a non-root account.
- Established logging, backups, and security audit procedures.
Customer Profile
The Challenges
- Newly provisioned VPS instances were quickly exposed to Internet scanning.
- Direct root login created unnecessary administrative risk.
- Password-based SSH authentication increased exposure to brute-force attacks.
- Publicly accessible SSH remained an attack surface even with key authentication.
- Default SSH access attracted automated scanning activity.
- The self-hosted application required controlled permissions and service isolation.
- Application startup and recovery needed to work reliably after deployment.
- Maintenance activities such as security updates and time synchronization had to remain functional.
- Logging and backup processes were required for operational visibility and recovery.
Why Bobcares?
- Treated server hardening as a prerequisite to application deployment rather than a later activity.
- Applied multiple independent security layers instead of relying on a single control.
- Reduced public exposure by moving administrative access to Tailscale.
- Used existing Linux security capabilities to isolate and restrict the application.
- Combined access control, firewall protection, brute-force mitigation, patching, logging, and backups.
- Validated SSH configuration before restarting the service to avoid administrative lockout.
What We Delivered
- Provisioned a minimal Ubuntu 22.04 VPS.
- Created the non-root claw administrative and application account.
- Configured SSH key-based authentication.
- Disabled root and password-based SSH login.
- Restricted SSH access to the claw user.
- Changed SSH to port 2222 and applied connection limits and timeout controls.
- Configured UFW with restrictive inbound policies.
- Implemented Fail2Ban monitoring for SSH login attempts.
- Enabled automated security patching.
- Configured systemd-timesyncd and standardized logs to UTC.
- Deployed Tailscale for private administrative access.
- Removed public SSH access after establishing Tailscale connectivity.
- Installed Node.js, Git, and pnpm for OpenClaw.
- Deployed OpenClaw under /opt/openclaw with protected configuration.
- Configured OpenClaw as a systemd service running under the claw account.
- Applied systemd service restrictions including NoNewPrivileges, PrivateTmp, ProtectSystem, and ProtectHome.
- Implemented logging through journalctl and backups using rsync.
- Performed a final OpenClaw security audit.
The Results
SSH Access
- Before: Root and password-based access created unnecessary exposure, while public SSH remained reachable from the Internet.
- After: SSH used key-based authentication, root and password logins were disabled, and administrative SSH access was moved behind Tailscale.
Network Exposure
- Before: The VPS had publicly reachable SSH access that could be discovered by Internet scanning.
- After: Public SSH access was removed after Tailscale deployment, reducing the externally visible attack surface.
Firewall Protection
- Before: The newly provisioned VPS required a defined inbound access policy.
- After: UFW denied inbound traffic by default while allowing only required access during deployment, with public SSH subsequently removed.
Application Privileges
- Before: The application required deployment and startup controls appropriate for a self-hosted service.
- After: OpenClaw operated under the non-root claw account through a restricted systemd service.
Brute-Force Protection
- Before: SSH remained exposed to repeated automated login attempts.
- After: Fail2Ban monitored SSH attempts and blocked repeat unauthorized connections.
Maintenance & Recovery
- Before: Security updates, logging, and recovery mechanisms needed to be established as part of the deployment.
- After: Automated security patching, journal logging, scheduled backups, and security auditing were incorporated into the operating model.
The Business Impact
- Reduced the publicly exposed attack surface of the self-hosted VPS.
- Improved control over administrative access without removing remote management capability.
- Reduced the risk associated with compromised application processes through non-root execution and systemd isolation.
- Established a repeatable security baseline for self-hosted application deployment.
- Improved operational readiness through automated updates, logging, backups, and security auditing.
- Reduced dependence on a single security mechanism by introducing multiple defensive layers.
Ongoing Collaboration
- Monitor SSH and system logs through journalctl.
- Maintain automated security patching.
- Review firewall and private network access.
- Maintain Fail2Ban protection for SSH.
- Monitor OpenClaw service operation and systemd restarts.
- Maintain scheduled backups of the OpenClaw deployment.
- Perform periodic security audits and configuration reviews.
Conclusion
Bobcares deployed OpenClaw on Ubuntu 22.04 with security hardening implemented before application exposure. SSH controls, UFW, Fail2Ban, Tailscale, systemd isolation, automated patching, logging, and backups created multiple layers of protection.
The resulting VPS provided a more controlled and manageable environment for self-hosting OpenClaw while reducing unnecessary public exposure and improving operational readiness.
