互联网似乎是一个强大的、独立的、坚不可摧的结构。 理论上，该网络足够强大，可以在核爆炸中幸存下来。 事实上，互联网可以放下一台小型路由器。 这一切都是因为互联网上充斥着关于猫的矛盾、漏洞、错误和视频。 互联网的骨干 BGP 充满了问题。 令人惊奇的是他还有呼吸。 除了互联网本身的错误之外，它还受到各种因素的破坏：大型互联网提供商、公司、国家和 DDoS 攻击。 该怎么办以及如何忍受它？
知道答案了 阿列克谢·乌恰金 (）是 IQ Option 网络工程师团队的领导者。 其主要任务是为用户提供平台的可访问性。 在阿列克谢的报告笔录中 我们来谈谈 BGP、DDOS 攻击、互联网交换机、提供商错误、去中心化以及小型路由器导致互联网进入睡眠状态的情况。 最后 - 关于如何度过这一切的一些技巧。
互联网崩溃的那一天
我将仅举几个互联网连接中断的事件。 这对于完整的图片来说就足够了。
《AS7007事件》。 互联网第一次崩溃是在 1997 年 7007 月。自治系统 XNUMX 的一台路由器的软件存在错误。 在某个时刻，路由器向其邻居公布其内部路由表，并将一半的网络送入黑洞。
“巴基斯坦反对 YouTube”。 2008 年，来自巴基斯坦的勇敢者决定屏蔽 YouTube。 他们做得非常好，以至于半个世界都没有猫了。
“Rostelecom 捕获 VISA、MasterCard 和 Symantec 前缀”。 2017 年，Rostelecom 错误地开始宣布 VISA、MasterCard 和 Symantec 前缀。 因此，金融流量是通过提供商控制的渠道进行的。 这次泄密事件持续的时间并不长，但对于金融公司来说却是不愉快的。
谷歌 vs 日本。 2017 年 XNUMX 月，Google 开始在其部分上行链路中公布日本主要提供商 NTT 和 KDDI 的前缀。 流量被作为传输发送到 Google，很可能是错误的。 由于谷歌不是提供商并且不允许过境流量，因此日本的很大一部分地区没有互联网。
“DV LINK 捕获了 Google、Apple、Facebook、Microsoft 的前缀”。 同样在 2017 年，俄罗斯提供商 DV LINK 出于某种原因开始宣布谷歌、苹果、Facebook、微软和其他一些主要参与者的网络。
“来自美国的 eNet 已捕获 AWS Route53 和 MyEtherwallet 前缀”。 2018 年，俄亥俄州提供商或其客户之一宣布推出 Amazon Route53 和 MyEtherwallet 加密钱包网络。 这次攻击是成功的：尽管有自签名证书，在用户进入 MyEtherwallet 网站时会出现警告，但许多钱包被劫持，部分加密货币被盗。
仅2017年一年，此类事件就超过14起！ 网络仍然是去中心化的，所以并不是所有的东西、也不是每个人都会崩溃。 但有数以千计的事件，全部与为互联网提供动力的 BGP 协议有关。
BGP及其问题
协议 BGP - 边界网关协议1989 年，IBM 和 Cisco Systems 的两名工程师首次在三张“餐巾纸”——A4 纸上描述了这一点。 这些 作为网络世界的遗迹，它仍然坐落在旧金山的思科系统公司总部。
该协议基于自治系统的交互 - 自治系统或简称AS。 自治系统只是在公共注册表中分配 IP 网络的 ID。 具有此 ID 的路由器可以向全世界公布这些网络。 相应地，Internet上的任意路径都可以表示为一个向量，称为 AS路径。 该向量由必须遍历才能到达目标网络的自治系统的数量组成。
例如，有一个由多个自治系统组成的网络。 您需要从 AS65001 系统转到 AS65003 系统。 来自一个系统的路径在图中用 AS 路径表示。 它由两个自治系统组成：65002和65003。对于每个目标地址都有一个AS路径向量，它由我们需要经过的自治系统的数量组成。
那么BGP存在哪些问题呢？
BGP是一种信任协议
BGP 协议是基于信任的。 这意味着我们默认信任我们的邻居。 这是互联网诞生之初开发的许多协议的一个特征。 让我们弄清楚“信任”的含义。
没有邻居验证。 正式来说，有 MD5，但 5 年的 MD2019 只是……
无过滤。 BGP 有过滤器并且对它们进行了描述，但是它们没有被使用或使用不正确。 稍后我会解释原因。
设置邻居非常容易。 在几乎所有路由器上通过 BGP 协议设置邻居只需几行配置。
无需BGP管理权限。 您不需要参加考试来证明您的资格。 没有人会剥夺您醉酒时配置 BGP 的权利。
两个主要问题
前缀劫持。 前缀劫持是在宣传不属于您的网络，就像 MyEtherwallet 的情况一样。 我们采用了一些前缀，与提供商达成一致或对其进行了黑客攻击，然后通过它我们宣布这些网络。
路由泄漏。 泄漏有点复杂。 泄漏是 AS Path 的变化。 在最好的情况下，这种变化只会导致更大的延误，因为您需要行驶更长的路线或在更宽敞的路段上行驶。 最坏的情况下，谷歌和日本的情况将会重演。
谷歌本身不是运营商或交通自治系统。 但当他向其提供商宣布日本运营商的网络时，通过 AS Path 通过 Google 的流量被视为更高优先级。 流量到达那里并下降只是因为谷歌内部的路由设置比边界的过滤器更复杂。
为什么过滤器不起作用？
没人在乎。 这是主要原因——没人关心。 通过 BGP 连接到提供商的小型提供商或公司的管理员使用 MikroTik，在其上配置了 BGP，甚至不知道可以在那里配置过滤器。
配置错误。 他们搞砸了一些事情，在面罩上犯了一个错误，戴上了错误的网布——现在又出现了一个错误。
没有技术可能性。 例如，电信提供商有许多客户。 明智的做法是自动更新每个客户端的过滤器 - 监视他是否拥有新网络，以及他是否已将网络出租给某人。 遵循这一点很困难，用你的双手更困难。 因此，他们只是安装宽松的过滤器或根本不安装过滤器。
Исключения。 对于心爱的客户和大客户也有例外。 特别是在运营商间接口的情况下。 例如，TransTeleCom 和 Rostelecom 有一堆网络，它们之间有一个接口。 如果关节掉落，对任何人都没有好处，因此过滤器会被放松或完全移除。
IRR 中的过时或不相关信息。 过滤器是根据记录的信息构建的 IRR - 互联网路由注册表。 这些是区域互联网注册商的注册机构。 通常，注册表包含过时或不相关的信息，或两者兼而有之。
这些注册商是谁？
所有互联网地址都属于该组织 IANA - 互联网号码分配机构。 当您从某人那里购买 IP 网络时，您购买的不是地址，而是使用它们的权利。 地址是一种无形资源，根据共同协议，它们均归 IANA 所有。
系统是这样工作的。 IANA 将 IP 地址和自治系统编号的管理委托给五个地区注册商。 他们发布自治系统 LIR-- 本地互联网注册商。 然后，LIR 向最终用户分配 IP 地址。
该系统的缺点是每个地区注册商都以自己的方式维护其注册簿。 每个人对于登记册中应包含哪些信息以及谁应该或不应该检查这些信息都有自己的看法。 结果就是我们现在的乱局。
您还能如何解决这些问题？
IRR-- 质量平庸。 IRR 很清楚——那里的一切都很糟糕。
BGP 社区。 这是协议中描述的一些属性。 例如，我们可以在我们的公告中附加一个特殊的社区，以便邻居不会将我们的网络发送给他的邻居。 当我们有 P2P 链接时，我们只交换我们的网络。 为了防止路由意外到其他网络，我们添加了社区。
社区不具有传递性。 它始终是两个人的合同，这是他们的缺点。 我们无法分配任何社区，但每个人都默认接受的社区除外。 我们不能确定每个人都会接受这个社区并正确解释它。 因此，最好的情况是，如果你同意你的上行，他就会明白你在社区方面想从他那里得到什么。 但你的邻居可能不明白，或者运营商会简单地重置你的标签，而你将无法达到你想要的。
RPKI+ROA只解决了一小部分问题。 RPKI 是 资源公钥基础设施 — 用于签署路由信息的特殊框架。 强制 LIR 及其客户维护最新的地址空间数据库是个好主意。 但它有一个问题。
RPKI也是一个分层的公钥系统。 IANA 拥有一个密钥，可以根据该密钥生成 RIR 密钥，也可以根据该密钥生成 LIR 密钥？ 他们使用 ROA 签署其地址空间 - 路由源授权：
——我向你们保证，这个前缀将代表本自治区公布。
除了ROA之外，还有其他对象，稍后会详细介绍。 这似乎是一件好事而且有用。 但它并不能保护我们免受“完全”一词的泄露，也不能解决前缀劫持的所有问题。 所以，玩家们并不急于实施。 尽管 AT&T 和大型 IX 公司等大公司已经保证，带有无效 ROA 记录的前缀将被删除。
也许他们会这样做，但目前我们有大量的前缀没有以任何方式签名。 一方面，尚不清楚它们是否被有效宣布。 另一方面，我们不能默认删除它们，因为我们不确定这是否正确。
那里还有什么？
北斗卫星导航系统。 这是学者们为粉红小马网络想出的一件很酷的事情。 他们说：
- 我们有 RPKI + ROA - 一种验证地址空间签名的机制。 让我们创建一个单独的 BGP 属性并将其称为 BGPSec 路径。 每个路由器都会用自己的签名对其向邻居发布的公告进行签名。 这样我们就可以从签名公告链中获得一条可信路径，并能够对其进行检查。
理论上很好，但实践中存在很多问题。 BGPSec 打破了许多现有的 BGP 机制，用于选择下一跳并直接在路由器上管理传入/传出流量。 BGPSec 直到整个市场 95% 的企业都实施了它才起作用，这本身就是一个乌托邦。
BGPSec 存在巨大的性能问题。 在当前的硬件上，检查公告的速度约为每秒 50 个前缀。 作为对比：当前互联网表中的700万个前缀将在000小时内上传，在此期间将再更改5次。
BGP 开放策略（基于角色的 BGP）。 基于模型的新提案 高雷克斯福德。 这是两位正在研究 BGP 的科学家。
高-雷克斯福德模型如下。 为了简化，BGP 有少量类型的交互：
- 提供商客户；
- 对等；
- 内部通信，例如 iBGP。
根据路由器的角色，默认情况下已经可以分配某些导入/导出策略。 管理员无需配置前缀列表。 根据路由器之间达成一致且可以设置的角色，我们已经收到了一些默认过滤器。 目前 IETF 正在讨论该草案。 我希望很快我们就能以 RFC 的形式看到它并在硬件上实现。
大型互联网提供商
让我们看一下提供商的示例 世纪互联。 它是美国第三大提供商，为 37 个州提供服务并拥有 15 个数据中心。
2018年50月，CenturyLink在美国市场上市911小时。 事件期间，两个州的ATM机运行出现问题，五个州的XNUMX号码几个小时无法拨打。 爱达荷州的彩票彻底被毁了。 目前该事件正在接受美国电信委员会的调查。
悲剧的原因是一个数据中心的一张网卡。 该卡发生故障，发送了错误的数据包，提供商的所有 15 个数据中心都瘫痪了。
这个想法对该提供商不起作用 “太大而不能倒下”。 这个想法根本行不通。 你可以选择任何一个主要的参与者，然后在上面放一些小东西。 美国在互联互通方面仍然表现良好。 拥有储备的 CenturyLink 客户纷纷涌入。 然后其他运营商抱怨他们的链接超载。
如果有条件的哈萨克斯坦电信垮台，整个国家将失去互联网。
企业
也许谷歌、亚马逊、FaceBook 和其他公司都支持互联网？ 不，他们也打破了它。
2017 年在圣彼得堡举行的 ENOG13 会议 杰夫·休斯顿 из APNIC 提交 。 它说我们习惯了互联网上的互动、资金流动和流量是垂直的。 我们有一些小型提供商为与大型提供商的连接付费，他们也已经为与全球交通的连接付费。
现在我们有了这样一个垂直方向的结构。 一切都会好起来的，但世界正在发生变化——主要参与者正在建造自己的跨洋电缆来建设自己的骨干网。
有关 CDN 电缆的新闻。
2018年，TeleGeography发布研究称，互联网上一半以上的流量不再是互联网，而是大型玩家的骨干CDN。 这是与互联网相关的流量，但这不再是我们谈论的网络。
互联网正在分裂成一大堆松散连接的网络。
微软有自己的网络，谷歌也有自己的网络，而且它们之间几乎没有重叠。 源自美国某处的流量通过 Microsoft 渠道跨越大洋到达欧洲 CDN 上的某处，然后通过 CDN 或 IX 连接到您的提供商并到达您的路由器。
权力下放正在消失。
互联网的这种力量正在消失，这种力量将有助于它在核爆炸中幸存下来。 用户和流量集中的地方出现。 如果有条件的谷歌云倒下了，一下子就会有很多受害者。 当 Roskomnadzor 封锁 AWS 时，我们部分地感受到了这一点。 CenturyLink 的例子表明，即使是很小的事情也足以实现这一目标。
以前，并不是所有东西、也不是每个人都破产了。 未来，我们可能会得出这样的结论：通过影响一个主要参与者，我们可以在很多地方、很多人身上打破很多东西。
状态
各州紧随其后，这也是它们通常会发生的情况。
在这方面，我们的 Roskomnadzor 根本不是先驱。 伊朗、印度和巴基斯坦也存在类似的关闭互联网做法。 英国有一项关于关闭互联网可能性的法案。
任何大国都希望有一个开关来完全或部分关闭互联网：Twitter、Telegram、Facebook。 并不是他们不明白自己永远不会成功，而是他们真的想要成功。 一般来说，这种切换是出于政治目的——消除政治竞争对手，或者选举即将到来，或者俄罗斯黑客再次破坏了某些东西。
DDoS 攻击
我不会从 Qrator Labs 的战友那里夺走面包，他们做得比我好得多。 他们有 关于互联网的稳定性。 这就是他们在 2018 年报告中写的。
DDoS 攻击平均持续时间降至 2.5 小时。 攻击者还开始数钱，如果资源不能立即可用，那么他们很快就会不管它。
攻击的强度越来越大。 2018 年，我们在 Akamai 网络上看到了 1.7 Tb/s，但这还不是极限。
新的攻击媒介正在出现，旧的攻击媒介正在加剧。 容易被放大的新协议不断出现，针对现有协议（尤其是 TLS 等）的新攻击不断出现。
大部分流量来自移动设备。 与此同时，互联网流量转向移动客户端。 进攻者和防守者都需要能够处理这一点。
刀枪不入 - 没有。 这是主要思想 - 不存在绝对可以防御任何 DDoS 的通用保护措施。
除非连接到互联网，否则无法安装系统。
我希望我已经吓到你了。 现在让我们考虑一下该怎么办。
怎么办？！
如果您有空闲时间、渴望并具备英语知识，请参加工作组：IETF、RIPE WG。 这些是开放邮件列表、订阅邮件列表、参与讨论、参加会议。 例如，如果您拥有 LIR 身份，您可以在 RIPE 中为各种倡议投票。
对于凡人来说这是 监控。 要知道什么坏了。
监控：检查什么？
正常，而不仅仅是二进制检查 - 它是否有效。 将 RTT 记录在历史记录中，以便您以后可以查看异常情况。
跟踪路由。 这是一个用于确定 TCP/IP 网络上的数据路由的实用程序。 帮助识别异常和阻塞。
HTTP 检查自定义 URL 和 TLS 证书 将有助于检测攻击的阻止或 DNS 欺骗，这实际上是同一件事。 阻止通常是通过 DNS 欺骗和将流量转向存根页面来实现的。
如果可能的话，如果您有申请，请检查客户对您来自不同地方的来源的解析。 这将帮助您检测 DNS 劫持异常，提供商有时会这样做。
监控：去哪里检查？
没有普遍的答案。 检查用户来自哪里。 如果用户在俄罗斯，请从俄罗斯进行检查，但不要仅限于此。 如果您的用户居住在不同的区域，请从这些区域进行检查。 但来自世界各地的更好。
监控：检查什么？
我想出了三种方法。 如果您知道更多，请写在评论中。
- 成熟的阿特拉斯。
- 商业监控。
- 您自己的虚拟机网络。
让我们来谈谈他们中的每一个。
成熟阿特拉斯 - 这是一个很小的盒子。 对于那些了解国内“检查员”的人 - 这是同一个盒子，但带有不同的贴纸。
RIPE Atlas 是一个免费程序。 您注册、通过邮件收到路由器并将其插入网络。 由于其他人使用了您的样本，您将获得一些积分。 通过这些贷款，您可以自己做一些研究。 您可以通过不同的方式进行测试：ping、traceroute、检查证书。 覆盖范围相当大，节点很多。 但也存在细微差别。
信用体系不允许构建生产解决方案。 没有足够的学分用于正在进行的研究或商业监测。 学分足以进行短期学习或一次性检查。 1-2 次检查消耗了一份样本的每日标准。
覆盖不均匀。 由于该计划是双向免费的，因此在欧洲、俄罗斯的欧洲部分和一些地区的覆盖范围很好。 但如果您需要印度尼西亚或新西兰，那么一切就更糟糕了 - 每个国家可能没有 50 个样本。
您无法从示例中检查 http。 这是由于技术上的细微差别造成的。 他们承诺在新版本中修复它，但目前无法检查http。 只能验证证书。 某种 http 检查只能对称为 Anchor 的特殊 RIPE Atlas 设备进行。
第二种方法是商业监控。 他一切都很好，你付钱了，对吗？ 他们向您承诺在世界各地有数十个或数百个监控点，并绘制出现成的漂亮仪表板。 但是，问题又来了。
是要付费的，有的地方还很贵。 Ping 监控、全球检查和大量 http 检查每年可能花费数千美元。 如果财务允许并且您喜欢这个解决方案，请继续。
感兴趣区域的覆盖范围可能不够。 使用相同的 ping，最多可以指定世界的一个抽象部分 - 亚洲、欧洲、北美。 很少有监控系统可以深入到特定的国家或地区。
对自定义测试的支持较弱。 如果您需要一些自定义内容，而不仅仅是网址上的“卷曲”，那么这也会存在问题。
第三种方式是你的监控。 这是一句经典的话：“让我们自己写吧！”
您的监控变成了软件产品的开发，并且是分布式软件产品。 你正在寻找一个基础设施提供商，看看如何部署和监控它——监控需要被监控，对吗？ 并且还需要支持。 在你接受这件事之前要三思十次。 付钱让别人帮你做这件事可能会更容易。
监控BGP异常和DDoS攻击
在这里，基于可用的资源，一切都变得更加简单。 使用 QRadar、BGPmon 等专门服务检测 BGP 异常。 他们接受来自多个操作员的完整视图表。 根据他们从不同操作员那里看到的情况，他们可以检测异常情况、寻找放大器等等。 注册通常是免费的 - 您输入您的电话号码，订阅电子邮件通知，该服务将提醒您出现问题。
监控 DDoS 攻击也很简单。 通常这是 基于NetFlow和日志。 有专门的系统，例如 快速网络监控，模块 Splunk的。 作为最后的手段，您可以选择 DDoS 保护提供商。 它还可以泄漏 NetFlow，并基于此，它会通知您针对您的方向的攻击。
发现
不要抱有任何幻想——互联网肯定会崩溃。 不是所有事情、也不是每个人都会发生故障，但 14 年 2017 起事故暗示将会发生事故。
您的任务是尽早发现问题。 至少不晚于您的用户。 重要的是要注意，始终保留“B 计划”。 计划是当一切都崩溃时你将采取的行动的策略。：储备运营商、DC、CDN。 计划是一个单独的清单，您可以根据它检查所有工作的情况。 该计划应该在没有网络工程师参与的情况下发挥作用，因为他们通常很少，而且他们想睡觉。
就这样。 祝您高可用，绿色监控。
预计下周新西伯利亚将迎来阳光明媚、客流量大且开发商高度集中的情况 。 在西伯利亚，预计将出现一系列有关监测、可达性和测试、安全和管理的报告。 预计降雨会以潦草笔记、网络、照片和社交网络帖子的形式出现。 我们建议推迟 24 月 25 日至 XNUMX 日的所有活动， 。 我们在西伯利亚等你！
来源： habr.com