Dienste können auf zwei Arten abgesichert werden:
Einschränken der Dienste, so dass auf sie nur von bestimmten Orten zugegriffen werden kann, kann durch Zugriffs-Beschränkungen auf Kernel-Ebene (durch eine Firewall) passieren. Konfigurieren Sie sie, so dass sie nur auf ein bestimmtes Interface horchen (einige 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 wertlos, dass inetd nicht so konfiguriert
werden kann, dass er nur auf ein bestimmtes Interface reagiert. Wie auch
immer, sein Ersatz, der xinetd
Meta-Daemon kennt ein
bind für diesen Zweck. Lesen Sie dazu bitte
xinetd.conf(5)
.
service nntp { socket_type = stream protocol = tcp wait = no user = news group = news server = /usr/bin/env server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin +/usr/sbin/snntpd logger -p news.info bind = 127.0.0.1 }
Die folgenden Abschnitte gehen detaillierter darauf ein, wie bestimmte Dienste abhängig von der beabsichtigten Benutzung passend konfiguriert werden.
Wenn Sie immernoch telnet statt ssh benutzen, sollten Sie dieses Handbuch kurz beiseite legen, und dies ändern. Ssh sollte anstelle von telnet für alle Fern-Logins benutzt werden. In einer Zeit, in der es leicht ist, Internet-Verkehr mit zu schnüffeln und an Klartext-Passwörter heranzukommen, sollten Sie lediglich Protokolle verwenden, die Kryptographie benutzen. Also führen Sie sofort ein apt-get install ssh auf Ihrem System aus.
Ermuntern Sie alle Nutzer Ihres Systems, ssh anstelle von telnet zu benutzen,
oder noch bessern: Deinstallieren Sie telnet/telnetd. Zusätzlich sollten Sie
es vermeiden, sich mit ssh als root einzuloggen und lieber andere Methoden
benutzen, um root zu werden. Wie zum Beispiel su
oder
sudo
. 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 Netzwerkkarten 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.
Erlauben Sie nur bestimmten Gruppenmitgliedern sich via ssh auf der Maschine einzuloggen. AllowGroups und AllowUsers haben entsprechende Direktiven um den Zugang zu der Maschine zu verwehren. Es wird nicht überraschen, dass es sich hierbei um "DenyUsers" und "DenyGroups" handelt.
Es ist Ihre Wahl, was Sie hier eintragen. Es ist sicherer Zugriff nur Nutzern zu erlauben, die ssh-Schlüssel in der ~/.ssh/authorized_keys haben. Wenn Sie dies wollen, setzen Sie es auf "no".
sshd_config(5)
).
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 Vorteile, abgesehen davon, dass er unter einer unfreien Lizens veröffentlicht wurde. OpenSSH ist ein wirklich freier ssh-Daemon, der sowohl ssh1 als auch ssh2 unterstützt. OpenSSH ist die Version, die installiert wird, wenn Sie auf Debian das Paket 'ssh' auswählen.
Mehr Informationen, wie Sie SSH mit Unterstützung für PAM aufsetzen, finden Sie
hier: security
mailing list archives
.
Squid ist eine der verbreitesten Proxy/Cache Server, und es gibt ein paar
Sicherheitsaspekte, die Sie beachten sollten. Squid's standard Konfiguration
lehnt alle Abfragen von Nutzern ab. Sie sollten Squid so konfigurieren, dass
er Zugriffe von vertrauenswürdigen Nutzern, Computern oder Netzwerken erlaubt,
indem Sie eine Zugriffs-Kontroll-Liste (ACL, Acces Control List) in
/etc/squid.conf
definieren. Mehr Informationen, wie Sie ACLs
definieren, finden Sie in der Squid User's
Guide
.
Ebenso kann bei ungeeigneter Konfiguration vorkommen, dass jemand eine Mail über Squid weiterleitet, da die Protokolle HTTP und SMTP ein ähnliches Design haben. Squid's Standard Konfiguration verweigert Zugriffe auf Port 25. Wenn Sie Verbindungen an Port 25 erlauben wollen, fügen Sie ihn einfach in der Safe_ports-Liste hinzu. Aber dies ist NICHT empfohlen.
Passendes Aufsetzen und Konfigurieren des Proxy/Cache-Servers ist nur ein Teil der Absicherung Ihrer Seite. Eine andere notwendige Aufgabe ist es, Squid's Log-Dateien zu analysieren, um sicher zu gehen, dass alles so arbeitet, wie es sollte. Es gibt ein paar Pakete in Debian GNU/Linux, die einem Administrator hierbei helfen können. Die folgenden Pakete sind in Woody (Debian 3.0) verfügbar:
calamaris
- Log-Datei-Analysator für Squid oder Oops
Proxy-Log-Dateien.
modlogan
- Ein modularer Log-Datei-Analysator.
sarg
- Squid Analysis Report Generator.
FIXME: Add more information about security on Squid 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
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. Sie können die folgende Zeile in Ihre
proftpd.conf
im globalen Abschnitt hinzufügen, um die
chroot-Fähigkeiten zu nutzen:
DefaultRoot ~
Starten Sie proftpd neu, indem Sie /etc/init.d/proftpd restart 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 Logind und Authentifizierung Passwort als
Klartext sendet (dies ist kein Problem, wenn Sie einen anonymen, öffentlichen
Dienst anbieten) und es gibt bessere Alternativen in Debian hierzu. Zum
Beispiel sftp
(aus dem Paket ssh
). Es gibt natürlich
auch freue Implementierungen von SSH für andere Betriebssysteme, zum Beispiel
putty
oder
cygwin
.
Wenn Sie dennoch einen FTP Server verwalten wollen, während Sie den Nutzern
Zugriff via SSH gewähren, könnten Sie auf ein typisches Problem 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
.
Heutzutage werden X-Terminals bei mehr und mehr Firmen benutzt, so dass ein Server für viele Arbeitsplätze zuständig ist. Dies kann gefährlich sein, weil Sie dem Datei-Server erlauben müssen, sich mit den X-Clients zu verbinden (X Server aus Sicht von X. X vertauscht die Definition von Client und Server). Wenn Sie dem (sehr schlechten) Vorschlag von vielen Dokumentationen folgen, geben Sie auf Ihrer Maschine xhost + ein. Dies erlaubt jedem X-Client sich mit Ihrem System zu verbinden. Für etwas bessere Sicherheit, sollten Sie stattdessen das Kommando xhost +Rechnername verwenden, um den Zugriff auf bestimmte Rechner zu begrenzen.
Allerdings ist es eine viel sicherere Lösung, ssh zu benutzen, um X zu tunneln
und die gesamte Sitzung zu verschlüsseln. Dies kann automatisch geschehen,
wenn Sie sich auf eine andere Maschine via ssh einloggen. Sie müssen es nur in
der /etc/ssh/ssh_config
einschalten, indem Sie
X11Forwarding auf yes setzen. In den Zeiten von SSH
sollten Sie die xhost-basierte Zugriffskontrolle komplett über Bord werfen.
Zur besten Sicherheit, wenn Sie keinen X-Zugriff von anderen Maschinen benötigen, ist es, die Bindung auf Port 6000 abzuschalten, indem Sie einfach folgendes eingeben:
$ startx -- -nolisten tcp
Dies ist das Standard-Verhalten unter XFree 4.1.0 (der Xserver aus Debian 3.0).
Wenn Sie XFree 3.3.6 laufen lassen (d.h. wenn Sie Debian 2.2 benutzen) können
Sie /etc/X11/xinit/xserverrcc
editieren, damit Sie etwas erhalten
wie:
#!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp
Wenn Sie XDM benutzen, setzen Sie in /etc/X11/xdm/Xservers
auf
:0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. Wenn Sie GDM
benutzen, stellen Sie sicher, dass die Option -nolisten tcp in der
/etc/gdm/gdm.conf
gesetzt ist (was 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 Nutzern sie
aufheben kann, sollten Sie Konfigurationsdatei
/etc/X11/app-defaults/XScreenSaver
editieren, und die lock-Zeile
von
*lock: False
(das ist der Standardwert unter Debian) auf
*lock: True
ändern.
FIXME: add information on how to disable the screensavers which show the user desktop (which might have sensitive information).
Lesen Sie mehr zur Sicherheit von X Window in XWindow-User-HOWTO
(/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz
).
FIXME: Add info on thread of debian-security on how to change config files of XFree 3.3.6 to do this.
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:
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
Client auf den Druck-Server zu bekommen. Traditionell machen dies
lpr
und lp
so, dass das Client-Kommando die Daten in
das Spool-Verzeichnis kopiert oder 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/Rechner, die nicht drucken
dürfen, mittels Firewall abblocken wollen (Der lpr
-Daemon kann
nicht so konfiguriert werden, dass er nur auf eine bestimmte IP-Adresse hört.)
Sie sollten Lprng
gegenüber lpr
vorziehen, da er so
konfiguriert werden kann, dass er Zugang-Kontrolle über IP kann. Und Sie
können spezifizieren, auf welche Schnittstelle er sich binden soll (wenn auch
etwas sonderbar).
Wenn Sie Ihren Drucker nur lokal auf Ihrem System benutzen, werden Sie 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 der Server muss auf irgendeinem Port hören.
Wie auch immer: Wenn Sie cups
nur lokal benutzen möchten, können
Sie es so konfigurieren, dass er nur auf die lokale Schleife (loopback
interface) hört, indem Sie folgendes in Ihrer /etc/cups/cupsd.conf
ändern:
Listen 127.0.0.1:631
Es gibt noch andere Sicherheits-Optionen in diese Konfigurations-Datei, wie zum
Beispiel das Erlauben oder Verweigern von Netzwerken oder Rechnern. Wenn Sie
sie allerdings nicht benötigen, belassen Sie es am besten dabei, einfach nur
den Port, auf den gehört wird, einzuschränken. Cups
liefert auch
Dokumentation über den HTTP-Port. Wenn Sie diese potentiell 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 auch so angepasst werden, dass zusätzliche Fähigkeiten einschließlich SSL- und TLS-Zertifikate oder Verschlüsselung möglich werden. Die Handbücher finden Sie unter http://localhost:631/ oder http://cups.org.
FIXME: Add more content (the article on Amateur Fortress Building
provides
some very interesting views).
FIXME: Check if PDG is available in Debian, and if so, suggest this as the preferred printing system.
FIXME: Check if Farmer/Wietse has a replacement for printer daemon and if it's available in Debian.
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-System zu erhalten.
Um dies auf einem Debian-System zu erreichen, entfernen Sie den SMTP-Daemon auf dem inetd:
$ update-inetd --disable smtp
und konfigurieren Sie den Mailer-Daemon so, dass er nur auf die lokale Schleife
achtet. In exim (dem Standard Mail Transport Agent (MTA) unter Debian) tun Sie
dies, indem Sie die in der Datei /etc/exim.conf
die Zeile
local_interfaces = "127.0.0.1"
hinzufügen.
Starten Sie beide Daemonen neu (inetd und exim) und exim wird lediglich auf den Socket 127.0.0.1:25 reagieren. Seien Sie vorsichtig und deaktivieren Sie erst inetd, oder exim wird nicht neu starten, da der inetd bereits eingehende Verbindungen behandelt.
Bei postfix
editieren Sie /etc/postfix/main.conf
:
inet_interfaces = localhost
Wenn Sie Mails lediglich lokal entgegennehmen 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 sollen. Wenn
Sie jedoch auch auf andere Schnittstellen reagieren müssen, sollten Sie
überlegen, ihn vom inetd aufrufen zu lassen und einen tcp-Wrapper einzusetzen,
so dass eingehende Verbindungen gegen /etc/hosts.allow
und
/etc/hosts.deny
geprüft werden. Außerdem werden Sie von
unautorisierte Zugriffsversuche gegen Ihren Mail-Daemon durch angemessenes
Protokollieren gewarnt werden wollen.
In jedem Fall können Sie Mail-Relais-Versuche auf 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 relayen wird ist diese Konfiguration für
den Relay-Test auf http://www.abuse.net/relay.html
nötig, um festzustellen, dass Ihr Server nicht relaisfähig ist.
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-recursive und Version. Sie können dies in dem global
Abschnitt tun (so wird es auf alle Zonen angewandt) oder jeweils pro Zone.
Dies ist im Paket bind-doc
dokumentiert, sobald das Paket
installiert ist können Sie hierzu mehr in
/usr/share/doc/bind/html/index.html
lesen.
Stellen Sie sich vor, Ihr Server ist mit dem Internet und Ihrem internen
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-recursive { 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-recursive { internal; }; allow-transfer { none; }; }; // Ab hier bis zur meineseite.bogus Zone // ist alles im Grunde die unveränderte Debian Standard Einstellung logging { category lame-servers { null; }; category cname { null; }; }; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; // Zone, die ich selbst hinzugefuegt habe zone "meineseite.bogus" { type master; file "/etc/bind/named.meineseite"; allow-query { any; }; allow-transfer { friendly; }; };
Bitte prüfen Sie (erneut) die Debian-Fehler-Datenbank (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 Beispiel
Skript, 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:
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
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 normalerweise nicht als
nicht-root User auf Debian Systemen läuft, sehen Sie bitte in der
Fehlerdatenbank zu Bind nach, insbesondere Bug #50013: bind should not run as
root
und Bug #132582:
Default install is potentially insecure
, Bug #53550
, Bug #128120
, und Bug #128120
. Fühlen Sie sich
ruhig dazu ermuntert, etwas zu den Fehlermeldungen beizutragen, wenn Sie
denken, 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 Benutzen von chroot,
Abschnitt 4.12) um Ihren Daemon herum bauen. Es gibt da einen sehr
einfachen Weg dies zu erreichen: Die -t Option (siehe die
Handbuchseite named(8)
). Dies wird Bind selbst in ein bestimmtes
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 Sie in diesem Chroot-Gefängnis benötigen, sind:
dev/null etc/bind/ - sollte die named.conf und alle Server-Zonen enthalten sbin/named-xfer - wenn Sie Namen transferieren var/run/named/ - sollte die pid und den Cache des Name-Server (falls es ihn gibt) enthalten. Dieses Verzeichniss muss für den named-User schreibbar sein. var/log/named - Wenn Sie in einer Datei protokollieren, muss dies für den 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 lese-Zugriff 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://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 compilieren. Sie können hierzu apt-get
mit der
source Option benutzen. Es kann sogar die Pakete herunterladen,
die Sie zum Compilieren benötigen. Sie müssten etwas ä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 @CFLOAGS@ Definition von autoconf verwendet wird) $ dpkg-buildpackage -rfakeroot $ cd .. $ dpkg -i bind-8.2.5-2*deb
Nach der Installation werden Sie die Dateien in das Chroot-Gefängnis
verschieben müssen [6]. 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.
FIXME, merge info from http://people.debian.org/~pzn/howto/chroot-bind.sh.txt
,
http://people.pdxlinux.org/~karlheg/
(Bind9 in Debian), http://www.cryptio.net/~ferlatte/config/
(Debian-spezifisch), http://www.psionic.com/papers/whitep01.html
,
http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm
und http://www.acmebw.com/papers/securing.pdf
.
FIXME: Add content.
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
).
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.
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.
Dies trifft auch auf andere Programme mit komplexen Funktionen und größerer Nutzergemeinde zu, einschließlich sendmail und einige ftp-Daemonen (z.B. wu-ftpd). (Natürlich kann auch ein Programm ohne viele Funktionen, das seine Nutzer nicht zufrieden stellt, unsicher sein, abgesehen davon, dass es nutzlos ist.)
In jedem Fall sollten Sie, wenn Sie diese laufen lassen, ähnliche Arrangements für sie in Erwägung ziehen — entziehen von root-Privilegien, einsperren in ein chroot-Gefängnis — oder ersetzen durch ein sichereres Äquivalent.
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 kaputt geht.
Wenn Sie Passwörter zwischen verschiedenen Maschinen teilen müssen, sollten Sie
andere alternativen in Erwägung ziehen. Zum Beispiel können Sie einen LDAP
Server aufsetzen, und PAM auf Ihren System so konfigurieren, dass es den LDAP
Server zur User Authentifizierung kontaktiert. Sie finden ein detailliertes
Setup in dem LDAP-HOWTO
(/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz
).
Lesen Sie mehr zu Sicherheit und NIS in dem NIS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz
).
FIXME (jfs): Add info on how to setup this in Debian
Sie sollten RPC wann immer nur möglich abschalten, dass ist dann der Fall, wenn
Sie ihn nicht benötigen. [7] Es
sind viele Sicherheitslöcher sowohl für den Portmapper, als auch für
RPC-basierende Dienste bekannt und könnten sehr leicht ausgenutzt werden.
Andererseits können NFS-Dienste in manchen Netzwerken sehr wichtig sein, also
versuchen Sie in Ihrem Netzwerk die Balance zwischen Sicherheit und Nutzbarkeit
zu wahren. Einige DDoS (distributed denial of service) Angriffe benutzen
RPC-Löcher, um in das System einzudringen und als so genannter Agent/Handler zu
fungieren. Lesen Sie mehr zu Sicherheit in NFS im NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz
).
Das Abschalten von portmap ist relativ einfach. Es gibt aber verschiedene
Methoden. Die einfachste ist es auf einem Debian 3.0 System 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, dies liegt daran, dass das Programm Teil des
Pakets net-base
(das nicht deinstalliert werden kann, ohne das
System kaputt zu machen) ist.
Dies entfernt in der Tat jeden symbolischen Link der etwas mit portmap zu tun
hat unterhalb von /etc/rc${runlevel}.d/, was Sie auch manuell
erledigen können. Eine andere Möglichkeit ist chmod 644
/etc/init.d/portmap, das erzeugt aber eine Fehlermeldung während des
Bootvorgang. Sie können auch den start-stop-daemon Teil im
/etc/init.d/portmap
Shell-Skript auskommentieren.
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. Sie müssen dann
das Paket ipchains
installieren, was (durch seine Priorität)
sicherlich bereits der Fall ist. Wenn Sie ein Woody-System (Debian 3.0)
installiert haben (mit dem standardmäßigen 2.4er Kernel) unterstützt der Kernel
Ihr iptables
(neftfilter). Der Hauptunterschied zwischen
ipchains
und iptables
ist, dass letzteres auf
stateful packet inspection (zustandsbehaftete Paket- untersuchung), 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 letztes in dieser Anleitung, weil es viel besser ist, sich nicht alleine auf die Fähigkeiten der Firewall zu verlassen, um ein System zu schützen. Die Sicherheit eines Systems setzt sich 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 Mißkonfigurationen oder frisch installierten Diensten, die noch nicht passend konfiguriert sind, schützen. Außerdem wird eine enge Konfiguration nach Hause telefonierende Trojaner am Funktionieren hindern, es sei denn, der Firewall-Code wurde entfernt. Beachten Sie, dass ein Eindringling keinen Superuser-Zugriff benötigt, um 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 noch vorhanden sind).
Demzufolge wäre ein passendes Firewall-Setup, eines mit einer standardmäßigen deny policy (also alles ablehnt, dass 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. Die Firewall kann so konfiguriert werden, dass Sie verhindert dass System von Außerhalb des lokalen Netzwerks Zugriff auf nicht öffentliche Dienste (Ports) bekommen. Zum Beispiel muss auf einem Mail-Server lediglich Port 25 (auf den 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 Dienste 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.
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 nicht viel über Firewalls wissen, lesen Sie das Firewalling-HOWTO, das
Sie im Paket doc-linux-text
finden (andere Formate gibt es auch).
Sehen Sie auch Seien Sie wachsam gegenüber
generellen Sicherheitsproblemen!, Abschnitt 2.2 für weitere (allgemeinere)
Verweise.
Wenn Sie Debian 3.0 benutzen, werden Sie feststellen, dass Sie bereits das
Paket iptables
installiert haben. Dies ist die Unterstützung für
die Netfilter-Implementation in 2.4.4+ 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
Skripten 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 Nutzen von
Firewall-Paketen, Abschnitt 5.15.3.2). 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.
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. Zudem stellt die
Konfigurationsdatei /etc/default/iptables
noch weitere
Informationen zu diesem Paket zur Verfügung.
Das manuelle Aufsetzen einer Firewall kann für neue (und manchmal auch für erfahrene) Administratoren kompliziert sein. Hierfür hat die Freie-Software Gemeinschaft eine große Zahl von Tools erstellt, die zur einfachen Konfiguration einer Lokalen Firewall benutzt werden können. Seien Sie vor gewarnt, dass einige dieser Tools sich mehr auf lokalen Schutz konzentrieren (auch 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
knetfilter
fwbuilder
shorewall
mason
, das basierend auf dem Netzwerkverkehr, denn Ihr System
"sieht", Firewall-Regeln vorschlagen kann
bastille
(unter anderem besitzt diese neue Version von bastille
unter den Abhärtungsstufen die Möglichkeit, Firewall-Regeln während des Starts
auszuführen)
ferm
fwctl
easyfw
firewall-easy
ipac-ng
gfcc
lokkit
oder gnome-lokkit
Die Pakete gfcc, firestarter und knetfilter sind graphische Administrations-Schnittstellen, die entweder GNOME (die ersten beiden) oder KDE (das letzte) benutzen und die eher benutzerorientiert sind (z.B. für Heimanwender) als die anderen Pakete in der Liste, die sich eher an Administratoren richten.
Seien Sie vor gewarnt, dass manche der zuvor skizzierten Pakete eigene Firewall-Skripten einführen, die beim Systemstart ausgeführt werden sollen, dies wird zweifellos mit dem allgemeinen Setup (wenn konfiguriert) kollidieren und dürfte zu unerwünschten Nebeneffekten führen. Das Firewall-Skript, das zuletzt ausgeführt wird, wird das System konfigurieren (was Sie so vielleicht nicht vorhatten). Sehen Sie hierzu in der Paket-Dokumentation nach und benutzen Sie nur eines dieser Setups. Allgemeiner: Andere Programme, die helfen die Firewall-Regeln aufzusetzen, können in den Konfigurationsdateien anderer rum pfuschen.
FIXME: Add more info regarding this packages
FIXME: Check Information on Debian firewalling and what/how does it change from other distributions.
FIXME: Where should the custom firewalling code be enabled (common FAQ in debian-firewall?)
Anleitung zum Absichern von Debian
Version: 2.5 (beta), Fri, 03 Dec 2004 23:31:52 +0000jfs@debian.org