Hello，嗨，大家好，我是哈喽猿。
这里是哈喽猿网
今天推送的是网络安全【kalinux】的文章，感谢您宝贵的时间阅读
DNS信息收集
从本节开始，咱们从头开始，体系的学习依据Kali Linux的web运用渗透测试。 本章主要目标是从各个角度收集测试目标的基本信息，包含收集信息的途径、各种工具的运用方法，以及简单的示例。 依照循序渐进的准则，第一节讲解怎么收集DNS信息。对于工具的运用，我这里不计划把运用说明再搬到这里，意义不大。读者希望google就能够了。 如果您对DNS的工作原理不是很了解，我建议您先在网上或许书籍上查阅相关资料。本节也对相关概念做了简单诠释，作为学习的辅助。 关于DNS（参考：http://zh.wikipedia.org/zh-cn/域名系统；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/域名服務器記錄類型列表
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服务器，许多公司都会有自己的域名服务器，这些服务器能够成为浸透测验过程中的一个突破点。
域名基本信息查询
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记录，从而可以得到邮件服务器信息。
域名枚举
在得到主域名信息之后，如果能通过主域名得到所有子域名信息，在通过子域名查询其对应的主机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条
示例：
反向地址解析
（参考：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的查询结果为：
所以想要获得完整的信息，可以多尝试不同的工具，整合结果。很多工具无法做反向查询的原因，在于域名所有者没有添加反向解析记录。
关于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记载类型有几十种，我这儿仅仅列出我认为重要的信息，期望读者能检查我给出的链接。
0 评论