Stalker Middleware, которую мы установили в прошлой статье, имеет интеграцию с нашей системой защиты контента, а так же с NGINX X-accel и Secure Link.
Статья рассчитана не только для профессионалов, но и для тех, кто еще ничего не знает про IPTV/OTT.
Есть два подхода к вещанию видео контента:
- Broadcast — когда поток с данными неконтролируемо распространяется по сети. Примеры: спутниковое/кабельное вещание, multicast.
- Unicast — клиент приходит на сервер и запрашивает контент. Применяется в OTT-сервисах.
Ключевое отличие — наличие обратной связи. Существуют гибридные системы, забудем про них в рамках этой статьи.
Broadcast
Наша компания работает с вещанием видео через интернет, поэтому тут кратко, просто чтобы было понятнее, в чем разница между скрэмблированием видео на источнике и управляемоей раздачи видео.
Multicast у меня в Broadcast попал, потому что, во-первых, это форма широкого вещания, во-вторых, я говорю не только про передачу пакетов в IP-сетях, но и затрагиваю DVB.
При Broadcast вещании нет обратной связи между источником и клиентом, поэтому есть только один способ защитить контент — заскрэмблировать все на источнике. Чтобы клиент смог посмотреть защищенный контент, ему нужно узнать ключ, который периодически меняется. Ключи рассылаются клиентам вместе с контентом таким образом, что только получатель может его расшифровать. Как правило, для этого используют модули условного доступа (CAM-модули), а такая система называется — система условного доступа.
С таким способом защиты контента встречались практически все, кто пользуется услугами платного ТВ. Спутниковые вещатели уже много лет используют такой способ защиты, вынуждая периодически менять карты доступа и/или CAM-модули (или даже приемники, если CAM-модуль встроенный).
Главный недостаток таких систем в том, что ключами можно делится (Кардшаринг). Без обратной связи, нельзя проверить подлинность карты или модуля, да и узнать о существовании и количестве злоумышленников технически невозможно.
В IPTV сетях вместо CAM-модулей используется специальный софт, он общается с CAS-сервером и получает ключи. Такой подход практически исключает кражу контента, т.к. общение с CAS-сервером происходит по защищенному Unicast-соединению, а у приемника нету карты или модуля, который можно обмануть или подделать. Управляемое сетевое оборудование позволяет ограничить количество каналов, просматриваемых одновременно (как правило, операторы разрешают просмотр 2-6 каналов одновременно), поэтому весь контент проблематично, как это делают при спутниковом/кабельном вещании.
Говорить тут особо не о чем. Технология принципиально не меняется уже много лет. Старые системы взламывают, появляются новые. Недостатки есть, но в целом система работает.
Unicast
При Unicast вещании можно использовать Broadcast подход: скрэмблируем поток на источнике, а ключи раздаем через интернет. В таком случае, все то же самое, что и у IPTV, только вещаем не мультикастом, а по HTTP.
А можно по-другому ограничить доступ к контенту: использовать уникальные для каждого пользователя токены. Идея заключается в том, что Middleware отдает каждому пользователю уникальные ссылки для просмотра, а видеосервер проверяет эти токены через Middleware API.
Такая схема требует меньше серверов и софта, что дает хорошую экономию и на старте, и во время эксплуатации. Сам контент не шифруется, но получить доступ к нему не получится без разрешения от Middleware. Портал выдает одноразовые ссылки, перехват которых не имеет значения — открыть ссылку сможет только то устройство, которое запросило ссылку. А от банального перехвата трафика спасает HTTPS.
«Но ведь контент остается открытым, ничто не мешает его сохранить на диск или ретранслировать другим пользователям.» — скажете вы.
Да, конечный пользователь может сохранять сегменты к себе на диск и даже организовать трансляцию другим пользователям. Но, у одноразовых ссылок есть срок жизни. Настроить и забыть не получится. Придется регулярно получать новые ссылки от Middleware. Да и в статистике будет видно, что пользователь 24/7 смотрит один и тот же канал. Подозрительно.
Так как раздача контента по HTTP процесс контролируемый, значит мы можем отслеживать количество одновременных соединений. А это значит, что два канала уже не получится смотреть одновременно (если, конечно, не позволяет тарифный план).
Чтобы ретранслировать весь ваш контент, придется зарегистрировать количество учетных записей, равное количеству телеканалов и настроить ботов, которые будут получать актуальные временные ссылки эмулируя работу приставки. Тут придется проявить фантазию, иначе по логам можно будет легко вычислить таких пользователей. Вот представьте, из одного датацентра (/24 сети) появилось 100 пользователей, которые 24/7 смотрят одни и те же каналы. Придется такой ботнет раскидать по разным датацентрам и настроить какую-нибудь систему ротации каналов между учетными записями, чтобы не было подозрительно. Можно обсудить в комментариях, как стырить контент и остаться незамеченными.
«Но ведь телеканалы не позволяют транслировать их в кабельных/локальных/интернет сетях без шифрования сертифицированной CAS-системой.» — добавьте вы.
Не будем в рамках этот статьи разбираться с юридическими нюансами. У разных телеканалов разные требования, бывают каналы, позволяющие открытую трансляцию, кроме телеканалов наши клиенты вещают видео с камер наблюдения, которое тоже нужно защищать от чужих глаз.
Система авторизации может применяться для передачи видео между серверами, датацентрами если вы агрегатор контента, а не вещаете напрямую клиентам.
Многие клиенты приходят к нам именно ради системы авторизации.
Ладно, хватит теории, давайте займемся практикой.
Stalker имеет несколько встроенных механизмов для защиты видео. Они имеют ряд ограничений: не совместимы с некоторым протоколами (например, RTSP), не могут полноценно защищать HLS потоки и не учитывают одновременные подключения. Зато не требуют специализированного видеосервера.
Если в настройка телеканала включить временные ссылки, но не установить галочку напротив «NGINX secure link» или «Flussonic support», то Stalker будет использовать X-Accel-Redirect для доступа к контенту.
Данная конфигурация подходит для защиты HTTP MPEG-TS потоков, т.к. между сервером и клиентом устанавливается только одно TCP соединение. Посмотрим, как выглядит конфигурация NGINX:
server{
listen 0.0.0.0:8888;
rewrite ^/ch/(.*) /stalker_portal/server/api/chk_tmp_tv_link.php?key=$1 last;
location /stalker_portal {
internal;
proxy_set_header Host 192.168.1.1; # <-- имя хоста с порталом или IP
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://192.168.1.1:88/stalker_portal; # <-- IP адрес портала
}
location ~* ^/get/(.*?)/(.*) {
internal;
set $upstream_uri $2;
set $upstream_host $1;
set $upstream_url http://$upstream_host/$upstream_uri;
proxy_set_header Host $upstream_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass $upstream_url;
}
}
Stalker генерирует ссылку вида: stalker/ch/TOKEN123, где TOKEN123 — уникальный, одноразовый пароль. Когда клиент открывает эту ссылку, NGINX делает rewrite на файл chk_tmp_tv_link.php, который проверяет валидность токена и возвращает ссылку на поток с помощью заголовка X-Accel-Redirect.
Исходный код файла chk_tmp_tv_link.php:
<?php
include "./common.php";
$result = Master::checkTemporaryLink($_GET['key']);
if (!$result){
$result = '/404/';
}
header("X-Accel-Redirect: ".$result);
?>
Согласно документации, для использования временных ссылок, необходимо задавать URL канала в формате: 192.168.1.1:8888/127.0.0.1:8899/udp/239.1.1.1:1234, где 192.168.1.1:8888 — это сервер udpxy, с установленным NGINX.
Проверив токен, Stalker возвращает в переменной $result ссылку на stalker/get/127.0.0.1:8899/udp/239.1.1.1:1234.
Как мы знаем из конфигурации NGINX, /get/ — это internal location, что означает, что доступ сюда можно получить только через X-Accel-Redirect заголовок, полученный от бэкенда.
Далее, с помощью нехитрого регулярного выражения, NGINX начинает проксировать (proxy_pass) на локальную (или удаленную) udpxy.
Как видите, защита контента от несанкционированного доступа — это просто. Один rewrite, один location с параметром internal и небольшой бэкенд скрипт — все это доступно «из коробки» и отлично работает. Подробнее о работает X-Accel вы можете почитать в официальной документации NGINX.
NGINX Secure links в Stalker
Теперь поставим галочку «NGINX secure link»
Ограничения:
Stalker защищает доступ к HTTP MPEG-TS потокам и ссылки на m3u8 плейлисты. Сами же чанки и медиа плейлисты остаются незащищенными и с помощью tcpdump/wireshark можно легко узнать адреса медиа плейлистов и подключаться к ним напрямую.
Самый простой и, главное, более надежный способ защитить потоки — включить интеграцию с Flussonic. Настройка со стороны Сталкера не требуется, стоит лишь поставить галочку «Flussonic» в настройках канала, а со стороны Flussonic требуется лишь указать адрес Сталкера.
Flussonic — это видеосервер нашей разработки, широко применяющийся во многих OTT и IPTV сервисах. Наши сильные стороны — это управление доступом и учет сессий, запись архива. Подробнее у нас на сайте.
У нас реализован механизм идентификации пользователей и отслеживания подключений с помощью авторизационных бэкендов. По протоколам HLS и HDS используются HTTP механизмы отслеживания сессий, а по протоколам RTMP, RTSP и MPEG-TS обрабатываются постоянные TCP сессии. Также отслеживается экспорт архива в формате MPEG-TS и MP4.
Stalker — это и есть авторизационный бэкенд. Когда клиент приходит за видео, мы передаем бэкенду не только IP-адрес и имя канала, но и другую важную информацию:
— Token
— HTTP Referer
— Количество открытых сессий на этом потоке
— Общее количество открытых сессий на сервере
— Запрашиваемый протокол: (hls, dash, hds, rtmp, rtsp, mpegts или mp4)
— Тип подключения (новое соединение или продлевается текущее)
— Тип запрашиваемого контента (живой поток, архив, скриншоты или обращение к API)
— User-Agent
— query string
— Адрес и порт сервера, куда пришел запрос
Эта информация позволяет бэкенду гибко контролировать доступ. Можно использовать все данные, чтобы строить сложные правила.
В ответ, Сталкер возвращает не просто да/нет, но и информацию о сроке действия разрешения (или запрета), id пользователя и количество одновременных соединений для этого пользователя.
Flussonic сохраняет ответ и на время действия разрешения не посылает повторных запросов в бэкенд. Так как статья получается итак затянутой, я не буду показывать как настроить авторизацию во Flussonic через Stalker, это очень просто и у нас есть краткая, но исчерпывающая документация по этому вопросу.
Подводим итоги.
В большинстве случаев для защиты контента от несанционнированого просмотра в интернете можно обойтись без шифрования, делается это легко бесплатными средствами популярной Middleware, а можно и настроить интеграцию с видеосервером, убрав со Stalker лишнюю роль и нагрузку.
Расскажите в комментариях, какими средствами защиты контента вы пользуетесь? Интересно не только про ТВ-вещание, но и VOD-сервисы, видеонаблюдение.
Судя по количеству просмотров первой статьи цикла «Строим OTT/IPTV сервис», еще не все построили свои решения и мне не стоит затягивать со следующими статьями.
Дальше надо бы поговорить про вставку видео на сайт, этот вопрос не такой простой, как может показаться. Прочитайте нашу статью "Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)", она рассказывает о современных средствах передачи и просмотра потокового видео в браузере. А еще мы запустили бесплатный сервис сбора статистики для всех наших клиентов.
Комментарии (13)
Ivan_83
01.07.2017 04:50+1udpxy в 2017 году да ещё и в чём то типа хайлоада это позор.
Оно было написано для личного использования и практически не масштабируется: каждый клиент это отдельный процесс который создаёт сокет для приёма мультикаста и сокет куда подключён клиент, и дальше перекладывает байтики из одного сокета в другой.
Если 100500 клиентов смотрят один канал значит ядро ОС 100500 раз дублирует мультикаст пакет по сокетам и 100500 раз делает переключение контекста, 100500 процессов копируют себе данные из мультикаст сокета чтобы тут же из скопировать в клиентский сокет и прочие более мелкие радости в таких же количествах.
Лучше поставить msd_lite, оно умеет жрать все те же ссылки, и не форкается на каждый клиентский коннект.
Потоков = сколько конфиге указано, если придёт 100500 клиентов на один тв канал то будет создан 1 сокет для приёма мультикаста, один кольцевой буфер для временного хранения и 100500 клиентских сокетов + несколько кб дополнительно к каждому клиенту для служебки, и будет их обслуживать один поток. Те каждый доп клиент на канал практически ничего не стоит, в отличии от udpxy.erlyvideo
01.07.2017 15:28во-первых, кто сказал хайлоад?
во-вторых, чего тут спорить: есть сложившаяся практика. Люди до сих пор ставят первый апач, а нам приходится поддерживать для госзаказчика сборку флюссоника под Suse 10 года выпуска. Есть такая практика и мы её описали.Ivan_83
03.07.2017 03:021. Тут когда то писали что хайлоад для udpxy начинается с 50 клиентов :)
И делать ОТТ ради двух колек малость перебор, в нормальных условиях.
2. Люди часто ставят то о чём написано в инструкции не вникая в тему.
2 ValdikSS
Кажется матроска сплиттер под венду понимает разные видеодороги, и вроде mpv тоже, но переключение хоткеями, насколько помню.
И это не грязный хак, это вполне себе документированная возможность, кажется в оригинале было про переключение ракурсов для удобства зрителя.
Lemko
01.07.2017 11:27Как на счет pre-roll, можно реализовать на стороне сервера?
erlyvideo
01.07.2017 14:04мы пока ещё не сделали: очень сложно оказалось реализовать для ситуации, когда плавающий fps, плавающая длина сегмента, скачущие настройки видео.
ValdikSS
03.07.2017 00:52Для MPEG-TS есть грязный хак: вещать разные видео в разных видеопотоках. Поддерживается муксером и демуксером VLC, как минимум. Я так вещаю совершенно разные файлы в разных кодеках, без перекодирования.
erlyvideo
03.07.2017 11:12вы имеете ввиду mpts или в другом пиде видео пустить?
ValdikSS
03.07.2017 11:47В разных PID, да.
Ivan_83, хак заключается в том, что большинство плееров не переключают видеодорожки сами, по окончании одной, а VLC переключает, не требуя действий от пользователя. Думаю, для веба можно сделать автоматизацию переключения скриптом.
А VP9 в WebM вообще позволяет смешивать стримы с разными параметрами фреймрейта и разрешения, и плееры меняют их на лету: https://files.catbox.moe/w0xth1.webm
erlyvideo
Максим, сталкер будет авторизовать доступ к лайву, файлам и архиву?
klu4ik
Да, коллеги из Информира говорят что будет.