网络与信息安全巡检实战：从清单到自动化脚本的落地指南

简介：这份文档面向中小学、幼儿园、职校及其他教育单位的信息安全负责人与网络管理员，围绕教育系统网络与信息安全巡检工作展开，帮助读者理清巡检流程、检查要点与整改方向。内容涵盖巡检计划安排、重要设备日志备份、数据备份方式、应用服务器与终端安全检测、运营商出口核查、网络与安全硬件设备弱口令排查等模块，并延伸至杀毒软件部署与堡垒机权限分配等附加安全措施，可作为校园网络安全自查与迎检的参考模板。资源包共1个docx文件，约15KB，结构紧凑、便于按章节查阅。目前已有542人学习下载，适合需要落实网络安全法日志留存要求、规范日常运维与应急整改的教育行业从业者参考使用。

1. 网络与信息安全巡检到底在巡什么：从一份 docx 清单说起

很多人第一次拿到「网络与信息安全巡检工作内容」这种文档时，会下意识把它当成一份打勾表：登录几台设备、看看 CPU、截几张图，一天就过去了。真到出事那天才发现，巡检记录里全是「正常」，可日志早就断了三个月，备份任务失败了半年没人管，应用服务器的中间件版本还停在两年前。巡检不是仪式，它是一套用固定动作提前暴露风险的机制。这份清单通常覆盖四块：网络设备与链路、安全设备与策略、服务器与中间件、日志与数据备份。它适合运维、安全管理员、等保整改负责人，也适合刚接手机房、需要把「口头巡检」变成「可追溯记录」的工程师。下面我按真实落地顺序，把这份 docx 拆成能直接抄的巡检方案。

2. 巡检清单怎么拆成可执行项：从设备到日志的四个维度

2.1 网络与安全设备巡检：先定对象再定指标

巡检翻车的头号原因不是技术难，而是对象没定清楚。我一般先把资产分成三类：网络设备（交换机、路由器、防火墙）、安全设备（WAF、IDS、堡垒机）、服务器（物理机、虚拟机、应用服务器）。每一类只盯它最容易出问题的指标，不要贪多。

网络设备看四个数：端口 up/down 状态、光模块收发光功率、CPU 与内存、接口错包和丢包计数。安全设备看策略命中数、会话表使用率、特征库版本、HA 状态。服务器看磁盘使用率、inode、负载、关键进程、监听端口。把这些写成表格，巡检才有落点。

这张表的价值在于：它把「巡检工作内容」翻译成了可采集、可判断的字段。没有阈值，巡检记录就只是数字堆砌，没人知道该不该处理。

2.2 日志备份巡检：断流比报错更可怕

日志备份是巡检里最容易被糊弄的一环。很多人只看「日志服务在跑」，不看「日志有没有真的写进去」。我踩过的坑是：日志采集 agent 进程活着，但输出目录权限被改，日志写不进去，监控却显示绿色。

巡检日志要查三件事：采集端进程与心跳、传输链路是否通、存储端是否有新数据落盘。最直接的办法是查最近一条日志的时间戳，和当前时间比对。超过阈值就告警。

# 检查日志目录最近文件时间，判断是否断流 LOG_DIR="/data/logs/app" LATEST=$(find "$LOG_DIR" -type f -name "*.log" -printf '%T@ %p\n' | sort -n | tail -1) LATEST_TS=$(echo "$LATEST" | awk '{print $1}') NOW_TS=$(date +%s) DIFF=$(( (NOW_TS - ${LATEST_TS%.*}) / 60 )) echo "最近日志文件: $(echo "$LATEST" | awk '{print $2}')" echo "距今 ${DIFF} 分钟" if [ "$DIFF" -gt 60 ]; then echo "CRITICAL: 日志可能断流超过 60 分钟" fi

这段脚本的逻辑很直白：找到目录下最新修改的日志文件，算出它距今多少分钟。参数LOG_DIR按实际路径改，阈值 60 分钟按业务日志频率调整——高频交易系统可能 5 分钟就算断流，后台管理系统 60 分钟可以接受。注意find的-printf在部分精简系统上不支持，可以换成stat逐文件取时间。

日志巡检还要看轮转策略。见过一台应用服务器因为 logrotate 配置写错，日志文件涨到 200G 把磁盘打满，业务直接挂掉。巡检时顺手看一眼/etc/logrotate.d/下对应配置和最近轮转时间，能省一次半夜救火。

2.3 数据备份巡检：备份成功不等于能恢复

数据备份巡检的核心不是「任务成功」，而是「可恢复」。我见过备份任务天天成功，恢复时发现备份文件是空的，因为备份脚本只打包了目录结构没打包数据。巡检备份要查四层：任务状态、备份文件大小与数量、备份介质剩余空间、恢复演练记录。

import os import time BACKUP_DIR = "/backup/db" MIN_SIZE_MB = 100 # 单份备份最小期望大小 MAX_AGE_HOURS = 26 # 超过 26 小时视为过期 now = time.time() issues = [] files = [f for f in os.listdir(BACKUP_DIR) if f.endswith(".bak")] if not files: issues.append("备份目录中没有 .bak 文件") for f in files: path = os.path.join(BACKUP_DIR, f) size_mb = os.path.getsize(path) / 1024 / 1024 age_h = (now - os.path.getmtime(path)) / 3600 if size_mb < MIN_SIZE_MB: issues.append(f"{f} 大小仅 {size_mb:.1f}MB，低于阈值") if age_h > MAX_AGE_HOURS: issues.append(f"{f} 已 {age_h:.1f} 小时未更新") if issues: print("备份巡检异常:") for i in issues: print(" -", i) else: print("备份巡检正常")

参数说明：MIN_SIZE_MB要根据数据库实际体量设，设太小等于没设；MAX_AGE_HOURS按备份频率加缓冲，日备设 26 小时合理。这段脚本只做静态检查，真正靠谱的做法是每月做一次恢复演练，把备份文件恢复到测试库并跑一致性校验。没有恢复演练的备份，只能算心理安慰。

2.4 应用服务器安全巡检：版本、账号、端口三件套

应用服务器是攻击面最集中的地方。巡检时我固定查三样：中间件与框架版本、系统账号与权限、对外监听端口。版本查有没有已知高危漏洞，账号查有没有多余的管理员和空密码，端口查有没有计划外开放。

# 应用服务器安全巡检基础采集 echo "=== 监听端口 ===" ss -tulnp | grep LISTEN echo "=== 可登录账号 ===" awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd echo "=== 关键中间件版本 ===" # 以 Tomcat 为例，按实际路径调整 CATALINA_HOME="/opt/tomcat" if [ -f "$CATALINA_HOME/RELEASE-NOTES" ]; then grep -m1 "Apache Tomcat Version" "$CATALINA_HOME/RELEASE-NOTES" fi

这段采集脚本输出三块信息，人工比对基线。ss -tulnp需要 root 或 sudo 才能看到进程名。账号检查里$7是登录 shell，过滤掉 nologin 和 false 后剩下的就是可登录账号，重点看有没有非预期账号。中间件版本要对照官方安全公告，这一步没法自动化，但可以定期人工过一遍。

3. 用 Python 把巡检做成可重复执行的脚本

3.1 巡检脚本的整体结构：采集、判断、输出

手工巡检最大的问题是不可重复、不可追溯。我一般用 Python 写一个巡检框架，分三层：采集层负责连设备、跑命令、读文件；判断层负责比对阈值和基线；输出层负责生成 Excel 或 JSON 报告。这样换一个环境只需要改采集层的连接参数。

import subprocess import json from datetime import datetime def run_cmd(cmd): """执行 shell 命令并返回输出，失败返回错误信息""" try: result = subprocess.run( cmd, shell=True, capture_output=True, text=True, timeout=30 ) return result.stdout.strip() or result.stderr.strip() except subprocess.TimeoutExpired: return "TIMEOUT" def collect_disk(): """采集磁盘使用率，返回超过阈值的挂载点""" out = run_cmd("df -hP | awk 'NR>1 {print $5, $6}'") alerts = [] for line in out.splitlines(): parts = line.split() if len(parts) != 2: continue usage, mount = parts pct = int(usage.replace("%", "")) if pct >= 85: alerts.append({"mount": mount, "usage": pct}) return alerts def build_report(): report = { "time": datetime.now().strftime("%Y-%m-%d %H:%M:%S"), "disk_alerts": collect_disk(), } return report if __name__ == "__main__": print(json.dumps(build_report(), ensure_ascii=False, indent=2))

逻辑说明：run_cmd统一封装命令执行，加 30 秒超时防止卡死。collect_disk用df -hP的 POSIX 输出格式，避免不同系统列对齐差异。阈值 85% 写在判断层，后续可以抽到配置文件。输出 JSON 方便对接监控平台，也可以换成 openpyxl 写 Excel。

3.2 输出 Excel 巡检报告：字段设计与合并策略

很多单位要求巡检输出 Excel，方便归档和签字。用 openpyxl 写报告时，字段设计比代码更重要。我一般分两个 sheet：汇总页放巡检时间、总体结论、异常数量；明细页放每台设备每个指标的实测值和判断结果。

from openpyxl import Workbook from openpyxl.styles import Font, PatternFill def write_excel(report, path="inspection.xlsx"): wb = Workbook() ws = wb.active ws.title = "巡检汇总" headers = ["检查项", "对象", "实测值", "阈值", "结论"] ws.append(headers) for cell in ws[1]: cell.font = Font(bold=True) cell.fill = PatternFill("solid", fgColor="D9E1F2") for alert in report.get("disk_alerts", []): ws.append(["磁盘使用率", alert["mount"], f"{alert['usage']}%", "85%", "异常"]) if not report.get("disk_alerts"): ws.append(["磁盘使用率", "全部挂载点", "正常", "85%", "正常"]) wb.save(path) print(f"报告已生成: {path}")

参数说明：PatternFill的颜色按单位模板改，headers顺序要和归档要求一致。异常行建议加红色字体，方便快速定位。注意 openpyxl 写大文件时内存占用高，巡检对象超过 500 台建议分文件写。

3.3 定时执行与结果归档：cron 与保留策略

巡检脚本写完不意味着结束，要让它定时跑、结果可追溯。Linux 下用 cron，Windows 下用计划任务。cron 表达式按巡检频率设，日巡检一般凌晨低峰期执行。

# 每天 02:30 执行巡检，报告按日期归档 30 2 * * * /usr/bin/python3 /opt/inspect/run_inspect.py >> /var/log/inspect/cron.log 2>&1

归档策略要定保留天数，否则报告会把磁盘吃满。我一般保留 90 天，用 find 清理过期文件：

# 清理 90 天前的巡检报告 find /opt/inspect/reports -name "*.xlsx" -mtime +90 -delete

注意 cron 环境变量和交互式 shell 不同，脚本里尽量用绝对路径，Python 解释器路径也要写全。日志重定向到文件，方便排查脚本本身失败的原因。

4. 巡检落地避坑：五条血泪经验

4.1 现象：巡检全绿但故障频发

原因：巡检项只覆盖了「设备活着」，没覆盖「业务可用」。比如交换机端口 up，但上联链路丢包 30%；备份任务成功，但备份文件损坏。

解决：每个巡检项都要有业务视角的验证。端口 up 之外加错包和丢包检查，备份成功之外加文件大小和恢复演练。巡检结论要能回答「业务现在能不能正常跑」。

4.2 现象：脚本在测试环境正常，生产环境报错

原因：生产环境的命令版本、权限、路径和测试环境不一致。比如ss命令在旧系统上是netstat，find -printf在 BusyBox 上不支持。

解决：脚本里对关键命令做兼容判断，或者统一用 POSIX 兼容写法。上线前在目标环境的最小权限账号下跑一遍，不要用 root 跑通就以为没问题。

4.3 现象：巡检报告没人看，异常没人处理

原因：报告只发邮件，没有闭环流程。异常项没有责任人、没有处理时限、没有复查机制。

解决：巡检报告要带异常清单和责任人字段，异常项进入工单系统跟踪。下次巡检自动复查上次异常是否关闭，没关闭的升级提醒。

4.4 现象：日志备份巡检通过，恢复时发现日志缺失

原因：巡检只查了日志文件存在，没查日志内容完整性。比如采集 agent 重启后丢了中间一段日志，文件还在但内容有断档。

解决：巡检时抽查日志时间戳连续性，或者用日志平台的采集延迟指标。关键系统要求日志平台有断点续传和完整性校验。

4.5 现象：应用服务器巡检漏掉中间件配置

原因：巡检只查了版本和端口，没查配置文件里的危险项。比如 Tomcat 开启了目录浏览、Nginx 配置了不安全的 CORS、数据库连接串里明文密码。

解决：把中间件安全配置基线纳入巡检，定期比对配置文件哈希或关键字段。基线变更要走审批，巡检发现偏离要告警。

5. 让巡检从「做完」变成「有用」：一个验证技巧

巡检做得好不好，不看报告多漂亮，看两件事：一是异常发现率，二是异常闭环率。我习惯每月做一次「盲测」：故意在一个非核心环境制造一个已知问题，比如停掉一个日志采集进程、改小一个备份文件、开放一个非预期端口，然后看巡检脚本能不能在下一个周期抓到。抓不到，说明巡检项有盲区；抓到了但没人处理，说明流程有问题。

这个盲测方法比看报告有用得多。它逼着你从「我巡了」转向「我巡到了」。另外，巡检项不是越多越好。我见过一份巡检表有 200 多项，执行一次要半天，最后大家只挑简单的打勾。巡检项要按风险排序，高危项必须查，低危项可以抽样。把有限的巡检时间花在真正会出事的地方。

我自己的习惯是：每次巡检后花十分钟看异常项的根因，如果是巡检项设计问题就改脚本，如果是流程问题就推动闭环。巡检不是交差，是给自己留后悔药。希望帮到你。

本文还有配套的精品资源，点击获取