2026-09-11 04:50:26 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 等保测评83%未通过主因是空口令、无审计、日志未留存等基线配置缺失，需重点核查弱口令、默认账户、明文传输、双因素缺失、审计日志、多余端口及公网漏洞7类高危项，建议立即整改并建立配置漂移监控机制，推动BaselineasCode实现持续合规。 综合评分： 85 文章分类： 安全建设,安全运营,政策法规,WEB安全,数据安全

甲方运维的等保自查清单先跑这7个高危项，再迎评

宝十八宝十八

网络安全老宋

2026年9月10日 12:00 山东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

导语： 你好，我是网络安全老宋。安全攻防干货准时送达！

网络安全老宋// 等保合规 · 基线核查实战

// 安全运维 · 迎评自查

甲方运维的等保自查清单先跑这7个高危项，再迎评

83% 的等保测评没过，不是栽在技术深，是栽在空口令、没开审计、日志不留存这几件一眼能看穿的事上。附一键自查脚本。

等保2.0基线核查高危项自查

🔑 一句话精华：等保测评 83% 没过，不是栽在技术深，是栽在空口令、没开审计、日志不留存这几件一眼能看穿的事上。

今年 9 月，公安部网安局公布「护网—2025」6 起行政执法典型案例，贵州某政务服务系统遭攻击、群众损失 400 余万元，查明原因是运营方没留存网络日志、没及时处置漏洞；江苏一家短信平台因为压根没做等保备案测评，被攻破后滥发诈骗短信 2.7 万余条。这些系统不是被什么高深 0day 打穿的，是连最基础的基线都没守住。

你自己的系统，测评师坐到你终端前，第一件事不是看 PPT，而是敲命令查配置。身份鉴别、访问控制、安全审计、入侵防范这四个控制点，三级系统「安全计算环境」11 个控制点里几乎全落在配置核查上——口令周期达不达标、审计开没开、默认账户改没改，全是一行配置的事。基线过硬，测评顺；基线松散，汇报讲得再好也补不回来。

上个月我写过一篇聊合规红线的文章，当时说网安法第 59 条能让单位吃罚单、直接责任人被处分。这篇把它落回运维手上：测评进场前，你先自己跑一遍，把最容易挂的高危项清零。

01为什么核查是测评的「重头戏」

等保 2.0 的三份国标里，现场测评方法只有三种：访谈、核查、测试。其中「核查」——查配置、看记录——承接了绝大多数测评项。三级系统通用要求总共 211 个测评项，安全计算环境一个域就占了 11 个控制点、三十多项细项。

说句实话，访谈你能临时补材料，测试看运气，唯独配置核查是实打实的，服务器上敲一条命令，结果当场出来，改不了口供。测评师进场最常坐的位置，就是运维那台终端前面，让你登录服务器给他看。

ℹ️ 法规锚点：《网络安全法》第二十一条要求采取技术措施监测、记录网络运行状态，按规定留存网络日志不少于六个月；三级系统每年至少测评一次；《关键信息基础设施安全保护条例》2021 年 9 月施行后，关基系统的核查要求进一步加严。

02最易挂的 7 类高危核查项

下面这 7 类，是从《高风险判定指引》判例和一线实测里提炼出来的最高频「一票否决」项。每一项都给：判定为高危的条件、一行自查命令、整改动作。

| | | | | | | — | — | — | — | — | | # | 核查项 | 判高危条件 | 一行自查 | 整改动作 | | 1 | 弱口令/空口令 | 存在空/弱口令且可登录 | awk -F: ‘($2==””){print $1}’ /etc/shadow | 删/锁空口令，强制复杂度 | | 2 | 默认账户未改 | admin/Administrator 用出厂口令 | net user | 重命名+改强口令，禁 Guest | | 3 | 远程明文传输 | Telnet/明文管理，口令被窃听 | 查 telnet 是否在跑 | 关 Telnet，强 SSHv2，堡垒机 | | 4 | 双因素缺失 | 三级核心设备仅静态口令 | 查控制台/MFA 开关 | 高权限账号启用 MFA | | 5 | 审计未开/日志不足 | 审计没开，或日志不足 6 月 | systemctl is-active auditd | 开 auditd+rsyslog，轮转26份 | | 6 | 多余服务/高危端口 | 开 135/445，默认共享未关 | ss -tulpn | 关不必要服务，收敛端口 | | 7 | 公网高危漏洞 | 互联网可达设备有已知大漏洞 | 漏扫/暴露面核查 | 打补丁或访问限制 |

逐条拆解最关键的三条，其余照表整改即可。

2.1 空口令和弱口令，最低级也最常见

空口令账户意味着任何人只要能连上服务器就能直接进。/etc/shadow 里第二字段为空就是空口令，一行 awk 就能揪出来：

⏺ Shell · 空口令排查

列出所有空口令账户，有输出即高风险项，必须清零

awk -F: ‘($2 == “”){print “空口令账户: ” $1}’ /etc/shadow

整改不是改个密码就完事。口令复杂度要落到 PAM：长度 8 位以上、含大小写+数字+特殊字符、重复字符限制、定期更换。源文给的 pwquality 配置是直接可抄的基线：

⏺ Conf · pwquality

/etc/security/pwquality.conf 口令复杂度（PAM 生效）

minlen = 8

dcredit = -1 # 至少 1 个数字

ucredit = -1 # 至少 1 个大写

lcredit = -1 # 至少 1 个小写

ocredit = -1 # 至少 1 个特殊字符

maxrepeat = 3 # 最多连续 3 个相同字符

enforcing = 1

2.2 审计没开，等于把溯源的门焊死了

测评判高危的另一条硬线：重要设备没开启任何审计功能，出事无法溯源。Linux 侧是 auditd 内核审计 + rsyslog 集中转发两层，很多系统只装了没启用，或者日志存本地几天就被轮转掉。

⏺ Shell · 审计开启

开启关键文件审计（身份/权限/提权相关）

/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 scope

加载并确认状态

augenrules –load

auditctl -s # 输出 enabled=1 即审计已开

日志留存是另一条硬指标：网络安全法要求不少于六个月，等保场景里 logrotate 按周轮转 26 份约等于半年。远程转发用 @@ 走 TCP 落到日志服务器，别只留本地——本地日志能被 root 删，这本身就是判例里「审计记录不满足保护要求」的问题。

2.3 公网高危漏洞 + 多余端口，是攻击者的后门

互联网直接可达的设备如果存在已知重大漏洞，比如早年的永恒之蓝、近年的 Log4j 类，未及时修补又没做访问限制，直接判高危。再加上 135/445、不必要的 SMB 默认共享，等于门没锁还把钥匙插在锁上。

⏺ Shell · 端口排查

看当前监听端口，重点排查 135/139/445/3389 等非必要暴露

ss -tulpn | grep -E ‘:135|:139|:445|:3389’

📌 老宋数据

等保测评未通过案例里，83% 源于高风险项处置不当。

三级系统 211 个测评项，最常被一票否决的，就是上面这 7 类。

把这几件事做对，你已经跑赢了大多数迎评突击队。

如果你身边有运维同事还在用默认配置，转发给他看看——这 7 类高危项，是他迎评前最该先清零的。

03一键自查脚本：测评前自己先跑

把上面的核查项串成一个只读巡检脚本，迎评前在自己环境跑一遍，报告里的问题项提前清零。脚本只查不改，安全。

⏺ Bash · 只读巡检

!/bin/bash

等保 Linux 基线自查（只读，不改动系统）

echo “== 1 空口令账户 ==”

awk -F: ‘($2 == “”){print $1}’ /etc/shadow

echo “== 2 口令复杂度 ==”

grep -E ‘^minlen|^[udlo]credit’ /etc/security/pwquality.conf

echo “== 3 登录失败锁定 ==”

grep -Ev ‘^#|^$’ /etc/security/faillock.conf

echo “== 4 SSH 基线 ==”

sshd -T | grep -Ei ‘permitrootlogin|maxauthtries|permitemptypasswords’

echo “== 5 审计与日志 ==”

systemctl is-active auditd rsyslog

auditctl -s | head -3

echo “== 6 监听高危端口 ==”

ss -tulpn | grep -E ‘:135|:139|:445|:3389’ || echo “无高危端口监听”

Windows 侧一条命令就能看口令与锁定策略现状，整改用 net accounts 或组策略：

⏺ PowerShell · Windows

核查：口令与锁定策略现状（Windows）

net accounts

整改：长度8/90天/最短7天/历史5次、5次失败锁15分钟

net accounts /minpwlen:8 /maxpwage:90 /minpwage:7 /uniquepw:5

数据库侧最常被判高风险的是「无审计」和「默认账户未锁」。MySQL 8.0 社区版不带审计插件，等保场景必须补齐——用 Percona 或 MariaDB 的审计插件，否则这一项直接挂。

04查完怎么办：整改闭环 + 复测留证

核查报告出来只是开始。整改按风险分三档：

| | | | | — | — | — | | 等级 | 处理节奏 | 典型项 | | 🔴 高危 | 立即改 | 空口令、明文管理通道、审计关闭、公网高危漏洞未修 | | 🟠 中危 | 限期改 | 口令策略不达标、锁定阈值不对、双因素没上 | | 🟡 低危 | 排期改 | 版本信息隐藏、banner 修改、不必要的服务 |

每一项整改后必须复测留证，三件套归档：改前配置截图、改后配置截图、复测命令输出。测评师要什么给什么，不用临时翻箱倒柜。

⚠️ 注意：整改前先备份配置文件（cp xxx.conf xxx.conf.bak），改完 sshd -t 之类先校验语法再重启，别一股脑重启把服务搞挂，那比不改还尴尬。

频率上建议三级演进：从迎评前一次性突击，走向季度周期核查，最终落到配置漂移持续监控。基线固化后，任何偏离默认配置的变更自动告警，合规从「运动式」变成「日常态」——这才是甲等保护该有的样子。

05真实代价：不做基线的后果

护网-2025 那 6 起案例，每一桩的根因都绕不开「基线没做」：

这些单位吃的不是「技术落后」的亏，是「该做的没做」的亏。处罚依据清一色是《网络安全法》第二十一条（义务）加第五十九条（罚则：单位处一万元以上十万元以下、直接责任人处五千元以上五万元以下，或处分/责令整改）。上次聊合规红线时我提过这三条，这次是它落地的活例子。

🔴 新规提醒：2025 版《网络安全等级保护测评高风险判定实施指引（试行）》已废除百分制，改为「符合（≥90% 且无重大隐患）/基本符合/不符合」三级结论；新增 33 项重大风险隐患触发项（含 11 项 2020 版未涵盖，如渗透测试覆盖率不足、零日漏洞无热补丁能力），重大隐患一票否决。从「合规达标」转向「实效防护」，靠刷分混过去的路子走不通了。

06进阶：Baseline as Code，让基线自己说话

人工核查不可持续，终局是把基线写成代码。国际上一套成熟做法是 Compliance as Code：用 OpenSCAP 扫 CIS Benchmark，再用 Ansible 把偏离自动纠正回来。

⏺ Bash · OpenSCAP 扫描

RHEL 9 / 兼容发行版：安装扫描器与安全基线内容

dnf install -y openscap-scanner scap-security-guide

按 CIS 服务器二级基线扫描，生成可读报告

oscap xccdf eval \

–profile xccdf_org.ssgproject.content_profile_cis_server_l2 \

–report /var/www/html/compliance-report.html \

/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Ansible 负责把「偏了的配置拉回基线」，且是幂等的——跑一次加固，跑一千次除非配置漂移否则不动：

⏺ YAML · Ansible 纠正

name: 确保 PermitRootLogin 为 no

ansible.builtin.lineinfile:

path: /etc/ssh/sshd_config

regexp: ‘^PermitRootLogin’

line: ‘PermitRootLogin no’

更进一步的玩法，是把扫描嵌进 CI/CD：镜像构建的最后一步跑 OpenSCAP，合规分低于阈值直接让构建失败，新服务器上线即合规，生产漂移问题大幅减少。CIS 规则还自带与 NIST 800-53、ISO 27001、PCI-DSS 的映射，过一次 CIS 等于同时覆盖多个框架，审计证据一次成型。

这条路子把「每年突击两个月」压缩成「每周半小时看一眼告警」，也是我把前面几篇合规文章串起来的底层逻辑：制度、技术、自动化，缺一不可。

老宋说： 等保的本质不是写了多少文档，是服务器上那几行配置到底有没有、开没开、日志留没留。判定从来不看你汇报写得多漂亮，看的是 sshd_config 里 PermitRootLogin 是不是 no、auditd 是不是 enabled=1、日志是不是真存了六个月。

行业里有个怪现象：愿意花几百万买设备，却没人愿意测评前自己敲一条命令自查。83% 的不过案例都栽在空口令、没开审计这种低级项上，说明平时靠突击、考前熬夜背书，测完就还回原样。2025 版指引废除百分制、改一票否决，恰恰是逼大家从「凑分」回到「实效」。

你现在能做的一件事：把第 03 节的脚本拷到你常用的一台服务器上跑一遍，看空口令和监听端口那两行有没有输出。有输出今天就改，没输出你今晚能睡个安稳觉——这比任何等保咨询报告都管用。

防御，不是在演练期间发现攻击，而是在演练开始前就把攻击面收敛到最小。

end

不想错过文章内容？读完请点一下“在看”，加个“关注”，您的支持是我创作的动力

期待您的一键三连支持（点赞、在看、分享~）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：网络安全老宋宝十八宝十八《甲方运维的等保自查清单先跑这7个高危项，再迎评》