Wie konfiguriere ich einen Protokollaggregator zur Authentifizierung von Daten?

Hintergrund : Die Remote-Protokollaggregation wird als ein Weg zur Verbesserung der Sicherheit angesehen. Im Allgemeinen wird damit das Risiko behoben, dass ein Angreifer, der ein System kompromittiert, Protokolle bearbeiten oder löschen kann, um die forensische Analyse zu vereiteln. Ich habe Sicherheitsoptionen in gängigen Protokolltools untersucht.

Aber etwas fühlt sich falsch an. Ich kann nicht sehen, wie einer der gängigen Remote-Logger (z. B. rsyslog, syslog-ng, logstash) konfiguriert wird, um zu authentifizieren, dass eine eingehende Nachricht wirklich vom angeblichen Host stammt. Ohne irgendeine Art von Richtlinienbeschränkung könnte ein Protokollurheber Nachrichten im Namen eines anderen Protokollherstellers fälschen.

Der Autor von rsyslog scheint vor der Authentifizierung von Protokolldaten zu warnen :

Ein letztes Wort zur Vorsicht: transport-tls schützt die Verbindung zwischen Sender und Empfänger. Es schützt nicht unbedingt vor Angriffen, die in der Nachricht selbst vorhanden sind. Insbesondere in einer Relay-Umgebung stammt die Nachricht möglicherweise von einem schädlichen System, in das ungültige Hostnamen und / oder andere Inhalte eingefügt wurden. Wenn für solche Dinge keine Bereitstellung vorhanden ist, werden diese Datensätze möglicherweise im Repository des Empfängers angezeigt. -transport-tls schützt nicht davor (aber es kann helfen, richtig verwendet). Beachten Sie, dass syslog-transport-tls Hop-by-Hop-Sicherheit bietet. Es bietet keine End-to-End-Sicherheit und authentifiziert die Nachricht selbst nicht (nur den letzten Absender).

Die folgende Frage lautet also: Was ist eine gute / praktische Konfiguration (in einem gängigen Protokolltool Ihrer Wahl - rsyslog, syslog-ng, logstash usw.), die ein gewisses Maß an Authentizität bietet?

Oder ... wenn niemand Protokolldaten authentifiziert, warum dann nicht ?

- -

(Nebenbei: Beim Erörtern / Vergleichen kann es hilfreich sein, einige Diagramme oder Begriffe aus RFC 5424 zu verwenden: Abschnitt 4.1: Beispiel für Bereitstellungsszenarien - z. B. "Absender" vs "Relais" vs "Kollektor")

Das ist eine gute Frage.

Ich benutze Logstash, um so etwas wie das zu erreichen, was Sie vorschlagen. Fügen Sie mithilfe von logstash (oder logstash-forwarder) zum Versenden von Protokollen an Ihr zentrales Erfassungssystem eine logstash-Konfiguration hinzu, um der Nachricht ein Schlüsselfeld hinzuzufügen, dessen Wert eine lange, zufällige Zeichenfolge ist, die für jeden Server eindeutig ist.

Auf der Empfangsseite können Sie dann eine entsprechende Regel hinzufügen, um Nachrichten zu verwerfen (oder zu benachrichtigen), bei denen der Schlüssel eines bestimmten Hosts nicht mit dem übereinstimmt, was Sie für seinen Hostnamen erwarten.

Dies ist nicht kugelsicher, aber ein solider Schritt in die richtige Richtung.

Die richtige Verwendung hierfür ist TLS mit Maschinenclientzertifikaten.

rsyslog tut dies seit ungefähr 2008 und hat großartige Anweisungen: http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

Der Prozess ist extrem einfach, da diese Dinge gehen:

1. Richten Sie eine Zertifizierungsstelle ein
2. Stellen Sie Zertifikate für alle Computer aus, von denen Sie Protokolle erstellen möchten
3. Konfigurieren Sie rsyslog für die Verwendung dieser Authentifizierung

Dann können sich Ihre Computer nicht gegenseitig ausgeben und niemand kann sich ohne eines Ihrer Zertifikate bei Ihrem Protokollserver anmelden.

Ich sehe, dass Sie das bereits gefunden haben, aber Sie sind immer noch besorgt über ihre Einschränkung. Darüber würde ich mir keine Sorgen machen. Die Protokollinjektion ist sicherlich eine Sache, aber es gibt viele Dinge, einschließlich der Injektion durch die Anwendung und der Injektion in den Protokollierungsprozess. Authentifiziertes rsyslog schützt Sie nicht, wenn jemand einen Protokollinjektionsangriff in Ihrer Anwendungssoftware hat, aber nichts wird oder kann; Nur das Reparieren der Anwendung kann dabei helfen. Dies schützt Sie nur vor gefälschten Protokollen.

Die anderen Vorbehalte können leicht gemildert werden, indem keine Relais verwendet werden, was ohnehin wenig Grund gibt. Wenn Sie keine Relais haben und die Option x509 / name für den gtls-Verbindungstreiber auf dem rsyslog-Server verwenden, sollten Sie keine Probleme haben.

Siehe auch das gtls-Konfigurationsdokument: http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html