加强linux系统的DNS服务的安全防御能力

2017-03-27

12746

M8-1 加强Linux 系统的DNS 服务的安全防御能力1.1场景描述1.1.1 学习目的学生通过该能力模块的学习, 能够独立完成和熟练掌握安全配臵DNS 服务器，加强Linux 系统的DNS 服务

M8-1 加强Linux 系统的DNS 服务的安全防御能力

1.1场景描述

1.1.1 学习目的

学生通过该能力模块的学习, 能够独立完成和熟练掌握安全配臵DNS 服务器，加强Linux 系统的DNS 服务的安全防御能力。

1.1.2 学习要求

理解：DNS 服务存在安全风险

掌握：DNS 服务安全选项配臵

掌握：DNS 服务TSIG 配臵

1.1.3 学习重点和难点

1. 学习重点

✧ 保护DNS 服务器本身安全

✧ 保护 Zone Transfer 的安全

✧ 保护 DNS 免于 Spoofed攻击

✧ 使用 TSIG保护DNS 服务器

✧ 保护Dynamic Update的安全

2. 学习难点

✧ 使用 TSIG保护DNS 服务器

1.2 知识准备

1.2.1 Zone Transfer

DNS 的区域传输目的是为了DNS 的备份，当DNS 服务器坏了，它的数据不会丢失。注意在配臵区域传输是一定要注意辅助服务器上建立的区域是辅助区域且与主服

务器的域名相同，而且区域传输是双向的，不但需要在辅助服务器上配臵还要在主服务器上进行相应的配臵。

1.2.2 DNS威胁

DNS 服务面临的安全问题主要包括：DNS 欺骗（DNS Spoffing ）、拒绝服务（Denial of service，DoS ）攻击、分布式拒绝服务攻击和缓冲区漏洞溢出攻击（Buffer Overflow ）。

1. DNS 欺骗

DNS 欺骗即域名信息欺骗是最常见的DNS 安全问题。当一个DNS 服务器

掉入陷阱，使用了来自一个恶意DNS 服务器的错误信息，那么该DNS 服

务器就被欺骗了。DNS 欺骗会使那些易受攻击的DNS 服务器产生许多安

全问题，例如：将用户引导到错误的互联网站点，或者发送一个电子邮

件到一个未经授权的邮件服务器。网络攻击者通常通过三种方法进行

DNS 欺骗。图1是一个典型的DNS 欺骗的示意图。

TuPkVGdvW6tl

（1）缓存感染

黑客会熟练的使用DNS 请求，将数据放入一个没有设防的DNS 服务器的缓存当中。这些缓存信息会在客户进行DNS 访问时返回给客户，从而将客户引导到入侵者所设臵的运行木马的Web 服务器或邮件服务器上，然后黑客从这些服务器上获取用户信

息。

（2）DNS 信息劫持

入侵者通过监听客户端和DNS 服务器的对话，通过猜测服务器响应给客户端的DNS 查询ID 。每个DNS 报文包括一个相关联的16位ID 号，DNS 服务器根据这个ID 号获取请求源位臵。黑客在DNS 服务器之前将虚假的响应交给用户，从而欺骗客户端去访问恶意的网站。

（3）DNS 复位定向

攻击者能够将DNS 名称查询复位向到恶意DNS 服务器。这样攻击者可以获得DNS 服务器的写权限。

2. 拒绝服务攻击

黑客主要利用一些DNS 软件的漏洞，如在BIND 9版本（版本9.2.0以前的 9系列）如果有人向运行BIND 的设备发送特定的DNS 数据包请求，BIND 就会自动关闭。攻击者只能使BIND 关闭，而无法在服务器上执行任意命令。如果得不到DNS 服务，那么就会产生一场灾难：由于网址不能解析为IP 地址，用户将无方访问互联网。这样，DNS 产生的问题就好像是互联网本身所产生的问题，这将导致大量的混乱。

3、分布式拒绝服务攻击

DDOS 攻击通过使用攻击者控制的几十台或几百台计算机攻击一台主机，使得服务拒绝攻击更难以防范：使服务拒绝攻击更难以通过阻塞单一攻击源主机的数据流，来防范服务拒绝攻击。Syn Flood是针对DNS 服务器最常见的分布式拒绝服务攻击。

4. 缓冲区漏洞

Bind 软件的缺省设臵是允许主机间进行区域传输（zone transfer）。区域传输主要用于主域名服务器与辅域名服务器之间的数据同步，使辅域名服务器可以从主域名服务器获得新的数据信息。一旦起用区域传输而不做任何限制，很可能会造成信息泄漏，黑客将可以获得整个授权区域内的所有主机的信息，判断主机功能及安全性，从中发现目标进行攻击。

1.2.3 TSIG

DNS 的事务签名分为 TSIG (Transaction Signatures) 与 SIG0 (SIGnature)两种。该如何选择呢? 首先，要先判断客户端与服务器间的信任关系为何，若是可信任者，可选择对称式的 TSIG。TSIG 只有一组密码，并无公开/私密金钥之分；若是

非完全信任者，可选择非对称式金钥的 SIG0，虽有公开/私密金钥之分，相对的，设定上也较复杂。至于要选用哪种较适合，就由自己来判断。通常区带传输是主域名服务器到辅助域名服务器。

1.TSIG 技术

交易签章 (TSIGRFC 2845)，是为了保护 DNS安全而发展的。从BIND 8.2版本开始引入 TSIG 机制，其验证 DNS 讯息方式是使用共享金钥 (Secret Key) 及单向杂凑函式(One-way hash function) 来提供讯息的验证和数据的完整性。主要针对区带传输（ZONE Transfer）进行保护的作用，利用密码学编码方式为通讯传输信息加密以保证 DNS 讯息的安全，特别是响应与更新的讯息数据。也就是说在DNS 服务器之间进行辖区传送时所提供保护的机制，以确保传输数据不被窃取及监听。

2.SIG0 技术简介

SIG0是一九九九年三月由 IBM公司的D. Eastlake 提出成为标准。其是利用公开金钥机制为辖区资料进行数字签章的动作，以保证每笔传输的 source record 具有可验证性与不可否认性。实际上 SIG0 才是防止 DNS Spoofing 发生最主要的技术，SIG0 是使用公开金钥加密法，让辖区管理者为其辖区数据加上数字签章，由此证明辖区资料的可信赖性。除此之外，SIG0 保有是否选择认证机制的弹性，以及可灵活地配合自订的安全机制。

1.3 注意事项

在对DNS 进行安全配臵之前，需要确认DNS 是否能够正常解析。

1.4 操作步骤

1.4.1选择没有安全缺陷的DNS 版本

BIND 主要分为三个版本：

（1）v4：1998年多数unix 捆绑

（2）v8：如今使用最多最广大版本

安全信息：http://security.nsfocus.com/showQueryL.asp?libID=530

（3）v9：最新版本，免费（http://www.isc.org)

2. 保持DNS 服务器配臵正确、可靠

dlint 是专门检查DNS 配臵文件开源代码软件：

dnstop 可以查询DNS 服务器状态：

1.4.2保护DNS 服务器本身安全

第一步：隔离DNS 服务器

DNS 服务器要专用，不要在DNS 服务器上运行其它服务，尽量允许普通用户登录。第二步：隐藏DNS 服务器

网络攻击者对DNS 服务进行攻击前，首先要知道BIND 有版本号，根据BIND 版本号找到漏洞来确定攻击DNS 服务器方法，攻击者使用dig 命令可以查询到BIND 的版本号。为了保障DNS 服务器安全的首先要隐藏DNS 服务器。下面是没有隐藏DNS 服务，攻击者查询到的DNS 服务器的版本。

[root@centos ~]# dig @192.168.123.11 txt chaos version.bind

; <<>> DiG 9.3.4-P1 <<>> @192.168.123.11 txt chaos version.bind

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10122

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION:

;version.bind. CH TXT

;; ANSWER SECTION:

version.bind. 0 CH TXT "9.2.4"

;; AUTHORITY SECTION:

version.bind. 0 CH NS version.bind.

;; Query time: 20 msec

;; SERVER: 192.168.123.11#53(192.168.123.11)

;; WHEN: Thu Jan 14 18:33:27 2010

;; MSG SIZE rcvd: 62

[root@centos ~]#

通过下面对服务器进行安全配臵，攻击者无法查询到DNS 服务地版本信息，编辑BIND 配臵文件，如下所示。

[root@lab2 ~]# vi /etc/named.conf

// named.conf for Red Hat caching-nameserver

options {

directory "/var/named";

version "unknow on this platform";

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

* If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default.

// query-source address * port 53;

};

// a caching only nameserver config

"/etc/named.conf" 79L, 1572C

在配臵文件中加入“version "unknow on this platform";”，保存配臵文件，然后退出，重启DNS 服务器。

[root@lab2 ~]# service named restart

停止 named：[ 确定 ]

启动 named：[ 确定 ]

[root@lab2 ~]#

再使用dig 命令进行测试，如下所示：

[root@centos ~]# dig @192.168.123.11 txt chaos version.bind

; <<>> DiG 9.3.4-P1 <<>> @192.168.123.11 txt chaos version.bind ; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61670

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION:

;version.bind. CH TXT

;; ANSWER SECTION:

version.bind. 0 CH TXT "unknow on this platform"

;; AUTHORITY SECTION:

version.bind. 0 CH NS version.bind. ;; Query time: 16 msec

;; SERVER: 192.168.123.11#53(192.168.123.11)

;; WHEN: Thu Jan 14 18:40:23 2010

;; MSG SIZE rcvd: 80

通过上面测试，可以看到攻击者无法查询到DNS 的版本信息。

第三步：避免透露DNS 服务器信息

和版本号一样，也不要轻易透露服务器其他信息。为了让潜在的攻击者更难得手，尽量不要在DNS 配臵文件中使用这HINFO 和 TXT两个资源记录。

第四步：以最小的权限及使用chroot()方式运行BIND

以 root 使用者的身分执行BIND 有安全隐患，攻击者若找到BIND 的安全漏洞，可能获取 root 的身分，从而进行对服务器攻击。

BIND 8.1.2 允許在启动DNS 服务器後，变更其UID 和GID ，可以使用命令 named -u named

以 chroot() 的方式执行BIND 可将危害减至最低

设臵 chroot 之后的环境：设臵dev/zero、dev/random、dev/log或etc/localtime，可以使用命令修改运行用户。

named -u named -t /var/named

1.4.3保护 DNS 免于 Spoofed 攻击

DNS 服务器若接受来自Internet 的递归询问要求，易遭受Spoofing 的攻击，导致攻击者修改DNS 服务器区域文件，其它用户解析域名的时候，取回的是假造的名称信息。

第一步：关闭rescursion 的功能

关闭 rescursion 功能后，DNS 服务器只会响应非递归的询问要求

无递归功能的DNS 服务器不易易遭受 Spoofing 的攻击，因为它不会送出查询要求，所以也不会摄取所管区域以外的任何数据

如果DNS 服务器还提供服务给合法的解析器（resolver ），或是充当其他D NS服务器的代询服务器（forwarder ），就不应该关闭 rescursion 的功能。如果无法关闭 rescursion 的功能，应该限制查询要求的服务对象

修改配臵文件：/etc/named.conf.加入一行：

[root@lab2 ~]# vi /etc/named.conf

// named.conf for Red Hat caching-nameserver

options {

directory "/var/named";

version "unknow on this platform";

recursion no;

fetch-glue no;

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

"/etc/named.conf" 81L, 1603C

第二步：关闭 glue fetching 的功能

修当DNS 服务器为响应询问的 DNS 封包建立 additional data 区段的数据时，会自动解析 NS 纪录中任何DNS 服务器的域名，这称为 glue fetching，易遭受 Spoofing 的攻击。

关闭 glue fetching 的功能，可避免DNS 服务器送出任何的查询要求，所以也不会摄取所管区域以外的任何数据。

当DNS 服务器返回一个域的域名服务器纪录并且域名服务器纪录中没有A 纪录，DNS 服务器会尝试获取一个纪录。就称为glue fetching, 攻击者可以利用它进行DNS 欺骗。关闭glue fetching 是一个好方法，修改配臵文件：/etc/named.conf.加入一行：

[root@lab2 ~]# vi /etc/named.conf

// named.conf for Red Hat caching-nameserver

options {

directory "/var/named";

version "unknow on this platform";

recursion no;

fetch-glue no;

dump-file "/var/named/data/cache_dump.db";

statistics-file "/var/named/data/named_stats.txt";

"/etc/named.conf" 81L, 1603C

第三步：限制查询要求的服务对象

如果无法关闭 rescursion 的功能，应该限制查询要求的服务对象

限制询问要求的来源（IP 地址）

限制可以查询的区域范围

DNS 服务器应该拒绝来自以下网络的询问要求

私有网络（除非你自己在使用）

实验性网络

群播网络

一般的DNS 服务器

对所管区域的名称信息，可以服务来自任何 IP 地址的查询要求，因为它是经授权而来管理该区域的权威DNS 服务器

对于所管区域以外的名称信息，只应该服务来自内部或可信赖之 IP 地址的查询要求

cahing-only DNS服务器

应该只服务来自特定 IP 地址的解析器

authoritative-only DNS服务器

必须服务来自任何IP 地址的询问要求，但是应该拒绝任何递归的询问要求。具

相关推荐