일부 보호 기능은 요청 속도를 늦추는 대신 일정 기간 클라이언트를 차단합니다.

Git 및 컨테이너 레지스트리의 인증 실패 차단#

단일 IP 주소에서 3분 동안 30개의 인증 실패 요청을 받으면 GitLab은 1시간 동안 HTTP 상태 코드 403을 반환합니다. 이는 다음의 조합에만 적용됩니다:

• Git 요청.

• 컨테이너 레지스트리(/jwt/auth) 요청.

이 제한:

• 성공적으로 인증하는 요청으로 초기화됩니다. 예를 들어, 29번의 인증 실패 요청 다음에 1번의 성공적인 요청, 그 다음 29번의 인증 실패 요청은 차단을 트리거하지 않습니다.

• gitlab-ci-token으로 인증된 JWT 요청에는 적용되지 않습니다.

• 기본적으로 비활성화됩니다.

응답 헤더는 제공되지 않습니다.

속도 제한을 피하기 위해 다음을 수행할 수 있습니다:

• 자동화된 파이프라인 실행을 분산하세요.

• 인증 실패 시도에 대해 지수 백오프 및 재시도를 구성하세요.

• 토큰 만료를 관리하기 위해 문서화된 프로세스와 모범 사례를 사용하세요.

구성 정보는 Linux 패키지 구성 옵션을 참조하세요.

문제 해결#

Rack Attack이 로드 밸런서를 차단 목록에 추가함#

모든 트래픽이 로드 밸런서에서 오는 것처럼 보이면 Rack Attack이 로드 밸런서를 차단할 수 있습니다. 이 경우 다음을 수행해야 합니다:

1. nginx[real_ip_trusted_addresses]를 구성하세요. 이렇게 하면 사용자의 IP가 로드 밸런서 IP로 나열되지 않습니다.

2. 로드 밸런서의 IP 주소를 허용 목록에 추가하세요.

3. GitLab을 재구성하세요:

   sudo gitlab-ctl reconfigure
   

Redis를 사용하여 Rack Attack에서 차단된 IP 제거#

차단된 IP를 제거하려면:

1. 프로덕션 로그에서 차단된 IP를 찾으세요:

   grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
   

2. 차단 목록은 Redis에 저장되므로 redis-cli를 열어야 합니다:

   /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
   

3. 다음 구문을 사용하여 차단을 제거할 수 있으며, <ip>를 차단 목록에 있는 실제 IP로 교체하세요:

   del cache:gitlab:rack::attack:allow2ban:ban:<ip>
   

4. IP가 있는 키가 더 이상 표시되지 않는지 확인하세요:

   keys *rack::attack*
   

   기본적으로 keys 명령은 비활성화됩니다.

5. 선택적으로 IP를 허용 목록에 추가하여 다시 차단 목록에 추가되는 것을 방지하세요.