PS: 弱爆了^.^偶尔看看，只是笑笑，各种浮躁和浅薄，域名服务和名字服务很多东东的啊。。。
DNS安全与攻防研究
目录
摘 要
随着Internet的飞速发展，DNS已成为互联网重要的基础服务，在网站运行和维护中起着至关重要的作用。但是，随之而来，它也暴露着各种漏洞。近年来，互联网上发生的网络攻击事件日益频繁，DNS系统也遭受到了一系列的攻击，导致了Internet通信受到严重的影响。业内不得不更多地关注DNS的安全。
本文首先探讨了DNS安全方面的研究背景，以此为导入对DNS安全进行研究。从DNS定义及其工作原理出发，到DNS安全体系的引入，并谈谈DNS的重要性；然后从DNS自身出发，对其进行一些安全方面的高级配置，加固DNS的安全；最后，围绕DNS周边环境，在linux操作系统内核调优，以及其他工具如iptables的使用，使DNS的安全更有保障。
关键字：DNS安全；网络安全；BIND；iptables
Abstract
The Domain Name System (DNS) is vital to the Internet, providing a mechanism for resolving host names into Internet Protocol (IP) addresses. Insecure underlying protocols and lack of authentication and integrity checking of the information within the DNS threaten the proper functionality of the DNS. With the development of Internet network application and business，the network attack events have happened more and more frequently．DNS system has suffered from a series of attack．It badly affected the communication of Internet. Therefore more and more people begin to pay attention to the security problem of DNS.
At the beginning．the paper lists some DNS attack examples, and then analyses the origin and process of DNS system，and showing some DNS security problems. After analyzing the problems, the paper puts forward some proposal for protecting the DNS server from attacking. The decision is made to focus on Response Rate Limiting (RRL) and determine the effectiveness of this mechanism against current and future attacks. And other nice tools can help the DNS, such as iptables. The main conclusion is that RRL is a proper defense against current amplification attacks, but it is not effective against future more sophisticated attacks.
Key words: DNS Security; Network Security; BIND; iptables
第1章 绪 论
1.1 研究背景
DNS的安全问题不容忽视！当前，DNS面临的风险很多，如拒绝服务攻击、域名劫持、错误的配置、软件漏洞、缓存污染、中间人攻击、DNS恶意指向等。这些风险中引发的事件，多数由于管理环节的疏漏，以及DNS配置复杂性、缺乏一个有效的快速更新机制等原因引起，关注DNS的安全，关注互联网的未来。
近年来，随着Internet网络应用和业务的不断发展，互联网上发生的网络攻击事件日益频繁，DNS系统也遭受到了一系列的攻击，导致了Internet通信受到严重的影响。
典型的几次攻击如暴风影音事件，百度域名劫持，瑞典顶级域名“.se”故障，BIND9漏洞导致“.com”无法正常解析，还有DDos攻击。DDos攻击在今天看来并不新鲜，近两年来发展态势也渐趋平缓，直至一个月前，欧洲反垃圾邮件组织Spamhaus突然遭受到高达300Gbps的大流量DDos攻击。这一轮被认为是史上最大的DDos攻击，让人们警醒，原来DDos攻击手段从未被攻击者忽略。针对Spamhaus的攻击，使用的主要攻击技术是DNS反射技术。从去年开始，DNS反射技术已经成为了大规模第三层DDoS攻击的主要部分。可以说，开放的DNS服务器（DNS解析器）是互联网的灾难，如果服务提供商没有一致努力关掉这些开放DNS服务器的话，DDoS攻击的规模会变得越来越大。最近的台菲黑客大战，台湾骇客已取得菲律宾DNS资料库帐号与密码，这里面有很多值得对DNS安全的思考。
1.2 DNS的重要性
DNS是因特网建设的基础。如果 DNS 系统运作不正常, 即使Web 服务器都完好如初,防火墙系统都善尽其职,相关的后端应用服务器以及数据库系统运作正常,因为无法在期限时间内查得到网址,将会导致电子邮件无法传递,想要使用网域名称去连接某个网页,也会因查不出网络地址,以致联机失败。
互联网上DNS服务器的事实标准就是ISC公司的。Berkeley Internert Name Domain(BIND)，它具有广泛的使用基础，互联网上的绝大多数DNS服务器都是基于这个软件的。在互联网上运行着的DNS服务器中，ISC的BIND占据了95%的市场份额。互联网是由很多不可见的基础构件组成。这其中就包含了DNS，它给用户提供了易于记忆的机器名称(如sina.com)，并且将它们翻译成数字地址的形式。对于那些用于公共服务的机器一般还提供“反向查询”的功能，这种功能可以把数字转换成名字。如何能加强确保 DNS 系统的运作正常, 或者当DNS系统在遭受网络攻击时候,能够让管理者及早发现是日益重要的系统安全的课题。
1.3 课题研究的思路
本课题本着理论与实践相结合的方法，对DNS的安全方面进行研究。从DNS基本工作原理出发，着手分析DNS的安全方面，并结合相关官方文档，通过自己的理解，用实验证明相关的描述，并加以改进和完善。
本文主要从DNS本身的服务安全和通过其他辅助工具进一步加强它的安全，两个角度出发。第一、二章先分析DNS安全的一些背景以及DNS安全等方面的阐述，然后第三、四章从两个角度着手实践和研究相关的安全策略。
本文结构如图1-1所示。
图1-1本文结构
第2章 DNS安全简介
2.1 DNS定义
实际上， DNS[1]是一个分布式数据库。它允许对整个数据库的各个部分进行本地控制；同时整个网络也能通过客户—服务器方式访问每个部分的数据。借助备份和缓存机制，DNS将具有强壮性和足够的性能。被称为名字服务器（name
图2-1 DNS数据库
server）的程序构成了DNS客户—服务器机制的服务器一端。名字服务器包含数据库中某些部分的信息，并使得被称为解析器（resolver）的客户端程序能访问到这些信息。解析器往往是创建查询请求并通过网络将它们发送到名字服务器的库例程。DNS数据库的结构图2-1所示。整个数据库用图来表示就像一棵倒着的树，根节点在顶端。
图2-2域
每个节点同时也是整棵树中新子树的根。每棵子树都代表整个数据库的一个部分（partition），对应到DNS中的一个域。每个域又能进一步被划分成更多的部分，在DNS中这叫做子域（subdomain）。子域在图2-2中被画成它们父域的孩子。每个域都有惟一的名字。域的域名（domain name）标识它在数据库中的位置。在DNS中，域名是从域根所在节点到整个树的根节点的标号的顺序连接，标号间用“.”来分隔。在DNS中，每个域都能被分成许多子域，而这些子域又可由不同的组织来管理。
2.2 DNS工作原理
DNS工作原理很复杂，本文不做具体的剖析，用一个具体的解析实例，来表明了一个真实域中真实主机的地址解析过程，包括如何遍历域名空间树的过程。本地名字服务器向根名字服务器查询www.hnctcm.edu.cn的地址，根服务器告知它去联系cn名字服务器。本地名字服务器问cn名字服务器同样的问题，被告知edu.cn名字服务器的地址列表。本地名字服务器从列表中选择一个edu.cn名字
图2-3域名解析过程
服务器并向其继续询问同样的问题，edu.cn名字服务器就告诉本地名字服务器hnctcm.edu.cn名字服务器的地址。最终，本地名字服务器向hnctcm.edu.cn名字服务器询问并获得答案。过程如图2-3所示。
2.3 DNS体系的安全缺陷
DNS在设计之初并没有考虑安全问题，作为一个开放系统，DNS明显存在未授权信息的泄漏问题，即保密性无法保证，同时也缺乏有效的接入控制。这里没有研究更早的漏洞，从国内的绿盟科技[9]对DNS的研究可以看到一些漏洞。
2010年国内绿盟科技NSFOCUS安全小组发现ISC BIND9中存在一个远程拒绝服务漏洞，利用构造特殊的DNS查询数据可以导致BIND进程异常退出。新版BIND 9支持Dynamically Loadable Zones，以代替过去用文本文件存放zone数据的方式。在BIND Dynamically Loadable Zones环境下配置子域委托时，如果针对该子域进行ANY RR查询，同时请求使用DNSSEC，有可能触发一次显式的abort()，致使BIND进程主动退出，导致拒绝服务攻击。没有使用DLZ的BIND服务不受此漏洞影响。攻击者只需发送单包即可触发此漏洞。
2013年3月份，kb.isc.org又指出，BIND 9.7, 9.8, 9.9使用的一个库在处理正则表达式时存在错误，可被利用耗尽内存资源并使BIND 9服务器不可用。
综上可以看出，BIND是本身是存在很多漏洞的，如果想让漏洞得到及时的修复，让自己的DNS服务器更优秀，就需要关注BIND官方的报告，及时为自己的服务器打上补丁，并进一步完善配置。
2.4 DNS服务面临的攻击
2.4.1 DNS反射/放大攻击
DNS反射/放大攻击[3][4]技术的基本方式是：向大量开放DNS服务器发送大范围域名查询的DNS请求，并将该DNS请求的源IP地址伪造成想要攻击的目标IP地址。开放DNS服务器在接收到请求后会对该请求进行解析查询，并将大范围域名查询的响应数据发送给攻击目标。由于请求数据比响应数据小得多，攻击者就可以利用该技术有效的放大其掌握的带宽资源和攻击流量。这个是关键点，请求的数据比相应的数据量要小，如果开放递归，返回的数据会更多。简单的测试命令如下:
客户端命令：dig ANY isc.org @192.168.10.112
图2-4反射/放大攻击原理图
使用完这条命令之后，会发现服务器段返回了很多数据给客户端，这就是放大攻击利用的最基本的原理。服务器端，可以利用tcpdump针对udp的53端口，抓取相应的通信包，也可以看出里面的数据。
这样，可想而知，如果进行分布式的攻击，DNS服务器是很难以承受的了的。攻击示意如图2-4所示。
2.4.2 劫持攻击
DNS劫持又称域名劫持，是指在劫持的网络范围内拦截域名解析的请求，分析请求的域名，把审查范围以外的请求放行，否则返回假的IP地址或者什么都不做使请求失去响应，其效果就是对特定的网络不能反应或访问的是假网址。域名劫持示意图如2-5所示。
图2-5域名劫持攻击示意图
2.4.3 其他攻击
DNS安全威胁主要有隐私泄露，数据损坏，拒绝服务等。隐私泄露主要是缓存被窥探等。数据损坏，存储块损坏，系统损坏，还有协议问题。针对存储区损坏，这里面就有信息过期呀，如隐藏主服务器的DDoS攻击，信息更改(主从服务器攻陷，社会工程攻击)，当然，域名劫持也算，如百度的域名劫持，其实就是一种社会工程攻击。而系统损坏，有解析器攻陷和客户端攻陷，解析器攻陷，主要是主机渗入，而客户端，就是一些恶意软件的功劳了。关于协议问题，主要是缓存中毒，查询预测，还有一些中间人的攻击。缓存中毒里面有过分自由的附加信息，当然，递归查询的开放，也会导致缓存中毒，而且它还对放大攻击助纣为虐。而决绝服务，由上面说的针对DNS服务器的，它会使系统/应用程序崩溃（特制数据包）和资源耗尽（DoS攻击和分布式DoS攻击）等两个方向的攻击。同时，针对网络基础的攻击，3月份的那次攻击，黑客就有针对CloudFlare的网络服务供应商和互联网交换设施攻击。从3月19日到3月21日，对Spamhaus的攻击流量在30G到90G之间波动。到3月22日，攻击流量达到了120G。在攻击者发现无法有效的击垮Spamhaus和作为防护服务提供商的CloudFlare之后，他们改变了攻击策略，转而攻击CloudFlare的网络带宽供应商和连接的互联网交换设施。CloudFlare主要从二级供应商处购买带宽，而二级供应商从一级供应商处购买带宽并保证相互之间的连接。一级供应商并不从彼此购买带宽，他们相互之间进行对等结算。根本上，是这些一级供应商来确保每一个网络能够连接到其他的网络。如果一级供应商的设备或网络出现故障，将会成为互联网一个很大的问题。当然，不仅仅可以针对服务器端的设备，还可以针对客户端的设备攻击。这些具体的攻击，没有做相应的实验，本文并没有提出相应的策略。
2.5 本章小结
本章主要阐述了DNS定义，工作原理，DNS体系的安全缺陷，还对DNS服务面临的一些主要攻击进行了探讨。
第3章 DNS安全加固研究
从DNS安全角度考虑，如何防止那些攻击，怎么样让DNS更安全可靠等等，这些紧跟着的问题都是需要解决的。本章从DNS自身安全的角度出发，对服务本身的配置进行调优和以及针对各种攻击的防范做出了研究。
3.1 分离解析配置
图3-1分离解析配置
视图语句基本语法:
view view_name {
match-clients { address_match_list };
[ zone_statement; ...]
};
每个视图view_name定义了一个将会在用户的子集中见到的zone_statement的DNS名称空间。根据用户的源地址(“address_match_list”)匹配视图定义的“match_clients”。
根据上面的架构图3-1，基于视图的分离解析，重点配置节如下：
两个acl，访问列表.这个对安全方面也很重要.可以限制访问该DNS的客户，所以如果内部使用的话，出了内部电脑，所有的攻击基本上是进不来的.
acl zone1 { 192.168.10.78;};
acl zone2 {10.10.10.11;};
view "lan192" { //视图名没所谓
zone "test.cn" IN {
type master;
file "test.cn.lan10";
also-notify { 192.168.10.111; };
};
}
view "lan10" { /*…*/ };
3.2 基于TSIG的主从服务
DNS规范定义了两种类型的名字服务器:primary master（主名字服务器）和secondary master（辅名字服务器）。区的primary master名字服务器从位于本机的文件中读取区域数据配置文件，而区的secondary master名字服务器则是从该区其他的权威名字服务器处读取数据，后者称为前者的master（主）服务器。颇为常见的是，这个master名字服务器就是这个区的primary master，不过也不一定非要这样：一个secondary master也能从其他secondary master那里加载区数据。
当一个secondary master启动时，它自动与其master服务器通信，如果需要，就从中获取区数据，这被称为“区传送”（zone transfer）。虽然许多人仍然使用secondary这个词，但现在人们更喜欢用slave（辅名字服务器）来表示secondary master名字服务器。其实一个区的主和辅名字服务器都是该区的权威。DNS提供这样两种类型的名字服务器是为了让管理变得简单些。一旦创建了区数据并建立起了主名字服务器，要创建新的名字服务器时，你就不需要傻乎乎地将数据从这台主机拷贝到那台主机了。你只需建立辅名字服务器，它能从该区的主名字服务器获取数据。一旦这些辅名字服务器建立起来，当需要时，它们就会自动传送新数据。
BIND 8.2使用了一种保护DNS消息的新机制，称为“事务签名”（transaction sigature），或简写成TSIG。TSIG使用共享密钥和单向散列函数来鉴别DNS消息，特别是响应和更新。现在，在RFC 2845中说明的TSIG的配置相当简单，对解析器和名字服务器的使用影响较轻，保护DNS消息和动态更新显得非常灵活。如果配置了TSIG，名字服务器或更新者将在一个DNS消息的附加数据部分添加一个TSIG记录。TSIG记录对DNS消息签名，证明消息发送者和接收者共享一个加密密钥，并保证消息在离开发送者后不被修改。黑客会利用IP欺骗一个DNS服务器，迫使其进行非法区带传输。TSIG技术可以进行有效防范。
如下两条命令，可以生成两个签名：
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST lan192
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST lan10
生成的四个文件如下：
Klan10.+157+57014.private
Klan192.+157+60759.private
Klan10.+157+57014.key
Klan192.+157+60759.key
其中一个私钥Klan192.+157+60759.private的内容如下：
Private-key-format: v1.3
Algorithm: 157 (HMAC_MD5)
Key: RQXeMPEXAj5Mx37pzJ044A==
Bits: AAA=
Created: 20130424114602
Publish: 20130424114602
Activate: 20130424114602
然后根据私钥的内容，添加到配置文件中。同架构图3.1一样，针对该架构图，相应的配置[11]如下：
acl zone1 { 192.168.10.78; };
acl zone2 { 10.10.10.11; };
key lan192 {
algorithm hmac-md5;
secret "RQXeMPEXAj5Mx37pzJ044A==";
};
key lan10 {
algorithm hmac-md5;
secret "TUklzhkwYd6roL7tO4BE5Q==";
};
options
{
listen-on port 53 { 192.168.10.112; };
directory "/var/named";
/*…*/
};
view "lan192" {
match-clients { key lan192;zone1; };
allow-query { zone1; };
server 192.168.10.111 { keys{lan192;}; };
zone "test.cn" IN {
type master;
file "test.cn.lan192";
allow-transfer { key lan192; };
also-notify { 192.168.10.111; };
};
zone "10.168.192.in-addr.arpa" IN {
type master;
file "192.168.10.zone";
allow-transfer { key lan192; };
also-notify { 192.168.10.111; };
};
};
view "lan10" { /*…*/ };
3.3 递归限制
递归对放大攻击的影响很大，如果DNS开放递归查询，黑客利用递归查询的DNS服务器，可以加大它的攻击效果。
安全界搞的一个检查dns开放递归查询的org网站，在这里可以按/24查询一个网段内是否有有问题的dns主机，国内有问题的dns server总数是250万台，这个是非常可怕的ddos攻击力量。国内有数量庞大的开放递归查询的dns服务器，（比如3月下旬号称互联网有史以来规模最大的攻击 spamhaus|cloudflare的DNS放大攻击事件里面的所有国内ip基本上都是openresolver）CERT等多家机构都提到了 http://openresolverproject.org/，这是个安全界搞的一个org项目，在这个网站任何个人或企业都建议可以用它自查一下，由于安全考虑该网站只支持/24的查询，如果你的网段真的非常大，可以联系官方。考虑到国内的 open dnsserver如此庞大的数目，如果被人调动会是很恐怖的力量，但最终想真的改善还需要大家一起动手。可能的话请互相传播宣传http://openresolverproject.org这个地址。
稍微具有点儿讽刺意义的事情是，各运营商和用户对这个事情貌似没有引起必要的关注，这个网站倒是被黑客盯上了，由于这个网站每次只能查一个 /24,而且连续查询会被锁，有人试图利用大量的 TORexit点在这个网站来遍历所有地址段，还是要感慨一下现在的黑客的素质。
所以，通过有效的手段禁用递归查询，能对DDoS攻击做到一定程度上的防范[7]。
具体配置[11]如下:
acl zone1 { 192.168.10.78; };
acl zone2 { 10.10.10.11; };
options {
recursion no;
additional-from-cache no;
allow-query { none; };
/* … */
};
view "lan192" {
match-clients { key lan192;zone1; };
allow-query { zone1; };
recursion yes;
additional-from-cache yes;
/* … */
};
view "lan10" { /* … */ };
3.4 rndc控制DNS
利用rndc远程控制DNS，使用cache服务器做为rndc的控制端，远程控制其他几台DNS服务器的配置文件加载，关闭以及打开关闭日志等功能。一方面方便管理大量的DNS服务器，使得操作更方便更高效。 另一方面，提高了服务器的安全性，因为不需要在SSH登陆到目标主机上进行操纵，直接在控制端执行几条命令就可以了，而且是控制在chroot的目录下的，提高了安全性。
rndc(Remote Name Daemon Control)是BIND安装包提供的一种控制域名服务运行的工具，它可以运行在其他计算机上，通过网络与DNS服务器进行连接，然后根据管理员的指令对named进程进行远程控制，此时，管理员不需要DNS服务器的根用户权限。使用rndc可以在不停止DNS服务器工作的情况进行数据的更新，使修改后的配置文件生效。在实际情况下，DNS服务器是非常繁忙的，任何短时间的停顿都会给用户的使用带来影响。因此，使用rndc工具可以使DNS服务器更好地为用户提供服务。rndc与DNS服务器实行连接时，需要通过数字证书进行认证，而不是传统的用户名/密码方式。在当前版本下，rndc和named都只支持HMAC-MD5认证算法，在通信两端使用共享密钥。rndc在连接通道中发送命令时，必须使用经过服务器认可的密钥加密。为了生成双方都认可的密钥，可
以使用rndc-confgen命令产生密钥和相应的配置，再把这些配置分别放入named.conf和rndc的配置文件rndc.conf中。
rndc配置实验的架构图3-2所示。
图3-2 rndc配置结构图
先在主从服务器上分别执行“rndc-confgen”这条命令，生成一段配置代码。然后根据配置代码，配置密钥文件即可。
例如，主服务器上的配置如下：
运行命令：“rndc-confgen”
然后根据命令的标准输出，生成配置文件，并定制主服务器上的key文件：
例如master_rndc.key内容如下：
key "master_rndc-key" {
algorithm hmac-md5;
secret "FOgSrUhEdprHOHlOgajsBQ==";
};
controls {
inet 192.168.10.112 port 953
allow {192.168.10.78;} keys { "master_rndc-key"; };
};
然后在主服务器的主配置文件中添加如下行：
include "/etc/master_rndc.key";
最后，在rndc控制端就可以根据主从的签名文件，生成自己的密钥文件了，文件如下：
/etc/rndc.conf
key "master_rndc-key" {
algorithm hmac-md5;
secret "FOgSrUhEdprHOHlOgajsBQ==";
};
key "slave_rndc-key" { /*…*/ };
options {
default-key "master_rndc-key";
default-server 192.168.10.112;
default-port 953;
};
server 192.168.10.112 {
key "master_rndc-key";
};
server 192.168.10.111 {
key "slave_rndc-key";
};
然后，就可以使用rndc命令，对主从服务器进行相应的操作了。
3.5 DNS RRL
DNS响应速率限制[6]，通过它可以缓和DNS反射/放大攻击的影响。
rate-limit {
responses-per-second 5;
window 5;
};
编写一个获取解析的shell脚本，内容如下:
while :
do
dig @192.168.10.111 +short +tries=1 +time=1 bbs.test.cn a
done
用bash直接运行该脚本，可以看到结果：
# source dig111.sh
192.168.10.112
192.168.10.112
……
得到的都是正确的解析，如果换个dig命令，想获取更多的内容，也就是所谓的放大。如果通过分布式地执行，这时候就会给服务器带来很大的压力。
将攻击的IP换成192.168.10.112，这台DNS服务器做了RRL，这时候看到的效果如下：
192.168.10.112
192.168.10.112
192.168.10.112
192.168.10.112
192.168.10.112
;; Truncated, retrying in TCP mode.
192.168.10.112
;; connection timed out; no servers could be reached
192.168.10.112
192.168.10.112
……
可以看出，通过RRL的设置，客户端的解析请求速率做了限制，，能对相应的放大攻击起到一定的缓和。
3.6 本章小结
本章主要从DNS自身的高级特性以及安全方面进行研究以及实践，如基于视图的分离解析配置；还有针对主从服务的域传送安全的事务签名配置，提高主从的安全性；另外，针对最近一直很火的DNS放大攻击，以及国内开放递归的DNS数量巨大，提出的一种递归限制的配置，如果是权威DNS，最好禁用递归；其次，用rndc管理DNS，可以提高DNS服务本身的安全；最后，对响应速率进行限制，可以缓和放大/反射等攻击。
第4章 DNS安全加固辅助策略
DNS&BIND官方手册上提供的一些安全配置可以让DNS安全得到一定的保障。为了进一步提高DNS的安全性，本章对linux防火墙iptables[8]做了针对性研究，并结合SELinux和BIND官方补丁包对DNS做出了更好的安全加固。
4.1 Iptables与linux内核参数调优
1.使用ipset简化iptables配置,更好地管理iptables配置。
ipset通过将一些IP地址统一的加到一个组里面，在写规则的时候，只需要针对这个组写。
iptables -A INPUT -s 192.168.10.112 -p icmp -j DROP
ipset -N badips iphash
创建了一个新的ipset集合叫做 badips
iptables -A INPUT -m set --set badips src -p icmp -j DROP
ipset -A badips 192.168.10.112
ipset -A badips 192.168.10.111
iptables -nL --line-number // iptables规则并没有改变.
ipset del badips 192.168.10.111
结合ipset和iptables,将iptables的规则整理一下，除了要添加特殊的规则，以后就几乎不要修改iptables策略了。
当然，端口也可以处理。
ipset -N servers ipmap –network 10.10.10.0/16
ipset -A servers 10.10.10.1
ipset -A servers 10.10.10.2
ipset -N ports portmap –from 1 –to 1024
ipset -A ports 21
ipset -A ports 22
ipset -A ports 25
ipset -B servers 10.10.10.2 -b ports
iptables -A FORWARD -m set –set servers dst,dst -j ACCEPT
iptables -A FORWARD -j DROP
2.国内的一些IP,在编写脚本的时候可以用到,如果需要针对某个国家来处理相关的内容的话，可以拿这个表里面的IP做处理。
http://www.ipdeny.com/ipblocks/data/countries/cn.zone
3.防SYN flood 攻击
通常，有两种简单的方法可以防御SYN Flood攻击。一是缩短等待时间( SYN Timeout)并增大队列的SYN包最大容量( tcp _max_SYN _backlog)，二是设置SYN Cookie。但是，这两种方法只能对付比较原始的SYN Flood攻击。缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效，而SYNCookie依赖于对方使用真实的IP地址。如果攻击者以每秒数万条的速度发送SYN报文，同时利SOCK_RAW等工具随机改写IP报文中的源地址，那么上述方法显然无法生效。
简单防SYN洪水攻击iptables规则:
iptables -I FORWARD 1 -p tcp --syn -m limit --limit 1/s -j ACCEPT
客户机访问 dns服务器，如果需要记录日志的话，当然需要在dns服务器上面进行日志记录
iptables -I INPUT -p udp --dport 53 -j LOG --log-tcp-options --log-tcp-sequence
如果需要在NAT转发上面设置 IPTABLES日志，需要在 FORWARD链上面添加日志记录的规则!
4.防ping的iptables规则
iptables –t filter -A INPUT -p icmp -j REJECT --reject-with icmp-host-unreachable
虽然，禁ping的方法很多，直接基于icmp将对应的包DROP掉;或者修改内核参数icmp_echo_ignore_all,虽然ping不通,但是返还给客户机的效果同IP不存在是不一样的!对这些返回信息做过对比研究的人，一下就明白你那边做了什么设置.更详细地说明，下面对几个内核参数的调整有说明。
5.取消IPV6
另外，如果没有用到ipv6的话，建议取消.
/etc/sysconfig/network
IPV6_NETWORKING=no
vi /etc/modprobe.d/ipv6.conf ///文件名没所谓!
blacklist ipv6
alias net-pf-10 off
alias ipv6 off
6.几个ipv4下的内核参数的解读。
6.1. icmp_echo_ignore_all
默认值是0!如果改成1,就ping不通了!建议是0！虽然ping不通,但是返还给客户机的效果同IP不存在是不一样的!
6.2. icmp_echo_ignore_broadcasts
默认值是1! ping广播!如果改成0!那么ping 10.255.255.255,设置成0之后,别人ping广播地址"ping -b 10.1.1.255"的时候,本机就不会主动回应了,也就不会暴露自己了,防止被攻击!如果是IP不存在!它回应 Destination host Unreachable!如果是IP存在，而加了:“iptables -t filter -A INPUT -p imcp -j DROP[REJECT]”，如果是REJECT,客户机ping的时候,就回应: Destination port Unreachable!也可以知道,你的主机是可用的!如果是DROP,就和上面的icmp_echo_ignore_all设置成0的效果一样!同样是暴露自己!所以，最后建议添加：“iptables -t filter -A INPUT -p icmp -j REJECT --reject-with icmp-host-unreachable”客户机ping的时候,就回应: Destination host Unreachable!可以骗一些低级的扫描工具!
6.3. ip_default_ttl
windows默认的128，linux默认是64!那么可以伪装成 128,认为是windows系统!
6.4. ip_local_port_range
允许系统打开的客户端端口!
cat ip_local_port_range //可用的客户端的范围
32768 61000
7.针对iptables规则太多的小调整.
在启用了iptables的情况下，iptables会把所有的连接都做链接跟踪处理，这样iptables就会有一个链接跟踪表，当这个表满的时候，就会出现上面的错误。iptables的链接跟踪表最大容量为/proc/sys/net/ipv4/ip_conntrack_max，链接碰到各种状态的超时后就会从表中删除。
报错有两种解决办法:
(1)加大 ip_conntrack_max 值
net.ipv4.ip_conntrack_max = 393216
net.ipv4.netfilter.ip_conntrack_max = 393216
(2)降低 ip_conntrack timeout 时间
vi /etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 300
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
8.防SYN洪水攻击的几个简单参数
8.1 tcp_fin_timeout
等待连接的超时时间,默认时间是60秒!"echo 5 > tcp_fin_timeout"
8.2 tcp_max_syn_backlog
默认可以接收多少的syn!默认是1024!
8.3 tcp_syn_retries
重试次数!
8.4 tcp_syncookies
只让一个IP地址占用一行的记录!默认是1,就是打开了!不要设置成0,否则可能一个IP就可以将表占满!
8.5 tcp_synack_retries
服务器回应重试时间! "echo 0 > tcp_synack_retries"
9.更多需要参阅内核官方的说明文档。
这儿只是几个典型的调优参数，主要是针对网络安全方面的内容。
4.2 SELinux和DNS
SELinux(Security-Enhanced Linux)是美国国家安全局（NSA）对于强制访问控制的实现，是 Linux上最杰出的新安全子系统。NSA是在Linux社区的帮助下开发了一种访问控制体系，在这种访问控制体系的限制下，进程只能访问那些在他的任务中所需要文件。哪些域可以访问哪些上下文.也就是哪些进程可以访问哪些文件.
Bind的 SELinux 文件类型。“named_zone_t” 这个文件类型用于主区域文件。其他服务不能修改此类型的文件。“named_cache_t” 默认情况下 named进程可以读写这种类型的标记的文件，无需另外的布尔值设置。
Bind的布尔变量。“named_write_master_zones”，当关闭这个布尔变量时不允许 named 进程读写主区配置文件。“named_disable_trans” 当关闭这个布尔变量时不保护 named进程。SElinux对 Bind DNS服务器的限制不多。默认情况下 SElinux的策略文件规定不允许 named进程写主区配置文件。如果允许named进程更新主区配置文件，需要开放下面的布尔值变量：
#setsebool -P named_write_master_zones=1
也可以禁止 SElinux保护 named守护进程，使用命令：
# setsebool -P named_disable_trans=1
然后重启 named进程：
#service named restart
SELinux的安全防护措施主要集中在各种网络服务的访问控制。对于像 Apache 、Samba、NFS、vsftp、MySQL、Bind DNS服务来说，系统默认配置的 SELinux仅仅开放了最基本的运行需求。至于连接外部网络、运行脚本、访问用户目录、共享文件等，必须经过一定的 SELinux策略调整才能充分发挥网络服务器的作用。很多用户一直觉得 SELinux的安全级别设置十分麻烦，因此有人经常关闭 SELinux
不让其工作，这样做是不对的。其实安全性和应用性就是有这种矛盾，系统管理员要寻找一定的安全中间点。
图4-1 SELinux环境部署图
DNS的实验架构如图4-1所示，将主从服务以及rndc都启动selinux服务，然后重启DNS服务，并查看各个配置文件的上下文信息，并针对主配置文件和区域数据配置文件设置特定的上下文，这时候named进程就能正常地访问需要的配置文件，DNS服务在selinux服务下也能正常地提供服务，并且在selinux下，服务本身的安全又得到了新的提升。
4.3 BIND源码补丁
关于如何为BIND源码包打补丁，以及根据源码包安装DNS服务，参阅附录，里面有具体的配置过程，并将所有的命令列表列出。可用性很高。
从官网上将补丁文件下载下来，如rpz+rl-9.9.2-P2.patch，然后在BIND软件根目录下运行“patch -s -p0 -i rpz+rl-9.9.2-P2.patch”，然后对软件进行配置，编译和安装即可。具体的操作过程，可以参阅附录。
4.4 本章小结
本章抛开DNS本身，利用操作系统本身的安全加固，以及iptables防火墙的配置，防洪水攻击，内核参数的调优等；还有，SELinux对DNS做的一些安全保护，都将它们引入了。最后，还研究了针对BIND的源码打补丁包。总之，全部是为了进一步加强DNS的安全。
总结与展望
首先，本文里面的实践都是基于linux平台，没有由浅入深地讲解和实践。若想完全利用起来，需要对linux系统比较熟悉，并且需要有一定的DNS&BIND基础。总的来说，本文从DNS本身出发，从一些高级的配置加强DNS的安全，并从其他方面分析了DNS安全方面能做出的更多努力。
DNS安全方面，还需要进行更深入和更有技术含量的研究，包括DNS&BIND安全配置、物理防火墙配置、攻击检测工具研究、垃圾流量分流等。通过本文，能对DNS安全有一定的了解，但还远远不够。路漫漫，其修远兮，吾将上下而求索。
参考文献
[1] Paul Albitz, Cricket Liu. DNS&BIND, 5th Edition[M]. O’Reilly, 2006.05.
[2]Cbris McNab. Network Security Assessment[M]. O’Reilly, 2006.01.
[3] Thijs Rozekrans. Defending against DNS reflection amplification attacks[D], 2013.02.
[4]刘威. DNS放大攻击的研究[J].深入研究,2010.02
[5]邵明珠，解瑞云，李伟峰. DNS安全分析及防御技术研究[J],2011.09
[6] Redhat. Response Rate Limiting in the Domain Name System (DNS RRL)[R](http://www.redbarn.org/dns/ratelimits)2012.06
[7] US-CERT.DNS Amplification Attacks [R] (http://www.us-cert.gov/ncas/alerts/TA13-088A)2013.03
[8]（美）MichaelRash著. Linux防火墙[M]. 北京市：人民邮电出版社, 2009.06.
[9]绿盟科技(http://www.nsfocus.com/)
[10]个人博客站点1 ( http://blog.csdn.net/c__ilikeyouma)
[11]个人博客站点2 ( http://lin-credible.github.io/)
附录
1.打补丁包
wgetftp://ftp.isc.org/isc/bind9/9.9.2-P2/bind-9.9.2-P2.tar.gz
//下载源码包
wget ftp://ftp.isc.org/isc/bind9/9.9.2-P2/bind-9.9.2-P2.tar.gz.sha512.asc
wget http://ss.vix.su/~vjs/rpz+rl-9.9.2-P2.patch
service named stop //停止本地服务.
tar xf bind-9.9.2-P2.tar.gz -C /usr/src/
cd /usr/src/bind-9.9.2-P2/
patch -s -p0 -i /taolinran/bind/rpz+rl-9.9.2-P2.patch
yum install -y openssl* //DNSSEC需要
./configure --prefix=/usr/local/bind --with-openssl=/usr
make && make install
cd /usr/local/bind/
cd sbin/
yum remove bind bind-devel
export PATH=$PATH:/usr/local/bind/sbin:/usr/local/bind/bin
cd /usr/local/bind/
mkdir chroot
userdel –r named
groupadd named
useradd -s /sbin/nologin -d /usr/local/bind/ -g named named
passwd -l named
cd chroot/
mkdir {dev,etc,var/{log,run,named}} -p
cd dev/
ls -lL /dev/zero /dev/null /dev/random
mknod null c 1 3
mknod random c 1 8
mknod zero c 1 5
cd /usr/local/bind/chroot/etc/
cp /taolinran/named_bak/chroot/etc/* ./
cp /taolinran/named_bak/chroot/var/named/* ../var/named/
/usr/local/bind/sbin/named-checkconf ./named.conf
echo $? //0，验证上一条命令的返回结果，如果是0，则运行成功.
/usr/local/bind/sbin/named-checkzone test.cn ../var/named/test.cn.lan10
/usr/local/bind/sbin/named-checkzone test.cn ../var/named/test.cn.lan192
id named
pwd ///usr/local/bind/chroot
chown root.named ./* -R
/usr/local/bind/sbin/named –u named -c ./etc/named.conf -t /usr/local/bind/chroot/
ps aux |grep name
lsof -i:53
host wordpress.test.cn 192.168.10.112
能正常解析，安装成功。
2.实验中主服务器的主配置文件
该配置文件，做好了主从配置，并基于TSIG，做了简单的分离解析，并结合了SELinux，同时配置了rndc。从服务器的主配置文件，以及主从的区域数据配置文件略。相应的实验数据以及所有配置文件[11]，参见参考文献。
acl zone1 {
192.168.10.78;
};
acl zone2 {
10.10.24.79;
};
key "master_rndc-key" {
algorithm hmac-md5;
secret "FOgSrUhEdprHOHlOgajsBQ==";
};
controls {
inet 192.168.10.112 port 953
allow { 192.168.10.78; } keys { "master_rndc-key"; };
};
key lan192 {
algorithm hmac-md5;
secret "RQXeMPEXAj5Mx37pzJ044A==";
};
key lan10 {
algorithm hmac-md5;
secret "TUklzhkwYd6roL7tO4BE5Q==";
};
options
{
listen-on port 53 { 192.168.10.112; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
query-source port 53;
query-source-v6 port 53;
recursion no;
additional-from-cache no;
allow-query { none; };
version "None of your business";
notify yes;
rate-limit {
response-per-second 5;
window 5;
};
};
view "lan192" {
match-clients { key lan192;zone1; };
allow-query { zone1; };
recursion yes;
additional-from-cache yes;
server 192.168.10.111 { keys{lan192;}; };
zone "test.cn" IN {
type master;
file "test.cn.lan192";
allow-transfer { key lan192; };
also-notify { 192.168.10.111; };
};
zone "10.168.192.in-addr.arpa" IN {
type master;
file "192.168.10.zone";
allow-transfer { key lan192; };
also-notify { 192.168.10.111; };
};
};
view "lan10" {
match-clients { key lan10;zone2; };
allow-query { zone2; };
recursion yes;
additional-from-cache yes;
server 192.168.10.111 { keys{lan10;}; };
zone "test.cn" IN {
type master;
file "test.cn.lan10";
allow-transfer { key lan10; };
also-notify { 192.168.10.111; };
};
zone "10.10.10.in-addr.arpa" IN {
type master;
file "10.10.10.zone";
allow-transfer { key lan10; };
also-notify { 192.168.10.111; };
};
致 谢
经过这段时间的学习和研究，关于DNS的安全方面，做了一个还算全面的了解和实践。总得来说，研究只是研究，要防止黑客的攻击，除了技术方面，还得从其他很多方面做出思考。最重要的是，DNS的管理员要时刻关注DNS的安全动态，并深入研究它，永远杜绝DNS的攻击是不可能的，但是要总结经验，自己的手里有枪，比防弹衣更安全。感谢开源的世界，让我觉得这个平坦的世界知识对我们每个人都是公平的，同时开源也带来了很多的挑战，就是需要不断地学习，不断地努力，不然，你会发现，这个世界的另一边，有很多人比你厉害很多很多。
PS： 感谢好多好多。。。好多好多人，还有自己，文章很烂很烂，我要对这个话题负责，我会抽空再多研究些的！
