Denetim günlükleri neden önemli ve nasıl saklanır

Denetim Günlüğü Nedir ve Neden İhtiyacınız Var?

Denetim günlüğü (Audit Log), sunucu, veritabanı veya uygulamadaki önemli olayların kaydıdır ve size kimin, ne zaman, nereden ve ne yaptığını gösterir. Bu günlükler, normal sistem günlüklerinden (syslog gibi) farklıdır; çünkü bilinçli olarak üç soruyu yanıtlamak için tasarlanırlar: "Kötü bir şey mi oldu?", "Kim sorumlu?" ve "Tekrarını nasıl önlerim?".

Birçok sunucu yöneticisi yalnızca hata günlüklerine bakar ve güvenliklerinin sağlandığını düşünür. Ancak gerçek bir saldırıda, saldırgan genellikle önce iz bırakmamak için günlükleri siler. Denetim günlüğünüz aynı sunucuda ve root erişimiyle saklanıyorsa, pratikte işe yaramaz. Bu makalede hangi olayları kaydetmeniz gerektiğini, günlükleri nerede tutmanız gerektiğini ve kimsenin bunları değiştiremediğinden nasıl emin olacağınızı öğreneceksiniz.

Denetim Günlüğünde Hangi Olayları Kaydetmeliyiz?

Her şeyi kaydetmek, günlüklerin o kadar hacimli olmasına neden olur ki önemli olayı bulamazsınız. Altın kural şudur: Bir olayı yeniden yapılandırmak için gereken her şeyi kaydedin, daha fazlasını değil. Aşağıda gerekli olayların bir listesi bulunmaktadır.

Kimlik Doğrulama ve Erişim Olayları

• Sisteme başarılı ve başarısız girişler (SSH, konsol, yönetim paneli)
• Kullanıcı veya yönetici tarafından şifre değişikliği
• Kullanıcıların ve grupların oluşturulması, silinmesi veya erişim değişiklikleri
• Yetki yükseltmek için sudo veya su kullanımı
• Yüksek riskli hesaplarla (veritabanı root'u gibi) veritabanına bağlanma

Örnek: Linux'ta, tüm sudo komutlarını ayrı bir dosyada kaydetmek için aşağıdaki komutu etkinleştirin:

# /etc/sudoers.d/audit
Defaults logfile=/var/log/sudo-audit.log
Defaults log_input, log_output

Bu ayarla, sudo ile çalıştırılan her komut, çıktısıyla birlikte kaydedilir. Bu, yönetim erişiminin kötüye kullanımını tespit etmede çok etkilidir.

Yapılandırma Değişiklikleri ve Kritik Dosyalar

• /etc/passwd, /etc/shadow ve /etc/ssh/sshd_config dosyalarındaki değişiklikler
• Yazılım paketlerinin kurulumu veya kaldırılması
• Güvenlik duvarı kurallarındaki değişiklikler (iptables, nftables, ufw)
• cron jobs veya systemd timers değişiklikleri

Hassas dosyalardaki değişiklikleri izlemek için auditd aracını kullanın:

auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config_change
auditctl -w /etc/passwd -p wa -k user_db_change

-p wa parametresi, yazma ve öznitelik değişikliği olaylarının kaydedilmesi anlamına gelir. -k etiketi, olayları ausearch -k sshd_config_change ile aramanıza olanak tanır.

Ağ ve Hizmet Olayları

• Sunucuda yeni portların açılması
• Hassas portlara (MySQL için 3306 gibi) olağandışı bağlantılar
• Kritik hizmetlerin (nginx, apache, mysql) başlatılması veya durdurulması
• Şüpheli IP adreslerine (Tor ağları veya yaptırım uygulanan IP'ler gibi) bağlanma girişimleri

Yeni bağlantıları kaydetmek için ss komutunu cron ile kullanabilirsiniz, ancak daha profesyonel bir yöntem, soketleri izlemek için auditd kullanmaktır:

auditctl -a always,exit -F arch=b64 -S bind -S connect -k network_connections

Denetim Günlüğünü Nasıl Değiştirilmez Hale Getiririz?

Olayları kaydetmek işin sadece yarısıdır. Saldırgan günlükleri silebiliyorsa, hiçbir şey olmamış gibidir. Aşağıda üç koruma katmanını açıklıyoruz.

1. Sunucu Dışında Saklama (Merkezi Günlükleme)

Denetim günlüğünü asla yalnızca olayların gerçekleştiği sunucuda saklamayın. Root yetkisi alan bir saldırgan rm -rf /var/log komutunu çalıştırıp her şeyi silebilir. Standart çözüm, günlükleri merkezi bir sunucuya göndermektir.

En basit yöntem rsyslog kullanmaktır. Merkezi sunucuda (örneğin IP 192.168.1.10), /etc/rsyslog.conf dosyasına aşağıdaki satırı ekleyin:

# Merkezi sunucuda
module(load="imtcp")
input(type="imtcp" port="514")
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

Ve istemci sunucularda:

# İstemci sunucuda
*.* @@192.168.1.10:514

Önemli not: Merkezi sunucu, SSH erişimini yalnızca belirli IP'lerden kabul etmeli ve güvenlik zincirini kırmamak için kendi günlüklerini de başka bir yere göndermelidir.

2. Dijital İmza ve Değişikliği Önleme (WORM Depolama)

Günlükleri başka bir sunucuya göndermek saldırganı durdurmaz; çünkü o sunucuya da erişim sağlarsa günlükleri değiştirebilir. Daha güçlü bir çözüm, WORM (Write Once Read Many) depolama kullanmaktır. Bu yöntemde, günlük dosyası yalnızca bir kez yazılır ve hiç kimse (root bile) onu değiştiremez.

Linux'ta, yalnızca eklemeye (append) izin veren chattr +a özelliğini kullanabilirsiniz:

chattr +a /var/log/audit/audit.log

Ancak bu yöntem de tam değildir; çünkü saldırgan dosyayı silip yeniden oluşturabilir. Tam koruma için, dosyayı mount -o remount,ro seçeneğiyle ayrı bir bölüme koymanız veya max_log_file_action = keep_logs özelliğine sahip auditd gibi araçlar kullanmanız gerekir.

Daha profesyonel bir yöntem, günlükleri Object Lock özelliğine sahip bir bulut hizmetine göndermektir. S3 Object Lock veya Azure Immutable Blob Storage gibi hizmetler, kilit süresi (örneğin 1 yıl) belirlemenize olanak tanır. Bu süre boyunca hiç kimse günlükleri silemez veya değiştiremez. Bulut altyapısı kullanıyorsanız, bu seçeneği mutlaka değerlendirin.

3. Günlüklerin Döndürülmesi ve Uzun Süreli Saklanması

Denetim günlüğü, en az güvenlik inceleme periyodunuz kadar saklanmalıdır. PCI-DSS gibi yaygın standartlar, 1 yıl saklama ve 3 ay çevrimiçi erişim gerektirir. Günlüklerin otomatik döndürülmesi için logrotate kullanın:

# /etc/logrotate.d/audit
/var/log/audit/audit.log {
    weekly
    rotate 52
    compress
    delaycompress
    notifempty
    missingok
}

Bu ayar, günlükleri haftalık olarak döndürür ve 52 kopya (bir yıl) saklar. Sıkıştırılmış dosyaları da merkezi sunucuya aktarabilirsiniz.

Denetim Günlüğü Saklamada Yaygın Hatalar

Aşağıda, genellikle günlük güvenliğini bozan birkaç yaygın hatayı gözden geçiriyoruz.

Hata 1: Günlükleri Sistemle Aynı Bölümde Saklamak

/var/log root bölümündeyse, diskin dolması tüm sistemi çökertebilir. Saldırgan ayrıca diski kasıtlı olarak doldurarak hizmetleri bozabilir. Çözüm: /var/log için ayrı bir bölüm ayırın ve boyutunu izleyin.

Hata 2: Başarısız Girişimleri Kaydetmemek

Birçok yönetici yalnızca başarılı olayları kaydeder. Ancak başarısız girişimler (yanlış şifreyle giriş gibi), brute-force saldırısının erken belirtileridir. auditd'de, failed sonuçlu USER_LOGIN olaylarının da kaydedildiğinden emin olun:

auditctl -a always,exit -F arch=b64 -S execve -F success!=1 -k failed_commands

Hata 3: Zaman Damgasını (Timestamp) Göz Ardı Etmek

Sunucu saati doğru değilse, bir saldırıda olayların sırasını yeniden oluşturmak imkansız hale gelir. NTP'yi mutlaka etkinleştirin ve saatin güvenilir bir kaynakla senkronize olduğundan emin olun:

timedatectl set-ntp true
timedatectl status

Olay Müdahalesinde Denetim Günlüğü Nasıl Kullanılır?

Bir olay meydana geldiğinde, ilk iş herhangi bir işlem yapmadan önce günlükleri kopyalamaktır. Sunucuyu yeniden başlatır veya hizmetleri durdurursanız, kanıtlar kaybolabilir. Önerilen adımlar:

1. Disk görüntüsü alma veya günlük dosyalarını ayrı bir ortama kopyalama
2. Saldırganın kullanıcı hesabıyla ilgili olayları arama: ausearch -ua username
3. Olay sırasındaki ağ bağlantılarını inceleme: ausearch -k network_connections -ts recent
4. Manipülasyonu tespit etmek için merkezi sunucu günlüklerini yerel günlüklerle karşılaştırma

Önemli not: Yerel ve merkezi günlükler farklıysa, saldırgan yerel günlüğü değiştirmiş demektir. Bu da başlı başına bir saldırı belirtisidir.

Denetim Günlüğü Yönetimi için Yardımcı Araçlar

Yüksek hacimli günlükler için aşağıdaki araçları göz önünde bulundurun:

• auditd: Linux için standart güvenlik denetim aracı
• rsyslog veya syslog-ng: Günlüklerin merkezi olarak aktarılması için
• SIEM (Wazuh veya Elastic Stack gibi): Otomatik analiz ve uyarı için
• logrotate: Dosya boyutunu ve döndürmeyi yönetmek için

Altyapınız bulut sunucularındaysa, bulut tabanlı günlük yönetimi hizmetlerini kullanabilirsiniz. ServerNet, barındırma platformlarında günlüklerin harici bir hedefe gönderilmesini sağlar; bu da merkezi mimari uygulamak için uygundur.

Özet

Denetim günlüğü yalnızca bir metin dosyası değildir; kritik bir savunma aracıdır. Gerçekten etkili olması için üç özelliğe sahip olmalıdır: eksiksiz (önemli olayları kaydetmeli), merkezi (ana sunucunun dışında saklanmalı) ve değiştirilemez (kimse onu manipüle edememeli). Bu makalede açıklanan yöntemleri uygulayarak, bir saldırı durumunda saldırganı tespit etmek ve olayın tekrarını önlemek için yeterli kanıta sahip olduğunuzdan emin olabilirsiniz.

Bugünden başlayın: Önce sunucunuzdaki kritik olayların listesini belirleyin, ardından günlükleri merkezi bir sunucuya göndermeyi kurun ve son olarak uzun vadeli bir döndürme ve saklama planı ayarlayın. Bu üç basit adım, güvenliğinizi önemli ölçüde artıracaktır.