<!-- CVS revision of original english document "1.24" -->

<chapt>Vor der Kompromittierung

<sect id="keep-secure">Halten Sie Ihr System sicher

<p>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).


<sect1 id="track-vulns">Beobachtung von Sicherheitslücken

<p>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.

<p>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 <url id="http://httpd.apache.org/security_report.html" name="Auflistung
von Sicherheitslücken"> durchsehen und die Mailingliste <url
id="http://httpd.apache.org/lists.html#http-announce" name="Ankündigungen für
den Apache-Server"> abonnieren.

<p>Um bekannte Sicherheitslücken, die die Debian-Distribution betreffen, zu
verfolgen, bietet das Testing-Security-Team von Debian einen <url
id="http://security-tracker.debian.net/" name="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
<url id="http://www.debian.org/Bugs/" name="Fehlerdatenbank von
Debian">. Administratoren können nach bekannten Sicherheitsmängeln für <url
id="http://security-tracker.debian.net/tracker/status/release/stable"
name="Stable">, <url
id="http://security-tracker.debian.net/tracker/status/release/oldstable"
name="Oldstable">, <url
id="http://security-tracker.debian.net/tracker/status/release/testing"
name="Testing"> oder <url
id="http://security-tracker.debian.net/tracker/status/release/unstable"
name="Unstable"> suchen.

<p>Der Tracker kann mittels einer Benutzerschnittstelle durchsucht werden (nach
<url id="http://cve.mitre.org/" name="CVE">-Namen und dem Paketnamen). Einige
Werkzeuge (wie zum Beispiel <package>debsecan</package>, vgl. <ref id="debsecan">) setzen diese Datenbank ein, um auf Verwundbarkeiten des
betreffenden Systems hinzuweisen, die noch nicht ausgebessert wurden (d.h. für
die eine Ausbesserung bevorsteht).

<p>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.

<p>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 <ref id="keep-up-to-date">). 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 <url
id="http://www.de.debian.org/security/crossreferences" name="Querverweise für
Debian-Sicherheitsankündigungen"> verwenden.

<p>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.


<sect1 id="keep-up-to-date">Fortlaufende Aktualisierung des Systems

<p>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 <url
id="http://www.cs.umd.edu/~waa/vulnerability.html" name="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 <ref
id="security-update"> beschrieben.


<sect2>Überprüfung von Hand, welche Sicherheitsaktualisierungen verfügbar sind

<p>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.

<p>Wenn Sie Ihr System nach der Beschreibung unter <ref id="security-update">
eingerichtet haben, müssen Sie nur Folgendes tun:

<example>
# 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 ... ]
</example>

<p>Weiter müssen alle Dienste, deren Bibliotheken aktualisiert wurden, neu
gestartet werden. Bemerkung: Lesen Sie <ref id="security-update"> für weitere
Informationen zu Bibliotheks- (und Kernel-)Aktualisierungen.

<p>Die erste Zeile wird die Liste der verfügbaren Pakete von den festgelegten
Paketquellen herunterladen. Die Option <tt>-s</tt> wird eine Simulation
durchführen, d.h. es werden <em>keine</em> 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:

<example>
# 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)
</example>

<p>In diesem Beispiel können Sie erkennen, dass auf dem System <package>cvs</package> und <package>cupsys</package>
mit neuen Versionen aus <em>Woodys</em> Sicherheitsarchiv aktualisiert werden
müssen. Um herauszufinden, warum eine Aktualisierung notwendig ist, sollten Sie
<url id="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 <url
id="http://www.debian.org/security/2003/dsa-233" name="DSA-233"> (für <package>cvs</package>) und
<url id="http://www.debian.org/security/2003/dsa-232" name="DSA-232"> (für
<package>cupsys</package>).

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

<sect2 id="update-desktop">Überprüfung von Aktualisierungen auf dem Desktop

<p>Seit Debian 4.0 <em>Lenny</em> gibt es in
Debian <package>update-notifier</package>, 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 <package>update-manager</package>.

<p>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 <ref id="security-update"> beschrieben), und Sie
mit <prgn>cron</prgn> die Paketinformationen aktualisieren, werden Sie
durch ein Desktop-Symbol in dem Benachrichtigungsbereich des Desktops
über Aktualisierungen informiert werden.

<p>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.

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

<p><prgn>Apt</prgn> richtet eine solche Aufgabe ein
(<file>/etc/cron.d/apt</file>), die abhängig von der Konfiguration von
Apt ausgeführt wird (genauer gesagt je
nach <em>APT::Periodic</em>). In der GNOME-Umgebung kann dieser Wert
über System &gt; Admin &gt; Software origins &gt; Updates oder
mit <prgn>/usr/bin/software-properties</prgn> geändert werden.
<!-- SB(20140124): Wie heißen die Menüeinträge auf Deutsch? -->

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

<example>
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
</example>

<p>Sie können auch eine andere cron-Aufgabe verwenden, z.B. die
von <package>cron-apt</package> installierte
(vgl. <ref id="cron-apt">). Damit können Sie auch nur per Hand nach
Aktualisierungen suchen.

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

<sect2 id="cron-apt">Automatisches Überprüfung von Aktualisierungen mit
cron-apt

<p>Eine andere Methode für automatische Sicherheitsaktualisierungen
ist <package>cron-apt</package>. 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.

<p>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 <ref id="check-releases"> beschrieben wird. Anderenfalls können Sie
sich nicht sicher sein, dass die heruntergeladenen Pakete wirklich aus
einer vertrauenswürdigen Quelle stammen.

<p>Weitere Informationen finden Sie auf
der <url id="http://www.debian-administration.org/articles/162"
name="Debian-Administration-Site">.

<sect2 id="debsecan">Automatisches Überprüfung von Aktualisierungen
mit debsecan

<p>Das Programm <prgn>debsecan</prgn> ermittelt den Sicherheitsstatus,
indem es sowohl nicht installierte Sicherheitsaktualisierungen als
auch Sicherheitslücken meldet. Im Gegensatz
zu <package>cron-apt</package>, 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 <ref id="track-vulns"> beschrieben).

<p>Nach der Installation des Debian-Pakets <package>debsecan</package>
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 <file>/etc/default/debsecan</file> 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.

<p>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. <prgn>Debsecan</prgn> wird alle
Verwundbarkeiten melden, wodurch diese Meldungen deutlich
umfangreicher werden als bei den anderen beschriebenen Werkzeugen.

<p>Weitere Informationen finden Sie auf
der <url id="http://www.enyo.de/fw/software/debsecan/" name="Site des
Autors">.

<sect2>Andere Methoden für Sicherheitsaktualisierungen

<p>Es gibt auch <package>apticron</package>, das ähnlich
wie <package>cron-apt</package> nach Aktualisierungen sucht und eine
E-Mail an den Administrator schickt. Weitere Informationen über
apticron finden Sie auf
der <url id="http://www.debian-administration.org/articles/491"
name="Site über Debian-Administration">.

<p>Sie können auch einen Blick auf <url
id="http://clemens.endorphin.org/secpack/" name="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
<url id="http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages"
name="check_debian_updates.sh"> von Dean Wilson.


<sect1>Vermeiden Sie den Unstable-Zweig

<p>Falls Sie nicht Zeit darauf verwenden wollen, selbst Pakete zu patchen, wenn
Verwundbarkeiten entdeckt werden, sollten Sie auf produktiven Systemen
<em>nicht</em> Debians Unstable-Zweig verwenden. Der Hauptgrund dafür ist, dass
es für <em>Unstable</em> keine Sicherheitsaktualisierungen gibt.

<p>Es ist eine Tatsache, dass manche Sicherheitsprobleme nur in Unstable
auftreten und <em>nicht</em> in <em>Stable</em>. 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.

<p>Um im <em>Unstable</em>-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 &ndash; mit Ausnahmen &ndash; nur in den
<em>Stable</em>-Zweig zurückportiert. Die Grundidee ist, dass zwischen den
Aktualisierungen <em>kein neuer Code</em> hinzugefügt werden sollte, sondern
nur Beseitigungen von wichtigen Problemen.

<p>Denken Sie daran, dass Sie allerdings den Sicherheitstracker verwenden
können (wie unter <ref id="track-vulns"> beschrieben), um bekannte
Sicherheitsprobleme für diesen Zweig nachzuvollziehen.


<sect1 id="security-support-testing">Sicherheitsunterstützung für den
Testing-Zweig

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

<list>

<item>Wenn eine Sicherheitslücke geschlossen wurde, portiert das Security Team
den Patch nach <em>Stable</em> zurück (da Stable normalerweise einige Minor-
oder Majorversionen zurückliegt). Die Paketbetreuer sind dafür verantwortlich,
Pakete für den <em>Unstable</em>-Zweig vorzubereiten. Grundlage dafür ist
normalerweise eine neue Veröffentlichung des Originalprogramms. Manchmal
ereignen sich die Änderungen fast zur selben Zeit, und manchmal enthält eine
der Veröffentlichungen eine Ausbesserung einer Sicherheitslücke vor einer
anderen. Pakete in <em>Stable</em> werden gründlicher getestet als die in
<em>Unstable</em>, da letztere in den meisten Fällen die neueste
Veröffentlichung des Originalprogramms enthält (welches neue, unbekannte Fehler
enthalten könnte).

<item>Gewöhnlich sind Sicherheitsaktualisierungen für den
<em>Unstable</em>-Zweig verfügbar, wenn der Paketbetreuer ein neues Paket
baut, und für den <em>Stable</em>-Zweig, wenn das Security Team eine neue
Version hochlädt und ein DSA veröffentlicht. Beachten Sie, dass beides nicht
des <em>Testing</em>-Zweig verändert.

<item>Wenn keine (neuen) Fehler in der <em>Unstable</em>-Version des Pakets
entdeckt werden, wandert es nach ein paar Tagen nach <em>Testing</em>. Das
dauert normalerweise zehn Tage. Es hängt allerdings von der Priorität des
Hochladens der Veränderung ab und davon, ob das Paket von <em>Testing</em>
zurückgehalten wird, da Abhängigkeiten nicht aufgelöst werden können. Beachten Sie,
dass wenn das Paket daran gehindert ist, nach Testing zu wandern, auch die
Priorität des Hochladens daran nichts ändern kann.

</list>

<p>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.

<p>Zusätzlich kann auch das <url id="http://secure-testing-master.debian.net"
name="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).

<p>Benutzer, die von diesem Angebot Gebrauch machen wollen, müssen folgende
Zeilen ihrer <file>/etc/apt/sources.list</file> (anstatt der Zeilen, die unter
<ref id="security-update"> dargestellt wurden) hinzufügen:

<example>
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
</example>

<p>Für weitere Informationen zu diesem Angebot können Sie die entsprechende
<url id="http://lists.debian.org/debian-devel-announce/2006/05/msg00006.html"
name="Ankündigung"> lesen. Dieses Angebot startete offiziell
im <url id="http://lists.debian.org/debian-devel-announce/2005/09/msg00006.html"
name="September 2005"> als zusätzliches Paketdepot und wurde später in
das allgemeine Sicherheitsarchiv integriert.

<sect1>Automatische Aktualisierungen in einem Debian GNU/Linux System

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

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

<list>

<item>Konfigurieren Sie <prgn>apt</prgn> so, dass Pakete, die Sie nicht
aktualisieren wollen, ihrer momentane Version beibehalten. Das können Sie
entweder mit einer Eigenschaft von <prgn>apt</prgn>, dem <em>pinning</em>
(festheften), erreichen, oder Sie kennzeichnen sie mit <prgn>dpkg</prgn> oder
<prgn>dselect</prgn> als <em>hold</em> (festgehalten).

<p>Um Pakete einer bestimmten Veröffentlichung mit pinning festzuheften, müssen
Sie <file>/etc/apt/preferences</file> bearbeiten (siehe <manref section="5"
name="apt_preferences">) und Folgendes hinzufügen:

<example>
  Package: *
  Pin: release a=stable
  Pin-Priority: 100
</example>
<p>FIXME: verify if this configuration is OK.

<item>Entweder setzen Sie <package>cron-apt</package> ein, wie in <ref id="cron-apt"> beschrieben
wird, und erlauben ihm, heruntergeladene Pakete zu installieren. Oder Sie fügen
selbst einen Eintrag für <prgn>cron</prgn> hinzu, damit die Aktualisierung
täglich ausgeführt wird. Ein Beispiel:

<example>
  apt-get update && apt-get -y upgrade
</example>

<p>Die Option <tt>-y</tt> veranlasst <prgn>apt</prgn>, für alle Fragen, die
während der Aktualisierung auftreten können, 'yes' anzunehmen. In manchen
Fällen sollten Sie die Option <tt>--trivial-only</tt> (nur Bagatellen) der
Option <tt>--assume-yes</tt> (ist gleichbedeutend mit <tt>-y</tt>)
vorziehen.<footnote>
Sie können auch die Option <tt>--quiet</tt> (<tt>-q</tt>) verwenden. Sie
verringert die Ausgabe von <prgn>apt-get</prgn> und wird keine Ausgabe
produzieren, wenn keine Pakete installiert werden.
</footnote>

<item>Richten Sie <prgn>debconf</prgn> so ein, dass während
der Aktualisierung keine Eingabe verlangt wird. Auf diese Weise können
Aktualisierungen nicht-interaktiv durchgeführt werden.<footnote>
Beachten Sie, dass einige Pakete <em>nicht</em> <prgn>debconf</prgn> verwenden
könnten. Die Aktualisierung könnte dann hängen bleiben, da Pakete während
ihrer Konfiguration Eingaben des Nutzers verlangen.
</footnote>

<item>Überprüfen Sie die Ergebnisse der Ausführung von <prgn>cron</prgn>, die
an den Superuser gemailt werden (sofern nicht die Umgebungsvariable
<tt>MAILTO</tt> im Skript geändert wurde).

</list>

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

<p>Um diese Aufgaben zu erfüllen, muss das System korrekt konfiguriert sein, um
Sicherheitsaktualisierungen herunterzuladen. Dies wurde in <ref
id="security-update"> diskutiert.

<p>Allerdings wird dieses Vorgehen ohne eine genaue Analyse nicht für
<em>Unstable</em> 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. <em>Testing</em> ist
vor diesem Problem etwas besser <em>geschützt</em>, da gravierende Fehler eine
bessere Chance haben entdeckt zu werden, bevor das Paket in den Testing-Zweig
wandert (obwohl Ihnen trotzdem <em>keine</em> Sicherheitsaktualisierungen zur
Verfügung stehen).

<p>Wenn Sie eine gemischte Distribution haben, also eine Installation von
<em>Stable</em> mit einige Pakete aus <em>Testing</em> oder <em>Unstable</em>,
können Sie mit den Pinning-Eigenschaften oder der Option
<tt>--target-release</tt> von <prgn>apt-get</prgn> herumspielen, um
<em>nur</em> die Pakete zu aktualisieren, die Sie früher aktualisiert
haben.<footnote>
Dies ist ein verbreitetes Problem, da viele Nutzer ein stabiles System
betreiben wollen, aber einige Pakete aus <em>Unstable</em> einsetzen, um die
neusten Funktionen zu haben. Das kommt daher, dass sich manche Projekte
schneller entwickeln als die Veröffentlichungen von Debians <em>Stable</em>.
</footnote>


<sect id="periodic-integrity">Periodische Überprüfung der Integrität

<p>Mit Hilfe der Basisinformationen, die Sie nach der Installation erstellt
haben (also mit dem Schnappschuss, der in <ref id="snapshot"> 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.

<p>Überprüfungen der Integrität sollen, wenn möglich, von außerhalb
durchgeführt werden.<footnote>
Ein leichter Weg, das ist tun, ist die Verwendung einer Live-CD wie <url
id="http://www.knoppix-std.org/" name="Knoppix Std">, die sowohl die Programme
zur Integritätsprüfung als auch die dazugehörige Datenbank enthält.
</footnote>
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.

<p>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.

<p>Einige Werkzeuge, die im Abschnitt über Programme zur Integritätsprüfung
beschrieben wurden, wie z.B. <prgn>aide</prgn>, <prgn>integrit</prgn> und
<prgn>samhain</prgn>, 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 <prgn>samhain</prgn>). Sie können den
Administrator auf verschiedenen Wegen warnen (normalerweise E-Mail, aber
<prgn>samhain</prgn> kann auch Seiten, SNMP-Traps oder einen Alarm an syslog
schicken), wenn sich das Dateisystem verändert.

<p>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.


<sect id="intrusion-detect">Aufsetzen einer Eindringlingserkennung

<p>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.

<p>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.

<p>Wenn ein bestimmter Angriff entdeckt worden ist, werden die meisten
Programme zur Eindringlingserkennung entweder den Vorfall mit
<prgn>syslog</prgn> 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
&ndash; sagen wir mal am nächsten Tag &ndash; 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.

<p>Eine interessante Quelle für Information ist
<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html"
name="CERT's Intrusion Detection Checklist">


<sect1>Netzwerk basierende Eindringlingserkennung

<p>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.

<p><package>snort</package> 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. <prgn>snort</prgn> 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
<tt>apt-get install snort</tt>, beantworten Sie die Fragen und beobachten Sie
die Protokolle. Für einen etwas breiteren Sicherheitsrahmen sollten Sie sich <url
id="http://www.prelude-ids.org" name="Prelude"> ansehen.

<p>Debians Paket <package>snort</package> 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.

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

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


<sect1>Host basierende Eindringlingserkennung 

<p>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.

<p><package>tiger</package> ist ein älteres Programm zur
Eindringlingserkennung, dass seit der Woody-Distribution auf Debian portiert
wurde. <prgn>tiger</prgn> 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
<prgn>tiger</prgn> einmal am Tag laufen und einen Bericht erstellen, der an den
Superuser geschickt wird und Informationen zu möglichen Kompromittierungen
enthält.

<p>Programme zur Protokollanalyse, wie zum Beispiel <package>logcheck</package>
können zusätzliche benutzt werden, um Einbruchsversuche zu erkennen. Siehe <ref
id="custom-logcheck">.

<p>Daneben können Pakete, die die Integrität des Dateisystems überwachen (siehe
<ref id="check-integ">), 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.


<sect>Vermeiden von Root-Kits

<sect1 id="LKM">Ladbare Kernel-Module (LKM)

<p>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.

<p>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 <file>procfs</file> zu verstecken, so dass nicht einmal eine
bekanntermaßen gute Kopie des Programms <prgn>ps</prgn> alle Informationen über
die aktuellen Prozesse korrekt auflisten.


<sect1>Erkennen von Root-Kits

<p>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.


<sect2 id="proactive">Aktive Verteidigung

<p>Der Vorteil dieser Art der Verteidigung ist, dass schon verhindert wird,
dass das System Schaden nimmt. Eine mögliche Strategie ist <em>das Ziel zuerst
zu erreichen</em>, 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 <file>/dev/kmem</file> (Kernelspeicher) manipulieren, um
sich zu verstecken.

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

<list>

<item><package>lcap</package> &ndash; eine benutzerfreundliche Schnittstelle, um dem
Kernel <em>Fähigkeiten</em> zu entziehen (kernelbasierte Zugriffskontrolle), um
das System sicherer zu machen. Beispielsweise wird das Ausführen von
<tt>lcap CAP_SYS_MODULE</tt> 
<footnote>
Es gibt über 28 Fähigkeiten einschließlich
<tt>CAP_BSET</tt>,
<tt>CAP_CHOWN</tt>,
<tt>CAP_FOWNER</tt>,
<tt>CAP_FSETID</tt>,
<tt>CAP_FS_MASK</tt>,
<tt>CAP_FULL_SET</tt>,
<tt>CAP_INIT_EFF_SET</tt>,
<tt>CAP_INIT_INH_SET</tt>,
<tt>CAP_IPC_LOCK</tt>,
<tt>CAP_IPC_OWNER</tt>,
<tt>CAP_KILL</tt>,
<tt>CAP_LEASE</tt>,
<tt>CAP_LINUX_IMMUTABLE</tt>,
<tt>CAP_MKNOD</tt>,
<tt>CAP_NET_ADMIN</tt>,
<tt>CAP_NET_BIND_SERVICE</tt>,
<tt>CAP_NET_RAW</tt>,
<tt>CAP_SETGID</tt>, 
<tt>CAP_SETPCAP</tt>,
<tt>CAP_SETUID</tt>,
<tt>CAP_SYS_ADMIN</tt>,
<tt>CAP_SYS_BOOT</tt>,
<tt>CAP_SYS_CHROOT</tt>,
<tt>CAP_SYS_MODULE</tt>,
<tt>CAP_SYS_NICE</tt>,
<tt>CAP_SYS_PACCT</tt>,
<tt>CAP_SYS_PTRACE</tt>,
<tt>CAP_SYS_RAWIO</tt>,
<tt>CAP_SYS_RESOURCE</tt>,
<tt>CAP_SYS_TIME</tt> und
<tt>CAP_SYS_TTY_CONFIG</tt>. Alle können deaktiviert werden, um Ihren Kernel
abzuhärten.
</footnote>
die Fähigkeit der ladbaren Module entfernen (sogar für Root).<footnote>
Um dies tun zu können, müssen Sie nicht <package>lcap</package>
installieren, aber damit ist es einfacher, als von Hand
<file>/proc/sys/kernel/cap-bound</file> anzupassen.
</footnote>
Weitere (etwas ältere) Informationen zu Kernelfähigkeiten finden Sie in Jon Corbets
Abschnitt <url id="http://lwn.net/1999/1202/kernel.php3" name="Kernel
development"> auf LWN vom Dezember 1999.

</list>

<p>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
<file>.config</file> 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.


<sect2>Reaktive Verteidigung

<p>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
(<file>System.map</file>). Eine reaktive Verteidigung kann den
Systemadministrator natürlich nur benachrichtigen, wenn das System bereits
kompromittiert wurde.

<p>Die Entdeckung von Root-Kits vollbringt unter Debian
<package>chkrootkit</package>. Das Programm <url name="Chkrootkit"
id="http://www.chkrootkit.org"> prüft Anzeichen von bekannten Root-Kits auf
dem Zielsystem. Es ist aber kein völlig sicherer Test.


<sect>Geniale/paranoide Ideen &mdash; was Sie tun können

<p>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 &mdash;
abhängig von Ihrem Standpunkt aus können Sie sie für
genial, paranoid, verrückt oder sicher halten,

<list>

<item>Mit Pluggable Authentication Modules (PAM) herum spielen. Wie in einem
phrack 56 Artikel geschrieben wurde, ist
das Schöne an PAM, dass »Ihrer Fantasie keine Grenzen
gesetzt sind.« Das stimmt. Stellen Sie sich vor, Root kann sich nur mit
einen Fingerabdruck oder Abtastung des Auges oder einer Kryptokarte einloggen
(warum habe ich hier nur »oder« und nicht »und« gesagt?).

<item>Faschistisches Logging. Ich würde sagen, dass alles, was wir
bisher über Logging besprochen haben, unter »weiches Loggen«
fällt. Wenn Sie echtes Logging betreiben wollen, besorgen Sie sich
einen Drucker mit Endlos-Papier und schicken ihm alle Logs. Hört sich lustig
an, ist aber zuverlässig und kann nicht manipuliert oder entfernt werden.

<item>CD-Distribution. Diese Idee ist sehr leicht zu realisieren und
bewirkt ganz gute Sicherheit. Erstellen Sie eine abgesicherte Debian
Distribution mit passenden Firewall-Regeln. Erstellen Sie davon ein bootbares
ISO-Image und brennen Sie es auf eine CD-ROM. Jetzt haben Sie eine nur lesbare
Distribution mit etwa 600 MB Speicherplatz für Dienste.  Stellen Sie lediglich
sicher, dass alle Daten, die geschrieben werden sollen, übers Netz geschrieben
werden. Für einen Eindringling ist es unmöglich, Schreibzugriff auf diesem
System zu erhalten. Alle Änderungen, die ein Eindringling vornimmt, werden mit
einem Reboot des Systems rückgängig gemacht.

<item>Schalten Sie die Modul-Fähigkeiten des Kernels ab. Wenn Sie
die Nutzung von Kernel-Modulen während der Kernel-Kompilierung
abschalten, werden viele Kernel basierende Hintertüren nicht
einsetzbar, da die meisten von ihnen darauf basieren, modifizierte
Kernel-Module zu installieren (siehe oben).

<item>Loggen über ein serielles Kabel (von Gaby Schilders). So lange
Server immer noch serielle Schnittstellen haben: Stellen Sie sich vor, Sie
ein Log-System für eine Anzahl von Servern. Es ist vom Netz abgeschnitten und
mit den Servern über einen Multiplexer für serielle Schnittstellen (Cyclades
oder ähnliches) verbunden. Jetzt sollen alle Ihre Server über ihre serielle
Schnittstelle loggen. Einfach nur hinschreiben. Die Log-Maschine
akzeptiert nur einfachen Text als Eingabe auf ihrer seriellen
Schnittstelle und schreibt ihn lediglich in eine Log-Datei. Schließen Sie
einen CD- oder DVD-Brenner an. Brennen Sie die Log-Datei, wenn sie die Größe
des Mediums erreicht hat. Wenn es jetzt nur noch CD-Brenner mit
automatischem Medien-Wechsel gäbe ... Nicht so dauerhaft gespeichert
wie ein Ausdruck, aber mit dieser Methode kann man größere Mengen handhaben,
und die CD-ROMs nehmen nicht so viel Platz weg.

<item>Ändern Sie die Dateiattribute mit <prgn>chattr</prgn> (dem Tipps-HOWTO
von Jim Dennis entnommen). Nachdem Sie Ihr System sauber installiert und
konfiguriert haben, verwenden Sie das Programm <prgn>chattr</prgn> mit dem
Attribut <tt>+i</tt>, um Dateien unveränderbar zu machen (die Datei kann nicht
gelöscht, umbenannt, verlinkt oder beschrieben werden). Sie sollten dieses
Attribut für alle Dateien in <file>/bin</file>, <file>/sbin/</file>,
<file>/usr/bin</file>, <file>/usr/sbin</file>, <file>/usr/lib</file> und den
Kerneldateien in root. Sie können auch eine Kopie aller Dateien in
<file>/etc/</file> mit <prgn>tar</prgn> oder dergleichen erstellen und das
Archiv als unveränderbar kennzeichnen.

<p>Mit dieser Vorgehensweise können Sie den Schaden zu begrenzen, den Sie
anrichten können, wenn Sie als Root eingeloggt sind. Sie können
keine Dateien mit einer fehlgeleiteten Umleitung überschreiben, und
Sie werden Ihr System nicht durch ein fehlplatziertes Leerzeichen im Kommando
<prgn>rm -fr</prgn> unbenutzbar machen (Sie können aber
Ihren Daten immer noch einigen Schaden zufügen &mdash; aber Ihre
Bibliotheken und Programme sind sicherer).

<p>Dies macht auch verschiedene Sicherheits- und Denial-of-Service (DoS)
Exploits entweder unmöglich oder weitaus schwieriger (da viele von
ihnen darauf beruhen, Dateien durch Aktionen eines SETUID-Programms zu
überschreiben, das <em>keinen frei wählbaren Shellbefehl zur Verfügung
stellt</em>.
<!-- SB (20050313): Was will uns das sagen? "that <em>isn't providing an
arbitrary shell command</em>" -->

<p>Eine Unbequemlichkeit dieser Vorgehensweise macht sich bemerkbar, wenn Sie
verschiedene Systemprogramme bauen und installieren. Auf der anderen Seite
verhindert dies auch, dass <prgn>make install</prgn> die Dateien
überschreibt. Wenn Sie vergessen, das Makefile zu lesen, und die Dateien, die
überschrieben werden sollen, mit chattr -i behandelt haben (und die
Verzeichnisse, in denen Sie neue Dateien erstellen wollen), schlägt der
make-Befehl fehl. Sie müssen nur das Kommando <prgn>chattr</prgn> ausführen und
make neu aufrufen.  Sie können diese Gelegenheit gleich dazu benutzen, Ihre
alten bin's und libs auszumisten und sie z.B. in ein .old/-Verzeichnis oder
Tar-Archiv zu verschieben.

<p>Beachten Sie, dass dies Sie auch daran hindert, die Pakete Ihres
Systems zu aktualisieren, da die Dateien aus den Paketen nicht
überschrieben werden können. Also sollten Sie vielleicht ein Skript oder
einen anderen Mechanismus haben, der das immutable-Flag auf allen Dateien
deaktiviert,
bevor Sie ein <prgn>apt-get update</prgn> ausführen.

<p>Spielen Sie mit der UTP-Verkabelung herum. Schneiden Sie dazu zwei oder vier
Kabel durch und stellen ein Kabel her, das nur Verkehr in eine Richtung
zulässt. Verwenden Sie dann UDP-Pakete, um Informationen an die Zielmaschine zu
schicken, die ein sicherer Log-Server oder ein System zur Speicherung von
Kreditkartennummern sein kann.

</list>


<sect1>Aufstellen eines Honigtopfes (honeypot)

<p>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.

<p>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<footnote>Sie sollten typischerweise eine
Bridge-Firewall einsetzen, damit die Firewall selbst nicht entdeckt werden
kann. Lesen Sie mehr dazu unter <ref id="bridge-fw">.</footnote>, 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 <ref
id="log-alerts">), 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:

<list>

<item>Die Firewall-Technologie, die Sie verwenden (verfügbar durch den
Linux-Kernel).

<item><package>syslog-ng</package>. Nützlich, um Logs des Honigtopfs zu einem
entfernen Syslog-Server zu schicken.

<item><package>snort</package>, um allen eingehenden Netzwerkverkehr auf
den Honigtopf mitzuschneiden und die Angriffe zu erkennen.

<item><package>osh</package>, eine eingeschränkte Shell mit Logging, die unter
SETUID-Root läuft und verbesserte Sicherheit hat (siehe den Artikel von Lance
Spitzner weiter unten).

<item>Natürlich alle Daemons, die Sie auf dem falschen Honigtopfserver
verwenden wollen. Je nachdem, welche Art von Angreifer Sie analysieren wollen,
können Sie den Honigtopf abhärten und die Sicherheitsaktualisierungen
einspielen (oder eben <em>nicht</em>).

<item>Integritätsprüfer (siehe <ref id="check-integ">) und das
Coroner's Toolkit (<package>tct</package>), um nach dem Angriff eine
Analyse durchzuführen.

<item><package>honeyd</package> und <package>farpd</package>, um einen
Honigtopf einzurichten, der auf Verbindungen zu ungenutzten IP-Adressen lauscht
und diese an Skripte weiterleitet, die echte Dienste simulieren. Sehen Sie sich
auch <package>iisemulator</package> an.

<item><package>tinyhoneypot</package>, um einen einfachen Honigtopf-Server mit
gefälschten Diensten einzurichten.

</list>

<p>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 <prgn>xen</prgn> oder <prgn>uml</prgn>
(User-Mode-Linux) enthalten ist. Wenn Sie diesen Weg wählen, müssen Sie Ihren
Kernel entweder mit <package>kernel-patch-xen</package> oder
<package>kernel-patch-uml</package> patchen.

<p>Sie können mehr über das Aufstellen eines Honigtopfs in Lanze
Spitzners exzellentem Artikel <url
id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml"
name="To Build a Honeypot"> (aus der Know your Enemy Serie).
Außerdem stellt das <url id="http://project.honeynet.org/" name="Honeynet
Project"> wertvolle Informationen über das Aufstellen von Honigtöpfen und der
Analyse von Angriffen auf sie zur Verfügung.
