Короткий ответ — да и нет. Технически механика WebRTC/TURN позволяет через браузер ретранслировать произвольные UDP/TCP-пакеты, и если TURN-сервер даёт чужим клиентам открытый или долго живущий доступ — его можно превратить в «общедоступный релей» и туннелировать через него любой трафик. Но это не «уязвимость WebRTC» в смысле баг в браузере — это особенность архитектуры TURN и неверная конфигурация/политика сервера и сигналинга. При правильной настройке систему можно защитить.
Ниже — что именно происходит и какие практические шаги предпринять.
Почему это возможно
- TURN (RFC 5766) предназначен именно для релеинга трафика между пирами, когда прямой P2P канал невозможен. Сервер выделяет «allocation» и потом пропускает пакеты между клиентом и указанными удалёнными адресами. Это позволяет ретранслировать не только RTP, но и произвольные UDP/TCP потоки, если клиент реализует соответствующее поведение.
- Браузерный WebRTC умеет передавать произвольные данные (DataChannel — SCTP/DTLS/UDP) и/или медиа-потоки, и клиентская реализация может «упаковать» туда произвольный UDP-трафик и посылать через TURN.
- Если TURN-сервер принимает подключения без надёжной авторизации (публичные сервера, встраивание долгоживущих creds в ссылку), то злоумышленник, получив ссылку/ключ/учётные данные, может использовать его как прокси.
Когда риск высокий
- Вы используете/публикуете публичный TURN (или coturn с статическими/долгоживущими учетными данными), и эти креды могут стать известны посторонним (в ссылке на комнату, логах, общедоступных конфигурациях).
- Система выдаёт TURN-учётные данные до подтверждения участника (например, прямо в URL приглашения), или токены имеют большой TTL.
- TURN не ограничивает количество/байттрафик/количество соединений на учётную запись.
Когда риск низкий / отсутствует
- TURN выдаёт эпемерные учетные данные (short-lived tokens), только после аутентификации пользователя и сигналингом, и их TTL — считанные секунды/минуты.
- TURN защищён и доступен только доверенным клиентам/домейнам (например, через аутентификацию по JWT, привязку к приложению).
- Вы вообще не используете публичный TURN: участники используют свои NAT или корпоративные прокси.
Практические меры защиты (что сделать сейчас)
1. Никогда не публикуйте статические TURN-логины в публичных ссылках.
2. Выдавайте TURN-учётные данные только после аутентификации участника (через сигналинг). Не принимайте анонимные запросы к TURN.
3. Используйте временные (short-lived) credentials. Coturn поддерживает режим "REST API / use-auth-secret": генерируйте username, содержащий expiry, и HMAC-сигнатуру. Сделайте TTL небольшим (несколько секунд/минут), чтобы не дать возможности повторно использовать креды.
4. Ограничьте время жизни allocation на TURN, и уменьшите пределы по трафику/количеству сессий на один пользователь/ключ.
5. Включите учёт, мониторинг и квоты: логируйте allocation/байтапп/коннекты, ставьте алерты на аномально большой объём или количество соединений.
6. Ограничьте общую пропускную способность (rate limiting) и число одновременных relay-сессий для одного аккаунта/адреса.
7. (Если применимо) ограничиьте список допустимых удалённых IP/портов, на которые сервер разрешает create-permission / канал биндинг — это уже нестандартная, но возможная серверная политика при интеграции с сигналингом: сигналинг заранее сообщает TURN «разрешённые пира-адреса» и сервер отвергает create-permission для других адресов.
8. Не используйте публичные/чужие TURN-сервера, в которых вы не контролируете политику и логи.
9. Если вы не хотите вообще релеить произвольный трафик, в coturn есть параметры, запрещающие TCP/UDP relay или ограничивающие порты (но это может сломать законную работу медиапотоков).
10. Принудительная аутентификация в конференции: требуйте вход/регистрацию перед выдачей кредов/ICE-candidates, используйте одноразовые join-токены и короткие TTL.
Специфика для популярных стеков
- Jitsi/Matrix/Asterisk: по умолчанию многие примеры используют coturn и могут быть настроены небезопасно (статический секрет, долгий TTL, выдача creds в URL). Настройте coturn с use-auth-secret и генерируйте креды динамически в момент входа. Для Jitsi Meet есть интеграция, позволяющая выдавать временные creds через Jicofo/Prosody/Jitsi/turncredentials — настройте это.
- Asterisk как SIP-сервер: если вы используете WebRTC-участников, та же рекомендация — динамические короткоживущие credentials для TURN; для SIP без WebRTC TURN обычно не нужен, но если он используется — примените те же правила.
Можно ли «исправить» протоколную возможность полностью?
- Протокол TURN изначально предоставляет функциональность реле — убрать это невозможно, не ломая NAT traversal для многих легитимных сценариев.
- Можно развивать стандарты и практики (например, более строгие token binding, привязка токена к конкретным ожидаемым peer-IP/port), но это требует изменений у многих реализаций и сигналинг-протоколов. На практике защититься нужно на уровне развертывания/конфигурации.
Рекомендации для администратора сервера (шаги)
1. Блокируйте публичный доступ к TURN или требуйте аутентификацию.
2. Включите use-auth-secret в coturn и генерируйте короткоживущие креды (пример TTL = 300s или меньше).
3. Не включайте TURN-креды в публичные приглашения; формируйте их на бекенде при запросе участника.
4. Ограничьте bandwidth/сессии/пайринг для каждого allocation.
5. Мониторьте и реагируйте на аномалии.
6. При наличии угроз — выключите публичный TURN или переведите на платный сервис с гарантированными политиками.
Если хотите — могу:
- посмотреть вашу текущую конфигурацию coturn / Jitsi / Asterisk и подсказать конкретные строки конфигурации;
- подготовить скрипт для генерации короткоживущих TURN-токенов (JWT/HMAC) для вашего сигналинга;
- помочь с настройкой мониторинга/оповещений по аномальной нагрузке на TURN.
Вывод: да — при небезопасной конфигурации любой TURN-сервер можно использовать как общедоступный релей для произвольного трафика; нет — при правильной политике выдачи краткоживущих удостоверений, аутентификации и лимитировании риска практически не будет.