This entry is part 1 of 11 in the series logstash

Wir werden bei unseren Terminen zu Logstash und ELK Stack, zum Glück, oft nach Möglichkeiten zur Anonymsierung von Informationen gefragt. Logstash bietet da schon out of the box Filter an, um sensible Daten zu schützen.

Die folgende Beispielkonfiguration zeigt gleich zwei Wege, automatisiert zu anonymisieren.

input {
  exec {
    command => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten"
    interval => 30
  }
}
filter {
  kv {
    field_split => ","
    trim => "\n"
  }
  noop {
    remove_field => [ "password", "message" ]
  }
  anonymize {
    fields => "user"
    algorithm => "SHA1"
    key => "TheSnake"
  }
  noop {
    add_field => { "message" => "message was anonymized" }
  }
}
output {
  stdout {
    codec => "rubydebug"
  }
}

Dieses Beispiel lässt sich einfach in eine Textdatei kopieren und mit Logstash auf der Commandline ausführen, ohne, dass Elasticsearch oder Kibana bemüht werden müssten.

/opt/logstash/bin/logstash -f ./blogartikel.conf

Dabei sendet diese Konfiguration alle 30 Sekunden eine Beispielnachricht, die zerlegt und anonymisiert wird und gibt sie auf stdout aus.

Der kv Filter zerlegt die Nachricht in einzelne Key-Value Paare und macht daraus Felder mit dem Namen des Key und dem Wert des Value. Liesse man die weiteren Filter weg, sähe die Nachricht wie folgt aus:

{
       "message" => "host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten\n",
      "@version" => "1",
    "@timestamp" => "2015-03-12T00:05:25.628Z",
          "host" => "pc01.rbpd.le",
       "command" => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten",
          "user" => "SamuelReynolds",
      "password" => "6oben1unten"
}

Da das Passwort Feld eigentlich gar nicht in nachfolgenden Tools wie Elasticsearch auftauchen soll, wird es durch die remove_field Option des ersten noop Filters komplett entfernt. Ebenso wie das message Feld, das die zu anonymisierenden Daten ja ebenfalls enthält.

Der anonymize Filter erstellt aus dem Usernamen einen Hash, damit auch dieser nicht im Klartext vorliegt. Das hat den Vorteil, dass man weitere Abfragen und Kibana Dashboards verwenden kann, um festzustellen, ob z.B. ein bestimmter User versucht, sich auf verschiedenen Hosts mit falschem Passwort anzumelden oder an einem Host viele gleiche Logmeldungen produziert. Aber man sieht in Kibana eben nicht den Usernamen des Users. Sollte es nötig sein, kann mit dieser Information ein Admin, der Zugriff auf die Originallogs am sendenden Host hat, nachsehen, wie der User tatsächlich heisst, aber nicht jeder, der Zugriff auf Kibana hat, hat auch gleich alle echten Usernamen.logstash_logo

Achtung – SHA1 gilt nicht mehr als sicher und sollte nicht mehr für sensible Daten verwendet werden. Hier wird er verwendet, um den resultierenden Hash kurz zu halten und den Blogartikel nicht mit einem zu langen Hash zu füllen. Sollte es sich um Daten handeln, die “nicht einfach zugänglich” gemacht werden sollen, aber nicht sicherheitsrelevant sind, kann durchaus auch SHA1 in Betracht gezogen werden, um nicht übermässig lange Lognachrichten zu produzieren und keine Ressourcen zur Berechnung unnötig langer Hashes zu verbrauchen. Diese Einschätzung muss aber von Fall zu Fall getroffen werden.

Der nachfolgende noop Filter fügt ein neues message Feld hinzu, um überhaupt ein solches Feld zu haben, da normalerweise jedes Event ein solches Feld hat und Filter und Dashboards sich üblicherweise darauf verlassen.

Mit den gezeigten Filtern sieht die Nachricht folgendermassen aus:

{
      "@version" => "1",
    "@timestamp" => "2015-03-11T23:22:35.293Z",
          "host" => "pc01.rbpd.le",
       "command" => "echo host=pc01.rbpd.le,user=SamuelReynolds,password=6oben1unten",
          "user" => "ee8a9e70ee30f82b7d169b4e259b052d3e6ef2db",
       "message" => "message was anonymized"
}

Da echte Daten nicht einfach vom exec Filter erzeugt werden, wird das command Feld für das Beispiel ignoriert, das hier ja auch wieder die sensiblen Daten enthält.

Um Anonymisierung bei Bedarf umkehrbar zu machen, kann der crypt Filter verwendet werden. Damit sind damit bearbeitete Felder für Kibana noch immer unlesbar, aber bei Bedarf und nach Freigabe können Admins mit Zugang zur Logstash Konfiguration die Felder wieder entschlüsseln.

P.S. Uns ist nicht entgangen, dass Kibana 4 released wurde. Da aber aktuell noch keine Pakete zur Verfügung stehen werden wir mit dem nächsten Artikel dazu noch etwas warten.

Thomas Widhalm

Autor: Thomas Widhalm

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält Schulungen und erstellt Schulungsunterlagen zu diesem faszinierenden Tool.