企业官网建设流程全解析

接到一个等保测评项目，进入客户机房，登录现场的Red Hat Enterprise Linux服务器，第一件事不是打开浏览器查扫描报告，而是先把手头常用的核查命令在脑海里过一遍。做过等保的人都有体会，Red Hat Enterprise Linux在企业服务器里的占比高得离谱，几乎每个测评项目都会遇到，而等保测评命令这套东西，熟练程度直接决定了人天成本和测评报告的准确性。哪怕客户现场一条记录、一次变更、一个服务状态都能通过命令行快速确认，不需要跟客户翻几年前的变更记录扯皮。这篇文章不绕弯子，直接梳理我在RHEL环境下做等保测评时最常用、最能出有效结论的命令体系，以及每个命令背后的安全意义和踩坑经验。

1. 为什么等保测评命令在RHEL上如此关键

很多刚入行的测评人员习惯用扫描器或图形界面工具去采集系统信息，到了Red Hat Enterprise Linux上却会发现，扫描器给出的结果经常是“半成品”：版本信息可能不准确、补丁信息缺失、配置采集不全，尤其是一台运行了五六年的老服务器，上面堆了各种历史配置，图形化工具根本看不出配置到底有没有生效。这时候，命令行就是最可靠的抓手，原因其实很朴素。

第一，等保测评的标准项绝大多数落实在配置文件和服务状态上。比如身份鉴别里的口令复杂度、登录失败处理、访问控制里的用户权限、安全审计里的日志策略，这些都是操作系统层面的具体设置，用命令直接读配置、查状态，结果非常明确，不会被工具误判。

第二，Red Hat Enterprise Linux的配置文件位置基本固定，通过命令可以快速定位。比如/etc/login.defs管密码策略，/etc/pam.d/system-auth管认证模块，/etc/ssh/sshd_config管远程登录，/etc/audit/auditd.conf管审计服务。测什么就看什么，干净利索。

第三，测评记录需要一个可追踪的证据链。命令行下执行的操作、回显的输出、时间戳、执行人，都能形成完整的审计记录，这是等保测评合规性的要求。等保测评本来就是“以事实为依据，以标准为准绳”，命令输出就是最扎实的事实依据。

这里提一句适用范围，我下面写的命令大多数适用于RHEL 6、7、8系，不同小版本之间个别文件路径和命令名称会有差异，比如RHEL 8里网络配置用nmcli为主，RHEL 6里还在用iptables为主，但核查思路是相通的。测评现场我会先确认系统版本，再决定具体命令的组合方式。确认版本本身也就一条命令的事。

2. 测评前的环境确认与权限准备

2.1 先摸清系统版本和主机状态

到现场后第一件事不是急着测安全配置，而是先摸清楚这台机器到底是什么版本、跑了多久、补丁大概什么水平。等保测评里面有个通用要求项涉及“产品版本”和“补丁升级”，很多测评机构也会重点核查这个，因为版本过老意味着大量已知漏洞长期暴露。

cat /etc/redhat-release uname -a hostnamectl uptime

这几个命令跑完，系统大版本、内核版本、主机名、开机时长都齐了。RHEL 7.x和RHEL 8.x的测评项侧重点会有差别，比如RHEL 8里默认用chrony做时间同步、SELinux状态更严格、crypto-policy策略文件影响面更大，如果一开始不确认版本就去套老经验，很容易测错或漏测。

补丁信息也不能只看yum update的输出，那只是检查当前有没有可更新包。测评时我会采取更稳妥的组合：yum check-update --security检查是否有安全更新待装，同时看历史补丁记录，然后结合CVE漏洞扫描结果判定这台机器是否需要整改。如果客户现场不允许执行更新类命令，那至少把check-update的结果打出来，作为“可用更新未安装”的证据。

2.2 获取合适的执行权限和身份

等保测评命令里，有一部分只需要普通用户权限就能看，比如查看系统版本、查看服务状态；但更多关键核查需要root权限，比如查看/etc/shadow里账号锁定状态、加载审计规则、检查/etc/sudoers配置。现场执行时必须注意三个问题。

第一，必须提前跟客户确认执行范围。等保测评是安全性测试，不到万不得已不应该对生产系统做修改性操作。我的原则是命令只读优先，能跑cat就不跑echo，能查状态就不停服务。遇到必须验证权限配置的场景，比如测试sudo提权到底能不能用，需要在客户书面授权范围内进行操作。

第二，优先使用sudo而非直接su -切root。通过sudo执行的命令都会被secure日志记录，这本身就是安全审计的一部分，也方便最后给客户提交一份完整的操作记录。如果客户不给sudo权限，那就只能以普通用户身份读取所有可读文件，然后把缺失项列成清单，让客户提供root权限下的补测结果。

第三，执行命令时养成一个好习惯：每一条关键命令都附带执行时间。我在测评现场一般会临时定义一个PS4变量，让脚本执行时自动打印时间戳，或者命令前用date输出一下。别嫌麻烦，出报告时你就知道这些时间戳有多重要——不同时间点的审计日志对比、命令覆盖范围的证明，全都要靠它们。

2.3 明确测评对象边界

一台RHEL主机上可能跑着Web服务、数据库、业务应用、容器，等保测评的范围不一定是整台机器。我的习惯是先通过ps -ef和ss -tlnp梳理出这台机器上对外监听的服务和进程，然后跟客户确认哪些属于测评对象，哪些属于边界外。别小看这一步，如果边界不划清楚，后面测出来的结果客户不认账，说“这个端口不归我们管”，你所有整改项全废了。

ps -ef --sort=-%cpu | head -30 ss -tlnp systemctl list-units --type=service --state=running

这三个命令组合起来，进程、TCP监听端口、常驻服务基本一目了然。拿到清单后再和客户确认边界，比一上来就瞎测要专业得多，也让客户觉得你做事有章法。

3. 安全配置核查实战命令集合

这一节是文章的核心。我按照等保测评通用要求中的层次，把RHEL的核查命令拆成几组，每一组分别对应“身份鉴别”“访问控制”“安全审计”“入侵防范”“恶意代码防范”等控制点。每组命令后面附加判定逻辑和我在现场踩过的坑。

3.1 身份鉴别与口令策略核查

身份鉴别是等保测评里出问题最多的地方，没有之一。口令强度不够、长期不更换、允许root远程登录、无失败锁定机制，随便一条都是高风险项。核查这部分，我建议先把/etc/login.defs和/etc/pam.d/system-auth这两个核心文件读一遍。

grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN|PASS_WARN_AGE" /etc/login.defs grep -E "pam_pwquality|pam_faillock|password requisite" /etc/pam.d/system-auth /etc/pam.d/password-auth cat /etc/security/pwquality.conf | grep -v "^#" | grep -v "^$"

先说/etc/login.defs，里面的PASS_MAX_DAYS表示口令最长有效期，等保2.0通用要求通常建议不大于90天（具体看单位定级和测评指导书），PASS_MIN_LEN表示最小长度，但在RHEL 7及以后，PASS_MIN_LEN的实际生效会被pam_pwquality模块覆盖，所以光改login.defs是不够的，必须看pam_pwquality.so的配置。

pam_pwquality.so里的minlen、dcredit、ucredit、lcredit、ocredit参数才是真正决定口令复杂度是否生效的关键。比如minlen=8 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1的意思是：密码最短8位，且必须包含数字、大写字母、小写字母、特殊字符。这里的负号代表“必须有至少一个”，如果写成正数dcredit=1，含义就变成了“最多允许1个数字”，很多人在这里搞反，整改了也没用。

登录失败锁定核查是另一个高频问题。RHEL 7里通过pam_faillock.so模块实现，检查时用：

grep -E "auth.*pam_faillock" /etc/pam.d/system-auth grep -E "account.*pam_faillock" /etc/pam.d/password-auth

如果没有配置pam_faillock的preauth和authfail两段，那说明系统没有登录失败锁定功能，按照等保要求这属于不满足项。这里有个细节，很多运维以为配置了deny=3就能锁定，但pam_faillock是三段式配置，preauth阶段用于在认证前检查用户是否已被锁定，authfail阶段用于记录认证失败的计数，authsucc阶段用于认证成功后清零计数，漏掉任何一段逻辑都不完整，现场判定时要核对三段是否齐全。

再补一条：检查空口令账号。等保里明确不允许存在空口令账户，用一条命令扫出来最直接。

awk -F: '($2 == "") {print $1}' /etc/shadow

这条命令如果输出为空，说明没有空口令账号，如果输出某个用户名，那不用废话，直接开不符合项。

3.2 访问控制与用户权限核查

访问控制在RHEL测评里主要看三块：账号清理、sudo权限、文件权限。账号清理检查那些长期不用的、离职员工的、来历不明的账号，命令很简单：

awk -F: '$3>=1000 {print $1, $3, $6}' /etc/passwd last -n 20 lastlog | head -20

awk命令能快速列出UID≥1000的普通用户，last和lastlog能看出哪些账号有过登录记录、哪些账号从未登录。测评现场经常出现一个账号创建了两三年但从未登录过的情况，这种属于典型的“僵尸账号”，整改建议就是禁用或删除。注意，系统账号（UID<1000）原则上不能用来交互式登录，如果发现某个系统服务账号被配置了登录Shell，也要列为风险点。

sudo权限核查是重头戏。很多人喜欢直接用cat /etc/sudoers，但更规范的做法是用visudo -c检查语法，同时读/etc/sudoers.d/目录下的所有配置文件。配置sudo权限过宽是等保测评的高频不符合项，比如直接给了ALL=(ALL) ALL这种权限，或者某些业务账号被赋予了NOPASSWD权限，那就意味着该账号可以免密执行任意命令。

visudo -c grep -E "^[a-zA-Z0-9_%]+.*ALL=" /etc/sudoers /etc/sudoers.d/* 2>/dev/null grep -E "^[a-zA-Z0-9_%]+.*NOPASSWD" /etc/sudoers /etc/sudoers.d/* 2>/dev/null

说一下判定逻辑：如果普通用户被赋予ALL=(ALL) ALL，在等保2.0里通常判定为“越权访问”，不符合最小权限原则。如果必须保留，至少应该限定命令范围，比如只允许该用户管理某个特定服务。NOPASSWD在企业环境里要看场景，运行自动化脚本的专用账号可以接受，但交互式登录用户账号配NOPASSWD属于典型的不符合项。

文件权限检查这一块，我通常抽查/etc/shadow、/etc/passwd、/etc/ssh/sshd_config这些敏感文件的权限位。正常情况下shadow应该是000或者600，只有root可读写；passwd是644。用ls -l逐个看效率太低，直接组合：

ls -l /etc/shadow /etc/passwd /etc/group /etc/sudoers /etc/ssh/sshd_config find /etc -name "*.conf" -perm /022 -type f 2>/dev/null | head -30

find里-perm /022表示查所有“组或其他用户可写”的配置文件，如果列出来一堆，说明系统配置文件权限普遍过宽，这不仅是等保不符合项，也是安全风险。现场如果客户问“怎么改”，一般chmod到644或600就行，但要注意部分服务对配置文件权限有额外要求，比如sshd要求~/.ssh目录权限不能超过700，authorized_keys不能超过600，否则SSH直接拒绝使用该密钥。

3.3 安全审计与日志核查

安全审计是等保测评里涉及命令最多的部分。RHEL的审计体系以auditd为核心，配合rsyslog记录系统日志。核查顺序通常是：先看服务有没有启动，再看规则有没有加载，最后看日志有没有正常轮转。

systemctl status auditd auditctl -s auditctl -l cat /etc/audit/auditd.conf | grep -E "max_log_file|num_logs|space_left_action|admin_space_left_action"

auditctl -s输出的是内核审计状态，enabled为1表示开启。如果enabled是0，那说明系统根本没有启用审计，这是一个非常严重的不符合项。auditctl -l列出当前加载的规则，测评时最好设置几条关键规则，比如对/etc/passwd、/etc/shadow、/etc/sudoers、/etc/ssh/sshd_config的写操作都要记录，对/usr/bin/passwd、/usr/bin/su等高危命令的执行也要记录。如果规则太少甚至为空，就说明审计覆盖范围不足。

配置审计规则需要提醒一句：auditctl -l看到的只是当前内核里加载的规则，真正决定重启后是否生效的是/etc/audit/rules.d/下的.rules文件。测评时要两个地方都看，避免出现“规则只在内存里生效，一重启就丢”的尴尬情况。检查规则文件用：

cat /etc/audit/rules.d/audit.rules augenrules --load

augenrules --load这个命令会把rules.d目录下的规则文件合并后重新加载，它是RHEL平台上管理audit规则的规范化方式。很多老运维习惯直接改/etc/audit/audit.rules然后重启auditd服务，这在RHEL 7上已经不合适了，重启auditd有时会忽略规则文件的变化，反而用了augenrules生成的合并规则，新手很容易踩这个坑。

系统日志方面，重点是确认rsyslog在运行且日志没有异常丢失。RHEL 7上默认的日志文件包括/var/log/messages、/var/log/secure、/var/log/cron、/var/log/maillog、/var/log/boot.log。测评时关键看secure日志，因为所有登录行为、sudo授权、用户切换都会记录在这里。

systemctl status rsyslog grep -i "authentication failure" /var/log/secure* | tail -20 grep -i "failed password" /var/log/secure* | tail -20 grep -i "accepted" /var/log/secure* | tail -20

这几组命令可以快速判断这台机器有没有被暴力破解尝试的痕迹。如果Authentication failure出现频率非常高，同时本机又没有启用登录失败锁定，那这个风险项基本坐实了，整改措施必须包含开启pam_faillock，否则即使打补丁也挡不住撞库。日志轮转也要确认，看/etc/logrotate.conf和/etc/logrotate.d/下有没有为audit、secure等日志配置轮转策略，日志无限增长导致磁盘满的案例在测评现场经常见到，有时候会发现审计日志文件都好几GB了，轮转策略却从未配置过。

3.4 入侵防范与系统完整性核查

等保对入侵防范的要求包括最小化服务、开启SELinux、及时更新补丁、监测系统完整性等。RHEL上的核心命令是getenforce和sestatus。SELinux在RHEL里默认是启动的，但很多运维在装应用时遇到权限问题就随手setenforce 0关闭了，重启后虽然没有自动关闭，但系统处于宽容模式（Permissive），这个在测评里是不满足的。

getenforce sestatus grep "^SELINUX=" /etc/selinux/config

getenforce输出Enforcing才是强制模式，Permissive就是只记录不阻止，等于形同虚设。检查时一定要同时看/etc/selinux/config里的持久化配置，因为setenforce 0只对当前内核生效，如果配置文件里写的是SELINUX=disabled，重启后SELinux彻底不加载，问题更严重。

网络服务最小化是另一个关键项。测评时要把目前系统上监听的端口和对应的服务进程全列出来，确认每一个端口背后是不是合法的业务服务。

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

发现异常端口或者不必要的服务在运行，比如telnet服务、rlogin服务、vsftpd如果业务不需要却开着，都属于不满足项。RHEL 7上还有个典型问题是防火墙配置不生效或直接没启用：

systemctl status firewalld firewall-cmd --list-all iptables -L -n -v

注意RHEL 7默认用的是firewalld，底层虽然还是iptables，但直接操作iptables命令改规则很容易和firewalld管理混淆。测评时我会先确认firewalld是否启用，如果启用且配置合理，一般不纠结底层iptables。但有一种特殊情况：客户手动停了firewalld，又直接用了iptables命令启动规则，这种配置一重启就失效，测评报告中要明确指出不可持续。

系统完整性这块，RHEL自带的工具是rpm -Va，它能校验系统安装过的所有rpm包的文件属性和校验和。执行一次全盘校验耗时很长（十几分钟甚至更久），但测评时可以在生产容忍范围内抽检关键包，比如：

rpm -Va | head -50 rpm -V openssh-server binutils glibc

如果出现太多“S.5....T”这类输出，说明文件被修改过，需要排查是否为入侵痕迹还是管理员故意改动。如果安装了AIDE这种完整性检测工具，那就直接看它的日志和策略文件：

ls -l /var/lib/aide/aide.db.gz aide --check

AIDE的坑在于首次初始化之后必须有个基线库，之后每次--check都是拿当前文件和基线对比。如果管理员改了某个配置文件但没更新基线，--check就会疯狂报警，测评时要先跟客户确认哪些报警是正常变更，哪些是真的可疑修改，别一看到告警就当成入侵证据。

3.5 恶意代码防范与网络加固核查

等保要求服务器需要安装恶意代码防范软件，但RHEL服务器上装商业杀软的并不多，很多单位觉得服务器不用杀毒。测评现场如果确认未安装任何反病毒软件，按照等保通用要求可以直接判定不符合，但整改优先级需要结合系统用途来定。核查命令：

rpm -qa | grep -i clamav systemctl status clamd 2>/dev/null rpm -qa | grep -iE "kaspersky|symantec|McAfee|sophos"

如果装了ClamAV，确认病毒库更新任务是否配置了定时执行。crontab -l里应该有定期更新病毒库的条目，如果只有装好的软件却从不更新病毒库，等于形同虚设。

网络加固这边，重点看内核参数和SSH配置。等保里对防伪冒和资源限制有具体要求，/etc/sysctl.conf里的参数最常用的是net.ipv4.tcp_syncookies（启用SYN Cookie防SYN Flood）、net.ipv4.conf.all.accept_redirects和net.ipv4.conf.default.accept_redirects（禁ICMP重定向，防止路由欺骗）、net.ipv4.ip_forward（非路由场景必须为0）。

sysctl net.ipv4.tcp_syncookies sysctl net.ipv4.ip_forward sysctl net.ipv4.conf.all.accept_redirects sysctl net.ipv4.conf.all.rp_filter cat /etc/sysctl.conf | grep -v "^#" | grep -v "^$"

这里有个常见误区：sysctl命令查询的是当前生效的内核参数，但等保测评要看的是持久化配置。如果sysctl.conf没有对应项目，但当前tcp_syncookies是1，说明可能有人手动echo 1 > /proc/sys/net/ipv4/tcp_syncookies，重启就丢了。所以每次查完当前值我都要grep一下配置文件，两边对齐才算真的满足。

SSH是RHEL上最主要的远程管理入口，它的加固状态基本决定了服务器暴露面。核查/etc/ssh/sshd_config时重点关注这几个键：

grep -E "^PermitRootLogin|^PermitEmptyPasswords|^MaxAuthTries|^Protocol|^PasswordAuthentication|^AllowUsers" /etc/ssh/sshd_config

PermitRootLogin no是禁止root直接远程登录，但如果服务器全部管理员都只用一个普通账号再sudo，那这条必须满足。MaxAuthTries等保建议不要超过5，我现场看到默认值“6”的情况非常多，虽然默认值不算特别离谱，但很多测评指导书里要求不超过5，那就得整改。有一个细节容易忽略：sshd_config里的配置项在文件里可能被注释掉，注释状态下用的是编译默认值。比如PasswordAuthentication默认是yes，如果文件里#PasswordAuthentication yes，那实际效果就是允许密码登录。测评时只看带^的行还不够，还要评估注释行对默认值的影响，必要时用sshd -T查看最终生效配置。

sshd -T | grep -E "permitrootlogin|permitemptypasswords|maxauthtries|passwordauthentication"

sshd -T直接输出加载了所有默认值之后的实际生效配置，比看文本文件更加可靠。这条命令是我在RHEL测评里的压轴技巧，也适合所有做基线核查的工程师。

时间同步虽然在等保里属于管理类控制项的一部分，但技术核查时也会看系统时间和时间同步服务。RHEL 7之前是ntpd，RHEL 7起chrony成为默认时间同步服务：

timedatectl chronyc sources systemctl status chronyd

时间同步出问题的系统会导致日志时间轴错乱，审计追踪无从谈起，所以这项属于“看似低危、实则牵一发动全身”的项目。如果发现chronyd没在运行，而系统时间偏移很大，报告里必须列为整改项。

4. 测评现场常见问题与排查技巧实录

4.1 只看到注释行没看到真实配置

我在上面提到过，光靠grep读sshd_config容易误判。真实案例：某台RHEL 7机器，/etc/ssh/sshd_config里写的是#PasswordAuthentication yes，看起来只是注释，但实际生效就是允许密码登录。如果测评员只报告“未见显式配置”，等于漏了一个本来可以检查的项。正确做法就是sshd -T，把服务器自己的解释器输出当作最终结论。这条经验适用于所有“配置文件+默认值”混合生效的场景。

4.2 auditd规则“重启即丢”

有一次测评客户的生产数据库服务器，auditctl -l能看到十几条规则，看起来挺完善。但我顺手打开/etc/audit/rules.d/audit.rules，里面只有寥寥两条。追问下来发现规则是多年前某位工程师手动auditctl -a临时加进内核的，一直没写进规则文件。一旦服务器重启，那些临时规则就全没了。测评判定不能只看运行时状态，一定要看持久化规则文件，两条对不上就得单独列风险。

4.3 密码复杂度参数被覆盖

现场经常遇到这种情况：/etc/login.defs里PASS_MIN_LEN配了12，/etc/security/pwquality.conf里也写得挺完整，但测试改密码时还是能设置简单密码。检查发现是/etc/pam.d/system-auth里的pam_pwquality.so根本没启用，或者被其他pam模块覆盖了。正确的排查路径是把整个认证链读一遍，别只看单点配置。RHEL 7的password-auth和system-auth两个文件是分开的，一个管密码登录，一个管本地登录，两边都要检查，只改一边等于白改。

4.4 版本差异导致的命令失效

RHEL 8上继续用iptables -L会提示用nft取代，RHEL 6上运行systemctl会直接报命令不存在。如果是测评一艘混合版本的大船，我的建议是每个版本建立一张命令对照表，RHEL 6用service/chkconfig，RHEL 7用systemctl，RHEL 8则要习惯nmcli、nftables、dnf这些新工具。等保测评对工具链的熟练度要求高，其实就是对版本差异的熟悉度要求高。另一个容易踩的差异点是：RHEL 8默认SSH版本是OpenSSH 8.0，不再支持ssh-dss算法，如果核查时发现客户配置里还留着这类弱算法，那是建议尽快移除的。

4.5 命令权限不足导致误判

普通用户能看/etc/passwd，看不到/etc/shadow，所以上面检查空口令账号的脚本必须root权限才能执行。测评时如果客户只给了普通账号，awk、ls -l /etc/shadow这些命令都会报权限错误，这时候不要强行判定为“不可读”或“符合”，而是要在测试记录里明确标注“该检查项需root权限执行，结果待补测”。这也是测评报告常见的问题之一：因为权限不够，把该测的项写成“不适用”，结果被客户质疑。

4.6 防火墙和业务冲突的排查

RHEL上启用了firewalld但业务端口没放行，业务会直接异常。测评时如果发现防火墙策略过严，要区分是“故意收紧”还是“配置错误导致生产故障”。有一个实用案例：客户说数据库连不上，让我看看是不是等保测评把防火墙改坏了。实际上现场没有任何人改过防火墙，firewall-cmd --list-all显示根本没有放行3306端口，说明这是历史遗留问题。此类排查的关键在于查看修改时间和配置变更记录，判断是近期改动还是存量问题。stat命令能看文件的最后修改时间，配合排查能还原时间线。

排查技巧这块还有一个小建议：测评命令不要一条条人肉执行，最好写成一个带注释的脚本集合，每条命令后面留一行输出说明。这样既保证每个检查项覆盖到位，又能把命令输出保留为测评证据。脚本放在本机跑完后把输出重定向到文件，防止终端缓冲区把部分结果冲掉。

5. 文件系统与存储核查补充

在等保测评里，文件系统和存储这块经常被新手忽略，但实际上RHEL环境下因为存储配置不合理导致的安全问题并不少。比如/tmp分区独立性问题、磁盘满导致的审计中断、LVM配置混乱等。这里展开说几个必须看的点。

5.1 关键目录独立分区检查

等保建议/tmp、/var、/home等易受攻击的目录使用独立分区，避免恶意文件塞满整个磁盘拖垮系统。检查命令是df -hT，看根目录与/tmp、/var、/home是否在同一分区。如果同一个/dev/mapper/xx-root下面挂了一堆目录，说明没有分区隔离，风险主要在于日志或临时文件的无限制增长会直接影响根文件系统空间。

df -hT mount | grep -E "/tmp|/var|/home"

如果/tmp没有挂独立分区，而且systemd下的tmp.mount服务又没有启用，那/tmp是普通目录，现有文件直接落在根分区。一个针对性的整改方案是可以启用systemd-tmpfiles清理临时文件，或在fstab里单独划分tmpfs挂载，但这些属于整改措施，测评现场只记录现状。

5.2 磁盘空间与审计可用性

审计日志写入失败时auditd的应对策略是space_left_action和admin_space_left_action，如果磁盘空间被打满，审计模块可能直接挂起。所以核查磁盘剩余空间和auditd.conf里的告警阈值是配套动作。我是这样检查的：

df -h df -i grep -E "^space_left_action|^admin_space_left_action|^max_log_file" /etc/audit/auditd.conf

df -i看的是inode使用率，很多人只关注磁盘空间，忽略了inode耗尽的隐患。日志文件非常多但每个都很小，就会导致inode先用完，现象就是磁盘还剩几个GB但无法创建新文件。这类问题在等保测评里定性为“日志存储空间不足导致审计数据无法持续保存”，属于中风险项。

5.3 挂载选项的安全性

RHEL默认挂载选项不一定都满足等保要求，比如/tmp如果挂载时启用了exec，那么恶意代码就有机会从/tmp直接执行。核查挂载选项用：

mount -l | grep -E "/tmp|/var|/home" findmnt -o TARGET,OPTIONS

等保测评里面比较常见的建议是/tmp挂载时带上nosuid,nodev,noexec等选项，但这里有个实际矛盾：不少业务安装包需要临时文件可执行，一旦直接加noexec业务就挂了。遇到这种情况测评员要在报告里写明现状和业务冲突，建议客户合理评估后做针对性加固，不能机械地要求整改。另外/home推荐nosuid,nodev，/var一般不用加noexec，因为很多程序会往/var写临时执行文件。现场核查要结合业务情况给建议，这才有说服力。

6. 测评结果整理与报告输出要点

命令跑完了，一大堆输出摆在面前，怎么把结果准确地落到报告里，是另一层功力。等保测评命令执行完毕后的结果整理，其实有标准动作。

第一，证据保留。每条重要命令输出必须保存到文件，文件名建议带上执行时间和检查项目，比如audit_rules_20250326.log、ssh_config_20250326.log。测评结束给客户提交的证据包里，命令原文、输出结果、执行时间、执行人信息缺一不可。最怕的是报告里写了“已核查”，但拿不出核查当时的原始输出，被复审时一问三不知。

第二，结果分类。按我个人的习惯，每一项检查结果分三类：“符合”“不符合”“部分符合/建议整改”。不要模糊。比如口令策略里PASS_MAX_DAYS配了90天，但pam_pwquality的复杂度校验没有开启，那这整个控制点判定为“部分符合”，在整改建议里写清楚具体哪一项达标、哪一项缺失。

第三，整改优先级。数据库服务器密码策略不对，和OA服务器密码策略不对，风险等级不一样。报告输出时要把高危项放前面，中危次之，低危最后。等级保护的对象还有定级区别，二级系统和三级系统的测评要求不一样，三级系统要求所有控制项全覆盖，二级系统可以适当简化，命令核查范围也跟着变。

第四，与客户确认。命令说到底只是工具，重要是把结论和客户对齐。输出报告之前我会拉着客户的运维负责人，把一个一个不符合项过一遍，哪些是他们已经知道但没时间改的，哪些是完全不知道的，哪些是误判需要重新核实的。这一步做好了，后续整改推进会顺畅很多。曾经遇到过客户说“我们密码三个月一改的，你们怎么测出来密码策略不对”，最后查下来是/etc/pam.d/password-auth没同步配置，本地改密码生效，SSH登录改密码不生效，客户自己没注意到这个差异。命令输出就是最好的沟通凭证。

这里再顺带说一个报告词汇规范的问题。等保测评报告里的单位名称、资产编号、测评范围、测评结论都有格式要求，命令输出作为依据材料放在附录即可。不要为了凑篇幅把大段命令行输出直接贴在正文，报告的可读性会被破坏，专家评审时也会觉得不专业。直接把命令输出的关键行引到正文表格里，完整输出放附录，这种格式是最稳妥的。

7. 写在最后的几点建议

做等保测评接触Red Hat Enterprise Linux多了，慢慢会发现命令本身只是载体，真正考验功力的是三件事：懂标准、懂系统、懂业务。懂标准是知道等保2.0里每一项要求对应到系统里到底测什么；懂系统是知道RHEL里每个配置文件、每个模块、每个服务状态的机制原理；懂业务是知道哪些安全措施在特定业务场景下会与稳定性冲突，需要做取舍而不是一刀切。

我给新入行朋友的建议是，把常用命令整理成自己的速查表，不用背，但要用熟。每个命令至少要知道两件事：它输出的每一项代表什么，以及这个结果怎么跟等保条款对应。比如getenforce输出Enforcing你知道符合，但输出Permissive的时候，对应的整改建议应该怎么给，文件要改哪里，改完要不要重启，这才是真正拉开差距的地方。

另外强烈建议在测试环境搭一套RHEL虚拟机练手。不用多高的配置，两台虚拟机就够：一台RHEL 7，一台RHEL 8或9，分别把等保相关的配置项改好，然后跑一遍上面提到的命令，看看输出长什么样，再故意把配置改错，看看命令输出怎么变化。这种对比训练比只看文档有效得多。我每次带新人也是这个思路，能在环境里自己跑出结论的，比背一百条命令都强。

最后再分享一个小技巧：执行整个核查清单的时候，先跑一遍快速侦察命令（版本、服务列表、端口、时间同步），再根据结果决定深挖方向。如果版本很老、服务很杂、时间不同步，那多半是一台长期缺乏运维的机器，测评重点就放到补丁、口令、审计、恶意代码这些基础项上；如果版本新、服务干净、加固痕迹明显，那重点核查方向就变成权限的精细化、内核参数、审计规则完整性这些进阶项。带着假设去跑命令，比你从头到尾机械执行一套固定命令要高效得多，也是我这些年测评下来觉得最实用的方法论。