Я включил журналы запросов DNS, и при запуске "tail -f / var / log / syslog" я вижу, что получаю сотни идентичных запросов с одного IP-адреса:
Apr 7 12:36:13 server17 named[26294]: client 121.12.173.191#10856: query: mydomain.de IN ANY +
Apr 7 12:36:13 server17 named[26294]: client 121.12.173.191#44334: query: mydomain.de IN ANY +
Apr 7 12:36:13 server17 named[26294]: client 121.12.173.191#15268: query: mydomain.de IN ANY +
Apr 7 12:36:13 server17 named[26294]: client 121.12.173.191#59597: query: mydomain.de IN ANY +
Частота около 5-10 запросов в секунду, продолжительностью около минуты. После этого тот же эффект повторяется с другого IP-адреса. Я зарегистрировал около 10 000 запросов примерно с 25 IP-адресов всего за пару часов, все они пришли из Китая, согласно whois [ipaddr].
Что здесь происходит? На мой сервер имен напали? Могу я что-нибудь с этим поделать?
Что здесь происходит? На мой сервер имен напали? Могу я что-нибудь с этим поделать?
Что здесь происходит?
Невозможно сказать по измененным записям журнала. Вот лишь несколько возможностей:
На мой сервер имен напали?
При 5-10 DNS-запросах в секунду с нескольких IP-адресов? Сомнительно. В большинстве известных мне DNS-атак используются специально созданные запросы, чтобы нарушить внутреннюю функциональность вашего сервера или перегрузить его ресурсы. Как правило, если вам нужно спросить, вас никто не атакует.
Могу я что-нибудь с этим поделать?
Конечно, вы можете заблокировать неправильные IP-адреса в своем брандмауэре или установить вышеупомянутый Fail2Ban инструмент.
Но нужно ли?
Помните, что вся работа вашего DNS-сервера - отвечать на запросы. Вы заметили это после того, как включили ведение журнала запросов и посмотрели результат. Вы видите сумасшедшее использование ЦП? Сетевой ввод-вывод? Остались ли другие заведомо законные запросы необслуженными из-за конфликта за ресурсы?
Если нет, зачем их блокировать? Пусть протоколы работают так, как они задуманы. Если вам нужны более чистые журналы, отключите ведение журнала запросов до тех пор, пока вам не понадобится диагностировать проблему.
Кто-то злоупотребляет вашим DNS-сервером для выполнения усиление атаки против IP-адреса 121.12.173.191, который злоумышленники подделывают.
Поскольку DNS в основном использует UDP, без подключения протоколом тривиально подделать исходный адрес запроса и отправить (больший) ответ обратно реальному владельцу этого поддельного адреса.
Использование ANY запросы на усиление хорошо известны в кругах DNS, но лишь относительно недавно были замечены хакерами в злоупотреблении.
Это это скорее всего что, если вы отслеживали TTL IP входящих пакетов, они будут несовместимыми, что указывает на то, что поддельные пакеты идут к вам по разным путям, хотя все они кажутся из одного и того же места.
Вы вполне можете видеть только 5-10 пакетов в секунду, но злоумышленники будут использовать множество других хостов для насыщения целевого адреса.
Хотя Fail2ban будет работать (я рекомендую его для многих целей), если вы видите один и тот же IP-адрес снова и снова, неизменный, нет причин не просто отказаться от него.
Заблокируйте его на своем брандмауэре или используйте IPTables.
iptables -A INPUT -s 121.12.173.191 -j DROP
Это должно избавить от запросов.
Если вы видите, что на ваш сервер попадают другие источники, то вы можете использовать IPTables для блокировки запросов от всего, что не из вашей сети, или использовать fail2ban для временной блокировки.
Fail2ban в любом случае использует IPTables для блокировки запросов, поэтому его постоянное добавление - не проблема. Вы также захотите посмотреть в своем дистрибутиве, как сделать изменение постоянным (обычно ваши сетевые скрипты при запуске). Если вы находитесь за брандмауэром, я настоятельно рекомендую сначала заблокировать там IP-адрес.
Независимо от того, как вы это делаете, убедитесь, что вы документируете это, чтобы вы (или ваша замена) не застряли через несколько месяцев, выясняя, почему это было сделано.
Я не знаю, вызвано ли это автоматическим сканированием, распространителями спама или другими причинами. Но что вы можете сделать, так это установить fail2ban и настроить его на блокировку слишком большого количества DNS-запросов за определенный интервал времени.
Надеюсь, эта ссылка вам поможет: http://www.debian-administration.org/article/Blocking_a_DNS_DDOS_using_the_fail2ban_package
5-10 запросов в секунду - это не так уж много и обычно не является признаком атаки (кроме случаев, когда они делают неправильные запросы или пытаются использовать какой-либо эксплойт для получения доступа к системе через какую-то уязвимость BIND ... Может быть, кто-то просто играет с помощью сценария или опубликовал пример кода, используя ваш DNS-сервер в качестве ссылки на каком-то китайском форуме, или это просто бот, пытающийся делать рекурсивные запросы о некоторых доменах (вы должны проверить tat в файле конфигурации BIND в разделе регистрации http://www.zytrax.com/books/dns/ch7/logging.html просто проверив, какие запросы они делают). Учитывая небольшое количество запросов (я надеюсь, ваша инфраструктура DNS выдержит это!), у вас есть 2 возможности:
1 - заблокировать все китайские IP-адреса (отметьте http://www.find-ip-address.org/ip-country/ )
2 - Ограничьте количество подключений до 3 в секунду на IP с помощью iptables
iptables -A INPUT -s ipaddress -p udp --dport 53 -m limit --limit 3/s -j ACCEPT
iptables -A INPUT -s ipaddress -p udp --dport 53 -j DROP
Обратите внимание, что ограничение одновременных подключений может вызвать некоторые проблемы, если вы примените это для любого IP-адреса, поскольку законные запросы законных клиентов будут истекать по таймауту, замедляя скорость просмотра любого клиента / сервера, использующего ваш DNS ...
Будьте осторожны с автоблоками и ограничениями скорости в протоколах без сохранения состояния
Не используйте эти белые списки вещей, которые вы никогда не должны блокировать.
Дело с Китаем - не единичный случай. Не знаю почему, но сканирование проводится постоянно и систематически.
Согласно следующему посту, это не новое явление, но я пока не нашел объяснения.
http://dyn.com/active-incident-notification-recent-chinanetany-query-floods/