|
|
Обзор подготовлен |
При поддержке |
|
|
«Нетрадиционная» защита 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
|
|