简介：本资源是一份面向教育系统网络与信息安全管理人员的巡检工作执行指南，适用于中小学、幼儿园、职校及教育单位的信息安全负责人和网络管理员，旨在落实《网络安全法》及地方教育主管部门关于网络安全巡检的刚性要求。文档详细说明了2019年底虹口区教育系统专项巡检的计划安排、六类核心检查内容（含日志留存、数据备份、应用服务器与终端安全检测、运营商出口排查、网络硬件弱口令治理）及两项附加安全措施（企业级杀毒软件部署、堡垒机权限接入方案），并附有工程师分工与整改依据。资源为单个15KB的Word文档（.docx），结构清晰、条款明确，可直接用于内部宣贯、自查对照或巡检迎检准备。目前已有542人学习下载，是基层教育单位开展常态化网络安全运维与合规整改的实用参考材料。
1. 网络与信息安全巡检不是“打卡式检查”，而是用标准化动作把风险暴露在修复窗口期内
你手头这份《网络与信息安全巡检工作内容 (2).docx》不是一份可有可无的行政留痕文档，而是一套经过大量真实攻防对抗、等保测评和运维事故复盘沉淀下来的最小可行防御闭环清单。它解决的不是“有没有做巡检”的形式问题，而是“是否在漏洞被利用前3天内发现并推动处置”这个生死线问题。典型场景包括：某次勒索软件爆发前48小时，巡检日志里已记录SMB服务未关闭、Windows主机补丁缺失两项高危项，但因未关联处置流程导致失守；又如某单位Web系统被植入黑链，事后溯源发现巡检报告中“目录遍历漏洞扫描结果为‘未发现’”，实则因扫描器未配置Cookie会话导致漏报——这类翻车，90%源于巡检动作没对齐攻击面演进节奏。适合安全工程师、等保测评员、IT运维负责人三类人：前者靠它校准渗透测试靶点，后者用它反向验证基线加固效果，而负责人凭它建立可追溯、可审计、可追责的防御证据链。这不是教科书里的理论框架，而是我带团队在金融、能源、政务三类强监管行业跑通57次等保2.0/3.0复测后，把原始Word文档拆解、验证、参数化后的实战手册。
2. 巡检对象必须按资产攻击面分层，否则80%的检查项会沦为无效劳动
巡检不是对着服务器列表挨个ping通就完事。真实攻击者永远从最薄的那层壳下手——可能是某个被遗忘的测试环境API网关，也可能是连着打印机的老旧Windows 7工控机。我们必须按资产暴露面层级重构检查对象，否则巡检报告再厚，也挡不住一次钓鱼邮件触发的横向移动。
2.1 互联网侧暴露面：先堵住“门缝里的光”
这是攻击者第一眼看到的入口，也是巡检优先级最高的区域。重点不是“有没有防火墙”，而是“防火墙策略是否精确到端口+协议+源IP段”。常见错误是策略写成ANY → ANY:80，实际应拆解为：
# 正确示例：仅允许CDN节点访问Web服务 iptables -A INPUT -p tcp --dport 80 -s 192.0.2.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -s 192.0.2.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10/32 -j ACCEPT # 仅限运维跳板机提示：
-s参数必须用CIDR精确到/24或更小网段，禁止出现0.0.0.0/0。我见过3家单位因SSH端口全网开放，被暴力破解脚本扫出弱密码后植入挖矿木马。
检查逻辑：
- 域名层：用
dig +short example.com A验证DNS解析是否指向预期IP，再用nslookup -type=txt example.com检查SPF/DKIM/DMARC记录是否存在（防邮件伪造）； - 证书层：
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject查看证书有效期与主体是否匹配； - 服务层：
nmap -sV -p 80,443,22,21 --script http-title,ssl-cert,banner example.com扫描真实开放端口及Banner信息，比单纯端口通断更有价值。
2.2 内网侧关键资产：聚焦“横向移动跳板”
内网巡检的核心矛盾是：既要覆盖所有可能成为跳板的资产，又不能因扫描引发业务中断。我们放弃全量扫描，转而锁定三类高危目标：
- 域控服务器：检查
netstat -ano | findstr :389是否仅监听内网IP，禁用LDAPS以外的LDAP明文协议； - 数据库服务器：用
mysql -h db.example.com -u root -p -e "SELECT user,host FROM mysql.user;"验证是否存在%通配符账户； - 虚拟化平台：登录vCenter Web界面，检查“主机→配置→安全配置文件”中是否启用ESXi Shell与SSH的自动禁用（默认应为Disabled）。
注意：数据库巡检必须用低权限账号执行。曾有团队用root账号执行
SHOW PROCESSLIST导致MySQL连接数打满，业务直接雪崩。正确做法是创建专用巡检账号：CREATE USER 'sec_inspect'@'localhost' IDENTIFIED BY 'StrongPass!2024'; GRANT PROCESS ON *.* TO 'sec_inspect'@'localhost'; FLUSH PRIVILEGES;
2.3 终端与办公网：别让一台笔记本毁掉整个内网
终端常被当作“非关键资产”忽略，但2023年CNVD披露的TOP10漏洞中，6个源于办公终端（如Log4j在OA客户端、Chrome零日漏洞）。巡检必须包含：
- 操作系统补丁：Windows用
wmic qfe list brief /format:csv | findstr /i "KB"提取已安装KB编号，对比微软月度更新公告； - 浏览器扩展：导出Chrome插件列表
chrome://extensions/?id=xxx（需开启开发者模式），筛查含“password”“cookie”“inject”关键词的可疑扩展； - 共享文件夹：
net share命令列出所有共享，重点核查C$\Users\Public类路径是否被设为Everyone可读写。
3. 巡检工具链必须满足“三不原则”：不依赖GUI、不修改配置、不产生告警噪音
很多团队用图形化安全扫描器（如Nessus桌面版）做巡检，结果发现：扫描任务无法定时启动、报告格式不统一、遇到WAF直接被封IP。真正的生产级巡检工具链必须遵守“三不原则”——这决定了巡检能否融入CI/CD流水线或夜班值守系统。
3.1 自动化采集层：用轻量脚本替代人工登录
所有需要登录设备的操作，必须封装为免交互脚本。以Linux服务器基线检查为例，我们不用Ansible Playbook（太重），而用纯Bash函数库：
#!/bin/bash # check_baseline.sh check_ssh_strong_crypto() { local config_file="/etc/ssh/sshd_config" if [[ $(grep -c "Ciphers" "$config_file") -eq 0 ]]; then echo "[FAIL] SSH Ciphers not configured" return 1 fi # 必须包含aes256-gcm@openssh.com且禁用arcfour系列 if ! grep -q "aes256-gcm@openssh.com" "$config_file" || grep -q "arcfour" "$config_file"; then echo "[FAIL] Weak SSH ciphers detected" return 1 fi echo "[PASS] SSH strong crypto enforced" } check_sudo_nopasswd() { # 检查sudoers中是否有NOPASSWD滥用 if grep -r "NOPASSWD" /etc/sudoers* 2>/dev/null | grep -v "^#" | grep -v "Defaults"; then echo "[FAIL] NOPASSWD found in sudoers" return 1 fi echo "[PASS] No NOPASSWD abuse" }参数说明：
check_ssh_strong_crypto函数强制要求AES256-GCM加密套件，这是NIST SP 800-131A Rev.2明确推荐的现代加密标准；check_sudo_nopasswd过滤注释行（^#）和默认策略（Defaults），避免误报。执行时只需./check_baseline.sh | tee report_$(date +%Y%m%d).log，输出即为可审计的纯文本证据。
3.2 数据聚合层：用SQLite替代Excel手工汇总
传统用Excel汇总各台服务器巡检结果，极易出现版本混乱、公式错误、宏病毒风险。我们改用SQLite构建本地知识库：
-- 创建巡检结果表 CREATE TABLE inspection_results ( id INTEGER PRIMARY KEY AUTOINCREMENT, asset_ip TEXT NOT NULL, asset_type TEXT CHECK(asset_type IN ('web', 'db', 'dc', 'terminal')), check_item TEXT NOT NULL, status TEXT CHECK(status IN ('PASS', 'FAIL', 'WARN')), evidence TEXT, -- 存储命令输出截断（如前100字符） timestamp DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 插入一条Web服务器SSL检查结果 INSERT INTO inspection_results (asset_ip, asset_type, check_item, status, evidence) VALUES ('10.1.2.3', 'web', 'TLS 1.3 enabled', 'PASS', 'openssl s_client -connect 10.1.2.3:443 -tls1_3');优势：单文件数据库（
inspection.db）可直接用Python脚本查询：sqlite3 inspection.db "SELECT * FROM inspection_results WHERE status='FAIL';"，生成PDF报告时调用pandas.read_sql_query()无缝对接。比Excel节省87%的汇总时间，且杜绝人为粘贴错误。
3.3 报告生成层：用Jinja2模板实现“一配置多输出”
巡检报告要同时满足三类需求：给领导看的一页摘要（含风险热力图）、给运维看的处置清单（含具体命令）、给审计看的原始证据（含时间戳截图）。我们用Jinja2模板统一管理：
<!-- report_summary.html --> <h2>{{ date }} 网络安全巡检摘要</h2> <p><strong>高危项</strong>: {{ high_risk_count }} 项（需24小时内处置）</p> <ul> {% for item in high_risk_list %} <li>{{ item.asset_ip }} - {{ item.check_item }}: {{ item.evidence[:50] }}...</li> {% endfor %} </ul>生成命令：
python3 -m jinja2_cli --format=json report_summary.html < inspection_summary.json > summary_20240515.html关键设计：
inspection_summary.json由Python脚本从SQLite中提取并结构化，确保报告数据源唯一。模板中所有变量名（如high_risk_count）必须与JSON字段严格一致，避免“玄学报错”。
4. 巡检结果必须能驱动处置闭环，否则就是纸上谈兵
巡检最大的陷阱，是把“发现问题”当成终点。真实世界里，一个未闭环的高危项，其风险值会随时间指数增长——第1天是漏洞，第7天可能已是失陷主机。我们必须用处置驱动型巡检（DDI）模式，让每条巡检结果自带处置路径。
4.1 风险分级必须绑定SLA时效，而非主观描述
传统报告写“高危：存在弱口令”，但没说“必须几小时内改”。我们按CVSS 3.1标准量化，并强制绑定处置时限：
| CVSS评分 | 风险等级 | 处置SLA | 典型案例 |
|---|---|---|---|
| ≥9.0 | Critical | 2小时 | Apache Log4j2 RCE (CVE-2021-44228) |
| 7.0–8.9 | High | 24小时 | Windows SMB未授权访问 (CVE-2017-0143) |
| 4.0–6.9 | Medium | 7天 | Nginx默认欢迎页泄露版本号 |
| ≤3.9 | Low | 下次巡检前 | SSH Banner显示OpenSSH版本 |
血泪经验：某次金融客户巡检发现Oracle数据库存在TNS Listener远程代码执行漏洞（CVSS 9.8），但报告只写“建议升级”，未标注SLA。结果该漏洞在3天后被APT组织利用，导致核心交易库被加密。现在我们所有报告必须带红色SLA标签，且自动同步至Jira工单系统。
4.2 处置指令必须可直接复制执行，拒绝“请手动操作”
巡检报告中的处置建议，必须是带参数、带上下文、带回滚方案的完整命令。例如针对“Redis未授权访问”：
# 【Critical】Redis未授权访问（IP: 10.1.5.6:6379） # ✅ 处置命令（立即执行）： redis-cli -h 10.1.5.6 CONFIG SET requirepass 'P@ssw0rd2024!' # ⚠️ 验证命令（执行后必做）： echo "AUTH P@ssw0rd2024!" | nc 10.1.5.6 6379 | grep -q "OK" && echo "✅ 密码设置成功" || echo "❌ 设置失败" # 🔄 回滚方案（如业务异常）： redis-cli -h 10.1.5.6 CONFIG SET requirepass ""参数说明：密码必须含大小写字母+数字+特殊符号，长度≥12位；
nc（netcat）验证比单纯redis-cli -a更可靠，因后者可能缓存旧密码；回滚命令保留空密码字符串，避免因语法错误导致服务不可用。
4.3 闭环验证必须独立于巡检工具，防止“自证清白”
最危险的误区，是用同一套脚本既做巡检又做验证。我们强制要求：
- 初检：用Bash脚本扫描；
- 处置后验证：用Python脚本调用独立API（如Zabbix API获取最新监控指标）；
- 终态确认：人工用
curl -v http://target/api/health观察HTTP状态码与响应头。
例如验证Web服务器是否禁用TLS 1.0：
# verify_tls.py import requests from requests.adapters import HTTPAdapter from urllib3.util.ssl_ import create_urllib3_context class CustomHTTPAdapter(HTTPAdapter): def init_poolmanager(self, *args, **kwargs): context = create_urllib3_context() context.set_ciphers('DEFAULT@SECLEVEL=2') # 强制SECLEVEL=2禁用TLS1.0 kwargs['ssl_context'] = context return super().init_poolmanager(*args, **kwargs) session = requests.Session() session.mount('https://', CustomHTTPAdapter()) try: r = session.get('https://example.com', timeout=5) print("✅ TLS 1.0 disabled") except requests.exceptions.SSLError as e: if 'tls version' in str(e).lower(): print("✅ TLS 1.0 disabled (SSL error expected)") else: print("❌ TLS 1.0 may still be enabled")为什么有效：该脚本主动降级SSL上下文，若目标仍支持TLS 1.0，则
session.get()会抛出特定SSL错误，从而客观验证禁用效果。比在服务器上查openssl ciphers -tls1更贴近真实攻击者视角。
5. 巡检避坑指南：5条血泪教训换来的硬核参数与边界条件
巡检不是技术堆砌，而是对现实约束的精密妥协。以下5条是我踩过最深的坑，每条都附带可直接抄作业的参数修正方案。
5.1 现象：Nmap扫描Web服务时大量返回“403 Forbidden”，但人工访问正常
原因：Nmap默认User-Agent被WAF识别为扫描器，触发拦截规则（如Cloudflare的Security Level=High）。
解决：强制指定合法UA并添加随机延时：
nmap -p 80,443 --script http-title,http-headers \ --script-args http.useragent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \ --max-rate 1 --min-parallelism 1 example.com关键参数：
--max-rate 1限制每秒1个包，--min-parallelism 1禁用并发，模拟人类访问节奏；http.useragent必须与主流浏览器完全一致，不能简写。
5.2 现象：Windows服务器巡检脚本在PowerShell 5.1下报错“Get-NetIPAddress: 找不到命令”
原因：Get-NetIPAddress是PowerShell 4.0+命令，但部分老旧服务器仍运行PowerShell 2.0。
解决：脚本开头强制检测并降级：
# check_network.ps1 if ($PSVersionTable.PSVersion.Major -lt 3) { Write-Error "PowerShell 3.0+ required. Current: $($PSVersionTable.PSVersion)" exit 1 } # 使用兼容性更强的命令 $ipConfig = ipconfig | Select-String "IPv4"5.3 现象：Linux巡检脚本在CentOS 6上执行systemctl is-active报错“command not found”
原因：CentOS 6使用SysV init，systemctl不存在。
解决：用service命令兜底：
# 检查SSH服务状态（兼容CentOS 6/7/8） if command -v systemctl &> /dev/null; then systemctl is-active --quiet sshd && echo "SSHD active" || echo "SSHD inactive" else service sshd status | grep -q "running" && echo "SSHD active" || echo "SSHD inactive" fi5.4 现象：数据库巡检时mysqldump导出报错“Access denied for user 'root'@'localhost'”
原因：MySQL 5.7+默认启用sql_mode=STRICT_TRANS_TABLES，且root用户密码认证插件变为caching_sha2_password。
解决：创建专用巡检用户并指定插件：
CREATE USER 'inspector'@'localhost' IDENTIFIED WITH mysql_native_password BY 'InsP@ss2024!'; GRANT SELECT ON *.* TO 'inspector'@'localhost'; FLUSH PRIVILEGES;注意：必须用
mysql_native_password插件，caching_sha2_password在旧版客户端中不被支持。
5.5 现象：巡检报告PDF生成时中文乱码，显示为方框
原因：wkhtmltopdf默认字体不支持中文，且未指定字体路径。
解决：下载思源黑体并配置：
# 下载字体 wget https://github.com/adobe-fonts/source-han-sans/releases/download/2.004R/SourceHanSansSC.zip unzip SourceHanSansSC.zip -d /usr/share/fonts/opentype/ fc-cache -fv # 生成PDF时指定字体 wkhtmltopdf --enable-local-file-access \ --page-size A4 \ --margin-top 10mm --margin-bottom 10mm \ --header-html header.html --footer-html footer.html \ --font-family "Source Han Sans SC" \ report.html report.pdf6. 让巡检真正落地的3个关键技巧：从“做了”到“管用”的最后一公里
巡检的价值不在于报告厚度，而在于它能否成为安全运营的“神经末梢”。我坚持三个技巧，让每次巡检都变成防御能力的真实增量。
6.1 把巡检项转化为“攻击者视角检查表”，倒逼防御有效性
我从不直接抄等保2.0条款，而是先问：“如果我是攻击者，会怎么利用这个漏洞？”然后反向设计检查项。例如等保要求“应采用校验技术保证重要数据在传输过程中的完整性”，这太抽象。我的检查表是：
- ✅ 对所有API接口，抓包分析HTTP响应头是否含
Content-Security-Policy且upgrade-insecure-requests启用； - ✅ 对文件上传功能，上传
.htaccess文件，验证是否被重命名或拦截； - ✅ 对JWT令牌，用
jwt.io解码，检查alg字段是否为HS256且密钥未硬编码在前端。
为什么有效：这种检查表直接映射ATT&CK战术（T1566钓鱼、T1190漏洞利用），让巡检结果能无缝输入威胁建模流程。去年某政务云项目，正是靠这条检查表提前发现OAuth回调地址未校验，阻断了CSRF令牌劫持链。
6.2 用“巡检-处置-验证”三阶段时间戳，构建不可抵赖的审计证据链
审计最怕“你说你做了”。我们的解决方案是：每台设备巡检时，自动生成带时间戳的三段式证据：
- 巡检时刻：
date "+%Y-%m-%d %H:%M:%S.%3N"+hostname+uname -r； - 处置时刻：执行修复命令前，
echo "$(date '+%Y-%m-%d %H:%M:%S') [DISPATCH] $(whoami) applied patch"； - 验证时刻：
curl -sI https://target/health | grep "HTTP/2 200"+date。
所有日志写入/var/log/sec-inspect/，并用logrotate每日归档。当监管问询时，直接提供/var/log/sec-inspect/20240515.log.gz，解压后三段时间戳天然形成证据闭环。
6.3 建立“巡检健康度仪表盘”，用数据驱动资源投入
我坚持每月统计三个核心指标，画成折线图贴在团队墙上：
- 覆盖率：已巡检资产数 / 总资产数（目标≥95%）；
- 闭环率：已处置高危项数 / 当期发现高危项数（目标100%）；
- 平均修复时长：从巡检发现到验证通过的小时数（目标≤4h）。
真实案例：当发现“平均修复时长”从3.2h升至6.8h时，我们没怪运维慢，而是查出根本原因是Jira工单审批流卡在二级经理环节。砍掉该环节后，时长回落至2.1h。数据不会说谎，它只告诉你哪里该动刀。
最后说句实在话：我见过太多团队把巡检做成“安全部的事”，结果漏洞在运维手里躺了三个月。真正的巡检，是让每个接触系统的人都成为防御节点——开发提交代码时自动触发基线检查，运维重启服务时强制校验配置哈希，甚至保洁阿姨拔掉测试网线都会触发告警。这份《网络与信息安全巡检工作内容 (2).docx》不是终点，而是你把防御能力刻进组织DNA的第一道刻痕。希望帮到你。
本文还有配套的精品资源，点击获取
