Reglas de entrada de SSH y VPN: qué controla realmente la lista de permitidos

Conéctese una vez antes de cambiar una regla y anote si el cliente se cuelga o lo rechazan de inmediato. Esa única diferencia le dice qué decisión descartó el paquete y le ahorra una hora de leer archivos de políticas. El resto del recorrido es corto: el paquete cruza un hook, coincide con una regla y llega a un oyente o no llega. Una lista de permitidos es solo contabilidad alrededor de esos tres hechos.

Siga un intento de SSH hasta el hook de entrada

Un cliente envía un SYN a la dirección del host en el puerto 22, y el núcleo decide si ese paquete es para un servicio local. Si lo es, se ejecuta la ruta de entrada y el conjunto de reglas acepta el paquete o lo descarta. El silencio significa que el SYN murió antes de que el oyente lo viera, mientras que un rechazo rápido significa que algo respondió con un reset. Son veredictos distintos de reglas distintas, y ambos son resultados legítimos.

Confirme después el oyente, porque ninguna regla rescata un servicio que no está. Ejecute ss -ltnp y compruebe que algo está vinculado al puerto y a la familia de direcciones que espera, y luego lea ssh -v en el cliente para ver dónde se detiene.

El reenvío es una decisión aparte

En un servidor VPN el hook más interesante es forward, porque el tráfico del cliente se enruta a través de la máquina en lugar de entregarse a ella. Un host que solo ejecuta su propio cliente VPN necesita un conjunto de reglas mucho menor que uno que reenvía paquetes de otras personas. Mezclar los dos diseños en una sola máquina produce reglas que parecen correctas y no dejan pasar nada.

Escriba la política interior como una pregunta propia: qué direcciones de cliente pueden alcanzar qué destinos a través del túnel. Mantenga la ruta administrativa, como SSH, en la ruta de entrada con su propia restricción de origen. Una regla forward permisiva añadida durante las pruebas es el defecto clásico que sobrevive a la prueba, así que revise todo el conjunto de reglas tras un cambio en lugar de la línea que editó. Abrir el oyente del túnel no es permiso para que cada cliente conectado administre el host.

Descartar y rechazar son acciones, no políticas

La política de una cadena base acepta o descarta, y esa es toda la lista de opciones, como dice la referencia de nftables. El rechazo existe como acción de regla con una respuesta elegida, y por eso escribirlo como política falla tanto en nftables como en iptables. En la práctica, un drop no da al cliente ninguna información, mientras que un reject le entrega un error con el que puede trabajar.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Lea ese esquema como la forma de una decisión y no como un archivo para pegar, ya que los rangos de direcciones son ejemplos. Un reject explícito en el puerto SSH hace que un cliente no autorizado falle en un segundo en lugar de esperar un tiempo de espera, lo que acorta su propia depuración. El silencio disuade el escaneo casual y no le dice absolutamente nada a un usuario autorizado. Elija por servicio y anote por qué, porque de lo contrario la siguiente persona lo cambiará de vuelta.

Conserve el tráfico de control que realmente necesita

Bloquear todo el ICMP es un valor por defecto popular que rompe el descubrimiento de MTU de la ruta, y el síntoma es una conexión que se establece y luego se atasca con paquetes grandes. El descubrimiento de vecinos en IPv6 depende de sus propios tipos de ICMPv6, y descartarlos rompe el enlace antes de que se consulte cualquier regla TCP. Ambos pertenecen a la lista de permitidos como dependencias nombradas y no como permisos generales. Una política que rompe el descubrimiento en silencio es peor que una que admite algo de tráfico de diagnóstico.

Permita los estados established y related para las conexiones que usted inició, y deje que el motor con estado se ocupe de las respuestas. Luego confirme que la ruta de respuesta no está bloqueada más afuera, porque una restricción solo de salida aguas arriba produce el mismo tiempo de espera que estaba a punto de culpar al host.

Demuestre la recuperación antes de retirar la ruta antigua

Mantenga abierta una sesión de consola, aplique el cambio y abra una conexión de gestión completamente nueva desde otro terminal. Una sesión existente no demuestra nada, porque puede sobrevivir a una regla que bloquea cada inicio de sesión nuevo, lo que la convierte en el falso positivo más convincente del trabajo con cortafuegos. Si un sistema de monitorización comprueba el host, añada su dirección de origen antes del cambio y no después de la primera alerta. Después pruebe un paquete grande y uno pequeño para demostrar que el descubrimiento sigue funcionando.

Para un servicio VPN, repita desde un cliente que nunca se haya conectado, porque una sesión reanudada puede reutilizar estado que una nueva debe negociar. Anote el conjunto exacto de reglas que pasó, con una suma de comprobación o una copia, para que una edición posterior se pueda comparar en lugar de adivinar. Coordine con quien posea el orden de las reglas, porque una regla anterior gana en silencio a la que usted añadió.