Härtung von Webservern (am Beispiel Apache)

Heutzutage werden nur mehr selten Betriebssysteme direkt angegriffen, da sind die gängigen Firewalls zu gut, aber über Applikationen werden dafür umso mehr (Web-)Server attackiert.
Häufige Einfallstore sind z. B. schlecht gewartete WordPress-Installationen (wenn man da nicht jemanden hat, der täglich überprüft, ob es sicherheitsrelevante Updates gibt und diese dann auch sofort installiert, …) oder nicht upgedatete PHP-Versionen - bitte beachten Sie, dass Sie nur (vom Hersteller und Ihnen) gewartete Systeme ans Netz der TU Graz anschließen dürfen und dass wir schlecht gewartete Systeme nach Vorwarnung und bereits gehackte Systeme sofort vom Netz nehmen.

Einfache Härtungsmaßnahmen

Zuallererst sollten Sie sich fragen, ob der Webserver (auch hinter einem Webinterface zur Konfiguration eines Druckers läuft ein Webserver!) überhaupt aus dem Internet oder anderen Institutsnetzen erreichbar sein soll - wenn nicht, dann sollte auch keine Freischaltung für den Server/die IP-Adresse beantragt werden, dann ist er zumindest aus dem Internet nicht erreich- und angreifbar.

Auch wenn es teilweise in Richtung „security through obscurity“ geht, wird noch immer empfohlen z. B. die Version des Webservers etc. nicht zu verraten, hier am Beispiel Apache veranschaulicht:

RequestHeader unset Proxy
RequestHeader unset Proxy_Host
RequestHeader unset Proxy_Port
RequestHeader unset Proxy_User
RequestHeader unset Proxy_Pass
RequestHeader unset Proxy_Password

ServerTokens ProductOnly
ServerSignature Off
TraceEnable Off

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

HTTPS

Zumindest wenn Sie auch Userdaten zum Server transportieren (Eingabeformulare), dann sollten Sie unbedingt Verschlüsselung (also HTTPS) verwenden, seit 2017 stufen die meisten Browser Webserver als unsicher ein, wenn diese bei Formulareingaben kein HTTPS oder nur mit SHA-1 ausgestellte Zertifikate verwenden, seit Anfang 2020 wird bei Server ohne HTTPS von vielen Browsern generell angezeigt, dass die Verbindung nicht sicher ist, weil auch die angezeigten Daten manipuliert sein könnten.

Verschlüsselung alleine ist aber nicht genug, es muss sich um vertrauenswürdige Verschlüsselung nach dem Stand der Technik handeln und dafür sind mehrere Dinge notwendig, u. a. ein offizielles Zertifikat und einige wichtige Einstellungen am Web-Server:

  1. Das Zertifikat darf nicht mit SHA-1 ausgestellt sein.
    Wenn Sie sich nicht sicher sind, dann rufen Sie www.ssllabs.com auf, geben dort Ihren Webserver ein und schauen dann, was in der Zeile „Signature algorithm“ steht - falls dort SHA1 steht, müssen Sie ein neues Zertifikat beantragen! Den entsprechenden notwendigen CSR erhalten Sie z. B. durch den Befehl openssl req -new -newkey rsa:2048 -nodes -out NAME.csr -keyout NAME.key -subj "/C=AT/O=Technische Universität Graz/CN=NAME.tugraz.at". Das Zertifikat, das Sie von Sectigo erhalten, speichern Sie unter NAME.crt.
    Insgesamt sollten Sie versuchen bei den o. g. SSL-Labs zumindest ein „A“ zu erreichen, ein „A+“ ist erstrebenswert.
  2. Für den Server NAME.tugraz.at sollten Sie nur bestimmte Methoden der Verschlüsselung erlauben, vor allem kein SSL sondern nur mehr TLS und auch davon nur mehr die neuesten Varianten 1.2 und 1.3 (dazu ist eventuelll auch ein Update der SSL-Library notwendig), weiters sollten Sie nur sichere „Cipher Suites“ (diese definieren, welche Algorithmen in welcher Priorität verwendet werden dürfen) zulassen:
    • Schlüsselaustausch
    • Authentifizierung
    • Verschlüsselung
    • Hashfunktion 
    SSLEngine on
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLCipherSuite 'EECDH+AESGCM:EDH+AESGCM'
SSLHonorCipherOrder on
    Weitere Einstellungen finden Sie z. B. auf cipherli.st, dabei sollten Sie aber überprüfen, ob Ihre Benutzer dadurch nicht ausgesperrt werden.
  3. HTTP sollte dauerhaft auf HTTPS umgeleitet sein, damit alte Bookmarks oder Links nicht auf unsichere Seiten führen können (HSTS):
    <VirtualHost *:80>
     ServerName NAME.tugraz.at
     Redirect permanent / https://NAME.tugraz.at/
    </VirtualHost>
    <VirtualHost NAME.tugraz.at:443>
     ServerName NAME.tugraz.at
     SSLCACertificateFile /pfad/zu/den/certs/geant.crt
     SSLCertificateFile /pfad/zu/den/certs/NAME.crt
     SSLCertificateKeyFile /pfad/zu/den/certs/NAME.key
     Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
     …
    </VirtualHost>

    geant.crt braucht man nur dann, wenn das in NAME.crt nicht enthalten ist.

  4. Für das (zumeist verwendete) „OpenSSL“ muss laufend überprüft werden, ob es gravierende Sicherheitslücken (POODLE, Heartbleed, Shellshock, FREAK, BEAST, Logjam, …) und Patches gibt.
    Zur Überprüfung gibt es hier einen Test.

CSP

Bei den folgenden Einstellungen müssen Sie überprüfen, ob dann noch alles funktioniert (z. B. Frames, SSI, externe Inhalte etc.) und sonst einzelne Zeilen auskommentieren:

Header always set X-Frame-Options "sameorigin"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options nosniff
Header always set Content-Security-Policy "default-src 'mailto' 'self'"
 Wenn Sie Ihre Webseite überarbeiten, dann sollte dabei gleich daran gedacht werden, dass CSP in Zukunft aktiviert werden soll!

Eine Alternative könnte z. B. auch so ausssehen:

Header always set Content-Security-Policy "default-src 'mailto' 'unsafe-inline' 'self' https://www.youtube.com;"

OCSP stapling

Außerhalb der <VirtualHost></VirtualHost>-Blöcke SSLStaplingCache shmcb:/tmp/stapling_cache(128000) und in jedem <VirtualHost></VirtualHost>-Block SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off (oder gleich in die tls.conf - s. u.).

HPKP

Man sollte sich sehr gut überlegen, für welche Server man das Pinning einsetzt, da es eigentlich nur hilft, wenn es jemand schafft für unsere Domain bei einer anderen CA (bei uns aktuell Sectigo) ein falsches Zertifikat zu bekommen, um eine Man-in-the-Middle-Attacke gegen die TU Graz zu fahren. Bei fehlerhaften Konfigurationen (oder wenn sich die CA ändert) kann das dazu führen, dass sich Clients, die das unterstützen, nicht mehr mit dem Server verbinden.

Das „Pinning“ selbst ist eigentlich recht einfach.

Refer(r)er-Policy

Man kann und sollte definieren, wann der „Referer-Header“ gesetzt wird - Beispiel: Header always set Referrer-Policy same-origin bewirkt, dass der Referer nur innerhalb derselben Umgebung gesetzt wird, was verhindert, dass man über mehrere Server hinweg einen User tracken kann.

Feature-Policy

Mit diesem neuen Header kann man viel mehr definieren, z. B. Header always set Feature-Policy "geolocation 'self'"

Weitere Informationen

BetterCrypto.org, Geek Flare, Mozilla, SSL-Config-Generator, Sysinfo.io, …

Unter Can I Use… (→ Show all) kann man überprüfen, welche Clients man aussperrt, wenn man bestimmte Versionen von SSL/TLS nicht mehr unterstützt.

Tipps

Man kann sich das - wenn man sehr viele virtuelle Server hat - vereinfachen, indem man sich z.B. 2 Dateien tls.conf und hardening.conf anlegt und diese dann einfach in jedem virtuellen Server einbindet:

<VirtualHost NAME.tugraz.at:443>
 ServerName NAME.tugraz.at
 Include conf/tls.conf
 SSLCACertificateFile /pfad/zu/den/certs/geant.crt
 SSLCertificateFile /pfad/zu/den/certs/NAME.crt
 SSLCertificateKeyFile /pfad/zu/den/certs/NAME.key
 Include hardening.conf
 …
</VirtualHost>

Durch einen Bug in OpenSSL ist es derzeit nicht möglich in name based virtuellen Servern unterschiedliche Cipher-Suites zu definieren, es wird immer die erste Cipher-Suite in der Konfig-Datei verwendet!

Weiterführende Informationen

STIGs (DISA / (DoD).
CIS Benchmarks.
Apache Security Hardening Guide.

Header-Checks Security Headers, SSL Labs (Qualys), ImmuniWeb.

Sichere Anwendungen

Neben der Voraussetzung, dass der Webserver möglichst sicher aufgesetzt sein sollte (eine Aufgabe, die laufend durchzuführen ist, es werden immer wieder Schwachstellen entdeckt, die dann geschlossen werden müssen), ist natürlich auch bei den Anwendungen darauf zu achten, dass sie sicher umgesetzt werden.
Das OWASP führt 2 Listen für die am meisten ausgenutzten Schwachstellen:

Jede neue Anwendung sollte in Richtung dieser Schwachstellen überprüft werden.