doc/de_DE.ISO8859-1/books/handbook/security/chapter.sgml
2012-09-14 17:47:48 +00:00

4260 lines
175 KiB
XML

<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD German Documentation Project
$FreeBSD$
$FreeBSDde: de-docproj/books/handbook/security/chapter.sgml,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>