🧒🏿 🧙🏼 🚒 VPN asesino. Acceso remoto adecuado a servidores de batalla ☝🏽 😻 🍉

La opinión expresada en este artículo es la opinión personal del autor. Él enfatiza que puede no coincidir con la opinión de su empleador, sus superiores y el departamento de seguridad.

Una de las mejores cosas de nuestra empresa en términos de infraestructura es cómo implementamos el acceso remoto. Esto es solo magia súper mega protegida. Hablé con muchos de mis compañeros guardias de seguridad y auditores, y parece que accidentalmente inventamos una historia completamente nueva al mezclar soluciones comerciales y nuestro software. Entonces, pensé, sería interesante profundizar en los detalles técnicos de cómo funciona la industria con soluciones de acceso remoto obsoletas y cómo la implementamos.

Buena persona VPN no aconsejará

Comenzaré con una declaración fuerte: todas las VPN son basura .

La VPN, como otras tecnologías digitales, se puede configurar para que si se piratea, el mundo no se acabará. Sin embargo, nadie hace esto ... ¡pero en teoría sí pueden!

En el 99.95% de los casos, la VPN está configurada para:

Crear un puente de red entre el dispositivo (computadora portátil u otro servidor)
... y una red más grande de servidores (por ejemplo, en la nube o en las instalaciones )
... e Internet, protegidos por una capa adicional de encriptación

Esta no es una buena idea. ¿Imagina si un virus se ha asentado en su computadora portátil y se está conectando a través de VPN a una red de servidores de batalla? Ta Dam! El virus ahora tiene acceso LAN a su producción. ¿Qué hay en el escape? Tristeza. Mucha tristeza

Bien, digamos que el caso del virus es descabellado. Pero, ¿qué pasa con el hecho de que un pirata informático puede infiltrarse en la propia VPN, por ejemplo, utilizando una vulnerabilidad dentro del dispositivo o software en el que funciona la VPN? Entonces, ¿habiendo llegado directamente a la red de destino? Este es un asunto serio y lejos de teorizar. Puede leer más en el artículo sobre cómo se usó Heartbleed para capturar VPN utilizando el vector de ataque, del cual advertí directamente en mi blog .

No hace mucho tiempo, una ola de vulnerabilidades de VPN se extendió por todo el mundo, que los ciberdelincuentes utilizaron de inmediato para obtener acceso a las redes objetivo. Pero esto no es sorprendente, ¿verdad? Estos sistemas "miran" directamente en la Red, sin ningún otro mecanismo de protección frente a ellos. Por lo general, las correcciones y parches no se aplican automáticamente e implican mecanismos propietarios controlados por software propietario que se ejecuta en un sistema operativo propietario. Bueno, buena suerte ahí.

¿Es difícil encontrar estos dispositivos VPN? Antes de escribir este artículo, nunca lo intenté, así que no estaba seguro. Aproximadamente media hora en Shodan.io y por favor, algunos resultados importantes de la salida:

Thomson Reuters es una compañía de $ 41 mil millones con 26,000 empleados, la mitad de los cuales proviene de servicios financieros.
SAP Concur es un servicio de gestión de viajes, romperlo daría un montón de datos personales y de pago de todo tipo.
Seguro progresivo : datos personales e información médica personal, junto con algunos datos de pago.
Chevron Phillips Chemical : el nombre habla por sí mismo.

Bueno, esto probablemente no sea muy bueno. Si estas cosas son tan fáciles de encontrar, no parece ser la solución perfecta para ponerlas en línea. ¿Tenemos alguna otra opción?

Cero confianza

Confianza cero [literalmente: “confianza cero”]: en esencia, significa que autoriza cada conexión y no asume que algunas de ellas son confiables porque ya están dentro de su red. Si desea comprender mejor este término y repensar su enfoque hacia los negocios, lea este artículo en Network World (perdón por otro autovergonzoso descarado).

Compramos la solución Okta Advanced Server Access (OASA) para introducir la autorización Zero-Trust en los servidores de batalla.
OASA es genial por tres razones:

1. Esto es solo una envoltura alrededor de la configuración de OpenSSH en esteroides

Bajo el capó, la plataforma OASA es una implementación bien administrada de OpenSSH (el mismo comando ssh en su consola). Y OpenSSH es una solución de administración remota extremadamente probada y segura. Por cierto, desde 2003, OpenSSH no ha tenido una sola vulnerabilidad que podría conducir a un acceso remoto no autorizado en la configuración estándar.
Los puntos de entrada en este esquema son instancias regulares de Amazon Linux 2 EC2. Por lo tanto, el área de ataque es extremadamente pequeña. Recuerde: uno de los principales problemas con el uso de una VPN son las configuraciones de software / SO patentadas que evitan los parches automáticos. La capacidad de actualizar nuestros puntos de entrada de red junto con el resto de la infraestructura es una gran victoria.

2. No hay puentes de red

Como mencioné anteriormente, la mayoría de las VPN están configuradas para crear un puente de red entre un dispositivo de red, como una computadora portátil, y una red de servidores en Internet. Uno de mis puntos más dolorosos en las VPN es que interceptan todo el tráfico de su red. Por supuesto, puede reconfigurar a un comportamiento diferente, pero nuestros clientes y los protocolos de seguridad NIST 800-53 SC-7 (7) generalmente requieren eso.

Este es un buen ejemplo de cómo algunas medidas de seguridad están muy por detrás del desarrollo de la industria. En el mundo de la vieja escuela, VPN podría ser la única capa para cifrar el tráfico. Los auditores a veces creen que sin la protección de VPN enviarán sus datos a través de canales no cifrados.

Afortunadamente, hay una mejor manera. En el modelo OASA, se establece una conexión individualmente entre usted y el servidor. Por ejemplo, en respuesta a la solicitud "Quiero iniciar sesión en la instancia de EC2 i-028d62efa6f0b36b5", su sistema se conecta al punto de entrada de la red y luego al servidor de destino. OASA también protege estas conexiones mediante la emisión de certificados de cliente de diez minutos después de la primera verificación de sus datos a través de SSO , y luego verificando que está en el dispositivo de confianza previsto (y confirmado).

Hay poca libertad para recorrer la red. Un administrador puede ingresar un punto de entrada de red y reenviar puertos a otro destino, pero esta función está deshabilitada de manera predeterminada y debe solicitarse explícitamente al establecer una conexión. Y la mejor parte es que nadie me exige que lleve todo el tráfico a través de la Nube privada virtual, porque esto no se llama una "VPN".

3. Acceso a la red dedicado e IP aleatoria

Estos puntos de entrada de red se implementan por separado para cada Nube privada virtual (por ejemplo, uno para producción, uno para puesta en escena, uno para desarrollo, etc.). Además, cada uno de ellos es monitoreado de cerca por nuestra solución de seguridad, que registra toda la actividad y filtra el tráfico. Si la galleta está dentro de uno de los puntos de entrada, algo tampoco funcionará. En cualquier situación, nuestro esquema de seguridad no permite el acceso a recursos protegidos simplemente porque ya está dentro de la Nube privada virtual.

Uno de mis mecanismos de defensa favoritos apareció por accidente. Cuando comenzamos a configurar los puntos de entrada, cada uno estaba configurado para una dirección IP estática de AWS. Muy rápidamente, descubrimos que estas direcciones IP a veces no estaban vinculadas a instancias EC2 en el momento adecuado, lo que podría conducir a una autoconfiguración incorrecta de OASA. Después de experimentar las delicias de una docena de soluciones diferentes en la producción, no pude soportarlo y simplemente eliminé toda la historia sobre IP estáticas, y funcionó.

OASA solo necesita una IP con conexión a Internet; no tiene que ser conocida de antemano. Cuando el cliente está listo para establecer una conexión, se solicita un GUID único, con la ayuda de la cual se determina la IP:

Usuario: Quiero iniciar sesión para conectarme a vpc-99f2acff
Aplicación de cliente OASA: he definido vpc-99f2acff como un servidor conocido con GUID 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f
Servidor OASA: K 25af5d4f-e657-4583-b0bd-beb1ca4f0c1f se puede acceder en 3.22.198.24, aquí están los certificados
Aplicación cliente OASA: certificados instalados, conexión a 3.22.198.24 a través de SSH ...

Esto significa que cada instancia de nuestra infraestructura de punto de entrada (una publicación separada al respecto para su atención) viene con un conjunto completamente nuevo de direcciones IP. Por lo tanto, los piratas informáticos aleatorios tendrán que buscar una IP entre decenas de millones, y su número aumenta cada día. Desafortunadamente para ellos, esta búsqueda es completamente en vano, gracias a ...

Puerto de empresa golpeando

La anulación de puertos [literalmente: anulación de puertos] es algo que, en principio, nadie usa en el mundo real, pero que es muy divertido de configurar. En resumen, la interrupción de puertos es una secuencia de "golpes" a varios puertos de red cerrados, y si la secuencia se repite correctamente, el puerto "real" se abre a su IP. Elegante, pero poco práctico en grandes proyectos reales.
Me inspiró la idea y pensé en cómo mejorarla. Así nació la solución que llamo Enterprise Port Knocking .

Quería crear un mecanismo que garantizara la cercanía de nuestros puntos de entrada a Internet, hasta que alguien pudiera acceder a ellos. Se suponía que este mecanismo era fácil de usar, confiable y autenticado de una manera existente.
Dibujé la arquitectura del mecanismo y fui con ella a nuestro increíblemente talentoso equipo de ingenieros. Unas semanas después comenzamos.

El servicio es bastante simple y se implementa como una función AWS Lambda, con acceso a través de AWS API Gateway (¡la alegría de la arquitectura sin servidor!) Para un uso fácil y confiable. El mecanismo funciona así:

El usuario se autentica correctamente a través de SSO.
La aplicación omite las cuentas de AWS configuradas en busca de un grupo de seguridad especialmente marcado (concepto de AWS para reglas de firewall)
La aplicación actualiza el Grupo de seguridad, lo que permite el acceso a la dirección IP del solicitante. Una regla en el Grupo de seguridad también almacena la marca de tiempo de agregar.
La tarea cron borra la lista de direcciones IP permitidas cada período de tiempo especificado.

Gracias a esta situación, ahora contamos con una solución de acceso remoto que está completamente cerrada a Internet y requiere autenticación de dos factores a través de nuestra base de datos de usuarios antes de abrir el puerto en el firewall .

¡Y es fácil!

Todavía no he tocado lo simples que son estos mecanismos en funcionamiento. Sé que hay muchos componentes, pero juntos crean una autorización muy simple:

Inicie sesión a través de SSO.
Haga clic en el lanzamiento de Enterprise Port Knocking en el portal SSO.
En el terminal, utilizando el comando SSH, especifique el destino como ID de la instancia EC2 de destino. ¡El sistema OASA es lo suficientemente inteligente como para determinar qué punto de entrada usar y todo lo demás sucede automáticamente!

Todo este sistema es una gran victoria para nuestra infraestructura, para nuestro cumplimiento de todos los acuerdos de seguridad y para la seguridad de nuestros clientes. A los usuarios realmente les gusta lo fácil que es conectarse a nuestros servidores, porque no necesita pasar por una autenticación adicional o recordar qué VPN usar. Y realmente me gusta mi sueño tranquilo. ¡Todos ganaron con el nuevo modelo!

Bueno, excepto por los hackers, por supuesto.

VPN asesino. Acceso remoto adecuado a servidores de batalla