Index: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml (revision 48774) +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml (revision 48775) @@ -1,3760 +1,3762 @@ Sicherheit Tom Rhodes Neu verfasst von MartinHeinenÜbersetzt von Sicherheit Übersicht Sicherheit, ob nun physisch oder virtuell, ist ein so breit gefächertes Thema, dass sich eine ganze Industrie darum gebildet hat. Es wurden bereits hunderte Verfahren zur Sicherung von Systemen und Netzwerken verfasst, und als Benutzer von &os; ist es unumgänglich zu verstehen, wie Sie sich gegen Angreifer und Eindringlinge schützen können. In diesem Kapitel werden einige Grundlagen und Techniken diskutiert. Ein &os;-System implementiert Sicherheit in mehreren Schichten, und viele weitere Programme von Drittanbietern können zur Verbesserung der Sicherheit beitragen. Nachdem Sie dieses Kapitel gelesen haben, werden Sie: Grundlegende auf &os; bezogene Sicherheitsaspekte kennen. Die verschiedenen Verschlüsselungsmechanismen von &os; kennen. Wissen, wie Sie ein Einmalpasswörter zur Authentifizierung verwenden. TCP-Wrapper für &man.inetd.8; einrichten können. Wissen, wie Sie Kerberos unter &os; einrichten. Wissen, wie Sie IPsec konfigurieren und ein VPN einrichten. Wissen, wie Sie OpenSSH unter &os; konfigurieren und benutzen. Wissen, wie Sie ACLs für Dateisysteme benutzen. Portaudit anwenden können, um Softwarepakete aus der Ports-Sammlung 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. Wissen, wie Sie die Ressourcen-Datenbank benutzt, um die Ressourcen für Benutzer zu steuern. Bevor Sie dieses Kapitel lesen, sollten Sie Grundlegende Konzepte von &os; und dem Internet verstehen. Dieses Buch behandelt weitere Sicherheitsthemen. Beispielsweise werden verbindliche Zugriffskontrollen im und Firewalls im besprochen. Einführung Sicherheit ist die Verantwortung eines jeden Einzelnen. Ein schwacher Einstiegspunkt in einem System kann einem Eindringling Zugriff auf wichtige Informationen verschaffen, was sich verheerend auf das gesamte Netzwerk auswirken kann. Eines der Grundprinzipien der Informationssicherheit sind die Vertraulichkeit, Integrität und Verfügbarkeit von Informationssystemen. Diese Grundprinzipien sind ein fundamentales Konzept der Computer-Sicherheit, da Kunden und Benutzer erwarten, dass ihre Daten geschützt sind. Zum Beispiel erwartet ein Kunde, dass seine Kreditkarteninformationen sicher gespeichert werden (Vertraulichkeit), dass seine Aufträge nicht hinter den Kulissen geändert werden (Integrität) und dass er zu jeder Zeit Zugang zu seinen Informationen hat (Verfügbarkeit). Um diese Grundprinzipien zu implementieren, wenden Sicherheitsexperten das sogenannte Defense-in-Depth-Konzept an. Die Idee dahinter ist, mehrere Sicherheitsschichten zu addieren, so dass nicht die gesamte Systemsicherheit gefährdet ist, wenn eine einzelne Sicherheitsschicht kompromittiert wird. Beispielsweise ist es nicht ausreichend, ein Netzwerk oder ein System nur mit einer Firewall zu sichern. Der Systemadministrator muss auch Benutzerkonten überwachen, die Integrität von Binärdateien prüfen und sicherstellen, dass keine bösartigen Programme installiert sind. Um eine effektive Sicherheitsstrategie zu implementieren, muss man Bedrohungen verstehen und wissen, wie man sich dagegen verteidigen kann. Was ist eine Bedrohung, wenn es um Computer-Sicherheit geht? Bedrohungen beschränken sich nicht nur auf entfernte Angreifer, die sich unerlaubten Zugriff auf ein System verschaffen wollen. Zu den Bedrohungen zählen auch Mitarbeiter, bösartige Software, nicht autorisierte Netzwerkgeräte, Naturkatastrophen, Sicherheitslücken und sogar konkurrierende Unternehmen. Der Zugriff auf Netzwerke und Systeme erfolgt ohne Erlaubnis, manchmal durch Zufall, oder von entfernten Angreifern, und in einigen Fällen durch Industriespionage oder ehemalige Mitarbeiter. Als Anwender müssen Sie vorbereitet sein und auch zugeben, wenn ein Fehler zu einer Sicherheitsverletzung geführt hat. Melden Sie Probleme umgehend dem verantwortlichen Sicherheitspersonal. Als Administrator ist es wichtig, Bedrohungen zu kennen und darauf vorbereitet zu sein, mögliche Schäden zu mildern. Wenn Sicherheit auf Systeme angewendet wird, empfiehlt es sich mit der Sicherung der Benutzerkonten zu beginnen und dann die Netzwerkschicht zu sichern. Dabei ist zu beachten, dass die Sicherheitsrichtlinien des Systems und des Unternehmens eingehalten werden. Viele Unternehmen haben bereits eine Sicherheitsrichtlinie, welche die Konfiguration von technischen Geräten abdeckt. Die Richtlinie sollte die Konfiguration von Arbeitsplatzrechnern, Desktops, mobilen Geräten, Mobiltelefonen, Produktions- und Entwicklungsservern umfassen. In einigen Fällen ist bereits eine Standardvorgehensweise vorhanden. Fragen Sie im Zweifelsfall das Sicherheitspersonal. Der übrige Teil dieser Einführung beschreibt, wie einige dieser grundlegenden Sicherheitskonfigurationen auf einem &os;-System durchgeführt werden. Der Rest dieses Kapitels beschreibt einige spezifische Werkzeuge, die verwendet werden können, um eine Sicherheitsrichtlinie auf einem &os;-System zu implementieren. Anmeldungen am System verhindern Ein guter Ausgangspunkt für die Absicherung des Systems ist die Prüfung der Benutzerkonten. Stellen Sie sicher, dass root ein starkes Passwort besitzt und dass dieses Passwort nicht weitergegeben wird. Deaktivieren Sie alle Konten, die keinen Zugang zum System benötigen. Es existieren zwei Methoden, um die Anmeldung über ein Benutzerkonto zu verweigern. Die erste Methode ist, das Konto zu sperren. Dieses Beispiel sperrt das Benutzerkonto toor: &prompt.root; pw lock toor Bei der zweiten Methode wird der Anmeldevorgang verhindert, indem die Shell auf /sbin/nologin gesetzt wird. Nur der Superuser kann die Shell für andere Benutzer ändern: &prompt.root; chsh -s /usr/sbin/nologin toor Die Shell /usr/sbin/nologin verhindert, dass dem Benutzer bei der Anmeldung am System eine Shell zugeordnet wird. Gemeinsame Nutzung von Benutzerkonten In manchen Fällen wird die Systemadministration auf mehrere Benutzer aufgeteilt. &os; bietet zwei Methoden, um solche Situationen zu handhaben. Bei der ersten und nicht empfohlenen Methode wird ein gemeinsames root Passwort der Mitglieder der Gruppe wheel verwendet. Hier gibt der Benutzer su und das Passwort für wheel ein, wenn er die Rechte des Superusers benötigt. Der Benutzer sollte dann nach der Beendigung der administrativen Aufgaben exit eingeben. Um einen Benutzer zu dieser Gruppe hinzuzufügen, bearbeiten Sie /etc/group und fügen Sie den Benutzer an das Ende des Eintrags wheel hinzu. Die Benutzer müssen durch Komma und ohne Leerzeichen getrennt werden. Die zweite und empfohlene Methode ein Benutzerkonto zu teilen wird über den Port oder das Paket security/sudo realisiert. Dieses Programm bietet zusätzliche Prüfungen, bessere Benutzerkontrolle und es kann auch konfiguriert werden, einzelnen Benutzern Zugriff auf bestimme, privilegierte Befehle zu gestatten. Benutzen Sie nach der Installation visudo, um /usr/local/etc/sudoers zu bearbeiten. Dieses Beispiel erstellt eine neue Gruppe webadmin und fügt das Benutzerkonto trhodes dieser Gruppe hinzu. Anschließend wird die Gruppe so konfiguriert, dass es Gruppenmitgliedern gestattet wird apache24 neu zu starten: &prompt.root; pw groupadd webadmin -M trhodes -g 6000 &prompt.root; visudo %webadmin ALL=(ALL) /usr/sbin/service apache24 * Passwort-Hashes Passwörter sind ein notwendiges Übel. Wenn sie verwendet werden müssen, sollten sie sehr komplex sein und dazu sollte eine leistungsfähige Hash-Funktion gewählt werden, um die Version des Passworts zu verschlüsseln, die in der Passwortdatenbank gespeichert wird. &os; unterstützt die Hash-Funktionen DES, MD5, SHA256, SHA512, sowie Blowfish Hash-Funktionen in seiner crypt()-Bibliothek. Das in der Voreinstellung verwendete SHA512 sollte nicht durch eine weniger sichere Hash-Funktion getauscht werden. Es kann jedoch durch den besseren Blowfish-Algorithmus ersetzt werden. Blowfish ist nicht Bestandteil von AES und ist nicht kompatibel mit allen Federal Information Processing Standards (FIPS). Die Verwendung wird in einigen Umgebungen vielleicht nicht gestattet. Um zu bestimmen, welche Hash-Funktion das Passwort eines Benutzers verschlüsselt, kann der Superuser den Hash für den Benutzer in der Passwortdatenbank von &os; nachsehen. Jeder Hash beginnt mit einem Zeichen, mit dem die verwendete Hash-Funktion identifiziert werden kann. Bei DES gibt es allerdings kein führendes Zeichen. MD5 benutzt das Zeichen $. SHA256 und SHA512 verwenden das Zeichen $6$. Blowfish benutzt das Zeichen $2a$. In diesem Beispiel wird das Passwort von dru mit dem Hash-Algorithmus SHA512 verschlüsselt, da der Hash mit $6$ beginnt. Beachten Sie, dass der verschlüsselte Hash und nicht das Passwort selbst, in der Passwortdatenbank gespeichert wird: &prompt.root; grep dru /etc/master.passwd dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh Der Hash-Mechanismus wird in der Login-Klasse des Benutzers festgelegt. In diesem Beispiel wird die voreingestellte Login-Klasse für den Benutzer verwendet. Der Hash-Algorithmus wird mit dieser Zeile in /etc/login.conf gesetzt: :passwd_format=sha512:\ Um den Algorithmus auf Blowfish zu ändern, passen Sie die Zeile wie folgt an: :passwd_format=blf:\ Führen Sie anschließend cap_mkdb /etc/login.conf aus, wie in beschrieben. Beachten Sie, dass vorhandene Passwort-Hashes durch diese Änderung nicht beeinträchtigt werden. Das bedeutet, dass alle Passwörter neu gehasht werden sollten, indem die Benutzer mit passwd ihr Passwort ändern. Für die Anmeldung auf entfernten Rechnern sollte eine Zwei-Faktor-Authentifizierung verwendet werden. Ein Beispiel für eine Zwei-Faktor-Authentifizierung ist etwas, was Sie besitzen (bspw. einen Schlüssel) und etwas, was Sie wissen (bspw. das Passwort für diesen Schlüssel). Da OpenSSH Teil des &os;-Basissystems ist, sollten alle Anmeldungen über das Netzwerk über eine verschlüsselte Verbindung mit einer schlüsselbasierten Authentifizierung stattfinden. Passwörter sollten hier nicht verwendet werden. Weitere Informationen finden Sie in . Kerberos-Benutzer müssen eventuell zusätzliche Änderungen vornehmen, um OpenSSH in Ihrem Netzwerk zu implementieren. Diese Änderungen sind in beschrieben. Durchsetzung einer Passwort-Richtlinie Die Durchsetzung einer starken Passwort-Richtlinie für lokale Benutzerkonten ist ein wesentlicher Aspekt der Systemsicherheit. In &os; kann die Länge, Stärke und Komplexität des Passworts mit den Pluggable Authentication Modules (PAM) implementiert werden. In diesem Abschnitt wird gezeigt, wie Sie die minimale und maximale Passwortlänge und die Durchsetzung von gemischten Zeichen mit dem Modul pam_passwdqc.so konfigurieren. Dieses Modul wird aufgerufen, wenn ein Benutzer sein Passwort ändert. Um dieses Modul zu konfigurieren, müssen Sie als Superuser die Zeile mit pam_passwdqc.so in /etc/pam.d/passwd auskommentieren. Anschließend bearbeiten Sie die Zeile, so dass sie den vorliegenden Passwort-Richtlinien entspricht: password requisite pam_passwdqc.so min=disabled,disabled,disabled,12,10 similar=deny retry=3 enforce=users Dieses Beispiel legt gleich mehrere Anforderungen für neue Passwörter fest. Die Einstellung min kontrolliert die Passwortlänge. Es verfügt über fünf Werte, weil dieses Modul fünf verschiedene Arten von Passwörtern definiert, basierend auf der Komplexität. Die Komplexität wird durch die Art von Zeichen definiert, die in einem Passwort vorhanden sind, wie zum Beispiel Buchstaben, Zahlen und Sonderzeichen. Die verschiedenen Arten von Passwörtern werden in &man.pam.passwdqc.8; beschrieben. In diesem Beispiel sind die ersten drei Arten von Passwörtern deaktiviert, was bedeutet, dass Passwörter, die dieser Komplexitätsstufe entsprechen, nicht akzeptiert werden, unabhängig von der Länge des Passworts. Die 12 legt eine Richtlinie von mindestens zwölf Zeichen fest, wenn das Passwort auch drei Arten von Komplexität aufweist. Die 10 legt eine Richtlinie fest, die auch Passwörter mit mindestens zehn Zeichen zulassen, wenn das Passwort Zeichen mit vier Arten von Komplexität aufweist. Die Einstellung similar verbietet Passwörter, die dem vorherigen Passwort des Benutzers ähnlich sind. Die Einstellung retry bietet dem Benutzer drei Möglichkeiten, ein neues Passwort einzugeben. Sobald diese Datei gespeichert wird, sehen Benutzer bei der Änderung ihres Passworts die folgende Meldung: &prompt.user; passwd Changing local password for trhodes Old Password: You can now choose the new password. A valid password should be a mix of upper and lower case letters, digits and other characters. You can use a 12 character long password with characters from at least 3 of these 4 classes, or a 10 character long password containing characters from all the classes. Characters that form a common pattern are discarded by the check. Alternatively, if noone else can see your terminal now, you can pick this as your password: "trait-useful&knob". Enter new password: Wenn ein Passwort nicht den Richtlinien entspricht, wird es mit einer Warnung abgelehnt und der Benutzer bekommt die Möglichkeit, es erneut zu versuchen, bis die Anzahl an Wiederholungen erreicht ist. Die meisten Passwort-Richtlinien erzwingen, dass Passwörter nach einer bestimmten Anzahl von Tagen ablaufen. Um dieses Limit in &os; zu konfigurieren, setzen Sie es für die Login-Klasse des Benutzers in /etc/login.conf. Die voreingestellte Login-Klasse enthält dazu ein Beispiel: # :passwordtime=90d:\ Um für diese Login-Klasse das Passwort nach 90 Tagen ablaufen zu lassen, entfernen Sie das Kommentarzeichen (#), speichern Sie die Änderungen und führen Sie cap_mkdb /etc/login.conf aus. Um das Passwort für einzelne Benutzer ablaufen zu lassen, geben Sie pw ein Ablaufdatum oder die Anzahl von Tagen, zusammen mit dem Benutzer an: &prompt.root; pw usermod -p 30-apr-2015 -n trhodes Wie zu sehen ist, wird das Ablaufdatum in der Form von Tag, Monat und Jahr angegeben. Weitere Informationen finden Sie in &man.pw.8;. Erkennen von Rootkits Ein Rootkit ist eine nicht autorisierte Software die versucht, Root-Zugriff auf ein System zu erlangen. Einmal installiert, wird diese bösartige Software normalerweise eine Hintertür für den Angreifer installieren. Realistisch betrachtet sollte ein durch ein Rootkit kompromittiertes System nach der Untersuchung von Grund auf neu installiert werden. Es besteht jedoch die enorme Gefahr, dass sogar das Sicherheitspersonal oder Systemingenieure etwas übersehen, was ein Angreifer dort platziert hat. Wird ein Rootkit erkannt, ist dies bereits ein Zeichen dafür, dass das System an einem bestimmten Zeitpunkt kompromittiert wurde. Meist neigen diese Art von Anwendungen dazu, sehr gut versteckt zu sein. Dieser Abschnitt zeigt ein Werkzeug, mit dem Rootkits erkannt werden können: security/rkhunter. Nach der Installation dieses Ports oder Pakets kann das System mit dem folgenden Kommando überprüft werden. Das Programm generiert eine ganze Menge Informationen und Sie werden diverse Male ENTER drücken müssen: &prompt.root; rkhunter -c Nachdem der Prozess abgeschlossen ist, wird eine Statusmeldung auf dem Bildschirm ausgegeben. Die Meldung enthält die Anzahl der überprüften Dateien, verdächtige Dateien, mögliche Rootkits und weitere Informationen. Während der Überprüfung erscheinen allgemeine Sicherheitswarnungen, zum Beispiel über versteckte Dateien, die Auswahl von OpenSSH-Protokollen und bekannte, anfällige Versionen installierter Anwendungen. Diese können nun direkt, oder nach detaillierter Analyse untersucht werden. Jeder Administrator sollte wissen, was auf den Systemen läuft, für die er verantwortlich ist. Werkzeuge von Drittanbietern, wie rkhunter oder sysutils/lsof, sowie native Befehle wie netstat oder ps, können eine große Menge an Informationen über das System anzeigen. Machen Sie sich Notizen darüber, was normal ist, und fragen Sie nach, wenn Ihnen etwas suspekt erscheint. Eine Beeinträchtigung zu verhindern ist ideal, aber die Erkennung einer Beeinträchtigung ist ein Muss. Überprüfung von Binärdateien Die Überprüfung von System- und Binärdateien ist wichtig, da sie Systemadministratoren Informationen über Systemänderungen zur Verfügung stellt. Eine Software, die das System auf Änderungen überwacht wird Intrustion Detection System (IDS) genannt. &os; bietet native Unterstützung für ein einfaches IDS-System. Obwohl die täglichen Sicherheits-E-Mails den Administrator über Änderungen in Kenntnis setzen, werden diese Informationen lokal gespeichert und es besteht die Möglichkeit, dass ein Angreifer diese Informationen manipulieren kann, um Änderungen am System zu verbergen. Daher ist es empfehlenswert, einen eigenen Satz an Signaturen zu erstellen und diese dann in einem schreibgeschützten Verzeichnis, oder vorzugsweise auf einem USB-Stick oder auf einem entfernten Server zu speichern. Das im Basissystem enthaltene Werkzeug mtree kann verwendet werden, um eine Spezifikation des Inhalts eines Verzeichnisses zu erzeugen. Hierbei wird ein Startwert (Seed) oder eine numerische Konstante benutzt, um die Spezifikation zu erstellen und um sicherzustellen, dass sich die Spezifikation nicht geändert hat. Dadurch kann festgestellt werden, ob eine Datei oder eine Binärdatei verändert wurde. Da ein Angreifer den Seed nicht kennt, ist es ihm fast unmöglich die Prüfsummen von Dateien zu manipulieren. Das folgende Beispiel generiert einen Satz mit SHA256-Prüfsummen für jede Binärdatei unterhalb von /bin und speichert diese Werte in einer versteckten Datei im Heimatverzeichnis von root unter dem Namen /root/.bin_chksum_mtree: &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree &prompt.root; mtree: /bin checksum: 3427012225 3483151339707503 stellt den Seed dar. Diesen Wert sollten Sie sich merken, aber nicht mit anderen Personen teilen. Die Ausgabe von /root/.bin_chksum_mtree sollte ähnlich der folgenden sein: # user: root # machine: dreadnaught # tree: /bin # date: Mon Feb 3 10:19:53 2014 # . /set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none . type=dir mode=0755 nlink=2 size=1024 \ time=1380277977.000000000 \133 nlink=2 size=1170 time=1380277977.000000000 \ cksum=484492447 \ sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a cat size=12096 time=1380277975.000000000 cksum=3909216944 \ sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 chio size=18520 time=1380277975.000000000 cksum=2208263309 \ sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 Der Report enthält den Rechnernamen, das Datum und die Uhrzeit der Spezifikation, sowie den Namen des Benutzers, der die Spezifikation erstellt hat. Für jede Binärdatei im Verzeichnis gibt es eine Prüfsumme, Größe, Uhrzeit und einen SHA256-Hashwert. Um sicherzustellen, dass die binären Signaturen nicht verändert wurden, vergleichen Sie den Inhalt des aktuellen Verzeichnisses mit der zuvor erstellen Spezifikation. Speichern Sie die Ergebnisse in einer Datei. Dieses Kommando benötigt den Seed, der verwendet wurde um die ursprüngliche Spezifikation zu erstellen: &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output &prompt.root; mtree: /bin checksum: 3427012225 Dies sollte die gleiche Prüfsumme für /bin produzieren, wie die ursprüngliche Spezifikation. Wenn keine Änderungen an den Binärdateien in diesem Verzeichnis aufgetreten sind, wird die Ausgabedatei /root/.bin_chksum_output leer sein. Um eine Änderung zu simulieren, ändern Sie mit touch das Datum von /bin/cat und führen Sie die Verifikation erneut aus: &prompt.root; touch /bin/cat &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output &prompt.root; more /root/.bin_chksum_output cat changed modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 Es wird empfohlen, Spezifikationen für Verzeichnisse zu erstellen, welche Binärdateien, Konfigurationsdateien und sensible Daten enthalten. In der Regel werden Spezifikationen für /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /etc und /usr/local/etc erstellt. Mit security/aide steht ein fortgeschrittenes IDS-System zur Verfügung, aber in den meisten Fällen bietet mtree die Funktionalität, die von Administratoren benötigt wird. Es ist jedoch sehr wichtig den Seed und die Prüfsummen in der Ausgabe vor böswilligen Benutzern verborgen zu halten. Weitere Informationen zu mtree finden Sie in &man.mtree.8;. System-Tuning für Sicherheit Unter &os; können viele Systemfunktionen mit sysctl konfiguriert werden. Dieser Abschnitt behandelt ein paar Sicherheitsmerkmale mit denen Denial of Service (DoS) verhindert werden sollen. Weitere Informationen über die Benutzung von sysctl und wie Werte vorübergehend oder auch permanent geändert werden können, finden Sie in . Jedes Mal wenn eine Einstellung mit sysctl geändert wird, vergrößert sich die Wahrscheinlichkeit eines unerwünschten Schadens, was die Verfügbarkeit des Systems beeinflusst. Alle Änderungen sollten überwacht und wenn möglich, vorher auf einem Testsystem ausprobiert werden, bevor sie auf einem Produktivsystem verwendet werden. In der Voreinstellung startet &os; in der Sicherheitsstufe (Securelevel) -1. Dieser Modus wird unsicherer Modus genannt, da die unveränderlichen Datei-Flags ausgeschaltet werden können und dadurch von allen Geräten gelesen und geschrieben werden kann. Solange die Einstellung nicht über sysctl oder in den Startskripten geändert wird, verbleibt die Sicherheitsstufe auf -1. Die Sicherheitsstufe kann während des Systemstarts erhöht werden. Dazu muss in /etc/rc.conf kern_securelevel_enable auf YES und kern_securelevel auf den gewünschten Wert gesetzt werden. Weitere Informationen zu diesen Einstellungen und den verfügbaren Sicherheitsstufen finden Sie in &man.security.7; und &man.init.8;. Das Erhöhen der Sicherheitsstufe kann zu Problemen mit &xorg; führen. Die Einstellungen net.inet.tcp.blackhole und net.inet.udp.blackhole können benutzt werden, um eingehende SYN-Pakete an geschlossenen Ports zu blockieren, ohne ein RST-Paket als Antwort zu senden. Standardmäßig wird jedoch ein RST-Paket gesendet, um zu zeigen, dass der Port geschlossen ist. Das ändern dieser Voreinstellung bietet einen gewissen Schutz gegen Portscans. Diese Portscans versuchen herauszufinden, welche Anwendungen auf einem System ausgeführt werden. Setzen Sie net.inet.tcp.blackhole auf 2 und net.inet.udp.blackhole auf 1. Weitere Informationen zu diesen Einstellungen finden Sie in &man.blackhole.4;. Die Einstellung net.inet.icmp.drop_redirect hilft dabei, sogenannte Redirect-Angriffe zu verhindern. Ein Redirect-Angriff ist eine Art von DoS, die massenhaft ICMP-Pakete Typ 5 versendet. Da solche Pakete nicht benötigt werden, setzen Sie net.inet.icmp.drop_redirect auf 1 und net.inet.ip.redirect auf 0. Source Routing zur Erfassung und zum Zugriff auf nicht-routbare Adressen im internen Netzwerk. Dies sollte deaktiviert werden, da nicht-routbare Adressen in der Regel nicht absichtlich geroutet werden. Um diese Funktion zu deaktivieren, setzen Sie net.inet.ip.sourceroute und net.inet.accept_sourceroute auf 0. Wenn ein Netzwerkgerät Nachrichten an alle Rechner in einem Subnetz senden muss, wird eine ICMP-Echo-Request Nachricht an die Broadcast-Adresse gesendet. Allerdings gibt es keinen guten Grund für externe Rechner, solche Nachrichten zu verschicken. Um alle externen Broadcast-Anfragen abzulehnen, setzen Sie net.inet.icmp.bmcastecho auf 0. Einige zusätzliche Einstellungen sind in &man.security.7; dokumentiert. Einmalpasswörter Einmalpasswörter Sicherheit Einmalpasswörter In der Voreinstellung unterstützt &os; One-time Passwords in Everything - (OPIE), das in der Voreinstellung - MD5-Hash-Funktionen einsetzt. + (OPIE). OPIE wurde + konzipiert um Replay-Angriffe zu verhindern, bei dem ein + Angreifer das Passwort eines Benutzers ausspäht und es + benutzt, um Zugriff auf ein System zu erlangen. Da ein Passwort + unter OPIE nur einmal benutzt wird, ist ein + ausgespähtes Passwort für einen Angreifer nur von geringem + Nutzen. OPIE verwendet eine sichere + Hash-Funktion und ein Challenge/Response-System, um Passwörter + zu verwalten. Die &os;-Implementation verwendet in der + Voreinstellung die MD5-Hash-Funktion. - Es gibt drei verschiedene Arten von Passwörtern. Das erste - ist das normales &unix;- oder Kerberos-Passwort. Das zweite ist - das Einmalpasswort, das von opiekey generiert - und von opiepasswd und dem Anmeldeprompt - akzeptiert wird. Das dritte Passwort ist das - geheime Passwort, das mit - opiekey (manchmal auch mit - opiepasswd) zum Erstellen der - Einmalpasswörter verwendet wird. + OPIE verwendet drei verschiedene Arten + von Passwörtern. Das erste ist das normale &unix;- oder + Kerberos-Passwort. Das zweite ist das Einmalpasswort, das von + opiekey generiert wird. Das dritte Passwort + ist das geheime Passwort, das zum Erstellen der + Einmalpasswörter verwendet wird. Das geheime Passwort steht in + keiner Beziehung zum &unix;-Passwort und beide Passwörter + sollten unterschiedlich sein. - Das geheime Passwort steht in keiner Beziehung zum - &unix;-Passwort. Beide können gleich sein, obwohl das nicht - empfohlen wird. Die geheimen Passwörter von - OPIE sind nicht auf eine Länge von 8 Zeichen, - wie alte &unix; Passwörter - Unter &os; darf das System-Passwort maximal - 128 Zeichen lang sein., beschränkt. - Gebräuchlich sind Passwörter, die sich aus sechs bis sieben - Wörtern zusammensetzen. Das OPIE-System - arbeitet vollständig unabhängig von den auf &unix;-Systemen - verwendeten Passwort-Mechanismen. - - Neben dem Passwort gibt es noch zwei Werte, die für + Es gibt noch zwei weitere 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 das Einmalpasswort + 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 das Einmalpasswort ergeben. Das Authentifizierungssystem (meistens PAM) merkt sich das zuletzt benutzte Einmalpasswort und der Benutzer ist authentifiziert, 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 + Iterationszähler den Wert 1 erreicht, muss OPIE neu initialisiert werden. Es gibt ein paar Programme, die in diesen Prozess einbezogen - werden. &man.opiekey.1; akzeptiert einen Iterationszähler, - einen Initialwert und ein geheimes Passwort. Daraus generiert - es ein Einmalpasswort oder eine Liste von Einmalpasswörtern. - &man.opiepasswd.1; wird benutzt, um Passwörter, Iterationszähler - oder Initialwerte zu ändern. Als Parameter verlangt es - entweder ein geheimes Passwort oder einen Iterationszähler - oder einen Initialwert und ein Einmalpasswort. + werden. Ein Einmalpasswort oder eine Liste von + Einmalpasswörtern, die von &man.opiekey.1; durch Angabe eines + Iterationszählers, eines Initalwertes und einem geheimen + Passwort generiert wird. &man.opiepasswd.1; wird benutzt, um + Passwörter, Iterationszähler oder Initialwerte zu ändern. &man.opieinfo.1; hingegen gibt den momentanen Iterationszähler und Initialwert eines Benutzers aus, den es aus /etc/opiekeys ermittelt. - Es gibt vier verschiedene Arten von Tätigkeiten. Zuerst - wird erläutert, wie &man.opiepasswd.1; ü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 &man.opiepasswd.1; über - eine nicht gesicherte Verbindung, oder zusammen mit - &man.opiekey.1; über eine gesicherte Verbindung eingesetzt - werden, um dasselbe zu erreichen. Als drittes wird beschrieben, - wie &man.opiekey.1; genutzt wird, um sich über eine nicht - gesicherte Verbindung anzumelden. Die vierte Tätigkeit - beschreibt, wie mit &man.opiekey.1; 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. + Dieser Abschnitt beschreibt vier verschiedene Arten von + Tätigkeiten. Zuerst wird erläutert, wie Einmalpasswörter über + eine gesicherte Verbindung konfiguriert werden. Als nächstes + wird erklärt, wie opiepasswd über + eine nicht gesicherte Verbindung eingesetzt wird. Als drittes + wird beschrieben, wie man sich über eine nicht gesicherte + Verbindung anmeldet. Die vierte Tätigkeit beschreibt, wie man + eine Reihe von Schlüsseln generiert, die man sich aufschreiben + oder ausdrucken kann, um sich von Orten anzumelden, die über + keine gesicherten Verbindungen verfügen. - Einrichten über eine gesicherte Verbindung + <acronym>OPIE</acronym> initialisieren Um OPIE erstmals zu initialisieren, - rufen Sie &man.opiepasswd.1; auf: + rufen Sie &man.opiepasswd.1; über eine gesicherte Verbindung + 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 merken, 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. Bei der nächsten - Anmeldung müssen Sie dann dieses Einmalpasswort - benutzen. + Die Option startet den Konsolen-Modus, + der davon ausgeht, dass der Befehl von einem sicherem Ort + ausgeführt wird. Dies kann beispielsweise der eigene Rechner + sein, oder über eine mit SSH gesicherte + Verbindung zum eigenen Rechner. + + Geben Sie das geheime Passwort ein, wenn Sie danach + gefragt werden. Damit werden die Einmalpasswörter generiert. + Dieses Passwort sollte schwer zu erraten sein und sich + ebenfalls vom Passwort des Bentuzerkontos unterscheiden. Es + muss zwischen 10 und 127 Zeichen lang sein. Prägen Sie sich + dieses Passwort gut ein! + + Die Zeile, die mit ID beginnt, enthält den + Login-Namen (unfrul), den voreingestellten + Iterationszähler (499) und den Initialwert + (to4268). Das System erinnert sich an + diese Parameter und wird sie bei einem Anmeldeversuch + anzeigen. Sie brauchen sich diese Dinge also nicht merken. + Die letzte Zeile enthält das generierte Einmalpasswort, das + aus den Parametern und dem geheimen Passwort ermittelt wurde. + Bei der nächsten Anmeldung muss dann diese Einmalpasswort + benutzt werden. - Einrichten über eine nicht gesicherte Verbindung + Initialisierung über eine nicht gesicherte + Verbindung Um Einmalpasswörter über eine nicht gesicherte Verbindung - einzurichten, oder das geheime Passwort zu ändern, müssen Sie - über eine gesicherte Verbindung zu einer Stelle verfügen, an - der Sie &man.opiekey.1; ausführen können. Dies kann etwa die + zu initialisieren, oder das geheime Passwort zu ändern, müssen + Sie über eine gesicherte Verbindung zu einer Stelle verfügen, + an der Sie opiekey ausführen können. Dies kann etwa die Eingabeaufforderung auf einer Maschine sein, der Sie vertrauen. 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 &man.opiepasswd.1; ü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 not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Gehen Sie zurück zu der nicht gesicherten Verbindung und geben dort das eben generierte Einmalpasswort ein. Erzeugen eines einzelnen Einmalpasswortes Nachdem 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: OPIE besitzt eine nützliche Eigenschaft. Wenn Sie an der Eingabeaufforderung Return drücken, 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-DOS Windows MacOS Jetzt müssen Sie das Einmalpasswort generieren, um der Anmeldeaufforderung nachzukommen. Dies muss auf einem gesicherten System geschehen, auf dem Sie &man.opiekey.1; ausführen können. Dieses Programm gibt es auch für &windows;, &macos; und &os;. 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: Do not use opiekey from telnet or dial-in sessions. Enter secret pass phrase: GAME GAG WELT OUT DOWN CHAT Sobald das Einmalpasswort generiert wurde, können Sie die Anmeldeprozedur fortsetzen. Erzeugen von mehreren Einmalpasswörtern Manchmal haben Sie keinen Zugriff auf eine sichere Maschine oder eine sichere Verbindung. In diesem Fall können Sie vorher mit &man.opiekey.1; einige Einmalpasswörter generieren. Zum Beispiel: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. Reminder: Do not 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 PHI Mit 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. Wirklich paranoide Benutzer können sich jetzt die Passwörter aufschreiben oder ausdrucken. Sie sollten die Passwörter nach Gebrauch durchstreichen. Einschränken der Benutzung von System-Passwörtern OPIE kann die Verwendung von &unix;-Passwörtern abhängig von der IP-Adresse einschränken. Die dazu nötigen Einstellungen werden in /etc/opieaccess vorgenommen, die bei der Installation des Systems automatisch erzeugt wird. Weitere Informationen über diese Datei und Sicherheitshinweise zu ihrer Verwendung finden Sie in &man.opieaccess.5;. opieaccess könnte beispielsweise die folgende Zeile enthalten: permit 192.168.0.0 255.255.0.0 Diese Zeile erlaubt es Benutzern, die sich von einer der angegebenen IP-Adressen anmelden, ihr &unix;-Passwort zu verwenden. Beachten Sie bitte, dass eine IP-Adresse leicht gefälscht werden kann. Findet sich in opieaccess kein passender Eintrag, muss die Anmeldung mit OPIE erfolgen. TCP-Wrapper TomRhodesBeigetragen von TCP-Wrapper TCP-Wrapper erweitern die Fähigkeiten von . Beispielsweise können Verbindungen protokolliert, Nachrichten zurückgesandt oder nur interne Verbindungen angenommen werden. Einige dieser Fähigkeiten können auch über eine Firewall implementiert werden, TCP-Wrapper fügen jedoch noch eine weitere Sicherheitsschicht und Kontrollmöglichkeiten hinzu, die eine Firewall nicht bieten kann. TCP-Wrapper sollten nicht als Ersatz für eine ordentlich konfigurierte Firewall angesehen werden, sondern stattdessen in Verbindung mit einer Firewall und anderen Sicherheitsmechanismen eingesetzt werden. TCP-Wrapper einrichten Um TCP-Wrapper unter &os; zu benutzen, muss der &man.inetd.8;-Server aus rc.conf mit den Optionen gestartet werden. Anschließend muss /etc/hosts.allow richtig konfiguriert werden. Im Gegensatz zu anderen Implementierungen 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 &man.inetd.8; gestartete Dienst erlaubt. Eine Konfigurationszeile ist wie folgt aufgebaut: Dienst : Adresse : Aktion. Dienst ist der von &man.inetd.8; gestartete Dienst (auch Daemon genannt). Die Adresse ist ein gültiger Rechnername, eine IP-Adresse oder eine IPv6-Adresse in Klammern ([ ]). 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. Um beispielsweise einkommende POP3-Verbindungen für den Dienst mail/qpopper zu erlauben, sollte hosts.allow um die nachstehende Zeile erweitert werden: # This line is required for POP3 connections: qpopper : ALL : allow Nachdem Sie die Zeile hinzugefügt haben, muss &man.inetd.8; neu gestartet werden: &prompt.root; service inetd restart Erweiterte Konfiguration 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. Externe Kommandos Stellen Sie sich vor, eine Verbindung soll verhindert werden und gleichzeitig soll demjenigen, der die Verbindung aufgebaut hat, eine Nachricht geschickt werden. Solch eine Aktion ist mit möglich. führt beim Verbindungsaufbau ein Kommando oder ein Skript aus. Ein Beispiel ist in hosts.allow 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 hosts.allow konfiguriert wurde, wird die Meldung You are not allowed to use daemon from hostname. zurückgegeben. Dies ist nützlich, wenn die Gegenstelle sofort benachrichtigt werden soll, nachdem die Verbindung getrennt wurde. Der Text der Meldung muss in Anführungszeichen (") stehen. Ein so konfigurierter Server ist anfällig für Denial-of-Service-Angriffe. Ein Angreifer kann die gesperrten Dienste mit Verbindungsanfragen überfluten. Eine weitere Möglichkeit bietet . Wie verbietet die Verbindung und führt externe Kommandos aus. Allerdings sendet 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) \ : deny Damit sind Verbindungen von der Domain *.example.com gesperrt. Jeder Verbindungsaufbau wird zudem in /var/log/connections.log protokolliert. Das Protokoll enthält den Rechnernamen, die IP-Adresse und den Dienst, der angesprochen wurde. In diesem Beispiel wurden die Metazeichen %a und %h verwendet. Eine vollständige Liste der Metazeichen finden Sie in &man.hosts.access.5;. Wildcards Die Wildcard ALL passt 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 beispielsweise der Fall, wenn der Verbindungsaufbau von einer IP-Adresse erfolgt, die nicht zu dem übermittelten Rechnernamen passt. In diesem Beispiel werden alle Verbindungsanfragen zu &man.sendmail.8; abgelehnt, wenn die IP-Adresse nicht zum Rechnernamen passt: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny Die Wildcard PARANOID kann einen Dienst unbrauchbar machen, wenn der Client oder der Server eine fehlerhafte DNS-Konfiguration besitzt. Seien Sie daher besonders vorsichtig, wenn Sie diese Wildcard in Ihre Konfiguration aufnehmen wollen. Weitere Informationen über Wildcards und deren Funktion finden Sie in &man.hosts.access.5;. Damit die gezeigten Beispiele funktionieren, muss die erste Konfigurationszeile in hosts.allow auskommentiert werden. <application>Kerberos5</application> TillmanHodgsonBeigetragen von MarkMurrayBeruht auf einem Beitrag von Kerberos ist ein Netzwerk-Protokoll, das Benutzer mithilfe eines sicheren Servers authentifiziert. Die Daten einer Kommunikation können verschlüsselt werden, nachdem die Kommunikationspartner mit Kerberos ihre Identität geprüft haben. Kerberos hat nur 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 folgenden Anweisungen beschreiben, wie Sie das mit &os; gelieferte Kerberos einrichten. Eine vollständige Beschreibung des Systems entnehmen Sie 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. Geschichte Kerberos5 Geschichte Das MIT hat Kerberos entwickelt, 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 ist als Port oder Paket security/krb5 verfügbar. 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 oder Paket security/heimdal und das Basissystem von &os; enthält eine minimale Installation von Heimdal. Die folgenden Beispiele verwenden die in &os; enthaltene Heimdal-Distribution. Das Heimdal <acronym>KDC</acronym> einrichten Kerberos5 Key Distribution Center Kerberos 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 der Kerberos-Server wenig Ressourcen benötigt, sollte das KDC 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 /etc/krb5.conf wie folgt bearbeitet: [libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG Diese Einstellungen setzen voraus, dass der voll qualifizierte Name des KDCs kerberos.example.org ist. Wenn das KDC einen anderen Namen hat, muss in der DNS-Zone ein Alias-Eintrag (CNAME-Record) für das KDC hinzugefügt werden. In großen Netzwerken mit einem ordentlich konfigurierten DNS-Server kann die Datei aus dem obigen Beispiel verkürzt werden: [libdefaults] default_realm = EXAMPLE.ORG Die 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.ORG Damit die Clients die Kerberos-Dienste benutzen können, muss /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 sich nicht merken, da ein davon abgeleiteter Schlüssel in /var/heimdal/m-key gespeichert wird. Um den Schlüssel zu erstellen, rufen Sie &man.kstash.8; auf und geben Sie ein Passwort ein. Nachdem der Schlüssel erstellt wurde, sollte die Datenbank initialisiert werden. Das Kerberos-Werkzeug &man.kadmin.8; kann mit kadmin -l im lokalen Modus benutzt werden, ohne den Netzwerkdienst, welcher zu diesem Zeitpunkt noch nicht läuft, zu verwenden. An der Eingabeaufforderung von &man.kadmin.8; kann mit init die Datenbank des Realms initialisiert werden. Zuletzt wird mit add das erste Prinzipal erstellt. Benutzen Sie die voreingestellten Optionen. Die Einstellungen können später modify verändert werden. An der Eingabeaufforderung von &man.kadmin.8; zeigt ? 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: xxxxxxxx Jetzt kann das KDC gestartet werden. Führen Sie zum Start der Dienste service kerberos start und service kadmind start aus. Obwohl zu diesem Zeitpunkt noch keine kerberisierten Dienste laufen, kann die Funktion des KDCs schon überprüft werden. Für den eben angelegten Benutzer können Sie sich vom KDC Tickets holen und anzeigen lassen: &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.ORG Nachdem der Test abgeschlossen ist, kann das temporäre Ticket zurückgezogen werden: &prompt.user; kdestroy Heimdal <application>Kerberos</application>-Dienste einrichten Kerberos5 Dienste einrichten Bei der Konfiguration eines Servers für die Kerberos-Authentifizierung muss zuerst sichergestellt werden, dass /etc/krb5.conf richtig konfiguriert ist. Die Datei kann entweder vom KDC kopiert, oder auf dem neuen System regeneriert werden. Als nächstes muss auf dem Server die /etc/krb5.keytab erzeugt werden. Dies ist der Hauptbestandteil um Dienste zu kerberisieren und entspricht der Erzeugung eines geheimen Schlüssels zwischen dem Dienst und dem KDC. Das Geheimnis ist ein kryptographischer Schlüssel, der in einem keytab> abgelegt wird. Diese Datei enthält den Schlüssel des Servers, mit dem sich der Server und das KDC gegenseitig authentifizieren können. Sie muss in einer sicheren Art und Weise an den Server übertragen werden, da ansonsten die Sicherheit des Servers gefährdet ist, wenn z.B. die Schlüssel öffentlich werden. In der Regel wird die keytab auf einem vertrauenswürdigen Rechner mit kadmin erzeugt und anschließend sicher auf den Server übertragen, beispielsweise mit &man.scp.1;. Wenn die Sicherheitsrichtlinien es erlauben, kann die Datei auch direkt auf dem Server erzeugt werden. Es ist sehr wichtig, dass die keytab auf sichere Weise auf den Server übertragen wird. Wenn der Schlüssel einer anderen Partei bekannt wird, kann sich diese Partei den Benutzern als Server ausgeben! Da der Eintrag für das Host-Prinzipal für die KDC-Datenbank auch mit kadmin erstellt wird, ist es praktisch, kadmin direkt auf dem Server zu benutzen. Natürlich ist auch kadmin ein kerberisierter Dienst: ein Kerberos-Ticket ist erforderlich, um sich gegenüber dem Netzwerkdienst zu authentifizieren und um sicherzustellen, dass der Benutzer, der kadmin ausführt, tatsächlich vorhanden ist. kadmin wird nach dem Passwort fragen, um ein neues Ticket zu generieren. Das Prinzipal, das sich mit dem kadmin-Dienst authentifiziert, muss über die Zugriffskontrollliste kadmin.acl dazu berechtigt sein. Weitere Informationen über Zugriffskontrolllisten finden Sie in den Heimdal-Info-Seiten (info heimdal) im Abschnitt Remote administration. Wenn der Zugriff auf kadmin von entfernten Rechnern verboten ist, kann sich der Administrator entweder über die lokale Konsole oder über &man.ssh.1; mit dem KDC verbinden, um die lokale Administration mit kadmin -l durchzuführen. Nach der Installation von /etc/krb5.conf, können Sie das Kommando add --random-key in kadmin ausführen, um das Host-Prinzipal in die Datenbank zu schreiben. Das Kommando ext extrahiert den Schlüssel des Prinzipals in eine eigene keytab: &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> exit Beachten Sie, dass ext den extrahierten Schlüssel standardmäßig in /etc/krb5.keytab speichert. Das ist gut, wenn das Kommando auf dem kerberisierten Server ausgeführt wird, ansonsten sollte das Argument --keytab pfad/zur/datei benutzt werden, wenn die keytab an einen anderen Ort extrahiert wird: &prompt.root; kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit Anschließend kann die erzeugte keytab sicher mit scp auf Server oder auf einen Wechseldatenträger kopiert werden. 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 die kerberisierten Dienste aktiviert werden. Einer der gebräuchlichsten Dienste ist &man.sshd.8;, der Kerberos über GSS-API unterstützt. Fügen Sie folgende Zeile in /etc/ssh/sshd_config ein: GSSAPIAuthentication yes Nach dieser Änderung muss &man.sshd.8; mit service sshd restart neu gestartet werden, damit die neue Konfiguration wirksam wird. Heimdal <application>Kerberos</application>-Clients einrichten Kerberos5 Clients einrichten Genau wie der Server, benötigt auch der Client eine Konfiguration in /etc/krb5.conf. Kopien Sie die Datei (sicher) vom KDC auf den Client, oder schreiben Sie die Datei bei Bedarf einfach neu. Testen Sie den Client, indem Sie mit kinit Tickets anfordern, mit klist Tickets anzeigen und mit kdestroy Tickets löschen. Kerberos-Anwendungen sollten auch kerberisierte Server ansprechen können. Wenn das nicht funktioniert, Sie aber Tickets anfordern können, hat wahrscheinlich der kerberisierte Server ein Problem und nicht der Client oder das KDC. Im Falle eines kerberisierten &man.ssh.1; ist GSS-API in der Voreinstellung deaktiviert. Testen Sie daher mit ssh -o GSSAPIAuthentication=yes hostname. Wenn Sie die kerberisierten Anwendungen testen, können Sie einen Paket-Sniffer wie tcpdump benutzen, um sicherzustellen, dass keine sensiblen Informationen im Klartext übertragen werden. Es stehen verschiedene Kerberos-Anwendungen zur Verfügung. Die Anwendungen, die SASL benutzen, können dann auch GSS-API benutzen. Viele Arten von Anwendungen können Kerberos zur Authentifizierung verwenden, vom Jabber-Client bis zum IMAP-Client. .k5login .k5users Normalerweise wird ein Kerberos-Prinzipal auf ein lokales Benutzerkonto abgebildet. 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 Benutzers können verwendet werden, um dieses Problem zu lösen. Mit der folgenden .k5login im Heimatverzeichnis des Benutzers webdevelopers haben beide Prinzipale auch ohne das gemeinsame Passwort Zugriff auf das Konto: tillmann@example.org jdoe@example.org Weitere Informationen zu .k5users finden Sie in &man.ksu.1;. Tipps und Fehlersuche Kerberos5 Fehlersuche Wenn Sie den Heimdal-Port oder den MIT-Port benutzen, muss in der Umgebungsvariable PATH der Pfad zu den Kerberos-Programmen vor dem Pfad zu den Programmen des Systems stehen. Wenn die Clients im Realm ihre Uhrzeit nicht synchronisieren, schlägt vielleicht die Authentifizierung fehl. beschreibt, wie Sie mithilfe von NTP die Uhrzeiten synchronisieren. Die MIT- und Heimdal-Systeme arbeiten bis auf kadmin, welches nicht standardisiert ist, gut zusammen. Wenn Sie den Namen eines Rechners ändern, müssen Sie auch den host/-Prinzipal ändern und die keytab aktualisieren. Dies betrifft auch spezielle Einträge wie den Prinzipal für Apaches www/mod_auth_kerb. Alle Rechner in einem Realm müssen vor- und rückwärts aufgelöst werden können. Entweder über DNS, zumindest aber über /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 hat zur Folge, dass ksu nicht funktioniert. Dies ist ein Fehler in den Zugriffsrechten und 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. Das Prinzipal kann dann mit kinit -l ein Ticket mit einer längeren Gültigkeit beantragen. 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 TGT. Das TGT 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 in sshd_config auf no. Ansonsten werden die Tickets gelöscht, wenn Sie sich abmelden. Host-Prinzipale können 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, wie in &man.kadmin.8; beschrieben, geht das nur mit Prinzipalen, denen eine Passwort-Policy zugewiesen wurde. Das Format von krb5.dict enthält pro Zeile ein Wort. Sie können daher einen symbolischen Link auf /usr/share/dict/words erstellen. Unterschiede zum <acronym>MIT</acronym>-Port Der 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 http://web.mit.edu/Kerberos/www/ 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 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. Wird MIT-Kerberos auf &os; eingesetzt, sollten in rc.conf folgende Zeilen aufgenommen werden: kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_flags="" kerberos5_server_enable="YES" kadmind5_server_enable="YES" Diese Zeilen sind notwendig, weil die Anwendungen von MIT-Kerberos die Binärdateien unterhalb von /usr/local installieren. Beschränkungen von <application>Kerberos</application> Kerberos5 Beschränkungen <application>Kerberos</application> muss ganzheitlich verwendet werden Jeder über das Netzwerk angebotene 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 Remote-ShellsKerberos zu benutzen, dagegen aber POP3-Zugriff auf einen Mail-Server zu erlauben, da POP3-Passwörter im Klartext versendet. <application>Kerberos</application> ist für Einbenutzer-Systeme gedacht In 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 von einem anderen Benutzer gestohlen oder kopiert 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. Es reicht, die Tickets im Heimatverzeichnis eines Benutzers zu speichern und mit Zugriffsrechten zu schützen. Das <acronym>KDC</acronym> ist verwundbar Das KDC muss genauso abgesichert werden wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC sollten absolut 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, sind auch die Netzwerkdienste nicht benutzbar, da eine Authentifizierung nicht durchgeführt werden kann. Das KDC ist also ein optimales Ziel für einen Denial-of-Service Angriff. Sie können diesem Angriff entgegenwirken, indem Sie einen KDC-Master und einen oder mehrere Slaves verwenden. Der Rückfall auf ein sekundäres KDC mittels PAM-Authentifizierung muss sorgfältig eingerichtet werden. Mängel von <application>Kerberos</application> Mit 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 &man.kinit.1; 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 Dokumentation Kerberos5 weiterführende Dokumentation The Kerberos FAQ Designing an Authentication System: a Dialogue in Four Scenes RFC 1510, The Kerberos Network Authentication Service (V5) MIT Kerberos-Seite Heimdal Kerberos-Seite OpenSSL TomRhodesBeigetragen von Sicherheit OpenSSL OpenSSL OpenSSL ist eine freie Implementierung der SSL und TLS-Protokolle. Es 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/apache22 und mail/claws-mail, 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 in &os; integrierte OpenSSL 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 /etc/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 erzeugen OpenSSL Zertifikate erzeugen Ein 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 []: An optional company name []:Another Name Beachten Sie, 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. &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 CA senden, wo die Angaben geprüft werden. Nach erfolgreicher Prüfung wird das Zertifikat unterschrieben und an Sie zurückgesandt. Die zweite Datei, cert.pem, enthält den privaten Schlüssel für das 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 1024 Erzeugen Sie dann den CA-Schlüssel: &prompt.root; openssl gendsa -des3 -out myca.key myRSA.key Erstellen Sie mit diesem Schlüssel das Zertifikat: &prompt.root; openssl req -new -x509 -days 365 -key myca.key -out new.crt Zwei 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/ssl abgelegt werden, das nur von root lesbar ist. Die Zugriffsrechte der Dateien können mit &man.chmod.1; auf 0700 gesetzt werden. Zertifikate benutzen Mit einem Zertifikat können beispielsweise die Verbindungen zu Sendmail verschlüsselt werden, um eine Klartext-Authentifizierung zu verhindern. Einige E-Mail-Programme geben Warnungen aus, wenn ein Zertifikat nicht lokal installiert ist. Weitere Informationen zur Installation von Zertifikaten finden Sie in der Dokumentation der entsprechenden Software. 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')dnl Im 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. Starten Sie anschließend Sendmail mit make restart neu. Wenn alles gut ging, erscheinen keine Fehlermeldungen in /var/log/maillog und Sie sehen Sendmail in der Prozessliste. Testen Sie nun den Mailserver mit &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 die Zeile STARTTLS erscheint, hat alles funktioniert. <acronym>VPN</acronym> mit IPsec NikClayton
nik@FreeBSD.org
Geschrieben von IPsec IPsec Grundlagen Hiten M.Pandya
hmp@FreeBSD.org
Geschrieben von Dieser Abschnitt beschreibt die Einrichtung von IPsec. Um IPsec einzurichten, sollten Sie einen neuen Kernel bauen 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. IPsec ESP IPsec AH IPsec besteht wiederum aus zwei Protokollen: Encapsulated Security Payload (ESP) verschlüsselt IP-Pakete mit einem symmetrischen Verfahren wie Blowfish oder 3DES. Damit werden die Pakete vor Manipulationen Dritter geschützt. Der Authentication Header (AH) enthält eine kryptographische Prüfsumme, die sicher stellt, dass ein IP-Paket nicht verändert wurde. Der Authentication-Header folgt nach dem normalen IP-Header und erlaubt dem Empfänger eines IP-Paketes, dessen Integrität zu prüfen. ESP und AH können, je nach Situation, zusammen oder einzeln verwendet werden. VPN Virtual Private Network VPN IPsec 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; finden Sie in &man.ipsec.4;. Die folgenden Optionen in der Kernelkonfiguration aktivieren IPsec: Kerneloption IPSEC options IPSEC #IP security device crypto Kerneloption IPSEC_DEBUG Wenn Sie zur Fehlersuche im IPsec-Subsystem Unterstützung wünschen, sollten Sie die folgende Option ebenfalls aktivieren: options IPSEC_DEBUG #debug for IP security VPN zwischen einem Heim- und Firmennetzwerk einrichten VPN einrichten 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 Möglichkeiten vor, um ein VPN für das folgende Szenario aufzubauen: Es müssen mindestens zwei Netzwerke vorhanden sein, welche intern IP benutzen. Beide Netzwerke sind über ein &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. Sie dürfen sich jedoch nicht überlappen. Zum Beispiel sollten nicht beide Netze 192.168.1.x benutzen. Konfiguration von IPsec in &os; TomRhodes
trhodes@FreeBSD.org
Geschrieben von Als erstes muss security/ipsec-tools aus der Ports-Sammlung installiert werden. Diese Software enthält einige Anwendungen, die bei der Konfiguration von IPsec hilfreich sind. Als nächstes müssen zwei &man.gif.4;-Pseudogeräte angelegt werden, um die Pakete zu tunneln und dafür zu sorgen, dass beide Netzwerke richtig miteinander kommunizieren können. Geben Sie als root die folgenden Befehle ein, wobei Sie intern und extern durch die realen internen und externen IP-Adressen der Gateways ersetzen müssen: &prompt.root; ifconfig gif0 create &prompt.root; ifconfig gif0 intern1 intern2 &prompt.root; ifconfig gif0 tunnel extern1 extern2 In diesem Beispiel ist die externe IP-Adresse des Firmennetzwerkes (LAN) 172.16.5.4 und die interne IP-Adresse ist 10.246.38.1. Das Heimnetzwerk (LAN) hat die externe IP-Adresse 192.168.1.12 mit der internen privaten IP-Adresse 10.0.0.5. Wenn dies verwirrend erscheint, schauen Sie sich die folgende Ausgabe von &man.ifconfig.8;an: Gateway 1: gif0: flags=8051 mtu 1280 tunnel inet 172.16.5.4 --> 192.168.1.12 inet6 fe80::2e0:81ff:fe02:5881%gif0 prefixlen 64 scopeid 0x6 inet 10.246.38.1 --> 10.0.0.5 netmask 0xffffff00 Gateway 2: gif0: flags=8051 mtu 1280 tunnel inet 192.168.1.12 --> 172.16.5.4 inet 10.0.0.5 --> 10.246.38.1 netmask 0xffffff00 inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4 Wenn Sie fertig sind, sollten beide internen Adressen über &man.ping.8; erreichbar sein: priv-net# ping 10.0.0.5 PING 10.0.0.5 (10.0.0.5): 56 data bytes 64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=42.786 ms 64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=19.255 ms 64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=20.440 ms 64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=21.036 ms --- 10.0.0.5 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 19.255/25.879/42.786/9.782 ms corp-net# ping 10.246.38.1 PING 10.246.38.1 (10.246.38.1): 56 data bytes 64 bytes from 10.246.38.1: icmp_seq=0 ttl=64 time=28.106 ms 64 bytes from 10.246.38.1: icmp_seq=1 ttl=64 time=42.917 ms 64 bytes from 10.246.38.1: icmp_seq=2 ttl=64 time=127.525 ms 64 bytes from 10.246.38.1: icmp_seq=3 ttl=64 time=119.896 ms 64 bytes from 10.246.38.1: icmp_seq=4 ttl=64 time=154.524 ms --- 10.246.38.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms Wie erwartet, können nun beiden Seiten ICMP-Pakete von ihren privaten Adressen senden und empfangen. Als nächstes müssen beide Gateways so konfiguriert werden, dass sie die Pakete des anderen Netzwerkes richtig routen. Mit dem folgenden Befehl erreicht man das Ziel: &prompt.root; corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0 &prompt.root; corp-net# route add net 10.0.0.0: gateway 10.0.0.5 &prompt.root; priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0 &prompt.root; priv-net# route add host 10.246.38.0: gateway 10.246.38.1 Ab jetzt sollten die Rechner von den Gateways sowie von den Rechnern hinter den Gateways erreichbar sein. Dies können Sie wieder mit &man.ping.8; überprüfen: corp-net# ping 10.0.0.8 PING 10.0.0.8 (10.0.0.8): 56 data bytes 64 bytes from 10.0.0.8: icmp_seq=0 ttl=63 time=92.391 ms 64 bytes from 10.0.0.8: icmp_seq=1 ttl=63 time=21.870 ms 64 bytes from 10.0.0.8: icmp_seq=2 ttl=63 time=198.022 ms 64 bytes from 10.0.0.8: icmp_seq=3 ttl=63 time=22.241 ms 64 bytes from 10.0.0.8: icmp_seq=4 ttl=63 time=174.705 ms --- 10.0.0.8 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.870/101.846/198.022/74.001 ms priv-net# ping 10.246.38.107 PING 10.246.38.1 (10.246.38.107): 56 data bytes 64 bytes from 10.246.38.107: icmp_seq=0 ttl=64 time=53.491 ms 64 bytes from 10.246.38.107: icmp_seq=1 ttl=64 time=23.395 ms 64 bytes from 10.246.38.107: icmp_seq=2 ttl=64 time=23.865 ms 64 bytes from 10.246.38.107: icmp_seq=3 ttl=64 time=21.145 ms 64 bytes from 10.246.38.107: icmp_seq=4 ttl=64 time=36.708 ms --- 10.246.38.107 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms Das Konfigurieren der Tunnel ist der einfache Teil. Die Konfiguration einer sicheren Verbindung geht viel mehr in die Tiefe. Die folgende Konfiguration benutzt pre-shared (PSK) RSA-Schlüssel. Abgesehen von den IP-Adressen, sind beide /usr/local/etc/racoon/racoon.conf identisch und sehen ähnlich aus: path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete padding # options are not to be changed { maximum_length 20; randomize off; strict_check off; exclusive_tail off; } timer # timing options. change as needed { counter 5; interval 20 sec; persend 1; # natt_keepalive 15 sec; phase1 30 sec; phase2 15 sec; } listen # address [port] that racoon will listen on { isakmp 172.16.5.4 [500]; isakmp_natt 172.16.5.4 [4500]; } remote 192.168.1.12 [500] { exchange_mode main,aggressive; doi ipsec_doi; situation identity_only; my_identifier address 172.16.5.4; peers_identifier address 192.168.1.12; lifetime time 8 hour; passive off; proposal_check obey; # nat_traversal off; generate_policy off; proposal { encryption_algorithm blowfish; hash_algorithm md5; authentication_method pre_shared_key; lifetime time 30 sec; dh_group 1; } } sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/$netmask $type address $network/$netmask $type ( $type being any or esp) { # $network must be the two internal networks you are joining. pfs_group 1; lifetime time 36000 sec; encryption_algorithm blowfish,3des,des; authentication_algorithm hmac_md5,hmac_sha1; compression_algorithm deflate; } Eine Beschreibung der verfügbaren Optionen finden Sie in der Manualpage von racoon.conf. Die Security Policy Database (SPD) muss noch konfiguriert werden, so dass &os; und racoon in der Lage sind den Netzwerkverkehr zwischen den Hosts zu ver- und entschlüsseln. Dies wird durch ein Shellskript ähnlich wie das folgende, das auf dem Firmennetzwerk-Gateway liegt, ausgeführt. Diese Datei wird während der Systeminitialisierung ausgeführt und sollte unter /usr/local/etc/racoon/setkey.conf gespeichert werden. flush; spdflush; # To the home network spdadd 10.246.38.0/24 10.0.0.0/24 any -P out ipsec esp/tunnel/172.16.5.4-192.168.1.12/use; spdadd 10.0.0.0/24 10.246.38.0/24 any -P in ipsec esp/tunnel/192.168.1.12-172.16.5.4/use; Einmal abgespeichert, kann racoon durch das folgende Kommando auf beiden Gateways gestartet werden: &prompt.root; /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.log Die Ausgabe sollte so ähnlich aussehen: corp-net# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf Foreground mode. 2006-01-30 01:35:47: INFO: begin Identity Protection mode. 2006-01-30 01:35:48: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:35:55: INFO: received Vendor ID: KAME/racoon 2006-01-30 01:36:04: INFO: ISAKMP-SA established 172.16.5.4[500]-192.168.1.12[500] spi:623b9b3bd2492452:7deab82d54ff704a 2006-01-30 01:36:05: INFO: initiate new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=28496098(0x1b2d0e2) 2006-01-30 01:36:09: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=47784998(0x2d92426) 2006-01-30 01:36:13: INFO: respond new phase 2 negotiation: 172.16.5.4[0]192.168.1.12[0] 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 192.168.1.12[0]->172.16.5.4[0] spi=124397467(0x76a279b) 2006-01-30 01:36:18: INFO: IPsec-SA established: ESP/Tunnel 172.16.5.4[0]->192.168.1.12[0] spi=175852902(0xa7b4d66) Um sicherzustellen, dass der Tunnel richtig funktioniert, wechseln Sie auf eine andere Konsole und benutzen Sie &man.tcpdump.1; mit dem folgenden Befehl, um sich den Netzwerkverkehr anzusehen. Tauschen Sie em0 durch die richtige Netzwerkkarte aus: &prompt.root; tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12 Die Ausgabe der Konsole sollte dem hier ähneln. Wenn nicht, gibt es ein Problem und ein Debuggen der ausgegebenen Daten ist notwendig. 01:47:32.021683 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa) 01:47:33.022442 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xb) 01:47:34.024218 IP corporatenetwork.com > 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xc) An diesem Punkt sollten beide Netzwerke verfügbar sein und den Anschein haben, dass sie zum selben Netzwerk gehören. Meistens sind beide Netzwerke durch eine Firewall geschützt. Um den Netzwerkverkehr zwischen den beiden Netzwerken zu erlauben, ist es notwendig Regeln zu erstellen. Für die &man.ipfw.8; Firewall fügen Sie folgende Zeilen in die Firewall-Konfigurationsdatei ein: ipfw add 00201 allow log esp from any to any ipfw add 00202 allow log ah from any to any ipfw add 00203 allow log ipencap from any to any ipfw add 00204 allow log udp from any 500 to any Die Regelnummern müssen eventuell, je nach ihrer Hostkonfiguration, angepasst werden. Für Benutzer der &man.pf.4;- oder &man.ipf.8;-Firewall sollte folgendes funktionieren: pass in quick proto esp from any to any pass in quick proto ah from any to any pass in quick proto ipencap from any to any pass in quick proto udp from any port = 500 to any port = 500 pass in quick on gif0 from any to any pass out quick proto esp from any to any pass out quick proto ah from any to any pass out quick proto ipencap from any to any pass out quick proto udp from any port = 500 to any port = 500 pass out quick on gif0 from any to any Zum Ende, um dem Computer den Start vom VPN während der Systeminitialisierung zu erlauben, fügen Sie folgende Zeilen in ihre /etc/rc.conf: ein ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot racoon_enable="yes" OpenSSH ChernLeeBeigetragen von OpenSSH Sicherheit OpenSSH OpenSSH stellt Werkzeuge bereit, um sicher auf entfernte Maschinen zuzugreifen. 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 wird in der Voreinstellung von &os; installiert. OpenSSH ist mit den SSH-Protokollen der Versionen 1 und 2 kompatibel. Vorteile von <application>OpenSSH</application> Wenn Daten unverschlüsselt über das Netzwerk gesendet werden, 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. Den SSH-Server aktivieren OpenSSH aktivieren Um zu überprüfen, ob &man.sshd.8; auf dem 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-Daemon, beim Systemstart automatisch aktiviert. Alternativ kann OpenSSH auch über &man.service.8; gestartet werden: &prompt.root; service sshd start SSH Client OpenSSH Client Benutzen Sie &man.ssh.1; um sich mit einem System zu verbinden, auf dem &man.sshd.8; läuft. Verwenden Sie dazu den Benutzernamen und den Namen des Rechners, mit dem Sie sich verbinden möchten: &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: ******* 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 werden in ~/.ssh/known_hosts gespeichert. In der Voreinstellung akzeptieren aktuelle Versionen von &man.sshd.8; nur SSH v2 Verbindungen. Wenn möglich, wird der Client versuchen Version 2 zu verwenden, ist dies nicht möglich, fällt er auf Version 1 zurück. Der Client kann gezwungen werden, nur eine der beiden Versionen zu verwenden, indem die Option oder übergeben wird. Die Unterstützung für Version 1 ist nur noch aus Kompatibilitätsgründen zu älteren Versionen enthalten. Secure Copy OpenSSH secure copy &man.scp.1; Mit &man.scp.1; lassen sich Dateien in einer sicheren Weise auf entfernte Maschinen ü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 &man.scp.1; übergeben werden, gleichen denen von &man.cp.1; 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. Konfiguration OpenSSH Konfiguration Die für das ganze System gültigen Konfigurationsdateien des OpenSSH-Daemons und des Clients befinden sich in /etc/ssh. Die Client-Konfiguration befindet sich in ssh_config, die des Servers befindet sich in sshd_config. Für beide Dateien existieren Manualpages, welche die einzelnen Konfigurationsoptionen beschreiben. &man.ssh-keygen.1; Mit &man.ssh-keygen.1; können DSA- oder RSA-Schlüssel für einen Benutzer erzeugt werden, die anstelle von Passwörtern verwendet werden können: &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 ~/.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. Viele Benutzer denken, dass die Verwendung von Schlüsseln generell sicher ist. Sie verwenden dann einen Schlüssel ohne eine Passphrase. Dies ist jedoch sehr gefährlich. Ein Administrator kann überprüfen, ob ein Schlüsselpaar mit einer Passphrase geschützt ist. Wenn die Datei mit dem privaten Schlüssel den Text ENCRYPTED enthält, dann hat der Benutzer eine Passphrase verwendet. Um die Benutzer zusätzlich zu schützen, kann ein from-Feld in der Datei des öffentlichen Schlüssels hinzugefügt werden. Zum Beispiel würde das Hinzufügen von from="192.168.10.5" vor dem ssh-rsa- oder ssh-dsa-Präfix dafür sorgen, dass sich ein bestimmter Benutzer nur noch von dieser IP-Adresse anmelden darf. Wenn bei der Erstellung der Schlüssel mit &man.ssh-keygen.1; eine Passphrase 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 . Die Optionen und Dateinamen sind abhängig von der OpenSSH-Version. Die für das System gültigen Optionen finden Sie in &man.ssh-keygen.1;. Verwendung von SSH-Agent Mit &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 jedes Mal 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. Zudem muss die zu verwaltende Identität mit &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 &xorg; zu verwenden, muss &man.ssh-agent.1; in ~/.xinitrc aufgenommen werden. Dadurch können alle unter &xorg; gestarteten Programme die Dienste von &man.ssh-agent.1; nutzen. ~/.xinitrc könnte etwa so aussehen: exec ssh-agent startxfce4 Dadurch wird bei jedem Start von &xorg; zuerst &man.ssh-agent.1; aufgerufen, das wiederum XFCE startet. Nachdem diese Änderung durchgeführt wurde, muss &xorg; neu gestartet werden. Danach können Sie mit &man.ssh-add.1; die SSH-Schlüssel laden. <acronym>SSH</acronym>-Tunnel OpenSSH Tunnel Mit OpenSSH ist es möglich, einen Tunnel zu erstellen, in dem ein anderes Protokoll verschlüsselt übertragen wird. Das folgende Kommando erzeugt einen Tunnel für &man.telnet.1;: &prompt.user; ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com &prompt.user; Dieses Beispiel verwendet die folgenden Optionen: Zwingt &man.ssh.1; dazu, die Version 2 des Protokolls zu verwenden, um sich mit dem Server zu verbinden. Zeigt an, dass ein Tunnel erstellt werden soll. Ohne diese Option würde &man.ssh.1; eine normale Sitzung öffnen. Zwingt &man.ssh.1; 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 Anmeldenamen auf dem entfernten SSH-Server an. Ein SSH-Tunnel erzeugt einen 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 &man.telnet.1; reserviert ist, erzeugt das eine sichere &man.telnet.1;-Verbindung durch einen SSH-Tunnel. Diese Vorgehensweise kann genutzt werden, um jedes unsichere TCP-Protokoll wie SMTP, POP3 und FTP weiterzuleiten. Mit &man.ssh.1; einen sicheren Tunnel für <acronym>SMTP</acronym> erstellen &prompt.user; ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** &prompt.user; telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP Zusammen mit &man.ssh-keygen.1; und zusätzlichen Benutzer-Accounts können leicht benutzbare SSH-Tunnel aufgebaut werden. Anstelle von Passwörtern können Schlüssel benutzt werden und jeder Tunnel kann unter einem eigenen Benutzer laufen. Praktische Beispiele für <acronym>SSH</acronym>-Tunnel Sicherer Zugriff auf einen <acronym>POP3</acronym>-Server In diesem Beispiel gibt es einen SSH-Server, der Verbindungen von außen akzeptiert. Im selben Netzwerk befindet sich zudem noch ein Mail-Server, der POP3 spricht. Um E-Mails auf sichere Weise abzurufen, bauen Sie eine SSH-Verbindung zu dem SSH-Server im Netzwerk auf und tunneln von dort zum Mail-Server weiter. &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 den Mail-Client so, dass er POP3 Anfragen zu localhost auf Port 2110 sendet. Diese Verbindung wird dann über den gesicherten Tunnel zu mail.example.com weitergeleitet. Umgehen einer strengen Firewall Einige Netzwerkadministratoren stellen sehr drakonische Firewall-Regeln auf, die nicht nur einkommende Verbindungen filtern, sondern auch ausgehende. Es kann sein, dass Sie externe Maschinen nur über die Ports 22 und 80 (SSH und Web) erreichen. Die Lösung hier ist es, eine SSH-Verbindung zu einer Maschine außerhalb der Firewall aufzumachen und durch diese zum gewünschten Dienst 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: ******* In diesem Beispiel benutzt ein Ogg Vorbis Client localhost und Port 8888. Die Verbindung wird dann zu music.example.com Port 8000 weitergeleitet. Die Firewall wurde somit erfolgreich umgangen. Die Option <varname>AllowUsers</varname> Es ist in der Regel ein gute Idee, festzulegen, welche Benutzer sich von welchem Rechner aus anmelden können. Dies lässt sich beispielsweise über die Option 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.32 Damit sich admin von jedem Rechner aus anmelden kann, geben Sie nur den Benutzernamen an: AllowUsers admin Sie können auch mehrere Benutzer in einer Zeile aufführen: AllowUsers root@192.168.1.32 admin Nur Benutzer, die in dieser Liste aufgeführt ist, dürfen 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 reload Weiterführende Informationen OpenSSH &man.ssh.1; &man.scp.1; &man.ssh-keygen.1; &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5; für Client Optionen. &man.sshd.8; &man.sftp-server.8; &man.sshd.config.5; für Server Optionen. Zugriffskontrolllisten für Dateisysteme TomRhodesBeigetragen von ACL Zugriffskontrolllisten (Access Control Lists, ACL) erweitern die normalen Zugriffsrechte von &unix; Systemen auf eine kompatible (&posix;.1e) Weise und bieten feiner granulierte Sicherheitsmechanismen. Der GENERIC-Kernel von &os; bietet ACL-Unterstützung für UFS-Dateisysteme. Benutzer, die es vorziehen einen eigenen Kernel zu übersetzen, müssen die folgende Option in die Kernelkonfigurationsdatei aufnehmen: options UFS_ACL 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. 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. 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 Optionen in /etc/fstab oder Namensänderungen der Geräte, immer aktiv. Dies verhindert auch, dass Zugriffskontrolllisten aus Versehen auf Dateisystemen 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_html In diesem Beispiel sind die Verzeichnisse directory1, directory2 und directory3 durch Zugriffskontrolllisten geschützt, wohingegen das Verzeichnis public_html nicht geschützt ist. Zugriffskontrolllisten benutzen Das 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 test Die 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::--- test Mit 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. Sicherheitsprobleme in Software Dritter überwachen TomRhodesBeigetragen von portaudit In den letzten Jahren wurden zahlreiche Verbesserungen in der Einschätzung und dem Umgang mit Sicherheitsproblemen erzielt. Die Gefahr von Einbrüchen in ein System wird aber immer größer, da Softwarepakete von Dritten auf nahezu jedem Betriebssystem installiert und konfiguriert werden. 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 ports-mgmt/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 clean Wä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 -Fda Die Datenbank wird automatisch aktualisiert, wenn &man.periodic.8; ausgeführt wird. Der eben genannte Befehl ist daher optional, er wird aber für das folgende Beispiel benötigt. 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 -a Existiert 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. &os; Sicherheitshinweise TomRhodesBeigesteuert von &os; Sicherheitshinweise Wie für andere hochwertige Betriebssysteme auch werden für &os; Sicherheitshinweise herausgegeben. Die Hinweise werden gewöhnlich auf den Sicherheits-Mailinglisten und in den Errata veröffentlicht, nachdem das Sicherheitsproblem behoben ist. Dieser Abschnitt beschreibt den Umgang mit den Sicherheitshinweisen. Wie sieht ein Sicherheitshinweis aus? &os; Sicherheitshinweise haben das folgende Format: ============================================================================= FreeBSD-SA-XX:XX.UTIL Security Advisory The FreeBSD Project Topic: denial of service due to some problem Category: core Module: sys Announced: 2003-09-23 Credits: Person 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. References Das 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 &man.ident.1; 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 Subversion-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. Prozess-Überwachung TomRhodesBeigetragen von Prozess-Überwachung Prozess-Ü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 einen Einbruchsversuch bis an den Anfang zurückverfolgen kann. Von Nachteil ist allerdings, dass durch diesen Prozess Unmengen an Protokolldateien erzeugt werden, die auch dementsprechenden Plattenplatz benötigen. Dieser Abschnitt beschreibt die Grundlagen der Prozess-Überwachung. Die Prozess-Überwachung aktivieren und konfigurieren Bevor Sie die Prozess-Überwachung verwenden können, müssen Sie diese über die folgenden Befehle aktivieren: &prompt.root; touch /var/account/acct &prompt.root; chmod 600 /var/account/acct &prompt.root; accton /var/account/acct &prompt.root; echo 'accounting_enable="YES"' >> /etc/rc.conf Einmal 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 und können über &man.sa.8; aufgerufen werden. Ohne Optionen gibt &man.sa.8; Informationen wie die Anzahl der Aufrufe pro Anwender, die abgelaufene Zeit in Minuten, die gesamte CPU- und Anwenderzeit in Minuten und die durchschnittliche Anzahl der Ein- und Ausgabeoperationen aus. Um Informationen über ausgeführte Befehle zu erhalten, verwenden Sie &man.lastcomm.1;. So können Sie etwa ermitteln, welche Befehle von wem auf welchem &man.ttys.5; ausgeführt wurden. Dieses Beispiel zeigt die Nutzung von &man.ls.1; durch trhodes auf dem Terminal ttyp1: &prompt.root; lastcomm ls trhodes ttyp1 Zahlreiche weitere nützliche Optionen finden Sie &man.lastcomm.1;, &man.acct.5; sowie &man.sa.8;. Einschränkung von Ressourcen Tom Rhodes Beigetragen von Ressourcen einschränken Seit Jahren benutzt &os; die Datenbank /etc/login.conf um Ressourcen zu beschränken. Obwohl dies immer noch unterstützt wird, ist es nicht die optimale Methode um die Beschränkung von Ressourcen zu steuern, da Benutzer in verschiedene Gruppen (Login-Klassen) aufgeteilt werden müssen und bei Änderungen immer die Datei und die Passwortdatenbank bearbeitet werden muss. Möglicherweise benötigt ein eingeschränkter Benutzer eine zusätzliche Klasse, dann müsste die Datenbank mit cap_mkdb neu gebaut werden und /etc/master.passwd müsste ebenfalls bearbeitet werden. Zusätzlich müsste die Passwortdatenbank mit pwd_mkdb neu gebaut werden. Dieser Prozess kann sehr zeitaufwendig sein, abhängig davon, wie viele Benutzer bearbeitet werden müssen. Mit &man.rctl.8; können Ressourcen für Benutzer sehr detailliert gesteuert werden. Die Befehl unterstützt nicht nur die Kontrolle der Ressourcen für Benutzer, sondern auch die Beschränkung auf Prozesse, Jails und den ursprünglichen Login-Klassen. Diese erweiterten Funktionen bieten Administratoren und Benutzern die Möglichkeit, Ressourcen über die Kommandozeile oder über eine Konfigurationsdatei zu steuern. Um diese Eigenschaft zu aktivieren, fügen Sie folgende Zeile in die Kernelkonfigurationsdatei: options RACCT options RCTL Das System muss nun neu übersetzt werden. Dieser Vorgang wird in beschrieben. Anschließend kann rctl benutzt werden, um die Regeln für das System festzulegen. Die Syntax der Regeln ist einfach und wird durch subject, subject-id, resource und action gesteuert. Hier ein Beispiel für eine Regel: user:trhodes:maxproc:deny=10/user Diese Regel zeigt den grundlegenden Aufbau, hier mit dem Subjekt user und der Subjekt-ID trhodes. maxproc definiert die Anzahl der Prozesse. Die Aktion deny verhindert, dass neue Prozesse erstellt werden. Im vorherigen Beispiel wurde für den Benutzer trhodes eine Beschränkung von 10 (zehn) Prozessen konfiguriert. Es sind noch weitere Aktionen verfügbar, beispielsweise die Protokollierung auf der Konsole, Benachrichtigungen an &man.devd.8; oder das Senden eines SIGTERM an einen Prozess. Beim hinzufügen von Regeln müssen einige Dinge beachtet werden. Das obige Beispiel würde den Benutzer sogar daran hindern, einfachste Dinge zu tun, nachdem er sich anmeldet und eine screen Sitzung gestartet hat. Sobald die Begrenzung für eine Ressource erreicht ist, wird folgende Meldung ausgegeben: &prompt.root; man test /usr/bin/man: Cannot fork: Resource temporarily unavailable eval: Cannot fork: Resource temporarily unavailable &man.rctl.8; kann auch benutzt werden, um einer Jail eine Speichergrenze zuzuweisen. Eine solche Regel könnte wie folgt festgelegt werden: &prompt.root; rctl -a jail:httpd:memoryuse:deny=2G/jail Damit die Regeln auch nach einem Neustart erhalten bleiben, müssen sie in /etc/rctl.conf hinzugefügt werden. Dazu schreiben Sie einfach die Regel, ohne das vorhergehende Kommando. Zum Beispiel: # Block jail from using more than 2G memory: jail:httpd:memoryuse:deny=2G/jail Mit rctl können auch Regeln entfernt werden: &prompt.root; rctl -r user:trhodes:maxproc:deny=10/user Die Manualpage zeigt auch eine Möglichkeit, alle Regeln zu entfernen. Falls es erforderlich ist alle Regeln für einen einzelnen Benutzer zu entfernen, kann dieser Befehl verwendet werden: &prompt.root; rctl -r user:trhodes Es gibt noch viele weitere Ressourcen, die verwendet werden können, um zusätzliche subjects zu kontrollieren. Weitere Informationen zu diesem Thema finden Sie in &man.rctl.8;.