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


Securing Debian Manual
Kapitel 5 - Absichern von Diensten, die auf Ihrem System laufen


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

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 einer bestimmten Schnittstelle horchen (einige Dienste bieten diese Fähigkeiten nicht). Oder verwenden Sie eine andere Methode, zum Beispiel den Linux-vserver-Patch (für 2.4.16), mit dem Prozesse an eine bestimmte Schnittstelle gebunden werden können.

Regarding the services running from inetd (telnet, ftp, finger, pop3...) it is worth noting that inetd can be configured so that services only listen on a given interface (using service@ip syntax) but that's an undocumented feature. One of its substitutes, the xinetd meta-daemon includes a bind option just for this matter. See xinetd.conf(5).

     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
     }

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


5.1 Absichern von ssh

Wenn Sie immer noch telnet statt ssh benutzen, sollten Sie dieses Handbuch kurz beiseitelegen und dies ändern. Ssh sollte anstelle von telnet für alle Anmeldungen aus der Ferne 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 Verschlüsselung benutzen. Also führen Sie sofort ein apt-get install ssh auf Ihrem System aus.

Ermuntern Sie alle Benutzer 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 su oder sudo. Schließlich sollten Sie noch die Datei /etc/ssh/sshd_config für mehr Sicherheit modifizieren:

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

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

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 ssh auswählen.

Mehr Informationen, wie Sie SSH mit Unterstützung für PAM aufsetzen, finden Sie hier: security mailing list archives.


5.1.1 SSH in ein Chroot-Gefängnis einsperren

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 http://chrootssh.sourceforge.net. Es ist aber aktuell noch nicht als Debianpaket verfügbar. Sie sollten stattdessen das pam_chroot-Modul, wie in Den Benutzerzugang einschränken, Abschnitt 4.11.9 beschrieben, verwenden.

In Chroot-Umgebung für SSH, Anhang G können Sie verschiedene Optionen finden, um Chroot-Umgebungen für SSH zu erstellen.


5.1.2 Ssh-Clients

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 mindterm verwenden, unterstützt dies nur Protokollversion 1. Jedoch ist der sshd-Server standardmäßig so konfiguriert, nur Version 2 (aus Sicherheitsgründen) zu akzeptieren.


5.1.3 Verbieten der Übertragung von Dateien

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

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


5.1.4 Beschränkung des Zugangs auf Dateientransfers

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:


5.2 Absichern von Squid

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 Benutzern, Computern oder Netzwerken erlaubt, indem Sie eine Zugriffs-Kontroll-Liste (ACL, Access Control List) in /etc/squid/squid.conf definieren. Mehr Informationen, wie Sie ACLs definieren, finden Sie im Squid User's Guide. Ein gute deutsche Dokumentation ist das Squid-Handbuch. Beachten Sie, dass Debian eine minimale Konfiguration für Squid bereitstellt, die alles verhindert, mit der Ausnahme, dass localhost sich mit Ihrem Proxy-Server (der standardmäßig mit dem Port 3128 läuft) verbinden kann. Sie müssen Ihre /etc/squid/squid.conf-Datei wie gewünscht anpassen. Die empfohlene minimale Konfiguration (mit dem Paket vertrieben) sieht wie folgt aus:

     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

Sie sollten Squid auch entsprechend Ihren System-Ressourcen konfigurieren einschließlich des Cache-Speichers (Option cache_mem), der Lage der zwischengespeicherten Dateien und der verwendeten Speichermenge auf der Platte (Option cache_dir).

Beachten Sie, 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. Dies ist aber NICHT empfohlen.

Passendes Aufsetzen und Konfigurieren des Proxy/Cache-Servers ist nur ein Teil der Absicherung Ihrer Site. Eine andere notwendige Aufgabe ist es, Squids Log-Dateien zu analysieren, um sicher zu gehen, dass alles so arbeitet, wie es soll. 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:

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 sollen sicher sein, dass es wirklich nötig ist, wenn Sie diese Eigenschaft nutzen wollen. Weitere Informationen über den »Accelerator Mode« in Squid finden Sie im Squid User's Guide - Accelerator Mode.


5.3 Absichern von FTP

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-Benutzer mit chroot einsperren, so dass diese nichts anderes sehen können als ihr eigenes Verzeichnis. Andernfalls können sie die Wurzel Ihres Dateisystems durchforsten, als hätten sie Shell-Zugriff darauf. Sie können die folgende Zeile in Ihre proftpd.conf-Datei im globalen Abschnitt hinzufügen, um die chroot-Fähigkeiten zu nutzen:

     DefaultRoot ~

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

Um ProFTPd-DoS-Angriffe durch ../../../ zu verhindern, fügen Sie die folgende Zeile Ihrer /etc/proftpd.conf hinzu: DenyFilter \*.*/

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 sftp (aus dem Paket ssh). Es gibt auch freie Implementierungen von SSH für andere Betriebssysteme, zum Beispiel putty oder cygwin.

Wenn Sie dennoch einen FTP-Server verwalten, während Sie den Benutzern 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 FTP-Server 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 Benutzer den anonymen FTP-Server mit gültigen SSH-Zugangsdaten füttern. Mehr Informationen und den Patch finden Sie unter: ProFTPD Patches. Dieser Patch wurde auch an Debian gesandt, vergleiche Fehler #145669.


5.4 Zugriff auf das X-Window-System absichern

Heutzutage werden X-Terminals in immer mehr Unternehmen 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 xhost + ein. Dies erlaubt jedem X-Client, sich mit Ihrem System zu verbinden. Für etwas bessere Sicherheit können Sie stattdessen das Kommando xhost +Rechnername verwenden, um den Zugriff auf bestimmte Rechner zu begrenzen.

Allerdings ist es eine viel sicherere Lösung, SSH zu benutzen, um X zu tunneln und die gesamte Sitzung zu verschlüsseln. Dies geschieht automatisch, wenn Sie sich an einer anderen Maschine via ssh anmelden. Damit dies funktioniert, müssen Sie den ssh-Client und den ssh-Server konfigurieren. Auf dem ssh-Client muss ForwardX11 in /etc/ssh/ssh_config auf yes gesetzt sein. Auf dem ssh-Server muss X11Forwarding in /etc/ssh/sshd_config auf yes gesetzt sein und das Paket xbase-clients muss installiert sein. Dies liegt daran, dass der SSH-Server /usr/X11R6/bin/xauth (bei Debian-Unstable (/usr/bin/xauth) verwendet, wenn er das Pseudo-X-Display aufsetzt. In den Zeiten von SSH sollten Sie die xhost-basierte Zugriffskontrolle komplett über Bord werfen.

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:

     $ startx -- -nolisten tcp

Dies ist das Standard-Verhalten unter XFree 4.1.0 (dem 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 /etc/X11/xinit/xserverrc editieren, damit Sie etwas erhalten wie:

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

Wenn Sie XDM benutzen, setzen Sie /etc/X11/xdm/Xservers auf :0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. Wenn Sie GDM benutzen, stellen Sie sicher, dass die Option DisallowTCP=true in /etc/gdm/gdm.conf eingetragen ist (was standardmäßig unter Debian der Fall ist). Dies wird grundsätzlich an jede X-Befehlszeile -nolisten tcp anhängen [48].

Sie können außerdem eine standardmäßige Zeitgrenze für die xscreensaver-Bildschirmsperre setzen. Auch wenn der Benutzer sie aufheben kann, sollten Sie die Konfigurationsdatei /etc/X11/app-defaults/XScreenSaver editieren und die lock-Zeile von

     *lock:                  False

(das ist der Standardwert unter Debian) auf Folgendes ändern:

     *lock:                  True

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

Lesen Sie mehr zur Sicherheit von X Window in XWindow-User-HOWTO (/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz).

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


5.4.1 Überprüfen Ihres Display-Managers

Wenn Sie einen Display-Manager lediglich zur lokalen Nutzung (für ein schönes graphisches Anmeldefenster) 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 /etc/X11/xdm/xdm-config erreichen:

     DisplayManager.requestPort:     0

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

     [xdmcp]
     Enable=false

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


5.5 Absichern des Druckerzugriffs (die lpd- und lprng-Problematik)

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?

In jeder UNIX-Druck-Architektur muss es einen Weg geben, um die Daten des Clients zu dem Druck-Server zu schicken. Traditionell machen dies lpr und lp so, dass das Client-Kommando die Daten in das Spool-Verzeichnis kopiert oder symbolisch verlinkt (weshalb diese Programme normalerweise SUID oder SGID sind).

Um jede Gefahr zu vermeiden, sollen Sie Ihren Druck-Server besonders sicher halten. Dies heißt, dass Sie Ihren Druckdienst 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 /etc/hosts.lpd eintragen.

Allerdings akzeptiert der lpr-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 blocken wollen (der lpr-Daemon kann nicht so konfiguriert werden, dass er nur auf eine bestimmte IP-Adresse lauscht).

Sie sollten Lprng gegenüber lpr 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).

Wenn Sie Ihren Drucker nur lokal auf Ihrem System benutzen, werden Sie diesen Dienst nicht über ein Netzwerk anbieten wollen. Sie sollten dann überlegen, ein anderes Druck-System, wie zum Beispiel das aus dem Paket cups oder PDQ, das auf den Zugriffsrechten des Gerätes /dev/lp0 beruht, einzusetzen.

Bei cups 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.

Wenn Sie cups jedoch nur lokal benutzen möchten, können Sie ihn so konfigurieren, dass er nur auf der Loopback-Schnittstelle lauscht, indem Sie Folgendes in Ihrer /etc/cups/cupsd.conf ändern:

     Listen 127.0.0.1:631

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 gelauscht wird, einzuschränken. Cups 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:

     <Location />
      Order Deny,Allow
      Deny From All
      Allow From 127.0.0.1
     </Location>

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 http://cups.org.

FIXME: Add more content (the article on Amateur Fortress Building provides some very interesting views).

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

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


5.6 Absichern des Mail-Dienstes

Wenn Ihr Server kein Mail-System ist, müssen Sie nicht wirklich einen 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.

Wenn Sie exim haben, müssen Sie den Daemon nicht laufen lassen, um dies zu erreichen, da der Standard-cron-Job die Mails abarbeitet. Sehen Sie in Daemons abschalten, Abschnitt 3.5.1, wie man dies erledigt.


5.6.1 Konfiguration eines Nullmailers

Sie brauchen vielleicht einen lokalen Mail-Daemon, damit 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.

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

Die folgenden Konfigurationsschritte müssen nur zur Konfiguration des exim-Pakets in der Debian 3.0 Version vorgenommen werden. Wenn Sie eine neuere Version verwenden (wie z.B. 3.1, das exim4 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 Verbindungen aus der Ferne zulässt.

In einem Debian 3.0 System mit exim muss man den SMTP-Daemon aus inetd wie folgt entfernen:

     $ update-inetd --disable smtp

und den Mail-Daemon so konfigurieren, dass er nur auf der loopback-Schnittstelle lauscht. In exim (dem Standard-Mail-Transport-Agent (MTA) unter Debian) tun Sie dies, indem Sie in der Datei /etc/exim.conf folgende Zeile hinzufügen:

     local_interfaces = "127.0.0.1"

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.

Bei postfix editieren Sie /etc/postfix/main.conf:

     inet_interfaces = localhost

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 /etc/hosts.allow und /etc/hosts.deny geprüft werden. Außerdem werden Sie vor unautorisierten Zugriffsversuchen gegen Ihren Mail-Daemon durch angemessenes Protokollieren gewarnt werden wollen.

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

     receiver_verify = true

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

Wenn Sie Mails nur weiterleiten möchten, können Sie in Erwägung ziehen, den Mail-Daemon durch Programme zu ersetzen, die nur zum Weiterleiten der Mail zu einem entfernten Mail-Server konfiguriert werden können. Debian stellt zurzeit ssmtp und nullmailer 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 [49] und sehen, welcher davon am besten auf Ihr System zugeschnitten ist.


5.6.2 Anbieten eines sicheren Zugangs zu Mailboxen

Wenn Sie entfernten Zugriff auf Mailboxen erlauben wollen, gibt es eine Anzahl von möglichen POP3- und IMAP-Daemonen.[50] 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.

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

Unter den IMAP-Servern in Debian vermeidet der cyrus-Server (im Paket cyrus-imapd) dies, indem er den gesamten Zugriff zu einer Datenbasis in einem beschränkten Teil des Dateisystems limitiert. Auch uw-imapd (installieren Sie entweder das uw-imapd- oder besser, wenn Ihre IMAP-Clients es unterstützen, das uw-imapd-ssl-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.

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 courier-imap (für IMAP) und courier-pop, teapop (für POP3) und cyrus-imapd (für POP3 und IMAP) bieten Server mit Authentifizierungsmethoden neben den lokalen Benutzerkonten. cyrus kann alle Authentifizierungsmethoden, die mittels PAM konfiguriert werden können, verwenden, währenddessen teapop-Datenbanken (wie postgresql und mysql) für die Benutzerauthentifizierung nutzen kann.

FIXME: Check: uw-imapd might be configured with user authentication through PAM too.


5.6.3 Sicherer Empfang von Mails

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 fetchmailrc, um dies zu zeigen:

     poll my-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
          my-imap-mailserver.org sleep 15 </dev/null > /dev/null'

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.

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

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

Dieses Kommando bindet den angegebenen Daemon (-l) an den Port (-d) und benutzt ein bestimmtes SSL-Zertifikat (-p).


5.7 Absichern von BIND

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:


5.7.1 Bind-Konfiguration um Missbrauch zu verhindern

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: allow-transfer, allow-query, allow-recursion und version. Sie können dies in dem globalen Abschnitt tun (so wird es auf alle Zonen angewandt) oder jeweils pro Zone. Dies ist im Paket bind-doc dokumentiert. Sobald das Paket installiert ist, können Sie hierzu mehr in /usr/share/doc/bind/html/index.html lesen.

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 lediglich DNS-Abfragen von Ihren internen Rechnern erlauben. Sie können dies einschränken, indem Sie Folgendes in Ihre /etc/bind/named.conf aufnehmen:

     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; } ;
     };

Die Option listen-on 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 listen-on gesetzt haben, könnten zwar nur interne Benutzer 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.

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 bind 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 Version-Direktive auf folgende Art:

      options { ... various options here ...
     version "Nicht verfügbar."; };

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

Eine beispielhafte named.conf-Konfigurationsdatei könnte so aussehen:

     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 "mysite.bogus" {
             type master;
             file "/etc/bind/named.meineseite";
             allow-query { any; };
             allow-transfer { friendly; };
     };

Bitte prüfen Sie (erneut) die Debian-Fehler-Datenbank (BTS) bezüglich Bind, insbesondere Bug #94760 (regarding ACLs on zone transfers). Fühlen Sie sich ruhig dazu ermutigt, zu diesem Bugreport beizutragen, wenn Sie glauben, nützliche Informationen hinzufügen zu können.


5.7.2 Ändern des BIND-Benutzers

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 README.Debian in Ihrer named-Dokumentation (/usr/share/doc/bind/README.Debian) 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 Beispielskript, um die Standard-Installation von Bind zu ändern, Anhang E ausprobieren.

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

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 keine 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 named verwendet. Sie können diese anlegen, indem Sie die folgenden Kommandos eingeben:

     addgroup named
     adduser --system --home /home/named --no-create-home --ingroup named \
           --disabled-password --disabled-login named

Beachten Sie, dass der Benutzer named sehr eingeschränkt ist. Wenn Sie – aus welchen Gründen auch immer – ein weniger eingeschränktes Setup haben möchten, benutzen Sie:

     adduser --system --ingroup named named

Editieren Sie nun /etc/init.d/bind mit Ihrem Lieblingseditor und ändern Sie die Zeile, die mit

     start-stop-daemon --start

anfängt zu[51]:

     start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

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

     OPTIONS="-u named -g named"

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

     -rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key

und den Ort, an dem bind seine PID-Datei erzeugt, z.B. indem Sie /var/run/named anstatt von /var/run verwenden:

     $ 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";
     };
     [ ... ]

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

     reload)
            /usr/sbin/ndc reload

in Folgendes ändern:

     reload)
             $0 stop
             sleep 1
             $0 start

Hinweis: Abhängig von Ihrer Debian-Version müssen Sie auch die restart-Zeile ändern. Dies wurde in der Version 1:8.3.1-2 von Debians BIND-Paket repariert.

Alles, was Sie jetzt noch tun müssen, ist, bind mittels /etc/init.d/bind restart neu zu starten und dann Ihr Syslog auf zwei Einträge wie die folgenden zu prüfen:

     Sep  4 15:11:08 nexus named[13439]: group = named
     Sep  4 15:11:08 nexus named[13439]: user = named

Voilà! Ihr named läuft nicht mehr 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 Bug #50013: bind should not run as root und Bug #132582: Default install is potentially insecure, Bug #53550, Bug #52745 und Bug #128129. Fühlen Sie sich ruhig dazu ermuntert, etwas zu den Fehlerbeschreibungen beizutragen, wenn Sie denken, nützliche Informationen hinzufügen zu können.


5.7.3 Chroot-Gefängnis für den Name-Server

To achieve maximum BIND security, now build a chroot jail (see Allgemeine chroot- und suid-Paranoia, Abschnitt 5.10) around your daemon. There is an easy way to do this: the -t option (see the named(8) manpage or page 100 of Bind's 9 documentation (PDF)). This will make Bind chroot itself into the given directory without you needing to set up a chroot jail and worry about dynamic libraries. The only files that need to be in the chroot jail are:

     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-Servers (falls es ihn gibt) enthalten.
                                Dieses Verzeichnis muss für
                                den named-User schreibbar sein.
     var/log/named   – Wenn Sie in eine 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.

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 /etc/named/ 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).

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

Wenn Sie für Bind ein komplettes Chroot-Gefängnis aufsetzen (d.h. Sie benutzen nicht nur -t), stellen Sie sicher, dass Sie die folgenden Dateien darin haben:[52]

     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.3.6.so
     lib/libc-2.3.6.so
     lib/ld-linux.so.2 – symbolischer Link auf ld-2.3.6.so
     lib/libc.so.6 – symbolischer Link auf libc-2.3.6.so
     sbin/ldconfig – kann gelöscht werden, nachdem Chroot aufgesetzt wurde
     sbin/named-xfer – wenn Sie Namen transferieren
     var/run/

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

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

     $ 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

Nach der Installation werden Sie die Dateien in das Chroot-Gefängnis verschieben müssen.[53] Sie können die init.d-Skripte in /etc/init.d lassen, so dass das System automatisch den Name-Server starten wird, aber editieren Sie sie, indem Sie bei den start-stop-daemon-Aufrufen in diesen Skripten --chroot /location_of_chroot hinzufügen. Oder verwenden Sie für BIND die Option -t, indem Sie sie in das OPTION-Argument in der Konfigurationsdatei /etc/default/bind (für Version 8) oder /etc/default/bind9 (für Version 9) eintragen.

Für weitere Informationen wie man Chroot-Gefängnisse aufsetzt, siehe Allgemeine chroot- und suid-Paranoia, Abschnitt 5.10.

FIXME: Füge Informationen aus folgenden Quellen ein: http://people.debian.org/~pzn/howto/chroot-bind.sh.txt, http://www.cryptio.net/~ferlatte/config/ (Debian-specific), http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html and http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm.


5.8 Absichern von Apache

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.

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 doc-central-Archive zuzugreifen, etc.) und nicht wollen, dass von außen auf ihn zugegriffen werden kann. Um dies zu tun, benutzen Sie die Listen oder BindAddress Direktiven in der Datei /etc/apache/http.conf.

Benutzen von Listen:

     Listen 127.0.0.1:80

Benutzen von BindAddress:

     BindAddress 127.0.0.1

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

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

Die Apache Documentation 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 apache-doc).

Mehr Informationen zu weiteren Restriktionen von Apache durch Einrichten chroot-Gefängnisses wird in Chroot-Umgebung für Apache, Anhang H bereitgestellt.


5.8.1 Verhindern, dass Benutzer Web-Inhalte veröffentlichen

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

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

     LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so

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

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

     Userdir disabled

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


5.8.2 Rechte der Protokolldateien

Apaches Protokolldateien gehören seit 1.3.22-1 dem Benutzer »root« und der Gruppe »adm« mit den Rechten 640. Diese Rechte ändern sich nach einer Rotation. Ein Eindringling, der das System über den Web-Server erreicht hat, kann so Einträge in alten Protokolldatei nicht (ohne Rechteerweiterung) entfernen.


5.8.3 Veröffentlichte Web-Dateien

Apache-Dateien befinden sich unterhalb von /var/www. 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.


5.9 Absichern von Finger

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

ffingerd ist der empfohlene finger-Daemon, wenn Sie vorhaben, einen öffentlichen Dienst anzubieten. In jedem Fall sind Sie zu Folgendem ermutigt, wenn Sie ihn über inetd, xinetd oder tcpserver aufzusetzen: Schränken Sie die Anzahl der Prozesse ein, die gleichzeitig laufen dürfen, schränken Sie den Zugriff auf den Finger-Daemon von bestimmten Hosts ein (indem Sie tcp-wrapper benutzen) und lassen Sie ihn nur auf der notwendigen Schnittstelle lauschen.


5.10 Allgemeine chroot- und suid-Paranoia

chroot 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). You can eventually create a modified root environment for the user or service you do not trust. 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.

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.[54]

Dies beinhaltet: Name-Server (wie bind), Web-Server (wie apache), Mail-Server (wie sendmail) und FTP-Server (wie wu-ftpd). 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 Absichern von BIND, Abschnitt 5.7).

Jedoch bietet Debian einige Software an, die helfen kann, chroot-Umgebungen aufzubauen. Sehen Sie Automatisches Erstellen von Chroot-Umgebungen, Abschnitt 5.10.1.

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

Seien Sie jedoch gewarnt, dass aus einem chroot-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 begrenzen 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. Der ausschließliche Einsatz sicherer Server-Programme, 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 chroot nicht als Sicherheits-, sondern als ein Testwerkzeug gedacht.


5.10.1 Automatisches Erstellen von Chroot-Umgebungen

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

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


5.11 Allgemeine Klartextpasswort-Paranoia

Sie sollten versuchen, jeden Netzwerk-Dienst, der seine Passwörter als Klartext über das Netz sendet oder empfängt, wie zum Beispiel FTP/Telnet/NIS/RPC, zu vermeiden. Der Autor empfiehlt jedem, ssh anstelle von telnet und ftp zu verwenden.

Vergessen Sie jedoch nicht, dass die Migration von telnet zu ssh die Sicherheit in keiner 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, ...

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


5.12 NIS deaktivieren

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.

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 LDAP-HOWTO (/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz).

Sie können mehr über NIS-Sicherheit in dem NIS-HOWTO (/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz) lesen.

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


5.13 Absichern von RPC-Diensten

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

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 portmap-Dienst kontrolliert RPC-Dienste durch Abbilden von RPC-Programmnummern auf DARPA-Protokoll-Portnummern. Er muss laufen, um RPC-Aufrufe ausführen zu können.

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.

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 fam bereitgestellt wird, ist ebenso ein RPC-Dienst und hängt deshalb von portmap ab.

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 NFS-HOWTO (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz) finden.


5.13.1 Vollständiges Deaktivieren von RPC-Diensten

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

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.


5.13.2 Einschränken des Zugriffs auf RPC-Dienste

Unglücklicherweise ist es in manchen Fällen nicht möglich, RPC-Dienste vom System zu entfernen. Einige lokale Desktop-Dienste (hauptsächlich SGIs fam) 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.

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


5.14 Hinzufügen von Firewall-Fähigkeiten

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 iptables (netfilter) zur Verfügung[55].


5.14.1 Firewallen des lokalen Systems

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 nicht einigen Netzwerken, IP-Adressen, etc. zur Verfügung zu stellen.

Dieser Schritt ist aber hauptsächlich deshalb als letzter in dieser Anleitung, weil es viel 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.

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 nach Hause telefonierende Trojaner am Funktionieren hindern, es sei denn, der Firewall-Code wird entfernt. Beachten Sie, dass ein Eindringling keinen 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).

Demzufolge wäre ein passendes Firewall-Setup, eines mit einer standardmäßigen Richtlinie, die alles ablehnt, was nicht ausdrücklich erlaubt ist, also:


5.14.2 Schützen anderer Systeme durch eine Firewall

Eine Debian-Firewall kann auch so installiert werden, dass sie mit Firewall-Regeln Systeme hinter 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 filtern).

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 802.1d Ethernet Bridging in der Kernel-Konfiguration und die neue Option netfilter ( firewalling ) Support auswählen. Sehen Sie dazu Aufsetzenden einer Bridge-Firewall, Anhang D, um zu erfahren, wie man dies auf einem Debian GNU/Linux System aufsetzt.


5.14.3 Aufsetzen einer Firewall

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 Nutzen von Firewall-Paketen, Abschnitt 5.14.3.1) installieren.

Of course, the configuration of the firewall is always system and network dependant. An administrator must know beforehand what is the network layout and the systems to protect, the services that need to be accessed, and whether or not other network considerations (like NAT or routing) need to be taken into account. Be careful when configuring your firewall, as Laurence J. Lane says in the iptables package:

The tools can easily be misused, causing enormous amounts of grief by completely crippling network access to a system. It is not terribly uncommon for a remote system administrator to accidentally get locked out of a system hundreds or thousands of miles away. You can even manage to get locked out of a computer who's keyboard is under your own fingers. Please, use due caution.

Vergessen Sie nicht: Das bloße Installieren von iptables (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!

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

Wenn Sie nicht viel über Firewalls wissen, sollten Sie beginnen, indem Sie das Firewalling and Proxy Server HOWTO lesen. Installieren Sie das Paket doc-linux-text, 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 http://lists.debian.org/debian-firewall. Sehen Sie auch Seien Sie wachsam gegenüber generellen Sicherheitsproblemen!, Abschnitt 2.2 für weitere (allgemeinere) Verweise zu Firewalls. Ein weiterer guter Leitfaden für Iptables ist http://iptables-tutorial.frozentux.net/iptables-tutorial.html.


5.14.3.1 Nutzen von Firewall-Paketen

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 personal firewall genannt), während andere vielseitiger sind und dazu benutzt werden können, komplexere Regelwerke zum Schutz ganzer Netzwerke zu erstellen.

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

Es gibt in Debian auch noch eine Menge anderer Frontends für Iptables. Eine vollständige Liste kann auf der Firewall-Seite des Debian-Wikis, die auch einen Vergleich der verschiedenen Pakete enthält, abgerufen werden.

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.

Wie bereits zuvor erläutert, sind einige Programme wie firestarter, guarddog und knetfilter 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 bastille), fokussieren auf das Erstellen von Firewall-Regeln zum Schutz 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 shorewall oder fwbuilder).

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 zorp 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 bind (richtig konfiguriert), dnsmasq, pdnsd oder totd für FTP frox oder ftp-proxy, für X11 xfwp, für IMAP imapproxy, für Mail smtpd oder für POP3 p3scan. Für andere Protokolle können Sie entweder einen allgemeinen TCP-Proxy wie simpleproxy oder einen allgemeinen SOCKS-Proxy wie dante-server, tsocks oder socks4-server verwenden. Typischerweise werden Sie auch ein Web-Cache-System (wie squid) und ein Web-Filtersystem (wie squidguard oder dansguardian) nutzen.


5.14.3.2 Manuelle init.d-Konfiguration

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

Dies ist das Beispiel-Firewallskript:

     #!/bin/sh
     ### BEGIN INIT INFO
     # Provides:          myfirewall
     # Required-Start:    $local_fs
     # Required-Stop:     $local_fs
     # Default-Start:     S
     # Default-Stop:      0 6
     # X-Start-Before:    $network
     # X-Stop-After:      $network
     # Short-Description: My custom firewall.
     ### END INIT INFO
     #
     # 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 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/myfirewall 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 you want to setup a management network (i.e. you've uncommented
     # the above line) you will need to define the SSH port as well (i.e.
     # uncomment the below line.) Remember to remove the SSH port from the
     # TCP_SERVICES string.
     # 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
       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

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


5.14.3.3 Konfiguration von Firewall-Regeln mittels ifup

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

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

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

For more advanced firewall configuration scripts through ifupdown you can use the hooks available to each interface as in the *.d/ directories called with run-parts (see run-parts(8)).


5.14.3.4 Testen Ihrer Firewall-Konfiguration

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.

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:

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

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 knockd 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 knockd auf der Schnittstelle lauscht und Sie sieht.

Das Testen einer Firewall, die ein internes Netz schützt, ist eine andere Aufgabe. Schauen Sie sich dafür einige Werkzeuge an, die es für entfernte Ausnutzbarkeitsbewertungen gibt (siehe Programme zur Fernprüfung der Verwundbarkeit, Abschnitt 8.1), um das Netzwerk von außerhalb nach innen (oder aus einer beliebig anderen Richtung) bezüglich der Effektivität der Firewall-Konfiguration zu testen.


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


Securing Debian Manual

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

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