CentOS安全基线检查不是一次性的事情，而是要配合自动化运维工具持续落地执行的系统工程。说白了，你光有一份检查清单没用，得用Ansible、Shell脚本或者专业的安全扫描工具把它跑起来，定期自动执行、自动出报告、自动修复，这才叫真正落地。很多运维团队的问题就出在这里——清单写得漂亮，但全靠人手动检查，三个月后就没人管了。今天这篇文章，我把CentOS 7/8的核心安全基线项逐一拆解，然后给你一套可以直接用的自动化落地方案，拿来就能跑。

一、CentOS安全基线到底查什么

安全基线的本质是给系统设定一个"最低安全标准"，所有服务器都要达到这个标准才能上线。CentOS的安全基线一般涵盖以下几个大类：账户与认证安全、网络与防火墙配置、文件系统权限、服务与端口管理、日志审计、内核参数加固、定时任务与计划任务安全。下面我逐个讲具体检查项和对应的自动化方法。

二、账户与认证安全：最容易被忽视的第一道防线

账户安全是所有安全的起点。你需要检查的具体项包括：是否存在UID为0的非root用户、密码策略是否合规、SSH登录是否禁用root远程登录、是否设置了登录失败锁定机制。具体来说，检查/etc/login.defs和/etc/pam.d/system-auth文件中的密码复杂度要求，确认PASS_MAX_DAYS不超过90天，PASS_MIN_DAYS不少于7天，密码长度至少8位且包含大小写字母、数字和特殊字符。

自动化落地可以用Ansible的lineinfile模块直接修改配置文件，示例如下：

- name: 设置密码最大有效期90天
  lineinfile:
    path: /etc/login.defs
    regexp: '^PASS_MAX_DAYS'
    line: 'PASS_MAX_DAYS   90'

- name: 禁用root SSH远程登录
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^#?PermitRootLogin'
    line: 'PermitRootLogin no'
  notify: restart sshd

同时要配置fail2ban或者pam_faillock来实现登录失败锁定。用Ansible部署fail2ban的jail配置，设置5次失败锁定30分钟，这比手动改配置可靠得多。

三、网络与防火墙：把不该开的口全部堵死

CentOS 7用firewalld，CentOS 8/Stream也是firewalld但底层换成了nftables。基线要求：只开放业务必需的端口，默认拒绝所有入站流量。你需要检查firewalld的默认区域是否为public或drop，是否有多余的rich rule，是否关闭了不必要的服务端口。

自动化方案是用Ansible的firewalld模块管理规则，配合一个端口白名单变量文件。比如你维护一个vars/firewall_ports.yml：

allowed_ports:
  - { port: 22, proto: tcp, note: "SSH" }
  - { port: 80, proto: tcp, note: "HTTP" }
  - { port: 443, proto: tcp, note: "HTTPS" }
  - { port: 3306, proto: tcp, note: "MySQL-内网only" }

然后在playbook里循环开放这些端口，同时确保firewalld默认策略是drop。另外一定要检查iptables/nftables规则是否有残留，CentOS升级过程中经常出现旧规则没清干净的情况。

四、文件系统权限：很多漏洞都是权限配置不当导致的

重点检查项：/etc/passwd、/etc/shadow、/etc/group、/etc/gshadow的权限必须是644和600；/root目录权限700；/tmp和/var/tmp必须设置sticky位（1777）；所有SUID/SGID文件要逐一排查，尤其是/usr/bin/passwd、/usr/bin/sudo这类高权限程序。用find命令批量扫描：

find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null

自动化落地建议写一个Shell脚本，定期cron执行，把结果输出到日志并发送告警。脚本逻辑很简单：扫描权限异常文件，和基线白名单对比，不符合的自动修复或者告警。对于SUID文件，建议维护一个白名单，不在白名单里的直接chmod u-s处理。

五、服务与端口管理：最小化原则是核心

基线要求：关闭所有不必要的服务，只保留业务必需的。用systemctl list-unit-files --state=enabled查看所有开机自启的服务，逐一评估。常见需要关闭的有：cups（打印服务）、avahi-daemon（局域网发现）、bluetooth、postfix（如果不用本地邮件）、rpcbind等。

Ansible自动化管理服务启停非常方便：

- name: 禁用不必要的服务
  systemd:
    name: "{{ item }}"
    enabled: no
    state: stopped
  loop:
    - cups
    - avahi-daemon
    - bluetooth
    - rpcbind
    - postfix
  when: item not in required_services

这里有个关键点：不要一刀切。你需要根据业务场景维护一个required_services变量，不同角色的服务器（Web、数据库、中间件）需要的服务不一样，自动化脚本要支持按角色区分。

六、内核参数加固：sysctl配置是重中之重

CentOS安全基线对内核参数有明确要求，主要涉及网络层抗攻击能力。核心参数包括：开启SYN Cookie防护（net.ipv4.tcp_syncookies=1）、禁用IP转发（net.ipv4.ip_forward=0，除非做路由）、禁用ICMP重定向（net.ipv4.conf.all.accept_redirects=0）、开启源地址验证（net.ipv4.conf.all.rp_filter=1）、限制core dump（kernel.core_pattern=|/usr/libexec/abrt-hook-ccpp）。

自动化方案是用Ansible的sysctl模块或者直接用template模块部署/etc/sysctl.d/99-security.conf：

net.ipv4.tcp_syncookies = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp
kernel.randomize_va_space = 2

部署后执行sysctl -p生效。注意，如果你的服务器需要做NAT或者路由转发，ip_forward要设为1，但要配合严格的防火墙规则。

七、日志审计：没有日志就没有追溯能力

基线要求：rsyslog或journald必须正常运行，日志保留至少180天，/var/log目录权限正确，审计日志（auditd）必须开启并记录关键系统调用。重点审计的事件包括：用户登录登出、su命令使用、权限变更、系统时间修改、selinux状态变更。

自动化方面，用Ansible部署auditd规则文件/etc/audit/rules.d/security.rules：

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /var/log/lastlog -p wa -k logins
-w /var/log/faillog -p wa -k logins
-a always,exit -F arch=b64 -S chmod -S fchmod -F auid>=1000 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -k perm_mod

同时配置logrotate确保日志不会撑爆磁盘，设置日志远程转发到集中日志服务器（比如ELK或者Graylog），这样即使服务器被入侵，日志也不会丢失。

八、SELinux和AppArmor：别嫌麻烦，必须开着

很多运维为了省事把SELinux关了，这是非常危险的做法。CentOS 7/8默认SELinux是enforcing模式，基线要求必须保持。如果某些业务确实需要关闭，必须有充分的评估和审批记录。自动化检查可以用Ansible的selinux模块确保状态为enforcing，同时用semanage管理自定义策略。

九、自动化落地的整体架构建议

光有零散的脚本不够，你需要一套完整的自动化体系。我推荐的架构是：Ansible作为配置管理和编排工具，配合自研的Shell检查脚本做深度扫描，用Cron或者Ansible Tower/AWX做定时调度，检查结果输出到本地日志并推送到企业微信或钉钉告警。具体来说：

第一层：Ansible Playbook负责配置类基线项（账户策略、防火墙、内核参数、服务管理），这些是确定性操作，跑一遍就能保证合规。

第二层：Shell脚本负责扫描类基线项（文件权限、SUID文件、异常进程、网络连接），因为这类检查需要复杂逻辑判断，Shell更灵活。

第三层：定期生成合规报告，可以用Python脚本解析扫描结果生成HTML或PDF报告，方便审计。

第四层：对于不合规项，区分"自动修复"和"人工确认"两类。密码策略、防火墙规则这类可以自动修，但删除SUID文件、修改关键配置这类必须人工确认后再执行。

十、几个容易踩的坑和实战建议

第一，不要在生产环境直接跑自动化脚本，先在测试环境验证。我见过太多人直接上线把SSH配置改错导致全站失联的案例。

第二，基线不是一成不变的。CentOS版本升级、业务变更都需要更新基线配置。建议用Git管理你的Ansible代码和基线配置文件，版本可追溯。

第三，自动化不等于不需要人工。定期（至少每月一次）要有人review自动化脚本的执行结果，检查有没有误报和漏报。机器能做80%的工作，剩下20%的判断还是要靠人。

第四，考虑使用成熟的开源工具作为补充，比如OpenSCAP可以直接做CIS基准扫描并生成报告，Lynis做系统安全审计，这些工具和你自建的自动化体系配合使用效果更好。

总结一下，CentOS安全基线检查清单配合自动化工具落地，核心就是三件事：清单要具体可执行、自动化要分层分模块、结果要可追溯可告警。把这三点做到位，你的服务器安全管理水平会上一个大台阶。