Con audisp-remote puedes reunir los registros de auditoría de varios equipos Ubuntu 24.04 en un servidor central sin dejar de guardarlos en cada equipo. Necesitas dos componentes: un cliente que envíe los eventos y un receptor Auditd que los escriba en su propio registro.
Este ejemplo usa una VPN ya configurada. El modo TCP de Auditd no cifra ni autentica por sí mismo, así que utiliza la dirección del receptor dentro de la VPN y no expongas el puerto a Internet. Si tu infraestructura ya usa Kerberos, KRB5 permite autenticar y cifrar la conexión, pero requiere configurarlo en ambos extremos.
Configurar el receptor de Auditd
Instala auditd en el servidor receptor si todavía no lo tienes. Edita /etc/audit/auditd.conf y ajusta estas opciones sin duplicar las entradas existentes:
tcp_listen_port = 16000
transport = TCP
write_logs = yesEn el cortafuegos del receptor, permite el puerto 16000/TCP solo desde las direcciones de los clientes autorizados dentro de la VPN. Usar la dirección privada en el cliente no limita por sí solo las interfaces en las que escucha el servidor.
Solicita la recarga de Auditd y comprueba que el puerto ha quedado en escucha:
sudo auditctl --signal reload
sudo ss -ltnp 'sport = :16000'Si el puerto no aparece, revisa los mensajes con sudo journalctl -u auditd -b. Si la configuración es correcta pero la recarga no ha abierto el puerto, aplica el cambio con un reinicio planificado del receptor y vuelve a comprobar la escucha antes de continuar.
Activar el reenvío en el cliente
Instala el paquete que incluye el complemento de reenvío:
sudo apt install audispd-pluginsEn /etc/audit/audisp-remote.conf, indica la dirección del receptor dentro de la VPN. Sustituye el nombre de ejemplo por el nombre o la IP que corresponda a tu red:
remote_server = audit-receptor.example.net
port = 16000
transport = TCPEn /etc/audit/plugins.d/au-remote.conf, cambia active a yes. Para distinguir los equipos en el registro central, configura un nombre de nodo único en /etc/audit/auditd.conf de cada cliente. Por ejemplo:
name_format = USER
name = client01Solicita la recarga con sudo auditctl --signal reload. Si Auditd no inicia el complemento o sigue usando la configuración anterior, revisa los mensajes del servicio antes de repetir la comprobación.
Comprobar que el evento llega al registro central
En el cliente, genera un evento de auditoría con un texto fácil de reconocer:
sudo auditctl -m "centralization-check-client01"En el receptor, busca los eventos recientes de tipo USER procedentes de ese nodo. Si has elegido otro nombre, sustitúyelo en la consulta:
sudo ausearch --input-logs --start recent --message USER --node client01 --interpretConfirma que aparecen el texto centralization-check-client01, el nodo esperado y la hora del envío. Así compruebas que el evento llegó y quedó escrito en el registro del receptor. Si no aparece, búscalo primero en el registro local del cliente y después revisa los mensajes del complemento, la conexión y el espacio disponible en el receptor.
Qué ocurre si se corta la conexión
Recibir un evento confirma que el envío funciona en ese momento, pero no que se recuperen los registros de una interrupción. Si necesitas guardarlos temporalmente en el cliente, audisp-remote permite usar mode = forward con format = managed. La cola en disco tiene un límite definido por queue_depth. Dimensiona esa cola según el volumen de registros y el tiempo de interrupción que necesitas cubrir.
Para configurar las reglas que generan los eventos, consulta la guía de Auditd en Ubuntu.
