7.2 Betrieb von Firewalls

Transkript

1 7.2 Betrieb von Firewalls 237 Administrator die virtuellen Interfaces aus, hinter denen sich die zu schützenden Systeme des jeweiligen Kunden befinden. Anhand des virtuellen Interfaces, über das ein Paket die Firewall-Plattform betritt, ordnet die Firewall das Paket zunächst der zugeordneten virtuellen Firewall zu. Anschließend wird es von der virtuellen Firewall weiter verarbeitet, d.h. gegen deren Regelbasis bzw. Statustabelle geprüft. Hersteller Check Point Cisco Juniper Produkt FireWall-1/VPN-1 VSX Cisco FWSM NetScreen-500 und höher Tab. 7 2 Hersteller und Produkte für virtuelle Firewalls 7.2 Betrieb von Firewalls Die wichtigsten Alltagsaufgaben eines Firewall-Administrators sind die regelmäßige Analyse der Logdatei der Firewall, das Troubleshooting von Kommunikationsproblemen sowie die Pflege der Regelbasis. Auf diese wichtigen betrieblichen Aufgaben wollen wir in den folgenden Unterabschnitten näher eingehen Analyse der Logdatei der Firewall Die Ziele bei der am besten täglich durchgeführten Logfile-Analyse sind primär Hinweise auf möglicherweise erfolgreiche Angriffe zu finden, aber auch fehlerhaft konfigurierte oder defekte Systeme sowie sonstige Auffälligkeiten zu entdecken. Auf diese Aspekte gehen wir in diesem Abschnitt ausführlich ein. Darüber hinaus kann das Logfile im Bedarfsfall als Werkzeug bei konkret auftretenden Kommunikationsproblemen herangezogen werden. Das Troubleshooting solcher Probleme behandelt der nächste Abschnitt»Troubleshooting von Kommunikationsproblemen«, S Je nach eingesetztem Firewall-Produkt unterscheiden sich die Logging-Philosophie und der Aufbau der Logdatei(en) grundlegend. Gemeinsam ist für alle Produkte jedoch, dass es zum einen systembezogene und zum anderen verbindungsbezogene Logeinträge gibt. Systembezogene Logeinträge liefern Informationen über den Zustand der Firewall (z.b. knappe Systemressourcen, Kommunikationsprobleme mit dem Management-Server etc.). Interessant für die tägliche Logfile-Analyse sowie für das Troubleshooting von Kommunikationsproblemen sind vor allem die verbindungsbezogenen Logeinträge, welche die von der Firewall erlaubten und vor allem verworfenen Verbindungen dokumentieren. Im weiteren Verlauf dieses Abschnitts beziehen wir uns ausschließlich auf die verbindungsbezogenen Logeinträge.

2 238 7 Management von Firewalls Aufbau einer Logdatei Je mehr Informationen ein Logeintrag beinhaltet, desto einfacher gestaltet sich die Logfile-Analyse. Die wichtigsten Informationen, die ein Logeintrag mindestens enthalten sollte, sind: Der Zeitstempel Jeder Logeintrag muss das Datum und die genaue Uhrzeit enthalten, an dem er erzeugt wurde. Um Logeinträge der Firewall mit Einträgen anderer Logdateien zur Deckung bringen zu können, zum Beispiel nach einem erfolgten Einbruch, sollten alle Systeme innerhalb einer Sicherheitsumgebung über dieselbe Uhrzeit verfügen. Für diesen Zweck bietet sich der Einsatz eines NTP-Servers an, der allen Systemen über das Network Time Protocol eine einheitliche Uhrzeit bereitstellt. Der Grund für den Logeintrag Um nachzuvollziehen, weshalb ein Logeintrag erzeugt wurde, sollte im Logeintrag die Nummer der Regel (Check Point FireWall-1) bzw. der Nachrichtencode (Cisco PIX) referenziert werden. Die Information, ob die geloggte Verbindung erlaubt oder verworfen wurde. Die Quell- und Ziel-IP-Adresse sowie der Quell- und Ziel-Port der geloggten Verbindung. Folgendes Beispiel zeigt drei Logeinträge, die die Cisco PIX Firewall unseres fiktiven Unternehmens erzeugt hat. Alle Einträge tragen den Fehlercode , der besagt, dass ein Paket aufgrund einer Access-Liste verworfen wurde. Der Name der entsprechenden Access-Liste wird ebenfalls dokumentiert. Oct 4 13:30:19 Cisco-PIX Oct :27:11: %PIX : Deny tcp src outside: /1165 dst inside: /1023 by access-group "outside_access_in" Oct 4 13:30:19 Cisco-PIX Oct :27:11: %PIX : Deny tcp src outside: /1233 dst RAS: /445 by access-group "outside_access_in" Oct 4 13:30:19 Cisco-PIX Oct :27:11: %PIX : Deny udp src inside: /49152 dst outside: /53 by access-group "inside_access_in" Logging Policy Die Logging Policy beschreibt, welche Ereignisse von der Firewall geloggt werden sollen. In der Praxis findet man meist nur eine von zwei Logging Policies an. Das Logging ist nur für die Clean-Up- und Stealth-Rule (siehe Abschnitt»Konfiguration der Cisco PIX«, S. 142) sowie für einzelne Regeln, über die

3 7.2 Betrieb von Firewalls 239»kritische«Dienste erlaubt werden, aktiviert. Auf diese Weise wird wenig I/O erzeugt und das Datenaufkommen bleibt überschaubar und damit leichter analysierbar. Dies ist insbesondere in großen Umgebungen wichtig. Bei dieser Policy dokumentiert das Logfile alle von der Firewall verworfenen Verbindungen (Clean-Up- und Stealth-Rule) sowie die erlaubten»kritischen«verbindungen wie zum Beispiel ein ssh-zugriff zur Firewall. Das Logging wird für (fast) alle Firewall-Regeln aktiviert, d.h., das Logfile dokumentiert alle verworfenen und zusätzlich auch alle erlaubten Verbindungen. Häufig existieren Vorgaben seitens der Revision eines Unternehmens, alle Verbindungen zu loggen. Im Falle eines erfolgreichen Angriffs auf ein System können bei dieser Logging Policy unter Umständen mehr Hinweise über den Ablauf des Angriffs gewonnen werden als bei der ersten Policy, da auch eine ungewöhnliche Häufung erlaubter Zugriffe auf einen Angriff hindeuten kann. Die gewählte Logging Policy sollte auch im Verdachtsfall, d.h., wenn ein System vermutlich gerade angegriffen wird, nicht verändert werden. Die Chance, dass Logfiles bei der forensischen Analyse sinnvoll verwertet werden können, ist dann am größten, wenn sie durch die Routine des normalen Betriebs entstanden sind. Bei der forensischen Analyse wird nach einem erfolgreichen Einbruch versucht, auf der Basis von verschiedenen Logdateien (Firewall-Logdatei, Systemlog des angegriffenen Systems, Log des Intrusion-Detection-Systems etc.) einen Angriff zu rekonstruieren und auf diese Weise zum Beispiel den Urheber des Angriffs zu ermitteln. Zur Erstellung einer Logging Policy gehört auch, sich über das Verhalten des eingesetzten Firewall-Produkts zu informieren, falls kein Logging mehr möglich ist, z.b. falls auf der Festplatte kein Platz mehr verfügbar ist oder die Verbindung zum Logserver unterbrochen wurde. Bei der Check Point Firewall-1 werden in so einem Fall die Logeinträge auf der lokalen Festplatte des Enforcement-Moduls zwischengespeichert, bis die Verbindung zum Management-Server wiederhergestellt werden kann. Läuft die Festplatte in der Zwischenzeit voll, stoppt die FireWall-1 je nach Konfiguration entweder das Logging und verweigert optional die Annahme weiterer Verbindungen, oder sie löscht alte Logeinträge. Bei einer Cisco PIX, die über das Netzwerk zu einem UDP-basierten syslog- Server loggt, geht beim Ausfall des Logservers der Betrieb unverändert weiter. Die PIX bietet aber auch die Möglichkeit, über TCP mit dem syslog-server zu kommunizieren. syslog-server, die TCP unterstützen, sind zum Beispiel der Kiwi syslogd, der syslog-ng von BalaBit, der Cisco PIX Firewall syslog-server PFSS sowie bestimmte Log-Appliances. Wird TCP verwendet, werden beim Ausfall des syslog-servers von der PIX keine weiteren Verbindungen mehr akzeptiert. Aus diesem Grund wird in den meisten Fällen ein UDP-basierter syslog-server bevorzugt.

4 240 7 Management von Firewalls Reduzierung der Datenmenge Um die Logdatei hinsichtlich Auffälligkeiten oder Hinweisen auf erfolgreiche Angriffe zu untersuchen, sollte vorher das»grundrauschen«, d.h. nicht interessierende Einträge, entfernt bzw. ausgeblendet werden. Dies gilt insbesondere für solche Logging Policies, bei denen (fast) alle erlaubten und nicht erlaubten Verbindungen geloggt werden. Nicht interessierende Einträge sind in der Regel: Verworfene NetBios-Broadcasts von Windows-Systemen. Befinden sich Windows-Systeme in einem an der Firewall angeschlossenen Netz, erscheinen deren Broadcasts im Logfile der Firewall, sofern das Logging hierfür nicht unterbunden wurde. Bekannte Phänomene, die bereits in der Vergangenheit analysiert wurden und für die es eine sinnvolle Erklärung gibt. Ein Beispiel hierfür sind von der Firewall verworfene Pakete, die zu einer Verbindung gehören, die von den Kommunikationspartnern zwar aufrechterhalten wird, aber von der Firewall aufgrund eines abgelaufenen Timeouts bereits aus der Statustabelle entfernt wurde. Abb. 7 9 Mustererkennung Korrelieren Kategorisieren Normalisieren (Grundrauschen abziehen) Filtern Logfile/Rohdaten Schritte zur Interpretation der Logdatei Häufig ist auch die Rolle der Firewall entscheidend für die Relevanz bestimmter Logfile-Einträge. Bei der Analyse der Logdatei der externen Firewall unseres fiktiven Unternehmens zum Beispiel sind Meldungen über erfolglose Verbindungsversuche der im Internet aktuell kursierenden Würmer und Trojaner eher von geringem Informationswert. Automatische Würmer probieren ziellos, anfällige Systeme zu finden. Ein dadurch erzeugter Logfile-Eintrag ist kein Indiz für einen gezielten potenziell erfolgreichen Angriff. Aus diesem Grund können derartige Logeinträge, erkennbar an den entsprechenden Portnummern, beim Logfile der externen Firewall als nicht interessierendes Grundrauschen aufgefasst werden. Treten entsprechende Einträge jedoch im Logfile der Intranet-Firewall auf, ist höchste Aufmerksamkeit geboten, da möglicherweise ein entsprechender Wurm im internen Netzwerk kursiert. Durch die Vorfilterung wird bereits ein Großteil der Einträge eines durchschnittlichen Tages unterdrückt, so dass das Logfile für den Administrator leser-

5 7.2 Betrieb von Firewalls 241 licher und leichter auswertbar wird. Die Vorfilterung kann entweder bereits implizit durch die Logging Policy erfolgen, d.h., bestimmte Ereignisse werden schlichtweg nicht geloggt, oder explizit durch den Einsatz von Filtern, mit denen im Logfile die nicht interessierenden Einträge ausgeblendet werden. Der grafische SmartView Tracker von Check Point bietet zum Beispiel die Möglichkeit zur Definition solcher Filter. Bei textbasierten Logdateien, wie der syslog-datei einer PIX Firewall oder einem mit fwm logexport oder fw log exportierten Check Point Logfile, kann eine Filterung mit Unix-Tools wie grep, sed oder awk skriptgesteuert erfolgen. Außerdem existieren so genannte Log-Appliances, die das Filtern und Analysieren großer Datenmengen aus verschiedenen Quellen (unter anderem der Firewall) in Echtzeit ermöglichen. Inhaltliche Auswertung der Logdatei Nach dem Ausblenden der nicht relevanten Logeinträge sollten an das verbleibende Logfile zum Beispiel folgende Fragen gestellt werden. Wie groß ist die Anzahl der Logeinträge? Ist die Anzahl der Logeinträge deutlich höher oder niedriger als am Vortag? Wie hoch ist die Abweichung in Prozent? Nach den Gesetzen der Stochastik sollten die Abweichungen nach Abzug des Grundrauschens nicht größer als ±20% sein. Wie groß ist die Anzahl der Logeinträge im Vergleich zum gleichen Wochentag der zurückliegenden Kalenderwoche? Können Abweichungen bei bestimmten Wochentagen durch periodische oder zuvor angekündigte Aktivitäten wie z.b. Updates, Backups oder Rechnungsläufe erklärt werden? Falls die Anzahl der Logeinträge ungewöhnlich hoch ist: Gibt es zum Beispiel einen neuen Wurm, der sich im Internet ausbreitet (externe Firewall)? Kann die erhöhte Anzahl durch Hardwareprobleme, wie zum Beispiel eine defekte Netzwerkkarte oder einen defekten Switchport, oder durch Konfigurationsfehler, zum Beispiel einem falschen Default-Gateway auf einem Host, erklärt werden? Falls dies zu keinem Ergebnis führt, sollte festgestellt werden, welche Regel die meisten Logeinträge verursacht hat. Handelt es sich hierbei um eine neue oder kürzlich modifizierte Regel, ist zu klären, ob es sich aufgrund des Informationsgehalts um Grundrauschen handelt, das zukünftig ebenfalls ausgeblendet werden kann. Gibt es Logeinträge, die auf einen erfolgreichen Einbruch hindeuten? Erscheint im Logfile zum Beispiel ein Eintrag, der einen von der Firewall verworfenen FTP-Zugriff eines Webservers in der DMZ in das interne Netzwerk dokumentiert, existieren dafür zwei denkbare Erklärungsmöglichkeiten.

6 242 7 Management von Firewalls Erstens hat der Administrator des Webservers versucht, vom Webserver aus über FTP-Dateien ins interne Netz zu transferieren, oder zweitens hat es ein Angreifer geschafft, über einen Angriff auf Applikationsebene in den Webserver einzubrechen und versucht nun, über das FTP-Protokoll weiter ins interne Netzwerk vorzudringen. Die erste Erklärungsmöglichkeit ist zunächst nicht sehr plausibel, da davon auszugehen ist, dass der Administrator des Webservers darüber informiert ist, dass FTP in Richtung internes Netzwerk von der Firewall nicht zugelassen wird. In so einem Fall sollte der Firewall-Administrator mit dem Administrator des Webservers Rücksprache halten. Kann der verdächtige Logeintrag dabei nicht plausibel erklärt werden, müssen auf dem Webserver weitere Maßnahmen ergriffen werden, um den Verdacht zu erhärten bzw. zu entkräften (siehe Kasten Incident Handling). Exkurs: Incident Handling Führt die Auswertung der Firewall-Logdatei zu dem Verdacht, dass in ein bestimmtes System eingebrochen wurde, müssen weitere Indizien gesammelt werden, um den Verdacht zu erhärten bzw. zu entkräften. Die fünf grundlegenden Schritte für das verdächtige System sind dabei: 1. Netzwerkanschluss»instrumentalisieren«, d.h. sich in die Lage zu versetzen, den Netzwerkverkehr mitlesen zu können (so genanntes Sniffing, siehe»troubleshooting von Kommunikationsproblemen«, S. 245) und gegebenenfalls rasch eine Trennung vom Netz vornehmen zu können. Die Trennung sollte dabei nach Möglichkeit ohne längeren Ausfall des Netzwerk-Links erfolgen, da eine auf dem System vom Angreifer installierte Malware die Logdateien des Systems auf ein solches»link down«-ereignis überprüfen könnte, um dann die»selbstzerstörung«einzuleiten. 2. Betriebssystem»instrumentalisieren«, d.h. die Logdateien des Betriebssystems hinsichtlich verdächtiger Einträge überprüfen sowie gegebenenfalls vertrauenswürdige Software einbringen (statisch gelinkt, wenn möglich), die alle Prozesse und Sockets auflistet, z.b. lsof für Unix- Betriebssysteme oder ein vergleichbares Tool für Windows (zum Beispiel das Freeware-Tool Pmon von Sysinternals, 3. Betriebssystem»validieren«, d.h. MD5-Prüfsummen von allen ausführbaren Dateien (Executables) anfertigen, insbesondere von denen, die gerade als Prozesse ausgeführt werden, und anschließend gegen eine vertrauenswürdige Datenbank vergleichen, die alle MD5-Hashes der Executables des Betriebssystems enthält. Abweichende MD5-Hashes können auf ein Rootkit hindeuten.

7 7.2 Betrieb von Firewalls 243 Ein Rootkit ersetzt wichtige Systemprogramme wie ps, ls oder netstat durch Trojanische Pferde. Das Ziel des Rootkits ist es, die vom Angreifer installierte Software (z.b. ein Backdoor-Programm), die ebenfalls Bestandteil des Rootkits sein kann, unsichtbar zu machen. Beispielsweise zeigt ein vom Rootkit ausgetauschtes dir- oder ls-executable alle Dateien mit Ausnahme der Dateien an, die vom Angreifer auf das kompromittierte System kopiert wurden. Mit dem Vergleich von MD5-Hashes können nur herkömmliche Rootkits, aber keine kernelbasierten Rootkits erkannt werden. Letztere klinken sich wie ein Gerätetreiber in den Kernel des Betriebssystems ein und tauschen bestimmte Systemcalls aus. Die Maßnahmen 1, 2 und 3 können in der Reihenfolge variieren. 4. Wenn die bisher beschriebenen Maßnahmen zu keinem Ergebnis führen, aber das System aufgrund seines Verhaltens weiterhin»verdächtig«erscheint, sollten Tools wie chkrootkit ( für Unix und klister oder Patchfinder2 ( für Windows eingesetzt werden, um eventuell ein kernelbasiertes Rootkit zu entdecken. 5. In Abhängigkeit von den Verdachtsmomenten muss eine Entscheidung getroffen werden zwischen Weiterlaufenlassen des Systems mit verstärktem Logging und Mitlesen des Netzwerkverkehrs. Zusätzlich sollte ein Backup des Systems durchgeführt werden. Das System vom Netz trennen, volatile Informationen wie Hauptspeicherinhalt, Prozessliste, Socket-Liste oder MACtimes sichern und dann zwecks Plattenkopie und anschließender Offline-Analyse der Kopie das System ausschalten. Ein Mittelweg zwischen 5a und 5b ist eine bitgenaue Plattenkopie im laufenden Betrieb, die durch das Weiterlaufen des Systems jedoch nicht konsistent ist (es sei denn, sie wird gegen einen Filesystem-Snapshot angefertigt) Vertiefende Literatur: SANS ICH-Guide mit einem 10-Punkte-Notfallplan: Dan Farmers und Wietse Venemas Ratgeber für UNIX: CERT-Informationen für Windows:

8 244 7 Management von Firewalls Einem Firewall-Logfile können grundsätzlich keine direkten Hinweise auf einen erfolgreichen Angriff entnommen werden. Erfolgreiche Angriffe werden über von der Firewall erlaubte Protokolle auf Anwendungsebene durchgeführt, so dass im Logfile der Firewall keine direkten Spuren hinterlassen werden. Es ist anhand der im Logfile dokumentierten verworfenen Pakete lediglich ersichtlich, welche Zugriffe nicht erfolgreich waren. Wie an obigem Beispiel beschrieben wurde, können aber auch solche Logeinträge für die Erkennung und Rückverfolgung eines zuvor erfolgten Einbruchs entscheidend sein. Bei der Analyse des Logfiles einer externen Firewall, die das Unternehmen vor Zugriffen aus dem Internet schützt, wird der Firewall-Administrator mehrmals täglich so genannte Portscans entdecken. Bei einem Portscan sucht ein potenzieller Angreifer systematisch nach Ports, die über das Internet erreichbar sind. Für diesen Zweck existieren zahlreiche freie (z.b. nmap) und kommerzielle (z.b. ISS Security Scanner) Werkzeuge, so genannte Portscanner, die automatisch nach offenen Ports suchen. Das Ziel eines Portscans ist die Beschaffung von Informationen über die erreichbaren Systeme und die darauf installierten Dienste. Ein bei der Logfile-Auswertung erkannter externer Portscan hat in der Regel einen geringen Informationswert, da es sich um keinen Angriff handelt und zum»grundrauschen des Internet-Traffics«gehört. Im Logfile der Firewall sind Portscans meist sehr leicht erkennbar, weil innerhalb von wenigen Sekunden Hunderte von Logeinträgen erzeugt werden. Bei einem Portscan werden entweder für eine bestimmte öffentliche IP-Adresse mehrere Hundert Ports durchprobiert, oder es werden für alle öffentlichen IP-Adressen bestimmte interessierende Ports, wie zum Beispiel der Port 22 für ssh-server oder der Port 80 für Webserver, durchprobiert. Portscans, die im Firewall Logfile sofort erkennbar sind, werden in der Regel durch unprofessionelle Script Kiddies (siehe Abschnitt»Das Sicherheitsproblem«, S. 92) durchgeführt. Ein professioneller Angreifer würde niemals auf diese Weise vorgehen, sondern auf Portscans entweder ganz verzichten oder so genannte Stealth Scans einsetzen, die sich nicht direkt im Logfile erkennen lassen. Stealth Scans erfolgen zum Beispiel sehr langsam, so dass eine Häufung verworfener Pakete nicht ohne weiteres erkennbar ist, oder verteilt von verschiedenen Quellen aus. Um zum Beispiel einen langsamen Scan zu erkennen, ist es wichtig, dass die Daten der Logdatei nicht nur chronologisch nach Zeit, sondern in verschiedenen anderen Ansichten sortiert nach Kriterien wie Quell-IP-Adresse, Ziel- IP-Adresse oder Ziel-Portnummer dargestellt werden können. Ein langsamer Portscan ist in einer chronologischen Ansicht nicht erkennbar, in einer nach Quell-IP-Adressen sortierten Ansicht aber sofort.