Cloudflare WAF, 서버 응답까지 막는다…무료 범위는?

서버가 돌려주는 내용도 방어 대상이 됐다

Cloudflare는 10월 21일 WAF의 full transaction detection과 응답 규칙을 정식 출시했다. 들어오는 요청뿐 아니라 원본 서버가 돌려주는 응답까지 연결해 살핀다. 적용 대상은 Cloudflare 프록시를 거치는 트래픽이다. 현재 관리형 탐지는 주요 취약점의 악용 여부를 확인하는 데 집중한다.

응답 차단의 시점은 서버가 요청을 처리한 뒤다. 민감한 내용이 요청자에게 전달되는 것을 막을 수 있지만, 원본 서버에서 이미 일어난 작업까지 되돌리지는 못한다.

앞단의 요청 차단도 계속 중요하다. Cloudflare의 실행 순서에서 요청 규칙이 Block처럼 처리를 끝내는 조치를 취하면 해당 요청은 뒤의 단계로 넘어가지 않는다. 요청 단계에서 멈추는 것과 서버 응답을 가로막는 것은 방어 시점이 다르다.

탐지 기록은 차단 완료 표시가 아니다

탐지는 위험 신호를 기록하고, 규칙은 그 신호에 어떤 조치를 할지 정한다. 기존 Attack Signature Detection도 신뢰도·분류·식별자 정보를 남기며 탐지 자체로 조치를 실행하지 않는다.

따라서 운영자는 ‘무엇에 일치했나’와 ‘무엇을 막았나’를 따로 봐야 한다. 같은 탐지 신호라도 기록만 하는 정책과 차단하는 정책의 결과는 다르다. 새 응답 기능 역시 탐지와 조치를 나눈 구조다.

무료도 규칙 3개, 본문 조건은 아직 불가하다

새 응답 기능의 공식 제공 범위는 다음과 같다. 기존 요청 규칙의 개수나 요금제 조건과 구별해야 한다.

응답 단계 설정은 Security → Security Rules 페이지 하단에 있다. 본문 조건을 직접 작성하지 못한다는 제한을 관리형 탐지가 응답 내용을 전혀 검사하지 못한다는 뜻으로 읽어서는 안 된다.

이벤트 수와 공격 요청 수를 같게 세면 안 된다

Security Events에서는 조치하거나 표시한 트래픽을 조사한다. 전체 유입 트래픽을 보려면 Security Analytics를 사용한다. 이벤트에는 어떤 조치가 실행됐고 어느 보안 기능이 관여했는지가 나타난다.

한 HTTP 요청이 여러 보안 기능에 걸리면 이벤트도 여러 개 생긴다. Sampled logs는 일부 이벤트만 보여줄 수 있고, 무료 요금제의 대시보드 기능은 이 표본 로그로 제한된다. 따라서 이벤트 세 줄을 서로 다른 공격 세 건으로 세거나, 목록에 없다는 이유로 해당 요청이 없었다고 결론 내리면 안 된다.

운영에 적용할 때는 Log로 조건에 걸리는 트래픽을 먼저 관찰하고, 이벤트의 조치와 서비스를 구분해 Block 적용 범위를 판단하는 편이 낫다. 탐지 건수를 늘리는 것보다 실제로 어떤 응답을 차단했는지 파악하는 것이 핵심이다.

자주 묻는 질문