Настройка anti-cascading в GBox: гайд 2026

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

В этом гайде разбираю конкретные пути к файлам, реальные директивы, последовательность команд перезапуска и то, как читать лог при срабатывании защиты. Без теоретических отступлений — только то, что реально работает.

Что такое cascading и зачем нужен anti-cascading в GBox

Каскадирование — это когда ваш доверенный пир не просто смотрит расшаренную карту, а сам становится сервером для своих клиентов. С точки зрения протокола это выглядит так: ECM-запрос приходит к вам с hop count = 1 (прямой пир), но количество запросов и их распределение по каналам выдают, что реально за этим пиром сидят ещё 5–10 клиентов.

Как возникает каскад: пир раздаёт вашу карту дальше

GBox — протокол на UDP (по умолчанию порт 8888, задаётся в строке запуска или конфиге плагина). Он передаёт CW (control words) между узлами с собственным счётчиком хопов в заголовке пакета. Пир получает CW от вас, и если у него нет ограничений на reshare, он транслирует его дальше по своей сети. Формально hop count увеличивается, но если пир его подделывает или у вас нет проверки — вы этого не видите.

Самый распространённый сценарий: вы дали доступ "другу", а он продал 20 субаккаунтов и его сервер генерирует 200 ECM/мин на вашу карту вместо обычных 5–10.

Чем cascading опасен: бан карты у оператора и перегрузка

Операторы мониторят аномальные паттерны дешифрования. Если с одной карты идут одновременные запросы по нескольким мультиплексам — алгоритм обнаружения спарринга срабатывает и карта улетает в бан. Это реально происходит, и восстановление занимает от нескольких дней до полной блокировки карты.

Кроме того, перегруженный аплинк начинает отвечать нестабильно. ECM-time растёт, пиры получают зависания картинки, и виноватым оказываетесь вы, хотя проблема в каскаде ниже.

Принцип работы anti-cascading: лимиты ECM и времени отклика

GBox anti-cascading работает через три механизма одновременно: ограничение числа хопов (hop limit), лимит одновременных соединений на share/account и контроль частоты ECM-запросов. Ни один из них сам по себе не защищает полностью — только комбинация.

Hop limit отсекает пиров, у которых в заголовке пакета hop count уже превышает разрешённое значение. Лимит соединений режет тех, кто пытается завести слишком много параллельных сессий. ECM-rate контроль ловит случаи, когда формально всё выглядит чисто, но запросов приходит слишком много за единицу времени.

Ключевые параметры anti-cascading в конфиге GBox

Здесь главное — понять, что gbox anti-cascading: настройка в разных прошивках и конфигурациях выглядит немного по-разному, но логика везде одна. Разберём конкретные файлы и строки.

Лимиты в CCcam.cfg: G: строка и параметры GBox

Основной конфиг CCcam на Dreambox лежит в /var/etc/CCcam.cfg. На TuxBox-прошивках — /etc/tuxbox/config/CCcam.cfg. GBox-пиры добавляются через G:-строки:

G: hostname.peer.net 8888 mypassword 2 1

Формат: G: хост порт пароль downhops uphops. Параметр downhops — сколько хопов вниз вы разрешаете пиру раздавать. Ставить 0 означает запрет дальнейшей раздачи. Uphops — сколько хопов вверх вы принимаете от пира.

Глобальные ограничения задаются отдельными директивами в том же файле:

CCCMAXHOPS 2
MAX CONNECTIONS 1
CCCRESHARE NO

CCCRESHARE NO — полный запрет пересдачи для всех C:-клиентов. Если нужно разрешить только прямым пирам, пишите CCCRESHARE 1, что ограничивает раздачу одним хопом ниже.

Ограничение хопов (hop count) и uphops/downhops

CCCMAXHOPS 2 — глобальный максимум. Для прямых доверенных пиров рекомендую ставить 1, максимум 2. При значении 3 и выше вы фактически открываете возможность каскада третьего уровня, и отследить его становится крайне сложно.

Параметр downhops=0 в G:-строке — это жёсткий запрет пиру раздавать вашу карту дальше. Именно его отсутствие чаще всего и приводит к незапланированным каскадам. Ставьте его явно, не полагайтесь на умолчания — у разных версий CCcam они могут отличаться.

Настройка max connections и ECM-rate на share

MAX CONNECTIONS 1 в CCcam.cfg ограничивает число одновременных подключений от одного C:-клиента. Для домашних пользователей с двумя ресиверами нужно ставить 2–3, иначе получите ложные срабатывания (об этом ниже).

Контроль частоты ECM в чистом CCcam реализован слабее, чем в OScam. Для тонкой настройки ECM-rate лучше использовать OScam с GBox-плагином — там это делается через параметры ecmnotfound и failban в конфигурации сервисов.

Расположение файлов: /var/etc/CCcam.cfg, /etc/oscam/, GBox-конфиг

Для OScam anti-cascading настраивается в двух файлах одновременно. /etc/oscam/oscam.server — описание ридеров и карт. /etc/oscam/oscam.user — параметры каждого аккаунта, включая hop-лимиты и лимиты соединений.

Пример секции в oscam.user:

[account]
user = peer_alex
pwd = str0ngpass
cccmaxhops = 1
cccreshare = 0
maxconn = 2
group = 1,2
monlevel = 0

cccreshare = 0 запрещает этому аккаунту пересдавать карты. maxconn = 2 позволяет одновременно подключиться двум устройствам — этого хватит для одного пира с резервным ресивером. cccmaxhops = 1 принимает запросы только с первого хопа.

Логирование OScam настраивается в /etc/oscam/oscam.conf:

[logging]
logfile = /var/log/oscam/oscam.log
debuglevel = 64

debuglevel = 64 включает подробный вывод по CCcam/GBox-соединениям. Для поиска проблем с каскадами иногда нужен уровень 128 или их комбинация — например, 192.

Пошаговая настройка защиты от каскадирования

Делать всё за один раз и перезапускать — плохая идея. Каждое изменение проверяйте отдельно, иначе при проблеме не поймёте, что именно сломало легитимные подключения.

Шаг 1: задать максимальное число хопов (1-2 для прямых пиров)

Начните с hop limit. В CCcam.cfg добавьте или откорректируйте:

CCCMAXHOPS 1

Для OScam — в каждый аккаунт в oscam.user добавьте cccmaxhops = 1. Если у вас есть пиры, которым вы доверяете немного больше и разрешаете один уровень раздачи (например, коллеге, у которого дома несколько ресиверов), ставьте им 2, но не больше.

Шаг 2: выставить лимит подключений на каждый share/account

В CCcam.cfg глобально: MAX CONNECTIONS 2. В OScam — на уровне каждого [account]: maxconn = 2. Для коммерческих раздачи (если вы по какой-то причине разрешаете пиру пересылать) можно поставить 5, но тогда hop limit обязательно должен быть 1.

Шаг 3: включить контроль ECM-time и порога запросов

В OScam для аккаунтов, которые вызывают подозрение, добавьте:

[account]
user = suspect_peer
failban = 30
ecmnotfound = 5

failban = 30 блокирует аккаунт на 30 минут после серии неудачных ECM. ecmnotfound = 5 — порог неудачных запросов до бана. Параметры подбираются под вашу ситуацию: если у пира нестабильный аплинк, слишком низкие значения дадут ложные баны.

Шаг 4: перезапуск сервиса и проверка лога

Для CCcam перезапуск делается так:

killall CCcam && sleep 2 && CCcam

Для OScam на системах с systemd:

systemctl restart oscam

На старых прошивках без systemd:

/etc/init.d/oscam restart

После перезапуска сразу смотрите лог. Для OScam:

tail -f /var/log/oscam/oscam.log | grep -i "hop\|cascade\|maxconn\|blocked"

Если в логе появляются строки с hop limit exceeded или too many connections — защита работает. Если видите такие строки на аккаунтах, которые не должны блокироваться — переходите к диагностике ложных срабатываний.

Шаг 5: тестовое подключение с контролем поведения пира

Попросите пира подключиться и посмотреть канал. Параллельно следите за логом. Нормальная картина: 1–2 ECM-запроса при открытии канала, затем редкие запросы раз в несколько минут (при смене ключа). Если ECM идут непрерывно потоком — что-то не так: либо каскад, либо очень нестабильный аплинк пира.

Диагностика и устранение ложных срабатываний

Самая частая жалоба после включения anti-cascading: "у меня нормальный пир, но его блокирует". Обычно причина — не каскад, а вполне легитимные сценарии использования.

Почему легитимный пир определяется как каскад

Пользователь с тремя ресиверами дома — это три одновременных подключения с одного аккаунта. Если у вас стоит maxconn = 1, он гарантированно получит блокировку. Решение простое: поднять maxconn до 3–4 для конкретного аккаунта, но оставить cccmaxhops = 1 жёстким.

Другая ситуация — пир за NAT или CGNAT провайдера. В этом случае несколько физически разных клиентов провайдера могут выходить с одного IP-адреса. Тут важно смотреть не на IP, а на число хопов и аккаунт.

Влияние zapping (быстрое переключение каналов) на ECM-rate

Если пир активно переключает каналы — каждое переключение генерирует ECM-запрос. 10 переключений за минуту — это 10 дополнительных ECM. При низком пороге failban это может выглядеть как атака.

Я в таких случаях поднимаю ecmnotfound до 15–20 для аккаунтов с несколькими ресиверами и оставляю жёсткий hop limit. Zapping сам по себе не признак каскада — его нужно отличать от систематически высокого ECM-rate, характерного именно для пересдачи.

Настройка порогов под реальное число ресиверов в семье

Формула простая: maxconn = число ресиверов + 1 (запас на переподключение). Если у пира 2 ресивера — ставьте 3. При этом cccmaxhops остаётся 1. Это разделяет легитимное многоустройственное использование от реального каскада.

Пир с динамическим IP добавляет ещё одну сложность: при переподключении он может ненадолго создавать две сессии (старая ещё не закрылась, новая уже открылась). Параметр keepalive в OScam помогает управлять временем жизни сессии — поставьте keepalive = 1 в [account], чтобы OScam активно контролировал соединение.

Чтение лога: какие строки указывают на каскад, а какие на overload

В OScam при включённом debuglevel = 64 строки каскада выглядят так:

2026/06/15 14:23:11 c [peer_alex] CAID 0D00 hop count 3 exceeded max 1, blocked

Это настоящее срабатывание anti-cascading — hop count превышает разрешённый. А вот строка перегрузки (overload) выглядит иначе:

2026/06/15 14:23:45 c [peer_alex] too many connections (3 > maxconn 2), rejected

Это не каскад — это просто превышение лимита соединений. Перепутать их легко, но решения разные: для первого нужно разбираться с пиром, для второго — просто поднять maxconn.

Признак настоящего каскада в логе — рост ECM по каналам, которые пир обычно не смотрит, нестабильное ECM-time (скачет от 300 мс до 2000 мс и обратно) и запросы в нерабочее время (4 утра, например).

Что важно при выборе источника карт и пиров

gbox anti-cascading: настройка теряет смысл, если ваш аплинк сам является неконтролируемым каскадом. Поэтому важно понимать, как оценивать пиров, которым вы доверяете свой шаринг.

Критерии надёжного источника без привязки к конкретным именам

Надёжный пир — тот, кто готов обсуждать hop-политику явно и соглашается на downhops=0 в G:-строке. Если пир уклоняется от разговора о хопах или настаивает на downhops=2 и выше без объяснений — это красный флаг.

Стабильность аплинка проверяется просто: смотрите на ECM-time в логе за несколько дней. Значения 200–800 мс с редкими выбросами — норма. Постоянные скачки до 2000–3000 мс означают нестабильный канал, и тогда ваши пиры будут получать фризы вне зависимости от anti-cascading.

Признаки пира, который сам каскадирует

В логе смотрите на uphop count входящих ECM. Если от пира регулярно приходят запросы с hop count = 2 и выше, хотя вы ожидаете только прямые подключения — он сам является промежуточным узлом в чьём-то каскаде.

Другой признак: аномально высокое число уникальных CAID/SID в запросах. Один домашний пользователь редко смотрит больше 5–10 каналов в сутки. Если с одного аккаунта за день прошли запросы по 80 разным SID — это явно не один человек.

Чек-лист признаков ненадёжного пира:

• Отказывается согласовывать hop-политику явно
• ECM-time постоянно нестабильное (скачки > 5x от среднего)
• Число уникальных SID за сутки аномально высокое
• Подключения идут с большого диапазона IP (CGNAT — исключение, но его видно)
• Активность в нехарактерное время (глубокая ночь в его часовом поясе)

Договорённости о hop-политике между администраторами

Лучшая защита — договорённость до начала шаринга. Явно оговаривайте: downhops=0, maxconn под конкретный сценарий использования, и что при обнаружении каскада аккаунт немедленно отключается без предупреждения.

В смешанных сетях CCcam + OScam hop-политика интерпретируется немного по-разному. CCcam считает хопы по своей логике, OScam — по своей. При переходе между ними hop count может сбиваться или пересчитываться. Поэтому в смешанных сетях я рекомендую выставлять hop limit ещё жёстче — 1 для всех внешних пиров без исключений — и проверять логи на обоих концах.