经历过一次等保三级测评现场核查之后，我最大的感触是：测评机构抽到的项目往往不是最复杂的，但一定是最容易被忽视的。这里说的是Linux主机层面的核查，几乎每一家被测单位的系统里都有一堆可以打勾通过的常规项，但真正现场演示时，总有三五处配置不过关，被测评师记为“不符合”或“部分符合”。

这篇文章写给正在做等保三级自查、整改，或者准备配合测评工作的运维和安全人员。我会围绕等保三级里与Linux主机强相关的核查项，把主机核查现场最常发生的事情讲清楚：测评师会查什么、怎么查、通过的标准是什么，以及我踩过和解决的坑。整个过程按“梳理核查边界 -> 逐步演示核查方法 -> 常见扣分项整改”的顺序展开，尽量让即使没参加过等保测评的读者，也能按照文章里的命令和配置自己完成一次自查。

等保三级对应的安全等级，通俗说就是“系统一旦被攻破，影响范围大、后果严重”这一档。因此在安全计算环境层面，对身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范、资源控制、数据备份等大类都有具体要求。网上关于“等保三级核查表”的资料已经很多，但把测评机构的现场核查动作还原成可以直接敲的命令，反而不多。这也正是我想补上的部分。

1. 等保三级到底“考”Linux什么？先理清核查边界

1.1 等保2.0框架里与Linux主机强相关的控制点

等保2.0的三级安全要求分为安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心、安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理等大类。而Linux主机层面，主要落在“安全计算环境”和“安全管理中心”两个大类。

• 安全计算环境：主要包含身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范、可信验证、数据完整性、数据保密性、数据备份恢复等控制点。
• 安全管理中心：包含系统管理、审计管理、安全管理三个角色的分离，以及集中管控。

换句话说，一台Linux服务器能不能过三级，首先要看它的身份鉴别配置、访问控制策略、审计日志覆盖、入侵防范措施、恶意代码防护、资源限制和数据备份机制。这七项基本涵盖了测评师在主机上核查的主要内容。

1.2 测评师现场核查的三种方式

理解核查方式很重要。很多运维只盯着“配置文件改没改”，却忽略了测评师的核查动作往往分三条线：

• 配置检查：直接看/etc/login.defs、/etc/pam.d/system-auth、/etc/ssh/sshd_config等配置文件内容。
• 访谈确认：问管理员“备份策略是什么”“有没有定期恢复演练”，然后要求出示记录。
• 审计验证：查看/var/log/secure、/var/log/messages、auditd审计日志，验证安全事件是否被记录、日志保存周期是否达标。

我们的自查动作要和测评师的核查动作对齐。比如说，测评师不会只看你装了auditd，他还要查审计日志是否真实写入、是否被普通用户篡改。这些细节，后面我会逐个展开。

2. 主机层面最容易被抽到的核查项：身份鉴别与访问控制的现场操作

2.1 身份鉴别：密码策略与锁定机制的现场核查

等保三级在“身份鉴别”控制点下明确要求：应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。另外还要求启用登录失败处理功能，如结束会话、限制非法登录次数和当网络登录连接超时自动退出。

以CentOS 7等常见的Linux发行版为例，实际核查时通常分三步：

第一是查看密码复杂度策略。检查/etc/pam.d/system-auth和/etc/pam.d/password-auth，看是否启用了pam_pwquality模块，并配置了密码长度、复杂度要求。比如：

cat /etc/pam.d/system-auth # 预期能看到： # password requisite pam_pwquality.so try_first_pass local_users_only retry=3 minlen=9 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1

这里minlen=9表示密码最短长度9位，dcredit=-1表示必须包含数字，ucredit=-1表示必须包含大写字母，ocredit=-1表示必须包含特殊字符，lcredit=-1表示必须包含小写字母。如果这行不存在，或者参数不是负值，会被认为“不符合”或“部分符合”。

第二是查看密码有效期。打开/etc/login.defs，关注PASS_MAX_DAYS（密码最长使用天数，常见基线是90天以内）、PASS_MIN_DAYS（最小修改间隔）、PASS_MIN_LEN（最短长度）。同时还要看/etc/shadow中那些有效账户是否有对应字段。

第三是查看登录失败锁定配置。这一步我踩过坑，因为不同版本的Linux、不同的PAM配置方式，锁定的实现路径不一样。CentOS 7/8常见做法是使用pam_faillock：

# /etc/pam.d/system-auth 和 /etc/pam.d/password-auth # 在 auth 段添加： # auth required pam_faillock.so preauth audit silent deny=5 unlock_time=300 # auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=300 # 在 account 段添加： # account required pam_faillock.so

deny=5表示连续失败5次锁定，unlock_time=300表示锁定300秒。如果系统使用了sssd，认证路径可能不一样，需要额外检查/etc/pam.d/system-auth-ac等文件是否内容一致。

2.2 SSH远程登录：身份鉴别的另一个高频扣分点

身份鉴别里还有两个高频检查点：网络登录连接超时和多因素鉴别。多因素鉴别在等保三级中属于增强项，多数单位可以结合堡垒机、动态令牌等实现。如果你们没有上堡垒机，这里很容易被记为“部分符合”。

网络登录超时的标准做法是配置/etc/profile中的TMOUT，以及SSH的ClientAliveInterval和ClientAliveCountMax：

echo 'export TMOUT=600' >> /etc/profile # sshd_config中设置 ClientAliveInterval 300 ClientAliveCountMax 2

TMOUT的单位是秒，600秒表示10分钟无操作自动退出。我在实际核查中发现一个常见问题：很多系统改完/etc/profile后，重新登录却不起作用。原因通常是用户家目录下有自己写的.bash_profile或.bashrc把TMOUT覆盖了，或者/etc/profile.d/下有同名配置冲突。排查时要多留个心眼。

SSH本身的加固也经常被归到“身份鉴别/访问控制”大类里：

# /etc/ssh/sshd_config PermitRootLogin no # 禁止root直接远程登录 PasswordAuthentication yes # 如果业务需要，保留密码认证，但推荐密钥认证 MaxAuthTries 3 # 一次连接允许的认证尝试次数 AllowUsers opsadmin # 仅允许指定账号SSH登录

这里要强调一下：PermitRootLogin no的“no”和“prohibit-password”含义不同。prohibit-password允许密钥登录但禁止密码登录，测评时如果看到这么配，通常可以算“部分符合”或“符合”，取决于现场解释。而完全禁止root远程登录，配合sudo授权给特定运维账号，是最稳的配置。但在某些无法上堡垒机的存量环境里，一刀切禁止root可能导致运维事故，我建议先确认堡垒机或带外管理通道可用，再执行变更。

2.3 访问控制：用户权限分离与最小化授权

访问控制是等保三级对Linux主机最看重的内容之一。测评师一般会看以下几个方面：

• 是否清理了默认账户和无关账户，例如games、lp等非业务账户是否被禁用或删除。
• 是否有明确的超级用户和普通用户分离，root账号是否由专人负责。
• 是否启用了sudo等精细授权机制，而不是把root密码直接给一批人。
• 关键目录和文件的权限是否合理，例如/etc/shadow、/etc/passwd是否可被普通用户修改。
• 是否对重要目录设置了防删保护，例如常用的是chattr +i +a。

另一个容易被扣分的是“危险服务”。虽然三级主要靠防火墙在区域边界封堵，但主机侧如果开着不必要的监听端口，测评师也会在“访问控制”里提出来。自查时可以用ss -tlnp列出所有监听端口，逐一确认服务用途。常见的多余服务包括telnet、ftp、rlogin、smtp（如果本机不需要发信）等。对于不用的服务，要么systemctl disable，要么firewall-cmd移除放行规则。

在用户权限分离方面，我建议日常运维不直接使用root登录，而是配一个普通用户加入wheel组：

useradd opsadmin passwd opsadmin usermod -aG wheel opsadmin

然后给特定命令做sudo白名单：

# /etc/sudoers.d/opsadmin opsadmin ALL=(ALL) /usr/bin/systemctl, /usr/bin/journalctl, /usr/sbin/ss

实际测评时，测评师会翻看sudo -l的输出，如果他发现普通用户能sudo bash、sudo su、sudo edit任意文件，那就等于没有做权限分离，直接扣分。这一点需要特别留意。

3. 审计日志和入侵防范：扣分重灾区的实际核查过程

3.1 安全审计：审计规则与日志留存是硬指标

安全审计这个控制点，在等保三级里几乎每台机器都会被抽到。具体要求是：应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；审计记录包括事件的日期和时间、用户、事件类型、事件是否成功等；审计记录要防止被未预期的删除、修改或覆盖。

先说要开哪些东西：

• rsyslog：保证系统日志写入本地文件。
• auditd：Linux内核审计守护进程，用于记录系统调用、文件访问等安全事件。
• 日志转发到日志服务器：三级要求对审计记录进行集中管理，不能只在本地。

查看rsyslog是否运行、journald是否正常写入、auditd是否active：

systemctl status rsyslog systemctl status auditd ls -l /var/log/secure /var/log/messages /var/log/audit/audit.log

如果auditd没开，整改方式很简单：

systemctl enable --now auditd auditctl -e 1 # 开启审计 auditctl -s # 查看状态

但要注意，auditd开启后默认审计规则很少，测评师往往会抽查“是否对重要文件和命令的修改进行了审计”。例如要求监视/etc/passwd、/etc/shadow、/etc/sudoers、/etc/ssh/sshd_config这些文件的写操作，以及用户删除、权限变更等命令。可以通过配置/etc/audit/rules.d/audit.rules实现：

-w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/sudoers -p wa -k identity -w /etc/ssh/sshd_config -p wa -k sshd_config -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -k perm_chng -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -k owners_chng -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -k file_delete

这套规则不算复杂，但对结论影响很大。测评师现场经常做的一件事就是tail审计日志，然后说“审计范围只有系统登录，用户操作没覆盖到”，接着记个“部分符合”。所以我在整改时都会主动把文件监控规则加上，并在核查前实际产生一两条可查的审计记录，比如用sudo执行一次命令，再ausearch搜出来，证明规则可触发。

审计日志的留存时间也是个硬指标。等保三级一般要求日志保存不少于6个月。很多服务器/var/log默认空间只有几GB，单开auditd和rsyslog之后，很快会被刷满。如果不解决磁盘容量问题，整改时需要在/etc/audit/auditd.conf里调整：

max_log_file = 512 max_log_file_percent = 75 space_left = 75 space_left_action = SYSLOG admin_space_left = 50 admin_space_left_action = SYSLOG num_logs = 20 flush = INCREMENTAL_ASYNC

同时要保证/var/log所在分区有足够空间。我遇到过一台机器把/var独立分区划了2GB，开审计日志后两周就满了，空间不足导致auditd停止审计，核查时照样被记为不符合。所以别只配规则，还要规划磁盘容量。

日志完整性保护方面，推荐把日志文件设置成仅管理员能写。对于系统日志，/var/log/audit的权限默认是root:root 600或640，这个没问题；但/var/log/messages如果权限是644，普通用户也能读，虽然不算严重扣分，但测评师会在“敏感信息保护”上提出意见。

3.2 入侵防范：从补丁更新到最小化安装

入侵防范控制点要求：应遵循最小安装的原则，仅安装需要的组件和应用程序；应关闭不需要的系统服务、默认共享和高危端口；应通过设定终端接入方式、网络地址范围等限制远程管理；应能发现可能存在的已知漏洞，并在经过充分测试评估后及时修补漏洞。

翻译成主机自查动作就是四件事。

第一，确认只安装了业务必需的软件包。自查时可以看rpm -qa或dpkg -l列出的包数量，如果系统初始安装时选了“带图形界面”且装了X Window、办公软件、开发工具链，测评师大概率会提意见。存量系统处理起来麻烦一些，但至少要保证桌面相关包不会出现在生产主机上。不用的包可以yum remove或dnf remove，也可以在整改报告里说明“已停用相关服务且网络侧不可达”。

第二，关闭无用的系统服务和端口。重点检查那些默认随开机启动的服务：

systemctl list-unit-files --type=service --state=enabled ss -tlnp

像cups、avahi-daemon、postfix（非邮件主机）、rpcbind、nfs等，如果没有实际用途就禁用掉。ssh、ntpd/chronyd、rsyslog这些保留，但要做好访问限制。

第三，补丁更新。测评并不是看当前补丁日期，而是看有没有建立补丁更新机制。也就是说，至少要有一个“定期检查漏洞并升级补丁”的流程记录。系统侧可以配置好yum/apt源，保证可以正常安装安全更新：

yum update --security -y

但生产环境升级有风险，所以等保测评更看重流程和记录，比如每季度有漏洞扫描报告、每季度有补丁更新审批表。主机自查时，最好把这些记录整理好，而不是只敲命令。

第四，防暴力破解和SSH防护。这部分既属于入侵防范也属于身份鉴别。更稳的做法是在主机上启用fail2ban这类防护，或者在边界防火墙上做源IP限制。如果业务IP段固定，建议在sshd_config或防火墙层限制来源网段。使用hosts.allow/hosts.deny时要注意，现代Linux很多服务不再走tcpd，如果SSH使用了最新配置且系统启用了firewalld，更推荐把源IP限制放在防火墙层：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" service name="ssh" accept' firewall-cmd --reload

这样即便SSH爆破打到主机，防火墙就直接丢了，比在sshd层防更彻底。

3.3 恶意代码防范：安装杀毒软件之后才是开始

等保三级在恶意代码防范控制点里有一条：应安装防恶意代码软件或加固具有相应功能的软件，并定期更新病毒库和查杀病毒。Linux生产环境里，这条经常被误解为“不用装杀毒”，但在等保测评里，如果不部署任何防恶意代码软件，通常会被记为“不符合”或“部分符合”。

最常见的合规思路是在Linux主机上安装ClamAV，并配合病毒库更新和定期扫描任务。CentOS安装：

yum install -y epel-release yum install -y clamav clamav-update freshclam systemctl enable --now clamd@scan

扫描任务加入cron，例如每周日凌晨扫描一次：

0 3 * * 0 clamscan -r /var /etc /home --move=/tmp/virus -l /var/log/clamav/clamscan.log

需要注意一点：如果单位已经购置了商业终端安全管理软件，并且扫描记录可以从管理平台导出，也可以视为满足控制点。测评时最有说服力的就是“部署名-版本-病毒库日期-最近的扫描记录”这一整套证据。别只装了ClamAV却不更新库，现场freshclam一跑，显示库是三个月前的，反而更扣分。

4. 资源控制与数据安全：三级标准里的“硬价格”

4.1 资源控制：并发会话限制与进程监控

资源控制这个控制点包含多项内容：应限制单个用户的多重并发会话、应限制终端接入方式、应提供登录连接超时并自动退出机制、应能够对重要程序进程进行监控等。

实操上，限制并发会话数量，可以在/etc/security/limits.conf里配置maxlogins：

* hard maxlogins 5

表示普通用户最多同时登录5个会话。root可以在单独条目里限制，但要注意root如果maxlogins太小，可能把自己踢出去。生产上建议root和普通用户分开限制，或者不限制root，靠堡垒机保证操作可审计。

进程监控方面，如果服务器数量不多，可以用脚本采集CPU、内存、磁盘、进程数；如果规模大，建议放到监控平台统一展示。测评师看的是“有没有监控手段”，但监控平台要能证明防止了资源耗尽，比如限制了单进程内存使用、设置了文件句柄数上限。这个日常配置通常放在/etc/security/limits.conf：

* soft nproc 1024 * hard nproc 65535 * soft nofile 1024 * hard nofile 65535

但我建议先了解业务实际用量再设置，否则把nproc砍得太低，可能直接拖垮应用。合理做法是先观察一周峰值再慢慢收紧。

4.2 数据备份与恢复：贵在“能证明有效”

数据安全及备份恢复是等保三级里最容易被“打回”的部分，因为很多单位只备份到了本地磁盘，没有异地备份，也没有定期恢复验证记录。

三级要求包括：

• 应提供本地数据备份与恢复功能，完全数据备份至少每天一次，备份介质场外存放。
• 应提供异地实时备份功能，利用通信网络将数据实时备份至备份场地。
• 应提供重要数据处理系统的热冗余，保证系统的高可用性。

说实话，这个控制点对很多中小单位来说是成本大头。主机层面我们能做的是把备份脚本本身准备好，把备份记录留好。一个简单的rsync或tar备份计划：

#!/bin/bash DAY=$(date +%F) BACKUP_DIR=/data/backup tar czf ${BACKUP_DIR}/etc_${DAY}.tar.gz /etc /var/spool/cron /root/.ssh find ${BACKUP_DIR} -type f -mtime +30 -delete

再配置每天定时执行，并保留执行日志。如果单位没有独立备份一体机，也可以把备份推送到异地的rsync服务器或对象存储里。测评师最看重的是备份是否能恢复。口头说“我们每周备份”没用，要能出示“上月做过一次恢复演练，在测试环境把备份恢复成功”的记录。这个建议一定要写进整改计划，因为只有备份没有恢复演练，在很多三级测评报告里一样会被记为部分符合。

4.3 数据保密性与完整性：别让数据裸奔

三级还要求采用密码技术保证重要数据在传输和存储过程中的保密性、完整性。主机层面常见的落点包括：

• 数据库、中间件与客户端之间是否启用SSL/TLS加密。
• 备份文件是否加密存储。
• 系统盘的LUKS全盘加密或重要目录的加密。
• 文件完整性校验（如AIDE）是否定期运行。

对Linux系统来说，如果重要应用都在内网，测评师通常不会严格要求全盘加密，但备份文件的加密和传输加密容易成为扣分点。比如备份文件直接明文存在共享存储上、明文FTP传输备份，就很容易在访谈环节被发现并记为不符合。

文件完整性监控用AIDE最省事：

yum install -y aide aide --init mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz aide --check

初始建立数据库，然后定期检查并比对。第一次初始化时建议排除掉频繁变化的目录，比如/var/log、/tmp，否则每次检查都会刷出一堆变更，慢慢就没人看了。这类工具部署起来不难，难在坚持看结果。我会在监控平台或cron里配置告警，只要结果非零就发邮件。

5. 我踩过的整改坑：从自查到通过测评的完整记录

5.1 坑一：PAM配置改了不生效，问题出在复合认证链

某次给一台存量CentOS 7.9做登录失败锁定配置，我把pam_faillock加进了/etc/pam.d/system-auth，反复测试，第5次错误密码后，第6次依然可以继续输入。排查了半天，发现/etc/pam.d/system-auth-ac是实际被加载的认证文件，很多系统在authconfig篡改后会把配置同步到*-ac文件，但手动改system-auth并不会同步到ac文件。后来我直接把锁定配置同时写入system-auth和password-auth，并让system-auth软链到system-auth-ac，问题才消失。

这个坑提醒我：改PAM文件前先看清楚/etc/pam.d/下的软链关系。不同的审计基线、加固工具也可能把配置文件恢复到默认状态，所以改完必须实测一次，不要只是cat看内容符合就完了。

5.2 坑二：会话超时和用户全局配置打架

前面提到TMOUT不生效的问题，实际排查链路是这样的：先在/etc/profile设了TMOUT=600，但测试用户依然挂着一天不掉线。随后发现用户家目录的.bash_profile里有TMOUT=0，等于覆盖了全局配置。解决办法是用/etc/profile.d/下单独文件，并在其中强制只读：

cat > /etc/profile.d/tmout.sh <<'EOF' readonly TMOUT=600 export TMOUT EOF

注意readonly一旦设置，当前shell无法取消。但用户依然可以在自己的.bashrc里写一个不加载profile的逻辑？实际上交互式登录shell会先读取/etc/profile，所以这个方案对大多数登录方式有效。如果用户使用su切换而非SSH登录，需要额外确认su是否会加载profile。这点在核查时很容易被测评师用“临时开一个用户试试”的方式验证，所以一定要实际多测试几种登录方式。

5.3 坑三：日志留存时间检查不了了之

有台服务器的/var/log/audit/audit.log只有3天的数据，但系统明明装了不止3天。后来发现是auditd的max_log_file设置太小，日志轮转后旧文件被删除，本地最多只能留三天。把max_log_file调大到512MB并配置num_logs=10之后，落地数据足够覆盖6个月。

不过还有一个背景问题：如果审计日志没有外送，只有本地，单机被攻破后攻方可以清理日志，三级要求实质上更倾向于日志集中存储。所以我后来给所有重要服务器都配置了rsyslog远程转发，确保本地即使被清理，远端日志服务器上仍然有数据。这也是测评师在“安全管理中心-集中管控”里会关心的点。

下面是rsyslog简单转发配置：

# 客户端 cat > /etc/rsyslog.d/50-remote.conf <<'EOF' *.* @@logserver.example.com:514 EOF systemctl restart rsyslog

如果网络环境不允许明文传输，可以用RELP或TLS，或者干脆用filebeat/fluentd把日志推到集中日志平台。对于三级测评，关键是日志能跨主机集中管理，并且有权限隔离。

5.4 坑四：备份验证这个“证据”比想象中更重要

我们单位有段时间备份脚本天天跑，日志也写得很漂亮，但测评机构访谈时问了一句“最近的恢复演练记录是什么时候，测试环境上面验证了什么”，现场没人能拿出记录。后来我们改成每个季度做一次恢复演练，在虚拟机上导入备份并启动应用，输出一份简报，包含恢复时间、数据校验结果、问题记录。这个记录在测评现场特别有说服力，花费也不高，强烈建议直接补上。

5.5 从整改到复测：一份主机自查动作表

最后分享一份我在多个等保三级整改项目中用过的主机自查动作表，每一步都对应前面介绍过的核查项。你可以直接拿去做巡检：

另外，我在多次整改之后，把上面表格里的配置项汇总成了一个极简的自查脚本，脚本只做“检查+输出状态”，不做任何修改，适合在测评前快速跑一遍。核心逻辑就是逐个grep配置文件、逐个systemctl is-active，最终输出一张类似上面表格的状态汇总。第一次完整执行需要30到40分钟，之后每周例行巡检反而很轻松。

这里多说一句：不要为了测评临时把所有配置都按基线改掉，改完却不测试业务。等保三级核查说到底是一次安全能力验证，不是考试突击。我见过太多单位在整改时把PAM、limits.conf、SELinux全部按等保要求改了，第二天应用起不来，加班回滚，测评现场又被打回原形。正确的节奏是，先评估变更影响范围，再分批灰度，最后再拉测。这样看起来慢，实际最省时间。

希望这篇文章对正在准备等保三级Linux主机核查的朋友有帮助。如果你在自查中踩过其他坑，也欢迎在评论区补充，我看了会继续更新这个核查清单。