Компания
22,30
рейтинг
13 октября 2011 в 12:07

Разное → 9 правил, как защитить свой Asterisk!



Сейчас все пишут про большое количество атак на Asterisk и прочих PBX. Живой пример из практики — у товарищей хакеров из КНДР не получилось пробраться на Asterisk, стоящий за простеньким роутером ASUS, почему — об этом далее, но зато у них отлично получилось ломануть, а вернее подобрать пароли к IP телефонам Yealink SIP T-22.

Сделать это было не сложно, стандартные пароли admin/admin все еще очень популярны. И, как показала практика, это может стоить десятки тысяч рублей…

Специалисты MyAsterisk Team составили 9 правил, которые помогут избежать атак хакеров и сохранят средства на Вашем счету.

Правило первое: Всегда менять логины и пароли на вех сетевых устройствах. Особенно на IP телефонах, VoIP шлюзах и т.д.

Пароли абонентов, админов, менеджеров Asterisk и т.д. должны состоять, не менее чем из 12 символов (буквы, цифры, перемена регистра), используйте сложные логины и пароли. Не соблюдение этого простого правила для некоторых уже стоило 15 000 рублей.

Правило второе: Использовать нестандартные порты SIP, IAX, SSH.

Меняйте стандартные порты на любые другие. Чем он будет больше непохож на стандартный – тем лучше.

SIP: Настройка порта производится в файле sip. Conf в секции general:
Bindport=5060 => bindport=5172

SSH: Новый порт не должен конфликтовать с уже открытыми в системе портами. Например, будем использовать 9321. Редактируем /etc/ssh/sshd_config

Удаляем знак # перед изменением. Port 9321
После чего перезапустим sshd для применения изменений, используя команду:
service sshd restart

IAX: Заходим в /etc/asterisk/iax.conf
меняем в строке порт на любой свободный ;bindport=4569
Перезапускаем Asterisk командой /etc/ininit.d/asterisk restart

Правило третье: Использовать пользователя с правами доступа по SSH.

Следует создать юзера и наделить его правами доступа только по SSH. Например, создадим пользователя myasterisk и зададим ему пароль. Пароль должен содержать символы, числа и буквы со сменой регистра.

# useradd myasterisk
# passwd myasterisk


Отредактируем /etc/ssh/sshd_config, добавив в него следующую строчку: AllowUsers myasterisk

Запретить пользователю root подключаться к серверу Asterisk по SSH: PermitRootLogin no

Правило четвертое: Задать разрешенные адреса для внутренних абонентов (Deny/Permit).

Данная настройка ограничивает возможность регистрации внутренних абонентов только с доверенных IP адресов. Для каждого экстеншена задаем диапазон адресов или допустимый IP адрес.

123
Deny=0.0.0.0/0.0.0.0
Permit=10.10.1.7
Permit=10.10.2.1/24

Где 10.10.2.1/24 – диапазон локальных адресов, с которых будет производится подключение. Подключения с других адресов Asterisk принимать не будет.

Правило пятое: Отключить гостевые вызовы (guest-звонки) и регистрации

Необходимо отредактировать /etc/asterisk/sip.conf
строку Allowguest=yes заменить на allowguest=no; Allow or reject guest calls (default is yes)

Данный вариант подойдет не всем пользователям, иногда бывает, что отказаться от guest-вызовов не представляется возможным.

Правило шестое: Установить лимит звонков

В том случае, если вас уже взломали, потерять меньше денег поможет строка Call-limit=1, прописанная в настройках ваших внутренних абонентов Эта строка ограничивает количество одновременных соединений.вашего внутреннего абонента.

Правило седьмое: Использовать различные правила исходящей маршрутизации

Не стоит лениться и использовать дефолтные маршруты, типа Exten => _X.,1,Hangup. Следует жестко прописывать направления с кодами городов, операторов мобильной связи и международных кодов (если такое вообще нужно), на пример: 8495XXXXXXX, 8961XXXXXXX, 89ХХXXXXXXX и т.д.

Правило восьмое: Отключить ответ о неверном пароле

По умолчанию Asterisk выдает одну ошибку о неверном пароле для существующего аккаунта и другую для несуществующего аккаунта. Существует множество программ для подбора паролей, поэтому злоумышленнику не составит труда проверить все короткие номера и собирать пароли лишь к существующим аккаунтам, которые ответили «неверный пароль». Чтобы помешать этому, меняем строчку в файле /etc/asterisk/sip.conf:
alwaysauthreject = no на alwaysauthreject = yes
и перезапускаем Asterisk.

После такой настройки, Asterisk будет отвечать одинаково для любых неверных авторизации «401 Unauthorized» и не сообщать подробностей.

Правило девятое: Использовать Iptables и Fail2ban

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».

Дело в том, что в 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:


Спасибо, Сергею Тамковичу за 9 правило.

Также MyAsterisk Team рекомендует обсудить с вашим Sip провайдером возможность регистрации только с вашего ip адреса, установить лимит расходования средств в сутки, исходя их ваших средних затрат и не лишним отключить междугороднюю и международную связь, если вы ей не пользуетесь, или сделать возможным совершать исходящие МГ и МН вызовы после ввода pin кода.

Cоблюдайте правила безопасности от MyAsterisk Team, чтобы не стать очередным героем этого ролика!

Автор: @MyAsterisk_Team
MyAsterisk
рейтинг 22,30
Реклама помогает поддерживать и развивать наши сервисы

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

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

  • +1
    Я бы ещё добавил alwaysauthreject=yes в sip.conf. Это предотвратит возможный перебор существующих пользователей.
    • +1
      Да, согласен! После такой настройки, Asterisk будет отвечать одинаково для любых неверных авторизации «401 Unauthorized» и не сообщать подробностей
  • 0
    >15 000 рублей
    Известны случаи и на 2-3 млн попадали организации.
    раз, два, три
    И такие количество таких атак будет только увеличиваться. Судя по тому какое недавно пришло письмо интересное, такими взломами уже и «пионеры» интересуются:

    «здравствуйте
    пишите софт под заказ?
    комплект для скана сети на sip-оборудование, парсер логов которые получаться после сканирования (отсеивает мусор и оставляет только PBX-станции), сканер отпарсенных логов на открытый 80 порт (сканирует почищенные логи на открытый Web-доступ к станции), один сканер (ищет станции по другому принципу — доступность для перебора паролей), парсер для обработки станций для подбора паролей, список диапазонов ip для всех стран мира, python (интерпретатор языка програмирования на котором написан сканер — нужен для запуска сканера) „

    Мы конечно отказались, но ведь найдется тот кто напишет.
  • 0
    На фрилансе найдутся такие спецы)
  • 0
    А я просто разрешил трафик только к провайдеру телефонии, и телефонам, всё остальное Дроп. После ваших процедур вы всё равно не будете уверены что в сип стеке астериска не найдут дыру.
  • +1
    Это всё очень интересно. У меня защитную роль играет fail2ban и пара настроек в самом asterisk. Надо будет попробовать еще и с iptables заморочиться.

    А никто не задавался вопросом, почему вдруг усилился интерес к PBX серверам?
    • 0
      Потому что за 1 день хакеры «зарабатывают» больше 100 тысяч долларов с одного абонента.
      «Истец требовал взыскать с ответчика стоимость около 90 тысяч минут звонков по всему миру — 3 млн 425 тыс. рублей. В суде представитель истца сообщил, что с номера абонента в один из дней было совершено около 10 тысяч соединений. Звонили в Египет, на Кубу, Гаити и т.д. Общая продолжительность разговоров составила около 90 тысяч минут.»
      То что Ростелеком не смог взыскать это все ерунда, хакеры свое уже получили.
  • 0
    Недавно присутствовал на экспертизе, НПО «попало» на сумму порядка 12000$ по вине сисадмина, неприменившего acl правила на интерфейсе циски. В итоге сип порт открыт, веб открыт, по сипу без аутентификации за три дня шли звонки на десяток стран: латвию, эстонию, гвинею и т.д.
    • 0
      И даже access-list не достаточно. Попробуйте прикрыть, а потом раза 3 подряд прогнать nmap например. Можете узнать много нового о своей циске. Если у вас маршрутизатор смотрит в интернет, то желательно обновить ios до 15.1 и прикрыться рефлективными листами. Или поставить на интернет Cisco ASA.
  • 0
    Я бы все эти пункты заменил на пару:
    1. на уровне файрволов: запретить ВСЁ кроме того откуда приходит трафик.
    2. межгород подключить в режиме предоплаты (с запретом ухода в минус) международку отключить на уровне оператора.
    3. в локалке вынести весь VoIp траффик в отдельный vlan.

    всё это относится к офисной телефонии.

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

Самое читаемое Разное