Custom Rules 표현식(Expression) 문법 완전 정복

 

Custom Rules 표현식 문법 완전 정복

사용자 정의 규칙(Custom Rules) 화면을 열면 표현식(Expression)을 입력하라고 합니다. 편집기에서 클릭으로 만들 수도 있지만, 문법을 알면 복사해서 붙이는 것만으로 훨씬 빠르고 정확해집니다.

안녕하세요, 코딩하는 안다형입니다. 이 글에서는 표현식의 구조와 자주 쓰는 필드, 연산자, 함수를 정리했습니다. 외울 것은 많지 않습니다. 구조는 항상 같습니다.

3줄 요약
1. 표현식은 필드 + 연산자 + 값 세 조각의 조합입니다. 여기에 and, or 로 붙여 나갑니다.
2. 문자열 비교는 대소문자를 구분합니다. lower() 로 감싸면 실수를 줄일 수 있습니다.
3. 규칙은 위에서 아래로 평가됩니다. Skip 규칙을 차단 규칙보다 위에 두세요.

 

표현식 짜는 순서: 필드, 연산자, 값, 조치

표현식의 기본 구조

모든 표현식은 결국 이 형태입니다.

(필드 연산자 값)

가장 단순한 예를 보겠습니다. 특정 경로로 들어오는 요청을 고르는 표현식입니다.

(http.request.uri.path contains "/wp-admin")

여기에 조건을 더하려면 and 나 or 로 이어 붙입니다.

(http.request.uri.path contains "/wp-admin" and ip.src ne 111.222.33.44)

읽으면 이렇습니다. "요청 경로에 /wp-admin 이 들어가고, 접속 IP가 내 IP가 아닌 경우." 여기에 조치로 Managed Challenge를 걸면 관리자 경로 보호 규칙이 됩니다.

자주 쓰는 필드

필드는 요청의 어느 부분을 볼 것인가입니다. 아래 여섯 개면 개인 사이트 규칙의 대부분을 만들 수 있습니다.

• ip.src: 접속한 IP 주소입니다. 값에 따옴표를 쓰지 않습니다.
• ip.src.country: 접속 국가의 두 글자 코드입니다. 한국은 KR입니다. 예전 표기인 ip.geoip.country 를 쓰는 문서도 있습니다.
• http.request.uri.path: 도메인 뒤의 경로입니다. 물음표 앞까지입니다.
• http.request.uri.query: 물음표 뒤의 값입니다.
• http.user_agent: 브라우저나 도구가 스스로 밝히는 이름입니다.
• http.request.method: GET, POST 같은 요청 방식입니다.

여기에 하나 더 알아두면 좋은 것이 있습니다. cf.threat_score 는 해당 IP의 과거 행적을 종합한 위협 점수입니다. 0에 가까울수록 안전하고 값이 클수록 위험합니다.

자주 쓰는 연산자

• eq / ne: 같다 / 같지 않다. 정확히 일치할 때 씁니다.
• contains: 포함한다. 경로나 User-Agent 검사에 가장 많이 씁니다.
• in: 목록 중 하나. 여러 값을 한 번에 비교할 때 편합니다.
• gt / ge / lt / le: 크다 / 크거나 같다 / 작다 / 작거나 같다. 숫자 비교용입니다.
• matches: 정규식 일치. 강력하지만 상위 플랜에서만 쓸 수 있습니다. 무료에서는 contains 로 대체하세요.

in 연산자는 이렇게 씁니다. 중괄호 안에 값을 공백으로 구분해 나열합니다.

(ip.src.country in {"RU" "CN" "VN"})

함수: lower() 만 알아도 됩니다

문자열 비교는 대소문자를 구분합니다. 그래서 User-Agent 를 검사할 때 대문자로 들어오면 조건을 빠져나갑니다. 이걸 막는 것이 lower() 입니다.

(lower(http.user_agent) contains "python-requests")

이렇게 하면 Python-Requests, PYTHON-REQUESTS 도 모두 걸립니다. 비교 값은 반드시 소문자로 적어야 한다는 점만 기억하세요.

 

자주 쓰는 필드와 연산자 정리표

자주 쓰는 필드와 연산자 정리

• ip.src: 접속한 IP를 봅니다. 주로 eq, in 을 씁니다.
• ip.src.country: 접속 국가를 봅니다. 주로 in, ne 를 씁니다.
• http.request.uri.path: 요청 경로를 봅니다. 주로 contains, eq 를 씁니다.
• http.user_agent: 브라우저 정보를 봅니다. 주로 contains, matches 를 씁니다.
• http.request.method: 요청 방식을 봅니다. 주로 eq 를 씁니다.
• cf.threat_score: 위협 점수를 봅니다. 주로 gt, ge 를 씁니다.

괄호와 우선순위

조건이 세 개를 넘어가면 괄호가 중요해집니다. and 가 or 보다 먼저 계산되기 때문입니다.

아래 두 표현식은 완전히 다른 뜻입니다.

A or B and C
(A or B) and C

첫 줄은 "A이거나, 또는 B이면서 C"입니다. 둘째 줄은 "A이거나 B이면서, 동시에 C"입니다. 의도한 것이 아래쪽이라면 괄호를 반드시 넣어야 합니다. 헷갈리면 무조건 괄호를 치세요. 손해가 없습니다.

규칙 순서가 결과를 바꿉니다

문법만큼 중요한 것이 순서입니다. Cloudflare는 규칙을 목록 위에서부터 평가하고, 차단 같은 종료 조치를 만나면 거기서 멈춥니다.

• Skip 규칙은 항상 맨 위에 둡니다. 아래에 있으면 이미 차단된 뒤라 실행되지 않습니다.
• 좁은 규칙을 위에, 넓은 규칙을 아래에 둡니다. 예외를 먼저 처리하고 일반 차단을 나중에 적용하는 순서입니다.
• 규칙이 의도대로 안 걸리면 문법보다 순서를 먼저 의심하세요.

이건 하지 마세요

• IP 값에 따옴표 붙이기: ip.src 는 문자열이 아닙니다. 따옴표 없이 그대로 씁니다.
• 국가 코드를 소문자로: 국가 코드는 대문자입니다. KR 이지 kr 이 아닙니다.
• lower() 를 쓰면서 비교 값을 대문자로: 영원히 일치하지 않습니다.
• 무료 플랜에서 matches 사용: 저장은 되어도 동작하지 않거나 거부됩니다. contains 로 바꾸세요.
• 괄호 없이 and 와 or 섞기: 의도와 다르게 동작합니다.
• 규칙을 만들고 순서를 확인하지 않기: 문법이 맞아도 순서가 틀리면 동작하지 않습니다.

자주 묻는 질문

Q. 편집기로 만드는 것과 표현식 직접 입력은 무엇이 다른가요?

결과는 같습니다. 편집기는 실수가 적고, 직접 입력은 복잡한 조건과 복사 붙여넣기에 유리합니다. 편집기로 만든 뒤 표현식 보기로 전환해 문법을 익히는 방법을 추천합니다.

Q. 규칙을 저장했는데 아무것도 안 걸립니다.

순서, 프록시 상태, 조건 범위 순으로 확인하세요. 그리고 보안 이벤트 로그에서 해당 규칙 이름으로 필터를 걸어 보면 실제로 평가되고 있는지 알 수 있습니다.

Q. 경로 비교에서 슬래시는 어떻게 쓰나요?

http.request.uri.path 는 슬래시로 시작합니다. "/wp-admin" 처럼 앞 슬래시를 포함해 적으세요. eq 는 정확히 일치해야 하므로 하위 경로까지 잡으려면 contains 가 편합니다.

Q. 정규식을 못 쓰면 많이 불편한가요?

개인 사이트에서는 큰 지장이 없습니다. contains 를 or 로 여러 개 이어 붙이면 대부분 대체됩니다. 조건이 길어지는 것이 유일한 단점입니다.

Q. 위협 점수는 얼마로 잡는 게 적당한가요?

값이 낮을수록 많이 걸립니다. 처음에는 넉넉하게 잡고 조치를 Managed Challenge로 두어 로그를 보며 조정하세요. 처음부터 낮은 값에 Block을 걸면 정상 방문자가 막힐 수 있습니다.

Q. 표현식이 틀리면 저장이 안 되나요?

문법 오류는 저장 단계에서 걸러집니다. 다만 문법은 맞지만 의도와 다른 표현식은 그대로 저장됩니다. 그래서 저장 후 로그 확인이 필요합니다.

마무리

정리하면 표현식은 필드 + 연산자 + 값이고, 이걸 and 와 or 로 이어 붙인 뒤 괄호로 묶는 것이 전부입니다. 여기에 lower() 하나와 규칙 순서만 챙기면 됩니다.

다음 글에서는 이 문법으로 실제로 가장 많이 쓰는 세 가지 조건, 국가와 IP와 User-Agent 기반 규칙을 만들어 보겠습니다.

 

함께 보면 좋은 글

• 웹호스팅 · VPS · 클라우드 뭘 골라야 할까
• 티스토리 2차 도메인 연결하는 방법
• 그누보드 메일 발송 설정하는 방법