Untitled Document

In diesem Kapitel will ich genau auf einzelne Probleme bei der Sicherheit unter Linux eingehen, erklären, wie Angreifer Attacken wie das Abtrennen eines Hosts vom Netzwerk, das Knacken von Passwörtern, Virenangriffe oder Datenklau durchführen, und wie man das verhindert. Weiters werden Tools zum Überwachen und Scannen von Netzwerken und das berüchtigte „Spoofing“ besprochen. Und ein weiter, sehr wichtiger Punkt: Wie erkenne ich einen Einbruch und welche Maßnahmen kann ich von vornherein treffen, um eine möglichst lückenlose Wiederherstellung zu ermöglichen?

Ein Denial-of-Service-Angriff hat immer zum Ziel, einen Host vom Netzwerk⁶ abzuschneiden und somit dessen Dienste unerreichbar zu machen.

Diese DoS-Attacken sind meistens einfach und relativ schnell durchzuführen und haben ein gleich sichtbares Ergebnis: der attackierte Host oder Dienst ist nicht mehr erreichbar. Sie erregen auch weit mehr Aufsehen als z.B. ein Datenklau, der vielleicht nicht einmal bemerkt wird. Deshalb sind diese Attacken unter Hackern sehr beliebt.

Diese Angriffe benutzen meist Fehler in diversen TCP/IP-Implementierungen aus, die solange bestehen, bis ein Patch vom Hersteller veröffentlicht wird. Glücklicherweise ist das bei Linux selten sehr lange, da Dank des öffentlichen Quellcodes und der riesigen Entwickler-Community meistens schon kurz nach Entdeckung eines Fehlers ein Patch bereitsteht. Doch auch hier sind DoS-Angriffe ein nachhaltiges Problem: der Administrator muss den neuesten Stand der Dinge kennen und sich ständig darum kümmern, sein System zu patchen.

Heutzutage können DoS-Angriffe ein nicht zu verachtendes Risiko bergen: Wenn z.B. die Firma Amazon einige Stunden nicht zu erreichen ist, gehen ihr mit Sicherheit einige Tausend Dollar verloren.

Ich möchte im folgenden Abschnitt über zwei Formen von Denial-of-Service - Attacken sprechen:

Ein relativ bekannter Angriff kann mit dem Netzwerkscanner nmap (siehe 2.4 Sniffer und Scanner) durchgeführt werden. Angreifer senden dabei Pakete an Zielports, um zu signalisieren, dass eine Verbindung erwünscht ist. Das ist durchaus legitim. Doch danach wird vom Angreifer ein Paket verschickt, das ein Reset-Flag enthält, also die Verbindung neu startet. Wird das alles wiederholt mit großer Geschwindigkeit und großen Paketen durchgeführt, können Dienste wie FTP, telnet oder HTTP blockiert werden. Das ist ein typischer DoS-Angriff, der mit Überschwemmung von Paketen die Verbindungswarteschlangen überlaufen lässt und den Rechner so von der Aussenwelt abschneidet. Das Problem hierbei ist, dass eigentlich ganz gewöhnliche, legitime Pakete gesendet werden, es ist also schwierig, gegen diese Art von Angriff vorzugehen.

Ein anderer Angriff names mimeflood.pl überschwemmt den Standard-Webserver Apache mit MIME-Headern, was ihn nach einer gewissen Zeit zum Absturz bringen kann. Da Apache keine Beschränkungen auf die Anzahl der MIME-Anfragen, die ein Client durchführen kann, festlegt, ist das es einfach möglich, einige Tausend MIME-Header an den Server zu schicken. Somit können ganze Websites ausgeschaltet werden. In der aktuellen Version von Apache ist dieser Fehler behoben, es gibt aber noch viele Server im Internet, die mit der betroffenen Version 1.2.5 laufen.

Andere DoS-Angriffe überfluten die Linux-Socket-Speicherbereinigung und lösen so eine Kernel-Panik und somit einen Absturz des Systems aus, oder sie scannen halboffene Verbindungen und blockieren auf diese Weise verschiedene Netzwerk-Dienste. Fast jeder DoS- Angriff wird mit Überflutung irgend einer Art ausgelöst.

Ein weiterer, sehr populärer Angriff ist der Ping of Death. Ping ist ein Tool zur Netzwerkdiagnose. Damit werden ECHO REQUEST-Anfragen an einen entfernten Host geschickt, um zu überprüfen, ob er aktiv ist. Einige ältere Linux-Versionen waren anfällig für Angriffe mit übergroßen Ping-Paketen, sie konnten so zum Absturz gebracht werden. Aber auch bei aktuellen Versionen gibt es eine weitere Ansatzstelle bei ping:

mit der ping-Option -l werden so viele Pakete wie nur möglich verschickt. Führt man das nun auf die Broadcast-Adresse aus (die Verteilungs-Adresse des Netzwerks, bei der die Pakete an alle Rechner eines Netzwerks geschickt werden), kann der gesamte Netzwerkverkehr lahmgelegt oder zumindest extrem verlangsamt werden.

Der Netscape-Communicator, nach wie vor eigentlich der Standardbrowser unter Linux, ist leider auch eine der beliebstesten Ansatzstellen für Denial-of-Service - Angriffe.

Ein Webserver schickt dem Browser vor jeder Datei sogenannte MIME-Header, die angeben, um welche Art von Datei es sich handelt und wie sie zu behandeln ist. Netscape-Communicator der Versionen 4.05 bis 4.5b können durch einen MIME-Header des Typs internal/parser zum Absturz gebracht werden.

Weitaus schlimmer kann ein damit verbundener Pufferüberlauf sein: wenn der Browser auf einen unbekannten MIME-Header trifft, wird eine Dialogbox mit einem Puffer von 1KB geöffnet, der mit der richtigen Aussage zum Überlaufen gebracht werden kann. Dieser Exploit (eine Routine oder ein Programm, dass eine Sicherheitslücke ausnützt) kann sogar eine interaktive Shell am Zielrechner erzeugen, der Angreifer hat somit Zugang zum System! In den neueren Versionen von Netscape Communicator treten diese Fehler nicht mehr auf, allerdings werden diese älteren Versionen noch immer (wenn auch eher selten) benutzt.

Eine wirksame Vorsorge gegen DoS-Attacken ist schwierig, da meistens völlig legitime Aktionen benutzt werden, um ein System oder eine Applikation zum Absturz zu bringen. Wichtig ist vor allem Folgendes:

Jeder Versuch, Passwörter zu knacken, entschlüsseln, zu löschen oder zu umgehen gilt⁷ als Passwortangriff. Bei Linux stehen Passwörter an erster Stelle auf der Wunschliste eines Crackers. Einen Shell- oder physikalischen Zugang vorausgesetzt, sind Passwörter alles, was man braucht, um Zugriff auf das System zu erhalten. Natürlich hat man es primär auf das root-Passwort abgesehen, da man damit nicht nur Zugang, sondern auch Kontrolle auf dem Rechner erlangt.

Passwortangriffe sind außerdem auch noch mit Hilfe von automatisierten Tools relativ einfach durchzuführen. Diese Programme setzen bei ihrer Suche nach möglichen Passwörtern vor allem auf die mangelnde Passwortsicherheit. Die meisten Benutzer wählen einfache Passwörter aus dem normalen Sprachgebrauch, die leicht zu merken sind. Solche Passwörter sind mit Hilfe von Wörterbüchern sehr leicht zu erraten.

Doch zuerst will ich kurz erklären, wie Linux Passwörter erzeugt und speichert.

Heutzutage werden bei den meisten Linux-Distributionen die Verschlüsselungsstandards DES oder MD5 benutzt. Hierbei handelt es sich um Einwegfunktionen, d.h. ein einmal verschlüsseltes Passwort kann nicht wieder in Klartext zurückgebracht werden. Man kann also Anhand des chiffrierten Codes nicht auf das Passwort schließen. Um ein verschlüsseltes Passwort zu überprüfen, muss es bei jeder Eingabe dieses Passwortes neu verschlüsselt und mit dem Chiffrierten in /etc/shadow verglichen werden.

Ein Linux-Passwort kann also mit keinem bisher bekannten Algorithmus entschlüsselt werden. Um ein Passwort zu knacken, muss ein Hacker nun erst einmal an den verschlüsselten Code in /etc/shadow herankommen, was sich schon einmal als schwierig gestaltet, da diese Datei nur für den root lesbar ist. Man kann dazu auch Programme wie login nutzen, doch diese haben meistens eine Wartezeit im Falle einer falschen Eingabe eingebaut, um ebendiese Passwortangiffe zu verhindern.

Ein typischer Passwortangriff geht Hilfe eines Wörterbuches vonstatten. Ein automatisiertes Tool verschlüsselt ein paar hundert Einträge dieses Wörterbuches pro Sekunde mit der gleichen Methode, die auch zur Chiffrierung bei Linux angewendet wird und vergleicht das Ergebnis mit den ergatterten, verschlüsselten Passwörtern.

Fortgeschrittene Tools chiffrieren nicht nur die einfachen Wörter, sonder lesen sie z.B. auch rückwärts, hängen sie aneinander oder kombinieren sie mit Zahlen. Mit dieser Methode können die meisten „normalen“ Passwörter geknackt werden.

Durch die Einführung der shadow-Suite, bei der die Passwörter nur für den root und dessen SUID-Programme wie ftp, ssh, telnet oder imapd lesbar sind und nicht mehr in der für jeden lesbaren Datei /etc/passwd stehen, wurde ein großer Schritt in Richtung Passwortsicherheit getan. Doch auch hier gab (oder gibt es teilweise noch immer) einige Sicherheitslöcher, vor allem bei einigen Netzwerkdiensten:

Vor allem bei FTP und telnet kann ein Core Dump erzwungen werden, der shadow-Passwörter enthält.

Bei einem Core Dump handelt es sich um einen Vorgang, bei dem nach einem ernsten Fehler oder einem internen Signal der aktuelle Programmspeicher in eine Datei geschrieben wird.

Ein wirksamer Schutz gegen Passwortangriffe ist vor allem die Wahl eines sicheren Passworts. Es sollte auf keinen Fall folgendermaßen gewählt werden:

Solche Passwörter könnten mit Tools wie Crack oder Jack the Ripper in Sekundenschnelle geknackt werden.

Ein gut gewähltes Passwort setzt sich aus Groß- und Kleinbuchstaben, die kein Wort bilden, Zahlen und Sonderzeichen (wenn möglich) zusammen.

Weiters sollten folgende Maßnahmen ergriffen werden, um eine möglichst hohe Passwortsicherheit zu gewährleisten:

In einem Netzwerk ist es besonders wichtig, dass Passwörter nicht mehrmals verwendet werden. Jeder User sollte auf jedem System und bei jedem Dienst ein eigenes Passwort benutzen, und trotzdem sollten alle diese Passwörter den oben genannten Kriterien entsprechen.

Boot Sektor-Viren werden meist durch infizierte Disketten verbreitet, die im Laufwerk vergessen werden und beim hochfahren des Rechners als bootfähige Disketten erkannt werden, in Wirklichkeit aber den Boot-Sektor infizieren.

Bösartige Code ist meist in einem regulären Programm versteckt und führt Funktionen aus, die vom Benutzer unerwünscht oder zumindest nicht beabsichtigt sind. Meistens werden dabei Dateien, manchmal sogar die ganze Platte, gelöscht.

Viren zeichnen sich aber vor allem dadurch aus, dass sie sich weiterverbreiten. Meist werden andere Dateien und Programme infiziert, oder das Virus verschickt sich per E-Mail selbst weiter.

Von den Zigtausenden bekannten Viren haben es allerdings nur ein winziger Bruchteil auf Linux abgesehen, man kann sie an einer Hand abzählen. Der Grund dafür ist, dass Linux einfach kein guter Brutplatz für Viren aller Art ist. Wie bereits in 1.3, Linux-Systemadministration besprochen, gibt es bei Linux eine auf Benutzer und Gruppen basierende Zugriffskontrolle, und der Lese-, Schreib- und Ausführzugriff ist strikt eingeschänkt. Es ist also äußerst schwierig, ein Virus zu schreiben, der sich in einer Linux-Umgebung weiterverbreitet.

Ein Trojanisches Pferd („Trojaner“) ist ein Programm, das von einem böswilligen Programmierer verändert worden ist. Meistens handelt es sich dabei um Binärdateien (also keine Scripts), wo sich der Quellcode nicht einsehen lässt.

Trojaner haben meist zum Ziel, entweder ein System von innen heraus zu infiltrieren, also einen Remote-Zugriff bereitzustellen. Daher auch der Name - das trojanische Pferd war ein riesiges, hölzernes Pferd, dass der Sage nach der Stadt Troja, die sich nicht erobern ließ, als Versöhnungsgeschenk von den Griechen angeboten wurde. In Wahrheit waren in dem Pferd Krieger versteckt, und als die Einwohner von Troja das Pferd in ihre Stadt holten, öffneten die Krieger die Tore der Stadt, damit die Eroberer Troja stürmen konnten.

Bei Linux lässt sich solch ein Remote-Zugriff ohne root-Rechte aber nur sehr schwer realisieren. Die meisten Linux-Trojaner dienen deshalb dazu, das System auszuspionieren. Ein gefälschtes /bin/login zum Beispiel verhält sich zwar nach außen hin nicht anders, speichert aber unter Umständen Passwörter in einer Textdatei.

Die beste Methode, infizierte Dateien oder Programme aufzuspüren, ist der sogenannte Objektvergleich. Dabei wird überprüft, ob noch alles so ist, wie man es zurückgelassen hat. Zu diesem Zweck wird eine Datenbank angelegt, in der das Datum der Erzeugung, der letzten Änderung und die Größe aller kritischen Dateien gespeichert wird. Natürlich macht dass nur bei manchen Dateien Sinn, bei Logfiles, in denen z.B. der gesamte Netzwerkverkehr aufgezeichnet wird, ist es logisch, dass sich Größe und Datum täglich ändern. Leider können solche Werte (Größe und Datum) relativ einfach manipuliert werden.

Eine weit zuverlässigere Methode, Veränderungen an Dateien aufzuspüren, ist daher die Verwendung von Prüfsummen. Das sind numerische Werte, die sich aus den Summen der Bits einer Datei zusammensetzen. Wenn zwei Prüfsummen übereinstimmen, ist es ziemlich wahrscheinlich, dass die Dateien ident sind.

Das beste Tool zu diesem Zweck heißt Tripwire. Es ist in vielen Distributionen schon enthalten, wer es noch nicht hat, kann es unter www.tripwire.org bekommen. Es bietet eine Vielzahl an Funktionen und Optionen.

Auch Firewalls können ein Infizieren des Systems durch Viren und Trojaner verhindern. Mehr dazu im Kapitel 3, Firewalls unter Linux.

Sniffer und Scanner gleichen einander insofern, als dass beides Tools zum Abhören,⁹ Überwachen oder Ausspionieren von Netzwerken sind.

Sniffer sind Tools, die im Verborgenen das Netzwerk überwachen und Informationen darüber sammeln.

Normalerweise hören und antworten Netzwerkrechner nur auf Datenpakete, die an sie adressiert sind. Es ist jedoch möglich, ein Programm zu schreiben, dass das Network-Interface in den sogenannten Promiscuous Mode versetzt wird. In diesem Modus können alle Datenpakete aus dem Netzwerk abgefangen werden, auch wenn sie woanders hin gehen sollten. Das ist natürlich nicht nötig, wenn man nur den Datenverkehr des lokalen Hosts abhören will. Die meisten Sniffer haben aber das gesamte Netzwerk im Visier, und das geht nur im Promiscuous Mode.

In der Datei /usr/src/linux/include/linux/if.h befinden sich alle Flags, die gesetzt werden können („Signale“, die den Zustand der Netzwerkschnittstelle angeben). Hier die Zeile 34 meiner if.h:

Wenn man nun in einem C-Programm oder einem Perl-Script die Datei if.h, importiert (#include <linux/if.h>), kann man das oben genannte IFF-PROMISC-Flag mit einer relativ einfachen Funktion setzen.

Das Programm linsniffer, einer der populärsten Sniffer unter Linux, benutzt dieses Flag zum Beispiel. Dieser Sniffer wird vor allem eingesetzt, um Passwörter abzufangen und aufzuzeichnen (u.a. FTP-Passwörter). Es werden aber auch viele andere Netzwerkaktivitäten aufgezeichnet, wie z.B. alle Shell-Eingaben einer telnet-Sitzung.

Sniffer stellen also eine große Gefahr dar, da damit Passwörter abgefangen werden können, vertrauliche Informationen aufgezeichnet werden und auch die Sicherheit des gesamten Netzwerks gefährden - Schließlich zeichnen die meisten Sniffer ja nicht nur die Aktivitäten des eigenen Hosts, sonder die aller Rechner des Netzwerks auf.

Es ist relativ schwierig, Sniffer aufzuspüren, da es sich um rein passive Programme handelt. Sie hinterlassen keinerlei Spuren und verbrauchen fast keine Systemressourcen. Die einzige Methode, festzustellen, ob ein Sniffer am Werk ist, ist festzustellen, ob sich eine Netzwerkschnittstelle im Promiscuous Mode befindet. Das geht am einfachsten mit Tools wie ifconfig oder ifstatus:

Wenn ein Sniffer gestartet ist, findet sich folgende Zeile im Output des ifconfig-Tools:

Aber wenn solche Tools die Aktivität von Sniffern feststellen, kann es bereits zu spät sein, der Angreifer könnte bereits an wertvolle Informationen gekommen sein. Um dem vorzubeugen, sollte man, wo immer es geht, auf Verschlüsselung setzen. Eine gute Alternative zu telnet und FTP (die mit Sniffern abgehört werden können) ist z.B. SSH (Secure Shell), das bidirektionale Verschlüsselung bietet. Mehr Informationen dazu in 2.6, Sicherheit bei Datenübertragungen.

Scanner sind Tools, die Sicherheitsschwachstellen jeder Art aufdecken. Sie können wie folgt in zwei Gruppen eingeteilt werden:

Systemscanner legen ihr Augenmerk hauptsächlich auf fehlerhafte Dateirechte und Schwachstellen bei den Accounts, wie leere Passwortfelder und schwache Passwörter. Ein schon etwas angegrauter, aber immer noch nützlicher Systemscanner ist COPS - Computer Oracle and Password System. Er sucht nach:

Netzwerkscanner hingegen testen Hosts über Netzwerkverbindunen, sondieren Dienste und Ports und suchen nach bekannten Exploits. Der ISS (Internet Security Scanner) ist ein Beispiel für solche Scanner. Er ist allerdings kommerziell.

Ein schon etwas älterer, wenn auch sehr bemerkenswerter Netzwerkscanner ist SATAN (Security Administrator's Tool for Analyzing Networks). Dieses Tool besteht aus mehreren Scan-Modulen, die entfernte Rechner auf Sicherheitsschwachstellen in folgenden Bereichen testen:

SATAN wurde im Lauf der Jahre weiterentwickelt, stark verbessert und in SAINT umbenannt - Security Administrator's Integrated Network Tool. Es bietet nun auch Support für folgende neue Fehlerquellen:

Der Standard-Netzwerkscanner bei Linux ist The network Mapper (nmap), der in nahezu jeder Distribution enthalten ist. Er scannt nach geöffneten Diensten und Ports und zeichnet sich durch vielseitige Funktionen aus.

Ein Scanner arbeitet immer nach dem gleichen Prinzip, egal ob Netzwerk- oder Systemscanner:

Nach dem Start wird ein bekannter Exploit oder eine Schwachstelle ausgewählt, nach der gesucht wird. Ist der Scan erfolgreich, d.h. das System oder das Netzwerk ist verwundbar, wird das in einer Log-Datei protokolliert. Anschließend wird der nächste Exploit ausgewählt, usw. Wenn alle bekannten Schwachstellen getestet wurden, wird das Resultat ausgegeben.

In den Händen von Systemadministratoren sind Scanner wichtige Tools, die einem ermöglichen, Schwachstellen aufzuspüren und auszumerzen. Es lohnt sich also, auf jedem neuen System ein paar Scanner laufen zu lassen. Aber in den falschen Händen können sie viel Schaden anrichten, da sie Hacker zeigen, wo sie bei ihrem Angriff ansetzen können.

Eines vorweg: Verhindern kann man Scans nicht. Aber man kann Scan-Aktivitäten aufspüren und ihren Ursprung feststellen.

Ein dazu geeignetes Tool ist courtney, es spürt SATAN und SAINT - Scans auf und stellt deren Ursprung fest. Man kann es unter

Die beste Methode, Scannern ihre Wirksamkeit zu nehmen, ist, sie selbst zu benutzen, und die gefundenen Sicherheitslöcher zu stopfen. Dazu sollte man jedoch immer die neuesten Versionen benutzen, da Scanner sich sehr schnell weiterentwickeln.

Ursprünglich verstand man unter Spoofing, dass Angreifer Pakete so fälschen, dass diese¹⁰ von einem anderen Absender zu stammen scheinen. Mittlerweile versteht man darunter jede Methode, Authentifizierungs- und Identifizierungsverfahren zu untergraben.

Beim IP-Spoofing fälschen Angreifer Pakete so, dass sie die IP-Adresse eines anderen, gewünschten Hosts tragen.

Zum Beispiel kann anhand von Einträgen in der Datei /etc/hosts.equiv entfernten Rechnern und deren Benutzern Zugang zum eigenen System gewährt werden, ohne dass ein Passwort eingegeben werden muss. Sie werden anhand ihrer IP-Adresse authentifiziert.

Allerdings ist ist nicht ganz so einfach, IP-Spoofing durchzuführen, nur indem man die IP-Adresse fälscht. Die Sache ist nämlich die: Bei einer TCP-Verbindung zwischen zwei Hosts koordinieren diese den Datenverkehr mit Sequenznummern. Diese bestätigen den Erhalt von Paketen. Das läuft folgendermaßen ab:

Bei Beginn der Verbindung sendet der Client ein Datenpaket mit seiner Anfangssequenznummer, der Server sendet daraufhin ebenfalls ein Paket zurück, gekoppelt mit seiner eigenen Anfangssequenznummer und der des Clients plus eins, als Bestätigung. Bei Erhalt dieses Paketes wiederum schickt auch der Client eine Bestätigung: die Anfangssequenznummer des Servers plus eins.

Wenn nun ein Paket mit einer gefälschten IP-Herkunftsadresse an den Server verschickt wird, schickt dieser seine Bestätigung an den Client, von dem er glaubt, dass das Paket stammt. Das heißt, der Angreifer bekommt das Paket nicht und muss nun die Sequenznummer des verlorenen Paketes herausfinden oder erraten, um sich mit dem Zielrechner zu synchronisieren und eine gültige Sitzung starten zu können. Das wird meist mit versierten Algorithmen und dem trial&error-Verfahren erreicht.

Obwohl die Anfangssequenznummern von Zufallsgeneratoren erzeugt werden, ist es mit einigem Aufwand möglich, diese zu erraten.

Jeder Dienst, der IP-Adressen als Authentifizierunsverfahren benutzt, ist durch IP-Spoofing verwundbar. Dazu gehören rsh (Remote-Shell) und das X-Window-System.

Doch man kann IP-Spoofing-Angriffe durchaus auch abwehren. Man sollte grundsätzlich keine Dienste verwenden, die IP-Adressen zum Authentifizieren benutzen, sondern auf Dienste zurückgreifen, die kryptographische Lösungen bieten. Die wichtigsten dieser Dienste werden ich im nächsten Abschnitt, 2.6, Sicherheit bei Datenübertragungen, vorstellen.

Eine weitere Art des Spoofing ist das ARP-Spoofing. ARP steht für Address Resolution Protocol, d.h. in ARP-Tabellen wird jeder Hardware-Adresse eine IP-Adresse zugeordnet. Hardware-Adressen sind einzigartige Werte, die vom Hersteller in die Netzwerkkarte gebrannt wurden und die physikalische Netzwerkschnittstelle identifizieren. Beim ARP-Spoofing sendet der Angreifer falsche ARP-Tabellen-Informationen an das Ziel und dessen Cache. Man „übernimmt“ somit eine andere IP-Adresse. Allerdings wird der Cache meist alle 60 Sekunden aktualisiert, dem Angreifer steht also nur wenig Zeit zur Verfügung.

Die beste Methode, um ARP-Spoofing abzuwehren, ist, die ARP-Tabellen statisch, also unveränderlich zu machen. Das bedeutet aber einen erhöhten Zeitaufwand, denn wenn sich die Hardwareadresse ändert (neuer Rechner oder Netzwerkkarte), muss die Tabelle manuell angepasst werden. Diese Tabelle befindet sich meistens in /etc/ethers, Das Tool zum Ändern der Tabelle heißt arp.

Eine gute zusätzliche Maßnahme ist die Verwendung des Programmes ARPWATCH, dass auf Veränderungen in der ARP-Tabelle achtet.

Beim DNS-Spoofing ändert ein Hacker die Zuordnungstabellen von Hostnamen und IP-Adressen bei einem DNS-Server. Wenn man die Auflösung eines Hostnamens (z.B. www.google.com) anfordert, erhält man eine geänderte IP-Adresse, meist zu einem Server, der sich unter der Kontrolle des Hackers befindet.

Am 23. Jänner 2001, 11 Uhr vormittags, fand ein großangelegter DNS-Spoofing-Angriff auf sämtliche Microsoft Server satt. Ich habe damals mit nslookup den Inhalt des Microsoft-DNS-Servers ausgelesen, darunter fand sich unter anderem:

Man sieht: Ein erfundener Hostname zeigt den Triumph des Hackers, und beim microsoft.com-Hostnamen wurde die IP entfernt, um die Seite unerreichbar zu machen.

Wenn man Unstimmigkeiten bei der Namensauflösung bemerkt, sollt man den entsprechenden DNS-Server sofort überprüfen. Es gibt dazu auch ein Tool namens DOC (Domain Obscenity Control), das automatisch Fehlverhalten von Domains diagnostiziert. Man findet es unter http://www.securityfocus.com/data/tools/auditing/network/doc.2.0.tar.Z

Zum Abschluss möchte ich noch ein weiters Spoofing-Utility erwähnen: ICQ Hijaak. Man kann damit Sitzungen entführen, Passwörter ändern und Nachrichten fälschen. Eigentlich harmlos, aber man kann damit ein wenig Verwirrung bei Bekannten stiften. Man findet es unter http://www.geocities.com/SiliconValley/Sector/8208/ICQHack.htm

Wie ich im Kapitel 2.4, Sniffer und Scanner, schon besprochen habe, sind einige Netzwerkdienste, vor allem telnet, ftp & rsh, sehr durch elektronische Abhöreinrichtungen gefährdet.

Doch es gibt eine empfehlenswerte Alternative für die meisten dieser Dienste: SSH¹¹ (Secure Shell). Das ist ein sicheres Login-System, das populäre Verschlüsselungsalgorithmen wie BlowFish und DES zur Chiffrierung der übertragenen Daten bietet.

Der Programmierer hat bei der Entwicklung auf einen modularen Aufbau von SSH geachtet. Das Basisprotokoll ist unabhängig von den Verschlüsselungsalgorithmen, wenn also jemals eines der Chiffrier-Verfahren geknackt würde, könnte man SSH schnell und einfach auf einen neuen Algorithmus umstellen.

Ein weiteres Plus von SSH ist, das es zur Authentifizierung von Hosts nicht deren IP verwendet, sondern Anhand von öffentlichen RSA-Schlüsseln. RSA, der Rivest-Shamir-Adelmann-Algorithmus, ist ein bekanntes Verschlüsselungssystem, dass mit einem öffentlichen und einem privaten Schlüssel arbeitet.

Wie fast jedes Programm unter Linux wird SSH mit Hilfe von Textdateien konfiguriert. Diese Dateien sind /etc/ssh_config für den Client und /etc/sshd_config für den SSH-Server.

Wenn man den Verkehr zwischen Server und Client nun mit einem Sniffer abhört, kann man mit den empfangenen Daten nicht viel anfangen: im Gegensatz zu telnet, wo man unter Umständen sogar das Passwort ergattern kann, erhält man bei SSH nur Datenmüll.

Beim Einloggen auf einen Remote-Rechner ist SSH mittlerweile fast Standard. Anfängliche Sicherheitsprobleme sind längst ausgemerzt, seit Version 1.2.26 kann SSH als sicher angesehen werden. Das ist bei Dateiübertragungen allerdings nicht der Fall, hier wird hauptsächlich FTP verwendet. Man wird also in manchen Fällen nicht darum herumkommen, FTP anzubieten.

FTP steht für File Transfer Protocol und dient vor allem dazu, Dateien zuverlässig und effektiv zwischen zwei Rechnern zu übertragen. Allerdings werden FTP-Daten standardmäßig nicht verschlüsselt übertragen. Auch hier können kritische Informationen mit Sniffern ausspioniert werden. Andere Sicherheitslöcher, wie z.B. fehlerhafte Dateirechte, wurden längst ausgemerzt.

FTP wird über die Datei /etc/ftpaccess konfiguriert. Um die Sicherheit von FTP zu erhöhen, kann bestimmten Usern der FTP-Zugriff verweigert werden (/etc/ftpusers). Man kann auch bestimmten Accounts von unterschiedlichen Hosts zu Zugriff erlauben oder verweigern, dazu wird die Datei /etc/ftphosts benutzt:

Eine sichere Alternative zu FTP ist SSLftp. Das ist ein SSL-fähiger FTP-Client und -Server. SSL steht für Secure Socket Layer, ein mehrschichtiges Protokoll, dass wie SSH auf RSA-Authentifizierung und einen starken Verschlüsselungsalgorithmus setzt. Mehr dazu noch später in diesem Kapitel. SSLftp bekommt man unter:

Die bekannteste und meistbenutzteste Methode, heutzutage Daten zu übertragen, ist zweifellos per E-Mail. Deshalb darf in diesem Kapitel ein Abschnitt über Mail-Sicherheit¹³ nicht fehlen.

Um E-Mails rund um den Globus zu transportieren, wird das Simple Mail Transfer Protocol (SMTP) verwendet. Ein SMTP-Server erhält ankommende Nachrichten, und je nachdem ob die Nachricht an einen entfernten oder lokalen Empfänger adressiert ist, leitet er die Mail weiter oder speichert sie zur Abholung. Das Problem bei SMTP-Servern: Standardmäßig vertrauen sie jedem. Benutzer können unter jeder beliebigen Adresse E-Mails verschicken, SMTP wird die Mail pflichtgemäß mit falscher Herkunftsadresse weiterleiten.

Das kann ein Problem werden, wenn Hacker unbegrenzten Zugang zu einem SMTP-Server bekommen. Sie können dann unter dem Deckmantel totaler Anonymität Tausende Spam-Mails innerhalb kürzester Zeit verschicken.

Es ist wichtig, zu verhindern, dass Unbefugte Zugriff auf einen SMTP-Server bekommen. Unter Umständen kann es so zu ernsten Fällen von Informationsdiebstahl kommen. Außerdem sollte dringend darauf geachtet werden, dass eventuell installierte SMTP-Server im eigenen Netzwerk vor missbräuchlicher Verwendung geschützt sind, um Spams oder gefälschten E-Mails vorzubeugen.

Der standardmäßige Mail-Transport-Agent ist bei Linux meist sendmail. Dieses Programm ist so komplex und schwierig zu konfigurieren, dass ganze Bücher darüber geschrieben wurden. Sendmail hatte früher eine Menge Sicherheitslöcher, vor allem war es anfällig für diverse Pufferüberläufe, bei einer schon etwas älteren Version gab es sogar einen Exploit, durch den man root-Zugriff erlangen konnte.

Ein etwas aktuelleres Sicherheitsloch bei sendmail ist, dass durch Senden von Nachrichten mit einer großen Anzahl von To:-Headern sendmail in Schach gehalten werden kann und dadurch das ganze System zum Stillstand gebracht werden kann. Aber nicht nur wegen diesen Schwachstellen ist sendmail ein beliebtes Ziel für Hacker, sondern auch aus folgenden Gründen:

Das Wichtigste ist wie immer: Auf dem Laufenden bleiben. Die aktuelle Version ist meist die sicherste. Bei den neuesten Versionen ist Relaying zum Glück standardmäßig deaktiviert. Unter Relaying versteht man das Bekommen und Weiterleiten von E-Mails. Will man Relaying zulassen, muss man dass in der Datei /etc/mail/access angeben.

Es gibt auch eine Liste aller weltweit bekannten Spammer. Sie heißt Real Blackhole List (RBL). Um sendmail anzuweisen, diese Liste jedesmal abzufragen, um zu bestimmen, ob es Mail von einer Domain akzeptieren kann, muss man folgenden Eintrag in die /etc/sendmail.mc - Konfigurationsdatei machen:

Nachdem dieser Befehl eingefügt wurde, muss man noch den m4-Makroprozessor laufen lassen:

Eine gute Alternative zu sendmail ist Qmail. Es wurde mit dem Ziel entwickelt, ein sicherer Ersatz für sendmail zu sein. Man bekommt es unter www.qmail.org.

Das Network File System (NFS)¹⁴ ähnelt grob der „Netzwerkumgebung“ in Windows. Man kann damit entfernte Dateisysteme mounten. Diese verhalten sich auf dem Rechner des entfernten Benutzers so, als ob sie lokal wären. Im lokalen Netzwerk ist das NFS durchaus praktisch, man sollte aber vermeiden, es auf einem öffentlichen Webserver laufen zu lassen. Muss man das aber, sollten unbedingt folgende Punkte beachtet werden:

Zum Abschluss dieses Kapitels über Sicherheit bei Datenübertragungen will ich noch etwas genauer auf das bereits erwähnte SSL (Secure Socket Layer)¹⁵ - Protokoll eingehen.

Bei der Verbindungsaufnahme tauschen der SSL-Server und der Client ihre Schlüssel aus und bauen danach eine synchronisierte, verschlüsselte Verbindung auf. Damit wäre das erste oben genannte Problem gelöst.

Zusätzlich kann der Server über beliebte Methoden wie RSA und DES Benutzer authentifizieren (Problem Nummer 2 behoben).

Und letztendlich kann der Server die Integrität laufender Sitzungen mit Message-Digest-Algorithmen wie MD5 überprüfen. Das funktioniert folgendermaßen: Ein 32-Bit Fingerabdruck einer bestimmten Eingabe wird generiert, der völlig eindeutig ist. (Es ist mathematisch völlig unmöglich, ein Duplikat zu erzeugen). Ein Datenpaket generiert also immer die gleiche MD5-Signatur, ausser es wurde verändert. Somit kann eine Arbeitssitzung leicht verifiziert werden.

Nach einigen anfänglichen Problemen, die bald behoben wurden, hat sich SSL bald als Standard für die Sicherung von Client-Server-Verbindungen etabliert. Bei Linux hat SSL vor allem für dem Webserver Apache Bedeutung. Dank eigenen Patches unterstützt der populäre Webserver ebenfalls SSL und kann damit sichere Sitzungen garantieren.

Ein wichtiges Instrument für Einbruchserkennung ist Logging. So wird der Vorgang¹⁶ genannt, wenn ein Betriebssystem oder eine Anwendung Ereignisse aufzeichnet und für spätere Durchsicht aufhebt. Bei Linux gibt es eine sehr umfangreiche Protokollierung, u.a. werden folgende Informationen aufgezeichnet:

lastlog oder last geben z.B. Informationen darüber aus, wann welcher Benutzer über welches Terminal eingeloggt war. Das ist natürlich enorm hilfreich, um unbefugten Zugriff aufzuspüren. Allerdings gibt es Programme, die diese Standard-Logging-Systeme umgehen können. Sie werden Sweeper oder Cleaner genannt.

Um gegen Cracker, die über solche Programme verfügen, vorzugehen, sollte man Logging-Tools von Drittanbietern verwenden. Nur selten wird diese Möglichkeit von Hackern berücksichtigt (oder diese Tools werden einfach übersehen). Außerdem kann man so die Standard-Systemlogs mit denen der zusätzlichen Logging-Tools vergleichen. Bei Unstimmigkeiten weiß man sofort, dass ein Einbruch stattgefunden hat.

Wer ultimative Zuverlässigkeit will, sollte seine Logs auf einen entfernten Server oder auf einmalbeschreibbare Medien umleiten.

System- und Kernelmeldungen werden übrigens von den Dämonen syslogd und klogd behandelt und in /var/log/messages gespeichert.

Ale paar Monate sollte man seine Log-Files auf CD oder andere externe Medien schreiben und zur Sicherheit einige Zeit aufbewahren. Dann können die Log-Dateien auf der Festplatte neu angelegt werden, um zu verhindern, dass sie übermäßig viel Speicherplatz belegen.

Um die Überprüfung der Logs zu automatisieren, gibt es die sogenannten Einbruchserkennungssysteme. Diese Tools beschränken sich aber meist nicht auf das Logging, sondern überwachen zusätzlich den Netzwerkverkehr und ergreifen bei verdächtigen Aktivitäten entsprechende Maßnahmen. Diese Einbruchserkennungs-systeme basieren meistens auf Datenbanken mit bekannten Angriffen oder Angriffssignaturen. Wird eines der Kriterien aus der Datenbank erfüllt, wird das als Einbruchsversuch aufgezeichnet. Man sollte allerdings großen Wert darauf legen, dass diese Datenbanken immer auf dem neuesten Stand sind, idealerweise werden sie täglich aktualisiert.

Diese Systeme können oft sogar automatisch Gegenmaßnahmen ergreifen, z.B. den betreffenden Port sperren oder die IP des Angreifers in hosts.deny eintragen, um ihm jeglichen Zugriff zu verweigern.

Allerdings haben Einbruchserkennungssysteme auch ihre Nachteile: Erstens sind sie recht speicherintensiv. Das kann sie auch zum Ziel von Hackern werden lassen: Wenn ein Hacker merkt, dass das System auf die gleichen Angriffsversuche immer mit der gleichen Maßnahme reagiert, kann er den Host mit gleichen Angriffen von vielen verschiedenen Adressen überschwemmen und so eine Prozess-Übersättigung herbeiführen und unter Umständen das Einbruchserkennungssystem zum Absturz bringen oder außer Gefecht setzen.

Was nun noch fehlt, ist die Wiederherstellung nach Einbrüchen - Disaster Recovery. Neben dem Risiko, die Daten aufgrund von Hackerangriffen zu verlieren, kann es auch noch andere Bedrohungen geben, die das System zumindest beeinträchtigen können:

Wenn man sich die Ratschläge aus Kapitel 1, besonders Physikalische Sicherheit und Sicherheit bei der Installation, zu Herzen genommen hat, ist die Grundlage für erfolgreiches Disaster Recovery geschaffen. Darüber hinaus sind Backups als wichtigstes Element zur Wiederherstellung nach Katastrophen anzusehen, darunter versteht man das Sichern wichtiger Daten auf externe Datenträger.

Backups werden je nach Art und Größe auf Iomega-ZIP-Laufwerke (100-250 MB), CD-ROMS (650-700 MB), Bandlaufwerke (2-5 GB) oder ganzen Wechselfestplatten (bis mehrere Hundert GB) gespeichert. Ein Backup muss nicht zwangsläufig das gesamte Dateisystem umfassen, auch ein Sichern wichtiger Projektdaten macht Sinn.

Die nötigen Tools zur Archivierung und Komprimierung von Daten und Verzeichnissen sind in jeder Linux-Distribution enthalten: tar und gzip:

Mit tar kann man nicht-komprimierte Archive erstellen. Viele Dateien können so zu einer Großen zusammengefasst werden, diese einzelne Datei wird Tarball genannt.

Wenn man z.B. alle Dateien im Verzeichnis /home archivieren will (was übrigens nicht bedeutet, dass sie anschließend gelöscht werden, der Tarball mit den archivierten Dateien wird nur hinzugefügt), kann man folgendes tun:

Das würde ein Tar-Archiv namens „alles.tar“ im aktuellen Verzeichnis erstellen, in dem alle Dateien von /home enthalten sind.

Nun kann man das komprimierte Archiv je nach Größe auf den jeweiligen Datenträger speichern. Wenn irgendwie möglich, sollte ein Backup immer nur auf einem Datenträger gespeichert sein und sich nicht über mehrere Disketten oder CD's erstrecken. Wenn man einen verliert, ist das Backup nutzlos, außerdem erhöht sich so die Gefahr eines Schreibfehlers.

Der beschriebene Datenträger sollte sicher verwahrt werden (am besten an einem anderen Ort). Wenn Backups jetzt auch noch so oft und regelmäßig wie möglich durchgeführt werden, kann eigentlich nicht mehr allzu viel schiefgehen.

6linux hacker's guide von anonymous, Kapitel 17 - Denial-of-Service-Angriffe

7linux hacker's guide von anonymous, Kapitel 5 -Passwortangriffe

Sicherheit unter Linux, URL: http://www.linuxfibel.de/securesystem.htm

8linux hacker's guide von anonymous, Kapitel 6 - Bösartiger Code

9linux hacker's guide von anonymous, Kapitel 7 - Bösartiger Code & Kapitel 8 - Scanner

10linux hacker's guide von anonymous, Kapitel 9 - Spoofing

11linux hacker's guide von anonymous, Kapitel 10 - Sicherheit der Daten während der Übertragung

SSH und PGP, URL: http://www.urz.uni-heidelberg.de/Veranstaltungen/LUG/Vortraege/SSH/Vortrag.SSH-2.html

Secure Shell für Benutzer, URL: http://www.lrz-muenchen.de/services/security/ssh/ssh-4.html

Secure Shell (SSH) für Unix, URL: http://www.uni-karlsruhe.de/Uni/RZ/Software/Systemsoftware/ssh/unix/#SSH2

Manpage von ssh

12linux hacker's guide von anonymous, Kapitel 11 - FTP-Sicherheit

Manpage von ftp

13linux hacker's guide von anonymous, Kapitel 12 - Mail-Sicherheit

14linux hacker's guide von anonymous, Kapitel 14.1.3 - Network File System

15linux hacker's guide von anonymous, Kapitel 15 - Sichere Protokolle

16linux hacker's guide von anonymous, Kapitel 19 - Logs und Audit-Trails, Kapitel 20 - Einbruchserkennung und Kapitel 21 - Disaster Recovery-Wiederherstellung nach Katastrophen.