OpenSSL und Zertifikate

Transkript

1 Grundpraktikum für IT-Sicherheit Material zum Praktikumsversuch OpenSSL und Zertifikate Zusammengestellt von: Andre Adelsbach, Marc Erdmann Lehrstuhl für Netz- und Datensicherheit ruhr-universität bochum Der Versuch findet im NDS-Netzlabor (Raum IC 4/58) statt. Seite 1 von 5

2 1. Einleitung OpenSSL[1] eine freie Implementierung des SSL Protokolls, das sichere Ende-zu-Ende Verbindungen herstellen kann und auf der Transportschicht arbeitet. In diesem Versuch wird ein Webserver mit OpenSSL gegen Abhören der Kommunikation und unbefugten Zugriff gesichert. 2. Szenario Sie sind der IT-Verantwortliche eines Zulieferbetriebes. Ihr Auftraggeber möchte in Zukunft alle Bestellungen komfortabel über das Internet abwickelt. Die Geschäftsführung hat bereits eingelenkt und es liegt nun an Ihnen, eine sichere online-business-umgebung zu schaffen. Gleichzeitig stellt auch Ihr Zulieferbetrieb sein Bestellwesen auf eine Internet-basierte Lösung um, die Sie natürlich testen müssen. 3. Technischer Rahmen Ihnen steht ein Rechner unter SuSE Linux 9.1 zur Verfügung auf dem die benötigten Softwarepakete bereits installiert sind. Als Webserver kommt Apache (Version 2.0) zum Einsatz. Die verschiedenen Möglichkeiten der Zugriffskontrolle sind auf der Website [2] des Apache Projects dokumentiert. Besonders empfehlenswert für die Versuchsdurchführung sind [3] und [4]. Ein einfaches Bestellformular existiert bereits auf den Rechnern und muss nicht von ihnen implementiert werden. Als Browser soll Firefox verwendet werden. 4. Versuchsdurchführung Voraussetzungen für die Teilnahme Grundlagenkenntnisse bei der Bedienung von grafischen und Text-basierten Linux-Systemen. Die Versuchsanleitung muss gelesen und verstanden werden. Ferner müssen Sie die Kontrollfragen beantworten können. Zum besseren Verständnis ist es hilfreich, die angegebenen Links anzuschauen. Eventuelle Nachfragen können gleich zu Beginn des Versuchs geklärt werden. Machen Sie sich mit den benötigten Tools vertraut, damit Sie die erforderlichen Kommandos beherrschen. Auswertung Die Versuchsauswertung sollte die Beantwortung der Fragen zur Vorbereitung enthalten und alle von Ihnen vorgenommenen Änderungen an Konfigurationen enthalten. Dokumentieren Sie auch Ihren Lösungsweg einschließlich möglicherweise entstandener Fehler und Ihre Diagnose. Ferner sollten Sie mindestens jeweils ein Beispiel einer mitgeschnittenen unverschlüsselten und verschlüsselten HTTP Verbindung dem Protokoll beifügen und kommentieren. Dazu können Sie die entsprechenden Export-Funktionen von Ethereal verwenden. 5. Vorgehen Teil 1 Implementieren sie zunächst einen nicht verschlüsselten Kennwortschutz für das Webinterface. Richten sie für ihre Nachbargruppe ein Benutzerkonto ein, mit dem Bestellungen simuliert werden Seite 2 von 5

3 können. Das Bestellsystem ist im Verzeichnis /srv/www/htdocs/shop installiert. Legen Sie in diesem Ordner eine Datei mit dem Namen.htaccess wie in [3], Abschnitt Getting it working beschrieben. Es soll nur eine Person Zugriff haben, für die Sie einen Account anlegen müssen. Verwenden Sie das Kommando htpasswd2 auf der Shell. Eine Anleitung für diesen Befehl finden Sie unter [5]. Hinweis: Nach jeder Änderung der Apache-Konfiguration muss der Dienst mit dem Befehl /etc/init.d/apache2 restart neugestartet werden; zur Fehlerdiagnose hilfreich sind die Logfiles, die sich in dem Verzeichnis /var/log/apache2 befinden. Überprüfen Sie, ob sie von einem Client aus über den Webbrowser sicherheitsrelevante Daten vom Server abfragen können (siehe auch Aufgabe zur Vorbereitung 3). Versuchen sie dann, die Bestellvorgänge einer anderen Gruppe abzuhören und deren Eingaben (insbesondere das Kennwort) zu dokumentieren. Sie können den Netzwerksniffer Ethereal[6] durch Eingabe des Kommandos ethereal von der Shell aus starten. Machen Sie sich mit Hilfe des Netzwerkplanes klar, von welchem Rechner die Gruppe, die Sie abhören möchten, welchen Rechner kontaktiert. Durch einen geeigneten Filter können Sie die Ausgabe übersichtlicher gestalten. Mit tcp.dstport == 80 and ip.src == werden zum Beispiel die Pakete aller HTTP-Verbindung angezeigt, die vom Rechner PC111 ausgehen. Passen Sie den Filter an Ihre Anforderungen an. Durchsuchen Sie die Pakete nach den vertraulichen Daten! Da die Rechner in einem Subnetz des Netzlabors über einen HUB miteinander verbunden sind, benötigen Sie keinerlei weitere Angriffstools, um die Verbindungen der anderen Gruppen mitschneiden zu können. Teil 2 Hinweis: HTTPS-Verbindungen nutzen den Zielport 443. Laden Sie das Stammzertifikat des Netzlabors vom Certification Authority Server (grundsätzliches zu SSL siehe [7]) herunter und importieren Sie es in den Webbrowser. Achten Sie dabei darauf, dass der Fingerprint des heruntergeladenen Zertifikats mit dem ausgehängten Zertifikat übereinstimmt und dokumentieren sie dies. Erzeugen Sie mit Hilfe der CA auf dem Server des Netzlabors ein Zertifikat für Ihren Server und konfigurieren Sie Apache so, dass das Webinterface per HTTPS zugänglich ist. Greifen Sie mit Ihrem Webbrowser (Firefox!) auf die Adresse PC111.netz1.test zu und wählen Sie Certification Authority. Laden Sie das Zertifikat, es wird automatisch im Browser installiert. Füllen sie das Formular für den Certificate Signing Request geeignet aus. Der Common Name muss dem vollen DNS-Namen Ihres Rechners entsprechen (hostname.netz.test). Diesen können Sie dem Netzwerkplan entnehmen. Das Zertifikat wird beim Download automatisch im Browser gespeichert. Sie können es über das Menü (Edit > Preferences > Advanced > Certificates) mit der Funktion Backup in eine Datei exportieren. Mit dem einzugebenen Kennwort wird die Datei verschlüsselt. Das Zertifikat wird zusammen mit dem privaten Schlüssel im PKCS#12 Format gespeichert und mit dem eingegebenen Kennwort verschlüsselt. Der Webserver benötigt die Daten jedoch im PEM Format. Mit openssl pkcs12 erfolgt die Konvertierung [8]. Der Webserver Apache wird durch die Konfigurationsdateien in /etc/apache2 verwaltet. Kopieren Sie den Teil aus der PEM-kodierten Datei, der den Schlüssel des Webservers enthält in den Unterordner ssl.key (Dateinamen frei wählbar) und das Zertifikat selbst in ssl.crt (Dateinamen frei wählbar). Der virtuelle Server mit SSL Unterstützung muss in vhosts.d definiert werden; orientieren Sie sich an der Beispiel-Konfiguration in der Datei /etc/apache2/vhosts.d/vhostssl.template. Seite 3 von 5

4 Hinweis: Nur Konfigurationsdateien mit der Endung.conf sind aktiv! Hinweis: Bei SuSE ist es notwendig, in der Datei /etc/sysconfig/apache2 den Eintrag APACHE_SERVER_FLAGS um -DSSL zu ergänzen. Dokumentieren Sie Ihre Konfigurationsänderungen und dass ein Abhören der Verbindungen nun nicht mehr möglich ist (ethereal). Teil 3 (optional) Statt einer Authentifikation mittels Benutzername und Kennwort, kann man die Identität eines berechtigten Anwenders auch mit Hilfe eines Zertifikats festellen. Dabei wird ein definiertes Paar aus Zertifikat und privatem Schlüssel im Browser gespeichert. Bei Ihnen ist dies bereits beim ersten Schritt von Teil 2 geschehen. Modifizieren Sie nun Ihre Apache-Konfiguration so, dass nur Browser, die ein von der Netzlabor CA unterschriebenes Zertifikat vorweisen können, auf das Bestellsystem zugreifen können. Der Teil des Webservers, der für HTTPS-Anfragen zuständig ist, wurde in /etc/apache2/vhosts.d/ konfiguriert. Kopieren Sie das Zertifikat der Netzlabor CA (es wird natürlich benötigt, um berechtigte Nutzer als solche zu identifizieren) in den Ordner /etc/apache2. Setzen Sie dann den Parameter SSLCACertificateFile mit dem Pfad und Dateinamen zum Zertifikat der CA in der Konfiguration Ihres SSL-fähigen VHosts. Geben Sie ausserdem SSLVerifyClient none an. Anschließend müssen sie das zu schützende Verzeichnis definieren (<Location /srv/...>) und den Zugang einschränken. SSLVerifyClient require ist die notwenige Direktive für die Zugriffsbeschränkung. Um genau einen Schritt in der Vertrauenskette nach oben zuzulassen, setzen Sie bitte SSLVerifyDepth 1. Nun muss verhindert werden, dass die Seite per HTTP aufgerufen wird. Dies geschieht mit einem Eintrag in /etc/apache2/default-server.conf. Weitere Informationen finden Sie in der Apache Dokumentation[2]. Um den Zugang auf Zertifikate mit bestimmten Subjektnamen einzuschränken, kann die Option FakeBasicAuth des SSL-Moduls mod_ssl verwendet werden. Durch Setzen dieser Option wir der Subject Distinguished Name (DN) des Client-Zertifikats in den Usernamen der HTTP Basic Authorization übersetzt. Dieser Versuchsteil wird nur durchgeführt, wenn noch genug Zeit zur Verfügung steht oder entsprechendes Interesse besteht. 6. Aufgaben zur Vorbereitung Als Vorbereitung sollten Sie die Dokumentation der verwendeten Softwarepackete gelesen haben und folgende Fragen kurz schriftlich beantworten: 1. Erklären Sie kurz die Möglichkeiten, die eine.htaccess Datei bietet. Welche Voraussetzungen müssen dafür in der globalen Apache-Konfigurtion geschaffen werden? 2. Wie wird eine Kennwortdatei für Apache AuthType Basic erstellt? Mit welchem Kommando kann man einen Benutzer hinzufügen? 3. Einige Konfigurationen werden Sie in Dateien wie.htaccess in einem Ordner ablegen, der über das Web zugänglich ist. Überlegen Sie, wie man mit Apache diese Zugriffskonfiguration und die Kennwortdatei mit Hilfe einer globalen Einstellung (in /etc/apache2/httpd.conf) gegen Download schützen kann. 4. Lesen Sie im RFC 2617[9] das Kapitel 2. Wie werden Benutzername und Kennwort bei AuthType Basic übertragen? Seite 4 von 5

5 5. Wie läuft ein SSL Handshake ab? Informationen finden Sie unter [10] im Kapitel The SSL Handshake. 6. Welche Rolle spielt die CA? 7. Welcher Befehl konvertiert ein PKCS#12 Zertifikat / Schlüssel nach PEM? Überlegen Sie, welchen Zweck der Kennwortschutz hat und wie das Kennwort beschaffen sein sollte. Weche Informationen und Daten werden Sie in der konvertierten Datei finden? 8. Was versteht man bei Apache unter Virtual Hosts? 9. Welche Einträge sind in der Apache-Konfiguration erforderlich, um HTTPS zu aktivieren bzw. zu erzwingen? 7. Verweise 1: 2: 3: 4: 5: 6: 7: 8: 9: ftp://ftp.isi.edu/in-notes/rfc2617.txt 10: Seite 5 von 5