简介这份文档面向中小学、幼儿园、职校及其他教育单位的信息安全负责人与网络管理员围绕教育系统网络与信息安全巡检的实际工作展开帮助读者理清巡检流程、检查要点与整改方向。内容涵盖巡检计划安排、重要设备日志备份、数据备份方式核查、应用服务器与终端安全检测、运营商出口排查以及网络与安全硬件设备弱口令检查等模块并延伸至杀毒软件部署与堡垒机权限分配等附加安全措施具有较强的实操参考价值。资源包内含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台有讲究我一般会选财务、教务、门卫、机房、校长办公室这五个位置因为它们分别代表了高价值数据、日常办公、对外接触、核心设备和决策层覆盖了不同类型的风险场景。检查步骤可以标准化成一张表现场逐台过检查项检查方法合格标准默认账号/弱口令控制面板→用户账户或net user命令无admin/administrator类账号密码长度≥8位含大小写和数字3389远程登录netstat -ano | findstr :3389无监听或已限制来源IP高危端口netstat -ano查看监听端口135/139/445等非必要端口已关闭杀毒软件任务栏图标或安全中心已安装且病毒库为最新在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读不了。输出重定向到带日期的文件里巡检完直接把文件附在报告后面比手写记录靠谱得多。脚本不是万能的它只能覆盖系统层的检查应用层和网络设备还是得手动看。但它的价值在于把重复劳动标准化让你有更多精力去处理真正需要判断的问题。我现在的习惯是每次巡检前先把脚本跑一遍把输出结果作为基线然后带着基线去现场核对发现异常就重点查。从那以后我每次做巡检都强制走一遍脚本加现场核对的流程漏项的情况基本没有了。希望帮到你。本文还有配套的精品资源点击获取