首页
社区
课程
招聘
如何确保你的DNS服务器免受劫持困扰
发表于: 2015-9-13 21:53 2216

如何确保你的DNS服务器免受劫持困扰

2015-9-13 21:53
2216
新闻链接:http://security.zdnet.com.cn/security_zone/2015/0911/3062584.shtml
新闻时间:2015年09月11日
新闻正文:
太多太多的DNS服务器被恶意人士加以劫持,并用于实施DDoS攻击。在今天的文章中,我们将共同探讨如何确保自身免受此类恶意行为的影响。
虽然现在看来已经可以算是陈年旧事,但就在互联网刚刚诞生的约二十年前,我们曾面临着一个巨大的难题:邮件服务器太过友好。
简而言之,大多数邮件服务器允许任何人进行接入,并将邮件发送给任何收件者。要实现这一切,我们甚至不需要作为邮件服务器的用户,或者只需要费一点小劲来将自己伪装成用户即可。
攻击者能够利用邮件服务器的邮件SMTP接收端口(TCP端口25)来实现连接,并模仿全部SMTP服务器用于交换邮件的内部命令发送各类操作(通过telent、脚本或者其它程序)。如此一来,黑客将能够伪造电子邮件、宣称其来自邮件服务器所托管的某位合法用户并将任意邮件内容发送给任意收件人。
垃圾邮件发送者会寻找这类“开放转发”服务器,并将成千万甚至上亿封垃圾邮件发送到世界各地。全球技术人员——以及邮件服务器供应商——花了约二十年时间来强制要求所有始发邮件必须进行实际来源验证,且由认证用户所发出。
然而在多年之后,类似的开放转发问题又出现在互联网领域的另一大基础性技术当中,即DNS。攻击者经常会利用配置不当的DNS服务器向查询客户端发送无效IP地址——或者发送大量虚假流量以实施DDoS攻击。
  利用DNS实施DDoS攻击
DDoS以及其它攻击者多年来一直在利用DNS实施他们的邪恶阴谋,但在过去几年当中,这种状况出现了愈演愈烈之势。
最近一段时间来,多数大规模DDoS攻击者开始频繁利用DNS“放大”技术。如果大家对其具体实现方式及背景信息感兴趣,可以查看US-CERT、互联网系统联盟以及CloudFlare上的相关资料(英文原文)。
最终,DNS服务器供应商与协议开发商不得不采取对应措施,而这一切正如当年SMTP邮件供应商所作出的保护努力一样。其中包括更理想的默认设置及新型防御机制。不过遗憾的是,DNS服务器——虽然它们看起来可能运行良好——仍然被人们所忽视,而且继续保留着攻击者不希望管理方发现的大量安全漏洞。
  禁用开放转发DNS服务器
每一家企业客户都能够轻松实现的保护手段就是限定自身DNS服务器对哪些以及来自谁的请求做出响应。对于内部DNS服务器而言,我们需要确保其只会针对来自内部计算机或者其它认证DNS服务器的查询给出DNS响应。
即使是在外部环境下,面向公众的DNS服务器也不应该以无脑方式对所有请求做出响应。如果大家的DNS服务器托管于*.example.com地址,那么绝对不会有合法用户在该域名之外进行域名地址查询。如果大家的DNS服务器当前会对来自任何使用者的全部查询做出响应,特别是来自任意域名的请求,那么这就是一台开放转发DNS服务器——相信我,这绝不是什么好事。
为了确保我们的DNS服务器不被划归为开放转发一类,并对其进行严格锁定并保证其合法运作,请将其IP地址输入到以下各DNS开放转发检测服务中进行安全性测试:
· Open Resolver Project

· Open DNS Resolver Check Site

· DNS Expertise - The Measurement Factory

· DNS Inspect

  DNS响应速率限制
作为防止自有DNS服务器被用于DDoS攻击活动的最佳防御手段之一,我们应当对其进行响应速率限制(简称RRL)。RRL主要面向权威DNS服务器(即那些应当对一个或者多个域名进行响应的DNS服务器),且允许DNS管理员针对DNS响应流量作出有效速率限制。尽管在默认情况下并未启用(但绝对应该被启用!),我们可以在BIND 9.9(及其后续版本)当中找到RRL,其同时也作为微软即将推出的Windows Server 2016 DNS服务的组成部分。
如果大家的DNS服务器并不支持RRL,则可以尝试利用其它备选方案实现同样的效果,包括使用防火墙速率过滤或者其它反DDoS服务来保护自己的DNS。
  禁用向上转介响应
对于大多数DNS来讲,当某台非递归权威DNS服务器收到一条未经认证的域名查询时,该DNS服务器会直接将该查询客户重新定向至顶级域名DNS服务器(能够在文件托管‘root hints’当中按照名称及IP地址进行排列)。这是一种较为礼貌的作法,类似于“嘿,我不知道答案是什么,但我建议你到那边试试运气。”
但事实上,这种方式相当于因为个人原因而毁掉大家的生活,而DNS放大攻击的出现也使得这种使用root hints的方式饱受诟病。BIND长久以来一直建议大家禁用这一向上转介行为。微软公司计划在其Windows Server 2016当中默认禁用向上转介机制,而大家也可以通过删除该root hints文件(具体位置为c:windowssystem32DNScache.dns)的方式在其它Windows Server早期版本中禁用该功能。
  检查所有DNS服务
针对计算机及设备用于接收连接的TCP或者UDP端口53进行扫描,从而检查所有运行有DNS服务的计算机及设备并对其进行安全配置。一般来讲,大家会发现其中存在着一些运行有计划外DNS服务器的装置及网络设备(例如无线路由器等)。
  开门揖盗最为愚蠢
DNS协议自从1983年诞生以来就一直拥有良好的实际表现。它虽然也经历过被滥用以及后续更新作为补救的状况,但总体而言,它仍然扮演着保障互联网正常运转的核心角色。不过我们绝不能够对现有安全水平盲目自满,特别是在DNS方面。
在文章的最后,我要提醒大家千万别让自己的DNS服务器重复当初公共邮件服务器的覆辙——作为现代IT世界中的一员,我们不可能再拿出十年时间来解决那些早就该进行修复的问题。

[注意]APP应用上架合规检测服务,协助应用顺利上架!

收藏
免费 0
支持
分享
最新回复 (0)
游客
登录 | 注册 方可回帖
返回
//