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

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

기본적으로 GitLab은 단일 IP 주소에서 1분 동안 10회의 인증 실패 요청을 받으면 1시간 동안 HTTP 상태 코드 403을 반환합니다. 세 값 모두 구성 가능합니다. 이는 다음을 합산한 경우에만 적용됩니다.

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

이 제한은 다음과 같습니다.

• 밴이 시작되기 전까지는 인증에 성공한 요청에 의해 재설정됩니다. 예를 들어 인증 실패 요청 9회 후 성공 요청 1회, 이후 다시 인증 실패 요청 9회가 발생해도 밴이 트리거되지 않습니다.
• 밴이 시작된 이후에는 인증에 성공해도 해제되지 않습니다. 밴은 자격 증명보다 먼저 확인되므로, 차단된 IP는 밴이 만료될 때까지 유효한 자격 증명으로도 403을 받습니다.
• 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를 열어야 합니다. 인스턴스를 분리하지 않은 설치 환경에서는 기본 Redis가 이에 해당합니다.

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

   gitlab_rails['redis_rate_limiting_instance']를 구성한 경우에는 대신 해당 인스턴스에 연결합니다. 잘못된 인스턴스에서 키를 삭제하면 성공한 것처럼 보이지만 밴은 그대로 남습니다.

3. 다음 구문에서 <ip>를 거부 목록에 등록된 실제 IP로 바꿔 차단을 제거할 수 있습니다.

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

4. 해당 IP를 가진 키가 더 이상 표시되지 않는지 확인합니다.

   keys *rack::attack*
   

   기본적으로 keys 명령은 비활성화되어 있습니다.

5. 선택적으로 IP를 허용 목록에 추가하여 다시 거부 목록에 등록되지 않도록 합니다.