Nginx-Sicherheitsbest Practices: Schützen Sie Ihren Webserver

Ihr Nginx-Server ist oft der erste öffentliche Dienst, den Benutzer und Angreifer erreichen können. Diese Nginx-Sicherheitsbest Practices konzentrieren sich auf die Kontrollen, die Nginx tatsächlich durchsetzen kann: TLS, Anfragenlimits, Header, Zugriffsregeln, sicherere Standardeinstellungen und regelmäßige Updates.

Nginx kann fehlerhaften Anwendungscode nicht von selbst reparieren. Behandeln Sie es als eine Schicht vor Ihrer App, Datenbank, Authentifizierungssystem und Host-Firewall.

Sichere Verbindungen mit TLS

TLS verschlüsselt den Datenverkehr zwischen dem Browser und Ihrem Server. Verwenden Sie ein vertrauenswürdiges Zertifikat, leiten Sie HTTP auf HTTPS um und deaktivieren Sie veraltete Protokollversionen.

Ein Zertifikat erhalten

Let's Encrypt ist für öffentliche Websites üblich, aber jede vertrauenswürdige Zertifizierungsstelle kann funktionieren. Auf vielen Linux-Servern speichert Certbot Dateien unter /etc/letsencrypt/live/your_domain.com/.

HTTPS konfigurieren

Bearbeiten Sie den Serverblock für Ihre Domain. Der Pfad ist oft /etc/nginx/sites-available/ auf Debian/Ubuntu oder /etc/nginx/conf.d/ auf RHEL-basierten Systemen.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name your_domain.com www.your_domain.com;

    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;

    # Fügen Sie Ihre gemeinsamen TLS-Einstellungen ein
    include /etc/nginx/snippets/ssl-params.conf;

    # ... andere Konfigurationen (root, location-Blöcke usw.)
}

server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com www.your_domain.com;

    # HTTP auf HTTPS umleiten
    return 301 https://$host$request_uri;
}

Konservative TLS-Parameter verwenden

Sie können gemeinsame TLS-Einstellungen in einem Snippet wie /etc/nginx/snippets/ssl-params.conf speichern.

# /etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# HSTS (HTTP Strict Transport Security) aktivieren
# Fügen Sie includeSubDomains hinzu, falls zutreffend
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP Stapling für schnellere Zertifikatsprüfungen aktivieren
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Diffie-Hellman-Parameter (generieren Sie bei Bedarf einen starken)
# ssl_dhparam /etc/nginx/ssl/dhparams.pem;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Fügen Sie includeSubDomains oder preload nur zu HSTS hinzu, nachdem Sie wissen, dass jede Subdomain HTTPS unterstützt. Ein schlechter HSTS-Rollout kann Benutzer von älteren Subdomains aussperren.

Ratenbegrenzung implementieren

Ratenbegrenzung hilft, Brute-Force-Versuche, Scraping und versehentliche Anfragefluten zu verlangsamen. Es ist keine vollständige DDoS-Lösung, gibt Ihrer App aber mehr Spielraum.

Beispiel für grundlegende Ratenbegrenzung

limit_req_zone definiert den gemeinsamen Zustand, und limit_req wendet das Limit auf einen Standort an.

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        # ...

        location /login {
            limit_req zone=mylimit burst=10 nodelay;
            # ... Ihre Login-Handler-Konfiguration
        }

        location / {
            limit_req zone=mylimit burst=20 nodelay;
            # ... Ihre Hauptseitenkonfiguration
        }
    }
}

In diesem Beispiel: $binary_remote_addr schlüsselt das Limit nach Client-IP-Adresse. burst=10 erlaubt einen kurzen Burst über die durchschnittliche Rate hinaus, und nodelay lehnt übermäßige Anfragen ab, anstatt sie zu verzögern.

Seien Sie vorsichtig hinter einem Load Balancer oder CDN. Wenn Nginx nur die IP-Adresse des Proxys sieht, kann die Ratenbegrenzung durch $binary_remote_addr alle Benutzer als einen Client bestrafen. Konfigurieren Sie die vertrauenswürdige echte IP-Behandlung, bevor Sie sich auf clientseitige Limits verlassen.

Häufige Angriffsfläche reduzieren

Nginx kann die Angriffsfläche reduzieren, aber Ihre Anwendung benötigt dennoch Eingabevalidierung, Ausgabekodierung, parametrisierte SQL, Authentifizierungsprüfungen und Abhängigkeits-Patching.

Sicherheitsheader hinzufügen

Sicherheitsheader können das Risiko auf Browserseite reduzieren:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Eine Content Security Policy kann bei XSS helfen, muss aber mit den Skripten, Stilen, Bildern und Drittanbieterdiensten Ihrer App übereinstimmen. Starten Sie im Nur-Bericht-Modus, bevor Sie sie auf einer Produktionsseite durchsetzen.

Offensichtliche Scanner vorsichtig blockieren

Einfache Musterblöcke können laute Scanner stoppen, sind aber kein Ersatz für eine WAF. Halten Sie sie eng, damit Sie keine legitimen Benutzer blockieren.

http {
    # Definieren Sie eine Map zum Blockieren böser Bots/Scanner
    map $http_user_agent $bad_bot {
        default 0;
        "~*malicious_bot_pattern" 1;
        "~*another_suspicious_agent" 1;
    }

    server {
        # ...
        if ($bad_bot) {
            return 403;
        }
        # ...
    }
}

Sensible Pfade einschränken

Verwenden Sie try_files, halten Sie autoindex ausgeschaltet, es sei denn, Sie benötigen Verzeichnislisten, und verweigern Sie den Zugriff auf versteckte Dateien, die niemals ausgeliefert werden sollten.

location / {
    root /var/www/html;
    index index.html index.htm;
    try_files $uri $uri/ =404;
    autoindex off; # Verzeichnislisting deaktivieren
}

# Beispiel für die Einschränkung des Zugriffs auf sensible Dateien
location ~ /\.ht {
    deny all;
}

Die Nginx-Version ausblenden

server_tokens off entfernt die Nginx-Version aus generierten Fehlerseiten und reduziert Details im Server-Antwortheader.

http {
    server_tokens off;
    # ...
}

HTTP-Methoden bei Bedarf einschränken

Wenn ein Endpunkt nur GET und POST akzeptiert, lehnen Sie andere Methoden dort ab. Tun Sie dies pro Standort, damit Sie keine CORS-Preflight-Anfragen oder API-Endpunkte stören, die legitimerweise PUT, PATCH oder DELETE verwenden.

location /api/ {
    # Nur GET und POST erlauben
    if ($request_method !~ ^(GET|POST)$) {
        return 405;
    }
    # ...
}

Nginx aktualisiert halten

Sicherheitsupdates kommen oft über das Paket-Repository Ihrer Linux-Distribution. Halten Sie Nginx und OpenSSL-bezogene Pakete gepatcht und testen Sie Neuladungen nach Updates.

Für Debian/Ubuntu:

sudo apt update
sudo apt upgrade nginx

Für CentOS/RHEL:

sudo dnf update nginx

Verwenden Sie yum update nginx auf älteren RHEL/CentOS-Versionen, die noch yum verwenden.

Host-Level-Schutz hinzufügen

Die Nginx-Sicherheit hängt auch vom Host um ihn herum ab:

• Erlauben Sie nur notwendige Ports in ufw, firewalld, Cloud-Sicherheitsgruppen oder Netzwerk-ACLs.
• Überwachen Sie /var/log/nginx/access.log und /var/log/nginx/error.log auf Spitzen, wiederholte 401/403-Antworten und verdächtige Pfade.
• Verwenden Sie Fail2ban oder ein ähnliches Tool, wenn Logmuster missbräuchliche Clients identifizieren können.
• Führen Sie sudo nginx -t vor jedem Neuladen aus, damit eine Sicherheitsänderung die Website nicht offline nimmt.

Fazit

Beginnen Sie mit HTTPS, Updates, eingeschränkten Ports, sicheren Headern und Ratenlimits auf sensiblen Pfaden wie /login. Überprüfen Sie dann regelmäßig Ihre Logs. Die meisten Nginx-Sicherheitserfolge kommen von stetiger Wartung und klarer Konfiguration, nicht von einer großen Härtungsdatei, die von einer anderen Site kopiert wurde.