Access log içindeki 404 istekleri ne zaman saldırı belirtisi olur?

Access log içinde görülen 404 kayıtları her zaman güvenlik olayı anlamına gelmez. Bir ziyaretçinin yanlış yazdığı URL, silinmiş bir sayfa, eski kampanya bağlantısı veya arama motoru botlarının güncel olmayan adresleri taraması 404 üretir. Ancak aynı hata kodu, zafiyet arayan otomatik botların ve saldırı araçlarının da en sık bıraktığı izlerden biridir. Bu nedenle önemli olan tekil 404 kaydı değil; isteğin yoğunluğu, deseni, kaynağı ve sunucu üzerindeki etkisidir.

Kurumsal bir web sitesinde 404 analizini doğru yapmak, hem güvenlik hem de operasyonel süreklilik açısından değerlidir. Özellikle hosting altyapısında kaynak tüketimi sınırlıysa, yoğun ve amaçlı 404 trafiği performansı etkileyebilir, gerçek kullanıcı isteklerini yavaşlatabilir veya daha büyük bir saldırının erken sinyali olabilir.

404 istekleri ne zaman normal kabul edilir?

404 hataları, erişilmek istenen dosya veya sayfanın sunucuda bulunmadığını gösterir. İçerik taşıma, URL yapısı değişikliği, yanlış yönlendirme, silinen görseller veya hatalı iç bağlantılar bu kayıtları oluşturabilir. Günlük trafik içinde az sayıda ve farklı URL’lere dağılmış 404 isteği çoğu zaman olağandır.

Normal davranış genellikle şu özellikleri taşır: istekler farklı kullanıcı ajanlarından gelir, yoğunluk aniden yükselmez, aynı IP kısa sürede yüzlerce deneme yapmaz ve URL’ler sitenin gerçek içerik yapısına yakındır. Örneğin eski bir blog yazısına ait görselin silinmesi, sürekli ama zararsız bir 404 kaydı üretebilir.

404 kayıtlarının saldırı belirtisine dönüştüğü durumlar

Bir 404 kaydını riskli yapan temel unsur, rastgele hata olması değil, sistematik keşif davranışı göstermesidir. Saldırganlar genellikle sunucuda zayıf yönetim panelleri, eski eklenti dosyaları, yedek arşivler, yapılandırma dosyaları veya bilinen açıklara ait yollar arar.

Kısa sürede yüksek sayıda istek gelmesi

Aynı IP adresinden birkaç saniye veya dakika içinde onlarca, yüzlerce 404 isteği geliyorsa bu davranış manuel gezinmeden çok otomatik taramaya işaret eder. Özellikle istekler ardışık şekilde farklı dizinleri deniyorsa dikkat edilmelidir.

Pratik kontrol için belirli bir zaman aralığında IP bazlı 404 sayısını inceleyin. Normal kullanıcı hataları genellikle seyrek ve bağlamsaldır; saldırı taramaları ise ritmik, yoğun ve tekrarlıdır.

Yönetim paneli, eklenti ve yedek dosya aramaları

Access log içinde /wp-admin/, /xmlrpc.php, /wp-content/plugins/, /backup.zip, /.env, /config.php gibi yolların tekrar tekrar denendiğini görüyorsanız bu daha ciddi değerlendirilmelidir. Bu isteklerin çoğu 404 dönse bile saldırganın amacı, bilinen dosya adları üzerinden açık bulmaktır.

Burada sık yapılan hata, “dosya bulunamadıysa sorun yok” düşüncesidir. Oysa 404 dönen taramalar, sonraki aşamada parola denemesi, açık eklenti istismarı veya kaynak tüketimi saldırısına dönüşebilir.

Gerçek kullanıcı davranışına benzemeyen user-agent bilgileri

Boş user-agent, bilinen tarayıcı formatına uymayan ifadeler, eski tarayıcı sürümleri veya güvenlik tarama araçlarını çağrıştıran bilgiler risk seviyesini artırır. Ancak yalnızca user-agent’a güvenmek doğru değildir; bu alan kolayca taklit edilebilir.

Daha sağlıklı değerlendirme için IP, istek sıklığı, hedeflenen URL deseni, yanıt kodları ve trafik zamanı birlikte incelenmelidir.

Access log analizi nasıl yapılmalı?

İlk adım, logları sadece hata listesi olarak değil, davranış verisi olarak okumaktır. Şüpheli kayıtları değerlendirirken şu sorular hızlı karar vermenizi sağlar:

• Aynı IP kısa sürede kaç farklı 404 URL’si denemiş?
• İstenen yollar WordPress, panel, yedek veya yapılandırma dosyalarına mı yöneliyor?
• İstekler gece saatlerinde veya olağan dışı trafik paterninde mi yoğunlaşıyor?
• 404 sonrası 403, 401, 500 veya giriş denemeleri görülüyor mu?
• İstekler tek bir ülkeden, veri merkezi IP’lerinden veya bilinen bot ağlarından mı geliyor?

Bu analiz, sadece güvenlik ekibi için değil, site yöneticileri için de faydalıdır. Yanlış yapılandırılmış yönlendirmeler ile saldırı taramalarını ayırmak, gereksiz engellemeleri ve gerçek kullanıcı kaybını önler.

Yanlış pozitifleri azaltmak için dikkat edilmesi gerekenler

Her yoğun 404 trafiği saldırı değildir. Büyük bir kampanya sonrası eski URL’lerin paylaşılması, arama motorlarının gecikmeli taraması veya taşınan içeriklerin yanlış yönlendirilmesi benzer tablo oluşturabilir. Bu nedenle engelleme kararı vermeden önce trafik kaynağı ve referer bilgisi kontrol edilmelidir.

Örneğin sosyal medya kampanyasından gelen hatalı bir bağlantı, yüzlerce 404 kaydı üretebilir. Bu durumda IP engellemek yerine doğru 301 yönlendirmesi oluşturmak gerekir. Buna karşılık aynı IP’nin /.git/, /.env ve eski eklenti dosyalarını denemesi güvenlik odaklı aksiyon gerektirir.

Şüpheli 404 trafiğine karşı alınabilecek önlemler

İlk olarak gereksiz dosyaların sunucuda bulunmadığından emin olun. Yedek arşivleri, eski kurulum klasörleri, test dosyaları ve geliştirme ortamına ait yapılandırmalar web kök dizininde tutulmamalıdır. Bu dosyalar bulunmasa bile sürekli aranıyor olmaları, saldırganların hangi yolları denediğini gösterir.

İkinci adım, oran sınırlama ve güvenlik duvarı kurallarıdır. Aynı IP’den kısa sürede çok sayıda 404 isteği geliyorsa geçici kısıtlama uygulanabilir. Ancak bu kural, arama motoru botlarını veya kurumsal proxy kullanan gerçek kullanıcıları etkilemeyecek şekilde dikkatli tasarlanmalıdır.

Üçüncü olarak log izleme alışkanlığı oluşturulmalıdır. Düzenli kontrol yapılmadığında saldırı keşifleri ancak performans düşüşü veya erişim problemi yaşandığında fark edilir. Güvenilir bir hosting hizmetinde log erişimi, güvenlik uyarıları ve kaynak kullanım takibi bu nedenle kritik öneme sahiptir.

Ne zaman profesyonel müdahale gerekir?

404 trafiğiyle birlikte CPU kullanımı artıyor, site yanıt süreleri uzuyor, yönetim panelinde başarısız giriş denemeleri çoğalıyor veya aynı IP bloklarından sürekli tarama geliyorsa olay basit hata yönetiminin ötesine geçmiş olabilir. Bu noktada sunucu günlükleri, uygulama logları ve güvenlik duvarı kayıtları birlikte incelenmelidir.

Paylaşımlı altyapılarda kullanıcı tarafında yapılabilecekler sınırlı olabilir; bu durumda sağlayıcıdan ilgili IP’lerin, zaman aralıklarının ve örnek log satırlarının paylaşılması istenmelidir. VPS veya özel sunucu kullanan yapılarda ise web sunucusu kuralları, WAF politikaları ve erişim limitleri daha esnek biçimde düzenlenebilir. Düzenli analiz edilen 404 kayıtları, yalnızca bulunamayan sayfaları değil, sisteme yönelen keşif girişimlerini de görünür hale getirir.