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