외부 요청 필터링
위험한 데이터 유실과 노출로부터 보호하기 위해 GitLab 관리자는 이제 GitLab 인스턴스에서 발생하는 일부 외부 요청을 제한하는 외부 요청 필터링 컨트롤을 사용할 수 있습니다.
안전한 웹훅 및 통합
관리자 역할을 적어도 가진 사용자는 프로젝트나 그룹에서 특정 변경이 발생할 때 트리거되는 웹훅을 설정할 수 있습니다. 트리거되면 POST HTTP 요청이 URL로 전송됩니다. 웹훅은 일반적으로 데이터를 적절한 방식으로 처리하는 특정 외부 웹 서비스로 데이터를 전송하도록 구성됩니다.
그러나 웹훅은 외부 웹 서비스 대신 내부 웹 서비스의 URL로 구성될 수 있습니다. 웹훅이 트리거되면 GitLab 서버나 해당 로컬 네트워크에 있는 비-GitLab 웹 서비스가 악용될 수 있습니다.
웹훅 요청은 GitLab 서버 자체에 의해 수행되며 권한 부여를 위해 후크당 단일 선택적 비밀 토큰을 사용합니다.
- 사용자 토큰이 아닌
- 리포지터리별 토큰 대신
결과적으로 이러한 요청은 의도된 것보다 더 넓은 액세스 권한을 가질 수 있으며 웹훅이 호스팅하는 서버에 있는 모든 것에 액세스할 수 있습니다.
- GitLab 서버
- API 자체
- 일부 웹훅의 경우 다른 서버로의 네트워크 액세스
웹훅은 인증이 필요하지 않은 웹 서비스를 사용하여 파괴적인 명령을 트리거할 수 있습니다. 이러한 웹훅은 GitLab 서버에 리소스를 삭제하는 엔드포인트로 POST HTTP 요청을 생성할 수 있습니다.
웹훅 및 통합에서 로컬 네트워크로의 요청 허용
전제 조건:
- 인스턴스에 대한 관리자 액세스가 필요합니다.
보안되지 않은 내부 웹 서비스의 악용을 방지하기 위해 모든 웹훅 및 통합 요청이 다음 로컬 네트워크 주소로의 접근을 허용하지 않습니다.
- 현재 GitLab 인스턴스 서버 주소
-
127.0.0.1,::1,0.0.0.0,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16, 및 IPv6 site-local (ffc0::/10) 주소를 포함한 사설 네트워크 주소
이러한 주소로의 액세스를 허용하려면:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역(Admin Area)을 선택합니다.
- Settings > Network을 선택합니다.
- Outbound requests를 확장합니다.
- 웹훅 및 통합에서 로컬 네트워크로의 요청 허용 확인란을 선택합니다.
시스템 후크로부터 로컬 네트워크로의 요청 방지
전제 조건:
- 인스턴스에 대한 관리자 액세스가 필요합니다.
시스템 후크는 기본적으로 로컬 네트워크로의 요청을 수행할 수 있습니다. 로컬 네트워크로의 시스템 후크 요청을 방지하려면:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역(Admin Area)을 선택합니다.
- Settings > Network을 선택합니다.
- Outbound requests를 확장합니다.
- 시스템 후크로부터 로컬 네트워크로의 요청 허용 확인란을 해제합니다.
DNS 리바인딩 공격 방지 강제
전제 조건:
- 인스턴스에 대한 관리자 액세스가 필요합니다.
DNS 리바인딩은 악성 도메인 이름이 내부 네트워크 리소스로 해결되도록하여 로컬 네트워크 액세스 제한을 우회하는 기술입니다. GitLab은 이러한 공격에 대한 보호를 기본적으로 활성화되어 있습니다. 이 보호를 비활성화하려면:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역(Admin Area)을 선택합니다.
- Settings > Network을 선택합니다.
- Outbound requests를 확장합니다.
- DNS 리바인딩 공격 방지 강제 확인란을 해제합니다.
요청 필터링
전제 조건:
- GitLab 인스턴스에 대한 관리자 액세스가 필요합니다.
다양한 요청을 차단함으로써 요청 필터링을 사용합니다:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역(Admin Area)을 선택합니다.
- Settings > Network을 선택합니다.
- Outbound requests를 확장합니다.
- IP 주소, IP 범위 및 허용 디렉터리에 정의된 도메인 이름을 제외한 모든 요청 차단 확인란을 선택합니다.
이 확인란을 선택하면 다음에 대한 요청만 차단되지 않습니다:
- Geo, Git, GitLab Shell, Gitaly, PostgreSQL 및 Redis와 같은 코어 서비스
- 객체 리포지터리
- 허용 디렉터리에 정의된 IP 주소 및 도메인
이 설정은 주요 GitLab 애플리케이션에서만 적용되며 Gitaly과 같은 다른 서비스는 이 규칙을 위반하는 요청을 계속할 수 있습니다. 게다가, 일부 GitLab 영역은 외부 필터링 규칙을 준수하지 않을 수 있습니다.
특정 IP 주소 및 도메인으로의 외부 요청 허용
전제 조건:
- 인스턴스에 대한 관리자 액세스가 필요합니다.
특정 IP 주소 및 도메인으로의 외부 요청을 허용하려면:
- 왼쪽 사이드바에서 아래쪽으로 이동하여 관리 영역(Admin Area)을 선택합니다.
- Settings > Network을 선택합니다.
- Outbound requests를 확장합니다.
- Local IP addresses and domain names that hooks and integrations can access에 IP 주소 및 도메인을 입력합니다.
엔트리는 다음과 같이 사용할 수 있습니다:
- 세미콜론, 쉼표 또는 공백(줄 바꿈 포함)으로 구분될 수 있습니다.
- 호스트명, IP 주소, IP 주소 범위와 같은 다른 형식을 포함할 수 있습니다. IPv6가 지원됩니다. 유니코드 문자를 포함하는 호스트명은 애플리케이션에서 국제화된 도메인 이름 (IDNA) 인코딩을 사용해야 합니다.
- 포트를 포함할 수 있습니다. 예를 들어
127.0.0.1:8080은127.0.0.1의 포트 8080으로의 연결만 허용합니다. 포트가 지정되지 않으면 해당 IP 주소나 도메인의 모든 포트가 허용됩니다. IP 주소 범위는 해당 범위 내 모든 IP 주소의 모든 포트를 허용합니다. - 각 엔트리당 255자 이상, 최대 1000개의 숫자입니다.
- 와일드카드(
*.example.com와 같은)는 포함하지 않아야 합니다.
예시:
example.com;gitlab.example.com
127.0.0.1,1:0:0:0:0:0:0:1
127.0.0.0/8 1:0:0:0:0:0:0:0/124
[1:0:0:0:0:0:0:1]:8080
127.0.0.1:8080
example.com:8080
문제 해결
외부 요청을 필터링할 때 다음과 같은 문제가 발생할 수 있습니다.
구성된 URL이 차단됨
만약 구성된 URL이 차단되지 않는다면, allowlist에 정의된 IP 주소, IP 범위 및 도메인 이름을 제외한 모든 요청 차단 확인란만 선택할 수 있습니다. 그렇지 않으면 URL이 차단되었다는 오류 메시지가 표시될 수 있습니다.
이 설정을 활성화할 수 없다면 다음 중 하나를 수행하세요:
- URL 설정을 비활성화합니다.
- 다른 URL을 구성하거나, URL 설정을 비워 둡니다.
- 구성된 URL을 allowlist에 추가합니다.
공용 러너 릴리스 URL이 차단됨
대부분의 GitLab 인스턴스는 public_runner_releases_url이 다음과 같이 설정되어 있습니다.
https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-runner/releases,
이는 요청 필터링을 방해할 수 있습니다.
이 문제를 해결하려면 GitLab에서 GitLab.com으로부터 러너 릴리스 버전 데이터를 더 이상 가져오지 않도록 구성하세요.
GitLab 구독 관리가 차단됨
요청 필터링을 할 때, GitLab 구독 관리가 차단됩니다.
이 문제를 해결하려면 customers.gitlab.com:443을 allowlist에 추가하세요.
GitLab 문서가 차단됨
요청 필터링을 할 때, 도움말 페이지 문서 기본 URL이 차단됨: 허용 디렉터리에 없는 호스트 및 IP 주소로의 요청은 거부됩니다라는 오류가 발생할 수 있습니다. 이 오류를 해결하려면:
- 변경 사항을 되돌려서 더 이상
도움말 페이지 문서 기본 URL이 차단됨오류 메시지가 표시되지 않도록 합니다. -
docs.gitlab.com, 또는 도움말 페이지 리디렉션 문서 URL을 allowlist에 추가합니다. - 변경 사항 저장을 선택합니다.
도움말