27 Апр
2012
Рубрика: Asterisk, Linux
Автор:    Комментариев нет

Iptables и Fail2ban для защиты Asterisk. Часть 1

Fail2ban являет собой инструмент, помогающий отслеживать такие строки, как «failed for 127.0.0.1 – Wrong password», а также «failed for 127.0.0.1 – Peer is not supposed to register» . Кроме того, Fail2ban способен существенным образом сократить объем мусорного трафика SIP.

Необходимо отметить наличие нескольких малоприятных ситуаций. В этих ситуациях анализ лога Asterisk помочь явно не сможет. Вот, к примеру, случай, в котором злоумышленники посылают REGISTER запросы без наличия идентификационных данных, никогда не отобразит в логе сообщение вида «Wrong password».

Все потому, что сигнализация SIP UDP в Asterisk обрабатывается при помощи одного единственного треда. Что касается обработки SIP трафика, то он является использующим значительное количество ресурсов процессора.

У клиентов, которые пользуются SIP INFO, периодически прекращается действие DTMF. Кроме того, регулярно возникают проблемы различного характера с установкой новых соединений, а также с завершением действующих. Все это приходится основной угрозой несущих роботов-брутфорсеров.

Вы зададите вопрос, как преодолевать проблемы, о которых на логах нет ни единого упоминания? Оказывается, все довольно просто. Все, что необходимо – это произвести генерацию сообщения о проблеме самостоятельно. Вот тогда вся остальная часть системы противодействия (к примеру, программа Fail2ban) сможет остаться неизменной.

Что выступает одним из характерных брутфорсу признаком? Итак, это огромное количество отправки SIP пакетов за определенную временную единицу.

Как посчитать возможное количество таких пакетов за одну временную единицу? Это можно осуществить при помощи iptables модуля, название которому Recent. На сетевых просторах содержится огромное количество ответов на вопросы, как при помощи данного модуля (recent) можно отбросить все приходящие пакеты с ранее определенной частотой. Каждый пользователь вместо того, чтобы отбросить пакет, должен сначала сгенерировать сообщения для системы, обнаруживающей атаки (fail2ban). Подобный подход славится как преимуществами, так и острыми недостатками.

Что касается недостатков, то основной из них – это заметные затраты системных ресурсов на обработку определенных сообщений, хотя возможность отбрасывать пакет является, казалось бы, условно бесплатной.

Количество преимуществ, разумеется, гораздо больше чем недостатков, а именно, благодаря новой возможности воспользоваться данной системой обнаружения различных атак и так далее.

Подготовим основу из правил iptables:

-A INPUT -p udp —dport 5060 -j SCAMBLOCK
-A INPUT -p udp —dport 5060 -m recent —set —name SIP
-A INPUT -p udp —dport 5060 -m recent —update —seconds 2 —hitcount 60 —name SIP \
-j LOG —log-prefix «SIP flood detected:»

Приведенное требование определет пакет с помощью цепочки SCАMBLOK. Именно внутри этой цепочки имеют место быть все заблокированные по разным причинам адреса IP. В случае выявления найденного хоть одного совпадения с одним из пакетов списка, пакет незамедлительно отбрасывается.

В случае не отбрасывания пакета используется второе правило, то есть пометка для учета, именуемого SIP. Что касается правила под номером три, то оно производит подсчеты, не состоялось ли превышение данного пакета.

В случае не превышения количества, правило тут же игнорируется, а если превышено, то незамедлительно выполняется конкретное действие. Системный лог в нашем с вами случае безнадежен. Прописывается пакетная детальная информация. Пакетная информация начинается с такой строки, как «SIP flood detected:». Время и количество пакетов для каждого источника отдельно рассчитываются. Из этого следует, что мы совершили ограничение по скорости приема пакетов SIP от каждого IР, которое не заблокировано, уровень составляет тридцать пакетов в секуду.

Что вы думаете об этом?