0,0
рейтинг
5 февраля 2010 в 10:48

Администрирование → Блокирование DNS DDoS при помощи пакета fail2ban

Вы уже устали от кучи сообщений от logcheck'а об откаpе в обслуживании запросов к named? Ниже будет написано как ограничить себя от DDoS к named'у при помощи пакета fail2ban.

События о которых идёт речь выглядят так:
System Events
=-=-=-=-=-=-=
Jan 21 06:02:13 www named[32410]: client 66.230.128.15#15333: query (cache)
+'./NS/IN' denied

Однако следует отметить, что в большинстве случаев ip-адрес источника может быть сфальсифицирован. Каждый узел в бот-сети может послать один или несколько пакетов в секунду к DNS-серверу. Сервер в свою очередь отвечает сообщением об ошибке в запросе сфальсифицированному адресу, вызывая отказ в обслуживании у источника.

Устали от того, что ваш DNS сервер используется в качестве оружия в чужих DDoS-атаках? Попробуйте установить себе пакет fail2ban (Debian GNU/Linux). Оригинальный сайт проекта www.fail2ban.org.

Сначала установим себе пакет fail2ban. По умолчанию будут отслеживаться и блокироваться только атаки на службу ssh. Это неплохая идея. В пакете fail2ban могут контролироваться и другие службы, более того можно самостоятельно написать обработчики и фильтры к нему, но обсуждение этих вопросов выходит за рамки данной статьи.
aptitude install fail2ban

После того как пакет будет установлен проверяем содержимое файла /etc/fail2ban/jail.conf.
В конце файла находим описание которое надо произвести в настройках сервера named чтобы fail2ban смог нормально обрабатывать события для службы DNS.

Для начала создадим каталог в котором будет сохраняться журнал работы DNS-сервера:
mkdir /var/log/named
chown bind.bind  /var/log/named
chmod 750  /var/log/named

После этого отредактируем /etc/bind/named.conf.local (У вас он может находиться в другом месте. Указанное имя актуально для пакета bind9 в Debian) добавив следующие строки:
logging {
    channel security_file {
        file "/var/log/named/security.log" versions 3 size 30m;
        severity dynamic;
        print-time yes;
    };
    category security {
        security_file;
    };
};

Перестартовываем Bind:
/etc/init.d/bind9 restart

Убеждаемся в том, что создаётся и заполняется журнал /var/log/named/security.log:
21-Jan-2010 07:19:54.835 client 66.230.160.1#28310: query (cache) './NS/IN' denied

Отлично, теперь внесём изменения в наструйку fail2ban. Открываем на редактирование /etc/fail2ban/jail.conf и вносим следующие изменения:
[named-refused-udp]

enabled  = false

заменяем на
[named-refused-udp]

enabled  = true

а также:
[named-refused-tcp]

enabled  = false

на
[named-refused-tcp]

enabled  = true

Перестартовываем fail2ban:
/etc/init.d/fail2ban restart

Убеждаемся, что fail2ban создаёт свой журнал /var/log/fail2ban.log, он будет содержать что-то вроде:
2010-01-21 07:34:32,800 fail2ban.actions: WARNING [named-refused-udp] Ban 76.9.16.171
2010-01-21 07:34:32,902 fail2ban.actions: WARNING [named-refused-tcp] Ban 76.9.16.171

Убеждаемся так-же в том, что fail2ban внёс соответствующие изменения в iptables:
$ sudo iptables-save | grep fail2ban

Теперь можно проверить насколько актуально и своевременно fail2ban ограничивает доступ:
tail -f /var/log/named/security.log

Теперь DNS сообщения об ошибках будут находиться в нескольких минутах друг от друга, а не в секундах.

Теперь о некоторых доработках напильником.

Скажем сервису logcheck смотреть в новое место для нахождения сообщений об ошибках. Правим файл /etc/logcheck/logcheck.logfiles добавив в конец файла строку:
/var/log/named/security.log

Убеждаемся, что мы теперь получаем сообщения от fail2ban по e-mail'у.

Хорошей идеей будет исследование опций в секции [DEFAULT] сервиса fail2ban в файле /etc/fail2ban/jail.conf. Возможно вы также захотите включить контроль других служб, кроме named. Может быть имеет смысл внести изменения в правила для игнорирования сетей из RFC1918 (смотрим в сторону опции ignoreip).

Также можно подумать об изменении bantime = 600 на более длительный срок.

Можно попробовать написать самостоятельно свои фильтры для fail2ban если вы в достаточной степени владеете магией составления регулярных выражений ;)

Короче дерзаем и исследуем :)

ps: Да, ещё, это всего лишь вольный перевод "Blocking a DNS DDOS using the fail2ban package" с некоторыми дополнениями из практики ;)
Александр Русских @oldengremlin
карма
86,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (10)

  • 0
    Спасибо. Все просто и понятно. Пошел ставить :)
  • 0
    Кстати, на всякий, в линуксе нет служб и сервисов, это все называется демонами (daemon) ;)
    • +1
      Такое умное замечание. Череп не жмёт?
      О словах и понятиях синонимах что-то слышали в этой жизни? ;)
      • +1
        Ну а чего бычить сразу-то? :)
        Просто в никсах это правильнее называть демонами, а в форточках службами/сервисами. Я просто заметил и на писал. Не зря же было указано «на всякий» :)
        К тому же я тебя не знаю… Вдруг ты просто не давно пересел с форточек на никсы и еще просто не знаешь об этом :)))
        • +1
          Ну а чего бычить сразу-то? :)
          А смайлики для чего рисуются? ;)
          Относительно «недавно»: можно было бы иногда и в профиль заглядывать тому кому пишешь ;) Если '97-й год это недавно… То да… Да, а до '97-го была OS/2 ;)
          «Форточки» ни на работе, ни дома на нетбуке — не использую и использовать не собираюсь…
          • 0
            Ну я то тоже смайлик поставил ;) Т.е. шутка на шутку, так сказать :)

            Не заглянул, сорри :)
    • 0
      А я-то думал, и почему это в линуксах программа управления системными фоновыми процессами называется «service»? А оказывается потому, что эти самые процессы называются демонами!
  • 0
    > следует отметить, что в большинстве случаев ip-адрес источника может быть сфальсифицирован

    сиё утверждение кажется мне спорным. Допустим, ДДоС идёт от обычных заражённых домашних тазиков — так кто же выпустит их пакеты с заспуфлеными адресами из своей сети? Хотя, может, админы действительно всё плохо настраивают.

    А сам fail2ban мне не понравился — я тестировал его на ВПСе и остался недоволен падением производительности виртуальной машины. То есть в случае атаки можно попробовать, но пока не трогают — лучше без него обойтись.
    • 0
      По каким причинам было падение производительности? fail2ban съедает много ресурсов на анализ логов?

      Какую альтернативу посоветуете?
      • 0
        по субъективным — тормозить начало.
        Альтернатива? Я переставил sshd на нестандартный порт, отключил доступ root и поставил нормальный пароль. Раз в день просматривал логи и блокировал айпишники, с которых были попытки подбора (хотя ссшд и так ограничивает количество попыток ввода пароля). Мне этого вполне хватило.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.