Как настроить шифрование канала связи

Защита от прослушивания разговоров — строим безопасную SIP телефонию своими руками

Привет, Хабр!
В этот раз хочу рассказать о технологиях шифрования VoIP звонков, о том какую защиту дают разные подходы и как организовать наиболее защищенную от прослушивания голосовую связь с технологическими гарантиями безопасности.
В статье я постараюсь доступно изложить особенности таких технологий как SIP\TLS, SRTP и ZRTP. И продемонстрирую конкретные схемы использования на примере нашего сервиса ppbbxx.com

Немного теории

Любой VoIP вызов состоит из 2-х основных составляющих: обмена сигнальной информацией и передачи между пользователями media потоков с голосом и/или видео.
На первом этапе, в процессе обмена сигнальной информацией, клиенты напрямую либо посредством сервера договариваются между собой о параметрах устанавливаемого вызова. Если связь устанавливается с помощью сервера, на основе сигнальной информации сервер авторизует клиента, устанавливает кто и кому звонит, проводит маршрутизацию и коммутацию. Благодаря данным сигнального протокола клиенты и сервер согласуют метод шифрования, используемые media кодеки, обмениваются ip адресами и номерами портов, где ожидается приём media и тд. Происходит это по таким протоколам как SIP, XMPP и прочим.
Непосредственно «разговор», то есть обмен между клиентами голосовыми данными, как правило происходит по протоколу RTP. Данные внутри передаются в том виде, о котором договорились клиенты и сервер на «сигнальном» этапе. Обмен голосом возможен как напрямую между клиентами, так и через сервер — посредник. Во втором случае сервер может помочь клиентам с прохождением NAT и в выборе кодеков.

Итак, что же собой представляет шифрованный VoIP вызов? Дальше речь пойдёт о SIP протоколе как наиболее популярном.
Как мы уже выяснили, звонок состоит из сигнальной и media частей, каждая из которых может быть зашифрована отдельно с применением специальных методов-протоколов. Для шифрования сигнальной информации применяется SIP\TLS, для шифрования «голоса» ZRTP и SRTP протоколы.

SIP\TLS — грубо говоря, аналог HTTPS для обычного SIP. Протокол позволяет клиенту убедиться, что он общается с нужным сервером при условии, что клиент доверяет предоставленному сервером сертификату. Подробнее можно прочитать на википедии

SRTP и ZRTP — это два разных способа шифровать RTP потоки. Принципиальное отличие между ними в том, что обмен ключами для SRTP происходит в сигнализации (на первой сигнальной стадии установки вызова). А для ZRTP непосредственно в начале обмена RTP пакетами (во второй, «медийной» части) по специальному протоколу, основанному на методе криптографии Диффи — Хеллмана.
Важно то, что для SRTP обязательным условием надёжности шифрования звонка является одновременное использование SIP\TLS + SRTP, иначе злоумышленнику не составит труда получить ключи (которые будут переданы по не шифрованному SIP) и прослушать разговор. В то время как для ZRTP это не важно, RTP поток будет надёжно зашифрован не зависимо от того, шифруется сигнализация или нет. Более того протокол умеет определять наличие «man in the middle» (в том числе серверов услуг!) между непосредственно говорящими клиентами. Это позволяет быть уверенным в том, что разговор невозможно прослушать, по крайней мере с точки зрения прослушивания сети/среды передачи данных.

Схема подключения SIP клиентов с различными настройками шифрования:

Можно выделить следующие схемы установки шифрованного звонка:

Оба пользователя используют SIP\TLS и SRTP. В этом случае обмен ключами для шифрования media происходят по защищенному сигнальному протоколу. Предполагается доверие к серверу, участвующему в установке связи. Посторонние не могут получить доступ ни к сигнальной информации, ни к голосовым данным. Недостаток в том, что пользователь не уведомлен на уровне протокола (клиента) и не убежден, что второй пользователь также использует шифрованное подключение к серверу.

Оба пользователя используют ZRTP, голос при этом проходит через сервер. В этом случае сервер определяется ZRTP протоколом как Trusted MitM (man in the middle). Обмен ключами происходит по алгоритму, основанному на методе Диффи — Хеллмана (что и гарантирует невозможность прослушки) по протоколу RTP. Если при этом используется защищенный SIP\TLS — посторонние так же не могут получить доступ ни к сигнальной информации, ни к «голосу». Как и в первом варианте предполагается доверие к коммутирующему серверу, но в отличии от него для надёжного шифрования голоса не требуется обязательное использование защищенного SIP\TLS. Также, в отличии от первого варианта, каждый пользователь видит, что разговор шифруется до сервера с обоих сторон, а также то, что оба подключены к одному и тому же (доверенному) серверу.

Оба пользователя используют ZRTP, но media устанавливается напрямую между клиентами. Так как обмен ключами проходит напрямую между клиентами, даже сервер, осуществивший коммутацию, не может прослушать разговор. В этом случае оба клиента отображают информацию о том, что установлен безопасный прямой сеанс связи. Убедиться в этом можно сверив SAS (короткие строки авторизации) — они будут одинаковыми. Если требуется скрыть от посторонних сигнальную информацию, следует использовать SIP\TLS. Это самый безопасный вариант, но в этом случае сервер не сможет выполнять многие функции, которые в других ситуациях выполняются на нем, к примеру запись непосредственно разговора, перекодирование голоса для клиентов с разными настройками аудиокодеков и тд.

Один пользователь использует первый метод, описанный выше, а другой — второй. В этом случае так же требуется доверие к серверу. Сигнальная информация шифруется с помощью SIP\TLS. Для пользователя с ZRTP протокол сообщит, что шифрованное соединение установлено до сервера (End at MitM). Используется ли шифрование с другой стороны на уровне протокола узнать не удастся.

На этом закончим с теорией и перейдём к практике! Настроим собственный SIP сервер, создадим SIP пользователей, установим SIP клиенты и научимся совершать шифрованные звонки c помощью бесплатного сервиса облачной телефонии ppbbxx.com

Настройка сервера

Для начала нужно создать собственный сервер. Для этого нужно зайти на сайт услуги ppbbxx.com, пройти простую регистрацию и войти в интерфейс настроек.

Первым делом пройдём в раздел «Internal network -> Domains» и создадим собственный домен, чтобы не быть ограниченным в выборе имён SIP пользователей. Можно припарковать свой домен либо создать личный субдомен в одной из зон сервиса.
Далее необходимо в разделе «Internal network -> Sip Users» создать SIP пользователей и настроить некоторые параметры их клиентов. Имена SIP пользователей могут быть произвольными, но так как на программных и аппаратных телефонах удобнее набирать цифры, мы будем заводить идентификаторы вида 1000@mydomain.ppbbxx.com и подобные. Я завёл 1000, 1001, 1002, 1003. После создания SIP идентификатора нужно не забыть нажать кнопку «Сохранить». Если никаких недозаполненных форм в интерфейсе настроек не осталось, система не будет ругаться и покажет лог изменений со статусом «Done».

Дальше необходимо настроить используемые кодеки и методы шифрования. Для этого нужно нажать значок с шестерёнкой слева от SIP идентификатора. Я планирую использовать SIP клиент (CSipSimple) на смартфоне и хочу использовать метод шифрования ZRTP поэтому в «basic» вкладке настроек выбираю кодеки G729 и SILK, а во вкладке «protection» ZRTP метод.

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

В целом, для настройки простейшей конфигурации этого достаточно. Можно настраивать SIP клиенты и звонить между ними, набирая их номера 1000, 1001, 1002, 1003. При желании к этому можно добавить общий SIP шлюз для звонков в телефонную сеть и настроить соответствующую маршрутизацию звонков. Но, в таком случае, это уже несколько иная схема использования услуги, которая требует скорее другого рода мер безопасности, нежели шифрование трафика до шлюза.

Перейдём к настройке SIP клиентов

Как я уже сказал, я планирую использовать CSipSimple на андроид смартфонах. Первым делом нужно установить клиент, используя стандартный Play Market, либо скачать на сайте производителя, который кстати открывает исходники своего клиента, что в отдельных случаях может иметь едва ли не сакральное значение. Установить нужно сам клиент и дополнительно кодеки. У меня установлены «CSipSimple», «Codec Pack for CSipSimple» и «G729 codec for CSipSimple». Последний платный и использовать его не обязательно, бесплатные SILK и OPUS обеспечивают достойное качество звонков по 3G сетям.

Запускаем CSipSimple и переходим в интерфейс настройки. Выбираем мастер «Вasic» и настраиваем, используя данные из веб интерфейса. Должно получиться так:

Далее в общих настройках CSipSimple в разделе «Медиа -> Аудиокодеки» нужно выбрать предпочитаемые кодеки. Для звонков через 3G я рекомендую использовать SILK, OPUS, iLBC, G729. Поскольку настройки в интерфейсе сервера и в интерфейсе клиента должны совпадать, а на сервере я выбрал SILK и G729, то в списке аудиокодеков CSipSimple я ставлю галочки только напротив этих кодеков, а остальные снимаю.
В разделе клиента «Сеть -> Безопасный протокол» нужно выбрать желаемые параметры шифрования. Я включаю только ZRTP. Остальное оставляю выключенным. При желании можно использовать SIP\TLS — нужно учитывать что сервер ожидает TLS соединения на 443-м порту. Это сделано специально для слишком умных операторов мобильной связи, блокирующих стандартные для VoIP порты.
Так же нужно учитывать, что SRTP и ZRTP не всегда совместимы и крайне желательно выбирать в клиенте только один из них.

Совершение звонков с использованием ZRTP

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

Сразу после выполнения инструкции звонок SIP пользователя 1001 пользователю 1000 будет выглядит таким образом.
CSipSimple показывает, что в звонке участвует MitM сервер, к которому подключены оба клиента. Параметр EC25 означает, что используется протокол Диффи-Хеллмана на эллиптических кривых с параметром 256 бит. AES-256 — алгоритм симметричного шифрования, который применяется. Статус ZRTP — Verifyed означает, что контрольная строка SAS подтверждена пользователем.

Изменим режим передачи медиа в настройках ppbbxx для обоих клиентов. Установка direct media = yes позволит передавать голос напрямую. В этом случае стороны видят одинаковые строки SAS, используется алгоритм симметричного шифрования Twofish-256. Использование ZRTP в этом режиме требует от клиентов намного большей свместимости и менее надежно с точки зрения установки связи, поскольку сервер не участвует в передаче данных. Обязательно использование одинаковых аудиокодеков на всех клиентах и корректная работа NAT.

Если у SIP пользователя 1001 шифрование не установлено, тогда как 1000 использует ZRTP, то второй клиент покажет, что зашифрованная передача голоса происходит только до сервера (End at MitM).

Источник

Шифруемся по ГОСТу: памятка по настройке динамической маршрутизации трафика

Пара слов о проекте

Топология сети у заказчика была типовая — full mesh между центром и филиалами. Требовалось внедрить шифрование каналов обмена информацией между всеми площадками, коих было 8 штук.

Обычно в подобных проектах всё статично: на криптошлюзах (КШ) задаются статические маршруты в локальную сеть площадки, прописываются списки IP-адресов (ACL) для шифрования. Однако в данном случае у площадок нет централизованного управления, и внутри их локальных сетей может происходить всё, что угодно: сети могут добавляться, удаляться и всячески модифицироваться. Для того чтобы избежать перенастройки маршрутизации и ACL на КШ при изменении адресации локальных сетей на площадках, было принято решение использовать GRE-туннелирование и динамическую маршрутизацию OSPF, в которую включены все КШ и большинство маршрутизаторов уровня ядра сети на площадках (на некоторых площадках администраторы инфраструктуры предпочли использовать SNAT в сторону КШ на маршрутизаторах ядра).

GRE-туннелирование позволило решить две задачи:
1. Использовать в ACL для шифрования IP-адрес внешнего интерфейса КШ, в котором инкапсулируется весь трафик, направляющийся на другие площадки.
2. Организовать p-t-p туннели между КШ, которые позволяют настроить динамическую маршрутизацию (в нашем случае между площадками организован провайдерский MPLS L3VPN).

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

А теперь собственно памятка – как и что мы настраивали

Субъекту КИИ на заметку: настраиваем криптошлюз

Базовая настройка сети

Прежде всего запускаем новый КШ и попадаем в консоль администрирования. Начать стоит с изменения пароля встроенного администратора — команда change user password administrator. Затем необходимо с провести процедуру инициализации (команда initialize) в процессе которой вводятся данные лицензии и инициализируется датчик случайных чисел (ДСЧ).

Обратите внимание! При инициализации КШ S-Terra устанавливается политика безопасности, при которой интерфейсы шлюза безопасности не пропускают пакеты. Необходимо либо создать собственную политику, либо с помощью команды run csconf_mgr activate выполнить активацию предустановленной разрешающей политики.
Далее необходимо настроить адресацию внешних и внутренних интерфейсов, а также маршрут по умолчанию. Работу с сетевой конфигурацией КШ и настройку шифрования предпочтительно выполнять через Cisco-like консоль. Данная консоль предназначена для ввода команд, аналогичных командам Cisco IOS. Конфигурация, сформированная с помощью Cisco-like консоли, в свою очередь конвертируется в соответствующие конфигурационные файлы, с которыми работают демоны ОС. Перейти в Cisco-like консоль из консоли администрирования можно командой configure.

Меняем пароли на встроенного пользователя cscons и enable:

>enable
Password: csp(предустановленный)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Настраиваем базовую сетевую конфигурацию:

#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#no shutdown
#interface GigabitEthernet0/1
#ip address 192.168.2.5 255.255.255.252
#no shutdown
#ip route 0.0.0.0 0.0.0.0 10.111.21.254

Выходим из Cisco-like консоли, и переходим в debian shell командой system. Устанавливаем собственный пароль для пользователя root командой passwd.
На каждом КШ настраивается отдельный туннель для каждой площадки. Настройка туннельного интерфейса производится в файле /etc/network/interfaces. За создание самого интерфейса отвечает утилита IP tunnel, входящая в предустановленный набор iproute2. Команда создания интерфейса прописывается в опцию pre-up.

Пример конфигурации типового туннельного интерфейса:
auto site1
iface site1 inet static
address 192.168.1.4
netmask 255.255.255.254
pre-up ip tunnel add site1 mode gre local 10.111.21.3 remote 10.111.22.3 key hfLYEg^vCh6p

Обратите внимание! Надо заметить, что настройки туннельных интерфейсов необходимо располагать вне секции

В противном случае данные настройки будут затерты при изменении сетевых настроек физических интерфейсов через Cisco-like консоль.

Динамическая маршрутизация

В S-Terra динамическая маршрутизация реализуется при помощи пакета программ Quagga. Для настройки OSPF нам потребуются включение и настройка демонов zebra и ospfd. Демон zebra отвечает за взаимодействие между демонами маршрутизации и ОС. Демон ospfd, как понятно из названия, отвечает за реализацию протокола OSPF.
Настройка OSPF производится либо через консоль демона, либо напрямую через конфигурационный файл /etc/quagga/ospfd.conf. В файл добавляются все физические и туннельные интерфейсы участвующие в динамической маршрутизации, а также объявляются сети, которые будут анонсироваться и принимать анонсы.

Пример конфигурации, которую требуется добавить в ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
network 192.168.1.4/31 area 0.0.0.0
network 192.168.1.16/31 area 0.0.0.0
network 192.168.2.4/30 area 0.0.0.0

В данном случае адреса 192.168.1.х/31 отведены под туннельные ptp-сети между площадками, адреса 192.168.2.х/30 — под транзитные сети между КШ и маршрутизаторами ядра.

Обратите внимание! Для уменьшения таблицы маршрутизации в крупных инсталляциях можно отфильтровать анонсирование самих транзитных сетей с помощью конструкций no redistribute connected или redistribute connected route-map.

После настройки демонов необходимо изменить статус запуска демонов в /etc/quagga/daemons. В опциях zebra и ospfd no исправить на yes. Запустить демон quagga и установить его автозапуск при запуске КШ командой update-rc.d quagga enable.

Если настройка GRE-туннелей и OSPF выполнена верно, то на КШ и маршрутизаторах ядра должны появится маршруты в сети остальных площадок и, таким образом, возникает сетевая связность между локальными сетями.

Шифруем передаваемый трафик

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

Шифрование в КШ S-Terra выполняется посредством протокола IPSec. Мы используем алгоритм «Кузнечик» в соответствии с ГОСТ Р 34.12-2015, а для совместимости со старыми версиями можно применить ГОСТ 28147-89. Аутентификация технически может выполняться как на предопределенных ключах (PSK), так и на сертификатах. Тем не менее в промышленной эксплуатации необходимо использовать сертификаты, выпущенные по ГОСТ Р 34.10-2012.

Работа с сертификатами, контейнерами и CRL выполняется с помощью утилиты cert_mgr. Первым делом с помощью команды cert_mgr create необходимо сформировать контейнер закрытого ключа и запрос на сертификат, который будет направлен в Центр управления сертификатами. После получения сертификата его вместе с корневым сертификатом УЦ и CRL (если используется) необходимо импортировать командой cert_mgr import. Убедиться в том, что все сертификаты и CRL установились можно командой cert_mgr show.

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

#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600

Данная политика применяется при построении первой фазы IPSec. Результатом успешного прохождения первой фазы служит установление SA (Security Association).
Далее нам потребуется определить список IP-адресов источника и получателя (ACL) для шифрования, сформировать набор преобразований (transform set), создать криптографическую карту (crypto map) и привязать ее к внешнему интерфейсу КШ.

Задаем ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3

Набор преобразований (так же, как и для первой фазы, используем алгоритм шифрования «Кузнечик» с использованием режима выработки имитовставки):

#crypto ipsec transform-set GOST esp-gost341215k-mac

Создаем криптокарту, указываем ACL, transform set и адрес пира:

#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3

Привязываем криптокарту к внешнему интерфейсу КШ:

#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN

Для шифрования каналов с другими площадками необходимо повторить процедуру создания ACL и криптокарты, изменив название ACL, IP-адреса и номер криптокарты.

Обратите внимание! В том случае, если не используется проверка сертификатов по CRL, это необходимо явно указать:

#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none

На этом настройку можно считать завершенной. В выводе команд Cisco-like консоли show crypto isakmp sa и show crypto ipsec sa должны отражаться построенные первые и вторые фазы IPSec. Эту же информацию можно получить с помощью команды sa_mgr show, выполненной из debian shеll. В выводе команды cert_mgr show должны появиться сертификаты удаленных площадок. Статус таких сертификатов будет remote. В том случае если туннели не строятся, необходимо заглянуть в лог VPN-сервиса, который хранится в файле /var/log/cspvpngate.log. Полный список лог-файлов с описанием их содержания присутствует в документации.

Мониторим «здоровье» системы

В КШ S-Terra для мониторинга используется стандартный демон snmpd. Помимо типичных для Linux параметров, S-Terra «из коробки» поддерживает выдачу данных об IPSec-туннелях согласно CISCO-IPSEC-FLOW-MONITOR-MIB, чем мы и пользуемся, отслеживая состояние IPSec-туннелей. Также поддерживается функционал кастомных OID’ов выдающих в качестве значений результаты выполнения скрипта. Эта возможность позволяет нам отслеживать сроки истечения сертификатов. Написанный скрипт парсит вывод команды cert_mgr show и в результате выдает количество дней до истечения локального и корневого сертификатов. Данный прием незаменим при администрировании большого количества КШ.

В чем цимус такого шифрования

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

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

Безусловно, шифрование за счет накладных расходов (overhead) влияет на скорость передачи данных, но незначительно — пропускная способность канала может снизиться максимум на 5—10 %. При этом технология протестирована и показала хорошие результаты даже на спутниковых каналах, которые довольно нестабильны и обладают низкой пропускной способностью.

Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»

Источник