8 votes

Comment configurer un agrégateur de journaux pour authentifier les données ?

Contexte : L'agrégation des journaux à distance est considérée comme un moyen d'améliorer la sécurité. En général, cela répond au risque qu'un attaquant qui compromet un système puisse modifier ou supprimer les journaux afin de faire échouer l'analyse médico-légale. J'ai fait des recherches sur les options de sécurité des outils de journalisation courants.

Mais quelque chose ne va pas. Je ne vois pas comment configurer l'un des enregistreurs distants courants (par exemple rsyslog, syslog-ng, logstash) pour authentifier qu'un message entrant provient vraiment de l'hôte supposé. Sans une sorte de contrainte de politique, un log-originateur pourrait falsifier des messages au nom d'un autre log-originateur.

L'auteur de rsyslog semble pour avertir de l'authentification des données du journal :

Un dernier mot d'avertissement : transport-tls protège la connexion entre l'expéditeur et le destinataire. Il ne protège pas nécessairement l contre les attaques qui sont présentes dans le message lui-même. En particulier dans dans un environnement de relais, le message peut provenir d'un système malveillant système malveillant, qui a placé des noms d'hôtes invalides et/ou d'autres contenus dans le message. S'il n'y a pas de provisionnement contre de telles choses, ces enregistrements peuvent apparaître dans le référentiel des récepteurs. Le protocole -transport-tls ne protège pas contre cela (mais il peut aider, s'il est utilisé correctement). Gardez à l'esprit que gardez à l'esprit que syslog-transport-tls fournit une sécurité hop-by-hop. Il ne sécurité de bout en bout et n'authentifie pas le message lui-même ( message lui-même (seulement le dernier expéditeur).

La question suivante est donc : quelle est une bonne configuration pratique (dans l'outil de journalisation de votre choix -- rsyslog, syslog-ng, logstash, etc) qui fournit un certain degré d'authenticité ?

Ou... si personne n'authentifie les données du journal, alors pourquoi pas ?

--

(A propos : lors de la discussion/comparaison, il peut être utile d'utiliser certains diagrammes ou la terminologie des documents suivants RFC 5424 : Section 4.1 : Exemples de scénarios de déploiement -- (par exemple, "expéditeur", "relais" ou "collecteur").

0 votes

Quelle partie essayez-vous de sécuriser ? L'agrégat du journal recevant les données d'un hôte correct, ou les données elles-mêmes ?

0 votes

Réception de l'hôte correct. Si Alice et Bob sont tous deux à l'origine des journaux, et que Trent est le collecteur de journaux, Alice devrait être capable de donner à Trent des journaux avec "hostname=alice" mais pas "hostname=bob". Mais je pensez à la configuration par défaut est conçue pour supposer qu'Alice pourrait être un relais de log, donc ils lui permettraient de soumettre n'importe quoi.

3voto

Falcon Momot Points 24815

La bonne chose à utiliser pour cela est TLS avec des certificats de client de machine.

rsyslog fait cela depuis 2008 environ, et a d'excellentes instructions : http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Le processus est extrêmement simple, pour ce genre de choses :

  1. Configurer une AC
  2. Délivrez des certificats à tous les ordinateurs dont vous voulez obtenir les journaux.
  3. Configurer rsyslog pour utiliser cette authentification

Ainsi, vos ordinateurs ne peuvent pas se faire passer pour d'autres et personne ne peut se connecter à votre serveur de journaux sans l'un de vos certificats.

Je vois que vous l'avez déjà trouvé, mais vous êtes toujours préoccupé par leur mise en garde. Je ne m'inquiéterais pas trop à ce sujet. L'injection de journaux est certainement une chose, mais il s'agit de plusieurs choses, y compris l'injection à travers l'application et l'injection dans le processus de journalisation. Le rsyslog authentifié ne vous protégera pas si quelqu'un a une attaque par injection de journal dans votre logiciel d'application, mais rien ne le fera ou ne le peut ; seule la correction de l'application peut y remédier. Cela vous protégera uniquement contre les journaux falsifiés.

Les autres mises en garde peuvent être facilement atténuées en n'utilisant pas de relais, ce qui n'a pas vraiment de raison d'être de toute façon. Si vous n'avez pas de relais et que vous utilisez l'option x509/name pour le pilote de connexion gtls dans le serveur rsyslog, vous ne devriez pas avoir de problème.

Voir aussi la doc de configuration gtls : http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html

1voto

Samat Jain Points 165

C'est une excellente question.

J'utilise logstash pour accomplir quelque chose comme ce que vous proposez. En utilisant logstash (ou logstash-forwarder) pour envoyer les journaux à votre système de collecte central, ajoutez une configuration logstash pour ajouter un champ clé au message, dont la valeur est une longue chaîne aléatoire unique à chaque serveur.

Ensuite, du côté de la réception, vous pouvez ajouter une règle correspondante pour rejeter (ou signaler) tout message où la clé d'un hôte spécifique ne correspond pas à ce que vous attendez pour son nom d'hôte.

Ce n'est pas infaillible, mais c'est un pas solide dans la bonne direction.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X