공격 요청은 통과했는데, 응답에서 막을 수 있을까? Cloudflare WAF의 새 방어선

공격으로 의심되는 요청이 서버에 도착했다고 해서 정보가 유출됐다고 단정할 수는 없습니다. 반대로 요청이 평범해 보여도 서버가 민감한 내용을 돌려줄 수 있습니다. Cloudflare가 10월 21일 발표한 WAF 확장은 이 사이를 살펴봅니다. 요청과 응답을 함께 분석하고, 필요한 경우 응답을 사용자에게 보내기 전에 차단하는 방식입니다. 다만 서버에서 이미 실행된 작업을 되돌리는 기능은 아닙니다.

들어오는 요청에서, 나가는 응답까지

웹 방화벽인 WAF는 요청을 살펴보고 차단 여부를 판단합니다. 이번에 추가된 full transaction detection은 서버가 무엇을 반환했는지도 판단에 보탭니다. 탐지와 조치는 별개입니다. 탐지 결과를 확인한 뒤 응답 규칙이 차단하도록 구성할 수 있습니다.

Cloudflare 공식 발표에 따르면 Cloudflare 프록시를 사용하는 도메인(존)에 정식 제공되며 Free 요금제도 포함됩니다. 모든 고객이 만들 수 있는 사용자 정의 응답 규칙은 최대 세 개이고, Log와 Block 조치를 지원합니다. 다만 응답 본문을 조건으로 직접 규칙을 작성하는 기능은 아직 제공되지 않습니다. 유료 고객이 사용자 정의 응답 규칙에서 활용할 탐지 결과 필드는 순차 적용 중이므로, 발표에 나온 항목이 자신의 계정에 모두 보이는지 따로 확인해야 합니다.

Cloudflare가 함께 공개한 php2shell 대응 설명은 이 기능의 첫 관리형 탐지가 해당 취약점 대응에 쓰였다고 밝혔습니다. 다만 이런 보호가 있어도 PHP 보안 업데이트는 해야 한다고 명시했습니다. 특정 취약점의 기본 보호가 배포됐다는 설명과 모든 사용자 정의 응답 규칙이 자동 활성화된다는 주장은 구분해야 합니다.

차단됐다는 말 뒤에 남는 일

VECTORLOG가 주목하는 부분은 방어 기능의 개수보다 사고를 판단하는 순서입니다. 요청 차단, 서버의 처리, 응답 차단은 서로 다른 지점에서 일어납니다. 마지막 단계에서 응답을 막았다는 사실만으로 앞선 처리까지 안전했다고 결론 내리면 안 됩니다.

예를 들어 운영자가 응답 차단 기록을 발견했다면, 차단 횟수를 보고 끝낼 것이 아니라 같은 시점의 서버 기록과 해당 경로의 권한을 함께 살펴보는 편이 낫습니다. 무엇이 실행됐고 어떤 정보가 반환되려 했는지를 구분해야 다음 조치가 정해지기 때문입니다. 이는 새 기능의 성능을 직접 시험한 결과가 아니라, 발표된 작동 범위에서 도출한 운영상의 판단입니다.

규칙을 늘리기 전에 확인할 것

우선 실제 서비스 트래픽이 Cloudflare 프록시를 통과하는지, Security > Security Rules에 응답 단계의 설정이 제공되는지 확인합니다. 이어 탐지 기록을 읽고 적용 경로를 좁혀 정상 기능이 막히지 않는지 검토할 필요가 있습니다. 회사 사이트라면 관리자 화면뿐 아니라 로그인·문의·주문처럼 끊기면 업무에 영향을 주는 흐름도 함께 살펴볼 대상입니다.

보안 패치와 서버 권한 점검은 별도의 과제로 남습니다. 이번 변화는 요청 검사에 응답 확인을 더하는 것이지, 취약점이 있는 서버를 그대로 운영해도 된다는 뜻이 아닙니다. 새로운 차단 기능을 켰는가보다, 차단이 발생했을 때 무엇을 확인하고 고칠 것인가를 먼저 정해 두는 편이 실무에 도움이 됩니다.

탐지 신호와 실제 조치를 구분하는 관점은 Cloudflare Precursor Monitor 모드에서 살펴본 운영 기준과도 연결됩니다. 다만 그 글은 봇 점수 반영 전 관찰을, 이번 기능은 서버 응답의 탐지·차단을 다룹니다. 같은 설정으로 혼동하지 않는 것이 중요합니다.

기준일: 2026년 10월 22일. 직접 사용한 후기가 아니라 공식 발표를 바탕으로 정리한 News입니다.

VECTORLOG의 운영 관점에서는 응답 차단을 침해가 없었다는 증거가 아니라 피해 확산을 줄이는 추가 방어선으로 보는 편이 적절합니다. 차단 로그와 원본 서버의 실행·권한 기록을 함께 확인하고, 취약점 패치는 별도로 진행해야 합니다.