htaccess - WebServer Konfiguration

Wer eine Webseite wie die MSXFAQ bei einem Shared Hoster betreibt, muss sich eigentlich um  nichts kümmen. Als dann aber Google wieder mal den Algorithmus für den Suchindex verändert hat, ist mir z.B. aufgefallen, dass meine Webseite etwas schneller sein könnte, wenn der Webserver "Caching" zu lassen würde. Zudem könnte ein komprimieren der Seite weitere Performancevorteile bringen. Bandbreite ist insbesondere auf Mobilgeräten nicht unbeschränkt vorhanden.

Auch andere Einstellungen lassen sich nur in der ".htaccess" vornehmen. Die ".htaccess" ist eine gesonders geschützte Systemdatei und wird vom Webserver nicht ausgeliefert. Sie können also nicht selbst direkt diese Datei anschauen. ich habe die wesentlichen Änderungen daher hier für mich und wen es sonst interessiert dokumentiert.

Defaults

Mein Hoster "1und1" hat natürlich schon eine ".htaccess" in dem Basisverzeichnis vorbereitet. Bei mir war dies:

# -FrontPage-
IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>

Ich habe aber natürlich die Pfade auf die AUTH-Dateien zur Sicherheit unkenntlich gemacht. Die hier noch sichtbaren "Frontpage-Extensions" sind aber nicht mehr aktiv und die Inhalte der AUTH-Dateien daher auch nicht mehr da. Insofern ist das nicht mehr relevant.

Security-Einstellungen

Diverse Parameter zur Steuerung ihres Browsers können per META-Tag in der HTML-Datei aber auch im HTTP-Header übertragen werden. Die Informationen in dem META-Tag können durch Skripte wohl sehr einfach überschrieben werden, während Header-Parameter besser geschützt sind. Folgende Werte sind gesetzt:

# Sicherheitseinstellungen
# https://siwecos.de/wiki/Content-Type-Nicht-Korrekt/DE
AddType 'text/html; charset=UTF-8' html

# Set content security
Header set Content-Security-Policy "default-src 'self' ; style-src 'self' 'unsafe-inline'; frame-src 'self' www.youtube.com; img-src 'self' www.netatwork.de https://www.google-analytics.com; script-src 'self' 'unsafe-inline' https://www.google-analytics.com https://ssl.google-analytics.com; connect-src https://www.google-analytics.com"

#https://siwecos.de/wiki/Referrer-Policy/DE
Header set Referrer-Policy "origin-when-cross-origin"

# https://siwecos.de/wiki/X-Frame-Options-Schwachstelle/DE
Header always append X-Frame-Options SAMEORIGIN

# https://siwecos.de/wiki/XSS-Schwachstelle/DE
Header set X-XSS-Protection "1; mode=block"

Header set X-Content-Type-Options nosniff

Es gibt durchaus noch Verbesserungspotential hinsichtlich Cookies, Content Security Policy (CSP) und natürlich HSTS.

Zu dem ein oder anderen Parameter habe ich eine eigene Seite geschrieben:

Es gibt diverse Seiten, die eine "sichere Webseite" prüfen.

Umleitung auf HTTPS

Es gehört heute schon zum guten Ton, dass die Webseite per HTTPS erreichbar ist. Die MSXFAQ ist dies schon seit vielen Jahren, auch wenn damals das SSL-Zertifikat bei 1&1 noch 5€/Monat extra gekostet hatte. Mittlerweile ist HTTPS schon erforderlich, weil Google und Co Seiten ohne HTTPS sogar abwerten. Und da auch auf der MSXFAQ z.B. Skripte liegen, die von Administratoren heruntergeladen und ggfls. mit privilegierten Rechten gestartet werden, ist SSL ein Baustein Veränderungen des Inhalts auf dem Transport weg zu verhindern. Ich habe am 8. Aug 2018 über folgende Einträge ein Redirect aktiviert:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Ich muss aber dazu sagen, dass die RewriteEngine schon vorher angeschaltet war und es sogar schon eine Umleitung von Zugriff auf die zusätzlichen Domains wie msxfaq.com, msxfaq.net u.a. auf die Haupt-URL www.msxfaq.de gegeben hat, Nun ist aber auch ein Zugriff auf http://www.msxfaq.de auf https://www.msxfaq.de aktiv.

Kein HSTS

Ich habe mich aktiv gegen HSTS entschieden und möchte auch beschreiben warum. HSTS ist eine Erweiterung, mit der eine Webseite den Clients mitteilen kann, dass sie z.B. nicht nur verschlüsselt zu erreichen ist sondern auch das Zertifikate passen muss. Damit können sensible Seiten, z.B. Homebanking, Firmen etc. es erschweren, dass ein Proxy dazwischen die Verbindung aufbricht. Ein 100% Schutz ist es aber nicht, denn hir Client muss dazu erst einmal die richtige Seite erreicht und die Information über das Zertifikat und die Cache-Dauer lokal gespeichert haben. Es funktioniert nicht, wenn Sie auf einem fremden PC mit bereits installierter "Abhörfunktion" die Seite das erste mal aufrufen. Der klassische Zugriff per Browser auf einem öffentlichen PC ist damit nicht abgesichert.

Für MSXFAQ halte ich daher erst einmal fest:

  • Ich erfasse keine Anmeldedaten
    Sie müssen und können an keiner Stelle der MSXFAQ eine Anmeldung vornehmen. Sie senden also nie Benutzernamen oder Kennworte an die MSXFAQ, die schützenswert sind
  • Alle Informationen sind öffentlich
    Die Inhalte sind durch keine Paywall o.ä. geschützt und sowieso lesbar. Egal, ob dies nun per HTTP oder HTTPS erfolgt
  • Keine "Darknet"-Themen
    Auf der MSXFAQ wird zumindest nach meinem Kenntnisstand nichts veröffentlicht, was "geheim" gehalten werden muss. Weder Zugangsdaten noch Hash-Listen, strafbare Bauanleitungen o.ä. Das Potential, dass Sie durch den Besuch der MSXFAQ in das Visier von Strafverfolgungsbehörden oder Geheimdienste kommen ist gering.
  • Offline-Risiko
    Das SSL-Zertifikat der MSXFAQ wird von meinem Hoster verwaltet und automatisch aktualisiert. Ich müsste also rechtzeitig die HSTS-Policy vor einem Zertifikatwechsel anpassen. Das Risiko, dass ihr Browser den Zugriff auf die MSXFAQ aufgrund eines nicht erkannten Zertifikatswechsel unterbindet, will ich nicht eingehen

Der Verzicht auf HSTS hat natürlich durchaus ein reales Risiko:

Ohne HSTS könnte eine Malware oder Proxy die von ihnen von der MSXFAQ geladenen Inhalte quasi "on the fly" verändern. Was wäre insbesondere für Code, z.B. PowerShell-Skripte" natürlich gefährlich. Sie sollten also immer alle Skripte auch in Augenschein nehmen. Mittelfristig werde ich die Skripte auf GitHub migrieren und hoffentlich einmal signieren.

Umleitung von "office365"

Ehe ich den Bereich "Cloud" angelegt hatte, lagen die meisten Seite unter dem Verzeichnis "Office 365". Damit alte Zugriffe auf diesen Bereich nicht ins Leere laufen, habe ich über die ".htaccess" hier eine Umleitung konfiguriert.

#redirect old directories and files to new files
RedirectMatch ^/office365/(.*)$ http://www.msxfaq.de/cloud/$1

Sie können es gerne ausprobieren. http://www.msxfaq.de/office365/index.htm wird direkt auf http://www.msxfaq.de/cloud/index.htm umgeleitet

Performance messen

Es gibt einige Seiten, die eine Performance Analyse von Webseiten erlauben. An erster Stelle natürlich auch die Google Tools

Die meisten Einstellungen gibt natürlich der WebHoster vor, aber dass per Default z.B. Kompression und Caching bei 1und1 wohl abgeschaltet ist. ist nicht verständlich. Kompression kostet vielleicht CPU-Leistung und kann beim Shared Hosting ein Problem werden. dem Client aber das Caching zu verhindern, weil per Default keine Policy angegeben wird, ist aber unsinnig. Seit April 2015 werden solche "Fehler" z.B. bei Google wohl negativ betrachtet.

Also ist es an der Zeit etwas zu ändern und der Hebel ist die ".htaccess"-Datei beim Webhoster.

Caching

Zuerst habe ich mich dem Caching angenommen und über folgende Einstellung dafür gesorgt, dass die verschiedenen Dateitypen im Cache gehalten werden.

# Browsercache 
<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType image/ico "access 1 week"
 ExpiresByType image/x-icon "access 1 week"
 ExpiresByType text/css "access 1 week"
 ExpiresByType image/bmp "access 1 week"
 ExpiresByType image/gif "access 1 week"
 ExpiresByType image/jpg "access 1 week"
 ExpiresByType image/jpeg "access 1 week"
 ExpiresByType image/png "access 1 week"
 ExpiresByType application/javascript "access 1 week"
 ExpiresByType application/x-javascript "access 1 week"
 ExpiresByType application/x-shockwave-flash "access 1 week"
 ExpiresDefault "access 1 day"
</IfModule>

# BEGIN Cache-Control Headers 
<ifModule mod_headers.c> 
 <filesMatch "\.(ico|jpe?g|png|gif|swf|css)$"> 
 Header set Cache-Control "public" 
 </filesMatch> 
 <filesMatch "\.(js)$"> 
 Header set Cache-Control "private" 
 </filesMatch> 
 <filesMatch "\.(x?html?)$"> 
 Header set Cache-Control "private, must-revalidate" 
 </filesMatch> 
</ifModule> 
# END Cache-Control Headers

Diese Änderungen sind relativ schnell erfolgt. Kürzere Werte als 1 Woche für statiche Inhalte werden von Google als Fehler bewertet.

Kompression

Eine weitere Option teilt dem Webserver mit, dass er die Inhalte komprimieren kann, d.h. gerade HTML-Seiten können per GZIP sehr stark verkleinert werden

# gzip aktivieren
<IfModule mod_gzip.c>
 mod_gzip_on       Yes
 mod_gzip_dechunk  Yes
 mod_gzip_item_include file      \.(html?|txt|css|js|php|pl)$
 mod_gzip_item_include mime      ^text/.*
 mod_gzip_item_include mime      ^application/x-javascript.*
 mod_gzip_item_exclude mime      ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.gzip.
</IfModule>

Die Option sollten den Apache dazu bringen, Inhalte on the fly zu komprimieren, wenn der Webhoster das zulässt

Zeichensatz

Bislang habe ich den Zeichensatz einer HTML-Seite immer im HTML-Header angegeben.

oder in Textform:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Genau genommen ist das aber schon "zu spät", denn der Client hat die Datei ja schon geladen und "Interpretiert "diese. Wenn er dabei den falschen Zeichensatz nimmt, dann kann er diese Info gar nicht mehr lesen.

Entsprechend schreiben die verschiedene "Optimierungstools", dass man das besser schon im HTTP-Header macht und das kann man auch über den Webserver einstellen.

AddCharset UTF-8 .html

Da bei mir alle Seiten als UTF-8 gespeichert sind, ist dies bei mir die richtig Einstellung.

Weitere Links