Schlagwort: webserver

Wartungsseite für alle Apache vhosts eines Webservers realisieren

prego Schreib einen Kommentar

Über eine Lösung um einen einzelnen Apache Vhost mit einer Wartungsseite auszustatten habe ich bereits vor einigen Jahren hier geschrieben.

Jetzt stand ich vor der Aufgabe wegen Wartungsarbeiten auf meinem Webserver eine Wartungsseite für alle dort gehosteten Apache Vhosts zu schalten. Davor sitzt ein Gate-Server mit Apache und mod_proxy. Eine Lösung das zu realisieren wäre auf dem Gate-Server mit mod_rewrite nach dem Vorhandensein einer Maintenance-Datei zu schauen und wenn die Bedingung zutrifft alle Anfragen auf die Wartungsseite weiterzuleiten. Eine solche Lösung ist in Ansätzen unter anderem hier skizziert. Unschön finde ich dabei die unnötig vielen Prüfungen nach der Maintenance-Datei.

Ich habe nun eine andere Lösung realisiert, die in meinen Augen deutlich einfacher und eleganter ist. Auf dem Gate-Server lasse ich einen Apache-Vhost auf einem gesonderten Port laufen auf dem die Wartungsseite angezeigt wird. Für den Fall, dass ich die Wartungsseite vorschalten möchte, leite ich einfach allen HTTP und HTTPS Traffic auf die IP des Gate-Servers und den gesonderten Port um. Mit nur einer iptables Regel ist somit für alle vhosts auf dem Webserver eine Wartungsseite vorgeschaltet:

iptables -t nat -A OUTPUT -p tcp -d INTERNALWEBSERVERIP --match multiport --dports 80,443 -j DNAT --to-destination EXTERNALGATESERVERIP:PORT

Bei dem Apache Vhost auf dem Gateserver ist noch zu beachten, dass man nach Möglichkeit den aufrufenden Browsern / Bots etc. mitteilt, dass es sich um etwas temporäres handelt. Aus diesem Grund habe ich in dem Vhost zwei Dinge beachtet:

  1. Es wird ein HTTP Status Code 503 (Temporarily Unavailable) gesendet
  2. Es wird der HTTP Header Retry-After gesetzt

Im vhost sieht das wie folgt aus. Spannend sind die letzten 3 Zeilen. Meine Wartungsseite heißt übrigens auch 503.html

<VirtualHost *:PORT>
  ServerName maintenance.example.net
  ServerAdmin webmaster@example.net
 
  DocumentRoot "/var/www/maintenance"
 
  <Directory "/var/www/maintenance">
    Options -Indexes
    AllowOverride None
    Require all granted
  </Directory>
 
 
  ErrorLog "/var/log/apache2/maintenance.example.net_error.log"
  CustomLog "/var/log/apache2/maintenance.example.net_access.log" combined 
 
  RedirectMatch 503  ^/(?!503.html)  
  ErrorDocument 503 /503.html
  Header always set Retry-After "18000"
</VirtualHost>

HSTS – Was es ist, wie es funktioniert und wie man es in Apache einrichtet

prego 3 Kommentare

HSTS steht für HTTP Strict Transport Security und ist ein HTTP-Header bei dem der Webserver dem anfragenden Browser mitteilt, das alle Verbindungen nur ueber SSL/TLS aufgebaut werden sollen.
HSTS soll „Man-in-the-middle“ Attacken abwehren oder erschweren. Das Angriffsszenario besteht darin, dass Nutzer in der Regel nie

https

in den Webbrowser eingeben, sondern immer nur

example.net

Die Weiterleitung von http:// zu https:// macht der Webserver. Das sieht dann zum Beispiel so aus:
ohne_hsts

Man kann sehen, dass die erste GET Anfrage mit einem HTTP 302 Weitergeleitet wird und die zweite dann ein 200 OK zurueck liefert. Der Webserver ist in diesem Fall so konfiguriert, das alles was per HTTP reinkommt, automatisch auf HTTPS umgeleitet wird:

<VirtualHost *:80>
        ServerAdmin webmaster@jan-von.de
        ServerName mail.jan-von.de
        DocumentRoot /var/www/empty
 
        RewriteEngine on
        RewriteCond %{HTTP:X-Forwarded-Proto} !https
        RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
 
        CustomLog /var/log/apache2/mail.jan-von.de-access.log combined
</VirtualHost>

Genau hier liegt auch das Problem. Man kann sich in einem fremden Netz befinden, zum Beispiel einem unbekannten oeffentichen WLAN, dort kann die HTTP Anfrage abgefangen und der HTTPS Aufruf auf einen alternativen Server weitergeleitet werden.

Hier kommt HSTS ins Spiel. Der Server teilt dem Webbrowser mit, dass er sich bitte fuer eine bestimmte Zeit (zum Beispiel ein Jahr) daran erinnern soll, das diese Webseite nur noch ueber HTTPS aufgerufen werden soll.

In Apache muss dafuer das Headers-Modul aktiviert sein:

a2enmod headers

und anschliessend fuegt man in den HTTPS vhost die folgende Zeile ein:

Header always set Strict-Transport-Security "max-age=31556926"

Der Parameter max-age wird in Sekunden gesetzt. 31556926 Sekunden sind 365 Tage. Ein weiterer Parameter den man optional noch mit Komma Semikolon separiert dahinter haengen kann ist includeSubDomains. Dafuer muss aber sichergestellt sein, dass auch alle Subdomains per HTTPS erreichbar sind.
Weiter muss man aufpassen, dass die entsprechenden vhosts auch die angegebene Zeit, also zum Beispiel ein Jahr lang per HTTPS erreichbar sind, ansonsten kann es zu Fehlermeldungen kommen.

Wenn man dann HSTS aktiviert hat und eine Webseite aufruft die es unterstuetzt, dann kann man schoen sehen, wie der Browser gleich HTTPS nimmt und gar nicht erst HTTP probiert.

mit_hsts

Weiteres zu dem Thema z.B. unter:

HowTo: Apache SSL and perfect forward secrecy

prego 3 Kommentare

Man liesst die Tage ueberall von perfect forward secrecy. Das bedeutet, dass man bei verschluesselten Verbindungen erst sichere Protokolle anbietet und gleichzeitig unsichere verbietet. Mit den folgenden Einstellungen kann man in Apache einen SSL vHost selber PFS like absichern und auch BEAST (Browser Exploit Against SSL/TLS) Attacken abschwaechen:

SSLProtocol all -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5

Um die SSL Konfiguration des vHosts zu testen ist noch der SSL Server Test von Qualys SSL Labs zu empfehlen.

(via)