jueves, 31 de enero de 2008

MEJORES PRACTICAS Y HERRAMIENTAS PARA EL MONITOREO DE BITACORAS EN UNIX

INTRODUCCION

Que es un log?
Registro oficial de eventos durante un periodo de tiempo en particular. Para los profesionales en seguridad informática un log es usado para registrar datos o información sobre quien, que, cuando, donde y por que de un evento que ocurre para un dispositivo en particular o aplicación.

La mayoría de los logs son almacenados o desplegados en el formato estándar ASCII. De esta forma logs generados por un dispositivo en particular puede ser leído y desplegado en otro diferente.

Propósito de los LOGS
Todos los sistemas pueden verse comprometidos por un intruso, de manera local o remota.

La seguridad no sólo radica en la prevención, sino también en la identificación. Entre menos tiempo haya pasado desde la identificación de intrusión, el daño será menor; para lograr esto es importante hacer un constante monitoreo del sistema.

De cualquier forma que se realice una proteccion de Unix debe incluir el monitoreo y revision de LOGS de una forma comprensiva, precisa y cuidadosa.

Los logs tienen numerosos propósitos:
Ayudar a resolver problemas de todo tipo
Proveer de avisos tempranos de abusos del sistema.
Después de una caida del sistema, proporcionan datos de forensia.
Como evidencia legal


SINTESIS.

Auditoría del Sistema
Una parte integral de cualquier sistema UNIX son sus facilidades de manejo de bitácoras. La mayoría del manejo de bitácoras esta provisto por dos programas principales: sysklogd y klogd. El primero provee de un sistema de bitácoras para los programas y las aplicaciones, mientras que el segundo provee del manejo de bitácoras para el kernel.

Klogd actualmente envía la mayoría de los mensajes al syslogd, pero en ocasiones enviará mensajes a la consola.
Sysklogd actualmente maneja las tareas de procesar la mayoría de los mensajes y enviarlos al archivo o dispositivo apropiado; esto se configura dentro del archivo /etc/syslog.conf.

Por defecto la mayoría de los archivos de bitácora están situados en /var/log, y generalmente los programas con su sistemas de bitácora internos (los servidores httpd en su mayoría) guardan sus archivos de bitácora en /var/log/nombre-de-programa, lo que permite centralizar los archivos de bitácora y hace fácil ponerlos en una partición separada.

Adicionalmente existen programas que manejas su propio intervalo de registro de bitácoras, uno de los más interesantes es el shell bash. Por defecto el bash guarda un archivo histórico de los comandos ejecutados en ~usuario/.bash_history, este archivo pude ser extremadamente interesante de leer, porque en muchas ocasiones muchos administradores escriben accidentalmente sus contraseñas en la línea de comandos.

Un mundo aparte a la hora de generar (y analizar) informes acerca de las actividades realizadas sobre una máquina Unix son los sistemas con el modelo de auditoría C2; mientras que con el modelo clásico se genera un registro tras la ejecución de cada proceso, en Unix C2 se proporciona una pista de auditoría donde se registran los accesos y los intentos de acceso de una entidad a un objeto, así como cada cambio en el estado del objeto, la entidad o el sistema global. Esto se consigue asignando un identificador denominado Audit ID a cada grupo de procesos ejecutados.

Unix system log files:
utmp. Informacion acerca de los usuarios actuales.
wtmp. Se encuentran los logins and logouts (time stamps, shutdowns y reboots).
lastlog. Los ultimos logins se registran en este archivo.

Estrategias para la administración de logs.
Una estación como servidor de logs.
Estaciones de una red configuradas para enviar sus log a un servidor especifico.
Rotación de los archivos de log.
Comprobación de integridad sobre los archivos renombrados (Archivos rotados).

Escenarios
Se pueden presentar dos escenarios principales:
Un único servidor central para la administración de Logs.
Al tener un único y común servidor de logs se establece también un único punto de falla o ataque. El sistema por completo dependería de la disponibilidad de este punto e igualmente un atacante al obtener acceso a este servidor pondría en duda la validez de los logs y la utilización de estos como evidencia en una investigación formal

Diferentes servidores que almacenan los logs de acuerdo a una clasificación de los mismos.
Tener un servidor para grupos de fuentes de logs, si el servidor de logs de los servidores con sistema operativo Windows NT falla, seguirá estando disponible el servidor de los de las maquinas Unix y desde luego los servidores de los demás dispositivos. Una forma de aumentar la disponibilidad es tener una replica de los logs en otros servidores de logs, alta redundancia.

Rotación de logs.
Los archivos de log pueden rápidamente consumir gran cantidad de almacenamiento en un servidor centralizado de logs. La técnica de rotación de logs permite limitar el volumen de datos que se tienen disponibles para examinar fácilmente, en este caso en el servidor de logs, y además controlar el número de archivos de logs que estarán expuestos a un posible daño por parte de un intruso.

Ya que la rotación depende del tiempo, es muy importante que tanto los servidores, como los dispositivos que producen los logs posean una alta exactitud en el tiempo. Para esto se puede utilizar el servicio Network Time protocol NTP.


Protección de logs.
Para lograr que los Logs sean confiables y válidos en determinadas situaciones como evidencia, se debe tomar medidas que protejan la exactitud, autenticidad y accesibilidad de los archivos

Exactitud.
Registrar todo en los archivos Logs: Configurar los logs de los sistemas para registrar la mayoría de la información que se pueda.
Manteniendo el tiempo real: Sincronizando las maquinas con un fuente de tiempo externa, como servidores NTP.
Usar múltiples sensores: Combinando logs de varios dispositivos, se aumenta el valor dado a cada uno.

Autenticidad. Se puede decir que un archivo de log es autentico si se puede probar que ellos no han sido modificados desde que ellos fueron originalmente registrados
Movimiento de Logs: se debe cambiar la localización de los archivos en si, se debe considerar trasladar los logs a una máquina diferente a la cual los produce.
Firmas, Encripción y Checksums: La única forma de estar absolutamente seguro que un archivo no ha sido modificado es firmar y encriptar el archivo de log usando PGP o algún otro esquema de llave-publica de encripción.
Trabajar con copias: Cuando se realiza cualquier tipo de análisis sobre los archivos de logs, nunca se debe realizar sobre el archivo original.
Asegurar la integridad del sistema: Se debe auditar permanentemente todos los cambios que se produzcan en el sistema.
Documentación de procesos: Establecer un proceso significa crear un documento que liste y detalle cada paso tomado, ya sea de forma manual o automático a la hora de recolectar la evidencia. Además, cualquier scripts que se utilice en el procesamiento y recolección de archivos de logs, deberá también contener comentarios explicando lo que exactamente se esta realizando.

Accesibilidad o Control de Acceso: Una vez el archive de log es creado debe ser auditado y protegido para prevenir accesos no autorizados.
Restringir el acceso a archivos: Un archivo de logs necesita ciertos permisos para que la aplicación o sistema que o produce pueda registrar eventos en él. Pero luego que esto se produce el archivo se debe cerrar y nadie debe tener acceso a modificar el contenido del mismo.
Cadena de custodia Al mover los archivos desde un servidor a un dispositivo offline, o cualquier otro manejo que se ha planeado realizar, es muy importante registrar los cambios de ubicación que los archivos han tenido

Almacenaje de logs.
Entre las formas comunes de almacenaje se encuentran aquellos dispositivos, medios y procedimientos estándares que utilizan las compañías para la realización de Backups de datos. Entre estos podemos encontrar el almacenaje en Cintas, CD-R, CD-RW, o Zip/Jazz drives.

El siguiente paso es lograr que estos datos permanezcan incorruptibles a lo largo del tiempo, esto se puede lograr con estado de solo lectura. Una forma de almacenar los logs con un estado de solo lectura es utilizando medios que físicamente están protegidos contra escritura.

Otros aspectos que hay que considerar es limite de vida de cada dispositivo y que la encripción de datos es recomendada en aquellos archivos de logs que posean datos críticos

Monitoreo en bitácoras
Generalmente no deseamos permitir a los usuarios ver los archivos de bitácoras de un servidor, y especialmente no queremos que sean capaces de modificarlos o borrarlos. Normalmente la mayoría de los archivos de bitácoras serán poseídos por el usuario y grupo root, y no tendrán permisos asignados para otros, así que en la mayoría de los casos el único usuario capaz de modificar los archivos de bitácoras será el usuario root.

Debido a la cantidad de información que se genera en la bitácoras, siempre es bueno adoptar algún sistema automático de monitoreo, que levante las alarmas necesarias para cuando algún evento extraño suceda.
El sistema operativo Debian utiliza LogCheck para realizar el análisis y monitoreo de bitácoras, RedHat emplea LogWatch, etc.

Ejemplos:

CDM
Software que permite la monitorización de UNIX, actualmente soportan varias versiones de UNIX y Linux, incluyendo Solaris, AIX, HP-UX, Irix, Linux, Sinix y Tru64 UNIX. Está compuesta por 3 módulos que se pueden usar individualmente o en conjunto para obtener la máxima visibilidad del rendimiento del sistema UNIX:
CPU, Disco y Memoria
Monitor de Procesos
Monitor de archivos Log

El Monitor de Archivos Log vigila los archivos log basados en formato ASCII y extrae información predefinida, eliminando la necesidad de intervención manual. Las utilidades de búsqueda del monitor permiten una definición sofisticada de ficheros log complejos y variables. Se pueden vigilar varios archivos log a la vez, y definir cualquier cantidad de perfiles de búsqueda para cada archivo.

Características:
Monitor de archivos log ASCII
Soporte de múltiples formatos de archivos
Un mensaje por linea
Archivos complejos con mensajes multilínea
Archivos con formato sin estructura
Definición fácil de perfiles usando
Expresiones Regulares :
Patrones
Posición absoluta en columnas
Posición relativa en caracteres
Monitorización de múltiples archivos simultáneamente
Múltiples perfiles de búsqueda para cada archivo
Consumo mínimo
Se puede buscar en el archivo completo o solo en las lineas nuevas

TANGO04

Esta herramienta nos permite alcanzar un mainframe con diferentes niveles de servicio, monitorear servidores, integrar diferentes arquitecturas, ademas:
Uso del CPU
Uso del File System
Abuso en el uso de procesos por el CPU
Promedio de carga de trabajo
Informacion general sobre procesos.
Procesos por usuario
Memoria Virtual (swap)

AIDE (Advanced Intrusion Detection Environment)

AIDE como su nombre lo dice es un detector de intrusos, tal como Tripwire. Tal como tripwire crea una base de datos basada en las reglas establecidas, la cual es usada para verificar la ointegridad de un archivo. Ademas AIDE permite checar inconsistencias en los atributos de archivos

Osiris

Osiris mantiene un detalle de los cambios de los logs en el flie system, se puede configurar para que envie un mail al adminstrador con estos logs, los hosts son escaneados periodicamente, mantiene al adminstrador constantemente prevenido contra ataques de trojanos. El proposito principal es aislar los cambios que indicen una amenaza o compromentan el sistema.

Samhain

Software multipalataforma, open source para verificación centralizada del los archivos de sistema (file system), basado en sistemas POSIX, capza de monitorear diferentes sistemas operativos desde un servidor central. Entre sus características principales se encuentran:
Consola basada en Web.
Monitoreo de log multiplataforma.
Tamper resistance[6]

Centrify DirectAudit

Permite cumplir reglas estricats en el File System, inspeccionar los problemas que se presenten a profundidad y proteger contra amenazas en UNIX. DirectAudit detalla los logs, determinando su importancia, enviando reportes, accesso de usuarios a sistema, que codigos ejecutaron, que cambios hicieron, etc.

Herramientas para la administración de logs.

Tripwire
Es una herramienta diseñada especialmente para Sistemas Operacionales UNIX. Dicha herramienta por medio de funciones se encarga de generar un Hash único por cada archivo que se le desee proteger su integridad. De esta forma cuando se presente un cambio en un log por parte del atacante, este cambio será notificado al administrador (enviándose un mail automático), ya que no reflejará el hash original. Para realizar dichas detecciones Tripwire también se basa en: CRC-32, MD5, SHA y HAVAL (firma digital de 128 bits).
logrotate
Esta herramienta alterna, comprime y envía logs de sistema. Está diseñada para facilitar la administración de los sistemas que generan un gran número de archivos de logs. Permite la rotación automática, comprensión, extracción y envió de los archivos de logs. Puede manipularse cada archivo log diaria, semanal o mensualmente, o cuando se haga demasiado grande.

SYSLOG
Es la principal herramienta de UNIX para llevar la bitácora de eventos. Con este sistema, se puede configurar el manejo de bitácoras a un nivel extremadamente alto de detalle y cada flujo de registros puede ir a un archivo diferente. Una habilidad muy buscada y muy potente del syslog es su capacidad de enviar registros de bitácoras a computadoras remotas. Esto permite centralizar las bitácoras en un solo servidor y fácilmente verificar los archivos de bitácora por razones de violaciones de seguridad y otras cosas extrañas en toda la red.

La mayoría del manejo de bitácoras esta provisto por dos programas principales: sysklogd y klogd. El primero provee de un sistema de bitácoras para los programas y las aplicaciones, mientras que el segundo provee del manejo de bitácoras para el kernel.
Klogd actualmente envía la mayoría de los mensajes al syslogd, pero en ocasiones enviará mensajes a la consola.
Sysklogd actualmente maneja las tareas de procesar la mayoría de los mensajes y enviarlos al archivo o dispositivo apropiado; esto se configura dentro del archivo /etc/syslog.conf.
Sin embargo existen varios problemas con el syslogd y el klogd, la principal es que si un atacante logra acceso de root, podrá modificar los archivos de bitácoras y nadie lo notará.
Cada mensaje enviado al sistema de bitácoras tiene dos clasificadores: el servicio y el nivel. El servicio indica el tipo de programa que envió el mensaje y el nivel es el orden de importancia. Sysklogd y klogd no son los únicos sistemas para el seguimiento de bitácoras, existen otros, entre los cuales podemos nombrar:
modular syslog. Firma digitalmente los registros de bitácora para que cualquier alteración en ellos sea inmediatamente detectable.
next generation syslog. Permite el firmado digital y además puede clasificar los registros de otras maneras (como patrones en los registros) además del tipo de servicio y el nivel.
Nsyslogd. Añade soporte para SSL (Secure Socket Layer) en la transmisión de bitácoras a una computadora remota.

Configuración del syslog
La lista de servicios disponibles en el syslogd es:
AUTH. Para mensajes de seguridad/autorización (obsoleto, ahora se utiliza AUTHPRIV)
AUTHPRIV . Mensaje de seguridad/autorización
CRON. Para los servicios de tareas programadas (cron y at)
DAEMON. Servicios del sistema sin un servicio especificado
FTP. Servicio de ftp
KERN. Mensajes del kernel
LOCAL0 a LOCAL7. Reservados para uso local del equipo
LPR. Subsistema de impresión
MAIL. Subsistema de correo electrónico
NEWS. Subsistema de USENET
SYSLOG. Mensajes generados internamente por el syslogd
USER. Mensajes genéricos a nivel de usuario
UUCP. Subsistema de UUCP

La lista de niveles disponibles para el syslogd es:
EMERGE. El sistema esta inservible
ALERT. Alguna acción debe ser tomada inmediatamente
CRIT. Condiciones críticas
ERR. Condiciones de error
WARNING. Condiciones de advertencia
NOTICE. Condición normal pero significativa
INFO. Mensaje informativo
DEBUG. Mensaje de depuración

Problemática
Una desventaja del sistema de auditoría en Unix puede ser la complejidad que puede alcanzar una correcta configuración; por si la dificultad del sistema no fuera suficiente, en cada Unix el sistema de logs tiene peculiaridades que pueden propiciar la pérdida de información interesante de cara al mantenimiento de sistemas seguros. Aunque muchos de los ficheros de log son comunes en cualquier sistema, su localización, o incluso su formato, pueden variar entre diferentes versiones de Unix.

Dentro de Unix hay dos grandes familias de sistemas: se trata de System V y BSD; la localización de ficheros y ciertas órdenes relativas a la auditoría de la máquina van a ser diferentes en ellas, por lo que es muy recomendable consultar las páginas del manual antes de ponerse a configurar el sistema de auditoría en un equipo concreto.

ANÁLISIS
Cada una de las etapas descritas para la administración de logs es crítica, así si se cuenta con un sistema de centralización bien diseñado e implementado pero a su vez, no se logra un buen método de administración de los archivos en el servidor de logs (rotación y comprobación integridad ), el sistema de administración como tal será ineficiente.
Los archivos de logs aunque son básicos a la hora de una investigación de intrusiones en los sistemas informáticos, siempre hay que tener en mente que son esenciales a la hora de tomar medidas legales contra esos intrusos.

Despues de la lectura considero que las mejores practicas para la administración y monitoreo de logs,son las siguientes:

Rotación de logs. Cuidando no se desborde el almacenamiento y el tiempo exacto del los logs.
Protección de logs. Buscando que los logs sean: exactos, autentificables y accesibles.
Exactos. Registrar todo en los logs, mantener el tiempo real y usar múltiples sensores para registrar eventos.
Autenticidad. Se debe probar que no han sido modificados desde que fueron registrados, a través de: cambar los Logs de lugar en en sistema, el uso de Firmas, Encripción y Checksums, evitar trabajar con logs originales y utilizar copias, auditar permanentemente todos los cambios que se produzcan en el sistema y documentar los procesos.
Accesibilidad o control de acceso. El log creado debe ser auditado y protegido para prevenir accesos no autorizados; mediante la restricción en el acceso a archivos y la Cadena de custodia, es decir establecer otros medios de almacenamiento secundario.
Almacenaje de logs. Tomar en cuenta Medios en los que se almacenaran los logs, en base a su importancia, tiempo de vida (del medio y de la información) y confidencialidad.
Uso de herramientas de administración de logs. Las cuales incluye el mismo sistema operativo: syslog; o software adicional como tripwire o logrotate.
Uso de herramientas de monitorización y análisis de logs. LogCheck, LogWatch, CDM,


Entre otras las herramientas de amplio uso para el monitoreo de UNIX son las siguientes: Tripwire, CDM, TANGO04, SAMHAIN, Snort, Osiris, Centrify DirectAudit, logrotate, etc.



REFERENCIAS.

http://congreso.seguridad.unam.mx/informacion/
Congreso de seguridad, Administración en sistemas Unix


http://www.ceyusa.com/documentos/cfe/
Manual de Administración del Sistema Operativo Unix


http://www2.sas.com/proceedings/sugi26/
MONITORING USAGE OF UNIX SOFTWARE


http://www.simson.net/ref/ugh.pdf y http://downloads.techrepublic.com.com/
The UNIXHATERS Handbook

http://i.i.com.com/cnwk.1d/i/tr/downloads/home/
Log_monitoring_and_management.pdf


http://www.cisco.com/warp/public/707/
Best Practices for Cisco Secure ACS for UNIX Administration

http://linux.sys-con.com/read/46186.htm
Best Practices for Managing Your Linux/Unix Performance and Availability

http://www.securityfocus.com/infocus/1771
Host Integrity Monitoring: Best Practices for Deployment


http://enterpriselinuxlog.blogs.techtarget.com/
10 IT system monitoring best practices


www.unal.edu.com/seguridad
Lista de chequeo de elementos esenciales de seguridad en el Sistema Operarivo

www.ceyusa.com
Administración del Sistema Operativo Unix

http://www.counterpane.com/log-analysis.html

No hay comentarios: