Auditorías: auditando sucesos de administración de cuentas

Ya que cualquiera con acceso a una cuenta administrativa tiene la autoridad de conceder a otras cuentas derechos y privilegios aumentados y además, crear cuentas adicionales, la auditoría de estos sucesos se convierte en una parte primordial del diseño e implementación de la seguridad de red en una organización. A menos de que dispongamos de métodos sofisticados de identificación, biometrías y medidas de alta seguridad, puede ser difícil e incluso imposible garantizar que la persona que usa una cuenta administrativa es el usuario a quien realmente le pertenece. Asimismo, auditarlos es una de las maneras en que una organización puede responsabilizar de sus acciones a los administradores.

Habilitando la auditoría de estos sucesos nos permitirá grabar eventos como:

  • Cuando se crea, cambia o elimina una cuenta de usuario o grupo.
  • Cuando se renombra, deshabilita o habilita una cuenta de usuario.
  • Cuando se establece o cambia una contraseña.
  • Cuando se cambia una directiva de seguridad de un equipo.

Aunque los cambios en los derechos de usuario aparecen como sucesos de administración de cuentas a primera vista, en realidad son sucesos de cambio de directivas. Si ambas directivas de auditoría están deshabilitadas, un administrador pícaro puede ser capaz de superar la seguridad de una red sin dejar rastro.

Debemos habilitar la auditoría tanto de aciertos como de errores de los sucesos de administración de cuentas. Los aciertos generan una entrada cuando cualquier suceso se produce con éxito. Los errores, en cambio, generan una entrada de los sucesos fallidos. Aunque los eventos con éxito son más a menudo que no, completamente inocentes, nos proporcionan una grabación de actividades invalorables cuando una red ha sido comprometida.

Eventos más comunes:

events

Configurando auditorías

Los Windows nos proporcionan varias categorías de auditorías para sucesos de seguridad. Cuando diseñamos nuestra estrategia, necesitaremos también ver que sucesos de aciertos y fallos incluimos de entre las categorías existentes:

  • Sucesos de inicio de sesión de cuentas
  • sucesos de administración de cuentas
  • acceso al servicio de directorio
  • sucesos de inicio de sesión
  • acceso a objetos
  • cambios de directivas
  • uso de privilegios
  • seguimiento de procesos
  • sucesos de sistema

Podemos observar el estado actual de las auditorías para cada área usando la MMC de directivas de seguridad.

auditoria

Sucesos de inicio de sesión de cuentas

Cuando un usuario inicia sesión en un dominio, el proceso se procesa en un controlador de dominio(en adelanta DC). Cuando auditamos los sucesos de inicio de sesión de cuentas en todos los DC, los intentos de inicio de sesión se registrarán en el DC que valida la cuenta. Estos sucesos se crean cuando un paquete de autenticación valida –con éxito o no- las credenciales de un usuario o equipo. Cuando se usan credenciales de dominio los sucesos de inicio de sesión de cuentas se generan sólo en los registros de sucesos de los DC. En cambio si las credenciales son de equipo local, estos sucesos se crean en los registros de sucesos del servidor o equipo localmente.

Si definimos esta configuración de directiva, debemos especificar si auditamos los aciertos o los errores. Los primeros sólo generan una entrada de auditoría si el inicio de sesión tiene éxito y los segundos cuando hay un error.

La auditoría de los aciertos nos proporciona una grabación de los inicios de sesión de usuarios o equipos en un dominio o equipo local. Mientras que la de los errores puede darnos pistas sobre intentos de intrusión comprometiendo alguna cuenta.

Al examinar los aciertos y los errores dispondremos, no sólo de la cuenta –o del SID de la cuenta- que inicia sesión, sino también de:

  • Nombre del equipo en que se originó el intento de inicio de sesión. Si se tratase de un ataque suelen usarse caracteres no imprimibles en el nombre del equipo utilizado para enmascarar su identidad en el visor de eventos.
  • Nombre del dominio o de equipo de la cuenta que podría usarse desde un equipo en grupo de trabajo para intentar un ataque.
  • Los tipos de intentos de inicio de sesión:
    • Tipo

      Nombre

      Descripción

      2 Interactivo Incluye tanto el inicio desde Servicios de Terminal en Windows 2000 como los que están frente a la máquina físicamente.
      3 Red Acceso a archivos e impresoras, normalmente.
      4 Lote Iniciado mediante un proceso con derechos de inicio de sesión por lotes.
      5 Servicio Iniciado por servicios usando el inicio de sesión como servicio.
      6 Proxy No se ha implementado en ninguna de las versiones de Windows.
      7 Desbloqueo Se graba al desbloquear la consola de un equipo.
      8 Red texto claro Reservado para inicios de sesión con texto claro en la red.
      9 Nuevas credenciales Iniciado mediante el comando Run As (Ejecutar como) con el parámetro /netonly
      10 Interactivo remoto Inicios desde Servicios de Terminal en Windows Server 2003 y Windows XP.
      11 Interactivo de caché Se han usado las credenciales de la caché para el inicio de sesión en local en un equipo.
      13 Desbloqueo en caché Se desbloquea el equipo y las credenciales del usuario se han comprobado contra credenciales previamente cacheadas.
  • El proceso que origina el inicio de sesión que puede ser uno de los siguientes:
    • Advapi: Para llamadas de API para LogonUser.
    • IIS: Para inicios usando la cuenta anónima o intentos de inicio usando autenticación básica o de texto.
    • LAN manager: Para intentos usando el protocolo Lan Manager.
    • Kerberos: Para llamadas desde el proveedor de seguridad de Kerberos.
    • KSecDD: Para conexiones de red.
    • MS.RADIU: Para intentos de inicio de sesión desde IAS.
    • NTLM o NtLmSsp: Para intentos de inicio de sesión usando el protocolo NTLM.
    • Service Control Manager: Intentos de inicio de sesión de servicios.
    • Seclogon: Para intentos de inicio de sesión usando el comando Run As.
    • User32 o WinlogonMSGina: Para intentos de inicio de sesión interactivos.
  • El paquete de autenticación utilizado, que puede ser uno de los siguientes:
    • Kerberos
    • Negociado
    • NTLM
    • Microsoft_Authentication_Package_v10
  • La IP y el puerto origen del intento de inicio de sesión en Windows Server 2003 solamente.

Los Event Id con los que nos podemos encontrar en los sucesos de inicio de sesión de cuenta más comunes son:

Event ID Descripción
672 Un ticket de autentificación de servicio fue correctamente emitido y validado.
673 Se concedió un ticket del servicio de concesión de tickets.
674 Un principal de seguridad ha renovado un ticket del servicio de autentificación o del servicio de concesión.
675 Ha fallado la pre-autentificación de Kerberos
676 La solicitud del ticket de autentificación ha fallado. //No implementado en 2003 ni XP.
677 No se concedió un ticket del servicio de concesión de tickets. //No implementado en 2003 ni XP.
678 Una cuenta se mapeó con éxito a una cuenta de dominio.
679 Error en el mapeo de una cuenta a una cuenta de dominio.
680 Se identificó a la cuenta usada para el intento de inicio de sesión con éxito. También indica el paquete de autentificación utilizado para la autentificación de la cuenta.
681 Intento de inicio de sesión fallido con una cuenta de dominio. //No implementado en 2003 ni XP, en su lugar se graba un 672.
682 Un usuario ha reconectado una sesión de servicios de terminal desconectada.
683 Un usuario ha desconectado su sesión de servicios de terminal sin cerrar sesión. Las sesiones de TS pueden permanecer en un estado de conexión que permite a los procesos continuar ejecutándose después de finalizar la sesión. Un Evento 683 indica cuando el usuario no ha cerrado sesión y el evento 682 cuando se recupera la conexión previamente desconectada sin ser cerrada.

En Windows 2000 un error en el inicio de sesión genera un 681 y éste a su vez contendrá código que nos dará la razón del error de autenticación. El código aparece en valores decimales. Por ejemplo:

code2000681 

3221225572 La cuenta usada es incorrecta o está mal escrita.
3221225578 La contraseña usada es incorrecta o está mal escrita.
3221225583 Se está intentando iniciar sesión fuera de las horas permitidas.
3221225584 Se está intentando iniciar sesión desde un equipo no autorizado.
3221225585 La contraseña utilizada está caducada.
3221225586 La cuenta de usuario está deshabilitada por el administrador
3221225875 La cuenta está caducada.
3221226020 Se ha iniciado sesión con la bandera de cambiar contraseña al próximo inicio.
3221226036 La cuenta está bloqueada.

¿Auditorías? Claro, por qué no!

Alguien pensará en las vacaciones que me he tomado, je je je, pues va a ser que no. Un pequeño contratiempo de salud me llevó un día a La Paz(Madrid) y desde ese momento, visita al Teched de Barcelona incluída, fuí mermando día a día hasta que una chica rubia y lista, cirujana ella, encontró el problema y lo solucionó rápida y excelentemente; mi agradecimiento irá siempre con ella. En fin, después de un merecido descanso de recuperación, cambio de puesto de trabajo, estancia en USA y vuelta a España, me encuentro con ganas de contaros alguna cosilla sobre Windows Server.

Se dice, nos dicen, se nos aconseja, …, tener una estrategia de seguridad y que ésta a su vez no es completa sin una estrategia de auditorías integral. Con más frecuencia que no, las empresas aprenden por la vía del dolor –sólo cuando sufren incidentes de seguridad. Sin un seguimiento auditado de las acciones hechas por el intruso, es casi imposible investigar un incidente de seguridad que haya tenido éxito. Como parte de una estrategia general de seguridad, debemos determinar cuales eventos necesitamos auditar, el nivel de auditoría apropiado a nuestro entorno, como debe recogerse la información auditada y, como debemos revisarla.

Debemos habilitar las auditorías y vigilar los registros(logs) auditados, porque hay que tener una línea básica de las operaciones normales de equipos y red; para detectar intrusiones en los equipos o la red y por determinar cuales sistemas y datos se han visto comprometidos durante o después de un incidente de seguridad.

Aunque muchos no lo comprenderán y serán esquivos a prestar recursos para realizarlo, revisar los logs de auditoría regularmente, con herramientas dedicadas, puede ayudarnos a prevenir daños futuros a la red o a los equipos una vez alguien haya conseguido penetrar en la red pero no haya causado excesivos daños.

 

¿Qué eventos auditar?

Como primer paso de nuestra estrategia de auditoría hemos de determinar que tipos de acciones u operaciones registrar. ¿Qué eventos del sistema operativo debemos auditar? La respuesta no es difícil, todos. Desafortunadamente, auditar todos los eventos puede requerir recursos excesivos y afectar negativamente al rendimiento general. Tengamos presente que cuanto más auditemos, más eventos se generan y más difícil será detectar los eventos críticos.

Si nuestro plan es revisar los eventos manualmente o si no tenemos claro cómo leerlos, puede ser extremadamente difícil aislar aquéllos que son peligrosos potencialmente de los que no lo son. Puede que necesitemos junto a otros compañeros revisar y determinar cuales son los eventos a auditar. Auditar aquéllos eventos que se crea nos serán de utilidad para una referencia posterior. Aunque es más fácil decirlo que hacerlo, muchos de estos eventos aparentemente serán fáciles.

Si no tenemos una política de seguridad implantada a nivel de empresa de auditoría, una forma bastante efectiva de buscar los eventos a auditar es juntar a un grupo de trabajadores de puestos relevantes y discutirlo. En definitiva hemos de decidir:

  • Acciones u operaciones a seguir.
  • Equipos a los que se les aplicarán dichas acciones u operaciones.

En los sistemas Windows Server 2003, Windows 2000 y Windows XP, podemos clasificar los eventos de auditoría en dos categorías: los aciertos y los errores. Los primeros indican que la acción u operación se ha completado con éxito por el sistema, mientras que los segundos indican que se ha intentado pero no se ha conseguido. Los eventos con error son útiles en el seguimiento de intentos de ataque al entorno; los eventos con éxito son de mayor dificultad de interpretación. Aunque la mayoría de eventos auditados con éxito son simples indicaciones de una actividad normal, un atacante que pretende conseguir acceso al sistema también generará estos sucesos. Frecuentemente una pauta de eventos es tan importante como el propio evento.

El visor de eventos

Todos los eventos de seguridad se graban en el registro de seguridad del visor de eventos. Además, los eventos relacionados pueden grabarse en los registros de aplicación y de sistema.

Antes de habilitar las directivas de auditoría, comprobamos la configuración predeterminada activa de los archivos de registro de seguridad en el visor, y que se muestran en,

Inicio->Herramientas administrativas->Visor de sucesos

Clic derecho en Seguridad, propiedades.

securitypropertieseventviewer

En cada registro de eventos, no sólo en seguridad, determinamos:

  • Un lugar para guardar los registros
  • Tamaño máximo de archivo de registro
  • Comportamiento de reemplazo

De forma predeterminada el registro de sucesos de seguridad se guarda en el archivo SecEvent.evt dentro del directorio %systemroot%system32config, aunque nosotros podemos editar el registro y cambiar dicha ubicación para cada uno de los archivos de registro. La ruta y el nombre de archivo para el registro de seguridad se encuentran en el valor del registro HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlogSecurity.

Tened en cuenta que de forma predeterminada el acceso al registro de seguridad sólo se permite a la cuenta del sistema y a los administradores, para evitar accesos de no-administradores, así que si movemos el lugar donde se van a guardar hay que prever el tipo de permisos a aplicar a dicho lugar. Además, como el servicio Event log no puede detenerse, los cambios de estos valores no se aplicarán hasta reiniciar el servidor.

En Windows Server 2003 podemos cambiar los permisos sobre los registros de aplicación y de sistema, pero no del de seguridad(Configurar el registro de sucesos localmente o mediante la directiva de grupo en Windows Server 2003).

Asimismo, el tamaño máximo de archivo está predeterminado a 16MB, antes de que el comportamiento establecido de reemplazo se inicie en Windows Server 2003, y de 512KB en Windows XP y Windows 2000. Como los discos duros de hoy son más que grandes en comparación con los anteriores, sería mejor incrementar este tamaño, siempre en relación al comportamiento de reemplazo que deseemos implantar. Según la arquitectura del servicio de sucesos, el tamaño acumulado no debería sobrepasar los 300MB. Cada suceso de seguridad ocupa entre 350 y 500 bytes, así que en unos 10MB cabrían entre 20000 y 25000 sucesos.

El tamaño lo podemos cambiar de forma individual en la página de propiedades del registro de seguridad del visor de sucesos o editando el registro. Tambíen podemos implementar el cambio en varios equipos usando plantillas de seguridad de directiva de grupo. El tamaño para este registro está en la clave del registro HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlogSecurityMaxSize.

 

Finalmente, al configurar la configuración del registro de sucesos de seguridad debemos definir qué pasará si se alcanza el tamaño máximo definido de archivo, conocido como comportamiento de reemplazo. Hay tres valores para dicho comportamiento:

  • Sobrescribir sucesos cuando sea necesario. Los sucesos se guardarán aunque se haya alcanzado el tamaño, máximo, cada nuevo sucesos reemplazará al más antiguo.
  • Sobrescribir sucesos que tengan más de X(donde X es un valor) días. Los sucesos se guardan hasta cumplir con el número de días especificados antes de reemplazarse. De forma predeterminada son 7 días.
  • No sobrescribir sucesos. No se guardarán los nuevos sucesos si se alcanza el tamaño del registro, deberá limpiarse manualmente y esto provocará un aviso de error cuando así ocurra, al inicio de sesión.

Si se produce el último caso y queremos que el sistema se apague hasta que un administrador limpie el registro, podemos configurarlo, de forma que se mostrará una BSOD con el error. Para hacerlo establecemos un valor de 1 en la clave HKEY_LOCAL_MACHINESYSTEMControlSetControlLsaCrashOnAuditFail. Cuando se da el caso y se apaga por este motivo, el valor pasa a ser 2, un administrador local debe iniciar sesión y cambiarlo a 1. El valor 0 deshabilita esta funcionalidad.

A menos que tengamos un sistema de auditorías centralizado como MOM (Microsoft Operations Manager), debemos ser cuidadosos con el comportamiento de reemplazo y escoger el que se adapte mejor a nuestro entorno y asegurarse que el tamaño es lo suficientemente grande para grabar los sucesos según dicho comportamiento.