Control de logs. Pablo Sanz Mercado.

Tamaño: px

Comenzar la demostración a partir de la página:

Download "Control de logs. Pablo Sanz Mercado."

Gloria Marín Medina
hace 8 años
Vistas:

1 Control de logs. Pablo Sanz Mercado. 1

2 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

nos permitirá poder solucionar el problema y así evitar que vuelva a ocurrir.

3 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

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.

4 * 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

Mensajes generados internamente por syslogd. * user. Mensajes genéricos del nivel de usuario. * uucp. Mensajes del sistema uucp. * local0. Reservado para uso local.

5 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

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

Documentos relacionados

Políticas de. Respaldo de Información. C.E.T.P E.M.T. Informática I.T.S Sistemas Operativos III - Prof. Leonardo Carámbula

Políticas de. Respaldo de Información. C.E.T.P E.M.T. Informática I.T.S Sistemas Operativos III - Prof. Leonardo Carámbula Políticas de Respaldo de Información Políticas de Respaldo Métodos más frecuentes: Copia de seguridad normal Copia de seguridad diaria Copia de seguridad incremental Copia de seguridad diferencial Políticas