Cloudflare / web-application-firewall

Always-on detections: eliminating the WAF “log versus block” trade-off (새 탭에서 열림)

Cloudflare는 기존 WAF의 고질적인 문제인 '로그와 차단 사이의 절충(log versus block trade-off)'을 해결하기 위해 새로운 '상시 가동 탐지(Always-on detections)' 시스템을 도입했습니다. 이 기술은 탐지와 대응을 분리하여 모든 요청에 대해 실시간으로 보안 메타데이터를 생성하며, 이를 통해 성능 저하 없이 보안 가시성을 극대화합니다. 결과적으로 보안 팀은 오탐 걱정 없이 신속하게 차단 정책을 수립하고, 향후 요청과 응답을 모두 분석하는 '전체 트랜잭션 탐지'로 진화할 수 있는 기반을 마련하게 되었습니다. ### 기존 WAF의 한계와 상시 가동 프레임워크 * **로그와 차단의 딜레마:** 기존 WAF는 오탐을 피하기 위해 먼저 로그 전용 모드에서 긴 시간 수동 튜닝을 거쳐야 했으며, 차단 모드에서는 특정 규칙이 발동되면 분석이 중단되어 다른 잠재적 위협에 대한 가시성을 잃는 문제가 있었습니다. * **탐지와 대응의 분리:** 새로운 프레임워크는 모든 요청에 대해 공격 시그니처 탐지를 상시 가동(Always-on)합니다. 탐지 결과는 메타데이터 형태로 요청에 부착되어 보안 분석 및 규칙 엔진에서 활용됩니다. * **지연 시간 최적화:** 차단 규칙이 설정되지 않은 경우 탐지 프로세스는 요청이 원본 서버로 전달된 후 실행되도록 설계되어 서비스 성능에 영향을 주지 않습니다. 차단 규칙 적용 시에만 인라인(In-line) 방식으로 전환되어 효율성을 극대화합니다. ### 공격 시그니처 탐지(Attack Signature Detection)의 기술적 구성 * **다양한 공격 벡터 커버리지:** SQL 삽입(SQLi), 교차 사이트 스크립팅(XSS), 원격 코드 실행(RCE) 및 특정 CVE(취약점)를 타겟팅하는 700개 이상의 관리형 규칙을 활용합니다. * **신뢰도(Confidence) 시스템:** 각 시그니처는 '높음(High)'과 '중간(Medium)' 신뢰도로 분류됩니다. '높음'은 오탐 가능성이 낮아 즉시 차단에 적합하며, '중간'은 실제 트래픽 환경에 따른 추가 검토가 권장됩니다. * **보안 규칙 필드 제공:** `cf.waf.signature.request.confidence`, `categories`, `ref` 등 3가지 주요 필드를 제공하여 사용자가 보안 분석 플랫폼에서 데이터를 확인하고 이를 기반으로 정교한 맞춤형 차단 정책을 수립할 수 있게 합니다. ### 전체 트랜잭션 탐지(Full-Transaction Detection)로의 진화 * **요청과 응답의 상관관계 분석:** 현재 개발 중인 이 기술은 수신되는 요청뿐만 아니라 그에 따른 서버의 응답까지 함께 분석하는 전체 HTTP 트랜잭션 탐지를 지향합니다. * **정교한 위협 식별:** 요청과 응답을 결합하여 분석함으로써 '반사형 SQL 삽입(Reflective SQLi)'이나 미세한 데이터 유출 패턴 등 요청만으로는 파악하기 어려운 위협을 효과적으로 찾아냅니다. * **오탐 감소:** 전체 맥락을 파악함으로써 기존 요청 기반 엔진보다 훨씬 낮은 오탐률을 구현하며, 서버의 잘못된 설정으로 인해 발생하는 보안 허점까지 포착할 수 있습니다. Cloudflare의 새로운 보안 모델을 활용하고자 한다면, 우선 '공격 시그니처 탐지'를 활성화하여 보안 분석 대시보드에서 트래픽 데이터를 축적하는 것이 좋습니다. 이를 통해 실제 위협 패턴을 파악한 뒤, 신뢰도가 높은 시그니처부터 단계적으로 차단 규칙을 적용하면 서비스 중단 없이 보안성을 최대로 높일 수 있습니다.

Toxic combinations: when small signals add up to a security incident (새 탭에서 열림)

보안 사고는 종종 단일한 대규모 공격이 아니라, 미세한 설정 오류와 비정상 신호들이 결합된 '독성 조합(Toxic Combinations)'을 통해 발생합니다. 개별적으로는 무해해 보이는 디버그 플래그 노출이나 관리자 페이지 접근 시도가 봇 트래픽 및 비정상적인 맥락과 결합될 때 시스템 침해나 데이터 유출의 결정적인 징후가 됩니다. 클라우드플레어는 이러한 개별 신호들을 통합 분석하여 단순한 요청 차단을 넘어 공격자의 의도와 잠재적 위협을 식별하는 새로운 보안 프레임워크를 제시합니다. ### 독성 조합의 정의와 식별 맥락 기본적인 보안 장비(WAF, API 보호 등)가 개별 요청의 위험도를 평가한다면, 독성 조합 탐지는 여러 신호 사이의 관계와 맥락을 분석합니다. * **봇 신호 분석:** 공격의 자동화 여부를 판단하기 위해 봇 점수(Bot Score)를 활용하며, 낮은 점수의 트래픽이 민감한 경로를 탐색하는지 확인합니다. * **민감 경로 결합:** `/admin`, `/debug`, `/metrics`, `/wp-admin` 등 관리자 권한이나 내부 정보가 노출될 수 있는 경로에 대한 요청을 집중 감시합니다. * **통계적 이상 징후:** 평소와 다른 지리적 접속(Geo jump), 동일한 행위를 반복하는 분산 IP(Rate-limit evasion), 예상치 못한 HTTP 상태 코드 발생 등을 분석합니다. * **설정 오류 식별:** 인증 헤더가 누락되었거나 세션 쿠키가 없는 상태에서 민감한 데이터에 접근하는 시도를 탐지합니다. ### 공격 단계별 분석 및 데이터 현황 클라우드플레어는 24시간 동안의 데이터를 분석하여 실제 공격이 이루어지는 과정을 세 단계로 구분했습니다. * **광범위한 탐색(Probing):** 분석 대상 호스트의 약 11%에서 관리자 페이지 접근 시도가 관찰되었으며, 이는 주로 워드프레스(WordPress) 환경에 집중되었습니다. * **독성 조합 필터링:** 탐색 시도 중 봇 신호와 특정 경로 접근이 결합된 사례를 추출한 결과, 워드프레스 제외 시 약 0.25%의 호스트가 실제 위험에 노출된 것으로 나타났습니다. * **도달 가능성 검증(Reachable):** 단순한 `200 OK` 응답이 실제 성공인지 확인하기 위해 리다이렉션이나 오설정으로 인한 허위 양성(False Positive)을 제거하여 실제 취약한 호스트를 선별합니다. ### 주요 위협 시나리오와 취약점 작은 신호들이 모여 형성되는 대표적인 보안 위협은 다음과 같습니다. * **관리자 엔드포인트 노출:** `/wp-admin`이나 서버 대시보드 스캔을 통해 무차별 대입 공격을 수행하거나, 특정 소프트웨어 버전의 CVE 취약점을 노린 타겟팅 공격으로 이어집니다. * **디버그 플래그 오용:** URL에 `?debug=true`와 같은 파라미터를 추가하여 기술 스택 정보, 환경 변수, 데이터베이스 쿼리 세부 내용을 탈취하려는 시도입니다. * **권한 및 접근 제어 위협:** 인증 헤더가 없는 상태에서 높은 ID 변동성(High ID churn)을 보이는 요청은 IDOR(부적절한 직접 객체 참조)를 통한 데이터 유출 가능성을 시사합니다. ### 보안 강화를 위한 실무 권장사항 * **통합 모니터링:** Cloudflare WAF와 봇 관리 기능을 결합하여 자동화된 스캐닝을 차단하고, Log Explorer를 통해 민감한 경로에 대한 비정상적인 성공 응답을 주기적으로 쿼리해야 합니다. * **디버그 모드 관리:** 운영 환경에서 불필요한 디버그 플래그가 활성화되어 있지 않은지 점검하고, 노출된 관리자 페이지에는 Zero Trust 인증이나 IP 화이트리스팅을 적용하십시오. * **맥락 기반 대응:** 단일 요청 차단에 그치지 않고, 특정 IP나 봇이 수행하는 일련의 행위 패턴을 분석하여 공격의 '의도'를 파악하는 방어 전략을 수립해야 합니다.

Google’s AI advantage: why crawler separation is the only path to a fair Internet (새 탭에서 열림)

구글은 검색 시장의 독점적 지위를 이용해 검색 인덱싱용 크롤러로 생성형 AI를 위한 데이터를 함께 수집하며, 이는 발행자(Publisher)들에게 선택권 없는 데이터 제공을 강요하는 결과를 초래하고 있습니다. 영국의 경쟁시장청(CMA)은 구글을 '전략적 시장 지위(SMS)' 사업자로 지정하고 규제를 검토 중이나, 진정한 공정성을 확보하기 위해서는 검색용 크롤러와 AI 학습용 크롤러를 법적으로 분리해야 합니다. 이러한 크롤러 분리만이 발행자가 검색 노출은 유지하면서도 AI의 무단 데이터 사용을 거부할 수 있게 하여, 건강한 디지털 생태계와 공정한 AI 경쟁 환경을 조성할 수 있는 유일한 길입니다. ### 영국 CMA의 구글 시장 지배력 지정과 규제적 배경 * **디지털 시장 경쟁 체제 도입**: 영국은 2024년 디지털 시장, 경쟁 및 소비자법(DMCC)을 시행하며, 검색 및 검색 광고 분야에서 90% 이상의 점유율을 가진 구글을 '전략적 시장 지위(SMS)' 사업자로 지정했습니다. * **법적 구속력 있는 규제**: 이번 지정으로 인해 CMA는 구글의 AI 개요(AI Overviews) 및 AI 모드와 같은 검색 생태계 전반에 대해 법적 구속력이 있는 행동 요구사항을 부과할 수 있는 권한을 갖게 되었습니다. * **발행자 보호의 필요성**: CMA는 발행자들이 구글 검색의 시장 지배력 때문에 자신의 콘텐츠가 AI 서비스에 활용되는 것을 알고도 크롤링을 허용할 수밖에 없는 구조적 한계를 인식하기 시작했습니다. ### 발행자의 딜레마와 검색·AI 크롤링의 결합 문제 * **거부권의 부재**: 발행자들은 웹사이트 트래픽과 광고 수익의 핵심인 구글 검색 결과에서 제외되는 것을 감당할 수 없기에, 구글의 크롤러(Googlebot)를 차단하지 못하는 실정입니다. * **수익 모델의 붕괴**: 구글은 검색 크롤링을 통해 확보한 데이터를 AI Overviews 등에 활용하여 사용자에게 직접 답변을 제공하며, 이는 발행자 사이트로의 트래픽 유입을 급감시키고 광고 기반 비즈니스 모델을 위협합니다. * **불공정 경쟁 우위**: 구글은 검색봇을 통해 사실상 무료로 대규모 데이터를 확보하는 반면, 다른 AI 기업들은 발행자와 데이터 사용료를 협상해야 하는 불리한 위치에 놓여 시장 왜곡이 발생합니다. ### 클라우드플레어 데이터를 통해 본 구글의 압도적 우위 * **압도적인 크롤링 규모**: 클라우드플레어의 관측 데이터에 따르면, 구글봇은 GPTBot보다 약 1.76배, PerplexityBot보다는 무려 167배나 더 많은 고유 URL에 접근하고 있습니다. * **차단율의 현격한 차이**: 발행자들은 다른 AI 크롤러(ClaudeBot, GPTBot 등)는 적극적으로 차단하거나 robots.txt로 제한하는 반면, 검색 노출을 위해 구글봇에 대해서는 거의 차단을 설정하지 않습니다. * **네트워크 점유율**: 구글봇은 클라우드플레어 네트워크 내 관측된 고유 URL의 약 8%를 크롤링하고 있으며, 이는 다른 어떤 검색 엔진이나 AI 봇보다 월등히 높은 수치입니다. ### 크롤러 분리: 공정한 인터넷을 위한 실질적 대안 * **선택권의 보장**: 구글이 검색 인덱싱용 크롤러와 AI 학습/추론용 크롤러를 별도로 운영하도록 강제해야 합니다. 이를 통해 발행자는 검색 트래픽은 유지하면서 AI의 데이터 활용만 선택적으로 거부할 수 있습니다. * **데이터 시장의 정상화**: 크롤러가 분리되면 구글 또한 다른 AI 기업들과 마찬가지로 양질의 데이터를 확보하기 위해 발행자와 공정한 가치 산정 및 보상 협상에 임해야 할 유인이 생깁니다. * **기술적 규제 필요성**: 단순한 robots.txt 정책 준수를 넘어, 웹 응용 프로그램 방화벽(WAF) 등을 통해 발행자가 각 목적별 크롤러를 기술적으로 독립 제어할 수 있는 환경이 마련되어야 합니다. 구글의 검색 독점력이 AI 시장의 독점으로 전이되는 것을 막으려면, 규제 당국은 '검색 노출'을 볼모로 잡은 구글의 통합 크롤링 관행을 즉시 중단시켜야 합니다. 크롤러 분리는 발행자의 권익 보호와 더불어 AI 산업 전반의 공정한 경쟁을 가능케 하는 필수적인 안전장치입니다.

How we mitigated a vulnerability in Cloudflare’s ACME validation logic (새 탭에서 열림)

Cloudflare는 최근 ACME(Automatic Certificate Management Environment) 검증 로직에서 특정 경로의 WAF(웹 애플리케이션 방화벽) 기능을 비활성화할 수 있는 취약점을 발견하고 패치했습니다. 이 결함은 `/.well-known/acme-challenge/*` 경로로 들어오는 요청을 처리하는 과정에서 발생했으며, 특정 조건에서 보안 필터링 없이 악의적인 요청이 원본 서버(Origin)에 도달할 수 있는 문제를 야기했습니다. 현재 모든 패치가 완료되어 고객의 추가 조치는 필요 없으며, 실제 악용 사례는 확인되지 않았습니다. ### ACME 프로토콜과 HTTP-01 챌린지 메커니즘 * ACME는 SSL/TLS 인증서의 발급, 갱신 및 취소를 자동화하는 프로토콜로, 도메인 소유권을 확인하기 위해 HTTP-01 챌린지 방식을 널리 사용합니다. * 인증 기관(CA)은 도메인 소유권을 확인하기 위해 특정 경로(`http://{customer domain}/.well-known/acme-challenge/{token value}`)에 토큰이 존재하는지 확인하는 요청을 보냅니다. * Cloudflare가 관리하는 인증서의 경우 해당 경로에 직접 응답하여 토큰을 제공하며, 만약 시스템에 등록되지 않은 토큰 요청일 경우 고객이 별도로 도메인 검증을 진행 중인 것으로 판단하여 요청을 원본 서버로 전달합니다. ### WAF 보안 기능을 무력화하는 논리적 결함 * 기존 시스템은 CA의 인증 시도가 WAF 규칙에 의해 차단되어 인증서 발급이 실패하는 것을 방지하기 위해, ACME 챌린지 경로에 대한 WAF 기능을 일시적으로 비활성화하도록 설계되었습니다. * 그러나 분석 결과, 요청된 토큰이 요청을 받은 현재 호스트 이름과 직접적인 연관이 없더라도, Cloudflare 시스템 내의 다른 존(Zone)에 존재하는 유효한 토큰이기만 하면 WAF가 비활성화되는 허점이 발견되었습니다. * 이로 인해 공격자가 특정 경로를 통해 보안 필터링을 우회하여 원본 서버에 직접 접근할 수 있는 취약한 상태가 노출되었습니다. ### 취약점 보완 및 패치 내용 * Cloudflare는 요청된 토큰이 해당 호스트 이름(Hostname)에 할당된 유효한 ACME HTTP-01 챌린지 토큰과 일치할 때만 보안 기능을 비활성화하도록 로직을 수정했습니다. * 이제 토큰의 유효성뿐만 아니라 호스트 이름과의 매칭 여부를 엄격하게 검증하여, 조건이 충족되지 않는 모든 요청은 정상적인 WAF 규칙의 통제를 받게 됩니다. * 이번 조치는 외부 보안 연구원의 제보를 통해 이루어졌으며, Cloudflare는 인프라의 투명성을 위해 해당 취약점의 상세 내용과 해결 과정을 공개했습니다. Cloudflare를 사용하는 고객은 별도의 설정 변경이나 조치를 취할 필요가 없으며, 현재 시스템은 해당 취약점으로부터 안전하게 보호되고 있습니다. 환경의 보안 강화를 위해 버그 바운티 프로그램 등을 통한 외부 협력을 지속하며 신속한 대응 체계를 유지하고 있습니다.