回复 11楼 田纳西 的帖子
呵呵,我对成因更感兴趣,因为显然ESET是不会对任何来自远程某IP的53端口的报文做攻击报告的,那么这么频繁地出现且实际没让用户感觉出系统的DNS解析不能,根据以上两者推断是ESET的UDP伪状态检测里某设置有问题,或者说因为没对DNS的UDP报文做特别处理而引起的误报...
例如根据UDP状态表内的记录时间,到期移除,那么此时刚好一条响应报文入站就被判断为无状态表内记录被匹配(查询报文是记录时间没到的时候就出去的),而由于远程端口为53,就被报为DNS缓存攻击....由于用户基本和固定的1到2个DNS服务器通信,所以一个出站的DNS查询建表,然后后续的DNS响应和再次的查询/响应在一段时间内都是通过同一条状态表记录来匹配.直到过期..如果刚好有查询在时间内,响应在时间外,那么就发生攻击报告..而用户系统则再做一次查询就可以再建一个UDP状态表内的记录,再无事一段时间.....
个人防火墙不少都那样,企业级的防火墙一般对DNS报文做额外处理:包括状态表的不同处理方式和额外的DNS字段匹配检查....个人防火墙里看得明的且测试过的是LNS可以用RAW+SPF做到比较好,NET FIREWALL提供了DNS的UDP报文的单独处理(DNS的TCP不会存在以上问题,因为除非TCP状态检测做的和UDP的一样方式,否则多个TCP标志的发起判断,一个查询发起就会在TCP状态表内有一个记录的,不会和UDP那样发生去共用之前查询报文的产生的记录)..
正如前面所说,一般除了服务提供商自己出点"有问题"的响应,也没谁有兴趣对个人计算机从DNS响应报文那里着手去开始攻击,所以个人防火墙不做特别处理就不做了吧,不过还做为"攻击"写在日志里,这就是产品做得"过"了,呵呵....:) |
楼主: gbx972
发表于 2011-4-3 21:56:56
楼主