Canal de bloqueo automático

Visión general: qué hace

El bloqueo automático es el canal en segundo plano de InfraGuard que detecta, verifica y bloquea IP atacantes sin intervención humana. No es una página: es un flujo que atraviesa los recolectores, el planificador y el ipset del kernel. Este artículo documenta esa estructura completa.

El canal tiene dos rutas de bloqueo independientes que convergen en un único punto de aplicación (ipset).

Ambas rutas ejecutan una comprobación de lista blanca y de inocencia justo antes de bloquear. Solo sobrevive el abuso confirmado; los candidatos que probablemente sean falsos positivos quedan exculpados. La ruta ② (planificador) está desactivada de forma predeterminada y debe habilitarla un administrador.

Cuándo usarlo

• Active la defensa automática cuando lleguen de forma continua botnets, escáneres y sondeos de fuerza bruta y el bloqueo manual no dé abasto.
• Cuando Detecciones ▸ IA JA3 muestre botnets que rotan su huella, ajuste el umbral para que se capturen automáticamente.
• Cuando un origen dispare repetidamente una alerta de IDS de cierta gravedad (roja/naranja) en Amenazas y quiera bloquearlo automáticamente.
• Cuando revise los motivos de bloqueo que se acumulan en Lista de bloqueo y reputación y exculpe los bloqueos excesivos a través de la Lista blanca.

Disposición

El bloqueo automático no tiene una página propia. Sus puntos de control y observación son:

• Configuración: Política de operaciones ▸ pestaña Ajustes de seguridad ▸ tarjeta Bloqueo automático (interruptor principal, modo, alcance, disparadores, inocencia).
• Observación de resultados: Lista de bloqueo y reputación (bloqueos /24 del recolector + /32 del planificador, motivos, liberación).
• Exculpación: Lista blanca (IP y CIDR manuales o exculpados automáticamente, con caducidad).
• Orígenes de los disparadores: Amenazas (gravedad del IDS), Detecciones (rotación de JA3).

Cómo se usa

1. Ruta ② bloqueo automático del planificador: activar y ajustar

El valor predeterminado es desactivado (autoblock_on=0). Accione el interruptor principal en Política de operaciones ▸ Ajustes de seguridad y, a continuación, ajuste la política.

Modo

Alcance

Disparadores (OR: a un candidato le basta con uno)

① Gravedad del conjunto de reglas IDS   suricata_alert_ct
   WHERE alert_ts >= NOW() - INTERVAL {window_min} MINUTE
     AND severity <= {sev_max}          -- crit=1, warn=2 (Suricata: 1=crítica … 3=baja)
   GROUP BY src_ip HAVING COUNT(*) >= {sev_count}

② Botnet con rotación de JA3   suricata_tls_ct
   WHERE event_ts >= NOW() - INTERVAL {ja3_window_min} MINUTE
     AND ja3_hash IS NOT NULL
   GROUP BY src_ip HAVING COUNT(DISTINCT ja3_hash) >= {ja3_rotation}

La columna de marca de tiempo del disparador de gravedad es alert_ts, mientras que el disparador de JA3 usa event_ts (difieren según la tabla). Al ajustar los umbrales, tenga presente sobre qué columna filtra cada ventana.

Valores predeterminados de la política (OpsPolicy::autoBlock())

Ajuste de la rotación de JA3 (medido): en el mundo real, los infractores que rotan JA3 alcanzan un pico de unos 32 JA3 distintos por sesión /32 (bots de centro de datos o nube, sin GREASE = estables y bloqueables). Por tanto, el valor predeterminado ja3_rotation=50 no captura nada. Para que dispare realmente, bájelo a unos 15–20. Ejecute antes --dry para ver el número de candidatos.

2. Orden de verificación de candidatos (AutoBlockService::run)

Cada IP candidata recopilada debe superar estas comprobaciones en orden antes de ser bloqueada realmente.

1. Exclusión de red interna o propia: se omite si SecurityScope::isInternal($ip) (skipped_internal). Esta decisión une las IP de las instancias registradas (prefijo /24 + IP exacta) con la lista blanca internal_networks de la política de operaciones. La fase de consulta también preexcluye excludePrefixes() mediante NOT LIKE.
2. Exculpación por lista blanca: se omite si infr_whitelist tiene una entrada /32 o /24 activa y no caducada (skipped_wl).
3. Veto por inocencia: se aplica solo a los candidatos exclusivamente de JA3 sin señal contundente (disparador de gravedad). Dentro del presupuesto de reputation_cap, consulta la reputación de AbuseIPDB; si la IP está totalmente limpia (puntuación de abuso 0 Y denuncias 0 Y no es Tor), se añade automáticamente a la lista blanca durante innocent_days (infr_whitelist(source=auto)) en lugar de bloquearse (innocent). Los candidatos por gravedad se saltan esta comprobación y se bloquean de inmediato.
4. Resolución de server_index: global→[0], per_server→resolver la dest_ip de destino mediante ServerIndexResolver::byIp (respaldo [0]).
5. Escritura: upsert en infr_block mediante InfrBlock::updateOrCreate([server_index, cidr], …) con source='schedule', is_active=true y reason='[InfraGuard Auto] …'.

recopilar candidatos (OR) → excluir internos → lista blanca → (solo JA3) veto por inocencia → server_index → escribir infr_block

isSpotless() devuelve false (es decir, bloquear con cautela) si la consulta de reputación falla, no está configurada o queda sin resolver. La exculpación por inocencia es una comprobación conservadora que solo se activa cuando una IP está claramente limpia.

3. Planificador y comando

infr:auto-block es un comando de una sola pasada que evalúa una vez y termina; no es un demonio. El planificador se activa cada minuto, pero el intervalo efectivo es autoblock_interval_min.

# Comprobar la puerta (sin efecto inmediato si la política está desactivada) y luego evaluar y escribir una vez
php artisan infr:auto-block

# Solo contar candidatos, sin escrituras (para ajuste/validación)
php artisan infr:auto-block --dry

# Forzar una ejecución, saltándose la puerta de la política (activación + intervalo)
php artisan infr:auto-block --force

# Suprimir la salida cuando no se ha bloqueado nada (para programación)
php artisan infr:auto-block --quiet-if-ok

Registro en la programación (routes/console.php):

Schedule::command('infr:auto-block --quiet-if-ok')
    ->everyMinute()
    ->withoutOverlapping(2)
    ->onOneServer()
    ->when($is_leader);   // control por nodo líder: un solo nodo en toda la flota

Lógica de la puerta:

• autoblock_on=0 → el comando informa de inmediato de «omitido» (desactivado por defecto, seguro).
• Aún no ha transcurrido el intervalo desde la última ejecución → se omite.
• --force y --dry se saltan la puerta.

Ejemplo de salida:

infr:auto-block — candidatos 12 (sev 3 · ja3 9) · bloqueados 7 · wl-skip 1 · internal-skip 2 · innocent 2

4. Ruta ① bloqueo automático del recolector (Node)

Los recolectores Node de cada host consumen eventos de Suricata y bloquean directamente en blacklist_info con granularidad /24. Esta ruta es independiente del planificador (ruta ②) y se ejecuta siempre.

Las cinco categorías de amenaza de srct_tx:

(A) [HTTP] escáner de URL       .env / .git / wp-login y otras URL con firma de escáner
(B) [HTTP] User-Agent de bot    curl / python-requests / sqlmap y otras firmas de herramientas
(C) [HTTP] sondeo por fuerza    muchas respuestas 4xx en una ventana corta (fuerza bruta de rutas)
(D) [TLS]  anomalía de JA3      muchos JA3, SNI ausente y otras huellas de botnet
(E) [FLOW] anomalía de flags TCP  muchas sesiones de escaneo cortas (escaneo de puertos)

srct_tx también ejecuta el filtrado por lista blanca + la exculpación automática por inocencia justo antes de bloquear: solo los candidatos E-only (escaneo corto en solitario) reciben una consulta de reputación en AbuseIPDB y, si están claramente limpios (0 denuncias · puntuación de abuso 0 · no Tor), se registran como exención de 30 días (infr_whitelist(source=auto)) y se omite el bloqueo. Si hay cualquier señal contundente (A/A2/B/C/D), se bloquea de inmediato. Sus constantes y umbrales se gestionan en Reglas y umbrales.

5. Ruta ③ aplicación: sync_black → ipset

infr_sync_black.mjs se ejecuta periódicamente en cada host y sincroniza ambas listas en el ipset blacklist del kernel.

# Ejecutar por host con su server_index (requiere root)
node infr_sync_black.mjs sv=4

# crontab (cada 5 min, con flock para evitar solapamientos)
*/5 * * * * /usr/bin/flock -n /var/run/sync_black.lock \
  /usr/bin/node /root/server_monitor/infr_sync_black.mjs sv=4 \
  >> /var/log/sync_black.log 2>&1

Comportamiento:

1. Cargar desde blacklist_info (/24) + infr_block (/32) donde server_index IN (0, <sv>) AND is_active/is_use=1.
2. Deduplicación balanced: omitir cualquier /32 cuya /24 padre ya la cubra.
3. Forzar el ipset del kernel a hash:net (recrearlo si es de otro tipo), cargar en un conjunto temporal y luego hacer un intercambio atómico (sin cortes).
4. Asegurar que existe iptables -I INPUT -m set --match-set blacklist src -j DROP (idempotente).
5. Red de seguridad: los prefijos privados (RFC1918), de bucle invertido y de la red propia (HOME_NET_PREFIX) nunca se cargan en el ipset, aunque se cuelen en la base de datos.

sync_black necesita root además de las herramientas del kernel ipset/iptables, y el ipset blacklist debe existir ya en el host de destino:

ipset create blacklist hash:net family inet hashsize 8192 maxelem 65536
iptables -I INPUT -m set --match-set blacklist src -j DROP

Fuentes de datos

Todas las tablas de origen y de registro residen en la conexión legacy_glory (la base de datos compartida por los recolectores y los scripts de aplicación).

Esquema de infr_block (resumen)

Acceso

El bloqueo automático no tiene interfaz de ejecución para el usuario. Las comprobaciones de permisos relevantes son (niveles: demo=1 · staff=5 · admin=10):

Las credenciales que usa el planificador nunca están codificadas en el código: se externalizan a infr_collector / .env. Las credenciales de base de datos de sync_black y los prefijos de la red propia se inyectan igualmente mediante variables de entorno o la sustitución de mezcla de Inventario ▸ Herramientas (sin codificarlas en el código).

Resolución de problemas y preguntas frecuentes

Lo he activado, pero no se bloquea nada.

• Compruebe el número de candidatos con --dry: php artisan infr:auto-block --dry.
• Es probable que el umbral de JA3 sea demasiado alto (50 de forma predeterminada). Los infractores reales rondan los 32, así que bájelo a 15–20.
• Disparador de gravedad: autoblock_severity=crit solo captura sev≤1 (rojo). Para incluir el naranja, establezca warn (sev≤2).
• Si todos los candidatos son internal-skip/wl-skip, revise la lista blanca interna de la Política de operaciones o la Lista blanca.

Los bloqueos no llegan al cortafuegos real.

• Una entrada de infr_block no se aplica hasta que se ejecuta sync_black. Compruebe el cron del host de destino, el argumento sv=<server_index> y que exista el ipset blacklist.
• Con el alcance balanced, una /32 ya cubierta por una /24 padre se deduplica intencionadamente y no se carga por separado (esto es normal).

Se ha bloqueado una IP inocente.

• Regístrela como /32 o /24 en la Lista blanca; quedará exenta a partir del siguiente barrido (libere la fila existente de infr_block desde Lista de bloqueo).
• La exculpación automática por inocencia se aplica solo a los candidatos exclusivamente de JA3. Las IP capturadas por el disparador de gravedad se bloquean con independencia de su reputación, por lo que requieren una exención manual.

Está en per_server, pero los registros aparecen como globales (server_index=0).

• Si la dest_ip de destino no puede resolverse mediante infr_server_index, se recurre de forma segura a [0]. Verifique la correspondencia de IP de recolectores e instancias.

El planificador se ejecuta en varios servidores a la vez.

• El control por nodo líder ->onOneServer()->when($is_leader) garantiza que solo lo ejecute un nodo. Consulte el estado del bloqueo de líder en el panel de observabilidad.

Relacionado

• Política de operaciones: interruptor principal, disparadores y alcance del bloqueo automático (pestaña Ajustes de seguridad)
• Lista de bloqueo y reputación: lista de resultados del bloqueo automático, motivos y liberación
• Lista blanca: IP/CIDR exentos, exención automática por inocencia
• Detecciones ▸ IA JA3: origen del disparador de rotación de JA3
• Amenazas: origen del disparador de gravedad del IDS
• Reputación de IP (AbuseIPDB): consulta de reputación para el veto por inocencia