Log Analizi Nedir? Linux ve Web Loglarını Okumaya Başlangıç

Log analizi nedir sorusunun kısa cevabı şu: bir sistemin kendi tuttuğu kayıtları okuyarak ne olduğunu bulmak. Bir sunucuya gece yüzlerce kez parola denendiyse bunu auth.log söyler. Biri sitende gizli dizinleri yokladıysa bunu access.log söyler. Bu yazıda hangi logun nerede durduğunu, bir satırın alan alan nasıl okunduğunu ve ilk analizini hangi komutlarla yapacağını göreceksin.

Log analizi nedir, ne işe yarar?

Log, bir sistemin yaşadığı olayları zaman sırasıyla yazdığı kayıttır. NIST tanımı kısadır: kurumun sistemlerinde ve ağlarında gerçekleşen olayların kaydı. Log analizi bu kayıtlardan bir soruya cevap çıkarmaktır: Kim girdi, ne zaman, nereden, ne denedi? Kayıtları toplayıp saklamak ise log yönetimidir.

Bir log satırı tek başına çoğu zaman önemsizdir. Anlam tekrarla ve sırayla ortaya çıkar. Bir yanlış parola gürültüdür. Aynı adresten dört dakikada yüzlerce yanlış parola bir betiktir. Arkasından gelen bir başarılı giriş ise artık bir olaydır.

Log analizini şu işler için yaparsın:

• Güvenlik: Kaba kuvvet denemesini, taramayı ve beklenmeyen girişi bulmak.
• Arıza giderme: Bir servisin neden durduğunu ya da sitenin neden 500 hatası verdiğini görmek.
• Olay müdahalesi: Saldırının zaman çizelgesini kurmak. Sürecin aşamalarını olay müdahalesi rehberinde bulursun.
• Denetim ve uyum: Hangi hesabın hangi yetkiyle ne yaptığını kanıtlamak.

Linux log dosyaları nerede bulunur?

Linux'ta düz metin loglar /var/log altında durur. Systemd kullanan dağıtımlarda bir de journald günlüğü vardır, onu dosya yerine journalctl komutuyla okursun. Dosya adları dağıtım ailesine göre değişir:

Üç ayrıntı aramanı kurtarır:

• Debian 12'den beri yeni kurulumlarda rsyslog varsayılan olarak gelmez. Giriş ve sistem dosyalarını (auth.log, syslog, secure, messages) rsyslog yazar. O kurulu değilse bu dosyalar oluşmaz. Kayıtlar yine tutulur, yalnız /var/log/journal altında ikili biçimde durur ve journalctl ile okunur. Fedora da 20. sürümden beri rsyslog'u varsayılan olarak kurmaz.
• Eski kayıtlar logrotate ile auth.log.1, auth.log.2.gz gibi dosyalara taşınır. Olay birkaç gün önceyse bu dosyalarda da ara. .gz uzantılıları zgrep ile açmadan tararsın.
• Yetki: Bu dosyaları okumak çoğu sistemde sudo ister.

Güvenlik duvarı kayıtları ayrı bir konu. Onları güvenlik duvarı log analizi yazısında okuyabilirsin.

auth.log nedir, bir satırı nasıl okursun?

auth.log, Debian ve Ubuntu'da kimlik doğrulama olaylarının yazıldığı dosyadır: SSH girişleri, sudo kullanımı, başarısız parola denemeleri. RHEL ailesinde aynı işi /var/log/secure görür. Kurgu bir SSH denemesi şöyle görünür:

Nov  5 03:11:52 vpn01 sshd[2205]: Failed password for invalid user admin from 198.51.100.77 port 51441 ssh2

İki güncel ayrıntı satırın görünüşünü değiştirir. OpenSSH 9.8'den beri bazı mesajlar sshd yerine sshd-session adıyla, 10.0'dan beri bazıları sshd-auth adıyla düşer. Debian'ın rsyslog paketi de bookworm sürümünden beri zamanı 2026-11-05T03:11:52.481203+03:00 gibi yıl, saniye kesri ve saat dilimiyle yazar. Bu yüzden ararken süreç adına değil, mesajın kendisine bak.

İlk analiz dört komutla yapılır. Önce son kayıtlara bakar ve başarısız denemeleri sayarsın. Sonra denemeleri kaynak adrese göre gruplar, en çok deneyen adresin başarılı girişi var mı diye bakarsın:

sudo tail /var/log/auth.log
sudo grep -c -i "Failed password" /var/log/auth.log
sudo grep -i "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn
sudo grep 198.51.100.77 /var/log/auth.log | grep -i accepted

$(NF-3) satırın sondan dördüncü alanını alır. Satır "from IP port N ssh2" ile bittiği için bu alan IP adresidir. grep büyük-küçük harfe duyarlıdır. -i olmadan "failed password" diye küçük harfle ararsan hiçbir şey bulamazsın ve saldırı yokmuş gibi görünür. -i iki yazımı da yakalar. Son komut boş dönerse bu dosyada o adresten başarılı giriş yoktur. Satır dönerse vaka büyür ve o hesabın girişten sonra ne yaptığına bakarsın. Komutların ayrıntısı için Linux komutları rehberine göz at.

Bu akışı tarayıcıda dene: Kapıyı Kim Zorluyor görevinde bir VPN sunucusunun auth.log dosyasını incelersin. Saldırgan IP'yi bulur, girişin başarılı olup olmadığını doğrular ve adresi fail2ban ile engellersin. Görev ücretsizdir, kurulum istemez. Komutları giriş yapmadan yazabilirsin, flag göndermek için giriş yaparsın.

Access log nasıl okunur?

Access log, web sunucusunun aldığı her isteği bir satıra yazdığı dosyadır. nginx'in yerleşik combined biçimi ile Apache'nin combined biçimi aynı alan sırasını kullanır, bu yüzden ikisini aynı yöntemle okursun. Kurgu bir satır:

198.51.100.23 - - [05/Nov/2026:03:12:01 +0300] "GET /.git/config HTTP/1.1" 404 153 "-" "Mozilla/5.0"

Soldan sağa alanlar şunlardır:

1. İstemcinin IP adresi
2. Kimlik alanı, neredeyse her zaman "-"
3. HTTP kimlik doğrulamasıyla giren kullanıcı, yoksa "-"
4. Saat dilimli zaman
5. İstek satırı: yöntem, yol ve protokol
6. Durum kodu. İlk rakam sonucu söyler: 2 başarı, 3 yönlendirme, 4 istemci hatası, 5 sunucu hatası.
7. Yanıt gövdesinin boyutu
8. Referer ve User-Agent

Güvenlik için iki alan öne çıkar. Durum kodu: aynı adresten kısa sürede gelen yüzlerce 404, çoğu zaman var olmayan yolların sırayla denendiği bir dizin taramasıdır. User-Agent: bu bilgiyi istemci kendisi yazar ve istediği gibi değiştirebilir. Ona kimlik gibi güvenme. Sunucu bir vekil sunucunun (proxy) arkasındaysa ve gerçek adres ayarı yapılmadıysa ilk alanda ziyaretçi yerine vekilin adresini görürsün.

Aşağıdaki üç komut sırayla durum kodlarının dağılımını, 404 üreten adresleri ve şüpheli adresin istediği yolları verir:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
awk '$9 == 404 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
awk '$1 == "198.51.100.23" {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

awk alanları boşluğa göre sayar. Zaman iki, istek satırı üç parçaya bölündüğü için yol $7, durum kodu $9 olur. Bozuk bir istek satırı bu sırayı kaydırabilir. Sonuç tuhafsa o satırı gözle aç. Bazı nginx paketlerinin varsayılan ayarı satırın sonuna X-Forwarded-For alanını ekler, baştaki alanlar değişmez. Bir tarama vakasını baştan sona Dizin Yoklaması görevinde çözebilirsin. Orada 404 artışının kullanıcı hatası mı tarama mı olduğunu ayırır, kaynağı nginx ile reddeder ve raporu yazarsın.

journalctl ile log nasıl okunur?

journalctl, systemd günlüğünü okuyan komuttur. auth.log'un olmadığı sistemlerde ana aracın budur. Dosya adı yerine servis, zaman ve önem derecesiyle süzersin:

sudo journalctl -u ssh --since today
sudo journalctl -u sshd --since "2026-11-05 02:00" --until "2026-11-05 04:00"
sudo journalctl -u ssh -g "Failed password"
sudo journalctl -p err -b
sudo journalctl -f

1. SSH servisinin bugünkü kayıtları. Debian ve Ubuntu'da birim adı ssh olur.
2. RHEL ve Fedora'da birim adı sshd olur. Burada saat aralığı da verildi.
3. Mesaj içinde arama.
4. Bu açılıştan beri hata ve daha ciddi kayıtlar.
5. Yeni kayıtları canlı izleme, tail -f gibi.

-u süreç adına değil, sürecin bağlı olduğu servis birimine göre süzer. Bu yüzden sshd-session adıyla yazılan satırlar da çıktıda kalır. Çıktıyı başka bir araca aktaracaksan -o json her kaydı ayrı bir JSON nesnesi olarak verir.

Windows'ta log analizi nereden başlar?

Windows logları düz metin dosyası değil, olay kaydıdır. Güvenlikte ilk bakılan yer Olay Görüntüleyicisi'ndeki Güvenlik (Security) günlüğüdür. Başarısız oturum açma 4625, başarılı oturum açma 4624 kimliğiyle yazılır. Linux'taki "Failed password yığını, ardından Accepted" deseninin Windows karşılığı, 4625 yığınının ardından gelen 4624'tür.

PowerShell'i yönetici olarak açıp son başarısız girişleri şöyle listelersin:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20

Oturum türlerini ve 4625 hata kodlarını Windows olay kimlikleri yazısında tablo hâlinde bulursun.

Log analizi adım adım nasıl yapılır?

Log analizi rastgele grep yazmak değil, bir soruyu sırayla daraltmaktır. Başlangıç için şu sıra işe yarar:

1. Soruyu yaz. Örnek: "Gece 03:00'te vpn01'e kim girmeye çalıştı, girebildi mi?"
2. Kaynağı seç. SSH için auth.log ya da journalctl, web için access.log, Windows için Güvenlik günlüğü.
3. Zamanı sabitle. Aralığı belirle, her kaynağın saat dilimini kontrol et.
4. Süz. grep, awk ya da journalctl ile yalnız ilgili satırları al.
5. Say ve grupla. sort ve uniq -c ile kim, ne kadar, ne sıklıkla sorusunu yanıtla.
6. Bağla. Aynı adresi diğer kaynaklarda ara. SSH'ı zorlayan adres siteyi de taramış olabilir.
7. Doğrula. Başarılı giriş var mı, sonrasında ne oldu? Engellemeden önce kanıtı gör.
8. Kanıtı koru. Orijinal dosyayı düzenleme. Kopyası üzerinde çalış, bulduğun satırları not al.

Üçüncü adım kolayca atlanır. Oysa her kaynak zamanı farklı yazar:

Türkiye saatine ayarlı bir sunucu +03:00, UTC'ye ayarlı bir sunucu +00:00 yazar. Kayıtları yan yana koymadan önce hepsini aynı saate çevir. Yoksa bir saldırgan içeri girmeden önce çıkmış gibi görünebilir. Birden çok kaynağı ve saat farkını birlikte çalışmak için Log Avı labında auth.log ve access.log kayıtlarını Windows olaylarıyla eşleştirip soruları yanıtlarsın. Cevap göndermek için ücretsiz hesabınla giriş yaparsın.

Log analizi ile SIEM arasındaki fark nedir?

Log analizi bir yöntemdir, SIEM ise bu yöntemi ölçekte çalıştıran sistemdir. Bir sunucu için grep yeterlidir. Yüzlerce sunucu, güvenlik duvarı ve bulut hesabı varsa kayıtları tek tek açamazsın.

SIEM elle analizi bitirmez. Alarm çaldığında analist yine ham kayda iner ve "gerçekten oldu mu" sorusunu kendisi yanıtlar. Toplama, kural ve alarm akışını SIEM nedir yazısında ayrıntılı okuyabilirsin.

Bu kararı vermeyi SOC Vardiya ile çalışabilirsin. Alarm listesinden vaka seçer, kural, ağ ve cihaz kanıtlarını inceler, gerekçeli karar verir ve müdahale edersin. Simülasyon ücretsizdir, tarayıcıda çalışır ve hesap açmadan başlarsın. İlerlemen o tarayıcıda saklanır.

Kaynaklar

• NIST CSRC Sözlüğü: Log tanımı (SP 800-92)
• Apache HTTP Server: Log dosyaları ve Combined Log Format
• systemd: journalctl kılavuz sayfası
• Debian 12 sürüm notları: Sistem günlüğündeki değişiklikler
• OpenSSH 9.8 sürüm notları: sshd-session ayrımı