Server CCcam: настройка сервера кардшаринга с нуля (2026)

Если ты читаешь это, то, скорее всего, уже знаешь что такое кардшаринг и зачем тебе нужен собственный server CCcam. Ты не ищешь объяснения концепции — ты хочешь рабочую инструкцию: установить, настроить CCcam.cfg, открыть порты, раздать F-lines клиентам и не облажаться с firewall. Вот это и разберём.

Гайд написан под CCcam 2.3.x на Debian/Ubuntu. Именно 2.3.2 — последняя стабильная версия, разработка остановлена, но протокол никуда не делся и клиентская база огромная.

Что такое CCcam server и как он работает

CCcam — это программа кардшаринга, работающая по TCP. Сервер держит подключённую смарт-карту через аппаратный ридер (Phoenix, Smargo, Argolis), получает от клиентов ECM-запросы (Entitlement Control Message) и возвращает расшифрованный Control Word. Клиент использует этот CW для декодирования зашифрованного видео на ресивере.

Ключевая терминология которую нужно понять сразу: CAID (Conditional Access ID) — идентификатор системы условного доступа (например, 0x0500 = Viaccess, 0x1800 = Nagravision), Provider ID — идентификатор конкретного провайдера внутри системы, SID — Service ID конкретного телеканала.

Архитектура клиент-сервер в CCcam

Это один и тот же бинарник. Режим работы определяется целиком содержимым CCcam.cfg. Если в конфиге есть F-lines — программа раздаёт карты клиентам. Если есть C-lines — подключается к внешним серверам. Оба режима одновременно — абсолютно нормально.

Типичная схема: твой сервер по C-line тянет карту от апстрима → через F-lines раздаёт своим клиентам. Один процесс, один конфиг, всё это делает.

Протокол CCcam: порт 12000 и обмен ECM/EMM

По умолчанию сервер слушает TCP 12000. Клиент подключается, проходит аутентификацию через username/password (из F-line на сервере), после чего начинается обмен ECM-запросами. Каждый раз когда ресивер хочет открыть зашифрованный канал — он шлёт ECM, сервер ищет подходящую карту по CAID/Provider, дешифрует и возвращает CW.

EMM (Entitlement Management Message) — это команды для самой карты, обновление ключей подписки. CCcam обрабатывает EMM автоматически, если карта подключена локально.

Отличие server-режима от client-режима

F-line = ты сервер для этого клиента. C-line = ты клиент для этого сервера. В конфиге нет переключателя "режим сервера" — наличие директив определяет роль. Без F-lines никто не сможет к тебе подключиться. Без C-lines и без локального ридера твой сервер не сможет ничего расшифровать.

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

Собственный server CCcam нужен когда хочешь раздавать карту нескольким ресиверам у себя дома, или когда строишь инфраструктуру для нескольких клиентов. Если нужно просто смотреть ТВ с одного ресивера — достаточно клиентской C-line на ресивере напрямую. Поднимать полноценный сервер ради одного клиента избыточно.

Требования к железу и системе для CCcam server

Хорошая новость — CCcam крайне нетребователен к ресурсам. Плохая — сеть важнее железа, и тут ошибки дороже.

Минимальные характеристики VPS/сервера

Реальный минимум: 1 vCPU, 512 MB RAM, 5 GB диска. Этого хватит с запасом для 15-20 клиентов. Raspberry Pi 3 или 4 справляется без проблем для домашнего использования — я тестировал на Pi 4 с 10 клиентами, CPU держался на уровне 3-5%.

Узкое место всегда одно — пропускная способность самой карты по ECM/сек. Железо тут не причём.

Поддерживаемые дистрибутивы Linux (Debian, Ubuntu, CentOS)

Лучший выбор — Debian 12 или Ubuntu 22.04 LTS. CentOS в 2026 году практически мёртв после Red Hat убил CentOS 8, используй AlmaLinux или Rocky Linux если нужна RHEL-совместимость. Команды в этом гайде — под Debian/Ubuntu.

Card reader: Phoenix, Smargo Plus, Argolis Smartreader+

Для локальной карты нужен USB ридер. Phoenix — самый дешёвый вариант, работает стабильно. Smargo Plus определяется по-другому в конфиге (тип smargo вместо mouse). Argolis Smartreader+ — дороже, зато без проблем с udev и горячим подключением.

Установка драйверов:

apt update
apt install -y pcscd pcsc-tools libpcsclite-dev
systemctl enable pcscd
systemctl start pcscd
pcsc_scan

pcsc_scan должен показать ATR карты — последовательность hex байт. Если показывает пустой вывод — ридер не определился, проверяй udev и права на /dev/ttyUSB*.

Сетевые требования: статический IP, пинг до клиентов, открытые порты

Статический IP обязателен — клиенты прописывают его в C-line, если IP меняется, все они отваливаются. Пинг до клиентов должен быть стабильным, желательно менее 150 мс. При 300+ мс начнутся фризы даже при идеальном ECM time на серверной стороне.

Для домашнего сервера без статического IP — DynDNS или аналоги, но это добавляет точку отказа. Лучше VPS.

Установка CCcam на Linux пошагово

CCcam распространяется как готовый бинарник под конкретную архитектуру. x86_64 — для большинства VPS. armv7 или aarch64 — для Raspberry Pi. mipsel — для ресиверов, но на VPS тебе это не нужно.

Скачивание бинарника CCcam 2.3.x под нужную архитектуру

# Проверить архитектуру системы
uname -m

# Скачать бинарник под x86_64
wget -O CCcam https://[your-source]/CCcam_2.3.2_x86_64

# Для ARM (Raspberry Pi 4 с 64-bit OS)
wget -O CCcam https://[your-source]/CCcam_2.3.2_aarch64

Распаковка и размещение: /usr/bin/CCcam, /usr/local/etc/CCcam.cfg

mv CCcam /usr/bin/CCcam
mkdir -p /usr/local/etc
touch /usr/local/etc/CCcam.cfg
touch /var/log/CCcam.log

CCcam ищет конфиг по нескольким путям: сначала /etc/CCcam.cfg, затем /usr/local/etc/CCcam.cfg, затем в текущей директории. Я предпочитаю /etc/CCcam.cfg — стандартнее.

Права доступа: chmod 755 на бинарник, 600 на конфиг

chmod 755 /usr/bin/CCcam
chmod 600 /etc/CCcam.cfg
chown root:root /etc/CCcam.cfg

600 на конфиге важно — в нём хранятся пароли всех F-lines и C-lines открытым текстом.

Создание systemd unit для автозапуска

Большинство старых гайдов используют init.d или вообще nohup ./CCcam & в скрипте. Это устарело. Systemd — единственный правильный вариант в 2026:

# /etc/systemd/system/cccam.service
[Unit]
Description=CCcam Cardsharing Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/CCcam
Restart=always
RestartSec=5
StandardOutput=append:/var/log/CCcam.log
StandardError=append:/var/log/CCcam.log
User=root

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable cccam
systemctl start cccam
systemctl status cccam

Проверка запуска: tail -f /var/log/CCcam.log

tail -f /var/log/CCcam.log

При успешном старте увидишь строки с инициализацией портов: listening on port 12000, webinfo server listening on 16001. Если порт занят — процесс падает сразу с ошибкой bind.

Структура CCcam.cfg: разбор всех директив

Вот где большинство застревает. Синтаксис CCcam.cfg нелогичен местами и плохо задокументирован. Разберём всё что нужно для рабочего server CCcam.

Серверные параметры: SERVER LISTEN PORT, WEBINFO LISTEN PORT

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
TELNET LISTEN PORT : 16000
ALLOW TELNET : yes
ALLOW WEBINFO : yes
WEBINFO PASSWORD : your_strong_password_here

Важный момент: WEBINFO без пароля или с простым паролем — серьёзная дыра. Этот порт отдаёт список всех F-lines, C-lines и статистику в браузер. Если оставить его открытым без firewall — любой может увидеть все твои клиенты и их пароли.

F-line: формат и параметры (F: username password hops reshare)

F-line описывает клиента который подключается к твоему серверу:

F: client1 strongpass123 1 0 0 { }
F: client2 anotherpass  1 0 0 { 0500:000000 }
F: partner1 trustpass   1 1 0 { }

Разбор параметров:

• username — логин клиента
• password — пароль (без пробелов)
• hops — сколько хопов карт клиент видит (1 = только твои прямые карты)
• reshare — может ли клиент перешарить дальше (0 = нет, 1 = да на один уровень)
• 0 — третий параметр (группы), обычно 0
• { } — опциональный CAID-фильтр. Пусто = все карты. 0500:000000 = только Viaccess

Критический баг который я видел неоднократно: если два F-lines имеют одинаковый username, CCcam молча берёт последний в файле, первый игнорируется без единого warning в логе. Проверяй на дубли.

C-line: подключение к внешним серверам (C: host port username password)

C: upstream.example.com 12000 myusername mypassword no { }
C: backup.example.com   12000 myusername2 pass2    no { }

Параметр no — отключить AES-шифрование соединения (стандарт для большинства серверов). Фигурные скобки — фильтр CAID для принимаемых карт, пусто = принять всё.

Локальная карта: SERIAL READER, NEWCAMD READER, PHOENIX READER

SERIAL READER : /dev/ttyUSB0 mouse 3690000 1 0 0 1 0 0 0 0

Параметры: устройство, тип ридера (mouse для Phoenix, smargo для Smargo Plus), частота в Hz (3690000 = 3.69 MHz стандартная, 6000000 = 6 MHz для некоторых карт), затем флаги. В логе после успешной инициализации появится строка с ATR.

Параметры безопасности: ALLOW TELNET, EXTRA OPEN PORT

ALLOW TELNET : yes
EXTRA OPEN PORT : 0
NEWCAMD LISTEN PORT : 0
CAMD35 TCP LISTEN PORT : 0

EXTRA OPEN PORT — дополнительный CCcam порт, обычно не нужен, выключи через 0. NEWCAMD и CAMD35 — другие протоколы, не CCcam, включай только если нужно.

Настройка firewall и портов

UFW — самый простой вариант на Ubuntu/Debian:

ufw default deny incoming
ufw allow ssh
ufw allow 12000/tcp
ufw deny 16001/tcp
ufw deny 16000/tcp
ufw enable

Открытие порта 12000 TCP для клиентов

Если хочешь разрешить WEBINFO только с конкретного IP (например со своего домашнего):

ufw allow from 1.2.3.4 to any port 16001 proto tcp
ufw allow from 1.2.3.4 to any port 16000 proto tcp

Закрытие WEBINFO (16001) от публичного доступа

Повторю потому что это реально важно: WEBINFO на порту 16001 — это полный дамп конфига через браузер. Без пароля или с дефолтным — любой сканер портов найдёт его за минуты. Закрыть firewall'ом обязательно.

iptables правила для защиты от сканеров

Rate-limiting на порт 12000 защищает от брутфорса подключений:

iptables -A INPUT -p tcp --dport 12000 -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -m conntrack --ctstate NEW -m limit --limit 30/min --limit-burst 10 -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -m conntrack --ctstate NEW -j DROP

30 новых соединений в минуту — нормально для легитимных клиентов при реконнектах. Брутфорс скрипты обычно делают 100-1000/мин и попадают в DROP.

fail2ban для блокировки brute-force на CCcam порт

Создай файл /etc/fail2ban/filter.d/cccam.conf:

[Definition]
failregex = .*\[.*\].*rejected user.*.*
            .*\[.*\].*wrong password.*.*
            .*authentication failed.*.*
ignoreregex =

Добавь в /etc/fail2ban/jail.local:

[cccam]
enabled  = true
filter   = cccam
logpath  = /var/log/CCcam.log
maxretry = 5
bantime  = 3600
findtime = 600

5 неудачных попыток за 10 минут — бан на час. Достаточно жёстко против скриптовых атак.

Подключение реальной смарт-карты через ридер

Это самая частая причина проблем у новичков. Карта вроде работает в Windows через DVBViewer, но в Linux не определяется. Почти всегда проблема в правах на устройство или в том что pcscd не запущен.

Настройка Phoenix reader через /dev/ttyUSB0

# Проверить что устройство определилось
ls -la /dev/ttyUSB*
dmesg | tail -20 | grep tty

# Добавить пользователя в группу dialout
usermod -aG dialout root

SERIAL READER : /dev/ttyUSB0 mouse 3690000 1 0 0 1 0 0 0 0

Параметры в CCcam.cfg: SERIAL READER, скорость 3.69MHz/6MHz

Частота 3.69 MHz (3690000) — стандарт для большинства карт. Некоторые новые карты работают на 6 MHz, попробуй 6000000 если карта не отвечает на стандартной частоте. В логе при успехе появится что-то вроде:

card detected: ATR = 3B 9F 96 80 1F C7 80 31 A0 73 BE 21 13 67 29 02 01 01 01 43

Проверка карты: cardreader log, ATR ответ

ATR (Answer To Reset) — это первое что карта отвечает при включении. По первым байтам можно определить тип карты и провайдера. Если ATR читается — карта физически работает. Если после ATR идут ошибки ECM — проблема с ключами или CAID.

Типичные ошибки: card not responding, reader busy

Самая коварная ситуация: ATR читается, карта определяется, но в логе постоянно card not found при ECM запросе. Почти всегда это несовпадение CAID. Клиент шлёт ECM с CAID 0x0500 (Viaccess), а карта — Nagravision (0x1800). Смотри в WEBINFO раздел Cards — какой CAID реально зарегистрирован у карты.

Проблема с udev: после перезагрузки USB ридер может получить другой номер (/dev/ttyUSB1 вместо /dev/ttyUSB0). Решение — udev rule с привязкой по serial number:

# Найти атрибуты устройства
udevadm info -a /dev/ttyUSB0 | grep serial

# Создать /etc/udev/rules.d/99-cccam-reader.rules
SUBSYSTEM=="tty", ATTRS{serial}=="A12B3C4D", SYMLINK+="cccam_reader"

Теперь в CCcam.cfg использовать /dev/cccam_reader — всегда стабильно.

Reshare и hops: правильная топология сети

Этот раздел понимают неправильно чаще всего. Разберём конкретно.

Что такое hops и как они считаются

Hops — это расстояние от реальной карты до клиента. Карта на твоём сервере = 0 хопов. Клиент который подключается к тебе видит эту карту как 1 хоп. Если этот клиент перешарит карту своим клиентам — они видят её как 2 хопа.

Чем больше хопов — тем выше ECM time. 0 хопов = несколько мс. 3 хопа через нестабильный интернет = 500-1000 мс и фризы гарантированы.

Reshare политика: 0, 1, 2 — что разрешать

В F-line второй цифровой параметр — reshare:

• 0 — клиент не может передать карту дальше. Для обычных клиентов.
• 1 — может перешарить на один уровень вниз. Для доверенных партнёров.
• 2 — может перешарить двум уровням. Редко нужно, аккуратно.

Моя рекомендация: для всех клиентов ставить 0, для проверенных партнёров которые строят свою сеть — 1. Никогда не давать reshare 2+ незнакомым людям.

Опасность бесконечных reshare-петель

CCcam обрабатывает это через MAXHOPS (по умолчанию 5) и механизм деduplication по ID карты. Но если два сервера перешаривают карту друг другу через разные C-lines — нагрузка растёт по экспоненте. Следи за topology через WEBINFO раздел Servers.

Фильтрация CAID/provider в F-line

Если апстрим даёт тебе несколько карт (например Viaccess + Nagravision + Irdeto), а клиенту нужна только одна — ограничь в F-line:

# Только Viaccess (0500)
F: client1 pass1 1 0 0 { 0500:000000 }

# Только конкретный Nagravision провайдер
F: client2 pass2 1 0 0 { 1800:000000:ABCD 1800:000000:EFGH }

# Конкретный канал по SID
F: client3 pass3 1 0 0 { 1800:000000:ABCD:1234 }

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

Мониторинг и диагностика CCcam server

Веб-интерфейс на порту 16001: что показывает

WEBINFO показывает в реальном времени: список подключённых клиентов (online/offline), время последнего ECM по каждому клиенту, статистику good/bad ECM, список карт по CAID, список upstream серверов из C-lines и их статус.

Обязательно включи WEBINFO PASSWORD в конфиге и закрой порт от публичного доступа — это уже обсуждали выше.

Анализ логов: ECM time, freeze, rejected

Что искать в логе:

# Успешный ECM
[client1] got ECM for caid 0500 prov 000000 in 245ms

# Ошибки
[client2] rejected user - wrong password
[client3] no card for caid 1800 prov 000000
[card] timeout waiting for ECM response

# Проблемный клиент
[client4] ECM time 3200ms - freeze possible

Команды через telnet localhost 16000

telnet localhost 16000

Команды в telnet-сессии:

• c — список текущих клиентов и их статус
• s — список upstream серверов из C-lines
• r — reload конфига без перезапуска (новые F-lines применятся немедленно)
• l — список карт
• q — выйти

Команда r особенно полезна — добавил нового клиента в CCcam.cfg, сделал reload, он сразу может подключаться без рестарта сервиса.

Метрики качества: ECM avg time <500ms, 0% freeze

Хороший ECM time при локальной карте: менее 300 мс. Через интернет с одним хопом: менее 500 мс. При 800+ мс клиенты начинают жаловаться на freeze. При 1500+ мс каналы будут зависать гарантированно — проблема либо в карте, либо в апстриме.

Нестабильность ECM time (скачки от 200 до 3000 мс) почти всегда означает проблемы с апстримом в C-line или нестабильный uplink VPS. Проверь ping до апстрим сервера в период скачков.

Оптимизация производительности и стабильности

Уменьшение ECM time через cache

Кеширование ECM — самая важная оптимизация если несколько клиентов смотрят один канал:

CACHE ENABLED : yes
CACHE EXPIRE : 15
EXTRA CACHE TTL : 0

При CACHE ENABLED первый ECM идёт на карту (например 250 мс), все последующие от других клиентов на тот же канал в течение 15 секунд берутся из кеша — это 1-2 мс. Разница огромная при 10+ клиентах на популярном канале.

Настройка MAXHOPS и MAXCASCADE

MAXHOPS : 3
MAXCASCADE : 5

MAXHOPS по умолчанию 5, но я рекомендую снизить до 2-3. Карты на 4-5 хопах всегда дают высокий ECM time. MAXCASCADE ограничивает глубину reshare дерева — защита от петель.

KEEPALIVE интервалы для нестабильных соединений

KEEPALIVE : 30

Каждые 30 секунд CCcam шлёт ping сообщение. Помогает удержать NAT-сессии на стороне клиентов которые за роутером. Без KEEPALIVE NAT таблица очищает запись через 60-120 секунд простоя и клиент отваливается без явного разрыва.

Балансировка нагрузки между несколькими картами одного провайдера

Если у тебя два апстрима с одним и тем же CAID, CCcam автоматически распределяет ECM между ними — round-robin с учётом ответившего первым. Если хочешь задать приоритет:

PRIORITIZE CARDS : yes

С этой директивой CCcam будет предпочитать карту с наименьшим текущим ECM time. На практике это снижает средний ECM time примерно на 20-30% при двух апстримах.

И последнее про оптимизацию: смени SERVER LISTEN PORT с дефолтного 12000 на что-нибудь нестандартное (например 21478). Это не security by obscurity в полном смысле — это просто убирает тебя из результатов массовых сканеров Shodan которые сканируют порт 12000 по расписанию. Количество попыток брутфорса упадёт на 80-90%.