做等保测评这几年我手里用得最多的系统就是Red Hat Enterprise Linux。不管是二级还是三级系统Linux服务器的测评项都集中在身份鉴别、访问控制、安全审计这几大块而命令行是测评师最趁手的工具。这篇文章我把在RHEL 7.x含7.4上常用的等保测评命令挨个过一遍包括命令怎么敲、输出怎么判读、常见坑在哪里。适合正在准备测评的数据中心运维、刚入行的测评工程师以及被要求整改的企业管理员参考。1. 测评前的底数获取系统版本与基础状态检查测评第一步必须先确认被测系统的归属信息。这一步不单是为了写报告更是为了后面的检查项做准备——比如RHEL 6和RHEL 7的PAM配置路径不同判断口令策略时敲的命令就不一样。1.1 系统发行版与内核信息采集先看发行版本cat /etc/redhat-release uname -a hostnamectl输出示例Red Hat Enterprise Linux Server release 7.4 (Maipo) Linux rhel-server 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linuxhostnamectl 展示的 Static hostname、Operating System、Kernel、Architecture这四个字段在报告的“主机信息”表里基本都能用上。注意 uname -a 显示的是 3.10.0-693.el7说明是 RHEL 7.4 的内核如果看到 3.10.0-957.el7那就是 7.6 之后的内核了。1.2 补丁等级与安全更新状态查看当前系统安装包的更新时间rpm -qa --last | head -20看最近一次 yum update 是什么时候。测评时通常要求系统“及时更新安全补丁”没有统一的天数标准但行业普遍参考最近90天内是否有更新记录。接着看是否有待更新的包yum check-update --security这个命令会把所有标记为安全更新的包列出来。如果输出为空或只提示“没有需要更新的软件包”说明系统补丁更新状态基本合格如果列出一大堆整改建议就是打补丁。这里要说明一个原则不要在测评现场直接跑 yum update尤其是生产服务器。我见过有新手测评师手痒去执行更新结果包管理器锁住、业务直接受影响。测评的原则是“只读优先”能用查看命令就不要动系统状态。yum check-update 本身是只读的安全可以放心用。1.3 运行时长与关键进程概况再看系统运行时长和资源占用判断是不是一台活跃的生产服务器uptime ps aux --sort-%cpu | head -15超过一年的 uptime 在等保测评报告里其实是常见情况这并不代表系统“不安全”但是配合补丁检查结果看一个跑了一年没重启、又没有安全更新的系统整改优先级就应该调高。2. 身份鉴别类测评命令口令策略、账户锁定与会话控制身份鉴别是等保三级系统里权重最高的控制点之一。测评项包括登录口令复杂度、口令生存周期、登录失败处理、远程登录限制。这两节是命令最密集的部分也是最容易出整改项的部分。2.1 口令复杂度与有效期核查RHEL 7 的口令策略由 /etc/login.defs 和 PAM 配置共同决定。先看有效期相关的四项cat /etc/login.defs | grep -E ^PASS_MAX_DAYS|^PASS_MIN_DAYS|^PASS_WARN_AGE测评合格参考值PASS_MAX_DAYS ≤ 90PASS_MIN_DAYS ≥ 7可选PASS_WARN_AGE ≥ 7这些参数只对新建用户生效。已经存在的用户系统只认 /etc/shadow 里保存的密码期限值。测评时不能只读 login.defs 就下结论必须把 shadow 里每个账户的密码修改日期和过期天数都摸清楚awk -F: {print $1, $3, $4, $5} /etc/shadowshadow 四个字段分别是用户名、最后一次修改密码距1970-01-01的天数、两次修改最小间隔天数、密码过期天数。把第3列最后修改时间加第5列过期天数换算成日期就能算出这个账户的密码什么时候到期。密码复杂度跑 PAM 配置grep -E pam_pwquality|pam_pwhistory /etc/pam.d/system-auth cat /etc/security/pwquality.confRHEL 7.4 之后密码复杂度参数集中在 pwquality.conf 里。常见的合格配置minlen 8 dcredit -1 ucredit -1 lcredit -1 ocredit -1分别表示最小长度8、至少包含数字1位、大写字母1位、小写字母1位、特殊字符1位。注意 pwquality.conf 里很多行是注释掉的注释掉的参数不生效如果 dcredit -1 这类配置前面有 # 号说明系统根本没开启这个复杂度要求。还有一个容易漏的点RHEL 7 会同时读取 /etc/pam.d/system-auth 和 /etc/pam.d/password-auth。有些管理员只改了 system-auth走 password-auth 的服务依然在用弱口令策略。测评时两个文件必须都看一眼。2.2 登录失败处理与账户锁定等保要求“应具有登录失败处理功能结束会话、限制登录次数”。RHEL 7.4 系统的标准方案是 pam_faillock也有存量服务器还在用 pam_tally2。先看当前生效的锁定策略grep -E pam_faillock|pam_tally2 /etc/pam.d/system-auth /etc/pam.d/password-auth正常的 faillock 配置会出现在三个位置auth 段auth required pam_faillock.so preauth失败计数auth 段且靠后auth required pam_faillock.so authfail认证失败处理account 段account required pam_faillock.so锁定检查典型合格配置如下auth required pam_faillock.so preauth silent audit deny5 unlock_time900 auth sufficient pam_unix.so nullok try_first_pass auth required pam_faillock.so authfail audit deny5 unlock_time900 account required pam_faillock.sodeny5 表示连续失败5次锁定unlock_time900 表示锁定15分钟。要是只看到 pam_unix 而没有 faillock那账户锁定这项基本就是不合格需要整改。查看当前账户锁定情况faillock --user rootfaillock 在 RHEL 7.4 默认安装如果系统报 command not found就用 pam_tally2pam_tally2 --user root注意faillock 输出里 When、Type、Source、Valid 才是关键。如果 Valid 显示最近的失败记录说明该账户近期有被暴力尝试过的痕迹。想清理测试过程留下的锁定记录时faillock --user root --reset这条命令测评期间谨慎使用只有整改后复测时才用而且要在明确授权下操作否则会把真实攻击痕迹抹掉。2.3 登录会话超时与登录提示身份鉴别里还有一项是“应具有登录失败处理功能结束会话”延伸出来就是对空闲会话的限制。RHEL 7 的超时靠 TMOUT 环境变量控制cat /etc/profile | grep -i tmout合格配置是 TMOUT600也就是10分钟空闲自动注销。注意 /etc/profile 里默认没有这一行如果 grep 不到输出就应该去检查 /etc/bashrc、/home 下的 ~/.bash_profile。SSH 会话层面的控制也不能漏grep -E ^ClientAliveInterval|^ClientAliveCountMax /etc/ssh/sshd_config推荐配置是 ClientAliveInterval 600、ClientAliveCountMax 3意思是每10分钟发一次探活包连续3次无响应就断开。这两个参数在测评时经常被忽略但正好能匹配“会话超时退出”的要求。2.4 远程管理的加密与Root限制身份鉴别类还有远程管理这块。等保要求“采用口令、密码技术、生物技术等两种或两种以上组合”以及对登录用户进行身份标识。SSH 配置里要重点检查grep -E ^Protocol|^PermitRootLogin|^MaxAuthTries|^PermitEmptyPasswords /etc/ssh/sshd_config推荐值Protocol 2、PermitRootLogin no 或 prohibit-password、MaxAuthTries ≤ 5、PermitEmptyPasswords no。RHEL 7.4 支持主机密钥的 ed25519 算法所以 sshd_config 里 HostKey 一般包含 /etc/ssh/ssh_host_ed25519_key这个不用改。但如果看到 PermitRootLogin yes整改项就来了——一般建议改成 no 或 prohibit-password允许密钥登录、禁止口令登录生产环境里 root 直登风险太高光这一条就能让整改报告多一页。3. 访问控制与系统权限核查命令访问控制这块测评的核心是系统里有没有越权账号、是否授权了不合理的 sudo 权限、文件权限是否放得太松。命令都比较简单但是输出解读的坑不少。3.1 用户账户与特权账号检查把所有UID为0的账户列出来awk -F: ($30){print $1} /etc/passwd正常情况下输出只有 root 一行。如果混入了其他账户基本可以判断是管理员手工加的特权账号或者后门账号需要重点核实。测评场景下看到 uid0 的非 root 账户报告上直接写高风险整改这个几乎不用商量。顺便看下 /etc/passwd 里有没有不该存在的登录 shellawk -F: $7!/sbin/nologin $7!/bin/false {print $1, $7} /etc/passwd这条会把所有能通过 shell 登录的账户列出来。测评时重点看有没有 games、shutdown 这类历史遗留账户被赋予了 /bin/bash。正常服务器上非运维账户应该一律 /sbin/nologin。3.2 sudo 授权与 su 管控核查sudo 权限的检查cat /etc/sudoers ls -l /etc/sudoers.d/ cat /etc/sudoers.d/*sudoers 里重点关注两行root ALL(ALL) ALL %wheel ALL(ALL) ALL如果发现普通账号被写成了 ALL(ALL) NOPASSWD: ALL这就等于把 root 权限平白送人了等保测评中属于明显的高风险点。特别注意 sudoers.d 目录很多管理员会把应用账号临时授权写在这里测评时只翻 /etc/sudoers 主文件会漏掉一大半授权信息。su 命令本身的权限也要确认ls -l /bin/su/bin/su 的所属组应该是 root权限是 -rwsr-xr-x设置了SUID位。如果 su 被降权或者被替换成非SUID会导致普通用户无法切换root但这不是等保的检查点反而是功能性问题。这里真正要检查的是有没有非授权用户被加入 root/wheel 组getent group wheel getent group rootwheel 组里的成员默认都有 su 到 root 的权限多一个不认识的用户都是越权风险。3.3 文件权限与 umask 核查等保访问控制里有“重要文件的访问权限”要求。最直观的一条ls -l /etc/passwd /etc/shadow /etc/group合格权限是 passwd 644、shadow 000 或 400、group 644。看到 /etc/shadow 权限是 644 甚至 777 时这项直接不合格——任何用户都能读出密码哈希暴力破解只是时间问题。umask 代表新建文件默认权限的掩码umask grep -E ^umask /etc/profile /etc/bashrc /etc/login.defs合格值一般是 077 或 022。022 是默认值新建文件是 644、目录是 755这个在多数企业里可以接受内网敏感服务器建议用 077新建文件只有属主可读写能防“临时文件被围观”。找全局可写文件和没有属主的文件find / -type f -perm -0002 2/dev/null find / -nouser -o -nogroup 2/dev/null全局可写文件意味着任何人都能改内容配置文件一旦被篡改后果可大可小。/tmp、/var/tmp 这类临时目录自身权限是 1777粘滞位目录本身在被检查范围内里面的普通文件不应该全局可写。find 输出里出现 /tmp 下的临时文件可以忽略但如果 /etc、/usr 下面出现全局可写文件那是实打实的整改项。3.4 SUID/SGID 程序审计查找带 SUID/SGID 位的程序find / -type f -perm /4000 -o -type f -perm /2000 2/dev/null常见的合法 SUID 文件是 passwd、su、sudo、mount、ping 等。如果发现 /usr/bin/vim、/usr/bin/find、tar 这类普通工具被加了 SUID 位多半是管理员图方便留下的应该立即降权。等保测评里“能够更改系统配置的命令”被普通用户以高权限执行属于访问控制缺陷整改建议就是去掉 SUID 位chmod u-s /usr/bin/vim测评阶段只记录、不改动即使要整改也必须在变更窗口内操作。4. 安全审计与日志核查命令安全审计是等保三级里分量最重的技术控制点之一。审计服务有没有开、规则全不全、日志能不能留存直接决定这一整块测评是 pass 还是 fail。4.1 auditd 审计服务状态与规则先看服务状态systemctl status auditd auditctl -s要求 auditd 处于 running 状态。如果显示 inactive 或者 failed整改建议第一行就是“启用并配置 Linux 审计服务”。看审计规则是否覆盖关键事件auditctl -l cat /etc/audit/audit.rules等保测评审计规则通常要求覆盖时间修改adjtimex、settimeofday、clock_settime身份鉴别事件login、logout文件权限变更chmod、chown、setfacl关键设备文件变更内核模块加载insmod、modprobe对应的 audit.rules 里应该能看到类似规则-w /etc/security/opasswd -p wa -k identity -w /etc/sudoers -p wa -k actions -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -a always,exit -F archb64 -S chmod -F auid1000 -k perm_chng如果 auditctl -l 输出为空表示审计规则没配置。这项和审计服务未部署一样都是高危整改。查看审计日志里有没有被审查的记录ausearch --start today -ts recent ausearch -k identity --start todayausearch -k identity 更适合测评它把所有打上 identity 标签的事件列出来能直接佐证“审计日志留有记录”这个检查项。在评审现场输出几条带 auid 的审计记录放在报告截图里比空口说有审计更有说服力。4.2 rsyslog 日志服务与远端备份日志服务状态systemctl status rsyslog cat /etc/rsyslog.conf | grep -E ^authpriv|^cron|^kern|^mail等保要求日志内容至少覆盖“用户鉴别、访问控制、系统运行等”并且“日志记录至少保存六个月”。前者看 rsyslog 有没有在记录 secureauthpriv、cron、messages 几类日志authpriv.* /var/log/secure cron.* /var/log/cron *.info /var/log/messages后者看有没有把日志转发到远端日志服务器grep -E |send /etc/rsyslog.conf /etc/rsyslog.d/*.conf发现类似.10.0.0.5:514 的行说明日志已经在向远程服务器汇聚这项可以判满足什么都没有的话整改建议会要求搭建日志集中存储。4.3 登录日志与异常行为回溯人工抽查登录记录last -n 20 lastb -n 10 grep Failed password /var/log/secure | tail -20last 看正常登录成功的历史lastb 看失败登录也就是暴力破解痕迹secure 日志里的 Failed password 行包含来源IP和尝试次数如果 lastb 输出比 last 还长几页说明这台机器正在被口令爆破。测评时这类证据要截图保留并且在结果里记录“存在多次登录失败记录建议排查入侵迹象”。另外还可以看特定用户的登录时间last root | head如果想看某用户最近 su 切换记录grep session opened for user root /var/log/secure | tail日志类测评命令的现场易错点在于有些日志文件被 logrotate 压缩过了比如 secure-20250401.gz。测评时先 ls -l /var/log/secure* 确认日志文件列表再决定看哪个文件。grep 压缩包前用 zcatzcat /var/log/secure-*.gz | grep Failed password | tail4.4 命令历史与操作留痕等保安全审计里有“应对审计过程进行保护防止未授权中断”。测评经常通过 shell history 倒查管理员登录后做了什么。查看命令历史history echo $HISTSIZE grep -E ^HISTSIZE|^HISTTIMEFORMAT /etc/profile合格配置是 HISTSIZE 合理比如1000以上最好还有 HISTTIMEFORMAT 加上时间戳。很多生产服务器 history 是空白的因为管理员用了不写历史的登录方式这在审计追溯里是硬伤。整改建议是开启命令时间戳记录echo export HISTTIMEFORMAT%F %T /etc/profile测评阶段需要克制不要随手在别人的服务器上写入这种配置只记录现状就行。5. 入侵防范与网络访问控制命令等保提的入侵防范在 Linux 层面的落地主要是 SELinux、防火墙、开放端口、补丁、异常进程。这部分的测评命令和日常排障比较接近但判定标准不太一样。5.1 SELinux 开启状态核查SELinux 状态必须用三个命令交叉确认getenforce sestatus cat /etc/selinux/configgetenforce 显示 Enforcing 是合格Permissive 说明强制模式被关闭Disabled 是永久关闭需要改配置文件重启才能恢复。单看配置文件里的 SELINUXenforcing 不能下结论必须结合当前生效状态因为管理员可能在运行时执行了 setenforce 0。测评时若遇到 Permissive 状态判断为“SELinux未全面启用”整改项是临时恢复 Enforcing 并修改配置文件永久生效。如果生产应用确实依赖关闭 SELinux整改路径一般是改用容器或者通过 audit2why、audit2allow 写自定义策略而不是一关到底。5.2 防火墙策略与开放端口审查防火墙实际生效状态systemctl status firewalld firewall-cmd --state firewall-cmd --list-allfirewalld 的 list-all 能看到当前 zone 里放行的服务和端口。理想的测评结果是有明确的放行策略且没有放行危险端口。如果系统用的是 nftables 或纯 iptablesiptables -L -n --line-numbers systemctl status iptables重点看 INPUT 链默认策略是否为 DROP 或 REJECT以及放行的端口是否和业务清单一致。默认 ACCEPT 且没有任何规则的系统防火墙这项基本不合格。再看实际监听端口ss -tlnp ss -unlpRHEL 7 里 netstat 依赖 net-tools可能没装直接用 ss 更保险。ss -tlnp 输出里会出现监听地址、端口和进程名。测评时把端口列表和“端口-服务-业务负责人”对照表比对凡是列表上找不到归属的端口都属于“开放不必要的端口”整改关闭。特别要关注 23telnet、512-515r-services、873rsync、3306MySQL 直连端口这类端口出现在不该出现的服务器上都是问题。5.3 异常进程与开机自启动项排查入侵防范要求“应能检测到对重点账户的冒用和暴力攻击”常见做法是人工抽查异常进程和计划任务。看进程ps aux --sort-%cpu | head -25 ps aux --sort-%mem | head -25临时目录下出现名为 kworker、sshd 的进程、或者进程路径在 /tmp 下几乎可以直接判断是挖矿木马。RHEL 上用 top 看会更直观但测评要留文本证据ps 的输出更适合剪贴到记录里。计划任务排查crontab -l -u root ls -l /var/spool/cron/ cat /var/spool/cron/* systemctl list-unit-files --stateenabled/var/spool/cron 下每个文件代表一个用户的 crontab。木马喜欢藏在 /var/spool/cron/ 里写一个更新任务payload 下在 /tmp过一会儿再执行。看到指向 /tmp 或 base64 字符串的下载任务基本就是中了招这时测评现场要把样本路径和时间记录清楚。开机自启动项systemctl list-unit-files --stateenabled | awk {print $1}确认没有多余的服务在开机时拉起。特别是 rc-local、inetd 这类古老的启动通道。RHEL 7 里默认没有 inetd如果有说明是额外安装的 xinetd 服务需要重点审查。5.4 内核网络加固参数抽查等保测评里网络安全的防护项涉及防 SYN 攻击、禁止 IP 转发、关闭 ICMP 重定向。用 sysctl 统一查看sysctl net.ipv4.ip_forward net.ipv4.conf.all.accept_redirects net.ipv4.conf.default.accept_redirects net.ipv4.tcp_syncookies合格参考值net.ipv4.ip_forward 0不做路由转发accept_redirects 0tcp_syncookies 1ip_forward 如果为 1 并且这台机器不是路由器就是配置错误。tcp_syncookies 为 1 说明基本防 SYN Flood。改成持久化需要写 /etc/sysctl.conf测评阶段只读不写。某些云环境默认会开 ip_forward如果对方确实是云主机且不承担路由功能这项可以在报告中说明然后按系统定位给整改建议。6. 常见问题与测评命令速查实操中遇到的坑比命令本身多得多我挑几个高频的录在这里。6.1 “改了一处PAM另一处没改”的经典翻车RHEL 7.x 的账户锁定和密码策略同时受 system-auth 和 password-auth 两个文件影响。很多管理员只在 system-auth 里加了 faillockSSH 登录会被锁定但本地控制台登录、FTP 登录走的是 password-auth等于没设防。测评时两个文件必须分别验证而且最好用多种登录方式实测一次触发锁定实测比 grep 配置文件可靠得多。6.2 密码到期时间“看着像合格其实不合格”shadow 文件里密码过期天数算出来可能是“还有180天才到期”但等保要求90天内必须改。这种不算“密码期限超长”实际风险是策略没有覆盖全部账户。测评命令chage -l username能输出该账户的密码最后修改日期、有效期、失效期。但 chage 一次只能看一个用户批量看还是用 awk 处理 /etc/shadow。有些账户用的是“永不过期”策略即过期天数为99999这类账户要逐一标注整改为修改密码并设置90天期限。6.3 auditd 规则不加载的现场疑案有审计服务不代表有审计规则。经常遇到 auditd 状态 running但 auditctl -l 输出为空重启后规则丢失。原因是规则写在 /etc/audit/rules.d/ 里的少了关键配置或者一个服务进程使用 auditctl 在运行时加载但没落盘。测评后核验时先看 /etc/audit/rules.d/RHEL 7 默认规则文件是 audit.rules 和 augenrules 生成的 /etc/audit/audit.rules。如果只有默认规则基本等于没有业务相关规则整改时要手工编写业务关键路径的审计规则集。6.4 测评命令速查表把常用命令整理成表格方便现场粘贴检查点命令合格参考系统版本cat /etc/redhat-releaseRHEL 7.x密码有效期cat /etc/login.defsPASS_MAX_DAYS ≤ 90密码复杂度grep pam_pwquality /etc/pam.d/system-auth8位且含四类字符账户锁定grep faillock /etc/pam.d/*deny5, unlock_time900会话超时grep TMOUT /etc/profileTMOUT600SSH Root限制grep PermitRootLogin /etc/ssh/sshd_configno 或 prohibit-passwordUID0账户awk -F: ($30) /etc/passwd仅 root全局可写find / -type f -perm -0002无审计服务auditctl -srunning审计规则auditctl -l有关键路径规则日志服务systemctl status rsyslogactiveSELinuxgetenforceEnforcing防火墙firewall-cmd --staterunning 且有放行策略开放端口ss -tlnp与业务清单一致补丁更新yum check-update --security无安全更新或记录可查这张表不是测评报告本身是现场核对用的工作底稿。做完一轮后把每个点的输出结果、判定结论、截图时间整理进底稿复测和整改时都能节省大量时间。6.5 现场操作注意事项经验之谈三条。第一只读命令和写命令要分开。测评现场只跑读取类命令任何写操作清日志、改配置、安装软件包都要在客户变更窗口内进行并且提前确认授权。哪怕只是 faillock --reset 这种看似无害的操作也可能把攻击者留下的证据清掉。第二输出要留档。RHEL 的终端输出直接复制到文本里就能作为证据但注意带上时间戳和主机名防止审计追溯时说不清是哪台机器。好习惯是每条命令后面手动记一行采集时间。第三评估报告里不要照抄命令输出当整改建议。整改建议要让客户看得懂比如“调整 /etc/ssh/sshd_config 中 PermitRootLogin 为 no重启 sshd 服务”而不是把输出表格贴回去。命令是工具整改才是目的。这套命令我在多个等保测评项目里反复用最直观的体会是Linux 测评考的不是“会不会敲命令”而是“命令输出背后代表什么风险”。同样一条 auditctl -l新手看到的是列表内容老手看到的是审计规则有没有覆盖用户登录、权限变更、文件访问这些关键行为以及日志能否支撑事后溯源。测评不是例行公事现场发现问题、给出可执行修复路径报告才有价值。最后分享一个小技巧测评前拿一台闲置的 RHEL 7.4 虚拟机先把这些命令完整跑一遍输出全部存档。到了客户现场心里就有底哪些输出是正常基线、哪些是异常状态一眼能分辨。测评这种工作准备工作做到位现场才不会慌。
RHEL 7等保测评常用命令详解：身份鉴别、访问控制与审计核查
做等保测评这几年我手里用得最多的系统就是Red Hat Enterprise Linux。不管是二级还是三级系统Linux服务器的测评项都集中在身份鉴别、访问控制、安全审计这几大块而命令行是测评师最趁手的工具。这篇文章我把在RHEL 7.x含7.4上常用的等保测评命令挨个过一遍包括命令怎么敲、输出怎么判读、常见坑在哪里。适合正在准备测评的数据中心运维、刚入行的测评工程师以及被要求整改的企业管理员参考。1. 测评前的底数获取系统版本与基础状态检查测评第一步必须先确认被测系统的归属信息。这一步不单是为了写报告更是为了后面的检查项做准备——比如RHEL 6和RHEL 7的PAM配置路径不同判断口令策略时敲的命令就不一样。1.1 系统发行版与内核信息采集先看发行版本cat /etc/redhat-release uname -a hostnamectl输出示例Red Hat Enterprise Linux Server release 7.4 (Maipo) Linux rhel-server 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linuxhostnamectl 展示的 Static hostname、Operating System、Kernel、Architecture这四个字段在报告的“主机信息”表里基本都能用上。注意 uname -a 显示的是 3.10.0-693.el7说明是 RHEL 7.4 的内核如果看到 3.10.0-957.el7那就是 7.6 之后的内核了。1.2 补丁等级与安全更新状态查看当前系统安装包的更新时间rpm -qa --last | head -20看最近一次 yum update 是什么时候。测评时通常要求系统“及时更新安全补丁”没有统一的天数标准但行业普遍参考最近90天内是否有更新记录。接着看是否有待更新的包yum check-update --security这个命令会把所有标记为安全更新的包列出来。如果输出为空或只提示“没有需要更新的软件包”说明系统补丁更新状态基本合格如果列出一大堆整改建议就是打补丁。这里要说明一个原则不要在测评现场直接跑 yum update尤其是生产服务器。我见过有新手测评师手痒去执行更新结果包管理器锁住、业务直接受影响。测评的原则是“只读优先”能用查看命令就不要动系统状态。yum check-update 本身是只读的安全可以放心用。1.3 运行时长与关键进程概况再看系统运行时长和资源占用判断是不是一台活跃的生产服务器uptime ps aux --sort-%cpu | head -15超过一年的 uptime 在等保测评报告里其实是常见情况这并不代表系统“不安全”但是配合补丁检查结果看一个跑了一年没重启、又没有安全更新的系统整改优先级就应该调高。2. 身份鉴别类测评命令口令策略、账户锁定与会话控制身份鉴别是等保三级系统里权重最高的控制点之一。测评项包括登录口令复杂度、口令生存周期、登录失败处理、远程登录限制。这两节是命令最密集的部分也是最容易出整改项的部分。2.1 口令复杂度与有效期核查RHEL 7 的口令策略由 /etc/login.defs 和 PAM 配置共同决定。先看有效期相关的四项cat /etc/login.defs | grep -E ^PASS_MAX_DAYS|^PASS_MIN_DAYS|^PASS_WARN_AGE测评合格参考值PASS_MAX_DAYS ≤ 90PASS_MIN_DAYS ≥ 7可选PASS_WARN_AGE ≥ 7这些参数只对新建用户生效。已经存在的用户系统只认 /etc/shadow 里保存的密码期限值。测评时不能只读 login.defs 就下结论必须把 shadow 里每个账户的密码修改日期和过期天数都摸清楚awk -F: {print $1, $3, $4, $5} /etc/shadowshadow 四个字段分别是用户名、最后一次修改密码距1970-01-01的天数、两次修改最小间隔天数、密码过期天数。把第3列最后修改时间加第5列过期天数换算成日期就能算出这个账户的密码什么时候到期。密码复杂度跑 PAM 配置grep -E pam_pwquality|pam_pwhistory /etc/pam.d/system-auth cat /etc/security/pwquality.confRHEL 7.4 之后密码复杂度参数集中在 pwquality.conf 里。常见的合格配置minlen 8 dcredit -1 ucredit -1 lcredit -1 ocredit -1分别表示最小长度8、至少包含数字1位、大写字母1位、小写字母1位、特殊字符1位。注意 pwquality.conf 里很多行是注释掉的注释掉的参数不生效如果 dcredit -1 这类配置前面有 # 号说明系统根本没开启这个复杂度要求。还有一个容易漏的点RHEL 7 会同时读取 /etc/pam.d/system-auth 和 /etc/pam.d/password-auth。有些管理员只改了 system-auth走 password-auth 的服务依然在用弱口令策略。测评时两个文件必须都看一眼。2.2 登录失败处理与账户锁定等保要求“应具有登录失败处理功能结束会话、限制登录次数”。RHEL 7.4 系统的标准方案是 pam_faillock也有存量服务器还在用 pam_tally2。先看当前生效的锁定策略grep -E pam_faillock|pam_tally2 /etc/pam.d/system-auth /etc/pam.d/password-auth正常的 faillock 配置会出现在三个位置auth 段auth required pam_faillock.so preauth失败计数auth 段且靠后auth required pam_faillock.so authfail认证失败处理account 段account required pam_faillock.so锁定检查典型合格配置如下auth required pam_faillock.so preauth silent audit deny5 unlock_time900 auth sufficient pam_unix.so nullok try_first_pass auth required pam_faillock.so authfail audit deny5 unlock_time900 account required pam_faillock.sodeny5 表示连续失败5次锁定unlock_time900 表示锁定15分钟。要是只看到 pam_unix 而没有 faillock那账户锁定这项基本就是不合格需要整改。查看当前账户锁定情况faillock --user rootfaillock 在 RHEL 7.4 默认安装如果系统报 command not found就用 pam_tally2pam_tally2 --user root注意faillock 输出里 When、Type、Source、Valid 才是关键。如果 Valid 显示最近的失败记录说明该账户近期有被暴力尝试过的痕迹。想清理测试过程留下的锁定记录时faillock --user root --reset这条命令测评期间谨慎使用只有整改后复测时才用而且要在明确授权下操作否则会把真实攻击痕迹抹掉。2.3 登录会话超时与登录提示身份鉴别里还有一项是“应具有登录失败处理功能结束会话”延伸出来就是对空闲会话的限制。RHEL 7 的超时靠 TMOUT 环境变量控制cat /etc/profile | grep -i tmout合格配置是 TMOUT600也就是10分钟空闲自动注销。注意 /etc/profile 里默认没有这一行如果 grep 不到输出就应该去检查 /etc/bashrc、/home 下的 ~/.bash_profile。SSH 会话层面的控制也不能漏grep -E ^ClientAliveInterval|^ClientAliveCountMax /etc/ssh/sshd_config推荐配置是 ClientAliveInterval 600、ClientAliveCountMax 3意思是每10分钟发一次探活包连续3次无响应就断开。这两个参数在测评时经常被忽略但正好能匹配“会话超时退出”的要求。2.4 远程管理的加密与Root限制身份鉴别类还有远程管理这块。等保要求“采用口令、密码技术、生物技术等两种或两种以上组合”以及对登录用户进行身份标识。SSH 配置里要重点检查grep -E ^Protocol|^PermitRootLogin|^MaxAuthTries|^PermitEmptyPasswords /etc/ssh/sshd_config推荐值Protocol 2、PermitRootLogin no 或 prohibit-password、MaxAuthTries ≤ 5、PermitEmptyPasswords no。RHEL 7.4 支持主机密钥的 ed25519 算法所以 sshd_config 里 HostKey 一般包含 /etc/ssh/ssh_host_ed25519_key这个不用改。但如果看到 PermitRootLogin yes整改项就来了——一般建议改成 no 或 prohibit-password允许密钥登录、禁止口令登录生产环境里 root 直登风险太高光这一条就能让整改报告多一页。3. 访问控制与系统权限核查命令访问控制这块测评的核心是系统里有没有越权账号、是否授权了不合理的 sudo 权限、文件权限是否放得太松。命令都比较简单但是输出解读的坑不少。3.1 用户账户与特权账号检查把所有UID为0的账户列出来awk -F: ($30){print $1} /etc/passwd正常情况下输出只有 root 一行。如果混入了其他账户基本可以判断是管理员手工加的特权账号或者后门账号需要重点核实。测评场景下看到 uid0 的非 root 账户报告上直接写高风险整改这个几乎不用商量。顺便看下 /etc/passwd 里有没有不该存在的登录 shellawk -F: $7!/sbin/nologin $7!/bin/false {print $1, $7} /etc/passwd这条会把所有能通过 shell 登录的账户列出来。测评时重点看有没有 games、shutdown 这类历史遗留账户被赋予了 /bin/bash。正常服务器上非运维账户应该一律 /sbin/nologin。3.2 sudo 授权与 su 管控核查sudo 权限的检查cat /etc/sudoers ls -l /etc/sudoers.d/ cat /etc/sudoers.d/*sudoers 里重点关注两行root ALL(ALL) ALL %wheel ALL(ALL) ALL如果发现普通账号被写成了 ALL(ALL) NOPASSWD: ALL这就等于把 root 权限平白送人了等保测评中属于明显的高风险点。特别注意 sudoers.d 目录很多管理员会把应用账号临时授权写在这里测评时只翻 /etc/sudoers 主文件会漏掉一大半授权信息。su 命令本身的权限也要确认ls -l /bin/su/bin/su 的所属组应该是 root权限是 -rwsr-xr-x设置了SUID位。如果 su 被降权或者被替换成非SUID会导致普通用户无法切换root但这不是等保的检查点反而是功能性问题。这里真正要检查的是有没有非授权用户被加入 root/wheel 组getent group wheel getent group rootwheel 组里的成员默认都有 su 到 root 的权限多一个不认识的用户都是越权风险。3.3 文件权限与 umask 核查等保访问控制里有“重要文件的访问权限”要求。最直观的一条ls -l /etc/passwd /etc/shadow /etc/group合格权限是 passwd 644、shadow 000 或 400、group 644。看到 /etc/shadow 权限是 644 甚至 777 时这项直接不合格——任何用户都能读出密码哈希暴力破解只是时间问题。umask 代表新建文件默认权限的掩码umask grep -E ^umask /etc/profile /etc/bashrc /etc/login.defs合格值一般是 077 或 022。022 是默认值新建文件是 644、目录是 755这个在多数企业里可以接受内网敏感服务器建议用 077新建文件只有属主可读写能防“临时文件被围观”。找全局可写文件和没有属主的文件find / -type f -perm -0002 2/dev/null find / -nouser -o -nogroup 2/dev/null全局可写文件意味着任何人都能改内容配置文件一旦被篡改后果可大可小。/tmp、/var/tmp 这类临时目录自身权限是 1777粘滞位目录本身在被检查范围内里面的普通文件不应该全局可写。find 输出里出现 /tmp 下的临时文件可以忽略但如果 /etc、/usr 下面出现全局可写文件那是实打实的整改项。3.4 SUID/SGID 程序审计查找带 SUID/SGID 位的程序find / -type f -perm /4000 -o -type f -perm /2000 2/dev/null常见的合法 SUID 文件是 passwd、su、sudo、mount、ping 等。如果发现 /usr/bin/vim、/usr/bin/find、tar 这类普通工具被加了 SUID 位多半是管理员图方便留下的应该立即降权。等保测评里“能够更改系统配置的命令”被普通用户以高权限执行属于访问控制缺陷整改建议就是去掉 SUID 位chmod u-s /usr/bin/vim测评阶段只记录、不改动即使要整改也必须在变更窗口内操作。4. 安全审计与日志核查命令安全审计是等保三级里分量最重的技术控制点之一。审计服务有没有开、规则全不全、日志能不能留存直接决定这一整块测评是 pass 还是 fail。4.1 auditd 审计服务状态与规则先看服务状态systemctl status auditd auditctl -s要求 auditd 处于 running 状态。如果显示 inactive 或者 failed整改建议第一行就是“启用并配置 Linux 审计服务”。看审计规则是否覆盖关键事件auditctl -l cat /etc/audit/audit.rules等保测评审计规则通常要求覆盖时间修改adjtimex、settimeofday、clock_settime身份鉴别事件login、logout文件权限变更chmod、chown、setfacl关键设备文件变更内核模块加载insmod、modprobe对应的 audit.rules 里应该能看到类似规则-w /etc/security/opasswd -p wa -k identity -w /etc/sudoers -p wa -k actions -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -a always,exit -F archb64 -S chmod -F auid1000 -k perm_chng如果 auditctl -l 输出为空表示审计规则没配置。这项和审计服务未部署一样都是高危整改。查看审计日志里有没有被审查的记录ausearch --start today -ts recent ausearch -k identity --start todayausearch -k identity 更适合测评它把所有打上 identity 标签的事件列出来能直接佐证“审计日志留有记录”这个检查项。在评审现场输出几条带 auid 的审计记录放在报告截图里比空口说有审计更有说服力。4.2 rsyslog 日志服务与远端备份日志服务状态systemctl status rsyslog cat /etc/rsyslog.conf | grep -E ^authpriv|^cron|^kern|^mail等保要求日志内容至少覆盖“用户鉴别、访问控制、系统运行等”并且“日志记录至少保存六个月”。前者看 rsyslog 有没有在记录 secureauthpriv、cron、messages 几类日志authpriv.* /var/log/secure cron.* /var/log/cron *.info /var/log/messages后者看有没有把日志转发到远端日志服务器grep -E |send /etc/rsyslog.conf /etc/rsyslog.d/*.conf发现类似.10.0.0.5:514 的行说明日志已经在向远程服务器汇聚这项可以判满足什么都没有的话整改建议会要求搭建日志集中存储。4.3 登录日志与异常行为回溯人工抽查登录记录last -n 20 lastb -n 10 grep Failed password /var/log/secure | tail -20last 看正常登录成功的历史lastb 看失败登录也就是暴力破解痕迹secure 日志里的 Failed password 行包含来源IP和尝试次数如果 lastb 输出比 last 还长几页说明这台机器正在被口令爆破。测评时这类证据要截图保留并且在结果里记录“存在多次登录失败记录建议排查入侵迹象”。另外还可以看特定用户的登录时间last root | head如果想看某用户最近 su 切换记录grep session opened for user root /var/log/secure | tail日志类测评命令的现场易错点在于有些日志文件被 logrotate 压缩过了比如 secure-20250401.gz。测评时先 ls -l /var/log/secure* 确认日志文件列表再决定看哪个文件。grep 压缩包前用 zcatzcat /var/log/secure-*.gz | grep Failed password | tail4.4 命令历史与操作留痕等保安全审计里有“应对审计过程进行保护防止未授权中断”。测评经常通过 shell history 倒查管理员登录后做了什么。查看命令历史history echo $HISTSIZE grep -E ^HISTSIZE|^HISTTIMEFORMAT /etc/profile合格配置是 HISTSIZE 合理比如1000以上最好还有 HISTTIMEFORMAT 加上时间戳。很多生产服务器 history 是空白的因为管理员用了不写历史的登录方式这在审计追溯里是硬伤。整改建议是开启命令时间戳记录echo export HISTTIMEFORMAT%F %T /etc/profile测评阶段需要克制不要随手在别人的服务器上写入这种配置只记录现状就行。5. 入侵防范与网络访问控制命令等保提的入侵防范在 Linux 层面的落地主要是 SELinux、防火墙、开放端口、补丁、异常进程。这部分的测评命令和日常排障比较接近但判定标准不太一样。5.1 SELinux 开启状态核查SELinux 状态必须用三个命令交叉确认getenforce sestatus cat /etc/selinux/configgetenforce 显示 Enforcing 是合格Permissive 说明强制模式被关闭Disabled 是永久关闭需要改配置文件重启才能恢复。单看配置文件里的 SELINUXenforcing 不能下结论必须结合当前生效状态因为管理员可能在运行时执行了 setenforce 0。测评时若遇到 Permissive 状态判断为“SELinux未全面启用”整改项是临时恢复 Enforcing 并修改配置文件永久生效。如果生产应用确实依赖关闭 SELinux整改路径一般是改用容器或者通过 audit2why、audit2allow 写自定义策略而不是一关到底。5.2 防火墙策略与开放端口审查防火墙实际生效状态systemctl status firewalld firewall-cmd --state firewall-cmd --list-allfirewalld 的 list-all 能看到当前 zone 里放行的服务和端口。理想的测评结果是有明确的放行策略且没有放行危险端口。如果系统用的是 nftables 或纯 iptablesiptables -L -n --line-numbers systemctl status iptables重点看 INPUT 链默认策略是否为 DROP 或 REJECT以及放行的端口是否和业务清单一致。默认 ACCEPT 且没有任何规则的系统防火墙这项基本不合格。再看实际监听端口ss -tlnp ss -unlpRHEL 7 里 netstat 依赖 net-tools可能没装直接用 ss 更保险。ss -tlnp 输出里会出现监听地址、端口和进程名。测评时把端口列表和“端口-服务-业务负责人”对照表比对凡是列表上找不到归属的端口都属于“开放不必要的端口”整改关闭。特别要关注 23telnet、512-515r-services、873rsync、3306MySQL 直连端口这类端口出现在不该出现的服务器上都是问题。5.3 异常进程与开机自启动项排查入侵防范要求“应能检测到对重点账户的冒用和暴力攻击”常见做法是人工抽查异常进程和计划任务。看进程ps aux --sort-%cpu | head -25 ps aux --sort-%mem | head -25临时目录下出现名为 kworker、sshd 的进程、或者进程路径在 /tmp 下几乎可以直接判断是挖矿木马。RHEL 上用 top 看会更直观但测评要留文本证据ps 的输出更适合剪贴到记录里。计划任务排查crontab -l -u root ls -l /var/spool/cron/ cat /var/spool/cron/* systemctl list-unit-files --stateenabled/var/spool/cron 下每个文件代表一个用户的 crontab。木马喜欢藏在 /var/spool/cron/ 里写一个更新任务payload 下在 /tmp过一会儿再执行。看到指向 /tmp 或 base64 字符串的下载任务基本就是中了招这时测评现场要把样本路径和时间记录清楚。开机自启动项systemctl list-unit-files --stateenabled | awk {print $1}确认没有多余的服务在开机时拉起。特别是 rc-local、inetd 这类古老的启动通道。RHEL 7 里默认没有 inetd如果有说明是额外安装的 xinetd 服务需要重点审查。5.4 内核网络加固参数抽查等保测评里网络安全的防护项涉及防 SYN 攻击、禁止 IP 转发、关闭 ICMP 重定向。用 sysctl 统一查看sysctl net.ipv4.ip_forward net.ipv4.conf.all.accept_redirects net.ipv4.conf.default.accept_redirects net.ipv4.tcp_syncookies合格参考值net.ipv4.ip_forward 0不做路由转发accept_redirects 0tcp_syncookies 1ip_forward 如果为 1 并且这台机器不是路由器就是配置错误。tcp_syncookies 为 1 说明基本防 SYN Flood。改成持久化需要写 /etc/sysctl.conf测评阶段只读不写。某些云环境默认会开 ip_forward如果对方确实是云主机且不承担路由功能这项可以在报告中说明然后按系统定位给整改建议。6. 常见问题与测评命令速查实操中遇到的坑比命令本身多得多我挑几个高频的录在这里。6.1 “改了一处PAM另一处没改”的经典翻车RHEL 7.x 的账户锁定和密码策略同时受 system-auth 和 password-auth 两个文件影响。很多管理员只在 system-auth 里加了 faillockSSH 登录会被锁定但本地控制台登录、FTP 登录走的是 password-auth等于没设防。测评时两个文件必须分别验证而且最好用多种登录方式实测一次触发锁定实测比 grep 配置文件可靠得多。6.2 密码到期时间“看着像合格其实不合格”shadow 文件里密码过期天数算出来可能是“还有180天才到期”但等保要求90天内必须改。这种不算“密码期限超长”实际风险是策略没有覆盖全部账户。测评命令chage -l username能输出该账户的密码最后修改日期、有效期、失效期。但 chage 一次只能看一个用户批量看还是用 awk 处理 /etc/shadow。有些账户用的是“永不过期”策略即过期天数为99999这类账户要逐一标注整改为修改密码并设置90天期限。6.3 auditd 规则不加载的现场疑案有审计服务不代表有审计规则。经常遇到 auditd 状态 running但 auditctl -l 输出为空重启后规则丢失。原因是规则写在 /etc/audit/rules.d/ 里的少了关键配置或者一个服务进程使用 auditctl 在运行时加载但没落盘。测评后核验时先看 /etc/audit/rules.d/RHEL 7 默认规则文件是 audit.rules 和 augenrules 生成的 /etc/audit/audit.rules。如果只有默认规则基本等于没有业务相关规则整改时要手工编写业务关键路径的审计规则集。6.4 测评命令速查表把常用命令整理成表格方便现场粘贴检查点命令合格参考系统版本cat /etc/redhat-releaseRHEL 7.x密码有效期cat /etc/login.defsPASS_MAX_DAYS ≤ 90密码复杂度grep pam_pwquality /etc/pam.d/system-auth8位且含四类字符账户锁定grep faillock /etc/pam.d/*deny5, unlock_time900会话超时grep TMOUT /etc/profileTMOUT600SSH Root限制grep PermitRootLogin /etc/ssh/sshd_configno 或 prohibit-passwordUID0账户awk -F: ($30) /etc/passwd仅 root全局可写find / -type f -perm -0002无审计服务auditctl -srunning审计规则auditctl -l有关键路径规则日志服务systemctl status rsyslogactiveSELinuxgetenforceEnforcing防火墙firewall-cmd --staterunning 且有放行策略开放端口ss -tlnp与业务清单一致补丁更新yum check-update --security无安全更新或记录可查这张表不是测评报告本身是现场核对用的工作底稿。做完一轮后把每个点的输出结果、判定结论、截图时间整理进底稿复测和整改时都能节省大量时间。6.5 现场操作注意事项经验之谈三条。第一只读命令和写命令要分开。测评现场只跑读取类命令任何写操作清日志、改配置、安装软件包都要在客户变更窗口内进行并且提前确认授权。哪怕只是 faillock --reset 这种看似无害的操作也可能把攻击者留下的证据清掉。第二输出要留档。RHEL 的终端输出直接复制到文本里就能作为证据但注意带上时间戳和主机名防止审计追溯时说不清是哪台机器。好习惯是每条命令后面手动记一行采集时间。第三评估报告里不要照抄命令输出当整改建议。整改建议要让客户看得懂比如“调整 /etc/ssh/sshd_config 中 PermitRootLogin 为 no重启 sshd 服务”而不是把输出表格贴回去。命令是工具整改才是目的。这套命令我在多个等保测评项目里反复用最直观的体会是Linux 测评考的不是“会不会敲命令”而是“命令输出背后代表什么风险”。同样一条 auditctl -l新手看到的是列表内容老手看到的是审计规则有没有覆盖用户登录、权限变更、文件访问这些关键行为以及日志能否支撑事后溯源。测评不是例行公事现场发现问题、给出可执行修复路径报告才有价值。最后分享一个小技巧测评前拿一台闲置的 RHEL 7.4 虚拟机先把这些命令完整跑一遍输出全部存档。到了客户现场心里就有底哪些输出是正常基线、哪些是异常状态一眼能分辨。测评这种工作准备工作做到位现场才不会慌。