Index: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml @@ -5,13 +5,18 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/security/chapter.xml,v 1.178 2012/04/30 17:07:41 bcr Exp $ - basiert auf: r43278 + basiert auf: r43764 --> Sicherheit - MatthewDillonViel von diesem Kapitel stammt aus der security(7) - Manualpage von + + + Tom + Rhodes + + Neu verfasst von + MartinHeinenÜbersetzt von @@ -24,18 +29,19 @@ Übersicht - Dieses Kapitel bietet eine Einführung in die Konzepte - der Systemsicherheit. Des weiteren werden einige allgemeine - Daumenregeln und einige fortgeschrittene Themen unter &os; - behandelt. Viele der hier besprochenen Punkte treffen sowohl - auf die Systemsicherheit als auch auf die Internetsicherheit zu. - Die Absicherung eines Systems ist unumgänglich, um Daten, - geistiges Eigentum, Zeit und vieles mehr vor Hackern und - dergleichen zu schützen. - - &os; besitzt eine Reihe von Werkzeugen und Mechanismen, um - die Integrität und die Sicherheit des Systems und des Netzwerks - zu schützen. + Sicherheit, ob nun physisch oder virtuell, ist ein so breit + gefächertes Thema, dass sich eine ganze Industrie darum gebildet + hat. Es wurden bereits hunderte Verfahren zur Sicherung von + Systemen und Netzwerken verfasst, und als Benutzer von &os; ist + es unumgänglich zu verstehen, wie Sie sich gegen Angreifer und + Eindringlinge schützen können. + + + In diesem Kapitel werden einige Grundlagen und Techniken + diskutiert. Ein &os;-System implementiert Sicherheit in + mehreren Schichten, und viele weitere Programme von + Drittanbietern können zur Verbesserung der Sicherheit + beitragen. Nachdem Sie dieses Kapitel gelesen haben, werden Sie: @@ -120,903 +126,598 @@ Einführung - Sicherheit ist ein Konzept, das beim Systemadministrator - anfängt und aufhört. Obwohl &os; über Sicherheitsfunktionen - verfügt, ist die Erstellung und Pflege von zusätzlichen - Sicherheitsmechanismen wohl eine der größten Aufgaben eines - Systemadministrators. - - Zur Systemsicherheit gehört auch die Beschäftigung mit - verschiedenen Arten von Angriffen, auch solchen, die versuchen, - ein System still zu legen, oder sonst unbrauchbar zu machen ohne - root zu - kompromittieren. Sicherheitsaspekte lassen sich in mehrere - Kategorien unterteilen: - - - - Denial-of-Service Angriffe. - - - - Kompromittierte Accounts. - - - - Kompromittierter root-Account durch - zugängliche Server. - - - - Kompromittierter root-Account durch - kompromittierte Accounts. - - - - Einrichten von Hintertüren. - - - - - DoS-Angriffe - Denial-of-Service (DoS) - - - Sicherheit - DoS-AAngriffe - Denial-of-Service (DoS) - - Denial-of-Service (DoS) - - Ein Denial-of-Service DoS-Angriff - entzieht einer Maschine Ressourcen, die sie zur Bereitstellung - von Diensten benötigt. Meist versuchen - DoS-Angriffe die Dienste oder den - Netzwerkstack einer Maschine zu überlasten, um so die Maschine - auszuschalten oder nicht nutzbar zu machen. Oft können - Angriffe auf Dienste durch die Angabe von Optionen verhindert - werden, die die Last, die ein Dienst auf das System unter - widrigen Umständen ausüben kann, begrenzt. Angriffen auf das - Netzwerk ist schwerer zu begegnen. Außer durch Trennen der - Internetverbindung ist zum Beispiel einem Angriff mit - gefälschten Paketen nicht zu begegnen. Diese Art von Angriff - wird das System zwar nicht unbrauchbar machen, kann aber die - Internetverbindung sättigen. - - - Sicherheit - kompromittierte Accounts - - - Kompromittierte Accounts kommen noch häufiger als - DoS-Angriffe vor. Viele - Systemadministratoren lassen immer noch unverschlüsselte Dienste - laufen, was zur Folge hat, dass das Passwort von Benutzern, die - sich von einem entfernten Standort anmelden, leicht ausgespäht - werden kann. Ein aufmerksamer Systemadministrator wird die - Logdateien über Anmeldungen von entfernten Systemen auf - verdächtige Quelladressen, auch für erfolgreiche Anmeldungen, - untersuchen. - - Allerdings gibt der Zugriff auf einen Account auf einem gut - gesicherten und gepflegten System nicht notwendig Zugriff auf - den root-Account. - Diese Unterscheidung ist wichtig, da ein Angreifer, der keinen - Zugang zu root - besitzt, seine Spuren nicht verwischen kann. Er kann höchstens - die Dateien des betreffenden Benutzers verändern oder die - Maschine stilllegen. Kompromittierte Accounts sind sehr - häufig, da Benutzer meist nicht dieselben Vorsichtsmaßnahmen - wie Administratoren treffen. - - - Sicherheit - Hintertüren - - - Es gibt viele Wege, Zugang zum root-Account - eines Systems zu bekommen: Ein Angreifer kann das Passwort von - root kennen, er kann einen Fehler in einem - Server entdecken, der unter root läuft und - dann über eine Netzwerkverbindung zu diesem Server einbrechen. - Oder er kennt einen - Fehler in einem SUID-root Programm, der es - ihm erlaubt, root zu werden, wenn er einmal - einen Account kompromittiert hat. Wenn ein Angreifer einen - Weg gefunden hat, root zu werden, braucht er - vielleicht keine Hintertür auf dem System installieren. - - Sicherheitsmaßnahmen sollten immer in mehreren Schichten - angelegt werden. Die Schichten können wie folgt eingeteilt - werden: - - - - Absichern von root-Accounts. - - - - Absichern von unter root laufenden - Servern und SUID/SGID Programmen. - - - - Absichern von Benutzer-Accounts. - - - - Absichern der Passwort-Datei. - - - - Absichern des Kernels, der Geräte und von - Dateisystemen. - - - - Schnelles Aufdecken von unbefugten Veränderungen des - Systems. - - - - Paranoia. - - - - Die einzelnen Punkte der obigen Liste werden im nächsten - Abschnitt genauer behandelt. - - - - Absichern von &os; - - - Sicherheit - &os; absichern - + Sicherheit ist die Verantwortung eines jeden Einzelnen. Ein + schwacher Einstiegspunkt in einem System kann einem + Eindringling Zugriff auf wichtige Informationen verschaffen, was + sich verheerend auf das gesamte Netzwerk auswirken kann. Eines + der Grundprinzipien der Informationssicherheit sind die + Vertraulichkeit, Integrität und Verfügbarkeit von + Informationssystemen. + + Diese Grundprinzipien sind ein fundamentales Konzept der + Computer-Sicherheit, da Kunden und Benutzer erwarten, dass ihre + Daten geschützt sind. Zum Beispiel erwartet ein Kunde, dass + seine Kreditkarteninformationen sicher gespeichert werden + (Vertraulichkeit), dass seine Aufträge nicht hinter den Kulissen + geändert werden (Integrität) und dass er zu jeder Zeit Zugang zu + seinen Informationen hat (Verfügbarkeit). + + Um diese Grundprinzipien zu implementieren, wenden + Sicherheitsexperten das sogenannte + Defense-in-Depth-Konzept an. Die + Idee dahinter ist, mehrere Sicherheitsschichten zu addieren, so + dass nicht die gesamte Systemsicherheit gefährdet ist, wenn + eine einzelne Sicherheitsschicht kompromittiert wird. + Beispielsweise ist es nicht ausreichend, ein Netzwerk oder ein + System nur mit einer Firewall zu sichern. Der + Systemadministrator muss auch Benutzerkonten überwachen, die + Integrität von Binärdateien prüfen und sicherstellen, dass keine + bösartigen Programme installiert sind. Um eine effektive + Sicherheitsstrategie zu implementieren, muss man Bedrohungen + verstehen und wissen, wie man sich dagegen verteidigen + kann. + + Was ist eine Bedrohung, wenn es um Computer-Sicherheit geht? + Bedrohungen beschränken sich nicht nur auf entfernte Angreifer, + die sich unerlaubten Zugriff auf ein System verschaffen wollen. + Zu den Bedrohungen zählen auch Mitarbeiter, bösartige Software, + nicht autorisierte Netzwerkgeräte, Naturkatastrophen, + Sicherheitslücken und sogar konkurrierende Unternehmen. + + Der Zugriff auf Netzwerke und Systeme erfolgt ohne + Erlaubnis, manchmal durch Zufall, oder von entfernten + Angreifern, und in einigen Fällen durch Industriespionage oder + ehemalige Mitarbeiter. Als Anwender müssen Sie vorbereitet sein + und auch zugeben, wenn ein Fehler zu einer Sicherheitsverletzung + geführt hat. Melden Sie Probleme umgehend dem verantwortlichen + Sicherheitspersonal. Als Administrator ist es wichtig, + Bedrohungen zu kennen und darauf vorbereitet zu sein, mögliche + Schäden zu mildern. + + Wenn Sicherheit auf Systeme angewendet wird, empfiehlt es + sich mit der Sicherung der Benutzerkonten zu beginnen und dann + die Netzwerkschicht zu sichern. Dabei ist zu beachten, dass die + Sicherheitsrichtlinien des Systems und des Unternehmens + eingehalten werden. Viele Unternehmen haben bereits eine + Sicherheitsrichtlinie, welche die Konfiguration von technischen + Geräten abdeckt. Die Richtlinie sollte die Konfiguration von + Arbeitsplatzrechnern, Desktops, mobilen Geräten, Mobiltelefonen, + Produktions- und Entwicklungsservern umfassen. In einigen + Fällen ist bereits eine Standardvorgehensweise vorhanden. + Fragen Sie im Zweifelsfall das Sicherheitspersonal. + + Der übrige Teil dieser Einführung beschreibt, wie einige + dieser grundlegenden Sicherheitskonfigurationen auf einem + &os;-System durchgeführt werden. Der Rest dieses Kapitels + beschreibt einige spezifische Werkzeuge, die verwendet werden + können, um eine Sicherheitsrichtlinie auf einem &os;-System zu + implementieren. + + + Anmeldungen am System verhindern + + Ein guter Ausgangspunkt für die Absicherung des Systems + ist die Prüfung der Benutzerkonten. Stellen Sie sicher, dass + root ein starkes + Passwort besitzt und dass dieses Passwort nicht weitergegeben + wird. Deaktivieren Sie alle Konten, die keinen Zugang zum + System benötigen. + + Es existieren zwei Methoden, um die Anmeldung über ein + Benutzerkonto zu verweigern. Die erste Methode ist, das + Konto zu sperren. Dieses Beispiel sperrt das Benutzerkonto + toor: + + &prompt.root; pw lock toor + + Bei der zweiten Methode wird der Anmeldevorgang + verhindert, indem die Shell auf + /sbin/nologin gesetzt wird. Nur der + Superuser kann die Shell für andere Benutzer ändern: + + &prompt.root; chsh -s /usr/sbin/nologin toor + + Die Shell /usr/sbin/nologin + verhindert, dass dem Benutzer bei der Anmeldung am System eine + Shell zugeordnet wird. + + + + Gemeinsame Nutzung von Benutzerkonten + + In manchen Fällen wird die Systemadministration auf + mehrere Benutzer aufgeteilt. &os; bietet zwei Methoden, um + solche Situationen zu handhaben. Bei der ersten und nicht + empfohlenen Methode wird ein gemeinsames root Passwort der + Mitglieder der Gruppe wheel verwendet. Hier gibt + der Benutzer su und das Passwort für + wheel ein, wenn er + die Rechte des Superusers benötigt. Der Benutzer sollte dann + nach der Beendigung der administrativen Aufgaben + exit eingeben. Um einen Benutzer zu dieser + Gruppe hinzuzufügen, bearbeiten Sie + /etc/group und fügen Sie den Benutzer an + das Ende des Eintrags wheel hinzu. Die + Benutzer müssen durch Komma und ohne Leerzeichen getrennt + werden. - Dieser Abschnitt behandelt die im - letzten Abschnitt - erwähnten Methoden zur Absicherung eines &os;-Systems. - - - Absichern von <systemitem class="username">root</systemitem> und - Accounts - - - &man.su.1; - - - 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 &man.su.1;, verwenden sollten. Stellen Sie sicher, dass - die PTYs in ttys als - insecure markiert sind und damit - Anmeldungen von root - verboten sind. In &os; ist die Anmeldung für root über &man.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. - - - wheel - - - 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 &man.su.1; - verwendet werden kann, ohne jemanden in wheel aufnehmen zu - müssen. - - Um ein Konto komplett zu sperren, verwenden Sie - &man.pw.8;: - - &prompt.root;pw lock staff - - Danach ist es diesem Benutzer nicht mehr möglich (auch - nicht mit &man.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 &man.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 - &man.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. - - - - Absichern von unter <systemitem class="username">root</systemitem> laufenden - Servern und SUID/SGID Programmen - - - Sandkästen - - - &man.sshd.8; - - - 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 &man.telnetd.8; - oder &man.rlogind.8;. - - Ein weiteres potentielles Risiko sind SUID- und - SGID-Programme. Die meisten dieser Programme, wie - &man.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. - - - - 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 &man.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. - - - - Absichern der Passwort-Datei - - Der einzig sichere Weg ist, so viele Accounts wie möglich - als ungültig zu markieren und &man.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. - - - - Absichern des Kernels, der Geräte und von - Dateisystemen - - Die meisten modernen Kernel haben einen Gerätetreiber, - der es erlaubt, Pakete abzuhören. Unter &os; 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. - - - &man.sysctl.8; - - - 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 &man.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: - - &prompt.root; sysctl kern.securelevel=1 - - In der Voreinstellung bootet der &os; Kernel mit einem - Securelevel von -1. Der Securelevel wird solange bei -1 bleiben, - bis er entweder durch den Administrator oder von &man.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 &man.security.7; - und &man.init.8;. + Die zweite und empfohlene Methode ein Benutzerkonto zu + teilen wird über den Port oder das Paket + security/sudo realisiert. Dieses Programm + bietet zusätzliche Prüfungen, bessere Benutzerkontrolle und + es kann auch konfiguriert werden, einzelnen Benutzern Zugriff + auf bestimme, privilegierte Befehle zu gestatten. + + Benutzen Sie nach der Installation + visudo, um + /usr/local/etc/sudoers zu bearbeiten. + Dieses Beispiel erstellt eine neue Gruppe webadmin und fügt das + Benutzerkonto trhodes dieser Gruppe hinzu. + Anschließend wird die Gruppe so konfiguriert, dass es + Gruppenmitgliedern gestattet wird apache24 + neu zu starten: + + &prompt.root; pw groupadd webadmin -M trhodes -g 6000 +&prompt.root; visudo +%webadmin ALL=(ALL) /usr/sbin/service apache24 * + + + + Passwort-Hashes + + Passwörter sind ein notwendiges Übel. Wenn sie verwendet + werden müssen, sollten sie sehr komplex sein und dazu sollte + eine leistungsfähige Hash-Funktion gewählt werden, um die + Version des Passworts zu verschlüsseln, die in der + Passwortdatenbank gespeichert wird. &os; unterstützt die + Hash-Funktionen DES, MD5, + SHA256, SHA512, sowie + Blowfish Hash-Funktionen in seiner + crypt()-Bibliothek. Das in der + Voreinstellung verwendete SHA512 sollte + nicht durch eine weniger sichere Hash-Funktion getauscht + werden. Es kann jedoch durch den besseren Blowfish-Algorithmus + ersetzt werden. - 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 &os; 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 &man.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. + Blowfish ist nicht Bestandteil von + AES und ist nicht kompatibel mit allen + Federal Information Processing Standards + (FIPS). Die Verwendung wird in einigen + Umgebungen vielleicht nicht gestattet. - 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. - - - - Ü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 - &man.find.1; und &man.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. - &man.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 &man.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. - - - - 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. - - - - Denial-of-Service Angriffe - Denial-of-Service (DoS) - - 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.). - + Um zu bestimmen, welche Hash-Funktion das Passwort eines + Benutzers verschlüsselt, kann der Superuser den Hash für den + Benutzer in der Passwortdatenbank von &os; nachsehen. Jeder + Hash beginnt mit einem Zeichen, mit dem die verwendete + Hash-Funktion identifiziert werden kann. Bei + DES gibt es allerdings kein führendes + Zeichen. MD5 benutzt das Zeichen + $. SHA256 und + SHA512 verwenden das Zeichen + $6$. Blowfish benutzt das Zeichen + $2a$. In diesem Beispiel wird das Passwort + von dru mit dem + Hash-Algorithmus SHA512 verschlüsselt, da + der Hash mit $6$ beginnt. Beachten Sie, + dass der verschlüsselte Hash und nicht das Passwort selbst, in + der Passwortdatenbank gespeichert wird: + + &prompt.root; grep dru /etc/master.passwd +dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh + + Der Hash-Mechanismus wird in der Login-Klasse des + Benutzers festgelegt. In diesem Beispiel wird die + voreingestellte Login-Klasse für den Benutzer verwendet. Der + Hash-Algorithmus wird mit dieser Zeile in + /etc/login.conf gesetzt: + + :passwd_format=sha512:\ + + Um den Algorithmus auf Blowfish zu ändern, passen Sie die + Zeile wie folgt an: + + :passwd_format=blf:\ + + Führen Sie anschließend cap_mkdb + /etc/login.conf aus, wie in beschrieben. Beachten Sie, dass + vorhandene Passwort-Hashes durch diese Änderung nicht + beeinträchtigt werden. Das bedeutet, dass alle Passwörter neu + gehasht werden sollten, indem die Benutzer mit + passwd ihr Passwort ändern. + + Für die Anmeldung auf entfernten Rechnern sollte eine + Zwei-Faktor-Authentifizierung verwendet werden. Ein Beispiel + für eine Zwei-Faktor-Authentifizierung ist + etwas, was Sie besitzen (bspw. einen Schlüssel) + und etwas, was Sie wissen (bspw. das Passwort + für diesen Schlüssel). Da OpenSSH + Teil des &os;-Basissystems ist, sollten alle Anmeldungen über + das Netzwerk über eine verschlüsselte Verbindung mit einer + schlüsselbasierten Authentifizierung stattfinden. Passwörter + sollten hier nicht verwendet werden. Weitere Informationen + finden Sie in . Kerberos-Benutzer + müssen eventuell zusätzliche Änderungen vornehmen, um + OpenSSH in Ihrem Netzwerk zu + implementieren. Diese Änderungen sind in beschrieben. + + + + Durchsetzung einer Passwort-Richtlinie + + Die Durchsetzung einer starken Passwort-Richtlinie für + lokale Benutzerkonten ist ein wesentlicher Aspekt der + Systemsicherheit. In &os; kann die Länge, Stärke und + Komplexität des Passworts mit den + Pluggable Authentication Modules + (PAM) implementiert werden. + + In diesem Abschnitt wird gezeigt, wie Sie die minimale und + maximale Passwortlänge und die Durchsetzung von gemischten + Zeichen mit dem Modul pam_passwdqc.so + konfigurieren. Dieses Modul wird aufgerufen, wenn ein + Benutzer sein Passwort ändert. + + Um dieses Modul zu konfigurieren, müssen Sie als Superuser + die Zeile mit pam_passwdqc.so in + /etc/pam.d/passwd auskommentieren. + Anschließend bearbeiten Sie die Zeile, so dass sie den + vorliegenden Passwort-Richtlinien entspricht: + + password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users + + Dieses Beispiel legt gleich mehrere Anforderungen für neue + Passwörter fest. Die Einstellung min + kontrolliert die Passwortlänge. Es verfügt über fünf Werte, + weil dieses Modul fünf verschiedene Arten von Passwörtern + definiert, basierend auf der Komplexität. Die Komplexität + wird durch die Art von Zeichen definiert, die in einem + Passwort vorhanden sind, wie zum Beispiel Buchstaben, Zahlen + und Sonderzeichen. Die verschiedenen Arten von Passwörtern + werden in &man.pam.passwdqc.8; beschrieben. In diesem + Beispiel sind die ersten drei Arten von Passwörtern + deaktiviert, was bedeutet, dass Passwörter, die dieser + Komplexitätsstufe entsprechen, nicht akzeptiert werden, + unabhängig von der Länge des Passworts. Die + 12 legt eine Richtlinie von mindestens + zwölf Zeichen fest, wenn das Passwort auch drei Arten von + Komplexität aufweist. Die 10 legt eine + Richtlinie fest, die auch Passwörter mit mindestens zehn + Zeichen zulassen, wenn das Passwort Zeichen mit vier Arten + von Komplexität aufweist. + + Die Einstellung similar verbietet + Passwörter, die dem vorherigen Passwort des Benutzers ähnlich + sind. Die Einstellung retry bietet dem + Benutzer drei Möglichkeiten, ein neues Passwort + einzugeben. + + Sobald diese Datei gespeichert wird, sehen Benutzer bei + der Änderung ihres Passworts die folgende Meldung: + + &prompt.user; passwd +Changing local password for trhodes +Old Password: + +You can now choose the new password. +A valid password should be a mix of upper and lower case letters, +digits and other characters. You can use a 12 character long +password with characters from at least 3 of these 4 classes, or +a 10 character long password containing characters from all the +classes. Characters that form a common pattern are discarded by +the check. +Alternatively, if noone else can see your terminal now, you can +pick this as your password: "trait-useful&knob". +Enter new password: + + Wenn ein Passwort nicht den Richtlinien entspricht, wird + es mit einer Warnung abgelehnt und der Benutzer bekommt die + Möglichkeit, es erneut zu versuchen, bis die Anzahl an + Wiederholungen erreicht ist. + + Die meisten Passwort-Richtlinien erzwingen, dass + Passwörter nach einer bestimmten Anzahl von Tagen ablaufen. + Um dieses Limit in &os; zu konfigurieren, setzen Sie es für + die Login-Klasse des Benutzers in + /etc/login.conf. Die voreingestellte + Login-Klasse enthält dazu ein Beispiel: + + # :passwordtime=90d:\ + + Um für diese Login-Klasse das Passwort nach 90 Tagen + ablaufen zu lassen, entfernen Sie das Kommentarzeichen + (#), speichern Sie die Änderungen und + führen Sie cap_mkdb /etc/login.conf + aus. - - Kernel-Cache für Routen. - - + Um das Passwort für einzelne Benutzer ablaufen zu lassen, + geben Sie pw ein Ablaufdatum oder die + Anzahl von Tagen, zusammen mit dem Benutzer an: + + &prompt.root; pw usermod -p 30-apr-2015 -n trhodes + + Wie zu sehen ist, wird das Ablaufdatum in der Form von + Tag, Monat und Jahr angegeben. Weitere Informationen finden + Sie in &man.pw.8;. + + + + Erkennen von Rootkits + + Ein Rootkit ist eine nicht + autorisierte Software die versucht, Root-Zugriff auf ein + System zu erlangen. Einmal installiert, wird diese bösartige + Software normalerweise eine Hintertür für den Angreifer + installieren. Realistisch betrachtet sollte ein durch ein + Rootkit kompromittiertes System nach der Untersuchung von + Grund auf neu installiert werden. Es besteht jedoch die + enorme Gefahr, dass sogar das Sicherheitspersonal oder + Systemingenieure etwas übersehen, was ein Angreifer dort + platziert hat. + + Wird ein Rootkit erkannt, ist dies bereits ein Zeichen + dafür, dass das System an einem bestimmten Zeitpunkt + kompromittiert wurde. Meist neigen diese Art von Anwendungen + dazu, sehr gut versteckt zu sein. Dieser Abschnitt zeigt ein + Werkzeug, mit dem Rootkits erkannt werden können: + security/rkhunter. + + Nach der Installation dieses Ports oder Pakets kann das + System mit dem folgenden Kommando überprüft werden. Das + Programm generiert eine ganze Menge Informationen und Sie + werden diverse Male ENTER drücken + müssen: + + &prompt.root; rkhunter -c + + Nachdem der Prozess abgeschlossen ist, wird eine + Statusmeldung auf dem Bildschirm ausgegeben. Die Meldung + enthält die Anzahl der überprüften Dateien, verdächtige + Dateien, mögliche Rootkits und weitere Informationen. Während + der Überprüfung erscheinen allgemeine Sicherheitswarnungen, + zum Beispiel über versteckte Dateien, die Auswahl von + OpenSSH-Protokollen und bekannte, + anfällige Versionen installierter Anwendungen. Diese können + nun direkt, oder nach detaillierter Analyse untersucht + werden. - 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. - &man.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 , und - . Angriffe mit gefälschten IP-Adressen - umgehen , 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 - , 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 () 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 , 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 - zu benutzen. Sollte das nicht möglich - sein, benutzen Sie bitte . - - 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 - &os; 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: + Jeder Administrator sollte wissen, was auf den Systemen + läuft, für die er verantwortlich ist. Werkzeuge von + Drittanbietern, wie rkhunter oder + sysutils/lsof, sowie native Befehle wie + netstat oder + ps, können eine große Menge an + Informationen über das System anzeigen. Machen Sie sich + Notizen darüber, was normal ist, und fragen Sie + nach, wenn Ihnen etwas suspekt erscheint. Eine + Beeinträchtigung zu verhindern ist ideal, aber die Erkennung + einer Beeinträchtigung ist ein Muss. + + + + Überprüfung von Binärdateien + + Die Überprüfung von System- und Binärdateien ist wichtig, + da sie Systemadministratoren Informationen über + Systemänderungen zur Verfügung stellt. Eine Software, die das + System auf Änderungen überwacht wird Intrustion + Detection System (IDS) + genannt. + + &os; bietet native Unterstützung für ein einfaches + IDS-System. Obwohl die täglichen + Sicherheits-E-Mails den Administrator über Änderungen in + Kenntnis setzen, werden diese Informationen lokal gespeichert + und es besteht die Möglichkeit, dass ein Angreifer diese + Informationen manipulieren kann, um Änderungen am System zu + verbergen. Daher ist es empfehlenswert, einen eigenen Satz an + Signaturen zu erstellen und diese dann in einem + schreibgeschützten Verzeichnis, oder vorzugsweise auf einem + USB-Stick oder auf einem entfernten Server + zu speichern. + + Das im Basissystem enthaltene Werkzeug + mtree kann verwendet werden, um + eine Spezifikation des Inhalts eines Verzeichnisses zu + erzeugen. Hierbei wird ein Startwert + (Seed) oder eine numerische + Konstante benutzt, um die Spezifikation zu erstellen und um + sicherzustellen, dass sich die Spezifikation nicht geändert + hat. Dadurch kann festgestellt werden, ob eine Datei oder + eine Binärdatei verändert wurde. Da ein Angreifer den + Seed nicht kennt, ist es ihm fast unmöglich die + Prüfsummen von Dateien zu manipulieren. Das folgende Beispiel + generiert einen Satz mit SHA256-Prüfsummen + für jede Binärdatei unterhalb von /bin + und speichert diese Werte in einer versteckten Datei im + Heimatverzeichnis von root unter dem Namen + /root/.bin_chksum_mtree: - - - Der Kernel reagiert nicht schnell genug, wenn ein - Server mit einer niedrigen Grundlast plötzlich angegriffen - wird. - + &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree +&prompt.root; mtree: /bin checksum: 3427012225 - - rtminexpire ist nicht klein genug, - um einen anhaltenden Angriff zu überstehen. - - + 3483151339707503 stellt den + Seed dar. Diesen Wert sollten Sie sich merken, aber + nicht mit anderen Personen teilen. + + Die Ausgabe von + /root/.bin_chksum_mtree sollte ähnlich + der folgenden sein: + + # user: root +# machine: dreadnaught +# tree: /bin +# date: Mon Feb 3 10:19:53 2014 + +# . +/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none +. type=dir mode=0755 nlink=2 size=1024 \ + time=1380277977.000000000 + \133 nlink=2 size=1170 time=1380277977.000000000 \ + cksum=484492447 \ + sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a + cat size=12096 time=1380277975.000000000 cksum=3909216944 \ + sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 + chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ + sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 + chio size=18520 time=1380277975.000000000 cksum=2208263309 \ + sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 + chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ + sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 + + Der Report enthält den Rechnernamen, das Datum und die + Uhrzeit der Spezifikation, sowie den Namen des Benutzers, der + die Spezifikation erstellt hat. Für jede Binärdatei im + Verzeichnis gibt es eine Prüfsumme, Größe, Uhrzeit und einen + SHA256-Hashwert. + + Um sicherzustellen, dass die binären Signaturen nicht + verändert wurden, vergleichen Sie den Inhalt des aktuellen + Verzeichnisses mit der zuvor erstellen Spezifikation. + Speichern Sie die Ergebnisse in einer Datei. Dieses Kommando + benötigt den Seed, der verwendet wurde um die + ursprüngliche Spezifikation zu erstellen: + + &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output +&prompt.root; mtree: /bin checksum: 3427012225 + + Dies sollte die gleiche Prüfsumme für + /bin produzieren, wie die ursprüngliche + Spezifikation. Wenn keine Änderungen an den Binärdateien in + diesem Verzeichnis aufgetreten sind, wird die Ausgabedatei + /root/.bin_chksum_output leer sein. Um + eine Änderung zu simulieren, ändern Sie mit + touch das Datum von + /bin/cat und führen Sie die Verifikation + erneut aus: + + &prompt.root; touch /bin/cat +&prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output +&prompt.root; more /root/.bin_chksum_output +cat changed + modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 + + Es wird empfohlen, Spezifikationen für Verzeichnisse zu + erstellen, welche Binärdateien, Konfigurationsdateien und + sensible Daten enthalten. In der Regel werden Spezifikationen + für /bin, /sbin, + /usr/bin, /usr/sbin, + /usr/local/bin, + /usr/local/sbin, + /etc und + /usr/local/etc erstellt. + + Mit security/aide steht ein + fortgeschrittenes IDS-System zur Verfügung, + aber in den meisten Fällen bietet mtree die + Funktionalität, die von Administratoren benötigt wird. Es ist + jedoch sehr wichtig den Seed und die Prüfsummen in der + Ausgabe vor böswilligen Benutzern verborgen zu halten. + Weitere Informationen zu mtree finden Sie + in &man.mtree.8;. + + + + System-Tuning für Sicherheit + + Unter &os; können viele Systemfunktionen mit + sysctl konfiguriert werden. Dieser + Abschnitt behandelt ein paar Sicherheitsmerkmale mit denen + Denial of Service + (DoS) verhindert werden sollen. Weitere + Informationen über die Benutzung von + sysctl und wie Werte vorübergehend oder + auch permanent geändert werden können, finden Sie in . - Wenn Ihre Server über eine T3 oder eine noch schnellere - Leitung mit dem Internet verbunden sind, ist es klug, mit - &man.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. - + + Jedes Mal wenn eine Einstellung mit + sysctl geändert wird, vergrößert sich die + Wahrscheinlichkeit eines unerwünschten Schadens, was die + Verfügbarkeit des Systems beeinflusst. Alle Änderungen + sollten überwacht und wenn möglich, vorher auf einem + Testsystem ausprobiert werden, bevor sie auf einem + Produktivsystem verwendet werden. + - - Anmerkungen zum Zugriff mit Kerberos und SSH - 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 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. - - + In der Voreinstellung startet &os; in der Sicherheitsstufe + (Securelevel) + -1. Dieser Modus wird + unsicherer Modus genannt, da die + unveränderlichen Datei-Flags ausgeschaltet werden können und + dadurch von allen Geräten gelesen und geschrieben werden kann. + Solange die Einstellung nicht über sysctl + oder in den Startskripten geändert wird, verbleibt die + Sicherheitsstufe auf -1. Die + Sicherheitsstufe kann während des Systemstarts erhöht werden. + Dazu muss in /etc/rc.conf + kern_securelevel_enable auf + YES und kern_securelevel + auf den gewünschten Wert gesetzt werden. Weitere + Informationen zu diesen Einstellungen und den verfügbaren + Sicherheitsstufen finden Sie in &man.security.7; und + &man.init.8;. - - DES, Blowfish, MD5, SHA256, SHA512 und Crypt - - BillSwingleTeile umgeschrieben und aktualisiert von - - - + + Das Erhöhen der Sicherheitsstufe kann zu Problemen mit + &xorg; führen. + - - - Sicherheit - Crypt - + Die Einstellungen + net.inet.tcp.blackhole und + net.inet.udp.blackhole können benutzt + werden, um eingehende SYN-Pakete an + geschlossenen Ports zu blockieren, ohne ein + RST-Paket als Antwort zu senden. + Standardmäßig wird jedoch ein RST-Paket + gesendet, um zu zeigen, dass der Port geschlossen ist. Das + ändern dieser Voreinstellung bietet einen gewissen Schutz + gegen Portscans. Diese Portscans versuchen herauszufinden, + welche Anwendungen auf einem System ausgeführt werden. Setzen + Sie net.inet.tcp.blackhole auf + 2 und + net.inet.udp.blackhole auf + 1. Weitere Informationen zu diesen + Einstellungen finden Sie in &man.blackhole.4;. + + Die Einstellung + net.inet.icmp.drop_redirect hilft dabei, + sogenannte Redirect-Angriffe zu verhindern. Ein + Redirect-Angriff ist eine Art von DoS, die + massenhaft ICMP-Pakete Typ 5 versendet. Da + solche Pakete nicht benötigt werden, setzen Sie + net.inet.icmp.drop_redirect auf + 1 und + net.inet.ip.redirect auf + 0. + + Source Routing zur + Erfassung und zum Zugriff auf nicht-routbare Adressen im + internen Netzwerk. Dies sollte deaktiviert werden, da + nicht-routbare Adressen in der Regel nicht absichtlich + geroutet werden. Um diese Funktion zu deaktivieren, setzen + Sie net.inet.ip.sourceroute und + net.inet.accept_sourceroute auf + 0. + + Wenn ein Netzwerkgerät Nachrichten an alle Rechner in + einem Subnetz senden muss, wird eine + ICMP-Echo-Request Nachricht an die + Broadcast-Adresse gesendet. Allerdings gibt es keinen guten + Grund für externe Rechner, solche Nachrichten zu verschicken. + Um alle externen Broadcast-Anfragen abzulehnen, setzen Sie + net.inet.icmp.bmcastecho auf + 0. - Crypt - Blowfish - DES - MD5 - SHA256 - SHA512 - - Jedem Benutzer eines &unix; Systems ist ein Passwort zugeordnet. - Es scheint offensichtlich, dass das Passwort nur dem Benutzer - und dem System bekannt sein muss. Um die Passwörter - geheim zu halten, werden sie mit einer nicht umkehrbaren Hash-Funktion - verschlüsselt, das heißt sie können leicht - verschlüsselt aber nicht entschlüsselt werden. Was wir - gerade als offensichtlich dargestellt haben, ist also nicht wahr: Das - Betriebssystem kennt das Passwort wirklich - nicht, es kennt nur das verschlüsselte - Passwort. Die einzige Möglichkeit, das originale Passwort - herauszufinden, besteht darin, alle möglichen Passwörter - auszuprobieren (brute force Suche). - - Zu der Zeit als &unix; entstanden ist, war die einzig sichere - Möglichkeit Passwörter zu verschlüsseln, leider - DES (Data Encryption Standard). Für die Einwohner der USA - stellte das kein Problem dar, aber da der Quellcode von DES nicht aus - den USA exportiert werden durfte, musste ein Weg gefunden werden, - der die Gesetze der USA nicht verletzte und gleichzeitig die - Kompatibilität mit anderen &unix; Systemen, die immer noch DES - benutzten, wahrte. - - Die Lösung bestand darin, die Verschlüsselungsbibliotheken - aufzuspalten. Benutzer in den USA konnten die DES-Bibliotheken - installieren und nutzen. In der Grundeinstellung benutzt &os; - MD5 als Verschlüsselungsmethode, das exportiert werden durfte - und damit von jedem genutzt werden konnte. Es wird davon ausgegangen, - dass MD5 sicherer als DES ist, so dass DES nur aus - Kompatibilitätsgründen installiert werden sollte. - - - Erkennen der Verschlüsselungsmethode - - Die derzeit unterstützten Hash-Funktionen sind DES, MD5, - Blowfish, SHA256 und SHA512. In der - Voreinstellung benutzten &os; 9.1 und neuere Versionen - SHA512 zur Verschlüsselung von Passwörtern. Ältere Versionen - benutzen standardmäßig MD5. - - Sie können leicht herausfinden, welche - Verschlüsselungsmethode von &os; verwendet wird. Ein Weg - besteht darin, die verschlüsselten Passwörter in - /etc/master.passwd zu untersuchen. - Passwörter, die mit MD5 verschlüsselt wurden, - sind länger als die mit DES verschlüsselten und - beginnen mit den Zeichen $1$. - Passwörter, die mit $2a$ - anfangen, wurden mit der Blowfish-Funktion verschlüsselt. - DES Passwörter besitzen keine offensichtlichen Merkmale, - an denen sie identifiziert werden könnten. Sie sind aber - kürzer als MD5-Passwörter und sind in einem - 64 Zeichen umfassenden Alphabet kodiert, das das - $-Zeichen nicht enthält. Ein relativ - kurzes Passwort, das nicht mit einem - $-Zeichen anfängt, ist wahrscheinlich - ein DES-Passwort. SHA256 und SHA512 beginnen mit dem Zeichen - $6$. - - Die Verschlüsselungsmethode für neue - Passwörter wird durch passwd_format in - /etc/login.conf bestimmt. Der Wert - dieser Variablen kann entweder des, - md5, blf, - sha256 oder sha512 sein. - Näheres schlagen Sie bitte in &man.login.conf.5; nach. + Einige zusätzliche Einstellungen sind in &man.security.7; + dokumentiert.