securing-howto/de/services.sgml

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

<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>Einschränken der Dienste, so dass auf sie nur von bestimmten
Orten aus zugegriffen werden kann, kann durch Zugriffs-Beschränkungen
auf Kernel-Ebene (durch eine Firewall) passieren. Konfigurieren Sie sie,
so dass sie nur auf ein bestimmtes Interface horchen (einige Dienste
bieten diese Fähigkeiten vielleicht nicht), oder durch eine andere
Methode. Zum Beispiel kann der Linux vserver-Patch (für 2.4.16) dazu
benutzt werden, Prozesse auf ein bestimmtes Interface zu binden.

<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 ein bestimmtes Interface
reagiert (unter Verwendung der <tt>service@ip</tt>-Syntax). Dies ist jedoch
eine nicht dokumentierte Eigenschaft.
Ein Ersatz, der <prgn>xinetd</prgn>
Meta-Daemon kennt eine <tt>bind</tt>-Option nur für diesen Zweck. Lesen Sie dazu
bitte <manref name="xinetd.conf" section="5">.

<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 <prgn>ssh<prgn>
<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 mit zu schnü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 ein bestimmtes Interface 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>Listen 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 Usern 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
Direktiven 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".

<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 /etc/eine_Datei</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 sind. Derzeit gibt es drei weitverbreitete
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">Chroot'en von ssh
<p>

<p>Zurzeit bietet OpenSSH keine Möglichkeit, automatisch Benutzer
bei der Verbindung zu chroot'en (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. Um jedoch den Zugang
zu <prgn>scp</prgn> einzuschränken, müssen Sie entweder:

<list>

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

<item>Benutzern, denen sichere Übertragungen verwehrt sind, richtige Shells
vorenthalten. Die angebotenen Shells, sollten dennoch Programme sein, die
Verbindungen zum ssh-Server sinnvoll gestalten, wie z.B. Menü-Programme
<!-- FIXME: What do you mean with "was useful at all" ? -->
(ala BBS). Andernfalls ist die verherige Möglichkeit bevorzugt.

</list>

<sect>Absichern von Squid

<p>Squid ist einer der verbreitetsten Proxy/Cache-Server, und es gibt ein
paar Sicherheitsaspekte, die Sie beachten sollten. Squid's Standard-Konfiguration
lehnt alle Anfragen von Nutzern 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.conf</file> definieren. Mehr
Informationen, wie Sie ACLs definieren, finden Sie in der <url
name="Squid User's Guide"
id="http://squid-docs.sourceforge.net/latest/html/book1.html">.
<!-- Todo: Deutsche Squid Guide raussuchen -->
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.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-Ressources 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 und neueren Versionen verfügbar:

<list>
<item><package>calamaris</package> - Log-Datei-Analysator für Squid oder Oops Proxy-Log-Dateien.
<item><package>modlogan</package>  - Ein modularer Log-Datei-Analysator.
<!-- This one is no longer available?
<item><package>sarg</package> - Squid Analysis Report Generator.
-->
<item><package>squidtaild</package> - 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
es 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, Kapitel 9"
id="http://squid-docs.sourceforge.net/latest/html/c2416.html">.

<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 des FTP-Nutzers chrooten, so dass ein Nutzer
nichts anderes sehen kann, als sein eigenes Verzeichnis. Andernfalls können
sie Ihr 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 Proftp-DoS Attacken 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. Nutzer 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 mehr und 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
gilt, da der ssh-Server <file>/usr/X11R6/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>Zur besten Sicherheit, wenn Sie keinen X-Zugriff von anderen Maschinen
benötigen, ist es, die Bindung auf 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/xserverrcc</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 in
<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>-nolisten tcp</tt> in der
<file>/etc/gdm/gdm.conf</file> gesetzt ist (was standardmäßig 
unter Debian der Fall ist), wie hier:

<example>
[server-Standard]
name=Standard Server
command=/usr/bin/X11/X -nolisten tcp
</example>

<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>
<p>ändern.<!-- Jens: <p> überprüfen -->

<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 Uebersetzung -->


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

<sect>Absichern des Drucker-Zugriffs (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 Zugang-Kontrolle
ü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 es 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 Sicherheits-Optionen in dieser
Konfigurations-Datei, 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;/Locationi&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="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 Alarm-Systemen zu erhalten.

<p>Wenn Sie <prgn>exim</prgn> haben, benötigen Sie den Daemon nicht
arbeitend, 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.

<!-- Jens: up to here for know -->
<p>If you want a relay-only setup, however, you can consider changing
the mailer daemon to programs that can <em>only</em> be configured to
forward the mail to a remote mail server. Debian provides currently
both <package>ssmtp</package> and <package>nullmailer</package> for
this purpose. In any case, you can evaluate for yourself any of the
mail transport agents 
<footnote>
To retrieve the list of mailer daemons available in Debian try:
<example>
$ apt-cache search mail-transport-agent
</example>
<p>The list will not include <prgn>qmail</prgn>, which is distributed
only as source code in the <package>qmail-src</package> package.
</footnote>
provided by Debian and see which one suits best to the system's
purposes.

<sect1>Providing secure access to mailboxes

<p>If you want to give remote access to mailboxes there are a number
of POP3 and IMAP daemons available.<footnote>
A list of servers/daemons which support these
protocols in Debian can be retrieved with:
<example>
$ apt-cache search pop3-server
$ apt-cache search imap-server
</example>
</footnote>
However, if you provide IMAP access note that it is a general file
access protocol, it can become the equivalent of a shell access
because users might be able to retrieve any file that they can
through it.

<p>Try, for example, to configure as your inbox path
<tt>{server.com}/etc/passwd</tt> if it succeeds your IMAP daemon is
not properly configured to prevent this kind of access.

<p>Of the IMAP servers in Debian the <prgn>cyrus</prgn> server (in the
<package>cyrus-imapd</package> package) gets around this by having all
access be to a database in a restricted part of the file system. Also,
<prgn>uw-imapd</prgn> (either install the <package>uw-imapd</package>
or better, if your IMAP clients support it,
<package>uw-imapd-ssl</package>) can be configured to chroot the users
mail directory but this is not enabled by default. The documentation
provided gives more information on how to configure it.

<p>Also, you might want to run an IMAP server that does not need valid
users to be created on the local system (which would grant shell
access too), both <package>courier-imap</package> (for IMAP) and
<package>courier-pop</package> <package>teapop</package> (for POP3)
and <package>cyrus-imapd</package> (for both POP3 and IMAP) provide
servers with authentication methods beside the local user
accounts. <prgn>cyrus</prgn> can use any authentication method that
can be configured through PAM whileas <prgn>teapop</prgn> might use
databases (such as <package>postgresql</package> and
<package>mysql</package>) for user authentication.


<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
statt-
dessen 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, fetchmail 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 angegeben Daemon (-l) an den Port
(-d) und nutzt ein bestimmtes 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 User laufen zu lassen (siehe <ref id="user-bind">)
und ihn zu chrooten (siehe <ref id="chroot-bind">).

</list>

<sect1 id="configure-bind">Bind configuration to avoid misuse 

<p>Sie sollten einige Informationen, die von außen 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 global 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 - ein
einfacher Server im heimischen Netzwerk. Sie möchten keinen Dienst
im Internet anbieten und DNS-Abfragen lediglich Ihrem internen Host
erlauben. Sie sollten 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 <em>listen-on</em> Option 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 abzustürzen
(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,
heraus zu finden, ob ein Bind für eine bestimmt 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 Users

<p>Bezüglich der Beschränkung von BINDs Privilegien müssen
Sie beachten, dass, wenn Sie BIND als nicht-root User laufen lassen, BIND
neue Netzwerk-Schnittstellen nicht automatisch entdecken kann, zum Beispiel
wenn Sie eine PCMCIA-Karte in Ihr Notebook stecken. Lesen Sie README.Debian in Ihrer
Dokumentation (<file>/usr/share/doc/bind/README.Debian</file>) für
mehr Informationen hierzu. Es gab in letzter Zeit Sicherheitsprobleme
mit BIND, so dass es nützlich ist, den User 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,
probieren Sie das Skript in <ref id="bind-chuser"> aus.

<p>Um BIND unter einem anderen User laufen zu lassen, müssen Sie
zunächst einen separaten User und eine separate Gruppe dafür
erstellen (es ist <em>keine</em> gute Idee für alle Dienste, die
Sie nicht als root laufen lassen, den User nobody und die Gruppe nogroup
zu benutzen). In diesem Beispiel wird der User und die Gruppe
<tt>named</tt> benutzt. 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 User <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 <tt>/etc/init.d/bind</tt> mit Ihrem Lieblings-Editor
und ändern Sie die Zeile, die mit 
<example>
start-stop-daemon --start
</example>

anfängt zu<footnote>Note that depending on your bind version you might not have the
<tt>-g</tt> option, most notably if you are using woody and installing
bind9 (9.2.1-2.woody).</footnote>:
<example>
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
</example>

<P>Change the permissions of files that are used by Bind, including <file>
/etc/bind/rndc.key</file>:

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

and where bind creates its pidfile, using, for example, <file>/var/run/named</file> instead of <file>/var/run</file>:

<example>
$ mkdir /var/run/named
$ chown named.named /var/run/named
$ vi /etc/named.conf
[ ... update the configuration file to use this new location ...]
options { ...
        pid-file "/var/run/named/named.pid";
};
[ ... ]
</example>

<p>Außerdem müssen Sie, um zu verhindern, dass irgendetwas als root
läuft, die <tt>reload</tt>-Zeile auskommentieren:

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

<p>und in Folgendes ändern:<!--Jens: <p> überprüfen -->
<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 durch
'/etc/init.d/bind restart' neu zu starten, und dann Ihr Syslog auf zwei
Einträge. wie die folgenden, 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 User 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 #128120" id="http://bugs.debian.org/52745">, und
<url name="Bug #128120" id="http://bugs.debian.org/128129">. 
Fühlen Sie sich ruhig dazu ermuntert, etwas zu den Fehlermeldungen
beizutragen, wenn Sie denken, nützliche Informationen beitragen zu 
können.


<sect1 id="chroot-bind">Chrooten des Name-Servers

<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 sehr einfachen Weg dies zu
erreichen: Die <tt>-t</tt> Option (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 documentation (PDF)">). Dies wird Bind selbst in ein bestimmtes
Verzeichnis chrooten lassen, ohne dass Sie einen eigenes
Chroot-Gefängnis aufsetzen müssen, oder 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/       - sollte die named.conf und alle Server-Zonen enthalten
sbin/named-xfer - wenn Sie Namen transferieren
var/run/named/  - sollte die pid und den Cache des Name-Server (falls es
                  ihn gibt) enthalten. Dieses Verzeichnis muss für
                  den named-User schreibbar sein.
var/log/named   - Wenn Sie in einer Datei protokollieren, muss dies
                  für den named-User schreibbar sein.
dev/log         - 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 bestimmt
Zugriffsrechte auch die named-Dateien. Dies ist eine einfache
Angelegenheit, da die Konfigurations-Dateien 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
zwischen speichernden Name-Server. Wenn dies der Fall ist, müssen Sie
ihm Lese- und Schreibzugriff auf die notwendigen Zonen gewähren (so
dass 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 8.2.3 (aus Debian Potato) 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:

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

<p>Sorgen Sie auch dafür, dass <prgn>syslogd</prgn> auf
$CHROOT/dev/log 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 hier tun:

<!-- FIXME: Does bind use autoconf? -->
<example>
$ apt-get --download-only source bind build-dep bind
$ cd bind-8.2.5-2
(ändern Sie das Makefile.in, so dass CFLAGS die Option '-static'
beinhaltet bevor die @CFLAGS@ Definition von autoconf verwendet wird)
$ dpkg-buildpackage -rfakeroot
$ 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
wird das chroot-Gefängnis etwas komplizierter </footnote>. Sie
können die <tt>init.d</tt> Skripten in <file>/etc/init.d</file>
lassen, so dass das System automatisch den Name-Server starten wird, aber
editieren Sie sie in dem Sie bei den <prgn>start-stop-daemon</prgn>
Aufrufen in diesen Skripten <tt>--chroot /location_of_chroot</tt>
hinzufügen.

<p>For more information on how to set up chroots see <ref id="chroot">.

<p>FIXME, merge info from
<url id="http://people.debian.org/~pzn/howto/chroot-bind.sh.txt">,
<!-- <url id="http://people.pdxlinux.org/~karlheg/"> (Bind9 in Debian), -->
<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">.
<!-- 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 den 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>More information on further restricting Apache by setting up a
chroot jail is provided in <ref id="chroot-apache-env">.

<sect1>Disabling users from publishing web contents

<p>The default Apache installation in Debian permits users to publish
content under the <file>$HOME/public_html</file>. This content can
be retrieved remotely using an URL such as:
http://your_apache_server/~user.

<p>If you do not want to permit this you must change the
<file>/etc/apache/http.conf</file> configuration file commenting out:

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

But if the module was linked statically (you can check this running
<tt>apache -l</tt>) you must add the following instead:

<example>
Userdir disabled
</example>

<p>Note: The <tt>disabled</tt> keyword is only available in Apache 1.3
and above. In you are using older versions of apache, you need to change 
the configuration file and add:

<!-- This can be removed since woody provides Apache 1.3 -->

<example>
&lt;Directory /home/*/public_html&gt;
    AllowOverride None
    Order deny,allow
    Deny from all
&lt;/Directory&gt;
</example>

<p>An attacker might still do user enumeration, since the answer
of the web server will be a <em>403 Permission Denied</em> and not a
<em>404 Not available</em>.

<sect1>Logfiles permissions

<p>Apache logfiles, since 1.3.22-1, are owned by user 'root' and group
'adm' with permissions 640 this permissions are changed after
rotation. An intruder that accessed the system through the web server
would not be able (without privilege escalation) to remove old log
file entries.

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

<sect1>Published web files

<p>Apache files are located under <file>/var/www</file>. Just after
installation the default file provides some information on the system
(mainly that it's a Debian system running Apache).  The default
webpages are owned by user root and group root by default, whileas the
Apache process runs as user www-data and group www-data. This should
make attackers that compromise the system through the web server
harder to deface the site. You should, of course, substitute the
default web pages (which might provide information you do not want to
show to outsiders) with your own.

<p>

<sect>Absichern von finger
<p>Wenn Sie einen finger-Dienst laufen lassen wollen, fragen Sie sich
bitte zuerst, ob Sie das auch tun müssen. Wenn Sie 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 - Konfigurierbarer finger-Daemon
<item>efingerd - Ein weiterer Unix-finger-Daemon mit anpassbarer Ausgabe
<item>ffingerd - Ein sicherer finger-Daemon
<item>fingerd - Remote-User Informationsserver
<item>xfingerd - 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, 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 achten, 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>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.

<p>Dies trifft auch auf andere Programme mit komplexen Funktionen und
größerer Nutzergemeinde zu, einschließlich sendmail und einige
ftp-Daemonen (z.B. wu-ftpd). (Natürlich kann auch ein Programm ohne
viele Funktionen, das seine Nutzer nicht zufrieden stellt, unsicher sein,
abgesehen davon, dass es nutzlos ist.)
-->

<p><prgn>chroot</prgn> is one of the most powerful possibilities to
restrict a daemon or a user or another service. Just imagine a jail
around your target, which the target cannot escape from (normally, but
there are still a lot of conditions that allow one to escape out of
such a jail). If you do not trust a user or a service, you can create
a modified root environment for him. This can use quite a bit of disk
space as you need to copy all needed executables, as well as
libraries, into the jail. But then, even if the user does something
malicious, the scope of the damage is limited to the jail.

<!-- 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>Many services running as daemons could benefit from this sort of
arrangement as. The daemons that you install with your Debian
distribution will not come, however, chrooted <footnote> It does try
to run them under <em>minimum priviledge</em> which include running
daemons with their own users instead of having them run as root
</footnote> per default.</p>

<p>This includes: name servers (such as <prgn>bind</prgn>), web
servers (such as <prgn>apache</prgn>), mail servers (such as
<prgn>sendmail</prgn>) and ftp servers (such as
<prgn>wu-ftpd</prgn>). It is probably fair to say that the complexity
of BIND is the reason why it has been exposed to a lot of attacks in
recent years (see <ref id="sec-bind">).

<p>However, Debian does provide some software that can help set up
<prgn>chroot</prgn> environments. See <ref id="auto-chroot">.

<!--
<p>In jedem Fall sollten Sie, wenn Sie diese laufen lassen, ähnliche
Arrangements für sie in Erwägung ziehen &ndash; entziehen von
root-Privilegien, einsperren in ein chroot-Gefängnis &ndash; oder
ersetzen durch ein sichereres Äquivalent.
-->

<p>Anyway, if you run any service on your system, you should consider
running them as secure as possible. This includes: revoking root
privileges, running in a restricted environment (such as a chroot
jail) or replacing them with a more secure equivalent.</p>

<p>However, be forewarned that a <prgn>chroot</prgn> jail can be
broken if the user running in it is the superuser. So, you need to
make the service run as a non-privileged user. By limiting its
environment you are limiting the world readable/executable files the
service can access, thus, you limit the possibilities of a privilege
escalation by use of local system security vulnerabilities.  Even in
this situation you cannot be completely sure that there is no way for
a clever attacker to somehow break out of the jail.  Using only server
programs which have a reputation for being secure is a good additional
safety measure. Even minuscule holes like open file handles can be
used by a skilled attacker for breaking into the system. After all,
<prgn>chroot</prgn> was not designed as a security tool but as a
testing tool.</p>

<sect1 id="auto-chroot">Making chrooted environments automatically

<p>There are several programs to chroot automatically servers and
services. Debian currently (accepted in May 2002) provides Wietse
Venema's <prgn>chrootuid</prgn> in the <package>chrootuid</package>
package, as well as <package>compartment</package> and
<package>makejail</package>. These programs can be used to set up a
restricted environment for executing any program
(<prgn>chrootuid</prgn> enables you to even run it as a restricted
user). 

<p>Some of these tools can be used to set up the chroot environment
easily. The <prgn>makejail</prgn> program for example, can create and
update a chroot jail with short configuration files (it provides
sample configuration files for <prgn>bind</prgn>, <prgn>apache</prgn>,
<prgn>postgresql</prgn> and <prgn>mysql</prgn>). It attempts to guess
and install into the jail all files required by the daemon using
<prgn>strace</prgn>, <prgn>stat</prgn> and Debian's package
dependancies. More information at <url
id="http://www.floc.net/makejail/">. <prgn>Jailer</prgn> is a similar
tool which can be retrieved from <url
id="http://www.balabit.hu/downloads/jailer/"> and is also available
as a Debian GNU package.

<!-- FIXME Site is down?
<p>Also useful to create chroots (or jails) is
<package>deb.pl</package>, 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
unixoide 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 Passworten 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 Ihren
System so konfigurieren, dass es den LDAP Server zur User
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) is a protocol that programs can use to
request services from other programs located on different computers.
The <prgn>portmap</prgn> service controls RPC services by mapping
RPC program numbers into DARPA protocol port numbers; it must be
running in order to make RPC calls.

<p>RPC-based services have had a bad record of security holes, although
the portmapper itself hasn't (but still provides information to
a remote attacker). 
Einige DDoS (distributed denial of service) Angriffe benutzen
RPC-Löcher, um in das System einzudringen und als so genannter
Agent/Handler zu fungieren.

<p>You only need RPC if you are using an RPC-based service.  The most
common RPC-based services are NFS (Network File System) and NIS
(Network Information System). See the previous section for more
information about NIS. The File Alteration Monitor (FAM) provided by the
package <package>fam</package> is also an RPC service, and thus
depends on <package>portmap</package>.

<p>NFS services are quite important in some networks. If that is the case
for you, then you will need to find a balance of security and
usability for your network.  (You can read more about NFS security in
the <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>).)

<sect1>Disabling RPC services completely

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

<p>Notice that some desktop environments (notably, GNOME) use RPC
services and need the portmapper for some of the file management
features. If this is your case, you can limit the access to RPC
services as described below.

<sect1>Limiting access to RPC services

<p>Unfortunately, in some cases removing RPC services from the system is not
an option. Some local desktop services (notably SGI's <package>fam</package>)
are RPC based and thus need a local portmapper. This means that under
some situations, users installing a desktop environment (like GNOME) 
will install the portmapper too. 

<P>There are several ways to limit access to the portmapper and to
RPC services:

<list>
<item>Block access to the ports used by these services
with a local firewall (see <ref id="firewall-setup">).
<item>Block access to these services using tcp wrappers, since
the portmapper (and some RPC services) are compiled with
<file>libwrap</file> (see <ref id="tcpwrappers">). This means that you can
block access to them through the <file>hosts.allow</file> and
<file>hosts.deny</file> tcp wrappers configuration.
<item>Since version 5-5, the <package>portmap</package> package
can be configured to listen only on the loopback interface. To do this,
modify <file>/etc/default/portmap</file>, uncomment the following line:
<tt>#OPTIONS="-i 127.0.0.1"</tt> and restart the portmapper. This
is sufficient to allow local RPC services to work while at the same time
prevents remote systems from accessing them (see, 
however, <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. Dies heißt, dass Sie, wenn Sie ein
Potato (Debian 2.2) System installiert haben (mit dem standardmäßigen Kernel 2.2)
werden Sie <prgn>ipchains</prgn> Firewall-Unterstützung im Kernel
haben. Das Paket <package>ipchains</package> sollte bereits (aufgrund seiner
Priorität) installiert sein.
Wenn Sie Debian 3.0 (oder 3.1) installiert haben (mit
dem standardmäßigen 2.4er Kernel) unterstützt der Kernel Ihr
<!-- Jens: FIXME -->
<prgn>iptables</prgn> (netfilter). Der Hauptunterschied zwischen
<prgn>ipchains</prgn> und <prgn>iptables</prgn> ist, dass letzteres auf
<em>stateful packet inspection</em> (zustandsbehaftete Paketuntersuchung),
so dass Ihnen sicherere (und einfacher zu erstellende)
Filterkonfigurationen zur Verfügung stehen.

<sect1>Firewallen des lokalen Systems

<p>Sie können eine Firewall dazu benutzen, den Zugriff auf Ihr
lokales System und sogar die Kommunikation von ihm nach Außen absichern.
Firewall-Regeln können dazu benutzt werden, Prozesse, die nicht
vernünftig konfiguriert werden können, zu schützen, aber
<em>nicht</em>, um Dienste für Netzwerke, 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 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, 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 andere
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 wurde 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 (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, email, ...)
<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 User 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, Sie beschützen
andere Systeme, siehe 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 es 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 verwirft (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. 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 der neuen 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>The default Debian installation, unlike other Linux distributions,
does not yet provide a way for the administrator to setup a firewall
configuration throughout the default installation but you can install
a number of firewall configuration packages (see <ref
id="firewall-pack">).

<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,
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 
von Kilometer entfernt ist, irrtümlicherweise selbst davon ausgeschlossen 
hat. Man kann es sogar schaffen, sich von dem Computer aus zu sperren, dessen
Tastatur unter seinen Fingern liegt. Lassen Sie daher die gebotene Vorsicht
walten.</em> 


<p>Vergessen Sie nicht: Das einfache Installieren von
<package>iptables</package> (oder dem älterem 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.
If you want to ask questions or need help setting up a firewall 
you can use the debian-firewall mailing list, see
<url id="http://lists.debian.org/debian-firewall">.
Sehen Sie auch <ref
id="references"> für weitere (allgemeinere) Verweise.

<sect2 id="firewall-pack">Using firewall packages

<p>Setting up manually a firewall can be complicated for novice (and
sometimes even expert) administrators. However, the free software
community has created a number of tools that can be used to easily
configure a local firewall. Be forewarned that some of this tools are
oriented more towards local-only protection (also known as
<em>personal firewall</em>) and some are more versatile and can be
used to configure complex rules to protect whole networks.

<p>Some software that can be used to set up firewall
rules in a Debian system is:

<list>
<item><package>firestarter</package>, a GNOME application oriented
towards end-users that includes a wizard useful to quickly setup
firewall rules. The application includes a GUI to be able to monitor
when a firewall rule blocks traffic.
<item><package>fwbuilder</package>, an object oriented GUI which
includes policy compilers for various firewall platforms including
Linux' netfilter, BSD's pf (used in OpenBSD, NetBSD, FreeBSD and 
MacOS X) as well as router's access-lists. It is similar to enterprise
firewall management software. Complete fwbuilder's functionality is
also available from the command line.
<item><package>shorewall</package>, a firewall configuration tool
which provides support for IPsec as well as limited support for traffic 
shaping as well as the definition of the firewall rules. Configuration
is done through a simple set of files that are used to generate the
iptables rules.
<item><package>guarddog</package>, a KDE based firewall configuration
package oriented both to novice and advanced users.
<item><package>knetfilter</package>, a KDE GUI to manage firewall
and NAT rules for iptables (alternative/competitor to the guarddog tool
although slightly oriented towards advanced users)
<item><package>bastille</package>, this hardening application is
described in <ref id="automatic-harden">, one of the hardening steps
that the administrator can configure is a definition of the allowed and
disallowed network traffic that is used to generate a set of firewall
rules that the system will execute on startup.
<item><package>mason</package>, an application which can propose
firewall rules based on the network traffic your system "sees".
<item><package>ferm</package>
<item><package>lokkit</package> or <package>gnome-lokkit</package>
<item><package>ipac-ng</package>, helps setup not traditional firewall
rules but network traffic classification rules.
<item><package>filtergen</package>
<item><package>fiaif</package>
<item><package>hlfl</package>
<item><package>kmyfirewall</package>
<item><package>netscript-2.4</package>
</list>
<!-- No longer available :
fwctl 
fireflier
easyfw
firewall-easy
gfcc
-->

<p>Notice that some of the packages outlined previously will
introduce firewalling scripts to be run when the system boots.
Test them extensively before rebooting or you might find yourself
locked from the box. If you mix different firewalling packages you
can have undesired effects, usually, the firewalling
script that runs last will be the one that configures the system
(which might not be what you pretend). Consult the package
documentation and use either one of these setups. 

<p>As mentioned before, some programs, like firestarter, guarddog 
and knetfilter, are administration GUIs using either GNOME or KDE 
(last two). These applications are much more user-oriented 
(i.e. for home users) than some of the other packages in the list 
which might be more administrator-oriented. Some of the programs
mentioned before (like <prgn>bastille</prgn>) are focused at setting up 
firewall rules to protect the host they run in but are not necessarily 
designed to setup firewall rules for firewall hosts that protect a 
network (like <prgn>shorewall</prgn> or <prgn>fwbuilder</prgn>).

<p>There is yet another type of firewall application: application proxies.
If you are looking into setting up an an enterprise-level that does
packet filtering and provides a number of transparent proxies that can
do fine-grain traffic analysis you should consider using 
<package>Zorp</package>, which provides this in a single program.
You can also manually setup this type of firewall host using the
proxies available in Debian for different services 
like for  DNS using <package>bind</package> (properly configured),
<package>dnsmasq</package>, <package>pdnsd</package> or 
<package>totd</package>
for FTP using <package>frox</package> or <package>ftp-proxy</package>, 
for X11 using <package>xfwp</package>,
for IMAP using <package>imapproxy</package>, 
for mail using <package>smtpd</package>,
or for POP3 using <package>p3scan</package>. For other protocols you
can either use a generic TCP proxy like <package>simpleproxy</package> 
or a generic SOCKS proxy like <package>dante-server</package>, 
<package>tsocks</package> or <package>socks4-server</package>.
Typically, you will also use a web caching system (like 
<package>squid</package>) and a web filtering system (like
<package>squidguard</package> or <package>dansguardian</package>).

<sect2>Manual init.d configuration
<p>Another possibility is to manually configure your firewall rules
through an init.d script that will run all the <prgn>iptables</prgn>
command. Take the following steps:

<list>
<item>Review the script below and adapt it to your needs. 

<item>Test the script and review the syslog messages to see which
traffic is being dropped. If you are testing from the network you will
want to either run the sample shell snippet to remove the firewall (if
you don't type anything in 20 seconds) or you might want to comment
out the <em>default deny</em> policy definitions (<em>-P INPUT
DROP</em> and <em>-P OUTPUT DROP</em>) and check that the system will
not drop any legitimate traffic.

<item>Move the script to <file>/etc/init.d/myfirewall</file>

<item>Configure the system to run the script before any network is
configured:
<example>
#update-rc.d myfirewall start 40 S . stop 89 0 6 .
</example>

</list>

<p>This is the sample firewall script:

<example>
#!/bin/sh
# Simple example firewall configuration
#
# Caveats:
# - This configuration applies to all network interfaces
#   if you want to retrict 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 will 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/firewall 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

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

fw_start () {

# Input traffic:
        /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Services
        for PORT in $TCP_SERVICES; do
            /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
        done
        for PORT in $UDP_SERVICES; do
            /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
        done
# 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
        /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT 
        for PORT in $REMOTE_TCP_SERVICES; do
            /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
        done
        for PORT in $REMOTE_UDP_SERVICES; do
            /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
        done
# 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
        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>

<sect2>Configuring firewall rules through ifup

<p>You can use also the network configuration in
<file>/etc/network/interfaces</file> to setup your firewall rules. For
this you will need to:

<list>
<item>Create your firewalling ruleset for when the interface is active.

<item>Save your ruleset with <prgn>iptables-save</prgn> to a file in
<file>/etc</file>, for example <file>/etc/iptables.up.rules</file>

<item>Configure <file>etc/network/interfaces</file> to run use the
configured ruleset:

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

</list>

<p>You can optionally also set a set of rules to be applied when the
network interface is <em>down</em> creating a set of rules, saving it
in <file>/etc/iptables.down.rules</file> and adding this directive to the
interface configuration:

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

<p>For more advanced firewall configuration scripts through
<package>ifupdown</package> you can use the hooks available to each
interface as in the <file>*.d/</file> directories called with
run-parts (see <manref name="run-parts" section="8">).

<sect2>Machen Sie es auf die (alte) Debian-Art

<P><strong>NOTE</strong>: This information only applies to iptables
in <em>woody</em>. Versions later than 1.2.7-8 don't any longer
have the init.d script described here. Users of Debian 3.1 or later
releases should either setup firewalling rules manually or use
any of the firewall generation programs described previously.

<p>Wenn Sie Debian 3.0 oder neuer benutzen, werden Sie feststellen, dass Sie bereits
das Paket <package>iptables</package> installiert haben. Dies ist die
Unterstützung für die Netfilter-Implementation in 2.4.4+
Kerneln. Da das System nach der Installation aber keine Firewall-Regeln
kennen kann (Firewall-Regeln sind zu systemspezifisch), müssen Sie
iptables einschalten. Wie auch immer: Die Skripte wurden so
konfiguriert, dass der Administrator Firewall-Regeln aufsetzen kann und
die init-Skripte sie dann <em>lernen</em> können und so immer als
das Setup der Firewall fungieren.

<p>Hierzu müssen Sie Folgendes tun:

<list>

<item>Konfigurieren Sie das Paket so, dass es mit dem System gestartet
wird. Bei neueren Versionen (seit 1.2.6a-1) werden Sie während der
Installation hiernach gefragt. Sie können es hinterher wieder mit
<tt>dpkg-reconfigure -plow iptables</tt> ändern. <em>Wichtig</em>:
Bei älteren Versionen geschah dies noch durch Editieren von
<file>/etc/default/iptables</file>, so dass die Variable
<tt>enable_iptables_initd</tt> auf <em>true</em> gesetzt wurde.

<item>Erstellen Sie Ihr Firewall-Setup mit iptables, benutzen Sie
dazu die Kommandozeile (siehe <manref name="iptables" section="8">) oder
andere der Tools aus Debians Firewall-Paketen (siehe <ref
id="firewall-pack">). Sie müssen einen Satz von Firewall-Regeln
erstellen, die benutzt werden sollen wenn die Firewall <em>aktiv</em> ist,
und einen anderen wenn die Firewall <em>inaktiv</em> (dies können
auch nur leere Regeln sein) ist.

<item>Sichern Sie die erstellten Regeln mit den Skripten
<tt>/etc/init.d/iptables save active</tt> und <tt>/etc/init.d/iptables
save inactive</tt>.
<!-- Jens: FIXME -->

</list>

<p>Sobald dies geschehen ist, ist Ihr Firewall-Setup im Verzeichnis
<file>/var/lib/iptables/</file> gespeichert und wird beim System-Boot
ausgeführt (oder wenn das initd Skript mit <em>start</em> und
<em>stop</em> gestartet wird). Beachten Sie, dass die standardmäßigen
Einstellungen unter Debian vorsehen, den Firewall-Code in den Multiuser-Runleveln 
(2 bis 5) sehr früh (10) zu starten. Außerdem wird er im singleuser-
Runlevel (1) gestoppt. Ändern Sie dies, wenn es nicht Ihren lokalen
Richtlinien entspricht.

<p>Please read the inline comments in the
<file>/etc/default/iptables</file> configuration file for more
information on the issues regarding this package.

<sect2>Testing your firewall configuration

<p>Testing your firewall configuration is as easy, and as dangerous,
as just running your firewall script (or enabling the configuration
you defined in your firewall configuration application). However,
if you are not careful enough and you are configuring your firewall
remotely (like through an SSH connection) you could lock yourself

<p>There are several ways to prevent this. One is running a 
script in a separate terminal that will remove the firewall configuration
if you don't feed it input. An example of this is:

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

<p>Another one is to introduce a backdoor in your system through an
alternate mechanism that allows you to either clear the firewall
system or punch a hole in it if something goes awry. For this you
can use <package>knockd</package> and configure it so that a certain
port connection attempt sequence will clear the firewall (or 
add a temporary rule). Even though the packets will be dropped
by the firewall, since <prgn>knockd</prgn> binds to the interface
and <em>sees</em> you will be able to work around the problem.

<p>Testing a firewall that is protecting an internal network is
a different issue, you will want to look at some of the tools
used for remote vulnerability assesment (see <ref id="vuln-asses">) to
probe the network from the outside in (or from any other direction)
to test the effectiveness of the firewall configuation.

<!--
<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
Tools erstellt, die zur einfachen Konfiguration einer Lokalen Firewall
benutzt werden können. Seien Sie vor gewarnt, dass einige dieser
Tools 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><package>firestarter</package>, oriented towards end-users
including a wizard to quickly defined the firewall rules.
<item><package>knetfilter</package>
<item><package>fwbuilder</package>, an object oriented GUI which
includes policy compilers for various firewall platforms including
iptables as well as router's access-lists.
<item><package>shorewall</package>  which provides support for IPsec as
well as limited support for traffic shaping as well as the definition
of the firewall rules.
<item><package>mason</package>, das basierend auf dem Netzwerkverkehr,
denn Ihr System "sieht", Firewall-Regeln vorschlagen kann
<item><package>bastille</package> (unter anderem besitzt diese neue Version
von bastille unter den Abhärtungsstufen die Möglichkeit,
Firewall-Regeln während des Starts auszuführen)
<item><package>guarddog</package>, a KDE based firewall configuration
package (alternative/competitor to the knetfilter package)
<item><package>ferm</package>
<item><package>fwctl</package>
<item><package>easyfw</package>
<item><package>firewall-easy</package>
<item><package>ipac-ng</package>
<item><package>gfcc</package>
<item><package>lokkit</package> oder <package>gnome-lokkit</package>
</list>

<p>Die Pakete gfcc, firestarter und knetfilter sind graphische
Administrations-Schnittstellen, die entweder GNOME (die ersten beiden)
oder KDE (das letzte) benutzen und die eher benutzerorientiert sind (z.B.
für Heimanwender) als die anderen Pakete in der Liste, die sich eher
an Administratoren richten.

<p>Seien Sie vor gewarnt, dass manche der zuvor skizzierten Pakete eigene
Firewall-Skripte einführen, die beim Systemstart ausgeführt
werden sollen, dies wird zweifellos mit dem allgemeinen Setup (wenn 
konfiguriert) kollidieren und dürfte zu unerwünschten Nebeneffekten führen. 
Das Firewall-Skript, das zuletzt ausgeführt wird, wird das System
konfigurieren (was Sie so vielleicht nicht vorhatten). Sehen Sie hierzu
in der Paket-Dokumentation nach und benutzen Sie nur eines dieser Setups.
Allgemeiner: Andere Programme, die helfen die Firewall-Regeln
aufzusetzen, können in den Konfigurationsdateien anderer
rum pfuschen.
-->