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
