1. 实验

​ 本实验的目标是获得对DNS（域名系统）的各种攻击的第一手经验。DNS是互联网的电话簿；它将主机名转换为IP地址，反之亦然。这种转换是通过DNS解析实现的，这种解析发生在幕后。DNS欺骗攻击以各种方式操纵此解析过程，目的是将用户误导到其他目的地，这些目的地通常是恶意的。本实验室主要研究几种DNS欺骗攻击技术。将首先设置和配置DNS服务器，然后在实验室环境中的目标上尝试各种DNS欺骗攻击。

​ 第一个大实验任务（本地DNS欺骗）中进行的攻击假设攻击者位于同一本地网络上，因此可以嗅探DNS数据包。这个假设是为了简化实验任务。第二个大实验任务为远程DNS攻击实验，攻击者在没有嗅探数据包的情况下发起远程欺骗攻击，远程攻击实验室比本地DNS欺骗实验更具挑战性

2. 实验步骤及结果

2.1 DNS _Local

2.1.1 环境搭建

容器部署

1. 清除上次docker网络环境
   

2. 启动容器
   

​ LAN结构如下：

DNS配置

1）Local DNS Server(对应10.9.0.53)

​ 已经部署了bind9程序，配置文件见 etc/bind/named.conf

• 简化：将源端口号固定为33333（DNS服务器会将DNS请求的源端口号随机化使得攻击更加困难）。文件named.conf.options:
  

• 关闭DNSSEC（DNSSEC 是防止DNS欺骗的保护机制）。文件named.conf.options:
  

• DNS cache，以下为常用命令：

  # rndc dumpdb -cache // Dump the cache to the specified file:/var/cache/bind/dump.db
  # rndc flush // Flush the DNS cache
  

• 转发attack32.com zone：请求该域名的都会被转发到它的nameserver
  

2）user

​ 在/etc/resolv.conf中将10.9.0.53添加为第一条nameserver记录，将local dns server作为首要的DNS服务器。

3）Attacker

​ 设置Attacker的nameserver（ etc/bind/named.conf），第一个为合法的zone attacker32.com，第二个为虚假的example.com zone：

测试部署

Get the IP address of ns.attacker32.com

与 Attacker nameserver 的zone file对应（此前DNS配置 local DNS server第四点）

Get the IP address of www.example.com.

1）user主机，输入命令dig www.example.com，会直接发请求给local DNS server,其会把请求发给对应的官方的nameserver：

2）使用@，直接发给ns.attacker32.com:

​ 获得的结果与Attacker上zone文件相同：

3）DNS缓存投毒目标

​ 使受害者 向ns.attacker32.com发送请求，如果攻击成功，输入1）的命令，即可直接获得从attacker处的虚假结果，而不会从域名的合法nameserver处（2）的效果）。

2.1.2 The Attack Tasks

Task 1: Directly Spoofing Response to User

1. 使用netwox工具

   1）在local DNS Server 使用命令rndc flush清除缓存。

   2）在seed-attacker容器内运行如下：
   
   3）user发起dns请求，成功被欺骗：
   

2. 使用scapy

   1）编写代码task1.py如下：

   ​ 构造欺骗信息如红框，注意iface为10.9.0.0/24对应的网卡。
   

   2）local DNS Server处清除缓存（rdnc flush)
   3) attacker容器内运行攻击scapy代码

   4）user端进行dns请求，实际信息被篡改，即攻击成功：
   

   5） 潜在问题补充

   ​ 实际实验中成功没有问题。实验手册中补充，可能会存在正常请求的响应比欺骗包回的快，提出解决方案：使用tc命令延迟向外的流量

   // Delay the network traffic by 100ms etho对应向外的路由器的网卡，即本实验中对应10.8.0.0/24的网卡
   # tc qdisc add dev eth0 root netem delay 100ms
   // Delete the tc entry
   # tc qdisc del dev eth0 root netem
   // Show all the tc entries
   # tc qdisc show dev eth0
   

Task 2: DNS Cache Poisoning Attack – Spoofing Answers

​ task1将攻击目标聚焦于user，需要总是等待user进行请求，效率并不高。task2将目标聚焦于DNS server，会是更高效的方式，即DNS缓存投毒：如果攻击者伪装从其他DNS server来的响应，该DNS Server就会把内容存储在缓存中，会保留相当长的一段时间。在该期间的请求都会直接返回缓存内的结果。我们只需spoof一次，影响就会持续直到下次缓存更新。

1. 使用scapy编写代码task2.py,目标为伪造local dns server发出的向其他dns server的查询的响应包
   
   注：ns记录相关没有对应编写，具体见task3；filter处可以再限制一下条件（src host 10.9.0.53 and dport 53)。

2. 运行代码，user发起一次查询，成功实现欺骗（local dns server先flush缓存）。
   

3. 查看缓存情况，确认投毒结果

   1）local dns server中，将cache dump下来并保存到文件中
   
   2）为方便查看，将文件复制到虚拟机中打开
   
   cache被改变，投毒成功：
   

Task 3: Spoofing NS Records

​进一步修改task2代码，实现NS记录的欺骗，以达成任何example.com的子域名dns请求都会返回被某恶意权威域名服务器的控制的结果。

1. 缓存投毒代码task2.py修改如下，代码见task3.py
   

2. local dns server清除缓存

3. attacker运行代码，user仍旧通过www.example.com查询
   

4. 结束代码运行，测试其他子域名

   hello.example.com:
   

   test.example.com:
   

   实现成功！

5. 缓存情况确认

   将local DNS server的缓存保存到文件中。具体步骤见task2。

   被修改的ns记录：
   

   刚刚查询的example.com域名：
   

Task 4: Spoofing NS Records for Another Domain

​ 通过Authority Section，将影响扩充到google.com。实验经过：

1. 如下，在task3.py基础上修改编写task4.py，，增加NS记录，其他保持一致。

   测试构造多个NS：
   

2. 清除缓存，attacker运行代码，user端dig www.example.com。查看缓存

   发现仅example.com的被留在缓存中
   

3. 尝试调换NS记录顺序
   
   仍旧不行

4. 将包的判定条件修改为example.com，成功

   并且，user端dig 任意example.com的子域名都可以。
   
   

5. 验证

   如下，将NS_NAME仍旧改为www.example.com,与3一样，不一样的是，把NS记录google.com改为google.example.com。发现成功录入cache。
   
   

6. 综上总结

   a. 成功的实验步骤为4.所示，1）攻击代码为task4.py；2）local DNS host 清除缓存；3）Attacker端运行代码；4）user端运行dig xxx.example.com;5)查看缓存成功投毒；6）dig xxx.google.com不会再像没缓存的时候返回正确的值，而是会返回空A值，因为ns.attacker32.com中对于只有自己的和example.com的nameserver。

   b.实验关键

   1）只会缓存一个域名的NS记录，存在覆盖情况。

   2）选择包并构造NS记录时，保证NS记录的rrname为条件语句：ns_name in pkt[DNS].qd.qname 的ns_name的同样层级的域名，即ns_name=='example.com'时，rrname为 google.com。即保证，将所有包含与ns记录对应的域名的包都抓到并构造响应的欺骗包。

   c.从task4中获取的经验，可以将前面task关于ns部分的代码进一步改进。注：前面没有用到ns记录的代码中关于该部分的没有做详细编写，即没有与实际对应，不影响使用。

Task 5: Spoofing Records in the Additional Section

1. 按照要求修改攻击代码task5.py构造部分如下：
   

2. 清除缓存，Attacker运行代码，user端 dig www.example.com。

   可以看到发包的资源记录部分是与预想的一致。

3. ，local dns server dump缓存（见task2 3.)，缓存结果如下：
   

   1） ns记录都显示了，没有附加记录在缓存中

   2） 可以看到，因为ns.attacker32.com在local dns server中原本就有设置（见环境配置dns配置与测试部署部分），所以并没有被我们构造的Additional Section部分ip:1.2.3.4影响。注释掉Additional Section部分的ns.attacker32.com,缓存结果仍然与上述相同：
   

   task4的4.情况下，会出现‘；additional ns.attacker32.com’的cache(见task4 4图)。是因为ns记录被覆盖只剩google.com的，没有ns.attacker32.com的，故该additional 记录存在。而我们这次ns记录存在ns.attacker32.com的。也确实ns.example.com没有被使用，参考了ns记录的ns.attacker32.com的，所以www.example.com才会是1.2.3.5（见该服务器对应zone)。

   3）如果将addsec2 ns.example.net改成ns.example.com，查询返回A记录是空值。从缓存结果图中看到，ns.example.com在ns.attacker32.com前面，于是转向使用它的内容，而该服务器在additional记录中被定义为5.6.7.8，找不到而没有返回。可以推断，符合要求的additional section有参考到的，没有在缓存中显示。

   4） 超出域的附加记录会直接被丢弃，即代码中对应第二第三条附加记录都没有录入到cache中。

2.2 DNS_Remote

2.2.1 环境搭建

​ 具体过程与DNS_Local部分相同，不同的是主机有所变化，实验网络结构:

​ 主要欺骗目标为www.example.com,该域名真实ip为93.184.216.34，由ICANN管理。

2.2.2 The Attack Tasks

The Kaminsky Attack

​ 前述已经完成在同一LAN下的DNS攻击，在同一个LAN下是可以直接看到query包。远程攻击缓存投毒的困难主要在于，响应包的事务id必须与请求包相匹配，而请求包的id通常是随机生成的，不在同一子网无法捕捉包看id，而自己暴力手段猜测id会败在缓存机制下，因为当我们成功之前，正确包已经到达被缓存，在time out 之前，dns server不会再向外查询。

​ Kaminsky提出的方案（主动构造对应域名的requests，同时大量不同id响应包响应dns server的请求以欺骗完成缓存中毒攻击）：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Sjq00KT6-1637420403002)(C:\Users\34860\AppData\Roaming\Typora\typora-user-images\image-20211119184255268.png)]

Task 2: Construct DNS request

1. 如下伪造从user端发送dns查询给local dns server，最终目的为让local dns server向其他dns server发起dns 查询。

   因此查询字段为xx.example.com,且不在缓存中，task2.py：
   

2. 经wirshark抓包可以看到，local dns server 10.9.0.53向别的dns server发起查询。

Task 3: Spoof DNS Replies

1. 编写欺骗程序，目的是向local dns server返回xxx.example.com的response，并欺骗其ns为攻击者的。代码task3.py如下：
   

   其中，ns为攻击者的dns server，目标ip为local dns server的，源端口为53,我们需要伪造真正example.com给local dns server的response，因此，src ip为某example.com权威域名服务器的。而在实验环境配置时，我们已经将local dns server的源端口号固定为33333，因此dport =33333。以下为dig example.com ns查到的多个权威域名服务器的name server(2 个)以及ip：
   

2. 通过wireshark抓包看到我们的response成功到达local dns server：
   

Task 4: Launch the Kaminsky Attack

1. 使用scapy生成构造dns请求包，代码gen_dns_request.py，将包保存到ip_req.bin

2. 使用scapy构造dns回复包(具体思路见task3），代码gen_dns_response.py，将包保存到ip_resp.bin

3. 使用socket发送请求与响应包实施攻击

   编写代码attack.c：

   a.读取包：

   b.随机化example.com的子域名，发送请求包的同时，构造大量id响应包：

   ​ 伪装权威域名第二个nameserver：

   c.函数：随机化函数与原始套接字发送

4. 查看缓存，确认成功：

Task 5: Result Verification

1. 向local dns server(已经被缓存)发起查询，在dig之前启动wireshark抓包：

2. 直接向attacker的dns server发起dig查询：
   

3. 对比1.2.结果，完全一致，即都是在ns.attacker32.com里设置的example.com zone规则，www.example.com为1.2.3.5.

4. 抓包观察

   以下为第一次dig(1.)的抓包结果，可以看到10.9.0.5向10.9.0.53即local dns server发起查询，local dns server继而向10.9.0.153发起查询，而10.9.0.153为ns.attacker32.com的ip，最后该dns server返回www.example.com的A记录结果。因此我们可以判断攻击是成功的。
   
   不仅是dns请求，arp请求也只有10.9.0.153的，即没有向其他dns server发起query，缓存中已有10.9.0.153：
   
   验证一下第二次dig（2.）的抓包：
   
   二者路径一致。

3. 总结

​ 实验顺利完成，即本地LAN与远程dns攻击两部分都完成。对dns欺骗有了更深刻的认知，对缓存投毒手段在实践中了解的更透彻。同一LAN中，可以通过抓包看见dns包进而实施欺骗，而远程没有这个优势，在id匹配方面是不小的挑战，实验通过Kaminsky方法完成了远程dns攻击。在实际情况下，除了id的随机化，还有dns server源端口变化与DNSSEC机制应对的挑战留待解决。