网络安全

网络安全课题研究--DNS Tunnel

继续从大佬同学那里骗作业过来~


利用DNS TUNNEL穿越网关计费系统

说到DNS Tunnel，我之前有一篇文章介绍过:
tecent安全工程师测试
当时是粗略的看了一下，这里重新复习一次DNS Tunnel的原理先。

DNS的定义

DNS(Domain Name System)，也就是域名解析系统，是一种能够将数字ip与域名形成映射的协议。就好像ip180.97.33.107这个我们很难记忆这4个数字，但是[www.baidu.com]本身我们很容易去记忆，将这两者联系起来的就是DNS协议。

DNS工作原理

当我们尝试去访问一个域名，比如说test.com的时候，此时电脑会发起一个请求去访问这个域名，此时会有一个请求去寻找域名所绑定的ip是什么。

我们访问的第一个服务器就是递归解析器(recusive resolver),也就是你的ISP(Internet Server Provider),互联网服务提供商，或者Wireless carriers(也就是手机平板之类使用的服务提供)或者其他第三方提供。递归解析器知道要访问哪些其他的DNS 服务器来获得你所访问的域名的解析

有时候递归服务器本身就会存储有ip和域名之间的映射关系，此时它就会直接返回ip地址，结束访问。

如果没有缓存这个映射关系的话，递归解析器就回去访问13个服务器，叫做根服务器(Root Server),根服务器能解析顶级域名所在的ip 地址，比如说.com等等。由于根服务器其实在世界上很多地区都有，所以域名解析的时候，DNS 能够确保递归解析器会去寻找离它最近的服务器进行询问。

接下来，递归解析器会去查询当前顶级域名(Top Level Domain)解析服务器，顶级域名解析服务器会返回当前域名服务器(权威服务器, Authorization Server)所在的地址，从而进一步访问:

最后就相当于是从域名服务器中取得了当前test.com的ip，访问指定ip就相当于是进行了访问

我们可以尝试使用linux下的dig指令来查看:

第一段相当于是介绍一些简单的查询参数。

1
2
3
4
5
; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> www.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41736
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 6

第二段是显示我们此时请求的域名是啥

1
2
;; QUESTION SECTION:
;www.baidu.com.                 IN      A

此时的A表示的是Address,也就是地址，说明我们此时查询的是www.baidu.com的地址。注意到这里的域名最后有一个**.**,这里是有原因的:

**.**其实是因为，所有的域名结尾都是.root，比如说www.google.com的真正域名是www.google.com.root。这里使用.省略这个写法。
第三段显示了当前DNS服务器给出的答复:

1
2
3
4
;; ANSWER SECTION:
www.baidu.com.          1154    IN      CNAME   www.a.shifen.com.
www.a.shifen.com.       267     IN      A       180.97.33.108
www.a.shifen.com.       267     IN      A       180.97.33.107

这里的CName(Canonical Name)表示的是当前域名的规范域名，相当于说这个域名和www.baidu.com是等效的。

第四段则是显示了此时的查询究竟查询了哪些服务器:

1
2
3
4
5
6
;; AUTHORITY SECTION:
a.shifen.com.           862     IN      NS      ns4.a.shifen.com.
a.shifen.com.           862     IN      NS      ns5.a.shifen.com.
a.shifen.com.           862     IN      NS      ns1.a.shifen.com.
a.shifen.com.           862     IN      NS      ns2.a.shifen.com.
a.shifen.com.           862     IN      NS      ns3.a.shifen.com.

这里能看到，这个a.shifen.com总共查询了五个DNS服务器，NS表示的就是Name Server，就是说这五个服务器在管理这个域名。

ADDITIONAL SECTION:
1
2
3
4
5
ns1.a.shifen.com.       442     IN      A       61.135.165.224
ns2.a.shifen.com.       466     IN      A       180.149.133.241
ns3.a.shifen.com.       466     IN      A       61.135.162.215
ns4.a.shifen.com.       439     IN      A       115.239.210.176
ns5.a.shifen.com.       532     IN      A       119.75.222.17

这一段显示的是上一段查询的服务器的ip为多少。

1
2
3
4
;; Query time: 64 msec
;; SERVER: 218.2.2.2#53(218.2.2.2)
;; WHEN: Wed Sep 27 10:54:47 DST 2017
;; MSG SIZE  rcvd: 271

最后一段表示的是一些查询结果，查询总共花了64秒。并且本机的DNS服务器地址为218.2.2.2,端口为53(默认的查询端口)

这里介绍一下DNS记录有哪些类型:

  • MX: 这类是SMTP用来传输邮件时候使用的
  • SRV: 用于记录每一种服务器提供的服务. SRV记录在高性能或者读取负载均衡方案和中很常见.
  • A: 表示此时为一个IPv4地址.
  • AAAA: 表示此时是一个IPv6地址.
  • TXT: 用于存放通用信息. 这个记录常常用于DNS Tunnel中.
  • PTR: 表示DNS反向信息.也就是说当前ip对应的域名是啥(查询的话，使用指令dig -x )

作业总结

最近做了一个作业，发现还是存在一些不熟悉的地方，这里记录一下：

存在cdn的网站，最后cdn的ip解析会解析到cdn所在的服务器上

我这里以为这个说法是不正确的，因为我一开始没想过cdn和dns能有啥关联的，所以想到说url的 CNAME 解析成cdn的url也没什么关系。后来才想到，如果cdn存在的话，那么对于CNAME解析，这个就不是一个别名那么简单，而是利用别名让url解析的ip对应到对应的cdn服务器上，从而实现cdn的加速（感觉一个很简单的道理一下子没想清楚）

DNS Tunnel

介绍了DNS的工作原理之后，我们做出如下的假设:
如果我们此时在一个受限制的网络中，不能主动访问外网，但是此时DNS请求却没有被禁止。那么我们如果利用DNS协议的话，是不是就能够伪装成进行DNS交换，但是实际上是和对应的服务器进行了交互，让DNS服务器帮忙转发我们的数据包呢？

假如说，此时我们已经能够控制一台域名服务器(Authorization Server)，那么当我们尝试访问一个域名，并且在本地的递归解析器中并没有留下缓存的话，那么其就会向我们之前所说的进行迭代查找。如果我们能够控制一个域名服务器的话，那么这个查找最终就会查找到对应的服务器上，然后服务器会对我们的请求进行回复，从而构建成一个逻辑上的通路。

比如说，这次我们要发送的数据为

1
c2VjcmV0

那么此时我们应该尝试访问的网站叫做:

1
c2VjcmV0.domain.com

那么接下来的操作就会如下图一样，完成一次通信:

最后就相当于在局域网中的电脑和外部的服务器形成了链接。

Web Portal认证方式

光知道DNS Tunnel 是啥还不够，我们还得知道这个Web Portal认证是啥，才能尝试去绕过。
Web portal，其实就是我们很多时候在商场或者学校链接WiFi的时候，有时候会插入一个页面，要求我们输入用户名密码，或者手机号之类的东西。这个时候进行认真的方式就叫做Web Portal。Web Portal本身的网络拓扑图大致如下:

然后用户在发起HTTP/HTTPS请求的时候，如果接入设备发现用户并没有进行身份认证的话，就会强制将用户重定向至于Portal服务器上。用户利用portal服务器上的信息进行基本的身份确认，然后将确认后的信息发送给接入设备。然后通过接入设备和认证服务器认证之后，计费服务器便开始进行数据请求并且进行流量计费。

绕过方法

我们可以看到，当前的Web Portal认证的方法有些【并没有阻止接入设备向外进行其他协议请求】。也就是说，其并没有限制DNS请求（当然也是看处理方式）。如果我们使用DNS隧道的方式，就能够绕过Web Portal中对于HTTP/HTTPS请求的拦截，完成通信。

这里使用工具Iodine进行DNS隧道搭建。为了能够实现DNS隧道搭建，那么最为关键的是要实现【查询域名的DNS请求能够来到我们指定的服务器上】。为了实现这一点，我们可以给DNS服务器上增加两条内容:

1
2
t1      IN  NS  t1ns.mydomain.com.
t1ns		IN	A	my.ip.add.ress

然后在服务器上使用iodined监听对于t1.mydomain.com的请求，

1
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com

其中 -P 后面可以填入我们此时隧道加密的密码，然后在客户端这边，使用iodine发起DNS请求

1
./iodine -f -P secretpassword t1.mydomain.com

如果设置没有问题的话，就能够建立DNS隧道了！
参考网站:
http://www.ruanyifeng.com/blog/2016/06/dns.html
http://blog.csdn.net/xianweijian/article/details/49450703