OScam anti-cascading: защита от каскадирования

Если вы раздаёте доступ через OScam и вдруг замечаете, что нагрузка на сервер выросла втрое, а один аккаунт генерирует ECM-запросы с десяти разных IP-адресов — кто-то пробросил вашу карту дальше. OScam anti-cascading защита существует именно для этого: выявить и заблокировать перепродажу доступа, не трогая честных клиентов. В этой статье разберём конкретные параметры, реальные примеры конфигов и типичные ловушки, в которые попадают при грубой настройке.

Что такое каскадирование и почему anti-cascading нужен

Механика простая. Ваш клиент подключается по CCcam или newcamd, получает расшифрованные CW (Control Words) и сам поднимает сервер — уже для своих клиентов. Это и есть каскад: цепочка серверов, каждый из которых пробрасывает сигнал дальше. Ваш единственный "легальный" логин по факту обслуживает 20–50 конечных устройств.

Последствия очевидны: ECM-time растёт, сервер перегружен, честные клиенты страдают. А вы платите за инфраструктуру, которую используют чужие люди.

Как выглядит каскад на стороне сервера

В норме один клиент запрашивает ECM с интервалом 7–12 секунд — это цикл смены ключей канала. Каскад выглядит иначе: несколько одновременных запросов на разные SID, разрывы и переподключения, пакеты запросов почти без паузы. Webif OScam (по умолчанию порт 8888) сразу это показывает — у одного логина несколько активных сессий с разных подсетей.

Другой признак — нетипичные CAID. Если аккаунт настроен на конкретный пакет, а запросы идут на CAID, которых в его профиле нет — это тревожный сигнал. Либо каскадный сервер перебирает всё подряд, либо клиент попытался расширить доступ.

Признаки в логах OScam (множество IP на один логин)

Простая команда покажет всё:

grep "имя_логина" /var/log/oscam.log | grep "login" | awk '{print $NF}' | sort | uniq -c | sort -rn

Если один логин засветился с 5+ разных IP за последние 30 минут — уже повод разбираться. В нормальной ситуации у клиента один IP (или несколько из одной подсети при CGNAT). Разные страны под одним логином в один и тот же момент — это уже не CGNAT, это каскад.

Чем anti-cascading отличается от обычного лимита подключений

Лимит подключений (параметр uniq в oscam.user) — это мгновенная проверка: больше N сессий — запрет. Но каскадный сервер умный: он может держать одно соединение и мультиплексировать через него запросы от многих клиентов.

Секция [anticasc] в oscam.conf работает иначе — анализирует поведение во времени. Смотрит, сколько уникальных пользователей "прячется" за одним логином, опираясь на статистику ECM-запросов за промежуток времени (sampletime). Это два разных инструмента, и правильная защита — это их связка.

Базовая защита в oscam.user: ограничение подключений и фильтры

Путь к файлу зависит от сборки. На большинстве box-устройств это /var/etc/oscam.user, на тuxbox-сборках — /etc/tuxbox/config/oscam/oscam.user. На Raspberry Pi с Kodi/LibreELEC обычно /etc/oscam/oscam.user. Перед правкой сделайте резервную копию.

Параметр uniq и его режимы (0–4)

Параметр uniq в блоке [account] управляет политикой при попытке второго входа с того же или другого места:

• uniq=0 — без ограничений. Все сессии разрешены одновременно.
• uniq=1 — один логин, один IP. Второй вход с другого IP блокируется.
• uniq=2 — один логин, любой IP, но только одна сессия. Новый вход отклоняется, пока старый активен.
• uniq=3 — один логин, одна сессия. При новом входе старая сессия разрывается.
• uniq=4 — один логин, один IP, при новом входе с того же IP старая сессия разрывается.

Для борьбы с каскадом лучше всего uniq=2 или uniq=3. Режим uniq=1 даст ложные срабатывания при динамическом IP — клиент переподключится с новым адресом и получит отказ. Если ваши клиенты сидят за DHCP провайдера — выбирайте uniq=2.

cccmaxhops и cccreshare для ограничения проброса CCcam

Вот рабочий пример блока [account] с защитой от CCcam-каскада:

[account]
user = client01
pwd = password123
uniq = 2
cccmaxhops = 1
cccreshare = 0
group = 1
au = 1

cccmaxhops=1 означает, что карта уходит максимум на один хоп по CCcam-протоколу. Клиент получает — но пробросить дальше не может, потому что cccreshare=0 запрещает ему делиться картой со своими клиентами. Это прямая блокировка построения CCcam-каскада.

Но учтите: если клиент использует newcamd или mgcamd — cccmaxhops на него не действует. Для этих протоколов нужны другие меры: ограничение через uniq и [anticasc].

Ограничение CAID/ident/services через caid и ident

Каскадный сервер часто пытается расширить доступ — запрашивает CAID, которые клиенту не нужны. Жёсткая привязка режет этот вектор:

[account]
user = client01
pwd = password123
caid = 0500
ident = 0500:032830,0500:042800
uniq = 2
cccmaxhops = 1
cccreshare = 0

Теперь клиент получает ECM только по CAID 0500 с конкретными ident-ами. Запросы на другие CAID просто отклоняются — и это сразу видно в логах.

Привязка к sid через oscam.services и группы (group)

Файл /etc/oscam/oscam.services (или /var/etc/oscam.services) позволяет создать список разрешённых SID и привязать к нему группу клиентов:

[mypackage]
caid = 0500
provid = 032830
srvid = 0001,0002,0003,0055

Затем в аккаунте:

services = mypackage
group = 1

Клиент не сможет запрашивать каналы вне этого списка. Каскадный сервер, который пытается расшифровать весь мультиплекс, получит отказы по большинству SID.

Контроль ECM-интервалов и частоты запросов

Нормальный ресивер запрашивает ECM раз в 7–12 секунд — это диктует сам поставщик: ключи меняются по расписанию. Каскадный сервер, обслуживающий 30 клиентов, генерирует запросы почти непрерывно: зрители смотрят разные каналы, переключаются, и каждое переключение — новый ECM.

Это разница между 8 запросами в минуту (нормально) и 80+ запросами в минуту (каскад).

Параметр numusers и контроль одновременных сессий

В секции [anticasc] параметр numusers задаёт ожидаемое число реальных пользователей за аккаунтом. Не число подключений — число людей. Для одиночного клиента: numusers=1. Для семьи с 3 телевизорами: numusers=3. Если фактическая нагрузка превышает это значение в период sampletime — срабатывает penalty.

ECM time и выявление аномальной частоты декодирования

В webif OScam (откройте браузер на http://<server-ip>:8888) в разделе "Clients" видны активные сессии. Колонка ECMtime показывает среднее время ответа. Нормальный клиент: 50–150 мс. Аномально высокие значения — сервер перегружен. Но важнее смотреть на частоту: сколько ECM-запросов в минуту делает конкретный логин.

Через monitor-порт (по умолчанию 9999) можно получить эту статистику в реальном времени. Telnet на порт и команда level 255 откроет расширенный вывод.

Настройка ratelimitecm и srvidholdtime в oscam.conf

В секции [global] файла /etc/oscam/oscam.conf:

[global]
logfile = /var/log/oscam.log
maxlogsize = 500
httpport = 8888
monport = 9999

[anticasc]
enabled = 1
numusers = 2
sampletime = 2
samples = 10
penalty = 1
aclogfile = /var/log/oscam.ac
fakedelay = 1000

Параметр srvidholdtime в секции [global] задаёт, сколько секунд OScam "помнит" последний запрошенный SID для клиента. Значение 6 — разумный минимум. При srvidholdtime=0 каждый чих клиента считается новым запросом, что даст ложные срабатывания ratelimit.

Анализ через monitor-порт и oscam webif (статус клиентов)

Самый быстрый способ найти проблемный аккаунт — отсортировать клиентов в webif по числу запросов. Или через grep по логу:

grep "client01" /var/log/oscam.log | grep "ECM" | wc -l

Эту же команду запустите для нормального клиента и сравните за аналогичный период. Разница в 10 раз — уже подозрительно.

Глобальные настройки anti-cascading в oscam.conf

Самое важное: секция [anticasc] компилируется не во всех сборках OScam. Проверьте свою сборку командой:

oscam --version | grep -i anticasc

Если строки нет — ваш бинарник собран без поддержки этой функции. Нужна сборка oscam-emu или специальная сборка с флагом -DHAVE_ANTICASC. Пути конфигов при этом остаются теми же, но раздел [anticasc] просто игнорируется без ошибки.

Секция [anticasc] — параметры enabled, numusers, sampletime, samples

Рабочий пример с объяснением каждого параметра:

[anticasc]
enabled = 1
numusers = 2
sampletime = 2
samples = 10
penalty = 1
aclogfile = /var/log/oscam.ac
fakedelay = 1000

enabled=1 — включает модуль. Очевидно, но без этого ничего не работает.

numusers=2 — ожидаемое число реальных зрителей за аккаунтом. OScam анализирует частоту запросов и оценивает, сколько "живых" людей реально сидит за этим логином. Не путать с числом сессий — это статистическая оценка.

sampletime=2 — интервал замера в минутах. Каждые 2 минуты OScam подводит итог: сколько ECM пришло, на сколько разных SID, с каких IP.

samples=10 — сколько последних замеров учитывается. При sampletime=2 и samples=10 анализируется последние 20 минут работы. Больше samples — меньше ложных срабатываний, но медленнее реакция.

penalty и его значения (0 — лог, 1 — фейк CW, 2 — бан, 3 — задержка)

Это самое важное, и тут большинство инструкций в сети дают только таблицу без объяснений последствий.

penalty=0 — только запись в лог. Клиент работает нормально, вы просто видите нарушения. Начинайте всегда с этого режима — неделю собирайте статистику, прежде чем что-то блокировать.

penalty=1 — отправка фейковых CW. Клиент получает неверные ключи, картинка у конечных зрителей рассыпается. Мягкая мера: честный клиент ничего не заметит (у него всё нормально), каскадный сервер получит жалобы от своих клиентов. Хорошее "предупреждение".

penalty=2 — полный бан аккаунта. Используйте только при явном, подтверждённом злоупотреблении. Грубая настройка с penalty=2 при низком numusers забанит половину честных клиентов с multiroom. Я видел конфиги, где люди ставили penalty=2 сразу и потом разгребали жалобы неделю.

penalty=3 — добавление задержки (fakedelay). Ответ приходит, но с паузой. Деградирует качество работы каскадного сервера — его клиенты получают зависания при переключении каналов.

Файл oscam.ac и анализ нарушителей

Параметр aclogfile задаёт путь к отдельному логу нарушений. Это удобно: основной oscam.log не засоряется, а в oscam.ac идут только записи об аккаунтах, превысивших лимит. Формат записи включает логин, время, число "угаданных" пользователей и принятое действие.

tail -f /var/log/oscam.ac

Следите за этим файлом первые дни после включения — сразу будет видно, кто реально злоупотребляет, а кто просто попал под ложное срабатывание.

Тонкая настройка fakedelay для зашумления каскада

Значение fakedelay=1000 означает задержку 1000 мс — секунда. Для честного клиента это незаметно (он в норме ждёт CW без особой спешки). Для каскадного сервера, который должен раздать CW 30 клиентам до истечения периода — это катастрофа.

Но: fakedelay выше 2000 мс начинает мешать даже честному zapping. При переключении канала ресивер запрашивает ECM, и если ответ задержан на 2+ секунды — пользователь видит чёрный экран. Держите fakedelay в диапазоне 500–1500 мс.

Диагностика: как отличить каскад от легитимного multiroom

Это то, что конкуренты почти не разбирают — а тут и скрыт главный источник ложных срабатываний. OScam anti-cascading защита работает хорошо только если вы понимаете, что именно анализируете.

Multiroom (несколько ресиверов в одном доме) против перепродажи

Семья с тремя телевизорами за одним роутером — это multiroom. Все три ресивера выходят через один публичный IP (NAT). С точки зрения сервера: один логин, один IP, три параллельных ECM-потока. Это норма, но при numusers=1 это выглядит как каскад.

Настоящий каскад выглядит иначе: три разных IP из разных подсетей, возможно разные страны, и паттерн запросов — хаотичный, потому что 30 зрителей смотрят 30 разных каналов одновременно. Один роутер с тремя ресиверами генерирует максимум 5–6 разных SID в единицу времени. Каскадный сервер на 30 клиентов — 20–30 SID.

Анализ географии IP и одновременности запросов

Практический чеклист для диагностики подозрительного аккаунта:

• Один публичный IP → multiroom или одиночный клиент. Поднимите numusers до 3–4, не паникуйте.
• Несколько IP из одной /24-подсети → CGNAT провайдера. Тоже норма — у некоторых операторов пул маленький.
• IP из разных AS-номеров и стран одновременно → явный каскад.
• IP меняется раз в сутки, всегда одна страна → динамический DHCP, не каскад.

GeoIP-проверку IP клиентов можно сделать вручную через любой публичный API или утилиту geoiplookup. Но в реальной жизни достаточно посмотреть на паттерн: если IP меняется и остаётся в одном регионе — это не каскад.

Когда срабатывание ложное и как настроить исключения

Для клиентов с multiroom — просто поднимите numusers в их индивидуальном блоке [account]:

[account]
user = family_client
pwd = password123
uniq = 2
cccmaxhops = 1
cccreshare = 0
numusers = 4
group = 2

Параметр numusers можно переопределить на уровне аккаунта — он перекрывает глобальное значение из [anticasc]. Этим механизмом и нужно пользоваться: глобально держите строгий лимит, а для известных легитимных multiroom-клиентов делайте исключения явно.

Для клиентов с динамическим IP, которые попадают под uniq=1 — переключите их на uniq=2 или uniq=3. Ограничение по логину, а не по IP, решает проблему DHCP без ущерба для безопасности.

Отдельный кейс: клиент использует один логин попеременно — на даче и дома. Разные IP, разная география, но не одновременно. [anticasc] с нормальными sampletime/samples это не поймает — нарушение должно быть одновременным. А вот uniq=1 заблокирует второй вход, даже если первый уже завершён. Для таких клиентов правильный выбор — uniq=0 или uniq=2 с коротким session timeout.

Как выбрать надёжный источник доступа (общие критерии)

Когда вы настраиваете anti-cascading на своём сервере — вы уже на стороне провайдера. Но многие читающие это сами являются клиентами upstream-сервера, и качество этого сервера напрямую влияет на то, что вы можете предложить своим пользователям.

Признаки стабильной инфраструктуры (uptime, поддержка протоколов)

Смотрите на реальные числа, а не на обещания. Заявленный uptime выше 99.5% — хорошо. Но попросите исторические данные или поставьте мониторинг самостоятельно (Zabbix, UptimeRobot) на тестовый период. Проверьте поддержку нужных вам протоколов: CCcam, newcamd, mgcamd — не все серверы одинаково хорошо работают с каждым из них.

CAID, которые вам нужны, должны быть в явном списке. "Поддерживаем всё" без конкретики — плохой знак.

Прозрачность правил по числу подключений

Нормальный провайдер прямо прописывает: сколько одновременных подключений включено в линию, какое значение cccmaxhops настроено на их стороне, есть ли ограничения по числу уникальных IP. Если правила расплывчаты — рискуете получить блокировку без предупреждения именно тогда, когда у вас легитимный multiroom.

На что смотреть в тестовом периоде

Тестовый доступ на 24–48 часов — минимум для оценки. За это время проверьте: среднее ECM-time (должно быть стабильно ниже 200 мс), поведение при zapping (переключение канала не должно давать чёрный экран дольше 1–2 секунд), стабильность при пиковой нагрузке вечером. Если тест дали только на ночь или в будний день — попросите продлить до выходных, когда нагрузка выше.