Linux 自动化安全加固方案

批量禁用明文协议服务需用ansible的systemd模块同时设enabled: false和masked: true；permitrootlogin必须设为no并reload sshd；pam_faillock.so需正确配置preauth/authfail两行；cron异常多因误建空/etc/cron.allow。

怎么用 ansible-playbook 批量关掉不必要服务

直接停掉 telnet、ftp、rsh 这类明文协议服务，是加固里最立竿见影的一环。但别用 systemctl stop 临时停——重启后又起来，得禁用 + 屏蔽双保险。

• 先查哪些服务在跑：systemctl list-unit-files --type=service | grep enabled，重点关注非系统核心且监听网络的服务
• Playbook 里用 systemd 模块时，必须同时设 enabled: false 和 masked: true，否则 enabled: false 只影响开机启动，服务仍可被其他单元拉起
• masked: true 本质是创建指向 /dev/NULL 的软链，比 disable 更彻底，但会阻断所有依赖它的服务（比如关了 avahi-daemon 可能影响某些打印机发现逻辑）
• 别批量禁用 dbus、systemd-journald、NetworkManager —— Ansible 本身依赖它们，Playbook 会中途断连

为什么 /etc/ssh/sshd_config 的 PermitRootLogin 必须设为 no

不是“建议”，是只要开了密码登录，PermitRootLogin yes 就等于把 root 密码裸奔扔在公网端口上。暴力破解工具扫到 22 端口后，第一轮就专打 root。

• 改完必须 reload：systemctl reload sshd，restart 会断当前连接；Ansible 里用 service 模块时，state: reloaded 比 restarted 更安全
• 如果真需要 root 操作，走普通用户 sudo，且确保 defaults requiretty 在 /etc/sudoers 里没被注释——否则 Ansible 的 sudo 任务会失败
• 别只改这一项：顺手检查 PasswordAuthentication no 和 PubkeyAuthentication yes，密钥登录没配好就关密码，你会被锁在外面

faillock 错误日志里出现 pam_faillock.so(unknown service) 怎么办

这是 PAM 配置漏了模块路径或服务名不匹配，pam_faillock.so 不生效，暴力破解试错成本几乎为零。

• 确认模块存在：find /lib/security -name "pam_faillock.so"，RHEL/centos 路径通常是 /lib64/security/pam_faillock.so，debian/ubuntu 是 /lib/x86_64-linux-gnu/security/pam_faillock.so
• 在 /etc/pam.d/common-auth（Debian系）或 /etc/pam.d/system-auth（RHEL系）里加两行，顺序不能错：
  auth [default=bad success=ok user_unknown=ignore] pam_faillock.so preauth silent deny=5 unlock_time=900
auth [default=die] pam_faillock.so authfail deny=5 unlock_time=900
• 别在 password 段加，那是改密码用的；也别漏掉 preauth 和 authfail 标志——少了它们，锁定逻辑直接失效

自动化加固后 crontab 任务突然不执行了

常见原因是加固脚本顺手改了 /etc/cron.allow 或 /etc/cron.deny，而多数发行版默认靠文件不存在来放行所有用户，一创建空文件就全拒了。

• 检查 /etc/cron.allow 是否被创建：存在且为空 = 只有 root 能用 cron；存在且含用户名 = 仅名单内可用；不存在 = 所有用户可用（前提是没 cron.deny）
• 加固 Playbook 里如果用了 copy 模块写入这些文件，务必加 backup: true，并确认 src 文件内容明确——空文件和没文件语义完全不同
• 另一个坑是 /var/spool/cron/ 下用户 crontab 权限被改成 600 以外的值，cron daemon 会静默忽略；加固后跑一遍 crontab -l -u $USER 确认是否还能读取

真正麻烦的从来不是加几条规则，而是每条规则对已有服务链路的隐性干扰——比如关了 rpcbind，NFS 客户端挂载失败；改了 umask，某些 Java 应用临时文件权限异常。加固不是越狠越好，得盯着监控和日志看实际影响。