DNS常见攻击与防范
DNS常见攻击与防范
转自:http://www.williamlong.info/archives/3813.html 日期:2015-7-10
随着网络的逐步普及,网络安全已成为INTERNET路上事实上的焦点,它关系着INTERNET的进一步发展和普及,甚至关系着INTERNET的生存。可喜的是我们那些互联网专家们并没有令广大INTERNET用户失望,网络安全技术也不断出现,使广大网民和企业有了更多的放心,下面就网络安全中的主要技术作一简介,希望能为网民和企业在网络安全方面提供一个网络安全方案参考。
DNS的工作原理
DNS分为Client和Server,Client扮演发问的角色,也就是问Server一个Domain Name,而Server必须要回答此Domain Name的真正IP地址。而当地的DNS先会查自己的资料库。如果自己的资料库没有,则会往该DNS上所设的的DNS询问,依此得到答案之后,将收到的答案存起来,并回答客户。
DNS服务器会根据不同的授权区(Zone),记录所属该网域下的各名称资料,这个资料包括网域下的次网域名称及主机名称。
在每一个名称服务器中都有一个快取缓存区(Cache),这个快取缓存区的主要目的是将该名称服务器所查询出来的名称及相对的IP地址记录在快取缓存区中,这样当下一次还有另外一个客户端到次服务器上去查询相同的名称 时,服务器就不用在到别台主机上去寻找,而直接可以从缓存区中找到该笔名称记录资料,传回给客户端,加速客户端对名称查询的速度。例如:
当DNS客户端向指定的DNS服务器查询网际网路上的某一台主机名称 DNS服务器会在该资料库中找寻用户所指定的名称 如果没有,该服务器会先在自己的快取缓存区中查询有无该笔纪录,如果找到该笔名称记录后,会从DNS服务器直接将所对应到的IP地址传回给客户端 ,如果名称服务器在资料记录查不到且快取缓存区中也没有时,服务器首先会才会向别的名称服务器查询所要的名称。例如:
DNS客户端向指定的DNS服务器查询网际网路上某台主机名称,当DNS服务器在该资料记录找不到用户所指定的名称时,会转向该服务器的快取缓存区找寻是否有该资料 ,当快取缓存区也找不到时,会向最接近的名称服务器去要求帮忙找寻该名称的IP地址 ,在另一台服务器上也有相同的动作的查询,当查询到后会回复原本要求查询的服务器,该DNS服务器在接收到另一台DNS服务器查询的结果后,先将所查询到的主机名称及对应IP地址记录到快取缓存区中 ,最后在将所查询到的结果回复给客户端
常见的DNS攻击包括:
1) 域名劫持
通过采用黑客手段控制了域名管理密码和域名管理邮箱,然后将该域名的NS纪录指向到黑客可以控制的DNS服务器,然后通过在该DNS服务器上添加相应域名纪录,从而使网民访问该域名时,进入了黑客所指向的内容。
这显然是DNS服务提供商的责任,用户束手无策。
2) 缓存投毒
利用控制DNS缓存服务器,把原本准备访问某网站的用户在不知不觉中带到黑客指向的其他网站上。其实现方式有多种,比如可以通过利用网民ISP端的DNS缓存服务器的漏洞进行攻击或控制,从而改变该ISP内的用户访问域名的响应结果;或者,黑客通过利用用户权威域名服务器上的漏洞,如当用户权威域名服务器同时可以被当作缓存服务器使用,黑客可以实现缓存投毒,将错误的域名纪录存入缓存中,从而使所有使用该缓存服务器的用户得到错误的DNS解析结果。
最近发现的DNS重大缺陷,就是这种方式的。只所以说是“重大”缺陷,据报道是因为是协议自身的设计实现问题造成的,几乎所有的DNS软件都存在这样的问题。
3)DDOS攻击
一种攻击针对DNS服务器软件本身,通常利用BIND软件程序中的漏洞,导致DNS服务器崩溃或拒绝服务;另一种攻击的目标不是DNS服务器,而是利用DNS服务器作为中间的“攻击放大器”,去攻击其它互联网上的主机,导致被攻击主机拒绝服务。
4) DNS欺骗
DNS欺骗就是攻击者冒充域名服务器的一种欺骗行为。
原理:如果可以冒充域名服务器,然后把查询的IP地址设为攻击者的IP地址,这样的话,用户上网就只能看到攻击者的主页,而不是用户想要取得的网站的主页了,这就是DNS欺骗的基本原理。DNS欺骗其实并不是真的“黑掉”了对方的网站,而是冒名顶替、招摇撞骗罢了。
现在的Internet上存在的DNS服务器有绝大多数都是用bind来架设的,使用的bind版本主要为bind 4.9.5+P1以前版本和bind 8.2.2-P5以前版本.这些bind有个共同的特点,就是BIND会缓存(Cache)所有已经查询过的结果,这个问题就引起了下面的几个问题的存在.
DNS欺骗
在DNS的缓存还没有过期之前,如果在DNS的缓存中已经存在的记录,一旦有客户查询,DNS服务器将会直接返回缓存中的记录
防止DNS被攻击的若干防范性措施
互联网上的DNS放大攻击(DNS amplification attacks)急剧增长。这种攻击是一种数据包的大量变体能够产生针对一个目标的大量的虚假的通讯。这种虚假通讯的数量有多大?每秒钟达数GB,足以阻止任何人进入互联网。
与老式的“smurf attacks”攻击非常相似,DNS放大攻击使用针对无辜的第三方的欺骗性的数据包来放大通讯量,其目的是耗尽受害者的全部带宽。但是,“smurf attacks”攻击是向一个网络广播地址发送数据包以达到放大通讯的目的。DNS放大攻击不包括广播地址。相反,这种攻击向互联网上的一系列无辜的第三方DNS服务器发送小的和欺骗性的询问信息。这些DNS服务器随后将向表面上是提出查询的那台服务器发回大量的回复,导致通讯量的放大并且最终把攻击目标淹没。因为DNS是以无状态的UDP数据包为基础的,采取这种欺骗方式是司空见惯的。
这种攻击主要依靠对DNS实施60个字节左右的查询,回复最多可达512个字节,从而使通讯量放大8.5倍。这对于攻击者来说是不错的,但是,仍没有达到攻击者希望得到了淹没的水平。最近,攻击者采用了一些更新的技术把目前的DNS放大攻击提高了好几倍。
当前许多DNS服务器支持EDNS。EDNS是DNS的一套扩大机制,RFC 2671对次有介绍。一些选择能够让DNS回复超过512字节并且仍然使用UDP,如果要求者指出它能够处理这样大的DNS查询的话。攻击者已经利用这种方法产生了大量的通讯。通过发送一个60个字节的查询来获取一个大约4000个字节的记录,攻击者能够把通讯量放大66倍。一些这种性质的攻击已经产生了每秒钟许多GB的通讯量,对于某些目标的攻击甚至超过了每秒钟10GB的通讯量。
要实现这种攻击,攻击者首先要找到几台代表互联网上的某个人实施循环查询工作的第三方DNS服务器(大多数DNS服务器都有这种设置)。由于支持循环查询,攻击者可以向一台DNS服务器发送一个查询,这台DNS服务器随后把这个查询(以循环的方式)发送给攻击者选择的一台DNS服务器。接下来,攻击者向这些服务器发送一个DNS记录查询,这个记录是攻击者在自己的DNS服务器上控制的。由于这些服务器被设置为循环查询,这些第三方服务器就向攻击者发回这些请求。攻击者在DNS服务器上存储了一个4000个字节的文本用于进行这种DNS放大攻击。
现在,由于攻击者已经向第三方DNS服务器的缓存中加入了大量的记录,攻击者接下来向这些服务器发送DNS查询信息(带有启用大量回复的EDNS选项),并采取欺骗手段让那些DNS服务器认为这个查询信息是从攻击者希望攻击的那个IP地址发出来的。这些第三方DNS服务器于是就用这个4000个字节的文本记录进行回复,用大量的UDP数据包淹没受害者。攻击者向第三方DNS服务器发出数百万小的和欺骗性的查询信息,这些DNS服务器将用大量的DNS回复数据包淹没那个受害者。
如何防御这种大规模攻击呢?首先,保证你拥有足够的带宽承受小规模的洪水般的攻击。一个单一的T1线路对于重要的互联网连接是不够的,因为任何恶意的脚本少年都可以消耗掉你的带宽。如果你的连接不是执行重要任务的,一条T1线路就够了。否则,你就需要更多的带宽以便承受小规模的洪水般的攻击。不过,几乎任何人都无法承受每秒钟数GB的DNS放大攻击。
因此,你要保证手边有能够与你的ISP随时取得联系的应急电话号码。这样,一旦发生这种攻击,你可以马上与ISP联系,让他们在上游过滤掉这种攻击。要识别这种攻击,你要查看包含DNS回复的大量通讯(源UDP端口53),特别是要查看那些拥有大量DNS记录的端口。一些ISP已经在其整个网络上部署了传感器以便检测各种类型的早期大量通讯。这样,你的ISP很可能在你发现这种攻击之前就发现和避免了这种攻击。你要问一下你的ISP是否拥有这个能力。
最后,为了帮助阻止恶意人员使用你的DNS服务器作为一个实施这种DNS放大攻击的代理,你要保证你的可以从外部访问的DNS服务器仅为你自己的网络执行循环查询,不为任何互联网上的地址进行这种查询。大多数主要DNS服务器拥有限制循环查询的能力,因此,它们仅接受某些网络的查询,比如你自己的网络。通过阻止利用循环查询装载大型有害的DNS记录,你就可以防止你的DNS服务器成为这个问题的一部分。
结束语:网络攻击越来越猖獗,对网络安全造成了很大的威胁。对于任何黑客的恶意攻击,都有办法来防御,只要了解了他们的攻击手段,具有丰富的网络知识,就可以抵御黑客们的疯狂攻击。一些初学网络的朋友也不必担心,因为目前市场上也已推出许多网络安全方案,以及各式防火墙,相信在不久的将来,网络一定会是一个安全的信息传输媒体。特别需要强调的是,在任何时候都应将网络安全教育放在整个安全体系的首位,努力提高所有网络用户的安全意识和基本防范技术。这对提高整个网络的安全性有着十分重要的意义。
转载:http://www.williamlong.info/archives/3813.html