Decodificadores, de la línea a los campos

El servidor decodifica en dos pasos. Primero, la pre-decodificación saca lo que tienen casi todas las líneas de syslog: la hora, el nombre del equipo y el nombre del programa. Después entran los decodificadores: un decodificador padre reconoce al programa por su nombre, y los decodificadores hijo, que declaran quién es su padre, aplican una expresión que saca los campos de ese formato de mensaje y los nombra en el orden en que los capturan.

La herramienta de prueba del servidor, wazuh-logtest, enseña esas fases una tras otra: pre-decodificación, decodificación y, al final, la regla que salta. Es la forma de comprobar un decodificador sin esperar a que ocurra un evento real.

Abre las tres tablas: log_crudo, decodificadores y decodificado.

En decodificado cada fila dice qué decodificador procesó una línea y qué campos sacó. Los campos son lo que luego se busca en el panel: filtrar por usuario, por caja o por dirección de origen solo es posible porque un decodificador los separó antes. Un decodificador que no saca el campo correcto deja la línea guardada pero invisible para esa búsqueda.

La línea 3 es un descuento manual hecho en una caja, un evento que interesa al área de pérdidas.

Los decodificadores que trae el producto cubren programas muy comunes, como el servicio de acceso remoto por SSH. Para esos, el campo srcip, la dirección de origen, ya sale hecho. Es el campo más usado de una investigación: con él se agrupa, se cruza con el inventario y se decide si bloquear.

La línea 4 es un intento fallido de inicio de sesión remoto en el servidor web.

La línea 5 la escribió panpos y el decodificador padre la reconoció, pero ningún hijo encajó con su mensaje: no se sacó ningún campo. La línea llegó al servidor, quedó registrada, pero ninguna regla que pregunte por un usuario o una caja puede dispararse con ella. Es un caso frecuente cuando un programa se actualiza y cambia el texto de sus mensajes.