diff --git a/de_DE.ISO8859-1/books/handbook/security/chapter.sgml b/de_DE.ISO8859-1/books/handbook/security/chapter.sgml new file mode 100644 index 0000000000..d5028afef1 --- /dev/null +++ b/de_DE.ISO8859-1/books/handbook/security/chapter.sgml @@ -0,0 +1,3620 @@ + + + + + + + Matthew + Dillon + Viel von diesem Kapitel stammt aus der security(7) + Manual-Seite von + + + + + Sicherheit + Sicherheit + + + Übersicht + + Dieses Kapitel bietet eine Einführung in die Konzepte + der Systemsicherheit. Neben einigen Daumenregeln werden fortgeschrittene + 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 friedlicher Ort zu sein, an dem Sie nur nette + Leute finden werden. Es ist unumgänglich, daß Sie + Ihre Daten, Ihr geistiges Eigentum, Ihre Zeit und vieles mehr vor + dem Zugriff von Hackern schützen. + + FreeBSD besitzt eine Reihe von Werkzeugen und Mechanismen, um die + Integrität und die Sicherheit Ihrer Systeme und Netzwerke + zu gewährleisten. + + Nach dem Sie dieses Kapitel durchgearbeitet haben, werden + Sie: + + + + Grundlegende auf FreeBSD bezogene Sicherheitsaspekte + kennen. + + + + Die verschiedenen Verschlüsselungsmechanismen von FreeBSD, + wie DES oder MD5, kennen. + + + + Wissen, wie Sie S/Key ein Einmal-Paßwort + Authentisierungssystem aufsetzen. + + + + Wissen, wie Sie Kerberos, ein weiteres Authentisierungssystem, + aufsetzen. + + + + Firewalls mit IPFW erstellen können. + + + + Wissen, wie Sie IPSec konfigurieren. + + + + OpenSSH, FreeBSDs Implementation von ssh, konfigurieren + und benutzen können. + + + + Bevor Die dieses Kapitel lesen, sollten Sie + + + + Grundlegende Konzepte von FreeBSD und dem Internet + verstehen. + + + + + + + Einführung + + 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. + + Sicherheit wird am besten in mehreren Schichten implementiert. + Kurz gesagt wollen Sie eine angemessene Zahl an Schichten einrichten, + und dann das System auf Einbrüche hin beobachten. Die + Sicherheitsmaßnahmen sollten nicht überzogen werden, + da sie sonst das Entdecken von Einbrüchen stören und die + Möglichkeit, Einbrüche zu entdecken, ist einer der wichtigsten + Aspekte einer Sicherheitsmaßnahme. Es macht zum Beispiel wenig + Sinn, jedes Programm mit der schg Option (siehe auch + &man.chflags.1;) zu schützen, weil dies verhindert, daß ein + Angreifer eine leicht zu entdeckende Veränderung vornimmt und + vielleicht dazu führt, daß Ihre Sicherheitsvorkehrungen den + Angreifer überhaupt nicht entdecken. + + 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 + root zu kompromittieren. Sicherheitsaspekte + lassen sich in mehrere Kategorien unterteilen: + + + + Denial of Service Angriffe. + + + + Kompromittierte Benutzeraccounts. + + + + Kompromittierter root-account durch + zugreifbare Server. + + + + Kompromittierter root-account durch + kompromittierte Benutzeraccounts. + + + + Einrichten von Hintertüren. + + + + + DoS Angriffe + Denial of Service (DoS) + + + Sicherheit + DoS Angriffe + Denial of Service (DoS) + + Denial of Service (DoS) + + 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. + + + Sicherheit + kompromittierte Accounts + + + Kompromittierte Benutzeraccounts kommen noch häufiger als + DoS Angriffe vor. Viele Systemadministratoren lassen auf ihren + Maschinen noch die Dienste telnetd, + rlogind, rshd + und ftpd 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, daß + das Paßwort 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. + + Es ist immer davon auszugehen, daß ein Angreifer, der + Zugriff auf einen Benutzeraccount hat, Zugang zum + root-Account erlangt. Allerdings gibt der + Zugriff auf einen Benutzeraccount auf einem gut gesicherten und + gepflegten System nicht notwendig Zugriff auf den + root-Account. Diese Unterscheidung ist wichtig, + da ein Angreifer, der keinen Zugang zu root + besitzt, seine Spuren nicht verwischen kann. Er kann höchstens + die Dateien des betreffenden Benutzers verändern oder die + Maschine stillegen. Kompromittierte Benutzeraccounts sind sehr + häufig, da Benutzer meist nicht dieselben Vorsichtsmaßnahmen + wie Administratoren treffen. + + + Sicherheit + Hintertüren + + + Es gibt viele Wege, Zugang zum root-Account + eines Systems zu bekommen: Ein Angreifer kann das Paßwort von + root kennen, er kann einen Fehler in einem + Server entdecken, der unter root läuft und + dann über eine Netzwerkverbindung zu diesem Server einbrechen. + Oder er kennt einen + Fehler in einem SUID-root Programm, der es + ihm erlaubt, root zu werden, wenn er einmal + einen Benutzeraccount kompromittiert hat. Wenn ein Angreifer einen + Weg gefunden hat, root zu werden, braucht er + vielleicht keine Hintertür auf dem System installieren. + Viele der heute + bekannten und geschlossenen Sicherheitslöcher, die zu einem + root 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. Backdoor) zu installieren. Eine Hintertür erlaubt es + dem Angreifer leicht auf den root-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, daß die + Lücke, die der Angreifer für den Einbruch ausgenutzt hat, + entdeckt wird. + + Sicherheitsmaßnahmen sollten immer in mehreren Schichten + angelegt werden. Die Schichten können wie folgt eingeteilt + werden: + + + + Absichern von root und + Benutzeraccounts. + + + + Absichern von unter root laufenden + Servern und SUID/SGID Programmen. + + + + Absichern von Benutzeraccounts. + + + + Absichern der Paßwort-Datei. + + + + Absichern des Kernels, der Geräte und von + Dateisystemen. + + + + Schnelles Aufdecken von unbefugten Veränderungen des + Systems. + + + + Paranoia. + + + + Die einzelnen Punkte der obigen Liste werden im nächsten + Abschnitt genauer behandelt. + + + + Sicherheit + Absichern + + + + Absichern von FreeBSD + + + Kommandos und Protokolle + In diesem Abschnitt wird fett verwendet, + um Kommandos oder Applikationen zu kennzeichnen. Zum Beispiel + wird ssh so gekennzeichnet, da es + sowohl ein Protokoll wie auch ein Kommando ist. + + + Die folgenden Abschnitte behandeln die im + letzten Abschnitt erwähnten + Methoden Ihr FreeBSD-System zu sichern. + + + Absichern von <username>root</username> und + Benutzeraccounts. + + + su + + + Zuallererst, kümmern Sie sich nicht um die Absicherung + von Benutzeraccounts, wenn Sie root + noch nicht abgesichert haben. Auf den meisten Systemen ist + root ein Paßwort zugewiesen. Sie + sollten immer davon ausgehen, daß + dieses Paßwort kompromittiert ist. Das heißt nicht, + daß Sie das Paßwort entfernen sollten, da es meist + für den Konsolenzugriff notwendig ist. Vielmehr heißt + es, daß Sie das Paßwort nicht außerhalb der + Konsole, auch nicht zusammen mit &man.su.1;, verwenden sollten. + Stellen Sie sicher, das Ihre PTYs in ttys als + unsicher markiert sind und damit Anmeldungen von + root mit telnet oder + rlogin verboten sind. Wenn Sie andere + Applikationen wie sshd zum Anmelden + benutzen, vergewissern Sie sich, daß dort ebenfalls + Anmeldungen als root verboten sind. Für + ssh editieren Sie + /etc/ssh/sshd_config und überprüfen, + daß PermitRootLogin auf NO + gesetzt ist. Beachten Sie jede Zugriffsmethode – Dienste + wie FTP werden oft vergessen. Nur an der Systemkonsole sollte + ein direktes Anmelden als root möglich + sein. + + + wheel + + + Natürlich müssen Sie als Systemadministrator + root-Zugriff erlangen können. Dieser + sollte aber durch zusätzliche Paßwörter + geschützt sein. Ein Weg, Zugang zu root + zu ermöglichen, ist es, berechtigte Mitarbeiter in + /etc/group in die Gruppe + wheel aufzunehmen. Die Personen, die + Mitglieder in der Gruppe wheel sind, + können mit su zu root + wechseln. Ihre Mitarbeiter sollten niemals die Gruppe + wheel als primäre Gruppe in + /etc/passwd besitzen. Mitarbeiter sollten + der Gruppe staff angehören und über + /etc/group in wheel + aufgenommen werden. Es sollten auch nur die Mitarbeiter, die + wirklich root Zugriff benötigen in + wheel aufgenommen werden. Mit anderen + Authentisierungsmethoden müssen Sie niemanden in + wheel aufnehmen. Wenn Sie z.B. + Kerberos nutzen, wechseln Sie mit + &man.ksu.1; zu root und der Zugriff wird + mit der Datei .k5login geregelt. Dies ist + vielleicht eine bessere Lösung, da es der + wheel-Mechanismus einem Angreifer immer + noch möglich macht, den root-Account + zu knacken, nachdem er einen Mitarbeiter-Account geknackt hat. + Obwohl der wheel-Mechanismus besser als + gar nichts ist, ist er nicht unbedingt die sicherste Lösung. + + Indirekt können Sie die Accounts von Mitarbeitern und + damit auch den Zugriff auf root schützen, + indem Sie eine alternative Zugangsmethode verwenden und die + Accounts der Mitarbeiter mit einem ungültigen verschlüsselten + Paßwort versehen. Mit &man.vipw.8; können Sie jedes + verschlüsselte Paßwort mit einem + * Zeichen ersetzen. Das Kommando + wird /etc/master.passwd und die + Benutzer/Paßwort Datenbank aktualisieren und die Paßwort + Authentisierung abstellen. + + Ein Account wie der folgende + + foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + sollte wie folgt abgeändert werden: + + foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + + Da ein verschlüsseltes Paßwort niemals + ein * sein kann, verhindert dies + die normale Anmeldung. Damit müssen sich die Mitarbeiter + mit anderen Mechanismen wie &man.kerberos.1; oder &man.ssh.1; + authentifizieren. Wenn Sie etwas wie + Kerberos benutzen, müssen Sie + die Maschinen, die die Kerberos-Server + beheimaten und die Maschinen der Benutzer absichern. Wenn Sie + öffentliche/private Schlüssel mit + ssh benutzen, muß die Maschine + von der die Anmeldung gestartet wird, gesichert + werden. Als zusätzliche Sicherheitsschicht können Sie + das Schlüsselpaar beim Erstellen mit &man.ssh-keygen.1; durch + ein Paßwort schützen. Dadurch, daß Sie die + Paßwörter Ihrer Mitarbeiter als ungültig markiert + haben, stellen Sie sicher, daß sich die Mitarbeiter nur mit + den sicheren Methoden, die Sie aufgesetzt haben, anmelden können. + Dies zwingt alle Mitarbeiter, verschlüsselte Verbindungen + für ihre Sitzungen zu verwenden, und schließt ein + wichtiges Loch, daß gerne von Angreifern ausgenutzt wird: + Das Abhören des Netzwerks von einer anderen weniger gesicherten + Maschine. + + Die indirekten Sicherheitsmechanismen setzen voraus, daß + 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 Paßwort + 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, + daß der Großteil der Einbrüche über das + Netzwerk erfolgt und die Einbrecher keinen Zugang zu der Maschine + besitzen. + Kerberos + + Mit Kerberos können Sie das + Paßwort eines Mitarbeiters an einer Stelle ändern + und alle Maschinen, auf denen der Mitarbeiter einen Account hat, + beachten die Änderung sofort. Wird der Account eines + Mitarbeiter einmal kompromittiert, so sollte die Fähigkeit, das + Paßwort mit einem Schlag auf allen Maschinen zu ändern, + nicht unterschätzt werden. Mit einzelnen Paßwörtern + wird es schwierig, das Paßwort auf N Maschinen zu ändern. + Mit Kerberos können Sie auch + Beschränkungen für Paßwörter festlegen: + Nicht nur das Ticket kann nach einiger Zeit ungültig werden, + Sie können auch festlegen, daß der Benutzer nach einer + bestimmten Zeit, z.B. nach einem Monat, das Paßwort wechseln + muß. + + + Absichern von unter <username>root</username> laufenden + Servern und SUID/SGID Programmen + + + ntalk + + + comsat + + + finger + + + Sandkästen + + + sshd + + + telnetd + + + rshd + + + rlogind + + + Ein kluger Systemadministrator läßt nur die + Dienste, die er wirklich braucht, laufen; nicht mehr und auch + nicht weniger. Beachten Sie, daß Server von Dritten die + fehleranfälligsten sind. Wenn Sie z.B. eine alte Version von + imapd oder popper + laufen lassen, ist das so, als würden Sie der ganzen Welt + freien Zugang zu root geben. Lassen Sie keine + Server laufen, die Sie vorher nicht genau überprüft haben. + Viele Server müssen nicht unter root + laufen, zum Beispiel können ntalk, + comsat und finger + in speziellen Sandkästen 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 muß + 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 root läuft, Lücken + gefunden, die zu einem root Zugriff führten. + Dies betrifft selbst die grundlegenden Systemdienste. Wenn Sie eine + Maschine betreiben, auf der man sich nur mit + sshd anmelden kann, dann stellen Sie die + Dienste telnetd, + rshd oder rlogind + ab! + + In der Voreinstellung laufen unter FreeBSD + ntalkd, comsat + und finger nun in einem Sandkasten. Ein + weiteres Programm, das in einem Sandkasten laufen sollte, ist + &man.named.8;. In /etc/defaults/rc.conf sind + die notwendigen Argumente, um named 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. + + sendmail + + + Einige Server wie sendmail, + popper, imapd + und ftpd 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 root laufen lassen und auf die + eingebauten Mechanismen vertrauen, Einbrüche zu entdecken. + + Weitere potentielle Löcher, die zu einem + root-Zugriff führen können, sind + die auf dem System installierten SUID- und SGID-Programme. Die + meisten dieser Programme wie rlogin stehen + in /bin, /sbin, + /usr/bin, oder /usr/sbin. + Obwohl nichts 100% sicher ist, können Sie davon ausgehen, + daß die SUID- und SGID-Programme des Basissystems ausreichend + sicher sind. Allerdings werden ab und an in diesen Programmen + Löcher gefunden. 1998 wurde in Xlib ein + Loch gefunden, das xterm, 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 der kluge 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 chmod 000 deaktiviert werden. Zum + Beispiel braucht ein Server ohne Bildschirm kein + xterm Programm. SGID-Programme sind + vergleichbar gefährlich. Wenn ein Einbrecher Zugriff auf + SGID-kmem Programm erhält, kann er + vielleicht /dev/kmem und damit die + verschlüsselte Paßwortdatei lesen. Dies kompromittiert + unter Umständen jeden Account, der mit einem Paßwort + geschützt ist. Alternativ kann ein Einbrecher, der in die + Gruppe kmem 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 + tty 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. + + + + Absichern von Benutzeraccounts + + Benutzeraccounts sind für gewöhnlich sehr schwierig + abzusichern. Während Sie drakonische Beschränkungen + für Ihre Mitarbeiter einrichten und deren Paßwörter + als ungültig markieren können, werden Sie das + vielleicht bei den normalen Benutzeraccounts nicht durchsetzen. + Wenn Sie über ausreichend Macht verfügen, gelingt es Ihnen + vielleicht doch, ansonsten müssen Sie diese Benutzeraccounts + aufmerksam überwachen. Wegen der zusätzlichen + Administrationsarbeit und der nötigen technischen + Unterstützung ist die Verwendung von + ssh und Kerberos + mit normalen Benutzeraccounts erschwert, obwohl das natürlich + sicherer als die Verwendung von verschlüsselten + Paßwörtern ist. + + + + Absichern der Paßwort-Datei. + + Der einzig sichere Weg ist, soviele Accounts wie möglich als + ungültig zu markieren und ssh oder + Kerberos zu benutzen, um auf sie + zuzugreifen. Obwohl die Datei /etc/spwd.db, + die die verschlüsselten Paßwörter enthält, + nur von root gelesen werden kann, mag ein + Angreifer lesenden Zugriff auf diese Datei erlangen, ohne die + Fähigkeit sie auch zu beschreiben. + + Ihre Überwachungsskripte sollten Änderungen + an der Paßwort-Datei melden (siehe Überprüfen der + Integrität von Dateien weiter unten). + + + + Absichern des Kernels, der Geräte und von + Dateisystemen. + + Wenn ein Angreifer root-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 FreeBSD wird das Gerät + bpf 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 + bpf nicht nötig. + + + sysctl + + Auch wenn Sie bpf nicht verwenden, + müssen Sie sich immer noch um /dev/mem + und /dev/kmem sorgen. Außerdem + kann der Angreifer immer noch auf die rohen Geräte (raw devices) + 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 + bpf oder ein anderes zum Abhören + geeignetes Gerät in den laufenden Kernel einzubringen. Um diese + Probleme zu vermeiden, müssen Sie den Kernel auf einer + höheren Sicherheitsstufe, mindestens 1, + laufen lassen. Die Sicherheitsstufe wird durch die Variable + kern.securelevel, die mit sysctl + gesetzt werden kann, angegeben. Nachdem Sie die Sicherheitsstufe + auf 1 gesetzt haben, sind schreibende Zugriffe + auf rohe Geräte verboten und die speziellen + chflags Optionen, wie schg + werden erzwungen. Sie müssen sicherstellen, daß die + schg Option auf allen kritischen Programmen, + Verzeichnissen und Skripten, die bis zum Setzen der Option laufen, + aktiviert ist. Das mag übertrieben sein da eine Migration + des Systems erschwert wird, wenn Sie auf einer höheren + Sicherheitsstufe arbeiten. Sie können einen Kompromiß + erreichen, indem Sie das System auf einer erhöhten + Sicherheitsstufe laufen lassen, aber die schg + Option nicht für jede Datei und jedes Verzeichnis auf der Welt + setzen. Eine andere Möglichkeit besteht darin, + / und /usr einfach + schreibgeschützt einzuhängen. Bedenken Sie, daß + Sie das Aufdecken eines Einbruchs vielleicht verhindern, wenn + Sie zu drastische Maßnahmen zum Schutz Ihres Systems + verwenden. + + + + Überprüfen der Integrität von Dateien + + 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 chflags die Option schg + auf die meisten Dateien in / und + /usr 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. + + 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, daß + 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ützen Maschine + ssh auf die anderen Maschinen erlauben, + indem Sie ssh 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 ssh + besser geeignet, auch wenn es deutliche Spuren + hinterläßt. + + Wenn das besonders geschützte System lesenden Zugriff + auf die Clients hat, müssen Sie Skripte 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 /etc und /usr/local/etc + 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 + / und /usr. + + Wenn Sie ssh anstelle von NFS + benutzen, wird das Erstellen der Skripte schwieriger. Sie müssen + die Skripte und die Programme wie find mit + scp 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 ssh nötig sein, + wenn Sie über ungesicherte Verbindungen arbeiten, aber + der Umgang mit dieser Methode ist auch sehr viel schwieriger. + + Ein gutes Sicherheitsskript wird auch Dateien von Benutzern, + die den Zugriff auf ein System ermöglichen, wie + .rhosts, .shosts, + .ssh/authorized_keys usw., auf + Veränderungen untersuchen, die über die Möglichkeiten + einer Überprüfung mit MD5, + die ja nur Veränderungen feststellen kann, hinausgehen. + + 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 und den + Zugriff auf Geräte verbieten. &man.mount.8; stellt dazu + die Optionen und + 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. + + Die Prozeßüberwachung (siehe &man.accton.8;) + des Betriebssystems steht ein günstiges Werkzeug zur + Verfügung, daß 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 Prozeßüberwachung sind + noch alle intakt. + + Schließlich sollten die Sicherheitsskripte die Logdateien + analysieren. Dies sollte so sicher wie möglich durchgeführt + werden, nützlich ist das Schreiben von Logdateien auf + entfernte Systeme mit syslog. 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. + + + + Paranoia + + Es schadet nicht, ein bißchen 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. + + + + Denial of Service Angriffe + Denial of Service (DoS) + + 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 allerdings den Schaden in der Hinsicht begrenzen, + daß Ihre Server von einem solchen Angriff nicht gestoppt + werden. + + + + Begrenzen von fork() Aufrufen. + + + + Begrenzen von Sprungbrett-Angriffen (ICMP response Angriffen, + ping zu Broadcast-Adressen usw.). + + + + Kernel-Cache für Routen. + + + + Ein häufiger DoS-Angriff gegen forkende Server versucht + den Server dazu zu bringen, möglichst viele Prozesse, viele + Dateideskriptoren und viel Speicher zu verbrauchen, bis hin zu + dem Punkt, an dem die Maschine ausfällt. &man.inetd.8; + besitzt einige Optionen, um diese Art von Angriffen zu begrenzen. + Beachten Sie bitte, daß 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 Manualseiten + von inetd gut durch und achten Sie speziell + auf die Optionen , und + . Angriffe mit gefälschten IP-Adressen + umgehen , so daß normalerweise eine + Kombination der Optionen benutzt werden muß. Manche Server, + die nicht von inetd gestartet werden, + besitzen Optionen, um den Start über fork() + einzuschränken. + + Sendmail besitzt die Option + , die besser als die + eingebauten Optionen zur Begrenzung der Systemauslastung funktioniert. + Sie sollten beim Start von sendmail + MaxDaemonChildren so hoch setzen, daß Sie + die erwartete Auslastung gut abfangen können. Allerdings + sollten Sie den Wert nicht so hoch setzen, daß der + Rechner über seine eigenen Füße fällt. + Es ist auch klug, sendmail im + Queue-Modus () laufen zu + lassen. Der Dæmon (sendmail -bd) sollte + getrennt von den Queue-Läufen (sendmail -q15m) + laufen. Wenn Sie trotzdem eine sofortige Auslieferung der Post + wünschen, können Sie die Queue in einem geringeren + Intervall, etwa , abarbeiten. Geben Sie + für dieses + sendmail aber einen vernünftigen + Wert für MaxDaemonChildren an, um + Fehler zu verhindern. + + Syslogd kann direkt angegriffen + werden. Daher empfehlen wir Ihnen unbedingt die Option + zu benutzen. Sollte das nicht möglich + sein, benutzen Sie bitte . + + Vorsicht ist auch mit Diensten geboten, die automatisch + eine Rückverbindung eröffnen, wie der + reverse-identd der tcpwrapper. + Diese Eigenschaft der tcpwrapper + sollten Sie normalerweise nicht nutzen. + + 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 root-Zugriff aus dem Netz + zu schützen. Konfigurieren Sie immer eine Firewall, die + alle Zugriffe blockiert, das heißt blockieren Sie + alles 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 + named, wenn Sie den primären + Namensdienst für eine Zone anbieten, + ntalkd oder + sendmail erlauben. Wenn Sie die + Firewall so konfigurieren, das sie in der Voreinstellung alle + Zugriffe erlaubt, ist es sehr wahrscheinlich, daß 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 root benutzt werden dürfen, + zu kompromittieren. Beachten Sie bitte auch, daß es + FreeBSD erlaubt, die Portnummern, die für dynamische + Verbindungen zur Verfügung stehen, zu konfigurieren. + Mit sysctl lassen sich verschiedene + Bereiche der net.inet.ip.portrange Variablen + setzen (eine Liste erhalten Sie mit sysctl -a | fgrep + portrange). + 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. + + ICMP_BANDLIM + + Eine andere Form eines DoS-Angriffs nutzt einen Server + als Sprungbrett, der Server wird dabei so angegriffen, daß + seine Antworten ihn selber, das lokale Netzwerk oder einen + anderen Server überlasten. Der am häufigsten verwendete + Angriff dieser Art ist der ICMP ping broadcast + Angriff. Der Angreifer fälscht dazu + ping-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 ping-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. Eine 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 alle mbuf-Strukturen + auf dem Server aufbrauchen und damit den Server stillegen, + insbesondere wenn der Server nicht in der Lage ist, die generierten + ICMP-Antworten schnell genug abzuführen. Der FreeBSD-Kernel + besitzt eine neue Option , die die + Auswirkungen von solchen Angriffen begrenzen kann. Die letzte + weit verbreitete Form von Sprungbrett-Angriffen verwendet + interne inetd-Dienste wie den + UDP echo-Dienst. Der Angreifer fälscht + dazu einfach ein UDP-Paket, indem er als Quellport den + echo-Port von Server A + und als Zielport den echo-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, + daß er mehrere Pakete dieser Art generiert. Ähnliche + Probleme gibt es mit dem internen + chargen-Port, daher sollten Sie + die internen inetd-Testdienste + abstellen. + + Gefälschte IP-Pakete können dazu benutzt werden, + den Kernel-Cache für Routen zu überlasten. Schauen Sie + sich bitte die sysctl-Parameter + net.inet.ip.rtexpire, rtminexpire + und rtmaxcache an. Ein Angriff der gefälschte + Pakete mit zufälligen Quelladressen einsetzt, bewirkt, daß + der Kernel eine Route im Route-Cache anlegt, die Sie sich mit + netstat -rna | fgrep W3 ansehen können. + Diese Routen verfallen für gewöhnlich nach 1600 Sekunden. + Wenn der Kernel feststellt, daß die Routingtabelle im Cache + zu groß geworden ist, wird er dynamisch den Wert von + rtexpire verringern. Dieser Wert wird aber nie + kleiner werden als rtminexpire. Daraus + ergeben sich zwei Probleme: + + + + Der Kernel reagiert nicht schnell genug, wenn ein + Server mit einer niedrigen Grundlast plötzlich angegriffen + wird. + + + + rtminexpire ist nicht klein genug, + um einen anhaltenden Angriff zu überstehen. + + + + 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 rtexpire und + rtminexpire 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. + + + + Anmerkungen zum Zugriff mit Kerberos und ssh + ssh + Kerberos + + Es gibt ein paar Punkte, die Sie beachten sollten, wenn Sie + Kerberos oder ssh + einsetzen wollen. Kerberos V ist ein + ausgezeichnetes Authentisierungsprotokoll. Leider gibt es + Fehler, in den für Kerberos + angepaßten Versionen von telnet und + rlogin, die sie ungeeignet für den + Umgang mit binären Datenströmen machen. Weiterhin + verschlüsselt Kerberos Ihre Sitzung + nicht, wenn Sie nicht die Option verwenden, + mit ssh wird dagegen alles + verschlüsselt. + + Ein Problem mit SSH sind Weiterleitungen von Verbindungen. + Wenn Sie eine sichere Arbeitsstation besitzen, die Ihnen + Zugriff auf alle anderen Maschinen gibt und von dort eine + Verbindung zu einer ungesicherten Maschine aufmachen, werden Ihre + Schlüssel preisgegeben. Das heißt, Ihre Schlüssel + werden nicht wirklich freigegeben, sondern die SSH erzeugt einen + Port für Weiterleitungen für die Dauer Ihrer Sitzung. + Ein Angreifer, der auf der unsicheren Maschine Zugang zu + root hat, kann diesen Port und Ihre + Schlüssel benutzen, um Zugriff auf andere Maschinen zu + erlangen, die mit Ihren Schlüsseln zugänglich + sind. + + Wir empfehlen Ihnen, für die Logins Ihrer Mitarbeiter immer + ssh zusammen mit + Kerberos einzusetzen. Damit reduzieren + Sie die Abhängigkeit von potentiell gefährdeten + Schlüsseln und schützen gleichzeitig die Paßwörter + mit Kerberos. + ssh-Schlüsselpaare sollten nur + für automatisierte Aufgaben von einem besonders gesicherten + Server eingesetzt werden (Kerberos + kann für diese Art von Aufgaben nicht eingesetzt werden). + Weiterhin empfehlen wir Ihnen, das Weiterreichen von Schlüsseln + in der ssh-Konfiguration abzustellen bzw. + die from=IP/DOMAIN Option in + authorized_keys zu verwenden, die den + Schlüssel nur von bestimmten Maschinen aus nutzbar macht. + + + + + + + + Bill + Swingle + Teile umgeschrieben und aktualisiert von + + + + + + DES, MD5, und <function>crypt()</function> + + Sicherheit + crypt() + + + crypt() + DES + MD5 + + Jedem Benutzer eines Unix-Systems ist ein Paßwort zugeordnet. + Es scheint offensichtlich, daß das Paßwort nur dem Benutzer + und dem System bekannt sein muß. Um die Paßwö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 Paßwort wirklich + nicht, es kennt nur das verschlüsselte + Paßwort. Die einzige Möglichkeit, das originale Paßwort + herauszufinden, besteht darin, alle möglichen Paßwörter + auszuprobieren (brute force Suche). + + Zu der Zeit als Unix entstanden ist, war die einzig sichere + Möglichkeit Paßwö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, mußte 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. + + Die Lösung bestand darin, die Verschlüsselungsbibliotheken + aufzuspalten. Benutzer in den USA konnten die DES-Bibliotheken + installieren und nutzen. In der Grundeinstellung benutzt FreeBSD + MD5 als Verschlüsselungsmethode, das exportiert werden durfte + und damit von jedem genutzt werden konnte. Es wird davon ausgegangen, + daß MD5 sicherer als DES ist, so daß DES nur aus + Kompatibilitätsgründen installiert werden sollte. + + + Erkennen der Verschlüsselungsmethode + + Vor FreeBSD 4.4 war libcrypt.a ein + symbolischer Link, der auf die Library zeigte, die die + Verschlüsselungsroutinen enthielt. Seit FreeBSD 4.4 enthält + libcrypt.a verschiedene Hash-Funktionen, deren + Anwendung sich konfigurieren läßt. Momentan werden + DES-, MD5- und Blowfish-Hash Funktionen unterstützt. In der + Voreinstellung benutzt FreeBSD die MD5-Hash Funktion. + + Sie können leicht herausfinden, welche + Verschlüsselungsmethode von FreeBSD verwendet wird. Ein Weg + besteht darin, die verschlüsselten Paßwörter in + /etc/master.passwd zu untersuchen. + Paßwörter, die mit MD5 verschlüsselt wurden, + sind länger als die mit DES verschlüsselten und + beginnen mit den Zeichen $1$. + Paßwörter, die mit $2$ + anfangen, wurden mit der Blowfish-Funktion verschlüsselt. + DES Paßwörter besitzen keine offensichtlichen Merkmale, + an denen sie identifiziert werden könnten. Sie sind aber + kürzer als MD5-Paßwörter und sind in einem + 64 Zeichen umfassenden Alphabet kodiert, das das + $-Zeichen nicht enthält. Ein relativ + kurzes Paßwort, das nicht mit einem + $-Zeichen anfängt, ist wahrscheinlich + ein DES-Paßwort. + + Die Verschlüsselungsmethode für neue + Paßwörter wird durch passwd_format in + /etc/login.conf bestimmt. Der Wert dieser + Variablen kann entweder des, md5 + oder blf sein. Näheres schlagen Sie bitte + in &man.login.conf.5; nach. + + + + + S/Key + S/Key + + Sicherheit + S/Key + + + S/Key ist ein Einmal-Paßwort System, das auf einer nicht + umkehrbaren Hash-Funktion basiert. Aus Kompatibilitätsgründen + benutzt FreeBSD MD4-Hashes, andere Systeme benutzen MD5 und DES-MAC. + S/Key ist seit Version 1.1.5 Teil des FreeBSD Basissystems und wird + auch auf einer wachsenden Zahl anderer Systeme benutzt. S/Key + ist eine geschützte Warenmarke von + Bell Communications Research, Inc. + + Ab der FreeBSD Version 5.0 wurde S/Key durch OPIE + (Onetime Passwords In Everything), das die gleichen Funktionen + bietet, abgelöst. OPIE benutzt MD5 Hash-Funktionen. + + In der folgenden Diskussion werden drei verschiedene Arten + von Paßwörtern verwendet. Die erste Art ist Ihr normales + Unix oder Kerberos Paßwort, das im folgenden + Unix-Paßwort genannt wird. Die nächste Art + ist das Einmal-Paßwort, das von dem S/Key-Kommando + key oder dem OPIE-Programm opiekey + generiert wird. Dieses Paßwort wird von den Programmen + keyinit oder opiepasswd und + dem Login-Programm akzeptiert. Im folgenden wird es + Einmal-Paßwort genannt. Die letzte Art von + Paßwörtern ist das geheime Paßwort, das Sie + mit den Programmen key/opiekey + (manchmal auch mit + keyinit/opiepasswd) zum Erstellen + der Einmal-Paßwörter verwenden. Dieses Paßwort + werden wir im folgenden geheimes Paßwort + oder schlicht Paßwort nennen. + + Das geheime Paßwort steht in keiner Beziehung zu Ihrem + Unix Paßwort, beide können gleich sein, obwohl das nicht + empfohlen wird. Die geheimen Paßwörter von S/Key oder + OPIE sind nicht auf eine Länge von 8 Zeichen beschränkt. + Sie können so lang sein, wie Sie wollen. Gebräuchlich sind + Paßwörter, die sich aus sechs bis sieben Wörtern + zusammensetzen. Das S/Key oder OPIE System arbeitet + größtenteils unabhängig vom Unix Paßwort + System. + + Neben dem Paßwort gibt es noch zwei Werte, die für + S/Key und OPIE wichtig sind. Der erste ist der + Initialwert (engl. seed oder + key), der aus zwei Buchstaben und fünf Ziffern + besteht. Der andere Wert ist der + Iterationszähler, der eine Zahl zwischen + 1 und 100 ist. S/Key generiert das Einmal-Paßwort, indem + es den Initialwert und das geheime Paßwort aneinander hängt + und dann die MD4/MD5 Hash-Funktion so oft, wie durch den + Iterationszähler gegeben, anwendet. Das Ergebnis wird in + sechs englische Wörter umgewandelt, die Ihr Einmal-Paßwort + sind. Das Authentisierungssystem (meistens PAM) merkt sich das + zuletzt benutzte Einmal-Paßwort und Sie sind authentisiert, + wenn die Hash-Funktion des Paßworts dem vorigen Paßwort + entspricht. Da nicht umkehrbare Hash-Funktionen benutzt werden, + ist es unmöglich, aus einem bekannten Paßwort weitere + gültige Einmal-Paßwö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, müssen S/Key und OPIE neu initialisiert + werden. + + In jedem System werden drei Programme verwendet, die weiter unten + beschrieben werden. Die Programme key und + opiekey verlangen einen Iterationszähler, + einen Initialwert und ein geheimes Paßwort. Daraus generieren + sie ein Einmal-Paßwort oder eine Liste von + Einmal-Paßwörtern. Die Programme keyinit + und opiepasswd werden benutzt, um S/Key bzw. + OPIE zu initialisieren. Mit ihnen können Paßwörter, + Iterationszähler oder Initialwerte geändert werden. + Als Parameter verlangen sie entweder ein geheimes Paßwort + oder einen Iterationszähler oder einen Initialwert und ein + Einmal-Paßwort. Die Programme keyinfo + und opieinfo geben den momentanen + Iterationszähler und Initialwert eines Benutzers aus. Diese + werden aus den Dateien /etc/skeykeys bzw. + /etc/opiekeys ermittelt. + + + Im folgenden werden vier verschiedene Tätigkeiten beschrieben. + Zuerst wird erläutert, wie keyinit oder + opiepasswd über eine gesicherte Verbindung + eingesetzt werden, um Einmal-Paßwörter das erste Mal + zu konfigurieren oder das Paßwort oder den Initialwert + zu ändern. Als nächstes wird erklärt, wie + keyinit oder opiepasswd + über eine nicht gesicherte Verbindung, zusammen mit + key oder opiekey über eine + gesicherte Verbindung, eingesetzt werden, um dasselbe zu erreichen. + Als drittes wird beschrieben, wie + key/opiekey genutzt werden, + um sich über eine nicht gesicherte Verbindung anzumelden. + Die vierte Tätigkeit beschreibt, wie mit key + oder opiekey eine Reihe von Schlüsseln + generiert werden, die Sie sich aufschreiben oder ausdrucken können, + um sich von Orten anzumelden, die über keine gesicherten + Verbindungen verfügen. + + + Einrichten über eine gesicherte Verbindung + + Benutzen Sie keyinit um S/Key das erste + Mal einzurichten, das Paßwort oder den Initialwert + zu ändern, während Sie über eine gesicherte + Verbindung, das heißt an der Konsole oder über ssh + angemeldet, sind: + + &prompt.user; keyinit +Adding unfurl: +Reminder - Only use this method if you are directly connected. +If you are using telnet or rlogin exit with no password and use keyinit -s. +Enter secret password: +Again secret password: + +ID unfurl s/key is 99 to17757 +DEFY CLUB PRO NASH LACE SOFT + + Mit OPIE benutzen Sie stattdessen + opiepasswd: + + &prompt.user; opiepasswd -c +[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 + + + Nach der Aufforderung Enter new secret pass phrase: + oder Enter secret password: geben Sie bitte Ihr + Paßwort ein. Dies ist nicht das Paßwort, mit dem Sie sich + anmelden, sondern es wird genutzt, um das Einmal-Paßwort + zu generieren. Die Zeile, die mit ID 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 Einmal-Paßwort, das aus diesen Parametern + und Ihrem geheimen Paßwort ermittelt wurde. Wenn sie sich jetzt + wieder anmelden wollten, dann müßten Sie dieses + Paßwort benutzen. + + + + Einrichten über eine nicht gesicherte Verbindung + + Um Einmal-Paßwörter über eine nicht gesicherte + Verbindung einzurichten, oder das geheime Paßwort zu ändern, + müssen Sie über eine gesicherte Verbindung zu einer Stelle + verfügen, an der Sie die Kommandos key + oder opiekey ausführen. Dies kann + ein Desk Accessory auf einem Macintosh oder + 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 nutzen können. + Benutzen Sie keyinit -s über die ungesicherte + Verbindung zu der Maschine, die Sie einrichten wollen: + + &prompt.user; keyinit -s +Updating unfurl: +Old key: to17758 +Reminder you need the 6 English words from the key command. +Enter sequence count from 1 to 9999: 100 +Enter new key [default to17759]: +s/key 100 to 17759 +s/key access password: +s/key access password:CURE MIKE BANE HIM RACY GORE + + + Mit OPIE benutzen Sie opiepasswd: + + &prompt.user; opiepasswd + +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 + + + Drücken Sie Return, um die Vorgabe + für den Initialwert, der von keyinit + key genannt wird, zu akzeptieren. Bevor + Sie nun das Zugriffspaßwort (engl. access password) + eingeben, rufen Sie über die gesicherte Verbindung + key mit denselben Parametern auf: + + &prompt.user; key 100 to17759 +Reminder - Do not use this program while logged in via telnet or rlogin. +Enter secret password: <secret password> +CURE MIKE BANE HIM RACY GORE + + Mit OPIE benutzen Sie opiekey: + + &prompt.user; opiekey 498 to4268 +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 + + + Gehen Sie nun zurück zu der nicht gesicherten Verbindung + und geben dort das eben generierte Einmal-Paßwort ein. + + + + Erzeugen eines einzelnen Einmal-Paßwortes + + Nachdem Sie S/Key oder OPIE eingerichtet haben, werden Sie beim + nächsten Anmelden wie folgt begrüßt: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +s/key 97 fw13894 +Password: + + OPIE begrüßt Sie wie folgt: + +&prompt.user; telnet example.com +Trying 10.0.0.1... +Connected to example.com +Escape character is '^]'. + +FreeBSD/i386 (example.com) (ttypa) + +login: <username> +otp-md5 498 gr4269 ext +Password: + + Anmerkung: S/Key und OPIE besitzen eine nützliche Eigenschaft, + die hier nicht gezeigt ist. Wenn Sie an der Eingabeaufforderung + Return eingeben, wird die echo-Funktion eingeschaltet, + das heißt Sie sehen, was Sie tippen. Dies ist besonders + nützlich, wenn Sie ein generiertes Paßwort von einem + Ausdruck abtippen müssen. + + MS-DOS + Windows + MacOS + + Jetzt müssen Sie Ihr Einmal-Paßwort generieren, + um der Anmeldeaufforderung nachzukommen. Dies muß auf + einem gesicherten System geschehen, auf dem Sie key + oder opiekey ausführen können. + Diese Programme gibt es übrigens auch für DOS, Windows und + MacOS. Beide Programme benötigen den Iterationszähler + sowie den Initialwert als Parameter, die Sie mittels + cut-and-paste direkt von der Login Aufforderung + nehmen können. + + Auf dem sicheren System: + + &prompt.user; key 97 fw13894 +Reminder - Do not use this program while logged in via telnet or rlogin. +Enter secret password: +WELD LIP ACTS ENDS ME HAAG + + Mit OPIE: + + &prompt.user; opiekey 498 to4268 +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 + + Mit dem jetzt generierten Einmal-Paßwort können + Sie die Anmeldeprozedur fortsetzen: + + login: <username> +s/key 97 fw13894 +Password: <return to enable echo> +s/key 97 fw13894 +Password [echo on]: WELD LIP ACTS ENDS ME HAAG +Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ... + + + + + Erzeugen von mehreren Einmal-Paßwörtern + + 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 key einige Einmal-Paßwörter + generieren, die Sie sich ausdrucken und mitnehmen können. + Zum Beispiel: + + &prompt.user; key -n 5 30 zz99999 +Reminder - Do not use this program while logged in via telnet or rlogin. +Enter secret password: <secret password> +26: SODA RUDE LEA LIND BUDD SILT +27: JILT SPY DUTY GLOW COWL ROT +28: THEM OW COLA RUNT BONG SCOT +29: COT MASH BARR BRIM NAN FLAG +30: CAN KNEE CAST NAME FOLK BILK + + Mit fordern Sie fünf + Paßwörter der Reihe nach an. Der letzte + Iterationszähler wird durch gegeben. + Beachten Sie bitte, daß die Paßwörter in der + umgekehrten Reihenfolge, in der sie + zu benutzen sind, ausgeben werden. Wenn Sie wirklich paranoid + sind, schreiben Sie sich jetzt die Paßwörter auf, + ansonsten drucken Sie sie mit lpr aus. + Beachten Sie, daß jede Zeile den Iterationszähler + und das Einmal-Paßwort zeigt. Trotzdem finden Sie es + vielleicht hilfreich, eine Zeile nach Gebrauch durchzustreichen. + + + + Einschränken der Benutzung von Unix + Paßwörtern + + Basierend auf dem Hostnamen, Benutzernamen, Terminal oder + IP-Adresse, können Sie die Verwendung von Unix + Paßwörtern einschränken. Die Beschränkungen + werden in /etc/skey.access definiert. Die + Manualseite &man.skey.access.5; beschreibt das Format dieser + Datei sowie einige Vorsichtsmaßnahmen, + die Sie treffen sollten, bevor Sie diese Datei einsetzen. + + Wenn /etc/skey.access nicht existiert und + das ist unter FreeBSD die Vorgabe, dann dürfen sich alle Benutzer + mit Unix Paßwörtern anmelden. Wenn die Datei existiert, + dann müssen alle Benutzer S/Key zum Anmelden benutzen. Ausnahmen + müssen explizit in skey.access konfiguriert + werden. In allen Fällen werden Unix Paßwörter + beim Anmelden auf der Konsole erlaubt. + + Das folgende Beispiel zeigt die drei häufigsten + Ausnahmen: + + permit internet 192.168.0.0 255.255.0.0 +permit user fnord +permit port ttyd0 + + Die erste Zeile (permit internet) erlaubt + es Benutzern, deren IP-Adresse, die immer noch gefälscht werden + kann, mit dem angegebenen Wert und der angegebenen Maske + übereinstimmt, Unix Paßwörter zu benutzen. Dies + sollte nicht als Sicherheitsmechanismus mißverstanden werden, + sondern sollte autorisierte Benutzer daran erinnern, daß sie + ein ungesichertes Netzwerk benutzen und sich mit S/Key anmelden + müssen. + + Die zweite Zeile (permit user) erlaubt + es dem angegebenen Benutzer, hier fnord, + jederzeit Unix Paßwörter zu verwenden. Dies sollte + allerdings nur für Benutzer konfiguriert werden, die das + key Programm nicht nutzen können (Leute + mit dump Terminals oder wirklich uneinsichtige). + + Die dritte Zeile (permit port) erlaubt allen + Benutzern, die sich an dem angegebenen Terminal anmelden, Unix + Paßwörter zu benutzen. Sie sollte für + Einwählverbindungen genutzt werden. + + + + + + + + Mark + Murray + Beigesteuert von + + + + + Mark + Dapoz + Basiert auf einem Beitrag von + + + + + Kerberos + Kerberos + + Kerberos ist ein zusätzliches Netzwerkprotokoll, das es + Benutzern erlaubt, sich über einen sicheren Server zu + authentifizieren. Dienste wie rlogin, + rcp oder das sichere Kopieren von Dateien + zwischen Systemen und andere risikoreiche Tätigkeiten werden + durch Kerberos erheblich sicherer und kontrollierbarer. + + Die folgende Anleitung kann nur als Wegweiser dazu dienen, wie + Sie Kerberos für FreeBSD aufsetzen. Für eine komplette + Beschreibung des Systems, sollten Sie sich auf jeden Fall die + entsprechenden Manual-Seiten ansehen. + + + Installation von Kerberos + + MIT + + Kerberos + Installation + + Kerberos ist eine optionale Komponente von FreeBSD. Am leichtesten + installieren Sie die Software, wenn Sie bei der ersten Installation + von FreeBSD in sysinstall die + Distribution 'krb4' oder 'krb5' auswählen. Damit installieren + Sie entweder die 'eBones' (KerberosIV) oder 'Heimdal' (Kerberos5) + Version von Kerberos. Beide Versionen werden mit FreeBSD ausgeliefert, + da sie außerhalb von den USA oder Kanada entwickelt werden. + Sie unterliegen deshalb auch nicht den restriktiven + Exportbeschränkungen der USA und sind auch für + Bewohner anderer Länder zugänglich. + + Als Alternative steht die MIT Variante von Kerberos in der + Ports-Kollektion unter security/krb5 zur + Verfügung. + + + + Erstellen der initialen Datenbank + + Die folgenden Schritte werden nur auf dem Kerberos-Server + durchgeführt. Stellen Sie bitte vorher sicher, daß + keine alten Kerberos-Datenbanken mehr vorhanden sind. Im + Verzeichnis /etc/kerberosIV sollten sich nur + die folgenden Dateien befinden: + + &prompt.root; cd /etc/kerberosIV +&prompt.root; ls +README krb.conf krb.realms + + Wenn noch andere Dateien, wie principal.* + oder master_key, existieren, müssen + Sie die alte Kerberos-Datenbank mit kdb_destroy + löschen. Wenn Kerberos nicht läuft, können Sie + die Dateien auch einfach löschen. + + Sie sollten nun die Dateien krb.conf und + krb.realms editieren, um Ihr Kerberos-Realm zu + definieren. Das folgende Beispiel zeigt dies für das Realm + EXAMPLE.COM auf dem Server + grunt.example.com. + krb.conf sollte wie folgt aussehen: + + &prompt.root; cat krb.conf +EXAMPLE.COM +EXAMPLE.COM grunt.example.com admin server +CS.BERKELEY.EDU okeeffe.berkeley.edu +ATHENA.MIT.EDU kerberos.mit.edu +ATHENA.MIT.EDU kerberos-1.mit.edu +ATHENA.MIT.EDU kerberos-2.mit.edu +ATHENA.MIT.EDU kerberos-3.mit.edu +LCS.MIT.EDU kerberos.lcs.mit.edu +TELECOM.MIT.EDU bitsy.mit.edu +ARC.NASA.GOV trident.arc.nasa.gov + + Die zusätzlich aufgeführten Realms brauchen Sie nicht + anzulegen. Sie zeigen hier nur, wie man Kerberos dazu bringt, andere + Realms zu erkennen. Sie können Sie also auch weglassen. + + Die erste Zeile benennt das Realm, in dem das System arbeitet. + Die anderen Zeilen enthalten Realm/Host Paare. Der erste Wert jeder + Zeile ist das Realm, der zweite Teil ein Host, der in diesem + Realm Key Distribution Center ist. Die + Schlüsselwörter admin server nach einem + Hostnamen bedeuten, daß dieser Host auch einen administrativen + Datenbankserver zur Verfügung stellt. Weitere Erklärungen zu + diesen Begriffen finden Sie in den Kerberos Manual-Seiten. + + Als nächstes muß + grunt.example.com in das Realm + EXAMPLE.COM aufgenommen werden. Desweiteren + erstellen wir einen Eintrag, der alle Rechner der Domäne + .example.com in das Realm + EXAMPLE.COM aufnimmt. + krb.realms sollte danach so aussehen: + + &prompt.root; cat krb.realms +grunt.example.com EXAMPLE.COM +.example.com EXAMPLE.COM +.berkeley.edu CS.BERKELEY.EDU +.MIT.EDU ATHENA.MIT.EDU +.mit.edu ATHENA.MIT.EDU + + Die zusätzlichen Realms sind hier wieder als Beispiel + gedacht. Sie können sie der Einfachheit halber auch + weglassen. + + Die erste Zeile nimmt ein einzelnes System + in das Realm auf. Die anderen Zeilen zeigen, wie bestimmte + Subdomänen einem bestimmten Realm zugeordnet werden. + + Das folgende Kommando muß nur auf dem Kerberos-Server + (oder Key Distribution Center) laufen. Mit + kdb_init können wir die Datenbank + anlegen: + + &prompt.root; kdb_init +Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM +You will be prompted for the database Master Password. +It is important that you NOT FORGET this password. + +Enter Kerberos master key: + + Anschließend muß der Schlüssel gespeichert + werden, damit Server auf der lokalen Maschine darauf zugreifen + können. Dies geschieht mit kstash: + + &prompt.root; kstash + +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! + + Das verschlüsselte Master-Paßwort wurde in + /etc/kerberosIV/master_key gesichert. + + + + Anlegen von Prinzipals + + Für jedes System, das mit Kerberos + gesichert werden soll, müssen zwei Prinzipale in die + Datenbank eingetragen werden. Ihre Namen sind + kpasswd und rcmd. Beide + Prinzipale müssen für jedes System angelegt werden, wobei + die Instanz der Name des jeweiligen Systems ist. + + Die Dæmonen kpasswd und + rcmd erlauben es anderen Systemen, + Kerberos-Paßwörter zu ändern und Kommandos wie + rcp, rlogin und + rsh laufen zu lassen. + + Beide Einträge werden im folgenden angelegt: + + &prompt.root; kdb_edit +Opening database... + +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: passwd +Instance: grunt + +<Not found>, Create [y] ? y + +Principal: passwd, Instance: grunt, kdc_key_ver: 1 +New Password: <---- geben Sie hier Zufallswerte ein +Verifying password + +New Password: <---- geben Sie hier Zufallswerte ein + +Random password [y] ? y + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: rcmd +Instance: grunt + +<Not found>, Create [y] ? + +Principal: rcmd, Instance: grunt, kdc_key_ver: 1 +New Password: <---- geben Sie hier Zufallswerte ein +Verifying password + +New Password: <---- geben Sie hier Zufallswerte ein + +Random password [y] ? + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- geben Sie nichts an, um das Programm zu verlassen + + + + Erstellen der Server-Datei + + Wir müssen nun für jede Maschine die Instanzen, + die Dienste definieren, aus der Datenbank mit + ext_srvtab extrahieren. Die erstelle Datei + muß auf einem sicheren Weg in das + /etc/kerberosIV Verzeichnis jedes Clients + kopiert werden. Die Datei muß auf jedem Server und auf + jedem Client vorhanden sein und ist unabdingbar für + Kerberos. + + &prompt.root; ext_srvtab grunt +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +Generating 'grunt-new-srvtab'.... + + Das Kommando erzeugt Dateien mit einem temporären Namen, + der es anderen Servern erlaubt, ihre Datei abzuholen. Die Datei + muß auf dem entsprechenden System in srvtab + umbenannt werden. Auf dem originalen System können Sie + mv benutzen, um die Datei umzubenennen: + + &prompt.root; mv grunt-new-srvtab srvtab + + Wenn die Datei für ein Client-System bestimmt ist und das + Netzwerk nicht sicher ist, kopieren Sie die Datei auf ein bewegliches + Medium und transportieren sie physikalisch. Kopieren Sie die Datei + auf den Client in das Verzeichnis /etc/kerberosIV + und benennen Sie sie in srvtab um. Setzen Sie + schließlich noch die Berechtigungen auf 600: + + &prompt.root; mv grumble-new-srvtab srvtab +&prompt.root; chmod 600 srvtab + + + + Füllen der Datenbank + + Wir können nun Benutzer in der Datenbank anlegen. Mit + kdb_edit legen wir zuerst die Benutzerin + jane an: + + &prompt.root; kdb_edit +Opening database... + +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: jane +Instance: + +<Not found>, Create [y] ? y + +Principal: jane, Instance: , kdc_key_ver: 1 +New Password: <---- geben Sie ein sicheres Paßwort ein +Verifying password + +New Password: <---- wiederholen Sie die Eingabe +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- geben Sie nichts an, um das Programm zu verlassen + + + + Testen + + Zuerst müssen die Kerberos-Dæmonen gestartet sein. + Wenn Sie /etc/rc.conf richtig angepaßt haben, + passiert das automatisch, wenn Sie booten. Dieser Schritt ist nur + auf dem Kerberos-Server notwendig, die Clients bekommen alles + was sie brauchen aus dem /etc/kerberosIV + Verzeichnis. + + &prompt.root; kerberos & +Kerberos server starting +Sleep forever on error +Log file is /var/log/kerberos.log +Current Kerberos master key version is 1. + +Master key entered. BEWARE! + +Current Kerberos master key version is 1 +Local realm: EXAMPLE.COM +&prompt.root; kadmind -n & +KADM Server KADM0.0A initializing +Please do not use 'kill -9' to kill this job, use a +regular kill instead + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! + + Jetzt können wir mit kinit versuchen, + ein Ticket für die ID jane, die wir + oben angelegt haben, zu erhalten: + + &prompt.user; kinit jane +MIT Project Athena (grunt.example.com) +Kerberos Initialization for "jane" +Password: + + Mit klist können Sie sich vergewissern, + daß Sie die Tickets auch erhalten haben: + + &prompt.user; klist +Ticket file: /tmp/tkt245 +Principal: jane@EXAMPLE.COM + + Issued Expires Principal +Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM + + Versuchen Sie nun das Paßwort mit passwd + zu ändern, um zu überprüfen, daß der + kpasswd Dæmon auch auf der + Kerberos-Datenbank autorisiert ist: + + &prompt.user; passwd +realm EXAMPLE.COM +Old password for jane: +New Password for jane: +Verifying password +New Password for jane: +Password changed. + + + + Anlegen von <command>su</command> Privilegien + + Mit Kerberos kann jedem Benutzer, der + root-Privilegien braucht, ein + eigenes Paßwort für + su zugewiesen werden. Dies wird dadurch + erreicht, daß die Instanz eines Prinzipals + root ist. Mit kbd_edit + legen wir nun den Eintrag jane.root in der + Kerberos-Datenbank an: + + &prompt.root; kdb_edit +Opening database... + +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: jane +Instance: root + +<Not found>, Create [y] ? y + +Principal: jane, Instance: root, kdc_key_ver: 1 +New Password: <---- geben Sie ein sicheres Paßwort ein +Verifying password + +New Password: <---- geben Sie das Paßwort erneut ein + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- geben Sie nichts an, um das Programm zu verlassen + + Versuchen Sie nun, für diesen Prinzipal Tickets zu + bekommen: + + &prompt.root; kinit jane.root +MIT Project Athena (grunt.example.com) +Kerberos Initialization for "jane.root" +Password: + + Als nächstes fügen wir den Prinzipal in + .klogin von root ein: + + &prompt.root; cat /root/.klogin +jane.root@EXAMPLE.COM + + Jetzt benutzen wir su: + + &prompt.user; su +Password: + + und kontrollieren, welche Tickets wir haben: + + &prompt.root; klist +Ticket file: /tmp/tkt_root_245 +Principal: jane.root@EXAMPLE.COM + + Issued Expires Principal +May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM + + + + Weitere Kommandos + + In einem der Beispiele haben wir einen Prinzipal mit + dem Namen jane und der Instanz + root angelegt. Der Prinzipal entstand aus + einem Benutzer mit dem gleichen Namen. Unter Kerberos ist es + Standard, daß ein + <principal>.<instance> der Form + <username>.root es dem + Benutzer <username> erlaubt, mit + su root zu werden, wenn die + entsprechenden Einträge in .klogin von + root existieren: + + &prompt.root; cat /root/.klogin +jane.root@EXAMPLE.COM + + Das gilt auch für die .klogin-Datei + im Heimatverzeichnis eines Benutzers: + + &prompt.user; cat ~/.klogin +jane@EXAMPLE.COM +jack@EXAMPLE.COM + + Die Einträge erlauben jedem, der sich im Realm + EXAMPLE.COM als jane oder + jack mit kinit authentifiziert + hat, über rlogin, rsh + oder rcp Zugriff auf den Account + jane und dessen Dateien. + + Im folgenden Beispiel meldet sich jane + mit Kerberos auf grunt an: + + &prompt.user; kinit +MIT Project Athena (grunt.example.com) +Password: +&prompt.user; rlogin grunt +Last login: Mon May 1 21:14:47 from grumble +Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 + The Regents of the University of California. All rights reserved. + +FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 + + Im folgenden Beispiel wurde der Prinzipal jack + mit einer Instanz null angelegt. Mit der obigen + .klogin-Datei kann er sich nun auf derselben + Maschine als jane anmelden: + + &prompt.user; kinit +&prompt.user; rlogin grunt -l jane +MIT Project Athena (grunt.example.com) +Password: +Last login: Mon May 1 21:16:55 from grumble +Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 + The Regents of the University of California. All rights reserved. +FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 + + + + + + + + Gary + Palmer + Beigetragen von + + + Alex + Nash + + + + + Firewalls + Firewall + + Sicherheit + Firewalls + + + Firewalls sind sehr wichtig für Leute, die mit dem Internet + verbunden sind. Weiterhin halten sie Einzug in private Netzwerke, um + dort die Sicherheit zu verbessern. Dieser Abschnitt erklärt, + was Firewalls sind, wie sie benutzt werden und wie man die + Möglichkeiten von FreeBSD nutzen kann, um eine Firewall zu + implementieren. + + + Es wird oft gedacht, daß eine Firewall zwischen dem internen + Netzwerk und dem weiten, schlechten Internet + alle Sicherheitsprobleme löst. Eine Firewall kann die Sicherheit + erhöhen, doch eine schlecht aufgesetzte Firewall ist ein + größeres Sicherheitsrisiko als gar keine Firewall. Eine + Firewall ist nur eine weitere Sicherheitsschicht, sie verhindert + aber nicht, daß ein wirklich entschlossener Cracker in + Ihr internes Netz eindringt. Wenn Sie Ihre interne Sicherheit + vernachlässigen, weil Sie Ihre Firewall für undurchdringlich + halten, machen Sie den Crackern die Arbeit leichter. + + + + Was ist eine Firewall? + + Auf dem Internet sind momentan zwei Arten von Firewalls + gebräuchlich. Die erste Art ist ein + Paketfilter, in dem ein Kernel auf einer + Maschine mit mehreren Netzwerkverbindungen auf Grund von Regeln + entscheidet, ob er ein Paket weiterleitet oder nicht. Der zweite + Typ sind Proxy-Server, die auf Dæmonen + angewiesen sind. Die Dæmonen authentifizieren Benutzer + und leiten Pakete weiter, das heißt sie können auf + Maschinen mit mehreren Netzwerkverbindungen laufen, auf denen + das Weiterleiten von Paketen durch den Kernel ausgeschaltet ist. + + Manchmal werden beide Arten einer Firewall kombiniert und es + ist nur einer besonderen Maschine, die + Bastion Host genannt wird, erlaubt, Pakete + in das interne Netzwerk über einen Paketfilter zu schicken. + Auf dem Bastion Host laufen Proxy-Dienste, die im allgemeinen + sicherer als normale Authentisierungsmechanismen sind. + + FreeBSD besitzt einen Kernel-Paketfilter (IPFW), der im Rest + dieses Abschnitts behandelt wird. Proxy-Server können + mit Hilfe von Software von Drittherstellern auf FreeBSD realisiert + werden, doch gibt es so viele Proxy-Server, daß deren + Behandlung den Rahmen dieses Abschnitts sprengen würde. + + + Packet-Filter + + Ein Router ist eine Maschine, die Pakete zwischen zwei oder + mehr Netzwerken weiterleitet. Ein Paketfilter ist ein spezieller + Router, der extra Code im Kernel hat, der es im erlaubt, die + Pakete mit Regeln zu vergleichen, bevor er das Paket weiterleitet. + Um die Filter zu aktivieren, müssen Sie zuerst die Regeln + definieren, die festlegen, ob ein Paket weitergeleitet wird oder + nicht. + + Um zu entscheiden, ob ein Paket weitergeleitet wird, sucht der + Code des Paketfilters eine Regel, die auf den Inhalt des Paketheaders + paßt. Wenn eine passende Regel gefunden wurde, wird die Aktion + der Regel ausgeführt. Die Aktion kann das Paket blockieren, + weiterleiten oder auch dem Sender eine ICMP-Nachricht schicken. + Die Regeln werden der Reihenfolge nach durchsucht und nur die + erste passende Regel wird angewandt. Daher wird auch von einer + Regelkette gesprochen. + + Die Kriterien, nach denen Sie ein Paket spezifizieren + können, hängen von der eingesetzten Software ab. + Typischerweise können Sie Pakete nach der Quell-IP Adresse, + der Ziel IP-Adresse, dem Quellport, dem Zielport (bei Protokollen, + die diese unterscheiden) oder dem Pakettyp (UDP, TCP, ICMP) + unterscheiden. + + + + Proxy-Server + + Auf Proxy-Servern werden die normalen Systemdienste + (telnetd, ftpd, + usw.) durch besondere Server ersetzt. Diese Server werden + Proxy-Server genannt, da sie normalerweise + nur weitergehende Verbindungen erlauben (proxy engl. für + Stellvertreter). Zum Beispiel können Sie auf Ihrer + Firewall einen Proxy-Telnet Server laufen lassen, der es Personen + erlaubt, aus dem Internet auf die Firewall eine Telnet-Verbindung + zu öffnen. Dort laufen Sie durch einen + Authentisierungsmechanismus und haben dann Zugriff auf Ihr + internes Netzwerk. Für den umgekehrten Weg können Sie + natürlich auch Proxy-Server einsetzen. + + Proxy-Server sind in aller Regel sicherer als normale Server + und bieten oft eine Reihe von Authentisierungsmechanismen. Dazu + gehören Einmal-Paßwort Systeme, bei denen das zum + Anmelden verwendete Paßwort sofort ungültig wird und + nicht zu einer weiteren Anmeldung benutzt werden kann, auch wenn + es abgehört wurde. Da Proxy-Server den Benutzern keinen + Zugang zu dem System geben, wird es für einen Angreifer + sehr schwer, Hintertüren zur Umgehung Ihres Sicherheitssystems + zu installieren. + + Mit Proxy-Servern lassen sich die Zugriffe meist noch weiter + beschränken. Der Zugriff kann auf bestimmte Rechner + eingeschschränkt werden und oft ist es möglich, + festzulegen, welcher Benutzer mit welcher Zielmaschine kommunizieren + darf. Welche Möglichkeiten Sie haben, hängt stark + von der Proxy-Software ab, die Sie einsetzen. + + + + + Was kann ich mit IPFW machen? + ipfw + + IPFW, das von FreeBSD zur Verfügung gestellt wird, + ist ein Paketfilter und ein Accounting-System, das im Kernel + läuft und mit &man.ipfw.8; ein Werkzeug im Userland + zur Verfügung stellt. Beide Teile zusammen erlauben es Ihnen, + die Regeln für Routing Entscheidungen im Kernel zu definieren + oder abzufragen. + + In IPFW gibt es zwei zusammenhängende Teile. Mit der + Firewall können Sie einen Paketfilter konfigurieren. Das + IP-Accounting Modul erlaubt es Ihnen, mit ähnlichen Regeln + wie den Firewall-Regeln, die Nutzung Ihres Routers zu überwachen. + Damit können Sie zum Beispiel sehen, wieviel Verkehr auf + Ihrem Router von einer bestimmten Maschine kommt oder wieviel + WWW (World Wide Web) Verkehr durch Ihren Router geht. + + Durch das Design von IPFW können Sie IPFW auch auf + nicht-Routern einsetzen und einen Paketfilter für eingehende + und ausgehende Verbindungen konfigurieren. Dies ist ein Spezialfall + der allgemeinen Anwendung von IPFW und es werden daher die gleichen + Kommandos und Techniken benutzt. + + + + Aktivieren von IPFW + + ipfw + aktivieren + + + Der größte Teil des IPFW-Systems befindet sich im + Kernel, daher müssen Sie die Konfigurationsdatei des Kernels + editieren und anschließend den Kernel neu übersetzen. + Das Kapitel "Konfiguration des FreeBSD Kernels" + + beschreibt, wie Sie dazu vorzugehen haben. + + Momentan gibt es drei Optionen in der Kernelkonfiguration, die + IPFW betreffen: + + + + options IPFIREWALL + + + Fügt den Paketfilter-Code in den Kernel ein. + + + + + options IPFIREWALL_VERBOSE + + + Aktiviert das Loggen von Paketen mit &man.syslogd.8;. + Ohne diese Option werden keine Pakete geloggt, auch wenn Sie + in den Filterregeln das Loggen angeben. + + + + + options IPFIREWALL_VERBOSE_LIMIT=10 + + + Begrenzt die Anzahl der über &man.syslogd.8; + geschriebenen Einträge. Die Option ist in Umgebungen + mit hoher Aktivität nützlich, in denen Sie die + Firewall Aktivitäten loggen möchten, aber einem + Angreifer nicht die Möglichkeit eines Denial of Service + Angriffs durch das Überlasten von syslog geben + wollen. + + Erreicht eine Regel der Regelkette die angegebene Grenze, + so wird für diesen Eintrag das Loggen abgestellt. Um + das Loggen von Paketen wieder zu aktivieren, müssen Sie + den Zähler mit &man.ipfw.8; zurücksetzen: + + &prompt.root; ipfw zero 4500 + Hier ist 4500 die Nummer der Regel in + der Regelkette, für die Sie das Log weiterführen + möchten. + + + + + Frühere Versionen von FreeBSD stellten die Option + IPFIREWALL_ACCT zur Verfügung. Die Option + ist mittlerweile überholt, da der Firewall Code automatisch + Accounting Möglichkeiten bereitstellt. + + + + + Konfiguration von IPFW + + ipfw + Konfiguration + + + Mit &man.ipfw.8; konfigurieren Sie die IPFW-Software. Die + Syntax dieses Kommandos sieht ziemlich kompliziert aus, doch wenn + Sie einmal den Aufbau der Kommandos verstanden haben, ist es sehr + einfach. + + Das Kommando unterstützt vier verschiedene Operationen: + Hinzufügen/Löschen, Anzeigen und Zurücksetzen von + Regeln, sowie das Zurücksetzen von Paketzählern. Die + Operationen Hinzufügen/Löschen werden genutzt um die + Regeln, nach denen Pakete akzeptiert, blockiert oder geloggt + werden, zu erstellen. Die Operation Anzeigen zeigt die Regelkette + und die Paketzähler an. Die Operation Zurücksetzen + löscht alle Regeln der Regelkette. Mit der letzten Operation + können Sie ein oder mehrere Paketzähler auf den Wert Null + zurücksetzen. + + + Ändern der IPFW-Regeln + + Die Syntax für diese Operation lautet: + + ipfw + -N + Kommando + index + Aktion + log + Protokoll + Adressen + Optionen + + + Dieser Aufruf unterstützt eine Option: + + + + -N + + + Löst Adressen und Namen von Diensten in der + Ausgabe auf. + + + + + Kommando kann auf die kürzeste + eindeutige Länge reduziert werden. Gültig sind die + Werte: + + + + add + + + Fügt einen Eintrag in die Firewall/Accounting + Regelkette ein. + + + + + delete + + + Löscht einen Eintrag in der Firewall/Accounting + Regelkette. + + + + + Frühere Versionen von IPFW verfügten über + getrennte Firewall- und Accounting-Einträge in der Regelkette. + In der jetzigen Version steht das Accounting für jeden + Eintrag in der Firewall-Regelkette zur Verfügung. + + Wenn ein Wert für index angegeben + ist, so wird die Regel an entsprechender Stelle in die Regelkette + eingefügt. Ansonsten wird die Regel an das Ende der Kette + gestellt, wobei der Index um 100 größer ist als der + Index der letzten Regel (die voreingestellte letzte Regel mit der + Nummer 65535 wird in diesem Verfahren nicht + berücksichtigt). + + Wenn der Kernel mit IPFIREWALL_VERBOSE + erstellt wurde, gibt die Regel mit der Option + log Meldungen auf der Systemkonsole + aus. + + Gültige Werte für Aktion + sind: + + + + reject + + + Blockiert das Paket und schickt dem Sender die + ICMP-Nachricht host or port unreachable. + + + + + allow + + + Leitet das Paket normal weiter. Zulässige Aliase + sind pass und + accept. + + + + + deny + + + Blockiert das Paket und benachrichtigt den Sender + nicht mit einer ICMP-Nachricht. Dem + Sender kommt es so vor, als hätte das Paket sein Ziel + nie erreicht. + + + + + count + + + Erhöht den Paketzähler für diese Regel, + trifft aber keine Entscheidung wie mit dem Paket zu + verfahren ist, das heißt die nächste Regel der + Kette wird auf das Paket angewendet. + + + + + Es ist möglich die kürzeste eindeutige Form der + Aktion anzugeben. + + Für Protokoll können die + folgenden Werte angegeben werden: + + + + all + + + Trifft auf jedes IP-Paket zu. + + + + + icmp + + + Paßt auf jedes ICMP-Paket. + + + + + tcp + + + Paßt auf jedes TCP-Paket. + + + + + udp + + + Trifft auf jedes UDP-Paket zu. + + + + + Die Syntax für Adresse + lautet: + + + from + Adresse/MaskePort + to + Adresse/MaskePort + via Interface + + + Port können Sie nur angeben, + wenn das Protokoll auch Ports + unterstützt (UDP und TCP). + + ist optional und gibt die IP-Adresse, + den Domainnamen eines lokalen Interfaces oder den Namen des + Interfaces (z.B. ed0) an und trifft nur + auf Pakete zu, die durch dieses Interface gehen. Die Nummern der + Interfaces können mit einem Platzhalter angegeben werden, + ppp* trifft auf alle Kernel-PPP Interfaces + zu. + + Adresse/Maske können Sie wie + folgt angeben: + + Adresse + + oder + + Adresse/Bitmaske + + oder + + Adresse:Maskenmuster + + + Anstelle einer IP-Adresse können Sie einen gültigen + Hostnamen angeben. + ist eine + dezimale Zahl, die angibt, wieviele Bits in der Adressmake + gesetzt werden sollen. Die Angabe + 192.216.222.1/24 erstellt eine Maske, die auf + jede Adresse des Klasse C Subnetzes 192.216.222 zutrifft. + Das + wird mit der gegebenen IP-Adresse logisch UND verknüpft. + Das Schlüsselwort any trifft auf jede + IP-Adresse zu. + + Die Portnummern werden wie folgt angegeben: + + + Port,Port,Port… + + + gibt entweder einen einzelnen Port oder eine Liste von Ports an + + + Port-Port + + + gibt einen Portbereich an. Sie können einen einzelnen + Bereich mit einer Liste kombinieren, müssen aber den Bereich + immer zuerst angeben. + + Die verfügbaren Optionen + sind: + + + + frag + + + Trifft auf Pakete zu, die nicht das erste Fragment + eines Datagrams sind. + + + + + in + + + Trifft auf eingehende Pakete zu. + + + + + out + + + Trifft auf ausgehende Pakete zu. + + + + + ipoptions spec + + + Trifft auf alle IP-Pakete zu, deren Header die in + spec angegebenen, durch Kommata + separierte, Optionen enthalten. Die unterstützten + IP-Optionen sind: ssrr (strict source + route), lsrr (loose source route), + rr (record packet route), und + ts (time stamp). Ein führendes + ! trifft auf alle Pakete zu, die diese + Option nicht gesetzt haben. + + + + + established + + + Trifft auf alle Pakete zu, die zu einer schon + bestehenden TCP-Verbindung gehören, das heißt + das RST- oder ACK-Bit ist gesetzt. Sie können den + Durchsatz der Firewall verbessern, wenn Sie die + established Regeln soweit wie + möglich an den Anfang der Regelkette stellen. + + + + + setup + + + Paßt auf alle Pakete, die versuchen eine + TCP-Verbindung aufzubauen, das heißt das SYN-Bit ist + gesetzt und das ACK-Bit ist nicht gesetzt. + + + + + tcpflags flags + + + Trifft auf alle Pakete zu, die im TCP-Header eine der + durch Kommata getrennten Option gesetzt haben. Die + gültigen Optionen sind: fin, + syn, rst, + psh, ack und + urg. Mit einem führenden + ! kann die Abwesenheit einer Option + erzwungen werden. + + + + + icmptypes types + + + Trifft auf ICMP-Pakete vom Typ + types. Hier kann eine + Kommata separierte Aufzählung von Bereichen oder + einzelnen Typen angegeben werden. Gebräuchliche Typen + sind: 0 echo reply (ping reply), + 3 destination unreachable, + 5 redirect, 8 echo + request (ping request) und 11 time + exceeded, das die Überschreitung der TTL angibt und + zum Beispiel von &man.traceroute.8; genutzt wird. + + + + + + + Anzeigen der IPFW-Regeln + + Die Syntax für dieses Kommando lautet: + + ipfw + -a + -t + -N + l + + + Drei Optionen sind für diese Form gültig: + + + + -a + + + Zeigt die Paketzähler zu den Regeln an. Diese + Option ist die einzige Möglichkeit, die Zähler zu + sehen. + + + + + -t + + + Zeigt die Zeit, zu der die Regel zuletzt aktiviert + wurde. Die Syntax dieser Ausgabe ist nicht kompatibel mit + der Eingabesyntax von &man.ipfw.8;. + + + + + -N + + + Versucht Adressen und Namen von Diensten + aufzulösen. + + + + + + + Zurücksetzen der IPFW-Regeln + + Die Regeln setzen Sie wie folgt zurück: + + ipfw + flush + + + Damit werden alle Regeln der Regelkette, mit Ausnahme der + Vorgaberegel 65535 gelöscht. Seien Sie + vorsichtig, wenn Sie die Regeln zurücksetzen. Die Vorgabe + für die Regel 65535 ist es, alle Pakete + zu blockieren, das heißt, das System ist solange vom + Netzwerk abgeschnitten, bis wieder neue Regeln in die Kette + eingefügt werden. + + + + Zurücksetzen der Paketzähler + + Um einen oder mehrere Paketzähler zurückzusetzen, + verwenden Sie folgende Syntax: + + ipfw + zero + index + + + Wenn Sie das Argument index nicht + angeben, werden alle Paketzähler zurückgesetzt. Wenn + Sie das Argument angeben, wird nur der Zähler der + angegebenen Regel zurückgesetzt. + + + + + Beispiel für <application>ipfw</application> + Kommandozeilen + + Das folgende Kommando blockiert alle Pakete, die von dem Host + evil.crackers.org auf den Telnet-Port + von nice.people.org gehen: + + &prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23 + + Das nächste Beispiel verbietet jeden IP-Verkehr von dem + ganzen crackers.org Klasse C + Netzwerk zu der Maschine nice.people.org: + + &prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org + + Wenn Sie X-Sessions zu Ihrem internen Netzwerk, einem Subnetz + eines C Klasse Netzwerkes, verbieten wollen, wenden Sie das + folgende Kommando an: + + &prompt.root; ipfw add deny tcp from any to my.org/28 6000 setup + + Um die Accounting Einträge zu sehen: + + &prompt.root; ipfw -a list + + oder kürzer + + &prompt.root; ipfw -a l + + + Den Zeitpunkt, an dem eine Regel das letzte Mal aktiviert + wurde, sehen Sie mit: + + &prompt.root; ipfw -at l + + + + Aufbau einer Firewall mit Paketfiltern + + + Beachten Sie bitte, daß die folgenden Vorschläge + wirklich nur Vorschläge sind. Die Anforderungen jeder + Firewall sind verschieden und wir können Ihnen wirklich + nicht sagen, wie Sie Ihre maßgeschneiderte Firewall aufsetzen + müssen. + + + Wenn Sie Ihre Firewall außerhalb eines kontrollierten + Testumfelds aufbauen, empfehlen wir Ihnen dringend, das Loggen der + Regeln im Kernel zu aktivieren und Regeln zu verwenden, die loggen. + Das macht es Ihnen leichter, Fehler zu finden und diese ohne + große Unterbrechungen zu beheben. Auch nachdem Sie die + Firewall aufgesetzt haben, empfehlen wir Ihnen, die `deny'-Regeln + zu loggen. Dies macht es leichter, Angriffen nachzugehen und das + Regelwerk Ihrer Firewall zu ändern, wenn sich die Anforderungen + einmal ändern. + + + Wenn Sie Pakete der accept-Regel loggen, + denken Sie bitte daran, daß Sie leicht sehr + große Datenmengen erzeugen können, da jedes + durchgelassene Paket einen Eintrag im Log generiert. Es kann + vorkommen, das große FTP oder HTTP Übertragungen das + System langsamer machen. Weiterhin wird für jedes der + betroffenen Pakete die Latenzzeit erhöht, da von Seiten des + Kernels mehr Arbeit zum Weiterleiten des Paketes erfoderlich ist. + Da alle Daten auf die Platte ausgeschrieben werden wird + syslogd auch mehr Prozessorzeit + beanspruchen und es kann leicht passieren, daß die + Partition, die /var/log enthält voll + läuft. + + + Sie sollten Ihre Firewall aus + /etc/rc.conf.local oder + /etc/rc.conf aktivieren. Die entsprechende + Manual-Seite zeigt Ihnen, welche Einstellungen Sie vornehmen + müssen und zeigt einige vorgegebene Firewall-Konfigurationen. + Wenn Sie keine der Vorgaben verwenden, können Sie Ihre + Regelkette mit ipfw list in eine Datei ausgeben + und diese Datei in /etc/rc.conf angeben. Wenn + sie weder /etc/rc.conf.local oder + /etc/rc.conf benutzen, um Ihre Firewall zu + aktivieren, stellen Sie bitte sicher, daß die Firewall + aktiviert ist, bevor die IP-Interfaces konfiguriert werden. + + Als nächstes müssen Sie festlegen, was Ihre Firewall + machen soll. Das wird sehr stark davon abhängen welche + Zugriffe Sie von außen auf Ihr Netzwerk erlauben wollen und + welche Zugriffe von innen nach außen erlaubt sein sollen. + Einige gebräuchliche Regeln sind: + + + + Blockieren Sie jeden einkommenden Zugriff auf Ports unter + 1024 für TCP. Dort befinden sich die meisten der + sicherheitsrelevanten Dienste wie finger, SMTP (Post) und + telnet. + + + + Blockieren Sie jeden einkommenden + UDP-Verkehr. Es gibt wenige nützliche UDP-Dienste und + die, die nützlich sind, stellen meist eine Bedrohung der + Sicherheit dar (z.B. die RPC- und NFS-Protokolle von Sun). + Dies bringt allerdings auch Nachteile mit sich. Da UDP ein + verbindungsloses Protokoll ist, verbieten Sie auch die + Antworten auf ausgehende UDP-Pakete, wenn Sie eingehende + UDP-Verbindungen blockieren. Dies kann zum Beispiel Probleme + für Anwender des internen Netzwerks hervorrufen, wenn + diese einen externen Archie-Server (prospero) verwenden. Wenn + Sie den Zugriff auf Archie erlauben wollen, müssen Sie + Pakete von den Ports 191 und 1525 zu jedem internen UDP-Port + durch Ihre Firewall lassen. Ein anderer Dienst, den Sie + vielleicht erlauben wollen, ist ntp, + der vom Port 123 ausgeht. + + + + Verbieten Sie Verkehr von außen zum Port 6000. Der + Port 6000 wird für den Zugriff auf X-Server genutzt und + kann eine Bedrohung der Sicherheit darstellen, insbesondere + wenn die Anwender gewohnt sind xhost + zu + benutzen. Tatsächlich kann X einen Bereich von Ports + verwenden, der bei 6000 anfängt. Die Obergrenze ist durch + die Zahl der Displays, die auf einer Maschine laufen, gegeben. + Laut RFC 1700 (Assigned Numbers) hat der höchst + mögliche Port die Nummer 6063. + + + + Überprüfen Sie, welche Ports von internen Servern + (z.B. SQL-Servern) benutzt werden. Da diese normalerweise aus + dem oben angesprochenen Bereich von 1-1024 fallen, ist es + wahrscheinlich gut, diese Ports ebenfalls zu blockieren. + + + + Eine Checkliste zum Aufbau einer Firewall ist vom CERT unter + http://www.cert.org/tech_tips/packet_filtering.html + erhältlich. + + Wie oben schon gesagt, können wir Ihnen nur + Richtlinien geben. Sie müssen selbst + entscheiden, welche Regeln Sie auf Ihrer Firewall einsetzen wollen. + Wir übernehmen keine Verantwortung + dafür, daß jemand in Ihr Netzwerk eindringt, auch wenn + Sie die obigen Ratschläge befolgt haben. + + + + + OpenSSL + + security + OpenSSL + + OpenSSL + + Das OpenSSL-Toolkit ist seit FreeBSD 4.0 Teil des Basissystems. + OpenSSL stellt eine + universale Kryptographie Bibliothek sowie die Protokolle Secure + Sockets Layer v2/v3 (SSLv2/SSLv3) und Transport Layer Security v1 + (TLSv1) zur Verfügung. + + Einer der Algorithmen, namentlich IDEA, in OpenSSL ist durch + Patente in den USA und anderswo geschützt und daher nicht frei + verfügbar. IDEA ist Teil des Quellcodes von OpenSSL wird aber + in der Voreinstellung nicht kompiliert. Wenn Sie den Algorithmus + benutzen wollen und die Lizenzbedingungen erfüllen, können + Sie MAKE_IDEA in + /etc/make.conf aktivieren und das System mit + make world neu bauen. + + Der RSA-Algorithmus ist heute in den USA und anderen Ländern + frei verfügbar. Früher wurde er ebenfalls durch ein Patent + geschützt. + + + OpenSSL + Installation + + + + Installation vom Quellcode + + OpenSSL ist Teil der src-crypto und + src-secure CVSup-Kollektionen. Mehr Informationen + über die Erhältlichkeit und das Aktualisieren des FreeBSD + Quellcodes erhalten Sie im Abschnitt + Beschaffung von FreeBSD. + + + + + + + + + Yoshinobu + Inoue + Beigetragen von + + + + + + IPsec + IPsec + + Sicherheit + IPsec + + + + Abschließende Zeichen + Am Ende der Beispiele in diesem und anderen Abschnitten werden + Sie oft ein ^D sehen. Das bedeutet, daß Sie + die Control-Taste zusammen mit der Taste + D drücken sollen. Eine weiterere häufig + genutzte Kombination ist ^C. Hier drücken Sie + die Taste Control zusammen mit der + C-Taste. + + + + HOWTOs, die die Implementation von IPSec in FreeBSD + beschreiben, finden Sie unter + und . + + + IPSec stellt eine sichere Kommunikation auf IP- und Socket-Ebene + zur Verfügung. Der folgende Abschnitt zeigt wie Sie IPSec + benutzen. Weitere Einzelheiten können Sie dem + + Entwickler Handbuch + + entnehmen. + + Die aktuelle Version von IPSec unterstützt den + Transport-Modus sowie den Tunnel-Modus, wobei der Tunnel-Modus einige + Beschränkungen besitzt. Unter http://www.kame.net/newsletter/ + finden Sie weitere Beispiele. + + Um IPSec benutzen zu können, müssen Sie folgende + Optionen in Ihren Kernel kompiliert haben: + + options IPSEC #IP security +options IPSEC_ESP #IP security (crypto; define w/IPSEC) + + + Transport-Modus mit IPv4 + + Um zwischen zwei Rechnern, im folgenden Beispiel HOST A + (10.2.3.4) und HOST B (10.6.7.8) sicher zu kommunizieren, + müssen wir zuerst eine + Sicherheitsassoziation einrichten. Das + folgende Beispiel benutzt den alten AH (Authentication Header) + von HOST A zu HOST B. Für die Kommunikation von HOST B + zu HOST A wird der neue AH mit dem neuen ESP (Encapsulating + Security Payload) kombiniert. + + Zu den Verfahren AH, neuer AH, + ESP und neuem ESP müssen nun + Algorithmen ausgewählt werden. Die zur Verfügung + stehenden Algorithmen werden in &man.setkey.8; erläutert. Wir + entschieden uns für die Kombinationen MD5 für AH, + new-HMAC-SHA1 für neuen AH und new-DES-expIV mit 8 Byte IV + für den neuen ESP. + + Die Schlüsselänge hängt stark vom + gewählten Algorithmus ab. Für MD5 beträgt sie 16 + Bytes, für new-HMAC-SHA1 20 Bytes und 8 Bytes für + new-DES-expIV. Wie wählten jeweils die Schlüssel + MYSECRETMYSECRET, + KAMEKAMEKAMEKAMEKAME und PASSWORD. + + Als nächstes müssen wir jedem Protokoll einen SPI + (Security Parameter Index) zuweisen. Beachten Sie bitte, daß + wir 3 SPIs benötigen, da drei Header erzeugt werden (einer + für die Kommunikation von HOST A zu HOST B und zwei für + die Kommunikation von HOST B zu HOST A). Beachten Sie weiterhin, + daß die SPIs größer oder gleich 256 sein + müssen. Im folgenden Beispiel haben wir uns für 1000, + 2000 und 3000 entschieden. + + + (1) + HOST A ------> HOST B + + (1)PROTO=AH + ALG=MD5(RFC1826) + KEY=MYSECRETMYSECRET + SPI=1000 + + (2.1) + HOST A <------ HOST B + <------ + (2.2) + + (2.1) + PROTO=AH + ALG=new-HMAC-SHA1(new AH) + KEY=KAMEKAMEKAMEKAMEKAME + SPI=2000 + + (2.2) + PROTO=ESP + ALG=new-DES-expIV(new ESP) + IV length = 8 + KEY=PASSWORD + SPI=3000 + + + Um die Sicherheitsassoziation einzurichten, führen Sie + &man.setkey.8; auf HOST A und HOST B aus: + + +&prompt.root; setkey -c +add 10.2.3.4 10.6.7.8 ah-old 1000 -m transport -A keyed-md5 "MYSECRETMYSECRET" ; +add 10.6.7.8 10.2.3.4 ah 2000 -m transport -A hmac-sha1 "KAMEKAMEKAMEKAMEKAME" ; +add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; +^D + + + Bevor Sie die Kommunikation mit IPSec nutzen können, + müssen Sie noch eine Sicherheits-Policy auf beiden Rechnern + einrichten: + + +Auf Host A: + +&prompt.root; setkey -c +spdadd 10.2.3.4 10.6.7.8 any -P out ipsec + ah/transport/10.2.3.4-10.6.7.8/require ; +^D + +Auf Host B: + +&prompt.root; setkey -c +spdadd 10.6.7.8 10.2.3.4 any -P out ipsec + esp/transport/10.6.7.8-10.2.3.4/require ; +spdadd 10.6.7.8 10.2.3.4 any -P out ipsec + ah/transport/10.6.7.8-10.2.3.4/require ; +^D + + + HOST A --------------------------------------> HOST E + 10.2.3.4 10.6.7.8 + | | + ========== old AH keyed-md5 ==========> + + <========= new AH hmac-sha1 =========== + <========= new ESP des-cbc ============ + + + + + Transport-Modus mit IPv6 + + Das folgende Beispiel zeigt die Nutzung von IPSec mit + IPv6. + + Das folgende Beispiel richtet den ESP Transport-Modus für + TCP Verbindungen zwischen HOST B Port 110 und HOST A ein. + + + ============ ESP ============ + | | + Host-A Host-B + fec0::10 -------------------- fec0::11 + + + Der Algorithmus zum Verschlüsseln ist blowfish-cbc, der + zugehörige Schlüssel ist kamekame. + Für die Authentifizierung wird hmac-sha1 mit dem + Schlüssel this is the test key verwendet. Auf + HOST A geben Sie die folgenden Befehle ein: + + + &prompt.root; setkey -c <<EOF + spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec + esp/transport/fec0::10-fec0::11/use ; + spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec + esp/transport/fec0::11-fec0::10/use ; + add fec0::10 fec0::11 esp 0x10001 + -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + add fec0::11 fec0::10 esp 0x10002 + -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + EOF + + + Entsprechend auf HOST B: + + &prompt.root; setkey -c <<EOF + spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec + esp/transport/fec0::11-fec0::10/use ; + spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec + esp/transport/fec0::10-fec0::11/use ; + add fec0::10 fec0::11 esp 0x10001 -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + add fec0::11 fec0::10 esp 0x10002 -m transport + -E blowfish-cbc "kamekame" + -A hmac-sha1 "this is the test key" ; + EOF + + + Beachten Sie bitte die Richtung der erstellen Security + Policy. + + + + Tunnel-Modus mit IPv4 + + Das folgende Beispiel baut einen Tunnel zwischen zwei Gateways + auf. + + Als Protokoll wird der alte AH Tunnel-Modus (RFC 1826) + verwendet. Zur Authentifizierung wird keyed-md5 mit dem + Schlüssel this is the test verwendet. + + + ======= AH ======= + | | + Network-A Gateway-A Gateway-B Network-B + 10.0.1.0/24 ---- 172.16.0.1 ----- 172.16.0.2 ---- 10.0.2.0/24 + + + Der Gateway A wird wie folgt konfiguriert: + + + &prompt.root; setkey -c <<EOF + spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec + ah/tunnel/172.16.0.1-172.16.0.2/require ; + spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec + ah/tunnel/172.16.0.2-172.16.0.1/require ; + add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any + -A keyed-md5 "this is the test" ; + add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any + -A keyed-md5 "this is the test" ; + + EOF + + + Wenn wie oben die Portnummer weggelassen wird, wird + [any] verwendet. Mit -m wird + der Modus der Sicherheitsassoziation angegeben. + -m any gilt für den Transport- sowie den + Tunnel-Modus. + + Auf Gateway B geben Sie folgendes ein: + + + &prompt.root; setkey -c <<EOF + spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec + ah/tunnel/172.16.0.2-172.16.0.1/require ; + spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec + ah/tunnel/172.16.0.1-172.16.0.2/require ; + add 172.16.0.1 172.16.0.2 ah-old 0x10003 -m any + -A keyed-md5 "this is the test" ; + add 172.16.0.2 172.16.0.1 ah-old 0x10004 -m any + -A keyed-md5 "this is the test" ; + + EOF + + + + + Tunnel-Modus mit IPv6 + + Transport- und Tunnel-Modus zwischen zwei Gateways + + Zwischen Gateway A und Gateway B soll der AH Transport-Modus + und der ESP Tunnel-Modus eingerichtet werden. In diesem Fall wird + zuerst der ESP-Tunnel eingerichtet, danach folgt das Einrichten des + AH Transport-Modus. + + + ========== AH ========= + | ======= ESP ===== | + | | | | + Network-A Gateway-A Gateway-B Network-B + fec0:0:0:1::/64 --- fec0:0:0:1::1 ---- fec0:0:0:2::1 --- fec0:0:0:2::/64 + + + Für ESP wird 3des-cbc zur Verschlüelung und hmac-sha1 + zur Authentifizierung verwendet. Bei AH wird zur Authentifizerung + hmac-md5 benutzt. Auf Gateway A sieht die Konfiguration wie folgt + aus: + + + &prompt.root; setkey -c <<EOF + spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec + esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require + ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ; + spdadd fec0:0:0:2::/64 fec0:0:0:1::/64 any -P in ipsec + esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require + ah/transport/fec0:0:0:2::1-fec0:0:0:1::1/require ; + add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10001 -m tunnel + -E 3des-cbc "kamekame12341234kame1234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:1::1 fec0:0:0:2::1 ah 0x10001 -m transport + -A hmac-md5 "this is the test" ; + add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10001 -m tunnel + -E 3des-cbc "kamekame12341234kame1234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:2::1 fec0:0:0:1::1 ah 0x10001 -m transport + -A hmac-md5 "this is the test" ; + + EOF + + + Im folgenden werden zwei Sicherheitsassoziationen mit + unterschiedlichen Endpunkten erstellt. + + Zwischen Host A und Gateway A soll ein ESP-tunnel eingerichtet + werden. Zur Verschlüsselung wird cast128-cbc und zur + Authentifizierung wird hmac-sha1 verwendet. Zusätzlich wird + zwischen Host A und Host B der ESP Transport-Modus eingerichtet. + Zur Verschlüsselung wird rc5-cbc verwendet. Die + Authentifizerung verwendet hmac-md5. + + + ================== ESP ================= + | ======= ESP ======= | + | | | | + Host-A Gateway-A Host-B + fec0:0:0:1::1 ---- fec0:0:0:2::1 ---- fec0:0:0:2::2 + + + Host A wird wie folgt konfiguriert: + + + &prompt.root; setkey -c <<EOF + spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec + esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use + esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ; + spdadd fec0:0:0:2::1[80] fec0:0:0:1::1[any] tcp -P in ipsec + esp/transport/fec0:0:0:2::2-fec0:0:0:l::1/use + esp/tunnel/fec0:0:0:2::1-fec0:0:0:1::1/require ; + add fec0:0:0:1::1 fec0:0:0:2::2 esp 0x10001 + -m transport + -E cast128-cbc "12341234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:1::1 fec0:0:0:2::1 esp 0x10002 + -E rc5-cbc "kamekame" + -A hmac-md5 "this is the test" ; + add fec0:0:0:2::2 fec0:0:0:1::1 esp 0x10003 + -m transport + -E cast128-cbc "12341234" + -A hmac-sha1 "this is the test key" ; + add fec0:0:0:2::1 fec0:0:0:1::1 esp 0x10004 + -E rc5-cbc "kamekame" + -A hmac-md5 "this is the test" ; + + EOF + + + + + + + + + Chern + Lee + Beigetragen von + + + + + + OpenSSH + OpenSSH + + Sicherheit + OpenSSH + + + Secure Shell stellt Werkzeuge bereit, um sicher auf entfernte + Maschinen zuzugreifen. Die Kommandos rlogin, + rsh, rcp und + telnet können durch ssh ersetzt werden. + Zusätzlich können andere TCP/IP-Verbindungen sicher durch + ssh weitergeleitet (getunnelt) werden. Mit ssh werden alle + Verbindungen verschlüsselt, dadurch wird verhindert, daß + die Verbindung zum Beispiel abgehört oder übernommen + (Hijacking) werden kann. + + OpenSSH wird vom OpenBSD Projekt gepflegt und basiert auf + SSH v1.2.12 mit allen aktuellen Fixen und Aktualisierungen. OpenSSH + ist mit den SSH Protokollen der Versionen 1 und 2 kompatibel. Seit + FreeBSD 4.0 ist die OpenSSH Teil des Basissystems. + + + Vorteile von OpenSSH + + 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/Paßwort Kombinationen + oder alle Daten an + beliebiger Stelle zwischen dem Client und dem Server abgehört + werden. Mit OpenSSH stehen eine Reihe von Authentisierungs- und + Verschlüsselungsmethoden zur Verfügung, um das zu + verhindern. + + + + Aktivieren von sshd + + OpenSSH + Aktivieren + + + Stellen Sie sicher, daß /etc/rc.conf + die folgende Zeile enthält: + sshd_enable="YES" + Der ssh Dæmon wird damit bei + dem nächsten Neustart des Systems geladen. Alternativ + können Sie den Dæmon auch händisch starten. + + + + SSH Client + + OpenSSH + Client + + + &man.ssh.1; arbeitet ähnlich wie &man.rlogin.1;: + + &prompt.root ssh user@example.com +Host key not found from the list of known hosts. +Are you sure you want to continue connecting (yes/no)? yes +Host 'example.com' added to the list of known hosts. +user@example.com's password: ******* + + Der Anmeldevorgang wird danach, wie von + rlogin oder telnet gewohnt, + weiterlaufen. SSH speichert einen Fingerabdruck des + Serverschlüssels. Die Aufforderung, yes + 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 + ~/.ssh/known_hosts, die der Version 2 in + ~/.ssh/known_hosts2 gespeichert. + + In der Voreinstellung akzeptieren OpenSSH Server Verbindungen + mit SSH v1 und SSH v2. Die Clients können sich aber das + Protokoll auswählen, dabei wird das Protokoll der Version 2 + als robuster und sicherer als die Vorgängerversion + angesehen. + + Mit den Optionen oder + kann die Protokollversion, die ssh verwendet, + erzwungen werden. + + + + Secure Copy + + OpenSSH + secure copy + + scp + + Mit scp lassen sich Dateien analog wie mit + rcp auf entfernte Maschinen kopieren. Mit + scp werden die Dateien allerdings in einer + sicheren Weise übertragen. + + &prompt.root scp user@example.com:/COPYRIGHT COPYRIGHT +user@example.com's password: +COPYRIGHT 100% |*****************************| 4735 +00:00 +&prompt.root + Da der Fingerabdruck schon im vorigen Beispiel abgespeichert + wurde, wird er bei der Verwendung von scp in + diesem Beispiel überprüft. Da die Fingerabdrücke + übereinstimmen, wird keine Warnung ausgegeben. + + Die Argumente, die scp übergeben + werden, gleichen denen von cp in der Beziehung, + daß 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 + + besitzen. + + + + + Konfiguration + + OpenSSH + Konfiguration + + + Die für das ganze System gültigen + Konfigurationsdateien des OpenSSH Dæmons und des Clients + finden sich in dem Verzeichnis + /etc/ssh. + + Die Client-Konfiguration befindet sich in + ssh_config, die des Servers befindet sich in + sshd_config. + + Das SSH-System läßt sich weiterhin über die + Anweisungen (Vorgabe ist + /usr/sbin/sshd) und + in /etc/rc.conf + konfigurieren. + + + + ssh-keygen + + Mit &man.ssh-keygen.1; können RSA-Schlüssel für + einen Benutzer erzeugt werden, die anstelle von + Paßwörtern verwendet werden können. + + &prompt.user ssh-keygen +Initializing random number generator... +Generating p: .++ (distance 66) +Generating q: ..............................++ (distance 498) +Computing the keys... +Key generation complete. +Enter file in which to save the key (/home/user/.ssh/identity): +Enter passphrase: +Enter the same passphrase again: +Your identification has been saved in /home/user/.ssh/identity. +... + + &man.ssh-keygen.1; erzeugt einen öffentlichen und einen + privaten Schlüssel für die Authentisierung. Der private + Schlüssel wird in ~/.ssh/identity, der + öffentliche Schlüssel in + ~/.ssh/identity.pub gespeichert. Damit die + RSA-Schlüssel zur Authentisierung verwendet werden + können, muß der öffentliche Schlüssel in der + Datei ~/.ssh/authorized_keys auf der + entfernten Maschine abgelegt werden. + + Damit werden Verbindungen zu der entfernten Maschine über + den RSA-Mechanismus anstelle von Paßwörtern + authentifiziert. + + Wenn bei der Erstellung der Schlüssel mit + &man.ssh-keygen.1; ein Paßwort angegeben wurde, wird der + Benutzer bei jeder Anmeldung zur Eingabe des Paßworts + aufgefordert. + + Zum gleichen Zweck kann ein DSA-Schlüssel zur Verwendung + mit SSH v2 erstellt werden. Dazu rufen Sie das Kommando + ssh-keygen -d oder ssh-keygen -t + dsa mit FreeBSD &os.current; auf. Sie erzeugen damit ein + DSA-Schlüsselpaar, das nur in SSH v2 Verbindungen genutzt + wird. Der öffentliche Schlüssel wird in + ~/.ssh/id_dsa.pub, der private Schlüssel + in ~/.ssh/id_dsa gespeichert. + + Die öffentlichen DSA-Schlüssel werden in + ~/.ssh/authorized_keys2 auf der entfernten + Maschine abgelegt. + + Mit &man.ssh-agent.1; und &man.ssh-add.1; können Sie + mehrere durch Paßwörter geschützte private + Schlüssel verwalten. + + + + SSH Tunnel + + OpenSSH + Tunnel + + + Mit OpenSSH ist es möglich, einen Tunnel zu erstellen, in + dem ein anderes Protokoll verschlüsselt übertragen + wird. + + Das folgende Kommando erzeugt einen Tunnel für + telnet: + + &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com +&prompt.user; + + Dabei wurden die folgenden Option von ssh + verwendet: + + + + + + + Zwingt ssh die Version 2 des Protokolls + zu benutzen (Benutzen Sie das nicht mit älteren + ssh-Servern). + + + + + + + + Zeigt an, daß ein Tunnel erstellt werden soll. + Ohne diese Option würde ssh eine + normale Sitzung öffnen. + + + + + + + + Zwingt ssh im Hintergrund zu + laufen. + + + + + + + + Ein lokaler Tunnel wird in der Form + localport:remotehost:remoteport + angegeben. Die Verbindung wird dabei von dem lokalen Port + localport auf einen entfernten + Rechner weitergeleitet. + + + + + + + + Gibt den entfernten SSH server an. + + + + + + Ein SSH-Tunnel erzeugt ein Socket auf + localhost und dem angegebenen Port. Jede + Verbindung, die auf dem angegebenen Socket aufgemacht wird, wird + dann auf den spezifizierten entfernten Rechner und Port + weitergeleitet. + + Im Beispiel wird der Port 5023 auf + die entfernte Maschine und dort auf localhost + Port 23 weitergeleitet. Da der Port + 23 für Telnet reserviert ist, + erzeugt das eine sichere Telnet Verbindung durch einen + SSH-Tunnel. + + Diese Vorgehensweise kann genutzt werden, um jedes unsichere + TCP-Protokoll wie SMTP, POP3, FTP, usw. weiterzuleiten. + + + Mit SHH einen sicheren Tunnel für SMTP erstellen&prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com +user@mailserver.example.com's password: ***** +&prompt.user; telnet localhost 5025 +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +220 mailserver.example.com ESMTP + + Zusammen mit &man.ssh-keygen.1; und zusätzlichen + Benutzer-Accounts können Sie leicht benutzbare SSH-Tunnel + aufbauen. Anstelle von Paßwörtern können Sie + Schlüssel benutzen und jeder Tunnel kann unter einem eigenen + Benutzer laufen. + + + + Beispiel für SSH-Tunnel + + + Sicherer Zugriff auf einen POP3-Server + + 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. + + &prompt.user; ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com +user@ssh-server.example.com's password: ****** + + Wenn Sie den Tunnel eingerichtet haben, konfigurieren Sie + Ihren Mail-Client so, daß er POP3 Anfragen zu + localhost Port 2110 sendet. Die Verbindung + wird dann sicher zu mail.example.com + weitergeleitet. + + + + Umgehen einer strengen Firewall + + Einige Netzwerkadministratoren stellen sehr drakonische + Firewall-Regeln auf, die nicht nur einkommende Verbindungen + filtern, sondern auch ausgehende. Es kann sein, daß Sie + externe Maschinen nur über die Ports 22 und 80 (SSH und + Web) erreichen. + + 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. + + 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. + + &prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled.myserver.com +user@unfirewalled.myserver.com's password: ******* + + Konfigurieren Sie Ihren Client so, daß er + localhost und Port 8888 benutzt. Die Verbindung + wird dann zu music.example.com Port 8000 + weitergeleitet und Sie haben die Firewall erfolgreich + umgangen. + + + + + + Weiterführende Informationen: + OpenSSH + &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; + &man.ssh-agent.1; &man.ssh-add.1; + &man.sshd.8; &man.sftp-server.8; + + + + + + +