[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]


Anleitung zum Absichern von Debian
Kapitel 10 - Vor der Kompromittierung


10.1 Halten Sie Ihr System sicher

Sie sollten bestrebt sein, Ihr System sicher zu halten, indem Sie seine Verwendung und die es betreffenden Verwundbarkeiten im Auge behalten. Sobald Patches verfügbar sind, sollte Sie diese auch einspielen. Denn auch wenn Sie zu Beginn ein sehr sicheres System eingerichtet haben, sollten Sie daran denken, dass die Sicherheit eines Systems mit der Zeit nachlässt. Das liegt daran, dass Sicherheitslücken in Systemdiensten entdeckt werden können. Außerdem können Benutzer die Sicherheit untergraben, wenn ihnen das notwendige Verständnis fehlt (z.B. wenn sie entfernt auf ein System mit einem Klartextpasswort oder einem einfach zu erratenden Passwort zugreifen) oder gar weil sie aktiv versuchen, die Sicherheit des Systems auszuschalten (indem sie z.B. zusätzliche Dienste lokal in ihren Konten installieren).


10.1.1 Beobachtung von Sicherheitslücken

Die meisten Administratoren werden sich Sicherheitslücken, die ihr System betreffen, bewusst, wenn sie den dazugehörigen Patch sehen. Sie können aber Angriffen schon im Vorfeld begegnen und vorübergehende Abwehrmaßnahmen einleiten, sobald Sie festgestellt haben, dass Ihr System verwundbar ist. Dies gilt besonders für exponierte Systeme (sind z.B. mit dem Internet verbunden), die Dienste anbieten. In diesem Fall sollte der Systemadministrator einen Blick auf die bekannten Informationsquellen werfen, um als erster zu wissen, wenn eine Sicherheitslücke für einen kritischen Dienst entdeckt wird.

Typischerweise abonniert man eine Mailingliste für Ankündigungen und beobachtet Webseiten oder Fehlerverfolgungssysteme der Software-Entwickler eines bestimmten Programms. So sollten beispielsweise Apache-Benutzer regelmäßig Apaches Auflistung von Sicherheitslücken durchsehen und die Mailingliste Ankündigungen für den Apache-Server abonnieren.

Um bekannte Sicherheitslücken, die die Debian-Distribution betreffen, zu verfolgen, bietet das Testing-Security-Team von Debian einen Sicherheitstracker an. Dieser führt alle bekannten Sicherheitslücken auf, die in Paketen von Debian noch nicht ausgebessert wurden. Die Informationen im Tracker stammen aus öffentlich zugänglichen Quellen. Dazu zählen Datenbanken über Sicherheitslücken und die Fehlerdatenbank von Debian. Administratoren können nach bekannten Sicherheitsmängeln für Stable, Oldstable, Testing oder Unstable suchen.

Der Tracker kann mittels einer Benutzerschnittstelle durchsucht werden (nach CVE-Namen und dem Paketnamen). Einige Werkzeuge (wie zum Beispiel debsecan, vgl. Automatisches Überprüfung von Aktualisierungen mit debsecan, Abschnitt 10.1.2.4) setzen diese Datenbank ein, um auf Verwundbarkeiten des betreffenden Systems hinzuweisen, die noch nicht ausgebessert wurden (d.h. für die eine Ausbesserung bevorsteht).

Sicherheitsbewusste Administratoren können mit diesen Informationen feststellen, welche Sicherheitslücken das System, das sie verwalten, betreffen könnten, wie schwer das Risiko der Lücke wiegt und ob vorübergehend Gegenmaßnahmen zu treffen sind (falls möglich), bis ein Patch verfügbar ist, der das Problem löst.

Sicherheitsprobleme in Veröffentlichungen, die vom Sicherheitsteam von Debian unterstützt werden, sollten irgendwann in Debian-Sicherheits-Ankündigungen (DSA) behandelt werden, die allen Benutzern zur Verfügung gestellt werden (vergleiche Fortlaufende Aktualisierung des Systems, Abschnitt 10.1.2). Sobald ein Sicherheitsproblem ausgebessert wurde und die Lösung in einer Ankündigung enthalten ist, wird es nicht mehr im Tracker aufgeführt. Sie können es aber immer noch mit einer Suchanfrage (nach dem CVE-Namen) finden, indem Sie Querverweise für Debian-Sicherheitsankündigungen verwenden.

Beachten Sie aber, dass die Informationen im Tracker des Debian-Testing-Sicherheitsteams nur bekannte Sicherheitslücken (d.h. solche, die öffentlich sind) beinhalten. In einigen Fällen gibt das Debian-Sicherheitsteam DSA für Pakete heraus, die auf vertraulichen Informationen beruhen, die das Team erhalten hat (z.B. über nicht-öffentliche Mailinglisten der Distributionen oder von Programmautoren). Seien Sie also nicht überrascht, in Sicherheitsankündigungen Sicherheitsprobleme zu entdecken, die nicht im Tracker enthalten sind.


10.1.2 Fortlaufende Aktualisierung des Systems

Sie sollten regelmäßig Sicherheitsaktualisierungen durchführen. Der ganz überwiegende Anteil der Exploits nutzt bekannte Sicherheitslücken aus, die nicht rechtzeitig ausgebessert wurden. Dies wird in der Veröffentlichung von Bill Arbaugh dargestellt, die 2001 auf dem »IEEE Symposium on Security and Privacy« vorgestellt wurde. Das Durchführen einer Aktualisierung wird unter Ausführen von Sicherheitsupdates, Abschnitt 4.2 beschrieben.


10.1.2.1 Überprüfung von Hand, welche Sicherheitsaktualisierungen verfügbar sind

Debian besitzt ein Werkzeug, um zu überprüfen, ob ein System aktualisiert werden muss. Viele Benutzer wollen aber einfach von Hand überprüfen, ob Sicherheitsaktualisierungen für ihr System zur Verfügung stehen.

Wenn Sie Ihr System nach der Beschreibung unter Ausführen von Sicherheitsupdates, Abschnitt 4.2 eingerichtet haben, müssen Sie nur Folgendes tun:

     # apt-get update
     # apt-get upgrade -s
     [ ... überprüfen der zu aktualisierenden Pakete ... ]
     # apt-get upgrade 
     # checkrestart
     [ ... Neustart der Dienste, die neu gestartet werden müssen ... ]

Weiter müssen alle Dienste, deren Bibliotheken aktualisiert wurden, neu gestartet werden. Bemerkung: Lesen Sie Ausführen von Sicherheitsupdates, Abschnitt 4.2 für weitere Informationen zu Bibliotheks- (und Kernel-)Aktualisierungen.

Die erste Zeile wird die Liste der verfügbaren Pakete von den festgelegten Paketquellen herunterladen. Die Option -s wird eine Simulation durchführen, d.h. es werden keine Pakete heruntergeladen oder installiert. Vielmehr teilt es Ihnen mit, welche heruntergeladen und installiert werden sollen. Durch dieses Ergebnis könnten Sie erfahren, welche Pakete von Debian ausgebessert wurden und als Sicherheitsaktualisierung verfügbar sind. Zum Beispiel:

     # apt-get upgrade -s
     Reading Package Lists... Done
     Building Dependency Tree... Done
     2 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
     Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
     Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
     Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
     Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)

In diesem Beispiel können Sie erkennen, dass auf dem System cvs und cupsys mit neuen Versionen aus Woodys Sicherheitsarchiv aktualisiert werden müssen. Um herauszufinden, warum eine Aktualisierung notwendig ist, sollten Sie http://security.debian.org besuchen und sich ansehen, welche aktuellen Debian-Sicherheits-Ankündigungen zu diesen Paketen veröffentlicht wurden. In unserem Fall sind die zugehörigen DSA DSA-233 (für cvs) und DSA-232 (für cupsys).

Denken Sie daran, den Rechner neuzustarten, wenn der Kernel aktualisiert wurde.


10.1.2.2 Überprüfung von Aktualisierungen auf dem Desktop

Seit Debian 4.0 Lenny gibt es in Debian update-notifier, das in einer Standardinstallation installiert wird. Es ist eine GNOME-Anwendung, die beim Starten des Desktops mitgestartet wird. Sie kann geprüft, welche Aktualisierungen für Ihr System zur Verfügung stehen, und diese installieren. Dafür verwendet es update-manager.

In dem Stable-Zweig gibt es Aktualisierungen nur zum Entfernen von Sicherheitsproblemen oder dann, wenn eine Zwischenveröffentlichung (point release) angeboten wird. Wenn das System richtig konfiguriert ist, um Sicherheitsaktualisierungen zu erhalten (wie in Ausführen von Sicherheitsupdates, Abschnitt 4.2 beschrieben), und Sie mit cron die Paketinformationen aktualisieren, werden Sie durch ein Desktop-Symbol in dem Benachrichtigungsbereich des Desktops über Aktualisierungen informiert werden.

Diese Benachrichtigung ist nicht aufdringlich und zwingt den Benutzer nicht dazu, die Aktualisierungen zu installieren. Über das Symbol kann der Desktop-Benutzer (mit dem Passwort des Systemadministrators) zu einer einfachen graphischen Benutzeroberfläche gelangen, um sich die verfügbaren Aktualisierungen anzeigen zu lassen und zu installieren.

Diese Anwendung arbeitet damit, dass sie die Paketdatenbank abruft und ihren Inhalt mit dem System vergleicht. Wenn die Datenbank regelmäßig mit cron aktualisiert wird, ist ihr Inhalt aktueller als die auf dem System installierten Pakete, worauf die Anwendung Sie hinweisen wird.

Apt richtet eine solche Aufgabe ein (/etc/cron.d/apt), die abhängig von der Konfiguration von Apt ausgeführt wird (genauer gesagt je nach APT::Periodic). In der GNOME-Umgebung kann dieser Wert über System > Admin > Software origins > Updates oder mit /usr/bin/software-properties geändert werden.

Wenn Ihr System täglich die Paketliste herunterladen soll, aber nicht die Pakete selbst, sollte /etc/apt/apt.conf.d/10periodic etwa so aussehen:

     APT::Periodic::Update-Package-Lists "1";
     APT::Periodic::Download-Upgradeable-Packages "0";

Sie können auch eine andere cron-Aufgabe verwenden, z.B. die von cron-apt installierte (vgl. Automatisches Überprüfung von Aktualisierungen mit cron-apt, Abschnitt 10.1.2.3). Damit können Sie auch nur per Hand nach Aktualisierungen suchen.

Benutzer der KDE-Umgebung sollten stattdessen adept und adept-notifier installieren, die vergleichbare Funktionen anbieten, aber nicht in der Standardinstallation enthalten sind.


10.1.2.3 Automatisches Überprüfung von Aktualisierungen mit cron-apt

Eine andere Methode für automatische Sicherheitsaktualisierungen ist cron-apt. Dieses Paket stellt ein Werkzeug zur Verfügung, mit dem das System in regelmäßigen Abständen (mit einem Cronjob) aktualisiert wird. Es kann so konfiguriert werden, dass es E-Mails mit dem lokalen Mail-Transport-Agent an den Systemadministrator schickt. Standardmäßig wird es nur die Paketliste aktualisieren und neue Pakete herunterladen. Es kann aber so konfiguriert werden, dass es automatisch Aktualisierungen installiert.

Hinweis: Wenn Sie vorhaben, Ihr System automatisch zu aktualisieren (auch wenn Sie sich nur die Pakete herunterladen), sollten Sie sich vielleicht die Distributionsveröffentlichung ansehen, wie in Überprüfung der Distribution mit der Release-Datei, Abschnitt 7.4.3 beschrieben wird. Anderenfalls können Sie sich nicht sicher sein, dass die heruntergeladenen Pakete wirklich aus einer vertrauenswürdigen Quelle stammen.

Weitere Informationen finden Sie auf der Debian-Administration-Site.


10.1.2.4 Automatisches Überprüfung von Aktualisierungen mit debsecan

Das Programm debsecan ermittelt den Sicherheitsstatus, indem es sowohl nicht installierte Sicherheitsaktualisierungen als auch Sicherheitslücken meldet. Im Gegensatz zu cron-apt, das nur Informationen zu verfügbaren Sicherheitsaktualisierungen bereitstellt, bezieht dieses Werkzeug auch Informationen von der Datenbank über Sicherheitslücken, die von Debians Sicherheitsteam verwaltet wird. Darin befinden sich auch Informationen über Lücken, die noch nicht durch eine Sicherheitsaktualisierung geschlossen wurden. Daher kann es Administratoren besser helfen, Sicherheitslücken im Blick zu behalten (wie unter Beobachtung von Sicherheitslücken, Abschnitt 10.1.1 beschrieben).

Nach der Installation des Debian-Pakets debsecan wird es mit Zustimmung des Administrators eine cron-Aufgabe erstellen, die das Programm aufruft und das Ergebnis an einen bestimmten Benutzer schickt, wenn sie ein verwundbares Paket findet. Sie wird auch Informationen aus dem Internet laden. Bei der Installation wird auch nach dem Ort der Sicherheitsdatenbank gefragt, dieser wird in /etc/default/debsecan gespeichert. Er kann leicht so angepasst werden, damit Systeme ohne Internetzugang auf einen lokale Spiegelserver zugreifen können und nur dieser mit der Sicherheitsdatenbank verbunden sein muss.

Beachten Sie jedoch, dass das Sicherheitsteam viele Verwundbarkeiten aufführt, die (wie risikoarme Probleme) nicht mit einer Sicherheitsaktualisierung ausgebessert werden oder bei denen sich später herausstellt, dass sie, anders als zunächst angenommen, Debian nicht betreffen. Debsecan wird alle Verwundbarkeiten melden, wodurch diese Meldungen deutlich umfangreicher werden als bei den anderen beschriebenen Werkzeugen.

Weitere Informationen finden Sie auf der Site des Autors.


10.1.2.5 Andere Methoden für Sicherheitsaktualisierungen

Es gibt auch apticron, das ähnlich wie cron-apt nach Aktualisierungen sucht und eine E-Mail an den Administrator schickt. Weitere Informationen über apticron finden Sie auf der Site über Debian-Administration.

Sie können auch einen Blick auf secpack werfen. Es ist ein inoffizielles Programm, um Sicherheitsaktualisierungen von security.debian.org mit Prüfung der Signatur durchzuführen. Es wurde von Fruhwirth Clemens geschrieben. Eine weitere Alternative bietet die Nagios-Erweiterung check_debian_updates.sh von Dean Wilson.


10.1.3 Vermeiden Sie den Unstable-Zweig

Falls Sie nicht Zeit darauf verwenden wollen, selbst Pakete zu patchen, wenn Verwundbarkeiten entdeckt werden, sollten Sie auf produktiven Systemen nicht Debians Unstable-Zweig verwenden. Der Hauptgrund dafür ist, dass es für Unstable keine Sicherheitsaktualisierungen gibt (siehe Wie wird die Sicherheit für Testing und Unstable gehandhabt?, Abschnitt 12.3.8).

Es ist eine Tatsache, dass manche Sicherheitsprobleme nur in Unstable auftreten und nicht in Stable. Das rührt daher, dass dort ständig neue Funktionen zu den Anwendungen hinzugefügt werden und auch neue Anwendungen aufgenommen werden, die unter Umständen noch nicht vollständig getestet wurden.

Um im Unstable-Zweig Sicherheitsaktualisierungen durchzuführen, müssen Sie vielleicht eine vollständige Aktualisierung mit einer neuen Version durchführen (was viel mehr als nur das betroffene Pakete aktualisieren könnte). Sicherheitsaktualisierungen wurden – mit Ausnahmen – nur in den Stable-Zweig zurückportiert. Die Grundidee ist, dass zwischen den Aktualisierungen kein neuer Code hinzugefügt werden sollte, sondern nur Beseitigungen von wichtigen Problemen.

Denken Sie daran, dass Sie allerdings den Sicherheitstracker verwenden können (wie unter Beobachtung von Sicherheitslücken, Abschnitt 10.1.1 beschrieben), um bekannte Sicherheitsprobleme für diesen Zweig nachzuvollziehen.


10.1.4 Sicherheitsunterstützung für den Testing-Zweig

Wenn Sie den Testing-Zweig verwenden, müssen Sie einige Problemkreise hinsichtlich der Verfügbarkeit von Sicherheitsaktualisierungen in Betracht ziehen:

Dieses Verhalten könnte sich je nach dem Status der Veröffentlichung der Distribution verändern. Wenn eine Veröffentlichung unmittelbar bevorsteht, werden auch das Sicherheitsteam oder die Paketbetreuer direkt Aktualisierungen für Testing zur Verfügung stellen.

Zusätzlich kann auch das Debian-Testing-Sicherheitsteam Debian-Testing-Sicherheitsankündigungen (DTSA) für Pakete im Testing-Zweig herausgeben, wenn sofort eine Lücke in diesem Zweig geschlossen werden muss und die normale Vorgehensweise nicht abgewartet werden kann (oder die übliche Vorgehensweise durch andere Pakete blockiert ist).

Benutzer, die von diesem Angebot Gebrauch machen wollen, müssen folgende Zeilen ihrer /etc/apt/sources.list (anstatt der Zeilen, die unter Ausführen von Sicherheitsupdates, Abschnitt 4.2 dargestellt wurden) hinzufügen:

     deb http://security.debian.org testing/updates main contrib non-free
     # Diese Zeile macht es möglich, auch Quellpakete herunterzuladen
     deb-src  http://security.debian.org testing/updates main contrib non-free

Für weitere Informationen zu diesem Angebot können Sie die entsprechende Ankündigung lesen. Dieses Angebot startete offiziell im September 2005 als zusätzliches Paketdepot und wurde später in das allgemeine Sicherheitsarchiv integriert.


10.1.5 Automatische Aktualisierungen in einem Debian GNU/Linux System

Es sei vorweggeschickt, dass automatische Aktualisierungen nicht vollständig empfohlen werden, da Administratoren die DSAs durchsehen und die Bedeutung einer bestimmten Sicherheitsaktualisierung verstehen sollten.

Wenn Sie Ihr System automatisch aktualisieren wollen, sollten Sie Folgendes durchführen:

Eine sichere Alternative könnte es sein, die Option -d (oder --download-only) zu verwenden. Das hat zur Folge, dass die benötigten Pakete nur heruntergeladen, aber nicht installiert werden. Und wenn dann die Ausführung von cron zeigt, dass das System aktualisiert werden muss, kann das von Hand vorgenommen werden.

Um diese Aufgaben zu erfüllen, muss das System korrekt konfiguriert sein, um Sicherheitsaktualisierungen herunterzuladen. Dies wurde in Ausführen von Sicherheitsupdates, Abschnitt 4.2 diskutiert.

Allerdings wird dieses Vorgehen ohne eine genaue Analyse nicht für Unstable empfohlen, da Sie Ihr System in einen unbrauchbaren Zustand bringen können, wenn sich ein gravierender Fehler in ein wichtiges Paket eingeschlichen hat und auf Ihrem System installiert wird. Testing ist vor diesem Problem etwas besser geschützt, da gravierende Fehler eine bessere Chance haben entdeckt zu werden, bevor das Paket in den Testing-Zweig wandert (obwohl Ihnen trotzdem keine Sicherheitsaktualisierungen zur Verfügung stehen).

Wenn Sie eine gemischte Distribution haben, also eine Installation von Stable mit einige Pakete aus Testing oder Unstable, können Sie mit den Pinning-Eigenschaften oder der Option --target-release von apt-get herumspielen, um nur die Pakete zu aktualisieren, die Sie früher aktualisiert haben.[73]


10.2 Periodische Überprüfung der Integrität

Mit Hilfe der Basisinformationen, die Sie nach der Installation erstellt haben (also mit dem Schnappschuss, der in Einen Schnappschuss des Systems erstellen, Abschnitt 4.19 beschrieben wird, sollte es Ihnen möglich sein, von Zeit zu Zeit die Integrität des Systems zu überprüfen. Eine Integritätsprüfung kann Veränderungen am Dateisystem entdecken, die durch einen Eindringling oder einen Fehler des Systemadministrators entstanden sind.

Überprüfungen der Integrität sollen, wenn möglich, von außerhalb durchgeführt werden.[74] Das bedeutet, dass das Betriebssystem des überprüften Systems nicht verwendet wird, um den falschen Eindruck von Sicherheit (also falsche Negative) zu verhindern, der z.B. durch installierte Rootkits entstehen könnte. Die Datenbank, mit der das System verglichen wird, sollte sich daher auf einem nur-lesbaren Medium befinden.

Falls der Einsatz eines außenstehenden Systems keine Möglichkeit ist, sollten Sie in Betracht ziehen, die Integritätsprüfung mit den verfügbaren Werkzeugen zur Prüfung der Integrität des Dateisystem durchzuführen. Allerdings sollten Vorsichtsmaßnahmen getroffen werden: Die Datenbank für die Integritätsprüfung sollte nur-lesbar sein, und Sie sollten auch sicherstellen, dass das Programm, das die Integrität überprüft, (und der Kernel des Betriebssystems) nicht manipuliert wurde.

Einige Werkzeuge, die im Abschnitt über Programme zur Integritätsprüfung beschrieben wurden, wie z.B. aide, integrit und samhain, sind schon so eingerichtet, dass sie regelmäßige Nachprüfungen durchführen (mittels crontab in den ersten beiden Fällen und mittels eines eigenständigen Daemons bei samhain). Sie können den Administrator auf verschiedenen Wegen warnen (normalerweise E-Mail, aber samhain kann auch Seiten, SNMP-Traps oder einen Alarm an syslog schicken), wenn sich das Dateisystem verändert.

Wenn Sie eine Sicherheitsaktualisierung des System vorgenommen haben, müssen Sie natürlich den Schnappschuss des Systems neu aufzeichnen, um ihn an die Änderungen durch die Sicherheitsaktualisierung anzupassen.


10.3 Aufsetzen einer Eindringlingserkennung

Debian GNU/Linux enthält Programme zur Erkennung von Eindringlingen. Das sind Programme, die unpassende oder bösartige Aktivitäten auf Ihrem lokalen System oder auf anderen System in Ihrem lokalen Netzwerk entdecken. Diese Art von Verteidigung ist wichtig, wenn das System sehr entscheidend ist oder Sie wirklich unter Verfolgungswahn leiden. Die gebräuchlichsten Herangehensweisen sind die statistische Entdeckung von Unregelmäßigkeiten und die Entdeckung bestimmter Muster.

Beachten Sie immer, dass Sie einen Alarm-und-Antwort-Mechanismus brauchen, um Ihre Systemsicherheit mit einer dieser Werkzeuge wirklich zu verbessern. Eindringlingserkennung ist Zeitverschwendung, wenn Sie niemanden alarmieren werden.

Wenn ein bestimmter Angriff entdeckt worden ist, werden die meisten Programme zur Eindringlingserkennung entweder den Vorfall mit syslog protokollieren oder E-Mails an Root schicken (der Empfänger der E-Mails kann normalerweise eingestellt werden). Ein Administrator muss die Programme passend konfigurieren, so dass falsche Positivmeldungen keinen Alarm auslösen. Alarme können auf einen laufenden Angriff hindeuten und wären später – sagen wir mal am nächsten Tag – nicht mehr nützlich, da der Angriff dann bereits erfolgreich beendet worden sein könnte. Stellen Sie also sicher, dass es eine passende Regelung über die Handhabung von Alarmen gibt, und dass technische Maßnahmen zur Umsetzung dieser Regelung vorhanden sind.

Eine interessante Quelle für Information ist CERT's Intrusion Detection Checklist


10.3.1 Netzwerk basierende Eindringlingserkennung

Programme, die der Netzwerk basierende Eindringlingserkennung dienen, überwachen den Verkehr eines Netzwerkabschnitts und arbeiten auf Grundlage dieser Daten. Genauer ausgedrückt, es werden die Pakete im Netzwerk untersucht, um festzustellen, ob sie mit bestimmten Merkmalen übereinstimmen.

snort ist ein vielseitiger Paketschnüffler oder -logger, der Angriffe mit Hilfe einer Bibliothek von Angriffssignaturen erkennt. Es erkennt eine breite Palette von Angriffen und Tests, wie zum Beispiel Pufferüberläufe, verdecktes Abtasten von Ports (stealth port scans), CGI Angriffe, SMB Tests und vieles mehr. snort hat auch die Fähigkeit, einen zeitnahen Alarm auszulösen. Dies ist ein Werkzeug, das auf jedem Router installiert werden sollte, um ein Auge auf Ihr Netzwerk zu haben. Installieren Sie es einfach mit apt-get install snort, beantworten Sie die Fragen und beobachten Sie die Protokolle. Für einen etwas breiteren Sicherheitsrahmen sollten Sie sich Prelude ansehen.

Debians Paket snort hat viele Sicherheitstests standardmäßig eingeschaltet. Jedoch sollten Sie die Konfiguration anpassen, um die Dienste, die auf Ihrem System laufen, zu berücksichtigen. Sie können auch zusätzliche Tests speziell für diese Dienste nutzen.

Es gibt noch andere, einfachere Werkzeuge, die dazu benutzt werden können, Angriffe auf das Netzwerk zu erkennen. portsentry ist ein interessantes Paket, das Sie warnen kann, wenn jemand Ihre Rechner scannt. Auch andere Programme wie ippl oder iplogger erkennen bestimmte IP (TCP und ICMP) Angriffe, auch wenn sie nicht so fortgeschrittene Techniken zur Erkennung von Netzwerkangriffen wie snort bieten.

Sie können jedes dieser Werkzeuge mit dem Paket idswakeup testen. Das ist ein Shell-Skript, das falsche Alarme verursacht und Signaturen vieler gebräuchlicher Angriffe enthält.


10.3.2 Host basierende Eindringlingserkennung

Eine Eindringlingserkennung, die auf einem Host basiert, beruht darauf, Software auf dem zu überwachenden System zu laden, die Log-Dateien und die Auditing-Programme des Systems als Datengrundlage verwendet. Sie sucht nach verdächtigen Prozessen, kontrolliert den Zugang zum Host und überwacht u.U. auch Änderungen an kritischen Systemdateien.

tiger ist ein älteres Programm zur Eindringlingserkennung, dass seit der Woody-Distribution auf Debian portiert wurde. tiger bietet Tests von verbreiteten Problemen in Zusammenhang mit Einbrüchen, wie der Stärke von Passwörtern, Problemen mit dem Dateisystem, kommunizierenden Prozessen und anderen Möglichkeiten, mit denen Root kompromittiert werden könnte. Dieses Paket umfasst neue, debianspezifische Sicherheitstests, einschließlich der MD5-Summen von installierten Programmen, des Orts von Dateien, die zu keinem Paket gehören und einer Analyse von lokalen, lauschenden Prozessen. Die Standardinstallation lässt tiger einmal am Tag laufen und einen Bericht erstellen, der an den Superuser geschickt wird und Informationen zu möglichen Kompromittierungen enthält.

Programme zur Protokollanalyse, wie zum Beispiel logcheck können zusätzliche benutzt werden, um Einbruchsversuche zu erkennen. Siehe Nutzung und Anpassung von logcheck, Abschnitt 4.13.1.

Daneben können Pakete, die die Integrität des Dateisystems überwachen (siehe Prüfung der Integrität des Dateisystems, Abschnitt 4.17.3), sehr nützlich sein, um Anomalien in einer abgesicherten Umgebung zu erkennen. Ein erfolgreicher Einbruch wird höchstwahrscheinlich Dateien auf dem lokalen Dateisystem verändern, um die lokalen Sicherheitsregelungen zu umgehen, Trojaner zu installieren oder Nutzer zu erstellen. Solche Ereignisse können mit Prüfwerkzeugen der Dateisystemintegrität erkannt werden.


10.4 Vermeiden von Root-Kits


10.4.1 Ladbare Kernel-Module (LKM)

Ladbare Kernel-Module sind Dateien, die nachladbare Teile des Kernels enthalten. Sie werden dazu verwendet, die Funktionalität des Kernel zu erweitern. Der Hauptnutzen des Einsatzes von Modulen liegt darin, dass Sie zusätzliche Geräte wie eine Ethernet- oder Soundkarte hinzuzufügen können, ohne dass die Kernelquelle gepatcht und der gesamte Kernel neu übersetzt werden müsste. Allerdings können Cracker LKMs für Root-Kits (knark und adore) benutzen, um auf GNU/Linux Systemen Hintertüren zu öffnen.

LKM-Hintertüren sind ausgeklügelter und schwere zu entdecken als traditionelle Root-Kits. Sie können Prozesse, Dateien, Verzeichnisse und sogar Verbindungen verstecken, ohne den Quellcode der Programme verändern zu müssen. Zum Beispiel kann ein bösartiges LKM den Kernel dazu zwingen, bestimmte Prozesses vor procfs zu verstecken, so dass nicht einmal eine bekanntermaßen gute Kopie des Programms ps alle Informationen über die aktuellen Prozesse korrekt auflisten.


10.4.2 Erkennen von Root-Kits

Es gibt zwei Herangehensweisen, um Ihr System gegen LKM-Root-Kits zu verteidigen: die aktive Verteidigung und die reaktive Verteidigung. Die Sucharbeit kann einfach und schmerzlos sein, oder schwierig und ermüdend, ganz abhängig von der Maßnahme, die Sie ergreifen.


10.4.2.1 Aktive Verteidigung

Der Vorteil dieser Art der Verteidigung ist, dass schon verhindert wird, dass das System Schaden nimmt. Eine mögliche Strategie ist das Ziel zuerst zu erreichen, also ein LKM zu laden, das dazu da ist, das System vor anderen böswilligen LKMs zu schützen. Eine andere Maßnahme ist es, dem Kernel Fähigkeiten zu entziehen. Zum Beispiel können Sie aus dem Kernel vollständig die Fähigkeit von ladbaren Kernel-Modulen entfernen. Beachten Sie allerdings, dass es Root-Kits gibt, die selbst in diesen Fällen funktionieren. Es gibt auch welche, die direkt /dev/kmem (Kernelspeicher) manipulieren, um sich zu verstecken.

Debian GNU/Linux hat ein paar Pakete, die dazu verwendet werden können, eine aktive Verteidigung aufzusetzen:

Wenn Sie diese vielen Möglichkeiten auf Ihrem GNU/Linux System nicht wirklich brauchen, sollten Sie die Unterstützung für ladbare Module während der Konfiguration des Kernels abschalten. Das erreichen Sie, indem Sie einfach CONFIG_MODULES=n während des Konfiguration Ihres Kernels oder in der Datei .config festsetzen. So werden LKM Root-Kits vermieden, aber Sie verlieren eine leistungsfähige Eigenschaft des Linux-Kernels. Außerdem kann das Abschalten der nachladbaren Module den Kernel überladen, so dass die Unterstützung ladbarer Module notwendig wird.


10.4.2.2 Reaktive Verteidigung

Der Vorteil reaktiver Verteidigung ist, dass sie die Systemressourcen nicht überlädt. Sie funktioniert durch das Vergleichen von einer Tabelle der Systemaufrufe mit einer bekanntermaßen sauberen Kopie (System.map). Eine reaktive Verteidigung kann den Systemadministrator natürlich nur benachrichtigen, wenn das System bereits kompromittiert wurde.

Die Entdeckung von Root-Kits vollbringt unter Debian chkrootkit. Das Programm Chkrootkit prüft Anzeichen von bekannten Root-Kits auf dem Zielsystem. Es ist aber kein völlig sicherer Test.


10.5 Geniale/paranoide Ideen — was Sie tun können

Dies ist wahrscheinlich der unsicherste und lustigste Abschnitt, da ich hoffe, dass manche der »Wow, das klingt verrückt«-Ideen umgesetzt werden. Im folgenden werden nur ein paar Ideen vorgestellt, wie Sie Ihre Sicherheit erhöhen können — abhängig von Ihrem Standpunkt aus können Sie sie für genial, paranoid, verrückt oder sicher halten,


10.5.1 Aufstellen eines Honigtopfes (honeypot)

Ein Honigtopf ist ein System, das darauf ausgelegt ist, Systemadministratoren beizubringen, wie Cracker ein System abtasten und darin einbrechen. Es ist eine Systemeinstellung mit der Erwartung und dem Zweck, dass das System abgetastet und angegriffen und möglicherweise darin eingebrochen wird. Wenn Systemadministratoren erfahren, welche Werkzeuge und Methoden Cracker anwenden, können sie daraus lernen, wie sie ihr System und Netzwerk besser schützen.

Debian GNU/Linux-Systeme können leicht als Honigtopf eingerichtet werden, wenn Sie Zeit opfern, sie aufzusetzen und zu überwachen. Sie können leicht den gefälschten Server, die Firewall[77], die den Honigtopf überwacht, und ein Programm, das Eindringling ins Netzwerk entdecken kann, einrichten. Verbinden Sie den Honigtopf mit dem Internet und warten Sie ab. Stellen Sie sicher, dass Sie rechtzeitig alarmiert werden (siehe Die Wichtigkeit von Logs und Alarmen, Abschnitt 4.13), wenn in das System eingedrungen wird, damit Sie geeignete Schritte einleiten und den Angriff beenden können, wenn Sie genug gesehen haben. Hier folgen einige Pakete und Probleme, die Sie in Betracht ziehen sollten, wenn Sie einen Honigtopf einrichten:

Falls Sie kein System übrig haben, um die Honigtöpfe und Systeme, die das Netzwerk schützen und kontrollieren, zu bauen, können Sie die Technologie zur Virtualisierung einsetzen, die in xen oder uml (User-Mode-Linux) enthalten ist. Wenn Sie diesen Weg wählen, müssen Sie Ihren Kernel entweder mit kernel-patch-xen oder kernel-patch-uml patchen.

Sie können mehr über das Aufstellen eines Honigtopfs in Lanze Spitzners exzellentem Artikel To Build a Honeypot (aus der Know your Enemy Serie). Außerdem stellt das Honeynet Project wertvolle Informationen über das Aufstellen von Honigtöpfen und der Analyse von Angriffen auf sie zur Verfügung.


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]


Anleitung zum Absichern von Debian

Version: 3.11, Mon, 10 Feb 2014 17:05:54 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Autoren, Abschnitt 1.1