Dienste können auf zwei Arten in einem laufenden System abgesichert werden:
Einschränken der Dienste, so dass auf sie nur von bestimmten Orten aus zugegriffen werden kann, kann durch Zugriffs-Beschränkungen auf Kernel-Ebene (durch eine Firewall) passieren. Konfigurieren Sie sie, so dass sie nur auf ein bestimmtes Interface horchen (einige Dienste bieten diese Fähigkeiten vielleicht nicht), oder durch eine andere Methode. Zum Beispiel kann der Linux vserver-Patch (für 2.4.16) dazu benutzt werden, Prozesse auf ein bestimmtes Interface zu binden.
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 ein bestimmtes Interface reagiert (unter
Verwendung der service@ip-Syntax). Dies ist jedoch eine nicht
dokumentierte Eigenschaft. Ein Ersatz, der xinetd
Meta-Daemon
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 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 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:
Lassen Sie ssh nur auf ein bestimmtes Interface hören, falls Sie mehrere haben (und ssh nicht auf allen verfügbar sein soll) oder Sie in Zukunft eine neue Netzwerkkarte einbauen werden (und keine ssh-Verbindungen auf Ihr erlauben wollen).
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.
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).
Nicht gesetzte Passwörter verspotten jegliche System-Sicherheit.
Erlauben Sie nur bestimmten Usern 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.
Erlauben Sie nur bestimmten Gruppenmitgliedern sich via ssh auf der Maschine einzuloggen. AllowGroups und AllowUsers haben äquivalente Direktiven um den Zugang zu der Maschine zu verwehren. Es wird nicht überraschen, dass es sich hierbei um "DenyUsers" und "DenyGroups" handelt.
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".
sshd_config(5)
).
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
.
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 sind. Derzeit gibt es drei weitverbreitete
ssh-Daemonen: ssh1, ssh2 und OpenSSH von den OpenBSD-Leuten. Ssh1 war der
erste verfügbare ssh-Daemon und er ist noch der weit verbreitetste (Gerüchten
zufolge gibt es sogar eine Windows-Version). Ssh2 hat gegenüber ssh1 viele
Vorteile, abgesehen davon, dass es unter einer unfreien Lizenz veröffentlicht
wurde. OpenSSH ist ein völlig freier ssh-Daemon, der sowohl ssh1 als auch ssh2
unterstützt. OpenSSH ist die Version, die installiert wird, wenn Sie auf
Debian das Paket 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 zu chroot'en (die kommerzielle Version bietet diese Funktionalität).
Wie dem auch sei, es gibt auch ein Projekt, das diese Funktionalität für
OpenSSH anbietet, vergleiche 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.10.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:
Squid ist einer der verbreitetsten Proxy/Cache-Server, und es gibt ein paar
Sicherheitsaspekte, die Sie beachten sollten. Squid's Standard-Konfiguration
lehnt alle Anfragen von Nutzern ab. Dennoch erlaubt das Debian-Paket Zugriff
von 'localhost', Sie müssen nur Ihren Browser richtig konfigurieren. Sie
sollten Squid so konfigurieren, dass er Zugriffe von vertrauenswürdigen
Nutzern, Computern oder Netzwerken erlaubt, indem Sie eine
Zugriffs-Kontroll-Liste (ACL, Access Control List) in
/etc/squid.conf
definieren. Mehr Informationen, wie Sie ACLs
definieren, finden Sie in der Squid User's
Guide
. 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.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-Ressources 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 und neueren Versionen verfügbar:
calamaris
- Log-Datei-Analysator für Squid oder Oops
Proxy-Log-Dateien.
modlogan
- Ein modularer Log-Datei-Analysator.
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 es weniger
vertrauenswürdig macht. Standardmäßig ist Squid nicht dazu konfiguriert, als
Web-Server zu arbeiten, Sie müssen sich darüber also keine Gedanken machen.
Sie müssen sicher stellen, dass es wirklich nötig ist, wenn Sie diese
Eigenschaft nutzen wollen. Weitere Informationen über den »Accelerator Mode«
in Squid finden Sie im Squid User's
Guide, Kapitel 9
.
Wenn Sie wirklich FTP benutzen müssen (ohne ihn mit sslwrap zu umhüllen oder
innerhalb eines SSL- oder SSH-Tunnels), sollten Sie ftp in das Home-Verzeichnis
des FTP-Nutzers chrooten, so dass ein Nutzer nichts anderes sehen kann, als
sein eigenes Verzeichnis. Andernfalls können sie Ihr Dateisystem durchlaufen,
als hätten sie Shell-Zugriff darauf. Sie können die folgende Zeile in Ihre
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 Proftp-DoS Attacken 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. Nutzer 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 mehr und mehr Firmen benutzt, wo ein Server für viele Arbeitsplätze benötigt wird. Dies kann gefährlich sein, weil Sie dem Datei-Server erlauben müssen, sich mit den X-Clients zu verbinden (X-Server aus Sicht von X. X vertauscht die Definition von Client und Server). Wenn Sie dem (sehr schlechten) Vorschlag von vielen Dokumentationen folgen, geben Sie auf Ihrer Maschine 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 gilt, da der ssh-Server
/usr/X11R6/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.
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
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/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 standardmäßig unter Debian der
Fall ist), wie hier:
[server-Standard] name=Standard Server command=/usr/bin/X11/X -nolisten tcp
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
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 Zugang-Kontrolle ü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 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 dieser Konfigurations-Datei, wie
zum Beispiel das Erlauben oder Verweigern von Netzwerken oder Rechnern. Wenn
Sie sie allerdings nicht benötigen, belassen Sie es am besten dabei, einfach
nur den Port, auf dem gehört wird, einzuschränken. 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 </Locationi>
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 Alarm-Systemen zu erhalten.
Wenn Sie exim
haben, benötigen Sie den Daemon nicht arbeitend, 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.
If you want a relay-only setup, however, you can consider changing the mailer
daemon to programs that can only be configured to forward the mail to
a remote mail server. Debian provides currently both ssmtp
and
nullmailer
for this purpose. In any case, you can evaluate for
yourself any of the mail transport agents [34] provided by Debian and see which one suits best to the
system's purposes.
If you want to give remote access to mailboxes there are a number of POP3 and IMAP daemons available.[35] However, if you provide IMAP access note that it is a general file access protocol, it can become the equivalent of a shell access because users might be able to retrieve any file that they can through it.
Try, for example, to configure as your inbox path {server.com}/etc/passwd if it succeeds your IMAP daemon is not properly configured to prevent this kind of access.
Of the IMAP servers in Debian the cyrus
server (in the
cyrus-imapd
package) gets around this by having all access be to a
database in a restricted part of the file system. Also, uw-imapd
(either install the uw-imapd
or better, if your IMAP clients
support it, uw-imapd-ssl
) can be configured to chroot the users
mail directory but this is not enabled by default. The documentation provided
gives more information on how to configure it.
Also, you might want to run an IMAP server that does not need valid users to be
created on the local system (which would grant shell access too), both
courier-imap
(for IMAP) and courier-pop
teapop
(for POP3) and cyrus-imapd
(for both POP3 and
IMAP) provide servers with authentication methods beside the local user
accounts. cyrus
can use any authentication method that can be
configured through PAM whileas teapop
might use databases (such as
postgresql
and mysql
) for user authentication.
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 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, 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 angegeben Daemon (-l) an den Port (-d) und nutzt ein bestimmtes 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:
Sie sollten einige Informationen, die von außen abgefragt werden können,
zurückhalten, so dass man nicht wertvolle Informationen über Ihre Organisation,
die Sie nicht herausgeben wollen, abfragen kann. Dies schließt die folgenden
Optionen mit ein: allow-transfer, allow-query,
allow-recursion 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
Netzwerk (Ihre interne IP ist 192.168.1.2) verbunden - ein einfacher Server im
heimischen Netzwerk. Sie möchten keinen Dienst im Internet anbieten und
DNS-Abfragen lediglich Ihrem internen Host erlauben. Sie sollten dies
einschränken, indem Sie folgendes in Ihre /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 listen-on Option bewirkt, dass sich DNS nur auf die Schnittstelle bindet, die die interne Adresse hat, aber sogar wenn diese Schnittstelle Verbindung zum Internet hat (zum Beispiel weil Sie NAT benutzen), werden Abfragen nur akzeptiert, wenn sie von internen Hosts kommen. Wenn das System mehrere Schnittstellen hat und Sie kein 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 abzustürzen (oder durch Speicher-Überlauf-Attacken auszunutzen). Sie könnten ihn sogar dazu bringen, lediglich auf 127.0.0.1 zu hören, wenn Sie den DNS-Service nicht für ein anderes System anbieten wollen.
Der version.bind-Eintrag in der chaos class enthält die Version des derzeit laufenden Bind-Prozesses. Diese Information wird oft von automatischen Scannern und bösartigen Individuen dazu verwendet, heraus zu finden, ob ein Bind für eine bestimmt Attacke verwundbar ist. Indem Sie falsche oder gar keine Informationen im version.bind Eintrag zur Verfügung stellen, minimieren Sie die Wahrscheinlichkeit, dass jemand Ihren Server aufgrund der publizierten Version attackieren wird. Um Ihre eigene Version anzugeben, benutzen Sie die 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 User laufen lassen, BIND neue
Netzwerk-Schnittstellen nicht automatisch entdecken kann, zum Beispiel wenn Sie
eine PCMCIA-Karte in Ihr Notebook stecken. Lesen Sie README.Debian in Ihrer
Dokumentation (/usr/share/doc/bind/README.Debian
) für mehr
Informationen hierzu. Es gab in letzter Zeit Sicherheitsprobleme mit BIND, so
dass es nützlich ist, den User zu wechseln, wenn es möglich ist. Wir werden
die Schritte, die dazu nötig sind, detailliert aufführen. Wenn Sie dies
automatisch machen lassen wollen, probieren Sie das Skript in Beispielskript, um die Standard-Installation von
Bind zu ändern, Anhang E aus.
Um BIND unter einem anderen User laufen zu lassen, müssen Sie zunächst einen separaten User und eine separate Gruppe dafür erstellen (es ist keine gute Idee für alle Dienste, die Sie nicht als root laufen lassen, den User nobody und die Gruppe nogroup zu benutzen). In diesem Beispiel wird der User und die Gruppe 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ä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 Lieblings-Editor und ändern Sie die Zeile, die mit
start-stop-daemon --start
anfängt zu[36]:
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
Change the permissions of files that are used by Bind, including
/etc/bind/rndc.key
:
-rw-r----- 1 root named 77 Jan 4 01:02 rndc.key
and where bind creates its pidfile, using, for example,
/var/run/named
instead of /var/run
:
$ mkdir /var/run/named $ chown named.named /var/run/named $ vi /etc/named.conf [ ... update the configuration file to use this new location ...] options { ... pid-file "/var/run/named/named.pid"; }; [ ... ]
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 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äuft nicht mehr als root. Wenn Sie mehr
Informationen darüber lesen wollen, warum BIND nicht als nicht-root User auf
Debian-Systemen läuft, sehen Sie bitte in der Fehlerdatenbank zu Bind nach,
insbesondere 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, nützliche Informationen beitragen 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
sehr einfachen Weg dies zu erreichen: Die -t Option (siehe die
Handbuchseite named(8)
oder Seite 100 von Bind's 9
documentation (PDF)
). Dies wird Bind selbst in ein bestimmtes
Verzeichnis chrooten lassen, ohne dass Sie einen eigenes Chroot-Gefängnis
aufsetzen müssen, oder sich Sorgen um dynamische Bibliotheken machen müssen.
Die einzigen Dateien, die in diesem Chroot-Gefängnis benötigt werden, sind:
dev/null etc/bind/ - sollte die named.conf und alle Server-Zonen enthalten sbin/named-xfer - wenn Sie Namen transferieren var/run/named/ - sollte die pid und den Cache des Name-Server (falls es ihn gibt) enthalten. Dieses Verzeichnis muss für den named-User schreibbar sein. var/log/named - Wenn Sie in einer Datei protokollieren, muss dies für den named-User schreibbar sein. dev/log - syslogd sollte hierauf hören, wenn named so konfiguriert ist, dass er darüber protokolliert.
Damit Ihr Bind Daemon vernünftig läuft, braucht er bestimmt Zugriffsrechte auch die named-Dateien. Dies ist eine einfache Angelegenheit, da die Konfigurations-Dateien immer in /etc/named/ liegen. Beachten Sie, dass er lediglich Lesezugriff benötigt, es sei denn, es handelt sich um einen sekundären oder zwischen speichernden Name-Server. Wenn dies der Fall ist, müssen Sie ihm Lese- und Schreibzugriff auf die notwendigen Zonen gewähren (so dass Zonen-Transfers vom primären Server funktionieren).
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 8.2.3 (aus Debian Potato) ein komplettes Chroot-Gefängnis aufsetzen (d.h. Sie benutzen nicht nur -t) , stellen Sie sicher, dass Sie die folgenden Dateien darin haben:
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 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 bevor die @CFLAGS@ Definition von autoconf verwendet wird) $ dpkg-buildpackage -rfakeroot $ cd .. $ dpkg -i bind-8.2.5-2*deb
Nach der Installation werden Sie die Dateien in das Chroot-Gefängnis
verschieben müssen [37]. Sie
können die init.d Skripten 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
Skripten --chroot /location_of_chroot hinzufügen.
For more information on how to set up chroots see Allgemeine chroot- und suid-Paranoia, Abschnitt 5.10.
FIXME, merge info from 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 den 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
).
More information on further restricting Apache by setting up a chroot jail is
provided in Chroot
-Umgebung
für Apache
, Anhang H.
The default Apache installation in Debian permits users to publish content
under the $HOME/public_html
. This content can be retrieved
remotely using an URL such as: http://your_apache_server/~user.
If you do not want to permit this you must change the
/etc/apache/http.conf
configuration file commenting out:
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
But if the module was linked statically (you can check this running apache -l) you must add the following instead:
Userdir disabled
Note: The disabled keyword is only available in Apache 1.3 and above. In you are using older versions of apache, you need to change the configuration file and add:
<Directory /home/*/public_html> AllowOverride None Order deny,allow Deny from all </Directory>
An attacker might still do user enumeration, since the answer of the web server will be a 403 Permission Denied and not a 404 Not available.
Apache logfiles, since 1.3.22-1, are owned by user 'root' and group 'adm' with permissions 640 this permissions are changed after rotation. An intruder that accessed the system through the web server would not be able (without privilege escalation) to remove old log file entries.
Apache files are located under /var/www
. Just after installation
the default file provides some information on the system (mainly that it's a
Debian system running Apache). The default webpages are owned by user root and
group root by default, whileas the Apache process runs as user www-data and
group www-data. This should make attackers that compromise the system through
the web server harder to deface the site. You should, of course, substitute
the default web pages (which might provide information you do not want to show
to outsiders) with your own.
Wenn Sie einen finger-Dienst laufen lassen wollen, fragen Sie sich bitte
zuerst, ob Sie das auch tun müssen. Wenn Sie müssen, werden Sie feststellen,
dass Debian viele finger-Daemonen zur Verfügung stellt (hier die Ausgabe von
apt-cache search fingerd
):
ffingerd
ist der empfohlene finger-Daemon, wenn Sie vorhaben,
einen öffentlichen Dienst anzubieten. In jedem Fall sind Sie dazu angespornt,
ihn über inetd, xinetd oder tcpserver laufend aufzusetzen: Schränken Sie die
Anzahl der Prozesse die gleichzeitig laufen dürfen ein. Schränken Sie den
Zugriff auf den Finger-Daemon von bestimmten Hosts ein (indem Sie tcp-wrapper
benutzen) und lassen Sie ihn nur auf die Schnittstellen achten, auf die er
achten muss.
chroot
is one of the most powerful possibilities to restrict a
daemon or a user or another service. Just imagine a jail around your target,
which the target cannot escape from (normally, but there are still a lot of
conditions that allow one to escape out of such a jail). If you do not trust a
user or a service, you can create a modified root environment for him. This
can use quite a bit of disk space as you need to copy all needed executables,
as well as libraries, into the jail. But then, even if the user does something
malicious, the scope of the damage is limited to the jail.
Many services running as daemons could benefit from this sort of arrangement as. The daemons that you install with your Debian distribution will not come, however, chrooted [38] per default.
This includes: name servers (such as bind
), web servers (such as
apache
), mail servers (such as sendmail
) and ftp
servers (such as wu-ftpd
). It is probably fair to say that the
complexity of BIND is the reason why it has been exposed to a lot of attacks in
recent years (see Sichern von BIND, Abschnitt 5.7).
However, Debian does provide some software that can help set up
chroot
environments. See Making chrooted
environments automatically, Abschnitt 5.10.1.
Anyway, if you run any service on your system, you should consider running them as secure as possible. This includes: revoking root privileges, running in a restricted environment (such as a chroot jail) or replacing them with a more secure equivalent.
However, be forewarned that a chroot
jail can be broken if the
user running in it is the superuser. So, you need to make the service run as a
non-privileged user. By limiting its environment you are limiting the world
readable/executable files the service can access, thus, you limit the
possibilities of a privilege escalation by use of local system security
vulnerabilities. Even in this situation you cannot be completely sure that
there is no way for a clever attacker to somehow break out of the jail. Using
only server programs which have a reputation for being secure is a good
additional safety measure. Even minuscule holes like open file handles can be
used by a skilled attacker for breaking into the system. After all,
chroot
was not designed as a security tool but as a testing tool.
There are several programs to chroot automatically servers and services.
Debian currently (accepted in May 2002) provides Wietse Venema's
chrootuid
in the chrootuid
package, as well as
compartment
and makejail
. These programs can be used
to set up a restricted environment for executing any program
(chrootuid
enables you to even run it as a restricted user).
Some of these tools can be used to set up the chroot environment easily. The
makejail
program for example, can create and update a chroot jail
with short configuration files (it provides sample configuration files for
bind
, apache
, postgresql
and
mysql
). It attempts to guess and install into the jail all files
required by the daemon using strace
, stat
and
Debian's package dependancies. More information at http://www.floc.net/makejail/
.
Jailer
is a similar tool which can be retrieved from http://www.balabit.hu/downloads/jailer/
and is also available as a Debian GNU package.
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 unixoide 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 Passworten 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 Ihren System so konfigurieren, dass es den LDAP
Server zur User 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) is a protocol that programs can use to request
services from other programs located on different computers. The
portmap
service controls RPC services by mapping RPC program
numbers into DARPA protocol port numbers; it must be running in order to make
RPC calls.
RPC-based services have had a bad record of security holes, although the portmapper itself hasn't (but still provides information to a remote attacker). Einige DDoS (distributed denial of service) Angriffe benutzen RPC-Löcher, um in das System einzudringen und als so genannter Agent/Handler zu fungieren.
You only need RPC if you are using an RPC-based service. The most common
RPC-based services are NFS (Network File System) and NIS (Network Information
System). See the previous section for more information about NIS. The File
Alteration Monitor (FAM) provided by the package fam
is also an
RPC service, and thus depends on portmap
.
NFS services are quite important in some networks. If that is the case for
you, then you will need to find a balance of security and usability for your
network. (You can read more about NFS security in the NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz
).)
Das Abschalten von portmap ist relativ einfach. Es gibt verschiedene Methoden.
Die einfachste in einem Debian 3.0 oder neueren System ist einfach das Paket
portmap
zu deinstallieren. Wenn Sie eine andere Version laufen
haben, werden Sie den Dienst, wie in Daemons abschalten, Abschnitt 3.6.1
beschrieben, abschalten müssen, weil das Programm Teil des Pakets
net-base
(das nicht deinstalliert werden kann, ohne das System
kaputt zu machen) ist.
Notice that some desktop environments (notably, GNOME) use RPC services and need the portmapper for some of the file management features. If this is your case, you can limit the access to RPC services as described below.
Unfortunately, in some cases removing RPC services from the system is not an
option. Some local desktop services (notably SGI's fam
) are RPC
based and thus need a local portmapper. This means that under some situations,
users installing a desktop environment (like GNOME) will install the portmapper
too.
There are several ways to limit access to the portmapper and to RPC services:
libwrap
(see Die Nutzung von tcpwrappers, Abschnitt
4.11). This means that you can block access to them through the
hosts.allow
and hosts.deny
tcp wrappers
configuration.
portmap
package can be configured to listen
only on the loopback interface. To do this, modify
/etc/default/portmap
, uncomment the following line:
#OPTIONS="-i 127.0.0.1" and restart the portmapper.
This is sufficient to allow local RPC services to work while at the same time
prevents remote systems from accessing them (see, however, Lösung des Problems der Weak-End-Hosts,
Abschnitt 4.17.5).
Das Debian GNU/Linux Betriebssystem hat die eingebauten Fähigkeiten des Linux
Kernels. Dies heißt, dass Sie, wenn Sie ein Potato (Debian 2.2) System
installiert haben (mit dem standardmäßigen Kernel 2.2) werden Sie
ipchains
Firewall-Unterstützung im Kernel haben. Das Paket
ipchains
sollte bereits (aufgrund seiner Priorität) installiert
sein. Wenn Sie Debian 3.0 (oder 3.1) installiert haben (mit dem
standardmäßigen 2.4er Kernel) unterstützt der Kernel Ihr iptables
(netfilter). Der Hauptunterschied zwischen ipchains
und
iptables
ist, dass letzteres auf stateful packet
inspection (zustandsbehaftete Paketuntersuchung), 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 und sogar die Kommunikation von ihm nach Außen absichern. Firewall-Regeln können dazu benutzt werden, Prozesse, die nicht vernünftig konfiguriert werden können, zu schützen, aber nicht, um Dienste für Netzwerke, 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 alle Dienste abgehärtet worden sind. Sie können sich sicherlich leicht eine Konfiguration vorstellen, bei der ein System lediglich von einer eingebauten Firewall geschützt, und der Administrator glückselig die Firewall-Regeln aus irgendwelchen Gründen (Probleme mit dem Setup, Verdruss, Denkfehler) entfernt. Dieses System wäre weit geöffnet für Angriffe, wenn es keine andere Schutzmaßnahmen auf dem System gibt.
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 wurde 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 (also alles ablehnt, was nicht ausdrücklich erlaubt ist), und weiterhin:
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. Eine Firewall kann so konfiguriert werden, dass ein Zugriff von Systemen außerhalb des lokalen Netzwerks auf interne Dienste (Ports) unterbunden wird. Zum Beispiel muss auf einem Mail-Server lediglich Port 25 (auf dem der Mail-Dienst aufsetzt) von außen zugänglich sein. Eine Firewall kann so konfiguriert werden, dass sogar wenn es neben den öffentlich zugänglichen noch andere Netzwerkdienste gibt, direkt an diese gesendete Pakete verwirft (dies nennt man filtern).
Sie können eine Debian GNU/Linux Maschine sogar so konfigurieren, dass sie als Bridge-Firewall (überbrückender Schutzwall) fungiert, d.h. eine filternde Firewall, die komplett transparent zum gesamten Netzwerk erscheint, ohne IP-Adresse auskommt, und daher nicht direkt attackiert werden kann. Abhängig von dem installierten Kernel müssen Sie vielleicht den Bridge-Firewall Patch installieren, und dann 802.1d Ethernet Bridging in der Kernel Konfiguration und der neuen 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.
The default Debian installation, unlike other Linux distributions, does not yet provide a way for the administrator to setup a firewall configuration throughout the default installation but you can install a number of firewall configuration packages (see Using firewall packages, Abschnitt 5.14.3.1).
Natürlich ist die Konfiguration einer Firewall immer vom System und dem
Netzwerk abhängig. Ein Administrator muss vorher das Netzwerklayout und die
Systeme, die er beschützen will, kennen, und ob andere netzwerkspezifischen
Erwägungen (wie NAT oder Routing) berücksichtigt werden müssen. Seien Sie
vorsichtig, wenn Sie Ihre Firewall konfigurieren. Wie Laurence J. Lane im
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 von Kilometer entfernt ist, irrtümlicherweise selbst davon ausgeschlossen hat. Man kann es sogar schaffen, sich von dem Computer aus zu sperren, dessen Tastatur unter seinen Fingern liegt. Lassen Sie daher die gebotene Vorsicht walten.
Vergessen Sie nicht: Das einfache Installieren von iptables
(oder
dem älterem Firewallcode) gibt Ihnen keine Sicherheit, es stellt lediglich die
Software zur Verfügung. Um eine Firewall zu haben, müssen Sie sie
konfigurieren.
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. If you want to
ask questions or need help setting up a firewall you can use the
debian-firewall mailing list, see http://lists.debian.org/debian-firewall
.
Sehen Sie auch Seien Sie wachsam gegenüber
generellen Sicherheitsproblemen!, Abschnitt 2.2 für weitere (allgemeinere)
Verweise.
Setting up manually a firewall can be complicated for novice (and sometimes even expert) administrators. However, the free software community has created a number of tools that can be used to easily configure a local firewall. Be forewarned that some of this tools are oriented more towards local-only protection (also known as personal firewall) and some are more versatile and can be used to configure complex rules to protect whole networks.
Some software that can be used to set up firewall rules in a Debian system is:
firestarter
, a GNOME application oriented towards end-users that
includes a wizard useful to quickly setup firewall rules. The application
includes a GUI to be able to monitor when a firewall rule blocks traffic.
fwbuilder
, an object oriented GUI which includes policy compilers
for various firewall platforms including Linux' netfilter, BSD's pf (used in
OpenBSD, NetBSD, FreeBSD and MacOS X) as well as router's access-lists. It is
similar to enterprise firewall management software. Complete fwbuilder's
functionality is also available from the command line.
shorewall
, a firewall configuration tool which provides support
for IPsec as well as limited support for traffic shaping as well as the
definition of the firewall rules. Configuration is done through a simple set
of files that are used to generate the iptables rules.
guarddog
, a KDE based firewall configuration package oriented both
to novice and advanced users.
knetfilter
, a KDE GUI to manage firewall and NAT rules for
iptables (alternative/competitor to the guarddog tool although slightly
oriented towards advanced users)
bastille
, this hardening application is described in Automatisches Abhärten von Debian-Systemen,
Kapitel 6, one of the hardening steps that the administrator can configure
is a definition of the allowed and disallowed network traffic that is used to
generate a set of firewall rules that the system will execute on startup.
mason
, an application which can propose firewall rules based on
the network traffic your system "sees".
ferm
lokkit
or gnome-lokkit
ipac-ng
, helps setup not traditional firewall rules but network
traffic classification rules.
filtergen
fiaif
hlfl
kmyfirewall
netscript-2.4
Notice that some of the packages outlined previously will introduce firewalling scripts to be run when the system boots. Test them extensively before rebooting or you might find yourself locked from the box. If you mix different firewalling packages you can have undesired effects, usually, the firewalling script that runs last will be the one that configures the system (which might not be what you pretend). Consult the package documentation and use either one of these setups.
As mentioned before, some programs, like firestarter, guarddog and knetfilter,
are administration GUIs using either GNOME or KDE (last two). These
applications are much more user-oriented (i.e. for home users) than some of
the other packages in the list which might be more administrator-oriented.
Some of the programs mentioned before (like bastille
) are focused
at setting up firewall rules to protect the host they run in but are not
necessarily designed to setup firewall rules for firewall hosts that protect a
network (like shorewall
or fwbuilder
).
There is yet another type of firewall application: application proxies. If you
are looking into setting up an an enterprise-level that does packet filtering
and provides a number of transparent proxies that can do fine-grain traffic
analysis you should consider using Zorp
, which provides this in a
single program. You can also manually setup this type of firewall host using
the proxies available in Debian for different services like for DNS using
bind
(properly configured), dnsmasq
,
pdnsd
or totd
for FTP using frox
or
ftp-proxy
, for X11 using xfwp
, for IMAP using
imapproxy
, for mail using smtpd
, or for POP3 using
p3scan
. For other protocols you can either use a generic TCP
proxy like simpleproxy
or a generic SOCKS proxy like
dante-server
, tsocks
or socks4-server
.
Typically, you will also use a web caching system (like squid
) and
a web filtering system (like squidguard
or
dansguardian
).
Another possibility is to manually configure your firewall rules through an
init.d script that will run all the iptables
command. Take the
following steps:
/etc/init.d/myfirewall
#update-rc.d myfirewall start 40 S . stop 89 0 6 .
This is the sample firewall script:
#!/bin/sh # Simple example firewall configuration # # Caveats: # - This configuration applies to all network interfaces # if you want to retrict this to only a given interface use # '-i INTERFACE' in the iptables calls. # - Remote access for TCP/UDP services is granted to any host, # you probably will want to restrict this using '--source' # # chkconfig: 2345 9 91 # description: Activates/Deactivates the firewall at boot time # # You can test this script before applying with the following shell # snippet, if you do not type anything in 10 seconds the firewall # rules will be cleared. #--------------------------------------------------------------- # while true; do test=""; read -t 20 -p "OK? " test ; \ # [ -z "$test" ] && /etc/init.d/firewall clear ; done #--------------------------------------------------------------- PATH=/bin:/sbin:/usr/bin:/usr/sbin # Services that the system will offer to the network TCP_SERVICES="22" # SSh only UDP_SERVICES="" # Services the system will use from the network REMOTE_TCP_SERVICES="80" # web browsing REMOTE_UDP_SERVICES="53" # DNS # Network that will be used for remote mgmt # (if undefined, no rules will be setup) # NETWORK_MGMT=192.168.0.0/24 if ! [ -x /sbin/iptables ]; then exit 0 fi fw_start () { # Input traffic: /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Services for PORT in $TCP_SERVICES; do /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT done for PORT in $UDP_SERVICES; do /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT done # Remote management if [ -n "$NETWORK_MGMT" ] ; then /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT else /sbin/iptables -A INPUT -p tcp --dport ${SSH_PORT} -j ACCEPT fi # Remote testing /sbin/iptables -A INPUT -p icmp -j ACCEPT /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -P INPUT DROP /sbin/iptables -A INPUT -j LOG # Output: /sbin/iptables -A OUTPUT -j ACCEPT -o lo /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # ICMP is permitted /sbin/iptables -A OUTPUT -p icmp -j ACCEPT # So are security package updates /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT for PORT in $REMOTE_TCP_SERVICES; do /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT done for PORT in $REMOTE_UDP_SERVICES; do /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT done # All other connections are registered in syslog /sbin/iptables -A OUTPUT -j LOG /sbin/iptables -A OUTPUT -j REJECT /sbin/iptables -P OUTPUT DROP # Other network protections echo 1 > /proc/sys/net/ipv4/tcp_syncookies echo 0 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 >/proc/sys/net/ipv4/conf/all/log_martians echo 1 > /proc/sys/net/ipv4/ip_always_defrag echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route } fw_stop () { /sbin/iptables -F /sbin/iptables -t nat -F /sbin/iptables -t mangle -F /sbin/iptables -P INPUT DROP /sbin/iptables -P FORWARD DROP /sbin/iptables -P OUTPUT ACCEPT } fw_clear () { /sbin/iptables -F /sbin/iptables -t nat -F /sbin/iptables -t mangle -F /sbin/iptables -P INPUT ACCEPT /sbin/iptables -P FORWARD ACCEPT /sbin/iptables -P OUTPUT ACCEPT } case "$1" in start|restart) echo -n "Starting firewall.." fw_stop fw_start echo "done." ;; stop) echo -n "Stopping firewall.." fw_stop echo "done." ;; clear) echo -n "Clearing firewall rules.." fw_clear echo "done." ;; *) echo "Usage: $0 {start|stop|restart|clear}" exit 1 ;; esac exit 0
You can use also the network configuration in
/etc/network/interfaces
to setup your firewall rules. For this
you will need to:
iptables-save
to a file in
/etc
, for example /etc/iptables.up.rules
etc/network/interfaces
to run use the configured
ruleset:
iface eth0 inet static address x.x.x.x [.. interface configuration ..] pre-up iptables-restore < /etc/iptables.up.rules
You can optionally also set a set of rules to be applied when the network
interface is down creating a set of rules, saving it in
/etc/iptables.down.rules
and adding this directive to the
interface configuration:
post-down iptables-restore < /etc/iptables.down.rules
For more advanced firewall configuration scripts through ifupdown
you can use the hooks available to each interface as in the *.d/
directories called with run-parts (see run-parts(8)
).
NOTE: This information only applies to iptables in woody. Versions later than 1.2.7-8 don't any longer have the init.d script described here. Users of Debian 3.1 or later releases should either setup firewalling rules manually or use any of the firewall generation programs described previously.
Wenn Sie Debian 3.0 oder neuer 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+ 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:
/etc/default/iptables
, so dass die
Variable enable_iptables_initd auf true gesetzt wurde.
iptables(8)
) oder andere der Tools aus
Debians Firewall-Paketen (siehe Using firewall
packages, 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.
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 und stop
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.
Please read the inline comments in the /etc/default/iptables
configuration file for more information on the issues regarding this package.
Testing your firewall configuration is as easy, and as dangerous, as just running your firewall script (or enabling the configuration you defined in your firewall configuration application). However, if you are not careful enough and you are configuring your firewall remotely (like through an SSH connection) you could lock yourself
There are several ways to prevent this. One is running a script in a separate terminal that will remove the firewall configuration if you don't feed it input. An example of this is:
$ while true; do test=""; read -t 20 -p "OK? " test ; \ [ -z "$test" ] && /etc/init.d/firewall clear ; done
Another one is to introduce a backdoor in your system through an alternate
mechanism that allows you to either clear the firewall system or punch a hole
in it if something goes awry. For this you can use knockd
and
configure it so that a certain port connection attempt sequence will clear the
firewall (or add a temporary rule). Even though the packets will be dropped by
the firewall, since knockd
binds to the interface and
sees you will be able to work around the problem.
Testing a firewall that is protecting an internal network is a different issue, you will want to look at some of the tools used for remote vulnerability assesment (see Programme zur Fernprüfung der Verwundbarkeit, Abschnitt 8.1) to probe the network from the outside in (or from any other direction) to test the effectiveness of the firewall configuation.
Anleitung zum Absichern von Debian
Version: 3.0, Mon, 16 May 2005 21:27:58 +0200jfs@debian.org