Control de logs.

Pablo Sanz Mercado.

El sistema de logs de un ordenador es fundamental, y curiosamente es lo menos utilizado. Cualquier anomal que presente el sistema operativo, o la mayor de los a a programas instalados en nuestro sistema, dejar un rastro, un comentario sobre lo a ocurrido, en un chero de registro, que nos permitir poder solucionar el problema a y as evitar que vuelva a ocurrir. Logs hay de muchos tipos, desde errores m nimos en el uso de aplicaciones, hasta intentos fallidos de entrada en el sistema. Nosotros nos centraremos en los logs de seguridad, si bien mucho de lo que se hable a continuacin tambin se puede aplicar o e a cualquier tipo de registro. Fundamentalmente el demonio que gestiona los logs del sistema es syslog, que se debe arrancar al inicio de la mquina y siempre debe estar operativo, es decir, a debemos asegurarnos de que en todos los directorios /etc/rc?.d (salvo en los de reinicio y apagado por supuesto), exista un enlace simblico que comience por S y o que apunte al demonio syslog (/etc/init.d/syslog), pues si no tenemos bien congurado este punto, es posible que cuando cambiemos de nivel de ejecucin se pare o el demonio syslog y por lo tanto perderemos todos los datos que posiblemente nos alerten de intrusiones. Por supuesto lo primero que intenta hacer un hacker al acceder al sistema es hacerse con el sistema de registro. Habitualmente se eliminan los rastros de la entrada en el sistema, y se prepara el demonio para que no registre nada de la actividad del hacker, para que este demonio siga haciendo su trabajo y no alerte su ausencia de registros al administrador, pero que lo que reciba este sea errneo. o Es fundamental por lo tanto que estos registros se transeran a otro sitio diferente del ordenador cuanto antes, pues el hacker en este tipo de operaciones estar rpidamente atrapado, ya que le ser muy complicado evitar que los registros a a a lleguen a manos del administrador si estos se han transferido rpidamente a una a cuenta de correo electrnico en un servidor externo, o bien se han transferido los o logs tal cual a otro ordenador. Este tipo de actuaciones se pueden realizar directamente desde la conguracin del propio syslog, con herramientas que procesen los o registros de forma rutinaria o bien con trucos de administracin como por ejemplo o copias programadas o sincronizacin con otros ordenadores. o

1.

syslog.

La conguracin de este demonio la tenemos en el chero o /etc/syslog.conf que est compuesto de l a neas que denen diferentes pol ticas de registro. Cada una de estas l neas est compuesta de dos columnas. En la primera se a dene la actividad y el grado de seriedad de los registros y en la segunda dnde o quedarn grabados. Por ejemplo podemos tener la l a nea: cron.* 2 /var/log/cron

con la cual queremos decir que cualquier mensaje que provenga del cron, quedar rea gistrado en el chero /var/log/cron. Hemos especicado cualquier mensaje porque tenemos el s mbolo * despus del punto que separa el proceso que genera infore mes de la gravedad de los mismos. Si queremos registrar solo ciertos mensajes del cron, lo que deberemos hacer es cambiar el asterisco por el ndice de gravedad que deseemos, siendo estos, ordenados de menor a mayor gravedad: * debug. Mensaje de depuracin. o * info. Mensaje informativo. * notice. Condicin normal, pero signicativa. o * warning. Hay condiciones de advertencia. * warn. El mismo caso que warning. En desuso. * err. Hay condiciones de error. * error. El mismo caso que err. En desuso. * crit. Las condiciones son cr ticas. * alert. Se debe tomar una accin correctora inmediatamente. o * emerg. El sistema est inutilizable. a * panic. El mismo caso que emerg. En desuso. Es decir, si queremos que cron registre solamente las entradas informativas en el chero /var/log/cron.info, tendr amos que escribir: cron.info /var/log/cron.info Si precedemos al nombre del chero donde queremos guardar el registro, el s mbolo menos (-), no sincronizaremos el disco despus de la escritura, para mejorar e las prestaciones de la mquina (sobre todo cuando realizamos muchos registros de a este tipo), pero hay que tener en cuenta que una ca de la mquina con esta da a conguracin har perder los ultimos registros (no sincronizados). o a Las facilidades sobre las que podemos guardar registros son: * auth. Mensajes de seguridad o autorizacin. Es conveniente utilizar no obso tante authpriv. * authpriv. Mensajes de seguridad o autorizacin. o * cron. Mensajes relacionados con el cron. * daemon. Mensajes realacionados con otros demonios del sistema. 3

* kern. Mensajes del n cleo. u * lpr. Mensajes del subsistema de impresin. o * mail. Mensajes del subsistema de correo electrnico. o * mark. Para uso interno exclusivamente, no debe usarse en aplicaciones. * news. Mensajes del subsistema de news. * security. El mismo caso que auth. En desuso. * syslog. Mensajes generados internamente por syslogd. * user. Mensajes genricos del nivel de usuario. e * uucp. Mensajes del sistema uucp. * local0. Reservado para uso local. * local7. Reservado para uso local. Es decir, si queremos que todos los mensajes de naturaleza cr tica, relacionados con el kernel, se queden reejados en el chero /var/log/kernel.critico, tendr amos que congurar este chero con la siguiente l nea: kern.crit /var/log/kernel.critico En una misma l nea podemos incluir diferentes entradas, es decir, podemos volcar a un mismo chero diferentes fuentes de mensajes, para ello tendremos que separar cada instancia mediante una coma si queremos utilizar el mismo nivel de generacin de logs, o mediante un punto y coma si queremos que sea diferente, es o decir: kern,mail.crit /var/log/mensajes.criticos registrar todas las entradas cr a ticas de mail y kern en /var/log/mensajes.criticos, mientras que: kern.debug;mail.crit /var/log/mensajes.criticos registrar todas las entradas cr a ticas de mail y las entradas debug de kern en el mismo chero. Adems hay que tener en cuenta que podemos hacer uso de cualquier chero en a nuestro sistema para registrar entradas de log. Como en linux podemos decir que cualquier dispositivo se comporta como un chero, lo que podemos hacer es pasar mensajes por ejemplo a la consola, para ello lo unico que tendremos que hacer es escribir /dev/console en vez del archivo que tuviramos en mente, hacindose este e e tipo de conguraciones para mensajes realmente preocupantes, como todos aquellos mensajes de emergencia que produce el kernel: kern.emerg /dev/console 4

2.

Logwatch.

Los logs deber leerse a diario, ya que es la unica manera de saber el estado de an nuestra mquina. Ya que puede llegar a ser complicado su lectura, ya que estamos a hablando de diferentes archivos a los que tendremos que acceder diariamente, discriminando las entradas le das con anterioridad de las no le das, lo que suele hacerse es instalar (o programar) una herramienta que genere informes de forma rutinaria que sean mandados por correo electrnico, de tal forma que podamos, diariamente o por ejemplo, tener una idea correcta del funcionamiento de nuestra mquina. a Una herramienta muy utilizada para este n es Logwatch, herramienta desarrollada con el n de generar informes sencillos de leer por el administrador. Una vez tenemos instalada esta utilidad, deber amos congurarla editando el chero logwatch.conf debiendo modicar al menos las siguientes tres entradas, si bien, como en todos los cheros de conguracin, deber o amos examinar cada uno de los defectos que nos aparece para garantizarnos que se acomodan a nuestra conguracin. o * MailTo = root * Range = yesterday * Detail = High La primera nos sirve para congurar la cuenta de correo electrnico a la que o queremos que mande el informe, en el ejemplo se dirigir al usuario root. En la a segunda entrada recogemos el rango del que queremos hacer el informe, si programamos la tarea por ejemplo en el cron, la podemos programar por ejemplo a las doce y un minuto de la noche, y as con este rango, justo en el primer minuto del , nuevo d nos mandar un informe con la actividad del d que acaba de terminar. a a a En cuanto a la ultima l nea, comentar que se reere al detalle con el que queremos que se realice el informe, siendo conveniente que sea un detalle alto para que podamos tener toda la informacin de nuestro sistema y no slamente parcial, si bien o o los informes sern mucho menos rpidos de analizar. a a