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

Anleitung zum Absichern von Debian
Kapitel 5 - Absichern von Servicem die auf Ihrem System laufen


Services können auf zwei Arten abgesichert werden:

Einschränken der Services, so dass auf Sie nur von bestimmten Orten 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 Services 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.

Was die Services angeht, die von inetd aufgerufen werden (telnet, ftp, finger, pop3...), so ist es nichts Wert, dass inetd nicht so konfiguriert werden kann, dass er nur auf ein bestimmtes Interface reagiert. Wie auch immer, sein Ersatz, der xinetd Meta-Daemon kennt ein bind für diesen zweck. Lesen Sie dazu bitte 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 detailierter darauf ein, wie bestimmte Services abhängig von der beabsichtigten Benutzung passend konfiguriert werden.


5.1 Absichern der Secure-Shell (ssh)

Wenn Sie immernoch 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 apt-get install ssh auf Ihren System aus.

Ermuntern Sie alle Nutzer Ihres Systems ssh anstelle von telnet zu benutzen, oder noch bessern: 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. Schliesslich sollte Sie noch die Datei /etc/ssh/sshd_config für mehr Sicherheit modifizieren:

Abschliessend beachten Sie bitte, dass diese Direktiven von einer OpenSSH Konfigurations-Datei 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 verbreiteste (Gerüchten zufolge, gibt es sogar eine Windows-Version). Ssh2 hat gegebüber ssh2 Vorteile, abgesehen davon, dass er unter einen unfreien Lizens veröffentlicht wurde. OpenSSH ist ein wirklich 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.2 Absicher von Squid

Squid ist eine der verbreitesten Proxy/Cache Server, und es gibt ein paar Sicherheitsaspekte, die Sie beachten sollten. Squid's standard Konfiguration lehnt alle Abfragen von Nutzern ab.Sie sollten Squid so konfigurieren, dass er Zugriffe von vertrauenswürdigen Nutzern, Computern oder Netzwerken erlaubt, indem Sie eine Zugriffs-Kontroll-Liste (ACL, Acces Control List) on /etc/squid.conf. Mehr Informationen, wie Sie ACLs definieren, finden Sie in der Squid User's Guide.

Ebenso kann bei ungeeigneter Konfiguration vorkommen, dass jemand eine Mail über Squid weiterleitet, da die Protokolle HTTP und SMTP ein ähnliches Design habven. Squid's standard Konfiguration verweigert Zugriffe auf Port 25. Wenn Sie Verbindungen an Port 25 erlauben wollen, fügen Sie ihn einfach in der Safe_ports-Liste hinzu. Aber dies ist NICHT empfohlen.

Passendes Aufsetzen und Konfigurieren des Proxy/Cache-Servers ist nur ein Teil des Absichern Ihrer Seite. Eine andere notwendige Aufgabe ist es, Squid's 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 Woody (Debian 3.0) verfügbar:

FIXME: Add more information about security on Squid 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 Heimatverzeichnis des FTP-Nutzer chrooten, so dass ein Nutzer nichts anderes sehen kann, als sein Verzeichniss. Anderfalls können sie Ihr Dateisystem durchlaufen, als hätten Sie Shell-Zugriff. Sie können die folgende Zeile in Ihre proftpd.conf im globalen Abschnitt hinzufügen, um die chroot-Fähigkeiten zu nutzen:

     DefaultRoot ~

Starten Sie proftpd neu, indem Sie /etc/init.d/proftpd restart eingebe, und prüfen Sie, ob Sie noch aus ihrem Heimatverzeichnis heraus kommen können.

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

Vergessen Sie nicht, dass FTP Logind und athentifizierungs 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 natürlich auch freue Implentierungen von SSH für andere Betriebssysteme, zum Beispiel putty oder cygwin.

Wenn Sie dennoch einen FTP Server verwalten wollen, während Sie den Nutzern Zugriff via SSH gewähren, könnten Sie auf ein typisches Problem tressen. Nutzer die innerhalb eines mit SSH abesicherten 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 Nutzer dem anonymen FTP-Server mit gültigen SSH-Zugangsdaten schicken. Mehr Informationen und der Patch sind finden Sie unter; ProFTPD Patches.


5.4 Zugriff auf das X-Window-System absichern

Heutzutage werden X-Terminals bei mehr und mehr Firmen benutzt, so dass ein Server für viele Arbeitsplätze zuständig ist. 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, sollten 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 kann automatisch geschehen, wenn Sie sich auf eine andere Maschine ssh-en. Sie müssen es nur in der /etc/ssh/ssh_config einschalten, indem Sie X11Forwarding auf yes setzen. In den zeiten von SSH sollten Sie die xhost-basierte Zugriffskontrolle komplett über Bord werfen.

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:

     $ startx -- -nolisten tcp

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

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

Wenn Sie XDM benutzen, setzen Sie in /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 -nolisten tcp in der /etc/gdm/gdm.conf gesetzt ist (was in der standardmässig unter Debian der Fall sein sollte), wie hier:

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

Sie können ausserdem die standard Zeitgrenze für xscreensaver Sperrungen setzen. Auch wenn der Nutzern sie aufheben kann, sollten Sie Konfigurationsdatei /etc/X11/app-defaults/XScreenSaver editieren, und die lock-Zeile von

     *lock:                  False

(das ist der standardwert unter Debian) auf

     *lock:                  True

ändern.

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 lediglichen 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 /etc/X11/xdm/xdm-config:

     DisplayManager.requestPort:     0

Normalerweise sind unter Debian alle Display-Manager so konfiguriert, dass sie standardmässig keine XDMCP-Services starten.


5.5 Absichern des Drucker-Zugriffs (Die lpd und lprng Sache)

Stellen Sie sich vor, Sie kommen zur Arbeit, und der Drucker spuckt entlose Mengen von Papier aus, weil jemand Ihren Drucker-Daemon DoS-et. Unangenehm, oder?

In jeder Unix Druck-Architektur muss es einen Weg geben, um die Daten des Client auf den Druck-Server zu bekommen. Traditionell machen dies lpr und lp so, dass das Client-Kommando die Daten in das Spool-Verzeichnis kopiert oder symlinkt (weshalb diese Programme normalerweise SUID oder SGID sind).

Um jede Gefahr zu vermeiden sollen Sie Ihren Druck-Server besonders sicher halten. Dies heisst, dass Sie Ihren Druck-Service so konfigurieren müssen, dass er nur Aufträge von vertauenswürdigen Rechnern annimmt. Hierzu müssen Sie die Rechner, von denen Sie Druckaufträge entgegennehmen möchten in die Datei /etc/hosts.lpd ein.

Allerdings akzeptier 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/Rechner, die nicht drucken dürfen, mittels Firewall abblocken wollen (Der lpr-Daemon kann nicht so konfiguriert werden, dass er nur auf eine bestimmte IP-Adresse hört.)

Sie sollten Lprng gegenüber lpr vorziehen, da er so konfiguriert werden kann, dass er Zugangkontrolle über IP kann. 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 ihn nicht über Netzwerk teilen 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 der Server muss auf irgendeinen Port hören.

Wie auch immer: Wenn Sie cups 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 /etc/cups/cupsd.conf ändern:

     Listen 127.0.0.1:631

Es gibt noch andere Sicherheits-Optionen in diese 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 den gehört wird, einzuschränken. Cups liefert auch Dokumentation über den HTTP-Port. Wen Sie diese potentiell nützlichen Informationen einen Angreifer ausserhalb nicht enthüllen wollen (und der Port offen ist), fügen Sie ausserdem folgendes hinzu:

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

Die Konfigurations-Datei kann auch so angepasset werden, dass zusätzliche Fähigkeiten, einschliessliche 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-Daemon

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, damit beispielsweise Mails an den Root-User von irgendwelchen Alarm-System erhalten.

Um dies auf einem Debian System zu erreichen, entfernen Sie den smtp-Daemon auf dem inetd:

     $ update-inetd --disable smtp

und konfigurieren Sie den Mailer-Daemon so, dass er nur auf die Lokale Schleife achtet. In exim (dem standard Mail Transport Agent (MTA) unter Debian) tun Sie dies, indem Sie die in der Datei /etc/exim.conf die Zeile

     local_interfaces = "127.0.0.1"

Hinzufügen.

Starten Sie beide Daemonen neu (inetd und exim) und exim wird lediglich auf den Socket 127.0.0.1:25 reagieren. Seien Sie vorsichtig und deaktivieren Sie erst inetd, oder exim wird nicht neu starten, da ider inetd bereits eingehende Verbindungen behandelt.

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

     inet_interfaces = localhost

Wenn Mails lediglich lokal entgegennehmen wollen ist dieses Herangehen besser als Mailer-Daemon in einen tcp-Wrapper zu hüllen oder Firewall-Regeln einzufügen, die den Zugang für alle limitieren sollen. 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. Ausserdem werden Sie von unautorisierte Zugriffsversuche gegen Ihren Mail-Daemon durch angemessenes Protokollieren gewarnt werden wollen.

In jedem Fall können Sie Mail-Relais-Versuche auf 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 relayen wird ist diese Konfiguration für den Relay-Test auf http://www.abuse.net/relay.html nötig, um festzustellen, dass Ihr Server nicht Relais-fähig ist.


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

     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 </dev/null > /dev/null'

Die wichtige Zeile ist die preconnect-Zeile. Sie startet eine ssh-Verbindung und erstellt den notwendigen Tunnel, duch 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-Services 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 umhüllt den angegeben Daemon (-l) an den Port (-d) und nutzt ein bestimmtes Zertifikat (-p).


5.8 Sichern von BIND

Es gibt verschiedene Dinge mit denen Sie sich auseinandersetzen sollen, um einen Domain-Server-Daemon abzusichern, die ähnlich zu den Überlegungen sind, wie man einen anderen Service absichert:

Sie sollten einige Informationen, die von aussen abgefragt werden können, zurückhalten, so dass man nicht wertvolle Informationen über Ihre Organisation, die Sie nicht herausgeben wollen, abfragen kann. Dies schliesst die folgenden Optionen mit ein: allow-transfer, allow-query, allow-recursive und version. Sie können dies in dem global 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 Neztwerk (Ihre interne IP ist 192.168.1.2) verbunden . Sie möchten keinen Service im Internet anbieten und DNS-Abfragen lediglich ihren internen Host erlauben. Sie sollten dies einschränken, indem Sie folgendes in ihre /etc/bind/named.conf aufnehmen:

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

Die liste-on Option bewirkt, dass sich DNS nur auf die Schnittstelle bindet, die internen Zugang 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 Nutzer Abfragen starten, aber, da der Port für Angreifer von aussen 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 DN-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, heraus zu finden, ob ein Bind für eine bestimmt Atacke 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 in der folgenden Art:

     options {
     	... verschiedene andere Optionen ...
     	version "Nicht verfuegbar.";
     };

Das ändern des version.bind Eintrages schützt eigentlich nicht gegen Attacken, aber Sie könntes es als sinnvolle Schutzvorrichtung ansehen.

Eine beispielhafte named.conf Konfigurations-Datei 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-recursive { internal; };
             allow-transfer { none; };
     };
     // Ab hier bis zur meineseite.bogus Zone 
     // ist alles im Grunde die unveränderte Debian Standard Einstellung
     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 hinzugefuegt habe
     zone "meineseite.bogus" {
             type master;
             file "/etc/bind/named.meineseite";
             allow-query { any; };
             allow-transfer { friendly; };
     };

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


5.8.1 Ändern von BIND User

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 entdecken kann. Zum Beispiel, wenn Sie eine PCMCIA-Karte in ihr Notebook stecken. Lesen Sie README.Debian in Ihrer Dokumentation (/usr/share/doc/bind/README.Debian) für mehr Informationen hierzu. Es gab in letzter Zeit Sicherheits-Probleme mit BIND, so dass es nützlich ist, den User zu wechseln, wenn es möglich ist. Wie werden die Schritte, die dazu nötig sind, detailiert listen, wenn Sie dies automatisch machen lassen wollen, probieren Sie das Skript in Beispiel Skript, um die standard Installation von Bind zu ändern, Anhang E aus.

Um BIND als ein anderer User laufen zu lassen müssen Sie zunächst einen separaten User und eine separate Gruppe dafür erstellen (es ist keine gute Idee für alle Services, die sie nicht als root laufen lasse, den User nobody und die Gruppe nogroup zu benutezn). In diesem Beispiel wird der User und die Gruppe named benutzt. 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 User named sehr eingeschränlt 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 Lieblings-Editor und änder Sie die Zeile, die mit

     start-stop-daemon --start

anfängt zu:

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

Ausserdem müssen Sie, um zu verhindern, dass irgendetwas als root läuft, die reload-Zeile auskommentieren:

     reload)
            /usr/sbin/ndc reload

und in folgendes ändern:

     reload)
             $0 stop
             sleep 1
             $0 start

Beachten Sie: Abhängig von Ihrer Debian Version, müssen Sie vielleicht 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 durch '/etc/init.d/bind restart' neu zu starten, und dann Ihr Syslog auf zwei Einträge. wie die folgenden, 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äft nicht mehr als root. Wenn Sie mehr Informationen darüber lesen wollen, warum BIND normalerweise nicht als nicht-root User 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 #128120, und Bug #128120. Fühlen sie sich ruhig dazu ermuntert, etwas zu den Fehlermeldungen beizutragen, wenn Sie denken, Sie können nützliche Informationen beitragen.


5.8.2 Chrooten des Name-Server

Um die grösstmögliche BIND Sicherheit zu erreichen, müssen Sie nun ein Chroot-Käfig (siehe Benutzen von chroot, Abschnitt 4.12) um Ihren Daemon herum bauen. Es gibt da einen sehr einfachen Weg dies zu erreichen: Die -t Option (siehe die Handbuchseite named(8)). Dies wird Bind selbst in ein bestimmtes Verzeichniss chrooten lassen, ohne dass Sie einen eigenen Chroot-Käfig aussetzen müssen, oder sich sorgen um dynamische Bibliotheken machen müssen. Die einzigen Dateien, die Sie in diesem Chroot-Käfig benötigen, sind:

     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 Verzeichniss muss für
     		  den named-User schreibbar sein.
     var/log/named   - Wenn Sie in einer Datei protokollieren, muss dies
                       für den names User schreibbar sein.
     dev/log         - syslogd sollte hierrauf hören, wenn named so
                       konfiguriert ist, dass er hierrüber protokolliert.

Damit Ihr Bind Daemon vernünftig läuft, braucht er bestimmt Zugriffsrechte auch die named-Dateien. Dies ist eine einfache Angelegenheit, da die Konfigurations-Dateie immer in /etc/named/ liegen. Beachten Sie, dass er lediglich lese-Zugriff benötigt, es sei denn, es handelt sich um einen sekundären oder zwischenspeichernden 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).

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 Installations des Paketes doc-linux-text (Text-Version) oder doc-linux-html (HTML-Version) verfügbar sein. Ein anderes nützliches Dokument ist http://www.psionic.com/papers/dns/dns-linux.

Wenn Sie für Bind 8.2.3 (aus Debian potato) einen kompletten Chroot-Käfig ausetzen (d.h. Sie benutzen nicht nur -t) , stellen Sie sicher, dass Sie die folgenden Zeilen benutzen:

     dev/log -  syslogd sollte hierrauf 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 Lin auf ld-2.1.3.so
     lib/libc.so.6 - symbolischer Lin 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/

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 compilieren. Sie können hierzu apt-get mit der source Option benutzen. Es kann sogar die Pakete herunterladen, die Sie zum Compilieren benötigen. Sie müssten etwas ähnlich wie das hier tun:

     $ 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 befor die @CFLOAGS@ Definition von autoconf verwendet wird)
     $ dpkg-buildpackage -rfakeroot
     $ cd ..
     $ dpkg  -i bind-8.2.5-2*deb

Nach der Installation werden Sie die Dateien im chroot-Gefängniss verschieben müssen [6]. 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 in dem Sie bei den start-stop-daemon Aufrufen in diesen Skripts --chroot /location_of_chroot hinzufügen.

FIXME, merge info from http://people.debian.org/~pzn/howto/chroot-bind.sh.txt, http://people.pdxlinux.org/~karlheg/ (Bind9 on Debian), http://www.cryptio.net/~ferlatte/config/ (Debian-specific), http://www.psionic.com/papers/whitep01.html, http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm and http://www.acmebw.com/papers/securing.pdf.


5.9 Absichern von Apache

FIXME: Add content.

Sie können den Zugriff auf Ihren Apache Server einschränken, wenn Sie ihn nur intern benutzen wollen (zum Beispiel zu Test Zwecken, oder um auf die doc-central Archive zuzugreifen, etc.) und nicht wollen, dass von aussen 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 anschliessen den Apache mit /etc/init.d/apache restart neu, und Sie werden sehen, dass er nur auf die lokale Schleife achtet.

In jedem Fall solten 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 Sicherheitsmassnahmen, die Sie auf einem Apache Webserver anwenden können, bereit (die gleichen Informationen erhalten Sie unter Debian auch durch das Paket apache-doc).


5.10 Absichern von finger

Wenn Sie einen Finger-Service laufen lassen wollen, fragen Sie sich bitte zuerst, ob Sie ihn 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 apt-cache search fingerd):

ffingerd ist der empfohlene finger Daemon, wenn Sie vorhaben, einen öffentlichen Service 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 Sei ihn nur auf die Schnittstellen achten, auf die er achten muss.


5.11 Allgemeine chroot und suid Paranoia

Wahrscheinlich ist es nur fair zu sagen, dass die Kompexität von BIND der Grund dafür ist, warum er in den letzten Jahren so oft für Attacken verwundbar war.

Dies trifft auch auf andere Programme mit Komplexen Funktionen und grösserer Nutzergemeinde zu, einschliesslich sendmail und einige ftp-Daemonen (z.B. WUftpd). (Natürlich kann auch ein Programm ohne viele Funktionen, das seine Nutzer nicht zufriedenstellt, unsicher sein, abgesehen dass es nutzlos ist.)

In jedem Fall sollten Sie, wenn Sie diese laufen lassen, ähnliche Arragements für Sie in Erwägung ziehen — entziehen von root-Privilegien, einsperren in ein chroot-Gefängniss — oder ersetzen durch ein sichereres Äquivalent.


5.12 Allgemeine Klartextpasswort Paranoia

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

Vergessen Sie jedoch nicht, dass die Migration von telnet zu ssh die Sicherheit in keinster Weise erhöt, 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 Services zu ersetzen. Sie sollten in Erwägung ziehen von diesen Services zu Ihren SSL-Versionen zu wechseln: ftp-ssl, telnet-ssl, pop-ssl, https ...

Die meisten der oben aufgelisteten Tips gelten für jedes Unixoide-System (Sie werden sie in jedem anderen Sicherheits-Relevanten Dokument, das sie jemals lesen, wiederfinden, wenn es sich auf Linux und andere Unices bezieht).


5.13 NIS deaktivieren

Sie sollten, wenn möglich, nicht NIS, den Network Information Service, benutzen, da er das teilen von Passworten erlaubt. Dies kann sehr unsicher sein, wenn Ihr Setup kaputt geht.

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

Lesen Sie mehr zu Sicherheit und NIS in der NIS-HOWTO (/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz).

FIXME (jfs): Add info on how to setup this in Debian


5.14 Abschalten von RPC-Servicen

Sie sollten RPC wannimmer nur möglich abschalten, dass ist dann der Fall, wenn Sie ihn nicht benötigen. [7] Es sind viele Sicherheits-Löcher sowohl für den Portmapper-Service als auch für RPC-basierende Services bekannt und könnten sehr leicht ausgenutzt werden. Andererseits können NFS-Service in manchen netzwerken sehr wichtig sein, also versuchen Sie in Ihrem Netzwerk die Balance zwischen Sicherheit und Nutzbarkeit zu waren. Einige DDoS (distributed denial of service) Angriffe benutzen rpc-Löcher, um in das System einzudringen und als sogennanter Agent/Handler zu fungieren. Lesen Sie mehr zu Sicherheit in NFS in NFS-HOWTO (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz).

Das Abschalten von Portmap ist relativ einfach. Es gibt aber verschiedene Methoden. Die einfachste is es auf einem Debian 3.0 System einfach das Paket portmap zu deinstallieren. Wenn Sie eine eine andere Version laufen haben, werden Sie den Service, wie in Daemon-Services abschalten, Abschnitt 3.6.1 beschrieben, abschalten müssen, dies liegt daran, dass das Programm Teil des Pakets net-base (das nicht deinstalliert werden kann, ohne das System kaputt zu machen) sein kann.

Dies entfernt in der Tat jeden symbolischen Link der etwas mit Portmap zu tun hat unterhalb von /etc/rc${runlevel}.d/, was Sie auch manuell erledigen können. Eine andere Möglichkeit ist chmod 644 /etc/init.d/portmap, das erzeugt aber eine Fehlermeldung während des Bootens. Sie können auch den start-stop-daemon Teil im /etc/init.d/portmap Shell-Skript auskommentieren.


5.15 Hinzufügen von Firewall Fähigkeiten

Das Debian GNU/Linux Betriebssystem hat die eingebauten Fähigkeiten des Linux Kernels. Dies heisst, dass Sie, wenn Sie ein Potato (Debian 2.2) System installiert haben (mit dem default Kernel 2.2) werden Sie ipchains Firewall-Unterstützung im Kernel haben. Sie müssen dann das Paket ipchains installieren, was (durch seine Priorität) sicherlich bereits der Fall ist. Wenn Sie ein Woody-System (Debian 3.0) installiert haben (mit dem standard 2.4er Kernel) unterstützt der Kernel Ihr iptables (neftfilter). Der Hauptunterschied zwischen ipchains und iptables ist, dass letzeres auf stateful packet inspection (zustandsbehaftete Paket Untersuchung), so dass Ihnen sicherere (und einfacher zu wartende) Filter-Konfigurationen zur Verfügung stehen.


5.15.1 Firewallen des lokalen Systems

Sie können eine Firewall dazu benutzen, den Zugriff auf Ihr lokales System und sogar die Kommunikation von ihm nach aus absicher. Firewall-Regeln lönnen dazu benutzt werden, Prozesse, die nicht vernünftigt konfiguriert werden können, zu schützen, aber nicht um Services für Netzwerke, IP-Adressen, etc. zur Verfügung zu stellen.

Dieser Schritt ist aber hauptsächlich deshalb als letztes 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 auf mehreren Ebenen zusammen; eine Firewall sollte die letzte sein, wenn alle Services abgehärtet worden sind. Sie können sich sicherleich leicht eine Konfiguration vorstellen, bei der ein System lediglich von einere ingebauten Firewall geschützt, und der Admistrator glückseelige Administrator 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 Schutzmassnahmen auf dem System gibt.

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

Demzufolge wäre ein passendes Firewall-Setup, eines mit einer default deny policy (also alles ablehnt, dass nicht ausdrücklich erlaubt ist), und weiterhin:


5.15.2 Schützen andere Systeme durch eine Firewall

Eine Debian Firewall kann auch so installiert werden, dass Sie, mit Firewall-Regeln, Systeme hinter ihr beschützt, indem es die Angriffsfläche zum Internet hin einschränkt. Die Firewall kann so konfiguriert werden, dass sie verhindert dass System von ausserhalb des lokalen Netzwerks Zugriff auf nicht öffentliche Services (Ports) verhindert. Zum Beispiel muss auf einem Mail-Server lediglich Port 25 (auf den der Mail-Service aufsetzt) von aussen zugänglich sein. Eine Firewall kann so konfiguriert werden, dass sogar wenn es öffentlich zugängliche Services gibt, direkt gesendete Pakete verwirft (dies nennt man filtern).

Sie können eine Debian GNU/Linux Maschine sogar so konfigurieren, dass er als Bridge-Firewall (überbrückender Schutzwall) fungiert, d.h. eine filternde Firewall, die komplett transparent zum gesamten Netzwerk erscheint, und 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 der neuen Option netfilter ( firewalling ) suport auswählen. Sehen Sie dazu Aufsetzen einer Überbrückenden Firewall (bridge Firewall), Anhang D, um zu erfahren, wie man dies auf einem Debian GNU/Linux System aufsetzt.


5.15.3 Konfigurieren der Firewall

Natürlich hängt die Konfiguration einer Firewall immer vom System und dem Netzwerk abhängig. Ein Administrator muss vorher das Netzwerk Layout 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 vorsichtig, wenn Sie Ihre Firewall konfigurieren. Wie Laurence J. Lane im iptables Paket sagt:

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

Vergessen Sie nicht: Das einfache installieren von iptables (oder älterem Firewall Coe) gibt Ihnen keine Sicherehit, es stellt lediglich die Software zur Verfügung. Um eine Firewall zu haben, müssen Sie sie konfigurieren.

Wenn Sie nicht viel über Firewalls wissen, lesen Sie die Firewalling-HOWTO, die Sie im Paket doc-linux-text finden (andere Formate gibt es auch). Sehen Sie auch Seien Sie Wachsam gegenüber generellen Sicherheitsproblemen!, Abschnitt 2.2 für weitere (allgemeinere) Verweise.


5.15.3.1 Machen Sie's auf die Debian Art

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

Hierzu müssen Sie folgendes tun:

Sobald dies geschehen ist, ist Ihr Firewall-Setup im Verezichnis /var/lib/iptables/ gespeichert und wird beim System-Boot ausgeführt (oder wenn das initd Skript mit start und stop gestartet wird). Beachten Sie, dass standard Einstellung unter Debian vorsehen, den Firewall-Code in den Multiuser Runleveln (2 bis 5) sehr früh (10) zu starten. Ausserdem wird er im singleuser Runlevel (1) gestoppt. Ändern Sie dies, wenn es nicht Ihren lokalen Richtlinien entspricht.

Wenn Sie keine Ahnung haben, wie Sie Ihre Firewall-Rules manuell aufsetzen sollen, sehen Sie in der Packet Filtering HOWTO und NAT HOWTO aus dem Paket iptables, zu browsen unter /usr/share/doc/iptables/html/. Zudem stellt die Konfigurationsdatei /etc/default/iptables noch weitere Informationen zu diesem Paket zur Verfügung.


5.15.3.2 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 grosse Zahl von Tools erstellt, die zur einfachen Konfiguration einer Lokalen Firewall benutzt werden können. Seien Sie vorgewarnt, dass einige Dieser Tools sich mehr auf lokalen Schutz konzentrieren (auch personal firewall genannt), während andere vielseitiger, und lönnen dazu benutzt werden, komplexere Regelwerke zum Schutz ganzer Netzwerke zu erstellen.

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

Die Pakete gfcc,firestarter und knetfilter sind graphische Administrations-Schnittstellen die entweder GNOME (die ersten beiden) oder KDE (das letzte) benutzen, die eher Nutzer orientiert sind (z.B. für Heimanwender) als die andere Pakete in der Liste, die sich eher an Administratioren richten.

Seien Sie vorgewarnt, dass manche der zuvor skizzierten Pakete eigene Firewall-Skripte einführen, die beim System-Start ausgeführt werden sollen, die zweifelsohne mit dem allgemeinen Setup (wenn es erfolgte) mit unerwünschten Nebeneffekten kollidieren wird. Das Firewall-Skript, das zuletzt ausgeführt wird, wird das das System konfigueren (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 anderen Konfigurations-Dateien beissen.

FIXME: Add more info regarding this packages

FIXME: Check Information on Debian firewalling and what/how does it change from other distributions.

FIXME: Where should the custom firewalling code be enabled (common FAQ in debian-firewall?)


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

Anleitung zum Absichern von Debian

2.5 (beta) 20 septiembre 2003Sat, 17 Aug 2002 12:23:36 +0200

Javier Fernández-Sanguino Peña jfs@computer.org