Sorun, doğrudan veya dolaylı şekilde herhangi bir siber saldırıdan ya da kötü niyetli bir faaliyetten kaynaklanmamıştır. Bunun yerine, veritabanı sistemlerimizden birinin izin yapılandırmasında yapılan bir değişiklik, Bot Yönetimi sistemimizde kullanılan “özellik dosyasına” çok sayıda fazla giriş yazılmasına neden oldu. Bu özellik dosyası bu nedenle iki katına çıktı. Beklenenden büyük olan dosya daha sonra ağımızı oluşturan tüm makinelere dağıtıldı.

Ağ trafiğini yönlendiren yazılım, sürekli değişen tehdit ortamına karşı Bot Yönetimi sistemini güncel tutmak için bu dosyayı okur. Ancak söz konusu yazılımın dosya boyutu için tanımlanmış bir sınırı vardı ve bu sınır, iki katına çıkmış dosyayı karşılayamayacak kadar düşüktü. Bu durum, yazılımın hataya düşmesine yol açtı.

Başlangıçta, gözlemlediğimiz belirtiler nedeniyle bunun büyük çaplı bir DDoS saldırısı olduğu yönünde yanlış bir değerlendirme yapıldı. Ardından asıl sorun doğru şekilde tespit edilerek, büyümüş dosyanın yayılımı durduruldu ve önceki sürüm dosyası ile değiştirildi. Temel trafik, 17:30 itibarıyla büyük ölçüde normale döndü. Trafiğin kısa sürede geri gelmesi nedeniyle bazı sistemlerde oluşan aşırı yük, birkaç saat içinde giderildi. 20:06 itibarıyla Cloudflare üzerindeki tüm sistemler normal işleyişine dönmüştür.

Kesinti

Aşağıdaki grafik, Cloudflare ağı tarafından sunulan 5xx hata HTTP durum kodlarının hacmini göstermektedir. Normalde bu değer çok düşük olmalıdır ve kesintinin başlangıcına kadar da düşüktü. Grafikteki ani artış ve sonraki dalgalanmalar, sistemimizin yanlış özellik dosyasını yüklemesi nedeniyle başarısız olduğunu gösterir.

Dikkat çekici olan, sistemlerin bir süre sonra toparlanmasıydı. Bu, dahili bir hata için çok sıra dışı bir davranıştı. Bunun açıklaması, dosyanın, izin yönetimini iyileştirmek için kademeli olarak güncellenen bir ClickHouse veritabanı kümesinde çalışan bir sorgu tarafından her beş dakikada bir oluşturuluyor olmasıydı. Kötü veri, yalnızca kümenin güncellenmiş bir kısmında sorgu çalıştırılırsa oluşuyordu.

Sonuç olarak, her beş dakikada bir, iyi veya kötü bir dizi yapılandırma dosyasının oluşturulması ve hızla ağa yayılması şansı vardı. Bu dalgalanma, bazen iyi bazen kötü yapılandırma dosyaları ağımıza dağıtıldığı için tüm sistemin kurtulup tekrar başarısız olması nedeniyle ne olduğunu anlamayı zorlaştırmıştır. Başlangıçta bu, bunun bir saldırıdan kaynaklanabileceği düşüncesine yol açtı.

Sonunda, her ClickHouse düğümü kötü yapılandırma dosyasını oluşturuyordu ve dalgalanma başarısız durumda stabilize oldu. Temel sorun tespit edilip 17:30'dan itibaren çözülene kadar hatalar devam etti.

Sorunu, kötü özellik dosyasının oluşturulmasını ve yayılmasını durdurarak ve bilinen iyi bir dosyayı özellik dosyası dağıtım kuyruğuna manuel olarak yerleştirerek çözülmüştür. 20:06'da normale döndü.

Cloudflare İstekleri Nasıl İşler ve Bugün Neler Ters Gitti?

Cloudflare'a yapılan her istek temiz bir yok izler. İstekler önce HTTP ve TLS katmanında sonlanır, ardından temel proxy sistemiminde akar ve son olarak önbellek aramaları yapan veya gerekirse kaynaktan veri getiren Pingora'dan geçer. Bir istek temel proxy'den geçerken, ağda bulunan çeşitli güvenlik ve performans ürünlerini çalıştırılır.

Proxy, WAF kurallarını ve DDoS korumasını uygulamaktan trafiği Geliştirici Platformu ve R2'ye yönlendirmeye kadar her müşterinin benzersiz yapılandırmasını ve ayarlarını uygular. Bunu, yapılandırma ve politika kurallarını proxy'den geçen trafiğe uygulayan alana özgü bir dizi modül aracılığıyla gerçekleştirir.

Bu modüllerden biri olan Bot Yönetimi, bugünkü kesintinin kaynağıydı.

1. 1. Cloudflare'ın Bot Yönetimi, diğer sistemlerin yanı sıra, ağdan geçen her istek için bot puanları oluşturmak üzere kullanılan bir makine öğrenimi modelini içerir.
   2. Model, girdi olarak bir "özellik" yapılandırma dosyası alır. Özellik, makine öğrenimi modelinin isteğin otomatik olup olmadığına dair bir tahminde bulunmak için kullandığı bireysel bir özelliktir.
   3. Bu özellik dosyası, her birkaç dakikada bir yenilenir ve tüm ağda  yayınlanır.
   4. Temel ClickHouse sorgu davranışlarındaki  bir değişiklik, bu dosyanın çok sayıda yinelenen "özellik" satırı içermesine neden oldu.
   5. Bu, daha önce sabit boyutlu olan özellik yapılandırma dosyasının boyutunu değiştirdi ve Botlar modülünün bir hatayı tetiklemesine neden oldu.
   6. Sonuç olarak, müşteriler için trafik işlemeyi yöneten temel proxy sistemi, Botlar modülüne bağlı olan herhangi bir trafik için HTTP 5xx hata kodları döndürdü. Bu durum, temel proxy'ye dayanan Workers KV ve Access'i de etkiledi.

Her iki sürüm de sorundan etkilendi, ancak gözlemlenen etki farklıydı:

1. 1. Yeni FL2 proxy motorunda dağıtılan müşteriler, HTTP 5xx hataları gözlemledi.
   2. Eski FL proxy motorundaki müşteriler hata görmedi, ancak bot puanları doğru şekilde oluşturulmadı, bu da tüm trafiğin sıfır bot puanı almasıyla sonuçlandı.
   3. Botları engellemek için kurallar dağıtan müşteriler, çok sayıda yanlış pozitif görmüş olmalıydı.
   4. Kurallarında bot puanı  kullanmayan müşteriler herhangi bir etki görmedi.

Bunun bir saldırı olabileceğine inanmamıza neden olan başka bir belirgin belirti daha vardı: Cloudflare'ın Durum sayfası çöktü. Durum sayfası, Cloudflare'ın altyapısından tamamen bağımsız olarak barındırılmaktadır. Bunun bir tesadüf olduğu ortaya çıksa da, sorunu teşhis eden ekibin bazı üyelerinin bir saldırganın hem sistemleri hem de durum sayfalarını hedef aldığına inanmasına yol açtı.

Olay Sırasındaki Diğer Etkiler

Temel proxy'e dayanan diğer sistemler de olay sırasında etkilendi. Buna Workers KV ve Cloudflare Access de dahildi.

1. 1. Ekip, 16:04'te Workers KV'ye temel proxy'yi atlamak için bir yama yapıldığında bu sistemler üzerindeki etkiyi azaltabildi.
   2. Daha sonra, Workers KV'ye dayanan tüm alt sistemler (Access dahil) azaltılmış bir hata oranı gözlemledi.

Cloudflare Panosu (Dashboard) da hem Workers KV'nin dahili olarak kullanılması hem de oturum açma akışının bir parçası olarak Cloudflare Turnstile'ın dağıtılması nedeniyle etkilendi. Turnstile bu kesintiden etkilendi, bu da aktif bir pano oturumu olmayan müşterilerin oturum açamamasına neden oldu.

1. 1. İlk dönem (14:30 - 16:10), bazı kontrol düzlemi ve pano işlevlerinin dayandığı Workers KV üzerindeki etkiden kaynaklandı. Bu, Workers KV'nin temel proxy sistemini atladığı 16:10'da restore edildi.
   2. Panoya yönelik ikinci etki dönemi, özellik yapılandırma verilerinin restore edilmesinden sonra meydana geldi. Geriye dönük oturum açma girişimleri panoyu bunaltmaya başladı.
   3. Bu birikim, yeniden deneme girişimleriyle birleşince gecikmeyi artırdı ve pano kullanılabilirliğini azalttı. Kontrol düzlemi eşzamanlılığını ölçeklendirmek, kullanılabilirliği yaklaşık 18:30'da restore etti.

Peki bir daha yaşanmaması için geliştirme adımları neler oldu ?

1. 1. Cloudflare tarafından oluşturulan yapılandırma dosyalarının, kullanıcı girdileriyle aynı seviyede sağlamlaştırılması.
   2. Daha geniş kapsamlı global kapatma (kill switch) mekanizmaları eklenmesi.
   3. Hata raporlarının veya çekirdek dökümlerinin sistem kaynaklarını aşırı tüketmesini engellemek.
   4. Tüm proxy modüllerinin hata koşullarındaki davranışlarının gözden geçirilmesi.

Bu makaledeki bazı bilgiler Cloudflare’ın kamuya açık teknik dökümantasyonundan derlenmiştir.