Riesgos de la delegación de Kerberos

8

He pasado horas y horas tratando de aprender y comprender la autenticación de Windows, Kerberos, SPN y la delegación restringida en IIS 7.5. Una cosa que no entiendo es por qué es "arriesgado" dejar habilitada la delegación (es decir, no deshabilitar la delegación para cuentas confidenciales) para administradores, directores generales, etc. ¿Puede alguien explicarme esto en términos simples? Encuadre su respuesta con respecto a un entorno de intranet.

Mi razonamiento es que no debería ser una preocupación, porque la delegación simplemente permite que un servidor web front-end, por ejemplo, actúe en nombre de la persona autenticada de Windows cuando se comunica con otros servidores. Si la persona tiene acceso, tiene acceso, no entiendo por qué esto debería ser una preocupación.

Por favor perdona mi ignorancia. Principalmente soy un desarrollador, pero mi empresa funciona muy esbelta en estos días y también me veo obligado a usar el sombrero de administrador del servidor ... desafortunadamente, todavía no encaja muy bien, jajaja.

Chiramisu
fuente

Respuestas:

7

Dos ejemplos:

  1. La delegación restringida permite la suplantación sin tener las credenciales del usuario o el token de autenticación. Para ver un ejemplo, vea esta respuesta .

  2. En un escenario de delegación sin restricciones más típico de carne y papas, ya sea la autenticación integrada de Windows o la autenticación de formularios, tener acceso de delegación al token de autenticación de un usuario es muy poderoso. Eso literalmente significa que el token se puede usar para suplantar a ese usuario para acceder a cualquier recurso de red. Cualquier persona involucrada en ese proceso, como un desarrollador, podría usarlo de una manera nefasta para obtener acceso no autorizado.

En ambos ejemplos, si la casilla está marcada para "la cuenta es confidencial y no se puede delegar", estos no son problemas de seguridad. También es posible diseñar un sistema / característica donde estas capacidades existen, pero están estrictamente controladas.

Esa casilla debe estar marcada para cuentas administrativas, como los miembros del grupo Administradores de empresa, porque (con suerte) esas cuentas rara vez necesitan usar aplicaciones que requieren suplantación. También es una buena idea para los altos ejecutivos que tienen acceso a información confidencial, como un CIO, COO, jefe de Finanzas / Tesorería, etc.

En resumen, Microsoft proporcionó esa casilla de verificación y la advertencia que la acompaña por una muy buena razón, y no debe descartarse ni tomarse a la ligera a menos que se pueda demostrar que un escenario particular no tiene una exposición de riesgo indeseable, o algún control compensatorio. Esto generalmente implica la verificación por parte de algunas personas calificadas que no están involucradas en la implementación o desarrollo real de una aplicación o sistema.

Greg Askew
fuente
En primer lugar, una respuesta increíblemente útil y profunda. No puedo decirte cuánto lo aprecio. :) Todavía me pregunto, qué es necesario para que esto sea explotado porque la gente ciertamente no tendrá acceso a las credenciales de nuestros ejecutivos. También se debe tener en cuenta que los sistemas a los que permitimos la delegación restringida son accesibles para todos los empleados de la red de todos modos. Además, estoy tratando de lograr esto con el modo de canalización integrado y SIN suplantación de ASP.NET.
Chiramisu
1
Incluso si usa el modo de canalización integrado, si el token de autenticación está presente, IIS y cualquier aplicación que se esté ejecutando puede aprovecharlo. Cuando se usa la autenticación integrada de Windows, el token de autenticación es parte del encabezado http. Puede ser útil intentar realizar una prueba de penetración en la configuración propuesta para determinar si lo que crees que es correcto.
Greg Askew
¡Santo cielo! ¿Parte del encabezado HTTP? Al menos debe estar encriptado ¿verdad? De lo contrario, ¡eso es una locura! ¿Por qué Microsoft incluso haría una recomendación tan ridícula? Me temo que no tengo la primera pista sobre la prueba de la pluma, por lo que tendré que aceptar su palabra. Aún así, ninguna de las aplicaciones en este servidor de intranet en particular está restringida internamente, por lo que creo que sería segura. Los tokens tienen un tiempo limitado y se generan dinámicamente, ¿verdad? Solo restringimos ciertas páginas con etiquetas allow/ denyautorización.
Chiramisu
2

He configurado miles de clientes con delegación, la mayoría de los no restringidos. Creo que es importante tener en cuenta que si no confía en su aplicación (digamos implementada en IIS) o si está dando sus credenciales de cuenta de servicio delegadas para que otros las usen libremente, entonces la delegación restringida es probablemente una buena idea. Sin embargo, si no espera que nadie tenga la capacidad de reescribir su aplicación, mantiene seguras las credenciales de su cuenta de servicio y confía en que sus aplicaciones solo van a delegar en los servicios para los que fueron diseñados, entonces Por lo general, no hay nada de qué preocuparse. He visto a algunos clientes "conscientes de la seguridad" centrarse mucho en problemas como este, mientras que sus recursos podrían gastarse mejor trabajando en amenazas de seguridad reales ...

BasicTek
fuente
Agradezco mucho tus ideas; muy útil. Hace mucho tiempo que dejé de configurar la delegación en nuestra Intranet y volví a ejecutar el AppPool en IIS con una cuenta especial con acceso al recurso necesario como estaba configurado previamente. Espero volver a visitar este tema y obtener una solución real, pero la falta de tiempo y experiencia con la delegación impide esa esperanza por ahora. :(
Chiramisu