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

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:

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:

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.

(Visited 1.398 times, 16 visits today)

7 Comentarios

  1. Para usar las dos vías descritas por H3R3T1C hay que modificar el fichero 30-server-remoto.conf para que interprete correctamente los logs generados por en este caso nginx y squid y los ponga independientes…

    Luego lo hago y actualizo.

    Chao.

  2. Saludos, hermanos.

    Te faltó una variante en la ultima parte, y es el uso de syslog-ng.

    Una sugerencia es tener un CT que contenga un directorio con base NFS en el nodo Proxmox VE donde guardes los logs de los equipos remotos.

    La configuración puede ser la siguiente:

    source s_net {
    udp(ip(DIRECCION_IP_DEL_SERVIDOR) port(514));
    };
    (…)
    destination d_remote_logs {
    file(“/srv/services/rsyslog/$YEAR-$MONTH-$DAY/$FULLHOST”
    owner(root) group(root) perm(0640) dir_perm(0750) create_dirs(yes)
    template(“$DATE $FULLHOST $PROGRAM $TAG [$FACILITY.$LEVEL] $MESSAGE\n”));
    };
    (…)
    log { source(s_net); destination (d_remote_logs); };
    log { source(s_src); destination (d_remote_logs); };
    (…)

    NOTA: Claro está que hay que probar también con él mismo.

    Entonces, como rsyslog es el que está marcado, pues, hay que desmarcarlo:

    systemctl unmask rsyslog.service

    No preocuparse, syslog-ng está habilitado en systemd. La ruta “/srv/services/rsyslog” es donde guardo los logs (NFS por debajo en el nodo Proxmox VE).

    Ahora bien, el que lo quiera pájaro/cuqui, puede poner esas opciones dentro de /etc/syslog-ng/conf.d y dejar intacto el archivo de configuración original.

    Ya solamente queda configurar el syslog-ng como cliente en TODOS los linuxes, aunque se puede dejar el rsyslog que viene por defecto, pero configurarlo contra el Syslog Server.

    Espero les sirva la sugerencia. 😀

  3. La parte cliente:

    destination d_net {
    udp( “DIRECCION IP DEL SERVIDOR” );
    };
    (…)
    destination d_net_tcp_tls {
    network(“DIRECCION IP DEL SERVIDOR” port(PUERTO)
    transport(“tls”)
    tls(ca-dir(“/etc/syslog-ng/ssl”))
    );
    };
    (…)
    log { source(s_src); destination(d_net); };

    Aún la onda del TLS me da palos, así que asumo por el 514/udp, de momento.

    😀

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*