Bundesamt für Sicherheit in der Informationstechnik

M 4.47 Protokollierung der Sicherheitsgateway-Aktivitäten

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Es muss festgelegt werden, welche Ereignisse protokolliert werden und wer die Protokolle auswertet. Die Protokollierung muss den jeweils geltenden rechtlichen Bestimmungen entsprechen. Für Protokolldaten ist in Deutschland insbesondere die Zweckbindung nach § 14 des BDSG zu beachten.

Für den Einsatz der Protokollierung am Sicherheitsgateway sollten die folgenden Punkte beachtet werden:

  • Es muss möglich sein, die Protokolldaten (beispielsweise IP-Adressen) eindeutig einzelnen Rechnern (oder Personen) zuzuordnen. Dabei müssen jedoch die jeweils zutreffenden gesetzlichen Regelungen zum Datenschutz beachtet werden.
  • Die Protokolldaten sollten nicht nur auf den einzelnen Komponenten des Sicherheitsgateways, sondern zusätzlich auch auf einem zentralen Protokollierungsserver (Loghost) gespeichert werden, so dass die Gefahr des Datenverlustes durch einen Hacker-Angriff oder durch einen Systemausfall verringert wird.
  • Die Übertragung der Protokollinformationen von den Komponenten zum Loghost muss über eine gesicherte Verbindung erfolgen, damit die Protokollinformationen vor ihrer endgültigen Speicherung nicht verändert werden können.
  • Wenn bei der Übertragung zum Loghost nicht-vertrauenswürdige Netze passiert werden müssen, so müssen die Daten verschlüsselt werden.
  • Die Größe des freien Speicherplatzes auf dem verwendeten Medium sollte regelmäßig kontrolliert werden.
  • Bei einem Ausfall der Protokollierung (z. B. aufgrund fehlenden Speicherplatzes auf der Festplatte) sollten alle Funktionen, die Protokolldaten generieren, gesperrt werden. Idealerweise sollte das Sicherheitsgateway jeglichen Verkehr blockieren und eine entsprechende Meldung an den Administrator weitergeben.
  • Die Protokolldaten sollten auf einem WORM-Medium ("Write Once, Read Many") gespeichert werden.
  • Art und Umfang der Protokollierung sollten sich an der Sensibilität der zu verarbeitenden Daten sowie am Verwendungszweck orientieren.
  • Spezielle, einstellbare Ereignisse, wie z. B. wiederholte fehlerhafte Passworteingaben für eine Benutzer-Kennung oder unzulässige Verbindungsversuche, müssen bei der Protokollierung hervorgehoben werden und sollten zu einer unverzüglichen Warnung des Firewall-Administrators führen.
  • Die einzelnen Komponenten sollten eine Zeitsynchronisation durchführen, um eine Korrelation der Daten zu ermöglichen. Siehe dazu auch M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation .

Bei kleinen Netzen, in denen nur ein einfaches Sicherheitsgateway eingesetzt wird, kann gegebenenfalls auf einen zusätzlichen Loghost verzichtet werden.

Umfang der Protokollierung am Paketfilter

Die Protokollierung am Paketfilter sollte zumindest alle Pakete erfassen, die auf Grund einer Paketfilterregel abgewiesen werden.

Je nach Sicherheitsanforderungen sind eventuell zusätzliche Klassen von Paketen interessant:

  • "Ungewöhnliche" Pakete, beispielsweise mit einer fehlerhaften Kombination aus TCP-Flags oder Pakete mit fehlerhaften Header-Informationen.
    Solche Pakete sollten zwar ohnehin durch eine entsprechende Paketfilterregel abgewiesen und aus diesem Grund bereits von der Protokollierung erfasst werden, aber es wird trotzdem empfohlen, solche Pakete gesondert zu protokollieren, da sie beispielsweise Indizien für sogenannte "Stealth Scans" sein können. Außerdem kann eine Häufung fehlerhafter Pakete auf technische Probleme im Netz hindeuten.
  • Bei verbindungsorientierten (beispielsweise TCP-basierten) Protokollen kann es sinnvoll sein, auch akzeptierte Pakete zu protokollieren, die zu einem Verbindungsaufbau gehören (beispielsweise TCP-Pakete, die zum 3-Wege-Handshake gehören), sowie eventuell zusätzlich Pakete, die zum Abbau einer bestehenden Verbindung gehören.
  • Bei verbindungslosen Protokollen, über die keine großen Datenmengen übertragen werden (beispielsweise UDP-basierte Protokolle wie DNS ) kann es unter Umständen sinnvoll sein, alle Pakete zu protokollieren.

Welche zusätzlichen Klassen von Paketen protokolliert werden hängt in erster Linie vom Schutzbedarf des vertrauenswürdigen Netzes ab. Allerdings bringt die Protokollierung alleine keinen Sicherheitsgewinn, sondern die Informationen müssen auch nach entsprechenden Kriterien ausgewertet werden.

Von den Paketen, für die eine Protokollierung gewünscht wird, sollten mindestens die folgenden Informationen protokolliert werden:

  • Quell- und Ziel-IP-Adresse
  • Quell- und Zielport oder ICMP-Typ
  • Datum und Zeit
  • zutreffende Regel des Paketfilters

Wird zusätzlich ein ALG verwendet, so kann auf die Protokollierung der akzeptierten Pakete verzichtet werden, da der Proxy in diesem Fall meist ausreichende Verbindungsinformationen protokolliert.

Umfang der Protokollierung am Application-Level-Gateway

Auf dem ALG, der durch den äußeren Paketfilter vor der großen Masse unzulässiger Pakete geschützt wird, sollten für jeden (erfolgreichen oder versuchten) Verbindungsaufbau die folgenden Daten protokolliert werden:

  • Quell- und Ziel-IP-Adresse
  • Quell- und Zielport
  • Dienst
  • Datum und Zeit
  • Verbindungsdauer
  • eventuell Authentisierungsdaten oder ausschließlich Tatsache des Fehlschlagens einer Authentisierung

Es muss möglich sein, für bestimmte Benutzer die Protokollierung abzuschalten, damit nicht wegen einer zu großen Anzahl von Protokolleinträgen wichtige Informationen übersehen werden. Diese Auswahl kann z. B. anhand des Rechteprofils einzelner Benutzer getroffen werden.

Für die einzelnen Protokolle werden darüber hinaus die folgenden Einstellungen empfohlen:

DNS

  • Ablehnung von Anfragen
  • Zulassen von Anfragen
  • von anderen Rechnern initiierte ("ausgehende") Zonen-Transfers
  • vom ALG initiierte ("eingehende") Zonen-Transfers

Zonen-Transfers werden in der Regel vom Betreiber des DNS-Server verhindert, so dass auf diese Überprüfungen auch verzichtet werden kann.

FTP

  • Ziel-Adresse (URL)
  • Abgelehnte PORT-Befehle
  • Name der übertragenen Datei
  • Menge der übertragenen Daten
  • Statusnachricht

HTTP

  • Ziel-Adresse (URL)
  • Menge der übertragenen Daten
  • Verbindungsmethode (z. B. GET, POST, CONNECT)
  • Hinweis auf angewandte Filterkriterien
  • Statusnachricht

NNTP

  • Ziel-Adresse (URL)
  • Menge der übertragenen Daten
  • Statusnachricht

SMTP

  • E-Mail-Adresse des Absenders und des Empfängers der E-Mail
  • Menge der übertragenen Daten
  • Hinweis auf angewandte Filterkriterien
  • Statusnachricht über Erfolg oder Misserfolg der Weiterleitung

Bei folgenden Modulen braucht keine gesonderte Protokollierung erfolgen:

Modul Begründung für Wegfall der Protokollierung
HTTPS Wird "in Reihe" mit einem HTTP-Proxy geschaltet, der bereits protokolliert.
Wartungsmodul Relevante Protokolldaten fallen nicht an.
IDS Protokolldaten werden auf dem IDS gesondert geliefert. Diese sollten nicht zentral gespeichert werden, um eine Umgehung von Modulen des Sicherheitsgateways zu unterbinden.

Tabelle: Module ohne gesonderte Protokollierung

Die Protokollierung wird stark vereinfacht, wenn die Software die freie Konfigurierbarkeit der "logging facility" (d.h. eine Kennzeichnung der einzelnen Log-Einträge) ermöglicht. Dadurch ist es möglich, jedem Dienst eine eindeutige Kennung zuzuordnen, anhand derer der Loghost die Protokolldaten auf verschiedene Dateien verteilen kann.

Werden die Protokolldaten über das Netz zu einem zentralen Loghost geschickt, so muss darauf geachtet werden, dass die Log-Einträge verschiedener Rechner und Dienste so gekennzeichnet werden, dass sie eindeutig zugeordnet werden können. Zusätzlich ist es sinnvoll, wenn alle Dienste ihre Protokolldaten fortlaufend nummerieren. Dadurch kann der Verlust bzw. die Manipulation von Protokolldaten erkannt werden.

Auswertung der Protokolldaten

Die Auswertung von Protokolldaten kann mit speziellen Tools unterstützt werden ("logfile analyzer"). Diese stellen die Protokolldateien auf unterschiedliche Weise dar, wobei sich die meisten Tools regulärer Ausdrücke bedienen, um relevante Daten aus den Protokolldateien zu extrahieren. Obwohl Listen mit sinnvollen regulären Ausdrücken zum Zwecke der Protokolldatenauswertung existieren, sind im Einzelfall meist Anpassungen notwendig.

Beispiele für verschiedene Ausgaben der Protokolldateien sind:

  • Gruppierung und Markierung zusammengehörender Protokolldaten (z. B. LogSurfer)
  • Anzeige relevanter Protokolldaten, wobei irrelevante Daten mittels regulärer Ausdrücke ausgeblendet werden können. Auf diese Weise könnten beispielsweise diejenigen Protokolldaten ausgeblendet werden, die eine erfolgreiche Operation (z. B. GET bei HTTP) dokumentieren (z. B. checksyslog).
  • Anzeige von Angriffen. Die Analyse der Protokolldaten muss dabei in Echtzeit vorgenommen werden.
  • Statistische Analyse der Protokolldaten (z. B. wie oft trat welche Meldung auf).

Neben der reinen Darstellung relevanter Protokolldaten existieren Tools, die abhängig von einer erkannten Auffälligkeit Aktionen (z. B. Ausführen eines Befehls) ermöglichen.

Auffällige Protokolleinträge sind beispielsweise:

  • Gehäuft auftretende Anfragen an Ports, auf denen keine Dienste laufen
  • Nicht erfolgreiche Zugriffsversuche auf Komponenten des Sicherheitsgateways
  • Aus dem nicht-vertrauenswürdigen Netz eintreffende Pakete mit IP-Adressen des vertrauenswürdigen Netzes (Hinweis auf IP-Spoofing)
  • Verdächtige, ausgehende Verbindungen von Servern aus dem vertrauenswürdigen Netz. Diese können ein Anzeichen dafür sein, dass nach einem erfolgreichen Einbruch der Angreifer Daten aus dem vertrauenswürdigen Netz nach außen kopiert oder von außen Dateien nachlädt, die er für seine weiteren Aktivitäten braucht.

Die Protokolldateien müssen regelmäßig ausgewertet werden und es sollte festgelegt werden, welche Auswertungen mindestens erfolgen sollen. Darüber hinaus sollten zumindest grobe Richtlinien dafür festgelegt werden, welche Schritte unternommen werden, wenn bei der Auswertung auffällige Einträge festgestellt werden.

Prüffragen:

  • Ist festgelegt, welche Ereignisse an den Komponenten des Sicherheitsgateways protokolliert werden?

  • Erfolgt eine regelmäßige Auswertung der Protokolldateien?

  • Entspricht die Protokollierung den geltenden datenschutzrechtlichen Bestimmungen?

  • Erfolgt die Vorhaltung der Protokolldaten zusätzlich zur lokalen Speicherung auf einem zentralen Protokollierungsserver?

  • Erfolgt die Übertragung der Protokollinformationen der Komponenten des Sicherheitsgateways über eine gesicherte Verbindung?

  • Wird bei Ausfall des Protokollierungsservers eine Alarmierung und Sperrung der Funktionen zur Protokolldatengenerierung vorgenommen?

  • Wird bei Ausfall des Protokollierungsservers der Datenverkehr am Sicherheitsgateway blockiert?

  • Sind die Protokolldaten vor Veränderung geschützt?

  • Decken sich die Art und der Umfang der Protokollierung mit den Vorgaben der Sicherheitsrichtlinien der Organisation?

  • Umfasst die Protokollierung an Paketfiltern mindestens folgende Informationen: Quell- und Ziel- IP -Adresse, Quell- und Zielport oder ICMP -Typ, Datum und Zeit sowie die zutreffende Regel des Paketfilters?

  • Werden auf dem Application-Level-Gateway alle Verbindungen protokolliert?

  • Existieren Eskalationsverfahren für den Fall, dass auffällige Einträge bei der Auswertung der Sicherheitsgateway-Protokolle identifiziert werden?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK