☰

Nginx Auth_Basic 재시도를 제한하는 방법은 무엇입니까?

tag-icon • tag-icon security nginx
Nginx Auth_Basic 재시도를 제한하는 방법은 무엇입니까?

Nginx의 Auth_Basic 모듈을 사용하여 웹 폴더를 보호했습니다. 문제는 작동할 때까지 여러 암호를 시도할 수 있다는 것입니다(무차별 대입 공격). 재시도 실패 횟수를 제한하는 방법이 있나요?

답변1

내가 아는 한,인증 기본모듈은 이 기능을 지원하지 않지만 다음을 사용하여 이 기능을 수행할 수 있습니다.Fail2ban.

존재하지 않는 사용자로 테스트하면 오류 로그에 다음과 같은 내용이 표시됩니다.

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"

그런 다음 필요한 필터를 만듭니다.

/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

Fail2Ban 규칙 테스트:

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]

logpath추신: Fail2ban은 금지할 로그 파일을 가져오므로 구성과 일치하는지 확인하십시오 .

답변2

다른 누구도 이 솔루션/해결 방법을 제공하지 않았다는 사실에 놀랐습니다.

Nginx 기본 인증 및 htpasswd선택적 비용 변수를 사용하여 bcrypt 비밀번호 암호화를 지원합니다. Bcrypt는 느리게 설계되었으므로 다양한 비밀번호를 시도할 수 있는 속도에 대한 엄격한 제한을 제공합니다.

기본 인증 사용자 이름/비밀번호를 생성할 때 사용

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

12의 비용을 사용하면 서버는 초당 몇 번 이상 비밀번호를 시도할 수 없을 가능성이 높으며 이를 14로 늘리면 비밀번호 시도당 약 1초를 보게 될 것입니다.

이렇게 구성하면 공격자가 수년간 지속적으로 비밀번호를 시도하더라도 합리적인 비밀번호는 무차별 대입 공격으로부터 면역됩니다.

예를 들어 초당 10번의 비밀번호 시도에서 8자리 영숫자 비밀번호에 대한 무차별 대입 공격은 692,351년이 걸립니다 62**8 / (10*3600*24*365).

이는 "지능형" 요청 제한을 설정하는 것보다 구성하기가 훨씬 쉽고 더 확실합니다.

답변3

나는 nginx에 이 작업을 수행할 수 있는 내부 시설이 없다고 생각합니다. 그만큼문서 페이지가능하다고는 하지 않습니다.

Fail2Ban을 사용하면 로그인 시도가 반복적으로 실패한 IP 주소를 차단할 수 있습니다.

Fail2Ban 위키에는 다음이 있습니다.nginx 관련 패턴.

Fail2Ban은 대부분의 대형 배포판에서 패키지로 제공됩니다.

답변4

이는 NGINX 기본 인증과 속도 제한을 조합하여 수행할 수 있습니다.

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";
    }
}

이 조각은 내 작업 구성에서 추출되었지만 조각 자체는 테스트되지 않았습니다.

기본 개념은 비율 제한을 우회할 수 있는 쿠키를 만든 다음 누군가가 성공적으로 인증하면 쿠키를 설정하는 것입니다. 이렇게 하면 누군가가 로그인하여 원하는 만큼 많은 요청을 수행할 수 있을 때까지 속도가 제한됩니다.

이 접근 방식의 주요 단점은 쿠키가 정적이라는 것입니다. 누군가가 어떤 계정에 로그인하면 토큰을 사용하여 다른 계정에 무차별 공격을 가할 수 있습니다. 사용자가 다른 사용자의 비밀번호를 무차별 대입하지 않을 것으로 신뢰하는 경우 이는 큰 문제가 아닙니다. 그러나 나는 NGINX의 구성에서 이보다 더 나은 작업을 수행할 수 없다고 생각합니다. 이상적으로 쿠키는 hash("$remote_user-SomeRandomBytes")성공적으로 로그인한 사용자에게 토큰이 바인딩되도록 하는 것입니다.

관련 정보