14.3. Absichern von FreeBSD

Dieser Abschnitt behandelt die im letzten Abschnitt erwähnten Methoden zur Absicherung eines FreeBSD-Systems.

14.3.1. Absichern von root und Accounts

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 die PTYs in ttys als insecure markiert sind und damit Anmeldungen von root verboten sind. In FreeBSD ist die Anmeldung für root über ssh(1) in der Voreinstellung deaktiviert, da in /etc/ssh/sshd_config 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 muss ein 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 dieser Gruppe können mit su zu root wechseln. Nur die Mitarbeiter, die tatsächlich root-Zugriff benötigen, sollten in die Gruppe wheel aufgenommen werden. Wenn Sie Kerberos für die Authentifizierung benutzen, erstellen Sie .k5login im Heimatverzeichnis von root, damit su(1) verwendet werden kann, ohne jemanden in wheel aufnehmen zu müssen.

Um ein Konto komplett zu sperren, verwenden Sie 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

foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

mit vipw(8) wie folgt abgeändert werden:

foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh

Diese Änderung hindert den Benutzer foobar daran, 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 sich Benutzer von einer restriktiven Maschine auf einer weniger restriktiven Maschine anmelden. Wenn zum Beispiel auf dem Hauptrechner alle möglichen Arten von Servern laufen, so sollten auf der Workstation keine Server laufen. Um die Workstation vernünftig abzusichern, sollten darauf 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. Beachten Sie, 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 das Passwort wechseln muss.

14.3.2. Absichern von unter root laufenden Servern und SUID/SGID Programmen

Ein kluger Systemadministrator lässt nur die wirklich benötigten Dienste laufen und ist sich darüber im Klaren, dass Server von Dritten oft die fehleranfälligsten sind. Lassen Sie keine Server laufen, die Sie vorher nicht genau überprüft haben. Denken Sie zweimal darüber nach, bevor Sie einen Dienst als root laufen lassen. Viele Daemonen können unter einem separaten Dienstkonto, oder in einem Sandkasten ausgeführt werden. Aktivieren Sie keine unsicheren Dienste, wie telnetd(8) oder rlogind(8).

Ein weiteres potentielles Risiko sind SUID- und SGID-Programme. Die meisten dieser Programme, wie rlogin(1) stehen in /bin, /sbin, /usr/bin, oder /usr/sbin zur Verfügung. Obwohl nichts 100% sicher ist, können Sie davon ausgehen, dass die SUID- und SGID-Programme des Basissystems ausreichend sicher sind. Es wird empfohlen, den Zugriff auf SUID-Programme mit einer Gruppe, auf die nur Mitarbeiter zugreifen können, zu beschränken. SUID-Programme, die niemand benutzt, sollten gelöscht werden. 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.

14.3.3. Absichern von Benutzer-Accounts

Accounts sind für gewöhnlich sehr schwierig abzusichern. Seien Sie daher aufmerksam bei der Überwachung der Benutzerkonten. Die Verwendung von ssh(1) und Kerberos erfordert zwar zusätzliche Administration und technische Unterstützung, ist aber verglichen mit der verschlüsselten Passwort-Datei die bessere Lösung.

14.3.4. Absichern der Passwort-Datei

Der einzig sichere Weg ist, so viele Accounts wie möglich als ungültig zu markieren und ssh(1) 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.

Überwachungsskripten sollten Änderungen an der Passwort-Datei melden. Dies wird in Überprüfen der Integrität von Dateien beschrieben.

14.3.5. Absichern des Kernels, der Geräte und von Dateisystemen

Die meisten modernen Kernel haben einen Gerätetreiber, der es erlaubt, Pakete abzuhören. Unter FreeBSD wird das Gerät bpf genannt. Dieses Gerät ist für DHCP erforderlich, kann aber in der Kernelkonfigurationsdatei entfernt werden, wenn das System kein DHCP anbietet.

Auch wenn bpf deaktiviert ist, 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. Ein Angreifer könnte kldload(8) benutzen, um sein eigenes bpf oder ein anderes zum Abhören geeignetes Gerät in den laufenden Kernel einzubringen. Um diese Probleme zu vermeiden, lassen Sie den Kernel auf einem höheren Sicherheitslevel laufen, mindestens auf securelevel 1.

Das Securelevel des Kernels kann auf verschiedene Wege gesetzt werden. Der einfachste Weg, den Securelevel des laufenden Kernels zu erhöhen, ist das Setzen von kern.securelevel:

# sysctl kern.securelevel=1

In der Voreinstellung 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 Startskript verändert wird. Der Securelevel kann während des Systemstarts durch das Setzen von 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.

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 sogar noch weitere Aktionen. Eine vollständige Beschreibung aller Securelevels finden Sie in security(7) und init(8).

Anmerkung:

Das Erhöhen des Securelevels auf 1 oder höher kann einige Probleme mit Xorg, verursachen, da der Zugriff auf /dev/io geblockt wird, ebenso die Installation von FreeBSD aus den Quellen, da der installworld Teil zeitweilig die append-only und die unveränderlichen Flags einiger Dateien zurücksetzen muss. Manchmal kann es, wie bei Xorg, 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 Skripte zu setzen. Ein weniger strenger 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, 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.

14.3.6. Überprüfen der Integrität von Dateien

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. Sicherheitsmaßnahmen sind nutzlos, oder schlimmer noch, vermitteln ein falsches Gefühl von Sicherheit, wenn der potentielle Angreifer nicht entdeckt wird. Die Aufgabe besteht nicht darin, den Angreifer aufzuhalten, sondern seine Angriffe zu verzögern, um ihn dann 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.

14.3.7. Paranoia

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.

14.3.8. Denial-of-Service Angriffe

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:

  1. Begrenzen von fork() Aufrufen.

  2. Begrenzen von Sprungbrett-Angriffen (ICMP response Angriffen, ping zu Broadcast-Adressen usw.).

  3. 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 Daemon (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:

  1. Der Kernel reagiert nicht schnell genug, wenn ein Server mit einer niedrigen Grundlast plötzlich angegriffen wird.

  2. 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.

14.3.9. Anmerkungen zum Zugriff mit Kerberos und SSH

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>.