Seite wählen

NETWAYS Blog

kostenfreie TLS-Zertifikate mit Let's Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase „nur“ wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.
Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als „nicht sicher“.
Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.
Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.
Aber wie kommt man nun zu den Zertifikaten?
Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.
Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.
Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.
Zertifikat nur 90 Tage gültig – was tun?
Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.
Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.
Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

Load Balancing mit dem Raspberry Pi – ein kleines Praxisbeispiel mit ldirectord

Was im großen geht, das geht natürlich auch im Kleinen.
Da sich meine Bastelaktivitäten mit dem Raspberry Pi mit der Zeit immer mehr eingestellt haben, da einige Projekte umgesetzt und andere wiederum im Sande verlaufen sind, stellte sich die Frage, was man denn nun mit den kleinen Rechenzwergen anfangen könnte. Zum brach rumliegen sind sie ja definitiv zu schade 😉
Da ich es immer schon ein wenig n3rd1g fand ein Webprojekt direkt von daheim zu hosten und das ganze möglichst ausfallsicher zu gestalten, entschied ich mich dazu einen kleinen Blog auf meinen RPi’s zu betreiben.
Damit alle meine Pi’s eine sinnvolle Tätigkeit bekommen, entschied ich mich einen Loadbalancer auf dem einen zu installieren und die restlichen zwei als „App-Server“ laufen zu lassen.
Hierbei ist die Software IPVS in Verbindung mit dem Ldirectord auf jeden Fall eine gute Wahl. Ldirectord ist ein Daemon, welcher mit IPVS spricht und noch viele Funktionen mitbringt, die IPVS von Hause aus nicht abdecken kann, wie zum Beispiel das automatische Herausnehmen eines Servers aus einem Load Balancing Pool, wenn dieser nicht den gewünschten Content ausliefert.
Es stehen mehrere Möglichkeiten zur Auswahl, wie der Load Balancer mit den Real-Servern (also unsere App-Server) die Daten austauschen kann. Die wichtigsten stellen wohl das Direct-Routing und das Masquerading dar.
In diesem Beispiel habe ich mich für Direct-Routing entschieden, da Masquerading doch zu einem Teil auf die Rechenleistung des Raspberry’s niederschlägt.
Auf dem Loadbalancer reicht es aus, wenn das Paket ldirectord installiert wird. Alle benötigten Abhängigkeiten wie IPVS werden automatisch mit installiert.

Konfiguration ldirectord

Nach abgeschlossener Installation muss zunächst die Datei /etc/default/ldirectord angepasst werden. Hier wird über die Variable „CONFIG_FILE“ der Ort der Config definiert:

# Set the following variable to define a default configuration
# file for ldirectord.
CONFIG_FILE=/etc/ldirectord.cf

Im Anschluss muss jene Datei natürlich noch angelegt und mit dem richtigen Inhalt befüllt werden, wie in folgendem Beispiel:

# Global Directives
checktimeout=10
checkinterval=10
fallback=127.0.0.1:80
autoreload=yes
logfile="/var/log/ldirectord.log"
quiescent=no
#callback="/usr/local/bin/sync_ldirectord"
# Virtual Server for HTTP
virtual=192.168.0.40:80
real=192.168.0.41:80 gate
real=192.168.0.42:80 gate
service=http
request="alive.html"
receive="foobar3000"
scheduler=rr
# persistent=600
protocol=tcp
checktype=negotiate

Die Config ist an und für sich recht einfach zu verstehen. Ein paar Einträge möchte ich jedoch erklären:
callback: Hier kann ein Script angegeben werden, welches nach einem Autoreload ausgeführt wird. Üblicherweise sollte hier eine Synchronisation zu einem zweiten Load Balancer statt finden.
virtual: Die IP samt Port für den Service, der balanced werden soll. Diese IP ist von außen direkt ansprechbar (einfach gesagt: Die IP kommt in den A-Record 😉 ) und muss auf dem Load Balancer als zusätzliche IP konfiguriert werden. Dahinter stehen die Realserver, auf die Anfragen verteilt werden.
checktype: Art der Überprüfung, ob ein Realserver ordnungsgemäß funktioniert. Bei einem Webdienst ist negotiate anzuraten, da hierbei ein Ergebnis (receive) angegeben werden kann, welches bei der Anforderung (request) zurückgegeben werden muss.
scheduler: Die Art, wie verteilt wird. Hier wird nur die Abkürzung eingetragen. Welche Arten es gibt, kann in der Man-Page von ipvsadm nachgelesen werden (Schalter -s, –scheduler)
fallback: Der Name ist selbsterklärend 😉 Sollten Alle Realserver aus dem Pool rausspringen, so wird ein Fallback Server (in unserem Beispiel localhost) eingesetzt. Hier kann beispielsweise eine Wartungsseite ausgeliefert werden.
Nachdem nun auch die Service-IP auf dem Load Balancer-Pi eingerichtet wurde (ifconfig eth0:1 192.168.0.40/32 – in unserem Beispiel), kann der Ldirectord gestartet werden. Im definierten Logfile werden wir jedoch feststellen, dass der Ldirector seine Realserver noch nicht erreichen kann und somit auf den Fallback Server geschaltet hat.

Konfiguration App-Server

Unsere Realserver können leider nicht ohne Weiteres die Anfragen, die vom Load Balancer kommen verarbeiten. Immerhin wird ja die Anfrage direkt an die IP 192.168.0.40 gestellt, welche ja auf den Systemen nicht bekannt ist. Damit das funktioniert, muss die Service-IP auf den Real-Servern noch als Loopbackdevice gebunden werden, damit sich der Realserver auch angesprochen fühlt. Jedoch Vorsicht: Nicht einfach so die Service IP als Loopback einbinden! Das würde dazu führen, dass der Realserver ARP-Anfragen mit seiner MAC-Adresse beantwortet, was wir ja nicht wollen. Das könnte den gesamten Dienst still legen. Hier muss im Vorfeld noch folgendes in die /etc/sysctl.conf eingetragen und mit sysctl -p übernommen werden, was das Verhalten unterbindet:

net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 0

Nun kann das Loopbackdevice hochgefahren werden:

root@rpi1:~# ifconfig lo:1 192.168.0.40/32

Sobald nun der Realserver die Datei „alive.html“ mit dem Inhalt „foobar3000“ ausliefern kann, wird er auch im Load Balancer als aktiv markiert und die Anfragen werden entsprechend weitergeleitet. Das der Webdienst richtig dafür eingerichtet wurde, setze ich an der Stelle einfach mal voraus 😉
Das Schöne am Ldirectord ist, dass er sich nicht nur auf Webdienste beschränkt. Es kann jeder TCP/UDP Dienst über den Load Balancer verteilt werden. Durch die optional einstellbare Persistenz kann auch sichergestellt werden, dass eine Verbindung immer wieder bei dem gleichen Realserver ankommen wird (für den konfigurierten Zeitraum).

Loadbalancing bei Geobasisinformation Brandenburg

Hochverfügbarkeit und Lastverteilung spielen bei Internet-basierenden Diensten eine immer größere Rolle. Der Einsatz von Open-Source Software schafft hierbei eine kostenkünstige Möglichkeit sowohl die Verfügbarkeit zu steigern, aber auch die Last eines einzelnen Systemes durch Clustering zu senken.

Bei Geobasisinformation Brandenburg werden verschiedene, auf Karten basierende, Dienste dem Kunden online zur Verfügung gestellt. Im Zuge des Projektes sollte die vorhandene Anwendung auf einen Loadbalancer migriert werden, welche bisher von einem einzelnen Server ausgeliefert wurden.

Die Basis hierfür war eine Kombination aus einem realen Server und einem virtualisierten Server, der im Fehlerfalle die Dienste übernehmen soll. Für die Ausfallsicherheit wurde Heartbeat auf beiden Servern installiert, und auf Basis von Version 2 für die grafische Administration konfiguriert.

Die Lastverteilung der eingehenden Anfragen wurde über das Linux Virtual Server Projekt gelöst. Hierbei werden alle Anfragen vom aktiven Director auf die dahinterliegenden Server www-1, www-2 … www-n verteilt. Die Synchronisation der Verbindungs-Tabellen zwischen den beiden Director-Knoten geschieht über eine dedizierte Netzwerkverbindung, so dass bei einem Ausfall keine Verbindungen verloren gehen.

Durch dieses Setup konnte nun sowohl die Ausfallsicherheit gesteigert, als auch eine Lastverteilung auf aktuell 2 Webserver geschaffen werden. Die Lastverteilung kann bei Bedarf ohne große Änderungen und Ausfallzeiten auf weitere Server ausgedehnt werden.