Volver al blog

Como configurar un server de logs en Linux y configurar tus clientes correctamente.

Tutorial de como montar un servidor de logs en GNU/Linux (Debian/Ubuntu) usando rsyslog y como configurar los clientes, con detalles, sugerencias y tips.

índice

Generalmente la conservación de logs es un problema en todo ambiente de administración de red (¡la ley lo exige!), en linux por suerte tenemos a rsyslog que es el server de logs por defecto en Debian 9 y Ubuntu 16.04.3 LTS a continuación un breve tutorial de cómo crear un server de logs y configurar a tus clientes correctamente para que envíen logs a este de la manera más segura posible.

Antes de empezar algunos comentarios.

Este tutorial solo aplica a rsyslog, no funciona con syslog-ng porque tiene otra sintaxis, pero la idea es la misma así que eres más que bienvenido a ajustarlo y publicar un tutorial sobre cómo hacerlo con syslog-ng.

Se asume una configuración de proxmox con varios CT clientes que generan logs y un CT que actuará como servidor del logs central.

Pero para nada es necesario que sea en proxmox y con CT, puedes hacerlos con máquinas físicas reales, con máquinas virtuales (no CT) en VMWare, etc.

Solo los logs que se procesan por syslogs serán manejados, otros servicios que usan logs directos a ficheros no se procesan y debes moverlos a mano (squid3, apache, nginx… más de esto al final)

Manos a la obra.

Empecemos, llamemos a la máquina que actuará como servidor “server-log” y pongamos que tiene como IP 192.168.0.12; los clientes serán simplemente “clientes”. Como server-log podemos usar el CT con sawmill que se explica en este post.

Ahora debes descargar este fichero logs.rar que contiene todos los ficheros pre-configurados que se usarán en este tutorial.

Configurando el server.

La configuración que necesitas para activar al server-logs como servidor de logs está en el fichero “30-server-remoto.conf” (si el número es importante, puedes variar el nombre, pero no el numero inicial) debes copiarlo a la PC/CT/MV de server-logs en /etc/rsyslog.d/ no reinicies syslog todavía, falta un paso.

Y ahora vamos a crear el directorio de logs para los hosts remotos. Si se fijaron en el fichero que acaban de copiar este directorio será “/var/log/hosts/” ustedes pueden cambiarlo a voluntad y ponerlo donde quiera, pero siempre debe recordar cambiarlo en el fichero “30-server-remoto.conf”

¿Como lo creamos?   copiar y pegar esto en consola, como root, claro:

mkdir /var/log/hosts/
chown syslog:adm /var/log/hosts
chmod 0755 /var/log/hosts

Esto crea el directorio, le pone los dueños y permisos correctos. Ahora sí estamos listos para reiniciar el servicio de logs, de esta manera:

service rsyslog restart

Si todo va bien ya tendremos a rsyslog escuchando en la PC, listo para recibir los logs remotos.

Configurando los clientes.

Ahora toca configurar los clientes para que envíen los logs al server, usa para esto el fichero “30-cliente-remoto.conf”

Este fichero lo ponen en el PC/CT/VM que debe enviar logs al server remoto en la carpeta /etc/rsyslog.d/ claro, deben fijarse y poner en este fichero la IP correcta del server-log, en este ejemplo usamos 192.168.0.12 así que tu debes configurar tu IP correcta.

Reinician el rsyslog como mismo hicieron en el server (ver más arriba) y ya deben tener una carpeta con el IP del cliente en el directorio /var/log/hosts del server.

Esto lo repiten con todas las PC/CT/VM que deben generar logs y listo, verás como se va llenando la carpeta del server con las carpetas de IP por cada cliente.

Algunas notas antes de pasar a otro tema.

Si, usamos TCP para las conexiones, según la bibliografía usar TCP lleva un ligero costo adicional de procesamiento y es un poco más lento, pero tiene como ventaja que eliminas la posibilidad de perder entradas de logs que existe con las conexiones UDP. (si, lee, busca, con UDP pueden perder entradas de logs y ser víctima de DoS para que no se registre actividad maliciosa)

Si aun así quieres usar UDP, simple, revisa la línea del cliente y donde pones la IP, pon una sola “@” delante de la IP, esto pasará a usar UDP listo.

Si, los logs NO SE PIERDEN si el server sale de línea o si simplemente necesitas reiniciarlo, el cliente está instruido para que guarde los logs en memoria mientras no pueda enviarlos al server-logs e incluso escribirlos al disco si no tiene memoria suficiente y antes de apagar la PC para enviarlos luego. (¿Que conveniente verdad?)

Lo anterior funciona de maravillas, vi un cliente enviar ~800 MB de logs a un server-logs porque este estuvo apagado por 6 meses…

No es necesario rotar los logs en los clientes por 365/52/12 (días/semanas/meses) porque estos logs estarán siendo enviados a él server, de hecho, es recomendable una vez confirmado que esto funciona configurar el logrotate para hacerlo diario y conservar solo una o dos copias de estos… para mantener el uso de disco al mínimo…

Rotando los logs.

Ahora toca asegurarnos que los logs remotos roten en el server-logs sino tendremos ficheros enormes, simplemente usa el fichero "logs-remotos" y ponlo en "/etc/logrotate.d/" para que logrotate pueda hacer su trabajo.

Esto rotará los logs diarios para cada uno de los logs que se reciban de manera remota, pero es posible que se puedan rotar semanales o mensuales, eso queda a tu elección, simplemente revisa el fichero y cambia los parámetros necesarios.

Ojo, si pusiste los logs en otro directorio que no es el mismo que el que mencionamos en todo este tutorial debes cambiarlo en este fichero también.

Y los que no usan rsyslog?

Bueno, si quieres que al server también se compilen los logs de los servicios que no usan rsyslog puede hacer dos cosas:

  1. La vía Ideal: Modificar el software en cuestión para que envíe logs a rsyslog de manera local y estos terminarán en el server-logs al final del día (alguna vez lo hice con squid2.7, apache puede hacerlo, nginx también...)
  2. La vía rápida: Mantener y rotar estos logs en el PC/CT/VM local por el año que se estipula y haz un rsync de esta carpeta al server de logs cada cierto tiempo, diariamente o cada hora en dependencia de la carga y objetivos que tengas con estos logs.

Eso es todo, cualquier problema, corrección o sugerencia déjenlo en los comentarios.

Suscríbete · Newsletter

Mantente al día, cada semana

Artículos prácticos sobre Linux, redes, seguridad, virtualización y la nube — escritos por sysadmins cubanos.

  • Guías y tutoriales de administración de sistemas
  • Nuevos artículos sobre servidores, redes y nube
  • Sin spam, cancela cuando quieras

Respetamos tu bandeja de entrada. Cancela con un clic.

Patrocinado por SYSCU

¿Tu infraestructura en la nube te cuesta de más?

SYSCU optimiza tu nube de punta a punta — FinOps, DevOps & CI/CD, migraciones a AWS, seguridad y observabilidad. Equipo 100 % senior que reduce tu factura hasta un 40 % y acelera tus despliegues en semanas.

Nuevo · BetaSYSCU Atlas Insight — la plataforma FinOps que convierte tu gasto AWS en decisiones: visibilidad multi-cuenta, recomendaciones automáticas y alertas de anomalías.

No comments yet