[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ weiter ]

Anleitung zum Absichern von Debian
Kapitel 4 - Nach der Installation


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 up, 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 Systemneustart 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 securezty update (siehe Ausführen von Sicherheitsupdates, Abschnitt 4.8) durchführen. Optional können sie sie sich einen Snapshot ihres Systems machen (siehe Einen Schnappschuss des Systems erstellen, Abschnitt 4.17).


4.1 Änderungen im BIOS (noch einmal)

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 auschliesslich 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 nur wenige ein BIOS Passwort benutzen, dass oft zu leicht vergessen wird.


4.2 Ein Passwort für LILO oder GRUB einstellen

Jeder kann sehr einfach eine roor 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 vorgabe 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 generierd ein gehashtes Passwort, das kompatibel mit grub's 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 Klartextpasswörter zu verwenden. Weitere Informationen über grub Passwörter können sie im grub-doc Packet finden.


4.3 Entfernen des root Promptes aus dem Kernel

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, befor das System hochgefahren 
     # wird
     DELAY=0

setzen.

Generieren sie ihr ramdisk image anschliessend 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 Kenel 2.2 nicht portiert wurde). Wenn sie dies als Bug ansehen, beachten sie Bug 145244 bevor sie ihn einsenden.


4.4 Booten von Diskette verbieten

Der standard MBR von Debian vor Version 2.2 verhielt sich nicht wie ein normaler Master Boot Record und lies 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 in grosse Schwierigkeiten mit ihren Installations aus irgendwelchen Gründen 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


4.5 einschränkender Konsolen zugang

Manche Sicherheits Policies könntem Administratoren dazu zwingen, sich erst als als User mit ihrem Passwort auf dem System einzulogen, 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:

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) einzulogen. Diese Eigenschaft kann eingeschränkt werden, indem sie nullok aus der Zeile

     auth       required   pam_unix.so nullok

entfernen.


4.6 Systemneustart auf der Konsole einschränken

Wenn an ihr System eine Tastatur angeschlossen ist, kann jeder (ja wirklich jeder) ihr System neu starten, ohne sich in ihr System einlogen zu müssen. Dies könnte oder könnte nicht gegen ihre Sicherheits Richtlinie 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). Der standardmässig 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 Manual Seite 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.


4.7 Partitionen auf die richtige Art einbinden

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 mount Points 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ässte 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 Skriptkiddies haben Exploits, die versuchen eine ausführbare Datei in /tmp zu erstellen. Wenn sie keine Ahnung haben, werden sie in dieser Grube hängenbleiben. Mit anderen Worten: Ein Benutzer kann nicht dazu getrickts werden, einen ausführbaren Trojaner in /tmp auszuführen, zum Beispiel indem er zufällig /tmp in seine Suchpfad aufnimmt.

Seien sie auch gewarnt, dass manche Skripts darauf aufbauen, dass /tmp ausführbare Rechte hat. Bemerkenswerter weise 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 gillt 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

4.7.1 /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. Regarding noexec, please be aware that it might not offer you that much security. Berücksichtigen sie dies:

     $ 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)

4.7.2 Setzen von /usr auf nur-lesen

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 neumounten 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 installiern von Paketen auszuführen, also möchten sie es vielleicht passend konfigurieren.

To do this modify /etc/apt/apt.conf and add:

       DPkg
       {
           Pre-Invoke  { "mount /usr -o remount,rw" };
           Post-Invoke { "mount /usr -o remount,ro" };
       };

Beachten sie 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.


4.8 Ausführen von Sicherheitsupdates

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 diese Paktet-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 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 ausschliesslich mit securety-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, sollte 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 heraus, 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).


4.9 Den Benutzern einen Sicheren Zugang bereitstellen


4.9.1 User Authentifizierung: PAM

PAM (Pluggable Authentication Modules) erlauben dem System Administrator 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, habend 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 Service, ist es, UNIX Authentifizierung zu emulieren (lessen sie /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz um mehr darüber zu erfahren, wie PAM Services unter Debian arbeiten sollten).

Jede Anwendung mit PAM Unterstützung bietet eine Konfiguratiosn Datei unter /etc/pam.d/ in welche 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 Authentifizierungs Schritte 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 sein zweites Element. Generell sollte es auch "requisite" gesetzt werden, so wird ein login Feger erzeugt, wenn eines der Module versagt.

Die erste Sache, die ich gerne mache, ist es, 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/ zufü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 standard authentifizierungs Modul mit MD5 Passwörtern ein 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/acces.conf eintragen. Nicht zuletzt sollten sie die folgende Zeile aktivieren, wenn sie ihrem Benutzern Limits setzen wollen:

     session  required   pam_limits.so

Dies schränkt die System die ein User nutzen darf ein (siehe unter in Resourcen-Nutzung limitieren: Die limits.conf Datei, Abschnitt 4.9.2). Sie können zum beispiel die Anzahl der Logins, die man haben kann, einschänken (für eine Gruppe von Nutzern oder Systemweit), die Anzahl der Prozesse, den belegten Speicher...

Editieren sie nun /etc/pam.d/passwd und ändern sie die erste Zeile. Si sollten die Option "md5" zufügen, um MD5-Passwörter zu benitzen, ä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 suen können sollen, zu dieser Gruppe. Fügen sie anschliessend die folgene 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 Service zu authentifizieren, ist dies sehr leicht zu erreichen, indem sie Dateien benutzen, in denen die Nutzer, denen es erlaubt ist sich einzulogen (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ässig verweigert).


4.9.2 Resourcen-Nutzung limitieren: Die limits.conf Datei

Sie sollten sich wirklich ernsthaft mit dieser Datei beschäfftigen. Hier können sie ihren Benutzern Resourcen-Limits definieren. Wenn sie PAM benutzen, wird die Date /etc/limits.conf ignoriert und sie sollten /etc/security/limits.conf stattdessen benutzen.

Wenn sie die Resourcen Nutzung nicht einschränken, kann jeder Nutzer mit einem einer gültigen Shell auf ihrem System (or sogar ein Einbrecher, der das System durch einen Service kompomotierte) so viel CPU, Speicher, Stack etc. benutzen, wie das System zur verfügung stellen kann. Dieses Problem der Resourcen Überbeanspruchung kann nur mit der Nutzung von PAM gelöst werden. Beachten sie, dass es einen Weg gibt, Resourcen 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 plazieren.

Für mehr Informationen hierzu lesen sie:

FIXME: Get a good limits.conf up here


4.9.3 User Login Actionen: Editieren von /etc/login.defs

Der nächste Schritt ist es, die grundlegende Konfiguration und die Actionen 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, sturres 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 durchtesten. Beachten sie jedoch die Tatsache, dass diese Einstellung nutzlost ist, wenn sie ein anderes Programm als getty benutzen, wie zum Beispiel mingetty.

     FAILLOG_ENAB        yes

Wenn sie diese Variable einschalten werden fehlgeschlagene Logins protokoliert. 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 Varible "FAILLOG_ENAB" auf yes gesetzt haben, dann sollten sie auch diese Variable auf yes setzen. Dies wird auch unbekannte Nutzernamen protokolieren. Wenn sie dies tun, gehen sie auch sicher, dass die Protokolle sinnvolle Zugriffsrechte haben (Zum Beispiel 640, mit einer angemessenen Gruppenzugehö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ähre verletzen kann.

     SYSLOG_SG_ENAB      yes

Dasgleiche wie bei SYSLOG_SU_ENAB, jedoch für das Programm sg.

     MD5_CRYPT_ENAB      yes

Wie bereits erklärt, reduzieren MD5-Summen-Passwörter grossartig 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.


4.9.4 ftp Einschränken: Editieren von /etc/ftpusers

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 wirklicht ftp erlauben wollen (wozu im allgemmeinen 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 Services 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).


4.9.5 su benutzen

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 ddas Programm su benutzen. Eigentlich ist es die betste 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.


4.9.6 sudo benutzen

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üft ist und sich korrekt authentifiziert ist er in der Lage, Kommandos, die in /etc/sudoers definiert wurde. 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.


4.9.7 verweigern von administrativen Fernzugriff

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

4.9.8 Nutzer einschränken

Manchmal werden sie vielleicht denken, dass sie einen Nutzer auf ihrem System erstellen müssen, um einen bestimmten Service (pop3 Email Server oder ftp) anzubieten. Bevor sie dies tun, erinnern sie sich zuerst darad, 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 zugegeriffen werden kann, beachten sie, dass es Nutzern möglich sein wird, sich einzuloggen. Sie können dies behebeben, 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, ein Nutzer, der auf ein interaktives Programm zugreifen kann (dass 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 Service, 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.


4.9.8.1 ssh für Nutzer einschränken

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 Paktete 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 remote Zugriff auf die Shell als auch remote Copy ü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 besiutzen, um Einmischungen durch den Nutzer zu verhinern (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

4.9.9 prüfen der Nutzer von Hand

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 For this to work the user cannot modify the .profile, 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 nehmen, ihn ändern und 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, dass sich als eine Bibliothek zwischen 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 sies nicht als Shell funktionert (auch nicht, wenn sie es zu /etc/shells hinzufügen).


4.9.10 Komplettieren von Nutzer Überwachung

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.


4.9.11 Nutzer Profil nachprüfen

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, dass 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.


4.9.12 umasks der Nutzer einstellen

Abhängig von ihrer 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 sie 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). 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...)

Debian's default umask Einsztellung is 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 grosszü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 die Standards für Nutzer werden, wenn sie mit dem adduser Kommando erstellt werden.

Beachten sie, dass ein Nutzer immernoch seine umask Einstellung abändern kann, wenn sie es möchten, um sie grosszügiger oder einschränkender zu machen.


4.9.13 Nutzer Sicht/Zugriff limitieren

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, bedenken sie es vorsichtig. Ein Nutzer kann normalerweise, wenn er nicht in eine streng abgeschirmte Umgebung (wie chroot) gesetzt wird, ziemlich viel Informationen von ihrem System sammeln, darunter:

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, und die Verzeichnisse, auf die er Zugriff hat.


4.10 Die Nutzung von tcpwrappers

TCP-Wrapper (Schurtzumschläge für TCP) wurden entwickelt, als es noch keine echten Paket-Filter gab, aber Zugsngskontrollen notwendig waren. Ein TCP-Wrapper erlaubt ihnen, einem Host oder einer Domain einen Service zu erlauben oder zu verweigern und default-mässig 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 Services

Einerseits werde manche Services, einschliesslich telnet, ftp, netbios, swat und finger in /etc/inetd.conf konfiguriert. Sie sehen es daran, dass die Konfigurations-Datei zuerst /usr/sbin/tcpd aufruft. Andererseits, selbst wenn ein Service 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. Services, die unter Debian mit TCP-Wrappern compiliert wurden, schliessen 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 Services, die gegen dei Wrapper-Bibliothek kompiliert wurden, der host.deny oder host.allow Datei hinzufügen, aber 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 abgewiesenden Services 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 "Verbinung zu %d blockiert" root) &

Beachten Sie: Das obige Beispiel kann sehr leicht geDoSet (Denial of Service, Verbindungsaufbau abgelehnt) werden, indem man versucht, sehr viele Verbindungen in kurzer Zeit aufzubauen. Viele Emails bedeuten viel Datei-Aktivitöt, lediglich erreicht durch das Senden von ein paar Paketen.


4.11 Die Wichtigkeit von Logs und Alarmen

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% Restrisiko gibt, für die keine Sichereheitsmaßnamen greifen. Als erstes gillt es, Angriffe auf diese 1% zu erkennen und als zweites Alarm auszuölö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 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.


4.11.1 Nutzen und anpassen von logcheck

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 Regelwidrigkeiten für drei unterschiedliche Setups (Workstation, Server und paranoid). Das Debian-Paket umfasst eine Konfigurations-Datei /etc/logcheck/logcheck.conf, die vom Program eingelesen wird, die definiert, an welchen Nutzer die Testergebnisse geschickt werden sollen. Es stellt ausserdem 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 ensprechende 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 wird 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 auszuschliessen, 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ächtsen 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-Pozess. 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).


4.11.2 Konfigurieren, wohin Alarmmeldungen geschickt werden sollen

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, werfen Sie einen Blick auf die Datei syslog.conf und deren Dokumentation, falls nicht. 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 mailbos von root senden. Diese Mailbos 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 besonderer Funktion und andere Aliase auf Ihrem System. Auf einem kleinen System ist es wohl am einfachtes, sicherzustellen, dass alle Alias 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.


4.11.3 Nutzen eines loghosts

Ein Loghost ist ein host der die syslog-Daten über ein Netzwerk sammelt. Wenn eine Ihrer Maschinen gecracked wird, kann der Eindringling seine Spuren nicht verwischen, solange er den Loghost nicht ebenfalls gecracked 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 änder Sie die Zeile

     SYSLOGD=""

in

     SYSLOGD="-r"

Als nächstes konfigurieren Sie die anderen Machinen, 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 mitloggen 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 Logdatei gelöscht hat). Sehen Sie für weitere Informationen die Handbuch-Seiten syslog(3), syslogd(8) und syslog.conf(5).


4.11.4 Zugriffsrechte auf Log-Dateien

Es ist nicht nur wichtig zu entscheiden, wie Warnungen genutzt werden, sondern auch, wer hierauf zugriff hat, d.h. wer Log-Dateien (fall Sie nicht einen Log-Host verwenden) lesen oder verändern kann. Sichereheits-Alarme, die ein Attacker verändern oder abschalten kann, sind im Falle eines Eindringens nicht viel wert. Ausserdem sollten Sie berücksichtigen, dass Log-Dateien einem Eindringling sehr viel Informationen über Ihr System enthüllen kann und welche normalen (und annormalen) 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 Author 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.


4.12 Benutzen von chroot

chroot chroot ist eine der mächtigsten Möglichkeiten einen Daemon, einen Nutzer oder einen anderen Service 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 wie 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 Service 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 Sicherheitsmassnahme 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. Schliesslich 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 Konfigurations-Dateien chroot-Gefängnisse erstellen und aktualisieren. Es versucht ausserdem 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 ausserden deb.pl, ein Skript das die Abhängigkeiten ein oder mehrerer Dateien analysiert.


4.12.1 Kernel configuration


4.12.2 Konfigurieren der Netzwerk-Fähigkeiten des Kernels

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 schliesslich noch ein paar andere Sachen:
     # Akzeptieren von umgeleitetet 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

4.12.3 Konfigurieren der Firewall

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 compiliert worden sein. Der standard Debian 2.2 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 Oaket-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 Kernelzu benutzen. Sie finden vor-compilierte 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 compilieren, 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.


4.13 Den Kernel patchen

FIXME: More content

Debian GNU/Linux stell verschiedene Patches für den Linux-Kernel zur Vergügung, die die Sicherheit erhöhen:

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:


4.14 Schutz vor Speicher-Überläufen

Speicher-Überlauf werde die Attacken über Software genannt, die unzureichende Überprüfung von Eingabegrenzen (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össere Privilegien gewährt (setuid oder setgid) kann zu einem kompromitierten System führen.

Es gibt hauptsächlich vier Methoden, um sich gegen Speicher-Überläufe zu schützen:

Debian GNU/Linux liefert bis einschliesslich 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 aufsprü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 Programe per brute-force (durchtesten aller Möglichkeiten) auf Kommado-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, und 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 Problemumgehungen nicht vor Speicher-Überläufen schützen lännen, da es wiederum Möglichkeiten gibt diese zu umgehen, wie es in Ausgabe 58 des phrack-Magazins beschrieben wurde.


4.15 sichere Datei-Übertragungen

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 wird duch 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 nocht 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.


4.16 Dateisystem Einschränken und konrollieren


4.16.1 Benutzung von Quotas

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össen der Quotas festlegen.

Es ein paar wichtige Punkte, über die Sie nachdenken sollten, wenn Sie ein Quota-System aufsetzen:

Auf jeder Partition/jedem Verzeichniss, auf dass Nutzer Schreibzugriff haben, sollten quotiert sein. Finden Sie diese Partitionen udn Verzeichnisse und schätzen Sie eine sinnvolle Quota-Grösse, 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 anschliessen, ob das Paket quota isntalliert 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 lere 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össen 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 der 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 ausserdem dass pam_limits.so diegleiche Funktionalität zur Verfügung stellen kann und das lshell Paket zur Zeit verwaist ist.


4.16.2 chattr/lsattr

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 Konfigurations-Dateien 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 compilieren), so dass Sie etwas mehr Zeit bekommen, den Angriff zu erkennen und die Komprimitierungen 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.


4.16.3 Prüfen der Integrität des Dateisystems

Sind Sie sicher, dass /bin/login auf Ihrer Festplatte immernoch 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 eta 1 zu 3,4e3803), so sind Sie sicher, solange niemand den Algorithmus gehackt hat, der die md5-Summen auf Ihrer Maschine erstellt. Dies ist, nunja, 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 lizensiert), 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 ausschliessen 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).


4.16.4 Aufsetzen von setuid-Check

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 hält 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 auch checksecurity(8) für weitere Konfigurations-Informationen.


4.17 Einen Schnappschuss des Systems erstellen

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 Kompromitierung (siehe Nach einer Komprimitierung, Kapitel 10) benutzen. Sie sollten so einen Schnappschuss immer dann erneuern, wenn Sie das System upgraden, 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.


4.18 Andere Empfehlungen


4.18.1 Benutzen Sie keine Software, die von svgalib abhängt

SVGAlib ist ganz nett für Konsolen-Liebhaber wie mich, aber in der Vergangenheit wurde mehrfach gezeigt, dass es ziemlich unsicher ist. Exploits durch zgv wurden veröffentlicht, und es war einfach root zu werden. Versuchen Sie die Nutzung von SVGAlib Programmen wann immer nur möglich zu verhindern.


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ weiter ]

Anleitung zum Absichern von Debian

2.5 (beta) 14 febrero 2004Sat, 17 Aug 2002 12:23:36 +0200

Javier Fernández-Sanguino Peña jfs@computer.org