Curso MIT "Seguridad de sistemas informáticos". Lección 13: Protocolos 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
Lección 13: "Protocolos de red" Parte 1 / Parte 2 / Parte 3

Supongamos que un cliente emite una solicitud para recibir un mensaje específico, por ejemplo, "dame el mensaje Nº 7", y encripta esto con la clave Kc, mail. Todo parece ser maravilloso.
El servidor de correo tiene una clave compartida que descifrará este mensaje, después de lo cual el servidor enviará de vuelta al cliente el cuerpo de este mensaje de correo electrónico, también cifrado con Kc, correo. ¿Alguien ve esto como un problema? ¿Por qué puede ser esto malo?



Estudiante: existe la posibilidad de que un hacker reemplace un mensaje o lo falsifique.

Profesor: sí, esto es problemático porque puedo enviarle cualquier correo electrónico que desee. Supongamos que tengo la intención de eliminar algún mensaje que esté en su bandeja de entrada porque no quiero que lo lea. Supongamos que esta letra está en el número 23.

Por lo tanto, voy a enviarle una carta que dice: "elimine el número 23", y la va a leer. Lo va a recibir, y la respuesta del servidor de correo con el comando "eliminar No. 23" se cifrará con esta clave Kc, mail. Y hasta ahora no se ha enviado al servidor de correo.

Pero si escaneo la red en el momento adecuado y confirmo este paquete, puedo enviarlo de vuelta al servidor de correo. Se verá como el mensaje "eliminar No. 23", cifrado con la clave. En este caso, el servidor de correo dirá: "¡Oh, sí, por supuesto, desea eliminar este mensaje, y lo haré!"

Entonces, hay un problema aquí porque permitimos que el adversario confunda al servidor de correo en cuanto a si nuestro mensaje fue generado por él o enviado a él en primer lugar.

Esto es lo que comúnmente se conoce en las descripciones de criptografía y protocolo como un "ataque de reflexión". ¿Tiene alguna sugerencia sobre cómo evitar este problema?

Estudiante: ¿es posible incluir simplemente un encabezado de mensaje que hable de su origen?

Profesor: sí, por regla general, desea tener algún tipo de forma inequívoca de decir lo que está sucediendo. Una forma es tener un encabezado en cada mensaje que diga: "de cliente a servidor" o "de servidor a cliente". Una forma aún mejor en la práctica es simplemente usar dos teclas separadas.

Porque es posible que desee tener un flujo de datos largo que no tenga espacio para bits de encabezado. Por lo tanto, cada vez que establece una conexión con un servicio, Kerberos 5 negocia el uso de dos claves en lugar de una. La primera clave se usará para cifrar los datos del cliente al servidor y la segunda para cifrar los datos del servidor al cliente. Este es el método de protección más óptimo para uso práctico.

Hablemos ahora sobre lo que está sucediendo con KDC. El servidor Kerberos es muy importante para el sistema, pero ¿qué sucede si este KDC falla? ¿Qué tan malo es esto para nuestro sistema? ¿Cómo afectará su vida la "caída" de KDC si usa Athena?

Estudiante: ¿ probablemente no puedas iniciar sesión?

Profesor: sí, lo es. En segundo lugar, tampoco podrá obtener entradas para nuevas solicitudes. Pero lo bueno es que KDC está bastante fuera del camino crítico para una conexión existente. Por lo tanto, no pasan datos por el KDC. Y si ya tiene un boleto para algo, puede continuar usándolo y mantener la entrada a algunos servicios de red. En realidad, esto está bastante bien almacenado en caché. Creo que la segunda cosa buena que los desarrolladores han imaginado es el potencial para replicar KDC. Por lo tanto, el sistema tiene un servidor Kerberos principal, que almacena la copia inicial de toda la base de datos. Esto le permite leer solo réplicas que contienen una copia de la base de datos inicial. No permite ninguna actualización, como el registro de usuarios o las actualizaciones clave, pero le permite responder a las solicitudes de inicio de sesión y TGS.

Por lo tanto, el registro "clonar" de la base de datos de Kerberos le permite continuar iniciando sesión y comunicarse con los servicios, incluso si KDC falla, hasta que se elimine y se restablezca su funcionalidad completa.

Estudiante: ¿cuán difícil es comprometer el servidor KDC y el sistema en su conjunto?

Profesor: KDC es la columna vertebral de cualquier sistema que ejecute Kerberos. Si este servicio se ve comprometido, el atacante obtendrá un control completo sobre el sistema. Podrá obtener boletos para cualquier servicio que desee, pretendiendo ser el cliente correcto, por lo que es bastante malo. Realmente queremos mantener a KDC a salvo, pero es difícil. Aunque no conozco un solo caso en el que el KDC MIT hubiera estado realmente comprometido durante unos 20 años. Pero, aparentemente, lo que realmente vale la pena preocuparse es la implementación de software de la seguridad de las cosas que intercambian estos dos servicios, Kerberos y TGS. Porque si se produce un desbordamiento del búfer en ellos o surge alguna otra vulnerabilidad similar, esto es realmente malo.



Por ejemplo, si un servidor SSH se ejecuta en KDC Kerberos y alguien adivina la contraseña raíz de este servidor SSH, simplemente iniciará sesión y copiará la base de datos. Así que creo que realmente quieres minimizar la superficie de ataque aquí, así que ten mucho cuidado al escribir el código KDC. No permita que nadie acceda directamente a este servicio. Por supuesto, hay algunos lugares en los que debe considerarse paranoico con respecto a la seguridad, pero esto no es tan importante para los servidores. Por supuesto, almacenan datos, pero si alguien irrumpe en un servidor de correo o servidor de impresión, pueden ser restaurados.

Aquí hay una pregunta interesante. Supongamos que alguien hackeó un servidor de correo. ¿Qué debes hacer para recuperarte de este ataque? Por ejemplo, si alguien robó su correo, esto es malo. Pero, ¿qué se debe hacer para evitar que un atacante obtenga acceso a su correo en el futuro?

Kerberos no tiene una operación de cancelación, pero puede generar una nueva clave para el servidor de correo y pegarla en la base de datos KDC. Luego instala un nuevo servidor de correo, le da una nueva clave, y luego algún atacante que tenga una clave antigua del servidor de correo no puede influir de ninguna manera.

Por otro lado, suponga que no cambia la clave del servidor de correo, Kmail. ¿A qué conducirá?



Estudiante: la clave no se ajustará al nuevo servidor.

Profesor: bueno, supongamos que instala un nuevo servidor de correo, arreglando el error que usó el hacker. Pero todavía tiene una clave de Kmail. Tal vez la recuperación del servidor tomó un día entero, por lo que todos los tickets caducaron. ¿Puede este hacker hacer algo interesante con el sistema? Si proporciona Kmail antiguo al nuevo servidor de correo, ¿es malo?

Estudiante: un atacante puede infiltrarse en un servidor de correo porque puede descifrar el primer ticket.

Profesor: seguro, por eso Kmail es realmente muy importante. Dices que puedes descifrar todo lo que sucede en el servidor de correo. Supongamos que el cliente se conecta al servidor de correo después de arreglarlo, pero el atacante aún conoce Kmail, que ha permanecido desde el último hackeo del sistema. Por lo tanto, puede descifrar este ticket de Kmail, mirar dentro del ticket y obtener una clave de sesión. Con él, podrá descifrar todos los mensajes que envíe, todas las respuestas que reciba, etc. Por lo tanto, después de restaurar el servidor de correo, es muy importante cambiar este Kmail.

En muchos sentidos, esto es incluso peor que simplemente rastrear el tráfico, porque si un atacante conoce esta clave de Kmail, puede sintetizar nuevos tickets para el servidor de correo sin contactar a KDC. Supongamos que conozco Kmail y quiero leer el correo de un servidor de correo. Solo emitiré este boleto, recolectaré todos estos cinco campos en el orden correcto, generaré una nueva clave y la cifraré usando Kmail. Se verá como la cosa real generada por KDC.

Por lo tanto, solo me conecto al servidor de correo, descifrará el mensaje correctamente y pensará que es un usuario específico, para que pueda proporcionarle correo, compartir una clave compartida con él, etc. Por lo tanto, es fundamental que nadie conozca la clave secreta de este servicio, porque de lo contrario no solo puede hacer que el tráfico sea descifrable y visible, sino que también puede imitar a cualquiera en este servicio.

Estudiante: si el servidor de correo se restaura después de una falla, ¿entonces probablemente necesite cambiar su clave en la base de datos?

Profesor: sí, después de restaurar el servidor de correo después de la falla, debe llamar al tipo que trabaja con este KDC y decir: "nuestro servidor de correo fue pirateado, ¡así que elimine su antigua clave Ks de la base de datos e inserte una nueva!" Por lo tanto, es probable que desee tener algún tipo de mecanismo fuera de la base de datos para demostrar que realmente es un servidor de correo.

Porque veremos en un segundo cómo cambia las claves, por ejemplo, usando el protocolo de cambio de contraseña. Puede contraseñas en el protocolo Kerberos, porque si conoce la contraseña anterior, puede cambiar la contraseña de usuario a la nueva contraseña en KDC. Pero dado que el pirata informático puede interceptar la contraseña enviada por correo, probablemente tendrá que ponerse en contacto con la oficina de registro de la cuenta y pedirle que cambie su contraseña al servidor de correo. Generarán una nueva clave y se la darán para que el hacker no pueda reconocerla.



De lo contrario, si el atacante conoce esta clave de Kmail, el servidor de correo no tiene nada que distinga al atacante del cliente correcto. En realidad, el atacante probablemente cambió la clave, por lo que ahora conoce los nuevos parámetros y usted no está allí, como si ya no estuviera en el servidor de correo. Por lo tanto, necesita protocolos externos para los principios del registro inicial en la base de datos y para cambiar las claves si olvidó su contraseña o si alguien cambió su contraseña para que pierda el acceso.

Por lo tanto, hay un grupo de personas en el MIT que ayudan a los usuarios a registrar cuentas y cambiar sus contraseñas. Para hacer esto, les presenta su ID de MIT, y pase lo que pase, podrán cambiar la clave por usted.

Por lo tanto, es muy importante hacerlo bien. Porque si la persona que le permite restablecer la contraseña se equivoca al verificar su ID de MIT, entonces puede comprometer el sistema, ¿verdad? Entonces, estas personas en Kerberos son parte de una base informática confiable.

Veamos otro uso interesante de Kerberos. Puede usar Kerberos para iniciar sesión en una computadora remota a través de SSH. Y la forma en que funciona es muy similar a trabajar con un servidor de correo. Obtiene un ticket para el servidor SSH y lo envía junto con su conexión SSH. Pero, ¿qué sucede si se conecta a Athena.dial-up y no tiene un cliente Kerberos en su computadora? Solo desea iniciar sesión en Athena.dial-up con su contraseña habitual.

Entonces, ¿cómo lo autentica el acceso telefónico de Athena si solo se conecta a esta máquina con una contraseña? No tiene una contraseña para Athena.dial-up, es una contraseña para el servidor Kerberos. Entonces, ¿qué debe hacer una computadora de acceso telefónico si inicia sesión con una contraseña?

El acceso telefónico funcionará utilizando el mismo protocolo que al iniciar sesión. Por lo tanto, va a enviar una solicitud del cliente al servidor Kerberos con una solicitud para dar un ticket, por ejemplo, al nombre de usuario "Alice". Y de regreso, el cliente recibirá una respuesta encriptada con la contraseña de Alice. Luego intentará aplicar la contraseña y ver si descifra correctamente. Si se descifra correctamente, puede iniciar sesión en el sistema.

Estudiante: ni siquiera necesita enviar su clave al servidor SSH, porque en esta conexión el servidor KDS puede enviar al usuario Kc de vuelta a través de la conexión SSH.

Profesor: es posible que sí, pero requiere un poco de imaginación del cliente SSH, que puede no serlo. Pero en principio esto es cierto. Si desea hacer esto correctamente, es probable que desee tener un cliente Kerberos en su computadora y obtener un boleto usted mismo, o tal vez usar un servidor SSH para reenviar, sin permitir que el servidor SSH tenga su clave.

Este es probablemente un buen plan. Pero resulta que, de hecho, esto es algo bastante peligroso que permite a cualquiera iniciar sesión en el servidor SSH. Anteriormente hablamos de un cliente que intentaba iniciar sesión. Este cliente sabía que al proporcionar una contraseña legal, recibió una respuesta del servidor Kerberos correcto, y si puede descifrar la respuesta, entonces la contraseña probablemente funcione correctamente.

Sin embargo, no hay nada en este protocolo que confirme el hecho de que esta respuesta proviene del servidor Kerberos correcto. Por lo tanto, si intento iniciar sesión en la máquina simplemente ingresando una contraseña, la máquina enviará esta solicitud al servidor. Luego, la respuesta se devolverá a esta solicitud, que parece estar encriptada con la contraseña que ingresé, pero esta respuesta tampoco puede ser del servidor Kerberos.

Supongamos que tengo una máquina con la que quiero iniciar sesión. Ingreso la contraseña X, y luego la máquina envía esta solicitud desde, s al servidor Kerberos.



Pero antes de que el servidor Kerberos envíe la respuesta real al cliente, enviaré mi propia respuesta, que parece la respuesta real, encriptada con mi contraseña X. Y luego la estación de trabajo en la que estoy intentando iniciar sesión o el servidor SSH intentará descifrar esta respuesta con mi contraseña falsa. Esto se verá bien, porque esta respuesta fue generada por mí en lugar del servidor Kerberos real. Por lo tanto, puedo iniciar sesión en lugar de usted. ¿Por qué está pasando esto?

Estudiante: porque no hay autenticación del servidor Kerberos.

Profesor: sí, no hay nada aquí que vincule esto a un servidor Kerberos real. La forma en que Kerberos corrige este inconveniente para las computadoras remotas, como Athena.dial-up, es que las computadoras de marcación tienen un tipo de clave secreta que comparten con KDC. Por lo tanto, para ingresar el acceso telefónico o cualquier estación de trabajo que realmente se preocupe por verificar si realmente es el usuario correcto, se deben hacer dos cosas.

El primer inicio de sesión en Kerberos se produce como se muestra en el diagrama. Pero no confiará en nadie solo porque esta respuesta está descifrada correctamente. Intentará obtener un ticket de servicio para sí mismo utilizando TGS, porque esta computadora de acceso telefónico tiene su propia clave secreta. En la primera etapa, él simplemente lo registra, y luego se dirige a TGS, diciendo: "por favor, deme un ticket de servicio en mi propio principio, en base a la conexión telefónica, para este cliente".

Luego recibe una respuesta y comprueba si puede descifrarla correctamente, porque conoce la clave de acceso telefónico para este Ks. Y si se descifra, significa que la computadora estaba hablando con el servidor Kerberos correcto. Porque solo el servidor Kerberos correcto en la segunda etapa puede enviarme un ticket cifrado con mi clave secreta Kdial-up.

Entonces esto es realmente muy importante. Por lo general, las estaciones de trabajo de Athena no dan este paso adicional porque las estaciones de trabajo de Athena no tienen una clave secreta que se almacena en ellas y se comparte con KDC. ¿Por qué se considera normal que las estaciones de trabajo de Athena le den la oportunidad de iniciar sesión en la primera etapa, pero no le brinden esa oportunidad de acceso telefónico?

Estudiante: esto es normal si no tiene acceso a ningún servicio porque el atacante no pudo falsificar un boleto.

Profesor: sí, esto es cierto, porque no hay nada interesante en la estación de trabajo de acceso telefónico en sí. Incluso si tiene acceso de root o ingresa a una estación de trabajo con una contraseña falsa, esto no molesta a nadie. No es como si pudieran hacer algo más fuera de su estación de trabajo. En el acceso telefónico, todo es mucho más interesante. Quizás tenga otros procesos ejecutándose desde otras sesiones en la estación de trabajo de acceso telefónico, y el hecho de que haya iniciado sesión con un UID específico de Unix, y que realmente quieran asegurarse de que usted sea la entidad correcta, es importante allí. . Es por eso que realizan un proceso de dos pasos para ingresar a la máquina, que es utilizado simultáneamente por varios usuarios.

Lo último de lo que quiero hablar es cómo reemplazamos las llaves. Presentamos la idea de que puede comprometer la clave del servidor de correo. Pero como usuario, probablemente también desee cambiar la contraseña. Por ejemplo, pensó que su contraseña no era lo suficientemente segura, la escribió en una hoja de papel y alguien podría haberla espiado, por lo que ahora desea cambiarla.

En cierto sentido, es bastante simple. Además de los servicios Kerberos y TGS, la interfaz del servidor Kerberos tiene un servicio adicional llamado Kpassword, que le permite cambiar su contraseña.



Obtiene un ticket para usar este servicio al igual que un ticket para un servidor de correo o cualquier otro servidor. Después de eso, envía su nueva contraseña a este servicio de Kpassword, encriptada con su clave de sesión. Y luego, si pasan todas las comprobaciones, su clave en la base de datos se actualizará con una nueva clave.

Si recuerdas, teníamos un objetivo: si alguien roba tu boleto, no debería ser lo suficientemente bueno como para dar la oportunidad de capturar completamente tu cuenta. Por este motivo, el servicio Kpassword no acepta ningún ticket, sino solo el ticket que inicialmente recibe del servicio Kerberos con su clave Kc. : , , , , – Kerberos TGS – . : Kerberos, , TGS, .
Kpassword, , , : «, Kerberos, . TGS, , , , - , . ».

, Kpassword , , , Kerberos. , Kpassword , Kerberos Kpassword.

Kpassword, - . , , Kerberos. Kerberos, ID , Kpassword.



Kerberos , Kpassword, Kpass, Kc,kpass Kpassword, Kc.

, – Kpassword, Tc,kpass, Kpass, , new pass Kc,pass, .

, , , , . - Athena, , , , . , , Gmail, , . , Kerberos TGS , - , .

, - Athena , , , . , . , . Tc,kpass, Kpassword, TGS, . , Kerberos Kc.

: , ?

: K . Kerberos , . , K. - K, .

: , ?

: , - , , . .

, , , , , , .

: , , .

: , , . , , Kerberos , , . , . . , , .

: K, ?

: , K – 56- DES, , , 56 , , 7 , . .

, , . , , , , . Kerberos?



: …

: , , , , , , . ?

: .

: , .

: - , , , , …

: , , Kerberos , , , . . , , , «» - , ! : „, Kc,pass, K. Kc,pass , Kpassword». , , KDC. , .
, , - , - . .

: , Kerberos ?

: , . « -», , , . , .

, Kerberos 5. , , , . , . , X, Kpassword - Y. , , . , g X , g Y.



gy X, gxy, gx Y gxy. gxy , . , , gxy. , , - gxy, . , .

: - G.

:Si por supuesto. G es un parámetro que puede enviar al comienzo del protocolo o por adelantado para colocarlo en Kerberos, no es demasiado importante. En cualquier caso, si utiliza el protocolo de cifrado de intercambio Diffie-Hellman, Kerberos 5 lo hace bien. Pero necesita saber acerca de la existencia de este protocolo si está desarrollando un nuevo protocolo propio. Eso es todo lo que quería hablar sobre Kerberos, y el lunes hablemos sobre SSL.


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?