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

<chapt id="sec-services">Absichern von Diensten, die auf Ihrem System
laufen

<p>Dienste können auf zwei Arten in einem laufenden System abgesichert werden:

<list>

<item>Sie so einstellen, dass auf sie nur von Zugangspunkten (Interfaces)
zugegriffen werden kann, von denen es nötig ist.

<item>Sie so konfigurieren, dass sie nur von legitimierten Nutzern auf
autorisierte Art und Weise benutzt werden können.

</list>

<p>Dienste können durch Zugriffsbeschränkungen auf Kernel-Ebene (durch eine
Firewall) eingeschränkt werden, so dass auf sie nur von bestimmten Orten aus
zugegriffen werden kann. Konfigurieren Sie sie,
so dass sie nur auf eine bestimmte Schnittstelle horchen (einige Dienste
bieten diese Fähigkeiten vielleicht nicht). Oder verwenden Sie eine andere
Methode, zum Beispiel den Linux-vserver-Patch (für 2.4.16),
mit dem Prozesse auf eine bestimmte Schnittstelle gebunden werden können.

<p>Was die Dienste angeht, die von <prgn>inetd</prgn> aufgerufen werden
(<prgn>telnet</prgn>, <prgn>ftp</prgn>, <prgn>finger</prgn>, <prgn>pop3</prgn>,
...), so ist es wert zu erwähnen, dass <prgn>inetd</prgn>
so konfiguriert werden kann, dass er nur auf eine bestimmte Schnittstelle
reagiert (unter Verwendung der <tt>service@ip</tt>-Syntax). Dies ist jedoch
eine nicht dokumentierte Eigenschaft.
Ein Ersatz, der
Meta-Daemon <prgn>xinetd</prgn>, kennt eine <tt>bind</tt>-Option nur für diesen Zweck. Lesen Sie dazu
bitte <manref name="xinetd.conf" section="5">.

<!-- FIXME: Avoid linewrap for server_args. I (Jens) think that += can be
 used to continue lines for server_args (not all key words support this). -->

<example>
service nntp
{
  socket_type  = stream
  protocol        = tcp
  wait            = no
  user            = news
  group           = news
  server          = /usr/bin/env
  server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
  bind            = 127.0.0.1
} 
</example>

<p>Die folgenden Abschnitte gehen detaillierter darauf ein, wie bestimmte
Dienste abhängig von der beabsichtigten Benutzung passend
konfiguriert werden.


<sect>Absichern von ssh
<p>Wenn Sie immer noch telnet statt ssh benutzen, sollten Sie dieses
Handbuch kurz beiseite legen, und dies ändern. Ssh sollte anstelle
von telnet für alle Fern-Logins benutzt werden. In einer Zeit, in
der es leicht ist, Internet-Verkehr mitzuschnüffeln und an
Klartext-Passwörter heranzukommen, sollten Sie lediglich Protokolle
verwenden, die Kryptographie benutzen. Also führen Sie sofort ein
<tt>apt-get install ssh</tt> auf Ihrem System aus.

<p>Ermuntern Sie alle Nutzer Ihres Systems, ssh anstelle von telnet zu
benutzen, oder noch besser: Deinstallieren Sie telnet/telnetd.
Zusätzlich sollten Sie es vermeiden, sich mit ssh als Root
einzuloggen und lieber andere Methoden benutzen, um Root zu werden. Wie
zum Beispiel <prgn>su</prgn> oder <prgn>sudo</prgn>. Schließlich sollten
Sie noch die Datei <file>/etc/ssh/sshd_config</file> für mehr
Sicherheit modifizieren:

<list>
<item><tt>ListenAddress 192.168.0.1</tt>
<p>Lassen Sie ssh nur auf eine bestimmte Schnittstelle hören, falls Sie
mehrere haben (und ssh nicht auf allen verfügbar sein
soll) oder Sie in Zukunft eine neue Netzwerkkarte einbauen werden (und
keine ssh-Verbindungen auf ihr erlauben wollen).

<item><tt>PermitRootLogin no</tt>
<p>Versuchen Sie so wenige Logins als Root wie möglich zu erlauben.
Wenn nun jemand Root werden will, benötigt er zwei Logins. So kann das
Root-Passwort nicht so leicht ausgetestet werden.

<item><tt>Port 666</tt> oder <tt>ListenAddress 192.168.0.1:666</tt>
<p>Verändern Sie den Listen-Port, so dass ein Eindringling nicht
wirklich sicher sein kann, ob ein sshd-Daemon läuft (aber beachten
Sie, dass dies lediglich »Sicherheit durch Verschleierung« ist).

<item><tt>PermitEmptyPasswords no</tt>
<p>Nicht gesetzte Passwörter verspotten jegliche System-Sicherheit.

<item><tt>AllowUsers alex ref ich@irgendwo</tt>
<p>Erlauben Sie nur bestimmten Nutzern sich via ssh auf der Maschine
einzuloggen. <tt>user@host</tt> kann auch verwendet werden, um einen
bestimmten Benutzer user dazu zu zwingen, nur von einem bestimmten
Rechner host aus zuzugreifen.

<item><tt>AllowGroups wheel admin</tt>
<p>Erlauben Sie nur bestimmten Gruppenmitgliedern sich via ssh auf der
Maschine einzuloggen. AllowGroups und AllowUsers haben äquivalente
Verfahrensweisen, um den Zugang zu der Maschine zu verwehren. Es wird nicht
überraschen, dass es sich hierbei um »DenyUsers« und »DenyGroups«
handelt.

<item><tt>PasswordAuthentication yes</tt>
<p>Es ist allein Ihre Wahl, was Sie hier eintragen. Es ist sicherer, Zugriff nur
Nutzern zu erlauben, die ssh-Schlüssel in der <file>~/.ssh/authorized_keys</file>-Datei
haben. Wenn Sie dies wollen, setzen Sie es auf »no«.
<!-- FIXME: What does this mean? Is it "more secure" to set this to
"no"? (era) --> <!-- jfs, IMHO yes since you place the key of the
incoming host in your server and the authentication is done against
the key. -->
<!-- Establishing trust between two hosts is always bad. For example, host A 
may log in directly on host B since the correct keys has been exchanged.
If host A gets cracked, the cracker/hacker/whatever now also get free access
to host B. (thomas) -->

<item>Schalten Sie jedwede Art der Authentifizierung ab, die Sie nicht
wirklich benötigen, zum Beispiel <tt>RhostsRSAAuthentication</tt>,
<tt>HostbasedAuthentication</tt>, <tt>KerberosAuthentication</tt> oder
<tt>RhostsAuthentication</tt>. Sie sollten sie abschalten, auch wenn sie
es standardmäßig bereits sind (siehe dazu die Handbuch-Seite
<manref name="sshd_config" section="5">).

<item><tt>Protocol 2</tt>
<p>Deaktivieren Sie die Protokollversion 1, da diese einige Designschwächen
hat, die es einfacher zu machen, Passwörter zu knacken. Für weitere Informationen
lesen Sie <url id="http://earthops.net/ssh-timing.pdf"
name="a paper regarding ssh protocol problems"> oder das 
<url id="http://xforce.iss.net/static/6449.php" name="Xforce advisory">.

<item><tt>Banner <file>/etc/<var>eine_Datei</var></file></tt>
<p>Fügen Sie einen Bannertext (er wird aus der Datei bezogen) für Benutzer,
die sich mit dem ssh-Server verbinden, hinzu. In einigen Ländern sollte das
Senden einer Warnung über unautorisierten Zugriff oder Benutzerüberwachung
vor dem Zugriff zu einem bestimmten System erfolgen, um sich rechtlich abzusichern.

</list>

<p>Sie können den Zugriff auf den ssh-Server auch mittels 
<tt>pam_listfile</tt> oder <tt>pam_wheel</tt> in der PAM-Kontrolldatei
beschränken. Zum Beispiel können Sie jeden abhalten, der nicht in der 
Datei <file>/etc/loginusers</file> aufgelistet ist, durch Hinzufügen
folgender Zeile zu <file>/etc/pam.d/ssh</file>:

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

<p>Abschließend beachten Sie bitte, dass diese Direktiven von einer
OpenSSH-Konfigurationsdatei stammen. Derzeit gibt es drei weit verbreitete
ssh-Daemonen: ssh1, ssh2 und OpenSSH von den OpenBSD-Leuten. Ssh1 war der
erste verfügbare ssh-Daemon und er ist noch der weit verbreitetste
(Gerüchten zufolge gibt es sogar eine Windows-Version). Ssh2 hat
gegenüber ssh1 viele Vorteile, abgesehen davon, dass es unter einer
unfreien Lizenz veröffentlicht wurde. OpenSSH ist ein völlig
freier ssh-Daemon, der sowohl ssh1 als auch ssh2 unterstützt.
OpenSSH ist die Version, die installiert wird, wenn Sie auf Debian das
Paket <package>ssh</package> auswählen.

<p>Mehr Informationen, wie Sie SSH mit Unterstützung für PAM
aufsetzen, finden Sie hier: <url
id="http://lists.debian.org/debian-security/2001/debian-security-200111/msg00395.html"
name="security mailing list archives">.


<sect1 id="ssh-chroot">SSH in ein Chroot-Gefängnis einsperren

<p>Zurzeit bietet OpenSSH keine Möglichkeit, automatisch Benutzer
bei der Verbindung in ein Chroot-Gefängnis einzusperren (die kommerzielle Version bietet diese
Funktionalität). Wie dem auch sei, es gibt auch ein Projekt, das diese
Funktionalität für OpenSSH anbietet, vergleiche <url
id="http://chrootssh.sourceforge.net">. Es ist aber aktuell noch nicht
für Debian paketiert. Sie sollten stattdessen das
<file>pam_chroot</file>-Modul, wie in in <ref
id="user-restrict"> beschrieben, verwenden.

<p>In <ref id="chroot-ssh-env"> können Sie verschiedene Optionen finden,
um Chroot-Umgebungen für SSH zu erstellen.

<sect1>Ssh-Clients

<p>Wenn Sie einen SSH-Client mit einem SSH-Server verwenden, müssen Sie
sicherstellen, dass er die selben Protokolle, die vom Server erzwungen werden,
unterstützt. Wenn Sie beispielsweise das Paket <package>mindterm</package>
verwenden, unterstützt dies nur Protokollversion 1. Jedoch ist der
sshd-Server standardmäßig so konfiguriert, nur Version 2 (aus
Sicherheitsgründen) zu akzeptieren.

<sect1>Verbieten von Dateitransfers

<p>Wenn Sie <em>nicht</em> möchten, das Benutzer Dateien zum und vom
ssh-Server übertragen, müssen Sie den Zugang zu <prgn>sftp-server</prgn>
<em>und</em> zu <prgn>scp</prgn> einschränken. Sie können dies für
<prgn>sftp-server</prgn> tun, indem Sie den korrekten <tt>Subsystem</tt>-Wert
in <file>/etc/ssh/sshd_config</file> eintragen.

<p>Sie können auch Benutzer mittels <package>libpam-chroot</package> in eine
Chroot-Umgebung einsperren, so dass sie, selbst wenn Dateitransfers erlaubt
sind, auf eine bestimmte Umgebung festgelegt sind, die keine Systemdateien
enthält.


<sect1 id="ssh-only-file">Beschränkung des Zugangs auf Dateitransfers

<p>Sie können den Zugang von Benutzern der Gestalt beschränken, dass sie nur
Dateien übertragen können, aber keine interaktive Shell erhalten. Dies können
Sie mit den folgenden Methoden erreichen:

<list>

<item>den Benutzern verbieten, sich auf dem ssh-Server einzuloggen (wie
oben beschrieben entweder durch die Konfigurationsdatei oder die
PAM-Konfiguration), oder

<item>den Benutzern nur eine eingeschränkte Shell wie
<package>scponly</package> oder <package>rssh</package> zuweisen. Diese Shells
schränken die Befehle ein, die den Benutzern zur Verfügung stehen, so dass sie
auf dem entfernten Rechner keine Befehle ausführen können.

</list>


<sect>Absichern von Squid

<p>Squid ist einer der verbreitetsten Proxy/Cache-Server und es gibt ein
paar Sicherheitsaspekte, die Sie beachten sollten. Squids Standard-Konfiguration
lehnt alle Anfragen von Benutzern ab. Dennoch erlaubt das Debian-Paket
Zugriff von 'localhost', Sie müssen nur Ihren Browser richtig konfigurieren.
Sie sollten Squid so
konfigurieren, dass er Zugriffe von vertrauenswürdigen Nutzern,
Computern oder Netzwerken erlaubt, indem Sie eine Zugriffs-Kontroll-Liste
(ACL, Access Control List) in <file>/etc/squid/squid.conf</file> definieren. Mehr
Informationen, wie Sie ACLs definieren, finden Sie im <url
name="Squid User's Guide"
id="http://www.deckle.co.za/squid-users-guide/Main_Page">.
Ein gute deutsche Dokumentation ist das <url name="Squid-Handbuch"
id="http://www.squid-handbuch.de/">.
Beachten Sie, dass Debian eine minimale Konfiguration für Squid bereitstellt,
die alles verhindert, mit der Ausnahme, dass <em>localhost</em> sich mit Ihrem
Proxy-Server (der standardmäßig mit dem Port 3128 läuft) verbinden kann.
Sie müssen Ihre <file>/etc/squid/squid.conf</file>-Datei wie gewünscht anpassen.
Die empfohlene minimale Konfiguration (mit dem Paket vertrieben) sieht wie
folgt aus:

<example>
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443 563     # https, snews
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 901         # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
(...)
# Erlaube nur cachemgr Zugriff von localhost
http_access allow manager localhost
http_access deny manager
# Erlaube nur purge Anfragen von localhost
http_access allow purge localhost
http_access deny purge
# Verbiete Anfragen zu unbekannten Ports
http_access deny !Safe_ports
# Verbiete CONNECT zu anderen als SSL-Ports
http_access deny CONNECT !SSL_ports
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
#Default:
# icp_access deny all
#
#Allow ICP queries from everyone
icp_access allow all
</example>

<p>Sie sollten Squid auch entsprechend Ihren System-Ressourcen konfigurieren,
inklusive Cache-Speicher (Option <tt>cache_mem</tt>), Lage der gecachten Dateien
und der verwendeten Speichermenge auf der Platte (Option <tt>cache_dir</tt>).

<p>Man beachte, dass es bei ungeeigneter Konfiguration vorkommen kann, dass jemand eine
Mail über Squid weiterleitet, da die Protokolle HTTP und SMTP
ein ähnliches Design haben. Squids Standardkonfiguration
verweigert Zugriffe auf Port 25. Wenn Sie Verbindungen an Port 25
erlauben wollen, fügen Sie ihn einfach zu der Safe_ports-Liste
hinzu. Aber dies ist <em>NICHT</em> empfohlen.

<p>Passendes Aufsetzen und Konfigurieren des Proxy/Cache-Servers ist nur
ein Teil der Absicherung Ihrer Seite. Eine andere notwendige Aufgabe ist
es, Squids Log-Dateien zu analysieren, um sicher zu gehen, dass alles so
arbeitet, wie es sollte. Es gibt ein paar Pakete in Debian GNU/Linux, die
einem Administrator hierbei helfen können.
Die folgenden Pakete sind in Debian 3.0 (Woody) und Debian 3.1 (Sarge)
verfügbar:

<list>
<item><package>calamaris</package> &ndash; Log-Datei-Analysator für Squid oder Oops-Proxy-Log-Dateien
<item><package>modlogan</package>  &ndash; ein modularer Log-Datei-Analysator
<item><package>sarg</package> &ndash; Squid Analysis Report Generator
<item><package>squidtaild</package> &ndash; Squid-Log-Beobachtungsprogramm
</list>

<p>Wenn Squid im »Accelerator Mode« betrieben wird, agiert er auch als
Web-Server. Aktivieren dieser Option erhöht die Komplexität des Codes, was
ihn weniger vertrauenswürdig macht. Standardmäßig ist Squid nicht dazu
konfiguriert, als Web-Server zu arbeiten, Sie müssen sich darüber also
keine Gedanken machen. Sie müssen sicher stellen, dass es wirklich nötig ist,
wenn Sie diese Eigenschaft nutzen wollen. Weitere Informationen über den
»Accelerator Mode« in Squid finden Sie im <url name="Squid User's Guide -
Accelerator Mode"
id="http://www.deckle.co.za/squid-users-guide/Accelerator_Mode">.


<sect id="ftp-secure">Absichern von FTP

<p>Wenn Sie wirklich FTP benutzen müssen (ohne ihn mit sslwrap zu
umhüllen oder innerhalb eines SSL- oder SSH-Tunnels), sollten Sie
ftp in das Home-Verzeichnis der FTP-Nutzer mit chroot einsperren, so dass sie
nichts anderes sehen können als ihr eigenes Verzeichnis. Andernfalls können
sie Ihr Root-Dateisystem durchlaufen, als hätten sie Shell-Zugriff darauf. Sie
können die folgende Zeile in Ihre <file>proftpd.conf</file>-Datei im
globalen Abschnitt hinzufügen, um die chroot-Fähigkeiten zu
nutzen:

<example>
DefaultRoot ~
</example>

<p>Starten Sie ProFTPd neu, indem Sie <tt>/etc/init.d/proftpd
restart</tt> eingeben, und prüfen Sie, ob Sie noch aus Ihrem
Home-Verzeichnis heraus kommen können.

<p>Um ProFTPd-DoS-Angriffe durch ../../../ zu verhindern, fügen Sie
die folgende Zeile Ihrer <file>/etc/proftpd.conf</file> hinzu:

<tt>DenyFilter \*.*/</tt>

<p>Vergessen Sie nicht, dass FTP Login- und Authentifizierungs-Passwort
als Klartext sendet (dies ist kein Problem, wenn Sie einen anonymen,
öffentlichen Dienst anbieten) und es gibt bessere Alternativen in
Debian hierzu. Zum Beispiel <prgn>sftp</prgn> (aus dem Paket
<package>ssh</package>). Es gibt auch freie
Implementierungen von SSH für andere Betriebssysteme, zum Beispiel
<url id="http://www.chiark.greenend.org.uk/~sgtatham/putty/"
name="putty"> oder <url id="http://www.cygwin.com" name="cygwin">.

<!-- Contributed by Jesus Climent -->
<p>Wenn Sie dennoch einen FTP-Server verwalten, während Sie
den Nutzern Zugriff via SSH gewähren, könnten Sie auf ein
typisches Problem stoßen. Benutzer, die innerhalb eines mit SSH
abgesicherten Systems auf einen anonymen FTP-Server zugreifen wollen,
können versuchen, sich auf dem <em>FTP-Server</em> einzuloggen.
Während der Zugriff verweigert werden wird, wird das Passwort
trotzdem als Klartext über das Netz gesendet. Um dies zu verhindern,
hat der ProFTPd-Entwickler TJ Saunders einen Patch erstellt, der
verhindert, dass Nutzer den anonymen FTP-Server mit gültigen
SSH-Zugangsdaten füttern. Mehr Informationen und den Patch finden
Sie unter: <url id="http://www.castaglia.org/proftpd/#Patches"
name="ProFTPD Patches">. Dieser Patch wurde auch an Debian gesandt,
vergleiche
<url id="http://bugs.debian.org/145669" name="Fehler #145669">.

<sect>Zugriff auf das X-Window-System absichern

<p>Heutzutage werden X-Terminals in immer mehr Firmen benutzt, wo
ein Server für viele Arbeitsplätze benötigt wird.
Dies kann gefährlich sein, weil Sie dem Datei-Server erlauben
müssen, sich mit den X-Clients zu verbinden (X-Server aus Sicht von
X. X vertauscht die Definition von Client und Server). Wenn Sie dem (sehr
schlechten) Vorschlag von vielen Dokumentationen folgen, geben Sie auf
Ihrer Maschine <tt>xhost +</tt> ein. Dies erlaubt jedem X-Client, sich mit
Ihrem System zu verbinden. Für etwas bessere Sicherheit können Sie
stattdessen das Kommando <tt>xhost +Rechnername</tt> verwenden, um den
Zugriff auf bestimmte Rechner zu begrenzen.

<p>Allerdings ist es eine viel sicherere Lösung, SSH zu benutzen, um
X zu tunneln und die gesamte Sitzung zu verschlüsseln. <!-- FIXME: Add "and compress" --> Dies
geschieht automatisch, wenn Sie sich auf eine andere Maschine
via ssh einloggen.

<!-- Sie müssen es nur in der <file>/etc/ssh/ssh_config</file>
einschalten, indem Sie <tt>X11Forwarding</tt> auf <tt>yes</tt> setzen.-->

Damit dies funktioniert, müssen Sie den ssh-Client und den
ssh-Server konfigurieren. Auf dem ssh-Client sollte <tt>ForwardX11</tt>
in <file>/etc/ssh/ssh_config</file> auf <tt>yes</tt> gesetzt sein. Auf dem
ssh-Server sollte <tt>X11Forwarding</tt> in
<file>/etc/ssh/sshd_config</file> auf <tt>yes</tt> gesetzt sein und das
Paket <package>xbase-clients</package> sollte installiert sein. Letzteres
liegt daran, dass der SSH-Server <file>/usr/X11R6/bin/xauth</file> (bei
Debian-Unstable (<file>/usr/bin/xauth</file>) verwendet, wenn er
das Pseudo-X-Display aufsetzt.
<!-- Discovered this when setting up two minimally installed boxes -->

In
den Zeiten von SSH sollten Sie die xhost-basierte Zugriffskontrolle
komplett über Bord werfen.
<!-- FIXME: Check. The text said "has to be disabled" [sic] -->

<p>Wenn Sie keinen X-Zugriff von anderen Maschinen benötigen, ist es für die
Sicherheit am besten, die Bindung auf dem TCP-Port 6000 abzuschalten, indem Sie
einfach Folgendes eingeben:

<example>
$ startx -- -nolisten tcp
</example>

<p>Dies ist das Standard-Verhalten unter XFree 4.1.0 (der Xserver aus
Debian 3.0 und 3.1). Wenn Sie XFree 3.3.6 laufen lassen (d.h. wenn Sie Debian 2.2
benutzen), können Sie <file>/etc/X11/xinit/xserverrc</file>
editieren, damit Sie etwas erhalten wie:

<example>
#!/bin/sh
exec /usr/bin/X11/X -dpi 100 -nolisten tcp
</example>

<p>Wenn Sie XDM benutzen, setzen Sie
<file>/etc/X11/xdm/Xservers</file> auf <tt>:0 local /usr/bin/X11/X vt7
-dpi 100 -nolisten tcp</tt>. Wenn Sie GDM benutzen, stellen Sie sicher,
dass die Option <tt>DisallowTCP=true</tt> in
<file>/etc/gdm/gdm.conf</file> eingetragen ist (was standardmäßig 
unter Debian der Fall ist). Dies wird grundsätzlich an jede X-Befehlszeile
<tt>-nolisten tcp</tt> anhängen
<footnote>
GDM wird  <tt>-nolisten tcp</tt> <em>nicht</em> anhängen, wenn es
<tt>-query</tt> oder <tt>-indirect</tt> in der Befehlszeile findet, da sonst
die Anfrage nicht funktionieren würde.
</footnote>.

<p>Sie können außerdem die standardmäßige Zeitgrenze für
die <prgn>xscreensaver</prgn>-Bildschirmsperre setzen. Auch wenn der Nutzer sie
aufheben kann, sollten Sie die Konfigurationsdatei
<file>/etc/X11/app-defaults/XScreenSaver</file> editieren, und die
lock-Zeile von
<example>
*lock:                  False
</example>
<p>(das ist der Standardwert unter Debian) auf
<example>
*lock:                  True
</example>
ändern.

<p>FIXME: Add information on how to disable the screensavers which
show the user desktop (which might have sensitive information).

<p>Lesen Sie mehr zur Sicherheit von X Window in
<url
name="XWindow-User-HOWTO"
id="http://www.tldp.org/HOWTO/XWindow-User-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz</file>).
<!-- TODO: Link zur deutschen Übersetzung -->


<p>FIXME: Add info on thread of debian-security on how to change config files
of XFree 3.3.6 to do this.  

<sect1>Überprüfen Ihres Display-Managers

<p>Wenn Sie einen Display-Manager lediglich zur lokalen Nutzung
(um einen schönen graphischen Login zu haben) haben wollen, gehen
Sie sicher, dass der XDMCP (X Display Manager Control Protocol) Krempel
abgeschaltet ist. Unter XDM können Sie dies mit der folgenden Zeile
in <tt>/etc/X11/xdm/xdm-config</tt> erreichen:

<example>
DisplayManager.requestPort:     0
</example>

<p>Für GDM müssen Sie in Ihre gdm.conf Folgendes eintragen:

<example>
[xdmcp]
Enable=false
</example>

<p>Normalerweise sind unter Debian alle Display-Manager so konfiguriert,
dass sie standardmäßig keine XDMCP-Dienste starten.


<sect>Absichern des Druckerzugriffs (die lpd- und lprng-Problematik)

<p>Stellen Sie sich vor, Sie kommen zur Arbeit, und der Drucker spuckt
endlose Mengen von Papier aus, weil jemand eine DoS-Attacke gegen Ihren Drucker-Daemon 
durchführt. Unangenehm, oder?

<!-- Info based on Dale Southard's post to debian-security April 11th 2002-->
<p>In jeder UNIX-Druck-Architektur muss es einen Weg geben, um die Daten
des Clients auf den Druck-Server zu bekommen. Traditionell machen dies
<prgn>lpr</prgn> und <prgn>lp</prgn> so, dass das Client-Kommando die
Daten in das Spool-Verzeichnis kopiert oder symbolisch verlinkt (weshalb diese
Programme normalerweise SUID oder SGID sind).

<p>Um jede Gefahr zu vermeiden, sollen Sie Ihren Druck-Server besonders
sicher halten. Dies heißt, dass Sie Ihren Druck-Dienst so konfigurieren
müssen, dass er nur Aufträge von vertrauenswürdigen
Rechnern annimmt. Hierzu müssen Sie die Rechner, von denen Sie
Druckaufträge entgegennehmen möchten, in die Datei
<file>/etc/hosts.lpd</file> eintragen.

<p>Allerdings akzeptiert der <prgn>lpr</prgn>-Daemon auch, wenn Sie dies
getan haben, Verbindungen auf Port 515 auf jeder Schnittstelle. Sie
sollten sich überlegen, ob Sie Verbindungen von Netzwerken/Rechnern,
die nicht drucken dürfen, mittels Firewall abblocken wollen (der
<prgn>lpr</prgn>-Daemon kann nicht so konfiguriert werden, dass er nur
auf eine bestimmte IP-Adresse hört).

<!-- FIXME
<p>Of course, you could also take the lpr/lprng sources
and change them so that the connect function is only done to "127.0.0.1".
apt-get source lpr
and patch the bind (finet) call
-->

<p>Sie sollten <prgn>Lprng</prgn> gegenüber <prgn>lpr</prgn>
vorziehen, da er so konfiguriert werden kann, dass er Zugangskontrolle
über IP beherrscht. Und Sie können spezifizieren, auf welche
Schnittstelle er sich binden soll (wenn auch etwas sonderbar).

<!-- FIXME: Ask Craig Small about his post in debian-private 19th October 2001 -->

<p>Wenn Sie Ihren Drucker nur lokal auf Ihrem System benutzen, werden Sie
diesen Dienst nicht über ein Netzwerk teilen wollen. Sie sollten dann
überlegen, ein anderes Druck-System, wie zum Beispiel das aus dem
Paket <package>cups</package> oder <url name="PDQ"
id="http://pdq.sourceforge.net/">, das auf den Zugriffsrechten des
Gerätes <file>/dev/lp0</file> beruht, einzusetzen.

<p>Bei <package>cups</package> werden die Druckaufträge mit dem
HTTP-Protokoll zum Server übertragen. Dadurch muss der Client nicht
über spezielle Privilegien verfügen, aber dies erfordert, dass der Server auf
irgendeinem Port lauscht.

<p>Wie auch immer: Wenn Sie <prgn>cups</prgn> nur lokal benutzen
möchten, können Sie ihn so konfigurieren, dass er nur auf die
lokale Schleife (loopback interface) hört, indem Sie Folgendes in
Ihrer <file>/etc/cups/cupsd.conf</file> ändern:

<example>
Listen 127.0.0.1:631
</example>

<p>Es gibt noch andere Sicherheitsoptionen in dieser
Konfigurationsdatei, wie zum Beispiel das Erlauben oder Verweigern von
Netzwerken oder Rechnern. Wenn Sie sie allerdings nicht benötigen,
belassen Sie es am besten dabei, einfach nur den Port, auf dem
gehört wird, einzuschränken. <prgn>Cups</prgn> liefert auch
Dokumentation über den HTTP-Port. Wenn Sie diese potenziell
nützlichen Informationen einem Angreifer von außerhalb nicht
enthüllen wollen (und der Port offen ist), fügen Sie
außerdem Folgendes hinzu:

<example>
&lt;Location /&gt;
 Order Deny,Allow
 Deny From All
 Allow From 127.0.0.1
&lt;/Location&gt;
</example>

<p>Die Konfigurationsdatei kann so angepasst werden, dass
zusätzliche Fähigkeiten einschließlich SSL- und
TLS-Zertifikate oder Verschlüsselung möglich werden. Die
Handbücher finden Sie unter http://localhost:631/ oder
<url id="http://cups.org">.

<P>FIXME: Add more content (the article on <url name="Amateur Fortress
Building" id="http://www.rootprompt.org"> provides some very
interesting views).  

<p>FIXME: Check if PDG is available in Debian, and if so,
suggest this as the preferred printing system.

<p>FIXME: Check if Farmer/Wietse has a replacement for printer daemon
and if it's available in Debian.

<sect>Absichern des Mail-Dienstes

<p>Wenn Ihr Server kein Mail-System ist, müssen Sie wirklich keinen
Mail-Daemon haben, der auf eingehende Verbindungen reagiert. Aber Sie
wollen lokale Mails ausliefern, um beispielsweise Mails an den
Root-User von irgendwelchen Alarmsystemen zu erhalten.

<p>Wenn Sie <prgn>exim</prgn> haben, müssen Sie den Daemon nicht
laufen lassen, um dies zu erreichen, da der Standard-<prgn>cron</prgn>-Job
die Mails abarbeitet. Sehen Sie in <ref id="disableserv"> wie man dies
erledigt.

<sect1>Konfiguration eines Nullmailers

<p>Sie mögen einen lokalen Mail-Daemon wollen, so dass er die Mails, die
vom lokalen Rechner zu einem anderen System geschickt wurden, versenden kann.
Dies ist üblich, wenn Sie eine Anzahl von Systemen zu administrieren haben
und nicht zu jedem von diesen eine Verbindung aufbauen wollen, um die dort
lokal verschickten Mails zu lesen. Genau wie all das Protokollieren eines
jeden individuellen Systems durch einen zentralen syslog-Server zentralisiert
werden kann, so kann auch Mail zu einem zentralen Mail-Server gesandt werden.

<p>Solch ein <em>nur sendendes</em> System sollte sorgfältig dafür
eingerichtet werden. Der Daemon kann ebenso konfiguriert werden, nur an der
Loopback-Adresse zu lauschen.

<p>Die folgenden Konfigurationsschritte müssen nur zur Konfiguration des
<package>exim</package>-Pakets in der Debian 3.0 Version vorgenommen werden.
Wenn Sie eine neuere Version verwenden (wie z.B. 3.1, das
<package>exim4</package> verwendet), so wurde das Installationssystem
verbessert, so dass, wenn der Mail-Transport-Agent konfiguriert wurde nur
lokale Mails zu versenden, es automatisch nur Verbindungen vom lokalen
Rechner und keine entfernten Verbindungen zulässt.

<p>In einem Debian 3.0 System mit <package>exim</package> muss man den
SMTP-Daemon aus <prgn>inetd</prgn> wie folgt entfernen:

<example>
$ update-inetd --disable smtp
</example>

<p>und den Mail-Daemon so konfigurieren, dass er nur auf die lokale
Schleife achtet. In <prgn>exim</prgn> (dem Standard-Mail-Transport-Agent (MTA) unter
Debian) tun Sie dies, indem Sie in der Datei
<file>/etc/exim.conf</file> die Zeile

<example>
local_interfaces = "127.0.0.1"
</example>

hinzufügen.

<p>Starten Sie beide Daemonen neu (inetd und exim) und exim wird
lediglich auf den Socket 127.0.0.1:25 lauschen. Seien Sie vorsichtig und
deaktivieren Sie erst inetd, oder exim wird nicht neu starten, da der
inetd-Daemon bereits eingehende Verbindungen behandelt.

<p>Bei <prgn>postfix</prgn> editieren Sie <file>/etc/postfix/main.conf</file>:

<example>
inet_interfaces = localhost
</example>

<p>Wenn Sie lediglich lokale Mails wollen, ist dieses Herangehen
besser als den Mailer-Daemon in einen tcp-Wrapper zu hüllen oder
Firewall-Regeln einzufügen, die den Zugang für alle limitieren.
Wenn Sie jedoch auch auf andere Schnittstellen reagieren
müssen, sollten Sie überlegen, ihn vom inetd aufrufen zu lassen
und einen tcp-Wrapper einzusetzen, so dass eingehende Verbindungen gegen 
<file>/etc/hosts.allow</file> und <file>/etc/hosts.deny</file>
geprüft werden. Außerdem werden Sie vor unautorisierten
Zugriffsversuchen gegen Ihren Mail-Daemon durch angemessenes
Protokollieren gewarnt werden wollen.

<p>In jedem Fall können Sie Mail-Zustellversuche auf dem SMTP-Level
ablehnen, indem Sie die <file>/etc/exim/exim.conf</file> abändern,
damit Sie Folgendes enthält:

<example>
receiver_verify = true
</example>

<p>Auch wenn Ihr Mail-Server keine Mails zustellen wird, ist diese
Konfiguration für den Relay-Tester auf <url
id="http://www.abuse.net/relay.html"> nötig, um festzustellen, dass
Ihr Server <em>nicht</em> relaisfähig ist.

<p>Wenn Sie Mails nur weiterleiten möchten, können Sie in Erwägung ziehen,
den Mail-Daemon durch Programme zu ersetzen, die <em>nur</em> zum
Weiterleiten der Mail zu einem entfernten Mail-Server konfiguriert werden
können. Debian stellt zurzeit <package>ssmtp</package> und
<package>nullmailer</package> für diese Zwecke zur Verfügung.
Auf jeden Fall können Sie für sich selbst alle von Debian angebotenen
Mail-Transport-Agents testen
<footnote>
Die Liste der in Debian verfügbaren Mail-Daemons erhalten Sie wie folgt:
<example>
$ apt-cache search mail-transport-agent
</example>
<p>Die Liste wird <prgn>qmail</prgn> nicht enthalten, da dies nur im
Quellcode im Paket <package>qmail-src</package> vertrieben wird.
</footnote>
und sehen, welcher davon am besten auf Ihr System zugeschnitten ist.

<sect1>Anbieten von sicherem Zugang zu Mailboxen

<p>Wenn Sie entfernten Zugriff auf Mailboxen erlauben wollen, gibt es eine
Anzahl von möglichen POP3- und IMAP-Daemonen.<footnote>
Eine Liste von Servern/Daemonen die diese Protokolle in Debian anbieten, kann
wie folgt erhalten werden:
<example>
$ apt-cache search pop3-server
$ apt-cache search imap-server
</example>
</footnote>
Wenn Sie IMAP-Zugriff anbieten, beachten Sie jedoch, dass es ein allgemeines
Dateizugriffsprotokoll ist. Es kann das Äquivalent zu einem Shell-Zugang
werden, da Benutzer in der Lage sein könnten, Zugang zu beliebigen Dateien
zu erhalten, auf die sie durch ihn zugreifen können.

<p>Versuchen Sie beispielsweise, <tt>{server.com}/etc/passwd</tt> als Ihren
Eingabepfad zu konfigurieren. Wenn dies gelingt, ist Ihr IMAP-Daemon nicht
richtig konfiguriert, um diese Art von Zugriff zu verhindern.

<p>Unter den IMAP-Servern in Debian vermeidet der <prgn>cyrus</prgn>-Server
(im Paket <package>cyrus-imapd</package>) dies, indem er den
gesamten Zugriff zu einer Datenbasis in einem beschränkten Teil des
Dateisystems limitiert. Auch <prgn>uw-imapd</prgn> (installieren Sie
entweder das <package>uw-imapd</package>- oder besser, wenn Ihre
IMAP-Clients es unterstützen, das <package>uw-imapd-ssl</package>-Paket)
kann konfiguriert werden, das Mailverzeichnis der Benutzer in ein
Chroot-Gefängnis einzusperren, dies ist jedoch nicht standardmäßig
aktiviert. Die angebotene Dokumentation enthält mehr Informationen, wie
man dies konfiguriert.

<p>Es ist ebenso empfehlenswert, einen IMAP-Server laufen zu haben, der
keine neuen Benutzer im lokalen System erfordert (dies würde auch einen
Shell-Zugang ermöglichen). Sowohl <package>courier-imap</package> (für IMAP)
und <package>courier-pop</package>, <package>teapop</package> (für POP3)
und <package>cyrus-imapd</package> (für POP3 und IMAP) bieten Server mit
Authentifizierungsmethoden neben den lokalen Benutzerkonten.
<prgn>cyrus</prgn> kann alle Authentifizierungsmethoden, die mittels PAM
konfiguriert werden können, verwenden, währenddessen <prgn>teapop</prgn>
Datenbanken (wie <package>postgresql</package> und
<package>mysql</package>) für die Benutzerauthentifizierung nutzen kann.


<p>FIXME: Check: <package>uw-imapd</package> might be configured with
user authentication through PAM too.

<sect1>Sicherer Empfang von Mails
<p>
Das Lesen und Empfangen von Mails ist das gebräuchlichste
Klartext-Protokoll. Wenn Sie POP3 oder IMAP benutzen, um Ihre Mails zu
erhalten, senden Sie ein Klartext-Passwort über das gesamte Netz, so
dass ziemlich jeder Ihre Mails von nun an lesen kann. Benutzen Sie
stattdessen SSL (Secure Sockets Layer), um Ihre Mails zu empfangen. Wenn Sie
einen Shell-Account auf dem Rechner, der als POP oder IMAP-Server agiert,
haben, ist die andere Alternative SSH. Hier ist eine beispielhafte
<file>fetchmailrc</file> um dies zu zeigen:

<example>
poll mein-imap-mailserver.org via "localhost"
with proto IMAP port 1236
user "ref" there with password "hackmich" is alex here warnings 3600
folders
.Mail/debian
preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
mein-imap-mailserver.org sleep 15 &lt;/dev/null &gt; /dev/null'
</example>

<p>Die wichtige Zeile ist die preconnect-Zeile. Sie startet eine
SSH-Verbindung und erstellt den notwendigen Tunnel, durch den automatisch
alle Verbindungen zum lokalen Port 1236 verschlüsselt an den
IMAP-Mail-Server weitergeleitet werden. Eine andere Möglichkeit
wäre es, <prgn>fetchmail</prgn> mit SSL-Unterstützung zu benutzen.

<p>Wenn Sie verschlüsselte Mail-Dienste wie POP oder IMAP anbieten
möchten, <tt>apt-get install stunnel</tt> und starten Sie Ihren
Daemon auf diese Weise:

<example>
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
</example>


<p>Dieses Kommando umhüllt den angegebenen Daemon (-l) an den Port
(-d) und nutzt ein bestimmtes SSL-Zertifikat (-p).


<sect id="sec-bind">Sichern von BIND

<p>Es gibt verschiedene Dinge, mit denen Sie sich auseinander setzen
sollten, um einen Domain-Server-Daemon abzusichern, die ähnlich zu
den Überlegungen sind, wie man einen anderen Dienst absichert:

<list>

<item>Konfigurieren Sie den Daemon selbst, so dass er von außen nicht
missbraucht werden kann (siehe auch <ref id="configure-bind">).
Dies schließt das Einschränken von
Abfragen durch Clients ein: Zonen-Transfers und rekursive Abfragen.

<item>Einschränken des Zugriffs des Daemon auf den Server
selbst, so dass dem Schaden für das System im Falle eines Einbruchs
Grenzen gesetzt sind. Hierzu gehört auch, den Daemon als
nicht-privilegierten Benutzer laufen zu lassen (siehe <ref id="user-bind">)
und ihn in ein Chroot-Gefängnis einzusperren (siehe <ref id="chroot-bind">).

</list>

<sect1 id="configure-bind">Bind-Konfiguration um Missbrauch zu verhindern 

<p>Sie sollten einige Informationen, die von außen über den DNS-Server abgefragt werden
können, zurückhalten, so dass man nicht wertvolle Informationen
über Ihre Organisation, die Sie nicht herausgeben wollen, abfragen
kann. Dies schließt die folgenden Optionen mit ein:
<em>allow-transfer</em>, <em>allow-query</em>, <em>allow-recursion</em>
und <em>version</em>. Sie können dies in dem globalen Abschnitt tun
(so wird es auf alle Zonen angewandt) oder jeweils pro Zone. Dies ist im
Paket <package>bind-doc</package> dokumentiert. Sobald das Paket
installiert ist, können Sie hierzu mehr in
<file>/usr/share/doc/bind/html/index.html</file> lesen.

<p>Stellen Sie sich vor, Ihr Server ist mit dem Internet und Ihrem
internen Netzwerk (Ihre interne IP ist 192.168.1.2) verbunden &ndash; ein
einfacher Server im heimischen Netzwerk. Sie möchten keinen Dienst
im Internet anbieten und lediglich DNS-Abfragen von Ihren internen Rechnern
erlauben. Sie können dies einschränken, indem Sie Folgendes in Ihre
<file>/etc/bind/named.conf</file> aufnehmen:

<example>
options {
            allow-query { 192.168.1/24; } ;
            allow-transfer { none; } ; 
            allow-recursion { 192.168.1/24; } ;
            listen-on { 192.168.1.2; } ;
            forward { only; } ;
            forwarders { A.B.C.D; } ;
};
</example>

<p>Die Option <em>listen-on</em> bewirkt, dass sich DNS nur auf die
Schnittstelle bindet, die die interne Adresse hat. Aber sogar wenn diese
Schnittstelle Verbindung zum Internet hat (zum Beispiel weil Sie NAT
benutzen), werden Abfragen nur akzeptiert, wenn sie von internen Hosts
kommen. Wenn das System mehrere Schnittstellen hat und Sie kein
<em>listen-on</em> gesetzt haben, könnten zwar nur interne Nutzer
Abfragen starten, aber, da der Port für Angreifer von außen
ansprechbar ist, könnten sie versuchen, den DNS zum Absturz zu bringen
(oder durch Speicher-Überlauf-Attacken auszunutzen). Sie
könnten ihn sogar dazu bringen, lediglich auf 127.0.0.1 zu
hören, wenn Sie den DNS-Service nicht für ein anderes System
anbieten wollen.
</p>

<p>Der version.bind-Eintrag in der chaos class enthält die Version
des derzeit laufenden Bind-Prozesses. Diese Information wird oft von
automatischen Scannern und bösartigen Individuen dazu verwendet
herauszufinden, ob ein <prgn>bind</prgn> für eine bestimmte Attacke verwundbar
ist. Indem Sie falsche oder gar keine Informationen im
version.bind-Eintrag zur Verfügung stellen, minimieren Sie die
Wahrscheinlichkeit, dass jemand Ihren Server aufgrund der publizierten
Version attackieren wird. Um Ihre eigene Version anzugeben, benutzen Sie
die <em>Version</em>-Direktive in der folgenden Art:
<example> options { ... verschiedene andere Optionen ...
version "Nicht verfuegbar."; }; </example>

<p>Das Ändern des version.bind-Eintrags schützt eigentlich
nicht gegen Attacken, aber Sie können es als sinnvolle
Schutzvorrichtung ansehen.
</p>

<p>Eine beispielhafte <file>named.conf</file>-Konfigurationsdatei
könnte so aussehen:

<example>
acl internal {
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // intern
        aa.bb.cc.dd;            // eth0 IP
};

acl friendly {
        ee.ff.gg.hh;            // slave DNS
        aa.bb.cc.dd;            // eth0 IP
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // intern
};

options {
        directory "/var/cache/bind";
        allow-query { internal; };
        allow-recursion { internal; };
        allow-transfer { none; };
};
// Ab hier bis zur meineseite.bogus Zone 
// ist alles im Grunde die unveränderte Debian-Standardeinstellung
logging {
        category lame-servers { null; };
        category cname { null; };   
};

zone "." {
        type hint;
        file "/etc/bind/db.root";
};

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

// Zone, die ich selbst hinzugefügt habe
zone "meineseite.bogus" {
        type master;
        file "/etc/bind/named.meineseite";
        allow-query { any; };
        allow-transfer { friendly; };
};
</example>

<P>Bitte prüfen Sie (erneut) die Debian-Fehler-Datenbank (BTS)
bezüglich Bind, insbesondere <url name="Bug #94760 (regarding ACLs
on zone transfers)" id="http://bugs.debian.org/94760">.  Fühlen Sie
sich ruhig dazu ermutigt, zu diesem Bugreport beizutragen, wenn Sie glauben, 
nützliche Informationen hinzufügen zu können.

<sect1 id="user-bind">Ändern des BIND-Benutzers

<p>Bezüglich der Beschränkung von BINDs Privilegien müssen
Sie beachten, dass, wenn Sie BIND als nicht-root Benutzer laufen lassen, BIND
neue Netzwerk-Schnittstellen nicht automatisch entdecken kann, zum Beispiel
wenn Sie eine PCMCIA-Karte in Ihr Notebook stecken. Lesen Sie die
Datei <file>README.Debian</file> in Ihrer named-Dokumentation
(<file>/usr/share/doc/bind/README.Debian</file>) für
mehr Informationen hierzu. Es gab in letzter Zeit viele Sicherheitsprobleme
mit BIND, so dass es nützlich ist, den Benutzer zu wechseln, wenn es
möglich ist. Wir werden die Schritte, die dazu nötig sind,
detailliert aufführen. Wenn Sie dies automatisch machen lassen wollen,
können Sie das Skript in <ref id="bind-chuser"> ausprobieren.

<p>Beachten Sie, dass dies nur auf die BIND-Version 8 zutrifft. In den
Debian-Paketen für die BIND-Version 9 wird der Benutzer <em>bind</em> erstellt
(seit Version 9.2.1-5, ist in <em>Sarge</em> enthalten) und mit der Variable
OPTIONS in <file>/etc/default/bind9</file> verwendet. Wenn Sie BIND 9 einsetzen
und Ihr Nameserver nicht als Benutzer <em>bind</em> läuft, sollten Sie die
Einstellungen in dieser Datei überprüfen.

<p>Um BIND unter einem anderen Benutzer laufen zu lassen, müssen Sie
zunächst einen zusätzlichen Benutzer und eine zusätzlich Gruppe dafür
erstellen (es ist <em>keine</em> gute Idee, für alle Dienste, die
Sie nicht als Root laufen lassen, den Benutzer nobody und die Gruppe nogroup
zu benutzen). In diesem Beispiel wird der Benutzer und die Gruppe
<tt>named</tt> verwendet. Sie können diese anlegen, indem Sie die
folgenden Kommandos eingeben:
<example>
addgroup named
adduser --system --home /home/named --no-create-home \ 
      --ingroup named --disabled-password --disabled-login named
</example>

<p>Beachten Sie, dass der Benutzer <tt>named</tt> sehr eingeschränkt
ist. Wenn Sie &ndash; aus welchen Gründen auch immer &ndash; ein weniger
eingeschränktes Setup haben möchten, benutzen Sie:
<example>
adduser --system --ingroup named named
</example>

<p>Editieren Sie nun <file>/etc/init.d/bind</file> mit Ihrem Lieblingseditor
und ändern Sie die Zeile, die mit 
<example>
start-stop-daemon --start
</example>

anfängt zu<footnote>Beachten Sie, dass Sie abhängig von Ihrer
Bind-Version die Option <tt>-g</tt> nicht haben, höchstwahrscheinlich
wenn Sie bind9 von Sarge (9.2.4) installiert haben.</footnote>:
<example>
start-stop-daemon --start --quiet \ 
--exec /usr/sbin/named -- -g named -u named
</example>

<p>Alternativ dazu können Sie auch die Standardkonfigurationsdatei (bei BIND 8
<file>/etc/default/bind</file>) bearbeiten (und erstellen, falls sie nicht
vorhanden ist) und Folgendes einfügen:

<example>
OPTIONS="-u named -g named"
</example>

<p>Ändern Sie die Rechte der Dateien, die von Bind verwendet werden, inklusive
<file>/etc/bind/rndc.key</file>:

<example>
-rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key
</example>

und wo bind seine PID-Datei erzeugt, z.B. indem Sie
<file>/var/run/named</file> anstatt von <file>/var/run</file> verwenden:

<example>
$ mkdir /var/run/named
$ chown named.named /var/run/named
$ vi /etc/named.conf
[ ... ändern Sie die Konfigurationsdatei, um diesen 
neuen Pfad zu verwenden ...]
options { ...
        pid-file "/var/run/named/named.pid";
};
[ ... ]
</example>

<p>Außerdem müssen Sie, um zu verhindern, dass irgendetwas als Root
läuft, im Init.d-Skript die <tt>reload</tt>-Zeile von:

<example>
reload)
       /usr/sbin/ndc reload
</example>

<p>in Folgendes ändern:
<example>
reload)
        $0 stop
        sleep 1
        $0 start
</example>

<p>Beachten Sie: Abhängig von Ihrer Debian-Version, müssen Sie
vielleicht auch die <tt>restart</tt>-Zeile ändern. Dies wurde in der
Version <tt>1:8.3.1-2</tt> von Debians BIND-Paket repariert.

<p>Alles, was Sie jetzt noch tun müssen, ist, bind mittels
<tt>/etc/init.d/bind restart</tt> neu zu starten und dann Ihr Syslog auf zwei
Einträge wie die folgenden zu prüfen:
<p>
<example>
Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named
</example>


<p>Voilà! Ihr named läuft <em>nicht mehr</em> als Root. Wenn Sie mehr
Informationen darüber lesen wollen, warum BIND nicht
als nicht-root Benutzer auf Debian-Systemen läuft, sehen Sie bitte in
der Fehlerdatenbank zu Bind nach, insbesondere <url name="Bug #50013:
bind should not run as root" id="http://bugs.debian.org/50013"> und
<url name="Bug #132582: Default install is potentially insecure"
id="http://bugs.debian.org/132582">,
<url name="Bug #53550" id="http://bugs.debian.org/53550">, 
<url name="Bug #52745" id="http://bugs.debian.org/52745"> und
<url name="Bug #128129" id="http://bugs.debian.org/128129">. 
Fühlen Sie sich ruhig dazu ermuntert, etwas zu den Fehlerbeschreibungen
beizutragen, wenn Sie denken, nützliche Informationen hinzufügen zu 
können.


<sect1 id="chroot-bind">Chroot-Gefängnis für Name-Server

<p>Um die größtmögliche BIND-Sicherheit zu erreichen,
müssen Sie nun ein Chroot-Gefängnis (siehe <ref id="chroot">)
um Ihren Daemon herum bauen. Es gibt einen einfachen Weg, dies zu
erreichen: Die Option <tt>-t</tt> (siehe die Handbuchseite <manref
name="named" section="8"> oder Seite 100 von
<url id="http://www.nominum.com/content/documents/bind9arm.pdf"
name="Bind's 9 Dokumentation (PDF)">). Dies wird Bind selbst in ein bestimmtes
Verzeichnis chrooten lassen, ohne dass Sie ein eigenes
Chroot-Gefängnis aufsetzen und sich Sorgen um dynamische
Bibliotheken machen müssen. Die einzigen Dateien, die in diesem
Chroot-Gefängnis benötigt werden, sind:

<example>
dev/null
etc/bind/       &ndash; sollte die named.conf und alle Server-Zonen 
                       enthalten
sbin/named-xfer &ndash; wenn Sie Namen transferieren
var/run/named/  &ndash; sollte die PID und den Cache des 
                           Name-Servers (falls es ihn gibt) enthalten.
                           Dieses Verzeichnis muss für
                           den named-User schreibbar sein.
var/log/named   &ndash; Wenn Sie in eine Datei protokollieren, muss 
                           dies für den named-User schreibbar sein.
dev/log       &ndash; syslogd sollte hierauf hören, wenn 
                  named so konfiguriert ist, dass er 
                  darüber protokolliert.
</example>

<p>Damit Ihr Bind-Daemon vernünftig läuft, braucht er bestimmte
Zugriffsrechte auf die named-Dateien. Dies ist eine einfache
Angelegenheit, da die Konfigurationsdateien immer in <tt>/etc/named/</tt>
liegen. Beachten Sie, dass er lediglich Lesezugriff benötigt, es
sei denn, es handelt sich um einen sekundären oder
zwischenspeichernden (Cache) Name-Server. Wenn dies der Fall ist, müssen Sie
ihm Lese- und Schreibzugriff auf die notwendigen Zonen gewähren (damit
Zonen-Transfers vom primären Server funktionieren).

<p>Mehr Informationen über das Chrooten von Bind finden Sie unter
<url name="Chroot-BIND-HOWTO"
id="http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html"> (betrifft Bind
9) und <url name="Chroot-BIND8-HOWTO"
id="http://www.tldp.org/HOWTO/Chroot-BIND8-HOWTO.html"> (betrifft
Bind 8). Diese Dokumente sollten auch nach der Installation des Paketes 
<package>doc-linux-text</package> (Text-Version) oder
<package>doc-linux-html</package> (HTML-Version) verfügbar sein. Ein
anderes nützliches Dokument ist <url
id="http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux">.

<p>Wenn Sie für Bind ein komplettes
Chroot-Gefängnis aufsetzen (d.h. Sie benutzen nicht nur <tt>-t</tt>),
stellen Sie sicher, dass Sie die folgenden Dateien darin haben:<footnote>
Diese Einstellungen wurden für die neueren Veröffentlichung von Bind noch nicht getestet.</footnote>

<!-- FIXME: This needs to be reviewed -->

<example>
dev/log &ndash;  syslogd sollte hierauf hören
dev/null
etc/bind/named.conf 
etc/localtime
etc/group &ndash; mit einer einzigen Zeile: "named:x:GID:"
etc/ld.so.cache &ndash; mit ldconfig erstellt   
lib/ld-2.3.6.so
lib/libc-2.3.6.so
lib/ld-linux.so.2 &ndash; symbolischer Link auf ld-2.3.6.so
lib/libc.so.6 &ndash; symbolischer Link auf libc-2.3.6.so
sbin/ldconfig &ndash; kann gelöscht werden, nachdem 
                       Chroot aufgesetzt wurde
sbin/named-xfer &ndash; wenn Sie Namen transferieren
var/run/
</example>

<p>Sorgen Sie auch dafür, dass <prgn>syslogd</prgn> auf
<tt>$CHROOT/dev/log</tt> achtet, so dass der Name-Server seine
syslog-Einträge in das lokale System-Protokoll schreiben lassen
kann.

<p>Wenn Sie Probleme mit dynamischen Bibliotheken vermeiden wollen,
können Sie Bind statisch kompilieren. Sie können hierzu
<prgn>apt-get</prgn> mit der <tt>source</tt> Option benutzen. Es kann
sogar die Pakete herunterladen, die Sie zum Kompilieren benötigen.
Sie müssten etwas ähnliches wie das Folgende tun:

<example>
$ apt-get source bind
# apt-get build-dep bind
$ cd bind-8.2.5-2
(editieren Sie src/port/linux/Makefile, so dass CFLAGS die Option
'-static' beinhaltet)
$ dpkg-buildpackage -rfakeroot -uc -us
$ cd ..
# dpkg -i bind-8.2.5-2*deb
</example>

<p>Nach der Installation werden Sie die Dateien in das Chroot-Gefängnis
verschieben müssen.<footnote>Es sei denn, Sie benutzen die
<tt>instdir</tt>-Option, wenn Sie <prgn>dpkg</prgn> aufrufen, aber dann
könnte das chroot-Gefängnis etwas komplizierter werden.</footnote> Sie
können die <tt>init.d</tt>-Skripte in <file>/etc/init.d</file>
lassen, so dass das System automatisch den Name-Server starten wird, aber
editieren Sie sie, indem Sie bei den <prgn>start-stop-daemon</prgn>-Aufrufen
in diesen Skripten <tt>--chroot /location_of_chroot</tt>
hinzufügen. Oder verwenden Sie für BIND die Option <em>-t</em>, indem Sie sie
in das OPTION-Argument in der Konfigurationsdatei
<file>/etc/default/bind</file> (für Version 8) oder
<file>/etc/default/bind9</file> (für Version 9) eintragen.

<p>Für weitere Informationen wie man Chroot-Gefängnisse aufsetzt,
siehe <ref id="chroot">.

<p>FIXME: Füge Informationen aus folgenden Quellen ein:
<url id="http://people.debian.org/~pzn/howto/chroot-bind.sh.txt">,
<!-- <url id="http://people.pdxlinux.org/~karlheg/"> (Bind9 in Debian),
not there any more. -->
<url id="http://www.cryptio.net/~ferlatte/config/"> (Debian-spezifisch),
<url id="http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html"> und 
<url id="http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm">.
<!-- Not available any more 
und
<url id="http://www.acmebw.com/papers/securing.pdf">. -->

<sect>Absichern von Apache

<p>FIXME: Add content: modules provided with the normal Apache installation
(under /usr/lib/apache/X.X/mod_*) and modules that can be installed 
separately in libapache-mod-XXX packages.

<p>Sie können den Zugriff auf Ihren Apache-Server einschränken,
wenn Sie ihn nur intern benutzen wollen (zum Beispiel zu Testzwecken,
oder um auf die <package>doc-central</package>-Archive zuzugreifen, etc.)
und nicht wollen, dass von außen auf ihn zugegriffen werden kann. Um
dies zu tun, benutzen Sie die <tt>Listen</tt> oder <tt>BindAddress</tt>
Direktiven in der Datei <file>/etc/apache/http.conf</file>.

<p>Benutzen von Listen:
<example>
Listen 127.0.0.1:80
</example>
<p>Benutzen von BindAddress:
<example>
BindAddress 127.0.0.1
</example>

<p>Starten Sie anschließend Apache mit <tt>/etc/init.d/apache
restart</tt> neu, und Sie werden sehen, dass er nur auf die lokale
Schleife achtet.

<p>In jedem Fall sollten Sie, wenn Sie nicht die ganze Funktionalität,
die Apache zur Verfügung stellt, benutzen wollen, mal einen Blick auf
die anderen Web-Server aus Debian werfen, zum Beispiel
<package>dhttpd</package>.

<p>Die <url name="Apache Documentation"
id="http://httpd.apache.org/docs/misc/security_tips.html"> stellt viele
Informationen zu Sicherheitsmaßnahmen, die Sie auf einem Apache
Web-Server anwenden können, bereit (die gleichen Informationen
erhalten Sie unter Debian auch durch das Paket
<package>apache-doc</package>).
<!-- Removed Jens: There was a FIXME in the past when this was missing, readd?
It can also be useful to read the 
<url name="Apache Security Configuration Document" 
id="http://www.intersectalliance.com/projects/ApacheConfig/index.html"> 
provided by <url name="InterSect Alliance" 
id="http://www.intersectalliance.com/">. -->

<p>Mehr Informationen zu weiteren Restriktionen von Apache durch Einrichten
chroot-Gefängnisses wird in <ref id="chroot-apache-env"> bereitgestellt.

<sect1>Verhindern, dass Benutzer Web-Inhalte veröffentlichen

<p>Die Standard-Apache-Installation in Debian erlaubt Benutzern Inhalt
unter <file>$HOME/public_html</file> bereitzustellen. Dieser Inhalt kann
aus aus der Ferne mit einer URL wie
http://Ihr_Apache_Server/~benutzer
abgegriffen werden.

<p>Wenn Sie dies nicht erlauben wollen, müssen Sie in der
Konfigurationsdatei <file>/etc/apache/http.conf</file> (von Apache 1.3)
folgendes Module auskommentieren:

<example>
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
</example>

<p>Wenn Sie Apache 2.0 verwenden, müssen Sie die Datei
<file>/etc/apache2/mods-enabled/userdir.load</file> entfernen oder die
Standardkonfiguration einschränken, indem Sie
<file>/etc/apache2/mods-enabled/userdir.conf</file> bearbeiten.

<p>Falls allerdings das Modul statisch verlinkt wurde (Sie können die Module,
die einkompiliert wurden,  mittels
<tt>apache -l</tt> überprüfen), müssen Sie das Folgende der Konfigurationsdatei
von Apache hinzufügen:

<example>
Userdir disabled
</example>

<p>Ein Angreifer kann immer noch die Benutzer herausfinden, da die Antwort
des Web-Servers <em>403 Permission Denied</em> und nicht
<em>404 Not available</em> lautet. Mit dem Rewrite-Modul können Sie das
verhindern.


<sect1>Rechte von Log-Datei

<p>Apache-Log-Dateien gehören seit 1.3.22-1 dem Benutzer 'root' und der
Gruppe 'adm' mit den Rechtebits 640. Diese Rechte ändern sich nach einer
Rotation. Ein Eindringling, der das System über den Web-Server erreicht hat,
kann so alte Log-Datei-Einträge nicht (ohne Rechteerweiterung) entfernen.

<!-- FIXME: What do you mean with "this permissions are changed after -->
<!-- rotation" -->


<sect1>Veröffentlichte Web-Dateien

<p>Apache-Dateien befinden sich unterhalb von <file>/var/www</file>. Direkt
nach der Installation bietet die Standardseite einige Informationen zu dem
System (hauptsächlich dass es ein Debian-System ist, auf welchem Apache
läuft). Die Standard-Webseiten gehören standardmäßig dem Benutzer root und
der Gruppe root, währenddessen der Apache-Prozess als Benutzer www-data und
Gruppe www-data läuft. Dies sollte es Angreifern, die in das System
durch den Web-Server eindringen, schwerer machen, die Site zu verunstalten.
Sie sollten natürlich die Standard-Webseiten (die Informationen, die Sie
der Außenwelt vorenthalten wollen, enthalten können) durch Ihre eigenen
ersetzen.


<sect>Absichern von Finger

<p>Wenn Sie den Finger-Dienst laufen lassen wollen, fragen Sie sich
bitte zuerst, ob Sie das auch wirklich tun müssen. Wenn Sie es müssen,
werden Sie feststellen, dass Debian viele Finger-Daemonen zur
Verfügung stellt (hier die Ausgabe von <prgn>apt-cache search
fingerd</prgn>):

<list>
<item>cfingerd &ndash; Konfigurierbarer finger-Daemon
<item>efingerd &ndash; ein weiterer Unix-finger-Daemon mit anpassbarer Ausgabe
<item>ffingerd &ndash; ein sicherer finger-Daemon
<item>fingerd &ndash; Remote-User-Informationsserver
<item>xfingerd &ndash; BSD-ähnlicher finger-Daemon mit qmail-Unterstützung
</list>
<p><package>ffingerd</package> ist der empfohlene finger-Daemon, wenn Sie
vorhaben, einen öffentlichen Dienst anzubieten. In jedem Fall sind
Sie dazu angespornt, wenn Sie ihn über inetd, xinetd oder tcpserver laufend
aufzusetzen: Schränken Sie die Anzahl der Prozesse die gleichzeitig
laufen dürfen ein. Schränken Sie den Zugriff auf den
Finger-Daemon von bestimmten Hosts ein (indem Sie tcp-wrapper benutzen)
und lassen Sie ihn nur auf die Schnittstellen lauschen, auf die er achten
muss.

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


<sect id="chroot">Allgemeine chroot- und suid-Paranoia

<p><prgn>chroot</prgn> ist eine der mächtigsten Möglichkeiten, einen
Daemon oder einen Benutzer oder einen anderen Dienst zu beschränken. Denken
Sie einfach an ein Gefängnis um Ihr Ziel, das das Ziel nicht verlassen kann
(normalerweise, es gibt aber einige Bedingungen, die einem einen Ausbruch
aus solch einem Gefängnis gestatten). Wenn Sie einem Benutzer oder einem
Dienst nicht trauen, können Sie eine modifizierte root-Umgebung für ihn
erzeugen. Dies kann einiges an Plattenplatz benötigen, da Sie alle benötigten
Programme ebenso wie Bibliotheken in das Gefängnis kopieren müssen. Aber danach
ist die Wirkung des Schadens, selbst wenn der Benutzer etwas bösartiges macht,
auf das Gefängnis beschränkt.

<!-- Consider removing this:
<p>A good example for this case is, if you do not authenticate against
<file>/etc/passwd</file> but use LDAP or MySQL instead. So your
ftp-daemon only needs a binary and perhaps a few libraries. A 
<prgn>chroot</prgn>ed environment would be an excellent security improvement; 
if a new exploit is found for this ftp-daemon, then attackers can only exploit
the UID of the ftp-daemon-user and nothing else. 
-->

<p>Viele Dienste, die als Daemonen laufen, können von dieser Vorgehensweise
profitieren. Die Daemonen, die Sie mit Ihrer Debian-Distribution installieren,
laufen jedoch nicht standardmäßig in einem chroot-Gefängnis.<footnote>Es wird
versucht, diese mit <em>minimalen Rechten</em> laufen zu lassen, was beinhaltet,
Daemonen unter ihren eigenen Benutzern, anstatt unter Root, laufen zu
lassen.</footnote></p>

<p>Dies beinhaltet: Name-Server (wie <prgn>bind</prgn>), Web-Server (wie
<prgn>apache</prgn>), Mail-Server (wie <prgn>sendmail</prgn>) und FTP-Server
(wie <prgn>wu-ftpd</prgn>). Wahrscheinlich ist es nur fair zu sagen, dass
die Komplexität von BIND der Grund dafür ist, warum er in den letzten Jahren
so oft für Attacken verwundbar war (vergleiche <ref id="sec-bind">).

<p>Jedoch bietet Debian einige Software an, die helfen kann,
<prgn>chroot</prgn>-Umgebungen aufzubauen. Sehen Sie <ref id="auto-chroot">.

<p>Wenn Sie irgendwelche Dienste in Ihrem System laufen lassen, sollten Sie
dies so sicher wie nur möglich tun. Dies beinhaltet: Entziehen von
root-Privilegien, Starten in beschränkten Umgebungen (wie ein
chroot-Gefängnis) oder Ersetzen durch ein sichereres Äquivalent.</p>

<p>Seien Sie jedoch gewarnt, dass aus einem <prgn>chroot</prgn>-Gefängnis
ausgebrochen werden kann, wenn der Benutzer, der im Inneren läuft, der 
Superuser ist. Sie müssen also sicherstellen, dass der Dienst als nicht
privilegierter Benutzer läuft. Durch Einschränken seiner Umgebung schränken
Sie die Welt-lesbaren/ausführbaren Dateien, auf die der Dienst zugreifen
kann, ein. Auf diese Weise limitieren Sie die Möglichkeiten einer
Rechteerweiterung durch lokale Sicherheitsverwundbarkeiten des Systems.
Selbst in dieser Situation können Sie nicht völlig sicher sein, dass es für
einen cleveren Angreifer keinen Weg gibt, irgendwie aus dem Gefängnis
auszubrechen. Verwenden von nur sicheren Server-Programmen, die einen guten
Ruf bezüglich Sicherheit haben, ist eine zusätzliche gute Sicherheitsmaßnahme.
Selbst kleinste Löcher wie offene Datei-Handle können von einem versierten
Angreifer zum Einbruch in das System verwendet werden. Schließlich war
<prgn>chroot</prgn> nicht als Sicherheitstool gedacht, sondern als ein
Testwerkzeug.</p>

<sect1 id="auto-chroot">Automatisches Erstellen von Chroot-Umgebungen

<p>Es gibt verschiedene Programme, um Server und Dienste automatisch in ein
Chroot-Gefängnis einzusperren. Debian bietet zurzeit (akzeptiert im Mai 2002)
Wietse Venemas <prgn>chrootuid</prgn> im Paket <package>chrootuid</package>,
ebenso wie <package>compartment</package> und <package>makejail</package>
an. Diese Programme können verwendet werden, um eine eingeschränkte Umgebung
zum Ausführen beliebiger Programme aufzusetzen
(<prgn>chrootuid</prgn> erlaubt es Ihnen sogar, es unter einem eingeschränkten
Benutzer laufen zu lassen). 

<p>Einige dieser Werkzeuge können verwendet werden, um das Chroot-Gefängnis
leicht aufzusetzen. Zum Beispiel kann das <prgn>makejail</prgn>-Programm ein
chroot-Gefängnis mit kurzen Konfigurationsdateien erzeugen und aktualisieren.
(Es bietet Beispielskonfigurationsdateien für <prgn>bind</prgn>,
<prgn>apache</prgn>, <prgn>postgresql</prgn> und <prgn>mysql</prgn>.) Es
versucht alle Dateien, die vom Daemon benötigt werden, mittels 
<prgn>strace</prgn>, <prgn>stat</prgn> und Debians Paketabhängigkeiten zu
bestimmen und in das Gefängnis zu installieren. Weitere Information gibt es
unter <url id="http://www.floc.net/makejail/">. <prgn>Jailer</prgn> ist ein
ähnliches Werkzeug und kann von <url
id="http://www.balabit.hu/downloads/jailer/"> heruntergeladen werden und ist
auch als Debian-Paket verfügbar.

<!-- FIXME: Site is down?
<p>Also useful to create chroots (or jails) is
<prgn>deb.pl</prgn>, a script that analyses dependencies of a
set of files.
-->

<sect>Allgemeine Klartextpasswort-Paranoia
<p>
Sie sollten versuchen, jeden Netzwerk-Dienst, der seine Passworte als
Klartext über das Netz sendet oder empfängt, wie zum Beispiel
FTP/Telnet/NIS/RPC, vermeiden. Der Autor empfiehlt jedem, ssh anstelle von
telnet und ftp zu verwenden.

<p>Vergessen Sie jedoch nicht, dass die Migration von telnet zu ssh die
Sicherheit in keinster Weise erhöht, wenn Sie weiterhin Klartext-Protokolle
verwenden. Am besten wäre es ftp, telnet, pop, imap und
http zu entfernen und durch ihre entsprechenden verschlüsselten
Dienste zu ersetzen. Sie sollten in Erwägung ziehen von diesen
Diensten zu deren SSL-Versionen zu wechseln: ftp-ssl, telnet-ssl,
pop-ssl, https, ...

<p>Die meisten der oben aufgelisteten Tipps gelten für jedes
Unix-System (Sie werden sie in jedem anderen sicherheitsrelevanten
Dokument, das Sie jemals lesen, wiederfinden, wenn es sich auf Linux und
andere Unices bezieht).

<sect>NIS deaktivieren

<p>Sie sollten, wenn möglich, nicht NIS, den Network Information
Service, benutzen, da er das gemeinsame Nutzen von Passwörtern erlaubt. Dies kann
sehr unsicher sein, wenn Ihr Setup fehlerhaft ist.

<p>Wenn Sie Passwörter zwischen verschiedenen Maschinen teilen
müssen, sollten Sie andere Alternativen in Erwägung ziehen. Zum
Beispiel können Sie einen LDAP-Server aufsetzen und PAM auf Ihrem
System so konfigurieren, dass es den LDAP-Server zur Benutzer-Authentifizierung
kontaktiert. Sie finden ein detailliertes Setup in dem
<url name="LDAP-HOWTO"
id="http://www.tldp.org/HOWTO/LDAP-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz</file>).

<p>Sie können mehr über NIS-Sicherheit in dem 
<url
name="NIS-HOWTO" id="http://www.tldp.org/HOWTO/NIS-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz</file>) lesen.

<p>FIXME (jfs): Add info on how to set this up in Debian.


<sect id="rpc">Sichern von RPC-Diensten

<p>Sie sollten RPC abschalten, wenn Sie es nicht benötigen.

<p>Remote Procedure Call (RPC, etwa »Entfernter Funktionsaufruf«) ist ein
Protokoll, das von Programmen verwendet werden kann, um Dienste von anderen
Programmen, die auf anderen Computern laufen, anzufordern.
Der <prgn>portmap</prgn>-Dienst kontrolliert RPC-Dienste durch Abbilden
von RPC-Programmnummern auf DARPA-Protokoll-Portnummern. Er muss laufen,
um RPC-Aufrufe ausführen zu können.

<p>RPC-basierte Dienste hatten eine unrühmliche Geschichte, was
Sicherheitslücken betrifft, obwohl dies für den Portmapper an sich nicht
gilt (dieser bietet aber nach wie vor entfernten Angreifern Informationen). 
Es ist zu beachten, dass einige DDoS-(distributed denial of service,
verteilte Dienstverweigerungen)-Angriffe RPC-Löcher benutzen,
um in das System einzudringen und als so genannter
Agent/Handler zu fungieren.

<p>Sie benötigen RPC nur dann, wenn Sie einen RPC-basierten Dienst verwenden.
Die bekanntesten RPC-basierten Dienste sind NFS (Network File System) und NIS
(Network Information System). Vergleichen Sie mit dem vorherigen Abschnitt
für weitere Information über NIS. Der File Alteration Monitor (FAM), der vom
Paket <package>fam</package> bereitgestellt wird, ist ebenso ein RPC-Dienst
und hängt deshalb von <package>portmap</package> ab.

<p>NFS-Dienste sind in einigen Netzwerken ziemlich wichtig. Wenn dies für
Sie der Fall ist, müssen Sie einen Ausgleich finden, zwischen Sicherheit
und Nutzbarkeit für Ihr Netzwerk. Sie können mehr über NFS-Sicherheit im
<url name="NFS-HOWTO"
id="http://www.tldp.org/HOWTO/NFS-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz</file>) finden.


<sect1>Vollständiges Deaktivieren von RPC-Diensten

<p>Das Abschalten von portmap ist relativ einfach. Es gibt
verschiedene Methoden. Die einfachste in einem Debian 3.0 oder neueren System ist
das Paket <package>portmap</package> zu deinstallieren. Wenn Sie
eine ältere Version von Debian laufen haben, werden Sie den Dienst, wie in
<ref id="disableserv"> beschrieben, abschalten müssen, weil
das Programm Teil des Pakets <package>netbase</package> (das
nicht deinstalliert werden kann, ohne das System kaputt zu machen) ist.

<p>Beachten Sie, dass einige Desktop-Umgebungen (hauptsächlich GNOME)
RPC-Dienste verwenden und den Portmapper für einige der
Dateimanager-Eigenschaften benötigen. Wenn dies bei Ihnen der Fall ist,
können Sie den Zugang zu RPC-Diensten, wie weiter unter beschrieben,
beschränken.

<sect1>Einschränken des Zugriffs auf RPC-Dienste

<p>Unglücklicherweise ist es in manchen Fällen nicht möglich, RPC-Dienste
vom System zu entfernen. Einige lokale Desktop-Dienste (hauptsächlich SGIs
<package>fam</package>) sind RPC-basiert und benötigen deshalb einen
lokalen Portmapper. Dies bedeutet, dass unter bestimmten Umständen Benutzer
die eine Desktop-Umgebung (wie GNOME) installieren, den Portmapper auch
installieren werden. 

<P>Es gibt einige Wege den Zugriff auf den Portmapper und RPC-Dienste zu
beschränken:

<list>
<item>Blockieren des Zugangs zu den Ports, die von diesen Diensten verwendet
      werden, mit einer lokalen Firewall (vergleiche
      <ref id="firewall-setup">).
<item>Blockieren des Zugangs zu diesen Diensten mittels TCP-Wrappers, da
      der Portmapper (und einige RPC-Dienste) mit <file>libwrap</file>
      (siehe <ref id="tcpwrappers">) kompiliert worden. Dies bedeutet,
      dass Sie Zugang zu diesen durch die <file>hosts.allow</file> und
      <file>hosts.deny</file> TCP-Wrapper-Konfiguration blockieren.
<item>Seit Version 5-5 kann das Paket <package>portmap</package> so
      konfiguriert werden, dass es nur noch an der lokalen
      Schleifenschnittstelle lauscht. Um dies zu erreichen, kommentieren Sie
      die folgende Zeile in der Datei <file>/etc/default/portmap</file> aus:
      <tt>#OPTIONS="-i 127.0.0.1"</tt> und starten Sie den Portmapper neu.
      Dies ist ausreichend, um lokale RPC-Dienste laufen zu lassen, während
      zur selben Zeit entfernte Systeme am Zugang gehindert werden (lesen
      Sie dazu auch <ref id="limit-bindaddr">).
</list>


<sect id="firewall-setup">Hinzufügen von Firewall-Fähigkeiten

<p>Das Debian-GNU/Linux-Betriebssystem hat die eingebauten
Fähigkeiten des Linux-Kernels. Wenn Sie eine aktuelle Veröffentlichung von
Debian (mit dem Standardkernel 2.6) installiert haben, steht Ihnen als Firewall
<prgn>iptables</prgn> (netfilter) zur Verfügung<footnote>Ist seit Kernel 2.4
verfügbar (was der Standardkernel für Debian 3.0 war). Ältere Kernelversionen
(wie 2.2, der in älteren Debian-Veröffentlichungen enthalten war) verwendeten
<prgn>ipchains</prgn>. Der Hauptunterschied zwischen <prgn>ipchains</prgn> und
<prgn>iptables</prgn> ist, dass letzteres auf <em>stateful packet
inspection</em> (zustandsbehaftete Paketuntersuchung) beruht, so dass Ihnen
sicherere (und einfacher zu erstellende) Filterkonfigurationen zur Verfügung
stehen. Ältere (und nun nicht länger unterstützte) Debian-Veröffentlichungen,
die den Kernel 2.0 einsetzen, benötigten einen geeigneten Kernel-Patch.
</footnote>.


<sect1>Firewallen des lokalen Systems

<p>Sie können eine Firewall dazu benutzen, den Zugriff auf Ihr
lokales System abzusichern und sogar um die Kommunikation von ihm nach Außen zu beschränken.
Firewall-Regeln können auch dazu benutzt werden, Prozesse zu sichern, die nicht
vernünftig konfiguriert werden können, um Dienste <em>nicht</em>
einigen Netzwerken, IP-Adressen, etc. zur Verfügung zu stellen.

<p>Dieser Schritt ist aber hauptsächlich deshalb als letzter in
dieser Anleitung, weil es <em>viel</em> besser ist, sich nicht alleine
auf die Fähigkeiten der Firewall zu verlassen, um ein System zu
schützen. Die Sicherheit eines Systems setzt sich aus mehreren
Ebenen zusammen; eine Firewall sollte die letzte sein, wenn bereits alle Dienste
abgehärtet worden sind. Sie können sich sicherlich leicht eine
Konfiguration vorstellen, bei der ein System lediglich von einer
eingebauten Firewall geschützt wird, und der Administrator glückselig
die Firewall-Regeln aus irgendwelchen Gründen
(Probleme mit dem Setup, Verdruss, Denkfehler, ...) entfernt. Dieses System
wäre weit geöffnet für Angriffe, wenn es keine anderen
Schutzmaßnahmen auf dem System gibt.

<p>Andererseits können Firewall-Regeln auf dem lokalen System
dafür sorgen, dass böse Dinge nicht passieren. Sogar wenn die
bereitgestellten Dienste sicher konfiguriert sind, kann eine Firewall
vor Misskonfigurationen oder frisch installierten Diensten, die noch
nicht passend konfiguriert sind, schützen. Außerdem wird eine strenge
Konfiguration <em>nach Hause telefonierende</em> Trojaner am
Funktionieren hindern, es sei denn, der Firewall-Code wird entfernt.
Beachten Sie, dass ein Eindringling <em>keinen</em> Superuser-Zugriff
benötigt, um ferngesteuerte Trojaner zu installieren (da es
erlaubt ist, sich an Ports zu binden, wenn es sich nicht um einen
privilegierten Port handelt und die Fähigkeiten (Capabilities) noch vorhanden
sind).

<p>Demzufolge wäre ein passendes Firewall-Setup, eines mit einer
standardmäßigen Deny-Policy (was also alles ablehnt, was nicht ausdrücklich
erlaubt ist), und weiterhin:

<list>

<item>Eingehende Verbindungen werden nur zu lokalen Diensten von
erlaubten Maschinen gestattet.

<item>Ausgehende Verbindungen werden nur von Diensten erlaubt, die auf
Ihrem System benutzt werden (DNS, Web-Surfen, POP, E-Mail,
...).<footnote>Im Gegensatz zu persönlichen Firewalls für
andere Betriebssysteme, stellt Debian GNU/Linux (noch) keine
Firewall-Erstellungs-Schnittstelle zur Verfügung, die Regeln
erstellen kann, die einzelne Prozesse oder Benutzer einschränken.
Jedoch kann der Iptables-Code so konfiguriert werden, dass er dies kann
(siehe dazu das »owner«-Modul in der Handbuchseite <manref name="iptables"
section="8">).</footnote>

<item>Die Forward-Regel verbietet alles; es sei denn, 
andere Systeme werden geschützt (siehe dazu unten).

<item>Alle anderen eingehenden und ausgehenden Verbindungen werden
abgelehnt.

</list>


<sect1>Schützen anderer Systeme durch eine Firewall

<p>Eine Debian-Firewall kann auch so installiert werden, dass sie mit
Firewall-Regeln Systeme <em>hinter</em> ihr beschützt, indem sie die
Angriffsfläche zum Internet hin einschränkt. Eine Firewall kann
so konfiguriert werden, dass ein Zugriff von Systemen außerhalb
des lokalen Netzwerks auf interne Dienste (Ports) unterbunden wird.
Zum Beispiel muss auf einem Mail-Server lediglich Port 25
(auf dem der Mail-Dienst aufsetzt) von außen zugänglich sein. Eine
Firewall kann so konfiguriert werden, dass sogar, wenn es neben den öffentlich
zugänglichen noch andere Netzwerkdienste gibt, direkt an diese gesendete Pakete verworfen werden (dies
nennt man <em>filtern</em>).

<p>Sie können eine Debian GNU/Linux Maschine sogar so konfigurieren,
dass sie als Bridge-Firewall (überbrückender Schutzwall)
fungiert, d.h. als eine filternde Firewall, die komplett transparent zum
gesamten Netzwerk erscheint, ohne IP-Adresse auskommt und daher
nicht direkt attackiert werden kann. Abhängig von dem installierten
Kernel müssen Sie vielleicht den Bridge-Firewall-Patch installieren
und dann <em>802.1d Ethernet Bridging</em> in der Kernel-Konfiguration
und die neue Option <em>netfilter ( firewalling ) Support</em>
auswählen. Sehen Sie dazu <ref id="bridge-fw">, um zu erfahren, wie
man dies auf einem Debian GNU/Linux System aufsetzt.


<sect1>Aufsetzen einer Firewall

<p>Die Debian-Standardinstallation bietet im Gegensatz zu vielen anderen
Linux-Distributionen noch keine Methode für den Administrator, eine
Firewall-Konfiguration mit der Standardinstallation einzurichten, aber
Sie können eine Anzahl von Firewall-Konfigurationspaketen (siehe <ref
id="firewall-pack">) installieren.

<p>Natürlich ist die Konfiguration einer Firewall immer vom
System und dem Netzwerk abhängig. Ein Administrator muss vorher
das Netzwerklayout und die Systeme, die er beschützen will, kennen,
die Dienste, auf die zugegriffen werden können muss,
und ob andere netzwerkspezifischen Erwägungen (wie NAT oder Routing)
berücksichtigt werden müssen. Seien Sie vorsichtig, wenn Sie Ihre
Firewall konfigurieren. Wie Laurence J. Lane im
<package>iptables</package>-Paket sagt:

<p><em>Die Werkzeuge können leicht falsch verwendet werden und eine
Menge Ärger verursachen, indem sie den gesamten Zugang zu einem 
Computernetzwerk stilllegen. Es ist nicht völlig ungewöhnlich, 
dass sich ein Systemadministrator, der ein System verwaltet, das hunderte oder tausende 
von Kilometern entfernt ist, irrtümlicherweise selbst davon ausgeschlossen 
hat. Man kann es sogar schaffen, sich von dem Computer auszusperren, dessen
Tastatur unter seinen Fingern liegt. Lassen Sie daher die gebotene Vorsicht
walten.</em> 

<p>Vergessen Sie nicht: Das bloße Installieren von
<package>iptables</package> (oder dem älteren Firewallcode) gibt Ihnen
keine Sicherheit, es stellt lediglich die Software zur Verfügung. Um
eine Firewall zu haben, müssen Sie sie konfigurieren!

<p>Wenn Sie keine Ahnung haben, wie Sie Ihre Firewall-Regeln manuell
aufsetzen sollen, sehen Sie in dem <em>Packet Filtering HOWTO</em> und
<em>NAT HOWTO</em> aus dem Paket <package>iptables</package>, zu finden
unter <file>/usr/share/doc/iptables/html/</file> nach.

<p>Wenn Sie nicht viel über Firewalls wissen, sollten Sie beginnen, indem Sie das
<url id="http://www.tldp.org/HOWTO/Firewall-HOWTO.html" 
name="Firewalling and Proxy Server HOWTO"> lesen.
Installieren Sie das Paket <package>doc-linux-text</package>,
wenn Sie es offline lesen wollen.
Wenn Sie Fragen stellen wollen oder Hilfe beim Einrichten einer Firewall 
benötigen, können Sie sich an die debian-firewall-Mailingliste wenden, siehe
<url id="http://lists.debian.org/debian-firewall">.
Sehen Sie auch <ref
id="references"> für weitere (allgemeinere) Verweise zu Firewalls.
Ein weiterer guter Leitfaden für Iptables ist <url
id="http://iptables-tutorial.frozentux.net/iptables-tutorial.html">.


<sect2 id="firewall-pack">Nutzen von Firewall-Paketen

<p>Das manuelle Aufsetzen einer Firewall kann für neue (und
manchmal auch für erfahrene) Administratoren kompliziert sein.
Hierfür hat die Freie-Software-Gemeinschaft eine große Zahl von
Werkzeugen erstellt, die zur einfachen Konfiguration einer lokalen Firewall
benutzt werden können. Seien Sie gewarnt, dass einige dieser
Werkzeuge sich mehr auf lokalen Schutz konzentrieren (auch <em>personal
firewall</em> genannt), während andere vielseitiger sind und dazu 
benutzt werden können, komplexere Regelwerke zum Schutz ganzer Netzwerke zu
erstellen.

<p>Einige Programme, die unter Debian zum Aufsetzen von Firewall-Regeln
benutzt werden können, sind:

<list>
<item>Für Desktop-Systeme:

<list>
<item><package>firestarter</package>, eine GNOME-Anwendung, die sich an
Endanwender richtet, die einen Wizard enthält, der nützlich ist, um schnell
Firewall-Regeln aufzustellen. Die Anwendung enthält eine graphische
Oberfläche zum Beobachten, ob eine Firewall-Regel Daten blockiert.

<item><package>guarddog</package> ist ein auf KDE beruhendes Paket zur
  Erstellung von Firewall-Regeln. Es richtet sich sowohl an Neulinge wie
  auch an Fortgeschrittene.

<item><package>knetfilter</package> ist ein KDE-Programm mit
  grafischer Oberfläche, um Firewall- und NAT-Regeln für iptables zu
  verwalten. Es ist eine Alternative zu guarddog, es ist jedoch etwas
  mehr auf fortgeschrittenere Benutzer ausgelegt.

<item>fireflier ist ein interaktives Werkzeug, um Firewall-Regeln zu
  erstellen. Dazu analysiert es den Netzwerkverkehr und
  Anwendungen. Es basiert auf einem Client-Server-Modell, daher müssen
  Sie sowohl den Server (<package>fireflier-server</package>) als auch
  einen der zahlreichen Clients (<package>fireflier-client-gtk</package>
  (Gtk+-Client), <package>fireflier-client-kde</package> (KDE-Client)
  oder <package>fireflier-client-qt</package> (QT-Client))
  installieren.
</list>

<item> Für Server-Systeme (textbasiert):
<list>
<item><package>fwbuilder</package>, eine objektorientierte graphische
Oberfläche, die Richtlinien-Compiler für verschiedene Firewall-Plattformen
inklusive Linux' netfilter, BSDs pf (verwendet in OpenBSD, NetBSD, FreeBSD
und MacOS X) ebenso wie Zugriffslisten von Routern enthält. Es ist ähnlich
zu Enterprise-Firewall-Management-Software. Die vollständige Funktionalität
von fwbuilder ist auch von der Kommandozeile verfügbar.

<item><package>shorewall</package>, ein Firewall-Konfigurationswerkzeug,
das Unterstützung für IPsec sowie beschränkte Unterstützung für Traffic 
Shaping und die Definition der Firewall-Regeln bietet. Die Konfiguration
geschieht durch eine einfache Menge von Dateien, die verwendet werden,
um die iptables-Regeln aufzustellen.

<item><package>bastille</package>, diese Härtungsanwendung ist in
<ref id="automatic-harden"> beschrieben. Einer der Härtungsschritte, die der
Administrator konfigurieren kann, ist eine Definition des erlaubten und
verbotenen Netzwerkverkehrs, der verwendet wird, eine Anzahl von
Firewall-Regeln, die das System am Start ausführt, zu generieren.
</list>

</list>

<p>Es gibt in Debian auch noch eine Menge anderer Frontends für Iptables. Eine
vollständige Liste kann auf der <url id="http://wiki.debian.org/Firewalls"
name="Firewall-Seite des Debian-Wikis">, die auch einen Vergleich der
verschiedenen Pakete enthält, abgerufen werden.

<p>Seien Sie gewarnt, dass manche der zuvor skizzierten Pakete
Firewall-Skripte einführen, die beim Systemstart ausgeführt
werden. Testen Sie diese ausführlich, bevor Sie neustarten, oder Sie finden
sich selbst ausgesperrt vor Ihrem Rechner wieder. Wenn Sie verschiedene
Firewall-Pakete mischen, kann dies zu unerwünschten Nebeneffekten führen. 
Gewöhnlich wird das Firewall-Skript, das zuletzt ausgeführt wird, das System
konfigurieren (was Sie so vielleicht nicht vorhatten). Sehen Sie hierzu
in der Paketdokumentation nach und benutzen Sie nur eines dieser Setups.

<p>Wie bereits zuvor erläutert, sind einige Programme wie <package>firestarter</package>,
<package>guarddog</package> und <package>knetfilter</package> graphische Administrations-Schnittstellen, die
entweder GNOME oder KDE (die letzte beiden) benutzen. Diese sind viel
benutzerorientierter (z.B. für Heimanwender) als einige der anderen Pakete
in der Liste, die sich eher an Administratoren richten. Einige der
Programme die zuvor aufgeführt wurden (wie <prgn>bastille</prgn>) fokussieren
auf dem Erstellen von Firewall-Regeln zum Schützen des Rechners, auf dem
sie laufen, sind aber nicht notwendigerweise dafür geschaffen,
Firewall-Regeln für Rechner zu erstellen, die ein Netzwerk schützen (wie
<prgn>shorewall</prgn> oder <prgn>fwbuilder</prgn>).

<p>Es gibt einen weiteren Typ von Firewall-Anwendungen: Anwendungs-Proxys.
Wenn Sie eine Möglichkeit suchen, eine Unternehmenslösung aufzusetzen, die
Pakete filtert und eine Anzahl von transparenten Proxys bietet, die
feinabgestimmte Verkehrsanalysen bieten, so sollten Sie
<package>zorp</package> genauer betrachten. Dies bietet alles in einem
einzelnen Programm.
Sie können diese Art von Firewall-Rechner auch manuell aufsetzen, indem
Sie die Proxys, die in Debian vorhanden sind, für verschiedene Dienste
verwenden. Zum Beispiel für DNS <package>bind</package> (richtig
konfiguriert),
<package>dnsmasq</package>, <package>pdnsd</package> oder 
<package>totd</package>
für FTP <package>frox</package> oder <package>ftp-proxy</package>, 
für X11 <package>xfwp</package>,
für IMAP <package>imapproxy</package>, 
für Mail <package>smtpd</package>
oder für POP3 <package>p3scan</package>. Für andere Protokolle können Sie
entweder einen allgemeinen TCP-Proxy wie <package>simpleproxy</package> 
oder einen allgemeinen SOCKS-Proxy wie <package>dante-server</package>, 
<package>tsocks</package> oder <package>socks4-server</package> verwenden.
Typischerweise werden Sie auch ein Web-Cache-System (wie 
<package>squid</package>) und ein Web-Filtersystem (wie
<package>squidguard</package> oder <package>dansguardian</package>) nutzen.


<sect2>Manuelle init.d-Konfiguration
<p>Eine andere Möglichkeit ist die manuelle Konfiguration Ihrer
Firewall-Regeln durch ein init.d-Skript, das die
<prgn>iptables</prgn>-Befehle ausführt. Befolgen Sie diese Schritte:

<list>
<item>Sehen Sie das unten aufgeführte Skript durch und passen Sie es Ihren
Anforderungen an. 

<item>Testen Sie das Skript und überprüfen Sie die Syslog-Meldungen nach
unterdrückten Netzverkehr. Wenn Sie vom Netzwerk aus testen, werden Sie
entweder den Beispielshellcode starten wollen, um die Firewall zu
entfernen (wenn Sie nichts innerhalb von 20 Sekunden eingeben) oder Sie
sollten die <em>default deny</em>-Richtliniendefinition auskommentieren
(<em>-P INPUT DROP</em> und <em>-P OUTPUT DROP</em>) und überprüfen, dass
das System keine gültigen Daten verworfen hat.

<item>Verschieben Sie das Skript nach <file>/etc/init.d/meineFirewall</file>

<item>Konfigurieren Sie das System das Skript zu starten, bevor irgendein
Netzwerk konfiguriert wird:
<example>
#update-rc.d meineFirewall start 40 S . stop 89 0 6 .
</example>

</list>

<p>Dies ist das Beispiel-Firewallskript:

<example>
#!/bin/sh
# Simple example firewall configuration.
#
# Caveats:
# - This configuration applies to all network interfaces
#   if you want to restrict this to only a given 
#   interface use '-i INTERFACE' in the 
#   iptables calls.
# - Remote access for TCP/UDP services is granted 
#   to any host, you probably want to restrict 
#   this using '--source'.
#
# chkconfig: 2345 9 91
# description: Activates/Deactivates the firewall at boot time
#
# You can test this script before applying with the 
# following shell snippet, if you do not type anything 
# in 10 seconds the firewall rules will be cleared.
#---------------------------------------------------------------
#  while true; do test=""; read  -t 20 -p "OK? " test ; \
#  [ -z "$test" ] && /etc/init.d/meineFirewall clear ; done
#---------------------------------------------------------------

PATH=/bin:/sbin:/usr/bin:/usr/sbin

# Services that the system will offer to the network
TCP_SERVICES="22" # SSH only
UDP_SERVICES=""
# Services the system will use from the network
REMOTE_TCP_SERVICES="80" # web browsing
REMOTE_UDP_SERVICES="53" # DNS
# Network that will be used for remote mgmt
# (if undefined, no rules will be setup)
# NETWORK_MGMT=192.168.0.0/24
# Port used for the SSH service, define this is you have setup a
# management network but remove it from TCP_SERVICES
# SSH_PORT="22"

if ! [ -x /sbin/iptables ]; then  
    exit 0
fi

fw_start () {

  # Input traffic:
  /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # Services
  if [ -n "$TCP_SERVICES" ] ; then
  for PORT in $TCP_SERVICES; do
    /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
  done
  fi
  if [ -n "$UDP_SERVICES" ] ; then
  for PORT in $UDP_SERVICES; do
    /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
  done
  fi
  # Remote management
  if [ -n "$NETWORK_MGMT" ] ; then
    /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT
  else 
    /sbin/iptables -A INPUT -p tcp --dport ${SSH_PORT}  -j ACCEPT
  fi
  # Remote testing
  /sbin/iptables -A INPUT -p icmp -j ACCEPT
  /sbin/iptables -A INPUT -i lo -j ACCEPT
  /sbin/iptables -P INPUT DROP
  /sbin/iptables -A INPUT -j LOG

  # Output:
  /sbin/iptables -A OUTPUT -j ACCEPT -o lo 
  /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # ICMP is permitted:
  /sbin/iptables -A OUTPUT -p icmp -j ACCEPT
  # So are security package updates:
  # Note: You can hardcode the IP address here to prevent DNS spoofing
  # and to setup the rules even if DNS does not work but then you 
  # will not "see" IP changes for this service:
  /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT
  # As well as the services we have defined:
  if [ -n "$REMOTE_TCP_SERVICES" ] ; then
  for PORT in $REMOTE_TCP_SERVICES; do
    /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT
  done
  fi
  if [ -n "$REMOTE_UDP_SERVICES" ] ; then
  for PORT in $REMOTE_UDP_SERVICES; do
    /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT
  done
  fi
  # All other connections are registered in syslog
  /sbin/iptables -A OUTPUT -j LOG
  /sbin/iptables -A OUTPUT -j REJECT 
  /sbin/iptables -P OUTPUT DROP
  # Other network protections
  # (some will only work with some kernel versions)
  echo 1 > /proc/sys/net/ipv4/tcp_syncookies
  echo 0 > /proc/sys/net/ipv4/ip_forward 
  echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
  echo 1 > /proc/sys/net/ipv4/conf/all/log_martians 
  echo 1 > /proc/sys/net/ipv4/ip_always_defrag
  echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
  echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
  echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
  echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

}

fw_stop () {
  /sbin/iptables -F
  /sbin/iptables -t nat -F
  /sbin/iptables -t mangle -F
  /sbin/iptables -P INPUT DROP
  /sbin/iptables -P FORWARD DROP
  /sbin/iptables -P OUTPUT ACCEPT
}

fw_clear () {
  /sbin/iptables -F
  /sbin/iptables -t nat -F
  /sbin/iptables -t mangle -F
  /sbin/iptables -P INPUT ACCEPT
  /sbin/iptables -P FORWARD ACCEPT
  /sbin/iptables -P OUTPUT ACCEPT
}


case "$1" in
  start|restart)
    echo -n "Starting firewall.."
    fw_stop 
    fw_start
    echo "done."
    ;;
  stop)
    echo -n "Stopping firewall.."
    fw_stop
    echo "done."
    ;;
  clear)
    echo -n "Clearing firewall rules.."
    fw_clear
    echo "done."
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|clear}"
    exit 1
    ;;
  esac
exit 0
</example>

<p>Um nicht alle Iptables-Regeln in das Init.d-Skript einfügen zu müssen,
können Sie auch das Programm <prgn>iptables-restore</prgn> verwenden, um die
Regeln zu laden, die zuvor mit <prgn>iptables-save</prgn> gespeichert
wurden. Um dies zu tun, müssen Sie Ihre Regeln erstellen und das Regelwerk
statisch speichern (z.B. in <file>/etc/default/firewall</file>).

<sect2>Konfiguration von Firewall-Regeln mittels <prgn>ifup</prgn>

<p>Sie können auch die Netzwerkkonfiguration in
<file>/etc/network/interfaces</file> verwenden, um Ihre Firewall-Regeln
einzurichten. Dafür müssen Sie Folgendes tun:

<list>
<item>Erstellen Sie Ihre Firewall-Regeln für die aktivierte Schnittstelle.

<item>Sichern Sie Ihre Regeln mit <prgn>iptables-save</prgn> in eine Datei
in <file>/etc</file>, zum Beispiel <file>/etc/iptables.up.rules</file>

<item>Konfigurieren Sie <file>/etc/network/interfaces</file>, diese Regeln
zu verwenden:

<example>
iface eth0 inet static
        address x.x.x.x
        [.. interface configuration ..]
        pre-up iptables-restore < /etc/iptables.up.rules
</example>

</list>

<p>Wahlweise können Sie auch Regeln erstellen, die beim Herunterfahren der
Netzwerkschnittstelle ausgeführt werden. Dazu erzeugen Sie diese, speichern sie
in <file>/etc/iptables.down.rules</file> und fügen diese Anweisung zur
Schnittstellenkonfiguration hinzu:

<example>
    post-down iptables-restore < /etc/iptables.down.rules
</example>

<p>Für weitergehende Firewall-Konfigurationsskripte durch
<package>ifupdown</package> können Sie die zu jeder Schnittstelle
verfügbaren Hooks (Einspringpunkte) wie in den
<file>*.d/</file>-Verzeichnissen verwenden, die mit
<prgn>run-parts</prgn> aufgerufen werden (vergleiche <manref name="run-parts" section="8">).


<sect2>Testen Ihrer Firewall-Konfiguration

<p>Testen Ihrer Firewall-Konfiguration ist so einfach und so schwierig,
wie das Starten Ihres Firewall-Skripts (oder die Aktivierung der
Konfiguration, die Sie in Ihrer Firewall-Konfigurationsanwendung
definierten). Wenn Sie jedoch nicht sorgfältig genug sind und Sie Ihre
Firewall aus der Ferne konfigurieren (z.B. durch eine SSH-Verbindung),
könnten Sie sich selbst aussperren.

<p>Es gibt mehrere Möglichkeiten, dies zu verhindern. Eine ist das Starten
eines Skriptes in einem separaten Terminal, das Ihre Firewall-Konfiguration
entfernt, wenn es keine Eingabe von Ihnen erhält. Ein Beispiel dafür ist:

<example>
$  while true; do test=""; read  -t 20 -p "OK? " test ; \
  [ -z "$test" ] && /etc/init.d/firewall clear ; done
</example>

<p>Eine andere Möglichkeit ist das Einführen einer Hintertür in Ihr
System durch einen alternativen Mechanismus, der es Ihnen erlaubt, das
Firewall-System entweder zurückzusetzen oder ein Loch in es schlägt, wenn
irgendetwas krumm läuft. Dafür können Sie <package>knockd</package>
verwenden und es so konfigurieren, dass eine spezielle
Portverbindungsversuchssequenz die Firewall zurücksetzt (oder eine
temporäre Regel hinzufügt). Selbst wenn die Pakete von der Firewall
zurückgewiesen werden, werden Sie Ihr Problem lösen können, da
<prgn>knockd</prgn> auf der Schnittstelle lauscht und Sie <em>sieht</em>.

<p>Das Testen einer Firewall, die ein internen Netz schützt, ist eine
andere Aufgabe. Schauen Sie sich dafür einige Werkzeuge an, die es für
entfernte Ausnutzbarkeitsbewertungen gibt (siehe <ref id="vuln-asses">),
um das Netzwerk von außerhalb nach innen (oder aus einer beliebig anderen
Richtung) bezüglich der Effektivität der Firewall-Konfiguration zu testen.
