为什么 2016 年 10 月的 Dyn 攻击仅限于东海岸?

信息安全 dns ddos
2021-08-25 21:12:59

互联网上的地图显示,Dyn DDoS 攻击的重点在美国东海岸。但为什么?

我的 DNS 提供商不在东海岸,我位于科罗拉多州。我的 DNS 是 8.8.8.8(谷歌公共 DNS)。然而,当我尝试访问 twitter.com 时,我的计算机无法解析该名称。

假设 DNS TTL 过期,Google 不得不发出递归查询,最终到达 Dyn,这可能是 twitter 的权威 DNS。(这是真的吗?)假设 Dyn 无法回答。这仍然无法解释为什么这次袭击会在地理上集中在东海岸。

有人可以解释吗?

3个回答

互联网上的地图显示,Dyn DDoS 攻击的重点在美国东海岸。但为什么?

这是因为第一波攻击主要发生在东海岸的芝加哥、华盛顿特区和纽约,那里有 Dyn 的三个 DNS 数据中心。

我的 DNS 是 8.8.8.8(谷歌公共 DNS)。然而,当我尝试访问 twitter.com 时,我的计算机无法解析该名称。假设 DNS TTL 过期,Google 不得不发出递归查询,最终到达 Dyn,这可能是 twitter 的权威 DNS。(真的吗?)

你是绝对正确的,这可能已经发生了,谷歌的 DNS 缓存条目可能已经过期,它必须对没有响应的 Dyn DNS 服务器进行递归查询,原因如下:

  • 您在科罗拉多州,连接到某个 XYZ ISP。当您尝试打开 twitter.com。机器尝试从 8.8.8.8 获取它的 IP 地址,这是您在机器中使用的 DNS。
  • 现在 8.8.8.8 不属于 XYZ ISP 它属于可能在科罗拉多州或其他地方(可能在东海岸)的 Google,即使 8.8.8.8 是或本来在科罗拉多州,您的 ISP 也可能无法连接到它(直接)。所以它可能仍然是从其他地方(可能是东海岸)获得最佳路线(到 8.8.8.8)。饱和点:有 N 个 Google 的公共 DNS 服务器位于不同的位置,并且您不知道要查询到哪一个(这取决于您的 ISP 到 8.8.8.8 的最佳路由)这是一个任播的概念,其中相同IP 地址位于多个位置,以提供更高的服务可用性。
  • 假设您的查询达到 8.8.8.8,并且正如您所说,twitter.com 的 TTL 已过期。现在 8.8.8.8 必须进行递归查询来为您获取 twitter.com 的地址,因此它必须经过询问 Root Name Server -> gTLD -> twitter.com 的根服务器的过程(在本例中为 Dyn托管)从查询到 gTLD 的以下服务器。
prok-MacBook:~ anirudh_malhotra$ dig twitter.com @g.gtld-servers.net.

; <<>> DiG 9.8.3-P1 <<>> twitter.com @g.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11045
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;twitter.com.         IN  A

;; AUTHORITY SECTION:
twitter.com.      172800  IN  NS  ns1.p34.dynect.net.
twitter.com.      172800  IN  NS  ns2.p34.dynect.net.
twitter.com.      172800  IN  NS  ns3.p34.dynect.net.
twitter.com.      172800  IN  NS  ns4.p34.dynect.net.

;; ADDITIONAL SECTION:
ns1.p34.dynect.net.   172800  IN  A   208.78.70.34
ns2.p34.dynect.net.   172800  IN  A   204.13.250.34
ns3.p34.dynect.net.   172800  IN  A   208.78.71.34
ns4.p34.dynect.net.   172800  IN  A   204.13.251.34

;; Query time: 146 msec

请注意,twitter.com 有四个名称服务器,它们将告诉 8.8.8.8 twitter.com的 IP 是什么,现在显然 Dyn 想要拥有相同名称服务器的多个位置(任播,就像 google 的公共 DNS)和还希望名称服务器位于不同的位置(可能一些在东海岸,一些在西部,甚至一些在美国以外)

  • 因此,当 8.8.8.8 再次查询这些名称服务器之一时,它可能会或可能不会去东海岸服务器,这完全取决于:到这些服务器的最佳路由是什么(或者更确切地说是这些服务器的 IP)

结论:当攻击发生在东海岸时,twitter.com 无法在科罗拉多州的 XYZ ISP 中工作,因为您正在查询位于东海岸的 8.8.8.8 服务器,该服务器正在查询受东海岸影响的 Dyn 服务器(由于到它的附近并从那里获得最佳路线)或者 8.8.8.8(可能仍在西海岸)仍然会查询 Dyn 东海岸受影响的服务器,因为从那里的最佳路线。因此,出于完全相同的原因,即使是坐在印度的我也可能无法获得 twitter.com(尽管极不可能,因为大量裁员)。

如果我们具体谈谈twitter.com的案例;为什么无法从东海岸访问该站点以及为什么可以从世界其他地方访问该站点(大致)。

BGP 从多个位置路由同一 IP 网络的公告,并且在不同位置存在基础设施是您查询的答案。

在从多个开放解析器中挖掘 twitter.com 时,我得到了所述域的多个 IP 地址,但它们都属于同一个 /24 IP 网络。

Kansals-MacBook:~ Kansal$ dig twitter.com A +short @4.2.2.4 104.244.42.193 104.244.42.65 Kansals-MacBook:~ Kansal$ dig twitter.com A +short @8.8.8.8 104.244.42.129 104.244.42.65 Kansals-MacBook:~ Kansal$ dig twitter.com A +short 104.244.42.65 104.244.42.193 Kansals-MacBook:~ Kansal$ dig twitter.com A +short @8.20.247.20 104.244.42.129 104.244.42.1 Kansals-MacBook:~ Kansal$

因此,twitter 站点托管在 104.244.42.0/24 段上(仅从不同位置从该段获取 ip;可能存在极端情况)。

在为这个 IP 段做WHOIS时,我知道了以下结果 -

Kansals-MacBook:~ Kansal$ whois 104.244.42.65 NetRange: 104.244.40.0 - 104.244.47.255 CIDR: 104.244.40.0/21 NetName: TWITTER-NETWORK NetHandle: NET-104-244-40-0-1 Parent: NET104 (NET-104-0-0-0-0) NetType: Direct Assignment OriginAS: AS13414 Organization: Twitter Inc. (TWITT) RegDate: 2014-12-08 Updated: 2014-12-08

这意味着104.244.40.0/21 IP 段属于 twitter。

Twitter 已从其遍布全球的各种数据中心(或托管设施)宣布了这一细分市场(/21 或 /22 或 /24)。
所以,当我请求 twitter.com 时,我去了新加坡(因为我正在从新加坡获得这个特定部分的最佳路线)当有人试图从东海岸访问 twitter.com 时,他可能拥有该部分的最佳路径从受到 DDoS 攻击的位置。

由于此公告可能来自多个位置的 IP 段以及全球基础设施的存在,服务仅受到影响(受到攻击的位置)。

希望这能回答您的问题。

地理负载平衡的 DNS 有关详细信息,请参阅以下答案:

https://security.stackexchange.com/a/140517/9195

我还要指出,由于 BGP 缩放技巧,您在 8.8.8.8 中遇到的系统可能不是我在 8.8.8.8 中遇到的系统。对于某些 DNS 查询,我们会得到不同的结果(可能只是 Google 的站点和地理负载平衡的站点),但否则它们将是相同的。

FWIW:我从多个位置看到以下 Twitter 信息,看起来他们所有的 DNS 服务器当前都托管在 dynect.net Dyn DNS 上:

挖 -t NS twitter.com

; <<>> DiG 9.8.1-P1 <<>> -t NS twitter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41734
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;twitter.com.           IN  NS

;; ANSWER SECTION:
twitter.com.        82622   IN  NS  ns2.p34.dynect.net.
twitter.com.        82622   IN  NS  ns3.p34.dynect.net.
twitter.com.        82622   IN  NS  ns4.p34.dynect.net.
twitter.com.        82622   IN  NS  ns1.p34.dynect.net.

;; Query time: 8 msec
;; SERVER: 173.203.4.8#53(173.203.4.8)
;; WHEN: Sat Oct 22 06:39:33 2016
;; MSG SIZE  rcvd: 115