어뷰징 및 인증 실패 차단

반복된 인증 실패 요청 후 클라이언트를 차단하는 밴을 설명합니다.

일부 보호 기능은 요청 속도를 늦추는 대신 일정 시간 동안 클라이언트를 차단합니다. 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 이 로드 밸런서를 차단할 수 있습니다. 이 경우 다음을 수행해야 합니다. nginx[real_ip_trusted_addresses] 를 구성합니다 . 이렇게 하면 사용자의 IP가 로드 밸런서 IP로 표시되지 않습니다. 로드 밸런서의 IP 주소를 허용 목록에 추가합니다. GitLab을 재구성합니다. sudo gitlab-ctl reconfigure Redis로 Rack Attack에서 차단된 IP 제거 # 차단된 IP를 제거하려면 다음과 같이 합니다. 프로덕션 로그에서 차단된 IP를 찾습니다. grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log 거부 목록은 속도 제한용 Redis 인스턴스에 저장되므로, 이 인스턴스에 대해 redis-cli 를 열어야 합니다. 인스턴스를 분리하지 않은 설치 환경에서는 기본 Redis가 이에 해당합니다. /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket gitlab_rails['redis_rate_limiting_instance'] 를 구성한 경우에는 대신 해당 인스턴스에 연결합니다. 잘못된 인스턴스에서 키를 삭제하면 성공한 것처럼 보이지만 밴은 그대로 남습니다. 다음 구문에서 <ip> 를 거부 목록에 등록된 실제 IP로 바꿔 차단을 제거할 수 있습니다. del cache:gitlab:rack::atta