蜜蜂云帆 CLOUD WIKI
云安全

云服务器安全加固实战清单：上线前必须做的 10 件事

2026年10月13日 更新 2026-10-28 11 分钟读完 4362 字
本文目录
  1. 第一层：收缩暴露面
  2. 1. 安全组只放必需端口
  3. 2. 主机防火墙做第二道兜底
  4. 第二层：身份与访问
  5. 3. SSH：换端口 + 密钥登录 + 禁 root
  6. 4. fail2ban 自动封禁爆破源
  7. 5. 服务不以 root 运行
  8. 第三层：补丁与运行环境
  9. 6. 及时打补丁，建立固定节奏
  10. 7. 关掉不用的服务与危险配置
  11. 第四层：可观测与恢复
  12. 8. 集中日志与关键告警
  13. 9. 备份遵循 3-2-1，并验证可恢复
  14. 10. 上 WAF，并做一次基线核查
  15. 加固检查表

云服务器被入侵的方式高度集中：SSH 弱口令爆破、未打补丁的中间件漏洞、安全组放开 0.0.0.0/0 的高危端口、应用以 root 运行。上线前把下面十项做完，能挡掉绝大多数自动化攻击。这份清单按"先收缩暴露面，再加固身份，最后做可观测与恢复"的顺序排列，照着做即可。

判断标准只有一条：假设攻击者已经知道你的 IP，他能在不借助任何 0day 的情况下走多远。清单的目的就是把这条路堵死。

第一层：收缩暴露面

1. 安全组只放必需端口

安全组是云平台侧的虚拟防火墙，优先级高于系统内防火墙，很多事故源于这里默认放通了全部端口。原则是最小化：只开放 80/443 给全网，SSH 限制定来源 IP，数据库端口（3306/5432/6379）一律不开公网，仅内网互通。

# 只允许办公 IP 访问 SSH
入方向  TCP 22    源 203.0.113.10/32   允许
入方向  TCP 443   源 0.0.0.0/0        允许
入方向  TCP 80    源 0.0.0.0/0        允许
出方向  全部      目的 0.0.0.0/0       允许
其余默认拒绝

2. 主机防火墙做第二道兜底

安全组配错、换云厂商、内网横向移动，这几种情况主机防火墙都能兜住。CentOS 用 firewalld，Ubuntu 用 ufw，规则与安全组保持一致。

# Ubuntu
ufw default deny incoming
ufw allow from 203.0.113.10 to any port 22
ufw allow 80,443/tcp
ufw enable && ufw status verbose

第二层：身份与访问

3. SSH：换端口 + 密钥登录 + 禁 root

三步做完能挡掉 95% 以上的自动爆破。密钥用 ed25519 生成，公钥写入 authorized_keys，确认能免密登录后再关密码认证——顺序反了会把自己锁在门外。

# 本地生成密钥
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# 服务端 /etc/ssh/sshd_config
Port 22022
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
# 校验并重载
sshd -t && systemctl reload sshd

改端口后记得同步更新安全组与云监控；如果用 CI/CD 或跳板机登录，先把新端口和密钥分发到所有自动化节点，再关闭旧通道。

4. fail2ban 自动封禁爆破源

换端口只是降低扫描命中率，日志里仍然会有尝试。fail2ban 读取 sshd 日志，在阈值内封禁来源 IP，这是性价比最高的一层动态防护。

apt install fail2ban -y
# /etc/fail2ban/jail.local
[sshd]
enabled = true
port    = 22022
maxretry = 3
findtime = 600
bantime  = 86400
systemctl enable --now fail2ban
fail2ban-client status sshd

5. 服务不以 root 运行

应用被拿下时，进程权限就是攻击者的权限。为每个服务建独立系统用户，只给必要目录的读写权限，端口小于 1024 的用反向代理或 setcap 转发。数据库同样如此，禁止应用账号拥有 DROP 与 GRANT 权限。

useradd -r -s /sbin/nologin appuser
chown -R appuser:appuser /opt/myapp
# 需要绑定 80 端口时
setcap 'cap_net_bind_service=+ep' /opt/myapp/bin/server

第三层：补丁与运行环境

6. 及时打补丁，建立固定节奏

绝大多数被入侵的主机，漏洞在半年前就已公开。不要让"不敢重启"变成不打补丁的理由：先在预发验证，再滚动重启，配合负载均衡做无损发布。内核热补丁可以救急，但不能长期替代重启。

# Debian/Ubuntu
apt update && apt list --upgradable
unattended-upgrade --dry-run
# RHEL/CentOS
dnf check-update --security
dnf update --security

7. 关掉不用的服务与危险配置

新机器常见的问题：装上就没用的 FTP、开着 6379 无密码的 Redis、PHP 的 allow_url_include、暴露的 /server-status。用 ss -tlnp 列出所有监听端口，逐个确认用途，没有归属的一律关闭。

ss -tlnp
systemctl list-unit-files --state=enabled
# Redis 必须绑定内网并设密码
bind 127.0.0.1 10.0.1.15
requirepass <强随机口令>

第四层：可观测与恢复

8. 集中日志与关键告警

日志留在被入侵的机器上等于没有。至少把 sshd、nginx、应用日志推送到另一台机器或日志服务，并对以下事件设告警：SSH 登录失败次数陡增、成功登录来自新地域、安全组规则被修改、磁盘与 CPU 长时间打满、Web 目录出现 .php 文件变更。

  • sshd 认证日志：/var/log/auth.log 或 /var/log/secure
  • Web 访问与错误日志：nginx access.log / error.log
  • 系统审计：auditd 记录关键文件写入与提权
  • 云平台操作审计：控制台登录、API 调用记录

9. 备份遵循 3-2-1，并验证可恢复

3 份数据、2 种介质、1 份异地。实践中最容易漏的是"验证"：备份任务天天成功，真出事时发现压缩包损坏或数据库 dump 缺表。每月至少做一次真实恢复演练，恢复到临时实例并跑通核心流程。

# MySQL 逻辑备份示例
mysqldump --single-transaction --quick --routines 
  -u backup -p dbname | gzip > /backup/db-$(date +%F).sql.gz
# 校验完整性
gzip -t /backup/db-$(date +%F).sql.gz && echo OK

10. 上 WAF，并做一次基线核查

WAF 挡的是 SQL 注入、XSS、恶意扫描这类应用层攻击，不能替代前面的系统加固，但对公开站点是必要的纵深。基线核查则用自动化工具把上面九项再过一遍，避免手工操作的遗漏，CIS Benchmark 是常用的参考标准。

# 开源基线核查
curl -s https://raw.githubusercontent.com/aquasecurity/kube-bench/main/... # 容器场景
# 主机场景常用 lynis
apt install lynis -y && lynis audit system

加固检查表

# 检查项 通过标准 验证命令
1 安全组最小化 仅 80/443 全网开放，SSH 限源 IP 控制台规则审查
2 主机防火墙 默认拒绝入站，规则与安全组一致 ufw status / firewall-cmd --list-all
3 SSH 加固 非 22 端口、密钥登录、禁 root sshd -T | grep -E 'password|root|port'
4 fail2ban sshd jail 处于 active fail2ban-client status sshd
5 服务降权 应用进程非 root ps -eo user,pid,cmd | grep app
6 补丁节奏 无待安装的安全更新 dnf update --security --dry-run
7 端口收敛 监听端口均有明确归属 ss -tlnp
8 日志外送 关键日志留存 ≥ 30 天且异地 抽查日志平台
9 备份可恢复 近 30 天内完成过恢复演练 恢复记录
10 WAF + 基线 WAF 开启，基线核查无高危项 lynis 报告

这张表建议直接放进上线检查单，每项留一个负责人和验证时间。具体到资源规划与责任划分，可结合什么是云服务器中讲的责任共担模型理解：平台负责物理与虚拟化层，操作系统以上全是你的责任。

常见问题

改了 SSH 端口还是被爆破怎么办？

换端口只能降低扫描命中率，全端口扫描仍能找到。真正有效的组合是禁用密码登录只留密钥、加 fail2ban 动态封禁、并把 SSH 来源限制在固定 IP 或通过跳板机接入。

云服务器只靠安全组不开主机防火墙可以吗？

不建议。安全组在云网络层生效，一旦被误改、换服务商或发生内网横向移动就失去防护。主机防火墙成本极低，两条规则就能形成第二道兜底，属于必做项。

打了补丁需要重启，业务不能停怎么办？

用负载均衡做滚动发布：先摘一台节点、更新并重启、健康检查通过后再处理下一台。做不到多节点的单机业务，应提前规划维护窗口，或使用内核热补丁过渡，但热补丁不能永久替代重启。

备份做了就能防勒索软件吗？

不一定。备份目录若挂载在同一台机器上并可写，勒索软件会一起加密。必须保证至少一份备份在异地的、只写的、与生产环境凭据隔离的存储上，并定期验证恢复。

延伸阅读

# SSH # 备份 # 安全加固 # 防火墙

相关文章