보안 및 개인정보 보호 · Clash 기술 블로그

Clash 원격 규칙 집합은 안전한가요? rule-providers 출처, 업데이트 및 변조 위험 확인

rule-providers는 계정 비밀번호를 직접 읽지는 않지만 도메인이 사용할 아웃바운드를 바꿀 수 있습니다. 사용하기 전에 출처, 업데이트 기록 및 롤백 파일을 확인하고 중요한 규칙이 업데이트되면 차이도 살펴보세요.

본문 읽기블로그로 돌아가기
  • rule-providers
  • 규칙 모음
  • 공급망
  • 보안
이 글의 목차
글 작성자
Clash 공식
게시일
업데이트 날짜
예상 읽기 시간
약 8분

자동 업데이트되는 원격 규칙은 사용자가 설정을 바꾸지 않아도 웹사이트 요청의 경로를 변경할 수 있습니다. 다운로드 성공 여부뿐 아니라 관리 주체, 추가된 도메인, 문제가 생겼을 때 이전 파일을 복원할 수 있는지도 확인하세요. 중요한 계정의 요청이 예상과 다른 경로로 나갔다면 파일 형식이 깔끔한지보다 연결 기록과 규칙 변경 내용을 살펴보는 것이 도움이 됩니다.

규칙 파일은 비밀번호를 읽지 못해도 민감한 요청의 출구를 바꿀 수 있습니다

Rule Provider(rule-providers)의 내용과 구성 내 규칙 순서, 특히 앞부분의 DOMAIN-SUFFIX 규칙을 확인하세요. 규칙 집합이 계정 비밀번호를 직접 읽지는 못하지만 직접 연결, 프록시 사용, 거부 여부 결정에 관여합니다. 범위가 너무 넓으면 은행, 회사 관리 화면, 내부 로그인 요청이 모르는 노드를 통과할 수 있습니다. 출처가 불분명하고 자동 업데이트되며 롤백 수단도 없다면 이런 변경을 확인해야 합니다.

연결 기록에 예상하지 않은 정책이 나타나면 이전의 신뢰할 수 있는 규칙 파일 백업을 복원하세요. 백업이 없다면 이 Provider의 규칙 참조를 임시로 제거하세요. 구성을 다시 불러오고 기존 연결을 끊은 뒤 발생 시각, Provider 이름, 일치 항목, 최종 출구를 저장소 변경과 비교해 잘못 포함된 도메인, 로컬 순서 오류, 원격 내용 교체를 구분하세요.

raw 주소는 어느 저장소, 관리자와 커밋에 해당할까요?

추가하기 전에 답할 수 있어야 할 항목

  • 이 raw 파일이 속한 공개 저장소와 유지관리자
  • 저장소의 커밋 기록이 규칙 주제와 일치하는지
  • 다운로드 내용이 예상한 YAML 텍스트나 MRS 바이너리 규칙 파일이며 로그인 페이지, 스크립트나 단축 링크 이동이 아님
  • 현재 구성에서 마지막으로 다운로드한 로컬 파일을 보존할 수 있는지
  • 오류가 발생했을 때 이 Provider 하나만 비활성화하는 방법을 아는지

브랜치 주소는 커밋할 때마다 바뀌므로 신뢰하면서 업데이트가 필요한 규칙에 적합합니다. 커밋 해시 주소의 내용은 고정되어 있어 은행이나 회사 직접 연결처럼 변경이 적고 영향이 큰 규칙에 적합합니다. 두 방식을 함께 사용할 수 있으며 모든 출처를 매시간 업데이트하도록 설정할 필요는 없습니다.

rule-providers의 URL, 형식, 캐시 경로는 어떻게 설정하나요?

검토 가능한 Rule Provider 예시
rule-providers:
  research:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/OWNER/REPO/COMMIT/rules.yaml
    path: ./ruleset/research.yaml
    interval: 86400

rules:
  # REPLACE_WITH_POLICY 必须换成当前配置中已经存在的策略组
  - RULE-SET,research,REPLACE_WITH_POLICY
  - MATCH,DIRECT

OWNER, REPO, COMMIT과 REPLACE_WITH_POLICY는 모두 자리표시자이므로 복사한 뒤 바로 활성화하면 안 됩니다. 확인한 저장소, 고정 커밋과 기존 정책 그룹으로 바꾸세요.

behavior와 format은 원격 내용에 맞춰야 하며 path는 코어가 허용하고 쓰기 가능한 위치로 지정해야 합니다. 규칙 참조를 MATCH 앞에 두되 회사 네트워크, 로컬 네트워크와 반드시 직접 연결해야 하는 우선순위 높은 규칙보다 앞에 놓지 마세요.

업데이트에 성공한 뒤 규칙 수와 수정 시각을 확인하고 익숙한 도메인 몇 개를 골라 일치 여부를 검사합니다. 페이지에 '업데이트 완료'가 표시되었다고 현재 실행 구성이 새 파일을 실제로 참조한다는 뜻은 아닙니다.

중요 규칙을 업데이트하기 전에 diff로 변경 내용 확인

별도의 검토 디렉터리에 rules.last.yaml을 준비하세요. 이미 확인하여 신뢰할 수 있는 이전 규칙 백업이어야 합니다. rules.new.yaml은 이번에 검토할 다운로드 파일입니다. 파일명이나 위치가 다르면 실제 경로로 바꾸고 후보 파일을 사용 중인 Provider 캐시에 바로 쓰지 마세요.

아래 명령은 단계별로 실행하세요. RULE_URL을 신뢰할 수 있는 저장소의 특정 커밋으로 고정된 실제 주소로 바꾸세요. 다운로드가 실패하면 중단하고 남아 있을 수 있는 이전 파일의 해시 계산이나 비교를 계속하지 마세요. 이전의 신뢰할 수 있는 백업이 없으면 후보 내용을 검토할 수만 있으며, diff 결과가 없다고 변경이 없다고 판단해서는 안 됩니다.

직접 제어하는 터미널에서 비교하고 RULE_URL을 먼저 교체
RULE_URL='https://raw.githubusercontent.com/OWNER/REPO/COMMIT/rules.yaml'
curl -L --fail --show-error -o rules.new.yaml "$RULE_URL"
sha256sum rules.new.yaml
diff -u rules.last.yaml rules.new.yaml | less

macOS에서는 sha256sum 대신 shasum -a 256을 사용할 수 있습니다. 해시는 두 파일이 같은지만 증명할 뿐 내용 자체의 신뢰성을 보장하지 않습니다. 실제로 확인해야 할 것은 추가·삭제된 항목, 저장소 커밋 설명과 규칙 주제의 일치 여부입니다.

수천 줄이던 파일이 갑자기 수십 줄로 줄거나 맨 앞에 <!doctype html>이 나타나거나 동영상 규칙에 계정 및 은행 도메인이 대량 추가되면 자동 업데이트를 중단해야 합니다.

업데이트 후 경로가 잘못됐다면 신뢰할 수 있는 규칙을 복원하고 기존 연결 끊기

이상 상황 처리

  1. 해당 Provider 업데이트 중지

    이전의 신뢰할 수 있는 규칙 백업이 있으면 해당 파일을 복원하고, 백업이 없으면 RULE-SET 참조를 임시로 제거하세요.

  2. 구성을 리로드하고 연결 끊기

    새 요청은 기존 정책으로 복구되어야 하며 이전 세션의 외부 경로는 자동으로 바뀌지 않습니다.

  3. 저장소 변경 내용 비교

    잘못 포함된 항목, 주소 이전, 형식 변경 또는 검증할 수 없는 출처 중 무엇인지 확인합니다.

  4. 민감한 계정 확인

    로그인 요청이 예상하지 않은 외부 경로를 거쳤다면 로그인 기록을 확인하고 위험 수준에 따라 인증 정보를 교체합니다.

  5. 고정 커밋 또는 대체 출처 사용

    설명할 수 없는 원격 파일에는 자동 업데이트를 다시 켜지 않습니다.

참고 자료