Wir haben also einen Rootserver oder VServer und wollen ein Backup nach zuhause einspielen. Zuerst sollte man sich Gedanken machen, ob die Bandbreite dafür ausreicht. Ich habe eine Leitung mit 1000 MBit Downstream und 50 MBit Upstream. Das sollte auch für größere Belange voll ausreichen, da im Wesentlichen der Downstream zählt. Der zu versorgende VServer hat (leider) nur 100 MBit Downstream und ist damit also voll ausgereizt.
Nun ist zu überlegen, wie man vorgehen will, denn es gibt mehrere Möglichkeiten. Ich persönlich habe mich dafür entschieden von meinem QNAP NAS einen OpenVPN Server aufspannen zu lassen, auf den sich dann der Server verbinden kann. Den Speicher habe ich als NFSv4 freigegeben, sodass der Server hier mounten kann. Aus Sicherheitsgründen sollte man beachten, dass für diesen NAS-Zugang ein eigener Account und ein eigener Freigabeordner erstellt wird. Schließlich gibt es für Backupzwecke keinen guten Grund, warum diese Daten einfach verfügbar sein sollten.
Warnung: Ein NFSv4 sollte niemals ins Internet hinein freigegeben werden, da es bei diesem Protokoll arge Sicherheitsbedenken gibt. Schließlich ist NFSv4 für interne Netzwerke konzipiert und hält hohen Sicherheitsanforderungen nicht stand. Das Tunneln über ein VPN ist daher das Mittel der Wahl.
Bedenkt, dass ihr für folgende Schritte in der Regel eine statische IPv4-Adresse benötigt. Fragt ggf. euren Internetprovider. Bei Unitymedia/Vodafone kann man sich diese auf Anfrage z.B. einfach einrichten lassen, wenn man das Komfort-Paket hat.
OpenVPN auf QNAP einrichten
Wir installieren zuerst die App „QVPN Service“ auf unserem QNAP NAS. Dieses konfigurieren wir wie auf dem folgenden Screenshot gezeigt. Wir haben hier als DNS-Server die zensurfreie und offene Variante vom Digitalcourage e.V. (IP 46.182.19.48). Man beachte außerdem, dass die Checkbox „Nutzen Sie diese Verbindung als Standard-Gateway für externe Geräte“ deaktiviert ist. Dies ist erforderlich, damit der Server nicht jeglichen Traffic über das QNAP NAS leitet, was wir bei einem Server idr. nicht haben wollen. Stattdessen werden wie später auf dem Server konfigurieren, dass IP-Adressen des lokalen Netzwerks an eben dieses weitergeleitet werden. Alle anderen Einstellungen können so belassen werden. Wir laden uns noch die Konfigurationsdatei herunter (QVPN v1.1 or newer), weil diese diese später für den Server benötigen.
Nun legen wir einen neuen Freigabeordner an. Dazu gehen wir unter Systemsteuerung → Freigabeordner auf Erstellen → Freigabeordner. Wir geben dem Ordner z.B. den Ordnernamen ServerBackup. Unter Zugangsrechte hat aktuell nur der Benutzer admin Zugriff auf den Freigabeordner. Falls gewünscht, können hier noch weiteren Nutzern der Zugang gewährt werden. Wir werden gleich noch einen separaten Nutzer für unsere Backupzwecke erstellen.
Nun wäre es sinnvoll einen neuen Benutzer mit beschränkten Rechten einzurichten. Für den Fall, dass der Server kompromittiert wird, wäre es sicherlich am Besten den Schaden zu minimieren und nicht das gesamte NAS freizugeben. Ganz nach dem Motto: So wenig Rechte wie möglich, so viele Rechte wie nötig. Gehen wir also unter Benutzer auf Erstellen → Einen Benutzer erstellen. Nennen wir den Benutzer beispielsweise serverbackup und vergeben ein Passwort. Als Benutzergruppe wählen wir everyone. Unter Freigabeordnerrecht setzen wir alle Freigabeordner auf Deny und den Ordner ServerBackup auf RW, damit wir Lese- und Schreibrechte erhalten. Erstellen wir nun den Nutzer.
Sofern das noch nicht passiert ist, müssen wir in der Systemsteuerung den NFS-v4-Dienst aktivieren:
Einrichtung auf dem Server
Das OpenVPN einrichten
Wir müssen zunächst OpenVPN installieren:
sudo apt-get install openvpn
Nun konfigurieren wir das VPN. Dazu legen wir zunächst die Datei /etc/openvpn/passwords.conf an, in der wir in der ersten Zeile unseren Benutzernamen und in der zweiten Zeile unser Passwort ablegen:
serverbackup
unserPasswort123
Nun nehmen wir die zuvor als vom QNAP NAS gespeicherte Konfigurationsdatei für das VPN und legen diese als /etc/openvpn/client.conf ab. Wir müssen diese noch so anpassen, dass Benutzername und Passwort aus unserer Datei ausgelesen werden. Ursprünglich ist es so vorgesehen, dass beim Herstellen der VPN-Verbindung per Prompt nach Benutzername und Passwort gefragt werden. Da wir eine automatisierte Lösung benötigen, müssen wir den Benutzernamen und das Passwort natürlich hinterlegen. Das haben wir bereits getan. Also modifizieren wir die client.conf an der Stelle auth-user-pass wie folgt:
auth-user-pass /etc/openvpn/passwords.conf
Die Datei client.conf sollte nun in etwa wie folgt aussehen:
client
dev tun
script-security 3
remote 42.42.42.42 1194
resolv-retry infinite
nobind
auth-nocache
auth-user-pass /etc/openvpn/passwords.conf
remote-cert-tls server
reneg-sec 0
cipher AES-256-CBC
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-$
float
proto udp
explicit-exit-notify 1
<ca>
...
</ca>
Eine sinnvolle Methode die VPN Verbindung herzustellen, wäre natürlich beim Systemstart. Daher legen wir nun die Datei /etc/init.d/iproute.sh für den init-Prozess an:
!/bin/sh
service openvpn@client start
sleep 30s
ip route add 192.168.178/24 dev tun0
sleep 5s
mount -a
Hier wird erst die VPN-Verbindung hergestellt. Zur Sicherheit warten wir 30 Sekunden. Die interne IP-Adresse meines NAS lautet 192.168.178.46. Daher legen wir das Netz 192.168.178.* auf das VPN um, also auf tun0. Wir warten noch mal 5 Sekunden. Dann mounten wir alle Laufwerke, was insbesondere unser NFSv4 einschließt. Den entsprechenden Eintrag für die fstab besprechen wir gleich.
Wir müssen das Skript noch für den Systemstart verlinken. Dies ist für Runlevel 3 (Multi-User Mode mit Netzwerk) und Runlevel 5 (mit GUI) erforderlich, auch wenn für Server im Regelfall Runlevel 3 reichen würde:
Leider ist es aus meiner persönlichen Erfahrung so, dass die VPN-Verbindung auch mal abbrechen kann und dann nicht wieder erneut aufgebaut wird. Ich habe mich deshalb dafür entschlossen, das Skript zusätzlich per Cronjob auszuführen und zwar jeweils wenige Minuten bevor das Backup erfolgen soll. Wenn wir das Backup z.B. um kurz nach 3:00 Uhr ausführen möchten, können wir die Cronjobdatei /etc/cron.d/openvpn z.B. wie folgt definieren:
0 3 * * * root /etc/init.d/iproute.sh
NFSv4 Filesystem mounten
Um die nötigen Voraussetzungen zu schaffen, müssen wir zuerst nfs-common installieren:
Hierbei ist 192.168.178.46 die lokale IP unseres NAS und ServerBackup der Name unseres Freigabeordners, den wir für das Backup konfiguriert haben. Wir mounten das Ganze nach /mnt/RemoveServerBackup und zwar als nfs-Dateisystem mit Lese- und Schreibrechten (rw).
Nicht vergessen, den Mountpoint auch zu erstellen:
mkdir /mnt/RemoteServerBackup
WordPress Backup einrichten
Wir installieren das Plugin BackWPup und erstellen einen neuen Auftrag. Hier wählen wir unter Allgemein„Backup in Verzeichnis“ und unter Planen stellen wir z.B. täglich um 3:25 Uhr ein. Unter „Ziel: Verzeichnis“ habe ich für meinen Blog z.B. /mnt/RemoteServerBackup/the_digital_native/wordpress/ eingestellt. Da ich noch weitere Backups auf diese Weise erstelle, macht es Sinn einen entsprechenden Unterordner zu wählen.
Konfiguration und Backup testen
Um das Ganze zu testen, stellen wir auf dem Server erst mal testweise die VPN-Verbindung her und mounten das Dateisystem:
service openvpn@client start
ip route add 192.168.178/24 dev tun0
mount -a
Wir gehen nun unter BackWPup in die Liste der Aufträge und wählen für den eben neu erstellten Auftrag Jetzt starten aus. Der Auftrag sollte nun durchlaufen. Nach Abschluss des Auftrags prüfe einfach, ob das entsprechende Backup auf deinem NAS liegt.
So, wir sind fertig! Wir können nun über VPN automatisiert ein WordPress Backup auf unserem QNAP NAS erstellen.
Recently, I had to downgrade my Lenovo Thinkpad P1 Gen 2 BIOS because I recognized some problems recently after a BIOS upgrade. Later it turned out, it was a hardware defect and the recent BIOS update was random. However, I learned something about downgrading the BIOS for recent Lenovo Notebooks an want to share the mistakes I made to save you some time if you have to do so.
Downloading Specific BIOS Versions for your P1: A Challenge
You will quickly find this support page for Drivers & Software for the P1 Gen 2 (Type 20QT, 20QU). Ok, you see the newest BIOS Versions there, currently version 1.34. If we want to have this, simply download BIOS Update Utility (Linux). But how to find any old BIOS versions? You cannot find any here. It turned out that the BIOS versions for the Lenovo X1 Extreme 2nd Gen has exactly the same BIOS, compare the download link of the most recent version for both websites, and surprisingly, the links are the (see here). This makes it very likely that the old BIOS versions match as well and indeed they do! Thus, download the Bios version of your choice for the Lenovo P1 Gen 2 at this page for another laptop.
Why not linking this BIOS versions at the P1 Gen 2 page? I don’t know. Sometime, we cannot understand why Lenovo does things. However, problem solved! Simply download the *.zip file „BIOS Update Utility (Linux)“ of your choice.
Old BIOS versions for the Lenovo P1 on the support page of the Lenovo X1
Finding the Right BIOS Version
After downloading the *.zip file, extract it. There are three files, for version 1.34 these are N2OET47P.cab, N2OET47W.cab and N2OHT35W.cab. You only need one, but the readme contains no information about that. What I have found by try and error: you cannot install N2OET47P.cab, meaning something that ends with P, because there is not supported device found (maybe for Lenovo X1?), N2OHT35W.cab seems to be an older version. And finally you go with N2OET47W.cab. In general, the Version N20ETXXW with XX being the higher number seems to be the version you want to have. If I’m wrong here or someone knows more, please contact me and I will update this article.
Make the BIOS Ready to Install
We need the fwupdmgr to install the *.cab files. Therefore install the following meta-package if not already done:
sudo apt install fwupd
Disconnect your Thunderbold Docking Station now (for good reasons, see below).
Upgrade
We can now push a newer BIOS version by the following command (adapt the filename to your needs):
fwupdmgr install N2OET47W.cab
Downgrade
For a downgrade, we have to force the downgrade with the following command (adapt the filename to your needs):
fwupdmgr install --allow-older N2OET42W.cab
Why Disconnecting the Docking Station
Now, you will be asked if you want to restart the PC, but be careful: be sure that your Thunderbold Docking Station is disconnected. Otherwise, you will run in the same problem as I did: The system reboots, the screen becomes black (both, laptop and external display) and nothing happens (even for 15 minutes). You cannot shut down your PC, even by pressing the power button for more than 10 seconds. Simply a black screen, some heat (you hear the fans) and you cannot power off. My solution was to open up the laptop, disconnecting the battery pack while the laptop was still running and therefore force the laptop to immediately shutdown. This is not nice, but fortunately the BIOS has not been broken and I was able to redo the work. With a disconnected docking station, of course.
On the Way to Finish it
Now, do the restart. The laptop will restart several times. All the work will need some times. Congratulations, you have the BIOS version of your choice! If you want to, reboot into the bios and check everything.
Self-Healing BIOS backup progressing…
For the Interested People: Why I did the Downgrade
By the way, in may case, the docking station had a hardware defect. But recently before the problems occurred, a BIOS update has been performed. Therefore, I had to exclude the possibility that the new BIOS is guilty and therefore I did a BIOS downgrade (with no success). I hope a new Docking Station will be on the way to me soon, as it is a case of warranty. At least, this article is an outcome on the needless BIOS downgrade 😉
Misrepresentations on screen by a defect Thunderbot Docking Station
Final Remarks
I hope I could help you with your issue. If you have some feedback or suggestions about this article, let me know by using the contact form or send me an e-mail. Thank you for reading and have a nice day.
Under several Linux distributions, including Debian and Ubuntu, we have the service command to controll daemons, e.g. service apache2 restart. In this article, we learn how to create a service-command for the standalone version of the SearX meta search engine. We build upon the default installation as prescribed within the quick start guide of the project documentation. We include both, searX and filtron.
Introduction
First we need a possibility to start SearX as a daemon, so we install the daemonize command:
sudo apt-get install daemonize
With daemonize, we can have an error-log, a std-out log and some pid that takes care about having only one instance running. With SearX installed at the default destination /opt/searx, we can execute the following command to start a SearX daemon:
We usually have three options following the service command: service searx start, service searx stop and service searx restart. This results in the following code snippet for the searx.sh file stored at /etc/init.d/searx.sh:
Letzes Update: 25.06.2020 um 21:57 Uhr (Änderungen sindfarblich gekennzeichnet)
Inzwischen nutzen stand Heute (24.06.2020) etwa bereits 13 Millionen Menschen die Corona-Warn-App. 15 Prozent der Bevölkerung werden erreicht, es gibt erste Infektionswarnungen. Es sollten sich nun erste positive Effekte zeigen. (Quelle)
Ich möchte hier meine Einschätzungen zur Corona-Warn-App hinsichtlich Datenschutz, IT-Sicherheit und Nützlichkeit kund tun. Dabei bemühe ich mich, alle Blickwinkel der verschiedenen involvierten Parteien und Berichterstatter Gehör zu schenken und abschließend eine rationale Empfehlung zu geben. Nach meiner Ansicht muss bei jeder digitalen Entscheidung der Trade-Off zwischen Risiko und Nutzen gezogen werden. Das berührt die Themen Datenschutz, IT-Security sowie Offenheit und Vertrauenswürdigkeit des Dienstanbieters gleichermaßen.
Funktion und Datenschutz
Konkret funktioniert die App so: Ein Handy sendet stets IDs per Bluethooth aus, die von anderen Handys empfangen werden können. Diese IDs ändern sich zudem über die Zeit. Rückschlüsse auf personenbezogene Daten (Name, Handynummer, usw.) der Nutzer sind nicht möglich. So kann man den Kontakt zwischen Nutzern über pseudonomysierte IDs nachzuweisen. Gespeicherte Daten sind neben der ID auch das Datum des Kontakts und die Distanz der Personen. Dies scheint sinnvoll, um das Gefahrenpotenzial zu bemessen. Die IDs der Nutzer werden generell erst mal nicht übertragen. Ist nun ein Mensch positiv, kann und sollte dieser dies in die App hinterlegen (per QR-Code Scan auf dem Bescheid oder per TAN-Verfahren). Nun werden die (pseudonymen) IDs dieses Benutzers auf den zentralen Servern abgelegt und für Warnmeldungen an die Nutzer verbreitet. Die Smartphones der Anwender entscheiden nun selbst gemäß ihres Protokolls, ob sie mit einer infizierten Person in Kontakt getreten sind. Das Infektionsrisiko wird in „niedriges Risiko“ oder „hohes Risiko“ oder „Risiko unbekannt“ eingeteilt. Ein niedriges Risiko wird angegeben, wenn „keine Begegnung mit nachweislich Corona-positiv getesteten Personen aufgezeichnet wurde oder sich Ihre Begegnung auf kurze Zeit und einen größeren Abstand beschränkt hat“ (Zitat aus der App). Der Server erfährt davon nichts. Zudem werden IDs nach 14 Tagen gelöscht, da hier die übliche Inkubationszeit erreicht ist. Damit ist dem Datenschutz nochmals besser genüge Getan. Auf die Übertragung einer GPS-Position wird bewusst verzichtet, sodass sich die Erstellung von Bewegungsprofilen der Nutzer ausschließt.
Hinsichtlich Datenschutz ist ein eindeutig positives Fazit zu ziehen: Das Konzept Privacy-by-Design wurde hier berücksichtigt. Tatsächlich funktioniert die App nicht, wie zuerst von einigen Datenschützern befürchtet, zentral, sondern die Datenhoheit bleibt so weit wie eben möglich in den Händen der Nutzer.
Die Datenschutzbestimmungen der App zeigen sich sehr offen und gut erklärt. Die zu verarbeitenden und zu speichernden Daten scheinen im gegebenen Kontext sinnvoll, d.h. so streng wie möglich, um den Einsatzzweck der App noch zu erfüllen.
Digitalcourage führt als Problem an „Detaillierte Bewegungsprofile der User können erstellt werden.“ Das sehe ich Anhand der oben beschriebenen Funktionsweise als sehr unwahrscheinlich an. Die App ist gerade so konzipiert, dass das kaum möglich erscheint.
Digitalcourage führt als Problem an „Beteiligte Personen können unter Umständen de-anonymisiert werden.“ Wie das konkret passieren soll, bleibt unklar. Die App ist Open Source und es wäre nachzuvollziehen, wenn das passieren würde. Es scheint nicht sehr wahrscheinlich.
Ein berechtigter Kritikpunkt ist hingegen, dass die App wohl nicht ohne die Google Play Services läuft (Quelle). Diese stehen unter Verdacht, den Benutzer auf die ein- oder andere Weise auszuspionieren und die Ergebnisse an Google zu senden. Jedes übliche Android-Smartphone von der Stange hat diese Services. Es gibt jedoch Möglichkeiten durch Installation eines eigenen Betriebssystems (z.B. LinageOS) trotz der Android-Basis sein Handy komplett entgooglet laufen zu lassen. Das machen zwar nur die wenigsten, besonders datenschutzaffine Menschen, aber es gibt gute Gründe dafür. Es sollte keiner auf Grund der Corona-Warn-App dazu gezwungen werden, sich die Google Play Services installieren zu müssen. Klare Forderung: Corona Warn-App bitte auch ohne Google Play Services! Es gibt bereits ein Projekt namens CoraLibre-android-sdk, welches eine freie, aber kompatible, Alternative zu Googles Privacy-Preserving Contact Tracing entwickeln möchte. Wir wünschen dem Projekt viel Erfolg und dass es auch in der offiziellen Corona-Warn-App Einzug hält.
IT-Security
Die App ist in sehr kurzer Zeit entstanden und konnte dementsprechend wenig getestet werden. Das liegt hier aber in der Natur der Sache, denn noch X Monate warten erhöht auch die Corona-Gefahren weiter. Sehr schön ist, dass die Corona-App von Anfang an von einem deutsches Team (SAP, Deutsche Telekom) entwickelt und Open Source publiziert wurde. Damit hat jeder die Möglichkeit in den Source Code zu gucken, Fehler zu finden und diese zu melden. Das können natürlich insbesondere auch unabhängige IT-Security-Spezialisten und Penetration-Tester.
Von Seiten des TÜV Nord wurden Fehler dann tatsächlich auch gefunden und mitgeteilt. Die Verantwortlichen von Telekom und SAP hätten darauf aber schnell reagiert und die kritischen Punkte noch vor Veröffentlichung der App beseitigt. So wünscht man es sich eigentlich. Fehler in Software werden wir nie verhindern, aber der Umgang damit ist entscheidend. Und der scheint hier gut zu sein. Während der TÜV sich zuerst über den kurzen Testzeitraum von 14 Tagen und die frühe Veröffentlichung beschwerte, lautete das Fazit zwei Tage später dann doch, die App werde „stabil und sicher laufen, ohne die Anwender auszuspionieren.“ (Quelle).
Ein letzter, ernst zu nehmender Kritikpunkt: Warum gibt es die App nicht bei F-Droid? Wenn die App doch Open Source ist und unter einer entsprechenden Lizenz steht, sollte das möglich sein. Grund sind hier die nötigen Google Play Services, die proprietär sind, sodass das F-Droid jegliches Projekt auf dessen Basis ablehnt. Hier haben wir auch den Punkt, dass wir jederzeit sicherstellen können, dass die binäre *.apk-Datei dem frei verfügbaren Source Code entspricht und nichts untergejubelt wird (Reproducible Builds). Hier bleibt also noch ein Kritikpunkt, trotz Open Source. Wir werden sehen, ob das Projekt CoraLibre-android-sdk es schaffen kann, die App auch in den F-Droid Store zu bringen!
Ältere Geräte
Ein Problem scheint tatsächlich zu sein, dass die App für ältere Geräte nicht zur Verfügung steht. Es wird mindestens ein iPhone 6 / iPhone SE oder Android 6 benötigt. Nach aktuellen Zahlen wären damit tatsächlich etwa 12% der Android-Nutzer ausgeschlossen, da diese eine ältere Version nutzen (Quelle). Das ist nicht wenig und betrifft tatsächlich wohl vor allem sozial schlechter gestellte wie Geringverdiener, Arbeitslose und arme Familien.
Tatsächlich muss man sich in der heutigen Zeit als Nutzer jedoch die kritische Frage stellen, ob man es denn für sich selbst verantworten kann, mit einem so alten Android durch die Gegend zu laufen. Schließlich gibt es hier auch gehörig Sicherheitslücken, die schon lange nicht mehr geschlossen werden. Schutz würde hier nur liefern, was ich schon länger fordere: Eine gesetzlich vorgeschriebene Updatepflicht über mehrere Jahre für noch auf dem Markt befindliche Geräte. Ich denke, 5 Jahre sollten es schon mindestens sein, wenn man ein neues Smartphone erwirbt. Also: Gesetze schaffen!
An dieser Stelle müssten übrigens Google (für Android) und Apple (für das iPhone) etwas machen. Es liegt an ihren Schnittstellen, dass es diese Versionsbeschränkungen gibt. Ganz vermeiden lässt sich das Problem jedoch auch bei bestem Willen nicht, da es alte Smartphones mit unzureichender Hardwareausstattung (insbesondere Bluetooth-Version) gibt, die nicht überwunden werden können.
Freiwilligkeit
Ein großer Punkt ist der der Freiwilligkeit. Diese sollte stets gewahrt bleiben. Auch wenn von der Bundesregierung die Freiwilligkeit betont wird, heißt das nicht, dass sich z.B. auch die Wirtschaft daran halten muss. Der Arbeitgeber könnte z.B. die Installation der App einfordern. Oder ein Supermarkt/Restaurant. Oder ein Veranstalter eine Großveranstaltung. Dass ein solcher Zwang nicht sein darf, klingt selbstverständlich. Daher sind die Forderungen eines entsprechenden Gesetzes nicht unberechtigt. Eine Formulierung wie „Die nicht-Installation der so genannten Corona-Warn-App darf zu keiner Benachteiligung führen“ würde da schon reichen.
Die Sichtweisen
„Da kann man nicht meckern“, sagen sie dann. Übersetzt heißt das so viel wie: „Alle Achtung, das ist ja mal richtig gut geworden.“
So ähnlich darf man Linus Neumann interpretieren, wenn er sich zur deutschen Corona-App äußert. Niemals würde er als Sprecher des Chaos Computer Club (CCC) zum Download der App aufrufen. „Wir haben aus grundsätzlichen Erwägungen noch nie ein Produkt oder eine Dienstleistung empfohlen“, sagt er ZDFheute. Wohl aber würde er vor der App warnen, sollte er Bedenken haben. Eine solche Warnung aber spricht Neumann nicht aus. Was für ein Lob.
Linus Neumann, Hacker, Netzaktivist und einer der Sprecher des Chaos Computer Clubs (CCC). Quelle: ZDF Heute
[Die App wird] stabil und sicher laufen, ohne die Anwender auszuspionieren
Es sprechen gute Gründe dafür, die Corona-Warn-App zu installieren: Die App scheint, nach allem was wir bisher wissen, solide programmiert, der Quellcode ist offen und IT-Sicherheits- und Privatsphäre-Experten haben keine Bedenken angemeldet. Falls die App funktioniert, könnte sie helfen, die Verbreitung von COVID-19, jedenfalls in Deutschland, einzudämmen. Alle, die dabei mithelfen, ihre Mitmenschen auf diese Art zu schützen, erweisen der gesamten Gesellschaft einen Dienst.
Es fällt auf, dass hier Digitalcourage als einzige Instanz zu dem Ergebnis kommt, explizit vom Einsatz der App abzuraten. Ansonsten scheint ein Großteil der Experten, auch für Datenschutz, im Gesamtfazit zufrieden. Ich kann mich dem Fazit von Digitalcourage nicht so ganz anschließen. Einige Kritikpunkte von Digitalcourage sind zu entschärfen, andere sind berechtigt und sollten durchdacht werden. Das Gesamtfazit kann ich angesichts der ehrlichen Bemühungen der Bundesregierung und der Verantwortlichen jedoch nicht nachvollziehen. Mein persönliches Fazit folgt im Anschluss.
Fazit
Ja, ein paar Kritikpunkte sind stehen geblieben: Probleme mit alten Geräten, das Thema Freiwilligkeit, die Pflicht zu den proprietären Google Play Services bzw. iOS Schnittstellen, das Fehlen im freien F-Droid Store und die kurzen Testzeiten für die IT-Security.
Der konkrete Nutzen muss sich während der Verwendung beweisen. Pauschale Vorabkritik zu möglicherweise erhöhten False-Positive- oder False-Negative-Ergebnissen halte ich für falsch. Auch, dass die Menschen dank ihrer tollen App dann plötzlich unvorsichtig werden, halte ich für fragwürdig.
Insgesamt ist das Projekt „Corona-Warn-App“ ein Musterbeispiel für gute Entscheidungen der Bundesregierung. Es wird konsequent auf Datenschutz und Privacy-By-Design gesetzt, die Entwicklung erfolgt in Deutschland, das Projekt ist Open Source und auf gemeldete Kritik/Sicherheitslücken wird schnell reagiert.
Im Allgemeinen würde ich eine Installation der Corona-Warn-App befürworten. Im Speziellen muss jeder für sich selbst die richtige Entscheidung treffen.
LineageOS ist ein alternatives Betriebssystem für viele Android-Handys, das auf dem Android Open Source Projekt basiert und vollständig offen ist. Es ist eine hervorragende Alternative zu Stock-Androids vom Hersteller, bietet eine pure Android Erfahrung und wird gut gepflegt bzw. häufig geupdatet. Leider ist die erstmalige Installation für Laien nicht immer ein einfaches Unterfangen. Updates der aktuellen Version können sehr einfach im laufenden Betrieb per Updater installiert werden. Major Updates, also eine neue Android Version, benötigen ein händisches Eingreifen und sind nicht immer ganz einfach umzusetzen.
Ich möchte hier beschreiben, wie man LinageOS 16.0 (Android 9) auf LinageOS 17.1 (Andorid 10) auf einem OnePlus 7 Pro updatet. Das Problem ist, dass bei der offiziellen Anleitung am Ende das Ein- oder Andere nicht mehr funktioniert, weil die Firmware nicht entsprechend geupdatet wurde. Dazu gehören wirklich wichtige Sachen, wie die mobile Datenverbindung. Man muss hier also etwas anders vorgehen und vorher über das originale OxygenOS 10 gehen.
Adb und Fastboot
Zuerst müssen wir sicherstellen, dass adb und fastboot installiert sind. Wie das allgemein für Windows & Linux geht, ist hier im offiziellen Wiki von LinageOS beschrieben. Zumindest wer Ubuntu oder Debian hat, hat es jedoch etwas leichter, denn da gibt es adb und fastboot bereits im offiziellen Ubuntu/Debian Repository. Installation wie folgt:
Wir müssen zuerst schauen, dass wir mit adb auf das Smartphone zugreifen können. Solltest du USB-Debugging bereits aktiviert haben, könnt ihr diesen Schritt überspringen. Schließ dein Smartphone per USB an und prüfe einfach, ob dein Smartphone gelistet wird, wenn du den Befehl adb devices im Terminal ausführst. Falls dein Device hier nicht auftaucht, die USB-Verbindung wieder trennen und wie folgt vorgehen:
Die Einstellungen öffnen und „Über das Telefon“ auswählen.
Auf den Eintrag „Build-Nummer“ (ganz unten) sieben mal tippen. Die Entwickleroptionen werden nun freigeschaltet.
Zurück zu den Einstellungen gehen und unter „System“ die „Entwickleroptionen“ öffnen.
Etwas runterscrollen, den Eintrag „Android-Debugging“ finden und aktivieren“.
Das Smartphone wieder per USB anschließen.
Im Terminal adb devices eintippen.
Nun sollte ein Dialog auf deinem Smartphone erscheinen, der nach USB-Debugging fragt. Markiere „immer erlauben“ und klicke auf „OK“.
Dein Smartphone sollte nun beim ausführen von adb devices gelistet werden.
Update durchführen
Wir werden zunächst das aktuelle OxygenOS 10 installieren (deine Daten gehen nicht verloren!), dann LinageOS 17.1 und schlussendlich (optional) die Open GApps, wenn ihr die Google Services haben wollt, die ihr nicht direkt aus dem PlayStore beziehen könnt. Achtung: Vor dem Installieren der GApps keinenfalls das neue LinageOS booten.
Wer auf seinem Smartphone root-Rechte nutzen möchte, wird idr. Magisk installiert haben, was jedoch durch das Update überschrieben wurde. Während der Magisk Manager weiterhin installiert ist, muss Magisk neu installiert werden.
Ladet euch zuerst die neuste Version von magisk von der GitHub-Projektseite unter Releases herunter. Aktuell ist Magisk v20.4 und die Datei heißt Magisk-v20.4.zip. Die Installation geht wie folgt:
Wir haben nun ein LinageOS 17.1 auf unserem OnePlus 7 Pro und es sollte alles funktionieren inkl. mobiler Datenverbindung. Wenn euch dieses Tutorial gefallen hat, dann meldet euch doch beim Newsletter an!
Kürzlich habe ich ein Lenovo P1 erworben, welches bereits ein vorinstalliertes Windows 10 Pro hatte. Natürlich habe ich direkt ein Linux installiert: In meinem Fall ein Kubuntu 20.04. Dazu habe ich die bereits existente NTFS-Partition mit Windows Installation auf 850GB etwas verkleinert und 100GB freien Platz für Linux geschaffen. Warum habe ich die NTFS-Partition so groß gelassen? Weil es nach meinen Recherchen wesentlich besser funktioniert von Linux aus auf einer NTFS-Partition zu schreiben, als in Windows eine ext4 Partition einzurichten. Die gemeinsame Datenpartition wird also die Windows NTFS-Partition. Auf eine swap-Partition habe ich ganz verzichtet, da 48GB Ram für alles Mögliche ausreichen wird.
Nun habe ich also ein Dual-Boot System Ubuntu 20.04 / Windows 10. Das ist schon mal fein. Aber auch unter Linux brauche ich gerne mal schnell die Windows-Funktionalitäten zur Hand (Photoshop, …). Und da zwei Windows 10 Instanzen zu pflegen doppelter Aufwand ist, kommt eine Möglichkeit das physische System in VirtualBox zu booten hier gerade recht. Darum soll es hier nun gehen.
Die Windows-Partitionen identifizieren
Ich benutze hier mal ganz einfach den KDE-Partition Manager. Wer kein Kubuntu hat und wo der KDE-Partition Manager fehlt, kann er nachinstalliert werden:
sudo apt-get install partitionmanager
Schauen wir uns mal die Partitionierung an. Diese sollte auf jedem System mit EFI ähnlich aussehen.
Hier sehen wir folgende Partitionen:
/dev/nvme0n1p1 eine fat32 Partititon, die zum EFI gehört. Man erkennt sie auch, weil sie unter /boot/efi gemountet ist. Diese Partition ist für uns relevant, da wir sie zum booten benötigen.
/dev/nvme0n1p2 ist eine so genannte Microsoft Reserved Partition, die heutzutage eigentlich keine Relevant mehr hat.
/dev/nvme0n1p3 ist nun die eigentlich wichtige Partition für uns. Hier liegt Windows.
/dev/nvme0n1p5 enthält unsere Linux Distribution
/dev/nvme0n1p4 enthält ein Windows Recovery, falls man Windows mal neu aufsetzen muss.
Zugriffsrechte im Dateisystem
Um auch ohne sudo vollständigen Zugriff auf unsere Windows 10 Partition zu haben, müssen wir noch was tun. Der beste Weg dazu ist eine udev Regel zu definieren, die die Windows 10 Partition zu einer bestimmten group hinzufügt.
Erstellen wir zunächst eine neue Gruppe für die Windows 10 Partition:
sudo groupadd win10disk
Nun den eigenen Benutzer der Gruppe hinzufügen
sudo usermod -a -G win10disk youruser
Nun müssen wir die UUID der Windows 10 Partition herausfinden. Das geht wie folgt:
Sollte sich eine andere eindeutige ID als ID_PART_TABLE_UUID ergeben, funktioniert dies auch. Kopiere die Variable und erstelle die Datei /etc/udev/rules.d/99-win10disk.rules mit in etwa folgendem Inhalt:
Speichere die Datei und führe nun einen Neustart durch. Prüfe nun, ob alles funktioniert hat mit:
ls -l /dev/nvme0n1p3
Der Output sollte in etwa wie folgt aussehen:
brw-rw---- 1 root win10disk 259, 3 Jun 1 13:29 /dev/nvme0n1p3
VirtualBox Raw Host Access VMDK Datei
Damit VirtualBox die physischen Partitionen vom EFI und Windows booten kann, muss einen spezielle VMDK (Virtual Machine Disk) Datei erstellt werden, welche die Partitionen repräsentiert. Diese Datei enthält keinen Daten von den physischen Partitionen, sondern ist nur eine Art Verweis, der VirtualBox den Zugriff erlaubt.
Du kannst das VirtualBox raw disk image mit VBoxManage erstellen. Das Zielverzeichnis kann mit der Option -filename spezifiziert werden. Wir wollen die Partitionen /dev/nvme0n1p1 (EFI) und /dev/nvme0n1p3 (Windows) einbinden. Das wären Partitionen 1 und 3 von /dev/nvme0n1:
RAW host disk access VMDK file /path/to/windows10.vmdk created successfully.
Die Virtuelle Maschine Erstellen und Konfigurieren
Erstelle wie üblich eine Windows 10 VM. Wähle bei Hard disk die Option „Use an existing virtual hard disk file“ und wähle die zuvor erstellte win10.vmdk aus.
Wenn der Wizard abgeschlossen ist, öffne die Settings der neuen VM. Wähle bei System bei „Boot Order“ als einziges „Hard Disk“ aus und deaktiviere alle anderen Optionen. Aktiviere die Option „Enable EFI (special OSses only)“, sofern dein Laptop EFI benutzt (davon gehen wir hier aus):
Unter Storage kannst du noch mal kontrollieren, ob alles richtig eingebunden ist. Hier sollte unter Controller: SATA die Datei win10.vmdk ausgewählt sein. Vermutlich wirst du die Option „Solid-state Drive“ noch aktivieren wollen.
GRUB einrichten
Starten wir nun die virtuelle Maschine. Höchst wahrscheinlich wird nun GRUB starten ohne Windows direkt laden zu können. Mit ls kannst du dir alle Partitionen anzeigen lassen:
grub> ls
(proc) (hd0) (hd0,gtp5) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1)
Wir wissen schon, dass unsere Windows Installation auf Partition 3 liegt. Verifizieren wir dies:
grub> ls (hd0,gpt3)
Partition hd0,gpt3: Filesystem type ntfs - Label 'Windows', UUID ABCDEF - Partition start at 283648KiB
Und das wars! Wir können nun den Bootvorgang starten. Die gemachten Einstellungen werden gespeichert und Windows fährt in Zukunft von selber hoch.
grub> boot
Was es noch zu beachten gibt
Nun nicht vergessen die VBoxGuestAdditions.iso einzulegen (Devices → Insert Guest Additions CD Image) und zu installieren. Nach einem Neustart von Windows sollte jetzt alles funktionieren. Insbesondere sollte die Fenstergröße frei verändert werden können.
Ist das nicht der Fall, liegt das an einem Bug der aktuellen VirtualBox Version (6.1.8), der bei manchen aufzutauchen scheint und bei manchen nicht. Das Problem lässt sich lösen, in dem in den Settings der VM unter Display den Graphics Controller auf VBoxVGA setzt und Enable 3D Acceleration deaktiviert. Das ist nicht optimal, aber alle mal besser als auf einem viel zu kleinen Bildschirm zu arbeiten. Dann die VM ein mal sauber über das Betriebssystem herunterfahren und wieder hochfahren. Es sollte jetzt funktionieren.
Windows 10 Schnellstart & Hibernate
Denkt daran, dass man den Schnellstart unter Windows 10 deaktivieren muss. Das sollte man aber auch schon für einfaches Dual-Boot tun. Es kommt sonst zu Problemen mit ggf. Datenverlusten. Auch Hibernate ist manchmal Problematisch und ich rate davon ab, diesen zu benutzen.
Fazit
Es ist erstaunlich, dass Windows 10 in dieser Form so gut funktioniert. Man bedenke, dass wir bei jedem direkten Start andere Hardware haben als über VirtualBox. Man sollte also Treiberprobleme vermuten. Auch erstaunlich ist, dass keine erneute Aktivierung bei jedem Hardwarewechsel nötig ist. Aber alles ist super und es funktioniert!
Ich persönlich nutze die VM vor allem für Adobe Produkte (Photoshop, Lightroom, Illustrator, Acrobat Pro), Canon EOS Utility, den Brother P-Touch Editor (Labeldrucker) und die Steuererklärung (Taxman 2020 für Selbstständige). Insbesondere Photoshop und Lightroom arbeiten unter einem nativ gebooteten System natürlich besser (Hardwarebeschleunigung!) Eine brauchbare Software für Steuererklärungen von selbstständigen Kleingewerbetreibenden scheint es für Linux leider nicht zu geben (beweist mir gerne das Gegenteil!)
Sieve-Skripte sind eine einfache Möglichkeit Mailfilter auf Mailservern umzusetzen. So können serverseitig etwa Regeln definiert werden, die eingehende Nachrichten z.B. bei vorliegen eines bestimmten Absenders, Empfängers oder Betreffs in einen Ordner verschiebt. Nachrichten können z.B. auch gelöscht oder als gelesen markiert werden. Man kann auch Nachrichten weiterleiten oder mit automatisierter Antwort ablehnen. Auch Abwesenheitsnotizen sind ein Typischer Anwendungsfall.
Die Möglichkeiten sind im Prinzip sehr ähnlich zu den Filterregeln, die man in Thunderbird hinterlegen kann. Der Wesentliche Vorteil: Das Filtern erfolgt auf dem Server. Das ist insbesondere dann von Vorteil, wenn man von mehreren Clients auf ein IMAP-Account zugreift. Da wir heutzutage in der Ära der Smartphones angelangt sind, tut das quasi jeder. Manch einer neben Desktop und Smartphone womöglich noch auf der Arbeit oder per Webmail. Mittels Sieve muss man die Filter nur ein mal pflegen und zwar auf dem Server.
Sieve Clients
Sieve stellt ein eigenes Protokoll zur Verfügung und ist unter Port 4190 zu erreichen. Nun könnte man seine Filter tatsächlich sogar per Telnet pflegen. Komfortabler ist aber ein Sieve Client (Überblick hier). Viele Clients sind jedoch veraltet. Empfehlenswert ist Manage Sieve (Windows und Linux), welches das editieren von Sieve Skripten mit Syntax-Hervorhebung ermöglicht. Das ist toll für Informatiker und Enthusiasten, wird aber den Otto-Normal-Verbraucher abschrecken. Wer seinen Nutzern die Filter komfortabel per GUI erstellen lassen möchte, dem sei die Sieve Erweiterung für den Webmailclient Roundcube empfohlen. Weiterer Vorteil: Man braucht keine weitere Software installieren. Wir besprechen daher im Folgenden auch die Installation von Sieve in Roundcube.
Editieren eines Sieve Skripts mittels Manage Sieve unter Linux
Wir gehen davon aus, dass Dovecot bereits vollständig für die Verwendung mit IMAP eingerichtet ist. Auch Roundcube sollte schon installiert sein. Wir besprechen hier nur die nötige Konfiguration für Sieve!
Dovecot einrichten
Bekanntermaßen wird Sieve häufig auch für das Filtern von z.B. Spam in den Spam-Ordner verwendet. Während hier die Regeln lediglich durch den Administrator auf dem Server abgelegt werden, möchten wir dem Endanwender ermöglichen Sieve-Skripte anzuwenden. Hierzu verwenden wir neben dem sieve Plugin auch managesieve.
Zuerst installieren wir die Sieve-Erweiterung von Dovecot:
Wir aktivieren nun das Sieve Plugin für den LMTP (Local Mail Transfer Protocol). Dazu editieren wir die Datei /etc/dovecot/conf.d/20-lmtp.conf:
protocol lmtp {
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
}
Sieve konfigurieren
Nun richten wir Sieve selbst ein. Dazu editieren wir /etc/dovecot/conf.d/90-sieve.conf. Generell gilt, dass ein Benutzer beliebig viele Sieve-Skripte haben kann. Diese müssen an einem Ort gespeichert werden. Hierfür bietet sich z.B. /var/vmail/sieve/scripts/%u an. Hierbei ist %u ein Platzhalter für den vollständigen Benutzernamen inklusive Domain, also der Form user@example.com. Außerdem muss der Ort für das aktuell aktive Sieve-Skript eines Nutzers angegeben werden. Ein Nutzer kann zwar beliebig viele Sieve-Skripte definieren, hat aber immer nur genau ein aktives Skript. Wir nehmen hier den Pfad /var/vmail/sieve/%u.sieve. Die 90-sieve.conf beinhaltet nun folgendes:
Wer ein Sieve-Skript für einen Spamfilter anlegen möchte, also z.B. bei vorliegen eines Spam-Headers in einen Spam-Ordner filtern möchte, tut dies in der Regel bevor das Skript des Benutzers ausgeführt wird. Daher wird sieve_before gesetzt. Folgendes könnte in 90-sieve.conf eingetragen werden:
sieve_before = /var/vmail/sieve/spam-global.sieve
Die Datei spam-global.sieve kann wie folgt aussehen:
Um unsere Sieve-Skripte auch von außen bearbeiten zu können, müssen wir nun managesieve aktivieren. Wir bearbeiten /etc/dovecot/conf.d/20-managesieve.conf:
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
Damit hätten wir es geschafft. Jetzt noch neu starten!
sudo service dovecot restart
Roundcube
Zuerst richten wir das Plugin managesieve für Roundcube ein. Dazu legen wir die Configdatei config.inc.php durch Kopieren der Defaultconfig config.inc.php.dist an:
Der Port 4190 ist der Standardport für Sieve und wir haben diesen in der managesieve.conf von Dovecot entsprechend gesetzt. Ich gehe davon aus, dass die Hostnamen in der Roundcube Konfigurationsdatei explizit gesetzt sind. So ist es mit dieser Konfiguration auch möglich Sieve-Skripte auf fremden Mailservern (ungleich localhost) zu editieren. Da dies möglich ist, sollten wir managesieve_usetls auf jeden Fall auf true setzen, damit wir Transportverschlüsselung haben. Wir müssen nun noch das managesieve-Plugin in der Roudcube Konfigurationsdatei aktivieren. Bei mir sieht /path-to-roundcube/config/config.inc.php ausschnittsweise wie folgt aus:
Wir können uns nun in Roundcube einloggen. Oben rechts unter Einstellungen finden wir nun links den Eintrag Filter. Hier können wir neue Filtersätze anlegen und einen Filtersatz aktivieren. Filter können sehr komfortabel über die GUI zusammengeklickt werden. Roundcube generiert das Sieve-Skript und pusht dieses auf den Server.
Bezüglich der möglichen Filter sind bei mir keine Wünsche offen geblieben. Aktuell wäre mir nicht bekannt, dass die Sieve-Skriptsprache Operationen unterstützt, die hier nicht abgedeckt werden. Solltest du andere Erfahrungen gemacht haben, dann kontaktiere mich doch bitte und ich werde den Artikel entsprechend ergänzen!
Heute wollen wir uns mit Content Security Policy (CSP) Headern beschäftigen. In erster Linie ist dies ein Sicherheitsfeature, um das Laden von (Java-)Skripten, aber auch Bilder, Fonts, iFrames etc. aus böswilligen Quellen zu unterbinden und so insbesondere Cross-Site-Scripting zu unterbinden. Wikipedia sagt dazu folgendes:
Content Security Policy (CSP) ist ein Sicherheitskonzept, um Cross-Site-Scripting und andere Angriffe durch Einschleusen von Daten in Webseiten zu verhindern.
In der Praxis sind jedoch Cross-Site-Scripting-Schwachstellen sehr verbreitet. Die Content Security Policy erzwingt eine strikte Trennung zwischen Inhaltsdaten im HTML-Code und externen Dateien z.B. mit JavaScript-Code. In der Regel ist der JavaScript-Code statisch und wird nicht dynamisch generiert.
Wir wollen CSP aber für noch mehr benutzen: Wir können damit auch unerwünschte Drittanbieter ausschließen, die uns WordPress quasi aufzwingt. Diese Drittanbieter können die Besucher eurer Webseite möglicherweise (in einigen Fällen sogar ziemlich sicher) tracken. Wer seinen Benutzern gegenüber Datenschutzfreundlich sein möchte, verzichtet nicht nur auf Google Analytics, sondern auch auf andere Drittanbieter. Dennoch möchte ich das Analysieren von Benutzerverhalten nicht gänzlich verteufeln, denn es liefert nützliche Einsichten, welche Reichweite man mit seinem Angebot erzielt und welche Angebote die Besucher womöglich besonders interessieren. Aber dazu gibt es auch Datenschutzfreundliche Alternativen: Matomo ist ein Paradebeispiel, welche ein selbst gehostetes System darstellt und freingranulare Einstellungen im Bezug auf Datenschutz bietet. Aus meiner Sicht ist der wichtigste Punkt, dass die Daten in den eigenen Händen bleiben und nicht z.B. bei Google landen. Ich beschreibe daher hier auch wie Matomo mit CSP funktioniert, wenn dieses auf einer Subdomain wie https://matomo.the-digital-native.de betrieben wird.
Für WordPress ganz übliche Drittanbeiter sind:
Gravatar: Verknüpft beim Dienstanbieter hinterlegte Avatare mit der E-Mailadresse. Sammelt möglicherweise Daten und wird ohnehin von nur wenigen Nutzern gebraucht. Damit Benutzer trotzdem Avatare verwenden können, ist es ratsam das Plugin WP User Avatar als Ersatz zu installieren.
Google Fonts: Stellt zentral und kostenlos Schriftarten zur Verfügung, die durch Webdesigner einfach als Fremdresource eingebunden werden können. Eine der ärgerlichsten Datenschutzsünden, denn Google erfährt so von jedem Besucher! Außerdem ist es wirklich sehr einfach möglich, Fonts auch auf dem eigenen Server abzulegen und per CSS nachzuladen. Es gibt also nicht mal einen guten Grund auf diesen Service zurück zu greifen.
Basiskonfiguration für WordPress
Folgende Konfiguration habe ich ausführlich getestet und kann im VirtualHost von apache2 so in der Form hinterlegt werden:
default-src wird immer dann angewandt, wenn eine Ressource geladen werden soll, auf die keine andere Regel zutrifft. Es wird hier empfohlen none zu setzen. Wer ein Kontakt-Formular wie Contact Form 7 einsetzt, wird hier leider zumindest self setzen müssen. Theoretisch sollte das auch anders gehen (via Direktive connect-src auf self). Leider funktioniert dies in der Praxis nicht.
img-src definiert, woher Bilder per <img>-Tag geladen werden können. self benötigt man hier logischerweise. Die Option data: ermöglicht das Laden von Bildern aus im HTML codierten Bildmaterial. Dies nutzt WordPress ebenfalls. Wer weitere Quellen für Bilder hat, muss diese hier angeben. Hier schließen wir u.a. Gravatar aus. Wer seinen Benutzern trotz allem Gravatar zur Verfügung stellen möchte, muss hier die URL https://secure.gravatar.com hinzufügen.
style-css gibt an, woher CSS-Dateien geladen werden können. Leider muss hier die unsichere Option unsafe-inline hinzugefügt werden, weil WordPress mittels <style>-Tag CSS-Attribute in das HTML einbettet. Dies ist ein Sicherheitsdefizit von WordPress. Wir schließen hier insbesondere auch Google Fonts aus, denn darauf kann man bei auch nur etwas Liebe zum Datenschutz wirklich verzichten.
font-src gibt Möglichkeiten zum Nachladen von Schriftarten an. Werden nur Systemschriftarten eingesetzt, kann hier none gewählt werden. WordPress lädt aber, je nach Theme, Schriftarten nach. Zum Teil auch eingebettete Schriftarten, sodass data: nötig wird.
script-src gibt insbesondere die Quellen für JavaScripte an. Dass wir hier self haben ist ok, jedoch erfordert WordPress auch unsafe-inline und unsafe-eval, was ein besonderes Sicherheitsrisiko darstellt. Letzteres ermöglicht das Ausführen von JavaScript-Code mit der so genannten eval()-Funktion und gibt als typischer Punkt, um Schadcode einzuschleusen. Die Entwickler von WordPress sollten hier dringend nachbessern und auch ohne unsafe-eval auskommen.
frame-src ermöglicht das Laden von Webseiten in <frame> oder <iframe> Elementen. Sollte aus Sicherheitsgründen auf self beschränkt bleiben, falls möglich.
form-action beschränkt die Webseiten, die durch das Absenden eines Formulars erreicht werden können. Für Funktionen wie Kontaktformulare, Newsletteranmeldung (lokal) etc. sollte hier self genügen.
Setzt man base-uri auf none, muss jede verlinkte Ressource mit einem vollständigen Pfad angegeben werden. Damit wäre z.B. <img src="my_picture.png"> nicht zulässig, sehr wohl aber <img src="https://the-digital-native.de/my_picture.png">. Erfreulicherweise setzt Wodpress dieses Sicherheitsfeature um!
frame-ancestors erlaubt bzw. verbietet, dass die eigene Webseite in andere Webseiten eingebunden werden kann, z.B. per iframe. Die Option self verhindert möglicherweise Missbrauch des eigenen Contents durch andere Webseitenbetreiber.
Konfiguration von Matomo
Ich empfehle Matomo auf der eigenen Domain zu hosten, z.B. als Subdomain. In dem Fall muss Matomo in img-src sowie script-src hinzugefügt werden. Wenn man die Opt-Out-Box von Matomo z.B. in die Datenschutzerklärung einbinden möchte, muss Matomo auch als frame-src zulassen, da es mittels iFrame eingebunden wird.
Die WordPress-Administration benötigt etwas mehr Rechte, um korrekt zu funktionieren. Da ich die Rechte für die Benutzerspezifischen Seiten nicht unnötig ausweiten möchte, habe ich in apache2 eine Location-Direktive erstellt, die auf das Unterverzeichnis wp-admin abzielt.
Auch hier braucht eine Matomo Instanz ein paar extra-Regeln, um die Einbettung in das Adminmenü zu ermöglichen. Eine Konfiguration kann wie folgt aussehen:
Wer das Plugin Yoast zur SEO-Optimierung benutzt, muss unter default-src den Eintrag https://yoast.com hinzufügen.
Generell gilt, dass ihr bei weiteren Plugins immer überprüfen solltet, ob diese auch funktionieren. Unter F12 gibt es in Firefox & Chrome die Console, wo durch CSP geblockte Inhalte angezeigt werden. Surft damit durch eure Webseite und auch das Admin-Menü. Fügt, falls nötig, weitere Webseiten zu den einzelnen Policies hinzu. Bedenkt aber: Lokale Lösungen sind Drittanbietern aus Datenschutzsicht immer vorzuziehen! Verwendet z.B. einen eigenen Captcha-Generator statt Googles ReCaptcha. Ja, es gibt viele Dienste, die euren Benutzern tolle Funktionalitäten bieten, aber wägt immer zwischen Datenschutz und Nice-To-Have Features ab!
Qualität der CSPs testen
Dafür gibt es das Mozilla Obversatory. Trotz dass wir das Maximum rausgeholt haben und einige grüne Häkchen sammeln, bekommen wir aktuell leider -20 Punkte. Kaputt macht uns das Ranking unsafe-inline und unsafe-eval. Hier sind die Softwareentwickler von WordPress gefragt, die hier als einziges Abhilfe schaffen können. Es bleibt Verbesserungspotential!
Mozilla Obversatory für https://the-digital-native.de
Garvatar Ersetzen
Fazit
Mit Content Security Policy Headern kann man eine Menge an zusätzlicher Sicherheit und Datenschutz für seine Nutzer erzielen. Eine gut getestete Grundlage für eine WordPress-Basisinstallation sowie eine Matomo Instanz haben wir hier geliefert. Bereits dies war tagelange Ausprobiererei, bis wir das Optimum an CSPs erreicht haben, ohne das die Funktionalität Schaden genommen hat. Komplexere Installationen benötigen hier evtl. nochmals mehr Aufwand.
Täglich gehen zig Millionen Mails durch die Welt. Heute sollte es selbstverständlich sein, vom Mailclient zum Mailserver transportverschlüsselt zu arbeiten: Mails abrufen per IMAP (Dovecot), Mails versenden per SMTP (Postfix). Aber auch die Intra-Mailserverkommunikation (Postfix) sollte heutzutage nach aktuellen Standards verschlüsselt erfolgen.
Noch vor wenigen Jahren war es noch absolut üblich, dass Mailserver unverschlüsselt miteinander kommunizierten. Noch im Januar 2015 kommunizierten nur gut 50% der Mailserver untereinander verschlüsselt. Heute sind es über 90% (Quelle: Google Transparency Report, Stand: Mai 2020). Das wird im Auge vieler Administratoren dennoch nicht genug sein, um unverschlüsselte Kommunikation komplett auszuschließen. Meiner Meinung nach sollten sich große Anbieter wie GMail, Outlook.com, Web.de, Gmx.de, … zusammen schließen und unverschlüsselte Kommunikation konsequent blocken. Unter diesem Druck wäre es nur eine Frage der Zeit, bis schlecht konfigurierte uralt Server verschwinden.
E-Mail Verschlüsselung über die Zeit. Quelle: Google
Inhalt
Hier möchten wir uns nun mit der Konfiguration von Postfix und Dovecot beschäftigen: Wir werden einen Parallelbetrieb von ECDSA / RSA Zertifikaten vorstellen. RSA ist dabei etablierter Standard. ECDSA (Elliptische-Kurven-Kryptografie) ist Cutting-Edge Technologie und wird in Zukunft an Bedeutung gewinnen. Wer diesen Artikel liest, möchte wahrscheinlich auf der Höhe der Zeit sein und schon heute ECDSA einsetzen.
Dabei nutzen wir Let’s Encrypt als Zertifizierungsstelle und acme.sh als ACME Clients Implementierung zum beziehen und installieren von Zertifikaten. acme.sh ist eine Alternative zu certbot, die für unsere Zwecke einige Vorteile bietet. Besonderes Augenmerk habe ich darauf gelegt, dass Zertifikate automatisch erneuert werden, denn schließlich ist ein Let’s Encrypt Zertifikat nur 3 Monate gültig.
Vorwissen
Für diesen Artikel sind Grundkenntnisse im Bereich von Administration von Linuxsevern im Allgemeinen sowie von Mailservern im speziellen zu empfehlen. Außerdem sollte grundsätzlich verstanden sein, was es mit asymmetrischer Kryptografie auf sich hat und warum eine Zertifizierungsstelle wir Let’s Encrypt benötigt wird.
Wir gehen davon aus, dass Sie Postfix und Dovecot bereits im Einsatz haben oder zumindest so weit konfiguriert haben, dass Ihnen nur noch die Verschlüsselung fehlt. Sollte das noch nicht der Fall sein, befolgen Sie bitte ein entsprechendes Tutorial, bevor Sie hier weiter machen.
Als Betriebssystem kommt bei uns Debian 10 (Buster) zum Einsatz. Auf Ubuntu sollte es kaum Unterschiede geben, für andere Distributionen sind evtl. kleinere Anpassungen nötig.
Wir erzeugen nun ein RSA– und ein ECDSA-Schlüsselpärchen, welche wir von der CA Let’s Encrypt mittels eines Zertifikats beglaubigen lassen. Für diesen Zweck verwenden wir das Shell-Skript acme.sh.
acme.sh installieren
Wir klonen zuerst das git-Repository von acme.sh. Falls git nicht installiert ist, holen Sie dies bitte jetzt nach:
sudo apt-get install git
Nun das git klonen und die Installation anstoßen. Es ist zu empfehlen, dies als root-User zu tun:
sudo su
git clone https://github.com/acmesh-official/acme.sh.git
cd ./acme.sh
./acme.sh --install
Der Installer sorgt für drei Dinge:
Erstellt und kopiert acme.sh in das home-Verzeichnis: ~/.acme.sh/. Alle Zertifikate werden später hier abgelegt und dann mittels einer Installationsroutine an ihren Zielort kopiert.
Es wird ein Alias erzeugt: acme.sh=~/.acme.sh/acme.sh
Es wird ein Cronjob angelegt, der ein mal am Tag Zertifikate checkt und, wenn nötig, neu beantragt und automatisch installiert.
Nach der Installation muss das Terminal ein mal neu gestartet werden, damit der Alias acme.sh funktioniert (ggf. neuer Login per ssh). Die Hilfe von acme.sh kann wie folgt aufgerufen werden: acme.sh -h
Zertifikate erzeugen
Wir könnten nun einerseits ein Wildcard Zertifikat generieren, was aber mit zusätzlichen Aufwänden verbunden ist (DNS Challenge) und ggf. sogar ein Sicherheitsrisiko darstellt. Daher sollten wir ein Zertifikat für den MX-Eintrag generieren (hier: mail.occumail.net) und, falls nötig, alias Domains für den IMAP Server (hier: imap.occumail.net) und für den SMTP Server (hier: smtp.occumail.net) anlegen.
Es stellt sich noch die Frage: Läuft auf dem Server ein Webserver wie apache2 oder nginx? Da acme.sh einen eigenen Webserver startet, kommt es natürlich zu einem Konflikt auf Port 80. Daher bauen wir hier einen Pre-Hook ein, der vor Generierung des Zertifikats apache2 stoppt (--pre-hook "service apache2 stop") und einen Post-Hook, der apache2 wieder startet (--post-hook "service apache2 start"). Für nginx geht dies äquivalent.
RSA Zertifikat erzeugen
Für den RSA Schlüssel empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) noch bis Ende 2023 eine Schlüssellänge von 2048 Bits, die als sicher gelte. Danach werden 3072 Bits empfohlen. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Wer nach aktuellem Kenntnisstand sicher sein möchte, wählt also 2048 Bits , wer für die Zukunft gewahrt sein möchte 3072 Bits und wer paranoid ist 4096 Bits. Man bedenke bei der Wahl immer, dass ein längerer Schlüssel einen (womöglich deutlichen) Rechenaufwand bedeutet. Bei schwacher Hardware oder schwachen VServern sollte man daher vorsichtig sein, einen zu langen Schlüssel zu wählen. Wir nehmen in unserem Beispiel 3072 Bits (Parameter--keylength 3072).
Nun testen wir erst mal, ob unsere Zertifikatsbeantragung funktioniert. Mit der Option --test wird vorerst nur ein Dummy-Zertifikat erzeugt. Wir sollten vorsichtig vorgehen und nicht ohne Tests arbeiten, da Beantragungen bei Let’s Encrypt auf 5 Ausstellungen pro Woche pro (Sub-)Domain beschränkt sind. Es darf also nicht zu oft schief gehen.
Es liegen nun unter ~/.acme.sh/mail.occumail.net folgende Dateien:
mail.occumail.net.csr: Certificate Signing Request mit den notwendigen Informationen, die zur Antragsstellung des Zertifikats bei Let’s Encrypt benutzt wurden.
mail.occumail.net.csr.conf: Konfigurationsdatei für die zukünftige Generierung von CSRs beim automatischen erneuern von Zertifikaten.
mail.occumail.net.cer: Unser Zertifikat für die beantragten (Sub-)Domains.
fullchain.cer: Zertifikat für die beantragten (Sub-)Domains zusammen mit Zwischenzertifikaten, die für die Chain of Trust benötigt werden. Diese Datei benötigen wir im Folgenden noch.
mail.occumail.net.key: Unser privater Schlüssel. Auch diese Datei benötigen wir noch.
ca.cer: Zertifikat der Certification Authority, also Let’s Encrypt.
mail.occumail.net.conf: Informationen für die neue Beantragung von Zertifikaten, wenn das Alte abläuft (alle 2 Monate)
Ein Vorteil von acme.sh im Vergleich zu certbot ist, dass der private Schlüssel nicht bei jeder Neubeantragung neu erzeugt wird. Das ermöglicht, die Zertifikate auch für TLSA-Records (DANE) und HPKP (Public Key Pinning) einzusetzen. Wer mit diesen Begriffen jetzt nichts anfangen kann, sollte sich diese nach Abschluss des Tutorials noch mal zur Gemüte führen, da sie für Mailserver durchaus relevant sind.
ECDSA Zertifikat erzeugen
Nun zum ECDSA (Elliptic Curve Digital Signature Algorithm). Let’s Encrypt stellt uns stand heute zwei Varianten zur Verfügung: ec-256 mit 256 Bit Schlüssellänge und ec-384 mit 384 Bit Schlüssellänge. Hier entspricht ec-256 bereits einer RSA-Schlüssellänge von 3072 Bit und ist damit auch auf längere Sicht hinreichen sicher (über Jahr 2023 hinaus). ec-384 entspricht einer RSA-Schlüssellänge von 7680 Bit und ist damit quasi auf Ewig unknackbar (Fehler im Algorithmus und unerwartete Technologiesprünge ausgenommen). Da diese Art von Algorithmus ob des ohnehin relativ kurzen Schlüssels sehr effizient ist, spricht aus Performancegründen aber auch kaum etwas gegen den Einsatz von ec-384.
Zur Generierung führen wir Äquivalent zu oben folgendes aus:
Es wird der Ordner ~/.acme.sh/mail.occumail.net_ecc erzeugt. Darin enthalten sind die gleichen Dateien wie für den RSA Fall.
Zertifikate Installieren
Nun müssen wir die Zertifikate noch installieren, d.h. von ~/.acme in die richtigen Zielordner verschieben. Auch das übernimmt acme.sh für uns. Wir benötigen den Private Key und unser Zertifikat einschließlich Chain of Trust. Außerdem müssen sowohl Postfix als auch Dovecot nach Abschluss neu gestartet werden, insbesondere auch beim automatischen Ausstellen neuer Zertifikate. Die Berechtigungen für die kopierten Dateien werden von acme.sh automatisch auf 600 gesetzt, sodass ein Zugriff nur vom Besitzer der Datei möglich ist.
Auch diese Operationen werden in der Datei ~/.acme.sh/mail.occumail.net/mail.occumail.net.conf bzw. ~/.acme.sh/mail.occumail.net_ecc/mail.occumail.net.conf persistiert, sodass das Installieren von Zertifikaten in Zukunft ebenfalls automatisiert erfolgt.
3.2 (E)DH-Key erzeugen
Postfix nutzt Forward Secrecy bereits ohne weitere Konfiguration. Allerdings werden für den Schlüsselaustausch via Forward Secrecy geeigneten Cipher-Suiten (EDH) bereits vorberechnete DH-Schlüssel mit 2048-Bit und 512-Bit verwendet. Wir berechnen einen neuen Schlüssel.
Das BSI empfiehlt aktuell noch einen Key mit mindestens 2048 Bits. Ab dem Jahr 2022 sollen Keys mit einer Größe von mindestens 3072 Bits verwendet werden. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Die ganze sicheren unter uns können dann noch 4096 Bits einsetzen. Ich habe mich für den Mittelweg entschieden und damit langfristig vorgesorgt.
smtpd_tls_security_level: may bedeutet, dass standardmäßig verschlüsselt werden soll, aber unverschlüsselte Verbindungen als Fallback zugelassen werden. encrypt bedeutet, dass Verschlüsselung erzwungen wird. Letzteres wäre eigentlich wünschenswert, aber, wie bereits weiter oben beschrieben, verschlüsseln derzeit (Mai 2020) „nur“ etwa 90% der Mailserver ihre Verbindung. Es könnten also Mails abgewiesen werden, was dem Sender jedoch mitgeteilt wird. Im Allgemeinen wird (noch) empfohlen hier may zu wählen. Idealisten mögen encrypt bevorzugen.
smtpd_tls_cert_file: Unser Zertifikat für RSA
smtpd_tls_key_file: Unser Private Key für RSA
smtpd_tls_eccert_file: User Zertifikat für ECDSA
smtpd_tls_eckey_file: User Private Key für ECDSA
smtpd_tls_session_cache_database: Ein Cache für User Sessions. Steigert die Performance von Loginprozessen.
smtpd_tls_ciphers: Stärke der Kryptografie bei opportunistischer Kryptografie (smtpd_tls_security_level=may) Der Standardwert ist hier medium und ermöglicht auch die Kommunikation mit veralteten Mailservern. Der Wert sollte auf high gesetzt werden. Wir werden später noch anpassen, welche Chiphers bei high erlaubt sind. Im Zweifelsfall ist es nicht schlimm den Wert high zu nehmen, denn wir haben im Notfall immernoch ein Fallback auf unverschlüsselte Kryptografie.
smtpd_tls_mandatory_ciphers: Stärke der Kryptografie bei erzwungener Verschlüsselung (smtpd_tls_security_level=encrypt). Hier sollte eventuell überdacht werden, ob medium eine gute Wahl ist, weil Mails evtl. abgewiesen werden, wenn der Kommunikationspartner keine starke Verschlüsselung untersützt. Idealisten sollten hier trotzdem bei high bleiben. Irrelevant, falls (smtpd_tls_security_level=may).
smtpd_tls_protocols: Hier werden alte Protokolle wie SSLv2 (1995), SSLv3 (1996), TLS 1.0 (1999) und TLS 1.1 (2006) augeschlossen. Dies entspricht den aktuellen Empfehlungen. Es bleiben die aktuelle TLS 1.3 Spezifikation von 2018 und als Fallback TLS 1.2 von 2008, welches auch noch als hinreichend sicher gilt. Gilt für (smtpd_tls_security_level=may).
smtpd_tls_mandatory_protocols: Protokolle bei smtpd_tls_security_level=encrypt.
smtpd_tls_dh1024_param_file: Der Diffie-Hellman Schlüssel, den wir in einem vorherigen Schritt erzeugt haben. Wir ersetzten hier den standardmäßigen 1024 Bit Schlüssel durch einen 2048, 3072 oder 4096 Bit großen Schlüssel (je nach dem, wie Sie sich entschieden haben).
smtpd_tls_received_header: Fügt jeder E-Mail einen Header hinzu, welche Kryptografie zum Empfang der Mail verwendet wurde. Für Interessierte.
smtpd_tls_eecdh_grade: Sicherheit bei EECDH (elliptische Kurven Kryptografie). Im Default hier strong, was eine 128-bit Sicherheit verspricht. Bei ultra werden 192-bit verwandt, was zusätzliche Sicherheit verspricht. Der Rechenaufwand ist hier etwa doppelt so hoch wie bei 128-bit.
smtpd_tls_loglevel: Loglevel für TLS Aktivitäten. Wert zwischen 0 und 4. Bei 1 wird ein guter Trade-Off erreicht. Höhere Werte loggen sehr viel und werden unübersichtlich.
Wir konfigurieren Postfix für ausgehende Mails wie folgt:
Die Konfiguration ist ähnlich zu der obigen zu lesen, nur dass es hier um ausgehende Mails geht:
Die hier angegebene tls_high_cipherlist ist ein guter Kompromiss mit Fokus auf starke Kryptografie. Bei ImmuniWeb erhält man mit dieser Konfiguration eine A+ Rating (Stand Mai 2020). Wer es ausprobieren möchte: Server mit Port angeben (z.B. occumail.net:25). Bei CryptCheck erhält man ein A Ranking (96 von 100 Punkte).
tls_preempt_cipherlist sagt aus, dass der Server die Präferenzen bei der Cipher setzt und nicht auf ggf. vom Client kommende Präferenzen reagiert.
tls_ssl_options sollte auf NO_COMPRESSION aus Sicherheitsgründen auf NO_COMPRESSION gesetzt werden (BREACH, CRIME).
Nicht vergessen: Zum Schluss ein mal Postfix neu starten:
service postfix restart
TLS-Konfiguration von Dovecot
Dovecot hat für die SSL-Konfiguration eine Extra Konfigurationsdatei:
ssl: Sollte auf required stehen, sodass Verschlüsselung erzwungen wird. Eigentlich gibt es keinen ernst zu nehmenden Mailclient mehr, der die hier eingesetzte Verschlüsselung nicht unterstützt. Da wir nur das Beste für unsere Nutzer wollen, erzwingen wir daher Verschlüsselung. Wer einen Mailclient nutzt, der hier nicht funktioniert, der sollte lieber gebeten werden den Client zu wechseln als die Dovecot-Konfiguration anzupassen.
ssl_cert: Unser RSA Zertifikat
ssl_key: Unser RSA Private Key
ssl_alt_cert: Unser ECDSA Zertifikat als Alternative zu RSA
ssl_alt_key: User ECDSA Private Key als Alterntaive zu RSA
ssl_client_ca_dir: Liste vertrauter Zertifizierungsstellen. Wird durch das Betriebssystem unter /etc/ssl/certs zur Verfügung gestellt.
ssl_cipher_list: Unsere Ciphers. Wie bei Postfix auch.
ssl_dh: Der Diffie-Hellman Schlüssel, den wir vorhin schon für Postfix generiert haben. Je nach dem, dh_2048.pem, dh_3072.pem, dh_4096.pem
ssl_min_protocol: Minimale TLS Version. Mit der Angabe TLSv1.2 schließen wird SSLv2, SSLv3, TLS 1.0 und TLS 1.1 aus. TLS 1.3 ist natürlich zugelassen.
ssl_cipher_list: Die unterstützen Ciphers. Wie bei Postfix.
ssl_prefer_server_ciphers: Auswahl der Ciphers durch Server vor Cliententscheidung bevorzugen.
Damit wären wir auch schon fertig. Nicht vergessen, Dovecot neu zu starten:
service dovecot restart
Fazit
Nun haben wir es geschafft: Eine sichere Konfiguration von Postfix und Dovecot mit ausreichend Abwärtskompatibilität. Außerdem haben wir mit ECDSA-Zertifikaten aktuellste Kryptografie, die in Zukunft sicherlich vermehrt zum Einsatz kommen wird. Zudem erneuern sich unsere Zertifikate automatisch.
Ergebnisse für occumail.net von CryptCheck. Stand: 02.05.2020Ergebnisse für occumail.net von ImmuniWeb. Stand: 02.05.2020
Viele kennen sicherlich den SSL Report von Qualys SSL Labs. Nun möchte man natürlich gute Ergebnisse bzgl. Sicherheit erzielen, aber kann auch nicht die Abwärtskompatibilität völlig außer Acht lassen. Ich versuche hier einen nach aktuellem Stand guten Trade-Off vorzustellen. Außerdem möchten wir auch im CryptCheck, ImmuniWeb SSL Security Test, DigiCert® SSL Installation Diagnostics Tool und SSL-Tools Check gut abschneiden. In diesem Tutorial setze ich auf Debain, apache2 und certbot. Ähnliches lässt sich natürlich auch mit nginx und/oder acme.sh erreichen.
Grundlage für diesen Artikel war folgende Konfiguration:
Debian 10
Apache 2.4.38 (Befehl: apache2 -v)
certbot 0.31.0 (Befehl: certbot --version)
openssl 1.1.1d (Befehl: openssl version)
Zertifikat mit certbot erzeugen
Wer certbot noch nicht installiert hat, möge das nach der einfachen Anleitung auf der certbot-Homepage tun. Kommen wir nun erst mal zur Generierung und der Installation des Zertifikats. Während sich Qualys mit 2048 Bit RSA Zertifikaten zufrieden gibt, erhalten wir bei CryptCheck damit nur eine durchschnittliche Bewertung. Für den RSA Schlüssel empfiehlt das BSI (Bundesamt für Sicherheit in der Informationstechnik) noch bis Ende 2023 eine Schlüssellänge von 2048 Bits, die als sicher gelte. Danach werden 3072 Bits empfohlen. Nachzulesen in der Sicherheitsrichtlinie BSI TR-02102-1 (Stand: 24. März 2020). Wir wählen hier 3072 Bits, weil das einem guten Kompromiss aus Sicherheit und Performance entspricht (Paramater --rsa-key-size 3072). Wer noch eins drauf setzten möchte, kann natürlich auch 4096 Bits nehmen.
Auf jeden Fall benötigen wir noch HTTP Strict Transport Security (HSTS). Dabei handelt es such um einen HTTP Header, der z.B. durch Apache gesetzt werden kann, und aussagt, dass diese Seite (für einen sehr langen Zeitraum) vom Browser nur noch per https aufgerufen werden darf. Unverschlüsselter Datenverkehr wird also für die Zukunft ausgeschlossen. Der Paramater lautet --hsts. Außerdem sollten wir eine Weiterleitung von http auf https einrichten. Auch das tut certbot für uns (Paramater --redirect). Der Befehl lautet also wie folgt:
certbot hat nun für uns die Datei /etc/letsencrypt/options-ssl-apache.conf erzeugt, die wie wie folgt editieren:
SSLEngine on
# Intermediate configuration, tweak to your needs
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384
SSLHonorCipherOrder on
SSLCompression off
Als SSL-Protokolle müssen wir in jedem Fall TLS 1.0 und TLS 1.1 herausnehmen, da wir seit Januar 2020 bei Qualys auf Grad B gestutzt werden. Es verbleiben die sicheren Versionen TLS 1.2 und TLS 1.3. Diese Protokolle gelten als nicht mehr hinreichend sicher. Die Wahl der Chipher-Suits war eine lange Suche und ausprobieren. Sie sorgen in Qualys dafür, dass wir einen sehr guten A+ Rank erhalten, aber keine Hanshake Simulation fehlschlägt. Auch ImmuniWeb verpasst uns einen A+ Rank. Auch bei CryptCheck erhalten wir eine A+ Raking mit 93/100 Punkten. Hätten wir RSA mit 4096 Bits genutzt, wäre CryptCheck mit 96/100 Punkten übrigens noch ein bisschen Glücklicher gewesen, weil wir 100/100 beim Schlüsselaustausch bekommen hätten. Ich halte das allerdings für etwas übertrieben.
Abschließend sollte man noch mal über DNS Certification Authority Authorization nachdenken. Der Folgende DNS Eintrag besagt, dass unser Zertifikat von Let’s Encrypt stammen muss und sorgt so für noch etwas mehr Sicherheit:
Wir haben es also geschafft: Ein Top Security Rank in allen mir bekannten Tests. Wer jetzt noch etwas mehr tun möchte, kann sich noch über DANE bzw. einen TLSA DNS-Eintrag Gedanken machen. Hier wird ein Hash des eigenen Zertifikats als DNS Eintrag hinterlegt, sodass das Zertifikat nicht unbemerkt ausgetauscht werden kann. Hier gibt es einen Generator dafür.
Auch einen Blick wert ist das Mozilla Obversatory, welches einem vor allem Vorschläge für diverse HTTP-Header macht. Für einfache Seiten ist dies relativ einfach umzusetzen, aber für CMS Software wie WordPress wird es schon schwieriger. In einem zukünftigen Artikel habe ich vor, mich mit dem Content Security Policy Header für WordPress zu beschäftigen. Stay Tuned!
