Server CCcam su Linux: guida completa all'installazione e alla configurazione

Configurare un server CCCAM su Linux da zero è una di quelle attività che sembrano semplici finché non si incontra il primo errore di compatibilità binaria alle 23:00. Questa guida copre l'intero percorso: decisioni sull'architettura, installazione dei binari, sintassi dei file di configurazione, regole del firewall e cosa fare in caso di problemi. Se hai una smartcard in mano e un computer Linux pronto, ecco esattamente cosa devi sapere.

Cosa fa effettivamente CCcam su Linux (e quando hai bisogno di un server)

CCcam è un demone per la condivisione di schede. Una macchina lo esegue con un lettore di smartcard fisico collegato: questo è il server. Altri dispositivi sulla rete (o su Internet) si connettono ad esso e richiedono la decrittazione ECM per i canali che stanno cercando di guardare. Il server decifra utilizzando la scheda fisica e invia la parola di controllo al client. Tutto questo avviene tramite TCP, porta predefinita 12000.

L'architettura è importante perché determina la configurazione. Un server ha una scheda collegata localmente ed espone linee F per i client in entrata. Un client si connette in uscita utilizzando linee C. La maggior parte delle persone si confonde perché CCcam funziona su entrambe le estremità: è lo stesso binario, solo configurato in modo diverso.

Modalità client vs. server: cosa cambia nella configurazione

Non esiste un flag separato per la "modalità server". La distinzione sta interamente nelle linee che compaiono in CCcam.cfg . Se hai linee F (che definiscono gli utenti che si connettono a te) e una linea DEVICE che punta a un lettore locale, sei un server. Se hai solo linee C (che puntano verso l'esterno, verso un altro host), sei un client. Puoi anche essere entrambi contemporaneamente, connettendoti a monte mentre servi i client a valle, ed è così che funzionano le cascate.

Perché Linux è il sistema operativo host preferito per CCcam

L'affidabilità è la ragione principale. Una macchina Linux che esegue CCcam come servizio systemd si riavvia automaticamente dopo un crash e sopravvive ai riavvii senza alcun intervento. Windows non dispone di un'infrastruttura demone equivalente per questo scopo. Inoltre, la maggior parte dei ricevitori satellitari basati su ARM attualmente utilizzati – Dreambox, VU+, Zgemma – esegue Enigma2, che è Linux. Quindi i binari, gli script di init e i percorsi di configurazione sono gli stessi su tutte le piattaforme.

Requisiti hardware: supporto CPU, RAM e lettore di smartcard fisico

CCcam non consuma molte risorse. Un processore da 500 MHz e 64 MB di RAM sono effettivamente sufficienti per una manciata di client. Qualsiasi moderno sistema Linux è ampiamente sovraqualificato. Il vero limite è il lettore di smartcard: è necessario un lettore interno (comune sull'hardware Dreambox) o un lettore USB esterno riconosciuto dal kernel. Le opzioni più comuni includono sc8in1, lettori in stile phoenixrc e lettori USB standard compatibili con CCID. Esegui dmesg | grep tty dopo aver collegato per confermare che sia stato rilevato: apparirà come /dev/ttyUSB0 , /dev/ttyACM0 o simile a seconda del chipset.

Installazione di CCcam su Linux: binario, dipendenze e primo avvio

CCcam 2.3.0 è l'ultima versione ad essere stata ampiamente distribuita. È closed-source, mai aggiornata e gli sviluppatori originali se ne sono andati da tempo. Quello che si ottiene è un binario statico o semi-statico, e su un moderno server Debian o Ubuntu a 64 bit, questo crea immediatamente problemi perché è un binario ELF a 32 bit.

Scegliere il binario CCcam giusto per la tua architettura

Esegui file CCcam su qualsiasi binario tu abbia. Vedrai qualcosa come ELF 32-bit LSB executable, ARM, EABI5 o ELF 32-bit LSB executable, Intel 80386 . Abbina il binario al tuo hardware. Binari ARM per ricevitori ARM. Binari x86 a 32 bit per server PC generici. Se utilizzi una macchina x86 a 64 bit, ti serve il binario x86 a 32 bit più il livello di compatibilità, non la build ARM, anche se ARM è in qualche modo disponibile.

Installazione delle dipendenze della libreria a 32 bit su Debian/Ubuntu

Su un nuovo sistema Debian 11/12 a 64 bit o Ubuntu 22.04, il runtime a 32 bit non è installato di default. Per prima cosa, correggi questo problema:

 dpkg --add-architecture i386 apt-get update apt-get install libc6-i386 lib32gcc-s1

Nelle versioni precedenti di Ubuntu (precedenti alla 20.04) potresti trovare riferimenti ia32-libs nelle vecchie guide: quel pacchetto non c'è più. Usa invece libc6-i386 . Dopo l'installazione, verifica con ldd CCcam per verificare che tutte le librerie condivise siano risolte. Se stai utilizzando un container Docker a 64 bit senza supporto multiarchitettura, salta completamente CCcam e passa direttamente a OScam (trattato nella sezione 6).

Posizionamento del binario e impostazione dei permessi eseguibili

 cp CCcam /usr/local/bin/CCcam chmod +x /usr/local/bin/CCcam chown root:root /usr/local/bin/CCcam

Nelle immagini dei ricevitori Enigma2, il binario solitamente si trova in /usr/bin/CCcam e viene avviato da uno script init.d. Non spostarlo su quei sistemi: i loro script init lo aspettano in quel percorso.

Esecuzione di CCcam come servizio systemd per il riavvio automatico

Crea /etc/systemd/system/cccam.service con questo contenuto:

 [Unit] Description=CCcam Card Server After=network.target [Service] ExecStartPre=/bin/sleep 10 ExecStart=/usr/local/bin/CCcam Restart=on-failure RestartSec=5 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

ExecStartPre=/bin/sleep 10 non è facoltativo se il lettore di smartcard necessita di un po' di tempo per inizializzarsi dopo l'avvio. Senza di esso, CCcam si avvia prima ancora che il kernel finisca di configurare il lettore USB e registra il messaggio "nessuna scheda trovata", quindi non riprova più correttamente.

 systemctl daemon-reload systemctl enable cccam systemctl start cccam

Verifica che il processo sia in ascolto sulla porta 12000

 ss -tlnp | grep 12000 # or netstat -tlnp | grep CCcam

Dovresti vedere CCcam associato a 0.0.0.0:12000 o a un IP di interfaccia specifico. Se non viene visualizzato nulla, controlla journalctl -u cccam -n 50 per errori di avvio.

CCcam.cfg Deep Dive: tutte le direttive che devi conoscere

Il file di configurazione si trova in /etc/CCcam.cfg per impostazione predefinita. CCcam cerca lì per primo. Alcuni script di avvio passano il percorso come argomento: controlla il tuo se le modifiche non vengono rilevate. Un problema che tormenta costantemente: i terminatori di riga di Windows (CRLF) nel file di configurazione causano errori di analisi silenziosi su Linux. Se hai modificato questo file su Windows e lo hai trasferito, esegui dos2unix /etc/CCcam.cfg prima di eseguire il debug di qualsiasi altra cosa.

I commenti usano # o // — entrambi funzionano. Le direttive non distinguono tra maiuscole e minuscole per la parola chiave stessa, ma i valori (nomi utente, password, nomi host) lo fanno.

Porta del server e indirizzo di ascolto: direttive SERVERPORT e BIND

 # Listen for incoming CCcam client connections SERVERPORT: 12000 # Bind to a specific interface (recommended) # BIND: 10.8.0.1

Se si dispone di più interfacce di rete, ad esempio un'interfaccia WAN e un'interfaccia VPN, CCcam si collegherà a tutte per impostazione predefinita (0.0.0.0). Questo rappresenta un problema di sicurezza. Utilizzare la direttiva BIND per bloccare solo l'IP dell'interfaccia VPN. Maggiori informazioni nella sezione dedicata al firewall.

Definizione dei lettori di schede locali: righe DEVICE, CARDTYPE e BOXKEY

 # Define the physical smartcard reader DEVICE: /dev/ttyUSB0 SR CARDTYPE: 0 BOXKEY: 00 00 00 00 00 00 00 00

Il percorso DEVICE deve corrispondere a quello mostrato dmesg . Se il lettore appare come /dev/ttyACM0 invece di /dev/ttyUSB0 , la configurazione deve indicare /dev/ttyACM0 . Sbagliare questo parametro è uno dei motivi più comuni per gli errori "nessuna scheda trovata". CARDTYPE 0 significa rilevamento automatico, che funziona per la maggior parte delle schede. BOXKEY è rilevante per le schede Nagravision che utilizzano una boxkey: lascialo a zero se la tua non lo fa.

Aggiunta di client C-line: C: analisi della sintassi

Una linea C indica a questo server di connettersi verso l'esterno a un altro server CCcam:

 C: remote.host.example 12000 myusername mypassword {0:0:1} 01

Analizzando il tutto: remote.host.example è il nome host o l'IP del server upstream. 12000 è la porta. myusername e mypassword sono le tue credenziali su quel server. {0:0:1} è un filtro CAID facoltativo nel formato {CAID:ProviderID:1} : un valore di 0:0:1 significa accettare tutti i CAID. Lo 01 finale è il numero di hop per le schede di ricondivisione ricevute da questa linea.

Aggiunta di utenti F-line (connessioni in entrata): F: sintassi e limiti di salto

Le linee F definiscono chi è autorizzato a connettersi al tuo server:

 F: client1 strongpassword 1 0 0 0 { 1830:000000:1 } F: client2 anotherpass 1 0 0 0 { 0:0:1 }

I campi dopo la password sono: livello di ricondivisione (1 = può ricondividere un solo passaggio), numero minimo di passaggi per le carte (0 = carte locali), gruppo CAID, gruppo di identificazione e un blocco filtro CAID opzionale. Il filtro { 1830:000000:1 } limita questo utente al solo CAID 0x1830. Utilizza password complesse e univoche per ogni linea F: queste sono le credenziali che i tuoi clienti inseriscono nelle loro linee C.

Linea B per bloccare ID provider specifici

 B: 1234 000000

Le linee B impediscono la condivisione di una specifica combinazione CAID/fornitore. Se hai una carta con più fornitori e vuoi negarne uno, ecco come fare. Il formato è B: CAID ProviderID .

LIMITE DI CONDIVISIONE e CONTEGGIO DI SALTI: Controllo della profondità di ricondivisione

HOP COUNT controlla quante volte una scheda può essere ricondivisa prima che CCcam interrompa la sua trasmissione. Impostalo in righe F (per utente) o globalmente:

 SHARE LIMIT: 3

Un HOP COUNT pari a 0 indica che la carta è locale e non verrà mai ricondivisa. Un valore pari a 1 indica che può essere inviata ai client con un solo hop, ma che questi ultimi non possono ricondividerla. Mantenete questo valore al minimo indispensabile: le catene di ricondivisione profonde rallentano i tempi di risposta dell'ECM e creano problemi di accountability.

Direttive LOG e DEBUG per la risoluzione dei problemi

 LOGFILE: /var/log/cccam.log LOGLEVEL: 1 DEBUG: 0

LOGLEVEL 1 fornisce eventi di connessione e attività ECM senza sovraccaricare il disco. Impostate temporaneamente DEBUG a 1 quando cercate un problema specifico: è prolisso e dovrete disattivarlo. L'interfaccia web sulla porta 16001 (credenziali predefinite: admin/admin, modificatele immediatamente) mostra lo stato della scheda in tempo reale, i client connessi e la temporizzazione ECM, molto più facile da leggere rispetto ai log grezzi durante la diagnosi.

Firewall, rete e inoltro delle porte per CCcam

È qui che la configurazione di un server CCCAM Linux si blocca più comunemente. Il servizio è in esecuzione, la configurazione sembra corretta, ma i client non riescono a connettersi. Nove volte su dieci si tratta di una regola del firewall o di un problema di NAT.

Apertura della porta TCP 12000 con iptables e ufw

Utilizzo diretto di iptables:

 iptables -A INPUT -p tcp --dport 12000 -j ACCEPT # Save rules so they survive reboot: iptables-save > /etc/iptables/rules.v4

Oppure se stai usando ufw:

 ufw allow 12000/tcp ufw reload

Se si desidera limitare l'accesso solo agli IP client noti (pratica decisamente migliore):

 iptables -A INPUT -p tcp --dport 12000 -s 203.0.113.45 -j ACCEPT iptables -A INPUT -p tcp --dport 12000 -j DROP

Associazione di CCcam a un'interfaccia specifica per evitare l'esposizione

Se il tuo server ha un'interfaccia pubblica (eth0) e un'interfaccia VPN (wg0 o tun0), non lasciare CCcam in ascolto su entrambe. Aggiungi la direttiva BIND in CCcam.cfg con l'IP dell'interfaccia privata/VPN. I client si connettono tramite la VPN e la porta 12000 non è mai esposta alla rete Internet pubblica. Questo è il modo corretto di procedere.

Utilizzo di un tunnel VPN (WireGuard/OpenVPN) anziché esporre pubblicamente la porta 12000

WireGuard è la scelta migliore al giorno d'oggi: meno overhead rispetto a OpenVPN, configurazione più semplice e il modulo kernel è ora mainline da Linux 5.6. Imposta un peer WireGuard tra il tuo server e ciascun client, assegna loro indirizzi in una subnet privata (ad esempio, 10.8.0.0/24), associa CCcam a 10.8.0.1 e inserisci quell'indirizzo nelle linee C sul lato client. Nessuno che scansioni Internet vedrà mai la porta 12000.

NAT e Port Forwarding se il server si trova dietro un router domestico

Se il tuo box Linux si trova su una rete domestica, devi inoltrare la porta TCP 12000 del router all'IP locale del server. La maggior parte dei router chiama questa operazione "port forwarding" o "server virtuale". Imposta la porta esterna su 12000, il protocollo TCP, l'IP interno sull'indirizzo LAN del server (rendilo statico, tramite prenotazione DHCP o configurazione manuale), la porta interna 12000. A questo punto, i client utilizzeranno il tuo IP pubblico nelle loro linee C.

Un problema importante: se il tuo ISP utilizza CGNAT (carrier-grade NAT), non hai un IP pubblico: ne condividi uno con decine di altri clienti e non c'è modo di inoltrare le connessioni in entrata. La soluzione è noleggiare un VPS economico, eseguirci WireGuard e incanalare il traffico CCcam attraverso di esso. Il VPS diventa l'endpoint pubblico; il tuo server di casa comunica attraverso il tunnel.

DNS dinamico per server senza IP statico

Se il tuo IP pubblico cambia, i client con il tuo vecchio IP nelle loro linee C non riusciranno a connettersi. Utilizza un servizio DNS dinamico e inserisci il nome host (ad esempio, myserver.ddns.net ) nelle linee C invece di un semplice IP. Esegui un client di aggiornamento DDNS come ddclient sul tuo server Linux per mantenere il record aggiornato. Anche la maggior parte dei router domestici lo ha integrato.

Inoltre: se il tuo ISP blocca specificatamente il TCP in entrata sulla porta 12000 (alcuni lo fanno), modifica SERVERPORT con qualcosa di meno evidente, come 15000 o 8080, aggiorna la regola di inoltro della porta del router e aggiorna la linea C di ogni client di conseguenza.

Risoluzione dei problemi comuni del server CCcam su Linux

Il debug di una configurazione Linux del server CCCAM segue uno schema piuttosto coerente: eliminare i livelli uno alla volta, partendo dal basso (il processo è effettivamente in esecuzione?) e risalendo attraverso la rete, quindi la configurazione e infine il rilevamento della scheda.

CCcam si avvia ma i client non riescono a connettersi: elenco di controllo

• Conferma che il processo è effettivamente in esecuzione: systemctl status cccam
• Conferma che è in ascolto: ss -tlnp | grep 12000
• Eseguire prima un test locale: telnet 127.0.0.1 12000 — se questo fallisce, il problema è il servizio, non la rete
• Controlla il firewall: iptables -L -n | grep 12000
• Controllare la riga F: nome utente e password devono corrispondere esattamente a quelli utilizzati dal cliente nella riga C
• Conferma che l'IP/nome host della linea C del client venga risolto correttamente dalla macchina client

'Nessuna carta trovata' o carta non rilevata dopo la definizione del lettore

Inizia con dmesg | tail -30 subito dopo aver collegato il lettore. Dovresti vedere una riga relativa a un nuovo dispositivo USB e al nodo dispositivo a cui è stato assegnato. Se non la vedi, il lettore non è riconosciuto a livello di kernel: potrebbe trattarsi di un problema del driver o di un guasto hardware.

Se il lettore viene visualizzato ma la scheda non viene rilevata, verifica che la riga DEVICE in CCcam.cfg punti al percorso esatto mostrato in dmesg. Ricorda: /dev/ttyACM0 e /dev/ttyUSB0 sono dispositivi diversi e quello sbagliato causerà un errore silenzioso. Verifica inoltre che l'utente del processo CCcam abbia i permessi di lettura/scrittura sul dispositivo: ls -l /dev/ttyUSB0 e aggiungi l'utente CCcam al gruppo dialout , se necessario.

Risposte ECM errate e errori di decodifica (mancata corrispondenza CAID)

Il client si connette, lo vedi nell'interfaccia web di CCcam sulla porta 16001, ma il canale non decifra. Quasi sempre si tratta di una mancata corrispondenza del CAID. Apri l'interfaccia web, controlla quali CAID il server sta effettivamente pubblicizzando. Quindi controlla quale CAID utilizza il canale: la schermata delle informazioni sul canale del tuo decoder o un menu della CAM lo mostreranno. Se non corrispondono, il server non può aiutare quel client, indipendentemente dallo stato della connessione.

Controllare anche il valore HOP COUNT. Se la linea F per quel client ha un valore di condivisione pari a 0 e la carta è stata ricevuta da una linea C upstream (non locale), il client non riceve nulla. Il valore HOP COUNT 0 blocca la condivisione di carte non locali.

Carico elevato/Tempi di risposta ECM lenti

Una singola scheda fisica può elaborare un solo ECM alla volta. Se si hanno 10 client che richiedono la decrittazione contemporaneamente, questi si mettono in coda e i tempi di risposta aumentano. Il canale potrebbe presentare problemi di intermittenza o oscurarsi momentaneamente. La soluzione consiste nell'utilizzare meno client, schede fisiche aggiuntive o linee C upstream aggiuntive con schede diverse. Non esiste una soluzione software alternativa a questo problema: è un vincolo hardware.

Posizione del file di registro e come leggere l'output di debug di CCcam

Se LOGFILE è definito in CCcam.cfg, i log vengono salvati lì. In caso contrario, se si esegue con systemd, utilizzare journalctl -u cccam -f per una coda live. Cercare le righe contenenti "connected", "ECM", "card" e codici di errore. Una risposta ECM pari a "0x00" indica solitamente che la scheda ha risposto correttamente. Errori come "N/D" o messaggi di timeout indicano problemi con la scheda.

CCcam si blocca all'avvio: correzione dell'incompatibilità binaria

Esegui prima file CCcam . Quindi esegui ldd CCcam . Se vedi "not a dynamic executable" (non un eseguibile dinamico), il binario è linkato staticamente e dovrebbe essere eseguito. Se vedi librerie non risolte ("not found"), installa i pacchetti a 32 bit mancanti. Se CCcam si chiude immediatamente con "Exec format error" (errore di formato Exec), l'architettura non è compatibile, ad esempio un binario ARM su x86. Procurati il binario corretto per la tua piattaforma.

CCcam vs OScam come server Linux: quando cambiare

Se stai iniziando da zero oggi, prendi seriamente in considerazione OScam. CCcam 2.3.0 è abandonware: nessuna patch, nessun aggiornamento, nessun codice sorgente da controllare. OScam è attivamente mantenuto, open source (GPL) e supporta un superset di ciò che fa CCcam. L'unico motivo per rimanere su CCcam è se hai specificamente bisogno della compatibilità del client CCcam con dispositivi legacy che non supportano il protocollo nativo di OScam – e anche in quel caso, OScam se ne occupa.

Differenze chiave nell'architettura

CCcam è una scatola nera. Prendi il binario, lo configuri e speri che funzioni: non c'è modo di ispezionarne o modificarne i componenti interni. OScam è completamente open source, aggiornato costantemente per nuovi tipi di schede e problemi di sicurezza, e ha un modello di configurazione molto più ricco, con filtri per lettore e per utente con una granularità che CCcam non può eguagliare. L'interfaccia web di OScam è anche sostanzialmente migliore della pagina base della porta 16001 di CCcam.

Filtraggio superiore di CAID e Provider ID di OScam

In OScam è possibile filtrare per CAID, ID provider, ID servizio e persino PID ECM specifici, il tutto in modo indipendente per lettore, utente e profilo. Il filtraggio di CCcam, al confronto, è piuttosto approssimativo. Se si gestisce una scheda con più pacchetti provider e si necessita di un controllo rigoroso su ciò a cui ogni client può accedere, OScam è lo strumento giusto.

Esecuzione di OScam come server di protocollo CCcam (ascoltatori cs378x / cs357x)

OScam può gestire il protocollo CCcam in modo nativo. Ciò significa che i client CCcam esistenti non devono modificare le loro linee C: OScam risponde sulla porta 12000 e non rilevano mai la differenza.

In /etc/oscam/oscam.conf , aggiungi un blocco listener:

 [cs378x] port = 12000 key = 0102030405060708091011121314151617181920

Il modulo cs378x gestisce le connessioni con protocollo CCcam versione 2.x. Per le versioni precedenti del protocollo CCcam, utilizzare cs357x. Gli utenti vengono quindi definiti in /etc/oscam/oscam.user con protocol = cccam .

Percorso di migrazione: conversione di CCcam.cfg in file di configurazione OScam

Le linee C di CCcam diventano voci del lettore in /etc/oscam/oscam.server :

 [reader] label = upstream1 protocol = cccam device = remote.host.example,12000 user = myusername password = mypassword caid = 1830 ident = 1830:000000

Le linee F di CCcam diventano voci utente in /etc/oscam/oscam.user :

 [account] user = client1 pwd = strongpassword protocol = cccam group = 1 caid = 1830

La conversione è meccanica, ma richiede di procedere riga per riga. Non esiste uno strumento automatico che gestisca ogni caso limite in modo affidabile. Prendetevi un'ora e fatelo manualmente: ne vale la pena per la manutenibilità a lungo termine di una corretta configurazione di OScam rispetto a un'installazione Linux di un server CCCAM legacy.