Header Optionen

Ergänzen Sie Ihre .htaccess Datei um folgende fettgedruckten Einträge, um diese über die Header-Optionen abzusichern.

Um sogenannte clickjacking-Attacken zu verhindern, die über <frame> und <iframe> eingebunden werden können, setzen Sie die X-Frame-Options auf DENY - Keine Seite kann dann Inhalte einbinden. Folgende Optionen stehen zur Auswahl:

• DENY - verbietet jeglichen Frame-Zugriff
• SAMEORIGIN - lässt nur Zugriffe von der eigenen Lokation zu
• ALLOW-FROM - (ALLOW-FORM uri wird nicht von allen Browsern unterstützt) dies lässt nur Zugriffe von einer bestimmten URI zu

Die X-Frame-Options kann man angeben, sind aber inzwischen durch die Content-Security-Policy und der Angabe von frame-ancestors veraltet. Wir führen diese hier trotzdem mit auf, da wir auch weiter unten nur eine rudimentäre CSP Anweisung ohne frame-ancestors abgebildet haben.

Header set X-Frame-Options DENY

X-XSS-Protektion - Dieser Header bezieht sich nur auf IE8 und IE9 und schaltet den cross-site-scripting Schutz ein.

Header set X-XSS-Protection "1; mode=block"

X-Content-Type-Options - Dieser Header verhindert beim Internet Explorer "mime" basierte Attacken. Wenn der Server text/html liefert wird mit der nosniff Option der Browser angewiesen auch nur text/html zu rendern.

Header set X-Content-Type-Options "nosniff"

X-Content-Security-Policy - Mit dieser CSP können Sie eine Reihe von Angriffen verhindern. Es unterbindet das Ausführen von Javascript auf Ihrer Seite, wenn es außerhalb Ihrer Domain liegt.
Beachten Sie, dass die hier abgebildete Einbindung nur eine sehr rudimentäre Form darstellt.

Header set Content-Security-Policy "default-src 'self'"

Alle Sicherheitsregel/-richtlinien der CSP finden Sie unter developer.mozilla.org. Achtung: die CSP sieht es nicht vor im Dokument enthaltene Scripte oder Styles auszuführen - nur als ausgelagerte Dateien. Sollte es unumgänglich sein, verwenden Sie nach Möglichkeit NICHT unsafe-eval, unsafe-inline, sondern benennen Sie Ihr Script oder/und Style mit nonce und binden Sie es mit nonce-IhrVergebenerName ein. Oder Sie verwenden den vom Script/Style zugewiesenen Hash. Diesen können Sie zum Beispiel mit der Chrome-Konsole sehen beginnend mit sha. Ein internes Script binden Sie dann Beispielsweise mit script-src 'sha256-xxxxxxxxxxxxxxx' ein oder einen internen Style mit
style-src 'sha256-xxxxxxxxxxxxxxx'

---

Strict-Transport-Security

Läuft Ihre Seite bereits verschlüsselt über https, sollten Sie auch den Header für HTTP Strict Transport Security (HSTS) angeben. Mit dieser Funktion teilt Ihre Website Ihren Besuchern mit, dass sie über eine verschlüsselte Verbindung (HTTPS) erreichbar ist und der Browser diese Einstellung für längere Zeit zwischenspeichern soll (max-age (entspricht dabei der Dauer in Sekunden)). Warum Sie ihre Seite überhaupt verschlüsseln sollten und welche weiteren Vorteile dies bringt, können Sie hier nachlesen.

Preload-List
Die Entwickler von Google Chrome führen eine Liste mit Domains, für die HSTS aktiviert ist. Die Liste wird auch von anderen Browsern wie Firefox, Safari oder Internet Explorer genutzt und hilft das sogenannte Trust-on-first-use-Problem zu lösen. Vergleichbar mit im Browser hinterlegten Zertifikaten ist so garantiert, dass bereits beim ersten Aufruf einer Domain die HSTS unterstützt, eine verschlüsselte Verbindung aufgebaut wird. Der Eintrag in diese Preload-Liste ist hier kostenlos möglich: hstspreload.appspot.com

Folgende Kriterien müssen dafür erfüllt sein:

• Die Website muss ein gültiges SSL-Zertifikat besitzen, dass nicht SHA–1-signiert sein darf.
• Sämtlicher HTTP-Verkehr muss auf HTTPS umgeleitet werden.
• Sämtliche Subdomains müssen über HTTPS ausgeliefert werden.
• Unter der Basis-Domain muss ein HSTS-Header mit folgenden Werten ausgeliefert werden:
  • Der max-age-Wert muss mindesten 18 Wochen (10886400 Sekunden) betragen.
  • Der includeSubdomain-Token muss gesetzt sein.
  • Der preload-Token muss gesetzt sein.
  • Falls für Ihre Website eine Weiterleitung besteht, muss die Quelladresse den HSTS-Header besitzen.

Die an den HSTS-Header gestellten Anforderungen werden mit folgendem Befehl in der .htaccess-Datei erfüllt (hier mit der Laufzeit von einem Jahr):

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

Anonymisierungsdienste

Anonymisierungsdienste wie beispielsweise TOR haben ihre Existenzberechtigung. Jedoch lockt dies selbstverständlich auch User an, die keine guten Absichten haben und so relativ einfach und sicher vor Verfolgung beispielsweise Hackversuche starten können. Das soll heißen, dass wenn so ein Dienst auffällt (wie in Logfiles etc.), dann im Regelfall nicht, weil etwas Positives dabei herausgekommen ist.

Hier haben wir bei awxcnx.de einen guten Text mit funktionierender Anleitung gefunden, den wir hier wieder geben möchten.
Quelle: https://www.awxcnx.de/handbuch_24i.htm

Für verschiedene Webangebote ist es in Einzelfällen gerechtfertigt, den anonymen Zugriff zu blockieren. Kommerzielle Anbieter müssen Nutzer idenfizieren, um eine gültigen Vertrag schließen zu können. Bei Wikipedia ist die Auswertung der IP-Adresse ein Teil der Qualitätskontrolle.

Im allgemeinen gilt jedoch nach §13 (6) TMG, das Anbieter von Diensten im Internet verpflichtet sind, eine anonyme Nutzung der Angebote zu ermöglichen, soweit dies technisch möglich und zumutbar ist.

JonDonym und Tor bieten Unterstützung für die Sonderfälle. Diese Techniken sind maßvoll einzusetzen und auf das Notwendige zu beschränken. Der einfache, lesende Zugriff auf Angebote sollte stets auch anonym möglich sein.

Die Dienste offerieren folgende Angebote:

• JonDonym: Es reicht eine E-Mail mit dem zu sperrenden DNS-Namen oder der IP-Adresse an "jap(-at-)inf.tu-dresden.de" zu senden. Die Domain wird von den Mix-Betreibern gesperrt. Die gesperrten Sites werden auf einer Webseite des Betreibers veröffentlicht, um eine missbräuliche Nutzung dieses Features zu vermeiden.
  
  Wer die Sperre gern selbst umsetzen möchte, kann eine ständig aktualisierte XML-Datei mit der Liste der IP-Adressen der Exit-Mixe verwenden.
• Torproject.org bieten zwei Möglichkeiten zur Prüfung, ob die IP-Adresse des Nutzers zu einem Rechner des Tor-Netzes gehört. Abhängig von dem Ergebnis der Prüfung kann der Zurgriff auf das eigene Webangebot gesperrt werden. Die Umsetzung dieser Sperrung liegt beim Anbieter des Webangebotes.
  
  TorDNSEL bietet eine DNSBL, die ähnlich der Spammerblacklisten für E-Mails. Für eine IP-Adresse kann mit einer Anfrage bei TorDNSEL geprüft werden, ob sie zu einem Exit-Server des TOR-Netzes gehört.
  
  check.torproject.org bietet eine Liste von Exit-Servern des Tor-Netzes, die auf das eigene Webangebot zugreifen können (xx.xx.xx.xx durch die eigene IP-Adresse ersetzen): http://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=xx.xx.xx.xxDiese Liste kann regelmäßig aktualisiert als Blockliste für Teile des Webangebotes genutzt werden, die nicht anonym genutzt werden sollen.
  
  Das folgende Shell-Script ist ein etwas grober Quick-Hack für Linux Server. Es kann als cron-Job regelmäßig die Liste der Tor-Exit-Relays abrufen und die iptable Firewall Regel aktualisieren. Damit wird der Zugriff auf den Server für Tor-Router komplett gesperrt, was den Forderungen des Datenschutzgesetzes und TKG nicht gerecht wird. (Aber nicht jeder Server hostet ein Angebot, das für die Öffentlichkeit frei zugänglich sein muss.)
  
  #!/bin/bash
  # Change to your IP address!
  IP='12.34.56.78'
  
  cd /tmp
  
  wget -q -O iplist "http://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=$IP"
  
  
  if [ $? != 0 ]; then
     echo "Couldn't get new list of router ips."
     echo "Keeping iptables rules as they are!"
     exit 1
  else
     if [ -f /var/spool/blocked_tor_router ]; then
        while read ROUTERIP; do
           iptables -D INPUT -j DROP -s $ROUTERIP
        done < /var/spool/blocked_tor_router
     fi
  fi
  
  sed '/^#.*/d' -i iplist
  while read ROUTERIP; do
     iptables -I INPUT -j DROP -s $ROUTERIP
  done < iplist
  
  mv iplist /var/spool/blocked_tor_router
  
  exit 0

Exploits

Wenn Sie über Ihre htaccess-Datei auch mod_rewrite nutzen können, können Sie die Bannliste auch mit folgender Liste gegen bekannte Exploits erweitern. Dies kann das Ausnutzen von Schwachstellen und einschleusen von Schadcode/Schaddateien verhindern. Sollten Sie ein CMS im Einsatz haben, müssen Sie ggf. die letzte Zeile etwas anpassen, damit Sie selbst Änderungen an Ihrer Seite über das CMS ausführen können.

RewriteEngine On
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\(|\)|<|>|'|"|\?|\*|%%|&%%|&"|").* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\b(globals|encode|localhost|loopback)\b.* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\b(execute|exec|sp_executesql|request|insert|union|declare)\b.* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\b(drop|alter|char|cast|convert|meta|script|truncate)\b.* [NC]
RewriteRule ^.* - [F,L]

Bad Bots

Wenn Sie über Ihre htaccess-Datei auch mod_rewrite nutzen können, können Sie die Bannliste auch um sogenannte Bad Bots, Schnüffler, Web Sauger, Grabber und Spider mit der folgenden Liste erweitern.
Dies unterbindet das Inspizieren und Kopieren Ihrer Inhalte.
Eingetragene Bots derzeit: 328. Zum einfacheren kopieren liegt die Liste als TXT-Datei vor und kann hier (nur manuell) abgerufen werden.