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:
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 →
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:
Ein RBAC-System (eine Rollenbasierte Zugriffskontrolle)
Memory Execution Prevention (NX-Bit), Memory Randomization (ASLR) und eine Verhinderung des Ausnutzens von Buffer-Overflows (über die PaX Patches)
Trusted Path Execution.
Zusätzliche chroot (Change Root) Härtung
Randomisierungen (TCP/IP Stack und Prozess-IDs)
Eingeschränkte Sichtbarkeit von Prozessen (z.B. den Kernel Threads)
Die Funktionalitäten lassen sich über Sysctl konfigurieren.
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.
Social Engineering oder in diesem Kontext auch Social Hacking ist eine der größten Gefahren für die IT-Sicherheit von Unternehmen. Ich möchte mit diesem Beitrag eine Beitragsreihe in meinem IT Security Blog beginnen, die Sicherheitslücken in Unternehmens- und Privatnetzwerken aufzeigen soll, denen ich immer wieder begegne. Die meisten Unternehmen legen den Fokus zum Schutz ihrer IT Infrastruktur viel zu eng und verstehen darunter meist nur die Sicherheit ihrer Server und den Grundschutz der Clients. Thematiken wie Social Engineering werden meist vollkommen außer Acht gelassen.
Am Beispiel des Unternehmens "Weltweit Dienstleistungs GmbH" möchte ich die Knackpunkte der IT Sicherheit näher erläutern. Das Netzwerk des Unternehmens sieht wie folgt aus:
Das obere Netzwerk ist mit dem Internet verbunden und durch eine Firewall geschützt. Die Web- und E-Mailserver befinden sich in einer DMZ (demilitarisierten Zone). Das interne Netzwerk ist durch eine Firewall von der DMZ getrennt. Es existiert ein W-Lan um BYODs (="Bring your Own Device"), also von Mitarbeitern selbst mitgebrachte IT-Geräte, an das interne Netzwerk anzuschließen. Die PCs sind auf einem aktuellen Stand und mit einer marktüblichen Antivirenlösung ausgestattet.
Eine erste, kurze Analyse der Dinge, die gut am oberen Aufbau sind:
Es wird eine dedizierte Firewall verwendet, um das gesamte Unternehmensnetzwerk zu schützen.
Der Web- und E-Mail-Server liegen in einer 2-stufigen-DMZ. Der Webserver ist der häufigste initiale Angriffs- und Schwachpunkt in einem Unternehmensnetzwerk.
Web- und E-Mail-Server liegen auf verschiedenen Servern. Damit kann der Zugriff auf E-Mails vermieden werden, wenn der Webserver kompromittiert worden ist.
Das interne Netzwerk ist durch eine Firewall geschützt. Durch diese Maßnahme kann bei einer Kompromittierung innerhalb des DMZ ein Angriff auf das interne Netzwerk erschwert werden.
Diese Woche möchte ich mich in meinem IT Security Blog, inspiriert durch eine Freundin, dem Thema sicherem Online-Banking zuwenden. Konkret wurde ich gefragt, ob der sogenannte "Inkognito-Modus", den manche Browser implementiert haben, zusätzliche Sicherheit beim Online-Banking bietet.
Ähnlich wie im Beitrag "Grundlagen der E-Mail Verschlüsselung" möchte ich anfangs die Angriffsmöglichkeiten und Risiken näher erläutern und anschließend einige Möglichkeiten nennen, Online-Banking sicherer und somit sorgloser genießen zu können.
Angriffsmöglichkeiten und Risiken beim Online-Banking
Die meisten werden Online-Banking in der Form kennen, dass sie sich über eine Webseite Ihrer Bank auf ihrem Konto einloggen und dort Transaktionen vornehmen können. Weitere Formen sind beispielsweise Online-Banking über eine App oder direkt aus einem Finanzprogramm heraus. All diesen Verfahren liegt zu Grunde, dass der Bankkunde über einen Client (also dem Browser, der App oder dem Finanzprogramm) mit einem Server (ein Computer, der einer Bank gehört) über das Internet kommuniziert.
Wie aus der Graphik ersichtlich, sind Angriffe an drei verschiedenen "Orten" möglich:
Auf dem Server der Bank,
im Internet, auf dem Weg vom Client zum Server und
auf dem Client, also dem PC des Kunden.
Die Details hinter der Wolke "Internet" habe ich im Artikel E-Mail Verschlüsselung: Die Grundlagen näher beschrieben. In der Realität liegen die Probleme in erster Linie beim Computer des Kunden oder, deutlich seltener, auf dem Weg vom Client zum Server. Auf die Sicherheit des Bankservers muss man sich als Kunde verlassen können, darauf haben Nutzer keinen Einfluss.