CCcam сервер: настройка и конфигурация в 2026

Если вы впервые разворачиваете server cccam с нуля — готовьтесь потратить пару часов. Не потому что это сложно, а потому что большинство руководств в интернете обрывочные и устаревшие. Здесь я собрал всё что реально нужно: от установки бинарника до защиты порта 16001 от сканеров. Будем говорить конкретно — команды, пути, директивы конфига с объяснением что будет если их поставить неправильно.

Что такое CCcam сервер и как работает протокол

Принцип простой: ваш ресивер не может расшифровать сигнал без control word (CW). Он отправляет ECM-пакет (Entitlement Control Message) на сервер, сервер прокидывает его к физической смарт-карте, карта возвращает CW, и ресивер расшифровывает картинку. Всё это занимает 200–800 мс при нормальной работе — если больше секунды, уже будут фризы.

EMM-пакеты (Entitlement Management Messages) — это обновления авторизации карты, они приходят реже и обрабатываются в фоне. CCcam умеет кешировать CW чтобы не гонять одинаковые ECM повторно от разных клиентов.

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

На сервере висит демон CCcam, к которому подключаются клиенты по F-линиям. Сам сервер может подключаться к upstream-серверам через C-линии — это peer-соединения. Локальные карты подключены через физические ридеры (serial, PCSC). Цепочка: клиент → ваш сервер → upstream → карта → обратно.

Для каждого клиента отдельный поток, поэтому нагрузка растёт линейно. 50 клиентов — 50 потоков, каждый ждёт своего ECM-ответа.

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

По умолчанию протокол CCcam работает на порту 12000/tcp. Соединение устанавливается раз, потом идёт постоянный поток данных — не как HTTP с запросами. Если разорвалось, клиент переподключается автоматически, но канал пропадает на время реконнекта (обычно 3–15 секунд).

Протокол проприетарный, закрытый. Именно поэтому разработка CCcam остановилась на версии 2.3.2 в 2014 году — автор закрыл проект, бинарник есть, исходников нет.

Отличия CCcam от OScam, NewCamd и mgcamd

CCcam — монолитный закрытый бинарник. Работает стабильно для базовых задач, но не развивается. NewCamd — более старый протокол, используется как транспорт внутри других систем. Mgcamd — клиент, не сервер, путаница частая.

OScam — open source, активно разрабатывается сообществом. Поддерживает намного больше CAS, ридеров и протоколов. Конфиг сложнее, но возможностей больше. Главное — OScam знает что делать с современными условными доступами, где CCcam просто не справляется.

Когда выбирать CCcam, а когда OScam

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

OScam — если работаете с Viaccess 5, Nagra3+, несколькими разными CAS одновременно, или нужна тонкая настройка балансировки нагрузки на карты. Также если планируете масштабироваться — OScam лучше мониторится и логируется.

Требования к серверу и подготовка системы

Хорошая новость: CCcam не требует ничего серьёзного. Плохая — если экономить на канале, клиенты будут страдать от задержек независимо от железа.

Минимальные требования: CPU, RAM, сеть

Для 50 клиентов хватит 1 vCPU, 512 МБ RAM, канал 10 Мбит/с. Реальный трафик ECM/CW небольшой — несколько килобайт на клиента в секунду. Критичнее latency: ping от сервера до клиентов должен быть меньше 50 мс, иначе ECM-задержки начнут складываться.

CPU нагружается только если много карт и запросов одновременно. RAM — CCcam держит в памяти кеш CW и состояние клиентов, 512 МБ с запасом на 100+ клиентов.

Выбор Linux дистрибутива (Debian/Ubuntu)

Debian 12 (Bookworm) — мой выбор для продакшна. Стабильные пакеты, длинный LTS-цикл, минимум неожиданных обновлений ядра. Ubuntu 22.04 LTS тоже нормально, но там иногда snap-пакеты лезут куда не просили.

Arch, Fedora, CentOS — если очень хочется, работать будет. Но команды установки пакетов будут другими, systemd там везде одинаковый.

Статический IP, проброс портов и DDNS

На VPS статический IP обычно уже есть. На домашнем сервере — либо купить статику у провайдера, либо поднять DDNS через DuckDNS или аналог и настроить обновление через cron:

*/5 * * * * curl -s "https://www.duckdns.org/update?domains=yourname&token=TOKEN&ip=" > /dev/null

Если сервер за NAT (роутер), нужен проброс порта 12000/tcp на локальный IP машины. Это делается в настройках роутера. Порт 16001 лучше не пробрасывать наружу вообще — только через VPN или reverse proxy.

Картоприёмник (PCSC) и драйверы для phoenix/smargo

Для физических карт через USB-ридер нужен pcscd:

apt install pcscd pcsc-tools libccid
systemctl enable pcscd --now
pcsc_scan

Если pcsc_scan видит карту — драйверы работают. Smargo USB определяется как /dev/ttyUSB0 или /dev/ttyUSB1. Пользователь, под которым запущен CCcam, должен быть в группе dialout:

usermod -aG dialout cccam

Это частая ошибка — карта видна через pcsc_scan, но CCcam её не подхватывает именно из-за прав доступа.

Установка CCcam на Linux: пошаговая инструкция

CCcam 2.3.2 распространяется как скомпилированный бинарник. Для x86_64 нужна версия CCcam.x86_64, для Raspberry Pi и ARM — armv7l бинарник, они несовместимы. Если поставить x86 на ARM, получите "cannot execute binary file".

Загрузка и распаковка бинарника CCcam 2.3.2

Скачайте архив, проверьте что это правильная архитектура:

file CCcam.x86_64
# CCcam.x86_64: ELF 64-bit LSB executable, x86-64

Если система 32-битная или ARM — нужен другой бинарник. На современном VPS почти всегда x86_64.

Размещение в /usr/bin и права доступа

mkdir -p /var/etc
cp CCcam.x86_64 /usr/bin/CCcam
chmod +x /usr/bin/CCcam
chown root:root /usr/bin/CCcam

Директория /var/etc нужна для CCcam.cfg — это стандартный путь, который CCcam ищёт по умолчанию. Можно использовать /etc/CCcam.cfg, тогда при запуске нужен флаг или symlink.

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

Большинство руководств до сих пор описывают init.d скрипты — это 2010-е. На современном Debian/Ubuntu правильно делать через systemd:

cat > /etc/systemd/system/cccam.service << 'EOF'
[Unit]
Description=CCcam Card Sharing Daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/CCcam -d
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable cccam

Флаг -d запускает CCcam в режиме демона с логированием. Restart=on-failure означает что systemd перезапустит процесс если он упадёт — важно для стабильности.

Запуск, остановка и проверка статуса демона

systemctl start cccam
systemctl status cccam
journalctl -u cccam -f          # live логи
ps aux | grep CCcam             # убедиться что процесс есть
ss -tlnp | grep 12000           # убедиться что порт слушается

Если ss -tlnp | grep 12000 ничего не показывает — CCcam не запустился. Смотрите journalctl -u cccam — там будет причина.

Конфигурация CCcam.cfg: разбор всех директив

Это самая важная часть. Неверно настроенный CCcam.cfg даёт либо "нет каналов", либо нестабильную работу, либо открытый доступ всем подряд. Разберём каждую директиву.

Расположение файла: /var/etc/CCcam.cfg

CCcam ищет конфиг в /var/etc/CCcam.cfg по умолчанию. Файл должен быть читаем пользователем, под которым запущен демон. Изменения применяются только после рестарта:

systemctl restart cccam

Директивы SERVER LISTEN PORT и WEBINFO LISTEN PORT

# Основной CCcam протокол — клиенты подключаются сюда
SERVER LISTEN PORT : 12000

# Веб-интерфейс для мониторинга
WEBINFO LISTEN PORT : 16001
ALLOW WEBINFO : yes
WEBINFO USERNAME : admin
WEBINFO PASSWORD : yourpassword

16001 снаружи лучше закрыть firewall и открывать только через reverse proxy с HTTPS. Иначе пароль летит в открытом виде, а сам интерфейс доступен всем желающим.

Локальные карты: SERIAL READER, NEWCAMD READER

Если карты подключены физически — они прописываются как SERIAL READER или INTERNAL. Если карты на другом сервере (OScam) — NEWCAMD READER. Подробнее в следующей секции.

Подключение C-линий: C: host port username password

C-линия — это подключение вашего сервера к upstream как клиент:

C: upstream.example.com 12000 myuser mypassword

Можно добавить несколько C-линий — CCcam использует их все параллельно. Если upstream недоступен, CCcam пробует следующий. Никогда не публикуйте реальные C-линии в открытых конфигах и примерах — они дают доступ к картам.

Раздача F-линий клиентам: F: username password hops uphops

# F: username password hops reshare uphops
F: client1 password123 1 0 0
F: client2 anotherpass 1 0 0

Каждая строка F: — один клиент. Важно понять параметры правильно, иначе либо клиент не видит каналы, либо вы открываете неконтролируемый re-share.

Reshare, hops, depth — что значат и как настроить

Hops — максимальное число пересылок ECM. Если hops=1, клиент видит только карты, напрямую подключённые к вашему серверу. Hops=2 — видит и то что ваши peers раздают. Чем больше hops, тем выше задержки.

Reshare — разрешает ли клиент раздавать полученный CW своим клиентам. Reshare=0 — нельзя, reshare=1 — можно раздавать 1 уровень. Для незнакомых пользователей всегда ставьте 0. Высокий reshare создаёт неконтролируемую нагрузку на карту и может привести к бану у провайдера.

Uphops — сколько уровней вверх по иерархии клиент может видеть. Обычно 0.

Безопасный дефолт для новых клиентов: F: user pass 1 0 0

Ещё одна полезная директива для снижения дублей ECM:

CACHE EXPIRE TIME : 15

15 секунд — разумный баланс. Слишком большое значение и кеш будет отдавать устаревшие CW. Слишком маленькое — больше повторных запросов к карте.

Подключение карты: SERIAL READER, INTERNAL и сетевые ридеры

SERIAL READER для phoenix/smargo через /dev/ttyUSB0

SERIAL READER : serial=smargo device=/dev/ttyUSB0 mhz=357 cardmhz=357 group=1

Скорость mhz зависит от типа CAS. Viaccess хорошо работает на 357 (3.57 МГц). Nagra3 часто требует 600 (6.0 МГц). Если карта инициализируется с ошибкой — попробуйте другое значение mhz, это первое что нужно менять.

Smargo USB обычно определяется как /dev/ttyUSB0. Проверить: dmesg | grep ttyUSB после подключения. Если видите тttyUSB0 и ttyUSB1 — у вас два устройства, нужно определить какое картоприёмник.

Группы (group=1, group=2) нужны когда несколько карт одного провайдера в одном сервере. Без групп возникает конфликт provider IDs — сервер не знает к какой карте роутить запрос. Группы решают это явно.

INTERNAL для встроенных слотов ресивера

На ресиверах с Linux (Dreambox, Vu+) CCcam может работать напрямую со встроенным картоприёмником:

INTERNAL READER : device=/dev/sci0 group=1

На VPS этот вариант не применим — только физические USB-ридеры или сетевые.

NEWCAMD READER для подключения к удалённому OScam

NEWCAMD READER : name=oscam1 protocol=newcamd host=192.168.1.10 port=10000 user=cccam password=pass deskey=0102030405060708091011121314 group=2

Это мост между CCcam и OScam. Полезно если карты управляются через OScam (лучшая поддержка современных CAS), а клиенты привыкли к CCcam. OScam на стороне карт, CCcam на стороне клиентов.

Параметры: BOXKEY, RSAKEY, AES KEY для специфичных CAS

Некоторые CAS требуют дополнительные ключи для инициализации карты. BOXKEY и RSAKEY специфичны для конкретных систем шифрования — если у вас нет карты, требующей эти параметры, строки просто не нужны. Прописывайте только то, что реально используете.

Веб-интерфейс CCcam и мониторинг

Порт 16001 — это не просто красивая картинка. Именно здесь видно что реально происходит на сервере: какие клиенты подключены, какое среднее время ECM, сколько ошибок. Без этого отлаживать проблемы практически невозможно.

Доступ к http://server:16001 и аутентификация

После запуска CCcam откройте в браузере http://ваш-ip:16001. Логин и пароль из директив WEBINFO USERNAME и WEBINFO PASSWORD в конфиге. Если не открывается — проверьте что ALLOW WEBINFO : yes и что firewall не блокирует порт.

Разделы: Status, Server, Clients, Shares, ECM/EMM log

Status — общая информация: версия, uptime, количество подключённых клиентов и peers. Server — список ваших C-линий и их статус (connected/disconnected). Clients — все F-линии и что они видят. Shares — какие карты/провайдеры доступны. ECM log — потоковая информация по каждому запросу.

Что смотреть: ECM time, FAIL counter, отвалы peers

Норма: avg ECM time меньше 500 мс, FAIL меньше 5% от total запросов. Если ECM time стабильно 800–1200 мс — проблема либо в карте (медленная инициализация), либо в задержках до upstream.

FAIL counter растёт — карта не отвечает на конкретные provider IDs, или C-линия перегружена. Peers disconnected и не переподключаются — проверьте сеть и учётные данные C-линий.

Защита веб-интерфейса через nginx reverse proxy

Голый порт 16001 в интернете — это плохо. Правильно: закрыть 16001 в firewall, поднять nginx как reverse proxy с basic auth и Let's Encrypt:

server {
    listen 443 ssl;
    server_name monitor.yourdomain.com;
    
    ssl_certificate /etc/letsencrypt/live/monitor.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monitor.yourdomain.com/privkey.pem;
    
    auth_basic "CCcam Monitor";
    auth_basic_user_file /etc/nginx/.htpasswd;
    
    location / {
        proxy_pass http://127.0.0.1:16001;
    }
}

Плюс fail2ban на порт 16001 чтобы ботнеты не перебирали пароли. Шаблон filter для CCcam — смотреть строки "bad password" в journalctl -u cccam.

Отладка проблем: чёрный экран, отвалы, freeze

Большинство проблем с server cccam попадают в одну из нескольких категорий. Системный подход — сначала логи, потом dogma.

Анализ логов: CCcam -d и /var/log/messages

journalctl -u cccam -f
journalctl -u cccam --since "1 hour ago" | grep -i error
dmesg | grep usb

В логах CCcam ищите: "card initialisation failed", "no card found", "bad password", "connection refused". Каждая из этих строк указывает на конкретную проблему.

ECM timeout и причины (медленная карта, перегрузка, hops)

"Card initialisation failed" — скорее всего неверная скорость ридера (mhz) или карта не того типа для выбранных параметров. Пробуйте mhz=357, 600, 800 по очереди.

"No card found on this provider" — карта инициализировалась, но не отдаёт нужные provider IDs. Возможно карта для другого региона или ключи устарели.

C-линия показывает CONNECTED но нет каналов

Это частая ситуация. CONNECTED означает только что TCP-соединение установлено и аутентификация прошла. Но каналы не появляются — значит upstream не шарит нужные провайдеры в вашу сторону. Проверьте в веб-интерфейсе раздел Shares — какие provider IDs вам доступны. Если пусто — upstream намеренно ограничил или C-линия нерабочая.

Freeze каждые N секунд: проблемы кеша и AU

Freeze каждые 10 секунд — классический признак cache miss. CW успевает истечь раньше чем придёт следующий. Решения: увеличить CACHE EXPIRE TIME, уменьшить hops (меньше прыжков — меньше задержка), проверить что AU (Auto-Update) для карты работает.

Freeze каждые несколько минут — скорее всего AU не работает и ключи протухают. Проверьте что в конфиге разрешён EMM для карты.

Картоприёмник not responding: питание, USB, скорость

Если картоприёмник отваливается раз в сутки — почти всегда это USB power saving. Linux агрессивно отключает USB-устройства для экономии питания. Фикс:

echo 'ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", ATTR{idProduct}=="YYYY", TEST=="power/control", ATTR{power/control}="on"' > /etc/udev/rules.d/99-usb-power.rules
udevadm control --reload-rules

XXXX и YYYY — vendor/product ID вашего ридера, смотреть через lsusb.

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

По умолчанию CCcam принимает подключения от любого IP на порту 12000. Это нормально если у вас закрытая сеть, но на публичном VPS — приглашение для ботов и брутфорса.

Firewall: открыть только 12000 и 16001 для нужных IP

# Разрешить SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# CCcam порт — только с конкретных IP клиентов
iptables -A INPUT -p tcp --dport 12000 -s 1.2.3.4 -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -s 5.6.7.8 -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -j DROP

# Веб-интерфейс — только localhost (nginx reverse proxy)
iptables -A INPUT -p tcp --dport 16001 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j DROP

Для сохранения правил после ребута: apt install iptables-persistent && netfilter-persistent save

Fail2ban правила для CCcam и SSH

Создайте /etc/fail2ban/filter.d/cccam.conf:

[Definition]
failregex = bad password.*from.*<HOST>
ignoreregex =

И джейл в /etc/fail2ban/jail.local:

[cccam]
enabled = true
port = 12000
filter = cccam
logpath = /var/log/cccam.log
maxretry = 3
bantime = 3600

Ограничение reshare и количества клиентов на F-линию

Reshare=0 по умолчанию для всех новых пользователей. Повышайте только для доверенных клиентов и только если понимаете последствия. Нагрузка на карту при высоком reshare может вызвать тротлинг или бан у провайдера карт.

Количество клиентов на одну физическую карту — реально не более 20–30 одновременных запросов. Если больше, ECM-время резко растёт. Следите за FAIL counter в веб-интерфейсе.

Мониторинг через collectd/Prometheus node_exporter

CCcam не экспортирует метрики напрямую в Prometheus. Но node_exporter покрывает CPU, RAM, сеть — базовый мониторинг здоровья сервера. Для специфичных CCcam метрик — парсить веб-интерфейс через curl и скрипт, или использовать OScam вместо CCcam (там есть API).

Бэкап CCcam.cfg и быстрое восстановление

# В crontab раз в неделю
0 3 * * 0 tar czf /backup/cccam-$(date +%F).tar.gz /var/etc/CCcam.cfg /usr/bin/CCcam

Восстановление за минуту: распаковать архив, systemctl restart cccam. Держите минимум 4 недельных бэкапа.

Критерии выбора провайдера C-линий: на что смотреть

Рынок C-линий непрозрачный. Половина провайдеров исчезает через 3 месяца после оплаты. Вот как минимизировать риск, не называя конкретных имён — их всё равно не стоит рекламировать.

Аптайм сервера и SLA

Нормальный провайдер показывает uptime 99%+ за последние 30 дней. Проверить можно через test-line: подключите на 48 часов и смотрите CONNECTED/DISCONNECTED в логах. Если за двое суток было больше 3 дропов — это уже тревожный знак.

Скорость ECM (<400ms — хорошо, >800ms — плохо)

Золотой стандарт — avg ECM меньше 400 мс в веб-интерфейсе. 400–600 — приемлемо. Больше 800 — будут периодические фризы. Больше 1000 — постоянные проблемы. Замеряйте в разное время суток: вечером пиковая нагрузка, и провайдеры с перегруженными серверами сразу себя показывают.

Стабильность карт и риск отключений после смены ключей

Провайдеры периодически меняют ключи шифрования — это технически неизбежно. Хороший провайдер переходит на новые ключи в течение часов. Плохой — пропадает на несколько дней и говорит "технические работы". Спросите напрямую: как быстро вы восстанавливаете сервис после смены ключей?

Поддержка клиента и реакция на тикеты

Первое обращение в поддержку до оплаты — лакмусовая бумажка. Если отвечают в течение 12 часов, на технические вопросы отвечают по существу — нормально. Если ответ через 3 дня и "всё работает, проверьте свой ресивер" — дальше лучше не станет.

Признаки ненадёжного провайдера

Скидка 80% на годовую подписку при предоплате без test-line — классическая схема. Нет test-line вообще — либо боятся что качество не понравится, либо скам. Нет отзывов на независимых форумах старше 6 месяцев — новый игрок без репутации. Поддержка отвечает только в Telegram без тикет-системы — нет истории переписки, нет доказательств договорённостей.

И главное: никогда не платите сразу за год. Месяц — максимум на первом периоде. Потеряете меньше если что-то пойдёт не так.