Date: Mon, 2 May 2016 18:04:06 +0000 (UTC) From: Bjoern Heidotting <bhd@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48773 - head/de_DE.ISO8859-1/books/handbook/security Message-ID: <201605021804.u42I46sG087001@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bhd Date: Mon May 2 18:04:06 2016 New Revision: 48773 URL: https://svnweb.freebsd.org/changeset/doc/48773 Log: Update to r43764: Rewrite the front of the security section. This version adds a small discussion on using sudo, shows and example of using an IDS rather than just discussing what they are, update of threats, discussion on rootkits and back doors, adds more sysctls and more. Add a section on password policy and password policy enforcement (with pam, pw, login.conf). Reviewed by: bcr Differential Revision: https://reviews.freebsd.org/D6175 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 Mon May 2 18:00:31 2016 (r48772) +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Mon May 2 18:04:06 2016 (r48773) @@ -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 --> <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security"> <info><title>Sicherheit</title> <authorgroup> - <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>Viel von diesem Kapitel stammt aus der security(7) - Manualpage von </contrib></author> + <author> + <personname> + <firstname>Tom</firstname> + <surname>Rhodes</surname> + </personname> + <contrib>Neu verfasst von </contrib> + </author> </authorgroup> <authorgroup> <author><personname><firstname>Martin</firstname><surname>Heinen</surname></personname><contrib>Übersetzt von </contrib></author> @@ -24,18 +29,19 @@ <sect1 xml:id="security-synopsis"> <title>Übersicht</title> - <para>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.</para> - - <para>&os; besitzt eine Reihe von Werkzeugen und Mechanismen, um - die Integrität und die Sicherheit des Systems und des Netzwerks - zu schützen.</para> + <para>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.</para> + + + <para>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.</para> <para>Nachdem Sie dieses Kapitel gelesen haben, werden Sie:</para> @@ -120,903 +126,598 @@ <sect1 xml:id="security-intro"> <title>Einführung</title> - <para>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.</para> - - <para>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 - <systemitem class="username">root</systemitem> zu - kompromittieren. Sicherheitsaspekte lassen sich in mehrere - Kategorien unterteilen:</para> - - <orderedlist> - <listitem> - <para>Denial-of-Service Angriffe.</para> - </listitem> - - <listitem> - <para>Kompromittierte Accounts.</para> - </listitem> - - <listitem> - <para>Kompromittierter <systemitem - class="username">root</systemitem>-Account durch - zugängliche Server.</para> - </listitem> - - <listitem> - <para>Kompromittierter <systemitem class="username">root</systemitem>-Account durch - kompromittierte Accounts.</para> - </listitem> - - <listitem> - <para>Einrichten von Hintertüren.</para> - </listitem> - </orderedlist> - - <indexterm> - <primary>DoS-Angriffe</primary> - <see>Denial-of-Service (DoS)</see> - </indexterm> - <indexterm> - <primary>Sicherheit</primary> - <secondary>DoS-AAngriffe</secondary> - <see>Denial-of-Service (DoS)</see> - </indexterm> - <indexterm><primary>Denial-of-Service (DoS)</primary></indexterm> - - <para>Ein Denial-of-Service <acronym>DoS</acronym>-Angriff - entzieht einer Maschine Ressourcen, die sie zur Bereitstellung - von Diensten benötigt. Meist versuchen - <acronym>DoS</acronym>-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.</para> - - <indexterm> - <primary>Sicherheit</primary> - <secondary>kompromittierte Accounts</secondary> - </indexterm> - - <para>Kompromittierte Accounts kommen noch häufiger als - <acronym>DoS</acronym>-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.</para> - - <para>Allerdings gibt der Zugriff auf einen Account auf einem gut - gesicherten und gepflegten System nicht notwendig Zugriff auf - den <systemitem class="username">root</systemitem>-Account. - Diese Unterscheidung ist wichtig, da ein Angreifer, der keinen - Zugang zu <systemitem class="username">root</systemitem> - 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.</para> - - <indexterm> - <primary>Sicherheit</primary> - <secondary>Hintertüren</secondary> - </indexterm> - - <para>Es gibt viele Wege, Zugang zum <systemitem class="username">root</systemitem>-Account - eines Systems zu bekommen: Ein Angreifer kann das Passwort von - <systemitem class="username">root</systemitem> kennen, er kann einen Fehler in einem - Server entdecken, der unter <systemitem class="username">root</systemitem> läuft und - dann über eine Netzwerkverbindung zu diesem Server einbrechen. - Oder er kennt einen - Fehler in einem SUID-<systemitem class="username">root</systemitem> Programm, der es - ihm erlaubt, <systemitem class="username">root</systemitem> zu werden, wenn er einmal - einen Account kompromittiert hat. Wenn ein Angreifer einen - Weg gefunden hat, <systemitem class="username">root</systemitem> zu werden, braucht er - vielleicht keine Hintertür auf dem System installieren.</para> - - <para>Sicherheitsmaßnahmen sollten immer in mehreren Schichten - angelegt werden. Die Schichten können wie folgt eingeteilt - werden:</para> - - <orderedlist> - <listitem> - <para>Absichern von <systemitem - class="username">root</systemitem>-Accounts.</para> - </listitem> - - <listitem> - <para>Absichern von unter <systemitem class="username">root</systemitem> laufenden - Servern und SUID/SGID Programmen.</para> - </listitem> - - <listitem> - <para>Absichern von Benutzer-Accounts.</para> - </listitem> - - <listitem> - <para>Absichern der Passwort-Datei.</para> - </listitem> - - <listitem> - <para>Absichern des Kernels, der Geräte und von - Dateisystemen.</para> - </listitem> - - <listitem> - <para>Schnelles Aufdecken von unbefugten Veränderungen des - Systems.</para> - </listitem> - - <listitem> - <para>Paranoia.</para> - </listitem> - </orderedlist> - - <para>Die einzelnen Punkte der obigen Liste werden im nächsten - Abschnitt genauer behandelt.</para> - </sect1> - - <sect1 xml:id="securing-freebsd"> - <title>Absichern von &os;</title> - - <indexterm> - <primary>Sicherheit</primary> - <secondary>&os; absichern</secondary> - </indexterm> + <para>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.</para> + + <para>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).</para> + + <para>Um diese Grundprinzipien zu implementieren, wenden + Sicherheitsexperten das sogenannte + <foreignphrase>Defense-in-Depth</foreignphrase>-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.</para> + + <para>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.</para> + + <para>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.</para> + + <para>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.</para> + + <para>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.</para> + + <sect2 xml:id="security-accounts"> + <title>Anmeldungen am System verhindern</title> + + <para>Ein guter Ausgangspunkt für die Absicherung des Systems + ist die Prüfung der Benutzerkonten. Stellen Sie sicher, dass + <systemitem class="username">root</systemitem> ein starkes + Passwort besitzt und dass dieses Passwort nicht weitergegeben + wird. Deaktivieren Sie alle Konten, die keinen Zugang zum + System benötigen.</para> + + <para>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 + <systemitem class="username">toor</systemitem>:</para> + + <screen>&prompt.root; <userinput>pw lock <replaceable>toor</replaceable></userinput></screen> + + <para>Bei der zweiten Methode wird der Anmeldevorgang + verhindert, indem die Shell auf + <filename>/sbin/nologin</filename> gesetzt wird. Nur der + Superuser kann die Shell für andere Benutzer ändern:</para> + + <screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin <replaceable>toor</replaceable></userinput></screen> + + <para>Die Shell <filename>/usr/sbin/nologin</filename> + verhindert, dass dem Benutzer bei der Anmeldung am System eine + Shell zugeordnet wird.</para> + </sect2> + + <sect2 xml:id="security-accountmgmt"> + <title>Gemeinsame Nutzung von Benutzerkonten</title> + + <para>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 <systemitem + class="groupname">wheel</systemitem> verwendet. Hier gibt + der Benutzer <command>su</command> und das Passwort für + <systemitem class="groupname">wheel</systemitem> ein, wenn er + die Rechte des Superusers benötigt. Der Benutzer sollte dann + nach der Beendigung der administrativen Aufgaben + <command>exit</command> eingeben. Um einen Benutzer zu dieser + Gruppe hinzuzufügen, bearbeiten Sie + <filename>/etc/group</filename> und fügen Sie den Benutzer an + das Ende des Eintrags <literal>wheel</literal> hinzu. Die + Benutzer müssen durch Komma und ohne Leerzeichen getrennt + werden.</para> - <para>Dieser Abschnitt behandelt die im - <link linkend="security-intro">letzten Abschnitt</link> - erwähnten Methoden zur Absicherung eines &os;-Systems.</para> - - <sect2 xml:id="securing-root-and-staff"> - <title>Absichern von <systemitem class="username">root</systemitem> und - Accounts</title> - - <indexterm> - <primary>&man.su.1;</primary> - </indexterm> - - <para>Auf den meisten Systemen ist <systemitem - class="username">root</systemitem> ein Passwort zugewiesen. - Sie sollten <emphasis>immer</emphasis> 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 <filename>ttys</filename> als - <literal>insecure</literal> markiert sind und damit - Anmeldungen von <systemitem class="username">root</systemitem> - verboten sind. In &os; ist die Anmeldung für <systemitem - class="username">root</systemitem> über &man.ssh.1; in der - Voreinstellung deaktiviert, da in - <filename>/etc/ssh/sshd_config</filename> - <literal>PermitRootLogin</literal> auf <literal>no</literal> - gesetzt ist. Beachten Sie jede Zugriffsmethode – - Dienste wie FTP werden oft vergessen. Nur an der - Systemkonsole sollte ein direktes Anmelden als <systemitem - class="username">root</systemitem> möglich sein.</para> - - <indexterm> - <primary><systemitem class="groupname">wheel</systemitem></primary> - </indexterm> - - <para>Natürlich muss ein Systemadministrator - <systemitem class="username">root</systemitem>-Zugriff - erlangen können. Dieser sollte aber durch zusätzliche - Passwörter geschützt sein. Ein Weg, Zugang zu <systemitem - class="username">root</systemitem> zu ermöglichen, ist es, - berechtigte Mitarbeiter in <filename>/etc/group</filename> in - die Gruppe <systemitem class="groupname">wheel</systemitem> - aufzunehmen. Die Personen dieser Gruppe können mit - <command>su</command> zu <systemitem - class="username">root</systemitem> wechseln. Nur die - Mitarbeiter, die tatsächlich <systemitem - class="username">root</systemitem>-Zugriff benötigen, - sollten in die Gruppe <systemitem - class="groupname">wheel</systemitem> aufgenommen werden. - Wenn Sie Kerberos für die Authentifizierung benutzen, - erstellen Sie <filename>.k5login</filename> im - Heimatverzeichnis von <systemitem - class="username">root</systemitem>, damit &man.su.1; - verwendet werden kann, ohne jemanden in <systemitem - class="groupname">wheel</systemitem> aufnehmen zu - müssen.</para> - - <para>Um ein Konto komplett zu sperren, verwenden Sie - &man.pw.8;:</para> - - <screen>&prompt.root;<userinput>pw lock <replaceable>staff</replaceable></userinput></screen> - - <para>Danach ist es diesem Benutzer nicht mehr möglich (auch - nicht mit &man.ssh.1;), sich anzumelden.</para> - - <para>Eine weitere Möglichkeit, bestimmte Benutzer zu sperren, - ist es, das verschlüsselte Passwort durch das Zeichen - <quote><literal>*</literal></quote> 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</para> - - <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> - - <para>mit &man.vipw.8; wie folgt abgeändert werden:</para> - - <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> - - <para>Diese Änderung hindert den Benutzer <systemitem - class="username">foobar</systemitem> daran, sich auf - konventionellem Wege am System anzumelden. Diese Maßnahmen - greifen allerdings nicht, wenn das betroffene System auch - eine Anmeldung über <application>Kerberos</application> oder - &man.ssh.1; erlaubt.</para> - - <para>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.</para> - - <para>Mit <application>Kerberos</application> 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 <application>Kerberos</application> 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.</para> - </sect2> - - <sect2> - <title>Absichern von unter <systemitem class="username">root</systemitem> laufenden - Servern und SUID/SGID Programmen</title> - - <indexterm> - <primary>Sandkästen</primary> - </indexterm> - <indexterm> - <primary>&man.sshd.8;</primary> - </indexterm> - - <para>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 <systemitem class="username">root</systemitem> - 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;.</para> - - <para>Ein weiteres potentielles Risiko sind SUID- und - SGID-Programme. Die meisten dieser Programme, wie - &man.rlogin.1; stehen in <filename>/bin</filename>, - <filename>/sbin</filename>, <filename>/usr/bin</filename>, - oder <filename>/usr/sbin</filename> 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-<systemitem class="groupname">kmem</systemitem> Programm - erhält, kann er vielleicht <filename>/dev/kmem</filename> 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 <systemitem class="groupname">kmem</systemitem> 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 - <systemitem class="groupname">tty</systemitem> 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.</para> - </sect2> - - <sect2 xml:id="secure-users"> - <title>Absichern von Benutzer-Accounts</title> - - <para>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 - <application>Kerberos</application> erfordert zwar zusätzliche - Administration und technische Unterstützung, ist aber - verglichen mit der verschlüsselten Passwort-Datei die bessere - Lösung.</para> - </sect2> - - <sect2> - <title>Absichern der Passwort-Datei</title> - - <para>Der einzig sichere Weg ist, so viele Accounts wie möglich - als ungültig zu markieren und &man.ssh.1; oder - <application>Kerberos</application> zu benutzen, um auf sie - zuzugreifen. Obwohl die Datei <filename>/etc/spwd.db</filename>, - die die verschlüsselten Passwörter enthält, - nur von <systemitem class="username">root</systemitem> gelesen werden kann, mag ein - Angreifer lesenden Zugriff auf diese Datei erlangen, ohne die - Fähigkeit sie auch zu beschreiben.</para> - - <para>Überwachungsskripten sollten Änderungen - an der Passwort-Datei melden. Dies wird in <link - linkend="security-integrity">Überprüfen der Integrität von - Dateien</link> beschrieben.</para> - </sect2> - - <sect2> - <title>Absichern des Kernels, der Geräte und von - Dateisystemen</title> - - <para>Die meisten modernen Kernel haben einen Gerätetreiber, - der es erlaubt, Pakete abzuhören. Unter &os; wird das Gerät - <filename>bpf</filename> genannt. Dieses Gerät ist für - <acronym>DHCP</acronym> erforderlich, kann aber in der - Kernelkonfigurationsdatei entfernt werden, wenn das System - kein <acronym>DHCP</acronym> anbietet.</para> - - <indexterm> - <primary>&man.sysctl.8;</primary> - </indexterm> - - <para>Auch wenn <filename>bpf</filename> deaktiviert ist, - müssen Sie sich immer noch um <filename>/dev/mem</filename> - und <filename>/dev/kmem</filename> sorgen. Außerdem - kann der Angreifer immer noch auf die rohen Geräte - (<foreignphrase>raw devices</foreignphrase>) - schreiben. Ein Angreifer könnte &man.kldload.8; benutzen, um - sein eigenes - <filename>bpf</filename> 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.</para> - - <para>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 - <varname>kern.securelevel</varname>:</para> - - <screen>&prompt.root; <userinput>sysctl kern.securelevel=1</userinput></screen> - - <para>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 <varname>kern_securelevel_enable</varname> auf - <literal>YES</literal> und der Wert der Variable - <varname>kern_securelevel</varname> auf den gewünschten - Securelevel in der <filename>/etc/rc.conf</filename> - erhöht werden.</para> - - <para>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;.</para> + <para>Die zweite und empfohlene Methode ein Benutzerkonto zu + teilen wird über den Port oder das Paket + <package>security/sudo</package> 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.</para> + + <para>Benutzen Sie nach der Installation + <command>visudo</command>, um + <filename>/usr/local/etc/sudoers</filename> zu bearbeiten. + Dieses Beispiel erstellt eine neue Gruppe <systemitem + class="groupname">webadmin</systemitem> und fügt das + Benutzerkonto <systemitem + class="username">trhodes</systemitem> dieser Gruppe hinzu. + Anschließend wird die Gruppe so konfiguriert, dass es + Gruppenmitgliedern gestattet wird <package>apache24</package> + neu zu starten:</para> + + <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput> +&prompt.root; <userinput>visudo</userinput> +%webadmin ALL=(ALL) /usr/sbin/service apache24 *</screen> + </sect2> + + <sect2 xml:id="security-passwords"> + <title>Passwort-Hashes</title> + + <para>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 <acronym>DES</acronym>, <acronym>MD5</acronym>, + <acronym>SHA256</acronym>, <acronym>SHA512</acronym>, sowie + Blowfish Hash-Funktionen in seiner + <function>crypt()</function>-Bibliothek. Das in der + Voreinstellung verwendete <acronym>SHA512</acronym> sollte + nicht durch eine weniger sichere Hash-Funktion getauscht + werden. Es kann jedoch durch den besseren Blowfish-Algorithmus + ersetzt werden.</para> <note> - <para>Das Erhöhen des Securelevels auf 1 oder höher - kann einige Probleme mit <application>&xorg;</application>, - verursachen, da der Zugriff auf <filename>/dev/io</filename> - geblockt wird, ebenso die Installation von &os; aus den - Quellen, da der <buildtarget>installworld</buildtarget> - Teil zeitweilig die append-only und die unveränderlichen - Flags einiger Dateien zurücksetzen muss. Manchmal kann es, - wie bei <application>&xorg;</application>, 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.</para> + <para>Blowfish ist nicht Bestandteil von + <acronym>AES</acronym> und ist nicht kompatibel mit allen + Federal Information Processing Standards + (<acronym>FIPS</acronym>). Die Verwendung wird in einigen + Umgebungen vielleicht nicht gestattet.</para> </note> - <para>Wenn das Securelevel des Kernel auf einen Wert von 1 oder - höher gesetzt ist, kann es sinnvoll sein das - <literal>schg</literal> 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 <literal>schg</literal> Flags für - alle Systemdateien und Verzeichnisse zu setzen. Eine andere - Möglichkeit ist es, die Verzeichnisse <filename>/</filename> - und <filename>/usr</filename> read-only zu mounten. Es sei - darauf hingewiesen, dass Sie nicht vor lauter Überlegen das - Wichtigste, nämlich die Entdeckung eines Eindringens, - vergessen.</para> - </sect2> - - <sect2 xml:id="security-integrity"> - <title>Überprüfen der Integrität von Dateien</title> - - <para>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 <command>chflags</command> die Option <literal>schg</literal> - auf die meisten Dateien in <filename>/</filename> und - <filename>/usr</filename> 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.</para> - - <para>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 - <application>SSH</application> auf die anderen Maschinen erlauben, - indem Sie <application>SSH</application>-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 <application>SSH</application> - besser geeignet, auch wenn es deutliche Spuren - hinterlässt.</para> - - <para>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 <filename>/etc</filename> und - <filename>/usr/local/etc</filename> - 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 - <filename>/</filename> und - <filename>/usr</filename>.</para> - - <para>Wenn Sie <application>SSH</application> anstelle von NFS - benutzen, wird das Erstellen der Skripten schwieriger. Sie müssen - die Skripten und die Programme wie <command>find</command> mit - <command>scp</command> 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 <application>SSH</application> nötig sein, - wenn Sie über ungesicherte Verbindungen arbeiten, aber - der Umgang mit dieser Methode ist auch sehr viel schwieriger.</para> - - <para>Ein gutes Sicherheitsskript wird auch Dateien von Benutzern, - die den Zugriff auf ein System ermöglichen, wie - <filename>.rhosts</filename>, <filename>.shosts</filename>, - <filename>.ssh/authorized_keys</filename> usw., auf - Veränderungen untersuchen, die über die Möglichkeiten - einer Überprüfung mit <literal>MD5</literal> - (die ja nur Veränderungen erkennen kann) hinausgehen.</para> - - <para>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 <literal>nosuid</literal> - 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.</para> - - <para>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.</para> - - <para>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 <command>syslog</command>. 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.</para> - </sect2> - - <sect2> - <title>Paranoia</title> - - <para>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.</para> - </sect2> - - <sect2> - <title>Denial-of-Service Angriffe</title> - <indexterm><primary>Denial-of-Service (DoS)</primary></indexterm> - - <para>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:</para> - - <orderedlist> - <listitem> - <para>Begrenzen von <function>fork()</function> Aufrufen.</para> - </listitem> - - <listitem> - <para>Begrenzen von Sprungbrett-Angriffen (ICMP response Angriffen, - <application>ping</application> zu Broadcast-Adressen usw.).</para> - </listitem> + <para>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 + <acronym>DES</acronym> gibt es allerdings kein führendes + Zeichen. <acronym>MD5</acronym> benutzt das Zeichen + <literal>$</literal>. <acronym>SHA256</acronym> und + <acronym>SHA512</acronym> verwenden das Zeichen + <literal>$6$</literal>. Blowfish benutzt das Zeichen + <literal>$2a$</literal>. In diesem Beispiel wird das Passwort + von <systemitem class="username">dru</systemitem> mit dem + Hash-Algorithmus <acronym>SHA512</acronym> verschlüsselt, da + der Hash mit <literal>$6$</literal> beginnt. Beachten Sie, + dass der verschlüsselte Hash und nicht das Passwort selbst, in + der Passwortdatenbank gespeichert wird:</para> + + <screen>&prompt.root; <userinput>grep dru /etc/master.passwd</userinput> +dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh</screen> + + <para>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 + <filename>/etc/login.conf</filename> gesetzt:</para> + + <programlisting> :passwd_format=sha512:\</programlisting> + + <para>Um den Algorithmus auf Blowfish zu ändern, passen Sie die + Zeile wie folgt an:</para> + + <programlisting> :passwd_format=blf:\</programlisting> + + <para>Führen Sie anschließend <command>cap_mkdb + /etc/login.conf</command> aus, wie in <xref + linkend="users-limiting"/> 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 + <command>passwd</command> ihr Passwort ändern.</para> + + <para>Für die Anmeldung auf entfernten Rechnern sollte eine + Zwei-Faktor-Authentifizierung verwendet werden. Ein Beispiel + für eine Zwei-Faktor-Authentifizierung ist + <quote>etwas, was Sie besitzen</quote> (bspw. einen Schlüssel) + und <quote>etwas, was Sie wissen</quote> (bspw. das Passwort + für diesen Schlüssel). Da <application>OpenSSH</application> + 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 <xref linkend="openssh"/>. Kerberos-Benutzer + müssen eventuell zusätzliche Änderungen vornehmen, um + <application>OpenSSH</application> in Ihrem Netzwerk zu + implementieren. Diese Änderungen sind in <xref + linkend="kerberos5"/> beschrieben.</para> + </sect2> + + <sect2 xml:id="security-pwpolicy"> + <title>Durchsetzung einer Passwort-Richtlinie</title> + + <para>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 + <foreignphrase>Pluggable Authentication Modules</foreignphrase> + (<acronym>PAM</acronym>) implementiert werden.</para> + + <para>In diesem Abschnitt wird gezeigt, wie Sie die minimale und + maximale Passwortlänge und die Durchsetzung von gemischten + Zeichen mit dem Modul <filename>pam_passwdqc.so</filename> + konfigurieren. Dieses Modul wird aufgerufen, wenn ein + Benutzer sein Passwort ändert.</para> + + <para>Um dieses Modul zu konfigurieren, müssen Sie als Superuser + die Zeile mit <literal>pam_passwdqc.so</literal> in + <filename>/etc/pam.d/passwd</filename> auskommentieren. + Anschließend bearbeiten Sie die Zeile, so dass sie den + vorliegenden Passwort-Richtlinien entspricht:</para> + + <programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting> + + <para>Dieses Beispiel legt gleich mehrere Anforderungen für neue + Passwörter fest. Die Einstellung <literal>min</literal> + 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 + <literal>12</literal> legt eine Richtlinie von mindestens + zwölf Zeichen fest, wenn das Passwort auch drei Arten von + Komplexität aufweist. Die <literal>10</literal> legt eine + Richtlinie fest, die auch Passwörter mit mindestens zehn + Zeichen zulassen, wenn das Passwort Zeichen mit vier Arten + von Komplexität aufweist.</para> + + <para>Die Einstellung <literal>similar</literal> verbietet + Passwörter, die dem vorherigen Passwort des Benutzers ähnlich + sind. Die Einstellung <literal>retry</literal> bietet dem + Benutzer drei Möglichkeiten, ein neues Passwort + einzugeben.</para> + + <para>Sobald diese Datei gespeichert wird, sehen Benutzer bei + der Änderung ihres Passworts die folgende Meldung:</para> + + <screen>&prompt.user; <userinput>passwd</userinput> +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:</screen> + + <para>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.</para> + + <para>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 + <filename>/etc/login.conf</filename>. Die voreingestellte + Login-Klasse enthält dazu ein Beispiel:</para> + + <programlisting># :passwordtime=90d:\</programlisting> + + <para>Um für diese Login-Klasse das Passwort nach 90 Tagen + ablaufen zu lassen, entfernen Sie das Kommentarzeichen + (<literal>#</literal>), speichern Sie die Änderungen und + führen Sie <command>cap_mkdb /etc/login.conf</command> + aus.</para> - <listitem> - <para>Kernel-Cache für Routen.</para> - </listitem> - </orderedlist> + <para>Um das Passwort für einzelne Benutzer ablaufen zu lassen, + geben Sie <command>pw</command> ein Ablaufdatum oder die + Anzahl von Tagen, zusammen mit dem Benutzer an:</para> + + <screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen> + + <para>Wie zu sehen ist, wird das Ablaufdatum in der Form von + Tag, Monat und Jahr angegeben. Weitere Informationen finden + Sie in &man.pw.8;.</para> + </sect2> + + <sect2 xml:id="security-rkhunter"> + <title>Erkennen von Rootkits</title> + + <para>Ein <firstterm>Rootkit</firstterm> 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.</para> + + <para>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: + <package>security/rkhunter</package>.</para> + + <para>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 <keycap>ENTER</keycap> drücken + müssen:</para> + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201605021804.u42I46sG087001>