☰

Wie kann man die Anzahl der erneuten Versuche von Nginx Auth_Basic begrenzen?

tag-icon • tag-icon security nginx
Wie kann man die Anzahl der erneuten Versuche von Nginx Auth_Basic begrenzen?

Ich habe einen Webordner mit dem Auth_Basic-Modul von Nginx geschützt. Das Problem ist, dass wir mehrere Passwörter ausprobieren können, bis es funktioniert (Brute-Force-Angriffe). Gibt es eine Möglichkeit, die Anzahl der fehlgeschlagenen Wiederholungsversuche zu begrenzen?

Antwort1

Soweit ich weiß,Authentifizierung BasicModul unterstützt diese Funktion nicht, aber Sie können dies tun, indem SieFail2ban.

Wenn Sie den Test mit einem nicht vorhandenen Benutzer durchführen, wird im Fehlerprotokoll etwa Folgendes angezeigt:

2012/08/25 10:07:01 [error] 5866#0: *1 no user/password was provided for basic authentication, client: 127.0.0.1, server: localhost, request: "GET /pma HTTP/1.1", host: "localhost:81" 2012/08/25 10:07:04 [error] 5866#0: *1 user "ajfkla" was not found in "/etc/nginx/htpasswd", client: 127.0.0.1, server: localhost, request: "GET /pma HTTP/1.1", host: "localhost:81"

Erstellen Sie dann den erforderlichen Filter:

/etc/fail2ban/filter.d/nginx-auth.conf

[Definition]
failregex = no user/password was provided for basic authentication.*client: <HOST>
              user .* was not found in.*client: <HOST>
              user .* password mismatch.*client: <HOST>
ignoreregex = </host></host></host>

/etc/fail2ban/jail.conf

[nginx-auth]
enabled = true
filter = nginx-auth
action = iptables[name=NoAuthFailures, port=80, protocol=tcp]
logpath = /var/log/nginx*/*error*.log
bantime = 3600 # 1 hour
maxretry = 3

Testen der Fail2Ban-Regeln:

fail2ban-regex /var/log/nginx/localhost.error_log /etc/fail2ban/filter.d/nginx-auth.conf

Failregex
|- Regular expressions:
|  [1] no user/password was provided for basic authentication.*client: <HOST>
|  [2] user .* was not found in.*client: <HOST>
|  [3] user .* password mismatch.*client: <HOST>
|
`- Number of matches:
   [1] 1 match(es)
   [2] 2 match(es)
   [3] 0 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    127.0.0.1 (Sat Aug 25 10:07:01 2012)
[2]
    127.0.0.1 (Sat Aug 25 10:07:04 2012)
    127.0.0.1 (Sat Aug 25 10:07:07 2012)
[3]

PS: Da Fail2ban zum Sperren Protokolldateien abruft, stellen Sie sicher, dass logpathdiese mit Ihrer Konfiguration übereinstimmen.

Antwort2

Ich bin erstaunt, dass niemand sonst diese Lösung/Umgehung angeboten hat.

Nginx Basic-Auth und htpasswdunterstützt die bcrypt-Passwortverschlüsselung mit einer optionalen Kostenvariable. bcrypt ist auf Langsamkeit ausgelegt und bietet daher eine harte Grenze dafür, wie schnell Sie verschiedene Passwörter ausprobieren können.

Verwenden Sie bei der Erstellung Ihres grundlegenden Authentifizierungsbenutzernamens/Passworts

htpasswd -B -C 12 path/to/users.db <username>

Bei Kosten von 12 kann Ihr Server Passwörter wahrscheinlich nicht öfter als ein paar Mal pro Sekunde ausprobieren. Erhöhen Sie diesen Wert beispielsweise auf 14, liegt Ihr Wert wahrscheinlich bei etwa 1 Sekunde pro Passwortversuch.

Mit dieser Konfiguration ist jedes vernünftige Passwort gegen Brute-Force-Angriffe immun, selbst wenn der Angreifer die Passwörter jahrelang immer wieder ausprobiert.

Bei 10 Passwortversuchen pro Sekunde würde beispielsweise ein Brute-Force-Angriff auf ein 8-stelliges alphanumerisches Passwort 692.351 Jahre dauern: 62**8 / (10*3600*24*365).

Dies ist viel einfacher zu konfigurieren und narrensicherer als die Einrichtung einer „intelligenten“ Anforderungsbegrenzung.

Antwort3

Ich glaube nicht, dass Nginx über eine interne Einrichtung verfügt, um dies zu tun.Dokumentationsseitelässt nicht darauf schließen, dass es möglich ist.

Mit Fail2Ban können Sie IP-Adressen blockieren, bei denen die Anmeldeversuche wiederholt fehlgeschlagen sind.

Das Fail2Ban Wiki hat einigenginx-spezifische Muster.

Fail2Ban sollte auf den meisten großen Distributionen als Paket verfügbar sein.

Antwort4

Dies kann mit einer Kombination aus NGINX-Basisauthentifizierung und Ratenbegrenzung erreicht werden.

http {
    map $http_cookie $rate_limit_key {
        default $binary_remote_addr;
        "~__Secure-rl-bypass=SomeRandomBytes" "";
    }
    limit_req_status 429;
    limit_req_zone $rate_limit_key zone=auth:10m rate=1r/m;

    server {
            auth_basic "Private Content";
            auth_basic_user_file your-auth-file.txt;

            limit_req zone=auth burst=20 delay=10;

            add_header Set-Cookie "__Secure-rl-bypass=SomeRandomBytes;Max-Age=${toString (3600*24*180)};Domain=$host;Path=/;Secure;HttpOnly";
    }
}

Dieses Snippet wurde aus meiner Arbeitskonfiguration extrahiert, aber das Snippet selbst wurde nicht getestet.

Das Grundkonzept besteht darin, dass Sie ein Cookie erstellen, mit dem die Ratenbegrenzung umgangen werden kann. Anschließend setzen Sie das Cookie, sobald sich jemand erfolgreich authentifiziert hat. Auf diese Weise unterliegt die Rate einer Person einer Begrenzung, bis sie sich anmeldet. Ab diesem Zeitpunkt kann sie so viele Anfragen stellen, wie sie möchte.

Der größte Nachteil dieses Ansatzes ist, dass das Cookie statisch ist. Sobald jemand mit einem beliebigen Konto angemeldet ist, kann er das Token verwenden, um andere Konten mit Brute Force zu knacken. Dies ist kein großes Problem, wenn Ihren Benutzern vertraut wird, dass sie das Passwort anderer Benutzer nicht mit Brute Force knacken. Ich glaube jedoch nicht, dass Sie in der NGINX-Konfiguration mehr erreichen können. Idealerweise wäre das Cookie hash("$remote_user-SomeRandomBytes")so, dass das Token an den Benutzer gebunden ist, der sich erfolgreich angemeldet hat.

verwandte Informationen