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

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

Hoy hablaremos sobre la seguridad de la red, en particular, discutiremos un artículo de Stephen Bellovin titulado "Una mirada retrospectiva a" Problemas de seguridad en el conjunto de protocolos TCP / IP "". Este tipo solía trabajar para AT&T, y ahora trabaja en Colombia. Lo interesante de este trabajo es que es relativamente antiguo: tiene más de 10 años y, de hecho, estos son comentarios sobre un artículo que salió una década antes en 1989.

Muchos de ustedes preguntan por qué estudiamos esto si muchos de los problemas descritos allí se resolvieron en las versiones actuales del protocolo TCP.



Es cierto que algunos de los problemas descritos por Stephen ya se han resuelto, y algunos de ellos siguen siendo problemas. Con esto en mente, los clasificaremos y veremos qué sucede. Quizás se pregunte por qué la gente no resolvió todos estos problemas al diseñar TCP. ¿Qué estaban pensando?

Y esto en realidad no está claro. Que piensas ¿Por qué el protocolo TCP no tenía la seguridad necesaria, considerando todas estas consideraciones? Alguna sugerencia?

Estudiante: En ese momento, Internet era un lugar mucho más crédulo.

Profesor: sí, fue literalmente una cita del artículo de este tipo. Sí, en ese momento en general ... creo que se desarrolló un conjunto de protocolos de Internet hace unos 40 años. Los requisitos eran completamente diferentes. Solo era necesario conectar un grupo de sitios relativamente crédulos que se conocían por su nombre a una red común.

Creo que esto sucede a menudo en cualquier sistema que tenga éxito: necesita cambios. Solía ​​ser un protocolo para un pequeño número de sitios, ahora este protocolo cubre todo el mundo. Y ya no se sabe por el nombre de todas las personas conectadas a Internet. No puedes llamarlos si hacen algo malo, y así sucesivamente.

Por lo tanto, creo que esta historia es la misma para muchos de los protocolos que estamos considerando. Y muchos de ustedes están haciendo una pregunta como, "¿qué demonios estaban pensando estos tipos? ¡Esto es tan imperfecto! Pero en realidad, diseñaron un sistema completamente diferente, simplemente lo adaptaron a las necesidades modernas.

Lo mismo, e Internet, como vimos en las últimas semanas, fue diseñado para un propósito completamente diferente. Pero se expandió y teníamos nuevas preocupaciones sobre cómo adaptar este protocolo a los requisitos modernos.

Hay otra cosa que sucedió un poco de repente, que la gente tuvo que sobrestimar la gravedad del problema de seguridad. Solía ​​ser que realmente no entendías todas las cosas por las que debías preocuparte, porque no sabías lo que el atacante podía hacer con tu sistema.



Creo que, en parte, por esta razón, será interesante ver qué sucedió con la seguridad de TCP, qué salió mal, cómo podemos solucionarlo, etc. Como resultado, debemos descubrir qué tipos de problemas deben evitarse al desarrollar nuestros propios protocolos, así como qué constituye un pensamiento adecuado sobre ataques de este tipo. ¿Cómo sabes lo que un atacante es capaz de hacer en tu propio protocolo cuando lo estás desarrollando para evitar tales dificultades?

Bien, dejemos a un lado el preámbulo y hablemos sobre este artículo.

Entonces, ¿cómo debemos pensar en la seguridad de la red? Creo que podríamos comenzar con el primer principio e intentar descubrir cuál es nuestro modelo de amenaza. Entonces, ¿qué puede hacer un atacante en nuestra red?

Probablemente tenga la capacidad de interceptar paquetes, y tal vez pueda modificarlos. Por lo tanto, si está enviando un paquete a través de la red, es aconsejable suponer que algún tipo malo verá su paquete y podrá cambiarlo antes de que llegue a su destino. También puede soltarlo y usar la capacidad de ingresar paquetes personalizados con contenido arbitrario que nunca envió.



Pero más peligrosa es la posibilidad de que los malos interfieran con sus protocolos descritos en el artículo. El atacante tiene su propia computadora, que controla por completo. Incluso si todas las computadoras en las que confía funcionan correctamente, el malo que tiene su propia computadora puede interferir con su protocolo o sistema.

Por lo tanto, si tiene un protocolo de enrutamiento que incluye a muchas personas hablando entre sí, y un poco de escala probablemente no sea práctico para mantener a los malos fuera. Si se está ejecutando un protocolo de enrutamiento con 10 participantes, entonces tal vez pueda llamarlos a todos y luego decir: "Bueno, sí, muchachos, los conozco a todos".

Pero en la escala de Internet hoy en día es imposible averiguar directamente quiénes son los otros miembros de la red que utilizan este protocolo. Entonces, probablemente, algún tipo malo va a participar en sus protocolos o sistemas distribuidos. Por lo tanto, es importante diseñar sistemas distribuidos que, sin embargo, puedan hacer algo razonable con esto.

Bien, ¿cuáles son las implicaciones de todo esto? Creo que revisaremos la lista. Interceptar paquetes es generalmente fácil de entender, no puede enviar datos importantes a través de la red si espera que el malo los intercepte, o al menos no los envíe en texto plano. Quizás deberías encriptar tus datos.



Parece relativamente fácil de entender, aunque aún debe tener esto en cuenta al desarrollar protocolos. La introducción o inyección de paquetes conduce a una gama más amplia de problemas interesantes, que se analizan en este artículo. En particular, los atacantes pueden inyectar paquetes que pueden suplantar paquetes de cualquier otro remitente. Dado que la ruta de transmisión de datos se basa en el uso de IP, el paquete en sí tiene un encabezado que indica la IP de origen del paquete y la IP de destino. Sin embargo, nadie verifica que la fuente sea necesariamente correcta. Actualmente hay algo de filtrado, pero no es perfecto y es difícil confiar en él.

Entonces, en una primera aproximación, un atacante puede insertar cualquier dirección IP dentro como fuente y enviarla al destino correcto. Es interesante descubrir qué puede hacer un atacante con la capacidad de enviar paquetes arbitrarios.

En las semanas anteriores, analizamos los problemas de desbordamiento del búfer en términos de seguridad web. Examinamos cómo un atacante puede usar un error de implementación, como desbordamientos de búfer. Curiosamente, el autor de este artículo no estaba realmente interesado en los errores de implementación; está más interesado en los errores de protocolo.

Entonces, ¿qué tiene de especial esto? ¿Por qué no prestó atención a los errores de implementación, aunque pasamos varias semanas para examinarlos? Por qué importa

Estudiante: porque debemos descartar estos errores al escribir el protocolo.

Profesor: sí, esto es realmente un gran fracaso debido a un error en el diseño del protocolo porque es difícil de cambiar. Entonces, si tiene un error de implementación y tiene memcpy o impresión que no verificó el rango de memoria, no puede notar este error. Pero si tiene una verificación de rango y aún funciona, se pueden evitar los desbordamientos del búfer, por lo que es excelente.

Pero si tiene algún tipo de error en la especificación del protocolo, en cómo debería funcionar el protocolo, entonces corregir dicho error requerirá corregir todo el protocolo, lo que significa un impacto potencial en todos los sistemas que hablan este protocolo. Entonces, si encontramos algún tipo de problema en el protocolo TCP, potencialmente será bastante destructivo. Debido a que cada máquina que use TCP tendrá que hacer cambios, ya que es potencialmente muy difícil hacer que un protocolo modificado sea compatible con la máquina anterior.

Los errores del protocolo TCP por los que Stephen estaba tan preocupado eran fundamentales, por lo que decidió hablar sobre ellos. En el primer ejemplo, observa cómo funcionan los números TCP SN.

Estudiante: esto está un poco fuera de tema, pero tengo curiosidad. Supongamos que encuentra un error en TCP. ¿Cómo le haces cambios? ¿Cómo le dices a todas las computadoras en el mundo que esto necesita ser cambiado?

Profesor : sí, creo que este es un gran problema. ¿Qué hacer si encuentra un error en TCP? Bueno, no está claro qué hacer. Creo que el autor aquí está luchando con esto. Si pudiera rediseñar TCP, muchos de estos errores son relativamente fáciles de solucionar si sabe de antemano qué buscar.

Pero dado que el TCP es bastante difícil de arreglar o cambiar, en última instancia sucede lo siguiente: los desarrolladores intentan encontrar configuraciones compatibles con versiones anteriores que permitan usar las implementaciones antiguas junto con la nueva implementación, o agregue algún campo adicional que haga que la conexión sea algo más segura.



Pero este es un gran problema. Si se trata de algún tipo de problema de seguridad profundamente arraigado en TCP, se convertirá en un gran problema para todos, porque es muy difícil incluso simplemente cambiar a la versión TCP, supongamos que n más 1.

IPv6 puede verse como un ejemplo de que esto no sucede, y sabemos que este problema surgirá durante otros 15 o 20 años. IPv6 ha existido por más de 10 años, pero es difícil convencer a las personas de que se alejen de IPv4. IPv4 es suficiente para ellos, parece funcionar, y piensan que cambiar a un nuevo protocolo de Internet será demasiado costoso. Dicen: "ya nadie habla IPv6, entonces, ¿por qué debería comenzar a hablar sobre este extraño protocolo con el que no hay nadie con quien hablar?" En cualquier caso, este es un tipo de movimiento hacia adelante, pero creo que tomará mucho tiempo. Realmente habrá alguna motivación para la migración, y la compatibilidad con versiones anteriores en este caso ayuda mucho.

IPv6 tiene muchas opciones de compatibilidad con versiones anteriores, por ejemplo, puede hablar con un host IPv4 usando IPv6. Por lo tanto, los desarrolladores están tratando de diseñar todo este soporte, pero aún es difícil convencer a las personas para que actualicen.

Entonces, considerando los números de secuencia TCP, vamos a considerar dos problemas relacionados con el funcionamiento del protocolo de enlace TCP. Así que pasemos un tiempo mirando cómo se establece inicialmente una conexión TCP.

Se envían tres paquetes para establecer una nueva conexión TCP. Nuestro cliente genera un paquete para conectarse al servidor, que dice que aquí está la dirección IP de mi cliente, la envío al servidor. Al mismo tiempo, hay una estructura de encabezado de paquete que consta de diferentes áreas, pero nos interesará el área del número de serie. Aquí tendremos el indicador SYN que dice: "Quiero sincronizar el estado y establecer una nueva conexión", e incluye el número de serie del cliente SNc.



Luego, cuando el servidor recibe este paquete, dice: "el cliente quiere conectarse conmigo, por lo que enviaré el paquete de regreso a esta dirección, sin importar quién diga que está tratando de contactarme". Por lo tanto, el servidor enviará el paquete al cliente, donde incluye su propio número de secuencia de sincronización del servidor SN y el número de confirmación del cliente ACK (SNc). Finalmente, en el tercer paquete, el cliente responde al servidor, confirmando la sincronización y enviando el número de confirmación (SN) del servidor ACK del servidor al servidor. Ahora el cliente puede comenzar a enviar datos.

Por lo tanto, para enviar datos, al comienzo de la conexión, el cliente debe incluir algunos datos en el paquete y adjuntar el número de serie del cliente SNc para indicar que en realidad se trata de datos legítimos del cliente. Señala, por ejemplo, que no se trata de algunos datos de mensajes posteriores que acaban de llegar ahora, porque el servidor perdió algunas de las partes iniciales de los datos.



Por lo tanto, como regla, todos estos números de serie están diseñados para proporcionar la entrega de paquetes. Si el cliente transmite dos paquetes, el que tiene el número de secuencia inicial es el primer dato, el siguiente número de secuencia es el siguiente dato. También es útil para proporcionar algunos requisitos de seguridad.

Antes de eso, di un ejemplo de que estos requisitos están cambiando. Por lo tanto, inicialmente nadie pensó que TCP debería proporcionar ninguna característica de seguridad. Pero entonces el TCP comenzó a usar aplicaciones, y parecían confiar en estas conexiones TCP, creyendo que ningún atacante podría romperlas o que el atacante no podía inyectar datos maliciosos en la conexión TCP existente. Como si de repente este mecanismo, que originalmente estaba destinado solo a ordenar paquetes, comenzara a garantizar cierta apariencia de seguridad para estas conexiones.

Por lo tanto, en este caso, supongo que el problema está relacionado con lo que el servidor podría haber sugerido con respecto a esta conexión TCP. Por lo general, el servidor asume, implícitamente, como puede imaginar, que esta conexión se establece con el cliente deseado en esta dirección IP C, y es natural que lo piense. Pero, ¿hay alguna razón para tal suposición? Si el servidor recibe un mensaje con algunos datos sobre esta conexión cliente-servidor y tiene un número de secuencia C, ¿por qué el servidor concluye que el cliente real envió estos datos?

Estudiante: porque el número de serie es difícil de adivinar.
Profesor: correcto, entonces esto es una especie de cosa implícita, lo que implica que debe haber un número de secuencia SNc correcto. Y para que se establezca esta conexión, el cliente debe tener un número de serie del servidor SN confirmado, y el servidor envía el número de serie del servidor solo a la dirección IP del cliente.

Estudiante: ¿cuántos bits hay disponibles para el número de secuencia?

Profesor: el número de secuencia TCP tiene 32 bits de largo, y aunque este no es un número aleatorio, no es fácil de adivinar, tomaría mucho ancho de banda.

Estudiante: ¿el número de serie es más alto que el número de serie inicial?

Profesor: sí, en principio, estas cosas están aumentando. Por lo tanto, cada vez que envía SYN, se considera 1 byte más que su número de secuencia. Es decir, si en la primera línea tuvimos el argumento (SNc), en la cuarta ya habrá (SNc + 1), y luego la numeración continúa desde aquí. Por lo tanto, si transfiere 5 bytes, el siguiente será el valor (SNc) +6. Simplemente cuenta los bytes que envía, con cada SYN contando 1 byte. La especificación TCP recomienda elegir estos números de serie para que su incremento ocurra a una velocidad aproximadamente fija. Los documentos de trabajo iniciales del protocolo RFC sugirieron que aumente estas cosas en aproximadamente 250,000 unidades más 250,000 por segundo.



La razón por la que esto no fue completamente aleatorio es porque estos números de secuencia se usan realmente para evitar que los paquetes no intervengan o para mezclar paquetes de conexiones anteriores con conexiones nuevas. Cada vez que establece una nueva conexión, elige un número de serie completamente aleatorio. Al mismo tiempo, existe la posibilidad de que si instala una serie de conexiones una y otra vez, un paquete de la conexión anterior tendrá un número de secuencia que es bastante similar al número de secuencia de su nueva conexión y, por lo tanto, el servidor lo aceptará como una parte válida de los datos para la nueva conexión.

Entonces, esto es lo que los desarrolladores de TCP estaban muy preocupados: estos paquetes desordenados o paquetes retrasados. Como resultado, realmente querían que estos números de secuencia fueran una secuencia de tiempo bastante monótona incluso entre compuestos.

Si abro una conexión, puede tener el mismo origen y destino, números de puerto, direcciones IP, etc. Pero desde que establecí esta conexión ahora, y no antes, los paquetes de mensajes enviados anteriormente, espero, no coincidirán con los números de secuencia que tengo para mi nueva conexión. Entonces este fue un mecanismo para evitar la confusión entre conexiones repetitivas.

Estudiante: si no sabe exactamente cuál será el paso de la secuencia del paquete, ¿cómo sabe que el paquete que recibe es el siguiente y no forma parte del anterior que usted ...

Profesor: Como regla, recuerdas el último paquete recibido. Y el siguiente número de secuencia es exactamente el siguiente paquete de la secuencia. Entonces, por ejemplo, el servidor sabe que vi exactamente una parte de los datos de la fecha (SNc +1), luego el siguiente será el paquete SYN (SNc +1), porque el paquete anterior al comienzo de la conexión era SYN (SNc).

Estudiante: entonces, usted dice que cuando establece el número de serie, incluso después de eso, usted ...

Profesor: bueno, por supuesto, estos números de serie, inicialmente, cuando los instala, se seleccionan de acuerdo con algún plan. Hablaremos sobre este plan. Puede pensar que son aleatorios, pero con el tiempo deberían representar una secuencia secuencial de cambios en los números de secuencia iniciales para la conexión.

Pero dentro de una conexión, todo termina tan pronto como se establece: los números de serie son fijos. Y solo marcan esta conexión a medida que se envían datos a través de ella.

Había planes que sugerían administrar estos números de serie. , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

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

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). ?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



SYN (SNs) (SNs) , . — , IP-, . , SNS SNS .

25:50

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


.

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 Cores) 10GB DDR4 240GB SSD 1Gbps , .

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?