From owner-svn-doc-head@freebsd.org Tue Mar 15 19:03:30 2016 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5300AD2F68; Tue, 15 Mar 2016 19:03:30 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 758DD1C3D; Tue, 15 Mar 2016 19:03:30 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u2FJ3TVD042185; Tue, 15 Mar 2016 19:03:29 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u2FJ3Tg6042184; Tue, 15 Mar 2016 19:03:29 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201603151903.u2FJ3Tg6042184@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Tue, 15 Mar 2016 19:03:29 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48419 - head/de_DE.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 19:03:30 -0000 Author: bhd Date: Tue Mar 15 19:03:29 2016 New Revision: 48419 URL: https://svnweb.freebsd.org/changeset/doc/48419 Log: Update to r42014 Reviewed by: bcr Differential Revision: https://reviews.freebsd.org/D5640 Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Tue Mar 15 17:37:39 2016 (r48418) +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Tue Mar 15 19:03:29 2016 (r48419) @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/security/chapter.xml,v 1.178 2012/04/30 17:07:41 bcr Exp $ - basiert auf: r41320 + basiert auf: r42014 --> Sicherheit @@ -25,22 +25,19 @@ Übersicht Dieses Kapitel bietet eine Einführung in die Konzepte - der Systemsicherheit. Neben einigen Daumenregeln werden - weiterführende Themen wie S/Key, OpenSSL und Kerberos - diskutiert. Die meisten der hier besprochenen Punkte treffen - sowohl auf die Systemsicherheit sowie die Internetsicherheit zu. - Das Internet hat aufgehört ein friedlicher - Ort zu sein, an dem Sie nur nette Leute finden werden. Es ist - unumgänglich, dass Sie Ihre Daten, Ihr geistiges Eigentum, - Ihre Zeit und vieles mehr vor dem Zugriff von Hackern - schützen. - - &os; besitzt eine Reihe von Werkzeugen und Mechanismen, um die - Integrität und die Sicherheit Ihrer Systeme und Netzwerke - zu gewährleisten. + 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. - Nachdem Sie dieses Kapitel durchgearbeitet haben, werden - Sie: + Nachdem Sie dieses Kapitel gelesen haben, werden Sie: @@ -50,8 +47,7 @@ Die verschiedenen Verschlüsselungsmechanismen - von &os;, wie DES oder - MD5, kennen. + von &os; kennen. @@ -60,36 +56,33 @@ - TCP-Wrapper für - inetd einrichten können. + TCP-Wrapper für &man.inetd.8; + einrichten können. - Wissen, wie Sie Kerberos5 + Wissen, wie Sie Kerberos unter &os; einrichten. - Firewalls mit IPFW - erstellen können. + Wissen, wie Sie IPsec konfigurieren und ein + VPN einrichten. - Wissen, wie Sie IPsec konfigurieren und ein - VPN zwischen &os;/&windows; - Systemen einrichten, + Wissen, wie Sie OpenSSH unter + &os; konfigurieren und benutzen. - OpenSSH, &os;s - Implementierung von SSH, konfigurieren - und benutzen können. + Wissen, wie Sie ACLs für Dateisysteme + benutzen. Portaudit anwenden können, - um Softwarepakete Dritter, die Sie über die - Ports-Sammlung installieren, auf bekannte + um Softwarepakete aus der Ports-Sammlung auf bekannte Sicherheitslücken hin zu überprüfen. @@ -99,8 +92,13 @@ Eine Vorstellung davon haben, was Prozessüberwachung - (Process Accounting) ist und wie - Sie diese Funktion unter &os; aktivieren können. + (Process Accounting) ist und + wie Sie diese Funktion unter &os; aktivieren können. + + + + Wissen, wie Sie die Ressourcen-Datenbank benutzt, um die + Ressourcen für Benutzer zu steuern. @@ -114,33 +112,26 @@ Dieses Buch behandelt weitere Sicherheitsthemen. - Beispielsweise werden vorgeschriebene Zugriffskontrollen - in und Firewalls in + Beispielsweise werden verbindliche Zugriffskontrollen + im und Firewalls im besprochen. Einführung - Sicherheit ist ein Konzept, das beim Systemadministrator anfängt - und aufhört. Obwohl alle BSD &unix; Mehrbenutzersysteme über - Sicherheitsfunktionen verfügen, ist es wohl eine der - größten Aufgaben eines Systemadministrators zusätzliche - Sicherheitsmechanismen zu erstellen und zu pflegen. Maschinen sind - nur so sicher wie sie gemacht werden und Sicherheitsanforderungen - stehen oft der Benutzerfreundlichkeit entgegen. Auf &unix; Systemen - können sehr viele Prozesse gleichzeitig laufen und viele dieser - Prozesse sind Server, das heißt von außen kann auf sie - zugegriffen werden. In einer Zeit, in der die Minicomputer und - Mainframes von gestern die Desktops von heute sind und Rechner - immer mehr vernetzt werden, kommt der Sicherheit eine große - Bedeutung zu. + 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: + root zu + kompromittieren. Sicherheitsaspekte lassen sich in mehrere + Kategorien unterteilen: @@ -152,8 +143,9 @@ - Kompromittierter root-Account durch - zugreifbare Server. + Kompromittierter root-Account durch + zugängliche Server. @@ -167,32 +159,30 @@ - DoS Angriffe + DoS-Angriffe Denial-of-Service (DoS) Sicherheit - DoS Angriffe + DoS-AAngriffe Denial-of-Service (DoS) Denial-of-Service (DoS) - Ein Denial-of-Service (Verhinderung von Diensten, DoS) Angriff + Ein Denial-of-Service DoS-Angriff entzieht einer Maschine Ressourcen, die sie zur Bereitstellung - von Diensten benötigt. Meist versuchen Denial-of-Service Angriffe - die Dienste oder den Netzwerkstack einer Maschine zu überlasten, - um so die Maschine auszuschalten oder nicht nutzbar zu machen. Einige - Angriffe versuchen, Fehler im Netzwerkstack auszunutzen, und die - Maschine mit einem einzigen Paket auszuschalten. Diese Art des - Angriffs kann nur verhindert werden, indem der entsprechende Fehler - im Kernel behoben wird. 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 Ihr System zwar nicht unbrauchbar machen, - kann aber die Internetverbindung sättigen. + 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 @@ -200,25 +190,20 @@ Kompromittierte Accounts kommen noch häufiger als - DoS Angriffe vor. Viele Systemadministratoren lassen auf ihren - Maschinen noch die Dienste telnetd, - rlogind, rshd - und ftpd laufen. Verbindungen zu diesen - Servern werden nicht verschlüsselt. Wenn Sie eine - größere Benutzerzahl auf Ihrem System haben, die sich von - einem entfernten System anmelden, ist die Folge davon, dass - das Passwort eines oder mehrerer Benutzer ausgespäht wurde. - Ein aufmerksamer Systemadministrator wird die Logs über Anmeldungen - von entfernten Systemen auf verdächtige Quelladressen, auch - für erfolgreiche Anmeldungen, untersuchen. - - Es ist immer davon auszugehen, dass ein Angreifer, der - Zugriff auf einen Account hat, Zugang zum - root-Account erlangt. 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 + 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 @@ -240,21 +225,7 @@ 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. - Viele der heute - bekannten und geschlossenen Sicherheitslöcher, die zu einem - root Zugriff führen, verlangen vom Angreifer - einen erheblichen Aufwand, um seine Spuren zu verwischen. Aus diesem - Grund wird er sich wahrscheinlich entschließen, eine Hintertür - (engl. Backdoor) zu installieren. - Eine Hintertür erlaubt es - dem Angreifer leicht auf den root-Account - zuzugreifen. Einem klugen Systemadministrator erlaubt sie allerdings - auch, den Einbruch zu entdecken. Wenn Sie es einem Angreifer verwehren, - Hintertüren zu installieren, kann das schädlich für - Ihre Sicherheit sein, da es vielleicht verhindert, dass die - Lücke, die der Angreifer für den Einbruch ausgenutzt hat, - entdeckt wird. + vielleicht keine Hintertür auf dem System installieren. Sicherheitsmaßnahmen sollten immer in mehreren Schichten angelegt werden. Die Schichten können wie folgt eingeteilt @@ -262,8 +233,8 @@ - Absichern von root und - Accounts. + Absichern von root-Accounts. @@ -272,7 +243,7 @@ - Absichern von Accounts. + Absichern von Benutzer-Accounts. @@ -306,91 +277,69 @@ &os; absichern - - Kommandos und Protokolle - 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 &os;-System zu sichern. + Dieser Abschnitt behandelt die im + letzten Abschnitt + erwähnten Methoden zur Absicherung eines &os;-Systems. Absichern von <systemitem class="username">root</systemitem> und Accounts - su + &man.su.1; - 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 &man.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. + 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 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 - &man.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. + 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 den Befehl + Um ein Konto komplett zu sperren, verwenden Sie &man.pw.8;: - &prompt.root;pw lock staff + &prompt.root;pw lock staff Danach ist es diesem Benutzer nicht mehr möglich (auch nicht mit &man.ssh.1;), sich anzumelden. @@ -404,32 +353,30 @@ foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - wie folgt abgeändert werden: + mit &man.vipw.8; wie folgt abgeändert werden: foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - 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 &man.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. + 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 @@ -443,8 +390,7 @@ 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. + bestimmten Zeit das Passwort wechseln muss. @@ -452,112 +398,39 @@ Servern und SUID/SGID Programmen - ntalk - - - comsat - - - finger - - Sandkästen - sshd - - - telnetd - - - rshd - - - rlogind - - - 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 &os; - ntalkd, comsat - und finger nun in einem Sandkasten. Ein - weiteres Programm, das in einem Sandkasten laufen sollte, ist - &man.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. - - sendmail + &man.sshd.8; - 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 + 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 + 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 @@ -571,29 +444,22 @@ - Absichern von Accounts + Absichern von Benutzer-Accounts 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. + 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 SSH oder + 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, @@ -601,88 +467,79 @@ 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). + Ü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 - 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 &os; 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. + 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. - sysctl + &man.sysctl.8; - Auch wenn Sie bpf nicht verwenden, + + 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. Weiterhin gibt es ein Programm zum Nachladen von - Modulen in den Kernel: &man.kldload.8;. Ein unternehmungslustiger - Angreifer kann dies benutzen, um sein eigenes + 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 - dieses Problem zu vermeiden, müssen Sie den Kernel auf - einem höheren Sicherheitslevel laufen lassen, mindestens + 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 ist das erhöhen des - Securelevel des laufenden Kernels durch ein - sysctl der kern.securelevel - Kernel Variablen: + 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 - Standardmässig bootet der &os; Kernel mit einem + 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 Startup Script verändert wird. Der + durch einen Eintrag im Startskript verändert wird. Der Securelevel kann während des Systemstarts durch das Setzen - der Variable kern_securelevel_enable auf + 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. - Der Standard Securelevel von einem &os;-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. Eine vollständige Liste - aller Securelevels finden Sie in &man.security.7;. + verbieten sogar noch weitere Aktionen. Eine vollständige + Beschreibung aller Securelevels finden Sie in &man.security.7; + und &man.init.8;. 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 &os; 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 &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, + 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 @@ -694,20 +551,15 @@ 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. - + 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. @@ -722,14 +574,12 @@ 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. + 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. @@ -890,14 +740,14 @@ Sendmail besitzt die Option , die besser als die eingebauten Optionen zur Begrenzung der Systemauslastung funktioniert. - Sie sollten beim Start von sendmail + 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 Dæmon (sendmail -bd) sollte + 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 @@ -931,7 +781,7 @@ named, wenn Sie den primären Namensdienst für eine Zone anbieten, ntalkd oder - sendmail erlauben. Wenn Sie die + 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 @@ -1172,6 +1022,7 @@ Einmalpasswörter + Einmalpasswörter Sicherheit @@ -1179,98 +1030,89 @@ In der Voreinstellung unterstützt &os; - OPIE (One-time Passwords in - Everything), das in der Regel MD5-Hash-Funktionen - einsetzt. - - Im Folgenden werden drei verschiedene - Passwörter verwendet. Das erste ist Ihr normales System- oder - Kerberos-Passwort und wird im Folgenden System-Passwort - genannt. Das zweite ist das Einmalpasswort, das bei OPIE von - opiekey generiert und von - opiepasswd und dem Login-Programm akzeptiert wird. - Im Folgenden wird es Einmalpasswort genannt. Das dritte - Passwort ist das geheime Passwort, das Sie mit + One-time Passwords in Everything + (OPIE), das in der Voreinstellung + MD5-Hash-Funktionen einsetzt. + + Es gibt drei verschiedene Arten von Passwörtern. Das erste + ist das normales &unix;- oder Kerberos-Passwort. Das zweite ist + das Einmalpasswort, das von opiekey generiert + und von opiepasswd und dem Anmeldeprompt + akzeptiert wird. Das dritte Passwort ist das + geheime Passwort, das mit opiekey (manchmal auch mit - opiepasswd) zum Erstellen - der Einmalpasswörter verwenden. Dieses Passwort - werden wir im Folgenden geheimes Passwort - oder schlicht Passwort nennen. + opiepasswd) zum Erstellen der + Einmalpasswörter verwendet wird. - Das geheime Passwort steht in keiner Beziehung zu Ihrem - System-Passwort, beide können gleich sein, obwohl das nicht + Das geheime Passwort steht in keiner Beziehung zum + &unix;-Passwort. Beide können gleich sein, obwohl das nicht empfohlen wird. Die geheimen Passwörter von - OPIE sind nicht auf eine Länge von 8 Zeichen, + OPIE sind nicht auf eine Länge von 8 Zeichen, wie alte &unix; Passwörter Unter &os; darf das System-Passwort maximal - 128 Zeichen lang sein., beschränkt. - Sie können so lang sein, wie Sie wollen. Gebräuchlich sind - Passwörter, die sich aus sechs bis sieben Wörtern - zusammensetzen. Das OPIE-System arbeitet - größtenteils unabhängig von den - auf &unix;-Systemen verwendeten Passwort-Mechanismen. + 128 Zeichen lang sein., beschränkt. + Gebräuchlich sind Passwörter, die sich aus sechs bis sieben + Wörtern zusammensetzen. Das OPIE-System + arbeitet vollständig unabhängig von den auf &unix;-Systemen + verwendeten Passwort-Mechanismen. Neben dem Passwort gibt es noch zwei Werte, die für - OPIE wichtig sind. Der erste ist der - Initialwert (engl. seed - oder key), der aus zwei Buchstaben - und fünf Ziffern besteht. Der zweite Wert ist der - Iterationszähler, eine Zahl zwischen - 1 und 100. OPIE generiert das Einmalpasswort, indem + OPIE wichtig sind. Der erste ist der + Initialwert (engl. + seed oder + key), der aus zwei Buchstaben und + fünf Ziffern besteht. Der zweite Wert ist der + Iterationszähler, eine Zahl zwischen 1 und 100. + OPIE generiert das Einmalpasswort, indem es den Initialwert und das geheime Passwort aneinander hängt und dann die MD5-Hash-Funktion so oft, wie durch den Iterationszähler gegeben, anwendet. Das Ergebnis wird in - sechs englische Wörter umgewandelt, die Ihr Einmalpasswort - sind. Das Authentifizierungssystem (meistens PAM) merkt sich das - zuletzt benutzte Einmalpasswort und Sie sind authentisiert, - wenn die Hash-Funktion des Passworts dem vorigen Passwort - entspricht. Da nicht umkehrbare Hash-Funktionen benutzt werden, - ist es unmöglich, aus einem bekannten Passwort weitere - gültige Einmalpasswörter zu berechnen. Der - Iterationszähler wird nach jeder erfolgreichen Anmeldung um - eins verringert und stellt so die Synchronisation zwischen Benutzer - und Login-Programm sicher. Wenn der Iterationszähler den - Wert 1 erreicht, muss OPIE neu initialisiert werden. - - In jedem System werden mehrere Programme verwendet, die weiter - unten beschrieben werden. opiekey verlangt - einen Iterationszähler, einen Initialwert und ein geheimes - Passwort. Daraus generiert es ein Einmalpasswort oder eine Liste - von Einmalpasswörtern. opiepasswd wird - dazu benutzt, um OPIE zu initialisieren. Mit diesem Programm - können Passwörter, Iterationszähler oder - Initialwerte geändert werden. Als Parameter verlangt es + sechs englische Wörter umgewandelt, die das Einmalpasswort + ergeben. Das Authentifizierungssystem (meistens PAM) merkt sich + das zuletzt benutzte Einmalpasswort und der Benutzer ist + authentifiziert, wenn die Hash-Funktion des Passworts dem + vorigen Passwort entspricht. Da nicht umkehrbare + Hash-Funktionen benutzt werden, ist es unmöglich, aus einem + bekannten Passwort weitere gültige Einmalpasswörter zu + berechnen. Der Iterationszähler wird nach jeder erfolgreichen + Anmeldung um eins verringert und stellt so die Synchronisation *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***