[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
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 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 aus der Ferne 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).
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 (die also mit dem Internet verbunden sind), 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-Sicherheits-Ankü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.
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
Sicherheitsaktualisierungen, Abschnitt 4.2 beschrieben.
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 Sicherheitsaktualisierungen, 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. Hinweis: Lesen Sie Ausführen von Sicherheitsaktualisierungen, 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
).
Hinweis: Sie werden Ihr System neustarten müssen, wenn der Kernel aktualisiert wurde.
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
Sicherheitsaktualisierungen, 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.
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.5.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
.
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
.
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.
Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable.
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 unter Umständen 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 mit Sicherheitsaktualisierungen kein neuer Code hinzugefügt werden sollte, sondern nur wichtige Probleme beseitigt werden.
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.
Wenn Sie den Testing-Zweig verwenden, müssen Sie einige Problemkreise hinsichtlich der Verfügbarkeit von Sicherheitsaktualisierungen in Betracht ziehen:
Wenn eine Sicherheitslücke geschlossen wurde, portiert das Sicherheitsteam den Patch nach Stable zurück (da Stable normalerweise einige Minor- oder Majorversionen zurückliegt). Die Paketbetreuer sind dafür verantwortlich, Pakete für den Unstable-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 Stable werden gründlicher getestet als die in Unstable, da letztere in den meisten Fällen die neueste Veröffentlichung des Originalprogramms enthält (welches neue, unbekannte Fehler enthalten könnte).
Gewöhnlich sind Sicherheitsaktualisierungen für den Unstable-Zweig verfügbar, wenn der Paketbetreuer ein neues Paket baut, und für den Stable-Zweig, wenn das Security Team eine neue Version hochlädt und ein DSA veröffentlicht. Beachten Sie, dass beides nicht des Testing-Zweig verändert.
Wenn keine (neuen) Fehler in der Unstable-Version des Pakets entdeckt werden, wandert es nach ein paar Tagen nach Testing. 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 Testing 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.
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.
Additionally, the Debian Testing Security
Team
can issue Debian Testing Security Advisories (DTSAs) for
packages in the testing branch if there is an immediate need to fix a
security issue in that branch and cannot wait for the normal procedure (or the
normal procedure is being blocked by some other packages).
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
Sicherheitsaktualisierungen, 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.
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:
Configure apt
so that those packages that you do not want to
update stay at their current version, either with apt
's
pinning feature or marking them as hold with
aptitude
or dpkg
.
Um Pakete einer bestimmten Veröffentlichung mit pinning festzuheften, müssen
Sie /etc/apt/preferences
bearbeiten (siehe
apt_preferences(5)
) und Folgendes hinzufügen:
Package: * Pin: release a=stable Pin-Priority: 100
FIXME: verify if this configuration is OK.
Entweder setzen Sie cron-apt
ein, wie in Automatisches Überprüfung von Aktualisierungen mit
cron-apt, Abschnitt 10.1.2.3 beschrieben wird, und erlauben ihm,
heruntergeladene Pakete zu installieren. Oder Sie fügen selbst einen Eintrag
für cron
hinzu, damit die Aktualisierung täglich ausgeführt
wird. Ein Beispiel:
apt-get update && apt-get -y upgrade
Die Option -y veranlasst apt
, für alle Fragen, die
während der Aktualisierung auftreten können, »yes« anzunehmen. In manchen
Fällen sollten Sie die Option --trivial-only (nur Bagatellen) der
Option --assume-yes (ist gleichbedeutend mit -y)
vorziehen.[73]
Richten Sie debconf
so ein, dass während der Aktualisierung keine
Eingabe verlangt wird. Auf diese Weise können Aktualisierungen
nicht-interaktiv durchgeführt werden.[74]
Überprüfen Sie die Ergebnisse der Ausführung von cron
, die an
den Superuser gemailt werden (sofern nicht die Umgebungsvariable
MAILTO im Skript geändert wurde).
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 Sicherheitsaktualisierungen, 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.[75]
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, extern durchgeführt werden.[76] 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 einer externen Prüfung nicht möglich 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 (wie unter Prüfung der Integrität des Dateisystems, Abschnitt 4.17.3 beschrieben). 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.
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 Informationen ist CERT's
Intrusion Detection Checklist
.
Programme, die der netzwerkbasierten 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 und -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.
Eine Eindringlingserkennung, die auf einem Host basiert, beruht darauf, Software auf dem zu überwachenden System zu laden, die Protokolldateien und die Überwachungsprogramme 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, welche 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 Sicherheitsrichtlinien zu umgehen, Trojaner zu installieren oder Benutzer zu erstellen. Solche Ereignisse können mit Prüfwerkzeugen der Dateisystemintegrität erkannt werden.
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 unmanipulierte Kopie des Programms ps
alle Informationen
über die aktuellen Prozesse korrekt auflisten.
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.
Der Vorteil dieser Art der Verteidigung ist, dass schon verhindert wird, dass
das System Schaden nimmt. Eine mögliche Strategie ist, das Ziel als
Erster 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:
lcap
– eine benutzerfreundliche Schnittstelle, um dem Kernel
Fähigkeiten zu entziehen (kernelbasierte Zugriffskontrolle), um das
System sicherer zu machen. Beispielsweise wird das Ausführen von lcap
CAP_SYS_MODULE [77] die
Fähigkeit der ladbaren Module entfernen (sogar für Root).[78] Weitere (etwas ältere)
Informationen zu Kernelfähigkeiten finden Sie in Jon Corbets Abschnitt
Kernel
development
auf LWN vom Dezember 1999.
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.
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.
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.
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?).
Faschistisches Protokollieren. Ich würde sagen, dass alles, was wir bisher über Protokollieren besprochen haben, unter »weiches Loggen« fällt. Wenn Sie echtes Protokollieren betreiben wollen, besorgen Sie sich einen Drucker mit Endlos-Papier und schicken ihm alle Protokolle. Hört sich lustig an, ist aber zuverlässig und kann nicht manipuliert oder entfernt werden.
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 Neustart des Systems rückgängig gemacht.
Schalten Sie die Modul-Fähigkeiten des Kernels ab. Wenn Sie die Nutzung von Kernel-Modulen während der Kernel-Kompilierung abschalten, werden viele kernelbasierte Hintertüren nicht einsetzbar, da die meisten von ihnen darauf beruhen, modifizierte Kernel-Module zu installieren (siehe oben).
Protokollieren über ein serielles Kabel (von Gaby Schilders). So lange Server immer noch serielle Schnittstellen haben: Stellen Sie sich ein Protokollsystem für eine Anzahl von Servern vor. 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 die Protokolle an ihre serielle Schnittstelle schicken, einfach nur hinschreiben. Die Protokollmaschine akzeptiert nur einfachen Text als Eingabe auf ihrer seriellen Schnittstelle und schreibt ihn lediglich in eine Protokolldatei. Schließen Sie einen CD- oder DVD-Brenner an. Brennen Sie die Protokolldatei, 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.
Ändern Sie die Dateiattribute mit chattr
(dem Tipps-HOWTO von Jim
Dennis entnommen). Nachdem Sie Ihr System sauber installiert und konfiguriert
haben, verwenden Sie das Programm chattr
mit dem Attribut
+i, 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 /bin
, /sbin/
,
/usr/bin
, /usr/sbin
, /usr/lib
und den
Kerneldateien in root. Sie können auch eine Kopie aller Dateien in
/etc/
mit tar
oder dergleichen erstellen und das
Archiv als unveränderbar kennzeichnen.
Mit dieser Vorgehensweise können Sie den Schaden zu begrenzen, den Sie
anrichten können, wenn Sie als Root eingeloggt sind. Sie können nicht mehr
Dateien mit einer fehlgeleiteten Umleitung überschreiben oder Ihr System durch
ein fehlplatziertes Leerzeichen im Kommando rm -fr
unbenutzbar
machen (Sie können aber Ihren Daten immer noch einigen Schaden zufügen
– aber Ihre Bibliotheken und Programme sind sicherer).
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 keinen frei wählbaren Shellbefehl zur Verfügung stellt.
Eine Unbequemlichkeit dieser Vorgehensweise macht sich bemerkbar, wenn Sie
verschiedene Systemprogramme bauen und installieren. Auf der anderen Seite
verhindert dies auch, dass make install
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 chattr
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.
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
apt-get update
ausführen.
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 Protokollserver oder ein System zur Speicherung von Kreditkartennummern sein kann.
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[79], 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 Protokollen 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:
die Firewall-Technologie, die Sie verwenden (verfügbar durch den Linux-Kernel)
syslog-ng
: nützlich, um Protokolle des Honigtopfs zu einem
entfernen syslog-Server zu schicken
snort
, um allen eingehenden Netzwerkverkehr auf den Honigtopf
mitzuschneiden und die Angriffe zu erkennen
osh
, eine eingeschränkte Shell mit Protokollfunktion, die unter
SETUID-Root läuft und verbesserte Sicherheit hat (siehe den Artikel von Lance
Spitzner weiter unten)
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 nicht).
Integritätsprüfer (siehe Prüfung der
Integrität des Dateisystems, Abschnitt 4.17.3) und das Coroner's Toolkit
(tct
), um nach dem Angriff eine Analyse durchzuführen
honeyd
und farpd
, 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
iisemulator
an.
tinyhoneypot
, um einen einfachen Honigtopf-Server mit gefälschten
Diensten einzurichten
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 ]
Securing Debian Manual
Version: 3.17,mailto:jfs@debian.org