-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
使用Bind设置或其他任何东西有更好的方法吗?
我已经用scapy测试了规则,它确实阻止了UDP数据包> 512在53号港口被抛出.
每个回复更新:
-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尝试了上述技术,尽管整个有效载荷无法传输,但内存损坏仍然存在.我想我会调查Unbound.
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.
我也会将此与其他缓解措施结合使用.
总结以上是内存溢出为你收集整理的linux – getaddrinfo()的Glibc bug缓解全部内容,希望文章能够帮你解决linux – getaddrinfo()的Glibc bug缓解所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)