@@@
時間 2013-12-24 14:50:00
** 博客園-原創精華區
原文 http://www.cnblogs.com/xuanhun/p/3489038.html

此文為轉載學習

從本節開始，我們從頭開始，系統的學習基于 Kali Linux 的 web 應用滲透測試。
本章主要目標是從各個角度搜集測試目標的基本信息，包括搜集信息的途徑、各種工具的使用方法，以及簡單的示例。
按照循序漸進的原則，第一節講解如何搜集 DNS 信息。對于工具的使用，我這里不打算把使用說明再搬到這里，意義不大。讀者希望 google 就可以了。
如果您對 DNS 的工作原理不是很了解，我建議您先在網上或者書籍上查閱相關資料。本節也對相關概念做了簡單詮釋，作為學習的輔助。
關于 DNS （參考： http://zh.wikipedia.org/zh-cn/%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F ；
http://man.ddvip.com/linux/debian/bin9/bind9-conf-2.html ）：
域名系統（英文： Domain Name System ， DNS ）是因特網的一項服務，它作為將域名和 IP 地址相互映射的一個分布式數據庫，能夠使人更方便的訪問互聯網。 DNS 使用 TCP 和 UDP 端口 53 。當前，對于每一級域名長度的限制是 63 個字符，域名總長度則不能超過 253 個字符。
DNS 命名用于 Internet 等 TCP/IP 網絡中，通過用戶友好的名稱查找計算機和服務。當用戶在應用程序中輸入 DNS 名稱時， DNS 服務可以將此名稱解析為與之相關的其他信息，如 IP 地址。
例如，多數用戶喜歡使用友好的名稱（如 debian.linuxsir.org ）來查找計算機，如網絡上的郵件服務器或 Web 服務器。友好名稱更容易了解和記住。但是，計算機使用數字地址在網絡上進行通訊。為更容易地使用網絡資源， DNS 等命名系統提供了一種方法，將計算機或服務的用戶友好名稱映射為數字地址。
下圖顯示了 DNS 的基本用途，即根據計算機名稱查找其 IP 地址。

• 指定的 DNS 域名，規定為完全合格的域名 (FQDN)
• 指定的查詢類型，可根據類型指定資源記錄，或者指定查詢操作的專用類型。
• DNS 域名的指定類別。
  例如，指定的名稱可為計算機的 FQDN ，如 Debian.linuxsir.org ，并且指定的查詢類型用于通過該名稱搜索地址 (A) 資源記錄。將 DNS 查詢看作客戶端向服務器詢問由兩部分組成的問題，如“您是否擁有名為‘ Debian.linuxsir.org’ 的計算機的 A 資源記錄？”當客戶端收到來自服務器的應答時，它將讀取并解釋應答的 A 資源記錄，獲取根據名稱詢問的計算機的 IP 地址。
  DNS 查詢以各種不同的方式進行解析。有時，客戶端也可使用從先前的查詢獲得的緩存信息在本地應答查詢。 DNS 服務器可使用其自身的資源記錄信息緩存來應答查詢。 DNS 服務器也可代表請求客戶端查詢或聯系其他 DNS 服務器，以便完全解析該名稱，并隨后將應答返回至客戶端。這個過程稱為遞歸。
  另外，客戶端自己也可嘗試聯系其他的 DNS 服務器來解析名稱。當客戶端執行此操作時，它會根據來自服務器的參考答案，使用其他的獨立查詢。這個過程稱為迭代。
  總之， DNS 查詢進程分兩部分進行：
• 名稱查詢從客戶端計算機開始，并傳輸至解析程序即 DNS 客戶端服務程序進行解析。
• 不能在本地解析查詢時，可根據需要查詢 DNS 服務器來解析名稱。
  記錄類型
  主條目：域名服務器記錄類型列表
  DNS 系統中，常見的資源記錄類型有：
  主機記錄 (A 記錄 ) ： RFC 1035 定義， A 記錄是用于名稱解析的重要記錄，它將特定的主機名映射到對應主機的 IP 地址上。
  別名記錄 (CNAME 記錄 ): RFC 1035 定義， CNAME 記錄用于將某個別名指向到某個 A 記錄上，這樣就不需要再為某個新名字另外創建一條新的 A 記錄。
  IPv6 主機語錄 (AAAA 記錄 ): RFC 3596 定義，與 A 記錄對應，用于將特定的主機名映射到一個主機的 IPv6 地址。
  服務位置記錄 (SRV 記錄 ): RFC 2782 定義，用于定義提供特定服務的服務器的位置，如主機 (hostname) ，端口 (port number) 等。
  NAPTR 記錄 : RFC 3403 定義，它提供了正則表達式方式去映射一個域名。 NAPTR 記錄非常著名的一個應用是用于 ENUM 查詢。
  完整的記錄類型列表參考： http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E6%9C%8D%E5%8B%99%E5%99%A8%E8%A8%98%E9%8C%84%E9%A1%9E%E5%9E%8B%E5%88%97%E8%A1%A8
  WHOIS （域名數據庫查詢）
  一個域名的所有者可以通過查詢 WHOIS 數據庫而被找到；對于大多數根域名服務器， 基本的 WHOIS 由 ICANN 維護，而 WHOIS 的細節則由控制那個域的域注冊機構維護。
  對于 240 多個國家代碼頂級域名 (ccTLDs) ，通常由該域名權威注冊機構負責維護 WHOIS 。例如中國互聯網絡信息中心 (China Internet Network Information Center) 負責 .CN 域名的 WHOIS 維護，香港互聯網注冊管理有限公司 (Hong Kong Internet Registration Corporation Limited) 負責 .HK 域名的 WHOIS 維護，臺灣網絡信息中心 (Taiwan Network Information Center) 負責 .TW 域名的 WHOIS 維護。
  提供 whois 查詢的站點很多 google“whois” ，你可以得到這些站點。
  
  
  
  另外所有的域名提供商都提供 whois 信息查詢。比如在萬網查詢“ iprezi.cn” ，會得到如下信息：
  
  
  
  在 whois 查詢中，注冊人姓名和郵箱信息，通常對于測試個人站點非常有用，因為我們可以通過搜索引擎，社交網絡，挖掘出很多域名所有人的信息。而對于小站點而言，域名所有人往往就是管理員。
  對于大型站點，我們更關心 DNS 服務器，很多公司都會有自己的域名服務器，這些服務器可以成為滲透測試過程中的一個突破點。
  除了 whois 查詢之外，我們還可以通過 host 命令來查詢 dns 服務器，命令格式為：
  如下圖：
  
  
  
  通過“ host –t ns mbdongbo.com” 得到該域名的兩個服務器為 ns12.xincache.com ， ns11.xincache.com 。
  A (Address) 記錄是用來指定主機名（或域名）對應的 IP 地址記錄。用戶可以將該域名下的網站服務器指向到自己的 web server 上。同時也可以設置您域名的子域名。通俗來說 A 記錄就是服務器的 IP, 域名綁定 A 記錄就是告訴 DNS, 當你輸入域名的時候給你引導向設置在 DNS 的 A 記錄所對應的服務器。
  通過
  可以查詢 a 記錄
  
  
  
  MX 記錄也叫做郵件路由記錄，用戶可以將該域名下的郵件服務器指向到自己的 mail server 上，然后即可自行操控所有的郵箱設置。您只需在線填寫您服務器的 IP 地址，即可將您域名下的郵件全部轉到您自己設定相應的郵件服務器上。
  簡單的說，通過操作 MX 記錄，您才可以得到以您域名結尾的郵局。
  通過
  可以查詢該域名下的 mx 記錄，從而可以得到郵件服務器信息。
  
  
  
  在得到主域名信息之后，如果能通過主域名得到所有子域名信息，在通過子域名查詢其對應的主機 IP ，這樣我們能得到一個較為完整的信息。
  使用 fierse 工具，可以進行域名列表查詢：
  fierce -dns domainName
  
  
  
  如上圖，通過 fierse ，成功枚舉出某域名下的子域名列表。
  關于 fierse 的工作原理，可以查看： http://ha.ckers.org/fierce/ 。
  除 fierse 之外， dnsdict6 、 dnsenum 、 dnsmap 都可以進行域名枚舉，需要說明的是，每個工具返回的結果并不相同，而且有的工具還有錯誤，讀者進行 dns 信息搜集的時候，要盡量使用不同的工具，盡可能得到完整的信息。 dnsdict6 、 dnsenum 、 dnsmap 進行枚舉的時候都是使用字典，進行掃描，這里以 dnsdict6 為例。
  dnsdict6 使用你提供的一個字典或者內置的列表來枚舉，基于 dnsmap 。
  使用語法：
  dnsdict6 [-d46] [-s|-m|-l|-x] [-t 線程 ] [-D] 域名 [ 字典路徑 ]
  參數說明 :
  -4 顯示 ipv4
  -t 指定要使用的線程 默認： 8 最大 :32
  -D ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝［只顯示字典不掃描］＝＝＝＝
  -d 顯示在 DNS 服務器上的 NS （一種服務記錄類型） MX （郵件服務器） ipv6 的域名信息
  － [smlx] 選擇字典大?。蹆戎玫? ] -s 小型是 50 條 － m 中等是 796 條 [ 默認 ] -l 大型 1416 條 － x 最大 3211 條
  示例：
  
  
  
  2.1.4 反向地址解析
  （參考： http://blog.csdn.net/jackxinxu2100/article/details/8145318 ）
  我們經常使用到得 DNS 服務器里面有兩個區域，即“正向查找區域”和“反向查找區域”，正向查找區域就是我們通常所說的域名解析，反向查找區域即是這里所說的 IP 反向解析，它的作用就是通過查詢 IP 地址的 PTR 記錄來得到該 IP 地址指向的域名，當然，要成功得到域名就必需要有該 IP 地址的 PTR 記錄。 PTR 記錄是郵件交換記錄的一種，郵件交換記錄中有 A 記錄和 PTR 記錄， A 記錄解析名字到地址，而 PTR 記錄解析地址到名字。地址是指一個客戶端的 IP 地址，名字是指一個客戶的完全合格域名。通過對 PTR 記錄的查詢，達到反查的目的。
  反向域名解析系統 (Reverse DNS) 的功能確保適當的郵件交換記錄是生效的。反向域名解析與通常的正向域名解析相反，提供 IP 地址到域名的對應。 IP 反向解析主要應用到郵件服務器中來阻攔垃圾郵件，特別是在國外。多數垃圾郵件發送者使用動態分配或者沒有注冊域名的 IP 地址來發送垃圾郵件，以逃避追蹤，使用了域名反向解析后，就可以大大降低垃圾郵件的數量。
  比如你用 xxx@name.com 這個郵箱給我的郵箱 123@163.com 發了一封信。 163 郵件服務器接到這封信會查看這封信的信頭文件，這封信的信頭文件會顯示這封信是由哪個 IP 地址發出來的。然后根據這個 IP 地址進行反向解析，如果反向解析到這個 IP 所對應的域名是 name.com 那么就接受這封郵件，如果反向解析發現這個 IP 沒有對應到 name.com ，那么就拒絕這封郵件。
  由于在域名系統中，一個 IP 地址可以對應多個域名，因此從 IP 出發去找域名，理論上應該遍歷整個域名樹，但這在 Internet 上是不現實的。為了完成逆向域名解析，系統提供一個特別域，該特別域稱為逆向解析域 in-addr.arpa 。這樣欲解析的 IP 地址就會被表達成一種像域名一樣的可顯示串形式，后綴以逆向解析域域
  名 "in-addr.arpa" 結尾。
  例如一個 IP 地址： 222.211.233.244 ，其逆向域名表達方式為： 244.233.221.222.in-addr.arpa
  兩種表達方式中 IP 地址部分順序恰好相反，因為域名結構是自底向上 ( 從子域到域 ) ，而 IP 地址結構是自頂向下 ( 從網絡到主機 ) 的。實質上逆向域名解析是將 IP 地址表達成一個域名 , 以地址做為索引的域名空間 , 這樣逆向解析的很大部分可以納入正向解析中。
  linux 中常用的反向解析工具為 nslookup 和 dig 。
  使用 dig 進行反向解析的命令格式為：
  dig -x ip @dnsserver # 用 dig 查看反向解析
  其中 dnsserver 可以不用指定，默認會使用本機配置的域名服務器進行反向查詢。指定 dsn 服務器示例如下圖：
  
  
  
  不指定 dns 服務：
  
  
  
  但是實際情況并不是盡如人意，查找的服務器不同，得到的結果的完整度也不同，比如上圖的兩個測試，都沒有得到想要的結果。很多時候，我們到提供反向查詢的網站進行查找，可能效果會更好一點。
  下面是我在 http://dns.aizhan.com/ 的查詢結果：
  
  
  
  而在 www.lbase.net 的查詢結果為：
  
  
  
  所以想要獲得完整的信息，可以多嘗試不同的工具，整合結果。很多工具無法做反向查詢的原因，在于域名所有者沒有添加反向解析記錄。
  2.1.5 關于 DNS 區域傳送漏洞
  很多 dns 探測工具，都會首先嘗試 dns 區域傳送，然后才是暴力枚舉，那么什么是 DNS 區域傳送漏洞呢？
  區域傳送操作指的是一臺后備服務器使用來自主服務器的數據刷新自己的 zone 數據庫。這為運行中的 DNS 服務提供了一定的冗余度，其目的是為了防止主域名服務器因意外故障變得不可用時影響到全局。一般來說， DNS 區域傳送操作只在網絡里真的有后備域名 DNS 服務器時才有必要執行，但許多 DNS 服務器卻被錯誤地配置成只要有人發出請求，就會向對方提供一個 zone 數據庫的拷貝。如果所提供的信息只是與連到因特網上且具備有效主機名的系統相關，那么這種錯誤配置不一定是壞事，盡管這使得攻擊者發現潛在目標要容易得多。真正的問題發生在一個單位沒有使用公用 / 私用 DNS 機制來分割外部公用 DNS 信息和內部私用 DNS 信息的時候，此時內部主機名和 IP 地址都暴露給了攻擊者。把內部 IP 地址信息提供給因特網上不受信任的用戶，就像是把一個單位的內部網絡完整藍圖或導航圖奉送給了別人。
  
  
  
  使用 dig 工具可以檢測 dns 區域傳送漏洞，語法如下：
  dig axfr @ 域名服務器 被檢測域名
  示例：
  root@kali-xuanhun:~# dig @wormhole.movie.edu movie.edu axfr
  ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @wormhole.movie.edu movie.edu axfr
  ;; 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
  ;; 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)
  小結
  運用 DNS 信息探測，結合社會工程方法，我們可以得到關于網站擁有者、服務器基本組織結構等方面的信息。
  我故意淡化了各種工具的詳細使用方法，因為如果把每種工具都詳細的羅列出來篇幅過長，同時也沒這個必要，讀者可以很方便的在網絡上找到每種工具的使用手冊。
  DNS 記錄類型有幾十種，我這里只是列出我認為重要的信息，希望讀者能查看我給出的鏈接。