说个这几天在安全圈里发酵的事Nacos 的 Derby 组件被曝出远程命令执行漏洞。如果你所在公司用了 Nacos 做配置中心和注册中心我建议先把手头的事放一放认真看完这篇。Nacos 在微服务体系里太常用了它管着配置、管着服务发现一旦本身出问题影响往往不是单台机器而是一整片业务。这个漏洞的名字也很直白——Nacos Derby 远程命令执行漏洞攻击者有机会通过 Nacos 内嵌的 Derby 数据库做到在服务器上执行命令。这篇文章不聊花哨的利用技巧重点讲清楚它是什么、怎么自查、怎么修复以及我在实际排查中踩过哪些坑。读完你至少能知道自己要不要应急。1. 漏洞背后的基础Nacos 与 Derby 各是什么1.1 Nacos 在微服务架构里的定位Nacos 是很多团队搭建微服务时绕不开的基础组件核心职能是两个配置管理和服务发现。配置管理解决的是“配置改一处所有服务生效”的问题服务发现解决的是“哪个服务实例在哪个地址、健康状态如何”的问题。简单说Nacos 就像整个系统里的“信息中枢”各个服务启动时找它拉配置运行中找它拿服务地址。正因为这个定位Nacos 在安全体系里的重要程度往往被低估。很多人觉得它不过是一个 Java 服务最多就是配置中心但实际上一旦 Nacos 被攻破攻击者能看到所有服务的配置信息包括数据库连接串、缓存地址、各类密钥和接口开关。这些东西的价值不亚于直接拿到一台跳板机。这也是为什么当 Nacos 出现高危漏洞时安全团队通常都会按照最高优先级处理。我在实际接触过的一些项目里甚至见过开发环境、测试环境、生产环境共用同一套 Nacos 的情况。安全团队明明只暴露了测试环境的入口但因为三套环境没隔离生产配置全部可以被读取。所以理解 Nacos 的定位再看这个漏洞你会发现它真正可怕的不是漏洞本身而是 Nacos 在架构中聚集了大量敏感信息。1.2 内嵌 Derby默认数据库的角色Derby 是一个纯 Java 编写的关系型数据库体积小、部署简单不需要单独安装数据库服务。Nacos 之所以默认选择 Derby很大程度是为了降低初次使用门槛单机模式下载解压就能启动配置存储这些事由内嵌 Derby 自动完成用户不用管数据库。简单理解一下这两层关系Nacos 是一个 Web 服务它需要一块地方保存配置数据。在单机模式下这块地方就是内嵌的 Derby 数据库。Derby 不是一个独立部署的进程而是跟着 Nacos 进程一起跑数据落在本地文件里。所以很多运维人员排查时下意识会看 8848 端口、看 Nacos 应用本身却忽略了应用内部还挂着一个数据库引擎。这里要澄清一个常见误解内嵌数据库不等于安全。Derby 虽然没有独立的网络监听端口但 Nacos 会通过自己的 HTTP 接口把数据库操作能力暴露出来。凡是能访问 Nacos 管理端口的人理论上都有可能触碰到后面的 Derby 操作入口。端口不独立不代表接口不暴露这是很多人栽跟头的地方。1.3 漏洞为什么会落在 Derby 身上Derby 本身不是什么“易攻破数据库”问题出在组合方式上。Nacos 为了管理配置提供了一些和数据库相关的操作能力这些能力在正常情况下应该被严格鉴权。但在某些版本和默认配置下访问控制不到位攻击者只要构造特定请求就可能让 Derby 去执行任意的 SQL 语句。更麻烦的是Derby 作为功能完整的数据库支持一些高级特性包括动态执行 Java 代码、调用系统命令等。这些能力本是给数据库管理员在特定场景下用的可一旦攻击者能控制输入它们就变成了从 SQL 注入升级到远程命令执行的桥梁。整个过程像什么呢就像一把多功能的瑞士军刀正常使用没问题但如果入口没人看管任何路过的人都能拿起来用危险程度自然成倍上升。所以看这个漏洞时不要只盯着“Derby”三个字要看到它背后的三层结构暴露在外的接口、不严格的鉴权、过强的数据库能力。后续修复和加固也要从这三层分别下手才能做到真正有效。2. 漏洞原理与影响远程命令执行是如何发生的2.1 攻击链路拆解不涉及潜在利用代码虽然官方没有公布所有技术细节但从多个公开分析和漏洞报告来看攻击链路大致可以拆成四步。第一步攻击者找到 Nacos 对外暴露的管理入口。Nacos 默认监听 8848 端口如果这个端口能通过网络触达攻击者就有了接触机会。第二步由于鉴权未开启或者鉴权存在绕过攻击者能够调用原本应该受保护的管理接口。第三步攻击者向这些接口提交恶意的 SQL 语句而该语句会直接进入 Derby 执行。第四步攻击者利用 Derby 允许执行 Java 特性的能力进一步调用系统命令。这里特别想强调很多人在分析漏洞时只看最后一步的命令执行觉得那是核心其实漏洞成立的前提是前面的访问控制失效。我们做修复时网络层面收口、开启鉴权、升级版本每一步都是在切断攻击链路中的某一环。如果只升级不收敛网络风险依然存在如果只封网络不开鉴权内部横向风险依然存在。分层防护的价值就在这里。2.2 远程命令执行的危害到底有多大说说“远程命令执行”这六个字的真实含义。攻击者一旦能在服务器上执行任意命令接下来能做的事简直太多了读取文件、创建账号、安装后门、下载恶意程序或者直接关闭安全服务。这些操作不需要多高深的技术只要权限允许顺手就能做。考虑到 Nacos 进程的运行身份如果部署时用的是 root 或高权限账号那攻击者拿到的就是 root 权限整台服务器就彻底沦陷了。就算不是 root攻击者也能以 Nacos 运行用户的身份读取配置数据、篡改服务注册信息进而影响业务系统。另一个容易被忽略的点是内网横向移动。很多时候攻击者并不是冲着 Nacos 本身来的而是把 Nacos 当跳板先拿下一台主机再通过内网访问其他系统。Nacos 这类基础组件往往部署在网络的核心位置周围连着大量业务服务一旦被突破后面就是一马平川。所以这类漏洞的影响范围绝对不能按一台机器来评估。2.3 哪些部署形态最危险结合行业里常见的部署方式和这次漏洞的触发条件我把风险等级分成三类大家可以对照自查。部署场景风险等级说明单机内嵌 Derby未开启鉴权可公网访问高攻击者不需要任何凭据入口直接暴露单机内嵌 Derby仅内网访问但鉴权弱或使用默认密钥中外部攻击难度高但内网失陷后横向移动容易集群部署使用外部数据库已严格鉴权网络有白名单低攻击面小但还要确认接口是否仍然开放这不是一个绝对的标准只是基于常见情况的判断。不同版本、不同配置下实际暴露面会有差异。我想表达的是不要因为自己“在公司内网”就觉得万事大吉。内网横向渗透是攻击者的惯用手段一台员工电脑被钓鱼、一台测试服务器被攻破都可能成为通向 Nacos 的跳板。3. 自查与排查先判断自己有没有踩中3.1 快速确认版本和部署模式排查的第一步是搞清楚两件事Nacos 是什么版本以及存储模式是不是内嵌 Derby。版本信息可以从几个地方看部署目录下的pom.xml、conf/application.properties、启动日志里的版本行或者登录控制台后底部显示的版本号。如果是在发布平台部署的看发布记录也行。拿到版本号以后对照官方安全公告确认是否在受影响范围内。存储模式也要确认。在conf/application.properties里找到配置数据源相关的内容如果没有配置db.url、db.user等外部数据库参数大概率就是单机内嵌 Derby 模式。如果配置了外部数据库连接说明存储已经切换但还要看 Derby 相关接口是否依然对外开放。这一步很快但不要靠记忆判断我见过不少团队负责人说“我们用的是 MySQL”结果一查MySQL 只是用了某个业务模块Nacos 本身还是 Derby。3.2 观察网络暴露和访问日志确认了版本和部署模式以后再看网络暴露面。登录服务器检查 Nacos 进程监听的地址和端口。如果监听地址是0.0.0.0:8848说明所有网卡都能访问能否从公网访问还要看云安全组和防火墙规则。如果绑定的是内网地址相对好一些但要继续确认防火墙是否只对可信来源放行。接着看访问日志。Nacos 的日志目录通常会有访问日志和nacos.log检索一些可疑特征比如包含derby、exec、shell、syscs等关键字的请求。如果发现来自非业务网段的 IP 频繁访问管理端口或者请求频率明显异常就要立刻警惕。注意在没有确认日志完整性的情况下不要指望日志里一定有攻击痕迹。日志被清理、日志级别没开全都是常见问题。日志排查是辅助手段不是唯一依据。3.3 判断有没有可能已经被攻击这里想提醒所有准备“直接打补丁”的同学如果主机已经失陷光升级版本相当于给房子换了把新锁小偷可能还在屋里。应急之前先快速判断有没有被入侵的痕迹主要包括几个方面。第一检查最近被修改的可疑文件重点看/tmp、/var/tmp、Nacos 目录下有没有来历不明的脚本、压缩包、二进制文件。第二看系统计划任务有没有新增条目很多后门是通过定时任务维持的。第三检查进程列表看有没有不认识的 Java 进程、抢占 CPU 的挖矿程序、连接外部 IP 的可疑进程。第四看系统用户列表和登录记录有没有新增的陌生账号有没有凌晨时段的异常登录。上面这些检查不需要复杂工具用几条命令就能完成。如果发现异常不要犹豫先把主机从网络上隔离保留现场证据再进入应急响应流程。安全问题的处置顺序很重要先止损再排查最后修复。4. 修复与加固从应急到常态化4.1 首要动作升级到修复版本针对这个漏洞最彻底的修复方式还是升级到包含修复的 Nacos 版本。升级时不要只看版本号“比较新”而要对照官方安全公告确认该版本确实修复了 Derby 相关的命令执行问题。升级前一定要做配置备份尤其是application.properties和外部数据源配置。升级后先在测试环境验证配置推送、服务注册、服务发现这些核心功能再推向生产。Nacos 这类组件一旦升级出问题影响的是所有依赖它的服务所以不要图快按变更流程走。如果暂时无法升级可以先把相关管理接口临时禁用比如通过防火墙规则或反向代理屏蔽可疑路径作为临时缓解措施。但临时缓解一定要设定到期时间问题拖久了就会变成常态这是运维上最常见的坑。4.2 网络层收敛别让 Nacos 裸奔无论是否升级网络层面的收敛都建议马上做。Nacos 是给内部服务用的组件正常情况下不需要对公网开放。在云安全组和防火墙上把源 IP 限制到运维网段、办公网网段或需要拉取配置的服务网段其他来源一律拒绝。同时检查 Nacos 进程的实际监听地址如果绑定的还是0.0.0.0试着改为具体内网 IP。这里要提醒一点修改监听地址后要确认服务消费者还能正常连接。因为有些跨网段的服务如果走公网或特殊路由改了绑定地址可能导致大面积连接失败。建议在测试环境先验证再在生产执行。很多漏洞攻击得手不是攻击手法多高明而是管理端口真的裸奔在公网上。把网络入口收住攻击者连敲门的机会都没有这是性价比最高的安全措施。4.3 开启认证与修改默认密钥升级和封网之后还有一个容易遗留的问题鉴权配置。Nacos 支持开启认证但不少团队因为历史原因一直没开或者开了认证却沿用默认密钥这样的鉴权形同虚设。开启认证时需要设置一个足够复杂的随机密钥并且妥善保存不要提交到 Git 仓库不要写在部署文档里。同时修改默认管理员密码改成强密码并且定期轮换。更高安全等级的环境可以考虑接入统一的认证系统用公司现有的账户体系做登录认证。配置完成后实际测试一下未登录状态是否真的无法访问管理接口不要只看配置文件里写着enabledtrue就觉得万无一失。安全配置以实际验证结果为准不以配置文件为准。4.4 审计与监控尽量在攻击过程早期发现安全加固做得再好也不能保证百分百不被突破所以监控和审计不能少。至少要覆盖三个层面。第一Nacos 访问日志要留存管理端口的登录尝试、配置变更记录、接口调用记录至少保留 90 天以上具体留存周期按公司合规要求来。第二对异常行为设置告警比如短期内大量登录失败、陌生 IP 访问管理端口、配置批量变更、Nacos 进程启动可疑子进程等。第三在主机侧部署安全 Agent 或文件完整性监控重点盯 Nacos 安装目录、配置文件、临时目录的变化。监控的意义在于即使攻击者真的突破了第一道防线安全团队也能在较早阶段发现并处置避免攻击者在内网里慢慢打洞、扩大战果。我见过不少安全事件明明日志里九天前就有异常登录但因为没人监控直到数据被加密勒索才发现。监控不是成本是保险。5. 实操总结我的排查经验与踩坑清单5.1 三个容易被忽略的坑第一个坑是以为内嵌数据库没有独立端口就安全。Derby 确实没有独立监听端口但它的操作入口在 Nacos 的 HTTP 接口上端口不独立不等于接口不暴露。很多团队在应急时只检查了 8848 端口是否对外开放却忽略了那些和 Derby 操作相关的管理接口排查范围一开始就窄了。第二个坑是升级后配置丢失或服务注册异常。我遇到过不止一次升级时图省事直接拷贝旧版的application.properties覆盖到新版本目录结果旧配置里既有外部数据库连接又残留了 Derby 相关配置启动后行为变得很奇怪。正确的做法是升级前 diff 配置逐个参数核对保留该保留的去掉该去掉的不要无脑覆盖。第三个坑是只给 Nacos 打了补丁没有盘点相关组件版本。Nacos 使用的客户端、内置的依赖库也可能存在其他已知漏洞。建议建一个资产台账把 Nacos 服务端、客户端、运维脚本、依赖组件全部登记在册定期对照漏洞情报排期修复。单点修复只是头痛医头系统性地治理才能避免下次再被同一个问题绊倒。5.2 一份可直接执行的排查命令清单下面这份命令清单是我在实际排查时常用的适合在没有专业扫描平台的情况下快速摸底。# 查看 Nacos 进程信息 ps -ef | grep nacos # 查看 8848 端口监听地址和对应进程 ss -lntp | grep 8848 # 查看系统最近登录记录 last -n 20 # 查看是否有可疑新增用户 grep -E nacos|admin|test /etc/passwd # 查看近期计划任务 crontab -l crontab -u root -l # 检查临时目录下的可疑文件 find /tmp /var/tmp -name *.sh -mtime -7 2/dev/null # 搜索 Nacos 日志中的可疑关键字 grep -iE derby|syscs_util|exec|shell|runtime /data/nacos/logs/nacos.log | tail注意这些命令只是辅助排查不能覆盖所有攻击痕迹。如果公司有条件建议直接把 Nacos 主机接入漏洞扫描平台和安全审计系统做一次针对性的安全检查。5.3 一个典型的处置案例某公司安全团队收到告警说配置中心存在高危漏洞。我协助排查时先通过堡垒机登录 Nacos 服务器查看版本确实在受影响范围。接着检查安全组规则发现管理端口对所有内网 IP 开放虽然还没发现公网攻击但内网横向移动风险非常高。当天先做了隔离在防火墙加白名单只允许运维网段的几台机器访问 Nacos。随后安排升级版本升级前备份了application.properties升级后验证配置推送和服务注册都正常同时修改了管理员密码。整个过程大概花了一个下午。复盘时我们发现这台 Nacos 已经上线两年多中间多次提示版本过旧但一直因为“线上稳定不敢动”被推迟升级。这次事件以后团队才真正把基础组件的版本维护提上日程。这个案例给我的感触很深技术漏洞往往不是最可怕的可怕的是长期无人维护带来的“历史欠账”。我个人在处理这类漏洞时体会最深的一点是不要只盯着“打补丁”这一步。先把资产摸清楚再按“网络收敛、开启鉴权、升级版本、持续监控”这个顺序推进。基础安全配置到位的情况下哪怕漏洞通告晚看到几天被利用的概率也会低很多。希望这篇关于 Nacos Derby 远程命令执行漏洞的文章能帮你先把应急方向理清楚少走一些弯路。