У меня были периодические проблемы с DNS с веб-сервером, когда некоторые DNS-серверы ISP не имеют моих имен хостов в кеше и не могут их найти. В то же время запросы к opendns для этих имен хостов разрешаются правильно. Он прерывистый, и у меня всегда работает нормально, поэтому трудно определить проблему, когда кто-то сообщает о проблемах с подключением на мой сайт.
Пытаясь понять это, я просматривал свои журналы, чтобы узнать, есть ли какие-нибудь ошибки, о которых мне следует знать.
Я нашел в своих журналах тысячи следующих сообщений с разных IP-адресов, но все они запрашивали аналогичные записи DNS:
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#36141: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#29075: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#47924: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:13 localhost named[26399]: client 94.76.107.2#4727: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:14 localhost named[26399]: client 94.76.107.2#16153: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:42:14 localhost named[26399]: client 94.76.107.2#40267: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:43:35 localhost named[26399]: client 82.209.240.241#63507: query (cache) 'burningpianos.com/MX/IN' denied
May 12 11:43:35 localhost named[26399]: client 82.209.240.241#63721: query (cache) 'burningpianos.org/MX/IN' denied
May 12 11:43:36 localhost named[26399]: client 82.209.240.241#3537: query (cache) 'burningpianos.com/MX/IN' denied
Я читал об уязвимости Дэна Камински к отравлению кеша DNS (http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html), и мне интересно, не являются ли эти записи журнала попыткой какого-то злоумышленника атаковать мой DNS-сервер.
В моих журналах есть тысячи записей, все запрашивают "горящие пианино", некоторые для com, некоторые для org, большинство из которых ищут запись mx. Есть запросы с нескольких IP-адресов, но каждый IP-адрес будет запрашивать сотни раз в день.
Так что для меня это пахнет атакой. Какая защита от этого?
Я не могу сказать вам наверняка, что это такое, но могу сказать, что это не так:
Как бы то ни было, я думаю, что это неправильная конфигурация этих доменов, хотя отсюда кажется, что они отключены. Я вижу некоторые несоответствия в записях клея для burningpianos.com - в .com серверы говорят, что они 209.97.196.66 и 0,67 - это вы?
Вопреки предположению Брэда, я бы сказал, что если возможно, вы должен на самом деле настройте свой сервер так, чтобы он возвращал REFUSED ответ на запросы по этим доменным именам.
Простое отбрасывание запросов означает, что клиенты на другой стороне будут продолжать повторять попытки, как, похоже, уже происходит.
Если трафик упадет, когда вы это сделаете, он сразу скажет вам, что исходные адреса не подделка, и это подтвердит теорию о неправильной конфигурации.
удостовериться allow-query в вашей конфигурации привязки разрешены только диапазоны IP-адресов, для которых вы надеетесь обслуживать информацию DNS.
в противном случае начните блокировать IP-адреса, которые запрашивают, поскольку это похоже на своего рода спам / обратное рассеяние, особенно если каждый IP-адрес делает много повторных запросов.
Ну, это же возможно вы стали мишенью для отравления тайника Каминского. Эти запросы могут быть попытками определить, является ли ваш DNS-сервер восприимчивым, путем поиска монотонно увеличивающихся идентификаторов запросов в ответах вашего DNS-сервера. Но очевидно, что ваш DNS-сервер не является публичным кеширующим рекурсивным сервером имен, поскольку все запросы отклоняются, но я полагаю, что такое хлопанье дверью неизбежно для скриптовых детей. Пока ваш сервер имен не обслуживает рекурсивный DNS с публичным кешированием, беспокоиться не о чем, даже если у вас была старая версия, уязвимая для атаки Каминского.
Другие возможности включают в себя странную неправильную конфигурацию со стороны burnpianos.com или попытку атаки с отражением. И то, и другое раздражает, но не вредно, если вы не тратите впустую свою (или невиновного человека в случае атаки отражения) пропускную способность, отправляя обратно отклоненные ответы. Я предполагаю, что, поскольку запрос был отклонен, он просто отбросил запрос без ответа, но я не эксперт по привязке, поэтому я не уверен.
Похоже, это может быть DNS-атака на ваш сервер или попытка прикрепить адреса, которые вы видите. Подделать udp-адрес запроса несложно, что приведет к атаке на целевой сервер. Журналирование запросов может облегчить засорение вашего DNS-сервера, но помогает увидеть этот вид активности.
Вы, вероятно, захотите разрешить запрос всем. Если вы кого-то заблокируете, они не смогут искать ваши серверы. Также проверьте, что все ваши DNS-серверы обслуживают хорошие данные. dnscog.com может проверить ваши серверы извне для вас.
Убедитесь, что вы блокируете рекурсию и запросы из кеша для внешних адресов.
Что касается некоторых серверов, у которых нет вашего разрешения DNS в кеше ... проверьте TTL ваших записей DNS. Это время жизни, и если оно установлено на низкое значение, серверы не будут кэшировать ваши записи очень долго.
Однако это не должно помешать им разрешить вас, поскольку они должны просто попасть на корневой сервер, найти ваши DNS-серверы и получить авторитетный ответ.
Т
Просто прохожу, но в этом конкретном случае я обнаружил, что директива allow-query-cache - это та, которую нужно установить, чтобы избежать этого сообщения. Добавьте в файл /etc/bind/ named.conf.options следующее:
// only localhot can query cached recursive dns entries
allow-query-cache { 127.0.0.1 };