2.1 DNS信息收集從本節(jié)開始，我們從頭開始，系統(tǒng)的學(xué)習(xí)基于Kali Linux的web 應(yīng)用滲透測(cè)試。 本章主要目標(biāo)是從各個(gè)角度搜集測(cè)試目標(biāo)的基本信息，包括搜集信息的途徑、各種工具的使用方法，以及

2.1 DNS信息收集

從本節(jié)開始，我們從頭開始，系統(tǒng)的學(xué)習(xí)基于Kali Linux的web 應(yīng)用滲透測(cè)試。 本章主要目標(biāo)是從各個(gè)角度搜集測(cè)試目標(biāo)的基本信息，包括搜集信息的途徑、各種工具的使用方法，以及簡(jiǎn)單的示例。

按照循序漸進(jìn)的原則，第一節(jié)講解如何搜集DNS 信息。對(duì)于工具的使用，我這里不打算把使用說明再搬到這里，意義不大。讀者希望google 就可以了。

如果您對(duì)DNS 的工作原理不是很了解，我建議您先在網(wǎng)上或者書籍上查閱相關(guān)資料。本節(jié)也對(duì)相關(guān)概念做了簡(jiǎn)單詮釋，作為學(xué)習(xí)的輔助。

關(guān)于DNS （參考：

域名系統(tǒng)（英文：Domain Name System，DNS ）是因特網(wǎng)的一項(xiàng)服務(wù)，它作為將域名和IP 地址相互映射的一個(gè)分布式數(shù)據(jù)庫，能夠使人更方便的訪問互聯(lián)網(wǎng)。DNS 使用TCP 和UDP 端口53。當(dāng)前，對(duì)于每一級(jí)域名長(zhǎng)度的限制是63個(gè)字符，域名總長(zhǎng)度則不能超過253個(gè)字符。

DNS 命名用于 Internet 等 TCP/IP 網(wǎng)絡(luò)中，通過用戶友好的名稱查找計(jì)算機(jī)和服務(wù)。當(dāng)用戶在應(yīng)用程序中輸入 DNS 名稱時(shí)，DNS 如 IP 地址。

例如，多數(shù)用戶喜歡使用友好的名稱（如 debian.linuxsir.org ）來查找計(jì)算機(jī)，如網(wǎng)絡(luò)上的郵件服務(wù)器或 Web 服務(wù)器。友好名稱更容易了解和記住。但是，計(jì)算機(jī)使用數(shù)字地址在網(wǎng)絡(luò)上進(jìn)行通訊。為更容易地使用網(wǎng)絡(luò)資源，DNS 等命名系統(tǒng)提供了一種方法，將計(jì)算機(jī)或服務(wù)的用戶友好名稱映射為數(shù)字地址。

下圖顯示了 DNS 的基本用途，即根據(jù)計(jì)算機(jī)名稱查找其 IP 地址。

本例中，客戶端計(jì)算機(jī)查詢 DNS 服務(wù)器，要求獲得某臺(tái)計(jì)算機(jī)（Debian.linuxsir.org ）的 IP 地址。由于 DNS 服務(wù)器能夠根據(jù)其本地?cái)?shù)據(jù)庫應(yīng)答此查詢，因此，它將以包含所請(qǐng)求信息的應(yīng)答來回復(fù)客戶端，即一條主機(jī) (A) 資源記錄，其中含有 Debian.linuxsir.org 的IP 地址信息(211.93.98.20)。

此例顯示了單個(gè)客戶端與 DNS 服務(wù)器之間的簡(jiǎn)單 DNS 查詢。實(shí)際上，DNS 查詢要復(fù)雜得多，包含此處未顯示的許多其他步驟。

當(dāng) DNS 客戶端需要查詢程序中使用的名稱時(shí)，它會(huì)查詢 DNS 服務(wù)器來解析該名稱?？蛻舳税l(fā)送的每條查詢消息都包括三條信息，指定服務(wù)器回答的問題：

* 指定的 DNS 域名，規(guī)定為完全合格的域名 (FQDN)

* 指定的查詢類型，可根據(jù)類型指定資源記錄，或者指定查詢操作的專用類型。 * DNS 域名的指定類別。

例如，指定的名稱可為計(jì)算機(jī)的 FQDN ，如 Debian.linuxsir.org ，并且指定的查詢類型用于通過該名稱搜索地址 (A) 資源記錄。將DNS 查詢看作客戶端向服務(wù)器詢問由兩部分組成的問題，如“您是否擁有名為‘Debian.linuxsir.org’的計(jì)算機(jī)的 A 資源記錄？”當(dāng)客戶端收到來自服務(wù)器的應(yīng)答時(shí)，它將讀取并解釋應(yīng)答的 A 資源記錄，獲取根據(jù)名稱詢問的計(jì)算機(jī)的 IP 地址。

DNS 查詢以各種不同的方式進(jìn)行解析。有時(shí)，客戶端也可使用從先前的查詢獲得的緩存信息在本地應(yīng)答查詢。DNS 服務(wù)器可使用其自身的資源記錄信息緩存來應(yīng)答查詢。

DNS 服務(wù)器也可代表請(qǐng)求客戶端查詢或聯(lián)系其他 DNS 服務(wù)器，以便完全解析該名稱，并隨后將應(yīng)答返回至客戶端。這個(gè)過程稱為遞歸。

另外，客戶端自己也可嘗試聯(lián)系其他的 DNS 服務(wù)器來解析名稱。當(dāng)客戶端執(zhí)行此操作時(shí)，它會(huì)根據(jù)來自服務(wù)器的參考答案，使用其他的獨(dú)立查詢。這個(gè)過程稱為迭代。

總之，DNS 查詢進(jìn)程分兩部分進(jìn)行：

* 名稱查詢從客戶端計(jì)算機(jī)開始，并傳輸至解析程序即 DNS * 不能在本地解析查詢時(shí)，可根據(jù)需要查詢 DNS 服務(wù)器來解析名稱。

記錄類型

主條目：域名服務(wù)器記錄類型列表

DNS 系統(tǒng)中，常見的資源記錄類型有：

主機(jī)記錄(A記錄) ：RFC 1035定義，A 記錄是用于名稱解析的重要記錄，它將特定的主機(jī)名映射到對(duì)應(yīng)主機(jī)的IP 地址上。

別名記錄(CNAME記錄): RFC 1035定義，CNAME 記錄用于將某個(gè)別名指向到某個(gè)A 記錄上，這樣就不需要再為某個(gè)新名字另外創(chuàng)建一條新的A 記錄。

IPv6主機(jī)語錄(AAAA記錄): RFC 3596定義，與A 記錄對(duì)應(yīng)，用于將特定的主機(jī)名映射到一個(gè)主機(jī)的IPv6地址。

服務(wù)位置記錄(SRV記錄): RFC 2782如主機(jī)(hostname)，端口(port number)等。

NAPTR 記錄: RFC 3403定義，它提供了正則表達(dá)式方式去映射一個(gè)域名。NAPTR 記錄非常著名的一個(gè)應(yīng)用是用于ENUM 查詢。

完整的記錄類型列表參考：dns 記錄類型

2.1.1 whois查詢

一個(gè)域名的所有者可以通過查詢WHOIS 數(shù)據(jù)庫而被找到；對(duì)于大多數(shù)根域名服務(wù)器，基本的WHOIS 由ICANN 維護(hù)，而WHOIS 的細(xì)節(jié)則由控制那個(gè)域的域注冊(cè)機(jī)構(gòu)維護(hù)。

對(duì)于240多個(gè)國(guó)家代碼頂級(jí)域名(ccTLDs)，通常由該域名權(quán)威注冊(cè)機(jī)構(gòu)負(fù)責(zé)維護(hù)WHOIS 。例如中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心(China Internet Network Information Center)負(fù)

責(zé) .CN 域名的WHOIS

維護(hù)，香港互聯(lián)網(wǎng)注冊(cè)管理有限公司

(Hong Kong Internet Registration Corporation Limited) 負(fù)責(zé) .HK 域名的WHOIS 維護(hù)，臺(tái)灣網(wǎng)絡(luò)信息中心 (Taiwan Network Information Center) 負(fù)責(zé) .TW 域名的WHOIS 維護(hù)。

提供whois 查詢的站點(diǎn)很多 google“whois”，你可以得到這些站點(diǎn)。

另外所有的域名提供商都提供whois 信息查詢。比如在萬網(wǎng)查詢“iprezi.cn”，會(huì)得到如下信息：

在whois 查詢中，注冊(cè)人姓名和郵箱信息，通常對(duì)于測(cè)試個(gè)人站點(diǎn)非常有用，因?yàn)槲覀兛梢酝ㄟ^搜索引擎，社交網(wǎng)絡(luò)，挖掘出很多域名所有人的信息。而對(duì)于小站點(diǎn)而言，域名所有人往往就是管理員。

對(duì)于大型站點(diǎn)，我們更關(guān)心DNS 服務(wù)器，很多公司都會(huì)有自己的域名服務(wù)器，這些服務(wù)器可以成為滲透測(cè)試過程中的一個(gè)突破點(diǎn)。

2.1.2 域名基本信息查詢

Dns 服務(wù)器查詢 除了

whois 查詢之外，我們還可以通過

host 命令來查詢

dns 服務(wù)器，命令格式為： host -t ns domainName

如下圖：

通過“host –t ns mbdongbo.com”得到該域名的兩個(gè)服務(wù)器為ns12.xincache.com ，ns11.xincache.com 。

a 記錄查詢

A (Address) 記錄是用來指定主機(jī)名（或域名）對(duì)應(yīng)的IP 地址記錄。用戶可以將該域名下的網(wǎng)站服務(wù)器指向到自己的web server上。同時(shí)也可以設(shè)置您域名的子域名。通俗來說A 記錄就是服務(wù)器的IP, 域名綁定A 記錄就是告訴DNS, 當(dāng)你輸入域名的時(shí)候給你引導(dǎo)向設(shè)置在DNS 的A 記錄所對(duì)應(yīng)的服務(wù)器。

通過

host -t a domainName

可以查詢a 記錄

mx 記錄查詢

MX 記錄也叫做郵件路由記錄，用戶可以將該域名下的郵件服務(wù)器指向到自己的mail server 上，然后即可自行操控所有的郵箱設(shè)置。您只需在線填寫您服務(wù)器的IP 地址，即可將您域名下的郵件全部轉(zhuǎn)到您自己設(shè)定相應(yīng)的郵件服務(wù)器上。

簡(jiǎn)單的說，通過操作MX 記錄，您才可以得到以您域名結(jié)尾的郵局。

通過

host -t mx domainName

可以查詢?cè)撚蛎碌膍x 記錄，從而可以得到郵件服務(wù)器信息。

2.1.3 域名枚舉

在得到主域名信息之后，如果能通過主域名得到所有子域名信息，在通過子域名查詢其對(duì)應(yīng)的主機(jī)IP ，這樣我們能得到一個(gè)較為完整的信息。

fierce

使用fierce 工具，可以進(jìn)行域名列表查詢：

fierce -dns domainName

如上圖，通過fierce ，成功枚舉出某域名下的子域名列表。

關(guān)于fierse 的工作原理，可以查看：http://ha.ckers.org/fierce/。

除fierse 之外，dnsdict6、dnsenum 、dnsmap 都可以進(jìn)行域名枚舉，需要說明的是，每個(gè)工具返回的結(jié)果并不相同，而且有的工具還有錯(cuò)誤，讀者進(jìn)行dns 信息搜集的時(shí)候，要盡量使用不同的工具，盡可能得到完整的信息。dnsdict6、dnsenum 、dnsmap 進(jìn)行枚舉的時(shí)候都是使用字典，進(jìn)行掃描，這里以dnsdict6為例。

dnsdict6

dnsdict6使用你提供的一個(gè)字典或者內(nèi)置的列表來枚舉，基于dnsmap 。

使用語法：

dnsdict6 [-d46] [-s|-m|-l|-x] [-t 線程] [-D] 域名 [字典路徑]

參數(shù)說明:

-4 顯示ipv4

-t 指定要使用的線程 默認(rèn)：8 最大:32

-D ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝［只顯示字典不掃描］＝＝＝＝

-d 顯示在DNS 服務(wù)器上的NS （一種服務(wù)記錄類型）MX （郵件服務(wù)器） ipv6 的域名信息

－[smlx] 選擇字典大?。蹆?nèi)置的] -s 小型是50條 －m 中等是796條[默認(rèn)] -l 大型1416條 －x 最大3211條

示例：

2.1.4 反向地址解析

（參考：http://blog.csdn.net/jackxinxu2100/article/details/8145318）

我們經(jīng)常使用到得DNS 服務(wù)器里面有兩個(gè)區(qū)域，即“正向查找區(qū)域”和“反向查找區(qū)域”，正向查找區(qū)域就是我們通常所說的域名解析，反向查找區(qū)域即是這里所說的IP 反向解析，它的作用就是通過查詢IP 地址的PTR 記錄來得到該IP 地址指向的域名，當(dāng)然，要成功得到域名就必需要有該IP 地址的PTR 記錄。PTR 記錄是郵件交換記錄的一種，郵件交換記錄中有A 記錄和PTR 記錄，A 記錄解析名字到地址，而PTR 記錄解析地址到名字。地址是指一個(gè)客戶端的IP 地址，名字是指一個(gè)客戶的完全合格域名。通過對(duì)PTR 記錄的查詢，達(dá)到反查的目的。

反向域名解析系統(tǒng)(Reverse DNS)的功能確保適當(dāng)?shù)泥]件交換記錄是生效的。反向域名解析與通常的正向域名解析相反，提供IP 地址到域名的對(duì)應(yīng)。IP 反向解析主要應(yīng)用到郵件服務(wù)器中來阻攔垃圾郵件，特別是在國(guó)外。多數(shù)垃圾郵件發(fā)送者使用動(dòng)態(tài)分配或者沒有注冊(cè)域名的IP 地址來發(fā)送垃圾郵件，以逃避追蹤，使用了域名反向解析后，就可以大大降低垃圾郵件的數(shù)量。

比如你用 xxx@name.com 這個(gè)郵箱給我的郵箱 123@163.com 發(fā)了一封信。163郵件服務(wù)器接到這封信會(huì)查看這封信的信頭文件，這封信的信頭文件會(huì)顯示這封信是由哪個(gè)IP 地址發(fā)出來的。然后根據(jù)這個(gè)IP 地址進(jìn)行反向解析，如果反向解析到這個(gè)IP 所對(duì)應(yīng)的域名是name.com 那么就接受這封郵件，如果反向解析發(fā)現(xiàn)這個(gè)IP 沒有對(duì)應(yīng)到name.com ，那么就拒絕這封郵件。

由于在域名系統(tǒng)中，一個(gè)IP 地址可以對(duì)應(yīng)多個(gè)域名，因此從IP 出發(fā)去找域名，理論上應(yīng)該遍歷整個(gè)域名樹，但這在Internet 上是不現(xiàn)實(shí)的。為了完成逆向域名解析，系統(tǒng)提供一個(gè)特別域，該特別域稱為逆向解析域in-addr.arpa 。這樣欲解析的IP 地址就會(huì)被表達(dá)成一種像域名一樣的可顯示串形式，后綴以逆向解析域域

名"in-addr.arpa" 結(jié)尾。

例如一個(gè)IP 地址：222.211.233.244，其逆向域名表達(dá)方式為：

244.233.221.222.in-addr.arpa

兩種表達(dá)方式中IP 地址部分順序恰好相反，因?yàn)橛蛎Y(jié)構(gòu)是自底向上(從子域到域) ，而IP 地址結(jié)構(gòu)是自頂向下(從網(wǎng)絡(luò)到主機(jī)) 的。實(shí)質(zhì)上逆向域名解析是將IP 地址表達(dá)成一個(gè)域名, 以地址做為索引的域名空間, 這樣逆向解析的很大部分可以納入正向解析中。

linux 中常用的反向解析工具為nslookup 和dig 。

使用dig 進(jìn)行反向解析的命令格式為：

dig -x ip @dnsserver #

用

dig 查看反向解析

其中dnsserver 可以不用指定，默認(rèn)會(huì)使用本機(jī)配置的域名服務(wù)器進(jìn)行反向查詢。指定dsn 服務(wù)器示例如下圖：

不指定dns 服務(wù)：

但是實(shí)際情況并不是盡如人意，查找的服務(wù)器不同，得到的結(jié)果的完整度也不同，比如上圖的兩個(gè)測(cè)試，都沒有得到想要的結(jié)果。很多時(shí)候，我們到提供反向查詢的網(wǎng)站進(jìn)行查找，可能效果會(huì)更好一點(diǎn)。

下面是我在http://dns.aizhan.com/的查詢結(jié)果：

而在www.lbase.net 的查詢結(jié)果為：

所以想要獲得完整的信息，可以多嘗試不同的工具，整合結(jié)果。很多工具無法做反向查詢的原因，在于域名所有者沒有添加反向解析記錄。

2.1.5 關(guān)于DNS

區(qū)域傳送漏洞

很多dns 探測(cè)工具，都會(huì)首先嘗試dns 區(qū)域傳送，然后才是暴力枚舉，那么什么是DNS 區(qū)域傳送漏洞呢？

區(qū)域傳送操作指的是一臺(tái)后備服務(wù)器使用來自主服務(wù)器的數(shù)據(jù)刷新自己的zone 數(shù)據(jù)庫。這為運(yùn)行中的DNS 服務(wù)提供了一定的冗余度，其目的是為了防止主域名服務(wù)器因意外故障變得不可用時(shí)影響到全局。一般來說，DNS 區(qū)域傳送操作只在網(wǎng)絡(luò)里真的有后備域名DNS 服務(wù)器時(shí)才有必要執(zhí)行，但許多DNS 服務(wù)器卻被錯(cuò)誤地配置成只要有人發(fā)出請(qǐng)求，就會(huì)向?qū)Ψ教峁┮粋€(gè)zone 數(shù)據(jù)庫的拷貝。如果所提供的信息只是與連到因特網(wǎng)上且具備有效主機(jī)名的系統(tǒng)相關(guān)，那么這種錯(cuò)誤配置不一定是壞事，盡管這使得攻擊者發(fā)現(xiàn)潛在目標(biāo)要容易得多。真正的問題發(fā)生在一個(gè)單位沒有使用公用/私用DNS 機(jī)制來分割外部公用DNS 信息和內(nèi)部私用DNS 信息的時(shí)候，此時(shí)內(nèi)部主機(jī)名和IP 地址都暴露給了攻擊者。把內(nèi)部IP 地址信息提供給因特網(wǎng)上不受信任的用戶，就像是把一個(gè)單位的內(nèi)部網(wǎng)絡(luò)完整藍(lán)圖或?qū)Ш綀D奉送給了別人。

使用dig 工具可以檢測(cè)dns 區(qū)域傳送漏洞，語法如下：

dig axfr @域名服務(wù)器 被檢測(cè)域名

示例：

root@kali-xuanhun:~# dig @wormhole.movie.edu movie.edu axfr

; <<>> DiG 9.8.4-rpz2 rl005.12-P1 <<>> @wormhole.movie.edu movie.edu axfr ; (1 server found)

;; global options: cmd

;; connection timed out; no servers could be reached

root@kali-xuanhun:~# dig axfr @ns12.zoneedit.com zonetransfer.me

; <<>> DiG 9.8.4-rpz2 rl005.12-P1 <<>> axfr @ns12.zoneedit.com zonetransfer.me ; (1 server found)

;; global options: cmd

zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com. 2013064418 2400 360 1209600 300

zonetransfer.me. 7200 IN NS ns16.zoneedit.com.

zonetransfer.me. 7200 IN NS ns12.zoneedit.com.

zonetransfer.me. 7200 IN A 217.147.180.162

zonetransfer.me. 7200 IN MX 0 ASPMX.L.GOOGLE.COM.

zonetransfer.me. 7200 IN MX 10 ALT1.ASPMX.L.GOOGLE.COM.

zonetransfer.me. 7200 IN MX 10 ALT2.ASPMX.L.GOOGLE.COM.

zonetransfer.me. 7200 IN MX 20 ASPMX2.GOOGLEMAIL.COM.

zonetransfer.me. 7200 IN MX 20 ASPMX3.GOOGLEMAIL.COM.

zonetransfer.me. 7200 IN MX 20 ASPMX4.GOOGLEMAIL.COM.

zonetransfer.me. 7200 IN MX 20 ASPMX5.GOOGLEMAIL.COM.

zonetransfer.me. 301 IN TXT "Remember to call or email Pippa on 44 123 4567890 or pippa@zonetransfer.me when making DNS changes"

zonetransfer.me. 301 IN TXT

"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"

testing.zonetransfer.me. 301 IN CNAME www.zonetransfer.me.

164.180.147.217.in-addr.arpa.zonetransfer.me. 7200 IN PTR www.zonetransfer.me. ipv6actnow.org.zonetransfer.me. 7200 IN AAAA 2001:67c:2e8:11::c100:1332

asfdbauthdns.zonetransfer.me. 7900 IN AFSDB 1 asfdbbox.zonetransfer.me.

office.zonetransfer.me. 7200 IN A 4.23.39.254

owa.zonetransfer.me. 7200 IN A 207.46.197.32

info.zonetransfer.me. 7200 IN TXT "ZoneTransfer.me service provided by Robin Wood - robin@digininja.org. See www.digininja.org/projects/zonetransferme.php for more information."

asfdbbox.zonetransfer.me. 7200 IN A 127.0.0.1

canberra_office.zonetransfer.me. 7200 IN A 202.14.81.230

asfdbvolume.zonetransfer.me. 7800 IN AFSDB 1 asfdbbox.zonetransfer.me.

email.zonetransfer.me. 2222 IN NAPTR 1 1 "" "E2U email" ""

email.zoneedit.com.zonetransfer.me.

dzc.zonetransfer.me. 7200 IN TXT "AbCdEfG"

dr.zonetransfer.me. 300 IN LOC 53 20 56.558 N 1 38 33.526 W 0.00m 1m 10000m 10m

rp.zonetransfer.me. 321 IN RP robin.zonetransfer.me.zonetransfer.me.

robinwood.zonetransfer.me.

sip.zonetransfer.me. 3333 IN NAPTR 2 3 "au" "E2U sip"

"!^.*$!sip:customer-service@zonetransfer.me!" .

alltcpportsopen.firewall.test.zonetransfer.me. 301 IN A 127.0.0.1

www.zonetransfer.me. 7200 IN A 217.147.180.162

staging.zonetransfer.me. 7200 IN CNAME www.sydneyoperahouse.com.

deadbeef.zonetransfer.me. 7201 IN AAAA dead:beaf::

robinwood.zonetransfer.me. 302 IN TXT "Robin Wood"

vpn.zonetransfer.me. 4000 IN A 174.36.59.154

_sip._tcp.zonetransfer.me. 14000 IN SRV 0 0 5060 www.zonetransfer.me.

dc_office.zonetransfer.me. 7200 IN A 143.228.181.132

zonetransfer.me. 7200 IN SOA ns16.zoneedit.com. soacontact.zoneedit.com.

2013064418 2400 360 1209600 300

;; Query time: 425 msec

;; SERVER: 209.62.64.46#53(209.62.64.46)

;; WHEN: Tue Dec 24 14:12:21 2013

;; XFR size: 37 records (messages 37, bytes 2673)

小結(jié)

運(yùn)用DNS 信息探測(cè)，結(jié)合社會(huì)工程方法，我們可以得到關(guān)于網(wǎng)站擁有者、服務(wù)器基本組織結(jié)構(gòu)等方面的信息。

我故意淡化了各種工具的詳細(xì)使用方法，因?yàn)槿绻衙糠N工具都詳細(xì)的羅列出來篇幅過長(zhǎng)，同時(shí)也沒這個(gè)必要，讀者可以很方便的在網(wǎng)絡(luò)上找到每種工具的使用手冊(cè)。

DNS 記錄類型有幾十種，我這里只是列出我認(rèn)為重要的信息，希望讀者能查看我給出的鏈接。