TALLER FINAL LOGS

SEGMENTO DOCUMENTAL.

ESTRATEGIAS:
Identificar los sistemas involucrados.
lIdentificar el alcance y objetivo para el cual se realizará la consolidación de logs.
lSincronizar el reloj de los sistemas involucrados.
lIdentificar los eventos que se desee monitorear.
lIdentificar los tipos de logs que serán almacenados.
lDefinir una estrategia de control de integridad de los archivos.
lDimensionar el tamaño, crecimiento y rotación de cada uno de los logs.
lIdentificar el mecanismo de almacenamiento de los backups.
lIdentificar las herramientas comerciales o gratuitas que pueden ayudar a examinar y correlacionar los logs.

POLÍTICAS: (DOCUMENTAR)

Las políticas más comunes son:
No almacenar
Resetearlos periódicamente
Rotarlos, manteniendo datos por un período fijo de tiempo hacia atrás
Archivar en cinta u otro medio de respaldo toda la historia
El primer método no es para nada recomendable dado que los logs son una de las principales herramientas para determinar la causa de un malfuncionamiento y para detectar algún acceso no autorizado al sistema.
La política de borrar los archivos de log cada vez que toman un tamaño que los hace molestos, si bien en la mayoría de los casos nos permite disponer de información, no nos garantiza disponer de los registros de un tiempo hacia atrás. Por otra parte si el tamaño de los logs crece excesivamente puede hacerse inmanejable extraer de ellos información o incluso pueden llegar a llenar el disco.

La práctica más usual consiste en ir "rotando" los nombres de archivo diariamente o semanalmente, de manera de ir descartando los archivos más antiguos y mantener información de una cantidad fija de días anteriores. Un ejemplo elemental de un script que se podría lanzar desde cron para realizar esto es el que sigue:
#!/bin/sh
cd /var/log
rm logfile.3
mv logfile.2 logfile.3
...
mv logfile logfile.0
cat /dev/null > logfile


LEGALIDAD: (SINCRONIZAR)

Exactitud de los archivos de log.

La exactitud significa que se puede probar que los archivos de log representan con precisión la actividad del sistema. Incluso la más pequeña imprecisión en los archivos de logs pueden llevar a cuestionar la validez de toda la evidencia.

La siguientes son pautas para que los logs estén creados con 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. Mientras algunos administradores ven poca utilidad almacenar información extra, cada campo de estos archivos tiene mucho significado en a la hora de una investigación forense.

Por ejemplo, supongamos que un administrador web aduce que un hackerhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn9 [9] ha quebrantado la seguridad de su máquina y ha introducido un //backdoorhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn10 [10]//, un servidor proxy para relanzar ataques a otras máquinas. ¿Cómo se logra probar que el tráfico viene desde un usuario especifico o que fue un ataque realizado por alguien más?, mientras esto no se pueda probar siempre, entre más información se registre más probabilidad de salir exitoso en estos casos se tiene.

MANTENIENDO EL TIEMPO REAL:

Sincronizando las maquinas con un fuente de tiempo externa. En
http://tycho.usno.navy.mil/ntp.html se puede encontrar una lista de servidores NTP.

USAR MÚLTIPLES SENSORES:

Es difícil perder información de entrada a un logs si múltiples dispositivos están registrando la misma información. Combinando logs de varios dispositivos, se aumenta el valor dado a cada uno. Los logs de firewalls, IDS (Intrusion Detection System) e incluso algo tan simple comoTCPDumphttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn11 [11] puede ayudar a probar que desde una dirección IP se realizó un ataque a una maquina especifica a un tiempo específico.

En http://www.iissecurity.net/4361.htm se puede encontrar un ejemplo del uso de un Snorthttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn12 [12] como suplemento de los logs de un servidor.

LEGITIMIDAD: (ENCRIPTAR)
Autenticidad de los archivos de log:
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. Generalmente los archivos de logs son archivos de texto muy fácilmente modificables, incluyendo su fecha y hora. Desde este aspecto no se podría dar la autenticidad pero llevando a cabo ciertos procedimientos se puede lograr este aspecto:

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 PGPhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn13 [13] o algún otro esquema de llave-publica de encripción.

La firma de archivos es muy útil ya que si sencillamente un archivo ha sido modificado (es corrupto), este no invalida el resto de logs. Se puede utilizar herramientas como Fsumhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn14 [14] que fácilmente genera MD5 hashes para los archivos.

Al encriptar los archivos se debe tener en cuenta el impacto que esto conlleva a la hora de la creación, modificación y acceso a los archivos.

ASEGURAR LA INTEGRIDAD DEL SISTEMA:

Se debe auditar permanentemente todos los cambios que se produzcan en el sistema. Si un intruso esta en capacidad de modificar cualquier archivo del sistema, los archivos de logs producidos por el mismo (sistema operativo) la validez de estos archivos como evidencia entrara en duda.

DOCUMENTACIÓN DE PROCESOS:

Mantener siempre en mente que un proceso bien establecido puede ser muy útil a la hora de evaluar autenticidad.

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. Las técnicas que se usen en los procesos deberán generalmente ser aceptadas legalmente para la administración y recolección de archivos de log.


CONTROL DE ACCESO

Una vez el archive de log es creado debe ser auditado y protegido para prevenir accesos no autorizados.

Si se asegura y audita un archive de log apropiadamente, se tendrá un evidencia documentada que ayuda ha establecer su credibilidad.

RESTRINGIR EL ACCESO A ARCHIVOS:

Un archive 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. Se puede también considerar programar comandos para bloquear el acceso a estos archivos y auditar luego este. También se debe tener en cuenta que al cambiar la ubicación de los archivos de logs se debe establecer los permisos correctamente.

ROTACIÓN DE LOGS:

Los archivos de log pueden rápidamente consumir gran cantidad de almacenamiento en un servidor centralizado de logs, (lo cual es relativamente costoso), de igual forma determinar que archivo de log en particular en un futuro será útil en una investigación o proceso legal es muy difícil. 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.
La estrategia de rotación de logs se basa principalmente en cambiar la ubicación de los archivos de logs a una nueva locación y renombrarlos de esta manera podrán reflejar la rotación.


BIBLIOGRAFÍA:

http://www.wikilearning.com/monografia/control_administracion_e_integridad_de_logs-estrategias_para_la_utilizacion_de_logs_como_evidencia/3485-7

LOG DE LINUX

¿Qué es un analizador de log? Los Analizadores de Log, así como de Cabeceras de Mensajes son herramientas de soporte que se encuentran ya disponibles para administradores de Google Apps. Estas herramientas permiten diagnosticar cuestiones relativas a herramientas de migración, herramientas de sincronización y la entrega de correo electrónico. Analizador de Logs: Evalua Logs de una variedad de herramientas de migración y sincronización, ofreciendo orientación en la resolución de la mayoría de los problemas visibles en los registros.

Nombre del Log	Path	Objetivo
Lastlog	/var/adm/	contiene un registro para cada usuario con la fecha y hora de su última conexión
Wtmp	/usr/adm/wtmp	almacena cada acceso al sistema y cada salida del mismo
Adm	/var/admspan>	Info administrativa del sistema
Acces_log_acces_log	/var/www/logs/access_log	archivos de registros del servidor Apache
Messages	/var/log/messages	aquí encontraremos los logs que llegan con prioridad info (información), notice (notificación) o warn (aviso).
Boot	/var/log/boot.log	Muestra mensajes referentes al arranque del sistema.
Debug	/var/log/debug	Muestra mensajes de depuracion.
Auth.log	/var/log/auth.log	se registran los login en el sistema, las veces que hacemos su, etc. Los intentos fallidos se registran en líneas con información del tipo invalid password oauthentication failure.
Daemon.log	/var/log/daemon.log	Muestra mensajes sobre demonios (permisos) o servicios corriendo en el sistema.
Dmesg	/var/log/dmesg	en este archivo se almacena la información que genera el kernel durante el arranque del sistema
Dpkg.log	/var/log/dpkg.log	Muestra un registro de los paquetes binarios instalado.
Faillog	/var/log/faillog	Muestra los intentos de acceso fallidos
Kern.log	/var/log/kern.log	se almacenan los logs del kernel, generados por klogd.
Lpr.log	/var/log/lpr.log	Muestra mensajes sobre la impresora
Mail	/var/log/mail.err   /var/log/mail.info   /var/log/mail.warn   /var/log/mail.log	Archivos varios que muestran mensajes sobre error, informacion, alertas y registro (respectivamente) para los correos (requiere tener un servicio de correos funcionando)
Mysql	/var/log/mysql.*	Archivos varios de registro para el servicio mysql (requiere tener un servicio mysql).
User.log	/var/log/user.log	Muestra informacion acerca de los procesos usados por el usuario
Xorg.0.log	/var/log/Xorg.0.log	Muestra registros de Xorg
Secure	/var/log/secure	Registra los accesos al servidor que tienen relación con procesos de autentificación.
Maillog	/var/log/maillog	Sucesos servidor de correo
Spooler	/var/log/spooler	Mensajes de cola de impresion
Entre otros	/var/log/samba	Mensajes del servicio samba