Log tutmanın temelleri

Bir olaydan sonra ilk soru hep aynıdır: ne oldu? Yanıtı loglar verir. Log yoksa kim girdi, ne zaman girdi, neye dokundu, hiçbirini kanıtlayamazsın. OWASP, güvenlik loglaması ve uyarı eksikliğini en kritik on web riski arasında sayar.

Sorun çoğu zaman logun hiç olmaması değildir. Log vardır ama yanlış şeyi yazar, yalnız saldırıya uğrayan makinede durur ya da kimse ona bakmaz. Saldırgan da bunu bilir ve izini örtmek için çoğu zaman önce yerel kayıtları siler.

Her şeyi loglamak çözüm değildir. Gürültü gerçek sinyali gömer, disk şişer ve kimse bakmaz. OWASP'ın Logging Cheat Sheet belgesi öncelikli olayları sayar.

İlk sırada başarılı ve başarısız kimlik doğrulama, erişim denetimi hataları ve girdi doğrulama hataları durur. Ardından kullanıcı ekleme ve silme, yetki değişiklikleri, hassas veriye erişim ve yapılandırma değişiklikleri gelir. Bu olaylar bir saldırının izini taşır.

Kaba kuvvet denemesi başarısız girişlerde, yetki yükseltme rol değişikliğinde, veri sızdırma da hassas tabloya erişimde görünür. Önce bunları tutarsın.

Loglamanın bir de düzeyi var. Hata ayıklama (debug) kayıtları geliştirme sırasında işe yarar ama üretimde açık kalırsa diski doldurur ve içine sır sızdırır. Üretimde bilgi, uyarı ve hata düzeyini tutar, debug'ı kapatırsın.

Güvenlik olayları için ayrı bir denetim (audit) kanalı açmak en temizidir: kimlik doğrulama ve yetki değişimi bu kanala düşer, uygulamanın gürültülü günlük kayıtlarına karışmaz. Böylece bir olayı incelerken binlerce debug satırını elemek zorunda kalmazsın.

Şemadaki ilk durak kaynaktır: sunucu, güvenlik duvarı, uygulama, kimlik sağlayıcısı. Her makinede çalışan toplayıcı (agent) satırları merkeze yollar. SIEM (güvenlik bilgisi ve olay yönetimi) farklı biçimleri tek biçime çevirir, kural da bu birleşik akışta şüpheli deseni arar.

Toplayıcı olmadan her kayıt doğduğu makinede kalır. Şunu da unutma: bir makinede root olan kişi o makinedeki her dosyaya yazabilir, yerel log da bu dosyalardan biridir.

auth.log -> yalnız /var/log/auth.log (yerel disk)
toplayıcı: yok

Bir de loglamaman gerekenler var. OWASP açık bir dışlama listesi verir: parola, oturum kimliği, erişim belirteci, şifreleme anahtarı, veritabanı bağlantı dizesi, kart numarası ve hassas kişisel veri loga düz yazılmaz. Log dosyalarını çoğu zaman destek ekibi, geliştirici ve yedekleme sistemi birlikte okur; sırrı loga yazmak onu bu geniş gruba açmaktır.

Oturumu ilişkilendirmen gerekiyorsa kimliğin özetini yaz. Maskeleme kuralını log kütüphanesine koy, her geliştiricinin aklına bırakma.

Ne kadar saklayacağın da bir karardır. Çok kısa saklarsan haftalar sonra fark edilen bir sızıntının izini bulamazsın; çok uzun saklarsan hem maliyet büyür hem de kişisel veri gereğinden fazla durur. Doğru süre, olayların çoğunun ne kadar sonra fark edildiğine ve yasal yükümlülüğe göre belirlenir. Az veriyi uzun, çok veriyi kısa tutmak iyi bir dengedir; gereksiz kişisel alanı en baştan yazmazsın.

İyi log satırı dört soruya yanıt verir: ne zaman, nerede, kim, ne? OWASP da olay alanlarını bu dört başlıkta toplar. Zaman damgası, olayın geçtiği uygulama ve sunucu, kaynak IP ile kullanıcı, olayın türü ve sonucu aynı satırda durur.

Biri eksikse satır incelemede işe yaramaz. Örneğin yalnız 'giriş başarısız' yazan bir satır, hangi hesaba, nereden ve ne zaman denendiğini söylemediği için bir kaba kuvvet denemesini öbüründen ayırmana yetmez.

Zaman damgası logun omurgasıdır. Damgayı UTC ve uluslararası biçimde (ISO 8601) yaz; örneğin 2026-07-25T20:54:59.649Z. Çok ülkenin güvenlik kurumunun birlikte yazdığı 2024 tarihli olay kaydı rehberi UTC'yi önerir, çünkü UTC'de zaman dilimi ve yaz saati karışıklığı yoktur.

Sunucular saatlerini NTP ile, örneğin chrony gibi bir istemciyle, güvenilir bir kaynaktan eşitlesin. Saatler kayarsa iki sunucunun kaydını yan yana koyduğunda sıra ters görünür ve kök nedeni yanlış yerde ararsın. Aynı isteğe ait satırlara ortak bir bağıntı kimliği yazarsan ön yüz, arka uç ve veritabanı kaydını tek zincirde birleştirirsin.

{ "ts": "2026-07-25T20:54:59.649Z", "app": "odeme-api", "host": "web-02",
  "src_ip": "203.0.113.45", "user": "admin", "event": "login",
  "result": "fail", "reason": "bad_password", "req_id": "a1f3c7" }

Satırı alanlarıyla oku. ts alanı olayın UTC zamanıdır ve sonundaki Z zamanın UTC olduğunu söyler. app ve host olayın nerede geçtiğini söyler. src_ip ve user kimin, nereden sorusunu yanıtlar.

event ve result olayın türünü ve sonucunu verir: bu bir giriş denemesi ve başarısız. req_id ise bağıntı kimliğidir; aynı isteğin başka sistemlerdeki satırlarını bu kimlikle birleştirirsin. Böyle bir satırı incelerken hiçbir soru açıkta kalmaz.

Yapılandırılmış log aramayı kökten değiştirir. Düz metin satırında 'admin' kelimesini aradığında hem kullanıcı adını hem bir yol parçasını hem de bir hata mesajını bulursun. Anahtar-değer biçiminde user alanında 'admin' aramak yalnız o kullanıcıyı getirir.

Olay anında saniyeler önemlidir; doğru alanı doğrudan sorgulayabilmek kök nedene giden yolu kısaltır. Bu yüzden yeni bir servis yazarken logu baştan JSON gibi yapılı bir biçimde üretirsin.

Toplanan log kendi kendine alarm üretmez, kritik olay için kural yazarsın. En bilinen kural kaba kuvvet (brute force) denemesini yakalar. Deseni şöyledir: aynı kaynaktan saniyeler içinde art arda başarısız giriş, yani HTTP 401, ardından tek bir başarılı giriş.

Son satır en tehlikelisidir, çünkü deneme tutmuş olabilir. Kuralı yazarken desen dar olmalı. Yalnız 401 kodunu ararsan başka sayfalardaki yetki hataları da gelir ve sonuç kirlenir; hem yolu hem kodu birlikte iste.

title: Web girişinde başarısız deneme
name: failed_login
logsource:
  category: webserver
detection:
  selection:
    cs-method: POST
    cs-uri-stem: /login
    sc-status: 401
  condition: selection
---
title: Tek kaynaktan kısa sürede çok sayıda başarısız giriş
correlation:
  type: event_count
  rules:
    - failed_login
  group-by:
    - c-ip
  timespan: 5m
  condition:
    gte: 10

Kuralı iki parça hâlinde oku. Sigma, SIEM'den bağımsız yazılan ortak bir tespit kuralı dilidir; araçlar kuralı kendi sorgu diline çevirir. Üstteki temel kural tek bir olayı tanımlar. logsource, kuralın hangi kayda bakacağını söyler: web sunucusu kayıtları.

detection içindeki selection üç koşulu birlikte ister: POST yöntemi, /login yolu ve 401 durum kodu. condition bu seçimin eşleşmesini yeterli sayar. name alanı kurala bir ad verir, alttaki kural ona bu adla başvurur. Alttaki korelasyon kuralı tek satırı değil, satırların sayısını izler.

event_count olay sayar. group-by sayımı kaynak IP'ye göre ayırır. timespan beş dakikalık bir pencere açar, condition da eşiği koyar: gte 10, yani on ya da daha çok.

Her kural iki yönden yanılabilir. Yanlış pozitif, zararsız bir olayı alarma çevirir; bir kullanıcının parolasını üç kez yanlış girmesi gerçek bir saldırı değildir. Yanlış negatif ise gerçek saldırıyı kaçırır. Saldırgan denemelerini yavaşlatırsa ya da çok sayıda adrese dağıtırsa her adres eşiğin altında kalır ve kural susar; bu durumu hesaba göre sayan ikinci bir kural yakalar.

Eşik keskin bir dengedir. Çok düşük tutarsan her unutkan kullanıcı alarm üretir ve ekip alarmlara bakmayı bırakır; buna uyarı yorgunluğu denir. Kuralı yayına almadan önce geçmiş loglarda dener, kaç gerçek olayı yakaladığına ve kaç boş alarm ürettiğine bakarsın. Az ama isabetli kural, çok ama gürültülü kuraldan iyidir.

Satırları gözle ayıklamak küçük bir olayda işe yarar, ama binlerce satırda elle tarama olmaz. Sigma kuralındaki selection bölümü aslında bir eşleşme desenidir. Pek çok araçta aynı deseni düzenli ifadeyle yazarsın: hangi satırların eşleşeceğini tek bir kalıp tanımlar.

İyi bir desen yalnız aradığın olayı yakalar, benzeyen ama ilgisiz satırları dışarıda bırakır. Yalnız 401 arayan bir desen panel sayfasındaki yetki hatasını da getirir, 200 ve 302 dönen başarılı girişler ise zaten dışarıda kalmalıdır.

Merkezi toplama ilk koruma adımıdır. 2024 tarihli olay kaydı rehberi logları merkezi ve güvenli bir depoya yollamayı önerir: yerel depo dolduğunda ya da cihaz ele geçtiğinde kayıt merkezde durur. İkinci adım değişmezliktir. OWASP, silinmeye ve değiştirilmeye karşı korunan bir denetim izi ister.

Yalnız ekleme yapılabilen (append-only) tablo bunun bir yoludur. Log verisini erken salt okunur ortama kopyalamak, erişimi yalnız ihtiyacı olana açmak ve logları ayrı bir ağda tutmak da aynı işi görür. MITRE ATT&CK güvenlik loglarını makine dışında saklamayı ayrı bir önlem diye listeler.

Merkezde logları tek biçime çevirmek neden önemli? Çünkü her kaynak kendi diliyle konuşur. Güvenlik duvarı 'deny', uygulama '403', kimlik sağlayıcısı 'access_denied' yazar; üçü de aynı şeyi anlatır.

SIEM bunları ortak alanlara eşler, böylece tek bir sorgu üç kaynağı birden tarar. Bu eşleme olmadan analist her kaynağı ayrı ayrı, ayrı sözdizimiyle sorgulamak zorunda kalır ve bağlantıları kaçırır. Normalleştirme, dağınık kaydı aranabilir bir bütüne çevirir.

Aynı ilkeler web sunucusu dışındaki her kayıt sisteminde geçerlidir. Kapı kartı sistemi, bulut hesabının denetim kaydı ya da veritabanının sorgu kaydı da aynı dört soruya yanıt vermeli, aynı biçimde merkeze akmalı ve aynı dar kurallarla izlenmeli. Kaydın yalnız doğduğu cihazda durması her yerde aynı riski taşır; cihaz ele geçerse kayıt da onunla gider.

Bulut hesabında denetim kaydını kapatmak, saldırganların ilk adımları arasındadır. Bu yüzden kaydın kapatılması da başlı başına bir uyarı konusu olur.