Bitácora del sistema - Introducción

Transcripción

1 Bitácora del sistema M A T E R I A : A R Q U I T E C T U R A A V A N Z A D A P R O F E S O R : J U A N J O S E M U Ñ O Z A L U M N O : F E D E R I C O D I B E N E D E T T O M A T R I C U L A :

2 Bitácora del sistema - Introducción Sistema de logs en un Sistema Operativo UNIX/LINUX /var/log: es la bitácora del sistema, puesto que aquí se almacenan los registros detallados de toda la actividad desarrollada en el transcurso de una sesión de trabajo. Logs del sistema Los logs del sistema son archivos y directorios donde normalmente el administrador del sistema recurre en busca de información y registros de actividad, con el objeto de determinar la causa de un problema, o bien como una actividad de control periódica. Lo más usual es que estos archivos se encuentren bajo /var/log: el administrador debería chequear como parte de sus controles de rutina los archivos que aparecen bajo este directorio en busca del tipo de información mencionada en el primer párrafo, especialmente el contenido de un archivo.

3 Qué es un log? Un log es un 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 un evento ocurre para un dispositivo o una aplicación en particular. 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.

4 Propósito de los LOGS Ayudar a resolver problemas de todo tipo. Proveer de avisos tempranos de abusos del sistema. Después de una caída del sistema, proporcionan datos del porque de la misma. Como evidencia legal y Auditoría del Sistema 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 protección de Unix debe incluir el monitoreo y revisión de LOGS de una forma comprensiva, precisa y cuidadosa.

5 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 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: Klogd: provee de un sistema de bitácoras para los programas y las aplicaciones. Actualmente envía la mayoría de los mensajes al syslogd, pero en ocasiones enviará mensajes a la consola. Sysklogd provee del manejo de bitácoras para el kernel. 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.

6 El 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.

7 Estrategias para la administración de logs. 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 pueden almacenan los logs de acuerdo a una clasificación de los mismos. En el caso que alguno falle, seguirá disponible alguno de los restantes (pueden estar montados en distintos S.O.) Una forma de aumentar la disponibilidad es tener una replica de los logs en otros servidores de logs, la contra es la alta redundancia. 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.

8 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. Ejemplo: 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

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

10 El sistema de Log en AIX AIX proporciona otro mecanismo para la gestión de errores y mensajes del //hardware//, del sistema operativo y de las aplicaciones, ofreciendo una información muy valiosa para determinar cualquier tipo de problemas en el entorno. Los registros guardados por ##errdemon## están en modo binario (a diferencia de los //logs// habituales en Unix) por defecto. AIX ofrece más herramientas para realizar diferente tareas sobre su sistema nativo de //log//: eliminar entradas (##errclear##) instalar nuevas entradas en el archivo de configuración (##errinstall##) detener el demonio ##errdemon## (##errstop##)

11 El sistema de Log en AIX El sistema de //log// en AIX es una de las características más potentes que el operativo nos ofrece, proporcionando un nivel de detalle y granularidad en la clasificación de eventos muy superior al de ##syslogd##; no obstante, la cantidad de información registrada, y el hecho de que no existan herramientas que informen de algún modo especial ante errores graves, hacen que no se consulte mucho el //log// y se pierdan entradas que son importantes, no sólo en lo referente a la seguridad del sistema sino también en lo que concierne a su estabilidad.

12 Logs remotos El demonio ##syslog## permite fácilmente guardar registros en máquinas remotas; de esta forma se pretende que, aunque la seguridad de un sistema se vea comprometida y sus //logs// sean modificados se puedan seguir registrando las actividades sospechosas en una máquina segura. Esto se consigue definiendo un ##`LOGHOST'## en lugar de un archivo normal en el fichero ##/etc/syslogd.conf## de la máquina de la que nos interesa guardar información. A partir de ese momento todos los mensajes generados en la máquina origen se enviarán a la destino y se registrarán según las reglas de esta, en un fichero (lo habitual), en un dispositivo o incluso se reenviarán a otra máquina. Esto, que en muchas situaciones es muy recomendable, si no se realiza correctamente puede incluso comprometer la seguridad de la máquina que guarda registros en otro equipo: por defecto, el tráfico se realiza en texto claro, por lo que cualquier atacante con un //sniffer// entre las dos máquinas puede tener acceso a información importante que habría que mantener en secreto.

13 Logs remotos Imaginemos una situación muy habitual: un usuario que teclea su //password// cuando el sistema le pide el //login//. Evidentemente, esto generará un mensaje de error que ##syslogd## registrará. Para evitar este problema existen dos aproximaciones: o bien registramos //logs// en un equipo directamente conectado al nuestro, sin emitir tráfico al resto de la red, o bien utilizamos comunicaciones cifradas (por ejemplo con SSH) para enviar los registros a otro ordenador.

14 Bitácora del sistema - Conclusiones Problema 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.

15 Bitácora del sistema - Conclusiones 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.

16 Bitácora del sistema - Conclusiones Después 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.

17 FIN