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


Securing Debian Manual
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 Ihrer Einrichtung ab, aber um physischen Zugriff zu verhindern, sollten Sie Änderen Sie das BIOS (noch einmal), Abschnitt 4.3, Ein Passwort für LILO oder GRUB einstellen, Abschnitt 4.4, Entfernen des Root-Promptes aus dem Kernel, Abschnitt 4.6, Einschränkung der Anmeldemöglichkeiten an der Konsole, Abschnitt 4.7 und Einschränkung des System-Neustarts von der Konsole aus, Abschnitt 4.8 lesen.

Bevor Sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um ein öffentliches Netzwerk handelt, sollten Sie wenigstens eine Sicherheitsaktualisierung (siehe Ausführen von Sicherheitsaktualisierungen, Abschnitt 4.2) durchführen. Daneben können Sie auch einen Schnappschuss Ihres Systems machen (siehe Einen Schnappschuss des Systems erstellen, Abschnitt 4.19).


4.1 Abonnement der Security-Announce-Mailingliste von Debian

Um Informationen zu verfügbaren Sicherheitsaktualisierungen und die Debian-Sicherheits-Ankündigungen (DSA) zu erhalten, sollten Sie Debians Security-Announce-Mailingliste abonnieren. Lesen Sie Das Sicherheitsteam von Debian, Abschnitt 7.1 für weitere Informationen, wie das Sicherheitsteam von Debian arbeitet. Hinweise, wie Sie die Mailinglisten von Debian abonnieren, finden Sie unter http://lists.debian.org.

DSAs werden mit der Signatur des Sicherheitsteams von Debian unterschrieben, die unter http://security.debian.org erhältlich ist.

Sie sollten in Betracht ziehen, auch die Mailingliste debian-security zu abonnieren. Dort finden allgemeine Diskussionen zu Sicherheitsthemen im Betriebssystem Debian statt. Sie können auf der Liste sowohl mit gleichgesinnten Systemadministratoren als auch mit Entwicklern von Debian und Programmautoren in Kontakt treten. Diese werden Ihre Fragen beantworten und Ihnen Ratschläge geben.

FIXME: Add the key here too?


4.2 Ausführen von Sicherheitsaktualisierungen

Sobald neue Sicherheitslöcher in einem Paket entdeckt wurden, reparieren sie Debians Paketbetreuer und Originalautoren im Allgemeinen innerhalb von Tagen oder sogar Stunden. Nachdem das Loch gestopft wurde, werden neue Pakete unter http://security.debian.org bereit gestellt.

Wenn Sie eine Debian-Veröffentlichung installieren, müssen Sie berücksichtigen, dass es seit der Veröffentlichung Sicherheitsaktualisierungen gegeben haben könnte, nachdem entdeckt wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es Zwischenveröffentlichungen gegeben haben, die diese Paketaktualisierungen enthalten. Für Debian 3.1 Sarge gab es vier Zwischenveröffentlichungen.

Während der Installation werden Sicherheitsaktualisierungen für Ihr System eingerichtet, offene Sicherheitsaktualisierungen heruntergeladen und Ihrem System hinzugefügt, sofern Sie sich nicht explizit dagegen entscheiden oder keine Internetverbindung besteht. Die Aktualisierungen werden noch vor dem ersten Systemstart eingespielt, damit das neue System sein Leben so aktuell wie möglich beginnt.

Um Ihr System manuell zu aktualisieren, fügen Sie die folgende Zeile in Ihre /etc/apt/sources.list ein. So werden Sie Sicherheitsaktualisierungen automatisch erhalten, wann immer Sie Ihr System aktualisieren. Ersetzen Sie [CODENAME] mit dem Namen der Veröffentlichung, z.B. mit squeeze.

       deb http://security.debian.org/ [CODENAME]/updates main contrib non-free

Hinweis: Falls Sie den Testing-Zweig einsetzen, sollten Sie die Sicherheitsspiegel für Testing verwenden. Das wird unter Sicherheitsunterstützung für den Testing-Zweig, Abschnitt 10.1.4 beschrieben.

Wenn Sie dies erledigt haben, stehen Ihnen zahlreiche Werkzeuge zur Verfügung, mit denen Sie Ihr System aktualisieren können. Wenn Sie ein Desktop-System einsetzen, können Sie eine Anwendung mit dem Namen Update-notifier verwenden[14], mit der Sie leicht prüfen können, ob neue Aktualisierungen verfügbar sind. Damit können Sie Ihr System auch über den Desktop auf den neusten Stand bringen (mit update-manager). Weitere Informationen finden Sie unter Überprüfung von Aktualisierungen auf dem Desktop, Abschnitt 10.1.2.2. Für den Desktop können Sie auch Synaptic (GNOME), Kpackage oder Adept (KDE) einsetzen, die einen größeren Funktionsumfang aufweisen. Wenn Sie auf einem textbasierten Terminal arbeiten, stehen Ihnen Aptitude, Apt und Dselect, wobei letzteres veraltet ist, zur Verfügung:

If you like, you can add the deb-src lines to /etc/apt/sources.list as well. See apt(8) for further details.


4.2.1 Sicherheitsaktualisierungen für Bibliotheken

Once you have executed a security update you might need to restart some of the system services. If you do not do this, some services might still be vulnerable after a security upgrade. The reason for this is that daemons that are running before an upgrade might still be using the old libraries before the upgrade [15].

From Debian Jessie and up, you can install the needrestart package, which will run automatically after each APT upgrade and prompt you to restart services that are affected by the just-installed updates. In earlier releases, you can run the checkrestart program (available in the debian-goodies package) manually after your APT upgrade.

Einige Pakete (wie libc6) werden diesen Test in der Postinst-Phase für eine begrenzte Anzahl von Diensten durchführen, da ein Upgrade von notwendigen Bibliotheken einige Anwendungen unbrauchbar machen kann, wenn sie nicht neu gestartet werden [16].

Indem das System auf Runlevel 1 (Single User) und dann zurück auf Runlevel 3 (Multi User) gebracht wird, sollten die meisten (wenn nicht alle) Systemdienste neu gestartet werden. Dies ist aber keine Option, wenn Sie die Sicherheitsaktualisierung über eine Verbindung aus der Ferne (z.B. mit Ssh) vornehmen, da diese getrennt werden würde.

Excercise caution when dealing with security upgrades if you are doing them over a remote connection like ssh. A suggested procedure for a security upgrade that involves a service restart is to restart the SSH daemon and then, immediately, attempt a new ssh connection without breaking the previous one. If the connection fails, revert the upgrade and investigate the issue.


4.2.2 Sicherheitsaktualisierung des Kernels

Stellen Sie zunächst sicher, dass Ihr Kernel durch das Paketsystem verwaltet wird. Wenn Sie die Installation mit dem Installationssystem von Debian 3.0 oder früher durchgeführt haben, ist Ihr Kernel nicht in das Paketsystem integriert und könnte veraltet sein. Sie können das leicht überprüfen, indem Sie Folgendes ausführen:

     $ dpkg -S `readlink -f /vmlinuz`
     linux-image-2.6.18-4-686: /boot/vmlinuz-2.6.18-4-686

Wenn Ihr Kernel nicht vom Paketsystem verwaltet wird, werden Sie anstatt der obigen Nachricht die Rückmeldung bekommen, dass das Paketverwaltungsprogramm kein Paket finden konnte, das mit der Datei verbunden ist. Die obige Meldung besagt, dass die Datei, die mit dem laufenden Kernel verbunden ist, vom Paket linux-image-2.6.18-4-686 zur Verfügung gestellt wird. Sie müssen also zuerst ein Paket mit einem Kernel-Image von Hand installieren. Das genaue Kernel-Image, das Sie installieren sollten, hängt von Ihrer Architektur und Ihrer bevorzugten Kernelversion ab. Wenn Sie das einmal erledigt haben, können Sie die Sicherheitsaktualisierungen des Kernels wie die jedes anderen Pakets durchführen. Beachten Sie allerdings, dass Kernelaktualisierungen nur für Aktualisierungen der gleichen Kernelversion wie der Ihrigen durchgeführt werden. D.h. apt wird nicht automatisch Ihren Kernel von 2.4 auf 2.6 aktualisieren (oder von 2.4.26 auf 2.4.27 [17]).

Das Installationssystem von aktuellen Debian-Veröffentlichungen wird den gewählten Kernel als Teil des Paketsystems behandeln. So können Sie überprüfen, welche Kernel Sie installiert haben:

     $ COLUMNS=150 dpkg -l 'linux-image*' | awk '$1 ~ /ii/ { print $0 }'

Um festzustellen, ob Ihr Kernel aktualisiert werden muss, führen Sie Folgendes aus:

     $ kernfile=`readlink -f /vmlinuz`
     $ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'`
     $ apt-cache policy $kernel
     linux-image-2.6.18-4-686:
       Installiert: 2.6.18.dfsg.1-12
       Installationskandidat: 2.6.18.dfsg.1-12
       Versionstabelle:
      *** 2.6.18.dfsg.1-12 0
             100 /var/lib/dpkg/status

Wenn Sie eine Sicherheitsaktualisierung durchführen, die auch das Kernel-Image umfasst, müssen Sie das System neu starten, damit die Sicherheitsaktualisierung Wirkung zeigen kann. Anderenfalls lassen Sie immer noch das alte (und verwundbare) Kernel-Image laufen.

Wenn Sie das System neu starten müssen (wegen eines Kernel-Upgrades), sollten Sie sicherstellen, dass der Kernel fehlerfrei booten wird und die Netzwerkverbindungen hergestellt werden, besonders wenn die Sicherheitsaktuali sierung über eine Verbindung aus der Ferne wie mit SSH durchgeführt wird. Für den ersten Fall können Sie Ihren Boot-Loader so konfigurieren, dass er den Originalkernel lädt, wenn ein Fehler auftritt (für weiterführende Informationen sollten Sie Remotely rebooting Debian GNU/Linux machines lesen). Im zweiten Fall müssen Sie ein Skript verwenden, das die Netzwerkverbindungen testen kann und überprüft, ob der Kernel das Netzwerksystem korrekt gestartet hat, und, wenn das nicht geschehen ist, das System neu startet [18]. Dies sollte böse Überraschungen verhindern, wie wenn Sie den Kernel aktualisieren und dann nach einem Reboot merken, dass die Netzwerkhardware nicht richtig erkannt oder konfiguriert wurde, und Sie daher eine weite Strecke reisen müssen, um das System wieder zum Laufen zu bringen. Natürlich hilft es beim Debuggen von Reboot-Problemen aus der Ferne, wenn die serielle Konsole des Systems [19] mit einem Konsolen- oder Terminalserver verbunden ist.


4.3 Änderen Sie das 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 Wechseldatenträgern booten müssen, die Standard-BIOS-Einstellung ändern, so dass das System ausschließlich von der Festplatte bootet. Gehen Sie sicher, dass Sie Ihr BIOS-Passwort nicht verlieren, oder Sie werden nicht mehr ins BIOS zurückkehren können, um die Einstellung wieder zu ändern, damit Sie im Falle eines Festplattenfehlers Ihr System wiederherstellen können, indem Sie zum Beispiel eine CD-ROM benutzen.

Eine andere, weniger sichere, aber bequemere Möglichkeit ist es, das BIOS so einzustellen, dass es von der Festplatte bootet, und nur falls dies fehlschlägt zu versuchen, von austauschbaren Datenträgern zu booten. Übrigens wird dies oft so gemacht, weil viele Leute ihr BIOS-Passwort nur selten benutzen, so dass sie es leicht vergessen.


4.4 Ein Passwort für LILO oder GRUB einstellen

Jeder kann sehr einfach eine Root-Shell auf Ihrem System bekommen, indem er einfach <Name-Ihres-Bootimages> init=/bin/sh am Bootprompt eingibt. Nachdem die Passwörter geändert und das System neu gestartet wurde, hat die Person uneingeschränkten Root-Zugang und kann nach Belieben alles auf Ihrem System machen. Nach dieser Prozedur haben Sie keinen Root-Zugang mehr zu Ihrem System, weil Sie das Root-Passwort nicht kennen.

Um sicher zu stellen, dass dies nicht passieren kann, sollten Sie den Boot-Loader mit einem Passwort schützen. Sie können zwischen einem globalen Passwort und Passwörtern für bestimmte Images wählen.

Für LILO müssen Sie die Konfigurationsdatei /etc/lilo.conf bearbeiten 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

Stellen Sie danach sicher, dass die Konfigurationsdatei nicht für alle lesbar ist, um zu verhindern, dass lokale Benutzer das Passwort lesen können. Haben Sie dies getan, rufen Sie lilo auf. Wenn Sie die restricted-Zeile weglassen, wird LILO immer nach dem Passwort fragen, egal ob LILO Parameter übergeben wurden oder nicht. Die Standard-Zugriffsrechte auf /etc/lilo.conf erlauben Root das Lesen und Schreiben und der Gruppe von lilo.conf, ebenfalls Root, das Lesen.

Wenn Sie GRUB anstelle von LILO verwenden, bearbeiten Sie /boot/grub/menu.lst und fügen Sie die folgenden zwei Zeilen am Anfang ein (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, können Sie Ihr Passwort verschlüsselt ablegen. Das Dienstprogramm grub-md5-crypt erzeugt ein gehashtes Passwort, das mit GRUBs Verschlüsselungsalgorithmus (MD5) kompatibel ist. Um Grub mitzuteilen, dass ein Passwort im MD5-Format verwendet wird, benutzen Sie die folgende Anweisung:

       timeout 3
       password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0

Der Parameter --md5 wurde hinzugefügt, um bei Grub einen MD5-Authentifizierungsprozess zu erzwingen. Das angegebene Passwort ist die mit MD5 verschlüsselte Version von »hackmich«. MD5-Passwörter sind Klartext-Passwörtern vorzuziehen. Weitere Informationen über Grub-Passwörter können Sie im Paket grub-doc finden.


4.5 Entfernen des Root-Prompts von Initramfs

Hinweis: Dies betrifft alle Standard-Kernel, die nach Debian 3.1 veröffentlicht wurden.

Die Linux-Kernel 2.6 enthalten die Möglichkeit, während des Bootvorgangs auf eine Root-Shell zuzugreifen. Dies geschieht, wenn beim Laden von Initramfs ein Fehler auftritt. Dadurch kann der Administrator auf eine Rettungs-Shell mit Root-Rechten zugreifen. Mit dieser Shell können von Hand Module geladen werden, falls eine automatische Erkennung scheitern sollte. Dieses Verhalten ist Standard für ein von Initramfs-tools erzeugtes Initramfs. Folgende Fehlermeldung wird auftreten:

       "ALERT!  /dev/sda1 does not exist.  Dropping to a shell!

In order to remove this behavior you need to set the following boot argument:panic=0. Add this to the variable GRUB_CMDLINE_LINUX in /etc/default/grub and issue update-grub or to the append section of /etc/lilo.conf.


4.6 Entfernen des Root-Promptes aus dem Kernel

Hinweis: Dies trifft nicht auf Kernel zu, die in Debian 3.1 enthalten sind, da die Wartezeit auf Null verändert wurde.

Linux 2.4-Kernel bieten kurz nach dem Laden des Cramfs einen Weg, Zugriff auf eine Root-Shell zu bekommen, also während das System bootet. Es erscheint eine Meldung, die dem Administrator erlaubt, eine ausführbare Shell mit Root-Privilegien zu öffnen. Diese Shell kann dazu benutzt werden, manuell Module zu laden, falls die automatische Erkennung fehlschlägt. Dies ist das Standard-Verhalten bei initrd's linuxrc. Die folgende Meldung wird erscheinen:

       Press ENTER to obtain a shell (waits 5 seconds)

Um dieses Verhalten zu entfernen, müssen Sie /etc/mkinitrd/mkinitrd.conf bearbeiten und folgenden Eintrag setzen:

       # DELAY  Anzahl Sekunden, die das linuxrc Skript warten soll, 
       # um den Benutzer Eingriffe zu erlauben, bevor das System hochgefahren
       # wird
       DELAY=0

Erstellen Sie anschließend Ihr Ramdisk-Image neu. Dies können Sie zum Beispiel so tun:

       # cd /boot
       # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7

oder (vorzugsweise) so:

       # dpkg-reconfigure -plow kernel-image-2.4.x-yz

4.7 Einschränkung der Anmeldemöglichkeiten an der Konsole

Manche Sicherheitsrichtlinien können Administratoren dazu zwingen, sich erst als Benutzer mit ihrem Passwort auf dem System einzuloggen und dann Superuser zu werden (mit Su oder Sudo). Eine solche Richtlinie wird in Debian durch Bearbeitung der Dateien /etc/pam.d/login und /etc/securetty (falls Sie PAM verwenden) implementiert.

Wenn Sie PAM benutzen, können Sie auch andere Änderungen am Login-Prozess, die auch Einschränkungen für einzelne Benutzer oder Gruppen zu bestimmten Zeiten enthalten können, durch Konfiguration der Datei /etc/pam.d/login vornehmen. Eine interessante Eigenschaft, die man auch abschalten kann, ist die Möglichkeit, sich mit einem leeren Passwort (Null-Passwort) anzumelden. Diese Eigenschaft kann eingeschränkt werden, indem Sie nullok aus folgender Zeile entfernen:

       auth       required   pam_unix.so nullok

4.8 Einschränkung des System-Neustarts von der Konsole aus

Wenn eine Tastatur an Ihr System angeschlossen ist, kann es jeder (ja, wirklich jeder) mit physischem Zugang zu Ihrem System neu starten, ohne sich an Ihrem System anmelden zu müssen, einfach indem er die Tastenkombination Strg+Alt+Entf drückt (auch als Affengriff bekannt). Dies könnte gegen Ihre Sicherheitsrichtlinien verstoßen (oder auch nicht).

Dies ist schwerwiegender, wenn das Betriebssystem in einer virtuellen Umgebung läuft. Dann erstreckt sich diese Fähigkeit auch auf Benutzer, die Zugriff auf die virtuelle Konsole haben (was auch über das Netzwerk geschehen könnte). Beachten Sie zudem, dass in einer solchen Umgebung diese Tastenkombination ständig verwendet wird (um in einigen grafischen Benutzeroberflächen eine Login-Shell zu öffnen), so dass ein Systemadministrator sie virtuell auslösen kann und das System neu startet.

Es gibt zwei Möglichkeiten, dies einzuschränken:

Wenn Sie dies einschränken wollen, müssen Sie in /etc/inittab sicherstellen, dass die Zeile, die ctrlaltdel enthält, shutdown mit der Option -a aufruft.

Standardmäßig enthält Debian diese Optionen:

       ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

The -a switch, as the shutdown(8) manpage describes,makes it possible to allow some users to shutdown the system. For this the file /etc/shutdown.allow must be created and the administrator has to include there the name of users which can boot the system. When the three finger salute combination is pressed in a console the program will check if any of the users listed in the file are logged in. If none of them is, shutdown will not reboot the system.

Wenn Sie die Tastenkombination Strg+Alt+Entf deaktivieren möchten, müssen Sie nur die Zeile mit ctrlaltdel in /etc/inittab auskommentieren.

Vergessen Sie nicht, init q auszuführen, nachdem Sie diese Datei bearbeitet haben, damit die Änderungen wirksam werden.


4.9 Einschränkung der Tastenkombination Magische S-Abf

Die Tastenkombination Magische S-Abf (Magic SysRq) erlaubt es Benutzern einer Konsole eines Linux-Systems, bestimmte systemnahe Befehle auszuführen, indem gleichzeitig Alt+S-Abf und eine bestimmte Taste gedrückt wird. Die Taste S-Abf wird auf vielen Tastaturen mit Druck bezeichnet.

Seit der Veröffentlichung von Etch ist die Tastenkombination Magische S-Abf im Linux-Kernel aktiviert, damit die Benutzer einer Konsole bestimmte Privilegien erhalten können. Ob dies auf Ihr System zutrifft, erkennen Sie daran, ob /proc/sys/kernel/sysrq existiert, und an dessen Wert:

     $ cat /proc/sys/kernel/sysrq 
     438

Der oben gezeigte Standardwert erlaubt alle S-Abf-Funktionen mit Ausnahme der Möglichkeit, Signale an Prozesse zu senden. Zum Beispiel können Benutzer, die an der Konsole angemeldet sind, alle Systeme nur-lesend neu einhängen, das System neu starten oder eine Kernelpanik auslösen. Wenn alle Fähigkeit aktiviert sind oder in älteren Kernel-Versionen (früher als 2.6.12), wird der Wert einfach 1 sein.

Sie sollten diese Fähigkeit deaktivieren, wenn der Zugang zur Konsole nicht auf angemeldete Benutzer beschränkt ist, nämlich wenn die Konsole an ein Modem angebunden ist, es leichten physischen Zugang zum System gibt oder es in einer virtuellen Umgebung läuft und andere Benutzer auf die Konsole zugreifen können. Dafür müssen Sie /etc/sysctl.conf bearbeiten und folgende Zeile einfügen:

     # Schaltet die Magische S-Abf-Taste ab
     kernel.sysrq = 0

Weitere Informationen finden Sie im security chapter in the Remote Serial Console HOWTO, in der Kernel SysRQ documentation und dem Wikipedia-Eintrag zur Magischen S-Abf-Taste.


4.10 Partitionen auf die richtige Art einhängen

Wenn Sie ein Ext-Dateisystem (ext2, ext3 oder ext4) einhängen, können Sie verschiedene Optionen mit dem mount-Befehl oder in /etc/fstab verwenden. Dies ist zum Beispiel mein fstab-Eintrag für meine /tmp-Partition:

       /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2

Achten Sie auf den Abschnitt mit den Optionen. Die Option nosuid ignoriert komplett alle setuid- und setgid-Bits, während noexec das Ausführen von Programmen unterhalb des Einhängepunkts verbietet und nodev Gerätedateien ignoriert. Das hört sich toll an, aber:

Die Option noexec, die verhindert, dass Programme ausgeführt werden können, ließ sich in früheren Kernelversionen leicht umgehen:

       alex@joker:/tmp# mount | grep tmp
       /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
       alex@joker:/tmp# ./date
       bash: ./date: Keine Berechtigung
       alex@joker:/tmp# /lib/ld-linux.so.2 ./date
       So 3. Dec 17:49:23 CET 2000

Neuere Versionen des Kernels verarbeiten aber die Option noexec richtig:

       angrist:/tmp# mount | grep /tmp
       /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
       angrist:/tmp# ./date
       bash: ./tmp: Keine Berechtigung
       angrist:/tmp# /lib/ld-linux.so.2 ./date 
       ./date: error while loading shared libraries: ./date: failed to map segment 
       from shared object: Operation not permitted

However, many script kiddies have exploits which try to create and execute files in /tmp. If they do not have a clue, they will fall into this pit. In other words, a user cannot be tricked into executing a trojanized binary in /tmp e.g. when /tmp is accidentally added into the local PATH.

Seien Sie sich auch bewusst, dass manche Skripte darauf aufbauen, dass /tmp ausführbare Rechte hat. Bemerkenswerterweise hatte (oder hat?) Debconf Probleme bei dieser Sache, weitere Informationen enthält Fehler 116448.

Nachfolgend ein gründlicheres Beispiel. Eine Anmerkung dazu: /var könnte auch noexec enthalten, aber manche Software [26] verwahrt ihre Programme unterhalb von /var. Dasselbe gilt für die Option nosuid.

     /dev/sda6   /usr          ext3    defaults,ro,nodev       0       2
     /dev/sda12  /usr/share    ext3    defaults,ro,nodev,nosuid        0       2
     /dev/sda7   /var          ext3    defaults,nodev,usrquota,grpquota 0      2
     /dev/sda8   /tmp          ext3    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda9   /var/tmp      ext3    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda10  /var/log      ext3    defaults,nodev,nosuid,noexec    0       2
     /dev/sda11  /var/account  ext3    defaults,nodev,nosuid,noexec    0       2
     /dev/sda13  /home         ext3    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
     /dev/fd0    /mnt/fd0      ext3    defaults,users,nodev,nosuid,noexec      0       0
     /dev/fd0    /mnt/floppy   vfat    defaults,users,nodev,nosuid,noexec      0       0
     /dev/hda    /mnt/cdrom    iso9660 ro,users,nodev,nosuid,noexec            0       0

4.10.1 /tmp noexec setzen

Be careful if setting /tmp noexec when you want to install new software, since some programs might use it for installation. apt is one such program (see http://bugs.debian.org/116448) if not configured properly APT::ExtractTemplates::TempDir (see apt-extracttemplates(1)). You can set this variable in /etc/apt/apt.conf to another directory with exec privileges other than /tmp.


4.10.2 /usr auf nur-lesend setzen

Wenn Sie auf /usr nur lesenden Zugriff erlauben, werden Sie nicht in der Lage sein, neue Pakete auf Ihrem Debian-GNU/Linux-System zu installieren. Sie werden es erst mit Schreibzugriff erneut einhängen müssen, die Pakete installieren und dann wieder nur mit lesendem Zugriff einhängen. Apt kann so konfiguriert werden, dass Befehle vor und nach dem Installieren von Paketen ausgeführt werden. Daher müssen Sie es passend konfigurieren.

Dafür müssen Sie /etc/apt/apt.conf bearbeiten und Folgendes einfügen:

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

Beachten Sie, dass das Post-Invoke mit der Fehlermeldung »/usr ist belegt« scheitern kann. Dies passiert vorwiegend, wenn Sie eine Datei benutzen, die aktualisiert wurde. Sie können diese Programme finden, indem Sie Folgendes ausführen:

     # lsof +L1

Halten Sie diese Programme an oder starten Sie sie erneut und rufen dann Post-Invoke manuell auf. Achtung! Das bedeutet, dass Sie wahrscheinlich jedes Mal Ihre Sitzung von X (falls Sie eine laufen haben) neu starten müssen, wenn Sie ein größeres Upgrade Ihres Systems durchführen. Sie müssen entscheiden, ob ein nur lesbares /usr zu Ihrem System passt. Vergleichen Sie auch diese discussion on debian-devel about read-only /usr.


4.11 Den Benutzerzugang absichern


4.11.1 Benutzerauthentifizierung: PAM

PAM (Pluggable Authentication Modules) erlaubt Systemadministratoren, auszuwählen, wie Anwendungen Benutzer authentifizieren. Beachten Sie, dass PAM nichts machen kann, solange die Anwendung nicht mit Unterstützung für PAM kompiliert wurde. Die meisten Anwendungen, die mit Debian geliefert werden, haben diese Unterstützung eingebaut. Vor Version 2.2 hatte Debian keine Unterstützung für PAM. Die derzeitige Standardkonfiguration für jeden Dienst, der PAM benutzt, ist es, UNIX-Authentifizierung zu emulieren (lesen Sie /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz, um mehr darüber zu erfahren, wie PAM-Dienste unter Debian arbeiten sollten).

Jede Anwendung mit PAM-Unterstützung stellt eine Konfigurationsdatei unter /etc/pam.d/ zur Verfügung, in welcher Sie ihr Verhalten einstellen können:

Die folgende Beschreibung ist weit davon entfernt, vollständig zu sein. Für weitere Informationen können Sie die Linux-PAM Guides lesen. Diese Dokumentation ist auf Ihrem System unter /usr/share/doc/libpam-doc/html/ verfügbar, wenn Sie libpam-doc installieren.

PAM offers you the possibility to go through several authentication steps at once, without the user's knowledge. You could authenticate against a Berkeley database and against the normal passwd file, and the user only logs in if the authentication succeeds in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. Generally it should be set to requisite, which returns a login failure if one module fails.


4.11.1.1 Passwortsicherheit in PAM

Sehen Sie sich /etc/pam.d/common-password an, die von /etc/pam.d/passwd eingebunden wird. [27] Andere Dateien in /etc/pam.d/ lesen diese Datei ein, um die Verwendung eines Passworts durch Programme, die einen Zugriff auf das System erlauben, wie etwa das Konsolen-Login (Login), grafische Login-Manager (z.B. Gdm oder Lightdm) und Login aus der Ferne (etwa mit Sshd), zu definieren.

Sie müssen sicherstellen, dass das Modul pam_unix.so die Option »sha512« verwendet, damit die Passwörter verschlüsselt werden. In Debian Squeeze ist dies standardmäßig eingerichtet.

Die Zeile mit der Konfiguration des Moduls pam_unix sollte etwa so aussehen:

       password   [success=1 default=ignore]      pam_unix.so nullok obscure minlen=8 sha512

Dieser Ausdruck

Sie müssen sicherstellen, dass in PAM-Anwendungen verschlüsselte Passwörter verwendet werden, weil dies Wörterbuchangriffe erschwert. Zugleich wird es dadurch möglich, Passwörter mit mehr als acht Zeichen einzusetzen.

Da mit diesem Modul auch definiert wird, wie Passwörter geändert werden, weil es von Chpasswd eingebunden wird, können Sie die Passwortsicherheit Ihres Systems erhöhen, indem sie libpam-cracklib installieren und folgenden Ausdruck in die Konfigurationsdatei /etc/pam.d/common-password eintragen:

       # Gehen Sie sicher, dass Sie libpam-cracklib zuerst installiert haben,
       # sonst werden Sie sich nicht einloggen können
       password   required     pam_cracklib.so retry=3 minlen=12 difok=3
       password   [success=1 default=ignore]      pam_unix.so obscure minlen=8 sha512 use_authok

So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum size [28] of 12 characters, and difference of at least 3 characters from the old password, and allows 3 retries. Cracklib depends on a wordlist package (such as wenglish, wspanish, wbritish, ...), so make sure you install one that is appropriate for your language or cracklib might not be useful to you at all.

Die zweite Zeile (mit dem Module pam_unix.so) ist – wie oben beschrieben – der Standard in Debian mit Ausnahme der Option use_authok. Diese Option ist notwendig, wenn pam_unix.so nach pam_cracklib.so aufgerufen wird, damit das Passwort vom zuerst aufgerufenen Modul weitergereicht wird. Anderenfalls muss der Benutzer sein Passwort zweimal eingegeben.

For more information about setting up Cracklib, read the pam_cracklib(8) manpage and the article Linux Password Security with pam_cracklib by Hal Pomeranz.

Mit dem PAM-Modul Cracklib richten Sie eine Richtlinie ein, welche die Verwendung guter Passwörter erzwingt.

Als Alternative können Sie auch PAM-Module einsetzen, die eine Zwei-Faktor-Authentifizierung verwenden, wie z.B. libpam-barada, libpam-google-authenticator, libpam-oath, libpam-otpw, libpam-poldi, libpam-usb oder libpam-yubico. Diese Module ermöglichen es, sich mit einer externen Authentifizierungsmethode am System anzumelden, etwa mit einer Chipkarte, einem USB-Stick oder Einmal-Passwörtern, die mit einer externen Anwendung, z.B. auf einem Mobiltelefon, erzeugt wurden.

Please note that these restrictions apply to all users but not to the password changes done by the root user. The root user will be able to set up any password (any length or complexity) for personal use or others regardless of the restrictions defined here.


4.11.1.2 Steuerung des Benutzerzugangs in PAM

Um sicher zu stellen, dass sich der Benutzer Root nur an lokalen Terminals anmelden kann, sollten Sie die folgende Zeile in /etc/pam.d/login einfügen:

       auth     requisite  pam_securetty.so

Danach sollten Sie die Liste der Terminals in /etc/securetty ändern, auf denen sich Root unmittelbar anmelden darf (wie in Einschränkung der Anmeldemöglichkeiten an der Konsole, Abschnitt 4.7 beschrieben). Alternativ dazu können Sie auch das pam_access-Modul aktivieren und /etc/security/access.conf bearbeiten. Dieses Vorgehen erlaubt eine allgemeinere und feiner abgestimmte Zugangssteuerung, leider fehlen aber vernünftige Protokollmeldungen (diese sind in PAM nicht standardisiert und sind ein besonders unbefriedigendes Problem). Wir werden zu access.conf in Kürze zurückkehren.


4.11.1.3 Höchstgrenzen für Benutzer in PAM

The following line should be enabled in /etc/pam.d/login to set up user resource limits.

       session  required   pam_limits.so

Dies schränkt die Systemressourcen ein, die ein Benutzer nutzen darf (siehe Ressourcen-Nutzung begrenzen: Die Datei limits.conf, Abschnitt 4.11.2 weiter unten). Sie können zum Beispiel die Anzahl der Logins, die man haben kann, einschränken (für eine Gruppe von Benutzern oder systemweit), die Anzahl der Prozesse, den belegten Speicher etc.


4.11.1.4 Steuerung von su in PAM

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 hinzu. Ergänzen Sie anschließend /etc/pam.d/su/ um die folgende Zeile:

       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.

If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow users 'ref' to log in via ssh. So you put them into /etc/sshusers-allowed and write the following into /etc/pam.d/ssh:

       auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

4.11.1.5 Temporäre Verzeichnisse in PAM

Da es eine Reihe von Sicherheitslücken mit so genannten unsicheren temporären Dateien zum Beispiel in Thttpd (vgl. DSA-883-1) gab, lohnt es sich, das Paket libpam-tmpdir zu installieren. Sie müssen dann lediglich Folgendes zu /etc/pam.d/common-session hinzuzufügen:

      session    optional     pam_tmpdir.so

Es gab auch eine Diskussion, dies standardmäßig in Debian einzufügen. Sehen Sie sich http://lists.debian.org/debian-devel/2005/11/msg00297.html für weitere Informationen an.


4.11.1.6 Konfiguration für nicht definierte PAM-Anwendungen

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 Standardkonfiguration dar (Zugriff wird standardmäßig verweigert).


4.11.2 Ressourcen-Nutzung begrenzen: Die Datei limits.conf

Sie sollten sich wirklich ernsthaft mit dieser Datei beschäftigen. Hier können Sie Ihren Benutzern Ressourcengrenzen vorgeben. In alten Veröffentlichungen war die Konfigurationsdatei /etc/limits.conf. Aber in neueren Versionen (mit PAM) sollte stattdessen die Konfigurationsdatei /etc/security/limits.conf benutzt werden.

Wenn Sie die Ressourcennutzung nicht einschränken, kann jeder Benutzer mit einer gültigen Shell auf Ihrem System (oder sogar ein Einbrecher, der das System durch einen Dienst kompromittierte, oder ein außer Kontrolle geratener Daemon) so viel CPU, Speicher, Stack etc. benutzen, wie das System zur Verfügung stellen kann. Dieses Problem der Überbeanspruchung von Ressourcen kann mit der Nutzung von PAM gelöst werden.

There is a way to add resource limits to some shells (for example, bash has ulimit, see bash(1)), but since not all of them provide the same limits and since the user can change shells (see chsh(1)) it is better to place the limits on the PAM modules as they will apply regardless of the shell used and will also apply to PAM modules that are not shell-oriented.

Ressourcengrenzen werden vom Kernel verhängt, aber sie müssen durch limits.conf konfiguriert werden und die PAM-Konfiguration der verschiedenen Dienste muss das passende PAM laden. Sie können herausfinden, welche Dienste Höchstgrenzen durchsetzen, indem Sie Folgendes ausführen:

     $ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"

Für gewöhnlich setzen Login, Ssh und die grafischen Sitzungsmanager (Gdm, Kdm und Xdm) Benutzerhöchstgrenzen durch, aber Sie sollte dies auch in anderen Konfigurationsdateien für PAM wie für Cron vornehmen, um zu verhindern, dass System-Daemons alle Systemressourcen aufbrauchen.

Die konkreten Begrenzungen, die Sie festlegen wollen, hängt von den Ressourcen Ihres Systems ab. Das ist einer der Hauptgründe, warum keine Höchstgrenzen in der Standardinstallation enthalten sind.

So setzt die Konfiguration im Beispiel unten eine Begrenzung von 100 Prozessen für alle Benutzer (um Fork-Bomben [29] zu vermeiden), eine Begrenzung auf 10 MB Speicher pro Prozess und ein Höchstgrenze von 10 gleichzeitigen Logins durch. Benutzer in der Gruppe adm haben höhere Begrenzungen und können Dateien mit einem Speicherabbild schreiben, wenn sie das wollen (es gibt also nur eine weiche Begrenzung).

     *              soft    core            0
     *              hard    core            0
     *              hard    rss             1000
     *              hard    memlock         1000
     *              hard    nproc           100
     *              -       maxlogins       1
     *              hard    data            102400
     *              hard    fsize           2048
     @adm           hard    core            100000
     @adm           hard    rss             100000
     @adm           soft    nproc           2000
     @adm           hard    nproc           3000
     @adm           hard    fsize           100000
     @adm           -       maxlogins       10

Dies könnten die Höchstgrenzen eines Standardbenutzers (einschließlich der System-Daemons) sein:

     $ ulimit -a
     core file size        (blocks, -c) 0
     data seg size         (kbytes, -d) 102400
     file size             (blocks, -f) 2048
     max locked memory     (kbytes, -l) 10000
     max memory size       (kbytes, -m) 10000
     open files                    (-n) 1024
     pipe size          (512 bytes, -p) 8
     stack size            (kbytes, -s) 8192
     cpu time             (seconds, -t) unlimited
     max user processes            (-u) 100
     virtual memory        (kbytes, -v) unlimited

Und dies die Höchstgrenzen für einen Administrator:

     $ ulimit -a
     core file size        (blocks, -c) 0
     data seg size         (kbytes, -d) 102400
     file size             (blocks, -f) 100000
     max locked memory     (kbytes, -l) 100000
     max memory size       (kbytes, -m) 100000
     open files                    (-n) 1024
     pipe size          (512 bytes, -p) 8
     stack size            (kbytes, -s) 8192
     cpu time             (seconds, -t) unlimited
     max user processes            (-u) 2000
     virtual memory        (kbytes, -v) unlimited

Lesen Sie für weitere Informationen:


4.11.3 Aktionen bei der Benutzeranmeldung: Bearbeiten von /etc/login.defs

Der nächste Schritt ist es, die grundlegende Konfiguration und die Aktionen bei der Benutzeranmeldung zu bearbeiten. Beachten Sie, dass diese Datei kein Bestandteil der PAM-Konfiguration ist. Sie ist eine Konfigurationsdatei, die von den Programmen Login und Su berücksichtigt wird. Es ist also wenig sinnvoll, sie auf Fälle abzustimmen, in denen keines der beiden Programme wenigstens indirekt aufgerufen wird (Das Programm Getty, welches auf der Konsole läuft und die anfängliche Anmeldeaufforderung zu Verfügung stellt, ruft Login auf).

       FAILLOG_ENAB        yes

Wenn Sie diese Variable einschalten, werden fehlgeschlagene Anmeldeversuche protokolliert. Es ist wichtig, hier auf dem Laufendem zu bleiben, um jemanden zu ermitteln, der einen Brute-Force-Angriff versucht.

       LOG_UNKFAIL_ENAB    no

Wenn Sie diese Variable auf »yes« setzen, werden unbekannte Benutzernamen protokolliert, wenn eine Anmeldung scheitert. Es ist zu empfehlen, sie auf »no« (den Standard) zu belassen, da anderenfalls das Passwort eines Benutzers aufgezeichnet werden könnte (falls er nämlich versehentlich anstatt seines Benutzernames sein Passwort eingibt). Falls Sie sie dennoch auf »yes« setzen, müssen Sie sicherstellen, dass die Protokolldateien angemessene Zugriffsrechte haben (zum Beispiel 640, mit einer passenden Gruppenzugehörigkeit wie adm).

       SYSLOG_SU_ENAB      yes

Dies schaltet das Mitprotokollieren von su-Versuchen im Syslog ein. Sehr wichtig auf ernsthaft betriebenen Maschinen, aber beachten Sie, dass dies auch die Privatsphäre verletzen kann.

       SYSLOG_SG_ENAB      yes

Das gleiche wie bei SYSLOG_SU_ENAB, aber für das Programm Sg.

       ENCRYPT_METHOD  SHA512

Wie bereits erklärt, reduziert eine Verschlüsselung von Passwörtern die Gefahr von Wörterbuchangriffen erheblich, da Sie längere Passwörter benutzen können. Diese Definition muss mit dem Wert in /etc/pam.d/common-password übereinstimmen.


4.11.4 Aktionen bei der Benutzeranmeldung: /etc/pam.d/login bearbeiten

Sie können die Datei zur Konfiguration des Anmeldevorgangs anpassen, um eine strengere Richtlinie festzuschreiben. Zum Beispiel können Sie die Wartezeit zwischen zwei Anmeldeversuchen im Vergleich zur Standardkonfiguration erhöhen. Diese Standardvorgabe setzt eine Wartezeit von drei Sekunden:

     auth       optional   pam_faildelay.so  delay=3000000

Wenn Sie den Wert von delay erhöhen, wird es schwieriger, sich durch bloßes Ausprobieren von Passwörtern (brute force) erfolgreich am Terminal anzumelden. Wenn ein falsches Passwort eingegeben wird, muss ein möglicher Angreifer (oder ein normaler Benutzer!) viele Sekunden warten, bis er wieder eine Eingabeaufforderung erhält, wodurch das Durchprobieren von Passwörtern sehr zeitaufwendig werden kann. So müssen etwa Benutzer bei delay=10000000 zehn Sekunden warten, wenn sie das falsche Passwort eingeben.

In dieser Datei können Sie auch einrichten, dass das System dem Benutzer vor einer Anmeldung eine Nachricht anzeigt. Standardmäßig ist dies deaktiviert, wie Sie hier sehen können:

     # auth       required   pam_issue.so issue=/etc/issue

Falls es Ihre Sicherheitsrichtlinie erfordert, können Sie mit dieser Datei eine Standardnachricht, dass der Zugang zum System beschränkt und der Benutzerzugang protokolliert wird, anzeigen lassen. Ein solcher Hinweis kann in bestimmten Regionen und nach der jeweiligen Rechtsprechung notwendig sein. Um dies zu aktivieren, müssen Sie nur die entsprechende Mitteilung in die Datei /etc/issue [30] eintragen und das Kommentarzeichen in der Zeile in /etc/pam.d/login entfernen, um das Modul pam_issue.so zu aktivieren. In dieser Datei können Sie weitere Einstellungen vornehmen, die für Ihre Sicherheit relevant sein könnten, wie zum Beispiel:


4.11.5 Ftp einschränken: bearbeiten von /etc/ftpusers

Die Datei /etc/ftpusers enthält eine Liste von allen Benutzern, denen es nicht erlaubt ist, sich auf dem Rechner mit Ftp einzuloggen. Benutzen Sie diese Datei nur, wenn Sie wirklich Ftp erlauben wollen (wozu im Allgemeinen nicht geraten wird, da es Klartext-Passwörter benutzt). Wenn Ihr Ftp-Daemon PAM unterstützt, können Sie dies ebenfalls benutzen, um Benutzern bestimmte Dienste zu erlauben oder zu verbieten.

FIXME (FEHLER): Ist es ein Fehler, dass ftpusers in Debian standardmäßig nicht die Benutzer mit Administratorenrecht (in base-passwd) beinhaltet?

Folgender Befehl ist ein bequemer Weg, alle Systemkonten zu /etc/ftpusers hinzuzufügen:

     $ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers

4.11.6 Verwendung von Su

Wenn es wirklich benötigt wird, dass Benutzer der Super-User (also Root, d.Ü.) auf Ihrem System werden, zum Beispiel um Pakete zu installieren oder neue Benutzer anzulegen, können Sie das Programm Su benutzen, um Ihre Identität zu wechseln. Sie sollten jeden Login als Benutzer Root vermeiden und stattdessen das Programm Su benutzen. Eigentlich ist die beste Lösung, Su zu entfernen und zu Sudo zu wechseln, da es eine feinere Steuerung und mehr Möglichkeiten bietet als Su. Wie auch immer, Su ist verbreiteter und wird auf vielen Unices eingesetzt.


4.11.7 Verwendung von Sudo

sudo allows the user to execute defined commands under another user's identity, even as root. If the user is added to /etc/sudoers and authenticates correctly, the commands defined in /etc/sudoers get enabled. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root.


4.11.8 Administrativen Fernzugriff verweigern

Sie sollten /etc/security/access.conf ebenfalls so verändern, dass ein Login aus der Ferne in ein administratives Konto nicht erlaubt wird. Auf diese Weise müssen Benutzer das Programm Su (oder Sudo) aufrufen, um Administratorenrechte zu bekommen, so dass es immer eine nachprüfbare Spur gibt.

Sie müssen die folgende Zeile zu Ihrer /etc/security/access.conf hinzufügen, in Debians Standardkonfigurationsdatei ist ein Beispiel auskommentiert:

        -:wheel:ALL EXCEPT LOCAL

Vergessen Sie nicht, in /etc/pam.d/ das pam_access-Module für jeden Dienst (oder die Standardkonfiguration) anzuschalten, wenn Sie wollen, dass Ihre Änderungen an /etc/security/access.conf berücksichtigt werden.


4.11.9 Den Benutzerzugang einschränken

Manchmal werden Sie denken, dass Sie einen Benutzer auf Ihrem System erstellen müssen, um einen bestimmten Dienst (Pop3-E-Mail-Server oder Ftp) anzubieten. Bevor Sie dies tun, denken Sie zuerst daran, dass die PAM-Implementierung in Debian GNU/Linux Ihnen erlaubt, Benutzer mit einer breiten Auswahl von externen Verzeichnisdiensten (Radius, LDAP etc.) zu überprüfen. Dies wird vom Paket libpam bewerkstelligt.

If users need to be created and the system can be accessed remotely take into account that users will be able to log in to the system. You can fix this by giving users a null (/dev/null) shell (it would need to be listed in /etc/shells). If you want to allow users to access the system but limit their movements, you can use the /bin/rbash, equivalent to adding the -r option in bash (RESTRICTED SHELL see bash(1)). Please note that even with restricted shell, a user that access an interactive program (that might allow execution of a subshell) could be able to bypass the limits of the shell.

Debian bietet zurzeit in seiner Unstable-Veröffentlichung (und wird es vielleicht der nächsten Stable-Veröffentlichung hinzufügen) das Modul pam_chroot (in libpam-chroot) an. Eine Alternative hierzu ist es, die Dienste, die eine Fernanmeldung ermöglichen (Ssh und Telnet), in einer Chroot-Umgebung laufen zu lassen. [31]

Wenn Sie einschränken wollen, wann ein Benutzer auf das System zugreifen kann, müssen Sie /etc/security/access.conf an Ihre Bedürfnisse anpassen.

Informationen, wie man Benutzer, die auf das System mittels des Dienstes Ssh zugreifen, in eine Chroot-Umgebung einsperrt, wird in Chroot-Umgebung für SSH, Anhang G beschrieben.


4.11.10 Überprüfen der Benutzer

Wenn Sie wirklich paranoid sind, sollten Sie eine systemweite Einrichtung verwenden, um zu überwachen, was die Benutzer auf Ihrem System tun. In diesem Abschnitt werden einige Tipps vorgestellt, wie Sie verschiedene Werkzeuge verwenden.


4.11.10.1 Überwachung von Ein- und Ausgabe mittels eines Skripts

Um sowohl die von den Benutzern ausgeführten Programme als auch deren Ergebnisse zu überwachen, können Sie den Befehl script verwenden. Sie können script nicht als eine Shell einsetzen (auch dann nicht, wenn Sie es zu /etc/shells hinzufügen). Aber Sie können in die Datei, welche den Startvorgang der Shell steuert, folgendes eintragen:

     umask 077
     exec script -q -a "/var/log/sessions/$USER"

Wenn Sie dies systemweit vornehmen, bedeutet dies natürlich, dass die Shell die weiteren persönlichen Startdateien nicht abarbeitet (weil die Shell von script überschrieben wird). Eine Alternative ist, dies in den Startdateien des Benutzers vorzunehmen (dann kann der Benutzer aber dies entfernen, vgl. dazu die Anmerkungen unten).

Sie müssen auch die Dateien im Überwachungsverzeichnis (im Beispiel /var/log/sessions/) so einrichten, dass die Benutzer in sie schreiben, sie aber nicht löschen können. Dies kann zum Beispiel bewerkstelligt werden, indem die Sitzungsdateien der Benutzer vorab erstellt und mit chattr auf append-only (nur anfügen) gesetzt werden.

Eine sinnvolle Alternative für Systemadministratoren, die auch Zeitinformationen enthält, ist:

     umask 077
     exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.11.10.2 Die Chronikdatei der Shell benutzen

Wenn Sie auswerten wollen, was die Benutzer in die Shell eingeben (aber nicht was das Ergebnis ist), können Sie eine systemweite /etc/profile so einrichten, dass alle Befehle in einer Chronikdatei gespeichert werden. Die systemweite Einstellung muss so eingerichtet werden, dass Benutzer die Überwachungsfähigkeit nicht aus ihrer Shell entfernen können. Ob dies möglich ist, hängt von der Art der Shell ab. Sie müssen also sicherstellen, dass alle Benutzer eine Shell verwenden, die das unterstützt.

Für die Bash zum Beispiel könnte /etc/profile folgendermaßen aufgebaut werden [32]:

       HISTFILE=~/.bash_history
       HISTSIZE=10000
       HISTFILESIZE=999999
       # Verhindert, dass Benutzer Befehle eintragen,
       # die in die Verlaufsdatei ignoriert werden
       HISTIGNORE=""
       HISTCONTROL=""
       readonly HISTFILE
       readonly HISTSIZE
       readonly HISTFILESIZE
       readonly HISTIGNORE
       readonly HISTCONTROL
       export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL

Damit dies funktioniert, dürfen die Benutzer nur Informationen zur .bash_history-Datei hinzufügen. Sie müssen daher zusätzlich die Option append-only (nur anfügen) mittels des Programms Chattr für die .bash_history aller Benutzer setzen [33].

Note that you could introduce the configuration above in the user's .profile. But then you would need to setup permissions properly in such a way that prevents the user from modifying this file. This includes: having the user's home directories not belong to the user (since the user would be able to remove the file otherwise) but at the same time allow the user to read the .profile configuration file and write on the .bash_history. It would be good to set the immutable flag (also using chattr) for .profile too if you do it this way.


4.11.10.3 Vervollständigung der Benutzerüberwachung durch Accounting-Werkzeuge

Die vorherigen Beispiele stellen eine einfache Art dar, um die Überwachung von Benutzern einzurichten. Sie eignen sich aber nicht unbedingt für komplexe Systeme oder für solche, auf denen die Benutzer überhaupt keine (oder ausschließlich) Shells am Laufen haben. Sollte dies der Fall sein, schauen Sie sich das Paket acct an, das Werkzeuge zur Auswertung (accounting utilities) enthält. Diese werden alle Befehle, die ein Benutzer oder ein Prozess auf dem System ausführt, – auf die Kosten von Plattenplatz – aufzeichnen.

Wenn Sie diese Auswertung aktivieren, werden alle Informationen über Prozesse und Benutzer unter /var/account/ gespeichert, genauer gesagt in pacct. Das Accounting-Paket enthält einige Werkzeuge (Sa, Ac und Lastcomm) zur Analyse dieser Daten.


4.11.10.4 Andere Methoden zur Benutzerüberwachung

Wenn Sie wirklich paranoid sind und jeden Befehl jedes Benutzers protokollieren wollen, können Sie den Quellcode der Bash so ändern, dass sie alles, was der Benutzer eingibt, in einer anderen Datei ablegt. Oder Sie lassen Ttysnoop ununterbrochen jedes neue tty[34] überwachen und die Ausgaben in einer Datei speichern. Ein anderes nützliches Programm ist snoopy (vergleichen Sie auch the project page). Dies ist ein für den Benutzer transparentes Programm, das sich als eine Bibliothek einhängt und eine Hülle um execve()-Aufrufe bildet. Jeder ausgeführte Befehl wird im syslogd aufgezeichnet, indem die authpriv-Möglichkeit benutzt wird (üblicherweise wird dies unter /var/log/auth.log gespeichert).


4.11.11 Nachprüfung der Benutzerprofile

Wenn Sie sehen wollen, was Benutzer tatsächlich tun, wenn sie sich am System anmelden, können Sie die wtmp-Datenbank benutzen, die alle Anmeldeinformationen enthält. Diese Datei kann mit verschiedenen Werkzeugen weiterverarbeitet werden, unter ihnen Sac, das ein Profil für jeden Benutzer ausgeben kann und zeigt, in welchem Zeitfenster sie sich für gewöhnlich auf dem System anmelden.

Für den Fall, dass Sie Accounting aktiviert haben, können Sie auch die mitgelieferten Werkzeuge verwenden, um festzustellen, wann Benutzer auf das System zugreifen und was sie ausführen.


4.11.12 Umasks der Benutzer einstellen

Abhängig von Ihren Benutzerrichtlinien möchten Sie ändern, wie Benutzer Informationen gemeinsam benutzen können. Dabei geht es um die Standardrechte von neu erstellten Dateien.

Das Standardwert von Umask ist in Debian 022. Das bedeutet, dass die Gruppe des Benutzers und alle anderen Benutzers auf dem System die Dateien (und Verzeichnisse) lesen und darauf zugreifen kann. Dieser Wert wird in der Standardkonfigurationsdatei /etc/profile gesetzt, die von allen Shells verwendet wird.

If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). Debian (by default[35]) creates one group per user so that only the user is included in its group. Consequently 027 and 077 are equivalent as the user's group contains only the user.

Dies ändern Sie, indem Sie eine passende Umask für alle Benutzer einstellen. Dazu müssen Sie einen umask-Aufruf in den Konfigurationsdateien aller Shells einfügen: /etc/profile (wird von allen Shells beachtet, die kompatibel mit Bourne sind), /etc/csh.cshrc, /etc/csh.login, /etc/zshrc und wahrscheinlich noch ein paar andere (je nachdem, welche Shells Sie auf Ihrem System installiert haben). Sie können auch die UMASK-Einstellung in /etc/login.defs verändern. Von all diesen Dateien erlangt die letzte, die von der Shell geladen wird, Vorrang. Die Reihenfolge lautet: die Standard-Systemkonfiguration für die Shell des Benutzers (d.h. /etc/profile und andere systemweite Konfigurationsdateien), dann die Shell des Benutzers (seine ~/.profile) und ~/.bash_profile etc.). Allerdings können einige Shells mit dem nologin-Wert ausgeführt werden, was verhindern kann, dass einige dieser Dateien ausgewertet werden. Sehen Sie in der Handbuchseite Ihrer Shell für weitere Informationen nach.

Bei Anmeldungen, die von Login Gebrauch machen, erhält die UMASK-Festlegung in /etc/login.defs Vorrang vor allen anderen Einstellungen. Dieser Wert wird aber nicht von Anwendungen des Benutzers beachtet, die nicht Login verwenden, wie z.B. solche, die durch Su, Cron oder Ssh ausgeführt werden.

Vergessen Sie nicht, die Dateien unter /etc/skel/ zu überprüfen und gegebenenfalls anzupassen, da dort die Standards für Benutzer festgelegt werden, die mit dem Befehl adduser erstellt werden. Standardmäßig enthalten die Dateien in Debian keinen Aufruf von umask. Wenn sich aber ein solcher in Konfigurationsdateien befindet, sind neue Benutzer eher geneigt, ihn ihren Bedürfnissen anzupassen.

Beachten Sie allerdings, dass ein Benutzer seine Umask-Einstellung ändern kann, wenn er es möchte, um sie großzügiger oder einschränkender zu machen, indem er seine Konfigurationsdateien verändert.

Das Paket libpam-umask passt die Standard-Umask eines Benutzers mit Hilfe von PAM an. Nachdem Sie das Paket installiert haben, tragen Sie Folgendes in /etc/pam.d/common-session ein:

     session    optional     pam_umask.so umask=077

Zu guter Letzt sollte Sie in Betracht ziehen, die Standard-Umask von Root (022, wird in /root/.bashrc festgelegt) auf einen strengeren Wert zu verändern. Damit kann verhindert werden, dass der Systemadministrator als Root sensible Dateien in von allen lesbaren Verzeichnissen (wie z.B. /tmp) ablegt und sie so dem Durchschnittsbenutzer zugänglich macht.


4.11.13 Beschränken, was Benutzer sehen und worauf sie zugreifen können

FIXME: Inhalt benötigt. Aufzeigen der Folgen beim Upgraden, wenn die Paketrechte verändert werden, falls nicht dpkg-statoverride verwendet wird (übrigens sollte ein derartig paranoider Administrator seine Benutzer in eine Chroot-Umgebung einsperren).

Wenn Sie einem Benutzer Zugriff auf das System mit einer Shell gewähren müssen, sollten Sie vorsichtig sein. Ein Benutzer kann normalerweise, wenn er sich nicht in einer streng abgeschirmten Umgebung befindet (z.B. in einem Chroot-Gefängnis), ziemlich viel Informationen über Ihr System sammeln. Darunter fallen:

Was kann ein Benutzer 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

The output is the list of files that a user can see and the accessable directories.


4.11.13.1 Begrenzung des Zugangs zu Informationen anderer Benutzer

Wenn Sie immer noch Benutzern einen Shellzugang zur Verfügung stellen wollen, sollten Sie die Informationen begrenzen, die man über anderen Benutzern einholen kann. Benutzer mit einer Shell haben die Neigung, eine ziemlich große Anzahl von Dateien in ihrem $HOME zu erstellen: Mailboxen, persönliche Daten, Konfigurationen für X/GNOME/KDE-Anwendungen ...

Unter Debian wird jeder Benutzer mit einer zugehörigen Gruppe erstellt. Verschiedene Benutzer gehören dabei nie zur selben Gruppe. Folgendes ist das Standardverhalten: Wenn ein Benutzerkonto angelegt wird, wird auch eine Gruppe mit dem gleichen Namen erstellt. Dieser Gruppe wird der Benutzer zugewiesen. Damit wird die Idee einer allgemeinen users-Gruppe überflüssig, die es Benutzern erschweren könnte, Informationen vor anderen Benutzern zu verstecken.

Allerdings wird das $HOME-Verzeichnis der Benutzer mit 0755-Rechten (lesbar von der Gruppe, lesbar von der Welt) erstellt. Die Rechte für die Gruppe sind kein Thema, da nur der Benutzer zu dieser Gruppe gehört. Allerdings könnten die Rechte für die Welt ein Problem darstellen, wobei dies von Ihren lokalen Richtlinien abhängt.

Sie können dieses Verhalten so abändern, dass das Erstellen eines Benutzers andere Rechte für $HOME liefert. Um dieses Verhalten für neue Benutzer zu ändern, wenn sie erstellt werden, ändern Sie in der Konfigurationsdatei /etc/adduser.conf DIR_MODE auf 0750 (nicht lesbar für die Welt) ab.

Benutzer können immer noch Informationen austauschen, aber nicht mehr unmittelbar in ihrem $HOME-Verzeichnis, es sei denn, dass sie dessen Recht verändert haben.

Wenn Sie den Lesezugriff auf die Home-Verzeichnisse für die Welt verhindert, sollten Sie beachten, dass dann Benutzer ihre persönlichen Webseiten nicht unter ~/public_html erstellen können, da der Webserver einen Teil des Pfads nicht lesen kann – und zwar das $HOME-Verzeichnis. Wenn Sie es Benutzern erlauben wollen, ihre HTML-Seiten in ihrem ~/public_html zu veröffentlichen, sollten Sie DIR_MODE auf 0751 setzen. Das ermöglicht dem Webserver Zugriff auf das eigentliche public_html-Verzeichnis (welches selbst die Rechte 0755 haben sollte). So kann er den von den Benutzern veröffentlichten Inhalt anbieten. Natürlich sprechen wir hier nur über die Standardeinstellung. Benutzer können grundsätzlich die Rechte für ihre eigenen Dateien nach ihrem Gutdünken vergeben. Oder Sie können die Dinge, die für das Web bestimmt sind, in einem getrennten Ort ablegen, der kein Unterverzeichnis vom $HOME-Verzeichnis des Benutzers ist.


4.11.14 Erstellen von Benutzerpasswörtern

In vielen Fällen muss ein Administrator viele Benutzerkonten erstellen und alle mit Passwörtern ausstatten. Der Administrator könnte natürlich einfach als Passwort den Namen des Benutzerkontos vergeben. Dies wäre aber unter Sicherheitsgesichtspunkten nicht sehr klug. Ein besseres Vorgehen ist es, ein Programm zur Erzeugung von Passwörtern zu verwenden. Debian stellt die Pakete makepasswd, apg und pwgen zur Verfügung, die Programme liefern (deren Name ist der gleiche wie der des Pakets), die zu diesem Zweck verwendet werden können. Makepasswd erzeugt wirklich zufällige Passwörter, gibt also der Sicherheit gegenüber der Aussprechbarkeit den Vorzug. Dagegen versucht pwgen, bedeutungslose, aber aussprechbare Passwörter herzustellen (dies hängt natürlich auch von Ihrer Muttersprache ab). Apg liefert Algorithmen für beide Möglichkeiten (Es gibt auch eine Client/Server-Version dieses Programms. Diese befindet sich aber nicht im Debian-Paket).

Passwd erlaubt nur die interaktive Zuweisung von Passwörtern (da es direkt den tty-Zugang benutzt). Wenn Sie Passwörter ändern wollen, wenn Sie eine große Anzahl von Benutzern erstellen, können Sie diese unter der Verwendung von adduser mit der --disabled-login-Option erstellen, und danach usermod oder chpasswd [36] benutzen (beide Programme stammen aus dem passwd-Paket. Sie haben sie also schon installiert). Wenn Sie lieber eine Datei verwenden, die alle Informationen zur Erstellung von Benutzern als Batch-Prozess enthält, sind Sie vielleicht mit newusers besser dran.


4.11.15 Überprüfung der Benutzerpasswörter

Die Passwörter der Benutzer sind manchmal die schwächste Stelle der Sicherheit eines Systems. Das liegt daran, dass manche Benutzer schwache Passwörter für ihr Konto wählen (und je mehr Benutzer Zugang zum System haben, umso größer die Chance, dass das passiert). Selbst wenn Sie Überprüfungen mit dem PAM-Module cracklib und Grenzen für Passwörter einsetzen, wie in Benutzerauthentifizierung: PAM, Abschnitt 4.11.1 beschrieben wird, ist es Benutzern immer noch möglich, schwache Passwörter zu verwenden. Da der Zugang der Benutzer auch den Zugang aus der Ferne (hoffentlich über Ssh) umfassen kann, ist es wichtig, dass das Erraten von Passwörtern für Angreifer aus der Ferne so schwierig wie möglich ist. Dies gilt insbesondere dann, wenn es ihnen gelungen sein sollte, Zugriff auf wichtigen Informationen wie den Benutzernamen oder sogar den Dateien passwd und shadow selbst zu bekommen.

A system administrator must, given a big number of users, check if the passwords they have are consistent with the local security policy. How to check? Try to crack them as an attacker would if having access to the hashed passwords (the /etc/shadow file).

Ein Administrator kann john oder crack (beide benutzen Brute-Force (rohe Gewalt) zum Knacken von Passwörtern) zusammen mit einer passenden Wörterliste verwenden, um die Passwörter der Benutzer zu überprüfen, und falls ein schlechtes Passwort entdeckt wird, geeignete Schritte unternehmen. Sie können mit apt-cache search wordlist nach Debian/GNU-Paketen suchen, die Wörterlisten enthalten, oder Sie besuchen die klassischen Internetseiten mit Wörterlisten wie ftp://ftp.ox.ac.uk/pub/wordlists oder ftp://ftp.cerias.purdue.edu/pub/dict.


4.11.16 Abmelden von untätigen Benutzern

Untätige (idle) Benutzer stellen für gewöhnlich ein Sicherheitsproblem dar. Ein Benutzer kann untätig sein, da er Mittagessen ist, oder weil eine Verbindung aus der Ferne hängen blieb und nicht wieder hergestellt wurde. Unabhängig von den Gründen können untätige Benutzer zu einer Kompromittierung führen:

In einige Systeme in der Ferne wurde sogar schon durch ein untätiges (und abgelöstes) Screen eingedrungen.

Die automatische Trennung von untätigen Benutzern ist gewöhnlich ein Teil der lokalen Sicherheitsrichtlinie, die durchgesetzt werden muss. Es gibt mehrere Arten, dies zu erreichen:

Vorzugswürdige Methoden sind die Daemonen Timeoutd oder Autolog, da letzten Endes die Benutzer ihre Standardshell ändern können oder zu einer anderen (unbeschränkten) Shell wechseln können, nachdem sie ihre Standardshell gestartet haben.


4.12 Die Nutzung von Tcpwrappers STOPP

TCP wrappers were developed when there were no real packet filters available and access control was needed. Nevertheless, they're still very interesting and useful. The TCP wrappers allow you to allow or deny a service for a host or a domain and define a default allow or deny rule (all performed on the application level). If you want more information take a look at hosts_access(5).

Viele der unter Debian installierten Dienste

Einerseits werden Sie bei manchen Diensten (einschließlich telnet, ftp, netbios, swat und finger), die in /etc/inetd.conf konfiguriert werden, sehen, dass die Konfigurationsdatei zuerst /usr/sbin/tcpd aufruft. Andererseits, selbst wenn ein Dienst nicht über den inetd-Superdaemon ausgeführt wird, kann die Unterstützung von TCP-Wrapper einkompiliert werden. Dienste, die unter Debian mit TCP-Wrappern kompiliert wurden, sind ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf (der GNOME-Aktivierungs-Daemon), nessus und viele andere.

Um herauszufinden, welche Pakete TCP-Wrapper benutzen[37], geben Sie Folgendes ein:

       $ apt-cache rdepends libwrap0

Beachten Sie bitte Folgendes, wenn Sie tcpchk (ein sehr nützliches Programm zur Überprüfung der TCP-Wrapper-Konfiguration und -Syntax) laufen lassen. Wenn Sie Stand-Alone-Dienste (alleinstehende Dienste, also solche, die direkt mit der Wrapper-Bibliothek verbunden sind) der host.deny- oder host.allow-Datei hinzufügen, wird tcpchk Sie warnen, dass er sie nicht finden kann, da er sie nur in /etc/inetd.conf sucht (die Handbuchseite ist an dieser Stelle nicht sehr genau).

Jetzt kommt ein kleiner Trick und vielleicht die kleinste Alarmanlage zur Erkennung von Eindringlingen: Im Allgemeinen sollten Sie eine anständige Firewall als erste und TCP-Wrapper als zweite Verteidigungslinie haben. Der Trick besteht nun darin, ein SPAWN-Kommando [38] in /etc/hosts.deny einzutragen, das immer dann eine Mail an Root schickt, wenn ein Dienst abgewiesen wurde:

       ALL: ALL: SPAWN ( \
         echo -e "\n\
         TCP Wrappers\: Verbindungsaufbau abgelehnt\n\
         Von\: $(uname -n)\n\
         Prozess\: %d (pid %p)\n\
         Benutzer\: %u\n\
         Host\: %c\n\
         Datum\: $(date)\n\
       " | /usr/bin/mail -s "Verbindung zu %d blockiert" root) &

Achtung: Das obige Beispiel kann sehr leicht zu DoS (Denial of Service, Verbindungsaufbau abgelehnt) führen, indem man versucht, sehr viele Verbindungen in kurzer Zeit aufzubauen. Viele E-Mails bedeuten viel Dateiaktivität, die lediglich durch das Senden von ein paar Paketen erreicht wird.


4.13 Die Wichtigkeit von Protokollen und Alarmen

Es ist leicht einzusehen, dass die Behandlung von Protokollen und Alarmen eine wichtige Angelegenheit in einem sicheren System ist. Stellen Sie sich vor, ein System ist perfekt konfiguriert und zu 99% sicher. Wenn ein Angriff unter dieses 1% fällt, und es keine Sicherheitsmaßnahmen gibt, dies erstens zu erkennen und zweitens einen Alarm auszulösen, so ist das System überhaupt nicht sicher.

Debian GNU/Linux stellt Werkzeuge zur Verfügung, die die Analyse von Protokolldateien übernehmen. Am beachtenswertesten sind swatch [39], logcheck oder loganalysis (alle Pakete werden ein wenig Anpassung benötigen, um unnötige Dinge aus den Berichten zu entfernen). Wenn sich das System in Ihrer Nähe befindet, könnte es nützlich sein, das System-Protokoll auf einer virtuellen Konsole auszugeben. Die ist nützlich, da Sie so (auch von weiter weg oder im Vorbeigehen) sehen können, ob sich das System richtig verhält. Debians /etc/syslog.conf wird mit einer auskommentierten Standardkonfiguration ausgeliefert. Um diese Ausgabe einzuschalten, entfernen Sie die Kommentarzeichen vor den entsprechenden Zeilen und starten syslog neu (/etc/init.d/syslogd restart):

       daemon,mail.*;\
             news.=crit;news.=err;news.=notice;\
             *.=debug;*.=info;\
             *.=notice;*.=warn       /dev/tty8

Um die Protokolle farbig zu gestalten, sollten Sie einen Blick auf colorize, ccze oder glark werfen. Es gibt noch eine Menge über die Analyse von Protokollen zu sagen, das hier nicht behandelt werden kann. Eine gute Quelle für weitere Informationen sind Bücher wie Security log management: identifying patterns in the chaos. In jedem Fall sind selbst automatische Werkzeuge dem besten Analysewerkzeug nicht gewachsen: Ihrem Gehirn.


4.13.1 Nutzung und Anpassung von logcheck

Das Paket logcheck ist in Debian auf drei Pakete verteilt: logcheck (das Hauptprogramm), logcheck-database (eine Datenbank regulärer Ausdrücke für das Programm) und logtail (gibt Protokollzeilen aus, die noch nicht gelesen wurden). Der Standard unter Debian (in /etc/cron.d/logcheck) ist, dass logcheck jede Stunde und nach jedem Neustart ausgeführt wird.

Wenn dieses Werkzeug in geeigneter Weise angepasst wurde, kann es sehr nützlich sein, um den Administrator zu alarmieren, wenn etwas ungewöhnliches auf dem System passiert. Logcheck kann vollständig angepasst werden, so dass es Mails über Ereignisse aus den Protokollen sendet, die Ihrer Aufmerksamkeit bedürfen. Die Standard-Installation umfasst Profile zum Ignorieren von Ereignissen und Verstößen gegen die Sicherheitsrichtlinie für drei unterschiedliche Einsatzbereiche (Workstation, Server und paranoid). Das Debian-Paket umfasst die Konfigurationsdatei /etc/logcheck/logcheck.conf, die vom Programm eingelesen wird, und die definiert, an welchen Benutzer die Testergebnisse geschickt werden sollen. Es stellt außerdem einen Weg für Pakete zur Verfügung, um neue Regeln in folgenden Verzeichnisses zu erstellen: /etc/logcheck/cracking.d/_packagename_ /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_, und /etc/logcheck/ignore.d.workstation/_packagename_. Leider benutzen das noch nicht viele Pakete. Wenn Sie ein Regelwerk entwickelt haben, dass für andere Benutzer nützlich sein könnte, schicken Sie bitte einen Fehlerbericht für das entsprechende Paket (als ein wishlist-Fehler). Mehr Informationen finden Sie unter /usr/share/doc/logcheck/README.Debian.

logcheck konfiguriert man am besten, indem man nach der Installation die Hauptkonfigurationsdatei /etc/logcheck/logcheck.conf bearbeitet. Verändern Sie den Benutzer, an den die Berichte geschickt werden (standardmäßig ist das Root). Außerdem sollten Sie auch den Schwellenwert für Berichte festlegen. logcheck-database hat drei Schwellenwerte mit steigender Ausführlichkeit: Workstation (Arbeitsplatz), Server und paranoid. »server« ist der Standardwert, »paranoid« wird nur für Hochsicherheitsmaschinen empfohlen, auf denen so wenig Dienste wie möglich laufen. »workstation« eignet sich für relativ geschützte, nicht kritische Maschinen. Wenn Sie neue Protokoll-Dateien hinzufügen wollen, müssen Sie diese nur zu /etc/logcheck/logcheck.logfiles hinzufügen. Es ist für die standardmäßige Syslog-Installation eingerichtet.

Once this is done you might want to check the mails that are sent, for the first few days/weeks/months. If you find you are sent messages you do not wish to receive, just add the regular expressions (see regex(7) and egrep(1)) that correspond to these messages to the /etc/logcheck/ignore.d.reportlevel/local. Try to match the whole logline. Details on howto write rules are explained in /usr/share/doc/logcheck-database/README.logcheck-database.gz. It's an ongoing tuning process; once the messages that are sent are always relevant you can consider the tuning finished. Note that if logcheck does not find anything relevant in your system it will not mail you even if it does run (so you might get a mail only once a week, if you are lucky).


4.13.2 Konfiguration, wohin Alarmmeldungen geschickt werden

Debian wird mit einer Standardkonfiguration für Syslog (in /etc/syslog.conf) ausgeliefert, so dass Meldungen je nach System in die passenden Dateien geschrieben werden. Das sollte Ihnen bereits bekannt sein. Falls nicht, werfen Sie einen Blick auf die Datei syslog.conf und deren Dokumentation. Wenn Sie ein sicheres System betreuen wollen, sollte Ihnen bekannt sein, wohin Protokoll-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 wichtig, eine neue Maschine zu haben, die für die anderen als ein Loghost fungiert (d.h. sie empfängt die Protokolle aller anderen Systeme).

Sie sollten auch an Mails für Root denken, da viele Programme zur Sicherheitskontrolle (wie snort) ihre Alarme an die Mailbox von Root senden. Diese Mailbox zeigt normalerweise auf den ersten Benutzer, der auf dem System erstellt wurde (prüfen Sie dazu /etc/aliases). Sorgen Sie dafür, dass Roots Mails irgendwo hin geschickt werden, wo sie auch gelesen werden (lokal oder in der Ferne).

Es gibt noch andere Konten mit besonderen Funktionen und andere Aliase auf Ihrem System. Auf einem kleinen System ist es wohl am einfachsten, sicherzustellen, dass alle Aliase auf das Root-Konto verweisen, und dass Mails an Root in das persönliche Postfach des Systemadministrators weiter geleitet werden.

FIXME: It would be interesting to tell how a Debian system can send/receive SNMP traps related to security problems (jfs). Check: snmptrapfmt, snmp and snmpd.


4.13.3 Nutzen eines Loghosts

A loghost is a host which collects syslog data remotely over the network. If one of your machines is cracked, the intruder is not able to cover the tracks, unless hacking the loghost as well. So, the loghost should be especially secure. Making a machine a loghost is simple. Just start the syslogd with syslogd -r and a new loghost is born. In order to do this permanently in Debian, edit /etc/default/syslogd and change the line

     SYSLOGD=""

in

     SYSLOGD="-r"

Als nächstes konfigurieren Sie die anderen Maschinen, so dass sie 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 in der Ferne mitprotokollieren wollen, schreiben Sie einfach:

       *.*                       @Ihr_Loghost

into your syslog.conf. Logging remotely as well as locally is the best solution (the attacker might presume to have covered his tracks after deleting the local log files). See the syslog(3), syslogd(8) and syslog.conf(5) manpages for additional information.


4.13.4 Zugriffsrechte auf Protokolldateien

It is not only important to decide how alerts are used, but also who has read/modify access to the log files (if not using a remote loghost). Security alerts which the attacker can change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder who has access to them.

Einige Zugriffsrechte auf Protokolldateien sind nach der Installation nicht gerade perfekt (aber das hängt natürlich von Ihrer lokalen Sicherheitsrichtlinie ab). Zuerst einmal müssen /var/log/lastlog und /var/log/faillog nicht für normale Benutzer lesbar sein. In der Datei lastlog können Sie sehen, wer sich zuletzt angemeldet hat. In faillog befindet sich eine Zusammenfassung fehlgeschlagener Anmeldeversuche. Der Autor empfiehlt, die Rechte von beiden auf 660 zu setzen (mit chmod 660). Werfen Sie einen kurzen Blick auf Ihre Protokolldateien und entscheiden Sie sehr vorsichtig, welche Protokolldateien Sie les- oder schreibbar für einen Benutzer 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
       (überprüfen, welchen Benutzern die Dateien unter /var/log gehören)
       #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
       (überprüfen, welchen Gruppen die Dateien unter /var/log gehören)
       # find /var/log -perm +004
       (Dateien, die von jedem Benutzer gelesen werden können)
       #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
       (Dateien, die nicht der Gruppe root oder adm gehören)

Um anzupassen, wie neue Protokolldateien erstellt werden, müssen Sie wahrscheinlich das Programm anpassen, das sie erstellt. Wenn die Protokolldateien ausgewechselt werden, können Sie das Verhalten der Erstellung und Auswechslung anpassen.


4.14 Den Kernel patchen

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

Die folgenden Sicherheitspatches für den Kernel sind nur noch für alte Kernelversionen in Woody verfügbar und werden nicht mehr weiterentwickelt:

Wie auch immer, einige Patches werden von Debian noch nicht zur Verfügung gestellt. Wenn Sie denken, dass manche von ihnen hinzugefügt werden sollten, fragen Sie danach auf Arbeit-bedürfende und voraussichtliche Pakete.


4.15 Schutz vor Pufferüberläufen

Pufferüberlauf (buffer overflow) wird eine verbreitete Art von Angriffen auf Software [41] genannt, welche die unzureichende Überprüfung von Eingabegrenzen ausnutzen (ein Programmierfehler, der häufig bei der Programmiersprache C auftritt), um durch Programmeingaben Befehle auf der Maschine auszuführen. Diese Attacken über Server, die auf Verbindungen warten, oder über lokal installierte Software, die einem Benutzer größere Privilegien gewährt (setuid oder setgid) kann zu einem kompromittierten System führen.

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

Debian GNU/Linux liefert bis einschließlich der Veröffentlichung 3.0 Software, um alle diese Methoden bis auf den Schutz bei der Übersetzung des Quellcodes (das wurde aber schon in Fehler #213994 nachgefragt) zu implementieren.

Beachten Sie, dass selbst wenn Debian einen Compiler zur Verfügung stellen würde, der Schutz vor Stapel- und Pufferüberläufen bieten würde, so doch alle Pakete neu übersetzt werden müssten, um diese Eigenschaft einzuführen. Tatsächlich ist das die Aufgabe der Distribution Adamantix (unter anderen Fähigkeiten). Die Auswirkungen dieses neuen Features auf die Stabilität der Software muss aber noch ermittelt werden (einige Programme und einige Prozessoren werden vielleicht deswegen nicht mehr funktionieren).

Seien Sie auf jeden Fall gewarnt, dass selbst diese Umgehungen des Problems nicht vor Pufferüberläufen schützen können, da es Möglichkeiten gibt, diese zu überlisten, wie in Ausgabe 58 des phrack-Magazins oder in COREs Advisory Multiple vulnerabilities in stack smashing protection technologies beschrieben.

Wenn Sie Ihren Schutz gegen Pufferüberläufe (unabhängig von der gewählten Methode) testen wollen, können Sie paxtest installieren und die angebotenen Tests laufen lassen.


4.15.1 Kernelpatch zum Schutz vor Pufferüberläufen

Ein Kernelpatch, der Schutz vor Pufferüberläufen bietet, ist der Openwall-Patch, der diese im Linux-Kernel 2.2 verhindern soll. Für 2.4 oder neuere Kernel müssen Sie die Umsetzung von Exec-Shield oder die von PaX (ist im Grsecurity-Patch kernel-patch-2.4-grsecurity und im Adamantix-Patch kernel-patch-adamantix enthalten) benutzen. Für weitere Informationen zum Einsatz dieser Patches lesen Sie Den Kernel patchen, Abschnitt 4.14.


4.15.2 Prüfprogramme für Pufferüberläufe

Zur Nutzung von Werkzeugen zum Aufspüren von Pufferüberläufen benötigen Sie in jedem Fall Programmiererfahrung, um den Quellcode zu reparieren (und neu zu kompilieren). Debian stellt beispielsweise bfbtester (einen Überlauftester, der Programme per Brute-Force (durch Testen aller Möglichkeiten) nach Überläufen der Kommandozeile und von Umgebungsvariablen durchtestet) bereit. Andere interessante Pakete sind auch rats, pscan, flawfinder und splint.


4.16 Sichere Übertragung von Dateien

Während der normalen Systemadministration müssen Sie immer mal wieder Dateien auf Ihr System spielen oder von diesem holen. Auf sichere Art und Weise Dateien von einem Host zu einem anderen zu kopieren, wird durch die Benutzung des Paketes ssh erreicht. Eine andere Möglichkeit ist die Nutzung von ftpd-ssl, einem ftp-Server der Secure Socket Layer benutzt, um Übertragungen zu verschlüsseln.

Jede dieser Methoden benötigt natürlich einen speziellen Client. Debian stellt Ihnen solche zur Verfügung, zum Beispiel enthält das Paket ssh das Programm scp. Es arbeitet wie rcp, aber ist komplett verschlüsselt, so dass die bösen Jungs noch nicht einmal herausbekommen können, WAS Sie kopieren. Passend zu dem Server gibt es auch ein ftp-ssl Client-Paket. Sie können Clients für diese Software sogar für andere (nicht-UNIXoide) Betriebssysteme finden. putty und winscp stellen eine secure-copy-Implementierung für jede Version von Microsoft-Betriebssystemen zur Verfügung.

Beachten Sie, dass die Verwendung von scp den Benutzern Zugang zum gesamten Dateisystem ermöglicht, es sei denn, dass es in eine chroot-Umgebung eingesperrt ist, wie es in SSH in ein Chroot-Gefängnis einsperren, Abschnitt 5.1.1 beschrieben wird. Wahrscheinlich sogar leichter (abhängig vom verwendeten Daemon) kann auch der FTP in eine chroot-Umgebung eingesperrt werden. Das wird in Absichern von FTP, Abschnitt 5.3 beschrieben. Falls Sie sich sorgen, dass Benutzer Ihre lokalen Dateien durchsehen, und Sie verschlüsselte Kommunikation wünschen, können Sie einen FTP-Daemon mit Unterstützung für SSL einrichten oder FTP mit Klartext und VPN verbinden (siehe Virtual Private Networks (virtuelle private Netzwerke), Abschnitt 8.5.


4.17 Einschränkung und Kontrolle des Dateisystems


4.17.1 Benutzung von Quotas

Es ist wichtig, eine gute Quota-Regelung zu haben, da es die Benutzer daran hindert, die Festplatten zu füllen.

Sie können zwei Arten von Quota-Systemen benutzen: Benutzer-Quota und Gruppen-Quota. Wie Sie sich sicher denken können, begrenzt ein User-Quota den Plattenplatz, den ein Benutzer belegen kann, und ein Gruppen-Quota macht dasselbe für Gruppen. Beachten Sie dies, wenn Sie die Größe der Quotas festlegen.

Es gibt ein paar wichtige Punkte, die Sie erwägen sollten, wenn Sie ein Quota-System aufsetzen:

Für jede Partition und jedes Verzeichnis, auf das Benutzer Schreibzugriff haben, sollte ein Quota eingerichtet werden. Berechnen Sie eine sinnvolle Quota-Größe, die Benutzerfreundlichkeit und Sicherheit kombiniert, und weisen Sie diese zu.

Sie wollen also Quotas benutzen. Zuerst müssen Sie prüfen, ob Ihr Kernel Quota unterstützt. Wenn nicht, müssen Sie ihn neu kompilieren. Prüfen Sie anschließend, ob das Paket quota installiert ist. Wenn nicht, installieren Sie es.

Um Quota für die entsprechenden Dateisysteme einzuschalten, müssen Sie nur die Einstellung defaults in Ihrer /etc/fstab zu defaults,usrquota ändern. Wenn Sie Gruppen-Quotas benötigen, ersetzen Sie usrquota durch grpquota. Sie können auch beides verwenden. Erstellen Sie dann leere quota.user und quota.group in den Hauptverzeichnissen der Dateisysteme, auf denen Sie Quotas einführen möchten (d.h. touch /home/quota.user /home/quota.group für das Dateisystem /home).

Starten Sie quota neu, indem Sie /etc/init.d/quota stop;/etc/init.d/quota start ausführen. Nun sollte quota laufen und die Größen können festgelegt werden.

Bearbeiten der Quotas eines bestimmten Benutzer wird mit edquota -u <user> gemacht. Gruppen-Quotas können mit edquota -g <group> geändert werden. Setzen Sie dann die weiche und die harte Grenze und inode-Quotas, falls Sie es benötigen.

Mehr Informationen über Quotas finden Sie im Handbuch von quot und im Mini-Howto von quota (/usr/share/doc/HOWTO/de-html/mini/DE-Quota-HOWTO.html). Sie sollten auch einen Blick auf pam_limits.so werfen.


4.17.2 Die für das ext2-Dateisystem spezifischen Attribute (chattr/lsattr)

Zusätzlich zu den normalen Unix-Rechten bieten die ext2- und ext3-Dateisysteme eine Anzahl von besonderen Attributen, die Ihnen mehr Kontrolle über die Dateien auf Ihrem System erlauben. Im Gegensatz zu den gewöhnlichen Rechten werden diese Attribute nicht vom gebräuchlichen Befehl ls -l angezeigt und können auch nicht mit chmod geändert werden. Um sie zu verwalten, brauchen Sie zwei weitere Programme, nämlich lsattr und chattr (im Paket e2fsprogs). Beachten Sie, dass das bedeutet, dass diese Attribute normalerweise bei einem Backup des Systems nicht gespeichert werden. Wenn Sie also eines verändern, könnte es sich lohnen, die aufeinander folgenden chattr-Befehle in einem Skript zu speichern, damit Sie sie später wieder zuweisen können, falls Sie ein Backup zurückspielen müssen.

Unter allen Attributen werden die zwei, die für die Erhöhung der Sicherheit am bedeutendsten sind, mit den Buchstaben »i« und »a« bezeichnet. Sie können nur vom Superuser vergeben (oder entfernt) werden:

Diese Attribute können auch für Verzeichnisse vergeben werden. In diesem Fall ist es jedem unmöglich, den Inhalt des Verzeichnisses zu verändern, also beispielsweise eine Datei umzubenennen oder zu löschen. Wenn das append-Attribut einem Verzeichnis zugewiesen wird, können nur noch Dateien erstellt werden.

It is easy to see how the 'a' attribute improves security, by giving to programs that are not running as the superuser the ability to add data to a file without modifying its previous content. On the other hand, the 'i' attribute seems less interesting: after all, the superuser can already use the basic Unix permissions to restrict access to a file, and an intruder that would get access to the superuser account could always use the chattr program to remove the attribute. Such an intruder may first be confused when noticing not being able to remove a file, but you should not assume blindness - after all, the intruder got into your system! Some manuals (including a previous version of this document) suggest to simply remove the chattr and lsattr programs from the system to increase security, but this kind of strategy, also known as "security by obscurity", is to be absolutely avoided, since it provides a false sense of security.

Dieses Problem lösen Sie auf sichere Art und Weise, indem Sie die Fähigkeiten des Linux-Kernel verwenden, wie es in Proaktive Verteidigung, Abschnitt 10.4.2.1 beschrieben wird. Die hier interessante Fähigkeit heißt CAP_LINUX_IMMUTABLE: Wenn Sie es vom Satz der Fähigkeiten entfernen (indem Sie zum Beispiel den Befehl lcap CAP_LINUX_IMMUTABLE verwenden, ist es nicht mehr möglich, irgendwelche »a« oder »i« Attribute auf Ihrem System zu verändern, auch nicht durch den Superuser! Ein umfassende Strategie könnte also folgendermaßen aussehen:

  1. Vergeben Sie die Attribute »a« und »i« an von Ihnen gewünschte Dateien.

  1. Fügen Sie den Befehl lcap CAP_LINUX_IMMUTABLE einem der Skripten, die den Start des Systems steuern (startup scripts), hinzu.

  1. Setzen Sie das Attribut »i« für dieses Skript, andere Startdateien und auch das Programm lcap selbst.

  1. Führen Sie den oben genannten Befehl per Hand aus (oder starten Sie Ihr System neu, um sicherzustellen, dass alles wie gewünscht funktioniert).

Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file would be to boot the system in single-user mode or using another bootdisk, two operations that require physical access to the machine !


4.17.3 Prüfung der Integrität des Dateisystems

Sind Sie sich sicher, dass /bin/login auf Ihrer Festplatte immer noch dasselbe Programm ist, das Sie vor ein paar Monaten installiert haben? Was wäre, wenn es sich um eine gehackte Version handelt, die eingegebene Passwörter in einer versteckten Datei ablegt oder sie als Klartext im ganzen Internet herummailt?

Die einzige Methode, um 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 Werkzeuge hierfür sind sxid, aide (Advanced Intrusion Detection Environment, fortgeschrittene Umgebung zur Erkennung von Eindringlingen), tripwire, integrit und samhain. Das Installieren von debsums wird Ihnen helfen, die Integrität des Dateisystems zu überprüfen, indem Sie die MD5-Summen jeder Datei gegen die MD5-Summe aus dem Debian-Archiv-Paket vergleichen. Seien Sie aber gewarnt, dass diese Dateien sehr leicht von einem Angreifer geändert werden können. Außerdem stellen nicht alle Pakete MD5-Summen für die in ihnen enthaltenen Programme zur Verfügung. Weitere Informationen finden Sie unter Regelmäßiges Überprüfung der Integrität, Abschnitt 10.2 und Einen Schnappschuss des Systems erstellen, Abschnitt 4.19.

You might want to use locate to index the whole filesystem, if so, consider the implications of that. The Debian findutils package contains locate which runs as user nobody, and so it only indexes files which are visible to everybody. However, if you change it's behaviour you will make all file locations visible to all users. If you want to index all the filesystem (not the bits that the user nobody can see) you can replace locate with the package slocate. slocate is labeled as a security enhanced version of GNU locate, but it actually provides additional file-locating functionality. When using slocate, the user only sees the actually accessible files and you can exclude any files or directories on the system. The slocate package runs its update process with higher privledges than locate, and indexes every file. Users are then able to quickly search for every file which they are able to see. slocate doesn't let them see new files; it filters the output based on your UID.

Sie sollten auch bsign oder elfsign einsetzen. elfsign bietet die Möglichkeit, digitale Signaturen an ELF-Binaries anzufügen und diese Signaturen zu überprüfen. Die aktuelle Fassung verwendet PKI, um die Checksummen der Binaries zu signieren. Dies hat den Vorteil, dass festgestellt werden kann, ob das Binary verändert wurde und wer es erstellt hat. bsign verwendet GPG, elfsign benutzt PKI-(X.509)-Zertifikate (OpenSSL).


4.17.4 Aufsetzen einer Überprüfung von setuid

Das Debian-Paket checksecurity enthält einen Cron-Job, der täglich in /etc/cron.daily/checksecurity ausgeführt wird. [42]. Dieser Cron-Job führt das Skript /usr/sbin/checksecurity aus, das Informationen über Änderungen sichert.

The default behavior does not send this information to the superuser but, instead keeps daily copies of the changes in /var/log/setuid.changes. You should set the MAILTO variable (in /etc/checksecurity.conf) to 'root' to have this information mailed to the superuser. See checksecurity(8) for more configuration info.


4.18 Absicherung des Netzwerkzugangs

FIXME: mehr (für Debian spezifischer) Inhalt benötigt


4.18.1 Konfiguration der Netzwerkfähigkeiten des Kernels

Many features of the kernel can be modified while running by echoing something into the /proc file system or by using sysctl. By entering /sbin/sysctl -A you can see what you can configure and what the options are, and it can be modified running /sbin/sysctl -w variable=value (see sysctl(8)). Only in rare cases do you need to edit something here, but you can increase security that way as well. For example:

     net/ipv4/icmp_echo_ignore_broadcasts = 1

Dies ist ein Windows-Emulator, weil es sich wie Windows bei Rundrufen (Broadcast-Ping) verhält, wenn es auf 1 gesetzt wird. Das bedeutet, dass ICMP-Echo-Anfragen, die an die Rundrufadresse geschickt werden, ignoriert werden. Anderenfalls macht es gar nichts.

Falls Sie verhindern wollen, dass Ihr System auf ICMP-Echo-Anfragen antwortet, müssen Sie nur diese Konfigurationsoption anschalten:

     net/ipv4/icmp_echo_ignore_all = 1

Verwenden Sie Folgendes, um Pakete mit unmöglichen Adressen (erzeugt durch falsche Routen) in Ihrem Netzwerk zu protokollieren:

     /proc/sys/net/ipv4/conf/all/log_martians = 1

Für weiterführende Informationen, welche Sachen mit /proc/sys/net/ipv4/* angestellt werden können, sollten Sie /usr/src/linux/Documentation/filesystems/proc.txt lesen. Alle Optionen werden gründlich in /usr/src/linux/Documentation/networking/ip-sysctl.txt [43] beschrieben.


4.18.2 Konfiguration von Syncookies

Diese Option ist ein zweischneidiges Schwert. Auf der einen Seite schützt es Ihr System vor dem Überfluten mit syn-Paketen. Auf der anderen Seite verletzt es definierte Standards (RFCs).

     net/ipv4/tcp_syncookies = 1

Wenn Sie das dauerhaft für den Kernel festlegen wollen, müssen Sie in /etc/network/options syncookies=yes festlegen. Jedes Mal, wenn /etc/init.d/networking ausgeführt wird (was typischerweise beim Booten geschieht), wird diese Option wirksam. Dagegen wird folgendes nur eine einmalige Wirkung bis zum nächsten Neustart haben:

     echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Diese Option ist nur verfügbar, wenn der Kernel mit CONFIG_SYNCOOKIES übersetzt wurde. Alle Kernel von Debian wurden mit dieser Option kompiliert. Sie können das folgendermaßen überprüfen:

     $ sysctl -A |grep syncookies
     net/ipv4/tcp_syncookies = 1

Weitere Informationen zu TCP-Syncookies finden Sie unter http://cr.yp.to/syncookies.html.


4.18.3 Absicherung des Netzwerks beim Hochfahren

Wenn Sie die Netzwerkoptionen des Kernels konfigurieren, müssen Sie dafür sorgen, dass sie bei jedem Neustart des Systems geladen werden. Das nachfolgende Beispiel aktiviert neben vielen der oben vorgestellten Optionen auch noch ein paar andere nützliche Optionen.

There are actually two ways to configure your network at boot time. You can configure /etc/sysctl.conf (see: sysctl.conf(5)) or introduce a script that is called when the interface is enabled. The first option will be applied to all interfaces, whileas the second option allows you to configure this on a per-interface basis.

Ein Beispiel einer Konfiguration von /etc/sysctl.conf, die einige Netzwerkoptionen auf der Kernelebene absichert, wird unten gezeigt. Beachten Sie darin den Kommentar, dass /etc/network/options beim Ausführen von /etc/init.d/networking (dies ist in der Startsequenz nach procps) einige Werte überschreiben könnte, wenn sich Werte in dieser Datei widersprechen.

     #
     # /etc/sysctl.conf - Configuration file for setting system variables
     # See sysctl.conf (5) for information. Also see the files under
     # Documentation/sysctl/, Documentation/filesystems/proc.txt, and
     # Documentation/networking/ip-sysctl.txt in the kernel sources 
     # (/usr/src/kernel-$version if you have a kernel-package installed)
     # for more information of the values that can be defined here.
     
     #
     # Be warned that /etc/init.d/procps is executed to set the following
     # variables.  However, after that, /etc/init.d/networking sets some
     # network options with builtin values.  These values may be overridden
     # using /etc/network/options.
     #
     #kernel.domainname = example.com
     
     # Additional settings - adapted from the script contributed
     # by Dariusz Puchala (see below)
     # Ignore ICMP broadcasts
     net/ipv4/icmp_echo_ignore_broadcasts = 1
     #
     # Ignore bogus ICMP errors
     net/ipv4/icmp_ignore_bogus_error_responses = 1
     # 
     # Do not accept ICMP redirects (prevent MITM attacks)
     net/ipv4/conf/all/accept_redirects = 0
     # _or_
     # Accept ICMP redirects only for gateways listed in our default
     # gateway list (enabled by default)
     # net/ipv4/conf/all/secure_redirects = 1
     #
     # Do not send ICMP redirects (we are not a router)
     net/ipv4/conf/all/send_redirects = 0
     #
     # Do not forward IP packets (we are not a router)
     # Note: Make sure that /etc/network/options has 'ip_forward=no'
     net/ipv4/conf/all/forwarding = 0
     #
     # Enable TCP Syn Cookies
     # Note: Make sure that /etc/network/options has 'syncookies=yes'
     net/ipv4/tcp_syncookies = 1
     #
     # Log Martian Packets
     net/ipv4/conf/all/log_martians = 1
     #
     # Turn on Source Address Verification in all interfaces to
     # prevent some spoofing attacks
     # Note: Make sure that /etc/network/options has 'spoofprotect=yes'
     net/ipv4/conf/all/rp_filter = 1
     #
     # Do not accept IP source route packets (we are not a router)
     net/ipv4/conf/all/accept_source_route = 0

Um dieses Skript verwenden zu können, müssen Sie es zuerst unter z.B. /etc/network/interface-secure (der Name ist nur ein Beispiel) erstellen und es wie folgt aus /etc/network/interfaces aufrufen:

     auto eth0
     iface eth0 inet static
             address xxx.xxx.xxx.xxx
             netmask 255.255.255.xxx
             broadcast xxx.xxx.xxx.xxx
             gateway xxx.xxx.xxx.xxx
             pre-up /etc/network/interface-secure

In diesem Beispiel wird das Skript aufgerufen, um alle Netzwerkschnittstellen abzusichern, wie unten gezeigt wird, bevor die Schnittstelle eth0 aktiviert wird.

     #!/bin/sh -e
     # Skriptname: /etc/network/interface-secure
     #
     # Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen,
     # um vor TCP/IP-Spoofing und Angriffen zu schützen.
     #
     # Wurde von Dariusz Puchalak beigesteuert
     #
     echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                                # Broadcast echo protection enabled.
     echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
                                                # IP forwarding disabled.
     echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookies protection enabled.
     echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log strange packets.
     # (this includes spoofed packets, source routed packets, redirect packets)
     # but be careful with this on heavy loaded web servers.
     echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                                # Bad error message protection enabled.
     
     # IP spoofing protection.
     echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
     
     # Disable ICMP redirect acceptance.
     echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
     echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
     
     # Disable source routed packets.
     echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
     
     exit 0

Beachten Sie, dass Sie auch verschiedene Netzwerkoptionen für verschiedene Schnittstellen (falls Sie mehr als eine haben) setzten können, indem Sie die pre-up-Zeile verändern:

     pre-up /etc/network/interface-secure $IFACE

Zusätzlich müssen Sie ein Skript verwenden, das Änderungen nur auf eine bestimmte Schnittstelle anwendet und nicht auf alle Schnittstellen. Beachten Sie aber, dass einige Netzwerkoptionen nur global gesetzt werden können. Dies ist ein Beispielsskript:

     #!/bin/sh -e
     # Skriptname: /etc/network/interface-secure
     #
     # Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen,
     # um vor TCP/IP-Spoofing und Angriffen zu schützen.
     #
     # Wurde von Dariusz Puchalak beigesteuert
     #
     
     IFACE=$1
     if [ -z "$IFACE" ] ; then
        echo "$0: Must give an interface name as argument!"
        echo "Usage: $0 <interface>"
        exit 1
     fi
     
     if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
        echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)"
        exit 1
     fi
     
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding  # IP forwarding disabled.
     echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians # Log strange packets.
     # (this includes spoofed packets, source routed packets, redirect packets)
     # but be careful with this on heavy loaded web servers.
     
     # IP spoofing protection.
     echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter
     
     # Disable ICMP redirect acceptance.
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects
     
     # Disable source routed packets.
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route
     
     exit 0

Eine andere Lösungsmöglichkeit ist es, ein init.d-Skript zu erstellen und es beim Booten auszuführen (verwenden Sie update-rc.d, um die passenden rc.d-Links herzustellen).


4.18.4 Konfiguration der Firewall

Um die Möglichkeiten einer Firewall zu haben, damit entweder das lokale System oder andere dahinter beschützt werden, muss der Kernel mit Firewall-Unterstützung kompiliert worden sein. Der Standardkernel von Debian 2.2 (Linux 2.2) stellt die Paketfilter-Firewall ipchains zur Verfügung. Der Standardkernel von Debian 3.0 (Linux 2.4) enthält die stateful Paketfilter-Firewall iptables (netfilter).

In jedem Fall ist es recht einfach, einen anderen als den mit Debian gelieferten Kernel zu benutzen. Sie finden vorkompilierte Kernel als Pakete vor, die Sie leicht auf Ihrem Debian-System installieren können. Mit Hilfe des Pakets kernel-source-X können Sie auch die Kernelquellen herunterladen und einen maßgeschneiderten Kernel kompilieren, indem Sie make-kpkg aus dem Paket kernel-package benutzen.

Auf das Aufsetzen einer Firewall unter Debian wird unter Hinzufügen von Firewall-Fähigkeiten, Abschnitt 5.14 ausführlich eingegangen.


4.18.5 Lösung des Problems der Weak-End-Hosts

Auf Systemen mit mehr als einer Schnittstelle zu verschiedenen Netzwerken können Dienste so eingerichtet werden, dass sie Verbindungen nur zu einer bestimmten IP-Adresse zulassen. Normalerweise verhindert das den Zugang zu diesen Diensten, wenn an sie Anfragen über andere Adressen gestellt werden. Allerdings bedeutet das nicht, dass der Dienst an eine bestimmte Hardware-Adresse (Netzwerkkarte) gebunden ist (ein verbreiteter Irrtum). [44]

Das ist kein Problem von ARP und auch keine Verletzung eines RFCs (es wird in RFC1122, Abschnitt 3.3.4.2 als weak end host bezeichnet). Vergessen Sie nicht, dass IP-Adressen nichts mit dem physischen Schnittstellen zu tun haben.

Im Kernel 2.2 (und davor) konnte dieses Problem so gelöst werden:

     # echo 1 > /proc/sys/net/ipv4/conf/all/hidden
     # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
     # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
     .....

Bei späteren Kernel kann das folgendermaßen gelöst werden:

Along this text there will be many occasions in which it is shown how to configure some services (sshd server, apache, printer service...) in order to have them listening on any given address, the reader should take into account that, without the fixes given here, the fix would not prevent accesses from within the same (local) network. [47]

FIXME: Comments on Bugtraq indicate there is a Linux specific method to bind to a given interface.

FIXME: Submit a bug against netbase so that the routing fix is standard behavior in Debian?


4.18.6 Schutz vor ARP-Angriffen

Wenn Sie den anderen Kisten in Ihrem LAN nicht trauen (das sollte immer so sein, da es die sicherste Einstellung ist), sollten Sie sich vor den verschiedenen ARP-Angriffen schützen.

Wie Sie wissen, wird das ARP-Protokoll dazu verwendet, IP-Adressen mit MAC-Adressen zu verknüpfen (für alle Details siehe RFC826). Jedes Mal, wenn Sie ein Paket an eine IP-Adresse schicken, wird eine ARP-Auflösung vorgenommen (zuerst wird in den lokalen ARP-Speicher geschaut, und falls die IP nicht im Speicher ist, wird ein Rundruf (Broadcast) mit der ARP-Anfrage verschickt), um die Hardware-Adresse des Ziels zu finden. Alle ARP-Angriffe zielen darauf ab, Ihrem Rechner vorzugaukeln, dass die IP-Adresse des Rechners B mit der MAC-Adresse des Computers des Angreifers verbunden ist. Dadurch wird jedes Paket, das Sie an den Rechner B, der mit der IP-Adresse verbunden ist, schicken wollen, an den Computer des Eindringlings umgeleitet ...

Diese Angriffe (Verfälschung des ARP-Speichers, ARP-Spoofing, ...) ermöglichen dem Angreifer, auf Netzwerken den Verkehr abzuhören (selbst bei Netzwerken, die über einen Switch laufen). Er kann sich leicht in eine Verbindung einschleusen oder einen Host vom Netzwerk nehmen oder ... ARP-Angriffe sind leistungsfähig und einfach durchzuführen. Es gibt dafür auch einige Werkzeuge wie arpspoof aus dem Paket dsniff oder arpoison.

Allerdings gibt es immer eine Lösung:


4.19 Einen Schnappschuss des Systems erstellen

Bevor Sie das System in produktiven Betrieb nehmen, können Sie einen Schnappschuss des gesamten Systems erstellen. Diesen Schnappschuss können Sie im Falle einer Kompromittierung (siehe Nach einer Kompromittierung (Reaktion auf einem Vorfall), Kapitel 11) benutzen. Sie sollten den Schnappschuss immer dann erneuern, wenn Sie das System aktualisieren, insbesondere wenn Sie auf eine neue Debian-Veröffentlichung upgraden.

Hierfür können Sie beschreibbare, austauschbare Datenträger benutzen, die Sie schreibschützen können. Dies kann eine Diskette (die nach der Benutzung schreibgeschützt wird), eine CD in einem CD-ROM-Laufwerk (Sie können auch wiederbeschreibbare CD-ROMs benutzen, so können Sie sogar alte Sicherheitskopien Ihrer MD5-Summen behalten), eine USB-Platte oder eine MMC-Karte (wenn Ihr System auf diese zugreifen kann und sie schreibgeschützt werden können) sein.

Das folgende Skript erstellt einen solchen Schnappschuss:

     #!/bin/bash
     /bin/mount /dev/fd0 /mnt/floppy
     trap "/bin/umount /dev/fd0" 0 1 2 3 9 13 15
     if [ ! -f /usr/bin/md5sum ] ; then
     	echo "Kann md5sum nicht finden. Breche ab."
     	exit 1
     fi
     /bin/cp /usr/bin/md5sum /mnt/floppy
     echo "Erstelle MD5-Datenbank"
     >/mnt/floppy/md5checksums.txt
     for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
     do
        find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
     done
     echo "MD5-Datenbank (nach der Installation) erstellt"
     if [ ! -f /usr/bin/sha1sum ] ; then
     	echo "Kann sha1sum nicht finden"
             echo "WARNUNG: nur die md5-Datenbank wird gespeichert"
     else
     	/bin/cp /usr/bin/sha1sum /mnt/floppy
     	echo "Erstelle SHA-1-Datenbank"
     	>/mnt/floppy/sha1checksums.txt
     	for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
     	do
     	   find $dir -type f | xargs /usr/bin/sha1sum >>/mnt/floppy/sha1checksums-lib.txt
     	done
     	echo "SHA-1-Datenbank (nach der Installation) erstellt"
     fi
     exit 0

Beachten Sie, dass das Programm md5sum (und sha1sum, falls verfügbar) auch auf der Diskette gesichert werden muss, so dass Sie es später benutzen können, um die anderen Programme Ihres Systems zu prüfen (für den Fall, dass md5sum oder sha1sum einen Trojaner enthalten). Wenn Sie aber sicher sein wollen, dass Sie eine gültige Kopie von md5sum verwenden, sollten Sie eine statische Kopie von md5sum erstellen und diese verwenden (damit wird verhindert, dass eine manipulierte libc-Bibliothek das Programm beeinträchtigt) oder md5sum nur in einer sauberen Umgebung einsetzen, die Sie etwa mit einer Rettungs-CD-ROM oder einer Live-CD erzeugen können (damit wird verhindert, dass ein manipulierter Kernel das Programm beeinflusst). Ich kann es nicht genug betonen: Wenn Sie ein System haben, in das eingebrochen wurde, können Sie den Ausgaben nicht vertrauen. Sehen Sie sich auch Nach einer Kompromittierung (Reaktion auf einem Vorfall), Kapitel 11 an.

Dieser Schnappschuss enthält nicht die Dateien unterhalb von /var/lib/dpkg/info, wo MD5-Summen installierter Pakete enthalten sind (die Dateien enden mit .md5sums). Sie können diese Informationen zusätzlich kopieren, aber Sie sollten Folgendes beachten:

Sobald der Schnappschuss erstellt wurde, sollten Sie sicherstellen, dass das entsprechende Medium schreibgeschützt ist. Sie können es dann als Sicherheitskopie verwenden oder in ein Laufwerk stecken, um jede Nacht mit cron die MD5-Summen des Systems mit Ihrem Schnappschuss zu vergleichen.

Wenn Sie keine Überprüfung von Hand einrichten wollen, können Sie immer eines der Integritätssysteme verwenden, die diese Aufgabe und noch vieles mehr für Sie erledigen werden. Weitere Informationen finden Sie unter Regelmäßiges Überprüfung der Integrität, Abschnitt 10.2.


4.20 Andere Empfehlungen


4.20.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 vermeiden.


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


Securing Debian Manual

Version: 3.17, Sun, 08 Apr 2012 02:48:09 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Autoren, Abschnitt 1.1