NTP ve saat farkı: kimlik doğrulama ile olay zaman çizelgesini birlikte düzeltmek

Bir olayın güvenlik duvarında ve sunucuda farklı saatlerde görünmesi, iki farklı olay yaşandığı anlamına gelmeyebilir. Saat dilimi, NTP sapması ve SIEM’in zaman alanını yorumlama biçimi ayrı nedenlerdir. Sağlıklı bir zaman çizelgesi için önce her katmanın zamanı nasıl ürettiği anlaşılmalıdır.

1. Saat ve bölgeyi ölç
2. Kaynağı belirle
3. Senkronizasyonu incele
4. Zaman sapmasını düzelt
5. Günlükleri karşılaştır
6. Alarm ve kanıtı doğrula

Saat dilimi ile saat sapmasını ayırın

Yerel saat doğru görünürken UTC zamanı veya saat dilimi yanlış olabilir. Ekran görüntüsünde yalnızca saat göstermek bu farkı saklar. Kanıt kaydında tarih, saat, zaman dilimi ve mümkünse UTC karşılığı bulunmalıdır.

Saatin elle değiştirilmesi geçici görünür bir düzelme sağlayabilir; ancak çalışan kimlik doğrulama ve uygulama işlemlerini etkileyebilir. Yönetilen ortamda kalıcı çözüm yetkili zaman kaynağı ve senkronizasyon yolunu düzeltmektir.

date -Is
date -u -Is
timedatectl status
chronyc tracking
chronyc sources -v

Kullanılan zaman istemcisini belirleyin

Linux dağıtımı ve sürümüne göre chrony, systemd-timesyncd veya başka bir istemci kullanılabilir. Her Ubuntu sürümünün aynı varsayılanla geldiğini varsaymayın. Birden fazla istemcinin aynı anda saati yönetmediğini kontrol edin.

Windows etki alanında zaman hiyerarşisi ve PDC Emulator rolü ayrıca önemlidir. Sanallaştırma araçlarının saat düzeltmesiyle işletim sisteminin NTP davranışının çelişip çelişmediği değerlendirilmelidir.

Kaynağa erişimi ve güvenilirliği inceleyin

NTP sunucusunun çözümlenmesi, ağ yolunun açık olması ve kaynağın kullanılabilir görünmesi ayrı kontrollerdir. Paket kaybı veya yanlış güvenlik duvarı kuralı senkronizasyonu engelleyebilir. Kaynak adı doğru olsa da istemcinin gerçekten ona kilitlendiği kontrol edilmelidir.

Bir sistemin saatinin diğerine benzemesi ikisinin de doğru olduğunu kanıtlamaz. Ortak ve güvenilir zaman referansı seçin. İzole ağlar için dış zaman bağımlılığı ve iç dağıtım tasarımı önceden belirlenmelidir.

Olay saatini alım saatinden ayırın

SIEM, olayın kaynak zamanını ve platforma geliş zamanını ayrı tutabilir. Kuyrukta bekleyen kayıtlar sonradan geldiğinde gecikme, saat sapması gibi görünebilir. Parser zaman dilimini yanlış yorumluyorsa kaynağın saatini değiştirmek sorunu büyütür.

Aynı test olayını kaynak günlükte, taşıma katmanında ve SIEM aramasında karşılaştırın. Ham zaman damgasını, normalleştirilmiş alanı ve alım zamanını kaydedin. Değişiklikten önceki kayıtları yeni ayara göre sessizce yeniden yorumlamayın.

Kapanış için sürekli ölçüm kurun

Düzeltme sonrasında yalnızca tek ölçüm almayın. Yeniden açılış, ağ kesintisi ve kaynak değişimi sonrasındaki davranışı izleyin. Kimlik doğrulama ve zaman tabanlı görevlerin beklenen biçimde çalıştığını sınayın.

• Yetkili kaynak ve sorumlusu kayıtlı.
• Sapma belirlenen eşik altında.
• Zaman dilimi parser ile tutarlı.
• Kaynak zamanı ve alım gecikmesi ayrı izleniyor.
• Saat elle değiştirilmeden senkronizasyon sürüyor.

İlgili çalışma notları

• Linux’ta Trellix Agent kurulumu: doğru paket, güvenilir indirme ve ePO kabulü
• VPN ve syslog kayıtları: IPsec üzerinden doğru kaynak kimliğiyle toplamak
• SIEM’e yeni log kaynağı ekleme: envanter, EPS ve parser kabulü

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: Yazıda belirtilen ürün ve desteklenen pilot ortam — Yetkili izole pilot, belirtilen sürüm/model desteği, mevcut durum kaydı ve değişiklik gerekiyorsa tutarlı yedek/geri erişim gerekir.

1. Saat, zone ve kaynak durumunu okuyun
2. Kaynak erişimini ve servis sorumluluğunu belirleyin
3. Desteklenen kaynak ayarını düzenleyin
4. Yeni ölçümleri ve kimlik işlevini karşılaştırın
5. Geri dönüş ve zaman çizelgesini koruyun

1. Saat, zone ve kaynak durumunu okuyun

Linux chrony örneğinde timezone ile saat senkronizasyonu farklıdır. Olayları karşılaştırırken UTC kaydını kullanın.

date -Is
timedatectl status
chronyc tracking
chronyc sources -v

2. Kaynak erişimini ve servis sorumluluğunu belirleyin

Chrony, systemd-timesyncd veya başka tek NTP istemcisi kullanılıyor olmalı; aynı host’ta ikinci bağımsız saat istemcisi kurmayın. Firewall/DNS ve hipervizör saat etkisini karşılaştırın.

3. Desteklenen kaynak ayarını düzenleyin

Dağıtımın chrony config dosyasında onaylı NTP server/pool tanımını mevcut ayar yedeğiyle değiştirin. Saatte büyük sıçrama kimlik doğrulama/veri tabanı etkisi doğurabilir; canlı makinede plansız date veya makestep çalıştırmayın.

4. Yeni ölçümleri ve kimlik işlevini karşılaştırın

Kaynak seçimi, offset ve senkron durumuyla birlikte Kerberos/TLS/log korelasyonunu doğrulayın. Windows karşılaştırmasında aşağıdaki salt okumalar kullanılabilir.

w32tm /query /status
w32tm /query /source
w32tm /query /peers

5. Geri dönüş ve zaman çizelgesini koruyun

Önceki tek NTP config sürümüne dönün; eski offset’i elle geri vermeyin. Değişiklik anını UTC ile kaydedin; eski log timestamp’lerini yeni saate göre değiştirmeyin.

Beklenen sonuç: Tek yetkili saat kaynağı senkron durumdadır; UTC olay ve kimlik doğrulama sonuçları tutarlıdır.

Sonuç farklıysa: Başarısız aşamada durun; ilgili kayıt/ürün sürümü/ön koşulu inceleyin. Farklı katmanı genel olarak sıfırlamak yerine tek nedeni ayırın.

Geri dönüş: Yalnız bu işlemde değişen öğeyi önceki uyumlu sürüm veya açıkça belirtilen yedek/restore planıyla geri alın; geri alınamaz veri/disk işlemlerini ayar geri dönüşü sanmayın.