简介电力监控系统作为关键信息基础设施其网络安全防护核心在于安全分区与纵向加密两大主线。生产控制大区与管理信息大区需严格隔离横向隔离装置控制数据单向流动纵向加密认证装置保障上下级调度通信的机密性与完整性。从等保2.0合规基线出发本文梳理了隔离装置配置、证书管理、主机加固及白名单落地要点并结合典型故障排查经验帮助工程师快速构建可落地的电力监控网络安全方案。1. 电力监控网络安全方案为什么安全分区和纵向加密是绕不开的两条主线做过电力监控系统集成或运维的人第一年基本都会被一件事折腾到——调度下令核查网络安全甲方把一摞整改要求扔过来说“下个月等保测评要进场你们把方案补上”。这里说的电力监控网络安全方案不是普通办公网的防火墙加杀毒软件而是围绕变电站监控系统、调度数据网、发电厂远动装置这一整套生产控制系统的安全设计落点永远是“安全分区、网络专用、横向隔离、纵向认证”这十六个字。本文我就按自己做过的真实项目路径把方案从合规基线拆到设备配置再拆到验证方法和踩坑记录给你一条能直接照着动手的路。2. 先看合规基线等保2.0三级与电监会36号文要求的差距分析2.1 电力监控系统安全防护的“十六字原则”怎么落地电力监控网络安全方案的第一件事不是买设备而是先分清你的系统在哪个区。生产控制大区和管理信息大区不能混生产控制大区内部还要再分控制区安全区Ⅰ和非控制区安全区Ⅱ。控制区里跑的是实时闭环业务比如远动、AGC/AVC、保护故障信息非控制区跑的是气象、水情、电量采集这类准实时业务。两个区间通信必须走横向隔离装置控制区数据往外发走正向隔离外部数据进来走反向隔离。我先讲一个真实的选型判断很多刚入行的人会把电力监控网络安全方案理解成“堆防火墙和IDS”其实在电力监控网络里横向隔离装置和纵向加密认证装置才是骨架。普通防火墙在三层以下做过滤而横向隔离装置在应用层做单向传输摆渡物理上只允许单向导通纵向加密认证装置则负责调度数据网上下级调度的隧道加密与身份认证。一句话防火墙解决的是“能不能访问”隔离和加密解决的是“是不是合法的生产数据在合法通道里跑”。2.2 用差距分析表把合规要求翻译成设备清单拿到一个站点我一般先做一张差距分析表把等保2.0三级通用要求加扩展要求、电监会36号文附件里的条款和现场实际对照逐条标状态。这张表不仅是给测评机构看的更是你后面做方案采购和施工的依据。检查项合规要求现场常见现状差距结论安全分区生产控制大区与管理信息大区物理隔离或逻辑隔离办公网与监控网共用交换机需划VLAN并在边界加横向隔离装置横向隔离控制区与非控制区之间部署经检测认证的隔离装置未部署或串接过期装置需新增正向/反向隔离装置纵向认证上下级调度间数据交换采用纵向加密认证装置部分链路裸跑需新增纵向加密认证装置主机加固最小化服务、加固账号口令、部署白名单远动主机开放SSH且口令弱需做安全基线加固并部署白名单入侵检测生产控制大区应部署入侵检测系统无需在核心交换机旁路部署IDS日志审计统一日志审计并留存6个月以上分散且时间不一致需部署日志审计平台统一NTP边界访问控制控制区与非控制区、上下级之间应设访问控制规则交换机三层直连需细化ACL或由隔离装置承担这张表做完方案骨架就出来了横向隔离装置、纵向加密认证装置、IDS、日志审计、主机加固与白名单管理五类设备。记住做电力监控网络安全方案顺序是先有分区边界再有边界设备最后才做主机加固反过来做边界没定主机加固做了也白做。2.3 用几条命令自查当前网络边界划分在出正式方案前我会先在现场用几条命令摸清现状避免被甲方的描述带偏。这三个命令可以最快暴露边界问题# 查看本机路由确认是否存在跨区直连路由 ip route show # 查看生产主机监听的端口确认是否对外开放了多余服务 ss -tlnp | head -50 # 跨区测试从控制区某主机ping管理信息区网关正常应不通 ping -c 3 192.168.x.x逻辑说明第一条命令看的是路由出口如果控制区主机有一条指向管理信息区的默认路由说明三层直连边界缺失这就是等保测评里最吃亏的一条第二条命令看的是主机对外暴露面很多远动装置会默认开着Telnet、FTP白名单加固之前先从这里摸底第三条命令是简单粗暴的隔离验证生产控制大区与管理信息大区之间正常情况下业务不应互通互通就说明边界部署无效。参数说明ping的目标地址要换成管理信息区实际网关ss命令在嵌入式装置上不一定有没有就用netstat -tlnp。做这一步之前先确认你有一个明确的书面授权生产网络操作要谨慎再谨慎。3. 做厚边界与加密横向隔离装置和纵向加密认证装置的部署与配置3.1 横向隔离装置正向/反向部署位置与典型配置参数横向隔离装置在电力监控网络安全方案里的地位相当于整个生产控制大区的“闸门”。正向隔离装置部署在控制区到非控制区的数据流方向上反向隔离装置部署在非控制区到控制区的方向上。注意这两台装置必须成对存在不允许用一台双向设备替代而且多数现场要求正向、反向物理上都是独立的装置。我一般会在方案里明确三组配置参数。第一组是IP与路由内网侧和外网侧地址规划要避开已有地址段避免路由冲突第二组是业务白名单配置只开放生产业务使用的源IP、目的IP、端口和协议正向隔离一般以TCP或UDP端口为粒度反向隔离通常只允许特定文件传输协议第三组是装置自身的管理方式建议单独管理IP并限制管理源地址。# 正向隔离装置业务白名单配置示例按常见web管理界面翻译 # 每条规则含义源地址段 - 目的地址段 : 端口 / 协议 rules [ {src: 10.1.1.0/24, dst: 10.2.1.0/24, port: 2404, proto: tcp, action: allow}, {src: 10.1.1.0/24, dst: 10.2.1.0/24, port: 102, proto: tcp, action: allow}, {src: 0.0.0.0/0, dst: 0.0.0.0/0, port: 0, proto: any, action: deny}, ]逻辑说明这段Python表达的是配置思路实际配置在装置自带的管理界面里完成。规则顺序很重要生产装置一般先写允许规则最后落一条全拒绝规则作为兜底。第一行放的是IEC 104规约的2404端口这是电力监控远动最常用的端口第二行放的102端口是IEC 61850 MMS常见的连接端口按实际业务调整。参数说明不要把管理信息区访问数据库、办公网的端口开到隔离装置上很多现场翻车的点在于把隔离装置当普通防火墙用放了一堆和电力业务无关的端口测评一查直接扣分。对于IEC 104规约如果你用不同端口承载多个通道白名单要写精确到每一对通道的地址端口不要用整个网段。3.2 纵向加密认证装置隧道路由与证书配置纵向加密认证装置解决的是上下级调度数据网之间的传输安全问题。它和横向隔离的分工是横向隔离管“区内横向”纵向加密管“上下级纵向”。常见的部署方式是在调度数据网的两端各部署一台装置一端在厂站端一端在调度端两者之间建立加密隧道。核心参数包括隧道两端IP、加密算法国密SM2/SM4为主流、密钥更新周期、证书与数字信封。配置纵向加密装置有一个容易被低估的点证书。多数地区的调度侧对厂站端证书有统一签发流程设备序列号、IP地址、所属调度机构都会编码进证书。现场常遇到的问题是证书申请材料里IP写错或者现场改了业务IP导致隧道建不起来。因此我给的落地顺序是先规划隧道两端地址再申请证书最后做隧道调试。# 纵向加密装置隧道连通性检查步骤 # 1. 在厂站端装置执行ping对端隧道地址确认链路可达 ping 10.200.0.2 # 2. 检查装置证书状态确认证书在有效期内且信任链完整 # 不同品牌命令不同常见为cert-view或show cert show cert status # 3. 查看隧道协商状态确认两端加密算法与密钥一致 show tunnel status逻辑说明第一句ping的是对端装置的隧道口地址不是业务地址。纵向加密装置的典型模型是业务主机地址不变数据先进本地装置被加密封装后通过隧道口发到对端装置再解封装送给业务主机。所以隧道连通是第一前提链路不通后面全免谈。第二句和第三句在装置命令行或管理界面执行各品牌命令有差异但检查项就这三类证书、隧道、密钥算法。参数说明密钥更新周期一般建议按调度要求设常见为24小时或7天很多厂站端装置默认开启了自动更新但调度端没启用两边配置不一致会导致定时断链。调试纵向加密最忌讳在没有调度侧配合时自己改装置参数一定要先做业务窗口计划并确认回退方案。3.3 双机冗余与切换别让高可用成为新的单点电力监控网络安全方案中横向隔离装置和纵向加密认证装置的可用性直接决定生产业务是否中断。大多数站点会采购两台构成双机热备但双机的坑往往在切换逻辑上。常见做法是主备两台装置间跑心跳检测到主机故障后备用机接管IP。这里最容易犯的错是把心跳线和业务线放在同一个交换机上交换机故障时主备同时失联业务全停。我一般会在方案里明确三点第一心跳链路与业务链路物理上分开至少用不同VLAN第二切换条件要同时看链路状态和业务端口状态只检测心跳会导致“设备活着但业务口坏了”不切换第三切换后要自动或手动做一次业务验证确认隧道和隔离规则在备用机上生效。很多装置的配置在主备间是自动同步的但同步失败时不会主动告警需要纳入日常巡检。4. 主机加固与白名单从安全操作系统基线到最小化服务和端口4.1 主机加固的基线项账号、口令、审计、危险服务边界设备做完之后电力监控网络安全方案的下一层是主机加固。现场最常见的主机是远动通信管理机、变电站监控后台、数据库服务器操作系统以Linux和Windows Server为主。加固基线我可以直接给一套标准账号策略、口令策略、审计策略、服务最小化、补丁管理、USB与外设管控。先说账号口令。Linux下检查是否存在弱口令或空口令账号确认root登录方式限制Windows下检查Guest、Administrator账号策略。然后说服务最小化Linux的Telnet、rlogin、FTP一律禁掉Windows的Remote Registry、NetBIOS也要处理。最后是审计所有登录和特权操作都要记录日志留存至少6个月。注意调度数据网里的老旧装置很多是嵌入式系统可能不支持常规加固这类设备就靠边界和隔离来补偿不要硬改系统。4.2 用脚本批量核对生产主机基线现场几十台机器一台台敲命令效率太低我会带一个批量核查脚本进现场。它的逻辑是用SSH免密批量执行一组检查命令输出结果统一汇总人工只看异常项。#!/bin/bash # 批量基线核查脚本片段适用于Linux主机 HOSTS_FILE/tmp/hosts.txt for host in $(cat $HOSTS_FILE); do echo $host ssh root$host echo --- 危险端口 --- ss -tlnp | grep -E :(23|21|513|514|3389)\b || echo none; echo --- 弱口令账号 --- awk -F: \$2\\ {print \$1} /etc/shadow; echo --- 登录审计 --- grep -c Accepted /var/log/secure 2/dev/null done逻辑说明这个脚本有三个检查点。危险端口检查的是Telnet23、FTP21、rlogin513/514、远程桌面3389是否被监听只要有输出就代表对应端口对外开放需要确认业务是否必须使用弱口令账号检查的是shadow文件中密码字段为空的账号出现即整改登录审计检查的是secure日志中成功接受登录的次数用于确认远程登录审计是否生效。参数说明HOSTS_FILE里每一行写一台主机IP脚本需要提前配置好SSH免密并且明确授权范围。注意一点不要在生产主机上安装额外的agent也不要修改系统配置只做只读核查。对Windows主机我一般把这条脚本替换成PowerShell版本检查项不变。4.3 应用白名单和USB管控在电力监控主机上的取舍应用白名单是电力监控网络安全方案里争议较大的一项。监管和测评机构希望部署运维人员担心误杀业务进程和补丁更新。我的取舍原则是对非控制区的服务器和控制区的关键主机优先做白名单对老旧、备件困难、型号杂的装置先评估再决定不要一刀切。白名单方案落地时最核心的是先学习后强控。部署模式分两步第一步是监控模式把所有进程和可执行文件纳入白名单库但不做拦截观察一到两个完整业务周期第二步才是强控模式只允许白名单内的程序运行其余一律拦截。# 白名单学习阶段数据采集示例采集进程路径和hash import hashlib, os, subprocess proc_rows subprocess.check_output([ps, -eo, pid,comm,args]).decode().splitlines() for row in proc_rows[1:]: parts row.split(maxsplit2) if len(parts) 3: continue pid, comm, args parts[0], parts[1], parts[2] try: exe_path os.readlink(f/proc/{pid}/exe) with open(exe_path, rb) as f: file_hash hashlib.sha256(f.read()).hexdigest() print(f{pid}\t{comm}\t{exe_path}\t{file_hash}) except (PermissionError, OSError): continue逻辑说明这段脚本把当前所有进程的可执行文件路径和SHA256哈希输出到标准输出白名单系统可以用这个清单做策略基线。学习阶段要覆盖启动、停机、故障切换这些状态不要只采集一个时间点的快照否则后台守护进程会在半夜自动拉起时被拦截。参数说明白名单粒度建议按“路径哈希”双维度控制路径相同但哈希变化时要触发告警说明程序被升级或被替换。补丁升级窗口要提前通知白名单管理员否则升级后可能直接导致服务起不来。USB管控虽然和网络无直接关系但在电力监控场景里属于“物理隔离的最后一道”建议在加固方案里一并写进去至少做到USB口禁用或仅允许经认证的U盘。5. 电力监控网络安全的常见坑与排查5.1 现象加装纵向加密装置后远动通道全部中断这是纵向加密项目里最常见的翻车点。现场加装装置后调度端能看到厂站已离线所有IEC 104通道全部超时。原因基本指向四类第一是证书没有正确导入或证书链不完整认证失败后装置直接丢弃报文第二是隧道参数两端不匹配比如加密算法、密钥更新周期不一致第三是厂站端装置没开转发模式数据被装置拦截第四是业务IP规划变更后没有同步隧道策略流量没有匹配到隧道规则。解决顺序先看装置日志确认是证书告警还是隧道协商告警然后用装置自带的连通测试工具从厂站端ping对端隧道地址确认链路层通再逐项核对证书状态和隧道两端参数。我处理过的一个现场最后发现是装置默认开启了“断开模式”业务流量不匹配任何规则时直接丢弃加一条匹配全部业务网段的转发规则就恢复了。5.2 现象双机切换频繁导致生产业务闪断横向隔离或纵向加密装置配置了双机热备但运行一段时间后发现备用机频繁接管每次接管业务就闪断几秒。原因通常有两个一是心跳链路不稳定装置的心跳超时时间设置过短轻微网络抖动就触发切换二是主备两台设备的运行状态检测条件不透彻只检测了心跳没有检测业务接口状态。还有一种情况是主备机的配置文件不同步备用机接管后规则不完整业务放通出现异常。解决思路拉长心跳超时时间到3秒以上同时把业务口链路状态纳入切换判定避免“设备活但口断了”的情况再做一次主备切换演练人为断掉主机的业务口观察备用机是否能完整承接业务。双机不是配好就不管了建议每一到两个月做一次主动切换试验逼出配置漂移问题。5.3 现象白名单强控后调度下发的遥控指令偶尔失败白名单部署从学习模式切换到强控模式后偶尔出现遥控指令被拦截的现象但不是每次都失败排查起来非常折磨人。原因分两层。第一层是进程白名单漏了进程调度下发指令时主站会先连接前置机的某个动态加载模块再由它唤起另一个处理进程这个进程在学习阶段从未出现过。第二层是文件白名单误伤告警产生时进程会动态写入日志文件或配置文件文件白名单把写入操作拦截了导致进程异常退出。解决思路关闭白名单强控切回监控模式复测遥控指令并采集被拦截的告警记录把新出现的进程路径和文件路径加入白名单再切回强控。这类问题出现的根本原因是学习周期不够只采集了日常数据没有覆盖调度操作场景。所以白名单学习窗口要覆盖完整的业务操作类型包括遥测、遥信、遥控、文件下发和远程维护会话。5.4 现象日志审计时间错乱告警关联不起来部署了统一日志审计平台后多个系统关联分析时发现时间线对不上告警事件无法复位到具体操作顺序。原因几乎都是NTP时钟同步未做。电力监控网络因为安全分区限制很多主机无法访问管理信息区NTP服务器各设备时间漂移严重时间戳错乱。有些装置的时间源是GPS对时和NTP对时混用也会出现秒级偏差。解决思路在控制区和非控制区各搭一台NTP服务器由装置或主机通过纵向加密隧道同步管理信息区的标准时钟源再对所有生产主机配置定时同步。做这个事时要注意如果NTP服务器本身走防火墙规则记得放行UDP 123端口但控制区内大量老旧Linux装置对NTP客户端支持不完整可以用脚本对时的方式做替代。统一时钟源这件事一定在项目初期就做后期补要返工很久。6. 验证与进阶从基线核查到应急演练让方案真正经得起测评与事故方案做完不是以设备上架为终点我一般会做三层验证。第一层是合规自查拿着等保测评检查表和第一版差距分析表逐项复测横向隔离规则是否生效、纵向加密隧道是否建立、主机危险端口是否已关闭、日志是否统一留存。第二层是业务功能测试在调度批准的业务窗口里逐个验证遥测、遥信、遥控链路确保安全设备没有改变业务行为。第三层是攻防演练用生产环境的测试分区做一次模拟攻击观察IDS是否告警、纵向加密隧道是否被非法访问阻断。这里给你一个我长期在用的验证技巧每一次变更后把配置备份文件、证书备份、路由表输出、装置版本信息全部打成一个带日期戳的快照。你永远不知道下一次故障和测评哪个先来这份快照就是你的后悔药。遇到“之前还能通现在突然断了”的问题第一步先对比快照差异比在装置上一行行翻配置快十倍。我的习惯是每个电力监控网络安全方案交付后都留下一份“改前改后”的对比说明包括策略变更记录和每一次业务测试的结果截图。这个习惯救过我好几次一次是隔了半年后现场反馈通道中断我把以前的快照翻出来一对比发现是有人把纵向加密装置的隧道重启后加载了旧配置。另一次是等保测评机构要求提供整改证据快照记录直接就能派上用场。最后想提醒你一句电力监控网络安全方案做得再漂亮也敌不过一次不规范的现场变更。把变更管理、备份和回退方案写进制度里比任何一台设备都重要。希望这篇笔记能帮你在做方案时少踩几个坑。本文还有配套的精品资源点击获取
简介电力监控系统作为关键信息基础设施其网络安全防护核心在于安全分区与纵向加密两大主线。生产控制大区与管理信息大区需严格隔离横向隔离装置控制数据单向流动纵向加密认证装置保障上下级调度通信的机密性与完整性。从等保2.0合规基线出发本文梳理了隔离装置配置、证书管理、主机加固及白名单落地要点并结合典型故障排查经验帮助工程师快速构建可落地的电力监控网络安全方案。1. 电力监控网络安全方案为什么安全分区和纵向加密是绕不开的两条主线做过电力监控系统集成或运维的人第一年基本都会被一件事折腾到——调度下令核查网络安全甲方把一摞整改要求扔过来说“下个月等保测评要进场你们把方案补上”。这里说的电力监控网络安全方案不是普通办公网的防火墙加杀毒软件而是围绕变电站监控系统、调度数据网、发电厂远动装置这一整套生产控制系统的安全设计落点永远是“安全分区、网络专用、横向隔离、纵向认证”这十六个字。本文我就按自己做过的真实项目路径把方案从合规基线拆到设备配置再拆到验证方法和踩坑记录给你一条能直接照着动手的路。2. 先看合规基线等保2.0三级与电监会36号文要求的差距分析2.1 电力监控系统安全防护的“十六字原则”怎么落地电力监控网络安全方案的第一件事不是买设备而是先分清你的系统在哪个区。生产控制大区和管理信息大区不能混生产控制大区内部还要再分控制区安全区Ⅰ和非控制区安全区Ⅱ。控制区里跑的是实时闭环业务比如远动、AGC/AVC、保护故障信息非控制区跑的是气象、水情、电量采集这类准实时业务。两个区间通信必须走横向隔离装置控制区数据往外发走正向隔离外部数据进来走反向隔离。我先讲一个真实的选型判断很多刚入行的人会把电力监控网络安全方案理解成“堆防火墙和IDS”其实在电力监控网络里横向隔离装置和纵向加密认证装置才是骨架。普通防火墙在三层以下做过滤而横向隔离装置在应用层做单向传输摆渡物理上只允许单向导通纵向加密认证装置则负责调度数据网上下级调度的隧道加密与身份认证。一句话防火墙解决的是“能不能访问”隔离和加密解决的是“是不是合法的生产数据在合法通道里跑”。2.2 用差距分析表把合规要求翻译成设备清单拿到一个站点我一般先做一张差距分析表把等保2.0三级通用要求加扩展要求、电监会36号文附件里的条款和现场实际对照逐条标状态。这张表不仅是给测评机构看的更是你后面做方案采购和施工的依据。检查项合规要求现场常见现状差距结论安全分区生产控制大区与管理信息大区物理隔离或逻辑隔离办公网与监控网共用交换机需划VLAN并在边界加横向隔离装置横向隔离控制区与非控制区之间部署经检测认证的隔离装置未部署或串接过期装置需新增正向/反向隔离装置纵向认证上下级调度间数据交换采用纵向加密认证装置部分链路裸跑需新增纵向加密认证装置主机加固最小化服务、加固账号口令、部署白名单远动主机开放SSH且口令弱需做安全基线加固并部署白名单入侵检测生产控制大区应部署入侵检测系统无需在核心交换机旁路部署IDS日志审计统一日志审计并留存6个月以上分散且时间不一致需部署日志审计平台统一NTP边界访问控制控制区与非控制区、上下级之间应设访问控制规则交换机三层直连需细化ACL或由隔离装置承担这张表做完方案骨架就出来了横向隔离装置、纵向加密认证装置、IDS、日志审计、主机加固与白名单管理五类设备。记住做电力监控网络安全方案顺序是先有分区边界再有边界设备最后才做主机加固反过来做边界没定主机加固做了也白做。2.3 用几条命令自查当前网络边界划分在出正式方案前我会先在现场用几条命令摸清现状避免被甲方的描述带偏。这三个命令可以最快暴露边界问题# 查看本机路由确认是否存在跨区直连路由 ip route show # 查看生产主机监听的端口确认是否对外开放了多余服务 ss -tlnp | head -50 # 跨区测试从控制区某主机ping管理信息区网关正常应不通 ping -c 3 192.168.x.x逻辑说明第一条命令看的是路由出口如果控制区主机有一条指向管理信息区的默认路由说明三层直连边界缺失这就是等保测评里最吃亏的一条第二条命令看的是主机对外暴露面很多远动装置会默认开着Telnet、FTP白名单加固之前先从这里摸底第三条命令是简单粗暴的隔离验证生产控制大区与管理信息大区之间正常情况下业务不应互通互通就说明边界部署无效。参数说明ping的目标地址要换成管理信息区实际网关ss命令在嵌入式装置上不一定有没有就用netstat -tlnp。做这一步之前先确认你有一个明确的书面授权生产网络操作要谨慎再谨慎。3. 做厚边界与加密横向隔离装置和纵向加密认证装置的部署与配置3.1 横向隔离装置正向/反向部署位置与典型配置参数横向隔离装置在电力监控网络安全方案里的地位相当于整个生产控制大区的“闸门”。正向隔离装置部署在控制区到非控制区的数据流方向上反向隔离装置部署在非控制区到控制区的方向上。注意这两台装置必须成对存在不允许用一台双向设备替代而且多数现场要求正向、反向物理上都是独立的装置。我一般会在方案里明确三组配置参数。第一组是IP与路由内网侧和外网侧地址规划要避开已有地址段避免路由冲突第二组是业务白名单配置只开放生产业务使用的源IP、目的IP、端口和协议正向隔离一般以TCP或UDP端口为粒度反向隔离通常只允许特定文件传输协议第三组是装置自身的管理方式建议单独管理IP并限制管理源地址。# 正向隔离装置业务白名单配置示例按常见web管理界面翻译 # 每条规则含义源地址段 - 目的地址段 : 端口 / 协议 rules [ {src: 10.1.1.0/24, dst: 10.2.1.0/24, port: 2404, proto: tcp, action: allow}, {src: 10.1.1.0/24, dst: 10.2.1.0/24, port: 102, proto: tcp, action: allow}, {src: 0.0.0.0/0, dst: 0.0.0.0/0, port: 0, proto: any, action: deny}, ]逻辑说明这段Python表达的是配置思路实际配置在装置自带的管理界面里完成。规则顺序很重要生产装置一般先写允许规则最后落一条全拒绝规则作为兜底。第一行放的是IEC 104规约的2404端口这是电力监控远动最常用的端口第二行放的102端口是IEC 61850 MMS常见的连接端口按实际业务调整。参数说明不要把管理信息区访问数据库、办公网的端口开到隔离装置上很多现场翻车的点在于把隔离装置当普通防火墙用放了一堆和电力业务无关的端口测评一查直接扣分。对于IEC 104规约如果你用不同端口承载多个通道白名单要写精确到每一对通道的地址端口不要用整个网段。3.2 纵向加密认证装置隧道路由与证书配置纵向加密认证装置解决的是上下级调度数据网之间的传输安全问题。它和横向隔离的分工是横向隔离管“区内横向”纵向加密管“上下级纵向”。常见的部署方式是在调度数据网的两端各部署一台装置一端在厂站端一端在调度端两者之间建立加密隧道。核心参数包括隧道两端IP、加密算法国密SM2/SM4为主流、密钥更新周期、证书与数字信封。配置纵向加密装置有一个容易被低估的点证书。多数地区的调度侧对厂站端证书有统一签发流程设备序列号、IP地址、所属调度机构都会编码进证书。现场常遇到的问题是证书申请材料里IP写错或者现场改了业务IP导致隧道建不起来。因此我给的落地顺序是先规划隧道两端地址再申请证书最后做隧道调试。# 纵向加密装置隧道连通性检查步骤 # 1. 在厂站端装置执行ping对端隧道地址确认链路可达 ping 10.200.0.2 # 2. 检查装置证书状态确认证书在有效期内且信任链完整 # 不同品牌命令不同常见为cert-view或show cert show cert status # 3. 查看隧道协商状态确认两端加密算法与密钥一致 show tunnel status逻辑说明第一句ping的是对端装置的隧道口地址不是业务地址。纵向加密装置的典型模型是业务主机地址不变数据先进本地装置被加密封装后通过隧道口发到对端装置再解封装送给业务主机。所以隧道连通是第一前提链路不通后面全免谈。第二句和第三句在装置命令行或管理界面执行各品牌命令有差异但检查项就这三类证书、隧道、密钥算法。参数说明密钥更新周期一般建议按调度要求设常见为24小时或7天很多厂站端装置默认开启了自动更新但调度端没启用两边配置不一致会导致定时断链。调试纵向加密最忌讳在没有调度侧配合时自己改装置参数一定要先做业务窗口计划并确认回退方案。3.3 双机冗余与切换别让高可用成为新的单点电力监控网络安全方案中横向隔离装置和纵向加密认证装置的可用性直接决定生产业务是否中断。大多数站点会采购两台构成双机热备但双机的坑往往在切换逻辑上。常见做法是主备两台装置间跑心跳检测到主机故障后备用机接管IP。这里最容易犯的错是把心跳线和业务线放在同一个交换机上交换机故障时主备同时失联业务全停。我一般会在方案里明确三点第一心跳链路与业务链路物理上分开至少用不同VLAN第二切换条件要同时看链路状态和业务端口状态只检测心跳会导致“设备活着但业务口坏了”不切换第三切换后要自动或手动做一次业务验证确认隧道和隔离规则在备用机上生效。很多装置的配置在主备间是自动同步的但同步失败时不会主动告警需要纳入日常巡检。4. 主机加固与白名单从安全操作系统基线到最小化服务和端口4.1 主机加固的基线项账号、口令、审计、危险服务边界设备做完之后电力监控网络安全方案的下一层是主机加固。现场最常见的主机是远动通信管理机、变电站监控后台、数据库服务器操作系统以Linux和Windows Server为主。加固基线我可以直接给一套标准账号策略、口令策略、审计策略、服务最小化、补丁管理、USB与外设管控。先说账号口令。Linux下检查是否存在弱口令或空口令账号确认root登录方式限制Windows下检查Guest、Administrator账号策略。然后说服务最小化Linux的Telnet、rlogin、FTP一律禁掉Windows的Remote Registry、NetBIOS也要处理。最后是审计所有登录和特权操作都要记录日志留存至少6个月。注意调度数据网里的老旧装置很多是嵌入式系统可能不支持常规加固这类设备就靠边界和隔离来补偿不要硬改系统。4.2 用脚本批量核对生产主机基线现场几十台机器一台台敲命令效率太低我会带一个批量核查脚本进现场。它的逻辑是用SSH免密批量执行一组检查命令输出结果统一汇总人工只看异常项。#!/bin/bash # 批量基线核查脚本片段适用于Linux主机 HOSTS_FILE/tmp/hosts.txt for host in $(cat $HOSTS_FILE); do echo $host ssh root$host echo --- 危险端口 --- ss -tlnp | grep -E :(23|21|513|514|3389)\b || echo none; echo --- 弱口令账号 --- awk -F: \$2\\ {print \$1} /etc/shadow; echo --- 登录审计 --- grep -c Accepted /var/log/secure 2/dev/null done逻辑说明这个脚本有三个检查点。危险端口检查的是Telnet23、FTP21、rlogin513/514、远程桌面3389是否被监听只要有输出就代表对应端口对外开放需要确认业务是否必须使用弱口令账号检查的是shadow文件中密码字段为空的账号出现即整改登录审计检查的是secure日志中成功接受登录的次数用于确认远程登录审计是否生效。参数说明HOSTS_FILE里每一行写一台主机IP脚本需要提前配置好SSH免密并且明确授权范围。注意一点不要在生产主机上安装额外的agent也不要修改系统配置只做只读核查。对Windows主机我一般把这条脚本替换成PowerShell版本检查项不变。4.3 应用白名单和USB管控在电力监控主机上的取舍应用白名单是电力监控网络安全方案里争议较大的一项。监管和测评机构希望部署运维人员担心误杀业务进程和补丁更新。我的取舍原则是对非控制区的服务器和控制区的关键主机优先做白名单对老旧、备件困难、型号杂的装置先评估再决定不要一刀切。白名单方案落地时最核心的是先学习后强控。部署模式分两步第一步是监控模式把所有进程和可执行文件纳入白名单库但不做拦截观察一到两个完整业务周期第二步才是强控模式只允许白名单内的程序运行其余一律拦截。# 白名单学习阶段数据采集示例采集进程路径和hash import hashlib, os, subprocess proc_rows subprocess.check_output([ps, -eo, pid,comm,args]).decode().splitlines() for row in proc_rows[1:]: parts row.split(maxsplit2) if len(parts) 3: continue pid, comm, args parts[0], parts[1], parts[2] try: exe_path os.readlink(f/proc/{pid}/exe) with open(exe_path, rb) as f: file_hash hashlib.sha256(f.read()).hexdigest() print(f{pid}\t{comm}\t{exe_path}\t{file_hash}) except (PermissionError, OSError): continue逻辑说明这段脚本把当前所有进程的可执行文件路径和SHA256哈希输出到标准输出白名单系统可以用这个清单做策略基线。学习阶段要覆盖启动、停机、故障切换这些状态不要只采集一个时间点的快照否则后台守护进程会在半夜自动拉起时被拦截。参数说明白名单粒度建议按“路径哈希”双维度控制路径相同但哈希变化时要触发告警说明程序被升级或被替换。补丁升级窗口要提前通知白名单管理员否则升级后可能直接导致服务起不来。USB管控虽然和网络无直接关系但在电力监控场景里属于“物理隔离的最后一道”建议在加固方案里一并写进去至少做到USB口禁用或仅允许经认证的U盘。5. 电力监控网络安全的常见坑与排查5.1 现象加装纵向加密装置后远动通道全部中断这是纵向加密项目里最常见的翻车点。现场加装装置后调度端能看到厂站已离线所有IEC 104通道全部超时。原因基本指向四类第一是证书没有正确导入或证书链不完整认证失败后装置直接丢弃报文第二是隧道参数两端不匹配比如加密算法、密钥更新周期不一致第三是厂站端装置没开转发模式数据被装置拦截第四是业务IP规划变更后没有同步隧道策略流量没有匹配到隧道规则。解决顺序先看装置日志确认是证书告警还是隧道协商告警然后用装置自带的连通测试工具从厂站端ping对端隧道地址确认链路层通再逐项核对证书状态和隧道两端参数。我处理过的一个现场最后发现是装置默认开启了“断开模式”业务流量不匹配任何规则时直接丢弃加一条匹配全部业务网段的转发规则就恢复了。5.2 现象双机切换频繁导致生产业务闪断横向隔离或纵向加密装置配置了双机热备但运行一段时间后发现备用机频繁接管每次接管业务就闪断几秒。原因通常有两个一是心跳链路不稳定装置的心跳超时时间设置过短轻微网络抖动就触发切换二是主备两台设备的运行状态检测条件不透彻只检测了心跳没有检测业务接口状态。还有一种情况是主备机的配置文件不同步备用机接管后规则不完整业务放通出现异常。解决思路拉长心跳超时时间到3秒以上同时把业务口链路状态纳入切换判定避免“设备活但口断了”的情况再做一次主备切换演练人为断掉主机的业务口观察备用机是否能完整承接业务。双机不是配好就不管了建议每一到两个月做一次主动切换试验逼出配置漂移问题。5.3 现象白名单强控后调度下发的遥控指令偶尔失败白名单部署从学习模式切换到强控模式后偶尔出现遥控指令被拦截的现象但不是每次都失败排查起来非常折磨人。原因分两层。第一层是进程白名单漏了进程调度下发指令时主站会先连接前置机的某个动态加载模块再由它唤起另一个处理进程这个进程在学习阶段从未出现过。第二层是文件白名单误伤告警产生时进程会动态写入日志文件或配置文件文件白名单把写入操作拦截了导致进程异常退出。解决思路关闭白名单强控切回监控模式复测遥控指令并采集被拦截的告警记录把新出现的进程路径和文件路径加入白名单再切回强控。这类问题出现的根本原因是学习周期不够只采集了日常数据没有覆盖调度操作场景。所以白名单学习窗口要覆盖完整的业务操作类型包括遥测、遥信、遥控、文件下发和远程维护会话。5.4 现象日志审计时间错乱告警关联不起来部署了统一日志审计平台后多个系统关联分析时发现时间线对不上告警事件无法复位到具体操作顺序。原因几乎都是NTP时钟同步未做。电力监控网络因为安全分区限制很多主机无法访问管理信息区NTP服务器各设备时间漂移严重时间戳错乱。有些装置的时间源是GPS对时和NTP对时混用也会出现秒级偏差。解决思路在控制区和非控制区各搭一台NTP服务器由装置或主机通过纵向加密隧道同步管理信息区的标准时钟源再对所有生产主机配置定时同步。做这个事时要注意如果NTP服务器本身走防火墙规则记得放行UDP 123端口但控制区内大量老旧Linux装置对NTP客户端支持不完整可以用脚本对时的方式做替代。统一时钟源这件事一定在项目初期就做后期补要返工很久。6. 验证与进阶从基线核查到应急演练让方案真正经得起测评与事故方案做完不是以设备上架为终点我一般会做三层验证。第一层是合规自查拿着等保测评检查表和第一版差距分析表逐项复测横向隔离规则是否生效、纵向加密隧道是否建立、主机危险端口是否已关闭、日志是否统一留存。第二层是业务功能测试在调度批准的业务窗口里逐个验证遥测、遥信、遥控链路确保安全设备没有改变业务行为。第三层是攻防演练用生产环境的测试分区做一次模拟攻击观察IDS是否告警、纵向加密隧道是否被非法访问阻断。这里给你一个我长期在用的验证技巧每一次变更后把配置备份文件、证书备份、路由表输出、装置版本信息全部打成一个带日期戳的快照。你永远不知道下一次故障和测评哪个先来这份快照就是你的后悔药。遇到“之前还能通现在突然断了”的问题第一步先对比快照差异比在装置上一行行翻配置快十倍。我的习惯是每个电力监控网络安全方案交付后都留下一份“改前改后”的对比说明包括策略变更记录和每一次业务测试的结果截图。这个习惯救过我好几次一次是隔了半年后现场反馈通道中断我把以前的快照翻出来一对比发现是有人把纵向加密装置的隧道重启后加载了旧配置。另一次是等保测评机构要求提供整改证据快照记录直接就能派上用场。最后想提醒你一句电力监控网络安全方案做得再漂亮也敌不过一次不规范的现场变更。把变更管理、备份和回退方案写进制度里比任何一台设备都重要。希望这篇笔记能帮你在做方案时少踩几个坑。本文还有配套的精品资源点击获取
