互联网安全笔记

互联网安全笔记

DNS安全

DNS查询示意图：

区(zone)与资源记录(resource record)

zone数据包括：

• zone中所有节点的权威数据
• zone顶端节点的数据（可认为是权威数据的一部分）
• 描述所授权subzone的数据，例如www
• 用于访问subzone的域名服务器的数据（也叫glue胶水数据）
  • subzone的权威服务器IP，但不属于当前zone

zone数据表示为资源记录（resource record），包含五个字段：

• NAME：域名
• TYPE：类型，例如A表示IPv4地址，NS表示权威服务器名字
• CLASS：实践中只有一种IN，Internet
• TTL：RR在缓存中的有效时间
• RDATA：资源数据

DNS消息传输

• UDP，TCP，端口53
• 实践中，多采用UDP
• 除IP头部和UDP头部外，最大UDP消息512字节

DNS消息格式

DNS for CDN查询示例

分组窃听与伪造应答

• 攻击者能够窃听查询请求，伪造应答
• 攻击效果依赖于哪一个应答先到达解析器：若攻击者伪造的应答先到达，则域名信息被篡改
• 若攻击者位于客户端和权威服务器之间，则为“中间人”攻击

Kaminsky攻击[blackhat 08]

利用操控查询+ID猜测来对缓存下毒，从而劫持一个域hit.edu.cn

1. 攻击者利用受操纵客户端查询一个hit.edu.cn中不存在的域名randomxx
2. 受害递归服务器中缓存没有命中，于是发出查询
3. 利用ID猜测，攻击者服务器发出大量应答，对缓存下毒，将hit.edu.cn的域名服务器定向到攻击者服务器

名字链

攻击者操纵一台客户端和一台服务器，实施“缓存下毒”攻击

1. 受操纵客户端向受害递归服务器发送针对攻击服务器的请求
2. 受害递归服务器向攻击服务器发送请求
3. 攻击者伪造应答：攻击者控制域名->受害域名（伪造CNAME）->攻击者指定IP地址

可信服务器欺骗

域名服务器被攻击或有意篡改数据，例如用手机接入一个公共wifi热点，该热点可能受攻击者控制来伪造数据

反射/放大攻击DoS

• DNS本身可能遭受DoS攻击，也可能被用于DoS攻击
• 反射(reflection)攻击：攻击者伪造源IP地址为受害者，向域名服务器发送UDP请求，域名服务器将应答发送给受害者
• 放大(amplification)攻击：攻击者发送一个60Byte的UDP查询，域名服务器最大产生一个4KByte的应答，流量放大比4/0.06=67

DNS SEC

• 将DNS层次化命名与公钥密码学结合
  • 用密码学（数字签名）来保护名字到地址映射
  • 利用DNS命名层次来形成PKI，形成从根到域名的信任链
• 目标包括
  • 数据起源真实性（Data origin authentication）
  • 数据完整性（Data integrity ）
  • 不提供机密性（confidentiality）

DNSSEC不保护整个DNS系统

公钥基础设施(PKI)提供认证链

• PKI：一套提供基于数字签名的公钥认证的软硬件集合
• 认证链：以一个公钥为起点(信任锚，Trust Anchor)，对下一个公钥证书进行认证，被认证的公钥用来对再下一个证书进行认证，如此认证下去
• PKI中只需要安全发布信任锚，就可以实现所有其他公钥的安全发布

DNSSEC的新RR

类型	代码	RFC	说明
DNSKEY	48	4034	DNSSEC Pubic Key, zone的公钥
DS	43	4034	Delegation signer，(下一级)授权的公钥摘要（指纹）
RRSIG	46	4034	RR Signature，资源记录的数字签名
NSEC	47	4034	Next Secure，用于authenticated denial of existence
NSEC3	50	5155	hashed authenticated denial of existence

DNS SEC如何运作

RRset

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PgaTYXF2-1665588287010)(https://www.cloudflare.com/img/products/ssl/diagram-rrsets.svg)]

使用 DNSSEC 保护某个区域的第一步，是将所有相同类型的记录分组到一个资源记录集（RRset）中。例如，如果您的区域中有三个具有相同标签（如label.example.com）的 AAAA 记录，它们将全部捆绑到一个 AAAA RRset 中。是整个 RRset 获得数字签名，而不是单独的 DNS 记录获得。

区域签名密钥（ZSK）

DNSSEC 中的每个区域都有一个区域签名密钥对（ZSK）：密钥的专用部分对区域中的每个 RRset 进行数字签名，而公共部分则验证签名。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OXbP7LpE-1665588287010)(https://www.cloudflare.com/img/products/ssl/diagram-zone-signing-keys-1.svg)]

但是，除非 DNS 解析器拥有验证签名的方法，否则这些 RRSIG 记录起不到作用。区域操作员还需要将公用 ZSK 添加到 DNSKEY 记录中的名称服务器，方能使其可用。

当 DNSSEC 解析器请求特定的记录类型（例如 AAAA）时，名称服务器还会返回相应的 RRSIG。然后，解析器可以从名称服务器中提取包含公用 ZSK 的 DNSKEY 记录。RRset、RRSIG 和公共 ZSK 将一同用于验证响应。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OYvBtkut-1665588287011)(https://www.cloudflare.com/img/products/ssl/diagram-zone-signing-keys-2.svg)]

密钥签名密钥（KSK）

除了区域签名密钥之外，DNSSEC 名称服务器还具有密钥签名密钥（KSK）。KSK验证 DNSKEY 记录的方式与上一节中描述的、我们的 ZSK保护其余 RRset 的方式完全相同：它签署公共 ZSK（存储在 DNSKEY 记录中），从而为 DNSKEY 创建 RRSIG。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WPKBc832-1665588287011)(https://www.cloudflare.com/img/products/ssl/diagram-key-signing-keys-1.svg)]

就像公用 ZSK 一样，名称服务器将公用 KSK 发布在另一个 DNSKEY 记录中，而这就给我们提供了上面显示的 DNSKEY RRset。公共 KSK 和公共 ZSK 均由私有 KSK 签名。然后，解析器就可以使用公共 KSK 来验证公共 ZSK。

现在，解析器的验证如下所示：

• 请求所需的 RRset，系统还将返回相应的 RRSIG 记录。
• 请求包含公用 ZSK 和公用 KSK 的 DNSKEY 记录，系统还将返回 DNSKEY RRset 的 RRSIG。
• 用公共ZSK验证所请求RRset的RRSIG。
• 用公共KSK验证所请求DNSKEY RRset的RRSIG。

委派签名者记录(DS)

DNSSEC 引入了委派签名者（DS）记录，以允许将信任从父区域转移到子区域。区域操作员对包含公共 KSK 的 DNSKEY 记录进行哈希处理，并将其提供给父区域以作为 DS 记录发布。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SjMoho3I-1665588287011)(https://www.cloudflare.com/img/products/ssl/diagram-delegation-signer-records.svg)]

每次将解析器引用到子区域时，父区域也会提供 DS 记录。此 DS 记录是解析器获知子区域启用 DNSSEC 的方式。

为了检查子区域的公共 KSK 的有效性，解析器对其进行哈希处理并将其与父区域的 DS 记录进行比较。如果两者匹配，则解析器可以假定公共 KSK 未被篡改，这意味着它可以信任子区域中的所有记录。

这就是在 DNSSEC 中建立信任链的方式。

DNSSEC的新标记

• **Checking Disabled (CD)**标记：由解析器在Query中设置，禁止递归服务器端进行真实性验证（由解析器自己来检查）；若未设置，则由递归服务器检查
  • DNS头部标记
• **Authenticated Data (AD)**标记：由递归服务器在Response中设置，表示应答中的Answer和Authority部分的所有数据通过了验证；若未设置，则尚未验证
  • DNS头部标记
• **DNSSEC OK(DO)**标记 [RFC3225]：由递归服务器在Query中设置，表示支持DNSSEC；若未设置，则权威在应答中不应有DNSSEC信息
  • 在EDNS0 OPT header (原RR中TTL) 中MSB(最高比特)

验证递归服务器的4种状态

• Secure：具有一个信任锚，并获得了一条信任链，能够验证应答中的所有签名应答中设置AD(Authenticated Data)标记
• Insecure：具有一个信任锚，一条信任链，但在一个授权点(delegation point)不存在DS记录，表示后续子分支无DNSSEC保护无特定应答信息
• Bogus：具有信任锚，授权信息表明该数据应该被签名，但应答未通过验证，原因包括：签名缺失，签名超时，不支持签名算法，相关NSEC记录缺失，等等应答返回码RCODE=2 “Server Failure”
• Indeterminate：为缺省操作模式，没有信任锚来表明名字空间树上特定部分是安全的无特定应答信息

带有DNSSEC的域名解析

问题：

请列出从根的KSK一直到WWW.ABC.COM的A记录的RRSIG之间完整的信任链

根KSK->根ZSK->comKSK->comZSK->ABC.comKSK->ABC.comZSK->www.ABC.com RRSIG

请分析在DNSSEC的保护范围中，为什么不包含用户侧的桩解析器（stub resolver）和递归解析器之间的通信？

不需要包含，终端主机的安全性由用户自己维护

明确否认存在

如果您向 DNS 询问不存在的域的 IP 地址，它将返回一个空答案 - 无法明确答复“抱歉，您请求的区域不存在”。如果您想对响应进行身份验证，这就是一个问题，因为没有可签名的消息。

DNSSEC 通过添加 NSEC 和 NSEC3 记录类型来解决此问题。它们都允许对否认存在的答复进行身份验证。

NSEC 会返回“下一个安全”的记录。例如，假设有一个为 api、blog 和 www 定义 AAAA 记录的名称服务器。如果您请求 store 的记录，它将返回一个包含 www 的 NSEC 记录，表示当记录按字母顺序排序时，strore 和 www 之间没有 AAAA 记录。这明确地告诉您 store 不存在。并且，由于 NSEC 记录经过签名，您可以像验证任何 RRset 一样验证其相应的 RRSIG。

但是，使用这种解决方案，人们无需知道他们要寻找的记录，就可以浏览区域并收集每条记录。如果区域管理员希望该区域的内容为隐私内容，则这可能造成潜在的安全威胁。

Zone Walking与NSEC3

DNSSEC暴露zone数据：利用NSEC来枚举RR，称作Zone Walking

DNSSEC Hashed Authenticated Denial of Existence (NSEC3) [RFC5155]

• 对域名（+ salt（公开的随机量））进行多次Hash，按Hash值排序
• 根据Hash值，无法获得域名
• 计算Hash值的方法，可通过NSEC3PARAM RR来配置

问题

请分析DNSSEC验证过程中“自顶向下方式”（BIND缺省行为）和“自底向上方式”两种方案有什么优缺点？

• 自顶向下方式，只要上层验证失败，下层无需继续验证

Key更新：缓存带来的复杂性

Key Rollover(秘钥滚动)

前者操作复杂但是文件小，后者操作简单但同一时间文件大小比较大

DNSSEC弱点

• 实现复杂，一些zone分割的特殊情况需要仔细编码
• 增加应答包大小，被用做DoS放大器
  • NSEC3最大增加8倍，NXDOMAIN情况下，增大10倍
• 应答验证增加了解析器负载
• 信任模型完全层次化，高层次出问题影响以下部分
• 根秘钥更新很难
  • 2010年产生后，尚未更新
• 验证者和签名创建之间需要松的时间同步
  • 由于RRSIG采用绝对时间戳
• wildcard存在增加了真实否定机制的复杂性
• 约4成主机无法采用DNSSEC，因为无线路由器或防火墙

BGP安全

BGP边界网关协议

路径向量(Path-Vector)路由

节点避免一条路径重复经过自己

• 路径向量：距离向量中添加通往目标的完整路径
• 每个节点基于邻居的路径向量计算自己的路径向量
  • 基于Bellman-ford算法，迭代计算直至收敛
  • 若采用一条路径，则将自己的添加在新路径上（次序重要吗？）
  • 当发现来自邻居的路径中包括自己时，舍弃该路径，避免回路

一种商业策略模型

• Transit服务：一个ISP为一个客户网络提供接入Internet的服务，后者向前者付费
• 供应商-客户(Provider-Customer, P2C)：客户向供应商付费，供应商为客户提供传递Transit服务
  • 客户不为供应商间传递流量
  • P2C: \ C2P: / 不允许 / 允许 /\
• 对等(Peer-Peer, P2P)：AS间相互(Peering)传递流量，互不付费
  • 不为各自的其他对等AS或供应商传递流量
  • P2P: - 不允许 _ _/ – 允许 /- -\
• 路由策略一般表现为一种选路上的限制或偏好

路由泄露

我们期望流量从源叶节点向上流向层，直到到达通往目标叶节点的路径，在该路径中它转弯并开始向下流向层，直到到达目标叶节点。

不幸的是，生活并不总是那么整洁。 例如，双归属客户可能由于疏忽的配置造成路由泄漏，并成为 ISP Left 和 ISP Right 之间的中转 AS。 假设我们对路由层次结构的理解是正确的，从客户 A 到客户 B 的流量上坡，然后下降到山谷（双归属客户），再次上坡，最后下坡到达客户B。

移除低谷

如果无法影响路由协议策略，可以在同一层级的元素之间安装对等链路（Peer），以创建比穿过山谷的路径成本更低的路径。

通常使用路由协议策略来阻止（或至少排斥）导致流量低谷的路由泄漏。 正如 RFC 7454 中冗长的细节中所解释的，我们示例中的两个 ISP 应过滤从其共享客户收到的传输路由。 在有利于可达性而不是稳定性或可预测交通模式的环境中，更好的解决方案可能是增加会导致路由低谷的路线的成本（或降低本地偏好（local preference））。

正式定义

假设我们可以为网络节点分配层次结构，使得核心节点具有最低级别，边缘节点具有最高级别，无谷流量流以非递增的级别顺序遍历节点，直到到达最内层节点，从那一点开始以非递减级别的顺序遍历节点。

• 将自治系统之间的链接编号为（+1,0,-1）（provider, peer, customer）。
• 无谷路径具有一系列 +1，后跟最多一个 0，然后是一系列 -1。

BGP4要点

• 交换网络层可达性信息(NLRI, Network Layer Reachability Info)
  • 对于IP网络，即IP地址
• 前缀基于路径向量协议，支持基于策略的路由，采用累积更新模式
• 两台相邻路由器，互称为peer，通过TCP端口179通信
• eBGP：不同自治域间BGP过程，路由器代表各自的自治域交换信息
• iBGP：同一自治域内的BGP过程，路由器间同步所有域内域外信息
• 路径属性：Origin, AS_path, Next_hop, Local_pref, (略)
• 最优路径选择：Local_pref, AS_path, Origin, MED (略)
• 四种消息：Open, Keepalive, Update, Notification

为什么不用IGP替代IBGP？

在自治系统内部使用IGP路由协议；而在不同自治系统之间使用BGP路由协议(严格来讲,BGP不是路由协议)。

1. IGP的能力限制，IGP处理路由的条目有限，而目前internet上核心路由器的路由表已经超过10万条。假如没有IBGP，那么这些路由只能采取重分发的方式直接导入到IGP中，这样做的缺点很明显：

   • 第一，IGP协议的作者并没有打算让IGP来处理如此大量的路由，IGP本身也无法处理这样大的路由数量;

   • 第二，如果非要让IGP来处理，那么根据IGP的处理原则，假如这10万路由中任何一条路由发生变化，那么运行IGP的路由器就不得不重新计算路由，更为严重的是，假如其中某一条路由出现路由抖动的情况，例如端口反复UP/DOWN，这会导致所有的IGP路由器每时每刻都不得不把10万条路由重新计算一遍，这种计算量对于绝大多数路由器来说是无法负担的。

• 如果利用IBGP的话，那么AS200中只有运行IBGP的路由器会学习到这1W条路由，其它运行IGP的路由器都不会学习到这1W条路由。并且由于BGP的路由控制能力大大强于IGP的路由控制能力，因此运行IBGP的路由器比运行IGP的路由器能更好的对这1W条路由做一些路由策略的处理，从而保证整个AS内部的路由器学习到的路由数目可以控制在可接受的范围之内。

2. 路由环路的问题。BGP是靠路由属性来防止路由环路的，例如AS_PATH属性，假如说没有IBGP协议，那么当所有BGP路由重分发到IGP中后，路由属性必然丢失，这就破坏了BGP的路由环路防止机制，产生了路由环路的隐患。

既然IBGP能够传送所有的路由前缀，为什么还需要IGP?

1. IBGP之间是TCP连接，也就意味着IBGP邻居采用的是逻辑连接的方式，两个IBGP连接不一定存在实际的物理链路。所以需要有IGP来提供路由，以完成BGP路由的递归查找。

2. BGP协议本身实际上并不发现路由，BGP将路由发现的工作全部移交给了IGP协议，它本身着重于路由的控制。因此，如果没有IGP，那么BGP也就毫无用处了。

总结：

BGP最优路径选择算法(Cisco实现)

Step	路由属性	优	说明
1	WEIGHT	高	本地权重配置
2	LOCAL_PREF	高	iBGP间交换，确定本AS内出口点
3	Self-originated	-	本路由器起源的路径优先
4	AS_PATH LENGTH	低	路径长度, AS_SET长度=1
5	ORIGIN	低	起源类型，IGP=0, EGP=1, INCOMPLETE=2
6	MED	低	eBGP间交换，区分到达相同AS的多个出口
7	eBGP > iBGP	-	若为eBGP, 跳到第9步
8	IGP Cost	低	若为iBGP，挑选IGP代价最小的
9	eBGP Oldest path	高	老路径优于新路径，减小路由摆动
10	Router ID	低	用于打破僵局

策略实现

(1) 入界流量控制

• 公布路由是一种承诺，即会携带数据包到达对应目的

• 通过控制向邻居输出的路由信息，(不)告诉谁=(不)为谁提供传递服务

  • 对客户，通告所有路由信息

  • 对提供商和对等体，只通告自己及自己客户的信息

(2) 出界流量控制

• 为通往客户、对等、提供商的出口从高到低设定Local preference
• 或者，为通往客户、对等、提供商的出口从低到高设定IGP Cost

(3) 影响上游入界入口

• Multihoming：同时连接多个提供商以获得可靠接入
• AS7希望AS2经过与AS5间的链接来访问自己
• Path prepending：通过重复添加自己来降低路径优先级

(4) 影响邻居入界入口

• AS7希望AS4经过链接(a-c)来访问自己
• AS7在©发出的路由声明上配置较低MED值
• AS4在路径选择时，倾向于选择MED值较低的(a)出口

(5) 增加前缀长度来竞争流量

• IP路由采用最长前缀匹配(Longest Prefix Match)
• AS4希望AS2到AS7的流量经过自己
• 通过将一个前缀拆成多个更长前缀获得流量

BGP安全威胁

• (BGP)路由安全问题，即路由器间的Byzantine**（拜占庭）故障问题**
  • 当某些路由器发生故障或恶意行为时，所有无故障路由器必须在有限时间内(termination)对特定消息达成一致(agreement)，该消息必须是由消息源所发送的(validity)
• 前缀劫持(Prefix hijacking)：一个AS声明一个属于其他AS的前缀
  • 蓄意的或配置错误
• 信道攻击：攻击邻居BGP路由器间TCP通信
  • 窃听、篡改、中间人攻击
  • 拒绝服务：打断TCP链接（引起路由震荡），剪断通信光纤
• 利用路由策略攻击：
  • 截断路径：令路径更短，从而占优
  • 延长路径：令伪造路径看起来像真实路径
  • 删除特定AS：隐藏该AS，使得与该AS相关策略失效
  • 添加特定AS：使得该AS为了避免环路，而自动删除该路由
  • 篡改MED或ORIGIN：影响邻居路由决策

前缀劫持成功的三种效果

• 黑洞(Blackhole)：流量被劫持到攻击者网络后被丢弃
  • 绝大多数由配置错误引发的劫持
  • 例如，巴基斯坦电信劫持Youtube
• 仿冒(Phishing)：攻击者假冒受害网络中的网站
  • 攻击者源地址欺骗(spoofing)
  • 例如，2014 黑客通过劫持电子货币矿工
• 窃听(Interception)：攻击者将劫持的流量又返还给受害网络
  • 例如，2010中国电信事故

BGP前缀劫持示例：伪造前缀声明

• AS6拥有前缀10.0.0.0/16，
• AS7通过声明10.0.0.0/16劫持相同前缀根据路由策略(无谷+客户优先+短路径)，AS7、2、4、5改变路由，AS3、6不变
• AS1上路由选择依赖于其他因素

BGP前缀劫持示例：声明更长前缀

AS7通过声明10.0.0.0/17和10.0.128.0/17劫持相同前缀

除AS6外，根据最长前缀匹配规则，所有AS都选择来自AS7的路由

BGP路由泄露(Leak)：示例

• 路由泄露：违背路由策略，“泄漏”有效的路由信息
• AS7违背无谷模型，将来自AS4的路由消息“泄露”给AS5
• 根据客户优先策略，AS5和AS2选择了经过AS7的路由
• 若AS4对入界流量进行过滤，只允许源地址为AS7起源的流量，则导致路由黑洞

BGP路由泄露：分析

• 违背无谷模型：向Provider/Peer泄露来自其他Provider/Peer的路由
• 向谁“泄露”路由意味着为谁提供流量传递服务，从而截获流量
• 具体效果依赖于“存在的路由”和“泄露路由”哪一个更优

BGP前缀窃听：示例

• 窃听：攻击者通过改变路由使自己位于通信路径上
• AS5通过向AS4声明10.0.0.0/16劫持该前缀
• AS4和AS7通往被劫持前缀的路由经过AS5

前缀劫持实例：中国电信事故

• 2010年4月8日，中国电信由于配置错误劫持了15%的网络前缀

BGP前缀窃听：分析

• 攻击者如何在不影响目标网络可达性的情况下，窃听尽可能大范围？
  • 任务1：攻击者若要实现窃听，必须令邻居通往目标前缀的路由经过攻击者
    • 方法：满足前缀劫持条件，让“经过攻击者路由”优于“已存在的路由”。
  • 任务2：利用另外的“通往目标前缀的路由”，该路由与受影响路由无重合
    • 方法：向受害邻居声明 “通往目标前缀的路由”，该路由上的AS都不会采纳该路由，因而不会受该声明影响。
• 一种实现前缀窃听的简单可行方法：向Provider或Peer进行“路由泄露”

BGP路由异常检测方法与局限性

• 从多个AS的BGP路由器收集BGP路由更新消息，与历史信息比较分析
• 以下情况可能是异常：
  • 多起源(MOAS，Multiple Origin AS)前缀：同一个前缀由多个不同起源AS声明
    • 然而，多个Provider可能同时声明同一个无独立AS号的Multihoming网络的前缀，
    • 或者做路由聚合时忽略了小于/24的前缀的起源AS或者，一个AS可能更换了Provider
  • 一条路由不是无谷的：这意味着路径是伪造的，或者存在路由泄露
    • 然而，无谷模型是对现实的一种抽象，并非100%符合，例如两个AS在不同地区的关系可能不同，据说中国电信在中国地区是其他Tier1 ISP的Provider，在国外是Customer
    • 或者，已有链接发生了问题，路由切换到用于备份的隐藏链接上，该链接之前未出现过
  • BGP路由和由traceroute发现的路径之间存在显著不同
    • 然而，攻击者可以篡改IP头部的TTL值，增加TTL以“跳过”攻击者的网络，或者伪造应答包的源IP地址
    • 另外，由于多种原因，BGP路由与实际traceroute经过路由可能不同
• “异常”是相对的，任何对策都无法完全区别出“异常”和“正常”

基于密码学的BGP安全方案

• 从体系结构上看，BGP安全的关键在于保护信息的完整性和真实性
• 起源验证(Origin Authentication)：保护前缀和起源AS的对应关系
  • 例如，RPKI（Resource PKI）[RFC6480~RFC6493, RFC7128]
• 路径验证(Path Authentication)：保护整条路径
  • 例如，BGPsec [draft-ietf-sidr-bgpsec-protocol-13]https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/

资源公共密钥基础架构(RPKI)

RPKI是一个专用的PKI框架，它使用X.509证书扩展来传输IP路由来源信息。一些需要发布前缀的组织创建了一个路由源签证（Route Origin Attestation, ROA），其中包括前缀、掩码长度范围和来源独立系统号。这些ROA会被发布到全世界，特定的组织可以用一个可验证的授权方式发布指定的IP前缀。

• 基于IP地址/ASN分配结构建立PKI
• 绑定“标识符资源和所有者的公钥”

• RPKI采用支持IP地址和AS号[RFC3779]的X.509 PKI证书[RFC5280]

• 三个组件：

  • RPKI：在IP地址/自治域号空间(资源Resource)分配的层次化结构上建立PKI
  • ROA：Route Origination Authorizations (ROAs)绑定“资源标示符和资源拥有者的公钥”，而不包括资源拥有者的身份，因此，provide authorization, but not authentication
  • REPO：一个分布式信息库系统，负责保存PKI对象和ROA对象
    • REPO间通过Rsync同步

• IAB对RPKI的评论

  1. the RPKI should have a single authoritative trust anchor

  2. this trust anchor should be aligned with the registry of the root of the allocation hierarchy

RPKI应用场景

RPKI主要概念

ROA（Route Origination Authorizations）

• ROA：IP地址范围，一个ASN，最大前缀长度
• EE证书：End-entity (EE) certificate，证书内公钥对应的私钥不能签发其他证书

发布ROA：

1. 创建包含被认证前缀的EE证书（公钥和前缀）
2. 构造ROA负载，包括EE证书中的前缀和AS号
3. 用EE证书中公钥所对应的私钥对ROA签名
4. 将EE证书和ROA上传到REPO系统

AS 0 ROA：前缀不可全球路由，例如192.168/16

REPO及所存储数据

• 目的：一个分布式REPO存储签名对象，提供给LIR/ISP来验证所有ROA

• 一个CA的REPO数据库：

  • manifest（清单）：REPO中所有签名对象的列表（除清单之外），清单的签名被包含在一个EE证书中

    • 清单号（数字递增）

    • 发布时间

    • 下一次计划更新时间

    • 一个文件和哈希值对的列表

  • 所有RC（资源证书）：CA和EE证书

  • CRL(证书召回列表)

  • ROA

• 理想情况下，每个RIR维护本地区内所有实体的PKI数据。

REPO Publication Point(发布点)

RPKI-RTR

路由器从ROA缓存中获得所需ROA信息，通过TCP，TLS，SSH等协议传输

路由器启动后执行协议的过程：

RPKI优缺点

优点：

• 不改变BGP，路由不需要在线密码学计算
• 前缀劫持检测
• 有效激励：AS为了避免自己的前缀被劫持，原因采用RPKI

挑战：

• RPKI本身成为最大弱点（被攻击，错误配置，故障）
• RPKI可以被不改变起源AS的攻击绕过，例如声明较短路径，或伪造路径

BGPsec

• BGPsec依赖于RPKI
• BGP更新消息中一条路径上的每个AS对自己的路由声明做签名

BGP黑洞

Blackhole Community

一个起源AS利用“BLACKHOLE”团体属性令邻居AS丢弃以指定IP前缀为目的的流量

利用定义的团体属性实现黑洞的好处：有统一标准会更容易地实现和监测黑洞

团体（community）属性可以添加在每一个路由前缀中，由RFC1997定义，是一个transitive optional属性。包含有团体属性的路由，表示该路由是一个路由团体中的一员，该路由团体具有某种或多种相同的特征

团体属性类型码为8，数值为32位，高16位0x0000和0xFFFF为保留，其余通常为ASN；低16位按功能来定义

黑洞团体注册为：“BGP Well-known Communities” BLACKHOLE (= 0xFFFF029A)，低16位数值666，为ISP常用值

当一个网络遭受DDoS攻击时，该网络可以声明一个涵盖了受害者IP地址的IP前缀，该声明附带黑洞团体属性，来通知邻居网络任何以该IP地址为目的的流量都应该被丢弃。

局部黑洞：当一台路由器收到带有黑洞团体属性的路由声明时，应该添加NO_ADVERTISE（0xFFFFFF02，该路径禁止被通告给其他相连路由器）或NO_EXPORT（0xFFFFFF01，该路径禁止被通告给AS或联盟外部的路由器）团体来阻止该前缀被传播到本自治域之外。

接受黑洞IP前缀：

• 通常BGP路由器不会接受长度大于/24 (IPv4)和/48 (IPv6)的声明。但黑洞前缀长度应该尽可能的长来防止未被攻击的IP地址收到影响。通常，黑洞前缀采用/32 (IPv4)和/128 (IPv6)
• 一个AS声明的黑洞前缀应该被该AS有权声明的前缀所覆盖
• 接收方已经同意在特定BGP会话中接受BLACKHOLE团体

IXP

IXP（Internet Exchange Point）：互联网交换中心是为电信运营商(ISP)/内容服务提供商(CSP)之间建立的集中交换平台，一般由第三方中立运营，是互联网重要基础设施

1. **中立性**：一般由非电信运营商控制的第三方建立并运营；	
2. **对等互联**：AS之间一般采用免费对等互联（Peering);	
3. 微利或非盈利性：本身只提供接入平台，不参与成员间的流量交换，在收费模式上只收取端口占用费。

优点：IXP利于本地ISP之间对等互联，降低互联成本，提高带宽，降低延迟，促进互联网扁平化。

IXP的经济学动机来自于在流量相当的ISP之间、ISP与CSP之间的免费互联来降低成本，并具有“网络效应”， 即IXP成员越多，对每个成员带来的好处越大

路由服务器（Route Server）：IXP提供的一个BGP路由器，只转发路由消息（参与控制平面），但不转发流量（不参与数据平面）。路由服务器将N个路由器之间NxN个BGP会话稀疏化为与路由服务器之间的N个会话。

IXP实现黑洞服务

• 受害用户向路由服务器（RS）声明带有黑洞标记的IP前缀，团体属性 (65535:666)

• 在某些IXP上，可以通知RS发出黑洞声明时排除无攻击流量的AS， 团体属性(IXP的ASN:IXP的ASN) (0:被排除AS)

• IP前缀长度范围：

  • IPv4: /8 ≤ 前缀长度 ≤ /32
  • IPv6: /19 ≤前缀长度≤ /128

• IP前缀验证：RIR（地区互联网注册）过滤来阻止非授权使用

• RS将该IP前缀的下一跳改写为黑洞下一跳（BN）

• BN有一个唯一的MAC地址（由ARP/NDP确定）

• 以BN的MAC地址为目的的帧都将被所有客户端口上的链路层ACL过滤掉

• 所以，所有被黑洞的IP前缀的流量都将在交换设施上被丢弃

BGP路由泄露

• **路由泄露（route leak）：**超过了预期范围的路由声明扩散
• **从一个AS到另一个AS的路由声明违背了接收者、发送者和/或之前AS路径上某个AS的预期政策。**预期范围通常由本地的重发布/过滤政策来定义，这些预期政策又通常以AS间互联商业关系来定义。
• **无谷(Valley-free)模型：**一条AS路径中在P2C或P2P之后不存在C2P或P2P。

路由泄露防御

思路1：AS内部防止泄露路由给邻居

思路2：检测来自邻居AS的路由泄露

基于角色的路由泄露阻止

思路：在BGP中直接加入角色概念，在两个BGP路由器在OPEN消息中对其所在AS间角色/关系达成一致。随后传播的UPDATE信息根据该角色/关系来用一个属性标记，从而阻止路由泄露。

BGP角色：BGP会话中一个新的可配置选项来反映对互联关系所达成的一致，可取值：

• 0 Peer：发送方和邻居是peer；
• 1 Provider：发送方是provider；
• 2 Customer: 发送方是customer；
• 3 Internal：发送方和邻居属于同一组织；
  • iBGP会话只能配置Internal角色在OPEN消息中以Capability选项来传递 [RFC5492]

建立连接时角色检查

当收到对端发过来的角色能力时，检查自己的角色是否匹配？

iOTC属性与路由泄露检测规则

在UPDATE消息中，添加一个新的非传递路径属性iOTC（Internal Only To Customer，只能发送给内部/客户），该属性只是一个标记

基于路由标记的路由泄露阻止

• 参考资料：Internet Draft: Methods for Detection and Mitigation of BGP Route Leaks
• 思路：在路由声明中添加一个RLP（Route-Leak Protection）标记，当provider或peer向Customer或Peer发送路由声明时添加该标记，此后若被“向上或横向”传播，则为路由泄露。
• RLP属性：一个新的BGP可选传递属性。类型码待定；长度占8位；数值为一个ASN（32位）和RLP字段（8位）对的序列；
  • RLP字段缺省为0，即未设定；为1时，“禁止向上或横向传播”；
  • AS_PATH上每个支持RLP的AS插入自己的{ASN, RLP}字段；（排除prepending）

路由泄露检测

• 接收方检测路由泄露：一条路由更新同时满足如下条件，则标记为路由泄露
  • 更新来自于customer或peer
  • 除最近一跳外，一跳或多跳的RLP字段为1（即禁止向上或横向传播）
• 排除“最近一跳”的原因：接收方应该检查“最近一跳”的前一跳是否设置了RLP来判断是否发生路由泄露；而且接收方已经知道更新来自于customer或peer。

路由泄露阻止

• 当检测到路由泄露后，基本原则是，若一个AS收到并标记了一个来自customer的路由为“路由泄露”，则这个AS应该否决“客户优先”（prefer customer）政策，并且优先选择其他“干净”的路由。这可以通过调整“Local preference”来实现;
• 若来自customer或peer的更新被标记为“路由泄露”，则接收方应该优先选择其他未被标记的替代路由；
• 若没有未被标记的替代路由，则一个被标记为“路由泄露”的路径也可以被接受；

总结

• 比较基于角色的方法与基于路由标记的方法：
• AS内部限制输出 vs. 检测外部输入
• AS粒度 vs. 前缀粒度需要所有邻居AS支持 vs.
• 需要大型provider支持

保护BGP重点问题

TTL安全（GTSM RFC5082: The Generalized TTL Security Mechanism]

• 发送方发送TTL值255；接收方检查TTL值，若不等于255，则丢弃。
  • 问题：上述TTL安全机制的原理是什么？

前缀过滤: 通用前缀过滤器

• 特殊用途前缀：IPv4特殊用途前缀, IPv6特殊用途前缀

• 尚未分配前缀：

  • IANA已分配前缀：IPv4地址已经全部分配，无需过滤；IPv6需及时更新

  • RIR已分配前缀：IRR（Internet Routing Registry）数据库，例如RADb Routing Assets Database, 由RIR和ISP维护的路由信息。

• SIDR (Secure Inter-Domain Routing)

  • RPKI RFC6480
    • 问题：如何利用RPKI过滤前缀?
      • 过滤未授权AS对应的前缀
  • BGPSec

• 太长的前缀：多数ISP不接受比/24或/48更长的前缀

• 过滤属于本地AS和下游客户的前缀：不需要从外部获得路由信息

• IXP局域网前缀

• 缺省路由：0.0.0.0/0

3 前缀过滤:全路由（Full Routing）网络的建议

4 路由摆动抑制

限制路由更新数量/频率

最大前缀数量

• 限制来自邻居AS的路由数量P
• eer应（问题：低于/高于）互联网中路由数量
• Provider应（问题：低于/高于）互联网中路由数量
• 超过限制后，可以出发日志记录，或关闭会话

AS路径过滤

• 只从customer接受包含该customer的路径
• 不接受包含私有ASN的路径，除非为了实现黑洞
• 不接受第一个AS不是相连邻居的路径，除非是IXP的
• 不应以一个非空路径来通告一个起源前缀，除非有意为其提供传递
• 不应路由泄露
• 不应改变BGP缺省行为，例如不应接收包含（问题：自己自治域号）的路径
• 参考RFC7132: Threat Model for BGP Path Security

下一跳过滤

• 缺省情况下，只接受路由信息的发送方为下一跳
• 在IXP共享网络中互联时，可以通告一个带有第三方（即非声明前缀的路由器）下一跳的前缀。一种典型的情景就是IXP中的(问题: 路由服务器)，只转发路由消息而不转发流量，详见RFC7947

清理团体属性

• 应清理入界路径中包含(问题：iotc）的团体属性，并只允许这些团体属性作为customer/peer的信令机制
• 不应删除其他团体属性

MANRS 路由安全共识规范

• MANRS（Mutually Agreed Norms for Routing Security）是由互联网协会（Internet Society）发起的以抵御路由威胁的一项全球行动。
• • MANRS操作手册给出了具体的路由安全操作指南，包含4个部分：
    • 阻止不正确路由信息传播（BGP安全操作）
    • 阻止伪造源地址的流量（源地址验证，反向路径转发）
    • 促进运营商间操作沟通与协作（注册联系信息，见下页）
    • 促进全球路由信息验证（注册路由信息政策和RPKI等）
      受第一个AS不是相连邻居的路径，除非是IXP的
• 不应以一个非空路径来通告一个起源前缀，除非有意为其提供传递
• 不应路由泄露
• 不应改变BGP缺省行为，例如不应接收包含（问题：自己自治域号）的路径
• 参考RFC7132: Threat Model for BGP Path Security

下一跳过滤

• 缺省情况下，只接受路由信息的发送方为下一跳
• 在IXP共享网络中互联时，可以通告一个带有第三方（即非声明前缀的路由器）下一跳的前缀。一种典型的情景就是IXP中的(问题: 路由服务器)，只转发路由消息而不转发流量，详见RFC7947

清理团体属性

• 应清理入界路径中包含(问题：iotc）的团体属性，并只允许这些团体属性作为customer/peer的信令机制
• 不应删除其他团体属性

[外链图片转存中…(img-AuQsfwWW-1665588287019)]

MANRS 路由安全共识规范

• MANRS（Mutually Agreed Norms for Routing Security）是由互联网协会（Internet Society）发起的以抵御路由威胁的一项全球行动。
• • MANRS操作手册给出了具体的路由安全操作指南，包含4个部分：
    • 阻止不正确路由信息传播（BGP安全操作）
    • 阻止伪造源地址的流量（源地址验证，反向路径转发）
    • 促进运营商间操作沟通与协作（注册联系信息，见下页）
    • 促进全球路由信息验证（注册路由信息政策和RPKI等）