Über

Meinen Blog gibt es nun schon seit fast 10 Jahren, verrückte Sache. Und obwohl ich grob über 300 Tutorials und How-To’s geschrieben habe, ist es wie so oft: Der Schuster hat gerne mal die schlechtesten Leisten. Wartung und Pflege des eigenen Systems geraten bei viel Stress und wenig freier Zeit in den Hintergrund. So kommt es, dass mich die Firma Enginsight letztens kontaktiert hat. Der Inhalt war ein weniger positiv – man übergab mir einen Sicherheitsbericht meines Blogs. Dieser enthielt Bewertungen in mehreren Kategorien und leider nicht nur gute, dazu später mehr. Das war der Anlass, dass ich mich mit der Sicherheits-Suite von Enginsight und der Sicherheit meines Blogs detaillierter auseinandergesetzt habe.

Erster Eindruck

Die Suite von Enginsight möchte mit ihren Tools die Sicherheit und Verfügbarkeit von IT-Netzwerken erhöhen und den Aufwand der Wartung und Überwachung verringern. Das Netzwerk kann hier beliebig verschieden und groß sein – von 1 Webseite, einem PC oder Server bis hin zu einem aus mehreren Nodes und Netzwerkkomponenten bestehenden Netzwerk.

Dank des 14-tägigen Probeaccounts lässt sich die Suite auch direkt selbst ausprobieren. Nach dem Login lande ich auf einem sehr übersichtlichen Dashboard, in dem mir meine eingerichteten Assets (in diesem Moment natürlich noch keine) angezeigt werden. Über eine Menüleiste habe ich schnellen Zugriff auf die wichtigsten Funktionen: Umgebungen, Hosts, Endpunkte, Alarme, Einstellungen, Suche, mein Profil sowie einigen weiteren Kleinigkeiten.

webseiten-netzwerke-analysieren-kontrollieren-enginsight-suite-dashboard
Übersichtliches Enginsight Dashboard mit ersten angelegten Assets

Detaillierte Analysen

Ich habe hier direkt meinen Blog als einen Endpunkt angelegt. Endpunkte sind Webseiten oder Webapplikationen, für die verschiedene Funktionen zur Verfügung gestellt werden: Webseite (Verfügbarkeitstests aus EU/USA), SSL/TLS, Web Thread Intelligence, Portscan, HTTP-Headers und Redirects. Die Funktionen können flexibel hinzugefügt werden. Anschließend starten direkt die ausgewählten Untersuchungen auf das eingegebene Ziel und nur wenige Sekunden später erhalte ich eine ausführliche Analyse meiner Seite:

Schnell ist klar: Hier muss was gemacht werden! Ich gehe mal kurz die Features durch und was jeweils untersucht wird:

  • Webseite: Stündliche Verfügbarkeitstests von Servern aus Frankfurt (EU) oder East-Virginia (USA), Analyse der Verbindungszeiten (wieviel Millisekunden Lookup, Connect, Transfer usw.)
  • HTTP-Headers: Analyse der Antwort-Header-Eigenschaften und speziell der Security-Header. Dazu mehr im Kapitel weiter unten
  • SSL/TLS: Untersuchung des verwendeten SSL-Zertifikats, der unterstützten Protokolle und Chiffren sowie möglicher Sicherheitslücken bzgl. SSL
  • Redirects: Weiterleitungen der Domain
  • Web Threat Intelligence: Prüfung von Sicherheitslücken beim Server, benutzten Anwendungen, der Webseite, benutzter Frameworks und Errechnung eines Scores
  • Portscan: Offene Ports und deren Service, ggf. Informationen zu eingesetzter Software und Version hinter einem Port

Ein Bericht hat mir dabei besonders wenig gefallen: Die Bewertung F bei den HTTP-Header. Also habe ich hier mal einen detaillierteren Blick geworfen:

Crashkurs HTTP-Headers

HTTP-Header sind Anweisungen, die vom Server- oder Webseitenbetreiber konfiguriert werden, um die Sicherheit des Webangebots sowie der Besucher zu erhöhen
Die Anweisungen können, je nach Hosting Setup, recht einfach über die .htaccess (empfohlen beim Shared Webhosting) gesetzt werden.
Im folgenden nenne ich zwei beispielhafte Security-Header, es gibt jedoch noch mehr:

HTTP Strict Transport Security (HSTS)

HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über HTTPS/SSL vom Client zum Server geschickt werden müssen. Anfragen über HTTP werden innerhalb dieses Zeitfensters dann komplett geblockt. Eine Beispielkonfiguration wäre:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Anzupassen: max-age als Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. includeSubDomains erweitert dieses Verfahren auf alle Subdomains. Weitere Informationen und Details zu HSTS und die preload-Eigenschaft in meinem separaten Artikel zum Thema HSTS und XSS-Protection hier.

Content-Security-Policy (CSP)

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen und Code-Injections, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.

Die Kontrolle der Inhalte wird hierbei in unterschiedliche Kategorien (auch Direktiven genannt) aufgeteilt und jeweils können erlaubte Datenquellen definiert werden. Beispielsweise gibt die Direktive script-src an, von welchen Domains und Quellen Skripte in die geschützte Seite eingebunden werden dürfen. Ein CSP-Beispiel:

Header always set Content-Security-Policy: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://wordpress.org data:; script-src 'self'; font-src 'self' fonts.gstatic.com; report-uri https://report-uri.de/report.php"

Diese CSP definiert erlaubte Datenquellen für die Direktiven default-src, img-src, script-srcfont-src und definiert einen Bericht-Endpunkt mit report-uri. Die Angabe ’self‘ erlaubt Daten von der eigenen Domain, in der die CSP benutzt wird. Zusätzlich wurden für Bilder die Domains von gravatar.com und wordpress.org sowie die Einbindung von data-uri Bildern als Ausnahmen definiert. Ebenso das Laden von Schriften vom Google Repository. Wenn ein Angreifer nun versucht, beispielsweise über einen Kommentar ein Skript von seiner Angreiferdomain einzubetten, würde die CSP dies blocken, da nur die eigene Domain Skripte einbinden darf.

Mehr zum Aufbau und Einrichtung des CSP Header in meinem Artikel zu diesem Thema hier.

Sicherheit von Hosts auch mit Künstlicher Intelligenz überwachen

Zurück zur Enginsight-Suite, denn hier gibt es noch viel mehr zu entdecken! Aus Gründen der Komplexität reiße ich die folgenden Features nur grob an.

Wie eingangs erwähnt, lassen sich auch Computer und Server in das System einfügen und durchleuchten. Dafür wird ein Client auf den Geräten eingerichtet und schon werden etliche Systemkomponenten untersucht: Auslastung von CPU, RAM, SWAP, integrierte Partitionen, Netzwerkschnittstellen, installierte Software und Updates sowie laufende Prozesse. Daran erkennt Enginsight dann mögliche Sicherheitsrisiken und gibt Handlungsempfehlungen.

Außerdem wacht eine auf Neuralen Netzwerken basierende Künstliche Intelligenz über die erfassten Daten. Auf Wunsch erkennt diese beispielsweise wenn personenbezogene Daten das Netzwerk verlassen oder bestimmte Metriken wie CPU oder RAM ihre Normalwerte verlassen. Basierend auf den gelernten Daten erkennt die KI Anomalien und alarmiert den Admin. Dieser kann den Vorfall dann einstufen und die KI lernt für zukünftig Entscheidung aus diesem Handeln. Somit wird die KI immer intelligenter und der Admin hat weniger Verwaltungsaufwand.

Im Peacemaker werden die Systemupdates aller angelegten Hosts in einer Übersicht angezeigt und können direkt verwaltet werden. So lassen sich beispielsweise unter Linux Updates direkt aus Enginsight heraus installieren.

Unter dem Menüpunkt Umgebung versteckt sich ein Visualisierungstool, mit dem die angelegten Assets miteinander in Verbindung gebracht werden können. Außerdem lassen sich hier auch Notizen oder ganze Dokumentationen für jedes Asset hinzufügen. So fehlt nie der Überblick bei komplexen Infrastrukturen.

Automatisierung über Alarme und Plugins

Zwei weitere Funktionen lassen sich gut kombinieren, um eine Automatisierung von Maßnahmen im Problemfall zu realisieren: 
Alarme können erstellt werden, um regelmäßige Überprüfungen durchzuführen und im Problemfall Maßnahmen zu ergreifen. Mögliche Überwachungen bei einem Endpunkt: Response Time, Tage bis Zertifikatsablauf, Webseite nicht erreichebar, Neue Sicherheitslücke, Datenschutzverstoß. Für Hosts gibt es noch mehr, hier nur ein paar: Temperatur, neue oder entfernte Programme, Verdächtiger Netzwerkverkehr. Natürlich lassen sich hier Benachrichtigungen einstellen, aber als besonderes Extra gibt es auch Plugins, die im Problemfall ausgeführt werden können.

Plugins sind im Skripte, die selbst geschrieben werden können. Zur Verfügung stehen die drei Sprachen: Bash, Powershell und Python. Plugins können per Cronjob regelmäßig ausgeführt oder eben von Alarmen getriggert werden. Dem Troubleshooting sind mit diesen drei Sprachen kaum Grenzen gesetzt. Beispielsweise könnten per SSH im Falle des Ausfalls bestimmter Webseiten die Netzwerksettings vom Server geändert oder repariert werden.

Fazit

Die Enginsight-Suite bietet eine große Palette an Sicherheits- und Überwachungsfeatures (nicht alle konnte ich in diesem Artikel vorstellen), mit denen sich einzelne Assets oder ganze Netzwerke analysieren und steuern lassen können. Dank KI-Metrik-Überwachung, Alarmen, Plugins und anderen kombinierbaren Lösungen ist hier eine großes Potential für Automatisierung, wenn alles richtig eingerichtet wird. Das Produkt ist immernoch stark in der Entwicklung und der Kontakt zum Enginsight-Team war äußerst angenehm – hier steckt viel Herzblut im Produkt. 

Das Installieren von .NET-Framework 3.5 war unter Windows 7 noch relativ einfach – Online- oder Offline-Installer herunterladen und los! Unter Windows 10 kann das unter Umständen mehr Probleme machen. Die Fehlercodes 0x800F081F und 0x800F0906 können die Installation bzw. Aktivierung sehr umständlich machen. „Aktivierung“, da das .NET-Framework 3.5 bereits in der Feature-Liste von Windows 10 („Windows-Features aktivieren oder deaktivieren“ im Startmenü) gelistet wird und eigentlich nur per Häkchen aktiviert werden muss. Windows 10 lädt das dann über Windows Update nach. Im besten Fall. Oder beim Nachladen der Installationsdaten von Windows Update erscheinen die besagten Fehlermeldungen.

Die Installation erfolgt nun über ein Installationsmedium von Windows 10 – via USB oder ISO. Beides lässt sich binnen Sekunden über das Windows 10 Media Creation Tool herunterladen bzw. erstellen. Ich empfehle das ISO-Abbild, dieses lässt sich mit Rechtsklick -> Bereitstellen direkt in ein virtuelles Laufwerk verwandeln.

Nun braucht es für die Installation nur noch ein paar Befehle aus der administrativen CMD (als Admin starten!): 

del /q C:\Windows\SoftwareDistribution\Download
Dism /Online /Cleanup-Image /StartComponentCleanup
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs

Neustart, fertig!
via

Mit einem einfachen „Trick“ könnt ihr die wiederkehrende Tipparbeit in der Windows Kommandozeile vereinfachen: Aliase.
Gemeint sind selbst definierte (zumeist kurze oder einfache) Befehle, die andere (zumeist lange oder komplexe) Befehle ersetzen oder mehrere Befehle kombinieren.

Ein paar Beispiele, welche komplexeren Befehle durch einen einfachen Alias ersetzt werden könnten:

:ausführlichen IP-Config-Bericht in die Zwischenablage
ipconfig /all | clip
: Einfacher Netzwerkreset
ipconfig /flushdns && ipconfig /release && ipconfig /renew
: WLAN-Passwort von einem WLAN anzeigen
netsh wlan show profile [WLAN-Name] key=clear
: Git Branch aktualisieren, Pakete installieren, lokale Variable setzen und Node starten
git pull && npm i && set envtype=localtest && npm run debug

Aliase erstellen

windows-cmd-aliase-befehle-commands-path

Erstellt zuerst einen neuen Ordner, irgendwo auf eurem PC und kopiert euch den Pfad dorthin, z.B.: C:/aliase

Öffnet Erweiterten Systemeinstellungen (Start -> Erweiterte Systemeinstellungen oder Ausführen -> sysdm.cpl) -> Erweitert -> Umgebungsvariablen und fügt dort diesen Pfad im oberen und unteren Teil jeweils zu Path hinzu:

Dies bewirkt, dass alle Inhalte dieses Ordners jederzeit über die Kommandozeile aufgerufen werden können, also global aufrufbar sind.
Startet alle offenen CMD-Fenster danach neu, sonst kommt die Änderung nicht an.

Anschließend erstellt ihr euch in dem Ordner Dateien mit einem Dateinamen nach Format: [Befehl].bat – mit dem gewünschten Befehl/Alias. Beispielsweise: ipr.bat (Eselsbrücke „IP-Reset“)
Öffnet die Datei in einem Texteditor und fügt ein:

REM ipr.bat:
@echo off
echo Run: ipconfig /flushdns + /release + /renew
ipconfig /flushdns && ipconfig /release && ipconfig /renew

oder pir.bat („pull-install-restart“):

REM pir.bat:
@echo off
echo Run: git pull + npm i + npm run debug
git pull && npm i && npm run debug

REM und echo sind optional und dienen nur zur Info. Nachdem ihr die Datei gespeichert habt, lässt sie sich per Doppelklick starten und per CMD wie ein Befehl aufrufen:

Aliase mit Parametern

Ein weiterer Punkt kann noch wichtig sein: Wenn ihr dynamische Informationen (Parameter) an das Skript hinter dem Alias geben müsst. Beispielsweise braucht das Auslesen des WLAN-Schlüssels den WLAN-Namen (SSID) dafür oder der Ping brauch ein Pingziel.
Parameter lassen sich in Batch Skripte entweder per %1 … %9 (1. bis 9. Parameter) oder %* (alle angegebenen Parameter nacheinander) übergeben. Folgende Beispiele sind nicht besonders sinnvoll und sollen nur der Demonstration dienen:

REM rf.bat:
@echo off
echo unveil + delete %*
attrib -r -a -s -h %*&&del /f /q %*
REM p.bat:
@echo off
echo Usage: p [target] [count] [version]
echo ping %1 -n %2 -%3
ping %1 -n %2 -%3

Ein kleiner Aufwand für dich, aber eine große Erleichterung für deine Finger! 😉
Ich verwende Aliase, da ich als Programmierer im Alltag einige Befehle dutzende Male pro Tag ausführen muss.

Dieser Beitrag ist eine Fortsetzung der kleinen Artikelserie zur Optimierung der HTTP-Header für mehr Sicherheit auf der Webseite und für alle Webseitenbesucher. In Teil 1 ging es um die zwei noch recht einfachen Header HSTS und X-XSS-Protection. Teil 2 wird nun den recht komplexen aber mächtigen Header Content-Security-Policy behandeln.
Es benötigt vom Webmaster schon einiges an Vorbereitung und Testing, um mit diesem Header nicht auch Schaden anzurichten, aber der Zugewinn an Schutz gegenüber Angriffen oder Code Injection ist bemerkenswert.

CSP für umfangreiche Datenherkunftseinschränkung

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. So können beispielsweise bestimmte Datentypen wie Skripte oder Stylesheets, die von einer anderen URL als der gerade zu ladenden Webseite angefragt werden, geblockt werden. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen, welche über zahlreiche Tricks versuchen, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.
Damit das jedoch so funktioniert, muss der Webmaster für alle oder einzelne Inhaltstypen die jeweiligen vertrauenswürdigen Quellen definieren. Hier wird es knifflig. Vergisst der Admin eine vertrauenswürdige Quelle, werden Inhalte von dort nicht mehr geladen und fehlen auf der Webseite. Das kann dazu führen, dass Schriftarten oder Bilder fehlen, Skripte und somit ganze Funktionen nicht mehr laufen und die Webseite sich in andere Seiten nicht mehr einbetten lässt. 
Die vertrauenswürdigen Ursprünge sind entweder bekannt oder müssen erarbeitet werden.

1. Informieren

Eine zu restriktiv gesetzte CSP kann die Webseite wie gesagt teilweise beschädigen. Ich empfehle daher die mehrstufige Vorgehensweise: Informieren, testen, optimieren und schlussendlich aktivieren.

Ein erster Blick lohnt beispielsweise bei MDN. Hier sehen wir, welche Direktiven und welche Werte möglich sind. Ich gehe später nochmal genauer auf die einzelnen Werte ein. Erst einmal solltet ihr euch einen groben Überblick holen. Nutzt für weitere Informationen neben diesem Artikel auch die Intros von html5rocks.com, SelfHTML, den Mehrstufen-Ansatz von dareboost.com und die dort verlinkten weiteren Artikel zu CSP-Basics und auch die vielen kleineren Webseiten und Blogger mit deren CSP-Empfehlungen.

2. Testen

Wir beginnen mit Tests, die keine Schäden anrichten können. Dazu nutzen wir das Report-Only Feature der CSP. Hierfür wird eine valide CSP über Content-Security-Policy-Report-Only gesetzt, angewendet aber nicht ausgeführt. Es werden Warnungen und Fehler ausgegeben, aber keine Anfragen tatsächlich blockiert. Gesetzt wird es wie gehabt in der .htaccess der Webseite:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self'; child-src 'self'; report-uri https://report-uri.de/report.php;"
</IfModule>

Der Inhalt dieser CSP ist erst einmal nur kopiert von kittpress.com und angepasst an das Report-Only Feature via .htaccess. Von hier arbeite ich mich dann weiter.

Die CSP wird nun theoretisch angewendet, aber nicht endgültig ausgeführt. Nun könnt ihr anhand der Browser-eigenen Dev-Tools und der Reports die Problemstellen identifizieren.
Wie ihr eine Report-Schnittstelle einrichtet, die beispielsweise Reports in eine Logdatei schreibt, habe ich im ersten Teil dieser Artikelserie erklärt. Ihr könnt auch genau dieselbe Reportschnittstelle hierfür nutzen, das funktioniert einwandfrei. Alternativ könnt ihr auch externe Report Services wie diesen als Ziel für eure Reports wählen.
Gegenüber euren Browsertools haben die Reports den Vorteil, dass jede CSP-Verletzung jedes Website-Besuchers an euch gemeldet wird – ohne, dass ihr dafür dann noch etwas tun müsst. Außerdem habt ihr alle Meldungen dann in einer großen und zentralen Server-Log (ggf. auch per Mail) und müsst nicht selbst rumsurfen und die Devtools abkopieren. Es geht ansonsten aber auch ohne report-uri.

3.1 Optimieren

Bei meinem ersten Test landeten weit über 100 Reports innerhalb von 1 Minute in der Report-Log – das reicht für eine erste Optimierung. Also habe ich die CSP erst einmal wieder deaktiviert/auskommentiert und die ersten Ausnahmen erstellt. Dazu habe ich mir jeden Report einzeln angesehen, wenn nötig eine Ausnahme erstellt, alle Logeinträge dieses spezifischen Problems entfernt, nächten Report angesehen. So lange, bis die Report-Log wieder leer war.
Anschließend die neue CSP wieder einkommentieren und wieder dreistellige Reports sammeln.
Diesmal dauert es länger und es kommen kleinere oder speziellere Probleme zum Vorschein: Von externen Seiten eingebundene Bilder oder Medien, alte http:// embeds von z.B. alten Google Maps Projekten, extern genutzte Services, Einbindungen von Inhalten noch über meine alte Domain hannes-schurig.de, externe Inhalte in Kommentaren usw.
Ich habe hier durchaus 2-3 Stunden verbracht, alte Blogartikel zu bearbeiten, Links zu korrigieren, meine alte Domain überall zu ersetzen, Kommentare zu korrigieren und mehr.
Nach 4-5 Iterationen über 3 Tage ist meine CSP nun ganz gut und die letzten 24 Stunden ergaben nur noch Reports, die geblockt werden können. Es verbleiben Logs von geblockten Domains wie countmake.cool, loadsource.org und eluxer.net – fragt mich nicht, was das ist. Manche Blocks kommen durch data, blob oder chrome-extension, ich denke das ist auch okay zu ignorieren.

Mit dieser Endfassung bin ich nun also ganz zufrieden und werde diese nun endgültig aktivieren:

<IfModule mod_headers.c> 
  Header always set Content-Security-Policy-Report-Only: "default-src 'self'; \
script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com https://*.googleapis.com https://www.google.com https://www.gstatic.com https://*.vgwort.de https://*.it-stack.de; \
img-src 'self' https://*.gravatar.com https://*.w.org https://*.wordpress.org www.google-analytics.com https://*.vgwort.de https://www.gstatic.com https://*.it-stack.de data:; \
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com https://*.it-stack.de https:; \
font-src 'self' data: https:; object-src 'none'; \
child-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
frame-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https:; \
worker-src 'self' https://www.google.com https://*.youtube.com https://*.it-stack.de https; \
connect-src 'self' wss://it-stack.de www.google-analytics.com https://*.vgwort.de; \
report-uri https://report.tld/report.php"
</IfModule>

Die Backslashes am Ende der Zeilen ermöglichen Zeilenumbrüche in .htaccess Dateien zur besseren Lesbarkeit.

3.2 Verstehen

Ein paar kleinere Hinweise oder Ergänzungen dazu:

default-src ’self‘ wird angewendet, wenn eine andere Direktive, die für eine Anfrage gebraucht wird, gar nicht vergeben wurde. Ist eine Direktive gesetzt, wird default-src komplett überschrieben, dortige Werte werden nicht vererbt. Beispiel: img-src abc.com würde das ’self‘ von default-src nicht vererben, ’self‘ sollte daher fast immer mit angegeben sein.

Mir ist klar, dass unsafe-inline/-eval die größte Schwachstelle der CSP sind, allerdings auch das größte Problem bei WordPress Blogs mit etlichen Plugins, Google Analytics und mehr. Der Aufwand, diese zwei Attribute zu entfernen, kann sehr aufwändig und langwierig werden. Ich betrachte diese CSP jetzt vorerst als (wenn auch schon fortgeschrittenes) MVP – minimum viable product 😉

CSS-Stylesheets wirken eher harmlos, enthalten schließlich nur kosmetische Informationen, wieso einschränken? Es ist nicht zu unterschätzen, wieviel Spionage auch durch CSS-Angriffe wie z.B. „CSS Exfil“ möglich ist.

Ebenso Fonts, ist das nicht etwas too much? Nein, auch Fonts können zu Keyloggern umfunktioniert und müssen daher ebenso gut eingeschränkt werden.

child-src ist noch CSP Version 2 und wird angeblich (laut dieses Validators) in Version 3 durch frame-src und worker-src ersetzt. Ich habe also vorsichtshalber einfach mal alle drei Direktiven so gesetzt. Parallel am besten immer noch mit Google’s Validator testen.

4. Aktivieren

Nachdem die CSP nun definiert und einige Stunden ohne neue benötigte Regel im Testbetrieb lief, kann sie nun aktiviert werden. Dazu einfach nur Content-Security-Policy-Report-Only in Content-Security-Policy umschreiben und fertig. Beobachtet selber noch einmal die Webseite, auch das Admin Backend und wenn alles funktioniert, ist es geschafft!

Ich werde vorerst die Log noch im Blick behalten, bin aber erstmal froh, auch diesen Punkt soweit erledigt zu haben:

Es wird langsam… 3 Security Header gesetzt, CSP ist neu

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-banner

Zum Start dieser kleinen Serie, inspiriert durch einen Sicherheitsreport meines Blogs von enginsight.com (dazu mehr im November), erst einmal die Grundlagen der HTTP-Header:

Was sind HTTP-Header und wofür brauche ich sie?

HTTP-Header, oder in diesem Artikel vor allem die HTTP-Header-Respond-Felder, sind ein Teil der Antwort eines Webservers an den anfragenden Client (mehr dazu). Sie enthalten Anweisungen, Informationen und Einschränkungen der Verbindung zwischen Browser und Server, aufgebaut als eine Vielzahl an Schlüssel-Wert-Paaren.
Der Betreiber einer Webseite oder eines Webservers kann diese Antwortfelder teilweise konfigurieren und damit die Sicherheit der Webseite und des Verbindungsaufbaus erhöhen. Die Felder, die speziell für mehr Sicherheit entwickelt wurden, werden auch kurz HTTP-Security-Header genannt.

Die Anpassung der Header kann unterschiedlich erfolgen und ist vom Webserver oder der Webhosting Umgebung abhängig. Webserver bieten für HTTP gewöhnlich Konfigurationsdateien an, teilweise gibt es diesen Zugriff auch in root-Webhosting-Lösungen. Für „normales“ Webhosting geht das größtenteils auch über eine .htaccess in der obersten Ebene. Das könnte im Falle meines Webhosters All-Inklusive beispielsweise sein:
/www/htdocs/w00bxxxx/.htaccess

Mögliche Probleme mit .htaccess bei Shared Webhosting

Achtung: Eventuell werden Header Anpassungen von eurem Hoster geblockt/entfernt. Das liegt dann an der Art und Weise der Webserver-Konfiguration.
Sidestory: Bei meinem Hoster All-Inklusive, dessen Shared Hosting Server größtenteils PHP über FPM/FastCGI realisieren, ist das beispielsweise der Fall. Hier müssten die Einstellungen direkt im VHost gesetzt werden, das kann nur der Hoster selbst. Freundlicherweise hat mich All-Inkl nach einer Nachfrage auf eine moderne Serverfarm umgezogen, wo ich mittels .htaccess auch Header setzen kann.
Sollte das für euch nicht möglich sein, funktioniert für WordPress auch der Workaround über die functions.php, den ihr auf dieser Seite ganz unten im letzten Absatz findet. 
Teilweise kann es auch sein, dass die Einträge durch Einstellungen im Admin-Backend überschrieben werden. So kann es sein, dass HSTS, „Enforce SSL“ und ähnliche Domain-basierte Eigenschaften in der Domänenverwaltung angepasst werden und die .htaccess Angaben überschreiben.

Hier die Analyse meines Blogs von securityheaders.com vor der Optimierung der Security Header:

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-header-analyse-davor
Security Header Analyse vorher mit der Endwertung D, nicht so vorteilhaft…

Kein sehr gutes Bild. Wird Zeit, daran zu arbeiten! Wir beginnen mit zwei recht unkomplizierten Security Feldern, HSTS und XSS-Protection. Sie bieten einen guten Einstieg in das Themengebiet und benötigen jeweils nur 1 Zeile in der .htaccess. Aber nun in die Details:

HTTP Strict Transport Security – SSL & HTTPS, bis dass der Tod uns scheidet

HSTS (HTTP Strict Transport Security) sollte ausschließlich aber unbedingt dann konfiguriert werden, wenn die Webseite SSL verschlüsselt (über https) erreichbar ist und nicht mehr über unverschlüsseltes HTTP erreichbar sein soll. HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über SSL vom Client zum Server geschickt werden müssen.

<IfModule mod_headers.c>
  # Die einfache HSTS Variante, halbes Jahr Zeitfenster
  # Header always set Strict-Transport-Security "max-age=15778463"
  # oder noch sicherer mit Subdomains, preload und allen Subdomains
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Zwei Werte sind hier wichtig: max-age und der optionale Parameter includeSubDomains. max-age ist die Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. Ist die Webseite innerhalb dieser Zeit nicht über https erreichbar, weil beispielsweise das Zertifikat abgelaufen ist, kann sie nicht mehr geöffnet werden. Browser geben dann diese Art von Fehlermeldung und für den Nutzer ist hier Endstation. Das kann jetzt für den Nutzer doof sein, sorgt aber für ein hohes Sicherheitsminimum, das nicht unterschritten werden darf. Eigentlich ein Plus.

Ein Blick in die weiteren Eigenschaften von HSTS lohnt sich

Die zusätzliche Angabe includeSubDomains erweitert dieses Verfahren auf alle Subdomains, ein Wildcard-Zertifikat ist hier also von Nöten. 
Zu guter Letzt gibt es noch die preload-Eigenschaft, die noch nicht Teil des offiziellen Standards ist. Es ist die Crème de la Crème der HSTS-Absicherung und implementiert den HSTS-Schutz für eure Domain explizit und direkt in alle modernen Browser (akt: Chr, FF, Opr, Saf, IE11, Edg). Dafür muss die Seite jedoch HSTS ordentlich eingebunden haben und auf dieser Seite registriert werden. Dieser Artikel beschreibt sehr ausführlich und einfach dieses Attribut und all seine Details.
Prüft die HSTS-Eigenschaften eurer Seite beispielsweise hier. Mehr Informationen zu HSTS auch hier. Einen ausführlichen Check eurer SSL-Servereigenschaften könnt ihr hier initiieren – das dauert 2, 3 Minuten, ist aber sehr ausführlich und informativ.

X-XSS-Protection – steckt mehr drin als gedacht

Als nächste Eigenschaft schauen wir auf das Feld X-XSS-Protection. Dieses steuert Browser-Features, welche XSS-Attacken erkennen und verhindern. Diese Mechanismen sind normalerweise aktiviert, können aber von Servern oder vom Nutzer deaktiviert werden; X-XSS-Protection erzwingt die Nutzung dann entsprechend der Angabe. Oft lese ich, dass der Header nur von IE und Chrome, teilweise auch von Safari ausgewertet wird. Laut MDN wird der Header jedoch von allen Browsern bis auf Firefox unterstützt. Folgende Umsetzung via .htaccess:

<IfModule mod_headers.c> 
  # Schutz aktivieren und Rendern verhindern bei einem Angriff
  # Header always set X-XSS-Protection "1; mode=block" 
  # oder noch besser: Seite aufräumen, rendern und Angriff melden:
  Header always set X-XSS-Protection "1; report=http://reportingserver.com/reporting_URI.php
</IfModule>

Relativ einfach: Der erste Wert 1 erzwingt-aktiviert den Schutz, mode=block stoppt das Rendering der Seite und blockiert sie komplett. Ohne mode=block wird die Anfrage gereinigt und dann ausgeführt. Soweit so einfach.

XSS-Protection Reporting – Mitlesen der Angriffe

Nun kommt jedoch noch eine spannendere Anweisung, die leider auf kaum einer Infoseite beschrieben wird; vermutlich, weil es etwas mehr Text brauch. Denn die report-Anweisung ermöglicht die Angabe einer Reporting-URI, an die ein Bericht des Angriffs geschickt wird. Das dortige Skript kann nun beispielsweise loggen, benachrichtigen oder beliebig anders reagieren. Das finde ich besonders wert- und sinnvoll, daher hier noch der Aufbau:
Beginnen wir mit dem beispielhaften Aufbau eines XSS-Protection Report Requests, welcher mittels POST an die URI geschickt wird:

POST http://test.local/foo HTTP/1.1
Host: test.local
Connection: keep-alive
Content-Length: 116
Pragma: no-cache
Cache-Control: no-cache
Origin: http://test.local
X-FirePHP-Version: 0.0.6
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36
Content-Type: application/json
Accept: */*
DNT: 1
Referer: http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E
Accept-Encoding: gzip, deflate
Accept-Language: cs,en-US;q=0.8,en;q=0.6

{"xss-report":{"request-url":"http://test.local/test.php?foo=%3Cscript%3Ealert(1);%3C/script%3E","request-body":""}}

Nun wird der Request gegen ein PHP-Skript geschickt und dort empfangen, in eine Datei geloggt und per Mail an den Admin geschickt. Dazu habe ich diesen MDN-Code etwas erweitert: Es gibt jetzt mehr Mailing-Optionen und die Möglichkeit, eine E-Mail bei jedem Angriff zu senden, statt nur beim ersten:

<?php
// Start configure
$log_file = dirname(__FILE__) . '/xss-report.log';
$log_file_size_limit = 10000000; // in bytes = 10MB - once exceeded no further entries are added
$email_every_attack = true;
$email_sender = 'phpmailer@mysite.de';
$email_recipient = 'admin@mysite.de';
$email_subject = 'XSS Violation';
$email_charset = 'utf-8';
// End configuration

$current_domain = preg_replace('/www\./i', '', $_SERVER['SERVER_NAME']);
$email_subject = $email_subject . ' on ' . $current_domain;
http_response_code(204); // HTTP 204 No Content
$json_data = file_get_contents('php://input');

// We pretty print the JSON before adding it to the log file
if ($json_data = json_decode($json_data)) {
  $json_data = json_encode($json_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
  if ($email_every_attack) {
    // Send an email
    $message = "XSS violation on " . $current_domain . ":\n\n" .
      $json_data . "\n\n" .
      "Logfile:" . $log_file;
    $headers =  "From: ".$email_sender."\r\n".
                "Content-Type: text/plain;charset=".$email_charset;
    mail($email_recipient, $email_subject, $message, $headers);
  } else if (filesize($log_file) > $log_file_size_limit) {
    exit(0);
  }
  file_put_contents($log_file, $json_data."\n", FILE_APPEND | LOCK_EX);
}
?>

Am besten testet ihr die Reporting-Funktion vorher, beispielsweise über einen online API-Tester. Baut euch einfach den Request zusammen und schickt ihn an eure Report-URI. Das funktioniert gut und dient mir nun als Informationsquelle, welche XSS-Angriffsversuche mit exakt welchen Anfragen gegen meine Seite gefahren werden. Hier nochmal das Setup visuell:

mehr-website-sicherheit-mit-http-header-hsts-xss-protection-report-setup_thumb
XSS-Protection Reporting Setup mit Logging und Mailing

Es sei erwähnt, dass die X-XSS-Protection durch die neuere und komplexere Content Security Policy (CSP) ersetzt wird. Das schauen wir uns im nächsten Artikel genauer an. Solange dieses Feld aber noch nicht komplett von allen Browsern unterstützt wird, empfiehlt es sich weiterhin, XSS-Protection zu verbauen (zumal es so einfach ist).

Abschluss der ersten Optimierung

Die ersten zwei Security Header sind damit optimiert, ein erster Schritt:

Die Frage wurde mir kürzlich gestellt und ich möchte einen kurzen Einblick in mein kleines Setup werfen, wie ich mein Android Smartphone, ein Xiaomi Redmi Note 4, gegen typische Probleme absichere.

Anti-Virus

Die meisten Gedanken beim Thema „Handy absichern“ gehen vermutlich immernoch Richtung Antivirus-Bemühungen. Ich bin nach wie vor der Meinung, dass Android an sich ein sehr sicheres System ist, wenn es verantwortungsvoll genutzt wird. Grundlegende Sicherheitshinweise:
Apps nur aus dem Google Play Store installieren, Installation von Drittanbietern blocken, Geräteadministratoren regelmäßig prüfen, USB-Debugging deaktivieren, Gerätespeicher verschlüsseln, keine unsicheren Webseiten besuchen, vorsichtig bei Werbung sowie zu guten Werbeangeboten und jederzeit mit Sorgfalt, Achtsamkeit und etwas Skepsis handeln.
(Erfahrene Nutzer können nach eigenem Ermessen anders handeln.)

Nichtsdestotrotz kann eine zusätzliche Sicherheitsebene die potentiellen Gefahren noch weiter minimieren, dagegen ist nichts einzuwenden. Die Liste der möglichen Anbieter ist lang und wie schon seit jeher ist die Wahl des „richtigen“ Anbieters eine Art Glaubensfrage. Ich werde hier also nicht weiter „beraten“ sondern nur meine Wahl kurz zeigen: Sophos Mobile Security (Webseite, Play Store). Ich kenne Sophos aus meinem Arbeitskontext als guten Securityanbieter mit guten Content-Filtern und habe mir daher die kostenlose App installiert. Sie scannt meine installierten Apps, sowie neue App-Installationen und achtet beim Surfen auch auf gefährliche Inhalte. Weitere Features sind möglich, die ich jedoch nicht benutze, darunter App-Sperren, Anruf-Blocker, Anti-Diebstahl, Authenticator, Passwort-Safe und mehr.

Anti-Diebstahl

Ebenfalls wichtig und oftmals unterschätzt, denn diese Sicherheitsmaßnahme wird erst benötigt, wenn es schon zu spät ist: Das Handy irgendwo liegen lassen, gar gestohlen oder sonstiges unbefugter Zugriff hat stattgefunden.
Hier kommt Cerberus zum Zuge und verkörpert das Glück im Unglück. Tracking, Sperren, Löschen, Alarm, über 30 Funktionen stehen zur Verfügung und können es dem unerwünschten Nutzer echt schwer machen. Die Funktionen werden über ein Webinterface gesteuert und per Internet an die App auf dem Handy geschickt. Alternativ können auch SMS Befehle verschickt werden. Das Handy ist also unter Kontrolle, solange die SIM des Besitzers eingelegt oder irgendein Internetempfang aktiv ist. Nun kann ein Dieb natürlich die SIM wechseln – Cerberus sendet beim SIM Wechsel automatisch alle Informationen der neuen SIM an vorher definierte Kontakte, inklusive Standort.
Fehlerhafte Entsperrversuche werden ebenfalls inklusive Foto der Frontkamera an den Besitzer gemeldet, wenn aktiviert.

Hinweis: Für Cerberus auf Xiaomi Smartphones müssen 2, 3 Einstellungen angepasst werden, ich habe das in diesem Artikel zusammengefasst.

Anti-Datenverlust

Ich weiß, ein seltsames Synonym für „Backups„. Die Möglichkeiten sind hier recht abhängig vom Hersteller, den zu sichernden Daten, deinem Datenschutzempfinden und dem Root-Zustand des Geräts.

Meine generelle Vorgehensweise ist an eine „Taktik“ angelehnt: Ich lasse so viel es geht in die Cloud speichern. Android sichert automatisch viel in die Cloud – Kontakte, Notizen, Kalender, Systemeinstellungen, WLAN Passwörter und neuerdings auch App-Daten. Google Fotos schickt jedes neue Foto in die Wolke. In allen Apps aktiviere ich wenn möglich diese Art von Datensicherung.

Lokale Sicherungen mit Root Zugriff eröffnen eine breite Palette von Tools und Apps wie beispielsweise Titanium Backup. Ich habe bisher nur einmal gerootet und Android wenige Monate später neu installiert. Seitdem lasse ich die Finger davon. 

Das Sichern von App-Daten war bis vor einigen Monaten nur recht umständlich mit Helium möglich. Mittlerweile kann das Android aber auch selbst, in den „Sichern & Wiederherstellen“ Einstellungen werden neben 17 Systemeigenschaften jetzt auch App-Daten-Backups angeboten. Alle Apps oder bestimmte Apps lassen sich hier sichern.

Alle Handyhersteller (die ich bisher gesehen habe) haben auch ein eigenes Backup-Tool. Oftmals sind die Backups in einem eigenen Format, teilweise auch mit Backup in die Cloud. Schaut euch einfach mal um, es ist vermutlich eine solche App vorinstalliert. Die Backups können aber vermutlich nicht auf Geräten anderer Hersteller wiederhergestellt werden. Trotzdem ist ein Notfallbackup hier sinnvoll.

Solltet ihr noch weitere dateibasierte Daten haben, die nicht schon durch irgendwelche Apps gesichert werden, geht das natürlich recht einfach über USB und dann entweder direkt über den Explorer oder mit Tools wie MyPhoneExplorer oder ähnliche.

Anti-Werbung

Es ist zwar keine klassische Sicherheitsmaßnahme aber Werbung kann nervig sein, Webseiten verlangsamen, Datenvolumen verbrauchen und eben auch Schadsoftware verbreiten. Mit nur einer App können alle Probleme behoben werden: AdGuard für Android. Einfach installiert und eingerichtet, gefiltert werden Werbungen im Browser und In-App (teilweise) sowohl über HTTP und HTTPS, größere Datenmengen werden gespart und der Webseitenaufbau ist klar erkennbar schneller. Ich kann das nur empfehlen, die Kosten für eine lebenslange Lizenz (vor allem bei 2, 3 oder mehr Lizenzen) sind voll okay.

Bei Kinder- bzw. Jugendschutzprogrammen ist es eine sehr wichtige Funktion: Das Starten einzelner Programme verhindern oder nur bestimmte Programme zulassen und alle anderen blockieren. Das lässt sich händisch jedoch auch ohne eingekaufte Zusatzsoftware in wenigen Minuten einrichten:

Mit der Registry nur bestimmte Programme zulassen

Sucht in der Registry nach dem Schlüssel:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies

Ihr erstellt nun einen Schlüssel „Explorer“ unter „Policies“ und einen DWORD-Wert „RestrictRun“ mit Wert „1“. In „Explorer“ erstellt ihr dann noch einen neuen Schlüssel „RestrictRun“ und könnt hier nun beliebig viele Zeichenfolgen erstellen. Jede Zeichenfolge steht für ein erlaubtes Programm. Alle Programme, die hier jetzt nicht gelistet sind, dürfen auch nicht mehr gestartet werden*. 
Der Name der Zeichenfolge ist eine fortlaufende Nummerierung und als Wert wird der Dateiname des Programms gesetzt. Die Änderungen werden beim Ab- und wieder Anmelden bzw. Neustart für den Nutzer aktiv. 

Einstellungen unter HKEY_CURRENT_USER gelten nur für den gerade angemeldeten Nutzer. Daher muss der Vorgang für jeden Nutzer, der eingeschränkt werden soll, innerhalb dessen Anmeldung gemacht werden. Oder ein Admin setzt die Einstellungen via HKEY_USERS, mehr dazu im letzten Abschnitt. 

Zum Testen empfehle ich, regedit.exe mit einzutragen. Somit könnt ihr auch in dem eingeschränkten Benutzer die Einstellungen noch via regedit.exe anpassen. Für den finalen Einsatz sollte regedit.exe unbedingt nicht erlaubt sein (also nicht auf der Liste stehen), weil der Nutzer sonst die Einstellung aushebeln könnte.

*RestrictRun blockiert nur Programmstarts über den Nutzerkontext des eingeschränkten Nutzers. Heißt: Systemkomponenten, Dienste oder Programme, die über einen anderen Nutzerkontext geladen werden, wie die CMD oder der Taskmanager, werden nicht blockiert. Das ist ganz gut, damit Treiber, Sicherheitsprogramme und andere kritische Windows-Komponenten weiterhin funktionieren. Prüft vorher das eingeschränkte Konto auf die gewünschten Einschränkungen.

Woher bekomme ich die Dateinamen meiner Programme?

Das ist relativ einfach, zwei Wege kurz beschrieben:

  1. Rechtsklick auf jede Verknüpfung, beispielsweise auf dem Desktop oder im Startmenü -> Eigenschaften und dort steht am Ende von „Ziel“ die ausführende Datei.
  2. Während das Programm geöffnet ist im Tastkmanager Rechtsklick darauf -> Eigenschaften und dann steht der Dateiname neben dem Programmicon. Eventuell müsst ihr den Programmlistenpunkt aufklappen und die Dateinamen der Unterpunkte somit auslesen, sollten es mehrere sein.

Via Registry bestimmte Programme blockieren

Das Blockieren einzelner Programme funktioniert nun fast genauso. In „Explorer“ wird nun ein Schlüssel und ein DWORD-Wert namens „DisallowRun“ erstellt. Im Schlüssel dient wieder eine Liste von Zeichenfolgen für die Aufzählung von Programmen bzw. deren ausführbaren Dateien. Die in der Liste eingetragenen Programme dürfen nicht mehr gestartet werden, alle anderen sind noch erlaubt.

  1. regedit.exe, SystemSettings.exe, SystemPropertiesAdvanced.exe, mmc.exe und weitere Systemtools solltet ihr vielleicht sperren. Vor allem, wenn ihr dem eingeschränkten Nutzer zutraut, euren Schutz umgehen zu wollen.
  2. Die Einstellungen setzt ihr beim ersten Login noch über die regedit.exe, ab dem zweiten Login werden Änderungen dann aber via Adminkonto gesetzt, da ja regedit.exe nicht mehr zugelassen sein sollte. Siehe letztes Kapitel.

Administration der Einstellungen außerhalb des eingeschränkten Nutzers

Ist ein Nutzer erst einmal eingeschränkt, wird die Administration schwierig. Wenn nur bestimmte Programme zugelassen sind, regedit.exe jedoch nicht, lässt sich nicht so einfach etwas ändern.
Hier empfiehlt es sich, die Einstellungen vor dem Login dieses Nutzers durch einen anderen Nutzer (mit Administrationsrechten) anzupassen.

Die benutzerspezifischen Inhalte des HKEY_CURRENT_USER können auch über einen anderen Nutzer via HKEY_USERS/[SID] eingesehen und geändert werden. Die SID des gewünschten Nutzers kann über die CMD ausgelesen werden:

REM// aktuell angemeldeter Nutzer:
C:\Users\Hannes>wmic useraccount where name='%username%' get sid
REM// SID
REM// S-1-5-21-3483483838-1959189235-3432330904-1001

REM// beliebiger Nutzername
C:\Users\Hannes>wmic useraccount where name='Hannes' get sid
REM// SID
REM// S-1-5-21-3483483838-1959189235-3432330904-1001

Mit dieser SID könnt ihr dann aus jedem Adminaccount heraus die Registry und den RestrictRun / DisallowRun Eintrag des Nutzers anpassen. Einfach die gewünschten Programme eintragen, als Nutzer anmelden, diese nutzen. So lassen sich die Einstellungen übrigens auch in Masse aus einem Account heraus einstellen und der Prozess auch einfach per Skript automatisieren und auf beliebig viele Nutzer ausrollen.

windows-restrictrun-start-whitelist-einrichten-sid-hkey-users
Über die CMD die SID eines Nutzers auslesen und seine Registry anpassen