Implementierung der Nginx-Flusskontrolle und Zugriffskontrolle

Nginx-Verkehrskontrolle

Die Ratenbegrenzung ist eine sehr nützliche, aber häufig missverstandene und falsch konfigurierte Funktion in Nginx. Wir können es verwenden, um die Anzahl der HTTP-Anfragen zu begrenzen, die ein Benutzer in einer bestimmten Zeit stellen kann. Die Anfrage kann eine GET-Anfrage für eine einfache Website-Homepage oder eine POST-Anfrage für ein Anmeldeformular sein. Die Ratenbegrenzung kann aus Sicherheitsgründen verwendet werden, beispielsweise um die Rate des Knackens von Passwörtern mit Brute-Force-Methoden zu verringern. Es kann auch zum Schutz vor DDOS-Angriffen verwendet werden, indem die Rate eingehender Anfragen auf einen für echte Benutzer typischen Wert begrenzt und die Ziel-URL-Adressen (über Protokolle) identifiziert werden. Häufiger wird diese Funktion verwendet, um vorgelagerte Anwendungsserver vor einer Überlastung durch zu viele gleichzeitige Benutzeranforderungen zu schützen.

Im Folgenden werden die Grundlagen und die erweiterte Konfiguration der Nginx-Verkehrsbegrenzung vorgestellt. „Verkehrsbegrenzung“ gilt auch für Nginx Plus.

1. So begrenzen Sie den Fluss von Nginx

Das „Flow Limit“ von Nginx verwendet den Leaky-Bucket-Algorithmus, der in Kommunikations- und Paketvermittlungs-Computernetzwerken häufig verwendet wird, um Notfälle zu bewältigen, wenn die Bandbreite begrenzt ist. Es ist wie bei einem Eimer, aus dessen Öffnung Wasser läuft, das aber unten ausläuft. Wenn die Geschwindigkeit, mit der Wasser aus dem Eimer gegossen wird, größer ist als die Geschwindigkeit, mit der Wasser aus dem Boden des Eimers austritt, läuft das Wasser im Eimer über. In ähnlicher Weise stellt Wasser in Bezug auf die Anforderungsverarbeitung Anforderungen vom Client dar und der Eimer stellt eine Warteschlange von Anforderungen dar, die darauf warten, gemäß dem „First-In-First-Out-Planungsalgorithmus“ (FIFO) verarbeitet zu werden. Wasser, das aus dem Boden des Eimers austritt, stellt Anforderungen dar, die den Puffer verlassen und vom Server verarbeitet werden, und Wasser, das aus dem Eimer überläuft, stellt Anforderungen dar, die verworfen und nicht verarbeitet werden.

2. Grundlegende Strombegrenzung konfigurieren

Die Konfiguration „Verkehrslimit“ hat zwei Hauptanweisungen, limit_req_zone und limit_req , wie unten gezeigt:

192.168.62.155-Konfiguration:
limit_req_zone $binary_remote_addr Zone=meinLimit:10m Rate=1r/s;
Upstream meinWeb {
    Server 192.168.62.157:80 Gewicht=1 max_fails=1 fail_timeout=1;
    }
Server {
    hören Sie 80;
    Servername localhost;

    Standort /Anmeldung {
        limit_req zone=meinlimit;
        Proxy-Passwort http://meinWeb;
        Proxy_set_header Host $host:$server_port;
        Proxy_Set_Header X-Real-IP $Remote_Addr;
        proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
        }
}

192.168.62.157-Konfiguration:
Server {
    hören Sie 80;
    Servername localhost;
    Standort /Anmeldung {
        root /usr/share/nginx/html;
        Index Index.html Index.html;
        }
}

Nach zweimaligem Klicken

Die Direktive limit_req_zone definiert die Parameter für die Ratenbegrenzung, während limit_req die Ratenbegrenzung in dem Kontext aktiviert, in dem sie auftritt (in diesem Fall für alle Anfragen an „/login/“).

Die Direktive limit_req_zone wird normalerweise im HTTP-Block definiert, sodass sie in mehreren Kontexten verwendet werden kann. Sie erfordert die folgenden drei Parameter:

• Schlüssel – Das Anforderungsattribut, das die angewendete Einschränkung definiert. Die Nginx-Variable $binary_remote_addr speichert im Beispiel die Binärform der Client-IP-Adresse. Das bedeutet, dass wir jede unterschiedliche IP-Adresse auf die durch den dritten Parameter festgelegte Anforderungsrate beschränken können. (Diese Variable wird verwendet, da sie weniger Platz beansprucht als die Zeichenfolgenform der Client-IP-Adresse $remote_addr )
• Zone – definiert eine gemeinsam genutzte Speicherzone, in der der Status jeder IP-Adresse und die Zugriffshäufigkeit auf die angeforderten, eingeschränkten URLs gespeichert werden. Die im gemeinsam genutzten Speicherbereich gespeicherten Informationen sind für die gemeinsame Nutzung zwischen Nginx-Arbeitsprozessen vorgesehen. Die Definition besteht aus zwei Teilen: dem Namen der Zone, die durch zone=keyword identifiziert wird, und einem Doppelpunkt, gefolgt von der Zonengröße. Die Statusinformationen von 16.000 IP-Adressen erfordern etwa 1 MB, sodass der Bereich im Beispiel 160.000 IP-Adressen speichern kann.
• Rate – Definiert die maximale Anforderungsrate. Im Beispiel kann die Rate 1 Anfrage pro Sekunde nicht überschreiten. Nginx verfolgt Anfragen tatsächlich mit einer Genauigkeit von Millisekunden, sodass die Ratenbegrenzung einer Anfrage alle 1000 Millisekunden entspricht. Da „Bursting“ nicht zulässig ist (siehe nächster Abschnitt), bedeutet dies, dass Anfragen, die innerhalb von 1000 Millisekunden nach einer vorherigen Anfrage eintreffen, abgelehnt werden.

limit_req_zone legt das Verkehrslimit und die Parameter der gemeinsam genutzten Speicherzone fest, begrenzt jedoch nicht tatsächlich die Anforderungsrate. Sie müssen also hinzufügen

Die Direktive limit_req wendet Verkehrsbeschränkungen auf einen bestimmten location oder server an. Im obigen Beispiel begrenzen wir den Fluss der /login/ -Anfragen.

Jede IP-Adresse ist nun auf eine Anfrage an /login/ pro Sekunde beschränkt, oder genauer gesagt, sie kann diese URL nicht innerhalb von 1000 Millisekunden nach der vorherigen Anfrage anfordern.

3. Umgang mit Notfällen

Was passiert, wenn wir innerhalb von 1000 Millisekunden 2 Anfragen erhalten? Bei der zweiten Anfrage gibt Nginx einen Fehler an den Client zurück. Dies ist möglicherweise nicht das, was wir wollen, da Anwendungen naturgemäß dazu neigen, stoßweise auszuführen. Vielmehr wollen wir überzählige Anfragen zwischenspeichern und dann zeitnah abarbeiten. Aktualisieren wir die Konfiguration und verwenden den burst -Parameter in limit_req :

limit_req_zone $binary_remote_addr Zone=meinLimit:10m Rate=10r/s;
    Upstream meinWeb {
        Server 192.168.62.157:80 Gewicht=1 max_fails=1 fail_timeout=1;
        }
       
    Server {
        hören Sie 80;
        Servername localhost;
        Standort /Anmeldung {
            limit_req Zone=meinLimit Burst=20;
            Proxy-Passwort http://meinWeb;
            Proxy_set_header Host $host:$server_port;
            Proxy_Set_Header X-Real-IP $Remote_Addr;
            proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
            }
    }

Der burst -Parameter definiert, wie viele Anfragen der Client über die von der Zone angegebene Rate hinaus stellen kann (in der Beispielzone mylimit ist die Rate auf 10 Anfragen pro Sekunde oder eine Anfrage alle 100 Millisekunden begrenzt). Anfragen, die innerhalb von 100 Millisekunden nach der vorherigen Anfrage eintreffen, werden in die Warteschlange gestellt und wir setzen die Warteschlangengröße auf 20.

Dies bedeutet, dass Nginx, wenn 21 Anfragen von einer bestimmten IP-Adresse gesendet werden, die erste Anfrage sofort an die vorgelagerte Serverfarm sendet und dann die verbleibenden 20 Anfragen in eine Warteschlange stellt. Anschließend leitet es alle 100 Millisekunden eine in die Warteschlange gestellte Anfrage weiter. Nur wenn eine eingehende Anfrage dazu führt, dass die Anzahl der in der Warteschlange befindlichen Anfragen 20 überschreitet, gibt Nginx einen Fehler an den Client zurück.

4. Konfigurieren Sie die Flusssteuerungsfunktionen

1. Protokollierung konfigurieren

Standardmäßig protokolliert Nginx Anfragen, die aufgrund einer Ratenbegrenzung verzögert oder gelöscht werden, wie unten gezeigt:

13.02.2019 04:20:00 [Fehler] 120315#0: *32086 Begrenzungsanforderungen, Überschuss: 1.000 durch Zone „mylimit“, Client: 192.168.1.2, Server: nginx.com, Anforderung: „GET / HTTP/1.0“, Host: „nginx.com“

Im Protokolleintrag enthaltene Felder:

• limiting requests - zeigt an, dass der Protokolleintrag für eine Anfrage ist, die "limited" ist
• Überschuss – die Anzahl der Anfragen pro Millisekunde, die die entsprechende „Ratenbegrenzung“-Konfiguration überschreiten
• Zone - definiert die Zone, in der die „Flussbegrenzung“ umgesetzt wird
• Client - die IP-Adresse des anfragenden Clients
• Server - Server-IP-Adresse oder Hostname
• Anfrage – die tatsächliche HTTP-Anfrage, die vom Client initiiert wird
• Host - der Wert des Hosts im HTTP-Header
  

Standardmäßig protokolliert Nginx abgelehnte Anfragen auf error , wie im obigen Beispiel in [error] gezeigt (Nginx protokolliert verzögerte Anfragen auf einer niedrigeren Ebene, normalerweise auf info ). Um die Protokollierungsebene von Nginx zu ändern, verwenden Sie die Direktive limit_req_log_level . Hier setzen wir die Protokollierungsebene für abgelehnte Anfragen auf warn :

Denken Sie daran, den Speicherort und die Ebene des Protokolls zu definieren:

limit_req_zone $binary_remote_addr Zone=meinLimit:10m Rate=1r/s;
    Upstream meinWeb {
        Server 192.168.62.157:80 Gewicht=1 max_fails=1 fail_timeout=1;
        }
    Server {
        hören Sie 80;
        Servername localhost;

        Standort /Anmeldung {
            limit_req Zone=meinLimit Burst=20;
            limit_req_log_level warnen;
            Proxy-Passwort http://meinWeb;
            Proxy_set_header Host $host:$server_port;
            Proxy_Set_Header X-Real-IP $Remote_Addr;
            proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
            }
    }

Greifen Sie weiterhin auf den Test zu und sehen Sie sich das Protokoll error.log an.

2. An den Client gesendeter Fehlercode

Wenn der Client das konfigurierte Verkehrslimit überschreitet, antwortet Nginx normalerweise mit dem Statuscode 503 (Dienst vorübergehend nicht verfügbar). Sie können die Direktive limit_req_status verwenden, um andere Statuscodes festzulegen (wie etwa den folgenden Statuscode 404):

limit_req_zone $binary_remote_addr Zone=meinLimit:10m Rate=10r/s;
	Upstream meinWeb {
    	Server 192.168.62.157:80 Gewicht=1 max_fails=1 fail_timeout=1;
		}
	Server {
    	hören Sie 80;
    	Servername localhost;
		
    	Standort /Anmeldung {
			limit_req zone=meinlimit;
			limit_req_log_level warnen;
			limit_req_status 404;
        	Proxy-Passwort http://meinWeb;
          Proxy_set_header Host $host:$server_port;
	      	Proxy_Set_Header X-Real-IP $Remote_Addr;
      		proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
        	}
	}

5. Zusammenfassung der Nginx-Verkehrskontrolle

Hier wurden viele der Funktionen der von Nginx und Nginx Plus bereitgestellten Funktion „Ratenbegrenzung“ abgedeckt, darunter das Festlegen von Anforderungsraten für verschiedene Standorte von HTTP-Anforderungen und das Konfigurieren burst -Parametern für die „Ratenbegrenzung“.

Nginx-Zugriffskontrolle

1. Nginx-Zugriffskontrollmodul

(1) IP-basierte Zugriffskontrolle: http_access_module
(2) Anmeldung basierend auf Benutzervertrauen: http_auth_basic_module

2. IP-basierte Zugriffskontrolle

1. Konfigurationssyntax

Syntax: Adresse zulassen | CIDR | Unix: | alle;
Standardmäßig: Nein. Kontext standardmäßig: http, Server, Standort.

Syntax: Adresse verweigern | CIDR | unix: | alle;
Standardmäßig: Nein. Kontext standardmäßig: http, Server, Standort.

2. Ändern Sie den Inhalt von /etc/nginx/conf.d/access_mod.conf wie folgt:

Server {
    hören Sie 80;
    Servername localhost;
    Standort ~ ^/admin {
        Stammverzeichnis /home/www/html;
        Index Index.html Index.hml;
        192.168.1.8 verweigern;
        alles erlauben;
        #deny 192.168.1.8;
        }
}
#Notiz:
Wenn Sie zuerst den Zugriff erlauben, legen Sie fest, wie der Zugriff verweigert werden soll. Dann ist die Zugangssperre wirkungslos.

Die Host-IP der virtuellen Maschine ist 192.168.1.8 und die IP der virtuellen Maschine ist 192.168.1.11 . Daher ist der Host-Maschine der Zugriff hier untersagt und allen anderen IPs ist der Zugriff gestattet.
Der Hostcomputer greift http://192.168.1.11/admin zu und zeigt die 403 Forbidden an.
Natürlich ist auch die umgekehrte Konfiguration möglich und es kann auch die IP-Segmentkonfigurationsmethode verwendet werden, z. B. allow 192.168.1.0/24; was bedeutet, dass alle IPs, die diesem Segment entsprechen, darauf zugreifen können.

3. Geben Sie den Standort an, um alle Anfragen abzulehnen

Wenn Sie alle Anfragen an eine bestimmte URL-Adresse ablehnen möchten, anstatt nur die Rate zu begrenzen, konfigurieren Sie einfach deny “ im location :

Server {
    hören Sie 80;
    Servername localhost;
    Standort /foo.html {
        Stammverzeichnis /home/www/html;
        alles leugnen;
        }
}

3. Anmeldung basierend auf Benutzervertrauen

1. Konfigurationssyntax

Syntax: auth_basic string | aus;
Standard: auth_basic aus;
Kontext: http, Server, Standort, limit_except

Syntax: auth_basic_user_file Datei;
Standardmäßig: Kein Kontext, standardmäßig: http, Server, Standort, limit_except
Datei: Die Datei, in der Benutzernamen- und Kennwortinformationen gespeichert werden.

2. Konfigurationsbeispiel

Benennen Sie access_mod.conf in auth_mod.conf um und der Inhalt lautet wie folgt:

Server {
	hören Sie 80;
	Servername localhost;
	Standort ~ ^/admin {
		Stammverzeichnis /home/www/html;
		Index Index.html Index.hml;
		auth_basic "Auth-Zugriffstest!";
		auth_basic_Benutzerdatei /etc/nginx/auth_conf;
		}
}

auth_basic ist nicht off , die Funktion zur Anmeldeüberprüfung ist aktiviert auth_basic_user_file lädt die Konto- und Kennwortdatei.

3. Erstellen Sie eine Passwortdatei

[root@192 ~]# mkdir /home/www/html/admin -p
[root@192 ~]# vim /home/www/html/admin
hallo qf
[root@192 ~]# yum install -y httpd-tools #htpasswd ist ein Befehlstool für den Open Source-HTTP-Server Apache httpd, das zum Generieren einer Kennwortdatei für die grundlegende HTTP-Authentifizierung verwendet wird. [root@192 ~]# htpasswd -cm /etc/nginx/auth_conf user10 //Erstes Erstellen eines neuen Benutzers [root@192 ~]# htpasswd -m /etc/nginx/auth_conf user20 //Zweites Hinzufügen eines Benutzers [root@192 ~]# cat /etc/nginx/auth_conf
Benutzer10:$apr1$MOa9UVqF$RlYRMk7eprViEpNtDV0n40
Benutzer20:$apr1$biHJhW03$xboNUJgHME6yDd17gkQNb0

4. Zugangstest

5. Einschränkungen

(1) Benutzerinformationen basieren auf Dateien (2) Mechanischer Betrieb und Verwaltung, geringe Effizienz

Dies ist das Ende dieses Artikels über die Implementierung der Flusssteuerung und Zugriffskontrolle von Nginx. Weitere relevante Inhalte zur Flusssteuerung und Zugriffskontrolle von Nginx finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!