Строим IPTV/OTT сервис: защита контента

    В этой статье я хочу рассказать, как защищают видео контент, какие технологии для этого применяют. Речь пойдет в основном про интернет вещание, но придется затронуть и про DVB, и про Multicast, чтобы было понятнее, в чем разница.

    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.

    image

    А можно по-другому ограничить доступ к контенту: использовать уникальные для каждого пользователя токены. Идея заключается в том, что Middleware отдает каждому пользователю уникальные ссылки для просмотра, а видеосервер проверяет эти токены через Middleware API.

    image

    Такая схема требует меньше серверов и софта, что дает хорошую экономию и на старте, и во время эксплуатации. Сам контент не шифруется, но получить доступ к нему не получится без разрешения от Middleware. Портал выдает одноразовые ссылки, перехват которых не имеет значения — открыть ссылку сможет только то устройство, которое запросило ссылку. А от банального перехвата трафика спасает HTTPS.

    «Но ведь контент остается открытым, ничто не мешает его сохранить на диск или ретранслировать другим пользователям.» — скажете вы.

    Да, конечный пользователь может сохранять сегменты к себе на диск и даже организовать трансляцию другим пользователям. Но, у одноразовых ссылок есть срок жизни. Настроить и забыть не получится. Придется регулярно получать новые ссылки от Middleware. Да и в статистике будет видно, что пользователь 24/7 смотрит один и тот же канал. Подозрительно.

    Так как раздача контента по HTTP процесс контролируемый, значит мы можем отслеживать количество одновременных соединений. А это значит, что два канала уже не получится смотреть одновременно (если, конечно, не позволяет тарифный план).

    Чтобы ретранслировать весь ваш контент, придется зарегистрировать количество учетных записей, равное количеству телеканалов и настроить ботов, которые будут получать актуальные временные ссылки эмулируя работу приставки. Тут придется проявить фантазию, иначе по логам можно будет легко вычислить таких пользователей. Вот представьте, из одного датацентра (/24 сети) появилось 100 пользователей, которые 24/7 смотрят одни и те же каналы. Придется такой ботнет раскидать по разным датацентрам и настроить какую-нибудь систему ротации каналов между учетными записями, чтобы не было подозрительно. Можно обсудить в комментариях, как стырить контент и остаться незамеченными.

    «Но ведь телеканалы не позволяют транслировать их в кабельных/локальных/интернет сетях без шифрования сертифицированной CAS-системой.» — добавьте вы.

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

    Система авторизации может применяться для передачи видео между серверами, датацентрами если вы агрегатор контента, а не вещаете напрямую клиентам.

    Многие клиенты приходят к нам именно ради системы авторизации.

    Ладно, хватит теории, давайте займемся практикой.


    Stalker имеет несколько встроенных механизмов для защиты видео. Они имеют ряд ограничений: не совместимы с некоторым протоколами (например, RTSP), не могут полноценно защищать HLS потоки и не учитывают одновременные подключения. Зато не требуют специализированного видеосервера.

    Если в настройка телеканала включить временные ссылки, но не установить галочку напротив «NGINX secure link» или «Flussonic support», то Stalker будет использовать X-Accel-Redirect для доступа к контенту.

    image

    Данная конфигурация подходит для защиты 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»

    image

    Ограничения:

    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-стриминга не существует)", она рассказывает о современных средствах передачи и просмотра потокового видео в браузере. А еще мы запустили бесплатный сервис сбора статистики для всех наших клиентов.
    Эрливидео
    38.52
    Современный видеостриминговый сервер
    Share post

    Comments 13

      0
      Максим, сталкер будет авторизовать доступ к лайву, файлам и архиву?
        0
        Да, коллеги из Информира говорят что будет.
      • UFO just landed and posted this here
          0
          во-первых, кто сказал хайлоад?

          во-вторых, чего тут спорить: есть сложившаяся практика. Люди до сих пор ставят первый апач, а нам приходится поддерживать для госзаказчика сборку флюссоника под Suse 10 года выпуска. Есть такая практика и мы её описали.
          • UFO just landed and posted this here
          0
          Как на счет pre-roll, можно реализовать на стороне сервера?
            0
            мы пока ещё не сделали: очень сложно оказалось реализовать для ситуации, когда плавающий fps, плавающая длина сегмента, скачущие настройки видео.

              0
              Спасибо за ответ.
              Когда надеяться, очень нужен такой функционал.
                0
                Для MPEG-TS есть грязный хак: вещать разные видео в разных видеопотоках. Поддерживается муксером и демуксером VLC, как минимум. Я так вещаю совершенно разные файлы в разных кодеках, без перекодирования.
                  0
                  вы имеете ввиду mpts или в другом пиде видео пустить?
                    0
                    В разных PID, да.
                    Ivan_83, хак заключается в том, что большинство плееров не переключают видеодорожки сами, по окончании одной, а VLC переключает, не требуя действий от пользователя. Думаю, для веба можно сделать автоматизацию переключения скриптом.

                    А VP9 в WebM вообще позволяет смешивать стримы с разными параметрами фреймрейта и разрешения, и плееры меняют их на лету: https://files.catbox.moe/w0xth1.webm
              0
              OTT без кпипта? Такого не бывает априори.
                +1
                постоянно, направо и налево.

              Only users with full accounts can post comments. Log in, please.