Иван Башлаков
02.07.2020
1308110

Проблемы безопасности и их решение при передаче голосовых данных по протоколу RTP

В данной статье мы рассмотрим основные проблемы безопасности, существующие в протоколе RTP, позволяющие злоумышленникам проводить различного рода атаки и перехват мультимедиа-трафика в VoIP-звонках. Системным администраторам и интеграторам VoIP будет полезно ознакомиться с данными уязвимостями и методами их решения, разработанными командой разработчиков PBX Asterisk. Уязвимости, позволяющие производить эксплоиты на RTP-трафик RTP — (Realtime Transport Protocol) — […]

В данной статье мы рассмотрим основные проблемы безопасности, существующие в протоколе RTP, позволяющие злоумышленникам проводить различного рода атаки и перехват мультимедиа-трафика в VoIP-звонках. Системным администраторам и интеграторам VoIP будет полезно ознакомиться с данными уязвимостями и методами их решения, разработанными командой разработчиков PBX Asterisk.

Уязвимости, позволяющие производить эксплоиты на RTP-трафик

RTP — (Realtime Transport Protocol) — является протоколом передачи мультимедийной информации в режиме реального времени прикладного уровня модели OSI. Данный протокол используется в системах связи, таких как VoIP-телефония, видеоконференциях, IPTV и т.п.

RTP использует в качестве транспорта протокол UDP, а для мониторинга статистики передачи и обеспечения качества обслуживания RTCP. Протокол RTP является одним из технических основ в VoIP-телефонии, обеспечивая передачу голоса в таких протоколах, как SIP и IAX/IAX2.

RTP изначально разрабатывался для передачи мультимедиа, поэтому он имеет следующие особенности:

  • Информация, передаваемая по данному протоколу, содержит временные метки для синхронизации;
  • Пакеты нумеруются для избежания потерь либо неправильного порядка доставки;
  • Указывается формат передаваемых данных для контроля полезной нагрузки на канал.

Тем не менее, RTP содержал в себе некоторые потенциальные угрозы безопасности. Разработчикам потребовалось немало сил и времени для устранения уязвимости несанкционированного раскрытия данных RTP в стеке транспортных протоколов в реальном времени. Например, если злоумышленник знал RTP-порты сеанса связи или одновременно отправлял пакеты на все потенциальные RTP-порты и мог отправлять их достаточное количество в установленном потоке, то Asterisk блокировался и это могло бы привести к отказу в обслуживании. Это потенциально позволило бы злоумышленнику временно отклонить, перенаправить или перехватить поток RTP в установленном вызове или выполнить распределенную атаку типа «отказ в обслуживании» (DDоS) в системе связи.


Представление сессии взаимодействия при передаче мультимедиа данных

Несмотря на то, что протокол RTP разработан около 25 лет назад и последняя его спецификация была опубликована в 2003 году, данная технология содержала в себе некоторые уязвимости, которые мы рассмотрим в данной статье. Стоит заметить, что благодаря усилиям команды разработчиков Asterisk, данные проблемы были устранены. 

Проблемы безопасности, содержащиеся в протоколе RTP, вызывали некоторые проблемы для разработчиков и пользователей VoIP, и не только для пользователей Asterisk. Хотя этот список не является исчерпывающим, следующие три особенности RTP вместе создают ситуацию, которая привела к уязвимости в Asterisk. Перечислим данные особенности:

  • Трафик сообщений SIP, включая сообщения SDP, которые содержат в себе параметры потока RTP, зачастую передается в виде простого текста по UDP или TCP.
  • Многие сети используют инфраструктуру NAT. RTP не имеет встроенных сценариев трансляции IP-адресов и портов. Это приводит к тому, что IP-адрес и порт назначения RTP, передаваемые в сообщениях SDP, становятся недоступными с другой конечной точки в сеансе.
  • Протокол RTP не имеет встроенных механизмов аутентификации или авторизации. Таким образом, нет никакого способа проверить из пакета RTP, что пакет пришел от конечной точки, авторизованной для передачи в этом сеансе.

Рассмотрим каждую из проблем более подробно:

Проблема: трафик SIP-сообщений часто передается в виде простого текста

Во многих случаях SIP-устройства устанавливают сеанс связи, отправляя сообщения сигнализации SIP в виде простого текста по транспортным протоколам UDP или TCP. Если бы злоумышленнику удалось перехватить поток этих сообщений, он мог бы определить адреса источника/назначения для перехвата потока мультимедиа RTP. Хотя большая часть информации в пакете SIP или SDP будет считаться метаданными, в более широком контексте эта информация значительно упрощает выполнение разнообразных атак VoIP. Без этой информации злоумышленнику пришлось бы постоянно отправлять большое количество пакетов по большому диапазону портов, чтобы нарушить потоки мультимедиа RTP, что часто затруднительно, но, безусловно, возможно.

Решение: шифрование сигнализации SIP

На протяжении многих лет Asterisk поддерживает шифрование трафика SIP-сообщений через TLS в своем драйвере канала chan_sip . С введением драйвера канала chan_pjsip и сопровождающего его стека SIP эта та же функциональность была перенесена. Таким образом, если ваша конечная точка поддерживает связь с Asterisk через TLS, весь ваш трафик SIP-сообщений и тела сообщений SDP могут быть зашифрованы, и злоумышленники не смогут перехватить сообщения, чтобы получить информацию о установленном сеансе RTP.

Использование протокола SIP c шифрованием TLS

Проблема: невозможность аутентификации RTP-трафика

Хотя сообщения SIP могут быть легко аутентифицированы, сам протокол RTP, без помощи других протоколов, не имеет никаких средств для аутентификации. Без использования других протоколов нет надежного способа определить, является ли полученный вами RTP-пакет именно тем, который послал отправитель. RFC RTP дает некоторые рекомендации, относительно данной проблемы:

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

Вне этого механизма конфиденциальность пакетов RTP может быть обеспечена с использованием SRTP с одним из протоколов обмена ключами, либо SDES, либо DTLS. В случае SDES обмен ключами происходит в трафике сообщений SIP, что также требует использования зашифрованного трафика сообщений SIP. В случае DTLS обмен ключами происходит в потоке RTP. Кроме того, можно использовать ICE с атрибутами ice-ufrag   и ice-pwd   с зашифрованной сигнализацией для обеспечения целостности передачи потока RTP.

Решение: шифрование медиа трафика

Начиная с версии 1.8, Asterisk поддерживает протокол SDES-SRTP, а с версии 11 Asterisk поддерживает как DTLS-SRTP, так и ICE. При зашифрованном потоке мультимедиа злоумышленнику чрезвычайно трудно, практически невозможно, повлиять на поток RTP.

Сессия с использованием шифрования SRTP
Важно отметить, что, если механизмы SDES-SRTP или DTLS-SRTP объединяется с шифрованием сообщений SIP с помощью протокола TLS, уязвимости, о которых сообщается в Asterisk, исключительно трудно использовать.

Asterisk предоставляет механизмы, которые всегда должны использоваться для предотвращения обработки неавторизованного RTP-трафика в течение сеанса связи:

  • strictrtp  — введенный в Asterisk 1.6, strictrtp  заставляет Asterisk отбрасывать все полученные RTP-пакеты, которые поступают не с исходного IP-адреса и порта отправителя потока RTP. Фактически, как только Asterisk «заблокирован» на прием пакетов RTP для определенного сеанса, он будет отбрасывать пакеты из любого другого источника (не важно, вредоносного или иного).
  • probation — введенный в Asterisk 1.8.10.0 и Asterisk 11.0.0, механизм probation еще больше повышает строгий контроль за RTP-трафиком за счет того, что Asterisk хранит исходный IP-адрес и порт потока RTP перед блокировкой и отклонением любых пакетов RTP из других источников. Это не позволяет злоумышленнику отправить пакет RTP до первого действительного пакета RTP и эффективно «украсть» поток. Количество пакетов, которые Asterisk получает до того, как заблокирует исходный IP-адрес и порт, по умолчанию установлено на 4.
RTP сессия с использованием протокола управления передачей данных (RTCP)

Проблема: NAT

Рассмотрим простой сценарий использования NAT, показанный ниже, где SIP-телефон за NAT хочет установить связь с АТС Asterisk с открытым IP-адресом:

Сетевая инфраструктура с использованием NAT

Когда конечная точка SIP со своим частным IP-адресом 192.168.0.2 отправляет запрос SIP INVITE на АТС Asterisk, она обозначает в теле SDP, что она хочет принимать пакеты RTP по IP-адресу 192.168.0.2 и некоторому порту (скажем, 10004), например:

c=IN IP4 192.168.0.2
m=audio 10004 RTP/AVP 0 8 101

Очевидно, что Asterisk не может отправлять медиапоток на 192.168.0.2, так как у него нет маршрутизируемого пути к этому IP-адресу. Однако, с ним могут взаимодействовать множество SIP-телефонов, которые имеют один и тот же IP-адрес. Несмотря на то, что за пределами Asterisk существуют механизмы, которые могут облегчить проблемы с NAT (такие как SIP ALG, ICE/STUN/TURN и т. д.), эти механизмы не всегда могут быть доступны.

Решение: Симметричные опции RTP

В то время как некоторые устройства NAT могут реализовать SIP ALG, чтобы помочь с трансляцией правильного IP-адреса и порта (и, в некоторых случаях, чтобы еще больше усложнить ситуацию), и в то время как есть некоторые протоколы, которые конечные абоненты могут использовать, чтобы помочь обнаружить их общедоступный IP-адрес адрес и порт, часто эти вещи недоступны или недостаточны для передачи мультимедиа. В этих случаях для данного сеанса Asterisk предоставляет возможность как в chan_sip  (nat=yes  или nat=comedia  или nat=force_rport,comedia), так и в chan_pjsip  (rtp_symmetric = true),  для отправки пакетов RTP на тот же IP-адрес и порт, с которого мы получили пакеты RTP.

Как правило, устройства NAT будут ретранслировать пакеты через этот порт обратно абоненту, который отправил медиа-поток. Большинство SIP-устройств, если они получают пакет RTP на тот же порт, с которого они передали RTP, распознают, что они находятся за NAT, и обрабатывают поток медиаданных так, как если бы он был получен на объявленном порту. Это позволяет конечным точкам обойти проблему использования NAT, создавая двунаправленную среду без помощи ALG или других протоколов.

Подписаться
Уведомление о
guest
0 Комментарий
Inline Feedbacks
View all comments

Остались вопросы?

Я - Першин Артём, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

ближайшие курсы

ближайшие Вебинары

ONLINE

10 доводов в пользу Asterisk

Распространяется бесплатно.

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

Безопасен в использовании.

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

Надежен в эксплуатации.

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

Гибкий в настройке.

Зачастую возможности Asterisk ограничивает только фантазия пользователя. Ни один конструктор шаблонов не сравнится с Asterisk по гибкости настройки. Это позволяет решать с помощью Asterisk любые бизнес задачи, даже те, в которых выбор в его пользу не кажется изначально очевидным.

Имеет огромный функционал.

Во многом именно Asterisk показал какой должна быть современная телефонная станция. За многие годы развития функциональность Asterisk расширилась, а все основные возможности по-прежнему доступны бесплатно сразу после установки.

Интегрируется с любыми системами.

То, что Asterisk не умеет сам, он позволяет реализовать за счет интеграции. Это могут быть интеграции с коммерческими телефонными станциями, CRM, ERP системами, биллингом, сервисами колл-трекинга, колл-бэка и модулями статистики и аналитики.

Позволяет телефонизировать офис за считанные часы.

В нашей практике были проекты, реализованные за один рабочий день. Это значит, что утром к нам обращался клиент, а уже через несколько часов он пользовался новой IP-АТС. Безусловно, такая скорость редкость, ведь АТС – инструмент зарабатывания денег для многих компаний и спешка во внедрении не уместна. Но в случае острой необходимости Asterisk готов к быстрому старту.

Отличная масштабируемость.

Очень утомительно постоянно возвращаться к одному и тому же вопросу. Такое часто бывает в случае некачественного исполнения работ или выбора заведомо неподходящего бизнес-решения. С Asterisk точно не будет такой проблемы! Телефонная станция, построенная на Asterisk может быть масштабируема до немыслимых размеров. Главное – правильно подобрать оборудование.

Повышает управляемость бизнеса.

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

Снижает расходы на связь.

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