Estoy aprendiendo cómo configurar iptables correctamente para defenderse de las exploraciones de puertos TCP en un VPS basado en Linux alojado. No estoy particularmente interesado en bloquear este tipo de ataque, sino en entender por qué tengo problemas con las conexiones desde mi computadora portátil después de reanudar desde suspensión / hibernación. Esto es lo que tengo actualmente, solo se muestran las reglas relevantes:
# Generated by iptables-save v1.6.0 on Sat Nov 10 15:32:06 2018
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [16:2432]
:LOG_RJC_tcp_rst - [0:0]
:TCP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p tcp -m recent --set --name TCP-PORTSCAN --mask 255.255.255.255 --rsource -j LOG_RJC_tcp_rst
-A INPUT -m limit --limit 20/min --limit-burst 20 -j REJECT --reject-with icmp-proto-unreachable
-A LOG_RJC_tcp_rst -m limit --limit 5/min -j LOG --log-prefix "iptables rjc (TCP rst): " --log-level 7
-A LOG_RJC_tcp_rst -p tcp -j REJECT --reject-with tcp-reset
-A TCP -p tcp -m recent --update --seconds 60 --reap --hitcount 6 --rttl --name TCP-PORTSCAN --mask 255.255.255.255 --rsource -j LOG_RJC_tcp_rst
-A TCP -p tcp -m tcp -m multiport --dports 22022,80,443 -j ACCEPT
COMMIT
# Completed on Sat Nov 10 15:32:06 2018
# Generated by iptables-save v1.6.0 on Sat Nov 10 15:32:06 2018
*raw
:PREROUTING ACCEPT [26:1576]
:OUTPUT ACCEPT [12:1808]
COMMIT
# Completed on Sat Nov 10 15:32:06 2018
En condiciones normales, todo parece funcionar bastante bien: se puede acceder al SSH en el puerto 22022 y al servidor web con y sin SSL. Me conecto a través de un enlace ADSL.
Las cosas van mal cuando se estableció las conexiones se "cortan" al suspender o hibernar mi computadora portátil durante el tiempo suficiente (mínimo 1 h): al reanudar, puedo ver que la protección de escaneo de puertos comienza a detectar mi dirección IP (registrado por la cadena LOG_RJC_tcp_rst ) - afortunadamente, puedo conectarme desde otro host y solucionar el problema. Me resisto a permitir explícitamente que mi dirección IP tout-court porque
- no es fijo (conexión ADSL),
- otros clientes legítimos también podrían verse afectados.
Lo más probable es que no esté entendiendo muchas cosas, pero supongo que cuando el cliente reanuda el servicio, sus conexiones TCP, una vez establecidas y ahora con tiempo de espera, "aumentan" con una ráfaga de paquetes (máx. 6 en 60 años según las reglas anteriores , ¿verdad?) Podría depurarlo a través del volcado de TCP en el lado del cliente, pero ... santa pereza ;-) La opción --reap no ayuda, ya que (de nuevo, supongo) purgaría la lista (mucho tiempo) después El estallido lo ha llenado lo suficiente. Por otra parte, terminar correctamente la conexión del cliente y esperar lo suficiente (horas) hace que sea un "buen tipo" otra vez; de hecho, apague la computadora portátil, vaya a dormir, reinicie al día siguiente, nunca haga es "malo", es decir, el escaneo del puerto TCP nunca se desencadena por nuevos intentos de conexión después de un arranque normal del sistema operativo.
Por lo tanto, aquí están mis preguntas.
-
¿Por qué las conexiones TCP se "reanudan" después de una suspensión de la memoria o hibernación en un cliente de Linux lo suficientemente largo como un intento de escaneo de puerto TCP, según las reglas de iptables anteriores? La explicación sobre lo que hace el kernel de Linux de estas conexiones de red sería beneficiosa.
-
¿Algún cortafuegos escalada de estrategia resolvería el problema? La propuesta citada parece un poco complicada, aunque estaría dispuesto a probar una estrategia más simple de dos niveles (o dos oportunidades), con una lista de alerta que detecte los primeros intentos de mal comportamiento (ráfagas de paquetes de fi) y un rechazar enumera a los delincuentes reales que siguen intentando.