Wir haben (natürlich mit Bedacht auf die Sicherheit) eine Menge Event Records von Sparse Generators gesammelt, diese zentral konsolidiert und in eine täglichen Rhythmus archiviert. Wie können wir also den Inhalt dieser Archive schützen?

Log Files schützen

Attribute der Dateien helfen. BSDs haben die Fähigkeit, Dateien und Ordnern zusätzliche Attribute zuzuordnen (Linux hat ähnliche Features, aber wer benutzt schon Linux in einer sicheren Umgebung? Okay, okay, ganz locker. Das war ein Witz… aber bitte benutzt doch OpenBSD). Diese zusätzlichen Attribute unterscheiden sich von der Standard Unix Permission Scheme indem, dass sie die Attribute generell für alle User eines Systems zuweisen und viel tiefer im System greifen als File-Permissions oder ACLs.

ls –lo kann genutzt werden um die Attribute anzusehen und chflags um sie zu ändern.

Ein nützliches Attribut zum Schutz der Logfiles is zudem append-only. Wenn dieses Attribut gesetzt ist, kann die Datei nicht gelöscht werden und Writes sind nur am Ende der Datei möglich.

# chflags sappnd filename

Aber das ist nur die Hälfte des Ganzen: root (oder etwas Ähnliches) können die Attribute immer noch entfernen, verändern und die Attribute wieder setzen, ohne dass irgendjemand Wind davon bekommt (abgesehen von der jüngsten Änderung, welche die Attribute wieder herstellt). Um das zu verhindern, muss die Fähigkeit, append-only zu enfernen, entfernt werden.

BSDs machen dies mittels securelevels. Securelevels ist eine Kernel-Variable, die gesetzt werden kann damit die Ausführung einer bestimmten Funktion verhindert. Setze securelevel auf 1. Grundsätzlich: Wenn securelevels über 0 gehoben werden, können sie nicht mehr gesenkt werden. OpenBSD wird securelevel automatisch auf 1 setzen, wenn es sich im Multiuser-Modus befindet. In FreeBSD sind securelevels per default auf -1.

Um dies zu ändern muss folgende Zeile zu /etc/sysctl.conf hinzugefügt werden:

01 kern.securelevel=1

Aber Achtung: Indem append-only gesetzt wird, warden Log Rotation Scripts sehr wahrscheinlich Fehler ausgeben. Aber, dennoch, append-only ist ein wertvolles Attribut in jedem Audit Trail.

Integrität wahren

Generell, wir wollen unsere Logfiles vor Veränderung, Zerstörung oder Fälschung schützen. Dies ist als Integritätsverifiaktion, Dateninkonvertabilität und Gerichtstaugliche Beweisdatensicherung oder sogar Signed und Sequenced bekannt.

Was können wir sonst noch tun?

WORMs: Line Printer und WORM Disk sind selbsterklärend. In einigen Fällen sind sie die beste Lösung. Netapp Snaplock ist eine gute Businesslösung. Sandisk Wrom SD Card ist – oder war – eine kleinere aber finanzierbarere Lösung, um Informationen sicher abzuspeichern. Aber: 1GB ist nicht wirklich brauchbar, um Logdaten zu sichern, aber die Hashes. Und diese sind genug, um eine Logfile zu verifizieren.

Remote Copy: Dupliziert den Log Stream und speichert die Kopien auf einem separaten Log Server. Dieser zweite, zusätzlich gesicherte Server kann für die Verifikation der Logs genutzt werden.

Hash Chaining: Nutzt kryptografische Methoden um die Integrität der Logs nach der ersten Speicherung zu schützen. Die Grundidee hierbei ist, das Hash der Nachricht N ins N+1 einzuspeisen. Dies stellt sicher, dass ein Angreifer das Log nich manipulieren kann ohne dass er entdeckt wird. Aber: Der Angreifer kann immer noch alle Einträge in der Chain ersetzen oder die jüngste Nachricht in der Kette manipulieren. Ein Problem dieser Methode ist aber die Verifikation: Wenn die Integrität der Nachricht X verifiziert werden muss, dann muss die Integrität aller vorherigen Nachrichten (die erste mit dem geheimen Hash) geprüft werden. Eine Variante, um dies zu beschleunigen, ist die Nutzung des Merkle-Trees.

Fazit

Wieso nehmen wir die Sicherheit unserer Log Files so Ernst? Wenn unseren Log Files nicht trauen können oder sie nicht zur Beweislage beiträglich sind, dann sind wir blind. Logs sicher und verifizierbar zu halten ist einer der komplexesten Aspekte des Log-Managements und der Lösungen für selbiges. Viele dieser Lösungen existieren, die das Problem beheben, aber sie müssen sehr vorsichtig implementiert werden. Und der Trend in Richtung Cloud Computing verheisst auch nichts Gutes!

Literatur

• Cryptographic Support for Secure Logs on Untrusted Machines
• Secure audit logging with tamper-resistant hardware
• Guide to Computer Security Log Management
• rsyslog’s first signature provider: why Guardtime?
• Forensics syslog-ng Use Case

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

• http://blog.gerhards.net/2013/05/rsyslogs-first-signature-provider-why.html
• http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.101.4911
• http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
• http://www.schneier.com/paper-secure-logs.pdf