Wicardd Anti-Cascading Setup: Przewodnik konfiguracyjny

Jeśli prowadzisz serwer oparty na Wicarddudostępniania kart i twoja fizyczna karta jest bombardowana żądaniami ECM, ktoś prawdopodobnie odsprzedaje twoją linię. Odpowiednia konfiguracja antykaskadowa Wicardd to sposób, aby to zatrzymać — lub przynajmniej uczynić to na tyle kosztownym, że przestanie być opłacalne. To nie jest prosta praca kopiuj-wklej. Progi mają znaczenie, okno próbkowania ma znaczenie, a błędne ustawienie spowoduje, że legalni klienci z wieloma tunerami zostaną odrzuceni, zanim jeszcze złapią rzeczywistego odsprzedawcę.

Ten przewodnik przeprowadza przez rzeczywiste dyrektywy konfiguracyjne, jak uzyskać rozsądne wartości początkowe i jak testować bez łamania rzeczy dla prawdziwych użytkowników.

Co rzeczywiście wykrywa antykaskadowanie w Wicardd

Podstawowa idea jest prosta: jedna linia subskrypcyjna powinna generować żądania ECM w mniej więcej takim samym tempie, w jakim pojedynczy odbiornik je generuje. Dobrze działający odbiornik DVB-S2 wysyła jedno żądanie ECM na okres kryptograficzny — zazwyczaj co 8–10 sekund na aktywny strumień. Jeśli konto zaczyna generować 15 żądań ECM w tym samym oknie, coś zasila wiele downstreamowych boxów z tego jednego logowania.

To jest kaskadowanie. Jedna linia, rozprzestrzeniona na kilku klientów, z których każdy żąda kluczy deszyfrujących równolegle. Wykrywanie opiera się na współbieżności i czasie, a nie tożsamości. Wicardd nie może faktycznie udowodnić, że ktoś odsprzedaje — może tylko zobaczyć, że wzór żądań nie pasuje do pojedynczego odbiornika.

Kaskadowanie vs. Legalni klienci z wieloma tunerami

Prawdziwa konfiguracja multi-pokojowa z odbiornikiem DVB-S2 i dwoma lub trzema dodatkowymi tunerami wygeneruje równoległe ECM. Tak samo będzie z obrazem w obrazie. Klient nagrywający jeden kanał, podczas gdy ogląda inny na tym samym boxie, może łatwo osiągnąć 2–3 jednoczesne żądania ECM w sposób legalny.

Różnica między tym a nadużywającym odsprzedawcą to utrzymująca się współbieżność przy wysokich liczbach. Klient z dwoma tunerami osiąga szczyt 2–3 równoległych ECM i wraca do normy. Kaskadowana linia działająca na 8–12 downstreamowych boxów utrzymuje wysoką współbieżność nieprzerwanie. Ten utrzymujący się wzór jest celem antykaskadowania.

Jak Wicardd liczy równoległe żądania ECM na konto

Wicardd utrzymuje wewnętrzny licznik żądań na konto. Każde przychodzące żądanie ECM z konta zwiększa ten licznik; licznik zmniejsza się, gdy odpowiedzi są wysyłane lub gdy przesuwające się okno czasowe się przesuwa. To, co konfigurujesz, to sufit — maksymalna liczba nierozwiązanych lub w toku żądań ECM dozwolonych na konto, zanim system podejmie działania.

Ocena jest przesuwająca się, a nie stałointerwałowa. Wybuch w sekundzie 0 i kolejny w sekundzie 4 są oba w oknie, jeśli twój interwał próbkowania wynosi 10 sekund. To jest zamierzone — łapie szybkie sekwencyjne żądania, które pochodzą z szybkiego przeskakiwania kanałów, które w przeciwnym razie wyglądają jak niskopoziomowe kaskadowanie.

Okna czasowe ECM i wskaźnik żądań jako sygnały wykrywania

Dwie liczby definiują wykrywanie: okno próbkowania (w sekundach) i liczba żądań, która wyzwala flagę w tym oknie. Okno 10-sekundowe z progiem 6 oznacza: jeśli konto zgłasza więcej niż 6 żądań ECM w dowolnym przesuwającym się 10-sekundowym okresie, Wicardd podejmuje skonfigurowane działanie.

Wąskie okna łapią nadużywających wybuchów, ale produkują fałszywe pozytywy na szybkich przeskakiwaczach. Szerokie okna pomijają zachowanie wybuchowe, ale łapią utrzymujące się przeciążenie. Będziesz musiał znaleźć odpowiednią równowagę dla swojej bazy użytkowników, dlatego ważne jest, aby ustalić bazę przed konfiguracją — omówione w sekcji 3.

Podstawowe dyrektywy antykaskadowe w konfiguracji Wicardd

Konfiguracja antykaskadowa Wicardd znajduje się w głównym pliku konfiguracyjnym i opcjonalnie w blokach na użytkownika/konto. Domyślna ścieżka instalacji w większości konfiguracji Linux to/etc/wicardd.conf. Niektóre wersje umieszczają go w/usr/local/etc/wicardd.conf lub w katalogu instalacyjnym jakowicardd.cfg. Sprawdź swój skrypt inicjalizacyjny lub jednostkę systemd, aby uzyskać dokładną ścieżkę przekazywaną do demona — zazwyczaj jest to-c argument.

Lokalizacja pliku konfiguracyjnego i bloków [konto]/Użytkownik

Globalne ustawienia antykaskadowe mają zastosowanie do wszystkich kont, chyba że zostaną nadpisane. Bloki na użytkownika pozwalają ustawić ściślejsze lub luźniejsze limity dla konkretnych logowań. W większości wersji Wicardd definicje użytkowników wyglądają tak:

[USER]

Globalne domyślne wartości trafiają do[ANTICASCADING] lub równoważnego globalnego bloku, przed jakimikolwiek definicjami użytkowników. Nadpisania na użytkownika w[USER] blokach mają pierwszeństwo. Jeśli nie masz bloków na użytkownika i używasz tylko płaskiej listy użytkowników, globalne ustawienia mają zastosowanie do wszystkich.

Ustawianie maksymalnych równoległych limitów ECM / połączeń na użytkownika

Themaxecm dyrektywa ogranicza liczbę jednoczesnych wniosków ECM w trakcie przetwarzania dla tego konta. To jest twoja pierwsza linia obrony. Ustaw ją zbyt nisko (na przykład 1), a odbiornik z podwójnym tunerem nie będzie działał. Ustaw ją zbyt wysoko (na przykład 20), a nie będzie to miało żadnego użytecznego efektu.

Dobrą wartością początkową dla typowego klienta z jednym odbiornikiem jest 3–4. Dla klienta, o którym wiesz, że ma konfigurację wielopokojową z maksymalnie 4 tunerami, ustaw ją na 6–8. Próg antykaskadowy to drugorzędna kontrola, która monitoruje wskaźnik w czasie;maxecm to twardy limit jednoczesny.

[ANTICASCADING]

Definiowanie interwału czasu detekcji i progu żądania

Wartośćdefault_window jest podana w sekundach. Wartośćdefault_threshold to liczba ECM, która, jeśli zostanie przekroczona w tym oknie, wyzwala akcję. Więcwindow = 10 ithreshold = 8 oznacza: więcej niż 8 ECM w dowolnym 10-sekundowym okresie rolującym oznacza konto.

Dlaczego 8, a nie 4? Ponieważ szybkie przełączanie. Klient szybko zmieniający kanały może złożyć 3–4 ECM w krótkiej kolejności, gdy dekoder próbuje każdego serwisu. Dając mały bufor powyżej twojegomaxecm jednoczesnego limitu zapobiega tym krótkim wybuchom wyzwalającym limit.

Wybór akcji: Throttle, Freeze lub Disconnect

Wicardd zazwyczaj oferuje trzy tryby odpowiedzi:

• throttle — dodatkowe ECM przekraczające limit są opóźniane lub ignorowane, klient ma gorszą jakość, ale nie jest odłączany
• freeze — konto jest wstrzymywane nafreeze_time sekund, a następnie automatycznie przywracane
• disconnect — połączenie jest natychmiast zrywane, co wymaga ponownego połączenia klienta

Zacznij odthrottle. Bez dwóch zdań. Koszt fałszywego pozytywnego wyniku na legalnym kliencie to pogorszenie obrazu — irytujące, ale możliwe do odzyskania. Koszt twardego odłączenia na legalnym kliencie z wieloma tunerami to zdenerwowany użytkownik i prośba o wsparcie. Pracuj na throttle przez tydzień, przeglądaj logi, a następnie zdecyduj, czy utrzymujący się winowajcy potrzebują eskalacji do freeze lub disconnect.

Po każdej edycji pliku konfiguracyjnego, uruchom ponownie lub przeładuj demona. Zmiany nie będą miały zastosowania, dopóki demon ich nie przechwyci. W konfiguracjach systemd:systemctl restart wicardd lubsystemctl reload wicardd jeśli przeładowanie jest wspierane. Powszechnym błędem jest edytowanie pliku, sprawdzanie zachowania i zastanawianie się, dlaczego nic się nie zmieniło — demon nadal działa na starym configu w pamięci.

Dostosowywanie progów bez zakazywania prawdziwych użytkowników

To jest miejsce, w którym większość przewodników zawodzi. Dają ci dyrektywy i zostawiają cię, abyś zgadywał liczby. Odpowiednie podejście to najpierw pomiar, a następnie ustawienie progów na podstawie tego, co faktycznie widzisz.

Ustalenie normalnych wskaźników ECM na kanał i kartę

Wybierz znanego klienta — jeden odbiornik, jeden strumień, siedzący na kanale przez 30 minut. Obserwuj wskaźnik ECM w logach Wicardd lub interfejsie statusu (więcej na ten temat w sekcji 4). Standardowy strumień DVB na zdrowej karcie będzie generował jedną odpowiedź ECM co 8–10 sekund. To jest twoja baza: około 6 ECMów na minutę, czyli około 1 ECM na 10-sekundowe okno.

Teraz wiesz, jak wygląda pojedynczy czysty tuner liczbowo. Ustaw swój próg, aby to uwzględnić, pomnożone przez oczekiwaną maksymalną liczbę tunerów, plus bufor na zapping i PiP.

Uwzględnianie wybuchów zappingu i PiP/multi-tuner

Zapping kanałów jest głównym wyzwalaczem fałszywych pozytywów. Gdy widz szybko przeskakuje między kilkoma kanałami, dekoder wysyła żądania ECM dla każdego z nich — często 3–5 w szybkim następstwie, zanim zatrzyma się na kanale. To są uzasadnione żądania i mają miejsce w bardzo krótkim oknie.

Obraz w obrazie jest podobny. Dwa strumienie z jednego urządzenia oznaczają dwa równoległe strumienie ECM. To nie jest nadużycie — to cecha nowoczesnych odbiorników. Twoje progi muszą to obsługiwać bez wyzwalania.

Rozsądna zasada: ustaw swójanticascade_threshold na (maksymalna oczekiwana liczba tunerów × 2) + 2, oceniane w 10-sekundowym oknie. Dla klienta z maksymalnie 2 tunerami to 6. Dla 4 tunerów to 10. To daje miejsce na wybuchy zappingu, jednocześnie łapiąc konto zasilające 8+ klientów downstream jednocześnie.

Nadpisy per-account dla zaufanych klientów multi-room

Jeśli masz konkretnych klientów, którym ufasz — przyjaciół z dużymi konfiguracjami multi-room, swoje własne testowe urządzenia — daj im wyraźne nadpisy per-user zamiast podnoszenia globalnego progu dla wszystkich.

[UŻYTKOWNIK]

W ten sposób twoje wyjątki o wysokim progu nie tworzą osłony dla rzeczywistych nadużywców korzystających z domyślnych kont. Wszyscy inni pozostają przy ściślejszym globalnym limicie.

Bądź ostrożny z klientami CGNAT. Użytkownik na NAT klasy operatorskiej dzieli publiczny adres IP z dziesiątkami innych subskrybentów. Limity oparte na IP będą ich niesprawiedliwie oznaczać, ale limity współbieżności ECM działają całkiem dobrze, ponieważ są powiązane z logowaniem konta, a nie z adresem IP źródłowym. Pamiętaj o tym, gdy ustawiasz limity połączeń i IP obok antykaskadowania.

Weryfikacja działania: logi, liczniki i testy na żywo

Skonfiguruj to, a następnie udowodnij. Nie zakładaj, że ustawienia działają tylko dlatego, że są w pliku i zrestartowałeś demona.

Odczytywanie trafień antykaskadowania w logu Wicardd

Ścieżka logu jest ustawiona w konfiguracji — szukajlogfile lublog_path dyrektywy, często wskazującej na/var/log/wicardd.log lub/tmp/wicardd.log. Gdy antykaskadowanie się uruchomi, zobaczysz wpis z nazwą konta, liczbą ECM, która to wyzwoliła, oknem, w którym to oceniano, oraz podjętą akcją. Wygląda to mniej więcej tak:

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

Jeśli nie widzisz tych wpisów, albo funkcja nie jest włączona, poziom logowania jest zbyt niski, albo demon nie przeładował konfiguracji. Sprawdź ustawienie szczegółowości logów — większość wersji ma dyrektywęloglevel lubdebug; ustaw ją na co najmniej 2 lub INFO podczas początkowej konfiguracji.

Obserwowanie statusu na żywo/interfejsu webowego dla oznaczonych kont

Wicardd zazwyczaj udostępnia interfejs statusu na lokalnym porcie — często TCP 8080 lub podobnym porcie interfejsu webowego skonfigurowanym w[STATUS] bloku. Pokazuje to aktywne połączenia na konto, aktualne ECM/s i flagi. Jest to bardziej przydatne niż śledzenie logów, gdy chcesz uzyskać widok w czasie rzeczywistym, kto osiąga limity.

Sortuj według wskaźnika ECM w widoku na żywo. Konto kaskadowe będzie na górze z wyraźnie nieproporcjonalnym wskaźnikiem w porównaniu do wszystkich innych. Pojedynczy czysty odbiornik nawet nie będzie wyglądał podejrzanie obok konta generującego 20+ ECM/s.

Kontrolowany test: symuluj równoległe żądania, aby potwierdzić wyzwolenie

Najczystszy sposób weryfikacji to kontrolowany test. Weź zapasowe konto — nie to, które używają prawdziwi klienci — i skieruj dwa lub trzy odbiorniki na nie jednocześnie. Lub użyj narzędzia testowego, które może wysyłać równoległe żądania ECM do tego samego konta. W obrębie skonfigurowanego okna próbkowania licznik powinien się uruchomić i powinieneś zobaczyć akcję throttlingu lub zamrożenia w logach.

Następnie przetestuj negatyw: pojedynczy odbiornik na swoim koncie z normalnym zachowaniem zappingu nigdy nie powinien wyzwalać. Obserwuj logi przez 10–15 minut rzeczywistego użytkowania z zmianami kanałów. Jeśli zobaczysz jakiekolwiek trafienia na koncie z pojedynczym odbiornikiem, twój próg jest zbyt niski — podnieś go lub poszerz okno.

Nie zaostrzaj progów po jednym dniu logów. Uruchom bieżącą konfigurację przez kilka dni przed dostosowaniem. Wzorce ECM różnią się w zależności od tego, co jest na antenie, pory dnia i tego, jak aktywnie twoi klienci zappingują. Pełny tydzień danych jest lepszy niż kilka godzin.

Łączenie antykaskadowania z innymi kontrolami nadużyć

Antykaskadowanie wychwytuje wzorzec współbieżności w odsprzedaży. Ale to tylko jedna warstwa, a ostrożny odsprzedawca, który zna twoje progi, może pozostać tuż poniżej nich. Potrzebujesz uzupełniających kontroli.

Limity połączeń/IP i zastrzeżenia dotyczące dynamicznych IP

Limity połączeń na konto ograniczają liczbę jednoczesnych połączeń TCP, które konto może utrzymać. Dla większości klientów z jednym odbiornikiem powinno to wynosić 1 lub 2. Odsprzedawca obsługujący 10 klientów potrzebuje 10 połączeń — nawet jeśli ukrywa stawkę ECM, liczba połączeń go zdradza.

Ale nie używaj limitów IP źródłowego jako głównej kontroli nadużyć. Dynamiczne IP zmieniają się. CGNAT oznacza, że wielu legalnych użytkowników dzieli jeden IP. Klient podróżujący lub korzystający z telefonu zmienia IP regularnie. Banowanie na podstawie IP zaszkodzi prawdziwym użytkownikom bardziej niż zdeterminowanym nadużywającym, którzy wiedzą, jak się ponownie połączyć. Użyj limitu połączeń na konto jako głównego ograniczenia, a limity IP jako dodatkowego sygnału.

Ograniczanie stawki ECM i czasy zamrożenia

Ograniczanie stawki ECM — różne od antykaskadowania — ogranicza liczbę ECM na sekundę, które konto może przesłać, niezależnie od wzorców współbieżności. Gdzie antykaskadowanie patrzy na równoległe w trakcie żądania, ograniczanie stawki patrzy na przepustowość w czasie. Razem wychwytują różne wzorce unikania.

Odsprzedawca, który ostrożnie rozkłada swoich klientów downstream, może uniknąć wyzwolenia limitów współbieżności, rozkładając żądania. Ale jeśli 12 klientów ogląda różne kanały, łączna liczba ECM/s z tego jednego konta nadal będzie podwyższona. Ograniczanie stawki wychwytuje to tam, gdzie antykaskadowanie może nie.

Wartośćfreeze_time (w sekundach) określa, jak długo konto jest zawieszone po osiągnięciu twardego limitu. Trzydzieści sekund wystarczy, aby zakłócić klientów downstream odsprzedawcy — wszyscy zamrażają się jednocześnie, co jest zauważalne — bez katastrofalnej kary dla legalnego klienta, który przypadkowo przekroczył próg.

Ochrona kart: Limity ECM na sekundę, aby uniknąć banów kart

To jest prawdziwa motywacja stojąca za tym wszystkim. Oficjalne karty inteligentne mają wbudowane limity stawki ECM na poziomie systemu dostępu warunkowego. Wypchnij zbyt wiele ECM zbyt szybko, a karta zostanie oznaczona jako podejrzana, zostanie ograniczona przez headend lub zostanie całkowicie zbanowana. Bany kart nie są możliwe do odzyskania bez kontaktu z dostawcą.

Antykaskadowanie chroni kartę pośrednio, zapobiegając generowaniu nadmiernego obciążenia przez jakiekolwiek pojedyncze konto. Ale powinieneś również ustawić twardy limit ECM/s na poziomie karty w konfiguracji serwera — wartość taka jakmax_ecm_per_second = 12 globalnie zapewnia, że nawet jeśli wiele kont osiągnie szczyty jednocześnie, karta nigdy nie zobaczy więcej niż 12 ECM/s łącznie. To jest rzeczywista ochrona, która zapobiega banowi, niezależnie od tego, kto powoduje obciążenie.

Połączenie odpowiedniej konfiguracji antykaskadowania Wicardd, limitów połączeń na konto i limitów stawki ECM na poziomie karty daje ci trzy niezależne warstwy. Odsprzedawca, który unika jednej, prawdopodobnie wyzwoli inną. A nawet przypadkowe przeciążenie ze strony legalnych użytkowników zostaje wychwycone, zanim karta odniesie szkody.