Cloudflare 방화벽 규칙 초보자 가이드: 무료 규칙 5개로 악성 트래픽 80% 차단하기(템플릿 포함)

들어가며
서버 로그가 매일 수천 건의 악성 스캔 요청으로 가득한데도 Cloudflare 무료 요금제를 쓰면서 방화벽 규칙을 하나도 설정하지 않았다면 사실상 무방비 상태입니다. 인터넷에서 튜토리얼을 찾아 코드를 복사해 붙여 넣었지만 규칙 우선순위를 거꾸로 배치해 전혀 적용되지 않는 경우도 있습니다.
(ip.src.country eq "CN") 같은 규칙 표현식을 처음 보면 막막하지만 며칠 동안 직접 다뤄 보니 무료 요금제의 규칙 5개면 정말 충분했습니다. 합리적으로 구성하면 정상 사용자를 잘못 차단하지 않으면서 악성 요청의 80% 이상을 걸러낼 수 있습니다. 이 글에서는 규칙 원리와 우선순위 설정을 포함해 이 5개 규칙을 30분 안에 구성하는 방법을 설명합니다.
1장: 무료 요금제의 규칙 5개로 충분한 이유
Cloudflare 무료 요금제가 사용자 지정 규칙을 5개만 제공한다는 사실을 보면 대부분 ‘이 정도로는 부족하지 않을까?’라고 생각합니다. Pro 요금제는 20개를 제공하는데 업그레이드해야 할까요?
서두르지 말고 먼저 살펴봅시다.
대부분의 악성 트래픽은 데이터 센터의 스캐너, 위협 점수가 높은 IP, 비정상 User-Agent라는 몇 가지 유형에서 발생합니다. Cloudflare 커뮤니티의 실전 경험에 따르면 규칙 5개를 합리적으로 구성하면 공격의 80% 이상을 막을 수 있습니다.
전형적인 80/20 법칙입니다.
무료 요금제에는 사용자 지정 규칙 5개 외에도 Cloudflare Free Managed Ruleset이 제공됩니다. 기본으로 활성화된 이 규칙 세트는 Shellshock, Log4J 같은 유명한 고위험 취약점을 방어합니다. 중소 규모 웹사이트라면 Managed Ruleset과 사용자 지정 규칙 5개만으로도 충분합니다.
Pro 요금제에서 추가되는 규칙 15개는 세밀한 운영에 더 많이 사용됩니다. 여러 하위 도메인을 각각 구성하거나 API 인터페이스마다 다른 정책을 설정해야 할 때가 대표적입니다. 웹사이트가 그 정도로 복잡하지 않다면 규칙 5개로 핵심 보호 요구 사항을 모두 충족할 수 있습니다.
물론 이 규칙 5개를 올바르게 사용해야 합니다. 우선순위가 잘못되면 규칙을 10개 구성해도 소용없습니다.
2장: 규칙 우선순위의 핵심
가장 실수하기 쉬운 부분입니다. 저도 처음 설정했을 때 규칙 순서를 거꾸로 배치해 애써 작성한 규칙이 하나도 적용되지 않았습니다.
Cloudflare 방화벽 규칙은 위에서 아래로 실행되며 파이프라인처럼 각 요청을 검사합니다. 규칙 1 다음 규칙 2를 검사하는 식입니다. 규칙이 일치하면 해당 동작(Allow, Block, Challenge 등)을 실행한 뒤 중단합니다. 단, Allow는 예외로 이후 규칙도 계속 평가합니다.
집 앞에서 경비원이 방문자를 확인하는 상황으로 비유해 보겠습니다.
- 먼저 신원을 확인: 가족이면 바로 통과(허용 목록)
- 그다음 검증: 낯선 사람이라면 신분증 확인(Challenge)
- 마지막으로 차단: 의심스러운 사람은 출입 거부(Block)
순서를 거꾸로 해 검증 전에 차단하면 정상 방문자도 들어올 수 없습니다.
흔한 실수는 국가 차단 규칙을 허용 목록보다 앞에 두는 것입니다. 예를 들어 UptimeRobot 같은 해외 모니터링 서비스를 사용하면서 첫 번째 규칙을 ‘중국 외 모든 IP 차단’으로 설정하면 모니터링 서비스가 바로 차단되어 웹사이트가 중단돼도 알 수 없습니다.
올바른 방법은 허용 목록을 언제나 첫 번째에 두는 것입니다. 검색 엔진 크롤러, 모니터링 서비스, 본인 IP처럼 정상임을 알고 있는 트래픽을 먼저 허용한 뒤 단계적으로 보호를 강화합니다.
놓치기 쉬운 또 한 가지는 동작에도 우선순위가 있다는 점입니다. 우선순위가 같은 규칙은 다음 순서로 실행됩니다.
- Allow(허용) > Skip(건너뛰기) > Challenge(인증) > Block(차단) > Log(기록)
요청이 Allow 규칙과 Block 규칙에 동시에 일치하면 Allow가 적용됩니다. 허용 목록을 맨 앞에 두어야 하는 이유도 가장 높은 우선순위를 보장해 이후 규칙에 정상 트래픽이 잘못 차단되지 않도록 하기 위해서입니다.
3장: 핵심 규칙 5개 구성안
이제 핵심 내용으로 들어가겠습니다. 아래 규칙 5개는 우선순위가 높은 순서로 나열했으며 그대로 복사해 사용할 수 있습니다.
규칙 1(최우선): 허용 목록 - 정상 트래픽 보호
역할: 정상임을 알고 있는 트래픽을 허용해 오탐을 방지합니다.
적용 대상:
- 검색 엔진 크롤러(Google, Bing, Baidu 등)
- 모니터링 서비스(UptimeRobot, StatusCake 등)
- 사무실 또는 집에서 사용하는 본인 IP
규칙 표현식:
(cf.client.bot) or (ip.src in {1.2.3.4 5.6.7.8})
동작: Allow
설명:
cf.client.bot은 Google, Bing 같은 주요 검색 엔진을 포함해 Cloudflare가 검증한 정상 크롤러를 나타냅니다.{1.2.3.4 5.6.7.8}을 본인의 IP 주소로 바꿉니다. 여러 IP는 공백으로 구분합니다.- IP 허용 목록이 필요 없다면
(cf.client.bot)으로 단순화할 수 있습니다.
규칙 2: 데이터 센터 ASN Challenge - 서버 팜 트래픽 차단
역할: 데이터 센터에서 들어오는 트래픽에 사람인지 확인하는 검증을 적용합니다.
적용 대상:
스캐너와 크롤링 도구는 대부분 VPS나 클라우드 서버에서 실행되지만 정상 사용자가 데이터 센터 IP로 웹사이트에 접속하는 경우는 드뭅니다. Challenge를 적용하면 봇을 효과적으로 걸러낼 수 있습니다.
규칙 표현식:
(ip.geoip.asnum in {13335 15169 16509 14618 45090})
동작: Managed Challenge
ASN 목록(자주 쓰이는 데이터 센터):
| ASN 번호 | 서비스 제공업체 | 설명 |
|---|---|---|
| AS13335 | Cloudflare | Cloudflare 자체 ASN, Challenge 권장 |
| AS15169 | Google Cloud | GCP |
| AS16509 | Amazon AWS | 최대 규모의 클라우드 서비스 제공업체 |
| AS14618 | Tencent Cloud | 중국에서 자주 사용 |
| AS45090 | Alibaba Cloud | 중국에서 자주 사용 |
웹사이트 상황에 맞춰 ASN을 추가하거나 삭제할 수 있습니다. VPN을 사용하는 실제 사용자가 잘못 차단될 수 있으므로 바로 Block하는 것은 권장하지 않습니다. Managed Challenge를 사용하면 실제 사용자는 검증을 통과할 수 있지만 봇은 막힙니다.
규칙 3: 위협 점수 + 위험 IP 필터
역할: Cloudflare의 위협 인텔리전스를 기반으로 고위험 IP를 차단합니다.
적용 대상:
Cloudflare는 각 IP에 0부터 100까지 점수를 부여하며 점수가 높을수록 위험합니다. 10을 넘으면 스팸 발송자일 수 있고, 40을 넘으면 악성 행위자일 가능성이 높으며, 50을 넘으면 바로 차단하는 것이 좋습니다.
규칙 표현식:
(cf.threat_score gt 10)
동작: Challenge(위협 점수 10-40) 또는 Block(위협 점수 50 초과)
권장 위협 점수 임계값:
| 위협 점수 | 위험 수준 | 권장 동작 |
|---|---|---|
| 0-10 | 낮은 위험 | 허용 |
| 11-40 | 중간 위험 | Challenge |
| 41-50 | 높은 위험 | JS Challenge |
| 51-100 | 매우 높은 위험 | Block |
최적화 팁:
구간별로 다르게 처리하려면 규칙 2개를 만들 수 있습니다.
- 규칙 3A:
(cf.threat_score gt 10 and cf.threat_score le 50)→ Challenge - 규칙 3B:
(cf.threat_score gt 50)→ Block
다만 이렇게 하면 규칙 2개를 사용합니다. 규칙 수가 부족하다면 gt 10과 Challenge를 함께 사용해 일주일 동안 효과를 관찰한 뒤 조정할 수 있습니다.
규칙 4: 비정상 User-Agent 차단
역할: 빈 UA, 악성 크롤러, 자동화 도구를 걸러냅니다.
적용 대상:
정상 브라우저는 서버에 ‘Chrome 브라우저입니다’ 같은 정보를 알리는 User-Agent를 보냅니다. UA가 비어 있거나 python-requests, curl처럼 명백한 스크립트 도구라면 실제 사용자의 접속이 아닐 가능성이 큽니다.
규칙 표현식:
(http.user_agent eq "") or (http.user_agent contains "python-requests") or (http.user_agent contains "curl") or (http.user_agent contains "sqlmap") or (http.user_agent contains "nikto") or (http.user_agent contains "MJ12bot")
동작: Block
자주 보이는 악성 UA 목록:
python-requests- Python 스크립트curl- 명령줄 도구sqlmap- SQL 인젝션 도구nikto- 취약점 스캐너MJ12bot- robots.txt를 준수하지 않는 Majestic SEO 크롤러masscan- 포트 스캔 도구ZmEu- 스캐너
주의 사항:
Mozilla,Chrome,Safari같은 주요 브라우저 UA는 차단하지 마세요.- 먼저 Log 동작으로 일주일 동안 관찰하고 로그에서 확인된 비정상 UA를 규칙에 추가할 수 있습니다.
- 웹사이트가 API를 제공한다면 자체 API 클라이언트 UA를 제외해야 할 수 있습니다.
규칙 5: 민감한 경로 보호
역할: 관리자 로그인 페이지, 민감한 API 인터페이스, 구성 파일을 보호합니다.
적용 대상:
WordPress의 /wp-admin, /wp-login.php는 공격자가 즐겨 스캔하는 경로입니다. .env, .git 같은 구성 파일이 유출되면 심각한 문제가 생깁니다.
규칙 표현식:
(http.request.uri.path contains "/wp-login" or http.request.uri.path contains "/wp-admin" or http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git") and not (ip.src in {1.2.3.4})
동작: Block 또는 Challenge
설명:
{1.2.3.4}를 본인 IP로 바꾸면 관리 페이지에 직접 접속할 때 영향을 받지 않습니다.- IP 허용 목록을 사용하지 않으려면
and not (ip.src in {1.2.3.4})부분을 제거하고 Challenge 동작을 사용합니다.
그 밖의 민감한 경로:
/xmlrpc.php(DDoS에 자주 악용되는 WordPress XML-RPC 인터페이스)/phpMyAdmin(데이터베이스 관리 화면)/config.php/.sql(데이터베이스 백업 파일)
웹사이트의 기술 스택에 맞춰 해당하는 민감한 경로를 추가할 수 있습니다.
전체 규칙 실행 흐름
규칙 5개를 구성하면 요청은 다음 순서로 처리됩니다.
접속 요청
↓
규칙 1: 정상 크롤러 또는 허용 목록 IP인가? → 예 → 바로 허용
↓ 아니요
규칙 2: 데이터 센터 ASN에서 왔는가? → 예 → 사람인지 확인 → 통과/차단
↓ 아니요
규칙 3: 위협 점수가 10을 넘는가? → 예 → Challenge/Block
↓ 아니요
규칙 4: User-Agent가 비정상인가? → 예 → Block
↓ 아니요
규칙 5: 민감한 경로에 접속하는가? → 예 → Block/Challenge
↓ 아니요
허용 후 원본 서버로 전달
이 흐름은 정상 사용자를 잘못 차단하지 않으면서 자동화 공격 대부분을 걸러냅니다.
4장: 실전 구성 절차
규칙을 읽는 것만으로는 충분하지 않으므로 직접 구성해 보겠습니다.
1단계: 방화벽 구성 페이지 열기
Cloudflare Dashboard에 로그인 → 도메인 선택 → 왼쪽 메뉴에서 ‘Security’(보안) 선택 → ‘WAF’ 클릭 → ‘Custom rules’(사용자 지정 규칙) 탭으로 이동합니다.
2단계: 첫 번째 규칙(허용 목록) 만들기
-
오른쪽 위의 파란색 ‘Create rule’ 버튼을 클릭합니다.
-
규칙 이름:
허용 목록-정상 크롤러와 모니터링처럼 알아보기 쉬운 이름을 입력합니다. -
표현식 편집기: 기본값은 Expression Builder(시각적 편집기)입니다. 코드를 바로 붙여 넣으려면 ‘Edit expression’을 클릭해 코드 모드로 전환합니다.
-
규칙 표현식 붙여 넣기:
(cf.client.bot) or (ip.src in {1.2.3.4})IP를 본인 IP로 바꾸세요.
-
동작 선택: 드롭다운 메뉴에서 ‘Allow’를 선택합니다.
-
‘Deploy’를 클릭합니다.
3단계: 나머지 규칙 4개 차례로 만들기
같은 방법으로 규칙 2부터 5까지 만듭니다. 각 규칙의 이름, 표현식, 동작은 3장의 내용을 참고하세요.
4단계: 규칙 순서 조정하기
규칙 5개를 모두 만들면 규칙 목록이 표시됩니다. 규칙 왼쪽의 점 6개 아이콘을 드래그해 다음 순서가 되도록 조정합니다.
- 허용 목록을 맨 위에 배치(우선순위 1)
- ASN Challenge를 두 번째에 배치
- 위협 점수를 세 번째에 배치
- 비정상 UA를 네 번째에 배치
- 민감한 경로를 다섯 번째에 배치
5단계: 규칙 효과 테스트하기
구성이 끝나면 다음과 같이 테스트하는 것이 좋습니다.
-
허용 목록 테스트: 본인 IP로 웹사이트에 접속하면 정상적으로 열려야 합니다.
-
UA 차단 테스트: 터미널을 열고 다음 명령을 입력합니다.
curl -A "sqlmap" https://내도메인.com차단 안내 페이지가 표시되어야 합니다.
-
차단 로그 확인: Cloudflare Dashboard → Security → Events에서 방금 발생한 차단 기록을 확인할 수 있습니다.
규칙이 적용되지 않으면 다음을 확인하세요.
- 규칙 표현식에 문법 오류가 없는지
- 우선순위 순서가 올바른지
- 올바른 동작을 선택했는지
5장: 고급 팁과 자주 묻는 질문
기본 규칙 5개만 구성해도 대부분의 공격을 막을 수 있지만 더 다듬을 만한 세부 사항이 있습니다.
규칙 효과를 판단하는 방법
Cloudflare는 **CSR(Challenge Solve Rate, 인증 통과율)**이라는 유용한 지표를 제공합니다.
공식: CSR = 인증 성공 횟수 / 전체 인증 요청 횟수
이 수치는 낮을수록 좋습니다. CSR이 0%에 가깝다면 인증 대상이 거의 모두 봇이고 인증을 통과한 봇이 없다는 뜻입니다. 이 경우 동작을 Challenge에서 Block으로 바꿔 바로 차단하고 서버 리소스를 절약할 수 있습니다.
CSR이 높다면(예: 50% 초과) 실제 사용자를 잘못 차단했을 가능성이 있으므로 규칙 조건을 조정해야 합니다.
CSR은 Security → Events → 규칙 클릭 → 상세 통계 데이터에서 확인합니다.
정상 사용자 오탐을 피하는 방법
가장 피하고 싶은 문제입니다. 다음 방법을 권장합니다.
- 새 규칙은 먼저 Log 모드로 7일간 관찰하기
- 동작을 ‘Log’로 선택해 기록만 하고 차단하지 않습니다.
- 일주일 후 Security Events에서 오탐이 없음을 확인하고 Challenge 또는 Block으로 변경합니다.
- 본인 IP와 모니터링 서비스를 허용 목록에 추가하기
- 자주 쓰는 IP를 규칙 1에 추가합니다.
- UptimeRobot의 IP 범위는 공식 웹사이트에서 확인해 허용 목록에 넣을 수 있습니다.
- 처음부터 Block을 사용하지 않기
- 먼저 Challenge로 일정 기간 관찰합니다.
- CSR이 0%에 가까운지 확인한 뒤 Block 전환을 고려합니다.
- 트래픽이 비정상적으로 감소하지 않는지 확인하기
- 규칙 설정 후 정상 트래픽도 크게 줄었다면 오탐일 수 있습니다.
- Security Events에서 정상 사용자가 차단됐는지 확인합니다.
갑작스러운 공격에 대응하는 방법
웹사이트가 CC 공격이나 DDoS 공격을 받아 트래픽이 급증하면 Under Attack 모드, 이른바 ‘5초 보호’를 임시로 활성화할 수 있습니다.
Security → Settings → Security Level → ‘I’m Under Attack’을 선택합니다.
이 모드는 모든 방문자에게 5초 동안 로딩 페이지를 표시하고 JS 검증을 수행합니다. 봇은 통과하지 못하고 실제 사용자는 5초 후 접속할 수 있습니다. 공격이 끝나면 Medium 또는 Low로 되돌려야 합니다.
규칙을 임시로 강화할 수도 있습니다.
- Challenge를 Block으로 변경
- 특정 국가에서 공격이 발생한다면 해당 국가 IP를 임시로 차단하도록 지역 차단 추가
규칙 5개가 부족할 때
실제로 규칙 5개가 부족한 경우에는 다음 방법을 사용할 수 있습니다.
or로 같은 유형의 규칙 합치기- 규칙 4처럼 여러 비정상 UA를
or로 한 규칙에 통합합니다. - 규칙 하나가 한 유형의 시나리오를 최대한 포괄하도록 구성합니다.
- 규칙 4처럼 여러 비정상 UA를
- IP 목록을 만들어 통합 관리하기
- Cloudflare IP 목록은 수천 개의 IP를 지원합니다.
- 규칙에서
ip.src in $blacklist처럼 목록을 참조합니다. - 그러면 규칙 수를 더 쓰지 않고도 하나의 규칙으로 많은 IP를 관리할 수 있습니다.
- Pro 요금제 업그레이드 고려하기
- Pro 요금제는 규칙 20개와 더 많은 고급 기능을 제공합니다.
- 웹사이트에서 수익이 난다면 투자할 가치가 있습니다.
자주 묻는 질문
Q: 규칙이 적용되지 않을 때는 어떻게 하나요?
A: 다음을 확인하세요.
- 규칙 표현식 문법에 오류가 없는지(오류가 있으면 Cloudflare가 알려 줍니다.)
- 우선순위 순서가 올바른지(허용 목록이 맨 위에 있어야 합니다.)
- 상위 규칙이 먼저 Allow 또는 Skip으로 처리하지 않았는지
Q: 내 IP가 차단되면 어떻게 하나요?
A: 규칙 1의 허용 목록에 본인 IP를 추가합니다.
(cf.client.bot) or (ip.src in {본인 IP})
Q: 위협 점수는 어느 정도로 설정하는 것이 적절한가요?
A: 다음 값을 권장합니다.
- 보수형:
cf.threat_score gt 30(차단이 적고 오탐 위험이 낮음) - 균형형:
cf.threat_score gt 10(보호와 사용자 경험을 함께 고려한 권장 설정) - 적극형:
cf.threat_score gt 5(더 많이 차단하지만 VPN 사용자를 잘못 차단할 수 있음)
먼저 10으로 설정해 일주일 동안 관찰한 뒤 CSR과 오탐 상황에 따라 조정하세요.
Q: Google 크롤러가 차단되는 이유는 무엇인가요?
A: 규칙 1(허용 목록)의 우선순위가 가장 높은지 확인합니다. cf.client.bot은 Google, Bing 등 주요 크롤러를 자동으로 식별하므로 허용 목록이 첫 번째라면 차단되지 않습니다.
결론
핵심을 정리하면 무료 요금제의 방화벽 규칙 5개면 충분합니다. 중요한 것은 다음 우선순위에 맞춰 합리적으로 구성하는 것입니다.
- 허용 목록을 첫 번째에 배치해 정상 트래픽 보호
- ASN Challenge로 서버 팜 트래픽 차단
- 위협 점수 필터로 고위험 IP 차단
- 비정상 UA 차단으로 자동화 도구 필터링
- 민감한 경로 보호로 백도어 방어
설정은 30분 후 적용됩니다. 일주일 뒤 Security Events를 확인하면 그동안 트래픽과 대역폭을 소모하던 스캐너가 모두 차단된 것을 볼 수 있을 것입니다.
지금 바로 구성해 보세요. Cloudflare Dashboard에서 위의 규칙 템플릿을 복사해 붙여 넣고 IP만 수정하면 30분 안에 끝낼 수 있습니다.
일주일 뒤 차단 데이터를 확인하는 것도 잊지 마세요. 효과가 좋다면 이 글을 저장해 두었다가 나중에 규칙을 조정할 때 다시 참고할 수 있습니다. 문제가 생기면 5장의 자주 묻는 질문도 확인하세요.
웹사이트에는 더 나은 보호가 필요합니다.
Cloudflare 방화벽 규칙으로 악성 트래픽을 필터링하는 전체 절차
규칙 우선순위를 이해하는 단계부터 핵심 규칙 5개를 구성하는 단계까지, 30분 안에 악성 트래픽의 80%를 걸러내는 전체 절차
Estimated time: PT30M
-
1
Step 1: 규칙 우선순위와 동작 순서 이해하기
Cloudflare 방화벽 규칙은 파이프라인처럼 위에서 아래로 각 요청을 검사합니다. 규칙 1 다음 규칙 2를 검사하는 식입니다. 규칙이 일치하면 해당 동작(Allow, Block, Challenge 등)을 실행한 뒤 중단합니다. 단, Allow는 예외로 이후 규칙도 계속 평가합니다. -
2
Step 2: 규칙 1 구성: 허용 목록(최우선)
역할: 정상임을 알고 있는 트래픽을 허용해 오탐을 방지합니다. -
3
Step 3: 규칙 2 구성: 데이터 센터 ASN Challenge
역할: 데이터 센터에서 들어오는 트래픽에 사람인지 확인하는 검증을 적용합니다. -
4
Step 4: 규칙 3 구성: 위협 점수 필터
역할: Cloudflare의 위협 인텔리전스를 기반으로 고위험 IP를 차단합니다. -
5
Step 5: 규칙 4 구성: 비정상 User-Agent 차단
역할: 빈 UA, 악성 크롤러, 자동화 도구를 걸러냅니다. -
6
Step 6: 규칙 5 구성: 민감한 경로 보호 및 규칙 순서 조정
역할: 관리자 로그인 페이지, 민감한 API 인터페이스, 구성 파일을 보호합니다.
FAQ
Cloudflare 무료 요금제의 방화벽 규칙 5개로 충분한가요? 악성 트래픽의 80%를 차단할 수 있는 이유는 무엇인가요?
대부분의 악성 트래픽은 몇 가지 유형에서 발생합니다.
• 데이터 센터의 스캐너
• 위협 점수가 높은 IP
• 비정상 User-Agent
Cloudflare 커뮤니티의 실전 경험에 따르면 규칙 5개를 합리적으로 구성했을 때 공격의 80% 이상을 막을 수 있습니다. 전형적인 80/20 법칙입니다.
무료 요금제에는 사용자 지정 규칙 5개 외에도 Cloudflare Free Managed Ruleset이 기본으로 활성화되어 있습니다. 이 규칙 세트는 Shellshock, Log4J 같은 유명한 고위험 취약점을 방어할 수 있습니다.
중소 규모 웹사이트라면 Managed Ruleset과 사용자 지정 규칙 5개만으로도 충분합니다.
Pro 요금제에서 추가되는 규칙 15개는 세밀한 운영에 더 적합합니다. 예를 들어 여러 하위 도메인을 각각 구성하거나 API 인터페이스마다 다른 정책을 설정해야 할 때 유용합니다. 웹사이트가 그 정도로 복잡하지 않다면 규칙 5개로 핵심 보호 요구 사항을 모두 충족할 수 있습니다.
다만 이 규칙 5개를 올바르게 사용해야 합니다. 우선순위가 잘못되면 규칙을 10개 구성해도 소용없습니다.
규칙 우선순위가 왜 중요한가요? 올바르게 설정하려면 어떻게 해야 하나요?
동작에도 우선순위가 있습니다.
• Allow(허용) > Skip(건너뛰기) > Challenge(인증) > Block(차단) > Log(기록)
요청이 Allow 규칙과 Block 규칙에 동시에 일치하면 Allow가 적용된다는 뜻입니다. 허용 목록을 맨 앞에 두어야 하는 이유도 우선순위를 가장 높게 보장해 이후 규칙에 정상 트래픽이 잘못 차단되지 않도록 하기 위해서입니다.
흔한 실수:
국가 차단 규칙을 허용 목록보다 앞에 두는 경우입니다. 예를 들어 UptimeRobot 같은 해외 모니터링 서비스를 사용하면서 첫 번째 규칙을 ‘중국 외 모든 IP 차단’으로 설정하면 모니터링 서비스가 바로 차단되어 웹사이트가 중단돼도 알 수 없습니다.
올바른 방법:
허용 목록은 언제나 첫 번째에 둡니다. 검색 엔진 크롤러, 모니터링 서비스, 본인 IP처럼 정상임을 알고 있는 트래픽을 먼저 허용한 뒤 단계적으로 보호를 강화합니다.
올바른 순서:
• 허용 목록을 맨 위에 배치(우선순위 1)
• ASN Challenge를 두 번째에 배치
• 위협 점수를 세 번째에 배치
• 비정상 UA를 네 번째에 배치
• 민감한 경로를 다섯 번째에 배치
위협 점수 임계값은 어느 정도가 적절한가요? 규칙이 효과적인지는 어떻게 판단하나요?
• 0-10: 낮은 위험, 허용
• 11-40: 중간 위험, Challenge
• 41-50: 높은 위험, JS Challenge
• 51-100: 매우 높은 위험, Block
먼저 10으로 설정해 일주일 동안 관찰한 뒤 CSR과 오탐 상황에 따라 조정하는 것이 좋습니다.
전략 선택:
• 보수형: cf.threat_score gt 30(차단이 적고 오탐 위험이 낮음)
• 균형형: cf.threat_score gt 10(보호와 사용자 경험을 함께 고려한 권장 설정)
• 적극형: cf.threat_score gt 5(더 많이 차단하지만 VPN 사용자를 잘못 차단할 수 있음)
규칙 효과를 판단하는 방법:
Cloudflare는 CSR(Challenge Solve Rate, 인증 통과율)이라는 유용한 지표를 제공합니다.
공식: CSR = 인증 성공 횟수 / 전체 인증 요청 횟수
이 수치는 낮을수록 좋습니다.
• CSR이 0%에 가까움: 인증 대상이 거의 모두 봇이고 인증을 통과한 봇이 없다는 뜻입니다. 이 경우 동작을 Challenge에서 Block으로 바꿔 바로 차단하고 서버 리소스를 절약할 수 있습니다.
• CSR이 높음(예: 50% 초과): 실제 사용자를 잘못 차단했을 가능성이 있으므로 규칙 조건을 조정해야 합니다.
CSR 확인 경로:
Security → Events → 규칙 클릭 → 상세 통계 데이터 확인
구성은 30분 후 적용됩니다. 일주일 뒤 Security Events를 확인하면 상당한 차단량을 볼 수 있습니다.
정상 사용자가 잘못 차단되는 일을 어떻게 피하나요? 규칙 5개가 부족하면 어떻게 하나요?
1) 새 규칙은 먼저 Log 모드로 7일간 관찰합니다. 동작을 ‘Log’로 선택해 기록만 하고 차단하지 않은 뒤, 일주일 후 Security Events에서 오탐이 없음을 확인하고 Challenge 또는 Block으로 변경합니다.
2) 본인 IP와 모니터링 서비스를 허용 목록에 추가합니다. 자주 쓰는 IP를 규칙 1에 추가하고 UptimeRobot의 IP 범위는 공식 웹사이트에서 확인해 허용 목록에 넣을 수 있습니다.
3) 처음부터 Block을 사용하지 않습니다. 먼저 Challenge로 일정 기간 관찰하고 CSR이 0%에 가까운지 확인한 뒤 Block 전환을 고려합니다.
4) 트래픽이 비정상적으로 감소하지 않는지 확인합니다. 규칙 설정 후 정상 트래픽도 크게 줄었다면 오탐일 수 있으므로 Security Events에서 정상 사용자가 차단됐는지 확인합니다.
규칙 5개가 부족할 때:
1) or로 같은 유형의 규칙을 합칩니다. 예를 들어 규칙 4는 여러 비정상 UA를 or로 한 규칙에 통합합니다. 규칙 하나가 한 유형의 시나리오를 최대한 포괄하도록 구성합니다.
2) IP 목록을 만들어 통합 관리합니다. Cloudflare IP 목록은 수천 개의 IP를 지원하며 규칙에서 ip.src in $blacklist처럼 참조할 수 있습니다. 그러면 규칙 수를 더 쓰지 않고도 하나의 규칙으로 많은 IP를 관리할 수 있습니다.
3) Pro 요금제 업그레이드를 고려합니다. Pro 요금제는 규칙 20개와 더 많은 고급 기능을 제공합니다. 웹사이트에서 수익이 난다면 투자할 가치가 있습니다.
규칙이 적용되지 않을 때는 어떻게 하나요? 내 IP가 차단되면 어떻게 처리하나요?
• 규칙 표현식 문법에 오류가 없는지 확인합니다. 오류가 있으면 Cloudflare가 알려 줍니다.
• 우선순위 순서가 올바른지 확인합니다. 허용 목록은 맨 위에 있어야 합니다.
• 상위 규칙이 먼저 Allow 또는 Skip으로 처리하지 않았는지 확인합니다.
내 IP가 차단된 경우:
규칙 1의 허용 목록에 본인 IP를 추가합니다: (cf.client.bot) or (ip.src in {본인 IP})
규칙 효과 테스트:
• 본인 IP로 웹사이트에 접속하면 정상적으로 열려야 합니다.
• curl -A "sqlmap" https://내도메인.com을 실행하면 차단 안내 페이지가 표시되어야 합니다.
• 차단 로그는 Cloudflare Dashboard → Security → Events에서 확인합니다.
규칙이 적용되지 않으면 다음을 다시 확인합니다.
• 규칙 표현식에 문법 오류가 없는지
• 우선순위가 올바른지
• 올바른 동작을 선택했는지
Google 크롤러가 차단되는 이유:
규칙 1(허용 목록)의 우선순위가 가장 높은지 확인합니다. cf.client.bot은 Google, Bing 등 주요 크롤러를 자동으로 식별하므로 허용 목록이 첫 번째라면 차단되지 않습니다.
갑작스러운 공격에는 어떻게 대응하나요? CSR(인증 통과율)이란 무엇인가요?
웹사이트가 CC 공격이나 DDoS 공격을 받아 트래픽이 급증하면 Under Attack 모드, 이른바 ‘5초 보호’를 임시로 활성화할 수 있습니다.
• Security → Settings → Security Level → ‘I'm Under Attack’ 선택
• 모든 방문자에게 5초 동안 로딩 페이지를 표시하고 JS 검증을 수행합니다.
• 봇은 통과하지 못하고 실제 사용자는 5초 후 접속할 수 있습니다.
• 공격이 끝나면 Medium 또는 Low로 되돌려야 합니다.
규칙을 임시로 강화할 수도 있습니다.
• Challenge를 Block으로 변경
• 특정 국가에서 공격이 발생한다면 해당 국가 IP를 임시로 차단하도록 지역 차단 추가
CSR(Challenge Solve Rate, 인증 통과율):
공식은 CSR = 인증 성공 횟수 / 전체 인증 요청 횟수입니다.
이 수치는 낮을수록 좋습니다.
• CSR이 0%에 가까움: 인증 대상이 거의 모두 봇이고 인증을 통과한 봇이 없다는 뜻입니다. Challenge를 Block으로 변경해 바로 차단하고 서버 리소스를 절약할 수 있습니다.
• CSR이 높음(예: 50% 초과): 실제 사용자를 잘못 차단했을 가능성이 있으므로 규칙 조건을 조정해야 합니다.
CSR 확인 경로:
Security → Events → 규칙 클릭 → 상세 통계 데이터 확인
2분 읽기 · 게시일: 2025년 12월 1일 · 수정일: 2026년 9월 4일
Cloudflare 풀스택
검색으로 들어왔다면 같은 시리즈의 이전 글이나 다음 글로 이동하는 것이 가장 빠릅니다.
이전
Cloudflare 캐시 적중률이 30%뿐인가요? 이 3가지 규칙으로 90%까지 높이기
Cloudflare가 기본적으로 HTML을 캐시하지 않아 적중률이 낮은 문제를 해결합니다. Cache Rules와 Edge TTL로 사이트 전체 캐시를 구성해 적중률을 30%에서 90%로 높이고 서버 부하를 크게 줄이는 전체 설정 절차, 보안 주의 사항, 검증 방법을 소개합니다.
15편 중 5편
다음
Cloudflare Under Attack 모드 설정 방법: SEO와 사용자 경험을 지키는 3가지 팁
Cloudflare Under Attack 모드의 작동 원리와 SEO 영향, Page Rules 설정, Challenge Passage 최적화, 7가지 모범 사례를 설명합니다.
15편 중 7편



댓글
GitHub로 로그인하여 댓글을 남기세요