Reverse Proxy

Ausführliche Erklärung

Ein Reverse Proxy positioniert sich vor einem oder mehreren Webservern und ist der zentrale Eingangspunkt für alle Anfragen aus dem Internet. Anders als ein Forward Proxy, der ausgehende Verbindungen von Clients ins Internet vermittelt, schützt ein Reverse Proxy die serverseitige Infrastruktur: Er verbirgt IP-Adressen und Aufbau der Backend-Server, sodass Angreifer keinen direkten Zugriff auf die eigentlichen Systeme erhalten.

Die Aufgaben gehen deutlich über das Weiterleiten hinaus. Der Reverse Proxy übernimmt die Lastverteilung (Load Balancing), indem er eingehenden Verkehr nach definierten Regeln auf mehrere Backend-Server verteilt und so die Überlastung einzelner Systeme verhindert. Durch Caching häufig angeforderter Inhalte wie Bilder oder statischer Dateien senkt er die Serverlast und beschleunigt die Auslieferung. Und er kann die TLS-Verschlüsselung zentral beenden (SSL- bzw. TLS-Terminierung), wodurch das rechenintensive Ver- und Entschlüsseln von den Backend-Servern wegfällt und die Zertifikatsverwaltung an einer Stelle zusammenläuft.

Für Unternehmen ist der Reverse Proxy damit ein Baustein der IT-Sicherheitsarchitektur. Er kann zusätzliche Schutzfunktionen bündeln – Web Application Firewall, Schutz gegen Überlastungsangriffe, IP-Filterung, Begrenzung der Anfragerate – und dient in Zero-Trust-Architekturen als zentrale Stelle, an der Zugriffsregeln durchgesetzt werden. Gängige Implementierungen sind Nginx, Apache mit mod_proxy, HAProxy und Traefik, die sich je nach Anforderung unterschiedlich gut eignen.

In der Praxis erlaubt ein Reverse Proxy es, Webanwendungen und Schnittstellen geordnet bereitzustellen, die Verfügbarkeit zu erhöhen und die Komplexität der internen Infrastruktur nach außen zu verbergen. Wartungsarbeiten an einzelnen Backend-Servern lassen sich durchführen, ohne dass die Dienste für die Nutzer ausfallen. Zu bedenken ist die Kehrseite: Der Reverse Proxy wird zum gemeinsamen Engpass und zum attraktiven Angriffsziel – er braucht dieselbe Sorgfalt bei Updates, Protokollierung und Ausfallsicherheit wie die Systeme, die er schützt.

Code-Beispiel

# Die Cache-Zone muss im http-Block definiert sein, sonst startet nginx nicht:
# proxy_cache_path /var/cache/nginx keys_zone=portal_cache:10m;

server {
    listen 80;
    server_name portal.beispielbau.at;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name portal.beispielbau.at;

    ssl_certificate     /etc/ssl/portal/fullchain.pem;
    ssl_certificate_key /etc/ssl/portal/privkey.pem;

    location / {
        proxy_pass http://backend:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Caching für statische Inhalte
    location ~* \.(jpg|png|pdf)$ {
        proxy_cache portal_cache;
        proxy_pass http://backend:8080;
    }
}