path: root/de_DE.ISO8859-1/books/handbook/security/chapter.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!--
     The FreeBSD Documentation Project
     The FreeBSD German Documentation Project

     $FreeBSD$
     $FreeBSDde: de-docproj/books/handbook/security/chapter.xml,v 1.178 2012/04/30 17:07:41 bcr Exp $
     basiert auf: 1.348
-->

<chapter id="security">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Matthew</firstname>
	<surname>Dillon</surname>
	<contrib>Viel von diesem Kapitel stammt aus der security(7)
	  Manualpage von </contrib>
      </author>
    </authorgroup>
    <authorgroup>
      <author>
	<firstname>Martin</firstname>
	<surname>Heinen</surname>
	<contrib>Übersetzt von </contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>Sicherheit</title>
  <indexterm><primary>Sicherheit</primary></indexterm>

  <sect1 id="security-synopsis">
    <title>Übersicht</title>

    <para>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 <quote>friedlicher</quote>
      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.</para>

    <para>&os; besitzt eine Reihe von Werkzeugen und Mechanismen, um die
      Integrität und die Sicherheit Ihrer Systeme und Netzwerke
      zu gewährleisten.</para>

    <para>Nachdem Sie dieses Kapitel durchgearbeitet haben, werden
      Sie:</para>

    <itemizedlist>
      <listitem>
	<para>Grundlegende auf &os; bezogene Sicherheitsaspekte
	  kennen.</para>
      </listitem>

      <listitem>
	<para>Die verschiedenen Verschlüsselungsmechanismen
	  von &os;, wie <acronym>DES</acronym> oder
	  <acronym>MD5</acronym>, kennen.</para>
      </listitem>

      <listitem>
	<para>Wissen, wie Sie ein Einmalpasswörter
	  zur Authentifizierung verwenden.</para>
      </listitem>

      <listitem>
	<para><acronym>TCP</acronym>-Wrapper für
	  <application>inetd</application> einrichten können.</para>
      </listitem>

      <listitem>
	<para>Wissen, wie Sie <application>Kerberos5</application>
	  unter &os; einrichten.</para>
      </listitem>

      <listitem>
	<para>Firewalls mit <acronym>IPFW</acronym>
	  erstellen können.</para>
      </listitem>

      <listitem>
	<para>Wissen, wie Sie IPsec konfigurieren und ein
	  <acronym>VPN</acronym> zwischen &os;/&windows;
	  Systemen einrichten,</para>
      </listitem>

      <listitem>
	<para><application>OpenSSH</application>, &os;s
	  Implementierung von <acronym>SSH</acronym>, konfigurieren
	  und benutzen können.</para>
      </listitem>

      <listitem>
	<para><application>Portaudit</application> anwenden können,
	  um Softwarepakete Dritter, die Sie über die
	  Ports-Sammlung installieren, auf bekannte
	  Sicherheitslücken hin zu überprüfen.</para>
      </listitem>

      <listitem>
	<para>Mit &os;-Sicherheitshinweisen umgehen können.</para>
      </listitem>

      <listitem>
	<para>Eine Vorstellung davon haben, was Prozessüberwachung
	  (<foreignphrase>Process Accounting</foreignphrase>) ist und wie
	  Sie diese Funktion unter &os; aktivieren können.</para>
      </listitem>
    </itemizedlist>

    <para>Bevor Sie dieses Kapitel lesen, sollten Sie</para>

    <itemizedlist>
      <listitem>
	<para>Grundlegende Konzepte von &os; und dem Internet
	  verstehen.</para>
      </listitem>
    </itemizedlist>

    <para>Dieses Buch behandelt weitere Sicherheitsthemen.
      Beispielsweise werden vorgeschriebene Zugriffskontrollen
      in <xref linkend="mac"/> und Firewalls in
      <xref linkend="firewalls"/> besprochen.</para>
  </sect1>

  <sect1 id="security-intro">
    <title>Einführung</title>

    <para>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.</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
      <username>root</username> 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 <username>root</username>-Account durch
	  zugreifbare Server.</para>
      </listitem>

      <listitem>
	<para>Kompromittierter <username>root</username>-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 Angriffe</secondary>
      <see>Denial-of-Service (DoS)</see>
    </indexterm>
    <indexterm><primary>Denial-of-Service (DoS)</primary></indexterm>

    <para>Ein Denial-of-Service (Verhinderung von Diensten, 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.</para>

    <indexterm>
      <primary>Sicherheit</primary>
      <secondary>kompromittierte Accounts</secondary>
    </indexterm>

    <para>Kompromittierte Accounts kommen noch häufiger als
      DoS Angriffe vor.  Viele Systemadministratoren lassen auf ihren
      Maschinen noch die Dienste <application>telnetd</application>,
      <application>rlogind</application>, <application>rshd</application>
      und <application>ftpd</application> 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.</para>

    <para>Es ist immer davon auszugehen, dass ein Angreifer, der
      Zugriff auf einen Account hat, Zugang zum
      <username>root</username>-Account erlangt.  Allerdings gibt der
      Zugriff auf einen Account auf einem gut gesicherten und
      gepflegten System nicht notwendig Zugriff auf den
      <username>root</username>-Account.  Diese Unterscheidung ist wichtig,
      da ein Angreifer, der keinen Zugang zu <username>root</username>
      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 <username>root</username>-Account
      eines Systems zu bekommen: Ein Angreifer kann das Passwort von
      <username>root</username> kennen, er kann einen Fehler in einem
      Server entdecken, der unter <username>root</username> läuft und
      dann über eine Netzwerkverbindung zu diesem Server einbrechen.
      Oder er kennt einen
      Fehler in einem SUID-<username>root</username> Programm, der es
      ihm erlaubt, <username>root</username> zu werden, wenn er einmal
      einen Account kompromittiert hat.  Wenn ein Angreifer einen
      Weg gefunden hat, <username>root</username> zu werden, braucht er
      vielleicht keine Hintertür auf dem System installieren.
      Viele der heute
      bekannten und geschlossenen Sicherheitslöcher, die zu einem
      <username>root</username> 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. <foreignphrase>Backdoor</foreignphrase>) zu installieren.
      Eine Hintertür erlaubt es
      dem Angreifer leicht auf den <username>root</username>-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.</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 <username>root</username> und
	  Accounts.</para>
      </listitem>

      <listitem>
	<para>Absichern von unter <username>root</username> laufenden
	  Servern und SUID/SGID Programmen.</para>
      </listitem>

      <listitem>
	<para>Absichern von 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 id="securing-freebsd">
    <title>Absichern von &os;</title>

    <indexterm>
      <primary>Sicherheit</primary>
      <secondary>&os; absichern</secondary>
    </indexterm>

    <note>
      <title>Kommandos und Protokolle</title>
      <para>In diesem Abschnitt werden Anwendungen
	<application>fett</application> gekennzeichnet, spezifische
	Kommandos werden in einer <command>Fixschrift</command>
	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.</para>
    </note>

    <para>Die folgenden Abschnitte behandeln die im
      <link linkend="security-intro">letzten Abschnitt</link> erwähnten
      Methoden Ihr &os;-System zu sichern.</para>

    <sect2 id="securing-root-and-staff">
      <title>Absichern von <username>root</username> und
	Accounts</title>

      <indexterm>
        <primary><command>su</command></primary>
      </indexterm>

      <para>Zuallererst, kümmern Sie sich nicht um die Absicherung
	von Accounts, wenn Sie <username>root</username>
	noch nicht abgesichert haben.  Auf den meisten Systemen ist
	<username>root</username> 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 Ihre PTYs in <filename>ttys</filename> als
	unsicher markiert sind und damit Anmeldungen von
	<username>root</username> mit <command>telnet</command> oder
	<command>rlogin</command> verboten sind.  Wenn Sie andere
	Anwendungen wie <application>SSH</application> zum Anmelden
	benutzen, vergewissern Sie sich, dass dort ebenfalls
	Anmeldungen als <username>root</username> verboten sind.  Für
	<application>SSH</application> editieren Sie
	<filename>/etc/ssh/sshd_config</filename> und überprüfen,
	dass <literal>PermitRootLogin</literal> auf <literal>no</literal>
	gesetzt ist.  Beachten Sie jede Zugriffsmethode &ndash; Dienste
	wie FTP werden oft vergessen.  Nur an der Systemkonsole sollte
	ein direktes Anmelden als <username>root</username> möglich
	sein.</para>

      <indexterm>
        <primary><groupname>wheel</groupname></primary>
      </indexterm>

      <para>Natürlich müssen Sie als Systemadministrator
	<username>root</username>-Zugriff erlangen können.  Dieser
	sollte aber durch zusätzliche Passwörter
	geschützt sein.  Ein Weg, Zugang zu <username>root</username>
	zu ermöglichen, ist es, berechtigte Mitarbeiter in
	<filename>/etc/group</filename> in die Gruppe
	<groupname>wheel</groupname> aufzunehmen.  Die Personen, die
	Mitglieder in der Gruppe <groupname>wheel</groupname> sind,
	können mit <command>su</command> zu <username>root</username>
	wechseln.  Ihre Mitarbeiter sollten niemals die Gruppe
	<groupname>wheel</groupname> als primäre Gruppe in
	<filename>/etc/passwd</filename> besitzen.  Mitarbeiter sollten
	der Gruppe <groupname>staff</groupname> angehören und über
	<filename>/etc/group</filename> in <groupname>wheel</groupname>
	aufgenommen werden.  Es sollten auch nur die Mitarbeiter, die
	wirklich <username>root</username> Zugriff benötigen in
	<groupname>wheel</groupname> aufgenommen werden.  Mit anderen
	Authentifizierungsmethoden müssen Sie niemanden in
	<groupname>wheel</groupname> aufnehmen.  Wenn Sie z.B.
	<application>Kerberos</application> benutzen, wechseln Sie mit
	&man.ksu.1; zu <username>root</username> und der Zugriff wird
	mit der Datei <filename>.k5login</filename> geregelt.  Dies ist
	vielleicht eine bessere Lösung, da es der
	<groupname>wheel</groupname>-Mechanismus einem Angreifer immer
	noch möglich macht, den <username>root</username>-Account
	zu knacken, nachdem er einen Mitarbeiter-Account geknackt hat.
	Obwohl der <groupname>wheel</groupname>-Mechanismus besser als
	gar nichts ist, ist er nicht unbedingt die sicherste Lösung.</para>

      <para>Um ein Konto komplett zu sperren, verwenden Sie den Befehl
	&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>wie folgt abgeändert werden:</para>

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

      <para>Durch diese Änderung wird der Benutzer
	<username>foobar</username> daran gehindert, 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
	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.</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, z.B. nach einem Monat, das Passwort wechseln
	muss.</para>
    </sect2>

    <sect2>
      <title>Absichern von unter <username>root</username> laufenden
        Servern und SUID/SGID Programmen</title>

      <indexterm>
        <primary><command>ntalk</command></primary>
      </indexterm>
      <indexterm>
        <primary><command>comsat</command></primary>
      </indexterm>
      <indexterm>
        <primary><command>finger</command></primary>
      </indexterm>
      <indexterm>
        <primary>Sandkästen</primary>
      </indexterm>
      <indexterm>
        <primary><application>sshd</application></primary>
      </indexterm>
      <indexterm>
        <primary><application>telnetd</application></primary>
      </indexterm>
      <indexterm>
        <primary><application>rshd</application></primary>
      </indexterm>
      <indexterm>
        <primary><application>rlogind</application></primary>
      </indexterm>

      <para>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
	<application>imapd</application> oder <application>popper</application>
	laufen lassen, ist das so, als würden Sie der ganzen Welt
	freien Zugang zu <username>root</username> geben.  Lassen Sie keine
	Server laufen, die Sie vorher nicht genau überprüft haben.
	Viele Server müssen nicht unter <username>root</username>
	laufen, zum Beispiel können <application>ntalk</application>,
	<application>comsat</application> und <application>finger</application>
        in speziellen <firstterm>Sandkästen</firstterm> 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 <username>root</username> läuft, Lücken
	gefunden, die zu einem <username>root</username> Zugriff führten.
	Dies betrifft selbst die grundlegenden Systemdienste.  Wenn Sie eine
	Maschine betreiben, auf der man sich nur mit
	<application>SSH</application> anmelden kann, dann stellen Sie die
	Dienste <application>telnetd</application>,
	<application>rshd</application> oder <application>rlogind</application>
	ab!</para>

      <para>In der Voreinstellung laufen unter &os;
	<application>ntalkd</application>, <application>comsat</application>
	und <application>finger</application> nun in einem Sandkasten.  Ein
	weiteres Programm, das in einem Sandkasten laufen sollte, ist
	&man.named.8;.  In <filename>/etc/defaults/rc.conf</filename> sind
	die notwendigen Argumente, um <application>named</application> 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.</para>
      <indexterm>
        <primary><application>sendmail</application></primary>
      </indexterm>

      <para>Einige Server wie <application>sendmail</application>,
	<application>popper</application>, <application>imapd</application>
	und <application>ftpd</application> 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 <username>root</username> laufen lassen und auf die
	eingebauten Mechanismen vertrauen, Einbrüche zu entdecken.</para>

      <para>Weitere potentielle Löcher, die zu einem
	<username>root</username>-Zugriff führen können, sind
        die auf dem System installierten SUID- und SGID-Programme.  Die
	meisten dieser Programme wie <application>rlogin</application> stehen
	in <filename class="directory">/bin</filename>,
	<filename class="directory">/sbin</filename>,
	<filename class="directory">/usr/bin</filename>, oder
	<filename class="directory">/usr/sbin</filename>.
	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 <literal>Xlib</literal> ein
	Loch gefunden, das <application>xterm</application>, 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 <command>chmod 000</command> deaktiviert werden.  Zum
	Beispiel braucht ein Server ohne Bildschirm kein
	<application>xterm</application> Programm.  SGID-Programme sind
	vergleichbar gefährlich.  Wenn ein Einbrecher Zugriff auf
	SGID-<groupname>kmem</groupname> 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 <groupname>kmem</groupname> 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
	<groupname>tty</groupname> 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 id="secure-users">
      <title>Absichern von Accounts</title>

      <para>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
	<application>SSH</application> und <application>Kerberos</application>
	mit normalen Accounts erschwert, obwohl das natürlich
	sicherer als die Verwendung von verschlüsselten
	Passwörtern ist.</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 <application>SSH</application> 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 <username>root</username> gelesen werden kann, mag ein
	Angreifer lesenden Zugriff auf diese Datei erlangen, ohne die
	Fähigkeit sie auch zu beschreiben.</para>

      <para>Ihre Überwachungsskripten sollten Änderungen
	an der Passwort-Datei melden (siehe <link
	linkend="security-integrity">Überprüfen der
	Integrität von Dateien</link> weiter unten).</para>
    </sect2>

    <sect2>
      <title>Absichern des Kernels, der Geräte und von
        Dateisystemen</title>

      <para>Wenn ein Angreifer <username>root</username>-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
	<devicename>bpf</devicename> 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
	<devicename>bpf</devicename> nicht nötig.</para>

      <indexterm>
        <primary><command>sysctl</command></primary>
      </indexterm>
      <para>Auch wenn Sie <devicename>bpf</devicename> nicht verwenden,
	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.  Weiterhin gibt es ein Programm zum Nachladen von
	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
	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&uml;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 &uuml;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 class="directory">/</filename> und
        <filename class="directory">/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">
      <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 class="directory">/</filename> und
	<filename class="directory">/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.  Die letzte Schicht des
	Sicherheitsmodells &ndash; das Aufdecken von Einbrüchen &ndash;
	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.</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 class="directory">/etc</filename> und
	<filename class="directory">/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 class="directory">/</filename> und
	<filename class="directory">/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>

	<listitem>
	  <para>Kernel-Cache für Routen.</para>
	</listitem>
      </orderedlist>

      <para>Ein häufiger DoS-Angriff gegen forkende Server versucht
	den Server dazu zu bringen, solange neue Prozesse zu starten,
	bis das System den ganzen Speicher und alle Dateideskriptoren
	verbraucht hat, was dann zu einem Ausfall des Servers führt.
	&man.inetd.8; besitzt einige Optionen, um diese Art von Angriffen
	zu begrenzen.  Beachten Sie bitte, dass es möglich ist, einen
	Ausfall einer Maschine zu verhindern, doch ist es generell nicht
	möglich, den Ausfall eines Dienstes bei dieser Art
	von Angriffen zu verhindern.  Lesen Sie sich bitte die Manualpages
	von <application>inetd</application> gut durch und achten Sie speziell
	auf die Optionen <option>-c</option>, <option>-C</option> und
	<option>-R</option>.  Angriffe mit gefälschten IP-Adressen
	umgehen <option>-C</option>, so dass normalerweise eine
	Kombination der Optionen benutzt werden muss.  Manche Server,
	die nicht von <application>inetd</application> gestartet werden,
	besitzen Optionen, um den Start über <function>fork()</function>
	einzuschränken.</para>

      <para><application>Sendmail</application> besitzt die Option
	<option>-OMaxDaemonChildren</option>, die besser als die
	eingebauten Optionen zur Begrenzung der Systemauslastung funktioniert.
	Sie sollten beim Start von <application>sendmail</application>
	<literal>MaxDaemonChildren</literal> 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, <application>Sendmail</application> im
	Queue-Modus (<option>-ODeliveryMode=queued</option>) laufen zu
	lassen.  Der D&aelig;mon (<command>sendmail -bd</command>) sollte
	getrennt von den Queue-Läufen (<command>sendmail -q15m</command>)
	laufen.  Wenn Sie trotzdem eine sofortige Auslieferung der Post
	wünschen, können Sie die Queue in einem geringeren
	Intervall, etwa <option>-q1m</option>, abarbeiten.  Geben Sie
	für <emphasis>dieses</emphasis>
	<application>Sendmail</application> aber einen vernünftigen
	Wert für <literal>MaxDaemonChildren</literal> an, um
	Fehler zu verhindern.</para>

      <para><application>Syslogd</application> kann direkt angegriffen
	werden.  Daher empfehlen wir Ihnen unbedingt die Option
	<option>-s</option> zu benutzen.  Sollte das nicht möglich
	sein, benutzen Sie bitte <option>-a</option>.</para>

      <para>Vorsicht ist auch mit Diensten geboten, die automatisch
	eine Rückverbindung eröffnen, wie der
	reverse-identd der <application>TCP-Wrapper</application>.
        Diese Funktion der <application>TCP-Wrapper</application>
	sollten Sie normalerweise nicht benutzen.</para>

      <para>Es empfiehlt sich sehr, interne Dienste vor externen Zugriffen
	durch eine Firewall an der Grenze Ihres Netzwerks zu schützen.
	Dahinter steckt mehr die Idee, das Netzwerk vor Überlastung
	durch Angriffe von außen zu schützen, als interne
	Dienste vor einem <username>root</username>-Zugriff aus dem Netz
	zu schützen.  Konfigurieren Sie immer eine Firewall, die
	alle Zugriffe blockiert, das heißt blockieren Sie
	<emphasis>alles</emphasis> außer den Ports A, B, C, D
	und M-Z.  Damit können Sie Zugriffe auf alle niedrigen
	Ports blockieren und Zugriffe auf spezielle Dienste wie
	<application>named</application>, wenn Sie den primären
	Namensdienst für eine Zone anbieten,
	<application>ntalkd</application> oder
	<application>sendmail</application> erlauben.  Wenn Sie die
	Firewall so konfigurieren, das sie in der Voreinstellung alle
	Zugriffe erlaubt, ist es sehr wahrscheinlich, dass Sie
	vergessen, eine Reihe von Diensten zu blockieren bzw. einen
	internen Dienst einführen und dann vergessen die Firewall
	zu aktualisieren.  Sie können immer die höheren
	Portnummern öffnen, ohne die niedrigen Portnummern,
	die nur von <username>root</username> benutzt werden dürfen,
	zu kompromittieren.  Beachten Sie bitte auch, dass es
	&os; erlaubt, die Portnummern, die für dynamische
	Verbindungen zur Verfügung stehen, zu konfigurieren.
	Mit <command>sysctl</command> lassen sich verschiedene
	Bereiche der <varname>net.inet.ip.portrange</varname> Variablen
	setzen (eine Liste erhalten Sie mit <command>sysctl -a | fgrep
	portrange</command>).
	So können Sie zum Beispiel die Portnummern 4000 bis 5000
	für den normalen Bereich und die Nummern 49152 bis 65535
	für den hohen Bereich vorsehen.  Dies erleichtert Ihnen
	die Konfiguration der Firewall, da Sie nun Zugriffe auf Ports
	unterhalb von 4000, mit Ausnahme der Dienste, die von außen
	erreichbar sein sollen, blockieren können.</para>

      <para>Eine andere Form eines DoS-Angriffs nutzt einen Server
	als Sprungbrett, der Server wird dabei so angegriffen, dass
	seine Antworten ihn selber, das lokale Netzwerk oder einen
	anderen Server überlasten.  Der am häufigsten verwendete
	Angriff dieser Art ist der <emphasis>ICMP ping broadcast
	Angriff</emphasis>.  Der Angreifer fälscht dazu
	<application>ping</application>-Pakete, die zu der Broadcast-Adresse
	Ihres LANs gesendet werden, indem er darin als Quelladresse
	die Adresse des Opfers einsetzt.  Wenn die Router an der Grenze
	Ihres Netzwerks <application>ping</application>-Pakete auf
	Broadcast-Adressen nicht abwehren, wird Ihr LAN genügend
	Netzwerkverkehr generieren, um das Ziel des Angriffs zu
	überlasten.  Dies kann besonders effektiv sein, wenn der
	Angreifer diese Methode mit mehreren Dutzend Broadcast-Adressen
	über mehrere Netzwerke einsetzt.  Es wurden schon
	Broadcast-Angriffe mit über 120&nbsp;Megabit pro Sekunde
	gemessen.  Ein zweiter Sprungbrett-Angriff wird gegen
	das Fehlerbehandlungssystem von ICMP eingesetzt.  Indem ein Angreifer
	Pakete konstruiert, die eine ICMP-Fehlermeldung hervorrufen, kann
	er das einkommende Netzwerk des Servers sättigen und diesen
	wiederum veranlassen sein ausgehendes Netzwerk mit ICMP-Antworten
	zu sättigen.  Diese Art des Angriffs kann den kompletten
	Speicher des Servers aufbrauchen und damit den Server stilllegen,
	insbesondere wenn der Server nicht in der Lage ist, die generierten
	ICMP-Antworten schnell genug abzuführen.  Verwenden Sie die
	<application>sysctl</application>-Variable
	<literal>net.inet.icmp.icmplim</literal>, um die Auswirkungen
	solcher Angriffe zu begrenzen.  Die letzte
	weit verbreitete Form von Sprungbrett-Angriffen verwendet
	interne <application>inetd</application>-Dienste wie den
	UDP <application>echo</application>-Dienst.  Der Angreifer fälscht
	dazu einfach ein UDP-Paket, indem er als Quellport den
	<application>echo</application>-Port von Server A
	und als Zielport den <application>echo</application>-Port von
	Server B angibt, wobei beide
	Server in Ihrem LAN stehen.  Die beiden Server werden nun
        dieses Paket zwischen sich hin und her schicken.  Der Angreifer
	kann die beiden Server und das LAN einfach damit überlasten,
	dass er mehrere Pakete dieser Art generiert.  Ähnliche
	Probleme gibt es mit dem internen
	<application>chargen</application>-Port, daher sollten Sie
	die internen <application>inetd</application>-Testdienste
	abstellen.</para>

      <para>Gefälschte IP-Pakete können dazu benutzt werden,
	den Kernel-Cache für Routen zu überlasten.  Schauen Sie
	sich bitte die  <command>sysctl</command>-Parameter
	<varname>net.inet.ip.rtexpire</varname>, <varname>rtminexpire</varname>
	und <varname>rtmaxcache</varname> an.  Ein Angriff der gefälschte
	Pakete mit zufälligen Quelladressen einsetzt, bewirkt, dass
	der Kernel eine Route im Route-Cache anlegt, die Sie sich mit
	<command>netstat -rna | fgrep W3</command> ansehen können.
	Diese Routen verfallen für gewöhnlich nach 1600 Sekunden.
	Wenn der Kernel feststellt, dass die Routingtabelle im Cache
	zu groß geworden ist, wird er dynamisch den Wert von
	<varname>rtexpire</varname> verringern.  Dieser Wert wird aber nie
	kleiner werden als <varname>rtminexpire</varname>.  Daraus
	ergeben sich zwei Probleme:</para>

      <orderedlist>
	<listitem>
	  <para>Der Kernel reagiert nicht schnell genug, wenn ein
	    Server mit einer niedrigen Grundlast plötzlich angegriffen
	    wird.</para>
	</listitem>

	<listitem>
	  <para><varname>rtminexpire</varname> ist nicht klein genug,
	    um einen anhaltenden Angriff zu überstehen.</para>
	</listitem>
      </orderedlist>

      <para>Wenn Ihre Server über eine T3 oder eine noch schnellere
	Leitung mit dem Internet verbunden sind, ist es klug, mit
        &man.sysctl.8; die Werte für <varname>rtexpire</varname> und
	<varname>rtminexpire</varname> händisch zu setzen.  Setzen
	Sie bitte keinen der Werte auf Null, außer Sie wollen die
	Maschine zum Erliegen bringen.  Ein Wert von 2&nbsp;Sekunden für
	beide Parameter sollte ausreichen, um die Routingtabelle vor
	einem Angriff zu schützen.</para>
    </sect2>

    <sect2>
      <title>Anmerkungen zum Zugriff mit Kerberos und SSH</title>
      <indexterm><primary><command>ssh</command></primary></indexterm>

      <para>Es gibt ein paar Punkte, die Sie beachten sollten, wenn Sie
	<application>Kerberos</application> oder <application>SSH</application>
	einsetzen wollen.  <application>Kerberos</application>&nbsp;5 ist ein
	ausgezeichnetes Authentifizierungsprotokoll.  Leider gibt es
	Fehler in den für <application>Kerberos</application>
	angepassten Versionen von <application>telnet</application> und
	<application>rlogin</application>, die sie ungeeignet für den
	Umgang mit binären Datenströmen machen.  Weiterhin
	verschlüsselt <application>Kerberos</application> Ihre Sitzung
	nicht, wenn Sie nicht die <option>-x</option> Option verwenden,
	mit <application>SSH</application> wird dagegen alles
	verschlüsselt.</para>

      <para>Ein Problem mit SSH sind Weiterleitungen von Verbindungen.
	Wenn Sie von einer sicheren Maschine, auf der sich Ihre
	Schlüssel  befinden, eine Verbindung zu einer
	ungesicherten Maschine aufmachen, wird für die Dauer der
	Sitzung ein Port für Weiterleitungen geöffnet.
	Ein Angreifer, der auf der unsicheren Maschine Zugang zu
	<username>root</username> hat, kann diesen Port
	benutzen, um Zugriff auf andere Maschinen zu
	erlangen, die mit Ihren Schlüsseln zugänglich
	sind.</para>

      <para>Wir empfehlen Ihnen, für die Logins Ihrer Mitarbeiter immer
	<application>SSH</application> zusammen mit
	<application>Kerberos</application> einzusetzen.  Damit reduzieren
	Sie die Abhängigkeit von potentiell gefährdeten
	Schlüsseln und schützen gleichzeitig die Passwörter
	mit <application>Kerberos</application>.
	<application>SSH</application>-Schlüsselpaare sollten nur
	für automatisierte Aufgaben von einem besonders gesicherten
	Server eingesetzt werden (<application>Kerberos</application>
	kann für diese Art von Aufgaben nicht eingesetzt werden).
	Weiterhin empfehlen wir Ihnen, das Weiterreichen von Schlüsseln
	in der <application>SSH</application>-Konfiguration abzustellen bzw.
	die <literal>from=IP/DOMAIN</literal> Option in
	<filename>authorized_keys</filename> zu verwenden, die den
	Schlüssel nur von bestimmten Maschinen aus nutzbar macht.</para>
    </sect2>
  </sect1>

  <sect1 id="crypt">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Bill</firstname>
	  <surname>Swingle</surname>
	  <contrib>Teile umgeschrieben und aktualisiert von </contrib>
	</author>
      </authorgroup>
      <!-- 21 Mar 2000 -->
    </sect1info>

    <title>DES, Blowfish, MD5, und Crypt</title>
    <indexterm>
      <primary>Sicherheit</primary>
      <secondary>Crypt</secondary>
    </indexterm>

    <indexterm><primary>Crypt</primary></indexterm>
    <indexterm><primary>Blowfish</primary></indexterm>
    <indexterm><primary>DES</primary></indexterm>
    <indexterm><primary>MD5</primary></indexterm>

    <para>Jedem Benutzer eines &unix; Systems ist ein Passwort zugeordnet.
      Es scheint offensichtlich, dass das Passwort nur dem Benutzer
      und dem System bekannt sein muss.  Um die Passwörter
      geheim zu halten, werden sie mit einer nicht umkehrbaren Hash-Funktion
      verschlüsselt, das heißt sie können leicht
      verschlüsselt aber nicht entschlüsselt werden.  Was wir
      gerade als offensichtlich dargestellt haben, ist also nicht wahr: Das
      Betriebssystem kennt das Passwort <emphasis>wirklich</emphasis>
      nicht, es kennt nur das <emphasis>verschlüsselte</emphasis>
      Passwort.  Die einzige Möglichkeit, das originale Passwort
      herauszufinden, besteht darin, alle möglichen Passwörter
      auszuprobieren (<foreignphrase>brute force</foreignphrase> Suche).</para>

    <para>Zu der Zeit als &unix; entstanden ist, war die einzig sichere
      Möglichkeit Passwörter zu verschlüsseln, leider
      DES (Data Encryption Standard).  Für die Einwohner der USA
      stellte das kein Problem dar, aber da der Quellcode von DES nicht aus
      den USA exportiert werden durfte, musste ein Weg gefunden werden,
      der die Gesetze der USA nicht verletzte und gleichzeitig die
      Kompatibilität mit anderen &unix; Systemen, die immer noch DES
      benutzten, wahrte.</para>

    <para>Die Lösung bestand darin, die Verschlüsselungsbibliotheken
      aufzuspalten.  Benutzer in den USA konnten die DES-Bibliotheken
      installieren und nutzen.  In der Grundeinstellung benutzt &os;
      MD5 als Verschlüsselungsmethode, das exportiert werden durfte
      und damit von jedem genutzt werden konnte.  Es wird davon ausgegangen,
      dass MD5 sicherer als DES ist, so dass DES nur aus
      Kompatibilitätsgründen installiert werden sollte.</para>

    <sect2>
      <title>Erkennen der Verschlüsselungsmethode</title>

      <para>Derzeit werden DES-, MD5- und Blowfish-Hash-Funktionen
	unterstützt.  In der
	Voreinstellung benutzt &os; die MD5-Hash-Funktion.</para>

      <para>Sie können leicht herausfinden, welche
	Verschlüsselungsmethode von &os; verwendet wird.  Ein Weg
	besteht darin, die verschlüsselten Passwörter in
	<filename>/etc/master.passwd</filename> zu untersuchen.
	Passwörter, die mit MD5 verschlüsselt wurden,
	sind länger als die mit DES verschlüsselten und
	beginnen mit den Zeichen <literal>&dollar;1&dollar;</literal>.
	Passwörter, die mit <literal>&dollar;2a&dollar;</literal>
	anfangen, wurden mit der Blowfish-Funktion verschlüsselt.
	DES Passwörter besitzen keine offensichtlichen Merkmale,
	an denen sie identifiziert werden könnten.  Sie sind aber
	kürzer als MD5-Passwörter und sind in einem
	64 Zeichen umfassenden Alphabet kodiert, das das
	<literal>&dollar;</literal>-Zeichen nicht enthält.  Ein relativ
	kurzes Passwort, das nicht mit einem
	<literal>&dollar;</literal>-Zeichen anfängt, ist wahrscheinlich
	ein DES-Passwort.</para>

      <para>Die Verschlüsselungsmethode für neue
        Passwörter wird durch <literal>passwd_format</literal> in
	<filename>/etc/login.conf</filename> bestimmt.  Der Wert dieser
	Variablen kann entweder <literal>des</literal>, <literal>md5</literal>
	oder <literal>blf</literal> sein.  Näheres schlagen Sie bitte
	in &man.login.conf.5; nach.</para>
    </sect2>
  </sect1>

  <sect1 id="one-time-passwords">
    <title>Einmalpasswörter</title>
    <indexterm><primary>Einmalpasswörter</primary></indexterm>
    <indexterm>
      <primary>Sicherheit</primary>
      <secondary>Einmalpasswörter</secondary>
    </indexterm>

    <para>In der Voreinstellung unterstützt &os;
      OPIE (<foreignphrase>One-time Passwords in
      Everything</foreignphrase>), das in der Regel MD5-Hash-Funktionen
      einsetzt.</para>

    <para>Im Folgenden werden drei verschiedene
      Passwörter verwendet.  Das erste ist Ihr normales System- oder
      Kerberos-Passwort und wird im Folgenden <quote>System-Passwort</quote>
      genannt.  Das zweite ist das Einmalpasswort, das bei OPIE von
      <command>opiekey</command> generiert und von
      <command>opiepasswd</command> und dem Login-Programm akzeptiert wird.
      Im Folgenden wird es <quote>Einmalpasswort</quote> genannt.  Das dritte
      Passwort ist das geheime Passwort, das Sie mit
      <command>opiekey</command> (manchmal auch mit
      <command>opiepasswd</command>) zum Erstellen
      der Einmalpasswörter verwenden.  Dieses Passwort
      werden wir im Folgenden <quote>geheimes Passwort</quote>
      oder schlicht <quote>Passwort</quote> nennen.</para>

    <para>Das geheime Passwort steht in keiner Beziehung zu Ihrem
      System-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&nbsp;Zeichen,
      wie alte &unix; Passwörter<footnote>
	<para>Unter &os; darf das System-Passwort maximal
	  128&nbsp;Zeichen lang sein.</para></footnote>, 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.</para>

    <para>Neben dem Passwort gibt es noch zwei Werte, die für
      OPIE wichtig sind.  Der erste ist der
      <quote>Initialwert</quote> (engl. <foreignphrase>seed</foreignphrase>
      oder <foreignphrase>key</foreignphrase>), der aus zwei Buchstaben
      und fünf Ziffern besteht.  Der zweite Wert ist der
      <quote>Iterationszähler</quote>, 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.</para>

    <para>In jedem System werden mehrere Programme verwendet, die weiter
      unten beschrieben werden.  <command>opiekey</command> verlangt
      einen Iterationszähler, einen Initialwert und ein geheimes
      Passwort.  Daraus generiert es ein Einmalpasswort oder eine Liste
      von Einmalpasswörtern.  <command>opiepasswd</command> 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
      entweder ein geheimes Passwort oder einen Iterationszähler
      oder einen Initialwert und ein Einmalpasswort.
      <command>opieinfo</command> hingegen gibt den momentanen
      Iterationszähler und Initialwert eines Benutzers aus.  Diese
      werden aus der Datei <filename>/etc/opiekeys</filename>
      ermittelt.</para>
      <!-- Credential Dateien -->

    <para>Im Folgenden werden vier verschiedene Tätigkeiten beschrieben.
      Zuerst wird erläutert, wie
      <command>opiepasswd</command> über eine gesicherte Verbindung
      eingesetzt werden, um Einmalpasswörter das erste Mal
      zu konfigurieren oder das Passwort oder den Initialwert
      zu ändern.  Als nächstes wird erklärt, wie
      <command>opiepasswd</command> über eine nicht gesicherte
      Verbindung, oder zusammen mit <command>opiekey</command> über
      eine gesicherte Verbindung eingesetzt werden, um dasselbe zu
      erreichen. Als drittes wird beschrieben, wie
      <command>opiekey</command> genutzt wird,
      um sich über eine nicht gesicherte Verbindung anzumelden.
      Die vierte Tätigkeit beschreibt, wie mit
      <command>opiekey</command> eine Reihe von Schlüsseln
      generiert wird, die Sie sich aufschreiben oder ausdrucken können,
      um sich von Orten anzumelden, die über keine gesicherten
      Verbindungen verfügen.</para>

    <sect2>
      <title>Einrichten über eine gesicherte Verbindung</title>

      <para>Um OPIE erstmals zu initalisieren, rufen Sie
	<command>opiepasswd</command> auf:</para>

      <screen>&prompt.user; <userinput>opiepasswd -c</userinput>
[grimreaper] ~ $ opiepasswd -f -c
Adding unfurl:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:

ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED
      </screen>

      <para>Nach der Aufforderung <prompt>Enter new secret pass phrase:</prompt>
	oder <prompt>Enter secret password:</prompt> geben Sie bitte Ihr
	Passwort ein.  Dies ist nicht das Passwort, mit dem Sie sich
	anmelden, sondern es wird genutzt, um das Einmalpasswort
	zu generieren.  Die Zeile, die mit <quote>ID</quote> anfängt,
	enthält Ihren Login-Namen, den Iterationszähler und den
	Initialwert.  Diese Werte müssen Sie sich nicht behalten, da
	das System sie zeigen wird, wenn Sie sich anmelden.  In der letzten
	Zeile steht das Einmalpasswort, das aus diesen Parametern
	und Ihrem geheimen Passwort ermittelt wurde.  Wenn sie sich jetzt
	wieder anmelden wollten, dann müssten Sie dieses
	Passwort benutzen.</para>
    </sect2>

    <sect2>
      <title>Einrichten über eine nicht gesicherte Verbindung</title>

      <para>Um Einmalpasswörter über eine nicht gesicherte
	Verbindung einzurichten, oder das geheime Passwort zu ändern,
        müssen Sie über eine gesicherte Verbindung zu einer Stelle
	verfügen, an der Sie <command>opiekey</command> ausführen.
	Dies kann etwa die Eingabeaufforderung auf einer Maschine, der Sie
	vertrauen, sein.  Zudem müssen Sie einen Iterationszähler
	vorgeben (100 ist ein guter Wert) und einen Initialwert wählen,
	wobei Sie auch einen zufällig generierten benutzen können.
	Benutzen Sie <command>opiepasswd</command> über die ungesicherte
	Verbindung zu der Maschine, die Sie einrichten wollen:</para>

      <screen>&prompt.user; <userinput>opiepasswd</userinput>

Updating unfurl:
You need the response from an OTP generator.
Old secret pass phrase:
        otp-md5 498 to4268 ext
        Response: GAME GAG WELT OUT DOWN CHAT
New secret pass phrase:
        otp-md5 499 to4269
        Response: LINE PAP MILK NELL BUOY TROY

ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY</screen>

      <para>Drücken Sie <keycap>Return</keycap>, um die Vorgabe
	für den Initialwert zu akzeptieren.  Bevor
	Sie nun das Zugriffspasswort
	(engl. <foreignphrase>access password</foreignphrase>)
	eingeben, rufen Sie über die gesicherte Verbindung
	<command>opikey</command> mit denselben Parametern auf:</para>

      <screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>

      <para>Gehen Sie nun zurück zu der nicht gesicherten Verbindung
	und geben dort das eben generierte Einmalpasswort ein.</para>
    </sect2>

    <sect2>
      <title>Erzeugen eines einzelnen Einmalpasswortes</title>

      <para>Nachdem Sie OPIE eingerichtet haben, werden Sie beim
	nächsten Anmelden wie folgt begrüßt:</para>

<screen>&prompt.user; <userinput>telnet example.com</userinput>
Trying 10.0.0.1...
Connected to example.com
Escape character is '^]'.

FreeBSD/i386 (example.com) (ttypa)

login: <userinput>&lt;username&gt;</userinput>
otp-md5 498 gr4269 ext
Password: </screen>

      <para>Anmerkung: OPIE besitzt eine nützliche Eigenschaft,
	die hier nicht gezeigt ist.  Wenn Sie an der Eingabeaufforderung
	<keycap>Return</keycap> eingeben, wird die echo-Funktion eingeschaltet,
	das heißt Sie sehen, was Sie tippen.  Dies ist besonders
	nützlich, wenn Sie ein generiertes Passwort von einem
	Ausdruck abtippen müssen.</para>

      <indexterm><primary>MS-DOS</primary></indexterm>
      <indexterm><primary>Windows</primary></indexterm>
      <indexterm><primary>MacOS</primary></indexterm>

      <para>Jetzt müssen Sie Ihr Einmalpasswort generieren,
	um der Anmeldeaufforderung nachzukommen.  Dies muss auf
	einem gesicherten System geschehen, auf dem Sie
	oder <command>opiekey</command> ausführen können.
	Dieses Programm gibt es übrigens auch für DOS, &windows; und
	&macos;.  Es benötigt den Iterationszähler
	sowie den Initialwert als Parameter, die Sie mittels
	<quote>cut-and-paste</quote> direkt von der Login-Aufforderung
	nehmen können.</para>

      <para>Auf dem sicheren System:</para>

      <screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>

      <para>Mit dem jetzt generierten Einmalpasswort können
	Sie die Anmeldeprozedur fortsetzen.</para>
    </sect2>

    <sect2>
      <title>Erzeugen von mehreren Einmalpasswörtern</title>

      <para>Manchmal müssen Sie sich an Orte begeben, an denen
	Sie keinen Zugriff auf eine sichere Maschine oder eine
	sichere Verbindung haben.  In diesem Fall können Sie
	vorher mit <command>opiekey</command>
	einige Einmalpasswörter generieren, die Sie sich
	ausdrucken und mitnehmen können.  Zum Beispiel:</para>

      <screen>&prompt.user; <userinput>opiekey -n 5 30 zz99999</userinput>
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
28: SALT TIN ANTI LOON NEAL USE
29: RIO ODIN GO BYE FURY TIC
30: GREW JIVE SAN GIRD BOIL PHI</screen>

      <para>Mit <option>-n 5</option> fordern Sie fünf
	Passwörter der Reihe nach an.  Der letzte
	Iterationszähler wird durch <option>30</option> gegeben.
	Beachten Sie bitte, dass die Passwörter in der
	<emphasis>umgekehrten</emphasis> Reihenfolge, in der sie
	zu benutzen sind, ausgeben werden.  Wenn Sie wirklich paranoid
	sind, schreiben Sie sich jetzt die Passwörter auf,
	ansonsten drucken Sie sie mit <command>lpr</command> aus.
	Beachten Sie, dass jede Zeile den Iterationszähler
	und das Einmalpasswort zeigt, trotzdem finden Sie es
	vielleicht hilfreich, eine Zeile nach Gebrauch durchzustreichen.</para>
    </sect2>

    <sect2>
      <title>Einschränken der Benutzung von
	System-Passwörtern</title>

      <para>OPIE kann die Verwendung von System-Passwörtern
	abhängig von der Quell-IP-Adresse einschränken.
	Die dazu nötigen Einstellungen werden in der Datei
	<filename>/etc/opieaccess</filename> vorgenommen, die
	bei der Installation des Systems automatisch erzeugt wird.
	Weitere Informationen über diese Datei und
	Sicherheitshinweise zu ihrer Verwendung entnehmen Sie bitte
	der Hilfeseite &man.opieaccess.5;.</para>

      <para>Die Datei <filename>opieaccess</filename> könnte
	beispielsweise die folgende Zeile enthalten:</para>

      <programlisting>permit 192.168.0.0 255.255.0.0</programlisting>

      <para>Diese Zeile erlaubt es Benutzern, die sich von einer der
	angegebenen Quell-IP-Adressen anmelden, ihr System-Passwort
	zu verwenden.  Beachten Sie bitte, dass eine Quell-IP-Adresse
	leicht gefälscht werden kann.</para>

      <para>Findet sich in <filename>opieaccess</filename> kein
	passender Eintrag, muss die Anmeldung mit OPIE erfolgen.</para>
    </sect2>
  </sect1>

  <sect1 id="tcpwrappers">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>TCP-Wrapper</title>

    <indexterm>
      <primary>TCP-Wrapper</primary>
    </indexterm>

    <para>Wahrscheinlich hat jeder, der &man.inetd.8; kennt,
      schon mal von den TCP-Wrappern gehört.  Die
      wenigsten erkennen den vollen Nutzen der TCP-Wrapper
      in einer Netzumgebung.  Es scheint, dass die meisten
      Leute Netzverbindungen mit einer Firewall absichern
      wollen.  Auch wenn eine Firewall ein mächtiges
      Instrument ist, gibt es Sachen, die eine Firewall
      nicht kann.  Eine Firewall kann beispielsweise keine
      Nachricht an den Verbindungsursprung senden.  Genau
      das und mehr können aber die
      <acronym>TCP</acronym>-Wrapper.  Im Folgenden werden
      die Funktionen der <acronym>TCP</acronym>-Wrapper
      und Beispiele für deren Konfiguration vorgestellt.</para>

    <para>Die <acronym>TCP</acronym>-Wrapper erweitern die
      Steuerungsmöglichkeiten, die <application>inetd</application>
      über die Dienste unter seiner Kontrolle hat.
      Beispielsweise können Verbindungen protokolliert,
      Nachrichten zurückgesandt oder nur interne Verbindungen
      angenommen werden.  Die <acronym>TCP</acronym>-Wrapper
      bieten nicht nur eine weitere Sicherheitsschicht, die
      teilweise auch von Firewalls geboten wird, sie bieten
      darüber hinaus Funktionen zur Steuerung von
      Verbindungen, die eine Firewall nicht bietet.</para>

    <para>Die erweiterten Funktionen der
      <acronym>TCP</acronym>-Wrapper sind kein Firewall-Ersatz.
      Sie sollten zusammen mit einer Firewall und anderen
      Sicherheitsvorkehrungen eingesetzt werden.  Die
      <acronym>TCP</acronym>-Wrapper sind eine weitere
      Sicherheitsschicht zum Schutz eines Systems.</para>

    <para>Da die Wrapper die Funktion von <application>inetd</application>
      erweitern, wird im Folgenden vorausgesetzt, dass Sie den
      Abschnitt über die
      <link linkend="network-inetd">inetd-Konfiguration</link>
      schon gelesen haben.</para>

    <note>
      <para>Streng genommen handelt es sich bei den von &man.inetd.8;
        gestarteten Programmen nicht um <quote>Daemonen</quote>.  Da
        sich diese Bezeichnung aber eingebürgert hat, wird sie auch
        in diesem Abschnitt verwendet.</para>
    </note>

    <sect2>
      <title>TCP-Wrapper einrichten</title>

      <para>Um die <acronym>TCP</acronym>-Wrapper unter &os;
        zu benutzen, muss nur der <application>inetd</application>
        aus <filename>rc.conf</filename> mit den voreingestellten
        Optionen <option>-Ww</option> gestartet werden.
        Die Konfigurationsdatei <filename>/etc/hosts.allow</filename>
        darf keine Fehler enthalten; falls doch, werden die
        Fehler mit &man.syslogd.8; protokolliert.</para>

      <note>
        <para>Im Gegensatz zu anderen Implementationen der
          <acronym>TCP</acronym>-Wrapper wird vom Gebrauch
          der Datei <filename>hosts.deny</filename> abgeraten.
          Die Konfiguration sollte sich vollständig in der
          Datei <filename>/etc/hosts.allow</filename> befinden.</para>
      </note>

      <para>In der einfachsten Konfiguration werden Dienste
        abhängig vom Inhalt der Datei
        <filename>/etc/hosts.allow</filename> erlaubt oder
        gesperrt.  Unter &os; wird in der Voreinstellung
        jeder von <application>inetd</application> gestartete Dienst
        erlaubt.  Sehen wir uns zunächst die Grundkonfiguration
        an.</para>

      <para>Eine Konfigurationszeile ist wie folgt aufgebaut:
        <literal>Dienst : Adresse : Aktion</literal>.
        <literal>Dienst</literal> ist der von <application>inetd</application>
        gestartete Dienst (auch Daemon genannt).  Die
        <literal>Adresse</literal> kann ein gültiger
        Rechnername, eine <acronym>IP</acronym>-Adresse oder
        eine IPv6-Adresse in Klammern
        (<literal>[</literal>&nbsp;<literal>]</literal>) sein.
        Der Wert <literal>allow</literal> im Feld
        <literal>Aktion</literal> erlaubt Zugriffe, der Wert
        <literal>deny</literal> verbietet Zugriffe.
        Die Zeilen in <filename>hosts.allow</filename>
        werden für jede Verbindung der Reihe nach
        abgearbeitet.  Trifft eine Zeile auf eine Verbindung
        zu, wird die entsprechende Aktion ausgeführt
        und die Abarbeitung ist beendet.</para>

      <para>Es gibt noch weitere Konfigurationsoptionen, die
        gleich erläutert werden.  Das bisher Gesagte
        reicht, um eine einfache Regel aufzustellen.  Wenn
        Sie einkommende <acronym>POP</acronym>3-Verbindungen
        für den Dienst
        <filename role="package">mail/qpopper</filename>
        erlauben wollen, erweitern Sie
        <filename>hosts.allow</filename> um die nachstehende Zeile:</para>

      <programlisting># This line is required for POP3 connections:
qpopper : ALL : allow</programlisting>

      <para>Nachdem Sie die Zeile hinzugefügt haben, muss der
        <application>inetd</application> neu gestartet werden.  Sie
        können dazu das Kommando &man.kill.1; verwenden
        oder <command>/etc/rc.d/inetd restart</command>
        ausführen.</para>
    </sect2>

    <sect2>
      <title>Erweiterte Konfiguration der TCP-Wrapper</title>

      <para>Die <acronym>TCP</acronym>-Wrapper besitzen
	weitere Optionen, die bestimmen, wie Verbindungen
	behandelt werden.  In einigen Fällen ist es
	gut, wenn bestimmten Rechnern oder Diensten eine
	Nachricht geschickt wird.  In anderen Fällen
	soll vielleicht der Verbindungsaufbau protokolliert
	oder eine E-Mail an einen Administrator versandt
	werden.  Oder ein Dienst soll nur für das
	lokale Netz bereitstehen.  Dies alles ist mit so genannten
	Wildcards, Metazeichen und der Ausführung externer
	Programme möglich und wird in den nächsten
	zwei Abschnitten erläutert.</para>

      <sect3>
	<title>Externe Kommandos ausführen</title>

	<para>Stellen Sie sich vor, eine Verbindung soll
	  verhindert werden und gleichzeitig soll demjenigen,
	  der die Verbindung aufgebaut hat, eine Nachricht
	  geschickt werden.  Auf welche Art müssen
	  die <acronym>TCP</acronym>-Wrapper konfiguriert werden?
	  Die Option <option>twist</option> führt beim
	  Verbindungsaufbau ein Kommando aus.  In der Datei
	  <filename>hosts.allow</filename> ist ein Beispiel
	  für diese Option enthalten:</para>

	<programlisting># Alle anderen Dienste sind geschützt
ALL : ALL \
        : severity auth.info \
        : twist /bin/echo "You are not welcome to use %d from %h."</programlisting>

	<para>Für jeden Dienst, der nicht vorher in
	  der Datei <filename>hosts.allow</filename> konfiguriert
	  wurde, wird die Meldung <quote>You are not allowed to use
	  <literal>daemon</literal> from
	  <literal>hostname</literal>.</quote> zurückgegegeben.
	  Dies ist besonders nützlich, wenn Sie die
	  Gegenstelle sofort benachrichtigen wollen, nachdem
	  die Verbindung getrennt wurde.  Beachten Sie, dass
	  der Text der Meldung in Anführungszeichen
	  (<literal>"</literal>) stehen <emphasis>muss</emphasis>,
	  es gibt keine Ausnahmen zu dieser Regel.</para>

	<warning>
	  <para>Ein so konfigurierter Server ist anfällig
	    für Denial-of-Service-Angriffe.  Ein Angreifer
	    kann die gesperrten Dienste mit Verbindungsanfragen
	    überfluten.</para>
	</warning>

	<para>Um einem Denial-of-Service-Angriff zu entgehen,
	  benutzen Sie die Option <option>spawn</option>.
	  Wie die Option <option>twist</option> verbietet die Option
	  <option>spawn</option> die Verbindung und führt
	  externe Kommandos aus.  Allerdings sendet die
	  Option <option>spawn</option> der Gegenstelle
	  keine Rückmeldung.  Sehen Sie sich die
	  nachstehende Konfigurationsdatei an:</para>

	<programlisting># Verbindungen von example.com sind gesperrt:
ALL : .example.com \
	: spawn (/bin/echo %a from %h attempted to access %d &gt;&gt; \
	  /var/log/connections.log) \
	: deny</programlisting>

	<para>Damit sind Verbindungen von der Domain
	  <hostid role="fqdn">*.example.com</hostid> gesperrt.
	  Jeder Verbindungsaufbau wird zudem in der Datei
	  <filename>/var/log/connections.log</filename>
	  protokolliert.  Das Protokoll enthält den
	  Rechnernamen, die <acronym>IP</acronym>-Adresse
	  und den Dienst, der angesprochen wurde.</para>

	<para>In der Konfigurationsdatei wurde beispielsweise
	  das Metazeichen <literal>%a</literal> verwendet.  Es gibt weitere
	  Metazeichen, die in der Hilfeseite &man.hosts.access.5;
	  beschrieben werden.</para>
      </sect3>

      <sect3>
	<title>Wildcards</title>

	<para>Bisher verwendeten die Beispiele immer die
	  Wildcard <literal>ALL</literal>.  Es gibt andere Wildcards,
	  welche die Funktionalität ein bisschen erweitern.  Die Wildcard
	  <literal>ALL</literal> passt beispielsweise auf
	  jeden Dienst, jede Domain oder jede
	  <acronym>IP</acronym>-Adresse.  Eine andere
	  Wildcard ist <literal>PARANOID</literal>.  Sie passt
	  auf jeden Rechner, dessen <acronym>IP</acronym>-Adresse
	  möglicherweise gefälscht ist.  Dies ist dann
	  der Fall, wenn der Verbindungsaufbau von einer
	  <acronym>IP</acronym>-Adresse erfolgt, die nicht
	  zu dem übermittelten Rechnernamen passt.  Das folgende
	  Beispiel sollte das ganze etwas klarer werden lassen:
	  </para>

	<programlisting># Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny</programlisting>

	<para>In diesem Beispiel werden alle Verbindungen zu
	  <command>sendmail</command> verboten, die von einer
	  <acronym>IP</acronym>-Adresse ausgehen, die nicht zum
	  Rechnernamen passt.</para>

	<caution>
	  <para>Die Wildcard <literal>PARANOID</literal>
	    kann einen Dienst unbrauchbar machen, wenn der
	    Client oder der Server eine fehlerhafte
	    <acronym>DNS</acronym>-Konfiguration besitzt.
	    Seien Sie daher besonders vorsichtig, wenn Sie diese Wildcard
	    in Ihre Konfiguration aufnehmen wollen.</para>
	</caution>

	<para>Weiteres über Wildcards und deren Funktion
	  lesen Sie bitte in der Hilfeseite &man.hosts.access.5;
	  nach.</para>

	<para>
	  Damit die gezeigten Beispiele funktionieren, müssen
	  Sie die erste Konfigurationszeile in der Datei
	  <filename>hosts.allow</filename> auskommentieren.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="kerberos5">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tillman</firstname>
	  <surname>Hodgson</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Mark</firstname>
	  <surname>Murray</surname>
	  <contrib>Beruht auf einem Beitrag von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title><application>Kerberos5</application></title>

    <para><application>Kerberos</application> ist ein Netzwerk-Protokoll,
      das Benutzer mithilfe eines sicheren Servers authentifiziert.
      Mit Risiken behaftete Dienste, wie das Anmelden an entfernten
      Systemen oder das Kopieren von Daten auf entfernte Systeme,
      werden durch <application>Kerberos</application> erheblich
      sicherer und lassen sich leichter steuern.</para>

    <para><application>Kerberos</application> hat eine Aufgabe:
      Die sichere Prüfung der Identität eines Benutzers
      (Authentifizierung) über das Netzwerk.  Das System
      überprüft weder die Berechtigungen der Benutzer
      (Autorisierung), noch verfolgt es die durchgeführten
      Aktionen (Audit).  Daher sollte <application>Kerberos</application>
      zusammen mit anderen Sicherheits-Systemen eingesetzt werden, die
      diese Funktionen bereitstellen.  Die Daten einer Kommunikation
      können verschlüsselt werden, nachdem die
      Kommunikationspartner mit <application>Kerberos</application>
      ihre Identität geprüft haben.</para>

    <para>Die folgenden Anweisungen beschreiben, wie Sie das mit
      &os; gelieferte <application>Kerberos</application> einrichten.
      Eine vollständige Beschreibung des Systems entnehmen
      Sie bitte den entsprechenden Hilfeseiten.</para>

    <para>Die Beschreibung der
      <application>Kerberos</application>-Installation benutzt
      folgende Namensräume:</para>

    <itemizedlist>
      <listitem>
	<para>Die <acronym>DNS</acronym>-Domain (Zone) heißt
	  example.org.</para>
      </listitem>

      <listitem>
	<para>Das <application>Kerberos</application>-Realm
	  heißt EXAMPLE.ORG.</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Benutzen Sie echte Domain-Namen, wenn Sie
	<application>Kerberos</application> einrichten.  Damit
	vermeiden Sie <acronym>DNS</acronym>-Probleme und stellen
	die Zusammenarbeit mit anderen
	<application>Kerberos</application>-Realms sicher.</para>
    </note>

    <sect2>
      <title>Geschichte</title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Geschichte</secondary>
      </indexterm>

      <para>Das <acronym>MIT</acronym> entwickelte
        <application>Kerberos</application>, um Sicherheitsprobleme
	auf dem Netzwerk zu lösen.  Das
	<application>Kerberos</application>-Protokoll verwendet
	starke Kryptographie, sodass ein Server die Identität
	eines Clients (der umgekehrte Vorgang ist auch möglich)
	über ein unsicheres Netzwerk feststellen kann.</para>

      <para>Der Begriff Kerberos wird sowohl für das Protokoll
	als auch für Programme verwendet, die
	<application>Kerberos</application> benutzen (wie
	<application>Kerberos</application>-Telnet).  Die aktuelle
	Protokollversion ist 5 und wird in
	<acronym>RFC</acronym>&nbsp;1510 beschrieben.</para>

      <para>Mehrere Implementierungen des Protokolls stehen frei
	zur Verfügung und decken viele Betriebssysteme ab.
	Das Massachusetts Institute of Technology
	(<acronym>MIT</acronym>), an dem <application>Kerberos</application>
	ursprünglich entwickelt wurde, entwickelt seine
	<application>Kerberos</application>-Version weiter.  In den
	<acronym>USA</acronym> wird diese Version häufig
	eingesetzt, unterlag aber Export-Beschränkungen,
	da sie in den <acronym>USA</acronym> entwickelt wurde.
	Die <acronym>MIT</acronym>-Version von
	<application>Kerberos</application> befindet sich im Port
	<filename role="package">security/krb5</filename>.
	Heimdal ist eine weitere Implementierung der Protokollversion 5.
	Sie wurde außerhalb der <acronym>USA</acronym> entwickelt
	und unterliegt daher keinen Export-Beschränkungen.
	Heimdal-<application>Kerberos</application> befindet sich
	im Port <filename role="package">security/heimdal</filename>
	und das Basissystem von &os; enthält eine minimale
	Installation von Heimdal.</para>

      <para>Um möglichst viele Benutzer anzusprechen, verwenden
	die folgenden Beispiele die in &os; enthaltene
	Heimdal-Distribution.</para>
    </sect2>

    <sect2>
      <title>Das Heimdal <acronym>KDC</acronym> einrichten</title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Key Distribution Center</secondary>
      </indexterm>

      <para><application>Kerberos</application> authentifiziert
	Benutzer an einer zentralen Stelle: dem Key Distribution
	Center (<acronym>KDC</acronym>).  Das <acronym>KDC</acronym>
	verteilt <firstterm>Tickets</firstterm>, mit denen ein
	Dienst die Identität eines Benutzers feststellen kann.
	Alle Mitglieder eines <application>Kerberos</application>-Realms
	vertrauen dem <acronym>KDC</acronym>, daher gelten für
	das <acronym>KDC</acronym> erhöhte
	Sicherheitsanforderungen.</para>

      <para>Obwohl das <acronym>KDC</acronym> wenig Ressourcen eines
	Rechners benötigt, sollte es wegen der
	Sicherheitsanforderungen auf einem separaten Rechner
	installiert werden.</para>

      <para>Das <acronym>KDC</acronym> wird in
        <filename>/etc/rc.conf</filename> wie folgt aktiviert:</para>

      <programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>

      <para>Danach wird die Konfigurationsdatei von
        <application>Kerberos</application>,
	<filename>/etc/krb5.conf</filename>, erstellt:</para>

      <programlisting>[libdefaults]
    default_realm = EXAMPLE.ORG
[realms]
    EXAMPLE.ORG = {
        kdc = kerberos.example.org
	admin_server = kerberos.example.org
    }
[domain_realm]
    .example.org = EXAMPLE.ORG</programlisting>

      <para>Diese Einstellungen setzen voraus, dass der voll
	qualifizierte Name des <acronym>KDC</acronym>s
	<hostid role="fqdn">kerberos.example.org</hostid> ist.
	Wenn Ihr <acronym>KDC</acronym> einen anderen Namen hat,
	müssen Sie in der DNS-Zone einen Alias-Eintrag (CNAME-Record)
	für das <acronym>KDC</acronym> hinzufügen.</para>

      <note>
	<para>Auf großen Netzwerken mit einem ordentlich
	  konfigurierten <acronym>BIND</acronym>
	  <acronym>DNS</acronym>-Server kann die Datei verkürzt
	  werden:</para>

        <programlisting>[libdefaults]
      default_realm = EXAMPLE.ORG</programlisting>

	<para>Die Zonendatei von <hostid role="fqdn">example.org</hostid>
	  muss dann die folgenden Zeilen enthalten:</para>

	<programlisting>_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
_kerberos           IN  TXT     EXAMPLE.ORG</programlisting>
      </note>

      <note>
	<para>Damit Klienten die
	  <application>Kerberos</application>-Dienste benutzen
	  können, muss die Datei <filename>/etc/krb5.conf</filename>
	  entweder die vollständige Konfiguration enthalten
	  oder eine minimale Konfiguration enthalten
	  <emphasis>und</emphasis> zusätzlich ein DNS-Server
	  richtig eingerichtet sein.</para>
      </note>

      <para>Im nächsten Schritt wird die
        <application>Kerberos</application>-Datenbank eingerichtet.
	Die Datenbank enthält die Schlüssel aller Prinzipale
	und ist mit einem Passwort geschützt.  Dieses Passwort
	brauchen Sie nicht zu behalten, da ein davon abgeleiteter
	Schlüssel in der Datei <filename>/var/heimdal/m-key</filename>
	gespeichert wird.  Den Schlüssel erstellen Sie, indem
	Sie das Programm <command>kstash</command> aufrufen und
	ein Passwort eingeben.</para>

      <para>Nachdem Sie den Schlüssel in
        <filename>/var/heimdal/m-key</filename> erstellt haben,
	können Sie die Datenbank mit dem Kommando
	<command>kadmin</command> initialisieren.  Verwenden
	Sie hierbei die Option <option>-l</option> (lokal).  Mit
	dieser Option wird die Datenbank lokal modifiziert.  Normal
	würde der <command>kadmind</command>-Dienst benutzt,
	der aber zu diesem Zeitpunkt noch nicht läuft.  An
	der Eingabeaufforderung von <command>kadmin</command>
	können Sie mit dem Kommando <command>init</command>
	die Datenbank des Realms einrichten.</para>

      <para>Zuletzt erstellen Sie mit dem Kommando <command>add</command>
	Ihren ersten Prinzipal.  Benutzen Sie die voreingestellten
	Optionen;  Sie können die Einstellungen später
	mit dem Kommando <command>modify</command> ändern.
	An der Eingabeaufforderung zeigt das Kommando
	<command>?</command> Hilfetexte an.</para>

      <para>Zusammengefasst wird die Datenbank wie folgt
	eingerichtet:</para>

      <screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput>xxxxxxxx</userinput>
Verifying password - Master key: <userinput>xxxxxxxx</userinput>

&prompt.root; <userinput>kadmin -l</userinput>
kadmin> <userinput>init EXAMPLE.ORG</userinput>
Realm max ticket life [unlimited]:
kadmin> <userinput>add tillman</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>

      <para>Jetzt kann das <acronym>KDC</acronym> gestartet werden.
	Führen Sie zum Start der Dienste die Kommandos
	<command>/etc/rc.d/kerberos start</command> und
	<command>/etc/rc.d/kadmind start</command> aus.  Obwohl
	zu diesem Zeitpunkt noch keine kerberisierten Dienste
	laufen, können Sie die Funktion des <acronym>KDC</acronym>s
	schon überprüfen.  Für den eben angelegten
	Benutzer können Sie sich vom <acronym>KDC</acronym>
	Tickets holen und diese Tickets anzeigen:</para>

      <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password:

&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE: <filename>/tmp/krb5cc_500</filename>
        Principal: tillman@EXAMPLE.ORG

  Issued           Expires          Principal
Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>

      <para>Dieses Ticket kann, nachdem Sie Ihre Arbeit beendet haben,
	zurückgezogen werden:</para>

      <screen>&prompt.user; <userinput>kdestroy</userinput></screen>
    </sect2>

    <sect2>
      <title><application>Kerberos</application>-Dienste
	einrichten</title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Dienste einrichten</secondary>
      </indexterm>

      <para>Alle Rechner, die kerberisierte Dienste anbieten,
	müssen eine Kopie der
	<application>Kerberos</application>-Konfigurationsdatei
	<filename>/etc/krb5.conf</filename> besitzen.  Sie
	können die Datei einfach vom <acronym>KDC</acronym>
	kopieren.</para>

      <para>Anschließend müssen Sie die Datei
	<filename>/etc/krb5.keytab</filename> erzeugen.  Im
	Gegensatz zu normalen Workstations benötigt jeder
	Server eine <filename>keytab</filename>.
	Diese Datei enthält den Schlüssel des
	Servers, mit dem sich der Server und das
	<acronym>KDC</acronym> gegenseitig authentifizieren
	können.  Die Datei muss sicher auf den Server
	transportiert werden (beispielsweise mit &man.scp.1;
	oder einer Diskette).  Unter keinen Umständen
	darf die Datei im Klartext, zum Beispiel mit
	<acronym>FTP</acronym>, übertragen werden,
	da sonst die Sicherheit des Servers gefährdet
	ist.</para>

      <para>Sie können die <filename>keytab</filename> auch
	mit dem Programm <command>kadmin</command> übertragen.
	Da Sie mit <command>kadmin</command> sowieso einen Host-Prinzipal
	für den Server einrichten müssen, ist das ganz
	praktisch.</para>

      <para>Sie müssen allerdings schon ein Ticket
	besitzen und berechtigt sein, <command>kadmin</command>
	auszuführen.  Die Berechtigung erhalten Sie durch
	einen Eintrag in der Zugriffskontrollliste
	<filename>kadmind.acl</filename>.  Weitere Informationen
	über Zugriffskontrolllisten erhalten Sie in den
	Heimdal-Info-Seiten (<command>info heimdal</command>)
	im Abschnitt <quote>Remote administration</quote>.  Wenn
	der Zugriff auf <command>kadmin</command> von entfernten
	Maschinen verboten ist, müssen Sie sich sicher
	auf dem <acronym>KDC</acronym> anmelden (lokale Konsole,
	&man.ssh.1; oder kerberisiertes Telnet) und die
	<filename>keytab</filename> lokal mit
	<command>kadmin -l</command> erzeugen.</para>

      <para>Nachdem Sie die Datei <filename>/etc/krb5.conf</filename>
	installiert haben, können Sie das Kommando
	<command>kadmin</command> benutzen.  An der Eingabeaufforderung
	von <command>kadmin</command> erstellt das Kommando
	<command>add --random-key</command> den Host-Prinzipal
	und das Kommando <command>ext</command> extrahiert den
	Schlüssel des Prinzipals in eine Datei:</para>

      <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin> <userinput>add --random-key host/myserver.example.org</userinput>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin> <userinput>ext host/myserver.example.org</userinput>
kadmin> <userinput>exit</userinput></screen>

      <para>Das Kommando <command>ext</command> (von
	<foreignphrase>extract</foreignphrase>) speichert den
	extrahierten Schlüssel in der Datei
	<filename>/etc/krb5.keytab</filename>.</para>

      <para>Wenn auf dem <acronym>KDC</acronym>, vielleicht aus
	Sicherheitsgründen, <command>kadmind</command>
	nicht läuft, können Sie das Kommando
	<command>kadmin</command> von entfernten Rechnern nicht
	benutzen.  In diesem Fall legen Sie den Host-Prinzipal
	<username>host/myserver.EXAMPLE.ORG</username> direkt
	auf dem <acronym>KDC</acronym> an.  Den Schlüssel
	extrahieren Sie in eine temporäre Datei (damit
	die Datei <filename>/etc/krb5.keytab</filename> nicht
	überschrieben wird):</para>

      <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin> <userinput>ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
kadmin> <userinput>exit</userinput></screen>

      <para>Anschließend müssen Sie die erzeugte
	<filename>example.keytab</filename> sicher auf den
	Server kopieren (mit <command>scp</command> oder
	mithilfe einer Diskette).  Geben Sie auf jeden Fall
	einen anderen Namen für die <filename>keytab</filename>
	an, weil sonst die <filename>keytab</filename> des
	<acronym>KDC</acronym>s überschrieben würde.</para>

      <para>Wegen der Datei <filename>krb5.conf</filename> kann
	der Server nun mit dem <acronym>KDC</acronym> kommunizieren
	und seine Identität mithilfe der Datei
	<filename>krb5.keytab</filename> nachweisen.  Jetzt
	können wir kerberisierte Dienste aktivieren.
	Für <command>telnet</command> muss die folgende
	Zeile in <filename>/etc/inetd.conf</filename> eingefügt
	werden:</para>

      <programlisting>telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user</programlisting>

      <para>Ausschlaggebend ist, dass die Authentifizierungs-Methode
	mit <option>-a</option> auf <literal>user</literal> gesetzt
	wird.  Weitere Details entnehmen Sie bitte der Hilfeseite
	&man.telnetd.8;.</para>

      <para>Nachdem sie die Zeile in <filename>/etc/inetd.conf</filename>
	eingefügt haben, starten Sie &man.inetd.8; mit
	dem Kommando <command>/etc/rc.d/inetd restart</command>
	durch.</para>
    </sect2>

    <sect2>
      <title><application>Kerberos</application>-Clients
	einrichten</title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Clients einrichten</secondary>
      </indexterm>

      <para>Ein Client lässt sich leicht einrichten.
	Sie benötigen nur die
	<application>Kerberos</application>-Konfigurationsdatei
	<filename>/etc/krb5.conf</filename>.  Kopieren Sie
	die Konfigurationsdatei einfach vom <acronym>KDC</acronym>
	auf den Client.</para>

      <para>Sie können jetzt mit <command>kinit</command>
        Tickets anfordern, mit <command>klist</command> Tickets
	anzeigen und mit <command>kdestroy</command> Tickets
	löschen.  Sie können mit
	<application>Kerberos</application>-Anwendungen kerberisierte
	Server ansprechen.  Wenn das nicht funktioniert,
	Sie aber Tickets anfordern können, hat wahrscheinlich
	der  kerberisierte Server ein Problem und nicht der
	Client oder das <acronym>KDC</acronym>.</para>

      <para>Wenn Sie eine Anwendung wie <command>telnet</command>
	testen, können Sie mit einem Paket-Sniffer
	(beispielsweise &man.tcpdump.1;) überprüfen,
	dass Passwörter verschlüsselt übertragen
	werden.  Probieren Sie auch die Option <option>-x</option>
	von <command>telnet</command>, die den gesamten Datenverkehr
	verschlüsselt (analog zu <command>ssh</command>).</para>

      <para>Zu Heimdal gehören noch weitere Anwendungen.
	Allerdings enthält das &os;-Basissystem nur eine
	minimale Heimdal-Installation mit nur einer
	kerberisierten Anwendung: <command>telnet</command>.</para>

      <para>Der Heimdal-Port enthält noch mehr kerberisierte
	Anwendungen wie <command>ftp</command>, <command>rsh</command>,
	<command>rcp</command> und <command>rlogin</command>.
	Der <acronym>MIT</acronym>-Port enthält ebenfalls
	weitere kerberisierte Anwendungen.</para>
    </sect2>

    <sect2>
      <title><filename>.k5login</filename> und
	<filename>.k5users</filename></title>

      <indexterm>
	<primary><filename>.k5login</filename></primary>
      </indexterm>
      <indexterm>
	<primary><filename>.k5users</filename></primary>
      </indexterm>

      <para>Normalerweise wird ein
	<application>Kerberos</application>-Prinzipal wie
	<username>tillman@EXAMPLE.ORG</username> auf ein lokales
	Benutzerkonto, beispielsweise <username>tillman</username>,
	abgebildet.  Daher benötigen Client-Anwendungen (zum
	Beispiel <command>telnet</command>) keinen Benutzernamen.</para>

      <para>Manchmal wird aber Zugriff auf ein lokales Benutzerkonto
	benötigt, zu dem es keinen passenden
	<application>Kerberos</application>-Prinzipal gibt.
	Der Prinzipal <username>tillman@EXAMPLE.ORG</username>
	bräuchte beispielsweise Zugriff auf das Konto
	<username>webdevelopers</username>.  Ebenso könnten
	andere Prinzipale auf dieses Konto zugreifen wollen.</para>

      <para>Die Dateien <filename>.k5login</filename> und
	<filename>.k5users</filename> im Heimatverzeichnis eines
	Benutzerkontos gewähren Zugriffe ähnlich wie
	die Dateien <filename>.hosts</filename> und
	<filename>.rhosts</filename>.  Um den Prinzipalen
	<username>tillman@example.org</username> und
	<username>jdoe@example.org</username> auf das Konto
	<username>webdevelopers</username> zu geben, wird im
	Heimatverzeichnis von <username>webdevelopers</username>
	die Datei <filename>.k5login</filename> mit folgendem
	Inhalt angelegt:</para>

      <screen>tillman@example.org
jdoe@example.org</screen>

      <para>Die angegebenen Prinzipale haben nun ohne ein gemeinsames
	Passwort Zugriff auf das Konto.</para>

      <para>Einzelheiten entnehmen Sie bitte den Hilfeseiten
	zu diesen Dateien.  Die Datei <filename>.k5users</filename>
	wird in der Hilfeseite des Kommandos <command>ksu</command>
	beschrieben.</para>
    </sect2>

    <sect2>
      <title>Tipps und Fehlersuche</title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Fehlersuche</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para>Wenn Sie den Heimdal-Port oder den
	    <acronym>MIT</acronym>-Port benutzen, muss in der
	    Umgebungsvariable <envar>PATH</envar> der Pfad zu
	    den Programmen des Ports vor dem Pfad zu den
	    <application>Kerberos</application>-Programmen des Systems
	    stehen.</para>
	</listitem>

	<listitem>
	  <para>Sind die Uhrzeiten der Systeme synchronisiert?
	    Wenn nicht, schlägt vielleicht die Authentifizierung
	    fehl.  <xref linkend="network-ntp"/> beschreibt, wie
	    Sie mithilfe von <acronym>NTP</acronym> die Uhrzeiten
	    synchronisieren.</para>
	</listitem>

	<listitem>
	  <para>Die <acronym>MIT</acronym>- und Heimdal-Systeme
	    arbeiten bis auf <command>kadmin</command> gut zusammen.
	    Für <command>kadmin</command> wurde das Protokoll
	    nicht normiert.</para>
	</listitem>

	<listitem>
	  <para>Wenn Sie den Namen eines Rechners ändern,
	    müssen Sie auch den <username>host/</username>-Prinzipal
	    ändern und die Datei <filename>keytab</filename>
	    aktualisieren.  Dies betrifft auch spezielle Einträge
	    wie den Prinzipal für Apaches <filename
	      role="package">www/mod_auth_kerb</filename>.</para>
	</listitem>

	<listitem>
	  <para>Die Rechnernamen müssen vor- und
	    rückwärts aufgelöst werden (im
	    <acronym>DNS</acronym> oder in
	    <filename>/etc/hosts</filename>).
	    <acronym>CNAME</acronym>-Einträge im
	    <acronym>DNS</acronym> funktionieren, aber die
	    entsprechenden A- und PTR-Einträge müssen
	    vorhanden und richtig sein.  Wenn sich Namen nicht
	    auflösen lassen, ist die Fehlermeldung nicht
	    gerade selbstsprechend: <errorname>Kerberos5 refuses
	      authentication because Read req
	      failed: Key table entry not found</errorname>.</para>
	</listitem>

	<listitem>
	  <para>Einige Betriebssysteme installieren
	    <command>ksu</command> mit falschen Zugriffsrechten;
	    es fehlt das Set-UID-Bit für <username>root</username>.
	    Das mag aus Sicherheitsgründen richtig sein,
	    doch funktioniert <command>ksu</command> dann nicht.
	    Dies ist kein Fehler des <acronym>KDC</acronym>s.</para>
	</listitem>

	<listitem>
	  <para>Wenn Sie für einen Prinzipal unter
	    <acronym>MIT</acronym>-<application>Kerberos</application>
	    Tickets mit einer längeren Gültigkeit als
	    der vorgegebenen zehn Stunden einrichten wollen,
	    müssen Sie zwei Sachen ändern.  Benutzen
	    Sie das <command>modify_principal</command> von
	    <command>kadmin</command>, um die maximale
	    Gültigkeitsdauer für den Prinzipal selbst
	    und den Prinzipal <username>krbtgt</username>
	    zu erhöhen.</para>
	</listitem>

	<listitem>
	  <para>Mit einem Packet-Sniffer können Sie feststellen,
	    dass Sie sofort nach dem Aufruf von <command>kinit</command>
	    eine Antwort vom <acronym>KDC</acronym>
	    bekommen &ndash; noch bevor Sie überhaupt ein
	    Passwort eingegeben haben!  Das ist in Ordnung:
	    Das <acronym>KDC</acronym> händigt
	    ein Ticket-Granting-Ticket (<acronym>TGT</acronym>)
	    auf Anfrage aus, da es durch einen vom Passwort
	    des Benutzers abgeleiteten Schlüssel
	    geschützt ist.  Wenn das Passwort
	    eingegeben wird, wird es nicht zum <acronym>KDC</acronym>
	    gesendet, sondern zum Entschlüsseln der
	    Antwort des <acronym>KDC</acronym>s benutzt, die
	    <command>kinit</command> schon erhalten hat.
	    Wird die Antwort erfolgreich entschlüsselt,
	    erhält der Benutzer einen Sitzungs-Schlüssel
	    für die künftige verschlüsselte
	    Kommunikation mit dem <acronym>KDC</acronym> und das
	    Ticket-Granting-Ticket.  Das Ticket-Granting-Ticket
	    wiederum ist mit dem Schlüssel des <acronym>KDC</acronym>s
	    verschlüsselt.  Diese Verschlüsselung ist
	    für den Benutzer völlig transparent und
	    erlaubt dem <acronym>KDC</acronym>,
	    die Echtheit jedes einzelnen <acronym>TGT</acronym>
	    zu prüfen.</para>
	</listitem>

	<listitem>
	  <para>Wenn Sie <application>OpenSSH</application> verwenden
	    und Tickets mir einer langen Gültigkeit
	    (beispielsweise einer Woche) benutzen, setzen Sie die Option
	    <option>TicketCleanup</option> in der Datei
	    <filename>sshd_config</filename> auf <literal>no</literal>.
	    Ansonsten werden Ihre Tickets gelöscht, wenn Sie
	    sich abmelden.</para>
	</listitem>

	<listitem>
	  <para>Host-Prinzipale können ebenfalls Tickets mit
	    längerer Gültigkeit besitzen.  Wenn der
	    Prinzipal eines Benutzers über ein Ticket verfügt,
	    das eine Woche gültig ist, das Ticket des
	    Host-Prinzipals aber nur neun Stunden gültig ist,
	    funktioniert der Ticket-Cache nicht wie erwartet.
	    Im Cache befindet sich dann ein abgelaufenes Ticket
	    des Host-Prinzipals.</para>
	</listitem>

	<listitem>
	  <para>Wenn Sie mit <filename>krb5.dict</filename> die
	    Verwendung schlechter Passwörter verhindern wollen,
	    geht das nur mit Prinzipalen, denen eine Passwort-Policy
	    zugewiesen wurde.  Die Hilfeseite von
	    <command>kadmind</command> beschreibt kurz, wie
	    <filename>krb5.dict</filename> verwendet wird.  Das
	    Format von <filename>krb5.dict</filename> ist
	    einfach:  Die Datei enthält pro Zeile ein Wort.
	    Sie können daher einen symbolischen Link auf
	    <filename>/usr/share/dict/words</filename> erstellen.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <title>Unterschiede zum <acronym>MIT</acronym>-Port</title>

      <para>Der Hauptunterschied zwischen
	<acronym>MIT</acronym>-<application>Kerberos</application>
	und Heimdal-<application>Kerberos</application>
	ist das Kommando <command>kadmin</command>.
	Die Befehlssätze des Kommandos (obwohl funktional
	gleichwertig) und das verwendete
	Protokoll unterscheiden sich in beiden Varianten.
	Das <acronym>KDC</acronym> lässt sich nur mit
	dem <command>kadmin</command> Kommando der passenden
	<application>Kerberos</application>-Variante verwalten.</para>

      <para>Für dieselbe Funktion können auch die
	Client-Anwendungen leicht geänderte Kommandozeilenoptionen
	besitzen.  Folgen Sie bitte der Anleitung auf der
	<application>Kerberos</application>-Seite
	(<ulink url="http://web.mit.edu/Kerberos/www/"></ulink>) des
	<acronym>MIT</acronym>s.  Achten Sie besonders auf den
	Suchpfad für Anwendungen.  Der <acronym>MIT</acronym>-Port
	wird standardmäßig in
	<filename class="directory">/usr/local/</filename>
	installiert.  Wenn die Umgebungsvariable <envar>PATH</envar>
	zuerst die Systemverzeichnisse enthält, werden die
	Systemprogramme anstelle der <acronym>MIT</acronym>-Programme
	ausgeführt.</para>

      <note>
	<para>Wenn Sie den <acronym>MIT</acronym>-Port
	  <filename role="package">security/krb5</filename> verwenden,
	  erscheint bei der Anmeldung mit <command>telnetd</command>
	  und <command>klogind</command> die Fehlermeldung
	  <errorname>incorrect permissions on cache file</errorname>.
	  Lesen Sie dazu bitte die im Port enthaltene Datei
	  <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>.
	  Wichtig ist, dass zur Authentifizierung die Binärdatei
	  <command>login.krb5</command> verwendet wird, die
	  für durchgereichte Berechtigungen die Eigentümer
	  korrekt ändert.</para>
      </note>

      <para>In der Datei <filename>rc.conf</filename> müssen
	folgende Zeilen aufgenommen werden:</para>

      <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
kadmind5_server="/usr/local/sbin/kadmind"
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>

      <para>Diese Zeilen sind notwendig, weil die Anwendungen
	von <acronym>MIT</acronym>-Kerberos Binärdateien
	unterhalb von <filename
	class="directory">/usr/local</filename> installieren.</para>
    </sect2>

    <sect2>
      <title>Beschränkungen von
	<application>Kerberos</application></title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>Beschränkungen</secondary>
      </indexterm>

      <sect3>
	<title><application>Kerberos</application> muss ganzheitlich
	  verwendet werden</title>

	<para>Jeder über das Netzwerk angebotetene Dienst
	  muss mit <application>Kerberos</application>
	  zusammenarbeiten oder auf anderen Wegen gegen Angriffe
	  aus dem Netzwerk geschützt sein.  Andernfalls
	  können Berechtigungen gestohlen und wiederverwendet
	  werden.  Es ist beispielsweise nicht sinnvoll, für
	  Anmeldungen mit <command>rsh</command> und
	  <command>telnet</command> <application>Kerberos</application>
	  zu benutzen, dagegen aber <acronym>POP3</acronym>-Zugriff
	  auf einen Mail-Server zu erlauben, da <acronym>POP3</acronym>
	  Passwörter im Klartext versendet.</para>
      </sect3>

      <sect3>
	<title><application>Kerberos</application> ist für
	  Einbenutzer-Systeme gedacht</title>

	<para>In Mehrbenutzer-Umgebungen ist
	  <application>Kerberos</application> unsicherer als in
	  Einbenutzer-Umgebungen, da die Tickets im für alle
	  lesbaren Verzeichnis <filename class="directory">/tmp</filename>
	  gespeichert werden.  Wenn ein Rechner von mehreren
	  Benutzern verwendet wird, ist es möglich, dass
	  Tickets gestohlen werden.</para>

	<para>Dieses Problem können Sie lösen, indem Sie mit
	  der Kommandozeilenoption <option>-c</option> oder besser
	  mit der Umgebungsvariablen <envar>KRB5CCNAME</envar> einen
	  Ort für die Tickets vorgeben.  Diese Vorgehensweise
	  wird leider selten benutzt.  Es reicht, die Tickets
	  im Heimatverzeichnis eines Benutzers zu speichern und
	  mit Zugriffsrechten zu schützen.</para>
      </sect3>

      <sect3>
	<title>Das <acronym>KDC</acronym> ist verwundbar</title>

	<para>Das <acronym>KDC</acronym> muss genauso abgesichert
	  werden wie die auf ihm befindliche Passwort-Datenbank.
	  Auf dem <acronym>KDC</acronym> dürfen keine anderen
	  Dienste laufen und der Rechner sollte physikalisch
	  gesichert sein.  Die Gefahr ist groß, da
	  <application>Kerberos</application> alle Passwörter
	  mit einem Schlüssel, dem Haupt-Schlüssel,
	  verschlüsselt.  Der Haupt-Schlüssel wiederum
	  wird in einer Datei auf dem <acronym>KDC</acronym>
	  gespeichert.</para>

	<para>Ein kompromittierter Haupt-Schlüssel ist nicht
	  ganz so schlimm wie allgemein angenommen.  Der
	  Haupt-Schlüssel wird nur zum Verschlüsseln
	  der Passwort-Datenbank und zum Initialisieren des
	  Zufallsgenerators verwendet.  Solange der Zugriff
	  auf das <acronym>KDC</acronym> abgesichert ist, kann
	  ein Angreifer wenig mit dem Haupt-Schlüssel
	  anfangen.</para>

	<para>Wenn das <acronym>KDC</acronym> nicht zur Verfügung
	  steht, vielleicht wegen eines Denial-of-Service Angriffs
	  oder wegen eines Netzwerkproblems, ist eine Authentifizierung
	  unmöglich.  Damit können die Netzwerk-Dienste
	  nicht benutzt werden; das <acronym>KDC</acronym> ist
	  also ein optimales Ziel für einen Denial-of-Service
	  Angriff.  Sie können diesem Angriff ausweichen,
	  indem Sie mehrere <acronym>KDC</acronym>s (einen Master
	  und einen oder mehrere Slaves) verwenden.  Der Rückfall
	  auf ein sekundäres <acronym>KDC</acronym> oder
	  eine andere Authentifizierungs-Methode (dazu ist
	  <acronym>PAM</acronym> bestens geeignet) muss sorgfältig
	  eingerichtet werden.</para>
      </sect3>

      <sect3>
	<title>Mängel von
	  <application>Kerberos</application></title>

	<para>Mit <application>Kerberos</application> können
	  sich Benutzer, Rechner und Dienste gegenseitig
	  authentifizieren.  Allerdings existiert kein Mechanismus,
	  der das <acronym>KDC</acronym> gegenüber Benutzern,
	  Rechnern oder Diensten authentifiziert.  Ein verändertes
	  <command>kinit</command> könnte beispielsweise alle
	  Benutzernamen und Passwörter abfangen.  Die von
	  veränderten Programmen ausgehende Gefahr können
	  Sie lindern, indem Sie die Integrität von Dateien
	  mit Werkzeugen wie
	  <filename role="package">security/tripwire</filename>
	  prüfen.</para>
      </sect3>
    </sect2>

    <sect2>
      <title>Weiterführende Dokumentation</title>
      <indexterm>
	<primary>Kerberos5</primary>
	<secondary>weiterführende Dokumentation</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para><ulink
	    url="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html">The
            Kerberos FAQ</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://web.mit.edu/Kerberos/www/dialogue.html">Designing
	    an Authentication System: a Dialogue in Four
	    Scenes</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC 1510,
	    The <application>Kerberos</application> Network
	    Authentication Service (V5)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://web.mit.edu/Kerberos/www/"><acronym>MIT</acronym>
	    <application>Kerberos</application>-Seite</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://www.pdc.kth.se/heimdal/">Heimdal
	    <application>Kerberos</application>-Seite</ulink></para>
	</listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 id="openssl">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>OpenSSL</title>
    <indexterm>
      <primary>Sicherheit</primary>
      <secondary>OpenSSL</secondary>
    </indexterm>
    <indexterm><primary>OpenSSL</primary></indexterm>

    <para>Es wird oft übersehen, dass
      <application>OpenSSL</application> Teil des &os;-Basissystems
      ist.  <application>OpenSSL</application> bietet eine
      verschlüsselte Transportschicht oberhalb der
      normalen Kommunikationsschicht und kann daher zusammen
      mit vielen Netzdiensten benutzt werden.</para>

    <para>Anwendungsbeispiele für <application>OpenSSL</application>
      sind die verschlüsselte Authentifizierung von
      E-Mail-Clients oder Web-Transaktionen wie das Bezahlen mit
      einer Kreditkarte.  <application>OpenSSL</application>
      kann während des Baus in viele Ports, wie
      <filename role="package">www/apache22</filename> und
      <filename role="package">mail/claws-mail</filename>,
      integriert werden.</para>

    <note>
      <para>Ist beim Aufruf von <command>make</command> die
	Variable <makevar>WITH_OPENSSL_BASE</makevar> nicht
	explizit auf <literal>yes</literal> gesetzt, baut
	die Ports-Sammlung meist den Port
	<filename role="package">security/openssl</filename>.</para>
    </note>

    <para>Das <application>OpenSSL</application> von &os; stellt
      die Protokolle Secure Sockets Layer v2/v3 (SSLv2/SSLv3) und
      Transport Layer Security v1 (TLSv1) zur Verfügung.
      Die <application>OpenSSL</application>-Bibliotheken stellen
      kryptographische Funktionen bereit.</para>

    <note>
      <para>Mit <application>OpenSSL</application> kann der
	<acronym>IDEA</acronym>-Algorithmus verwendet werden,
	wegen Patenten in den USA ist der Algorithmus in der
	Voreinstellung allerdings deaktiviert.  Wenn Sie die
	<acronym>IDEA</acronym>-Lizenz akzeptieren, können
	Sie den <acronym>IDEA</acronym>-Algorithmus aktivieren,
	indem Sie die Variable <makevar>MAKE_IDEA</makevar>
	in <filename>make.conf</filename> setzen.</para>
    </note>

    <para>Meist wird <application>OpenSSL</application> eingesetzt,
      um Zertifikate für Anwendungen bereitzustellen.  Die
      Zertifikate stellen die Identität einer Firma oder
      eines Einzelnen sicher.  Wenn ein Zertifikat nicht von
      einer Zertifizierungsstelle (<foreignphrase>Certificate
        Authority</foreignphrase>, <acronym>CA</acronym>)
      gegengezeichnet wurde, erhalten Sie normalerweise eine
      Warnung.  Eine Zertifizierungsstelle ist eine Firma
      wie <ulink url="http://www.verisign.com/">VeriSign</ulink>,
      die Zertifikate von Personen oder Firmen
      gegenzeichnet und damit die Korrektheit der Zertifikate
      bestätigt.  Diese Prozedur kostet Geld, ist aber
      keine Voraussetzung für den Einsatz von Zertifikaten,
      beruhigt aber sicherheitsbewusste Benutzer.</para>
      <!-- XXX paranoid users ?? -->

    <sect2>
      <title>Zertifikate erzeugen</title>

      <indexterm>
	<primary>OpenSSL</primary>
	<secondary>Zertifikate erzeugen</secondary>
      </indexterm>

      <para>Ein Zertifikat erzeugen Sie mit dem nachstehenden
	Kommando:</para>

      <screen>&prompt.root; <userinput>openssl req -new -nodes -out req.pem -keyout cert.pem</userinput>
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:<userinput><replaceable>US</replaceable></userinput>
State or Province Name (full name) [Some-State]:<userinput><replaceable>PA</replaceable></userinput>
Locality Name (eg, city) []:<userinput><replaceable>Pittsburgh</replaceable></userinput>
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput><replaceable>My Company</replaceable></userinput>
Organizational Unit Name (eg, section) []:<userinput><replaceable>Systems Administrator</replaceable></userinput>
Common Name (eg, YOUR name) []:<userinput><replaceable>localhost.example.org</replaceable></userinput>
Email Address []:<userinput><replaceable>trhodes@FreeBSD.org</replaceable></userinput>

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<userinput><replaceable>SOME PASSWORD</replaceable></userinput>
An optional company name []:<userinput><replaceable>Another Name</replaceable></userinput></screen>

      <para>Beachten Sie bitte, dass die Eingabe bei
	<quote>Common Name</quote> ein gültiger Domain-Name
	sein muss.  Eine andere Eingabe erzeugt ein unbrauchbares
	Zertifikat.  Das Zertifikat kann mit einer
	Gültigkeitsdauer und anderen
	Verschlüsselungsalgorithmen erzeugt werden.
	Die Hilfeseite &man.openssl.1; beschreibt die zur
	Verfügung stehenden Optionen.</para>

      <para>Das Verzeichnis, in dem Sie den letzten Befehl ausgeführt
	haben, enthält nun zwei Dateien:  Die Anforderung für
	ein neues Zertifikat wurde in <filename>req.pem</filename>
	gespeichert.  Diese Datei können Sie an eine
	Zertifizierungsstelle senden, wo Ihre Angaben geprüft werden.
	Nach erfolgreicher Prüfung wird das Zertifikat an Sie
	zurückgesandt.  Die zweite Datei, <filename>cert.pem</filename>,
	enthält den privaten Schlüssel für Ihr Zertifikat
	und darf auch keine Fall in fremde Hände geraten, da ein
	Angreifer sonst in der Lage ist, anderen Personen oder Rechnern
	vorzugaukeln, dass es sich bei ihm um Sie handelt.</para>

      <para>Wenn Sie keine Signatur einer Zertifizierungsstelle
	benötigen, können Sie ein selbst-signiertes
	Zertifikat erstellen.  Erzeugen Sie dazu zuerst einen
	<acronym>RSA</acronym>-Schlüssel:</para>

      <screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out <filename>myRSA.key</filename> 1024</userinput></screen>

      <para>Erzeugen Sie dann den <acronym>CA</acronym>-Schlüssel:</para>

      <screen>&prompt.root; <userinput>openssl gendsa -des3 -out <filename>myca.key</filename> <filename>myRSA.key</filename></userinput></screen>

      <para>Erstellen Sie mit diesem Schlüssel das
        Zertifikat:</para>

      <screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key <filename>myca.key</filename> -out <filename>new.crt</filename></userinput></screen>

      <para>Zwei neue Dateien befinden sich nun im Verzeichnis:
	Der Schlüssel der Zertifizierungsstelle
	<filename>myca.key</filename> und das Zertifikat selbst,
	<filename>new.crt</filename>.  Sie sollten in einem
	Verzeichnis, vorzugsweise unterhalb von
	<filename class="directory">/etc</filename> abgelegt
	werden, das nur von <username>root</username> lesbar
	ist.  Setzen Sie die Zugriffsrechte der Dateien mit
	<command>chmod</command> auf <literal>0700</literal>.</para>
    </sect2>

    <sect2>
      <title>Beispiel für Zertifikate</title>

      <para>Was fangen Sie mit einem Zertifikat an?  Sie
	könnten damit beispielsweise die Verbindungen zu
	<application>Sendmail</application> verschlüsseln.
	Dies würde die Klartext-Authentifizierung
	für Benutzer des lokalen <acronym>MTA</acronym>
	überflüssig machen.</para>

      <note>
	<para>Das ist nicht unbedingt die beste Lösung,
	  da einige <acronym>MUA</acronym>s Warnungen ausgeben,
	  wenn ein Zertifikat nicht lokal installiert ist.
	  Die Installation von Zertifikaten wird in der
	  Dokumentation der <acronym>MUA</acronym>s
	  beschrieben.</para>
      </note>

      <para>Ergänzen Sie die Konfigurationsdatei von
	<application>sendmail</application> (<filename>.mc</filename>)
	um die nachstehenden Zeilen:</para>

      <programlisting>dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/new.crt')dnl
define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting>

      <para>Im Verzeichnis <filename class="directory">/etc/certs</filename>
        befindet sich der Schlüssel und das Zertifikat.  Bauen Sie danach
        im Verzeichnis <filename class="directory">/etc/mail</filename>
	mit dem Kommando <command>make
	<maketarget>install</maketarget></command> die
	<filename>.cf</filename>-Datei und starten Sie anschließend
	<application>sendmail</application> mit <command>make
	<maketarget>restart</maketarget></command> neu.</para>

      <para>Wenn alles gut ging, erscheinen keine Fehlermeldungen
	in der Datei <filename>/var/log/maillog</filename> und
	Sie sehen <application>sendmail</application> in der
	Prozessliste.</para>

      <para>Testen Sie nun den Mailserver mit dem Kommando
	&man.telnet.1;:</para>

      <screen>&prompt.root; <userinput>telnet <replaceable>example.com</replaceable> 25</userinput>
Trying 192.0.34.166...
Connected to <hostid role="fqdn">example.com</hostid>.
Escape character is '^]'.
220 <hostid role="fqdn">example.com</hostid> ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
<userinput>ehlo <replaceable>example.com</replaceable></userinput>
250-example.com Hello example.com [192.0.34.166], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
<userinput>quit</userinput>
221 2.0.0 <hostid role="fqdn">example.com</hostid> closing connection
Connection closed by foreign host.</screen>

      <para>Wenn in einer Zeile <literal>STARTTLS</literal>
	erscheint, hat alles funktioniert.</para>
    </sect2>
  </sect1>

  <sect1 id="ipsec">
    <sect1info>
      <authorgroup>
        <author>
	  <firstname>Nik</firstname>
	  <surname>Clayton</surname>
	  <affiliation>
	    <address><email>nik@FreeBSD.org</email></address>
          </affiliation>
          <contrib>Geschrieben von </contrib>
        </author>
      </authorgroup>
    </sect1info>

    <title>VPNs mit IPsec</title>

    <indexterm>
      <primary>IPsec</primary>
    </indexterm>

    <para>Dieser Abschnitt beschreibt, wie Sie mit &os;-Gateways
      ein <firstterm>Virtual-Private-Network</firstterm>
      (<acronym>VPN</acronym>) einrichten.  Als Beispiel wird ein
      <acronym>VPN</acronym> zwischen zwei Netzen verwendet,
      die über das Internet miteinander verbunden sind.</para>

    <sect2>
      <sect2info>
        <authorgroup>
          <author>
            <firstname>Hiten M.</firstname>
            <surname>Pandya</surname>
	    <affiliation>
	      <address><email>hmp@FreeBSD.org</email></address>
	    </affiliation>
	    <contrib>Geschrieben von </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>IPsec Grundlagen</title>

      <para>Dieser Abschnitt zeigt Ihnen, wie Sie IPsec einrichten.  Um IPsec
        einzurichten, sollten Sie einen neuen Kernel bauen können (siehe
	<xref linkend="kernelconfig"/>).</para>

      <para>IPsec ist ein Protokoll, das auf dem Internet-Protokoll
	(IP) aufbaut.  Mit IPsec können mehrere Systeme
	geschützt miteinander kommunizieren.  Das in
	&os; realisierte IPsec-Protokoll baut auf der <ulink
	url="http://www.kame.net/">KAME-Implementierung</ulink>
	auf und unterstützt sowohl IPv4 als auch IPv6.</para>

      <indexterm>
	<primary>IPsec</primary>
	<secondary>ESP</secondary>
      </indexterm>

      <indexterm>
	<primary>IPsec</primary>
	<secondary>AH</secondary>
      </indexterm>

      <para>IPsec besteht wiederum aus zwei Protokollen:</para>

      <itemizedlist>
        <listitem>
          <para><emphasis>Encapsulated Security Payload (ESP)</emphasis>
	    verschlüsselt IP-Pakete mit einem symmetrischen Verfahren
	    (beispielsweise Blowfish oder 3DES).  Damit werden
	    die Pakete vor Manipulationen Dritter geschützt.</para>
        </listitem>

        <listitem>
          <para>Der <emphasis>Authentication Header (AH)</emphasis>
	    enthät eine kryptographische Prüfsumme,
	    die sicher stellt, dass ein IP-Paket nicht verändert
	    wurde.  Der Authentication-Header folgt nach dem
	    normalen IP-Header und erlaubt dem Empfänger
	    eines IP-Paketes, dessen Integrität zu
	    prüfen.</para>
        </listitem>
      </itemizedlist>

      <para><acronym>ESP</acronym> und <acronym>AH</acronym>
	können, je nach Situation, zusammen oder einzeln
	verwendet werden.</para>

      <indexterm>
        <primary>VPN</primary>
      </indexterm>

      <indexterm>
        <primary>Virtual Private Network</primary>
        <see>VPN</see>
      </indexterm>

      <para>IPsec kann in zwei Modi betrieben werden:  Der
	<firstterm>Transport-Modus</firstterm> verschlüsselt
	die Daten zwischen zwei Systemen.  Der
	<firstterm>Tunnel-Modus</firstterm> verbindet zwei
	Subnetze miteinander.  Durch einen Tunnel können
	dann beispielsweise verschlüsselte Daten übertragen
	werden.  Ein Tunnel wird auch als Virtual-Private-Network (VPN)
	bezeichnet.  Detaillierte Informationen über
	das IPsec-Subsystem von &os; enthält die
	Hilfeseite &man.ipsec.4;.</para>

      <para>Die folgenden Optionen in der Kernelkonfiguration
	aktivieren IPsec:</para>

      <indexterm>
        <primary>Kerneloption</primary>
        <secondary>IPSEC</secondary>
      </indexterm>

      <screen>options   IPSEC        #IP security
device    crypto</screen>

      <indexterm>
        <primary>Kerneloption</primary>
        <secondary>IPSEC_DEBUG</secondary>
      </indexterm>

      <para>Wenn Sie zur Fehlersuche im IPsec-Subsystem
	Unterstützung wünschen, sollten Sie die
	folgende Option ebenfalls aktivieren:</para>

      <screen>options   IPSEC_DEBUG  #debug for IP security</screen>
    </sect2>

    <sect2>
      <title>Was ist ein VPN?</title>

      <para>Es gibt keinen Standard, der festlegt, was ein
	Virtual-Private-Network ist.  VPNs können mit
	verschiedenen Techniken, die jeweils eigene Vor- und
	Nachteile besitzen, implementiert werden.
	Dieser Abschnitt stellt eine Möglichkeit vor,
	ein VPN aufzubauen.</para>
    </sect2>

    <sect2>
      <title>Das Szenario: Zwei Netzwerke, ein Heim- und ein
	Firmennetzwerk.  Beide sind mit dem Internet verbunden und
	verhalten sich dank <acronym>VPN</acronym> wie ein Netzwerk.</title>

      <indexterm>
        <primary>VPN</primary>
        <secondary>einrichten</secondary>
      </indexterm>

      <para>Dieses Szenario hat die folgenden Vorausetzungen:</para>

      <itemizedlist>
        <listitem>
	  <para>Es müssen zwei Netzwerke vorhanden sein.</para>
        </listitem>

        <listitem>
	  <para>Beide Netzwerke müssen intern IP benutzen.</para>
        </listitem>

        <listitem>
	  <para>Beide Netzwerke sind über ein &os;-Gateway
	    mit dem Internet verbunden.</para>
        </listitem>

        <listitem>
	  <para>Der Gateway jedes Netzwerks besitzt mindestens
	    eine öffentliche IP-Adresse.</para>
        </listitem>

        <listitem>
          <para>Die intern verwendeten IP-Adressen können
	    private oder öffentliche Adressen sein.
	    Sie dürfen sich nicht überlappen; zum Beispiel:
	    nicht beide sollten <hostid role="ipaddr">192.168.1.x</hostid>
	    benutzen.</para>
        </listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <sect2info>
        <authorgroup>
          <author>
            <firstname>Tom</firstname>
            <surname>Rhodes</surname>
            <affiliation>
              <address><email>trhodes@FreeBSD.org</email></address>
            </affiliation>
            <contrib>Geschrieben von </contrib>
          </author>
        </authorgroup>
      </sect2info>

      <title>Konfiguration von IPsec in &os;</title>

      <para>Als erstes muss <filename
        role="package">security/ipsec-tools</filename> aus
	der Ports-Sammlung installiert werden.  Dieses Softwarepaket
	Dritter enthält einige Anwendungen, die ihnen bei der
	Konfiguration von IPsec helfen.</para>

      <para>Als nächstes müssen zwei &man.gif.4;-Pseudogeräte
        angelegt werden, um die Pakete zu tunneln und dafür zu sorgen,
        dass beide Netzwerke richtig miteinander kommunizieren können.
        Geben Sie als Benutzer <username>root</username> die folgenden Befehle
        ein: Austausch der <replaceable>internen</replaceable> und
        <replaceable>externen</replaceable> Werte durch die realen internen
        und externen Gateways:</para>

      <screen>&prompt.root; <userinput>ifconfig gif0 create</userinput></screen>
      <screen>&prompt.root; <userinput>ifconfig gif0 <replaceable>internal1 internal2</replaceable></userinput></screen>
      <screen>&prompt.root; <userinput>ifconfig gif0 tunnel <replaceable>external1 external2</replaceable></userinput></screen>

      <para>Beispiel: Die öffentliche <acronym>IP</acronym>-Adresse
	des Firmennetzwerkes <acronym>(LAN)</acronym> ist:
        <hostid role="ipaddr">172.16.5.4</hostid> mit einer internen
        <acronym>IP</acronym>-Adresse von
        <hostid role="ipaddr">10.246.38.1</hostid>.  Das Heimnetzwerk
        <acronym>(LAN)</acronym> hat die öffentliche
	<acronym>IP</acronym>-Adresse
        <hostid role="ipaddr">192.168.1.12</hostid> mit der internen
        privaten <acronym>IP</acronym>-Adresse
        <hostid role="ipaddr">10.0.0.5</hostid>.</para>

      <para>Dies mag verwirrend erscheinen, schauen Sie sich deshalb
	das folgende Beispiel aus dem &man.ifconfig.8;-Befehl an:</para>

      <programlisting>Gateway 1:

gif0: flags=8051 mtu 1280
tunnel inet 172.16.5.4 --&gt; 192.168.1.12
inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6
inet 10.246.38.1 --&gt; 10.0.0.5 netmask 0xffffff00

Gateway 2:

gif0: flags=8051 mtu 1280
tunnel inet 192.168.1.12 --&gt; 172.16.5.4
inet 10.0.0.5 --&gt; 10.246.38.1 netmask 0xffffff00
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4</programlisting>

      <para>Wenn Sie fertig sind, sollten beide privaten
	<acronym>IP</acronym>s mit dem &man.ping.8; Befehl, wie die folgende
	Darstellung zeigt, erreichbar sein:</para>

      <programlisting>priv-net# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms
--- 10.0.0.5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms

corp-net# ping 10.246.38.1
PING 10.246.38.1 (10.246.38.1): 56 data bytes
64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms
64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms
64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms
64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms
64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms
--- 10.246.38.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms</programlisting>

      <para>Wie erwartet, können nun beiden Seiten
        <acronym>ICMP</acronym>-Pakete von ihren privaten Adressen
	senden und empfangen.  Als nächstes müssen beide
	Gateways so konfiguriert werden, dass sie die Pakete des anderen
	Netzwerkes richtig routen.  Mit dem folgenden Befehl
	erreicht man das Ziel:</para>

      <screen>&prompt.root; <userinput>corp-net# route add <replaceable>10.0.0.0 10.0.0.5 255.255.255.0</replaceable></userinput></screen>
      <screen>&prompt.root; <userinput>corp-net# route add net <replaceable>10.0.0.0: gateway 10.0.0.5</replaceable></userinput></screen>

      <screen>&prompt.root; <userinput>priv-net# route add <replaceable>10.246.38.0 10.246.38.1 255.255.255.0</replaceable></userinput></screen>
      <screen>&prompt.root; <userinput>priv-net# route add host <replaceable>10.246.38.0: gateway 10.246.38.1</replaceable></userinput></screen>

      <para>Ab jetzt sollten die Rechner von den Gateways sowie von den
	Rechnern hinter den Gateways erreichbar sein.  Dies wird an dem
	folgendem Beispiel deutlich:</para>

      <programlisting>corp-net# ping 10.0.0.8
PING 10.0.0.8 (10.0.0.8): 56 data bytes
64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms
64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms
64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms
64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms
64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms
--- 10.0.0.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms

priv-net# ping 10.246.38.107
PING 10.246.38.1 (10.246.38.107): 56 data bytes
64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms
64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms
64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms
64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms
64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms
--- 10.246.38.107 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms</programlisting>

      <para>Das Konfigurieren der Tunnel ist der einfache Teil.  Die
	Konfiguration einer sicheren Verbindung geht sehr viel mehr in
	die Tiefe.  Die folgende Konfiguration benutzt pre-shared
	(<acronym>PSK</acronym>) <acronym>RSA</acronym>-Schlüssel.
	Abgesehen von den <acronym>IP</acronym>-Adressen, sind beide
        <filename>/usr/local/etc/racoon/racoon.conf</filename> identisch
        und sehen ähnlich aus wie:</para>

      <programlisting>path    pre_shared_key  "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
log     debug;  #log verbosity setting: set to 'notify' when testing and debugging is complete

padding # options are not to be changed
{
        maximum_length  20;
        randomize       off;
        strict_check    off;
        exclusive_tail  off;
}

timer   # timing options. change as needed
{
        counter         5;
        interval        20 sec;
        persend         1;
#       natt_keepalive  15 sec;
        phase1          30 sec;
        phase2          15 sec;
}

listen  # address [port] that racoon will listening on
{
        isakmp          172.16.5.4 [500];
        isakmp_natt     172.16.5.4 [4500];
}

remote  192.168.1.12 [500]
{
        exchange_mode   main,aggressive;
        doi             ipsec_doi;
        situation       identity_only;
        my_identifier   address 172.16.5.4;
        peers_identifier        address 192.168.1.12;
        lifetime        time 8 hour;
        passive         off;
        proposal_check  obey;
#       nat_traversal   off;
        generate_policy off;

                        proposal {
                                encryption_algorithm    blowfish;
                                hash_algorithm          md5;
                                authentication_method   pre_shared_key;
                                lifetime time           30 sec;
                                dh_group                1;
                        }
}

sainfo  (address 10.246.38.0/24 any address 10.0.0.0/24 any)    # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp)
{                                                               # $network must be the two internal networks you are joining.
        pfs_group       1;
        lifetime        time    36000 sec;
        encryption_algorithm    blowfish,3des,des;
        authentication_algorithm        hmac_md5,hmac_sha1;
        compression_algorithm   deflate;
}</programlisting>

      <para>Die Erklärung einer jeden verfügbaren Option würde
	den Rahmen dieses Textes sprengen.  Es gibt sehr viele
	relevante Informationen in der
	<application>racoon</application>-Konfigurationsanleitung.</para>

      <para>Die <acronym>SPD</acronym>-Methoden müssn noch konfiguriert
	werden so dass, &os; und <application>racoon</application> in der
	Lage sind den Netzwerkverkehr zwischen den Hosts zu ver-
	und entschlüsseln.</para>

      <para>Dies wird durch ein einfaches Shellscript ähnlich wie das
	folgende, das auf dem Firmennetzwerk-Gateway liegt,
	ausgeführt.  Diese Datei wird während der
	Systeminitialisierung ausgeführt und sollte unter
	<filename>/usr/local/etc/racoon/setkey.conf</filename>
	abgespeichert werden.</para>

<programlisting>flush;
spdflush;

# To the home network
spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use;
spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use;</programlisting>

      <para>Einmal abgespeichert, kann <application>racoon</application>
	durch das folgende Kommando auf beiden Gateways gestartet
	werden:</para>

      <screen>&prompt.root; <userinput>/usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log</userinput></screen>

      <para>Die Ausgabe sollte so ähnlich aussehen:</para>

      <programlisting>corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf
Foreground mode.
2006-01-30 01:35:47: INFO: begin Identity Protection mode.
2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon
2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a
2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-&gt;172.16.5.4[0] spi=28496098(0x1b2d0e2)
2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-&gt;192.168.1.12[0] spi=47784998(0x2d92426)
2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0]
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]-&gt;172.16.5.4[0] spi=124397467(0x76a279b)
2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]-&gt;192.168.1.12[0] spi=175852902(0xa7b4d66)</programlisting>

      <para>Um sicherzustellen, dass der Tunnel richtig funktioniert,
	wechseln Sie auf eine andere Konsole und benutzen Sie
	&man.tcpdump.1; mit dem folgenden Befehl, um sich den
	Netzwerkverkehr anzusehen.  Tauschen Sie <literal>em0</literal>
	durch die richtige Netzwerkkarte aus.</para>

      <screen>&prompt.root; <userinput>tcpdump -i em0 host <replaceable>172.16.5.4 and dst 192.168.1.12</replaceable></userinput></screen>

      <para>Die Ausgabe der Konsole sollte dem hier ähneln.  Wenn
	nicht, gibt es ein Problem und ein Debuggen der ausgegebenen
	Daten ist notwendig.</para>

      <programlisting>01:47:32.021683 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
01:47:33.022442 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb)
01:47:34.024218 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc)</programlisting>

      <para>An diesem Punkt sollten beide Netzwerke verfügbar sein und
	den Anschein haben, dass sie zum selben Netzwerk gehören.
	Meistens sind beide Netzwerke durch eine Firewall geschützt.
	Um den Netzwerkverkehr zwischen den beiden Netzwerken zu erlauben,
	ist es notwendig Regeln zu erstellen.  Für die &man.ipfw.8;
	Firewall fügen Sie folgende Zeilen in ihre
	Firewall-Konfigurationsdatei ein:</para>

      <programlisting>ipfw add 00201 allow log esp from any to any
ipfw add 00202 allow log ah from any to any
ipfw add 00203 allow log ipencap from any to any
ipfw add 00204 allow log udp from any 500 to any</programlisting>

      <note>
        <para>Die Regelnummern müssen eventuell, je nach ihrer
          Hostkonfiguration, angepasst werden.</para>
      </note>

      <para>Für Benutzer der &man.pf.4;- oder &man.ipf.8;-Firewall
	sollte folgendes funktionieren:</para>

      <programlisting>pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port = 500 to any port = 500
pass in quick on gif0 from any to any
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port = 500 to any port = 500
pass out quick on gif0 from any to any</programlisting>

      <para>Zum Ende, um dem Computer den Start vom
	<acronym>VPN</acronym> während der Systeminitialisierung
	zu erlauben, fügen Sie folgende Zeilen in ihre
	<filename>/etc/rc.conf</filename>: ein</para>

      <programlisting>ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
racoon_enable="yes"</programlisting>
    </sect2>
  </sect1>

  <sect1 id="openssh">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Chern</firstname>
	  <surname>Lee</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
	<!-- 21 April 2001 -->
      </authorgroup>
    </sect1info>

    <title>OpenSSH</title>
    <indexterm><primary>OpenSSH</primary></indexterm>
    <indexterm>
      <primary>Sicherheit</primary>
      <secondary>OpenSSH</secondary>
    </indexterm>

    <para><application>OpenSSH</application> stellt Werkzeuge bereit,
      um sicher auf entfernte
      Maschinen zuzugreifen.  Die Kommandos <command>rlogin</command>,
      <command>rsh</command>, <command>rcp</command> und
      <command>telnet</command> können durch
      <application>OpenSSH</application> ersetzt werden.
      Zusätzlich können TCP/IP-Verbindungen sicher durch
      SSH weitergeleitet (getunnelt) werden.  Mit SSH werden alle
      Verbindungen verschlüsselt, dadurch wird verhindert, dass
      die Verbindung zum Beispiel abgehört oder übernommen
      (<foreignphrase>Hijacking</foreignphrase>) werden kann.</para>

    <para><application>OpenSSH</application> wird vom OpenBSD-Projekt
      gepflegt und basiert auf SSH&nbsp;v1.2.12 mit allen aktuellen
      Fixen und Aktualisierungen.  <application>OpenSSH</application>
      ist mit den SSH-Protokollen der Versionen 1 und 2 kompatibel.</para>

    <sect2>
      <title>Vorteile von OpenSSH</title>

      <para>Mit &man.telnet.1; oder &man.rlogin.1; werden Daten in
	einer unverschlüsselten Form über das Netzwerk
	gesendet.  Daher besteht die Gefahr, das Benutzer/Passwort
	Kombinationen oder alle Daten an beliebiger Stelle zwischen
	dem Client und dem Server abgehört werden.  Mit
	<application>OpenSSH</application> stehen eine Reihe von
	Authentifizierungs- und Verschlüsselungsmethoden zur
	Verfügung, um das zu verhindern.</para>
    </sect2>

    <sect2>
      <title>Aktivieren von sshd</title>
      <indexterm>
        <primary>OpenSSH</primary>
        <secondary>aktivieren</secondary>
      </indexterm>

      <para>Unter &os; entscheidet der
        Anwender bei einer <literal>Standard</literal>-Installation, ob
        der <application>sshd</application>-Daemon aktiviert werden soll.
        Um zu überprüfen, ob  <application>sshd</application>
        auf Ihrem System aktiviert ist, suchen Sie in
        <filename>rc.conf</filename> nach der folgenden Zeile:</para>

      <programlisting>sshd_enable="YES"</programlisting>

      <para>Ist diese Zeile vorhanden, wird &man.sshd.8;, der
	<application>OpenSSH</application>-D&aelig;mon, beim
	Systemstart automatisch aktiviert.  Alternativ können Sie
	<application>OpenSSH</application> auch über das
	&man.rc.8;-Skript <filename>/etc/rc.d/sshd</filename>
	starten:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/sshd start</userinput></screen>
    </sect2>

    <sect2>
      <title>SSH Client</title>
      <indexterm>
        <primary>OpenSSH</primary>
        <secondary>Client</secondary>
      </indexterm>

      <para>&man.ssh.1; arbeitet ähnlich wie &man.rlogin.1;:</para>

      <screen>&prompt.root; <userinput>ssh <replaceable>user@example.com</replaceable></userinput>
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput>
Host 'example.com' added to the list of known hosts.
user@example.com's password: <userinput>*******</userinput></screen>

      <para>Der Anmeldevorgang wird danach, wie von
        <command>rlogin</command> oder <command>telnet</command> gewohnt,
	weiterlaufen.  SSH speichert einen Fingerabdruck des
	Serverschlüssels.  Die Aufforderung, <literal>yes</literal>
	einzugeben, erscheint nur bei der ersten Verbindung zu einem
	Server.  Weitere Verbindungen zu dem Server werden gegen den
	gespeicherten Fingerabdruck des Schlüssels geprüft und
	der Client gibt eine Warnung aus, wenn sich der empfangene
	Fingerabdruck von dem gespeicherten unterscheidet.  Die
	Fingerabdrücke der Version 1 werden in
	<filename>~/.ssh/known_hosts</filename>, die der Version 2 in
	<filename>~/.ssh/known_hosts2</filename>  gespeichert.</para>

      <para>In der Voreinstellung akzeptieren aktuelle
	<application>OpenSSH</application>-Server nur SSH&nbsp;v2
	Verbindungen.  Wenn möglich, wird Version&nbsp;2 verwendet,
	ist dies nicht möglich, fällt der Server auf
	Version&nbsp;1 zurück.  Der Client kann gezwungen werden,
	nur eine der beiden Versionen zu verwenden, indem die Option
	<option>-1</option> (für die Version&nbsp;1) oder
	<option>-2</option> (für die Version&nbsp;2) übergeben
	wird.  Die Unterstützung für Version&nbsp;1 ist nur
	noch aus Kompatibilitätsgründen zu älteren
	Versionen enthalten.</para>
    </sect2>

    <sect2>
      <title>Secure Copy</title>
      <indexterm>
        <primary>OpenSSH</primary>
        <secondary>secure copy</secondary>
      </indexterm>
      <indexterm><primary><command>scp</command></primary></indexterm>

      <para>Mit  &man.scp.1; lassen sich Dateien analog wie mit
        &man.rcp.1; auf entfernte Maschinen kopieren.  Mit
	<command>scp</command> werden die Dateien allerdings in einer
	sicheren Weise übertragen.</para>

      <screen>&prompt.root; <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@example.com's password:
COPYRIGHT            100% |*****************************|  4735
00:00
&prompt.root;</screen>

      <para>Da der Fingerabdruck schon im vorigen Beispiel abgespeichert
        wurde, wird er bei der Verwendung von <command>scp</command> in
	diesem Beispiel überprüft.  Da die Fingerabdrücke
	übereinstimmen, wird keine Warnung ausgegeben.</para>

      <para>Die Argumente, die <command>scp</command> übergeben
        werden, gleichen denen von <command>cp</command> in der Beziehung,
	dass die ersten Argumente die zu kopierenden Dateien sind und
	das letzte Argument den Bestimmungsort angibt.  Da die Dateien
	über das Netzwerk kopiert werden, können ein oder mehrere
	Argumente die Form
	<option>user@host:&lt;path_to_remote_file></option>
	besitzen.</para>
    </sect2>

    <sect2>
      <title>Konfiguration</title>
      <indexterm>
        <primary>OpenSSH</primary>
        <secondary>Konfiguration</secondary>
      </indexterm>

      <para>Die für das ganze System gültigen
        Konfigurationsdateien des
	<application>OpenSSH</application>-D&aelig;mons und des Clients
	finden sich in dem Verzeichnis
	<filename class="directory">/etc/ssh</filename>.</para>

      <para>Die Client-Konfiguration befindet sich in
        <filename>ssh_config</filename>, die des Servers befindet sich in
	<filename>sshd_config</filename>.</para>

      <para>Das SSH-System lässt sich weiterhin über die
        Anweisungen <option>sshd_program</option> (Vorgabe ist
	<filename>/usr/sbin/sshd</filename>) und
	<option>sshd_flags</option> in <filename>/etc/rc.conf</filename>
	konfigurieren.</para>
    </sect2>

    <sect2 id="security-ssh-keygen">
      <title>ssh-keygen</title>

      <para>Mit &man.ssh-keygen.1; können DSA- oder RSA-Schlüssel
        für einen Benutzer erzeugt werden, die anstelle von
	Passwörtern verwendet werden können:</para>

      <screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>

      <para>&man.ssh-keygen.1; erzeugt einen öffentlichen und einen
        privaten Schlüssel für die Authentifizierung.  Der private
        Schlüssel wird in <filename>~/.ssh/id_dsa</filename> oder
        <filename>~/.ssh/id_rsa</filename> gespeichert, während
        sich der öffentliche Schlüssel in
        <filename>~/.ssh/id_dsa.pub</filename> oder
        <filename>~/.ssh/id_rsa.pub</filename> befindet, je nachdem,
        ob es sich um einen <acronym>DSA</acronym>- oder einen
        <acronym>RSA</acronym>-Schlüssel handelt.
        Der öffentliche Schlüssel muss sowohl für
	<acronym>RSA</acronym>- als auch für
	<acronym>DSA</acronym>-Schlüssel in die Datei
        <filename>~/.ssh/authorized_keys</filename> auf dem entfernten
        Rechner aufgenommen werden, damit der Schlüssel
        funktioniert.</para>

      <para>Damit werden Verbindungen zu der entfernten Maschine über
	SSH-Schlüsseln anstelle von Passwörtern
	authentifiziert.</para>

      <para>Wenn bei der Erstellung der Schlüssel mit
	&man.ssh-keygen.1; ein Passwort angegeben wurde, wird der
	Benutzer bei jeder Anmeldung zur Eingabe des Passworts
	aufgefordert.  Um den Umgang mit SSH-Schlüsseln zu
	erleichtern, kann &man.ssh-agent.1; die Verwaltung dieser
	Schlüssel für Sie übernehmen.  Lesen Sie dazu
	den <xref linkend="security-ssh-agent"/> weiter unten.</para>

      <warning>
	<para>Die Kommandozeilenoptionen und Dateinamen sind
	  abhängig von der <application>OpenSSH</application>-Version.
	  Die für Ihr System gültigen Optionen finden Sie
	  in der Hilfeseite &man.ssh-keygen.1;.</para>
      </warning>
    </sect2>

    <sect2 id="security-ssh-agent">
      <title>ssh-agent und ssh-add</title>

      <para>Mit &man.ssh-agent.1; und &man.ssh-add.1; ist es
        möglich, <application>SSH</application>-Schlüssel
        in den Speicher zu laden, damit die Passphrase nicht jedesmal
        eingegeben werden muss.</para>

      <para>&man.ssh-agent.1; übernimmt die Authentifizierung
        von ihm geladener privater Schlüssel.
        &man.ssh-agent.1; sollte nur dazu verwendet werden, ein
        anderes Programm zu starten, beispielsweise eine Shell oder
        einen Window-Manager.</para>

      <para>Um &man.ssh-agent.1; in einer Shell zu verwenden, muss
        es mit einer Shell als Argument aufgerufen werden.
        Zusätzlich müssen die zu verwaltende Identität
        (durch &man.ssh-add.1;) sowie deren Passphrase für den
        privaten Schlüssel übergeben werden.  Nachdem dies
        erledigt ist, kann sich ein Benutzer über &man.ssh.1;
        auf jedem Rechner anmelden, der einen entsprechenden
        öffentlichen Schlüssel besitzt.  Dazu ein
        Beispiel:</para>

      <screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
&prompt.user; ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
&prompt.user;</screen>

      <para>Um &man.ssh-agent.1; unter X11 zu verwenden, müssen
        Sie &man.ssh-agent.1; in Ihre <filename>~/.xinitrc</filename>
        aufnehmen.  Dadurch können alle unter X11 gestarteten
        Programme die Dienste von &man.ssh-agent.1; nutzen.  Ihre
        <filename>~/.xinitrc</filename> könnte dazu etwas so
        aussehen:</para>

      <programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>

      <para>Dadurch wird bei jedem Start von X11 zuerst
        &man.ssh-agent.1; aufgerufen, das wiederum
        <application>XFCE</application> startet.  Nachdem Sie diese
        Änderung durchgeführt haben, müssen Sie X11
        neu starten.  Danach können Sie mit &man.ssh-add.1;
        Ihre SSH-Schlüssel laden.</para>
    </sect2>

    <sect2 id="security-ssh-tunneling">
      <title>SSH-Tunnel</title>
      <indexterm>
        <primary>OpenSSH</primary>
        <secondary>Tunnel</secondary>
      </indexterm>

      <para>Mit <application>OpenSSH</application> ist es möglich,
	einen Tunnel zu erstellen, in dem ein anderes Protokoll
	verschlüsselt übertragen wird.</para>

      <para>Das folgende Kommando erzeugt einen Tunnel für
        <application>telnet</application>:</para>

       <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
&prompt.user;</screen>

      <para>Dabei wurden die folgenden Optionen von <command>ssh</command>
        verwendet:</para>

      <variablelist>
	<varlistentry>
	  <term><option>-2</option></term>

	  <listitem>
	    <para>Erzwingt die Version 2 des Protokolls (Benutzen Sie die
	      Option nicht mit langsamen
	      <application>SSH</application>-Servern).</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-N</option></term>

	  <listitem>
	    <para>Zeigt an, dass ein Tunnel erstellt werden soll.
	      Ohne diese Option würde <command>ssh</command> eine
	      normale Sitzung öffnen.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-f</option></term>

	  <listitem>
	    <para>Zwingt <command>ssh</command> im Hintergrund zu
	      laufen.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><option>-L</option></term>

	  <listitem>
	    <para>Ein lokaler Tunnel wird in der Form
	      <replaceable>localport:remotehost:remoteport</replaceable>
	      angegeben.  Die Verbindung wird dabei von dem lokalen Port
	      <replaceable>localport</replaceable> auf einen entfernten
	      Rechner weitergeleitet.</para>
	  </listitem>
	  </varlistentry>

	<varlistentry>
	  <term><option>user@foo.example.com</option></term>

	  <listitem>
	    <para>Gibt den entfernten SSH-Server an.</para>
	  </listitem>
	</varlistentry>
      </variablelist>


       <para>Ein SSH-Tunnel erzeugt ein Socket auf
         <hostid>localhost</hostid> und dem angegebenen Port.  Jede
	 Verbindung, die auf dem angegebenen Socket aufgemacht wird, wird
	 dann auf den spezifizierten entfernten Rechner und Port
	 weitergeleitet.</para>

       <para>Im Beispiel wird der Port <replaceable>5023</replaceable> auf
	 die entfernte Maschine und dort auf <hostid>localhost</hostid>
	 Port <replaceable>23</replaceable> weitergeleitet.  Da der Port
	 <replaceable>23</replaceable> für
	 <application>Telnet</application> reserviert ist,
	 erzeugt das eine sichere
	 <application>Telnet</application>-Verbindung durch einen
	 SSH-Tunnel.</para>

       <para>Diese Vorgehensweise kann genutzt werden, um jedes unsichere
         TCP-Protokoll wie SMTP, POP3, FTP, usw. weiterzuleiten.</para>

       <example>
       <title>Mit SSH einen sicheren Tunnel für SMTP erstellen</title>
       <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
user@mailserver.example.com's password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet localhost 5025</userinput>
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP</screen>

       <para>Zusammen mit &man.ssh-keygen.1; und zusätzlichen
         Benutzer-Accounts können Sie leicht benutzbare SSH-Tunnel
	 aufbauen.  Anstelle von Passwörtern können Sie
	 Schlüssel benutzen und jeder Tunnel kann unter einem eigenen
	 Benutzer laufen.</para>
       </example>

      <sect3>
	<title>Beispiel für SSH-Tunnel</title>

	<sect4>
	  <title>Sicherer Zugriff auf einen POP3-Server</title>

	  <para>Nehmen wir an, an Ihrer Arbeitsstelle gibt es einen
	    SSH-Server, der Verbindungen von außen akzeptiert.  Auf
	    dem Netzwerk Ihrer Arbeitsstelle soll sich zudem noch ein
	    Mail-Server befinden, der POP3 spricht.  Das Netzwerk oder die
	    Verbindung von Ihrem Haus zu Ihrer Arbeitsstelle ist unsicher
	    und daher müssen Sie Ihre E-Mail über eine gesicherte
	    Verbindung abholen können.  Die Lösung zu diesem
	    Problem besteht darin, eine SSH-Verbindung von Ihrem Haus zu
	    dem SSH-Server an Ihrer Arbeitsstelle aufzubauen, und von dort
	    weiter zum Mail-Server zu tunneln.</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:mail.example.com:110 user@ssh-server.example.com</replaceable></userinput>
user@ssh-server.example.com's password: <userinput>******</userinput></screen>

	  <para>Wenn Sie den Tunnel eingerichtet haben, konfigurieren Sie
	    Ihren Mail-Client so, dass er POP3 Anfragen zu
	    <hostid>localhost</hostid> Port 2110 sendet.  Die Verbindung
	    wird dann sicher zu <hostid>mail.example.com</hostid>
	    weitergeleitet.</para>
	</sect4>

	<sect4>
	  <title>Umgehen einer strengen Firewall</title>

	  <para>Einige Netzwerkadministratoren stellen sehr drakonische
	    Firewall-Regeln auf, die nicht nur einkommende Verbindungen
	    filtern, sondern auch ausgehende.  Es kann sein, dass Sie
	    externe Maschinen nur über die Ports 22 und 80 (SSH und
	    Web) erreichen.</para>

	  <para>Sie wollen auf einen Dienst, der vielleicht nichts mit
	    Ihrer Arbeit zu tun hat, wie einen Ogg Vorbis Musik-Server,
	    zugreifen.  Wenn der Ogg Vorbis Server nicht auf den Ports 22
	    oder 80 läuft, können Sie aber nicht auf ihn
	    zugreifen.</para>

	  <para>Die Lösung hier ist es, eine SSH-Verbindung zu einer
	    Maschine außerhalb der Firewall aufzumachen und durch
	    diese zum Ogg Vorbis Server zu tunneln.</para>

	  <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:music.example.com:8000 user@unfirewalled-system.example.org</replaceable></userinput>
user@unfirewalled-system.example.org's password: <userinput>*******</userinput></screen>

	  <para>Konfigurieren Sie Ihren Client so, dass er
	    <hostid>localhost</hostid> und Port 8888 benutzt.  Die Verbindung
	    wird dann zu <hostid>music.example.com</hostid> Port 8000
	    weitergeleitet und Sie haben die Firewall erfolgreich
	    umgangen.</para>
      </sect4>
      </sect3>
    </sect2>

    <sect2>
      <title>Die Option <varname>AllowUsers</varname></title>

      <para>Es ist in der Regel ein gute Idee, festzulegen, welche
        Benutzer sich von welchem Rechner aus anmelden können.
        Dies lässt sich beispielsweise über die Option
        <literal>AllowUsers</literal> festlegen.  Soll sich etwa
        nur <username>root</username> vom Rechner mit der IP-Adresse
        <hostid role="ipaddr">192.168.1.32</hostid> aus einwählen
        dürfen, würden Sie folgenden Eintrag in
        <filename>/etc/ssh/sshd_config</filename> aufnehmen:</para>

      <programlisting>AllowUsers root@192.168.1.32</programlisting>

      <para>Damit sich <username>admin</username> von jedem Rechner aus
        anmelden kann, geben Sie nur den Benutzernamen an:</para>

      <programlisting>AllowUsers admin</programlisting>

      <para>Sie können auch mehrere Benutzer in einer Zeile
        aufführen:</para>

      <programlisting>AllowUsers root@192.168.1.32 admin</programlisting>

      <note>
        <para>Nur ein Benutzer, der in dieser Liste aufgeführt ist,
          darf sich auf diesem Rechner anmelden.</para>
      </note>

      <para>Nachdem Sie <filename>/etc/ssh/sshd_config</filename>
        angepasst haben, muss &man.sshd.8; seine Konfigurationsdateien
        neu einlesen.  Dazu geben Sie Folgendes ein:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/sshd reload</userinput></screen>
    </sect2>

    <sect2>
      <title>Weiterführende Informationen</title>
      <para><ulink url="http://www.openssh.com/">OpenSSH</ulink></para>
      <para>&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
        &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5;</para>
      <para>&man.sshd.8; &man.sftp-server.8; &man.sshd.config.5;</para>
    </sect2>
  </sect1>

  <sect1 id="fs-acl">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Zugriffskontrolllisten für Dateisysteme</title>

    <indexterm>
      <primary>ACL</primary>
    </indexterm>

    <para>Zusammen mit anderen Verbesserungen des Dateisystems wie
      Schnappschüsse bietet &os; auch
      <firstterm>Zugriffskontrolllisten</firstterm> (<foreignphrase>access
        control list</foreignphrase>, <acronym>ACL</acronym>).</para>

    <para>Zugriffskontrolllisten erweitern die normalen Zugriffsrechte
      von &unix; Systemen auf eine kompatible (&posix;.1e) Weise
      und bieten feiner granulierte Sicherheitsmechanismen.</para>

    <para>Zugriffskontrolllisten für Dateisysteme werden mit der
      nachstehenden Zeile in der Kernelkonfiguration aktiviert:</para>

    <programlisting>options UFS_ACL</programlisting>

    <para>Diese Option ist in der <filename>GENERIC</filename>-Konfiguration
      aktiviert.  Das System gibt eine Warnung aus, wenn ein Dateisystem mit
      <acronym>ACL</acronym>s eingehangen werden soll und die
      Unterstützung für <acronym>ACL</acronym>s nicht im Kernel
      aktiviert ist.  Das Dateisystem muss weiterhin erweiterte Attribute
      zur Verfügung stellen, damit <acronym>ACL</acronym>s verwendet
      werden können.  Das neue <acronym>UNIX</acronym>-Dateisystem
      <acronym>UFS2</acronym> stellt diese Attribute
      standardmäßig zur Verfügung.</para>

    <note><para>Die Konfiguration erweiterter Attribute auf
      <acronym>UFS1</acronym> ist mit einem höheren Aufwand als die
      Konfiguration erweiterter Attribute auf <acronym>UFS2</acronym>
      verbunden.  Zudem ist <acronym>UFS2</acronym> mit erweiterten
      Attributen leistungsfähiger als <acronym>UFS1</acronym>.
      Zugriffskontrolllisten sollten daher mit <acronym>UFS2</acronym>
      verwendet werden.</para></note>

    <para>Die Angabe der Option <option>acl</option> in
      <filename>/etc/fstab</filename> aktiviert Zugriffskontrolllisten
      für ein Dateisystem.  Die bevorzugte Möglichkeit ist
      die Verwendung von Zugriffskontrolllisten mit &man.tunefs.8; (Option
      <option>-a</option>), im Superblock des Dateisystems festzuschreiben.
      Diese Möglichkeit hat mehrere Vorteile:</para>

    <itemizedlist>
      <listitem>
	<para>Nochmaliges Einhängen eines Dateisystems (Option
	  <option>-u</option> von &man.mount.8;) verändert den Status
	  der Zugriffskontrolllisten nicht.  Die Verwendung von
	  Zugriffskontrolllisten kann nur durch Abhängen und erneutes
	  Einhängen eines Dateisystems verändert werden.  Das
	  heißt auch, dass Zugriffskontrolllisten nicht
	  nachträglich auf dem Root-Dateisystem aktiviert werden
	  können.</para>
      </listitem>

      <listitem>
	<para>Die Zugriffskontrolllisten auf den Dateisystemen sind,
	  unabhängig von den Option in <filename>/etc/fstab</filename>
	  oder Namensänderungen der Geräte, immer aktiv.  Dies
	  verhindert auch, dass Zugriffskontrolllisten aus Versehen
	  auf Dateisystem ohne Zugriffskontrolllisten aktiviert werden und
	  durch falsche Zugriffsrechte Sicherheitsprobleme entstehen.</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Es kann sein, dass sich der Status von Zugriffskontrolllisten
        später durch nochmaliges Einhängen des Dateisystems
	(Option <option>-u</option> von &man.mount.8;) ändern
	lässt.  Die momentane Variante ist aber sicherer, da der
	Status der Zugriffskontrolllisten nicht versehentlich geändert
	werden kann.  Allgemein sollten Zugriffskontrolllisten auf einem
	Dateisystem, auf dem sie einmal verwendet wurden, nicht deaktiviert
	werden, da danach die Zugriffsrechte falsch sein können.
	Werden Zugriffskontrolllisten auf einem solchen Dateisystem wieder
	aktiviert, werden die Zugriffsrechte von Dateien, die sich
	zwischenzeitlich geändert haben, überschrieben, was zu
	erneuten Problemen führt.</para>
    </note>

    <para>Die Zugriffsrechte einer Datei werden durch ein
      <literal>+</literal> (Plus) gekennzeichnet, wenn die Datei durch
      Zugriffskontrolllisten geschützt ist:</para>

    <programlisting>drwx------  2 robert  robert  512 Dec 27 11:54 private
drwxrwx---+ 2 robert  robert  512 Dec 23 10:57 directory1
drwxrwx---+ 2 robert  robert  512 Dec 22 10:20 directory2
drwxrwx---+ 2 robert  robert  512 Dec 27 11:57 directory3
drwxr-xr-x  2 robert  robert  512 Nov 10 11:54 public_html</programlisting>

    <para>Die Verzeichnisse <filename class="directory">directory1</filename>,
      <filename class="directory">directory2</filename> und
      <filename class="directory">directory3</filename>
      sind durch Zugriffskontrolllisten geschützt, das Verzeichnis
      <filename class="directory">public_html</filename> nicht.</para>

    <sect2>
      <title>Zugriffskontrolllisten benutzen</title>

      <para>Das Werkzeug &man.getfacl.1; zeigt Zugriffskontrolllisten
	an.  Das folgende Kommando zeigt die <acronym>ACL</acronym>s
	auf der Datei <filename>test</filename>:</para>

      <screen>&prompt.user; <userinput>getfacl <filename>test</filename></userinput>
	#file:test
	#owner:1001
	#group:1001
	user::rw-
	group::r--
	other::r--</screen>

      <para>Das Werkzeug &man.setfacl.1; ändert oder entfernt
        <acronym>ACL</acronym>s auf Dateien.  Zum Beispiel:</para>

      <screen>&prompt.user; <userinput>setfacl -k <filename>test</filename></userinput></screen>

      <para>Die Option <option>-k</option> entfernt alle
	<acronym>ACL</acronym>s einer Datei oder eines Dateisystems.
	Besser wäre es, die Option <option>-b</option>
	zu verwenden, da sie die erforderlichen Felder
	beibehält.</para>

      <screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,g:web:r--,o::--- <filename>test</filename></userinput></screen>

      <para>Mit dem vorstehenden Kommando werden die eben
	entfernten Zugriffskontrolllisten wiederhergestellt.
	Der Befehl gibt die Fehlermeldung
	<errorname>Invalid argument</errorname> aus,
	<!-- doch nicht auf <devicename>stdout</devicename> ?? -->
	wenn Sie nicht existierende Benutzer oder Gruppen
	als Parameter angeben.</para>
    </sect2>
  </sect1>

  <sect1 id="security-portaudit">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Sicherheitsprobleme in Software Dritter überwachen</title>

    <indexterm>
      <primary>Portaudit</primary>
    </indexterm>

    <para>In den letzten Jahren wurden zahlreiche Verbesserungen in
      der Einschätzung und dem Umgang mit Sicherheitsproblemen
      erzielt.  Die Gefahr von Einbrüchen in ein System wird
      aber immer größer, da Softwarepakete von Dritten
      auf nahezu jedem Betriebssystem installiert und konfiguriert
      werden.</para>

    <para>Die Einschätzung der Verletzlichkeit eines Systems ist
      ein Schlüsselfaktor für dessen Sicherheit.  &os;
      veröffentlicht zwar Sicherheitshinweise
      (<foreignphrase>security advisories</foreignphrase>) für
      das Basissystem, das Projekt ist allerdings nicht dazu in der
      Lage, dies auch für die zahlreichen Softwarepakete von
      Dritten zu tun.  Dennoch gibt es einen Weg, auch diese
      Programmpakete zu überwachen.  Das in der Ports-Sammlung
      enthaltene Programm <application>Portaudit</application> wurde
      gezielt dafür entwickelt.</para>

    <para>Der Port <filename role="package">ports-mgmt/portaudit</filename>
      fragt dazu eine Datenbank, die vom &os; Security Team sowie
      den Ports-Entwicklern aktualisiert und gewartet wird, auf
      bekannte Sicherheitsprobleme ab.</para>

    <para>Bevor Sie <application>Portaudit</application> verwenden
      können, müssen Sie es über die Ports-Sammlung
      installieren:</para>

    <screen>&prompt.root; <userinput>cd /usr/ports/security/portaudit &amp;&amp; make install clean</userinput></screen>

    <para>Während der Installation werden die
      Konfigurationsdateien für &man.periodic.8; aktualisiert, was
      es <application>Portaudit</application> erlaubt, seine Ausgabe
      in den täglichen Sicherheitsbericht einzufügen.
      Stellen Sie auf jeden Fall sicher, dass diese (an das
      E-Mail-Konto von <username>root</username> gesendeten)
      Sicherheitsberichte auch gelesen werden.  An dieser Stelle
      ist keine weitere Konfiguration nötig.</para>

    <para>Nach der Installation kann ein Administrator die unter
      <filename class="directory">/var/db/portaudit</filename> lokal
      gespeicherte Datenbank aktualisieren und sich danach durch
      folgenden Befehl über mögliche Sicherheitslücken
      der von ihm installierten Softwarepakete informieren:</para>

    <screen>&prompt.root; <userinput>portaudit -Fda</userinput></screen>

    <note>
      <para>Die Datenbank wird automatisch aktualisiert, wenn
        &man.periodic.8; ausgeführt wird.  Der eben genannte
        Befehl ist daher optional, er wird aber für das
        folgende Beispiel benötigt.</para>
    </note>

    <para>Nach erfolgter Installation der Datenbank kann ein
      Administrator über die Ports-Sammlung installierte
      Softwarepakete Dritter jederzeit überprüfen.  Dazu
      muss er lediglich folgenden Befehl eingeben:</para>

    <screen>&prompt.root; <userinput>portaudit -a</userinput></screen>

    <para>Existiert in Ihren installierten Softwarepaketen eine
      Sicherheitslücke, wird <application>Portaudit</application>
      eine Ausgabe ähnlich der folgenden produzieren:</para>

    <programlisting>Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: &lt;http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html&gt;

1 problem(s) in your installed packages found.

You are advised to update or deinstall the affected package(s) immediately.</programlisting>

    <para>Wenn Sie die angegebene <acronym>URL</acronym> über einen
      Internetbrowser aufrufen, erhalten Sie weitere Informationen
      über die bestehende Sicherheitslücke, wie die betroffenen
      Versionen, die Version des &os;-Ports sowie Hinweise auf weitere
      Seiten, die ebenfalls Sicherheitshinweise zu diesem Problem
      bieten.</para>

    <para><application>Portaudit</application> ist ein mächtiges
      Werkzeug und insbesondere in Zusammenarbeit mit dem
      Port <application>Portupgrade</application> äußerst
      hilfreich.</para>
  </sect1>

  <sect1 id="security-advisories">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Beigesteuert von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>&os; Sicherheitshinweise</title>

    <indexterm>
      <primary>Sicherheitshinweise</primary>
    </indexterm>

    <para>Wie für andere hochwertige Betriebssysteme auch
      werden für &os; Sicherheitshinweise herausgegeben.
      Die Hinweise werden gewöhnlich auf den Sicherheits-Mailinglisten
      und in den Errata veröffentlicht, nachdem das
      Sicherheitsproblem behoben ist.  Dieser Abschnitt beschreibt
      den Umgang mit den Sicherheitshinweisen.</para>

    <sect2>
      <title>Wie sieht ein Sicherheitshinweis aus?</title>

      <para>Der nachstehende Sicherheitshinweis stammt von
	der Mailingliste &a.security-notifications.name;:</para>

      <programlisting>=============================================================================
FreeBSD-SA-XX:XX.UTIL                                     Security Advisory
                                                          The FreeBSD Project

Topic:          denial of service due to some problem<co id="co-topic"/>

Category:       core<co id="co-category"/>
Module:         sys<co id="co-module"/>
Announced:      2003-09-23<co id="co-announce"/>
Credits:        Person<co id="co-credit"/>
Affects:        All releases of &os;<co id="co-affects"/>
                &os; 4-STABLE prior to the correction date
Corrected:      2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
                2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
                2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
                2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
                2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
                2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
                2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
                2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
                2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)<co id="co-corrected"/>
<acronym>CVE</acronym> Name:       CVE-XXXX-XXXX<co id="co-cve"/>

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://www.FreeBSD.org/security/.

I.   Background<co id="co-backround"/>


II.  Problem Description<co id="co-descript"/>


III. Impact<co id="co-impact"/>


IV.  Workaround<co id="co-workaround"/>


V.   Solution<co id="co-solution"/>


VI.  Correction details<co id="co-details"/>


VII. References<co id="co-ref"/></programlisting>


      <calloutlist>
	<callout arearefs="co-topic">
	  <para>Das Feld <literal>Topic</literal> enthält eine
	    Beschreibung des Sicherheitsproblems und benennt das
	    betroffene Programm.</para>
	</callout>

	<callout arearefs="co-category">
	  <para>Das Feld <literal>Category</literal> beschreibt den
	    betroffenen Systemteil.  Mögliche Werte für dieses
	    Feld sind <literal>core</literal>, <literal>contrib</literal>
	    oder <literal>ports</literal>.  Die Kategorie
	    <literal>core</literal> gilt für Kernkomponenten
	    des &os;-Betriebssystems, die Kategorie
	    <literal>contrib</literal> beschreibt zum Basissystem
	    gehörende Software Dritter beispielsweise
	    <application>sendmail</application>.  Die Kategorie
	    <literal>ports</literal> beschreibt Software, die
	    Teil der Ports-Sammlung ist.</para>
	</callout>

	<callout arearefs="co-module">
	  <para>Das Feld <literal>Module</literal> beschreibt die
	    betroffene Komponente.  Im Beispiel ist
	    <literal>sys</literal> angegeben, das heißt
	    dieses Problem betrifft eine Komponente, die vom
	    Kernel benutzt wird.</para>
	</callout>

	<callout arearefs="co-announce">
	  <para>Das Feld <literal>Announced</literal> gibt den
	    Zeitpunkt der Bekanntgabe des Sicherheitshinweises
	    an.  Damit existiert das Sicherheitsproblem,
	    ist vom Sicherheits-Team bestätigt worden
	    und eine entsprechende Korrektur wurde in das
	    Quellcode-Repository von &os; gestellt.</para>
	</callout>

	<callout arearefs="co-credit">
	  <para>Das Feld <literal>Credits</literal> gibt die Person
	    oder Organisation an, die das Sicherheitsproblem
	    bemerkte und gemeldet hat.</para>
	</callout>

	<callout arearefs="co-affects">
	  <para>Welche &os;-Releases betroffen sind, ist im Feld
	    <literal>Affects</literal> angegeben.  Die Version einer
	    Datei, die zum Kernel gehört, können Sie
	    schnell mit <command>ident</command> ermitteln.  Bei Ports
	    ist die Versionsnummer angegeben, die Sie im Verzeichnis
	    <filename class="directory">/var/db/pkg</filename> finden.
	    Wenn Sie Ihr System nicht täglich aktualisieren,
	    ist Ihr System wahrscheinlich betroffen.</para>
	</callout>

	<callout arearefs="co-corrected">
	  <para>Wann das Problem in welchem Release behoben wurde,
	    steht im Feld <literal>Corrected</literal>.</para>
	</callout>

	<callout arearefs="co-cve">
	  <para>Reserviert für Informationen, über die
	    in der <emphasis>Common Vulnerabilities Database</emphasis>
	    nach Sicherheitslücken gesucht werden kann.</para>
	</callout>

	<callout arearefs="co-backround">
	  <para>Im Feld <literal>Background</literal> wird
	    das betroffene Werkzeug beschrieben.  Meist finden Sie
	    hier warum das Werkzeug Bestandteil von &os; ist,
	    wofür es benutzt wird und eine kurze
	    Darstellung der Herkunft des Werkzeugs.</para>
	</callout>

	<callout arearefs="co-descript">
	  <para>Im Feld <literal>Problem Description</literal> befindet
	    sich eine genaue Darstellung des Sicherheitsproblems.
	    Hier wird fehlerhafter Code beschrieben oder geschildert,
	    wie ein Werkzeug ausgenutzt wird.</para>
	</callout>

	<callout arearefs="co-impact">
	  <para>Das Feld <literal>Impact</literal> beschreibt die
	    Auswirkungen des Sicherheitsproblems auf ein System,
	    beispielsweise erweiterte Rechte oder gar
	    Superuser-Rechte für normale Benutzer.</para>
	</callout>

	<callout arearefs="co-workaround">
	  <para>Im Feld <literal>Workaround</literal> wird
	    eine Umgehung des Sicherheitsproblems beschrieben.
	    Die Umgehung ist für Administratoren gedacht,
	    die ihr System aus Zeitnot, Netzwerk-technischen oder
	    anderen Gründen nicht aktualisieren können.
	    Nehmen Sie Sicherheitsprobleme ernst:  Auf einem
	    betroffenen System sollte das Problem entweder behoben
	    oder, wie hier beschrieben, umgangen werden.</para>
	</callout>

	<callout arearefs="co-solution">
	  <para>Im Feld <literal>Solution</literal> enthält eine
	    getestete Schritt-für-Schritt Anleitung, die das
	    Sicherheitsproblem behebt.</para>
	</callout>

	<callout arearefs="co-details">
	  <para>Das Feld <literal>Correction Details</literal>
	    enthält die CVS-Tags der betroffenen Dateien
	    zusammen mit zugehörigen Revisionsnummern.</para>
	</callout>

	<callout arearefs="co-ref">
	  <para>Im Feld <literal>References</literal> finden sich
	    Verweise auf weitere Informationsquellen.  Dies können
	    URLs zu Webseiten, Bücher, Mailinglisten und Newsgroups
	    sein.</para>
	</callout>
      </calloutlist>
    </sect2>
  </sect1>

  <sect1 id="security-accounting">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Beigetragen von </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Prozess-Überwachung</title>

    <indexterm>
      <primary>Prozess-Überwachung</primary>
    </indexterm>

    <para>Prozess-Überwachung
      (<foreignphrase>Process accounting</foreignphrase>) ist ein
      Sicherheitsverfahren, bei dem ein Administrator verfolgt,
      welche Systemressourcen verwendet werden und wie sich diese
      auf die einzelnen Anwender verteilen.  Dadurch kann das
      System überwacht werden und es ist sogar möglich,
      zu kontrollieren, welche Befehle ein Anwender eingibt.</para>

    <para>Diese Fähigkeiten haben sowohl Vor- als auch Nachteile.
      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.
      Dieser Abschnitt beschreibt die Grundlagen der
      Prozess-Überwachung.</para>

    <sect2>
      <title>Die Prozess-Überwachung aktivieren und
        konfigurieren</title>

      <para>Bevor Sie die Prozess-Überwachung verwenden können,
        müssen Sie diese aktivieren.  Dazu führen Sie als
        <username>root</username> die folgenden Befehle aus:</para>

       <screen>&prompt.root; <userinput>touch <filename>/var/account/acct</filename></userinput>
&prompt.root; <userinput>accton <filename>/var/account/acct</filename></userinput>
&prompt.root; <userinput>echo 'accounting_enable="YES"' &gt;&gt; <filename>/etc/rc.conf</filename></userinput></screen>

      <para>Einmal aktiviert, wird sofort mit der Überwachung von
	<acronym>CPU</acronym>-Statistiken, Befehlen und anderen
	Vorgängen begonnen.  Protokolldateien werden in einem
	nur von Maschinen lesbaren Format gespeichert, daher müssen
	Sie diese über &man.sa.8; aufrufen.  Geben Sie keine
	Optionen an, gibt <command>sa</command> Informationen wie
	die Anzahl der Aufrufe pro Anwender, die abgelaufene Zeit in
	Minuten, die gesamte <acronym>CPU</acronym>- und Anwenderzeit
	in Minuten, die durchschnittliche Anzahl der Ein- und
	Ausgabeoperationen und viel andere mehr aus.</para>

      <para>Um Informationen über ausgeführte Befehle zu
	erhalten, verwenden Sie &man.lastcomm.1;. So können Sie
	etwa ermittlen, welche Befehle von wem auf welchem &man.ttys.5;
	ausgeführt wurden:</para>

      <screen>&prompt.root; <userinput>lastcomm ls
	<username>trhodes</username> ttyp1</userinput></screen>

      <para>Das Ergebnis sind alle bekannten Einsätze von
        <command>ls</command> durch <username>trhodes</username>
        auf dem Terminal <literal>ttyp1</literal>.</para>

      <para>Zahlreiche weitere nützliche Optionen finden Sie in den
	Manualpages zu &man.lastcomm.1;, &man.acct.5; sowie
	&man.sa.8;.</para>
    </sect2>
  </sect1>
</chapter>