ASPIRE

DNS和安全

=Start=

缘由：

前面在博客中整理了两篇和DNS原理及作用相关的文章，详细介绍了DNS的原理和作用，这里想整理记录一下DNS和安全的关系及其能起到的作用，方便以后参考。

正文：

参考解答：
DNS的重要性：

1、技术角度看
DNS解析是互联网绝大多数应用的实际寻址方式；域名技术的再发展、以及基于域名技术的多种应用，丰富了互联网应用和协议。

2、资源角度看
域名是互联网上的身份标识，是不可重复的唯一标识资源；互联网的全球化使得域名成为标识一国主权的国家战略资源。

DNS对黑客的几个意义：
  1. 传输命令与控制指令（c&c）
  2. 偷渡数据（steal data）
  3. 重定向流量（hijacking）
  4. 信息收集（zone transfer/domain leak）
DNS对于企业（安全）的重要性：
  • 如果您的内部DNS表现不佳或者不可用，那么您的所有应用程序的性能将会很差或者会明显下降。如果您的内部DNS受到攻击，那么攻击者将对您的网络上的所有服务一目了然并且可以十分容易到达目标服务器。黑客也可能会控制和更新DNS记录，将您的内部流量重定向到他们自己的恶意目的地。
  • 如果您的外部DNS表现不佳或不可用，则客户可能无法联系您的网站或向您的企业发送电子邮件。如果网络体验不佳，客户可能会流逝或转向竞争对手。外部DNS表示您的品牌和互联网的可用性，根据您的业务性质，可能会对您的品牌和收入产生重大影响。不安全的外部DNS可能会悄悄地将您的客户引向恶意网站，欺骗您的网站以窃取客户信息或拦截电子邮件。
  • 如果您的递归DNS表现不佳或者不可用，您的互联网访问就会变得无效或严重退化。这是因为您无法快速解析任何外部网站或资源的IP地址。不安全的递归DNS可能会导致您在不知情的情况下进入恶意或受损目的地。不安全的递归DNS会导致进行恶意软件通过DNS 与命令与控制（C2）通信，另外数据泄露也会经常利用不安全的DNS服务。
DNS在企业安全中可以起到的作用：
  • 在DNS层实施安全防御，可以有效检测和控制类似于WannaCry恶意软件的感染。

 

一些概念补充：

DNS区域传送（DNS zone transfer）指的是一台备用服务器使用来自主服务器的数据刷新自己的域（zone）数据库。这为运行中的DNS服务提供了一定的冗余度，其目的是为了防止主的域名服务器因意外故障变得不可用时影响到整个域名的解析。一般来说，DNS区域传送操作只在网络里真的有备用域名DNS服务器时才有必要用到，但许多DNS服务器却被错误地配置成只要有client发出请求，就会向对方提供一个zone数据库的详细信息，所以说允许不受信任的因特网用户执行DNS区域传送（zone transfer）操作是后果最为严重的错误配置之一。

DNS区域传送漏洞的危害：黑客可以快速的判定出某个特定zone的所有主机，收集域信息，选择攻击目标，找出未使用的IP地址，黑客可以绕过基于网络的访问控制。

# Windows 利用方式：
nslookup
server=ns.vul.com
ls vul.com

# Linux 利用方式：
dig axfr @ns.vul.com vul.com

DNS劫持，就是指用户访问一个被标记的地址时，DNS服务器故意将此地址指向一个错误的IP地址的行为。范例，网通、电信、铁通的某些用户有时候会发现自己打算访问一个地址，却被转向了各种推送广告等网站，这就是DNS劫持。

DNS污染，指的是用户访问一个地址，国内的服务器(非DNS)监控到用户访问的已经被标记地址时，服务器伪装成DNS服务器向用户发回错误的地址的行为。范例，访问Youtube、Facebook之类网站等出现的状况。

参考链接：

=END=

Docker

, , , ,
, , , ,

《 “DNS和安全” 》 有 35 条评论

  1. `
    现在威胁情报里面最有用的两个基础数据：PDNS和网络流量。

    检测的话可以利用pdns数据来分析恶意dns。可以是从企业内部去dns数据中分析恶意dns，也可以是从外部pdns威胁分析服务中获取恶意的dns，如思科的opendns服务；防御方法一般可以采用DNS RPZ来sinkhole/blackhole dns请求(前者是返回无害的dns答复给请求，后者是不返回dns答复给请求，从而阻断恶意dns的请求), 或者采用外部的具备安全能力的DNS服务器，如IBM的 9.9.9.9 DNS服务。

    在内部进行安全分析、检测的话：
    进程树，dns, netflow, http, https 握手，这些能记录的都记录上。
    `

    回复

  11. 从救火到先知-DNS安全分析场景实践谈
    https://zhuanlan.zhihu.com/p/34992317
    https://www.sec-un.org/%e4%bb%8e%e6%95%91%e7%81%ab%e5%88%b0%e5%85%88%e7%9f%a5%ef%bc%8cdns%e5%ae%89%e5%85%a8%e5%88%86%e6%9e%90%e5%9c%ba%e6%99%af%e5%ae%9e%e8%b7%b5%e8%b0%88/
    `
    DNS是互联网和物联网（IOT）的“神经系统”，是连接网络的第一步动作，DNS系统是一个基于C/S结构的巨型分布式数据库系统，实现域名到IP地址的转换，对用户访问各种互联网应用至关重要。DNS协议设计之初的目标是提供一种一致的命名空间和灵活高效的解析服务，DNS系统有着良好的系统性能，同时作为一个开放的系统，也存在着诸多的安全问题和隐患。

    DNS协议的数据报文不受限制地传输，使得DNS通讯作为隐蔽通道在整个攻击链多个环节被黑客们广泛应用，通过研究DNS流量或数据，可以发现网络的安全攻击以及异常行为。虽然很多企业正在全力以赴地应对网络安全威胁，以期能检测和规避网络攻击，但遗憾的是，大多数企业并没有对DNS安全起到足够的重视，至使企业的数据、资产和信誉都处在风险之中。思科2016年度安全报告指出，近91.3%的“已知不良”恶意软件被发现使用DNS作为主要手段，但68%的企业却忽略了这个问题，并没有对DNS解析进行监测，思科非常形象地把这称作“DNS盲点”——DNS是互联网上最常见的协议，但它却成为了最容易被忽视的。

    恶意软件一般通过DNS实现命令与控制(Command and Control)信道、窃取数据和重定向流量等三个目的。除了恶意软件，还有很多网络攻击也离不开DNS，比如APT攻击、垃圾邮件、僵尸网络和挂马网站等，它们都在利用DNS伺机攻击企业的网络。

    域名在一定程度上反映了用户的网络访问行为，对一些用户而言，每天能监测到海量的域名信息，如何从这些海量信息中，抽取需要人工能确认或分析过来的信息至关重要。海量的域名信息，经过白域名库、黑域名的筛选，形成的灰域名数量可以大大减少，可以到达工具或人工的分析程度，同时分析的结果又可以反馈到名单库中。

    (一).基于多元属性特征的检测方法（也称静态安全检测）
    (二).针对域名的行为特征方面（动态安全检测）

    3.安全分析场景
    3.1 隐蔽隧道的监测场景
    3.2 恶意域名的访问分析
    3.3 Visibility场景：解析的趋势分布
    3.4 用户行为分析场景
    3.5 高风险主机检测分析
    3.6 新增域名的监测场景
    3.7 DNS Server监测场景
    3.8 Rdata数据的深入分析
    `

    回复

  18. erbbysam/DNSGrep: Quickly Search Large DNS Datasets
    https://github.com/erbbysam/dnsgrep
    `
    A utility for quickly searching presorted DNS names. Built around the Rapid7 rdns & fdns dataset.
    一个在预先排序的DNS数据集中进行快速搜索的实用程序。基于Rapid7 rdns和fdns数据集构建。
    `

    回复

  19. Datacon DNS攻击流量识别 内测笔记
    http://momomoxiaoxi.com/%E6%95%B0%E6%8D%AE%E5%88%86%E6%9E%90/2019/04/24/datacondns1/
    `
    题目
    比赛结果
    分析思路
    困难与挑战
    时间线
    攻击与检测
    DNS缓存投毒或网关劫持
    DNS域传送漏洞
    非法DNS 动态更新：
    DNS Amplification Attack
    DNS子域名枚举
    DNS tunnel
    Nsec 枚举
    收获
    参考

    考察DNS安全问题，因此首先寻找都有哪些DNS安全问题。
    主要思路：
    攻击者思路：搜索搜集对应的攻击类型，依据特征进行检测。
    Google
    Nmap dns攻击插件
    Nessus dns攻击插件
    防御者思路：
    传统厂商检测规则
    snort
    suricata
    `

    回复

  20. DataCon 2019: 1st place solution of malicious DNS traffic & DGA analysis
    https://paper.tuisec.win/detail/c45f10f2c89e3c0
    https://www.cdxy.me/?p=806
    https://static.cdxy.me/datacon-%E9%98%BF%E9%87%8C%E4%BA%91-%E7%A0%94%E8%AE%A8%E4%BC%9A%E6%9C%80%E7%BB%88%E7%89%88.pdf
    https://github.com/Xyntax/datacon_2019_DNS/
    `
    Q1 DNS恶意流量检测
    解题思路：结合专家经验在多个维度做统计特征，滤出超越统计基线3sigma的异常行为，人工检验异常数据确认攻击，然后编写规则滤出该类攻击全部数据包。
    方案特点：
    使用云环境大数据分析组件，高效完成题目。
    使用异常检测方法，所使用的特征空间能够对数据集做完全线性二分类，达到100% precision和recall。

    1.2 解题策略
    通过对数据的初步人工浏览和简单可视化分析发现：

    数据经过脱敏，因此部分字符分布、语义、信息熵等特征会受到影响。
    时间区间很短，因此并不适合用”对历史行为建模以检测未知”的思路来做。
    数据完整，不存在缺失值填充的问题。
    题中说明存在五种攻击方式，且提交的是DNS query的packet id，表明出题人自信已经100%吃透了这1kw数据包。因此本次五种攻击模式不会太复杂，每种攻击流量都是”干净”的(可以用规则搞定答案全集，不存在模棱两可、特征模糊、人工难辨的情况)，猜测攻击包有可能是出题人自己造的。
    eth层、frame层、UDP层、TCP层的特征高度统一，出题人没有留下漏洞，因此重点分析DNS层即可。

    据此，我的解题策略为：
    原始日志->特征工程->异常检测->人工验证(得到部分答案)->pattern提取->规则匹配->全部答案。

    1.3 特征工程
    接下来开始思考本题的特征维度。根据我的安全经验，将DNS攻击分为三种建模：

    密集请求型：例如随机子域名DDoS、反射型DDoS。其特征为QPS高、时序特征强，一般能够可视化观察到波峰。
    漏洞攻击型：例如针对DNS server的已知漏洞攻击。其特征为数量少、受DNS type影响，适合分类统计。如果批量PoC的话，则特征同1。
    数据传输型：例如DNS Tunnel、Malware DGA、PoC中的DNS回显、SSRF重绑定等。其特征在于域名文本特征明显、适用于规则匹配。

    1.4 异常检测
    将以上统计特征通过全量数据建立基线，然后在每个特征维度滤出超越3sigma的异常值。

    1.5 人工验证及过滤
    将以上异常检测滤出的IP按照异常维度数量排序，依次人工确认是否为攻击行为，然后通过规则滤出存在攻击的数据包。

    1.6 总结
    从结果来看，本题最高效的特征如下：

    DNS type。
    src_ip维度的统计分析特征（QPS、域名数量、请求响应数），因为出题人将src_ip的行为做的非常干净，找到了IP就找到了攻击。
    分析方法只用了3sigma异常基线一种，人工排序观察Top的异常结果，确认攻击后写规则捞出全部同类攻击。
    `

    回复

  21. https://github.com/rrenaud/Gibberish-Detector
    https://pc.nanog.org/static/published/meetings/NANOG71/1444/20171004_Gong_A_Dga_Odyssey__v1.pdf
    https://cloud.tencent.com/developer/article/1142855
    https://github.com/360netlab/DGA/tree/master/code
    https://www.botconf.eu/wp-content/uploads/2015/12/OK-P06-Plohmann-DGArchive.pdf
    https://www.usenix.org/sites/default/files/conference/protected-files/security16_slides_plohmann.pdf
    https://github.com/rmariko/security-ids/blob/0696255b7f2600429a3129bdc1b271d3c4db20ae/ids.py
    https://github.com/LittleHann/DGA-1/blob/master/dga_algorithms/Conficker.cpp
    https://github.com/andrewaeva/DGA/blob/master/dga_algorithms/Matsnu.py
    https://github.com/LittleHann/dga-collection/tree/master/dgacollection
    https://github.com/360netlab/DGA/tree/master/code
    https://github.com/baderj/domain_generation_algorithms/tree/e2ed68a9813b2265652a79291a74b4c23fc13bf0
    https://www.cdxy.me/?p=805
    https://github.com/shyoshyo/Datacon-9102-DNS
    http://momomoxiaoxi.com/数据分析/2019/04/24/datacondns1/
    `
    Q2 DGA域名检测与家族聚类
    解题思路：首先通过专家经验做强关联社区发现洗出一部分DGA域名，以此为正样本训练二分类模型识别DGA域名，然后对结果分别进行社区发现、社区聚合、标签传播扩展与降噪，最终得到结果。
    方案特点：
    1、使用改进的强社区发现方法和专家知识，将无监督问题转化为有监督问题。
    2、从种子样本到二分类、社区发现、降噪，最终结果回流到样本集，不断递归收敛最终获取准确结果。
    3、通过DGA公开家族特征、whois特征、http响应特征等扩展数据增强结果。

    解题策略：
    1、解题前没有label数据，属于零先验知识数据挖掘，因此不能直接设计单个model进行multiclass多分类一步得到所有DGA家族分类。
    2、针对这种场景，我们设计了一个 种子样本生成-二分类-社区发现-降噪与传播-更新种子样本 的循环工作流，在每次迭代过程中的”降噪与传播”部分引入专家经验，在每次迭代中提高精度和召回，最终逼近正确答案。

    特征维度：
    1、稀有TLD
    2、DGA家族互斥假设
    3、WHOIS特征
    4、域名访问频次
    5、域名长度统计
    6、源IP计数
    7、信息熵
    8、域名可读性
    9、Markov概率
    10、N-Gram平均排名

    结果优化
    这一步通过引入其他维度数据进一步提高精度和召回。

    域名维度特征：
    Only SLD+TLD && length(SLD) > 5
    Number of rdata < 5
    HTTP alive
    NXDOMAIN rate
    WHOIS existed
    WHOIS sinkhole
    Alexa rank < 1M
    IP malicious request rate
    DGA Generate Algorithm

    社区维度特征：
    NXDOMAIN≥ 20%
    Number of Domain names ≥ 4
    Query in a short times
    `

    回复

  22. 安全应急之命令控制
    https://l0gs.xf0rk.space/2019/06/14/about-command-and-control/
    `
    命令控制 (C&C、CNC、Command & Control），受控机器（木马后门）与攻击者控制服务器通讯行为。受控机器通过一定的通道，从控制服务器获得指定的业务指令并执行恶意行为，例如上传从宿主机偷窃的到的信息、定时给感染机文件加密勒索等。

    根据命令控制通道所使用的协议及实现方式不同，常见的类型如下所示：

    SSH 隧道（SSH 代理、端口转发），建立一个 SSH 通道，将相关数据包转发至目标机器
    HTTP 命令隧道，将 TCP 流量数据包或控制命令数据封装到 HTTP 数据包中，相关测试工具有 reGeorgl 等
    ICMP 命令隧道，将命令控制指令封装到 ICMP 数据包中，相关测试工具有 icmptunnel 等
    DNS 命令隧道，将命令控制指令封装到 DNS 数据包中，相关测试工具有 dnscat2 等

    下文将介绍 DNS 命令隧道分类、命令控制实践及 DNS 查询日志采集等。

    1. 命令控制隧道
    1.1. 命令隧道
    2. DNS 命令隧道
    2.1. IP 型 DNS 命令隧道
    2.1.1. IP 隧道本质
    2.1.2. DNSCAT2 演示
    2.2. 域名型 DNS 命令隧道
    2.2.1. DNS 递归解析
    2.2.2. DNSLOG 演示
    2.2.3. 域名请求有效空间
    3. DNS 流量采集
    3.1. SYSMON 工具采集
    `

    回复

  25. DNS 隧道通信特征与检测
    http://blog.nsfocus.net/dns-tunnel-communication-characteristics-detection/
    `
    一、DNS 隧道技术解析
    1.1 DNS协议解析过程
    1.1.1 迭代查询
    1.1.2 递归查询
    1.2 DNS隧道
    1.2.1 DNS隧道攻击实现流程
    1.2.2 典型恶意程序
    1.2.3 经典的攻击事件
    二、DNS隧道攻击实现以及流行工具展示
    2.1 测试平台
    2.2 dns2tcp
    2.2.1 dns2tcp建立隧道流程
    2.2.2 dns2tcp数据包分析
    2.2.3 总结
    2.3 iodine
    2.3.1 iodine建立隧道流程
    2.3.2 iodine数据包分析
    2.3.3 总结
    2.4 Dnscat2
    2.4.1 Dnscat2 建立隧道流程
    2.4.2 Dnscat2 数据包分析
    2.4.3 总结
    三、检测DNS隧道木马
    3.1 DNS会话中数据包的总数
    3.2 隧道消息类型
    3.3 域名固定部分不变
    `

    回复

  26. 一次出人意料而名留青史的DNS投毒攻击
    https://mp.weixin.qq.com/s/KaIiJaKDrE2Q5iZ_GwBG1g
    `
    2008年7月，在互联网上发生了一件极具历史意义的DNS安全事件，该事件一经发布，立即震动了整个互联网，因为，自1983年DNS被发明以来，人们还从未遇到过这类影响深远而易于实现的攻击。Cricket Liu, 《DNS and BIND》（O’Reilly出版）的作者， 认为这可能是互联网历史上最大的一次DNS安全事件。1

    这个攻击是美国人Dan Kaminsky精心构造的，他本人因此一战成名，该攻击也因此被命名为Kaminsky攻击。

    漏洞由CERT于2008年7月8日发布2，但没有公布细节，Dan那时正在协助一些DNS厂商补上这个漏洞，并计划于8月6日在拉斯维加斯召开的Black Hat年度安全大会上披露全部细节内容（然而漏洞细节还是在7月21日被泄漏了出来），由于明明知道有漏洞却又不知道到底怎么回事，当时安全圈内颇有一些人对Dan表示了不满3。

    该攻击令人恐惧之处在于，攻击者并不要求有什么特别的条件（比如占据某个路由交换节点可以监听和修改DNS报文），也无需使用社工之类的手段，攻击者就是一个普普通通的网络用户，却可以使用该方法，无差别地在全球复现这个攻击。

    攻击产生的后果是什么？

    后果是DNS服务器缓存中的记录被修改（所谓被“投毒”），比如用户本来想访问www.baidu.com，如果本机没有缓存，就会向本地DNS查询该域名的IP，但由于DNS服务器被投毒，所以用户得到的IP并不是想要去的地方，而是一个攻击者设定的IP，这样，用户就被牵引到完全可能是恶意的网站。

    这种对IP的掉包，对搞信息安全的人来讲，哪怕是随便想一想，都会毛骨悚然。

    在用户层面是无法感知和防范这种攻击的，因为攻击破坏了互联网底层的基础设施：域名服务。而域名服务正是那种它不出事时你意识不到它存在，一旦出事都是大事的东西。
    `

    回复

  28. DNS攻击和防护
    http://www.h3c.com/cn/d_201311/804188_30008_0.htm

    DNS安全威胁及未来发展趋势的研究
    https://www.freebuf.com/articles/network/169175.html

    DNSSEC ‘and’ DNS over TLS
    https://blog.apnic.net/2018/08/20/dnssec-and-dns-over-tls/
    `
    1. DNS 的概念/定义

    域名系统（DNS）是 Internet 的电话簿。人们通过例如 nytimes.com 或 espn.com 等域名在线访问信息。Web 浏览器通过Internet 协议（IP）地址进行交互。DNS 将域名转换为 IP 地址，以便浏览器可以加载 Internet 资源。

    2. DNS 存在的安全问题和风险

    针对DNS的DDoS攻击（利用僵尸网络或是工具软件伪造源IP发送海量DNS查询）

    DNS欺骗（缓存投毒、劫持、重定向）

    3. DNS 的各种安全增强方案它们的功能和侧重点

    DNS over HTTPS
    * 本质上，DoH依靠HTTP客户端的安全性来提供其安全性保证，从而将建立安全TLS连接的所有复杂性移交给建立该连接的HTTP客户端。要注意的一件事是，尽管DoT提供了一种服务器身份验证方法，但DoH要求对服务器进行身份验证。

    DNS over TLS
    * 简而言之，DoT提供了传输层的机密性，避免信息明文传输。(In short, DNS-over-TLS is designed to provide confidentiality and integrity between a DNS client and server, only when using the Out of Band Key Pinned Privacy Profile. DoT also provide the Opportunistic privacy profile for compatibility with current network setups, although this privacy profile does not guarantee confidentiality and integrity.)

    DNSSEC
    * 在传统的DNS数据中添加了数字签名，这可确保DNS数据的接收者可以验证源站的身份，同时可以验证在传输过程中数据是否被修改过。

    DoT和DoH都旨在提供DNS数据的机密性和完整性，并保护DNS客户端和服务器之间的通信通道。但DNSSEC的目的是确保DNS数据的真实性，并确保DNS记录数据源自经过身份验证的来源。DNSSEC与DoT和DoH兼容并互补。
    (DoT and DoH both aim at providing confidentiality and integrity of DNS data and securing the communication channel between the DNS client and server. DNSSEC however aims and insuring the authenticity of DNS data and ensuring the DNS record data originated from an authenticated source. DNSSEC is both compatible with, and complementary to, DoT and DoH.)

    In terms of a secure and trusted DNS, we need more security elements, not less.
    在安全可靠的DNS方面，我们需要更多的安全元素，而不是更少。
    `

    回复

  29. 什么是 DNS？ | DNS 的工作方式
    https://www.cloudflare.com/zh-cn/learning/dns/what-is-dns/

    DNS 安全
    https://www.cloudflare.com/zh-cn/learning/dns/dns-security/

    基于 HTTPS 的 DNS 和基于 TLS 的 DNS | 安全 DNS
    https://www.cloudflare.com/zh-cn/learning/dns/dns-over-tls/

    什么是 DNS
    https://www.cloudflare.com/zh-cn/learning/ddos/glossary/domain-name-system-dns/

    DNS 服务器类型
    https://www.cloudflare.com/zh-cn/learning/dns/dns-server-types/

    DNSSEC: An Introduction
    https://blog.cloudflare.com/dnssec-an-introduction/

    DNS Security: Comparing DNS-over-TLS, DNSSEC and DNS-over-HTTPS
    https://blog.circuitsofimagination.com/2018/11/08/dns-o-t-dnssec-dns-o-h.html

    What is the difference between DNSSEC and DNS security?
    https://www.infoblox.com/dns-security-resource-center/dns-security-faq/what-is-the-difference-between-dnssec-dns-security/

    回复

  30. 阿里云DNS – 打造安全稳定的数字经济基础设施
    https://bcs.qianxin.com/2020/pc_pptdown.html
    https://shs3.b.qianxin.com/qax-cms/b81e54e24f3aa805a45736a847d083bf.pdf
    `
    # DNS加密和隐私保护
    • DNSSEC(RFC4033/4034/4035)并没有特别的针对数据保密和用户隐私性的要求，DNSSEC 唯一的隐私性考虑 是避免区文件被遍历枚举的风险，增加了NSEC3协议
    • 斯诺登事件之后，IAB/IETF开始热议隐私性问题，陆续发布了相关标准和技术要求： RFC7526 DNS Privacy Considerations，RFC7858 DNS over TLS （DoT），RFC8484 DNS over HTTPS（DoH）
    • 2019年 DNS技术社群发起的“DNS加密部署计划”, IETF 发起ADD工作组（ https://datatracker.ietf.org/wg/add/about/ ）

    截止到2020年7月底：
    • 操作系统支持DNS加密：苹果iOS、微软Windows，谷歌Android
    • 主流浏览器和内核支持DoH： Chrome和Firefox
    • 公共DNS加密服务：Google DNS，Cloudflare DNS， 阿里云公共DNS
    `

    回复

  31. 关于BGP安全那些事儿
    https://mp.weixin.qq.com/s/rZunI6Uxyks2TbSarsqR8A
    `
    # 导语
    美国时间10月4日中午，Facebook公司网络出现重大故障，故障持续了6个小时后才恢复。官方给出的故障原因，简单来说是一次误操作引发了连锁反应。
    （复杂点就是：在例行网络维护中，发送的一条命令无意中关闭了其全球骨干网的所有BGP连接，在其DNS服务器与内部网络不通后触发了内部机制，自动禁止DNS服务所在网段的BGP路由播布，而这又导致故障范围进一步加剧，并对故障恢复带来极大困难）。
    这是Facebook创立以来最严重的一次网络访问事故，在这起故障中，我们又看到了BGP的身影（我为什么要说“又”）。

    # BGP是什么？
    BGP协议，全称Border Gateway Protocol（边界网关协议），是组成我们当今Internet的一种去中心化的自治系统间的动态路由协议，它允许Internet上不同AS（自治系统）之间自动交换IP路由信息和可达信息，最主要功能在于控制路由的传播和选择最好的路由，并且还具备冗余备份、消除环路的特点。

    # BGP安全问题有哪些？
    BGP路由的安全威胁，可以大致分为两大类：BGP路由劫持（包括IP前缀劫持、IP子前缀劫持、AS路径篡改）、BGP路由泄露。

    1) BGP路由劫持
    a. 流量被“黑洞”，正常访问中断
    b. 流量被中间人监听或攻击，或重定向到虚假网站以窃取数据
    c. IP被用于进行垃圾邮件活动
    d. 正常用户访问路径变长，网络延迟增加

    2) BGP路由泄露
    a. 泄露者AS网络流量拥塞，引发网络丢包
    b. 造成互联网局部链路拥塞，引发网络丢包
    c. 泄露者AS无下一跳路径，导致流经该AS的流量中断

    3) 其他
    拒绝服务攻击（DoS）：恶意或无意导致的配置错误的BGP表内容，将流经该AS的流量错误地指向其它AS网络，可能引发受害者AS网内拥塞或流量中断

    # 如何监控和防范
    1. IP前缀检测
    2. 全路由认证安全机制

    # 写在最后
    其实在导语所述故障中除了BGP之外，还有另外一个基础协议的身影–DNS，作为互联网的基础设施，BGP和DNS的安全理应得到更多的重视。
    这类故障不是第一次出现，也必然不会是最后一次出现。希望从顶层设计到底层实现，从业界到厂商，能共同携手更好的提升这里的安全能力。如同这个文章也许受众会很窄、浏览量会很低，但是我们仍然希望更多的朋友能看到。
    `

    回复

    • 关于BGP安全那些事儿
      https://mp.weixin.qq.com/s/rZunI6Uxyks2TbSarsqR8A

      ==
      这类故障不是第一次出现，也必然不会是最后一次出现。希望从顶层设计到底层实现，从业界到厂商，能共同携手更好的提升这里的安全能力。

      想起以前教网络的老师讲的一句话，TCP/IP协议是一个跛腿的协议，由于”出现的早，接受的多”而战胜了其他的一些网络协议方案（比如OSI模型），但出来混迟早是要还的，尤其是现在对安全越来越重视、研究越来越多的情况下；不过底层基石协议出问题，上层想要补救修复可没那么容易，完全规避肯定是不可能了，就看以后有没有办法重新弄一套然后切换过去了（说不定也会出现类似的演进过程？）。

      如果把业界+厂商比做真实世界里的一个大公司，业界就像是提供infrastructure的基础架构部门，厂商就像是基于基础架构部门的设计/能力自行开发/封装上层应用的各BU/BG，然后就会发现：

      0. 最初做infrastructure设计/开发的人不多，没想到公司能发展这么快，只想着能支撑到一定容量就可以了；也没有考虑太多的security方面的问题，只考虑到了一些简单的场景（当时用户也不多、产品有限，已经完全够了）；……

      1. 随着公司的快速发展，之前infrastructure设计考虑不足的问题逐渐暴露（对应的就是现实世界中的各大故障）；然后公司内部开始审视这些问题，但因为现在公司确实是太大了，各BU/BG发展也不是那么均衡，所以就会出现：
      a. 发展快、实力强的BG（比如国外的FAANG、国内的腾讯阿里），开始自建轮子替换有问题的基础设施模块，同时反过来推动infrastructure修补以前考虑不充分的设计……
      b. 发展中的基础架构部门，正在/已经开发出了比之前更好的infrastructure产品，在努力推动公司内的各BU/BG替换之前的产品……
      c. 发展没那么快的BU/BG、新设立的小部门，也许才刚刚熟悉了之前的infrastructure产品用法，业务还在起步甚至是挣扎阶段，就被通知要改代码进行升级，业务开发心里的想法是？？？？？
      d. 各种「历史遗留问题」……

      2. 毕竟公司是一个大的整体，所以：
      a. 即便是发展很快很强的大BG也无法完全做到独善其身，底层基础设施有问题了，他们也可能会受到影响，虽然他们自己已经做了很多的工作（这也是他们推动业界和其它厂商共同进步的原因之一）；
      b. 设计实施infrastructure的业界也在努力，他们也没法一开始就预见到所有后面发生的事情，尤其是在资源和能力都有限的早期，后面的推动他们能做的也有限；
      c. 小部门也不是不想快速跟进业界最佳实践，资源能力不允许啊；
      d. 改好了，功劳是没有的；没改好，黑锅已经提前准备好了。

      3. 总的来看，公司整体infrastructure能力（包括安全属性）已经在快速发展和提升了，但因为外部发展太快（而且专门研究的人变多），之前欠下的债过多，所以短期内问题还会不断暴露，不过长期上，肯定是会变得更好的（趋势是上升的，但具体道路却是迂回、曲折的）。
      ==

      回复

  32. BGP劫持原理及如何防御
    https://www.secpulse.com/archives/187787.html
    `
    即，BGP劫持之所以很常见且很难避免的原因在于——BGP在 1989 年首次面世的时候并没有考虑到安全性，而是认为每个BGP都在说真话，且BGP前缀通告的内容中【IP段前缀】和【AS_PATH】都可以伪造，因此其它的BGP是无法分清楚哪个通告是真的哪个通告是假的，当前只能通过监控来发现这类问题。

    ==
    互联网跟人类社会一样，都通过特定的规则和法律来确保社会的正常运行。BGP协议就是互联网中的“规则”之一。BGP用于在不同的自治系统(AS)之间交换路由信息，当两个AS需要交换路由信息时，每个AS都必须指定一个运行BGP的节点，来代表AS与其他的AS交换路由信息。
    ==

    但这些规则可能会被人为或意外打破。**破坏 Internet 规则的最常见方式之一是 BGP 路由器通告不属于其自己的 AS 的前缀，也就是说，BGP路由器非法宣布特定前缀，从而将流量从其预期目的地重定向到它自己的 AS。这称为 BGP 路由劫持，也称为前缀劫持、路由劫持和 IP 劫持。**

    2018 年 4 月，恶意黑客公布了一些属于 Amazon Web Services 的 IP 前缀，一些试图登录加密货币网站的用户被重定向到黑客所创造的虚假网页之中，导致了超过 160,000 美元的损失。

    除了恶意攻击，BGP 劫持的意外实施也可能产生严重后果。2008 年，巴基斯坦的一家 ISP 试图通过更新其 BGP 路由来审查 YouTube，由于在审查过程中配置错误，整个互联网中的YouTube 流量路全都输送到了巴基斯坦 ISP，导致了全球 YouTube 长达数小时的中断。

    **BGP劫持之所以非常常见，很大一部分原因是因为BGP的设计者并未考虑到BGP劫持的可能性，并且默认所有 BGP “说话者”都在说真话。**如果想要了解如何减轻这种风险，首先要了解 BGP 前缀通告和 BGP 劫持的工作原理。

    # BGP 如何通告前缀？

    AS 由多个路由器组成，并在其边界内包含特定的前缀或路由，向相邻的 AS 通告。BGP 路由器在整个 Internet 中传播这些前缀，并通过各种 AS 维护到该目的地的路径，每个 AS 负责向其邻居宣布它拥有并包含在其中的前缀，BGP 路由器中维护的 BGP 表，其中包含为到达该特定前缀必须经过的 AS 路径。
    例如下图：
    …

    当AS 100需要与AS170建立联系时，首先需要将自己的前缀 195.25.0.0/23 通告给相邻的 AS。这样，当该信息到达 AS 170 时，路由表中的信息将包括：
    前缀：195.25.0.0/23
    AS_PATH: AS100 AS190

    在这个过程中，如果 AS 170 收到来自具有不同路径的此前缀，则会优先选择最短路径，即绿色虚线建立联系。（如红色虚线路径更长，穿越的 AS 数量更多，假设之前所有的 BGP 属性都保持不变，会通过最短路径，也就是绿色路径进行传播。）

    在 AS 边缘与其他 AS 中的 BGP 路由器形成对等互连的是外部 BGP 或 eBGP 路由器，eBGP 路由器负责向其他 AS 通告前缀。

    当“敌对”AS 宣布它实际上不受控制的IP前缀的路由时，就会发生 BGP 路由劫持。例如，在下图中，AS 140 非法通告与 AS 100 相同的前缀：
    …

    AS 140 中的恶意劫持者正在宣传不属于自己的 AS 的前缀，所有其他 AS 将收到两个具有相同前缀的不同通告，后续的选择将取决于 BGP 属性。

    **所以，AS_PATH 长度属性在 BGP 劫持中的具有非常重要的作用，假设所有先前的属性保持不变，将按照最短 AS_PATH 的路由。**如果 AS_PATH 相等，则由其他属性决定，例如最旧的路径或路由器 ID，这会导致路由的结果难以预测。在上图中，只有 AS 190 可以确保正确路由到 195.25.0.0/23 前缀。

    此外，劫持者可以执行所谓的 AS_PATH 伪造，其中对目的地的通告 AS_PATH 进行修改，以便发往相关路由的流量将通过本地 AS。在这些情况下，合法 AS 包含在 AS_PATH 中，以便在将流量引导至非法 AS 时更难检测到此类劫持。（对于这点不是太理解？难道流量在被路由到1个AS之后还会继续往后走？）

    那么BGP劫持会造成什么后果，劫机者又为什么要劫持呢？
    BGP劫持可能导致互联网流量出错，被监控或拦截，被“黑洞”，或者作为中间人攻击的一部分将流量导向虚假网站。此外，垃圾邮件发送者可以使用BGP劫持或实施BGP劫持的AS网络，以欺骗合法IP以进行垃圾邮件。

    另外，攻击者可能执行 BGP 路由劫持的原因包括：
    * 拒绝对特定在线服务的服务。
    * 将流量重定向到伪造网页，以实现凭据、***号和其他机密信息的网络钓鱼。
    * 重定向流量以压倒某些服务。
    * 为了破坏而破坏，进行无差别攻击。

    BGP劫持是对 Internet 上正确路由操作的一个非常真实的潜在威胁。因此，采用适当的机制和配置来防止此类攻击和事故非常重要。**然而，我们并不能直接避免BGP劫持的发生，除了持续监控互联网流量如何路由之外，用户和网络可以做很少的事情来防止BGP劫持。**

    # IP段前缀过滤
    大多数网络应该只在必要时接受IP段前缀声明，并且只应将其IP前缀声明到某些网络，而不是整个Internet。这样做有助于防止意外的路由劫持，并可能使AS不接受伪造的IP前缀声明; 但是，这在实践中很难实施。

    # BGP劫持检测
    劫持检测可以采取多种形式。基线性能的变化，例如更大的延迟、错误的流量或性能的普遍下降是可能表明某种形式的劫持的初步迹象。此外，监控广告以及记录路线的可用性和停机时间是发现劫持的重要方面。
    更复杂的系统还可以分析来自邻居的公告 AS 以查看被劫持的前缀是否包含在公告中，可以识别前缀不匹配，并使用路径分析来确保正确的路由。

    # BGPsec
    从 1989 年BGP首次面世以来，就在不断的发展和改进。但直到在 2017 年引入 BGPsec 时，才进行了一些安全性的尝试，但尚未得到任何实质性采用。所以，就目前而言，这个 30 多年的协议本质上仍然很脆弱，需要一些复杂的监控机制来控制它。
    有可能有助于打击 BGP 路由劫持的一个方面是使用路由源授权 (ROA)。ROA 是加密签名的对象，可用于验证特定前缀是否源自合法 AS。ROA 由每个 AS 所有者与区域互联网注册机构 (RIR) 合作创建，RIR 提供生成它们所需的 RPKI 基础设施。
    `

    回复

  33. 告别DNS劫持，一文读懂DoH
    https://www.upyun.com/tech/article/629/%E5%91%8A%E5%88%ABDNS%E5%8A%AB%E6%8C%81%EF%BC%8C%E4%B8%80%E6%96%87%E8%AF%BB%E6%87%82DoH.html
    `
    #DoH(DNS over HTTPS) 的优点和缺点
    DoH 的优点是显而易见的，该技术提高了安全性并保护了用户隐私。与传统的 DNS 相比，DoH 提供了加密措施。它利用 HTTPS 这种行业通用的安全协议，将 DNS 请求发往 DNS 服务器，这样运营商或第三方在整个传输过程中，只能知道发起者和目的地，除此以外别的什么都知道，甚至都不知道我们发起了 DNS 请求。

    DoH 的加密措施可防止窃听或拦截 DNS 查询，但这也会带来了一些潜在的风险。多年以来实施的一些互联网安全措施都要求 DNS 请求过程可见。例如，家长控制需要依靠运营商为一些用户阻止访问某些域名。执法部门可能希望通过 DNS 数据来跟踪罪犯，并且许多组织都会使用安全系统来保护其网络，这些安全系统也会使用 DNS 信息来阻止已知的恶意站点。引入 DoH 可能会严重影响上述这些情况。因此，目前 DoH 还处于自主配置的时期。用户需要清楚谁可以看到数据，谁可以访问数据以及在什么情况下可以访问。

    #DoH 与 DoT(DNS over TLS)
    除了基于 HTTPS 的 DNS 外，目前还有另一种用于保护域名系统的技术：基于 TLS 的 DNS（DoT）。这两个协议看起来很相似，它们也都承诺了更高的用户安全性和隐私性。但是这两项标准都是单独开发的，并且各有各的 RFC 文档。DoT 使用了安全协议 TLS，在用于 DNS 查询的用户数据报协议（UDP）的基础上添加了 TLS 加密。DoT 使用 853 端口，DoH 则使用 HTTPS 的 443 端口。

    由于 DoT 具有专用端口，因此即使请求和响应本身都已加密，但具有网络可见性的任何人都可以发现来回的 DoT 流量。DoH 则相反，DNS 查询和响应在某种程度上伪装在其他 HTTPS 流量中，因为它们都是从同一端口进出的。

    关于 DoT 和 DoH 究竟哪个更好？这个还有待商榷。不过从网络安全的角度来看，DoT 可以说是更好的。它使网络管理员能够监视和阻止 DNS 查询，这对于识别和阻止恶意流量非常重要。另一方面，DoH 查询隐藏在常规 HTTPS 流量中。这意味着，若不阻止所有其他的 HTTPS 流量，就很难阻止它们。
    `

    回复

  34. DNS加密说明
    https://blog.cloudflare.com/zh-cn/dns-encryption-explained-zh-cn/
    `
    #加密DNS
    对DNS进行加密会使网络窥探者更难以查看您的DNS信息，或在传输过程中破坏它们。就像网络从未加密的HTTP迁移到加密的HTTPS一样，现在也有对DNS本身加密的DNS协议的升级。加密网络使私人和安全的通信与商业得以蓬勃发展。加密DNS将进一步增强用户隐私性。

    存在两种标准化的机制来保护您和解析器之间的DNS传输，即DNS over TLS (2016) 和DNS Queries over HTTPS (2018)。两者都基于传输层安全性（TLS），TLS也用于保护您与使用HTTPS的网站之间的通信。在TLS中，服务器（无论是web服务器还是DNS解析器）使用证书向客户端（您的设备）进行身份验证。

    通过DNS over TLS（DoT），原始的DNS消息被直接嵌入到安全的TLS通道中。从外面看，他人既无法了解正在查询的名称，也无法对其进行修改。预期中的客户端应用程序将能够解密TLS。

    在对未加密DNS包的跟踪中，很明显，客户端可以直接发送一个DNS请求，然后解析器给出一个DNS响应。然而，在加密的DoT情况下，在发送加密DNS消息之前客户端与服务器会交换一些TLS握手消息：
    * 客户端发送一个Client Hello，通告其支持TLS功能。
    * 服务器以服务器Hello响应，并同意将用于保护连接的TLS参数。证书消息包含服务器的身份，而证书验证消息将包含数字签名，客户端可以使用服务器证书对其进行验证。客户端通常会根据其本地受信任的证书颁发机构列表来检查此证书，但是DoT规范提到了其他信任机制，例如公钥固定。
    * 客户端和服务器都完成TLS握手后，它们终于可以开始交换加密的消息。
    * 虽然上面的图片仅包含一个DNS查询和响应，但在实践中，安全TLS连接将保持开放，并将被重新用于以后的DNS查询。

    此前已实现通过新端口上非常快的TLS来保护未加密协议：
    * 网络流量：HTTP (tcp/80) -> HTTPS      (tcp/443)
    * 发送电子邮件：SMTP (tcp/25) -> SMTPS      (tcp/465)
    * 接收电子邮件：IMAP (tcp/143) ->      IMAPS (tcp/993)
    * 现在：DNS (tcp/53 or udp/53)      -> DoT (tcp/853)

    引入新端口的一个问题是现有的防火墙可能会阻止它。因为它们采用了必须明确启用新服务的白名单方法，或者因为采用了网络管理员明确禁止服务的阻止列表方法。如果安全选项（DoT）比不安全选项的可用性更低，那么用户和应用程序可能会试图退回到未加密的DNS。这随后可能允许攻击者强制用户使用不安全的版本。

    这种回退攻击不是仅存于理论上的。SSL剥离此前曾被用于将HTTPS网站降级为HTTP，从而允许攻击者窃取密码或劫持账户。

    另一种方法，DNS Queries over HTTPS（DoH），旨在支持两个主要用例：
    * 防止路径上的设备干扰DNS的上述问题。这包括上面的端口阻塞问题。
    * 允许web应用程序通过现有的浏览器API访问DNS。
    DoH本质上是HTTPS，与web使用的加密标准相同，并且重用相同的端口号（tcp/443）。Web浏览器已经不支持不安全的HTTP，而支持HTTPS。这使得HTTPS成为安全传输DNS消息的最佳选择。您可以在这里找到此类DoH的请求示例。

    #部署DoT和DoH
    由于DoT和DoH都是相对较新的技术，它们还没有得到普遍应用。在服务器端，主要的公共解析器包括Cloudflare的1.1.1.1和谷歌DNS都支持它。然而，许多ISP解决方案仍然缺乏对它的支持。您可以在DNS服务器源上找到支持DoH的一小部分公共解析器，还可以在DNS隐私公共解析器上找到另一种支持DoT和DoH的公共解析器。

    有两种方法可在最终用户设备上启用DoT或DoH：
    * 添加对应用程序的支持，绕过来自操作系统的解析器服务。
    * 添加对操作系统的支持，透明地为应用程序提供支持。

    在客户端，DoT或DoH通常有三种配置模式：
    * 关闭：DNS将不会被加密。
    * 机会模式：尝试为DNS使用安全传输，但如果前者不可用，则退回到未加密的DNS。这种模式容易受到降级攻击，攻击者可以迫使设备使用未加密的DNS。机会模式的目的是在没有活跃的攻击者时提供隐私性。
    * 严格模式：尝试通过安全传输使用DNS。如果不可用，则出现严重故障并向用户显示错误。
    `

    DNS over TLS
    https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/
    `
    By default, DNS is sent over a plaintext connection. DNS over TLS (DoT) is one way to send DNS queries over an encrypted connection. Cloudflare supports DNS over TLS on standard port 853 and is compliant with RFC7858. With DoT, the encryption happens at the transport layer, where it adds TLS encryption on top of the user datagram protocol (UDP).
    默认情况下，DNS查询是通过明文进行传递的。DNS over TLS(DoT)是通过加密连接发送DNS查询的一种方法。Cloudflare在标准端口853上支持DNS over TLS，并符合RFC7858标准。使用DoT，加密发生在传输层，它在用户数据报协议(UDP)之上添加TLS加密。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注