Sicherheit für DNN-Installationen Teil 2 - HTTPS

Wir wollen also DNN für uns und die Sicherheit unserer Besucher absichern - Maßnamen übrigens, die auch im Zusammenhang mit der kommenden DSGVO (Datenschutzgrundverordnung) zu tun haben, denn es geht hierbei auch um Datensicherheit.

Als ersten Schritt von vertrauensbildenden Maßnahmen wollen wir die Kommunikation der Besucher mit der Website verschlüsseln. Dazu ist die Installation eines Zertifikats notwendig. Je nach Zweck der Website kann dabei ein kostenloses Zertifikat (wie z.B. von Let's Encrypt), welches nur der Feststellung der Identität des Server dient, oder ein personalisiertes (aber kostenpflichtiges) Zertifikat verwendet werden (beim Betrieb eines Webshops z.B.).

Schritt 1: AAAA-Record in DNS eintragen

Ich bin mir nicht ganz sicher, ob der später vorgestellte ACME-Client oder die Zertifikatsanforderung dran "schuld" ist, aber Fakt ist, dass ich bei der Anforderung einer solchen irgendwann einmal (nachdem es davor immer funktioniert hatte) eine eher kryptische Fehlermeldung bekam. Nach langem Suchen fand ich den Hinweis darauf, dass im DNS kein AAAA-Record eingetragen war (was vorher auch nie der Fall war). Dieser Record dient zur Auflösung der IP v6-Adresse und ist jedenfalls durchzuführen.

Hier gibt es ausnahmsweise keine Anleitung. Denn je nachdem, ob man das selbst tun kann (DNS-Zugang erforderlich) oder ob man dazu seinen Provider kontaktieren muss ist es auch abhängig vom verwendeten DNS-Client immer unterschiedlich, wie das gemacht wird.

Überprüfen lässt es sich allerding recht einfach: in einer Konsole einfach den Befehl "nslookup" und die Url der Website eingeben:

Wird hier eine IP v6-Adresse angezeigt (in dem Fall 2a03:f80:ed15:37:235:56:56:0) dann ist alles in Ordnung.

Nachdem es eine gewisse Zeit benötigt, bis das DNS-System weltweit Bescheid weiß können nach dem erfolgten Eintrag im DNS-Server mehrere Stunden vergehen – was allerdings erst ab Schritt 6 eine Rolle spielt.

Ich würde unbedingt empfehlen, den entsprechenden Record für alle Websites am System einzutragen (bzw. eintragen zu lassen):

Schritt 2: Url Rewriter Modul in IIS installieren

Dazu klickt man zunächst im IIS Manager rechts unter Aktionen "Neue Webplattformkomponenten abrufen", um den Webplattform-Installer zu starten:

Im Suchfeld "Url" eingeben und die Eingabetaste drücken:

Im entsprechenden Suchergebnis auf [Hinzufügen] klicken:

Dann auf [Installieren] klicken:

Den Lizenzbedingungen zustimmen:

Installation abwarten, auf [Fertig stellen] klicken:

Schritt 3: Let’s Encrypt – Client installieren

Es gibt in der Zwischenzeit einige ACME-Clients für Windows, ich verwende letsencrypt-win-simple, ein einfaches Kommandozeilen-Werkzeug, das z.B. über PowerShell aufgerufen werden kann. Das Tool kann von GitHub heruntergeladen werden. Zur Zeit der Erstellung dieses Blogs ist die Version 1.9.8.0 aktuell.

Die Installation ist denkbar einfach: Man erstellt auf dem Server ein Verzeichnis (z.B. C:\LetsEncrypt), kopiert die heruntergeladene ZIP-Datei dort hinein und entpackt sie (am besten mit 7Zip, rechte Maustaste und "Hier entpacken").

Updates werden genauso installiert, einfach bestehende Dateien überschreiben.

Alternativen

Ich habe keine Erfahrung mit anderen Tools, daher möchte ich hier nur eines erwähnen: Certify The Web ist ein Tool mit grafischer Oberfläche, das für bis zu fünf verwalteten Websites kostenlos ist. Nähere Informationen findet man unter https://certifytheweb.com/.

Schritt 4: X3.UrlManagement installieren

Auf der abzusichernden DNN-Website ist es nützlich, das X3.UrlManagement Modul zu installieren, weil damit einiges erleichtert wird. Das Tool ist (momentan noch) unter http://dnnurlmanagement.codeplex.com erhältlich, auf GitHub ist es unter https://github.com/mathisjay/X3.DnnUrlManagement verfügbar, allerdings steht hier (noch) keine Release zur Verfügung. Installiert wird es wir jedes andere Modul. Danach erstellt man (am besten unter "Administrator") eine Seite, auf der man eine Instanz dieses Moduls platziert.

Benutzerdefinierte Fehlerseiten

Bevor man weiter arbeitet sollte man für die Seiten zur Behandlung der HTTP-Fehler 404 (Seite nicht gefunden) und 500 (interner Serverfehler) erstellen. Ich gehe hier nicht auf diese Problematik ein, die ist an anderen Stellen zur Genüge beschrieben.

Im X3-Modul stellt man dann diese Seiten als Fehlerseiten ein:

Auch die Datei web.config muss für diesen Zweck noch angepasst werden, dazu später.

Zu ignorierende reguläre Ausdrücke

Die Anforderung eines Let’s-Encrypt-Zertifikats erfordert Zugriff auf einen Ordner namens ".well-known". UNIX- und Linux-Kenner wissen: Beginnt ein Datei- oder Verzeichnisname mit einem Punkt, so ist dies eine versteckte Datei bzw. ein verstecktes Verzeichnis. In Windows ist das zwar nicht so, der Ordner muss trotzdem so heißen. Der Ordner muss auch nicht als versteckt markiert werden.

In den regulären Ausdrücken muss zu diesem Zweck die Einstellung für "Ignore URL Regular Expressions" von

(?<!linkclick\.aspx.+)(?:(?<!\?.+)(\.pdf$|\.gif$|\.png($|\?)|\.css($|\?)|\.js($|\?)|\.jpg$|\.axd($|\?)|\.swf$|\.flv$|\.ico$|\.xml($|\?)|\.txt$))

auf

(?<!linkclick\.aspx.+)(?:(?<!\?.+)(\.pdf$|\.gif$|\.png($|\?)|\.css($|\?)|\.js($|\?)|\.jpg$|\.axd($|\?)|\.swf$|\.flv$|\.ico$|\.xml($|\?)|\.txt$)|\.well-known)

geändert werden:

Schritt 5: MIME Type für die Website hinzufügen

Dieser Schritt ist in IIS 10 (Windows 2016 Server) nicht mehr notwendig, im Gegenteil, es kann passieren, dass die Zertifikatsanforderung nicht mehr funktioniert, wenn man es setzt. Unter den Vorgängern ist es jedoch zwingend erforderlich.

Der Schritt hat nun mit dem bereits angesprochenen Ordner ".well-known" zu tun. Damit der IIS dies nicht als Skript sieht und den Download aus diesem mit einem Fehler 404.17 blockiert muss ein entsprechender MIME-Type angelegt werden.

Im IIS-Manager markiert man zunächst die Website und öffnet dann mit einem Doppelklick die MIME Types:

Unter Aktionen (rechte Seite) klickt man auf "Hinzufügen" und gibt dann folgenden neuen MIME Type an:

Dateinamenserweiterung: . (Punkt)
MIME Type: text/plain

Schritt 6: Let’s Encrypt!

Nun sind alle Vorbereitungen zur Installation des Zertifikats getroffen – und der Spaß kann beginnen.

Zunächst öffnet man eine Konsole (sicherheitshalber als Administrator) und wechselt in den Ordner, in dem man den ACME-Client (siehe Schritt 3) installiert hat.

Danach gibt man folgenden Befehl ein:

letsencrypt.exe --accepttos --plugin manual --manualhost www.mydomain.com --webroot C:\DNN

Danach muss noch das Binding auf der Web-Site erstellt werden. Im IIS Manager klickt man dafür mit der rechten Maustaste auf die Website und wählt aus dem Kontextmenü "Edit Bindings". Dann wählt man "Add" und gibt folgendes ein:

(Unter Hostname den tatsächlichen Hostnamen eintragen, z.B. www.mydomain.com, unter SSL certificate das soeben erstellte Zertifikat auswählen)

Danach ist die Site auch unter https erreichbar:

Schritt 7: HTTPS erzwingen

Im nächsten Schritt wollen wir HTTPS für die Website erzwingen – wenn also jemand http://www.mysite.com eingibt, soll automatisch auf https://www.mysite.com umgeleitet werden, und nur mehr verschlüsselte Requests und Antworten zugelassen werden.

Dazu muss man aber sagen, dass durch eine automatische Umleitung die Möglichkeit eines Man-In-The-Middle-Angriffszenarios möglich ist. Andererseits geben wenige User das Protokoll in der die Url ein, sondern etwa:

www.meintelebanking.com

Der Browser führt hier zunächst einmal einen HTTP-Request durch, nachdem die Bank aber die Seiten für das Telebanking nur verschlüsselt ausliefert (sonst sollte man dringend die Bank wechseln!) antwortet der Webserver mit einem HTTP-301-Statuscode ("Moved permanently") und leitet den Request auf die Adresse mit dem HTTPS-Protokoll um. Da die erste Anfrage unverschlüsselt erfolgt ist sie anfällig für Manipulation. Ein Angreifer könnte in einer manipulierten Antwort auf eine andere Seite (die zumindest einmal gleich aussieht, eine ähnliche aussehende Adresse verwendet und mit einem Zertifikat ausgestattet ist) umleiten, dort Benutzernamen und Passwort abfragen und dann mit diesen Daten den Browser wieder über HTTPS zum Telebanking schicken. Auffallen würde das wahrscheinlich nicht so schnell.

Lesestoff dazu: https://www.troyhunt.com/owasp-top-10-for-net-developers-part-9/ (der Abschnitt "Try not to redirect from HTTP to HTTPS" im unteren Drittel).

Hier muss also zwischen Usability und Sicherheit abgewogen werden.

Ich gehe (noch) den Weg der Usability. Was nun notwendig ist, sind einige Einträge in der Datei web.config im Stammverzeichnis der DNN-Installation.

Suchen wir zunächst einmal das Ende des Abschnitts system.webserver. Davor (also noch innerhalb dieses Abschnitts) tragen wir unsere rewrite-rules ein:

<rewrite>
   <rules>
      <rule name="HTTP to HTTPS redirect" stopProcessing="true">
         <match url="(.*)" />
         <conditions>
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
         </conditions>
         <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
      </rule>
   </rules>
</rewrite>

Damit wäre die Umleitung erledigt – von "sicherer" Kommunikation können wir allerdings noch nicht ausgehen. Da bleibt noch einiges zu tun...

Weiter: Sicherheit für DNN-Installationen Teil 3 - Sicherheitseinstellungen für ASP.Net-Installationen