Kali Linux***测试实战 2.1 DNS信息收集

阅读量：5746 次

发布时间：2019-06-18

本文共 9372 字，大约阅读时间需要 31 分钟。

2.1 DNS信息收集

从本节开始，我们从头开始，系统的学习基于KaliLinux的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）：

域名系统（英文：DomainName System，DNS）是因特网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。DNS使用TCP和UDP端口53。当前，对于每一级域名长度的限制是63个字符，域名总长度则不能超过253个字符。

DNS 命名用于Internet 等TCP/IP 网络中，通过用户友好的名称查找计算机和服务。当用户在应用程序中输入DNS 名称时，DNS服务可以将此名称解析为与之相关的其他信息，如IP 地址。

例如，多数用户喜欢使用友好的名称（如debian.linuxsir.org）来查找计算机，如网络上的邮件服务器或Web服务器。友好名称更容易了解和记住。但是，计算机使用数字地址在网络上进行通讯。为更容易地使用网络资源，DNS等命名系统提供了一种方法，将计算机或服务的用户友好名称映射为数字地址。

下图显示了DNS 的基本用途，即根据计算机名称查找其IP 地址。

24144611-60e9201b63a64c4a9e387c8d67d347e

本例中，客户端计算机查询DNS 服务器，要求获得某台计算机（Debian.linuxsir.org）的IP 地址。由于DNS 服务器能够根据其本地数据库应答此查询，因此，它将以包含所请求信息的应答来回复客户端，即一条主机(A) 资源记录，其中含有Debian.linuxsir.org 的IP 地址信息(211.93.98.20)。

此例显示了单个客户端与DNS 服务器之间的简单DNS 查询。实际上，DNS查询要复杂得多，包含此处未显示的许多其他步骤。

当DNS 客户端需要查询程序中使用的名称时，它会查询DNS 服务器来解析该名称。客户端发送的每条查询消息都包括三条信息，指定服务器回答的问题：

* 指定的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记录)：RFC1035定义，A记录是用于名称解析的重要记录，它将特定的主机名映射到对应主机的IP地址上。

别名记录(CNAME记录):RFC 1035定义，CNAME记录用于将某个别名指向到某个A记录上，这样就不需要再为某个新名字另外创建一条新的A记录。

IPv6主机语录(AAAA记录):RFC 3596定义，与A记录对应，用于将特定的主机名映射到一个主机的IPv6地址。

服务位置记录(SRV记录):RFC 2782定义，用于定义提供特定服务的服务器的位置，如主机(hostname)，端口(portnumber)等。

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

2.1.1 whois查询

WHOIS（域名数据库查询）

一个域名的所有者可以通过查询WHOIS数据库而被找到；对于大多数根域名服务器，基本的WHOIS由ICANN维护，而WHOIS的细节则由控制那个域的域注册机构维护。

对于240多个国家代码顶级域名(ccTLDs)，通常由该域名权威注册机构负责维护WHOIS。例如中国互联网络信息中心(ChinaInternet Network Information Center)负责.CN 域名的WHOIS维护，香港互联网注册管理有限公司(HongKong Internet Registration Corporation Limited) 负责.HK 域名的WHOIS维护，台湾网络信息中心(Taiwan Network Information Center) 负责.TW 域名的WHOIS维护。

提供whois查询的站点很多google“whois”，你可以得到这些站点。

24144641-b371a268bfb84f1fa9a5b5ff81e7874

另外所有的域名提供商都提供whois信息查询。比如在万网查询“iprezi.cn”，会得到如下信息：

24144648-22538f2e86554ebcba3b40481b44069

在whois查询中，注册人姓名和邮箱信息，通常对于测试个人站点非常有用，因为我们可以通过搜索引擎，社交网络，挖掘出很多域名所有人的信息。而对于小站点而言，域名所有人往往就是管理员。

对于大型站点，我们更关心DNS服务器，很多公司都会有自己的域名服务器，这些服务器可以成为***测试过程中的一个突破点。

2.1.2 域名基本信息查询

Dns服务器查询

除了whois查询之外，我们还可以通过host命令来查询dns服务器，命令格式为：

host -t ns domainName

如下图：

24144657-57ed11910c1c488498e555fdb7c398e

通过“host–t ns mbdongbo.com”得到该域名的两个服务器为ns12.xincache.com，ns11.xincache.com。

a记录查询

A (Address)记录是用来指定主机名（或域名）对应的IP地址记录。用户可以将该域名下的网站服务器指向到自己的webserver上。同时也可以设置您域名的子域名。通俗来说A记录就是服务器的IP,域名绑定A记录就是告诉DNS,当你输入域名的时候给你引导向设置在DNS的A记录所对应的服务器。

通过

host -t a domainName

可以查询a记录

24144704-25406985c37c4316b36888ff0edbb39

mx记录查询

MX记录也叫做邮件路由记录，用户可以将该域名下的邮件服务器指向到自己的mailserver上，然后即可自行操控所有的邮箱设置。您只需在线填写您服务器的IP地址，即可将您域名下的邮件全部转到您自己设定相应的邮件服务器上。

　　简单的说，通过操作MX记录，您才可以得到以您域名结尾的邮局。

通过

host -t mx domainName

可以查询该域名下的mx记录，从而可以得到邮件服务器信息。

24144711-73ccc05cd3114f96860aacdadf300b5

2.1.3 域名枚举

在得到主域名信息之后，如果能通过主域名得到所有子域名信息，在通过子域名查询其对应的主机IP，这样我们能得到一个较为完整的信息。

fierse

使用fierse工具，可以进行域名列表查询：

fierce -dns domainName

24144718-37600fe3afaf4e378ea42aa7744b6d6

如上图，通过fierse，成功枚举出某域名下的子域名列表。

关于fierse的工作原理，可以查看：。

除fierse之外，dnsdict6、dnsenum、dnsmap都可以进行域名枚举，需要说明的是，每个工具返回的结果并不相同，而且有的工具还有错误，读者进行dns信息搜集的时候，要尽量使用不同的工具，尽可能得到完整的信息。dnsdict6、dnsenum、dnsmap进行枚举的时候都是使用字典，进行扫描，这里以dnsdict6为例。

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条

示例：

24144729-93c61077c79a4e75bcd984c91715d53

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记录的查询，达到反查的目的。

反向域名解析系统(ReverseDNS)的功能确保适当的邮件交换记录是生效的。反向域名解析与通常的正向域名解析相反，提供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服务器示例如下图：

24144741-e3055c3d425b4b458d9e08017dbdf8a

不指定dns服务：

24144750-87c95c3f1edc43f4acce67710bae389

但是实际情况并不是尽如人意，查找的服务器不同，得到的结果的完整度也不同，比如上图的两个测试，都没有得到想要的结果。很多时候，我们到提供反向查询的网站进行查找，可能效果会更好一点。

下面是我在http://dns.aizhan.com/的查询结果：

24144756-0ecf8cce5c7a4ded9fe7e73d98321ee

而在的查询结果为：

24144802-723d99f04ed142a38a569a7e909b362

所以想要获得完整的信息，可以多尝试不同的工具，整合结果。很多工具无法做反向查询的原因，在于域名所有者没有添加反向解析记录。

2.1.5关于DNS区域传送漏洞

很多dns探测工具，都会首先尝试dns区域传送，然后才是暴力枚举，那么什么是DNS区域传送漏洞呢？

区域传送操作指的是一台后备服务器使用来自主服务器的数据刷新自己的zone数据库。这为运行中的DNS服务提供了一定的冗余度，其目的是为了防止主域名服务器因意外故障变得不可用时影响到全局。一般来说，DNS区域传送操作只在网络里真的有后备域名DNS服务器时才有必要执行，但许多DNS服务器却被错误地配置成只要有人发出请求，就会向对方提供一个zone数据库的拷贝。如果所提供的信息只是与连到因特网上且具备有效主机名的系统相关，那么这种错误配置不一定是坏事，尽管这使得***者发现潜在目标要容易得多。真正的问题发生在一个单位没有使用公用/私用DNS机制来分割外部公用DNS信息和内部私用DNS信息的时候，此时内部主机名和IP地址都暴露给了***者。把内部IP地址信息提供给因特网上不受信任的用户，就像是把一个单位的内部网络完整蓝图或导航图奉送给了别人。

24144810-160dc23a97f645e6a45ee42d390f916

使用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

; (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.7200INSOAns16.zoneedit.com.soacontact.zoneedit.com. 2013064418 2400 360 1209600 300

zonetransfer.me.7200INNSns16.zoneedit.com.

zonetransfer.me.7200INNSns12.zoneedit.com.

zonetransfer.me.7200INA217.147.180.162

zonetransfer.me.7200INMX0 ASPMX.L.GOOGLE.COM.

zonetransfer.me.7200INMX10 ALT1.ASPMX.L.GOOGLE.COM.

zonetransfer.me.7200INMX10 ALT2.ASPMX.L.GOOGLE.COM.

zonetransfer.me.7200INMX20 ASPMX2.GOOGLEMAIL.COM.

zonetransfer.me.7200INMX20 ASPMX3.GOOGLEMAIL.COM.

zonetransfer.me.7200INMX20 ASPMX4.GOOGLEMAIL.COM.

zonetransfer.me.7200INMX20 ASPMX5.GOOGLEMAIL.COM.

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

zonetransfer.me.301INTXT"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"

testing.zonetransfer.me. 301INCNAMEwww.zonetransfer.me.

164.180.147.217.in-addr.arpa.zonetransfer.me. 7200 IN PTRwww.zonetransfer.me.

ipv6actnow.org.zonetransfer.me.7200INAAAA2001:67c:2e8:11::c100:1332

asfdbauthdns.zonetransfer.me. 7900 INAFSDB1asfdbbox.zonetransfer.me.

office.zonetransfer.me.7200INA4.23.39.254

owa.zonetransfer.me.7200INA207.46.197.32

info.zonetransfer.me.7200INTXT"ZoneTransfer.me serviceprovided by Robin Wood - robin@digininja.org. Seewww.digininja.org/projects/zonetransferme.php for more information."

asfdbbox.zonetransfer.me. 7200INA127.0.0.1

canberra_office.zonetransfer.me. 7200 IN A202.14.81.230

asfdbvolume.zonetransfer.me. 7800 INAFSDB1asfdbbox.zonetransfer.me.

email.zonetransfer.me.2222INNAPTR1 1 "" "E2U+email""" email.zoneedit.com.zonetransfer.me.

dzc.zonetransfer.me.7200INTXT"AbCdEfG"

dr.zonetransfer.me.300INLOC53 20 56.558 N 1 38 33.526 W 0.00m 1m10000m 10m

rp.zonetransfer.me.321INRProbin.zonetransfer.me.zonetransfer.me.robinwood.zonetransfer.me.

sip.zonetransfer.me.3333INNAPTR2 3 "au" "E2U+sip""!^.*$!sip:customer-service@zonetransfer.me!" .

alltcpportsopen.firewall.test.zonetransfer.me. 301 IN A127.0.0.1

www.zonetransfer.me.7200INA217.147.180.162

staging.zonetransfer.me. 7200INCNAMEwww.sydneyoperahouse.com.

deadbeef.zonetransfer.me. 7201INAAAAdead:beaf::