Securizar su arquitectura

1. Desarrollo de un ataque tipo

Como regla general, muchos ataques utilizan el phishing como forma de comprometer el sistema atacado. El social engineering (capacidad de convencer a una persona para que haga aquello que se espera de ella) es un arma temible. Puede haberse tomado la molestia de actualizar su sistema operativo y plugins, si un usuario se ha dejado engañar por un mensaje electrónico malicioso y abre un documento adjunto peligroso, entonces la seguridad ya está comprometida.

Habitualmente, un ataque se desarrolla siguiendo los siguientes pasos:

1. Enfoque centrado en terceros de confianza

Del puesto de trabajo del usuario a una cuenta de administrador de dominio

Durante la lectura de los diferentes elementos mencionados anteriormente, sin ninguna duda adivinará que puede ser muy complicado proteger un Active Directory.

Tomemos como ejemplo un usuario de soporte de proximidad. Su cuenta es miembro de un grupo de dominio que a su vez es miembro del grupo Administrador local de todos los puestos de trabajo. Por la naturaleza de sus funciones, es normal que un usuario como este pueda acceder como administrador a los puestos de trabajo.

Por tanto, esto significa que a lo largo de sus diferentes intervenciones, el hash de su cuenta se va a encontrar en un número importante de puestos. Será suficiente que con que uno de puestos esté bajo el control de un usuario de la herramienta mimikatz (o equivalente), para que se muestre la contraseña de este usuario y que el usuario malintencionado pueda reutilizar esta cuenta para conectarse como administrador en cualquier otro puesto de trabajo.

Si entre estos puestos de trabajo hay algún puesto de cuentas de administradores que se encargan de administrar los servidores (o peor, Active Directory), entonces el atacante podrá ejecutar mimikatz en los puestos en cuestión y, de esta manera, recuperar la contraseña de un administrador de servidores o de dominio.

Una vez como administrador de dominio, el atacante puede generar un «Golden Ticket» y obtener un acceso prácticamente permanente e indetectable como administrador de dominio.

Alguien estará tentado de responder: «No hay problema, tengo un antivirus en todos mis puestos de trabajo y servidores, por lo que mimikatz o cualquier otra herramienta no podrán ejecutarse nunca».

Anular la protección saltándose un antivirus es extremadamente sencillo, sobre todo con una herramienta como mimikatz, para la que las fuentes son libres y existen conversores PowerShell. Para convencerse, puede aplicar las recomendaciones de este artículo (http://www.blackhillsinfosec.com/?p=5555), que explica cómo, codificando simplemente algunas líneas en las fuentes (principalmente sustituyendo la palabra «mimikatz»), su antivirus permanecerá mudo durante su ejecución. Aunque este método ya no funcione en el momento...

1. Principio de mínimo privilegio y JEA

El principio de privilegio mínimo es, como su propio nombre indica, un principio que consiste en ejecutar cada tarea con una cuenta de usuario que tenga exactamente los permisos necesarios para completar dicha tarea.

En la práctica, esto no siempre es factible, aunque conviene hacer siempre todo lo posible para estar lo más cerca posible de la necesidad reduciendo al máximo la superficie de ataque expuesta. Si un usuario no necesita permisos específicos, ¿por qué asignárselos? Y, ¿cómo asegurarse que el usuario no tiene más derechos de los que le hacen falta?

La superficie de ataque será mucho más reducida si actualiza, de manera regular, su parque informático tanto a nivel de sistema operativo como de aplicaciones instaladas, sin olvidar a los equipos de red. El capítulo El ciclo de vida de su infraestructura aborda, en particular, el uso de WSUS (Windows Server Update Services) para desplegar actualizaciones en sus sistemas Windows.

Una nueva tecnología llamada JEA, del inglés Just Enough Administration permite, como su nombre indica, asignar «solo los permisos necesarios para la administración» de cualquier componente que se pueda administrar con PowerShell.

También es posible acceder a los recursos de la red a través de esta solución (a diferencia de otras soluciones que utilizan la cuenta SYSTEM del puesto local, limitando de esta manera las interacciones con los recursos de la red, ya que en este caso se utiliza la cuenta del puesto).

JEA está disponible desde PowerShell 5.0 y por tanto Windows Server 2008 R2 y Windows 7 (aunque es parcialmente compatible con este OS, porque no es posible configurar JEA para utilizar cuentas virtuales).

De manera más concreta, a continuación se muestra el concepto en sus grandes líneas:

1. AppLocker o el control de las aplicaciones

Applocker es una funcionalidad que ha hecho aparición en Windows 7 (en su edición Enterprise e Ultimate) y Windows Server 2008 R2 con el objetivo de reemplazar a las directivas de restricción de aplicaciones de las versiones anteriores de Windows.

Como con las directivas de restricción de software, Applocker permite definir las aplicaciones autorizadas a ejecutarse por parte de sus usuarios estándar en el seno de su dominio desplegando sus parámetros mediante directivas de grupo.

El interés principal es limitar la instalación de malwares en los puestos de trabajo pero también impedir la instalación de programas no conformes o que requieren una licencia que no posee, etc. En los puestos de trabajo y servidores más sensibles (por ejemplo, los controladores de dominio) puede ser suficiente con autorizar únicamente una lista blanca de ejecutables, bloqueando el resto.

Esta funcionalidad se aplica, principalmente, en puestos cliente con Windows 7/8/8.1 Enterprise, aunque también puede ser interesante auditar y limitar los ejecutables lanzados en Windows Server 2008 R2 y Windows Server 2012/2012 R2.

Applocker presenta varias ventajas en comparación con las directivas de restricción de software:

Sepa, también, que si una directiva de grupo posee a la vez una directiva de restricción de software y una directiva de control de aplicación (Applocker), sólo se aplicará la directiva Applocker en el puesto.

Por lo tanto, si posee un parque informático heterogéneo...

1. Enfoque de la delegación de la administración

Dado que las políticas de seguridad están bien diferenciadas en las distintas divisiones de la empresa y que los equipos IT no son los mismos, conviene encontrar una solución que permita delegar las tareas necesarias para el trabajo de cada uno sin comprometer la seguridad de la totalidad del dominio Active Directory.

Existen distintas maneras de delegar los permisos a los usuarios. Algunas autorizaciones pueden asignarse, fácilmente, a través de grupos de seguridad ya existentes. Es el caso, por ejemplo, de la delegación de la administración de un servicio como DHCP (mediante el grupo DHCPAdmins) o DNS (mediante el grupo DNSAdmins), o incluso la posibilidad de consultar los registros de eventos (mediante el grupo Event Log readers), etc.

Es posible realizar, también, una delegación en el seno de Active Directory mucho más granular, directamente a nivel de los objetos.

La estructura de un dominio Active Directory está organizada por defecto de forma jerárquica. Es posible, en efecto, delegar tareas a nivel de un bosque, de un sitio, de un dominio o incluso de una unidad organizativa. Además, cada objeto posee atributos con DACL (Discretionary Access Control List) asociados, de modo que también es posible delegar las opciones de manera muy precisa (reinicializar la contraseña del usuario, autorizar la desactivación de una cuenta de usuario, etc.). Pasaremos a la práctica un poco más adelante en este mismo capítulo.

Antes de comenzar con la configuración de la delegación de su Active Directory, conviene estudiar bien las necesidades actuales a las que debe responder.

2. Delegación de cuentas de usuario

Pasemos, ahora, a la práctica...

1. El Firewall de Windows

Windows Server 2016 ponen a su disposición un firewall capaz de analizar a la vez el tráfico entrante y saliente gracias a su nuevo módulo de firewall con seguridad avanzada accesible a través de la consola MMC con el mismo nombre.

Este módulo de firewall no debe confundirse con el firewall «básico», conocido en entornos XP y accesible mediante el comando firewall.cpl. El firewall básico no permite definir reglas para el tráfico saliente, sino únicamente excepciones para el tráfico entrante.

Desde Windows Server 2008 R2, la consola del firewall básico ha evolucionado y permite habilitar la protección dependiendo del tipo de red a la que está conectada la tarjeta de red, a saber: "Dominio", "Privada" o "Pública". Cada interfaz de red tendrá asignado un perfil de-pendiendo de las características definidas por el servicio Reconocimiento de ubicación de red.

A continuación, seleccione las aplicaciones para las que desea autorizar el tráfico entrante. Esto presenta una ventaja en comparación a la apertura de un puerto, pues una aplicación autorizada abre una «brecha» únicamente durante el tiempo de ejecución de la aplicación mientras que una regla aplicada sobre un puerto deja este puerto abierto durante todo el tiempo y nada garantiza que la aplicación que escucha en el puerto no es, en realidad, un malware.

También es posible configurar reglas de firewall desde una consola MMC que permita configurar, de forma muy precisa y granular, los flujos, tanto entrantes como salientes. Esto permite adaptarse mejor a la realidad de los requisitos en producción.

Se trata de la consola MMC Firewall con seguridad avanzada (accesible en las Herramientas administrativas, mediante el acceso directo wf.msc o bien a través de la opción Configuración avanzada en la consola básica del firewall)....