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>

Apache: OCSP Stapling aktivieren

prego 4 Kommentare

Ab Apache Version 2.4 (in Debian Jessie enthalten) wird OCSP Stapling unterstützt. OCSP steht für Online Certificate Status Protocol. Damit kann die Gültigkeit eines Zertifikates abgefragt werden. Das ganze sieht in der Praxis dann so aus, dass wenn ein Nutzer eine Webseite über HTTPS aufruft, der Webbrowser dann eine im Zertifikat enthaltene OCSP Responder Adresse abfragt um festzustellen, ob das Zertifikat noch gültig ist. Das ist natürlich für die Sicherheit gut, hat aber zwei Nachteile:

  • Die OCSP Responder Server werden beim Verbindungsaufbau zusätzlich abgefragt, das führt je nach Auslastung und Verfügbarkeit des Responders zu einer Verzögerung
  • Der OCSP Responder Server bekommt mit, welche Webseite von welcher IP-Adresse aufgerufen wird

Ob die OCSP Responder letzteres nun loggen oder nicht ist nicht immer eindeutig zu klären, deswegen gehe ich davon aus, dass das im Zweifel so ist.

Abhilfe bringt OCSP Stapling. Dabei fragt der Webserver selbst regelmäßig den OCSP Responder für seine Zertifikate ab und behält diese Information in einem Zwischenspeicher. Beim Verbindungsaufbau sendet er dann die OCSP Antwort gleich mit. Da es sich hierbei um eine komplett signierte Kommunikation handelt, vom OCSP Responder über den Webserver bis hin zum Browser und der Browser die Signatur überprüft ist die Antwort verifiziert und der Browser muss keine Verbindung mehr zum OCSP Responder aufnehmen.

In Apache ist das ganze recht einfach eingerichtet. Ich habe einfach unter /etc/apache2/conf.d/ eine Datei OCSP_Stapling.conf angelegt mit dem folgenden Inhalt:

SSLUseStapling on
SSLStaplingCache 'shmcb:/tmp/stapling-cache(102400)'
SSLStaplingReturnResponderErrors off

Dabei ist wichtig, dass der SSLStaplingCache außerhalb eines vhosts definiert wird. Prüfen kann man das ganze dann bei dem von mir gern genommenen SSL Server Test von Qualys. Da sieht das dann bei Erfolg so aus:

screenshot-www ssllabs com 2015-08-30 14-35-20

Weitere Informationen zu dem Thema:

KVM: convert raw disc images to qcow2

prego Schreib einen Kommentar

So langsam steht bei meinen Servern auch ein Update von Wheezy auf Jessie an und vorher möchte ich einen Snapshot der Festplatten machen um für einen hoffentlich nicht notwendigen revert gerüstet zu sein. Als ich die Maschinen eingerichtet habe, habe ich als Speicherformat für die images RAW gewählt. Damit sind keine Snapshots möglich. Eine Konvertierung zu qcow2 ist sehr einfach möglich:

qemu-img convert -p -f raw -O qcow2 -o preallocation=metadata disk.img disk.qcow2.img

via