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

目录

2.1 DNS信息收集1

2.1.1 whois查询3

2.1.2 域名基本信息查询4

Dns服务器查询4

a记录查询4

mx记录查询5

2.1.3 域名枚举5

fierse 5

dnsdict6 6

2.1.4 反向地址解析7

2.1.5 关于DNS区域传送漏洞8

小结11

2.1 DNS信息收集

从本节开始，我们从头开始，系统的学习基于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 服务器，要求获得某台计算机（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记录)：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

2.1.1 whois查询

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服务器，很多公司都会有自己的域名服务器，这些服务器可以成为渗透测试过程中的一个突破点。

2.1.2 域名基本信息查询

Dns服务器查询

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

host -t ns domainName

如下图：

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

a记录查询

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

通过

host -t a domainName

可以查询a记录

mx记录查询

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

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

通过

host -t mx domainName

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

2.1.3 域名枚举

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

fierse

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

fierce -dns domainName

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

关于fierse的工作原理，可以查看：http://ha.ckers.org/fierce/。

除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条

示例：

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

; (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)

小结

运用DNS信息探测，结合社会工程方法，我们可以得到关于网站拥有者、服务器基本组织结构等方面的信息。

我故意淡化了各种工具的详细使用方法，因为如果把每种工具都详细的罗列出来篇幅过长，同时也没这个必要，读者可以很方便的在网络上找到每种工具的使用手册。

DNS记录类型有几十种，我这里只是列出我认为重要的信息，希望读者能查看我给出的链接。

2.2节--《操作系统指纹识别》。

更多相关文章  www.xuanhun521.com,原文链接

ps：对此文章或者安全、安全编程感兴趣的读者，可以加qq群：Hacking:303242737;Hacking-2群：147098303；Hacking-3群：31371755；hacking-4群:201891680;Hacking-5群：316885176