Curso MIT "Seguridad de sistemas informáticos". Lección 12: Seguridad de la red, parte 2

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3
Lección 5: “¿De dónde vienen los sistemas de seguridad?” Parte 1 / Parte 2
Lección 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Lección 7: “Sandbox de cliente nativo” Parte 1 / Parte 2 / Parte 3
Lección 8: "Modelo de seguridad de red" Parte 1 / Parte 2 / Parte 3
Lección 9: "Seguridad de aplicaciones web" Parte 1 / Parte 2 / Parte 3
Lección 10: “Ejecución simbólica” Parte 1 / Parte 2 / Parte 3
Lección 11: "Ur / Lenguaje de programación web" Parte 1 / Parte 2 / Parte 3
Lección 12: Seguridad de red Parte 1 / Parte 2 / Parte 3

Estudiante: quizás todavía tenga un problema de conflicto de intereses porque podría usar 32 bits para las direcciones de pares y tiene muchos puertos para cada uno de ellos. ¿Probablemente tiene un conflicto de números de secuencia de todas estas conexiones que obtiene?

Profesor: resulta que estos números de secuencia son específicos de la dirección IP y el número de puerto del par de origen / destino. Entonces, si estos son puertos diferentes, entonces no interfieren entre sí en absoluto. Específicamente, los puertos tienen números de serie más bajos.



Estudiante: si los números de serie son globales, ¿puede el atacante entrar en la conexión entre otros clientes?

Profesor: sí, este es un buen punto. De hecho, si el servidor aumenta el número de serie, por ejemplo, en 64k para cada conexión, se conecta al servidor, y luego otras 5 personas se conectan a él, y aquí puede organizar un ataque. Entonces, hasta cierto punto, tienes razón, es un poco problemático. Por otro lado, probablemente podría hacerlo para que un paquete de la última línea de S-> A se entregue inmediatamente antes de este paquete en la primera línea de C-> S. Si envía sus paquetes uno tras otro, existe una buena posibilidad de que también lleguen al servidor uno por uno.

El servidor recibirá S-> A y responderá con este número de secuencia (SN). Será diferente a los (SN) en la segunda línea, pero con el número de serie inmediatamente después. Y entonces sabrá exactamente qué número de secuencia (SN) debe incluirse en el tercer paquete de su secuencia.
Por lo tanto, creo que esta no es una forma muy confiable de conectarse al servidor, se basa en suposiciones. Pero si organiza cuidadosamente sus paquetes de la manera correcta, puede adivinar fácilmente la secuencia. O tal vez lo intentes varias veces y tendrás suerte.

Estudiante: incluso si los números se generan por casualidad, debe adivinar uno de los 4 mil millones de números posibles. Esto no es demasiado, ¿verdad? Creo que dentro de un año probablemente podrás entrar en esta red.

Profesor: sí, tienes toda la razón. No debe confiar demasiado en TCP en términos de seguridad. Porque tienes razón, son solo 4 mil millones de conjeturas. Y probablemente pueda enviar muchos paquetes durante el día si tiene una conexión razonablemente rápida.

Así que aquí tenemos una especie de argumento interesante sobre la falta de fiabilidad de TCP, porque solo tenemos 32 bits. No podemos asegurarlo de ninguna manera. Pero creo que muchas aplicaciones que dependen de este protocolo lo suficiente no piensan en absoluto en seguridad, y esto realmente se convierte en un problema.

Pero tienes toda la razón. En la práctica, desea utilizar algún tipo de cifrado además de obtener garantías más serias de que nadie ha falsificado sus datos, ya que utiliza claves de cifrado de más de 32 bits. En la mayoría de los casos, esto sigue siendo efectivo para evitar la manipulación de la conexión TCP.

Veamos ahora por qué es malo si las personas pueden falsificar conexiones TCP desde direcciones arbitrarias.

Una de las razones por las cuales esto es malo es que puede afectar la autorización basada en la dirección IP cuando el servidor verifica de qué dirección proviene la solicitud. Si un servidor decide si permite o rechaza la conexión en función de la dirección IP, esto podría ser un problema para un atacante que falsificó la conexión desde una dirección de origen arbitraria.

Entonces, un ejemplo donde esto era un problema, hoy este problema se resuelve básicamente, es el uso de una familia de comandos r, como rlogin. Solía ​​ser que podría ejecutar algo como rlogin para una computadora en, por ejemplo, athena.dialup.mit.edu. Y si su conexión proviene del host MIT, entonces este comando rlogin tendrá éxito si dice: "sí, soy el usuario de Alice en esta computadora, déjenme iniciar sesión como usuario de Alice en otra computadora". Y esta operación será permitida, ya que todas las computadoras en la red mit.edu son confiables para hacer tales declaraciones.

Tengo que decir que el acceso telefónico nunca tuvo este problema. Este compuesto usó Cerberus desde el principio. Pero otros sistemas, por supuesto, tenían tales problemas. Y este es un ejemplo del uso de una dirección IP en un mecanismo de autenticación de conexión cuando el sistema verifica si el cliente que llama al servidor es confiable. Entonces, lo que solía ser un problema ya no es un problema. Pero confiar en IP todavía parece un mal plan.



Ahora rlogin ya no está en uso, recientemente ha sido reemplazado por el shell SSH seguro, que es un excelente protocolo de capa de red. Por otro lado, hay muchos otros ejemplos de protocolos que dependen de la autorización basada en la dirección IP. Uno de ellos es SMTP. Cuando envía un correo electrónico, utiliza SMTP para hablar con algún servidor de correo para enviar mensajes. Para evitar el spam, muchos servidores SMTP solo aceptan mensajes entrantes de una dirección IP de origen específica. Por ejemplo, el servidor de correo de Comcast solo acepta correo de direcciones IP de Comcast. Lo mismo ocurre con los servidores de correo MIT: solo aceptarán correo de direcciones IP de MIT. Pero teníamos al menos un servidor que no funcionaba como debería, utilizando autenticación IP.

Todo aquí no es tan malo. En el peor de los casos, enviará correo no deseado a través del servidor de correo. Probablemente por eso todavía usan rlogin, mientras que las cosas que le permiten iniciar sesión en una cuenta arbitraria han dejado de usar la autenticación basada en IP.

Entonces, ¿por qué ese mecanismo de autenticación es un mal plan? Como suposición, supongamos que algún servidor usa rlogin. ¿Qué harías para atacar? ¿Qué mal podría pasar?

Estudiante: un atacante puede simplemente ingresar a su computadora, falsificar a un usuario que va a ingresar a la red con su nombre de usuario y obtener acceso a la red.

Profesor: sí, básicamente un atacante se hace cargo de una computadora. Sintetiza datos que parecen un conjunto válido de comandos rlogin que dicen: "Inicie sesión como este usuario y ejecute este comando en mi shell de Unix".

Sintetiza estos datos (SNc + 1), monta todo el ataque y envía estos datos como si un usuario legítimo interactuara con el cliente rlogin, y luego puede continuar.



Bueno, esa es una de las razones por las que no desea que se adivinen sus números de secuencia TCP. Otro problema es que estos ataques de reinicio reinician el ataque. De la misma manera que podríamos enviar un paquete SYN, si conocemos el número de serie de alguien, podemos enviar un paquete de reinicio de la misma manera.

Mencionamos brevemente a un cliente legal que envía un paquete de restablecimiento de conexión falso que un atacante ha establecido. Un atacante también podría intentar enviar paquetes de descarte para una conexión existente si de alguna manera sabe que su número de secuencia está en esa conexión. De hecho, no está claro qué tan grande es este problema.

En algún nivel, debe suponer que todas sus conexiones TCP pueden interrumpirse en cualquier caso y en cualquier momento, es decir, no parece que su red sea confiable. Por lo tanto, tal vez debería esperar una desconexión.

En el caso de que los enrutadores "hablen" entre sí, esta suposición es especialmente crítica. Si tiene muchos enrutadores que se comunican entre sí mediante algunos protocolos de enrutamiento, existen algunas conexiones físicas entre ellos. Pero además de estas conexiones físicas, se comunican a través de un protocolo de red que funciona a través de TCP. De hecho, en cada una de estas conexiones físicas que utilizan los enrutadores para intercambiar información de enrutamiento, se inicia una sesión TCP. Aquí se usa el protocolo BGP, del que hablaremos más adelante.

Este protocolo BGP utiliza el hecho de que si la conexión TCP está activa, la conexión física también está activa. Entonces, si una conexión TCP se rompe, el enrutador cree que la conexión está rota y comienza a contar todas sus tablas de enrutamiento.



Por lo tanto, si el adversario desea organizar algún tipo de ataque de denegación de servicio DoS, puede intentar adivinar los números de serie de estos enrutadores y abandonar estas sesiones. Si la sesión TCP entre los dos enrutadores está desactivada, ambos enrutadores consideran que esta conexión está inactiva y deben volver a contar todas las tablas de enrutamiento, lo que hará que las rutas cambien. Después de eso, el atacante puede restablecer otra conexión, y así sucesivamente.

Por lo tanto, este es un ataque algo alarmante, y no porque viole el secreto de otra persona, etc., al menos no directamente, sino porque realmente causa muchos problemas de acceso para otros usuarios del sistema.

Estudiante: si usted es un atacante y desea organizar un ataque dirigido contra un usuario específico, ¿podría seguir enviando solicitudes para conectarse al servidor en nombre de su dirección IP y obligarlo a restablecer la conexión al servidor?

Profesor: suponga que uso Gmail y desea evitar que reciba cualquier información de Gmail, así que simplemente envíe paquetes a mi máquina, fingiendo que provienen de un servidor de Gmail. En este caso, debe adivinar los números de puerto de origen y destino correctos.

El número de puerto de destino es probablemente 443 porque uso HTTPS. Pero el número de puerto de origen será algo aleatorio de 16 bits. Además, los números de serie variarán. Por lo tanto, si no adivina el número de secuencia que está en mi ventana TCP y que es de decenas de kilobytes, no tendrá éxito.

Entonces tienes que adivinar una buena cantidad de cosas. No hay acceso a Oracle aquí. No puedes pedirle al servidor el número de serie de este tipo. Esta es la razón por la cual esto tampoco funcionará.

Por lo tanto, muchos de estos problemas se han solucionado, incluida esta cosa basada en RST, especialmente para los enrutadores BGP. En realidad hubo dos soluciones divertidas. Una cosa realmente muestra cómo puede explotar cosas existentes o usarlas para solucionar problemas específicos. Utiliza la propiedad de que estos enrutadores se comunican solo entre sí y no con nadie más en la red. Como resultado, si el paquete no llega desde un enrutador ubicado en el otro extremo de la conexión, este paquete se descarta.

La implementación exitosa de los desarrolladores de estos protocolos es un área maravillosa en el paquete llamado "curso de la vida", o TTL. Este es un campo de 8 bits que cada enrutador reduce para garantizar que los paquetes no terminen en un bucle infinito. El valor máximo de TTL es 255 y disminuye aún más.

Entonces, ¿qué estoy haciendo estos protocolos inteligentes? Desechan cualquier paquete con un valor TTL que no sea igual a 255. Porque si el paquete tiene un valor de 255, entonces solo puede provenir de un enrutador en el otro lado de esta conexión. Y si el adversario intenta inyectar cualquier otro paquete en la conexión BGP existente, tendrá un valor TTL menor que 255, porque este valor será reducido por otros enrutadores ubicados a lo largo de la ruta de enrutamiento, incluido este enrutador. Por lo tanto, este paquete simplemente será rechazado por el destinatario.

Así que este es un ejemplo de una combinación inteligente de técnicas retrocompatibles que resuelven este problema tan específico.



Estudiante: ¿El enrutador inferior derecho no envía algo con un TTL de 255?

Profesor: Este es un enrutador físico. Y él sabe que se trata de conexiones separadas, por lo que analiza tanto el TTL como el origen del paquete. Entonces, si el paquete vino del enrutador superior izquierdo, no lo aceptará para una conexión TCP entre él y el enrutador superior derecho.

En su mayor parte, estos enrutadores confían en sus vecinos inmediatos, y este proceso puede controlarse utilizando el mecanismo de enrutamiento de ruta múltiple automático.

Otras soluciones para BGP son implementar alguna forma de encabezado de autenticación, incluido un encabezado de autenticación MD5. Pero en realidad, los desarrolladores se centraron en esta aplicación en particular, para la cual un ataque de reinicio es especialmente crítico.

Este problema persiste hoy. Si hay alguna conexión a largo plazo y quiero interrumpirla, solo tengo que enviar una gran cantidad de paquetes RST, aproximadamente cientos de miles, pero probablemente no 4 mil millones. Porque los servidores en realidad son algo vulnerables a qué número de secuencia aceptan para restablecer.

Puede ser cualquier paquete en una ventana específica. En este caso, el atacante podría romper esta conexión sin mucho esfuerzo. Este sigue siendo un problema para el que no hay una solución realmente buena.

Y lo último que puede suceder debido a la previsibilidad de los números de secuencia es inyectar datos en las conexiones existentes. Supongamos que tenemos un protocolo hipotético similar a rlogin, que en realidad no realiza una autenticación basada en IP, por lo que debe ingresar su contraseña para iniciar sesión.

El problema es que tan pronto como ingrese su contraseña, tal vez su conexión TCP simplemente se establezca y pueda aceptar datos arbitrarios. Entonces, el atacante solo necesita esperar hasta que uno de ustedes inicie sesión en la computadora ingresando su contraseña.

El atacante no sabe cuál es la contraseña, pero tan pronto como establezca una conexión TCP, inmediatamente tratará de adivinar su número de serie e ingresará algunos datos en su conexión existente. Entonces, si puedo adivinar correctamente su número de serie, esto me permitirá fingir que no soy yo, pero ingresó algún comando después de autenticarse correctamente con una contraseña.



Todo esto indica por qué realmente no desea confiar en estos números de secuencia de 32 bits en el sentido de seguridad. Pero veamos qué hacen realmente las pilas TCP modernas para mitigar este problema. Un enfoque del problema que cubriremos en las próximas 2 conferencias es implementar cierto grado de seguridad a nivel de aplicación. En este nivel, utilizaremos la criptografía para autenticar, cifrar, firmar y verificar mensajes sin mucha participación de TCP.

Algunas de las aplicaciones existentes también ayudan a resolver problemas de seguridad, o al menos dificultan que un atacante explote estos problemas. La gente pone esto en práctica hoy, por ejemplo, en Linux y Windows, manteniendo diferentes números de secuencia inicial para cada par de origen / destino.

Por lo tanto, la mayoría de las implementaciones de TCP SYN todavía calculan este número de secuencia ISN inicial de la misma manera que lo hicimos antes. Así que este es un viejo estilo ISN, digamos que sí. Y para generar realmente un número de serie para cualquier conexión en particular, agregamos a este ISN de estilo antiguo un desplazamiento aleatorio de 32 bits. Es decir, le agregamos una función, algo como una función hash o SHA-1, o algo mejor.



Esta función incluye la dirección IP de origen, el número de puerto de origen, la dirección IP de destino, el número de puerto de destino y alguna clave secreta que solo el servidor conoce. Por lo tanto, creamos una buena oportunidad para que cualquier conexión en particular determine la dirección IP y el puerto para el par fuente / destino, al tiempo que conservamos todas las buenas propiedades de este antiguo algoritmo de asignación de números de secuencia de estilo.

Pero si tiene conexiones de diferentes conjuntos de origen / destino, entonces no hay nada que le permita averiguar el valor exacto del número de serie de otro conjunto de conexiones. De hecho, debe adivinar esta clave para calcular este valor.

Espero que el núcleo del sistema operativo del servidor almacene esta clave en algún lugar de su memoria y no se la dé a nadie. Así es como la mayoría de las pilas TCP de hoy resuelven este problema particular en el campo de los números de secuencia comunes de 32 bits. Esto no es demasiado bueno, pero funciona.

Estudiante: ¿ podrías repetir esto de nuevo? Sobre la singularidad de la clave ...

Profesor: cuando mi máquina arranca, o cuando cualquier máquina arranca, genera una clave aleatoria. Cada vez que lo recarga, genera una nueva clave. Esto significa que cada vez que los números de serie de un par de origen / destino en particular cambian con la misma frecuencia de desplazamiento. Por lo tanto, para un par de origen / destino dado, los parámetros de la función son fijos. Entonces sigue la secuencia cuando los números evolucionan de acuerdo con sus números de secuencia iniciales para nuevos compuestos, cambiando de acuerdo con un algoritmo específico. Por lo tanto, se proporciona protección contra la inyección de paquetes antiguos de conexiones anteriores en conexiones nuevas, así como protección contra la reasignación de paquetes.

Lo único para lo que necesitamos este número de serie de la muestra anterior es la elección del algoritmo para evitar problemas con estos paquetes duplicados. Anteriormente, consideramos que si obtiene un número de serie para una conexión A: A -> S: SYN (...), luego puede llegar a una conclusión sobre el número de serie para la conexión ACK (SN).



, 32- , F. , , .

: ?

: , . F, , F , , , .

: , …

: , F - -, . -, , . , , , , . , F .

, TCP, . , , - .

, . , TCP , DNS, . , DNS UDP – . UDP — , , . UDP . , , , . , , . DNS-. DNS?



, DNS- C: C53 -> S53 mit.edu, 53.

S: S53 -> C53 IP-, – .

, , , , . , mit.edu, .

, DNS- . IP-, , . IP- mit.edu IP-. , , , , . , .



, , . IP-. , , DNS- . , , IP- mit.edu.

: , , ?

: , . , , . DNS-, , . 2 . — , 16 . , 16 . ID, 16 , .

, , 32 . , , , , .



, , .

, DNS DNS . , , DNS . , DNS SEC, . , , , DNS- . , , .

origin. DNS , IP-, : „, “. , , , , , , . , , ?

, – DNS- , . , , . -, DNS-, . , DNS SEC, , , DNS- . DNS- , , , – , .

DNS SEC , NSEC. , . , NSEC , foo.mit.edu, goo.mit.edu, , .



, , , , , , „, “.

. , foo.mit.edu -> goo.mit.edu — >…. : » , , gooa.mit.edu". , , .

, DNS . NSEC3, – - , - .

52:00

Curso MIT "Seguridad de sistemas informáticos". 12: « », 3


.

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps hasta diciembre de forma gratuita al pagar por un período de seis meses, puede ordenar aquí .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?