• 구성 가능한 제한
• Git 및 컨테이너 레지스트리에 대한 인증 실패 금지
• 구성할 수 없는 제한
  • 리포지터리 아카이브
  • 웹훅 테스팅
  • 사용자 가입
  • 사용자명 업데이트
  • 사용자명 존재
  • 프로젝트 작업 API 엔드포인트
  • AI 액션
  • API를 사용하여 멤버 삭제
• 문제 해결
  • Rack Attack이 로드 밸런서를 차단하는 문제
  • Redis를 사용하여 Rack Attack에서 차단된 IP 제거

요율 제한

요율 제한은 웹 애플리케이션의 보안과 내구성을 향상시키는 데 사용되는 일반적인 기술입니다.

예를 들어 간단한 스크립트가 초당 수천 개의 웹 요청을 만들 수 있습니다. 이러한 요청은 다음과 같을 수 있습니다:

• 악의적인 요청
• 무관심한 요청
• 단순한 버그

귀하의 응용 프로그램 및 인프라는 이러한 부하를 견딜 수 없을 수 있습니다. 자세한 내용은 서비스 거부 공격(Denial-of-service attack)을 참조하십시오. 대부분의 경우 단일 IP 주소로부터의 요청 속도를 제한함으로써 이러한 문제를 완화할 수 있습니다.

대부분의 무차별 대입 공격(brute-force attacks)은 비슷한 방식으로 요율 제한으로 완화됩니다.

구성 가능한 제한

귀하의 인스턴스의 관리자 영역에서 다음 요율 제한을 설정할 수 있습니다:

• 가져오기/내보내기 요율 제한
• 이슈 요율 제한
• 노트 요율 제한
• 보호된 경로
• 원시 엔드포인트 요율 제한
• 사용자 및 IP 요율 제한
• 패키지 레지스트리 요율 제한
• Git LFS 요율 제한
• Git SSH 작업의 요율 제한
• 파일 API 요율 제한
• 중지된 API 요율 제한
• GitLab Pages 요율 제한
• 파이프라인 요율 제한
• 사고 관리 요율 제한
• 인증되지 않은 프로젝트 디렉터리 API 요율 제한

다음 명령을 사용하여 이러한 요율 제한을 설정할 수 있습니다.:

• 웹훅 요율 제한

Git 및 컨테이너 레지스트리에 대한 인증 실패 금지

단일 IP 주소로부터 3분 동안 30번의 인증 실패 요청이 수신되면 GitLab은 1시간 동안 HTTP 상태 코드 403을 반환합니다. 이는 다음에만 적용됩니다.

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

이 제한은 다음과 같이 관리됩니다.

• 성공적으로 인증되는 요청에 의해 재설정됩니다. 예를 들어, 29번의 인증 실패 요청 후 1회의 성공적인 요청, 또 다시 29번의 인증 실패 요청이 발생하는 경우 금지가 트리거되지 않습니다.
• gitlab-ci-token에 의해 인증된 JWT 요청에는 적용되지 않습니다.
• 기본적으로 비활성화되어 있습니다.

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

구성 정보는 다음을 참조하십시오. Omnibus GitLab 구성 옵션.

구성할 수 없는 제한

리포지터리 아카이브

• 소개: GitLab 12.9에서 도입됨.

리포지터리 아카이브 다운로드에 대한 요율 제한이 있습니다. 이 제한은 프로젝트 및 다운로드를 시작하는 사용자에게 적용됩니다. UI 또는 API를 통해 다운로드를 시작할 수 있습니다.

요율 제한은 사용자 당 분당 5회의 요청을 의미합니다.

웹훅 테스팅

• 테스팅 시작: GitLab 13.4에서 도입됨.

웹훅 테스트에 대한 요율 제한이 있으며, 웹훅 기능의 남용을 방지합니다.

요율 제한은 사용자 당 분당 5회의 요청을 의미합니다.

사용자 가입

• 도입: GitLab 14.7에서 도입됨.

/users/sign_up 엔드포인트에 IP 주소당 요율 제한이 있습니다. 이것은 엔드포인트의 남용을 방지하기 위한 조치입니다. 예를 들어, 사용자명 또는 사용 중인 이메일 주소를 대규모로 검색하기 위한 시도를 완화하기 위함입니다.

요율 제한은 IP 주소당 분당 20회의 호출을 의미합니다.

사용자명 업데이트

• 도입: GitLab 14.7에서 도입됨.

사용자명이 얼마나 자주 변경될 수 있는지에 대한 요율 제한이 있습니다. 이것은 기능의 남용을 완화하기 위해 진행되며, 예를 들어, 사용 중인 사용자명을 대규모로 검색하기 위한 시도를 방지하기 위함입니다.

요율 제한은 인증된 사용자 당 분당 10회의 호출을 의미합니다.

사용자명 존재

• 도입: GitLab 14.7에서 도입됨.

선택한 사용자명이 이미 사용 중인지 확인하기 위해 내부 엔드포인트 /users/:username/exists에 대한 요율 제한이 있습니다. 이것은 사용 중인 사용자명을 대규모로 검색하는 위험을 완화하기 위함입니다.

요율 제한은 IP 주소당 분당 20회의 호출을 의미합니다.

프로젝트 작업 API 엔드포인트

• 도입: GitLab 15.7에서 플래그ci_enforce_rate_limits_jobs_api가 포함됨. 기본적으로 비활성화됨.
• 일반적으로 사용 가능: GitLab 16.0에서 일반 사용 가능. ci_enforce_rate_limits_jobs_api 피처 플래그가 제거됨.

project/:id/jobs 엔드포인트에 대한 요율 제한이 있습니다. 이는 작업 검색 시 시간 초과를 줄이기 위해 진행됩니다.

요율 제한은 기본적으로 인증된 사용자 당 600회의 호출을 의미합니다. 요율 제한을 구성할 수 있습니다.

AI 액션

• GitLab 16.0에 도입.

GraphQL aiAction 뮤테이션에 대한 요청 제한이 있으며, 이 엔드포인트의 남용을 방지하기 위해 시행됩니다.

요청 제한은 사용자당 8시간에 160번의 호출입니다.

API를 사용하여 멤버 삭제

• GitLab 16.0에 도입.

API 엔드포인트(/groups/:id/members 또는 /project/:id/members)를 사용하여 프로젝트나 그룹 멤버를 삭제하는 경우에도 요청 제한이 있습니다.

요청 제한은 분당 60번의 삭제입니다.

문제 해결

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로 대체하여 다음 구문을 사용하여 차단을 해제할 수 있습니다:

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

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

   keys *rack::attack*
   

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

5. 필요하다면, 차단을 피하도록하기 위해 IP를 허용 디렉터리에 추가할 수 있습니다.