CC BY
50
Gubskaya Oksana Alexandrovna, teacher, oksanochka23932393@mail.ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S. M. Budyonny,
Zaikin Nikolay Nikolaevich, teacher, zaykin53@mail. ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny,
Svidlo Alexander Vladimirovich Oksana Alexandrovna, teacher, svid-lo_av@yandex. ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S. M. Budyonny,
Fatyanova Elena Valentinovna, teacher, fatlen 7 7@,mail. ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyon-ny
УДК 623. 61
ПРОБЛЕМЫ ЗАЩИТЫ РЕЧЕВЫХ СЕРВИСОВ В МУЛЬТИСЕРВИСНОЙ СЕТИ СПЕЦИАЛЬНОГО НАЗНАЧЕНИЯ
Д.И. Елисеев, Е.А. Савельев, Д. А. Иванов, Н.Б. Ачкасов
В статье рассмотрены методы воздействия на технологию VoIP сервисов, в частности передачи речи в открытом сегменте IP-телефонии, анализ которых показал, что защита IP-телефонии должна строиться на всех уровнях эталонной модели, начиная с прикладного, особое внимание уделяется транспортному уровню, сетевому, и заканчивая правильным конфигурированием плана нумерации. Кроме этого, поддержание версии программного обеспечения и операционной системы IP АТС, IP-шлюзов и программных коммутаторов в актуальном состоянии, обновление прошивок и настройка безопасности оконечного оборудования.
Ключевые слова: защита, мультисервисные сети, IP-телефоны, вредоносное воздействие, эталонная модель.
Технология VoIP стала обыденной для большинства пользователей сети связи специального назначения. IP-телефония является частным случаем более широкого понятия VoIP (Voice over IP - речь по протоколу межсетевого взаимодействия) для обеспечения двухстороннего общения. Технология VoIP в общем случае обеспечивает множество вариантов передачи голоса через IP, в том числе не имеющих никакого отношения к телефонии и вообще к общению людей. Например, технология VoIP применяется для трансляции звука и видео в системах видеотрансляции, видеонаблюдения, в охранных системах, системах оповещения, в ходе вебинаров, при просмотре фильмов в режиме онлайн. Услуга передачи речи в сети связи специального назначения все большей степени обеспечивается средствами и протоколами ведомственной мульти-сервисной сети передачи данных [1].
Для услуг IP-телефонии на сети связи специального назначения МО РФ используется протокол сигнализации SIP 2.0 (Session Initiation Protocol - протокол инициирования сеанса), базовые принципы которого изложены в документе RFC 3261. Он характеризируется относительно простой реализацией, гибкостью и расширяемостью, в отличие от устаревшего предшественника H.323, который на рассматриваемой сети для целей телефонии вообще не применялся. Изначально в протоколе SIP было определено
290
шесть сообщений-запросов (или так называемых методов), что было вполне достаточно для инициирования и поддержания сеанса мультимедиа. В процессе совершенствования число запросов выросло до 14, однако надо признать, что далеко не все из возможных используются в реальных приложениях на сети связи МО РФ.
Голос (возможно также совместно с видео) в сетях с коммутацией пакетов передается, как правило, посредством протоколов RTP/RTCP (Real-time Transport Protocol - транспортный протокол реального времени и Real-Time Transport Control Protocol -протокол управления транспортировкой в реальном времени), описанных в документе RFC 3550 [2]. RTP используется для транспортирования посредством IP-пакетов голосовой и вообще любой медиаинформации, критичной к времени передачи, а RTCP обеспечивает передачу управляющей информации и контроль качества RTP-потока.
При вызове от абонента А к абоненту Б на сети IP в процессе сеанса связи сначала происходит последовательный обмен сигнальными сообщениями между сетевыми элементами начиная от оконечных IP устройств: IP-телефон (программный Soft-Phone), далее между транзитными и оконечными IP АТС, IP-шлюзами и программными коммутаторами по протоколу SIP, который функционирует совместно с протоколом SDP (Session Description Protocol). SDP - протокол описания сессии, базовые понятия которого описывает RFC 3264, сетевой протокол прикладного уровня, предназначенный для согласования параметров сессии, таких как кодеков речи и видео, длительности сеанса связи и других параметров, в том числе параметров шифрования меди-контента (рис. 1). После согласования необходимых параметров и ответа вызываемого абонента на вызов в работу включается протоколы RTP/RTCP [3], которые обеспечивает непосредственно транспортировку полезной информации, закодированной речевыми или видеокодеками. Типовой сценарий вызова от сервера к абоненту представлен на рис. 2.
Л Message Body_
Л Session Description Protocol
Session Description Protocol Version (v): 9 is Owner/Creator, Session Id (o): - 3793375779 3793379779 IN IP4 192.168.100.7 Session Name (s): pimedia Bandwidth Information (b): AS:84 > Time Description, active time it}: 0 О Session Attribute (a): X-nat:9
Media Description, naine and address (m): audio 4092 RTP/SAVP 8 IS 161
Connection Information (c): IN IP4 192.168.190.7
Bandwidth Information (b): TIAS:64009
Media Attribute (a): rtcp:4903 IN IP4 192.168.100.7
Media Attribute (a): sendrecv
Media Attribute (a): rtpmap:8 PCMA/8990
Media Attribute (a): rtpmap:18 G729/8009
Media Attribute (a): rtpmap:191 telephone-event/3000
Media Attribute (a): fmtp:191 0-16
Media Attribute (a): ssrc: 1036537412 cname: 396406550693329a
Media Attribute (a): crypto:! AES_CH_12S_HMAC_SHA1_80 inline :pSd0RHTnVD+NHg/nZ8L/YxoZ2DpAzpi09ZGEvuN2 ' Media Attribute (a): crypto:2 AES_CM_128_HMAC_SHA1_32 inline :irPzZgdOUOzxmdmepb6QXpfEd/ûgSt790vVcbIZl Media Attribute Fieldname: crypto tag 2
Crypto suite: AESCM128 HMACSHA132 Key parameters [Generated Call-ID: 50d7dEJ822ced4eb8ac47f5d21a27b2221
Рис. 1. Фрагмент сообщения SDP
192.168.100.111 Сервер
50Ы 5050 50Ы ЖО НВЗ 1QIÎ6 10236 50Ы 5060
Клиент 192.168.100.6
:iv.-:~E sep ::7::а t°°phc-r---v°rt'
::о~гу'г =
ISC' R'rz'n
200 ::k SDP u ^рЬ-г^.^гГ
fi CK
47104 47104 47104 47104 47104 7076 7076 47104 47104
Рис. 2. Сценарий обмена сообщениями при установлении сессии по протоколу SIP
291
В силу доступности арендованных каналов между узлами связи актуальность приобретает защищенность VoIP сервисов, в частности IP-телефонии. Если для закрытого сегмента сети передачи данных проблема защиты решается комплексно, то безопасности передачи речи в открытом сегменте сети МО РФ стоит уделять дополнительное внимание. Особенно актуально проблема защиты стоит при общении абонентов между различными военными городками, объединенными одной АТС, через арендованную линию провайдера. Протоколы VoIP-услуг в открытом сегменте сети специального назначения наряду с «классическими» опасностями подвержены также и специфическим. Защита IP-телефонии должна строиться на всех уровнях эталонной модели, начиная с прикладного, особое внимание в последние годы уделяется транспортному уровню, сетевому, и заканчивая правильным конфигурированием плана нумерации.
В случае проникновения в открытый сегмент для злоумышленника самый простой способ вредоносного воздействия - организовать DDos-атаку, при этом можно даже не посылать множество SIP-запросов на программный коммутатор. Можно «вмешаться» и подслушать разговор, можно дестабилизировать услугу отправляя пустые RTP-пакеты, на обработку которых шлюз или программный коммутатор будет затрачивать ресурсы, что приведет к задержкам, и разговор станет вести практически невозможно (атака Call tampering) [4].
Атака на VoIP-сервисы корпоративной сети во всем мире является одним из самых удобных способов монетизации. Так, найдя уязвимость, злоумышленник может совершать звонки на номера платных услуг или «перепродавать линию» для междугородных/международных звонков. В последние годы подобные уязвимости приходилось неоднократно закрывать специалистам по безопасности весьма крупных компаний, например Cisco, Microsoft, Digium - подразделению Sangoma Technologies (в частности разработчикам Skype и Asterisk), и таких примеров не мало. Еще одна специфическая проблема - голосовой фишинг и спит (SPIT - spam over Internet telephony или VAM -voice/VoIP spam). В первом случае абонент вместо того, чтобы работать, слушает рекламу или «холодный» звонок, во втором - принимает моментально «сорвавшийся» вызов, стимулируя соблазн перезвонить, или получает прямое предложение перезвонить на «сервисный» номер для уточнения некоторых вопросов. В итоге министерство платит за звонок по увеличенному тарифу, а абонент раскрывает свои персональные данные. Спит и фишинг еще не стали массовым явлением, но уже отмечаются на сетях мобильной связи, и объемы атак увеличиваются. При этом не рассматриваются вопросы борьбы с использованием VoIP как метода телефонного терроризма [5].
Еще один возможный способ атаки - подбор пары логин/пароль, а также перехват мультимедиа данных.
Попытки подбора паролей к SIP-аккаунтам в публичных сетях не редкость, готовые инструменты находятся в свободном доступе в Интернет. Это обуславливает выполнение жестких требований использовать только устойчивые ко взлому логины и пароли. Имя пользователя не должно быть простым, и тем более не должно совпадать с абонентским номером и паролем авторизации.
В открытом сегменте передачи данных для VoIP рекомендуется выделять отдельные подсети (физические или VLAN), что позволит изолировать голосовой трафик от трафика компьютерной сети и к тому же обеспечить QoS для VoIP. При этом не следует считать эту меру панацеей, так как сниферы-анализаторы трафика без труда обнаружат и захватят трафик VoIP в VLAN. Пример перехвата трафика представлен на рис. 3 - 4. В перехваченном трафике можно отфильтровать все сообщения для каждой сессии, как показано на рис. 2.
Традиционные межсетевые экраны, к сожалению, не могут в полной мере противостоять атакам, поскольку они работают на транспортном уровне и не производят анализ пакетов вышележащих уровней. Обычно в корпоративных сетях для защиты применяются специализированные решения класса NGFW (Next-Generation Firewall).
Примерами являются Certes Networks, SonicWall, Point, свободно распространяемые IPS Snort/Suricata. Однако на сети специального назначения такие продукты применены быть не могут [6].
No. Time Source Destination ProtocoE Length Info
55 16 92483- 192 168 100 7 192 168 100 111 NBNS 94 Name query NBSTAT *<00>O0><00><00X00><J—=
56 16 92488- 192 168 100 111 192 168 100 7 ICMP 122 Destination unreachable (Port unreachabj^H
57 16. 99892... 192. 168 100 .5 192. 168. .100. .255 ШР 307 54915 > 54915 len-263
58 17. 00201.. 192, 168 100 ш. 192. 168 100 .253 и@Р 307 54915 ^ 54915 Len=263
Él 17 00977... ш 1БЙ 10® щ 192.168. .100. .1.11 :ini> 62 5061 -> 5060 Loni2
69 17. 65569... 168 100 .8 да. 168. .100.111 5IP/SDP 829 Status : 250 Ok
61 17. 65617- 192. 168 100 .111 да. 168. 100 .6 sir 478 Request: ACK sip :61011$192.168.100.6:471
62 17. 65717.. 192. 168 100 .111 192. 168. 100 .7 SIP/SOP 975 Status: 200 OK j
Г. S 1 ! 69981- Î92. 168 Ï00 .7 № 168. Мб .111 RTCP 104 Receiver Report Source description
Ш 17. 69983- ÎS2. Ш 100 да. 168. 100 .111 RTCP 104 Receiver Report Source description
65 17. 69983... 192. 168 10® .7 192. 168. 100 .111 SIP 401 Request: ACK sip : S1011jil92.168.100. Ill: 5
66 17. 70383... 192. 168 100 .7 192. 168. 100 .111 NBNS 94 Name query NRSTAT
67 17 70386- 192 168 100 111 192 168 100 7 ICMP 122 Destination unreachable (Part unreachabl^B
68 17.70458.. 192. 168. 100. .7 192. 168. .100. .111 SIP/SOP 1007 Request: IHVITE sip:61011^192.168.100.11
69:17. .70483... 192. 168. .100, .111 да. .168. .100. .7 613 Status: 100 Wying |
70 17. . 70497.. 192. 168. 100. .111 192. .168. 100 .7 SIP/SHP 928 status : 200 OK j
Рис. 3. Главное окно программы Wireshark при перехвате трафика
Wireshark ■ Звонки VoIP ■ 61011_61012.pcapng
Время Старта Время Останова Исходный Спикер Из В Протокол Длительность
15.539138 20.354138 192168.1007 ■61012" о:61012@192.163100.111> «¡р:61011Ш92 168.100.111 > SP 00:00:04
15.659311 20350653 192.168.100.111 ■61012" ' р:61012@192.168.lOCLllls <&ip:61[)ll!S|192.168.10tt.fe47104;lran&port=ijdp> SP 00:00:D4
Рис. 4. Окно программы Wireshark для анализа сессии IP-телефонии
Простыми и эффективными мерами являются в первую очередь традиционные мероприятия по борьбе с DoS - регулировка трафика на маршрутизаторе, использование пограничных контроллеров сессий (SBC, session border controllers), правильная настройка программных коммутаторов. Так, контроллеры SBC, являясь единой точкой входа трафика, производят анализ пакетов в реальном времени, и способны обнаруживать и предотвращать DDoS-атаки, распространение спама и вирусные атаки. Дополнительно к этому некоторые реализации SBC позволяют шифровать трафик, обеспечивают защиту его от перехвата в публичных сетях. Однако SBC используются в основном провайдеры услуг, но не на сети связи специального назначения, где применение таких устройств избыточно.
Чтобы реализовать атаку MITM («человек посередине» - Man in the middle) достаточно перехватить сеанс регистрации SIP. Обычно протокол SIP использует транспортный протокол UDP по порту 5060, что упрощает атаку. Злоумышленник может инициировать регистрацию на сервере, отправляя ложные сведения о клиенте в сообщении SIP REGISTER, и зарегистрируется от имени легитимного пользователя. В последующем сеансе он пропускает через себя весь трафик. Дальнейшая обработка также не вызывает проблем - анализатор трафика на основе свободного программного обеспечения умеет извлекать аудио, сохранять и прослушивать информацию (рис. 5).
ia,5 19 19,5
Рис. 5. Окно программы Wireshark для прослушивания речевого трафика
293
Говоря в общем защита от атаки «человек посередине» для VoIP достаточно хорошо проработана. Это проверка МАС-адреса на межсетевом экране, использование протокола контроля доступа и аутентификации IEEE 802.1x, использование протоколов RADIUS, наконец шифрование потока.
В корпоративных сетях для обеспечения безопасности IP-телефонии в основном применяют два различных подхода: формирование защищенного канала между узлами сети (как правило VPN-туннель, от английского virtual private network, виртуальная частная сеть) и использование протоколов обеспечения безопасности непосредственно для IP-телефонии. Первый способ широко распространен при построении виртуальных корпоративных сетей, однако на сети специального назначение применение такого способа в силу целого ряда причин крайне ограничено.
Шифрование, наряду с эффективными методами аутентификации и грамотным формированием паролей, позволяет защитить услугу от подбора пароля, и самое важное - от прослушивания речевой информации ограниченного пользования при общении абонентов на сети открытой дальней телефонной связи.
Протоколы обеспечения безопасности IP-телефонии можно условно разделить на три группы:
протоколы защиты сигнального трафика SIP (SIPS - Secured SIP),
протоколы защиты медиатрафика (SRTP - Secure RTP),
протоколы генерации/распределения ключей для протоколов защиты медиатрафика (MIKEY, SDES, ZRTP, DTLS).
В настоящее время для программного шифрования речи и сигнальных сообщений на корпоративных сетях можно использовать протоколы: SIP/TCP/SRTP, SIP/TLS/SSL совместно с SRTP (Secure Real Time Protocol) или ZRTP (Z and Real-time Transport Protocol, акроним от названия протокола и имени создателя Phil Zimmermann SRTP).
SIP совместно с использованием транспортного протокола TCP и SRTP пожалуй самый простой способ защиты, который позволяет практически скрыть содержимое разговора, но не сигнальный трафик и заголовки RTP (рис. 6).
Рис. 6. Сценарий обмена сообщениями при установлении сессии
по протоколу 8ТР/8КТР
Протоколы защиты сигнализации предназначены для защиты информации об IP-адресах и телефонных номерах вызывающего и вызываемого абонентов, а также о поддерживаемых кодеках. Для этого используется протокол Secured SIP (SSIP, или связка SIP/TLS - transport layer security, обновленная версия SSL. Протокол защиты транспортного уровня, описан RFC 6176), появился в качестве замены обозначения SSL (Secure Sockets Layer) после того, как де-факто стал Интернет-стандартом. Замена вызвана юридическими аспектами, так как протокол SSL изначально принадлежал компании Netscape. И сейчас зачастую аббревиатуры SSL и TLS продолжают использовать в
качестве синонимов, но каноническим именем является TLS, а протоколы семейства SSL окончательно устарели и не должны использоваться. Ключевым отличием TLS от SSL является поддержка целого ряда расширений, позволяющих реализовать современные методы защиты информации.
TLS работает аналогично защищенному HTTPS. HTTPS стремительно вытесняет незащищённую версию (HTTP): доля зашифрованного веб-трафика растёт, скорее всего, в скором будущем весь веб-трафик в Интернете будет зашифрован. В новой версии HTTP/2 защита информации средствами TLS должна использоваться по умолчанию. Благодаря этому TLS - один из самых изученных и исследованных протоколов современного Интернета.
Всего существует четыре версии TLS, все они описаны в RFC: TLS 1.0, TLS 1.1, TLS 1.2 и вышедшая в 2018 году версия TLS 1.3. TLS 1.0 во многом повторяет устаревший SSLv3. TLS 1.1 и 1.2 достаточно близки к 1.0, но в версии 1.2 используется другая основа псевдослучайной функции и введена поддержка шифров в режиме аутентифицированного шифрования.
TLS 1.3 весьма и весьма существенно отличается от всех предыдущих версий TLS. Радикально изменена логика установления соединения, а сам протокол стал архитектурно строже, из спецификации удалены многие сообщения (элементы протокола), а оставшиеся - заметно переработаны. Есть основания полагать, что в Интернете TLS 1.3 быстро станет основной версией. Так, уже в июле 2019 года поддержку TLS 1.3 предоставляют Google и Facebook, а также основные ветки браузеров Chrome и Firefox.
Наиболее часто используемыми версиями на сегодня являются TLS 1.3 и 1.2, допускается использование TLS 1.1, однако готовится RFC, который отнесёт версии ниже 1.2 в разряд нерекомендуемых. TLS 1.0 традиционно долгие годы используется для защиты SIP. TLS 1.0 можно назвать версией 3.1 SSL, как и указано в спецификациях при описании способа наименования версий: SSL 3.1 - это TLS 1.0; 3.2 - TLS 1.1; 3.3
- TLS 1.2; 3.4 - TLS 1.3
Активная работа в рамках IETF над новой версией TLS 1.3 началась в 2014 году. Одной из причин разработки нового стандарта стал резко возросший интерес научно-технического сообщества к архитектуре TLS. Также сыграло роль обнаружение нескольких существенных уязвимостей в самом протоколе, что гораздо опаснее наличия дефектов в конкретных реализациях. Отличие версий TLS 1.3 от предыдущих обусловлено переосмыслением модели угроз, в рамках которой проектируется новый протокол: TLS попытались сделать и более быстрым (по крайней мере, потенциально), и более защищённым, и более скрытным. Существенные усилия были направлены на то, чтобы даже хорошо оснащенный и подготовленный злоумышленник не мог узнать ничего более, кроме как о факте установления TLS-соединения. TLS протокол работает поверх TCP и может обеспечить защиту IP-телефонии.
Ключевым аспектом реализации TLS является использование TLS-сертификатов. Сертификаты передаются сервером. Серверный сертификат содержит открытый ключ сервера. В теории спецификация позволяет установить соединение без отправки серверных сертификатов. Это так называемый «анонимный» режим, однако он практически не используется, как и режимы TLS без шифрования. Так, свыше 99% веб-серверов, поддерживающих TLS, передают TLS-сертификаты. Серверный сертификат - это сертификат, по имени соответствующий серверу и содержащий серверный открытый ключ электронной подписи (RSA или ECDSA).
Асимметричные криптосистемы (с открытым ключом) как правило не используют для передачи в реальном масштабе времени. Поэтому TLS использует внутри сессии симметричные шифры. Обычно это блочные шифры, работающие в режиме, сходном с потоковым. Есть несколько основных способов выработки общих секретных данных для сеансового ключа. О симметричных сеансовых ключах узлы договариваются в процессе установления соединения. Для симметричных ключей используется пара
- один для передаваемых сообщений, второй - для принимаемых. Серверному ключу
для передаваемых сообщений соответствует клиентский ключ для принимаемых. Большинство методов получения исходных данных сеансового ключа так или иначе оперируют публичным ключом сервера. На практике этот ключ использует почти 100% TLS-сессий. Публичный ключ передаётся сервером в сертификате. Помимо RSA и Диффи-Хеллмана, возможны экзотические схемы формирования ключа.
Оптимальным с точки зрения производительности для защиты медиатрафика представляется протокол SRTP (RFC 3711).
Основные задачи протокола SRTP:
шифрование передаваемых голосовых данных;
аутентификация передаваемых сообщений;
защита от дублирования пакетов;
сохранение полосы пропускания, сжатие RTP-заголовков.
Шифрование информации в SRTP выполняется методом AES (Advanced Encryption Standard - усовершенствованный стандарт шифрования, типовой размер блока 128 бит, ключ имеет длину 128/192/256 бит) (рис. 1), что повышает защищенность и производительность протокола. Возможности по конфигурированию шифрования в SRTP весьма широки вплоть до использования любого стандарта шифрования (с четко описанным алгоритмом) или отключения шифрования (используя NULL-шифр). Отключение шифрования может быть полезно для экономии аппаратных ресурсов, если важно лишь обеспечение целостности и правильного порядка доставки данных, но не требуется шифрование. При этом сохраняется защита от атаки повторного воспроизведения (playback-атак), так как блоки передаваемой информации последовательно нумеруются и исключена возможность повторной передачи уже принятого ранее сообщения. Методы шифрования SRTP обеспечивают не только безопасную передачу данных, но также и безопасное воспроизведение мультимедиа, т.е. злоумышленник не только не сможет расшифровать данные, но и также не сможет их подменить либо воспроизвести в дальнейшем после перехвата. Для аутентификации сообщения и защиты его целостности используется алгоритм HMAC-SHA1, где в качестве аргумента функция хеширования получает данные из заголовка пакета о переносимой полезной нагрузке, то есть криптозащита вполне приемлема. Недостатком протокола SRTP является то, что заголовки пакетов не шифруются, и по перехваченным данным о типе передаваемой информации злоумышленник может сделать косвенный вывод, что происходит обмен мультимедиа, и каким-либо образом помешать передаче.
Еще одним механизмом обеспечения безопасности данных в протоколе SRTP является обмен идентификационными ключами. На основе главного ключа генерируются дополнительные идентификационные ключи для каждой новой сессии. В итоге, даже если злоумышленник получит ключ, передаваемый в ходе установления сессии, то он не поможет ему для расшифровки других сессий, и объем полученных им данных не будет сколь либо значительным. Однако этот протокол не обеспечивает защиту процесса аутентификации, и необходимо использовать дополнительные механизмы, наиболее предпочтительно использование связки с TLS, который в свою очередь требует сертификатов. Связку SRTP+TLS возможно реализовать на Asterisk (начиная с версии 1.8), FreeSWITCH, Протей-Комета.
Протоколы третьей группы предназначены для формирования и распределения ключей шифрования медиатрафика между сетевыми устройствами. Для решения этих задач чаще всего в корпоративных сетях используются протоколы MIKEY, SDES, ZRTP, DTLS.
MIKEY (Multimedia Internet KEYing, протокол обмена ключами) описан в рекомендациях RFC 3830 и RFC 6043. Протокол имеет несколько режимов, регламентирующих способ формирования секретного ключа сессии для SRTP, это режим предустановленного ключа, режим открытого ключа и режим Диффи-Хелмана. Причем второй и третий режимы не защищают от атаки MITM и требуют реализации механиз-
ма аутентификации сообщений. Транспортом для переноса сообщений протокола может выступать SIP/SDP-сообщение, но чаще всего применяется протокол RTSP (Real Time Streaming Protocol).
SDES (Session Description Protocol Security Descriptions - описание безопасности протокола SDP) описан в RFC 4568. Принцип заключается в том, что один из корреспондентов передает ключ в SIP-сообщении (рис. 1). Корреспондент использует в дальнейшем его для шифрования.
При этом изначально обмен сигнальными сообщениями должен быть защищен от злоумышленника. Поэтому SDES используется только в дополнении с SIP/TLS и с цифровым сертификатом сервера. Также данный способ не обеспечивает безопасности «из конца в конец». Это означает, что сессия устанавливается от абонента А одной IP-АТС к абоненту Б другой IP-АТС, SDES будет распределять ключи между А и IP-АТС и между абонентом Б и IP-АТС, но не напрямую между А и Б.
Протокол DTLS (протокол датаграмм безопасности транспортного уровня -Datagram Transport Layer Security) является дополнением безопасности для SRTP и специфицирован в RFC 5764. Он описывает формирование медиасессий «точка-точка» с жесткой фиксацией портов UDP корреспондента. Сообщения протокола передаются совместно с RTP-пакетами. Для организации сессии (DTLS - ассоциации) абоненты обмениваются сообщениями. Так как в основе протокола DTLS лежит TLS, использующий инфраструктуру открытых ключей (PKI), то применение DTLS возможно тоже только при наличии PKI.
Asterisk и FreeSWITCH в последних версиях поддерживают протокол ZRTP, который специально разработан для защиты VoIP. ZRTP использует в качестве основы RTP протокол, предоставляет методы аутентификации и безопасности посредством шифрования данных, регламентирован RFC 6189.
Протокол ZRTP предусматривает работу по схеме «точка-точка», при этом отдельно указана возможность применения протокола в многопоточном режиме, когда необходимо организовать одновременно несколько защищенных медиапотоков (например, голос и видео). Также предусмотрен вариант работы с легитимным посредником, которым может выступать, например, программный коммутатор открытого сегмента или IP-АТС. Для работы по протоколу ZRTP каждое сетевое устройство должно иметь предустановленный уникальный идентификатор (ZID) и поддерживать одинаковые наборы криптографических алгоритмов.
Шифрование в ZRTP основано на механизме симметричного шифрования без использования защищенного канала для передачи ключа. В момент инициализации вызова SIP/TLS/ZRTP используется метод обмена ключами Диффи-Хеллмана, для аутентификации применяется SAS (Short Authentication String - короткая строка аутентификации. Особенностью реализации и главным отличительным достоинством по сравнению с SRTP является то что при установлении сеанса медиатрафик передается непосредственно между оконечными устройствами, и открытая ключевая информация передаются между абонентами в режиме передачи мультимедиа по RTP, а не в режиме установления сессии в сообщениях SIP/SDP, и не «видны» каким-либо другим устройствам, принимающим участие в передаче данных. Ключ при установлении сеанса связи ZRTP создается для каждого отдельного сеанса уникальный, и его генерация основывается на публичных идентификаторах вызова. Ключи являются временными, после окончания сеанса уничтожаются. Достоинство протокола ZRTP также состоит в том, что нет необходимости хранения заранее сгенерированных ключей и поддержания громоздкой инфраструктуры их распределения, при этом отсутствуют центры программной сертификации ключей. Так же для ZRTP гипотетически не имеет значения, какой протокол используется для установления сеанса связи - SIP, H.248, H.323, поскольку обмен ключами происходит с использованием RTP. Основываясь на методах симметричного шифрования, ZRTP не исключает возможность перехвата трафика, но позволяет обнаруживать факт перехвата. Протокол ZRTP предусматривает использование SAS.
SAS рассчитывается обоими корреспондентами по специальному алгоритму и может быть использована для вербального сравнения непосредственно после ответа абонента на вызов (увидел-произнес-сравнили). В примере на рис. 8 это символьная строка 5nkw на экране программного телефона после ответа на звонок. После подтверждения SAS голосовой (и видео) канал переводятся в закрытый режим - обратите внимание на открытый и закрытый замок на рис. 7.
Zûiper
о е
61011
s вши
' Established 00:00:09
[ 12:27 0 14,S ИБ/с * # . ..id £Ш> 74 У,
61012(61012)
Мобильный 61012 00:05
# ^ ::: Л I :
.*. Конфер а
|рансф :: II Пауза -г Меню
SaS: Бпки
9 Confirm в Reject
w I - Ф I -
Проверка SAS
Подтверждение SAS "5nkw" Пожалуйста, сравните строку со своим пиром.
Отклони Подтеер ть дить
Рис. 7. Вид окон программного телефона Zoiper для ОС Windows и Android
Для контроля целостности каждое передаваемое сообщение ZRTP содержит проверочный код CRC, а также код аутентификации сообщения MAC (Message Authentication Code), вычисляемый посредством хеш-функций. В качестве аргумента хеш-функции используется само защищаемое сообщение, ключом служит специальный параметр, передаваемый (для большинства сообщений) в следующем сообщении. Алгоритм хеширования согласовывается в самом начале сессии. Ошибка в хеш-сообщении, как правило, означает обнаружение атаки MITM, так как ошибки обусловленные каналом связи обнаруживаются при проверке контрольной суммы CRC пакета ZRTP. В итоге у злоумышленника, выполнившего перехват трафика, есть всего лишь одна возможность скомпрометировать идентификационную строку SAS. В ходе дальнейших сеансов новые ключи для абонентов, уже устанавливавших ранее сеансы связи, генерируются на основе хеш ранее созданных ключей. То есть, если злоумышленник не получил доступ к защищаемой информации при первом звонке представленные на рис. 8 - 10, то не сможет получить и при последующих.
- 14 4 235540... 192 168.1 >0.6 192 168.1 0.111 ITLSvl j 1271 Application Data
15 4 236326... 192 168.1 >0.111 192 168.1 >0.6 TLSvl 732 Application Data, Application Data
16 4 239596... 192 168.1 0.6 192 168.1 0.111 TCP 66 Д3811 -»• 5061 [ACK] Seq=1206 Ack=667 Win- 514 Len=0 TSval= 7647523 TSecr=55019
17 4 311783... 192 168.1 >0.6 192 168.1 0.111 TLSvl 519 Application Data
18 4 349227... 192 168.1 >0.111 192 168.1 0.6 TCP 66 5061 43811 [ACK] Seq=667 Ack=1659 Win- 517 Len=0 TSval= 55048 TSecn=7647530
19 4 353967... 192 168.1 >0.6 192 168.1 >0.111 TLSvl 1431 Application Data
20 4 353988... 192 168.1 >0.111 192 168.1 >0.6 TCP 66 5061 43811 [ACK] Seq=667 Ack=3024 Win- 540 Len=0 TSval= 55049 TSecn=7647534
21 4 35646Z.. 192 168.1 >0.111 192 168.1 >0.6 TLSvl 732 Application Data, Application Data
TJ Л ЗЙЙ17/1 1Q9 1fiK 1 Ш 111 1Q9 1ЙЯ 1 \а 1 Tl 4u1 7 91 aa flnnl ¡ratinn Пэ+а
Рис. 8. Окно программы Wireshark при захвате защищенного сигнального
трафика SIP
• Frame 14: 1271 bytes on wire (10168 bits), 1271 bytes captured <10168 bits) on interface eth0, id 0 Ethernet II, Src: XiaomiCo_d2:2f:a7 (18:f0:e4:d2:2f:a7), Dst PcsCompu_48:63:aa <08:00:27:48 : 63 :aa) Internet Protocol Version 4, Src: 192.168.130.6, Dst: 192.168.100.111
Transmission Control Protocol, Src Port: 43811, Dst Port: 5061, Seq: 1, Ack: 1, Len: 1205
* Transport Layer Security
A TLSvl Record Layer: Application Data Protocol: sip.tcp Content Type: Application Data (23) Version: TLS 1.0 (0x0301) Length: 1200
[Encrypted Application Data: 9dlb50a8cble6849b445544alcfd7176ff63b5f97d001025...
Рис. 9. Содержимое перехваченного пакета SIP/TCP защищенного протоколом TLS
298
t> Frame 70: 224 bytes on wire (1792 bits), 224 bytes captured (1792 bits) on interface eth0, id 0 Ethernet II, Src: PcsCompu_48:63:aa (08:00:27:48:63:aa), Dst: HonHaiPr_42:e6:3c (3c : 77 :eo: 42 :eô: 3c) Internet Protocol Version 4, Src: 192.168.100.111, Dst: 192.168.100.7 User Datagram Protocol, Src Port: 10584, Dst Port: 4006 * Data (182 bytes)
Data : 8098a0d2090902S865788ca95d711bf424532021284e56e6... [Length: 182]
Рис. 10. Содержимое перехваченного речевого пакета
Выводы. Свободно распространяемые программные IP-телефоны, на основе открытого ПО, которые могут реализовать протокол ZRTP, представлены достаточно широко. Это CsipSimple, Баклан для ОС Android, Jitsi, Phoner для Windows, Zoiper для обоих указанных ОС и для Linux.
Сложность в реализации программного шифрования в поставляемых аппаратно-программных средствах Уо1Р на сети связи специального назначения представляет отсутствие поддержки в таких устройствах рассмотренных протоколов, поскольку на начальном этапе цифровизации сети вопросу безопасности открытого сегмента уделялось гораздо меньше внимания, технические условия на поставку оборудования не предусматривали таких средств, да и сами протоколы стремительно развиваются, предлагая по сравнению с начальным этапом построения сети гораздо больший выбор. Необходимо также отметить, что поставляемые в открытый сегмент сети МО РФ программно-аппаратные средства зачастую основаны на свободном программном обеспечении, однако если исходные продукты реализуют механизмы защиты, то выходной продукт, такой как СППГ, имеет урезанный функционал. НТЦ «Протей» например в своих продуктах заявляют поддержку транспортного протокола TLS, однако в поставках специальной техники для нужд МО РФ таковая отсутствует. На данный момент нет информации, какие из оконечных аппаратных IP-телефонов осуществляют поддержку ZRTP. Примером реализации SRTP являются аппараты Yealink. Поэтому компромиссным вариантом реализации защиты IP-телефонии на сети связи специального назначения видится применение протоколов SIP/TLS/SRTP.
Услуга IP-телефонии - это сложное решение, и для защиты следует применять комплексный подход, учитывая возможные угрозы на всех уровнях. Кроме этого, следует не забывать и об общепринятых мероприятиях, таких как поддержание версии ПО и ОС IP АТС, IP-шлюзов и программных коммутаторов в актуальном состоянии, обновление прошивок и настройка безопасности оконечного оборудования.
Список литературы
1. Протоколы обеспечения безопасности IP-телефонии. М.Ковцур. Первая миля
5/2012.
2. Гольдштейн Б.С., Пинчук А.В., Суховицкий А.Л. IP-телефония. -M.: Радио и связь, 2001. 336 с.
3. Обеспечиваем безопасность VoIP-сервиса и защиту от прослушивания [Электронный ресурс] URL: https://xakep.ru/2014/09/08/safe-voip/ (дата обращения: 10.01.2021).
4. Оценка уровня риска угрозы безопасности фрода в сети VoIP по протоколу SIP. Матвеев В.А., Морозов А.М., Бельфер Р.А. Электросвязь. 2014. № 6. С. 35-38.
5. Анализ протоколов защищенной IP-телефонии. Ляхов А.В., Касьянен-ко Н.Г. Информационные системы и технологии в моделировании и управлении. IV Всероссийская научно-практическая конференция. Посвящается 75-летию Гуманитарно-педагогической академии (филиал) ФГАОУ ВО «КФУ им. В.И. Вернадского» в г. Ялте. 2019. С. 129-133.
6. Ключи, шифры, сообщения: как работает TLS. Александр Венедюхин [Электронный ресурс] https://tls.dxdt.ru/tls.html (дата обращения: 10.01.2021).
Елисеев Дмитрий Иванович, преподаватель, eliseevvDI@mail.ru, Россия, Санкт-Петербург, Военная академия связи имени Маршала Советского Союза С.М. Буденного,
Савельев Евгений Алексеевич, старший научный сотрудник, savea1941@yandex. ru, Россия, Санкт-Петербург, Военная академия связи имени Маршала Советского Союза С.М. Буденного,
Иванов Денис Александрович, преподаватель, prosto_deniss@,mail.ru, Россия, Санкт-Петербург, Военная академия связи имени Маршала Советского Союза С. М. Буденного,
Ачкасов Николай Борисович, преподаватель, profAchasovv@yandex.ru, Россия, Санкт-Петербург, Военная академия связи имени Маршала Советского Союза С. М. Буденного
PROBLEMS WITH PROTECTING SPEECH SERVICES IN A SPECIAL-PURPOSE
MULTISERVICE NETWORK
D.I. Eliseev, E.A. Savelyev, D.A, Ivanov, N.B. Achkasov
The article considers methods of influencing the technology of VoIP services, in particular speech transmission in the open segment of IP telephony, which showed that IP telephony protection should be built at all levels of the reference model, starting with the application, special attention in recent years is paid to the transport layer, network, and ending with the correct configuration of the numbering plan. In addition, you should not forget about the generally accepted measures, such as maintaining the software and OS versions of IP PBX, IP gateways and software switches in the current state, updating firmware and configuring the security of terminal equipment.
Key words: protection, multiservice networks, IP phones, malicious impact, reference model.
Yeliseyev Dmitry Ivanovich, teacher,, eliseevvDI@mail.ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny,
Savelyev Evgeny Alexeyevich, senior researcher, savea1941@yandex.ru, Russia, Saint Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny,
Ivanov Denis Alexandrovich, teacher, prosto_deniss@,mail. ru, Russia, Saint Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny,
Achkasov Nikolay Borisovich, teacher, profAchasovv@yandex. ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny
