Configuración Anti-Cascading de Wicardd: Guía de Configuración

Si ejecutas un servidor de intercambio de tarjetas basado en Wicarddintercambio de tarjetas y tu tarjeta física está siendo bombardeada con solicitudes ECM, probablemente alguien esté revendiendo tu línea. Configurar correctamente la configuración anti-cascading de Wicardd es cómo pones fin a eso — o al menos lo haces lo suficientemente costoso como para que deje de valer la pena. Esto no es un simple trabajo de copiar y pegar. Los umbrales importan, la ventana de muestreo importa, y configurarlo incorrectamente expulsará a los clientes legítimos de múltiples sintonizadores antes de que atrape a un revendedor real.

Esta guía repasa las directivas de configuración reales, cómo derivar valores iniciales sensatos y cómo probar sin romper las cosas para los usuarios reales.

Lo que Anti-Cascading Detecta Realmente en Wicardd

La idea central es simple: una línea de suscripción debería producir solicitudes ECM a aproximadamente la misma tasa que un solo receptor las genera. Un receptor DVB-S2 bien comportado envía una solicitud ECM por período de criptografía — típicamente cada 8–10 segundos por flujo activo. Si una cuenta comienza a generar 15 solicitudes ECM en la misma ventana, algo está alimentando múltiples cajas de downstream desde ese único inicio de sesión.

Eso es cascading. Una línea, distribuida a varios clientes, cada uno solicitando claves de descifrado en paralelo. La detección se basa en la concurrencia y el tiempo, no en la identidad. Wicardd no puede probar realmente que alguien esté revendiendo — solo puede ver que el patrón de solicitudes no coincide con un solo receptor.

Cascading vs. Clientes Legítimos de Múltiples Sintonizadores

Una configuración genuina de múltiples habitaciones con un receptor DVB-S2 y dos o tres sintonizadores adicionales generará ECMs paralelos. También lo hará la imagen en imagen. Un cliente grabando un canal mientras ve otro en la misma caja puede fácilmente alcanzar 2–3 solicitudes ECM simultáneas legítimamente.

La diferencia entre eso y un revendedor abusivo es la concurrencia sostenida en altos conteos. Un cliente de dos sintonizadores alcanza un máximo de 2–3 ECMs concurrentes y vuelve a bajar. Una línea en cascada que ejecuta 8–12 cajas de downstream se mantiene constantemente en alta concurrencia. Ese patrón sostenido es lo que apunta el anti-cascading.

Cómo Wicardd Cuenta Solicitudes ECM Paralelas Por Cuenta

Wicardd mantiene un contador de solicitudes por cuenta internamente. Cada solicitud ECM entrante de una cuenta incrementa ese contador; el contador se decrementa a medida que las respuestas salen o a medida que avanza la ventana de tiempo rodante. Lo que configuras es el límite — el número máximo de ECMs no resueltos o en vuelo permitidos por cuenta antes de que el sistema tome acción.

La evaluación es rodante, no de intervalo fijo. Un estallido en el segundo 0 y otro en el segundo 4 están ambos en la ventana si tu intervalo de muestreo es de 10 segundos. Eso es intencional — captura las solicitudes secuenciales rápidas que provienen de un cambio rápido de canales, que de otro modo parecen un cascading de bajo nivel.

Ventanas de Tiempo ECM y Tasa de Solicitudes como Señales de Detección

Dos números definen la detección: la ventana de muestreo (en segundos) y el conteo de solicitudes que activa una bandera dentro de esa ventana. Una ventana de 10 segundos con un umbral de 6 significa: si una cuenta envía más de 6 solicitudes ECM en cualquier intervalo rodante de 10 segundos, Wicardd toma la acción configurada.

Ventanas estrechas atrapan a los abusadores de ráfagas pero producen falsos positivos en los zappers rápidos. Ventanas amplias pierden el comportamiento de ráfagas pero capturan sobrecargas sostenidas. Necesitarás encontrar el equilibrio correcto para tu base de usuarios, por eso es importante establecer una línea base antes de configurar — cubierto en la Sección 3.

Directivas Clave Anti-Cascading en la Configuración de Wicardd

La configuración anti-cascading de Wicardd se encuentra en el archivo de configuración principal y opcionalmente en bloques por usuario/cuenta. La ruta de instalación predeterminada en la mayoría de las configuraciones de Linux es/etc/wicardd.conf. Algunas compilaciones lo colocan en/usr/local/etc/wicardd.conf o en el directorio de instalación comowicardd.cfg. Revisa tu script de inicio o unidad systemd para la ruta exacta que se pasa al demonio — generalmente es el-c argumento.

Localizando el Archivo de Configuración y los Bloques [cuenta]/Usuario

Los ajustes globales anti-cascading se aplican a todas las cuentas a menos que se anulen. Los bloques por usuario te permiten establecer límites más estrictos o más flexibles para inicios de sesión específicos. En la mayoría de las versiones de Wicardd, las definiciones de usuario se ven así:

[USUARIO]

Los valores predeterminados globales van en el[ANTICASCADING] o bloque global equivalente, antes de cualquier definición de usuario. Las anulaciones por usuario en los[USUARIO] bloques tienen prioridad. Si no tienes bloques por usuario y solo usas una lista de usuarios plana, los ajustes globales se aplican a todos.

Estableciendo Límites Máximos de ECM Paralelos / Conexiones Por Usuario

Elmaxecm la directiva limita el número de solicitudes ECM simultáneas en vuelo para esa cuenta. Esta es tu primera línea de defensa. Si la configuras demasiado baja (como 1), un receptor de doble sintonizador no puede funcionar. Si la configuras demasiado alta (como 20), no hace nada útil.

Un punto de partida funcional para un cliente típico de un solo receptor es 3–4. Para un cliente que sabes que tiene una configuración de múltiples habitaciones con hasta 4 sintonizadores, configúralo en 6–8. El umbral anti-cascada es una verificación secundaria que observa la tasa a lo largo del tiempo;maxecm es el límite simultáneo duro.

[ANTICASCADING]

Definiendo el Intervalo de Tiempo de Detección y el Umbral de Solicitud

Eldefault_window valor está en segundos. Eldefault_threshold es el conteo de ECM que, si se excede dentro de esa ventana, activa la acción. Así quewindow = 10 ythreshold = 8 significa: más de 8 ECMs en cualquier período rodante de 10 segundos marca la cuenta.

¿Por qué 8 y no 4? Porque el cambio rápido de canales. Un cliente que cambia de canales rápidamente puede enviar 3–4 ECMs en rápida sucesión mientras el decodificador intenta cada servicio. Dar un pequeño margen por encima de tumaxecm límite simultáneo evita que esos cortos estallidos activen el límite de tasa.

Eligiendo la Acción: Throttle, Freeze o Disconnect

Wicardd típicamente ofrece tres modos de respuesta:

• throttle — los ECMs adicionales más allá del límite se retrasan o se ignoran, el cliente se degrada pero no se corta
• freeze — la cuenta se pausa durantefreeze_time segundos, luego se restaura automáticamente
• disconnect — la conexión se corta inmediatamente, requiriendo que el cliente se reconecte

Comienza conthrottle. Sin duda. El costo de un falso positivo en un cliente legítimo es una imagen degradada — molesto pero recuperable. El costo de una desconexión dura en un cliente legítimo de múltiples sintonizadores es un usuario enojado y una solicitud de soporte. Funciona en throttle durante una semana, lee los registros, luego decide si los infractores sostenidos necesitan escalar a freeze o disconnect.

Después de cualquier edición en el archivo de configuración, reinicia o recarga el demonio. Los cambios no se aplican hasta que el demonio los recoge. En configuraciones de systemd:systemctl restart wicardd osystemctl reload wicardd si se admite una recarga. Un error común es editar el archivo, verificar el comportamiento y preguntarse por qué nada cambió — el demonio todavía está ejecutando la configuración antigua en memoria.

Ajustando Umbrales Sin Prohibir a Usuarios Reales

Aquí es donde la mayoría de las guías fallan. Te dan las directivas y te dejan adivinar los números. El enfoque correcto es medir primero, luego establecer umbrales basados en lo que realmente ves.

Estableciendo tasas normales de ECM por canal y tarjeta

Elige un cliente conocido y bueno: un receptor, un stream, sentado en un canal durante 30 minutos. Observa la tasa de ECM en los registros de Wicardd o en la interfaz de estado (más sobre eso en la Sección 4). Un stream DVB estándar en una tarjeta saludable registrará una respuesta ECM cada 8-10 segundos. Esa es tu línea base: aproximadamente 6 ECM por minuto, o alrededor de 1 ECM por ventana de 10 segundos.

Ahora sabes cómo se ve un solo sintonizador limpio numéricamente. Establece tu umbral para acomodar eso, multiplicado por tu cuenta máxima de sintonizadores esperada, más un margen para zapping y PiP.

Contabilizando los Estallidos de Zapping y PiP/Multi-Sintonizador

El zapping de canales es el principal desencadenante de falsos positivos. Cuando un espectador cambia rápidamente entre varios canales, el decodificador envía solicitudes de ECM para cada uno: a menudo 3-5 en rápida sucesión antes de establecerse en un canal. Estas son solicitudes legítimas, y ocurren en un intervalo de tiempo muy corto.

La imagen en imagen es similar. Dos streams de una caja significan dos streams ECM paralelos. Eso no es abuso: es una característica de los receptores modernos. Tus umbrales necesitan manejar esto sin desencadenar.

Una regla razonable: establece tuanticascade_threshold en (máximo de sintonizadores esperados × 2) + 2, evaluado en una ventana de 10 segundos. Para un cliente con hasta 2 sintonizadores, eso es 6. Para 4 sintonizadores, eso es 10. Esto da espacio para estallidos de zapping mientras aún captura una cuenta que alimenta a 8+ clientes downstream simultáneamente.

Anulaciones por Cuenta para Clientes de Multi-Habitación de Confianza

Si tienes clientes específicos en los que confías: amigos con grandes configuraciones de multi-habitación, tus propias cajas de prueba, dales anulaciones explícitas por usuario en lugar de aumentar el umbral global para todos.

[USUARIO]

De esta manera, tus excepciones de alto umbral no crean cobertura para abusadores reales que utilizan cuentas predeterminadas. Todos los demás permanecen en el límite global más estricto.

Ten cuidado con los clientes CGNAT. Un usuario en un NAT de grado de operador comparte una IP pública con docenas de otros suscriptores. Los límites basados en IP los marcarán injustamente, pero los límites de concurrencia de ECM funcionan bien porque están vinculados al inicio de sesión de la cuenta, no a la IP de origen. Ten eso en cuenta al establecer límites de conexión e IP junto con la anti-cascada.

Verificando que Funciona: Registros, Contadores y Pruebas en Vivo

Configúralo, luego demuéstralo. No asumas que la configuración está funcionando solo porque está en el archivo y reiniciaste el daemon.

Leyendo los Golpes de Anti-Cascada en el Registro de Wicardd

La ruta del registro se establece en la configuración: busca unlogfile olog_pathdirectiva, que a menudo apunta a/var/log/wicardd.log o/tmp/wicardd.log. Cuando se activa la anti-cascada, verás una entrada con el nombre de la cuenta, el conteo de ECM que la activó, la ventana en la que se evaluó y la acción tomada. Se ve aproximadamente así:

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

Si no estás viendo estas entradas, o bien la función no está habilitada, el nivel de registro es demasiado bajo, o el daemon no recargó la configuración. Verifica tu configuración de verbosidad de registro: la mayoría de las compilaciones tienen unaloglevel odebugdirectiva; configúralo en al menos 2 o INFO durante la configuración inicial.

Observando el Estado en Vivo/Interfaz Web para Cuentas Marcadas

Wicardd típicamente expone una interfaz de estado en un puerto local: a menudo TCP 8080 o un puerto de interfaz web similar configurado en el[ESTADO]bloque. Esto muestra conexiones activas por cuenta, ECM/s actuales y banderas. Es más útil que seguir los registros cuando deseas una vista en tiempo real de quién está alcanzando los límites.

Ordena por tasa de ECM en la vista en vivo. Una cuenta en cascada estará en la parte superior con una tasa desproporcionada en comparación con todos los demás. Un solo receptor limpio ni siquiera parecerá sospechoso al lado de una cuenta que empuja 20+ ECM/s.

Prueba Controlada: Simular Solicitudes Paralelas para Confirmar el Desencadenamiento

La forma más limpia de verificar es una prueba controlada. Toma una cuenta de repuesto: no una que usen clientes reales — y apunta dos o tres receptores a ella simultáneamente. O usa una herramienta de prueba que pueda enviar solicitudes ECM paralelas a la misma cuenta. Dentro de tu ventana de muestreo configurada, el contador debería activarse y deberías ver la acción de limitación o congelación en los registros.

Luego prueba lo negativo: un solo receptor en su propia cuenta con un comportamiento de zapping normal nunca debería desencadenar. Observa los registros durante 10-15 minutos de uso real con cambios de canal. Si ves algún golpe en una cuenta de un solo receptor, tu umbral es demasiado bajo: súbelo o amplía la ventana.

No endurezcas los umbrales después de un día de registros. Ejecuta la configuración actual durante varios días antes de ajustar. Los patrones de ECM varían según lo que esté al aire, la hora del día y cuán activamente estén zapeando tus clientes. Una semana completa de datos es mejor que unas pocas horas.

Combinando el anti-cascading con otros controles de abuso

El anti-cascading captura el patrón de concurrencia de reventa. Pero es una capa, y un revendedor cuidadoso que conoce tus umbrales puede mantenerse justo por debajo de ellos. Necesitas controles complementarios.

Límites de conexión/IP y advertencias sobre IP dinámica

Los límites de conexión por cuenta limitan cuántas conexiones TCP simultáneas puede mantener una cuenta. Para la mayoría de los clientes de un solo receptor, esto debería ser 1 o 2. Un revendedor que alimenta a 10 clientes necesita 10 conexiones; incluso si disfrazan la tasa de ECM, el conteo de conexiones los delata.

Pero no uses límites de IP de origen como tu control principal de abuso. Las IP dinámicas cambian. CGNAT significa que múltiples usuarios legítimos comparten una IP. Un cliente que viaja o está en móvil cambia de IP regularmente. Las prohibiciones basadas en IP perjudicarán a los usuarios reales más que a los abusadores determinados que saben reconectarse. Usa la conexión por cuenta como el límite principal, los límites de IP como una señal suplementaria solamente.

Limitación de tasa de ECM y tiempos de congelación

La limitación de tasa de ECM — distinta del anti-cascading — limita los ECM por segundo que una cuenta puede enviar independientemente de los patrones de concurrencia. Mientras que el anti-cascading observa solicitudes paralelas en vuelo, la limitación de tasa observa el rendimiento a lo largo del tiempo. Juntas capturan diferentes patrones de evasión.

Un revendedor que dosifica cuidadosamente a sus clientes aguas abajo podría evitar activar los límites de concurrencia escalonando las solicitudes. Pero si 12 clientes están viendo diferentes canales, el ECM/s agregado de esa cuenta seguirá siendo elevado. La limitación de tasa captura eso donde el anti-cascading podría no hacerlo.

Elfreeze_time valor (en segundos) determina cuánto tiempo se suspende una cuenta después de alcanzar un límite duro. Treinta segundos son suficientes para interrumpir a los clientes aguas abajo de un revendedor; todos se congelan simultáneamente, lo cual es notable, sin ser una penalización catastrófica para un cliente legítimo que activó un umbral por accidente.

Protección de tarjeta: límites de ECM por segundo para evitar prohibiciones de tarjeta

Esta es la verdadera motivación detrás de todo esto. Las tarjetas inteligentes oficiales tienen límites de tasa de ECM integrados a nivel del sistema de acceso condicional. Envía demasiados ECM demasiado rápido y la tarjeta se marca como sospechosa, se limita la tasa por el headend, o se prohíbe por completo. Las prohibiciones de tarjeta no son recuperables sin contactar al proveedor.

El anti-cascading protege la tarjeta indirectamente al evitar que cualquier cuenta individual genere una carga excesiva. Pero también deberías establecer un límite duro de ECM/s a nivel de tarjeta en la configuración del servidor — un valor comomax_ecm_per_second = 12 globalmente asegura que incluso si múltiples cuentas alcanzan picos simultáneamente, la tarjeta nunca vea más de 12 ECM/s en total. Esa es la protección real que previene una prohibición, independientemente de quién esté causando la carga.

La combinación de una configuración adecuada de anti-cascading de Wicardd, límites de conexión por cuenta y límites de tasa de ECM a nivel de tarjeta te da tres capas independientes. Un revendedor que evade una probablemente activará otra. Y incluso la sobrecarga accidental de usuarios legítimos se captura antes de que la tarjeta sufra daños.