上一讲我们用一大篇聊了嵌入式设备的安全基线评论区不少人在问等保2.0工控扩展要求到底怎么落到自家网关、DTU、边缘控制器上做工业现场安全改造这两年我最常被问到的是——测评机构拿着一张表要的是制度文件和设备配置截图可嵌入式工程师更关心的是手里这个嵌入式Linux盒子怎么调、Modbus功能码怎么拦、有没有现成的合规自查脚本先跑一遍。所以这一讲不聊虚的直接拆两条主线先把等保2.0工控扩展要求拆成边界、主机、应用三个层面去适配再把功能码深度防护和合规自查脚本做成可以直接抄的落地方案最后补一份第18篇课后思考题的完整解析。1. 等保2.0工控扩展要求到底在要求什么1.1 从“通用要求”到“工控扩展要求”多了哪些硬指标等保2.0标准体系里通用安全要求是基础盘任何信息系统都要过而工控扩展要求是在这个盘子上额外增加的专门针对工业控制系统。很多设备供应商第一次接触时会把这两张表混着看结果要么过度设计要么漏项。其实工控扩展要求最核心的底层逻辑只有一条工业控制系统的首要目标是保障业务连续性不能为了安全手段牺牲生产控制链路的实时性和可用性。这句话值得多读几遍。通用要求强调的是“机密性、完整性、可用性”这个常规顺序而工业现场经常要把可用性放到更靠前的位置。具体到嵌入式设备这意味着安全模块不能动不动就重启协议过滤不能引入无法接受的时延补丁升级要考虑停产窗口日志审计也不能在设备运行时把磁盘写爆。理解了这一点再看那些控制点就不会觉得是抠字眼。工控扩展要求涉及的控制点很多我把和嵌入式设备关系最密切的几类整理成了一张表控制类典型要求嵌入式设备对应的落地措施安全物理环境控制机柜、现场设备位置保护防非授权物理接触对外接口封闭、外壳防拆告警、Console口权限控制安全通信网络基于工业协议进行通信传输设备具备可信接入能力启用TLS/DTLS封装Modbus TCP网关做来源白名单安全区域边界控制网与信息网/互联网隔离访问控制粒度细化嵌入式网关实现IP、端口、应用协议三层过滤安全计算环境工业控制设备自身安全包括身份鉴别、访问控制、入侵防范关闭冗余服务、SSH密钥认证、进程白名单、固件签名安全管理中心日志审计、时钟同步、集中管控设备日志外发NTP/SNTP对时审计接口开放这张表看起来像测评用的但实际操作时完全可以反过来用先按行把设备已有的功能对照一遍再决定哪些靠设备自身做哪些靠上游防火墙做。比如只有一路Modbus TCP下行链路的采集盒子SSH密钥认证和日志外发就基本覆盖了“安全计算环境”和“安全管理中心”两大块如果还带远程运维通道就得把通信网络和区域边界的要求一起纳入。1.2 嵌入式设备在这套体系里到底算“哪个对象”这也是我一直想强调的不少项目把“等保合规”直接理解成“买一台防火墙、写几份制度”。但等保2.0工控扩展要求的对象是整个工控系统嵌入式设备在系统里可能是现场采集终端、控制从站、智能网关也可能是历史服务器下面的瘦客户端。不同角色承担的合规项差得很远。比如一个Modbus RTU从站如果只是纯被动响应安全重点在物理防护和协议可用性如果它同时还是一个支持远程维护的DTU能把现场数据拉到远端运维平台那“安全通信网络”“安全区域边界”的要求就上来了必须考虑加密通信隧道、来源IP绑定和访问控制。在自研设备上更常见的情况是设备既采集数据又执行控制本身还带调试接口和远程升级通道。这种情况下我建议直接把设备按“工业控制设备边缘计算节点”双重角色来设计防线下发权限、日志审计、远程升级校验、调试接口管控全部做成默认安全配置。测评时把这些配置截图和自查脚本结果交上去基本不会心虚。2. 分层适配把安全要求拆到设备不同层级2.1 边界层先用网络隔离兜住大头边界层解决的是“谁允许跟谁通信”的问题。工控扩展要求在“安全区域边界”里反复强调控制设备之间、控制设备与上位机之间、控制网络和其他网络之间必须有明确的访问控制策略。很多老旧PLC没有任何身份认证能力把防线压到嵌入式设备上反而更现实——用设备自己做一个安全网关挡住不该进来的流量。以嵌入式Linux网关为例最常见的落地手段是nftables/iptables。先把来源IP、目标端口全列成白名单非白名单请求直接丢掉。Modbus TCP默认端口是502可以先用状态防火墙做第一道过滤iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 502 -m conntrack --ctstate NEW -s 192.168.10.0/24 -j ACCEPT iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 502 -m conntrack --ctstate NEW -j DROP iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 502 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT这里有个容易忽略的点工控协议经常是长连接不能简单对每个包做ACL必须放行established状态同时又要防止某个IP把连接数打满所以还要做并发连接限制和速率限制。更细的Modbus功能码过滤放在应用层见第3章。边界层如果是在设备内嵌场景还可以划分VLAN或独立网卡把调试网口、管理网口、业务网口物理/逻辑隔离。现场采集设备经常只有一个网口那至少要做到管理SSH只绑定管理地址段或者干脆不占用业务网口通过隐藏串口管理口访问。2.2 主机层嵌入式Linux加固是重头戏“安全计算环境”对应的就是设备自身的安全配置。很多嵌入式设备为了调试方便出厂就开着Telnet、FTP、SNMP默认口令这是测评里最容易被扣分的地方。我的习惯做法是先砍服务。系统里只保留sshd还是只监听内网管理口、时间同步、日志服务、业务进程。FTP直接用SCP替代TFTP这种无认证协议在线上环境必须彻底移除。接着是SSH配置至少做到PermitRootLogin prohibit-password PubkeyAuthentication yes PasswordAuthentication no MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2如果是只读文件系统的设备还要关注/tmp、/var/log别写爆。可以用tmpfs挂载临时目录日志用logrotate限制大小。给一个简单的sysctl加固片段sysctl -w kernel.randomize_va_space2 sysctl -w net.ipv4.tcp_syncookies1 sysctl -w net.ipv4.conf.all.accept_redirects0 sysctl -w net.ipv4.conf.all.secure_redirects0主机层还建议做文件完整性基线。嵌入式设备不像服务器能频繁装agent最简单的办法是在固件发布时生成关键文件哈希列表设备启动后用脚本对比一遍发现异常就记录并告警。这项能力虽然简单但在合规测评里对应“入侵防范”的控制点非常有效。2.3 应用层白名单与业务语义校验边界和主机加固做完最容易被忽略的是应用层防护。很多攻击根本不在“非法IP”层面而是合法上位机被入侵后拿着合法会话直接对PLC下发恶意指令。这时仅靠IP白名单完全没用必须在应用层做业务语义校验。嵌入式设备上的应用层防护有几个层次进程白名单系统只允许指定的几个二进制可执行其他一律拦截。systemd的RestrictAddressFamilies、ProtectSystem、NoNewPrivileges都能帮上忙进程可执行文件也可以用dm-verity做只读校验。协议级白名单针对Modbus、S7comm、OPC UA等工业协议限定功能码、寄存器范围、地址区间和操作类型。行为基线对正常上位机的读写频率、访问地址建立基线一旦出现异常高频写请求或广播地址访问直接阻断并生成审计日志。这三层越往上越接近业务实现成本也越高。对于资源有限的MCU设备至少要把协议级白名单做了因为这是从攻击手里拦住“单包变指令”的关键。3. 功能码深度防护Modbus协议的攻防细节3.1 先搞懂Modbus功能码的“语义”Modbus可能是工控系统里最普及也最不安全的协议之一。很多嵌入式工程师只把Modbus当成“读寄存器、写寄存器”但到了安全防护层面必须把每个功能码背后的操作语义搞清楚。功能码名称操作类型风险等级0x01读线圈只读低0x02读离散输入只读低0x03读保持寄存器只读低0x04读输入寄存器只读低0x05写单个线圈写高可篡改IO状态0x06写单个寄存器写高可篡改参数0x0F写多个线圈写高可批量篡改0x10写多个寄存器写高可批量篡改0x2B封装接口读写混合中高需解析子功能码一个典型的攻击场景是这样攻击者扫描到内网某个PLC开放了502端口直接构造一帧Modbus TCP写保持寄存器请求把PID参数改成0。从网络流量看这帧数据就是正常的TCP连接IP防火墙根本拦不住只有解析到功能码0x06和寄存器地址才知道这是恶意写操作。所以功能码深度防护的实质是让安全设备理解工控协议的业务语义。3.2 深度过滤策略白名单功能码寄存器范围限制在自研嵌入式网关里做功能码过滤最稳妥的不是拿现成IDS硬套而是按业务链路配置白名单。比如某台PLC只允许上位机读取保持寄存器0x0000-0x000F不允许写入任何参数那策略就是放行来源IP为指定上位机的Modbus TCP请求且功能码∈{0x01,0x02,0x03,0x04}放行目标寄存器地址落在0x0000-0x000F区间丢弃或记录功能码∈{0x05,0x06,0x0F,0x10}的请求unit id0的请求直接丢弃Modbus TCP不支持广播unit id0通常意味着扫描或探测行为这里补充一点Modbus串行链路上的广播地址0在TCP里并不合法很多攻击工具为了扫描方便会把unit id设成0。真正的PLC往往也能响应但站在安全角度直接丢弃并记日志是最干净的策略。另外一个容易被忽略的细节是“写寄存器地址范围”。有的设备虽然允许上位机写寄存器但只允许写配置寄存器区不允许写运行参数区。这时过滤规则不能只看功能码要把功能码寄存器起始地址寄存器数量一起解析。Modbus写多个寄存器的请求里会带“起始地址”和“寄存器数量”过滤逻辑要校验“起始地址数量”是否越界否则一个写多个寄存器请求可能把运维参数区整段打乱。3.3 实战基于嵌入式Linux实现一个轻量Modbus TCP深度过滤器在嵌入式Linux上做Modbus深度过滤可重资产方案是用DPDK/eBPF但对大多数网关设备太重调试周期也长。我建议先做一个轻量级应用层转发代理设备监听一个端口解析Modbus TCP报文通过校验后才转发给下游PLCPLC响应再原路返回。下面是一段Python实现的核心逻辑生产环境可以替换成C或Rust思路一致import socket, struct READ_CODES {0x01, 0x02, 0x03, 0x04} WRITE_CODES {0x05, 0x06, 0x0F, 0x10} def parse_modbus_tcp(pkt): if len(pkt) 8: return None tid struct.unpack(H, pkt[0:2])[0] pid struct.unpack(H, pkt[2:4])[0] length struct.unpack(H, pkt[4:6])[0] unit_id pkt[6] func pkt[7] return {tid: tid, pid: pid, length: length, unit_id: unit_id, func: func} def check_policy(pkt_info): if pkt_info[pid] ! 0x0000: return False if pkt_info[unit_id] 0: return False if pkt_info[func] in WRITE_CODES: return False # 如果还需要校验寄存器范围从pkt[8:]继续解析 return True代理主循环里从socket接收到完整TCP流后拆出事务标识符、协议标识符、长度和功能码调用check_policy判断。判断失败的请求直接丢弃或返回一个Modbus异常响应常见是功能码0x80异常码0x02非法数据地址判断成功的请求再转发到PLC的502端口。这个方案的优点是逻辑简单清晰完全透明不需要改动PLC固件缺点是转发延迟比内核模块高一些。实测在百兆以太网上单帧解析加转发延迟在几十微秒到几百微秒之间对大多数数据采集和参数轮询场景完全够用。如果现场对时延极其敏感比如运动控制同步那就得上eBPF或专用硬件原理也是同样的过滤逻辑。4. 合规自查脚本把检查变成半自动化工具4.1 脚本功能规划与输出格式每次做现场测评前手工检查一堆设备配置真的很折磨人。所以我平时维护了一套针对嵌入式Linux设备的合规自查脚本目的不是替代测评机构而是把能自动化的检查项变成可复现的报告减少人工遗漏。脚本规划遵循几个原则不主动向PLC写数据只做请求、读响应避免影响生产。尽量用系统自带的命令和接口不在生产设备上装大型扫描工具。输出统一格式每项检查给出PASS/FAIL/WARN最后生成汇总报告。所有主动探测操作默认关闭需要命令行参数手动开启。输出格式建议用纯文本或JSON方便后续接日志平台。比如检查项名称、检查结果、检查详情、建议修复方案这些字段缺一不可。4.2 核心脚本片段端口、SSH、Modbus探测第一项基础检查是开放端口和服务。不用nmap直接读/proc/net/tcp再结合ss命令把LISTEN状态的端口拉出来check_open_ports() { echo [*] 检查对外开放端口... ss -lnt | awk NR1 {print $4} | grep -oP \d$ | sort -n -u /tmp/ports.txt cat /tmp/ports.txt }第二项是SSH配置检查。重点看是否允许root密码登录、是否允许空密码、是否关闭密码认证check_ssh_config() { grep -E ^PermitRootLogin|^PasswordAuthentication|^PubkeyAuthentication /etc/ssh/sshd_config || echo FAIL: sshd_config项缺失 }第三项是Modbus功能性探测也是最核心的。通过主动发送一个读保持寄存器请求0x03到本机或下游PLC看是否有响应再用一个非法的写功能码0x06的请求看设备是否返回异常码。写请求只发送到自研设备的测试虚拟从站不对生产PLC执行import socket, struct def check_modbus_vuln(ip, port502): sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) try: sock.connect((ip, port)) read_pkt struct.pack(HHHBBHHHH, 0x0001, 0x0000, 0x0006, 0x01, 0x03, 0x0000, 0x0002) sock.send(read_pkt) resp sock.recv(256) print(read response:, resp.hex() if resp else EMPTY) finally: sock.close()这类脚本可以批量巡检多个IP输出结果自动对比“期望配置基线”。我一般把基线文件放在/etc/security/baseline/下面检查脚本每跑一次就生成一个新报告diff一下就可以看出设备配置被改了什么。4.3 如何把自查脚本接入设备自检流程合规自查脚本不能只在测评前跑一次最好挂进设备日常自检流程。嵌入式Linux可以用systemd timer也可以用开机脚本延迟执行。生产环境建议写成systemd service开机后30秒执行一次结果写到/var/log/security-check.log每天凌晨再跑一次防止运行期间配置被意外修改。脚本接入自检流程后还要注意两个坑一是别在巡检时把设备负载拉满检查项要拆成小批次二是别把审计日志明文存在世界可读的地方。报告目录建议用权限700日志通过syslog或rsyslog转发到集中审计平台这是“安全管理中心”里日志审计项会重点看的。合规报告里最好留一个“检查时间”字段并和NTP时间源对齐。没有统一时钟的审计日志很难作为合规证据这也是现场经常被整改的地方。5. 第18篇课后思考题完整解析5.1 思考题回顾上一讲结尾我留了三道思考题都是围绕嵌入式安全合规的实操问题。这一节统一解答顺便把题目背后设计的考点一起讲清楚。等保2.0工控扩展要求下嵌入式设备选型时从安全视角最需要关注的三个要素是什么一个Modbus TCP从站设备只允许上位机读取状态不允许远程写配置如何在不改造设备固件的情况下实现写保护合规自查脚本扫描到同一个IP开放了TCP/502端口如何确认它到底是不是真正的Modbus服务避免误报5.2 题目一解析嵌入式设备选型的安全三要素这道题考察的不是堆砌功能而是抓主要矛盾。很多采购清单喜欢写“支持国密算法”“支持TPM安全芯片”听着很全但到了工控现场真正决定合规上限的通常是三件事第一固件升级机制是否闭环。设备有没有签名的固件包、升级过程是否校验完整性、是否有回滚机制。固件无法安全更新的设备等保测评中“安全计算环境”的入侵防范项很难过关。第二默认服务最小化。出厂的Linux系统是不是只开了业务端口还是开着Telnet、FTP、SNMP默认口令。默认服务越少被扣分的面就越小后面主机加固的改造成本也越低。第三身份鉴别与审计能力。设备是否支持密钥认证、有没有本地日志和远程日志外发能力、日志能否附带可信时间戳。这直接对应“身份鉴别”和“安全审计”两大控制项。把这三个要素排序比堆安全功能更有工程价值。如果一台设备强制要求密码复杂度却连日志都不能外发那它在等保体系里依然是个孤岛。5.3 题目二解析不改固件实现Modbus TCP写保护这道题的本质是“外部安全组件如何对透明工控协议做业务语义拦截”。既然不能改PLC或从站固件就需要在这条链路上插入一个透明代理或前置安全网关。最常见的方案是构建一个透明Modbus TCP网关上位机把目标从站地址指向网关网关收到写请求后先解析功能码如果是0x06或0x10按策略直接拦截并给上位机返回Modbus异常码0x02非法数据地址或0x04从站设备故障。读请求正常转发。这样做的关键在于“透明性”。上位机那边不需要改软件但IP地址和路由要调整从站那边完全不感知中间设备因为TCP连接是网关代为建立的。实际操作时网关要做两层socket一个监听来自上位机的连接一个主动连向下游从站。应用层解析到功能码后决定是否转发。如果不想自己写代理也可以用eBPF钩到TC/netfilter路径只解析Modbus头里的功能码比应用层代理时延更低。但对大多数场景我仍推荐先做应用层代理逻辑清晰、测试方便、故障好排查。5.4 题目三解析如何识别真实的Modbus服务端口开放不等于业务可用更不等于协议一定是Modbus。合规自查脚本如果只看到502端口就报“Modbus暴露”在测评时很容易被反驳。正确的识别方式有两种一种是被动识别在链路上抓若干个包检查报文的协议标识符字段通常应为0x0000检查功能码是否落在常用功能码集合里检查事务标识符是否递增。如果一段时间内根本没有符合Modbus TCP特征的流量就不能判定为真实Modbus服务。另一种是主动探测主动构造一个读保持寄存器请求功能码0x03寄存器数量1若响应报文中功能码为0x03且数据长度字段匹配基本上可以确认是Modbus TCP。要注意的是主动探测请求只应该发到测试网络或得到授权的设备绝不能拿生产PLC当靶子否则一个错误请求可能触发从站异常停机。判断时还要留意有些设备会把Modbus TCP封装在Docker映射端口里还有的设备用Rust或其他协议框架实现兼容层响应字节序可能不同。所以脚本里最好同时记录TCP连接状态、响应延迟、响应内容把“端口开放”和“协议有效”区分开。6. 落地过程中的几个坑和我的习惯做法6.1 容易被忽略的合规细节第一个坑来自主动探测。一次巡检里我用脚本向一组Modbus从站发送0x06写请求本想测试从站是否会对非法写返回异常码结果其中一台老设备收到写保持寄存器请求后当场把运行参数清零。那次之后我改了规矩自查脚本里所有“写功能码”探测一律关闭只能针对自研测试从站跑生产网络只做被动抓包和只读功能码探测。第二个坑是时间同步。等保审计里要求日志时间准确但很多嵌入式设备默认不配NTP或者只在上电时同步一次运行几周后时间漂移。整改方法很简单把chronyd或systemd-timesyncd启用指定可信NTP源并把同步状态加入自查报告。可在实际现场很多安全团队只盯着漏洞和端口时间同步这种小项反而成了整改单上的常客。第三个坑是只读文件系统带来的“假合规”。有些设备做了只读根文件系统看起来很安全但业务运行目录、/var/run、/tmp没做内存盘日志和临时文件无限增长最终把存储耗尽。安全合规的前提是设备稳定运行所以加固时必须同时确认tmpfs挂载、日志大小限制、看门狗机制都在位。6.2 我的习惯做法基线即代码报告即证据最后分享一个长期养成的习惯。我在自研设备里不再手工维护“一套配置”而是把安全基线写进固件构建脚本。也就是说每次编译固件都会重新生成sshd配置、sysctl参数、iptables规则、文件完整性基线保证每台设备出厂即合规。自查脚本也会跟着固件版本走每次迭代都保留一份报告。这个做法的最大收益是测评时不用去现场临时解释配置是怎么来的直接给出历史报告和当前报告对比说服力完全不一样。对于已经部署的老设备也可以用配置管理工具定期推一遍基线避免现场人员手工改乱。做嵌入式安全合规不一定非要上多高端的设备把边界层、主机层、应用层的适配逻辑摸透再配合一套能自动生成报告的脚本大部分工控场景都能覆盖得比较扎实。功能码深度防护那块尤其值得在采购前先在小规模环境里做一轮验证因为每个现场的PLC、DCS协议行为都不完全一样拿一套通用规则直接上线迟早会出事。