¿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.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *