<?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 – 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¨r alle Securelevels und für alle Einschränkungen, die sie schaffen, möglich. Ein bisschen Vorausplanung ist eine gute Idee. Das Verständnis für die Beschränkungen, die durch jedes Securelevel verursacht werden, ist wichtig, da sie die einfache Benutzung des Systems verschlechtern. Es vereinfacht auch die Wahl einer Standardeinstellung und schützt vor Überraschungen.</para> </note> <para>Wenn das Securelevel des Kernel auf einen Wert von 1 oder höher gesetzt ist, kann es sinnvoll sein das <literal>schg</literal> Flag auf kritische Startdateien, Verzeichnisse und Scripte (z.B. alles was läuft bis zu dem Punkt auf dem das Securelevel gesetzt ist) zu setzen. Dies könnte etwas ü,bertrieben sein, und auch das Upgrade des Systems ist sehr viel schwerer, wenn es auf einem hohen Securelevel läuft. Ein strengerer Kompromiss ist es, das System auf einem höheren Securelevel laufen zu lassen, aber keine <literal>schg</literal> Flags für alle Systemdateien und Verzeichnisse zu setzen. Eine andere Möglichkeit ist es, einfach die Verzeichnisse <filename 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 – das Aufdecken von Einbrüchen – ist sicherlich die wichtigste. Alle Sicherheitsmaßnahmen sind nichts wert, oder wiegen Sie in falscher Sicherheit, wenn Sie nicht in der Lage sind, einen möglichen Einbruch zu entdecken. Die Hälfte der Sicherheitsmaßnahmen hat die Aufgabe, einen Einbruch zu verlangsamen, um es zu ermöglichen, den Einbrecher auf frischer Tat zu ertappen.</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æ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 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 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> 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>$1$</literal>. Passwörter, die mit <literal>$2a$</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>$</literal>-Zeichen nicht enthält. Ein relativ kurzes Passwort, das nicht mit einem <literal>$</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 Zeichen, wie alte &unix; Passwörter<footnote> <para>Unter &os; darf das System-Passwort maximal 128 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><username></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><secret password></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> <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 >> \ /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> 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 – 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 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 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]->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]->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]->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]->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 > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 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 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æ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 v2 Verbindungen. Wenn möglich, wird Version 2 verwendet, ist dies nicht möglich, fällt der Server auf Version 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 1) oder <option>-2</option> (für die Version 2) übergeben wird. Die Unterstützung für Version 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:<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æ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 && 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: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html> 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"' >> <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>