asterisk.ru

Думаю все слышали про программу Fail2ban, а некоторые даже умеют настраивать её для работы с логом Asterisk. Действительно, вылавливая строки вида «failed for ’127.0.0.1′ – Wrong password» и «failed for ’127.0.0.1′ – Peer is not supposed to register» – можно существенно сократить количество мусорного SIP трафика. Однако, есть несколько неприятных ситуаций, в которых анализ лога Asterisk не поможет. Например, в случае когда злоумышленник посылает запрос REGISTER без идентификационных данных – в логе никогда не появится сообщение «Wrong password».

Лично я не особо боюсь того, что к моей системе подберут пароль одного из клиентов. Вероятность данного события мала, поскольку все пароли в системе стойкие. И даже если пароль подберут, у большинства клиентов установлено ограничение на 1-2 одновременных вызова. Для меня неприятность SIP брутфорса заключается в другом. Дело в том, что в Asterisk вся SIP UDP сигнализация обрабатывается одним единственным тредом. Обработка SIP трафика – ресурсоёмкий процесс, 7-8 мегабит мусорных запросов заставляют Asterisk полностью скушать ядро процессора (например Intel E5335, E5405). Когда ядро полностью съедено, происходит вытеснение полезного SIP трафика – мусорным. Перестают работать DTMF у клиентов использующих SIP INFO. Начинаются проблемы с установкой новых и завершением существующих соединений. И вот это – основная угроза которую несут роботы-брутфорсеры.

Так как же бороться с проблемами о которых нет сообщений в логах? Очень просто – необходимо сгенерировать сообщение о проблеме самому, тогда всю остальную часть нашей системы противодействия (например программу fail2ban) можно будет оставить без изменений. Характерным признаком брутфорса является большое количество SIP пакетов в единицу времени. Посчитать количество пакетов в единицу времени можно с помощью модуля iptables под названием recent. В интернете есть много примеров как с помощью модуля recent отбрасывают пакеты приходящие с частотой выше определённой. Мы, вместо отбрасывания, будем генерировать сообщения для нашей системы обнаружения атак (например fail2ban). Такой подход имеет свои недостатки и преимущества. Основным недостатком является, то что на обработку сообщений будут тратиться ресурсы системы, тогда как отбрасывание пакета условно бесплатное. Преимуществ чуть больше: мы сможем воспользоваться всеми возможностями нашей системы обнаружения атак, такими как белые списки IP адресов, единообразный учёт всех обнаруженных атак и так далее.

От теории – к практике! Подготовим скелет из правил iptables: Первое правило проверяет наш пакет по цепочке SCAMBLOCK. В данной цепочке хранятся заблокированные IP адреса, если пакет совпадает с одним из адресов этой цепочки – он отбрасывается. Если пакет не отброшен, то во втором правиле он помечается для учёта под именем SIP. Третье правило считает не превысил ли данный пакет указанное количество (60) за указанное время (2 секунды). Если количество не превышено – правило игнорируется, если превышено – выполняется действие. В нашем случае в системный лог пишется детальная информация о пакете начинающаяся со строки «SIP flood detected: «. Количество пакетов и время считаются отдельно для каждого источника. Таким образом получается, что мы ограничили скорость приёма SIP пакетов от каждого незаблокированного IP адреса на уровне 30 пакетов в секунду. Для меня данное ограничение является комфортным, с одной стороны все клиенты, даже самые крупнные, шлют пакеты с одного IP адреса со скоростями ниже 30 пакетов/с, с другой стороны, 30 пакетов в секунду практически не отражаютя на работе системы. Возможно, что эту величину следует подправлять в ту или иную сторону в зависимости от производительности сервера, количества и типа абонентов.

В некоторых системах встроенное ограничение модуля recent на параметр hitcount весьма небольшое, например в CentOS это ограничение составляет 20 пакетов. Если вы попробуете выполнить приведенную выше команду, то получите следующую ошибку: Или вот так, для 64 битных систем: Изменить максимальное ограничение можно передав модулю recent специальный параметр при загрузке. Для этого создадим файл /etc/modprobe.d/ipt.conf и пропишем в нём интересующий нас параметр:

options ipt_recent ip_pkt_list_tot=60

Будьте осторожны увеличивая данное ограничение, помните что вместе с ним увеличивается память, требуемая для хранения последних пакетов, а также количество циклов процессора требуемые на их обработку.

Ну вот и всё, теперь любой флуд на порт 5060 будет обнаружен с помощью модуля recent пакета iptables. Сообщение об обнаруженном флуде будет направлено в системный лог где его сможет увидеть наша любимая система обнаружения атак (например fail2ban). iptables не ограничивает нас одним лишь системным логом, действию LOG можно указать уровень (level) и facility сообщения, а в настройках Syslog перенаправить данные сообщения в отдельный файл. Сами же сообщения о SIP флуде будут выглядеть вот так: Оригинал статьи - http://tamkovich.com/2011/06/defending- ... -iptables/

ded, статейка оч. неплохая. Вообщем понятно, что для fail2ban можно добавить собственные события - это есть в доке на fail2ban, однако в рекомендациях по настройке iptables для * есть
# iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
# iptables -A INPUT -p tcp --syn -j DROP
И потом, даже если работать без NAT, то можно подключиться через роутер (например cisco), а там есть
достаточно надежный механизм для защиты от подобной гадости. (чтобы не грузить проц на сервере)

Это не помогает разве ?

Кому? Мне, или Сергею Тамковичу (который эту статью написал)?
Мы используем всякие механизмы, и там где есть - Cisco access-list (of course).
-p tcp --syn -m limit --limit 1/s -j ACCEPT - защищает от флуда tcp syn-атак, а в Астериске трафик udp в основ

ded, если я правильно понял, Вы разместили статью для того, чтобы её прочитали и возможно высказали свое мнение на эту тему. Ну да, я поставил в строках tcp, понятно что это не udp - не надо так уж "передергивать". UDP - отличается от tcp только тем, что доставка "не гарантирована", но никто не запрещал указать в iptables UDP, примерно в таком же ключе как я и написал. Масса примеров-мучений в инете на эту тему. Метод, защиты от UDP flood может быть и проще чем у автора этой статьи, вопрос только в том - как будет загружен процессор ?
Кому-то вообще достаточно просто ограничить количество соединений посредством iptables, чем городить этот огород.
- Не очень-то понятно, на какую же массированную атаку это должно быть расчитано ? Всем миром навалятся ? А какова полоса канала(у asterisk) по отношению к атаке,чтобы asterisk вообще потерял способность отвечать ?
можно посмотреть еще вот это http://conference.cluj.roedu.net/papers/12.pdf

Для UDP не бывает SYN атак.
Всем миром навалятся - легко, для этого и существуют бот-неты.

Учебные кинофильмы:
http://www.youtube.com/watch?v=VCoz_gnfCIc
http://www.youtube.com/watch?v=2phV23pAD8k

ded, да не так легко как кажется, есть еще провайдер через которого Вы подключены. Отчасти это и его проблема.И потом, за udp food можно и заработать ...

Да, можно, на этом именно зарабатывают: продают готовые бот-неты и менеджмент к ним.
Можно загасить почти что всё что угодно.

ded, ну хорошо. например я ограничиваю количество подключений примерно так
iptables -I INPUT -p udp --dport 5060 -j DROP -m iplimit --iplimit-above 1000
После чего меня "гасят" и подключиться никто не может снаружи - ни свои ни чужие - кому от этого польза ? Что трафик своруют ? - если навалятся всем миром - у этого автора какого размера таблица то будет ? даже если он ее чистит...
Это решение как раз не очень-то расчитано на то, что всем миром навалятся...

заработать не в этом смысле, а срок

У меня трафик по протоколу 5060 - 7Gb за сутки на вход к MyPBX 400. Звонков в этот день небыло. В iptables перенаправил на MyPBX 400 порт 5060 по udp и по tcp. Почему такой огромный трафик?

Уместный вопрос. И своевременный.