Curso MIT "Seguridad de sistemas informáticos". Lección 12: Seguridad de red, Parte 3

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: ¿hay algún tipo de firma para dominios de nivel superior inexistentes?

Profesor: Creo que hay. Un dominio de puntos es solo otro dominio e implementa el mismo mecanismo. Por lo tanto, los dominios "dot" y "dot.com" hoy en día usan el DNS SEC, y hay todos estos registros que dicen, por ejemplo, que .in es el nombre de dominio que existe, y el nombre "dot" también existe, y no hay nada más entre ellos. Entonces, en los dominios de nivel superior, todas estas cosas están presentes.



Estudiante: además del peligro de los ataques DoS, ¿por qué nos importa tanto la repetición de nombres de dominio dentro de mit.edu?

Profesor: No lo sé con certeza. De todos modos, AFS tiene un archivo de texto que enumera todos estos nombres de dominio MIT. Pero creo que, en general, algunas empresas se sienten un poco incómodas en este sentido, porque a menudo tienen nombres internos que están en el DNS y que no se pueden dar a personas externas. Creo que, de hecho, esta es un área difusa que nunca se ha formalizado y que no explica exactamente qué garantías proporcionan los usuarios de DNS. Por lo general, las personas suponen que si existe un nombre confidencial, en el caso de DNS no se revelará.

Creo que este es otro lugar donde este sistema no tiene una especificación clara en términos de lo que debería o no debería proporcionar.

Estudiante: ¿es posible establecer el período de validez de una firma resaltándola de alguna manera?

Profesor: estas cosas tienen una fecha de vencimiento, por ejemplo, puede firmar que este conjunto de nombres es válido durante una semana, y luego los clientes, si tienen un reloj sincronizado, pueden rechazar mensajes antiguos firmados.

Entonces, podemos suponer que discutimos los ataques adivinando los números de secuencia TCP SYN. Otro tema interesante con respecto al TCP es el ataque DDoS, que explota el hecho de que el servidor está en algún estado. Si observa este apretón de manos, que se dibujó en la pizarra anteriormente, verá que cuando el cliente establece una conexión con el servidor, el servidor debe recordar el número de serie del cliente SNc. Por lo tanto, el servidor debe admitir cierta estructura de datos en un bloque separado, lo que muestra que este número de secuencia se utiliza para esta conexión.



Este es un tipo de tabla donde se almacena el número de secuencia SN y que la conexión cliente-servidor tiene el número de secuencia SNc. La razón por la que el servidor debe mantener esta tabla es porque el servidor necesita averiguar cuál debe ser el número de secuencia SNc correcto más adelante, por ejemplo, SNc + 1. Además, el servidor también necesita almacenar números de SN, que son mucho más importantes, ya que le muestran al servidor que la conexión se establece con el "tipo correcto".

El problema es que esta tabla no tiene borde real. De esa manera, puede obtener paquetes de alguna máquina sin siquiera saber quién los envía. Simplemente obtiene un paquete que se parece a C-> S con una dirección de origen que dice ser C. Para aceptar potencialmente esta conexión desde esta dirección IP, debe crear una entrada en la tabla. Además, estos registros existen desde hace mucho tiempo, porque, quizás, alguien establece una conexión con usted desde un lugar muy distante y al mismo tiempo se pierden muchos paquetes. En el peor de los casos, puede tomar, por ejemplo, un minuto hasta que alguien termine este protocolo de enlace TCP. Por lo tanto, debe mantener este estado en la pila TCP durante un tiempo relativamente largo, y no hay forma de adivinar si será válido o no.

Por lo tanto, el ataque DoS más común contra la mayoría de las pilas TCP que la gente ha creado es la transmisión simple de una gran cantidad de paquetes. Si soy un atacante, solo envío una gran cantidad de paquetes SYN a un servidor específico y hago que desborde esta tabla.

El problema es que, en el mejor de los casos, un atacante simplemente usa la misma dirección IP de origen. En este caso, simplemente puede decir que a cada cliente solo se le permiten dos entradas, o algo así. Y luego el atacante puede usar un máximo de 2 dos entradas en la tabla.

El problema, por supuesto, es que un atacante puede falsificar las direcciones IP de los clientes y hacer que se vean al azar. Entonces será muy difícil para el servidor distinguir quién está tratando de establecer una conexión con él: un atacante o algún cliente del que el servidor nunca haya oído hablar antes.

Entonces, si observa un sitio que debería aceptar conexiones desde cualquier parte del mundo, este será un gran problema. Porque denegas el acceso a todos o deberías poder almacenar el estado para la mayoría de los intentos de conexión falsos.

Por lo tanto, este es un problema tanto para TCP como para la mayoría de los protocolos que permiten un tipo de inicio de conexión, en el que el servidor debe guardar el estado. Pero hay algunas soluciones implementadas en TCP de las que hablaremos en un segundo, y tratarán de resolver este problema, que se llama SYN Flooding en TCP.



En general, este es un problema que debe tener en cuenta y tratar de evitar en cualquier protocolo que esté desarrollando. Debe especificar que el servidor no debe guardar el estado hasta que pueda autenticar e identificar al cliente. Porque solo después de la autenticación del cliente se puede decidir si se permite la conexión, por ejemplo, solo una vez, en cuyo caso el servidor no necesita guardar el estado para esta conexión.

El problema es que usted garantiza la preservación del estado incluso antes de saber quién se está conectando con usted. Veamos cómo podemos contrarrestar el ataque de inundación SYN Flooding, que es que el servidor está acumulando demasiado estado.

Podría cambiar TCP nuevamente, por ejemplo, solucionarlo con bastante facilidad con criptografía u otra cosa, o cambiar lo que es responsable de guardar algún estado. Pero el hecho es que necesitamos usar TCP tal como está. ¿Podríamos resolver este problema sin modificar el protocolo TCP existente?

Esto, de nuevo, es un ejercicio para tratar de descubrir exactamente qué trucos podríamos realizar, o más bien, qué suposiciones podríamos dejar solos y seguir cumpliendo con el formato de encabezado TCP existente al trabajar con ellos.

Y el truco es encontrar una forma inteligente de hacer un servidor sin estado, para que no tenga que almacenar esta tabla en la memoria. Esto se puede hacer eligiendo cuidadosamente los SN, es decir, en lugar de la fórmula que consideramos anteriormente y donde tuvimos que agregar esta función, elegiremos los números de serie de una manera completamente diferente. Le daré la fórmula exacta, y luego hablaremos sobre por qué es realmente interesante y qué buenas propiedades tiene.

Si el servidor detecta que está sufriendo un ataque de este tipo, pasa al modo en el que selecciona SN utilizando la fórmula con la misma función F que consideramos antes.



Esta función tiene la dirección IP de origen, la dirección IP de destino, las mismas cosas que antes: puerto de origen, puerto de destino, marca de tiempo y clave. Y vamos a combinar esta función con una marca de tiempo, más bien "de grano grueso", de unos pocos minutos de tamaño. Hay una separación entre estas dos partes del encabezado: la función y la marca de tiempo, que no necesita muchos bits. Olvidé cómo funciona exactamente este protocolo en una computadora real, pero puedes imaginar que la marca de tiempo toma 8 bits, y el resto de la fórmula del número de secuencia es de 24 bits.

Entonces, ¿por qué es un buen plan? ¿Qué está pasando aquí? ¿Por qué se necesita esta extraña fórmula? Debes recordar lo que intentamos obtener de los números de serie. Aquí suceden dos cosas.

El primero es la protección contra paquetes duplicados. Quedaba en la placa un circuito con este número de serie de estilo antiguo, al que agregamos una función para evitar la duplicación de paquetes de conexiones anteriores.



Resulta que las personas no pudieron encontrar una mejor manera de protegerse de ataques como SYN Flooding, excepto para usar este plan de acción, que funciona bien en algunas situaciones. Era un plan, pero otro plan era una función con marca de tiempo en la que abandonamos este componente del viejo estilo. En cambio, nos centraremos en asegurarnos de que si alguien nos proporciona este número de secuencia ACK (SN) en respuesta al paquete, esa persona será el cliente "correcto".

Recuerde que para evitar ataques de suplantación de IP, confiamos en este valor (SN). Después de todo, si el servidor envía este valor de SN al cliente en el segundo paso, esperamos que solo este cliente pueda enviarnos el valor de SN corregido en el tercer paso, completando la conexión.

Es por eso que tenía que almacenar este número de serie en una tabla, porque de lo contrario, ¿cómo podría saber si esta es una respuesta real o falsa? La razón para usar esta función F es que ahora no podemos guardar esta tabla en la memoria.

En cambio, cuando se muestra el intento de conexión, que se muestra en el primer paso, en el segundo paso calculamos los SN utilizando esta fórmula y simplemente lo enviamos de vuelta al cliente que desea contactarnos, y luego nos olvidamos de esta conexión.



Luego, cuando llega el tercer paquete y su valor (SN) corresponde a lo que esperamos ver, significa que alguien recibió nuestra respuesta en el segundo paso y finalmente nos la envió. Finalmente, después de este tercer paso, podemos guardar el registro real de esta conexión TCP en la memoria. Esta es una forma de diferir la persistencia del servidor hasta que el cliente envíe el valor exacto del número de serie. La construcción de tal construcción hace posible verificar que el cliente envió al servidor exactamente la respuesta que se espera de él, y no algún valor arbitrario.

Estudiante: ¿SNc solo dura un tiempo limitado?

Profesor: sí, el servidor no almacena el valor SNc de forma permanente, y esto no es demasiado bueno. No mostré esto en el diagrama, pero aquí al final de la tercera línea hay un campo que muestra que este paquete no tiene datos, pero incluye el número de secuencia SNc solo porque tiene este campo.



Por lo tanto, el servidor puede restaurar el valor de SNc, porque de todos modos el cliente lo incluirá en este paquete. Anteriormente, no importaba, pero ahora es como si fuera relevante. No vamos a verificar nada aquí, pero la existencia de tal campo es en sí misma algo bueno. Sin embargo, tiene algunas tristes consecuencias. Por ejemplo, si usa algunas cosas complicadas que se pueden abusar aquí. Pero esto no es tan malo como desbordar la memoria del servidor con solicitudes de clientes.

Porque lo único que nos preocupa es liberar el almacenamiento de esta tabla y la confianza de que las conexiones se establecen con clientes genuinos. Y si este cliente establece un millón de conexiones conmigo, dejaré de aceptar solicitudes de él, es bastante simple. El problema es que las direcciones falsas son difíciles de distinguir de las direcciones genuinas de los clientes.

Estudiante: ¿necesito mantener una marca de tiempo?

Profesor: sí, ¡hay algo inteligente! Cuando obtenemos el valor de los SN en el tercer paso, necesitamos descubrir cómo calcular los datos de entrada para esta función F para verificar que este valor sea correcto. Por lo tanto, tomamos la marca de tiempo ubicada al final del paquete y la usamos para calcular dentro de la función. Todo lo demás lo podemos restaurar. Sabemos quién nos acaba de enviar el tercer paso y el paquete, tenemos todos estos campos y nuestra clave, que, una vez más, sigue siendo secreta, y la marca de tiempo de los últimos 8 bits de la secuencia. En este caso, puede suceder que excluyamos las marcas de tiempo demasiado antiguas simplemente prohibiendo las conexiones antiguas.

Estudiante: Creo que usas esto cuando eres atacado, solo porque pierdes 8 bits de seguridad, o por alguna otra razón.

Profesor: sí, esto no es muy bueno, tiene muchas propiedades malas. En cierto modo, realmente estamos perdiendo 8 bits de seguridad. Porque ahora la parte indiscutible es de solo 24 bits en lugar de 32.

Otro problema es ¿qué sucede si pierdes ciertos paquetes? En TCP, generalmente se acepta que si se pierde el tercer paquete, entonces el cliente puede estar esperando nada. O, perdón, tal vez el protocolo que ejecutamos sobre esta conexión TCP es un protocolo que supone que el servidor inicialmente tiene la intención de decir algo, así que me conecto y escucho la respuesta. Y en SMTP, por ejemplo, el servidor debería enviarme algo como un saludo a través del protocolo. Supongamos que me conecto al servidor SMTP, envío el tercer paquete, creo que hice todo y solo espero que el servidor me responda, por ejemplo:

"Hola, este es un servidor SMTP, ¡por favor envíeme su correo electrónico!"

Entonces, este tercer paquete puede perderse. En TCP real, el servidor recuerda que en el segundo paso respondió al cliente, pero nunca recibió un tercer paquete de respuesta. Por lo tanto, el servidor enviará al cliente nuevamente un segundo paquete para reiniciar el tercer paquete. Por supuesto, si el servidor no almacena ningún estado, no tiene idea de qué enviar. Esto hace que establecer una conexión sea algo problemático, porque ambas partes esperarán un paso recíproco el uno del otro. El servidor ni siquiera sabe que el cliente está esperando una respuesta de él, y el cliente está esperando la respuesta del servidor, aunque no va a responder porque no almacena el estado. Por lo tanto, esta es otra razón por la cual no utiliza el modo productivo del servidor constantemente.

Estudiante: también puede tener pérdida de datos si establece dos conexiones de muy corta duración desde un host inmediatamente una tras otra.

Profesor: sí, por supuesto. Otra cosa es que nos negamos a usar este viejo estilo de número de secuencia ISN, que aumentó la independencia de estas conexiones múltiples en poco tiempo entre sí. Creo que hay una serie de compromisos aquí, acabamos de hablar de tres de ellos, por lo que hay algunas razones más para preocuparse.

Si pudiéramos desarrollar un protocolo desde cero, esforzándonos por lo mejor, podríamos tener un buen volumen separado de 64 bits para la función F y un volumen de 64 bits para la marca de tiempo, y luego podríamos usarlo constantemente, sin renunciar Todas estas cosas bonitas.

Estudiante: ¿los SN en el segundo y tercer paso deben ser los mismos?

Profesor: por supuesto, porque de lo contrario el servidor no podrá concluir que este cliente recibió nuestro paquete. Si el servidor no verifica que este SN tiene el mismo significado que antes, entonces podría ser aún peor, porque podría simular una conexión desde una dirección IP arbitraria en el primer paso, y luego obtener esta respuesta en el segundo paso. O incluso no obtendría esta respuesta porque está dirigida a una dirección IP diferente. Luego, en el tercer paso, establezco una conexión desde otra dirección IP. En este caso, el servidor admitiría la conexión establecida, esperaría a que envíe datos, y así sucesivamente.



Estudiante: pero la marca de tiempo será diferente, ¿verdad? ¿Cómo puede el servidor contar esto usando una nueva marca de tiempo si no almacena el estado?

Profesor: como dije, estas marcas de tiempo son bastante "de grano grueso" y se clasifican en minutos. Si se conecta en el mismo minuto, entonces todo está en orden, si se conecta en el borde del minuto, esto es una lástima.

Otro problema con este circuito es que es imperfecto en muchos sentidos. Pero la mayoría de los sistemas de trabajo, incluido Linux, tienen formas de detectar demasiadas entradas en esta tabla. Y cuando ocurre la amenaza de su desbordamiento, el sistema cambia a otro esquema.

Estudiante: si un atacante controla una gran cantidad de direcciones IP y hace lo que usted dijo, incluso si cambia ...

Profesor: sí, realmente puedes hacer poco. La razón por la que este plan nos importó tanto fue porque queríamos filtrar o distinguir de alguna manera entre los atacantes y los "buenos". Si un atacante tiene más direcciones IP y solo controla más máquinas que los buenos, puede conectarse a nuestro servidor, solicitar varias páginas web o mantenerse en contacto.

Y luego será muy difícil para el servidor determinar si se reciben solicitudes de clientes legítimos, o si es solo un atacante que conecta los recursos del servidor. Entonces tienes toda la razón. Este esquema solo funciona si el atacante tiene una pequeña cantidad de direcciones IP y quiere lograr un efecto.

Y esto es motivo de preocupación, porque hoy en día algunos atacantes controlan una gran cantidad de computadoras pirateadas por usuarios comunes. Esto les permite crear DoS con una flota de máquinas ubicadas en todo el mundo, y es bastante difícil defenderse de él.

Quiero mencionar una cosa más interesante: la negación del servicio DoS es mala en sí misma, pero aún peor cuando los propios protocolos contribuyen a tal ataque. El atacante lo sabe y ataca principalmente sistemas con protocolos como DNS. El protocolo DNS incluye un cliente que envía una solicitud al servidor, y el servidor envía una respuesta al cliente. Y en muchos casos, el tamaño de la respuesta en bytes es mucho mayor que el volumen de la solicitud.



Preguntaste sobre el servidor mit.edu. , , mit.edu — , mit.edu, , DNS SEC, .

100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .

, . , TCP SYN Flooding, DNS- , . , , « ».

DNS. . , DNS-. , . .

: DNS- …

: , DNS- , - .

: , ?

: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .

, DNS , , , . , .

, , , – , , , . , , . .

DNS- , . , , .

, : «, , »! , , DNS- .

, . - -, . DoS , . , , , , .



, , . , , , .

, , . .

, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .

, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .

, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.



, , , IP- . IP- , , IP- . IP- , . , . , , , IP-. , , .

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

, , , . : , , , , , DoS — . .

Por lo tanto, debe esforzarse por evitar cosas tales como los ataques SYN Flooding y los ataques RST que le permiten desconectar a un usuario de red arbitrario. Estas son cosas que son realmente perjudiciales en un nivel bajo y que son difíciles de solucionar en un nivel alto. Pero más o menos aseguran la integridad y confidencialidad de los datos mediante el cifrado. Hablaremos sobre cómo hacer esto en la próxima conferencia sobre Cerberus.


La versión completa del curso está disponible aquí .

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?