VMware vCenter Server 6.7 y Rsyslog CentOS o Red Hat 7

Hola sufridores “informáticos”, el post de hoy va dedicado a los que como yo, ofrecen conocimiento gratuito en forma de publicaciones u entradas, para que otros aprendan o salgan del problema que se les presenta o simplemente se entretengan haciendo esto, en vez de comprando un DLC para unos de sus juegos favoritos … después de ese DLC viene otro y lo sabes !!!.

Si no sabéis cuál era uno de mis anteriores blog os dejo la url www.cmdsistemas.es

Hoy es el aniversario para mi, de la fecha en la que empece a escribir en internet tratando de aportar conocimientos, que nunca son inventados, no soy un genio, simplemente son horas de lectura sobre personas que saben más que yo, ya sean libros, manuales, blogs, documentación oficial etc.

Dejemos la lectura de almohada y vamos con Rsyslog.

Este tema va tratar como tener un servidor centralizado de logs mediante la herramienta de Linux RSYSLOG. Y de paso vamos aprovechar para aprende donde tenemos que configurar VCenter para que le mande los logs a nuestro server de logs, matamos dos pájaros de un tiro. (sentido figurado, I love pájaros).

No os lo vais a creer pero ahora esta sonando Loquillo y los Trogloditas, Cadillac Solitario:

” Quizás el “martini” me ha hecho recordar 
nena, ¨por qué no volviste a llamar? 
Creí que podía olvidarte sin más 
y aún a ratos, ya ves. “

Si que recuerdos de cuando viví en Madrid y trabajaba en Telefónica Data en Guzman el Bueno con la Frame Relay y CISCO, también me recuerda una época feliz que estuve contratado en Cap Gemini pero me tenían en Repsol YPF (maravilloso) en proyectos, de aquella Cap Gemini pagaba bien; además de aquella conocí alguna chica que es difícil de olvidar … pero que ha “pasao” con todo eso??!! Así no empieza el post ni las capturas … ya estamos con la lectura de almohada otra vez …, pero no pasa nada ya acabo de sonar, vamos allá.

RSYSLOG, he seleccionado esta herramienta principalmente porque viene implementada en Red Hat y todo lo que viene en red Hat es bueno, muy bueno y además es de los más usados en Linux. Todos los que estáis sabéis que es un log, pueden ser que nos informen de una acción de un usuario, una actividad de red, un fallo de hardware, un evento de sistema, logs en dispositivos de red desde una caída de interface a un fallo en un ventilador, etc.
Si tenéis windows el programa KiwiSyslog os soluciona mucho, teniendo versión gratuita y de pago, pero en producción y si queremos aprovechar recursos, rsyslog es una solución buena sabiendo implementar y configurar, eso si or va requerir unas horas de laboratorio o pruebas. Rsyslog permite implementación de seguridad, alto procesamiento de logs, permite usar protocolo TCP y protocolo UDP, en el blog de www.cmdsistemas.es os explicaba hace años las principales diferencias entre esos protocolos. Además Rsyslog permite diferentes fuentes de recepción de distintas plataformas y sistemas operativos.
Rsyslog funciona cliente – servidor y lógicamente es mucho mas ligero que usar una comunidades SNMP, que veremos mas adelante en este blog con Zabbix.
Los logs de Rsyslog se nos van almacenar por defecto en el directorio /var/log por ello y por otras razones siempre aconsejo montar el directorio /var de Linux en una particion distinta a /etc y el resto de directorios principales y dependiendo si es una máquina virtual o no, tener en cuenta su crecimiento ya sea mediante Think provision o ampliación mediante LVM u otros medios. ( si esto no lo entiendes no te preocupes no es importante para este post).
Rsyslog funciona mediante Systemd Journa Dameon (journald) podéis ver la descripción pinchando aquí enlace.

Para funcionar con Rsyslog debemos tenerlo instalado tanto en el que va hacer de servidor como en el que va hacer de cliente. Rsyslog puede almacenar los logs de manera local, enviarlos a un servidor remoto, descartar el mensaje o a otro proceso mediante el “|”(pipe) como hacemos con algunos comandos de la consola linux. Rsyslog tiene un esquema de funcionamiento para los mensajes de log que genera y es el siguiente:
type (tipo de dato, en ingles facility).priority (severidad, severity_level) destino (destination, donde va ser enviado el log)

  • facility: es la aplicación o el tipo de proceso que se genera,incluye el auth, el cron, el daemon, el kernel, local0..local7. Si usamos el * significa que todas las aplicaciones o procesos. Su usamos none = facility no estable prioridades como por ejemplo seria escribir: mail.none
    auth= mensaje generado en el proceso de autenticación (login)
    cron= mensaje generado por procesos programados (crontab)
    daemon= mensaje generado por servicios internos (daemons)
    kernel = menajes generados por el propio servicio del kernel de linux
    mail=mensajes generador por el servidor de correo implicito en linux
    syslog= mensajes generados por el propio servicio (daemon) de rsyslog
    lpr= mensajes generador por las impresoras locales o servicios de impresión
    local0-7= mensajes personalizados definidos por el administrador, siendo el local7 asignado por CISCO o Windows
  • severity_level: el tipo o clasificación de mensaje: emerg-0, alert-1, crit-2, err-3, warn-4, notice-5, info-6, debug-7. Usar * como el caso anterior.
  • destination: comentado en las líneas del párrafo anterior y se define con la IP:puerto. Por ejemplo en el parrafo anterior decíamos que se podía descartar, esto sería enviándolo a /dev/null

Para el laboratorio yo he usado CentOS 7 de servidor y de cliente Red Hat, de cliente os vale cualquier cosa que genere logs siempre y cuando sepáis llegar a configurar bien el SO o el hardware.
((Advertencia: Algunas capturas a modo de mostrar el comando pueden estar realizadas tanto en cliente como en servidor, por lo que el nombre del host puede variar, pero sería lo mismo a fin de ver la ejecución y respuesta del comando, como por ejemplo saber si esta activo el proceso.))

Si no lo tenemos ya instalado que lo podemos comprobar con el comando que veis en la captura (no os fijéis en el nombre del equipo pues es una captura en el cliente no en el servidor en el que estamos trabajando ahora, ya que en el servidor CentOS sabía que no venía instalado pero en la versión de Rhel que tenía no estaba seguro, pero el comando lógicamente es el mismo):

…debemos instalarlo:
En CentOS sería:$ sudo yum update && yum install rsyslog
En Ubuntu sería:$ sudo apt update && apt install rsyslog
Etc …

Lo siguiente sería arrancar el servicio y hacer que este enable si reiniciamos, de ahí las siguientes dos líneas:
$ sudo systemctl start rsyslog
$ sudo systemctl enable rsyslog
$ sudo systemctl status rsyslog
Y esta última para ver si esta ya activo el daemon. También si estamos en modo root podemos escribir rsyslog.service es decir:
$ systemctl status rsyslog

También podemos hacer la instalación en CentOS por interface gráfico, sería instalar el paquete que veis marcado en el centro y pinchar en el botón requerido que también veis en la imagen para que nos marque los otros dos paquetes, de esta manera ya tendríamos los tres necesarios. En la imagen también veis un botón que dice eliminar, este si no lo tenéis instalado dira descargar y después cambiará a instalar.

 

La configuración principal de Rsyslog esta en el fichero rsyslog.conf en el directorio /etc/rsyslog.conf
También tenemos el directorio /etc/rsyslog.d/ pero este es para aplicaciones y servicios que igual vemos más adelante en otro post, aunque no se si le dedicaré tanto tiempo porque quiero montar para vosotros un servidor SNMP con Zabbix.
Necesitamos editar rsyslog.conf por ello al estar fuera del directorio (supongo si estas aquí no eres nuevo en linux) escribimos la ruta absoluta, podemos usar nano o el editor que más nos guste, yo suelo usar vi, que aunque no lo uso de manera avanzada para numerar las líneas e insertar código me gusta mas que nano u otros.
$sudo vim /etc/rsyslog.conf

Como decía al principio, Rsyslog funciona mediante Systemd Journa Dameon (journald) pero también con el modulo imuxsock para importar las estructuras de los mensajes de log vía los socket de Unix, entonces al editar el fichero de configuración que ya debéis tener en pantalla, veréis las líneas que cargan estos módulos:

Para saber más sobre rsyslog y problemas con sistemas IDS y en este caso con Snort y saber más acerca de este módulo de imuxsock, podéis leer estos dos artículos que son interesantes y da sabiduría extra además de ser muy cortos 🙂 (level UP) http://www.elmundoenbits.com/2013/03/imuxsock-rsyslog-limit.html#.W9mtM5NKhaQ y http://rm-rf.es/modificar-ratelimit-de-rsyslog-imuxsock/

Una vez en modo configuración vamos habilitar el servidor, para ello tenemos que descomentar una o dos líneas, dependiendo si quieres que escuche peticiones con el protocolo UDP, TCP o por ambos, yo de mano para hacer la prueba de funcionamiento os recomiendo TCP que aunque es más lento debía a los paquetes ACK de confirmación de recepción de paquetes de datos nos viene mejor para estar seguros de que funciona, en el ejemplo lo vamos hacer para ambos aunque luego en el cliente habilito solo para enviar por TCP. Udp os recuerdo que funciona sin ACK y por lo tanto hay datos que se pueden perder aunque en una red saludable y con tarjetas no saturadas la cache, no debería presentar problemas.

Si quereis un puerto distinto al 514 sería sustituirlo pero debéis recordar cambiarlo en todos los clientes que vayan a comunicarse, ya que por defecto la mayoría lo harán contra este puerto.

Ahora toca crear una plantilla que será usada para recepcionar en nuestro recién instalado servidor de logs. Esta plantilla le dirá a nuestro Rsyslog donde queremos salvar los mensajes enviados por los clientes que tenemos en red de syslog.
En el fichero que tenemos editado buscaremos la línea que dice GLOBAL DIRECTIVES y antes de ella escribiremos nuestra plantilla (template). En la captura en vez de una os voy a dejar tres porque veáis distintas plantillas, pero buscando por internet teneis varias hechas.

Como veis por ejemplo en la primera plantilla marcada con la primera flecha en rojo, las variables harán que en /var/log/ aparezca otro directorio con el nombre de la máquina y el programa que la genera.
La siguiente línea que dice: . ?RemoteLogs & ∼
se usa para indicar al Rsyslog que pare de procesar el mensaje recibido una vez creado el fichero y no sigo escribiendo en archivos de registro locales. La palabra RemoteLogs aunque esta en ingles en las dos líneas, es una palabra estandar que usamos en estas plantillas pero no indica nada, podría ser pepillo_grillo en ambas.
Si no encontráis por internet la plantilla que necesitáis necesitais mirar en la web oficial: https://www.rsyslog.com/
Ya podéis salvar y salir del editor vim, a continuación hay que reiniciar el servicio, además lo inicio en la última línea (por si las moscas):

Y comprobamos que rsyslog este escuchando por TCP e UDP, para ellos podemos usar el comando SS o netstat:

Como últimos pasos debemos permitir la entrada del tráfico en nuestro firewall y si tenemos habilitado secure linux lo mismo.
Para SELinux y Firewall sería:

Y reiniciamos el firewall:
firewall-cmd –reload
En ubuntu sería parecido pero no usa firewalld usa ufw:
#sudo ufw allow 514/udp
#sudo ufw allow 514/tcp
#sudo ufw reload

BIENNNN!!!, llegados a este punto ya tenemos nuestro servidor de syslogs, ahora vamos a proceder a activarlo en un cliente con linux, mi caso Red hat para por ejemplo ver como llegan los logs de autenticación que definíamos, explicábamos y marcábamos en la captura de más arriba en la tercera flecha roja.
También vamos habilitar el cliente syslog para el Vcenter 6.7 que daba título a esta publicación, pero deberemos para el vcenter, incluir una plantilla (template) nueva en el syslog.conf que dejaremos para otro post, pero que podéis hacer vuestros deberes y os animo a publicar alguna en los comentarios en este post.

Tenemos que entrar al Vcenter pero no por el puerto 443, sino por el puerto 5480 y tras meter nuestras credenciales de administrador, lo normal es adminitrator seguido de nuestro dominio de singleOn en mi caso administrator@vsphere.local y la password que escribimos en la instalación en este apartado. Luego en administrador de dispositivos vamos a syslog, ver la captura:

Pinchamos en configurar, debajo de Configuración de reenvío en la captura de encima de este texto y nos saldrá esta ventana:

Donde la Ip es la de nuestro servidor de rsyslog en el que llevamos trabajando durante toda la publicación y el puerto el que configuramos pero mejor usar protocolo TCP para las pruebas que UDP como en la imagen, yo tengo UDP pero ya había probado antes con UDP y una plantilla específica en rsyslog.
Podemos mandar un mensaje de prueba una vez guardado, en el botón diseñado para ese fin, dejo una captura:

Para configurar otro tipo de cliente para por ejemplo ver los logs de la plantillas que configuramos antes, como la de autenticación de usuario o login, hay que instalar rsyslog si no esta instalado y a continuación editar el fichero de antes rsyslog.conf. Yo lo hago sobre un Red Hat llamado rhel0.
sudo vim /etc/rsyslog.conf
Después hay que modificar una línea de las que viene para indicar donde esta el servidor remoto, es decir nuestro CentOS y en esta línea será encabezada por el símbolo @, pudiendo ser uno u dos seguidos dependiendo si quieres que se envíe en UDP o TCP. En la línea que os dejo de ejemplo veréis un asterisco,punto,asterisco (*.*), eso es para que envíe todo tipo de facilitys, si quisieramos solo los de autenticación, sería poner aut.*, os dejo una captura:

 

Cliente.

si en vez de *.* @@192.168.1.202:514 dijera: auth. * @@192.168.1.202:514 sería los de autenticación.
si en vez de *.*@@192.168.1.202:514 dijera: mail.*@192.168.1.202:514 serían los logs del servidor de correo en este cliente y fijaros que solo hay una “@”, por lo que sería por UDP el envío.
Creo que ya lo pillasteis todos :).
Toca grabar y salir y reiniciar el servicio.
$ sudo systemctl restart rsyslog

Ahora solo nos queda ir al servidor y monitorizar si generamos logs en nuestros clientes de syslog. Los fichero recordar que aparecerán en:
ls -l /var/log/
y si lo hicisteis como yo, o bien el nombre o bien la ip, os dejo una captura hecha dentro del directorio /var/log donde aparece el directorio rhel0 y dentro los log de autenticación.

Las reglas por defecto de donde guarda el cron, el mail, etc las veis en el propio fichero de configuración, si usáis linux sabéis que es en esos directorios donde vais a buscar.

Y por fin con esto hemos terminado al completo de probar nuestro servidor de logs y funciona, ahora es cuestión de ir centralizando en el y definiendo en cada máquina que queremos enviar.
Espero haberos ayudado un poco.

Hasta la próxima.