¿Cómo configurar un agregador de registros para autenticar datos?

8

Antecedentes : la agregación de registros remotos se considera una forma de mejorar la seguridad. En general, esto aborda el riesgo de que un atacante que compromete un sistema pueda editar o eliminar registros para frustrar el análisis forense. He estado investigando opciones de seguridad en herramientas de registro comunes.

Pero algo se siente mal. No puedo ver cómo configurar ninguno de los registradores remotos comunes (por ejemplo, rsyslog, syslog-ng, logstash) para autenticar que un mensaje entrante realmente se origina en el supuesto host. Sin algún tipo de restricción de política, un generador de registros podría falsificar mensajes en nombre de otro generador de registros.

El autor de rsyslog parece advertir sobre la autenticación de datos de registro :

Una última palabra de precaución: transport-tls protege la conexión entre el emisor y el receptor. No necesariamente protege contra ataques que están presentes en el mensaje mismo. Especialmente en un entorno de retransmisión, el mensaje puede haberse originado en un sistema malicioso, que colocó nombres de host y / u otro contenido no válido en él. Si no hay aprovisionamiento contra tales cosas, estos registros pueden aparecer en el repositorio de los receptores. -transport-tls no protege contra esto (pero puede ayudar, si se usa correctamente). Tenga en cuenta que syslog-transport-tls proporciona seguridad hop-by-hop. No proporciona seguridad de extremo a extremo y no autentica el mensaje en sí (solo el último remitente).

Entonces, la pregunta de seguimiento es: ¿cuál es una configuración buena / práctica (en cualquier herramienta de registro común de su elección: rsyslog, syslog-ng, logstash, etc.) que proporciona cierta cantidad de autenticidad?

O ... si nadie autentica los datos de registro, ¿por qué no ?

-

(Aparte: al analizar / comparar, puede ser útil usar algunos diagramas o terminología de RFC 5424: Sección 4.1: Escenarios de implementación de ejemplo, por ejemplo, "originador" vs "retransmisión" vs "recolector")

— Tim Otten
fuente

¿Qué parte estás tratando de asegurar? ¿El agregado de registro que recibe datos de un host correcto o los datos en sí?

— Shane Andrie

Recibiendo del host correcto. Si Alice y Bob son ambos originadores de registros, y Trent es el recolector de registros, Alice debería poder dar registros de Trent con "hostname = alice" pero no "hostname = bob". Pero creo que la configuración predeterminada está diseñada para suponer que Alice podría ser un relé de registro, por lo que le permitirían enviar cualquier cosa.

— Tim Otten

1

Esta es una gran pregunta.

Utilizo logstash para lograr algo como lo que estás proponiendo. Usando logstash (o logstash-forwarder) para enviar registros a su sistema de recolección central, agregue una configuración de logstash para agregar un campo clave al mensaje, siendo su valor una cadena larga y aleatoria que es exclusiva de cada servidor.

Luego, en el lado receptor, puede agregar una regla correspondiente para descartar (o alertar) cualquier mensaje en el que la clave de un host específico no coincida con lo que espera para su nombre de host.

Esto no es a prueba de balas, pero es un paso sólido en la dirección correcta.

— EEAA
fuente

3

Lo correcto para esto es TLS con certificados de cliente de máquina.

rsyslog está haciendo esto desde aproximadamente 2008, y tiene excelentes instrucciones: http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

El proceso es extremadamente simple, ya que estas cosas van:

Configurar una CA
Emitir certificados a todos sus equipos de los que desea registros
Configure rsyslog para usar esa autenticación

Entonces, sus computadoras no pueden hacerse pasar entre sí y nadie puede iniciar sesión en su servidor de registro sin uno de sus certificados.

Veo que ya lo encontraste, pero todavía estás preocupado por su advertencia. No me preocuparía demasiado por eso. La inyección de registros es ciertamente una cosa, pero son muchas cosas, incluida la inyección a través de la aplicación y la inyección en el proceso de registro. Rsyslog autenticado no lo protegerá si alguien tiene un ataque de inyección de registro en el software de su aplicación, pero nada lo hará ni podrá hacerlo; solo arreglar la aplicación puede ayudarlo. Esto solo lo protegerá contra los registros falsos.

Las otras advertencias se pueden mitigar fácilmente al no usar relés, lo que de todos modos hay muy pocas razones para hacerlo. Si no tiene relés y usa la opción x509 / name para el controlador de conexión gtls en el servidor rsyslog, no debería tener problemas.

Consulte también el documento de configuración de gtls: http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html

— Falcon Momot
fuente