[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Dienste können auf zwei Arten in einem laufenden System abgesichert werden:
Sie so einstellen, dass auf sie nur von Zugangspunkten (Interfaces) zugegriffen werden kann, von denen es nötig ist.
Sie so konfigurieren, dass sie nur von legitimierten Nutzern auf autorisierte Art und Weise benutzt werden können.
Dienste können durch Zugriffsbeschränkungen auf Kernel-Ebene (durch eine Firewall) eingeschränkt werden, so dass auf sie nur von bestimmten Orten aus zugegriffen werden kann. Konfigurieren Sie sie, so dass sie nur auf eine bestimmte Schnittstelle horchen (einige Dienste bieten diese Fähigkeiten vielleicht nicht). Oder verwenden Sie eine andere Methode, zum Beispiel den Linux-vserver-Patch (für 2.4.16), mit dem Prozesse auf eine bestimmte Schnittstelle gebunden werden können.
Was die Dienste angeht, die von inetd
aufgerufen werden
(telnet
, ftp
, finger
, pop3
,
...), so ist es wert zu erwähnen, dass inetd
so konfiguriert
werden kann, dass er nur auf eine bestimmte Schnittstelle reagiert (unter
Verwendung der service@ip-Syntax). Dies ist jedoch eine nicht
dokumentierte Eigenschaft. Ein Ersatz, der Meta-Daemon xinetd
,
kennt eine bind-Option nur 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 detaillierter darauf ein, wie bestimmte Dienste abhängig von der beabsichtigten Benutzung passend konfiguriert werden.
Wenn Sie immer noch telnet statt ssh benutzen, sollten Sie dieses Handbuch kurz beiseite legen, und dies ändern. Ssh sollte anstelle von telnet für alle Fern-Logins benutzt werden. In einer Zeit, in der es leicht ist, Internet-Verkehr mitzuschnüffeln und an Klartext-Passwörter heranzukommen, sollten Sie lediglich Protokolle verwenden, die Kryptographie benutzen. Also führen Sie sofort ein apt-get install ssh auf Ihrem System aus.
Ermuntern Sie alle Nutzer Ihres Systems, ssh anstelle von telnet zu benutzen,
oder noch besser: Deinstallieren Sie telnet/telnetd. Zusätzlich sollten Sie es
vermeiden, sich mit ssh als root einzuloggen und lieber andere Methoden
benutzen, um root zu werden. Wie zum Beispiel su
oder
sudo
. Schließlich sollten Sie noch die Datei
/etc/ssh/sshd_config
für mehr Sicherheit modifizieren:
ListenAddress 192.168.0.1
Lassen Sie ssh nur auf eine bestimmte Schnittstelle hören, falls Sie mehrere haben (und ssh nicht auf allen verfügbar sein soll) oder Sie in Zukunft eine neue Netzwerkkarte einbauen werden (und keine ssh-Verbindungen auf ihr erlauben wollen).
PermitRootLogin no
Versuchen Sie so wenige Logins als Root wie möglich zu erlauben. Wenn nun jemand Root werden will, benötigt er zwei Logins. So kann das Root-Passwort nicht so leicht ausgetestet werden.
Port 666 oder ListenAddress 192.168.0.1:666
Verändern Sie den Listen-Port, so dass ein Eindringling nicht wirklich sicher sein kann, ob ein sshd-Daemon läuft (aber beachten Sie, dass dies lediglich "Sicherheit durch Verschleierung" ist).
PermitEmptyPasswords no
Nicht gesetzte Passwörter verspotten jegliche System-Sicherheit.
AllowUsers alex ref ich@irgendwo
Erlauben Sie nur bestimmten Nutzern sich via ssh auf der Maschine einzuloggen. user@host kann auch verwendet werden, um einen bestimmten Benutzer user dazu zu zwingen, nur von einem bestimmten Rechner host aus zuzugreifen.
AllowGroups wheel admin
Erlauben Sie nur bestimmten Gruppenmitgliedern sich via ssh auf der Maschine einzuloggen. AllowGroups und AllowUsers haben äquivalente Verfahrensweisen, um den Zugang zu der Maschine zu verwehren. Es wird nicht überraschen, dass es sich hierbei um "DenyUsers" und "DenyGroups" handelt.
PasswordAuthentication yes
Es ist allein Ihre Wahl, was Sie hier eintragen. Es ist sicherer, Zugriff nur
Nutzern zu erlauben, die ssh-Schlüssel in der
~/.ssh/authorized_keys
-Datei haben. Wenn Sie dies wollen, setzen
Sie es auf "no".
Schalten Sie jedwede Art der Authentifizierung ab, die Sie nicht wirklich
benötigen, zum Beispiel RhostsRSAAuthentication,
HostbasedAuthentication, KerberosAuthentication oder
RhostsAuthentication. Sie sollten sie abschalten, auch wenn sie
es standardmäßig bereits sind (siehe dazu die Handbuch-Seite
sshd_config(5)
).
Protocol 2
Deaktivieren Sie die Protokollversion 1, da diese einige Designschwächen hat,
die es einfacher zu machen, Passwörter zu knacken. Für weitere Informationen
lesen Sie a paper regarding
ssh protocol problems
oder das Xforce advisory
.
Banner /etc/eine_Datei
Fügen Sie einen Bannertext (er wird aus der Datei bezogen) für Benutzer, die sich mit dem ssh-Server verbinden, hinzu. In einigen Ländern sollte das Senden einer Warnung über unautorisierten Zugriff oder Benutzerüberwachung vor dem Zugriff zu einem bestimmten System erfolgen, um sich rechtlich abzusichern.
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
.
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 für Debian paketiert. Sie sollten stattdessen
das pam_chroot
-Modul, wie in in Den Nutzerzugang einschränken, Abschnitt
4.11.8 beschrieben, verwenden.
In Chroot
-Umgebung für
SSH
, Anhang G können Sie verschiedene Optionen finden, um
Chroot-Umgebungen für SSH zu erstellen.
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.
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. Um jedoch den Zugang zu
scp
einzuschränken, müssen Sie entweder:
den Benutzern verbieten, sich auf dem ssh-Server einzuloggen (wie oben beschrieben entweder durch die Konfigurationsdatei oder die PAM-Konfiguration), oder
Benutzern, denen sichere Übertragungen verwehrt sind, richtige Shells vorenthalten. Die angebotenen Shells sollten dennoch Programme sein, die Verbindungen zum ssh-Server sinnvoll gestalten, wie z.B. Menü-Programme (a la BBS). Andernfalls ist die vorherige Möglichkeit bevorzugt.
Squid ist einer der verbreitetsten Proxy/Cache-Server und es gibt ein paar
Sicherheitsaspekte, die Sie beachten sollten. Squids Standard-Konfiguration
lehnt alle Anfragen von Benutzern ab. Dennoch erlaubt das Debian-Paket Zugriff
von 'localhost', Sie müssen nur Ihren Browser richtig konfigurieren. Sie
sollten Squid so konfigurieren, dass er Zugriffe von vertrauenswürdigen
Nutzern, Computern oder Netzwerken erlaubt, indem Sie eine
Zugriffs-Kontroll-Liste (ACL, Access Control List) in
/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, inklusive Cache-Speicher (Option cache_mem), Lage der gecachten Dateien und der verwendeten Speichermenge auf der Platte (Option cache_dir).
Man beachte, dass es bei ungeeigneter Konfiguration vorkommen kann, dass jemand eine Mail über Squid weiterleitet, da die Protokolle HTTP und SMTP ein ähnliches Design haben. Squids Standardkonfiguration verweigert Zugriffe auf Port 25. Wenn Sie Verbindungen an Port 25 erlauben wollen, fügen Sie ihn einfach zu der Safe_ports-Liste hinzu. Aber dies ist NICHT empfohlen.
Passendes Aufsetzen und Konfigurieren des Proxy/Cache-Servers ist nur ein Teil der Absicherung Ihrer Seite. Eine andere notwendige Aufgabe ist es, Squids Log-Dateien zu analysieren, um sicher zu gehen, dass alles so arbeitet, wie es sollte. Es gibt ein paar Pakete in Debian GNU/Linux, die einem Administrator hierbei helfen können. Die folgenden Pakete sind in Debian 3.0 (Woody) und Debian 3.1 (Sarge) verfügbar:
calamaris
- Log-Datei-Analysator für Squid oder
Oops-Proxy-Log-Dateien.
modlogan
- Ein modularer Log-Datei-Analysator.
sarg
- Squid Analysis Report Generator.
squidtaild
- Squid-Log-Beobachtungsprogramm.
Wenn Squid im »Accelerator Mode« betrieben wird, agiert er auch als Web-Server.
Aktivieren dieser Option erhöht die Komplexität des Codes, was ihn weniger
vertrauenswürdig macht. Standardmäßig ist Squid nicht dazu konfiguriert, als
Web-Server zu arbeiten, Sie müssen sich darüber also keine Gedanken machen.
Sie müssen sicher stellen, dass es wirklich nötig ist, wenn Sie diese
Eigenschaft nutzen wollen. Weitere Informationen über den »Accelerator Mode«
in Squid finden Sie im Squid User's
Guide - Accelerator Mode
.
Wenn Sie wirklich FTP benutzen müssen (ohne ihn mit sslwrap zu umhüllen oder
innerhalb eines SSL- oder SSH-Tunnels), sollten Sie ftp in das Home-Verzeichnis
der FTP-Nutzer mit chroot einsperren, so dass sie nichts anderes sehen können
als ihr eigenes Verzeichnis. Andernfalls können sie Ihr Root-Dateisystem
durchlaufen, als hätten sie Shell-Zugriff darauf. Sie können die folgende
Zeile in Ihre 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 Nutzern Zugriff
via SSH gewähren, könnten Sie auf ein typisches Problem stoßen. Benutzer, die
innerhalb eines mit SSH abgesicherten Systems auf einen anonymen FTP-Server
zugreifen wollen, können versuchen, sich auf dem 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 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
.
Heutzutage werden X-Terminals in immer mehr Firmen benutzt, wo ein Server für viele Arbeitsplätze benötigt wird. Dies kann gefährlich sein, weil Sie dem Datei-Server erlauben müssen, sich mit den X-Clients zu verbinden (X-Server aus Sicht von X. X vertauscht die Definition von Client und Server). Wenn Sie dem (sehr schlechten) Vorschlag von vielen Dokumentationen folgen, geben Sie auf Ihrer Maschine 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 auf eine andere Maschine via ssh einloggen. Damit dies funktioniert,
müssen Sie den ssh-Client und den ssh-Server konfigurieren. Auf dem ssh-Client
sollte ForwardX11 in /etc/ssh/ssh_config
auf
yes gesetzt sein. Auf dem ssh-Server sollte
X11Forwarding in /etc/ssh/sshd_config
auf
yes gesetzt sein und das Paket xbase-clients
sollte
installiert sein. Letzteres 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 (der Xserver aus Debian 3.0
und 3.1). Wenn Sie XFree 3.3.6 laufen lassen (d.h. wenn Sie Debian 2.2
benutzen), können Sie /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 [41].
Sie können außerdem die standardmäßige Zeitgrenze für die
xscreensaver
-Bildschirmsperre setzen. Auch wenn der Nutzer 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
*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.
Wenn Sie einen Display-Manager lediglich zur lokalen Nutzung (um einen schönen graphischen Login zu haben) haben wollen, gehen Sie sicher, dass der XDMCP (X Display Manager Control Protocol) Krempel abgeschaltet ist. Unter XDM können Sie dies mit der folgenden Zeile in /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.
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 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 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 Druck-Dienst so konfigurieren müssen, dass
er nur Aufträge von vertrauenswürdigen Rechnern annimmt. Hierzu müssen Sie die
Rechner, von denen Sie Druckaufträge entgegennehmen möchten, in die Datei
/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 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 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 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 dies erfordert, dass der Server auf irgendeinem Port lauscht.
Wie auch immer: Wenn Sie cups
nur lokal benutzen möchten, können
Sie ihn so konfigurieren, dass er nur auf die lokale Schleife (loopback
interface) hört, indem Sie Folgendes in Ihrer /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 gehört 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 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.
Wenn Ihr Server kein Mail-System ist, müssen Sie wirklich keinen Mail-Daemon haben, der auf eingehende Verbindungen reagiert. Aber Sie wollen lokale Mails ausliefern, um beispielsweise Mails an den Root-User von irgendwelchen Alarmsystemen zu erhalten.
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.6.1 wie man dies erledigt.
Sie mögen einen lokalen Mail-Daemon wollen, so dass er die Mails, die vom lokalen Rechner zu einem anderen System geschickt wurden, versenden kann. Dies ist üblich, wenn Sie eine Anzahl von Systemen zu administrieren haben und nicht zu jedem von diesen eine Verbindung aufbauen wollen, um die dort lokal verschickten Mails zu lesen. Genau wie all das Protokollieren eines jeden individuellen Systems durch einen zentralen syslog-Server zentralisiert werden kann, so kann auch Mail zu einem zentralen Mail-Server gesandt werden.
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 entfernten
Verbindungen 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 die lokale Schleife
achtet. In exim
(dem Standard-Mail-Transport-Agent (MTA) unter
Debian) tun Sie dies, indem Sie 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 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 [42] und sehen, welcher davon am besten auf Ihr System
zugeschnitten ist.
Wenn Sie entfernten Zugriff auf Mailboxen erlauben wollen, gibt es eine Anzahl von möglichen POP3- und IMAP-Daemonen.[43] 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.
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 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, 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 umhüllt den angegebenen Daemon (-l) an den Port (-d) und nutzt ein bestimmtes SSL-Zertifikat (-p).
Es gibt verschiedene Dinge, mit denen Sie sich auseinander setzen sollten, um einen Domain-Server-Daemon abzusichern, die ähnlich zu den Überlegungen sind, wie man einen anderen Dienst absichert:
Konfigurieren Sie den Daemon selbst, so dass er von außen nicht missbraucht werden kann (siehe auch Bind-Konfiguration um Missbrauch zu verhindern, Abschnitt 5.7.1). Dies schließt das Einschränken von Abfragen durch Clients ein: Zonen-Transfers und rekursive Abfragen.
Einschränken des Zugriffs des Daemon auf den Server selbst, so dass dem Schaden für das System im Falle eines Einbruchs Grenzen gesetzt sind. Hierzu gehört auch, den Daemon als nicht-privilegierten Benutzer laufen zu lassen (siehe Ändern des BIND-Benutzers, Abschnitt 5.7.2) und ihn in ein Chroot-Gefängnis einzusperren (siehe Chroot-Gefängnis für Name-Server, Abschnitt 5.7.3).
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 Nutzer Abfragen starten, aber, da der Port für Angreifer von außen ansprechbar ist, könnten sie versuchen, den DNS zum Absturz zu bringen (oder durch Speicher-Überlauf-Attacken auszunutzen). Sie könnten ihn sogar dazu bringen, lediglich auf 127.0.0.1 zu hören, wenn Sie den DNS-Service nicht für ein anderes System anbieten wollen.
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 in der folgenden Art:
options { ... verschiedene andere Optionen ... version "Nicht verfuegbar."; };
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 "meineseite.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.
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.
Um BIND unter einem anderen Benutzer laufen zu lassen, müssen Sie zunächst einen separaten Benutzer und eine separate 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 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 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[44]:
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u 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 wo 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, 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 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.
Um die größtmögliche BIND-Sicherheit zu erreichen, müssen Sie nun ein
Chroot-Gefängnis (siehe Allgemeine chroot- und
suid-Paranoia, Abschnitt 5.10) um Ihren Daemon herum bauen. Es gibt einen
einfachen Weg, dies zu erreichen: Die Option -t (siehe die
Handbuchseite named(8)
oder Seite 100 von Bind's 9
Dokumentation (PDF)
). Dies wird Bind selbst in ein bestimmtes
Verzeichnis chrooten lassen, ohne dass Sie ein eigenes Chroot-Gefängnis
aufsetzen und sich Sorgen um dynamische Bibliotheken machen müssen. Die
einzigen Dateien, die in diesem Chroot-Gefängnis benötigt werden, sind:
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:[45]
dev/log - syslogd sollte hierauf hören dev/null etc/bind/named.conf etc/localtime etc/group - mit einer einzigen Zeile: "named:x:GID:" etc/ld.so.cache - mit ldconfig erstellt lib/ld-2.1.3.so lib/libc-2.1.3.so lib/ld-linux.so.2 - symbolischer Link auf ld-2.1.3.so lib/libc.so.6 - symbolischer Link auf libc-2.1.3.so sbin/ldconfig - kann gelöscht werden, nachdem Chroot aufgesetzt wurde sbin/named-xfer - wenn Sie Namen transferieren var/run/
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.[46] 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.
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-spezifisch), http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html
und http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm
.
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.
Die Standard-Apache-Installation in Debian erlaubt Benutzern Inhalt unter
$HOME/public_html
bereitzustellen. Dieser Inhalt kann aus 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
Beachten Sie, dass disabled nur ab Version 1.3 von Apache verfügbar ist [47].
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.
Apache-Log-Dateien gehören seit 1.3.22-1 dem Benutzer 'root' und der Gruppe 'adm' mit den Rechtebits 640. Diese Rechte ändern sich nach einer Rotation. Ein Eindringling, der das System über den Web-Server erreicht hat, kann so alte Log-Datei-Einträge nicht (ohne Rechteerweiterung) entfernen.
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.
Wenn Sie den Finger-Dienst laufen lassen wollen, fragen Sie sich bitte zuerst,
ob Sie das auch wirklich tun müssen. Wenn Sie es müssen, werden Sie
feststellen, dass Debian viele Finger-Daemonen zur Verfügung stellt (hier die
Ausgabe von apt-cache search fingerd
):
cfingerd - Konfigurierbarer finger-Daemon
efingerd - Ein weiterer Unix-finger-Daemon mit anpassbarer Ausgabe
ffingerd - Ein sicherer finger-Daemon
fingerd - Remote-User Informationsserver
xfingerd - BSD-ähnlicher finger-Daemon mit qmail-Unterstützung
ffingerd
ist der empfohlene finger-Daemon, wenn Sie vorhaben,
einen öffentlichen Dienst anzubieten. In jedem Fall sind Sie dazu angespornt,
wenn Sie ihn über inetd, xinetd oder tcpserver laufend aufzusetzen: Schränken
Sie die Anzahl der Prozesse die gleichzeitig laufen dürfen ein. Schränken Sie
den Zugriff auf den Finger-Daemon von bestimmten Hosts ein (indem Sie
tcp-wrapper benutzen) und lassen Sie ihn nur auf die Schnittstellen lauschen,
auf die er achten muss.
chroot
ist eine der mächtigsten Möglichkeiten, einen Daemon oder
einen Benutzer oder einen anderen Dienst zu beschränken. Denken Sie einfach an
ein Gefängnis um Ihr Ziel, das das Ziel nicht verlassen kann (normalerweise, es
gibt aber einige Bedingungen, die einem einen Ausbruch aus solch einem
Gefängnis gestatten). Wenn Sie einem Benutzer oder einem Dienst nicht trauen,
können Sie eine modifizierte root-Umgebung für ihn erzeugen. Dies kann einiges
an Plattenplatz benötigen, da Sie alle benötigten Programme ebenso wie
Bibliotheken in das Gefängnis kopieren müssen. Aber danach ist die Wirkung des
Schadens, selbst wenn der Benutzer etwas bösartiges macht, auf das Gefängnis
beschränkt.
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.[48]
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 Sichern 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: Entziehen 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 limitieren Sie die Möglichkeiten einer Rechteerweiterung
durch lokale Sicherheitsverwundbarkeiten des Systems. Selbst in dieser
Situation können Sie nicht völlig sicher sein, dass es für einen cleveren
Angreifer keinen Weg gibt, irgendwie aus dem Gefängnis auszubrechen. Verwenden
von nur sicheren Server-Programmen, die einen guten Ruf bezüglich Sicherheit
haben, ist eine zusätzliche gute Sicherheitsmaßnahme. Selbst kleinste Löcher
wie offene Datei-Handle können von einem versierten Angreifer zum Einbruch in
das System verwendet werden. Schließlich war chroot
nicht als
Sicherheitstool gedacht, sondern als ein Testwerkzeug.
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.
Sie sollten versuchen, jeden Netzwerk-Dienst, der seine Passworte als Klartext über das Netz sendet oder empfängt, wie zum Beispiel FTP/Telnet/NIS/RPC, vermeiden. Der Autor empfiehlt jedem, ssh anstelle von telnet und ftp zu verwenden.
Vergessen Sie jedoch nicht, dass die Migration von telnet zu ssh die Sicherheit in keinster Weise erhöht, wenn Sie weiterhin Klartext-Protokolle verwenden. Am besten wäre es ftp, telnet, pop, imap und http zu entfernen und durch ihre entsprechenden verschlüsselten Dienste zu ersetzen. Sie sollten in Erwägung ziehen von diesen Diensten zu deren SSL-Versionen zu wechseln: ftp-ssl, telnet-ssl, pop-ssl, https, ...
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).
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.
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.
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.6.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.
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:
Blockieren des Zugangs zu den Ports, die von diesen Diensten verwendet werden, mit einer lokalen Firewall (vergleiche Hinzufügen von Firewall-Fähigkeiten, Abschnitt 5.14).
Blockieren des Zugangs zu diesen Diensten mittels TCP-Wrappers, da der
Portmapper (und einige RPC-Dienste) mit libwrap
(siehe Die Nutzung von tcpwrappers, Abschnitt
4.12) kompiliert worden. Dies bedeutet, dass Sie Zugang zu diesen durch
die hosts.allow
und hosts.deny
TCP-Wrapper-Konfiguration blockieren.
Seit Version 5-5 kann das Paket portmap
so konfiguriert werden,
dass es nur noch an der lokalen Schleifenschnittstelle lauscht. Um dies zu
erreichen, kommentieren Sie die folgende Zeile in der Datei
/etc/default/portmap
aus: #OPTIONS="-i
127.0.0.1" und starten Sie den Portmapper neu. Dies ist
ausreichend, um lokale RPC-Dienste laufen zu lassen, während zur selben Zeit
entfernte Systeme am Zugang gehindert werden (lesen Sie dazu auch Lösung des Problems der Weak-End-Hosts,
Abschnitt 4.18.5).
Das Debian-GNU/Linux-Betriebssystem hat die eingebauten Fähigkeiten des
Linux-Kernels.[49] Dies heißt,
dass Sie, wenn Sie ein Potato-System (Debian 2.2 mit dem standardmäßigen Kernel
2.2) installiert haben, ipchains
Firewall-Unterstützung im Kernel
haben. Das Paket ipchains
sollte bereits (aufgrund seiner
Priorität) installiert sein. Wenn Sie ein Debian 3.0 (oder 3.1) System
installiert haben (der Standard-Kernel ist 2.4), so verfügen Sie auch über die
iptables
(netfilter) Firewall. Der Hauptunterschied zwischen
ipchains
und iptables
ist, dass letzteres auf
stateful packet inspection (zustandsbehaftete Paketuntersuchung)
beruht, so dass Ihnen sicherere (und einfacher zu erstellende)
Filterkonfigurationen zur Verfügung stehen.
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 Deny-Policy (was also alles ablehnt, was nicht ausdrücklich erlaubt ist), und weiterhin:
Eingehende Verbindungen werden nur zu lokalen Diensten von erlaubten Maschinen gestattet.
Ausgehende Verbindungen werden nur von Diensten erlaubt, die auf Ihrem System benutzt werden (DNS, Web-Surfen, POP, E-Mail, ...).[50]
Die Forward-Regel verbietet alles; es sei denn, andere Systeme werden geschützt (siehe dazu unten).
Alle anderen eingehenden und ausgehenden Verbindungen werden abgelehnt.
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 Aufsetzen einer überbrückenden Firewall (bridge Firewall), Anhang D, um zu erfahren, wie man dies auf einem Debian GNU/Linux System aufsetzt.
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.
Natürlich ist die Konfiguration einer Firewall immer vom System und dem
Netzwerk abhängig. Ein Administrator muss vorher das Netzwerklayout und die
Systeme, die er beschützen will, kennen, die Dienste, auf die zugegriffen
werden können muss, und ob andere netzwerkspezifischen Erwägungen (wie NAT oder
Routing) berücksichtigt werden müssen. Seien Sie vorsichtig, wenn Sie Ihre
Firewall konfigurieren. Wie Laurence J. Lane im iptables
-Paket
sagt:
Die Werkzeuge können leicht falsch verwendet werden und eine Menge Ärger verursachen, indem sie den gesamten Zugang zu einem Computernetzwerk stilllegen. Es ist nicht völlig ungewöhnlich, dass sich ein Systemadministrator, der ein System verwaltet, das hunderte oder tausende von Kilometern entfernt ist, irrtümlicherweise selbst davon ausgeschlossen hat. Man kann es sogar schaffen, sich von dem Computer auszusperren, dessen Tastatur unter seinen Fingern liegt. Lassen Sie daher die gebotene Vorsicht walten.
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
.
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:
firestarter
, eine GNOME-Anwendung, die sich an Endanwender
richtet, die einen Wizard enthält, der nützlich ist, um schnell Firewall-Regeln
aufzustellen. Die Anwendung enthält eine graphische Oberfläche zum Beobachten,
ob eine Firewall-Regel Daten blockiert.
fwbuilder
, eine objektorientierte graphische Oberfläche, die
Richtlinien-Compiler für verschiedene Firewall-Plattformen inklusive Linux'
netfilter, BSDs pf (verwendet in OpenBSD, NetBSD, FreeBSD und MacOS X) ebenso
wie Zugriffslisten von Routern enthält. Es ist ähnlich zu
Enterprise-Firewall-Management-Software. Die vollständige Funktionalität von
fwbuilder ist auch von der Kommandozeile verfügbar.
shorewall
, ein Firewall-Konfigurationswerkzeug, das Unterstützung
für IPsec sowie beschränkte Unterstützung für Traffic Shaping und die
Definition der Firewall-Regeln bietet. Die Konfiguration geschieht durch eine
einfache Menge von Dateien, die verwendet werden, um die iptables-Regeln
aufzustellen.
guarddog
, ein KDE-basiertes Firewall-Konfigurations-Paket, das
sich an Anfänger wie auch an fortgeschrittene Benutzer richtet.
knetfilter
, eine KDE-Oberfläche zur Verwaltung von Firewall- und
NAT-Regeln für iptables (Alternative/Konkurrent zum guarddog-Werkzeug, obwohl
es sich leicht an fortgeschrittene Benutzer richtet).
bastille
, diese Härtungsanwendung ist in Automatisches Abhärten von Debian-Systemen,
Kapitel 6 beschrieben. Einer der Härtungsschritte, die der Administrator
konfigurieren kann, ist eine Definition des erlaubten und verbotenen
Netzwerkverkehrs, der verwendet wird, eine Anzahl von Firewall-Regeln, die das
System am Start ausführt, zu generieren.
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 dem Erstellen von Firewall-Regeln zum
Schützen des Rechners, auf dem sie laufen, sind aber nicht notwendigerweise
dafür geschaffen, Firewall-Regeln für Rechner zu erstellen, die ein Netzwerk
schützen (wie 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.
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:
Sehen Sie das unten aufgeführte Skript durch und passen Sie es Ihren Anforderungen an.
Testen Sie das Skript und überprüfen Sie die Syslog-Meldungen nach unterdrückten Netzverkehr. Wenn Sie vom Netzwerk aus testen, werden Sie entweder den Beispielshellcode starten wollen, um die Firewall zu entfernen (wenn Sie nichts innerhalb von 20 Sekunden eingeben) oder Sie sollten die default deny-Richtliniendefinition auskommentieren (-P INPUT DROP und -P OUTPUT DROP) und überprüfen, dass das System keine gültigen Daten verworfen hat.
Verschieben Sie das Skript nach /etc/init.d/meineFirewall
Konfigurieren Sie das System das Skript zu starten, bevor irgendein Netzwerk konfiguriert wird:
#update-rc.d meineFirewall start 40 S . stop 89 0 6 .
Dies ist das Beispiel-Firewallskript:
#!/bin/sh # Simple example firewall configuration. # # Caveats: # - This configuration applies to all network interfaces # if you want to restrict this to only a given interface use # '-i INTERFACE' in the iptables calls. # - Remote access for TCP/UDP services is granted to any host, # you probably want to restrict this using '--source'. # # chkconfig: 2345 9 91 # description: Activates/Deactivates the firewall at boot time # # You can test this script before applying with the following shell # snippet, if you do not type anything in 10 seconds the firewall # rules will be cleared. #--------------------------------------------------------------- # while true; do test=""; read -t 20 -p "OK? " test ; \ # [ -z "$test" ] && /etc/init.d/meineFirewall clear ; done #--------------------------------------------------------------- PATH=/bin:/sbin:/usr/bin:/usr/sbin # Services that the system will offer to the network TCP_SERVICES="22" # SSH only UDP_SERVICES="" # Services the system will use from the network REMOTE_TCP_SERVICES="80" # web browsing REMOTE_UDP_SERVICES="53" # DNS # Network that will be used for remote mgmt # (if undefined, no rules will be setup) # NETWORK_MGMT=192.168.0.0/24 # Port used for the SSH service, define this is you have setup a # management network but remove it from TCP_SERVICES # SSH_PORT="22" if ! [ -x /sbin/iptables ]; then exit 0 fi fw_start () { # Input traffic: /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Services if [ -n "$TCP_SERVICES" ] ; then for PORT in $TCP_SERVICES; do /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT done fi if [ -n "$UDP_SERVICES" ] ; then for PORT in $UDP_SERVICES; do /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT done fi # Remote management if [ -n "$NETWORK_MGMT" ] ; then /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT else /sbin/iptables -A INPUT -p tcp --dport ${SSH_PORT} -j ACCEPT fi # Remote testing /sbin/iptables -A INPUT -p icmp -j ACCEPT /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -P INPUT DROP /sbin/iptables -A INPUT -j LOG # Output: /sbin/iptables -A OUTPUT -j ACCEPT -o lo /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # ICMP is permitted: /sbin/iptables -A OUTPUT -p icmp -j ACCEPT # So are security package updates: # Note: You can hardcode the IP address here to prevent DNS spoofing # and to setup the rules even if DNS does not work but then you # will not "see" IP changes for this service: /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT # As well as the services we have defined: if [ -n "$REMOTE_TCP_SERVICES" ] ; then for PORT in $REMOTE_TCP_SERVICES; do /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT done fi if [ -n "$REMOTE_UDP_SERVICES" ] ; then for PORT in $REMOTE_UDP_SERVICES; do /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT done fi # All other connections are registered in syslog /sbin/iptables -A OUTPUT -j LOG /sbin/iptables -A OUTPUT -j REJECT /sbin/iptables -P OUTPUT DROP # Other network protections # (some will only work with some kernel versions) echo 1 > /proc/sys/net/ipv4/tcp_syncookies echo 0 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 > /proc/sys/net/ipv4/conf/all/log_martians echo 1 > /proc/sys/net/ipv4/ip_always_defrag echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route } fw_stop () { /sbin/iptables -F /sbin/iptables -t nat -F /sbin/iptables -t mangle -F /sbin/iptables -P INPUT DROP /sbin/iptables -P FORWARD DROP /sbin/iptables -P OUTPUT ACCEPT } fw_clear () { /sbin/iptables -F /sbin/iptables -t nat -F /sbin/iptables -t mangle -F /sbin/iptables -P INPUT ACCEPT /sbin/iptables -P FORWARD ACCEPT /sbin/iptables -P OUTPUT ACCEPT } case "$1" in start|restart) echo -n "Starting firewall.." fw_stop fw_start echo "done." ;; stop) echo -n "Stopping firewall.." fw_stop echo "done." ;; clear) echo -n "Clearing firewall rules.." fw_clear echo "done." ;; *) echo "Usage: $0 {start|stop|restart|clear}" exit 1 ;; esac exit 0
Sie können auch die Netzwerkkonfiguration in
/etc/network/interfaces
verwenden, um Ihre Firewall-Regeln
einzurichten. Dafür müssen Sie Folgendes tun:
Erstellen Sie Ihre Firewall-Regeln für die aktivierte Schnittstelle.
Sichern Sie Ihre Regeln mit iptables-save
in eine Datei in
/etc
, zum Beispiel /etc/iptables.up.rules
Konfigurieren Sie /etc/network/interfaces
, diese Regeln zu
verwenden:
iface eth0 inet static address x.x.x.x [.. interface configuration ..] pre-up iptables-restore < /etc/iptables.up.rules
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
Für weitergehende Firewall-Konfigurationsskripte durch ifupdown
können Sie die zu jeder Schnittstelle verfügbaren Hooks (Einspringpunkte) wie
in den *.d/
-Verzeichnissen verwenden, die mit
run-parts
aufgerufen werden (vergleiche
run-parts(8)
).
ACHTUNG: Diese Informationen gelten nur für iptables in Woody. Versionen nach 1.2.7-8 haben nicht mehr länger das init.d-Skript, das hier beschrieben wird. Benutzer von Debian 3.1 (Sarge) oder neueren Veröffentlichungen sollten entweder die Firewall-Regeln manuell aufbauen oder eines der Programme zur Erzeugung einer Firewall verwenden, die weiter oben beschrieben wurden.
Wenn Sie Debian 3.0 oder neuer benutzen, werden Sie feststellen, dass Sie das
Paket iptables
installiert haben. Dies ist die Unterstützung für
die Netfilter-Implementation in 2.4.4+ Kerneln. Da das System nach der
Installation aber keine Firewall-Regeln kennen kann (Firewall-Regeln sind zu
systemspezifisch), müssen Sie iptables einschalten. Wie auch immer: Die
Skripte wurden so konfiguriert, dass der Administrator Firewall-Regeln
aufsetzen kann und die init-Skripte sie dann lernen können und so
immer als das Setup der Firewall fungieren.
Hierzu müssen Sie Folgendes tun:
Konfigurieren Sie das Paket so, dass es mit dem System gestartet wird. Bei
neueren Versionen (seit 1.2.6a-1) werden Sie während der Installation hiernach
gefragt. Sie können es hinterher wieder mit dpkg-reconfigure -plow
iptables ändern. Wichtig: Bei älteren Versionen geschah dies
noch durch Editieren von /etc/default/iptables
, so dass die
Variable enable_iptables_initd auf true gesetzt wurde.
Erstellen Sie ein Firewall-Setup mit iptables, benutzen Sie dazu die
Kommandozeile (siehe iptables(8)
) oder andere Werkzeuge aus
Debians Firewall-Paketen (siehe Nutzen von
Firewall-Paketen, Abschnitt 5.14.3.1). Sie müssen einen Satz von
Firewall-Regeln erstellen, die benutzt werden sollen, wenn die Firewall
aktiv ist, und einen anderen, wenn die Firewall inaktiv (dies
können auch nur leere Regeln sein) ist.
Sichern Sie die erstellten Regeln mit den Skripten /etc/init.d/iptables save active und /etc/init.d/iptables save inactive.
Sobald dies geschehen ist, ist Ihr Firewall-Setup im Verzeichnis
/var/lib/iptables/
gespeichert und wird beim System-Boot
ausgeführt (oder wenn das initd-Skript mit start- oder
stop-Argument gestartet wird). Beachten Sie, dass die standardmäßigen
Einstellungen unter Debian vorsehen, den Firewall-Code in den
Multiuser-Runleveln (2 bis 5) sehr früh (10) zu starten. Außerdem wird er im
singleuser-Runlevel (1) gestoppt. Ändern Sie dies, wenn es nicht Ihren lokalen
Richtlinien entspricht.
Bitte lesen Sie die Kommentare in der
/etc/default/iptables
-Konfigurationsdatei für weitere
Informationen zu den dieses Paket betreffenden Dingen.
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 internen 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 ]
Anleitung zum Absichern von Debian
Version: 3.10, Fri, 26 Jan 2007 16:59:21 +0000jfs@debian.org