服务器安全加固自动化脚本，说到底追求的就是几件事：标准统一、可重复执行、尽量少出错。真正落到动作上，重点通常集中在这些环节：关掉不必要的冗余服务，收紧登录入口，管住权限，及时打补丁，同时把审计痕迹完整留下来。再进一步，还得根据系统类型和业务用途做差异化裁剪，让规则能够动态适配；登录方式上强制使用密钥认证，sudo 只放行白名单命令，关键文件权限要逐项修复，auditd 和远程日志也要一起启用。补丁更新完成后，不能只停留在“装完了”，还需要验证是否真正生效；配置在变更前后都要做好备份，这样一旦出现问题，才能随时回滚。
写服务器安全加固自动化脚本，核心是把人工加固步骤标准化、可重复、少出错。重点不是堆功能，而是聚焦最小必要操作：关冗余服务、锁登录入口、控权限、打补丁、留审计痕迹。
明确加固范围，先做最小化裁剪
脚本不能搞“一套配置走天下”，必须按系统类型来拆分策略，比如 CentOS 7/8、Ubuntu 20.04+、Rocky Linux 各有差异；同时还得看机器用途，是 Web 服务器、数据库，还是跳板机，处理方式都不一样。拿 Web 服务器来说，FTP、Telnet、rsh 这类服务通常默认就该禁用；而数据库服务器还要再往前走一步，额外收紧 MySQL、PostgreSQL 的远程访问，并清理匿名用户。
- 用 os-release 或 uname -r 判断发行版和内核版本，动态加载对应规则
- 通过 systemctl list-unit-files --state=enabled 扫描开机自启服务，只保留 sshd、crond、rsyslog 等必需项
- 用 ss -tlnp 检查监听端口，对非业务端口（如 25、111、631）直接 stop + disable 对应服务
强化身份认证与访问控制
密码登录是最大风险面，脚本必须默认关闭密码认证，强制密钥登录，并设登录失败锁定机制。
- 修改 /etc/ssh/sshd_config：设置 PermitRootLogin no、PasswordAuthentication no、MaxAuthTries 3、LoginGraceTime 60
- 用 faillock（RHEL/CentOS）或 pam_faildelay（Debian/Ubuntu）启用 PAM 登录失败锁定，例如 faillock --user xxx --reset 清除误锁
- 为普通用户配置 sudoers 时，用 visudo -f /etc/sudoers.d/admin 单独管理，禁止 NOPASSWD 全权限，限定命令白名单（如 /bin/systemctl restart nginx）
文件权限与日志审计要落地
很多脚本只改配置不验效果，结果权限仍宽松、日志没归档。加固必须验证+持续记录。
- 批量修复关键文件权限：chmod 600 /etc/shadow /etc/gshadow、chmod 644 /etc/passwd /etc/group、chmod 644 /etc/ssh/sshd_config
- 启用 auditd 并追加规则，例如监控敏感目录：-w /etc/passwd -p wa -k identity，再用 ausearch -k identity 验证是否生效
- 配置 rsyslog 将 auth、sudo、cron 日志发往远程日志服务器（或本地归档），并设置 logrotate 保留至少 90 天
补丁更新与加固后验证不可跳过
脚本最后一步不是“完成”，而是确认加固真实生效。否则可能因配置冲突导致 SSH 断连或服务异常。
- 执行 yum update -y 或 apt upgrade -y 后，用 rpm -q --changelog kernel | head -10（RHEL）或 apt changelog linux-image-$(uname -r)（Ubuntu）检查关键补丁是否已装
- 重启 sshd 前先开一个备用会话，运行 sshd -t 校验配置语法，再 systemctl restart sshd
- 加固完成后自动跑一次基线检查：对比 CIS Benchmark 条目，输出未达标项（如 “SSH PermitEmptyPasswords 未设为 no”），生成简明报告存到 /var/log/hardening-report.log
不复杂但容易忽略的是回滚能力——脚本开头应备份原始配置（如 /etc/ssh/sshd_config.bak），并在出错时提示手动恢复路径。真正的安全加固，不在脚本多炫酷，而在每一步都经得起重放和审计。
