2008年(5)
分类:
2008-07-19 13:14:58
如果受到DNS SERVER的缓存中毒(cache poison),则使用此DNS SERVER的用户访问中国工商银行网站时,可能到达的是一个类似工商银行网站的界面,从而使用户蒙受损失。要实现缓存中毒,要从DNS解析处理的机制分析。DNS是树型层次结构,递归式解析以求解。当到达DNS SERVER时,它将请求提交给上层并最终由域名归属的权威服务器给出回答。如果DNS SERVER递归请求解答时,尽管递归可能发生多次的请求应答,其实质就是DNS SERVER请求域名,域名的权威服务器最终给出回答,这正是一对请求应答的UDP包。如果攻击能够伪造它是一个权威服务器应答,并且在真正的权威服务器应答返回前到达了,那么在DNS SERVER就缓存了攻击者的回答,这个回答就是类似工商银行网站所在的IP。 UDP包通过5元组(srcip,srcport,dstip,dstport,protocol)来标识唯一性连接。DNS SERVER能够接收攻击者的应答包,必须要求它有以下几点:1、来自权威服务器所在IP以及服务对应port 2、返回的对象是自己的IP和发包时的port 3、protocol是udp 其中1没有问题,自己向权威服务器发包解析下就知,2中发包时的port可能有点问题,需要讨论,3显然没问题。那么只要解决发包时的port伪造就可以了。UDP port有16位,会有65536种可能,这使得攻击有些难度。幸运地是,不少DNS对来自同一客户端的各种域名请求,在做递归解析时,都会重用源端口。这点区别于TCP,TCP经常性变化端口,但UDP通常会重用端口,因为TCP变化端口有利保持与同一服务器的多个连接,而UDP这种这种需求比较少。这样,一种攻击方案设计可以考虑让攻击者先测试任意一个域名看返回的源port是什么,这个源port也将是攻击者请求攻击域名时,在DNS SERVER所向权威服务器发起的源port。(注意:若采用随机化DNS SERVER的源端口,将导致此攻击方法失效,如最新的ISC发布的patch以及一些版本的dns server,可用 dig porttest.dns-oarc.net TXT @dns_server_ip来判断源端口是否随机化。) 方案似乎非常简单了, 因此,攻击方案将是: 1、攻击者向DNS SERVER请求域名解析 2、攻击者伪造所在的权威服务器(202.106.83.125)的应答 只要等待DNS SERVER缓存清空并做递归解析请求权威记录时,就很快成功了。问题在于,为了防止此种脆弱性的漏洞,DNS请求解析协议加入了Transaction ID,以防止攻击。这种Transaction ID为16位0xFFFF,有65536种可能性,这极大加大了难度。因为攻击时间点必须在递归请求时间和权威返回记录这段短时间内才能够成功,并且不能够响应超时。尽管困难,但这并不是不可能。很简单的,攻击者可以通过向权威发送大量请求包的方式将阻塞权威返回应答,将时间留给了攻击者! 只要如攻击方案中发送大量的解析包和大量的伪造应答包,是很可能成功的,这只是一个概率问题。这个概率为多大,取决于一个良好的Transaction ID设计算法。但由于"Birthday Paradox"存在,采用“生日攻击”使得并不很大的发包数也很可能攻击成功。 注:The Birthday Paradox 对于ID总可能值数为t,对于n请求回应伪造的n个应答,发生Transaction ID相同的可能性概率为P=1-(1-1/t)^[n*(n-1)/2]。对于16位ID时t为65536,只需要n=700可达到100%成功率,n=300可达到50%成功率。而如果只是针对单个包特定Transaction ID只有n/65536的成功概率。 附:建议 如果是权威服务器,关闭递归。由于只回应自己授权域的查询,而不会缓存任何外部的数据,因此攻击无效。所以,以下都是针对通用递归解析服务器进行考虑。 1、及时升级到最新版本及打补丁。这是必须做的事情。 2、控制递归解析允许的IP及split DNS保护,并可通过forward方式使得解析不直接请求根(forward to protect-ip server and this protect-ip server only accepts the request from limited ip.)从而快速响应正确域名。破解时间race。 3、布署IDS,检测53端口及IP真实性及单IP请求流量限制。破解攻击包源。 4、采用强的随机数生成和不重用源端口的较安全DNS服务器版本。本质上使攻击不可行 5、采用DNSSEC(RFC 3008:Domain Name System Security (DNSSEC) Signing Authority),采用公 钥体系认证请求源及完整性校验。受限于当前的通用环境。 6、主动监测缓存条目,实时删除非法缓存条目。这也是一种方法,有些滞后,但能够减小影响。因为攻击成功后缓存的TTL有时为一天时间。 ***设置小的TTL,减小缓存中毒效应。(这其实是错误的,因为小的TTL会使得攻击机会增多。一次攻击成功率与机会窗口时间,即授权服务器解析响应返回时间相关,而与TTL时间无关。)具体可见下面分析: 为何采用强的随机数生成和不重用源端口可以本质上使攻击不可行的分析: I: Number distinct IDs available (maximum 65536) ID空间 攻击成功的概率是机会窗口时间内伪造包数目(D*F)除以问题空间大小(N*P*I),即p=(D*F)/(N*P*I),则尝试A次成功概率PS=1-(1-p)^A,注意A=T/TTL,其中T为攻击尝试时间,TTL为域名缓存时间,每次TTL过期才导致新的攻击可能,因为这时需要做新的递归请求。 当不随机化端口时,P=1,注意到F=R*W,此时PS=1-(1-D*F/N*P*I)^A=1-(1-D*R*W/N*P*I)^A=1-(1-R/1638400)^(T/TTL)。 通常一个现实的DNS响应包最小大小为80bytes,设R=7000,即4.5Mb/s攻击速率下,设TTL=3600(大多数DNS服务器的默认值),那么24小时成功率为10%,一周后可达50%。这是脆弱的。特别是当TTL=60秒时,3小时就可达50%,9小时高达90%攻击成功率。 若采用随机化端口,P=64000,此时PS=1-(1-R/104857600000)^(T/TTL)。对于TTL=3600的域名,需要285Gb/s才能够在24小时成功率为10%,一周后达50%。对于TTL=60的域名,也需要4Gb/s,才能够在一周后达到50%。 也就是说,当TTL=3600或者更大值时,攻击是不可能的,因为在一段长时间内的现实下,285G/s还是高不可及的攻击速率。当然,对于TTL=60或者更短的情况下,攻击是有可能的,如把TTL=10s时,并且采用R=1677721.6,攻击速率为1Gb/s,一周成功率=1-(1-1677721.6/104857600000)^60480=62%。 因此,只要DNS SERVER采用默认配置,攻击将完全不可行。要特别值得提醒的是,域名缓存TTL时间不能太短,否则攻击仍然有可能发生。不过,仍然可通过网络监管策略,我们可以发现网络的异常高流量,从而采取措施。 |