MatthewDillonViel von diesem Kapitel stammt aus der security(7)
Manualpage von MartinHeinenÜbersetzt von SicherheitSicherheitÜbersichtDieses Kapitel bietet eine Einführung in die Konzepte
der Systemsicherheit. Neben einigen Daumenregeln werden
weiterführende Themen wie S/Key, OpenSSL und Kerberos
diskutiert. Die meisten der hier besprochenen Punkte treffen
sowohl auf die Systemsicherheit sowie die Internetsicherheit zu.
Das Internet hat aufgehört ein friedlicher
Ort zu sein, an dem Sie nur nette Leute finden werden. Es ist
unumgänglich, dass Sie Ihre Daten, Ihr geistiges Eigentum,
Ihre Zeit und vieles mehr vor dem Zugriff von Hackern
schützen.&os; 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 &os; bezogene Sicherheitsaspekte
kennen.Die verschiedenen Verschlüsselungsmechanismen
von &os;, wie DES oder
MD5, kennen.Wissen, wie Sie ein Einmalpasswörter
zur Authentifizierung verwenden.TCP-Wrapper für
inetd einrichten können.Wissen, wie Sie KerberosIV
vor 5.0-Release einrichten.Wissen, wie Sie Kerberos5
unter &os; einrichten.Firewalls mit IPFW
erstellen können.Wissen, wie Sie IPsec konfigurieren und ein
VPN zwischen &os;/&windows;
Systemen einrichten,OpenSSH, &os;s
Implementierung von SSH, konfigurieren
und benutzen können.Portaudit anwenden können,
um Softwarepakete Dritter, die Sie über die
Ports-Sammlung installieren, auf bekannte
Sicherheitslücken hin zu überprüfen.Mit &os;-Sicherheitshinweisen umgehen können.Eine Vorstellung davon haben, was Prozessüberwachung
(Process Accounting) ist und wie
Sie diese Funktion unter &os; aktivieren können.Bevor Sie dieses Kapitel lesen, sollten SieGrundlegende Konzepte von &os; und dem Internet
verstehen.Dieses Buch behandelt weitere Sicherheitsthemen.
Beispielsweise werden vorgeschriebene Zugriffskontrollen
in und Firewalls in
besprochen.EinführungSicherheit 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.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 Accounts.Kompromittierter root-Account durch
zugreifbare Server.Kompromittierter root-Account durch
kompromittierte Accounts.Einrichten von Hintertüren.DoS AngriffeDenial-of-Service (DoS)SicherheitDoS AngriffeDenial-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.Sicherheitkompromittierte AccountsKompromittierte Accounts 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, dass
das Passwort eines oder mehrerer Benutzer ausgespäht wurde.
Ein aufmerksamer Systemadministrator wird die Logs über Anmeldungen
von entfernten Systemen auf verdächtige Quelladressen, auch
für erfolgreiche Anmeldungen, untersuchen.Es ist immer davon auszugehen, dass ein Angreifer, der
Zugriff auf einen Account hat, Zugang zum
root-Account erlangt. Allerdings gibt der
Zugriff auf einen Account 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 stilllegen. Kompromittierte Accounts sind sehr
häufig, da Benutzer meist nicht dieselben Vorsichtsmaßnahmen
wie Administratoren treffen.SicherheitHintertürenEs gibt viele Wege, Zugang zum root-Account
eines Systems zu bekommen: Ein Angreifer kann das Passwort 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 Account 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, dass 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
Accounts.Absichern von unter root laufenden
Servern und SUID/SGID Programmen.Absichern von Accounts.Absichern der Passwort-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.Absichern von &os;Sicherheit&os; absichernKommandos und ProtokolleIn diesem Abschnitt werden Anwendungen
fett gekennzeichnet, spezifische
Kommandos werden in einer Fixschrift
dargestellt und Protokolle verwenden die normale Schriftart.
Diese typographische Konvention hilft, Begriffe wie ssh
zu unterscheiden, die sowohl Protokoll als auch Kommando
sein können.Die folgenden Abschnitte behandeln die im
letzten Abschnitt erwähnten
Methoden Ihr &os;-System zu sichern.Absichern von root und
AccountssuZuallererst, kümmern Sie sich nicht um die Absicherung
von Accounts, wenn Sie root
noch nicht abgesichert haben. Auf den meisten Systemen ist
root ein Passwort zugewiesen. Sie
sollten immer davon ausgehen, dass
dieses Passwort kompromittiert ist. Das heißt nicht,
dass Sie das Passwort entfernen sollten, da es meist
für den Konsolenzugriff notwendig ist. Vielmehr heißt
es, dass Sie das Passwort nicht außerhalb der
Konsole, auch nicht zusammen mit &man.su.1;, verwenden sollten.
Stellen Sie sicher, dass Ihre PTYs in ttys als
unsicher markiert sind und damit Anmeldungen von
root mit telnet oder
rlogin verboten sind. Wenn Sie andere
Anwendungen wie SSH zum Anmelden
benutzen, vergewissern Sie sich, dass dort ebenfalls
Anmeldungen als root verboten sind. Für
SSH editieren Sie
/etc/ssh/sshd_config und überprüfen,
dass 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.wheelNatürlich müssen Sie als Systemadministrator
root-Zugriff erlangen können. Dieser
sollte aber durch zusätzliche Passwö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
Authentifizierungsmethoden müssen Sie niemanden in
wheel aufnehmen. Wenn Sie z.B.
Kerberos benutzen, 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.Um ein Konto komplett zu sperren, verwenden Sie den Befehl
&man.pw.8;:&prompt.root;pw lock staffDanach ist es diesem Benutzer nicht mehr möglich (auch
nicht mit &man.ssh.1;), sich anzumelden.Eine weitere Möglichkeit, bestimmte Benutzer zu sperren,
ist es, das verschlüsselte Passwort durch das Zeichen
* zu ersetzen. Da ein
verschlüsseltes Passwort niemals diesem Zeichen entsprechen
kann, kann sich der betroffene Benutzer ebenfalls nicht mehr
anmelden. Beispielsweise müsste dazu das Kontofoobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcshwie folgt abgeändert werden:foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcshDurch diese Änderung wird der Benutzer
foobar daran gehindert, sich auf
konventionellem Wege am System anzumelden. Diese
Maßnahmen greifen allerdings nicht, wenn das betroffene
System auch eine Anmeldung über
Kerberos oder &man.ssh.1; erlaubt.Diese Sicherheitsmechanismen setzen voraus, dass
Sie sich von einer restriktiven Maschine auf einer weniger restriktiven
Maschine anmelden. Wenn zum Beispiel auf Ihrem Hauptrechner alle
möglichen Arten von Servern laufen, so sollten auf Ihrer
Workstation keine Server laufen. Um Ihre Workstation vernünftig
abzusichern, sollten auf Ihr so wenig Server wie möglich bis hin
zu keinem Server laufen. Sie sollten zudem über einen
Bildschirmschoner verfügen, der mit einem Passwort
gesichert ist. Natürlich kann ein Angreifer, der physikalischen
Zugang zu einer Maschine hat, jede Art von Sicherheitsmechanismen
umgehen. Dieses Problem sollten Sie daher auch in Ihren
Überlegungen berücksichtigen. Beachten Sie dabei aber,
dass der Großteil der Einbrüche über das
Netzwerk erfolgt und die Einbrecher keinen Zugang zu der Maschine
besitzen.KerberosIVMit Kerberos können Sie das
Passwort eines Mitarbeiters an einer Stelle ändern
und alle Maschinen, auf denen der Mitarbeiter einen Account hat,
beachten die Änderung sofort. Wird der Account eines
Mitarbeiters einmal kompromittiert, so sollte die Fähigkeit, das
Passwort mit einem Schlag auf allen Maschinen zu ändern,
nicht unterschätzt werden. Mit einzelnen Passwörtern
wird es schwierig, das Passwort auf N Maschinen zu ändern.
Mit Kerberos können Sie auch
Beschränkungen für Passwörter festlegen:
Nicht nur das Ticket kann nach einiger Zeit ungültig werden,
Sie können auch festlegen, dass ein Benutzer nach einer
bestimmten Zeit, z.B. nach einem Monat, das Passwort wechseln
muss.Absichern von unter root laufenden
Servern und SUID/SGID ProgrammenntalkcomsatfingerSandkästensshdtelnetdrshdrlogindEin kluger Systemadministrator lässt nur die
Dienste, die er wirklich braucht, laufen; nicht mehr und auch
nicht weniger. Beachten Sie, dass Server von Dritten die
fehleranfälligsten sind. Wenn Sie z.B. eine alte Version von
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 muss
er immer noch aus dem Sandkasten selber ausbrechen. Je mehr Schichten
der Angreifer zu durchbrechen hat, desto kleiner sind seine Aussichten
auf Erfolg. In der Vergangenheit wurden praktisch in jedem
Server, der unter 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
SSH anmelden kann, dann stellen Sie die
Dienste telnetd,
rshd oder rlogind
ab!In der Voreinstellung laufen unter &os;
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.sendmailEinige 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,
dass die SUID- und SGID-Programme des Basissystems ausreichend
sicher sind. Allerdings werden ab und an in diesen Programmen
Löcher gefunden. 1998 wurde in 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 ein kluger Systemadministrator den Zugriff auf
SUID-Programme mit einer Gruppe, auf die nur Mitarbeiter zugreifen
können, beschränken. SUID-Programme, die niemand benutzt,
sollten mit 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 Passwortdatei lesen. Dies kompromittiert
unter Umständen jeden Account, der mit einem Passwort
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 AccountsAccounts sind für gewöhnlich sehr schwierig
abzusichern. Während Sie drakonische Beschränkungen
für Ihre Mitarbeiter einrichten und deren Passwörter
als ungültig markieren können, werden Sie das
vielleicht bei den normalen Accounts nicht durchsetzen.
Wenn Sie über ausreichend Macht verfügen, gelingt es Ihnen
vielleicht doch, ansonsten müssen Sie diese Accounts
aufmerksam überwachen. Wegen der zusätzlichen
Administrationsarbeit und der nötigen technischen
Unterstützung ist die Verwendung von
SSH und Kerberos
mit normalen Accounts erschwert, obwohl das natürlich
sicherer als die Verwendung von verschlüsselten
Passwörtern ist.Absichern der Passwort-DateiDer einzig sichere Weg ist, so viele 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 Passwö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 Überwachungsskripten sollten Änderungen
an der Passwort-Datei melden (siehe Überprüfen der
Integrität von Dateien weiter unten).Absichern des Kernels, der Geräte und von
DateisystemenWenn 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 &os; 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.sysctlAuch 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, dass 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 Kompromiss
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 aber, dass
Sie das Aufdecken eines Einbruchs vielleicht verhindern, wenn
Sie zu drastische Maßnahmen zum Schutz Ihres Systems
verwenden.Überprüfen der Integrität von DateienSie 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, dass
Ihre Sicherheitsüberprüfungen vor einem Angreifer
verborgen bleiben und daher sind sie auf einem besonders
geschützten System gut aufgehoben. Um dies optimal auszunutzen,
müssen Sie dem besonders geschützten System Zugriffsrechte
auf die zu schützenden Systeme geben. Sie können die
Dateisysteme der zu schützenden Systeme schreibgeschützt
für das besonders geschützte System exportieren, oder
Sie können der besonders geschützten Maschine
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ässt.Wenn das besonders geschützte System lesenden Zugriff
auf die Clients hat, müssen Sie Skripten schreiben, die die
Überwachung durchführen. Wenn Sie die NFS-Methode
verwenden, können Sie dazu einfache Systemwerkzeuge wie
&man.find.1; und &man.md5.1; benutzen. Am besten berechnen
Sie einmal am Tag MD5-Prüfsummen der Dateien, Konfigurationsdateien
in /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 Skripten schwieriger. Sie müssen
die Skripten 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 erkennen 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 verbieten.
&man.mount.8; stellt dazu nosuid
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 Prozessüberwachung (siehe &man.accton.8;)
des Betriebssystems steht ein günstiges Werkzeug zur
Verfügung, dass sich bei der Analyse eines Einbruchs
als nützlich erweisen kann. Insbesondere können Sie
damit herausfinden, wie der Einbrecher in das System eingedrungen ist,
vorausgesetzt die Dateien der Prozessüberwachung sind
noch alle intakt.Schließlich sollten die Sicherheitsskripten die Logdateien
analysieren. Dies sollte so sicher wie möglich durchgeführt
werden, nützlich ist das Schreiben von Logdateien auf
entfernte Systeme mit 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.ParanoiaEs schadet nicht, ein bisschen paranoid zu sein.
Grundsätzlich darf ein Systemadministrator jede
Sicherheitsmaßnahme treffen, die die Bedienbarkeit des
Systems nicht einschränkt. Er kann auch Maßnahmen
treffen, die die Bedienbarkeit einschränken,
wenn er diese vorher genau durchdacht hat. Was noch wichtiger
ist: Halten Sie sich nicht sklavisch an dieses Dokument, sondern
führen Sie eigene Maßnahmen ein, um nicht einem
künftigen Angreifer, der auch Zugriff auf dieses Dokument
hat, alle Ihre Methoden zu verraten.Denial-of-Service AngriffeDenial-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 sehr wohl den Schaden begrenzen, den solche
Angriffe verursachen können und insbesondere einen kompletten
Serverausfall verhindern, indem Sie beispielsweise folgende
Vorkehrungen treffen: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, solange neue Prozesse zu starten,
bis das System den ganzen Speicher und alle Dateideskriptoren
verbraucht hat, was dann zu einem Ausfall des Servers führt.
&man.inetd.8; besitzt einige Optionen, um diese Art von Angriffen
zu begrenzen. Beachten Sie bitte, dass es möglich ist, einen
Ausfall einer Maschine zu verhindern, doch ist es generell nicht
möglich, den Ausfall eines Dienstes bei dieser Art
von Angriffen zu verhindern. Lesen Sie sich bitte die Manualpages
von inetd gut durch und achten Sie speziell
auf die Optionen , und
. Angriffe mit gefälschten IP-Adressen
umgehen , so dass normalerweise eine
Kombination der Optionen benutzt werden muss. 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 sendmailMaxDaemonChildren so hoch setzen, dass Sie
die erwartete Auslastung gut abfangen können. Allerdings
sollten Sie den Wert nicht so hoch setzen, dass der
Rechner über seine eigenen Füße fällt.
Es ist auch klug, 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 diesesSendmail 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 TCP-Wrapper.
Diese Funktion der TCP-Wrapper
sollten Sie normalerweise nicht benutzen.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, dass Sie
vergessen, eine Reihe von Diensten zu blockieren bzw. einen
internen Dienst einführen und dann vergessen die Firewall
zu aktualisieren. Sie können immer die höheren
Portnummern öffnen, ohne die niedrigen Portnummern,
die nur von root benutzt werden dürfen,
zu kompromittieren. Beachten Sie bitte auch, dass es
&os; erlaubt, die Portnummern, die für dynamische
Verbindungen zur Verfügung stehen, zu konfigurieren.
Mit 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.Eine andere Form eines DoS-Angriffs nutzt einen Server
als Sprungbrett, der Server wird dabei so angegriffen, dass
seine Antworten ihn selber, das lokale Netzwerk oder einen
anderen Server überlasten. Der am häufigsten verwendete
Angriff dieser Art ist der 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. Ein zweiter Sprungbrett-Angriff wird gegen
das Fehlerbehandlungssystem von ICMP eingesetzt. Indem ein Angreifer
Pakete konstruiert, die eine ICMP-Fehlermeldung hervorrufen, kann
er das einkommende Netzwerk des Servers sättigen und diesen
wiederum veranlassen sein ausgehendes Netzwerk mit ICMP-Antworten
zu sättigen. Diese Art des Angriffs kann den kompletten
Speicher des Servers aufbrauchen und damit den Server stilllegen,
insbesondere wenn der Server nicht in der Lage ist, die generierten
ICMP-Antworten schnell genug abzuführen. Verwenden Sie die
sysctl-Variable
net.inet.icmp.icmplim, um die Auswirkungen
solcher Angriffe zu begrenzen. 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,
dass 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, dass
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, dass 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 SSHsshKerberosIVEs gibt ein paar Punkte, die Sie beachten sollten, wenn Sie
Kerberos oder SSH
einsetzen wollen. Kerberos 5 ist ein
ausgezeichnetes Authentifizierungsprotokoll. Leider gibt es
Fehler in den für Kerberos
angepassten 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 von einer sicheren Maschine, auf der sich Ihre
Schlüssel befinden, eine Verbindung zu einer
ungesicherten Maschine aufmachen, wird für die Dauer der
Sitzung ein Port für Weiterleitungen geöffnet.
Ein Angreifer, der auf der unsicheren Maschine Zugang zu
root hat, kann diesen Port
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 Passwö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.BillSwingleTeile umgeschrieben und aktualisiert von DES, Blowfish, MD5, und CryptSicherheitCryptCryptBlowfishDESMD5Jedem Benutzer eines &unix; Systems ist ein Passwort zugeordnet.
Es scheint offensichtlich, dass das Passwort nur dem Benutzer
und dem System bekannt sein muss. Um die Passwörter
geheim zu halten, werden sie mit einer nicht umkehrbaren Hash-Funktion
verschlüsselt, das heißt sie können leicht
verschlüsselt aber nicht entschlüsselt werden. Was wir
gerade als offensichtlich dargestellt haben, ist also nicht wahr: Das
Betriebssystem kennt das Passwort wirklich
nicht, es kennt nur das verschlüsselte
Passwort. Die einzige Möglichkeit, das originale Passwort
herauszufinden, besteht darin, alle möglichen Passwörter
auszuprobieren (brute force Suche).Zu der Zeit als &unix; entstanden ist, war die einzig sichere
Möglichkeit Passwörter zu verschlüsseln, leider
DES (Data Encryption Standard). Für die Einwohner der USA
stellte das kein Problem dar, aber da der Quellcode von DES nicht aus
den USA exportiert werden durfte, musste ein Weg gefunden werden,
der die Gesetze der USA nicht verletzte und gleichzeitig die
Kompatibilität mit anderen &unix; Systemen, die immer noch DES
benutzten, wahrte.Die Lösung bestand darin, die Verschlüsselungsbibliotheken
aufzuspalten. Benutzer in den USA konnten die DES-Bibliotheken
installieren und nutzen. In der Grundeinstellung benutzt &os;
MD5 als Verschlüsselungsmethode, das exportiert werden durfte
und damit von jedem genutzt werden konnte. Es wird davon ausgegangen,
dass MD5 sicherer als DES ist, so dass DES nur aus
Kompatibilitätsgründen installiert werden sollte.Erkennen der VerschlüsselungsmethodeDerzeit werden DES-, MD5- und Blowfish-Hash-Funktionen
unterstützt. In der
Voreinstellung benutzt &os; die MD5-Hash-Funktion.Sie können leicht herausfinden, welche
Verschlüsselungsmethode von &os; verwendet wird. Ein Weg
besteht darin, die verschlüsselten Passwörter in
/etc/master.passwd zu untersuchen.
Passwörter, die mit MD5 verschlüsselt wurden,
sind länger als die mit DES verschlüsselten und
beginnen mit den Zeichen $1$.
Passwörter, die mit $2a$
anfangen, wurden mit der Blowfish-Funktion verschlüsselt.
DES Passwörter besitzen keine offensichtlichen Merkmale,
an denen sie identifiziert werden könnten. Sie sind aber
kürzer als MD5-Passwörter und sind in einem
64 Zeichen umfassenden Alphabet kodiert, das das
$-Zeichen nicht enthält. Ein relativ
kurzes Passwort, das nicht mit einem
$-Zeichen anfängt, ist wahrscheinlich
ein DES-Passwort.Die Verschlüsselungsmethode für neue
Passwö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.EinmalpasswörterEinmalpasswörterSicherheitEinmalpasswörterIn der Voreinstellung unterstützt &os;
OPIE (One-time Passwords in
Everything, das in der Regel MD5-Hash-Funktionen
einsetzt.Im Folgenden werden drei verschiedene
Passwörter verwendet. Das erste ist Ihr normales System- oder
Kerberos-Passwort und wird im Folgenden System-Passwort
genannt. Das zweite ist das Einmalpasswort, das bei OPIE von
opiekey generiert und von
opiepasswd und dem Login-Programm akzeptiert wird.
Im Folgenden wird es Einmalpasswort genannt. Das dritte
Passwort ist das geheime Passwort, das Sie mit
opiekey (manchmal auch mit
opiepasswd) zum Erstellen
der Einmalpasswörter verwenden. Dieses Passwort
werden wir im Folgenden geheimes Passwort
oder schlicht Passwort nennen.Das geheime Passwort steht in keiner Beziehung zu Ihrem
System-Passwort, beide können gleich sein, obwohl das nicht
empfohlen wird. Die geheimen Passwörter von
OPIE sind nicht auf eine Länge von 8 Zeichen,
wie alte &unix; PasswörterUnter &os; darf das System-Passwort maximal
128 Zeichen lang sein., beschränkt.
Sie können so lang sein, wie Sie wollen. Gebräuchlich sind
Passwörter, die sich aus sechs bis sieben Wörtern
zusammensetzen. Das OPIE-System arbeitet
größtenteils unabhängig von den
auf &unix;-Systemen verwendeten Passwort-Mechanismen.Neben dem Passwort gibt es noch zwei Werte, die für
OPIE wichtig sind. Der erste ist der
Initialwert (engl. seed
oder key), der aus zwei Buchstaben
und fünf Ziffern besteht. Der zweite Wert ist der
Iterationszähler, eine Zahl zwischen
1 und 100. OPIE generiert das Einmalpasswort, indem
es den Initialwert und das geheime Passwort aneinander hängt
und dann die MD5-Hash-Funktion so oft, wie durch den
Iterationszähler gegeben, anwendet. Das Ergebnis wird in
sechs englische Wörter umgewandelt, die Ihr Einmalpasswort
sind. Das Authentifizierungssystem (meistens PAM) merkt sich das
zuletzt benutzte Einmalpasswort und Sie sind authentisiert,
wenn die Hash-Funktion des Passworts dem vorigen Passwort
entspricht. Da nicht umkehrbare Hash-Funktionen benutzt werden,
ist es unmöglich, aus einem bekannten Passwort weitere
gültige Einmalpasswörter zu berechnen. Der
Iterationszähler wird nach jeder erfolgreichen Anmeldung um
eins verringert und stellt so die Synchronisation zwischen Benutzer
und Login-Programm sicher. Wenn der Iterationszähler den
Wert 1 erreicht, muss OPIE neu initialisiert werden.In jedem System werden mehrere Programme verwendet, die weiter
unten beschrieben werden. opiekey verlangt
einen Iterationszähler, einen Initialwert und ein geheimes
Passwort. Daraus generiert es ein Einmalpasswort oder eine Liste
von Einmalpasswörtern. opiepasswd wird
dazu benutzt, um OPIE zu initialisieren. Mit diesem Programm
können Passwörter, Iterationszähler oder
Initialwerte geändert werden. Als Parameter verlangt es
entweder ein geheimes Passwort oder einen Iterationszähler
oder einen Initialwert und ein Einmalpasswort.
opieinfo hingegen gibt den momentanen
Iterationszähler und Initialwert eines Benutzers aus. Diese
werden aus der Datei /etc/opiekeys
ermittelt.Im Folgenden werden vier verschiedene Tätigkeiten beschrieben.
Zuerst wird erläutert, wie
opiepasswd über eine gesicherte Verbindung
eingesetzt werden, um Einmalpasswörter das erste Mal
zu konfigurieren oder das Passwort oder den Initialwert
zu ändern. Als nächstes wird erklärt, wie
opiepasswd über eine nicht gesicherte
Verbindung, oder zusammen mit opiekey über
eine gesicherte Verbindung eingesetzt werden, um dasselbe zu
erreichen. Als drittes wird beschrieben, wie
opiekey genutzt wird,
um sich über eine nicht gesicherte Verbindung anzumelden.
Die vierte Tätigkeit beschreibt, wie mit
opiekey eine Reihe von Schlüsseln
generiert wird, die Sie sich aufschreiben oder ausdrucken können,
um sich von Orten anzumelden, die über keine gesicherten
Verbindungen verfügen.Einrichten über eine gesicherte VerbindungUm OPIE erstmals zu initalisieren, rufen Sie
opiepasswd auf:&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
Passwort ein. Dies ist nicht das Passwort, mit dem Sie sich
anmelden, sondern es wird genutzt, um das Einmalpasswort
zu generieren. Die Zeile, die mit 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 Einmalpasswort, das aus diesen Parametern
und Ihrem geheimen Passwort ermittelt wurde. Wenn sie sich jetzt
wieder anmelden wollten, dann müssten Sie dieses
Passwort benutzen.Einrichten über eine nicht gesicherte VerbindungUm Einmalpasswörter über eine nicht gesicherte
Verbindung einzurichten, oder das geheime Passwort zu ändern,
müssen Sie über eine gesicherte Verbindung zu einer Stelle
verfügen, an der Sie opiekey ausführen.
Dies kann etwa die Eingabeaufforderung auf einer Maschine, der Sie
vertrauen, sein. Zudem müssen Sie einen Iterationszähler
vorgeben (100 ist ein guter Wert) und einen Initialwert wählen,
wobei Sie auch einen zufällig generierten benutzen können.
Benutzen Sie opiepasswd über die ungesicherte
Verbindung zu der Maschine, die Sie einrichten wollen:&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 zu akzeptieren. Bevor
Sie nun das Zugriffspasswort
(engl. access password)
eingeben, rufen Sie über die gesicherte Verbindung
opikey mit denselben Parametern auf:&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 Einmalpasswort ein.Erzeugen eines einzelnen EinmalpasswortesNachdem Sie 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>
otp-md5 498 gr4269 ext
Password: Anmerkung: OPIE besitzt 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 Passwort von einem
Ausdruck abtippen müssen.MS-DOSWindowsMacOSJetzt müssen Sie Ihr Einmalpasswort generieren,
um der Anmeldeaufforderung nachzukommen. Dies muss auf
einem gesicherten System geschehen, auf dem Sie
oder opiekey ausführen können.
Dieses Programm gibt es übrigens auch für DOS, &windows; und
&macos;. Es benötigt den Iterationszähler
sowie den Initialwert als Parameter, die Sie mittels
cut-and-paste direkt von der Login-Aufforderung
nehmen können.Auf dem sicheren System:&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 CHATMit dem jetzt generierten Einmalpasswort können
Sie die Anmeldeprozedur fortsetzen.Erzeugen von mehreren EinmalpasswörternManchmal 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 opiekey
einige Einmalpasswörter generieren, die Sie sich
ausdrucken und mitnehmen können. Zum Beispiel:&prompt.user; opiekey -n 5 30 zz99999
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <secret password>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
28: SALT TIN ANTI LOON NEAL USE
29: RIO ODIN GO BYE FURY TIC
30: GREW JIVE SAN GIRD BOIL PHIMit fordern Sie fünf
Passwörter der Reihe nach an. Der letzte
Iterationszähler wird durch gegeben.
Beachten Sie bitte, dass die Passwörter in der
umgekehrten Reihenfolge, in der sie
zu benutzen sind, ausgeben werden. Wenn Sie wirklich paranoid
sind, schreiben Sie sich jetzt die Passwörter auf,
ansonsten drucken Sie sie mit lpr aus.
Beachten Sie, dass jede Zeile den Iterationszähler
und das Einmalpasswort zeigt, trotzdem finden Sie es
vielleicht hilfreich, eine Zeile nach Gebrauch durchzustreichen.Einschränken der Benutzung von
System-PasswörternOPIE kann die Verwendung von System-Passwörtern
abhängig von der Quell-IP-Adresse einschränken.
Die dazu nötigen Einstellungen werden in der Datei
/etc/opieaccess vorgenommen, die
bei der Installation des Systems automatisch erzeugt wird.
Weitere Informationen über diese Datei und
Sicherheitshinweise zu ihrer Verwendung entnehmen Sie bitte
der Hilfeseite &man.opieaccess.5;.Die Datei opieaccess könnte
beispielsweise die folgende Zeile enthalten:permit 192.168.0.0 255.255.0.0Diese Zeile erlaubt es Benutzern, die sich von einer der
angegebenen Quell-IP-Adressen anmelden, ihr System-Passwort
zu verwenden. Beachten Sie bitte, dass eine Quell-IP-Adresse
leicht gefälscht werden kann.Findet sich in opieaccess kein
passender Eintrag, muss die Anmeldung mit OPIE erfolgen.TomRhodesBeigetragen von TCP-WrapperTCP-WrapperWahrscheinlich hat jeder, der &man.inetd.8; kennt,
schon mal von den TCP-Wrappern gehört. Die
wenigsten erkennen den vollen Nutzen der TCP-Wrapper
in einer Netzumgebung. Es scheint, dass die meisten
Leute Netzverbindungen mit einer Firewall absichern
wollen. Auch wenn eine Firewall ein mächtiges
Instrument ist, gibt es Sachen, die eine Firewall
nicht kann. Eine Firewall kann beispielsweise keine
Nachricht an den Verbindungsursprung senden. Genau
das und mehr können aber die
TCP-Wrapper. Im Folgenden werden
die Funktionen der TCP-Wrapper
und Beispiele für deren Konfiguration vorgestellt.Die TCP-Wrapper erweitern die
Steuerungsmöglichkeiten, die inetd
über die Dienste unter seiner Kontrolle hat.
Beispielsweise können Verbindungen protokolliert,
Nachrichten zurückgesandt oder nur interne Verbindungen
angenommen werden. Die TCP-Wrapper
bieten nicht nur eine weitere Sicherheitsschicht, die
teilweise auch von Firewalls geboten wird, sie bieten
darüber hinaus Funktionen zur Steuerung von
Verbindungen, die eine Firewall nicht bietet.Die erweiterten Funktionen der
TCP-Wrapper sind kein Firewall-Ersatz.
Sie sollten zusammen mit einer Firewall und anderen
Sicherheitsvorkehrungen eingesetzt werden. Die
TCP-Wrapper sind eine weitere
Sicherheitsschicht zum Schutz eines Systems.Da die Wrapper die Funktion von inetd
erweitern, wird im Folgenden vorausgesetzt, dass Sie den
Abschnitt über die
inetd-Konfiguration
schon gelesen haben.Streng genommen handelt es sich bei den von &man.inetd.8;
gestarteten Programmen nicht um Daemonen. Da
sich diese Bezeichnung aber eingebürgert hat, wird sie auch
in diesem Abschnitt verwendet.TCP-Wrapper einrichtenUm die TCP-Wrapper unter &os;
zu benutzen, muss nur der inetd
aus rc.conf mit den voreingestellten
Optionen gestartet werden.
Die Konfigurationsdatei /etc/hosts.allow
darf keine Fehler enthalten; falls doch, werden die
Fehler mit &man.syslogd.8; protokolliert.Im Gegensatz zu anderen Implementationen der
TCP-Wrapper wird vom Gebrauch
der Datei hosts.deny abgeraten.
Die Konfiguration sollte sich vollständig in der
Datei /etc/hosts.allow befinden.In der einfachsten Konfiguration werden Dienste
abhängig vom Inhalt der Datei
/etc/hosts.allow erlaubt oder
gesperrt. Unter &os; wird in der Voreinstellung
jeder von inetd gestartete Dienst
erlaubt. Sehen wir uns zunächst die Grundkonfiguration
an.Eine Konfigurationszeile ist wie folgt aufgebaut:
Dienst : Adresse : Aktion.
Dienst ist der von inetd
gestartete Dienst (auch Daemon genannt). Die
Adresse kann ein gültiger
Rechnername, eine IP-Adresse oder
eine IPv6-Adresse in Klammern
([]) sein.
Der Wert allow im Feld
Aktion erlaubt Zugriffe, der Wert
deny verbietet Zugriffe.
Die Zeilen in hosts.allow
werden für jede Verbindung der Reihe nach
abgearbeitet. Trifft eine Zeile auf eine Verbindung
zu, wird die entsprechende Aktion ausgeführt
und die Abarbeitung ist beendet.Es gibt noch weitere Konfigurationsoptionen, die
gleich erläutert werden. Das bisher Gesagte
reicht, um eine einfache Regel aufzustellen. Wenn
Sie einkommende POP3-Verbindungen
für den Dienst
mail/qpopper
erlauben wollen, erweitern Sie
hosts.allow um die nachstehende
Zeile:# This line is required for POP3 connections:
qpopper : ALL : allowNachdem Sie die Zeile hinzugefügt haben, muss der
inetd neu gestartet werden. Sie
können dazu das Kommando &man.kill.1; verwenden
oder /etc/rc.d/inetd restart
ausführen.Erweiterte Konfiguration der TCP-WrapperDie TCP-Wrapper besitzen
weitere Optionen, die bestimmen, wie Verbindungen
behandelt werden. In einigen Fällen ist es
gut, wenn bestimmten Rechnern oder Diensten eine
Nachricht geschickt wird. In anderen Fällen
soll vielleicht der Verbindungsaufbau protokolliert
oder eine E-Mail an einen Administrator versandt
werden. Oder ein Dienst soll nur für das
lokale Netz bereitstehen. Dies alles ist mit so genannten
Wildcards, Metazeichen und der Ausführung externer
Programme möglich und wird in den nächsten
zwei Abschnitten erläutert.Externe Kommandos ausführenStellen Sie sich vor, eine Verbindung soll
verhindert werden und gleichzeitig soll demjenigen,
der die Verbindung aufgebaut hat, eine Nachricht
geschickt werden. Auf welche Art müssen
die TCP-Wrapper konfiguriert werden?
Die Option führt beim
Verbindungsaufbau ein Kommando aus. In der Datei
hosts.allow ist ein Beispiel
für diese Option enthalten:# Alle anderen Dienste sind geschützt
ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."Für jeden Dienst, der nicht vorher in
der Datei hosts.allow konfiguriert
wurde, wird die Meldung You are not allowed to use
daemon from
hostname. zurückgegegeben.
Dies ist besonders nützlich, wenn Sie die
Gegenstelle sofort benachrichtigen wollen, nachdem
die Verbindung getrennt wurde. Beachten Sie, dass
der Text der Meldung in Anführungszeichen
(") stehen muss,
es gibt keine Ausnahmen zu dieser Regel.Ein so konfigurierter Server ist anfällig
für Denial-of-Service-Angriffe. Ein Angreifer
kann die gesperrten Dienste mit Verbindungsanfragen
überfluten.Um einem Denial-of-Service-Angriff zu entgehen,
benutzen Sie die Option .
Wie die Option verbietet
die Verbindung und führt
externe Kommandos aus. Allerdings sendet die
Option der Gegenstelle
keine Rückmeldung. Sehen Sie sich die
nachstehende Konfigurationsdatei an:# Verbindungen von example.com sind gesperrt:
ALL : .example.com \
: spawn (/bin/echo %a from %h attempted to access %d >> \
/var/log/connections.log) \
: denyDamit sind Verbindungen von der Domain
*.example.com gesperrt.
Jeder Verbindungsaufbau wird zudem in der Datei
/var/log/connections.log
protokolliert. Das Protokoll enthält den
Rechnernamen, die IP-Adresse
und den Dienst, der angesprochen wurde.In der Konfigurationsdatei wurde beispielsweise
das Metazeichen %a verwendet. Es gibt weitere
Metazeichen, die in der Hilfeseite &man.hosts.access.5;
beschrieben werden.WildcardsBisher verwendeten die Beispiele immer die
Wildcard ALL. Die Wildcard
ALL passt beispielsweise auf
jeden Dienst, jede Domain oder jede
IP-Adresse. Eine andere
Wildcard ist PARANOID. Sie passt
auf jeden Rechner dessen IP-Adresse
möglicherweise gefälscht ist. Dies ist dann
der Fall, wenn der Verbindungsaufbau von einer
IP-Adresse erfolgt, die nicht
zu dem übermittelten Rechnernamen passt.
Für solche Fälle werden mit der
Wildcard PARANOID Aktionen
festgelegt, beispielsweise:# Block possibly spoofed requests to sendmail:
sendmail : PARANOID : denyIn diesem Beispiel werden alle Verbindungen zu
sendmail verboten, die von einer
IP-Adresse ausgehen, die nicht zum
Rechnernamen passt.Die Wildcard PARANOID
kann einen Dienst unbrauchbar machen, wenn der
Client oder der Server eine fehlerhafte
DNS-Konfiguration besitzt.
Setzen Sie die Wildcard bitte umsichtig ein.Weiteres über Wildcards und deren Funktion
lesen Sie bitte in der Hilfeseite &man.hosts.access.5;
nach.In der Voreinstellung sind alle Dienste erlaubt.
Damit die gezeigten Beispiele funktionieren, müssen
Sie die erste Konfigurationszeile in der Datei
hosts.allow auskommentieren.MarkMurrayBeigesteuert von MarkDapozBasiert auf einem Beitrag von KerberosIVKerberosIVKerberos 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 &os; konfigurieren. Eine komplette
Beschreibung des Systems finden Sie in den entsprechenden
Hilfeseiten.Installation von KerberosIVMITKerberosIVinstallierenKerberos ist eine optionale Komponente von &os;. Am
leichtesten installieren Sie die Software, wenn Sie bei
der ersten Installation von &os; 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 &os; 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-Sammlung unter security/krb5 zur
Verfügung.Erstellen der initialen DatenbankDie folgenden Schritte werden nur auf dem Kerberos-Server
durchgeführt. Stellen Sie bitte vorher sicher, dass
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.realmsWenn 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.govDie 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, dass dieser Host auch einen administrativen
Datenbankserver zur Verfügung stellt. Weitere Erklärungen zu
diesen Begriffen finden Sie in den Kerberos Manualpages.Als nächstes muss
grunt.example.com in das Realm
EXAMPLE.COM aufgenommen werden. Des Weiteren
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.EDUDie 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 muss nur auf dem Kerberos-Server
(oder Key Distribution Center) laufen. Mit
kdb_init können wir die Datenbank
anlegen:&prompt.root; kdb_initRealm 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 muss der Schlüssel gespeichert
werden, damit Server auf der lokalen Maschine darauf zugreifen
können. Dies geschieht mit kstash:&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!Das verschlüsselte Master-Passwort wurde in
/etc/kerberosIV/master_key gesichert.Anlegen von PrinzipalsFü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-Passwörter zu ändern und Kommandos wie
&man.rcp.1;, &man.rlogin.1; und &man.rsh.1;
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:passwdInstance: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:rcmdInstance: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 verlassenErstellen der Server-DateiWir müssen nun für jede Maschine die Instanzen,
die Dienste definieren, aus der Datenbank mit
ext_srvtab extrahieren. Die erstelle Datei
muss auf einem sicheren Weg in das
Verzeichnis /etc jedes Clients
kopiert werden. Die Datei muss auf jedem Server und auf
jedem Client vorhanden sein und ist unabdingbar für
Kerberos.&prompt.root; ext_srvtab gruntEnter 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
muss auf dem entsprechenden System in srvtab
umbenannt werden. Auf dem originalen System können Sie
&man.mv.1; benutzen, um die Datei umzubenennen:&prompt.root; mv grunt-new-srvtab srvtabWenn 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.
Benennen Sie die Datei in srvtab um und setzen Sie
schließlich noch die Berechtigungen auf 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabFüllen der DatenbankWir 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:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- geben Sie ein sicheres Passwort 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 verlassenTestenZuerst müssen die Kerberos-Dæmonen gestartet sein.
Wenn Sie /etc/rc.conf richtig angepasst 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,
dass 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.COMVersuchen Sie nun das Passwort mit &man.passwd.1;
zu ändern, um zu überprüfen, dass 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 su PrivilegienMit Kerberos kann jedem Benutzer, der
root-Privilegien braucht, ein
eigenes Passwort für
&man.su.1; zugewiesen werden. Dies wird dadurch
erreicht, dass 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:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- geben Sie ein sicheres Passwort ein
Verifying password
New Password: <---- geben Sie das Passwort 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 verlassenVersuchen 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.COMJetzt benutzen wir &man.su.1;:&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.COMWeitere KommandosIn 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, dass ein
principal.instance der Form
username.root es dem
Benutzer username erlaubt, mit
&man.su.1; root zu werden, wenn die
entsprechenden Einträge in .klogin von
root existieren:&prompt.root; cat /root/.klogin
jane.root@EXAMPLE.COMDas gilt auch für die .klogin-Datei
im Heimatverzeichnis eines Benutzers:&prompt.user; cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COMDie Einträge erlauben jedem, der sich im Realm
EXAMPLE.COM als jane oder
jack mit kinit authentifiziert
hat, mittels &man.rlogin.1;, &man.rsh.1; oder &man.rcp.1;
auf den Account jane und dessen
Dateien zuzugreifen.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 1995Im 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 1995TillmanHodgsonBeigetragen von MarkMurrayBeruht auf einem Beitrag von Kerberos5Das Basissystem enthält ab &os; 5.1
nur noch Kerberos5. Die
Konfiguration von Kerberos5
ist der Konfiguration von KerberosIV
sehr ähnlich. Wenn Sie KerberosIV
benötigen, installieren Sie den Port
security/krb4.
Der folgende Abschnitt beschreibt ausschließlich
Kerberos5 für &os;-Releases
ab 5.0.Kerberos ist ein Netzwerk-Protokoll,
das Benutzer mithilfe eines sicheren Servers authentifiziert.
Mit Risiken behaftete Dienste, wie das Anmelden an entfernten
Systemen oder das Kopieren von Daten auf entfernte Systeme,
werden durch Kerberos erheblich
sicherer und lassen sich leichter steuern.Kerberos hat eine Aufgabe:
Die sichere Prüfung der Identität eines Benutzers
(Authentifizierung) über das Netzwerk. Das System
überprüft weder die Berechtigungen der Benutzer
(Autorisierung), noch verfolgt es die durchgeführten
Aktionen (Audit). Daher sollte Kerberos
zusammen mit anderen Sicherheits-Systemen eingesetzt werden, die
diese Funktionen bereitstellen. Die Daten einer Kommunikation
können verschlüsselt werden, nachdem die
Kommunikationspartner mit Kerberos
ihre Identität geprüft haben.Die folgenden Anweisungen beschreiben, wie Sie das mit
&os; gelieferte Kerberos einrichten.
Eine vollständige Beschreibung des Systems entnehmen
Sie bitte den entsprechenden Hilfeseiten.Die Beschreibung der
Kerberos-Installation benutzt
folgende Namensräume:Die DNS-Domain (Zone) heißt
example.org.Das Kerberos-Realm
heißt EXAMPLE.ORG.Benutzen Sie echte Domain-Namen, wenn Sie
Kerberos einrichten. Damit
vermeiden Sie DNS-Probleme und stellen
die Zusammenarbeit mit anderen
Kerberos-Realms sicher.GeschichteKerberos5GeschichteDas MIT entwickelte
Kerberos, um Sicherheitsprobleme
auf dem Netzwerk zu lösen. Das
Kerberos-Protokoll verwendet
starke Kryptographie, sodass ein Server die Identität
eines Clients (der umgekehrte Vorgang ist auch möglich)
über ein unsicheres Netzwerk feststellen kann.Der Begriff Kerberos wird sowohl für das Protokoll
als auch für Programme verwendet, die
Kerberos benutzen (wie
Kerberos-Telnet). Die aktuelle
Protokollversion ist 5 und wird in
RFC 1510 beschrieben.Mehrere Implementierungen des Protokolls stehen frei
zur Verfügung und decken viele Betriebssysteme ab.
Das Massachusetts Institute of Technology
(MIT), an dem Kerberos
ursprünglich entwickelt wurde, entwickelt seine
Kerberos-Version weiter. In den
USA wird diese Version häufig
eingesetzt, unterlag aber Export-Beschränkungen,
da sie in den USA entwickelt wurde.
Die MIT-Version von
Kerberos befindet sich im Port
security/krb5.
Heimdal ist eine weitere Implementierung der Protokollversion 5.
Sie wurde außerhalb der USA entwickelt
und unterliegt daher keinen Export-Beschränkungen.
Heimdal-Kerberos befindet sich
im Port security/heimdal
und das Basissystem von &os; enthält eine minimale
Installation von Heimdal.Um möglichst viele Benutzer anzusprechen, verwenden
die folgenden Beispiele die in &os; enthaltene
Heimdal-Distribution.Das Heimdal KDC einrichtenKerberos5Key Distribution CenterKerberos authentifiziert
Benutzer an einer zentralen Stelle: dem Key Distribution
Center (KDC). Das KDC
verteilt Tickets, mit denen ein
Dienst die Identität eines Benutzers feststellen kann.
Alle Mitglieder eines Kerberos-Realms
vertrauen dem KDC, daher gelten für
das KDC erhöhte
Sicherheitsanforderungen.Obwohl das KDC wenig Ressourcen eines
Rechners benötigt, sollte es wegen der
Sicherheitsanforderungen auf einem separaten Rechner
installiert werden.Das KDC wird in
/etc/rc.conf wie folgt aktiviert:kerberos5_server_enable="YES"
kadmind5_server_enable="YES"Danach wird die Konfigurationsdatei von
Kerberos,
/etc/krb5.conf, erstellt:[libdefaults]
default_realm = EXAMPLE.ORG
[realms]
EXAMPLE.ORG = {
kdc = kerberos.example.org
admin_server = kerberos.example.org
}
[domain_realm]
.example.org = EXAMPLE.ORGDiese Einstellungen setzen voraus, dass der voll
qualifizierte Name des KDCs
kerberos.example.org ist.
Wenn Ihr KDC einen anderen Namen hat,
müssen Sie in der DNS-Zone einen Alias-Eintrag (CNAME-Record)
für das KDC hinzufügen.Auf großen Netzwerken mit einem ordentlich
konfigurierten BIND
DNS-Server kann die Datei verkürzt
werden:[libdefaults]
default_realm = EXAMPLE.ORGDie Zonendatei von example.org
muss dann die folgenden Zeilen enthalten:_kerberos._udp IN SRV 01 00 88 kerberos.example.org.
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.
_kpasswd._udp IN SRV 01 00 464 kerberos.example.org.
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org.
_kerberos IN TXT EXAMPLE.ORGDamit Klienten die
Kerberos-Dienste benutzen
können, muss die Datei /etc/krb5.conf
entweder die vollständige Konfiguration enthalten
oder eine minimale Konfiguration enthalten
und zusätzlich ein DNS-Server
richtig eingerichtet sein.Im nächsten Schritt wird die
Kerberos-Datenbank eingerichtet.
Die Datenbank enthält die Schlüssel aller Prinzipale
und ist mit einem Passwort geschützt. Dieses Passwort
brauchen Sie nicht zu behalten, da ein davon abgeleiteter
Schlüssel in der Datei /var/heimdal/m-key
gespeichert wird. Den Schlüssel erstellen Sie, indem
Sie das Programm kstash aufrufen und
ein Passwort eingeben.Nachdem Sie den Schlüssel in
/var/heimdal/m-key erstellt haben,
können Sie die Datenbank mit dem Kommando
kadmin initialisieren. Verwenden
Sie hierbei die Option (lokal). Mit
dieser Option wird die Datenbank lokal modifiziert. Normal
würde der kadmind-Dienst benutzt,
der aber zu diesem Zeitpunkt noch nicht läuft. An
der Eingabeaufforderung von kadmin
können Sie mit dem Kommando init
die Datenbank des Realms einrichten.Zuletzt erstellen Sie mit dem Kommando add
Ihren ersten Prinzipal. Benutzen Sie die voreingestellten
Optionen; Sie können die Einstellungen später
mit dem Kommando modify ändern.
An der Eingabeaufforderung zeigt das Kommando
? Hilfetexte an.Zusammengefasst wird die Datenbank wie folgt
eingerichtet:&prompt.root; kstash
Master key: xxxxxxxx
Verifying password - Master key: xxxxxxxx
&prompt.root; kadmin -l
kadmin> init EXAMPLE.ORG
Realm max ticket life [unlimited]:
kadmin> add tillman
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxxJetzt kann das KDC gestartet werden.
Führen Sie zum Start der Dienste die Kommandos
/etc/rc.d/kerberos start und
/etc/rc.d/kadmind start aus. Obwohl
zu diesem Zeitpunkt noch keine kerberisierten Dienste
laufen, können Sie die Funktion des KDCs
schon überprüfen. Für den eben angelegten
Benutzer können Sie sich vom KDC
Tickets holen und diese Tickets anzeigen:&prompt.user; kinit tillman
tillman@EXAMPLE.ORG's Password:
&prompt.user; klist
Credentials cache: FILE: /tmp/krb5cc_500
Principal: tillman@EXAMPLE.ORG
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORGDieses Ticket kann, nachdem Sie Ihre Arbeit beendet haben,
zurückgezogen werden:&prompt.user; k5destroyKerberos-Dienste
einrichtenKerberos5Dienste einrichtenAlle Rechner, die kerberisierte Dienste anbieten,
müssen eine Kopie der
Kerberos-Konfigurationsdatei
/etc/krb5.conf besitzen. Sie
können die Datei einfach vom KDC
kopieren.Anschließend müssen Sie die Datei
/etc/krb5.keytab erzeugen. Im
Gegensatz zu normalen Workstations benötigt jeder
Server eine keytab.
Diese Datei enthält den Schlüssel des
Servers, mit dem sich der Server und das
KDC gegenseitig authentifizieren
können. Die Datei muss sicher auf den Server
transportiert werden (beispielsweise mit &man.scp.1;
oder einer Diskette). Unter keinen Umständen
darf die Datei im Klartext, zum Beispiel mit
FTP, übertragen werden,
da sonst die Sicherheit des Servers gefährdet
ist.Sie können die keytab auch
mit dem Programm kadmin übertragen.
Da Sie mit kadmin sowieso einen Host-Prinzipal
für den Server einrichten müssen, ist das ganz
praktisch.Sie müssen allerdings schon ein Ticket
besitzen und berechtigt sein, kadmin
auszuführen. Die Berechtigung erhalten Sie durch
einen Eintrag in der Zugriffskontrollliste
kadmind.acl. Weitere Informationen
über Zugriffskontrolllisten erhalten Sie in den
Heimdal-Info-Seiten (info heimdal)
im Abschnitt Remote administration. Wenn
der Zugriff auf kadmin von entfernten
Maschinen verboten ist, müssen Sie sich sicher
auf dem KDC anmelden (lokale Konsole,
&man.ssh.1; oder kerberisiertes Telnet) und die
keytab lokal mit
kadmin -l erzeugen.Nachdem Sie die Datei /etc/krb5.conf
installiert haben, können Sie das Kommando
kadmin benutzen. An der Eingabeaufforderung
von kadmin erstellt das Kommando
add --random-key den Host-Prinzipal
und das Kommando ext extrahiert den
Schlüssel des Prinzipals in eine Datei:&prompt.root; kadmin
kadmin> add --random-key host/myserver.example.org
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin> ext host/myserver.example.org
kadmin> exitDas Kommando ext (von
extract) speichert den
extrahierten Schlüssel in der Datei
/etc/krb5.keytab.Wenn auf dem KDC, vielleicht aus
Sicherheitsgründen, kadmind
nicht läuft, können Sie das Kommando
kadmin von entfernten Rechnern nicht
benutzen. In diesem Fall legen Sie den Host-Prinzipal
host/myserver.EXAMPLE.ORG direkt
auf dem KDC an. Den Schlüssel
extrahieren Sie in eine temporäre Datei (damit
die Datei /etc/krb5.keytab nicht
überschrieben wird):&prompt.root; kadmin
kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
kadmin> exitAnschließend müssen Sie die erzeugte
example.keytab sicher auf den
Server kopieren (mit scp oder
mithilfe einer Diskette). Geben Sie auf jeden Fall
einen anderen Namen für die keytab
an, weil sonst die keytab des
KDCs überschrieben würde.Wegen der Datei krb5.conf kann
der Server nun mit dem KDC kommunizieren
und seine Identität mithilfe der Datei
krb5.keytab nachweisen. Jetzt
können wir kerberisierte Dienste aktivieren.
Für telnet muss die folgende
Zeile in /etc/inetd.conf eingefügt
werden:telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a userAusschlaggebend ist, dass die Authentifizierungs-Methode
mit auf user gesetzt
wird. Weitere Details entnehmen Sie bitte der Hilfeseite
&man.telnetd.8;.Nachdem sie die Zeile in /etc/inetd.conf
eingefügt haben, starten Sie &man.inetd.8; mit
dem Kommando /etc/rc.d/inetd restart
durch.Kerberos-Clients
einrichtenKerberos5Clients einrichtenEin Client lässt sich leicht einrichten.
Sie benötigen nur die
Kerberos-Konfigurationsdatei
/etc/krb5.conf. Kopieren Sie
die Konfigurationsdatei einfach vom KDC
auf den Client.Sie können jetzt mit kinit
Tickets anfordern, mit klist Tickets
anzeigen und mit kdestroy Tickets
löschen. Sie können mit
Kerberos-Anwendungen kerberisierte
Server ansprechen. Wenn das nicht funktioniert,
Sie aber Tickets anfordern können, hat wahrscheinlich
der kerberisierte Server ein Problem und nicht der
Client oder das KDC.Wenn Sie eine Anwendung wie telnet
testen, können Sie mit einem Paket-Sniffer
(beispielsweise &man.tcpdump.1;) überprüfen,
dass Passwörter verschlüsselt übertragen
werden. Probieren Sie auch die Option
von telnet, die den gesamten Datenverkehr
verschlüsselt (analog zu ssh).Zu Heimdal gehören noch weitere Anwendungen.
Allerdings enthält das &os;-Basissystem nur eine
minimale Heimdal-Installation mit nur einer
kerberisierten Anwendung: telnet.Der Heimdal-Port enthält noch mehr kerberisierte
Anwendungen wie ftp, rsh,
rcp und rlogin.
Der MIT-Port enthält ebenfalls
weitere kerberisierte Anwendungen..k5login und
.k5users.k5login.k5usersNormalerweise wird ein
Kerberos-Prinzipal wie
tillman@EXAMPLE.ORG auf ein lokales
Benutzerkonto, beispielsweise tillman,
abgebildet. Daher benötigen Client-Anwendungen (zum
Beispiel telnet) keinen Benutzernamen.Manchmal wird aber Zugriff auf ein lokales Benutzerkonto
benötigt, zu dem es keinen passenden
Kerberos-Prinzipal gibt.
Der Prinzipal tillman@EXAMPLE.ORG
bräuchte beispielsweise Zugriff auf das Konto
webdevelopers. Ebenso könnten
andere Prinzipale auf dieses Konto zugreifen wollen.Die Dateien .k5login und
.k5users im Heimatverzeichnis eines
Benutzerkontos gewähren Zugriffe ähnlich wie
die Dateien .hosts und
.rhosts. Um den Prinzipalen
tillman@example.org und
jdoe@example.org auf das Konto
webdevelopers zu geben, wird im
Heimatverzeichnis von webdevelopers
die Datei .k5login mit folgendem
Inhalt angelegt:tillman@example.org
jdoe@example.orgDie angegebenen Prinzipale haben nun ohne ein gemeinsames
Passwort Zugriff auf das Konto.Einzelheiten entnehmen Sie bitte den Hilfeseiten
zu diesen Dateien. Die Datei .k5users
wird in der Hilfeseite des Kommandos ksu
beschrieben.Tipps und FehlersucheKerberos5FehlersucheWenn Sie den Heimdal-Port oder den
MIT-Port benutzen, muss in der
Umgebungsvariable PATH der Pfad zu
den Programmen des Ports vor dem Pfad zu den
Kerberos-Programmen des Systems
stehen.Sind die Uhrzeiten der Systeme synchronisiert?
Wenn nicht, schlägt vielleicht die Authentifizierung
fehl. beschreibt, wie
Sie mithilfe von NTP die Uhrzeiten
synchronisieren.Die MIT- und Heimdal-Systeme
arbeiten bis auf kadmin gut zusammen.
Für kadmin wurde das Protokoll
nicht normiert.Wenn Sie den Namen eines Rechners ändern,
müssen Sie auch den host/-Prinzipal
ändern und die Datei keytab
aktualisieren. Dies betrifft auch spezielle Einträge
wie den Prinzipal für Apaches www/mod_auth_kerb.Die Rechnernamen müssen vor- und
rückwärts aufgelöst werden (im
DNS oder in
/etc/hosts).
CNAME-Einträge im
DNS funktionieren, aber die
entsprechenden A- und PTR-Einträge müssen
vorhanden und richtig sein. Wenn sich Namen nicht
auflösen lassen, ist die Fehlermeldung nicht
gerade selbstsprechend: Kerberos5 refuses
authentication because Read req
failed: Key table entry not found.Einige Betriebssysteme installieren
ksu mit falschen Zugriffsrechten;
es fehlt das Set-UID-Bit für root.
Das mag aus Sicherheitsgründen richtig sein,
doch funktioniert ksu dann nicht.
Dies ist kein Fehler des KDCs.Wenn Sie für einen Prinzipal unter
MIT-Kerberos
Tickets mit einer längeren Gültigkeit als
der vorgegebenen zehn Stunden einrichten wollen,
müssen Sie zwei Sachen ändern. Benutzen
Sie das modify_principal von
kadmin, um die maximale
Gültigkeitsdauer für den Prinzipal selbst
und den Prinzipal krbtgt
zu erhöhen.Mit einem Packet-Sniffer können Sie feststellen,
dass Sie sofort nach dem Aufruf von kinit
eine Antwort vom KDC
bekommen – noch bevor Sie überhaupt ein
Passwort eingegeben haben! Das ist in Ordnung:
Das KDC händigt
ein Ticket-Granting-Ticket (TGT)
auf Anfrage aus, da es durch einen vom Passwort
des Benutzers abgeleiteten Schlüssel
geschützt ist. Wenn das Passwort
eingegeben wird, wird es nicht zum KDC
gesendet, sondern zum Entschlüsseln der
Antwort des KDCs benutzt, die
kinit schon erhalten hat.
Wird die Antwort erfolgreich entschlüsselt,
erhält der Benutzer einen Sitzungs-Schlüssel
für die künftige verschlüsselte
Kommunikation mit dem KDC und das
Ticket-Granting-Ticket. Das Ticket-Granting-Ticket
wiederum ist mit dem Schlüssel des KDCs
verschlüsselt. Diese Verschlüsselung ist
für den Benutzer völlig transparent und
erlaubt dem KDC,
die Echtheit jedes einzelnen TGT
zu prüfen.Wenn Sie OpenSSH verwenden
und Tickets mir einer langen Gültigkeit
(beispielsweise einer Woche) benutzen, setzen Sie die Option
in der Datei
sshd_config auf no.
Ansonsten werden Ihre Tickets gelöscht, wenn Sie
sich abmelden.Host-Prinzipale können ebenfalls Tickets mit
längerer Gültigkeit besitzen. Wenn der
Prinzipal eines Benutzers über ein Ticket verfügt,
das eine Woche gültig ist, das Ticket des
Host-Prinzipals aber nur neun Stunden gültig ist,
funktioniert der Ticket-Cache nicht wie erwartet.
Im Cache befindet sich dann ein abgelaufenes Ticket
des Host-Prinzipals.Wenn Sie mit krb5.dict die
Verwendung schlechter Passwörter verhindern wollen,
geht das nur mit Prinzipalen, denen eine Passwort-Policy
zugewiesen wurde. Die Hilfeseite von
kadmind beschreibt kurz, wie
krb5.dict verwendet wird. Das
Format von krb5.dict ist
einfach: Die Datei enthält pro Zeile ein Wort.
Sie können daher einen symbolischen Link auf
/usr/share/dict/words erstellen.Unterschiede zum MIT-PortDer Hauptunterschied zwischen
MIT-Kerberos
und Heimdal-Kerberos
ist das Kommando kadmin.
Die Befehlssätze des Kommandos (obwohl funktional
gleichwertig) und das verwendete
Protokoll unterscheiden sich in beiden Varianten.
Das KDC lässt sich nur mit
dem kadmin Kommando der passenden
Kerberos-Variante verwalten.Für dieselbe Funktion können auch die
Client-Anwendungen leicht geänderte Kommandozeilenoptionen
besitzen. Folgen Sie bitte der Anleitung auf der
Kerberos-Seite
() des
MITs. Achten Sie besonders auf den
Suchpfad für Anwendungen. Der MIT-Port
wird standardmäßig in /usr/local/
installiert. Wenn die Umgebungsvariable PATH
zuerst die Systemverzeichnisse enthält, werden die
Systemprogramme anstelle der MIT-Programme
ausgeführt.Wenn Sie den MIT-Port
security/krb5 verwenden,
erscheint bei der Anmeldung mit telnetd
und klogind die Fehlermeldung
incorrect permissions on cache file.
Lesen Sie dazu bitte die im Port enthaltene Datei
/usr/local/share/doc/krb5/README.FreeBSD.
Wichtig ist, dass zur Authentifizierung die Binärdatei
login.krb5 verwendet wird, die
für durchgereichte Berechtigungen die Eigentümer
korrekt ändert.In der Datei rc.conf müssen
folgende Zeilen aufgenommen werden:kerberos5_server="/usr/local/sbin/krb5kdc"
kadmind5_server="/usr/local/sbin/kadmind"
kerberos5_server_enable="YES"
kadmind5_server_enable="YES"Diese Zeilen sind notwendig, weil die Anwendungen
von MIT-Kerberos Binärdateien
unterhalb von /usr/local installieren.Beschränkungen von
KerberosKerberos5BeschränkungenKerberos muss ganzheitlich
verwendet werdenJeder über das Netzwerk angebotetene Dienst
muss mit Kerberos
zusammenarbeiten oder auf anderen Wegen gegen Angriffe
aus dem Netzwerk geschützt sein. Andernfalls
können Berechtigungen gestohlen und wiederverwendet
werden. Es ist beispielsweise nicht sinnvoll, für
Anmeldungen mit rsh und
telnetKerberos
zu benutzen, dagegen aber POP3-Zugriff
auf einen Mail-Server zu erlauben, da POP3
Passwörter im Klartext versendet.Kerberos ist für
Einbenutzer-Systeme gedachtIn Mehrbenutzer-Umgebungen ist
Kerberos unsicherer als in
Einbenutzer-Umgebungen, da die Tickets im für alle
lesbaren Verzeichnis /tmp
gespeichert werden. Wenn ein Rechner von mehreren
Benutzern verwendet wird, ist es möglich, dass
Tickets gestohlen werden.Dieses Problem können Sie lösen, indem Sie mit
der Kommandozeilenoption oder besser
mit der Umgebungsvariablen KRB5CCNAME einen
Ort für die Tickets vorgeben. Diese Vorgehensweise
wird leider selten benutzt. Es reicht, die Tickets
im Heimatverzeichnis eines Benutzers zu speichern und
mit Zugriffsrechten zu schützen.Das KDC ist verwundbarDas KDC muss genauso abgesichert
werden wie die auf ihm befindliche Passwort-Datenbank.
Auf dem KDC dürfen keine anderen
Dienste laufen und der Rechner sollte physikalisch
gesichert sein. Die Gefahr ist groß, da
Kerberos alle Passwörter
mit einem Schlüssel, dem Haupt-Schlüssel,
verschlüsselt. Der Haupt-Schlüssel wiederum
wird in einer Datei auf dem KDC
gespeichert.Ein kompromittierter Haupt-Schlüssel ist nicht
ganz so schlimm wie allgemein angenommen. Der
Haupt-Schlüssel wird nur zum Verschlüsseln
der Passwort-Datenbank und zum Initialisieren des
Zufallsgenerators verwendet. Solange der Zugriff
auf das KDC abgesichert ist, kann
ein Angreifer wenig mit dem Haupt-Schlüssel
anfangen.Wenn das KDC nicht zur Verfügung
steht, vielleicht wegen eines Denial-of-Service Angriffs
oder wegen eines Netzwerkproblems, ist eine Authentifizierung
unmöglich. Damit können die Netzwerk-Dienste
nicht benutzt werden; das KDC ist
also ein optimales Ziel für einen Denial-of-Service
Angriff. Sie können diesem Angriff ausweichen,
indem Sie mehrere KDCs (einen Master
und einen oder mehrere Slaves) verwenden. Der Rückfall
auf ein sekundäres KDC oder
eine andere Authentifizierungs-Methode (dazu ist
PAM bestens geeignet) muss sorgfältig
eingerichtet werden.Mängel von
KerberosMit Kerberos können
sich Benutzer, Rechner und Dienste gegenseitig
authentifizieren. Allerdings existiert kein Mechanismus,
der das KDC gegenüber Benutzern,
Rechnern oder Diensten authentifiziert. Ein verändertes
kinit könnte beispielsweise alle
Benutzernamen und Passwörter abfangen. Die von
veränderten Programmen ausgehende Gefahr können
Sie lindern, indem Sie die Integrität von Dateien
mit Werkzeugen wie
security/tripwire
prüfen.Weiterführende DokumentationKerberos5weiterführende DokumentationThe
Kerberos FAQDesigning
an Authentication System: a Dialogue in Four
ScenesRFC 1510,
The Kerberos Network
Authentication Service (V5)MIT
Kerberos-SeiteHeimdal
Kerberos-SeiteTomRhodesBeigetragen von OpenSSLSicherheitOpenSSLOpenSSLEs wird oft übersehen, dass
OpenSSL Teil des &os;-Basissystems
ist. OpenSSL bietet eine
verschlüsselte Transportschicht oberhalb der
normalen Kommunikationsschicht und kann daher zusammen
mit vielen Netzdiensten benutzt werden.Anwendungsbeispiele für OpenSSL
sind die verschlüsselte Authentifizierung von
E-Mail-Clients oder Web-Transaktionen wie das Bezahlen mit
einer Kreditkarte. OpenSSL
kann während des Baus in viele Ports, wie
www/apache13-ssl und
mail/sylpheed-claws,
integriert werden.Ist beim Aufruf von make die
Variable WITH_OPENSSL_BASE nicht
explizit auf yes gesetzt, baut
die Ports-Sammlung meist den Port
security/openssl.Das OpenSSL von &os; stellt
die Protokolle Secure Sockets Layer v2/v3 (SSLv2/SSLv3) und
Transport Layer Security v1 (TLSv1) zur Verfügung.
Die OpenSSL-Bibliotheken stellen
kryptographische Funktionen bereit.Mit OpenSSL kann der
IDEA-Algorithmus verwendet werden,
wegen Patenten in den USA ist der Algorithmus in der
Voreinstellung allerdings deaktiviert. Wenn Sie die
IDEA-Lizenz akzeptieren, können
Sie den IDEA-Algorithmus aktivieren,
indem Sie die Variable MAKE_IDEA
in make.conf setzen.Meist wird OpenSSL eingesetzt,
um Zertifikate für Anwendungen bereitzustellen. Die
Zertifikate stellen die Identität einer Firma oder
eines Einzelnen sicher. Wenn ein Zertifikat nicht von
einer Zertifizierungsstelle (Certificate
Authority, CA)
gegengezeichnet wurde, erhalten Sie normalerweise eine
Warnung. Eine Zertifizierungsstelle ist eine Firma
wie VeriSign,
die Zertifikate von Personen oder Firmen
gegenzeichnet und damit die Korrektheit der Zertifikate
bestätigt. Diese Prozedur kostet Geld, ist aber
keine Voraussetzung für den Einsatz von Zertifikaten,
beruhigt aber sicherheitsbewusste Benutzer.Zertifikate erzeugenOpenSSLZertifikate erzeugenEin Zertifikat erzeugen Sie mit dem nachstehenden
Kommando:&prompt.root; openssl req -new -nodes -out req.pem -keyout cert.pem
Generating a 1024 bit RSA private key
................++++++
.......................................++++++
writing new private key to 'cert.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:PA
Locality Name (eg, city) []:Pittsburgh
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company
Organizational Unit Name (eg, section) []:Systems Administrator
Common Name (eg, YOUR name) []:localhost.example.org
Email Address []:trhodes@FreeBSD.org
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:SOME PASSWORD
An optional company name []:Another NameBeachten Sie bitte, dass die Eingabe bei
Common Name ein gültiger Domain-Name
sein muss. Eine andere Eingabe erzeugt ein unbrauchbares
Zertifikat. Das Zertifikat kann mit einer
Gültigkeitsdauer und anderen
Verschlüsselungsalgorithmen erzeugt werden.
Die Hilfeseite &man.openssl.1; beschreibt die zur
Verfügung stehenden Optionen.Das Verzeichnis, in dem Sie den letzten Befehl ausgeführt
haben, enthält nun zwei Dateien: Die Anforderung für
ein neues Zertifikat wurde in req.pem
gespeichert. Diese Datei können Sie an eine
Zertifizierungsstelle senden, wo Ihre Angaben geprüft werden.
Nach erfolgreicher Prüfung wird das Zertifikat an Sie
zurückgesandt. Die zweite Datei, cert.pem,
enthält den privaten Schlüssel für Ihr Zertifikat
und darf auch keine Fall in fremde Hände geraten, da ein
Angreifer sonst in der Lage ist, anderen Personen oder Rechnern
vorzugaukeln, dass es sich bei ihm um Sie handelt.Wenn Sie keine Signatur einer Zertifizierungsstelle
benötigen, können Sie ein selbst-signiertes
Zertifikat erstellen. Erzeugen Sie dazu zuerst einen
RSA-Schlüssel:&prompt.root; openssl dsaparam -rand -genkey -out myRSA.key 1024Erzeugen Sie dann den CA-Schlüssel:&prompt.root; openssl gendsa -des3 -out myca.keymyRSA.keyErstellen Sie mit diesem Schlüssel das
Zertifikat:&prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crtZwei neue Dateien befinden sich nun im Verzeichnis:
Der Schlüssel der Zertifizierungsstelle
myca.key und das Zertifikat selbst,
new.crt. Sie sollten in einem
Verzeichnis, vorzugsweise unterhalb von
/etc abgelegt
werden, das nur von root lesbar
ist. Setzen Sie die Zugriffsrechte der Dateien mit
chmod auf 0700.Beispiel für ZertifikateWas fangen Sie mit einem Zertifikat an? Sie
könnten damit beispielsweise die Verbindungen zu
Sendmail verschlüsseln.
Dies würde die Klartext-Authentifizierung
für Benutzer des lokalen MTA
überflüssig machen.Das ist nicht unbedingt die beste Lösung,
da einige MUAs Warnungen ausgeben,
wenn ein Zertifikat nicht lokal installiert ist.
Die Installation von Zertifikaten wird in der
Dokumentation der MUAs
beschrieben.Ergänzen Sie die Konfigurationsdatei von
sendmail (.mc)
um die nachstehenden Zeilen:dnl SSL Options
define(`confCACERT_PATH',`/etc/certs')dnl
define(`confCACERT',`/etc/certs/new.crt')dnl
define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnlIm Verzeichnis
/etc/certs
befindet sich der Schlüssel und das Zertifikat.
Bauen Sie danach im Verzeichnis
/etc/mail
mit dem Kommando make install
die .cf-Datei und starten
Sie anschließend sendmail
mit make restart neu.Wenn alles gut ging, erscheinen keine Fehlermeldungen
in der Datei /var/log/maillog und
Sie sehen sendmail in der
Prozessliste.Testen Sie nun den Mailserver mit dem Kommando
&man.telnet.1;:&prompt.root; telnet example.com 25
Trying 192.0.34.166...
Connected to example.com.
Escape character is '^]'.
220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)
ehlo example.com
250-example.com Hello example.com [192.0.34.166], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
quit
221 2.0.0 example.com closing connection
Connection closed by foreign host.Wenn in einer Zeile STARTTLS
erscheint, hat alles funktioniert.NikClaytonnik@FreeBSD.orgGeschrieben von VPNs mit IPsecIPsecDieser Abschnitt beschreibt, wie Sie mit &os;-Gateways
ein Virtual-Private-Network
(VPN) einrichten. Als Beispiel wird ein
VPN zwischen zwei Netzen verwendet,
die über das Internet miteinander verbunden sind.Hiten M.Pandyahmp@FreeBSD.orgGeschrieben von IPsec GrundlagenDieser Abschnitt zeigt Ihnen, wie Sie IPsec einrichten
und damit &os;-Systeme und µsoft.windows; 2000/XP Systeme
sicher miteinander verbinden. Um IPsec einzurichten,
sollten Sie einen neuen Kernel erzeugen können (siehe
).IPsec ist ein Protokoll, das auf dem Internet-Protokoll
(IP) aufbaut. Mit IPsec können mehrere Systeme
geschützt miteinander kommunizieren. Das in
&os; realisierte IPsec-Protokoll baut auf der
KAME-Implementierung
auf und unterstützt sowohl IPv4 als auch IPv6.&os enthält eine von Hardware
beschleunigte Variante des IPsec-Protokolls. Diese
Variante wurde von OpenBSD übernommen und wird
Fast-IPsec genannt. Das
&man.crypto.4;-Subsystem arbeitet mit Kryptographie-Hardware
zusammen, die IPsec beschleunigt. Das Subsystem
ist neu und bietet noch nicht alle Funktionen, die
KAME-IPsec bietet. Wenn Sie die Hardware-Beschleunigung
nutzen wollen, fügen Sie folgende Zeile der
Kernelkonfiguration hinzu:KerneloptionFAST_IPSECoptions FAST_IPSEC # new IPsec (cannot define w/ IPSEC)Momentan können Sie Fast-IPsec
nicht zusammen mit KAME-IPsec benutzen. Weiteres zu
Fast-IPsec erfahren Sie in der
Hilfeseite &man.fast.ipsec.4;.Damit Firewalls den Status von &man.gif.4;-Tunneln
überwachen können, müssen Sie die Option
in Ihrer
Kernelkonfiguration aktivieren:options IPSEC_FILTERGIF #filter ipsec packets from a tunnelIPsecESPIPsecAHIPsec besteht wiederum aus zwei Protokollen:Encapsulated Security Payload (ESP)
verschlüsselt IP-Pakete mit einem symmetrischen Verfahren
(beispielsweise Blowfish oder 3DES). Damit werden
die Pakete vor Manipulationen Dritter geschützt.Der Authentication Header (AH)
enthät eine kryptographische Prüsumme,
die sicher stellt, dass ein IP-Paket nicht verändert
wurde. Der Authentication-Header folgt nach dem
normalen IP-Header und erlaubt dem Empfänger
eines IP-Paketes, dessen Integrität zu
prüfen.ESP und AH
können, je nach Situation, zusammen oder einzeln
verwendet werden.VPNVirtual Private NetworkVPNIPsec kann in zwei Modi betrieben werden: Der
Transport-Modus verschlüsselt
die Daten zwischen zwei Systemen. Der
Tunnel-Modus verbindet zwei
Subnetze miteinander. Durch einen Tunnel können
dann beispielsweise verschlüsselte Daten übertragen
werden. Ein Tunnel wird auch als Virtual-Private-Network (VPN)
bezeichnet. Detaillierte Informationen über
das IPsec-Subsystem von &os; enthält die
Hilfeseite &man.ipsec.4;.Die folgenden Optionen in der Kernelkonfiguration
aktivieren IPsec:KerneloptionIPSECKerneloptionIPSEC_ESPoptions IPSEC #IP security
options IPSEC_ESP #IP security (crypto; define w/ IPSEC)KerneloptionIPSEC_DEBUGWenn Sie zur Fehlersuche im IPsec-Subsystem
Unterstützung wünschen, sollten Sie die
folgende Option ebenfalls aktivieren:options IPSEC_DEBUG #debug for IP securityWas ist ein VPN?Es gibt keinen Standard, der festlegt, was ein
Virtual-Private-Network ist. VPNs können mit
verschiedenen Techniken, die jeweils eigene Vor- und
Nachteile besitzen, implementiert werden.
Dieser Abschnitt stellt eine Möglichkeit vor,
ein VPN aufzubauen.VPN zwischen zwei Netzen über das InternetVPNeinrichtenDieses Szenario hat die folgenden Vorausetzungen:Es müssen zwei Netzwerke vorhanden sein.Beide Netzwerke müssen intern IP benutzen.Beide Netzwerke sind über einen &os;-Gateway
mit dem Internet verbunden.Der Gateway jedes Netzwerks besitzt mindestens
eine öffentliche IP-Adresse.Die intern verwendeten IP-Adressen können
private oder öffentliche Adressen sein.
Der Gateway kann, wenn nötig, IP-Adressen mit
NAT umschreiben.Die IP-Adressen der internen Netzwerke
dürfen nicht überlappen.
Mit NAT ließe sich diese Anforderung zwar umgehen, doch
wäre die Konfiguration und Pflege des resultierenden
Netzwerks zu aufwändig.Wenn die zu verbindenden Netzwerke intern dieselben
IP-Adressen benutzen (beispielsweise
192.168.1.x), müssen
einem der Netzwerke neue IP-Adressen zugewiesen werden.Die Netzwerktopologie sieht wie folgt aus:Netzwerk #1 [ Interne Rechner ] Privates Netz, 192.168.1.2-254
[ Win9x/NT/2K ]
[ UNIX ]
|
|
.---[fxp1]---. Private IP, 192.168.1.1
| FreeBSD |
`---[fxp0]---' Öffentliche IP, A.B.C.D
|
|
-=-=- Internet -=-=-
|
|
.---[fxp0]---. Öffentliche IP, W.X.Y.Z
| FreeBSD |
`---[fxp1]---' Private IP, 192.168.2.1
|
|
Netzwerk #2 [ Interne Rechner ]
[ Win9x/NT/2K ] Privates Netz, 192.168.2.2-254
[ UNIX ]Beachten Sie die beiden öffentlichen IP-Adressen.
Im Folgenden werden sie durch Buchstaben (als Platzhalter)
gekennzeichnet. Setzen Sie hierfür Ihre eigenen
öffentlichen IP-Adressen ein. Beide Gateways
besitzen die interne Adresse
x.x.x.1 und beide
Netzwerke besitzen unterschiedliche private IP-Adressen:
192.168.1.x und
192.168.2.x. Die Default-Route
aller internen Systeme ist jeweils die Gateway-Maschine
(x.x.x.1).Aus der Sicht der Systeme sollen jetzt beide
Netzwerke wie über einen Router, der in diesem
Fall etwas langsamer ist, verbunden werden.Auf dem Rechner 192.168.1.20
soll also beispielsweise der folgende Befehl funktionieren:ping 192.168.2.34&windows;-Systeme sollen die Systeme auf dem anderen
Netzwerk erkennen und Shares sollen funktionieren. Alles
soll genauso wie in lokalen Netzwerken funktionieren.Zusätzlich soll die Kommunikation zwischen beiden
Netzwerken noch verschlüsselt werden.Das VPN wird in mehreren Schritten aufgebaut:Zuerst wird eine virtuelle Verbindung zwischen
beiden Netzwerken über das Internet eingerichtet.
Die virtuelle Verbindung können Sie mit Werkzeugen
wie &man.ping.8; prüfen.Danach wird eine Sicherheitsrichtlinie
(Security-Policy) festgelegt,
die automatisch den Datenverkehr zwischen beiden
Netzwerken verschlüsselt und entschlüsselt.
Mit Werkzeugen wie &man.tcpdump.1; können Sie
überprüfen, dass die Daten tatsächlich
verschlüsselt werden.Wenn sich &windows;-Systeme im VPN gegenseitig
erkennen sollen, so sind noch weitere
Konfigurationsschritte notwendig, die aber nicht
in diesem Abschnitt beschrieben werden.Schritt 1: Die virtuelle Verbindung einrichtenNehmen wir an, sie wollten von der Gateway-Maschine
im Netzwerk #1 (öffentliche IP-Adresse
A.B.C.D, private IP-Adresse
192.168.1.1) das Kommando
ping 192.168.2.1 absetzen.
192.168.2.1 ist die private
IP-Adresse des Systems W.X.Y.Z
im Netzwerk #2. Welche Voraussetzungen müssen
erfüllt sein, damit der Befehl funktioniert?Die Gateway-Maschine muss das System
192.168.2.1 erreichen
können. Das heißt, eine Route zu diesem
System muss existieren.Private IP-Adressen, wie der Bereich
192.168.x, sollten im
Internet nicht verwendet werden. Jedes Paket zu
192.168.2.1 muss daher
in ein anderes Paket gepackt werden, das von
A.B.C.D kommt und
zu W.X.Y.Z geschickt
wird. Das erneute Verpacken der Pakete wird als
Kapselung bezeichnet.Wenn das Paket W.X.Y.Z
erreicht, muss es dort ausgepackt und an
192.168.2.1 ausgeliefert
werden.Sie können sich diese Prozedur so vorstellen,
dass ein Tunnel zwischen beiden Netzwerken existiert.
Die beiden Tunnel-Enden besitzen die IP-Adressen
A.B.C.D und
W.X.Y.Z. Der Tunnel
muss zudem Verkehr zwischen den privaten IP-Adressen
erlauben und transportiert so Daten zwischen privaten
IP-Adressen über das Internet.Unter &os; wird der Tunnel mit
gif-Geräten (generic
interface) erstellt. Auf jedem Gateway
muss das gif-Gerät mit
vier IP-Adressen eingerichtet werden: Zwei öffentliche
IP-Adressen und zwei private IP-Adressen.Die gif-Geräte werden vom
Kernel bereitgestellt und müssen in der
Kernelkonfigurationsdatei auf beiden Maschinen angegeben
werden:device gifWie gewöhnlich müssen Sie danach einen
neuen Kernel erstellen, installieren und das System
neu starten.Der Tunnel wird in zwei Schritten aufgebaut. Mit
&man.ifconfig.8; werden zuerst die öffentlichen
IP-Adressen konfiguriert. Anschließend werden
die privaten IP-Adressen mit &man.ifconfig.8; eingerichtet.Auf der Gateway-Maschine im Netzwerk #1 bauen
Sie den Tunnel mit den folgenden Kommandos auf:&prompt.root; ifconfig gif0 create
&prompt.root; ifconfig gif0 tunnel A.B.C.DW.X.Y.Z
&prompt.root; ifconfig gif0 inet 192.168.1.1192.168.2.1 netmask 0xffffffffAuf dem anderen Gateway benutzen Sie dieselben Kommandos,
allerdings mit vertauschten IP-Adressen:&prompt.root; ifconfig gif0 create
&prompt.root; ifconfig gif0 tunnel W.X.Y.ZA.B.C.D
&prompt.root; ifconfig gif0 inet 192.168.2.1192.168.1.1 netmask 0xffffffffDie Konfiguration können Sie anschließend mit
dem folgenden Kommando überprüfen:ifconfig gif0Auf dem Gateway in Netzwerk #1 sollten Sie
beispielsweise die nachstehende Ausgabe erhalten:&prompt.root; ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet A.B.C.D --> W.X.Y.Z
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
Wie Sie sehen, ist ein Tunnel zwischen den IP-Adressen
A.B.C.D und
W.X.Y.Z aufgebaut worden,
der Verkehr zwischen den Adressen
192.168.1.1 und
192.168.2.1 zulässt.Gleichzeitig wurde ein Eintrag in der Routing-Tabelle
erstellt, den Sie sich mit netstat -rn
ansehen können. Auf der Gateway-Maschine in Netzwerk #1
sieht das so aus:&prompt.root; netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
...
192.168.2.1 192.168.1.1 UH 0 0 gif0
...Die Route ist eine Host-Route, wie in der Spalte
Flags angegeben. Das heißt
die beiden Gateways wissen wie sie einander erreichen,
sie kennen allerdings nicht das Netzwerk auf der
anderen Seite. Dieses Problem werden wir gleich
angehen.Wahrscheinlich ist auf beiden Gateways eine Firewall
eingerichtet. Für den VPN-Verkehr muss die Firewall
umgegangen werden. Sie können generell den Verkehr
zwischen beiden Netzwerken erlauben oder Regeln erstellen,
die beide Tunnel-Enden des VPNs voreinander schützen.Der Test des VPNs wird erheblich leichter, wenn Sie
jeden Verkehr zwischen den Tunnel-Enden in der Firewall
erlauben. Wenn Sie auf der Gateway-Maschine &man.ipfw.8;
einsetzen, erlaubt die folgende Regel jeden Verkehr
zwischen den Tunnel-Enden, ohne die anderen Regeln zu
beeinflussen:ipfw add 1 allow ip from any to any via gif0Diese Regel muss offensichtlich auf beiden Gateway-Maschinen
existieren.Damit sollten Sie das Kommando ping
jetzt absetzen können. Auf dem System
192.168.1.1 sollte der
nachstehende Befehl Antworten erhalten:ping 192.168.2.1Denselben Test können Sie auch auf der anderen
Gateway-Maschine ausführen.Allerdings können Sie noch nicht die anderen
internen Maschinen auf den Netzwerken erreichen. Die Ursache
ist das Routing – die Gateway kennen sich zwar
gegenseitig, wissen aber noch nichts von den Netzwerken
hinter dem anderen Gateway.Um die Netzwerke bekannt zu geben, muss auf jeder
Gateway-Maschine noch eine statische Route hinzugefügt
werden. Auf der ersten Gateway-Maschine setzen Sie dazu
das folgende Kommando ab:route add 192.168.2.0 192.168.2.1 netmask 0xffffff00Dies entspricht der Anweisung: Um Rechner
auf dem Netz 192.168.2.0
zu erreichen, schicke die Pakete zum System
192.168.2.1. Auf
dem anderen Gateway muss das analoge Kommando (mit den
IP-Adressen 192.168.1.x)
abgesetzt werden.Damit ist jetzt der IP-Verkehr zwischen beiden
Netzwerken möglich.Zwei Drittel des VPNs zwischen beiden Netzen
ist nun eingerichtet. Es ist virtuell und
es ist ein Netzwerk. Es ist allerdings
noch nicht privat. Dies können Sie
mit &man.ping.8; und &man.tcpdump.1; überprüfen.
Setzen Sie auf dem ersten Gateway den folgenden Befehl ab:tcpdump dst host 192.168.2.1Starten Sie dann, ebenfalls auf dem ersten Gateway, den
folgenden Befehl:ping 192.168.2.1Sie werden die nachstehende Ausgabe erhalten:16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo replyDie ICMP-Nachrichten werden unverschlüsselt
übertragen. Mit der Option
von &man.tcpdump.1; können Sie sich weitere Daten
der Pakete anzeigen lassen.Die Daten sollen aber automatisch verschlüsselt
werden. Wie das geht, wird im nächsten Abschnitt
erläutert.ZusammenfassungFügen Sie in beiden Kerneln die Zeile
device gif ein und bauen Sie die Kernel
neu.Fügen Sie auf dem Gateway in Netzwerk #1
folgende Zeilen in /etc/rc.conf
ein:gif_interfaces="gif0"
gifconfig_gif0="A.B.C.D W.X.Y.Z"
ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"Setzen Sie dabei die richtigen IP-Adressen für
die Platzhalter ein.Fügen Sie auf beiden Gateways die nachstehende
Regel in das Firewall-Skript (zum Beispiel
/etc/rc.firewall) ein:ipfw add 1 allow ip from any to any via gif0Nehmen Sie in /etc/rc.conf auf dem
Gateway #2 analoge Änderungen, die IP-Adressen
müssen vertauscht werden, vor.Schritt 2: Die Verbindung mit IPsec schützenUm die Verbindung zu schützen, verwenden wir IPsec.
IPsec bietet einen Mechanismus, mit dem sich zwei
Systeme auf einen Schlüssel einigen können.
Mit diesem Schlüssel wird dann der Datenverkehr zwischen
beiden Systemen verschlüsselt.Es gibt hierbei zwei Sachen die konfiguriert werden
müssen:Die Security-Association bestimmt,
mit welchen Methoden der Verkehr zwischen beiden Systemen
verschlüsselt wird.Die Security-Policy bestimmt,
was verschlüsselt wird. Es soll ja nicht der
gesamte Datenverkehr nach außen verschlüsselt
werden, sondern nur der Teil des Verkehrs, der zum
VPN gehört.Die Security-Association wie auch die Security-Policy
werden vom Kernel verwaltet und können von Anwendungen
verändert werden. Dazu müssen allerdings zuerst
IPsec und das Encapsulated-Security-Payload (ESP) Protokoll
in die Kernelkonfigurationsdatei eingetragen werden:KerneloptionIPSECoptions IPSEC
options IPSEC_ESPWie üblich, müssen Sie danach den Kernel
übersetzen, installieren und das System neu starten.
Die Kernel müssen auf beiden Gateway-Maschinen
neu erstellt werden.IKESie können die Security-Association auf zwei
Arten konfigurieren: Manuell, dann müssen Sie
den Verschlüsselungsalgorithmus, die Schlüssel
und alles Weitere selbst konfigurieren. Oder automatisch,
mithilfe eines Dæmons, der das Internet-Key-Exchange
Protokoll (IKE) beherrscht.Im Allgemeinen wird die letzte Variante bevorzugt.
Sie ist auch wesentlich leichter einzurichten.IPsecSecurity-PolicysetkeyMit &man.setkey.8; können Sie Security-Policies
editieren und anzeigen. Die Beziehung von
setkey und der Tabelle der
Security-Policies im Kernel entspricht
dem Verhältnis von &man.route.8; und der Routing-Tabelle.
Die momentanen Security-Associations lassen sich ebenfalls
mit setkey anzeigen;
setkey verhält sich in diesem Fall
wie netstat -r, um die Analogie
fortzuführen.Sie haben die Wahl zwischen mehreren Programmen,
wenn Sie Security-Associations mit &os; verwalten
wollen. Im Folgenden wird racoon
beschrieben, das Sie über den Port security/ipsec-tools
installieren können.racoonAuf beiden Gateway-Maschinen muss
racoon laufen.
Konfiguriert wird jeweils die IP-Adresse der Gegenstelle
sowie der geheime Schlüssel. Dabei muss auf beiden
Gateway-Maschinen der gleiche Schlüssel verwendet
werden.Die beiden raccon-Daemonen prüfen mithilfe des
geheimen Schlüssels gegenseitig ihre Identität.
Anschließend generieren Sie einen neuen geheimen
Schlüssel, mit dem dann der Datenverkehr im VPN
verschlüsselt wird. Dieser Schlüssel wird
von Zeit zu Zeit geändert. Ein Angreifer,
der einen der Schlüssel geknackt hat – das ist
schon ziemlich unwahrscheinlich – kann somit nicht
viel mit diesem Schlüssel anfangen, da schon wieder ein
anderer Schlüssel verwendet wird.Die Konfiguration von racoon befindet sich in
${PREFIX}/etc/racoon. In der
dort befindlichen Konfigurationsdatei sollten Sie nicht
allzu viele Änderungen vornehmen müssen.
Sie müssen allerdings den so genannten
Pre-Shared-Key (den vorher ausgetauschten
Schlüssel) ändern.In der Voreinstellung befindet sich dieser Schlüssel
in der Datei ${PREFIX}/etc/racoon/psk.txt.
Dieser Schlüssel wird nicht zum
Verschlüsseln des Datenverkehrs verwendet. Er dient
lediglich der Authentifizierung der beiden racoon-Daemonen.Für jeden entfernten Kommunikationspartner enthält
psk.txt eine Zeile. Damit besteht die
Datei psk.txt in unserem Beispiel
aus einer Zeile (wir verwenden einen entfernten
Kommunikationspartner).Auf dem Gateway #1 sieht diese Zeile wie
folgt aus:W.X.Y.Z geheimDie Zeile besteht aus der öffentlichen IP-Adresse
der Gegenstelle, Leerzeichen und dem geheimen Schlüssel.
Sie sollten natürlich nicht geheim
verwenden. Für den geheimen Schlüssel gelten
dieselben Regeln wie für Passwörter.Auf dem anderen Gateway sieht die Zeile
folgendermaßen aus:A.B.C.D geheimDie Zeile besteht aus der öffentlichen IP-Adresse
der Gegenstelle, Leerzeichen und dem geheimen Schlüssel.
Die Zugriffsrechte von psk.txt müssen
auf 0600 (Lese- und Schreibzugriff nur
für root) gesetzt sein, bevor
racoon gestartet wird.Auf beiden Gateway-Maschinen muss racoon laufen. Sie
brauchen ebenfalls Firewall-Regeln, die IKE-Verkehr
erlauben. IKE verwendet UDP, um Nachrichten zum
ISAKMP-Port (Internet Security Association Key Management Protocol)
zu schicken. Die Regeln sollten früh in der
Regelkette auftauchen:ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmpWenn racoon läuft, können Sie versuchen,
mit ping von einem Gateway-Rechner aus
den anderen Gateway zu erreichen. Die Verbindung wird zwar immer
noch nicht verschlüsselt, aber racoon wird die
Security-Association zwischen beiden Systemen einrichten.
Dies kann eine Weile dauern, und Sie bemerken vielleicht
eine kleine Verzögerung, bevor die Antworten von
der Gegenstelle kommen.Die Security-Association können Sie sich auf einem
der beiden Gateway-Systeme mit &man.setkey.8; ansehen:setkey -DDamit ist die erste Hälfte der Arbeit getan.
Jetzt muss noch die Security-Policy konfiguriert werden.Damit wir eine sinnvolle Security-Policy erstellen
können, fassen wir das bisher geleistete zusammen.
Die Diskussion gilt für beide Enden des Tunnels.Jedes gesendete IP-Paket enthält im Header
Informationen über das Paket selbst. Im Header
befinden sich die IP-Adressen des Senders und des
Empfängers. Wie wir bereits wissen, dürfen
private IP-Adressen, wie
192.168.x.y nicht auf
das Internet gelangen. Pakete zu privaten IP-Adressen
müssen zuerst in einem anderen Paket gekapselt
werden. In diesem Paket werden die privaten IP-Adressen
durch öffentliche IP-Adressen ersetzt.Das ausgehende Paket hat beispielsweise wie folgt
ausgesehen:
.----------------------.
| Src: 192.168.1.1 |
| Dst: 192.168.2.1 |
| <other header info> |
+----------------------+
| <packet data> |
`----------------------'Es wird in ein anderes Paket umgepackt (gekapselt)
und sieht danach wie folgt aus:
.--------------------------.
| Src: A.B.C.D |
| Dst: W.X.Y.Z |
| <other header info> |
+--------------------------+
| .----------------------. |
| | Src: 192.168.1.1 | |
| | Dst: 192.168.2.1 | |
| | <other header info> | |
| +----------------------+ |
| | <packet data> | |
| `----------------------' |
`--------------------------'Die Kapselung wird vom gif-Gerät
vorgenommen. Das neue Paket enthält im Header eine
öffentliche IP-Adresse und der Datenteil des Pakets
enthält das ursprüngliche Paket.Natürlich soll der gesamte Datenverkehr des VPNs
verschlüsselt werden. Dies kann man wie folgt
ausdrücken:Wenn ein Paket von A.B.C.D
zu W.X.Y.Z geschickt wird,
verschlüssele es entsprechend der
Security-Association.Wenn ein Paket von W.X.Y.Z
kommt und für A.B.C.D
bestimmt ist, entschlüssele es entsprechend der
Security-Association.Das ist fast richtig. Mit diesen Regeln würde
der ganze Verkehr von und zu W.X.Y.Z
verschlüsselt, auch wenn er nicht zum VPN gehört.
Die richtige Formulierung lautet:Wenn ein Paket, das ein gekapseltes Paket enthält,
von A.B.C.D zu
W.X.Y.Z geschickt wird,
verschlüssele es entsprechend der
Security-Association.Wenn ein Paket, das ein gekapseltes Paket enthält,
von W.X.Y.Z kommt und für
A.B.C.D bestimmt ist,
entschlüssele es entsprechend der
Security-Association.Dies ist eine zwar subtile aber eine
notwendige Änderung.Die Security-Policy können Sie mit &man.setkey.8;
erstellen. &man.setkey.8; besitzt eine Konfigurations-Syntax
zur Erstellung der Security-Policy. Sie können die
Konfiguration über die Standardeingabe oder in einer
Datei, die Sie mit der Option angeben,
erstellen.Gateway #1 (öffentliche IP-Adresse:
A.B.C.D) muss
folgendermaßen konfiguriert werden, um alle
ausgehenden Pakete an W.X.Y.Z
zu verschlüsseln:spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;Speichern Sie dieses Kommando in einer Datei, beispielsweise
/etc/ipsec.conf ab. Rufen Sie
anschließend das nachstehende Kommando auf:&prompt.root; setkey -f /etc/ipsec.conf weist &man.setkey.8; an,
der Security-Policy-Datenbank eine Regel hinzuzufügen.
Der Rest der Zeile gibt an, auf welche Pakete diese
Regel zutrifft. A.B.C.D/32
und W.X.Y.Z/32 sind
die IP-Adressen und Netzmasken, die Systeme angeben,
auf die diese Regel zutrifft. Im Beispiel gilt die
Regel für die beiden Gateway-Systeme.
zeigt an, dass die Regel nur
für Pakete gilt, die gekapselte Pakete enthalten.
legt fest, dass die Regel nur
für ausgehende Pakete gilt. gibt an, dass die Pakete
geschützt werden. Das benutzte Protokoll
wird durch angegeben.
kapselt das Paket in ein
IPsec-Paket. Die nochmalige Angabe von
A.B.C.D und
W.X.Y.Z gibt die
Security-Association an. Das abschließende
erzwingt die Verschlüsselung
der Pakete.Diese Regel gilt nur für ausgehende Pakete.
Sie brauchen eine analoge Regel für eingehende
Pakete:spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;In dieser Regel wird anstelle
von benutzt und die IP-Adressen
sind notwendigerweise umgekehrt angegeben.Das zweite Gateway-System mit der IP-Adresse
W.X.Y.Z braucht
entsprechende Regeln:spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;Schließlich brauchen Sie auf beiden Gateway-Systemen
noch Firewall-Regeln, die ESP- und IPENCAP-Pakete in beide
Richtungen erlauben:ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.DDa die Regeln symmetrisch sind, können sie auf
beiden Systemen verwendet werden.Damit sehen ausgehende Pakete wie folgt aus:
.------------------------------. --------------------------.
| Src: A.B.C.D | |
| Dst: W.X.Y.Z | |
| < weitere Header > | | Encrypted
+------------------------------+ | packet.
| .--------------------------. | -------------. | contents
| | Src: A.B.C.D | | | | are
| | Dst: W.X.Y.Z | | | | completely
| | < weitere Header > | | | |- secure
| +--------------------------+ | | Encap'd | from third
| | .----------------------. | | -. | packet | party
| | | Src: 192.168.1.1 | | | | Original |- with real | snooping
| | | Dst: 192.168.2.1 | | | | packet, | IP addr |
| | | < weitere Header > | | | |- private | |
| | +----------------------+ | | | IP addr | |
| | | <Paket-Daten> | | | | | |
| | `----------------------' | | -' | |
| `--------------------------' | -------------' |
`------------------------------' --------------------------'
Am anderen Ende des VPNs werden die Pakete zuerst
entsprechend der von racoon ausgehandelten Security-Association
entschlüsselt. Das gif-Interface
entfernt dann die zweite Schicht, damit das ursprüngliche
Paket zum Vorschein kommt. Dieses kann dann in das interne
Netzwerk transportiert werden.Dass die Pakete wirklich verschlüsselt werden,
können Sie wieder mit &man.ping.8; überprüfen.
Melden Sie sich auf dem Gateway
A.B.C.D an und rufen
das folgende Kommando auf:tcpdump dst host 192.168.2.1Auf demselben Rechner setzen Sie dann noch das
nachstehende Kommando ab:ping 192.168.2.1Dieses Mal wird die Ausgabe wie folgt aussehen:XXX tcpdump outputJetzt zeigt &man.tcpdump.1; ESP-Pakete an. Auch wenn
Sie diese mit der Option untersuchen,
werden Sie wegen der Verschlüsselung nur
unverständliche Zeichen sehen.Herzlichen Glückwunsch. Sie haben soeben ein
VPN zwischen zwei entfernten Netzen eingerichtet.ZusammenfassungIPsec muss in beiden Kernelkonfigurationsdateien
enthalten sein:options IPSEC
options IPSEC_ESPInstallieren Sie den Port security/ipsec-tools. Tragen Sie
auf beiden Rechnern in
${PREFIX}/etc/racoon/psk.txt jeweils
die IP-Adresse des entfernten Gateways und den geheimen
Schlüssel ein. Setzen Sie die Zugriffsrechte der
Datei auf 0600.Fügen Sie auf jedem Rechner die folgenden
Zeilen zu /etc/rc.conf hinzu:ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"Erstellen Sie auf jedem Rechner die Datei
/etc/ipsec.conf mit den nötigen
-Zeilen. Auf dem Gateway #1
hat die Datei folgenden Inhalt:spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
esp/tunnel/W.X.Y.Z-A.B.C.D/require;Auf dem Gateway #2 sieht die Datei so aus:spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
esp/tunnel/A.B.C.D-W.X.Y.Z/require;Fügen Sie auf beiden Rechnern Firewall-Regeln
hinzu, die IKE-, ESP- und IPENCAP-Verkehr erlauben:ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.DDas VPN wurde in zwei Schritten eingerichtet. Maschinen
auf beiden Netzen können miteinander kommunizieren
und der Datenverkehr zwischen beiden Netzen wird automatisch
verschlüsselt.ChernLeeBeigetragen von OpenSSHOpenSSHSicherheitOpenSSHOpenSSH stellt Werkzeuge bereit,
um sicher auf entfernte
Maschinen zuzugreifen. Die Kommandos rlogin,
rsh, rcp und
telnet können durch
OpenSSH ersetzt werden.
Zusätzlich können TCP/IP-Verbindungen sicher durch
SSH weitergeleitet (getunnelt) werden. Mit SSH werden alle
Verbindungen verschlüsselt, dadurch wird verhindert, dass
die Verbindung zum Beispiel abgehört oder übernommen
(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.Vorteile von OpenSSHMit &man.telnet.1; oder &man.rlogin.1; werden Daten in
einer unverschlüsselten Form über das Netzwerk
gesendet. Daher besteht die Gefahr, das Benutzer/Passwort
Kombinationen oder alle Daten an beliebiger Stelle zwischen
dem Client und dem Server abgehört werden. Mit
OpenSSH stehen eine Reihe von
Authentifizierungs- und Verschlüsselungsmethoden zur
Verfügung, um das zu verhindern.Aktivieren von sshdOpenSSHaktivierenUnter &os; entscheidet der
Anwender bei einer Standard-Installation, ob
der sshd-Daemon aktiviert werden soll.
Um zu überprüfen, ob sshd
auf Ihrem System aktiviert ist, suchen Sie in
rc.conf nach der folgenden Zeile:sshd_enable="YES"Ist diese Zeile vorhanden, wird &man.sshd.8;, der
OpenSSH-Dæmon, beim
Systemstart automatisch aktiviert. Alternativ können Sie
OpenSSH auch über das
&man.rc.8;-Skript /etc/rc.d/sshd
starten:/etc/rc.d/sshd startSSH ClientOpenSSHClient&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 aktuelle
OpenSSH-Server nur SSH v2
Verbindungen. Wenn möglich, wird Version 2 verwendet,
ist dies nicht möglich, fällt der Server auf
Version 1 zurück. Der Client kann gezwungen werden,
nur eine der beiden Versionen zu verwenden, indem die Option
(für die Version 1) oder
(für die Version 2) übergeben
wird. Die Unterstützung für Version 1 ist nur
noch aus Kompatibilitätsgründen zu älteren
Versionen enthalten.Secure CopyOpenSSHsecure copyscpMit &man.scp.1; lassen sich Dateien analog wie mit
&man.rcp.1; 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,
dass die ersten Argumente die zu kopierenden Dateien sind und
das letzte Argument den Bestimmungsort angibt. Da die Dateien
über das Netzwerk kopiert werden, können ein oder mehrere
Argumente die Form
besitzen.KonfigurationOpenSSHKonfigurationDie 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ässt sich weiterhin über die
Anweisungen (Vorgabe ist
/usr/sbin/sshd) und
in /etc/rc.conf
konfigurieren.ssh-keygenMit &man.ssh-keygen.1; können DSA- oder RSA-Schlüssel
für einen Benutzer erzeugt werden, die anstelle von
Passwörtern verwendet werden können:&prompt.user; ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com
&man.ssh-keygen.1; erzeugt einen öffentlichen und einen
privaten Schlüssel für die Authentifizierung. Der private
Schlüssel wird in ~/.ssh/id_dsa oder
~/.ssh/id_rsa gespeichert, während
sich der öffentliche Schlüssel in
~/.ssh/id_dsa.pub oder
~/.ssh/id_rsa.pub befindet, je nachdem,
ob es sich um einen DSA- oder einen
RSA-Schlüssel handelt.
Der öffentliche Schlüssel muss sowohl für
RSA- als auch für
DSA-Schlüssel in die Datei
~/.ssh/authorized_keys auf dem entfernten
Rechner aufgenommen werden, damit der Schlüssel
funktioniert.Damit werden Verbindungen zu der entfernten Maschine über
SSH-Schlüsseln anstelle von Passwörtern
authentifiziert.Wenn bei der Erstellung der Schlüssel mit
&man.ssh-keygen.1; ein Passwort angegeben wurde, wird der
Benutzer bei jeder Anmeldung zur Eingabe des Passworts
aufgefordert. Um den Umgang mit SSH-Schlüsseln zu
erleichtern, kann &man.ssh-agent.1; die Verwaltung dieser
Schlüssel für Sie übernehmen. Lesen Sie dazu
den weiter unten.Die Kommandozeilenoptionen und Dateinamen sind
abhängig von der OpenSSH-Version.
Die für Ihr System gültigen Optionen finden Sie
in der Hilfeseite &man.ssh-keygen.1;.ssh-agent und ssh-addMit &man.ssh-agent.1; und &man.ssh-add.1; ist es
möglich, SSH-Schlüssel
in den Speicher zu laden, damit die Passphrase nicht jedesmal
eingegeben werden muss.&man.ssh-agent.1; übernimmt die Authentifizierung
von ihm geladener privater Schlüssel.
&man.ssh-agent.1; sollte nur dazu verwendet werden, ein
anderes Programm zu starten, beispielsweise eine Shell oder
einen Window-Manager.Um &man.ssh-agent.1; in einer Shell zu verwenden, muss
es mit einer Shell als Argument aufgerufen werden.
Zusätzlich müssen die zu verwaltende Identität
(durch &man.ssh-add.1;) sowie deren Passphrase für den
privaten Schlüssel übergeben werden. Nachdem dies
erledigt ist, kann sich ein Benutzer über &man.ssh.1;
auf jedem Rechner anmelden, der einen entsprechenden
öffentlichen Schlüssel besitzt. Dazu ein
Beispiel:&prompt.user; ssh-agent csh
&prompt.user; ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
&prompt.user;Um &man.ssh-agent.1; unter X11 zu verwenden, müssen
Sie &man.ssh-agent.1; in Ihre ~/.xinitrc
aufnehmen. Dadurch können alle unter X11 gestarteten
Programme die Dienste von &man.ssh-agent.1; nutzen. Ihre
~/.xinitrc könnte dazu etwas so
aussehen:exec ssh-agent startxfce4Dadurch wird bei jedem Start von X11 zuerst
&man.ssh-agent.1; aufgerufen, das wiederum
XFCE startet. Nachdem Sie diese
Änderung durchgeführt haben, müssen Sie X11
neu starten. Danach können Sie mit &man.ssh-add.1;
Ihre SSH-Schlüssel laden.SSH-TunnelOpenSSHTunnelMit 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 Optionen von ssh
verwendet:Erzwingt die Version 2 des Protokolls (Benutzen Sie die
Option nicht mit langsamen
SSH-Servern).Zeigt an, dass 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 SSH 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 ESMTPZusammen mit &man.ssh-keygen.1; und zusätzlichen
Benutzer-Accounts können Sie leicht benutzbare SSH-Tunnel
aufbauen. Anstelle von Passwörtern können Sie
Schlüssel benutzen und jeder Tunnel kann unter einem eigenen
Benutzer laufen.Beispiel für SSH-TunnelSicherer Zugriff auf einen POP3-ServerNehmen 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, dass er POP3 Anfragen zu
localhost Port 2110 sendet. Die Verbindung
wird dann sicher zu mail.example.com
weitergeleitet.Umgehen einer strengen FirewallEinige Netzwerkadministratoren stellen sehr drakonische
Firewall-Regeln auf, die nicht nur einkommende Verbindungen
filtern, sondern auch ausgehende. Es kann sein, dass Sie
externe Maschinen nur über die Ports 22 und 80 (SSH und
Web) erreichen.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-system.example.org
user@unfirewalled-system.example.org's password: *******Konfigurieren Sie Ihren Client so, dass er
localhost und Port 8888 benutzt. Die Verbindung
wird dann zu music.example.com Port 8000
weitergeleitet und Sie haben die Firewall erfolgreich
umgangen.Die Option AllowUsersEs ist in der Regel ein gute Idee, festzulegen, welche
Benutzer sich von welchem Rechner aus anmelden können.
Dies lässt sich beispielsweise über die Option
AllowUsers festlegen. Soll sich etwa
nur root vom Rechner mit der IP-Adresse
192.168.1.32 aus einwählen
dürfen, würden Sie folgenden Eintrag in
/etc/ssh/sshd_config aufnehmen:AllowUsers root@192.168.1.32Damit sich admin von jedem Rechner aus
anmelden kann, geben Sie nur den Benutzernamen an:AllowUsers adminSie können auch mehrere Benutzer in einer Zeile
aufführen:AllowUsers root@192.168.1.32 adminNur ein Benutzer, der in dieser Liste aufgeführt ist,
darf sich auf diesem Rechner anmelden.Nachdem Sie /etc/ssh/sshd_config
angepasst haben, muss &man.sshd.8; seine Konfigurationsdateien
neu einlesen. Dazu geben Sie Folgendes ein:&prompt.root; /etc/rc.d/sshd reloadWeiterführende InformationenOpenSSH&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
&man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5;&man.sshd.8; &man.sftp-server.8; &man.sshd.config.5;TomRhodesBeigetragen von ACLZugriffskontrolllisten für DateisystemeZusammen mit anderen Verbesserungen des Dateisystems wie
Schnappschüsse gibt es ab &os; 5.0
Zugriffskontrolllisten (access
control list, ACL).Zugriffskontrolllisten erweitern die normalen Zugriffsrechte
von &unix; Systemen auf eine kompatible (&posix;.1e) Weise
und bieten feiner granulierte Sicherheitsmechanismen.Zugriffskontrolllisten für Dateisysteme werden mit der
nachstehenden Zeile in der Kernelkonfiguration aktiviert:options UFS_ACLDiese Option ist in der GENERIC-Konfiguration
aktiviert. Das System gibt eine Warnung aus, wenn ein Dateisystem mit
ACLs eingehangen werden soll und die
Unterstützung für ACLs nicht im Kernel
aktiviert ist. Das Dateisystem muss weiterhin erweiterte Attribute
zur Verfügung stellen, damit ACLs verwendet
werden können. Das neue UNIX-Dateisystem
UFS2 stellt diese Attribute
standardmäßig zur Verfügung.Die Konfiguration erweiterter Attribute auf
UFS1 ist mit einem höheren Aufwand als die
Konfiguration erweiterter Attribute auf UFS2
verbunden. Zudem ist UFS2 mit erweiterten
Attributen leistungsfähiger als UFS1.
Zugriffskontrolllisten sollten daher mit UFS2
verwendet werden.Die Angabe der Option in
/etc/fstab aktiviert Zugriffskontrolllisten
für ein Dateisystem. Die bevorzugte Möglichkeit ist
die Verwendung von Zugriffskontrolllisten mit &man.tunefs.8; (Option
), im Superblock des Dateisystems festzuschreiben.
Diese Möglichkeit hat mehrere Vorteile:Nochmaliges Einhängen eines Dateisystems (Option
von &man.mount.8;) verändert den Status
der Zugriffskontrolllisten nicht. Die Verwendung von
Zugriffskontrolllisten kann nur durch Abhängen und erneutes
Einhängen eines Dateisystems verändert werden. Das
heißt auch, dass Zugriffskontrolllisten nicht
nachträglich auf dem Root-Dateisystem aktiviert werden
können.Die Zugriffskontrolllisten auf den Dateisystemen sind,
unabhängig von den Option in /etc/fstab
oder Namensänderungen der Geräte, immer aktiv. Dies
verhindert auch, dass Zugriffskontrolllisten aus Versehen
auf Dateisystem ohne Zugriffskontrolllisten aktiviert werden und
durch falsche Zugriffsrechte Sicherheitsprobleme entstehen.Es kann sein, dass sich der Status von Zugriffskontrolllisten
später durch nochmaliges Einhängen des Dateisystems
(Option von &man.mount.8;) ändern
lässt. Die momentane Variante ist aber sicherer, da der
Status der Zugriffskontrolllisten nicht versehentlich geändert
werden kann. Allgemein sollten Zugriffskontrolllisten auf einem
Dateisystem, auf dem sie einmal verwendet wurden, nicht deaktiviert
werden, da danach die Zugriffsrechte falsch sein können.
Werden Zugriffskontrolllisten auf einem solchen Dateisystem wieder
aktiviert, werden die Zugriffsrechte von Dateien, die sich
zwischenzeitlich geändert haben, überschrieben, was zu
erneuten Problemen führt.Die Zugriffsrechte einer Datei werden durch ein
+ (Plus) gekennzeichnet, wenn die Datei durch
Zugriffskontrolllisten geschützt ist:drwx------ 2 robert robert 512 Dec 27 11:54 private
drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1
drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2
drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3
drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_htmlDie Verzeichnisse directory1,
directory2 und directory3
sind durch Zugriffskontrolllisten geschützt, das Verzeichnis
public_html nicht.Zugriffskontrolllisten benutzenDas Werkzeug &man.getfacl.1; zeigt Zugriffskontrolllisten
an. Das folgende Kommando zeigt die ACLs
auf der Datei test:&prompt.user; getfacl test
#file:test
#owner:1001
#group:1001
user::rw-
group::r--
other::r--Das Werkzeug &man.setfacl.1; ändert oder entfernt
ACLs auf Dateien. Zum Beispiel:&prompt.user; setfacl -k testDie Option entfernt alle
ACLs einer Datei oder eines Dateisystems.
Besser wäre es, die Option
zu verwenden, da sie die erforderlichen Felder
beibehält.&prompt.user; setfacl -m u:trhodes:rwx,g:web:r--,o::--- testMit dem vorstehenden Kommando werden die eben
entfernten Zugriffskontrolllisten wiederhergestellt.
Der Befehl gibt die Fehlermeldung
Invalid argument aus,
wenn Sie nicht existierende Benutzer oder Gruppen
als Parameter angeben.TomRhodesBeigetragen von PortauditSicherheitsprobleme in Software Dritter überwachenIn den letzten Jahren wurden zahlreiche Verbesserungen in
der Einschätzung und dem Umgang mit Sicherheitsproblemen
erzielt. Die Gefahr von Einbrüchen in ein System wird
aber immer größer, da Softwarepakete von Dritten
auf nahezu jedem Betriebssystem installiert und konfiguriert
werden.Die Einschätzung der Verletzlichkeit eines Systems ist
ein Schlüsselfaktor für dessen Sicherheit. &os;
veröffentlicht zwar Sicherheitshinweise
(security advisories) für
das Basissystem, das Projekt ist allerdings nicht dazu in der
Lage, dies auch für die zahlreichen Softwarepakete von
Dritten zu tun. Dennoch gibt es einen Weg, auch diese
Programmpakete zu überwachen. Das in der Ports-Sammlung
enthaltene Programm Portaudit wurde
gezielt dafür entwickelt.Der Port security/portaudit
fragt dazu eine Datenbank, die vom &os; Security Team sowie
den Ports-Entwicklern aktualisiert und gewartet wird, auf
bekannte Sicherheitsprobleme ab.Bevor Sie Portaudit verwenden
können, müssen Sie es über die Ports-Sammlung
installieren:&prompt.root; cd /usr/ports/security/portaudit && make install cleanWährend der Installation werden die
Konfigurationsdateien für &man.periodic.8; aktualisiert, was
es Portaudit erlaubt, seine Ausgabe
in den täglichen Sicherheitsbericht einzufügen.
Stellen Sie auf jeden Fall sicher, dass diese (an das
E-Mail-Konto von root gesendeten)
Sicherheitsberichte auch gelesen werden. An dieser Stelle
ist keine weitere Konfiguration nötig.Nach der Installation kann ein Administrator die unter
/var/db/portaudit lokal
gespeicherte Datenbank aktualisieren und sich danach durch
folgenden Befehl über mögliche Sicherheitslücken
der von ihm installierten Softwarepakete informieren:&prompt.root; portaudit -FdaDie Datenbank wird automatisch aktualisiert, wenn
&man.periodic.8; ausgeführt wird. Der eben genannte
Befehl ist daher optional, er wird aber für das
folgende Beispiel benötigt.Nach erfolgter Installation der Datenbank kann ein
Administrator über die Ports-Sammlung installierte
Softwarepakete Dritter jederzeit überprüfen. Dazu
muss er lediglich folgenden Befehl eingeben:&prompt.root; portaudit -aExistiert in Ihren installierten Softwarepaketen eine
Sicherheitslücke, wird Portaudit
eine Ausgabe ähnlich der folgenden produzieren:Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-0001020eed82.html>
1 problem(s) in your installed packages found.
You are advised to update or deinstall the affected package(s) immediately.Wenn Sie die angegebene URL über einen
Internetbrowser aufrufen, erhalten Sie weitere Informationen
über die bestehende Sicherheitslücke, wie die betroffenen
Versionen, die Version des &os;-Ports sowie Hinweise auf weitere
Seiten, die ebenfalls Sicherheitshinweise zu diesem Problem
bieten.Portaudit ist ein mächtiges
Werkzeug und insbesondere in Zusammenarbeit mit dem
Port Portupgrade äußerst
hilfreich.TomRhodesBeigesteuert von Sicherheitshinweise&os; SicherheitshinweiseWie für andere hochwertige Betriebssysteme auch
werden für &os; Sicherheitshinweise herausgegeben.
Die Hinweise werden gewöhnlich auf den Sicherheits-Mailinglisten
und in den Errata veröffentlicht, nachdem das
Sicherheitsproblem behoben ist. Dieser Abschnitt beschreibt
den Umgang mit den Sicherheitshinweisen.Wie sieht ein Sicherheitshinweis aus?Der nachstehende Sicherheitshinweis stammt von
der Mailingliste &a.security-notifications.name;:=============================================================================
&os;-SA-XX:XX.UTIL Security Advisory
The &os; Project
Topic: denial of service due to some problem
Category: core
Module: sys
Announced: 2003-09-23
Credits: Person@EMAIL-ADDRESS
Affects: All releases of &os;
&os; 4-STABLE prior to the correction date
Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)
2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)
2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)
2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)
2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)
2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)
2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)
2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)
2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)
CVE Name: CVE-XXXX-XXXX
For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
http://www.FreeBSD.org/security/.
I. Background
II. Problem Description
III. Impact
IV. Workaround
V. Solution
VI. Correction details
VII. ReferencesDas Feld Topic enthält eine
Beschreibung des Sicherheitsproblems und benennt das
betroffene Programm.Das Feld Category beschreibt den
betroffenen Systemteil. Mögliche Werte für dieses
Feld sind core, contrib
oder ports. Die Kategorie
core gilt für Kernkomponenten
des &os;-Betriebssystems, die Kategorie
contrib beschreibt zum Basissystem
gehörende Software Dritter beispielsweise
sendmail. Die Kategorie
ports beschreibt Software, die
Teil der Ports-Sammlung ist.Das Feld Module beschreibt die
betroffene Komponente. Im Beispiel ist
sys angegeben, das heißt
dieses Problem betrifft eine Komponente, die vom
Kernel benutzt wird.Das Feld Announced gibt den
Zeitpunkt der Bekanntgabe des Sicherheitshinweises
an. Damit existiert das Sicherheitsproblem,
ist vom Sicherheits-Team bestätigt worden
und eine entsprechende Korrektur wurde in das
Quellcode-Repository von &os; gestellt.Das Feld Credits gibt die Person
oder Organisation an, die das Sicherheitsproblem
bemerkte und gemeldet hat.Welche &os;-Releases betroffen sind, ist im Feld
Affects angegeben. Die Version einer
Datei, die zum Kernel gehört, können Sie
schnell mit ident ermitteln. Bei Ports
ist die Versionsnummer angegeben, die Sie im Verzeichnis
/var/db/pkg finden.
Wenn Sie Ihr System nicht täglich aktualisieren,
ist Ihr System wahrscheinlich betroffen.Wann das Problem in welchem Release behoben wurde,
steht im Feld Corrected.Reserviert für Informationen, über die
in der Common Vulnerabilities Database
nach Sicherheitslücken gesucht werden kann.Im Feld Background wird
das betroffene Werkzeug beschrieben. Meist finden Sie
hier warum das Werkzeug Bestandteil von &os; ist,
wofür es benutzt wird und eine kurze
Darstellung der Herkunft des Werkzeugs.Im Feld Problem Description befindet
sich eine genaue Darstellung des Sicherheitsproblems.
Hier wird fehlerhafter Code beschrieben oder geschildert,
wie ein Werkzeug ausgenutzt wird.Das Feld Impact beschreibt die
Auswirkungen des Sicherheitsproblems auf ein System,
beispielsweise erweiterte Rechte oder gar
Superuser-Rechte für normale Benutzer.Im Feld Workaround wird
eine Umgehung des Sicherheitsproblems beschrieben.
Die Umgehung ist für Administratoren gedacht,
die ihr System aus Zeitnot, Netzwerk-technischen oder
anderen Gründen nicht aktualisieren können.
Nehmen Sie Sicherheitsprobleme ernst: Auf einem
betroffenen System sollte das Problem entweder behoben
oder, wie hier beschrieben, umgangen werden.Im Feld Solution enthält eine
getestete Schritt-für-Schritt Anleitung, die das
Sicherheitsproblem behebt.Das Feld Correction Details
enthält die CVS-Tags der betroffenen Dateien
zusammen mit zugehörigen Revisionsnummern.Im Feld References finden sich
Verweise auf weitere Informationsquellen. Dies können
URLs zu Webseiten, Bücher, Mailinglisten und Newsgroups
sein.TomRhodesBeigetragen von Prozess-ÜberwachungProzess-ÜberwachungProzess-Überwachung
(Process accounting) ist ein
Sicherheitsverfahren, bei dem ein Administrator verfolgt,
welche Systemressourcen verwendet werden und wie sich diese
auf die einzelnen Anwender verteilen. Dadurch kann das
System überwacht werden und es ist sogar möglich,
zu kontrollieren, welche Befehle ein Anwender eingibt.Diese Fähigkeiten haben sowohl Vor- als auch Nachteile.
Positiv ist, dass man ein Einbruchsversuch bis an den Anfang
zurückverfolgen kann. Von Nachteil ist allerdings,
dass durch diesen Prozess Unmengen an Protokolldateien erzeugt
werden, die auch dementsprechenden Plattenplatz benötigen.
Dieser Abschnitt beschreibt die Grundlagen der
Prozess-Überwachung.Die Prozess-Überwachung aktivieren und
konfigurierenBevor Sie die Prozess-Überwachung verwenden können,
müssen Sie diese aktivieren. Dazu führen Sie als
root die folgenden Befehle aus:&prompt.root; touch /var/account/acct
&prompt.root; accton /var/account/acct
&prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.confEinmal aktiviert, wird sofort mit der Überwachung von
CPU-Statistiken, Befehlen und anderen
Vorgängen begonnen. Protokolldateien werden in einem
nur von Maschinen lesbaren Format gespeichert, daher müssen
Sie diese über &man.sa.8; aufrufen. Geben Sie keine
Optionen an, gibt sa Informationen wie
die Anzahl der Aufrufe pro Anwender, die abgelaufene Zeit in
Minuten, die gesamte CPU- und Anwenderzeit
in Minuten, die durchschnittliche Anzahl der Ein- und
Ausgabeoperationen und viel andere mehr aus.Um Informationen über ausgeführte Befehle zu
erhalten, verwenden Sie &man.lastcomm.1;. So können Sie
etwa ermittlen, welche Befehle von wem auf welchem &man.ttys.5;
ausgeführt wurden:&prompt.root; lastcomm ls
trhodes ttyp1Das Ergebnis sind alle bekannten Einsätze von
ls durch trhodes
auf dem Terminal ttyp1.Zahlreiche weitere nützliche Optionen finden Sie in den
Manualpages zu &man.lastcomm.1;, &man.acct.5; sowie
&man.sa.8;.