Обзор подготовлен При поддержке
CNewsAnalytics Компания ТрансТелеКом

«Нетрадиционная» защита IP-телефонии

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

Традиционные средства пасуют

Традиционный межсетевой экран (МСЭ) обычно «открывает» доступ всего нескольким сетевым протоколам — HTTP, SMTP, HTTPS, FTP и т.п., которые используют всего один (очень редко два) порта. Делается это, как правило, заранее — еще при установке. В IP-телефонии же необходимо динамически открывать до 6 портов на каждый (!) звонок — 2 порта для сигнального трафика в оба конца, 2 порта для голосового трафика и, опционально, 2 порта для контроля производительности (с помощью протокола RTCP). Если производитель свой продукт называет межсетевым экраном (firewall), но при этом строит его на базе обычного пакетного фильтра, входящего в состав операционной системы Linux или FreeBSD, то у такого защитного решения будут большие сложности с поддержкой IP-телефонии. Но на этом проблемы не ограничиваются — мало уметь динамически открывать порты.

Чтобы сделать звонок при помощи IP-телефона, первым делом посылается соответствующее сигнальное сообщение. Оно без особых проблем проходит через межсетевой экран и доходит до вызываемого абонента. Тот в свою очередь отправляет подтверждение, которое также проходит через МСЭ, «ожидающий» ответ. Но когда в дело вступает обмен голосовыми данными, ситуация коренным образом меняется. Исходящий «голос», вероятно, будет пропущен МСЭ, а вот входящий будет им отброшен, так как МСЭ ничего не знает об этом соединении и не «ждет» его. Ведь он не способен «посмотреть» выше транспортного уровня и «заглянуть» вглубь сигнальных пакетов, передаваемых на сеансовом уровне и хранящих сведения об используемых параметрах соединения (в том числе и портах). В результате соединение установлено, а слышать друг друга абоненты не могут — межсетевой экран блокирует голосовой трафик.

Другая проблема связана с сетевой трансляцией адресов (Network Address Translation, NAT), которая обычно встроена в МСЭ и позволяет организовать соединение сети с большим диапазоном внутренних и зачастую немаршрутизируемых адресов с внешней сетью. Обычно NAT просматривает сетевой трафик на 3-м сетевом уровне и заменяет указанные адреса источников на внешне доступный адрес (например, адрес МСЭ). При этом также выделяются порты, через которые и осуществляется взаимодействие с внешним миром. Для IP-телефонии в этом случае начинаются серьезные проблемы, так как информация о параметрах соединения скрывается на 2 уровня выше — на сеансовом уровне. Это значит, что NAT «не сработает», и внешний абонент не сможет дозвониться до внутреннего пользователя — он его просто «не увидит».

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

Использование VPN для обеспечения конфиденциальности голосового трафика — правильное решение, но нельзя забывать про вносимые задержки и приоритезацию трафика. Если трафик зашифрован, то проходные сетевые устройства не будут знать, что они обрабатывают трафик, критичный к задержкам. А значит, такой трафик «пойдет в порядке общей очереди».

И уж тем более традиционные средств защиты не способны защитить от атак на инфраструктуру VoIP. Даже несмотря на наличие в рекламных материалах фраз «контроль на уровне приложений», многие производители скромно умалчивают о том, что IP-телефония в список таких приложений не входит. А это значит, что VoIP-пакеты могут быть очень большого размера, нестандартного формата, использовать неразрешенные команды в сигнальном трафике или приводить к отказу в обслуживании. И все это остается за пределами внимания традиционных межсетевых экранов и систем предотвращения атак.

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

Интегрированная или собственная защита?

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

Но здесь надо помнить рассуждения, приведенные для традиционных средств защиты. Если сетевая инфраструктура «не понимает» протоколов IP-телефонии, то никакие встроенные механизмы защиты сети не помогут, и придется дополнительно расходовать финансовые средства на навесные системы защиты VoIP. Если же сеть построена с учетом современных технологий (не только VoIP, но и видеотелефония, видеоконференцсвязь и т.д.), то эффективность защиты (технологическая и финансовая) будет гораздо выше. Наверное поэтому главными серьезными игроками на рынке IP-телефонии с самыми радужными перспективами являются производители, которые наряду с VoIP-инфраструктурой выпускают средства защиты и сетевое оборудование. В этом случае достигается идеальная совместимость всех решений, а в итоге выигрывает потребитель.

Стандартизация механизмов безопасности IP

Большинство VoIP-решений использует семейство протоколов H.323, которое, однако, постепенно сменяется более прогрессивным протоколом SIP. Но многие разработчики SIP-устройств в первую очередь фокусируются на увеличении числа функций и совместимости, а не на безопасности. В отличие от стандарта H.323, в рамках которого разработана спецификация H.235, описывающая различные механизмы безопасности, протокол SIP практически лишен каких бы то ни было серьезных защитных функций, что вызывает сомнения в безоблачности нашего VoIP-будущего, которое многие эксперты связывают именно с протоколом SIP.

Усилия же различных разработчиков и экспертов в области безопасности разрозненны и не увязаны в единую стратегию. Так, например, в США целых два министерства независимо друг от друга разработали рекомендации по защите инфраструктуры пакетной передачи голоса. Это министерство торговли — Security Considerations for Voice Over IP Systems. Recommendations of the National Institute of Standards and Technology. Special Publication 800-58. January 2005 и министерство обороны — Voice Over Internet Protocol (VoIP). Security Technical Implementation Guide. Defense Information Systems Agency. Field Security Operations. January 2004.

Некоторые надежды возлагаются на сформированный в июле 2005 года альянс по безопасности VoIP (http://www.voipsa.org), целью которого является проведение исследований, повышение осведомленности, обучение и разработка бесплатных методик и инструментов для тестирования в области защищенности IP-телефонии. Но пока единственным результатом работы данного альянса явилось создание таксономии атак и уязвимых мест IP-телефонии.

С другой стороны, незачем ждать выработки стандартов — уже сейчас есть все, чтобы сделать внедряемую или уже внедренную инфраструктуру VoIP защищенной. Достаточно вспомнить разработанную в ITU и стандартизованную в ISO модель FCAPS (Fault, Configuration, Accounting, Performance, Security). Несмотря на то, что данная модель разрабатывалась для других целей, она является идеальным инструментом для оценки инфраструктуры IP-телефонии с точки зрения управления и безопасности.

Модель FCAPS

Управление сбоями

Управление конфигурацией

Управление использованием сервисов

Управление производительностью

Управление безопасностью

Мониторинг, сбор и анализ сигналов тревоги

Инвентаризация

Генерация отчетов и отслеживание использования сервисов

Сбор данных

Контроль доступа

Обнаружение проблем

Резервирование и восстановление

Биллинг

Генерация отчетов

Регистрация попыток доступа

Устранение или коррекция проблем

Обновление конфигурации

 

Анализ данных

Контроль действий пользователей

Тестирование

Управление базой данных

 

 

 

Восстановление после сбоев

 

 

 

 

Можно заметить, что, несмотря на наличие отдельной категории «безопасность», ее очень сложно выделить в отдельное направление — она тесно переплетается с остальными функциональными категориями. Например, сбор сигналов тревоги об инцидентах — это первая категория модели. Инвентаризация средств защиты и контроль их конфигурации — это вторая категория. Защита от DoS-атак — это четвертая категория и т.д. Следование этой модели позволит сделать инфраструктуру VoIP не только хорошо защищенной, но и хорошо управляемой, что и является залогом ее успешного использования.

Вопрос времени

Вопросы безопасности новых информационных технологий (а к ним относится и IP-телефония) сейчас находятся в центре внимания многих. Никто не хочет, внедряя у себя новомодное решение, помогающее бизнесу, привносить в компанию и новые угрозы. Сейчас информационная безопасность ставится во главу угла при выборе новых ИТ-систем. Этой теме посвящаются и различные публикации.

Несмотря на слухи, циркулирующие в среде ИТ-специалистов насчет низкой защищенности IP-телефонии, на самом деле эта технология гораздо более защищена, чем ее традиционная «сестра». При том, что стоимость этой защиты существенно ниже, а управление гораздо удобнее и эффективнее, чем в ранее привычной телефонии. Поэтому переход к IP-телефонии, предоставляющей гораздо более привлекательные для бизнеса услуги и функции — это всего лишь вопрос времени. И первый, кто поймет и осуществит это — станет лидером в своем сегменте рынка.

Алексей Лукацкий / CNews Analytics


Вернуться на главную страницу обзора

Версия для печати

Опубликовано в 2005 г.

Техноблог | Форумы | ТВ | Архив
Toolbar | КПК-версия | Подписка на новости  | RSS