最近带队做了几个油品储运站区的工控系统安全巡检，结果比预想的要紧张。一次例行查看整理出十个严重漏洞，按通用标准打分，好几个都踩在“可直接远程打穿”的线上。而这些漏洞覆盖的燃油储罐，数量是以“千”为单位的。这十类问题不是某一家厂商的孤立缺陷，而是油气储运这种重资产行业里普遍存在的结构性短板。
这篇文章我把这次巡检里发现的十类严重漏洞整理成完整的拆解报告，包括漏洞长什么样、为什么存在、攻击者怎么利用、以及现场怎么一步步加固。适合做油库、炼厂储运、成品油管道场站相关系统的运维和安全管理岗位参考，也适合刚接触工控安全、想知道“为什么说储罐能被网络攻击打穿”的朋友。
1. 问题是怎么暴露的：一次储罐区巡检带出的“十连击”
1.1 从“例行查看”到“紧急报告”
事情的起点是一次很常规的季度检测。按惯例，这类检测主要是看系统运行状态、备份配置、查查登录记录，按理说半天就能收工。但这次扫描结果一出来，气氛就不太对了：目标机柜里的几十台控制器和上位机，存在多种高危脆弱点，其中好几项可以直接让访问者获得控制权限，进而下发操作指令。
进一步扩大范围的核查更让人后背发凉：同一套自动化模板被复制到了多个场站，数据采集、液位联锁、阀门控制这些核心逻辑几乎一模一样。也就是说，在一个站找到的漏洞，基本可以直接“平移”到其他站再用一遍。标题里的“数千燃油储罐”不是修辞，而是把各场站的罐数量加总之后的真实数字。
这个现象在业内其实有个很形象的说法：“一个配置模板，打穿一片储罐”。很多油气储运企业为了降低运维成本，会把站控系统的组态工程做成标准模板，再分配给各场站。模板省了钱，也把同一种脆弱性复制到了每一个分站。攻击者不需要逐个研究，只要拿到一份模板的漏洞，就等于拿到了所有站点的“通用钥匙”。
1.2 为什么燃油储罐会成为网络攻击的靶子
很多人一听到“储罐被网络攻击”，第一反应是“罐子又没有网线，怎么打？”这里要澄清一个常见的理解偏差：被攻击的不是储罐的金属壳体，而是控制储罐运行的那套自动化系统。
现代燃油储罐区几乎都是自动化运行。液位计实时把油位数据传回站控系统，系统根据液位高低自动启停泵、开闭阀门、触发高高低低联锁报警，这些控制逻辑全部依赖上位机、控制器、通信网络之间的协作。只要这套协作链条上有一个漏洞，攻击者就能像坐在中控室里一样，远程改变油位设定值、关闭联锁保护、误开关阀门。
更深层的原因在于油气储运系统的三个先天属性：
一是生命周期长。很多控制器和上位机在投产之后连续运行十年甚至二十年，系统架构和软件版本基本定格在投产那天。开箱时默认开启的服务，十年后还开着；早期固件里的硬编码口令，至今原封不动。
二是可用性压倒一切。生产系统的首要原则是不能停，液位联锁坏一个触点都要小心翼翼，更不要说为了安全加固去重启控制器。很多已知漏洞迟迟不修复，不是没人知道，而是不敢停系统。
三是历史设计假设太乐观。早期工控系统设计时普遍假设网络是封闭可信的，所以协议不带加密、软件不带认证、端口无条件开放。这个假设在隔离的物理网络里或许成立，但当这些网络逐步与办公网、远程运维通道互联之后，就彻底失效了。
2. 十个严重漏洞逐个拆解：类别、成因与危险等级
2.1 先看这份漏洞全景表
这次巡检归纳出的十类漏洞，涵盖了设备固件、通信协议、网络架构、主机系统、账户管理和运维流程六个层面。下面按实际影响的严重程度排序。
| 序号 | 漏洞类别 | 风险等级 | 受影响对象 | 典型后果 |
|---|---|---|---|---|
| 1 | 默认口令从未修改 | 严重 | 控制器、上位机、HMI | 获得操作权限，直接下发控制指令 |
| 2 | 固件内置硬编码后门口令 | 严重 | 老版本控制器、远程维护模块 | 绕过正常认证进入系统 |
| 3 | 数据采集与控制指令明文传输 | 严重 | 控制器与上位机通信链路 | 窃听、篡改控制指令 |
| 4 | 调试接口/管理服务暴露至办公网 | 严重 | 工程站、历史数据库 | 未授权读取与写参数 |
| 5 | 旧版数据接口服务缺少认证 | 高危 | 站控系统上位机 | 绕过业务逻辑直接读写数据 |
| 6 | Web管理平台注入类漏洞 | 高危 | 站级Web组态页面 | 获取账号权限、篡改页面逻辑 |
| 7 | 固件协议栈存在缓冲区溢出隐患 | 高危 | 老旧控制器 | 异常报文导致控制器重启或失控 |
| 8 | 运维终端携带恶意代码进入生产网 | 高危 | 工程师站、操作站 | 横向渗透、勒索加密、指令篡改 |
| 9 | 账号权限过大且多人共用 | 中危 | 站控系统、上位机账号 | 权限滥用、事故溯源困难 |
| 10 | 安全日志缺失、告警不落地 | 中危 | 全部系统 | 发生安全事件后无法追溯 |
这张表是从十几套现场系统里横向对比后浓缩出来的。要说哪些最致命，答案很直接：前三类。它们分别代表“门没锁”“钥匙就插在锁上”“门锁本身形同虚设”三种情况。一个攻击者只要会用其中一类，就能对储罐区产生实质影响。
2.2 默认口令和硬编码口令，老问题为什么还能“通杀”
第一类和第二类漏洞属于账户口令问题，也是这次巡检里最容易利用的。现场的控制器用默认用户名加默认口令就可以进入配置模式，上位机组态软件的工程密码是空，历史数据库的超级账号也是初始密码。这些口令在出厂文档里写得清清楚楚，稍微有点经验的从业者都能猜到。
也许有人会问：这些系统不是上线时都会改口令吗？现实是，很多项目上线时确实设了密码，但设完就再也没有轮换过。更麻烦的是，一些点位为了运维方便，刻意保留了默认口令，理由是“现场调试要快速进场”。
硬编码口令则更隐蔽。它存在于早年固件的后门账号里，普通配置界面看不到，只有用特定账号名才能触发。这个问题最麻烦的地方在于：它不是改个密码就能解决的。即便运维人员把可见账号的密码全部换新，后门账号依然以固定凭证躺在固件里，等待任何知道它存在的人调用。
我在现场见过一个很典型的场景：工程师打开某控制器配置软件，连接后提示输入密码，他在键盘上敲了六个“1”，系统直接放行。整个操作耗时不到十秒。拿下控制器之后，读取配方、修改设定值、停止联锁逻辑都是可选项。这种“秒进”的体验，让漏洞的危害级别直接拉满。
2.3 未授权接口与调试通道，攻击者通往阀门的“近路”
第四类和第五类属于服务暴露问题。工控系统上位机通常运行两类服务：一类是给现场工程师用的调试和维护通道，一类是给业务系统用的数据接口。问题在于，这些服务在设计时只考虑了“能用”，没有考虑“谁能用”。
调试接口暴露在办公网段是最常见的桥头堡。从办公网发起扫描，就能发现大量开放调试端口的上位机。利用工具连上去以后，不仅可以读取实时液位、温度、流量等工艺参数，还可以尝试下发阀门开度指令、修改泵组启停状态。
旧版数据接口的问题更有意思：它的本意是给上层系统提供只读数据视图，但实际接口实现里，业务方可以通过构造特殊参数来写入控制点。这个漏洞的存在意味着“查看数据”和“写控制指令”之间的边界被抹平了。攻击者不需要破解任何密码认证，只要会构造请求，就能越过业务边界直接触达控制指令层面。
这类问题最让人无奈的地方不是技术难度高，而是修复阻力大。上位机服务和接口往往与业务深度耦合，厂家的技术支持不在现场不敢乱动，第三方系统对接时又依赖这些接口，一旦关停，上层报表、数据中台全都跟着瘫痪。于是很多站都在“明知道是个洞，但暂时只能让它敞着”的状态里维持运行。
2.4 经典工控协议裸奔了几十年，问题出在“设计假设”
第三类漏洞是通信协议安全性缺失，这是十个问题里最“源远流长”的一类。
早期工业控制系统的通信协议在设计时有一个共同前提：通信链路是物理隔离的、封闭的、可信的。在这个前提下，协议里完全没有加密、认证、完整性校验这些元素，只追求一个目标——快速可靠地把数据从采集端送到控制端。
这个设计思路在当年是合理的。一台控制器和一条专线之间，想接入网络都难，谁会想到要对报文做加密？但几十年后，当这些控制网络被越来越多地接入监控大网、办公网络、远程运维通道之后，协议的“裸奔”属性就变成了隐患：
- 明文传输让攻击者可以在链路上做中间人窃听，拿到液位、温度、压力等工艺参数，然后根据这些信息判断罐区运行状态。
- 更严重的是指令篡改。攻击者截获一条合法控制报文，替换掉里面的目标地址和指令值，原本“关闭阀门A”的合法操作就可能变成“打开阀门B”。
- 一些控制器对异常报文的解析处理并不健壮，构造畸形的协议包直接发送，就可能让控制器协议栈崩溃，触发不必要的停车或误动作。
这种“设计于互联网时代之前、运行于互联网时代之后”的错位，是整个工控系统安全脆弱性的根源之一。协议本身不提供安全能力，那么在协议之上必须用网络层的访问控制来补足，这是后续整改的核心思路。
2.5 权限、日志和固件，管理侧的三个“黑洞
第六类到第十类问题表面上看没有前三类那么“能动阀门”，但它们是攻击链路上不可缺少的助推器。
Web管理平台的注入类漏洞能帮助攻击者在前端不暴露任何痕迹的情况下获取管理员账号。由于这些平台往往还关联了设备的配置文件，攻击者拿到权限后可以进一步导出配置、篡改画面、植入恶意页面逻辑。
缓冲区溢出问题出现在老旧设备的协议栈实现里。把长度异常的报文发过去，一部分控制器可能出现异常重启，另一部分则存在被利用执行任意代码的可能。这个漏洞在平时不声不响，但一旦被触发，破坏力远高于直接关掉一台泵。
运维终端携带恶意代码的问题更值得从业者警惕。现场工程师经常用同一台笔记本既上办公网处理邮件，又插到生产网做调试。这台笔记本一旦在办公网上中了招，当它被接入生产网瞬间，恶意代码也就跟着进了控制区。业内把这种传输方式叫作“摆渡”，它能让所有看似严密的网络隔离形同虚设。
账号权限过大和日志缺失则代表事后应急能力的不足。一个全员共用的超级账号，出了事根本说不清是哪个人在哪个时间点做了什么操作；日志不落地，连最基础的攻击溯源都做不到。这两个问题单独看危害等级不算最高，但它们叠加在其他漏洞之上时，会让整个安全事件变得“打了白打”。
3. 从办公网到储罐区：一条真实可行的完整攻击链路
3.1 攻击链路的完整推演
单独看十个漏洞中的每一个，似乎都有点“隔靴搔痒”的感觉。但把它们串成一条链路来看，攻击的完整逻辑就清晰了。
以这次巡检中发现的典型组合为例：办公网某台电脑上有员工账号，通过钓鱼邮件投递的文档可以获得一个外层控制权。办公网与生产网之间虽然部署了隔离装置，但现场为了解决远程运维问题，在某个时段开放了一条临时转发策略，这条策略一直没撤销。
攻击者利用Web管理平台注入漏洞横向移动到生产网，接着扫描发现上位机的调试接口。利用未授权接口和旧版数据接口组合，读取到储罐液位和联锁参数。紧接着，攻击者通过默认口令直接登录上位机组态软件，修改了高液位联锁的触发值，把原本应该报警停泵的阈值提高到了一个危险高度。
最后，在某个储罐正在收油作业、液位快速上升的过程中，攻击者执行了最终动作：修改设定值、停掉联锁、关闭上位机报警。整个攻击链路从第一次入侵到最终触发物理后果，间隔可能只有几个小时。
有意思的是，这条链路上没有任何一个环节使用了“极高技术含量”的手段。默认口令、注入漏洞、未授权接口、开放策略，全是安全圈里的“基础题”。它们之所以能组合成致命攻击，不是技术精湛，而是现场对这些基础问题毫无防守。
3.2 拿到操作权限之后，攻击者能造成什么物理后果
很多人对“网络攻击影响物理储罐”的认知停留在“偷数据”的层面。但储罐区的特殊之处在于，它的控制指令最终会变成物理世界的动作：开阀门、启泵、停泵、调温、加热、联锁、泄压。
一旦攻击者拿到控制器操作权限，可选的物理后果包括但不限于：
- 正常作业期间误开某个罐的出口阀门，导致油品串罐甚至溢出。溢出后的油品遇到火源，可能就是重大事故。
- 修改液位联锁值，让储罐在液位超高时依然继续进油，使储罐进入超装状态。严重超装会导致罐壁受力异常、罐体变形。
- 关闭核心报警和高高液位联锁，让本应自动触发的安全保护在危急时刻沉默，人为制造“裸奔”状态。
- 利用缓冲区溢出让控制器异常重启或进入停止模式，中断输油流程，造成全线停输。
这些后果的共同特点是不需要攻击者具备石油化工专业背景，只需要把控制指令“翻译”成现场动作的能力。由于生产网内缺少认证和校验机制，指令到达现场就会被执行，物理后果随之而来。对于一个存储大量易燃易爆介质的储罐区来说，这类后果的严重程度几乎是灾难级的。
3.3 为什么“物理隔离”神话不能再依赖
不少从业者有一个惯性思维：厂里的生产网是物理隔离的，外网进不来，所以安全没问题。这个说法在十年前有一定道理，但现在已经严重过时。
物理隔离的边界正在被业务需求不断“凿穿”。远程诊断运维、数据上传到集团监控平台、移动端液位查询、天眼系统的远程观看，每一项业务都在生产网的边界上开了一个口子。今天开一个端口做数据回传，明天开一条策略供出差工程师远程连入，后天为了临时调试再放行一个IP段，层层加码之后，“物理隔离”这四个字早就名存实亡。
就算边界上暂时没有洞，前面提到的“摆渡攻击”也会绕过物理隔离。运维笔记本和U盘在办公网与生产网之间来回穿梭，恶意代码利用人的行为而非网络链路完成了隔离的跨越。物理隔离防得住网络扫描，防不住人的习惯漏洞。
所以，把安全信任建立在“我们内网很干净”的假设上，是储罐区网络安全最大的误区。任何外部接入点、任何运维操作行为、任何看似不起眼的配置改动，都可能是安全边界的真实缺口。边界必须被假设为“迟早会被穿透”，而储罐区内的设备防护才是真正的防线。
4. 整改优先级与加固实操：先止血，再清创
4.1 先给十类漏洞排个处置顺序
拿到这份漏洞清单后，最忌讳的事情就是眉毛胡子一把抓。我的建议是严格按照“止血优先、清创其后、康复跟上”的顺序来推进。
第一阶段目标是阻断已被利用的直接路径。默认口令全部强改、调试接口从办公网移除、明文协议链路上增加访问控制，这三项是最紧急的止血措施。它们不需要重新购买设备，也不需要大规模重构，两三天内就可以实施大部分。
第二阶段目标是清理系统内部的问题。Web平台、数据接口固件升级，去除硬编码后门，规范账号权限和日志策略。这个阶段牵涉系统停机、业务中断，必须和调度、生产沟通好窗口期。
第三阶段目标是建立常态化机制。部署日志审计、定期巡检、漏洞扫描、补丁管理流程，把安全从“一次性整改”变成“持续性运营”。
这个顺序背后有个朴素逻辑：先把门锁换掉，再清理屋里角落的隐患，最后才谈得上日常巡查。如果一上来就讨论固件升级、改造协议，可能折腾几个月还没落地，而默认口令的问题一天没解决，攻击者就一天不需要关心其他漏洞。
4.2 网络分区三步走：从“一片大平层”到“三进三出”
储罐区的网络整改，最值得投入的一步是网络分区，而不是在单个设备上打补丁。很多场站的现状是“一片大平层”：所有控制器、上位机、工程师站、办公电脑都趴在同一个网段里，彼此之间通信完全无阻挡。这种情况下，任何一个设备的沦陷都意味着全线崩溃。
分区改造可以分三步走。
第一步是把生产控制区和办公管理区彻底分开，两区之间只保留业务必需的数据通道，并且通过专门的隔离设备进行单向访问控制。这是储罐区最核心的架构性整改。
第二步是生产控制区内再做细粒度分段。按照罐区、泵棚、装车台、计量区、公用工程等工艺单元，把控制网络划分成若干安全域。域与域之间的横向通信策略默认拒绝，只放行业务必需的流程流量。
第三步是关键链路上增加协议管控。对于数据采集与控制指令所在的通信链路，在设备前端串接支持工控协议深度解析的防护节点，把非法指令、畸形报文、未授权访问全部掐在门口。
分区改造的经验教训就一句话：不要在办公网和生产网之间省那点设备钱，更不要为了一时运维便利长期开着临时策略。所有跨区的访问通道必须登记、审批、有时效，到期自动下线。
4.3 口令、协议、补丁的现场操作细节
口令整改看起来简单，实操中却有不少坑。第一坑是只改上位机口令、不改控制器口令。第二坑是改完口令后没有做统一的密码台账管理。第三坑是把新口令设得过于复杂，三个月后工程师自己都记不住，索性写张纸条贴在显示器边上。我的建议是引入专门的密码保险箱统一托管设备账号，口令轮换周期定在90天以内，关键设备每季度强制轮换一次。
协议加固层面，短期内最有效的措施是在不影响业务的前提下，优先停用未使用的服务端口。很多控制器出厂默认打开的服务其实业务根本用不到，为什么让它继续监听在网络上？另外，数据采集链路建议启用带完整性校验的安全传输模式。如果现场设备老旧不支持，就先在网络层用白名单机制限制通信对象，把协议暴露面压到最小。
补丁管理是工控系统整改中最讲究的一个环节。直接在生产系统上自动打补丁是绝对禁止的。现场必须建立一个“先测试后实施”的流程：补丁先在测试环境跑两周，确认不影响联锁逻辑和组态画面之后，再在生产窗口期实施。窗口期选择要避开收发油高峰期，还要准备快速回滚预案。测试环境可以小，但不能没有；没有测试环境就贸然打补丁，等于把控制系统当成实验田。
4.4 上线验证与回归测试：别让加固变成新的故障源
每次整改完成后，一定要做上线验证。这个环节容易被人跳过，觉得“改都改了，恢复运行就行”。但工控系统最怕的不是攻防对抗，而是没做回归测试直接投运导致的生产异常。
验证工作至少要覆盖三块内容：
第一块是功能回归。逐条核对液位联锁、温度报警、泵启停、阀开关等核心控制逻辑是否与整改前一致。方法是把联锁触发值和报警限值逐一对照原始组态截图，确认没有在加固过程中被“顺手”改坏。
第二块是通信校验。每条数据采集链路上的报文是否还在正常上传，控制指令下发是否有时延，历史数据和报表是否持续落库。一但出现通信中断，优先检查是否有协议防护规则误杀了正常流量。
第三块是权限确认。所有账号能否正常登录，权限划分是否与运维分工一致，有没有在整改过程中误删合法账户。
做完这三块验证并且记录签字之后，这次整改才算真正闭环。否则，一个安全加固动作可能引发新的生产故障，到时候操作员一边骂安全部门，一边把整改措施回滚，前面的功夫全白费。
5. 巡检排查技巧与常见陷阱：把安全感装进日常流程
5.1 季度巡检清单：半天一次的心脏检查
储罐区的安全巡检不需要天天搞，但必须定期搞、标准化地搞。我把日常巡检浓缩成一张清单，一个季度做一次，半天时间可以完成。
第一项是账户口令核查。抽检五台关键控制器和三台上位机，确认没有默认口令、弱口令和共用账号残留。这个抽检不需要把全部设备翻一遍，重点看最核心的液位联锁相关点位。
第二项是端口服务巡检。用扫描工具扫一遍生产网段，看有没有新增的开放端口、陌生服务和未登记的地址。重点关注办公网到生产网之间的数据通道是否出现了新的映射关系。
第三项是日志查证。检查上位机、数据库、隔离设备的安全日志是否正常落盘，有没有明显的暴力破解、异常外联记录。不要等到事情发生后再去找日志，那时候大概率已经找不到了。
第四项是运维行为审查。查一下最近三个月有没有运维人员从办公网远程接入生产网，接入的事由、审批、时长是否匹配。这个环节通常会让运维部门不太舒服，但恰恰是发现问题最多的环节。
第五项是配置比对。把当前运行的关键配置文件与基线版本做哈希比对，确认没有未授权的修改。一旦发现差异，立刻溯源是谁、何时、为什么改动。
这五项内容看起来简单，贵在坚持。最大的风险不是巡检发现不了问题，而是发现问题之后没人跟进处理，把巡检报告变成垃圾桶里的废纸。
5.2 现场运维最容易踩的五个坑
结合多次巡检经验，我把现场运维里最容易踩的坑整理如下，每一条都来自真实教训。
第一个坑是“图省事，设了一个万能的运维账号”。很多现场为了几个人都能干活，干脆共用同一个超级账号，密码人人知道。这个账号一旦被利用，所有操作都会算在同一个虚拟的人头上，事故调查根本分不清责任。
第二个坑是“远程维护通道长期打开”。远程运维工具今天用了一次，通道就挂着不关。攻击者不需要自己打开门，运维人员已经替他把门长期开着。
第三个坑是“厂家的电话支持要留后门”。不少厂家在调试或故障处理时需要远程接入，会要求开通临时的后门账号或调试端口。维护结束后，这些后门经常忘记清理，成为长期的暗门。
第四个坑是“新设备上线直接接入生产网”。新购的控制器、电脑、交换机到手后，没有经过安全配置就直接上线，出厂默认口令、默认服务、默认共享全部保持原样，等于主动往生产网里注入陌生脆弱点。
第五个坑是“只防外网，不防内鬼”。内部人员误操作、违规操作、账号转借带来的风险，往往远高于外部攻击。安全策略如果只盯着边界，忽略了内部行为审计，防线就缺了最里面的一块。
5.3 快速理解工控安全和传统信息安全的思维切换
最后说一点认知层面的东西。很多从IT安全转到工控安全的同事，一开始很不适应储罐区的安全节奏，原因在于两者对“核心目标”的定义完全不同。
传统信息安全讲究机密性、完整性、可用性三要素排序，通常把机密性放第一。工控安全恰恰反过来，可用性必须放第一。一套储罐控制系统哪怕被完全破解，只要它还能稳定运行、联锁还在，现场就先不会出事。反之，哪怕没有任何攻击者，一次不当的补丁更新让控制器重启，就可能触发联锁误动、泵组跳停，造成生产和安全双重损失。
这个思维差异决定了方法和工具的取舍。在储罐区做安全加固，永远要绕着“可用性优先”转：先保住系统持续运行，再考虑降低风险。凡是可能引起停机的操作，都必须安排在生产窗口期、做足回归测试和回滚预案。明白了这条主线，很多看似“保守”“落后”的工控安全做法就都能理解了。
真正跑完这几轮巡检和整改，我最深的体会是：储罐区的安全，拼的不是高深的技术，而是基础工作的扎实程度。那些几十年前埋下的隐患，攻击者用最简单的密码就能引爆。一个运行了十五年的场站，可能只是因为默认口令没改、临时通道没关、日志没开，就给数千座储罐留下了一道公开的侧门。每一次巡检都不必追求轰轰烈烈的大改造，把默认口令全部轮换、把临时策略全部清理、把日志全部落盘，这些扎实的细节累积起来，才是最真实的安全感。
