Tamkovich.com: Телеком/VoIP блог

Защита Asterisk от SIP атак с помощью iptables

18 июня, 2011 by Сергей Тамкович

Думаю все слышали про программу 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:

-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: "

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

В некоторых системах встроенное ограничение модуля recent на параметр hitcount весьма небольшое, например в CentOS это ограничение составляет 20 пакетов. Если вы попробуете выполнить приведенную выше команду, то получите следующую ошибку:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "
iptables: Unknown error 4294967295

Или вот так, для 64 битных систем:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "
iptables: Unknown error 18446744073709551615

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

options ipt_recent ip_pkt_list_tot=60

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

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

Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=369 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=349
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350

8 комментариев to “Защита Asterisk от SIP атак с помощью iptables”

1. on 20 Июн 2011 at 15:17   Ben-Ja
   
   

   Хмм… А почему бы не выбрать пакеты начала сессии (например при помощи -m string) и не поставить на них ограничение по времени?
   Ну например, по аналогии с пингом:
   iptables -A INPUT -p icmp —icmp-type 8 -m limit —limit 1/s —limit-burst 1 -j ACCEPT
   iptables -A INPUT -p icmp —icmp-type 8 -j DROP
   Будет пропускать один входяший пинг пакет в секунду, а остальные дропать.
   Почему бы не сделать нечто похожее и пропускать один пакет установления связи в 2сек. а остальным говорить «досвидания» (reject)? ведь тогда получится что мы не просто ведем логи, а еще и не даем начать новые сессии флудерам.

2. on 20 Июн 2011 at 17:25   Сергей Тамкович
   
   

   Преимуществ описанного подхода (выделять какие-то пакеты с помощью модуля string) перед моим — я не вижу, если они есть — опиши их пожалуйста развёрнуто. Недостаток же я вижу сходу. Флудить могут не только пакетами с началом SIP-сессий, но и любыми другими пакетами. В общем случае могут вообще мусор слать на SIP порт. Заглядывать внутрь SIP пакетов смысла нет, брутфорсерские SIP пакеты ничем не отличаются от обычных обычных, отличительная черта роботов — большое количество SIP пакетов с одного адреса в единицу времени — по этому критерию их и надо выявлять.

3. on 21 Июн 2011 at 13:23   Ben-Ja
   
   

   >отличительная черта роботов – большое количество SIP пакетов с одного адреса в единицу времени – по этому критерию их и надо выявлять.

   Их надо не выявлять, а банить автоматом. Причем делать это можно средствами самого iptables.

   Хм… Ну тут громадное поле для творчества.
   Вобщем, есть над чем подумать…

4. on 18 Сен 2011 at 23:12   DonRumata
   
   

   хорошая статья, имхо лучше выявлять, чем сидеть и думать чо так тихо стало внезапно…

5. on 18 Мар 2012 at 13:02   Mistral
   
   

   Мой способ защиты от флуда, такой себе SBC.

   ….
   -A INPUT -p udp -m state —state NEW -m udp —dport 5060 -j SIP-BORDER
   ….

   -A SIP-BORDER -m string —string «tel:» —algo bm —to 65 -j REJECT —reject-with icmp-host-prohibited
   -A SIP-BORDER -m string —string «OPTIONS SIP:» —algo bm —to 65 -j ACCEPT
   -A SIP-BORDER -m string —string «INVITE SIP:» —algo bm —to 65 -m hashlimit —hashlimit-upto 4/min —hashlimit-burst 1 —hashlimit-mode srcip,dstport —hashlimit-name sip_i_limit -j ACCEPT
   -A SIP-BORDER -m string —string «REGISTER SIP:» —algo bm —to 65 -m hashlimit —hashlimit-upto 2/min —hashlimit-burst 1 —hashlimit-mode srcip,dstport —hashlimit-name sip_r_limit -j ACCEPT
   -A SIP-BORDER -m hashlimit —hashlimit-upto 10/min —hashlimit-burst 1 —hashlimit-mode srcip,dstport —hashlimit-name sip_o_limit -j ACCEPT
   -A SIP-BORDER -j REJECT —reject-with icmp-host-prohibited
   ….

6. on 15 Янв 2015 at 05:56   Valentin
   
   

   Несмотря на приличный срок давности этой статьи,
   имеются существенные и верные описания правил
   для файервола…

7. on 30 Ноя 2015 at 17:39   Сергей
   
   

   Не могли бы пояснить по правилам iptables? в вашем примере первое правило
   -A INPUT -p udp —dport 5060 -j SCAMBLOCK
   отправляет все сип пакеты в некую цепочку SCAMBLOCK. а что это за цепочка и откуда в ней возникнут списки нежелательных адресов?
   и ещё, из этой цепочки нужно делать возврат или по достижении конца цепочки мы и так оттуда выйдем на вторую строку вашего примера?

8. on 30 Апр 2019 at 19:08   Dmitry
   
   

   В статье описано только то, что сделать для попадания сообщений о флуде в лог,
   но ведь нужно еще fail2ban на эти сообщения настроить.

   Как?

Оставить отзыв

Имя

Mail

Website

CAPTCHA Code *

Current month ye@r day *

Leave this field empty *