Очень интересную статью о безопасности в IP телефонии, опубликовали на сайте linkmeup.ru . Выкладываем ее без изменений, так сказать, от автора.

=======================

Здравствуйте, коллеги и друзья, я, Семенов Вадим, совместно с командой проектаnetwork-class.net представляем вниманию обзорную статью, которая затрагивает основные тенденции и угрозы в IP телефонии, и самое главное, те инструменты защиты, что на данный момент предлагает производитель в качестве защиты (если выражаться языком специалистов по безопасности, то рассмотрим какие инструменты предлагает производитель для уменьшения уязвимостей, которыми смогут воспользоваться нелегитимные лица). Итак, меньше слов– переходим к делу.
Для многих читающих термин IP телефония уже давно сформировался, а также и то, что данная телефония «лучше», дешевле по сравнению с телефонией общего пользования (ТФОП), богата различными дополнительными функциями и т.д. И это действительно так, однако… отчасти. По мере перехода от аналоговой (цифровой) телефонии со своими абонентскими линиями (от абонентского телефона до станции или станционного выноса) и соединительными линиями (меж станционная линия связи) ни много ни мало были только лишь в зоне доступа и управления провайдера телефонии. Иными словами, обычным обывателям туда доступа не было (ну или практически так, если не учитывать кабельную канализацию). Вспоминается один вопрос на старом добром форуме хакеров «Подскажите, как получить доступ к АТС? – ответ: «Ну как, берешь бульдозер – таранишь стену здания АТС и вуаля». И эта шутка имеет свою долю правды) Однако с переносом телефонии в дешевую IP среду мы получили в довесок и те угрозы, которые несет в себе открытая IP среда. Примером приобретенных угроз может служить следующее:

Сниффинг сигнальных портов с целью совершения платных вызовов за чужой счет
Подслушивание за счет перехвата голосовых IP пакетов
Перехват звонка, представление нелегитимным пользователем как легитимный пользователь, атака «человек по середине»
DDOS атаки на сигнальные сервера станции с целью вывода из строя всей телефонии
Спам-атаки, обрушение большого количества фантомных вызовов на станцию с целью занять все её свободные ресурсы

Несмотря на очевидность в необходимости устранять все возможные уязвимости дабы уменьшить вероятность реализации той или иной атаки - по факту внедрение тех или иных мер защиты необходимо начинать с составления графика, учитывающего стоимость внедрения защитных мер от конкретной угрозы и убытков предприятия от реализации злоумышленниками этой угрозы. Ведь глупо тратить денег на безопасность актива больше, чем стоит сам актив, который мы защищаем.
Определив бюджет на безопасность, начнем устранение именно тех угроз, которые наиболее вероятны для компании, например для малой организации больнее всего будет получить большой счет за несовершенные междугородние и международные звонки, в то время как для государственных компаний важнее всего сохранить конфиденциальность разговоров. Начнем же постепенное рассмотрение в текущей статье с базовых вещей – это обеспечение безопасного способа доставки служебных данных от станции к телефону. Далее рассмотрим аутентификацию телефонов перед подключением их к станции, аутентификацию станции со стороны телефонов ну и шифрование сигнального трафика (для скрытия информации кто и куда звонит) и шифрование разговорного трафика.
У многих производителей голосового оборудования (в том числе и у Cisco Systems) есть уже интегрированные инструменты безопасности от обычного ограничения диапазона ip адресов, с которых можно совершать вызовы, до аутентификации оконечных устройств по сертификату. Например, у производителя Cisco Systems с его голосовой линейкой продуктов CUCM (Cisco Unified CallManager) с версии продукта 8.0 (дата выхода в свет май 2010г.; на данный момент доступна версия 10.5 от мая 2014г.) стала интегрироваться функция «Безопасность по умолчанию». Что она в себя включает:

Аутентификация всех скачиваемых по/с TFTP файлов (конфигурационные файлы, файлы прошивки для телефонов т.д.)
Шифрование конфигурационных файлов
Проверка сертификата с инициализации телефоном HTTPS соединения

Давайте рассмотрим пример атаки «человека по середине», когда нелегитимное лицо перехватывает конфигурационный файлы для телефонов, из которого телефон узнает на какую станцию ему регистрироваться, на каком протоколе работать, какую прошивку скачивать и т.д. Перехватив файл, злоумышленник сможет вносить в него свои изменения либо полностью затереть файл конфигурации, тем самым не дав телефонам всего офиса (см. рисунок) зарегистрироваться на станции, а, следовательно, лишив офиса возможности совершать звонки.

Рис.1 Атака «человек посередине»

Для защиты от этого нам понадобятся знания по несимметричному шифрованию, инфраструктуре открытых ключей и представления о составляющих «Безопасности по умолчанию», с которыми мы сейчас познакомимся: Identity Trust List (ITL) и Trust Verification Service (TVS). TVS – сервис, предназначенный для обработки запросов с IP телефонов, у которых нет ITL или CTL файла во внутренней памяти. IP телефон обращается к TVS в случае необходимости удостовериться может ли он доверять тому или иному сервису перед тем, как начать обращаться к нему. Станция к тому же выступает в роли репозитория, хранящем сертификаты доверенных серверов. В свою очередь ITL представляет собой список из открытых ключей составляющих кластер станции элементов, но для нас важно, что там хранится открытый ключ TFTP сервера и открытый ключ TVS сервиса. При первоначальной загрузке телефона, когда телефон получил свой IP адрес и адрес TFTP сервера, он запрашивает наличие ITL файла (рис.2). Если он есть на TFTP сервере, то, слепо доверяя, загружает его в свою внутреннюю память и хранит до следующей перезагрузки. После скачивания ITL файла телефон запрашивает подписанный конфигурационный файл.

Теперь рассмотрим как мы сможем использовать инструменты криптографии – подписывание файла с помощью хеш-функций MD5 или SHA и шифрование с помощью закрытого ключа TFTP сервера (рис.3). Особенность хеш-функций заключается в том, что это однонаправленные функции. По полученному хешу с какого-либо файла, нельзя проделать обратную операцию и получить в точности оригинальный файл. При изменении файла - изменяется и сам хеш, полученный с этого файла. Стоит отметить, что хеш не записывается в сам файл, а просто добавляется к нему и передается совместно с ним.

Рис.3 Подписывание файла конфигурации телефона

При формировании подписи берется сам конфигурационный файл, извлекается с него хеш и шифруется закрытым ключом TFTP сервера (который обладает только TFTP-сервер).
При получении данного файла с настройками, телефон первоначально проверяет его на целостность. Мы помним, что хеш - это однонаправленная функция, поэтому телефону не остается ничего делать, кроме как отделить зашифрованный TFTP сервером хеш от конфигурационного файла, расшифровать его с помощью открытого ключа TFTP (а откуда его знает IP телефон? – а как раз из ITL файла), из чистого конфигурационного файла вычислить хеш и сравнить его с тем, что мы получили при расшифровании. Если хеш совпадает - значит при передаче в файл не вносились никакие изменения и его можно смело применять на телефоне (рис.4).

Рис.4 Проверка файла конфигурации IP телефоном

Подписанный конфигурационный файл для телефона представлен ниже:

Рис. 5 Подписанный файл IP телефона в Wireshark

Подписав конфигурационный файл, мы смогли обеспечить целостность передаваемого файла с настройками, однако мы не защитили его от просмотра. Из пойманного файла конфигурации можно получить достаточно много полезной информации, например ip адрес телефонной станции (в нашем примере это 192.168.1.66) и открытые порты на станции (2427) и т.д. Не правда ли достаточно важная информация, которую не хотелось бы просто так «светить» в сети? Для скрытия данной информации производители предусматривают использование симметричного шифрования (для шифрования и дешифрования используется один и тот же ключ). Ключ в одном случае может быть введен на телефон вручную, в другом случае шифрование файла конфигурации телефона на станции происходит с использованием открытого ключа телефона. Перед отправлением файла телефону – tftp сервер, на котором хранится этот файл, шифрует его с помощью открытого ключа телефона и подписывает с помощью своего закрытого ключа (тем самым мы обеспечиваем не только скрытость, но и целостность передаваемых файлов). Здесь главное не запутаться, кто какой ключ использует, но давайте разберем по порядку: tftp сервер, зашифровав файл открытым ключом IP телефона, обеспечил тем самым, что этот файл сможет открыть только владелец парного открытого ключа. Подписав файл своим закрытым ключом, tftp сервер подтверждает, что именно он создал его. Зашифрованный файл представлен на рисунке 6:

Рис.6 Зашифрованный файл IP телефона

Итак, на данный момент мы рассмотрели возможность защищать наши конфигурационные файлы для телефонов от просмотра и обеспечивать их целостность. На этом функции «Безопасности по умолчанию» заканчиваются. Для обеспечения шифрования голосового трафика, скрытия сигнальной информации (о том кто звонит и куда звонит), необходимы дополнительные инструменты, основанные на списке доверенных сертификатов – CTL, который мы рассмотрим далее.

Аутентификация телефонной станции

Когда телефону необходимо взаимодействие с телефонной станцией (например, согласовать TLS соединение для обмена сигнализации), IP телефону необходимо аутентифицировать станцию. Как можно догадаться, для решения данной задачи также широко используются сертификаты. На данный момент современные IP станции состоят из большого количества элементов: несколько сигнальных серверов для обработки вызовов, выделенный сервер администрирования (через него добавляются новые телефоны, пользователи, шлюзы, правила маршрутизации и т.д.), выделенный TFTP сервер для хранения файлов конфигурации и программного обеспечения для телефонов, сервер для вещания музыки на удержании и проч, кроме этого в голосовой инфраструктуре может быть голосовая почта, сервер определения текущего состояния абонента (online, offline, «на обеде») – список набирается внушительный и, что самое главное, каждый сервер имеет свой самоподписанный сертификат и каждый работает как корневой удостоверяющий центр (рис.7). По этой причине любой сервер в голосовой инфраструктуре не будет доверять сертификату другого сервера, например голосовой сервер не доверяет TFTP серверу, голосовая почта – сигнальному серверу и к тому же телефоны должны хранить у себя сертификаты всех участвующих в обмене сигнального трафика элементов. Сертификаты телефонной станции изображены на рисунке 7.

Рис.7 Самоподписанные сертификаты Cisco IP станции

Для задач установления доверительных отношений между вышеописанными элементами в голосовой инфраструктур, а также шифрования голосового и сигнального трафика в игру входит так называемый список доверенных сертификатов Certificate Trust List (CTL). CTL содержит все самоподписанные сертификаты всех серверов в кластере голосовой станции, а также участвующих в обмене сигнальными сообщениями телефонии (например, файервол) и этот файл подписывается закрытым ключом доверенного центра сертификации (рис.8). CTL файл эквивалентен проинсталлированным сертификатам, которые используются в работе веб браузеров при работе с https протоколом.

Рис.8 Список доверенных сертификатов

Для того чтобы создать CTL файл на оборудовании Cisco, потребуется ПК с USB разъемом, установленная на нем программа CTL client и сам токен Site Administrator Security Token (SAST) (рис.9), содержащий закрытый ключ и X.509v3 сертификат, подписанный центром аутентификации производителя (Cisco).

Рис.9 eToken Cisco

CTL client - программа, которая устанавливается на Windows ПК и с которой можно перевести ВСЮ телефонную станцию в так называемый mixed mode, то есть смешанный режим поддержки регистрации оконечных устройств в безопасном и небезопасном режимах. Запускаем клиент, указываем IP адрес телефонной станции, вводим логин/пароль администратора и CTL client устанавливает TCP соединение по порту 2444 со станцией (рис.10). После этого будет предложено всего лишь два действия:

Рис.10 Cisco CTL Client

После создания CTL файла, остается перезагрузить TFTP сервера для того, чтобы они подкачали к себе новый созданный CTL файл, и далее перезагрузить голосовые сервера, чтобы IP телефоны также перезагрузились и загрузили новый CTL файл (32 килобайта). Загруженный CTL файл можно просмотреть из настроек IP телефона (рис.11)

Рис.11 CTL файл на IP телефоне

Аутентификация оконечных устройств

Для обеспечения подключения и регистрации только доверенных оконечных устройств необходимо внедрение аутентификации устройств. На этот случай многие производители используют уже проверенный способ – аутентификация устройств по сертификатам (рис.12). Например, в голосовой архитектуре Cisco это реализовано следующим образом: имеются два вида сертификатов для аутентификации с соответствующими открытыми и закрытыми ключами, которые хранятся на телефоне:
Manufacturer Installed Certificate – (MIC). Сертификат, установленный производителем, содержит 2048 битный ключ, который подписан центром сертификации компании производителя (Cisco). Данный сертификат установлен не на все модели телефонов, и если он установлен, то в наличии другого сертификата (LSC) нет необходимости.
Locally Significant Certificate – (LSC) Локально значащий сертификат, содержит открытый ключ IP телефона, который подписан закрытым ключом локального центра аутентификации, который работает на самой телефонной станции Сertificate Authority Proxy Function (CAPF).
Итак, если у нас есть телефоны с предустановленным MIC сертификатом, то каждый раз, когда телефон будет регистрироваться на станцию, станция будет запрашивать для аутентификации предустановленный производителем сертификат. Однако, в случае компрометации MIC-а для его замены необходимо обращение в центр сертификации производителя, что может потребовать большого количества времени. Дабы не зависеть от времени реакции центра сертификации производителя на перевыпуск скомпрометированного сертификата телефона, предпочтительней использование локального сертификата.

Рис.12 Сертификаты для аутентификации оконечных устройств

По умолчанию на IP телефон не установлен LSC сертификат и его установка возможна, используя MIB сертификат (при его наличии), или через TLS соединение (Transport Layer Security) по разделяемому общему ключу, сгенерированному администратором вручную на станции и введенном на телефоне.
Процесс установки на телефон локально значащего сертификата (LSC), содержащий открытый ключ телефона, подписанного локальным центром сертификации изображен на рисунке 13:

Рис.13 Процесс установки локально значащего сертификата LSC

1. После загрузки IP телефон запрашивает доверенный список сертификатов (CTL-файл) и файл с конфигурацией
2. Станция отправляет запрашиваемые файлы
3. Из полученной конфигурации телефон определяет – нужно ли ему загружать локально значащий сертификат (LSC) со станции
4. Если мы на станции выставили для телефона, чтобы он установил LSC сертификат (см.ниже), который станция будет использовать для аутентификации данного IP телефона, то мы должны позаботиться о том, чтобы на запрос об выдаче LSC сертификата – станция выдала его тому, кому он предназначается. Для этих целей мы можем использовать MIC-сертификат (если он есть), сгенерировать одноразовый пароль на каждый телефон и ввести его на телефоне вручную либо не использовать авторизацию вообще.
На примере продемонстрирован процесс установки LSC с использованием сгенерированно

Код курса БТ19, 2 дня

Статус

Аннотация

Курс посвящен комплексным вопросам анализа защищенности и обеспечения безопасности IP-телефонии (Voice over IP (VoIP) -- системы связи, обеспечивающей передачу речевого сигнала по сети Интернет или по любым другим IP-сетям).Подробно рассматриваются современные подходы к построению инфраструктуры IP-телефонии и ее защита, уязвимости и атаки на ее компоненты. Особое внимание уделяется системам мониторинга и методологии анализа защищенности VoIP-сети.

Более 50% учебного времени уделяется практическим работам по анализу защищенности и настройке компонентов VoIP в соответствии с требованиями безопасности как небольших организаций, так и предприятий с развитой филиальной сетью и территориально распределенными пользователями.

В курсе использованы материалы и рекомендации таких компетентных в области информационной безопасности международных организаций как European Telecommunications Standards Institute (ETSI), International Telecommunication Union (ITU), Voice over IP Security Alliance (VOIPSA) и ряда других.

Применяемая в процессе обучения технология виртуализации серверов и рабочих мест позволяет каждому специалисту индивидуально выполнять практические работы в индивидуальной VoIP-сети. Коллективная работа специалистов осуществляется с применением программных и программно-аппаратных телефонов.

Аудитория:

Системные и сетевые администраторы, ответственные за эксплуатацию VoIP-приложений
Администраторы информационной безопасности
Эксперты и аналитики по вопросам компьютерной безопасности, ответственные за анализ состояния информационной безопасности, определение требований к защищенности сетевых ресурсов и защите от утечки конфиденциальной информации по техническим каналам.

Предварительная подготовка

Базовые знания по IP-сетям, основным протоколам и службам стека TCP/IP
Навыки работы с ОС Windows 2003/2008 и Linux

Вы можете проверить свои знания протоколов стека TCP/IP, запросив в Учебном центре тест для самопроверки.

БТ05 « »
БТ03 « »

По окончанию обучения

Вы приобретете знания:

о современных механизмах и средствах защиты VoIP-сетей
об уязвимостях протоколов и служб VoIP: SIP, H.323, RTP
о применении защищенных протоколов TLS, SRTP

Вы сможете:

применять сетевые анализаторы для мониторинга трафика
проводить анализ защищиты VoIP-сетей
обеспечивать безопасное функционирование IP-телефонии и конференцсвязи

Пакет слушателя

Фирменное учебное пособие
Версии основных рассматриваемых в курсе средств защиты, дополнительная и справочная информация по тематике курса в электронном виде

Дополнительно

После успешной сдачи зачета выпускники получают свидетельства об обучении Учебного центра «Информзащита».

Выпускники Учебного центра могут получать бесплатные консультации специалистов центра в рамках пройденного курса.

Программа курса

Основные понятия и определения VoIP. Терминология. Архитектуры VoIP и их составляющие. Качество передачи речевой информации. Кодеки.
Основные протоколы VoIP . Архитектура. Анализ протоколов VoIP. Сетевой анализатор Wireshark.
Уязвимости и атаки на VoIP. Классификация уязвимостей IP-телефонии.
Инвентаризация VoIP сети. Инвентаризация VoIP приложений. Инвентаризация пользователей.
Перехват VoIP-трафика . Нарушение маршрутизации. Атака «человек посередине».
Манипулирование в системах VoIP. Удаление регистрации абонентов. Несанкционированная регистрация. Перехват регистрации.
Атаки на протокол передачи трафика реального времени RTP (Real-Time Protocol). Микширование речевых сигналов.
Спам в VoIP-сетях. Организация спама при помощи Asterisk.
Механизмы обеспечения безопасности IP-телефонии. Уровни информационной инфраструктуры корпоративной сети. Концепция глубокоэшелонированной защиты. Обзор механизмов и средств защиты сетей.
Планирование защищённой сетевой инфраструктуры IP-телефонии. Выбор местоположения VoIP сервера в сети. Обеспечение сетевой безопасности VoIP сервера. Конфигурирование межсетевого экрана. Использование систем обнаружения атак. Настройка сетевого оборудования.
Анализ защищенности VoIP. Методология. Системы анализа защищённости. Варианты классификации. Архитектура и принципы работы сканеров. Программа SiVuS (SIP Vulnerability Scanner).
Криптографическая защита в VoIP сетях. Криптографические методы защиты информации. Виртуальная частная сеть. Общие принципы построения VPN. Управление ключами. Модель инфраструктуры открытых ключей. Формат сертификатов открытых ключей X.509. Использование TLS (Transport Layer Security), SRTP (Secure Real-time Transport Protocol). Настройка Asterisk.
Аппаратно-программный комплекс шифрования «Континент». Создание VPN на основе АПКШ "Континент". Применение АПКШ «Континент» для защиты VoIP.
Office Communication Server. Архитектура. Варианты использования. Установка и настройка Office Communication Server.

Итоговый зачет

Цель этой статьи обсудить две наиболее распространенных уязвимости, которые присутствуют в текущих реализациях VoIP.

"Наша связь безопаснее обычной телефонной линии"

Технология VoIP прочно вошла в нашу жизнь. Многие действующие операторы связи начали предоставлять услуги VoIP; появились новые провайдеры VoIP. Помимо проблем с качеством предоставляемых услуг, проблема безопасности (как и её отсутствие) недопонимается многими поставщиками услуг VoIP.

Цель этой статьи обсудить две наиболее распространенных уязвимости, которые присутствуют в текущих реализациях VoIP. Первая уязвимость позволяет перехватить пользовательскую подпись (Subscription) и соответствующие соединения. Вторая уязвимость позволяет прослушивать VoIP-соединения. Хотя VoIP реализован с помощью нескольких протоколов, эта статья фокусируется на уязвимостях, связанных с протоколом SIP (Session Initiation Protocol – протокол инициации соединения), являющимся стандартом IETF (RFC 3261). Эти два вида атак (помимо других атак, типа DoS) уже обсуждались в различных исследовательских статьях, но не признавались в качестве реально действующих.

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

Кратко о SIP

Протокол инициации соединений (SIP, IETF RFC 3261) широко используемый стандарт, который используется в VoIP для установления и разрывания телефонных звонков. На Рис. 1 с высокого уровня показаны сообщения SIP во время телефонного разговора. Пояснение следует ниже.

Рис. 1: Установление и разрывание связи.

Шаг 1, устройство пользователя (User Agent в терминологии SIP) регистрируется у регистратора доменов, который отвечает за содержание базы данных со всеми пользователями для соответствующего домена. Регистрация пользователя необходима для связи с удаленной стороной. Когда Bob хочет позвонить Alice, он посылает запрос INVITE прокси-серверу. Прокси-серверы отвечают за маршрутизацию SIP-сообщений и определение местоположения пользователей. Когда прокси получает запрос INVITE, он пытается найти вызываемую сторону и ретранслирует соединение вызывающему, проходя при этом несколько шагов, типа DNS-lookup. Атака на перехват регистрационной подписи происходит как раз на первом шаге.

Перехват регистрации

На Рис. 2 показано типичное регистрационное сообщение и ответ от регистратора, используемый для анонсирования точки связи. Это показывает, что устройство пользователя принимает звонки.

Запрос REGISTER содержит заголовок Contact , указывающий IP-адрес устройства пользователя. Когда прокси получает запрос на входящий звонок (INVITE), он произведет поиск, чтобы узнать, как связаться с соответствующим пользователем. В нашем случае пользователь с телефоном 210-853-010 доступен по адресу 192.168.94.70. Прокси перенаправит запрос INVITE на этот адрес.

На Рис. 3 показан измененный запрос REGISTER, который отправил хакер.

Рис. 3: измененный вариант запроса REGISTER

В этом случае все заголовки и параметры остаются неизменными, кроме заголовка Contact. В этом заголовке был изменен IP-адрес (192.168.1.3), который теперь указывает на устройство хакера. Этот запрос отправляется SIP регистратору по адресу 192.168.1.2. Хакер легко может генерировать подобный запросы, используя программу SiVus, показанную на Рис. 4:

Рис. 4: Подмена регистрации SIP с помощью SiVUS.

Атака перехвата работает следующим образом:

Блокировать регистрацию законного пользователя. Это достигается одним из следующих способов:
- DoS-атака против устройства пользователя
- Дерегистрация пользователя (ещё одна атака, в этой статье не рассматривается)
- Генерация множества запросов REGISTER в более короткий промежуток времени, чтобы вызвать race-condition и отменить регистрацию законного пользователя
Послать запрос REGISTER с IP-адресом хакера.

Рис. 5 показывает подход к осуществлению этой атаки:

Рис. 5: Обзор атаки перехвата регистрации

Сама возможность этой атаки обусловлена следующими причинами:

Сообщения посылаются в открытом виде, что позволяет хакеру перехватывать, модифицировать и отсылать их в своих целях.
Текущая реализация сообщений протокола SIP не позволяет проверять целостность данных, поэтому изменение сообщений никак не обнаруживается.

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

Эта атака может быть предотвращена с помощью SIPS (SIP поверх TLS) и авторизации SIP-запросов и ответов (что может включать проверку целостности). Фактически, использование SIPS и авторизации может предотвратить другие виды атак, включая прослушивание.

Прослушивание

Прослушивание в VoIP немного отличается от прослушивания данных в обычных сетях, но принцип тот же. Прослушивание в VoIP подразумевает перехват служебных сообщений и соответствующих потоков мультимедийных данных. Служебные сообщения используют протоколы и порты, отличные от мультимедийных данных. Мультимедийные потоки обычно передаются по UDP, используя протокол RTP (Real Time Protocol – протокол реального времени).

На Рис. 6 показаны действия, необходимые для прослушивания с помощью Ethereal:

Рис. 6: Перехват мультимедийных данных с помощью Ethereal.

Действия, необходимые для перехвата и декодирования голосовых данных:

Перехват и декодирование RTP-пакетов.
Анализ сессии.
Сохранение данных в виде звукового файла.

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

Можно отбросить этот аргумент, если использовать ARP-спуфинг для осуществления атаки man-in-the-middle. Мы не будем рассматривать ARP-спуфинг в этой статье, на эту тему уже написано много статей. Основная суть в том, что хакер вещает подмененные MAC-адреса, заставляя соответствующие пакеты проходить через свой компьютер. Это позволяет прослушивать данные между двумя пользователями. На Рис. 7 показан пример атаки подмены таблиц ARP:

Рис. 7: Атака ARP-спуфинг.

С помощью подмены ARP-таблиц хакер может перехватывать, анализировать и прослушивать VoIP-соединения.

На Рис. 8 показано использование программы Cain для осуществления атаки man-in-the-middle и перехвата VoIP-трафика.

Рис. 8: Использование Cain для осуществления man-in-the-middle.

Заключение

Ожидается, что описанные выше уязвимости будут использованы в ближайшем будущем в личных и финансовых целях (например, мошенничество).

Инвестиции в производство и исследования, а также широкое распространение услуг VoIP за последние три года показывает, что VoIP прочно вошла в нашу жизнь. В то же время вопросы безопасности становятся более очевидными с ростом количества пользователей. IETF внесло несколько улучшений в стандарты VoIP, которые должны обеспечить защиту VoIP-трафика. Самыми очевидными являются использование TLS поверх SIP для защиты служебных данных и SRTP (Secure Real Time Protocol) для защиты мультимедийных данных. Основная проблема в том, что большинство провайдеров медленно адоптируют эти протоколы и иногда путают безопасность в пакетных сетях с безопасностью телефонных сетей.

Статья написана специально для linkmeup.

=======================

Здравствуйте, коллеги и друзья, я, Семенов Вадим, совместно с командой проекта network-class.net представляем вниманию обзорную статью, которая затрагивает основные тенденции и угрозы в IP телефонии, и самое главное, те инструменты защиты, что на данный момент предлагает производитель в качестве защиты (если выражаться языком специалистов по безопасности, то рассмотрим какие инструменты предлагает производитель для уменьшения уязвимостей, которыми смогут воспользоваться нелегитимные лица). Итак, меньше слов– переходим к делу.
Для многих читающих термин IP телефония уже давно сформировался, а также и то, что данная телефония «лучше», дешевле по сравнению с телефонией общего пользования (ТФОП), богата различными дополнительными функциями и т.д. И это действительно так, однако… отчасти. По мере перехода от аналоговой (цифровой) телефонии со своими абонентскими линиями (от абонентского телефона до станции или станционного выноса) и соединительными линиями (меж станционная линия связи) ни много ни мало были только лишь в зоне доступа и управления провайдера телефонии. Иными словами, обычным обывателям туда доступа не было (ну или практически так, если не учитывать кабельную канализацию). Вспоминается один вопрос на старом добром форуме хакеров «Подскажите, как получить доступ к АТС? – ответ: «Ну как, берешь бульдозер – таранишь стену здания АТС и вуаля». И эта шутка имеет свою долю правды) Однако с переносом телефонии в дешевую IP среду мы получили в довесок и те угрозы, которые несет в себе открытая IP среда. Примером приобретенных угроз может служить следующее:

Сниффинг сигнальных портов с целью совершения платных вызовов за чужой счет
Подслушивание за счет перехвата голосовых IP пакетов
Перехват звонка, представление нелегитимным пользователем как легитимный пользователь, атака «человек по середине»
DDOS атаки на сигнальные сервера станции с целью вывода из строя всей телефонии
Спам-атаки, обрушение большого количества фантомных вызовов на станцию с целью занять все её свободные ресурсы

Аутентификация всех скачиваемых по/с TFTP файлов (конфигурационные файлы, файлы прошивки для телефонов т.д.)
Шифрование конфигурационных файлов
Проверка сертификата с инициализации телефоном HTTPS соединения

Рис.1 Атака «человек посередине»

Рис.3 Подписывание файла конфигурации телефона

Рис.4 Проверка файла конфигурации IP телефоном

Подписанный конфигурационный файл для телефона представлен ниже:

Рис. 5 Подписанный файл IP телефона в Wireshark

Рис.6 Зашифрованный файл IP телефона

Аутентификация телефонной станции

Рис.7 Самоподписанные сертификаты Cisco IP станции

Рис.8 Список доверенных сертификатов

Рис.9 eToken Cisco

Рис.10 Cisco CTL Client

Рис.11 CTL файл на IP телефоне

Аутентификация оконечных устройств

Для обеспечения подключения и регистрации только доверенных оконечных устройств необходимо внедрение аутентификации устройств. На этот случай многие производители используют уже проверенный способ – аутентификация устройств по сертификатам (рис.12). Например, в голосовой архитектуре Cisco это реализовано следующим образом: имеются два вида сертификатов для аутентификации с соответствующими открытыми и закрытыми ключами, которые хранятся на телефоне:
Manufacturer Installed Certificate - (MIC) . Сертификат, установленный производителем, содержит 2048 битный ключ, который подписан центром сертификации компании производителя (Cisco). Данный сертификат установлен не на все модели телефонов, и если он установлен, то в наличии другого сертификата (LSC) нет необходимости.
Locally Significant Certificate – (LSC) Локально значащий сертификат, содержит открытый ключ IP телефона, который подписан закрытым ключом локального центра аутентификации, который работает на самой телефонной станции Сertificate Authority Proxy Function (CAPF).
Итак, если у нас есть телефоны с предустановленным MIC сертификатом, то каждый раз, когда телефон будет регистрироваться на станцию, станция будет запрашивать для аутентификации предустановленный производителем сертификат. Однако, в случае компрометации MIC-а для его замены необходимо обращение в центр сертификации производителя, что может потребовать большого количества времени. Дабы не зависеть от времени реакции центра сертификации производителя на перевыпуск скомпрометированного сертификата телефона, предпочтительней использование локального сертификата.

Рис.12 Сертификаты для аутентификации оконечных устройств

Рис.13 Процесс установки локально значащего сертификата LSC

Рис.14 Режим настроек CAPF на телефоне

Заходим в режим настройки телефона и вводим наш ключ (рис.15):

Рис.15 Аутентификационный ключ для установки LSC

После этого установка LSC сертификата на телефон прошла успешна (рис.16):

Рис.16 Настройки безопасности на IP телефоне

Особенностью же использования LSC сертификата для аутентификации оконечных устройств является то, что при компрометации самого сертификата – он может быть переподписан новым закрытым ключом центром сертификации CAPF телефонной станции.

Итак, на данный момент мы добились безопасности не только скачиваемых файлов, но и аутентификацию сигнальных серверов со стороны оконечных устройств (IP телефонов), а также самих оконечных устройств со стороны станции. Рассмотрим теперь сохранение конфиденциальности разговоров за счет шифрования голосового трафика и скрытия сигнальной информации.

Шифрование разговоров - SRTP

Рассмотрим, что на данный момент предлагает производитель, для выполнения самой востребованной задачи – обеспечения конфиденциальности разговоров.
Стандартно все сигнальные и голосовые сообщения передаются в открытом виде, как на представленном рисунке 17:

Рис.17 Открытое сообщение SIP

Secure Real Time Protocol (SRTP) – это специально разработанный протокол RTP, призванный для передачи голоса и видео, однако дополненный механизмами обеспечения конфиденциальности, целостности передаваемой информации не только через RTP, но и RTCP. Голосовое приложение, поддерживающие SRTP, должно конвертировать RTP пакеты в SRTP перед отправкой их по сети. Обратная операция должна быть продела на приемной стороне. В архитектуре SRTP определены два типа ключей: мастер-ключ и сессионный ключ (для шифрования и аутентификации) (рис. 18). Однако SRTP не регламентирует порядок обмена мастер-ключами, для данных целей необходимо использовать TLS или IPSec. Для обмена ключами стандартизованным решением для SRTP является MIKEY (Multimedia Internet Keying), однако могут быть использованы и такие протоколы как SDES и ZRTP.

Рис.18 Совершение звонка с помощью SRTP

Процесс обмена сообщениями SRTP:

Телефон и сервер обмениваются сертификатами;
Телефон и сервер аутентифицируют друг друга;
Телефон создает TLS ключи для SHA аутентификации и для шифрования AES;
Телефон шифрует ключи с помощью открытого ключа станции и отправляет. Станция расшифровывает с помощью своего закрытого ключа;
Станция обменивается TLS ключами с каждым из телефонов и приступает к безопасному обмену телефонных сигнальных сообщений (телефон вызываемого абонента звонит);
Станция создает сессионные ключи для SRTP SHA аутентификации и SRTP AES шифрованию;
Станция распространяет сессионные ключи обоим телефонам через защищенное сигнальное соединение;
Телефоны приступают обмен голосового трафика через защищенное SRTP соединение (вызываемый поднял трубку).

Включением шифрования и аутентификации на оборудовании Cisco заведуют профайлы безопасности. Выглядит он следующим образом (рис.19):

Рис.19 Профайл безопасности на Cisco CallManager

В нем мы определяем в каком режиме будут регистрироваться и работать оконечные устройства (телефоны). При выборе опции Non Secure – не шифруются ни сигнальные данные, ни голос; Authenticated – шифруются сигнальные сообщения, но не шифруется голос; Encrypted – шифруется и сигнализация и голос. Есть возможность выбора шифрования конфигурационных данных. После создания профайла необходимо его назначить на телефон (рис.20).

Рис.20 Профайл безопасности телефона на Cisco CallManager

На данный момент мы рассмотрели основные моменты в безопасности IP телефонии, позволяющие бороться против основных угроз телефонии, однако это только шапка айсберга всей безопасности голосовой инфраструктуры) Отдельно необходимо рассмотрение физической безопасности инфраструктуры (например здесь: ГОСТ Р ИСО/МЭК 17799-2005 Практические правила управления информационной безопасностью), и отдельную тему можно посвятить сетевой безопасности. Надеюсь, что тот, кто дочитал статью до конца, остался ей доволен и информация была полезной.
На любые вопросы готов ответить по почте: [email protected]
При поддержке проекта network-class.net

Практические аспекты защиты корпоративной сети IP-телефонии

С IP-телефонией, как и любой новой технологией, связано множество различных мифов, слухов и домыслов, мешающих ее повсеместному распространению. Многие из них касаются безопасности IP-телефонии. Апологеты традиционной телефонии утверждают, что коль скоро в технологии VoIP в качестве среды передачи используется протокол IP, то к ней применимы и все сетевые атаки, а следовательно, IP-среда для передачи голосового трафика не подходит. С одной стороны, они правы: атаки действительно возможны. Однако аналогичные атаки (прослушивание, фальсификация абонента и другие) применимы и к традиционной телефонии (см. врезку "Стоимость перехвата информации..."). Более того, в случае с традиционной телефонией реализовать эти атаки гораздо проще, а обнаружить и локализовать - намного сложнее. А по стоимости защиты обычные телефонные переговоры отличаются от более современной IP-телефонии на несколько порядков (в худшую сторону). Но, конечно же, чтобы новая технология позволила обмениваться звонками защищенным образом, ее необх одимо правильно внедрить и настроить.

Стоимость перехвата информации
Купить телефонный жучок, радиозакладку или иное устройство съема информации можно на любом радиорынке и даже в Интернет-магазине: нижняя ценовая планка 10-30 дол. (но без гарантии качества). В детективном агентстве такое устройство предложат в аренду за 20-50 дол. плюс залоговая стоимость жучка (хотя эта деятельность и является незаконной). А заказ "прослушки" профессионалам обойдется всего в 50-100 дол. в час. Еще одно удобство для злоумышленников представляет тот факт, что во многих случаях радиозакладки не требуют дополнительных источников питания и тем более их замены, так как "питаются" от самой телефонной линии. Да и сами телефонные линии представляют потенциальную угрозу, поскольку могут использоваться для прослушивания помещений, через которые проходят, за счет различных электромагнитных наводок и излучений.
Про каждый из стандартов и протоколов IP-телефонии (Н.323, SIP, MGCP, Skinny) можно написать не одну статью, но это не входит в задачи данной публикации. Описание механизмов защиты самих протоколов передачи голоса поверх IP (например, протокол Н.235 или SRTP), представляющих собой неотъемлемую часть голосовой инфраструктуры, также не является целью этого обзора. Если начать говорить об общих принципах работы IP-телефонии, то до темы ее защиты можно никогда не добраться. Таким образом, в данной статье будет описан ряд практических аспектов, связанных с защищенным использованием "последовательницы" традиционной телефонии.

Разделение сети на сегменты
Главное, что необходимо сделать при построении инфраструктуры IP-телефонии, - отделить ее от сегментов, в которых передаются обычные данные (файлы, электронная почта и т.д.). Это можно сделать как с помощью технологии виртуальных локальных сетей (VLAN), так и с помощью межсетевых экранов (МЭ). Первый вариант более эффективен и не требует никаких дополнительных инвестиций, так как механизм VLAN реализован в большинстве коммутаторов. Подобная сегментация позволит создать дополнительный рубеж, предупреждающи й прослушивание переговоров обычными пользователями.
Хорошей практикой является использование отдельного адресного пространства для сегментов IP-телефонии (например, из диапазонов, указанных в RFC 1918). Если сеть, передающая голос поверх протокола IP, имеет достаточно большие масштабы, то в ней не обойтись без динамической адресации по протоколу DHCP. В этом случае необходимо использовать два DHCP-сервера: один для голосовой сети, а второй для сети данных.

Фильтрация и контроль доступа
Голосовые шлюзы (Voice Gateway), подключенные к телефонной сети общего пользования (ТфОП), должны отвергать все протоколы IP-телефонии (Н.323, SIP и другие), приходящие из сегмента данных корпоративной сети. Зачастую поддержка протоколов IP-телефонии реализуется в маршрутизаторах с интеграцией сервисов (Integrated Services Router), что позволяет сэкономить на оборудовании, обеспечивая при этом поддержку самых современных технологий. В этом случае встроенный в маршрутизатор пакетный фильтр с контролем состояни я может отслеживать любые нарушения в голосовом обмене и, например, блокировать пакеты, которые не являются частью процедуры установления вызова. Помимо встроенных в компоненты IP-телефонии механизмов фильтрации и контроля доступа существуют и специальные решения, защищающие элементы голосовой инфраструктуры от возможных несанкционированных воздействий. К таким решениям относятся межсетевые экраны (МЭ), шлюзы прикладного уровня (Application Layer Gateway, ALG) и специализированные пограничные контроллеры (Session Border Controller).

Выбор межсетевого экрана
Для защиты сети IP-телефонии подходит не всякий межсетевой экран - он должен удовлетворять ряду специфичных требований, присущих именно этой технологии передачи голоса. Например, протокол передачи голосовых данных RTP использует динамические UDP-порты, исчисляемые тысячами. Попытка разрешить их все на межсетевом экране приводит к открытию одной большой "дыры" в защите. Следовательно, межсетевой экран должен также динамически определять используемые для связи п орты, открывать их в начале телефонного разговора и закрывать по его окончании.
Вторая особенность заключается в том, что ряд протоколов, например SIP, помещает информацию об используемых параметрах соединения не в заголовок пакета, а в тело данных. Поэтому обычный пакетный фильтр, исследующий только адреса и порты получателя и отправителя, а также тип протокола, в данном случае будет абсолютно бесполезным. Межсетевой экран должен уметь анализировать не только заголовок, но и тело данных пакета, вычленяя из него всю необходимую для организации соединения информацию.

Прикладные шлюзы и пограничные контроллеры
Другая серьезная проблема, решение которой необходимо продумать до приобретения межсетевого экрана, - трансляция сетевых адресов (Network Address Translation, NAT). Коль скоро при установке вызова используются динамические порты, указанные в запросе на установление соединения между абонентами, то технология скрытия топологии сети путем трансляции адресов делает телефонные переговоры нево зможными. Решением проблемы является использование специальных прикладных шлюзов (ALG), выпускаемых в виде выделенных устройств или интегрированных в межсетевые экраны, "понимающие" протоколы с динамическими портами (например, SIP или RTCP). Некоторые производители выпускают только специализированные защитные шлюзы для обработки VoIP-трафика. Но при их выборе следует помнить, что в защите корпоративной сети все равно не обойтись без обычного МЭ, умеющего анализировать не только протоколы Н.323, SIP и MGCP, но и другие распространенные в сетях протоколы: HTTP, FTP, SMTP, SQL*Net и т.д.
Ряд производителей предлагают решение проблемы защиты путем использования специализированных пограничных контроллеров (SBC). По сути, эти устройства во многом аналогичны описанным выше прикладным шлюзам.

Защита от подмены
Динамическая адресация во многих элементах инфраструктуры IP-телефонии дает злоумышленникам большой простор для деятельности: они могут "выдать" свой IP-адрес за IP-телефон, сервер управления звонками и т.д. А значит, перед администратором сети возникает задача аутентификации всех участников телефонных переговоров. Для этого необходимо использовать различные стандартизированные протоколы, включая 802.lx, RADIUS, сертификаты PKI Х.509 и т.д. И, конечно, нельзя сбрасывать со счетов уже упомянутые выше правила контроля доступа на маршрутизаторах и МЭ, усложняющие злоумышленникам задачу подключения к голосовым сегментам.
Указанные методы позволяют эффективно бороться с "левыми" подключениями, в отличие от традиционной телефонии, где эта задача если и решается, то очень дорогостоящими средствами.

Шифрование
Шифрование - наиболее эффективный способ сохранить телефонные переговоры в тайне (см. врезку "Скремблеры и вокодеры..."). Однако такая функциональность влечет за собой ряд сложностей, которые необходимо обязательно учитывать при построении защищенной сети связи.

Скремблеры и вокодеры для защиты традиционной телефонии
Среди средств защиты особняком стоят вокодеры (voice coder) и скремблеры, которые осуществляют шифрование телефонных переговоров. Очевидно, что такие устройства должны быть установлены у всех участников защищенных переговоров. Механизм шифрования встраивается в телефон или поставляется в виде отдельного устройства. В первом случае абонентский терминал становится слишком дорогим (и приходится отказываться от многофункциональных и удобных телефонных аппаратов зарубежного производства), во втором - практически полностью отсутствует возможность масштабирования, и пользование телефоном становится крайне неудобным. Оснастить каждого абонента скремблером или вокодером - задача не из легких. При этом вопрос стоимости также не снимается: цена одного скремблера колеблется от 200 до 500 дол. Если прибавить сюда цену телефонного аппарата и стоимость установки защитных устройств, получатся поистине астрономические цифры. Так что такой способ защиты традиционной телефонии нельзя считать экономичным.
Одна из самых главных проблем - задержка, добавляемая процессом зашифр ования/расшифрования. В случае применения потокового шифрования задержка гораздо ниже, чем при использовании блочных шифров, но полностью от нее избавиться не удастся. Эта проблема решается путем использования более быстрых алгоритмов или включения механизмов QoS в модуль шифрования.
Еще одна трудность - накладные расходы, связанные с увеличением длины передаваемых пакетов. Для протокола IPSec размер добавляемого заголовка составляет около 40 байт, что достаточно много для 50-70-байтовых пакетов IP-телефонии. Впрочем, скорости современных сетей постоянно растут, и с течением времени эта проблема будет снята. А пока оптимальным решением обеих проблем является протокол SecureRTP (SRTP), принятый в качестве стандарта весной 2004г. (RFC 3711).

Защита от нарушения работоспособности
Несмотря на то что различные компоненты IP-телефонии потенциально подвержены атакам "отказ в обслуживании" (о сбоях в традиционной телефонии см. врезку "Перемаршрутизация звонков..."), существует целый ряд защитных мер, предотвращающих как сами DoS-атаки, так и их последствия. Для этого можно использовать встроенные в сетевое оборудование механизмы обеспечения информационной безопасности, а также дополнительные решения:
разделение корпоративной сети на непересекающиеся сегменты передачи голоса и данных, что предотвращает появление в "голосовом" участке распространенных атак, в том числе и DoS;
применение специальных правил контроля доступа на маршрутизаторах и МЭ, защищающих периметр корпоративной сети и отдельные ее сегменты;
использование системы предотвращения атак на сервере управления звонками и ПК с голосовыми приложениями;
установку специализированных систем защиты от DoS- и DDoS-атак;
«применение специальных настроек на сетевом оборудовании, которые предотвращают подмену адреса, часто используемую при DoS-атаках, и ограничивают полосу пропускания, не позволяя вывести из строя атакуемые ресурсы большим потоком бесполезного трафика.

Перемаршрутизация звонков в традиционной телефонии
Еще од на угроза - перемаршрутизация звонков на другие телефонные номера, сброс собеседника с линии или "прорыв" сигнала "занято". Например, в 1989 г. хакерская группа The Legion of Doom получила контроль над телефонной сетью компании BellSouth, включая возможность прослушивания телефонных каналов связи, перемаршрутизацию вызовов, маскировку под технический персонал станции и даже вывод из строя системы экстренной связи 911. Для расследования этого инцидента были приглашены 42 эксперта, а затраты BellSouth на их работу составили 1,5 млн дол. И это не считая потери репутации и других трудно вычисляемых потерь.

Управление
Для удаленного управления использование защищенных протоколов доступа (например, SSH) является обязательным (в данном случае шифрование вносит гораздо меньше задержек, чем при шифровании голосовых данных). Если же доступ к какому-либо компоненту сети IP-телефонии осуществляется по обычному протоколу (например, по HTTP), то непременным условием такого доступа должно быть применение протоко ла IPSec или SSL. В противном случае любой злоумышленник сможет не только перехватывать все данные с незащищенным элементом, но и подменять их.
Если требование криптографии вступает в конфликт с производительностью, то шифрованием на IP-телефонах или голосовых приложениях на ПК можно пренебречь. Если, конечно, к сети не применяются законодательные требования защиты всей конфиденциальной информации (включая и телефонные разговоры). Например, такое требование для всех федеральных структур США прописано в секции 5131 американского закона Information Technology Management Reform Act of 1996.
При отказе от скрытия голосового трафика его необходимо в обязательном порядке отделить от всех остальных типов передаваемых данных с помощью VLAN. При этом передача голоса между офисами должна быть защищена с помощью криптографических преобразований. Для этих целей можно задействовать встроенный в маршрутизаторы механизм IPSec VPN или установить отдельные шифраторы, сертифицированные в ФСБ России.

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

Заключение
В опубликованном годовом отчете IBM "Security Threats and Attack Trends Report" приведен анализ основных угроз года прошедшего и дается прогноз на 2005 г. По мнению экспертов IBM, увеличение числа сетей IP-телефонии приведет к росту угроз для их существования и бесперебойного функционирования. Поэтому обеспокоиться защитой внедряемой или уже внедренной инфраструктуры IP-телефонии необходимо именно сейчас, чтобы позже не "кусать себе локти". И это не так трудно, как кажется на первый взгляд. Существуют технологии, значительно повышающие защищенность VoIP, и они давно известны специалистам по информационной безопасности. Более того, эти технологии зачастую уже внедрены в компоненты, применяемые в построении среды передачи голоса поверх протокола IP. А значит, надо просто воспользоваться ими.

По материалам ИА "Daily Sec".