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

В данной статье мы рассмотрим основные проблемы безопасности, существующие в протоколе 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.

Проблема: невозможность аутентификации 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.

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.

Проблема: NAT

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

Когда конечная точка 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 или других протоколов.