Корпоративная АТС на базе Asterisk предоставляет широкие возможности по обеспечению переговоров в IP-сетях, позволяет более эффективно управлять организацией и существенно экономить на звонках. Но из-за слабой защищенности или неправильной настройки VoIP-сервис может стать причиной серьезных финансовых потерь. В этой статье мы рассмотрим, как этого не допустить.

Проблемы защиты VoIP

Как и любое сетевое приложение, VoIP-сервис подвержен «классическим» атакам, но есть своя специфика. Например, в случае DDoS не обязательно «заваливать» сервер SYN-запросами. Можно «вмешаться» в разговор, отправляя пустые пакеты, на обработку которых сервис будет затрачивать ресурсы, это приведет к задержкам, и разговор вести станет невозможно (атака Call tampering).

Причем взлом VoIP является одним из самых удобных способов монетизации. Так, найдя ошибку в сервисе, злоумышленник может совершать звонки на платные сервисы, «продавать линию» или рассылать аудиоспам. В разное время уязвимости приходилось срочно закрывать безопасникам из Cisco, разработчикам Skype и Asterisk, и таких примеров очень много. Еще одна специфическая проблема — голосовой фишинг и спам (SPIT — spam over Internet telephony или VAM — voice/VoIP spam). В первом случае пользователь вместо того, чтобы работать, слушает рекламу, во втором — абонент получает предложение позвонить на «сервисный» номер (вроде PayPal) для уточнения некоторых вопросов. В итоге он оплачивает разговор по увеличенному тарифу или раскрывает персональные данные. Спит и фишинг еще не стали массовым явлением, но уже замечены, и объемы увеличиваются. Их реализация сама по себе не сложна, требуется всего лишь подготовленный файл и программа дозвона (Asterisk + Spitter).

Еще один частый способ атаки — подбор логинов и паролей, а также перехват данных VoIP. Чтобы реализовать MITM, не обязательно находиться в той же сети, достаточно изменить DNS-запись или перехватить сеанс (SIP registration hijacking). Так как SIP использует UDP, это упрощает атаку. Злоумышленник вклинивается в процесс подключения к серверу, отправляя ложные сведения о клиенте в пакете SIP REGISTER, и регистрируется от имени пользователя. В последующем он пропускает через себя весь трафик. Дальнейшая обработка также не вызывает проблем — снифер Cain & Abel умеет извлекать аудио и сохранять в формат WAV.

Защита VoIP

Увы, защита VoIP не включается одной кнопкой и должна планомерно строиться на всех уровнях, начиная с сетевого уровня (iptables, IPS) и заканчивая правильной настройкой плана набора.

Традиционные межсетевые экраны не могут полностью противостоять специфическим атакам, поскольку они работают на транспортном уровне и не умеют «смотреть» внутрь пакета. Здесь нужны специализированные решения, относящиеся к классу NGFW (Next-Generation Firewall). Сегодня они представлены такими вендорами, как Check Point, Certes Networks, SonicWall. Хотя, например, свободно распространяемые IPS Snort/Suricata уже имеют ряд правил, позволяющих распознать атаки на VoIP.

Могут быть эффективными традиционные мероприятия по борьбе с DoS — регулировка трафика на маршрутизаторе, использование пограничных контроллеров сессий (SBC, session border controllers), правильная настройка сервера и приложения. Так, контроллеры SBC, являясь единой точкой входа и анализируя пакеты в реальном времени, способны предотвращать DDoS-атаки, распространение спама и вирусные эпидемии. Плюс некоторые реализации SBC умеют шифровать трафик, обеспечивая защиту от перехвата в WAN. Под VoIP рекомендуется выделять отдельные сети (физические или VLAN), это позволит скрыть голосовой трафик от пользователей сети и лучше контролировать QoS для VoIP. Хотя не следует считать эту меру панацеей, так как сниферы без проблем найдут трафик VoIP VLAN.

Что касается атаки MITM, то защита от нее давно уже отлажена. Это проверка МАС-адреса на файрволе, использование протокола контроля доступа и аутентификации IEEE 802.1x, шифрование потока. Шифрование, наряду с продвинутыми методами аутентификации и правильной парольной политикой, позволяет защититься от подбора пароля.

В настоящее время реализовано несколько вариантов: VPN, TLS/SSL, SRTP (Secure Real Time Protocol) или ZRTP (Z and Real-time Transport Protocol). Виртуальные сети наиболее популярны у провайдеров услуг, но VPN, увеличивая накладные расходы на передачу пакетов, нередко сами становятся причиной задержек. Да и не с каждым протоколом VPN можно обеспечить соединение удаленному пользователю в конкретных условиях. Кроме того, обычно шифруется канал только между VPN-серверами, а внутри конкретного сегмента сети сотрудники ведут переговоры по незащищенному каналу.

Теперь рассмотрим реализацию этих методов на примере Asterisk.

Протокол SRTP/ZRTP

Оптимальным с точки зрения производительности является SRTP (RFC 3711), позволяющий шифровать (AES) медиапоток и обеспечивать проверку подлинности (HMAC-SHA-1) информации. Однако этот протокол не обеспечивает защиту процесса аутентификации, и необходимо дополнительно использовать сторонние инструменты вроде TLS/SSL. Связку SRTP + TLS/SSL можно легко организовать на Asterisk (с 1.8), FreeSWITCH, SIP-коммутаторе OpenSIPS и других подобных решениях. Кроме того, Asterisk и FreeSWITCH поддерживают протокол ZRTP, который специально разработан для VoIP Филиппом Циммерманном, создателем PGP (отсюда и первая буква Z в названии). Протокол обеспечивает безопасную аутентификацию и обмен данными, стандартизирован в RFC 6189. Во время инициализации ZRTP-звонка используется метод обмена ключами Диффи — Хеллмана, для аутентификации применяется SAS (Short Authentication String). Весь разговор шифруется, причем пара ключей генерируется для каждого сеанса автоматически, что очень удобно, так как позволяет легко встроить этот механизм в уже существующие продукты и не требуется инфраструктура PKI.

В дополнение к SRTP, в канальном драйвере chan_sip из состава Asterisk 11 реализована поддержка безопасного транспортного протокола DTLS-SRTP, предназначенного для передачи мультимедийных RTP-потоков c использованием шифрования, которая может быть задействована для абонентов, использующих WebRTC и SIP.

Конечно, с SRTP и ZRTP должны уметь работать и клиенты (софтофоны и аппаратные): Linphone (TLS, SRTP, ZRTP), Jitsi (TLS, SRTP, ZRTP), Blink (TLS, SRTP), MicroSIP (TLS, SRTP). Некоторая информация доступна на страничке. Сам Циммерманн предложил собственный софтофон Zfone, работающий по ZRTP (есть версии для Windows, Linux и OS X). В настоящее время Zfone находится в состоянии бета, но уже два года по техническим причинам его нельзя скачать с официального сайта.

Настройка SRTP + TLS/SSL в Asterisk

Сервер Asterisk поддерживает TLS между серверами и сценарий клиент — сервер. Для активации TLS достаточно прописать в настройках (sip.conf) всего несколько команд:

tcpenable=yes
tcpbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/cert/asterisk.pem
tlscafile=/etc/asterisk/cert/ca.crt
tlsprivatekey=/var/lib/asterisk/keys/voip.example.org.key
tlsclientmethod=tlsv1

Проверяем подключение:

$ openssl s_client host localhost port 5061

В настройках клиента ставим transport=tls.

RSA-ключи, используемые для шифрования, можно сгенерировать при помощи команды openssl genrsa и специальных скриптов astgenkey (astgenkey -n keyname) или asttlscert (копируют ключи в /var/lib/asterisk/keys). Последние не всегда доступны в пакетах или специальных дистрибутивах вроде Elastix, взять их можно на SVN-сервере.

Теперь подключение безопасно и подсмотреть регистрационные данные нельзя, хотя сами переговоры не шифруются. Штатный для Asterisk протокол IAX2, как и SIP, можно настроить на поддержку шифрования SRTP (AES128). Для этого необходимо добавить всего одну строку в конфиг iax.conf или sip.conf:

encryption=yes

Перезапускаем настройки sip reload/iax2 reload, затем проверяем, загружен ли модуль:

CLI> module show like res_srtp.so

Команда iax show peers должна показать метку (E) напротив подключенных клиентов, означающую, что шифрование активно. В журналах появится запись вида encrypt_frame: Encoding.

Другие статьи в выпуске:

Хакер #179. Интернет вещей — новый вектор атак

• Содержание выпуска
• Подписка на «Хакер»-60%

Защита от подбора пароля

Попытки подбора паролей к SIP-аккаунтам давно уже не редкость, тем более что готовые инструменты лежат в свободном доступе, а простой скрипт пишется за день. Например, комплект утилит SIPVicious позволяет получить списки SIP в указанном диапазоне IP, рабочие расширения (extensions) и подобрать к ним пароль.

Все это приводит к необходимости использовать только устойчивые к взлому пароли, обязательно отключать демоаккаунты и расширения. Имя пользователя, прописываемое в user, не должно быть простым (вроде 101, 102...) и совпадать с названием расширения.

И конечно, надо использовать TLS/SSL, как показано выше, поскольку большинство скриптов просто не поддерживают такую возможность. Гостевые вызовы отключаются в sip.confодной строкой:

allowguest=no

Хотя надо иметь в виду, что некоторые SIP-устройства не смогут устанавливать соединения при такой настройке.

Сервер, в случае ошибки запроса на соединение, отправляет одно из следующих сообщений:

• 401 Unauthorized — несанкционированный доступ (только серверы регистрации);
• 404 Not Found — пользователь не найден;
• 404 Unknown user account — неизвестный логин и пароль;
• 407 Proxy Authentication Required — требуется авторизация для прокси-сервера.

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

$ ./svwar.py -force -e100-1000 192.168.1.1 m REGISTER

Но можно усложнить ему задачу, заставив сервер выдавать одну и ту же ошибку (401 Unauthorized) во всех случаях, для этого нужно внести запись:

alwaysauthreject=yes

По умолчанию сервер выдает полную информацию об используемой версии ПО, поэтому установим в sip.conf произвольные значения:

useragent=VoIPServer
sdpsession=VoIPServer
realm=VoIPServer

Сразу после установки в Asterisk доступно большое количество модулей (в Elastix, например, их 229), некоторые из них никогда не используются. Лишние следует убрать. Проверяем по команде module show и выгружаем — module unload chan_gtalk.so или, если постоянно, прописываем в modules.conf:

noload => chan_gtalk.so

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

Deny=0.0.0.0/0.0.0.0
Permit=192.168.1.10
;macaddress = deadbeef4dad

Теперь подключение клиента будет приниматься только с 192.168.1.10. Аналогичные ограничения следует предусмотреть для AMI-интерфейса (Asterisk Manager Interface) вmanager.conf.

Более сложные параметры доступа задаются при помощи ACL. В Asterisk 11 стали доступны именованные ACL (Named ACL), которые, в отличие от обычных ACL, не привязаны к определенным конфигурациям модуля, поэтому их можно использовать одновременно в нескольких модулях. Настройка NACL производится при помощи тех же Deny/Permit вacl.conf, затем нужный ACL просто подключается в расширении директивой acl.

Желательно «заставить» сервер слушать только определенный интерфейс и изменить используемый порт по умолчанию, прописав в sip.conf следующие записи:

bindaddr = 192.168.1.1
bindport = 7777

Для IAX настройки в iax.conf аналогичны (по умолчанию порт 4569). Изменение порта, конечно, при серьезном исследовании сети не спасет, но потребует дополнительной перестройки всех клиентов. Чтобы не возиться с этим, в некоторых ситуациях можно пробросить порт:

iptables -I FORWARD 1 -d 127.0.0.1 -p tcp --dport 4569 -j ACCEPT

Хотя многие специализированные и самописные скрипты просто тестируют подключение на 5060 и, если он закрыт, игнорируют узел. А сканирование легко заблокировать при помощи IPS. И конечно же, файрволом следует прикрыть SIP-порты 5060/5061, чтобы они не светились наружу.

Что же делать сотрудникам, которые находятся вне LAN? Самые, наверное, простые и проверенные временем рекомендации: VPN или размещение VoIP-сервера с ограниченными возможностями в DMZ. Другой способ — организовать нечто вроде Captive-портала. Например, Travelin Man позволяет автоматически реконфигурировать Asterisk и iptables при подключении пользователя на специальную веб-страницу, после чего он может соединяться с SIP с указанными параметрами.

Еще один вариант — DISA (Direct Inward System Access), предоставляющий возможность через городской номер совершить дозвон до внутренних или внешних абонентов, хотя он подходит не для всех случаев.

exten => s,1,Answer
exten => 000,1,DISA(1234|default)

Более экзотический способ — техника Port Knocking, позволяющая открыть нужный порт после выполнения определенной последовательности попыток подключения к закрытым портам. В Elastix, например, такая функциональность настраивается через веб-интерфейс.

Настройки экстеншна

Междугородние звонки всем сотрудникам, как правило, не нужны, поэтому следует ограничить такую возможность только определенной группе абонентов. Входящие и исходящие звонки должны быть описаны в разных контекстах. Зачастую админы ленятся, используя в описании маршрутов символы замены, и получается что-то вроде:

exten => _5X.,1,Dial(SIP/${EXTEN})

Это может привести к тому, что сотрудник или злоумышленник может позвонить куда угодно. Поэтому следует жестко прописывать все цифры международных кодов, городов или мобильных операторов, четко указывая, куда можно звонить:

exten => _8495XXXXXXX,1,Dial(SIP/${EXTEN})

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

exten => 3XXX,1,GotoIfTime(9:00-18:00|mon-fri|*|*?OUT,s,1)
; include => <context>[|<hours>|<weekdays>|<monthdays>|<months>]
include => daytime|9:00-18:00|mon-fri

В случае нарушения можно предусмотреть отправку почтового сообщения на ящик админа:

same => n,System(echo ${EXTEN}> mail -s "ALARM!!!" admin@example.org)

Чтобы увидеть в журнале IP абонента, можно добавить в диал-план Noop(SIP packet from ${SIPCHANINFO(recvip)}) и далее автоматизировать бан таких хостов с помощью фильтра в fail2ban.

Если сервис все-таки взломали, перед детальным разбором инцидента можно ограничить абонента количеством одновременных соединений, добавив в расширение параметр call-limit=1.

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

В поставке специальных дистрибутивов можно найти аддоны, позволяющие автоматически обнаруживать и блокировать попытки мошенничества, защищать от атак, определять аномалии в вызовах. Например, в Elastix доступны Humbug Analytics, Mango Analytics и Anti-Hacker.

WWW

Security Considerations for Voice Over IP System (NIST SP 800-58): 1.usa.gov/8o8cdC

Список полезных утилит: voipsa.org/Resources/tools.php

Настройка SRTP в FreeSWITCH: wiki.freeswitch.org/wiki/SRTP

Софтофон Zfone: zfoneproject.com

Полезные скрипты для настройки Asterisk: bit.ly/HzOcQ8

Заключение

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