服务器安全合规审计：从基线检查到整改验证的操作流程
服务器安全合规审计，本质是拿一份安全基线逐项对照服务器现状，找出不符合项并整改，最后留下可复核的记录。
它不依赖昂贵设备，一台普通 Linux 服务器就能开始。
下面按检查、整改、验证的顺序讲清楚，命令以 CentOS 7/8 和 Ubuntu 20.04 以上常见环境为例，其他发行版注意包管理器和配置文件路径差异。
先明确审计范围和操作前提
动手前先确定三件事：要审计哪些机器、以什么标准检查、改动前如何回滚。
- 建议先在测试机或低峰期操作，重要配置修改前执行
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak备份。 - 确认你有
root或sudo权限，并保留一个已登录的 SSH 会话，避免改错 SSH 配置后把自己关在门外。 - 审计标准可参考等保或 CIS 基线，但不必一次做全，优先处理账号、SSH、防火墙、日志、补丁五类高风险项。
账号与权限的核查方法
先看有哪些账号能登录、哪些账号拥有特权。
# 查看可登录用户
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd
# 查看 UID 为 0 的特权账号
awk -F: '$3 == 0 {print $1}' /etc/passwd
# 查看最近登录情况
lastlog | head预期结果是：只保留必要的可登录账号，UID 为 0 的除 root 外没有多余账号。
如果发现陌生账号或空密码账号，用 passwd -l 用户名 锁定，确认无用后再 userdel 删除。
空密码账号可用 awk -F: '($2 == "") {print $1}' /etc/shadow 查找。
SSH 与防火墙的整改要点
这两项是外部入侵最常利用的入口，整改后效果也最直接。
编辑 /etc/ssh/sshd_config，关注以下配置项：
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 5
ClientAliveInterval 300
ClientAliveCountMax 2改完先执行 sshd -t 检查语法，没有输出说明配置合法，再执行 systemctl restart sshd。
注意：关闭密码登录前，必须确认密钥登录已经可用，否则会立即失去远程连接。
防火墙方面，先确认规则再放行端口，避免误封业务：
# firewalld
firewall-cmd --list-all
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
# ufw
ufw status verbose
ufw allow 22/tcp原则是只放行必要端口，数据库、缓存等内部服务不要对公网开放。
日志、补丁与高危项的复查
审计不止看配置，还要看有没有异常痕迹和已知漏洞。
- 日志检查：用
lastb | head查看失败登录来源，用journalctl -u sshd --since today查看当天 SSH 日志。出现大量来自同一 IP 的失败登录，考虑用fail2ban或防火墙封禁。 - 补丁检查：CentOS 用
yum check-update，Ubuntu 用apt list --upgradable，确认安全更新是否安装。生产环境升级前先在测试机验证，不要直接在生产执行全量升级。 - 文件权限：检查
ls -l /etc/shadow，正常应为000或400且属主为 root；/tmp目录建议挂载时加noexec，降低恶意脚本执行风险。
整改后怎样验证审计是否生效
整改完不要凭感觉收工，用命令复查并留存输出。
sshd -T | grep -E 'permitrootlogin|passwordauthentication'
firewall-cmd --list-ports
awk -F: '$2 == "" {print $1}' /etc/shadow对比整改前的记录，确认每一项都符合预期。
建议把检查命令和结果整理成一份文档，注明执行日期和机器 IP，下次复查时可以直接对照。
容易踩坑的地方
- 关闭密码登录前没测通密钥，导致无法远程登录，只能走控制台救援。
- 防火墙规则只加临时规则没加
--permanent，重启后失效。 - 直接删除账号而不是先锁定，可能影响依赖该账号运行的服务。
- 只做一次审计就不再复查，账号和端口会随业务变化重新出现风险。
如果审计范围扩大到多台服务器或需要定期出具报告，建议先把单机流程跑顺，再考虑用脚本或配置管理工具批量执行。
