Wicardd Anti-Cascading Setup: Konfigurationsanleitung

Wenn Sie einen auf Wicardd basierendenCard-SharingServer betreiben und Ihre physische Karte mit ECM-Anfragen überflutet wird, verkauft wahrscheinlich jemand Ihre Leitung weiter. Die richtige Konfiguration der Wicardd-Anti-Cascading-Einstellungen ist der Weg, um dem ein Ende zu setzen — oder zumindest es so teuer zu machen, dass es sich nicht mehr lohnt. Das ist kein einfacher Copy-Paste-Job. Die Schwellenwerte sind wichtig, das Abtastfenster ist wichtig, und eine falsche Einstellung wird legitime Multi-Tuner-Clients abweisen, bevor sie jemals einen tatsächlichen Wiederverkäufer erfassen.

Diese Anleitung behandelt die tatsächlichen Konfigurationsanweisungen, wie man sinnvolle Startwerte ableitet und wie man testet, ohne die Dinge für echte Benutzer zu brechen.

Was Anti-Cascading tatsächlich in Wicardd erkennt

Die Grundidee ist einfach: Eine Abonnementleitung sollte ECM-Anfragen ungefähr in dem Tempo erzeugen, in dem ein einzelner Empfänger sie generiert. Ein gut funktionierender DVB-S2-Empfänger sendet eine ECM-Anfrage pro Kryptoperiode — typischerweise alle 8–10 Sekunden pro aktivem Stream. Wenn ein Konto beginnt, 15 ECM-Anfragen im selben Fenster zu generieren, wird etwas von diesem einen Login aus mehrere nachgelagerte Boxen versorgen.

Das ist Cascading. Eine Leitung, die auf mehrere Clients verteilt ist, die jeweils parallel Entschlüsselungsschlüssel anfordern. Die Erkennung basiert auf Gleichzeitigkeit und Timing, nicht auf Identität. Wicardd kann tatsächlich nicht beweisen, dass jemand weiterverkauft — es kann nur sehen, dass das Anfrage-Muster nicht mit einem einzelnen Empfänger übereinstimmt.

Cascading vs. legitime Multi-Tuner-Clients

Ein echtes Multi-Raum-Setup mit einem DVB-S2-Empfänger und zwei oder drei zusätzlichen Tunern wird parallele ECMs erzeugen. Das wird auch bei Bild-in-Bild der Fall sein. Ein Client, der einen Kanal aufnimmt, während er einen anderen auf derselben Box ansieht, kann leicht 2–3 gleichzeitige ECM-Anfragen legitim erreichen.

Der Unterschied zwischen dem und einem missbräuchlichen Wiederverkäufer ist die anhaltende Gleichzeitigkeit bei hohen Zählungen. Ein Zwei-Tuner-Client erreicht 2–3 gleichzeitige ECMs und fällt dann zurück. Eine kaskadierte Leitung, die 8–12 nachgelagerte Boxen betreibt, hat ständig hohe Gleichzeitigkeit. Dieses anhaltende Muster ist das, was Anti-Cascading anvisiert.

Wie Wicardd parallele ECM-Anfragen pro Konto zählt

Wicardd führt intern einen Anfragezähler pro Konto. Jede eingehende ECM von einem Konto erhöht diesen Zähler; der Zähler verringert sich, wenn Antworten gesendet werden oder wenn das rollende Zeitfenster voranschreitet. Was Sie konfigurieren, ist die Obergrenze — die maximale Anzahl von ungelösten oder in Bearbeitung befindlichen ECMs, die pro Konto erlaubt sind, bevor das System Maßnahmen ergreift.

Die Auswertung ist rollierend, nicht in festen Intervallen. Ein Ausbruch bei Sekunde 0 und ein weiterer bei Sekunde 4 liegen beide im Fenster, wenn Ihr Abtastintervall 10 Sekunden beträgt. Das ist beabsichtigt — es erfasst die schnellen sequenziellen Anfragen, die vom schnellen Kanalwechsel kommen, die ansonsten wie niedriggradiges Cascading aussehen.

ECM-Zeitfenster und Anfragerate als Erkennungssignale

Zwei Zahlen definieren die Erkennung: das Abtastfenster (in Sekunden) und die Anzahl der Anfragen, die innerhalb dieses Fensters ein Flag auslösen. Ein Fenster von 10 Sekunden mit einer Schwelle von 6 bedeutet: Wenn ein Konto mehr als 6 ECM-Anfragen in einem rollierenden Zeitraum von 10 Sekunden einreicht, ergreift Wicardd die konfigurierte Maßnahme.

Engere Fenster erfassen Ausbruchs-Missbraucher, erzeugen jedoch falsch-positive Ergebnisse bei schnellen Zappern. Breite Fenster erfassen Ausbruchsverhalten, erfassen jedoch anhaltende Überlastung. Sie müssen das richtige Gleichgewicht für Ihre Benutzerbasis finden, weshalb es wichtig ist, eine Basislinie zu erstellen, bevor Sie konfigurieren — behandelt in Abschnitt 3.

Kern-Anti-Cascading-Richtlinien in der Wicardd-Konfiguration

Die Wicardd-Anti-Cascading-Konfiguration befindet sich in der Hauptkonfigurationsdatei und optional in Benutzer-/Konto-Blöcken. Der Standardinstallationspfad auf den meisten Linux-Setups ist/etc/wicardd.conf. Einige Builds platzieren es unter/usr/local/etc/wicardd.conf oder im Installationsverzeichnis alswicardd.cfg. Überprüfen Sie Ihr Init-Skript oder die systemd-Einheit auf den genauen Pfad, der an den Daemon übergeben wird — es ist normalerweise das-cArgument.

Den Konfigurationsdatei und die [account]/Benutzerblöcke finden

Die globalen Anti-Cascading-Einstellungen gelten für alle Konten, es sei denn, sie werden überschrieben. Benutzerblöcke ermöglichen es Ihnen, engere oder lockerere Grenzen für spezifische Logins festzulegen. In den meisten Wicardd-Versionen sehen die Benutzerdefinitionen so aus:

[BENUTZER]

Globale Standardwerte kommen in den[ANTICASCADING] oder äquivalenten globalen Block, vor allen Benutzerdefinitionen. Benutzerüberschreibungen in den[BENUTZER]Blöcken haben Vorrang. Wenn Sie keine Benutzerblöcke haben und nur eine flache Benutzerliste verwenden, gelten die globalen Einstellungen für alle.

Maximale parallele ECM-/Verbindungsgrenzen pro Benutzer festlegen

Diemaxecm Die Richtlinie begrenzt die Anzahl gleichzeitiger in-flight ECM-Anfragen für dieses Konto. Dies ist Ihre erste Verteidigungslinie. Setzen Sie sie zu niedrig (wie 1), kann ein Dual-Tuner-Empfänger nicht funktionieren. Setzen Sie sie zu hoch (wie 20), hat es keinen nützlichen Effekt.

Ein funktionierender Ausgangspunkt für einen typischen Einzelreceiver-Client liegt bei 3–4. Für einen Client, von dem Sie wissen, dass er ein Multiroom-Setup mit bis zu 4 Tunern betreibt, setzen Sie ihn auf 6–8. Der Anti-Cascading-Schwellenwert ist eine sekundäre Überprüfung, die die Rate über die Zeit überwacht;maxecm ist die harte gleichzeitige Obergrenze.

[ANTICASCADING]

Definition des Erkennungszeitintervalls und des Anfrageschwellenwerts

Derdefault_window Wert ist in Sekunden. Derdefault_threshold ist die ECM-Anzahl, die, wenn sie innerhalb dieses Zeitfensters überschritten wird, eine Aktion auslöst. Alsowindow = 10 undthreshold = 8 bedeutet: mehr als 8 ECMs in einem beliebigen 10-sekündigen rollierenden Zeitraum kennzeichnet das Konto.

Warum 8 und nicht 4? Weil schnelles Zappen. Ein Client, der schnell die Kanäle wechselt, kann 3–4 ECMs in schneller Folge einreichen, während der Decoder jeden Dienst ausprobiert. Ein kleiner Puffer über Ihrermaxecm gleichzeitigen Obergrenze verhindert, dass diese kurzen Spitzen die Ratenbegrenzung auslösen.

Auswahl der Aktion: Drosseln, Pausieren oder Trennen

Wicardd bietet typischerweise drei Reaktionsmodi an:

• drosseln — zusätzliche ECMs über dem Limit werden verzögert oder ignoriert, der Client wird beeinträchtigt, aber nicht getrennt
• pausieren — das Konto wird fürfreeze_time Sekunden pausiert und dann automatisch wiederhergestellt
• trennen — die Verbindung wird sofort getrennt, der Client muss sich erneut verbinden

Beginnen Sie mitdrosseln. Ganz klar. Die Kosten für ein falsch positives Ergebnis bei einem legitimen Client sind ein verschlechtertes Bild — ärgerlich, aber wiederherstellbar. Die Kosten für eine harte Trennung bei einem legitimen Multi-Tuner-Client sind ein verärgerter Benutzer und eine Supportanfrage. Führen Sie eine Woche lang im Drosselmodus, lesen Sie die Protokolle und entscheiden Sie dann, ob wiederholte Übeltäter auf Pausieren oder Trennen eskaliert werden müssen.

Nach jeder Bearbeitung der Konfigurationsdatei starten oder laden Sie den Daemon neu. Änderungen werden erst wirksam, wenn der Daemon sie aufnimmt. Bei systemd-Setups:systemctl restart wicardd odersystemctl reload wicardd wenn ein Neuladen unterstützt wird. Ein häufiger Fehler ist es, die Datei zu bearbeiten, das Verhalten zu überprüfen und sich zu fragen, warum sich nichts geändert hat — der Daemon läuft weiterhin mit der alten Konfiguration im Speicher.

Anpassung der Schwellenwerte ohne echte Benutzer zu sperren

Hier scheitern die meisten Anleitungen. Sie geben Ihnen die Richtlinien und lassen Sie die Zahlen erraten. Der richtige Ansatz ist, zuerst zu messen und dann die Schwellenwerte basierend auf dem, was Sie tatsächlich sehen, festzulegen.

Baseline der normalen ECM-Raten pro Kanal und Karte

Wählen Sie einen bekannten guten Client — einen Empfänger, einen Stream, der 30 Minuten lang auf einem Kanal sitzt. Überwachen Sie die ECM-Rate in den Wicardd-Protokollen oder der Statusoberfläche (mehr dazu in Abschnitt 4). Ein standardmäßiger DVB-Stream auf einer gesunden Karte wird alle 8–10 Sekunden eine ECM-Antwort liefern. Das ist Ihre Basislinie: ungefähr 6 ECMs pro Minute oder etwa 1 ECM pro 10-Sekunden-Fenster.

Jetzt wissen Sie, wie ein einzelner sauberer Tuner numerisch aussieht. Setzen Sie Ihre Schwelle so, dass sie das berücksichtigt, multipliziert mit Ihrer erwarteten maximalen Tuneranzahl, plus einem Puffer für Zapping und PiP.

Berücksichtigung von Zapping-Spitzen und PiP/Multi-Tuner

Kanal-Zapping ist der Hauptauslöser für falsch-positive Ergebnisse. Wenn ein Zuschauer schnell durch mehrere Kanäle wechselt, sendet der Decoder ECM-Anfragen für jeden einzelnen — oft 3–5 in schneller Folge, bevor er sich auf einen Kanal einigt. Das sind legitime Anfragen, und sie passieren in einem sehr kurzen Zeitfenster.

Bild-in-Bild ist ähnlich. Zwei Streams von einer Box bedeuten zwei parallele ECM-Streams. Das ist kein Missbrauch — das ist ein Merkmal moderner Empfänger. Ihre Schwellenwerte müssen dies handhaben, ohne auszulösen.

Eine vernünftige Regel: Setzen Sie Ihreanticascade_threshold auf (maximal erwartete Tuner × 2) + 2, ausgewertet über ein 10-Sekunden-Fenster. Für einen Client mit bis zu 2 Tunern sind das 6. Für 4 Tuner sind das 10. Das gibt Raum für Zapping-Spitzen, während gleichzeitig ein Konto, das 8+ downstream Clients gleichzeitig speist, erfasst wird.

Pro-Konto-Overrides für vertrauenswürdige Multi-Raum-Clients

Wenn Sie spezifische Clients haben, denen Sie vertrauen — Freunde mit großen Multi-Raum-Setups, Ihre eigenen Testboxen — geben Sie ihnen explizite pro-Benutzer-Overrides, anstatt die globale Schwelle für alle zu erhöhen.

[BENUTZER]

Auf diese Weise erzeugen Ihre Ausnahmen mit hohen Schwellenwerten keinen Schutz für tatsächliche Missbraucher, die Standardkonten verwenden. Alle anderen bleiben bei der strengeren globalen Grenze.

Seien Sie vorsichtig mit CGNAT-Clients. Ein Benutzer in einem Carrier-Grade-NAT teilt sich eine öffentliche IP mit Dutzenden anderer Abonnenten. IP-basierte Limits werden sie unfair kennzeichnen, aber ECM-Konkurrenzlimits funktionieren einwandfrei, da sie an den Konto-Login und nicht an die Quell-IP gebunden sind. Denken Sie daran, wenn Sie Verbindungs- und IP-Limits neben der Anti-Kaskadierung festlegen.

Überprüfen, ob es funktioniert: Protokolle, Zähler und Live-Tests

Konfigurieren Sie es, und beweisen Sie es. Gehen Sie nicht davon aus, dass die Einstellungen funktionieren, nur weil sie in der Datei sind und Sie den Daemon neu gestartet haben.

Lesen von Anti-Kaskadierungs-Treffern im Wicardd-Protokoll

Der Protokollpfad ist in der Konfiguration festgelegt — suchen Sie nach einerlogfile oderlog_path Direktive, die oft auf/var/log/wicardd.log oder/tmp/wicardd.log zeigt. Wenn die Anti-Kaskadierung ausgelöst wird, sehen Sie einen Eintrag mit dem Kontonamen, der ECM-Anzahl, die sie ausgelöst hat, dem Fenster, in dem sie ausgewertet wurde, und der ergriffenen Maßnahme. Es sieht ungefähr so aus:

[2026-03-12 14:22:31] ANTICASCADE: user=clientX ecm_count=11 window=10s action=throttle

Wenn Sie diese Einträge nicht sehen, ist entweder die Funktion nicht aktiviert, das Protokollniveau zu niedrig oder der Daemon hat die Konfiguration nicht neu geladen. Überprüfen Sie Ihre Protokoll-Verbosity-Einstellung — die meisten Builds haben eineloglevel oderdebug Direktive; setzen Sie sie während der ersten Einrichtung auf mindestens 2 oder INFO.

Überwachung des Live-Status/Web-Interfaces für markierte Konten

Wicardd bietet typischerweise eine Statusoberfläche auf einem lokalen Port an — oft TCP 8080 oder einen ähnlichen Web-UI-Port, der in der[STATUS] Block konfiguriert ist. Dies zeigt pro Konto aktive Verbindungen, aktuelle ECM/s und Flags. Es ist nützlicher als das Verfolgen von Protokollen, wenn Sie eine Echtzeitansicht darüber haben möchten, wer die Limits erreicht.

Sortieren Sie nach ECM-Rate in der Live-Ansicht. Ein kaskadiertes Konto wird ganz oben sitzen mit einer offensichtlich unverhältnismäßigen Rate im Vergleich zu allen anderen. Ein einzelner sauberer Empfänger wird neben einem Konto, das 20+ ECM/s drückt, nicht einmal verdächtig erscheinen.

Kontrollierter Test: Simulieren Sie parallele Anfragen, um das Auslösen zu bestätigen

Der sauberste Weg zur Überprüfung ist ein kontrollierter Test. Nehmen Sie ein Ersatzkonto — nicht eines, das echte Clients verwenden — und richten Sie zwei oder drei Empfänger gleichzeitig darauf aus. Oder verwenden Sie ein Testwerkzeug, das parallele ECM-Anfragen an dasselbe Konto senden kann. Innerhalb Ihres konfigurierten Abtastfensters sollte der Zähler auslösen und Sie sollten die Drossel- oder Einfrieraktion in den Protokollen sehen.

Testen Sie dann das Negative: Ein einzelner Empfänger auf seinem eigenen Konto mit normalem Zapping-Verhalten sollte niemals auslösen. Überwachen Sie die Protokolle über 10–15 Minuten realer Nutzung mit Kanalwechseln. Wenn Sie Treffer auf einem Einzelreceiver-Konto sehen, ist Ihre Schwelle zu niedrig — erhöhen Sie sie oder erweitern Sie das Fenster.

Ziehen Sie die Schwellenwerte nicht nach einem Tag Protokollen an. Führen Sie die aktuelle Konfiguration mehrere Tage lang aus, bevor Sie Anpassungen vornehmen. ECM-Muster variieren je nach dem, was auf Sendung ist, zu welcher Tageszeit und wie aktiv Ihre Clients zappen. Eine volle Woche an Daten ist besser als ein paar Stunden.

Kombination von Anti-Cascading mit anderen Missbrauchskontrollen

Anti-Cascading erfasst das Parallelitätsmuster des Wiederverkaufs. Aber es ist nur eine Schicht, und ein sorgfältiger Wiederverkäufer, der Ihre Schwellenwerte kennt, kann gerade darunter bleiben. Sie benötigen ergänzende Kontrollen.

Verbindungs-/IP-Limits und Dynamische-IP-Warnungen

Pro-Konto-Verbindungslimits begrenzen, wie viele gleichzeitige TCP-Verbindungen ein Konto aufrechterhalten kann. Für die meisten Einzelempfänger-Clients sollte dies 1 oder 2 sein. Ein Wiederverkäufer, der 10 Clients versorgt, benötigt 10 Verbindungen — selbst wenn sie die ECM-Rate verschleiern, verrät die Anzahl der Verbindungen sie.

Aber verwenden Sie keine Quell-IP-Limits als Ihre primäre Missbrauchskontrolle. Dynamische IPs ändern sich. CGNAT bedeutet, dass mehrere legitime Benutzer eine IP teilen. Ein Client, der reist oder mobil ist, ändert regelmäßig die IP. IP-basierte Sperren schaden echten Benutzern mehr als entschlossenen Missbrauchern, die wissen, wie sie sich erneut verbinden können. Verwenden Sie Verbindungen pro Konto als primäre Begrenzung, IP-Limits nur als ergänzendes Signal.

ECM-Rate-Limitierung und Freeze-Zeiten

Die ECM-Rate-Limitierung — die sich von Anti-Cascading unterscheidet — begrenzt die ECMs pro Sekunde, die ein Konto unabhängig von Parallelitätsmustern durchschieben kann. Während Anti-Cascading parallele in-flight-Anfragen betrachtet, schaut die Rate-Limitierung auf den Durchsatz über die Zeit. Zusammen erfassen sie unterschiedliche Umgehungsmuster.

Ein Wiederverkäufer, der seine nachgelagerten Clients sorgfältig taktet, könnte es vermeiden, die Parallelitätslimits auszulösen, indem er die Anfragen staffelt. Aber wenn 12 Clients alle verschiedene Kanäle ansehen, wird die aggregierte ECM/s von diesem einen Konto immer noch erhöht sein. Die Rate-Limitierung erfasst das, wo Anti-Cascading möglicherweise nicht funktioniert.

Derfreeze_timeWert (in Sekunden) bestimmt, wie lange ein Konto nach Erreichen eines harten Limits gesperrt ist. Dreißig Sekunden reichen aus, um die nachgelagerten Clients eines Wiederverkäufers zu stören — sie alle frieren gleichzeitig ein, was auffällt — ohne eine katastrophale Strafe für einen legitimen Client, der versehentlich einen Schwellenwert überschreitet.

Kartenschutz: ECM-pro-Sekunde-Obergrenzen zur Vermeidung von Kartensperren

Das ist die eigentliche Motivation hinter all dem. Offizielle Smartcards haben ECM-Rate-Limits, die auf der Ebene des bedingten Zugangssystems eingebaut sind. Zu viele ECMs zu schnell drücken und die Karte wird als verdächtig markiert, wird von der Zentrale in der Rate begrenzt oder wird vollständig gesperrt. Kartensperren sind ohne Kontaktaufnahme mit dem Anbieter nicht wiederherstellbar.

Anti-Cascading schützt die Karte indirekt, indem es verhindert, dass ein einzelnes Konto übermäßige Last erzeugt. Aber Sie sollten auch eine harte ECM/s-Obergrenze auf Kartenebene in der Serverkonfiguration festlegen — ein Wert wiemax_ecm_per_second = 12stellt global sicher, dass selbst wenn mehrere Konten gleichzeitig Spitzen erreichen, die Karte niemals mehr als 12 ECMs/s insgesamt sieht. Das ist der tatsächliche Schutz, der eine Sperre verhindert, unabhängig davon, wer die Last verursacht.

Die Kombination aus richtiger Wicardd-Anti-Cascading-Konfiguration, Verbindungslimits pro Konto und ECM-Rate-Obergrenzen auf Kartenebene gibt Ihnen drei unabhängige Schichten. Ein Wiederverkäufer, der eine Umgehung einer Schicht vermeidet, wird wahrscheinlich eine andere auslösen. Und selbst versehentliche Überlastungen von legitimen Benutzern werden erfasst, bevor die Karte Schaden nimmt.