diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md index f1944be5..6db16715 100644 --- a/docs/28-servidor-de-produccion.md +++ b/docs/28-servidor-de-produccion.md @@ -1928,6 +1928,35 @@ nuevos no llegaban a evaluarse nunca. Se vio contando (`grep -c dport` daba 30 y qué `saddr` salía primero. Por eso `cortafuegos apply-input` **borra la tabla antes de cargar** — usar `nft -f` a pelo se saltea esa mitad. +#### La hora exacta, reconstruida del `access.log` + +El usuario preguntó a qué hora se bloqueó, y el log lo dice sin ambigüedad. Su IP —`45.234.61.160`, +autenticada como `sergio`, **2709 peticiones**— tuvo estos silencios: + +| silencio | desde | hasta | +|---:|---|---| +| **93,2 min** | 16-09 **11:59:37** UTC | **13:32:49** UTC ← cuando vacié los sets | +| 50,1 min | 10:44:58 | 11:35:06 | +| 10,0 min | 11:45:06 | 11:55:05 | + +Los tres son el **`timeout` de 10 minutos del ban disparándose una y otra vez**: cada vez que volvía, +su primera ráfaga lo baneaba de nuevo. `154.197.1.2`, que usa el proxy de forma sostenida pero sin +ráfagas, sólo perdió huecos de 5 minutos. + +🧨 **Y la exención que tenía no servía: su IP no estaba en la red eximida.** La ACL histórica de squid +exime `45.234.60.0/24` y él entra desde `45.234.61.160` — **una red de al lado**. Parecía cubierto y +no lo estaba: la pertenencia se MIDE (`ip in red`), no se deduce del parecido del prefijo. Con el +`/23` que nft dedujo al unir los dos `/24`, ahora sí. + +#### Y la decisión de fondo: en un servicio que YA AUTORIZA, no va límite por tasa + +El uso real de esta caja es **intensivo** —varias sesiones de agente en paralelo, cada una abriendo +túneles a la vez—, y un límite calibrado para «una persona normal navegando» no protege de nada: el +atacante ajusta su ritmo, el usuario no puede trabajar más despacio. Squid ya pide usuario y +contraseña y tiene su ACL; el ban por tasa ahí no agrega seguridad, agrega cortes. Queda apagado +(60000/min, ráfaga 1000: números que ningún cliente real alcanza) y contra un flood queda el tope +GLOBAL `syn_nuevas_por_seg`, que no distingue usuarios ni banea a nadie por ser rápido. + #### Lo que esto enseña del cortafuegos como herramienta Un cortafuegos correcto y un cortafuegos usable no son lo mismo, y la diferencia **no se ve al diff --git a/scripts/servidor/cortafuegos-entrada.ron b/scripts/servidor/cortafuegos-entrada.ron index 257086d7..c4c9d47e 100644 --- a/scripts/servidor/cortafuegos-entrada.ron +++ b/scripts/servidor/cortafuegos-entrada.ron @@ -51,6 +51,12 @@ "201.209.132.56", "201.211.110.96", "181.225.47.111", "186.167.0.0/16", "190.72.0.0/16", "190.74.0.0/16", "190.77.0.0/16", "45.234.60.0/24", + // ⚠ `45.234.61.0/24` TAMBIÉN, y esto es lo que causó el corte del 16-09: el usuario entra + // desde `45.234.61.160` —autenticado como `sergio`, 2709 peticiones— y la ACL de squid sólo + // exime al `.60.0/24`. Una IP de al lado no es la misma red: estuvo **93 minutos sin proxy** + // (11:59→13:32 UTC) más dos cortes previos de 50 y 10 minutos, que son el `timeout` de 10 + // minutos del ban disparándose una y otra vez. + "45.234.61.0/24", ], drop_estados_invalidos: true, icmp_echo_por_seg: 10, @@ -113,13 +119,21 @@ // fuente DESCONOCIDA, no un control de uso. Los usuarios de verdad están en // `confiables` y no llegan nunca a esta regla. Con 300/min y `burst 5` se baneaba solo // un cliente normal. - nuevas_por_min: 1200, ban_timeout_seg: 60, - // ⚠⚠ LA RÁFAGA ES LO QUE LO ROMPIÓ, no la tasa. `limit rate over N/minute burst 5` - // banea a quien abre 6 conexiones DE GOLPE aunque su promedio sea bajísimo, y un agente - // o un navegador detrás de un proxy abre decenas. Medido: `154.197.1.2` —autorizado, con - // contraseña— terminó en `@ban4` y perdió el proxy entero. - rafaga: 200, + // ⚠⚠ EL BAN POR TASA EN ESTE PUERTO ESTÁ EFECTIVAMENTE APAGADO, y es una decisión: + // + // · El servicio ya AUTORIZA: squid pide usuario y contraseña y tiene su propia ACL. + // Un ban por tasa no agrega seguridad, agrega falsos positivos. + // · El uso real de esta caja es INTENSIVO —varias sesiones de agente en paralelo, cada + // una abriendo túneles a la vez—, y un límite calibrado para «una persona normal + // navegando» no le sirve a nadie acá. Medido el 16-09: con 300/min y `burst 5`, el + // usuario principal perdió el proxy 93 minutos seguidos. + // · Lo que SÍ queda contra un flood es el `syn_nuevas_por_seg` global de arriba, que + // no distingue usuarios y no puede banear a nadie por ser rápido. + // + // El tipo exige > 0, así que se apaga con números que ningún cliente real alcanza. + nuevas_por_min: 60000, + rafaga: 1000, ), ], )