Regra de EC2 só para VPN: todos os grupos de seguridade asociados deben coincidir

Engadese unha regra de entrada para o grupo de clientes VPN, non se elimina nada e o servizo segue sendo accesible desde internet. Nada está roto. Un grupo de seguridade non ten unha anulación, unha prioridade nin unha denegación final contra a que a regra estreita poida gañar. Cada grupo asociado á instancia achega os seus propios permisos a un conxunto combinado, e a regra ampla que esqueceu segue nese conxunto. Converter a instancia en só VPN significa auditar todos, non engadir a un unha regra que soe mellor.

Escriba o servizo antes de escribir a regra

Comece polo destino exacto, o protocolo e o porto, e a interface de rede na que o servizo realmente escoita. Unha instancia con varias interfaces ou varios servizos nun porto necesita a auditoría por interface, porque os grupos asociados poden ser distintos. Despois determine que enderezo de orixe recibe realmente esa interface para un usuario VPN, en lugar do enderezo que o cliente mostra na súa propia xanela de conexión.

Eses dous enderezos diverxen máis a miúdo do que a xente espera en canto interveñen a tradución e o encamiñamento.

Tres modelos de orixe, tres regras distintas

Con acceso privado encamiñado, a instancia recibe o grupo de clientes ou o rango corporativo, segundo como se encamiña e se traduce a ruta. Cun endpoint público alcanzado a través da saída corporativa, a instancia ve en cambio o enderezo NAT corporativo, e só se ese destino usa realmente a ruta VPN, xa que o túnel dividido pode deixalo nunha conexión doméstica. Cun endpoint Client VPN xestionado, aplícase o modelo documentado de asociación e rede de destino, e o enderezo do cliente procede do CIDR de cliente configurado.

O que non funciona é referenciar unha pasarela VPN como orixe dun grupo de seguridade. As referencias de grupo coinciden con interfaces de rede elásticas dentro da VPC ou dunha rede emparellada, e unha pasarela que reenvía paquetes non é unha delas.

Lea a unión en todos os grupos asociados

Abra a instancia, atope a súa interface de rede e enumere cada grupo de seguridade asociado. Para cada un, revise cada regra que cubra o seu protocolo e porto, incluídos rangos de portos amplos e ambas as familias de enderezos. Unha regra IPv4 de 0.0.0.0/0 non o exime de comprobar ::/0, e unha regra que permite todo o tráfico oculta por completo a cuestión do porto. Só despois dese inventario pode dicir cal é o permiso efectivo para o servizo.

A referencia de regras de AWS describe os grupos de seguridade como só-permitir e afirma que as regras de todos os grupos asociados se agregan, que é todo o mecanismo detrás deste fallo.

As ACL de rede son unha política aparte e sen estado con entradas ordenadas de permiso e denegación, e avalíanse na subrede, non na instancia.

Non responda cun muro de denegacións

Engadir unha denegación NACL para toda a subrede co fin de imitar un cortalumes ao que está acostumado é a ferramenta equivocada e arriscada. As entradas NACL están ordenadas e non teñen estado, así que unha denegación colocada por riba dun permiso existente rompe en silencio tráfico non relacionado, incluído o camiño de volta das sesións que intentaba conservar. Corrixa o permiso amplo do grupo de seguridade no grupo que o posúe e despois deixe a ACL en paz, agás que forme parte real do deseño.

Quitar un enderezo público da instancia é unha garantía máis forte, e tamén é un cambio arquitectónico con consecuencias administrativas e de aplicación, non unha caixa nunha lista de permisos.

Probe cunha sesión nova e conserve unha forma de entrar

Antes de retirar calquera permiso existente, confirme unha ruta de administración independente e aprobada, porque a regra que está a piques de eliminar pode ser da que depende a recuperación da súa sesión. Despois probe unha conexión permitida nova desde a VPN e unha conexión denegada nova desde unha ruta de proba autorizada que non sexa VPN. As sesións rastrexadas existentes sobreviven aos cambios de regras de forma que as vellas shells abertas resultan inútiles como proba de aceptación.

Por último, manteña a autorización propia da aplicación. Unha saída corporativa traducida pode representar a centos de persoas, e a admisión na rede nunca identificou a un usuario individual nin ao seu dispositivo.