- zweistufige Zertifikatinfrastruktur unter Linux - Konfiguration und Installation unter Verwendung von Debian GNU/Linux

Transkript

1 - - Konfiguration und Installation unter Verwendung von Debian GNU/ Version vom:

2 Inhaltsverzeichnis Seite 2 von Allgemeines Abbildungsverzeichnis Tabellenverzeichnis Quellcodeverzeichnis Voraussetzungen Beispielhafte Festplattenaufteilung Benötigte Verzeichnisstruktur Installation des Grundsystems Nutzerpakete (Tasksel) Nachträgliche Aktualisierung / Einrichtung der Onlinequellen Installation erforderlicher Softwarepakete Einrichtung und Verwendung von OpenSSL Benötigte Infrastruktur anlegen Erstellung der openssl.conf Datei Erstellung eines RootCA Zertifikats Erstellung des Server ICA Zertifikats Erstellung des User ICA Zertifikats Erstellung eines Computerzertifikats Besonderheiten bei Zertifikaten für SOC Geräte Erstellung von CRL-Dateien am Beispiel der RootCA Rückruf von Zertifikaten Installation ausgestellter Zertifikate Installation der gesamten Zertifikatskette unter Windows Installation der Zertifikatskette unter am Beispiel von Debian Installation des Computerzertifikats unter Absicherung des Systems Konfiguration der in integrierten Firewall Anhang openssl.conf... 14

3 Seite 3 von Allgemeines Dieses Dokument soll als eine einfache Anleitung zur Einrichtung einer zweistufigen Zertifikatinfrastruktur unter Debian GNU/ dienen. Mit ihrer Hilfe wird es möglich sein, sowohl Computerzertifikate (zum Beispiel für die Verwendung in Webservern) und auch Benutzerzertifikate (zum Beispiel für die verschlüsselung) auszustellen Abbildungsverzeichnis Abbildung 1 Benötigte Verzeichnisstrukur Abbildung 2 Nutzerpakete (Tasksel) Abbildung 3 Statistik Zeitabweichung (ntp) 1.2. Tabellenverzeichnis Tabelle 1 Partitionsaufteilung 1.3. Quellcodeverzeichnis Beispielcode 1 /etc/apt/sources.list Beispielcode 2 /etc/npt.conf Beispielcode 3 /etc/iptables.conf Beispielcode 4 /etc/ip6tables.conf Beispielcode 5 /etc/rc.local Beispielcode 6 /CertServer/openssl.conf

4 Seite 4 von Voraussetzungen Dieses Dokument setzt ein gewisses Grundwissen im Umgang und der Konfiguration des -Betriebssystems voraus, um sowohl die Basisinstallation des Systems durchführen zu können, als auch um die Möglichkeit zur Behebung möglicher auftretender Fehler zu haben. Die Installation und Konfiguration wird unter Verwendung von Debian GNU/ in der Version 7.0 (Wheezy) beschrieben, kann aber auch mit geringen Modifikationen unter jedem anderen - oder Unix-Betriebssystem angewendet werden. Als Hardwareumgebung diente bei der Erstellung dieser Anleitung ein i586 VIA Eden System mit einer 1,0GHz CPU, 512MB RAM und einer Festplattenkapazität von 5GB. Eine Netzanbindung ist für die Installation des Systems zwingend erforderlich, im weiteren Betrieb sollte diese aber abgesichert, oder sogar aus Sicherheitsgründen auf dessen Verwendung ganz verzichtet werden Beispielhafte Festplattenaufteilung Auf eine Aufteilung der einzelnen Verzeichnisse (/boot, /home, /var, /log, /tmp) wird verzichtet, da dieses System einzig zur Verwaltung der Zertifikatinfrastruktur eingesetzt wird. Folgende Partitionierung der 5GB Festplatte findet Verwendung. Partition Typ Größe Mountpoint sda1 primär (ext4) 4 GiB (4096 MiB) / sda2 primär (swap) Rest (ca. 0,9 GB) Swap Tabelle 1 Partitionsaufteilung 2.2. Benötigte Verzeichnisstruktur Für eine erfolgreiche Einrichtung einer Zertifikatinfrastruktur, und der Erstellung und Verwaltung dieser Zertifikate ist es erforderlich, eine gewisse Verzeichnisstruktur zu generieren. Abbildung 1 zeigt die benötigte Verzeichnisstruktur und die darin zwingend notwendigen Dateien. Abbildung 1 Benötigte Verzeichnisstrukur

5 Seite 5 von Installation des Grundsystems Die Installation eines Debian GNU/ Basisbetriebssystems mittels Netzwerkinstallation dauert, je nach vorhandener System- und Netzwerkgeschwindigkeit durchschnittlich zwischen 20 und 35 Minuten. Während des Installationsprozesses werden mehrere Konfigurationseinstellungen abgefragt, darunter zum Beispiel die Festplattenpartitionierung, der Computername, die Nutzerpasswörter und auch mögliche Nutzerpakete (Tasksel) Nutzerpakete (Tasksel) Ein wichtiges Merkmal einer kleinen, schnellen und vor allem sicheren installation ist es, dass nur solche Software (Pakete) installiert wird, welche notwendig ist. Während der Installation des Basissystems bietet die Installationsroutine die Möglichkeit zur Installation gewisser Userpakete (zum Beispiel grafische Oberfläche, File-Server, Apache Web-Server, Ssh-Server) schon während der Grundinstallation an. Um die Sicherheit dieses Zertifikats-Servers so hoch wie möglich zu halten, wird dazu geraten, auf die Installation jeglicher Pakete innerhalb dieses Installationsschrittes zu verzichten (siehe Abbildung 2 Nutzerpakete (Tasksel)). Mögliche benötigte Pakete für die weitere Verwendung des Systems, wie zum Beispiel die Ssh-Server Funktionalität können dann nachträglich mittels des systemeigenen Paketverwaltungstools installiert werden. Abbildung 2 Nutzerpakete (Tasksel) Sind alle Installationsschritte beendet, ist es notwendig, das System neu zu starten Nachträgliche Aktualisierung / Einrichtung der Onlinequellen Sofern zur Installation nicht schon auf die Möglichkeit der Netzwerkinstallation (Businesscard- / Netzwerkinstall- Image) zurückgegriffen wurde, sollte nach erfolgreicher Installation des Systems eine Aktualisierung mittels der Onlinequellen des Debian Projekts durchgeführt werden. Hierfür sollte während der Grundinstallation schon eine mögliche Paketquelle des Debian Projekts eingerichtet worden sein. Ist dies nicht der Fall, kann dies mittels manueller Anpassung der Datei /etc/apt/sources.lst nachgeholt werden. Mit Hilfe der nachfolgenden Konfiguration ist eine erfolgreiche Aktualisierung des Systems möglich. Dies allerdings zu Lasten der Netzwerkgeschwindigkeit, da eine Aktualisierung mit den Quellen in Schweden durchgeführt wird. Eine ausführliche Liste möglicher Spiegelserver ist auf der Webseite des Debian Projekts unter zu finden. 01 deb wheezy main 02 deb-src wheezy main deb wheezy/updates main 05 deb-src wheezy/updates main Beispielcode 1 /etc/apt/sources.list

6 Seite 6 von Installation erforderlicher Softwarepakete Ist die Aktualisierung des Grundsystems abgeschlossen, können weitere benötigte Softwarepakete installiert werden. Soll das System im weiteren Verlauf auch weiterhin über das Netzwerk erreichbar sein, ist es ratsam zusätzlich zum OpenSSL Paket die Softwarepakete OpenSSH-Server und NTP zu installieren. Durch die Installation des OpenSSH-Server Pakets wird es ermöglicht, das System von einem anderen entfernten PC aus mittels Secure Shell-Verbindung zu verwalten, bei Bedarf Konfigurationsänderungen durchzuführen und auch benötigte Datenübertragungen durchzuführen. Nach erfolgreicher Installation des OpenSSH-Server Pakets mittels des Befehls sudo apt-get install openssh-server ist keine weitere nachfolgende Konfiguration erforderlich. Das System ist ab sofort mittels Secure Shell über das Netzwerk erreichbar. Um die Systemzeit des Zertifikatservers im Gleichklang mit allen weiteren Systemen zu halten, sollte das NTP Paket installiert werden. Mit Hilfe dieses Pakets ist es möglich, die lokale Systemzeit mit Zeitservern im Internet, oder falls vorhanden, einem lokalen Zeitserver abzugleichen. Nach erfolgreicher Installation, durchgeführt mittels des Befehls sudo apt-get install ntp, ist es erforderlich, die Konfigurationsdatei entsprechend den Bedürfnissen anzupassen. Eine relativ aktuelle Liste möglicher öffentlicher Zeitserver ist auf der Internetseite vorhanden. 01 driftfile /var/lib/ntp/ntp.drift server #ptbtime1.ptb.de 04 server #ptbtime2.ptb.de 05 server 0.de.pool.ntp.org #bessere Alternative falls DNS-Auflösung funktioniert 06 server 1.de.pool.ntp.org 07 server 0.europe.pool.ntp.org 08 # diese Zeilen nur aktivieren, falls allen Systemen im lokalen Netz vertraut wird (z.b. Firmennetzwerk) 09 #disable auth 10 #broadcastclient Beispielcode 2 /etc/npt.conf Dass die Zeitaktualisierung funktioniert und mit welchen Servern sich das System aktualisiert kann mittels des Befehls ntpq p angezeigt werden. Abbildung 3 Statistik Zeitabweichung (ntp) Das eigentlich wichtige Paket auf diesem System stellt das OpenSSL Paket dar. Mit dessen Hilfe werden im Folgenden die benötigten Benutzer- und Computerzertifikate erstellt. Die Installation dieses Pakets erfolgt ähnlich wie auch schon die vorhergehenden Softwarepakete mittels des Befehls sudo apt-get install openssl. Alle für dieses Paket erforderlichen Konfigurationsanpassungen werden im folgenden Kapitel erläutert.

7 Seite 7 von Einrichtung und Verwendung von OpenSSL Sind alle nutzerspezifischen Softwarepakete installiert, kann nun die Verzeichnisstruktur, die benötigten Dateien und die entsprechenden Nutzerberechtigungen eingerichtet werden Benötigte Infrastruktur anlegen Wie in der Abbildung 1 Benötigte Verzeichnisstrukur dargestellt, sollte zwecks der einfacheren Verwaltbarkeit der Zertifikate eine gewisse Verzeichnisstruktur angelegt werden. Mit den folgenden Befehlen ist dies relativ einfach möglich. mkdir pv /CertServer/{RootCA,ServerICA,UserICA} mkdir pv /CertServer/RootCA/{certs,crl,newcerts} mkdir pv /CertServer/ServerICA/{certs,crl,newcerts} mkdir pv /CertServer/UserICA/{certs,crl,newcerts} Sind alle Verzeichnisse angelegt, kann mit der Erstellung der benötigten Dateien fortgefahren werden. touch /CertServer/{RootCA/RCAindex,ServerICA/SICAindex,UserICA/UICAindex,openssl.conf} echo 00 > /CertServer/RootCA/RCAserial echo 01 > /CertServer/ServerICA/SICAserial echo 01 > /CertServer/UserICA/UICAserial Nach Erstellung der Verzeichnisstrukur und dem Anlegen aller benötigten Dateien, sollte aus Sicherheitsgründen die Berechtigung auf alle Verzeichnisse, darin bereits enthaltene und zukünftige Dateien dahingehend geändert werden, dass nur ein spezieller Benutzer Zugriff auf diese Verzeichnisstruktur erhält. chmod 1006 /CertServer -R 4.2. Erstellung der openssl.conf Datei Nach der Erstellung der Datei /CertServer/openssl.conf im vorherigen Abschnitt, ist es nun erforderlich, die benötigten Einträge der Datei hinzuzufügen. Eine beispielhafte Datei /CertServer/openssl.conf ist im Kapitel 7.1. openssl.conf auf Seite 14 zu finden. Die OpenSSL Konfigurationsdatei ist zwecks unterschiedlicher Anwendungsbereiche / Zertifikatstypen auch in verschiedene Bereiche aufgeteilt, welche durch einen in eckigen Klammern ([]) gesetzten Begriff definiert werden. Der erste Abschnitt [ca] (Zeile 01-02) definiert, welcher Zertifikatstyp ausgestellt werden soll, falls während des Aufrufs des Zertifikaterstellungsbefehls kein Zertifikatstyp angegeben wird. Die Abschnitte zwei bis vier [Root_CA] (Zeilen 05-29), [Server_CA] (Zeilen 32-53) und [User_CA] (Zeilen 56-77) definieren, welche Einstellungen und Vorgaben Verwendung finden, wenn Zertifikate durch die jeweiligen ausstellenden Zertifikatsserver ausgestellt werden. Die Abschnitte fünf und sechs [policy_match] (Zeilen 80-87)und [policy_anything] (Zeilen 89-96) legen fest, welche Orts- und Personenangaben in den jeweiligen Zertifikatstypen wie angegeben werden müssen. In diesem Fall sind die Einstellungen gleich. Abschnitte sieben bis neun [req] (Zeilen ), [req_distinguished_name] (Zeilen ) und [req_attributes] (Zeilen ) legen die Einstellungen und Vorgaben fest, welche bei der Erstellung eines selbstsignierten RootCA Zertifikats Anwendung finden. Die Bereiche zehn bis dreizehn [RCA_ext] (Zeilen ), [SCA_ext] (Zeilen ), [UCA_ext] (Zeilen ) und [v3_ca] (Zeilen ) definieren die Zertifikatserweiterungen für die Zertifikate, welche von den jeweiligen Zertifikatsservern ausgestellt werden. Der Bereich [v3_ca] dient hierbei zur Definierung der Einstellungen für das RootCA Zertifikat selbst. Der letzte Bereich [crl_ext] (Zeilen ) legt die Einstellungen für die Erstellung von CRLs fest. Eine unter lesbare Version der hier verwendeten openssl.conf Datei steht unter zum Download zur Verfügung.

8 Seite 8 von Erstellung eines RootCA Zertifikats Die folgenden Schritte sind für die Erstellung eines selbstsignierten RootCA Zertifikats erforderlich: Generierung des privaten Schlüssels: openssl genrsa aes256 out /CertServer/RootCA/RCAkey.pem 4096 Selbstsignierung des RootCA Zertifikats openssl req new x509 days 3652 extensions v3_ca key /CertServer/RootCA/RCAkey.pem out /CertServer/RootCA/RCAcert.pem config /CertServer/openssl.conf Generierung einer.crt Datei für den Export openssl x509 in /CertServer/RootCA/RCAcert.pem out /CertServer/RootCA/RCAcert.crt Kopieren der erstellten Dateien in das Archivverzeichnis cp /CertServer/RootCA/RCA* /CertServer/RootCA/certs/ Erstellung des Server ICA Zertifikats Auch für die Erstellung des Server ICA Zertifikats sind drei (/vier) Schritte erforderlich: Generierung des privaten Schlüssels und des Zertifikatrequests openssl req newkey rsa:2048 keyout /CertServer/ServerICA/SICAkey.pem out /CertServer/ServerICA/SICAreq.pem config /CertServer/openssl.conf Signierung des Zertifikatrequests durch die RootCA openssl ca name Root_CA keyfile /CertServer/RootCA/RCAkey.pem in /CertServer/ServerICA/SICAreq.pem out /CertServer/ServerICA/SICAcert.pem outdir /CertServer/RootCA/certs config /CertServer/openssl.conf Generierung einer.crt Datei für den Export openssl x509 in /CertServer/ServerICA/SICAcert.pem out /CertServer/ServerICA/SICAcert.crt Kopieren der erstellten Dateien in das Archivverzeichnis cp /CertServer/ServerICA/SICA* /CertServer/RootCA/certs/ Erstellung des User ICA Zertifikats Die Erstellung des Zertifikats für die User ICA ähnelt der Erstellung für die Server ICA fast zu 100 Prozent. Einzig die Verzeichnisse und die Dateinamen unterscheiden sich. Generierung des privaten Schlüssels und des Zertifikatrequests openssl req newkey rsa:2048 keyout /CertServer/UserICA/UICAkey.pem out /CertServer/UserICA/UICAreq.pem config /CertServer/openssl.conf Signierung des Zertifikatrequests durch die RootCA openssl ca name Root_CA keyfile /CertServer/RootCA/RCAkey.pem in /CertServer/UserICA/UICAreq.pem out /CertServer/UserICA/UICAcert.pem outdir /CertServer/RootCA/certs config /CertServer/openssl.conf Generierung einer.crt Datei für den Export openssl x509 in /CertServer/UserICA/UICAcert.pem out /CertServer/UserICA/UICAcert.crt Kopieren der erstellten Dateien in das Archivverzeichnis cp /CertServer/UserICA/UICA* /CertServer/RootCA/certs/. Nach Erstellung der drei Zertifikatserver Zertifikats und der dazugehörigen privaten Schlüssel sollte dafür gesorgt werden, dass die privaten Schlüssel nicht in falsche Hände geraten, da unter Zuhilfenahme der jeweiligen

9 Seite 9 von 17 Partnerdateien ab Sofort alle weiteren Zertifikate erstellt werden und auch Repliken der existierenden Zertifikate angefertigt werden können.. Aus Sicherheitsgründen sollten die jeweiligen beiden Teile auf ein, von diesem System unabhängigem Medium, zum Beispiel ein hardwareverschlüsselter USB-Stick, gespeichert werden um im Falle eines Schadens an diesem System noch Zugriff auf die Zertifikatinfrastruktur zu haben Erstellung eines Computerzertifikats Bei der Erstellung eines Computerzertifikats ist darauf zu achten, dass der Antragsteller in diesem Fall nicht eine natürliche Person mit einem Vor- und Zunamen ist, sondern der Computer mit seinem voll qualifiziertem Computernamen. Im Falle eines Web-Servers ist dies dann die vollständige Web-Adresse, unter der das System zu erreichen ist. Beispiele: Zertifikat für TestPC zur Kommunikationsverschlüsselung: TestPC.testdom.loc Zertifikat für die https auf dem Webserver Generierung des privaten Schlüssels und des Zertifikatrequests openssl req newkey rsa:1024 keyout /CertServer/ServerICA/newcerts/CompCertkey.pem out /CertServer/ServerICA/newcerts/CompCertreq.pem config /CertServer/openssl.conf Signierung des Zertifikatrequests durch die RootCA openssl ca name Server_CA keyfile /CertServer/ServerICA/SICAkey.pem in /CertServer/ServerICA/newcerts/CompCertreq.pem out /CertServer/ServerICA/newcerts/CompCertcert.pem outdir /CertServer/ServerICA/certs config /CertServer/openssl.conf Generierung einer.crt Datei für den Export openssl x509 in /CertServer/ServerICA/newcerts/CompCertcert.pem out /CertServer/UserICA/newcerts/CompCertcert.crt Zertifikat und Schlüssel zur Installation unter Windows kombinieren openssl pkca12 export inkey /CertServer/ServerICA/newcerts/CompCertkey.pem in /CertServer/ServerICA/newcerts/CompCertcert.pem name Computerzertifikat out /CertServer/ServerICA/newcerts/CompCertcert.p12 Kopieren der erstellten Dateien in das Archivverzeichnis cp /CertServer/ServerICA/SICA/newcerts/* /CertServer/ServerICA/SICA/certs/ Besonderheiten bei Zertifikaten für SOC Geräte Da die meisten SOC Geräte die Installation von Zertifikaten ermöglichen (z.b. WLAN AccessPoints, Router, Switche, VPN-Endpunkte), aber bei der Installation der Zertifikate es nicht ermöglichen nach dem Password des privaten Schlüssels zu fragen, ist eine Entfernung des Passworts erforderlich. Entfernen der Passphrase aus dem privaten Schlüssel openssl rsa in /CertServer/ServerICA/newcerts/CompCertkey.pem out /CertServer/ServerICA/newcerts/CompCertkey_wo_password.pem Kombinieren des Zertifikats mit dem privaten Schlüssel ohne Passwort cp /CertServer/ServerICA/newcerts/ComCertcert.crt /CertServer/ServerICA/newcerts/CompCertcert_wo_password.crt cat /CertServer/ServerICA/newcerts/CompCertkey_wo_password.pem >> /CertServer/ServerICA/newcerts/CompCertcert_wo_password.crt

10 Seite 10 von Erstellung von CRL-Dateien am Beispiel der RootCA Die Erstellung der CRL-Dateien der unterschiedlichen Zertifikatserver unterscheidet sich einzig in den Verzeichnissen und den Dateinamen. Generierung einer CRL-Datei openssl ca gencrl keyfile /CertServer/RootCA/RCAkey.pem cert /CertServer/RootCA/RCAcert.pem out /CertServer/RootCA/crl/RCAcrl.pem config /CertServer/openssl.conf Generierung einer.crt Datei für den Export (DER Format) openssl crl in /CertServer/RootCA/crl/RCAcrl.pem outform der out /CertServer/RootCA/crl/RCAcrlDER.crt Generierung einer.crl Datei für den Export (Plain text) openssl crl in /CertServer/RootCA/crl/RCAcrl.pem out /CertServer/RootCA/crl/RCAcrl.crl text Es ist erforderlich, dass die neu erstellten CRL-Dateien nach deren Erstellung unverzüglich an den dafür vorgesehenen Platz im Netzwerk (siehe openssl.conf Datei Zeilen 139, 154 und 168) mit den definierten Dateinamen kopiert werden. Hierdurch wird die Möglichkeit gegeben, bei der Kontrolle der Zertifikate zu kontrollieren, ob diese auch noch Gültigkeit besitzen Rückruf von Zertifikaten Manchmal ist es erforderlich, kompromittierte, verlorene, oder einfach nicht mehr benötigte Zertifikate zurückzuziehen. Da die Löschung des privaten Schlüssels nicht die Gültigkeit des Zertifikats beendet, ist es erforderlich, das Gültigkeitsende eines Zertifikats auch in der Zertifikatinfrastruktur und damit auch allen Kontrollstellen mitzuteilen. Mit dem folgenden Befehl wir dies bewerkstelligt: openssl ca revoke /CertServer/ServerICA/certs/ComCertcrt.pem keyfile /CertServer/ServerICA/SICAkey.pem cert /CertServer/ServerICA/SICAcert.pem Nach erfolgtem Rückruf eines oder mehrerer Zertifikate ist es erforderlich, die dem Zertifikatserver entsprechende CRL-Datei neu zu generieren und zu publizieren (siehe Erstellung von CRL-Dateien am Beispiel der RootCA).

11 Seite 11 von Installation ausgestellter Zertifikate 5.1. Installation der gesamten Zertifikatskette unter Windows Die Installation eines erstellten Computerzertifikats und der dazugehörigen Zertifikatskette (RootCA, ServerICA und Computerzertifikat) gestaltet sich unter Windows relativ einfach. Folgende Schritte sind hierfür unter einem administrativen Konto erforderlich: - Aufruf der MMC - Hinzufügen des Zertifikat SnapIns (Computerkonto) - Import der RCAcert.crt Datei unter dem Verzeichnis Vertrauenswürdige Stammzertifizierungsstellen - Import der SICAcert.crt Datei unter dem Verzeichnis Zwischenzertifizierungsstellen - Import der CompCertcrt.p12 Datei unter Eigene Zertifikate Ähnlich ist auch bei der Installation eines Benutzerzertifikats zu verfahren. Allerdings ist hier die Anmeldung unter dem jeweiligen Benutzer erforderlich. - Aufruf der MMC - Hinzufügen des Zertifikat SnapIns (Userkonto) - Import der RCAcert.crt Datei unter dem Verzeichnis Vertrauenswürdige Stammzertifizierungsstellen - Import der SICAcert.crt Datei unter dem Verzeichnis Zwischenzertifizierungsstellen - Import der CompCertcrt.p12 Datei unter Eigene Zertifikate 5.2. Installation der Zertifikatskette unter am Beispiel von Debian Die Installation der Zertifikatskette unter gestaltet sich ähnlich einfach, wie schon unter Windows. Folgende Schritte sind erforderlich: - Erstellung eines aussagekräftigen Verzeichnisses unter /usr/share/ca-certificates (zum Beispiel Domainname) - Speicherung der Zertifikatsdateien (nur.crt Dateien) der Zertifikatsstellen in diesem Verzeichnis - Mittels dpkg-reconfigure ca-certificates die Zertifikate im System registrieren 5.3. Installation des Computerzertifikats unter Die Installation eines Computerzertifikats unter gestaltet sich dahingehend als schwierig, dass es keine zentrale Installationsstelle gibt, wie beispielsweise unter Windows. Unter ist es erforderlich, das Computerzertifikat für jede einzelne Verwendung jeweils separat zu registrieren, wodurch hier keine einheitliche Anleitung dazu gegeben werden kann.

12 Seite 12 von Absicherung des Systems Sind alle Pakete installiert und die wichtigsten Zertifikate erstellt, wird es erforderlich, dieses System gegen unerlaubten Zugriff abzusichern. Die einfachste und sicherste Methode ist sicherlich, die Desaktivierung der Netzwerkverbindung. Allerdings wird hierdurch auch die Schwierigkeit zur Erstellung und zum Austausch von Zertifikaten erhöht. Die elegantere Methode der Absicherung des Systems ist die Vorschaltung einer Hardware-Firewall, oder die Aktivierung der in integrierten Firewall. Die Vorschaltung einer Hardware-Firewall ist auf Grund der hohen Kosten allerdings zu überdenken Konfiguration der in integrierten Firewall Die Einrichtung der in integrierten Firewall, iptables genannt, ist unter Debian 7.0 relativ einfach möglich, da die hierfür benötigten Kernel-Module schon standardmäßig aktiv sind. Einzig die Konfigurationsdateien, jeweils eine für den IPv4-Verkehr und den IPv6-Verkehr, müssen erstellt und der Aufruf dieser Konfigurationsdateien zum Systemstart muss eingerichtet werden. 01 *filter 02 :INPUT ACCEPT [0:0] 03 :FORWARD ACCEPT [0:0] 04 :OUTPUT ACCEPT [0:0] 05 A INPUT i lo j ACCEPT 06 A INPUT m conntrack --ctstate RELATED,ESTABLISHED j ACCEPT 07 A INPUT p tcp m TCP --dport 22 j ACCEPT 08 A INPUT p icmp m icmp --icmp-type 8 j ACCEPT 09 A INPUT j DROP 10 COMMIT Beispielcode 3 /etc/iptables.conf 01 *filter 02 :INPUT ACCEPT [0:0] 03 :FORWARD ACCEPT [0:0] 04 :OUTPUT ACCEPT [0:0] 05 A INPUT i lo j ACCEPT 06 A INPUT m rt --rt-type 0 j REJECT 07 A INPUT p icmpv6 j ACCEPT 08 A INPUT m state --state RELATED,ESTABLISHED j ACCEPT 09 A INPUT m state --state INVALID j DROP 10 A INPUT p tcp m tcp --dport 22 j ACCEPT 11 A INPUT j DROP 12 A OUTPUT m rt --rt-type 0 j REJECT 13 A OUTPUT j ACCEPT 14 A FORWARD m rt --rt-type 0 j REJECT 15 A FORWARD j REJECT 16 COMMIT Beispielcode 4 /etc/ip6tables.conf Beide Konfigurationsdateien beschränken den Zugriff auf das System auf das Nötigste. Das System wird weiterhin per PING und per SSH-Verbindung erreichbar sein. Alle weiteren Verbindungsversuche werden ohne jegliche Reaktion verworfen ( A INPUT j DROP). Es ist mit der Verwendung eines Kernels >= 2.6 anzuraten, beide Dateien zu erstellen und auch zu verwenden, da ab Kernel-Version 2.6 automatisch die IPv6-Adressunterstützung aktiviert ist. Auch wenn das System keine IPv6-Adresse manuell konfiguriert bekommt, ist das System trotz alledem über die selbstkonfigurierte link lokale IPv6-Adresse (FE80:.) aus dem lokalen Netzwerk erreichbar und kann somit kompromittiert werden. Der Aufruf beider Konfigurationsdateien während des Systemstarts kann dann mittels Zeilen in der /etc/rc.local Datei erfolgen. Bei der Bearbeitung der rc.local Datei ist zu beachten, dass die vorhandene Datei editiert werden sollte anstatt sie zu überschreiben, da es sich bei der rc.local Datei um eine ausführbare Scriptdatei handelt.

13 Seite 13 von iptables-restore < /etc/iptables.conf 02 ip6tables-restore < /etc/ip6tables.conf clear 10 exit 0 Beispielcode 5 /etc/rc.local Nach erfolgreicher Erstellung beider Konfigurationsdateien und der Anpassung der rc.local Datei ist es ratsam, das System neu zu starten, um die erfolgreiche Aktivierung der Änderungen zu kontrollieren. Mit den folgenden Befehlen kann relativ einfach kontrolliert werden, ob die oben definierten Regeln auch aktiviert wurden. Sollte die definierten Regeln nach Eingabe der Befehle nicht dargestellt werden, ist die Aktivierung nicht erfolgt und eine Suche nach den Gründen wird erforderlich. sudo iptables-save sudo ip6tables-save

14 Seite 14 von Anhang 7.1. openssl.conf 01 [ca] 02 default_ca = Server_CA # Der Standardpart, falls nicht anders ausgewählt 03 #################################################################### [Root_CA] # Abschnitt zur Verwendung auf einer Root CA 06 Dir = /CertServer/RootCA # Hier wird alles gespeichert 07 Certs = $dir/certs # Hier werden die ausg. Zertifikate gespeichert 08 crl_dir = $dir/crl # Hier werden die CRLs gespeichert 09 database = $dir/rcaindex # Dies ist die Index-Datenbankdatei 10 new_certs_dir = $dir/newcerts # Hier werden die neuen Zertifikate gespeichert Certificate = $dir/rcacert.pem # Das RootCA Zertifikat 13 Serial = $dir/rcaserial # Dies ist die Seriennummern-Datenbankdatei 14 Crl = $dir/crl/crl.pem # Die aktuelle CRL-Datei 15 private_key = $dir/rcakey.pem # Der private Schluessel zum RootCA Zertifikat 16 RANDFILE = $ENV::HOME/.rnd x509_extensions = RCA_ext # Die Erweiterungen zu diesem Zertifikatstyp default_days = 1826 # Die Zertifikatslaufzeit in Tagen 21 default_crl_days = 730 # Die Gueltigkeit der CRL-Datei in Tagen 22 default_md = sha1 # Zu verwendender Verschluesselungsalgorithmus 23 Preserve = no # Policy = policy_match 26 _in_dn = no # Die Adr. nicht dem Distinguished Name hinzuf. 27 name_opt = ca_default # 28 cert_opt = ca_default # 29 copy_extensions = none # 30 ###################################################################### [Server_CA] # Abschnitt zur Verwendung auf einer Server ICA 33 Dir = /CertServer/ServerICA # Hier wird alles gespeichert 34 Certs = $dir/certs # Hier werden die ausg. Zertifikate gespeichert 35 crl_dir = $dir/crl # Hier werden die CRLs gespeichert 36 database = $dir/sicaindex # Dies ist die Index-Datenbankdatei 37 new_certs_dir = $dir/newcerts # Hier werden die neuen Zertifikate gespeichert Certificate = $dir/sicacert.pem # Das ServerICA Zertifikat 40 Serial = $dir/sicaserial # Dies ist die Seriennummern-Datenbankdatei 41 Crl = $dir/crl.pem # Die aktuelle CRL-Datei 42 private_key = $dir/sicakey.pem # Der private Schluessel zum ServerICA Zertifikat 43 RANDFILE = $ENV::HOME/.rnd x509_extensions = SCA_ext # Die Erweiterungen zu diesem Zertifikatstyp default_days = 731 # Die Zertifikatslaufzeit in Tagen 48 default_crl_days = 365 # Die Gueltigkeit der CRL-Datei in Tagen 49 default_md = sha1 # Zu verwendender Verschluesselungsalgorithmus 50 Preserve = no # Policy = policy_anything 53 _in_dn = no # Die Adr. nicht dem Distinguished Name hinzuf. 54 ###################################################################### 55

15 Seite 15 von [User_CA] # Abschnitt zur Verwendung auf einer User ICA 57 Dir = /CertServer/UserICA # Hier wird alles gespeichert 58 Certs = $dir/certs # Hier werden die ausg. Zertifikate gespeichert 59 crl_dir = $dir/crl # Hier werden die CRLs gespeichert 60 database = $dir/uicaindex # Dies ist die Index-Datenbankdatei 61 new_certs_dir = $dir/newcerts # Hier werden die neuen Zertifikate gespeichert Certificate = $dir/uicacert.pem # Das ServerICA Zertifikat 64 Serial = $dir/uicaserial # Dies ist die Seriennummern-Datenbankdatei 65 Crl = $dir/crl.pem # Die aktuelle CRL-Datei 66 private_key = $dir/uicakey.pem # Der private Schluessel zum UserICA Zertifikat 67 RANDFILE = $ENV::HOME/.rnd x509_extensions = UCA_ext # Die Erweiterungen zu diesem Zertifikatstyp default_days = 731 # Die Zertifikatslaufzeit in Tagen 72 default_crl_days = 365 # Die Gueltigkeit der CRL-Datei in Tagen 73 default_md = sha1 # Zu verwendender Verschluesselungsalgorithmus 74 Preserve = no # Policy = policy_anything 77 emain_on_dn = no # Die Adr. nicht dem Distinguished Name hinzuf. 78 ###################################################################### [policy_match] 81 countryname = match 82 #stateorprovincename = optional 83 #localityname = optional 84 organizationname = supplied 85 #organizationalunitname = optional 86 commonname = supplied 87 address = optional [policy_anything] 90 countryname = match 91 #stateorprovincename = optional 92 #localityname = optional 93 organizationname = supplied 94 #organizationalunitname = optional 95 commonname = supplied 96 address = optional 97 #################################################################### [req] # Abschnitt zur Erstellung eines RootCA Zertifikats 100 default_bits = default_keyfile = privkey.pem 102 distinguished_name = req_distinguished_name 103 attributes = req_attributes 104 x509_extensions = v3_ca # Die Erweiterungen zu diesem Zertifikatstyp 105 ###################################################################### [req_distinguished_name] 108 countryname = Laendercode (2 Buchstaben-Code) 109 countryname_default = DE 110 countryname_min = countryname_max = #stateorprovincename = Bundesland /-staat oder Provinzname (voller Name) 113 #stateorprovincename_default = Nordrhein-Westfalen 114 #localityname = Ortsname 115 #localityname_default = Muelheim an der Ruhr 116 organizationname = Organisationsname / Firmenname

16 Seite 16 von organizationname_default = privat 118 #organizationalunitname = Organisationsbereich / Firmenabteilung 119 #organizationalunitname_default = Studis 120 commonname = Name des Antragsstellers (Personenname) 121 commonname_max = address = Adresse 123 address_max = ###################################################################### [req_attributes] 127 challengepassword = Passwort falls Zertifikatsrueckruf erforderlich (Authentifizierung) 128 challengepassword_min = challengepassword_max = unstructuredname = z.b. ein optionaler Firmenname / Adresse, ###################################################################### [RCA_ext] # Abschnitt fuer die Erweiterungen des durch die RootCA ausgestellten Zertifikats 134 basicconstraints = critical, CA:TRUE 135 keyusage = crlsign, keycertsign 136 subjectkeyidentifier = hash 137 authoritykeyidentifier = keyid,issuer:always 138 subjectaltname = copy 138 issueraltname = issuer:copy 139 crldistributionpoints = URI: 140 nscerttype = sslca, ca, objca 141 nsbaseurl = nscomment = This certificate is an Issuing CA certificate 143 ###################################################################### [SCA_ext] # Abschnitt fuer die Erweiterungen des durch die ServerICA ausgestellten Zertifikats 146 #basicconstraints = critical, CA:FALSE 147 keyusage = digitalsignature, keyencipherment 148 #extendedkeyusage = serverauth, clientauth 149 subjectkeyidentifier = hash 150 authoritykeyidentifier = keyid,issuer:always 151 subjectaltname = copy 152 #issueraltname = DNS:test.dyndns.org 153 issueraltname = issuer:copy 154 crldistributionpoints = URI: 155 nscerttype = server 156 nsbaseurl = #nscapolicyurl = nscomment = This certificate is a Server certificate 159 ###################################################################### [UCA_ext] # Abschnitt fuer die Erweiterungen des durch die UserICA ausgestellten Zertifikats 162 #basicconstraints = critical, CA:FALSE 163 keyusage = digitalsignature, keyenciphermen, keyagreement 164 subjectkeyidentifier = hash 165 authoritykeyidentifier = keyid,issuer:always 166 subjectaltname = copy 167 issueraltname = issuer:copy 168 crldistributionpoints = URI: 169 nscerttype = client, 170 nsbaseurl = #nscapolicyurl = nscomment = This certificate is a User certificate 173 ###################################################################### [v3_ca] # Abschnitt fuer die Erweiterungen des selbstsignierten Zertifikats (Erstellung RootCA) 176 basicconstraints = critical, CA:TRUE

17 Seite 17 von subjectkeyidentifier = hash 178 authoritykeyidentifier = keyid:always,issuer:always 179 keyusage = crlsign, keycertsign 180 nscerttype = sslca, ca, objca 181 subjectaltname = copy 182 issueraltname = issuer:copy 183 crldistributionpoints = URI: 184 nsbaseurl = nscomment = This certificate is a Root CA Certificate 186 ###################################################################### [crl_ext] # Abschnitt fuer die Erstellung von CRLs 189 issueraltname = issuer:copy 190 authoritykeyidentifier = keyid:always,issuer:always Beispielcode 6 /CertServer/openssl.conf