In diesem Abschnitt werden Anwendungen
fett gekennzeichnet, spezifische
Kommandos werden in einer Fixschrift
dargestellt und Protokolle verwenden die normale Schriftart.
Diese typographische Konvention hilft, Begriffe wie ssh
zu unterscheiden, die sowohl Protokoll als auch Kommando
sein können.
Die folgenden Abschnitte behandeln die im letzten Abschnitt erwähnten Methoden Ihr FreeBSD-System zu sichern.
Zuallererst, kümmern Sie sich nicht um die Absicherung
von Accounts, wenn Sie root
noch nicht abgesichert haben. Auf den meisten Systemen ist
root
ein Passwort zugewiesen. Sie
sollten immer davon ausgehen, dass
dieses Passwort kompromittiert ist. Das heißt nicht,
dass Sie das Passwort entfernen sollten, da es meist
für den Konsolenzugriff notwendig ist. Vielmehr heißt
es, dass Sie das Passwort nicht außerhalb der
Konsole, auch nicht zusammen mit su(1), verwenden sollten.
Stellen Sie sicher, dass Ihre PTYs in ttys
als
unsicher markiert sind und damit Anmeldungen von
root
mit telnet
oder
rlogin
verboten sind. Wenn Sie andere
Anwendungen wie SSH zum Anmelden
benutzen, vergewissern Sie sich, dass dort ebenfalls
Anmeldungen als root
verboten sind. Für
SSH editieren Sie
/etc/ssh/sshd_config
und überprüfen,
dass PermitRootLogin
auf no
gesetzt ist. Beachten Sie jede Zugriffsmethode – Dienste
wie FTP werden oft vergessen. Nur an der Systemkonsole sollte
ein direktes Anmelden als root
möglich
sein.
Natürlich müssen Sie als Systemadministrator
root
-Zugriff erlangen können. Dieser
sollte aber durch zusätzliche Passwörter
geschützt sein. Ein Weg, Zugang zu root
zu ermöglichen, ist es, berechtigte Mitarbeiter in
/etc/group
in die Gruppe
wheel
aufzunehmen. Die Personen, die
Mitglieder in der Gruppe wheel
sind,
können mit su
zu root
wechseln. Ihre Mitarbeiter sollten niemals die Gruppe
wheel
als primäre Gruppe in
/etc/passwd
besitzen. Mitarbeiter sollten
der Gruppe staff
angehören und über
/etc/group
in wheel
aufgenommen werden. Es sollten auch nur die Mitarbeiter, die
wirklich root
Zugriff benötigen in
wheel
aufgenommen werden. Mit anderen
Authentifizierungsmethoden müssen Sie niemanden in
wheel
aufnehmen. Wenn Sie z.B.
Kerberos benutzen, wechseln Sie mit
ksu(1) zu root
und der Zugriff wird
mit der Datei .k5login
geregelt. Dies ist
vielleicht eine bessere Lösung, da es der
wheel
-Mechanismus einem Angreifer immer
noch möglich macht, den root
-Account
zu knacken, nachdem er einen Mitarbeiter-Account geknackt hat.
Obwohl der wheel
-Mechanismus besser als
gar nichts ist, ist er nicht unbedingt die sicherste Lösung.
Um ein Konto komplett zu sperren, verwenden Sie den Befehl pw(8):
#
pw lock staff
Danach ist es diesem Benutzer nicht mehr möglich (auch nicht mit ssh(1)), sich anzumelden.
Eine weitere Möglichkeit, bestimmte Benutzer zu sperren,
ist es, das verschlüsselte Passwort durch das Zeichen
„*
“ zu ersetzen. Da ein
verschlüsseltes Passwort niemals diesem Zeichen entsprechen
kann, kann sich der betroffene Benutzer ebenfalls nicht mehr
anmelden. Beispielsweise müsste dazu das Konto
wie folgt abgeändert werden:
Durch diese Änderung wird der Benutzer
foobar
daran gehindert, sich auf
konventionellem Wege am System anzumelden. Diese
Maßnahmen greifen allerdings nicht, wenn das betroffene
System auch eine Anmeldung über
Kerberos oder ssh(1) erlaubt.
Diese Sicherheitsmechanismen setzen voraus, dass Sie sich von einer restriktiven Maschine auf einer weniger restriktiven Maschine anmelden. Wenn zum Beispiel auf Ihrem Hauptrechner alle möglichen Arten von Servern laufen, so sollten auf Ihrer Workstation keine Server laufen. Um Ihre Workstation vernünftig abzusichern, sollten auf Ihr so wenig Server wie möglich bis hin zu keinem Server laufen. Sie sollten zudem über einen Bildschirmschoner verfügen, der mit einem Passwort gesichert ist. Natürlich kann ein Angreifer, der physikalischen Zugang zu einer Maschine hat, jede Art von Sicherheitsmechanismen umgehen. Dieses Problem sollten Sie daher auch in Ihren Überlegungen berücksichtigen. Beachten Sie dabei aber, dass der Großteil der Einbrüche über das Netzwerk erfolgt und die Einbrecher keinen Zugang zu der Maschine besitzen.
Mit Kerberos können Sie das Passwort eines Mitarbeiters an einer Stelle ändern und alle Maschinen, auf denen der Mitarbeiter einen Account hat, beachten die Änderung sofort. Wird der Account eines Mitarbeiters einmal kompromittiert, so sollte die Fähigkeit, das Passwort mit einem Schlag auf allen Maschinen zu ändern, nicht unterschätzt werden. Mit einzelnen Passwörtern wird es schwierig, das Passwort auf N Maschinen zu ändern. Mit Kerberos können Sie auch Beschränkungen für Passwörter festlegen: Nicht nur das Ticket kann nach einiger Zeit ungültig werden, Sie können auch festlegen, dass ein Benutzer nach einer bestimmten Zeit, z.B. nach einem Monat, das Passwort wechseln muss.
Ein kluger Systemadministrator lässt nur die
Dienste, die er wirklich braucht, laufen; nicht mehr und auch
nicht weniger. Beachten Sie, dass Server von Dritten die
fehleranfälligsten sind. Wenn Sie z.B. eine alte Version von
imapd oder popper
laufen lassen, ist das so, als würden Sie der ganzen Welt
freien Zugang zu root
geben. Lassen Sie keine
Server laufen, die Sie vorher nicht genau überprüft haben.
Viele Server müssen nicht unter root
laufen, zum Beispiel können ntalk,
comsat und finger
in speziellen Sandkästen unter
einem Benutzer laufen. Ein Sandkasten ist keine perfekte Lösung,
wenn Sie nicht eine Menge Arbeit in die Konfiguration investieren,
doch bewährt sich hier das Prinzip, die Sicherheit in Schichten
aufzubauen. Wenn es einem Angreifer gelingt, in einen Server,
der in einem Sandkasten läuft, einzubrechen, dann muss
er immer noch aus dem Sandkasten selber ausbrechen. Je mehr Schichten
der Angreifer zu durchbrechen hat, desto kleiner sind seine Aussichten
auf Erfolg. In der Vergangenheit wurden praktisch in jedem
Server, der unter root
läuft, Lücken
gefunden, die zu einem root
Zugriff führten.
Dies betrifft selbst die grundlegenden Systemdienste. Wenn Sie eine
Maschine betreiben, auf der man sich nur mit
SSH anmelden kann, dann stellen Sie die
Dienste telnetd,
rshd oder rlogind
ab!
In der Voreinstellung laufen unter FreeBSD
ntalkd, comsat
und finger nun in einem Sandkasten. Ein
weiteres Programm, das in einem Sandkasten laufen sollte, ist
named(8). In /etc/defaults/rc.conf
sind
die notwendigen Argumente, um named in
einem Sandkasten laufen zu lassen, in kommentierter Form schon
enthalten. Abhängig davon, ob Sie ein neues System installieren
oder ein altes System aktualisieren, sind die hierfür
benötigten Benutzer noch nicht installiert.
Ein kluger Systemadministrator sollte immer nach Möglichkeiten
suchen, Server in einem Sandkasten laufen zu lassen.
Einige Server wie sendmail,
popper, imapd
und ftpd werden normalerweise nicht in
Sandkästen betrieben. Zu einigen Servern gibt es Alternativen,
aber diese wollen Sie vielleicht wegen der zusätzlich nötigen
Arbeit nicht installieren (ein weiteres Beispiel für den
Widerspruch zwischen Sicherheit und Benutzerfreundlichkeit).
In diesem Fall müssen Sie die
Server unter root
laufen lassen und auf die
eingebauten Mechanismen vertrauen, Einbrüche zu entdecken.
Weitere potentielle Löcher, die zu einem
root
-Zugriff führen können, sind
die auf dem System installierten SUID- und SGID-Programme. Die
meisten dieser Programme wie rlogin stehen
in /bin
,
/sbin
,
/usr/bin
, oder
/usr/sbin
.
Obwohl nichts 100% sicher ist, können Sie davon ausgehen,
dass die SUID- und SGID-Programme des Basissystems ausreichend
sicher sind. Allerdings werden ab und an in diesen Programmen
Löcher gefunden. 1998 wurde in Xlib
ein
Loch gefunden, das xterm, der
normal mit SUID installiert wird, verwundbar machte. Es ist besser
auf der sicheren Seite zu sein, als sich später zu beklagen,
darum wird ein kluger Systemadministrator den Zugriff auf
SUID-Programme mit einer Gruppe, auf die nur Mitarbeiter zugreifen
können, beschränken. SUID-Programme, die niemand benutzt,
sollten mit chmod 000
deaktiviert werden. Zum
Beispiel braucht ein Server ohne Bildschirm kein
xterm Programm. SGID-Programme sind
vergleichbar gefährlich. Wenn ein Einbrecher Zugriff auf
SGID-kmem
Programm erhält, kann er
vielleicht /dev/kmem
und damit die
verschlüsselte Passwortdatei lesen. Dies kompromittiert
unter Umständen jeden Account, der mit einem Passwort
geschützt ist. Alternativ kann ein Einbrecher, der in die
Gruppe kmem
eingebrochen ist, die
Tastendrücke auf PTYs verfolgen. Dies schließt
auch PTYs mit ein, auf denen sich ein Benutzer mit sicheren
Methoden anmeldet. Ein Einbrecher, der Zugriff auf die
tty
Gruppe hat, kann auf fast jeden Terminal
anderer Benutzer schreiben. Wenn der Benutzer einen Terminal-Emulator
benutzt, der über eine Tastatur-Simulation verfügt,
könnte der Angreifer Daten generieren, die den Terminal
veranlassen, ein Kommando unter diesem Benutzer laufen zu lassen.
Accounts sind für gewöhnlich sehr schwierig abzusichern. Während Sie drakonische Beschränkungen für Ihre Mitarbeiter einrichten und deren Passwörter als ungültig markieren können, werden Sie das vielleicht bei den normalen Accounts nicht durchsetzen. Wenn Sie über ausreichend Macht verfügen, gelingt es Ihnen vielleicht doch, ansonsten müssen Sie diese Accounts aufmerksam überwachen. Wegen der zusätzlichen Administrationsarbeit und der nötigen technischen Unterstützung ist die Verwendung von SSH und Kerberos mit normalen Accounts erschwert, obwohl das natürlich sicherer als die Verwendung von verschlüsselten Passwörtern ist.
Der einzig sichere Weg ist, so viele Accounts wie möglich als
ungültig zu markieren und SSH oder
Kerberos zu benutzen, um auf sie
zuzugreifen. Obwohl die Datei /etc/spwd.db
,
die die verschlüsselten Passwörter enthält,
nur von root
gelesen werden kann, mag ein
Angreifer lesenden Zugriff auf diese Datei erlangen, ohne die
Fähigkeit sie auch zu beschreiben.
Ihre Überwachungsskripten sollten Änderungen an der Passwort-Datei melden (siehe Überprüfen der Integrität von Dateien weiter unten).
Wenn ein Angreifer root
-Zugriff erlangt,
kann er so ziemlich alles mit Ihrem System anstellen, doch sollten Sie
es ihm nicht zu leicht machen. Die meisten modernen Kernel haben
zum Beispiel einen Gerätetreiber, der es erlaubt, Pakete
abzuhören. Unter FreeBSD wird das Gerät
bpf
genannt. Für gewöhnlich
wird ein Angreifer versuchen, dieses Gerät zu nutzen, um
Pakete abzuhören. Sie sollten ihm diese Gelegenheit nicht
geben und auf den meisten Systemen ist das Gerät
bpf
nicht nötig.
Auch wenn Sie bpf
nicht verwenden,
müssen Sie sich immer noch um /dev/mem
und /dev/kmem
sorgen. Außerdem
kann der Angreifer immer noch auf die rohen Geräte
(raw devices)
schreiben. Weiterhin gibt es ein Programm zum Nachladen von
Modulen in den Kernel: kldload(8). Ein unternehmungslustiger
Angreifer kann dies benutzen, um sein eigenes
bpf
oder ein anderes zum Abhören
geeignetes Gerät in den laufenden Kernel einzubringen. Um
dieses Problem zu vermeiden, müssen Sie den Kernel auf
einem höheren Sicherheitslevel laufen lassen, mindestens
auf securelevel 1.
Das Securelevel des Kernels kann auf verschiedene Wege
gesetzt werden. Der einfachste Weg ist das erhöhen des
Securelevel des laufenden Kernels durch ein
sysctl
der kern.securelevel
Kernel Variablen:
#
sysctl kern.securelevel=1
Standardmässig bootet der FreeBSD Kernel mit einem
Securelevel von -1. Der Securelevel wird solange bei -1 bleiben,
bis er entweder durch den Administrator oder von init(8)
durch einen Eintrag im Startup Script verändert wird. Der
Securelevel kann während des Systemstarts durch das Setzen
der Variable kern_securelevel_enable
auf
YES
und der Wert der Variable
kern_securelevel
auf den gewünschten
Securelevel in der /etc/rc.conf
erhöht werden.
Der Standard Securelevel von einem FreeBSD-System direkt nach dem Start ist -1. Dies wird „insecure mode“ genannt, da zum Beispiel unverändeliche Dateiflags abgeschaltet werden könnten, von allen Geräten gelesen und auf alle geschrieben werden kann.
Sobald der Securelevel auf den Wert 1 oder höher gesetzt ist, werden die append-only und die unveränderlichen Dateien geschützt, die Flags können nicht abgeschaltet werden und der Zugriff auf raw Devices ist verboten. Höhere Levels verbieten mehr Aktionen. Für einen vollständige Liste aller Securelevels, lesen Sie bitte die security(7) Manual Seite (oder die Manual Seite von init(8) für ältere Releases als FreeBSD 7.0).
Das Erhöhen des Securelevels auf 1 oder höher
kann einige Probleme mit X11 verursachen (Zugriff auf
/dev/io
wird geblockt), ebenso die Installation
von FreeBSD aus den Quellen (der installworld
Teil muss zeitweilig die append-only und die
unveränderlichen Flags einiger Dateien zurücksetzen),
und auch noch in einigen anderen Fällen. Manchmal kann es,
wie bei X11, durch das sehr frühe Starten von xdm(1)
im Boot Prozess möglich sein, dies zu umgehen, wenn der
Securelevel noch niedrig genug ist.
Workarounds wie dieser sind nicht f¨r alle Securelevels
und für alle Einschränkungen, die sie schaffen,
möglich. Ein bisschen Vorausplanung ist eine gute
Idee. Das Verständnis für die Beschränkungen,
die durch jedes Securelevel verursacht werden, ist wichtig, da sie
die einfache Benutzung des Systems verschlechtern. Es vereinfacht
auch die Wahl einer Standardeinstellung und schützt vor
Überraschungen.
Wenn das Securelevel des Kernel auf einen Wert von 1 oder
höher gesetzt ist, kann es sinnvoll sein das
schg
Flag auf kritische Startdateien,
Verzeichnisse und Scripte (z.B. alles was läuft bis zu
dem Punkt auf dem das Securelevel gesetzt ist) zu setzen. Dies
könnte etwas übertrieben sein, und auch das Upgrade
des Systems ist sehr viel schwerer, wenn es auf einem hohen
Securelevel läuft. Ein strengerer Kompromiss ist es, das
System auf einem höheren Securelevel laufen zu lassen, aber
keine schg
Flags für alle Systemdateien
und Verzeichnisse zu setzen. Eine andere Möglichkeit ist es,
einfach die Verzeichnisse /
und
/usr
read-only zu mounten.
Es sei darauf hingewiesen, dass Sie nicht vor lauter Überlegen
das Wichtigste, nämlich die Entdeckung eines Eindringens,
vergessen.
Sie können die Systemkonfiguration und die Dateien
nur so weit schützen, wie es die Benutzbarkeit des
Systems nicht einschränkt. Wenn Sie zum Beispiel
mit chflags
die Option schg
auf die meisten Dateien in /
und
/usr
setzen, kann das Ihre
Arbeit mehr behindern
als nützen. Die Maßnahme schützt zwar die
Dateien, schließt aber auch eine Möglichkeit,
Veränderungen zu entdecken, aus. Die letzte Schicht des
Sicherheitsmodells – das Aufdecken von Einbrüchen –
ist sicherlich die wichtigste. Alle Sicherheitsmaßnahmen sind
nichts wert, oder wiegen Sie in falscher Sicherheit, wenn Sie
nicht in der Lage sind, einen möglichen Einbruch zu entdecken.
Die Hälfte der Sicherheitsmaßnahmen hat die Aufgabe,
einen Einbruch zu verlangsamen, um es zu ermöglichen, den
Einbrecher auf frischer Tat zu ertappen.
Der beste Weg, einen Einbruch zu entdecken, ist es, nach veränderten, fehlenden oder unerwarteten Dateien zu suchen. Der wiederum beste Weg, nach veränderten Dateien zu suchen, ist es, die Suche von einem anderen (oft zentralen) besonders geschützten System durchzuführen. Es ist wichtig, dass Ihre Sicherheitsüberprüfungen vor einem Angreifer verborgen bleiben und daher sind sie auf einem besonders geschützten System gut aufgehoben. Um dies optimal auszunutzen, müssen Sie dem besonders geschützten System Zugriffsrechte auf die zu schützenden Systeme geben. Sie können die Dateisysteme der zu schützenden Systeme schreibgeschützt für das besonders geschützte System exportieren, oder Sie können der besonders geschützten Maschine SSH auf die anderen Maschinen erlauben, indem Sie SSH-Schlüsselpaare installieren. Mit Ausnahme des verursachten Netzwerkverkehrs ist die NFS-Methode die am wenigsten sichtbare. Sie erlaubt es Ihnen, nahezu unentdeckt die Dateisysteme der Clients zu beobachten. Wenn Ihr besonders geschütztes System mit den Clients über einen Switch verbunden ist, ist die NFS-Methode oft das Mittel der Wahl. Wenn das besonders geschützte System allerdings mit einem Hub verbunden ist, oder der Zugriff über mehrere Router geschieht, ist die NFS-Methode aus der Netzwerksicht zu unsicher. In einem solchen Fall ist SSH besser geeignet, auch wenn es deutliche Spuren hinterlässt.
Wenn das besonders geschützte System lesenden Zugriff
auf die Clients hat, müssen Sie Skripten schreiben, die die
Überwachung durchführen. Wenn Sie die NFS-Methode
verwenden, können Sie dazu einfache Systemwerkzeuge wie
find(1) und md5(1) benutzen. Am besten berechnen
Sie einmal am Tag MD5-Prüfsummen der Dateien, Konfigurationsdateien
in /etc
und
/usr/local/etc
sollten öfter überprüft werden. Wenn Unstimmigkeiten
zwischen den auf der besonders geschützten Maschine gehaltenen
MD5-Prüfsummen und den ermittelten Prüfsummen festgestellt
werden, sollte Ihr System einen Systemadministrator benachrichtigen,
der den Unstimmigkeiten dann nachgehen sollte. Ein gutes Skript
überprüft das System auch auf verdächtige
SUID-Programme sowie gelöschte oder neue Dateien in
/
und
/usr
.
Wenn Sie SSH anstelle von NFS
benutzen, wird das Erstellen der Skripten schwieriger. Sie müssen
die Skripten und die Programme wie find
mit
scp
auf den Client kopieren. Damit machen
Sie die Überprüfung für einen Angreifer sichtbar.
Außerdem kann der SSH-Client auf dem
Zielsystem schon kompromittiert sein. Zusammenfassend kann der
Einsatz von SSH nötig sein,
wenn Sie über ungesicherte Verbindungen arbeiten, aber
der Umgang mit dieser Methode ist auch sehr viel schwieriger.
Ein gutes Sicherheitsskript wird auch Dateien von Benutzern,
die den Zugriff auf ein System ermöglichen, wie
.rhosts
, .shosts
,
.ssh/authorized_keys
usw., auf
Veränderungen untersuchen, die über die Möglichkeiten
einer Überprüfung mit MD5
(die ja nur Veränderungen erkennen kann) hinausgehen.
Wenn Sie über große Partitionen verfügen, kann
es zu lange dauern, jede Datei zu überprüfen. In diesem
Fall sollten Sie beim Einhängen des Dateisystems Optionen
setzen, die das Ausführen von SUID-Programmen verbieten.
mount(8) stellt dazu nosuid
zur Verfügung. Sie sollten diese Dateien aber trotzdem
mindestens einmal die Woche überprüfen, da das Ziel
dieser Schicht das Aufdecken eines Einbruchs, auch wenn er nicht
erfolgreich war, ist.
Die Prozessüberwachung (siehe accton(8)) des Betriebssystems steht ein günstiges Werkzeug zur Verfügung, dass sich bei der Analyse eines Einbruchs als nützlich erweisen kann. Insbesondere können Sie damit herausfinden, wie der Einbrecher in das System eingedrungen ist, vorausgesetzt die Dateien der Prozessüberwachung sind noch alle intakt.
Schließlich sollten die Sicherheitsskripten die Logdateien
analysieren. Dies sollte so sicher wie möglich durchgeführt
werden, nützlich ist das Schreiben von Logdateien auf
entfernte Systeme mit syslog
. Ein Einbrecher
wird versuchen, seine Spuren zu verwischen. Die Logdateien
sind wichtig für den Systemadministrator, da er aus ihnen
den Zeitpunkt und die Art des Einbruchs bestimmen kann. Eine
Möglichkeit, die Logdateien unverändert aufzuheben,
ist es, die Systemkonsole auf einen seriellen Port zu legen
und die Informationen dort von einer gesicherten Maschine
auszulesen.
Es schadet nicht, ein bisschen paranoid zu sein. Grundsätzlich darf ein Systemadministrator jede Sicherheitsmaßnahme treffen, die die Bedienbarkeit des Systems nicht einschränkt. Er kann auch Maßnahmen treffen, die die Bedienbarkeit einschränken, wenn er diese vorher genau durchdacht hat. Was noch wichtiger ist: Halten Sie sich nicht sklavisch an dieses Dokument, sondern führen Sie eigene Maßnahmen ein, um nicht einem künftigen Angreifer, der auch Zugriff auf dieses Dokument hat, alle Ihre Methoden zu verraten.
Dieser Abschnitt behandelt Denial-of-Service Angriffe (DoS). Ein DoS-Angriff findet typischerweise auf der Paketebene statt. Während Sie nicht viel gegen moderne Angriffe mit falschen Paketen, die das Netzwerk sättigen, ausrichten können, können Sie sehr wohl den Schaden begrenzen, den solche Angriffe verursachen können und insbesondere einen kompletten Serverausfall verhindern, indem Sie beispielsweise folgende Vorkehrungen treffen:
Begrenzen von fork()
Aufrufen.
Begrenzen von Sprungbrett-Angriffen (ICMP response Angriffen, ping zu Broadcast-Adressen usw.).
Kernel-Cache für Routen.
Ein häufiger DoS-Angriff gegen forkende Server versucht
den Server dazu zu bringen, solange neue Prozesse zu starten,
bis das System den ganzen Speicher und alle Dateideskriptoren
verbraucht hat, was dann zu einem Ausfall des Servers führt.
inetd(8) besitzt einige Optionen, um diese Art von Angriffen
zu begrenzen. Beachten Sie bitte, dass es möglich ist, einen
Ausfall einer Maschine zu verhindern, doch ist es generell nicht
möglich, den Ausfall eines Dienstes bei dieser Art
von Angriffen zu verhindern. Lesen Sie sich bitte die Manualpages
von inetd gut durch und achten Sie speziell
auf die Optionen -c
, -C
und
-R
. Angriffe mit gefälschten IP-Adressen
umgehen -C
, so dass normalerweise eine
Kombination der Optionen benutzt werden muss. Manche Server,
die nicht von inetd gestartet werden,
besitzen Optionen, um den Start über fork()
einzuschränken.
Sendmail besitzt die Option
-OMaxDaemonChildren
, die besser als die
eingebauten Optionen zur Begrenzung der Systemauslastung funktioniert.
Sie sollten beim Start von sendmail
MaxDaemonChildren
so hoch setzen, dass Sie
die erwartete Auslastung gut abfangen können. Allerdings
sollten Sie den Wert nicht so hoch setzen, dass der
Rechner über seine eigenen Füße fällt.
Es ist auch klug, Sendmail im
Queue-Modus (-ODeliveryMode=queued
) laufen zu
lassen. Der Dæmon (sendmail -bd
) sollte
getrennt von den Queue-Läufen (sendmail -q15m
)
laufen. Wenn Sie trotzdem eine sofortige Auslieferung der Post
wünschen, können Sie die Queue in einem geringeren
Intervall, etwa -q1m
, abarbeiten. Geben Sie
für dieses
Sendmail aber einen vernünftigen
Wert für MaxDaemonChildren
an, um
Fehler zu verhindern.
Syslogd kann direkt angegriffen
werden. Daher empfehlen wir Ihnen unbedingt die Option
-s
zu benutzen. Sollte das nicht möglich
sein, benutzen Sie bitte -a
.
Vorsicht ist auch mit Diensten geboten, die automatisch eine Rückverbindung eröffnen, wie der reverse-identd der TCP-Wrapper. Diese Funktion der TCP-Wrapper sollten Sie normalerweise nicht benutzen.
Es empfiehlt sich sehr, interne Dienste vor externen Zugriffen
durch eine Firewall an der Grenze Ihres Netzwerks zu schützen.
Dahinter steckt mehr die Idee, das Netzwerk vor Überlastung
durch Angriffe von außen zu schützen, als interne
Dienste vor einem root
-Zugriff aus dem Netz
zu schützen. Konfigurieren Sie immer eine Firewall, die
alle Zugriffe blockiert, das heißt blockieren Sie
alles außer den Ports A, B, C, D
und M-Z. Damit können Sie Zugriffe auf alle niedrigen
Ports blockieren und Zugriffe auf spezielle Dienste wie
named, wenn Sie den primären
Namensdienst für eine Zone anbieten,
ntalkd oder
sendmail erlauben. Wenn Sie die
Firewall so konfigurieren, das sie in der Voreinstellung alle
Zugriffe erlaubt, ist es sehr wahrscheinlich, dass Sie
vergessen, eine Reihe von Diensten zu blockieren bzw. einen
internen Dienst einführen und dann vergessen die Firewall
zu aktualisieren. Sie können immer die höheren
Portnummern öffnen, ohne die niedrigen Portnummern,
die nur von root
benutzt werden dürfen,
zu kompromittieren. Beachten Sie bitte auch, dass es
FreeBSD erlaubt, die Portnummern, die für dynamische
Verbindungen zur Verfügung stehen, zu konfigurieren.
Mit sysctl
lassen sich verschiedene
Bereiche der net.inet.ip.portrange
Variablen
setzen (eine Liste erhalten Sie mit sysctl -a | fgrep
portrange
).
So können Sie zum Beispiel die Portnummern 4000 bis 5000
für den normalen Bereich und die Nummern 49152 bis 65535
für den hohen Bereich vorsehen. Dies erleichtert Ihnen
die Konfiguration der Firewall, da Sie nun Zugriffe auf Ports
unterhalb von 4000, mit Ausnahme der Dienste, die von außen
erreichbar sein sollen, blockieren können.
Eine andere Form eines DoS-Angriffs nutzt einen Server
als Sprungbrett, der Server wird dabei so angegriffen, dass
seine Antworten ihn selber, das lokale Netzwerk oder einen
anderen Server überlasten. Der am häufigsten verwendete
Angriff dieser Art ist der ICMP ping broadcast
Angriff. Der Angreifer fälscht dazu
ping-Pakete, die zu der Broadcast-Adresse
Ihres LANs gesendet werden, indem er darin als Quelladresse
die Adresse des Opfers einsetzt. Wenn die Router an der Grenze
Ihres Netzwerks ping-Pakete auf
Broadcast-Adressen nicht abwehren, wird Ihr LAN genügend
Netzwerkverkehr generieren, um das Ziel des Angriffs zu
überlasten. Dies kann besonders effektiv sein, wenn der
Angreifer diese Methode mit mehreren Dutzend Broadcast-Adressen
über mehrere Netzwerke einsetzt. Es wurden schon
Broadcast-Angriffe mit über 120 Megabit pro Sekunde
gemessen. Ein zweiter Sprungbrett-Angriff wird gegen
das Fehlerbehandlungssystem von ICMP eingesetzt. Indem ein Angreifer
Pakete konstruiert, die eine ICMP-Fehlermeldung hervorrufen, kann
er das einkommende Netzwerk des Servers sättigen und diesen
wiederum veranlassen sein ausgehendes Netzwerk mit ICMP-Antworten
zu sättigen. Diese Art des Angriffs kann den kompletten
Speicher des Servers aufbrauchen und damit den Server stilllegen,
insbesondere wenn der Server nicht in der Lage ist, die generierten
ICMP-Antworten schnell genug abzuführen. Verwenden Sie die
sysctl-Variable
net.inet.icmp.icmplim
, um die Auswirkungen
solcher Angriffe zu begrenzen. Die letzte
weit verbreitete Form von Sprungbrett-Angriffen verwendet
interne inetd-Dienste wie den
UDP echo-Dienst. Der Angreifer fälscht
dazu einfach ein UDP-Paket, indem er als Quellport den
echo-Port von Server A
und als Zielport den echo-Port von
Server B angibt, wobei beide
Server in Ihrem LAN stehen. Die beiden Server werden nun
dieses Paket zwischen sich hin und her schicken. Der Angreifer
kann die beiden Server und das LAN einfach damit überlasten,
dass er mehrere Pakete dieser Art generiert. Ähnliche
Probleme gibt es mit dem internen
chargen-Port, daher sollten Sie
die internen inetd-Testdienste
abstellen.
Gefälschte IP-Pakete können dazu benutzt werden,
den Kernel-Cache für Routen zu überlasten. Schauen Sie
sich bitte die sysctl
-Parameter
net.inet.ip.rtexpire
, rtminexpire
und rtmaxcache
an. Ein Angriff der gefälschte
Pakete mit zufälligen Quelladressen einsetzt, bewirkt, dass
der Kernel eine Route im Route-Cache anlegt, die Sie sich mit
netstat -rna | fgrep W3
ansehen können.
Diese Routen verfallen für gewöhnlich nach 1600 Sekunden.
Wenn der Kernel feststellt, dass die Routingtabelle im Cache
zu groß geworden ist, wird er dynamisch den Wert von
rtexpire
verringern. Dieser Wert wird aber nie
kleiner werden als rtminexpire
. Daraus
ergeben sich zwei Probleme:
Der Kernel reagiert nicht schnell genug, wenn ein Server mit einer niedrigen Grundlast plötzlich angegriffen wird.
rtminexpire
ist nicht klein genug,
um einen anhaltenden Angriff zu überstehen.
Wenn Ihre Server über eine T3 oder eine noch schnellere
Leitung mit dem Internet verbunden sind, ist es klug, mit
sysctl(8) die Werte für rtexpire
und
rtminexpire
händisch zu setzen. Setzen
Sie bitte keinen der Werte auf Null, außer Sie wollen die
Maschine zum Erliegen bringen. Ein Wert von 2 Sekunden für
beide Parameter sollte ausreichen, um die Routingtabelle vor
einem Angriff zu schützen.
Es gibt ein paar Punkte, die Sie beachten sollten, wenn Sie
Kerberos oder SSH
einsetzen wollen. Kerberos 5 ist ein
ausgezeichnetes Authentifizierungsprotokoll. Leider gibt es
Fehler in den für Kerberos
angepassten Versionen von telnet und
rlogin, die sie ungeeignet für den
Umgang mit binären Datenströmen machen. Weiterhin
verschlüsselt Kerberos Ihre Sitzung
nicht, wenn Sie nicht die -x
Option verwenden,
mit SSH wird dagegen alles
verschlüsselt.
Ein Problem mit SSH sind Weiterleitungen von Verbindungen.
Wenn Sie von einer sicheren Maschine, auf der sich Ihre
Schlüssel befinden, eine Verbindung zu einer
ungesicherten Maschine aufmachen, wird für die Dauer der
Sitzung ein Port für Weiterleitungen geöffnet.
Ein Angreifer, der auf der unsicheren Maschine Zugang zu
root
hat, kann diesen Port
benutzen, um Zugriff auf andere Maschinen zu
erlangen, die mit Ihren Schlüsseln zugänglich
sind.
Wir empfehlen Ihnen, für die Logins Ihrer Mitarbeiter immer
SSH zusammen mit
Kerberos einzusetzen. Damit reduzieren
Sie die Abhängigkeit von potentiell gefährdeten
Schlüsseln und schützen gleichzeitig die Passwörter
mit Kerberos.
SSH-Schlüsselpaare sollten nur
für automatisierte Aufgaben von einem besonders gesicherten
Server eingesetzt werden (Kerberos
kann für diese Art von Aufgaben nicht eingesetzt werden).
Weiterhin empfehlen wir Ihnen, das Weiterreichen von Schlüsseln
in der SSH-Konfiguration abzustellen bzw.
die from=IP/DOMAIN
Option in
authorized_keys
zu verwenden, die den
Schlüssel nur von bestimmten Maschinen aus nutzbar macht.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.