Saldırı Altındayım: Cloudflare “Under Attack” Modu Nasıl Açılır?

Site açılmıyor, sunucu yük ortalaması tavan yapmış, panelde CPU grafiği düz çizgi hâlinde en üstte duruyor ve ziyaretçi sayısı normalin onlarca katı. “DDoS saldırısı altındayım ne yapmalıyım” diye ararken karşınıza DDoS’un tanımını anlatan on tane yazı çıkıyor, ama hiçbiri şu anda hangi düğmeye basacağınızı söylemiyor. Alan adınız Cloudflare üzerindeyse o düğme var ve ücretsiz planda bile açık: Cloudflare under attack modu, tek tıkla tüm gelen isteklere tarayıcı doğrulaması koyar ve otomatik istek üreten trafiğin büyük kısmını sunucunuza hiç ulaştırmadan keser.

Bu yazı bir DDoS ansiklopedisi değil, saldırı anında yanınızda açık tutacağınız bir müdahale sırası. Sırasıyla şunları göreceksiniz: gerçekten saldırı altında mısınız yoksa sadece viral olmuş bir içeriğiniz mi var (ikisinin çözümü zıttır), saldırı modunun tam olarak ne yaptığı, panelden hangi ekrandan açıldığı, açtıktan sonraki ilk on dakikada yapılacaklar ve hiçbir Türkçe kaynakta anlatılmayan kısım: bu mod açıkken API isteklerinizin, ödeme sağlayıcınızın bildirim çağrılarının, mobil uygulamanızın ve arama motoru tarayıcılarının da aynı bekleme ekranına takıldığı — yani bu düğmenin kalıcı açık bırakılacak bir ayar olmadığı.

Önce Teşhis: Gerçekten Saldırı mı, Yoğun Trafik mi#

Saldırı ile organik yoğunluğu ayırt etmenin en hızlı yolu, isteklerin dağılımına bakmaktır; sayısına değil. Gerçek trafik çeşitlidir: farklı sayfalar, farklı ülkeler, farklı tarayıcılar, referans kaynakları var. Saldırı tekdüzedir: aynı yol, aynı User-Agent, referans yok, oturum yok.

Sunucuya SSH ile girebiliyorsanız dört komut yeterlidir; sırasıyla yük ortalamasını, eşzamanlı bağlantı sayısını, en çok dövülen yolları ve baskın User-Agent'ı verirler:

uptime
ss -Hnt state established '( sport = :443 or sport = :80 )' | wc -l
tail -n 5000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -15
tail -n 5000 /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -10

⚠️ Cloudflare zaten aktifse birinci sütundaki IP adresleri sizin ziyaretçileriniz değil, Cloudflare uç sunucularıdır. Gerçek IP’yi görmek için sunucunuzda gerçek IP başlığını çözmeniz gerekir; Nginx tarafında bu şu şekilde yapılır (Cloudflare'in yayımladığı IP bloklarının tamamı set_real_ip_from satırlarıyla eklenmelidir) ve saldırı öncesinde tamamlanmış olması gereken bir hazırlıktır:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header CF-Connecting-IP;

log_format cf '$http_cf_connecting_ip - $remote_user [$time_local] '
              '"$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';

Sunucuya hiç giremiyorsanız teşhisi Cloudflare panelinden yapın: Analytics & Logs → Traffic ekranında istek grafiği dikey bir duvara dönüşmüşse ve Security → Events ekranında engellenen istek sayısı patlamışsa cevap nettir. Saldırının türlerini ve neyi hedeflediklerini merak ediyorsanız DDoS saldırısı nedir yazısı arka planı verir; ama önce müdahaleyi yapın, okumayı sonraya bırakın.

Bir uyarı: sitenizin yavaşlamasının sebebi her zaman saldırı değildir. Tek bir ağır sorgu, bozuk bir cron görevi ya da paket limitinize dayanmış olmanız da aynı belirtileri verir. Trafik grafiğinde anormal bir yükselme yoksa sorun trafikte değildir; saldırı modunu açmak o durumda hiçbir şeyi düzeltmez, sadece ziyaretçilerinizi yorar.

Under Attack Modu Tam Olarak Ne Yapar#

Under Attack modu, Cloudflare’in güvenlik seviyesi (Security Level) ayarının en üst kademesidir ve açıldığı anda alan adınıza gelen her isteğe bir JavaScript sorgulaması koyar. Ziyaretçi sayfayı istediğinde önce Cloudflare’in ara ekranı gelir, tarayıcı arka planda küçük bir hesaplama yapar, doğrulama başarılıysa ziyaretçiye bir doğrulama çerezi (cf_clearance) verilir ve asıl sayfaya geçilir. Bu doğrulama yaklaşık beş saniye sürer ve çerez geçerli olduğu sürece tekrarlanmaz.

Bunun neden işe yaradığı önemli: saldırı trafiğinin çok büyük kısmı JavaScript çalıştıramayan basit istemcilerden gelir — betikler, kütüphaneler, ele geçirilmiş cihazlardaki minimal HTTP istemcileri. Bu istemciler doğrulamayı geçemez, sunucunuza hiç ulaşamaz ve yükü Cloudflare’in kendi ağında kalır.

Güvenlik seviyeleri arasındaki fark şudur:

Tablodaki son satırın “herkese, ayrım yapmadan” kısmı bu yazının çekirdeğidir. Mod, kötü niyetli isteği iyisinden ayırt etmeye çalışmaz; ayırt edemediği için hepsine aynı testi uygular. Bu, saldırı anında doğru bir tercihtir ve saldırı bittikten sonra yanlış bir tercihe dönüşür.

Saldırı Modu Nasıl Açılır: Adım Adım#

1. Cloudflare hesabınıza girin ve saldırı altındaki alan adını seçin.
2. Sol menüden Security → Settings bölümüne gidin. (Panel sürümüne göre bu ayar Overview ekranının sağ üstünde “Under Attack Mode” anahtarı olarak da bulunabilir.)
3. Security Level ayarını I’m Under Attack seçeneğine getirin.
4. Değişiklik uç sunuculara saniyeler içinde yayılır; yeni sekmede sitenizi açıp bekleme ekranını gördüğünüzde mod aktiftir.
5. Sunucunuzun yük ortalamasını izleyin. Düşüş genellikle bir-iki dakika içinde başlar.

Alan adınızın Cloudflare üzerinden geçtiğinden emin olun: DNS kayıtlarının yanındaki bulut simgesi turuncu olmalıdır. Gri bulut “sadece DNS” demektir; o kayıt için trafik doğrudan sunucunuza gider ve saldırı modunun hiçbir etkisi olmaz. Bu, saldırı anında en sık yapılan hatadır — mod açılır, saldırı devam eder, çünkü hedeflenen alt alan adı gri buluttadır. Alan adının tüm kayıtlarını tek tek gözden geçirin: www, kök kayıt, api, mail ve varsa panel alt alan adları.

Modu tüm site yerine sadece saldırı alan yola uygulamak da mümkündür ve çoğu zaman daha akıllıcadır. Panelde Rules → Configuration Rules bölümünden bir kural oluşturup, örneğin sadece /wp-login.php ve /xmlrpc.php isteklerinde güvenlik seviyesini yükseltebilirsiniz. Böylece ana sayfanız normal hızda açılmaya devam eder.

Açtıktan Sonraki İlk On Dakika#

Saldırı modu ateşi düşürür, hastalığı iyileştirmez. Nefes aldığınız anda şu sırayı uygulayın:

1. Saldırının hedefini belirleyin. Cloudflare’de Security → Events ekranını açın, kaynak ülkeye, ASN’ye, User-Agent’a ve istenen yola göre gruplayın. Genelde tek bir yol (/, /?s=, /wp-login.php, bir arama sayfası) ezici çoğunluğu oluşturur.
2. Hedefe özel kural yazın. WAF bölümünde özel kural oluşturup o desene doğrudan engelleme ya da yönetilen doğrulama uygulayın. Örneğin belirli bir ASN’den gelen ve arama parametresi taşıyan istekleri engellemek, tüm siteyi doğrulamaya sokmaktan çok daha az yan etki üretir.
3. Hız limiti koyun. Aynı IP’den dakikada belirli sayının üzerinde istek gelmesini sınırlayın. Sunucu tarafında da aynısını yapabilirsiniz; Nginx hız limitleme ve güvenlik başlıkları yazısı bu yapılandırmayı adım adım anlatır. İki katmanı birlikte kullanmak, Cloudflare’i aşan trafik için sigorta olur.
4. Önbelleği agresifleştirin. Sayfa önbelleklemesi açık olan bir sitede saldırı isteklerinin çoğu Cloudflare’den yanıtlanır, sunucunuza hiç düşmez. Statik bir sayfa için “Cache Everything” kuralı, saldırı süresince ciddi kazanç sağlar.
5. Sunucuyu kontrol edin. Yük düştü mü? PHP-FPM süreçleri normale döndü mü? Veritabanı bağlantı sayısı azaldı mı? Düşmediyse trafik Cloudflare’i baypas ediyor demektir — sunucunuzun gerçek IP adresi sızmış olabilir. Bu durumda güvenlik duvarınızı sadece Cloudflare IP bloklarına açık hâle getirin.

Son madde, insanların en çok atladığı maddedir. Sunucunuzun kaynak IP adresi biliniyorsa saldırgan Cloudflare’i tamamen atlar ve doğrudan sunucuya vurur. Kalıcı çözüm, 80 ve 443 portlarını yalnızca Cloudflare aralıklarına açmaktır. Aşağıdaki örnekte önce Cloudflare bloklarına izin verilir, ardından son satırla genel erişim kapatılır — tüm blokları eklemeden son satırı çalıştırmayın, yoksa sitenizi tamamen erişilmez yaparsınız:

ufw allow from 173.245.48.0/20 to any port 443 proto tcp
ufw allow from 103.21.244.0/22 to any port 443 proto tcp
ufw delete allow 443/tcp

Under Attack Modunun Yan Etkileri#

Bu bölüm, saldırı modunu açanların büyük kısmının sonradan öğrendiği kısımdır: bekleme ekranı sadece insan ziyaretçilere değil, tarayıcı olmayan her istemciye çıkar. JavaScript çalıştıramayan her istemci doğrulamayı geçemez ve sizin açınızdan “çalışmıyor” hâline gelir.

Cloudflare, tanıdığı arama motoru tarayıcılarını genellikle ayırt eder; ama bu bir garanti değildir ve entegrasyonlarınızın hiçbiri bu ayrıcalığa dahil değildir. Bu yüzden saldırı modunu açtıktan hemen sonra şu üç muafiyeti tanımlamak neredeyse her zaman gerekir:

1. Ödeme/banka bildirim yolları (/odeme/bildirim, /callback/... gibi).
2. Uygulama API kökü (/api/*).
3. Sizin kendi sunucularınızın IP adresleri.

Bunlar Security → WAF → Custom rules altında “Skip” eylemiyle, ilgili yol veya IP eşleşmesi verilerek yazılır. Muafiyet yazarken kapsamı olabildiğince dar tutun: bütün /wp-json/* yolunu muaf tutmak, saldırganın da o yolu kullanabileceği anlamına gelir.

Saldırı Modunu Ne Zaman Kapatmalısınız#

Saldırı modu geçici bir moddur ve trafiğin normale dönmesinden sonra kapatılmalıdır. Kalıcı açık bırakmak üç somut zarar üretir: her yeni ziyaretçi birkaç saniye bekler ve dönüşüm oranınız düşer, entegrasyonlarınız sessizce çalışmamaya devam eder, arama motorlarının tarama bütçesi doğrulama ekranlarında harcanır.

Kapatma kararı için pratik ölçüt: Cloudflare Security → Events ekranında engellenen istek grafiği saldırı öncesi seviyeye döndüyse ve sunucu yükü normale indiyse mod artık gereksizdir. Kapatmayı tek adımda değil, kademeli yapın:

1. Güvenlik seviyesini I’m Under Attack’tan High’a indirin.
2. Yarım saat bekleyin, yük grafiğini izleyin.
3. Sorun yoksa Medium seviyeye dönün.
4. Saldırı sırasında yazdığınız hedefe özel WAF kurallarını ve hız limitlerini kaldırmayın — asıl kalıcı korumanız onlardır.
5. Muafiyet kurallarını da bırakın; zararsızdırlar ve bir dahaki sefere hazır olurlar.

Saldırı tekrar başlarsa geri dönmek beş saniyelik bir iştir. Bu yüzden “ne olur ne olmaz açık kalsın” demeye gerek yoktur.

Saldırı Modu Yetmediğinde#

Bazı saldırılar JavaScript doğrulamasını geçebilen gerçek tarayıcı otomasyonlarıyla ya da doğrudan sunucu IP’nize yapılır. Bu durumda sıradaki adımlar şunlardır:

• Hedefe özel yönetilen doğrulama (Managed Challenge) ve engelleme kuralları. Ülke, ASN, User-Agent, istek yolu ve sorgu parametresi kombinasyonlarıyla saldırganın imzasını daraltın. Bot davranışlarının nasıl ayırt edildiğini CAPTCHA ve bot koruması yazısında bulabilirsiniz.
• Uygulama katmanı kuralları. SQL enjeksiyonu, dosya dahil etme ve yönetici paneli deneme saldırılarında isteğin gövdesine ve parametrelerine bakan bir güvenlik duvarı katmanı gerekir; saldırı modu bu tür istekleri içeriğine göre değil, istemcinin tarayıcı olup olmamasına göre eler.
• Sunucu IP’sini değiştirmek. IP sızdıysa ve saldırı doğrudan sunucuya geliyorsa, IP değişikliği + güvenlik duvarını yalnızca Cloudflare bloklarına açmak birlikte uygulanır. Yalnız IP değiştirmek geçici çözümdür.
• Ağ katmanı koruması. Uygulama seviyesinin altındaki hacim saldırıları (UDP/SYN sel) için koruma sunucunun kendi ağında olmalıdır; bu, hosting sağlayıcınızın altyapı seviyesindeki filtreleme kabiliyetiyle ilgilidir.

Saldırı sırasında sitenizde Cloudflare kaynaklı 520, 521 veya 522 hataları görmeye başlarsanız bu, uç sunucuların sizin sunucunuza ulaşamadığını söyler — yani saldırı modu açık olsa bile origin çökmüş demektir. Bu hataların tek tek anlamları için Cloudflare 520, 521 ve 522 hataları yazısına bakabilirsiniz.

Saldırı Bittikten Sonra: Kalıcı Hazırlık#

Bir saldırıyı atlatmanın gerçek kazancı, ikincisine hazırlıklı olmaktır. Saldırı bittikten sonraki hafta içinde şunları tamamlayın:

• Gerçek ziyaretçi IP’sinin sunucu kayıtlarına düşmesini sağlayın (yukarıdaki real_ip_header yapılandırması). Bunu yapmadan bir sonraki saldırıda kimin vurduğunu göremezsiniz.
• Güvenlik duvarını yalnızca Cloudflare aralıklarına açın ve bunu belgeleyin.
• Yönetici giriş yollarını (/wp-login.php, /administrator) kalıcı hız limitine alın.
• Statik içerik için önbellek kurallarını sıkılaştırın; önbellekten dönen her istek, saldırı anında sunucunuza düşmeyen bir istektir.
• Bir olay defteri tutun: saldırı ne zaman başladı, hangi yol hedeflendi, hangi kural işe yaradı. Bir sonraki sefer bu not, en değerli belgeniz olur.

Sıkça Sorulan Sorular#

Under attack modu ücretsiz Cloudflare planında var mı#

Evet, saldırı modu ücretsiz planda da kullanılabilir ve bu, onu Türkiye’deki küçük ve orta ölçekli siteler için en erişilebilir acil müdahale aracı yapar. Ayarın kendisi güvenlik seviyesinin bir kademesi olduğu için ek bir hizmet satın almanız gerekmez. Ücretli planlarda farklılaşan şey mod değil, yanına ekleyebileceğiniz gelişmiş bot yönetimi, daha esnek hız limitleri ve ayrıntılı kural sayısıdır. Yani acil durum düğmesi herkeste var, çevresindeki ince ayar araçları plana göre değişir.

Saldırı modu açıkken ziyaretçilerim ne görüyor#

Ziyaretçiler sayfaya girmeden önce Cloudflare’in kısa bir doğrulama ekranını görür ve bu ekran genellikle beş saniye civarında sürer. Doğrulama başarılı olduğunda tarayıcılarına bir doğrulama çerezi yazılır ve çerez geçerli olduğu sürece sonraki sayfalarda bekleme tekrar etmez. Yani bir ziyaretçi için maliyet oturum başına birkaç saniyedir, her tıklamada değil. Yine de ilk izlenimi bozduğu ve mobil bağlantılarda daha uzun hissettirdiği için modun süresiz açık bırakılması önerilmez.

Saldırı modunu açtım ama site hâlâ açılmıyor#

Bunun en yaygın üç sebebi vardır. Birincisi, saldırıya uğrayan DNS kaydının Cloudflare üzerinden geçmemesidir; kaydın yanındaki bulut simgesi gri ise trafik doğrudan sunucunuza gider ve mod hiçbir şey yapmaz. İkincisi, saldırganın sunucunuzun gerçek IP adresini bilmesi ve Cloudflare’i tamamen atlamasıdır; çözüm güvenlik duvarını yalnızca Cloudflare bloklarına açmaktır. Üçüncüsü, sunucunun saldırı sırasında zaten çökmüş olmasıdır — bu durumda Cloudflare 521 veya 522 hatası gösterir ve önce servislerinizi ayağa kaldırmanız gerekir.

Saldırı modu Google sıralamamı etkiler mi#

Kısa süreli kullanımda kayda değer bir etkisi olmaz, çünkü arama motorları geçici erişim zorluklarını tolere eder ve Cloudflare doğrulanmış tarayıcıları genellikle ayırt eder. Ancak mod günlerce açık kalırsa tarama sıklığı düşer, yeni içerikleriniz geç fark edilir ve büyük sitelerde tarama bütçesi verimsiz harcanır. Bu yüzden saldırı geçtikten sonra modu kapatmak, sadece kullanıcı deneyimi için değil arama görünürlüğü için de gereklidir. Uzun süreli koruma istiyorsanız doğru araç saldırı modu değil, hedefe özel WAF kuralları ve hız limitleridir.

API ve ödeme bildirimlerim saldırı modunda çalışır mı#

Hayır, hiçbir önlem almazsanız çalışmazlar ve bu, saldırı modunun en sinsi yan etkisidir. Ödeme sağlayıcısının bildirim çağrısı bir tarayıcı değildir, JavaScript doğrulamasını geçemez ve karşılığında HTML bir bekleme sayfası alır; sonuç olarak siparişler ödendi işaretlenmez. Aynı durum mobil uygulama istekleri, entegrasyonlar ve kesinti izleme servisleri için de geçerlidir. Çözüm, bildirim yollarını ve API kökünü WAF’ta “Skip” eylemiyle muaf tutmak, mümkünse muafiyeti sadece ilgili sağlayıcının IP aralığıyla sınırlamaktır.

Saldırı modunu ne kadar süre açık bırakmalıyım#

Saldırı trafiği normale dönene kadar, tipik olarak birkaç saatten uzun olmayacak şekilde açık bırakın. Cloudflare güvenlik olayları grafiğinde engellenen istek sayısının saldırı öncesi seviyeye inmesi kapatma sinyalidir. Kapatırken doğrudan normal seviyeye dönmek yerine önce “High” kademesine inip yarım saat gözlem yapın. Bu sırada saldırı sırasında yazdığınız hedefe özel kuralları ve hız limitlerini kaldırmayın; kalıcı korumanız onlardır, saldırı modu yalnızca kazandığınız zamandı.

Cloudflare olmadan saldırıyı durdurabilir miyim#

Kısmen, ama uygulama seviyesinin ötesine geçen hacim saldırılarında sunucu tarafı önlemler tek başına yetmez. Sunucuda hız limitleri, güvenlik duvarı kuralları ve otomatik IP engelleme araçlarıyla düşük yoğunluklu taciz trafiğini durdurabilirsiniz; bunlar zaten her sunucuda olması gereken temel yapılandırmalardır. Ancak gelen trafik ağ bant genişliğinizi doldurmaya başladığında paketler sunucunuza ulaşmadan önce filtrelenmelidir ve bu, hosting sağlayıcınızın altyapı seviyesinde sunduğu koruma ile çözülür. En sağlam kurulum, önde bir trafik filtreleme katmanı ile sunucu içindeki sıkı yapılandırmanın birlikte çalıştığı kurulumdur.

Saldırı sonrası hangi kayıtları saklamalıyım#

Saldırı süresince oluşan web sunucusu erişim kayıtlarını, güvenlik olayları dışa aktarımını ve sunucu kaynak grafiklerinin ekran görüntülerini saklayın. Bu üçü, saldırının hangi yolu hedeflediğini, hangi ağlardan geldiğini ve hangi kuralın etkili olduğunu sonradan analiz etmenizi sağlar. Kayıtlar aynı zamanda tekrarlayan bir saldırıda desen karşılaştırması yapmanıza ve kalıcı kuralları isabetli yazmanıza imkân verir. Ayrıca olayın zaman çizelgesini kısa bir not hâlinde tutmak, aynı senaryoyu bir yıl sonra yaşadığınızda en hızlı başvuru kaynağınız olur.

Kapanış#

Saldırı anında doğru refleks, kaynak araştırmak değil trafiği kesmektir. Cloudflare saldırı modu tam olarak bunu yapar: JavaScript çalıştıramayan istemcileri sunucunuza hiç ulaştırmadan eler ve size düşünecek zaman kazandırır. Ama kazandığı şey zamandır, çözüm değildir — o zaman içinde saldırının hedeflediği yolu bulup hedefe özel kural yazmanız, hız limiti koymanız ve sunucunuzun gerçek IP’sini kapatmanız gerekir. Ve mod, işi bittiğinde kapatılır: her yeni ziyaretçiye bekleme ekranı gösteren, API çağrılarınızı ve ödeme bildirimlerinizi sessizce düşüren bir ayar kalıcı bir yapılandırma olamaz.

Saldırı sizde tek seferlik bir olay değil de tekrarlayan bir durum hâline geldiyse, korumayı uygulama katmanının altına indirmek gerekir. Ağ seviyesinde filtrelenmiş bir altyapı için DDoS korumalı sunucu çözümlerimize, uygulama katmanındaki istekleri içeriğine bakarak eleyen bir katman için web uygulama güvenlik duvarı hizmetimize bakabilirsiniz. Kural yazma, güvenlik duvarı sıkılaştırma ve saldırı sonrası analiz gibi işleri kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmeti bu yükü devralır; kaynaklarınızın komşu hesaplardan etkilenmediği bir yapı arıyorsanız da VDS sunucu paketleri doğru başlangıç noktasıdır.