В нашем последнем сканировании TW PCI одним из наших флагов было «Отказ в обслуживании с усилением DNS».
Прямо сейчас на DNS-сервере работает Bind 9.8.1-P1. Похоже, что CVE предназначены для более старой версии: CVE-2006-0988, CVE-2006-0987.
В качестве доказательства было указано следующее: Вывод: 26-байтовый ЛЮБОЙ запрос для [мой домен] дал гораздо больший ответ, размером 283 байта.
Итак, из внешнего мира я копаю:
taco $ dig -t NS . @[my domain]
За что возвращаюсь:
; <<>> DiG 9.8.1-P1 <<>> -t NS . @[my domain]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 54954
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;. IN NS
;; Query time: 47 msec
;; SERVER: [my ip address]#53([my ip address])
;; WHEN: Mon Nov 25 15:53:24 2013
;; MSG SIZE rcvd: 17
Мне кажется, что мой сервер BIND поступает правильно и отказывается. Но скан верен в том, что для небольшого ввода он получил гораздо больший результат. Даже если это не позволяло рекурсию извне.
Есть ли способ заставить BIND вообще не отвечать или отправить более короткий ответ? Есть ли что-то еще, что мне нужно сделать, чтобы сделать сканирование TW PCI счастливым?
Запрос, о котором они говорят, вероятно, больше похож на dig -t any [your domain] @[your nameserver], который, вероятно, вернет более широкий отклик, о котором они говорят.
Это авторитетный сервер имен? Если так ... ну, вы действительно мало что можете сделать с его использованием в отражении, кроме запросов с ограничением скорости.
Отражение DNS - это неприятная вещь для Интернета в целом, но я не понимаю, почему пропускная способность вашего авторитетного DNS-сервера используется для увеличения трафика DDoS, связана с вашим соответствием PCI.
Вышеупомянутый ответ Шейна Мэддена уместен - вы делаете правильные вещи для рекурсивного обслуживания, если вы ограничиваете рекурсию для своих собственных клиентов и отрицаете ее для тех, кто находится за пределами тех границ, которые вы определили в отношении того, кому вы обслуживаете. Не используйте открытый резольвер без уважительной причины и если вы решите, что вам нужно это сделать по какой-либо причине, вы должны активно отслеживать злоупотребления и блокировать как можно скорее; в противном случае вы представляете опасность для других участников сети.
Что касается авторитетного сервиса, то он снова прав - тут мало что можно сделать, кроме ограничения скорости отклика (RRL). [На что стоит ISC (авторы BIND, а также операторы F-root, один из тринадцати корневые серверы имен) - сильно страдают от этого, будучи одной из главных целей для размышлений, потому что небольшая длина запроса в сочетании с большим ответом на ЛЮБОЙ запрос создает существенный коэффициент усиления. Мы как бы застряли на этом, пока подмена источника UDP остается легкой.]
Что касается вашей текущей версии (BIND 9.8.1-P1): при условии, что вы используете исходный код от ISC, существует ряд нерешенных уязвимостей, затрагивающих 9.8.1-P1, которые вы, возможно, захотите устранить. Большинство из них, если их использовать, приводят к отказу в обслуживании, когда сервер выходит из строя с ошибкой ASSERT или INSIST - BIND 9 на самом деле разработан сбой, как только он обнаруживает несогласованное состояние, вместо продолжения и, возможно, еще большего риска.
Вы можете найти список применимых рекомендаций по безопасности, обратившись к Матрица безопасности BIND В зависимости от того, какие функции вы используете, не все из перечисленных ниже уязвимостей обязательно применимы, но, тем не менее, вам следует проверить их, чтобы быть уверенным. BIND 9.8 в настоящее время имеет версию 9.8.6-P1, или вы можете перейти на BIND 9.9.4-P1 и получить RRL бесплатно (ну, это необязательная компиляция, но за цену дополнительного аргумента командной строки для настройки вы можете иметь его и помочь сделать ваш авторитетный сервер менее привлекательной целью для размышлений.)
CVE Number Short Description
2013-6320 A Winsock API Bug can cause a side-effect affecting BIND ACLs
2013-4854 A specially crafted query can cause BIND to terminate abnormally
2013-2266 A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named
2012-5689 BIND 9 with DNS64 enabled can unexpectedly terminate when resolving domains in RPZ
2012-5688 BIND 9 servers using DNS64 can be crashed by a crafted query
2012-5166 Specially crafted DNS data can cause a lockup in named
2012-4244 A specially crafted Resource Record could cause named to terminate
2012-3817 Heavy DNSSEC validation load can cause a "bad cache" assertion failure
2012-1667 Handling of zero length rdata can cause named to terminate unexpectedly
2011-4313 BIND 9 Resolver crashes after logging an error in query.c