Hey @Wyndo, thank you for championing the "harm reduction" approach. It would have been easy to just post another hype topic, but you chose to highlight the hard, unsexy work of security engineering instead. That leadership saves users from real pain. Honored to co-pilot this one with you.
OpenClaw is not completely secure yet, but there are still ways we can improve our security and reduce risks. This is how we can stay in the game while playing it safer.
Once again, great post! One quick note: Claude pointed out to me that the playbook does NOT actually set `PermitRootLogin no` or `PasswordAuthentication no` despite the final success message that says "Password authentication has been DISABLED" (playbook.yml line 176). I confirmed that the playbook doesn't contain explicit instructions to set those values. So then, is there another setting/instruction that applies those rules eventually?
FWIW, I have already applied those settings in my own VPS, but I think it's nice to still clarify for others who may be reading this post for the first time.
Awesome stuff 🙂. While you're checking the repo, also please note that the `--mgmt-cidr` option for the `deploy.sh` script (shown in the README) is not actually implemented. I don't need it (I think? 🫣) but I was trying to understand what it does and saw that there's no logic for it.
I'll also work on removing the cidr.. That was there on a version prior to the one I released. I initially had a Caddy container proxying the openclaw dashboard to my management vlan, so I didn't need to ssh into the box to work on it. But then it occurred to me that I was leaving the door open for people to actually just expose that Caddy to the internet. So I removed it, but I obviously left code behind.
Thanks so much for this! Quick question for those of us using a VPS: if I follow a typical VPS setup + hardening guide (eg this one from DO https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu) first before running the ansible playbook, will that break any of the actions being carried out by Ansible? I see some stuff about firewalls and that's part of the DO guide so I'd like to not have to debug any of that if it causes problems. Thanks again in advance!
Great question. And in this case, no, as the firewall rules from the hardening guide are complimentary to the ones on the DigitalOcean setup guide for Ubuntu.
Thanks Cristian for pointing that out. I'll work on that and update the article soon. I'll reply here to make you and other readers aware of the update.
will map docker port 18789 to host 127.0.0.1:18789 thus it will not be reachable over Tailscale unless you use "tailscale serve" or other reverse proxy mechanism.
It seems that Openclaw doesn't use tools.yaml by default. I've added some folders to allowedPaths and deniedPaths however the agent has access to them anyway.
I also tried to specify those restrictions in openclaw.json with
tools: {
filesystem: {
config but I was told by the Openclaw that it does not understand filesystem key.
Thanks for bringing this up. As of today (16th of Feb), the documentation points out to using the agent.workspace attribute to prevent access to other directories. That on itself sets the actual working directory for the agent, but if the agent tries to reach an absolute path, it will be able to do so. To prevent this, the agents.default.sandbox configuration spins up a new docker container to prevent access to your local machine.
Important to say that as I stated on a few of my articles already, docker, if not in rootless mode, can be another vector of attack.
Hey @Wyndo, thank you for championing the "harm reduction" approach. It would have been easy to just post another hype topic, but you chose to highlight the hard, unsexy work of security engineering instead. That leadership saves users from real pain. Honored to co-pilot this one with you.
appreciate this super in-depth post, Fernando!
OpenClaw is not completely secure yet, but there are still ways we can improve our security and reduce risks. This is how we can stay in the game while playing it safer.
Thanks for showing the way! 🙏
"Credential Rotation (Assume All Compromised)"
Yes! particularly right now. I usually go after the assume compromise style to security. Solid breakdown here =)
Honest breakdowns like this protect people from costly mistakes.
Security guard in place for all known entry protection and services to the same for the good 😊
All known vulnerabilities trappable are automated with alerts for the same for the good 😊
This is seriously the best, most complete and most easy to understand lock-down guide on internet. Thank you so much.
Once again, great post! One quick note: Claude pointed out to me that the playbook does NOT actually set `PermitRootLogin no` or `PasswordAuthentication no` despite the final success message that says "Password authentication has been DISABLED" (playbook.yml line 176). I confirmed that the playbook doesn't contain explicit instructions to set those values. So then, is there another setting/instruction that applies those rules eventually?
FWIW, I have already applied those settings in my own VPS, but I think it's nice to still clarify for others who may be reading this post for the first time.
Thanks for pointing that out. I may have missed committing the change. I'll review the git repo.
My VPS uses Debian 13 and I noticed a few gaps in the playbook. Made the changes in a PR (https://github.com/Next-Kick/openclaw-hardened-ansible/pull/3) in case you prefer to see them there.
Merged :D
Awesome stuff 🙂. While you're checking the repo, also please note that the `--mgmt-cidr` option for the `deploy.sh` script (shown in the README) is not actually implemented. I don't need it (I think? 🫣) but I was trying to understand what it does and saw that there's no logic for it.
I'll also work on removing the cidr.. That was there on a version prior to the one I released. I initially had a Caddy container proxying the openclaw dashboard to my management vlan, so I didn't need to ssh into the box to work on it. But then it occurred to me that I was leaving the door open for people to actually just expose that Caddy to the internet. So I removed it, but I obviously left code behind.
Thanks so much for this! Quick question for those of us using a VPS: if I follow a typical VPS setup + hardening guide (eg this one from DO https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu) first before running the ansible playbook, will that break any of the actions being carried out by Ansible? I see some stuff about firewalls and that's part of the DO guide so I'd like to not have to debug any of that if it causes problems. Thanks again in advance!
Great question. And in this case, no, as the firewall rules from the hardening guide are complimentary to the ones on the DigitalOcean setup guide for Ubuntu.
I believed the guide needs to be updated, it seems that the routes has change from ~/.clawdbot to ~/.openclaw/
It's updated.
Thanks Cristian for pointing that out. I'll work on that and update the article soon. I'll reply here to make you and other readers aware of the update.
There is little inconsistency in Docker guide:
ports:
- "127.0.0.1:18789:18789"
will map docker port 18789 to host 127.0.0.1:18789 thus it will not be reachable over Tailscale unless you use "tailscale serve" or other reverse proxy mechanism.
Hi! Thanks for the amazing article.
It seems that Openclaw doesn't use tools.yaml by default. I've added some folders to allowedPaths and deniedPaths however the agent has access to them anyway.
I also tried to specify those restrictions in openclaw.json with
tools: {
filesystem: {
config but I was told by the Openclaw that it does not understand filesystem key.
Can you help me please? Thanks in advance.
Hey Basil,
Thanks for bringing this up. As of today (16th of Feb), the documentation points out to using the agent.workspace attribute to prevent access to other directories. That on itself sets the actual working directory for the agent, but if the agent tries to reach an absolute path, it will be able to do so. To prevent this, the agents.default.sandbox configuration spins up a new docker container to prevent access to your local machine.
Important to say that as I stated on a few of my articles already, docker, if not in rootless mode, can be another vector of attack.
Here are additional details on the documentation.
- https://docs.openclaw.ai/concepts/agent-workspace
- https://docs.openclaw.ai/gateway/sandboxing
Skip number 8 section in this case (outdated). Step 15 should also be configured in openclaw.json as well.
Regards,
Fernando