OpenSSH高危漏洞与Moxa交换机排查修复实战指南

最近安全圈讨论度最高的话题里，OpenSSH 和 Moxa 绝对排在前列。CVE-2024-6387 这个被命名为 regreSSHion 的严重漏洞，因为可以让攻击者在未认证的情况下触发远程代码执行（RCE），被很多安全公告直接标成了 Critical。而 Moxa 工业以太网交换机因为内置了 OpenSSH 组件，同样被卷进了这轮风暴里。

我最近在处理一批工业网络设备时，正好把 Moxa 设备的排查、验证和修复流程完整走了一遍。这篇文章不打算只念厂商公告，而是按实际处置思路，把漏洞原理、Moxa 设备的具体风险、无损检测方法以及修复加固流程串起来讲清楚，给正在处理同类问题的运维和安全同事一份可以直接照做的参考。

1. 漏洞背景：OpenSSH 严重漏洞与 RCE 风险的前因后果

1.1 这个漏洞到底有多严重：CVE-2024-6387 关键信息拆解

CVE-2024-6387 是 OpenSSH 在 2024 年 7 月被公开的一个远程代码执行漏洞，影响的版本区间是 OpenSSH 8.5p1 到 9.7p1，官方在 9.8p1 中完成了修复。它本质上是 2006 年 CVE-2006-5051 的回归，所以被安全社区称作 regreSSHion，意思是“当年的老问题又回来了”。

问题出在 sshd 的信号处理机制上。sshd 使用 SIGALRM 信号来管理登录超时，而信号处理器里调用了一些并非异步信号安全（async-signal-safe）的函数，比如 syslog。当信号处理和主逻辑同时访问同一块内存时，就会产生竞争条件，进而导致堆内存释放后又被使用，也就是 use-after-free。

攻击者不需要提前拿到账号密码，只要能在 sshd 处理超时的竞争窗口内不断触发请求，就有机会在受影响的系统上执行任意代码。由于 sshd 默认以 root 权限运行，一旦利用成功，攻击者拿到的就是 root shell。虽然不是所有系统都能稳定利用，但这个漏洞的触发面依然很宽：基于 glibc 的 Linux 系统、默认配置的 sshd、暴露到网络的 22 端口，几乎都满足前提条件。

对 IT 环境来说，一台服务器被 getshell 已经够让人头疼；对工业网络来说，这更是直接戳到了地基。Moxa 工业以太网交换机普遍使用嵌入式 Linux 系统，OpenSSH 是它最常见的远程管理通道之一，所以当安全意识强的团队开始排查时，会发现曝光在互联网上的 Moxa 设备数量比想象中多得多。

1.2 为什么工业交换机被重点点名：Moxa 首当其冲

Moxa 交换机在工业现场的地位很高，从工厂自动化到轨道交通、电力站控系统，几乎处处都有它。很多型号看起来是个“傻瓜交换机”，实际上内部跑的是精简 Linux，默认开放 Web 管理、SNMP、SSH 等服务。其中 SSH 又是运维人员最常用的远程维护通道，毕竟比 Web 界面稳定，也比 Telnet 安全。

但这恰恰是问题所在。工业交换机有几个特点，导致 OpenSSH 漏洞落在它头上时危害会被放大。

第一是生命周期长。一台 Moxa 交换机在现场跑七八年很正常，很多设备从上线开始就没升级过固件。厂商发布修复固件后，用户也很难在短时间内安排窗口去升级，因为涉及停产、业务连续性、备件等一系列问题。

第二是管理习惯差。很多集成商为了远程调试方便，会把 Moxa 的管理口直接接到办公网、核心业务网，甚至通过端口映射暴露到公网。一个 22 端口映射到公网的交换机，等于给全网扫描器送了一份“开门迎客”的邀请函。

第三是运维盲区。大多数企业的安全团队只盯服务器和终端，很少把网络基础设施，尤其是 OT 侧的交换机纳入漏洞管理流程。Moxa 设备常常处于“有 IP、有责任人、没人看安全公告”的状态。

第四是攻击链价值极高。交换机一旦被 RCE，攻击者可以查看和修改 VLAN 配置、改成端口镜像、抓取流经的业务数据，甚至把流量引到攻击者控制的设备上，成为内网横向移动的跳板。对工业网络来说，这远比一台普通 Web 服务器被入侵影响更大。

2. 影响评估：先搞清楚你的 Moxa 交换机是不是“易受影响”的那一批

2.1 三步自查：型号、固件与 OpenSSH 版本

面对这种安全公告，第一步不是急着打补丁，而是确认你手里的设备到底在不在影响范围内。Moxa 产品线很多，EDS、IKS、ICS、PT 系列等等，不同型号、不同固件版本的搭载情况完全不一样。我的做法是三步走。

第一步，登录设备 Web 管理界面，在 System Information 或者 About 页面找到产品型号和当前固件版本。如果 Web 管理界面已经无法访问，就通过 console 串口线登录查看。很多设备在登录后的欢迎信息里也会显示固件版本。

第二步，去 Moxa 官网查安全公告。搜索 “Moxa Security Advisory” 或者直接搜型号加 OpenSSH 关键词，在公告中比对受影响型号和修复固件版本。这里有一个很需要注意的地方：不是所有 Moxa 型号都受影响，同一个型号的不同固件版本也可能一个有问题、一个没问题。不要凭印象判断，必须比对官方清单。

第三步，如果设备能进入 shell，可以执行sshd -V或ssh -V查看 OpenSSH 版本；如果设备不支持 shell 命令，可以用扫描方式识别 SSH banner。做完这些之后，把所有信息整理成表格，记录 IP、型号、固件版本、OpenSSH 版本、管理面暴露情况、责任人，方便后续按优先级处理。

2.2 最容易出事的三个网络场景

我在排查过程中发现，同样一台 Moxa 交换机，风险高低完全取决于它接在哪、谁能访问它。以下三种场景是我认为最需要优先处理的。

场景一是管理口直连公网。这种情况最常见于远程运维需求强烈的中小型项目，或者外包集成商为了自己调试方便留下的“后门”。攻击者用全网扫描就能发现这类设备，再配合 CVE-2024-6387 这类漏洞直接远程打穿。遇到这种连接方式，无论漏洞是否实际影响，都必须第一时间整改。

场景二是管理口接在办公网段，IT 网络和 OT 网络没有严格隔离。攻击者可能先通过钓鱼邮件、Web 漏洞打进办公网，再横向扫描内网网段，发现 22 端口后尝试利用漏洞。这种路径在攻防演练里非常常见，而且 Moxa 设备往往不在安全团队的监控范围内，被入侵很久都发现不了。

场景三是管理 VLAN 和业务 VLAN 共享广播域，或者 ACL 配置形同虚设。有些现场虽然划分了 VLAN，但没有限制谁可以访问管理地址，任何一台接入业务网的设备都能直接 ping 通交换机的管理 IP。这种情况下漏洞利用门槛进一步降低。判断设备风险，首先看“谁能访问 22 端口”，其次才是版本号。

3. 漏洞检测实操：在不动生产的前提下做一次无损排查

3.1 通过设备管理界面收集信息

在工业环境里，最忌讳的事就是在一个正在运行的网络上乱跑扫描器。如果设备 Web 管理界面还能登录，优先通过界面收集信息，尽量避免主动探测带来的风险。

登录 Web 管理界面后，重点看几个地方：System Information 页面看型号和固件版本；Service 或 Network Service 页面看 SSH 服务是否启用、端口是多少、认证方式是密码还是密钥；有些新固件还会显示 OpenSSH 版本。如果厂商在界面上提供了“检查更新”或“安全补丁”入口，可以直接点击查看是否有可用更新。

这里要提醒一点，设备 Web 管理界面本身也是管理面，如果暴露在办公网或公网，同样存在被攻击的入口。所以收集信息的过程尽量在带外网络或者维护窗口进行，不要在业务高峰现场开一堆页面。

如果设备提供命令行接口，可以登录后执行show version、display version之类的命令查看固件信息。对于支持 shell 的设备，sshd -V可以准确显示 OpenSSH 版本。注意，不是所有系列都支持随意执行系统命令，不要因为好奇去尝试危险操作。

3.2 用端口扫描和固件公告交叉确认

当设备 Web 界面不可用、或者需要通过外部视角确认管理面暴露情况时，我会使用 nmap 做一次轻量扫描。命令很简单：

nmap -sV -p 22 --script ssh2-enum-algos <设备IP>

这条命令的作用是连接目标 22 端口，获取 SSH banner 并枚举支持的密钥交换算法。通过 banner 能直接看到 OpenSSH 的版本号，再和漏洞影响区间比对，可以初步判断风险。但这里有一个很关键的坑：banner 显示的版本号不一定是实际运行版本。有些厂商会在维护版本中 backport 安全补丁，版本号可能依然是 OpenSSH 8.6，但漏洞已经修复；反过来，banner 也可能被人为修改，隐藏真实版本。

所以，扫描结果只作为初筛。最终判断必须以 Moxa 官方安全公告为准。如果扫描器显示版本在受影响区间，而公告没有列出这个型号，就按照“潜在受影响”处理，先限制访问、持续跟踪，不要轻易放过。

在 OT 网络里跑扫描之前，一定要提前通知相关人员，选择低峰窗口。扫描行为本身对网络是安全的，但会引起入侵检测设备告警，也要避免扫描到 PLC、RTU 等脆弱设备造成意外响应。

3.3 哪些“验证”动作绝对不要做

很多安全意识强的同事听说漏洞后，第一反应是想自己验证一下。这种热情可以理解，但在生产环境里，有几件事是我强烈不建议做的。

第一，不要在生产 Moxa 设备上跑网上流传的利用脚本或者概念验证程序。CVE-2024-6387 的利用过程涉及反复触发 sshd 的竞争条件，很可能导致 sshd 崩溃，进而让交换机失去远程管理能力。对于工业交换机来说，ssh 服务崩溃不算灾难，但如果在同一设备上还承载着其他管理通道，就有连锁影响。

第二，不要通过暴力尝试 SSH 登录来“测试漏洞”。这既不能证明漏洞存在，还会刷爆日志，甚至触发账号锁定策略，给正常运维带来麻烦。

第三，不要从来路不明的公众号、论坛下载所谓“漏洞检测脚本”直接上传到设备执行。攻击者也可能利用这种心理投毒，让你亲手把后门装进工控网络。

正确做法是，把需求告诉厂商技术支持，让厂商提供官方检测工具或确认方法；或者在自己的实验环境里用相同版本搭建测试系统，验证充分后再决定是否对生产设备采取措施。

4. 修复与加固：Moxa 交换机安全处置的完整路径

4.1 升级 Moxa 官方修复固件的标准流程

当确认设备受漏洞影响，且 Moxa 官方发布了修复固件时，升级是唯一彻底的办法。我建议按以下流程操作。

第一步，从 Moxa 官网下载与你设备型号完全匹配的修复固件。下载后立即校验文件哈希值，使用sha256sum或md5sum对比官网提供的值，确保固件完整且未被篡改。这一步不能省，固件损坏是升级失败最常见的元凶。

第二步，备份当前配置。登录 Web 管理界面，在 System 或 Configuration 页面导出配置文件，保存到本地。有些型号支持导出二进制配置文件，有些支持文本格式，两种都可以。备份后还要核对备份文件中是否包含用户名、密码、VLAN 配置等关键信息，避免升级后无法恢复原有网络结构。

第三步，规划维护窗口。工业交换机升级会导致业务中断，必须提前与现场操作人员确认停机时间，评估升级期间对产线、控制系统的风险。如果交换机承载关键流量，尽量选择停产检修时段，并在现场安排工艺人员值守。

第四步，执行升级。在 Web 界面的 Firmware Upgrade 页面上传固件。部分型号也支持通过 TFTP/FTP 方式升级，需要提前准备好文件服务器，并确保设备可以访问到该服务器。上传之后，设备会自动校验固件并重启，这个过程通常需要几分钟。

第五步，升级完成后，重新登录设备，确认固件版本已经更新、原配置是否保留、管理端口是否正常工作、业务端口状态是否恢复。如果升级后配置丢失，立刻从备份导入，并逐项核对 VLAN、端口速率、SNMP 等设置。

第六步，如果升级失败导致设备无法启动，可以通过 console 口进入引导加载程序，手动重新加载固件。这也是为什么我反复强调现场必须保留 console 线的原因。

注意：升级过程中绝对不要断电。工业交换机固件升级时断电，轻则固件损坏，重则设备变砖。一定要使用不间断供电的电源，或者确认现场供电稳定后再操作。

4.2 临时缓解措施：官方补丁到位前怎么撑住

有些情况下，官方修复固件还没有发布，或者现场无法在近期安排升级窗口。这时必须靠临时缓解措施降低风险。按效果从高到低排序，我的建议如下。

最有效的手段是限制 SSH 访问源。在 Moxa 设备自带的防火墙功能或者上游核心交换机上配置 ACL，只允许管理网段内的固定 IP 访问 22 端口，其他源地址一律拒绝。如果设备管理口必须暴露给远程维护，至少要通过防火墙源 NAT 和 IP 白名单做双重限制。

第二种手段是直接关闭 SSH 服务。如果现场没有使用 SSH 做远程管理的需求，只是默认开放了而已，那么在 Web 管理界面的服务列表里把 SSH 关闭，攻击面就没了。远程维护可以临时改用 Web 管理界面或串口 console。关闭服务前要先确认其他管理通道可用，免得给自己锁在门外。

第三种手段是暂时禁用密码登录，改用公钥认证。Moxa 设备的 SSH 服务通常支持配置认证方式，把密码认证关闭后，攻击者即使想爆破也需要先具备私钥。但这措施只增加攻击门槛，并不能完全防御 RCE 漏洞，所以只能作为辅助手段使用。

第四种手段是网络隔离。将 Moxa 设备的管理口单独划入管理 VLAN，与业务 VLAN 物理或逻辑隔离，并在三层设备上禁止管理 VLAN 流量跨网段访问。这样攻击者即使打进了业务网，也需要先突破网络边界才能触达交换机管理口。

不要忘记，在落实这些缓解措施的同时，把临时方案记录到文档里，设置一个明确的复审日期。临时缓解永远只是拖延时间的手段，不能代替最终修复。

4.3 长期加固：把工业交换机管理面收进“保险箱”

经历过这一轮漏洞风波后，我强烈建议所有工控网络负责人做一次长期加固，而不是等下一个高危漏洞曝出来再应急。

先把所有网络设备，尤其是一线交换机，纳入资产管理数据库。记录内容至少包括设备型号、固件版本、安装位置、承载业务、管理方式、责任人、维护窗口。很多单位在这轮排查中卡住的根本原因，就是根本不知道现场有多少台 Moxa，自然也无从谈起修不修。

管理面统一走带外管理（OOB）。所谓带外，就是通过独立的物理链路访问设备管理口，不依赖业务网络。即使业务网络被攻击者打穿，管理面仍然是隔离的。如果条件不支持独立的带外网络，至少要把管理流量放到专门的管理 VLAN，并用防火墙彻底限制访问。

默认密码必须修改。Moxa 设备出厂账号密码公开可查，很多现场几年不换密码。别以为工业设备“没人知道”，扫描器可以轻松识别 Moxa 品牌，然后使用公开默认密码尝试登录。配合 OpenSSH 漏洞，攻击者完全可以在你的网络里“逛花园”。

关闭用不到的服务。SNMP、Telnet、HTTP 管理页面、FTP 文件服务，凡是业务不需要的统统禁用。服务越少，能被利用的面越小。如果只通过 SSH 管理就足够，那就把 Web 管理也关掉，或限制到内部少数运维主机。

最后，定期跟踪厂家安全公告。Moxa 这类厂商都有安全公告页面，建议配置订阅提醒。不要等漏洞新闻炸出来再去查，而是形成常态化的月度安全审查机制。

5. 延伸实战：Linux 服务器升级 OpenSSH 的避坑指南

这次漏洞影响的远不只 Moxa。你的网络里那些运行 CentOS、Alibaba Cloud Linux、openEuler 的服务器，如果 OpenSSH 版本在影响区间，同样需要处理。这部分我结合最近的升级经验，把最容易踩的坑提前讲清楚。

5.1 优先使用发行版补丁：CentOS、Alibaba Cloud Linux、openEuler 怎么处理

很多人在处理 OpenSSH 漏洞时，第一反应就是下载最新源码手动编译。其实这是最有风险的方式，能不动源码就尽量不要动。

发行版维护者通常会把安全修复以 backport 方式移植到原有的 OpenSSH 版本里，所以版本号看起来依然不是 9.8p1，但漏洞实际已经修复。这也是为什么不能只看版本号就判断是否受影响。正确的处理顺序是先看发行版软件源有没有更新。

CentOS 和 RHEL 兼容系统：

yum update openssh openssh-clients openssh-server

Alibaba Cloud Linux 3：

dnf update openssh openssh-clients openssh-server

openEuler：

yum update openssh openssh-clients openssh-server

执行完更新后，需要重启 sshd 服务让新版本生效：

systemctl restart sshd

如果你的发行版软件源还没有发布修复补丁，再考虑源码升级。另外要注意，更新前备份/etc/ssh目录非常关键，尤其是sshd_config和主机密钥。主机密钥不需要重新生成，沿用原文件即可，避免客户端收到主机密钥变更告警。

5.2 源码编译升级 OpenSSH 的核心步骤与回滚方案

在特殊情况下需要从源码编译升级 OpenSSH 时，我推荐使用下面的流程，这条流程在测试环境里已经跑过很多次。

# 安装编译依赖 yum install -y gcc make zlib-devel openssl-devel pam-devel # 下载源码并校验 wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gz sha256sum openssh-9.8p1.tar.gz # 解压、配置 tar -xzf openssh-9.8p1.tar.gz cd openssh-9.8p1 ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-pam --with-md5-passwords --with-tcp-wrappers make -j$(nproc) make install

编译前必须做几件事：备份/etc/ssh/sshd_config，备份现有sshd和ssh二进制文件，另外打开一个临时备用会话。最简单的办法是先用 systemd 开启一个 telnet 会话端口作为保底，或者确保当前 SSH 连接绝不中断。我在操作时通常会开至少两个 SSH 会话，一个留在终端，一个用来重启服务，万一重启失败，还能用另一个会话恢复配置。

make install之后不要急着重启，先执行sshd -t检查配置文件是否有语法错误。如果配置没问题，再重启 sshd。重启之后，先在备用会话里测试能否正常登录，确认新连接没问题后再关闭旧会话。

如果升级后 sshd 无法启动，先不要慌。检查日志/var/log/messages或者journalctl -u sshd，大部分问题出在 PAM 配置或者/etc/ssh目录权限上。目录权限要求一般是700，私钥文件是600。有时候 SELinux 上下文不对也会导致 sshd 起不来，执行restorecon -Rv /etc/ssh可以解决。最坏的兜底方案是用备份的二进制文件覆盖回来，或者使用发行版自带的 openssh 包重新安装：

yum reinstall -y openssh-server openssh-clients

源码升级最大的风险不是编译失败，而是编译完成后由于动态库路径、PAM 模块差异导致系统无法正常登录。所以如果你的系统可以通过软件源获取修复版本，真心不建议折腾源码编译。

5.3 升级后的配置验证与日志审计

升级完成不等于万事大吉，还要做一轮验证和审计。首先ssh -V确认版本号；然后从一个新终端发起 SSH 连接，确认密码认证、公钥认证、SCP/SFTP 功能都正常。不要只看能登录就结束了，要多测试几种日常使用的功能，避免升级后某天突然有人反映文件传不上去。

查看日志也很重要。系统日志里应该能看到 sshd 正常启动的信息：

grep sshd /var/log/secure | tail -30

如果发现大量 Failed password 日志，说明你的服务器已经被扫描器盯上了，需要加强密码强度或者改为公钥认证。升级窗口结束后，把每台主机的 IP、升级时间、原版本、新版本记录到运维台账里，后续做漏洞管理时直接用这份清单对照，效率会高很多。

有条件的话，给 SSH 服务加一层监控。使用 Wazuh、OSSEC 或者 zabbix 监控 sshd 日志和进程状态，发现异常登录、频繁爆破时及时告警。服务器安全从来不是一次升级就能一劳永逸的，持续监控才是常态。

6. 常见问题与排查技巧实录

6.1 问题速查表

这一节把最近处理过程中遇到的高频问题整理成了一张速查表，方便现场对照处理。

6.2 我的几条独家处置心得

处理完这一整轮问题，我有几个很深的体会想分享。

第一，先清点后补丁，别一上来就全网扫描和升级。工业网络能稳定运行靠的是不乱动，先建立清单，按照风险优先级处理：公网暴露的设备最优先，办公网可达的其次，管理 VLAN 内部的可以放缓。慌乱操作才是这次漏洞最大的敌人。

第二，升级 Moxa 设备时，手里务必有一条 console 线。现场见过太多因为升级失败导致 Web 和 SSH 都连不上，只能抱着设备干瞪眼的案例。console 口是最后的逃生通道，没有这条线，别轻易动固件。

第三，不要把 OpenSSH 版本号当成唯一判断依据。Moxa 和其他厂商都有可能 backport 修复，版本号没变不代表漏洞还在；反过来，版本号高于 9.7 也不等于绝对安全，仍然要确认实际运行固件是否包含完整修复。

第四，临时缓解措施一定要落到文档里，设置复审日期。光靠脑子记，半年后谁都不记得当初为什么开这个防火墙规则，漏洞可能还在那里，防护手段却已经被人为删除。把缓解措施写进运维交接文档，才能确保它真正执行到补丁到位那天。

最后一句话送给做工控安全的朋友：OT 环境里的高危漏洞不会因为设备“冷门”就不被攻击，扫描器比你想象中更了解 Moxa。但只要按正确顺序处理，稳住管理面、收紧暴露面、稳妥推进补丁，风险完全可以控制在可接受范围内。