Control de logs.

Control de logs.
Pablo Sanz Mercado.
1
El sistema de logs de un ordenador es fundamental, y curiosamente es lo menos
utilizado. Cualquier anomalı́a que presente el sistema operativo, o la mayorı́a de los
programas instalados en nuestro sistema, dejará un rastro, un comentario sobre lo
ocurrido, en un fichero de registro, que nos permitirá poder solucionar el problema
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 continuación también se puede aplicar
a cualquier tipo de registro.
Fundamentalmente el demonio que gestiona los logs del sistema es syslog, que
se debe arrancar al inicio de la máquina y siempre debe estar operativo, es decir,
debemos asegurarnos de que en todos los directorios /etc/rc?.d (salvo en los de
reinicio y apagado por supuesto), exista un enlace simbólico que comience por S y
que apunte al demonio syslog (/etc/init.d/syslog), pues si no tenemos bien configurado este punto, es posible que cuando cambiemos de nivel de ejecución se pare
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 erróneo.
Es fundamental por lo tanto que estos registros se transfieran a otro sitio diferente del ordenador cuanto antes, pues el hacker en este tipo de operaciones estará rápidamente atrapado, ya que le será muy complicado evitar que los registros
lleguen a manos del administrador si estos se han transferido rápidamente a una
cuenta de correo electrónico en un servidor externo, o bien se han transferido los
logs tal cual a otro ordenador. Este tipo de actuaciones se pueden realizar directamente desde la configuración del propio syslog, con herramientas que procesen los
registros de forma rutinaria o bien con trucos de administración como por ejemplo
copias programadas o sincronización con otros ordenadores.
1.
syslog.
La configuración de este demonio la tenemos en el fichero
/etc/syslog.conf que está compuesto de lı́neas que definen diferentes polı́ticas de
registro.
Cada una de estas lı́neas está compuesta de dos columnas. En la primera se
define la actividad y el grado de seriedad de los registros y en la segunda dónde
quedarán grabados. Por ejemplo podemos tener la lı́nea:
cron.*
/var/log/cron
2
con la cual queremos decir que cualquier mensaje que provenga del cron, quedará registrado en el fichero /var/log/cron. Hemos especificado cualquier mensaje porque
tenemos el sı́mbolo * después del punto que separa el proceso que genera informes 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 depuración.
* info. Mensaje informativo.
* notice. Condición normal, pero significativa.
* 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 acción correctora inmediatamente.
* emerg. El sistema está inutilizable.
* panic. El mismo caso que emerg. En desuso.
Es decir, si queremos que cron registre solamente las entradas informativas en
el fichero /var/log/cron.info, tendrı́amos que escribir:
cron.info /var/log/cron.info
Si precedemos al nombre del fichero donde queremos guardar el registro, el
sı́mbolo menos (-), no sincronizaremos el disco después de la escritura, para mejorar
las prestaciones de la máquina (sobre todo cuando realizamos muchos registros de
este tipo), pero hay que tener en cuenta que una caı́da de la máquina con esta
configuración harı́a perder los últimos registros (no sincronizados).
Las facilidades sobre las que podemos guardar registros son:
* auth. Mensajes de seguridad o autorización. Es conveniente utilizar no obstante authpriv.
* authpriv. Mensajes de seguridad o autorización.
* cron. Mensajes relacionados con el cron.
* daemon. Mensajes realacionados con otros demonios del sistema.
3
* kern. Mensajes del núcleo.
* lpr. Mensajes del subsistema de impresión.
* mail. Mensajes del subsistema de correo electrónico.
* 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 genéricos del nivel de usuario.
* 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 reflejados en el fichero
/var/log/kernel.critico, tendrı́amos que configurar este fichero 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 fichero diferentes fuentes de mensajes, para ello tendremos que
separar cada instancia mediante una coma si queremos utilizar el mismo nivel de
generación de logs, o mediante un punto y coma si queremos que sea diferente, es
decir:
kern,mail.crit /var/log/mensajes.criticos
registrarı́a todas las entradas crı́ticas de mail y kern en /var/log/mensajes.criticos,
mientras que:
kern.debug;mail.crit /var/log/mensajes.criticos
registrarı́a todas las entradas crı́ticas de mail y las entradas debug de kern en el
mismo fichero.
Además hay que tener en cuenta que podemos hacer uso de cualquier fichero en
nuestro sistema para registrar entradas de log. Como en linux podemos decir que
cualquier dispositivo se comporta como un fichero, lo que podemos hacer es pasar
mensajes por ejemplo a la consola, para ello lo único que tendremos que hacer es
escribir /dev/console en vez del archivo que tuviéramos en mente, haciéndose este
tipo de configuraciones para mensajes realmente preocupantes, como todos aquellos
mensajes de emergencia que produce el kernel:
kern.emerg /dev/console
4
2.
Logwatch.
Los logs deberı́an leerse a diario, ya que es la única manera de saber el estado de
nuestra máquina. Ya que puede llegar a ser complicado su lectura, ya que estamos
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 electrónico, de tal forma que podamos, diariamente
por ejemplo, tener una idea correcta del funcionamiento de nuestra máquina.
Una herramienta muy utilizada para este fin es Logwatch, herramienta desarrollada con el fin de generar informes sencillos de leer por el administrador. Una vez
tenemos instalada esta utilidad, deberı́amos configurarla editando el fichero logwatch.conf debiendo modificar al menos las siguientes tres entradas, si bien, como en
todos los ficheros de configuración, deberı́amos examinar cada uno de los defectos
que nos aparece para garantizarnos que se acomodan a nuestra configuración.
* MailTo = root
* Range = yesterday
* Detail = High
La primera nos sirve para configurar la cuenta de correo electrónico a la que
queremos que mande el informe, en el ejemplo se dirigirá al usuario root. En la
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ı́a nos mandarı́a un informe con la actividad del dı́a que acaba de terminar.
En cuanto a la última lı́nea, comentar que se refiere al detalle con el que queremos
que se realice el informe, siendo conveniente que sea un detalle alto para que podamos tener toda la información de nuestro sistema y no sólamente parcial, si bien
los informes serán mucho menos rápidos de analizar.
5