Интеграция Fail2ban с CSF для противодействия DDoS на nginx

[sebres]

В последнее время участились случаи, когда злоумышленники осуществляют распределенный перебор паролей с разных адресов IP одной подсети класса C

Не совсем правда, т.к. гораздо чаще это бот-сети с абсолютно разных IP адресов. Просто это не так очевидно (IP же разные).

Алгоритм работы Fail2ban не способен распознать такое поведение

Позвольте (как сотруднику fail2ban) не согласиться: пока IPv6 не допилен, атаки из подсети в IPv4 это действительно редкость и тогда это не совсем так — существуют как минимум две возможности сделать подобное средствами f2b:

• используя jail «recidive» (не очень гибкое решение, подобное вашему cron, хотя и не для подсети);
• используя эту версию ban-time-incr, к сожалению уже довольно долго валяющуюся pull-реквестом (более гибкое решение, позволяющее увеличивать время бана нелинейно, хотя тоже пока не для подсети); Я как-то писал об этом на хабре.
• IPv6 уже в окончательной стадии разработки — там появится возможность определять ширину полосы (маску) подсетей (и возможно веса к ним). Подробнее можно почитать тут и тут.

Ну а пока, изменив параметры «actionban» и «actionunban» например для «recidive» можно уже сейчас блокировать подсети. Хотя для IPv4 это имхо не нужно, т.к. действительно редкость. Тем более из-за одного двух нехороших адресов класть всю подсеть в бан на неделю — как-то через чур уж жестко.

Бегло собрал статистику со всех своих серверов (и некоторых customer с большой посещаемостью) — из всех плохих адресов (из bips) свалившихся в бан с инкрементом:
— 8 пар и 1 тройка из одной подсети /24 для IP с баном больше 1 дня;
— 3 пары из одной подсети /24 в бане дольше недели;
— и ни одного (subnet /24) с баном более месяца;
Всего 17.4 тысяч уникальных IP с баном длиннее 1 дня, т.е. действительно плохих (banCount > 5).

[simnetworks]

Не совсем правда, т.к. гораздо чаще это бот-сети с абсолютно разных IP адресов. Просто это не так очевидно (IP же разные).

lfd выявляет и блокирует подобного рода атаки, однако, только для поддерживаемых им сервисов. Это одна из причин, по которой я предпочел использовать Fail2ban как дополнение к CSF.

используя jail «recidive» (не очень гибкое решение, подобное вашему cron, хотя и не для подсети);

Эта методика описана в статье.

используя эту версию ban-time-incr, к сожалению уже довольно долго валяющуюся pull-реквестом (более гибкое решение, позволяющее увеличивать время бана нелинейно, хотя тоже пока не для подсети); Я как-то писал об этом на хабре.

Описанное в статье решение базируется на Fail2ban v0.8.6 из стандартного репозитория Debian Wheezy.

IPv6 уже в окончательной стадии разработки — там появится возможность определять ширину полосы (маску) подсетей (и возможно веса к ним). Подробнее можно почитать тут и тут.

Т.е. в итоге полноценной поддержки подсетей в Fail2ban пока нет. А вести полемику на тему того, чей костыль красивее :-) и насколько целесообразно его применение, я смысла не вижу.

Ну а пока, изменив параметры «actionban» и «actionunban» например для «recidive» можно уже сейчас блокировать подсети.

Такая методика может привести к тому, что заблокированной окажется вся подсеть буквально из-за одного адреса IP, проявляющего чрезмерную активность.

Хотя для IPv4 это имхо не нужно, т.к. действительно редкость.

В статье приведена выдержка из журнала, которая наглядно показывает, что идет целенаправленный подбор с разных IP одной подсети. Это не синтетический тест. Далее по тексту приведен результат работы скрипта из cron со статистикой попыток для трех заблокированных подсетей: 332-641. Идея написания скрипта родилась у меня, когда статья уже была по большей части готова. Я взглянул на журнал работы Fail2ban и обнаружил, что идет массовый перебор с разных IP одних и тех подсетей. Насколько такие случаи являются массовыми, судить не берусь.

Тем более из-за одного двух нехороших адресов класть всю подсеть в бан на неделю — как-то через чур уж жестко.

Для того, что бы снизить вероятность этого используется двухступенчатая фильтрация. jail «recidive» блокирует отдельные IP на неделю, если они проявляли чрезмерную активность в течение суток: 10 или более блокировок. А срипт из cron в связке с соответствующими настройками logrotate блокирует также на неделю те подсети, чьи адреса набрали за туже неделю 30 или более блокировок. Таким образом, для блокировки всей подсети необходимо как минимум три активных адреса :-)

[sebres]

Это одна из причин, по которой я предпочел использовать Fail2ban как дополнение к CSF...

А вести полемику на тему того, чей костыль красивее...

Дык я вам не про то что красивее, а про то что для IPv4 подсетей оно как бы и не нужно… Достаточно при повторах просто ложить в бан дольше чем это делает сама jail (пользуем либо recidive, либо ban-time-incr, либо и то и другое).
Ну улетят все адресса из subnet чуть познее в бан чем у вас — в результате эти лишние 15 минут не идут ни в какое сравнение с неделей в бане (= 10080 минут).

Про остальное же (wp-фильтр для f2b, nginx limit_req и т.д.) в интернетах материала уйма, было неоднократно и на хабре — например тут или тут.

[JIghtuse]

Вы не в курсе, планирует ли fail2ban поддерживать nftables? Интересно, на что повлияет миграция на новый фреймворк.

[sebres]

Не слышал пока, но поспрашиваю…
А так, ежели просто переписать actions использующие iptables на nftables — дело то не хитрое, но результат не будет уметь (использовать) такие вкусности как expressions в правилах (aka instructions) и т.д. Я так понимаю, что ваш вопрос про это?

[FisHlaBsoMAN]

[зануда]
Например по C будут баниться 3г модемы полосатого оператора и прочий мобильный инет. У меня товарищ замучался постоянно либо переподключаться, либо через аномайзер/впн открывать. Далеко ходить не надо, хабрасторадж постоянно банит и картинки у него, соответственно, не открываются. А гугл капчу просит переодически, типа с вашей подсети много запросов. Хотя, возможно это зависит от региона.
[/зануда]
Хотя конечно не факт.

[simnetworks]

С удовольствие ознакомлюсь со статьей на тему написания собственных «regex.custom.pm» :-) Конкретно в моем случае необходимо было спешно развернуть защиту от DDoS на базе имевшихся наработок под Fail2ban. Интегрировать последний с CSF оказалось быстрее, нежели переделывать все под RegExp.

[aspel]

Подскажите как будет вести себя сервер при добавлении в бан 100000 ip?

[intelligence]

Если на каждый ip создавать свое правило iptables, то будет вести себя плохо. Для подобных задач можно использовать ipset

[simnetworks]

intelligence CSF в зависимости от настроек может использовать ipset или создавать по отдельному правилу iptables на каждый заблокированный адрес IP. Но это неважно. Если на вас натравят сеть ботов в ~100000 уникальных адресов, то iptables никак не справится с такой атакой, что с ipset, что без оного. Тут потребуется уже профессиональная защита от DDoS. Описанное решение способно противостоять только атакам слабой и средней мощности.

[sunnybear]

100000 уникальных адресов раскидываются балансировщиком на нужное количество нод (10-50) и перестают быть проблемой. Тем более что они все обычно одновременно не используются — т.е. возможна ротация.

[sunnybear]

Проблема в том, что простого iptables достаточно для противодействия атакам малой и средней мощности (до 30-50 Гбит/с), но только в случае отсутствия slow-DDoS (когда идет по 10-20 запросов в минуту с разных IP адресов, что не попадает ни под какие из вышеперечисленных фильтров).
Защита одного конкретно взятого сайта или даже семейства сайтов на одной CMS тоже большой проблемы не представляет: если известна инфраструктура, то быстрее руками дырки почистить. Но если инфраструктура неизвестна, и нужно «на лету» определять, какие запросы являются «вредными», решение будет посложнее.
Единственное технологически отлаженное решение сейчас у QRator, но там много false positive, и цены высокие.

[alexkuzko]

Попросили похожее сделать, дали ссылку на данную статью ;)
Обнаружил что на Debian не всегда заводится, причина даже в конфиге описана, но упомяну ее здесь. В файле /etc/fail2ban/jail.com нужно поставить параметр:
backend = polling
Т.к. auto чаще всего выбирает gamin и… это не работает, особенно если у вас relatime/noatime.