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.1, Ein Passwort für LILO oder GRUB einstellen, Abschnitt 4.2, Entfernen des root Promptes aus dem Kernel, Abschnitt 4.3, Booten von Diskette verbieten, Abschnitt 4.4, einschränkender Konsolen-Zugang, Abschnitt 4.5, und System-Neustart auf der Konsole einschränken, Abschnitt 4.6 lesen.
Bevor Sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um ein öffentliches Netzwerk handelt, sollten Sie wenigstens ein security update (siehe Ausführen von Sicherheitsupdates, Abschnitt 4.8) durchführen. Optional können Sie sich einen Snapshot Ihres Systems machen (siehe Einen Schnappschuss des Systems erstellen, Abschnitt 4.17).
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 auschließlich von der Festplatte bootet. Gehen Sie sicher, dass Sie Ihr BIOS Passwort nicht verlieren, oder Sie werden, im Falle eines Festplattenfehlers, nicht mehr ins BIOS zurückkehren können, um die Einstellung wieder zu ändern, so dass Sie Ihr System wiederherstellen können, indem Sie zum Beispiel eine CD-ROM benutzen.
Eine andere, weniger sicher, aber bequemere Möglichkeit ist es, das BIOS so einzustellen, dass es von 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 so selten benutzen, 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 and kann alles auf Ihrem System machen, das Sie will. 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 zwischem 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 immmer 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 Utility 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 angegeben Passwort ist die md5 verschlüsselte Version von "hackmich". Es ist vorzuziehen md5- statt Klartext-Passwörter zu verwenden. Weitere Informationen über grub Passwörter können Sie im grub-doc Paket finden.
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 betreten, 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.
Generieren Sie Ihr Ramdisk-Image anschließend 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 machen Sie (vorzugsweise):
# 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 einsenden.
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 abschalten wird:
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 Boot Disketten von Debian 2.2 installieren KEINEN mbr, sondern nur LILO
Manche Sicherheits-Regelwerke könnten Administratoren dazu zwingen, sich erst
als User mit Ihrem Passwort auf dem System einzuloggen, und dann Superuser zu
werden (mit su
oder sudo
). Solche eine Policy ist in
Debian in der Datei /etc/login.defs
oder
/etc/securetty
(falls sie PAM verwenden) implementiert. In:
login.defs
, ändern Sie die CONSOLE Variable, die eine Datei oder
eine Liste von Terminals definiert, an denen sich root einloggen darf
securetty
entfernen Sie oder fügen Sie Terminals hinzu, bei denen
Root Zugriff erhalten darf
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 konfigurieren 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 oder könnte nicht gegen Ihre Sicherheitsrichtlinien
verstoßen. 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 in
der Manualseite 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) 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 zum Beispiel,
ist 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 alle setuid und setgid Bits komplett, während noexec das ausführen irgendwelcher Programme unterhalb des Einhängepunkt (mount point) verbietet und nodev Geräte ignoriert. Das hört sich toll an, aber es
Die noexec Option, die verhindert, dass Binaries 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
ausführbare Datei in /tmp
zu erstellen. Wenn sie keine Ahnung
haben, werden sie in dieser Grube hängen bleiben. Mit anderen Worten: Ein
Benutzer kann nicht dazu getrickst werden, einen ausführbaren Trojaner in
/tmp
auszuführen, zum Beispiel indem er zufällig /tmp
in seinen Such-Pfad aufnimmt.
Seien Sie auch gewarnt, dass manche Skripts darauf aufbauen, dass
/tmp
ausführbare Rechte hat. Bemerkenswerterweise hatte (oder
hat?) Debconf Probleme bei dieser Sache, weitere Informationen enthält Bug
116448
.
Nachfolgend ist ein gründlichereres Beispiel. Dazu: /var
könnte
auch noexec enthalten, aber manche Software, wie zum Beispiel Smartlist, behält
seine Programme unterhalb von /var. Das selbe 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
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 wieder mit Schreibzugriff erneut mounten müssen,
die Pakete installieren, und dann wieder read-only mounten. Die neuste Version
von apt (in Debian 3.0 'woody') kann konfiguriert werden, Befehle vor und nach
dem Installieren von Paketen auszuführen, also möchten Sie es vielleicht
passend konfigurieren.
Um dies zu machen öffnen Sie /etc/apt/apt.conf
und fügen Sie 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 während des Updates benutzen. Ärgerlich, aber kein grosses Problem. Gehen Sie einfach sicher, dass sie nicht länger benutzt werden, und führen Sie das Post-Invoke manuell aus.
Sobald neue Sicherheitslöcher in einem Paket entdeckt wurden, reparieren sie
Debian Paket-Betreuer und ursprüngliche Autoren im allgemein innerhalb von
Tagen oder sogar Stunden. Nachdem das Loch gestopft wurde, werden neue Pakete
unter http://security.debian.org
bereit
gestellt.
Wenn Sie eine Debian Release installieren, müssen Sie berücksichtigen, dass es seitdem der Releas gemacht wurde, Sicherheitsupdates geben könnte, nachdem entdeckt wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es kleinere Releases gegeben haben (es gab acht kleinere Releases von Debian 2.2 potato), die Paket-Updates enthalten.
Sie müssen sich das Erstellungsdatum Ihres CD Sets (wenn Sie ein solches benutzen) notieren, und auf der Sicherheitsseite prüfen, ob es Sicherheits-Updates gegeben hat. Wenn es solche gibt, und Sie die Pakete nicht von der Sicherheits-Seite herunterladen können (Ihr System ist noch nicht mit dem Internet verbunden, oder?), könnten Sie es in Erwähgung 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 Beispiel-Konfiguration finden sie unter Sicherheits-Update geschützt durch eine Firewall, Anhang F.
Um Ihr System upzudaten, fügen Sie die folgende Zeile in Ihre
/etc/apt/sources.list
, und Sie werden Sicherheits-Updates
automatisch erhalten, wann immer Sie Ihr System updaten.
deb http://security.debian.org/debian-security stable/updates main contrib non-free
Die meisten Leute, die nicht in einem Land leben, das den Import oder die Nutzung starker Kryptographie verbietet, sollten auch diese Zeile hinzufügen:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
Wenn Sie möchten, können Sie ebenfalls eine deb-src Zeile hinzufügen. Weitere
Details finden Sie unter apt(8)
.
Sie sollten regelmässig Sicherheits-Updates durchführen; die meisten
Sicherheitsprobleme resultieren aus bekannten Sicherheitslücken, die nicht
rechtzeitig gestopft wurden, wie auch http://www.cs.umd.edu/~waa/vulnerability.html
name="paper by Bill Arbaugh"> (vorgetrafen auf dem 2001 IEEE
Symposium on Security and Privacy) erklärt.
FIXME: Add info on how the signature of packages is done so that this can be done automatically through a cron job (big warning: DNS spoofing).
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 Standard-Konfiguration
für jedweden PAM benutzenden Dienst ist es, UNIX Authentifizierung zu emulieren
(lessen 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 bietet eine Konfigurationsdatei unter
/etc/pam.d/
in welcher Sie ihr Verhalten einstellen können:
Die folgende Beschreibung ist weit davon entfernt komplett zu sein, für weitere
Informationen möchten Sie vielleicht The
Linux-PAM System Administrator's Guide
(auf der PAM Hauptseite
),
diese Dokumentation ist auch in dem Paket libpam-doc
enthalten.
PAM bieten Ihnen die Möglichkeit, durch mehrere Authentifizierungsschritte auf einmal zu gehen, ohne das 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 koennen 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-Sicherheits-check bereitstellt; es fragt nach einem neuen Passwort mit einem Minimum von 12 Zeichen, einer Differenz von mindestens 3 Zeichen zum alten Passwort, und erlaubt 3 Versuche. 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 Direktive 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
Nun sollten Sie alle Terminals, von denen sich der Benutzer Root einloggen
können sollte, in /etc/security/access.conf
eintragen. Nicht
zuletzt sollten Sie die folgende Zeile aktivieren, wenn Sie Ihren Benutzern
Limits setzen wollen:
session required pam_limits.so
Dies schränkt die System die ein User nutzen darf ein (siehe unter in Ressourcen-Nutzung limitieren: Die limits.conf Datei, Abschnitt 4.9.2). Sie können zum Beispiel die Anzahl der Logins, die man haben kann, einschränken (für eine Gruppe von Nutzern oder System weit), die Anzahl der Prozesse, den belegten Speicher...
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 via ssh einzuloggen. Sie schreiben in also in eine
Datei /etc/ssh-users-allowed
und schreiben das folgende in
/ect/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).
Sie sollten sich wirklich ernsthaft mit dieser Datei beschäftigen. Hier können
Sie Ihren Benutzern Ressourcen-Limits definieren. Wenn Sie PAM benutzen, wird
die Datei /etc/limits.conf
ignoriert, und Sie sollten
/etc/security/limits.conf
stattdessen benutzen.
Wenn Sie die Ressourcen Nutzung nicht einschränken, kann jeder Nutzer
mit einem einer gültigen Shell auf Ihrem System (oder sogar ein Einbrecher, der
das System durch einen Dienst kompromittierte) so viel CPU, Speicher, Stack
etc. benutzen, wie das System zur Verfügung stellen kann. Dieses Problem der
Ressourcen Überbeanspruchung kann nur mit der Nutzung von PAM gelöst
werden. Beachten Sie, dass es einen Weg gibt, 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.
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.
FIXME: Get a good limits.conf up here
Der nächste Schritt ist es, die grundlegende Konfiguration und die Aktionen bei User Login zu editieren.
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 potentielle 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.
Die Datei /etc/ftpusers
enthält eine Liste von allen Nutzern,
denen es nicht erlaubt ist, sich auf dem host 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 (BUG): Is it a bug that the default ftpusers in Debian does not
include all the administrative users (in base-passwd
).
Wenn es wirklich benötigt wird, dass Nutzer Super User 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 mehr Möglichkeiten bietet als
su
. Wie auch immer, su
ist allgemeiner und wird auf
vielen Unices benutzt.
Das sudo
erlaubt es dem Benutzer, ein definiertes Kommando unter
einer anderen Nutzer-Identitä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 modifizieren,
dass ein administrativer Login aus der Ferne nicht erlaubt ist. Auf diese
Weise müssen die Nutzer das Programm su
(oder sudo
)
benutzen, so dass es immer eine prüfbare Spur gibt, wann immer ein Nutzer
administrative Möglichkeiten nutzen möchte.
Sie müssen die folgende Zeile zu Ihrer /etc/security/access.conf
hinzufügen, die Debians Standard-Konfigurations Datei hat ein Beispiel
auskommentiert:
-:wheel:ALL EXCEPT LOCAL
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
gelistet sein) zuweisen. Wenn Sie den Nutzern erlauben wollen, auf das System
zuzugreifen, aber ihre Bewegungen einschränken wollen, können Sie
/bin/rbash
benutzen, als ob Sie die -r Option der
Bash (RESTRICTED SHELL, siehe bash(1)
) verwendet hätten.
Beachten Sie bitte, dass sogar mit einer restricted Shell ein Nutzer, der auf
ein interaktives Programm zugreifen kann (das es ihm erlauben würde, eine
subshell auszuführen), diese Limitierung der Shell umgehen kann.
Debian bietet zur Zeit in seiner unstable Release (und wird es vielleicht der
nächste stable Release hinzufügen) das pam_chroot
Modul. Eine
Alternative hierzu ist es, den Dienst, der einen Fern-Login anbietet (ssh,
telnet), in einer chroot-Umgebung laufen zu lassen.
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.
Debian's sshd wird ihnen nicht erlauben, die Bewegungen eines Nutzer durch den
Server einzuschränken, da er die Chroot Funktionalität, die das kommerzielle
Programm (sshd2) hat (benutzen Sie 'ChrootGroups' oder 'ChrootUsers', siehe
dazu sshd2_config(5)
). Wie auch immer, es gibt einen Patch, der
ihnen erlaubt dies zu tun, den Patch erhalten Sie von Bug Report 139047
oder von
http://www.cag.lcs.mit.edu/~raoul/
(und er wird wohl in der Zukunft auf das OpenSSH Paket angewendet werden).
Emanuel Lacour hat SSH Pakete mit diesen Fähigkeiten unter http://debian.home-dn.net/woody/ssh/
,
allerdings wird empfohlen durch die Compilierungs-Schritte zu gehen. Eine
Beschreibung von den notwendigen Schritten finden Sie unter http://mail.incredimail.com/howto/openssh/
(so ziemlich alles trifft dort auch auf Debian zu, auch wenn von RedHat 7.2 die
rede ist). Nachdem Sie den Patch angewendet haben, müssen Sie die
/etc/passwd
anpassen, indem Sie das Heimat-Verzeichnis des Nutzers
ändern (in den speziellen /./ Token).
joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash
Dies wird beides einschränken, sowohl fern Zugriff auf die Shell als auch Fernkopien über einen ssh Kanal.
Gehen Sie sicher, dass Sie alle benötigten Binaries in den Chroot-Pfaden für den Nutzer haben. Diese Dateien sollte Root besitzen, um Einmischungen durch den Nutzer zu verhindern (zum Beispiel die chrooted Sandbox zu verlassen). Ein Beispiel könnte so aussehen:
./bin: total 660 drwxr-xr-x 2 root root 4096 Mar 18 13:36 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -r-xr-xr-x 1 root root 531160 Feb 6 22:36 bash -r-xr-xr-x 1 root root 43916 Nov 29 13:19 ls -r-xr-xr-x 1 root root 16684 Nov 29 13:19 mkdir -rwxr-xr-x 1 root root 23960 Mar 18 13:36 more -r-xr-xr-x 1 root root 9916 Jul 26 2001 pwd -r-xr-xr-x 1 root root 24780 Nov 29 13:19 rm lrwxrwxrwx 1 root root 4 Mar 30 16:29 sh -> bash ./etc: total 24 drwxr-xr-x 2 root root 4096 Mar 15 16:13 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rw-r--r-- 1 root root 54 Mar 15 13:23 group -rw-r--r-- 1 root root 428 Mar 15 15:56 hosts -rw-r--r-- 1 root root 44 Mar 15 15:53 passwd -rw-r--r-- 1 root root 52 Mar 15 13:23 shells ./lib: total 1848 drwxr-xr-x 2 root root 4096 Mar 18 13:37 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rwxr-xr-x 1 root root 92511 Mar 15 12:49 ld-linux.so.2 -rwxr-xr-x 1 root root 1170812 Mar 15 12:49 libc.so.6 -rw-r--r-- 1 root root 20900 Mar 15 13:01 libcrypt.so.1 -rw-r--r-- 1 root root 9436 Mar 15 12:49 libdl.so.2 -rw-r--r-- 1 root root 248132 Mar 15 12:48 libncurses.so.5 -rw-r--r-- 1 root root 71332 Mar 15 13:00 libnsl.so.1 -rw-r--r-- 1 root root 34144 Mar 15 16:10 libnss_files.so.2 -rw-r--r-- 1 root root 29420 Mar 15 12:57 libpam.so.0 -rw-r--r-- 1 root root 105498 Mar 15 12:51 libpthread.so.0 -rw-r--r-- 1 root root 25596 Mar 15 12:51 librt.so.1 -rw-r--r-- 1 root root 7760 Mar 15 12:59 libutil.so.1 -rw-r--r-- 1 root root 24328 Mar 15 12:57 libwrap.so.0 ./usr: total 16 drwxr-xr-x 4 root root 4096 Mar 15 13:00 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. drwxr-xr-x 2 root root 4096 Mar 15 15:55 bin drwxr-xr-x 2 root root 4096 Mar 15 15:37 lib ./usr/bin: total 340 drwxr-xr-x 2 root root 4096 Mar 15 15:55 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rwxr-xr-x 1 root root 10332 Mar 15 15:55 env -rwxr-xr-x 1 root root 13052 Mar 15 13:13 id -r-xr-xr-x 1 root root 25432 Mar 15 12:40 scp -rwxr-xr-x 1 root root 43768 Mar 15 15:15 sftp -r-sr-xr-x 1 root root 218456 Mar 15 12:40 ssh -rwxr-xr-x 1 root root 9692 Mar 15 13:17 tty ./usr/lib: total 852 drwxr-xr-x 2 root root 4096 Mar 15 15:37 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rw-r--r-- 1 root root 771088 Mar 15 13:01 libcrypto.so.0.9.6 -rw-r--r-- 1 root root 54548 Mar 15 13:00 libz.so.1 -rwxr-xr-x 1 root root 23096 Mar 15 15:37 sftp-server
Wenn Sie paranoid sind, dann möchten Sie den Nutzern vielleicht eine definierte
.profile
aufzwingen, das die Environments so setzt, dass Sie die
Überwachungsmöglichkeiten der Shell nicht entfernen können (Kommandos werden
auf $HISTFILE ausgegeben). Die .profile
könnte so
gesetzt werden:
HISTFILE=/home/_user_/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 set -o HISTFILE set -o HISTSIZE set -o HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE
Beachten sie: Das -o-Attribut erlaubt nur lesenden Zugriff auf die Variable.
Damit dies funktioniert, darf der Nutzer .profile
oder
.bash_history
nicht modifizieren, aber er muss ersteres lesen und
letzteres schreiben können. Sie können dies leicht tun, indem Sie die Dateien
und das Verzeichnis, indem sich diese Dateien befinden, so dass Sie einem
anderen Benutzer gehören (root), und der Gruppe des Nutzers auf die
History-Datei Schreibzugriff gewähren. Eine andere Möglichkeit ist es, dass
Programm chattr
zu benutzen.
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 ausgibt. Oder Sie lassen
ttysnoop
konstant jedes neue tty überwachen und die Ausgaben in
einer Datei ausgeben. Ein anderes nützliches Programm ist Snoopy
. Dies
ist ein für den Nutzer transparentes Programm, das sich als eine Bibliothek
dazwischen hä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).
Beachten Sie, dass Sie hierfür nicht das script
Kommando benutzen
können, da dies nicht als Shell funktioniert (auch nicht, wenn Sie es zu
/etc/shells
hinzufügen).
Die vorherigen Beispiele sind ein einfacher Weg, um Nutzer Überwachung zu
konfigurieren, eignet sich aber nicht unbedingt für komplexe Systeme. Sollte
dies der Fall sein, schauen Sie sich das Paket acct
, die
accounting Utilities, an. Diese werden alle Kommandos, die ein Nutzer oder ein
Prozess auf dem System ausführt, auf die Kosten von Plattenplatz aufzeichnen.
Wenn Sie diese 'Buchführung' aktivieren, werden alle Informationen über
Prozesse und Nutzer unter /var/account/
gehalten. Das
Accounting-Paket schließt Werkzeuge (sa
und ac
) zur
Analyse dieser Daten ein.
Wenn Sie sehen wollen, was Nutzer normalerweise tun, wenn sie sich
verbinden, 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, was die Standardrechte von neu erstellten Dateien
sind. 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 andere (abhängig von den
Shells, die Sie auf Ihrem System installiert haben) ändern. Von all diesen hat
die zuletzt geladene Vorrang: PAM's limits.conf, die
Standard-System-Konfiguration für die Shell des Nutzers, die Shell des Nutzers
(sein ~/.profile
), ~/.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 werden, wenn sie mit dem adduser
Kommando erstellt werden.
Beachten sie, dass ein Nutzer immer noch seine umask Einstellung abändern kann, wenn er es möchten, um sie großzügiger oder einschränkender zu machen.
FIXME: Content needed. Tell of consequences of changing packages permissiones when upgrading (and admin this paranoid should chroot his users BTW).
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 nicht in eine streng abgeschirmte Umgebung (wie chroot) gesetzt wird, ziemlich viel Informationen von Ihrem System sammeln, darunter:
/etc
. Jedoch werden Debians
Standard Rechte auf sensitive 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
Verzeichnisses oder durch raten, indem man die
Binaries und Bibliotheken durch sieht, die auf Ihrem System installiert sind.
/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), und manche sind sogar
ausschließlich für root verfügbar (Probieren Sie einige Protokolle unter
/var/log
aus. Sehen Sie sich auch 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 durch atmen):
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.
TCP-Wrapper (Schutzumschläge für TCP) wurden entwickelt, als es noch keine
echten Paket-Filter gab, aber Zugangs-Kontrollen notwendig waren. 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.
Wenn Sie mehr Informationen haben möchten, sehen Sie sich
hosts_access(5)
an.
Viele der unter Debian installierten Dienste
tcpd
) aufgerufen
Einerseits werde manche Dienste, einschließlich telnet, ftp, netbios, swat und
finger in /etc/inetd.conf
konfiguriert. Sie sehen es daran, dass
die Konfigurationsdatei zuerst /usr/sbin/tcpd
aufruft.
Andererseits, selbst wenn ein Dienst nicht über den
inetd
-Superdaemon ausgeführt wird, kann es in jedem Fall, den
TCP-Wrapper-Regeln unterworfen werden, indem man die Unterstützung dafür
einkompiliert. Dienste, die unter Debian mit TCP-Wrappern compiliert wurden,
schließen ssh, portmap, in.talk, roc.statd, rpc.mountd, gdm, oaf (der
GNOME-Aktivierungs Daemon), nessus und viele andere ein.
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
laufen lassen: Sie
können Dienste, die gegen die Wrapper-Bibliothek kompiliert wurden, der
host.deny
oder host.allow
Datei hinzufügen, aber
tcpchk
wird Sie warnen, dass er sie nicht finden kann, da er sie
in /etc/inetd.conf
sucht (die Manual-Seite 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 [5] Kommando in /etc/hosts.deny
einzutragen, das
immer dann eine Mail an root schickt, wenn der Wrapper eines abgewiesenen
Dienstes ausgelöst 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) &
Beachten Sie: 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 Datei-Aktivität, die lediglich durch das Senden von ein paar Paketen erreicht wird.
Wie Logs (Protokolldateien) und Alarme in einem sicheren System behandelt werden, ist eine wichtige Angelegenheit. Es ist leicht zu verstehen, dass selbst wenn ein System angeblich perfekt konfiguriert und zu 99% sicher ist, es immer noch 1% Rest-Risiko gibt, für die keine Sicherheitsmaßnahmen greifen. Als erstes gilt es, Angriffe auf dieses 1% zu erkennen und als zweites Alarm auszulösen, oder das System ist in keinster Weise sicher.
Debian GNU/Linux stellt Tools zur Verfügung, die die Analyse von Log-Dateien
übernehmen. Am beachtenswertesten sind logcheck
oder
loganalysis
(beide Pakete werden ein wenig Anpassung benötigen, um
unnötige Dinge aus den Reports zu entfernen). Wenn sich das System in der 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
kommt mit einer kommentierten
Standard-Konfiguration. Um diese Ausgabe einzuschalten, unkommentieren Sie die
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
Es gibt da noch einiges über Log-Analyse, das hier nicht behandelt werden kann.
Eine gute Quelle für weiter Informationen ist Counterpane's Log Analysis
Resources
. In jedem Fall sind selbst automatische Tools dem besten
Tool nicht gewachsen: Ihrem Gehirn.
Das Programm logcheck
ist in Debian in zwei Pakete aufgeteilt:
logcheck
(das Haupt-Programm) und logcheck-database
(eine Datenbank regulärer Ausdrücke für das Programm). Der Standard unter
Debian (unter /etc/cron.d/logcheck
) ist, dass
logcheck
jeweils um 14:00 Uhr und nach jedem Neustart ausgeführt
wird.
Dieses Tool kann sehr nützlich sein, wenn es geeignet angepasst wurde, 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 eine Konfigurationsdatei
/etc/logcheck/logcheck.conf
, die vom Programm eingelesen wird, 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 den
Verzeichnissen zu realisieren:
/etc/logcheck/hacking.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, senden Sie bitte einen Bug-Report für das
entsprechende Paket (als ein wishlist-Bug). Mehr Informationen finden
Sie unter /usr/share/doc/logcheck/README.Debian
.
Der beste Weg logcheck
zu konfigurieren ist es, es einfach zu
installieren (Sie werden gefragt werden, an welchen Nutzer die Mail-Reports
geschickt werden soll, und ob aus den Einträgen im Syslog ein
/etc/logcheck/logcheck.logfiles
generiert werden soll). Wenn Sie
andere Logfiles hinzufügen möchten, ändern Sie einfach
/etc/logcheck/logcheck.logfiles
indem Sie sie hinzufügen. Die
Paket-Abhängigkeiten werden dafür sorgen, dass logcheck-database
auch installiert wird. Während der Installation werden Sie gefragt, welches
Sicherheits-Niveau benötigt wird: Workstation, Server oder paranoid. Dadurch
wird /etc/logcheck/ignore.d
(durch einen symbolischen Link) auf
die richtigen Verzeichnisse zeigen. Um dies zu ändern, führen Sie
dpkg-reconfigure -plow logcheck-database aus. Erstellen Sie dann
eine Datei /etc/ignore.d/local
; diese Datei enthält alle Regeln,
Meldungen auszuschließen, die nicht gemeldet werden sollen. Lassen Sie es für
den Anfang leer (ein einfaches cp /dev/null /etc/ignore.d/local
sollte reichen).
Wenn Sie dies einmal geschafft haben, sollten Sie die nächsten
Tage/Wochen/Monate die verschickten Mails prüfen, ob Sie Meldungen geschickt
bekommen, die Sie nicht erhalten wollen. Fügen Sie dann einen entsprechenden
regulären Ausdruck (siehe regex(7)
) zu
/etc/ignore.d/local
. Die ist ein andauernder Tuning-Prozess.
Wenn nur noch relevante Meldungen verschickt werden, können Sie davon ausgehen,
dass dieser Prozess beendet ist. Beachten Sie, dass Logcheck Ihnen keine Mail
schickt, wenn es nichts relevantes auf Ihrem System findet, selbst wenn es
läuft (so bekommen Sie höchstens eine Mail pro Woche, wenn Sie Glück haben).
Debian kommt mit einer Standard-Konfiguration für Syslog (in /etc/syslog.conf),
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 pflegen 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 nehmen, die für die anderen als ein Loghost fungieren wird (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 permanent 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 mit zu loggen
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). Sehen Sie für
weitere Informationen die Handbuch-Seiten syslog(3)
,
syslogd(8)
und syslog.conf(5)
.
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. Sichereheits-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 sehr viel Informationen über Ihr System enthüllen kann und welche normalen (und anormalen) Operationen er ausführen kann, wenn er darauf Zugriff hat.
Ein paar Zugriffsrechte auf Log-Dateien sind nach der Installation nicht gerade
perfekt (aber das hängt natürlich von Ihrer lokalen Sicherheits-Policy ab).
Zuerst einmal müssen /var/log/lastlog
und
/var/log/faillog
nicht für normalen Nutzer lesbar sein. In der
lastlog-Datei können Sie sehen, wer sich zuletzt eingeloggt hat, und in faillog
eine Zusammenfassung fehlgeschlagener Logins. Der Autor empfiehlt beides auf
660 zu chmod'en. 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 (zeigt zu welchen Nutzern /var/log gehört) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (zeigt zu welchen Gruppen /var/log gehört) # find /var/log -perm +004 (zeigt, welche Dateien von jedem Nutzer gelesen werden können) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (zeigt, welche Dateien zu anderen Gruppen als root oder adm gehört)
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 bei der Erstellung und Rotation anpassen.
chroot
ist eine der mächtigsten Möglichkeiten einen Daemon, einen
Nutzer oder einen anderen Dienst einzuschränken. Stellen Sie sich einfach ein
Gefängnis um Ihr Ziel vor, aus dem Ihr Ziel nicht ausbrechen kann
(Normalerweise, aber es gibt immernoch ein paar Bedinungen, unter denen es
erlaubt es, aus einem solchen Gefängnis auszubrechen). Wenn Sie einem Nutzer
nicht trauen, können Sie ihm eine Change-Root-Umgebung erstellen. Dies kann
zwar einiges an Platten-Platz verbrauchen, da Sie alles benötigte Ausführbare
in das Gefängnis kopieren müssen, ebenso alle Bibliotheken. Sogar wenn der
Nutzer etwas boshaftes anstellt, ist der Schadensrahmen auf das Gefängnis
beschränkt.
Ein gutes Beispiel für diesen Fall ist es, wenn Sie nicht mit
/etc/passwd
authentifizieren, sondern stattdessen LDAP oder MySQL
verwenden. So benötigt Ihr ftp-Daemon lediglich ein Binary und vielleicht ein
paar Bibliotheken. Ein ge-chroot-ete Umgebung wäre eine exzellente
Sicherheits-Umgegung; wenn ein neuer Exploit für diesen ftp-Daemon bekannt wird
kann ein Angreifer nur die Nutzer-ID (User-ID, UID) des internen
ftp-Daemon-Nutzers ausnutzen und nichts anderes.
Natürlich kann auch die Sicherheit ander Daemonen von einem solchen Arrangement profitieren.
Seien Sie jedoch vorgewarnt, dass man auch aus einem
chroot
-Gefängnis ausbrechen kann, wenn der Nutzer, der es laufen
lässt, der Superuser ist. Also ist es notwendig, dass Sie den Dienst als nicht
privilegierter Nutzer laufen lassen. Indem Sie die Umgebung einschränken,
schränken Sie die für alle les- / ausführbaren Dateien, auf die das System
Zugriff hat, und so verkleinern Sie die Möglichkeit einer Ausweitung der
System-Privilegien, indem lokale Verwundbarkeiten der Systemsicherheit
ausgenutzt werden. Aber sogar in dieser Situation können Sie nicht wirklich
sicher sein, dass es für einen cleveren Angreifer keinen Weg gibt, irgendwie
aus dem Gefängnis auszubrechen. Es ist eine zusätzliche Sicherheitsmaßnahme,
nur Server-Programme zu benutzen, die einen gewisse Reputation in Sachen
Sicherheit haben. Sogar die kleinste Lücke, wie eine offene Behandlung von
Dateien, kann von einem geschickten Angreifer genutzt werden, um in das System
einzubrechen. Schließlich wurde chroot
nicht als
Sicherheits-Werkzeug designed, sondern als Test-Werkzeug.
Eine zusätzliche Anmerkung: BIND (Berkeley Internet Name Domain) ist standardmässig unter Debian nicht ge-chroot-et. Tatsächlich ist dies bei keinem Daemon der Fall.
Es gibt übrigens Software (derzeit nicht unter Debian, aber in der Zukunft
sollte sie paketiert sein), die helfen kann, eine chroot-Umgebung einzurichten.
Zum Beispiel kann makejail
mit sehr kleinen Konfigurationsdateien
chroot-Gefängnisse erstellen und aktualisieren. Es versucht ausßerdem alle für
den Daemon benötigten Dateien zu erraten und in dem Gefängis zu installieren.
Mehr Informationen finden Sie unter http://www.floc.net/makejail/
.
Jailer
ist ein ähnliches Werkzeug, dass Sie unter http://www.balabit.hu/downloads/jailer/
erhalten.
Für das Erstellen von chroots (oder Gefänsnissen) ist außerdem
deb.pl
, ein Skript das die Abhängigkeiten ein oder mehrerer
Dateien analysiert.
FIXME: Content missing
Viele Fähigkeiten des Kernels können im laufenden Betrieb verändert werden,
indem man etwas in das /proc
-Datei-System echo-t, oder indem man
sysctl benutzt. Geben Sie sysctl -A ein, um zu sehen, was Sie
konfigurieren können und wie die Optionen hierfür sind. Nur in selten Fällen
müssen Sie hier etwas verstellen, aber Sie können auf diese Art auch die
Sicherheit erhöhen.
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. Anderenfalls macht es gar nichts.
net/ipv4/icmp_echo_ignore_all = 0
Wenn Sie kein ICMP auf Ihrer Firewall blockieren wollen, schalten Sie dies ein.
net/ipv4/tcp_syncookies = 1
Diese Option ist ein zweischneidiges Schwert. Auf der einen Seite schützt es
Ihr System gegen überfluten von syn-Paketen, auf der anderen Seite verletzt es
definierte Standards (RFCs). Diese Option ist recht dumm , da es die
Gegenseite ebenso flutet wie Sie, so dass die Gegenseite auch beschäfftigt ist.
Wenn Sie diese Option ändern wollen, können Sie es auch in
/etc/network/options
ändern, indem Sie syncookies=yes
setzten.
/proc/sys/net/ipv4/conf/all/log_martians = 1
Packete mit unmöglichen Adressen (erzeugt durch falsche Routen) in Ihrem Netzwerk werden protokolliert.
Hier ist ein Beispiel wie man dies und andere nützliche Sachen setzen kann.
Sie sollten diese Informationen zu einem Skript
/etc/network/interface-secure
(der Name kommt aus einem Beispiel)
hinzufügen , und es durch /etc/network/interfaces
wie nachfolgend
gezeigt aufrufen lassen:
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
# Skript-Name: /etc/network/interface-secure # Modifiziert das normale Verhalten, um uns gegen manche TCP/IP Attacken # und Manipulationen zu schützen # # beigetragen von Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Rundruf-Antwort-Schutz # einscahlten echo 0 > /proc/sys/net/ipv4/ip_forward # ip-Weiterleutung abschalten echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP-Syn-Cookie Schutz einschalten echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Packete mit unmöglichen # Adressen logen, seien Sie # hiermit auf ausgelasteten # Webservern vorsichtig echo 1 > /proc/sys/net/ipv4/ip_always_defrag # Defragmentierungs-Schutz # immer einschalten echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # Schutz vor schlechten # Fehlermeldungen einschalten # Jetzt kommt Schutz vor ip-Spoofing for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # und schließlich noch ein paar andere Sachen: # Akzeptieren von umgeleiteten ICMP abschalten for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Abschalten von Source Routed Packets for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Logen von gespooften Paketen, Source Routed Paketen und Redirect # Paketen for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
Um die Möglichkeiten einer Firewall zu haben, um entweder das lokale System
oder andere dahinter zu beschützen, muss der Kernel mit
Firewall-Unterstützung kompiliert worden sein. Der Debian 2.2 Standard-Kernel
(also der Kernel-Version 2.2) stellt die Paket-Filter-Firewall
ipchains
zur Verfügung, der Debian 3.0 Standard-Kernel (Version
2.4) stellt die stateful Paket-Filter iptables
(netfilter) Firewall zur Verfügung. Ältere Debian Distributionen würden einen
passenden Kernel-Patch (Debian 2.1 nutzte Kernel 2.0.34) benötigen.
In jedem Fall ist es recht einfach, einen anderen als den von Debian
installierten Kernel zu benutzen. Sie finden vor-kompilierte Kernel als
Pakete, die Sie leicht auf Ihrem Debian System installieren können. Sie können
auch die Kernel-Quellen downloaden, indem Sie das Paket
kernel-source-X
installieren, und Ihren eigens angepassten Kernel
kompilieren, indem Sie make-kpkg
benutzen.
Auf das Aufsetzen einer Firewall unter Debian wird unter Hinzufügen von Firewall-Fähigkeiten, Abschnitt 5.15 ausführlich eingegangen.
FIXME: More content
Debian GNU/Linux stell verschiedene Patches für den Linux-Kernel, die die Sicherheit erhöhen, zur Verfügung:
lids-2.2.19
)
lcap
)
trustees
)
selinux
, auch verfügbar von der Seite des
Paket-Betreuers
)
kernel-patch-2.2.19-harden
kernel-patch-freeswan
)
kernel-patch-int
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 auf Work Needing and
Prospective Packages
nach ihnen. Ein paar von ihnen sind:
Speicher-Überlauf werde die Attacken über Software genannt, die unzureichende Überprüfung von Eingabe-Grenzen (ein häufiger Programmierfehler) ausnutzen, um durch Programm-Eingaben 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 Speicher-Überläufe zu schützen:
hier
).
Debian GNU/Linux liefert bis einschließlich der Release 3.0 lediglich Software,
um die erste und die letzte dieser Methoden zu implementieren (Kernel-Patch und
Werkzeuge um mögliche Speicher-Überläufe zu finden). Zur Nutzung dieser
Werkzeuge zum Aufspühren von Speicher-Überläufen benötigen Sie in jedem Fall
Programmier-Erfahrung, um den Quellcode zu reparieren (und neu zu compilieren).
Debian stell beispielsweise bfbtester
(einen Überlauf-Tester, der
Programme per brute-force (durch Testen aller Möglichkeiten) auf Kommando-Zeile
und Umgebungs-Variablen durchtestet) und njamd
zur Verfügung.
Was Kernel-Patches (beschrieben im Abschnitt Den
Kernel patchen, Abschnitt 4.13) betrifft, so stellt der Openwall-Patch
Schutz gegen Speicher-Überläufe in 2.2er Linux-Kerneln zur Verfügung, während
Sie für 2.4er Kernel den Grsecureity-Patch (im Paket
kernel-patch-2.4-grsecurity
enthält neben vielen anderen Sachen
(ACLs, Zufälligkeiten im Netzwerk, um es zu erschweren, das Betriebssystem zu
erraten) auch den Openwall-Patch, siehe features
) oder die
Linux-Sicherheits-Module (in den Paketen kernel-patch-2.4-lsm
und
kernel-patch-2.5-lsm
) benutzen müssen.
Seien Sie in jedem Fall gewarnt, dass selbst diese Problem-Umgehungen nicht vor
Speicher-Überläufen schützen können, da es wiederum Möglichkeiten gibt diese zu
umgehen, wie es in Ausgabe
58
des phrack-Magazins beschrieben wurde.
Während der normalen System-Administration 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 Transmissionen 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 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.
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ößen der Quotas festlegen.
Es ein paar wichtige Punkte, über die Sie nachdenken sollten, wenn Sie ein Quota-System aufsetzen:
/home
ebenso wie auf /tmp
.
Auf jeder Partition/jedem Verzeichnis, auf dass Nutzer Schreibzugriff haben, sollten quotiert sein. Finden Sie diese Partitionen und Verzeichnisse und schätzen Sie eine sinnvolle Quota-Größe, die Nutzbarkeit und Sicherheit kombiniert.
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 compilieren. Prüfen Sie
anschließen, 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 Datei /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 Dateien
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 ein /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 (sagen wir mal "ref") wir mit edquota -u ref gemacht. Gruppen-Quotas können mit edquota -g <group> geändert werden. Setzen Sie dann die weiche und die harte Grenze und/oder inode-Quotas, wenn Sie es benötigen.
Mehr Informationen über Quotas finden Sie in der Manual-Seite von quota, und
dem quota Mini-Howto
(/usr/share/doc/HOWTO/en-html/mini/Quota.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 zur Zeit verwaist
ist.
Diesen beiden Befehle sind sehr nützlich, aber Sie arbeiten nur auf ext2 Dateisystemen. Mit 'lsattr' können Sie die Attributen einer Datei anzeigen lassen und mit 'chattr' können Sie Sie ändern. Beachten Sie, dass Attribute nicht dasselbe sind, wie Zugriffsrechte. Es gibt viele Attribute, aber nur die wichtigsten, die die Sicherheit erhöhen, werden hier erwähnt. Es gibt zwei Kennzeichnungen (flags), die nur der Superuser setzen kann.
Zunächst gibt es das 'a' Flag. Wenn dieses bei einer Datei gesetzt ist, dann
kann an diese Datei nur angehängt werden. Dieses Attribut ist für einige
Dateien in /var/log/
nützlich, beachten Sie aber, dass durch
Log-Rotations-Skripte Dateien manchmal verschoben werden.
Das zweite Flag ist das 'i'-Flag, kurz für immutable also unveränderlich. Wenn Sie eine Datei so behandeln, kann Sie weder modifiziert, noch gelöscht, noch umbenannt werden, oder verlinkt werden. Wenn Sie nicht möchten, dass Nutzer einen Blick auf Ihre Konfigurationsdateien werfen können, setzen Sie dieses Flag, und entfernen Sie die Lesbarkeit. Zusätzlich bietet es Ihnen etwas mehr Sicherheit gegen Eindringlinge, da ein Cracker dadurch verwirrt werden könnte, wenn er eine Datei nicht verschieben kann. Dennoch sollten Sie nicht davon ausgehen, dass ein Cracker von Blindheit geschlagen ist, immerhin ist er in Ihr System eingedrungen.
Zusätzlich können Sie die Programme chattr
und lsattr
von Ihrem System entfernen, so dass ein Eindringling mit root-Zugang diese
Attribute nicht verändern (oder auflisten) kann. Da Sie Teil von
e2fsprogs
sind und dieses die Priorität required hat,
können Sie das Paket nicht einfach entfernen. Sie können jedoch diese beiden
Applikationen (und wahrscheinlich noch andere) einfach löschen. Kopieren Sie
Sie vorher auf einen auswechselbaren Datenträger (Diskette?) zusammen mit Ihrem
md5-Summen.
Ein Eindringling auf Ihrem System müsste so erst eigene Kopien dieser Programme herunterladen (wahrscheinlich sogar selbst kompilieren), so dass Sie etwas mehr Zeit bekommen, den Angriff zu erkennen und die Kompromittierung rückgängig zu machen, bevor das gesamte System überrannt wird.
FIXME: This is a bug that could be reported, are any of the binaries provided
by the program useful in production systems? If not, and since the libraries
are needed by many packages a new package e2fsprogs-utils
could be
included with less than Required priority.
Vergessen Sie nicht: chattr
und lsattr
sind nur für
das Dateisystem ext verfügbar.
Sind Sie sicher, dass /bin/login
auf Ihrer Festplatte immer noch
dasselbe Programm ist, dass Sie vor ein paar Monaten installiert haben? Was
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 Eindringlings Erkennungs Umgebung), 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.
Weiterhin können Sie locate
durch slocate
ersetzen.
slocate ist eine um Sicherheit erweiterte Version von GNU locate. Wenn Sie
slocate benutzen, sieht ein Benutzer nur Dateien, auf die er auch Zugriff hat,
während Sie alle Dateien und Verzeichnisse des gesamten Systems ausschließen
können.
FIXME: put references to the snapshot taken after installation.
FIXME: Add a note regarding packages not providing debsums for all apps installed (not mandatory).
Debian liefert einen 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.
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, 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/umout /dev/fd0 echo "md5 Datenbank (nach der Installation) erstellt"
Beachten Sie, dass das Programm md5sum auch auf der Diskette gesichert wird, so dass Sie es später benutzen können, um die anderen Programme Ihres Systems zu prüfen (gesetz dem Fall das 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 es jede Nacht benutzen, um die md5-Summen Ihres Systems gegen Ihren Schnappschuss 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
2.5 (beta) 31 mayo 2004Sat, 17 Aug 2002 12:23:36 +0200jfs@computer.org