Die Funktionsweise und Sinnhaftigkeit einer Firewall

Dieser Beitrag bietet einen Überblick über die Funktionsweise einer Firewall und deren Sinn oder Unsinn. In meinem Freundeskreis höre ich oftmals folgende Aussagen:

  • "Eine Firewall schützt mich vor Hakerangriffen und Viren."
  • "Meine Firewall wehrt ständig Portscans ab, ich bin sicher."
  • "Durch meine Firewall kann ich bestimmen, welche Anwendungen Zugriff auf das Internet haben"

Hierbei ist einiges Wahres dabei, aber auch viel gefährliches Halbwissen. Generell sollte im Hintergrund behalten werden, dass der IT-Security-Sektor ein Milliardenmarkt ist und viele Unternehmen ein Interesse an einer "anhaltenden" oder "steigenden IT-Gefahrenlage" haben. Viele Softwareprodukte fluten den Nutzer mit Meldungen von erfolgreich abgewehrten Gefahren, um ihm ein Gefühl der subjektiven Sicherheit zu vermitteln. Nutzer, die sich erfolgreich von einer Gefahr beschützt gefühlt haben, empfehlen auch gerne mal ein Produkt weiter...

Grundlegendes: Vor was schützt eigentlich eine Firewall?

Im Artikel Netzwerkgrundlagen habe ich bereits kurz erläutert, wie die Kommunikation in einem Netzwerk funktioniert: IT-Geräte rufen im Internet Services auf, die von einem entfernten PC hinter einer IP und einem Port angeboten werden. Beim Anschauen dieser Webseite wurde beispielsweise mit Hilfe des Browsers eine Verbindung zur IP Adresse hinter der Domain itsecblog.de zu Port 443 (https) aufgebaut. Die meisten Desktop Firewalls sind Paketfilter mit einer so genannten Stateful Packet Inspection. Der Begriff klingt erst einmal "wichtig", beschreibt jedoch nichts anderes als eine Technik, die Datenpakete einer bestimmten Sitzung zuordnet. Ein Beispiel:

Der User "Müller" öffnet den Blog, er stellt also eine Verbindung von seinem PC mit dem Webserver dieses Blogs her. Ein Stateful Packet Inspection Filter ist nun in der Lage, alle Pakete zu identifizieren und zuzulassen, die im Rahmen des Datenaustausches zwischen dem Browser des Clients "Müller" und dem Webserver versendet werden.

Viele Firewalls bietet die Möglichkeit, den Zugriff auf bestimmte IP-Adressen bzw. Ports und Protokolle zu verhindern (bzw. erschweren).

Eine Firewall schützt vor Angriffen gegen den Client... oder?

Ein weit verbreiteter Irrtum - eine Firewall schützt nicht gegen Gefahren, die beim Surfen im Internet, dem Lesen von E-Mails oder der Verwendung anderer Anwendungen auftreten. Es ist unmöglich, beispielsweise den Browser oder das E-Mail Programm direkt über eine Internetverbindung anzugreifen. Weder ein Browser, noch ein E-Mailprogramm bieten im Internet einen Service an, mit dem ein Angreifer sich verbinden könnte. Bei Nicht-Serverdiensten wie dem Browser oder den Großteil aller Anwendungen ist eine Firewall vollkommen nutzlos. Angriffe finden grundsätzlich über die Inhaltsebene statt. Firewalls mit einem Funktionsumfang, die so etwas verhindern könnten, sind keine Firewalls mehr, sondern beispielsweise inhaltsbezogene Proxys. Mit einer Firewall im klassischen Sinne hat dies nichts mehr zu tun. Ein reines, korrekt konfigurierte Clientsystem hat keine offenen Ports. Wofür auch? Welche Aufgaben sollte eine Firewall in so einer Konfiguration übernehmen? Ein Port ohne Service dahinter ist geschlossen. Soll ein Service angeboten werden, muss die Firewall an diesem Port den Traffic durchlassen.

In dieser Konfiguration stellt eine Firewall eher eine Sicherheitslücke als ein Sicherheitsgewinn dar: Eine Firewall ist eine weitere Softwarekomponente, die Sicherheitslücken enthalten könnte und angegriffen werden kann. Einen Zweck erfüllt sie hierbei nicht. Das Betriebssystem Ubuntu hat im Auslieferungszustand die integrierte Firewall beispielsweise komplett deaktiviert. Je mehr Software an einem Kommunikationsprozess beteiligt ist, desto höher die Chancen für einen Angreifer, eine Schwachstelle zu finden!

Die Funktionsweise und Sinnhaftigkeit einer Firewall weiterlesen

TLS (SSL) Verschlüsselung und Schwachstellen im Detail

Seit wenigen Tagen überschlägt sich die Presse mit Meldungen, dass Verschlüsselungen "im Internet" geknackt worden sein. Leider wurde hierbei so oft voneinander zitiert, dass sich auch viele Übertreibungen und Vereinfachungen in den Nachrichten finden, die mit der Wahrheit wahrscheinlich nicht mehr all zu viel zu tun haben. Nachdem ich die ersten Schlagzeilen gelesen habe, dachte ich mir anfangs, dass ich es mir nicht vorstellen konnte, dass die unterschiedlichen mathematischen Probleme, auf den Verschlüsselungen beruhen, geknackt worden sind. Nach dem Lesen der Artikels bemerkte ich, dass ich recht hatte: Nicht die Verschlüsselungen wurden geknackt, sondern, im Gegenteil, es wurde getrickst und beeinflusst, um Verschlüsselungen, durch absichtlich inkorrekte Implementierung, unsicherer zu gestalten.

Wie ich bereits im Beitrag Grundlagen der Verschlüsselung auf mögliche Schwachstellen hingewiesen habe, möchte ich nun einmal kurz & leicht verständlich auswerten, was eigentlich in den Presse in den letzten Tagen bekannt geworden ist. Ich stütze mich hierbei auf die Berichte der New York Times, des Guardian und des Online-Portal ProPublica. Weiterhin habe ich mir Texte von Bruce Schneier als Quelle genommen, ein anerkannter, renommierter Kryptographieexperte, der ebenfalls Zugriff auf die geleakten Dokumente hatte.

Ist die SSL Verschlüsselung unwirksam und somit sinnlos?

Nein, nach den bisher vorliegenden Informationen nicht. Den Berichten zur Folge wurden Wege gefunden, dennoch verschlüsselte Informationen mitlesen zu können. Die Wege sind bei weitem nicht neu, nur die Größenordnung und die hohe Systematik dahinter ist neu. Um die "Schwachstellen" von SSL nachvollziehen zu können, müssen wir im im Bereich der SSL bzw. TLS Verschlüsselungen ins Detail gehen, hierbei werde ich auch auf das Thema Perfect Forward Secrecy (PFS) eingehen.

Der TLS-Handshake: Der Verbindungsaufbau

Wird eine https-verschlüsselte Webseite aufgerufen, müssen zahlreiche Nachrichten zwischen den Server und dem Browser ausgetauscht werden, bevor im Browser der Inhalt der Webseite angezeigt werden kann.

Der TLS Handshake im Detail
Der TLS Handshake im Detail (Angelehnt an https://commons.wikimedia.org/wiki/File:SSL_handshake_with_two_way_authentication_with_certificates.svg)

TLS (SSL) Verschlüsselung und Schwachstellen im Detail weiterlesen

DNSCrypt für mehr Sicherheit und Privatsphäre

DNSCrypt ist eine interessante Möglichkeit für PCs, Server und Android-Smartphones, die Sicherheit, Integrität und Privatsphäre im Internet deutlich zu erhöhen. DNSCrypt geht auf eine Initiative von OpenDNS zurück, ein globaler, öffentlicher DNS Anbieter.

Die Relevanz der Sicherheit von DNS Anfragen wird häufig von Administratoren und sicherheitsbewussten IT Nutzern übersehen, obwohl die Manipulationen von DNS Antworten eines der häufigsten und einfachsten Möglichkeiten darstellt, ein System zu kompromittieren.

DNSSEC war ein erstes Vorhaben, die Authentizität und Integrität der DNS Daten sicherzustellen.

Was ist DNS, wie funktioniert es?

Ein kurzer Abriss zu den Funktionsweisen des DNS Systems, ich beschreibe im Folgenden die Standardfunktionsweise der Namensauflösung unter Windows, Linux und Android:

DNS Aufloesung ohne DNSCrypt als Flussdiagramm
DNS Auflösung ohne DNSCrypt als Flussdiagramm

Das Diagramm ist einfach verständlich, die Schwachstellen liegen vor allem an den Punkten 1 und 2, worauf ich gleich näher eingehen werde. DNS Anfragen und Antworten werden grundsätzlich im Klartext über das Internet versendet, für jeden lesbar. Mit einem Netzwerk-Sniffer extrahiert, sieht die Anfrage (Punkt 1 in der oberen Darstellung) wie folgt aus: DNSCrypt für mehr Sicherheit und Privatsphäre weiterlesen

Ein gehärteter Linux Kernel mit PaX und Grsecurity

Pax Tux
Das Linux-Maskottchens in der PaX Variante.

Einen eigenen, sicheren Linux Kernel mit PaX und Grsecurity zu kompilieren hat eine Menge Vorteile, insbesondere bei öffentlich erreichbaren Servern. Ich kann jedem nur empfehlen, seinen Computer mit diesen beiden Kernel-Patchsammlungen zu härten.

In der IT-Sicherheit gibt es das Prinzip, optimiert-minimalistisch vorzugehen. Minimalistisch bedeutet, dass die Anzahl der Services, Anwendungen und Dateien auf einem Server und auf dem Netzwerkpfad auf dem Weg dorthin quantitativ möglichst gering gehalten werden sollte. Jedes Netzwerkgerät, jede Firewall, jeder Virenscanner und jedes Intrusion Detection System das sich in einem Netzwerk oder auf einem Computer befindet, kann prinzipiell Schwachstellen enthalten und angreifbar sein.

Optimiert vorzugehen bedeutet, das die notwendigen Tools hochsicher konfiguriert worden, in einer sicheren Umgebung kontrolliert laufen und, wenn möglich, gehärtet worden sind.

Zusammenfassung: Viele Tools zur Absicherung sind oftmals unsicherer als wenige, hoch optimierte und gehärtete Komponenten!

Auf jedem Linux Server ist ein Linux-Kernel vorhanden, es handelt sich daher um eine notwendige Komponente, die es im Folgenden zu härten gilt.

Was ist ein Kernel?

Der Kernel ist der "essentielle Kern" eines jeden Betriebssystems. Es ist der "unterste Teil" des Betriebssystems, der jedoch mit den höchsten Rechten läuft. Sollte dieses Grundwissen über den Kernel nicht vorhanden sein, empfehle ich jedem, sich vor einer Härtung mit PaX & Co. ein grundlegendes Wissen zu der Thematik anzueignen. Ein falsch konfigurierter, selbst kompilierter, gehärteter Kernel kann anfälliger sein, als der Kernel der Distribution!

Was ist PaX?

PaX beinhaltet eine Reihe von Patches, die für den Linux Kernel entwickelt worden sind. Die Patches bieten eine Reihe Vorteile, neue Funktionalitäten und einige Verbesserung vorhandener Kernel-Features. Als Schutz vor Exploits bietet PaX beispielsweise eine verbesserte ASLR (Address Space Layout Randomization).

Was ist Grsecurity?

Grsecurity sind weitere Patches für den Linux Kernel. PaX und Grsecurity wurden für eine Zusammenarbeit entwickelt und bedingen einander. Die Hauptfeatures von Grsecurity sind:

  1. Ein RBAC-System (eine Rollenbasierte Zugriffskontrolle)
  2. Memory Execution Prevention (NX-Bit), Memory Randomization (ASLR) und eine Verhinderung des Ausnutzens von Buffer-Overflows (über die PaX Patches)
  3. Trusted Path Execution.
  4. Zusätzliche chroot (Change Root) Härtung
  5. Randomisierungen (TCP/IP Stack und Prozess-IDs)
  6. Eingeschränkte Sichtbarkeit von Prozessen (z.B. den Kernel Threads)

Die Funktionalitäten lassen sich über Sysctl konfigurieren.

Ein gehärteter Linux Kernel mit PaX und Grsecurity weiterlesen

Linux Kernel kompilieren

Dieser Beitrag wurde am 14.Dezember 2014 auf die Linux-Kernel-Version 3.14.26 aktualisiert.

Einen eigenen Linux Kernel aus den Quellen zu kompilieren, ist Thema dieses IT Security Blog Beitrags. In einigen Tagen (Update: Beitrag erschienen) werde ich einen weiteren Beitrag veröffentlichen, bei denen ich Möglichkeiten nennen werde, einen "gehärteten" bzw. "gepatchten" Linux Kernel zu kompilieren. Bevor wir uns jedoch mit Themen wie PAX, grSecurtity & Co. auseinander setzen, müssen einige Grundlagen vorhanden sein. Die Quellcodebeispiele werde ich auf Basis eines Debian GNU/Linux Systems (Ubuntu 14.04 LTS) demonstrieren.

Vor- und Nachteile eines eigenen Kernels

Um es vorwegzunehmen - notwendig ist ein eigener Kernel in den meisten Fällen nicht. Mit Hilfe eines eigenen Kernels ist es beispielsweise möglich, diesen exakt an das System anzupassen, daher nur die Module bzw. Treiber zu kompilieren, die auch wirklich für das System benötigt werden. Ein Debian Paket des aktuellen Kernels lässt sich somit auf eine Größe von etwa 6-7 MB reduzieren. Notwendig ist ein selbst kompilierter Kernel beispielsweise auch dann, wenn dieser für mehr Sicherheit, zur Systemhärtung, gepatcht und angepasst werden soll.

Die Konfiguration erfordert etwas Erfahrung, der größte "Nachteil" ist die etwas schwerere Wartbarkeit. Ein Update des selbst kompilierten Kernels aus den Paketquellen der Distribution ist dann nicht mehr ohne weiteres möglich.

Eine Wiederherstellung bzw. Rückkehr zum originalen Kernel der Distribution ist zu jedem Zeitpunkt ohne Probleme möglich.

Linux Kernel kompilieren weiterlesen

Martin Witkowski zu Themen aus IT, Datenschutz & Sicherheit.