Schwerpunkt 2: Reverse-Proxy Traefik

Reverse-Proxys sind wesentliche Komponenten von Netzwerkstrukturen, die als Vermittler zwischen Serveranwendungen und dem Client fungieren. Sie bieten eine Lösung für viele Herausforderungen in der modernen Webarchitektur, auf welche näher in diesem Post eingegangen wird.

1. Grundlegende Funktionen eines Reverse-Proxys

1.1 Forward-Proxy

Um die Funktionsweise eines Reverse-Proxys besser zu verstehen, ist es hilfreich, den Unterschied zwischen einem Forward-Proxy und einem Reverse-Proxy zu kennen. Ein Forward-Proxy agiert als Vermittler zwischen einem Client und einem Server und maskiert die Identität des Clients, indem er die Anfragen des Clients im Namen des Servers weiterleitet. Ein Beispiel für den Use Case eines Forward-Proxys ist die Umgehung von Netzwerkbeschränkungen, zum Beispiel in Unternehmen, um den Zugriff auf bestimmte Websites oder Inhalte zu überwachen.

1.2 Reverse-Proxy

Der Reverse-Proxy nimmt die Anfragen im Namen des Servers entgegen und verarbeitet sie, im Gegensatz zu einem Forward-Proxy, der die Anfragen des Clients weiterleitet. Ein Reverse-Proxy fungiert somit als Mittelweg zwischen dem Client und dem Webserver.

Anhand einer herkömmlichen Web-Anfrage möchte ich die Funktion eines Reverse-Proxys näher darstellen. Bei dem Aufruf auf https://fabio.sauna.re wandelt zuerst der Browser mithilfe des Domain Name Systems (DNS) den vollqualifizierten Domänennamen (FQDN) in eine IP-Adresse um, an die die Anfrage dann an die IP-Adresse mit dem Port 443 gesendet wird.

Allerdings, wenn ein zusätzlicher Webdienst auf demselben HTTPS-Standardport 443 bereitgestellt werden soll, wird es zu einem Fehler kommen, der unter Ubuntu Server bind: Address already in use lauten würde. Dies liegt daran, dass zwei Anwendungen nicht gleichzeitig auf demselben Port ausgeführt werden können. Hier kommt der Reverse-Proxy ins Spiel. Anstatt die Anfrage direkt an den Webserver weiterzuleiten, werden die Web-Ports (80/443) ausschließlich dem Reverse-Proxy zugewiesen. Der Reverse-Proxy leitet dann die Anfrage basierend auf der URL an die zugewiesene Zielanwendung weiter. Diese Zielanwendung kann dann auf einem anderen freien Port positioniert werden, was schlussendlich die parallele Ausführung zweier Web-Anwendungen ermöglicht.

Eine weitere wichtige Funktion von Reverse-Proxys besteht im Load Balancing. Durch Load Balancing können mehrere Instanzen einer Anwendung zu einem Cluster zusammengefasst werden, um über eine einzige URL angesprochen zu werden und durch das Zusammenschließen von Computerleistung die Effizienz und Verfügbarkeit zu erhöhen. Bei Load Balancing wird die Last zwischen den einzelnen Anwendungen (Nodes), die sich im Cluster befinden, nach einem definierten Schema verteilt.
Außerdem können Reverse-Proxys die Leistung von Webseiten verbessern, indem sie statische Inhalte zwischenspeichern und so die Ladezeiten reduzieren (Caching). Sie können auch die Datenmenge verringern, die zwischen dem Server und dem Client übertragen werden muss, indem Komprimierungstechniken implementiert werden.

Beispiele für beliebte Anwendungen, die Reverse-Proxys beinhalten, sind Apache, Nginx, Microsoft IIS und Caddy. Sie ermöglichen nicht nur das Routing von Anfragen an Port 80, sondern können mit jedem Port und jedem Transportprotokoll umgehen, einschließlich TCP, UDP, ICMP, QUIC und anderen.
Im unten stehenden Konfigurations-Beispiel wird die grundlegende Funktion von Reverse-Proxys dargestellt. Mit dieser Nginx Konfiguration könnten die URLs fabio.sauna.re (dieser Blog) und searx.sauna.re (Meta-Suchmaschine), die beide standardmäßig auf Port 80 hören und auf demselben Host (IP: 172.187.202.93) betrieben werden:

# Auf Anfragen an den Port 80 mit URL "fabio.sauna.re" reagieren
server {
   listen 80;
   server_name fabio.sauna.re;
   location / {
       # Blog wurde auf Port 8081 umgestellt [in Ghost Einstellungen]
       # bei URL Match leitet Nginx hier weiter
       proxy_pass http://localhost:8081;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
   }
}
# Auf Anfragen an den Port 80 mit URL "searx.sauna.re" reagieren
server {
   listen 80;
   server_name searx.sauna.re;
   location / {
       # Blog wurde auf Port 8081 umgestellt [in Searx-NG Einstellungen]
       # bei URL Match leitet Nginx hier weiter
       proxy_pass http://localhost:8082;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
   }
}

2. Vorstellung von Traefik

Traefik ist ein vielseitiger, moderner HTTP-Reverse-Proxy und Load-Balancer, besonders geeignet für Microservice-Architekturen und Cloud-Native Umgebungen. Es kann dynamisch auf Konfigurationsänderungen reagieren und sich flexibel anpassen, was einen Vorteil gegenüber traditionellen Proxy-Lösungen wie Nginx oder Apache bietet.
Traefik dient als Router, der mittels definierten URL-Matching-Regeln bestimmt, wie Anfragen an entsprechende Dienste weitergeleitet werden. Diese Regeln, auch als Routing bekannt, setzen das Erfüllen spezifischer Kriterien voraus, um angewendet zu werden. Im Schaubild und in der docker-compose.yml wird diese Funktionsweise dargestellt.

ghost:
	image: ghost:latest
	container_name: ghost
	hostname: ghost
	restart: unless-stopped
	depends_on:
		- ghost-db
	env_file:
		- ./common.env
		- ./ghost.env
	volumes:
		- ./ghost/data:/var/lib/ghost/content
	networks:
		- blog
	labels:
    	# Traefik Konfiguration
		- traefik.enable=true
		- traefik.http.routers.ghost.entrypoints=https
		- traefik.http.routers.ghost.rule=Host(`fabio.sauna.re`) # URL Matching
		- traefik.http.routers.ghost.tls.certresolver=sauna
		- traefik.http.routers.ghost.middlewares=ratesec-chain@file # Middleware Chain Ratesec (Ratelimiting, Secure-Headers)
		- traefik.http.routers.ghost.service=ghost
		- traefik.http.services.ghost.loadbalancer.server.port=2368
        # Einstellungen für das Admin-Interface
		- traefik.http.routers.ghost-admin.entrypoints=https
		- traefik.http.routers.ghost-admin.rule=Host(`fabio.sauna.re`) && Path(`/ghost/`) # URL Matching mit Pfad
		- traefik.http.routers.ghost-admin.tls.certresolver=sauna
		- traefik.http.routers.ghost-admin.middlewares=secure-chain@file # Middleware Secure Chain (zusätzlich SSO und IP-Whitelisting)
		- traefik.http.routers.ghost-admin.service=ghost-admin
		- traefik.http.services.ghost-admin.loadbalancer.server.port=2368
		- com.centurylinklabs.watchtower.enable=true

Die Unterstützung von „Middlewares“ ermöglicht Traefik, Anfragen und Antworten vor ihrer Weiterleitung zu modifizieren. Hierbei geht es insbesondere um Features wie Authentifizierung, Rate-Limiting, Umleitungen und HTML-Header Modifikationen, die im nächsten Kapitel näher thematisiert werden. Ein interessanter Aspekt von Traefik ist das sogenannte „Middleware-Chaining“, bei dem mehrere Middlewares in einer bestimmten Reihenfolge gruppiert angewendet werden können.

3. Implementierte Sicherheitsfeatures meines Blogs

3.1 SSL-Verschlüsselung

Mithilfe von Reverse-Proxys können eine Vielzahl an Sicherheitsfeatures implementiert werden. Dazu gehört unter anderem die Verschlüsselung von Anfragen mit SSL/TLS. SSL verschlüsselt Daten während der Übertragung und schafft so einen sicheren Kanal zwischen Client und Server. Würde der Kommunikationskanal abgehört werden, ist der Inhalt verschlüsselt und dadurch für Dritte unlesbar. Dies ist von entscheidender Bedeutung, da ohne diese Verschlüsselung, der Mitschnitt von sensiblen Informationen wie Passwörter und persönliche Daten möglich wäre.

Die HTTPS-Verschlüsselung wird mithilfe von Zertifikaten implementiert. Ein Zertifikat ist eine digitale Signatur, die die Authentizität einer Webseite bestätigt und von signifikanter Bedeutung ist, um Verschlüsselung zu realisieren. Die Verwaltung von Zertifikaten kann jedoch mühsam sein, insbesondere wenn für jede einzelne Web-Anwendung unterschiedliche Konfigurationen notwendig sind und jeweils ein eigenes Zertifikat benötigt wird.
In meinem Fall arbeite ich mit sogenannten Wildcard-Zertifikaten (*.sauna.re), die für alle Subdomänen einer Domain gültig sind, bei denen an der Stelle des Sterns jegliche Buchstaben stehen können. Dadurch benötige ich pro Domäne nur ein Zertifikat, was die Pflege erleichtert. Wildcard-Zertifikate können gekauft oder mit dem integrierten Acme-Bot von Let’s Encrypt, eine gemeinnützige Zertifizierungsstelle, die kostenlose SSL/TLS-Zertifikate bereitstellt, und der DNS Challenge [1] generiert werden.
Außerdem laufen Zertifikate in regelmäßigen Abständen ab, üblicherweise nach etwa einem Jahr, was zu Ausfällen führen kann. Ein bekanntes Beispiel ist der Microsoft Teams Ausfall im Februar 2020, der durch ein abgelaufenes Zertifikat verursacht wurde [2]. Daher ist es einfacher, alle Zertifikate zentral im Reverse-Proxy zu beantragen und verwalten.

Überdies kann ein Reverse-Proxy die Verschlüsselungsalgorithmen konfigurieren. Es gibt viele Algorithmen, einige davon sind jedoch veraltet und nicht mehr sicher, wie SSLv2 und SSLv3, die mehrfach geknackt wurden [3] [4]. Am Reverse-Proxy können diese veralteten Algorithmen zentral deaktiviert und die Verwendung sichererer Algorithmen erzwungen werden. Auf meinem Reverse-Proxy habe ich die aktuellen Richtlinien für Cipher-Suites konfiguriert, die auch für meinen Blog gelten. Diese Konfiguration kann hier entnommen und unter folgenden Links [5] [6] auf Sicherheitsempfehlungen getestet werden:

[tls.options]
  [tls.options.default]
    curvePreferences = [ "X25519", "CurveP256", "CurveP384"]
    sniStrict = true
    cipherSuites = [
        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", #tls1.2 #1
        "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", #tls1.2 #2
        "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384", #tls1.2 #3
        "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", #tls1.2 #4
        "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305", #tls1.2 #5
        "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305", #tls1.2 #6
        "TLS_AES_128_GCM_SHA256", #tls1.3 #1
        "TLS_AES_256_GCM_SHA384", #tls1.3 #2
        "TLS_CHACHA20_POLY1305_SHA256", #tls1.3 #3
        "TLS_FALLBACK_SCSV" #fallback
    ]

3.2 WAF

Ein weiteres Sicherheitsfeature, das durch einen Reverse-Proxy implementiert werden kann, ist eine Web Application Firewall (WAF). Eine WAF ist eine spezielle Art von Firewall, die zentral am Reverse-Proxy eingestellt werden kann, um den Datenverkehr zu überwachen und unerwünschten oder schädlichen Traffic zu blockieren. Dies bietet eine zusätzliche Sicherheitsebene und kann helfen, spezielle Web-basierte Angriffe, wie Cross-Site Scripting (XSS) oder SQL-Injection, abzuwehren. Für meinen Blog nutze ich das Traefik Modsecurity Plug-In, das alle Anfragen an den Modsecurity Container weiterleitet [7].

3.3 HTML-Header

Ansonsten ermöglichen Reverse-Proxys die zentrale Konfiguration von HTML-Headern, die für die Sicherheit wichtig sind. HTML-Header sind Informationen, die im HTTP-Header einer Webseite übertragen werden und verschiedene Zwecke erfüllen können, wie die Prävention von Clickjacking, die Implementierung einer strikten Transport-Security oder die Kontrolle von Content Security Policies. Durch die Konfiguration dieser HTML-Header kann die Sicherheit der Web-Anwendung verbessert werden, indem potenzielle Angriffsvektoren minimiert werden. Die konfigurierten Headers dieses Blogs sind beigefügt und können unter [8] getestet werden.

[http.middlewares.secure-headers.headers]
	#Basic Headers
	browserXssFilter = true
	contentTypeNosniff = true

	# HSTS
	stsSeconds = 63072000
	stsIncludeSubdomains = true
	stsPreload = true
	forceSTSHeader = true

	# Policies
	referrerPolicy = "same-origin"			
	
	# Accesscontrol
	accessControlAllowMethods= ["GET", "OPTIONS", "PUT"]
	accessControlMaxAge = 100
	hostsProxyHeaders = ["X-Forwarded-Host"]
	
	# TODO (müssen noch getestet und implementiert werden)
	# contentSecurityPolicy = "default-src 'self' 'unsafe-inline'" #new
	# featurePolicy = "camera 'none'; geolocation 'none'; microphone 'none'; payment 'none'; usb 'none'; vr 'none';"

3.4 Zugangskontrolle

Distributed Denial of Service (DDoS) sind bösartige Versuche, die Funktionalität einer Website zu stören, indem sie das Ziel mit einem Übermaß an Internetverkehr überfluten. Ein Reverse-Proxy mit Rate-Limiting Fähigkeiten kann dazu beitragen, einen Server vor DDoS-Angriffen zu schützen, indem er die Rate der Anfragen kontrolliert, die den Server erreichen.

Reverse-Proxys können ebenfalls verwendet werden, um Anwendungen in bestimmten IP-Bereichen zu öffnen. Sie stellen Single Sign-On (SSO)-Funktionen bereit, die mit Forward-Auth implementiert werden können, und ermöglichen Zugangskontrollen über IP-Whitelisting. Um die Authentifizierung zu bestätigen, bevor die Anfrage a den ursprünglichen Service weitergeleitet wird, wird jede Anfrage an eine bestimmte Service-URL weitergeleitet. Dies wird als „Forward-Auth“ bezeichnet.
Um die Sicherheit zu erhöhen und den Zugriff auf bestimmte Netzwerkressourcen zu beschränken, sind diese Maßnahmen besonders hilfreich. Ein anschauliches Beispiel dafür ist die Admin-URL dieses Blogs. Der Netzwerkverkehr auf https://fabio.sauna.re/ghost kann nur von meiner Heimadresse IP und dem SSO Provider Authelia (Forward-Auth Header) durchgeführt werden, was ein starkes Sicherheitsfeature darstellt. Detailliertere Informationen zu dieser Thematik können im letzten Post dieser Serie eingesehen werden [9].

# Rate-Limiting
[http.middlewares.rate-limit.rateLimit]
	average = 100
	burst = 50

# IP-Whitelisting (IPs zensiert)
[http.middlewares.whitelist.ipwhitelist]         
	sourceRange = ["9.9.9.9/24", "8.8.8.8"]

ä Forward-Auth (Adresse zensiert)
[http.middlewares.oauth.forwardAuth]
	address = "http://authelia:9091/api/verify?rd=https://example.com/"
	trustForwardHeader = true
	authResponseHeaders = ["Remote-User", "Remote-Groups", "Remote-Name", "Remote-Email"]
	[http.middlewares.oauth.forwardAuth.tls]
		insecureSkipVerify = true    

4. Nachteile von Reverse-Proxys

Wie bereits erwähnt, bietet der Einsatz von Reverse-Proxys zahlreiche Vorteile. Jedoch gibt es auch Nachteile bei der Implementierung von Reverse-Proxys, diese Nachteile werden im folgenden Abschnitt erläutert.

Der größte Nachteil der Implementierung von Reverse-Proxys ist, dass sie eine potenzielle Single-Point-of-Failure-Komponente sind. Infolgedessen können alle Serveranwendungen im dahinterliegenden Netzwerk nicht genutzt werden, wenn der Reverse-Proxy ausfällt. Daher ist es bei Einhaltung der Uptime die beste Praxis, mehr als einen Reverse-Proxy im Netzwerk zu implementieren.

Die Einstellung und Implementierung von Reserve-Proxys kann sich als äußerst komplex gestalten und daher sind Fehler in der Konfiguration wahrscheinlicher. Zum Beispiel, bei falscher Konfiguration des Cachings, können veraltete Inhalte an die Benutzer ausgeliefert werden. Fataler wären inkorrekte Einstellungen in der Verschlüsselung, die die Sicherheit der Kommunikation gefährden würden. Fehlkonfigurationen können es Angreifern ermöglichen, sensible Informationen abzufangen oder Manipulationen vorzunehmen, was schwerwiegende Sicherheitsverletzungen zur Folge haben kann. Die Integration eines Reverse-Proxys in ein System trägt zur Steigerung seiner Gesamtkomplexität bei. Sie stellt eine zusätzliche Anwendung dar, die gewartet, aktualisiert und überwacht werden muss, was den Arbeitsaufwand in der Systemadministration erhöht.

Aufgrund der Umleitung aller Anfragen durch den Reverse-Proxy besteht die Möglichkeit, dass Engpässe im Netzwerk auftreten und dadurch der Netzwerkverkehr verlangsamt wird. Um dies zu verdeutlichen, möchte ich ein konkretes Beispiel nennen, das auf meinem Server auftritt. Wenn ich einen Speedtest mit der Anwendung LibreSpeed durchführe, erhalte ich eine wesentlich höhere Verbindungsgeschwindigkeit, wenn ich direkt auf die Anwendung zugreife (http://202.61.227.137:8090), im Vergleich zur Verwendung des Proxys (https://speed.sauna.re). Dies könnte an einer fehlerhaften Konfiguration liegen, aber auch daran, dass Traefik im Vergleich zu anderen Reverse-Proxys neuer auf dem Markt ist und noch nicht gleich schnell leistet wie der Nginx. Dieser Leistungsunterschied ist aber in meinem Fall weniger wichtig, da Traefik mir einzigartige Features bietet, die Nginx nicht hat.

5. Persönliche Meinung zu Traefik

Meine Reise mit Traefik begann bereits 2019, ein Weg, der zweifellos mit Herausforderungen verbunden war. Das Produkt war zu diesem Zeitpunkt noch sehr neu auf dem Markt, was bedeutete, dass die Initialisierung eine erhebliche Herausforderung darstellte. Als die Version 2.x eingeführt wurde, fand ich mich inmitten einer Fülle von „Breaking Changes“ wieder. Dies erforderte eine umfassende Überarbeitung meiner bisherigen Konfiguration.

Eine meiner Lieblingsfunktionen von Traefik ist das sogenannte „Chaining“ von Middlewares, was eine einfache und replizierbare Konfiguration ermöglicht. Hiermit kann ich Dienste gruppieren und verschiedene Sicherheitsfunktionen wie IP-Whitelisting, Rate-Limiting und HTML-Header in Chains kombinieren.
Zudem schätze ich die eingebaute DNS-Challenge und die dynamische Konfiguration, die neue Container automatisch lädt und sich selbst aktualisiert. Das hat das Management meiner Infrastruktur erheblich vereinfacht und wäre unter dem Nginx oder Apache nicht möglich.
Ferner bietet das integrierte Dashboard eine hervorragende Übersicht, während Plug-Ins die Möglichkeit zur Erweiterung der Funktionalität darstellen.

Letztlich hat sich Traefik in meiner Homelab-Umgebung, in der hauptsächlich Docker-Container betrieben werden, als die optimale Lösung herausgestellt. Im Vergleich zu Konkurrenzprodukten wie Nginx sind die Vorteile von Traefik unverkennbar. Es ist ein vielseitiges, flexibles und leistungsstarkes Tool, das meine Netzwerkanforderungen effektiv erfüllt und die Verwaltung meiner Anwendungen erheblich erleichtert hat.

Weitere Posts aus dieser Serie

Vorlesungsinhalt: Entwicklung verteilter Systeme

Der Vorlesungsinhalt des Moduls „Entwicklung verteilter Systeme“ der DHBW-Mannheim wird mit einem Fokus auf Server-Client-Beziehungen erklärt.

Fabio SaunaFabio Sauna

Schwerpunkt 1: Content Management System (CMS) Ghost

Entdecke das alternative CMS Ghost. Ein benutzerfreundliches Open-Source-System, das ein leistungsstarkes Blogging ermöglicht.

Fabio SaunaFabio Sauna

Schwerpunkt 3: Identity and Access Management (IAM) Authelia

Authelia, ein Open-Source IAM, vereint Authentifizierung und Autorisierung. Lerne seine Funktionsweise und Einbindung kennen.

Fabio SaunaFabio Sauna