Inhaltsverzeichnis
Du benötigst als mittelständischer Unternehmer, Geschäftsführer oder IT-Leiter Unterstützung bei Projekten im Bereich IT-Infrastruktur oder IT-Sicherheit? Kontaktiere mich gerne für ein kostenfreies Erstgespräch.
Auch wenn ich mich ja sonst oft und gerne in der Microsoft-Welt tummle, bin ich von Windows Webservern irgendwie noch immer kein wirklicher Fan. Dennoch kann aufgrund bestimmter Applikationen und Situationen die Notwendigkeit bestehen, einen Windows Webserver bereitzustellen.
Stellst Du einen solchen Windows Webserver mittels IIS bereit, so solltest Du einige zusätzliche Anstrengungen unternehmen, um diesen Server zu härten. Grundsätzlich ist selbstredend auch bei internen Servern stets darauf zu achten, dass unnötige Einstellungen, Ports etc. deaktiviert sind. Aber gerade bei Webservern gilt es zusätzliche Konfigurationen vorzunehmen, da sie in der Regel für die gesamte Außenwelt – und somit einem größeren Angreiferkreis – erreichbar sind.
Daneben gelten insbesondere für Windows Webserver Sicherheitsaspekte, die auch schon für gewöhnliche interne Server aus meiner Sicht eine Selbstverständlichkeit darstellen: Komplexe Benutzer-Kennwörter, ggf. administrative Konten umbenennen (z. B. den SID500 Administrator) und Windows Updates einspielen.
Folgend gehe ich nicht weiter auf eventuell vorhandene Firewalls, die vor dem Webserver hängen, ein. Auch das Thema Antivirus greife ich nicht auf, da es hierbei teils sehr kontroverse Ansichten über den Sinn und Unsinn auf Webservern gibt. Der Webserver wird autark betrachtet und entsprechend justiert. Mögliche Alternativen ergeben sich seit Windows Server 2016 auch mit Containern oder einer Installation auf einem Nano Server. Diese beiden Varianten dürften künftig auch die präferierte Wahl sein, obgleich einige Einstellungen vermutlich dennoch umzusetzen sind. In diesem Guide wird aber erstmal von einem klassischen Windows-Server ausgegangen.
Mit Qualys SSL Server Test einen ersten Eindruck über den Windows Webserver gewinnen
Im weiteren Verlauf gehe ich davon aus, dass Dein Windows Webserver über das Internet bereits erreichbar ist. Zumindest soweit erreichbar, als dass Du mittels dem Webtool Qualys SSL Server Test eine erste Überprüfung Deines Webservers durchführen kannst. Dieser Schritt ist grundsätzlich optional, z. B. wenn Du Deinen Webserver nicht „ungesichert“ von außen erreichbar machen willst.
Öffne zunächst die Seite des Qualys SSL Server Tests und gebe bei Hostname Deine URL ein. Achte darauf, dass Du den Haken bei Do not show the results on the boards aktivierst. Andernfalls sehen andere nämlich Deine Hostnamen in der Liste der zuletzt durchgeführten Tests.
Das Webtool überprüft daraufhin die Konfiguration Deines Webserver u. a. auf die Verwundbarkeit der POODLE-Attacke, schwachen Verschlüsselungsprotokollen etc. Ein Ergebnis wie im nachfolgenden Screenshot bedeutet dringenden Handlungsbedarf. Anstatt einem F solltest Du ein A erreichen.
Anfällige Protokolle und Verschlüsselungsverfahren deaktivieren mit IIS Crypto
Im ersten Schritt der Härtung werden anfällige Verschlüsselungsverfahren wie SSL 3.0 oder TLS 1.0 abgeschaltet, da diese anfällig für diverse Angriffsszenarien sind. Ein Beispiel ist die bereits erwähnte POODLE-Attacke, welche eine Schwachstelle in SSL 3.0 ausnutzt. Ein „Nachteil“ der Deaktivierung kann sein, dass alte Browser nicht mehr auf Deine Webseite zugreifen können. Aber ganz ehrlich? Läuft Deine Seite überhaupt zufriedenstellen in einem Internet Explorer 6 oder anderen Uralt-Browsern? Auf die würde ich persönlich eh keine Rücksicht mehr nehmen 😉
Achtung! Du musst allerdings sicherstellen, dass Du einen RDP-Client einsetzt, der die Protokoll-Version 8.0 unterstützt. D. h. wenn Du bspw. noch von einem Windows 7 Client arbeitest, musst Du ein Updatepaket für RDP 8.0 installieren. Andernfalls kannst Du nicht mehr auf Deinen Windows Webserver per RDP zugreifen, da für den Zugriff TLS 1.0 benötigt wird.
Auch wenn ein SQL-Server auf dem Webserver betrieben werden sollte, gilt es ein paar Punkte zu beachten. Microsoft beschreibt in einem TechNet-Beitrag, dass etwa für SQL Server 2012 SP3 das CU1 und für SQL Server 2014 SP1 das CU 5 installiert sein muss. Grundlegend sollest Du dir aber überlegen, ob ein SQL Dienst auf einem Webserver etwas zu suchen hat, oder ob Du diesen Dienst nicht lieber auf einen zweiten Server auslagerst, der nur für Deinen Webserver über die notwendigen Ports und Protokolle erreichbar ist.
Die folgenden Einstellungen lassen sich auch über die Registry setzen, aber als Admins haben wir ja schließlich knappe Zeitressourcen 😉 Also erleichtern wir uns die Arbeit mit einem kleinen, schlanken und kostenlosen Tool namens IIS Crypto von Nartac Software. Das Tool ist portabel und muss demnach nicht installiert werden. IIS Crypto ist für Windows Server 2008, 2012 und 2016 freigegeben – auch wenn seit 2016 keine Aktualisierung mehr erfolgt. Die Version 2.0 ist also immer noch die aktuellste.
Was macht IIS Crypto?
Das Tool erleichtert Dir die Konfiguration der Einstellungen wie TLS- und SSL-Protokolle. Dabei orientiert es sich an dem TechNet Artikel How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll. Die Einstellungen werden so vorgenommen, als wenn Du sie über die GPEDIT.MSC durchführen würdest. Des Weiteren können benutzerdefinierte Templates erstellt oder auf ein Best Practises Template zurückgegriffen werden. Letzteres ist für die meisten Anwendungsfälle gut und ausreichend. Wer die Konfiguration automatisieren will, kann übrigens neben der GUI-Version auch auf eine CLI-Version zurückgreifen.
IIS Crypto starten und Einstellungen vornehmen
Wenn Du die Anwendung startest, wirst Du in dem sich öffnenden Fenster links einen Reiter mit verschiedenen Kategorien und in der Mitte die Einstellungen sehen. Vermutlich werden SChannel (Secure Channel) wie SSL 3.0 und TLS 1.0 noch aktiviert sein. Erstelle ggf. einen Screenshot, damit Du bei Bedarf später wieder auf den Ursprungszustand zurückspringen kannst, sollte irgendwas nicht wie erwartet funktionieren. Anschließend klickst Du auf den Button Best Practises. Daraufhin werden einige Häkchen wie SSL 3.0 verschwinden. TLS 1.0 bleibt jedoch noch bestehen. Diesen musst Du manuell abhaken.
Danach wechselst Du in den Reiter Cipher Suites, um veraltete Kryptograophie-Algorithmen abzuschalten. Auch hier am besten vorab wieder einen Screenshot erstellen und danach auf den Button Best Practises klicken. Sobald Du auf Apply klickst, werden die Änderung übernommen. Ein Neustart des Servers ist erforderlich, damit die geänderten Einstellungen auch in Kraft treten.
Die ersten Schritte sind getan, ein erneuter Test beim Qualys SSL Server Test sollte bereits jetzt ein deutlich besseres Resultat liefern.
Erweitere Windows Firewall überprüfen
Im nächsten Schritt solltest Du die Einstellungen der Windows Firewall Deines Windows Webservers überprüfen. Grundsätzlich kann natürlich vor Deinem Webserver eine Drittanbieter-Firewall hängen, die sich um das Thema IT-Security kümmert, bestimmte Ports und Anwendungen zulässt oder sperrt.
Dennoch sollte aus meiner Sicht auch die Firewall auf der Seite des Windows Servers sauber eingestellt sein. Und sei es einfach nur, um Deinem Defense-In-Depth Ansatz eine zusätzliche Sicherheitsschicht hinzuzufügen. In der erweiterten Windows Firewall schaust Du als Erstes in die Inbound-Rules, also den eingehenden Regeln. Hier würde ich zunächst einmal nach aktiven Regeln filtern, um einen besseren Überblick zu gewinnen.
Mein Ansatz ist es ferner, mir erstmal eine eigene Hauptregel anzulegen (Z. B. Firmenname), die alles darf. Damit kann vermieden werden, den Ast abzusägen, auf dem ich sitze. Hier ist auf jeden Fall darauf zu achten, unter Scope den erlaubten Remote IP Adressbereich auf Deine IP-Adresse oder IP-Range einzuschränken. Dies funktioniert natürlich nur einwandfrei, wenn Du von einer festen IP bzw. einem festen IP-Bereich zugreifst, der Dir gehört.
Im Anschluss sollten die erlaubten Inbound-Regeln soweit wie möglich reduziert werden, sodass nur noch die nötigsten Regeln aktiv sind. Beispielsweise sollte RDP (Port 3389) auf keinen Fall über das Web frei erreichbar sein, sondern nur für Deine feste IP. Ein Angreifer könnte sich andernfalls remote verbinden, sehen, mit welchem User Du angemeldet bist, Kennwörter testen usw. Auch bei anderen etwaig benötigten Protokollen wie SMTP würde ich den IP Scope zu eng wie möglich ziehen. Andere Regeln wie World Wide Web Services (HTTPS) müssen in den meisten Fällen natürlich auf Any stehen bleiben, damit Deine Webseiten-Nutzer die Webseite auch aufrufen können.
Zweitranging solltest Du dann noch die Outbound-Regeln, also die ausgehenden Regeln, kontrollieren. Auch hier würde ich geschwätzige Anwendungen deaktivieren und nur das Nötigste behalten.
Du hast alle Regeln konfiguriert? OK, dann teste das Ganze doch mal. Sind wirklich alle unnötigen Ports geschlossen und von außen nicht mehr erreichbar. Suche dazu via Google mal nach dem Begriff Online Port Scanner, um tatsächlich außerhalb zu prüfen. Wenn Du Deine über Deine eigene, berechtigte IP-Adresse z. B. mit NMAP scannst, bringt Dir das nicht viel…
Internet Information Services (IIS) härten
Im nächsten Schritt sollen Parameter gesetzt werden, um den Webdienst von IIS zu härten. Im Folgenden nehme ich an, dass Du bereits ein Binding für HTTPS und Port 443 erstellt hast. Des Weiteren solltest Du unter am besten im Abschnitt Service Certificates auch ein eigenes SSL Zertifikat eingespielt haben.
Webseite dauerhaft auf HTTPS umstellen
Um Deine Site automatisch von http:// auf https:// umleiten zu lassen, greifst Du am besten auf die kostenlose IIS-Erweiterung URL Rewrite zurück und erstellst eine entsprechende eine Regel zur Umleitung. URL Rewrite unterstützt in der Version 2.1 sowohl IIS 8.0 und 8.5 als auch 10.0.
Nach der Installation befindet sich im IIS Manager ein neues Icon mit dem Namen URL Rewrite. Hier erstellst Du jetzt eine neue Regel via Add Rule und wählst dann den Eintrag Blank Rule aus.
Stelle im Anschluss die folgenden Einstellungen ein:
- Match URL
- Requested URL: Matches the Pattern
- Using: Regular Expressions
- Pattern: (.*)
- Ignore case anhaken
- Conditions
- Logical grouping: Match all
- Via Add hinzufügen
- Condition Input: {HTTPS}
- Type: Matches the Pattern
- Pattern: ^OFF$
- Server Variables
- Keine
- Action
- Action Type: Redirect
- Action Properties -> Redirect URL: https://{HTTP_HOST}/{R:1}
- Haken bei Append query string setzen
- Redirect Type: Permanent (301)
HTTP Strict Transport Security (HSTS) aktivieren
Um die Sicherheit zusätzlich zu erhöhen und um eine Maßnahme gegen Man-in-the-Middle-Angriffe umzusetzen, empfiehlt sich die Aktivierung von HTTP Strict Transport Security (HSTS). HSTS dient zur Absicherung von HTTPS-Verbindungen, indem sie vor der Aushebelung der Verbindungsverschlüsselung in Form einer Downgrade-Attacke oder vor Session-Hijacking schützen soll. Dazu teilt der Server dem Webbrowser über einen HTTP Response Header mit, für eine durch den Server-Administrator definierte Zeit ausschließlich verschlüsselte Verbindungen zu zulassen (Ausführlich im RFC6797 nachzulesen).
Um HSTS auf dem Windows Webs15erver zu aktivieren, muss nun ein entsprechende HTTP Response Header angelegt werden.
Öffne dazu im IIS Manager den Abschnitt HTTP Response Headers
Klicke oben rechts auf Add, um einen neuen Response Header zu erstellen. Als Namen trägst Du nun strict-transport-security ein. Unter Value trägst Du folgende Zeile ein
max-age=31536000; includeSubdomains
Die Max-Age Zeit entspricht einem Jahr in Sekunden. Subdomains sollen ebenfalls berücksichtigt werden.
Fazit
Mit diesen grundlegenden Einstellungen hast Du die Sicherheit von IIS und Deinem Windows Webserver schon ein ganzes Stück erhöht. Es gibt noch andere Stellschrauben, an denen man drehen kann – aber das sind aus meiner Sicht erstmal mit die Wichtigsten überhaupt.
Welche Tipps und Erfahrungen hast Du noch? Betreibst Du Windows Webserver und was unternimmst Du darüber hinaus, um die Sicherheit des Servers zu erhöhen? Schreib es mir gerne in die Kommentare.
