Sunucu Loglarından Anormallik Tespiti: Net İzleme Planı

Sunucu loglarını takip etmek, “sorun ne zaman başladı?” sorusunu dakikalar içinde yanıtlamayı sağlar. Doğru yapılandırılmış log toplama ve analiz sayesinde; saldırı denemeleri, yanlış yapılandırma, performans darboğazı ve kaynak tükenmesi gibi durumları önceden yakalarsınız. Bu rehberde, Linux tabanlı VDS/VPS ve genel hosting kurulumlarında loglardan anormallik tespiti yapmak için net bir yöntem, kontrol listesi ve aksiyon akışı bulacaksınız.

Aşağıdaki akış, hem yeni başlayanların temel seviyede doğru sinyalleri görmesini hem de tecrübeli ekiplerin belirgin hataları hızlı sınıflandırmasını hedefler. Hedefiniz; logları “okumak” değil, loglardan “karar vermek” olmalıdır.

1) Logları izlemeye başlamadan önce: kapsam ve hedef tanımı

Anormallik tespiti, hangi logların hangi amaçla toplanacağını netleştirince anlamlı hale gelir. Aksi halde yüzlerce satırı taramak yerine yanlış alarm üretirsiniz.

Hangi hedeflere odaklanın?

Aşağıdaki hedefler, bariz bir fayda sağlar: - Güvenlik: başarısız SSH denemeleri, anormal HTTP yöntemleri (ör. POST/PUT artışı), patikaya göre anormal tarama - Stabilite: servis çökmesi, yeniden başlama döngüleri, OOM (Out of Memory) olayları - Performans: 5xx artışı, upstream timeouts, disk doluluk yaklaşımı, i/o wait artışı - Kaynak tükenmesi: CPU %90+ kalıcılığı, RAM tükenmesi, trafik artışı (beklenmedik bant genişliği kullanımı)

Temel karar: log depolama ve erişim modeli

Loglar tek bir dosyada birikirse analiz zorlaşır. Pratik yaklaşım: - Sunucuda log saklama süresi: günlük döndürme + yeterli retention (ör. 7-30 gün) - Merkezi erişim: tek sunucuda bile bile olsa arama kolaylığı için standartlaştırma - Erişim izleri: loglarda kimlik doğrulama/başlık bilgileri gibi hassas alanlar bulunabilir

2) Log kaynaklarını doğru seçin: sistem + uygulama + ağ

“Anormallik” sinyali, yalnızca web sunucusu loglarında değildir. En iyi sonuç, üç katmanı birlikte izlemekle gelir: sistem, uygulama ve ağ.

Önerilen log türleri (Linux)

Aşağıdaki liste, VDS/VPS üzerinde yaygın ve etkilidir: - Sistem (systemd/journal): servis hataları, yeniden başlama, OOM kill - Auth: SSH ve yetkilendirme girişleri (ör. /var/log/auth.log) - Web sunucusu: Nginx/Apache erişim + hata logları - Uygulama: PHP-FPM, Node, Java servisleri (uygulama çökmesi ve hata stack’leri) - Sistem kaynakları: disk/CPU/RAM olayları (disk doluluğu, i/o hataları)

Web anormalliği sinyalleri: erişim ve hata ayrımı

Erişim logu “olanı” söyler (kim ne yaptı?), hata logu “neden”e yaklaşır (neden 502/500 oluştu?). Web katmanında şu eşleştirme önemlidir: - 5xx artışı + aynı anda upstream timeout - URL pattern değişimi + beklenmedik User-Agent dağılımı - Tek bir IP/ASN’den yüksek deneme + aynı anda auth başarısızlığı

3) Anormallik tespiti için net eşik ve kurallar

Logları tek bir yöntemle yorumlamak yerine, “kural seti” oluşturun. Kural seti, hem manuel kontrol hem de otomatik alarm için temeldir.

Güvenlik anormalliği: SSH ve HTTP taraması

Aşağıdaki kurallar, saldırı sinyalini erken yakalar:

SSH başarısız giriş eşikleri - Son 10 dakikada aynı IP’den 10+ başarısız giriş - Son 30 dakikada ülke/ASN değişimi olmadan artan deneme sayısı

HTTP tarama anormalliği - Son 5 dakikada aynı IP’den 404 oranında belirgin sıçrama - GET yanında anormal miktarda POST/PUT veya garip payload uzunlukları - User-Agent içinde bilinen tarayıcılar dışı tek tip kalıplar

Stabilite anormalliği: servis yeniden başlama ve OOM

• Son 1 saatte aynı servisin 3+ kez yeniden başlaması
• Kernel loglarında Out of memory (OOM) satırlarının görülmesi
• Uygulama loglarında “connection refused” ve “upstream prematurely closed” artışı

Performans anormalliği: 5xx, timeout, i/o

• Son 5 dakikada 5xx oranının eşik üstü olması (ör. toplam isteklerin %2’si veya üzerinde)
• Upstream timeout ve 499 (client closed request) artışı birlikteyse kapasite/latency problemi
• Disk i/o wait yükselişi + web hata loglarında 502/504 artışı

Not: Eşik değerler sabit değildir. Hedef trafiğiniz düşükse yüzde eşikleri küçük sapmaları bile büyütür; daha doğru yaklaşım “mutlak istek sayısı + yüzde” ikilisidir.

4) Pratik analiz: örnek sorgular, filtreler ve raporlama

Aşağıdaki yöntemler, logları manuel incelemeniz gerektiğinde zaman kazandırır. Tercihen analiz sırasında log satırlarını zaman penceresine bölün.

Zaman penceresi belirle

Önce “şüpheli dönem”i bulun, sonra daraltın: - İpucu: monitoring panelinizde CPU spike / 5xx artışı başladığı dakikayı tespit edin - Ardından loglarda o dakikadan 15-30 dakika geri sarın

Nginx erişim logundan anormali arama

Aşağıdaki komut yaklaşımıyla IP bazlı dağılım ve hata yoğunluğu incelenir (örnek yapı):

• Belirli bir zaman aralığında 5xx yoğun IP’leri görmek için:
• grep ile tarih/saat penceresi

• Sonra IP’ye göre sayım

• 404 artışını kontrol etmek için:

• status alanında 404 filtre
• Aynı IP’nin denediği path’leri listeleyin

Auth log ile brute-force sinyalini hızlandırma

Auth loglarda şu akış iş görür: - Başarısız giriş satırlarını filtrele - IP’yi gruplayıp say - Aynı anda başarılı giriş var mı kontrol et

Hızlı rapor formatı

Her anormallik olayı için 4 bilgiyi standart hale getirin: 1. Başlangıç zamanı (logda görünen ilk satır) 2. Etkilenen servis (nginx, php-fpm, sshd vb.) 3. Kaynak (IP/ASN/URL pattern) 4. Sonuç (5xx artışı mı, CPU spike mı, servis yeniden başlatma mı)

Bu format, ekip içi iletişimde “aynı olayı farklı yorumlama” problemini azaltır.

5) Otomasyon ve alarm: logdan aksiyona geçiş

Anormallik tespiti “tespit etmek”le bitmez. Loglardan aksiyona geçmeniz gerekir. Bu aşama, yanlış pozitif alarm ve gecikmeyi azaltır.

Otomasyon stratejileri

1. Eşik tabanlı alarm: belirlenen kural setine göre bildirim
2. Model tabanlı sinyal (opsiyonel): haftalık trendlerden sapma yakalama
3. Olay bazlı korelasyon: ör. “SSH brute-force + HTTP 404 spike” birlikte olunca daha yüksek öncelik

Yanlış alarm azaltma (net yöntem)

• Aynı IP’den 30 dakika boyunca düşük yoğunluk varsa alarmı tetiklemeyin
• Periyodik bot trafiği (ör. bot crawl) için bilinen patternleri hariç tutun
• Eşiği sadece yüzdeyle değil, minimum istek sayısıyla da belirleyin

Aksiyon örnekleri

Kuralınız tetiklenince şu sırayı izleyin: 1. Logdan olayın türünü doğrulayın (güvenlik mi, performans mı?) 2. Etkiyi ölçün (5xx oranı, servis sağlığı, CPU/RAM) 3. Müdahaleyi sınırlı yapın (ör. ilgili IP’yi geçici engelleme) 4. Sonucu doğrulayın (5-15 dk sonra metriklerde düzelme var mı?)

6) NetKıyas’ta karar verirken log odaklı kriterler

Loglardan anormallik tespiti yapmak, sunucunun sunduğu kapasiteyle doğrudan ilişkilidir. Plan seçerken sadece CPU/RAM değil, log analizini etkileyen altyapıyı da değerlendirin.

Sunucu sağlayıcı seçiminde log analizini etkileyen maddeler

• Disk I/O performansı: log yazma ve arama gecikirse olay tespiti geçikir
• Log retention desteği: otomatik döndürme ve saklama
• Kaynak izolasyonu: paylaşımlı ortamda başka kullanıcıların yoğunluğu sizin loglarınızda “bulanık sinyal” yaratır
• Kontrol paneli / erişim: SSH erişimi, günlük dosyalarına erişim, zaman senkronizasyonu
• Anomali sonrası müdahale hızı: servis yeniden başlatma, firewall kuralı değişimi gibi aksiyonların süresi

Karşılaştırma tablosu: anormallik tespiti için pratik farklar

Aşağıdaki tablo, genel seçim mantığını özetler (sağlayıcıdan sağlayıcıya değişebilir):

Eğer logdan aksiyon alma ihtiyacınız sık ve acilse (ör. yoğun trafik, sürekli güvenlik kontrolü), daha fazla izolasyon sağlayan yapı genellikle daha net sinyal üretir.

Sonuç: İlk 60 dakikada kuracağınız net plan

Anormallik tespiti için en iyi başlangıç, rastgele log okumak değil; logları hedefe göre toplamak ve ölçülebilir eşikler tanımlamaktır. İlk 60 dakikada şu sırayı uygulayın: - 1) İzleme hedeflerini belirleyin (güvenlik, stabilite, performans) - 2) Sistem + auth + web hata/erişim log kaynaklarını eşleştirin - 3) Net kural seti oluşturun (SSH başarısızlık, 5xx/timeout, OOM) - 4) Her olay için 4 alanlı rapor şablonunu kullanın (zaman, servis, kaynak, sonuç) - 5) Alarm tetiklenince aksiyon akışını prova edin (doğrula → etkiyi ölç → müdahale → doğrula)

Bu planı yaptıktan sonra loglar “geçmişi anlatan dosya” olmaktan çıkar, “karar veren sistem” haline gelir. Sorun yaşadığınız ilk senaryoyu seçin ve kuralları o senaryoya göre kesinleştirerek devam edin.