服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 针对getaddrinfo（）的Glibc错误缓解
Intereting Posts
ssl客户端证书validation在nginx中失败 我可以设置端口转发来模拟不只是一个端口，但另一个IP地址？ 有没有简单的方法通过HTTP从远程Windows 2012 R2机器获取性能信息？ 强制在同一子网上的IP静态路由？ linux服务器不断踢我 Windows Server 2012上的SNMP磁盘队列长度（MRTG） SELinux干扰Apache / PHP Runtime.getRuntime（）。exec（String）无法创build一个新的进程| Java + LINUX W2K8R2：如何安全地使Windows服务群集资源脱机 窗口服务器目录权限 – 带有完全控制子文件夹的只读文件夹 我可以使用Apache作为正向代理cachingHTTPSstream量吗？ 我可以给计算机帐户访问权限删除自己吗？ 警告：主机名no-reverse-dns-configured.com不解决地址 如何检查下载/上传速度到Web服务器？ iis 7.5网站权限

针对getaddrinfo（）的Glibc错误缓解

今天跨过glibc的一个漏洞 ，涉及getaddrinfo（）调用DNSparsing。 我在两台面向互联网的Bind9机器上运行Ubuntu 12.04。 我不确定我完全理解这个漏洞，但似乎是由一个恶意DNS服务器的大量回复引起的。 其中一个缓解措施是“丢弃UDP DNS数据包大于512字节的防火墙”，所以我在DNS服务器上configuration了netfilter，删除来自或去往端口53的任何UDP> 512字节： -A INPUT -i lo -j ACCEPT -A INPUT -p udp --sport 53 -m length --length 511:65535 -j DROP -A INPUT -p udp --dport 53 -m length --length 511:65535 -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

有没有更好的方式来做到这一点绑定设置或任何东西？ 我用scapytesting了这个规则，它确实阻塞了在端口53上丢弃大于512的UDP包。

每个响应更新： -A INPUT -i lo -j ACCEPT -A INPUT -p udp --sport 53 -m length --length 949:65535 -j DROP -A INPUT -p udp --dport 53 -m length --length 949:65535 -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

和/etc/bind/named.conf.options 

 options { ... // 2016-02-17 - tmb - glibc exploit mitigation edns-udp-size 900 ; max-udp-size 900 ; };

更新2 ：正如下面的atdre所指出的那样，Cloudflare尝试了上述技术，尽pipe整个有效负载不能被传输，但内存损坏仍然是可能的。 我想我会考虑放弃 。

如果你在本地运行绑定，这会给你一个testing： 

 dig @127.0.0.1 tcf.rs.dns-oarc.net txt

如下所述： https ： //www.dns-oarc.net/oarc/services/replysizetest 。

你会得到这样的答复： 

 root@myhost:~# dig @127.0.0.1 tcf.rs.dns-oarc.net txt ; <<>> DiG <<>> @127.0.0.1 tcf.rs.dns-oarc.net txt ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61575 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 26, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1024 ;; QUESTION SECTION: ;tcf.rs.dns-oarc.net. IN TXT ;; ANSWER SECTION: tcf.rs.dns-oarc.net. 60 IN CNAME tcf.x981.rs.dns-oarc.net. tcf.x981.rs.dns-oarc.net. 59 IN CNAME tcf.x986.x981.rs.dns-oarc.net. tcf.x986.x981.rs.dns-oarc.net. 58 IN CNAME tcf.x991.x986.x981.rs.dns-oarc.net. tcf.x991.x986.x981.rs.dns-oarc.net. 57 IN TXT "Tested at 2016-02-17 15:44:36 UTC" tcf.x991.x986.x981.rs.dns-oarc.net. 57 IN TXT "xx.xx.xx.xx DNS reply size limit is at least 991"

你可以添加绑定选项 

 options { ... edns-udp-size 1024 ; max-udp-size 1024 ; };

在文件named.conf中

如下所述： https ： //labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-reply-size-issues 。

我会把这个和其他缓解措施一起使用。

而一个防火墙，丢弃> 512字节的UDP DNS数据包。 （特别是通过UDP，TCP仍然是一个攻击媒介），这也不是正确的行为，而是破坏了其他function。

自引入EDNS0以来，在DNS规范中就没有这种限制，只要丢弃数据包就会导致有效stream量的中断。

鸟类build议，configuration一个parsing器名称服务器来限制响应大小返回到客户端是一个更好的方法，因为客户端将至less被按照规范正确通知（截断响应），而不是只是沉默，最终超时，但适当的解决scheme是安装补丁glibc（这是一些错误的地方，大小是没有错的） 。

经过一些testing，CloudFlare确定限制DNS数据包的响应大小并closuresEDNS0支持不能补救CVE-2015-7547。 您可以使用作者的PoC代码自己进行testing，在整篇文章中以链接的forms提供。

你可以阅读他们的结论，以及在这里看到他们的testing结果 – https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/

CloudFlare说，

唯一有效的缓解措施是在本地主机上运行一个DNSparsing器，攻击者不能引入资源耗尽，或者至less强制cachingTTL来缓解等待中的游戏攻击。

将以下三个有用的实用程序作为可以安装和configuration的开源parsing程序：

  1. 不作承诺
  2. PowerDNS Recursor
  3. 结DNSparsing器

他们也继续说，

一个好的缓解措施是用本地cachingDNSparsing器或者至less一个DNSCrypt隧道来保护自己。 可以说，parsing器中也可能存在一个漏洞，但它被包含在守护进程中，而不是所有使用C库的东西（例如，sudo）。