校园网解析 DNS故障及安全防护策略

 目前多数校园网都同时接入多个运营商，多出口路由和域名解析问题曾经困扰着不少大学校园网管理人员。

    最近几个月以来，一些校园网的用户和管理人员发现学校的DNS服务器陆续出现无法正常提供递归域名解析服务的情况，也有一些校园网发现一些知名的网站(如www.baidu.com,www.qq.com)域名解析出现奇怪的现象，很多用户和管理员面对这些现象仍然很困惑。

    域名系统的安全性一直是互联网运行安全的关键之一。在国际上，DNSSec作为域名系统安全的一项重要措施，近年来也出现了新的进展。这些新的技术是否可以解决我们校园网域名解析面临的安全问题？

    为此，我们组织了关于DNS安全防护策略的讨论，本期沙龙相聚在合肥中国科技大学，邀请清华大学、中国科技大学、郑州大学、上海聚川技术公司等相关专家，介绍和分析如何部署DNS安全防护措施，更好地保障学校的网络运行和安全。

    DNS安全的背景及事件分析

    DNS的安全问题不容忽视！不要让DNS成为校园网安全的短板！

    问题DNS服务攻击具有以下的特点：利用最少的资源，发动最具破坏力的攻击、利用最少的攻击，获得最大的收益、可以轻易绕过严密安全防护。

    当前，DNS面临的风险包括：拒绝服务攻击、域名劫持、错误的配置、软件漏洞、缓存污染、中间人攻击、DNS恶意指向。

    这些风险中引发的事件，多数由于管理环节的疏漏，以及DNS配置复杂性、缺乏一个有效的快速更新机制等原因引起的，下面分别举例说明：

    Key1拒绝服务攻击

    攻击使用大量的请求或是流量湮灭DNS服务器，使得DNS服务无法正常提供服务。

    典型案例：

    暴风影音攻击事件——蝴蝶效应

    2009年5月19日晚，由于暴风影音的域名出现无法解析的故障，而用户端的暴风影音软件持续发送大量的DNS解析请求形成了对DNS递归查询服务器的Ddos攻击，导致多省的网络服务中断。

    事件背景：

    DNSPod——免费的动态域名解析服务提供商，拥有ns1.dnspod.net至ns6.dnspod.net六台DNS解析服务器，为30万个域名提供权威解析服务。每天的解析请求达20亿次。

    暴风影音——国内著名的免费媒体播放软件，拥有1.2亿的用户装机量。DNSPod的用户之一。

    事件回放：

    1.游戏私服互斗，导致攻击DNSPod的服务器，瞬间的攻击流量达10G；

    2.电信的IDC为避免影响网络，在路由上禁封了DNSpod的IP地址，导致DNSPod无法提供正常的DNS解析服务；

    3.暴风影音软件会定期自动访问自己的主站获取信息，由于域名无法解析就持续发送解析请求；

    4.大量的暴风影音用户持续发送域名解析请求导致递归解析服务器的资源耗尽，形成拒绝服务攻击；

    5.用户无法获得DNS解析服务，导致网络应用瘫痪。

    事件分析：

    1.DNSPod的管理和IDC的责任心问题。

    2.暴风影音的管理和更新机制问题。  Key2域名劫持

    攻击者通过各种手段修改权威服务器上域名的NS或者A记录的指向，达到劫持该域名的目地。

    典型案例：

    百度域名劫持事件——社会工程学攻击

    2010年1月12日百度域名被劫持，导致多个地区在长达4小时内无法正常访问百度，有的地区在24小时后才恢复正常。

    事件背景：

    Register.com——美国域名注册代理服务商，提供.com的域名注册服务，你只需提供一个有效的邮件地址和相应的费用便可在Register.com上注册你想要的域名(前提是该域名还未被别人注册)，之后你可以随时使用该邮箱和设置的密码登录Register.com的网站修改你注册域名的ns记录或A记录的指向。

    百度——国内最大的搜索服务提供商，baidu.com域名的拥有者，该域名通过Register.com公司注册。

    事件回放：

    攻击者冒充百度的代理商联系Register.com公司的客服人员(通过在线聊天软件)要求修改注册时使用的邮箱。

    Register.com公司的客服人员在经过不完善的认证后将baidu.com域名的注册邮箱改成了antiwahabi2008@gmail.com；

    黑客使用密码重置功能获得baidu.com域名管理帐号密码，并登录系统修改了baidu.com的域名指向；

    百度发现问题后无法用自己的帐号登录修改域名指向，只能通过联系Register.com公司的客服来进行处理，由于时差的关系联系进展缓慢，导致问题出现4个多小时后才得以解决。

    事件分析：

    1.域名注册的管理问题：商业化运作，管理混乱，没有监管机制；

    2.根域名管理权问题：根域名控制在少数一些国家手中。

    Key3配置错误

    错误的配置信息导致DNS服务器无法提供正常的服务，DNS的配置是目前网络服务中少有的几个难理解的配置之一！

    典型案例：

    瑞典顶级域名.se故障

    2009年10月12日晚瑞典顶级域名服务器出现故障，导致一百多万使用.se结尾的域名无法正常解析，一些地区直到48小时候才能正常解析.se域名

    事件回放：

    1.2009年10月12日瑞典顶级域名.se服务商的管理员象往常一样使用脚本对域名服务器.se的zone文件进行更新。

    2.更新后发现所有.se的域名无法正常解析

    3.管理迅速检查原因，发现是因为脚本在编辑存盘时把原本应该有的.给不小心删掉了，这个错误直接导致.se从根域名服务器数据中消失。

    4.虽然管理员迅速的对zone进行了修复，但是扩散出去的数据导致一些地区在48小时候才重新认为.se是有效域名。

    事件分析：

    1.DNS配置文件的复杂性；

    2.DNS缺乏一个有效的快速更新机制。Key4软件漏洞

    DNS服务软件本身存在安全漏洞，导致DNS无法正常提供服务。

    典型案例：

    Bind9漏洞导致.com无法正常解析

    2011年3月底，我们陆续接到一些院校投诉其DNS解析服务存在故障，经常无法正常解析域名。最后查明是bind9软件存在条件竞争漏洞导致的。

    事件背景：

    DNS安全扩展(DNSSEC)蜒是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535)，它利用数字签名的技术来保证域名解析的权威性，以保证域名不受中间人的攻击或缓存污染。

    Verisign公司——域名服务商，.com域名的实际维护者，DNSSEC协议的发起人之一。

    Bind软件——DNS服务程序，目前网络上使用最广泛的DNS软件，教育网的占有率在90%以上。

    事件回放：

    1.ISC在Bind8.1.x版本后开始支持DNSSec，并在Bind9版本后默认打开了DNSSec的查询，Bind9.6-ESVR3之前的版本在实现DNSSEC查询的过程中存在一个条件竞争漏洞；

    2.2011年3月下旬，Verisign公司开始向13台根域名服务器发布.com域名的DNSSEC数据；

    3.根域名服务器上的DS数据诱发了Bind软件的漏洞，导致递归服务器的非DS请求有50%的几率被根服务认为是无效请求而返回SERVFAIL应答。这直接导致用户端访问.com的域名有一半的几率会失败；

    4.3月31号，ISC发布安全公告，并更新了Bind9软件。

    事件分析：

    1.DNS软件是否需要随时更新？

    2.DNS软件更新机制。