文章分为三个部分。 第一个包含有关什么是BGP劫持及其传统版本的一般信息。 对于那些熟悉这种现象的人，建议直接进入第二部分。 第二部分将描述通过向您的AS-SET中添加外部AS来宣布外部前缀的方法。 在第三部分中，将评估使用第二部分中描述的方法捕获torproject.org资源的IP地址并为其颁发证书的复杂性。 假定读者熟悉BGPv4的原理。
简单的BGP劫持
简而言之，BGP劫持是捕获他人的IP地址（随机或有意）。
通常，BGP劫持是这样的：不拥有前缀的AS会开始声明它（别人的前缀），上行链路/对等体会接受它，并开始在Internet上传播。 他们之所以接受它，是因为在联结处没有前缀过滤（这是配置错误，或者是这样设想的（由于各种原因，很难在具有非常大的运算符的联结处构建前缀过滤器，因此对于本文而言这并不重要）） ） Rostelecom（
AS12389 ）最近
开始发布前缀万事达卡（
AS26380 ），Visa和其他一些金融组织（根据
官方版本 ，由于软件故障），这是最近最引人注目的例子之一。 您可以在bgplay历史中看到这些公告的外观（
通过web ，
json （
存档 ）
查看 ），这是其中一个RIPE收集器中的其中一个（前缀216.119.216.0/24属于万事达卡（AS26380））：
"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24
真正的公告如下所示：
"source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24
即 在这种情况下，Rostelecom直接从其AS宣布了前缀（AS-PATH中的最后一个AS是12389）。 如果Rostelecom的上行链路和盛宴通过根据AS-SET
建立前缀列表和/或
根据ROA RPKI验证前缀来过滤来自Rostelecom的前缀，则可以避免出现问题。 大型操作符之间的前缀列表的构建通常没有完成，并且并非所有人都实现了RPKI（但是有
进步 ）。 从理论上讲，这种劫持可以由任何人进行，但前提是所宣布的前缀至少通过一个上行链路/宴会“泄漏”。 通常，大型俄罗斯运营商会在其客户的方向上配置前缀过滤器，因此，小型自治系统（中小型运营商，一些托管服务商和一些企业）几乎无法进行此类攻击（但同样，这完全取决于地区/国家/地区的特定运营商）。
但是，攻击者仍然会发现未配置过滤功能的地方（上行链路）（在2017年，巴西是
劫持的
领先者 ），并通过抢夺IP地址来进行攻击（通常，此类事件属于新闻源），以实现更有效的攻击，宣布比真实始发者更具体的前缀（带有更长的掩码）。 现在，让我们继续进行攻击，在该版本中，ROA RPKI验证和AS-SET前缀列表都不会保存。
BGP劫持，在其AS-SET中添加了AS受害者
请考虑以下情形：
- 攻击者获取AS和IP地址（实际上，从技术上讲，他不需要IP地址，它们更有可能只是不会引起问题）。
- 攻击者连接到各种大型运营商和IX（至少一个运营商或IX），不仅指定其AS，还指定其AS-SET作为已声明前缀的数据源（这是运营商之间进行交互的正常做法（包括包括当处于客户端-上行链路关系中时）或包含在IX-ah中）。 在正常情况下，当假定客户端不是死胡同，但它本身具有（或将具有）具有bgp的客户端和它们自己的网络的客户端时，将指定AS-SET，而不仅仅是AS。
- 一段时间后，攻击者将受害者的AS添加到他的AS-SET中，并开始通过自己宣布自己的前缀，即 宣布的AS-PATH如下所示：“ AS_攻击者AS_受害者”。 从自动构造的前缀列表的角度以及从RPKI的角度来看，这是一个完全有效的公告，因此这两种保护机制在这里都将无法使用。
- 所宣布的前缀开始与真实的公告（受害者的公告）竞争，即他赢得并进入路由表的某个地方，他失败而不会的某个地方（受害者的公告将保留在那里）。 它取决于攻击者使用多少个上行链路和多少个IX。 当攻击者以客户端身份连接到某个AS时，在内部（大多数情况下），由于本地偏好较大，他将赢得受害者（如果受害者不是同一上行链路的客户端，则受害者将通过AS-PATH获胜）前置），即 攻击者需要使用其AS-SET连接到尽可能多的上行链路，以最大程度地发挥攻击的效力。
另外，攻击者必须连接到最大数量的IX，因为 通常，死锁AS会将最高本地首选项设置为IX，如果IX中不包含受害者前缀，则它将在死锁AS的路由表中丢失攻击者的公告。
从理论上讲，这是一个相当强大的攻击，但幸运的是，在实践中，将出现以下限制：
- 您需要草拟至少一个法人实体，但实际上，很可能在不同国家/地区都需要。
- 必须与运营商IX签订协议，几乎总是要通过LIR / RIR支付连接费。
- 一些操作员仍然不能自动建立AS-SET前缀列表，因此需要为此写字母。 如果知名公司的AS-ka突然出现在未知公司的AS-SET中，那么经验丰富的管理员就会怀疑。
- 攻击后，如果刑事案件被公开，最有可能没收所使用的设备（如果它位于某种数据中心中）。
- 不同运算符/ IX的前缀列表在不同时间更新，因此，当这也不是最简单的工作时，您将需要分析谁进行更新。
可能的保护措施：
- 从理论上讲，为了防御这种攻击，您需要与操作员（更好的是客户端，因为它们的本地优先级更高）和IX具有尽可能多的接口。 即 做攻击者会做的同样的事情。 当然，在实践中，这很难实施，并且需要大量资源。 此方法仅与专业提供信息安全服务的服务有关。
- 如果您有网站，请在帐户任务中使用CAA记录（如果您的SSL证书提供者支持它，而Letsencrypt支持）（请参阅RFC6844 ）。 在这种情况下，攻击者将无法颁发证书（除非他可以更改CAA记录）
- 从理论上讲，BGPsec的广泛实施应消除这种攻击，但其命运尚不清楚（实际上，它尚未应用或很少使用）。
- 替代验证AS_PATH的实现（不使用BGPsec）（到目前为止，这是一个草案 ，可以在广泛实施的情况下解决上述问题）。
- 禁止在未经AS拥有者许可的情况下无限制地将外国AS添加到您的AS-SET中，可以减少在使用AS-SET过滤关节的区域进行此类攻击的可能性。 现在没有这样的禁令。
实际上，对于大多数读者而言，唯一适用于他们的建议是第二（关于CAA记录中帐户的使用），而在选择具有良好连接性的主机的情况下则是部分第一。 同时，您需要记住托管记录的DNS服务可能受到的攻击（但这是一个单独的问题，其中包含很多内容）
捕获torproject.org困难吗
攻击者需要解决两个问题：
- 将流量重定向到目标受众（目标受众-会收到假网站的人）
- 生成证书
简介：
$ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197
如您所见，有一个CAA记录，您可以从letencrypt获取证书，在CAA记录中没有对帐户的绑定，这意味着攻击者从理论上解决了该问题。 torproject.org的IP地址由著名的Hezner托管拥有。
假设攻击者的目标受众是某些俄罗斯运营商的客户。 赫兹纳不是俄罗斯运营商的客户（但是直接或通过IX-s与大型运营商建立了对等关系）。 攻击者将CA流量重定向到他自己的最简单方法是成为该操作员的客户端，并以赢得更高本地偏好为代价来取胜。 这里的所有内容尤其相对简单明了。
要在letencrypt中获取证书，您需要letencrypt所在的提供程序将流量定向到攻击者，而不是Hezner（AS24940）。 letsencrypt可以将美国和欧洲IP的地址解析为不同的地址，但是让我们看看影响来自acme-v02.api.letsencrypt.org/2.19.125.202的流量流向攻击者主机的难度。 在这里，我们面临一个事实，就是letencrypt托管在Akamai CDN上，该CDN在全球范围内具有很好的连接性（大多数主要IX上都存在，并与大量大型播放器直接相连）。 Akamai没有公共LG，原则上，有一个用于客户端的
API ，您可以使用它进行traceroute / ping，但是即使没有公共LG，您也可以查看
对等db来评估其存在的规模。 同样，您可以查看
hezner 。 可以很容易地看到两个AS都存在相同的IX，因此我们可以得出结论，以A_mai 24940显示Akamai表（AS20940）中的AS Hezner前缀（AS24940）的可能性接近于1。这意味着如果攻击者如果它试图通过某个IX宣布Hezner的前缀，则它们将根据AS_PATH丢失来自Hezner的真实声明（因为AS_PATH将包含攻击者的AS）。 一种可能的解决方案是在攻击者和Akamai之间组织一个“直接”对等（如果Akamai同意这一点，并且它的本地优先级高于与IX的交界处）。
总而言之，通过将其他人的AS添加到您的AS-SET中，可以导致torproject.org网站的性能显着下降（适用于大量客户，但一般情况下并不适用于每个人），但是可以在letencrypt中获得torproject.org SSL证书，由于真正的始发者（Hezner）与letsencrypt（Akamai）使用的CDN之间的良好连接，极有可能无法解决问题。 但是，在其他情况下，当受害站点的宿主和证书颁发机构之间存在过渡AS，并且它们存在于AS_PATH中时，使用上述方法获得证书的风险会大大增加。