관리형 WAF 룰 운영Cloudflare 가 고치는 룰을 우리는 어떻게 다루나

1주차에 우리 존 이벤트를 보면 새 룰의 오탐을 미리 압니다.

• 기존 룰 수정은 «BETA» 별도 룰로 먼저 나오고, 다음 주기에 원래 룰에 반영됩니다.
• 꺼진 채 추가되는 룰도 있습니다.
• beta 태그가 7일보다 오래 남기도 하니 바뀐 시점은 changelog 의 last_updated 로 봅니다(RSS 제공).

Free 플랜은 Free Managed Ruleset 을 쓰며, 위 룰셋을 켰다면 따로 필요 없습니다.

Managed Ruleset 과 공격 점수? 위에 OWASP 를 더한 이득은 크지 않다고 문서는 봅니다.

도메인 › Security › Settings › (필터) Web application exploits › Cloudflare managed ruleset 켜기 › Save

• 기본 범위는 모든 요청이고, Edit scope 로 호스트나 경로를 좁힙니다.
• 토글로 잠시 꺼도 설정은 남습니다.
• 존에서는 한 룰셋을 한 번만 배포합니다(여러 설정은 Enterprise 계정 단위 배포).

1. Security Events? 에서 Service 를 관리형 룰로 걸러 룰 ID 와 룰셋 이름을 적습니다.
2. 걸린 정상 요청의 공통점(같은 경로 등)을 찾습니다.
3. Security rules › Create › Managed rules 에서 그 경로만 그 룰을 건너뛰는 예외를 만듭니다.

재정의로 룰을 끄면(Off) 모든 요청에서 보호가 빠집니다.

급하다고 룰셋을 끄거나 «Skip all remaining rules» 예외를 넓게 걸면 막던 공격도 들어옵니다.

• 걸린 룰 하나만, 그 경로에서만 건너뛰는 예외가 기본입니다.

Events 탭에서 건너뛴(Skip) 요청을 주기적으로 찾아 공격이 섞였는지 봅니다.

도메인 › Security › Security rules › (필터) Managed rules › 실행(Execute) 룰 이름 › 룰셋 설정 또는 Browse rules

• 룰셋 액션을 Default 로 두면 재정의가 풀려 룰마다 기본 액션으로 돌아갑니다.
• 새 룰은 빼고 지금 룰만 바꾸려면 룰 재정의를 씁니다.
• 태그로 고르면 새 룰 포함 여부(Include new rules, Only selected rules)를 묻습니다.

OWASP 룰셋은 태그와 룰 단위로 켜짐만 바꿉니다. 액션은 룰셋의 OWASP action 에서 정합니다.

도메인 › Security › Security rules › Create › Managed rules

관리자 화면 오탐이라면 그 경로만 뺍니다.

http.host eq "www.example.com" and starts_with(http.request.uri.path, "/admin")

• 예외는 건너뛸 실행(Execute) 룰보다 목록 위에 둡니다.
• 예외에 맞은 요청은 기본으로 기록됩니다(Log matching requests).
• Browser Integrity Check 같은 다른 기능은 커스텀 룰의 Skip 으로 뺍니다.

도메인 › Security › Analytics › Events 탭 › Add filter › Service equals Managed rules

• Sampled logs 한 줄을 펼치면 룰 ID 와 룰셋 이름이 보입니다.
• OWASP 내역은 Additional logs 에 따로 나오고 JSON 내보내기엔 빠집니다.
• 요청 하나가 여러 기능에 걸리면 이벤트도 여러 건입니다.

목록은 표본 추출? 결과일 수 있어, 기간을 짧게 잡을수록 더 많은 건이 보입니다.

그래프가 최근 며칠을 비워 보이면 기간을 바꾸거나 표, API 로 다시 셉니다. 2026-10-15 랩 존도 그래프는 10-10 이후 비었지만 GraphQL 에는 매일 이벤트가 있었습니다.

1. 걸린 요청을 보고 오탐은 예외로 뺍니다.
2. 먼저 막을 태그에 Block 재정의를 겁니다. 좁은 재정의가 룰셋의 Log 보다 우선합니다.
3. 룰셋 액션을 Default 로 바꿔 룰마다 Cloudflare 기본 액션으로 돌립니다.

룰셋 액션을 Block 으로 재정의하면 새 룰도 1주차 Log 없이 바로 막습니다. Log 는 Enterprise 전용입니다.

릴리스 때 Cloudflare 가 바꾸는 기본 액션(1주차 Log 에서 2주차 기본으로)은 우리가 액션을 지정한 룰에 닿지 않습니다.

• 액션 재정의는 꼭 필요한 룰에만 두고 이유와 날짜를 기록합니다.
• 필요 없어진 재정의는 주기적으로 기본값으로 되돌립니다.

PUT /zones/{zone_id}/rulesets/phases/http_request_firewall_managed/entrypoint
"action": "execute", "action_parameters": {"id": "(룰셋 ID)", "overrides": {…}}

• 기본 속성은 action 과 enabled 이고, 룰셋에 따라 더 받기도 합니다.
• 한 룰에 재정의 태그가 여럿이면 목록의 마지막 태그를 따릅니다.
• 관리형 룰셋 ID 는 Managed Rules 문서에 있습니다.

PUT 은 룰 목록 전체를 바꾸니 skip 룰과 다른 실행 룰도 함께 넣습니다.

GET /zones/{zone_id}/rulesets/phases/http_request_firewall_managed/entrypoint

• 대시보드는 Security › Settings 의 Web application exploits 에서 봅니다.
• 프록시하지 않는(DNS only) 레코드의 트래픽은 관리형 룰이 못 봅니다.
• Enterprise 는 계정 단위 배포도 봅니다. 같은 단계에서 계정 단위가 먼저 평가됩니다.

같은 룰셋을 계정과 존 양쪽에 배포하지 않습니다. 두 번 평가되고, 존 예외가 계정 쪽 일치를 못 막습니다.

• Enterprise 전용이며 설정은 Super Administrator 만 합니다.
• 관리형 룰셋마다 켜고, 켠 뒤 걸린 요청부터 남습니다.
• Cloudflare 는 공개키만 저장하니 개인키를 잃으면 새 키로 다시 설정합니다.
• 같은 필드에 여러 룰이 걸리면 마지막 룰 기준으로 남습니다.

푸는 방법은 셋입니다.

• Security Events 에서 개인키를 넣어 브라우저 안에서
• 명령줄 도구 matched-data-cli 로
• Logpush 로그를 SIEM? 에 넣기 전 Worker 에서

• 1에 가까울수록 공격이고, 100 은 점수를 매기지 않은 요청입니다.
• 커스텀 룰과 요청 수 제한 룰의 조건식에 쓰며, 둘 다 관리형 룰보다 먼저 평가됩니다.
• 시작 기준은 cf.waf.score le 20, Business 는 cf.waf.score.class eq "attack" 입니다.
• 21~50(likely_attack)엔 정상 요청이 섞여 50 미만 전부 차단은 권하지 않습니다.
• Enterprise 는 Log 로 시작해 Managed Challenge 나 Block 으로 올립니다.

봇 점수와는 다릅니다. 공격 점수는 «공격의 변형인가», 봇 점수는 «자동화인가»를 봅니다.

진입점 룰셋은 목록 순서로 평가하고, skip 룰은 자기 뒤의 execute 룰만 건너뜁니다.

• PUT 할 때 예외(skip)를 실행 룰보다 앞에 둡니다.
• 존 단위 예외는 계정 단위 룰을 못 건너뛰니 계정 단위 예외를 씁니다.