LOGisch – was man beim Loggen beachten sollte

LOG-INFR A STRUK TUR 15
LOGisch – was man beim
Loggen beachten sollte
Für den Aufbau einer Log-Infrastruktur steht eine kaum überschaubare
Auswahl an Produkten zur Verfügung. Sie alle können aber nur die in Logs
enthaltenen Daten auswerten und darstellen. Grund genug, einen Schritt
zurückzugehen und sich Gedanken zu machen, was geloggt werden soll.
Von Markus Pfister
E
in regnerischer Sonntag. Sie
wollen Sonne sehen und schauen Urlaubsfotos an, starten den
Rechner und suchen die Fotos
von den Ferien in Hawaii. Die
Bilder werden aussortiert und besonders
gelungene kopiert man in eine Präsentation. Dank der Zeitstempel in den Metadaten der Fotos lässt man die Ferien chronologisch Revue passieren und verschickt
ein besonders schönes Bild einer bekannten Person. Dann wird noch eine Sicherungskopie erstellt.
Das Beispiel mit den Ferienfotos eignet sich, um die Eigenschaften einer modernen Log-Infrastruktur aufzuzeigen
(siehe Tabelle 1).
Warum loggen?
Diverse Sicherheitsstandards (z.B. BSI,
ISO 27001, PCI-DSS) oder von Sicherheitsgremien wie NIST (National Insti­
tute of Standards and Technology) und
OWASP (Open Web Application Security
Project) herausgegebene Empfehlungen
fordern eine funktionierende Log-Infrastruktur. Steht die in Logs enthaltene Information nicht zur Verfügung, befindet
sich die IT- und Security-Operation im
«Blindflug». Die in Logs enthaltene Information wird verwendet für:
−− Analyse von Problemen und
Fehlerbehebung
−− Beweismittel bei kriminellen Handlungen (Betrug, Hacking, Missbrauch)
−− Erfüllung gesetzlicher Anforderungen
−− Performance Skalierung (baselining)
−− Auslösen von möglichst zeitnahen
Aktionen aufgrund der aus den Logs
gewonnenen Erkenntnisse, z.B. Bereitstellen weiterer Instanzen wenn eine
Anzahl Anfragen überschritten wurde
Eigenschaft
Beispiel
Log-Infrastruktur
Collection
Sie haben die Fotos von der Kamera
auf den Computer geladen.
Einsammeln von Log-Informationen
Aggregation
Sie sortieren doppelte Fotos aus.
Gleichartige Einträge werden
zusammengefasst.
Correlation
Durch die zeitliche Sortierung der Fotos
können Sie den Ferienablauf
nachvollziehen.
Die Log-Information stammt von unterschiedlichen Systemen und muss in
einen Zusammenhang gebracht werden.
Alerting
Sie schicken schöne Fotos einer
­bekannten Person.
Bei gewissen Ereignissen oder dem
Erreichen eines Schwellwerts wird
z. B. die IT-Operation benachrichtigt.
Dashboards
Sie erstellen mit den aussagekräftigsten
Fotos eine Präsentation.
Die Log-Information wird grafisch
aufbereitet, z. B. auf einer Zeitachse mit
Drill-Down-Möglichkeit.
Compliance
Sie löschen Fotos, die nicht Ihren
­Qualitätsstandards entsprechen.
Festgestellte Ereignisse werden gegen
die Anforderungen aus einem Standard
geprüft.
Retention
Sie sichern die Urlaubsfotos.
Die Logs werden den jeweiligen Anfor­
derungen entsprechend archiviert oder
nach einer bestimmten Zeit gelöscht.
Analysis
Sie möchten wissen, an wie vielen
Tagen in den Ferien schlechtes Wetter
war und schauen die Fotos unter diesem
Aspekt an.
Bei besonderen Ereignissen (Betrug,
Missbrauch, Hacking) werden spezifische
Analysen zur Aufklärung und Beweis­
sicherung durchgeführt.
Tabelle 1: Komponenten einer modernen Log-Infrastruktur (z.B. Security und
Incident Management, SIEM).
Bezug zur IT-Sicherheit
Der Nachvollzug von Angriffen oder
kriminellen Handlungen mittels IT-­
­
Systemen ist oft nur anhand von LogAuswertungen möglich. Die EchtzeitÜberwachung analysiert Log-Informa­
tionen auf bekannte Angriffsmuster und
hat zum Ziel, den Angriff so früh und zuverlässig wie möglich zu erkennen. Nachstehend eine unvollständige Liste, wo
überall Loginformationen anfallen. Diese
wird entweder vor Ort in Files oder Datenbanken gespeichert oder über das
Netzwerk an einen Logserver geschickt.
−− Sicherheitskomponenten (Firewalls,
Web Proxies, Remote Access, Intru­
sion Detection (IDS), Identity and
Access Management (IAM))
−− Betriebssysteme
−− Middleware (DB, Message Brokers,
Queues)
−− Infrastrukturdienste (Active Directory, Backup)
−− Anwendungen
«Security Information and Event
Management»-Systeme (SIEM) fokussieren auf sicherheitsspezifische Problemstellungen. Die folgenden Feststellungen haben für alle Arten von LogInfrastrukturen Gültigkeit.
Was loggen?
Logs von Anwendungen und Systeme produzieren riesige Datenmengen. Dies kann
die Performanz beeinflussen, da für das
Schreiben der Informationen langsame
­Input-/Output-Operationen notwendig
sind. Grund genug, nur bedeutsame Informationen zu loggen. Weniger Log-Information macht sich auch bei der Auswertung
durch schnellere Ergebnisse bemerkbar.
5/15
16 LOG-INFR A STRUK TUR
17
Aufrufkette für Webshop
Firewall
Web Entry Server
Log
Anwendung A
Anwendung A
Webshop
Log
Log
Log
DB
Log
Firewall
Web Entry Server
Log
Webshop
Log
Log
DB
Log
Loggen
Passworte (Credentials)
von Benutzern
Nein
auch keine Passwort-Hashes
Kreditkartennummern
Nein
Die Kreditkartennummer kann durch ein «Token» ersetzt
werden, das als Stellvertreter für die Kreditkartennummer
dient. Das Token wird bei Bedarf von autorisierten Personen
benutzt, um die zugehörige Kreditkartennummer zu ermitteln.
Kontonummern
Nein
Auch hier kann bei Bedarf die «Token»-Technik verwendet
werden.
Cookies
Nein
Cookies enthalten sensitive Informationen, die für unerlaubten
Zugriff auf eine Anwendung verwendet werden können.
Personendaten
Nein
Diese Angaben sind mit einer UserID verknüpft, die ähnlich
dem erwähnten Token für Kreditkarten verwendet werden
kann, um nähere Angaben über den Benutzer zu erhalten.
UserID
Ja
Request-URLs
Ja, mit
Vorsicht
Log
Zeiterfassung
Collection
Aggregation
Correlation
Alerting
Dashboard
Compliance
Retention
Analysis
DB
Log
Log
Darstellung 1: Betroffene Komponenten bei einer Anfrage
an den Webshop.
Log
Infrastruktur
Darstellung 2: Komponenten einer Log-Infrastruktur.
Firewall
Was
Web Entry Server
newID=ABC
Log
Add HTTP Header
UID: ABC
Webshop
Log
…,ABC,…
Log
…,ABC,…
SQL Insert UID
,ABC,
DB
Log
…,ABC,…
Darstellung 3: Eingefügte Unique Identifiers (UID) helfen,
Zusammenhänge zu erkennen.
−− Information über die normale Funktionsweise kann kompakt sein, soll aber
die Art und Anzahl der aufgerufenen
Applikationsfunktionen sichtbar
machen.
−− Information über Fehlersituationen
und besondere Vorkommnisse (z.B.
hohe Ressourcennutzung) sollen
ausführlich sein, um einen Einblick
in das vorliegende Problem zu
ermöglichen.
−− Jeder Log-Eintrag soll Auskunft
geben über:
Wer: User/System/Anwendung
Was: Verwendete Funktion, Request
URL
Wann: Timestamp
Wo: Servername, IP, Port, Protokoll
Wie: Detailbeschreibung zum Fehler
Warum: Fehler-Level
Ein Beispiel
In einer «N-Tier»-Architektur werden
an den Webshop gerichtete Anfragen vom
Firewall an den Web Entry Server und von
diesem an den Webshop geleitet. Der
Webshop speichert Daten in einer Datenbank (siehe Darstellung 1).
Um das Beispiel einfach zu halten,
loggen alle Komponenten in ein File. Das
Loggen könnte auch über ein Netzprotokoll an eine zentrale Log-Komponente
erfolgen. Weil der Webshop für optimale
Lastverteilung auf mehreren Instanzen
läuft, kann der genaue Weg durch die Verarbeitungskette nicht im Voraus bestimmt werden, da jede der drei Web­
5/15
shop-Instanzen die Anfrage beantworten
könnte. In komplexen IT-Architekturen
ist dies der Normalfall. Die Pfeile in
Darstellung 1 zeigen mögliche Verar­
­
beitungswege, die eine Anfrage an den
Webshop nehmen kann. Alle für den
Web­
shop-Betrieb zuständigen Systeme
sind in der Aufrufkette «Webshop»
zusammengefasst.
Wenn ein Benutzer auf den Webshop
zugreift, fallen Log-Informationen beim
Firewall, dem Web Entry Server, beim
Webshop und in der Datenbank an. Diese
Log-Informationen werden gesammelt
und die Daten so aufbereitet, dass Zusammenhänge erkannt werden können
(correlation). Dafür ist die Log-Infrastruktur zuständig (siehe Darstellung 2).
Nicht einfach alles loggen
Der Gesetzgeber (Datenschutzgesetz)
oder Industriestandards (Payment Card
Industry, PCI) schränken das Sammeln
(loggen) gewisser Daten ein. Aus diesem
Grunde müssen Log-Einträge auf Compliance mit dem regulatorischen Umfeld
geprüft werden (siehe Tabelle 2).
Log correlation ist die Verknüpfung
von in Logs enthaltener Information. Beispielsweise werden Timestamps verwendet, um auf verschiedenen Systemen protokollierte Ereignisse im Zusammenhang
auf einer Zeitachse darzustellen. Dies ist
nur möglich, wenn alle Logs auswertbare
Timestamps enthalten. Um die Angaben
in den verschiedenen Logs in der richtigen Reihenfolge zu filtern, greift man oft
auf diese Informationen zurück (siehe
Tabelle 3).
Hilfe für die Log correlation
Unique Identifiers (UID) sind Token, die
einmalig vorkommen und damit als Unterscheidungsmerkmal verwendet werden können. Wird eine UID möglichst am
Anfang der durch eine Anfrage ausgelösten Verarbeitungskette eingefügt und an
die nachfolgenden (downstream) Systeme
weitergegeben, lassen sich zusammen­
gehörige Log-Informationen anhand der
UID herausfiltern. Dazu muss die UID von
jedem System mit ins Log geschrieben
werden. Das Erstellen dieser UID wird
etwa von Apache Module «mod_unique_
id» unterstützt. Im Beispiel (siehe Darstellung 3) fügt der Web Entry Server die
UID ein und reicht sie in der Verarbeitungskette weiter. Die nachfolgenden
Systeme schreiben die UID ins Log.
End-To-End-Information
Die Zugehörigkeit eines Systems zu einer
Verarbeitungskette wird als «Topologie»
in der Log-Infrastruktur hinterlegt. Die
Verarbeitungsketten entsprechen Geschäftsfunktionen – hier der Kunden­
interaktion mit dem Webshop. Abfragen
eines Kunden können so pro Geschäftsfunktion aus Sicht Business (Funktion,
Aufrufpfade) wie auch unter Audit- und
Security-Aspekten analysiert werden.
Die Gruppierung von Systemen nach
Geschäftsfunktionen hat folgende Vor­
teile:
−− Im Störungsfall kann das Business
über die betroffenen Funktionen
informiert werden.
−− Die Einhaltung von Service Level
Agreements ist überprüfbar.
−− Tritt ein Fehler beim Webshop auf,
sind die in erster Linie zu untersu-
URLs können in den Query-Parametern sensitive Angaben
enthalten, die vor dem Loggen entfernt werden müssen.
Log-Erzeugung:
−− Was muss geloggt werden?
−− Was darf nicht geloggt werden?
−− Log-File-Format, inklusive Feld­
formate (z.B. Timestamps in UTC)
−− Definition von Fehlerstufen (Debug,
Info, Warnung, Fehler, fataler Fehler)
−− Definition der Meldungspriorität
(tief, mittel, hoch)
Log-Einsammlung:
−− Wie werden Log-Informationen
gesammelt (Protokolle, Häufigkeit)?
−− Verbleiben Logs als Kopie am
Entstehungsort?
Tabelle 2: Diese Daten sollten am besten gar nicht ins Log geschrieben werden.
chenden Systeme im Voraus definiert
(Firewall, Web Entry Server, Web
Shop, DB).
Was kann schiefgehen?
−− Die Timestamps spielen bei der Log
correlation eine Schlüsselrolle. Dies
bedingt, dass die Uhren auf den
Rechnern synchronisiert sind.
−− Loggen ist für ein System oder eine
Anwendung abgeschaltet (unabsichtlich oder absichtlich).
−− Logs werden nachträglich verän­dert. Damit verlieren sie die Beweis­kraft.
−− Logs werden in proprietären Formaten geschrieben und können nicht
gelesen werden.
−− Platz für die Logs ist aufgebraucht.
−− Logs werden nur bei Störungen, d.h.
reaktiv, analysiert. Damit vergibt ein
Unternehmen die Möglichkeit, proaktiv Störungen zu beheben, bevor
sich diese bei Kunden und Benutzern
bemerkbar machen.
Log Policies
Durch die Vorgabe von Richtlinien, wie
das Loggen in einem Unternehmen erfolgen soll, wird verhindert, dass Informationen fehlen bzw. vorhanden, aber nicht
auswertbar sind. In Umgebungen, in denen vom Regulator Logs vorgeschrieben
sind, ist die Log Policy ein zentraler Baustein. Dabei ist die Sensitivität der geloggten Daten bzw. der Systeme, die Logs
erzeugen, zu berücksichtigen (gering,
mittel, hoch). Eine konsistente Defini­
tion von Fehler-Levels erleichtert dem
IT-Betrieb die Klassifizierung von Fehlern und das Einrichten automatisierter
Behebungsmechanismen.
Feldart
Bemerkung
Timestamp
Werden Server in unterschiedlichen Zeitzonen betrieben, muss der Timestamp
die verwendete Zeitzone oder die Abweichung zur Coordinated Universal
Time (UTC) enthalten. Wird in ein Log in New York und Zürich der Timestamp
«31. Dez 2015 11 Uhr» ohne Zeitzoneninformation eingetragen, werden beide
Einträge als zur gleichen Zeit stattgefunden betrachtet.
Rechnernamen
IP-Adressen haben den Vorteil, dass sie wenig Platz im Log brauchen und der
DNS-Lookup entfällt. In grossen, an unterschiedlichen Standorten verteilten
Unternehmen, können die IP-Adressen interner Netzwerke gleich sein. Werden
dann Logs über das ganze Unternehmen korreliert, entstehen falsche Resultate.
In diesen Fällen ist der DNS-Name vorzuziehen.
Anwendungsname
Diese Angabe darf in keinem Log fehlen.
Anwendungs­
funktion
Oft ist von Interesse, was die Ursache (root cause) eines Problems war.
Die Angabe der Anwendungsfunktion hilft bei der Fehlersuche.
UserID
Notwendig, um Aktionen, die durch einen Benutzer ausgelöst wurden, zu
korrelieren.
SessionID
Ist im Kontext einer Anwendung hilfreich, um den Verlauf einer Sitzung
nachzuvollziehen.
Protokoll
Port
Werden oft als zusätzliches Filterkriterium verwendet, um die zu untersuchende
Datenmenge im Voraus einzuschränken (z.B. interessieren beim Webshop nur
http/https-Anfragen).
Log-Aufbewahrung:
−− Wie lange müssen Logs aufbewahrt
werden?
−− Wann müssen die Logs verschlüsselt
werden?
−− Wie werden Logs archiviert?
−− Wie wird sichergestellt, dass Logs
nicht nachträglich verändert werden?
Log-Auswertung:
−− Welche Bedürfnisse müssen durch die
Abfragen abgedeckt sein?
−− Wer hat Zugriff auf die Logs und die
Log-Infrastruktur?
−− Häufigkeit der Log-Auswertung
Log-Vernichtung:
−− Wie und wann werden nicht benötigte Logs vernichtet?
Event-Behandlung
Die Echtzeitüberwachung (Monitoring)
von Logs erlaubt die zeitnahe Abarbeitung mittels Log-Analyse entdeckter
Ereignisse, falls diese einer Bearbei­
­
tung bedürfen. Dazu müssen die Verant­
wortlichkeiten definiert und die betrieblichen Voraussetzungen geschaffen werden. Dann profitiert das Business durch
eine höhere Verfügbarkeit der Anwendungen und einen höheren Grad an Sicherheit. n
MARKUS PFISTER
Senior Security Consultant, In&Out AG IT
Consulting & Engineering, Zürich
Tabelle 3: Diese Daten im Log helfen, Ereignisse zu korrelieren.
5/15