[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Wenn das System installiert ist, können Sie es noch weiter absichern, indem Sie einige der in diesem Kapitel beschriebenen Schritte ausführen. Natürlich hängt dies vor allem von Ihrem Setup ab, aber um physischen Zugriff zu verhindern, sollten Sie Änderungen im BIOS (noch einmal), Abschnitt 4.3, Ein Passwort für LILO oder GRUB einstellen, Abschnitt 4.4, Entfernen des Root-Promptes aus dem Kernel, Abschnitt 4.6, Einschränkender Konsolen-Zugang, Abschnitt 4.7 und System-Neustart von der Konsole aus einschränken, Abschnitt 4.8 lesen.
Bevor Sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um ein öffentliches Netzwerk handelt, sollten Sie wenigstens eine Sicherheitsaktualisierung (siehe Ausführen von Sicherheitsupdates, Abschnitt 4.2) durchführen. Optional können Sie auch einen Schnappschuss Ihres Systems machen (siehe Einen Schnappschuss des Systems erstellen, Abschnitt 4.18).
Um Informationen zu verfügbaren Sicherheitsaktualisierungen und die
Debian-Sicherheits-Ankündigungen (DSA) zu erhalten, sollten Sie Debians
Security-Announce-Mailingliste abonnieren. Lesen Sie Das Sicherheitsteam von Debian, Abschnitt
7.1 für weitere Informationen, wie das Sicherheitsteam von Debian arbeitet.
Hinweise, wie man die Mailinglisten von Debian abonniert, finden Sie unter
http://lists.debian.org
.
DSAs werden mit der Signatur des Sicherheitsteams von Debian unterschrieben,
die unter http://security.debian.org
erhältlich ist.
Sie sollten in Betracht ziehen, auch die debian-security
Mailingliste
zu abonnieren. Dort finden allgemeine Diskussionen zu
Sicherheitsthemen im Betriebssystem Debian statt. Sie können auf der Liste
sowohl mit gleichgesinnten Systemadministratoren als auch mit Entwicklern von
Debian und Programmautoren in Kontakt treten. Diese werden Ihre Fragen
beantworten und Ihnen Ratschläge geben.
FIXME: Add the key here too?
Sobald neue Sicherheitslöcher in einem Paket entdeckt wurden, reparieren sie
Debians Paketbetreuer und Originalautoren im Allgemeinen innerhalb von Tagen
oder sogar Stunden. Nachdem das Loch gestopft wurde, werden neue Pakete unter
http://security.debian.org
bereit
gestellt.
Wenn Sie ein Debian-Release installieren, müssen Sie berücksichtigen, dass es seit der Veröffentlichung Sicherheitsaktualisierungen gegeben haben könnte, nachdem entdeckt wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es kleinere Releases gegeben haben. Es gab vier kleinere Veröffentlichungen von Debian 3.1 Sarge, die diese Paketaktualisierungen enthalten.
Sie müssen sich das Erstellungsdatum Ihres CD-Sets (wenn Sie ein solches benutzen) notieren und auf der Sicherheitsseite nachprüfen, ob es Sicherheitsaktualisierungen gegeben hat. Wenn es solche gibt, und Sie die Pakete nicht von der Sicherheitsseite mit einem anderen System herunterladen können (Ihr System ist doch nicht schon mit dem Internet verbunden, oder?), könnten Sie es in Erwähnung ziehen (falls Sie nicht beispielsweise durch eine Firewall, geschützt sind), Firewall-Regeln zu aktivieren, so dass Ihr System ausschließlich mit security.debian.org Verbindung aufnehmen kann, und dann ein Update ausführen. Eine Beispielkonfiguration finden Sie unter Schutz der Sicherheitsaktualisierung durch eine Firewall, Anhang F.
Anmerkung:Seit Debian Woody 3.0 wird Ihnen nach der Installation die Möglichkeit eingeräumt, Sicherheitsaktualisierungen Ihrem System hinzuzufügen. Wenn Sie hier 'ja' sagen, wird das Installationssystem die passenden Schritte unternehmen, um die Quellen der Sicherheitsaktualisierungen Ihren Paketquellen hinzuzufügen. Falls Sie nun eine Internetverbindung haben, wird Ihr System alle Sicherheitsaktualisierungen herunterladen, die seit Entstehung Ihres Installationsmediums erzeugt wurden. Falls Sie ein Upgrade von einer älteren Version von Debian durchführen, oder Sie das Installationssystem anweisen, dies nicht zu tun, sollten Sie die hier vorgestellten Schritte unternehmen.
Um Ihr System manuell zu aktualisieren, fügen Sie die folgende Zeile in Ihre
/etc/apt/sources.list
ein. So werden Sie
Sicherheitsaktualisierungen automatisch erhalten, wann immer Sie Ihr System
aktualisieren.
deb http://security.debian.org/debian-security stable/updates main contrib non-free
Hinweis: Falls Sie den Testing-Zweig einsetzen, sollten Sie die Sicherheitsspiegel für Testing verwenden. Das wird unter Sicherheitsunterstützung für den Testing-Zweig, Abschnitt 10.1.4 beschrieben.
Wenn Sie dies erledigt haben, stehen Ihnen zahlreiche Werkzeuge zur Verfügung,
mit denen Sie Ihr System aktualisieren können. Wenn Sie ein Desktop-System
einsetzen, können Sie eine Anwendung mit dem Namen update-notifier
verwenden[10], die Sie auf neue
Aktualisierungen aufmerksam macht. Damit können Sie Ihr System auch über den
Desktop auf den neusten Stand bringen (mit update-manager
). Für
den Desktop können Sie auch synaptic
, kpackage
oder
adept
einsetzen, die einen größeren Funktionsumfang aufweisen.
Wenn Sie auf einem textbasierten Terminal arbeiten, stehen Ihnen
aptitude
, apt
und dselect
, wobei
letzteres veraltet ist, zur Verfügung:
Falls Sie die textbasierte Oberfläche von aptitude
verwenden
wollen, müssen Sie zunächst u (für Update) und dann g (für
Upgrade) eingeben. Oder Sie führen auf der Befehlszeile Folgendes als Root
aus:
# aptitude update # aptitude upgrade
Falls Sie apt
einsetzen möchten, müssen Sie obige Zeilen von
aptitude
nur mit apt-get
ersetzen.
Falls Sie dselect
verwenden wollen, müssen Sie zuerst
aktualisieren ([U] für Update), dann installieren ([I] für Install) und
schließlich die installieren/aktualisierten Pakete konfigurieren ([C] für
Configure).
Wenn Sie möchten, können Sie ebenfalls eine deb-src Zeile hinzufügen. Weitere
Details finden Sie unter apt(8)
.
Anmerkung: Sie brauchen folgende Zeile nicht hinzufügen:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
Das liegt daran, dass sich der Server, der security.debian.org hostet, außerhalb der USA befindet und somit kein getrenntes Archiv für Non-US hat.
Wenn Sie eine Sicherheitsaktualisierung durchgeführt haben, müssen Sie
gegebenenfalls einige Dienste des Systems neu starten. Wenn Sie das nicht tun,
könnten Dienste auch nach der Sicherheitsaktualisierung immer noch verwundbar
sein. Das liegt daran, dass Daemonen, die schon vor einem Upgrade liefen,
immer noch die alten Bibliotheken vor dem Upgrade verwenden könnten.[11] Um herauszufinden, welche
Daemonen neu gestartet werden müssen, können Sie das Programm
checkrestart
(ist im Paket debian-goodies
enthalten)
oder diesen Einzeiler (als Root) verwenden:[12]
# lsof | grep <aktualisierte_Bibliothek> | awk '{print $1, $9}' | uniq | sort +0
Einige Pakete (wie libc6
) werden diesen Test in der Postinst-Phase
für eine begrenzte Anzahl von Diensten durchführen, da ein Upgrade von
notwendigen Bibliotheken einige Anwendungen unbrauchbar machen kann, wenn sie
nicht neu gestartet werden [13].
Indem das System auf Runlevel 1 (Single User) und dann zurück auf Runlevel 3 (Multi User) gebracht wird, sollten die meisten (wenn nicht alle) Systemdienste neu gestartet werden. Dies ist aber keine Möglichkeit, wenn Sie die Sicherheitsaktualisierung über eine entfernte Verbindung (z.B. mit ssh) vornehmen, da sie getrennt werden würde.
Lassen Sie Vorsicht walten, wenn Sie es mit Sicherheitsaktualisierungen über eine entfernte Verbindung wie mit ssh zu tun haben. Die empfohlene Vorgehensweise für Sicherheitsaktualisierungen, die Dienste betreffen, ist, den SSH-Daemon neu zu starten und sofort zu versuchen, eine neue SSH-Verbindung herzustellen, ohne die alten zu beenden. Falls der Verbindungsversuch scheitern sollte, machen Sie die Aktualisierung rückgängig und untersuchen Sie das Problem.
Stellen Sie zunächst sicher, dass Ihr Kernel durch das Paketsystem verwaltet wird. Wenn Sie die Installation mit dem Installationssystem von Debian 3.0 oder früher durchgeführt haben, ist Ihr Kernel nicht in das Paketsystem integriert und könnte veraltet sein. Sie können das leicht überprüfen, indem Sie Folgendes ausführen:
$ dpkg -S `readlink -f /vmlinuz` kernel-image-2.4.27-2-686: /boot/vmlinuz-2.4.27-2-686
Wenn Ihr Kernel nicht vom Paketsystem verwaltet wird, werden Sie anstatt der
obigen Nachricht die Rückmeldung bekommen, dass das Paketverwaltungsprogramm
kein Paket finden konnte, das mit der Datei verbunden ist. Die obige Meldung
besagt, dass die Datei, die mit dem laufenden Kernel verbunden ist, vom Paket
kernel-image-2.4.27-2-686
zur Verfügung gestellt wird. Sie müssen
also zuerst ein Paket mit einem Kernel-Image von Hand installieren. Das genaue
Kernel-Image, das Sie installieren sollten, hängt von Ihrer Architektur und
Ihrer bevorzugten Kernelversion ab. Wenn Sie das einmal erledigt haben, können
Sie die Sicherheitsaktualisierungen des Kernels wie die jedes anderen Pakets
durchführen. Beachten Sie allerdings, dass Kernelaktualisierungen nur
für Aktualisierungen der gleichen Kernelversion wie der Ihrigen durchgeführt
werden. D.h. apt
wird nicht automatisch Ihren Kernel von 2.4 auf
2.6 aktualisieren (oder von 2.4.26 auf 2.4.27 [14]).
Das Installationssystem von Debian 3.1 wird den gewählten Kernel (2.4 oder 2.6) als Teil des Paketsystems behandeln. Sie können überprüfen, welche Kernel Sie installiert haben:
$ COLUMNS=150 dpkg -l 'kernel-image*' | awk '$1 ~ /ii/ { print $0 }'
Um festzustellen, ob Ihr Kernel aktualisiert werden muss, führen Sie Folgendes aus:
$ kernfile=`readlink -f /vmlinuz` $ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'` $ apt-cache policy $kernel kernel-image-2.4.27-2-686: Installed: 2.4.27-9 Candidate: 2.4.27-9 Version Table: *** 2.4.27-9 0 (...)
Wenn Sie eine Sicherheitsaktualisierung durchführen, die auch das Kernel-Image umfasst, müssen Sie das System neu starten, damit die Sicherheitsaktualisierung Wirkung zeigen kann. Anderenfalls lassen Sie immer noch das alte (und verwundbare) Kernel-Image laufen.
Wenn Sie das System neu starten müssen (wegen eines Kernel-Upgrades), sollten
Sie sicherstellen, dass der Kernel fehlerfrei booten wird und die
Netzwerkverbindungen hergestellt werden, besonders wenn die
Sicherheitsaktualisierung über eine entfernte Verbindung wie mit ssh
durchgeführt wird. Für den ersten Fall können Sie Ihren Boot-Loader so
konfigurieren, dass er den Originalkernel lädt, wenn ein Fehler auftritt (für
weiterführende Informationen sollten Sie Remotely rebooting
Debian GNU/Linux machines
lesen). Im zweiten Fall müssen Sie ein
Skript verwenden, das die Netzwerkverbindungen testen kann und überprüft, ob
der Kernel das Netzwerksystem korrekt gestartet hat, und, wenn das nicht
geschehen ist, das System neu startet [15]. Dies sollte böse Überraschungen verhindern, wie wenn man
den Kernel aktualisiert und dann nach einem Reboot merkt, dass die
Netzwerkhardware nicht richtig erkannt oder konfiguriert wurde, und man daher
eine weite Strecke zurücklegen muss, um das System wieder hoch zu bringen.
Natürlich hilft es beim Debuggen von Reboot-Problemen aus der Ferne, wenn die
serielle Konsole des Systems [16] mit einem Konsolen- oder Terminalserver verbunden ist.
Erinnern Sie sich an Setzen Sie ein Passwort im BIOS, Abschnitt 3.1? Nun, jetzt sollten Sie, nachdem Sie nicht mehr von austauschbaren Datenträgern booten müssen, die Standard-BIOS-Einstellung so umändern, dass es ausschließlich von der Festplatte bootet. Gehen Sie sicher, dass Sie Ihr BIOS-Passwort nicht verlieren, oder Sie werden nicht mehr ins BIOS zurückkehren können, um die Einstellung wieder zu ändern, so dass Sie im Falle eines Festplattenfehlers Ihr System wiederherstellen können, indem Sie zum Beispiel eine CD-ROM benutzen.
Eine andere, weniger sichere, aber bequemere Möglichkeit ist es, das BIOS so einzustellen, dass es von der Festplatte bootet, und nur falls dies fehlschlägt versucht, von austauschbaren Datenträgern zu booten. Übrigens wird dies oft so gemacht, weil viele Leute ihr BIOS-Passwort nur selten benutzen, so dass sie es zu leicht vergessen.
Jeder kann sehr einfach eine root-Shell auf Ihrem System bekommen, indem er einfach <Name-Ihres-Bootimages> init=/bin/sh am Bootprompt eingibt. Nachdem die Passwörter geändert und das System neu gestartet wurde, hat die Person uneingeschränkten Root-Zugang und kann nach Belieben alles auf Ihrem System machen. Nach dieser Prozedur haben Sie keinen Root-Zugang mehr zu Ihrem System, weil Sie das Root-Passwort nicht kennen.
Um sicher zu stellen, dass dies nicht passieren kann, sollten Sie den Boot-Loader mit einem Passwort schützen. Sie können zwischen einem globalen Passwort und Passwörtern für bestimmte Images wählen.
Für LILO müssen Sie die Konfigurationsdatei /etc/lilo.conf
editieren und eine password und restricted Zeile, wie
im folgenden Beispiel, einfügen:
image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackmich restricted
Gehen Sie danach sicher, dass die Konfigurationsdatei nicht für alle lesbar
ist, um zu verhindern, dass lokale Nutzer das Passwort lesen können. Haben Sie
dies getan, rufen Sie lilo auf. Wenn Sie die restricted-Zeile
weglassen, wird lilo immer nach dem Passwort fragen, egal ob LILO Parameter
übergeben wurden oder nicht. Die Standard-Zugriffsrechte auf
/etc/lilo.conf
erlauben root das Lesen und Schreiben, und der
Gruppe von lilo.conf, ebenfalls root, das Lesen.
Wenn Sie GRUB anstelle von LILO verwenden, editieren Sie
/boot/grub/menu.lst
und fügen die folgenden zwei Zeilen am Anfang
an (dabei ersetzen Sie natürlich hackmich mit dem vorgesehenen
Passwort). Dies verhindert, dass Benutzer die Booteinträge verändern können.
timeout 3 legt eine Wartedauer von 3 Sekunden fest, bevor
grub
den Standard-Eintrag bootet.
timeout 3 password hackmich
Um die Integrität Ihres Passwortes zusätzlich abzusichern, sollten Sie Ihr
Passwort verschlüsselt ablegen. Das Dienstprogramm grub-md5-crypt
erzeugt ein gehashtes Passwort, das kompatibel mit GRUBs
Verschlüsselungsalgorithmus (MD5) ist. Um grub
mitzuteilen, dass
ein Passwort im MD5-Format verwendet wird, benutzen Sie die folgende Anweisung:
timeout 3 password --md5 $1$arPydhOM$bIgEKjMW5kxeEuvE1Rah4/
Der Parameter --md5 wurde hinzugefügt, um bei grub
einen
MD5-Authentifizierungsprozess zu erzwingen. Das angegebene Passwort ist die
MD5 verschlüsselte Version von "hackmich". MD5-Passwörter sind
Klartext-Passwörtern vorzuziehen. Weitere Informationen über
grub
-Passwörter können Sie im grub-doc
-Paket finden.
Hinweis: Dies betrifft alle Standard-Kernel, die nach Debian 3.1 veröffentlicht wurden.
Die Linux-Kernel 2.6 enthalten die Möglichkeit, während des Bootvorgangs eine
Root-Shell zu erhalten. Dies geschieht, wenn beim Laden von initramfs ein
Fehler auftritt. Dadurch kann der Administrator auf eine Rettungsshell mit
Root-Rechten zugreifen. Mit dieser Shell können von Hand Module geladen
werden, falls eine automatische Erkennung scheitern sollte. Diese Verhalten
ist Standard für ein von initramfs-tools
erzeugtes Initramfs.
Folgende Fehlermeldung wird auftreten:
"ALERT! /dev/sda1 does not exist. Dropping to a shell!
Um dieses Verhalten abzuschalten, müssen Sie folgenden Boot-Parameter setzen:
panic=0. Sie können ihn entweder in den Abschnitt kopt in
/boot/grub/menu.lst
eintragen und update-grub
ausführen oder ihn dem Abschnitt append von /etc/lilo.conf
hinzufügen.
Hinweis: Dies trifft nicht auf Kernel zu, die in Debian 3.1 enthalten sind, da die Wartezeit auf Null verändert wurde.
Linux 2.4 Kernel bieten kurz nach dem Laden des cramfs einen Weg Zugriff auf
eine Root-Shell zu bekommen, also während das System bootet. Es erscheint eine
Meldung, die dem Administrator erlaubt, eine auszuführende Shell mit
Root-Privilegien zu öffnen. Diese Shell kann dazu benutzt werden, manuell
Module zu laden, falls die automatische Erkennung fehlschlägt. Dies ist das
Standard-Verhalten bei initrd
's linuxrc
. Die
folgende Meldung wird erscheinen:
Press ENTER to obtain a shell (waits 5 seconds)
Um dieses Verhalten zu entfernen, müssen Sie
/etc/mkinitrd/mkinitrd.conf
editieren und den Eintrag
# DELAY Anzahl Sekunden, die das linuxrc Skript warten soll, # um den Nutzer Eingriffe zu erlauben, bevor das System hochgefahren # wird DELAY=0
setzen.
Erstellen Sie anschließend Ihr Ramdisk-Image neu. Dies können Sie zum Beispiel so tun:
# cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
oder (vorzugsweise) so:
# dpkg-reconfigure kernel-image-2.4.x-yz
Manche Sicherheitsregelwerke könnten Administratoren dazu zwingen, sich erst
als Benutzer mit ihrem Passwort auf dem System einzuloggen, und dann Superuser
zu werden (mit su
oder sudo
). Solche eine Policy ist
in Debian in der Datei /etc/login.defs
oder
/etc/securetty
(falls Sie PAM verwenden) implementiert.
In login.defs
ändern Sie die CONSOLE-Variable, die eine Datei oder
eine Liste von Terminals definiert, an denen sich Root einloggen darf.
In securetty
[17]
entfernen Sie oder fügen Sie Terminals hinzu, auf die Root zugreifen darf.
Falls Sie nur lokalen Zugang zur Konsole erlauben wollen, benötigen Sie
console, ttyX [18] und vc/X (falls Sie die
devfs-Schnittstelle verwenden). Sie sollten auch ttySX [19] hinzufügen, wenn Sie eine
serielle Konsole für den lokalen Zugang verwenden. (Wenn X eine ganze Zahl
(Integer) ist, sollten Sie mehrere Instanzen [20] haben, abhängig von der Anzahl der virtuellen Konsolen, die
Sie in /etc/inittab
aktiviert haben [21]). Weiterführende
Informationen zu Terminal-Schnittstellen finden Sie im Text-Terminal-HOWTO
.
Wenn Sie PAM benutzen, können Sie auch andere Änderungen am Login-Prozess, die
auch Einschränkungen für einzelne Benutzer oder Gruppen zu bestimmten Zeiten
enthalten können, durch Konfiguration der Datei /etc/pam.d/login
vornehmen. Eine interessante Eigenschaft, die man auch abschalten kann, ist
die Möglichkeit, sich mit einem leeren Passwort (Null Passwort) einzuloggen.
Diese Eigenschaft kann eingeschränkt werden, indem sie nullok aus der
Zeile
auth required pam_unix.so nullok
entfernen.
Wenn an Ihr System eine Tastatur angeschlossen ist, kann jeder (ja wirklich
jeder) Ihr System neu starten, ohne sich in Ihr System einloggen zu
müssen. Dies könnte gegen Ihre Sicherheitsrichtlinien verstoßen (oder auch
nicht). Wenn Sie dies einschränken wollen, müssen Sie in
/etc/inittab
prüfen, ob die Zeile, die enthält, dass
ctrlaltdel shutdown
aufruft, den -a
Schalter enthält (vergessen Sie nicht, init q auszuführen, nachdem
Sie diese Datei irgendwie verändert haben). Standardmäßig enthält Debian
diesen Schalter:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Jetzt müssen Sie, um es manchen Benutzern zu erlauben, Ihr System neu
zu starten, eine Datei /etc/shutdown.allow
erstellen, wie es die
Handbuchseite shutdown(8)
beschreibt. Dort müssen die Namen der
Benutzer, die das System neu booten dürfen, aufgeführt sein. Wenn der drei
Finger Salut (auch bekannt als Strg+Alt+Entf und
Affengriff) ausgeführt wird, wird geprüft, ob irgendeiner der
Benutzer, die in der Datei aufgelistet sind, eingeloggt sind. Wenn es keiner
von ihnen ist, wird shutdown
das System nicht neu
starten.
Wenn Sie eine ext2-Partition einbinden, können Sie verschiedene Optionen mit
dem mount-Befehl oder in /etc/fstab
verwenden. Dies ist zum
Beispiel mein fstab-Eintrag für meine /tmp
-Partition:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Sie sehen den Unterschied in der Spalte mit den Optionen. Die Option nosuid ignoriert komplett alle setuid- und setgid-Bits, während noexec das Ausführen von Programmen unterhalb des Einhängepunkts verbietet und nodev Gerätedateien ignoriert. Das hört sich toll an, aber:
dies ist nur auf ext2-Dateisysteme anwendbar
kann leicht umgangen werden
Die noexec-Option, die verhindert, dass Binarys ausgeführt werden können, ließe sich in früheren Kernelversionen leicht umgehen:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
Neuere Versionen des Kernels verarbeiten aber die Option noexec richtig:
angrist:/tmp# mount | grep /tmp /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev) angrist:/tmp# ./date bash: ./tmp: Keine Berechtigung angrist:/tmp# /lib/ld-linux.so.2 ./date ./date: error while loading shared libraries: ./date: failed to map segment from shared object: Operation not permitted
Wie auch immer, viele Skript-Kiddies haben Exploits, die versuchen eine Datei
in /tmp
zu erstellen und auszuführen. Wenn sie keine Ahnung
haben, werden sie in dieser Grube hängen bleiben. Mit anderen Worten: Ein
Benutzer kann nicht hereingelegt werden, einen ausführbaren Trojaner in
/tmp
laufen zu lassen, zum Beispiel indem er zufällig
/tmp
in seinen Suchpfad aufnimmt.
Seien Sie sich auch bewusst, dass manche Skripte darauf aufbauen, dass
/tmp
ausführbare Rechte hat. Bemerkenswerterweise hatte (oder
hat?) Debconf Probleme bei dieser Sache, weitere Informationen enthält Fehler
116448
.
Nachfolgend ein gründlicheres Beispiel. Eine Anmerkung dazu: /var
könnte auch noexec enthalten, aber manche Software [22] verwahrt ihre Programme
unterhalb von /var
. Dasselbe gilt für die nosuid-Option.
/dev/sda6 /usr ext3 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext3 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext3 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext3 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext3 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext3 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext3 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev,nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev,nosuid,noexec 0 0
/tmp
noexec setzen
Seien Sie vorsichtig, wenn Sie /tmp
noexec setzen und neue
Software installieren wollen, da manche Software es während der Installation
benutzt. apt
ist ein solches Programm (siehe http://bugs.debian.org/116448
),
wenn nicht APT::ExtractTemplates::TempDir (siehe
apt-extracttemplates(1)
) passend konfiguriert wurde. Sie können
diese Variable in /etc/apt/apt.conf
auf ein anderes Verzeichnis
als /tmp
mit exec-Privilegien setzen.
Wenn Sie auf /usr
nur lesenden Zugriff erlauben, werden Sie nicht
in der Lage sein, neue Pakete auf Ihrem Debian GNU/Linux System zu
installieren. Sie werden es erst mit Schreibzugriff erneut mounten müssen, die
Pakete installieren und dann wieder nur mit lesendem Zugriff mounten.
apt
kann so konfiguriert werden, dass Befehle vor und nach dem
Installieren von Paketen ausgeführt werden. Vielleicht sollten Sie es passend
konfigurieren.
Dazu öffnen Sie /etc/apt/apt.conf
und fügen Sie Folgendes ein:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Beachten Sie, dass das Post-Invoke mit einer "/usr busy" Fehlermeldung scheitern wird. Dies passiert vorwiegend, wenn Sie eine Datei benutzen, die aktualisiert wurde. Sie können diese Programme finden, indem Sie
# lsof +L1
ausführen.
Halten Sie diese Programme an oder starten Sie sie erneut und rufen dann
Post-Invoke manuell auf. Achtung! Das bedeutet, dass Sie
wahrscheinlich jedes Mal Ihre Sitzung von X (falls Sie eine laufen haben) neu
starten müssen, wenn Sie ein größeres Upgrade Ihres Systems durchführen. Sie
müssen entscheiden, ob ein nur lesbares /usr
zu Ihrem System
passt. Vergleichen Sie auch diese Diskussion
auf debian-devel über nur-lesbares /usr
.
PAM (Pluggable Authentication Modules) erlauben dem Systemadministrator
auszuwählen, wie eine Anwendung Benutzer authentifiziert. Beachten Sie, dass
PAM nichts machen kann, solange die Anwendung nicht mit Unterstützung für PAM
kompiliert wurde. Die meisten Anwendungen, die mit Debian geliefert werden,
haben diese Unterstützung eingebaut. Vor Version 2.2 hatte Debian keine
Unterstützung für PAM. Die derzeitige Standardkonfiguration für jeden Dienst,
der PAM benutzt, ist es, UNIX-Authentifizierung zu emulieren (lesen Sie
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz
, um mehr darüber
zu erfahren, wie PAM-Dienste unter Debian arbeiten sollten).
Jede Anwendung mit PAM-Unterstützung stellt eine Konfigurationsdatei unter
/etc/pam.d/
zur Verfügung, in welcher Sie ihr Verhalten einstellen
können:
welches Verfahren zur Authentifizierung benutzt wird.
welches Verfahren innerhalb einer Sitzung benutzt wird.
wie Passwörter überprüft werden.
Die folgende Beschreibung ist weit davon entfernt, komplett zu sein. Für
weitere Informationen können Sie The
Linux-PAM System Administrator's Guide
(auf der PAM-Hauptseite
)
lesen, diese Dokumentation ist auch in dem Paket libpam-doc
enthalten.
PAM bieten Ihnen die Möglichkeit, durch mehrere Authentifizierungsschritte auf
einmal zu gehen, ohne dass der Benutzer es weiß. Sie können gegen eine
Berkeley Datenbank und gegen die normale passwd
Datei
authentifizieren, und der Benutzer kann sich nur einloggen, wenn er beide Male
korrekt authentifiziert wurde. Sie können viel einschränken mit PAM, genauso
wie Sie Ihr System weit öffnen können. Seien Sie also vorsichtig. Eine
typische Konfigurationszeile hat ein Kontrollfeld als zweites Element.
Generell sollte es auf requisite gesetzt werden, so wird ein
Loginfehler erzeugt, wenn eines der Module versagt.
Die erste Sache, die ich gerne mache, ist, MD5-Unterstützung zu den
PAM-Anwendungen hinzuzufügen, da dies gegen lexikalische Attacken hilft (da
Passwörter länger sein können, wenn sie MD5 benutzen). Die folgenden zwei
Zeilen sollten Sie in allen Dateien unterhalb von /etc/pam.d/
hinzufügen, die Zugriff auf Ihre Maschine gewähren, wie zum Beispiel
login und ssh.
# Gehen Sie sicher, dass Sie libpam-cracklib zuerst installiert haben, # sonst werden Sie sich nicht einloggen können password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
Also, was macht diese Beschwörungsformel nun genau? Die erste Zeile lädt das
cracklib PAM-Modul, welches einen Passwort-Sicherheitscheck bereitstellt. Es
fragt nach einem neuen Passwort mit mindestens 12 Zeichen, einer Differenz von
mindestens 3 Zeichen zum alten Passwort, und erlaubt 3 Versuche. Cracklib
benötigt ein Paket mit Wörterlisten (wie wngerman
,
wenglish
, wspanish
, ...). Stellen Sie also sicher,
dass Sie ein passendes Paket für Ihre Sprache installiert haben. Ansonsten ist
cracklib nicht verwendbar. [23] Die zweite Zeile führt das Standardauthentifizierungsmodul
mit MD5-Passwörtern aus und erlaubt Passwörter mit einer Länge von Null. Die
use_authtok-Anweisung ist notwendig, um das Passwort von dem
vorherigen Modul übergeben zu bekommen.
Um sicher zu stellen, dass sich der Benutzer root nur von lokalen Terminals
einloggen kann, sollten Sie die folgende Zeile in /etc/pam.d/login
eingefügt werden:
auth requisite pam_securetty.so
Danach sollten die Liste der Terminal in /etc/securetty
ändern,
auf denen sich Root unmittelbar anmelden darf. Alternativ dazu können Sie auch
das pam_access-Modul aktivieren und
/etc/security/access.conf
bearbeiten. Dieses Vorgehen erlaubt
eine allgemeinere und feiner abgestimmte Zugangskontrolle, leider fehlen aber
vernünftige Protokollmeldungen (diese sind in PAM nicht standardisiert und sind
ein besonders unbefriedigendes Problem). Wir werden zu
access.conf
in Kürze zurückkehren.
Zu guter Letzt sollte die folgende Zeile in /etc/pam.d/login
aktiviert werden, um den Benutzern Grenzen ihrer Systemressourcen zu setzen.
session required pam_limits.so
Dies schränkt die Systemressourcen ein, die ein Benutzer nutzen darf (siehe Ressourcen-Nutzung limitieren: Die Datei
limits.conf
, Abschnitt 4.10.2). Sie können zum Beispiel die
Anzahl der Logins, die man haben kann, einschränken (für eine Gruppe von
Nutzern oder systemweit), die Anzahl der Prozesse, den belegten Speicher etc.
Editieren Sie nun /etc/pam.d/passwd
und ändern Sie die erste
Zeile. Sie sollten die Option "md5" zufügen, um MD5-Passwörter zu
benutzen, ändern Sie die minimale Passwort-Länge von 4 auf 6 (oder mehr) und
setzen Sie eine Maximallänge, wenn Sie möchten. Die resultierende Zeile wird
in etwa so aussehen:
password required pam_unix.so nullok obscure min=6 max=11 md5
Wenn Sie su schützen möchten, so dass nur manche Leute es benutzen können, um
root auf Ihrem System zu werden, müssen Sie eine neue Gruppe "wheel"
zu Ihrem System hinzufügen (das ist der sauberste Weg, da keine Datei solche
Gruppenrechte bisher benutzt). Fügen Sie root und die anderen Benutzer, die zu
root su
en können sollen, zu dieser Gruppe. Fügen Sie anschließend
die folgende Zeile zu /etc/pam.d/su/
hinzu:
auth requisite pam_wheel.so group=wheel debug
Dies stellt sicher, dass nur Personen aus der Gruppe "wheel"
su
benutzen können, um root zu werden. Andere Benutzer wird es
nicht möglich sein, root zu werden. Tatsächlich werden Sie eine ablehnende
Nachricht bekommen, wenn Sie versuchen root zu werden.
Wenn Sie es nur bestimmten Nutzern erlauben wollen, sich bei einem PAM-Dienst
zu authentifizieren, ist dies sehr leicht zu erreichen, indem Sie Dateien
benutzen, in denen die Nutzer, denen es erlaubt ist, sich einzuloggen (oder
nicht), gespeichert sind. Stellen Sie sich vor, Sie möchten lediglich dem
Nutzer 'ref' erlauben, sich mittels ssh
einzuloggen. Sie
schreiben ihn also in eine Datei /etc/ssh-users-allowed
und
schreiben das Folgende in /etc/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Da es eine Reihe von Sicherheitslücken mit so genannten unsicheren temporären
Dateien zum Beispiel in thttpd (vgl. DSA-883-1
) gab,
lohnt es sich, das Paket libpam-tmpdir
zu installieren. Alles,
was Sie machen müssen, ist, Folgendes zu /etc/pam.d/common-session
hinzuzufügen:
session optional pam_tmpdir.so
Es gab auch eine Diskussion, dies standardmäßig in Etch einzufügen. Sehen Sie
sich http://lists.debian.org/debian-devel/2005/11/msg00297.html
für weitere Informationen an.
Zuletzt, aber nicht am unwichtigsten, erstellen Sie
/etc/pam.d/other
mit den folgenden Zeilen:
auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so
Diese Zeilen stellen für alle Anwendungen, die PAM unterstützen, eine gute Standard-Konfiguration dar (Zugriff wird standardmäßig verweigert).
limits.conf
Sie sollten sich wirklich ernsthaft mit dieser Datei beschäftigen. Hier können
Sie Ihren Benutzern Ressourcen-Limits definieren. In alten Veröffentlichungen
war die Konfigurationsdatei /etc/limits.conf
. Aber in neueren
Versionen (mit PAM) sollte stattdessen die Konfigurationsdatei
/etc/security/limits.conf
benutzt werden.
Wenn Sie die Ressourcennutzung nicht einschränken, kann jeder Nutzer mit einer gültigen Shell auf Ihrem System (oder sogar ein Einbrecher, der das System durch einen Dienst kompromittierte, oder ein außer Kontrolle geratener Daemon) so viel CPU, Speicher, Stack etc. benutzen, wie das System zur Verfügung stellen kann. Dieses Problem der Überbeanspruchung von Ressourcen kann mit der Nutzung von PAM gelöst werden.
Es gibt einen Weg, Ressourcen-Limits zu manchen Shells hinzuzufügen (zum
Beispiel hat bash
ulimit
, siehe
bash(1)
). Aber da nicht alle die gleichen Limits zur Verfügung
stellen, und da der Nutzer seine Shell ändern kann (siehe
chsh(1)
), ist es besser, die Limits in den PAM-Modulen zu
platzieren, da diese unabhängig von der verwendeten Shell Anwendung finden und
auch PAM-Module betreffen, die nicht shellorientiert sind.
Ressourcen-Limits werden vom Kernel verhängt, aber sie müssen durch
limits.conf
konfiguriert werden, und die PAM-Konfiguration der
verschiedenen Dienste muss das passende PAM laden. Sie können herausfinden,
welche Dienste Limits durchsetzen, indem Sie Folgendes ausführen:
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Für gewöhnlich nehmen login
, ssh
und die grafischen
Sitzungsmanager (gdm
, kdm
und xdm
)
Nutzerlimits in Anspruch, aber Sie sollte dies auch in anderen
Konfigurationsdateien für PAM wie für cron
tun, um zu verhindern,
dass Systemdaemonen alle Systemressourcen aufbrauchen.
Die konkreten Begrenzungen, die Sie festlegen wollen, hängt von den Ressourcen Ihres Systems ab. Das ist einer der Hauptgründe, warum keine Limits in der Standardinstallation enthalten sind.
Zum Beispiel nimmt die Konfiguration im Beispiel unten eine Begrenzung von 100 Prozessen für alle Nutzer vor (um Fork-Bomben [24] zu vermeiden) und eine Begrenzung auf 10MB Speicher pro Prozess und ein Limit von 10 gleichzeitigen Logins. Benutzer in der Gruppe adm haben höhere Begrenzungen und können Dateien mit einem Speicherabbild schreiben, wenn sie das wollen (es gibt also nur eine weiche Begrenzung).
* soft core 0 * hard core 0 * hard rss 1000 * hard memlock 1000 * hard nproc 100 * - maxlogins 1 * hard data 102400 * hard fsize 2048 @adm hard core 100000 @adm hard rss 100000 @adm soft nproc 2000 @adm hard nproc 3000 @adm hard fsize 100000 @adm - maxlogins 10
Dies könnten die Limits eines Standardnutzers (einschließlich der Systemdaemonen) sein:
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) 102400 file size (blocks, -f) 2048 max locked memory (kbytes, -l) 10000 max memory size (kbytes, -m) 10000 open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited
Und dies die Limits für einen Administrator:
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) 102400 file size (blocks, -f) 100000 max locked memory (kbytes, -l) 100000 max memory size (kbytes, -m) 100000 open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2000 virtual memory (kbytes, -v) unlimited
Für mehr Informationen hierzu lesen Sie:
Seifried's
Securing Linux Step by Step
in dem Limiting users overview
Abschnitt.
LASG
in dem
Limiting and monitoring users Abschnitt.
/etc/login.defs
Der nächste Schritt ist es, die grundlegende Konfiguration und die Aktionen bei
User-Login zu editieren. Beachten Sie, dass diese Datei kein Bestandteil der
PAM-Konfiguration ist. Sie ist eine Konfigurationsdatei, die von den
Programmen login- und su berücksichtigt wird. Es ist
also wenig sinnvoll, sie auf Fälle abzustimmen, in denen keines der beiden
Programme wenigstens indirekt aufgerufen wird (Das Programm getty
,
welches auf der Konsole läuft und die anfängliche Loginaufforderung zu
Verfügung stellt, ruft login
auf).
FAIL_DELAY 10
Diese Variable sollte auf einen höheren Wert gesetzt werden, um es schwerer zu
machen, mittels Brute Force (roher Gewalt, stures Durchprobieren, Anm. d.
Übers.) auf einem Terminal einzuloggen. Wenn ein falsches Passwort eingegeben
wird, muss der potenzielle Angreifer (aber auch der normale Benutzer!) 10
Sekunden warten, um einen neuen login Prompt zu bekommen, was auf die Dauer
viel Zeit kostet, wenn sie Passwörter durch testen. Beachten Sie jedoch die
Tatsache, dass diese Einstellung nutzlos ist, wenn Sie ein anderes Programm als
getty
benutzen, wie zum Beispiel mingetty
.
FAILLOG_ENAB yes
Wenn Sie diese Variable einschalten, werden fehlgeschlagene Logins protokolliert. Es ist wichtig, hier auf dem Laufendem zu bleiben, um jemanden zu fassen, der eine Brute-Force-Attacke versucht.
LOG_UNKFAIL_ENAB no
Wenn Sie diese Variable auf 'yes' setzen, werden auch unbekannte Benutzernamen protokolliert, wenn eine Anmeldung scheitert. Es ist zu empfehlen, sie auf 'no' (den Standard) zu belassen, da anderenfalls das Passwort eines Benutzers aufgezeichnet werden könnte (falls er nämlich versehentlich anstatt seines Benutzernames sein Passwort eingibt). Falls Sie sie dennoch auf 'yes' setzen, müssen Sie sicher gehen, dass die Protokolldateien angemessene Zugriffsrechte haben (zum Beispiel 640, mit einer passenden Gruppen-Zugehörigkeit wie adm).
SYSLOG_SU_ENAB yes
Dies schaltet das Mitprotokollieren von su
-Versuchen im
Syslog
ein. Sehr wichtig auf ernsthaften Maschinen, aber beachten
Sie, dass dies auch die Privatsphäre verletzen kann.
SYSLOG_SG_ENAB yes
Das gleiche wie bei SYSLOG_SU_ENAB, jedoch für das Programm
sg
.
MD5_CRYPT_ENAB yes
Wie bereits erklärt, reduzieren MD5-Summen-Passwörter großartig das Problem lexikalischer Attacken, da Sie längere Passwörter benutzen können. Wenn Sie slink benutzen, lesen Sie die Dokumentation zu MD5, bevor Sie diese Option einschalten. Ansonsten wird dies in PAM gesetzt.
PASS_MAX_LEN 50
Wenn Sie MD5-Passwörter in Ihrer PAM Konfiguration aktiviert haben, dann sollten Sie diese Variable auf denselben Wert setzen, den Sie dort benutzt haben.
/etc/ftpusers
Die Datei /etc/ftpusers
enthält eine Liste von allen Nutzern,
denen es nicht erlaubt ist, sich auf dem Rechner mit ftp einzuloggen.
Benutzen Sie diese Datei nur, wenn Sie wirklich ftp erlauben wollen (wozu im
Allgemeinen nicht geraten wird, da es Klartext-Passwörter benutzt). Wenn Ihr
ftp-Daemon PAM unterstützt, können Sie dies ebenfalls benutzen, um Nutzern
bestimmte Dienste zu erlauben oder zu verbieten.
FIXME (FEHLER): Ist es ein Fehler, dass ftpusers
in Debian
standardmäßig nicht die Benutzer mit Administratorenrecht (in
base-passwd
) beinhaltet?
Folgender Befehl ist ein einfacher Weg, alle Systemkonten zu
/etc/ftpusers
hinzuzufügen:
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers
Wenn es wirklich benötigt wird, dass Nutzer der Super-User (also Root, d.Ü.)
auf Ihrem System werden, zum Beispiel um Pakete zu installieren oder neue
Benutzer anzulegen, können Sie das Programm su
benutzen, um Ihre
Identität zu wechseln. Sie sollten jeden Login als Nutzer Root vermeiden und
stattdessen das Programm su
benutzen. Eigentlich ist die beste
Lösung, su
zu entfernen und zu sudo
zu wechseln, da
es eine feinere Steuerung und mehr Möglichkeiten bietet als su
.
Wie auch immer, su
ist verbreiteter und wird auf vielen Unices
benutzt.
Das sudo
erlaubt es dem Benutzer, ein definiertes Kommando unter
einer anderen Nutzeridentität auszuführen, sogar als Root. Wenn der Nutzer zu
/etc/sudoers
hinzugefügt ist und sich korrekt authentifiziert, ist
er in der Lage, Kommandos, die in /etc/sudoers
definiert wurden,
auszuführen. Sicherheitsverletzungen, wie ein inkorrektes Passwort oder der
Versuch ein Programm auszuführen, für das Ihre Rechte nicht ausreichen, werden
protokolliert und an root gemailt.
Sie sollten /etc/security/access.conf
ebenfalls so verändern, dass
ein Login aus der Ferne in ein administratives Konto nicht erlaubt wird. Auf
diese Weise müssen die Nutzer das Programm su
(oder
sudo
) aufrufen, um Administratorenrechte zu bekommen, so dass es
immer eine nachprüfbare Spur gibt.
Sie müssen die folgende Zeile zu Ihrer /etc/security/access.conf
hinzufügen, die Debians Standardkonfigurationsdatei hat ein Beispiel
auskommentiert:
-:wheel:ALL EXCEPT LOCAL
Vergessen Sie nicht, in /etc/pam.d/
das
pam_access-Module für jeden Dienst (oder jede
Standardkonfiguration) anzuschalten, wenn Sie wollen, dass Ihre Änderungen an
/etc/security/access.conf
berücksichtigt werden.
Manchmal werden Sie vielleicht denken, dass Sie einen Nutzer auf Ihrem System erstellen müssen, um einen bestimmten Dienst (pop3 E-Mail Server oder ftp) anzubieten. Bevor Sie dies tun, erinnern Sie sich zuerst daran, dass die PAM Implementierung in Debian GNU/Linux Ihnen erlaubt, Nutzer mit einer breiten Auswahl von externen Verzeichnisdiensten (radius, ldap, etc.) zu bestätigen. Dies wird vom libpam-Paket bewerkstelligt.
Wenn Sie einen Nutzer anlegen müssen, und auf Ihr System aus der Ferne
zugegriffen werden kann, beachten Sie, dass es Nutzern möglich sein wird, sich
einzuloggen. Sie können dies beheben, indem Sie diesen Nutzern eine Null
(/dev/null
) als Shell (sie müsste in /etc/shells
aufgelistet sein) zuweisen. Wenn Sie den Nutzern erlauben wollen, auf das
System zuzugreifen, aber ihre Bewegungen einschränken wollen, können Sie
/bin/rbash
benutzen. Dies hat das gleiche Ergebnis, wie wenn Sie
die -r Option der Bash
(RESTRICTED SHELL,
siehe bash(1)
) verwendet hätten. Beachten Sie bitte, dass sogar
mit einer beschränkten Shell ein Nutzer, der auf ein interaktives Programm
zugreifen kann (das ihm erlaubt, eine Subshell auszuführen), diese Limitierung
der Shell umgehen kann.
Debian bietet zurzeit in seiner Unstable-Veröffentlichung (und wird es
vielleicht der nächsten Stable-Veröffentlichung hinzufügen) das
pam_chroot
-Modul (in libpam-chroot
) an. Eine
Alternative hierzu ist es, die Dienste, die eine Fernanmeldung ermöglichen
(ssh
und telnet
), in einer
chroot
-Umgebung laufen zu lassen. [25]
Wenn Sie einschränken wollen, wann ein Nutzer auf das System zugreifen
kann, müssen sie /etc/security/access.conf
an Ihre Bedürfnisse
anpassen.
Informationen, wie man Benutzer, die auf das System mittels dem
ssh
-Dienst zugreifen, in eine chroot
-Umgebung
einsperrt, wird in Chroot
-Umgebung für
SSH
, Anhang G beschrieben.
Wenn Sie wirklich paranoid sind, sollten Sie vielleicht eine systemweite Einrichtung verwenden, um zu überwachen, was die Benutzer auf Ihrem System tun. In diesem Abschnitt werden eine Tipps vorgestellt, wie Sie verschiedene Werkzeuge verwenden.
Um sowohl die von den Nutzern ausführten Programme als auch deren Ergebnisse zu
überwachen, können Sie den Befehl script
verwenden. Sie können
script
nicht als eine Shell einsetzen (auch dann nicht, wenn Sie
es zu /etc/shells
hinzufügen). Aber Sie können in die Datei,
welche den Startvorgang der Shell steuert, folgendes eintragen:
umask 077 exec script -q -a "/var/log/sessions/$USER"
Wenn Sie auswerten wollen, was die Benutzer in die Shell eingeben (aber nicht
was das Ergebnis ist), können Sie eine systemweite /etc/profile
so
einrichten, dass alle Befehle in der History-Datei (Verlaufsdatei)
gespeichert werden. Die systemweite Einstellung muss so eingerichtet werden,
dass Benutzer die Auditmöglichkeit nicht aus ihrer Shell entfernen können. Ob
dies möglich ist, hängt von der Art der Shell ab. Sie müssen also
sicherstellen, dass alle Benutzer eine Shell verwenden, die das unterstützt.
Für die Bash zum Beispiel könnte /etc/profile
folgendermaßen
aufgebaut werden [26] :
HISTFILE=~/.bash_history HISTSIZE=10000 HISTFILESIZE=999999 # Don't let the users enter commands that are ignored # in the history file HISTIGNORE="" HISTCONTROL="" readonly HISTFILE readonly HISTSIZE readonly HISTFILESIZE readonly HISTIGNORE readonly HISTCONTROL export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
Damit dies funktioniert, dürfen die Nutzer nur Informationen zur
.bash_history
-Datei hinzufügen. Sie müssen daher
zusätzlich die append-only-Option (nur-anfügen) mittels des
Programms chattr
für die .bash_history
aller Nutzer
setzen [27].
Beachten Sie, dass Sie obige Konfiguration auch in .profile
des
Benutzers eintragen können. Dann müssten Sie aber die Rechte korrekt vergeben,
so dass der Benutzer daran gehindert ist, diese Datei zu verändern. Dies
schließt ein, dass das Home-Verzeichnis der Benutzers diesem nicht
gehört (sonst könnte er die Datei einfach löschen). Gleichzeitig müsste ihm
ermöglicht werden, die Konfigurationsdatei .profile
zu lesen und
in .bash_history
zu schreiben. Falls Sie diesen Weg gehen wollen,
wäre es auch gut, das immutable-Flag (unveränderbar) für
.profile
zu setzen (auch dazu verwenden Sie chattr
).
Die vorherigen Beispiele sind ein einfacher Weg, um die Überwachung von Nutzern
einzurichten. Sie eignen sich aber nicht unbedingt für komplexe Systeme oder
für solche, auf denen die Nutzer überhaupt keine (oder ausschließlich) Shells
am Laufen haben. Sollte dies der Fall sein, schauen Sie sich das Paket
acct
an, das Werkzeuge zur Bilanzierung (accounting utilities)
enthält. Diese werden alle Kommandos, die ein Nutzer oder ein Prozess auf dem
System ausführt, auf die Kosten von Plattenplatz aufzeichnen.
Wenn Sie diese Bilanzierung aktivieren, werden alle Informationen über Prozesse
und Nutzer unter /var/account/
gespeichert, genauer gesagt in
pacct
. Das Accounting-Paket schließt einige Werkzeuge
(sa
, ac
und lastcomm
) zur Analyse dieser
Daten ein.
Wenn Sie wirklich paranoid sind und jedes Kommando des Nutzers protokollieren
wollen, könnten Sie den Quellcode der Bash
so ändern, dass sie
alles, das der Nutzer eingibt in einer anderen Datei ablegt. Oder Sie lassen
ttysnoop
ununterbrochen jedes neue tty [28] überwachen und die Ausgaben in
einer Datei speichern. Ein anderes nützliches Programm ist snoopy
(vergleichen Sie auch the project
page
). Dies ist ein für den Nutzer transparentes Programm, das sich
als eine Bibliothek einhängt und eine Hülle um execve()-Aufrufe
bildet. Jedes ausgeführte Kommando wird im syslogd
aufgezeichnet,
indem die authpriv-Möglichkeit benutzt wird (üblicherweise wird
dies unter /var/log/auth.log
gespeichert).
Wenn Sie sehen wollen, was Nutzer tatsächlich tun, wenn sie sich beim
System anmelden, können Sie die wtmp
-Datenbank benutzen, die alle
Login-Informationen enthält. Diese Datei kann mit verschiedenen Werkzeugen
weiterverarbeitet werden, unter ihnen sac
, das ein Profil für
jeden Nutzer ausgeben kann und zeigt, in welchem Zeitfenster sie sich für
gewöhnlich auf dem System einloggen.
Für den Fall, dass Sie Accounting aktiviert haben, können Sie auch die mitgelieferten Werkzeuge verwenden, um festzustellen, wann Nutzer auf das System zugreifen und was sie ausführen.
Abhängig von Ihren Richtlinien möchten Sie vielleicht ändern, wie Nutzer Informationen teilen können. Dabei geht es um die Standardrechte von neu erstellten Dateien.
Wenn die Standardwerte von Debian für Ihr System zu großzügig sind, müssen Sie die umask-Einstellungen für alle Shells ändern. Strengere Umask-Einstellungen sind 027 (kein Zugriff der Gruppe other auf neue Dateien, dazu zählen andere Benutzer auf dem System) oder 077 (kein Zugriff der Mitglieder der Gruppe des Benutzers). Debian erzeugt (standardmäßig[29]) für jeden Benutzer eine eigene Gruppe, so dass das einzige Gruppenmitglied der Benutzer selbst ist. Daher ergibt sich zwischen 027 und 077 kein Unterschied, da die Benutzergruppe nur den Benutzer selbst enthält.
Dies ändern Sie, indem Sie eine passende umask für alle Benutzer
einstellen. Dazu müssen Sie einen umask
-Aufruf in den
Konfigurationsdateien aller Shells einfügen: /etc/profile
(wird
von allen Shells beachtet, die kompatibel mit Bourne sind),
/etc/csh.cshrc
, /etc/csh.login
,
/etc/zshrc
und wahrscheinlich noch ein paar andere (je nachdem,
welche Shells Sie auf Ihrem System installiert haben). Sie können auch die
UMASK-Einstellung in /etc/login.defs
verändern. Von
all diesen Dateien erlangt die letzte, die von der Shell geladen wird, Vorrang.
Die Reihenfolge lautet: die Standard-System-Konfiguration für die Shell des
Benutzers (d.h. /etc/profile
und andere systemweite
Konfigurationsdateien) und dann die Shell des Benutzers (seine
~/.profile
) und ~/.bash_profile
etc.). Allerdings
können einige Shells mit dem nologin-Wert ausgeführt werden, was
verhindern kann, dass einige dieser Dateien ausgewertet werden. Sehen Sie in
der Handbuchseite Ihrer Shell für weitere Informationen nach.
Bei Anmeldungen, die von login
Gebrauch machen, erhält die
UMASK-Festlegung in /etc/login.defs
Vorrang vor allen anderen
Einstellungen. Dieser Wert wird aber nicht von Anwendungen des Benutzers
beachtet, die nicht login
verwenden, wie z.B. solche, die durch
su
, cron
oder ssh
ausgeführt werden.
Vergessen Sie nicht, die Dateien unter /etc/skel/
zu überprüfen
und gegebenenfalls anzupassen, da dort die Standards für Benutzer festgelegt
werden, die mit dem Befehl adduser
erstellt werden. Standardmäßig
enthalten die Dateien in Debian keinen Aufruf von umask
. Wenn
sich aber ein solcher in Konfigurationsdateien befindet, sind neue Benutzer
eher geneigt, ihn ihren Bedürfnissen anzupassen.
Beachten Sie allerdings, dass ein Nutzer seine umask-Einstellung abändern kann, wenn er es möchte, um sie großzügiger oder einschränkender zu machen, indem er seine Konfigurationsdateien verändert.
Das Paket libpam-umask
passt die Standard-umask eines
Benutzers mit Hilfe von PAM an. Nachdem Sie das Paket installiert haben,
tragen Sie Folgendes in /etc/pam.d/common-session
ein:
session optional pam_umask.so umask=077
Zu guter Letzt sollte Sie in Betracht ziehen, die Standard-Umask von Root (022,
wird in /root/.bashrc
festgelegt) auf einen strengeren Wert zu
verändern. Damit kann verhindert werden, dass der Systemadministrator als Root
sensible Dateien in von allen lesbaren Verzeichnissen (wie z.B.
/tmp
) ablegt und sie so dem Durchschnittsbenutzer zugänglich
macht.
FIXME: Inhalt benötigt. Aufzeigen der Folgen beim Upgraden, wenn die
Paketrechte verändert werden, falls nicht dpkg-statoverride
verwendet wird (übrigens sollte ein derartig paranoider Administrator seine
Nutzer in eine chroot
-Umgebung einsperren).
Wenn Sie einem Nutzer Zugriff auf das System mit einer Shell gewähren müssen, sollten Sie vorsichtig sein. Ein Nutzer kann normalerweise, wenn er sich nicht in einer streng abgeschirmten Umgebung befindet (z.B. in einem chroot-Gefängnis), ziemlich viel Informationen über Ihr System sammeln. Darunter fallen:
einige Konfigurationsdateien unter /etc
. Jedoch werden Debians
Standardrechte für sensible Dateien (die zum Beispiel Passwörter enthalten
könnten) den Zugriff auf kritische Informationen verhindern. Um zu sehen, auf
welche Dateien nur der root Nutzer zugreifen kann, führen Sie zum Beispiel
find /etc -type f -a -perm 600 -a -uid 0 als Superuser aus.
Ihre installierten Pakete. Indem man die Paket-Datenbank und das
/usr/share/doc
-Verzeichnis ansieht, oder indem man mit Hilfe der
auf Ihrem System installierten Binaries und Bibliotheken versucht zu raten.
einige Protokolle unter /var/log
. Beachten Sie, dass auf einige
Protokolle nur Root und die adm-Gruppe zugreifen kann (versuchen
Sie find /var/log -type f -a -perm 640). Manche sind sogar
ausschließlich für Root verfügbar (sehen Sie sich find /var/log -type f
-a -perm 600 -a -uid 0 an).
Was kann ein Nutzer von Ihrem System sehen? Wahrscheinlich ziemlich viele Sachen, versuchen Sie mal Folgendes (und jetzt tief durchatmen):
find / -type f -a -perm +006 2>/dev/null find / -type d -a -perm +007 2>/dev/null
Was Sie sehen, ist eine Liste von allen Dateien, die ein Nutzer einsehen kann, und die Verzeichnisse, auf die er Zugriff hat.
Wenn Sie immer noch Benutzern einen Shellzugang zur Verfügung stellen wollen, sollten Sie vielleicht die Informationen begrenzen, die man über anderen Nutzern einholen kann. Nutzer mit einer Shell haben die Neigung, eine ziemlich große Anzahl von Dateien in ihrem $HOME zu erstellen: Mailboxen, persönliche Daten, Konfigurationen für X/GNOME/KDE-Anwendungen ...
In Debian wird jeder Nutzer mit einer zugehörigen Gruppe erstellt. Verschiedene Nutzer gehören dabei nie zur selben Gruppe. Folgendes ist das Standardverhalten: Wenn ein Benutzerkonto angelegt wird, wird auch eine Gruppe mit dem gleichen Namen erstellt. Dieser Gruppe wird der Nutzer zugewiesen. Damit wird die Idee einer allgemeinen users-Gruppe überflüssig, die es Nutzern erschweren könnte, Informationen vor anderen Nutzern zu verstecken.
Allerdings wird das $HOME-Verzeichnis der Benutzer mit 0755-Rechten (lesbar von der Gruppe, lesbar von der Welt) erstellt. Die Rechte Für die Gruppe sind kein Thema, da nur der Nutzer zu dieser Gruppe gehört. Allerdings könnten die Rechte für die Welt ein Problem darstellen, wobei dies von Ihren lokalen Grundsätzen abhängt.
Sie können dieses Verhalten so abändern, dass das Erstellen eines Nutzers
andere Rechte für $HOME liefert. Um dieses Verhalten für
neue Nutzer zu ändern, wenn sie erstellt werden, ändern Sie in der
Konfigurationsdatei /etc/adduser.conf
DIR_MODE auf 0750
(nicht lesbar für die Welt) ab.
Benutzer können immer noch Informationen austauschen, aber nicht mehr unmittelbar in ihrem $HOME-Verzeichnis, es sei denn, dass sie dessen Recht verändert haben.
Wenn Sie den Lesezugriff auf die Home-Verzeichnisse für die Welt verhindert,
sollten Sie beachten, dass dann Nutzer ihre persönlichen Webseiten nicht unter
~/public_html
erstellen können, da der Webserver einen Teil des
Pfads nicht lesen kann – und zwar das $HOME-Verzeichnis. Wenn
Sie es Nutzern erlauben wollen, ihre HTML-Seiten in ihrem
~/public_html
zu veröffentlichen, sollten Sie DIR_MODE
auf 0751 setzen. Das ermöglicht dem Webserver Zugang zum
public_html
-Verzeichnis (welches selber die Rechte 0755 haben
sollte). So kann er den von den Nutzern veröffentlichten Inhalt anbieten.
Natürlich sprechen wir hier nur über die Standardeinstellung. Benutzer können
grundsätzlich die Rechte für ihre eigenen Dateien nach ihrem Gutdünken
vergeben. Oder Sie können die Dinge, die für das Web bestimmt sind, in einem
getrennten Ort ablegen, der kein Unterverzeichnis vom
$HOME-Verzeichnis des Nutzers ist.
In vielen Fällen muss ein Administrator viele Benutzerkonten erstellen und alle
mit Passwörtern ausstatten. Der Administrator könnte natürlich einfach als
Passwort den Namen des Nutzerkontos vergeben. Dies wäre aber unter
Sicherheitsgesichtspunkten nicht sehr klug. Ein besseres Vorgehen ist es, ein
Programm zur Erzeugung von Passwörtern zu verwenden. Debian stellt die Pakete
makepasswd
, apg
und pwgen
zur Verfügung,
die Programme liefern (deren Name ist der gleiche wie der des Pakets), die zu
diesem Zweck verwendet werden können. Makepasswd
erzeugt wirklich
zufällige Passwörter, gibt also der Sicherheit gegenüber der Aussprechbarkeit
den Vorzug. Dagegen versucht pwgen
, bedeutungslose, aber
aussprechbare Passwörter herzustellen (dies hängt natürlich auch von Ihrer
Muttersprache ab). Apg
liefert Algorithmen für beide
Möglichkeiten (Es gibt auch eine Client/Server-Version dieses Programms. Diese
befindet sich aber nicht im Debian-Paket).
Passwd
erlaubt nur die interaktive Zuweisung von Passwörtern (da
es direkt den tty-Zugang benutzt). Wenn Sie Passwörter ändern wollen, wenn Sie
eine große Anzahl von Benutzern erstellen, können Sie diese unter der
Verwendung von adduser
mit der
--disabled-login-Option erstellen, und danach usermod
oder chpasswd
[30]
benutzen (beide Programme stammen aus dem passwd
-Paket. Sie haben
sie also schon installiert). Wenn Sie lieber eine Datei verwenden, die alle
Informationen zur Erstellung von Nutzern als Batch-Prozess enthält, sind Sie
vielleicht mit newusers
besser dran.
Die Passwörter der Nutzer sind manchmal die schwächste Stelle der
Sicherheit eines Systems. Das liegt daran, dass manche Nutzer schwache
Passwörter für ihr Konto wählen (und je mehr Nutzer Zugang zum System haben,
umso größer die Chance, dass das passiert). Selbst wenn Sie Überprüfungen mit
dem PAM-Module cracklib und Grenzen für Passwörter einsetzen, wie in Nutzerauthentifizierung: PAM, Abschnitt 4.10.1
beschrieben wird, ist es Nutzern immer noch möglich, schwache Passwörter zu
verwenden. Da der Zugang der Nutzer auch den Zugang aus der Ferne (hoffentlich
über ssh
) umfassen kann, ist es wichtig, dass das Erraten von
Passwörtern für entfernte Angreifer so schwierig wie möglich ist. Dies gilt
insbesondere dann, wenn es ihnen gelungen sein sollte, Zugang zu wichtigen
Informationen wie den Benutzernamen oder sogar den Dateien passwd
und shadow
selbst zu bekommen.
Ein Systemadministrator muss bei einer großen Anzahl von Nutzern überprüfen, ob
deren Passwörter mit den lokalen Sicherheitsmaßstäben in Einklang stehen. Und
wie überprüft man das? Indem man versucht, sie wie ein Angreifer zu knacken,
der Zugriff auf die gehashten Passwörter hat (also auf die Datei
/etc/shadow
).
Ein Administrator kann john
oder crack
(beide
benutzen Brute-Force (Rohe Gewalt) zum Knacken von Passwörtern) zusammen mit
einer passenden Wörterliste verwenden, um die Passwörter der Nutzer zu
überprüfen, und falls ein schlechtes Passwort entdeckt wird, geeignete Schritte
unternehmen. Sie können mit apt-cache search wordlist
nach
Debian/GNU-Paketen suchen, die Wörterlisten enthalten, oder Sie besuchen die
klassischen Internetseiten mit Wörterlisten wie ftp://ftp.ox.ac.uk/pub/wordlists
oder ftp://ftp.cerias.purdue.edu/pub/dict
.
Untätige (idle) Nutzer stellen für gewöhnlich ein Sicherheitsproblem dar. Ein Nutzer kann untätig sein, da er Mittagessen ist, oder weil eine entfernte Verbindung hängen blieb und nicht wieder hergestellt wurde. Unabhängig von den Gründen können untätige Benutzer zu einer Kompromittierung führen:
weil die Konsole des Benutzers vielleicht nicht verriegelt ist und damit ein Eindringling darauf zugreifen kann.
weil ein Angreifer an eine schon beendete Netzwerkverbindung anknüpfen und
Befehle an die entfernte Shell schicken kann (das ist ziemlich einfach, wenn
die entfernte Shell, wie bei telnet
, nicht verschlüsselt ist).
In einige entfernte System wurde sogar schon durch ein untätiges (und
abgelöstes) screen
eingedrungen.
Die automatische Trennung von untätigen Benutzern ist gewöhnlich ein Teil der lokalen Sicherheitsregeln, die durchgesetzt werden müssen. Es gibt mehrere Wege, dies zu tun:
Wenn die Shell des Benutzers die Bash
ist, kann ein
Systemadministrator TMOUT einen Standardwert zuweisen (vergleich
bash(1)
). Das hat zur Folge, dass die Shell automatisch entferne,
untätige Nutzer ausloggt. Beachten Sie, dass der Wert mit der
-o-Option gesetzt werden muss. Ansonsten wäre es den Nutzern
möglich, ihn zu verändern (oder zu löschen).
Installieren Sie timeoutd
und konfigurieren Sie
/etc/timeouts
passend zu Ihren lokalen Sicherheitsrichtlinien.
Der Daemon achtet auch untätige Nutzer und beendet ihre Shells gegebenenfalls.
Installieren Sie autolog
und richten Sie es so ein, dass es
untätige Nutzer entfernt.
Vorzugswürdige Methoden sind die Daemonen timeoutd
und
autolog
, da letzten Endes die Nutzer ihre Standardshell ändern
können oder zu einer anderen (unbeschränkten) Shell wechseln können, nachdem
sie ihre Standardshell gestartet haben.
TCP-Wrapper (Schutzumschläge für TCP) wurden entwickelt, als es noch keine
echten Paketfilter gab, aber Zugangskontrollen notwendig waren. Trotzdem sind
sie immer noch hoch interessant und nützlich. Ein TCP-Wrapper erlaubt Ihnen,
einem Host oder einer Domain einen Dienst anzubieten oder zu verweigern, und
standardmäßig Zugriff zu erlauben oder zu verweigern (das alles wird auf der
Anwendungsebene durchgeführt). Wenn Sie mehr Informationen haben möchten,
sehen Sie sich hosts_access(5)
an.
Viele der unter Debian installierten Dienste
werden entweder durch den TCP-Wrapper Service (tcpd
) aufgerufen,
oder wurden mit libwrapper (Bibliothek für TCP-Wrapper) Unterstützung kompiliert.
Einerseits werden Sie bei manchen Diensten (einschließlich telnet
,
ftp
, netbios
, swat
und
finger
), die in /etc/inetd.conf
konfiguriert werden,
sehen, dass die Konfigurationsdatei zuerst /usr/sbin/tcpd
aufruft.
Andererseits, selbst wenn ein Dienst nicht über den
inetd
-Superdaemon ausgeführt wird, kann die Unterstützung von
Tcp-Wrapper einkompiliert werden. Dienste, die unter Debian mit TCP-Wrappern
kompiliert wurden, sind ssh
, portmap
,
in.talk
, rpc.statd
, rpc.mountd
,
gdm
, oaf
(der GNOME-Aktivierungs-Daemon),
nessus
und viele andere.
Um herauszufinden, welche Pakete TCP-Wrapper benutzen[31], versuchen Sie Folgendes:
$ apt-cache rdepends libwrap0
Beachten Sie bitte Folgendes, wenn Sie tcpchk
(ein sehr nützliches
Programm zur Überprüfung der TCP-Wrapper-Konfiguration und -Syntax) laufen
lassen. Wenn Sie Stand-Alone-Dienste (alleinstehende Dienste, also solche, die
direkt mit der Wrapper-Bibliothek verbunden sind) der host.deny
-
oder host.allow
-Datei hinzufügen, wird tcpchk
Sie
warnen, dass er sie nicht finden kann, da er sie nur in
/etc/inetd.conf
sucht (die Handbuchseite ist an dieser Stelle
nicht sehr genau).
Jetzt kommt ein kleiner Trick und vielleicht die kleinste Alarmanlage zur
Erkennung von Eindringlingen: Im Allgemeinen sollten Sie eine anständige
Firewall als erste und TCP-Wrapper als zweite Verteidigungslinie haben. Der
Trick besteht nun darin, ein SPAWN-Kommando [32] in
/etc/hosts.deny
einzutragen, das immer dann eine Mail an Root
schickt, wenn ein Dienst abgewiesen wurde:
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Verbindungsaufbau abgelehnt\n\ By\: $(uname -n)\n\ Prozess\: %d (pid %p)\n\ Nutzer\: %u\n\ Host\: %c\n\ Datum\: $(date)\n\ " | /usr/bin/mail -s "Verbindung zu %d blockiert" root) &
Achtung: Das obige Beispiel kann sehr leicht zu DoS (Denial of Service, Verbindungsaufbau abgelehnt) führen, indem man versucht, sehr viele Verbindungen in kurzer Zeit aufzubauen. Viele E-Mails bedeuten viel Dateiaktivität, die lediglich durch das Senden von ein paar Paketen erreicht wird.
Es ist leicht einzusehen, dass die Behandlung von Logs (Protokolldateien) und Alarmen eine wichtige Angelegenheit in einem sicheren System ist. Stellen Sie sich vor, ein System ist perfekt konfiguriert und zu 99% sicher. Wenn ein Angriff unter dieses 1% fällt, und es keine Sicherheitsmaßnahmen gibt, dies erstens zu erkennen und zweitens einen Alarm auszulösen, so ist das System überhaupt nicht sicher.
Debian GNU/Linux stellt Werkzeuge zur Verfügung, die die Analyse von
Log-Dateien übernehmen. Am beachtenswertesten sind swatch
[33], logcheck
oder
loganalysis
(alle Pakete werden ein wenig Anpassung benötigen, um
unnötige Dinge aus den Reports zu entfernen). Wenn sich das System in Ihrer
Nähe befindet, könnte es nützlich sein, das System-Log auf einer virtuellen
Konsole auszugeben. Die ist nützlich, da Sie so (auch von weiter weg oder im
Vorbeigehen) sehen können, ob sich das System richtig verhält. Debians
/etc/syslog.conf
wird mit einer auskommentierten
Standardkonfiguration ausgeliefert. Um diese Ausgabe einzuschalten, entfernen
Sie die Kommentarzeichen vor den entsprechenden Zeilen und starten
syslog
neu (/etc/init.d/syslogd restart):
daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8
Um die Logs farbig zu gestalten sollten einen Blick auf colorize
,
ccze
oder glark
werfen. Es gibt da noch eine Menge
über die Analyse von Logs zusagen, das hier nicht behandelt werden kann. Eine
gute Quelle für weiter Informationen ist die Webseite Log Analysis
. In jedem Fall sind
selbst automatische Werkzeuge dem besten Analysewerkzeug nicht gewachsen: Ihrem
Gehirn.
logcheck
Das Paket logcheck
ist in Debian auf drei Pakete verteilt:
logcheck
(das Hauptprogramm), logcheck-database
(eine
Datenbank regulärer Ausdrücke für das Programm) und logtail
(gibt
Logzeilen aus, die noch nicht gelesen wurden). Der Standard unter Debian (in
/etc/cron.d/logcheck
) ist, dass logcheck
jede Stunde
und nach jedem Neustart ausgeführt wird.
Wenn dieses Werkzeug in geeigneter Weise angepasst wurde, kann es sehr nützlich
sein, um den Administrator zu alarmieren, wenn etwas ungewöhnliches auf dem
System passiert. Logcheck
kann vollständig angepasst werden, so
dass es Mails über Ereignisse aus den Logs sendet, die Ihrer Aufmerksamkeit
bedürfen. Die Standard-Installation umfasst Profile zum ignorieren von
Ereignissen und Rechtswidrigkeiten für drei unterschiedliche Setups
(Workstation, Server und paranoid). Das Debian-Paket umfasst die
Konfigurationsdatei /etc/logcheck/logcheck.conf
, die vom Programm
eingelesen wird, und die definiert, an welchen Nutzer die Testergebnisse
geschickt werden sollen. Es stellt außerdem einen Weg für Pakete zur
Verfügung, um neue Regeln in folgenden Verzeichnisses zu erstellen:
/etc/logcheck/cracking.d/_packagename_
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
, und
/etc/logcheck/ignore.d.workstation/_packagename_
. Leider benutzen
das noch nicht viele Pakete. Wenn Sie ein Regelwerk entwickelt haben, dass für
andere Nutzer nützlich sein könnte, schicken Sie bitte einen Fehlerbericht für
das entsprechende Paket (als ein wishlist-Fehler). Mehr Informationen
finden Sie unter /usr/share/doc/logcheck/README.Debian
.
logcheck
konfiguriert man am besten, indem man nach der
Installation seine Hauptkonfigurationsdatei
/etc/logcheck/logcheck.conf
bearbeitet. Verändern Sie den
Benutzer, an den die Berichte geschickt werden (standardmäßig ist das Root).
Außerdem sollten Sie auch den Schwellenwert für Berichte festlegen.
logcheck-database
hat drei Schwellenwerte mit steigender
Ausführlichkeit: Workstation (Arbeitsplatz), Server und paranoid.
"server" ist der Standardwert, "paranoid" wird nur für
Hochsicherheitsmaschinen empfohlen, auf denen so wenig Dienste wie möglich
laufen. "workstation" eignet sich für relativ geschützte, nicht
kritische Maschinen. Wenn Sie neue Log-Dateien hinzufügen wollen, müssen Sie
diese nur zu /etc/logcheck/logcheck.logfiles
hinzufügen. Es ist
für die standardmäßige Sysloginstallation eingerichtet.
Wenn Sie dies geschafft haben, sollten Sie die nächsten Tage/Wochen/Monate die
verschickten Mails überprüfen. Falls Sie Nachrichten finden, die Sie nicht
erhalten wollen, fügen Sie die regulären Ausdrücke (regular expressions,
vergleiche regex(7)
und egrep(1)
), die zu diesen
Nachrichten passen, in
/etc/logcheck/ignore.d.reportlevel/local
ein.
Versuchen Sie, dass der reguläre Ausdruck mit der gesamten Logzeile
übereinstimmt. Details, wie man Regeln schreibt, finden Sie in
/usr/share/doc/logcheck-database/README.logcheck-database.gz
. Das
ist ein andauernder Prozess der Abstimmung. Wenn nur noch relevante Meldungen
verschickt werden, können Sie davon ausgehen, dass dieser Prozess beendet ist.
Beachten Sie, dass logcheck
, selbst wenn er läuft, Ihnen keine
Mail schickt, wenn er nichts Relevantes auf Ihrem System findet (so bekommen
Sie höchstens eine Mail pro Woche, wenn Sie Glück haben).
Debian wird mit einer Standardkonfiguration für Syslog (in
/etc/syslog.conf
) ausgeliefert, so dass Meldungen je nach System
in die passenden Dateien geschrieben werden. Das sollte Ihnen bereits bekannt
sein. Falls nicht, werfen Sie einen Blick auf die Datei
syslog.conf
und deren Dokumentation. Wenn Sie ein sicheres System
betreuen wollen, sollten Ihnen bekannt sein, wohin Log-Meldungen geschickt
werden, so dass sie nicht unbeachtet bleiben.
Zum Beispiel ist es für viele Produktiv-Systeme sinnvoll, Meldungen auch auf der Konsole auszugeben. Aber bei vielen solcher Systeme ist es sehr wichtig, auch eine neue Maschine zu haben, die für die anderen als ein Loghost fungiert (d.h. sie empfängt die Logs aller anderen Systeme).
Sie sollten auch an Mails für Root denken, da viele Sicherheits-Kontrollen (wie
snort
) ihre Alarme an die Mailbox von root senden. Diese Mailbox
zeigt normalerweise auf den ersten Nutzer, der auf dem System erstellt wurde
(prüfen Sie dazu /etc/aliases
). Sorgen Sie dafür, dass roots
Mails irgendwo hin geschickt werden, wo sie auch gelesen werden (lokal oder
ferngesteuert).
Es gibt noch andere Accounts mit besonderer Funktion und andere Aliase auf Ihrem System. Auf einem kleinen System ist es wohl am einfachsten, sicherzustellen, dass alle Aliase auf den Root-Account zeigen, und dass Mails an root in das persönliche Postfach des System-Administrator weiter geleitet werden.
FIXME: It would be interesting to tell how a Debian system can send/receive
SNMP traps related to security problems (jfs). Check:
snmptrapfmt
, snmp
and snmpd
.
Ein Loghost ist ein Host der die syslog-Daten über ein Netzwerk sammelt. Wenn
eine Ihrer Maschinen geknackt wird, kann der Eindringling seine Spuren nicht
verwischen, solange er den Loghost nicht ebenfalls geknackt hat. Demzufolge
muss der Loghost also besonders sicher sein. Aus einer Maschinen einen Loghost
zu machen ist relativ einfach: Starten Sie den syslogd
einfach mit
syslogd -r, und ein neuer Loghost ist geboren. Um dies unter
Debian dauerhaft zu machen, editieren Sie /etc/init.d/sysklogd
und
ändern Sie die Zeile
SYSLOGD=""
in
SYSLOGD="-r"
Als nächstes konfigurieren Sie die anderen Maschinen, Ihre Daten an den Loghost
zu senden. Fügen Sie einen Eintrag, ähnlich dem folgenden zu der
/etc/syslog.conf
hinzu:
facility.level @Ihr_Loghost
Schauen Sie in die Dokumentation um zu erfahren, wodurch Sie facility und level ersetzen können (Sie sollten nicht wörtlich übernommen werden). Wenn Sie alles fern mit loggen wollen, schreiben Sie einfach:
*.* @Ihr_Loghost
in Ihre syslog.conf
. Sowohl lokal als auch entfernt mitzuloggen
ist die beste Lösung (ein Angreifer könnte davon ausgehen, dass er seine Spuren
verwischt hat, nachdem er die lokale Log-Datei gelöscht hat). Für weitere
Informationen sehen Sie sich die Handbuch-Seiten syslog(3)
,
syslogd(8)
und syslog.conf(5)
an.
Es ist nicht nur wichtig zu entscheiden, wie Warnungen genutzt werden, sondern auch, wer hierauf Zugriff hat, d.h. wer Log-Dateien (falls Sie nicht einen Log-Host verwenden) lesen oder verändern kann. Sicherheits-Alarme, die ein Angreifer verändern oder abschalten kann, sind im Falle eines Eindringens nicht viel wert. Außerdem sollten Sie berücksichtigen, dass Log-Dateien einem Eindringling ziemlich viel Informationen über Ihr System verraten, wenn er auf sie Zugriff hat.
Einige Zugriffsrechte auf Log-Dateien sind nach der Installation nicht gerade
perfekt (aber das hängt natürlich von Ihren lokalen Sicherheitsmaßstäben ab).
Zuerst einmal müssen /var/log/lastlog
und
/var/log/faillog
nicht für normale Nutzer lesbar sein. In der
lastlog
-Datei können Sie sehen, wer sich zuletzt eingeloggt hat.
In faillog
befindet sich eine Zusammenfassung fehlgeschlagener
Logins. Der Autor empfiehlt, die Rechte von beiden auf 660 zu setzen (mit
chmod 660
). Werfen Sie einen kurzen Blick auf Ihre Log-Dateien,
und entscheiden Sie sehr vorsichtig, welche Log-Dateien Sie les- oder
schreibbar für einen Nutzer mit einer anderen UID als 0 und einer anderen
Gruppe als 'adm' oder 'root' machen. Sie können dies sehr leicht auf Ihrem
System überprüfen:
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u (see to what users do files in /var/log belong) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (see to what groups do files in /var/log belong) # find /var/log -perm +004 (files which are readable by any user) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (files which belong to groups not root or adm)
Um anzupassen, wie neue Log-Dateien erstellt werden, müssen Sie wahrscheinlich das Programm anpassen, das sie erstellt. Wenn die Log-Dateien rotiert werden, können Sie das Verhalten der Erstellung und Rotation anpassen.
Debian GNU/Linux stellt verschiedene Patches für den Linux-Kernel zur Verfügung, die die Sicherheit erhöhen:
Erkennung von Eindringlingen für Linux (Linux Intrusion Detection
, enthalten im
Paket lids-2.2.19
). Dieser Kernelpatch erleichtert Ihnen, Ihr
Linuxsystem abzuhärten, indem er Ihnen ermöglicht, Prozesse einzuschränken, zu
verstecken und zu schützten, sogar vor Root. Er führt Fähigkeiten für eine
zwingende Zugangskontrolle ein.
Linux Trustees
(im
Paket trustees
). Dieser Patch fügt ein ordentliches,
fortgeschrittenes Rechtemanagement Ihrem Linux-Kernel hinzu. Besondere
Objekte, die "trustees" (Treuhänder) genannt werden, sind mit jeder
Datei oder Verzeichnis verbunden. Sie werden im Speicher des Kernels abgelegt
und erlauben so eine schnelle Abfrage aller Rechte.
NSA Enhanced Linux (im Paket selinux
. Backports von Paketen, die
SElinux unterstützen, sind unter http://selinux.alioth.debian.org/
erhältlich. Weiterführende Informationen können Sie auf der SElinux in Debian Wiki Seite
und auf Manoj
Srivastavas
und Russell Cookers'
SElinux-Webseiten finden.
Der Exec-Shield-Patch
aus dem Paket kernel-patch-exec-shield
. Dieser Patch schützt vor
einigen Pufferüberläufen (stack smashing attacks).
Der Grsecurity-Patch
aus
den Paketen kernel-patch-2.4-grsecurity
und
kernel-patch-grsecurity2
[34] verwirklicht Mandatory Access Control durch RBAC und stellt
Schutz vor Pufferüberläufen durch PaX, ACLs, Zufälligkeit im Netzwerk (um die
Erkennung von Spuren des OS zu erschweren) und noch viele Features
mehr
zur Verfügung.
kernel-patch-adamantix
bietet die Patches an, die für die
Debian-Distribution Adamantix
entwickelt wurden.
Dieser Patch für den Kernel 2.4.x führt einige Sicherheitsfähigkeiten wie
nichtausführbaren Speicher durch den Einsatz von PaX
und Mandatory Access
Control auf Grundlage von RSBAC
ein. Andere Features sind
der
Random-PID-Patch
, ein mit AES verschlüsseltes Loop-Gerät,
Unterstützung von MPPE und eine Zurückportierung von IPSEC v2.6.
cryptoloop-source
. Dieser Patch erlaubt Ihnen, die Fähigkeiten
der Crypto-API des Kernels zu verwenden, um verschlüsselte Dateisysteme mit dem
Loopback-Gerät zu erstellen.
Kernel-Unterstützung von IPSEC (im Paket kernel-patch-openswan
).
Wenn Sie das IPsec-Protokoll mit Linux verwenden wollen, benötigen Sie diesen
Patch. Damit können Sie ziemlich leicht VPNs erstellen, sogar mit
Windows-Rechnern, da IPsec ein verbreiteter Standard ist. IPsec-Fähigkeiten
wurden in den Entwicklungskernel 2.5 eingefügt, so dass dieses Feature
standardmäßig im zukünftigen Kernel 2.6 enthalten sein wird. Homepage:
http://www.openswan.org
.
FIXME: Der neuste Kernel 2.4 in Debian enthält eine Rückeinbindung des
IPSEC-Codes aus 2.5. Kommentar dazu.
Die folgenden Sicherheitspatches für den Kernel sind nur noch für alte Kernelversionen in Woody verfügbar und werden nicht mehr weiterentwickelt:
POSIX Access Control Lists
(ACLs, Listen zur Zugangskontrolle) für Linux im Paket
kernel-patch-acl
. Dieser Kernelpatch stellt Listen zur
Zugangskontrolle zur Verfügung. Das ist eine fortgeschrittene Methode, um den
Zugang zu Dateien einzuschränken. Es ermöglicht Ihnen, den Zugang zu Dateien
und Verzeichnisses fein abzustimmen.
Der Patch für den Linux-Kernel Openwall
von Solar Designer,
der im Paket kernel-patch-2.2.18-openwall
enthalten ist. Er
enthält eine nützliche Anzahl von Beschränkungen des Kernels wie eingeschränkte
Verweise, FIFOs in /tmp
, ein begrenztes
/proc
-Dateisystem, besondere Handhabung von Dateideskriptoren,
einen nichtausführbaren Bereich des Stapelspeichers des Nutzers und andere
Fähigkeiten. Hinweis: Dieser Patch ist nur auf die Kernelversion 2.2
anwendbar, für 2.4 werden von Solar keine Pakete angeboten.
kernel-patch-int
. Auch dieser Patch fügt kryptographische
Fähigkeiten zum Linux-Kernel hinzu. Er war bis zu den Debian-Releases bis
Potato nützlich. Er funktioniert nicht mehr mit Woody. Falls Sie Sarge oder
eine neuere Version verwenden, sollten Sie einen aktuelleren Kernel einsetzen,
in dem diese Features bereits enthalten sind.
Wie auch immer, einige Patches werden von Debian noch nicht zur Verfügung
gestellt. Wenn Sie denken, dass manche von ihnen hinzugefügt werden sollten,
fragen Sie danach auf Arbeit-bedürfende und
voraussichtliche Pakete
.
Pufferüberlauf (buffer overflow) wird eine verbreitete Art von Angriffen auf Software [35] genannt, die die unzureichende Überprüfung von Eingabegrenzen ausnutzen (ein Programmierfehler, der häufig bei der Programmiersprache C auftritt), um durch Programmeingaben Befehle auf der Maschine auszuführen. Diese Attacken über Server, die auf Verbindungen warten, oder über lokal installierte Software, die einem Nutzer größere Privilegien gewährt (setuid oder setgid) kann zu einem kompromittierten System führen.
Es gibt hauptsächlich vier Methoden, um sich gegen Pufferüberläufe zu schützen:
Patchen Sie den Kernel, um das Ausführen des Stapelspeichers zu verhindern. Sie können entweder Exec-Shield, OpenWall oder PaX (ist in den Grsecurity- und Adamantixpatches enthalten) verwenden.
Benutzen Sie eine Bibliothek wie libsafe
,
um verwundbare Funktionen zu überschreiben und ordentliche Prüfungen
einzuführen (Informationen wie man libsafe
installiert finden Sie
hier
).
Verbessern Sie den Quellcode, indem Sie Werkzeuge einsetzen, die Teile finden, die zu dieser Verwundbarkeit führen könnten.
Übersetzen Sie den Quellcode neu, um vernünftige Prüfungen einzuführen, um
Überläufe zu verhindern. Benutzen Sie dazu den Stack Smashing
Protector (SSP)
Patch für GCC (der von Adamantix
verwendet wird).
Debian GNU/Linux liefert bis einschließlich der Release 3.0 Software, um alle
dieser Methoden bis auf den Schutz bei der Übersetzung des Quellcodes (das
wurde aber schon in Fehler
#213994
nachgefragt) zu implementieren.
Beachten Sie, dass selbst wenn Debian einen Compiler zur Verfügung stellen würde, der Schutz vor Stapel- und Pufferüberläufen bieten würde, so doch alle Pakete neu übersetzt werden müssten, um diese Eigenschaft einzuführen. Tatsächlich ist das die Aufgabe der Distribution Adamantix (unter anderen Fähigkeiten). Die Auswirkungen dieses neuen Features auf die Stabilität der Software muss aber noch ermittelt werden (einige Programme und einige Prozessoren werden vielleicht deswegen nicht mehr funktionieren).
Seien Sie auf jeden Fall gewarnt, dass selbst diese Umgehungen des Problems
nicht vor Pufferüberläufen schützen können, da es Möglichkeiten gibt, diese zu
überlisten, wie in Ausgabe
58
des phrack-Magazins oder in COREs Advisory Multiple
vulnerabilities in stack smashing protection technologies
beschrieben.
Wenn Sie Ihren Schutz gegen Pufferüberläufe (unabhängig von der gewählten
Methode) testen wollen, können Sie paxtest
installieren und die
angebotenen Tests laufen lassen.
Ein Kernelpatch, der Schutz vor Pufferüberläufen bietet, ist der
Openwall-Patch, der diese im Linux-Kernel 2.2 verhindern soll. Für 2.4 oder
neuere Kernel müssen Sie die Umsetzung von Exec-Shield oder die von PaX (ist im
Grsecurity-Patch kernel-patch-2.4-grsecurity
und im
Adamantix-Patch kernel-patch-adamantix
enthalten) benutzen. Für
weitere Informationen zum Einsatz dieser Patches lesen Sie den Abschnitt Den Kernel patchen, Abschnitt 4.13.
libsafe
Es ist ziemlich einfach, ein Debian GNU/Linux-System mit libsafe
zu schützen. Sie müssen nur das Paket installieren und Ja sagen,
damit die Bibliothek global geladen wird. Seien Sie dennoch vorsichtig, da das
Software unbrauchbar machen kann (besonders Programme, die mit der alten
libc5
verknüpft sind). Sie sollten also zuerst die gemeldeten Fehlerberichte
lesen und die kritischsten Programme auf Ihrem System mit dem Programm zum
Einhüllen von libsafe
testen.
Wichtiger Hinweis: Der Schutz durch libsafe
könnte im
Moment nicht wirkungsvoll sein, wie es in 173227
beschrieben wird.
Testen Sie es gründlich, bevor Sie es in einer produktiven Umgebung einsetzen,
und verlassen Sie sich nicht ausschließlich darauf, um Ihr System zu schützen.
Zur Nutzung von Werkzeugen zum Aufspüren von Pufferüberläufen benötigen Sie in
jedem Fall Programmiererfahrung, um den Quellcode zu reparieren (und neu zu
kompilieren). Debian stellt beispielsweise bfbtester
(einen
Überlauftester, der Programme per Brute-Force (durch Testen aller
Möglichkeiten) nach Überläufen der Kommandozeile und von Umgebungsvariablen
durchtestet) bereit. Andere interessante Pakete sind auch rats
,
pscan
, flawfinder
und splint
.
Während der normalen Systemadministration müssen Sie immer mal wieder Dateien
auf Ihr System spielen oder von diesem holen. Auf sichere Art und Weise
Dateien von einem Host zu einem anderen zu kopieren, wird durch die Benutzung
des Paketes ssh
erreicht. Eine andere Möglichkeit ist die Nutzung
von ftpd-ssl
, einem ftp-Server der Secure Socket Layer
benutzt, um Übertragungen zu verschlüsseln.
Jede dieser Methoden benötigt natürlich einen speziellen Client. Debian stellt
Ihnen solche zur Verfügung, zum Beispiel enthält das Paket ssh
das
Programm scp
. Es arbeitet wie rcp
, aber ist komplett
verschlüsselt, so dass die bösen Jungs noch nicht einmal
herausbekommen können, WAS Sie kopieren. Wie es den Server gibt, so gibt es
natürlich auch ein ftp-ssl
Client-Paket. Sie können Clients für
diese Software sogar für andere (nicht-UNIXoide) Betriebssysteme finden.
putty
und winscp
stellen eine
secure-copy-Implementierung für jede Version von Microsoft-Betriebssystemen zur
Verfügung.
Beachten Sie, dass die Verwendung von scp
den Nutzern Zugang zum
gesamten Dateisystem ermöglicht, es sei denn, dass es in eine
chroot
-Umgebung eingesperrt ist, wie es in SSH in ein Chroot-Gefängnis
einsperren, Abschnitt 5.1.1 beschrieben wird. Wahrscheinlich sogar
leichter (abhängig vom verwendeten Daemon) kann auch der FTP in eine
chroot
-Umgebung eingesperrt werden. Das wird in Absichern von FTP, Abschnitt
5.3 beschrieben. Falls Sie sich sorgen, dass Nutzer Ihre lokalen Dateien
durchsehen, und Sie verschlüsselte Kommunikation wünschen, können Sie einen
FTP-Daemon mit Unterstützung für SSL einrichten oder FTP mit Klartext und VPN
verbinden (siehe Virtual Private Networks
(virtuelle private Netzwerke), Abschnitt 8.5.
Es ist wichtig, eine gute Quota-Regelung zu haben, da es die Nutzer daran hindert, die Festplatten zu füllen.
Sie können zwei Arten von Quota-Systemen benutzen: Nutzer-Quota und Gruppen-Quota. Wie Sie sicher denken können, limitiert User-Quota den Plattenplatz, den ein Nutzer belegen kann, und Gruppen-Quota macht dasselbe für ganze Gruppen. Beachten Sie dies, wenn Sie die Größe der Quotas festlegen.
Es gibt ein paar wichtige Punkte, über die Sie nachdenken sollten, wenn Sie ein Quota-System aufsetzen:
Halten Sie die Quotas klein genug, so dass die Nutzer Ihre Festplatte nicht aufzehren können.
Halten Sie die Quotas groß genug, so dass Nutzer sich nicht beschweren oder dass Ihr Mail-Quota Sie daran hindert, nach einer Weile Mails anzunehmen.
Nutzen Sie Quotas auf allen Bereichen, die Nutzer beschreiben können, auf
/home
ebenso wie auf /tmp
.
Für jede Partition und jedes Verzeichnis, auf das Nutzer Schreibzugriff haben, sollte ein Quota eingerichtet werden. Berechnen Sie eine sinnvolle Quota-Größe, die Benutzerfreundlichkeit und Sicherheit kombiniert, und weisen Sie diese zu.
So, nun wollen Sie Quotas benutzen. Zuerst müssen Sie prüfen, ob Ihr Kernel
Quota unterstützt. Wenn nicht, müssen Sie ihn neu kompilieren. Prüfen Sie
anschließend, ob das Paket quota
installiert ist. Wenn nicht,
installieren Sie es.
Um Quota für die entsprechenden Dateisysteme einzuschalten, müssen Sie nur die
Einstellung defaults in Ihrer /etc/fstab
zu
defaults,usrquota ändern. Wenn Sie Gruppen-Quotas benötigen,
ersetzen Sie usrquota durch grpquota. Sie können
auch beides verwenden. Erstellen Sie dann leere quota.user
und
quota.group
in den Hauptverzeichnissen der Dateisysteme, auf denen
Sie Quotas einführen möchten (d.h. touch /home/quota.user
/home/quota.group für das Dateisystem /home
).
Starten Sie quota
neu, indem Sie /etc/init.d/quota
stop;/etc/init.d/quota start ausführen. Nun sollte quota laufen, und
die Größen können festgelegt werden.
Bearbeiten der Quotas eines bestimmten Nutzer wird mit edquota -u <user> gemacht. Gruppen-Quotas können mit edquota -g <group> geändert werden. Setzen Sie dann die weiche und die harte Grenze und inode-Quotas, falls Sie es benötigen.
Mehr Informationen über Quotas finden Sie im Handbuch von quot und im
Mini-Howto von quota
(/usr/share/doc/HOWTO/de-html/mini/DE-Quota-HOWTO.html
). Sie
sollten auch einen Blick auf pam_limits.so
werfen.
Zusätzlich zu den normalen Unix-Rechten bieten die ext2- und ext3-Dateisysteme
eine Anzahl von besonderen Attributen, die Ihnen mehr Kontrolle über die
Dateien auf Ihrem System erlauben. Im Gegensatz zu den gewöhnlichen Rechten
werden diese Attribute nicht vom gebräuchlichen Befehl ls -l
angezeigt und können auch nicht mit chmod
geändert werden. Um sie
zu verwalten, brauchen Sie zwei weitere Programme, nämlich lsattr
und chattr
(im Paket e2fsprogs
). Beachten Sie, dass
das bedeutet, dass diese Attribute normalerweise bei einem Backup des Systems
nicht gespeichert werden. Wenn Sie also eines verändern, könnte es sich
lohnen, die aufeinander folgenden chattr
-Befehle in einem Skript
zu speichern, damit Sie sie später wieder zuweisen können, falls Sie ein Backup
zurückspielen müssen.
Unter allen Attributen werden die zwei, die für die Erhöhung der Sicherheit am bedeutendsten sind, mit den Buchstaben 'i' und 'a' bezeichnet. Sie können nur vom Superuser vergeben (oder entfernt) werden:
Das Attribut 'i' ('immutable', unveränderlich): Eine Datei mit diesem Attribut kann weder verändert noch gelöscht oder umbenannt werden, nicht einmal vom Superuser. Auch ein Link auf sie kann nicht angelegt werden.
Das Attribut 'a' ('append', anfügen): Dieses Attribut hat den gleichen Effekt
für das Attribut immutable, allerdings mit der Ausnahme, dass Sie immer noch
die Datei im Anfügen-Modus öffnen können. Das bedeutet, dass Sie ihr immer
noch Inhalt hinzufügen, aber den vorhanden Inhalt nicht verändern können.
Dieses Attribut ist besonders für die Protokolldateien nützlich, die unter
/var/log/
gespeichert werden. Beachten Sie aber, dass sie durch
Log-Rotations-Skripte manchmal verschoben werden.
Diese Attribute können auch für Verzeichnisse vergeben werden. In diesem Fall ist es jedem unmöglich gemacht, den Inhalt des Verzeichnisses zu verändern, also beispielsweise eine Datei umzubenennen oder zu löschen. Wenn das append-Attribut einem Verzeichnis zugewiesen wird, können nur noch Dateien erstellt werden.
Es ist leicht einzusehen, wie das 'a' Attribut die Sicherheit verbessert, indem
es Programmen, die nicht vom Superuser ausgeführt werden, die Fähigkeit
einräumt, Daten hinzuzufügen, aber verhindert, dass älterer Inhalt verändert
wird. Dem gegenüber erscheint das 'i' Attribut uninteressanter. Schließlich
kann der Superuser ja schon die normalen Unix-Rechte verwenden, um den Zugang
zu Dateien einzuschränken. Und ein Angreifer, der Zugang zum Konto des
Superusers hat, könnte immer das Programm chattr
benutzen, um die
Attribute zu entfernen. Ein solcher Eindringlich ist vielleicht zunächst
verwirrt, wenn er feststellt, dass er eine Datei nicht löschen kann. Aber Sie
sollten nicht davon ausgehen, dass er blind ist – immerhin hat er es
geschafft, in Ihr System einzudringen! Einige Handbücher (einschließlich
früherer Versionen dieses Dokuments) empfehlen, einfach die Programme
chattr
und lsattr
vom System zu entfernen, um die
Sicherheit zu erhöhen. Aber diese Strategie, die auch als "security by
obscurity" (Sicherheit durch Verschleierung) bekannt ist, sollte unter
allen Umständen vermieden werden, da sie ein falsches Gefühl von Sicherheit
vermittelt.
Dieses Problem lösen Sie auf sichere Art und Weise, indem Sie die Fähigkeiten des Linux-Kernel verwenden, wie es in Aktive Verteidigung, Abschnitt 10.4.2.1 beschrieben wird. Die hier interessante Fähigkeit heißt CAP_LINUX_IMMUTABLE: Wenn Sie es vom Satz der Fähigkeiten entfernen (indem Sie zum Beispiel den Befehl lcap CAP_LINUX_IMMUTABLE verwenden, ist es nicht mehr möglich, irgendwelche 'a' oder 'i' Attribute auf Ihrem System zu verändern, auch nicht dem Superuser! Ein vollständige Strategie könnte also folgendermaßen aussehen:
Vergeben Sie die Attribute 'a' und 'i' an von Ihnen gewünschte Dateien.
Fügen Sie den Befehl lcap CAP_LINUX_IMMUTABLE einem der Skripten, die den Start des Systems steuern (startup scripts), hinzu.
Setzen Sie das Attribut 'i' für dieses Skript, andere Startdateien und auch das
Programm lcap
selbst.
Führen Sie den oben genannten Befehl per Hand aus (oder starten Sie Ihr System neu, um sicherzustellen, dass alles wie gewünscht funktioniert).
Sind Sie sich sicher, dass /bin/login
auf Ihrer Festplatte immer
noch dasselbe Programm ist, das Sie vor ein paar Monaten installiert haben?
Was wäre, wenn es sich um eine gehackte Version handelt, die eingegebene
Passwörter in einer versteckten Datei ablegt oder sie als Klartext im ganzen
Internet herummailt?
Die einzige Methode einen gewissen Schutz dafür zu haben ist es, die Dateien jede(n) Stunde/Tag/Monat (ich ziehe täglich vor) zu prüfen, indem man deren aktuelle und alte MD5-Summe vergleicht. Zwei unterschiedliche Dateien können keine gleichen MD5-Summen haben (die MD5-Summe umfasst 128 Bits, so ist die Wahrscheinlichkeit, dass zwei unterschiedliche Dateien eine gleiche MD5-Summe haben etwa 1 zu 3,4e3803). So sind Sie sicher, solange niemand den Algorithmus gehackt hat, der die MD5-Summen auf Ihrer Maschine erstellt. Dies ist, nun ja, extrem schwer und sehr unwahrscheinlich. Sie sollten diese Überprüfung Ihrer Programme als sehr wichtig ansehen.
Weit verbreitete Tools hierfür sind sxid
, aide
(Advanced Intrusion Detection Environment, fortgeschrittene Umgebung zur
Erkennung von Eindringlingen), tripwire
, integrit
und
samhain
. Das Installieren von debsums
wird Ihnen
helfen, die Integrität des Dateisystems zu überprüfen, indem Sie die MD5-Summen
jeder Datei gegen die MD5-Summe aus dem Debian-Archiv-Paket vergleichen. Seien
Sie aber gewarnt, dass diese Dateien sehr leicht von einem Angreifer geändert
werden können. Außerdem stellen nicht alle Pakete MD5-Summen für die in ihnen
enthaltenen Programme zur Verfügung. Weitere Informationen finden Sie unter Periodische Überprüfung der
Integrität, Abschnitt 10.2 und Einen Schnappschuss
des Systems erstellen, Abschnitt 4.18.
Sie benutzen vielleicht locate
, um das gesamte Dateisystem zu
indizieren. Wenn das so ist, sollten Sie die Auswirkungen davon
berücksichtigen. Das Debianpaket findutils
enthält
locate
, das als Nutzer nobody läuft. Daher indiziert es nur
Dateien, die von jedermann eingesehen werden können. Wenn Sie dieses Verhalten
verändern, werden allerdings alle Orte von Dateien für alle Nutzer sichtbar.
Wenn Sie das gesamte Dateisystem indizieren wollen (und nicht nur die
Stückchen, die der Nutzer nobody sehen kann), können Sie locate
durch das Paket slocate
ersetzen. slocate wird als eine um
Sicherheit erweiterte Version von GNU locate bezeichnet, hat aber tatsächlich
weitere Funktionen zum Auffinden von Dateien. Wenn Sie slocate
benutzen, sieht ein Benutzer nur Dateien, auf die er auch Zugriff hat, während
Sie Dateien und Verzeichnisse des gesamten Systems ausschließen können. Das
Paket slocate
führt seinen Aktualisierungsprozess mit höheren
Rechten aus als locate. Außerdem indiziert es jede Datei. Nutzern wird es
dadurch ermöglicht, schnell nach jeder Datei zu suchen, die sie sehen können.
slocate
zeigt ihnen keine neuen Dateien an; es filtert die Ausgabe
auf Grundlage der UID.
Sie sollten auch bsign
oder elfsign
einsetzen.
elfsign
bietet die Möglichkeit, digitale Signaturen an
ELF-Binaries anzufügen und diese Signaturen zu überprüfen. Die aktuelle
Fassung verwendet PKI, um die Checksummen der Binaries zu signieren. Dies hat
den Vorteil, dass festgestellt werden kann, ob das Binary verändert wurde und
wer es erstellt hat. bsign
verwendet GPG, elfsign
benutzt PKI-(X.509)-Zertifikate (OpenSSL).
Das Debian-Paket checksecurity
enthält einen
Cron
-Job, der täglich in
/etc/cron.daily/checksecurity
ausgeführt wird. [36]. Dieser Cron
-Job
führt das Skript /usr/sbin/checksecurity
aus, das Informationen
über Änderungen sichert.
Das Standard-Verhalten sendet diese Informationen nicht an den Superuser.
Stattdessen erstellt es eine tägliche Kopie dieser Änderungen unter
/var/log/setuid.changes
. Sie sollten die Variable MAILTO (in
/etc/checksecurity.conf
) auf 'root' setzen, damit diese
Informationen an ihn gemailt werden. Sehen Sie sich auch
checksecurity(8)
für weitere Konfigurations-Informationen an.
FIXME: Mehr (für Debian spezifischer) Inhalt benötigt.
Viele Fähigkeiten des Kernels können während des Betriebs verändert werden,
indem etwas an das /proc
-Dateisystem geschickt wird, oder indem
sysctl
benutzt wird. Wenn Sie /sbin/sysctl -A
eingeben, können Sie sehen, was Sie einstellen können und was die Optionen
sind. Veränderungen werden vorgenommen, indem /sbin/sysctl -w
variable=value ausgeführt wird (vergleiche sysctl(8)
). Nur
in seltenen Fällen müssen Sie hier etwas bearbeiten. Aber auch hier können Sie
die Sicherheit erhöhen. Zum Beispiel:
net/ipv4/icmp_echo_ignore_broadcasts = 1
Dies ist ein Windows Emulator, weil es sich wie Windows bei Rundrufen (Broadcast-Ping) verhält, wenn es auf 1 gesetzt wird. Das bedeutet, dass ICMP-Echo-Anfragen, die an die Rundrufadresse geschickt werden, ignoriert werden. Anderenfalls macht es gar nichts.
Falls Sie verhindern wollen, dass Ihr System auf ICMP-Echo-Anfragen antwortet, müssen Sie nur diese Konfigurationsoption anschalten:
net/ipv4/icmp_echo_ignore_all = 1
Verwenden Sie Folgendes, um Pakete mit unmöglichen Adressen (erzeugt durch falsche Routen) in Ihrem Netzwerk zu protokollieren:
/proc/sys/net/ipv4/conf/all/log_martians = 1
Für weiterführende Informationen dazu, welche Sachen mit
/proc/sys/net/ipv4/*
angestellt werden können, sollten Sie
/usr/src/linux/Documentation/filesystems/proc.txt
lesen. Alle
Optionen werden gründlich in
/usr/src/linux/Documentation/networking/ip-sysctl.txt
[37] beschrieben.
Diese Option ist ein zweischneidiges Schwert. Auf der einen Seite schützt es Ihr System vor dem Überfluten mit syn-Paketen. Auf der anderen Seite verletzt es definierte Standards (RFCs).
net/ipv4/tcp_syncookies = 1
Wenn Sie das dauerhaft für den Kernel festlegen wollen, müssen Sie in /etc/network/options syncookies=yes festlegen. Jedes Mal, wenn /etc/init.d/networking ausgeführt wird (was typischerweise beim Booten geschieht), wird diese Option wirksam. Dagegen wird folgendes nur eine einmalige Wirkung bis zum nächsten Neustart haben:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Diese Option ist nur verfügbar, wenn der Kernel mit CONFIG_SYNCOOKIES übersetzt wurde. Alle Kernel von Debian wurden mit dieser Option kompiliert. Sie können das folgendermaßen überprüfen:
$ sysctl -A |grep syncookies net/ipv4/tcp_syncookies = 1
Weitere Informationen zu TCP-Syncookies finden Sie unter http://cr.yp.to/syncookies.html
.
Wenn Sie die Netzwerkoptionen des Kernels konfigurieren, müssen Sie dafür sorgen, dass sie bei jedem Neustart des Systems geladen werden. Das nachfolgende Beispiel aktiviert neben vielen der oben vorgestellten Optionen auch noch ein paar andere nützliche Optionen.
Tatsächlich gibt es zwei Möglichkeiten, Ihr Netzwerk beim Booten einzurichten.
Sie können entweder /etc/sysctl.conf
konfigurieren (siehe
sysctl.conf(5)
) oder ein Skript einsetzen, das beim Aktivieren der
Netzwerkschnittstellen aufgerufen wird. Die erste Möglichkeit wird auf alle
Schnittstellen angewendet, die zweite erlaubt es Ihnen, die Konfiguration für
jede Schnittstelle separat zu wählen.
Ein Beispiel einer Konfiguration von /etc/sysctl.conf
, die einige
Netzwerkoptionen auf der Kernelebene absichert, wird unten gezeigt. Beachten
Sie darin den Kommentar, dass /etc/network/options
beim Ausführen
von /etc/init.d/networking
(dies ist in der Startsequenz nach
procps
) einige Werte überschreiben könnte, wenn sich Werte in
dieser Datei widersprechen.
# # /etc/sysctl.conf - Configuration file for setting system variables # See sysctl.conf (5) for information. Also see the files under # Documentation/sysctl/, Documentation/filesystems/proc.txt, and # Documentation/networking/ip-sysctl.txt in the kernel sources # (/usr/src/kernel-$version if you have a kernel-package installed) # for more information of the values that can be defined here. # # Be warned that /etc/init.d/procps is executed to set the following # variables. However, after that, /etc/init.d/networking sets some # network options with builtin values. These values may be overridden # using /etc/network/options. # #kernel.domainname = example.com # Additional settings - adapted from the script contributed # by Dariusz Puchala (see below) # Ignore ICMP broadcasts net/ipv4/icmp_echo_ignore_broadcasts = 1 # # Ignore bogus ICMP errors net/ipv4/icmp_ignore_bogus_error_responses = 1 # # Do not accept ICMP redirects (prevent MITM attacks) net/ipv4/conf/all/accept_redirects = 0 # _or_ # Accept ICMP redirects only for gateways listed in our default # gateway list (enabled by default) # net/ipv4/conf/all/secure_redirects = 1 # # Do not send ICMP redirects (we are not a router) net/ipv4/conf/all/send_redirects = 0 # # Do not forward IP packets (we are not a router) # Note: Make sure that /etc/network/options has 'ip_forward=no' net/ipv4/conf/all/forwarding = 0 # # Enable TCP Syn Cookies # Note: Make sure that /etc/network/options has 'syncookies=yes' net/ipv4/tcp_syncookies = 1 # # Log Martian Packets net/ipv4/conf/all/log_martians = 1 # # Turn on Source Address Verification in all interfaces to # prevent some spoofing attacks # Note: Make sure that /etc/network/options has 'spoofprotect=yes' net/ipv4/conf/all/rp_filter = 1 # # Do not accept IP source route packets (we are not a router) net/ipv4/conf/all/accept_source_route = 0
Um dieses Skript verwenden zu können, müssen Sie es zuerst unter z.B.
/etc/network/interface-secure
(der Name ist nur ein Beispiel)
erstellen und es wie folgt aus /etc/network/interfaces
aufrufen:
auto eth0 iface eth0 inet static address xxx.xxx.xxx.xxx netmask 255.255.255.xxx broadcast xxx.xxx.xxx.xxx gateway xxx.xxx.xxx.xxx pre-up /etc/network/interface-secure
In diesem Beispiel wird das Skript aufgerufen, um alle Netzwerkschnittstellen abzusichern, wie unten gezeigt wird, bevor die Schnittstelle eth0 aktiviert wird.
#!/bin/sh -e # Skriptname: /etc/network/interface-secure # # Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen, # um vor TCP/IP-Spoofing und Angriffen zu schützen # # Wurde von Dariusz Puchalak beigesteuert # # Broadcast echo protection enabled echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # IP forwarding disabled echo 0 > /proc/sys/net/ipv4/conf/all/forwarding # TCP syn cookies protection enabled echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Log strange packets (this includes spoofed packets, source routed packets, # redirect packets) but be careful with this on heavy loaded web servers echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Bad error message protection enabled echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # IP spoofing protection echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # Disable ICMP redirect acceptance echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # Disable source routed packets echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route exit 0
Beachten Sie, dass Sie auch verschiedene Netzwerkoptionen für verschiedene Schnittstellen (falls Sie mehr als eine haben) haben können, indem Sie die pre-up-Zeile verändern:
pre-up /etc/network/interface-secure $IFACE
Zusätzlich müssen Sie ein Skript verwenden, das Änderungen nur auf eine bestimmte Schnittstelle anwendet und nicht auf alle Schnittstellen. Beachten Sie aber, dass einige Netzwerkoptionen nur global gesetzt werden können. Dies ist ein Beispielsskript:
#!/bin/sh -e # Skriptname: /etc/network/interface-secure # # Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen, # um vor TCP/IP-Spoofing und Angriffen zu schützen # # Wurde von Dariusz Puchalak beigesteuert IFACE=$1 if [ -z "$IFACE" ] ; then echo "$0: Must give an interface name as argument!" echo "Usage: $0 <interface>" exit 1 fi if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)" exit 1 fi # IP forwarding disabled echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding # Log strange packets (this includes spoofed packets, source routed packets, # redirect packets) but be careful with this on heavy loaded web servers echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians # IP spoofing protection echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter # Disable ICMP redirect acceptance echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects # Disable source routed packets echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route exit 0
Eine andere Lösungsmöglichkeit ist es, ein init.d-Skript zu
erstellen und es beim Booten auszuführen (verwenden Sie
update-rc.d
, um die passenden rc.d-Links
herzustellen).
Um die Möglichkeiten einer Firewall zu haben, damit entweder das lokale System
oder andere dahinter beschützt werden, muss der Kernel mit
Firewall-Unterstützung kompiliert worden sein. Der Standardkernel von Debian
2.2 (Linux 2.2) stellt die Paketfilter-Firewall ipchains
zur
Verfügung. Der Standardkernel von Debian 3.0 (Linux 2.4) enthält die
stateful Paketfilter-Firewall iptables
(netfilter).
In jedem Fall ist es recht einfach, einen anderen als den mit Debian
gelieferten Kernel zu benutzen. Sie finden vorkompilierte Kernel als Pakete
vor, die Sie leicht auf Ihrem Debian-System installieren können. Mit Hilfe des
Pakets kernel-source-X
können Sie auch die
Kernelquellen herunterladen und einen maßgeschneiderten Kernel kompilieren,
indem Sie make-kpkg
aus dem Paket kernel-package
benutzen.
Auf das Aufsetzen einer Firewall unter Debian wird unter Hinzufügen von Firewall-Fähigkeiten, Abschnitt 5.14 ausführlich eingegangen.
Auf Systemen mit mehr als einer Schnittstelle zu verschiedenen Netzwerken können Dienste so eingerichtet werden, dass sie Verbindungen nur zu einer bestimmte IP-Adresse zulassen. Normalerweise verhindert das Zugang zu diesen Diensten, wenn an sie Anfragen über andere Adressen gestellt werden. Allerdings bedeutet das nicht, dass der Dienst an eine bestimmte Hardware-Adresse (Netzwerkkarte) gebunden ist (ein verbreiteter Irrtum). [38]
Das ist kein Problem von ARP und auch keine Verletzung eines RFCs (es wird in
RFC1122
,
Abschnitt 3.3.4.2 als weak end host bezeichnet). Vergessen Sie nicht,
dass IP-Adressen nichts mit dem physischen Schnittstellen zu tun haben.
Im Kernel 2.2 (und davor) könnte dieses Problem so gelöst werden:
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden .....
Bei späteren Kernel kann das folgendermaßen gelöst werden:
Regeln für iptables.
Richtig konfiguriertes Routing. [39] Oder:
Patchen des Kernels. [40]
In diesem Text finden sich viele Fälle, in denen gezeigt wird, wie man einige Dienste (sshd-Server, apache, Druckserver, ...) so konfiguriert, dass sie nur auf einer bestimmten Adresse lauschen. Der Leser sollte in Betracht ziehen, dass das den Zugang aus dem gleichen (lokalen) Netzwerk nicht verhindern kann, wenn nicht die in diesem Abschnitt vorgeschlagenen Schritte ergriffen werden. [41]
FIXME: Comments on Bugtraq indicate there is a Linux specific method to bind to a given interface.
FIXME: Submit a bug against netbase so that the routing fix is standard behavior in Debian?
Wenn Sie den anderen Kisten in Ihrem LAN nicht trauen (das sollte immer so sein, da es die sicherste Einstellung ist), sollten Sie sich vor den verschiedenen ARP-Angriffen schützen.
Wie Sie wissen, wird das ARP-Protokoll dazu verwendet, IP-Adressen mit
MAC-Adressen zu verknüpfen (für alle Details siehe RFC826
). Jedes Mal,
wenn Sie ein Paket an eine IP-Adresse schicken, wird eine ARP-Auflösung
vorgenommen (zuerst wird in den lokalen ARP-Speicher geschaut, und falls die IP
nicht im Speicher ist, wird ein Rundruf (Broadcast) mit der ARP-Anfrage
verschickt), um die Hardware-Adresse des Ziels zu finden. Alle ARP-Angriffe
zielen darauf ab, Ihrem Rechner vorzugaukeln, dass die IP-Adresse des Rechners
B mit der MAC-Adresse des Computers des Angreifers verbunden ist. Dadurch wird
jedes Paket, das Sie an den Rechner B, der mit der IP-Adresse verbunden ist,
schicken wollen, an den Computer des Eindringlings umgeleitet ...
Diese Angriffe (Verfälschung des ARP-Speichers, ARP-Spoofing, ...) ermöglichen
dem Angreifer, auf Netzwerken den Verkehr abzuhören (selbst bei Netzwerken, die
über einen Switch laufen). Er kann sich leicht in eine Verbindung einschleusen
oder einen Host vom Netzwerk nehmen oder ... ARP-Angriffe sind leistungsfähig
und einfach durchzuführen. Es gibt dafür auch einige Werkzeuge wie
arpspoof
aus dem Paket dsniff
oder arpoison
.
Allerdings gibt es immer eine Lösung:
Verwenden Sie einen statischen ARP-Speicher. So erstellen Sie "statische" Einträge in Ihrem ARP-Speicher:
arp -s host_name hdwr_addr
Indem Sie statische Einträge für jeden wichtigen Host in Ihrem Netzwerk vergeben, stellen Sie sicher, dass niemand einen (falschen) Eintrag für diese Hosts erstellen oder verändern kann (statische Einträge verfallen nicht und können nicht verändert werden). Auch gefälschte ARP-Antworten werden ignoriert.
Entdecken Sie verdächtigen ARP-Verkehr. Sie können dazu arpwatch
,
karpski
oder allgemeinere IDS, die auch verdächtigen ARP-Verkehr
entdecken können wie snort
oder prelude
, einsetzen.
Verwirklichen Sie einen IP-Filter, der die MAC-Adressen überprüft.
Bevor Sie das System in eine produktive Umgebung stellen, können Sie einen Schnappschuss des gesamten Systems machen. Diesen Schnappschuss können Sie im Falle einer Kompromittierung (siehe Nach einer Kompromittierung (Reaktion auf einem Vorfall), Kapitel 11) benutzen. Sie sollten so einen Schnappschuss immer dann erneuern, wenn Sie das System aktualisieren, insbesondere wenn Sie auf eine neue Debian Release upgraden.
Hierfür können Sie beschreibbare, austauschbare Datenträger benutzen, die Sie schreibschützen können. Dies kann eine Diskette (die nach der Benutzung schreibgeschützt wird), eine CD in einem CD-ROM-Laufwerk (Sie können auch wiederbeschreibbare CD-ROMs benutzen, so können Sie sogar alte Sicherheitskopien Ihrer MD5-Summen behalten), eine USB-Platte oder eine MMC-Karte (wenn Ihr System auf diese zugreifen kann und sie schreibgeschützt werden können) sein.
Das folgende Skript erstellt einen solchen Schnappschuss:
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy if [ ! -f /usr/bin/md5sum ] ; then echo "Kann nicht md5sum finden. Breche ab." exit 1 fi /bin/cp /usr/bin/md5sum /mnt/floppy echo "Erstelle MD5-Datenbank" >/mnt/floppy/md5checksums.txt for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ do find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt done echo "MD5-Datenbank (nach der Installation) erstellt" if [ ! -f /usr/bin/sha1sum ] ; then echo "Kann nicht sha1sum finden" else /bin/cp /usr/bin/sha1sum /mnt/floppy echo "Erstelle SHA-1-Datenbank" >/mnt/floppy/sha1checksums.txt for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ do find $dir -type f | xargs /usr/bin/sha1sum >>/mnt/floppy/sha1checksums-lib.txt done echo "SHA-1-Datenbank (nach der Installation) erstellt" fi /bin/umount /dev/fd0 exit 0
Beachten Sie, dass das Programm md5sum (und sha1sum, falls verfügbar) auch auf der Diskette gesichert werden muss, so dass Sie es später benutzen können, um die anderen Programme Ihres Systems zu prüfen (für den Fall, dass md5sum oder sha1sum einen Trojaner enthalten). Wenn Sie aber sicher sein wollen, dass Sie eine gültige Kopie von md5sum verwenden, sollten Sie eine statische Kopie von md5sum erstellen und diese verwenden (damit wird verhindert, dass eine manipulierte libc-Bibliothek das Programm beeinträchtigt) oder md5sum nur in einer sauberen Umgebung einsetzen, die Sie etwa mit einer Rettungs-CD-ROM oder einer Live-CD erzeugen können (damit wird verhindert, dass ein manipulierter Kernel das Programm beeinflusst). Ich kann es nicht genug betonen: Wenn Sie ein System haben, in das eingebrochen wurde, können Sie den Ausgaben nicht vertrauen. Sehen Sie sich auch Nach einer Kompromittierung (Reaktion auf einem Vorfall), Kapitel 11 an.
Dieser Schnappschuss enthält nicht die Dateien unterhalb von
/var/lib/dpkg/info
, wo MD5-Summen installierter Pakete enthalten
sind (die Dateien enden mit .md5sums
). Sie können diese
Informationen zusätzlich kopieren, aber Sie sollten Folgendes beachten:
die Dateien mit den MD5-Summen enthalten die MD5-Summen aller Dateien, die ein Debian-Paket enthält, nicht nur die der Systemprogramme. Das hat zur Folge, dass diese Datenbank viel größer ist (5 MB statt 600 KB auf einem Debian GNU/Linux System mit graphischen Subsystem und etwa 2,5 GB Software installiert) und nicht auf ein kleines, transportables Medium wie eine Diskette passt, aber wohl auf einen tragbaren USB-Speicher.
nicht alle Debian-Pakete stellen MD5-Summen der installierten Dateien zur
Verfügung, da es (derzeit) nicht in der Policy verlangt wird. Sie können
allerdings nach der Installation die MD5-Summen aller Pakete mit
debsums
erstellen:
# debsums --generate=missing,keep
Sobald der Schnappschuss erstellt wurde, sollten Sie sicherstellen, dass das
entsprechende Medium schreibgeschützt ist. Sie können es dann als
Sicherheitskopie verwenden oder in ein Laufwerk stecken, um jede Nacht mit
cron
die MD5-Summen des Systems mit Ihrem Schnappschuss zu
vergleichen.
Wenn Sie keine Überprüfung von Hand einrichten wollen, können Sie immer eines der Integritätssysteme verwenden, die diese Aufgabe und noch vieles mehr für Sie erledigen werden. Weitere Informationen finden Sie unter Periodische Überprüfung der Integrität, Abschnitt 10.2.
SVGAlib ist ganz nett für Konsolen-Liebhaber wie mich, aber in der
Vergangenheit wurde mehrfach gezeigt, dass es ziemlich unsicher ist. Exploits
durch zgv
wurden veröffentlicht, und es war einfach root zu
werden. Versuchen Sie die Nutzung von SVGAlib Programmen wann immer nur
möglich zu verhindern.
[ 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, Thu, 23 Aug 2012 15:10:24 +0000jfs@debian.org