Regla de EC2 solo para VPN: todos los grupos de seguridad asociados deben coincidir

Se añade una regla de entrada para el grupo de clientes VPN, no se elimina nada y el servicio sigue siendo accesible desde internet. Nada está roto. Un grupo de seguridad no tiene una anulación, una prioridad ni una denegación final contra la que la regla estrecha pueda ganar. Cada grupo asociado a la instancia aporta sus propios permisos a un conjunto combinado, y la regla amplia que olvidó sigue en ese conjunto. Convertir la instancia en solo VPN significa auditar todos, no añadir a uno una regla que suene mejor.

Escriba el servicio antes de escribir la regla

Empiece por el destino exacto, el protocolo, el puerto y la interfaz de red en la que el servicio realmente escucha. Una instancia con varias interfaces o varios servicios en un puerto necesita la auditoría por interfaz, porque los grupos asociados pueden ser distintos. Después determine qué dirección de origen recibe realmente esa interfaz para un usuario VPN, en lugar de la dirección que el cliente muestra en su propia ventana de conexión.

Esas dos direcciones divergen más a menudo de lo que la gente espera en cuanto intervienen la traducción y el enrutamiento.

Tres modelos de origen, tres reglas distintas

Con acceso privado enrutado, la instancia recibe el grupo de clientes o el rango corporativo, según cómo se enrute y se traduzca la ruta. Con un endpoint público alcanzado a través de la salida corporativa, la instancia ve en cambio la dirección NAT corporativa, y solo si ese destino usa realmente la ruta VPN, ya que el túnel dividido puede dejarlo en una conexión doméstica. Con un endpoint Client VPN gestionado, se aplica el modelo documentado de asociación y red de destino, y la dirección del cliente procede del CIDR de cliente configurado.

Lo que no funciona es referenciar una puerta de enlace VPN como origen de un grupo de seguridad. Las referencias de grupo coinciden con interfaces de red elásticas dentro de la VPC o de una red emparejada, y una puerta de enlace que reenvía paquetes no es una de ellas.

Lea la unión en todos los grupos asociados

Abra la instancia, encuentre su interfaz de red y enumere cada grupo de seguridad asociado. Para cada uno, revise cada regla que cubra su protocolo y puerto, incluidos rangos de puertos amplios y ambas familias de direcciones. Una regla IPv4 de 0.0.0.0/0 no le exime de comprobar ::/0, y una regla que permite todo el tráfico oculta por completo la cuestión del puerto. Solo después de ese inventario puede decir cuál es el permiso efectivo para el servicio.

La referencia de reglas de AWS describe los grupos de seguridad como solo-permitir y afirma que las reglas de todos los grupos asociados se agregan, que es todo el mecanismo detrás de este fallo.

Las ACL de red son una política aparte y sin estado con entradas ordenadas de permiso y denegación, y se evalúan en la subred, no en la instancia.

No responda con un muro de denegaciones

Añadir una denegación NACL para toda la subred con el fin de imitar un cortafuegos al que está acostumbrado es la herramienta equivocada y arriesgada. Las entradas NACL están ordenadas y no tienen estado, así que una denegación colocada por encima de un permiso existente rompe en silencio tráfico no relacionado, incluido el camino de vuelta de las sesiones que intentaba conservar. Corrija el permiso amplio del grupo de seguridad en el grupo que lo posee y luego deje la ACL en paz, salvo que forme parte real del diseño.

Quitar una dirección pública de la instancia es una garantía más fuerte, y también es un cambio arquitectónico con consecuencias administrativas y de aplicación, no una casilla en una lista de permisos.

Pruebe con una sesión nueva y conserve una forma de entrar

Antes de retirar cualquier permiso existente, confirme una ruta de administración independiente y aprobada, porque la regla que está a punto de eliminar puede ser de la que depende la recuperación de su sesión. Después pruebe una conexión permitida nueva desde la VPN y una conexión denegada nueva desde una ruta de prueba autorizada que no sea VPN. Las sesiones rastreadas existentes sobreviven a los cambios de reglas de forma que las viejas shells abiertas resultan inútiles como prueba de aceptación.

Por último, mantenga la autorización propia de la aplicación. Una salida corporativa traducida puede representar a cientos de personas, y la admisión en la red nunca identificó a un usuario individual ni a su dispositivo.