服务器评测
DNS Server（BIND）
1、DNS服务器的主要风险
a> DNS信息泄露（通过DNS信息猜测网络架构）；
b> 非法取得DNS配置信息；
c> 通过BIND进程获得主机权限；
d> 入侵DNS可以轻易地进一步伪装自己的身份（比如说查找没被使用的IP，某些情况下使用这些IP就可以绕过某些使用网段的验证），所以这是一个很好的first stage；
2、对应的防御手段：
a> 使用TSIG（Transaction SIGnature）事务签名控制访问；
b> 限制zone文件的传输（master只能传给slave，slave不传给任何人，并且最好使用TSIG而非IP作为限制条件）;
c> 在权威DNS服务器上限制递归式DNS查询（bind默认就是禁止的，也可以配置成对内部机器开放），让专门的Local DNS Server去响应递归式查询，这样可以防止cache注入和name伪造攻击，而且对性能优化也是很有好处的。；
d> chroot BIND的进程（RHEL上的bind-chroot包提供此功能，www.linuxidc.com 此包被@DNS Server包含。启用以后用ps -ef能看到named -t /var/named/chroot）；
e> 记录日志，必要的话记录到远端主机上（bind提供了非常灵活的日志功能，可以定义哪些信息category被记录到哪儿channel）；
3、BIND从版本9才开始支持DNSSEC和TSIG，重写了全部的底层代码，带来了更高的安全性和更低的性能（可参见http://my.opera.com/jlake/blog/show.dml/489422）；
4、DNS服务的结构：
a> zone文件是一个DNS服务器可以响应的命名空间，一个zone文件中通常包含一个域名和此域名下的子域名；
b> master DNS服务器包含第一手的zone文件，slave服务器通过zone transfer从master取得zone文件；
c> master和slave给前来查询的客户端做出的属于自己的zone的响应被称作“权威应答”，而被cache在Local DNS的响应被称为“非权威应答”；
d> DNS查询分为递归式和迭代式；
e> 递归式查询。通常用于权威服务器。服务器在收到查询后，如果本身不是此查询的“权威域”，则会让客户端去向另一个DNS服务器去查询（通常是root DNS）；
f> 递归式查询。DNS服务器收到客户端查询后帮助客户端完成迭代查询后直接把结果返回给客户端。这样客户端只用“一跳”就完成了DNS查询。通常用于local DNS；
g> master和slave必须响应迭代式查询。对于递归式查询，它可以选响应或者不响应；
h> cacheing-only的DNS服务器不提供任何zone文件的权威数据。通常就是local DNS服务器。一般用于帮助客户端完成递归式查询；
5、DNS同时监听53 UDP端口和53 TCP端口，UDP的优先；
6、bind的进程名称是named；配置在/etc/named.conf（root可写，其它人可读）；zone存放在/var/named/（默认所有人可写）；
7、针对DNS的攻击：
a> 第一类攻击是遍历DNS信息，为下一次攻击做准备。攻击者也许只是不断地进行DNS查询，或是请求zone transfer（嗅探得到之），或者对IP地址进行PTR反查。用于猜测网络中存在哪些IP，以及它们扮演的角色。防御的手段是限制zone的传输和使用分离的命名空间；
b> 更危险的攻击是缓存注入（cache poisoning）或者名称欺骗（name spoofing）。前者是往local DNS的缓存中注入错误的解析地址（一般会设为很长的TTL），导致用户被引向错误的服务器。后者则是抢在真正的权威应答之前伪造一个应答回给查询者，或是干脆伪装成权威应答。解决此类问题的方法是限制递归查询，www.linuxidc.com 并且部署DNSSEC（Domain Name System Security Extensions）（RFC2535描述）（在bind 9中实现）；
c> 第三类攻击最为危险。攻击者可能控制了更高一级的DNS Server（如root），由于较低级的权威DNS的控制者是更高一级的DNS Server指定的，如果更高级的DNS被控制了，那么较为低级的DNS Server也就被绕过去了（攻击者可以指定自己的机器作为权威的服务器）。
8、bind可以基于IP、TSIG KEY来制作ACL（Access Control List）。ACL使用匹配即退出机制。（和2－b联系起来看）；
9、TSIG：
a> TSIG（Transaction SIGnature）是一个使用对称式加密算法对消息进行签名（非加密，所以依然是明文）的协议，主要用于DNS；不使用非对称式加密的主要是出于速度的考虑，所以签名也不是通常意义上的数字签名，而是类HMAC的带密钥的摘要算法；
b> TSIG协议中带有一个时间戳来说明此消息的过期时间，用于防止重放攻击；因此通信的双方最好是配置安全的NTP服务；
c> TSIG机制在RFC2845中描述；
d> 命令行工具dnssec-keygen可以帮助我们制作TSIG KEY；由于/etc/named.conf是全局可读写的，所以最好把key单独存放在一个文件里，然后用include包含进来；
e> 虽然TSIG并不承担加密的功能，但bind仍然可以基于TSIG做访问控制；
f> TSIG的弱点一：对称密钥难于管理（每一台机器被攻破就要全部更换）这也限制了TSIG在整个互联网的使用，通常只在企业内部使用；
g> TSIG的弱点二：只能提供“Next-hop”安全，提供不了“端对端”安全（因为不是所有的DNS都部署了TSIG），所以他验证不了递归DNS查询，只能认证迭代DNS查询和master和slave之间zone文件的传输。如果要提供端对端的安全，需要使用DNSSEC；
h> TSIG的弱点三：另一个TSIG的设计目标是此过程可以被整合到标准的C gethostname和gethostbyname方法里面去，但目前标准的方法还是不支持TSIG的；
10、Domain Name System Security Extensions (DNSSEC)DNS安全扩展（http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions）的主要想法是让客户端对DNS Server（从root直到最终的权威DNS服务器）进行认证；
11、Local DNS也可以配置成某些域的权威应答，这样一来可以加快查询速度，二来也可以在Internet网断掉的时候依然提供服务；bind也可以设置只让某些IP进行查询（allow-query白名单），这样来建立一个内部的DNS Server；
12、bind可以通过bogus选项把一些DNS服务器的IP列入黑名单，从而不相信它们回答的DNS应答。也可以通过blackhole选项把一些客户端IP放进黑名单，从而不响应它们的查询请求。blackhole和allow-query的区别是前者完全没反应，后者会回复refuse响应；
13、有一种需求叫做“view”，意思是对不同来源IP的查询给予不同的应答。可用于CDN用的智能DNS解析。以前这种需求需要多个DNS Server来满足，现在bind 9中的可以给一个zone配多个view来满足此需求。view也是使用匹配即退出机制。如果一个zone使用了view，那么所有的zone都应该在view里；
14、CHAOS类记录。bind在9.4版本之后真正支持了CHAOS记录（用于提供局域网内的DNS记录，详见http://victor.se/bjorn/its/chaos-dns.php），在这之前CHAOS记录只作为查询bind版本的一个途径。可以通过查询CHAOS类的version.bind和authors.bind的TXT记录来获得bind的版本信息。但是有经验的管理员会把这些信息隐去以防御攻击。注意是隐去而不是更换成别的字符，因为若能查询出version.bind（无论结果是什么）则已经说明此bind版本大于8.2，能查出authors.bind则说明此bind大于9.1.0；
15、bind的日志十分灵活，可以指定记录15类信息（category）。而在channel中可以设定记录的错误级别，也可以指定记录到syslog或者文件或者标准错误输出中去。每个channel可以指定要记录的category，互相之间可以重复；
16、SRV（Service record）记录在RFC 2782定义。它可以指定服务的IP和端口，有一些网络服务需要SRV解析的支持，如Session Initiation Protocol (SIP) 和 the Extensible Messaging and Presence Protocol (XMPP) 。详见http://en.wikipedia.org/wiki/SRV_record；
17、Windows操作系统使用一种动态DNS更新的技术让客户端可以自己更新自己的DNS记录，包括A记录和PTR记录，域控制器甚至可以更新SRV记录，这会带来一定的风险。处理的办法是使用TSIG和bind 9中的update-policy机制，这可以让客户端只能更新zone中属于自己的记录。更好的办法是把DHCP服务器也配置上TSIG更新，以让IP和KEY更好地绑定在一起（windows中地DHCP服务器采用的是GSS-TSIG）；
18、DDNS解析。其实就相当于是动态的PTR记录。这个工作也是需要客户端来更新自己的PTR记录和A记录，如上一条所述，这个工作最好是配合DHCP服务器的TSIG校验来做；
