Select Page

Login Logs? Gern, aber bitte anonymisiert

by | Mar 13, 2015 | Elastic Stack

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
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

More posts on the topic Elastic Stack

Kibana Sicherheits-Updates: CVSS:Critical

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die "Reporting" Funktion deaktiviert habt. Der...