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.5, Booten von Diskette verbieten, 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-Anweisungen (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 dem Release Sicherheitsupdates gegeben haben könnte, nachdem entdeckt wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es kleinere Releases gegeben haben (es gab sieben kleinere Releases von Debian 2.2 Potato), 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
Wenn Sie dies erledigt haben, können Sie Ihr System mit apt
oder
dselect
aktualisieren.
apt
verwenden wollen, müssen Sie (als root) nur
Folgendes tun:
# apt-get update # apt-get upgrade
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 [7]. 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:
# lsof | grep dpkg- | awk '{print $1, $8}' | 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 [8].
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 die
Rückmeldung bekommen, dass der Paketmanager kein Paket finden konnte, das mit
der Datei verbunden ist, anstatt der obigen Nachricht, die 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 [9]).
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 [10]. 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 [11] 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
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
generiert ein gehashtes Passwort, das kompatibel mit grubs
Verschlüsselungsalgorithmus (MD5) ist. Um grub
mitzuteilen, dass
verschlüsselte Passwörter benutzt werden, benutzen Sie die folgende Anweisung:
timeout 3 password --md5 $1$arPydhOM$bIgEKjMW5kxeEuvE1Rah4/
Der --md5 Parameter 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örter vorzuziehen. Weitere Informationen über
grub
-Passwörter können Sie im grub-doc
-Paket finden.
Hinweis: Dies trifft nicht auf Kernel zu, die in Debian 3.1 enthalten sind.
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
Beachten Sie, dass Debian 3.0 Woody den Benutzern erlaubt, 2.4er
Kernel zu installieren (indem Sie flavors wählen), aber der
Standard-Kernel ist 2.2 (von einigen Architekturen abgesehen, auf die der
Kernel 2.2 nicht portiert wurde). Wenn Sie dies als Bug ansehen, beachten Sie
Bug 145244
, bevor Sie
ihn melden.
Der Standard-MBR von Debian vor Version 2.2 verhielt sich nicht wie ein normaler Master-Boot-Record und ließ eine Methode offen, einfach in ein System einzubrechen:
Dieses Verhalten können Sie ändern, indem Sie
lilo -b /dev/hda
eingeben.
Nun ist LILO in den MBR geschoben worden. Dies können Sie auch erreichen,
indem Sie boot=/dev/hda zu lilo.conf
hinzufügen. Es
gibt noch eine Möglichkeit, die den MBR komplett abschaltet:
install-mbr -i n /dev/hda
Auf der anderen Seite könnte diese "Hintertür", die viele Leute nicht kennen, Ihnen einmal die Haut retten, wenn Sie aus irgendwelchen Gründen in große Schwierigkeiten mit Ihrer Installation geraten.
FIXME überprüfen, ob das für 2.2 wirklich stimmt, oder war es 2.1? INFO: Die Bootdisketten von Debian 2.2 installieren KEINEN mbr, sondern nur LILO.
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.
login.defs
ändern Sie die CONSOLE-Variable, die eine Datei oder
eine Liste von Terminals definiert, an denen sich Root einloggen darf.
securetty
[12]
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 [13] und vc/X (falls Sie die
devfs-Schnittstelle verwenden). Sie sollten auch ttySX [14] hinzufügen, wenn Sie eine
serielle Konsole für den lokalen Zugang verwenden. (Wenn X eine ganze Zahl
(Integer) ist, sollten Sie mehrere Instanzen [15] haben, abhängig von der Anzahl der virtuellen Konsolen, die
Sie in /etc/inittab
aktiviert haben [16]). 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 irgendwelcher Programme unterhalb des Einhängepunkts (mount point) verbietet und nodev Geräte ignoriert. Das hört sich toll an, aber es
Die noexec-Option, die verhindert, dass Binarys ausgeführt werden können, lässt sich 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
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 [17] verwahrt ihre Programme
unterhalb von /var
. Dasselbe gilt für die nosuid-Option.
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 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.
Was noexec betrifft, seien Sie sich bitte bewusst, dass es Ihnen nicht sehr viel Sicherheit bietet. Beachten Sie Folgendes:
$ cp /bin/date /tmp $ /tmp/date (wird aufgrund des noexec nicht ausgeführt) $/lib/ld-linux.so.2 /tmp/date (funktioniert, da date nicht direkt ausgeführt wird)
Wenn Sie auf /usr
nur lesenden Zugriff erlauben, werden Sie nicht
in der Lage sein, neue Pakete auf Ihrem Debian GNU/Linux System installieren
können. Sie werden es erst mit Schreibzugriff erneut mounten müssen, die
Pakete installieren und dann wieder nur mit lesendem Zugriff mounten. Die
neuste Version von apt
(in Debian 3.0 'Woody') kann konfiguriert
werden, Befehle vor und nach dem Installieren von Paketen auszuführen.
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 2.2 geliefert
werden, haben diese Unterstützung eingebaut. Weiterhin hatte Debian keine
Unterstützung für PAM vor Version 2.2. 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:
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 auch 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. [18] 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 in 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
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 oder 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 [19] 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 yes
Wenn Sie die Variable FAILLOG_ENAB auf yes gesetzt haben, dann sollten Sie auch diese Variable auf yes setzen. Dies wird auch unbekannte Nutzernamen protokollieren. Wenn Sie dies tun, gehen Sie auch sicher, dass die Protokolle sinnvolle Zugriffsrechte haben (zum Beispiel 640, mit einer angemessenen Gruppen-Zugehörigkeit wie adm), weil Nutzer oft versehentlich ihr Passwort als Usernamen eingeben und dies anderen nicht zugänglich machen wollen.
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?
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 Nutzer eine Null
(/dev/null
) als Shell (sie müsste in /etc/shells
auflistet 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. [20]
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 [21] :
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 [22].
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 setzten (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 [23] ü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. Dies ändern Sie, indem Sie eine passende
umask für alle Nutzer einstellen. Sie können die
UMASK-Einstellung in /etc/limits.conf
,
/etc/profile
, /etc/csh.cshrc
,
/etc/csh.login
, /etc/zshrc
und wahrscheinlich auch
noch in anderen Dateien (abhängig von den Shells, die Sie auf Ihrem System
installiert haben) ändern. Von all diesen hat die zuletzt geladene Vorrang.
Die Reihenfolge lautet: PAMs limits.conf
, die
Standard-System-Konfiguration für die Shell des Nutzers, die Shell des Nutzers
(seine ~/.profile
) und ~/.bash_profile
...).
Debians default umask Einstellung ist 022, d.h., dass
Dateien (und Verzeichnisse) von Nutzer aus der Gruppe und jedem anderen Nutzer
des Systems lesbar und zugreifbar sind. Wenn dies zu großzügig für Ihr System
ist, müssen Sie die umask Einstellung für alle Shells (und für PAM) ändern.
Vergessen Sie nicht, die Dateien unter /etc/skel/
anzupassen, da
dort die Standards für Nutzer festgelegt werden, die mit dem Befehl
adduser
erstellt werden.
Beachten Sie allerdings, dass ein Nutzer seine umask-Einstellung abändern kann, wenn er es möchten, um sie großzügiger oder einschränkender zu machen.
FIXME: Inhalt benötigt. Aufzeigen der Folgen beim Upgraden, wenn die
Paketrechte verändert werden (außerdem sollte eine derartige 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:
/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.
/usr/share/doc
-Verzeichnis ansieht, oder indem man mit Hilfe der
auf Ihrem System installierten Binaries und Bibliotheken versucht zu raten.
/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
[24]
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:
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:
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.
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
tcpd
) aufgerufen,
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, versuchen Sie Folgendes:
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \ sed 's/,libwrap0$//;s/^[[:space:]]\+//'
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 [25] 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 Alarme eine wichtige Angelegenheit in einem sicheren System. 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 Tools zur Verfügung, die die Analyse von Log-Dateien
übernehmen. Am beachtenswertesten sind swatch
[26], 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 die gesamte Zeile der Meldung ü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 an 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 wird, wo sie auch gelesen werden (entweder 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:
snmptraglogd
, 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 setzten (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, dass 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:
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.
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.
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.
selinux
. Auch verfügbar auf der Webseite des
Entwicklers
).
Exec-Shield-Patch
aus dem Paket kernel-patch-exec-shield
. Dieser Patch schützt vor
einigen Pufferüberläufen (stack smashing attacks).
Grsecurity-Patch
aus
den Paketen kernel-patch-2.4-grsecurity
und
kernel-patch-grsecurity2
[27] 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-patch-freeswan
).
Wenn Sie das IPsec-Protokoll mit Linux verwenden wollen, brauchen 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 diese Feature
standardmäßig im zukünftigen Kernel 2.6 enthalten sein wird. Homepage:
http://www.freeswan.org
.
Hinweis: Die Verwendung von FreeSwan wurde zugunsten von OpenSwan aufgegeben.
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 wurden aufgegeben:
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.
FIXME: Weitere Ausführungen. Erklärung, wie diese Patches unter Debian mit den kernel-2.x.x-patch-XXX-Paketen installiert werden können.
FIXME: Sortiere die Patches danach, ob sie nur auf Kernel 2.2, auf Kernel 2.4 oder auf beide anwendbar 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
. Ein paar von ihnen sind:
HAP
patch
(HAP steht für Hank Approved Paranoid Linux). Eine
Sammlung für Sicherheitspatches für den Kernel 2.2.x.
Pufferüberlauf (buffer overflow) wird eine verbreitete Art von Angriffen auf Software [28] 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:
libsafe
,
um verwundbare Funktionen zu überschreiben und ordentliche Prüfungen
einzuführen (Informationen wie man libsafe
installiert finden Sie
hier
).
StackGuard
(das von
Immunix
verwendet wird) oder
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, der 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) durch Überläufe der Kommandozeile und von Umgebungsvariablen
durchtestet) und njamd
. Andere interessante Paket 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 sshd
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 Chroot'en von ssh, 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 entweder
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 ein paar wichtige Punkte, über die Sie nachdenken sollten, wenn Sie ein Quota-System aufsetzen:
/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 könnten auch lshell
mögen, oder auch nicht, da es den FHS
verletzt. Beachten Sie außerdem, dass pam_limits.so
die gleiche
Funktionalität zur Verfügung stellen kann und das lshell
Paket
zurzeit verwaist
ist.
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:
/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 9.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:
lcap
selbst.
Sind Sie sich sicher, dass /bin/login
auf Ihrer Festplatte immer
noch dasselbe Programm ist, dass 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
(non-free; die neue Version wird GPL lizenziert),
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 geändert werden können.
Sie benutzen vielleicht locate
, um das gesamte Dateisystem zu
indizieren. Wenn das so ist, sollten Sie die Auswirkungen davon
berücksichtigen. Das Debianpaket locate
läuft als Nutzer nobody.
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 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.
FIXME: put references to the snapshot taken after installation.
FIXME: Add a note regarding packages not providing debsums for all apps installed (not mandatory).
FIXME: Mention signed binaries using say, bsign or elfsign
Debian liefert den täglich ausgeführten Cron
-Job
/etc/cron.daily/standard
. Dieser Cron
-Job führt das
Skript /usr/sbin/checksecurity
, das Informationen über Änderungen
sichert.
Damit dieser Check ausgeführt wird, müssen Sie in
/etc/checksecurity.conf
CHECKSECURITY_DISABLE="FALSE" setzen. Dies ist bereits
der Standardwert, so dass diese Option bereits aktiviert sein sollte, solange
Sie nichts geändert haben.
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 CHECKSECURITY_EMAIL (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.
FIXME: Inhalt fehlt.
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
[29] 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.
FIXME Instead of providing this script provide a sample configuration
for sysctl.conf
(see: sysctl.conf(5)
). Also send
this as a wishlist bug to the procps package.
Erstellen Sie dieses Skript in /etc/network/interface-secure
(der
Name ist nur ein Beispiel) und rufen Sie wie folgt aus
/etc/network/interfaces
auf:
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
# Skriptname: /etc/network/interface-secure # Verändert das Standardverhalten in einigen Bereichen, um vor TCP/IP-Spoofing # und Angriffen zu schützen # # Wurde von Dariusz Puchalak beigesteuert # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # broadcast echo protection enabled echo 0 > /proc/sys/net/ipv4/ip_forward # ip forwarding disabled echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # 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/ip_always_defrag # defragging protection always enabled echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # bad error message protection enabled # now ip spoofing protection echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # and finally some more things: # 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 echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
Sie können auch ein init.d-Skript erstellen und es beim Booten
ausfü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 (auch die Kernelversion ist 2.2) stellt die Paketfilter-Firewall
ipchains
zur Verfügung. Der Standardkernel von Debian 3.0
(Kernelversion 2.4) enthält die stateful Paketfilter-Firewall
iptables
(netfilter). Ältere Debian-Distributionen benötigen
einen passenden Kernelpatch (Debian 2.1 nutzt Kernel 2.0.34).
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
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 zu 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, dem selbst ich aufgesessen bin). [30]
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:
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. [33]
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 Auflösung mit arp
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 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:
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.
arpwatch
,
karpski
oder allgemeinere IDS, die auch verdächtigen ARP-Verkehr
entdecken können wie snort
oder prelude
, einsetzen.
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 10) 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 sein (die nach der Benutzung schreibgeschützt wird) oder eine CD in einem CD-ROM Laufwerk (Sie können auch wieder beschreibbare CD-ROMs benutzen, so können Sie sogar alte Sicherheitskopien Ihrer MD5-Summen behalten).
Das folgende Skript erstellt einen solchen Schnappschuss:
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy /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 /bin/umount /dev/fd0 echo "md5 Datenbank (nach der Installation) erstellt"
Beachten Sie, dass das Programm md5sum 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 einen Trojaner enthält).
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:
Sobald der Schnappschuss erstellt wurde, sollten Sie sicherstellen, dass das
entsprechende Medium schreibgeschützt ist. Sie können dann eine
Sicherheitskopie erstellen, oder jede Nacht mit cron
die
MD5-Summen Ihres Systems mit Ihrem Schnappschuss zu vergleichen.
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.
Anleitung zum Absichern von Debian
Version: 3.2, Mon, 20 Jun 2005 08:01:04 +0000jfs@debian.org