Las solicitudes de conexión se bloquean con SYN_SENT después de algunos intentos.

Question

Trasladamos oficinas y configuramos la infraestructura LAN/WAN en el nuevo lugar.

Cuando inicio conexiones SSH a mi servidor (que está en la nube, no en la LAN), funciona bien para las primeras 3 o 4 solicitudes en intervalos cortos (como 4 llamadas en 5 segundos), las conexiones adicionales se bloquean en el estado SYN_SENT. Todas las solicitudes posteriores se bloquean con SYN_SENT hasta lo que parece un tiempo de espera. Después de eso, volverá a funcionar unas cuantas veces.

No se realizaron cambios en el servidor y diferentes clientes locales se comportan de esta manera. Supongo que la diferencia radica en la infraestructura de TI, no en los dos puntos finales.

¿Qué posibles explicaciones existen para este comportamiento? ¿Dónde debería buscar una solución?

Usamos un firewall Zyxel ZyWall que tuvimos que restablecer. ¿Tiene algún filtro que pueda explicar este comportamiento?

Answer 1

Las reglas de iptables en el servidor tenían una cadena de reglas "anti ssh bruteforce" que utiliza el módulo "reciente" para desconectar conexiones después de que se realizaron 4 intentos en 1 minuto. Esta regla tenía una excepción en la INPUTcadena, para permitir todos los ssh desde nuestra IP facial. A medida que avanzábamos, la IP de la cara cambió y hubo que adaptar la regla. Como referencia, así es como hice esto.

Listar todas las reglas de iptables

# iptables -L --line-numbers

Observe la regla de aceptación en la INPUTcadena, que se configuró para aceptar todas las conexiones ssh desde nuestra dirección IP facial (anterior) y la regla antifuerza bruta que descarta las conexiones ssh después de varios intentos en la SSH_CHECKcadena:

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
...
14   ACCEPT     tcp  --  old.myISP.com      anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num  target     prot opt source               destination
...
3    DROP       all  --  anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source

Editar las reglas en/etc/iptables.rules

Cambiar

-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT

a

-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT

donde 111.222.33.44 es la nueva IP de la cara. Y lea las reglas adaptadas:

 # iptables-restore < /etc/iptables.rules