Linux 云服务器上线前,先做完这 8 项安全检查

Linux 云技术栈

一台云服务器最危险的时刻，往往不是服务挂了，而是服务刚刚上线：SSH 还在用密码，数据库端口直接暴露，Docker 映射出来的端口没人盘过，备份也从来没恢复过。

这篇不讲“万能加固脚本”，只给一份可以在 Ubuntu 云主机上逐项执行的检查清单，适合网站、API、Docker 服务和个人项目。

/ / /

1. 先盘点：机器到底暴露了什么

先回答三个问题：谁能登录？哪些端口对公网开放？哪些服务必须常驻？

# 当前监听端口
sudo ss -lntup

# 已运行的服务
systemctl --type=service --state=running

# 当前登录和最近登录记录
who
last -n 20

看到不认识的监听端口，先查清进程来源，再决定是否关闭。不要在不了解依赖关系时直接 kill 进程，云主机上最常见的事故之一，就是把唯一的管理入口关掉。

/ / /

2. SSH：先验证密钥，再收紧入口

OpenSSH 支持公钥认证。实际操作时，顺序比配置项更重要：

1. [01]创建或确认本地密钥；
3. [02]把公钥写入目标用户的 ~/.ssh/authorized_keys；
5. [03]新开终端，确认密钥登录成功；
7. [04]保留当前 SSH 会话；
9. [05]最后再考虑关闭密码登录和 root 远程登录。

ssh-keygen -t ed25519 -C "your-name@your-device"
ssh-copy-id user@server-ip
ssh user@server-ip

修改 SSH 配置后，先检查语法：

sudo sshd -t
sudo systemctl reload ssh.service

远程机器上改 SSH，永远不要只开一个终端窗口操作。Ubuntu 文档也特别提醒，配置错误可能让你失去远程入口。

/ / /

3. 防火墙：只放行真正需要的端口

Ubuntu 常用 ufw 管理主机级防火墙。一个克制的起点是：默认拒绝入站，只开放 SSH、HTTP 和 HTTPS。

sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH 不是 22 端口时，请替换成实际端口
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw --dry-run enable
sudo ufw enable
sudo ufw status verbose

数据库、Redis、内部管理面板通常不应该直接暴露到公网。优先让它们只监听内网地址，或者通过 VPN、跳板机和 SSH 隧道访问。

/ / /

4. Docker 端口，不等于防火墙已经管住

这是很多加固清单里最容易漏掉的一项。Docker 发布容器端口时，会参与配置 iptables 规则；官方文档提醒，容器暴露端口可能绕过 ufw 或 firewalld 的预期规则。

docker ps --format "table {{.Names}}\\t{{.Ports}}"
sudo iptables -S DOCKER-USER

更稳妥的做法是：

• -不需要公网访问的服务绑定到 127.0.0.1；
• -只让反向代理暴露 80/443；
• -同时检查 iptables、DOCKER-USER 链和云厂商安全组；
• -不把 Docker socket 暴露给不可信容器。

/ / /

5. 最小权限：谨慎把用户加入 docker 组

能控制 Docker daemon 的用户，通常就具备接近宿主机 root 的能力。建议日常使用普通用户，需要提权时使用 sudo，并定期检查授权。

getent group sudo
getent group docker
sudo -l -U username

权限越方便，失误的半径通常也越大。对生产机，这个取舍应该被记录下来。

/ / /

6. 更新系统，同时保留回滚路径

补丁不是跑一次 apt upgrade 就结束。上线前至少确认安全更新正常、内核升级后是否需要重启、关键服务是否有备份。

sudo apt update
apt list --upgradable
sudo apt upgrade

# 判断是否需要重启
test -f /var/run/reboot-required && echo "需要重启"

生产机器建议先在测试实例验证，再安排维护窗口。升级前记录当前版本和服务状态，出问题时才知道从哪里回退。

/ / /

7. 日志和告警：别等磁盘满了才发现异常

至少检查 SSH、系统服务和磁盘空间。日志本身不是监控，但没有日志，监控也很难解释。

# SSH 服务最近的日志
sudo journalctl -u ssh.service --since "1 hour ago"

# 磁盘与 inode
df -h
df -ih

# 最近的错误级别日志
sudo journalctl -p warning..alert -b

长期运行的服务器，还应监控磁盘、CPU、内存、证书到期时间和备份结果。“能访问”不等于“运行正常”。

/ / /

8. 最后做一次恢复演练

备份文件存在，只能证明备份动作发生过，不能证明你能恢复。

至少演练一次：

• -从备份恢复数据库到临时实例；
• -从对象存储下载文件并校验；
• -重新部署一个最小版本的应用；
• -记录恢复耗时和缺失的凭证。

如果恢复步骤只能靠某个人记忆，系统就还没有真正可运维。

/ / /

一份上线前速查表

/ / /

写在最后

Linux 云服务器安全不是把命令复制进终端就结束了。真正有用的检查，应该能回答三件事：入口在哪里、异常怎么发现、坏了以后怎么恢复。

先把这 8 项跑一遍，再考虑更复杂的扫描器、零信任和自动化策略。很多时候，最划算的安全投入不是再装一个工具，而是把已有端口、权限、日志和备份真正盘清楚。

资料参考：

• -Ubuntu Server 安全文档：https://documentation.ubuntu.com/server/how-to/security/
• -Ubuntu 防火墙文档：https://documentation.ubuntu.com/server/how-to/security/firewalls/
• -Ubuntu OpenSSH 文档：https://documentation.ubuntu.com/server/how-to/security/openssh-server/
• -Docker Ubuntu 安装与防火墙说明：https://docs.docker.com/engine/install/ubuntu/