CIDR Allow/Deny-Snippet-Generator (nginx)

nginx allow/deny-Direktiven aus CIDR-Liste generieren

IP Addresses / CIDRs

Configuration Type

Options

Include commentsAdd "deny all" at end

Nginx Configuration

Enter IP addresses to generate Nginx config

Der CIDR-Allow/Deny-Snippet-Generator fuer nginx erstellt einsatzbereite nginx-Konfigurationsbloecke mit allow- und deny-Direktiven aus Listen von IP-Adressen oder CIDR-Bloecken. Geben Sie Adressen wie 192.168.1.0/24 und 10.0.0.0/8 ein, waehlen Sie Allowlist- oder Blocklist-Modus, und erhalten Sie korrekt formatierte Direktiven, die Sie direkt in Ihre Server-Bloecke einfuegen oder als Include-Datei speichern koennen.

nginx-Zugriffskontrolle verstehen

Wenn Sie nginx als Webserver oder Reverse-Proxy betreiben, ist IP-basierte Zugriffskontrolle eine der einfachsten und wirksamsten Moeglichkeiten, sensible Ressourcen zu schuetzen. Das ngx_http_access_module ist standardmaessig in nginx kompiliert und erfordert keine zusaetzliche Installation -- Sie fuegen einfach allow- und deny-Direktiven zu Ihrer Konfiguration hinzu. Dies ist der Standardansatz zum Einschraenken von Admin-Panels, internen APIs, Staging-Servern und jedem Endpunkt, der nicht oeffentlich zugaenglich sein sollte.

Das Konzept ist geradlinig: Sie listen die IP-Adressen oder CIDR-Bloecke auf, die erlaubt (oder verweigert) werden sollen, und nginx prueft jede eingehende Anfrage gegen die Liste. Das entscheidende Detail, an dem viele scheitern, ist die Auswertungsreihenfolge. Nginx verarbeitet allow- und deny-Direktiven von oben nach unten und stoppt beim ersten Treffer. Wenn deny all vor Ihren allow-Zeilen erscheint, wird jede Anfrage unabhaengig von der Quell-IP verweigert. Der Generator behandelt dies automatisch, indem er die Standardregel immer am Ende platziert, aber das Verstaendnis des Auswertungsmodells ist wichtig bei der Fehlersuche von Zugriffsproblemen.

Wo die nginx-Zugriffskontrolle komplex wird, ist bei mehrstufigen Konfigurationen. Direktiven in einem location-Block ueberschreiben die des umschliessenden server-Blocks, der wiederum die des http-Blocks ueberschreibt. Wenn Sie eine Allowlist in Ihrem Server-Block einrichten, aber vergessen, sie auf eine bestimmte Location anzuwenden, erbt diese Location, was der uebergeordnete Block definiert. Fuer komplexe Konfigurationen ist der sauberste Ansatz, Ihre Zugriffsregeln in einer separaten Datei abzulegen und sie ueberall dort einzubinden, wo sie benoetigt werden, was genau dem Workflow entspricht, den der Generator unterstuetzt.

So generieren Sie nginx-Allow/Deny-Direktiven

Geben Sie Ihre IP-Adressen oder CIDR-Bloecke ein -- einen pro Zeile oder kommagetrennt.
Waehlen Sie den Modus: Allowlist (aufgelistete IPs erlauben, alle anderen verweigern) oder Blocklist (aufgelistete IPs verweigern, alle anderen erlauben).
Der Generator formatiert jeden Eintrag als korrekte nginx-Direktive mit korrekter Syntax.
Kopieren Sie die Ausgabe in Ihren nginx-server-, location- oder http-Block, oder speichern Sie sie als Include-Datei.
Fuehren Sie nginx -t aus, um die Konfiguration zu testen, und laden Sie dann mit nginx -s reload neu.

Beispiele fuer nginx-Allow/Deny-Ausgaben

Allowlist-Modus

Eingabe:

192.168.1.0/24
10.0.0.0/8
203.0.113.50

Ausgabe:

allow 192.168.1.0/24;
allow 10.0.0.0/8;
allow 203.0.113.50;
deny all;

Blocklist-Modus

Eingabe:

198.51.100.0/24
203.0.113.0/24

Ausgabe:

deny 198.51.100.0/24;
deny 203.0.113.0/24;
allow all;

Verwendung einer Include-Datei

server {
    listen 443 ssl;
    server_name admin.example.com;

    include /etc/nginx/conf.d/admin-allowlist.conf;

    location / {
        proxy_pass http://backend;
    }
}

Wann den nginx-CIDR-Snippet-Generator verwenden

Admin-Panel-Schutz -- Zugriff auf /admin oder /wp-admin nur auf Buero- und VPN-IP-Bereiche beschraenken.
Staging-Server-Zugriffskontrolle -- Staging-Umgebungen auf IP-Adressen von Entwickler- und QA-Teams beschraenken.
API-Rate-Limiting nach IP -- In Kombination mit limit_req_zone hoehere Limits fuer bekannte Partner-IPs erlauben, waehrend unbekannte Quellen eingeschraenkt werden.
Geografisches Blockieren -- Ganze laenderweite CIDR-Bereiche vom Zugriff auf bestimmte Ressourcen blockieren.
Compliance-Anforderungen -- Zugriff auf sensible Datenendpunkte auf genehmigte Unternehmensnetzwerk-Bereiche beschraenken.

Wie nginx-Zugriffskontroll-Direktiven funktionieren

Regel-Verarbeitungsreihenfolge

Nginx wertet allow- und deny-Direktiven in Reihenfolge von oben nach unten aus. Die erste passende Regel gewinnt. Das bedeutet:

# Dies FUNKTIONIERT -- spezifisches Allow vor allgemeinem Deny
allow 192.168.1.0/24;
deny all;

# Dies FUNKTIONIERT NICHT -- deny all wird zuerst ausgewertet
deny all;
allow 192.168.1.0/24;   # wird nie erreicht

Der Generator platziert die Standardregel (deny all oder allow all) immer am Ende, um eine korrekte Auswertung sicherzustellen.

Direktiven-Geltungsbereich

Zugriffskontroll-Direktiven koennen auf verschiedenen Ebenen platziert werden:

http-Block -- Gilt fuer alle virtuellen Hosts
server-Block -- Gilt fuer einen bestimmten virtuellen Host
location-Block -- Gilt fuer einen bestimmten URL-Pfad

location /api/internal {
    allow 10.0.0.0/8;
    deny all;

    proxy_pass http://internal-api;
}

IPv6-Unterstuetzung

Der Generator verarbeitet IPv6-Adressen und CIDR-Bloecke mit derselben Syntax:

allow 2001:db8::/32;
allow 192.168.1.0/24;
deny all;

Kombination mit Proxy-Headern

Wenn nginx hinter einem Load Balancer oder CDN steht, kommt die Client-IP aus einem Header wie X-Forwarded-For statt aus der TCP-Verbindung. In diesem Fall verwenden Sie das ngx_http_realip_module, um die echte Client-IP vor der Zugriffskontroll-Auswertung festzulegen:

set_real_ip_from 10.0.0.0/8;       # Ihrem Load-Balancer-Bereich vertrauen
real_ip_header X-Forwarded-For;
real_ip_recursive on;

allow 203.0.113.0/24;              # Basierend auf echter Client-IP erlauben
deny all;

Praktische Hinweise zur nginx-Zugriffskontrolle

Der haeufigste Fehler bei der nginx-Zugriffskontrolle ist, die Konfiguration nicht vor dem Neuladen zu testen. Ein fehlendes Semikolon, ein ungueltiger CIDR-Block oder auch nur ein verirrtes Zeichen fuehren dazu, dass nginx -t fehlschlaegt, und wenn Sie ohne Test neuladen, bleibt die alte Konfiguration aktiv -- aber beim naechsten Neustart von nginx (z.B. nach einem Server-Reboot) weigert sich der Dienst vollstaendig zu starten, weil die ungueltige Konfiguration auf der Festplatte liegt. Fuehren Sie immer nginx -t vor nginx -s reload aus, und erwaegen Sie, diese Pruefung als automatisierten Gate in Ihre Deployment-Skripte aufzunehmen.

Beim Schutz von Admin-Panels verlassen Sie sich nicht allein auf IP-basierte Zugriffskontrolle. Verwenden Sie sie als eine Schicht in einem Defense-in-Depth-Ansatz: IP-Allowlisting, um einzuschraenken, wer ueberhaupt die Login-Seite erreichen kann, starke Authentifizierung dahinter und Rate-Limiting, um Brute-Force-Angriffe von erlaubten IPs zu verhindern. IP-Adressen koennen auf Anwendungsebene gefaelscht werden (ueber gefaelschte Header), stellen Sie also sicher, dass Sie real_ip_header korrekt konfigurieren, wenn Sie hinter einem Reverse-Proxy stehen, und vertrauen Sie X-Forwarded-For niemals direkt, ohne den unmittelbaren Upstream zu validieren.

Fuer grosse Allowlists (Hunderte von Eintraegen) erwaegen Sie die Verwendung des geo-Moduls anstelle einzelner allow/deny-Direktiven. Das geo-Modul verwendet intern einen binaeren Suchbaum, der schneller ist als der lineare Scan von allow/deny fuer grosse Listen. Der Kompromiss ist eine etwas komplexere Konfiguration, aber fuer Listen mit mehr als 50-100 Eintraegen ist der Leistungsunterschied auf Servern mit hohem Datenverkehr messbar.

Haeufig gestellte Fragen

Warum startet nginx nach dem Hinzufuegen von Allow/Deny-Regeln nicht? Die haeufigste Ursache ist ein fehlendes Semikolon am Ende einer Direktivenzeile. Jede allow- und deny-Zeile muss mit ; enden. Der Generator behandelt dies automatisch. Fuehren Sie nginx -t aus, um die Syntax vor dem Neuladen zu pruefen.

Kann ich Allow- und Deny-Direktiven in einem einzigen Block mischen? Ja, aber die Reihenfolge ist entscheidend. Nginx verarbeitet Regeln von oben nach unten und stoppt beim ersten Treffer. Typischerweise erlauben Sie entweder eine Menge von IPs und verweigern alle anderen, oder verweigern eine Menge und erlauben alle anderen. Das Mischen von Allow und Deny fuer verschiedene IP-Bereiche im selben Block ist gueltig, aber schwieriger zu warten.

Was ist der Unterschied zwischen deny all und return 403? deny all ist eine Zugriffskontroll-Direktive, die eine 403-Forbidden-Antwort zurueckgibt. return 403 ist eine Content-Direktive, die ebenfalls 403 zurueckgibt, aber nicht an der Allow/Deny-Auswertungskette teilnimmt. Fuer IP-basierte Zugriffskontrolle verwenden Sie immer allow/deny-Direktiven.

Wie binde ich das generierte Snippet in meine nginx-Konfiguration ein? Speichern Sie die Ausgabe in einer Datei wie /etc/nginx/conf.d/allowlist.conf und verwenden Sie die include-Direktive in Ihrem Server- oder Location-Block: include /etc/nginx/conf.d/allowlist.conf;

Was ist, wenn mein nginx hinter einem CDN oder Load Balancer steht? Sie muessen das ngx_http_realip_module konfigurieren, um die echte Client-IP aus dem entsprechenden Header zu extrahieren (ueblicherweise X-Forwarded-For oder X-Real-IP). Ohne dies sieht nginx fuer jede Anfrage die IP des CDN oder Load Balancers, und Ihre Allowlist greift auf die falsche Adresse zu.

Gibt es ein Limit fuer die Anzahl der Allow/Deny-Regeln, die nginx verarbeiten kann? Es gibt kein festes Limit, aber die Leistung nimmt linear mit der Anzahl der Regeln ab, da nginx sie sequentiell durchsucht. Fuer Listen mit mehr als 100 Eintraegen erwaegen Sie die Verwendung des geo-Moduls oder der map-Direktive fuer bessere Leistung. Fuer die meisten Konfigurationen mit weniger als 50 Regeln ist die Auswirkung auf die Leistung vernachlaessigbar.