前言
想必有些朋友和我一样，想要弄清楚当使用浏览器访问一个站点时，究竟向那些站点发起了 HTTP 请求；站点的 HTTP 响应；这些站点的域名是否和 shell 终端输出的 socket 套接字IP地址对应得上；这些站点使用的域名，IP地址，物理地址，域名拥有者和IP地址拥有者之间的联系；系统当前是否存在恶意或非法的网络连接。。。等等。
本博文就是要以随手取得的开源工具，并且用一种可实际操作的标准化流程，来达到上述种种分析任务的目标。
这套工具集与流程，以及思路，适用于你想分析的任何对象（这里指站点），并且这里提出的方法仅作为抛砖引玉，最终目的是激发大家对相关技术的思考，研究出更好的调试，分析方法，从而彻底明白访问站点时发生的事情。
准备工具
firefox 或其它浏览器内建的 web开发者工具
（这里使用 firefox 的开发者工具，不使用 firebug 插件的原因是它的“网络”分析模块没有 firefox 内建的开发者工具来得“强大”）
我们主要通过它的“网络”模块，查看当访问一个站点时，浏览器向哪些 URL 并发的 HTTP 请求内容，以及站点的 HTTP 响应内容，然后在它的“查看器”模块中，定位引发浏览器请求其它 URL 的相应 HTML 标签
firefox 的 noscript 插件
需要额外安装，详见后文；
用于禁止或允许站点的脚本以及跨域脚本，可以阻止，拦截，以及净化恶意站点存在的各种类型跨站脚本；我们用它来分析加载一个站点的脚本前后的 socket 套接字 IP 地址列表，对比前后的差异
shell 命令行工具 dig
CentOS6.5 默认安装，可以通过 yum 或者 rpm ，或者官方网站更新到最新版；
作为 DNS 解析的本地客户端，向因特网上的 DNS 服务器发送解析请求；
我们利用它来将开发者工具“网络”模块列出的域名，与 shell 终端执行 netstat 输出的 socket 套接字的 IP 地址，对应起来；当然你也可以使用 nslookup ，甚至 windows 平台的 nslookup，不过它没有 dig 强大
APNIC（Asia-Pacific Network Information Centre，亚太互联网络信息中心） 的 whois 数据库查询页面
CNNIC（China Internet Network Information Center，中国互联网络信息中心） 的 whois 数据库查询页面
其它提供 whois 查询以及站点相关信息查询服务的站点
http://www.wmtips.com/tools/info/
上述这些站点用于查询对象的域名注册信息，IP地址注册信息，网络范围，网络块大小，物理地址，AS自治域号码（如果有申请）等等，对于深入理解站点的背景信息甚至网络拓扑至关重要。
接着，以我个人的博客首页 URL 地址为测试用例来介绍标准化的分析流程；在这之前，需要下载，安装 firefox 的 noscript 插件，官方下载地址：
参考如下截图：
确认已经安装并启用 noscript，以 firefox 访问
http://shayi1983.blog.51cto.com/
注意底部 noscript 的状态栏，左侧是当前页面允许或禁止的脚本和所有用于引入脚本的 HTML 标签数量统计；单击右侧选项可以单独允许或禁止当前页面引入的某个同域或跨域的脚本，
为了测试方便，我们将包括 shayi1983.blog.51cto.com 站点在内的所有站点引入的脚本全部拦截，然后刷新页面，并且打开一个 shell 终端，执行
netstat -antupeo 命令，查看打开的网络连接：
各位大牛可能都已经猜到接下来的流程了：使用 dig 工具，对上面9个广域网 IP 进行反向 DNS 解析，查询其对应的域名，并且结合 APNIC 与 CNNIC 的 whois 数据库查询，阐明这些域名与 shayi1983.blog.51cto.com 站点的（利益）关系；
先别着急，我们还没用到 firefox 开发者工具的“网络”模块，分析在访问
shayi1983.blog.51cto.com 站点时，浏览器都向哪些 URL 发起了 HTTP 请求，记下这些 URL 的“主机名”部分，利用 dig 对这些主机名进行正向 DNS 解析，将结果的 IP 地址与上面 9 个广域网 IP 进行验证，如果要进一步获取信息，再使用
whois 数据库。这就是整个分析调试的流程。
回到主题，我们整理汇总了在访问 shayi1983.blog.51cto.com 站点时，浏览器请求的所有站点列表，用 dig 对这个列表中的每个主机名进行 DNS 解析，将结果与 shell 的输出比对；对于你想分析的任何其它站点，这个方法都是适用的，注意， noscript 可以让你挖掘到更多的站点引用信息：
shayi1983.blog.51cto.com
blog.51cto.com
home.51cto.com
p_w_picpaths.51cto.com
img1.51cto.com
ucenter.51cto.com
log.51cto.com
ad.doubleclick.net
new.51cto.com
s3.51cto.com
d.agkn.com
v.admaster.com.cn这里要解释一下 ad.doubleclick.com , d.agkn.com , v.admaster.com.cn
这三个站点。根据开发者工具的网络模块显示，在访问 shayi1983.blog.51cto.com
的时候，浏览器都向这3个站点发起了 HTTP 请求，为什么我们用 noscript 禁用了所有脚本，竟然还有跨域请求？
问题出在前述的 noscript <iframe> 过滤漏洞（暂且这么称呼）；因为某种未知原因， noscript 没能过滤掉 <iframe> 引入的内容，导致浏览器向引入的目标站点，即 log.51cto.com ，发起 HTTP 请求；
而在开发工具中查看浏览器向这3个第三方站点发起的 HTTP 请求信息，其 “Referer”请求头的值，刚好就是 log.51cto.com ，意味着当 firefox 请求 log.51cto.com 的 pageview.php web 应用程序时，返回的 HTML 页面中，又引入了这3个站点的内容，并且 noscript 没能及时阻止，导致 firefox 访问这3个站点，对应的套接字 IP 地址可以在 shell 中验证；
同时这也验证了“木桶原理”这条安全业界准则，试想一下，如果这些第三方域，继续引入其它站点的内容，形成庞大的站点引用树，最终不可避免的将会引入恶意站点的 javascript 脚本，导致用户 cookie 劫持，个人信息被窃，下载网页***等严重后果。
在这个场景中，noscript 安全功能强大，但是其 <iframe> 过滤漏洞，恰恰成了最短的那块木板。
下面就是整个 DNS 查询的结果，过程比较枯燥，但是对于一些知识点和需要重视的地方，还是会在截图中注明：
看到这里，如果你已经觉得头晕了，那么我们把这个前因后果，三方之间（ 51cto，帝联，光环新网）的关系整理总结如下：（ 全部依赖个人的推测，如果有错误之处还恳请同行指正 ）
一，上海帝联科技股份有限公司，是一家提供IDC机房服务器托管，以及 CDN （内容分发网络）加速的运营商，它首先向 APNIC 申请租用 IP 地址，前者被分配到的地址块是119.254.112.0/20( IP 子网划分后的结果为119.254.112.0-119.254.127.255)，实际的分配动作，可能是APNIC，也可能是 CNNIC，
二，帝联通过（租用） 北京光环新网科技股份有限公司这家 ISP 的服务 ，接入互联网，光环新网将这个网段与它被分配到的 AS 自治域号码 AS23844（这个AS号码可能是光环新网向 CNNIC 申请的） ，关联起来，用于 BGP互联，实现将该网段路由至 CSTNET（中国科技网）这个国内的骨干网上，再通过这个骨干网与国内其它骨干网，以及 Internet 互通互连。
这样就实现了向帝联提供接入服务。
三，51cto 向帝联租用 CDN 加速服务，后者向前者提供一台 IP 为 119.254.116.18 的服务器，用于图片缓存，从表面上看，只有这一台服务器，但实际上，即便是用于加速图片下载的服务器，后端也有大量的内网服务器集群来实现负载均衡；
光这样还不行，既然我们可以通过 CNAME 域名访问到这台服务器和它的内网集群，说明帝联有向其它提供域名申请的厂商，将这个 IP 与 51cto.ghcdn.cn 关联起来，后者负责将这条资源记录写入其自身维护的区数据文件，简单的讲，
负责 ghcdn.cn 域的权威名字服务器，其区数据文件中，应该就保存着这一条映射记录，
最后，51cto 的开发人员，将这个 CNAME 域名通过 HTML <img> 标签的 src 属性，引入到页面 HTML 源码中，这个过程也有可能是和发布博客相关的 web 应用程序在用户提交博文时，自动完成的，具体可能是由判断用户是否勾选“置顶”复选框的代码逻辑执行，当然相关代码是由开发人员编写的。
这样，当其它用户访问该页面时，例如我这里的 firefox 先向谷歌的 DNS 服务器 8.8.8.8 请求解析 img1.51cto.com 的 IP 地址，如果 8.8.8.8 在它的本地缓存中有这条记录，而且记录没有过期，那它就直接发给客户端；假设 8.8.8.8 不知道这个域名的 IP ，它总知道“根名字服务器”的 IP 吧 ？
（A）8.8.8.8 可能亲自向分布在全世界各地的 13台“根名字服务器”其中一台，请求解析 img1.51cto.com 的 IP 地址，或者
（B）8.8.8.8 向客户端返回其中一台的 IP，要客户端自己向这个根名字服务器请求解析 img1.51cto.com
(A)叫做 DNS 递归解析；(B)叫做 DNS 迭代解析
不管是递归还是迭代，任何一台根名字服务器，肯定知道负责 com. 这个 gTLD（通用顶级域）的权威名字服务器的其中一台的 IP ，对于递归解析，它亲自向其中一台发起查询；对于迭代解析，它将其中一台的 IP 通过 DNS 应答，发给客户端，叫客户端自己去查；
因为 com. 是 . 的子域；而 51cto.com. 是 com. 的子域，因此负责 com. 域的任何一台权威名字服务器，应该都知道负责 51cto.com. 域的权威名字服务器的 IP ，所以，负责 com. 域的权威名字服务器，可能亲自去查（递归），也可能向本地客户端，返回负责 51cto.com. 域的名字服务器 IP ，要其自己去查（迭代），
需要注意的是，对于递归解析，查询结果会从负责 51cto.com. 域的名字服务器（到这里才会产生实际的查询结果）逐级返回至根名字服务器，然后再返回到递归解析请求的起始点，即 8.8.8.8，最后，由它将查询结果交给客户端。
不管是那种方式，51cto.com. 域的权威名字服务器，肯定知道 img1.51cto.com 的 IP ，只要得到这条资源记录，那么本地客户端就可以向该 IP 发起 HTTP 请求，而 img1.51cto.com 与 51cto.ghcdn.cn 指向同样的 IP ，因此也可以直接请求解析 51cto.ghcdn.cn，只是它的整个解析流程会涉及到负责 cn. 这个国家顶级域的权威名字服务器；
关于这一点，下面通过 dig 的一个追踪 DNS 解析过程的参数：trace 就可以非常直观的展现，有兴趣的朋友也可以自行研究搜索介绍 dig 使用的文章:
看完上面这张图后，你发现存在问题了吗？
如果 dig 的追踪和输出结果无误，那么上面的截图表示，最终由 180.153.162.151 这台名字服务器返回查询结果，但结果仅仅是一个 CNAME 域名，我们知道，因特网上的主机，最终是要依赖 IP 地址进行路由访问的，因此必须知道 51cto.ghcdn.cn 的 IP 地址，
如果是 dig ，那也就算了，因为它已经完成交给它的任务：追踪解析 img1.51cto.com 的过程，即便最后结果是 CNAME，它也不在意；
但是对于浏览器而言，那就不一样了，它被赋予的任务是从这台主机下载图片，并展现给用户，这需要知道实际的 IP 地址才行（排除本地缓存的例外情况）；
因此，我个人推测：浏览器需要向 8.8.8.8 ，请求解析 51cto.ghcdn.cn 的 IP 地址，因此除了经历类似上面 dig 的解析过程外，还涉及和 cn. 这个国家顶级域相关的解析链（当然可以用 wireshark 验证是否正确，留给各位课后练习）
下面，给出一张用 dig 追踪解析 51cto.ghcdn.cn IP 地址的过程，来模拟浏览器可能的相同行为：
下面给出一张查询“负责 ghcdn.cn. 域的权威名字服务器”与“负责 51cto.com.域的权威名字服务器”结果的截图，
提醒一下，这里只是为了交流技术，严格禁止，并且对用截图中给出的信息，向目标进行 DNS 区域数据文件传送，DNS 缓存下毒，伪造源IP的查询反射 DDOS，等***行为带来的后果不承担任何法律责任：
*****补充知识点：关于 SOA（起始授权记录），权威回答与非权威回答
用最通俗的解释，SOA 就是负责某个域的名字服务器的记录；通常，一个域可能会有多个名字服务器来负责，但是其中只有一个名字服务器的优先级别最高，SOA 就记录了这个至高无上的名字服务器的信息；
如果我们（客户端 DNS 解析程序）直接向负责某个域的名字服务器其中之一，查询该域的任何信息，那么得到的响应会表明是权威回答，因为它就负责维护这个域中所有主机-域名到 IP 地址的映射关系；这每一条映射称为“资源记录”；包含该区所有资源记录的文件称为“正向解析的区数据文件”；
如果我们向任何其它不属于这个域的名字服务器，查询该域的信息，得到的响应会表明是非权威回答，因为这些第三方名字服务器可能返回它们本地缓存的记录；
下面用截图来说明这些概念：
为了更深入理解，我们再举个例子，如下：
好了，经过上面一连串的努力，总算对 img1.51cto.com 这个域名的前世今生有了稍微清晰一点的认识，我们继续把前面 netstat 命令输出中，剩余的5条 IP 地址记录，解释清楚，作为本篇博文的结束：
转载于:https://blog.51cto.com/shayi1983/1553095
814
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
