<!-- CVS revision of original english document "1.68" -->

<chapt>Nach der Installation

<p>Wenn das System installiert ist, können Sie es noch weiter absichern,
indem Sie einige der in diesem Kapitel beschriebenen Schritte ausführen.
Natürlich hängt dies vor allem von Ihrem Setup ab, aber um
physischen Zugriff zu verhindern, sollten Sie <ref id="bios-boot">, 
<ref id="lilo-passwd">, <ref id="kernel-root-prompt">,
<ref id="restrict-console-login"> und <ref id="restrict-reboots"> lesen.

<p>Bevor Sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um
ein öffentliches Netzwerk handelt, sollten Sie wenigstens eine
Sicherheitsaktualisierung 
(siehe <ref id="security-update">) durchführen. Optional können Sie auch
einen Schnappschuss Ihres Systems machen (siehe <ref id="snapshot">).


<sect id="debian-sec-announce">Abonnement der Security-Announce-Mailingliste
von Debian

<p>Um Informationen zu verfügbaren Sicherheitsaktualisierungen und die
Debian-Sicherheits-Ankündigungen (DSA) zu erhalten,
sollten Sie Debians Security-Announce-Mailingliste abonnieren. Lesen Sie <ref
id="debian-sec-team"> für weitere Informationen, wie das Sicherheitsteam von
Debian arbeitet. Hinweise, wie man die Mailinglisten von Debian abonniert,
finden Sie unter <url id="http://lists.debian.org">.

<p>DSAs werden mit der Signatur des Sicherheitsteams von Debian unterschrieben, die
unter <url id="http://security.debian.org"> erhältlich ist.

<p>Sie sollten in Betracht ziehen, auch die <url
id="http://lists.debian.org/debian-security" name="debian-security Mailingliste"> zu abonnieren. Dort finden allgemeine Diskussionen zu Sicherheitsthemen
im Betriebssystem Debian statt. Sie können auf der Liste sowohl mit
gleichgesinnten Systemadministratoren als auch mit Entwicklern von Debian und
Programmautoren in Kontakt treten. Diese werden Ihre Fragen beantworten und
Ihnen Ratschläge geben.

<p>FIXME: Add the key here too?


<sect id="security-update">Ausführen von Sicherheitsupdates

<p>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 <url
name="http://security.debian.org" id="http://security.debian.org"> bereit
gestellt.

<p>Wenn Sie ein Debian-Release installieren, müssen Sie berücksichtigen, dass
es seit der Veröffentlichung Sicherheitsaktualisierungen gegeben haben könnte, nachdem entdeckt
wurde, dass ein bestimmtes Paket verwundbar ist. Ebenso könnte es kleinere
Releases gegeben haben. Es gab vier kleinere Veröffentlichungen von Debian 3.1
<em>Sarge</em>, die diese Paketaktualisierungen enthalten.

<p>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 erster Systemstart
eingespielt, damit das neue System sein Leben so aktuell wie möglich
beginnt.

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

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

<p><em>Hinweis:</em> Falls Sie den <em>Testing</em>-Zweig einsetzen, sollten
Sie die Sicherheitsspiegel für Testing verwenden. Das wird unter <ref
id="security-support-testing"> beschrieben.

<p>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
<prgn>update-notifier</prgn> verwenden<footnote>Ab <em>Etch</em> und
den folgenden Veröffentlichungen.</footnote>, mit der Sie leicht
prüfen können, ob neue Aktualisierung verfügbar sind. Damit können Sie
Ihr System auch über den Desktop auf den neusten Stand bringen
(mit <prgn>update-manager</prgn>). Weitere Informationen finden Sie
unter <ref id="update-desktop">. Für den Desktop können Sie
auch <package>synaptic</package> (GNOME), <package>kpackage</package>
oder
<package>adept</package> (KDE) einsetzen, die einen größeren
Funktionsumfang aufweisen. Wenn Sie auf einem textbasierten Terminal
arbeiten, stehen Ihnen
<package>aptitude</package>, <package>apt</package> und
<package>dselect</package>, wobei letzteres veraltet ist, zur Verfügung:

<list>
<item>Falls Sie die textbasierte Oberfläche von <package>aptitude</package>
verwenden wollen, müssen Sie zunächst <em>u</em> (für Update) und dann
<em>g</em> (für Upgrade) eingeben. Oder Sie führen auf der Befehlszeile
Folgendes als Root aus:
<example>
 # aptitude update
 # aptitude upgrade
</example>

<item>Falls Sie <package>apt</package> einsetzen möchten, müssen Sie obige
Zeilen von <prgn>aptitude</prgn> nur mit <prgn>apt-get</prgn> ersetzen.

<item>Falls Sie <package>dselect</package> verwenden wollen, müssen Sie zuerst
aktualisieren ([U] für Update), dann installieren ([I] für Install) und
schließlich die installieren/aktualisierten Pakete konfigurieren ([C] für
Configure).
</list>

<p>Wenn Sie möchten, können Sie
der Datei <file>/etc/apt/sources.list</file> die Zeilen mit deb-src
hinzufügen. Weitere Details finden Sie unter <manref name="apt"
section="8">.

<sect1 id="lib-security-update">Sicherheitsaktualisierungen von Bibliotheken

<p>Wenn Sie eine Sicherheitsaktualisierung durchgeführt haben, müssen Sie
gegebenenfalls einige Dienste des Systems neu starten. Wenn Sie das nicht tun,
könnten Dienste auch nach der Sicherheitsaktualisierung immer noch verwundbar
sein. Das liegt daran, dass Daemonen, die schon vor einem Upgrade liefen, immer
noch die alten Bibliotheken vor dem Upgrade verwenden könnten.<footnote>
Selbst wenn die Bibliotheken aus dem Dateisystem entfernt wurden, werden die
Inodes nicht beseitigt, bis kein Programm mehr einen offenen Dateideskriptor
mit Verweis auf sie hat.</footnote>
Um herauszufinden, welche Daemonen neu gestartet werden müssen, können Sie das
Programm <prgn>checkrestart</prgn> (ist im Paket
<package>debian-goodies</package> enthalten) oder diesen Einzeiler (als Root)
verwenden:<footnote>Je nach der Version von lsof müssen Sie $8 statt $9 verwenden.</footnote>

<example>
# lsof | grep &lt;aktualisierte_Bibliothek&gt; | awk '{print $1, $9}' | uniq | sort -k 1
</example>

<p>Einige Pakete (wie <package>libc6</package>) 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
<footnote>
Das passierte z.B. beim Upgrade von libc6 2.2.x zu 2.3.x wegen Problemen mit
der NSS-Authentifizierung, siehe <url
id="http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html">.
</footnote>.

<p>Indem das System auf Runlevel 1 (Single User) und dann zurück auf Runlevel 3
(Multi User) gebracht wird, sollten die meisten (wenn nicht alle) Systemdienste
neu gestartet werden. Dies ist aber keine Möglichkeit, wenn Sie die
Sicherheitsaktualisierung über eine entfernte Verbindung (z.B. mit ssh)
vornehmen, da sie getrennt werden würde.

<p>Lassen Sie Vorsicht walten, wenn Sie es mit Sicherheitsaktualisierungen über
eine entfernte Verbindung wie mit ssh zu tun haben. Die empfohlene
Vorgehensweise für Sicherheitsaktualisierungen, die Dienste betreffen, ist, den
SSH-Daemon neu zu starten und sofort zu versuchen, eine neue SSH-Verbindung
herzustellen, ohne die alten zu beenden. Falls der Verbindungsversuch scheitern
sollte, machen Sie die Aktualisierung rückgängig und untersuchen Sie das
Problem.

</sect1>


<sect1 id="kernel-security-update">Sicherheitsaktualisierung des Kernels

<p>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 <em>nicht</em> in das Paketsystem
integriert und könnte veraltet sein. Sie können das leicht überprüfen, indem
Sie Folgendes ausführen:

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

<p>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
<package>linux-image-2.6.18-4-686</package> 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
<em>nur</em> für Aktualisierungen der gleichen Kernelversion wie der Ihrigen
durchgeführt werden. D.h. <prgn>apt</prgn> wird nicht automatisch Ihren Kernel
von 2.4 auf 2.6 aktualisieren (oder von 2.4.26 auf 2.4.27
<footnote>
Es sei denn, Sie haben ein Kernel-Metapaket wie
<package>linux-image-2.6-686</package> installiert, welches immer die neueste
Minor-Version des Kernels einer Architektur installieren wird.
</footnote>).

<p>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:

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

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

<example>
$ 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
  Kanditat: 2.6.18.dfsg.1-12
  Versionstabelle:
 *** 2.6.18.dfsg.1-12 0
        100 /var/lib/dpkg/status
</example>

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

<!-- FIXME: Do a script to check for the above, maybe using ps -p 1 -o etime |
tail -1 and obtain the creation time of `readlink -f /vmlinuz`. -->

<p>Wenn Sie das System neu starten müssen (wegen eines Kernel-Upgrades),
sollten Sie sicherstellen, dass der Kernel fehlerfrei booten wird und die
Netzwerkverbindungen hergestellt werden, besonders wenn die
Sicherheitsaktualisierung über eine entfernte Verbindung wie mit ssh
durchgeführt wird. Für den ersten Fall können Sie Ihren Boot-Loader so
konfigurieren, dass er den Originalkernel lädt, wenn ein Fehler auftritt (für
weiterführende Informationen sollten Sie <url
id="http://www.debian-administration.org/?article=70" name="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
<footnote>
Ein Beispielskript mit dem Namen <url
id="http://www.debian-administration.org/articles/70/testnet" name="testnet">
ist im Artikel <url id="http://www.debian-administration.org/?article=70"
name="Remotely rebooting Debian GNU/Linux machines"> enthalten. Ein
ausgereifteres Testskript befindet sich im Artikel <url
id="http://www.debian-administration.org/?article=128" name="Testing network
connectivity">
</footnote>.
Dies sollte böse Überraschungen verhindern, wie wenn man den Kernel
aktualisiert und dann nach einem Reboot merkt, dass die Netzwerkhardware nicht
richtig erkannt oder konfiguriert wurde, und man daher eine weite Strecke
zurücklegen muss, um das System wieder hoch zu bringen. Natürlich hilft es beim
Debuggen von Reboot-Problemen aus der Ferne, wenn die serielle Konsole des
Systems
<footnote>
Das Einrichten einer seriellen Konsole würde den Rahmen dieses Dokuments
sprengen. Informationen dazu finden Sie im <url
id="http://www.tldp.org/HOWTO/Serial-HOWTO.html" name="Serial HOWTO"> und im
<url id="http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/index.html"
name="Remote Serial Console HOWTO">.
</footnote>
mit einem Konsolen- oder Terminalserver verbunden ist.
</p>

</sect1>


<sect id="bios-boot">Änderungen im BIOS (noch einmal)

<p>Erinnern Sie sich an <ref id="bios-passwd">? Nun, jetzt sollten Sie, nachdem
Sie nicht mehr von austauschbaren Datenträgern booten müssen, die
Standard-BIOS-Einstellung umändern, so dass das System <em>ausschließlich</em> 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.

<p>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.

<sect id="lilo-passwd">Ein Passwort für LILO oder GRUB einstellen
<p>
Jeder kann sehr einfach eine Root-Shell auf Ihrem System bekommen, indem er
einfach <tt>&lt;Name-Ihres-Bootimages&gt; init=/bin/sh</tt> 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.

<p>
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.

<p>Für LILO müssen Sie die Konfigurationsdatei <file>/etc/lilo.conf</file>
editieren und eine <tt>password</tt> und <tt>restricted</tt> Zeile, wie im
folgenden Beispiel, einfügen:

<example>
  image=/boot/2.2.14-vmlinuz
     label=Linux
     read-only
     password=hackmich
     restricted
</example>

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

<p>
Wenn Sie GRUB anstelle von LILO verwenden, editieren Sie
<file>/boot/grub/menu.lst</file> und fügen die folgenden zwei Zeilen
am Anfang an (dabei ersetzen Sie natürlich <tt>hackmich</tt> mit dem
vorgesehenen Passwort). Dies verhindert, dass Benutzer die
Booteinträge verändern können. <tt>timeout 3</tt> legt eine
Wartedauer von 3 Sekunden fest, bevor <prgn>grub</prgn> den Standard-Eintrag
bootet.

<example>
  timeout 3
  password hackmich
</example>

<p>Um die Integrität Ihres Passwortes zusätzlich abzusichern,
sollten Sie Ihr Passwort verschlüsselt ablegen. Das Dienstprogramm
<prgn>grub-md5-crypt</prgn> erzeugt ein gehashtes Passwort, das kompatibel
mit GRUBs Verschlüsselungsalgorithmus (MD5) ist.
Um <prgn>grub</prgn> mitzuteilen, dass ein Passwort im MD5-Format verwendet
wird, benutzen Sie die folgende Anweisung:
<example>
  timeout 3
  password --md5 $1$arPydhOM$bIgEKjMW5kxeEuvE1Rah4/
</example>

Der Parameter --md5 wurde hinzugefügt, um bei <prgn>grub</prgn> einen
MD5-Authentifizierungsprozess zu erzwingen. Das angegebene Passwort ist die
MD5 verschlüsselte Version von &quot;hackmich&quot;. MD5-Passwörter sind
Klartext-Passwörtern vorzuziehen. Weitere Informationen über
<prgn>grub</prgn>-Passwörter können Sie im <package>grub-doc</package>-Paket
finden.


<sect id="kernel-initramfs-promt">Entfernen des Root-Prompts von Initramfs

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

<p>Die Linux-Kernel 2.6 enthalten die Möglichkeit, während des Bootvorgangs
eine Root-Shell zu erhalten. Dies geschieht, wenn beim Laden von initramfs ein
Fehler auftritt. Dadurch kann der Administrator auf eine Rettungsshell mit
Root-Rechten zugreifen. Mit dieser Shell können von Hand Module geladen werden,
falls eine automatische Erkennung scheitern sollte. Diese Verhalten ist
Standard für ein von <prgn>initramfs-tools</prgn> erzeugtes Initramfs. Folgende
Fehlermeldung wird auftreten:
<example>
  "ALERT!  /dev/sda1 does not exist.  Dropping to a shell!
</example>

<p>Um dieses Verhalten abzuschalten, müssen Sie folgenden Boot-Parameter
setzen: <em>panic=0</em>. Sie können ihn entweder in den Abschnitt kopt in
<file>/boot/grub/menu.lst</file> eintragen und <prgn>update-grub</prgn>
ausführen oder ihn dem Abschnitt append von <file>/etc/lilo.conf</file>
hinzufügen.


<sect id="kernel-root-prompt">Entfernen des Root-Promptes aus dem Kernel

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

<p>Linux 2.4 Kernel bieten kurz nach dem Laden des cramfs einen Weg Zugriff
auf eine Root-Shell zu bekommen, also während das System bootet. Es
erscheint eine Meldung, die dem Administrator erlaubt, eine
auszuführende Shell mit Root-Privilegien zu öffnen. Diese Shell kann
dazu benutzt werden, manuell Module zu laden, falls die automatische
Erkennung fehlschlägt. Dies ist das Standard-Verhalten bei
<prgn>initrd</prgn>'s <file>linuxrc</file>. Die folgende Meldung wird
erscheinen:
<example>
  Press ENTER to obtain a shell (waits 5 seconds)
</example>

<p>Um dieses Verhalten zu entfernen, müssen Sie
<file>/etc/mkinitrd/mkinitrd.conf</file> editieren und den Eintrag
<example>
  # DELAY  Anzahl Sekunden, die das linuxrc Skript warten soll,
  # um den Nutzer Eingriffe zu erlauben, bevor das System hochgefahren 
  # wird
  DELAY=0
</example>
setzen.

<p>Erstellen Sie anschließend Ihr Ramdisk-Image neu. Dies können Sie
zum Beispiel so tun:
<example>
  # cd /boot
  # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
</example>
<p>oder (vorzugsweise) so:
<example>
  # dpkg-reconfigure kernel-image-2.4.x-yz
</example>


<sect id="restrict-console-login">Einschränkender Konsolen-Zugang

<p>Manche Sicherheitsregelwerke könnten Administratoren dazu zwingen,
sich erst als Benutzer mit ihrem Passwort auf dem System einzuloggen, und
dann Superuser zu werden (mit <prgn>su</prgn> oder <prgn>sudo</prgn>).
Solche ein Regelwerk ist in Debian in den Dateien
<file>/etc/pam.d/login</file> und <file>/etc/securetty</file> (falls Sie
PAM verwenden) implementiert.

<list>

<item>Die Datei <file>/etc/pam.d/login</file>
<footnote>In älteren Debian-Veröffentlichungen müssen Sie in der
Datei <file>login.defs</file> die CONSOLE-Variable ändern, die eine
Datei oder eine Liste von Terminals definiert, an denen sich Root
anmelden darf.</footnote>
aktiviert das Modul pam_securetty.so. Wenn es richtig konfiguriert
ist, wird Root, wenn er sich auf einer unsicheren Konsole anmelden
will, nicht nach einem Passwort gefragt, sondern sein Anmeldeversuch
wird abgelehnt.

<item>In <file>securetty</file>
<footnote>
Die Datei <file>/etc/securetty</file> ist eine Konfigurationsdatei, die zum
Paket <package>login</package> gehört.
</footnote>
entfernen Sie oder fügen Sie Terminals hinzu, auf die Root zugreifen
darf. Falls Sie nur lokalen Zugang zur Konsole erlauben wollen, benötigen Sie
<em>console</em>, <em>ttyX</em>
<footnote>
Oder <em>ttyvX</em> in GNU/FreeBSD und <em>ttyE0</em> in GNU/KNetBSD.
</footnote>
und <em>vc/X</em> (falls Sie die <em>devfs</em>-Schnittstelle verwenden). Sie
sollten auch <em>ttySX</em> 
<footnote>
Oder <em>comX</em> in GNU/Hurd, <em>cuaaX</em> in GNU/FreeBSD
und <em>ttyXX</em> in GNU/KNetBSD.
</footnote>
hinzufügen, wenn Sie eine serielle Konsole für den lokalen Zugang
verwenden (wobei X eine ganze Zahl ist; es kann wünschenswert sein, mehrere
Instanzen zu verwenden). Die Standardeinstellung in <em>Wheezy</em>
<footnote>
Die Standardeinstellung in <em>Woody</em> beinhaltet zwölf lokale tty-
und virtuelle Konsolen und
die <em>console</em>-Schnittstelle. Anmeldungen von entfernten Orten
sind nicht erlaubt. In <em>Sarge</em> stellt die Standardeinstellung
64 Konsolen für tty- und virtuelle Konsolen zu Verfügung.
</footnote>
beinhaltet viele tty-Konsolen, serielle Schnittstellen und vc-Konsolen
sowie den X-Server und die <em>console</em>-Schnittstelle. Sie können
das ohne Probleme anpassen, wenn Sie nicht derartige viele Konsolen
benutzen. Sie können die Anzahl der Konsolen und Schnittstellen in
<file>/etc/inittab</file> überprüfen
<footnote>
Achten Sie auf die <em>getty</em> Einträge.
</footnote>.
Weiterführende Informationen zu Terminal-Schnittstellen finden Sie im <url
id="http://tldp.org/HOWTO/Text-Terminal-HOWTO-6.html"
name="Text-Terminal-HOWTO">.

</list>

<p>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 <file>/etc/pam.d/login</file> vornehmen. Eine
interessante Eigenschaft, die man auch abschalten kann, ist die
Möglichkeit, sich mit einem leeren Passwort (Null Passwort)
einzuloggen. Diese Eigenschaft kann eingeschränkt werden, indem sie
<em>nullok</em> aus der Zeile
<example>
  auth       required   pam_unix.so nullok
</example>
entfernen.


<sect id="restrict-reboots">System-Neustart von der Konsole aus einschränken

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

<p>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). Ein Systemadministration kann sie auch dazu
verwenden, <em>virtuell</em> das System neu zu starten.

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

<list>
<item>mit einer Konfiguration, mit der nur <em>bestimmte</em> Benutzer
das System neu starten dürfen,
<item>diese Eigenschaft vollständig zu deaktivieren.
</list>

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

<p>Standardmäßig enthält Debian diese  Optionen:
<example>
  ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
</example>

<p>Die Option <tt>-a</tt> ermöglicht es, <em>einigen</em> Benutzern zu
erlauben, das System neu zu starten (vgl. die
Handbuchseite <manref section="8" name="shutdown">). Dazu müssen Sie
die Datei <file>/etc/shutdown.allow</file> erstellen und die Namen der
Benutzer, die das System neu booten dürfen, aufführen. Wenn
der <em>Affengriff</em> in einer Konsole ausgeführt wird, wird
geprüft, ob irgendeiner der Benutzer, die in der Datei aufgelistet
sind, angemeldet ist. Wenn es keiner von ihnen ist,
wird <prgn>shutdown</prgn> das System <em>nicht</em> neu starten.

<p>Wenn Sie die Tastenkombination Ctrl+Alt+Del deaktivieren möchten,
müssen Sie nur die Zeile mit <em>ctrlaltdel</em>
in <file>/etc/inittab</file> auskommentieren.

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


<sect id="restrict-sysrq">Die Tastenkombination Magische S-Abf einschränken.

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

<p>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 <file>/proc/sys/kernel/sysrq</file>
existiert, und an dessen Wert:

<example>
$ cat /proc/sys/kernel/sysrq 
438
</example>

<p>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 einbinden, 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.

<p>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 <file>/etc/sysctl.conf</file> bearbeiten und folgende Zeile
einfügen:

<example>
# Disables the magic SysRq key
kernel.sysrq = 0
</example>

<p>Weitere Informationen finden Sie
im <url id="http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html"
name="security chapter in the Remote Serial Console HOWTO">, in der
<url id="http://kernel.org/doc/Documentation/sysrq.txt" name="Kernel
SysRQ documentation"> und
dem <url id="https://de.wikipedia.org/wiki/Magische_S-Abf-Taste"
name="Wikipedia-Eintrag zur Magischen S-Abf-Taste">.


<sect>Partitionen auf die richtige Art einbinden
<p>
Wenn Sie ein <tt>Ext</tt>-Dateisystem (<tt>ext2</tt>, <tt>ext3</tt> oder
<tt>ext4</tt>) einbinden, können Sie verschiedene
Optionen mit dem mount-Befehl oder in <file>/etc/fstab</file> verwenden.
Dies ist zum Beispiel mein fstab-Eintrag für meine
<file>/tmp</file>-Partition:
<example>
  /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2
</example>

<p>
Sie sehen den Unterschied in der Spalte mit den Optionen. Die Option
<tt>nosuid</tt> ignoriert komplett alle setuid- und setgid-Bits,
während <tt>noexec</tt> das Ausführen von Programmen
unterhalb des Einhängepunkts verbietet und <tt>nodev</tt> Gerätedateien ignoriert. Das
hört sich toll an, aber:
<list>
<item>ist nur auf <tt>ext2</tt> oder <tt>ext3</tt>-Dateisysteme anwendbar,
<item>kann leicht umgangen werden
</list>

<p>Die <tt>noexec</tt>-Option, die verhindert, dass Binarys
ausgeführt werden können, ließe sich in früheren Kernelversionen leicht
umgehen:
<example>
  alex@joker:/tmp# mount | grep tmp
  /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
  alex@joker:/tmp# ./date
  bash: ./date: Permission denied
  alex@joker:/tmp# /lib/ld-linux.so.2 ./date
  Sun Dec  3 17:49:23 CET 2000
</example>

<p>Neuere Versionen des Kernels verarbeiten aber die Option <tt>noexec</tt>
richtig:

<example>
  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
</example>

<p>
Wie auch immer, viele Skript-Kiddies haben Exploits, die versuchen eine
Datei in <file>/tmp</file> zu erstellen und auszuführen. Wenn sie keine
Ahnung haben, werden sie in dieser Grube hängen bleiben. Mit anderen
Worten: Ein Benutzer kann nicht hereingelegt werden, einen
ausführbaren Trojaner in <file>/tmp</file> laufen zu lassen, zum
Beispiel indem er zufällig <file>/tmp</file> in seinen Suchpfad
aufnimmt.

<p>Seien Sie sich auch bewusst, dass manche Skripte darauf aufbauen, dass
<file>/tmp</file> ausführbare Rechte hat. Bemerkenswerterweise
hatte (oder hat?) Debconf Probleme bei dieser Sache, weitere
Informationen enthält Fehler <url id="http://bugs.debian.org/116448"
name="116448">.

<p>
Nachfolgend ein gründlicheres Beispiel. Eine Anmerkung dazu:
<file>/var</file> könnte auch noexec enthalten, aber manche Software
<footnote>Einiges davon trifft auf den Paketverwalter <package>dpkg</package>
zu, da die Installations- oder Deinstallationsanweisungen (post, pre) unter
<file>/var/lib/dpkg/</file> liegen, und auch auf Smartlist.
</footnote>
verwahrt ihre Programme unterhalb von <file>/var</file>. Dasselbe gilt für die
nosuid-Option.

<example>
/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
</example>

<sect1><file>/tmp</file> noexec setzen
<p>
Seien Sie vorsichtig, wenn Sie <file>/tmp</file> noexec setzen und neue
Software installieren wollen, da manche Software es während der
Installation benutzt. <package>apt</package> ist ein solches Programm (siehe
<url id="http://bugs.debian.org/116448">), wenn nicht
<tt>APT::ExtractTemplates::TempDir</tt> (siehe <manref
name="apt-extracttemplates" section="1">) passend konfiguriert wurde. Sie
können diese Variable in <file>/etc/apt/apt.conf</file> auf ein
anderes Verzeichnis als <file>/tmp</file> mit exec-Privilegien setzen.

<!-- This is a duplicate of the example a few paragraphs up. So why repeat it?
(thomas)
<p>Was noexec betrifft, seien Sie sich bitte bewusst, dass es Ihnen nicht
sehr viel Sicherheit bietet. Beachten Sie Folgendes:
<example>
  $ cp /bin/date /tmp
  $ /tmp/date
  (wird aufgrund des noexec nicht ausgeführt)
  $/lib/ld-linux.so.2 /tmp/date
  (funktioniert, da date nicht direkt ausgeführt wird)
</example>
-->

<sect1>Setzen von /usr auf nur-lesen
<p>Wenn Sie auf <file>/usr</file> nur lesenden Zugriff erlauben, werden Sie
nicht in der Lage sein, neue Pakete auf Ihrem Debian GNU/Linux System
zu installieren. Sie werden es erst mit Schreibzugriff
erneut mounten müssen, die Pakete installieren und dann wieder
nur mit lesendem Zugriff mounten. <package>apt</package>
kann so konfiguriert werden, dass Befehle vor und nach dem
Installieren von Paketen ausgeführt werden. Vielleicht sollten Sie es passend
konfigurieren.

<p>Dazu öffnen Sie <file>/etc/apt/apt.conf</file> und fügen Sie Folgendes
ein:
<example>
  DPkg
  {
      Pre-Invoke  { "mount /usr -o remount,rw" };
      Post-Invoke { "mount /usr -o remount,ro" };
  };
</example>

<p>Beachten Sie, dass das Post-Invoke mit einer "/usr busy"
Fehlermeldung scheitern wird. Dies passiert vorwiegend, wenn Sie eine
Datei benutzen, die aktualisiert wurde. Sie können diese Programme finden,
indem Sie
<example>
  # lsof +L1
</example>
ausführen.

<p>Halten Sie diese Programme an oder starten Sie sie erneut und rufen dann
Post-Invoke manuell auf. <em>Achtung!</em> 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 <file>/usr</file> zu Ihrem System
passt. Vergleichen Sie auch diese <url
id="http://lists.debian.org/debian-devel/2001/11/threads.html#00212"
name="Diskussion auf debian-devel über nur-lesbares /usr">.


<sect>Den Benutzern einen sicheren Zugang bereitstellen

<sect1 id="auth-pam">Nutzerauthentifizierung: PAM

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

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

<list>
<item>welches Verfahren zur Authentifizierung benutzt wird.
<item>welches Verfahren innerhalb einer Sitzung benutzt wird.
<item>wie Passwörter überprüft werden.
</list>

<p> Die folgende Beschreibung ist weit davon entfernt, vollständig zu
sein. Für weitere Informationen können
Sie die <url id="http://www.linux-pam.org/Linux-PAM-html/" name="Linux-PAM
Guides"> lesen. Diese Dokumentation ist auf Ihrem System
unter <file>/usr/share/doc/libpam-doc/html/</file> verfügbar, wenn
Sie <package>libpam-doc</package> installieren.

<p>PAM bieten Ihnen die Möglichkeit, durch mehrere Authentifizierungsschritte
auf einmal zu gehen, ohne dass der Benutzer es weiß. Sie
können gegen eine Berkeley-Datenbank und gegen die normale <file>passwd</file>
Datei authentifizieren, und der Benutzer kann sich nur anmelden, wenn er
beide Male korrekt authentifiziert wurde. Sie können viel
einschränken mit PAM, genauso wie Sie Ihr System weit öffnen
können. Seien Sie also vorsichtig. Eine typische Konfigurationszeile
hat ein Kontrollfeld als zweites Element.
<!-- Second in mine (old Debian v2.0 though), check this! (FIXME) (era) -->
Generell sollte es auf <tt>requisite</tt> gesetzt werden, so wird ein
Loginfehler erzeugt, wenn eines der Module versagt.
<!-- Lots of fields in mine are "required", please elaborate? (FIXME) (era) -->


<sect2 id="pam-passwords">Passwortsicherheit in PAM

<p>Sehen Sie sich <file>/etc/pam.d/common-password</file> an, die
von <file>/etc/pam.d/passwd</file> eingebunden wird.
<footnote>In früheren Debian-Veröffentlichungen befand sich die
Konfiguration der Module direkt
in <file>/etc/pam.d/passwd</file>.</footnote>
Andere Dateien in <file>/etc/pam.d/</file> lesen diese Datei ein,
um die Verwendung eines Passworts durch Programme, die einen Zugriff
auf das System erlauben, wie etwa das Konsolen-Login (<tt>login</tt>),
grafische Login-Manager (z.B. <tt>gdm</tt> oder <tt>lightdm</tt>) und
Login aus der Ferne (etwa mit <tt>sshd</tt>), zu definieren.

<p>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.

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

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

<p>Dieser Ausdruck

<list>

<item>erzwingt die Verschlüsselung von Passwörtern mit der
Hashfunktion SHA-512, wenn sie gespeichert werden
(Option <em>sha512</em>),

<item>aktiviert die Überprüfung der Komplexität eines Passworts, wie
sie in der Handbuchseite <manref name="pam_unix" section="8"> beschrieben
wird (Option <em>obscure</em>),

<item>erfordert, dass das Passwort mindestens acht Zeichen lang ist
(Option <em>min</em>).

</list>

<p>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.

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

<example>
  # 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
</example>

<p>Also, was macht diese Beschwörungsformel nun genau? Die erste Zeile lädt das
PAM-Modul cracklib, welches einen Passwort-Sicherheitscheck bereitstellt. Es
fragt nach einem neuen Passwort mit mindestens zwölf Zeichen
<footnote>
Die Option <em>minlen</em> ist nicht auf Anhieb völlig verständlich,
weil sie nicht die genaue Anzahl der Zeichen eines Passworts ist. Ein
Kompromiss zwischen Komplexität und Länge eines Passworts kann mit dem
Parameter »credit« für verschiedene Arten von Zeichen erreicht
werden. Weitere Informationen finden Sie in der
Handbuchseite <manref name="pam_cracklib" section="8">.
</footnote>,
einer Differenz von mindestens drei Zeichen zum alten Passwort und
erlaubt drei Versuche. Cracklib benötigt ein Paket mit Wörterlisten
(wie <package>wngerman</package>,
<package>wenglish</package>, <package>wspanish</package>, ...). Stellen Sie
also sicher, dass Sie ein passendes Paket für Ihre Sprache installiert
haben. Ansonsten ist cracklib nicht verwendbar.

<p>Die zweite Zeile (mit dem Module pam_unix.so) ist &ndash; wie oben
beschrieben &ndash; der Standard in Debian mit Ausnahme der
Option <em>use_authok</em>. 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.

<p>Weitere Informationen über die Konfiguration von Crackllib finden
Sie in der Handbuchseite <manref name="pam_cracklib" section="8"> und
dem
Artikel <url id="http://www.deer-run.com/~hal/sysadmin/pam_cracklib.html"
name="Linux Password Security with pam_cracklib"> von Hal Pomeranz.

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

<p>Als Alternative können Sie auch PAM-Module einsetzen, die eine
Zwei-Faktor-Authentifizierung verwenden, wie
z.B. <package>libpam-barada</package>,
<package>libpam-google-authenticator</package>, <package>libpam-oath</package>,
<package>libpam-otpw</package>, <package>libpam-poldi</package>,
<package>libpam-usb</package>
oder <package>libpam-yubico</package>. 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.

<p>Denken Sie daran, dass diese Einschränkungen alle Benutzer
betreffen <em>außer</em> Änderungen von Passwörtern, die der Benutzer
root vornimmt. Dieser kann unabhängig von den eingerichteten
Beschränkungen jedes Passwort (in Hinblick auf Länge oder Komplexität)
für sich oder andere Benutzer vergeben.

<sect2 id="pam-rootaccess">Die Kontrolle des Benutzerzugangs in PAM

<p>Um sicher zu stellen, dass sich der Benutzer Root nur an lokalen
Terminals anmelden kann, sollten Sie die folgende Zeile in
<file>/etc/pam.d/login</file> eingefügt werden:

<example>
  auth     requisite  pam_securetty.so
</example>

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

<sect2 id="pam-limits">Beschränkung der Benutzer in PAM

<p>Die folgende Zeile sollte in <file>/etc/pam.d/login</file>
aktiviert werden, um den Benutzern Grenzen ihrer Systemressourcen zu setzen.
<!-- SB 20050302: to set up user resource limits -->

<example>
  session  required   pam_limits.so
</example>

<p>Dies schränkt die Systemressourcen ein, die ein Benutzer nutzen darf (siehe
<ref id="user-limits">). 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.

<sect2 id="pam-su">Kontrolle von su in PAM

<p>Wenn Sie <prgn>su</prgn> 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
<prgn>su</prgn>en können sollen, zu dieser Gruppe. Fügen Sie
anschließend die folgende Zeile zu <file>/etc/pam.d/su/</file> hinzu:

<example>
  auth        requisite   pam_wheel.so group=wheel debug
</example>

<p>Dies stellt sicher, dass nur Personen aus der Gruppe "wheel"
<prgn>su</prgn> 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.

<p>Wenn Sie es nur bestimmten Nutzern erlauben wollen, sich bei einem
PAM-Dienst zu authentifizieren, ist dies sehr leicht zu erreichen, indem Sie
Dateien benutzen, in denen die Nutzer, denen es erlaubt ist, sich
einzuloggen (oder nicht), gespeichert sind. Stellen Sie sich vor, Sie
möchten lediglich dem Nutzer 'ref' erlauben, sich mittels <prgn>ssh</prgn>
einzuloggen. Sie schreiben ihn also in eine Datei
<file>/etc/ssh-users-allowed</file> und schreiben das Folgende in
<file>/etc/pam.d/ssh</file>:

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

<sect2 id="pam-temp">Temporäre Verzeichnisse in PAM

<p>Da es eine Reihe von Sicherheitslücken mit so genannten unsicheren temporären
Dateien zum Beispiel in thttpd (vgl. <url
id="http://www.debian.org/security/2005/dsa-883" name="DSA-883-1">) gab, lohnt es
sich, das Paket <package>libpam-tmpdir</package> zu installieren. Alles, was
Sie machen müssen, ist, Folgendes zu <file>/etc/pam.d/common-session</file>
hinzuzufügen:

<example>
 session    optional     pam_tmpdir.so
</example>

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

<sect2 id="pam-undefined">Konfiguration für sonstige PAM-Anwendungen

<p>Zuletzt, aber nicht am unwichtigsten, erstellen Sie
<file>/etc/pam.d/other</file> mit den folgenden Zeilen:

<example>
  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
</example>

<p>Diese Zeilen stellen für alle Anwendungen, die PAM
unterstützen, eine gute Standard-Konfiguration dar (Zugriff wird
standardmäßig verweigert).


<sect1 id="user-limits">Ressourcen-Nutzung limitieren: Die Datei
<file>limits.conf</file>

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

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

<p>Es gibt einen Weg, Ressourcen-Limits zu manchen
Shells hinzuzufügen (zum Beispiel hat <prgn>bash</prgn> <prgn>ulimit</prgn>,
siehe <manref section="1" name="bash">). Aber da nicht alle die gleichen
Limits zur Verfügung stellen, und da der Nutzer seine Shell
ändern kann (siehe <manref section="1" name="chsh">), ist es besser,
die Limits in den PAM-Modulen zu platzieren, da diese unabhängig von der
verwendeten Shell Anwendung finden und auch PAM-Module betreffen, die nicht
shellorientiert sind.

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

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

<p>Für gewöhnlich nehmen <file>login</file>, <file>ssh</file> und die
grafischen Sitzungsmanager (<file>gdm</file>, <file>kdm</file> und
<file>xdm</file>) Nutzerlimits in Anspruch, aber Sie sollte dies auch in
anderen Konfigurationsdateien für PAM wie für <file>cron</file> tun, um zu
verhindern, dass Systemdaemonen alle Systemressourcen aufbrauchen.

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

<p>Zum Beispiel nimmt die Konfiguration im Beispiel unten eine Begrenzung von
100 Prozessen für alle Nutzer vor (um <em>Fork-Bomben</em> 
<footnote>
Programme, die immer mehr Prozesse erzeugen, um so das System zum Absturz zu
bringen, d.Ü.
</footnote>
zu vermeiden) und eine Begrenzung auf 10MB Speicher pro Prozess und ein Limit
von 10 gleichzeitigen Logins. Benutzer in der Gruppe <tt>adm</tt> haben höhere
Begrenzungen und können Dateien mit einem Speicherabbild schreiben, wenn sie das
<!-- SB (20050421): "can produce core files if they want to" -->
wollen (es gibt also nur eine <em>weiche</em> Begrenzung).

<p>
<example>
*              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
</example>

<p>Dies könnten die Limits eines Standardnutzers (einschließlich der
Systemdaemonen) sein:

<example>
$ 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
</example>

<p>Und dies die Limits für einen Administrator:

<example>
$ 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
</example>

<p>Für mehr Informationen hierzu lesen Sie:
<list>

<item><url
id="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html"
name="PAM reference guide for available modules">

<item><url
id="http://www.samag.com/documents/s=1161/sam0009a/0009a.htm"
name="PAM configuration article">.

<item><url
id="http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html"
name="Seifried's Securing Linux Step by Step"> in dem <em>Limiting
users overview</em> Abschnitt.

<item><url id="http://seifried.org/lasg/users/" name="LASG"> in dem 
<em>Limiting and monitoring users</em> Abschnitt.

</list>


<sect1>Aktionen bei der Benutzeranmeldung: Editieren von
<file>/etc/login.defs</file>
<p>
Der nächste Schritt ist es, die grundlegende Konfiguration und die Aktionen bei
User-Login zu editieren. Beachten Sie, dass diese Datei kein Bestandteil der
PAM-Konfiguration ist. Sie ist eine Konfigurationsdatei, die von den Programmen
<tt>login</tt>- und <tt>su</tt> 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 <prgn>getty</prgn>, welches
auf der Konsole läuft und die anfängliche Loginaufforderung zu Verfügung
stellt, <em>ruft</em> <prgn>login</prgn> auf).

<example>
  FAILLOG_ENAB        yes
</example>

<p>Wenn Sie diese Variable einschalten, werden fehlgeschlagene Logins
protokolliert. Es ist wichtig, hier auf dem Laufendem zu bleiben, um
jemanden zu fassen, der eine Brute-Force-Attacke versucht.

<example>
  LOG_UNKFAIL_ENAB    no
</example>

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

<example>
  SYSLOG_SU_ENAB      yes
</example>

<p>Dies schaltet das Mitprotokollieren von <prgn>su</prgn>-Versuchen im
<file>Syslog</file> ein. Sehr wichtig auf ernsthaften Maschinen, aber beachten
Sie, dass dies auch die Privatsphäre verletzen kann.

<example>
  SYSLOG_SG_ENAB      yes
</example>

<p>Das gleiche wie bei <var>SYSLOG_SU_ENAB</var>, jedoch für das Programm
<prgn>sg</prgn>.

<example>
 ENCRYPT_METHOD  SHA512
</example>

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

<sect1>Aktionen bei der
Benutzeranmeldung: <file>/etc/pam.d/login</file> editieren

<p>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:

<example>
auth       optional   pam_faildelay.so  delay=3000000
</example>

<p>Wenn Sie den Wert von <em>delay</em> 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 <em>delay=10000000</em> zehn Sekunden warten, wenn sie das falsche
Passwort eingeben.

<p>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:

<example>
# auth       required   pam_issue.so issue=/etc/issue
</example>

<p>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 Umgebungen und nach der
jeweiligen Rechtsprechung notwendig sein. Um dies zu aktivieren,
müssen Sie nur die entsprechende Mitteilung in die
Datei <file>/etc/issue</file>
<footnote>Der Standardinhalt dieser Datei enthält Informationen über
das Betriebssystem und dessen Version, die Sie möglicherweise
unbekannten Benutzern nicht mitteilen möchten.</footnote> 
eintragen und das Kommentarzeichen in der Zeile
in <file>/etc/pam.d/login</file> entfernen, um das Modul pam_issue.so
zu aktivieren.

<p>In dieser Datei können Sie weitere Einstellungen vornehmen, welche
für Ihre Sicherheit relevant sein könnten, wie z.B.:

<list>

<item>Regeln erstellen, welcher Benutzer zu welchen Zeiten auf das
System zugreifen kann, indem Sie das Modul <em>pam_time.so</em>
aktivieren und <file>/etc/security/time.conf</file> entsprechend
konfigurieren (standardmäßig deaktiviert),

<item>den Anmeldevorgang so einrichten, dass Benutzerbeschränkungen,
die in <file>/etc/security/limits.conf</file> definiert sind,
verwendet werden (standardmäßig aktiviert),

<item>dem Benutzer Informationen über die vorangegangene Anmeldung
anzeigen (standardmäßig aktiviert),

<item>nach erfolgter Anmeldung dem Benutzer eine Nachricht
(<file>/etc/motd</file> und <file>/run/motd.dynamic</file>) anzeigen
(standardmäßig aktiviert).

</list>

<sect1>ftp einschränken: bearbeiten von <file>/etc/ftpusers</file>
<p>
Die Datei <file>/etc/ftpusers</file> enthält eine Liste von allen
Benutzern, denen es <em>nicht</em> 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.

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

<p>Folgender Befehl ist ein einfacher Weg, alle Systemkonten zu
<file>/etc/ftpusers</file> hinzuzufügen:

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


<sect1>Verwendung von su

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

<sect1>Verwendung von sudo

<p>
Das <prgn>sudo</prgn> erlaubt es dem Benutzer, ein definiertes Kommando
unter einer anderen Nutzeridentität auszuführen, sogar als
Root. Wenn der Nutzer zu <file>/etc/sudoers</file> hinzugefügt ist
und sich korrekt authentifiziert, ist er in der Lage, Kommandos, die in
<file>/etc/sudoers</file> definiert wurden, auszuführen.
Sicherheitsverletzungen, wie
ein inkorrektes Passwort oder der Versuch ein Programm auszuführen,
für das Ihre Rechte nicht ausreichen, werden protokolliert und an
Root gemailt.

<sect1>Administrativen Fernzugriff verweigern
<p>Sie sollten <file>/etc/security/access.conf</file> ebenfalls so
verändern, dass ein Login aus der Ferne in ein administratives Konto nicht
erlaubt wird. Auf diese Weise müssen die Nutzer das Programm <prgn>su</prgn>
(oder <prgn>sudo</prgn>) aufrufen, um Administratorenrechte zu bekommen, so
dass es immer eine nachprüfbare Spur gibt.

<p>Sie müssen die folgende Zeile zu Ihrer
<file>/etc/security/access.conf</file> hinzufügen, die
Debians Standardkonfigurationsdatei hat ein Beispiel auskommentiert:
<example>
   -:wheel:ALL EXCEPT LOCAL
</example>

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


<sect1 id="user-restrict">Den Nutzerzugang einschränken

<p>Manchmal werden Sie vielleicht denken, dass Sie einen Nutzer auf Ihrem
System erstellen müssen, um einen bestimmten Dienst (pop3 E-Mail
Server oder ftp) anzubieten. Bevor Sie dies tun, erinnern Sie sich zuerst
daran, dass die PAM Implementierung in Debian GNU/Linux Ihnen erlaubt,
Nutzer mit einer breiten Auswahl von externen Verzeichnisdiensten
(radius, ldap, etc.) zu bestätigen. Dies wird vom libpam-Paket
bewerkstelligt.

<p>Wenn Sie einen Nutzer anlegen müssen, und auf Ihr System aus der
Ferne zugegriffen werden kann, beachten Sie, dass es Nutzern
möglich sein wird, sich einzuloggen. Sie können dies beheben,
indem Sie diesen Nutzern eine Null (<file>/dev/null</file>) als Shell (sie
müsste in <file>/etc/shells</file> aufgelistet sein) zuweisen. Wenn Sie
den Nutzern erlauben wollen, auf das System zuzugreifen, aber ihre
Bewegungen einschränken wollen, können Sie
<file>/bin/rbash</file> benutzen. Dies hat das gleiche Ergebnis, wie wenn Sie
die <tt>-r</tt> Option der
<prgn>Bash</prgn> (<em>RESTRICTED SHELL</em>, siehe <manref name="bash"
section="1">) verwendet hätten. Beachten Sie bitte, dass sogar mit
einer beschränkten Shell ein Nutzer, der auf ein interaktives
Programm zugreifen kann (das ihm erlaubt, eine Subshell
auszuführen), diese Limitierung der Shell umgehen kann.

<p>Debian bietet zurzeit in seiner Unstable-Veröffentlichung (und wird es
vielleicht der nächsten Stable-Veröffentlichung hinzufügen) das
<file>pam_chroot</file>-Modul (in
<package>libpam-chroot</package>) an. Eine Alternative hierzu ist es, die
Dienste, die eine Fernanmeldung ermöglichen (<prgn>ssh</prgn> und
<prgn>telnet</prgn>), in einer <prgn>chroot</prgn>-Umgebung laufen zu lassen.
<footnote><package>libpam-chroot</package> wurden noch nicht vollständig
getestet. Es funktioniert mit <prgn>login</prgn>, aber es dürfte nicht leicht
sein, diese Umgebung für andere Programme einzurichten.</footnote>

<p>Wenn Sie einschränken wollen, <em>wann</em> ein Nutzer auf das
System zugreifen kann, müssen sie
<file>/etc/security/access.conf</file> an Ihre Bedürfnisse anpassen.

<p>Informationen, wie man Benutzer, die auf das System mittels dem
<prgn>ssh</prgn>-Dienst zugreifen, in eine <prgn>chroot</prgn>-Umgebung
einsperrt, wird in <ref id="chroot-ssh-env"> beschrieben.

<sect1>Überprüfen der Nutzer

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

<sect2>Überwachung von Ein- und Ausgabe mittels eines Skripts

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

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

<sect2>Die History-Datei der Shell benutzen

<p>Wenn Sie auswerten wollen, was die Benutzer in die Shell eingeben (aber
nicht was das Ergebnis ist), können Sie eine systemweite
<file>/etc/profile</file> so einrichten, dass alle Befehle in der
<tt>History</tt>-Datei (Verlaufsdatei) gespeichert werden. Die systemweite
Einstellung muss so eingerichtet werden, dass Benutzer die Auditmöglichkeit
nicht aus ihrer Shell entfernen können. Ob dies möglich ist, hängt von der Art
der Shell ab. Sie müssen also sicherstellen, dass alle Benutzer eine Shell
verwenden, die das unterstützt.</p>

<p>Für die Bash zum Beispiel könnte <file>/etc/profile</file> folgendermaßen
aufgebaut werden
<footnote>
Wenn HISTSIZE eine sehr große Zahl zugewiesen wird, kann dies bei einigen
Shells zu Problemen führen, da der Verlauf für jede Sitzung eines Nutzers im
Speicher abgelegt wird. Sie sind auf der sichereren Seite, wenn Sie HISTSIZE
auf einen ausreichend großen Wert setzen und eine Kopie der History-Datei des
Benutzers anlegen (falls Sie aus irgendwelchen Gründen den ganzen Verlauf von
einem Nutzer benötigen).
</footnote>
:

<example>
  HISTFILE=~/.bash_history
  HISTSIZE=10000
  HISTFILESIZE=999999
  # Don't let the users enter commands that are ignored
  # in the history file
  HISTIGNORE=""
  HISTCONTROL=""
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTFILESIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
  export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
</example>

<p>Damit dies funktioniert, dürfen die Nutzer nur Informationen zur
<file>.bash_history</file>-Datei hinzufügen. Sie müssen daher
<em>zusätzlich</em> die <em>append-only</em>-Option (nur-anfügen) mittels
des Programms <prgn>chattr</prgn> für die <file>.bash_history</file> aller
Nutzer setzen
<footnote>
Ohne das Append-Only-Flag wäre es den Nutzern möglich, den Inhalt des Verlaufs
zu löschen, indem sie <tt>> .bash_history</tt> ausführen.
</footnote>.

<p>Beachten Sie, dass Sie obige Konfiguration auch in <file>.profile</file> des
Benutzers eintragen können. Dann müssten Sie aber die Rechte korrekt vergeben,
so dass der Benutzer daran gehindert ist, diese Datei zu verändern. Dies
schließt ein, dass das Home-Verzeichnis der Benutzers diesem <em>nicht</em>
gehört (sonst könnte er die Datei einfach löschen). Gleichzeitig müsste ihm
ermöglicht werden, die Konfigurationsdatei <file>.profile</file> zu lesen und
in <file>.bash_history</file> zu schreiben. Falls Sie diesen Weg gehen wollen,
wäre es auch gut, das <em>immutable</em>-Flag (unveränderbar) für
<file>.profile</file> zu setzen (auch dazu verwenden Sie <prgn>chattr</prgn>).

<sect2>Vervollständigung der Nutzerüberwachung durch Accounting-Werkzeuge

<p>Die vorherigen Beispiele sind ein einfacher Weg, um die Überwachung von
Nutzern einzurichten. Sie eignen sich aber nicht unbedingt für komplexe Systeme
oder für solche, auf denen die Nutzer überhaupt keine (oder ausschließlich)
Shells am Laufen haben. Sollte dies der Fall sein, schauen Sie sich das Paket
<package>acct</package> an, das Werkzeuge zur Bilanzierung (accounting
utilities) enthält. Diese werden alle Kommandos, die ein Nutzer oder ein
Prozess auf dem System ausführt, auf die Kosten von Plattenplatz aufzeichnen.

<p>Wenn Sie diese Bilanzierung aktivieren, werden alle
Informationen über Prozesse und Nutzer unter
<file>/var/account/</file> gespeichert, genauer gesagt in
<file>pacct</file>. Das Accounting-Paket schließt
einige Werkzeuge (<prgn>sa</prgn>, <prgn>ac</prgn> und <prgn>lastcomm</prgn>)
zur Analyse dieser Daten ein.

<sect2>Andere Methoden zur Benutzerüberwachung 
<p>Wenn Sie wirklich paranoid sind und jedes Kommando des Nutzers
protokollieren wollen, könnten Sie den Quellcode der <prgn>Bash</prgn> so
ändern, dass sie alles, das der Nutzer eingibt in einer anderen Datei
ablegt. Oder Sie lassen <package>ttysnoop</package> ununterbrochen jedes neue
tty
<footnote>
Ttys werden für lokal Logins und entfernte Logins mit ssh und telnet erzeugt.
</footnote>
überwachen und die Ausgaben in einer Datei speichern. Ein anderes nützliches
Programm ist <package>snoopy</package> (vergleichen Sie auch <url
id="http://sourceforge.net/projects/snoopylogger/" name="the project page">).
Dies ist ein für den Nutzer transparentes Programm, das sich als eine
Bibliothek einhängt und eine Hülle um <var>execve()</var>-Aufrufe bildet. Jedes
ausgeführte Kommando wird im <prgn>syslogd</prgn> aufgezeichnet, indem die
<tt>authpriv</tt>-Möglichkeit benutzt wird (üblicherweise wird dies unter
<file>/var/log/auth.log</file> gespeichert).

<sect1>Nachprüfung der Nutzerprofile

<p>Wenn Sie <em>sehen</em> wollen, was Nutzer tatsächlich tun, wenn
sie sich beim System anmelden, können Sie die <file>wtmp</file>-Datenbank
benutzen, die alle Login-Informationen enthält. Diese Datei kann mit
verschiedenen Werkzeugen weiterverarbeitet werden, unter ihnen
<prgn>sac</prgn>, das ein Profil für jeden Nutzer ausgeben kann
und zeigt, in welchem Zeitfenster sie sich für gewöhnlich
auf dem System anmelden.

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

<sect1>umasks der Nutzer einstellen

<p>Abhängig von Ihren Richtlinien möchten Sie vielleicht
ändern, wie Nutzer Informationen teilen können. Dabei geht es um die
Standardrechte von neu erstellten Dateien.

<p>Wenn die Standardwerte von Debian für Ihr System zu großzügig sind, müssen
Sie die umask-Einstellungen für alle Shells ändern. Strengere
Umask-Einstellungen sind 027 (kein Zugriff der Gruppe <em>other</em> auf neue
Dateien, dazu zählen andere Benutzer auf dem System) oder 077 (kein Zugriff der
Mitglieder der Gruppe des Benutzers). Debian erzeugt
(standardmäßig<footnote>Wird in <file>/etc/adduser.conf</file> festgelegt
(USERGROUPS=yes). Sie ändern dieses Verhalten, wenn Sie den Wert auf no
setzen. Dies wird aber nicht empfohlen.</footnote>) für jeden Benutzer eine
eigene Gruppe, so dass das einzige Gruppenmitglied der Benutzer selbst
ist. Daher ergibt sich zwischen 027 und 077 kein Unterschied, da die
Benutzergruppe nur den Benutzer selbst enthält.

<p>Dies ändern Sie, indem Sie eine passende <tt>umask</tt> für alle Benutzer
einstellen. Dazu müssen Sie einen <prgn>umask</prgn>-Aufruf in den
Konfigurationsdateien aller Shells einfügen: <file>/etc/profile</file> (wird
von allen Shells beachtet, die kompatibel mit Bourne sind),
<file>/etc/csh.cshrc</file>, <file>/etc/csh.login</file>,
<file>/etc/zshrc</file> und wahrscheinlich noch ein paar andere (je nachdem,
welche Shells Sie auf Ihrem System installiert haben). Sie können auch die
<var>UMASK</var>-Einstellung in <file>/etc/login.defs</file> verändern. Von all
diesen Dateien erlangt die letzte, die von der Shell geladen wird, Vorrang. Die
Reihenfolge lautet: die Standard-System-Konfiguration für die Shell des
Benutzers (d.h. <file>/etc/profile</file> und andere systemweite
Konfigurationsdateien) und dann die Shell des Benutzers (seine
<file>~/.profile</file>) und <file>~/.bash_profile</file> etc.). Allerdings
können einige Shells mit dem <em>nologin</em>-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.

<p>Bei Anmeldungen, die von <prgn>login</prgn> Gebrauch machen, erhält die
UMASK-Festlegung in <file>/etc/login.defs</file> Vorrang vor allen anderen
Einstellungen. Dieser Wert wird aber nicht von Anwendungen des Benutzers
beachtet, die nicht <prgn>login</prgn> verwenden, wie z.B. solche, die durch
<prgn>su</prgn>, <prgn>cron</prgn> oder <prgn>ssh</prgn> ausgeführt werden.

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

<p>Beachten Sie allerdings, dass ein Nutzer seine <tt>umask</tt>-Einstellung
abändern kann, wenn er es möchte, um sie großzügiger
oder einschränkender zu machen, indem er seine Konfigurationsdateien verändert.

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

<example>
session    optional     pam_umask.so umask=077
</example>

<p>Zu guter Letzt sollte Sie in Betracht ziehen, die Standard-Umask von Root
(022, wird in <file>/root/.bashrc</file> 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. <file>/tmp</file>) ablegt und sie so dem Durchschnittsbenutzer zugänglich
macht.


<sect1>Nutzer Sicht/Zugriff limitieren

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

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

<list>

<item>einige Konfigurationsdateien unter <file>/etc</file>. Jedoch
werden Debians Standardrechte für sensible Dateien (die zum Beispiel
Passwörter enthalten könnten) den Zugriff auf kritische
Informationen verhindern. Um zu sehen, auf welche Dateien nur der Root-Benutzer zugreifen kann, führen Sie zum Beispiel <tt>find /etc -type f -a
-perm 600 -a -uid 0</tt> als Superuser aus.

<item>Ihre installierten Pakete. Indem man die
Paket-Datenbank und das <file>/usr/share/doc</file>-Verzeichnis ansieht,
oder indem man mit Hilfe der auf Ihrem System installierten Binaries und
Bibliotheken versucht zu raten.

<item>einige Protokolle unter <file>/var/log</file>. Beachten Sie, dass
auf einige Protokolle nur Root und die <tt>adm</tt>-Gruppe zugreifen kann
(versuchen Sie <tt>find /var/log -type f -a -perm 640</tt>). Manche
sind sogar ausschließlich für Root verfügbar (sehen Sie sich 
<tt>find /var/log -type f -a -perm 600 -a -uid 0</tt> an).

</list>


<p>Was kann ein Nutzer von Ihrem System sehen? Wahrscheinlich ziemlich
viele Sachen, versuchen Sie mal Folgendes (und jetzt tief durchatmen):
<example>
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null  
</example>

<p>Was Sie sehen, ist eine Liste von allen Dateien, die ein Nutzer
<em>einsehen</em> kann, und die Verzeichnisse, auf die er Zugriff hat.

<sect2 id="limit-user-perm">Begrenzung des Zugangs zu Informationen anderer
Nutzer

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

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

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

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

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

<p>Wenn Sie den Lesezugriff auf die Home-Verzeichnisse für die Welt verhindert,
sollten Sie beachten, dass dann Nutzer ihre persönlichen Webseiten nicht unter
<file>~/public_html</file> erstellen können, da der Webserver einen Teil des
Pfads nicht lesen kann &ndash; und zwar das <var>$HOME</var>-Verzeichnis. Wenn
Sie es
Nutzern erlauben wollen, ihre HTML-Seiten in ihrem <file>~/public_html</file>
zu veröffentlichen, sollten Sie <em>DIR_MODE</em> auf 0751 setzen. Das
ermöglicht dem Webserver Zugang zum <file>public_html</file>-Verzeichnis
<!--SB (20050304): Übersetzung von "the final <file>public_html</file>
directory"? Final=endgültig? --> 
(welches selber die Rechte 0755 haben sollte). So kann er den von den Nutzern
veröffentlichten Inhalt anbieten. Natürlich sprechen wir hier nur über die
Standardeinstellung. Benutzer können grundsätzlich die Rechte für ihre eigenen
Dateien nach ihrem Gutdünken vergeben. Oder Sie können die Dinge, die für das
Web bestimmt sind, in einem getrennten Ort ablegen, der kein Unterverzeichnis
vom <var>$HOME</var>-Verzeichnis des Nutzers ist.


<sect1 id="user-pwgen">Erstellen von Benutzerpasswörtern

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

<p><prgn>Passwd</prgn> 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 <prgn>adduser</prgn> mit der <tt>--disabled-login</tt>-Option
erstellen, und danach <prgn>usermod</prgn> oder <prgn>chpasswd</prgn>
<footnote>
<prgn>Chpasswd</prgn> kann keine MD5-Passwörter erzeugen. Daher muss ihm das
Passwort in verschlüsselter Form übergeben werden, bevor es mit der
<tt>-e</tt>-Option verwendet werden kann.
</footnote>
benutzen (beide Programme stammen aus dem <package>passwd</package>-Paket. Sie
haben sie also schon installiert). Wenn Sie lieber eine Datei verwenden, die
alle Informationen zur Erstellung von Nutzern als Batch-Prozess enthält, sind
Sie vielleicht mit <prgn>newusers</prgn> besser dran.


<sect1>Kontrolle der Benutzerpasswörter

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

<p>Ein Systemadministrator muss bei einer großen Anzahl von Nutzern überprüfen,
ob deren Passwörter mit den lokalen Sicherheitsmaßstäben in Einklang stehen. Und
wie überprüft man das? Indem man versucht, sie wie ein Angreifer zu knacken,
der Zugriff auf die gehashten Passwörter hat (also auf die Datei
<file>/etc/shadow</file>).

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


<sect1 id="idle-logoff">Ausloggen von untätigen Nutzern

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

<list>
<item>weil die Konsole des Benutzers vielleicht nicht verriegelt ist und damit
ein Eindringling darauf zugreifen kann.

<item>weil ein Angreifer an eine schon beendete Netzwerkverbindung anknüpfen
und Befehle an die entfernte Shell schicken kann (das ist ziemlich einfach,
wenn die entfernte Shell, wie bei <prgn>telnet</prgn>, nicht verschlüsselt
ist).
</list>

<p>In einige entfernte System wurde sogar schon durch ein untätiges (und
abgelöstes) <prgn>screen</prgn> eingedrungen.

<p>Die automatische Trennung von untätigen Benutzern ist gewöhnlich ein Teil
der lokalen Sicherheitsregeln, die durchgesetzt werden müssen. Es gibt mehrere
Wege, dies zu tun:

<list>
<item>Wenn die Shell des Benutzers die <prgn>Bash</prgn> ist, kann ein
Systemadministrator <tt>TMOUT</tt> einen Standardwert zuweisen (vergleich
<manref section="1" name="bash">). Das hat zur Folge, dass die Shell
automatisch entferne, untätige Nutzer ausloggt. Beachten Sie, dass der Wert mit
der <tt>-o</tt>-Option gesetzt werden muss. Ansonsten wäre es den Nutzern
möglich, ihn zu verändern (oder zu löschen).

<p>Installieren Sie <package>timeoutd</package> und konfigurieren Sie
<file>/etc/timeouts</file> passend zu Ihren lokalen Sicherheitsrichtlinien. Der
Daemon achtet auch untätige Nutzer und beendet ihre Shells gegebenenfalls.
<!-- FIXME : Does 'screen' prevent timeoutd from detecting idle time like
I think it does, or it was due to my tricks with ttysnoop -->

<item>Installieren Sie <package>autolog</package> und richten Sie es so ein,
dass es untätige Nutzer entfernt.
</list>

<p>Vorzugswürdige Methoden sind die Daemonen <prgn>timeoutd</prgn> und
<prgn>autolog</prgn>, da letzten Endes die Nutzer ihre Standardshell ändern
können oder zu einer anderen (unbeschränkten) Shell wechseln können, nachdem
sie ihre Standardshell gestartet haben.


<sect id="tcpwrappers">Die Nutzung von tcpwrappers 

<p>TCP-Wrapper (Schutzumschläge für TCP) wurden entwickelt,
als es noch keine echten Paketfilter gab, aber Zugangskontrollen
notwendig waren. Trotzdem sind sie immer noch hoch interessant und nützlich.
Ein TCP-Wrapper erlaubt Ihnen, einem Host oder einer
Domain einen Dienst anzubieten oder zu verweigern, und
standardmäßig Zugriff zu erlauben oder zu verweigern (das alles wird auf der
Anwendungsebene durchgeführt). Wenn Sie mehr Informationen haben möchten, sehen
Sie sich <manref name="hosts_access" section="5"> an.

<p>Viele der unter Debian installierten Dienste

<list>
<item>werden entweder durch den TCP-Wrapper Service (<file>tcpd</file>)
aufgerufen,
<item>oder wurden mit libwrapper (Bibliothek für TCP-Wrapper)
Unterstützung kompiliert.
</list>

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

<p>Um herauszufinden, welche Pakete TCP-Wrapper benutzen<footnote>Bei älteren
Veröffentlichungen von Debian sollte Sie Folgendes ausführen:
<example>
  $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
        sed 's/,libwrap0$//;s/^[[:space:]]\+//'
</example>
</footnote>, versuchen Sie Folgendes:

<example>
  $ apt-cache rdepends libwrap0
</example>

<p>Beachten Sie bitte Folgendes, wenn Sie <prgn>tcpchk</prgn> (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
<file>host.deny</file>- oder <file>host.allow</file>-Datei hinzufügen, wird
<prgn>tcpchk</prgn> Sie warnen, dass er sie nicht finden kann, da er sie nur in
<file>/etc/inetd.conf</file> sucht (die Handbuchseite ist an dieser Stelle nicht
sehr genau).

<p>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
<var>SPAWN</var>-Kommando <footnote>Beachten Sie hier die Schreibweise, da
<em>spawn</em> nicht funktionieren wird.</footnote> in
<file>/etc/hosts.deny</file> einzutragen, das immer dann eine Mail an Root
schickt, wenn ein Dienst abgewiesen wurde:

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

<p><em>Achtung</em>: 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.

<!--
# Could this example be more interesting? 
# It also relates to the next section (jfs)
#
# era: cf hosts_access(5) manual page,
# and why are you not using logger(1) here? (FIXME?)
#
#&lt;example&gt;
#ALL: ALL: SPAWN ( \
#  /usr/local/sbin/send_syslog %u %c %d )
#&lt;example&gt;

#  With send_syslog as:
##!/usr/bin/perl -w
#
#use Sys::Syslog qw(:DEFAULT setlogsock);
#
#$user=shift(@ARGV) || 'unknown';
#$host=shift(@ARGV) || 'unknown';
#$service=shift(@ARGV) || 'unknown';
#setlogsock('unix');
#openlog("alert",'', 'user');
#syslog('warning', 'Connection from %s at %s to %s blocked.', ($user, $host, $service) );
#closelog();
#
#exit 0;
-->


<sect id="log-alerts">Die Wichtigkeit von Logs und Alarmen

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

<p>Debian GNU/Linux stellt Werkzeuge zur Verfügung, die die Analyse von
Log-Dateien übernehmen. Am beachtenswertesten sind <package>swatch</package>
<footnote>Es gibt darüber einen ziemlich guten Artikel von <url
id="http://www.spitzner.net/swatch.html" name="Lance Spitzner">.
</footnote>,
<package>logcheck</package> oder <package>loganalysis</package> (alle
Pakete werden ein wenig Anpassung benötigen, um unnötige Dinge
aus den Reports zu entfernen). Wenn sich das System in Ihrer Nähe
befindet, könnte es nützlich sein, das System-Log auf einer
virtuellen Konsole auszugeben. Die ist nützlich, da Sie so (auch von
weiter weg oder im Vorbeigehen) sehen können, ob sich das System
richtig verhält. Debians <file>/etc/syslog.conf</file> wird mit
einer auskommentierten Standardkonfiguration ausgeliefert. Um diese Ausgabe
einzuschalten, entfernen Sie die Kommentarzeichen vor den entsprechenden Zeilen
und starten <prgn>syslog</prgn> neu (<tt>/etc/init.d/syslogd restart</tt>):

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

<p>Um die Logs farbig zu gestalten, sollten Sie einen Blick auf
<package>colorize</package>, <package>ccze</package> oder
<package>glark</package> werfen. Es gibt da noch eine Menge über die Analyse
von Logs zu sagen, das hier nicht behandelt werden kann. Eine gute Quelle für
weitere Informationen sind Bücher wie <url name="Security log
management: identifying patterns in the chaos"
id="http://books.google.com/books?id=UyktqN6GnWEC">. In jedem Fall
sind selbst automatische Werkzeuge dem besten Analysewerkzeug nicht
gewachsen: Ihrem Gehirn.

<!-- FIXME: Add information related to OSSEC, however
     it is currently not packaged for Debian

Information relevant for OSSEC :

- Web page: http://www.ossec.net/
- Ubuntu Guide: http://ubuntuforums.org/showthread.php?t=213445
- ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361954
  (Reason it is not currently packaged, as of, dic 2010 is because
  of a need of OpenSSL excemption)
     Point to the book: http://books.google.com/books?id=h37q2q3wvcUC
-->

<!-- FIXME: Check information on SHARP, the 'syslog heuristic analysis
and response program'.  The paper is at
id="http://www.csis.gvsu.edu/sharp/". Is it free software? packaged?
URL doesn't exist any more, but its archive on archive.org:
http://web.archive.org/web/20020816100838/http://www.csis.gvsu.edu/sharp/
http://web.archive.org/web/20020816100838/http://www.csis.gvsu.edu/sharp/sharp.ps
No download location is available.
-->


<sect1 id="custom-logcheck">Nutzung und Anpassung von <prgn>logcheck</prgn>

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

<p>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. <prgn>Logcheck</prgn> kann vollständig
angepasst werden, so dass es Mails über Ereignisse aus den Logs
sendet, die Ihrer Aufmerksamkeit bedürfen. Die Standard-Installation
umfasst Profile zum ignorieren von Ereignissen und Rechtswidrigkeiten
für drei unterschiedliche Setups (Workstation, Server und paranoid).
Das Debian-Paket umfasst die Konfigurationsdatei
<file>/etc/logcheck/logcheck.conf</file>, die vom Programm eingelesen
wird, und die definiert, an welchen Nutzer die Testergebnisse geschickt
werden sollen. Es stellt außerdem einen Weg für Pakete zur
Verfügung, um neue Regeln in folgenden Verzeichnisses zu erstellen:
<file>/etc/logcheck/cracking.d/_packagename_</file>
<file>/etc/logcheck/violations.d/_packagename_</file>,
<file>/etc/logcheck/violations.ignore.d/_packagename_</file>,
<file>/etc/logcheck/ignore.d.paranoid/_packagename_</file>,
<file>/etc/logcheck/ignore.d.server/_packagename_</file>, und
<file>/etc/logcheck/ignore.d.workstation/_packagename_</file>.
Leider benutzen das noch nicht viele Pakete. Wenn Sie ein Regelwerk
entwickelt haben, dass für andere Nutzer nützlich sein
könnte, schicken Sie bitte einen Fehlerbericht für das entsprechende
Paket (als ein <em>wishlist</em>-Fehler). Mehr Informationen finden Sie
unter <file>/usr/share/doc/logcheck/README.Debian</file>.

<p><prgn>logcheck</prgn> konfiguriert man am besten, indem man nach der
Installation seine Hauptkonfigurationsdatei
<file>/etc/logcheck/logcheck.conf</file> 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. <package>logcheck-database</package> hat drei Schwellenwerte mit
steigender Ausführlichkeit: Workstation (Arbeitsplatz), Server und
paranoid. "server" ist der Standardwert, "paranoid" wird nur für
Hochsicherheitsmaschinen empfohlen, auf denen so wenig Dienste wie möglich
laufen. "workstation" eignet sich für relativ geschützte, nicht kritische
Maschinen. Wenn Sie neue Log-Dateien hinzufügen wollen, müssen Sie diese nur zu
<file>/etc/logcheck/logcheck.logfiles</file> hinzufügen. Es ist für die
standardmäßige Sysloginstallation eingerichtet.

<p>Wenn Sie dies geschafft haben, sollten Sie die nächsten Tage/Wochen/Monate
die verschickten Mails überprüfen. Falls Sie Nachrichten finden, die Sie nicht
erhalten wollen, fügen Sie die regulären Ausdrücke (regular expressions,
vergleiche <manref name="regex" section="7"> und <manref name="egrep"
section="1">), die zu diesen Nachrichten passen, in
<file>/etc/logcheck/ignore.d.<var>reportlevel</var>/local</file> ein. Versuchen
Sie, dass der reguläre Ausdruck mit der gesamten Logzeile übereinstimmt. Details, wie man
Regeln schreibt, finden Sie in
<file>/usr/share/doc/logcheck-database/README.logcheck-database.gz</file>. Das
ist ein andauernder Prozess der Abstimmung. Wenn nur noch relevante Meldungen
verschickt werden, können Sie davon ausgehen, dass dieser Prozess beendet ist.
Beachten Sie, dass <prgn>logcheck</prgn>, selbst wenn er läuft, Ihnen keine
Mail schickt, wenn er nichts Relevantes auf Ihrem System findet (so bekommen
Sie höchstens eine Mail pro Woche, wenn Sie Glück haben).


<sect1>Konfiguration, wohin Alarmmeldungen geschickt werden

<p>Debian wird mit einer Standardkonfiguration für <tt>Syslog</tt> (in
<file>/etc/syslog.conf</file>) 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
<file>syslog.conf</file> und deren Dokumentation. Wenn Sie ein sicheres System
betreuen wollen, sollten Ihnen bekannt sein, wohin Log-Meldungen geschickt
werden, so dass sie nicht unbeachtet bleiben.

<p>Zum Beispiel ist es für viele Produktiv-Systeme sinnvoll, Meldungen auch auf
der Konsole auszugeben. Aber bei vielen solcher Systeme ist es sehr wichtig,
auch eine neue Maschine zu haben, die für die anderen als ein Loghost fungiert
(d.h. sie empfängt die Logs aller anderen Systeme).

<p>Sie sollten auch an Mails für Root denken, da viele
Sicherheits-Kontrollen (wie <package>snort</package>) ihre Alarme an die
Mailbox von Root senden. Diese Mailbox zeigt normalerweise auf den ersten
Nutzer, der auf dem System erstellt wurde (prüfen Sie dazu
<file>/etc/aliases</file>). Sorgen Sie dafür, dass Roots Mails
irgendwo hin geschickt werden, wo sie auch gelesen werden (lokal
oder ferngesteuert).

<p>Es gibt noch andere Accounts mit besonderer Funktion und andere Aliase auf
Ihrem System. Auf einem kleinen System ist es wohl am einfachsten,
sicherzustellen, dass alle Aliase auf den Root-Account zeigen, und dass
Mails an Root in das persönliche Postfach des System-Administrator
weiter geleitet werden.

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


<sect1>Nutzen eines Loghosts

<p>Ein Loghost ist ein Server, der die syslog-Daten über ein Netzwerk
sammelt. Wenn eine Ihrer Maschinen geknackt wird, kann der Eindringling seine
Spuren nicht verwischen, solange er den Loghost nicht ebenfalls geknackt
hat. Demzufolge muss der Loghost also besonders sicher sein.  Aus einer
Maschine einen Loghost zu machen, ist relativ einfach: Starten Sie den
<prgn>syslogd</prgn> einfach mit <tt>syslogd -r</tt>, und ein neuer Loghost ist
geboren. Um dies unter Debian dauerhaft zu machen, editieren Sie
<file>/etc/default/syslogd</file> und ändern Sie die Zeile

<!-- FIXME: The following could also be interesting -->
<!-- How to hide the logging server on the network i.e. by not giving -->
<!-- it an IP address and adding a static ARP entry on the hosts using -->
<!-- the remote syslog server (only if on the same hub); if the remote -->
<!-- syslog server would be on a separate network, the default gateway -->
<!-- should be configured accordingly. -->

<example>
SYSLOGD=""
</example>
in 
<example>
SYSLOGD="-r".
</example>

Als nächstes konfigurieren Sie die anderen Maschinen, Ihre Daten an
den Loghost zu senden. Fügen Sie einen Eintrag, ähnlich dem
folgenden, zu der <file>/etc/syslog.conf</file> hinzu:

<example>
  facility.level            @Ihr_Loghost
</example>

Schauen Sie in die Dokumentation, um zu erfahren, wodurch Sie
<em>facility</em> und <em>level</em> ersetzen können (Sie sollten
nicht wörtlich übernommen werden). Wenn Sie alles in der Ferne
mitprotokollieren wollen, schreiben Sie einfach:

<example>
  *.*                       @Ihr_Loghost
</example>

in Ihre <file>syslog.conf</file>. Sowohl lokal als auch entfernt
mitzuprotokollieren, ist die beste Lösung (ein Angreifer könnte davon
ausgehen, dass er seine Spuren verwischt hat, nachdem er die lokale
Log-Datei gelöscht hat). Für weitere Informationen sehen Sie sich die
Handbuch-Seiten <manref name="syslog" section="3">, <manref
name="syslogd" section="8"> und <manref name="syslog.conf" section="5"> an.


<sect1>Zugriffsrechte auf Log-Dateien

<p>Es ist nicht nur wichtig zu entscheiden, wie Warnungen genutzt werden,
sondern auch, wer hierauf Zugriff hat, d.h. wer Log-Dateien (falls Sie
nicht einen Log-Host verwenden) lesen oder verändern kann.
Sicherheits-Alarme, die ein Angreifer verändern oder abschalten
kann, sind im Falle eines Eindringens nicht viel wert. Außerdem sollten
Sie berücksichtigen, dass Log-Dateien einem Eindringling ziemlich viel
Informationen über Ihr System verraten, wenn er auf sie Zugriff hat.

<!--  It should be explained why after installation this is not
 already done, jfs -->

<p>Einige Zugriffsrechte auf Log-Dateien sind nach der Installation
nicht gerade perfekt (aber das hängt natürlich von Ihren
lokalen Sicherheitsmaßstäben ab). Zuerst einmal müssen
<file>/var/log/lastlog</file> und <file>/var/log/faillog</file> nicht
für normale Benutzer lesbar sein. In der <file>lastlog</file>-Datei können
Sie sehen, wer sich zuletzt angemeldet hat. In <file>faillog</file> befindet
sich  eine Zusammenfassung fehlgeschlagener Logins. Der Autor empfiehlt, die
Rechte von beiden auf 660 zu setzen (mit <prgn>chmod 660</prgn>). Werfen Sie
einen kurzen Blick auf Ihre Log-Dateien, und
entscheiden Sie sehr vorsichtig, welche Log-Dateien Sie les- oder
schreibbar für einen Nutzer mit einer anderen UID als 0 und einer
anderen Gruppe als »adm« oder »root« machen. Sie können dies sehr
leicht auf Ihrem System überprüfen:

<example>
  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (see to what users do files in /var/log belong)
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (see to what groups do files in /var/log belong)
  # find /var/log -perm +004
  (files which are readable by any user)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (files which belong to groups not root or adm)
</example>

<p>Um anzupassen, wie neue Log-Dateien erstellt werden, müssen Sie
wahrscheinlich das Programm anpassen, das sie erstellt. Wenn die
Log-Dateien rotiert werden, können Sie das Verhalten der Erstellung und
Rotation anpassen.

<!-- This is no longer true, check apache's logrotate
<p>
I want to emphasize that the apache log file permissions are really
screwed due to the fact that the apache user owns the apache log
files. If a user gets a shell with a back door in apache, they can
easily remove the logfiles.
-->

<!--
# This is quite personal, IMHO, since this is due to the fact that 
# root priviledges are dropped on startup. I prefer an attacker to erase
# a service's logfiles than to erase all of my system's logs. Anyhow, this
# can be improved by changing user permissions after rotation
-->


<sect id="kernel-patches">Den Kernel patchen

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

<list>
<item>Erkennung von Eindringlingen für Linux (<url id="http://www.lids.org"
name="Linux Intrusion Detection">, enthalten im Paket
<package>lids-2.2.19</package>). Dieser Kernelpatch erleichtert Ihnen, Ihr
Linuxsystem abzuhärten, indem er Ihnen ermöglicht, Prozesse einzuschränken, zu
verstecken und zu schützten, sogar vor Root. Er führt Fähigkeiten für eine
zwingende Zugangskontrolle ein.

<item><url id="http://trustees.sourceforge.net/" name="Linux Trustees"> (im
Paket <package>trustees</package>). Dieser Patch fügt
ein ordentliches, fortgeschrittenes Rechtemanagement Ihrem Linux-Kernel
hinzu. Besondere Objekte, die "trustees" (Treuhänder) genannt werden, sind mit
jeder Datei oder Verzeichnis verbunden. Sie werden im Speicher des Kernels
abgelegt und erlauben so eine schnelle Abfrage aller Rechte.

<item>NSA Enhanced Linux (im Paket <package>selinux</package>. Backports von
Paketen, die SElinux unterstützen, sind unter <url
id="http://selinux.alioth.debian.org/"> erhältlich. Weiterführende
Informationen können Sie auf der <url id="http://wiki.debian.org/SELinux"
name="SElinux in Debian Wiki Seite"> und auf <url
id="http://www.golden-gryphon.com/software/security/selinux.xhtml" name="Manoj
Srivastavas"> und <url id="http://www.coker.com.au/selinux/" name="Russell
Cookers'"> SElinux-Webseiten finden.

<item>Der <url id="http://people.redhat.com/mingo/exec-shield/"
name="Exec-Shield-Patch"> aus dem Paket
<package>kernel-patch-exec-shield</package>. Dieser Patch schützt vor einigen
Pufferüberläufen (stack smashing attacks).

<item>Der <url id="http://www.grsecurity.net/" name="Grsecurity-Patch"> aus den
Paketen <package>kernel-patch-2.4-grsecurity</package> und
<package>kernel-patch-grsecurity2</package>
<footnote>
Beachten Sie, dass ein Konflikt zwischen diesem Patch und den Patches besteht,
die schon im Quellpaket des Kernels 2.4 von Debian enthalten sind. Sie werden
den Vanilla-Kernel verwenden müssen. Dazu führen Sie folgende Schritte durch:
<example>
# apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
# tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
# cd kernel-source-2.4.22
# /usr/src/kernel-patches/all/2.4.22/unpatch/debian
</example>
<p>Für weitere Informationen siehe <url id="http://bugs.debian.org/194225"
name="#194225">, <url id="http://bugs.debian.org/199519" name="#199519">, <url
id="http://bugs.debian.org/206458" name="#206458">, <url
id="http://bugs.debian.org/203759" name="#203759">, <url
id="http://bugs.debian.org/204424" name="#204424">, <url
id="http://bugs.debian.org/210762" name="#210762">, <url
id="http://bugs.debian.org/211213" name="#211213"> und die <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200309/msg01133.html"
name="Diskussion auf debian-devel">.
</footnote>
verwirklicht Mandatory Access Control durch RBAC und stellt Schutz vor
Pufferüberläufen durch PaX, ACLs, Zufälligkeit im Netzwerk (um die Erkennung
von Spuren des OS zu erschweren) und <url
id="http://www.grsecurity.net/features.php" name="noch viele Features mehr">
zur Verfügung.

<item><package>kernel-patch-adamantix</package> bietet die Patches an, die für
die Debian-Distribution <url id="http://www.adamantix.org/" name="Adamantix">
entwickelt wurden. Dieser Patch für den Kernel 2.4.x führt einige
Sicherheitsfähigkeiten wie nichtausführbaren Speicher durch den Einsatz von
<url id="http://pageexec.virtualave.net/" name="PaX"> und Mandatory Access
Control auf Grundlage von <url id="http://www.rsbac.org/" name="RSBAC" >
ein. Andere Features sind <url name="der Random-PID-Patch"
id="http://www.vanheusden.com/Linux/sp/">, ein mit AES verschlüsseltes
Loop-Gerät, Unterstützung von MPPE und eine Zurückportierung von IPSEC v2.6.

<item><package>cryptoloop-source</package>. Dieser Patch erlaubt Ihnen, die
Fähigkeiten der Crypto-API des Kernels zu verwenden, um verschlüsselte
Dateisysteme mit dem Loopback-Gerät zu erstellen.

<item>Kernel-Unterstützung von IPSEC (im Paket
<package>kernel-patch-openswan</package>). Wenn Sie das IPsec-Protokoll mit
Linux verwenden wollen, benötigen Sie diesen Patch. Damit können Sie ziemlich
leicht VPNs erstellen, sogar mit Windows-Rechnern, da IPsec ein verbreiteter
Standard ist. IPsec-Fähigkeiten wurden in den Entwicklungskernel 2.5 eingefügt,
so dass dieses Feature standardmäßig im zukünftigen Kernel 2.6 enthalten sein
wird. Homepage: <url id="http://www.openswan.org">.

<em>FIXME</em>: Der neuste Kernel 2.4 in Debian enthält eine Rückeinbindung des
IPSEC-Codes aus 2.5. Kommentar dazu.

</list>

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

<list>

<item><url id="http://acl.bestbits.at/" name="POSIX Access Control Lists">
(ACLs, Listen zur Zugangskontrolle) für Linux im Paket
<package>kernel-patch-acl</package>. Dieser Kernelpatch
stellt Listen zur Zugangskontrolle zur Verfügung. Das ist eine fortgeschrittene
Methode, um den Zugang zu Dateien einzuschränken. Es ermöglicht Ihnen, den
Zugang zu Dateien und Verzeichnisses fein abzustimmen.

<item>Der Patch für den Linux-Kernel <url name="Openwall"
id="http://www.openwall.com/linux/"> von Solar Designer, der im Paket
<package>kernel-patch-2.2.18-openwall</package> enthalten ist. Er enthält eine
nützliche Anzahl von Beschränkungen des Kernels wie eingeschränkte Verweise,
FIFOs in <file>/tmp</file>, ein begrenztes <file>/proc</file>-Dateisystem,
besondere Handhabung von Dateideskriptoren, einen nichtausführbaren Bereich des
Stapelspeichers des Nutzers und andere Fähigkeiten. Hinweis: Dieser Patch ist
nur auf die Kernelversion 2.2 anwendbar, für 2.4 werden von Solar keine Pakete
angeboten.

<item><package>kernel-patch-int</package>. Auch dieser Patch fügt
kryptografische Fähigkeiten zum Linux-Kernel hinzu. Er war bis zu den
Debian-Releases bis Potato nützlich. Er funktioniert nicht mehr mit
Woody. Falls Sie Sarge oder eine neuere Version verwenden, sollten Sie einen
aktuelleren Kernel einsetzen, in dem diese Features bereits enthalten sind.

</list>

<!-- FIXME: Make the entries coherent: should the package names be links to the
relevant package pages? -->

<p>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 <url name="Arbeit-bedürfende und voraussichtliche Pakete"
id="http://www.de.debian.org/devel/wnpp/">.


<sect>Schutz vor Pufferüberläufen

<p><em>Pufferüberlauf</em> (buffer overflow) wird eine verbreitete Art von
Angriffen auf Software
<footnote>
Sie sind in der Tat so verbreitet, dass sie die Grundlage für 20% aller
gemeldeten Sicherheitsmängel pro Jahr darstellen, wie von <url
id="http://icat.nist.gov/icat.cfm?function=statistics" name="statistics from
ICAT's vulnerability database"> herausgefunden wurde.
</footnote>
genannt, die die unzureichende Überprüfung von Eingabegrenzen ausnutzen (ein
Programmierfehler, der häufig bei der Programmiersprache C auftritt), um durch
Programmeingaben Befehle auf der Maschine auszuführen. Diese Attacken über
Server, die auf Verbindungen warten, oder über lokal installierte Software, die
einem Nutzer größere Privilegien gewährt (<tt>setuid</tt> oder <tt>setgid</tt>)
kann zu einem kompromittierten System führen.

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

<list>

<item>Patchen Sie den Kernel, um das Ausführen des Stapelspeichers zu
verhindern. Sie können entweder Exec-Shield, OpenWall oder PaX (ist in den
Grsecurity- und Adamantixpatches enthalten) verwenden.

<item>Verbessern Sie den Quellcode, indem Sie Werkzeuge einsetzen, die Teile
finden, die zu dieser Verwundbarkeit führen könnten.

<item>Übersetzen Sie den Quellcode neu, um vernünftige Prüfungen einzuführen,
um Überläufe zu verhindern. Benutzen Sie dazu den <url
id="http://www.research.ibm.com/trl/projects/security/ssp/" name="Stack
Smashing Protector (SSP)"> Patch für GCC (der von <url
id="http://www.adamantix.org" name="Adamantix"> verwendet wird).

</list>

<p>Debian GNU/Linux liefert bis einschließlich der Release 3.0 Software, um
alle dieser Methoden bis auf den Schutz bei der Übersetzung des Quellcodes (das
wurde aber schon in <url id="http://bugs.debian.org/213994" name="Fehler
#213994"> nachgefragt) zu implementieren.

<p>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).

<p>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 <url name="Ausgabe 58"
id="http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz"> des
phrack-Magazins oder in COREs Advisory
<url id="http://online.securityfocus.com/archive/1/269246"
name="Multiple vulnerabilities in stack smashing protection technologies">
beschrieben.

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

<sect1>Kernelpatch zum Schutz vor Pufferüberläufen

<p>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 <package>kernel-patch-2.4-grsecurity</package> und im
Adamantix-Patch <package>kernel-patch-adamantix</package> enthalten) benutzen.
Für weitere Informationen zum Einsatz dieser Patches lesen Sie den Abschnitt
<ref id="kernel-patches">.

<sect1>Prüfprogramme für Pufferüberläufe

<p>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 <package>bfbtester</package> (einen
Überlauftester, der Programme per Brute-Force (durch Testen aller
Möglichkeiten) nach Überläufen der Kommandozeile und von Umgebungsvariablen
durchtestet) <!-- FIXME: Where is it? und <package>njamd</package> --> bereit. Andere interessante Pakete sind auch
<package>rats</package>, <package>pscan</package>, <package>flawfinder</package>
und <package>splint</package>.


<sect>Sichere Übertragung von Dateien

<p>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 <package>ssh</package> erreicht. Eine
andere Möglichkeit ist die Nutzung von <package>ftpd-ssl</package>,
einem ftp-Server der <em>Secure Socket Layer</em> benutzt, um
Übertragungen zu verschlüsseln.

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

<p>Beachten Sie, dass die Verwendung von <prgn>scp</prgn> den Nutzern Zugang
zum gesamten Dateisystem ermöglicht, es sei denn, dass es in eine
<prgn>chroot</prgn>-Umgebung eingesperrt ist, wie es in <ref id="ssh-chroot">
beschrieben wird. Wahrscheinlich sogar leichter (abhängig vom verwendeten
Daemon) kann auch der FTP in eine <prgn>chroot</prgn>-Umgebung eingesperrt
werden. Das wird in  <ref id="ftp-secure"> beschrieben. Falls Sie sich sorgen,
dass Nutzer Ihre lokalen Dateien durchsehen, und Sie verschlüsselte
Kommunikation wünschen, können Sie einen FTP-Daemon mit Unterstützung
für SSL einrichten oder FTP mit Klartext und VPN verbinden (siehe  <ref
id="vpn">.


<sect>Einschränkung und Kontrolle des Dateisystems

<sect1>Benutzung von Quotas

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

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

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

<list>
<item>Halten Sie die Quotas klein genug, so dass die Nutzer Ihre
Festplatte nicht aufzehren können.

<item>Halten Sie die Quotas groß genug, so dass Nutzer sich nicht
beschweren oder dass Ihr Mail-Quota Sie daran hindert, nach einer Weile
Mails anzunehmen.

<item>Nutzen Sie Quotas auf allen Bereichen, die Nutzer beschreiben
können, auf <file>/home</file> ebenso wie auf <file>/tmp</file>.

</list>

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

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

<!-- FIXME: How to check for quota support? What to tweak when
recompiling? -->

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

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

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

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


<sect1 id="ext2attr">Die für das ext2-Dateisystem spezifischen Attribute
(chattr/lsattr)
<!-- section last edited by Frédéric Schütz <schutz@mathgen.ch> -->

<p>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
<prgn>ls -l</prgn> angezeigt und können auch nicht mit <prgn>chmod</prgn>
geändert werden. Um sie zu verwalten, brauchen Sie zwei weitere Programme,
nämlich <prgn>lsattr</prgn> und <prgn>chattr</prgn> (im Paket
<package>e2fsprogs</package>). 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 <prgn>chattr</prgn>-Befehle in einem Skript zu speichern, damit Sie
sie später wieder zuweisen können, falls Sie ein Backup zurückspielen müssen.

<p>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:

<list>

<item>Das Attribut 'i' ('immutable', unveränderlich): Eine Datei mit diesem
Attribut kann weder verändert noch gelöscht oder umbenannt werden, nicht einmal
vom Superuser. Auch ein Link auf sie kann nicht angelegt werden.

<item>Das Attribut 'a' ('append', anfügen): Dieses Attribut hat den gleichen
Effekt für das Attribut immutable, allerdings mit der Ausnahme, dass Sie immer
noch die Datei im Anfügen-Modus öffnen können. Das bedeutet, dass Sie ihr immer
noch Inhalt hinzufügen, aber den vorhanden Inhalt nicht verändern
können. Dieses Attribut ist besonders für die Protokolldateien nützlich, die
unter <file>/var/log/</file> gespeichert werden. Beachten Sie aber, dass sie
durch Log-Rotations-Skripte manchmal verschoben werden.

</list>

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

<p>Es ist leicht einzusehen, wie das 'a' Attribut die Sicherheit verbessert,
indem es Programmen, die nicht vom Superuser ausgeführt werden, die Fähigkeit
einräumt, Daten hinzuzufügen, aber verhindert, dass älterer Inhalt verändert
wird. Dem gegenüber erscheint das 'i' Attribut uninteressanter. Schließlich
kann der Superuser ja schon die normalen Unix-Rechte verwenden, um den Zugang
zu Dateien einzuschränken. Und ein Angreifer, der Zugang zum Konto des
Superusers hat, könnte immer das Programm <prgn>chattr</prgn> benutzen, um die
Attribute zu entfernen. Ein solcher Eindringlich ist vielleicht zunächst
verwirrt, wenn er feststellt, dass er eine Datei nicht löschen kann. Aber Sie
sollten nicht davon ausgehen, dass er blind ist &ndash; immerhin hat er es geschafft,
in Ihr System einzudringen! Einige Handbücher (einschließlich früherer
Versionen dieses Dokuments) empfehlen, einfach die Programme
<prgn>chattr</prgn> und <prgn>lsattr</prgn> vom System zu entfernen, um die
Sicherheit zu erhöhen. Aber diese Strategie, die auch als "security by
obscurity" (Sicherheit durch Verschleierung) bekannt ist, sollte unter allen
Umständen vermieden werden, da sie ein falsches Gefühl von Sicherheit
vermittelt.

<p>Dieses Problem lösen Sie auf sichere Art und Weise, indem Sie die
Fähigkeiten des Linux-Kernel verwenden, wie es in <ref id="proactive">
beschrieben wird. Die hier interessante Fähigkeit heißt
<tt>CAP_LINUX_IMMUTABLE</tt>: Wenn Sie es vom Satz der Fähigkeiten entfernen
(indem Sie zum Beispiel den Befehl <tt>lcap CAP_LINUX_IMMUTABLE</tt> verwenden,
ist es nicht mehr möglich, irgendwelche 'a' oder 'i' Attribute auf Ihrem System
zu verändern, auch nicht dem Superuser! Ein vollständige Strategie könnte also
folgendermaßen aussehen:

<enumlist>
   <item>Vergeben Sie die Attribute 'a' und 'i' an von Ihnen gewünschte
   Dateien. 

   <item>Fügen Sie den Befehl <tt>lcap CAP_LINUX_IMMUTABLE</tt> einem der
   Skripten, die den Start des Systems steuern (startup scripts), hinzu.  
   <!--  Is there anything interesting in :
   http://lists.debian.org/debian-security/2001/debian-security-200107/msg00024.html
   -->

   <item>Setzen Sie das Attribut 'i' für dieses Skript, andere Startdateien
   und auch das Programm <prgn>lcap</prgn> selbst.

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


<sect1 id="check-integ">Prüfung der Integrität des Dateisystems

<p>Sind Sie sich sicher, dass <file>/bin/login</file> 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?

<p>Die einzige Methode einen gewissen Schutz dafür zu haben ist es,
die Dateien jede(n) Stunde/Tag/Monat (ich ziehe täglich vor) zu
prüfen, indem man deren aktuelle und alte MD5-Summe vergleicht. Zwei
unterschiedliche Dateien können keine gleichen MD5-Summen haben (die
MD5-Summe umfasst 128 Bits, so ist die Wahrscheinlichkeit, dass zwei
unterschiedliche Dateien eine gleiche MD5-Summe haben etwa 1 zu 3,4e3803).
So sind Sie sicher, solange niemand den Algorithmus gehackt hat, der die
MD5-Summen auf Ihrer Maschine erstellt. Dies ist, nun ja, extrem schwer
und sehr unwahrscheinlich. Sie sollten diese Überprüfung Ihrer
Programme als sehr wichtig ansehen.

<p>Weit verbreitete Tools hierfür
sind <package>sxid</package>, <package>aide</package> (Advanced Intrusion
Detection Environment, fortgeschrittene Umgebung zur Erkennung von
Eindringlingen), <package>tripwire</package>, <package>integrit</package> und
<package>samhain</package>.
Das Installieren von <prgn>debsums</prgn> 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 <ref id="periodic-integrity"> und <ref id="snapshot">.

<p>Sie benutzen vielleicht <prgn>locate</prgn>, um das gesamte Dateisystem zu
indizieren. Wenn das so ist, sollten Sie die Auswirkungen davon
berücksichtigen. Das Debianpaket <package>findutils</package> enthält
<prgn>locate</prgn>, das als Nutzer nobody läuft. Daher indiziert es nur
Dateien, die von jedermann eingesehen werden
können. Wenn Sie dieses Verhalten verändern, werden allerdings alle Orte von
Dateien für alle Nutzer sichtbar. Wenn Sie das gesamte Dateisystem indizieren
wollen (und nicht nur die Stückchen, die der Nutzer nobody sehen kann), können
Sie <prgn>locate</prgn> durch das Paket <package>slocate</package>
ersetzen. slocate wird als eine um Sicherheit erweiterte Version von GNU locate
bezeichnet, hat aber tatsächlich weitere Funktionen zum Auffinden von Dateien.
Wenn Sie <prgn>slocate</prgn> benutzen, sieht ein
Benutzer nur Dateien, auf die er auch Zugriff hat, während Sie 
Dateien und Verzeichnisse des gesamten Systems ausschließen können.
Das Paket <package>slocate</package> führt seinen Aktualisierungsprozess mit
höheren Rechten aus als
locate. Außerdem indiziert es jede Datei. Nutzern wird es dadurch ermöglicht,
schnell nach jeder Datei zu suchen, die sie sehen können. <prgn>slocate</prgn>
zeigt ihnen
keine neuen Dateien an; es filtert die Ausgabe auf Grundlage der UID.

<p>Sie sollten auch <package>bsign</package> oder <package>elfsign</package>
einsetzen. <package>elfsign</package> 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. <package>bsign</package> verwendet
GPG, <package>elfsign</package> benutzt PKI-(X.509)-Zertifikate (OpenSSL).


<sect1>Aufsetzen einer Überprüfung von setuid

<p>Das Debian-Paket <package>checksecurity</package> enthält einen
<prgn>Cron</prgn>-Job, der täglich in
<file>/etc/cron.daily/checksecurity</file> ausgeführt wird.
<footnote>
In älteren Veröffentlichungen war checksecurity in cron integriert und die
Datei hieß <file>/etc/cron.daily/standard</file>.
</footnote>.
Dieser <prgn>Cron</prgn>-Job führt das Skript
<prgn>/usr/sbin/checksecurity</prgn> aus, das Informationen über Änderungen
sichert.

<p>Das Standard-Verhalten sendet diese Informationen nicht an den
Superuser. Stattdessen erstellt es eine tägliche Kopie dieser
Änderungen unter <file>/var/log/setuid.changes</file>. Sie sollten
die Variable MAILTO (in <file>/etc/checksecurity.conf</file>) auf 'root'
setzen, damit diese Informationen an ihn gemailt werden. Sehen Sie sich auch
<manref name="checksecurity" section="8"> für weitere
Konfigurations-Informationen an.


<sect id="network-secure">Absicherung des Netzwerkzugangs

<p>FIXME: Mehr (für Debian spezifischer) Inhalt benötigt.

<sect1 id="kernel-conf">Konfiguration der Netzwerkfähigkeiten des Kernels

<p>Viele Fähigkeiten des Kernels können während des Betriebs verändert werden,
indem etwas an das <file>/proc</file>-Dateisystem geschickt wird, oder indem
<prgn>sysctl</prgn> benutzt wird. Wenn Sie <tt>/sbin/sysctl -A</tt> eingeben,
können Sie sehen, was Sie einstellen können und was die Optionen
sind. Veränderungen werden vorgenommen, indem <tt>/sbin/sysctl -w
variable=value</tt> ausgeführt wird (vergleiche <manref section="8"
name="sysctl">). Nur in seltenen Fällen müssen Sie hier etwas bearbeiten. Aber
auch hier können Sie die Sicherheit erhöhen. Zum Beispiel:

<example>
  net/ipv4/icmp_echo_ignore_broadcasts = 1
</example>

<p>Dies ist ein <em>Windows Emulator</em>, 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.

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

<example>
  net/ipv4/icmp_echo_ignore_all = 1
</example>

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

<example>
  /proc/sys/net/ipv4/conf/all/log_martians = 1
</example>

<p>Für weiterführende Informationen dazu, welche Sachen mit
<file>/proc/sys/net/ipv4/*</file> angestellt werden können, sollten Sie
<file>/usr/src/linux/Documentation/filesystems/proc.txt</file> lesen. Alle
Optionen werden gründlich in
<file>/usr/src/linux/Documentation/networking/ip-sysctl.txt</file>
<footnote>
In Debian kopiert das Paket <package>kernel-source-<var>version</var></package> die Kernelquellen
nach <file>/usr/src/kernel-source-<var>version</var>.tar.bz2</file>. Ersetzen Sie einfach
<var>version</var> mit der installierten Kernelversion.
</footnote>
beschrieben.


<sect1 id="tcp-syncookies">Konfiguration von Syncookies

<p>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).
<!-- What does this mean? (jfs)
This option is quite dumb as it floods the
other side like it floods you, so the other side is also busy. 
-->

<example>
  net/ipv4/tcp_syncookies = 1
</example>

<p>Wenn Sie das dauerhaft für den Kernel festlegen wollen, müssen Sie in
<tt>/etc/network/options</tt> <tt>syncookies=yes</tt> festlegen. Jedes Mal, wenn
<tt>/etc/init.d/networking</tt> 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:

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

<p>Diese Option ist nur verfügbar, wenn der Kernel mit
<tt>CONFIG_SYNCOOKIES</tt> übersetzt wurde. Alle Kernel von Debian wurden mit
dieser Option kompiliert. Sie können das folgendermaßen überprüfen:
 
<example>
  $ sysctl -A |grep syncookies
  net/ipv4/tcp_syncookies = 1
</example>

<p>Weitere Informationen zu TCP-Syncookies finden Sie unter <url
id="http://cr.yp.to/syncookies.html">.


<sect1 id="net-harden">Absicherung des Netzwerks beim Hochfahren

<p>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.

<p>Tatsächlich gibt es zwei Möglichkeiten, Ihr Netzwerk beim Booten
einzurichten. Sie können entweder <file>/etc/sysctl.conf</file> konfigurieren
(siehe <manref section="5" name="sysctl.conf">) oder ein Skript einsetzen, das
beim Aktivieren der Netzwerkschnittstellen aufgerufen wird. Die erste
Möglichkeit wird auf alle Schnittstellen angewendet, die zweite erlaubt es
Ihnen, die Konfiguration für jede Schnittstelle separat zu wählen.

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

<example>
#
# /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
</example>

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

<example>
  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
</example>

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


<example>
#!/bin/sh -e
# Skriptname: /etc/network/interface-secure
#
# Verändert das Standardverhalten für alle Schnittstellen in einigen Bereichen,
# um vor TCP/IP-Spoofing und Angriffen zu schützen
#
# Wurde von Dariusz Puchalak beigesteuert
#
# Broadcast echo protection enabled
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# IP forwarding disabled
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding

# TCP syn cookies protection enabled
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Log strange packets (this includes spoofed packets, source routed packets,
# redirect packets) but be careful with this on heavy loaded web servers
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians

# Bad error message protection enabled
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
                                           
# IP spoofing protection
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# Disable ICMP redirect acceptance
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Disable source routed packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

exit 0
</example>

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

<example>
pre-up /etc/network/interface-secure $IFACE
</example>

<p>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:

<example>
#!/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 &lt;interface&gt;"
   exit 1
fi

if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
   echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)"
   exit 1
fi

# IP forwarding disabled
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding

# Log strange packets (this includes spoofed packets, source routed packets,
# redirect packets) but be careful with this on heavy loaded web servers
echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians

# IP spoofing protection
echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter

# Disable ICMP redirect acceptance
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects

# Disable source routed packets
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route

exit 0
</example>

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


<sect1 id="kernel-fw">Konfiguration der Firewall

<p>Um die Möglichkeiten einer Firewall zu haben, damit entweder das
lokale System oder andere <em>dahinter</em> 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 <prgn>ipchains</prgn> zur Verfügung. Der
Standardkernel von Debian 3.0 (Linux 2.4) enthält die
<em>stateful</em> Paketfilter-Firewall <prgn>iptables</prgn> (netfilter).

<p>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 <package>kernel-source-<var>X</var></package> können Sie auch die
Kernelquellen herunterladen und einen maßgeschneiderten
Kernel kompilieren, indem Sie <prgn>make-kpkg</prgn> aus dem Paket
<package>kernel-package</package>
benutzen.

<p>Auf das  Aufsetzen einer Firewall unter Debian wird unter <ref
id="firewall-setup"> ausführlich eingegangen.


<sect1 id="limit-bindaddr">Lösung des Problems der Weak-End-Hosts 
<!-- SB (20050306): "Disabling weak-end hosts issues" - Gibt's dafür eine
vernünftige Übersetzung? "Week-end host" wäre wohl "Kneipe" ;-) -->
 
<!-- FIXME I read this and I dont get what's the point? -->
 
<p>Auf Systemen mit mehr als einer Schnittstelle zu verschiedenen Netzwerken
können Dienste so eingerichtet werden, dass sie Verbindungen nur zu einer
bestimmte IP-Adresse zulassen. Normalerweise verhindert das Zugang zu diesen
Diensten, wenn an sie Anfragen über andere Adressen gestellt werden. Allerdings
bedeutet das nicht, dass der Dienst an eine bestimmte <em>Hardware</em>-Adresse
(Netzwerkkarte) gebunden ist (ein verbreiteter Irrtum).
<footnote>
Um das nachzuvollziehen folgendes Beispiel, das von Felix von Leitner auf der
Bugtraq-Mailingliste vorgestellt wurde:
<example>
   host a (eth0 connected to eth0 of host b):
     ifconfig eth0 10.0.0.1
     ifconfig eth1 23.0.0.1
     tcpserver -RHl localhost 23.0.0.1 8000 echo fnord

   host b:
     ifconfig eth0 10.0.0.2
     route add 23.0.0.1 gw 10.0.0.1
     telnet 23.0.0.1 8000
</example>
<p>Das scheint allerdings nicht mit Diensten zu funktionieren, die mit
127.0.0.1 verbunden sind. Sie sollten vielleicht für die Tests raw sockets
verwenden.
</footnote>

<p>Das ist kein Problem von ARP und auch keine Verletzung eines RFCs (es wird
in <url id="ftp://ftp.isi.edu/in-notes/rfc1122.txt" name="RFC1122">, Abschnitt
3.3.4.2 als <em>weak end host</em> bezeichnet). Vergessen Sie nicht, dass
IP-Adressen nichts mit dem physischen Schnittstellen zu tun haben.

<p>Im Kernel 2.2 (und davor) könnte dieses Problem so gelöst werden:
<example>
# 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
.....
</example>

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

<list>
<item>Regeln für iptables.
<item>Richtig konfiguriertes Routing.
<footnote>
Die Tatsache, dass dieses Verhalten durch Routing geändert werden kann, wurde
von Matthew G. Marsh in dem Bugtraq-Thread beschrieben:
<example>
  eth0 = 1.1.1.1/24
  eth1 = 2.2.2.2/24
  ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
  ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000
  ip route add default dev eth0 table 1
  ip route add default dev eth1 table 2
</example>
</footnote> Oder:
<item>Patchen des Kernels.
<footnote>
Wie im Bugtraq-Thread beschrieben, gibt es dafür einige Patches auf <url
id="http://www.linuxvirtualserver.org/~julian/#hidden"> und <url
id="http://www.fefe.de/linux-eth-forwarding.diff">.
</footnote>
</list>

<p>In diesem Text finden sich viele Fälle, in denen gezeigt wird, wie man
einige Dienste (sshd-Server, apache, Druckserver, ...) so konfiguriert, dass sie
nur auf einer bestimmten Adresse lauschen. Der Leser sollte in Betracht ziehen,
dass das den Zugang aus dem gleichen (lokalen) Netzwerk nicht verhindern kann,
wenn nicht die in diesem Abschnitt vorgeschlagenen Schritte ergriffen werden.
<footnote>
Ein Angreifer, der nicht in der gleichen Broadcast-Domain (also dem gleichen
Netzwerk) wie der angegriffene Host ist, kann auf viele Probleme bei Zugang
stoßen, nachdem die Anbindung der IP-Adressen konfiguriert wurde. Wenn der
Angriff über einen Router läuft, kann es sich als ziemlich schwer
herausstellen, die Antworten zurückzubekommen.
</footnote>

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

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


<sect1>Schutz vor ARP-Angriffen

<p>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.
 
<p>Wie Sie wissen, wird das ARP-Protokoll dazu verwendet, IP-Adressen mit
MAC-Adressen zu verknüpfen (für alle Details siehe <url name="RFC826"
id="ftp://ftp.isi.edu/in-notes/rfc826.txt">). 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 ...

<p>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
<prgn>arpspoof</prgn> aus dem Paket <package>dsniff</package> oder <url
name="arpoison" id="http://arpoison.sourceforge.net/">.

<p>Allerdings gibt es immer eine Lösung:

<list>

<item>Verwenden Sie einen statischen ARP-Speicher. So erstellen Sie "statische"
Einträge in Ihrem ARP-Speicher:
<example>
  arp -s host_name hdwr_addr 
</example> 
<p>Indem Sie statische Einträge für jeden wichtigen Host in Ihrem Netzwerk
vergeben, stellen Sie sicher, dass niemand einen (falschen) Eintrag für diese
Hosts erstellen oder verändern kann (statische Einträge verfallen nicht und
können nicht verändert werden). Auch gefälschte ARP-Antworten werden
ignoriert.

<item>Entdecken Sie verdächtigen ARP-Verkehr. Sie können dazu
<package>arpwatch</package>, <package>karpski</package> oder allgemeinere IDS,
die auch verdächtigen ARP-Verkehr entdecken können wie <package>snort</package>
oder <url name="prelude" id="http://www.prelude-ids.org">, einsetzen.

<item>Verwirklichen Sie einen IP-Filter, der die MAC-Adressen überprüft.

</list>


<sect id="snapshot">Einen Schnappschuss des Systems erstellen

<p>Bevor Sie das System in eine produktive Umgebung stellen, können
Sie einen Schnappschuss des gesamten Systems machen. Diesen
Schnappschuss können Sie im Falle einer Kompromittierung (siehe <ref
id="after-compromise">) benutzen. Sie sollten so einen Schnappschuss
immer dann erneuern, wenn Sie das System aktualisieren, insbesondere wenn Sie
auf eine neue Debian Release upgraden.

<p>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.

<p>Das folgende Skript erstellt einen solchen Schnappschuss:

<example>
#!/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 nicht md5sum finden. Breche ab."
	exit 1
fi
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Erstelle MD5-Datenbank"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
   find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
done
echo "MD5-Datenbank (nach der Installation) erstellt"
if [ ! -f /usr/bin/sha1sum ] ; then
	echo "Kann nicht sha1sum finden"
        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
</example>

<p>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 <ref
id="after-compromise"> an.

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

<list>

<item>Die Dateien mit den MD5-Summen enthalten die MD5-Summen aller
Dateien, die ein Debian-Paket enthält, nicht nur die der Systemprogramme. Das
hat zur Folge, dass diese Datenbank viel
größer ist (5 MB statt 600 KB auf einem Debian GNU/Linux System
mit grafischen Subsystem und etwa 2,5 GB Software installiert) und nicht auf
ein kleines, transportables Medium wie eine Diskette passt, aber wohl auf einen
tragbaren USB-Speicher.

<item>Nicht alle Debian-Pakete stellen MD5-Summen der installierten Dateien zur
Verfügung, da es (derzeit) nicht in der Richtlinie verlangt wird. Sie können
allerdings nach der Installation die MD5-Summen aller Pakete mit
<package>debsums</package> erstellen:
<example>
# debsums --generate=missing,keep
</example>

</list>

<p>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
<prgn>cron</prgn> die MD5-Summen des Systems mit Ihrem Schnappschuss zu
vergleichen.

<p>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 <ref
id="periodic-integrity">.


<sect>Andere Empfehlungen

<!-- TODO: Remove this? -->

<sect1>Benutzen Sie keine Software, die von svgalib abhängt

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

<!-- FIXME: Move this to policy section if there ever is one? -->
