admin 管理员组

文章数量: 887019

互联网安全笔记

文章目录

  • 互联网安全笔记
  • DNS安全
      • 区(zone)与资源记录(resource record)
      • DNS消息传输
      • DNS消息格式
      • DNS for CDN查询示例
      • 分组窃听与伪造应答
      • Kaminsky攻击[blackhat 08]
      • 名字链
      • 可信服务器欺骗
      • 反射/放大攻击DoS
    • DNS SEC
      • DNSSEC不保护整个DNS系统
      • 公钥基础设施(PKI)提供认证链
      • DNSSEC的新RR
      • DNS SEC如何运作
        • RRset
        • 区域签名密钥（ZSK）
        • 密钥签名密钥（KSK）
        • 委派签名者记录(DS)
        • DNSSEC的新标记
        • 验证递归服务器的4种状态
      • 带有DNSSEC的域名解析
      • 问题：
        • 请列出从根的KSK一直到WWW.ABC.COM的A记录的RRSIG之间完整的信任链
      • 明确否认存在
      • Zone Walking与NSEC3
      • 问题
      • Key更新：缓存带来的复杂性
      • Key Rollover(秘钥滚动)
      • DNSSEC弱点
  • BGP安全
      • BGP边界网关协议
      • 路径向量(Path-Vector)路由
      • 一种商业策略模型
      • 路由泄露
        • 移除低谷
        • 正式定义
      • BGP4要点
        • 为什么不用IGP替代IBGP？
        • 既然IBGP能够传送所有的路由前缀，为什么还需要IGP?
        • 总结：
      • BGP最优路径选择算法(Cisco实现)
      • 策略实现
      • BGP安全威胁
      • 前缀劫持成功的三种效果
      • BGP前缀劫持示例：伪造前缀声明
      • BGP前缀劫持示例：声明更长前缀
      • BGP路由泄露(Leak)：示例
      • BGP路由泄露：分析
      • BGP前缀窃听：示例
      • 前缀劫持实例：中国电信事故
      • BGP前缀窃听：分析
      • BGP路由异常检测方法与局限性
    • 基于密码学的BGP安全方案
    • 资源公共密钥基础架构(RPKI)
      • RPKI应用场景
      • RPKI主要概念
      • ROA（Route Origination Authorizations）
      • REPO及所存储数据
      • REPO Publication Point(发布点)
      • RPKI-RTR
      • RPKI优缺点
    • BGPsec
    • BGP黑洞
      • Blackhole Community
    • IXP
      • IXP实现黑洞服务
    • BGP路由泄露
      • 路由泄露防御
      • 基于角色的路由泄露阻止
      • 建立连接时角色检查
      • iOTC属性与路由泄露检测规则
      • 基于路由标记的路由泄露阻止
      • 路由泄露检测
      • 路由泄露阻止
      • 总结
    • 保护BGP重点问题
        • 前缀过滤: 通用前缀过滤器
        • 3 前缀过滤:全路由（Full Routing）网络的建议
        • 4 路由摆动抑制
        • 最大前缀数量
        • AS路径过滤
        • 下一跳过滤
        • 清理团体属性
      • MANRS 路由安全共识规范
        • 下一跳过滤
        • 清理团体属性
      • MANRS 路由安全共识规范

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

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

名字链

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

  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说明
DNSKEY484034DNSSEC Pubic Key, zone的公钥
DS434034Delegation signer，(下一级)授权的公钥摘要（指纹）
RRSIG464034RR Signature，资源记录的数字签名
NSEC474034Next Secure，用于authenticated denial of existence
NSEC3505155hashed authenticated denial of existence

DNS SEC如何运作

RRset

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

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

区域签名密钥（ZSK）

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OXbP7LpE-1665588287010)(https://www.cloudflare/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/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/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/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->ABCKSK->ABCZSK->www.ABC 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内部的路由器学习到的路由数目可以控制在可接受的范围之内。
  1. 路由环路的问题。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路由属性优说明
1WEIGHT高本地权重配置
2LOCAL_PREF高iBGP间交换，确定本AS内出口点
3Self-originated-本路由器起源的路径优先
4AS_PATH LENGTH低路径长度, AS_SET长度=1
5ORIGIN低起源类型，IGP=0, EGP=1, INCOMPLETE=2
6MED低eBGP间交换，区分到达相同AS的多个出口
7eBGP > iBGP-若为eBGP, 跳到第9步
8IGP Cost低若为iBGP，挑选IGP代价最小的
9eBGP Oldest path高老路径优于新路径，减小路由摆动
10Router 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/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等）

本文标签： 互联网安全 笔记

版权声明：本文标题：互联网安全笔记 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.freenas.com.cn/jishu/1729002535h1305563.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。