Пробежал через эксплуатировать для сегодняшней glibc, которая включает вызов getaddrinfo () для разрешения DNS. Я запускаю Ubuntu 12.04 на двух устройствах Bind9, выходящих в Интернет. Я не уверен, что полностью понимаю эксплойт, но, похоже, он вызван большим ответом от вредоносного DNS-сервера. Одно из смягчений - это "брандмауэр, отбрасывающий UDP-пакеты DNS> 512 байт" поэтому я настроил netfilter на DNS-серверах, чтобы отбрасывать любые UDP> 512 байт, приходящие или идущие на порт 53:
-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
Есть ли лучший способ сделать это с помощью настройки привязки или чего-то еще? Я протестировал правило с помощью 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: Как указывает Атдре Ниже Cloudflare попробовал описанный выше метод, и хотя всю полезную нагрузку передать не удалось, повреждение памяти все еще оставалось возможным. Я думаю, что посмотрю Несвязанный.
Пока Брандмауэр, отбрасывающий UDP-пакеты DNS размером> 512 байт. смягчает эксплойт (в частности, через UDP, TCP все еще может быть вектором атаки), это также неправильное поведение и вместо этого нарушает другие функции.
С момента появления EDNS0 в спецификации DNS нет такого ограничения, и вы будете вызывать сбои для действительного трафика, просто отбрасывая пакеты.
То, что предлагает Birdwes, с настройкой сервера имен преобразователя для ограничения размера ответа обратно его клиентам - лучший способ, поскольку клиенты будут, по крайней мере, должным образом уведомлены (усеченный ответ) в соответствии со спецификациями, а не просто молчание и, в конечном итоге, тайм-аут, но правильное решение - установить пропатченный glibc (вот где что-то не так, размер не тот).
Если вы запускаете привязку локально, это дает вам тест:
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 .
Я бы использовал это в сочетании с другими средствами защиты.
После небольшого тестирования CloudFlare определила, что ограничение размера ответа DNS-пакетов и отключение поддержки EDNS0 не исправляет CVE-2015-7547. Вы можете проверить себя, используя PoC-код автора, доступный в виде связанных ссылок по всему посту.
Вы можете прочитать об их выводах, а также увидеть результаты их тестов здесь - https://blog.cloudflare.com/a-tale-of-a-dns-exploit-cve-2015-7547/
CloudFlare говорит:
Единственное хорошее решение - запустить DNS-преобразователь на локальном хосте, где злоумышленник не может вызвать исчерпание ресурсов или, по крайней мере, установить минимальный TTL кеша, чтобы обезвредить ожидающую игровую атаку.
Предоставление следующих трех полезных утилит в качестве преобразователей с открытым исходным кодом, которые вы можете установить и настроить:
Они также продолжают говорить:
Как правило, хорошим решением является защита себя с помощью локального кэширующего DNS-преобразователя или, по крайней мере, DNSCrypt туннель. Возможно, уязвимость может быть и в резолвере, но она содержится в самом демоне, а не во всем, что использует библиотеку C (например, sudo).