Корпоративные VoIP сети из средства позволяющего сэкономить на звонках, стали неотъемлемой частью бизнес-процессов, ежедневно обеспечивая сотрудников возможностью обмена сообщениями, позволяя более эффективно управлять организацией. Но из-за слабой защищенности или неправильной настройки сервисы могут стать причиной серьезных финансовых потерь.
Проблемы защиты VoIP
Любой VoIP сервис подвержен всем классическим атакам направленными на сетевое приложение, которые могут нарушить его работу. На первом месте по популярности стоит DDOS, затем MITM (Man-in-Middle), спам, вирусы и черви, использующие уязвимости в реализации сервера. Конечно для VoIP в каждом случае есть и своя специфика. Например, в случае DDOS не обязательно «заваливать» сервер запросами открывающими новые соединения. Можно «вмешаться» в разговор отправляя пустые пакеты, на обработку которых будет затрачивать ресурс, что обычно вызывает задержки, а разговор вести уже невозможно (атака Call tampering).
Причем взлом VoIP один из самых удобных способов монетизации хакера. Найдя ошибку в сервисе хакер может выполнить определенные действия: провести DOS, прослушать разговоры, совершать звонки на платные сервисы, или рассылать аудиоспам. В разное время уязвимости приходилось срочно закрывать Cisco, Skype, разработчикам Asterisk и таких примеров очень много. Еще одна специфическая проблема — головосовой фишинг и спам (SPIT (spam over Internet telephony) или VAM (voice/VoIP spam). В первом случае пользователь вместо того чтобы работать слушает рекламу, во втором абонент получает предложение от некоторого популярного сервиса, позвонить на «сервисный» номер для уточнения некоторых вопросов. В итоге либо он оплачивает разговор по увеличенному тарифу или раскрывает персональные данные. Спит и фишинг еще не стали массовым явлением, но уже замечен и объемы увеличиваются. Их реализация сама по себе не сложная, нужен подготовленный файл и программа дозвона (например, Asterisk + Spitter).
Еще одним частым способом атаки является подбор логинов и паролей и перехват данных VoIP. Чтобы реализовать MITM не обязательно нужно находиться в той же сети, достаточно изменить DNS или перехватить сеанс (SIP registration hijacking). Так как SIP использует UDP, это упрощает атаку. Хакер вклинивается в процесс подключения к серверу отправляя ложные сведения о клиенте в пакете SIP REGISTER и регистрируется от имени пользователя. В последующем он пропускает через себя весь трафик. Сниффер Cain & Abel(oxid.it/cain.html) умеет извлекать аудио и сохранять в формат WAV
Защита VoIP
Защита VoIP не включается одной кнопкой и должна строиться на нескольких уровнях: от сетевого (iptables, IPS) до правильной настройки плана набора.
Традиционные межсетевые экраны не могут полностью противостоять специфическим, ведь они работают на транспортном уровне, а не уровне приложения и не умеют смотреть внутрь пакета. Здесь нужны специализированные решения относящиеся к NGFW (Next-Generation Firewall) и представленные сегодня различными вендорами: Check Point Voice over IP, Certes Networks, SonicWall и другие.
Могут быть эффективными традиционные мероприятия по борьбе с DOS — регулировка трафика на маршрутизаторе, использование пограничных контроллеров сессий (SBC, session border controllers), правильная настройка сервера и приложения. Так SBC являясь единой точкой входа и анализируя пакеты в реальном времени, способны предотвращать DDOS-атаки, распространение спама и вирусных эпидемий. Плюс некоторые реализации умеют шифровать трафик. Рекомендовано под 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-SHA1) информации. Однако он не обеспечивает защиту процесса аутентификации и дополнительно необходимо использовать сторонние инструменты вроде TLS/SSL. Связку SRTP + TLS/SSL легко можно организовать на Asterisk (с 1.8), FreeSWITCH (wiki.freeswitch.org/wiki/SRTP), SIP-коммутаторе OpenSIPS и других решениях.
Кроме этого Asterisk и FreeSWITCH поддерживают протокол ZRTP, который специально разработан для VoIP Филиппом Циммерманном (Phil Zimmermann) создателем PGP (отсюда и первая буква Z в названии). Протокол стандартизирован в RFC 6189, обеспечивает безопасную аутентификацию и обмен данными. Во время инициализации ZRTP звонка используется метод обмена ключами Диффи — Хеллмана, для аутентификации применяется SAS (Short Authentication String). Весь разговор шифруется, причем пара ключей генерируется для каждого сеанса автоматически, это очень удобно, так как возможно легко встроить этот механизм в уже существующие продукты и не требуется инфраструктура PKI.
В дополнение к SRTP в Asterisk 11 в канальном драйвере chan_sip добавлена поддержка безопасного транспортного протокола DTLS-SRTP, предназначенного для передачи мультимедийных RTP-потоков c использованием шифрования, которая может быть задействована для абонентов, использующих WebRTC и SIP.
Конечно пс SRTP и ZRTP должны уметь работать и клиенты (софтфоны и аппаратные): Linphone (TLS, SRTP, ZRTP), Jitsi (TLS, SRTP, ZRTP), Blink (TLS, SRTP), MicroSIP (TLS, SRTP). Некоторая информация доступна в (voip-info.org/wiki/view/Asterisk+encryption). Сам Циммерманн предложил собственный софтфон Zfone (zfoneproject.com, в версиях для Linux, Windows и Mac OS X) работающий по ZRTP. В настоящее время Zfone находится в состоянии бета, но уже 2 года скачать его с официального сайта по техническим причинам нельзя.
Настройка 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) или ast_tls_cert (копируют ключи в /var/lib/asterisk/keys). Последние не всегда доступны в пакетах или специальных дистрибутивах вроде Elastix, взять их можно на SVN сервере (svnview.digium.com/svn/asterisk/branches/12/contrib/scripts).
Теперь подключение безопасно, и подсмотреть регистрационные данные нельзя, хотя сами переговоры не шифруются. Штатный для 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 ..».
Защита от подбора пароля
Попытки подбора паролей к SIP аккаунтам не такая уже и большая редкость. Тем более, что готовые инструменты есть в свободном доступе, а простой скрипт пишется за день. Например, комплект утилит SIPVicious (code.google.com/p/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 e 1001000 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 (nerdvittles.com/?p=689) позволяет автоматически реконфигурировать Asterisk при подключении пользователя на специальную веб-страницу, после чего он может соединяться с SIP с указанными параметрами.
Еще вариант DISA (Direct Inward System Access) предоставляющая возможность через городской номер совершить дозвон до внутренних или внешних абонентов.
exten => s,1,Answer exten => 000,1,DISA(1234|default) |
Более экзотический вариант — техника Knocking Port, позволяющая открыть нужный порт, выполнив попытку подключения к закрытым портам с определенной последовательностью. В Elastix например такая функциональность настраивается через веб-интерфейс.
В Asterisk используется специальный SIP Security Event Framework, позволяющий в том числе собирать информацию о проблемах безопасности. Подключив соотвествующий журнал в logger.conf: «security_log => security», мы можем блокировать все попытки перебора пароля при помощи анализатора журналов fail2ban.
Настройки экстешна
Междугородние звонки всем сотрудникам, как правило не нужны, поэтому следует ограничить такую возможность только определенной группе абонентов. Входящие и исходящие звонки должны быть описаны в разных контекстах. Не редко админы ленятся, используя в описании маршрутов символы замены и получается что-то вроде:
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 </months></monthdays></weekdays></hours></context> |
В случае нарушения можно предусмотреть отправку почтового сообщения на потчовый ящик админа:
same => n,System(echo ${EXTEN}> mail -s "ALARM!!!" admin@example.org) |
Чтобы увидеть в журнале IP абонента, можно добавить в диалплан Noop(SIP packet from ${SIPCHANINFO(recvip)}) и далее автоматизировать бан таких хостов с помощью фильтра в fail2ban.
Если уже все таки взломали, то лучше сразу ограничить абонента количеством одновременных соединений добавив в расширение параметр «call-limit=1».
Используемую систему биллинга, лучше сразу настроить на резкое возрастание количества междугородних звонков и установить лимит по расходам на абонента.
В поставке специальных дистрибутивов можно найти специальные аддоны позволяющие автоматически обнаруживать и блокировать попытки мошенничества, защищать от атак, определять аномалии в вызовах. Например в Elastix (addons.elastix.org) доступны Humbug Analytics, Mango Analytics и Anti-Hacker.
Заключение
Сервис VoIP это сложное решение и для его защиты следует применять именно комплексный подход, блокируя возможные угрозы на всех уровнях. Кроме прочего следует беспокоиться и о об обычных мероприятиях: актуальности версии ПО и ОС сервера, обновлении прошивки и безопасности оконечного оборудования.