Eine Standard-Nginx-Installation liefert Traffic aus. Sie schützt ihn nicht. Die Standardkonfiguration gibt die Versionsnummer preis, akzeptiert jede HTTP-Methode, sendet keine Sicherheitsheader und verwendet die TLS-Einstellungen, die OpenSSL bereitstellt.

Diese Anleitung härtet Nginx auf Debian 12 und Ubuntu 24.04. Jeder Abschnitt benennt zuerst die Bedrohung und zeigt dann die Direktive, die sie blockiert. Sie können diese Änderungen auf einem laufenden Server ohne Ausfallzeit anwenden.

Voraussetzungen:

Nginx installiert und mindestens eine Website über HTTPS erreichbar (Let's Encrypt SSL/TLS für Nginx einrichten auf Debian 12 und Ubuntu 24.04)
Root- oder sudo-Zugang
Grundkenntnisse der Nginx-Konfigurationsstruktur (Nginx-Konfigurationsdatei: Aufbau und Struktur erklärt)

Wir speichern alle Härtungsdirektiven in einer einzigen Include-Datei. Das hält Ihre Server-Blöcke sauber und erleichtert das Auditing:

sudo touch /etc/nginx/snippets/security-hardening.conf

Jeder Server-Block, der gehärtet werden soll, erhält eine Zeile:

include /etc/nginx/snippets/security-hardening.conf;

Nach jeder Änderung in dieser Anleitung testen und neu laden:

sudo nginx -t && sudo systemctl reload nginx

Wie verberge ich die Nginx-Serverversion?

Fügen Sie server_tokens off; im http-Block in /etc/nginx/nginx.conf hinzu. Das entfernt die Versionsnummer aus dem Server-Antwortheader und den Standard-Fehlerseiten. Angreifer scannen nach bestimmten Versionen mit bekannten CVEs. Die Version zu verbergen behebt keine Schwachstellen, erhöht aber die Kosten gezielter Angriffe.

Fügen Sie in /etc/nginx/nginx.conf innerhalb des http-Blocks hinzu:

server_tokens off;

Das gehört in die Hauptkonfiguration, nicht in das Snippet, da es global gilt.

Nach dem Neuladen prüfen Sie den Antwortheader:

curl -sI https://your-domain.com | grep -i server

Server: nginx

Keine Versionsnummer. Vor dieser Änderung stand dort etwas wie Server: nginx/1.24.0.

Wie blockiere ich Anfragen an unbekannte Hostnamen?

Wenn jemand die IP-Adresse Ihres Servers direkt anspricht oder einen unbekannten Hostnamen verwendet, liefert Nginx den ersten gefundenen Server-Block aus. Das öffnet die Tür für DNS-Rebinding-Angriffe und ermöglicht Scannern, Ihre Dienste zu identifizieren.

Ein Default-Server-Block, der alle nicht zugeordneten Anfragen ablehnt, verhindert das. Fügen Sie ihn als ersten Server-Block hinzu, den Nginx lädt:

sudo nano /etc/nginx/sites-available/00-default-deny.conf

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;

    server_name _;

    # Self-signed or snakeoil cert just to complete the TLS handshake
    ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;
    ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;

    return 444;
}

Statuscode 444 ist Nginx-spezifisch. Er schließt die Verbindung sofort, ohne eine Antwort zu senden.

Aktivieren Sie ihn:

sudo ln -s /etc/nginx/sites-available/00-default-deny.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Unter Debian 12 und Ubuntu 24.04 installieren Sie das Paket ssl-cert, falls das Snakeoil-Zertifikat fehlt:

sudo apt install ssl-cert

Testen Sie es durch direkten Zugriff auf die IP:

curl -sI -k https://YOUR_SERVER_IP

Die Verbindung schließt sich mit einer leeren Antwort oder einem curl-Fehler (Exit-Code 52). Kein Inhalt ausgeliefert.

Welche TLS-Konfiguration sollte ich 2026 für Nginx verwenden?

Verwenden Sie das Intermediate-Profil von Mozilla: TLS 1.2 und 1.3 mit Forward-Secret-Cipher-Suites. Das deckt Clients bis Firefox 27 und Android 4.4.2 ab und verwirft unsichere Protokolle. TLS 1.0 und 1.1 sind anfällig für POODLE und BEAST und wurden seit RFC 8996 (2021) als veraltet eingestuft. Wenn alle Ihre Clients TLS 1.3 unterstützen, verwenden Sie stattdessen das Modern-Profil (ssl_protocols TLSv1.3;).

Die TLS-Härtung wurde Anfang 2026 dringlicher. CVE-2026-1642 (CVSS 5.9) zeigte, dass die TLS-Upstream-Verarbeitung von Nginx eine Race Condition aufwies, die MitM-Injection vor Abschluss des Handshakes ermöglichte. Der Fix wurde in Nginx 1.28.2 und 1.29.5 veröffentlicht. Prüfen Sie Ihre Version mit nginx -v und aktualisieren Sie bei Bedarf.

Profil	Protokolle	Ältester Client	Anwendungsfall
Modern	Nur TLS 1.3	Firefox 63, Chrome 70	APIs, moderne Webanwendungen
Intermediate	TLS 1.2 + 1.3	Firefox 27, Android 4.4	Allzweck-Server
Old	TLS 1.0 + 1.1 + 1.2 + 1.3	IE 8 auf XP	Nur Legacy-Kompatibilität

Generieren Sie DH-Parameter für die DHE-Cipher-Suites im Intermediate-Profil. Das dauert einige Minuten:

sudo openssl dhparam -out /etc/nginx/dhparam.pem 2048
sudo chmod 644 /etc/nginx/dhparam.pem

Fügen Sie die TLS-Härtung in /etc/nginx/snippets/security-hardening.conf hinzu:

# TLS protocols - Mozilla Intermediate profile
ssl_protocols TLSv1.2 TLSv1.3;

# Cipher suites - Mozilla Intermediate profile (version 5.7)
# TLS 1.3 suites are configured automatically by OpenSSL
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:DHE-RSA-CHACHA20-POLY1305';

ssl_prefer_server_ciphers off;
ssl_dhparam /etc/nginx/dhparam.pem;

# Session settings
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

Warum ssl_prefer_server_ciphers off? Mit ausschließlich starken Ciphern in der Liste liefert die Client-Präferenz bessere Performance. Clients wählen den Cipher, den ihre Hardware am besten beschleunigt.

Warum ssl_session_tickets off? Session-Tickets verwenden einen serverweiten Schlüssel. Wenn dieser Schlüssel kompromittiert wird, kann ein Angreifer alle aufgezeichneten Sitzungen entschlüsseln. Ohne Tickets bietet der gemeinsame Session-Cache Wiederaufnahme nur auf demselben Server, was für Einzelserver-Setups ausreicht.

Hinweis zu OCSP-Stapling: Let's Encrypt hat seinen OCSP-Dienst im August 2025 eingestellt. Wenn Sie Let's-Encrypt-Zertifikate verwenden, entfernen Sie alle ssl_stapling-Direktiven. Sie verursachen Warnungen in Ihren Logs. Let's Encrypt veröffentlicht Widerrufsinformationen nun ausschließlich über CRLs.

Laden Sie neu und testen Sie von Ihrem lokalen Rechner:

openssl s_client -connect your-domain.com:443 -tls1_2 </dev/null 2>/dev/null | grep "Protocol\|Cipher"

    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

Bestätigen Sie, dass TLS 1.1 abgelehnt wird:

openssl s_client -connect your-domain.com:443 -tls1_1 </dev/null 2>&1 | head -5

Der Handshake schlägt fehl. Für ein vollständiges Audit reichen Sie Ihre Domain bei SSL Labs ein. Ziel ist ein A- oder A+-Grade.

Wie aktiviere ich HSTS in Nginx?

HSTS (HTTP Strict Transport Security) weist Browser an, sich für einen festgelegten Zeitraum nur über HTTPS zu verbinden. Ohne HSTS kann ein MitM-Angreifer die erste HTTP-Anfrage abfangen und die Verbindung herabstufen. Sobald ein Browser den HSTS-Header gesehen hat, verweigert er Klartext-HTTP-Verbindungen zu Ihrer Domain, bis max-age abläuft.

Fügen Sie in /etc/nginx/snippets/security-hardening.conf hinzu:

# HSTS - 2 years, include subdomains
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

Das Flag always stellt sicher, dass Nginx diesen Header auch bei Fehlerantworten sendet (4xx, 5xx). Ohne always würde eine 403- oder 500-Antwort den Header nicht enthalten und ein Fenster für Downgrade-Angriffe offenlassen.

Bevor Sie includeSubDomains hinzufügen, stellen Sie sicher, dass alle Ihre Subdomains HTTPS unterstützen. Diese Direktive gilt für jede Subdomain. Eine Subdomain ohne gültiges Zertifikat wird unerreichbar.

HSTS-Preloading: Das Hinzufügen von preload zum Header und die Übermittlung Ihrer Domain an hstspreload.org verankert die HTTPS-Erzwingung fest in Browsern. Das ist dauerhaft. Die Entfernung dauert Monate. Fügen Sie preload erst hinzu, wenn Sie sicher sind, dass jede Subdomain immer HTTPS bereitstellt.

Nach dem Neuladen:

curl -sI https://your-domain.com | grep -i strict

strict-transport-security: max-age=63072000; includeSubDomains

Welche Sicherheitsheader sollte jeder Nginx-Server haben?

Fünf Antwortheader schützen gegen verbreitete browserseitige Angriffe: MIME-Sniffing, Clickjacking, Cross-Site-Scripting, Referrer-Leaks und Missbrauch von Browser-APIs. Fügen Sie alle fünf mit dem always-Flag hinzu, damit sie auch bei Fehlerantworten gelten. Der veraltete X-XSS-Protection-Header sollte nicht eingebunden werden. Moderne Browser haben ihre XSS-Auditoren entfernt, und der Header selbst hat in einigen Fällen Schwachstellen verursacht.

Fügen Sie in /etc/nginx/snippets/security-hardening.conf hinzu:

# Prevent MIME type sniffing - stops browsers from interpreting files as a
# different content type than declared, blocking drive-by download attacks
add_header X-Content-Type-Options "nosniff" always;

# Clickjacking protection - prevents your pages from being embedded in
# iframes on other sites
add_header X-Frame-Options "SAMEORIGIN" always;

# Content Security Policy - controls which sources can load scripts, styles,
# images, and other resources. Start restrictive, loosen as needed.
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self';" always;

# Referrer Policy - controls how much URL information the browser sends
# when navigating away from your site
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Permissions Policy - disables browser features you don't use, preventing
# compromised scripts from accessing camera, microphone, etc.
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;

interest-cohort=() tauchte in älteren Anleitungen auf, um Google FLoC zu blockieren. FLoC wurde 2023 eingestellt. Moderne Browser erkennen diese Direktive nicht und geben Konsolenwarnungen aus, wenn Sie sie einbinden.

Header	Wert	Abgewehrte Bedrohung
X-Content-Type-Options	`nosniff`	MIME-Confusion-Angriffe, Drive-by-Downloads
X-Frame-Options	`SAMEORIGIN`	Clickjacking über Iframe-Einbettung
Content-Security-Policy	`default-src 'self'`	XSS, Dateninjection, nicht autorisiertes Laden von Ressourcen
Referrer-Policy	`strict-origin-when-cross-origin`	URL-Leaks an Dritte
Permissions-Policy	`camera=(), microphone=()...`	Missbrauch von Browser-APIs durch injizierte Skripte

CSP-Anpassung: Das obige Beispiel ist strikt. Die meisten Anwendungen brauchen Anpassungen. Wenn Ihre Website Skripte von einem CDN lädt, fügen Sie es hinzu: script-src 'self' https://cdn.example.com;. Nutzen Sie die Entwicklerkonsole Ihres Browsers, um CSP-Verstöße zu finden, und lockern Sie die Richtlinie schrittweise. Verwenden Sie niemals unsafe-eval, ohne das Risiko zu verstehen.

Die `add_header`-Vererbungsfalle

Nginx verwirft alle add_header-Direktiven aus übergeordneten Blöcken, wenn ein untergeordneter location-Block eigene add_header-Direktiven definiert. Wenn Sie einen Header in einem location-Block hinzufügen, verschwinden alle Sicherheitsheader der server- oder http-Ebene aus den Antworten dieser Location.

Zwei Lösungen:

Nginx 1.29.3+: Verwenden Sie add_header_inherit merge; im untergeordneten Block, um übergeordnete Header zu erhalten.
Ältere Versionen: Wiederholen Sie die Zeile include /etc/nginx/snippets/security-hardening.conf; in jedem Location-Block, der eigene Header hinzufügt.

Laden Sie neu und prüfen Sie:

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://your-domain.com | grep -iE "x-content-type|x-frame|content-security|referrer-policy|permissions-policy"

Alle fünf Header erscheinen in der Ausgabe. Prüfen Sie auch einen bestimmten location-Pfad, nicht nur die Wurzel, um Vererbungsprobleme aufzudecken.

Wie deaktiviere ich unsichere HTTP-Methoden in Nginx?

Die meisten Websites benötigen nur GET, HEAD und POST. Methoden wie DELETE, PUT, TRACE und OPTIONS (wenn ungenutzt) vergrößern Ihre Angriffsfläche. TRACE kann insbesondere Cookies und Auth-Tokens durch Cross-Site-Tracing-Angriffe (XST) leaken.

Der sauberste Ansatz in Standard-Nginx ist limit_except, das speziell für Methodeneinschränkungen entwickelt wurde. Platzieren Sie es in Ihren location-Blöcken:

location / {
    limit_except GET POST {
        deny all;
    }

    # ... your existing config
}

limit_except GET erlaubt implizit HEAD (HEAD ist ein GET ohne Body laut HTTP-Spezifikation). Jede nicht aufgeführte Methode gibt 403 Forbidden zurück.

Für einen globalen Ansatz mit map (in nginx.conf im http-Block hinzufügen):

map $request_method $method_not_allowed {
    default  1;
    GET      0;
    HEAD     0;
    POST     0;
}

Dann im Server-Block:

if ($method_not_allowed) {
    return 405;
}

Der limit_except-Ansatz wird bevorzugt, wenn Sie Kontrolle pro Location benötigen. Der map-Ansatz eignet sich für eine serverweite Pauschalrichtlinie.

Testen Sie mit einer blockierten Methode:

curl -sI -X DELETE https://your-domain.com

Gibt HTTP/1.1 403 Forbidden oder HTTP/1.1 405 Not Allowed zurück.

curl -sI -X GET https://your-domain.com

Gibt HTTP/1.1 200 OK zurück (oder Ihren normalen Antwortcode).

Wie beschränke ich den Zugriff auf Admin-Pfade nach IP-Adresse?

Admin-Panels, Monitoring-Dashboards und Status-Endpunkte sollten nicht aus dem öffentlichen Internet erreichbar sein. Die Nginx-Direktiven allow und deny beschränken den Zugriff auf IP-Adress-Ebene pro Location.

location /admin {
    allow 203.0.113.10;      # Your office IP
    allow 198.51.100.0/24;   # Your VPN range
    deny all;

    # ... proxy_pass or other directives
}

location /nginx-status {
    stub_status;
    allow 127.0.0.1;
    allow ::1;
    deny all;
}

Die Reihenfolge ist entscheidend. Nginx wertet allow und deny von oben nach unten aus und stoppt beim ersten Treffer. Setzen Sie deny all an den Schluss.

Wenn sich Ihre IP häufig ändert, ziehen Sie eine Zugriffsbeschränkung über Ihre Firewall oder ein VPN in Betracht. IP-basierte ACLs in Nginx sind eine zweite Schutzschicht, kein Ersatz für Authentifizierung.

Von einer erlaubten IP:

curl -sI https://your-domain.com/admin

Gibt Ihre normale Antwort zurück (200, 302, etc.).

Von einer anderen IP (oder über einen Proxy) gibt dieselbe Anfrage HTTP/1.1 403 Forbidden zurück.

Prüfen Sie das Zugriffslog auf abgelehnte Anfragen:

sudo tail -5 /var/log/nginx/access.log | grep admin

Welche Buffer- und Timeout-Limits verhindern DoS-Angriffe in Nginx?

Standard-Buffergrößen und Timeouts sind großzügig. Ein Angreifer kann dies ausnutzen, indem er große Header, langsame Anfragen oder übergroße Bodies sendet, um Worker-Verbindungen zu blockieren. Das Verschärfen dieser Werte begrenzt den Schaden, den eine einzelne Verbindung anrichten kann.

Fügen Sie in /etc/nginx/snippets/security-hardening.conf hinzu:

# Maximum allowed request body size - reject uploads larger than 10MB
client_max_body_size 10m;

# Buffer for reading client request body
client_body_buffer_size 16k;

# Buffer for reading large client headers
large_client_header_buffers 4 16k;

# Timeouts - how long Nginx waits for client data
client_body_timeout 30s;
client_header_timeout 30s;
send_timeout 30s;
keepalive_timeout 65s;

Direktive	Wert	Zu hoch	Zu niedrig
`client_max_body_size`	`10m`	Erlaubt riesige Uploads, die die Festplatte füllen	Bricht Upload-Formulare
`client_body_buffer_size`	`16k`	Speicherverschwendung pro Verbindung	Erzwingt Temp-Dateien für kleine POSTs
`large_client_header_buffers`	`4 16k`	Speicherverschwendung bei Header-Angriffen	Bricht Apps mit großen Cookies/URLs
`client_body_timeout`	`30s`	Slow-Loris-Verbindungen bleiben offen	Trennt Nutzer in langsamen Netzen
`client_header_timeout`	`30s`	Wie oben	Wie oben
`send_timeout`	`30s`	Blockiert Verbindungen für langsame Clients	Bricht große Downloads ab
`keepalive_timeout`	`65s`	Erschöpfung des Verbindungspools	Zusätzliche TLS-Handshakes

Passen Sie client_max_body_size an Ihre Anwendung an. Wenn Sie Datei-Uploads verarbeiten, setzen Sie den Wert auf das, was Ihre App erwartet. Ein Standardwert von 10 MB ist für die meisten Webanwendungen angemessen.

Laden Sie neu und testen Sie das Body-Size-Limit:

dd if=/dev/zero bs=1M count=11 2>/dev/null | curl -s -X POST --data-binary @- -o /dev/null -w "%{http_code}" https://your-domain.com/

Erwartet: 413 (Request Entity Too Large).

Für Rate Limiting und tiefgreifenderen DDoS-Schutz siehe Nginx Rate Limiting und DDoS-Schutz.

Wie teste ich die vollständige Härtungskonfiguration?

Sobald alle Änderungen vorgenommen sind, laden Sie neu und gehen Sie die wichtigsten Prüfpunkte durch. Beginnen Sie mit einem Konfigurationstest und Neuladen:

sudo nginx -t && sudo systemctl reload nginx

Prüfen Sie Header und Versionsinformationen mit einer einzigen Anfrage:

curl -sI https://your-domain.com

Der Server-Header sollte nginx ohne Versionsnummer zeigen. Alle sechs Sicherheitsheader (HSTS, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Referrer-Policy, Permissions-Policy) sollten in der Antwort erscheinen.

Für TLS bestätigen Sie Protokoll und Cipher von Ihrem lokalen Rechner:

openssl s_client -connect your-domain.com:443 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

Sie wollen TLSv1.2 oder TLSv1.3 mit einem GCM- oder CHACHA20-Cipher.

Greifen Sie direkt auf die Server-IP zu, um den Default-Deny-Block zu prüfen:

curl -sk https://YOUR_SERVER_IP -o /dev/null -w "%{http_code}"

Ein Antwortcode von 000 bedeutet, dass die Verbindung ohne Antwort geschlossen wurde, was korrekt ist.

Versuchen Sie eine blockierte HTTP-Methode:

curl -sI -X TRACE https://your-domain.com -o /dev/null -w "%{http_code}"

Das sollte 403 oder 405 zurückgeben.

Für ein externes Audit reichen Sie Ihre Domain bei SSL Labs ein (Ziel: A oder A+) und bei securityheaders.com für einen Header-spezifischen Bericht.

Vollständiges Härtungs-Snippet

Die vollständige /etc/nginx/snippets/security-hardening.conf mit allem aus dieser Anleitung:

# /etc/nginx/snippets/security-hardening.conf
# Nginx security hardening - include in each server block

# --- TLS Hardening (Mozilla Intermediate profile v5.7) ---
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:DHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers off;
ssl_dhparam /etc/nginx/dhparam.pem;

# TLS session settings
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# --- HSTS ---
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# --- Security Headers ---
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self';" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;

# --- Buffer Limits ---
client_max_body_size 10m;
client_body_buffer_size 16k;
large_client_header_buffers 4 16k;

# --- Timeouts ---
client_body_timeout 30s;
client_header_timeout 30s;
send_timeout 30s;
keepalive_timeout 65s;

Denken Sie daran, auch server_tokens off; im http-Block von /etc/nginx/nginx.conf zu setzen und den Default-Deny-Server-Block separat zu erstellen.

Fehlerbehebung

Nginx lädt nach Änderungen nicht neu:

sudo nginx -t

Lesen Sie die Fehlermeldung. Sie nennt Datei und Zeilennummer. Häufige Ursachen: fehlende Semikolons, Tippfehler in Direktivennamen, Verweis auf eine nicht existierende DH-Parameter-Datei.

Header fehlen auf bestimmten Pfaden:

Die add_header-Vererbungsfalle. Wenn ein location-Block eigene add_header-Direktiven hat, werden alle übergeordneten Header verworfen. Binden Sie das Snippet in diesem Location-Block ein oder verwenden Sie add_header_inherit merge; ab Nginx 1.29.3+.

CSP blockiert legitime Ressourcen:

Öffnen Sie die Entwicklerkonsole des Browsers (F12). Suchen Sie nach Refused to load-Fehlern. Sie benennen die blockierte Ressource und die verantwortliche CSP-Direktive. Fügen Sie die Quelle schrittweise zu Ihrer Richtlinie hinzu.

TLS-Handshake-Fehler:

journalctl -u nginx -f

Beobachten Sie SSL-Fehler während der Verbindung. Prüfen Sie, ob Ihre Zertifikatskette vollständig ist:

openssl s_client -connect your-domain.com:443 -servername your-domain.com </dev/null 2>/dev/null | grep "Verify return code"

Erwartet: Verify return code: 0 (ok).

Log-Speicherort:

# Error log
sudo tail -20 /var/log/nginx/error.log

# Real-time monitoring
sudo journalctl -u nginx -f

Nächste Schritte: Nach der Härtung des Servers richten Sie Nginx Rate Limiting und DDoS-Schutz ein, um missbräuchliche Verkehrsmuster zu bewältigen. Für standortspezifische Konfigurationen siehe Nginx Server Blocks: Mehrere Domains auf einem VPS betreiben.

Verwandt: Nginx-Administration auf einem VPS | Nginx-Konfigurationsdatei: Aufbau und Struktur erklärt | Let's Encrypt SSL/TLS für Nginx einrichten auf Debian 12 und Ubuntu 24.04

Nginx-Sicherheitshärtung unter Ubuntu und Debian

Wie verberge ich die Nginx-Serverversion?

Wie blockiere ich Anfragen an unbekannte Hostnamen?

Welche TLS-Konfiguration sollte ich 2026 für Nginx verwenden?

Wie aktiviere ich HSTS in Nginx?

Welche Sicherheitsheader sollte jeder Nginx-Server haben?

Die `add_header`-Vererbungsfalle

Wie deaktiviere ich unsichere HTTP-Methoden in Nginx?

Wie beschränke ich den Zugriff auf Admin-Pfade nach IP-Adresse?

Welche Buffer- und Timeout-Limits verhindern DoS-Angriffe in Nginx?

Wie teste ich die vollständige Härtungskonfiguration?

Vollständiges Härtungs-Snippet

Fehlerbehebung

Verwandte Artikel