Mes: diciembre 2008

Además de guardar contraseñas en AD o en las SAM, Windows Server 2003, Windows 2000 y Windows XP almacenan contraseñas y otros secretos en otras ubicaciones para una variedad de propósitos.

LSA secrets

Local Security Authority mantiene información sobre todos los aspectos de la seguridad local del sistema operativo. LSA lleva a cabo:

• Autentica usuarios
• Administra las directivas locales de seguridad
• Administra las directivas de auditorías y su configuración
• Genera testigos de acceso.

Además, almacena información usada por el sistema, conocida como secretos LSA. Estos secretos incluyen elementos como información sobre RAS; contraseñas de relaciones de confianza; y nombres de usuario, contraseñas y nombres de cuentas. Quizás lo más importante sea que los nombres de cuentas y las contraseñas para servicios que se ejecutan bajo el contexto de cuentas de usuario están almacenadas como secretos LSA. Estos secretos pueden ser revelados localmente mediante cuentas con programas de depuración con derechos de usuario. Consecuentemente, debemos ser cuidadosos sobre la información que las aplicaciones almacenan en los secretos LSA. Un atacante que comprometa físicamente el equipo o convertirse en administrador del sistema pueden conseguir acceder fácilmente a la información almacenada si no se toman otras precauciones, como usar syskey.exe (System Key).

Syskey se introdujo en el SP2 de Windows NT 4.0 y está habilitado de forma predeterminada en Windows Server 2003, Windows 2000 y Windows XP. System Key es la clave maestra utilizada para proteger la clave cifrada de contraseña y la contraseña de cuenta de equipo, por lo tanto, es una operación de seguridad del sistema crítica.

Data Protection API

La API de protección de datos DPAPI habilita a los secretos para ser almacenados con seguridad mediante aplicaciones, usando la clave derivada de la contraseña del usuario. El cifrado de secretos sólo puede realizarse localmente, a menos que se usen perfiles móviles. Si la contraseña del usuario se reinicia, la clave utilizada por DPAPI se perderá a menos que haya sido recuperada previamente. DPAPI sólo está disponible en Windows Server 2003, Windows 2000 y Windows XP. Usando esta API las aplicaciones pueden almacenar la información cifrada, en el registro o en una base de datos. En Windows XP y Server 2003 DPAPI se usa para la protección de las claves de EFS (Encrypting File System) en grupos de trabajo.

Credenciales salvadas

De forma predeterminada, Windows Server 2003, Windows 2000 y Windows XP salvan las credenciales de las cuentas de dominio usadas para iniciar sesión en la red en el equipo local. Estas credenciales incluyen el nombre de usuario, la contraseña y el nombre del dominio. Más que almacenarla, la información se guarda con una forma de cifrado irreversible y en el equipo local. En cuanto un usuario inicia sesión correctamente en la red desde un equipo una vez, el puede usar sus credenciales de dominio, aun si el equipo no se encuentra conectado a la red o no hay controladores de dominio en ese instante. Esta funcionalidad es crítica en el caso de usuarios en oficinas remotas sin DCs locales o usuarios de portátiles. Podemos variar el número de credenciales salvadas en un equipo en cualquier momento configurándolo en la clave del registro siguiente:

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsNTCurrentVersionWinlogonCachedLogonsCount

De forma predeterminada el valor de la entrada tipo REG_SZ es 10, podemos cambiarlo entre 0 y 50, dependiendo de nuestras necesidades.

En redes de alta seguridad el valor debe ser 0. Se obliga a la presencia de un DC para la comprobación de las credenciales del usuario. Esto impedirá que un usuario inicie sesión con credenciales salvadas. Aunque las credenciales salvadas están cifradas de manera irreversible no son invulnerables a ataques de fuerza bruta, aunque en ello influirá la contraseña elegida por el usuario.

Gestor de credenciales

Windows XP introduce un nuevo método de administración de credenciales, y que también está implementado en Windows Server 2003. Esta funcionalidad la encontramos en el Panel de Control,  Nombres de usuarios y contraseñas almacenados, desde el que podemos administrar:

• Usuarios y contraseñas
• Certificados X.509, incluyendo smart cards.
• Cuentas passport

NTLM

NT LAN Manager conocido como NTLM fue el primero en Windows NT y es una mejora respecto al protocolo LM. A diferencia de las contraseñas LM, que usan el conjunto de caracteres ASCII, las de NTLM están basadas en el conjunto de caracteres Unicode, se reconocen las minúsculas y las mayúsculas, la longitud aumenta hasta 128 caracteres. Como con LM, el sistema no almacena la contraseña sino que almacena una representación de la misma mediante el NTLM OWF. OWF se combina con el algoritmo MD4 Hash, que implementa una función de cifrado denominada digest (resumen)-un hash de 16 bytes- de una cadena de texto de longitud variable, que en este caso es la contraseña del usuario.

Otra de las diferencias entre NTLM y LM es que las contraseñas del primero no se dividen en partes más pequeñas antes de combinar su algoritmo de hash. NTLM usa el mismo proceso Desafío/Respuesta para autenticarse como LM. NTLM es el proveedor predeterminado de autenticación e Windows NT, Windows 2000 y Windows Server 2003 mientras no sean miembros de un dominio de Active Directory, y aun así se utiliza por diversas funciones. Para respetar compatibilidad hacia atrás, el hash LM se envía junto al Hash NT. Si eliminamos los hashes LM de la BD al crear contraseñas mayores de 14 caracteres o modificando la llave NoLMHash del registro, el sistema crea un valor nulo para el hash LM. Aunque este valor nulo no sirve para autenticar al usuario se sigue enviando junto al hash NT.

NTLMv2

Segunda versión del protocolo NTLM, apareció con el SP4 de Windows NT 4.0 y se incluye en Windows 2000 y posteriores. Sigue las mismas reglas que NTLM, sin embargo usa un proceso de autenticación ligeramente distinto. NTLMv2 necesita además que la posible diferencia horaria entre clientes y servidores no supere los 30 minutos.

Si el cliente y el servidor son compatibles con NTLMv2, se consigue una sesión de seguridad mejorada. Esta seguridad mejorada proporciona claves separadas para confidencialidad e integridad del mensaje, proporciona una entrada al cliente al desafío para impedir ataques específicos de texto plano, y usa un hash basado en el algoritmo MD5 y el código de autenticación de mensaje (HMAC) para la comprobación de la integridad del mensaje.

Kerberos

Kerberos v5 es el protocolo predeterminado de autenticación en equipos con Windows Server 2003, 2000 y XP que son miembros de un dominio de Active Directory. Los sistemas Windows anteriores no son compatibles con Kerberos y usarán uno de los métodos de autenticación LM. Cumpliendo con la RFC 1510 se implementa en los sistemas operativos Windows, siendo interoperable con otros mundos kerberos con una mínima configuración. Los beneficios que aporta:

• Autenticación mutua. Kerberos habilita al cliente comprobar la identidad del servidor, a un servidor la de otro servidor y al cliente a comprobar su identidad en el servidor.
• Transmisión segura por el medio. Los mensajes kerberos se cifran con una variedad de claves de cifrado para asegurar que nadie pueda interferir en los datos de un mensaje kerberos. Además, la contraseña en realidad no se envía a través de la red cuando se usa kerberos. Esto no significa, sin embargo, que un atacante no pueda llevar a cabo un ataque de fuerza bruta contra una secuencia de autenticación interceptada. Es importante elegir buenas contraseñas y fuertes.
• Impide la repetición de paquetes de autenticación. Kerberos minimiza la posibilidad de que alguien obtenga y reutilice paquetes de autenticación kerberos mediante marcas de tiempo como un notario que lo acredita. De forma predeterminada desde Windows 2000 todos los relojes están sincronizados con el controlador de dominio que los autentica mediante NTP. Para que un ticket kerberos continúe siendo válido, los relojes deben permanecer sincronizados con una diferencia no superior a 5 minutos entre ellos.
• Autenticación delegada. Los servicios de Windows se hacen pasar por clientes cuando acceden a recursos de clientes, ‘de parte de…’. Kerberos incluye un mecanismo proxy que habilita al servicio para imitar al cliente cuando conecta con otros servicios. Entre otras cosas, esto permite a aplicaciones de n capas a utilizar credenciales en sistemas back-end sin depender en cuentas duplicadas o autenticación de paso a través como sería requerido por protocolos de autenticación LM. Windows Server 2003 proporciona un mecanismo más resistente para usar delegación mediante delegación obligada y es compatible con otros protocolos de autenticación mediante protocol translation (PT).

Los cuatro componentes que permiten a Kerberos v5 la autenticación entre usuarios y equipos cliente que usan kerberos y controladores de dominio con Windows Server 2003 o Windows 2000.

• KDC(Key Distribution Center). El servicio de red que provee de tickets TGTs a usuarios y equipos en la red. Administra el intercambio de secretos compartidos entre un usuario y un servidor cuando se autentican entre ellos. KDC contiene dos servicios: El servicio de autenticación y el servicio de concesión de ticket. El primero proporciona la autenticación inicial del usuario en la red y le otorga un TGT. Siempre que un usuario solicita acceso a un servicio de red aporta su TGT para el segundo de los servicios, y este entonces proporciona al usuario con un ticket de servicio para autenticarse contra el servicio de red destino. KDC se ejecuta en todos los controladores de dominio.
• TGT(Ticket-granting ticket). Proporcionado para usuarios la primera vez que se autentican con el KDC. TGT es un servicio de ticket para KDC. Siempre que un usuario necesita solicitar un ticket de servicio para un servicio de red, presenta el TGT al KDC para validar que se ha autenticado en la red. Como seguridad añadida los sistemas Windows verifican, de forma predeterminada, que la cuenta de usuario permanece activa cada vez que un TGT se presenta en el KDC. O sea, el KDC comprueba que la cuenta no esté deshabilitada. En Windows 2000 cuando se recibe un TGT de usuario, un servidor en el que se confía por delegación puede solicitar tickets de servicio para el usuario para cualquier otro servicio en la red. En Windows Server 2003, el servidor puede directamente solicitar un ticket de sesión mediante conversión de protocolo (PT). También diferente en Windows Server 2003, utilizando su Servicio de Nombre principal (SPN) puede determinarse que servicios el equipo puede delegar. Mejora de seguridad sobre la delegación en Windows 2000.

Pestaña delegación en una cuenta de equipo en Windows Server 2003.

• Service Ticket. Proporcionado por un usuario siempre que conecta a un servicio en la red. El usuario adquiere el ticket del servicio al presentar el TGT ante el KDC y solicitar el ticket del servicio en el equipo del servicio de red. El ticket contiene una copia de la clave de sesión del equipo destino e información sobre el usuario que está conectando. Esta información se usa para comprobar que el usuario está autorizado a acceder al servicio de red deseado comparando la información de autenticación –a saber, el SID de usuario y los SIDs de los grupos de los que es miembro- contra la lista de control de acceso (DACL) del objeto al que está intentando acceder. El ticket de servicio se cifra usando la clave que comparten el KDC y el servidor destino. Esto asegura que el servidor destino se autentica ya que él es único que puede descifrar la clave de sesión.
• Referral Ticket. Emitido cada vez que un usuario intenta conectar al servidor destino que es miembro de un dominio diferente. Este ticket es realmente un TGT para el dominio en el que el recurso se encuentra. Está cifrado usando una clave interdominio entre el dominio inicial y el dominio destino que se intercambia como parte del establecimiento de una relación de confianza transitiva.

Todas las transacciones de autenticación kerberos estarán compuestas de alguna combinación de los siguientes mensajes de intercambio:

• Authentication Service Exchange. Usado por el KDC para proporcionar un usuario con clave de sesión iniciada y un TGT para solicitudes de ticket de servicio futuras. Comprende una solicitud KRB_AS_REQ enviada por el usuario al KDC y una respuesta KRB_AS_REP devuelto por el KDC al usuario.
• Ticket-Granting Service Exchange. Utilizado por el KDC para distribuir claves de sesiones y tickets de servicio. El ticket de servicio devuelto está cifrado usando la clave compartida maestra por el KDC y el servidor destino, así que el servidor destino es el único que puede descifrar el ticket. Comprende una solicitud KRB_TGS_REQ y una respuesta KRB_TGS_REP, al igual que el anterior.
• Client/Server Authentication Exchange. Usado por el usuario al presentar un ticket de servicio en la red. Comprende tanto una solicitud del usuario como una respuesta del servidor destino, KRB_AP_REQ y KRB_AP_REP.

Para utilizar el intercambio de autenticación cliente-servidor, el usuario introduce su nombre de inicio de sesión, contraseña y dominio en el cuadro de diálogo del inicio en Windows. El equipo cliente localiza al KDC usando DNS. Después el equipo del usuario envía una solicitud de autenticación Kerberos(KRB_AS_REQ) al controlador de dominio. La información de cuenta del usuario y la hora actual del equipo se codifican con la clave compartida entre la cuenta de usuario y el KDC. Finalmente, el servicio de autenticación en el KDC autentica al usuario, genera un TGT para el usuario y se lo envía como Respuesta Kerberos (KRB_AS_REP).

Cuando un usuario se autentica a sí mismo con Kerberos una serie de paquetes se intercambian para completar la validación de sus credenciales.

Autenticación inicial	Obteniendo un ticket de sesión Kerberos

El sistema operativo es el responsable de almacenar con seguridad y transmitir las credenciales de las cuentas. Windows es compatible con variedad de protocolos para transmitirlas a través de la red y autenticar a las cuentas y con diversos formatos de almacenamiento.

Cuando inicia sesión un usuario desde el cuadro de diálogo a tal efecto, varios componentes trabajan juntos para autenticar las credenciales con seguridad.

 

Windows server 2003 usa el protocolo Kerberos v5 de forma predeterminada para la autenticación del dominio y también es compatible con el uso de los protocolos Lan Manager(LM), NT Lan Manager (NTLM) y NT Lan Manager v2 (NTLMv2). Debido al uso de sistemas operativos de versión única o de aplicaciones que usan sus mismos métodos de autenticación, Windows Server es compatible con métodos de autenticación anteriores para mantener la compatibilidad con estos sistemas y aplicaciones. Sin embargo, podemos afinar la autenticación en Windows siguiendo nuestras necesidades técnicas.

Lan Manager(LM)

La autenticación con Lan Manager es compatible con los sistemas Windows 2000, XP y 2003.

Las contraseñas LM tienen un límite de 14 caracteres y no son almacenadas por el sistema operativo. En su lugar, se cifran con la función (OWF) de un sentido de LAN Manager, que se forma con la conversión a mayúsculas de la contraseña, añadiendo un relleno de asteriscos hasta los 14 caracteres, si fuese necesario, dividiéndolos luego en dos mitades y cifrando un valor constante con ellas usando el algoritmo DES (Data Encryption Standard).

 

Cuando un usuario se autentica usando el protocolo LM, la autenticación se efectúa con una interacción simple de Desafío/Respuesta desde el Controlador de Dominio.

El cliente envía una solicitud de autenticación al servidor de inicio de sesión. El servidor devuelve un desafío (que cambia en cada ocasión). El cliente entonces usa el hash LM de la contraseña para cifrar (cambiante en cada ocasión) una cabecera usando DES. El servidor descifra la cabecera cifrada en el cliente usando la contraseña LM almacenada en su base de datos de contraseñas. Si coinciden la enviada y la comprobada, las credenciales son validadas. NTLM funciona de la misma forma, pero con cabeceras más largas. Si un atacante es capaz de capturar paquetes en la autenticación Desafío/Respuesta, podría usar fuerza bruta para encontrar la contraseña; aunque requiere múltiples operaciones de cifrado y consume tiempo, las contraseñas pueden revelarse.

Al reducir los caracteres a 14 y sólo mayúsculas, separándolos en dos mitades de 7, los hashes LM son fácilmente vulnerables a la fuerza bruta y ataques de diccionario. Hay muchas herramientas en Internet para ello.

Permisos de Active Directory, Archivo y Registro.

Los permisos sobre AD, archivo y registro se conceden usando DACLs(discretionary access control lists). Concedemos permisos a objetos mediante la creación de un ACE(access control entry) para la cuenta o grupo del que la cuenta es miembro.

Repasemos un poco…

Tipos y ámbito de los grupos.

En Windows Server 2003, Windows 2000 y Windows XP podemos organizar los usuarios y otros objetos del dominio en grupos para administrarles los derechos y permisos. Definir grupos de seguridad es una premisa para asegurar redes distribuidas.

Podemos asignar los mismos permisos a un número de cuentas grande con solamente una operación usando grupos de seguridad. Ello asegura permisos y derechos a todos los miembros de un grupo. El uso de los grupos para asignar derechos y permisos significa también que las ACLs, en los recursos, permanecen inalteradas y son más fáciles de controlar y auditar. Las cuentas de usuario que necesiten acceder a un recurso específico sólo han de ser añadidas o eliminadas del grupo apropiado, sin necesidad de cambiar las ADLs frecuentemente, son pequeñas y fáciles de interpretar.

Grupos especiales

Hay algunos grupos cuya pertenencia, aún siendo administradores, no se pueden administrar, se denominan grupos especiales. La pertenencia a un grupo especial se obtiene por las cuentas automáticamente como resultado de su actividad en el equipo o en la red. Es esencial entender como funcionan estos grupos ya que son frecuentemente mal usados y pueden seriamente afectar a la seguridad de la red si no se implementan adecuadamente.

Grupos del equipo local

Los grupos del equipo local son grupos de seguridad que son específicos para él y no se reconocen en otro lugar, sea el dominio u otros equipos. Estos grupos son el medio principal de administración de derechos y permisos sobre recursos en un equipo local. Existen varios tipos de grupos integrados locales predeterminados en equipos con Windows Server 2003, Windows 2000 o Windows XP.

• Administradores
• Operadores de copia
• Invitados
• Usuarios avanzados
• Duplicadores
• Usuarios
• HelpServicesGroup
• Operadores de configuración de red
• Usuarios de escritorio remoto.

La configuración de seguridad predeterminada para usuarios avanzados (desde Windows 2000) es compatible con la predeterminada para usuarios en Windows NT. Esto permite a los usuarios avanzados ejecutar aplicaciones antiguas que no están certificadas para Windows Server 2003, Windows 2000 y Windows XP Professional y que por tanto no pueden ser ejecutadas en el contexto de seguridad más seguro de usuarios. En un entorno seguro, deberíamos estudiar la forma de ejecutar las aplicaciones bajo el contexto de usuarios y no hacer a los miembros de usuarios miembros a su vez de usuarios avanzados. Los usuarios avanzados pueden llevar a cabo más operaciones en el propio sistema, como cambiar la hora y la fecha, modificar la configuración de pantalla y crear cuentas de usuario y recursos compartidos. También pueden modificar:           * HKEY_LOCAL_MACHINESoftware           * Program Files           * %Windir%           * %Windir%System32 Por lo que un no-administrador podría cambiar archivos en el último directorio y tomar el control del sistema operativo. Es una razón por la que los usuarios avanzados deberían considerarse como administradores locales a todos los efectos.

 

Además de los grupos integrados, pueden crearse grupos locales adicionales que adecuen las necesidades de seguridad de nuestra organización. Podemos añadir grupos globales desde cualquier dominio de confianza a los grupos locales para conceder derechos y permisos sobre los recursos locales. No podemos añadir grupos locales desde un equipo a grupos locales de otro equipo.

Grupos integrados del dominio

Al igual que existen grupos integrados del equipo local existen grupos integrados en dominios de Active Directory. Estos grupos tienen delegados derechos y permisos.

• Administradores
• Operadores de copia
• Operadores de servidores
• Operadores de cuentas
• Operadores de impresión
• Grupo compatible Pre-Windows 2000
• Duplicadores, invitados y usuarios, que funcionan igual que en los equipos locales pero esta vez con el ámbito de todos los equipos del dominio.

Grupos locales de dominio

Estos grupos existen en dominios Windows 2000 o Windows Server 2003 al ser convertidos a modo nativo. Estos grupos pueden contener miembros de cualquier parte del bosque, bosques de confianza o dominios de confianza pre-Windows 2000. Estos grupos sólo se pueden utilizar para asignar permisos a recursos en equipos que son miembros del dominio en el que existen.

Grupos globales

Los grupos globales en dominios Windows 2000 y Windows Server 2003 pueden contener cuentas desde sus propios dominios y pueden usarse para establecer las ACLs en todos los dominios de confianza. Una vez convertido el dominio a modo nativo, los grupos globales pueden anidarse, es decir, pueden contener a su vez otros grupos globales del mismo dominio. Nunca contendran cuentas o grupos globales de otros dominios, sin importar que el dominio sea mixto o nativo.

• Administradores del dominio
• Administradores de Empresa (desde Windows 2000)
• Administradores de Esquema (desde Windows 2000)
• Servidores RAS e IAS (desde Windows 2000)
• Propietarios del creador de directivas de grupo

Grupos universales

Si el dominio está en modo nativo podemos usar grupos de seguridad universales. Como los grupos globales se pueden usar en cualquier dominio de confianza. Sin embargo, estos grupos pueden tener miembros desde cualquier dominio en el bosque. Por el ámbito del que dispone, la pertenencia a grupos universales se almacena en el catálogo global. El catálogo global se replica totalmente en todo el bosque, lo que significa que la pertenencia a grupos universales debería permanecer bastante estática, especialmente en bosques donde la convergencia no se produce rápidamente.

Implementar seguridad basada en funciones

Todos los derechos y permisos se otorgan sobre una base discrecional, lo que significa que cualquier cuenta con Control Total, puede dar o denegar permisos en un objeto a otros principales de seguridad. Para crear una red segura, debemos crear una estructura para otorgar derechos y permisos que sea escalable, flexible, gestionable y por encima de todo, segura. Con una estructura basada en funciones en la concesión de derechos y permisos podremos controlar el acceso a la información. Así, nunca se concederán o negarán permisos o derechos a cuentas especificas directamente, sino que en su lugar lo haremos en grupos basados en su trabajo o función.

En esta implementación, cada tipo de grupo se usa para un propósito especifico y crear una discreta separación de la cuenta y la asignación de permisos basados en la función o trabajo del usuario. Crear grupos de dominio local o grupos locales y asignarles permisos sobre recursos. Crear grupos globales basados en una función o trabajo, emplazarlos en los grupos de dominio local o grupos locales creados y luego colocar a los usuarios en el grupo global apropiado.

Grupos Universales vs. Grupos Globales

En modo nativo disponemos de la posibilidad de utilizar Grupos Universales, pero ¿cuándo deberíamos usarlos?

Primero, cuando más de un recurso con las mismas necesidades de seguridad existe en muchos dominios del bosque y los usuarios de estos recursos también existen en muchos dominios del bosque. No podemos conseguir con elegancia este mapeo sin los grupos universales.

Segundo, podemos usar los grupos universales al asignar permisos sobre objetos de Active Directory en un bosque de múltiples dominios.

Beneficios de un estructura de seguridad basada en funciones:

• Los grupos están segmentados en áreas discretas. Sólo los grupos de dominio local o los grupos locales tienen permisos asignados para ellos y contienen sólo grupos globales o universales. Además, los grupos globales contienen sólo cuentas u otros grupos.
• Los permisos están en los recursos no en la cuenta. Esto permite a los administradores de recursos controlar la seguridad de los mismos, sin un acceso importante a las cuentas.
• Los permisos pueden ser seguidos fácilmente.
• Los permisos se controlan mediante administración de grupos, no cambiando los permisos en los recursos, haciendo así los registros de auditoría más fáciles de leer y administrar.

No quiero dejar pasar la ocasión para desearos que paséis unas navidades en paz, salud y amor con vuestras familias y seres queridos, al mismo tiempo también espero que vuestros deseos y necesidades se vean cumplidas durante el 2009.

Merry Christmas!. With many good wishes for Christmas and the coming year.

Juansa

En Windows Server 2003, 2000 y XP, lo que pueden hacer las cuentas se dividen en dos partes: derechos y permisos. Los derechos son acciones u operaciones que una cuenta puede o no puede realizar. Los permisos definen los recursos a los que una cuenta puede o no puede acceder y el nivel de dicho acceso. Entendamos que recursos comprenden también a los objetos de Active Directory, objetos de sistema de archivo y llaves del registro. Aunque las cuentas son el eje central de seguridad de Windows, asignarles derechos y permisos directamente es difícil de administrar y muchas veces de solucionar su aplicación o no aplicación tanto de derechos como de permisos. Por ello, siempre se aconseja no asignarlos a cuentas y en su lugar hacerlo sobre grupos y emplazar las cuentas dentro de los mismos. La creación de una estructura de grupos para administrar la asignación de derechos y permisos es una parte esencial de la seguridad de Windows.

Derechos de usuario y permisos

Como ya he dicho las acciones que una cuenta puede llevar a cabo y el nivel con que un usuario podrá acceder a la información son determinados por los derechos de usuario y los permisos.

Los administradores podemos asignar derechos específicos a cuentas de grupos o de usuario. Estos derechos autorizan a llevar a cabo acciones específicas, por ejemplo iniciar sesión, crear copias de seguridad, etc… Se diferencian de los permisos de forma clara e inequívoca, los derechos se aplican a cuentas, los permisos se adjuntan a los objetos.

• Privilegios

Un derecho es asignado a una cuenta y especifica las acciones permitidas en la red.

• Derechos de inicio de sesión

Derecho asignado a una cuenta y que especifica la forma en que la misma iniciará sesión en el sistema. Por ejemplo: iniciar sesión local.

Los privilegios

Algunos privilegios pueden sobrescribir los permisos establecidos en un objeto.

• Actuar como parte del sistema operativo

Este privilegio permite literalmente a la cuenta o aplicaciones en ejecución bajo la misma ser parte de la base de confianza del cálculo. Esto permite a un proceso autenticarse como cualquier usuario, y por lo tanto obtener acceso a los recursos bajo la identidad del mismo. Sólo los servicios de autenticación de bajo-nivel de mayor confianza deben necesitar este privilegio. El usuario o proceso con este privilegio puede crear tokens que garantizan más derechos que los que normalmente se proporcionan en su contexto de seguridad.

No deberíamos asignar este privilegio a menos que estemos completamente seguros que es necesario.

• Administrar los registros de auditoría y seguridad

Permite a un usuario especificar opciones de auditorías de acceso a objetos para recursos individuales, como archivos, objetos de AD y llaves del registro. La auditoría a los objetos no se llevará a cabo a menos que tengamos habilitada la configuración de auditoría que la activa. Un usuario con este privilegio puede ver y limpiar el registro de seguridad en el visor de sucesos.

• Agregar estaciones de trabajo al dominio

Permite añadir equipos a un dominio específico. Los usuarios sólo pueden unir hasta 10 equipos de forma predeterminada. Para aumentar éste número hay que cambiar una propiedad llamada ms-DS-MachineAccountQuota o también podemos delegar en un usuario la capacidad de crear cuentas de equipo en una OU.

• Ajustar cuotas de memoria para un proceso

Este privilegio determina quien puede cambiar la memoria máxima que se puede consumir por un proceso. Útil para un afinamiento del sistema, pero que podría convertirse en un ataque DOS.

• Apagar el sistema

Permite al usuario el apagado del sistema local. Quitándoles este derecho a los usuarios de Terminal Server impediremos que apaguen el equipo, sea accidental o intencionadamente.

• Bloquear páginas de memoria

Permitir a un proceso mantener datos en la memoria física impidiendo que el sistema los pagine en la memoria virtual en disco. Este privilegio puede afectar al rendimiento del sistema, es obsoleto y no debe usarse.

• Cambiar la hora del sistema

Permite al usuario establecer la hora en el reloj interno del equipo. De forma predeterminada, desde Windows 2000, los usuarios del dominio no tienen este privilegio para evitar que cambien la hora de su sistema y ello interfiera en la autenticación Kerberos (una diferencia de 5 o más minutos impediría trabajar correctamente).

• Cargar y descargar controladores de dispositivo

Permite a un usuario instalar y desinstalar controladores de dispositivo que no han sido instalados por el administrador de P&P y controlar los dispositivos(iniciarlos o detenerlos). Como los controladores se ejecutan como programas en los que se confía, un mal uso de este privilegio podría servir para la instalación de programas hostiles, como rootkits, y darles acceso a los recursos. No debería concederse en exceso.

• Crear objetos compartidos permanentes

Permite a un proceso crear un objeto de directorio en el Administrador de objetos. Este privilegio es útil para los componentes en modo kernel para la ampliación del espacio de nombres. Ya que los componentes que se ejecutan en modo kernel ya disfrutan de este privilegio no parece necesaria su aplicación especifica.

• Crear objetos globales

Este privilegio se añadió en el SP4 de Windows 2000 y está presente en Windows Server 2003. Controla la creación de objetos del sistema globales por aplicaciones, incluyendo operaciones como el mapeo de archivos en las sesiones de Terminal Server. También se aplica si se crean enlaces simbólicos en el administrador de objetos.

• Crear un archivo de paginación

Permite al usuario crear y cambiar el tamaño del archivo de paginación. Esto se hace especificando un tamaño de archivo de paginación para una determinada unidad en el cuadro de diálogo de opciones de Rendimiento, desde el cuadro de diálogo de las propiedades del sistema.

• Crear un objeto testigo

Permite a un proceso la creación de un token y usarlo para obtener acceso a recursos locales cuando el proceso use las APIs de creación de token. Predeterminadamente sólo LSA (Local Security Authority) puede crear tokens.

• Depurar programas

Permite al usuario adjuntar un depurador a cualquier proceso. Sin este privilegio, podemos depurar los programas propios. Este privilegio proporciona un acceso poderoso a componentes del sistema operativo sensibles y críticos, así que a ver a quien se le concede!!

• Forzar el apagado desde un sistema remoto

Permite al usuario el apagado de un sistema desde cualquier ubicación remota de la red.

• Generar auditorías de seguridad

Permite a un proceso generar entradas en el registro de Seguridad (Security log) para auditar el acceso a los objetos. También le permite generar otras auditorías de seguridad. Este registro de seguridad se utiliza para el seguimiento del acceso no autorizado al sistema.

• Habilitar las cuentas de equipo y de usuario en las que se confía para delegación

Permite al usuario seleccionar la configuración de ‘se confía para delegación’ de la configuración de un objeto equipo o usuario. El usuario u objeto al que se le concede este privilegio debe tener permiso de escritura sobre las banderas de control de la cuenta del usuario u objeto. Un proceso de servidor ya se esté ejecutando en un equipo o usuario en los que se confía por delegación puede acceder a recursos en otro equipo. El proceso usa credenciales delegadas de cliente, siempre que la cuenta del cliente no tenga establecida la bandera de control en la cuenta de Account Cannot Be Delegated(la cuenta no puede delegarse). El abuso de este privilegio o sobre los valores de ‘se confía para delegación’ pueden hacer vulnerable nuestra red a ataques con troyanos.

• Hacer copias de seguridad de archivos y directorios

Permite a los usuarios eludir los permisos de archivos y directorios para realizar una copia de seguridad almacenada en el sistema. Algo como asignar los permisos: Recorrer carpeta / Ejecutar archivo, Listar carpeta / Leer datos, Atributos de lectura, Atributos extendidos de lectura y Permisos de lectura, a todos los archivos y carpetas del equipo local.

• Incrementar prioridades de planificación de procesos

Permite a un proceso con permiso de escritura sobre otro, elevar la prioridad de ejecución del otro proceso. Un usuario con este privilegio puede cambiar la planificación de prioridad de un proceso usando el Administrador de Tareas.

• Modificar valores de entorno de la memoria no volátil(firmware)

Permite la modificación de las variables de entorno del sistema, sea por un proceso o por un usuario desde el cuadro de diálogo de propiedades del sistema.

• Omitir la comprobación de recorrido

Permite al usuario navegar entre directorios que de otra forma no tendría acceso. No permite listar los contenidos sólo atravesarlos. Si no se tiene este privilegio el sistema comprueba las ACL del directorio para asegurarse que el usuario dispone del permiso Recorrer carpeta / Ejecutar archivo.

• Perfilar el rendimiento del sistema

Permite a un usuario usar las herramientas de rendimiento-monitorización para monitorizar los procesos del sistema. Este privilegio es necesario para el complemento de Rendimiento de la consola MMC si está configurado para recoger datos mediante WMI.

• Perfilar un proceso individual

Permite a un usuario usar las herramientas de rendimiento-monitorización para monitorizar procesos que no son del sistema. Este privilegio es obligatorio para el complemento de Rendimiento de la consola MMC  en el caso de estar configurado para recoger datos mediante WMI.

• Quitar el equipo de la estación de acoplamiento

Permite al usuario desacoplar al portátil mediante el interfaz de usuario. Por supuesto los usuarios sin este derecho podrán anular el acople manualmente o mediante pequeños conectores y sacar el portátil de la estación de acoplamiento.

• Realizar las tareas de mantenimiento del volumen

Permite al usuario administrar volúmenes y discos.

• Reemplazar un testigo a nivel de proceso

Permite a un proceso reemplazar el testigo predeterminado asociado a un subproceso que se ha iniciado. Este privilegio sólo debería obtenerse mediante la cuenta de Sistema Local. Se usa, entre otras cosas, para crear testigos restringidos.

• Representar al cliente después de la autenticación
• Restaurar archivos y directorios

Permite a un usuario evitar los permisos de archivo y directorio cuando restaura una copia de seguridad y establecer cualquier objeto principal como el propietario de un objeto.

• Sincronizar los datos de Directory Service

Permite a un proceso leer todos los objetos y propiedades en el directorio, a pesar de la protección de los mismos. Este privilegio es necesario para usar sincronización de servicios de directorio LDAP.

• Tomar posesión de archivos y otros objetos

Permite a un usuario romar posesión de cualquier objeto asegurable del sistema, incluyendo los objetos de AD, archivos e impresoras, impresoras, llaves del registro, procesos e hilos.

Los Derechos de usuario

• Tener acceso a este equipo desde la red

Permite a un usuario conectar con el equipo desde la red.

• Denegar el acceso desde la red a este equipo

Deniega la conexión con el equipo desde la red. Predeterminadamente no está asignado a nadie, a excepción de la cuenta integrada de soporte. El mal uso puede llevar al bloqueo de uno mismo o del sistema.

• Iniciar sesión como proceso por lotes

Permite a un usuario iniciar sesión usando un archivo por lotes. De forma predeterminada está concedido sólo a los administradores. Cuando uno de ellos usa el asistente de añadir una tarea programada para programar una tarea y ejecutarse bajo un usuario y contraseña particulares, este usuario es asignado automáticamente al inicio de sesión como un derecho de proceso por lotes. Cuando llega el momento de ejecutarse, el programador de tareas inicia la sesión del usuario como un proceso por lotes más que un usuario interactivo, y la tarea se ejecuta en el contexto de seguridad del usuario.

• Denegar el inicio de sesión como trabajo por lotes

Deniega al usuario la posibilidad del inicio de sesión usando un proceso por lotes. De forma predeterminada no está concedido a nadie.

• Iniciar sesión como servicio

Permite a un objeto principal iniciar sesión como servicio y establecer un contexto de seguridad. Las cuentas de Sistema Local, Servidor de red y Servicio Local siempre retienen el derecho de iniciar sesión como servicio. Cualquier servicio que se ejecute con una cuenta distinta debe serle concedido el derecho.

• Denegar el inicio de sesión como servicio

Deniega a un objeto principal la posibilidad de iniciar sesión como servicios y establecer un contexto de seguridad.

• Permitir el inicio de sesión local

Permite a un usuario iniciar sesión en el equipo mediante sea con la consola o una sesión de servicios de terminal y con IIS. La configuración de este derecho debe realizarse con precaución puesto que podríamos incluso impedirnos a nosotros mismos acceder al sistema si nos lo quitamos. En Windows Server 2003 es posible que un usuario establezca una conexión mediante una sesión de servicios de terminal contra un equipo específico sin este derecho, debido a la existencia del derecho de ‘permitir inicio de sesión a través de Servicios de Terminal Server’.

• Denegar el inicio de sesión localmente

Deniega al usuario el inicio de sesión a la consola del equipo. Predeterminado a nadie. También ha de aplicarse con precaución ya que podríamos impedirnos a nosotros mismos acceder al sistema.

• Permitir inicio de sesión a través de Servicios de Terminal Server

Permite a un usuario el inicio de sesión usando servicios de terminal en XP y Windows Server 2003. Si concedemos este derecho no es necesario ya añadir al usuario al derecho de inicio de sesión local como lo era en Windows 2000.

• Denegar inicio de sesión a través de Servicios de Terminal Server

Deniega el inicio de sesión al usuario usando servicios de terminal. Si tiene el derecho de inicio de sesión local, podrá hacerlo a la consola del equipo.

Podemos ver los privilegios y derechos de inicio de sesión asignados a equipos y usuarios con showpriv.exe del resource kit, esta herramienta en línea de comandos nos permite, indicándole el nombre del privilegio, conocer las cuentas y grupos que lo tienen asignado. Aunque no lista los servicios que tienen los derechos o privilegios inherentes como LocalSystem.

Con la herramienta whoami y el parámetro /all también obtenemos información sobre los privilegios y derechos.

La única protección de las cuentas de usuario son las contraseñas elegidas por los mismos.

Los usuarios -y en lo que respecta, los administradores- históricamente han sido malos generadores de contraseñas aleatorias y peor aun en mantener el secreto de las mismas. Podemos tener una sensación de seguridad, pero sólo una contraseña débil puede causar la exposición de secretos de la compañía, puede ser utilizada para lanzar con éxito un ataque de denegación de servicio, o sabotear la red. A menos que empleemos métodos de autenticación multielemento para todos los usuarios, debemos implementar configuración de seguridad a las contraseñas.

En Windows Server podemos crear directivas de contraseña a nivel de dominio para todas las cuentas del dominio mediante directivas de grupo, o a nivel de OU para cuentas locales en sistemas que son miembros del dominio.

Valor	Predeterminado 2000/XP	Predeterminado 2003	Rango
Forzar el historial de contraseñas	Una contraseña recordada	24 contraseñas recordadas	0 a 24
Vigencia máxima de la contraseña	42 días	42 días	0 a 999
Vigencia mínima de la contraseña	0 días	1 día	0 a 999
Longitud mínima de la contraseña	0 caracteres	7 caracteres	0 a 14
Las contraseñas deben cumplir los requerimientos de complejidad	Deshabilitado	Habilitado	habilitado/deshabilitado
Almacenar contraseñas usando cifrado reversible	Deshabilitado	Habilitado	habilitado/deshabilitado

*Se cambió en Windows Server 2003 para forzar una seguridad mayor que la predeterminada en windows 2000.

• Podemos forzar a los usuarios a variar sus contraseñas habilitando el historial de contraseñas. Si no la habilitamos el usuario podrá reutilizar una contraseña a pesar incluso de haber caducado.
• Con la vigencia máxima y mínima configuramos el tiempo durante el que pueden usar una contraseña sin tener que cambiarla y el mínimo que tendrá vigencia –para evitar que un usuario listo la cambie el número de veces establecido en el historial y reúse la antigua.. Esta configuración puede estar sobrescrita por el valor de ‘la contraseña nunca caduca’ en las cuentas, y que normalmente nos sirve en aquéllas cuentas que no necesitan iniciar sesión interactiva y por tanto no es necesario ningún aviso de que la contraseña va a caducar.
• La longitud mínima obliga a un mínimo de caracteres en la contraseña. Lo recomendado estaría entre 12 y 14 caracteres.
• Los requerimientos de complejidad, sin entrar en detalles ni motivaciones, obligarán al uso de caracteres incluidos en las siguientes 5 categorías:
  • Letras mayúsculas
  • Letras minúsculas
  • Números
  • Caracteres no alfanuméricos (@#$%&/()=?[]{}<>,.;:~-_|`^+*)
  • Caracteres Unicode (por ejemplo, €)

  Las cuentas de equipo también tienen contraseña. Cuando un equipo se une a un dominio, se generan una contraseña con l que autenticarse. Esta contraseña es la clave cifrada para configurar canales seguros entre el equipo y los controladores de dominio. La contraseña se genera usando CryptoGenRand y se cambia cada 30 días de manera predeterminada. Un equipo una vez autenticado, las cuentas de equipo pertenecen al grupo de usuarios autenticados, el equipo puede ser objetivo de ataques que pueden comprometer físicamente a mismo y poder ser usado para acceder a recursos seguros permitidos a éste grupo. La contraseña de la cuenta del equipo se asegura por System Key en el equipo local.

  Unas líneas básicas que se recomiendan en la creación de contraseñas son:

  • Evitar el uso de palabras comunes o sin faltas de ortografía, y palabras extranjeras.
  • Evitar el aumento de su longitud añadiendo un dígito.
  • Evitar el uso de palabras que otros pueden fácilmente observar en tu escritorio (equipo preferido, miembros familiares, nombres de mascotas,…).
  • Evitar  el uso de palabras o frases conocidas de la cultura popular (refranes, citas,…)
  • Evitar el pensar en las contraseñas como palabras pensadas como códigos secretos.
  • Usar contraseñas que nos obliguen a utilizar ambas manos escribiendo desde el teclado.
  • Usar letras mayúsculas y minúsculas, número y símbolos en todas las contraseñas.
  • Usar frases como ‘Como hay que saltar a la comba?’
  • Ausencia de restricciones del sistema, apostar siempre por la longitud
  • Envolver la contraseña con caracteres; como BIENBIENBIENBIEN, lo que añadiría 16 caracteres.
  • Usar el carácter espacio en blanco dentro de la contraseña.
• Almacenar las contraseñas utilizando cifrado reversible es un valor de uso en los controladores de dominio.

Una recomendación de configuración sería:

– Recordar 24 contraseñas

– 42 días máximo de vigencia

– 2 días mínimo de vigencia

– 8 caracteres mínimo (mejor 12 a 14)

– Requerir que la contraseña sea compleja.

– Cifrado reversible deshabilitado para los usuarios del dominio.

Configuración de bloqueo de cuentas

También podemos definir directivas de bloqueo de cuentas en todo el dominio o cuentas locales en equipos individuales con las directivas de seguridad local. Deben configurarse tres valores cuando definimos una directiva de bloqueo de cuenta:

Valor	Predeterminado	Rango
Umbral de bloqueos de la cuenta	nada	0, nunca se bloqueará. 1 a 999 intentos.
Duración del bloqueo de cuenta	deshabilitado	0, obligará a un administrador a desbloquearla. 1 a 99,999 minutos.
Restablecer la cuenta de bloqueos después de	nada	1 a 99,999 minutos. Debe ser menor o igual al establecido para la duración del bloque de cuenta.

Con esto hay que tener presente que un atacante podría llevar acabo una denegación de servicios bloqueando todas las cuentas de usuario, incluyendo las de servicios con la ejecución de un vbscript (ADSI).

Quizás el mejor enfoque sea una correcta preparación de los usuarios para la creación de contraseñas fuertes y una auditoría de los sucesos de inicio de sesión (revisándolos para detectar ataques de fuerza bruta o de diccionario).

If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will sucumb in every battle. – The Art of War, Sun Tzu   Si te conoces tanto a ti como a tu enemigo, no temas el resultado ni de cien batallas. Si sólo te conoces a ti pero no a tu enemigo, perderás tantas batallas como tantas ganes. Si no te conoces ni a ti ni a tu enemigo, sucumbirás en cada una de ellas. – El arte de la guerra, Sun Tzu hace más de 2000 años.

Las cuentas son la unidad central de seguridad en equipos ejecutando Microsoft Windows Server 2003, Windows 2000, Windows XP y las aplicaciones que se ejecutan en ellos.

Los derechos y permisos se asignan a las cuentas y comprobados por los recursos en el momento de su acceso. Debe entenderse que usuario y cuenta de usuario no es la misma entidad. Cualquiera en posesión de las credenciales asociadas a una cuenta de usuario puede usar dicha cuenta, a pesar del nombre del que la use -un equipo controlará y auditará el acceso a sus recursos basándose en el token de cuenta de usuario, nunca en la identidad física de la persona que la esté usando.

Seguridad de cuentas

Cada cuenta de usuario, equipo o grupo es un objeto principal de seguridad en los sistemas ya mencionados. Estos objetos reciben permisos para acceder a los recursos. Los derechos de usuario se permiten o niegan a las cuentas directamente o por su pertenencia a un grupo. La suma de estos permisos y derechos definen lo que los objetos principales de seguridad pueden y no pueden hacer en la red.

Las cuentas de usuario se encuentran o en un ámbito local o un ámbito de dominio., Tanto en Windows 2000 como en Windows Server 2003 server las cuentas de dominio se almacenan en la base de datos de directorio del Directorio Activo(Ntds.dit) en controladores de dominio , mientras que la cuentas locales se almacenan en una base de datos SAM individual (Security Accounts Manager) de las estaciones de trabajo o servidores miembros tanto si están como sino unidos al dominio. Las cuentas de dominio pueden ser utilizadas para autenticarse frente a cualquier equipo en el bosque, y en cualquier dominio con relación de confianza ,en el que la cuenta exista, mientras que las cuentas locales sólo autentican para el acceso a recursos en el equipo local.

SID’s

Aunque la referencia de cuentas de usuario se realiza usando el nombre o el nombre universal principal (UPN), el sistema operativo internamente las referencia por su identificador de seguridad (SID). Para cuentas de dominio el SID se crea con la concatenación del SID del dominio y un identificador relativo (RID) para la cuenta. Los SID’s son únicos dentro de su ámbito (Local o de dominio) y nunca se reutilizan. Un ejemplo:

S-1-5-21-388323654-654782038-156896542-1470
S-revisión-autoridad-subautoridad-identificador relativo

• Revisión

Valor indicador de la versión de la estructura del SID utilizada. El valor actual es 1.

• Autoridad identificadora

Valor que identifica a la autoridad que puede emitir SIDs para este aprticular tipo de objeto principal de seguridad. El valor de la autoridad identificadora del SID de una cuenta o grupo en Windows Server 2003, Windows 2000 y Windows XP es 5 para NT Authority.

• Subautoridades

La información más importante en un SID está contenida en una serie de uno o más valores de subautoridad. Todos los valores de la serie sin incluir el último, identifican colectivamente a un dominio en una empresa. Esta parte se conoce como identificador de dominio. El último valor en la serie identifica una cuenta particular  o grupo relativo a un dominio. Este valor es el RID. En el ejemplo 1470.

Predeterminadamente diversos objetos principales de seguridad son creados durante la instalación del sistema operativo o dominio; los SID’s para estas cuentas se denominan SID’s conocidos.

SIDs conocidos Windows 2000

Windows Server 2003 – SID’s conocidos

 

Cuando un usuario inicia sesión correctamente en la red, se crea un token de acceso. Una copia del mismo se adjunta a cada proceso e hilo que se ejecuta de parte del usuario. El token de acceso se usa por el equipo para determinar si el usuario dispone de la autoridad apropiada para acceder a la información o para realizar una acción u operación. El contenido de un token incluye:

• El SID de la cuenta.
• Una lista de SIDs de los grupos de seguridad que incluye la cuenta. En un dominio en modo nativo, la lista también incluye el SID almacenado en el atributo SID-History de la cuenta.
• Una lista de los derechos y privilegios de inicio de sesión que la cuenta posee directamente o por su pertenencia a grupos de seguridad.
• El SID del usuario o grupo de seguridad quién, por defecto, se convierte en propietario de cualquier objeto que el usuario creó o tomó posesión de él.
• El SID del grupo de seguridad primario del usuario. Esto se usa por el subsistema POSIX cuando se utiliza el servidor de archivos para Macintosh o el servidor de impresión para Macintosh para proporcionar servicios de archivos o impresión desde equipos con Windows NT o superiores a clientes Macintosh.
• El proceso que causó la creación del token (Sesion manager, LAN manager, o RPC).
• Un valor indicando si el token es un primary token o un impersonation token. El primero es el que representa el contexto de seguridad de un proceso, mientras el segundo es un token de acceso que en un hilo dentro de un proceso  de servicio puede usarse para adoptar un contexto de seguridad temporal para el cliente del servicio.
• Un valor que indica en qué medida un servicio puede adoptar el contexto de seguridad de un cliente representado por este token de acceso.
• Información sobre el propio token de acceso. Esta información la usa el sistema operativo internamente.
• Una lista opcional de SID’s añadidos a un token de acceso por un proceso con autoridad para crear un token restringido. SID’s restringidos pueden limitar el acceso de un hilo a un nivel más bajo que el permitido al usuario.
• Un valor que indica si el token está asociado con la sesión de inicio de sesión del cliente.

Podemos saber los detalles de nuestro token de acceso con el comando:

 whoami /all

Las cuentas disponen de una opciones de seguridad que hemos de configurar para afinar la configuración por defecto proporcionada. El directorio activo nos permite asegurar las cuentas de usuario individualmente de varias formas, que incluyen las siguientes opciones:

Horas de inicio de sesión.

Determina los días y horas de la semana, en periodos de una hora, en los que el usuario puede iniciar sesión en la red. Directiva de grupo proporciona una configuración para cerrar la sesión de un usuario forzosamente cuando el horario de sesión permitido ha expirado.

Iniciar sesión en.

Restringe a las cuentas el inicio de sesión interactiva a sólo los equipos de la red especificados.

El usuario debe cambiar la contraseña en el siguiente inicio de sesión.

Fuerza al usuario a cambiar su contraseña la próxima vez que inicie sesión interactiva. Esto es útil para nuevas cuentas y forzar los cambios de contraseña aleatorios.

El usuario no puede cambiar la contraseña.

Este valor impedirá a los usuarios cambiar su contraseña. Opción utilizada en cuentas compartidas, como las de los internet shop.

La contraseña nunca caduca.

Exceptuando si las directivas de grupo establecidas en el dominio respecto a la caducidad de las contraseñas dicen lo contrario, esta opción es para que la contraseña de la cuenta nunca caduque. Normalmente se establece en cuentas no interactivas y que no reciben avisos de caducidad, cuentas usadas en servicios por ejemplo.

Almacenar la contraseña usando cifrado reversible.

Almacenar las contraseñas de tal manera que puedan ser descifradas por el sistema operativo y ser comparadas con contraseñas en texto plano. Esta opción necesita si se usa protocolos como CHAP o SPAP para la autenticación. Si esta opción está seleccionada, la próxima vez que el usuario cambie su contraseña, la nueva se almacenará utilizando cifrado reversible. El hash es enviado a través de la red para propósitos de autenticación, entonces se descifra y compara con la copia de la contraseña en texto plano. Se usa sólo en cuentas que necesitan texto plano para que la contraseña sea conocida por el controlador de dominio, como las usadas en la autenticación de resumen IIS o desde equipos Macintosh.

Cuenta deshabilitada.

Impide que la cuenta pueda usarse, pero no la elimina. Hay elementos asociados a la cuenta por los cuales no queremos eliminarla, aunque ya no es necesaria para iniciar ninguna sesión del usuario y la deshabilitamos por seguridad.

La tarjeta inteligente es necesaria para un inicio de sesión interactivo.

Requiere que se utilice una tarjeta inteligente para iniciar sesión, incluyendo inicios de sesión de Terminal Services o Inicio de Servicios, pero no inicios en la red. Aquéllos usuarios con esta opción establecida no tienen permitido el inicio de sesión mediante su nombre y contraseña. En Windows 2000 la contraseña que se usó antes de establecer esta opción no se elimina, en XP y Windows Server 2003 se resetea automáticamente.

Se confía en la cuenta para su delegación.

Habilita a los servicios que se ejecutan con esta cuenta, llevar a cabo operaciones de parte de otra cuenta de usuario o equipo. La opción está disponible tanto para cuentas de usuario como de equipo y se viene utilizando con aplicaciones que se ejecutan en servidores web. Solo deberíamos establecerla si sabemos que es necesario para una funcionalidad correcta de una aplicación distribuida. Además, para usuarios que usen EFS para cifrar archivos en servidores remotos, la cuenta del servidor debe ser confiada para delegación para que el servidor pueda generar el perfil local para la cuenta y el usuario que usará las claves del usuario. Todos los controladores de dominio en AD están implícitamente confiados para delegación. Configurado en Windows Server 2003 en la pestaña de delegación de las propiedades de la cuenta.

Si un atacante compromete un equipo con el que se confía para delegación podría ser capaz de usar las credenciales de cualquier usuario o equipo que se autentique con el equipo comprometido para acceder a otros recursos de red.
Esto significa que dichos equipos had de ser protegidos, fisica y lógicamente, de igual forma que los controladores de dominio.

 La cuenta es importante y no se puede delegar.

Impide que la cuenta se delegue.

Usar tipos de cifrado DES para esta cuenta.

Habilita a la cuenta para usar DES, que es compatible con múltiples niveles de cifrado, para interoperabilidad con los mundos Kerberos basados en Unix, más que el algoritmo RC4 usado por defecto en Windows 2000 y 2003.

No pedir la autenticación Kerberos previa.

Deshabilita la autenticación previa de Kerberos que se usa de forma predeterminada, para interoperabilidad con MIT Kerberos v4.

La cuenta caduca.

Deshabilita automáticamente una cuenta en una fecha determinada.

Importante: No podemos establecer las opciones siguientes en la cuenta integrada de Administrador en Windows 2000, aunque sí se puede en Windows Server 2003: * La contraseña nunca caduca * Almacenar la contraseña usando cifrado reversible * Cuenta deshabilitada * La tarjeta inteligente es necesaria para un inicio de sesión interactivo * Se confía en la cuenta para su delegación * La cuenta es importante y no se puede delegar * Usar tipos de cifrado DES para esta cuenta * No pedir la autenticación Kerberos previa

 

Seguridad en cuentas administrativas

A pesar de la seguridad implementada en una red, siempre tenemos una colección de cuentas de usuario que están intrínsecamente confiadas a los administradores. Estas cuentas disponen de permisos y derechos que las habilitan para poder causar trastornos en cualquier mecanismo de seguridad mediante sus derechos innatos, sea mediante elevación de privilegios o comprometiendo el software o el hardware. Aunque puede que se haya investigado a fondo a los administradores durante el proceso de contratación, la cuenta de administrador en la mayoría de las redes es solo una cuenta mal protegida o con una contraseña mal creada. Una vez comprometida, una cuenta de este tipo es un pasaporte sin trabas para la entrada e la red entera y a todos los datos que hay en ella. Por lo tanto, es primordial proteger y asegurar las cuentas de administradores. Además de las opciones que son aplicables a las cuentas, podemos considerar las prácticas siguientes para estas cuentas:

• Mínima cantidad de cuentas que tengan acceso de administrador. Podemos delegar autoridad sobre cada objeto de AD y el sistema de archivos. Además, la mayoría de servicios instalan grupos especiales de administración.
• Utilizar grupos restringidos para controlar la pertenencia en grupos administrativos. Los grupos restringido en directivas nos permiten controlar la pertenencia a grupos automáticamente. Los controladores de dominio refrescan las directivas cada 5 minutos predeterminadamente; por lo tanto, cada cinco minutos, las cuentas que no están definidas en la configuración de directiva de grupos restringidos son eliminadas del grupo de seguridad. Si auditamos los sucesos de administración de cuentas, la aplicación de esta directiva quedará registrada en el registro de sucesos de seguridad con un ID 637. El ID de llamante en el mensaje de error listará el nombre de equipo del controlador de dominio en el que se produjo el cambio en vez del nombre de cuenta de usuario.
• Solicitar autenticación de factor múltiple. Podemos obligar a autenticación con tarjeta inteligente para cuentas con acceso administrativo, miembros especiales del grupo de administradores de organización o del grupo de administradores de dominio. Así puede que evitemos riesgos asociados a las contraseñas y añadimos un elemento físico de seguridad en el uso de las cuentas de administrador.
• Restringir el uso de cuentas de administrador en equipos determinados. Ya que un atacante puede fácilmente con las credenciales de un administrador si previamente ha comprometido un equipo donde inicia sesión un administrador, las cuentas de administrador sólo deben usarse en equipos de confianza donde se evite el compromiso, con la consola de servidor por ejemplo. Con esto creamos algunos inconvenientes de administración, sin embargo, para necesidades de alta seguridad, podemos usar la opción de inicio de sesión de una cuenta de equipo para restringir el inicio interactivo de cuentas de administrador en ciertos equipos. Combinando este valor con una buena seguridad física de los equipos en que se restringe el uso de la cuenta, aumentamos la seguridad de la cuenta de administrador.
• No usar cuentas de administrador para rutinas diarias. No hay que navegar por internet, leer el correo, etc… con una cuenta de administrador; podemos limitar los daños de cualquier virus o troyano si usamos en su lugar un inicio de sesión secundario (RunAs), o alguna utilidad como **RunAsAdmin para equilibrar el uso de las cuentas y las rutinas diarias.
• No permitas a los usuarios ser administradores locales. A menos que tengamos una razón clara y necesaria técnicamente para ello, debemos prohibir a los usuarios tener privilegios de administrador local. Los usuarios con estos privilegios pueden modificar la configuración del equipo, tienen acceso total al sistema operativo y al registro.
• Examina a los empleados antes de concederles acceso administrativo. Junto al departamento de recursos humanos, evaluar a a los administradores de la red durante su contratación para impedir dar permisos a administradores potencialmente maliciosos o demasiado descuidados.
• Bloqueo de servidores y equipos. Bloquear servidores y equipos sin atención es importante cuando se usan cuentas con derechos administrativos. Un atacante necesita pocos segundos en un equipo con sesión iniciada para comprometer el sistema. Directivas de bloqueo si la tarjeta inteligente es retirada.

** RunAsAdmin

Sus opciones, lo que nos servirá para establecer con que privilegios se ejecutará por defecto el shell, en principio Usuario normal:

Si lo tenemos instalado en un Windows Server 2003 o XP se nos añade un icono en el systray. Pinchando en él, se nos ofrece la opción Ejecutar como y seleccionandola se nos pedirá con que nivel de privilegios, selecciono Usuario Normal.

El cuadro para elegir el qué ejecutar con ese nivel de privilegios, utilizo el botón buscar para escoger el ejecutable(u otro) y selecciono el Iexplore.exe. Aceptar y vemos la ventana del navegador. El programa añade en la barra de título el nivel de su ejecución. En este caso en mi equipo aparece otro, un add-on de Aaron Margosis para IE que tengo instalado, con el añadido del color verde que me indica que navega bajo protección de una cuenta con niveles bajos de privilegios.

 

¿Que qué pasa si hubiera elegido sin restricción? Pues en este caso el IExplore muestra que lo estoy ejecutando con nivel de administrador y mi privbar me luce de color rojo.

Al que le haya gustado la utilidad de sysinternals y le guste más usar un GUI para ejecutar el comando, http://www.penguinbyte.com/software/ezexecute/.

Para poder asegurar nuestros servidores no hay mejor camino que entender el concepto de seguridad en estos casos. La seguridad es como un gran mapa que hay que entender para saber como asegurar los servidores y las redes y saber sus limitaciones, con ello podemos evitar pérdidas de tiempo, dinero y energía intentando medidas de seguridad imposibles o impracticables.

Siempre hay que pensar con la Seguridad:

En términos de asignación de los privilegios más bajos que se necesiten para realizar una tarea. Si una aplicación con privilegios altos se ve comprometida, el atacante podría ser capaz de extender el ataque más allá de lo que debería qué si la aplicación se ejecutará con el nivel más bajo de privilegios posible. Por ejemplo: ¿Qué pasaría si un usuario con cuenta de administrador del dominio abriese un email que contiene un adjunto que lanza un virus? Pues que el virus se ejecutaría con esos privilegios. Así que mediante el uso del nivel más bajo de privilegios reduciríamos el alcance de la posible infección.

Defensa en profundidad. Imaginemos la seguridad de nuestra red como si fuera una cebolla. Cada capa que añades te aleja más de su centro, donde existe nuestro más crítico activo. Defender cada capa en nuestra red como si la defensa de la siguiente sea inefectiva o inexistente. La seguridad agregada de nuestra red aumentará significativamente si defendemos y vigilamos en todos los niveles e incrementamos la tolerancia a fallos de la seguridad.

Reducir la superficie de ataque. Los atacantes son ilimitados y su tiempo también, mientras nosotros disponemos de poco tiempo y pocos recursos. Un atacante necesita saber una sola vulnerabilidad para atacar nuestra red con éxito, y nosotros debemos señalarlas todas para defenderlas. Reducir la superficie de ataque es la mejor opción que tenemos que considerar para proteger nuestros activos. Los atacantes encontrarán pocos objetivos y tendremos menos a monitorizar o mantener.

Evitar suposiciones. Las suposiciones generalmente nos llevan a pasar por alto, descartar prematuramente, o, evaluar incorrectamente detalles críticos. Con frecuencia estos detalles no son obvios o están escondidos dentro de procesos o tecnologías. Motivo por el que tenemos que probar y probar y probar!

Proteger, detectar y responder. Debido a que presumiblemente en algún momento parte de la seguridad falle, si pensamos en la seguridad de un equipo o de una red, pensaremos en cómo podemos proteger de forma pro-activa, detectando y respondiendo a los intentos de intrusión o incidentes de seguridad. Es un ciclo de vida de la seguridad simple. Desde este punto de vista hemos de estar preparados lo mejor posible para manejar sucesos impredecibles.

Asegurar con diseño, de forma predeterminada y con implementación. Cuando se diseña una red hay que asegurarse de cumplir ciertos criterios:

• El diseño incluye la seguridad como un componente integral.
• El diseño es seguro de forma predeterminada.
• La implementación y su administración en curso mantiene la seguridad de la red.

Si cumplimos estos tres objetivos, podremos abordar la seguridad de forma pro-activa y nativa más que reactiva y artificial. Agregar la seguridad al final es una forma excelente de asegurar una forma de tener múltiples vulnerabilidades disponibles para los atacantes.

Releyendo encontré la referencia al artículo de Scott Culp que publicó en el sitio web de Microsoft, «10 Immutable Laws of Security» al que le siguió el «10 Immutable Laws of Security Administration» allá por el 2000.