校园网安全巡检实战：日志留存、弱口令排查与终端抽查指南

简介：这份文档面向中小学、幼儿园、职校及其他教育单位的信息安全负责人与网络管理员，围绕教育系统网络与信息安全巡检的实际工作展开，帮助读者理清巡检流程、检查要点与整改方向。内容涵盖巡检计划安排、重要设备日志备份、数据备份方式核查、应用服务器与终端安全检测、运营商出口排查以及网络与安全硬件设备弱口令检查等模块，并延伸至杀毒软件部署与堡垒机权限分配等附加安全措施，具有较强的实操参考价值。资源包内含1个docx文档，压缩包约15KB，体积轻便，便于快速查阅与打印使用。目前已有542人学习下载，适合需要落实网络安全法日志留存要求、开展日常安全自查或准备迎检的教育单位技术人员参考借鉴。

1. 一份巡检清单背后的真实战场：从日志留存到弱口令排查

很多做校园网运维的老师拿到这份《网络与信息安全巡检工作内容》时，第一反应是“又来检查了”。但如果你仔细拆开这份文档，会发现它其实是一份非常典型的、可以直接复用的安全巡检作业指导书。它覆盖了日志留存、数据备份、应用服务器安全检测、终端抽查、运营商出口梳理、网络与安全硬件设备弱口令排查六大块，外加杀毒软件部署和堡垒机权限分配两项附加措施。换句话说，这是一份从“查什么”到“怎么改”的完整闭环文档。适合谁用？中小学、幼儿园、职校的信息安全负责人和网络管理员，尤其是那些没有专职安全团队、需要一个人扛起整张网的单位。它解决的核心问题是：在有限的人力和预算下，如何按照合规要求把安全巡检做到位，并且留下可追溯的记录。接下来我会按这份文档的实际执行逻辑，把每个环节拆成能直接抄作业的步骤，顺便把我在类似巡检中踩过的坑一并说清楚。

2. 日志留存与数据备份：合规底线怎么查、怎么补

2.1 日志留存不少于六个月，具体怎么落地

《网络安全法》第二十一条第三项明确要求“采取监测、记录网络运行状态、网络安全事件的技术措施，并按照规定留存相关的网络日志不少于六个月”。这份巡检文档把“防火墙”“应用服务器”“安全设备”及其他重要设备的日志留存作为第一项检查内容，说明它是合规检查的硬指标。但实际操作中，很多学校的设备日志默认只存一周甚至更短，巡检时一查就露馅。

我一般会按下面这个顺序去核实和整改。先确认设备是否开启了日志功能，再确认日志存储位置和保留周期，最后确认日志是否可读、可导出。

# 以常见Linux应用服务器为例，检查rsyslog服务状态和日志保留配置 systemctl status rsyslog # 查看日志文件的实际保留情况，确认是否有轮转策略 ls -lh /var/log/messages* /var/log/secure* # 检查logrotate配置，确认保留周期 cat /etc/logrotate.conf | grep -E "rotate|weekly|monthly"

上面这段命令的逻辑是：先确认日志服务在运行，再查看日志文件的实际存在情况，最后检查轮转配置。参数上重点看rotate后面的数字，它代表保留多少个轮转周期。如果配置是rotate 4且weekly，那实际只保留约一个月，远达不到六个月的要求。常见做法是改成monthly配合rotate 6，或者直接配置远程日志服务器，把日志集中存储。

对于防火墙和安全设备，多数品牌在Web管理界面里有“日志配置”或“日志存储”选项，需要手动把存储周期调到180天以上。如果设备本身存储空间不够，就得配置syslog服务器外发。这里有个血泪经验：调完周期后一定要重启日志服务或者设备，否则配置不生效的情况我遇到过不止一次。

提示：巡检时不要只看配置页面显示的数字，一定要实际翻一下最早的那条日志日期，确认真的存了那么久。

2.2 数据备份检查：完全、增量、差异三种方式怎么区分和验证

文档里明确要求“请提供数据备份方式（完全备份、增量备份、差异备份）及证明”。这句话的关键词是“及证明”——不是问你有没有备份，而是让你拿出证据。很多管理员口头说“每天都有备份”，但一问备份文件在哪、最近一次恢复测试是什么时候，就答不上来了。

先把这个概念理清楚，因为巡检时经常发现有人把增量当差异用。完全备份是每次都把全部数据备一份；增量备份是只备上次备份后变化的数据；差异备份是备上次完全备份后变化的数据。三者的恢复链条完全不同：完全备份直接恢复；增量备份需要“完全+所有增量”按顺序恢复；差异备份只需要“完全+最近一次差异”。

验证备份是否有效，我一般会走这三步：

# 第一步：确认备份任务是否在计划任务中正常运行 crontab -l | grep -i backup # 第二步：查看备份文件的实际大小和修改时间，确认不是空文件 ls -lh /backup/full/ /backup/incremental/ 2>/dev/null # 第三步：抽样验证备份文件的完整性（以tar包为例） tar -tzf /backup/full/backup_20241201.tar.gz | head -20

第一步是确认备份任务没有被禁用或报错；第二步是看文件大小是否合理，如果增量备份文件大小和完全备份差不多，那说明备份策略配置有问题；第三步是实际列出备份内容，确认文件没有损坏。参数上注意tar -tzf只是列出内容不解压，对生产环境没有影响，适合巡检时快速验证。

如果单位用的是Windows Server自带的备份工具或者第三方备份软件，验证逻辑类似：找到备份计划、查看最近一次执行结果、抽样恢复一个文件到临时目录。文档里说的“证明”，其实就是这些操作记录和截图。我习惯在巡检时直接让管理员现场恢复一个文件，比看任何报告都管用。

3. 应用服务器安全检测：从弱口令到Webshell的排查路径

3.1 默认账号、弱口令与远程登录端口排查

文档里列的第一条就是“应用服务器是否使用默认出厂账号、弱口令等行为，如账号为‘admin’、‘administrator’等，如存在需要现场修改”。这条看起来简单，但实际巡检中招率极高。很多应用系统的后台管理员账号就是admin配admin123，甚至有些设备出厂后从来没改过。

排查思路分三层：先查系统层账号，再查应用层账号，最后查远程登录端口。系统层用命令直接看：

# 查看Linux系统所有可登录账号 cat /etc/passwd | grep -E "/bin/bash|/bin/sh" # 检查是否存在空口令账号 sudo awk -F: '($2 == "") {print $1}' /etc/shadow # 查看当前监听的高危端口，重点关注3389、22、1433、3306等 ss -tlnp | grep -E ":3389|:22|:1433|:3306|:6379|:27017"

第一段命令列出所有能登录shell的账号，重点看有没有多余的、不认识的管理账号。第二段是检查空口令账号，这是最危险的情况。第三段是看端口监听情况，文档里特别提到3389远程登录和高危端口是否关闭。如果服务器不需要远程桌面，3389就应该关掉；如果必须用，至少要限制来源IP。

应用层账号的排查没有统一命令，需要登录每个应用系统的管理后台去看。常见做法是：先问清楚这个系统是谁在维护、管理账号有哪些人知道，然后逐个检查账号列表，把不用的账号禁用或删除。这里有个坑：有些系统删了账号会导致关联数据丢失，所以禁用比删除更稳妥。

注意：现场修改弱口令时，一定要先确认修改后不会影响业务系统的正常运行。我遇到过改完数据库密码后应用连不上的情况，后悔药可没地方买。

3.2 Webshell、木马与信息泄露的现场排查

文档里列了一长串入侵类风险：Web入侵类的挂马、Webshell，系统入侵类的异常、RDP爆破、SSH爆破、主机漏洞，病毒木马类的远程控制、系统后门、勒索软件、挖矿病毒，还有信息泄露类的脱裤和数据库弱口令登录。这些不可能在巡检现场全部深度排查，但有几个快速检查点可以覆盖大部分明显问题。

# 检查最近登录失败记录，看是否有暴力破解痕迹 sudo lastb | head -30 # 检查异常的网络连接，重点关注ESTABLISHED状态的外部IP ss -tnp state established | grep -v "127.0.0.1" # 查找最近24小时内被修改过的Web目录文件（以常见路径为例） find /var/www -type f -mtime -1 -name "*.php" -o -name "*.jsp" -o -name "*.aspx" 2>/dev/null # 检查计划任务中是否有异常条目 sudo crontab -l ls -la /etc/cron.d/ /etc/cron.daily/

第一段看暴力破解痕迹，如果lastb输出里有大量来自同一IP的失败记录，说明服务器正在被爆破。第二段看当前活跃的外部连接，如果发现服务器主动连向陌生IP，可能是被植入了远程控制程序。第三段是查找最近被修改的Web文件，Webshell通常会修改或新增文件。第四段是检查计划任务，挖矿病毒和勒索软件经常通过计划任务维持运行。

参数上-mtime -1表示一天内修改过的文件，巡检时可以根据需要改成-mtime -7看一周内的变化。find命令里的-o是逻辑或，表示匹配任意一种后缀。这些命令的输出需要结合业务实际判断，比如正常的网站更新也会修改文件，所以重点看那些在非工作时间被修改的、或者文件名异常的条目。

对于数据库弱口令和信息泄露，最直接的办法是尝试用常见弱口令连接数据库，但这一步必须在获得授权的前提下进行。文档里说的“根据现场实际情况将出具相关报告，进行整改”，意思就是巡检人员会记录问题但不一定现场深挖，后续出报告再跟进。

4. 终端抽查与网络设备排查：5台机器的抽样逻辑

4.1 终端安全抽查：为什么是5台、怎么选

文档里明确写了“终端安全以抽查方式（数量5台）”，检查内容包括默认账号或弱口令、3389远程登录是否关闭、高危端口是否关闭、杀毒软件是否安装。5台这个数字不是随便定的，它是在巡检时间和覆盖面之间取的平衡点。选哪5台有讲究：我一般会选财务、教务、门卫、机房、校长办公室这五个位置，因为它们分别代表了高价值数据、日常办公、对外接触、核心设备和决策层，覆盖了不同类型的风险场景。

检查步骤可以标准化成一张表，现场逐台过：

在Windows终端上，可以用一条命令快速拉出关键信息：

# 查看本地用户和端口监听情况 Get-LocalUser | Select-Object Name, Enabled, PasswordLastSet Get-NetTCPConnection -State Listen | Where-Object {$_.LocalPort -in 3389,135,139,445} | Select-Object LocalAddress, LocalPort, OwningProcess

第一段列出所有本地用户及其启用状态和密码最后修改时间，如果某个账号的PasswordLastSet是几年前，基本可以判定是弱口令或默认口令。第二段筛选出3389、135、139、445这几个高危端口的监听情况，有输出就说明端口开着，需要进一步确认是否必要。

提示：抽查时最好让终端使用人在场，现场问一下电脑平时谁在用、有没有装过不明软件，比单纯看配置更能发现问题。

4.2 网络与安全硬件设备：弱口令是重灾区

文档里对网络硬件设备和安全硬件设备的检查“主要以弱口令为主”，这个定位非常准确。交换机的admin/admin、防火墙的admin/admin123、路由器的默认密码，这些在校园网里太常见了。而且很多设备买来之后就没改过密码，因为改密码需要登录Web界面或者console口，有些管理员嫌麻烦就一直拖着。

排查方法按设备类型分。交换机如果支持SSH，可以直接登录后查看用户配置；如果不支持，就得通过console线连上去看。防火墙和路由器一般都有Web管理界面，登录后找“系统管理”或“用户管理”里的账号列表。我一般会准备一份常见设备默认口令表，巡检时逐个试——当然这是在获得授权的前提下。

# 以华为交换机为例，查看本地用户配置 display local-user # 查看当前登录用户 display users # 以H3C防火墙为例，查看管理员账号 display local-user

这些命令的输出重点看用户名和权限级别。如果看到admin账号且权限是最高级，同时密码从没改过，那就是必须现场整改的问题。整改时注意：改完密码后要确认所有依赖这个账号的运维脚本或监控系统不会断，否则改了密码反而导致监控失效。

文档里还提到“各单位是否存在自行接入外网的状况，如存在，请提供运营商名称”。这一条容易被忽略，但它是网络边界清晰化的关键。有些学校因为业务需要自己拉了一条宽带，但没有跟信息中心报备，导致网络拓扑出现计划外的出口。巡检时如果发现这种情况，记录运营商名称和接入方式就行，不需要现场处理，但后续要纳入统一管理。

5. 附加安全措施与避坑指南：杀毒部署、堡垒机与常见翻车现场

5.1 企业级杀毒软件部署与堡垒机权限分配

文档里的附加安全措施有两项：一是虹口教育信息中心提供企业级杀毒软件，由巡检工程师现场安装、扫描、调试防护策略；二是把应用服务器加入堡垒机，实现身份认证、授权管理和运维审计。这两项的价值在于把分散的安全能力集中起来，但落地时有几个关键点。

杀毒软件部署不是点一下“下一步”就完事。现场安装前要先确认服务器上有没有已经装了的其他杀毒软件，如果有，必须先卸载干净再装新的，否则两个杀毒软件互相打架导致服务器卡死的情况我见过不止一次。安装完成后要立即更新病毒库，然后跑一次全盘扫描。扫描时间要避开业务高峰期，否则CPU和磁盘IO被占满，业务系统响应会明显变慢。

堡垒机的核心价值是“事中控制、事后审计”。把应用服务器加入堡垒机后，所有运维操作都要经过堡垒机跳转，操作过程会被录屏或记录命令日志。配置时要注意：先建好用户和角色，再分配服务器权限，最后测试连接。常见坑是堡垒机本身的高可用没做，堡垒机一挂所有服务器都登不上去，所以如果条件允许，堡垒机最好做双机热备。

5.2 巡检避坑：五条血泪经验

现象一：日志配置改了但没生效。原因：很多设备修改日志存储周期后需要重启日志服务或设备本身，只保存配置不重启等于没改。解决：改完配置后执行重启操作，然后实际查看最早日志日期确认。

现象二：弱口令改了导致业务中断。原因：应用系统、数据库、中间件之间用同一套账号密码，改了其中一个没同步改其他的。解决：改密码前先梳理账号依赖关系，改完后立即测试业务功能，最好在业务低峰期操作。

现象三：终端抽查时发现杀毒软件装了但病毒库是半年前的。原因：杀毒软件装了之后没人管，自动更新被禁用或更新服务器连不上。解决：检查更新配置，确保病毒库能自动更新，巡检时把病毒库日期作为必查项。

现象四：堡垒机加入服务器后运维人员抱怨操作卡顿。原因：堡垒机的录屏功能占用资源较大，或者网络链路质量差。解决：调整录屏策略，对普通操作只记录命令不录屏，关键操作才开录屏；同时检查堡垒机到服务器的网络延迟。

现象五：数据备份文件存在但恢复不出来。原因：备份时没有做完整性校验，或者备份文件被加密但密钥丢失。解决：每次备份后抽样验证，定期做恢复演练，备份密钥单独保管。

6. 把巡检做成可复用的检查脚本：一个偷懒但有效的习惯

巡检做了几年之后，我最大的教训是：靠脑子记检查项一定会漏。后来我养成了一个习惯，把每次巡检的检查项写成一个脚本，现场跑一遍，输出结果直接贴进报告。这样既不会漏项，又能留下标准化的记录。下面这个脚本框架覆盖了文档里的大部分检查点，可以根据实际环境调整。

#!/bin/bash # 安全巡检快速检查脚本 # 用法：bash security_check.sh > check_result_$(date +%Y%m%d).txt echo "===== 巡检时间: $(date) =====" echo "" echo "----- 1. 系统账号检查 -----" echo "可登录账号列表：" cat /etc/passwd | grep -E "/bin/bash|/bin/sh" echo "空口令账号检查（无输出为正常）：" sudo awk -F: '($2 == "") {print $1}' /etc/shadow echo "" echo "----- 2. 高危端口检查 -----" echo "当前监听的高危端口：" ss -tlnp | grep -E ":3389|:22|:1433|:3306|:6379|:27017" || echo "未发现高危端口监听" echo "" echo "----- 3. 日志保留检查 -----" echo "日志轮转配置：" grep -E "rotate|weekly|monthly" /etc/logrotate.conf 2>/dev/null || echo "未找到logrotate配置" echo "最早日志文件：" ls -lht /var/log/messages* 2>/dev/null | tail -3 echo "" echo "----- 4. 异常登录检查 -----" echo "最近失败登录记录（前10条）：" sudo lastb 2>/dev/null | head -10 || echo "无失败登录记录或权限不足" echo "" echo "----- 5. 计划任务检查 -----" echo "当前用户计划任务：" crontab -l 2>/dev/null || echo "无计划任务" echo "系统级计划任务目录：" ls -la /etc/cron.d/ /etc/cron.daily/ 2>/dev/null echo "" echo "===== 检查完成 ====="

这个脚本的逻辑是按巡检文档的检查项顺序组织的，每一段对应一个检查维度。参数上没有什么复杂的，关键是sudo权限要提前配好，否则lastb和/etc/shadow读不了。输出重定向到带日期的文件里，巡检完直接把文件附在报告后面，比手写记录靠谱得多。

脚本不是万能的，它只能覆盖系统层的检查，应用层和网络设备还是得手动看。但它的价值在于把重复劳动标准化，让你有更多精力去处理真正需要判断的问题。我现在的习惯是：每次巡检前先把脚本跑一遍，把输出结果作为基线，然后带着基线去现场核对，发现异常就重点查。从那以后我每次做巡检都强制走一遍脚本加现场核对的流程，漏项的情况基本没有了。希望帮到你。

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