Cloudflare Brotli WAF, 켜져 있어도 자동 차단은 아니다
10월 25일 Brotli 긴급 WAF 규칙이 추가된 뒤 Next.js 사이트의 정상 상품 이미지가 막히기 시작했다. 기본값은 기록만 한다는데 내 사이트에서는 왜 차단이 걸릴까?
- Cloudflare가 10월 25일 발표한 Brotli 관련 긴급 규칙 두 개는 기본적으로 Log를 사용한다.
- 탐지 조건에는 정상 요청도 포함되므로, 일치 기록만으로 공격이라고 단정할 수 없다.
- 기존 Block 덮어쓰기가 새 규칙에 적용될 수 있어 개별 규칙의 실제 동작을 확인해야 한다.
규칙이 켜졌다는 사실만으로 요청이 막히지는 않는다
Cloudflare의 10월 25일 긴급 WAF 릴리스는 Brotli 취약점 CVE-2026-111497에 대응하는 두 규칙을 제시했다. 기본값은 요청을 기록하는 Log다. 활성화된 규칙에 요청이 일치해도 이 액션 자체는 차단하지 않는다.
운영자가 확인할 것은 활성화 스위치와 실제 액션 두 가지다. 기본값을 쓰는지, 기존 설정이 다른 액션을 적용하는지에 따라 같은 규칙의 결과가 달라진다.
Next.js 규칙은 정상 이미지 최적화 요청에도 일치한다
두 규칙은 정상 트래픽도 포착할 수 있는 조건을 사용한다. 따라서 일치 건수는 곧 공격 횟수가 아니다.
| 규칙 | 일치하는 요청 | Block으로 바꿀 때 영향 |
|---|---|---|
| Brotli 요청 본문 | Content-Encoding: br를 선언한 요청이다. | 정상적인 Brotli 압축 본문도 거부될 수 있다. |
| Next.js 이미지 경로 | /_next/image 이미지 최적화 요청이다. | 정상 이미지가 로드되지 않을 수 있다. |
첫 규칙은 Accept-Encoding: br에 일치하는 규칙이 아니다. Cloudflare의 응답 Brotli 압축 설정에도 영향을 주지 않는다. 요청 본문의 압축 형식과 응답에서 사용할 압축 형식을 혼동해 사이트의 압축 설정부터 바꾸면 대응 대상이 어긋난다.
예전에 지정한 Block이 새 규칙에도 적용될 수 있다
관리 규칙 덮어쓰기는 규칙 집합 전체, 태그, 개별 규칙 수준에서 설정할 수 있다. 규칙 집합·태그 설정은 나중에 추가되는 규칙에도 적용되며, 개별 규칙 설정이 더 넓은 범위의 설정보다 우선한다.
Cloudflare도 이번 릴리스에서 기존 규칙 집합의 Block 덮어쓰기가 새 탐지에 적용되면 배포 직후부터 정상 트래픽을 막을 수 있다고 알렸다. ‘기본값이 Log’라는 발표와 실제 서비스의 Block 동작이 동시에 성립할 수 있는 이유다.
대시보드에서는 Security rules의 Cloudflare Managed Ruleset을 열고 Browse rules에서 해당 규칙의 액션을 확인한다. 기록을 보며 영향을 평가하려면 개별 규칙에 Log를 지정하는 방법이 있다. 전체 WAF를 끄는 방식보다 대상 규칙과 적용 범위를 먼저 좁힐 수 있다.
일치 기록에서는 경로와 실제 액션을 함께 읽는다
Security Events는 Cloudflare가 조치하거나 표시한 요청의 이벤트를 보여 준다. 이미지가 안 뜨기 시작했다면 해당 시간대의 경로와 액션을 좁혀 보는 것이 점검 순서다. /_next/image에 Block이 적용된 기록과 브라우저에서 실패한 요청을 대조하면 WAF가 관련됐는지 판단할 근거를 얻을 수 있다.
다만 Sampled logs는 전체 이벤트를 항상 보여 주지 않는다. 샘플링된 목록에 특정 요청이 없다는 이유만으로 차단이나 공격이 전혀 없었다고 결론 낼 수는 없다. 범위를 좁혀 다시 확인할 필요가 있다.
WAF 설정과 영향받는 소프트웨어의 업데이트도 별도로 진행해야 한다. Node.js 보안 공지는 조작된 Brotli 데이터를 풀 때 발생하는 런타임 디코더 결함과 수정 배포를 설명한다. 요청을 기록하거나 거부하는 설정이 디코더 코드 자체를 고치지는 않는다. 필요한 차단 범위를 정하면서 실제 서비스의 보안 업데이트까지 마쳐야 한다.