Zaman damgası ve saat dilimi tuzakları

Zaman çizelgesi kurmak olay müdahalesinin bel kemiğidir. Hangi olay önce oldu? Cevap sırayı, sıra da neden sonuç ilişkisini belirler.

Tek bir yanlış saat, saldırganın giriş kapısını tamamen kaçırmana yol açar. Bu derste web01'in nginx kaydını, dc01'in Windows olaylarını ve güvenlik duvarının epoch damgalarını tek eksene çekeceksin.

Önce her kaynağın zamanı nasıl yazdığını göreceksin. Sonra dönüştürme komutlarını, Türkiye'ye özgü saat tuzaklarını, olay zamanı ile alınma zamanı farkını ve saat sapmasını öğreneceksin. En sonda çok kaynaklı bir çizelgeyi doğru sırayla kuracak ve saatleri koruyan ayarları göreceksin.

Sorun şudur: her kaynak zamanı kendi biçiminde yazar. Klasik syslog (RFC 3164) ay, gün ve saat yazar; yıl da saat dilimi de yoktur. RFC 5424 ise RFC 3339 biçimini kullanır ve ofseti ekler.

Nginx $time_local ile yerel saati ofsetle, $time_iso8601 ile aynı bilgiyi ISO 8601 biçiminde verir. Windows EVTX kaydında SystemTime UTC'dir, ama Event Viewer onu yerel saate çevirip gösterir. Sysmon UtcTime alanını adından da anlaşılacağı gibi UTC yazar.

Zeek ağ kayıtlarında ts alanı ondalıklı epoch saniyesidir. journald ise -o short-iso ile yerel saati ofsetle, --utc ile UTC olarak basar. Aynı an bu kaynaklarda altı ayrı görünüm alır.

Kaynak             Alan ya da biçim            Aynı an
syslog (RFC 3164)  Mmm dd hh:mm:ss             Sep 14 03:02:11
syslog (RFC 5424)  RFC 3339, ofsetli           2026-09-14T03:02:11+03:00
nginx              $time_local                 14/Sep/2026:03:02:11 +0300
nginx              $time_iso8601               2026-09-14T03:02:11+03:00
Windows EVTX       SystemTime (UTC)            2026-09-14T00:02:11.0000000Z
Sysmon             UtcTime                     2026-09-14 00:02:11.482
Zeek               ts (epoch, ondalıklı)       1789344131.482913
journald           -o short-iso                2026-09-14T03:02:11+03:00

nginx     : [14/Sep/2026:03:02:11 +0300]      -> 2026-09-14T00:02:11Z
windows   : 2026-09-14 00:12:51Z (UTC)        -> 2026-09-14T00:12:51Z
firewall  : 1789344131                        -> 2026-09-14T00:02:11Z
TR yerel  : UTC + 3 saat (2016'dan beri yaz kış değişmez)

Ofset yönünü karıştırmak en sık yapılan hatadır. +0300 ifadesi, yerel saatin UTC'den üç saat ileride olduğunu söyler. UTC'ye dönmek için saatten üç saat çıkarırsın, eklemezsin. Tersini yaparsan olayı gerçek zamanından altı saat uzağa taşırsın ve çizelge baştan yanlış kurulur. Eksi ofset tersini yapar: -0500 yazan bir damgaya beş saat eklersin.

Kural tek cümledir: yerel saatten ofseti çıkar, UTC'yi bulursun. Ofset işaretini kendisi taşıdığı için kural hiç değişmez. Yön hatasını fark edene kadar saatlerce yanlış izi sürebilirsin. Bu yüzden her dönüşümden sonra bilinen bir olayla sağlama yap.

Araçlar da zamanı sessizce çevirir. Get-WinEvent çıktısındaki TimeCreated değeri, kayıttaki UTC anın makinenin yerel saatine çevrilmiş hâlidir. PowerShell'de .ToUniversalTime() ile UTC'ye döndürürsün. Tablolama programları da benzer davranır.

ISO biçimli bir damgayı açınca onu tarih sanıp kendi saat dilimine göre gösterebilir ya da ofseti atabilir. Başka bir ülkedeki ekip arkadaşın aynı dosyayı açtığında farklı bir saat görür. Güvenli yol, zaman alanını metin olarak tutmak ve UTC olduğunu alan adına yazmaktır: zaman_utc gibi. Kullandığın aracın varsayılanını bilinen bir olayla bir kez sına.

Dönüştürmeyi elle yapmazsın, araca yaptırırsın. GNU date epoch değerini @ işaretiyle alır ve -u ile UTC basar. Aynı komut ofsetli bir yerel saati de UTC'ye çevirir.

macOS ve BSD'deki date farklı çalışır; orada epoch için -r seçeneği kullanılır. Windows'ta PowerShell DateTimeOffset sınıfıyla, her yerde de Python'un datetime modülüyle aynı sonucu alırsın. Epoch değerinin uzunluğuna dikkat et.

Günümüz tarihlerinde on haneli bir değer saniyedir. On üç haneli bir değer milisaniyedir ve bine bölünmeden çevrilirse binlerce yıl ötesine düşer. Bazı araçlar on altı haneli mikrosaniye de yazar. Önce haneyi say, sonra birimi seç.

$ date -u -d @1789344131 +%FT%TZ
2026-09-14T00:02:11Z

$ date -u -d '2026-09-14 03:02:11 +0300' +%FT%TZ
2026-09-14T00:02:11Z

$ date -u -r 1789344131                      # macOS ve BSD
Mon Sep 14 00:02:11 UTC 2026

PS> [DateTimeOffset]::FromUnixTimeSeconds(1789344131).UtcDateTime
14 Eylül 2026 Pazartesi 00:02:11

$ python3 -c 'import datetime as d; print(d.datetime.fromtimestamp(1789344131, d.timezone.utc))'
2026-09-14 00:02:11+00:00

Tek tek çevirmek yerine bütün kaynağı bir kerede normalleştirirsin. Aşağıdaki gawk betiği nginx damgasını parçalarına ayırır ve mktime ile epoch'a çevirir.

mktime tarihi makinenin saat dilimine göre yorumlar; bu yüzden betik TZ=UTC ile çalışır ve ofset elle düşülür. Sonuç, her satırın başına eklenen ISO biçimli bir UTC alanıdır. Üç kaynağı da aynı biçime getirdikten sonra sort -m ile birleştirirsin. -m seçeneği zaten sıralı dosyaları yeniden sıralamadan birleştirir.

Ham damgayı satırda bırak. Dönüşümde hata bulursan ham değer elinde durduğu için işi baştan alırsın. Kaynağın adını da satıra yaz; tartışmalı bir satırın aslına saniyeler içinde dönersin.

$ TZ=UTC gawk '{
    split(substr($4, 2), p, /[\/:]/)
    ay = (index("JanFebMarAprMayJunJulAugSepOctNovDec", p[2]) + 2) / 3
    t = mktime(p[3] " " ay " " p[1] " " p[4] " " p[5] " " p[6])
    s = (substr($5, 1, 1) == "-") ? -1 : 1
    o = s * (substr($5, 2, 2) * 3600 + substr($5, 4, 2) * 60)
    print strftime("%Y-%m-%dT%H:%M:%SZ", t - o, 1), $0
  }' access.log > nginx.utc

$ sort -m nginx.utc windows.utc firewall.utc | head -5
2026-09-14T00:02:11Z 198.51.100.77 - - [14/Sep/2026:03:02:11 +0300] "GET /admin HTTP/1.1" 404 162 ...
2026-09-14T00:02:11Z firewall 198.51.100.77 -> 10.20.30.10:443 izin
2026-09-14T00:04:55Z 198.51.100.77 - - [14/Sep/2026:03:04:55 +0300] "POST /uploads/up.php HTTP/1.1" 200 34 ...
2026-09-14T00:12:51Z dc01 4624 mkaya LogonType=10 198.51.100.77
2026-09-14T00:15:02Z dc01 7045 AltayUpdateSvc C:\Users\Public\svc.exe

Türkiye 7 Eylül 2016'dan beri sabit UTC+3 kullanır ve yaz saati uygulamaz. Bu bilgi IANA saat dilimi veritabanında Europe/Istanbul adıyla kayıtlıdır. Güncel kayıtlar için çeviri tek bir çıkarma işlemidir.

Eski arşivlerde durum farklıdır. 2016'dan önce Türkiye kışın EET (UTC+2), yazın EEST (UTC+3) kullanıyordu. Ocak 2015'te yerel saatle yazılmış 10:00 damgası 08:00 UTC'ye, Temmuz 2015'teki aynı damga 07:00 UTC'ye denk gelir.

2016 öncesi bir kayıtta sabit +3 varsaymak bir saatlik hata üretir. Çözüm ofseti elle yazmak değil, saat dilimi adını kullanmaktır. Europe/Istanbul adını bilen bir araç o tarihteki kuralı kendisi uygular.

$ TZ=Europe/Istanbul date -d '2015-01-10 10:00' +'%F %T %z'
2015-01-10 10:00:00 +0200
$ TZ=Europe/Istanbul date -d '2015-07-10 10:00' +'%F %T %z'
2015-07-10 10:00:00 +0300
$ TZ=Europe/Istanbul date -d '2026-01-10 10:00' +'%F %T %z'
2026-01-10 10:00:00 +0300

Yaz saati uygulayan ülkelerin kayıtlarında ofset yıl içinde değişir. Avrupa'daki bir sunucunun mart ve kasım damgaları farklı ofset taşır. Geçiş gecesinde bir saat ya iki kez yaşanır ya da hiç yaşanmaz.

Orta Avrupa'da sonbaharda saat geri alındığında 02:30 damgası iki ayrı anı gösterebilir. Çok ülkeli ortamda ofseti sabit varsaymak sessiz ama büyük bir hatadır. Syslog'un eksik yılı da ayrı bir tuzaktır.

Yıl dönümünde toplanan bir dosyada aralık satırları ocak satırlarıyla karışır. Toplayıcı yılı kendi saatinden eklerse aralık kayıtları bir sonraki yıla taşınabilir. Yılı dosya adından, döndürme tarihinden ya da merkezî toplayıcının alınma zamanından doğrula.

İkinci tuzak kayıt gecikmesidir. Olayın olduğu an ile SIEM'e düştüğü an aynı değildir. Arada ajanın okuma aralığı, ağ, kuyruk ve ayrıştırma vardır.

Fark bazen saniyeler, bazen saatlerdir; makine ağdan kopmuşsa kayıtlar günler sonra gelebilir. Bu yüzden her kayıtta iki zaman alanı bulunur. Olay zamanı işin gerçekten olduğu andır. Alınma zamanı kaydın toplayıcıya ya da dizine vardığı andır.

Splunk'ta bu ikisi _time ve _indextime alanlarıdır. Microsoft Sentinel ve Log Analytics'te olay zamanı TimeGenerated, alınma zamanı _TimeReceived alanıdır. Sıralamayı olay zamanına göre yap. Alınma zamanına göre sıralarsan, ağ yavaşladığı anda hikâye ters döner.

index=guvenlik earliest=-24h
| eval gecikme = _indextime - _time
| stats count perc95(gecikme) AS p95 max(gecikme) AS enbuyuk by sourcetype
| sort - p95

sourcetype      count    p95   enbuyuk
WinEventLog     48211    41    9312
nginx:access    120544   4     38
linux:auth      9310     2     11

Sorgu her kayıt için alınma ile olay zamanı arasındaki farkı saniye olarak hesaplar. perc95 kayıtların yüzde 95'inin bu süre içinde geldiğini söyler.

Windows kayıtlarında 95. yüzdelik 41 saniyedir, ama en büyük gecikme iki buçuk saati aşar. Demek ki en az bir makine bir süre toplayıcıya ulaşamamıştır. Gecikme tespit kurallarını da etkiler.

Son beş dakikaya bakan ve her beş dakikada bir çalışan bir kural, geç gelen kaydı hiçbir turda görmeyebilir. Kural penceresini kaynağın gecikmesine göre ayarlamak bu yüzden bir tespit mühendisliği işidir. Aynı ölçümü Log Analytics'te ingestion_time() ile TimeGenerated farkından yaparsın.

Alınma zamanının işe yaradığı bir durum da vardır. Olay zamanını kaynak makine yazar. Makinenin saati kaymışsa olay zamanı da kayar. Toplayıcının saati ise genelde düzgündür, çünkü merkezî sunucular sıkı izlenir.

Bir kaynağın kayıtları alınma zamanından sonra olmuş görünüyorsa, yani olay zamanı gelecekteyse, o makinenin saati ileridedir. Gecikme değerinin aniden eksiye düşmesi sapmayı yakalamanın ucuz bir yoludur. Aynı sorgu bu yüzden hem geç gelen kaydı hem de ileri giden saati gösterir. Eksi gecikme gördüğünde o makinenin saat ayarını hemen kontrol et.

Üçüncü tuzak saat sapmasıdır. Her makinenin saati zamanla kayar. NTP kapalıysa ya da kaynağa ulaşamıyorsa birkaç ayda dakikalarca fark oluşur. Bu kaymayı bilmeden kurduğun çizelge olayları yanlış sıraya dizer ve seni yanlış makineye götürür.

Sapmayı ölçmek kolaydır. Linux'ta timedatectl status saatin eşitlenip eşitlenmediğini, chronyc tracking ise NTP saatine göre güncel farkı gösterir. Windows'ta w32tm /query /status zaman kaynağını ve son başarılı eşitlemeyi listeler.

Sapma kendi izini de bırakır. Kerberos, istemci ile DC arasındaki saat farkı ilkedeki toleransı aşarsa isteği reddeder. Varsayılan tolerans beş dakikadır ve hata KRB_AP_ERR_SKEW (0x25) koduyla kayda düşer.

depo01$ timedatectl status | grep -E 'Time zone|synchronized|NTP'
                Time zone: Europe/Istanbul (+03, +0300)
System clock synchronized: no
              NTP service: active

depo01$ chronyc tracking | grep -E 'Reference|System time'
Reference ID    : C0000201 (ntp1.altaykargo.example)
System time     : 241.337209702 seconds slow of NTP time

Sapmayı ölçtükten sonra düzeltmeyi yaz ve o makinenin bütün damgalarına aynı değeri uygula. depo01 saati 241 saniye gerideyse, o makinenin her damgasına 241 saniye eklersin. Çizelgede her satır kaynağını taşısın: dosya adı, makine ve ham damga.

ISO 8601 biçimi burada işini kolaylaştırır. En büyük birim en solda durduğu için metin sıralaması zaman sıralamasıyla aynı sonucu verir. Eşit damgalar ayrı bir sorundur.

Saniye çözünürlüğü kalabalık sistemlerde yetmez; kaynağın milisaniye yazıp yazmadığını kontrol et. Yazmıyorsa sırayı olay mantığıyla düzelt, çünkü giriş, komut ve çıkış sırası değişmez. Çok sayıda kaynak için Plaso (log2timeline) bütün delillerden tek bir süper zaman çizelgesi üretir. Timesketch'te ise ekip bu çizelgeyi birlikte inceler.

Savunma tarafı basittir ama disiplin ister. Bütün sunucular aynı iç NTP kaynağına bağlanır ve eşitleme durumu izlenir. Sapma belirli bir eşiği, örneğin bir saniyeyi aşarsa alarm üretilir.

Windows etki alanında üyeler saatini DC'den alır. Orman kökündeki PDC öykünücüsü rolünü taşıyan DC ise güvenilir bir dış kaynağa bağlanır.

Toplayıcı her kayda normalleştirilmiş bir UTC alanı ekler ve ham damgayı da saklar. Bu ayarlar olaydan önce yapılır; olay anında geriye dönük düzeltme hem zaman alır hem tartışma yaratır. NIST'in log yönetimi planlama rehberi de (SP 800-92 Rev. 1 taslağı) log yönetimini olaydan önce planlanan bir iş olarak ele alır.