Bitácora del Sistema - AA-2011

Bitácora del Sistema
Universidad CAECE
Federico Lanzani, 77129/6
ARQUITECTURA AVANZADA
INGENIERIA EN SISTEMAS
Tabla de contenido
¿Qué es un log y para qué sirve? ............................................................................3
Log del sistema en Windows ..................................................................................3
Log del sistema en Debian y Redhat .......................................................................4
Archivos de log importantes en UNIX ..............................................................5
Ejemplo de funcionamiento de logs en Debian ......................................................5
¿Qué es el demonio syslogd? .................................................................................7
Configuración del syslogd ................................................................................7
Ejemplos de syslog.conf ...................................................................................8
Bitácoras Remotas ..................................................................................................9
Como hacer buen uso de las bitácoras ................................................................ 11
Conclusiones ........................................................................................................ 12
Bibliografía ........................................................................................................... 14
Página 2 de 14
¿Qué es un log y para qué sirve?
Los logs del sistema son archivos y directorios donde normalmente el administrador
del sistema recurre en busca de información y registros de actividad, bien con el objeto
de determinar la causa de un problema, o bien como una actividad de control
periódica.
A la definición anterior se le puede agregar que es un registro de eventos durante un
periodo de tiempo. Generalmente se representa como un archivo de texto plano, que
tiene un evento por línea (es muy importante la fecha). Al estar representados en
formato ASCII, se gana una característica muy importante: la portabilidad. De esta
forma logs generados por un dispositivo en particular puede ser leído y desplegado en
otro diferente.
La importancia de un log reside siempre en la información que contiene. Un buen log
da información sobre quién, que, cuando, donde y por qué ocurre un evento para un
dispositivo o aplicación. El log puede no ser usado nunca, si no surge la necesidad de
revisarlo. Entonces, lo más importante del log es definir la información que contiene,
para que en un futuro cercano o lejano, esa información nos sirva al momento de ser
revisada. Este no es un tema menor.
Una característica importante de los logs, es que estos no avisan, sino que
simplemente registran los eventos. Por eso, agregamos a lo dicho anteriormente: es
importante definir la información que contendrá un log, pero es igual de importante la
revisión periodica de los mismos, con el fin de encontrar lo que planean detectar.
Un log del sistema es entonces, un archivo que contiene eventos logueados por
componentes del sistema operativo. Contiene información sobre cambios en
dispositivos, drivers, cambios en el sistema, eventos, operaciones y más.
Algunos logs también sirven en ciertos sistemas como evidencia legal y para auditar el
sistema.
Log del sistema en Windows
En Windows XP, se puede ver el log del sistema con el Visor de Eventos.
Cada evento tiene, fecha, hora ,usuario, equipo, número de evento (tipo), origen, tipo
(error, advertencia, información, auditoría de aciertos y auditoria de errores).
Página 3 de 14
La auditoria de aciertos describe la correcta finalización de un evento de seguridad
auditado. La auditoria de errores describe la incorrecta finalización de un evento de
seguridad auditado.
Log del sistema en Debian y Redhat
UNIX comprende la premisa mencionada en la introducción de que es tan importante
tener un log del sistema como tener programas y herramientas eficientes para
gestionarlo y revisarlo.
Una parte integral de cualquier sistema UNIX son sus facilidades de manejo de
bitácoras. La mayoría del manejo de logs está provisto por dos programas principales y
sumamente importantes: sysklogd y klogd.
sysklogd : provee de un sistema de bitácoras para los programas y las aplicaciones.
Klogd: provee el manejo de bitácoras para el kernel.
Por defecto, la mayoría de los archivos de bitácora están situados en /var/log.
Por lo general, es común que los programas cuenten con un log interno. Por
convención, estos se ubican en /var/log/nombre-de-programa. Esto que parece una
trivialidad, es sumamente importante ya que permite centralizar los archivos de
bitácora. El log más importante es probablemente el que se encuentra en
var/log/messages.
Adicionalmente existen programas que manejan 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.
El sistema operativo Debian utiliza LogCheck para realizar el análisis y monitoreo de
bitácoras, RedHat emplea LogWatch, etc.
Ejemplo de log del sistema en Debian y Redhat:
Jul 17 22:04:25 router dnsprobe[276]: dns query failed
Jul 17 22:04:29 router last message repeated 2 times
Jul 17 22:04:29 router dnsprobe[276]: Primary DNS server Is Down... Switching To
Secondary DNS server
Jul 17 22:05:08 router dnsprobe[276]: Switching Back To Primary DNS server
Jul 17 22:26:11 debian -- MARK –
Jul 17 22:46:11 debian -- MARK –
Jul 17 22:47:36 router -- MARK –
Jul 17 22:47:36 router dnsprobe[276]: dns query failed
Jul 17 22:47:38 debian kernel: rtc: lost some interrupts at 1024Hz.
Página 4 de 14
Jun 17 22:47:39 debian kernel: IN=eth0 OUT=
MAC=00:0f:ea:91:04:07:00:08:5c:00:00:01:08:00 SRC=61.4.218.24
DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=21599 DF PROTO=TCP
SPT=59297 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Archivos de log importantes en UNIX
El archivo syslog (guardado en var/adm o var/log/) es uno de los archivos de log más
importantes del sistema. En este archivo se guardan, en texto plano, mensajes
relativos a la seguridad de la máquina, como los accesos o los intentos de acceso a
ciertos servicios. No obstante, este archivo es escrito por syslogd, por lo que
dependiendo de nuestro archivo de configuración encontraremos en el archivo una u
otra información. (Hablaremos más adelante de lo que es syslog y el daemon UNIX que
implementa este estándar)
Otro archivo de log importante es el wtmp es un archivo que almacena información
relativa a cada conexión y desconexión al sistema.
El archivo lastlog es un archivo binario guardado generalmente en /var/adm/, y que
contiene un registro para cada usuario con la fecha y hora de su última conexión.
Faillog es un archivo muy parecido al anterior, pero se diferencia de que en lugar de
guardar información sobre la fecha y hora del último acceso al sistema lo hace del
último intento de acceso de cada usuario; Por ejemplo, este archivo tendrá una
entrada de conexión fallida si el usuario (o alguien en su lugar) teclea incorrectamente
su contraseña.
Ejemplo de funcionamiento de logs en Debian
Las bitácoras en Debian están configuradas por defecto en archivos del directorio
/var/log. Existen varias de acuerdo al programa que registra los mensajes. Todas
excepto wtmp y btmp son archivos de texto plano:
auth.log: Mantiene mensajes de autenticación, producidos por ejemplo por la librería
PAM indicando que usuarios abrieron y cerraron sesiones. Manejado por syslog.
kern.log: Mensajes del kernel. Manejado por syslog.
wtmp: wtmp mantiene información de usuarios que han abierto o cerrado sesiones,
se examina con el programa last (está relacionada con /var/run/utmp que mantiene
información de los usuarios que están conectados ---usado por el programa who).
Página 5 de 14
btmp: btmp mantiene información de sesiones que se intentaron abrir pero que no
pudieron autenticarse, se examina con el progama lastb.
lpr.log: Mensajes sobre impresoras. Manejado por syslog.
mail.log, mail.err, mail.info, mail.warn, exim: Mensajes sobre correo. Todos excepto
exim son manejados por syslog.
user.log: Mensajes de diversos programas, tipo user. Manejador por syslog.
Messages: Mensajes informativos de diversos programas (e.g del kernel). Manejado
por syslog.
daemon.log: Mensajes varios.
Debug: Mensajes de depuración de algunos programas, empleados usualmente por los
desarrolladores para encontrar fallas.
uucp.log: Empleado por el sistema Unix to Unix Copy (transferencia de archivos en
algunas redes no tan modernas o sin muchos recursos).
Dado que las bitácoras pueden crecer mucho (algunas en un día), en Debian son
rotadas con cierta frecuencia (diaria, semanal o mensual) empleando cron (en
particular syslog y auth.log).
Página 6 de 14
¿Qué es el syslog y que es el demonio syslogd?
En páginas anteriores hicimos menciones a lo que es Syslog y Syslogd. En este capítulo
explayaremos lo que es este estándar, archivo y daemon de UNIX.
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. Hablaremos más de esto más adelante.
El estándar syslog es un estándar que procura centralizar le manejo de los registros de
eventos que generan los diversos programas. Entre otras cosas, facilita a los
desarrolladores de aplicaciones la generación y el manejo de mensajes a registrar y
facilita a los administradores del sistema el manejo de forma centralizada de los
mensajes provenientes de diferentes aplicaciones.
El demonio syslogd es sumamente importante ya que es quien implementa el estándar
syslog en UNIX.
El demonio clasifica los mensajes por origen e importancia, para luego enviarlos a
diferentes destinos como archivos, a la terminal de un operador, o eventualmente a un
comando que lo reenvíe a direcciones de correo electrónico.
El syslog tiene además capacidad para manejar mensajes originados en diferentes
computadores en una red.
Para configurar este demonio, existe el archivo de config, que especifica hacia dónde
se deben enrutar los diferentes mensajes.
Configuración del syslogd
El syslog Cada línea tiene el siguiente formato:
selector <Tab> action
La acción especificada se aplicará a todos los mensajes que verifiquen las condiciones
que se especifican con el selector. Pueden ser las siguientes:
1. Guardar en un archivo
2. Reenviar hacia el syslogd de otra maquina
Página 7 de 14
3. Reenviar a una terminal de usuario
4. Usar el texto del mensaje como entrada a un comando.
El selector se especifica como un par facility.level. Cuando un programa envía un
mensaje al syslog, lo hace especificando un valor de "facility" y un valor de "level“.
El campo facility procura identificar al programa que originó el mensaje (son valores
prefijados en cada sistema, de un set finito. Ej: kernel, cron, ftp, etc), mensajes de
seguridad, de autenticación, usuarios y una serie de valores que pueden ser usados
con cierta libertad para diferentes aplicaciones (local0 a local7, user)
El campo level busca clasificar el nivel de importancia o severidad del mismo.
Los valores posibles de level son en general 8 y van en orden de severidad creciente
desde DEBUG hasta EMERG.
Ejemplos de syslog.conf
mail.debug /var/log/mail.debug.log
Todos los mensajes debug (y mayores), en el sistema de mail se escribiran en el path
mostrado.
*.crit root,adm
Todos los mensajes criticos se enviaran al usuario root y adm si estan logueados.
Página 8 de 14
Bitácoras Remotas
El demonio syslogd permite fácilmente guardar registros en máquinas remotas. La
principal ventaja de esto, es que 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 archivo 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 archivo (lo
habitual), en un dispositivo o incluso se reenviarán a otra máquina (al no hacer un
control de referencias circulares, es importante no entrar en bucles circulares, que
romperán el sistema); si suponemos que estas reglas, en nuestro caso, registran los
mensajes de la prioridad especificada antes en /var/adm/messages, en este archivo
aparecerán entradas de la máquina que ha enviado la información.
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. Pogamos como ejemplo una situación muy
habitual: un usuario que teclea su contraseña cuando el sistema le pide el login.
Evidentemente, esto generará un mensaje que syslogd registrará.
Para evitar este problema existen dos aproximaciones:
1. Registramos logs en un equipo directamente conectado al nuestro, sin emitir
tráfico al resto de la red. En este caso sólo necesitamos un equipo con dos
tarjetas de red, una por donde enviar el tráfico hacia la red local y la otra para
conectar con la máquina donde almacenamos los logs, que sólo será accesible
desde nuestro equipo y que no ha de tener usuarios ni ofrecer servicios ni
tener gran potencia de procesador.
2. Utilizamos comunicaciones cifradas (por ejemplo con SSH) para enviar los
registros a otro ordenador. En este caso, utilizar comunicaciones cifradas para
guardar registros en otro equipo de la red, requiere algo más de trabajo; aquí
no es estrictamente necesario que la máquina esté aislada del resto de la red,
ya que la transferencia de información se va a realizar de forma cifrada,
consiguiendo que un potencial atacante no obtenga ningún dato
comprometedor analizando el tráfico; evidentemente, aunque no esté aislado,
es fundamental que el sistema donde almacenamos los logs sea seguro. Para
Página 9 de 14
enviar un log cifrado a una máquina remota podemos utilizar, como hemos
dicho antes, SSH unido a las facilidades que ofrece syslogd, si lo hacemos así, lo
único que necesitamos es el servidor sshden la máquina destino y el cliente
sshen la origen.
Página 10 de 14
Como hacer buen uso de las bitácoras
Las bitácoras tiene varias particularidades que vienen heredadas de su condición de
archivo. Al ser el log un concepto incremental, una cosa que siempre es olvidada es en
poner un limite a este archivo, ya se por su monitoreo manual o automatico. Es muy
importante este punto ya que en un ambiente de pruebas, los logs tienden a tener un
tamaño muy reducido, cosa que dista mucho por lo general de la vida real.
Es muy común que pase que al momento de tener que revisar un log, este sea tan
grande que resulte difícil de manejar (nadie quiere archivos de texto plano en tamaño
de 500MB). Por esta razón, es útil implementar una rotación de logs, que permite
limitar el volumen de datos que se tienen disponibles para examinarlos fácilmente.
Como grandes cantidades de información se guardan en estas bitácoras, es importante
para una correcta administración del sistema, contar con un sistema automático de
monitoreo, que avise ante ciertos eventos.
La administración de logs en cuanto a la ubicación de sus logs se puede ver de tres
distintas maneras:
1. Tener un único servidor central para la administración de logs.
2. Tener varios servidores distribuidos, que se repartan los logs por su
clasificación de los mismos.
3. Tener varios servidores distribuidos, que tengan replicas.
En cuanto a la seguridad, es muy importante restringir el acceso y modificación a estos
archivos. Para ello contamos con los permisos que maneja el sistema operativo. Es
muy raro que necesitemos algo más, a excepción posiblemente de la encripción. De
todas maneras, en un entorno UNIX, el sistema operativo por defecto restringe las
modificaciones de log de sistema, a excepción del usuario root.
Página 11 de 14
Conclusiones
Todo lo referido a la administración de logs es una tarea crítica. No basta con tener un
sistema centralizado bien diseñado y correctamente implementado sino se le da la
misma importancia al chequeo o a la administración de los archivos en el servidor con
respecto a su integridad y rotación; para tener un sistema de administración de logs
eficiente, es necesario cumplir y con creces cada uno de los puntos.
Una particularidad interesante mencionada ya, es que los archivos de logs, pese a su
aparente simpleza por ser archivos de texto plano, sirven como herramientas legales a
la hora de investigar intrusiones en los sistemas informáticos. Es más, siempre hay que
tener en mente que son esenciales a la hora de tomar medidas legales contra esos
intrusos.
La administración de logs es crítica, así que es de vital importancia darle la importancia
que se merece.
A modo personal, considero estas prácticas como las básicas y esenciales para
cualquier administrador que quiera cumplir mínimamente con un sistema de
administración de logs eficiente:
1. Implementar una rotación de logs que mantenga los logs en un tamaño
manejable. Nunca dejar que los logs lleguen a tamaños desorbitantes y si ese
fue el caso, arreglarlo.
2. Más importante que loguear, es saber que acción tomar ante un evento. Si no
se monitorea el log, es un desperdicio de recursos.
3. Buscar siempre proteger la autenticidad de los logs. Es importante que no sean
alterables y en el caso que hayan sido modificados, que sea probable.
4. El tiempo es probablemente el factor más importante en un log. Mantener
siempre el tiempo real.
5. Por más que el log sea un archivo que registra el pasado, es invaluable si es
necesario. Por eso, siempre realizar copias de seguridad al momento de
trabajar con el.
6. 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. O sea, establecer otros medios de almacenamiento secundario.
7. Tener en claro donde se almacenara cada log, categorizarlos según su
importancia y tiempo de vida. Referido al lugar de almacenamiento, tener en
cuenta que un log de un sistema confidencial no puede estar al alcance de
cualquier usuario.
8. Tomar una estrategia respecto a los logs en cuanto a su distribución
(centralizada o distribuida).
Página 12 de 14
9. En el caso de UNIX, usar syslog como herramienta. Es sumamente potente y
esta muy bien documentada. Otras las herramientas de amplio uso para el
monitoreo de UNIX son las siguientes: Tripwire, CDM, TANGO04, SAMHAIN,
Snort, Osiris, Centrify DirectAudit, logrotate, et
10. Los logs deben ser exactos, autentificables y accesibles por los usuarios
adecuados. Es importante proteger los logs de accesos no autorizados que
puedan poner en riesgo su integridad.
Página 13 de 14
Bibliografía
•
http:en.wikipedia.org/wiki/Syslog
Syslog, definición
•
http:iie.fing.edu.uy/ense/asign/admunix/logs.htm#Heading7
Curso de administración UNIX. Syslog y Archivos de registro de eventos
•
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:oreilly.com/openbook/debian/book/ch07_04.html
“Learning Debian GNU/Linux, capitulo 7.4”: Logs del sistema.
•
http:support.microsoft.com/kb/308427
Cómo ver y administrar registros de sucesos en el Visor de sucesos de Windows
XP
Página 14 de 14