Wesentliche Nginx-Sicherheit: Best Practices und häufig gestellte Fragen zur Fehlerbehebung

Wesentliche Nginx-Sicherheit ist nicht eine einzelne Einstellung oder ein magischer Header. Es ist eine Sammlung sorgfältiger Standardeinstellungen: HTTPS, strikter Dateizugriff, sicheres Proxy-Verhalten, begrenzte Exposition und Logs, die Ihnen helfen, Probleme zu erkennen, bevor sie wachsen.

Diese FAQ behandelt die Fragen, die Teams normalerweise stellen, nachdem sie Nginx online gebracht haben und feststellen, dass die Standardkonfiguration nur ein Ausgangspunkt ist.

Welche Nginx-Sicherheitseinstellungen sollten zuerst überprüft werden?

Beginnen Sie mit den Grundlagen, die versehentliche Exposition reduzieren. Diese Einstellungen schützen vor häufigen Fehlern, nicht vor fortgeschrittenen Angriffen.

Deaktivieren Sie zunächst die Versions-Tokens:

server_tokens off;

Dies verhindert, dass Nginx seine Version in Fehlerseiten und Headern anzeigt. Es macht den Server nicht unsichtbar, aber es entfernt unnötige Details.

Zweitens stellen Sie sicher, dass Ihr Dokumentenstammverzeichnis korrekt ist. Ein häufiger Fehler ist, root auf ein Projektverzeichnis anstatt auf das öffentliche Build-Verzeichnis zu setzen. Das kann Quelldateien, Umgebungsbeispiele oder private Assets offenlegen.

Für eine statische Seite bevorzugen Sie etwas wie:

root /var/www/example.com/public;

nicht:

root /var/www/example.com;

Drittens blockieren Sie versteckte Dateien, es sei denn, Ihre Anwendung benötigt sie wirklich:

location ~ /\.(?!well-known) {
    deny all;
}

Dies erlaubt .well-known-Pfade, die für die Zertifikatsvalidierung verwendet werden, während Dateien wie .env, .git und .htpasswd verweigert werden.

Überprüfen Sie schließlich die Upload-Limits. Wenn Ihre Website keine großen Uploads akzeptiert, halten Sie client_max_body_size bescheiden. Dies reduziert die Schadensreichweite versehentlicher großer Anfragen.

Wie sollte Nginx HTTPS handhaben?

HTTPS sollte der normale Pfad für öffentliche Websites und APIs sein. Leiten Sie einfaches HTTP auf HTTPS um, verwenden Sie gültige Zertifikate und vermeiden Sie veraltete Protokolleinstellungen.

Ein einfacher Weiterleitungs-Serverblock sieht so aus:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Der HTTPS-Serverblock sollte auf Ihre Zertifikatsdateien verweisen und moderne TLS-Einstellungen enthalten. Viele Teams verwenden Certbot oder einen verwalteten Load Balancer, um Zertifikate zu verwalten. Wichtig ist, die Erneuerung automatisiert und überwacht zu halten.

Sicherheitsheader können Browsern auch helfen, sicherere Entscheidungen zu treffen:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Seien Sie vorsichtig mit der Content Security Policy. Sie ist leistungsstark, aber eine strenge Richtlinie kann Skripte, Schriftarten, Analysen oder eingebettete Inhalte beschädigen, wenn Sie sie ohne Tests anwenden. Starten Sie wenn möglich im Nur-Bericht-Modus.

Für eine praktische HTTPS-Anleitung siehe Nginx mit HTTPS sichern.

Wie sichere ich Nginx als Reverse Proxy?

Wenn Nginx Datenverkehr an eine App weiterleitet, müssen Sie die richtigen Anforderungsinformationen bewahren, ohne blind Client-Eingaben zu vertrauen.

Übliche Proxy-Header sehen so aus:

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;

Diese Header helfen der vorgelagerten Anwendung, die ursprüngliche Anfrage zu verstehen. Sie sind nützlich für Protokollierung, Weiterleitungen, Ratenbegrenzung und Sicherheitsprüfungen.

Wenn Nginx hinter einem anderen vertrauenswürdigen Proxy oder Load Balancer sitzt, konfigurieren Sie die echte IP-Behandlung sorgfältig. Vertrauen Sie nur bekannten Proxy-Adressen:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Vertrauen Sie X-Forwarded-For nicht aus dem offenen Internet. Ein Client kann diesen Header fälschen. Vertrauen Sie ihm nur, wenn die Anfrage von Ihrem Load Balancer, CDN oder internen Proxy kommt.

Sie sollten auch Details der vorgelagerten Implementierung verbergen. Wenn Ihre App frameworkspezifische Header zurückgibt, die Sie nicht benötigen, entfernen Sie sie auf der Proxy- oder Anwendungsebene.

Sollte ich Ratenbegrenzung verwenden?

Ratenbegrenzung ist nützlich für Anmeldeseiten, Such-Endpunkte, teure APIs und alle Routen, die Angreifer billig missbrauchen können. Es ist kein Ersatz für Anwendungssicherheit, aber es kann Brute-Force-Versuche und lauten Datenverkehr verlangsamen.

Beispiel:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

Dies erstellt einen gemeinsamen Speicherbereich, der nach Client-IP sortiert ist, und begrenzt Anfragen an den Login-Pfad. Die genauen Werte hängen von Ihren Benutzern ab. Ein Unternehmens-Dashboard kann normalerweise strengere Grenzen tolerieren als eine öffentliche Verbraucher-App in Mobilfunknetzen.

Testen Sie Ratenbegrenzungen sorgfältig. Wenn Ihre Website hinter einem Proxy liegt und Sie die echte Client-IP-Behandlung nicht konfiguriert haben, kann jeder Benutzer von derselben Adresse zu kommen scheinen. Das kann legitimen Datenverkehr blockieren.

Warum sehe ich immer noch verdächtige Anfragen?

Öffentliche Nginx-Server erhalten ständig Hintergrundgeräusche: Scans nach alten Admin-Panels, PHP-Dateien, WordPress-Pfaden und offengelegten Umgebungsdateien. Diese Anfragen in Logs zu sehen, bedeutet nicht immer, dass Sie kompromittiert sind.

Was zählt, ist, wie Ihr Server antwortet. Eine Anfrage nach /wp-admin auf einer Nicht-WordPress-Seite sollte 404 oder 403 zurückgeben. Eine Anfrage nach /.env sollte niemals Geheimnisse preisgeben. Eine Anfrage mit einem seltsamen Pfad sollte nicht an einen internen Admin-Dienst weitergeleitet werden.

Überprüfen Sie Ihre Zugriffslogs auf:

• Wiederholte 401- oder 403-Antworten
• Viele Anfragen von einer IP
• Große Anforderungskörper
• Sondierung nach versteckten Dateien
• Ungewöhnliche User-Agents
• Spitzen bei 499-, 502- oder 504-Antworten

Für eine breitere Fehlerbehebung siehe Nginx häufige Fehler.

Wann sollte ich um Sicherheitshilfe bitten?

Holen Sie einen Sicherheitsingenieur oder erfahrenen DevOps-Berater hinzu, wenn Nginx Kundendaten, Authentifizierung, Zahlungsflüsse, private APIs oder interne Admin-Tools schützt. Sie sollten auch Hilfe nach einem vermuteten Sicherheitsvorfall, unerwarteter Dateiexposition oder wiederholtem Angriffsverkehr, der die Verfügbarkeit beeinträchtigt, suchen.

Professionelle Überprüfung lohnt sich, wenn die Konfiguration mehrere Ebenen umfasst, wie CDN, Load Balancer, Nginx, Service Mesh und Anwendungsframework. Eine sichere Nginx-Datei kann immer noch durch eine schlechte Vertrauensgrenze an anderer Stelle geschwächt werden.

Sichern Sie Nginx, indem Sie unnötige Exposition entfernen, HTTPS erzwingen, Proxy-Header sorgfältig behandeln und Logs überwachen. Sie brauchen keine riesige Konfiguration, um sicherer zu sein. Sie brauchen klare Standardeinstellungen, getestete Änderungen und die Gewohnheit, zu überprüfen, was Ihr Server tatsächlich ausliefert.