Kali Linux滲透 DNS信息收集

@@@
時(shí)間 2013-12-24 14:50:00
** 博客園-原創(chuàng)精華區(qū)
原文 http://www.cnblogs.com/xuanhun/p/3489038.html

此文為轉(zhuǎn)載學(xué)習(xí)

從本節(jié)開始澡刹,我們從頭開始件豌,系統(tǒng)的學(xué)習(xí)基于 Kali Linux 的 web 應(yīng)用滲透測試宅荤。
本章主要目標(biāo)是從各個(gè)角度搜集測試目標(biāo)的基本信息,包括搜集信息的途徑着裹、各種工具的使用方法,以及簡單的示例。
按照循序漸進(jìn)的原則问畅,第一節(jié)講解如何搜集 DNS 信息艾栋。對(duì)于工具的使用爆存,我這里不打算把使用說明再搬到這里,意義不大蝗砾。讀者希望 google 就可以了先较。
如果您對(duì) DNS 的工作原理不是很了解,我建議您先在網(wǎng)上或者書籍上查閱相關(guān)資料悼粮。本節(jié)也對(duì)相關(guān)概念做了簡單詮釋闲勺,作為學(xué)習(xí)的輔助。
關(guān)于 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 ):
域名系統(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í)域名長度的限制是 63 個(gè)字符勺远,域名總長度則不能超過 253 個(gè)字符。
DNS 命名用于 Internet 等 TCP/IP 網(wǎng)絡(luò)中时鸵,通過用戶友好的名稱查找計(jì)算機(jī)和服務(wù)胶逢。當(dāng)用戶在應(yīng)用程序中輸入 DNS 名稱時(shí), DNS 服務(wù)可以將此名稱解析為與之相關(guān)的其他信息饰潜,如 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ù)器之間的簡單 DNS 查詢。實(shí)際上史煎, DNS 查詢要復(fù)雜得多谦屑,包含此處未顯示的許多其他步驟。
當(dāng) DNS 客戶端需要查詢程序中使用的名稱時(shí)篇梭,它會(huì)查詢 DNS 服務(wù)器來解析該名稱氢橙。客戶端發(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 客戶端服務(wù)程序進(jìn)行解析鸵荠。
  • 不能在本地解析查詢時(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 定義,用于定義提供特定服務(wù)的服務(wù)器的位置牵舱,如主機(jī) (hostname) 串绩,端口 (port number) 等。
    NAPTR 記錄 : RFC 3403 定義芜壁,它提供了正則表達(dá)式方式去映射一個(gè)域名礁凡。 NAPTR 記錄非常著名的一個(gè)應(yīng)用是用于 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 (域名數(shù)據(jù)庫查詢)
    一個(gè)域名的所有者可以通過查詢 WHOIS 數(shù)據(jù)庫而被找到慧妄;對(duì)于大多數(shù)根域名服務(wù)器顷牌, 基本的 WHOIS 由 ICANN 維護(hù),而 WHOIS 的細(xì)節(jié)則由控制那個(gè)域的域注冊(cè)機(jī)構(gòu)維護(hù)塞淹。
    對(duì)于 240 多個(gè)國家代碼頂級(jí)域名 (ccTLDs) 窟蓝,通常由該域名權(quán)威注冊(cè)機(jī)構(gòu)負(fù)責(zé)維護(hù) WHOIS 。例如中國互聯(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ì)于測試個(gè)人站點(diǎn)非常有用,因?yàn)槲覀兛梢酝ㄟ^搜索引擎关划,社交網(wǎng)絡(luò)小染,挖掘出很多域名所有人的信息。而對(duì)于小站點(diǎn)而言贮折,域名所有人往往就是管理員裤翩。
    對(duì)于大型站點(diǎn),我們更關(guān)心 DNS 服務(wù)器调榄,很多公司都會(huì)有自己的域名服務(wù)器踊赠,這些服務(wù)器可以成為滲透測試過程中的一個(gè)突破點(diǎn)。
    除了 whois 查詢之外每庆,我們還可以通過 host 命令來查詢 dns 服務(wù)器筐带,命令格式為:
    如下圖:

    通過“ host –t ns mbdongbo.com” 得到該域名的兩個(gè)服務(wù)器為 ns12.xincache.com , ns11.xincache.com 缤灵。
    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ù)器帖鸦。
    通過
    可以查詢 a 記錄

    MX 記錄也叫做郵件路由記錄,用戶可以將該域名下的郵件服務(wù)器指向到自己的 mail server 上胚嘲,然后即可自行操控所有的郵箱設(shè)置作儿。您只需在線填寫您服務(wù)器的 IP 地址,即可將您域名下的郵件全部轉(zhuǎn)到您自己設(shè)定相應(yīng)的郵件服務(wù)器上馋劈。
    簡單的說攻锰,通過操作 MX 記錄,您才可以得到以您域名結(jié)尾的郵局妓雾。
    通過
    可以查詢?cè)撚蛎碌? mx 記錄娶吞,從而可以得到郵件服務(wù)器信息。

    在得到主域名信息之后君珠,如果能通過主域名得到所有子域名信息寝志,在通過子域名查詢其對(duì)應(yīng)的主機(jī) IP 娇斑,這樣我們能得到一個(gè)較為完整的信息策添。
    使用 fierse 工具,可以進(jìn)行域名列表查詢:
    fierce -dns domainName

    如上圖毫缆,通過 fierse 唯竹,成功枚舉出某域名下的子域名列表。
    關(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 使用你提供的一個(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ù)器中來阻攔垃圾郵件攀唯,特別是在國外。多數(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è)測試咖城,都沒有得到想要的結(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 探測工具,都會(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 工具可以檢測 dns 區(qū)域傳送漏洞,語法如下:
    dig axfr @ 域名服務(wù)器 被檢測域名
    示例:
    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)
    小結(jié)
    運(yùn)用 DNS 信息探測亚茬,結(jié)合社會(huì)工程方法酪耳,我們可以得到關(guān)于網(wǎng)站擁有者、服務(wù)器基本組織結(jié)構(gòu)等方面的信息刹缝。
    我故意淡化了各種工具的詳細(xì)使用方法葡兑,因?yàn)槿绻衙糠N工具都詳細(xì)的羅列出來篇幅過長,同時(shí)也沒這個(gè)必要赞草,讀者可以很方便的在網(wǎng)絡(luò)上找到每種工具的使用手冊(cè)讹堤。
    DNS 記錄類型有幾十種,我這里只是列出我認(rèn)為重要的信息厨疙,希望讀者能查看我給出的鏈接洲守。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市沾凄,隨后出現(xiàn)的幾起案子梗醇,更是在濱河造成了極大的恐慌,老刑警劉巖撒蟀,帶你破解...
    沈念sama閱讀 206,126評(píng)論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件叙谨,死亡現(xiàn)場離奇詭異,居然都是意外死亡保屯,警方通過查閱死者的電腦和手機(jī)手负,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,254評(píng)論 2 382
  • 文/潘曉璐 我一進(jìn)店門涤垫,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人竟终,你說我怎么就攤上這事蝠猬。” “怎么了统捶?”我有些...
    開封第一講書人閱讀 152,445評(píng)論 0 341
  • 文/不壞的土叔 我叫張陵榆芦,是天一觀的道長。 經(jīng)常有香客問我喘鸟,道長匆绣,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,185評(píng)論 1 278
  • 正文 為了忘掉前任什黑,我火速辦了婚禮犬绒,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘兑凿。我一直安慰自己凯力,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 64,178評(píng)論 5 371
  • 文/花漫 我一把揭開白布礼华。 她就那樣靜靜地躺著咐鹤,像睡著了一般。 火紅的嫁衣襯著肌膚如雪圣絮。 梳的紋絲不亂的頭發(fā)上祈惶,一...
    開封第一講書人閱讀 48,970評(píng)論 1 284
  • 那天,我揣著相機(jī)與錄音扮匠,去河邊找鬼捧请。 笑死,一個(gè)胖子當(dāng)著我的面吹牛棒搜,可吹牛的內(nèi)容都是我干的疹蛉。 我是一名探鬼主播,決...
    沈念sama閱讀 38,276評(píng)論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼力麸,長吁一口氣:“原來是場噩夢(mèng)啊……” “哼可款!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起克蚂,我...
    開封第一講書人閱讀 36,927評(píng)論 0 259
  • 序言:老撾萬榮一對(duì)情侶失蹤闺鲸,失蹤者是張志新(化名)和其女友劉穎,沒想到半個(gè)月后埃叭,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體摸恍,經(jīng)...
    沈念sama閱讀 43,400評(píng)論 1 300
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 35,883評(píng)論 2 323
  • 正文 我和宋清朗相戀三年赤屋,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了立镶。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片壁袄。...
    茶點(diǎn)故事閱讀 37,997評(píng)論 1 333
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖谜慌,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情莺奔,我是刑警寧澤欣范,帶...
    沈念sama閱讀 33,646評(píng)論 4 322
  • 正文 年R本政府宣布,位于F島的核電站令哟,受9級(jí)特大地震影響恼琼,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜屏富,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 39,213評(píng)論 3 307
  • 文/蒙蒙 一晴竞、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧狠半,春花似錦噩死、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,204評(píng)論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至已日,卻和暖如春垛耳,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背飘千。 一陣腳步聲響...
    開封第一講書人閱讀 31,423評(píng)論 1 260
  • 我被黑心中介騙來泰國打工堂鲜, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人护奈。 一個(gè)月前我還...
    沈念sama閱讀 45,423評(píng)論 2 352
  • 正文 我出身青樓缔莲,卻偏偏與公主長得像,于是被迫代替她去往敵國和親霉旗。 傳聞我的和親對(duì)象是個(gè)殘疾皇子酌予,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 42,722評(píng)論 2 345

推薦閱讀更多精彩內(nèi)容

  • 1. 概述 在網(wǎng)絡(luò)環(huán)境中一般用戶只需要在瀏覽器中輸入url如www.sunny.com就可以到對(duì)應(yīng)服務(wù)器獲取相應(yīng)的...
    ghbsunny閱讀 2,865評(píng)論 0 7
  • 14.1 引言 域名系統(tǒng)(DNS)是一種用于TCP/IP應(yīng)用程序的分布式數(shù)據(jù)庫,它提供主機(jī)名字和IP地址之間的轉(zhuǎn)換...
    張芳濤閱讀 1,874評(píng)論 0 8
  • 什么是DNS及功能: DNS(Domain name server),是將IP地址轉(zhuǎn)換為域名地址奖慌。當(dāng)在互聯(lián)網(wǎng)訪問外...
    魏鎮(zhèn)坪閱讀 7,626評(píng)論 0 8
  • 目錄: 一些基本概念主機(jī)名DNS名稱解析DNS 解析的后端存儲(chǔ)名稱解析總結(jié) 大規(guī)模域名解析的體系架構(gòu)DNS 解析需...
    C86guli閱讀 12,477評(píng)論 3 34
  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具(例如配置管理抛虫,服務(wù)發(fā)現(xiàn),斷路器简僧,智...
    卡卡羅2017閱讀 134,599評(píng)論 18 139