Обеспечение защиты информации в ip телефонии. Информационная безопасность в IP-сетях телефонии

Цель этой статьи обсудить две наиболее распространенных уязвимости, которые присутствуют в текущих реализациях 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) для защиты мультимедийных данных. Основная проблема в том, что большинство провайдеров медленно адоптируют эти протоколы и иногда путают безопасность в пакетных сетях с безопасностью телефонных сетей.

Несмотря на солидный возраст технологии VoIP и ее широкое распространение в корпоративном и государственном секторе, использование данной технологии вызывает ряд серьезных проблем, связанных с безопасностью: относительно несложно установить прослушивание VoIP-звонков, относительно несложно изменить содержание VoIP-звонков, система VoIP подвержена DoS-атакам.

Существующие решения проблемы

Использование патентованных (закрытых) аудио кодеков

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

Использование VLAN

При построении системы IP-телефонии принято выделять отдельную сеть VLAN, к которой подключаются все IP-телефоны. Данный способ обладает рядом недостатков:

Если злоумышленник получит доступ к VLAN системы IP-телефонии, то ему будет доступны для прослушивания все телефонные переговоры.
Данное решение никак не может обеспечить безопасность системы IP-телефонии, построенной между двумя и более территориально распределенными офисами.

Шифрование и криптографическая аутентификация VoIP

Данный способ обеспечения безопасности на сегодняшний день является наиболее надежным. Защита современных систем IP-телефонии может быть реализована с помощью различных протоколов таких как SRTP, ZRTP и IPSec. Однако, каждый из этих протоколов обладает рядом существенных недостатков:

SRTP, ZRTP используют «слабую» криптографию — ключи шифрования недостаточной длины или некриптостойкие алгоритмы шифрования.
IPSec — требует проведения предварительного обмена ключами, часто блокируется различными интернет-провайдерами, в ряде случаев в силу ограничения технологии не позволяет установить защищенное соединение.
Помимо частных недостатков, все упомянутые способы криптографической защиты IP-телефонии обладают общим недостатком — отсутствие сертификатов ФСБ РФ и ФСТЭК РФ. Из этого следует, что существующие способы защиты IP-телефонии нельзя использовать в государственных учреждениях.

Решение обеспечения безопасности VoIP от ОАО «ИнфоТеКС»

Основой защиты VoIP является VPN-решение ViPNet CUSTOM, которое обладает следующим функционалом:

Шифрование и фильтрация сигнального и голосового трафика всех участников сети IP-телефонии.
Обеспечивает беспрепятственное прохождение VoIP-трафика через устройства NAT.
Поддержка виртуальных адресов, в том числе в протоколах SIP, H.323 и Cisco SCCP (Skinny Client Control Protocol), является решением проблемы пересечения пространства IP-адресов удаленных офисов.

Преимущества

Позволяет организовать защиту гетерогенных систем IP-телефонии.
Позволяет организовать защищенное взаимодействие между двумя и более локальными сетями с пересекающейся IP-адресацией без изменения топологии этих сетей.
Обеспечивает защиту мобильных пользователей IP-телефонии.
Обеспечивает прохождении VPN-трафика в случае использования NAT или противодействия со стороны провайдера.
Наличие сертификатов ФСБ и ФСТЭК.

Спецификацией IETF, где описаны стандартные методы для всех компонентов VPN, является протокол Internet Protocol Security, или IPSec, - иногда его называют туннелирова-нием третьего уровня (Layer-3 Tunneling). IPSec предусматривает стандартные методы идентификации пользователей или компьютеров при инициации туннеля, стандартные способы использования шифрования конечными точками туннеля, а также стандартные методы обмена и управления ключами шифрования между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Идентификацию можно выполнять с помощью спецификации IPSec, причем она является обязательным компонентом протокола IPv6.

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

Некоторые поставщики VPN используют другой подход под названием «посредники каналов» (circuit proxy), или VPN пятого уровня. Этот метод функционирует над транспортным уровнем и ретранслирует трафик из защищенной сети в общедоступную сеть Internet для каждого сокста в отдельности. (Сокет IP идентифицируется комбинацией TCP-соединения и конкретного порта или заданным портом UDP. Протокол IP не имеет пятого - сеансового -уровня, однако ориентированные на сокеты операции часто называют операциями сеансового уровня).

Шифрование информации, передаваемой между инициатором и терминатором туннеля, часто осуществляется с помощью защиты транспортного уровня (Transport Layer Security, TLS), ранее протокола защищенных сокетов (Secure Sockets Layer, SSL). Для стандартизации аутентифицированного прохода через брандмауэры IETF определил протокол под названием SOCKS, и в настоящее время SOCKS 5 применяется для стандартизованной реализации посредников каналов.

В SOCKS 5 клиентский компьютер устанавливает аутентифицированный сокет (или сеанс) с сервером, выполняющим роль посредника (proxy). Этот посредник - единственный способ связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сокета, он может осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий. Для сравнения, виртуальные частные сети уровня 2 и 3 обычно просто открывают или закрывают канал для всего трафика по аутентифицированному туннелю. Это может представлять проблему, если нет гарантии защиты информации на другом конце туннеля.

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

Расположение конечной точки внутри защищаемой брандмауэром зоны обычно означает открытие прохода через брандмауэр (как правило, через конкретный порт TCP). Некоторые компании предпочитают применять реализуемый брандмауэром контроль доступа ко всему трафику, в том числе и к туннелируемому, особенно если другую сторону туннеля представляет пользователь, стратегия защиты которого неизвестна или не внушает доверия. Одно из преимуществ применения тесно интегрированных с брандмауэром продуктов тунне-лирования состоит в том, что можно открывать туннель, применять к нему правила защиты брандмауэра и перенаправлять трафик на конечную точку на конкретном компьютере или в защищаемой брандмауэром подсети.

Как и любая другая вычислительная функция, работа по созданию сетей VPN проводится с помощью программного обеспечения. Между тем программное обеспечение для VPN может выполняться на самых разных аппаратных платформах. Маршрутизаторы или коммутаторы третьего уровня могут поддерживать функции VNP по умолчанию (или в качестве дополнительной возможности, предлагаемой за отдельную плату). Аппаратно и программно реализуемые брандмауэры нередко предусматривают модули VPN со средствами управления трафиком или без них. Некоторые пограничные комбинированные устройства включают в себя маршрутизатор, брандмауэр, средства управления пропускной способностью и функции VPN (а также режим конфигурации). Наконец, ряд чисто программных продуктов выполняется на соответствующих серверах, кэширует страницы Web, реализует функции брандмауэра и VPN.

Механизм VPN немыслим без идентификации. Инфраструктура с открытыми ключами (Public Key Infrastructure, PKI) для электронной идентификации и управления открытыми ключами является в настоящее время основной. Данные PKI целесообразнее всего хранить в глобальном каталоге, обращаться к которому можно по упрощенному протоколу доступа к каталогу (Lightweight Directory Access Protocol, LDAP).

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

Если говорить о недостатках и уязвимостях IP-телефонии, прежде всего следует отметить те же «болезни», какими страдают другие службы, использующие протокол IP. Это подверженность атакам червей и вирусов, DoS-атакам, несанкционированному удаленному доступу и др. Несмотря на то, что при построении инфраструктуры IP-телефонии данную службу обычно отделяют от сегментов сети, в которых «ходят» не голосовые данные, это еще не является гарантией безопасности. Сегодня большое количество компаний интегрируют IP-телефонию с другими приложениями, например с электронной почтой. С одной стороны, таким образом появляются дополнительные удобства, но с другой — и новые уязвимости. Кроме того, для функционирования сети IP-телефонии требуется большое число компонентов, таких, как серверы поддержки, коммутаторы, маршрутизаторы, межсетевые экраны, IP-телефоны и т. д. При этом для поддержки функционирования IP-сети часто используются неспециализированные ОС. К примеру, большинство IP-УАТС построено на базе обычных и хорошо известных операционных систем (Windows или Linux), которые теоретически обладают всеми уязвимостями, характерными для данных систем.

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

Среди основных угроз, которым подвергается IP-телефонная сеть, можно выделить:

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

Это далеко не весь перечень возможных проблем, связанных с использованием IP-телефонии. Альянс по безопасности VoIP (VOIPSA) разработал документ, описывающий широкий спектр угроз IP-телефонии, который помимо технических угроз включает вымогательство через IP-телефонию, спам и т. д.

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

Что же строить?

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

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

возможность создания виртуальных локальных сетей (VLAN) с использованием встроенных возможностей коммутаторов;
применение встроенных механизмов фильтрации и контроля доступа;
ограничение и представление гарантируемой полосы пропускания, что позволяет эффективно подавлять DoS-атаки;
ограничение числа устройств с различными MAC-адресами, подключенными к одному порту;
предотвращение атак на расходование пула адресов DHCP-сервиса;
предотвращение засорения таблиц ARP и «воровство» адресов;
предотвращение атак с анонимных адресов;
применение списков контроля доступа, ограничивающих адреса узлов, которые могут передавать данные IP-телефонам.

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

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

Применение специализированных межсетевых экранов значительно повышает безопасность IP-телефонной сети, например, при помощи фильтрации трафика с учетом состояния соединения (stateful inspection ), что позволяет пропускать только необходимый трафик и соединения, установленные в определенном направлении (от сервера к клиенту или наоборот). Кроме того, межсетевой экран предоставляет возможности по:

фильтрации трафика управления установкой IP-телефонных соединений;
передаче трафика управления через NAT и сетевые туннели;
TCP-перехвату, который обеспечивает проверку закрытия TCP-сессий, что позволяет защищаться от ряда атак типа отказа в обслуживании (DoS).

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

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

Защита от прослушивания

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

Наиболее совершенный способ противодействия подобным манипуляциям — использование IP-телефонов со встроенными средствами шифрования. Кроме того, дополнительную защиту обеспечивает шифрование трафика между телефонами и шлюзами. На сегодняшний день практически все производители, такие как Avaya, Nortel и Cisco, предлагают встроенные средства шифрования для информационных потоков и сигнализации. Шифрование трафика является наиболее логичным решением для защиты от прослушивания разговоров, но такая функциональность несет и ряд трудностей, которые необходимо учитывать при построении защищенной связи. Основной проблемой может быть задержка, добавляемая процессом зашифровывания и расшифровывания трафика. При работе в локальной сети подобная проблема, как правило, не дает о себе знать, но при связи через территориально-распределенную сеть способна доставлять неудобства. К тому же шифрование сигнализации, происходящее на прикладном уровне, может затруднить работу межсетевых экранов. В случае применения потокового шифрования задержки гораздо ниже, чем при использовании блочных шифров, хотя полностью от них избавиться не удастся. Вариантом решения проблемы могут служить более быстрые алгоритмы или включение механизмов QoS в модуль шифрования.

QoS

Принято считать, что основное назначение механизмов QoS (Quality of Service ) — обеспечение должного качества связи. Но не стоит забывать, что они играют важнейшую роль и при решении задач безопасности. Для передачи речи и данных из логически отдельных виртуальных ЛВС используется общая физическая полоса пропускания. При заражении узла вирусом или червем может произойти переполнение сети трафиком. Однако если прибегнуть к механизмам QoS, настроенным соответствующим образом, трафик IP-телефонии будет попрежнему иметь приоритет при прохождении через общие физические каналы, и DoS-атака окажется безуспешной.

Защита от подмены телефонов и серверов управления

Многие элементы IP-телефонии имеют динамическую адресацию, что позволяет злоумышленникам использовать это в своих целях. Они могут «выдать себя» за IP-телефон, сервер управления звонками и т. д. Для защиты от устройств, пытающихся замаскироваться под авторизованные IP-телефоны или несанкционированно подключенных к сетевой инфраструктуре, можно воспользоваться правилами контроля доступа на маршрутизаторах и межсетевых экранах. Кроме того, могут пригодиться средства строгой аутентификации всех абонентов инфраструктуры IP-телефонии. Для подтверждения подлинности абонентов могут применяться различные стандартизированные протоколы, включая RADIUS, сертификаты PKI x.509 и т. д.

Защита от DoS-атак

Атаки типа «отказ в обслуживании» на приложения IP-телефонии (например, на серверы обработки звонков) и среду передачи данных представляют собой довольно серьезную проблему. Если говорить об атаках на среду передачи данных, отметим, что за передачу данных в IP-телефонии, как правило, отвечает протокол RTP (Real-Time Protocol ). Он уязвим для любой атаки, которая перегружает сеть пакетами или приводит к замедлению процесса их обработки конечным устройством (телефоном или шлюзом). Следовательно, злоумышленнику достаточно «забить» сеть большим количеством RTP-пакетов либо пакетов с высоким приоритетом обслуживания, которые будут конкурировать с легитимными RTP-пакетами. В таком случае для защиты можно использовать как встроенные в сетевое оборудование механизмы обеспечения информационной безопасности, так и дополнительные решения:

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

Защита IP-телефонов

IP-телефоны содержат целый ряд специальных настроек, препятствующих несанкционированному доступу к ним. К таким настройкам относятся, например, доступ к функциям телефона только после предъявления идентификатора и пароля или запрет локального изменения настроек и т. д. С целью предотвращения загрузки на IP-телефон несанкционированно модифицированного программного обеспечения и конфигурационных файлов, их целостность может контролироваться цифровой подписью и сертификатами X.509.

Защита от мошенничества в IP-телефонной сети

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

Стандарты в IP-телефонии

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

Заключение

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

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

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

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

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

Здравствуйте, коллеги и друзья, я, Семенов Вадим, совместно с командой проекта 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 с использованием сгенерированного ключа.
На станции в режиме настроек IP телефона указываем, что мы хотим установить LSC сертификат на телефон и при этом установка будет произведена успешна, если на телефоне ввести аутентификационный ключ, который мы определили как 12345 (рис.14).

Рис.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