写在前面
关于 OpenClaw 的部署、升级、接入飞书、接入大模型、多机器人配置……这些主题我之前已经写了好几篇。那几篇笔记的重点都是“怎么把它跑起来”“怎么配置好用”。
但在实际折腾的过程中，我发现一个被很多人忽略的问题：大家忙着跑通功能，往往把安全放在最后考虑，甚至根本不考虑。
我的服务器是阿里云的 2 核 2G，系统是 Alibaba Cloud Linux 3。作为一个 7x24 小时运行的服务，OpenClaw 暴露在公网上的时间越长，风险就越大。SSH 暴力破解、容器逃逸、密钥泄露……这些不是理论上的威胁，而是每天都在发生的事。
这篇笔记不是部署教程，也不是配置教程。它是我前面所有实操经验的安全篇总结——我会记录在部署和配置过程中，做了哪些安全加固、为什么这么做、以及这些配置到底在防什么。
如果你已经照着我的其他笔记把 OpenClaw 跑起来了，那这篇笔记就是你的“安全检查清单”。
一、服务器基础安全：先把门守好
OpenClaw 跑在服务器上，服务器的安全是一切的前提。这一步没做好，后面容器配置得再安全也没用。
1.1 改 SSH 端口 + 关密码登录
默认的 22 端口每天被扫描无数次。我做了这几件事：
| 配置项 | 我的设置 | 防什么 |
|---|---|---|
| Port | 28345 | 避开自动化扫描工具的默认端口探测 |
| PermitRootLogin | no | 让攻击者猜不到用户名（不是 root） |
| PasswordAuthentication | no | 只允许密钥登录，密码再强也可能被破 |
| MaxAuthTries | 3 | 输错几次就断掉，暴力破解没戏 |
1.2 阿里云安全组：云平台的防火墙
安全组在云平台边缘节点就把流量过滤掉了，比服务器上的 iptables 更安全——攻击者连你的服务器都摸不到。
| 原则 | 我的做法 |
|---|---|
| 最小开放 | 只开 SSH 端口（限定我的 IP）和 OpenClaw 端口（只绑本地） |
| 默认拒绝 | 没明确允许的流量，全部拦掉 |
| 分层防御 | 安全组 + 容器安全 + 应用认证，三道防线 |
关键点：OpenClaw 的 Web 端口我只绑了 127.0.0.1，不暴露在公网。我通过本地代理访问，这样就算端口被扫到，外部也连不进来。
二、容器安全配置：把 OpenClaw 关进“笼子”
Docker 容器的默认权限其实偏大。如果容器被攻破，攻击者可能获得宿主机的部分权限。我的目标是：即使容器被入侵，攻击者也干不了什么。
| 配置项 | 我的设置 | 安全作用 |
|---|---|---|
cap_drop: ALL | 移除所有 Linux Capabilities | 容器只有最小必要权限，无法执行高危系统操作 |
cap_add: DAC_OVERRIDE | 只保留文件读写权限 | 不多给一个多余的权限 |
read_only: true | 根文件系统只读 | 攻击者无法在容器内安装恶意软件或篡改系统文件 |
user: "1000:1000" | 非 root 用户运行 | 容器内没有 root 权限 |
no-new-privileges:true | 禁止权限提升 | 防止通过 setuid 等方式提权 |
ports: 127.0.0.1:38459:18789 | 只绑定本地 | Web 服务不暴露公网 |
2.1 Docker 部署的独特安全优势：快速止损
如果容器真的被攻击了——比如你发现日志里有异常请求、某个 Agent 行为怪异——Docker 部署能让你秒级止损：
# 立即暂停（保留现场，方便排查）
docker pause openclaw-gateway
# 或者直接停止
cd /opt/openclaw && docker compose down
对比传统部署方式：如果是直接跑在宿主机上的进程，被攻击后你需要 kill 进程、查端口、清理残留文件……一套操作下来至少几分钟。而 Docker 部署下，一条命令就能把整个服务隔离起来，给你争取宝贵的排查时间。
这也是我选择 Docker 部署的重要原因之一——不仅方便管理，更是为了在被攻击时能快速切断风险。
2.2 挂载目录的权限策略
这是我从一个坑里爬出来的教训。挂载目录的权限设计遵循该写的才给写，不该写的坚决只读。
| 挂载目录 | 权限 | 为什么这么设 |
|---|---|---|
./config、./workspace、./agents | :rw | OpenClaw 需要写入会话状态和记忆，只读会报错 |
./credentials | :ro | 飞书密钥，只读，防止被窃取或篡改 |
./skills、./extensions | :ro | 技能和插件代码，只读，防止恶意代码注入 |
踩坑记录：一开始我把 config 目录也设成了只读，结果容器一直报 EROFS。查了半天才发现 OpenClaw 需要在里面写会话状态。教训：安全配置要建立在理解程序运行机制的基础上，不能一刀切。
三、文件权限：防止“自己人”泄密
服务器上可能有多个用户（或者你以后会加其他人）。如果文件权限太松，别人就能看到你的密钥。
| 文件/目录 | 权限 | 防什么 |
|---|---|---|
.env | 600 | 只有所有者能读写，其他用户看不到 API Key |
credentials/ | 700 | 只有所有者能访问，飞书 Secret 不外泄 |
docker-compose.yml | 640 | 同组可读，但不可写，防止配置被篡改 |
| 其他目录 | 755 | 正常访问即可 |
| 其他文件 | 644 | 正常读取即可 |
为什么是 1000:1000？ 因为容器以 user: "1000:1000" 运行，宿主机文件属主也设为 1000:1000，容器才能正常读写。
四、技能安装：从可信源下载
技能本质上是下载代码并在你的环境中执行。如果下载慢，你可能去非官方渠道找，这就引入了风险。
我的做法：让小智从国内可信镜像站 http://mirror-cn.clawhub.com 安装。
在飞书里告诉小智：
"国内镜像站地址 mirror-cn.clawhub.com，用这个地址下载安装技能。帮我安装一下 [技能名称]"
安全收益：
- 镜像站对技能做了基础安全扫描
- 避免从不明第三方源下载
- 小智自动处理，减少人为操作失误
技能共享的权限考虑：技能默认安装在小智的工作区。为了让所有 Agent 都能用，我把它移到全局目录，并保持只读挂载，防止运行中的 Agent 篡改技能代码。
五、数据备份：最后一道防线
安全配置再完善，也可能有疏漏。定期备份是数据可恢复性的保障。
| 备份内容 | 重要性 | 说明 |
|---|---|---|
workspace/ | ⭐⭐⭐⭐⭐ | Agent 的记忆和规则，丢了要重新训练 |
config/credentials/ | ⭐⭐⭐⭐⭐ | 飞书密钥，泄露可轮换，但丢了麻烦 |
config/openclaw.json | ⭐⭐⭐⭐ | 核心配置，丢了服务无法原样恢复 |
data/ | ⭐⭐⭐⭐ | 聊天记录，不可重建 |
备份策略：每周日凌晨自动备份，保留 28 天。这个窗口足够你发现数据异常并回滚。
六、安全验证：确认配置真的生效
# 验证非 root 运行
docker exec -it openclaw-gateway whoami
# 应输出：node
# 验证根文件系统只读
docker exec -it openclaw-gateway touch /test.txt
# 应报错：Read-only file system
# 验证端口绑定
docker compose ps
# 应显示：127.0.0.1:38459->18789/tcp
# 验证无权限错误
docker compose logs openclaw --tail 50 | grep -i "erofs\|permission"
# 应无输出
七、应急响应：被攻击了怎么办？
7.1 快速止损
# 方案1：暂停（最快，保留现场，方便排查）
docker pause openclaw-gateway
# 方案2：停止（彻底，释放资源）
cd /opt/openclaw && docker compose down
暂停 vs 停止的区别：
| 操作 | 效果 | 适用场景 |
|---|---|---|
docker pause | 冻结进程，保留内存状态 | 怀疑被攻击，需要保留现场分析 |
docker compose down | 停止容器，释放资源 | 确定要重启，或需要彻底清理 |
7.2 排查问题
# 导出日志
docker compose logs openclaw --tail 500 > incident.log
# 检查可疑文件
ls -la /opt/openclaw/workspace/main/skills/
ls -la /opt/openclaw/skills/
# 检查配置文件是否被篡改
diff /opt/openclaw/config/openclaw.json /path/to/backup/openclaw.json
7.3 恢复服务
# 如果之前用了 pause，恢复
docker unpause openclaw-gateway
# 如果之前用了 down，启动
cd /opt/openclaw && docker compose up -d
⚠️ 重要提醒：重启不一定“干净”
docker compose down + up -d 能恢复容器运行状态，但不会清除被篡改的持久化数据：
| 项目 | 重启后是否恢复干净 |
|---|---|
| 内存中的恶意代码 | ✅ 清除 |
| 正在进行的攻击连接 | ✅ 断开 |
| 被篡改的配置文件 | ❌ 如果文件被改了，还在 |
| 被注入的恶意技能 | ❌ 如果技能代码被改了，还在 |
| 被盗取的密钥 | ❌ 密钥文件还在 |
如果需要完全干净的恢复，建议从备份恢复：
# 1. 停止容器
cd /opt/openclaw && docker compose down
# 2. 从备份恢复配置文件
cp /path/to/clean-backup/config/openclaw.json config/
# 3. 清理可疑技能
rm -rf skills/<可疑技能名>
# 4. 重新启动
docker compose up -d
八、常见问题（安全视角）
Q1：2核2G服务器够用吗？
够用。我跑了 5-6 个 Agent，内存限制 1.5G，CPU 限制 1 核，很稳定。资源限制本身就是安全措施——防止某个 Agent 耗光资源导致拒绝服务。
Q2：装技能太慢有安全风险吗？
有。下载慢会诱使你去非官方渠道找资源，增加被植入后门的风险。我的解决方案是使用国内可信镜像站，让小智自动安装。
Q3：docker pause 和 docker stop 有什么区别？
| 命令 | 效果 | 恢复 | 适用场景 |
|---|---|---|---|
docker pause | 冻结进程，保留内存状态 | docker unpause | 保留现场排查 |
docker compose down | 停止并删除容器 | docker compose up -d | 重启服务 |
docker stop | 停止容器，保留容器 | docker start | 临时停止 |
九、安全检查清单
| 检查项 | 状态 | 防什么 |
|---|---|---|
| SSH 端口已改（非 22） | ☐ | 避开自动化扫描 |
| SSH 密码登录已关 | ☐ | 防止暴力破解 |
| 安全组配置了 IP 白名单 | ☐ | 网络层访问控制 |
| 容器以非 root 运行 | ☐ | 限制容器权限 |
| 容器根文件系统只读 | ☐ | 防止容器内篡改 |
| OpenClaw 端口只绑本地 | ☐ | 服务不暴露公网 |
.env 权限 600 | ☐ | 防止 API Key 泄露 |
credentials/ 权限 700 | ☐ | 防止飞书 Secret 泄露 |
| 技能/插件目录只读挂载 | ☐ | 防止代码注入 |
| 定期备份已配置 | ☐ | 数据可恢复 |
| 应急响应命令已熟悉 | ☐ | 被攻击时快速止损 |
最后
回顾我写过的那些 OpenClaw 笔记——《阿里云2核2G服务器玩转OpenClaw：Docker安全部署完全指南》《OpenClaw Docker 部署极速升级指南》《OpenClaw 接入阿里云百炼大模型完整教程》《OpenClaw 接入飞书机器人完整教程》《OpenClaw 多飞书机器人完整配置教程》《亲测有效！OpenClaw卸载重装党狂喜！5步彻底干净》——它们讲的是怎么部署、怎么配置、怎么升级、怎么接入各种服务。
而这篇笔记，是前面所有经验的安全篇总结。
我把自己在实操过程中对安全的思考和做法提炼出来，核心就是这几条：
- 缩小攻击面：改 SSH 端口、关密码登录、安全组白名单、端口只绑本地
- 限制容器权限：非 root 运行、只读根文件系统、最小 Capabilities
- 保护敏感数据：密钥文件 600 权限、凭证目录 700、关键目录只读挂载
- 防止代码注入：技能和插件目录只读、从可信源安装
- 快速止损能力：Docker 部署，一条命令就能暂停或停止服务
- 保证可恢复：定期备份、保留 28 天
这些配置大部分是一次性的，花半小时配好，后面就不用操心了。但如果你忽略了它们，风险会一直存在。
特别提一下应急响应：docker pause 能让你在被攻击时秒级冻结容器、保留现场，从容排查；docker compose down 能快速重启服务。但记住，重启不会清除被篡改的持久化数据——真正的“干净”恢复，需要从备份还原。
安全没有绝对，但能多做一层就多做一层。希望这份笔记对你有帮助。
有问题欢迎交流，我会持续更新。
