2025년 11월 18일 Cloudflare Global Network 오류(비교)

Cloudflare의 [[https://www.cloudflare.com/ko-kr/application-services/products/bot-management/|Bot Management]]에는, 그 외 여러 시스템과 함께, 네트워크를 통과하는 모든 요청에 대해 봇 점수(bot score)를 생성하는 머신러닝 모델이 포함되어 있습니다. 고객들은 이 봇 점수를 사용해 어떤 봇이 사이트에 접근할 수 있는지 제어합니다.

이 모델은 “feature” 구성 파일을 입력으로 사용합니다. 여기서 feature란 요청이 자동화된 것인지 아닌지를 판단하기 위해 머신러닝 모델이 사용하는 개별 특성을 말하며, feature 구성 파일은 이러한 개별 feature들의 모음입니다.

이 feature 파일은 몇 분마다 갱신되어 전체 네트워크에 배포되며, 인터넷 트래픽의 변동에 신속히 대응할 수 있게 해줍니다. 새로운 유형의 봇이나 공격에 빠르게 대응해야 하기 때문에, 이 파일은 자주 그리고 빠르게 배포되는 것이 매우 중요합니다.

그런데 이 파일을 생성하는 기반 ClickHouse 쿼리 동작이 변경되면서, feature 행이 중복되어 파일 크기가 증가했습니다. 이전에는 고정 크기였던 feature 파일이 커지면서, 봇 모듈에서 오류가 발생하게 된 것입니다.

As a result, HTTP 5xx error codes were returned by the core proxy system that handles traffic processing for our customers, for any traffic that depended on the bots module. This also affected Workers KV and Access, which rely on the core proxy.

Unrelated to this incident, we were and are currently migrating our customer traffic to a new version of our proxy service, internally known as FL2. Both versions were affected by the issue, although the impact observed was different.

Customers deployed on the new FL2 proxy engine, observed HTTP 5xx errors. Customers on our old proxy engine, known as FL, did not see errors, but bot scores were not generated correctly, resulting in all traffic receiving a bot score of zero. Customers that had rules deployed to block bots would have seen large numbers of false positives. Customers who were not using our bot score in their rules did not see any impact.

Throwing us off and making us believe this might have been an attack was another apparent symptom we observed: Cloudflare’s status page went down. The status page is hosted completely off Cloudflare’s infrastructure with no dependencies on Cloudflare. While it turned out to be a coincidence, it led some of the team diagnosing the issue to believe that an attacker may be targeting both our systems as well as our status page. Visitors to the status page at that time were greeted by an error message:

[[파일:클플 오류5.png]]

내부 사고 채팅방에서는, 이번 문제가 최근 발생한 대규모 [[https://blog.cloudflare.com/defending-the-internet-how-cloudflare-blocked-a-monumental-7-3-tbps-ddos/|Aisuru DDoS]] 공격의 연장일 수 있다는 우려가 있었습니다.

[[파일:클플 오류6.png]]

{{{+5 쿼리 동작 변경}}}

앞서 언급했듯, 기본 쿼리 동작 변경으로 인해 feature 파일에 중복된 행이 많이 포함되게 되었습니다. 문제의 데이터베이스 시스템은 ClickHouse 소프트웨어를 사용합니다.

참고로, ClickHouse 분산 쿼리가 어떻게 작동하는지 이해하면 도움이 됩니다. ClickHouse 클러스터는 여러 샤드(shard)로 구성됩니다. 모든 샤드에서 데이터를 쿼리하려면, default라는 데이터베이스에 있는 “Distributed” 엔진 기반의 분산 테이블을 사용합니다. Distributed 엔진은 r0 데이터베이스의 기본 테이블을 쿼리하는데, 이 기본 테이블이 각 ClickHouse 샤드에 데이터가 실제로 저장되는 곳입니다.

Distributed 테이블에 대한 쿼리는 공유 시스템 계정을 통해 실행됩니다. 분산 쿼리의 보안과 신뢰성을 개선하기 위한 노력의 일환으로, 향후에는 초기 사용자 계정으로 쿼리를 실행하도록 작업이 진행되고 있습니다.

오늘 이전에는, ClickHouse 사용자가 시스템 테이블(system.tables, system.columns 등)을 통해 테이블 메타데이터를 쿼리할 때 default 데이터베이스의 테이블만 볼 수 있었습니다.

사용자들이 이미 r0 기본 테이블에 암묵적으로 접근할 수 있었기 때문에, 11:05에 이 접근을 명시적으로 허용하도록 변경했습니다. 이를 통해 사용자가 해당 테이블의 메타데이터도 볼 수 있게 되었고, 모든 분산 서브쿼리가 초기 사용자 계정에서 실행되도록 하여, 쿼리 제한과 접근 권한을 더 세밀하게 평가할 수 있게 되었습니다. 이렇게 하면 한 사용자의 잘못된 서브쿼리가 다른 사용자에게 영향을 미치는 것을 방지할 수 있습니다.

하지만 이 변경으로 인해, 이전에는 “default” 데이터베이스만 포함될 것이라고 가정했던 쿼리 결과가 이제 모든 사용자가 접근할 수 있는 정확한 테이블 메타데이터를 반환하게 되었습니다.

{{{SELECT

name,

type

FROM system.columns

WHERE

table = 'http_requests_features'

order by name;}}}

쿼리가 데이터베이스 이름을 필터링하지 않는 점에 주목해야 합니다. ClickHouse 클러스터 사용자들에게 명시적 권한을 점진적으로 적용하는 과정에서, 11:05 변경 이후 위 쿼리는 r0 데이터베이스에 저장된 기본 테이블 때문에 컬럼이 “중복”되어 반환되기 시작했습니다.

안타깝게도, 이 쿼리는 Bot Management의 feature file 생성 로직에서 각 입력 “feature”를 구성하는 데 사용되는 쿼리 유형이었습니다.

위 쿼리는 (단순화한 예시처럼) 컬럼 테이블을 반환하게 됩니다.

[[파일:클플 오류7.png]]

하지만 사용자에게 추가 권한을 부여한 결과, 이제 쿼리 응답에는 r0 스키마의 모든 메타데이터가 포함되게 되었고, 그로 인해 응답 행 수가 사실상 두 배 이상 늘어나 최종 파일 출력에서 feature 수에도 영향을 미쳤습니다.