DMIT发安全通报了

Eic 2026-08-29 23:18 1

一、事件时间线

2026 年 8 月 26 日 16:00–18:00(美东时间) 该时段处于业务低峰。DMIT 在此期间检测到一批特征异常的流量:规模不大,但请求构造、目标路径与后续大规模滥用流量完全一致。我们判定其为试探性流量,即攻击方在正式利用前对可用出口进行的验证与筛选。

次日凌晨 3:00–4:00(美东时间) 网络边界出现异常流量增长,短时间峰值接近 100 Gbps。经排查确认,流量来源并非 DDoS 攻击,而是部署在客户虚拟机上的一类 SNI 代理应用程序。

8 月 26 日至今 DMIT 已就该问题发出两次邮件通知,并对确认存在开放代理行为的实例执行了关机处理。两次通知中均提供了整改说明与工单支持渠道。仍有相当数量的实例在恢复运行后未做任何整改,缺陷原样存在,并再次被第三方利用。

低峰试探与随后的峰值利用之间的间隔,是本次事件中最值得注意的一点。它说明攻击方并非随机扫描后立即打满,而是先完成了出口可用性的清点,再统一发起。

二、缺陷说明

该类应用在处理 SNI 转发时未对请求来源与目标做有效校验。其后果是:互联网上的任意第三方,无需持有该实例的任何凭据,即可通过客户的虚拟机强制代理访问 Cloudflare 及其后端的 OpenAI 资源。

运行该类应用的客户实例,实质上是一个面向全网开放的匿名 AI 请求出口。

三、缺陷验证方式

关于 DMIT 的判定方式,我们完整披露如下:

既然客户的虚拟机可以被任意第三方利用,DMIT 同样可以利用该缺陷本身进行探测。 我们对相关实例执行了与攻击者相同路径的连通性验证,以确认缺陷是否真实可被利用,而非依据端口特征或流量模式做推断。

这同时决定了我们的判定标准:我们判定的不是"客户是否运行了某个软件",而是"该实例此刻是否可被任意第三方作为匿名出口使用"。 自用与否,与该端口是否对全网开放,是两件事。

该探测仅用于判定缺陷是否存在,不涉及读取或留存客户数据。

四、DMIT 必须处置的原因

4.1 主要原因:滥用行为具有明显的组织化特征

DMIT 判断,本次缺陷利用并非零散试探,而是有组织的 AI 资源滥用。可能形态包括第三方 AI 中转服务、API 代理售卖,以及模型蒸馏训练所需的大批量数据采集。

依据有二:

其一,攻击者能够在短时间内产生构造正确、且可持续返回大量数据的 OpenAI 请求。这意味着攻击方大概率持有批量的"合法"API 凭据或其他有效请求来源。单纯的扫描行为不会呈现这一特征。

其二,即前述低峰时段的试探性流量。先探测、后集中利用,是有预谋、有资源调度能力的行为模式,与机会主义式的滥用有本质区别。

流量规模、请求构造质量、持续性与预备动作共同指向一个结论:客户实例正被用作规模化数据获取链条中的匿名出口层。

4.2 IP 与 ASN 资源的信誉风险

一旦大量 AI 服务提供商将 DMIT 的 IP 段与 ASN 标记为恶意代理或滥用来源,后果由全体客户共同承担:IP 段进入风控名单、正常业务请求被拦截、优化线路价值受损。此类标记的撤销周期以月计,且往往不可完全恢复。

DMIT 必须主动清理已被恶意使用、以及可被恶意使用的资源,而不是等待外部机构代替我们做出判定。

4.3 不作为可能被认定为"协助"

在已发出两次通知、已明确知悉缺陷存在与流量用途的前提下,继续容许相关实例运行,客观上构成对第三方行为的便利提供。

"协助第三方进行 OpenAI 模型蒸馏"这一认定,对 DMIT 本身,以及对所有在 DMIT 平台上正常使用 AI API 服务的客户,都是明确不利的。我们不会让少数拒不整改的实例,把全体客户的业务连续性置于该风险之下。

4.4 次要原因:边界容量与全网服务质量

DMIT 客户虚拟机普遍配置 2 至 10 Gbps 端口。近千台实例短时间全速并发足以耗尽边界容量,影响平台上所有客户的网络质量。

我们如实说明:即便不做处置,相关实例通常会在 1 至 2 小时内耗尽流量配额而被自动限速或超量停机,对 DMIT 的计费收入并无差别。但对客户而言,流量配额被陌生第三方无偿消耗殆尽,影响是显而易见的。 我们将此列为次要原因,是因为它虽然直接,但可自愈;而前三项风险不会自愈。

五、后续处置

针对经两次通知后仍未整改的实例,DMIT 将采取包括暂停服务、终止服务及费用追偿在内的措施。

具体处置内容、判定依据与恢复条件,将以第三次邮件通知的形式向受影响客户单独说明。 本通报不构成对具体账户的处置决定。

六、这是一个行业性问题

本次事件的根源是客户侧软件的通用缺陷,社区已在互联网多家服务供应商处大量发现同类问题。据我们所知,其他数据中心可能尚未遭遇达到 DMIT 8 月 26 日规模的大规模利用。这不代表其平台不存在同类实例,更可能只是尚未被攻击方选中。

我们选择公开通报,一是让客户完整了解自己的实例发生了什么,二是希望这份信息对同业与社区有所参考。




其中这段“这同时决定了我们的判定标准:我们判定的不是"客户是否运行了某个软件",而是"该实例此刻是否可被任意第三方作为匿名出口使用"。 自用与否,与该端口是否对全网开放,是两件事。” 就是明说你们建梯子可以,别被人利用来攻击就好


而且这样搞会让openai直接风控所有ip段,佬们最好还是自查一下

最新回复 (8)
  • linuxbest 08-29 23:19
    1

    别啊 我才刚刚入手哇

    求openai大人放过

  • jinyu30 08-29 23:20
    2

    不要用reality偷使用了cloudflare cdn的sni即可避免

  • Nobody_233 08-29 23:20
    3

    虽然跟这个事情没关系 但是日本的服务器多久刷新呀… 是跳票了吗

  • linuxbest 08-29 23:21
    4

    我是在隔壁收的,dmit本身一般很久才刷新一次

    考虑到硬件价格 估计要到圣诞节了

  • Nobody_233 08-29 23:23
    5

    现在有个gomami 但是还是想用dmit.. gomami的上下行感觉有点不达标emm 我用bandwagon都可以跑到500mbps 但是gomami只有30-100mbps

  • sunfly 08-29 23:47
    6

    这种没用cf sni的也不好找吧~

  • sunfly 08-29 23:57
    7

    @jinyu30 不是很懂,方便展开说说吗,之前看233boy脚本里面,偷的都是bing、微软、亚马逊、苹果这样的大厂,这个估计都套了cf了,明显应该不行了

    隔壁看到说可以用国内域名或者自己的域名,不知道行不行,自己的域名要托管国内还是国外也行

    要不能不能偷别的节点的域名哈哈

  • jinyu30 08-30 00:05
    8

    reality协议目的是伪造和权威域名一样的流量特征,对外表现为端口转发,因此对于非代理流量会直接转发到目标域名上。路径为:


    Client (curl OpenAI) → DMIT (Reality forward) → OpenAI

* 帖子来源Linux.do
返回