Tipik sorular: ayrılan çalışanın hesabı ayrılış tarihinden sonra kullanılmış mı, bir müşteri kaydını kim sildi, yönetici paneline gece hangi adresten girildi. Cevap tek dosyada durmaz; VPN ağ geçidi, etki alanı denetleyicisi, uygulama ve firewall aynı olayın farklı parçalarını çoğu zaman farklı saat referanslarıyla yazar.
Hangi log kaynaklarını inceliyoruz?
Dört grup kaynağı inceliyoruz: sistem ve sunucu, ağ, güvenlik, uygulama ve bulut. Alanların anlamını her sistemin kendi yapılandırmasından teyit ederiz; aynı adlı alan iki kurulumda farklı değer yazabilir.
Sistem ve sunucu kayıtları
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta |
|---|---|---|
Windows Event Log (Security.evtx, System.evtx) | Oturum açma (4624), başarısız deneme (4625), süreç başlatma (4688), günlük temizleme (1102), saat değişikliği (4616) | 4688'de komut satırı politika açılmadıkça boştur. Windows 10/11'de Security günlüğü varsayılan 20 MB'tır, dolunca en eski olayların üzerine yazar. |
| Active Directory kayıtları | Kerberos bilet istekleri (4768, 4769), NTLM doğrulaması (4776), hesap oluşturma (4720), kilitlenme (4740) | Logon ID yalnızca aynı bilgisayarda ve yeniden başlatmaya kadar tekildir; makineler arasında anahtar olamaz. |
| Linux sistem logları | /var/log/auth.log (Debian), /var/log/secure (RHEL), systemd journal, wtmp, btmp | Debian 12'den itibaren rsyslog varsayılan olarak kurulmaz; auth.log yoksa kayıtlar journal'dadır. |
| Audit logları | auditd (/var/log/audit/audit.log), uygulamaların denetim izleri | auid alanı, kullanıcı su ile başka hesaba geçse de oturumu ilk açan hesabı taşır. |
| Hata ve olay kayıtları | Servis kurulumu (7045), beklenmedik kapanış (41, 6008), yeniden başlatma (1074), uygulama hata dosyaları | Hata satırı olayın kendisini değil, sistemin ona tepkisini gösterir. |
Ağ kayıtları
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta |
|---|---|---|
| Firewall logları | İzin verilen ve reddedilen bağlantılar, IP ve port, NAT dönüşümü | Bağlantı NAT öncesinde iç, sonrasında dış adresle görünür; satırın hangisini yazdığını önce belirleriz. |
| VPN kayıtları | Kullanıcı adı, dış IP, tünel içi IP, bağlanma ve ayrılma zamanı | Tünel içi adresi hesaba bağlayan çoğu zaman yalnızca bu kayıttır. |
| Proxy logları | Kullanıcı ya da iç IP, istenen adres, yanıt kodu | HTTPS'te proxy genellikle yalnızca alan adını görür. Kayıtta tam URL varsa TLS denetimi yapılıp yapılmadığını sorarız. |
| DNS kayıtları | Hangi iç adresin hangi alan adını ne zaman sorguladığı | Şifreli DNS (DoH, DoT) kullanan cihazın sorguları kurumun DNS sunucusuna hiç uğramayabilir. |
| DHCP kayıtları | IP, MAC adresi ve cihaz adı eşlemesi, kira zamanları | Windows DHCP sunucusu gün adlı dosyalara (DhcpSrvLog-Mon.log gibi) yazar; dosya yerel saatle gece yarısı değişir, bir hafta sonra üzerine yazılır. |
| Router / switch kayıtları | Arayüz durumu, yapılandırma değişikliği, yönetici girişleri | Eski tip syslog (RFC 3164) satırında yıl ve saat dilimi yoktur; ikisi raporda varsayım olarak yazılır. |
Güvenlik sistemleri
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta |
|---|---|---|
| IDS / IPS kayıtları | İmzaya ya da davranış kuralına uyan trafik, alarm önceliği | Alarm denemeyi gösterir, başarıyı değil. |
| WAF kayıtları | Gelen istek, eşleşen kural, engelleme kararı | Kural "yalnız izle" modundaysa engellendiği sanılan istek uygulamaya ulaşmış olabilir. |
| SIEM kayıtları | Farklı kaynaklardan tek biçime çevrilmiş olaylar, korelasyon alarmları | İşlenmiş kopyadır, dönüştürmede alan düşebilir; kritik satırları ham kaynakta da buluruz. |
| Authentication / login kayıtları | Kimlik sağlayıcı ve tek oturum açma (SSO) kayıtları, çok faktörlü doğrulama, başarısız denemeler | Microsoft Entra ID oturum açma kayıtlarını ücretsiz sürümde 7, P1 ve P2'de 30 gün tutar. |
Uygulama, veri tabanı ve bulut kayıtları
| Kaynak | Ne gösterir | Dikkat ettiğimiz nokta |
|---|---|---|
| Web server logları (Apache / Nginx) | İstemci IP'si, zaman, istek satırı, durum kodu, Referer, User-Agent | Önde ters proxy ya da CDN varsa, ayrıca yapılandırılmadıkça %h ve $remote_addr onun adresidir. Varsayılan biçim kaynak portu yazmaz. |
| Uygulama ve API logları | İstek kimliği, kullanıcı, uç nokta (endpoint), parametreler, yanıt kodu | Neyin loglanacağına geliştirici karar verir; kaydın yokluğu olayın yokluğu değildir. |
| Kullanıcı işlem kayıtları | Hangi hesabın hangi kaydı ne zaman oluşturduğu, değiştirdiği, sildiği | Uygulama yöneticisi bu tabloyu düzenleyebiliyorsa bağımsız bir kopyayla karşılaştırırız. |
| Veri tabanı logları | Bağlantı, sorgu ve hata kayıtları, işlem (transaction) günlükleri | PostgreSQL'de log_statement varsayılanı none, MySQL'de genel sorgu logu varsayılan olarak kapalıdır. Ayrıntı: veri tabanı incelemesi. |
| E-posta sunucu kayıtları | Gönderici, alıcı, Message-ID, sunucular arası aktarım, teslim durumu | Exchange Server ileti izleme kaydı UTC yazar, içeriği tutmaz, konu satırını varsayılan olarak tutar; dosyalar 30 günde, klasör dolarsa daha erken silinir. |
| Cloud sistem logları | AWS CloudTrail, Microsoft 365 birleşik denetim kaydı, Google Workspace denetim kayıtları | CloudTrail'de eventTime UTC'dir; olay geçmişi (Event history) son 90 günün yönetim olaylarını gösterir. |
İnceleme için hangi materyal gerekir?
Log dosyalarının özgün hâli, onları üreten yapılandırma ve toplama kaydı. Ekran görüntüsü logun kendisi değildir; Excel'e aktarılmış dosyada da tarihler bölgesel ayara göre yeniden yorumlanmış olabilir.
- Özgün dosyalar:
.evtx,access.logve döndürülmüş arşivleri (access.log.1,.gz), journal dosyaları, bulut konsolundan JSON dışa aktarımı. - Logu üreten yapılandırma:
log_formatsatırı,rsyslog.conf, saat dilimi ve NTP ayarı, SIEM'in alan eşleme kuralları. - Toplama kaydı: dosyayı kim, hangi yöntemle, ne zaman aldı; alındığı anda hesaplanan SHA-256 değeri. Değeri hash hesaplama aracıyla tarayıcıda da üretebilirsiniz.
- İç IP planı ve NAT kuralları. Bunlar olmadan
10.0.3.17gibi bir adresin hangi cihaz olduğu anlaşılmaz.
Ceza soruşturmasında el konulan sistemlerin yedeğinden şüpheliye ya da vekiline verilen kopya (CMK m.134/4) da inceleme materyali olabilir. Madde, Anayasa Mahkemesi'nin 12.02.2026 tarihli, E.2023/128, K.2026/36 sayılı kararıyla iptal edilmiştir (RG 25.05.2026); iptal 25.02.2027'de yürürlüğe girecektir.
Log incelemesi nasıl ilerler?
- Soru ve zaman aralığı. Hangi olay, hangi hesaplar, hangi tarihler.
- Teslim ve bütünlük. Her dosyanın SHA-256 değeri teslim anındaki değerle karşılaştırılır; iş çalışma kopyası üzerinde yürür.
- Kaynak envanteri. Her kaynak için biçim, alan anlamları, saat referansı, ilk ve son kaydın tarihi. Kayıtlar olaydan sonra başlıyorsa bunu işin başında söyleriz.
- Saat normalizasyonu. Bütün zamanlar UTC'ye çevrilir. Her kaynağın saat sapması ayrı ölçülür, eşleştirme toleransı gerekçesiyle yazılır.
- Ayrıştırma. Açık kaynak araçlar (ör. plaso/log2timeline) ve kendi betiklerimizle. Araç ve sürüm rapora geçer; adımları başka bir uzman tekrarlayabilmelidir.
- Değerlendirme. Bütünlük, korelasyon, zaman çizelgesi, alternatif açıklamalar.
Zaman damgası incelemesi: kayıtlardaki saatler neden tutmaz?
Çünkü her sistem zamanı kendi referansıyla yazar: kimi UTC, kimi yerel saat, kimi saat dilimini hiç belirtmez. Türkiye 2016'dan beri sürekli UTC+3 olduğundan aynı an iki kayıtta üç saat farkla görünebilir; incelemeye her kaynağın zaman damgasını (timestamp) çözerek başlarız.
| Kaynak | Zaman nasıl yazılır |
|---|---|
Apache %t | İsteğin alındığı an, ofsetle: [14/Mar/2026:23:47:05 +0300] |
| Windows olay günlüğü | TimeCreated SystemTime, UTC (Olay Görüntüleyici ekranda yerel saate çevirir) |
Linux auditd | msg=audit(1773521225.412:3187): Unix saniyesi ve kayıt numarası |
| Eski tip syslog (RFC 3164) | Mar 14 23:47:05: yerel saat; yıl ve saat dilimi yok |
| AWS CloudTrail, Exchange ileti izleme | ISO 8601, UTC: 2026-03-14T20:47:05Z |
Örnek: Tablodaki değerlerin hepsi 14 Mart 2026 20:47:05 UTC'dir; saat dilimine bakılmazsa 20:47 ile 23:47 iki ayrı olay gibi okunur. 2016 öncesi kayıtlarda yaz saati ve Avrupa'dan farklı geçiş tarihleri (2011, 2014, 2015) de hesaba katılır. Ayrıntı: zaman damgaları ve saat dilimi; dönüşüm için zaman damgası dönüştürücü.
Saat dilimi doğru olsa da saatin kendisi yanlış olabilir: NTP'nin (RFC 5905) varsaydığı 15 ppm frekans toleransı günde yaklaşık 1,3 saniye, altı ayda dört dakikaya yakın kayma demektir. Sapmayı her kaynakta ayrı ölçeriz (NTP durumu, 4616 olayları, wtmp).
Log bütünlüğü ve manipülasyon değerlendirmesi nasıl yapılır?
İki soruyu ayırarak. Dosyanın toplandığı andan beri değişip değişmediği, toplama anındaki hash değeriyle kesin olarak sınanır. Kaydın olaydan sonra, toplamadan önce düzenlenip düzenlenmediğinin ise kesin testi yoktur; dolaylı izlerle tartılır. Düz metin logu yetkili biri değiştirebilir, syslog protokolünde de kriptografik koruma yoktur (RFC 5424).
- Teslim zinciri. Hash değeri, alan kişi, zaman, yöntem. Yargıtay 8. Ceza Dairesi, imaj alınıp hash değerlerinin tespit edilmemesini beraat gerekçeleri arasında saymıştır (E.2012/21817, K.2013/25428).
- Süreklilik. Kayıt numaralarında atlama, 1102 ve 4616 olayları, döndürülmüş dosyalar arasında boş kalan saatler, geriye akan zaman.
- Kaynaklar arası çelişki. Web sunucusu bir isteği yazmış, önündeki firewall o dakikada hiçbir bağlantı görmemiş.
- Koruma mekanizmaları. Merkezi log sunucusuna anlık gönderim, tek seferlik yazılabilir (WORM) depolama, journald'ın Forward Secure Sealing özelliği, ticari toplu kullanım sağlayıcılarının her gün kaydettiği bütünlük değeri.
İz bulunmaması değişiklik olmadığını ispatlamaz. Bizce en sağlam dayanak bağımsızlıktır: şirket sunucusu, servis sağlayıcı ve bulut gibi kontrolü farklı kişilerde olan sistemler aynı olayı tutarlı gösteriyorsa, hepsinin birlikte düzenlenmiş olması zayıf bir ihtimaldir. İzlerin ayrıntısı log kayıtlarının delil değeri yazısında.
Farklı sistem loglarının korelasyonu ve olay zaman çizelgesi
Korelasyon, kayıtları ortak alanlar üzerinden birbirine bağlamaktır: IP ve zaman aralığı (varsa port), kullanıcı adı, oturum kimliği, X-Request-ID gibi istek kimlikleri, e-postada Message-ID. Her bağlantının gerekçesi raporda yazılır.
Örnek (veriler kurgusaldır, zamanlar UTC'ye çevrilmiştir): Bir şirket, ayrılan bir çalışanın müşteri listesini dışarı aldığından şüpheleniyor. Zaman çizelgesi şöyle kurulabilir:
| Saat (UTC) | Kaynak | Kayıt |
|---|---|---|
| 18:02:11 | VPN ağ geçidi | ornek.kullanici hesabı 203.0.113.25 adresinden bağlandı, tünel içi adres 10.8.0.14 |
| 18:02:40 | Etki alanı denetleyicisi | Aynı hesap için Kerberos bilet isteği (4768), istemci 10.8.0.14 |
| 18:05:03 | CRM uygulama logu | Aynı hesapla "müşteri listesini dışa aktar" işlemi, 4.812 satır |
| 18:05:09 | Firewall | 10.8.0.14'ten harici bir dosya paylaşım hizmetine 14 MB çıkış |
Çizelge hesabın kullanıldığını güçlü biçimde gösterebilir; hesabı kimin kullandığını ise tek başına göstermez, parola paylaşılmış ya da çalınmış olabilir. 203.0.113.25 adresinin olay anındaki abonesi ayrı bir eşleştirme ister (IP adresi tespiti ve CGNAT analizi). Saldırı ya da hesap ele geçirme şüphesinde inceleme siber olay incelemesine dönüşür.
Log analizi neyi gösteremez?
Loglanmayan bir olayı gösteremez; varsayılan ayarlar ise pek çok işlemi hiç kaydetmez. Bir satırın varlığı içeriğinin doğru olduğunu da göstermez: User-Agent, Referer ve X-Forwarded-For istemcinin kendi yazdığı değerlerdir. Olay dönemine ait kayıtlar silinmiş ya da üzerine yazılmışsa o aralığı tahminle doldurmayız; raporda boşluk olarak kalır.
Raporda neler yer alır?
Soru, materyal listesi ve hash değerleri, yöntem ve araç sürümleri, saat referansı tablosu, bulgular, zaman çizelgesi, alternatif açıklamalar ve incelemenin sınırları. Ham satırlar ektedir; her bulgu kaynağındaki satıra kadar izlenebilir.
Rapor uzman görüşü (HMK m.293) ya da bilimsel mütalaa (CMK m.67/6) olarak hazırlanıp avukatınız tarafından dosyaya sunulabilir. Mahkemeyi bağlamaz, diğer delillerle birlikte değerlendirilir; hukuki nitelendirme avukata ve mahkemeye aittir. Dosyada loglara dayanan bir bilirkişi raporu varsa (uzmanlık alanları listesindeki adıyla "Veri ve Log Kaydı İnceleme"), teknik tespitlerini bilirkişi raporunun teknik değerlendirmesi kapsamında inceleyebiliriz.