NCam anti-cascading: настройка защиты от каскадов
Если ваш сервер раздаёт линии и вы замечаете, что одни и те же аккаунты генерируют подозрительно много ECM-запросов — добро пожаловать в проблему каскадирования. NCam anti-cascading: настройка этого механизма — не самая очевидная задача, потому что почти все гайды в сети просто перечисляют ключи без объяснения порядка действий. Разберём всё по-человечески: от понимания механизма до финальной подстройки под реальных клиентов.
Что такое каскадирование и зачем NCam anti-cascading
Базовая идея каскада проста: вы выдали одному клиенту аккаунт, а он использует его не для своего ресивера, а как источник для своего мини-сервера CCcam/OScam — и раздаёт дальше. Один аккаунт, который должен обслуживать один-два ресивера, внезапно обслуживает десятки.
Механизм каскада: как одна линия превращается в раздачу
Технически это выглядит так: клиент подключает ваш аккаунт как peer в свой CCcam или как reader в свой OScam/NCam. К нему в свою очередь подключаются его клиенты. Все их ECM-запросы проксируются через ваш аккаунт наверх — к вашему серверу и дальше к источнику карты.
В результате вы несёте нагрузку за десятки пользователей, получая оплату за одного. Источник карты видит с вашей стороны аномально высокую частоту ECM и может ограничить или заблокировать вашу линию.
Признаки каскадирования в логах NCam
Смотреть надо на несколько вещей одновременно. В основном логе NCam (/var/log/ncam/ncam.log или через WebIF) ищите:
- Один user генерирует ECM-запросы с частотой выше 1 в секунду стабильно
- ECM приходят с равномерным интервалом — признак того, что это машина, а не человек, переключающий каналы
- В строках лога num_clients для конкретного account резко вырастает в вечерние часы
- Запросы идут одновременно на несколько разных SID от одного user в течение секунды
Это не стопроцентный диагноз, но достаточный повод начать собирать статистику через anti-cascading.
Чем anti-cascading отличается от обычных лимитов (cccmaxhops, maxconnections)
Три механизма решают разные задачи, и их часто путают. Это критично, потому что если крутить не тот параметр — ничего не изменится.
maxconnections в ncam.user — просто лимит одновременных TCP-соединений от одного account. Каскадёр может держать одно соединение и через него гнать сотни ECM. Это не поможет.
cccmaxhops — параметр протокола CCcam, ограничивает глубину дерева раздачи. Работает только для CCcam-пиров, не для newcamd или CS378x. И опять же, один hop вполне может быть каскадом.
Anti-cascading работает по времени: он считает, сколько уникальных потребителей используют один account в течение окна sampletime. Если больше numusers — применяется penalty. Это единственный механизм, который реально ловит скрытую субраздачу.
Параметры anti-cascading в ncam.server и ncam.user
NCam унаследовал конфигурацию от OScam, поэтому пути и структура файлов аналогичны. На обычном Linux-сервере конфиги лежат в /etc/ncam/. На ресиверах под Enigma2 — чаще всего /var/etc/ncam/. Не путайте: файл называется ncam.conf, ncam.user, ncam.server — не oscam.*.
Глобальный блок [anticasc] в ncam.conf
Блок прописывается в основном конфиге ncam.conf. Пример рабочей конфигурации:
[anticasc]
enabled = 1
numusers = 1
sampletime = 5
samples = 2
penalty = 0
aclogfile = /var/log/ncam/anticasc.log
Это стартовая конфигурация для сбора статистики — penalty=0 означает только логирование без каких-либо блокировок.
Ключи: enabled, numusers, sampletime, samples, penalty, aclogfile
enabled = 1 — включает механизм. Без этого всё остальное игнорируется.
numusers — максимальное число уникальных потребителей на один account в течение окна sampletime. Для одного ресивера ставьте 1, для клиентов с двумя телевизорами — 2. Глобальное значение — это дефолт; на уровне пользователя можно переопределить.
sampletime — длина окна в минутах. За это время NCam накапливает статистику ECM. Слишком короткое (1-2 минуты) — поймаете легитимный зэппинг. Оптимум для большинства случаев — 5-8 минут.
samples — сколько окон подряд должно быть превышение, прежде чем сработает penalty. Значение 2 означает: превышение в двух последовательных окнах. Это защита от случайных всплесков.
penalty — реакция на превышение. Подробнее ниже.
aclogfile — отдельный лог для событий anti-cascading. Очень рекомендую указывать — в основном логе события теряются среди прочего шума.
Привязка к пользователю: numusers и penalty в ncam.user
Глобальные настройки — это одно. Но у вас наверняка есть клиенты с разными профилями: кто-то с одним ресивером, кто-то с тремя телевизорами в доме. Для них нужно переопределять параметры в ncam.user.
[account]
user = client_vasya
pwd = secret123
numusers = 3
penalty = 0
Параметры numusers и penalty в блоке [account] перекрывают глобальные значения именно для этого пользователя. Клиент с тремя ресиверами получает numusers=3 и не попадает под глобальный лимит.
Режимы penalty: 0 (только лог), 1 (fake CW), 2 (бан), 3 (delay)
penalty=0 — тихий режим. Нарушение фиксируется в aclogfile, клиент ничего не замечает. Используйте для сбора статистики.
penalty=1 — fake CW. NCam начинает отправлять заведомо неверные Control Words. Ресивер декодирует мусор — картинка рассыпается. Клиент замечает проблему, но не получает явного отказа. Это мягкий, но действенный вариант.
penalty=2 — полный бан account. Жёстко. Применяйте только к подтверждённым каскадёрам после анализа логов.
penalty=3 — задержка ответа. NCam искусственно увеличивает время отклика на ECM. Картинка подмерзает. Менее очевидно для клиента, чем fake CW.
Пошаговая настройка и подбор значений
Вот где большинство гайдов облажались: они дают список параметров, но не объясняют порядок действий. NCam anti-cascading: настройка требует итеративного подхода — сначала наблюдаем, потом действуем.
Шаг 1: запуск в режиме penalty=0 для сбора статистики
Включите блок [anticasc] с numusers=1, sampletime=5, samples=2, penalty=0. Перезапустите демон:
/etc/init.d/ncam restart
Или мягкий reload без обрыва соединений:
kill -HUP $(cat /var/run/ncam.pid)
Оставьте работать минимум 24-48 часов. Вечерние часы — самое важное время, именно тогда нагрузка максимальна и паттерны каскадирования проявляются чётче всего.
Шаг 2: анализ anticasc.log и определение нормы по каждому user
Смотрите в /var/log/ncam/anticasc.log. Типичная запись выглядит примерно так:
2026/06/15 21:34:12 client_petrov: numusers exceeded (current: 3, max: 1)
Для каждого пользователя отметьте, какой максимум уникальных потребителей фиксировался. Если client_petrov регулярно показывает 2-3 — возможно, у него просто три телевизора. Если значение прыгает до 10-15 в вечерние часы — это каскад.
Шаг 3: установка numusers с запасом под легитимные ресиверы
После анализа логов выставьте глобальный numusers чуть выше среднего легитимного потребления. Правило: реальное число ресиверов + 1. Для клиентов с нестандартным числом устройств — per-user переопределение в ncam.user.
Не пытайтесь сразу поставить numusers=1 для всех. Это убьёт часть честных клиентов в первый же день.
Шаг 4: выбор penalty и перезапуск без потери линий
После базовой калибровки переходите на penalty=1 (fake CW). Это разумный компромисс: каскадёры получают нерабочий сигнал, легитимные клиенты не затронуты. При необходимости ужесточайте до penalty=2 для конкретных аккаунтов через ncam.user.
Перезагружайте через kill -HUP — это позволяет обновить конфиг без обрыва активных соединений.
Шаг 5: проверка через ncam WebIF (раздел Anti-Cascading)
WebIF NCam (по умолчанию порт 8181) содержит раздел Anti-Cascading в меню мониторинга. Там видны текущие счётчики по каждому аккаунту, количество срабатываний и активные penalty. Смотрите туда каждый день первые две недели — это покажет, правильно ли подобраны параметры.
Диагностика ложных срабатываний и тонкая настройка
Это то, о чём молчат почти все инструкции. После включения penalty вы неизбежно получите жалобы от честных клиентов. Не паникуйте — это нормально на этапе калибровки.
Почему легитимные клиенты попадают под penalty
Самая частая причина — неправильно выбранный sampletime. Если окно слишком короткое, любой всплеск активности засчитывается как нарушение. При этом клиент с одним ресивером, который активно смотрит телевизор, легко генерирует 5-10 ECM за минуту на разные каналы.
Вторая причина — неточный numusers. Клиент честно говорил вам, что у него «один телевизор», но на деле ещё есть планшет с приложением и второй ресивер в спальне.
Влияние zapping (быстрого переключения каналов) на samples
Зэппинг — главный источник ложных срабатываний. Когда пользователь быстро листает каналы, ресивер отправляет ECM на каждый новый SID. За 30 секунд активного зэппинга можно получить запросы к 8-10 разным сервисам.
Anti-cascading видит это как несколько потребителей, запрашивающих разные SID почти одновременно. Внешне — вылитый каскад. По факту — один человек выбирает, что посмотреть.
Решение: увеличьте sampletime до 6-8 минут. За такое окно зэппинг размывается и перестаёт выглядеть как аномалия. Одновременно поднимите samples до 3 — три последовательных окна с превышением вместо двух.
Подстройка sampletime под поведение реальных ресиверов
Нет универсальных цифр. Всё зависит от аудитории. Если ваши клиенты — спортивные фанаты, они во время матча часами смотрят один канал. Если это люди, которые постоянно переключаются между новостями и развлекательным — нужен более длинный sampletime.
Мой рабочий диапазон: sampletime=6, samples=3. Это убирает большинство ложных срабатываний без потери чувствительности к реальным каскадам.
Связь с ECM timeout и кэшем (cache-ex)
Ещё два момента, которые ломают статистику. Первый: высокий ECM timeout. Если источник карты отвечает медленно (>800 мс), ресивер может отправить повторный запрос до получения ответа на первый. NCam регистрирует это как два отдельных ECM. При коротком sampletime это накапливается в счётчике и может дать ложное превышение.
Второй: cache-ex и CSP пиры. Если у вас настроен обмен кэшем с другими серверами, эти пиры генерируют ECM-запросы, которые попадают в счётчик anti-cascading наравне с пользователями. Результат — статистика искажена, penalty может сработать на аккаунте, который на самом деле не нарушает ничего.
Правильное решение: держите cache-ex/CSP пиры в отдельной группе аккаунтов и ставьте им penalty=0 в ncam.user. Они не должны участвовать в логике anti-cascading.
Как выбрать стабильную линию-источник, чтобы anti-cascading имел смысл
Настраивать anti-cascading на вашем сервере имеет смысл только если сама входящая линия стабильна. Если источник нестабилен — вы будете бороться с симптомами, а не с причиной.
Признаки качественного источника карты (без перепродажи на вашей стороне)
Хорошая линия — это прежде всего предсказуемый ECM time. Смотрите на показания в WebIF NCam в разделе Readers: нормальный показатель для большинства европейских спутниковых пакетов — 200-400 мс на канал. Если ECM time скачет от 100 мс до 2000 мс — источник либо сам каскадный, либо перегружен.
Обратите внимание на поведение в вечерний прайм-тайм (20:00-23:00). Именно тогда видна реальная стабильность источника. Если днём всё отлично, а вечером начинаются FREEZE и timeout — источник сам находится под нагрузкой.
Критерии оценки: стабильность ECM time, аптайм, отсутствие фрилоадеров
Что конкретно проверять перед тем, как строить на линии свою раздачу:
- ECM time стабильно в диапазоне 200-500 мс, без всплесков выше 1000 мс
- Нет периодических полных отвалов соединения (disconnect в логе NCam)
- Источник явно ограничивает число подключений — это признак того, что он сам не раздаёт бесконтрольно
- Нет регулярных «серых» часов без сигнала, особенно ночью или по выходным
- При запросе двух-трёх одновременных ECM нет деградации времени ответа
Чек-лист проверки перед тем, как раздавать линию дальше
Перед тем как открывать аккаунты для своих клиентов:
- Поработайте с линией в одиночку минимум 48 часов, записывая ECM time в лог
- Проверьте стабильность в разное время суток — утро, день, вечерний прайм
- Убедитесь, что в ncam.server для этого reader прописаны корректные параметры caid и services — это снизит число лишних ECM-запросов
- Включите anti-cascading в режиме penalty=0 до подключения первых клиентов — так у вас будет чистая базовая статистика без посторонних данных
- Проверьте системное время сервера: ntpdate -q pool.ntp.org. Некорректное время сломает окна sampletime и сделает статистику anti-cascading бессмысленной
И ещё один момент, который обычно упускают: при перезапуске демона NCam счётчики anti-cascading сбрасываются. Если каскадёр знает об этом, он может эксплуатировать линию в промежутках между рестартами. Поэтому не перезапускайте демон слишком часто и следите за aclogfile регулярно — медленный каскад, который работает между рестартами, иначе не поймать.
В каком файле NCam находятся настройки anti-cascading?
Глобальный блок [anticasc] прописывается в ncam.conf — это прямой наследник oscam.conf, структура идентична. Per-user параметры numusers и penalty задаются в ncam.user в блоке [account] конкретного пользователя. Типичный путь на Linux-сервере: /etc/ncam/. На ресиверах Enigma2 чаще встречается /var/etc/ncam/.
Чем numusers отличается от maxconnections и cccmaxhops?
Это три абсолютно разных механизма. numusers — лимит уникальных потребителей в окне sampletime, то есть логика по времени и поведению. maxconnections — просто лимит TCP-соединений к вашему серверу от одного account, каскадёр легко укладывается в него с одним соединением. cccmaxhops — параметр протокола CCcam, ограничивает глубину дерева, но работает только для CCcam и не защищает от newcamd/CS378x каскадов. Крутить их вместо [anticasc] — пустая трата времени.
Какой penalty выбрать, чтобы не потерять клиентов?
Начинайте всегда с penalty=0 — только логирование, никакого воздействия. Соберите статистику за 1-2 суток, откалибруйте numusers. Потом переходите на penalty=1 (fake CW): клиент получает рассыпанную картинку, но соединение не рвётся и бан не применяется. penalty=2 (полный бан account) применяйте только к подтверждённым нарушителям после анализа логов. penalty=3 (задержка) — промежуточный вариант, менее заметный для клиента.
Почему честный подписчик с двумя ресиверами попадает под блокировку?
Почти всегда — глобальный numusers выставлен меньше реального числа его устройств. Решение: в ncam.user в блоке [account] этого клиента добавьте numusers=2 (или сколько у него реально ресиверов). Заодно увеличьте sampletime до 6-8 минут — быстрый зэппинг при коротком окне тоже может вызывать ложные срабатывания даже при правильном numusers.
Влияет ли быстрое переключение каналов (zapping) на anti-cascading?
Да, и это одна из главных причин ложных срабатываний. При быстром листании каналов ресивер отправляет ECM на каждый новый SID, и за 30-60 секунд счётчик уникальных потребителей в коротком окне может выглядеть как каскад. Решение — увеличить sampletime до 4-8 минут и поднять samples до 3, чтобы усреднение сглаживало такие всплески.
Нужно ли исключать cache-ex пиры из anti-cascading?
Однозначно да. Cache-ex и CSP пиры генерируют ECM-запросы, которые NCam считает наравне с обычными пользователями. Это искажает счётчик и может привести к срабатыванию penalty на аккаунтах, которые не нарушают ничего. Держите cache-ex пиры в отдельной группе аккаунтов и ставьте им penalty=0 в ncam.user — они не должны участвовать в логике anti-cascading.
Где посмотреть результаты работы anti-cascading?
В двух местах. Первое — отдельный журнал, путь к которому вы задали в aclogfile (рекомендую /var/log/ncam/anticasc.log). Второе — WebIF NCam, раздел Anti-Cascading в меню мониторинга (по умолчанию сервер доступен на порту 8181). Там в реальном времени видны счётчики по каждому аккаунту, количество превышений и активные penalty.