© 1995-2010 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
fboerner 2010-02-06 14:21:09 UTC
FreeBSD German Documentation Repository
Modified files:
books/handbook/security chapter.sgml
Log:
MFen 1.333
Erklaerungen zu Securelevel und Prblemen bei X11 und installworld bei Securelevel >1
Approved by: bcr (mentor)
Revision Changes Path
1.171 +82 -30 de-docproj/books/handbook/security/chapter.sgml
Index: chapter.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/handbook/security/chapter.sgml,v
retrieving revision 1.170
retrieving revision 1.171
diff -u -I$FreeBSDde.*$ -r1.170 -r1.171
--- chapter.sgml 26 Jan 2010 19:07:24 -0000 1.170
+++ chapter.sgml 6 Feb 2010 14:21:09 -0000 1.171
@@ -3,8 +3,8 @@
The FreeBSD German Documentation Project
$FreeBSD: doc/de_DE.ISO8859-1/books/handbook/security/chapter.sgml,v 1.54 2008/03/26 19:02:45 jkois Exp $
- $FreeBSDde: de-docproj/books/handbook/security/chapter.sgml,v 1.170 2010/01/26 19:07:24 fboerner Exp $
- basiert auf: 1.332
+ $FreeBSDde: de-docproj/books/handbook/security/chapter.sgml,v 1.171 2010/02/06 14:21:09 fboerner Exp $
+ basiert auf: 1.333
-->
<chapter id="security">
@@ -47,7 +47,7 @@
Integrität und die Sicherheit Ihrer Systeme und Netzwerke
zu gewährleisten.</para>
- <para>Nach dem Sie dieses Kapitel durchgearbeitet haben, werden
+ <para>Nachdem Sie dieses Kapitel durchgearbeitet haben, werden
Sie:</para>
<itemizedlist>
@@ -646,30 +646,82 @@
Modulen in den Kernel: &man.kldload.8;. Ein unternehmungslustiger
Angreifer kann dies benutzen, um sein eigenes
<devicename>bpf</devicename> oder ein anderes zum Abhören
- geeignetes Gerät in den laufenden Kernel einzubringen. Um diese
- Probleme zu vermeiden, müssen Sie den Kernel auf einer
- höheren Sicherheitsstufe, mindestens <literal>1</literal>,
- laufen lassen. Die Sicherheitsstufe wird durch die Variable
- <varname>kern.securelevel</varname>, die mit <command>sysctl</command>
- gesetzt werden kann, angegeben. Nachdem Sie die Sicherheitsstufe
- auf <literal>1</literal> gesetzt haben, sind schreibende Zugriffe
- auf rohe Geräte verboten und die speziellen
- <command>chflags</command> Optionen, wie <literal>schg</literal>
- werden erzwungen. Sie müssen sicherstellen, dass die
- <literal>schg</literal> Option auf allen kritischen Programmen,
- Verzeichnissen und Skripten, die bis zum Setzen der Option laufen,
- aktiviert ist. Das mag übertrieben sein da eine Migration
- des Systems erschwert wird, wenn Sie auf einer höheren
- Sicherheitsstufe arbeiten. Sie können einen Kompromiss
- erreichen, indem Sie das System auf einer erhöhten
- Sicherheitsstufe laufen lassen, aber die <literal>schg</literal>
- Option nicht für jede Datei und jedes Verzeichnis auf der Welt
- setzen. Eine andere Möglichkeit besteht darin,
- <filename>/</filename> und <filename>/usr</filename> einfach
- schreibgeschützt einzuhängen. Bedenken Sie aber, dass
- Sie das Aufdecken eines Einbruchs vielleicht verhindern, wenn
- Sie zu drastische Maßnahmen zum Schutz Ihres Systems
- verwenden.</para>
+ geeignetes Gerät in den laufenden Kernel einzubringen. Um
+ dieses Problem zu vermeiden, müssen Sie den Kernel auf
+ einem höheren Sicherheitslevel laufen lassen, mindestens
+ auf securelevel 1.</para>
+
+ <para>Das Securelevel des Kernels kann auf verschiedene Wege
+ gesetzt werden. Der einfachste Weg ist das erhöhen des
+ Securelevel des laufenden Kernels durch ein
+ <command>sysctl</command> der <varname>kern.securelevel</varname>
+ Kernel Variablen:</para>
+
+ <screen>&prompt.root; <userinput>sysctl kern.securelevel=<replaceable>1</replaceable></userinput></screen>
+
+ <para>Standardmässig 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
+ Securelevel kann während des Systemstarts durch das Setzen
+ der Variable <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>Der Standard Securelevel von einem &os;-System direkt nach
+ dem Start ist -1. Dies wird <quote>insecure mode</quote> genannt,
+ da zum Beispiel unverändeliche Dateiflags abgeschaltet werden
+ könnten, von allen Geräten gelesen und auf alle geschrieben
+ werden kann.</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 mehr Aktionen. Für einen vollständige Liste
+ aller Securelevels, lesen Sie bitte die &man.security.7;
+ Manual Seite (oder die Manual Seite von &man.init.8; für
+ ältere Releases als &os; 7.0).</para>
+
+ <note>
+ <para>Das Erhöhen des Securelevels auf 1 oder höher
+ kann einige Probleme mit X11 verursachen (Zugriff auf
+ <filename>/dev/io</filename> wird geblockt), ebenso die Installation
+ von &os; aus den Quellen (der <maketarget>installworld</maketarget>
+ 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,
+ 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>
+ </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 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 <literal>schg</literal> Flags für alle Systemdateien
+ und Verzeichnisse zu setzen. Eine andere Möglichkeit ist es,
+ einfach 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 id="security-integrity">
@@ -741,7 +793,7 @@
<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
+ 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>
@@ -1138,7 +1190,7 @@
<para>In der Voreinstellung unterstützt &os;
OPIE (<foreignphrase>One-time Passwords in
- Everything</foreignphrase>, das in der Regel MD5-Hash-Funktionen
+ Everything</foreignphrase>), das in der Regel MD5-Hash-Funktionen
einsetzt.</para>
<para>Im Folgenden werden drei verschiedene
@@ -4049,7 +4101,7 @@
<term><option>user(at)foo.example.com</option></term>
<listitem>
- <para>Gibt den entfernten SSH server an.</para>
+ <para>Gibt den entfernten SSH-Server an.</para>
</listitem>
</varlistentry>
</variablelist>
@@ -4662,7 +4714,7 @@
zu kontrollieren, welche Befehle ein Anwender eingibt.</para>
<para>Diese Fähigkeiten haben sowohl Vor- als auch Nachteile.
- Positiv ist, dass man ein Einbruchsversuch bis an den Anfang
+ Positiv ist, dass man einen Einbruchsversuch bis an den Anfang
zurückverfolgen kann. Von Nachteil ist allerdings,
dass durch diesen Prozess Unmengen an Protokolldateien erzeugt
werden, die auch dementsprechenden Plattenplatz benötigen.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Sat 06 Feb 2010 - 15:21:25 CET