악용 및 인증 실패 차단

요청 속도를 늦추는 대신 클라이언트를 일정 기간 차단하는 GitLab의 보호 기능과 Rack Attack 문제 해결 방법을 설명합니다.

일부 보호 기능은 요청 속도를 늦추는 대신 일정 기간 클라이언트를 차단합니다. Git 및 컨테이너 레지스트리의 인증 실패 차단 # 단일 IP 주소에서 3분 동안 30개의 인증 실패 요청을 받으면 GitLab은 1시간 동안 HTTP 상태 코드 403 을 반환합니다. 이는 다음의 조합에만 적용됩니다: Git 요청. 컨테이너 레지스트리( /jwt/auth ) 요청. 이 제한: 성공적으로 인증하는 요청으로 초기화됩니다. 예를 들어, 29번의 인증 실패 요청 다음에 1번의 성공적인 요청, 그 다음 29번의 인증 실패 요청은 차단을 트리거하지 않습니다. 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 를 열어야 합니다: /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket 다음 구문을 사용하여 차단을 제거할 수 있으며, <ip> 를 차단 목록에 있는 실제 IP로 교체하세요: del cache:gitlab:rack::attack:allow2ban:ban:<ip> IP가 있는 키가 더 이상 표시되지 않는지 확인하세요: keys *rack::attack* 기본적으로 keys 명령은 비활성화 됩니다. 선택적으로 IP를 허용 목록에 추가 하여 다시 차단 목록에 추가되는 것을 방지하세요.