Hier ein kurzes Video zum Thema
Windows Live Mail SSL Verschlüsselung bei IMAP
Telekom: Windows Live Mail SSL Verschlüsselung bei IMAP weiterlesen
Archiv für den Monat: Mai 2014
Web-Zertifikat erstellen und installieren
Ziel dieses Beitrags: Mit Boardmitteln unter Debian eine eigene CA (Certificate Authority), also eine Zertifizierungsstelle erstellen sowie ein selbstzertifiziertes Serverzertifikat erstellen und einbinden.
Nachteil: Der einzige Unterschied zu einem von einer anerkannten Stelle signierten Zertifikat ist, dass der Client (Emailprogramm, Browser, etc.) eine Warnung ausgeben wird, dass er die CA nicht kennt. Der Benutzer muss dann einmal bestätigen und kann das Zertifikat trotzdem akzeptieren.
Alternative: Zertifikat von einer anerkannten Zertifizierungsstelle einsetzen. Ein Beitrag hierzu ist in Vorbereitung.
1. OpenSSL
Für die Verwaltung der Zertifikate und für die Verschlüsselung der Verbindungen mit SSL und TLS kommt unter Linux fast immer OpenSSL zum Einsatz. In der Regel ist openssl bereits installiert. Wenn nicht, muss das Paket openssl nachinstalliert werden. Aus diesem Paket wird der Kommandozeilenbefehl openssl benötigt.
2. Erstellen der CA
Verzeichnis für das Zertifikat anlegen. z. B. /root/ca:
|
1 2 |
root@mail:# mkdir /root/ca root@mail:# cd /root/ca |
2.1 Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird.
|
1 |
root@mail:~/ca# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650 |
Die Laufzeit wird hier mit 10 Jahren (3650 Tagen) bewusst hoch gewählt.
Das CA-Zertifikat wird nach cacert.pem geschrieben. Der vorstehende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit. Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Die Passphrase, welche beim Erstellen abgefragt wird sollte daher sehr sicher gewählt werden. Bei jedem Signieren eines anderen Zertifikats wird diese Passphrase benötigt. Es sollte sichergestellt werden, dass der Private-Key (ENCRYPTED PRIVATE KEY) cakey.pem ausschließlich zum Signieren anderer Zertifikate verwendet wird. Dieser Key ist der sensibelste Teil einer CA-Infrastruktur.Das Root-CA Zertifikat wird ausschlieslich zum Signieren von anderen Zertifikaten benötigt! Als nächstes Daten eingeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, bitte einen Punkt eingeben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen. Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA einfach eigenen Namen eintragen. Prüfen, ob die die beiden Dateien cacert.pem und cakey.pem im gewählten Verzeichnis /root/ca entstanden sind.
2.2 Die Rechte aus Sicherheitsgründen so setzen, dass die Schlüsseldatei nur für root lesbar ist:
|
1 |
root@mail:~/ca#root@linux# chmod 600 cakey.pem |
2.3 Testen, ob der Schlüssel mit der Passphrase wieder geöffnet werden kann.
|
1 |
root@mail:~/ca# openssl rsa -in cakey.pem -noout -text |
3. Schlüssel für das Serverzertifikat erzeugen
Nachdem die eigene CA steht, kann diese für den Server ein Zertifikat herausgeben. Dazu erzeugt man/frau zunächst einen 2048 Bit langen RSA Schlüssel serverkey.pem (RSA PRIVATE KEY), der mit AES 128 verschlüsselt auf der Platte abgelegt wird (auch hier wieder ein verschlüsselter Schlüssel). Die Passphrase muss diesmal nicht sonderlich geheim sein, da wir sie ohnehin im Anschluss wieder entfernen werden. OpenSSL lässt allerdings keine leere Phrase zu:
|
1 |
root@mail:~/ca# openssl genrsa -out serverkey.pem -aes128 2048 -days 3650 |
Diese Passphrase wird wieder entfernt, damit der Serverdienst (z. B. Apache) den Schlüssel bei jedem Booten des Servers ohne Passworteingabe verarbeiten kann.
|
1 |
root@mail:~/ca# openssl rsa -in serverkey.pem -out serverkey.pem |
4. Certificate Signing Request erzeugen
Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Eingaben nötig, die genau wie zum Erstellen der CA benötigt werden.
|
1 |
root@mail:~/ca# openssl req -new -key serverkey.pem -out req.pem -nodes |
Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu z. B. sommer-wg.de verwendet, so muss der Common Name eben genau sommer-wg.de heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren.
Die Option A challenge password kann man/frau leer lassen. Es sind nuch in /root/ca/ inzwischn 4 Dateien vorhanden. Der CSR (Zertifikats-Request) liegt jetzt in der Datei req.pem und kann von der CA anschliessend signiert werden.
5. OpenSSL-Konfiguration anpassen
Weitere Einstellungen muss man in der Datei /etc/ssl/openssl.cnf ändern, bevor man signieren kann. Datei openssl.cnf öffnen und folgende Zeilen in der Sektion [CA_default ] anpassen:
|
1 2 3 4 5 |
dir = . # Where everything is kept new_certs_dir = $dir # default place for new certs private_key = $dir/cakey.pem # The private key RANDFILE = $dir/.rand # private random number file default_days = 3650 # how long to certify for |
Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an.
Nun muss man/frau noch einige Dateien anlegen:
|
1 2 |
root@mail:~/ca# echo 01 > serial root@mail:~/ca# touch index.txt |
6. Serverzertifikat signieren
Endspurt: Eigene CA signiert das gewünschte Server-Zertifikat:
|
1 |
root@mail:~/ca# openssl ca -in req.pem -notext -out servercert.pem |
7. Zertifikatsdaten anzeigen
7.1 Die Details eines Zertifikates können mit Hilfe des folgenden Befehls angezeigt werden:
|
1 |
root@mail:~/ca# openssl x509 -in servercert.pem -noout -text |
7.2 Zertifikat in PKCS#12 (pfx) konvertieren:
|
1 |
root@mail:~/ca# openssl pkcs12 -nokeys -in servercert.pem -export -out servercert.pfx -name "NAME" |
8. Zertifikate installieren
Web-Server, Vorbemerkung: Einen VirtualHost für den Port 443 darf es aus technischen Gründen nur einmal geben, da z. B. Apache für diesen Port nur ein einziges SSL-Zertifikat ausliefern kann. Es ist also nicht möglich, die Adressen https://www.meinepage1.de und https://www.meinepage2.de über den selben Apache ausliefern zu lassen. Nur unter Verwendung einer zusätzlichen IP-Nummer (und anschließender Anpassung der Listen-Direktiven) ist sowas u. U, möglich.
8.1 Publikation des Root-CA Zertifikats
Vorstehend wurde ein Zertifikat mit einem zugehörigen Private-Key erzeugt. Das Zertifikat ist für den Zeitraum von 10 Jahren gültig. Nochmal: Es sollte sichergestellt werden, dass der Private-Key ausschließlich zum Signieren anderer Zertifikate verwendet wird. Dieser Key ist der sensibelste Teil einer CA-Infrastruktur. Der Zertifikatteil (public Key) dieses Paares wird den Clients (Browsern) zur Verfügung gestellt. Die Clients können die Gültigkeit von Zertifikaten, die mit diesem Private-Key signiert wurden, mit Hilfe des Root-CA Zertifikats (cacert.pem) verifizieren.
Zuerst müssen alle für die Verifizierung durch Browser unnötigen Informationen aus dem Zertifikat entfernt werden:
|
1 |
root@mail:~/ca# openssl x509 -in cacert.pem -out cacert.crt |
Dieses Zertifikat kann auf der Website publiziert werden. Der Webserver sollte einen MIME Eintrag für .crt Files konfiguriert haben. Das Modul mod_ssl in Apache, erwartet, dass das conf-Verzeichnis eine zusätzliche Konfigurationsdatei namens ssl.conf enthält …
|
1 2 3 4 |
<IfModule mod_ssl.c> AddType application/x-x509 -cacert.crt AddType application/x-pkcs7 -cacrl.crl </IfModule> |
… in Bearbeitung
Jetzt können sich die Clients das Zertifikat herunterladen und im Browser installieren. Wenn dieses erfolgt ist, akzeptiert der Browser alle Zertifikate, die mit dem zugehörigen Root-CA Key signiert wurden.
Quellen: openssl.org, Wikipedia, Sascha Kersten, Christian Piazzi,
Debian GNU/Linux Anwenderhandbuch von Frank Ronneburg
(CC BY-NC-ND 3.0 DE)
Neuen vServer von Server4You auf aktuellen Debian- und Plesk-Stand updaten
vServer vom Discounter sind extrem preiswert geworden, z. B. kostet der vServer Pro X5 von Server4You für das erste Jahr schlappe 82,18 €. Das sind somit nur 6,85 € pro Monat und das ist meiner Meinung für einen quasi dedizierten Server sehr preiswert.
Die Hardwareausstattung kann man/frau hier nachlesen. Zahlreiche Features wie z. B. Reverse DNS, Backup, Snapshot, Firewall, 3 feste IPs, Plesk bis 10 Domains etc. sind bereits enthalten. Überbuchungen konnte ich in diesen ersten Wochen nicht beobachten oder feststellen. Meine Erfahrungen mit dem Ticket-Support sind überwiegend sehr gut. Nervig bei S4Y ist allerdings das sehr oft zickige Powerpanel.
Solche vServer haben aber oft den Nachteil, dass meistens veraltete Templates seitens des Discounters zum Einsatz kommen. So hatte mein im April 2014 erstinstallierter vServer noch Debian 6.0x squeeze und Plesk 11.0x drauf.
Die aktuelle Debian Version ist 7.5 wheezy und die aktuelle Panelversion von Plesk ist zz. 11.5.30 Mit wenigen Stunden Zeit und Geduld kann man den vServer jedoch auf den neusten Debian und Plesk-Stand korrigieren.
Nachfolgend möchte ich an einem Beispiel die mögliche Vorgehensweise exemplarisch für einen frischen und leeren vServer von z. B. S4Y beschreiben.
1. Restore
Bitte beachten Sie das bei einem Restore eine auswählbare Neuinstallation des vSERVERs stattfindet und alle Daten verloren gehen. Bitte Plesk-Lizenz vorher über PowerPanel Software sichern.
1.1 Im Powerpanel von S4Y einen Restore anfordern
1.2 man/frau erhält dann einen Restore Code per Mail
1.3 Über das Powerpanel die Minimale Debian Installation ausführen
1.4 Über Putty und ssh als root anmelden
1.5 ggf. den Midnight Commander (mc) installieren und konfigurieren
apt-get install mc
1.7 Update und Upgrade durchführen
> apt-get update
> apt-get upgrade
1.8 z.B. mc als Editor wählen
1.9 Debian Version anzeigen
> cat /etc/issue
> Debian GNU/Linux 6.0 \n \l
2. Debian Upgrade
2.1 Über Putty und ssh als root anmelden
2.2 z. B. über mc -x navigieren
> etc/apt/sources.list
2.3 Editiere source.list
Ersetze squeeze durch wheezy und speichern!
2.4 Update und Upgrade durchführen
> apt-get update
> apt-get upgrade
2.4 Kernel Upgrade
Für amd64-based (64 bit) systems:
> apt-get install linux-image-2.6-amd64
ODER i686 (32 bit) systems:
> apt-get install linux-image-2.6-686
Bitte nur das eine ODER das andere ausführen!
2.5 ggf. udev installieren
> apt-get install udev
2.6 Reboot auslösen
2.7 Über Putty und ssh als root anmelden
2.8 distupgrade
> apt-get dist-upgrade
Das dauert etwas … 😉
Fragen beantworten mit Default-Werten!
2.9 Reboot auslösen
2.10 Über Putty und ssh als root anmelden
2.11 Update und Upgrade durchführen
> apt-get update
> apt-get upgrade
2.12 Reboot
2.13 Über Putty und ssh als root anmelden
2.14 Debian Version anzeigen
> cat /etc/issue
> Debian GNU/Linux 7 \n \l
3. Plesk Upgrade
Voraussetzungen: Linux muss/darf nur mit einer Minimalinstallation vorhanden sein!
3.1 Über Putty und smcsh als root anmelden
3.2 z. B. über mc -x navigieren
> etc/apt/sources.list
3.3 Editiere source.list
Füge folgenden Eintrag hinzu
https://ftp.de.debian.org/debian wheezy main non-free
3.4 Update und Upgrade durchführen
> apt-get update
> apt-get upgrade
Falls Fehlermeldung auftreten, diese zwingend korrigieren
3.6 Anlegen eines Installationsverzeichnisse /var/install/plesk z. B. via mc -x und MKDIR
/var/install/plesk
3.7 Mit cd zum gerade angelegten Installationsverzeichnis navigieren
> cd /var/install/plesk
3.8 Autoinstaller von Parallels herunterladen
> wget https://autoinstall.plesk.com/plesk-installer
3.9 Rechte anpassen
> chmod +x plesk-installer
3.10 Plesk Installation starten
> ./plesk-installer
Das dauert etwas … 😉
Fragen beantwortemc -xn Default-Werten!
3.11 Reboot auslösen
3.12 Über Putty und ssh als root anmelden
3.13 Update und Upgrade durchführen
> apt-get update
> apt-get upgrade
3.14 Reboot
3.15 Im Browser an Plesk anmelden
https://servername:8443
Login: root
Kennwort rootpassword
Fragen beantworten!
Im Zweifels erst denken, dann antworten 😉
3.16 Plesk-Lizenz einspielen (siehe Punkt 1.)
Plesk-Lizenz für 10 Domainen bei Server4You ggf. anfordern
3.17 Firewall härten
Härtung in Abhängigkeit und Wechselwirkung von Punkt 4 vornehmen.
4. Grundabsicherung, Härtung
Eins der ersten Dinge, die man bei einem Rootserver machen sollte ist, dem User root das einloggen über SSH zu verbieten.
4.1 SSH verbieten
4.11 Editiere sshd_config
> /etc/ssh/sshd_config
Port 22 ändern auf z. B. 22922
4.12 SSH-Dienst neu starten
> /etc/init.d/ssh restart
4.2 SSH sicherer einrichten
4.21 Einen neuen User erstellt man/frau mit folgendem Befehl:
> useradd -g users -d /home/user4711 -s /bin/bash user4711
Hier wird ein User namens user4711 in der Gruppe users mit der Bash als Standartshell angelegt. Das Homeverzeichnis des Users liegt in /home/user4711
(Dieses Verzeichnis muss z. B. über mc -x und MKDIR manuell angelegt werden!)
4.22 Der User hat bis jetzt aber noch kein Passwort.
Das Passwort kann man mit dem „passwd“ Befehl ändern.
Als root kann man auch das Passwort für andere User ändern:
> passwd user4711
> Enter new Password:#!pwR§4711!#
Hier sollte man/frau auch darauf achten, das man kein zu einfaches Passwort wählt. Also es sollte mindestens 8 Zeichen haben, Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen beinhalten.
4.23 Den neuen User mit einem weiteren Putty Login in einem zweiten Fenster testen.
4.3 root login sperren
4.31 root das einloggen verbieten
zur Datei sshd_Config navigieren
/etc/ssh/sshd_config
4.32 Zeile wie folgt ändern
von
PermitRootLogin yes
auf
PermitRootLogin no
4.33 SSH Daemon Config neu laden:
> /etc/init.d/ssh reload
4.34 Danach sollte man/frau sich mit root nichtmehr einloggen können.
4.35 Switch User su
Ab jetzt loggt man/frau sich einfach mit dem angelegten User ein und loggt sich über den Switch User Befehl als root ein:
> su
5. Benachrichtigung bei SSH Login
5.1 Login-Script erstellen
Mit folgendem Skript erhält man eine E-Mail, sobald sich ein Benutzer per SSH einloggt. Erstelle dazu ein ausführbares Shell Skript /opt/shell-login.sh mit folgendem Inhalt:
|
1 2 3 4 5 |
#!/bin/bash echo "Login auf $(hostname) am $(date +%Y-%m-%d) um $(date +%H:%M)" echo "Benutzer: $USER" echo finger |
Damit die Mails beim Login versendet werden, muss folgende Zeile
|
1 |
/opt/shell-login.sh | mailx -s "SSH Login auf SERVERNAME" mail@beispiel.de |
in der Datei /etc/profile eingetragen werden.
Die Datei /opt/shell-login.sh muss die Rechte 755 besitzen:
> chmod 755 /opt/shell-login.sh
Die Mail wird nun automatisch versendet, sobald sich ein Benutzer per SSH einloggt. Der User bekommt davon nichts mit.
5.2 Das Programm finger ggf. nachinstallieren und testen
> apt-get install finger
> apt-get update
> apt-get upgrade
> finger
5.3 Brute Force Attacken abwehren
5.31 auth.log
In der Log-Datei /var/log/auth.log kann man möglicherweise fehlgeschlagene Loginversuche mit dem Protokoll SSH auf spüren, die nicht von Ihnen stammen.
5.32 fail2ban ist ein in Python geschriebenes Programm, welches verschiedene Serverdienste gegen unbefugten Zugriff absichern kann. Zur Abwehr also auf Debian das Programm fail2ban installieren:
> apt-get install fail2ban
> apt-get update
> apt-get upgrade
5.33 fail2ban konfigurieren
Editiere /etc/fail2ban/jail.conf wie folgt
ignoreip = 127.0.0.1
bantime = 3600
maxretry = 3
Erforderlichen Parameter um den SSH Dämon zu überwachen:
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 4
In vorstehende Konfiguration für Fail2Ban wird eine IP Adresse für 1 Stunde gesperrt, nachdem von dieser 4 fehlgeschlagene Anmeldeversuche für SSH stattgefunden haben.
5.34 Restart fail2ban
/etc/init.d/fail2ban restart
5.4 Weitere Sicherheitshinweise, Artikel, Tutorials …
Rootkits mit rkhunter aufspüren
ssh-Zertifikate
etc.