Yazar: Selçuk Dikici¹²³⁴

¹ Anadolu Üniversitesi, İşletme Fakültesi, İşletme Bölümü, Eskişehir, Türkiye ² İstanbul Üniversitesi, Mühendislik Fakültesi, Endüstri Mühendisliği Bölümü, İstanbul, Türkiye ³ Anadolu Üniversitesi, Adalet Meslek Yüksekokulu, Eskişehir, Türkiye ⁴ Abant İzzet Baysal Üniversitesi, Düzce Meslek Yüksekokulu, Endüstriyel Elektronik Bölümü, Bolu, Türkiye

---

UYARI VE ETİK SORUMLULUK BEYANI

BU KİTAPÇIKTA YER ALAN BİLGİLER, SADECE EĞİTİM, ARAŞTIRMA VE SİMÜLE EDİLMİŞ LABORATUVAR ORTAMLARINDA TEST EDİLMEK ÜZERE HAZIRLANMIŞTIR. GERÇEK SİSTEMLER ÜZERİNDE YETKİSİZ VE YASADIŞI HER TÜRLÜ LOG MANİPÜLASYONU, SİLME VEYA DEĞİŞTİRME FAALİYETİ CİDDİ HUKUKİ SONUÇLARA (CEZAİ VE HUKUKİ YAPTIRIMLARA) YOL AÇAR VE SUÇ TEŞKİL EDER. ULUSAL VE ULUSLARARASI MEVZUATA (KVKK, GDPR VB.) RİAYET ETMEK HER KULLANICININ YÜKÜMLÜLÜĞÜNDEDİR. BU KİTAPÇIĞIN KÖTÜYE KULLANIMINDAN YAZAR VEYA YAYINCI SORUMLU TUTULAMAZ.

---

İÇİNDEKİLER

1. Giriş: Log Yönetiminin Önemi 1.1. Neden Log Tutarız? 1.2. ISP Loglarının Yapısı ve Kapsamı 1.3. Bu Kitapçığın Amacı
2. ISP Loglarının Temel Kaynakları ve Yönetimi 2.1. RADIUS / AAA Sunucuları (Kimlik Doğrulama ve Muhasebe Kayıtları) 2.1.1. Amaç ve İşleyiş 2.1.2. Kayıt Türleri ve Kapsamları 2.1.3. Yaygın Sistemler ve Log Yapıları 2.1.4. Veritabanı Entegrasyonu ve Sorgulama 2.1.5. İz Silme Yöntemleri (Teorik ve Riskler) 2.2. SYSLOG Sunucuları (Merkezi Sistem ve Ağ Logları) 2.2.1. Syslog Protokolü Nedir? 2.2.2. Dosya Yapısı ve Log Dizinleri (Linux) 2.2.3. Rsyslog.conf Dosyası Yapılandırması 2.2.4. Syslog Sunucusu Kurulumu (rsyslog) 2.2.5. Log Formatları ve Yorumlama 2.2.6. Log Sorgulama ve Filtreleme Komutları 2.2.7. Syslog Verilerini Uzak Sunucuya Gönderme 2.2.8. Syslog Loglarını Silme ve Manipüle Etme (Teorik ve Riskler) 2.2.9. Log Rotasyonu ve Saklama Politikaları 2.2.10. Web Tabanlı Arayüzler (Opsiyonel) 2.3. Deep Packet Inspection (DPI) Sistemleri (Derin Paket Analizi) 2.3.1. Tanım ve Amaçlar 2.3.2. DPI Sistem Mimarisi ve Bileşenleri 2.3.3. Açık Kaynak DPI Araçları (nDPI, OpenDPI) 2.3.4. Trafik Analizi Senaryoları ve Uygulamaları 2.3.5. Ticari DPI Sistemleri 2.3.6. Trafik Engelleme & Şekillendirme (QoS) 2.3.7. DPI ile Loglama ve İzleme Entegrasyonu 2.3.8. IDS/IPS ile Entegrasyon 2.3.9. Gizlilik ve Etik Tartışmalar (Yasal Sınırlar) 2.3.10. DPI Sistemlerinin Saldırıya Açık Noktaları ve Karşı Önlemler 2.4. Veritabanı Sunucuları (DPI Log Depolama ve Sorgulama) 2.4.1. Amaçlar ve Yaygın Sistemler 2.4.2. DPI Log Format Yapısı 2.4.3. PostgreSQL Entegrasyonu (Kurulum, Veritabanı/Kullanıcı Oluşturma) 2.4.4. PostgreSQL Tablo Yapısı ve Sorgular (Ekleme, Silme, Temel Sorgular) 2.4.5. Gelişmiş PostgreSQL Sorguları (Analitik Örnekler) 2.4.6. MongoDB Entegrasyonu (Kurulum, Veritabanı/Koleksiyon Oluşturma, Ekleme, Silme) 2.4.7. MongoDB Sorguları 2.4.8. Performans ve Optimizasyon (İndeksleme, Arşivleme) 2.4.9. Yedekleme ve Replikasyon Stratejileri 2.4.10. Güvenlik ve KVKK Uyumluluğu 2.4.11. Grafana ve Monitöring Entegrasyonu 2.4.12. SIEM Entegrasyonu (Veritabanı Loglarının Önemi) 2.4.13. Örnek Senaryo: IP Saklama ve Silme İşlemi (Uygulamalı) 2.4.14. Periyodik Temizlik ve Otomasyon (Cronjob Örnekleri)
3. SIEM Sistemleri (Security Information and Event Management) 3.1. Giriş: SIEM Nedir ve Neden Önemlidir? 3.2. SIEM Temel Bileşenleri (Log Toplama, Normalizasyon, Korelasyon, Alarm, Depolama, Raporlama) 3.3. SIEM Yazılımları ve Teknolojileri (Açık Kaynak ve Ticari Çözümler) 3.4. SIEM Kurulum ve Yapılandırma Adımları (Örnek: Elastic Stack + Wazuh) 3.4.1. Elasticsearch Kurulumu 3.4.2. Logstash Kurulumu ve Basit Konfigürasyon 3.4.3. Kibana Kurulumu ve Çalıştırılması 3.4.4. Wazuh Agent ve Manager Kurulumu 3.5. SIEM Log Yönetimi Komutları (Syslog ve Journalctl) 3.6. Log Analizi ve Korelasyon Örnekleri (Elasticsearch Query DSL) 3.7. SIEM Alarmları ve Kural Yazımı (Wazuh Örneği) 3.8. SIEM Raporlama (Kibana Dashboard, Splunk Query Örnekleri) 3.9. SIEM Güvenlik ve Performans İpuçları 3.10. Örnek Komutlar ve Snippetler (Toplu Bakım ve Kontrol) 3.11. Kaynaklar ve İleri Okumalar
4. İz Bırakmadan Erişim Mümkün mü? Logların Kalıcılığı ve Adli Bilişim Perspektifi 4.1. RADIUS Sunucuları ve İz Kalıcılığı 4.2. Syslog Sistemleri ve İz Manipülasyon Riski 4.3. Deep Packet Inspection (DPI) Sistemleri ve Yüksek İzleme Yeteneği 4.4. Veritabanı Sistemleri ve Değişiklik Takibi 4.5. SIEM Sistemleri ve Kapsamlı İz Kaydı 4.6. Sonuç: Modern Altyapılarda İz Bırakmama Çabalarının Sonuçları
5. Sonuç ve Genel Değerlendirme 5.1. Etkili Log Yönetimi İlkeleri 5.2. Gelecek Trendler ve Gelişmeler

---

1. Giriş: Log Yönetiminin Önemi

Günümüzün dijital çağında, ağlar ve sistemler üzerindeki her aktivite bir iz bırakır. Bu izler, “log” adı verilen kayıtlarda saklanır. Loglar, bir sistemin veya ağın nasıl çalıştığına dair kritik bilgiler içeren zaman damgalı olay kayıtlarıdır. İnternet Servis Sağlayıcıları (ISP’ler) gibi büyük altyapılarda, milyonlarca kullanıcının her gün yaptığı milyarlarca işlem loglanır. Bu loglar, hem operasyonel verimlilik hem de güvenlik ve yasal uyumluluk açısından hayati öneme sahiptir.

1.1. Neden Log Tutarız? Log tutmanın başlıca nedenleri şunlardır:

• Güvenlik Denetimi ve Olay Tespiti: Saldırıları, yetkisiz erişimleri, kötü amaçlı yazılımları ve anormal davranışları tespit etmek.
• Adli Bilişim (Forensics): Bir güvenlik ihlali veya yasa dışı aktivite durumunda olayın kökenini, kapsamını ve etkisini araştırmak için delil toplamak.
• Performans İzleme ve Sorun Giderme: Sistem ve ağ performansını izleyerek darboğazları tespit etmek, hataları ve kesintileri gidermek.
• Yasal Uyum ve Düzenlemeler: KVKK (Kişisel Verilerin Korunması Kanunu), GDPR (Genel Veri Koruma Tüzüğü) ve diğer ulusal/uluslararası düzenlemelere uyum sağlamak. Çoğu ülke, belirli sürelerle veri loglarının tutulmasını yasal zorunluluk haline getirmiştir.
• Kapasite Planlaması ve Trend Analizi: Geçmiş verilere dayanarak gelecekteki ihtiyaçları tahmin etmek ve sistemleri optimize etmek.

1.2. ISP Loglarının Yapısı ve Kapsamı ISP’ler, internet erişimi sağladıkları için çok çeşitli log türleri tutar. Bunlar arasında:

• Bağlantı Logları: Kimin (kullanıcı adı, MAC adresi), ne zaman (oturum başlama/bitiş zamanı), hangi IP adresiyle bağlandığı.
• Trafik Logları: Hangi kaynak IP’den hangi hedef IP’ye ne kadar veri aktarıldığı, hangi protokollerin (HTTP, DNS, VPN vb.) kullanıldığı.
• DNS Sorgu Logları: Hangi kullanıcıların hangi alan adlarına (web sitelerine) erişmeye çalıştığı.
• Hata Logları: Sistem veya ağ bileşenlerindeki sorunlar, başarısız oturum açma denemeleri.

1.3. Bu Kitapçığın Amacı Bu kitapçık, ISP loglarının farklı kaynaklardan nasıl toplandığını, yönetildiğini ve depolandığını teknik düzeyde açıklamayı hedeflemektedir. Özellikle RADIUS/AAA sunucuları, Syslog sunucuları, Deep Packet Inspection (DPI) sistemleri ve veritabanı sunucuları gibi ana kaynaklar ele alınacaktır. Kitapçık, bu logların teorik olarak nasıl manipüle edilebileceği veya silinebileceği yöntemleri sunarken, aynı zamanda modern SIEM sistemlerinin logların kalıcılığını ve adli bilişim açısından izlerin neredeyse tamamen ortadan kaldırılamazlığını nasıl sağladığını da detaylandıracaktır.

ÖNEMLİ UYARI TEKRARI: BURADA SUNULAN TÜM TEKNİK BİLGİLER SADECE AKADEMİK VE EĞİTİM AMAÇLIDIR. GERÇEK SİSTEMLER ÜZERİNDE YETKİSİZ MÜDAHALE KESİNLİKLE YASAK VE SUÇTUR.

---

2. ISP Loglarının Temel Kaynakları ve Yönetimi

ISP’ler, farklı hizmet katmanlarında farklı türde loglar üreten çeşitli sunucu ve sistem bileşenleri kullanır. Bu bölümde, başlıca log kaynakları ve bu logların nasıl yönetildiği teknik detaylarıyla incelenecektir.

2.1. RADIUS / AAA Sunucuları (Kimlik Doğrulama ve Muhasebe Kayıtları)

RADIUS (Remote Authentication Dial-In User Service) ve AAA (Authentication, Authorization, Accounting) sistemleri, ağ erişimi sağlayan servislerde kullanıcı kimlik doğrulama, yetkilendirme ve oturum muhasebesi işlemlerini merkezi olarak yöneten kritik bileşenlerdir. ISP’ler için internete bağlanan her kullanıcının oturum bilgilerini kaydederler.

2.1.1. Amaç ve İşleyiş

• Authentication (Kimlik Doğrulama): Bir kullanıcının kim olduğunu doğrular (örneğin, kullanıcı adı ve şifre ile).
• Authorization (Yetkilendirme): Kullanıcının hangi hizmetlere erişebileceğini ve ne kadar bant genişliği kullanabileceğini belirler.
• Accounting (Muhasebe): Kullanıcının oturum süresi, veri transfer miktarı, kullanılan IP adresi gibi oturum bilgilerini kaydeder. İşte bu kısım, ISP’ler için en kritik loglama alanıdır.

2.1.2. Kayıt Türleri ve Kapsamları RADIUS/AAA sunucuları tarafından tutulan temel kayıt türleri şunlardır:

• IP Adresi: Kullanıcıya atanan veya kullanıcının kullandığı IP adresi (genellikle dinamik olarak atanır).
• Oturum Başlama/Bitiş Zamanı: Kullanıcının internete bağlandığı ve bağlantısının kesildiği tam zaman damgası.
• MAC Adresi: Kullanıcının cihazının fiziksel adresi (Network Access Server – NAS üzerinden alınabilir).
• Kullanıcı Adı: Müşteri hesap numarası veya özel bir tanımlayıcı.
• Aktarılan Veri Miktarı: Oturum boyunca gönderilen ve alınan veri (byte) miktarı.
• NAS Port Bilgisi: Kullanıcının hangi erişim noktasından (modem/router portu) bağlandığı.

2.1.3. Yaygın Sistemler ve Log Yapıları

• FreeRADIUS: Açık kaynaklı ve en yaygın kullanılan RADIUS sunucularından biridir. Logları genellikle /var/log/freeradius/radius.log dosyasında tutar. Detaylı muhasebe kayıtları ise /var/log/freeradius/radacct/<client_ip>/detail gibi dizinlerde bulunabilir.
• Cisco ISE (Identity Services Engine): Kurumsal seviyede AAA hizmetleri sunan ticari bir çözümdür. Loglarını merkezi bir veritabanında veya syslog sunucularına yönlendirerek tutar.
• Windows NPS (Network Policy Server): Microsoft tabanlı ağlarda RADIUS işlevselliği sağlar. Loglar genellikle Event Viewer’da veya belirlenmiş log dosyalarında tutulur.
• Radiator: Yüksek performanslı ve esnek bir RADIUS sunucusudur.

🧪 Komut Örneği: Bağlantı Geçmişini Görme (FreeRADIUS)

Bash

cat /var/log/freeradius/radacct/<client_ip>/detail

Bu komut, belirli bir istemci IP adresine ait detaylı muhasebe kayıtlarını gösterir.

2.1.4. Veritabanı Entegrasyonu ve Sorgulama Birçok RADIUS sistemi, log verilerini daha verimli bir şekilde depolamak ve sorgulamak için PostgreSQL, MySQL gibi veritabanları ile entegre çalışır. Bu, büyük hacimli verilerin yönetilmesini ve karmaşık sorguların çalıştırılmasını sağlar.

• PostgreSQL Örneği: radacct tablosu, muhasebe kayıtlarını içerir.

SQL

SELECT * FROM radacct WHERE username='userX' ORDER BY acctstarttime DESC;

Bu sorgu, ‘userX’ adlı kullanıcının tüm oturum kayıtlarını en yeniden eskiye doğru sıralar.

2.1.5. İz Silme Yöntemleri (Teorik ve Riskler) RADIUS logları, sistemin kritik güvenlik ve muhasebe kayıtları olduğundan, tasarımları gereği kolayca silinemez veya değiştirilemez yapıdadır. Ancak, yetkili bir yönetici tarafından veritabanı veya dosya sistemi üzerinde doğrudan müdahale ile teorik olarak silinebilirler.

🛠️ İz Silme (Teorik Uygulama – Veritabanı Örneği):

SQL

DELETE FROM radacct WHERE username='userX' AND acctstarttime BETWEEN '2025-07-10' AND '2025-07-12';

Bu SQL komutu, ‘userX’ kullanıcısının belirli bir tarih aralığındaki tüm muhasebe kayıtlarını radacct tablosundan siler. Riskler:

• Adli İz Bırakma: Veritabanı işlemleri (DELETE komutu dahil) genellikle veritabanının kendi denetim loglarına (audit logs) kaydedilir. Bu, silme işleminin kendisinin bir iz bırakmasına neden olur.
• Veri Bütünlüğü: Oturum açılış-kapanış kayıtları arasındaki tutarsızlıklar, sistemin normal işleyişini bozar ve anormallik olarak alarm üretebilir.
• Yasal Sonuçlar: Yasal olarak log tutma zorunluluğu olan kurumlarda bu tür silme işlemleri ciddi hukuki yaptırımlarla karşılaşılmasına neden olur.

UYARI: RADIUS logları, yasal takip ve adli incelemeler için temel kanıt niteliğindedir. Bu logların yetkisiz silinmesi veya değiştirilmesi Türkiye’de 5651 sayılı “İnternet Ortamında Yapılan Yayınların Düzenlenmesi ve Bu Yayınlar Yoluyla İşlenen Suçlarla Mücadele Edilmesi Hakkında Kanun” gibi mevzuatlarca suç kabul edilmektedir.

2.2. SYSLOG Sunucuları (Merkezi Sistem ve Ağ Logları)

Syslog, UNIX/Linux tabanlı sistemlerde ve ağ cihazlarında sistem mesajlarını merkezi veya yerel olarak toplayan, yönlendiren ve kaydeden standart bir loglama protokolüdür. Routerlar, switchler, firewalllar, sunucular gibi ağ üzerinde çalışan çeşitli cihazlardan gelen logları tek bir sunucuya yönlendirmek için kullanılır.

2.2.1. Syslog Protokolü Nedir? Syslog, temel olarak UDP 514 portunu kullanır (TCP de desteklenebilir, daha güvenilir iletişim için). Mesajlar “tesis (facility)” (mesajın kaynağı, örn. kernel, mail) ve “önem derecesi (severity)” (mesajın önemi, örn. hata, uyarı, bilgi) olmak üzere iki ana kategoride sınıflandırılır. Bu, logların filtrelenmesini ve önceliklendirilmesini sağlar.

2.2.2. Dosya Yapısı ve Log Dizinleri (Linux) Linux sistemlerde loglar genellikle /var/log/ dizini altında depolanır:

• /var/log/syslog: Genel sistem logları (Debian/Ubuntu tabanlı sistemlerde).
• /var/log/messages: Genel kernel ve servis mesajları (CentOS/RHEL tabanlı sistemlerde).
• /var/log/auth.log: Kimlik doğrulama ile ilgili loglar (SSH girişleri, sudo komutları vb.).
• /var/log/kern.log: Sadece çekirdek (kernel) logları.
• /var/log/daemon.log: Servis (daemon) programlarına ait loglar.
• /var/log/dmesg: Önyükleme (boot) mesajları.
• /var/log/lastlog: Kullanıcıların son giriş zamanları.
• /var/log/wtmp / /var/log/btmp: Sistemdeki giriş/çıkış hareketleri, başarısız giriş denemeleri.

2.2.3. Rsyslog.conf Dosyası Yapılandırması rsyslog (Rocket-fast System for log processing), Syslog protokolü üzerinde çalışan modern bir loglama sistemidir ve Linux dağıtımlarında sıkça kullanılır. Yapılandırma dosyaları:

• /etc/rsyslog.conf: Ana yapılandırma dosyası.
• /etc/rsyslog.d/*.conf: Daha küçük, modüler yapılandırma dosyaları (önerilen yöntem).

✍️ Örnek Kurallar: rsyslog.conf içindeki kurallar, hangi tesis ve önem derecesindeki logların nereye yazılacağını veya yönlendirileceğini belirler:

authpriv.* /var/log/auth.log     # authpriv tesisindeki tüm seviyeler auth.log'a
kern.* /var/log/kern.log     # kernel tesisindeki tüm seviyeler kern.log'a
mail.info     /var/log/mail.log     # mail tesisindeki 'info' seviyesi ve üzeri mail.log'a
*.=info;*.=notice;*.=warn  /var/log/messages # Tüm tesislerden info, notice, warn seviyesindekiler messages'a

🚧 Uzaktan Log Gönderme: Bir istemcinin loglarını merkezi bir Syslog sunucusuna göndermesi için kural:

*.* @192.168.1.10:514       # Tüm logları (tüm tesisler, tüm seviyeler) UDP ile 192.168.1.10 adresine gönder
*.* @@192.168.1.10:514      # TCP ile (daha güvenilir)

2.2.4. Syslog Sunucusu Kurulumu (rsyslog) Merkezi bir Syslog sunucusu kurmak için:

• Debian/Ubuntu:Bashsudo apt update sudo apt install rsyslog
• CentOS/RHEL:Bashsudo yum install rsyslog sudo systemctl enable rsyslog

Sunucuyu UDP 514 portunda dinlemeye almak için /etc/rsyslog.conf dosyasında şu satırlar aktif hale getirilir:

module(load="imudp")      # UDP input modülünü yükle
input(type="imudp" port="514") # 514 portunu dinle

Değişikliklerden sonra rsyslog servisi yeniden başlatılır:

Bash

sudo systemctl restart rsyslog

2.2.5. Log Formatları ve Yorumlama Syslog mesajları belirli bir formatı takip eder:

Jul 12 10:15:01 server1 sshd[1211]: Accepted password for user1 from 192.168.1.100 port 51432 ssh2

• Jul 12 10:15:01: Tarih ve saat (timestamp).
• server1: Logu gönderen cihazın ana bilgisayar adı (hostname).
• sshd[1211]: Logu üreten programın adı (daemon) ve Process ID (PID).
• Accepted password...: Olayın kendisi (mesaj içeriği).

2.2.6. Log Sorgulama ve Filtreleme Komutları Log dosyaları metin tabanlı olduğundan, Linux’un temel metin işleme komutları ile sorgulanabilir:

• grep ile IP sorgusu:Bashgrep "192.168.1.100" /var/log/syslog
• Zaman filtresi (awk ile):Bashawk '/Jul 12 10:/,/Jul 12 11:/' /var/log/syslog Bu komut, 12 Temmuz saat 10:00 ile 11:00 arasındaki logları getirir.
• Servis bazlı log arama:Bashgrep sshd /var/log/auth.log

2.2.7. Syslog Verilerini Uzak Sunucuya Gönderme İstemcilerin logları merkezi bir Syslog sunucusuna gönderilerek toplu yönetim sağlanır. /etc/rsyslog.d/remote.conf gibi bir dosyada kural tanımlanır:

*.* @logserver.example.com:514 # Logları logserver.example.com adresine yönlendir

Sunucu tarafında bu logları ayrı dizinlere yazmak için bir şablon (template) tanımlanabilir:

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs # Tüm logları RemoteLogs şablonuna göre yaz

Bu sayede her cihazın logu, kendi ana bilgisayar adına ve program adına göre ayrı dosyalara kaydedilir.

2.2.8. Syslog Loglarını Silme ve Manipüle Etme (Teorik ve Riskler) Syslog dosyaları temelde metin dosyalarıdır. Bu nedenle, uygun yetkilere sahip bir yönetici tarafından doğrudan dosya sisteminde müdahale edilebilir. 🤞 Teorik İz Silme Yöntemleri:

• Tek satır silme (sed ile):Bashsed -i '/192.168.1.100/d' /var/log/syslog Bu komut, /var/log/syslog dosyasındaki “192.168.1.100” içeren tüm satırları siler.
• Belli zaman aralığındaki logları silme (awk ile):Bashawk '!/Jul 12 10:/' /var/log/syslog > temp.log && mv temp.log /var/log/syslog Bu komut, “Jul 12 10:” ile başlayan satırları hariç tutarak yeni bir dosya oluşturur ve orijinal dosyanın üzerine yazar. ⚠️ Uyarı ve Riskler:
• Adli İzler: Dosya boyutundaki ani düşüşler, dosya erişim zamanlarındaki (timestamp) değişiklikler gibi metadata izleri Forensic analizlerle tespit edilebilir.
• Denetim Logları (Audit Logs): Birçok Linux sistemi, dosya sistemi erişimlerini ve değişikliklerini denetim loglarına (audit logs) kaydeder. Silme komutunun kendisi bu loglarda bir iz bırakır.
• SIEM ve Log Korelasyonu: Syslog logları SIEM sistemlerine aktarılıyorsa, SIEM bu anormallikleri (logların aniden kesilmesi veya eksikliği) tespit edebilir ve alarm üretebilir.

2.2.9. Log Rotasyonu ve Saklama Politikaları Log dosyaları zamanla çok büyük boyutlara ulaşabilir. logrotate aracı, bu dosyaların otomatik olarak sıkıştırılması, arşivlenmesi, silinmesi ve yeni log dosyalarının oluşturulması için kullanılır. Bu, disk alanı yönetimini sağlar ve sistem performansını korur.

• Logrotate Ayarları: Genellikle /etc/logrotate.d/rsyslog dosyasında bulunur.

/var/log/syslog {
  daily         # Günlük rotasyon
  rotate 7      # Son 7 sıkıştırılmış kopyayı sakla
  compress      # Eski logları sıkıştır
  missingok     # Log dosyası yoksa hata verme
  notifempty    # Boşsa rotasyon yapma
  create 640 syslog adm # Yeni log dosyasını belirli izinlerle oluştur
  postrotate    # Rotasyon sonrası çalıştırılacak komutlar
    /usr/lib/rsyslog/rsyslog-rotate # rsyslog'a sinyal gönder
  endscript
}

2.2.10. Web Tabanlı Arayüzler (Opsiyonel) Büyük Syslog ortamlarında logları analiz etmek için web tabanlı arayüzler kullanılır:

• Graylog: Syslog verilerini Elasticsearch ile depolayan ve güçlü arama/analiz yetenekleri sunan bir merkezi log yönetim aracıdır.
• LogAnalyzer: Rsyslog loglarını web arayüz üzerinden incelemek için kullanılan basit bir araçtır.
• Kibana: ELK (Elasticsearch, Logstash, Kibana) yığınının bir parçası olarak log verilerini görselleştirmek ve analiz etmek için kullanılır.

2.3. Deep Packet Inspection (DPI) Sistemleri – Teknik Kılavuz

Deep Packet Inspection (DPI), veri paketlerinin sadece başlık bilgilerini değil, aynı zamanda içeriklerini (payload) de analiz eden gelişmiş bir ağ güvenlik ve yönetim teknolojisidir. ISP’ler ve büyük kurumlar tarafından ağ trafiğini daha derinlemesine anlamak ve yönetmek için kullanılır.

2.3.1. Tanım ve Amaçlar DPI, katman 7 (uygulama katmanı) düzeyinde çalışır. Temel amaçları:

• Ağ Trafiği Sınıflandırması: Hangi uygulamaların (YouTube, Netflix, Skype vb.) veya protokollerin (HTTPS, DNS, FTP vb.) kullanıldığını tespit etmek.
• Güvenlik Denetimi (IDS/IPS): Kötü amaçlı yazılımları, saldırı imzalarını veya anormal davranışları paket içeriğinden tespit etmek.
• Erişim Kontrolü (URL/İçerik Filtreleme): Yasaklı web sitelerine veya zararlı içeriklere erişimi engellemek.
• Bant Genişliği Yönetimi (QoS – Quality of Service): Belirli uygulama türlerine (örn. VoIP, video akışı) öncelik vermek veya diğerlerini (örn. dosya indirme) kısıtlamak.
• Yasal Dinleme ve İzleme: Yasal talepler doğrultusunda belirli trafik akışlarını izlemek.

2.3.2. DPI Sistem Mimarisi Bir DPI sistemi genellikle şu temel bileşenlerden oluşur:

• Capture Engine (Yakınlama Motoru): Ağdan gelen tüm trafiği yakalar ve ön işlemden geçirir.
• Parser Engine (Ayrıştırma Motoru): Yakalanan paketleri bilinen protokollere (HTTP, DNS, TLS vb.) göre ayrıştırır ve içeriği anlaşılır bir formata dönüştürür.
• Signature Engine (İmza Motoru): Tanımlı imza veritabanlarına (bilinen saldırı kalıpları, uygulama imzaları) karşı paket içeriğini karşılaştırır.
• Heuristic/Behavior Engine (Sezgisel/Davranışsal Motor): İmza tabanlı olmayan, ancak anormal veya şüpheli davranışları tespit etmek için yapay zeka ve makine öğrenimi tekniklerini kullanır.
• Decision Engine (Karar Motoru): Analiz sonuçlarına göre trafiği bloklama, loglama, izin verme veya bant genişliği şekillendirme kararlarını verir.

2.3.3. Açık Kaynak DPI Araçları

• nDPI: ntop tarafından geliştirilen, ağ protokollerini ve uygulamalarını tespit etmek için kullanılan popüler bir açık kaynak DPI kütüphanesidir. Özellikle trafik akışlarını analiz etmek ve istatistik çıkarmak için etkilidir.
  • Kurulum (Ubuntu Örneği):Bashsudo apt update sudo apt install git cmake build-essential libpcap-dev git clone https://github.com/ntop/nDPI.git cd nDPI make
  • Demo Uygulaması Çalıştırma:Bashcd example sudo ./ndpiReader -i eth0 # eth0 arayüzünden gelen trafiği analiz et
  • Belirli bir protokolü filtrele (Örnek: HTTPS):Bashsudo ./ndpiReader -i eth0 -p HTTPS
• OpenDPI & libprotoident: OpenDPI artık aktif olarak geliştirilmese de birçok ticari ve açık kaynak yazılımın temelini oluşturmuştur. libprotoident ise paket içeriğine (payload) dayalı uygulama tespiti yapar.

2.3.4. Trafik Analizi Senaryoları ve Uygulamaları DPI araçları, çeşitli ağ trafiği analiz senaryolarında kullanılabilir:

• Senaryo 1: YouTube Trafiğini Tespit Etme ve Engelleme
  • nDPI ile tespit:Bashsudo ./ndpiReader -i eth0 -p YOUTUBE
  • iptables ile basit engelleme (payload eşleşmesi):Bashsudo iptables -A OUTPUT -p tcp --dport 443 -m string --algo bm --hex-string '|594F5554554245|' -j DROP
  • Not: Yukarıdaki iptables kuralı basit bir örnek olup, modern DPI motorları ile çok daha doğru ve dinamik tespitler yapılır. HTTPS trafiği şifreli olduğu için doğrudan içerik analizi zordur, genellikle SNI (Server Name Indication) veya DNS istekleri üzerinden tespit yapılır.
• Senaryo 2: DNS Tünelleme Tespiti
  • Kötü niyetli aktörler tarafından güvenlik duvarlarını atlatmak için kullanılan bir yöntemdir.
  • nDPI ile tespit:Bashsudo ./ndpiReader -i eth0 --dns-check
• Senaryo 3: Tor Trafiğini Yakalama
  • Anonim iletişim için kullanılan Tor ağını tespit etme.
  • nDPI ile tespit:Bashsudo ./ndpiReader -i eth0 -p TOR

2.3.5. Ticari DPI Sistemleri Piyasada birçok güçlü ticari DPI çözümü bulunmaktadır. Bunlar genellikle daha yüksek performans, gelişmiş raporlama, entegrasyon yetenekleri ve GUI tabanlı yönetim sunar:

• Sandvine PacketLogic
• Cisco NetFlow / NBAR (Network Based Application Recognition)
• Blue Coat PacketShaper
• Huawei DPI
• Allot Communications Bu sistemler genellikle L7 uygulama tanıma, otomatik protokol güncellemeleri, otomatik engelleme/shaping ve detaylı trafik istatistikleri gibi özelliklere sahiptir.

2.3.6. Trafik Engelleme & Şekillendirme (QoS) DPI sistemleri, tespit ettikleri uygulama veya protokol bazında trafik akışlarını engellemek veya bant genişliğini şekillendirmek (QoS) için kullanılır. Linux sistemlerde tc (traffic control) ve iptables/nftables ile entegre çalışabilirler.

• tc ile basit trafik sınıflandırması:Bashsudo tc qdisc add dev eth0 root handle 1: htb default 30 sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 1mbit
• DPI çıktısını nftables ile gerçek zamanlı kontrol edebilmek için ndpi-netfilter gibi ara yazılımlar gereklidir. Bu, dinamik kurallar oluşturarak belirli uygulamaları (örn. torrent) anında engelleyebilir veya yavaşlatabilir.

2.3.7. DPI ile Loglama ve İzleme Entegrasyonu DPI sistemleri, analiz ettikleri her paket hakkında detaylı loglar üretir. Bu loglar, genellikle merkezi log yönetim sistemlerine (Syslog, SIEM) aktarılır.

• Syslog Tabanlı Kayıt:Bash./ndpiReader -i eth0 -v 2 | logger -t DPI_MONITOR Bu komut, ndpiReader çıktısını Syslog’a gönderir ve DPI_MONITOR etiketiyle kaydedilmesini sağlar.
• Elastic Stack ile İzleme: Packetbeat gibi araçlar, ağ trafiğini doğrudan yakalayıp Elasticsearch’e gönderebilir. nDPI çıktısı da Filebeat aracılığıyla Elasticsearch’e yönlendirilebilir.
  • Packetbeat config (örnek):YAMLpacketbeat.protocols.http: ports: [80, 8080, 8000, 5000, 8002] packetbeat.interfaces.device: eth0
  Bu entegrasyonlar, DPI verilerinin merkezi bir platformda (Kibana) görselleştirilmesini ve analiz edilmesini sağlar.

2.3.8. IDS/IPS ile Entegrasyon DPI, İzinsiz Giriş Tespit Sistemleri (IDS) ve İzinsiz Giriş Önleme Sistemleri (IPS) ile entegre çalışarak ağ güvenliğini artırır.

• Suricata + nDPI: Suricata, yüksek performanslı bir IDS/IPS aracıdır ve nDPI ile entegre çalışarak uygulama katmanı protokollerini daha etkin bir şekilde tanıyabilir.
  • Suricata kurulumu:Bashsudo apt install suricata sudo suricata -c /etc/suricata/suricata.yaml -i eth0
  • Loglar:Bashtail -f /var/log/suricata/fast.log
  • Suricata’nın suricata.yaml dosyasında uygulama katmanı protokolleri aktif edilmelidir.

2.3.9. Gizlilik ve Etik Tartışmalar (Yasal Sınırlar) DPI sistemleri, veri paketlerinin içeriğini analiz ettiği için ciddi gizlilik endişeleri yaratır. Bu durum, KVKK (Türkiye) ve GDPR (Avrupa Birliği) gibi kişisel verilerin korunmasına yönelik düzenlemelerle sıkı bir şekilde sınırlıdır.

• Kurumlar, DPI kullanmadan önce açıkça belirtmeli ve ilgili yasal izinleri almalıdır.
• DPI sistemlerinin yasal dinleme amacıyla kullanımı, ilgili mahkeme kararları veya yasal yetkilendirmelerle sınırlıdır.
• Etik Sorumluluk: Her türlü ağ izleme faaliyetinin etik sınırlar içinde kalması ve bireylerin mahremiyet haklarına saygı göstermesi esastır.

2.3.10. DPI Sistemlerinin Saldırıya Açık Noktaları ve Karşı Önlemler Gelişmiş saldırganlar, DPI sistemlerini atlatmak için çeşitli “evasion” teknikleri kullanabilir:

• Paket Bölme (Fragmentation): Paketleri küçük parçalara bölerek DPI’ın imzaları bir bütün olarak tanımasını engellemek.
• Şifreleme (TLS, DoH – DNS over HTTPS): Trafiği şifreleyerek içeriğin görünmez hale gelmesini sağlamak.
• Protokol Tünelleme (VPN içinde başka protokol): Bir protokolü (örn. DNS) başka bir protokol (örn. HTTP) içinde tünelleyerek trafik türünü gizlemek. Karşı Önlemler:
• TLS Fingerprinting: Şifreli trafiğin içeriğine bakamasa da, bağlantı başlangıcındaki TLS el sıkışma (handshake) özelliklerinden uygulamanın türünü tespit etmek.
• DNS Çözümleyici Kontrolü: Kendi DNS sunucusu yerine public DNS sunucusu (örn. Google DNS 8.8.8.8) kullanan cihazları tespit etmek.
• Zamanlama Analizi (Timing Correlation): Trafik desenlerini ve zamanlamaları analiz ederek şüpheli aktiviteleri (örn. botnet iletişimi) tespit etmek.

2.4. Veritabanı Sunucuları (DPI Log Depolama ve Sorgulama)

Log verileri, DPI sistemleri, Syslog sunucuları ve diğer ağ cihazları tarafından sürekli olarak üretilen kritik bilgi bloklarıdır. Bu logların etkin bir şekilde depolanması, analiz edilmesi ve gerektiğinde adli delil olarak kullanılması için merkezi veritabanı sistemlerine ihtiyaç vardır.

2.4.1. Amaçlar ve Yaygın Sistemler Veritabanları, log yönetiminde aşağıdaki amaçlarla kullanılır:

• Uzun Vadeli Saklama: Yasal uyumluluk ve adli analizler için logları belirli süreler boyunca güvenli bir şekilde saklamak.
• Hızlı Sorgulama ve Analiz: Büyük hacimli log verileri üzerinde hızlı ve karmaşık sorgular çalıştırarak güvenlik olaylarını veya performans sorunlarını tespit etmek.
• Hukuki/Gecikmeli Analiz: Geçmiş olayları araştırmak ve adli kanıt toplamak.
• Trafik İstatistikleri ve Raporlama: Ağ trafiği desenleri, uygulama kullanımı ve güvenlik trendleri hakkında istatistikler ve raporlar oluşturmak. Yaygın olarak kullanılan veritabanı sistemleri:
• PostgreSQL: Açık kaynaklı, güçlü, ilişkisel bir veritabanıdır. Genellikle yapılandırılmış log verileri için tercih edilir.
• MySQL / MariaDB: Yaygın, esnek ilişkisel veritabanlarıdır.
• Oracle DB: Kurumsal düzeyde, ticari bir ilişkisel veritabanıdır.
• MongoDB (NoSQL): Yüksek hacimli, yapılandırılmamış veya yarı yapılandırılmış (JSON benzeri) log verileri için ölçeklenebilir bir NoSQL veritabanıdır.

2.4.2. DPI Log Format Yapısı DPI sistemleri genellikle loglarını JSON veya benzeri yapılandırılmış formatlarda üretir. Örnek bir DPI log kaydı:

JSON

{
  "timestamp": "2025-07-11T20:45:10Z",
  "src_ip": "192.168.1.100",
  "dst_ip": "8.8.8.8",
  "protocol": "DNS",
  "app": "GoogleDNS",
  "bytes_sent": 128,
  "bytes_received": 512,
  "flow_id": "a1b2c3d4e5f6"
}

Veritabanına aktarılacak temel alanlar: timestamp, src_ip, dst_ip, port, protocol, application name, bytes_sent, bytes_received, flow_id vb.

2.4.3. PostgreSQL Entegrasyonu PostgreSQL, log verilerini tablo yapısında saklamak için idealdir.

• PostgreSQL Kurulumu (Debian/Ubuntu):Bashsudo apt update sudo apt install postgresql postgresql-contrib sudo systemctl start postgresql
• Veritabanı Oluşturma:Bashsudo -u postgres createdb dpi_logs
• Kullanıcı Tanımlama:Bashsudo -u postgres createuser dpiuser -P # Şifre isteyecektir
• Yetki Verme:SQLGRANT ALL PRIVILEGES ON DATABASE dpi_logs TO dpiuser; Bu komutlar, log verilerini depolamak için bir veritabanı ve bir kullanıcı oluşturur.

2.4.4. PostgreSQL Tablo Yapısı ve Sorgular Log verileri için bir tablo oluşturulur:

SQL

CREATE TABLE connection_logs (
  id SERIAL PRIMARY KEY,
  timestamp TIMESTAMP,
  src_ip INET,       -- IP adresleri için özel veri tipi
  dst_ip INET,
  protocol TEXT,
  app TEXT,
  bytes_sent INT,
  bytes_received INT
);

• Veri Ekleme:SQLINSERT INTO connection_logs (timestamp, src_ip, dst_ip, protocol, app, bytes_sent, bytes_received) VALUES (NOW(), '192.168.1.100', '8.8.8.8', 'DNS', 'GoogleDNS', 128, 512);
• Basit Sorgu:SQLSELECT * FROM connection_logs WHERE src_ip = '192.168.1.100' LIMIT 10;
• Tarihe Göre Silme (Log Rotasyonu):SQLDELETE FROM connection_logs WHERE timestamp < NOW() - INTERVAL '30 days'; Bu komut, 30 günden eski logları siler.
• VACUUM Kullanımı: DELETE komutları, veritabanı dosya boyutunu hemen küçültmez. VACUUM FULL komutu, boş alanı geri kazanır:SQLVACUUM FULL connection_logs; UYARI: VACUUM FULL işlemi tabloyu kilitler ve uzun sürebilir. Genellikle VACUUM (yalnız) düzenli olarak çalıştırılır veya otomatik vakumlama kullanılır.

2.4.5. Gelişmiş PostgreSQL Sorguları Veritabanında depolanan loglar üzerinde karmaşık analizler yapılabilir:

• En çok trafik oluşturan IP adresini bulma:SQLSELECT src_ip, SUM(bytes_sent + bytes_received) as total_bytes FROM connection_logs GROUP BY src_ip ORDER BY total_bytes DESC LIMIT 5;
• Uygulamaya göre protokol analizi:SQLSELECT app, COUNT(*) FROM connection_logs GROUP BY app;
• Saatlik trafik istatistiği:SQLSELECT date_trunc('hour', timestamp) as hour, SUM(bytes_sent + bytes_received) FROM connection_logs GROUP BY hour ORDER BY hour;

2.4.6. MongoDB Entegrasyonu MongoDB, esnek şeması sayesinde yapılandırılmamış veya değişen log formatları için uygundur.

• Kurulum (Debian/Ubuntu):Bashsudo apt install mongodb sudo systemctl enable --now mongodb
• Mongo Shell’e Girme:Bashmongosh
• Veritabanı ve Koleksiyon Oluşturma:JavaScriptuse dpi_logs // Veritabanını seçer veya oluşturur db.createCollection("logs") // 'logs' adında bir koleksiyon (ilişkisel DB'deki tabloya benzer) oluşturur
• Veri Ekleme:JavaScriptdb.logs.insertOne({ timestamp: new Date(), ip: "192.168.1.100", dst: "8.8.8.8", protocol: "DNS", app: "GoogleDNS", bytes_sent: 128, bytes_received: 512 });

2.4.7. MongoDB Sorguları MongoDB’de veriler JSON (BSON) formatında depolandığı için sorgular da JSON benzeri bir sözdizimi kullanır:

• IP’ye Göre Sorgulama:JavaScriptdb.logs.find({ ip: "192.168.1.100" }).limit(10)
• Protokole Göre Sorgulama:JavaScriptdb.logs.find({ protocol: "DNS" })
• Silme (Tarihe Göre):JavaScriptdb.logs.deleteMany({ timestamp: { $lt: new Date("2025-06-01") } }) Bu komut, 1 Haziran 2025’ten önceki tüm logları siler.

2.4.8. Performans ve Optimizasyon Büyük log veritabanlarında sorgu performansını artırmak için indeksleme kritik öneme sahiptir.

• PostgreSQL İndeks:SQLCREATE INDEX idx_src_ip ON connection_logs (src_ip); CREATE INDEX idx_timestamp ON connection_logs (timestamp DESC);
• MongoDB İndeks:JavaScriptdb.logs.createIndex({ ip: 1 }); // Artan sıra db.logs.createIndex({ timestamp: -1 }); // Azalan sıra (son logları sorgulamak için)
• Arşivleme Stratejileri: Eski logları daha yavaş ama daha ucuz depolama alanlarına taşımak (soğuk veri yönetimi) veya her ay/yıl için ayrı tablolar/koleksiyonlar oluşturmak.

2.4.9. Yedekleme ve Replikasyon Veritabanları, kritik log verileri içerdiğinden düzenli yedekleme ve yüksek erişilebilirlik için replikasyon (çoğaltma) stratejileri uygulanmalıdır.

• PostgreSQL Yedekleme:Bashpg_dump dpi_logs > dpi_logs_backup_$(date +%Y%m%d).sql
• MongoDB Yedekleme:Bashmongodump --db dpi_logs --out /backup/dpi_logs/$(date +%Y%m%d)/

2.4.10. Güvenlik ve KVKK Uyumluluğu Log veritabanlarının güvenliği ve kişisel verilerin korunması (KVKK/GDPR) hayati öneme sahiptir.

• Şifreli Yedekleme: Yedeklerin şifrelenerek saklanması.
• Erişim Kontrol Listeleri (ACL): pg_hba.conf (PostgreSQL) veya Role-Based Access Control (RBAC) (MongoDB) ile verilere erişimi sıkılaştırmak.
• IP’yi Maskeleme/Anonimleştirme: Yasal zorunluluklar dışında IP adresleri gibi kişisel verilerin anonimleştirilmesi.
• Log Tutma Süreleri: KVKK gibi düzenlemeler, logların belirli bir süre (genellikle maksimum 2 yıl) tutulmasını ve ardından silinmesini zorunlu kılar.

2.4.11. Grafana ve Monitöring Entegrasyonu Veritabanında depolanan log verileri, Grafana gibi görselleştirme araçları kullanılarak interaktif panolar (dashboard) halinde sunulabilir. Bu, ağ yöneticilerinin ve güvenlik ekiplerinin trafik trendlerini, anormallikleri ve güvenlik olaylarını gerçek zamanlı olarak izlemesini sağlar. PostgreSQL ve MongoDB için hazır Grafana veri kaynağı eklentileri bulunmaktadır.

2.4.12. SIEM Entegrasyonu (Veritabanı Loglarının Önemi) Veritabanları, SIEM sistemleri için önemli bir log kaynağıdır. Veritabanı logları, güvenlik olaylarının korelasyonunda ve daha geniş bir güvenlik bağlamının oluşturulmasında kullanılır. Filebeat veya Logstash gibi araçlar, veritabanı loglarını Elasticsearch gibi SIEM bileşenlerine aktarabilir.

2.4.13. Örnek Senaryo: IP Saklama ve Silme İşlemi (Uygulamalı) Bir kullanıcıya ait belirli bir IP adresinin loglarının, yasal bir süreç sonrası veya KVKK gereği silinmesi gerektiğinde izlenebilecek (teorik) adımlar:

• PostgreSQL:SQLDELETE FROM connection_logs WHERE src_ip = '192.168.1.100' AND timestamp > '2025-07-11'; VACUUM FULL connection_logs; -- Boş alanı geri kazanmak için
• MongoDB:JavaScriptdb.logs.deleteMany({ ip: "192.168.1.100", timestamp: { $gt: new Date("2025-07-11") } })

UYARI: Bu tür işlemler sadece yasal ve etik sınırlar içinde, uygun yetkilendirmelerle ve denetim altında yapılmalıdır. Silme işleminin kendisi de sistemde izler bırakabilir.

2.4.14. Periyodik Temizlik ve Otomasyon Log veritabanlarının düzenli olarak temizlenmesi, performansın korunması ve disk alanı yönetiminin sağlanması için otomatize edilmelidir.

• Cronjob Örneği (PostgreSQL için):Bash0 2 * * * psql -U dpiuser -d dpi_logs -c "DELETE FROM connection_logs WHERE timestamp < NOW() - INTERVAL '90 days'; VACUUM;" Bu cronjob, her gece saat 02:00’de 90 günden eski logları siler ve VACUUM işlemini çalıştırır.
• MongoDB Script: Benzer işlemler, Node.js, Python veya bash scriptleri aracılığıyla zamanlanabilir.

2.4.15. Sonuç Veritabanlarının doğru yapılandırılması ve yönetilmesi, DPI sistemleri gibi kaynaklardan gelen logların uzun vadeli saklanması, hızlı sorgulanması ve etkin analiz edilmesi için kritik öneme sahiptir. Performans, yedekleme, KVKK uyumluluğu ve güvenlik, bir arada sağlanması gereken temel unsurlardır. PostgreSQL gibi ilişkisel veritabanları yapılandırılmış sorgular için uygunken, MongoDB gibi NoSQL veritabanları çok hacimli ve çeşitli veri için ölçeklenebilirlik sunar.

---

3. SIEM Sistemleri (Security Information and Event Management)

SIEM (Security Information and Event Management) sistemleri, kurumların farklı kaynaklardan (sunucular, ağ cihazları, uygulamalar, güvenlik sistemleri) gelen güvenlik olaylarını ve loglarını merkezi olarak topladığı, analiz ettiği, ilişkilendirdiği ve raporladığı kapsamlı çözümlerdir. Temel amacı, güvenlik tehditlerini erken tespit etmek, olay müdahale süreçlerini desteklemek ve yasal/kurumsal uyumluluk sağlamaktır.

3.1. Giriş: SIEM Nedir ve Neden Önemlidir? Geleneksel güvenlik sistemleri genellikle birbirinden bağımsız çalışır ve büyük hacimli loglar üretir. Bu logları manuel olarak incelemek neredeyse imkansızdır. SIEM, bu logları tek bir platformda birleştirerek, farklı kaynaklardan gelen olaylar arasında korelasyon kurar ve potansiyel tehditleri otomatik olarak belirler.

3.2. SIEM Temel Bileşenleri Bir SIEM sistemi genellikle şu bileşenlerden oluşur:

Bileşen	Açıklama
Log Toplama	Farklı kaynaklardan (firewall, IDS/IPS, sunucu, veritabanı, uygulama vb.) logların merkezi bir noktaya aktarılması.
Normalizasyon	Farklı formatlardaki (Syslog, Windows Event Logs, JSON vb.) logların ortak, anlaşılır ve analiz edilebilir bir formata dönüştürülmesi.
Korelasyon	Toplanan log ve olayların analiz edilip aralarındaki ilişkilerin (örneğin, başarısız giriş denemelerinin ardından bir dosya erişimi) tespit edilmesi.
Alarm / Uyarı	Önceden tanımlanmış kurallar veya anormallikler tespit edildiğinde güvenlik ekiplerine otomatik olarak uyarı veya alarm üretimi.
Depolama	Yasal uyumluluk ve adli analizler için logların güvenli, sıkıştırılmış ve uzun süre (aylar/yıllar) saklanması.
Raporlama	Güvenlik durumu, uyumluluk gereksinimleri (PCI DSS, HIPAA, ISO 27001) ve denetim için detaylı raporların hazırlanması.

E-Tablolar’a aktar

3.3. SIEM Yazılımları ve Teknolojileri Piyasada hem açık kaynaklı hem de ticari birçok SIEM çözümü bulunmaktadır:

• Açık Kaynak:
  • Elastic Stack (ELK Stack): Elasticsearch (depolama ve arama motoru), Logstash (log işleme ve normalizasyon), Kibana (veri görselleştirme ve pano). Popüler ve esnektir.
  • Wazuh: Açık kaynaklı bir Host-based Intrusion Detection System (HIDS) ve SIEM platformu. Güvenlik olay yönetimi, uyumluluk denetimi ve güvenlik açığı tespiti sunar.
  • OSSEC: Host tabanlı bir izinsiz giriş tespit sistemidir, Wazuh’un temelini oluşturur.
  • Graylog: Log yönetimi ve temel SIEM işlevleri sunar, Elasticsearch’i arka uç olarak kullanabilir.
• Ticari:
  • Splunk: Piyasadaki en güçlü ve yaygın SIEM çözümlerinden biridir. Güçlü arama dili (SPL) ve geniş entegrasyon yetenekleri vardır.
  • IBM QRadar: IBM’in kapsamlı bir güvenlik analizi platformudur.
  • ArcSight (Micro Focus): Büyük ölçekli kurumlar için geliştirilmiş kurumsal SIEM çözümü.
  • McAfee Enterprise Security Manager (ESM): McAfee’nin güvenlik operasyon merkezi (SOC) için tasarlanmış SIEM’i.

3.4. SIEM Kurulum ve Yapılandırma Adımları (Örnek: Elastic Stack + Wazuh) Bu bölümde, açık kaynaklı ve popüler bir SIEM çözümü olan Elastic Stack ile HIDS yetenekleri sunan Wazuh’un temel kurulum adımları özetlenmiştir.

3.4.1. Elasticsearch Kurulumu Elasticsearch, log verilerini depolayan, indeksleyen ve arama yetenekleri sağlayan dağıtık bir arama ve analiz motorudur.

• Elasticsearch 8.x yükleme (Debian/Ubuntu için örnek):Bashwget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.8.1-amd64.deb sudo dpkg -i elasticsearch-8.8.1-amd64.deb
• Servisi başlatma ve aktif etme:Bashsudo systemctl start elasticsearch sudo systemctl enable elasticsearch
• Durumu kontrol etme:Bashsudo systemctl status elasticsearch
• Elasticsearch cluster durumunu kontrol etme:Bashcurl -X GET "localhost:9200/_cluster/health?pretty"

3.4.2. Logstash Kurulumu ve Basit Konfigürasyon Logstash, çeşitli kaynaklardan logları toplayan, işleyen (filtreleme, normalizasyon) ve Elasticsearch gibi hedeflere gönderen bir veri işleme hattıdır.

• Logstash yükleme:Bashwget https://artifacts.elastic.co/downloads/logstash/logstash-8.8.1.deb sudo dpkg -i logstash-8.8.1.deb
• Basit Syslog input ve Elasticsearch output içeren konfigürasyon dosyası (02-syslog.conf) oluşturma:Bashsudo nano /etc/logstash/conf.d/02-syslog.conf İçerik örneği (Syslog loglarını dinleyip Elasticsearch’e yönlendirir):input { syslog { port => 514 type => "syslog" } } filter { if [type] == "syslog" { grok { match => { "message" => "%{SYSLOGLINE}" } # Syslog satırlarını ayrıştırır } } } output { elasticsearch { hosts => ["localhost:9200"] index => "syslog-%{+YYYY.MM.dd}" # Günlük indeks oluşturur } }
• Logstash servisini başlatma:Bashsudo systemctl start logstash sudo systemctl enable logstash

3.4.3. Kibana Kurulumu ve Çalıştırılması Kibana, Elasticsearch’te depolanan verileri görselleştiren, panolar oluşturan ve arama/analiz yapmaya olanak tanıyan bir web arayüzüdür.

• Kibana yükleme:Bashwget https://artifacts.elastic.co/downloads/kibana/kibana-8.8.1-amd64.deb sudo dpkg -i kibana-8.8.1-amd64.deb
• Servisi başlatma:Bashsudo systemctl start kibana sudo systemctl enable kibana
• Kibana’ya web tarayıcısından erişim: http://localhost:5601

3.4.4. Wazuh Agent ve Manager Kurulumu Wazuh, sunucularda ve uç noktalarda güvenlik açığı tespiti, dosya bütünlüğü izleme, yapılandırma denetimi ve olay müdahalesi sağlayan bir ajandır. Manager, ajanlardan gelen verileri toplar, analiz eder ve korelasyon kurallarını uygular.

• Wazuh Manager Kurulumu (CentOS/Ubuntu):Bashcurl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add - echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list sudo apt-get update sudo apt-get install wazuh-manager sudo systemctl start wazuh-manager sudo systemctl enable wazuh-manager
• Wazuh Agent Kurulumu:Bashsudo apt-get install wazuh-agent Agent’ı Manager’a bağlamak için /var/ossec/etc/ossec.conf dosyasında Manager IP adresi belirtilir:XML<ossec_config> <client> <server> <address>WAZUH_MANAGER_IP</address> ... </server> ... </client> </ossec_config> Ardından Agent servisi başlatılır:Bashsudo systemctl start wazuh-agent sudo systemctl enable wazuh-agent

3.5. SIEM Log Yönetimi Komutları SIEM’e gönderilen logların kaynak sistemlerde nasıl inceleneceği:

• Syslog Logları İnceleme:Bashtail -n 100 /var/log/syslog # Son 100 logu göster grep -i "error" /var/log/syslog # "error" içeren logları filtrele tail -f /var/log/syslog # Gerçek zamanlı log izleme
• Journalctl ile Systemd Loglarını İzleme: journalctl, systemd tabanlı sistemlerde tüm logları merkezi olarak yönetir.Bashjournalctl # Tüm logları göster journalctl -n 100 # Son 100 logu göster journalctl -u sshd # Belirli bir servise (sshd) ait loglar journalctl -f # Canlı izleme

3.6. Log Analizi ve Korelasyon Örnekleri (Elasticsearch Query DSL) Kibana arayüzünde veya doğrudan Elasticsearch API’si üzerinden güçlü sorgularla loglar analiz edilebilir:

• Belirli IP’den Gelen Tüm Logları Getirme:JSONGET /syslog-*/_search { "query": { "match": { "source.ip": "192.168.1.100" } } }
• Hata Seviyesinde Logları Listeleme:JSONGET /syslog-*/_search { "query": { "match": { "log.level": "error" } } }
• Belirli Tarih Aralığındaki Olaylar:JSONGET /syslog-*/_search { "query": { "range": { "@timestamp": { "gte": "now-7d/d", # Son 7 gün "lt": "now/d" # Bugüne kadar } } } }

3.7. SIEM Alarmları ve Kural Yazımı (Wazuh Örneği) SIEM’in en önemli özelliği, korelasyon kuralları tanımlayarak anormallikleri veya güvenlik ihlallerini otomatik olarak tespit etmesi ve alarm üretmesidir. Wazuh’ta kurallar XML formatında tanımlanır.

• Kural Dosyası Oluşturma (örneğin /var/ossec/etc/rules/local_rules.xml):XML<rule id="100001" level="10"> <if_sid>18107</if_sid> <description>Şüpheli SSH başarısız oturum açma denemesi algılandı.</description> <group>authentication_failed,</group> <mail>security-team@example.com</mail> </rule> Bu kural, belirli bir SID (kural kimliği) ile ilişkilendirilmiş SSH başarısız giriş denemelerini yüksek önem derecesinde (level 10) bir alarm olarak işaretler ve güvenlik ekibine e-posta gönderir.
• Kural Dosyasını Yükleme ve Wazuh Servisini Yeniden Başlatma:Bashsudo systemctl restart wazuh-manager

3.8. SIEM Raporlama SIEM sistemleri, toplanan ve analiz edilen veriler üzerinde kapsamlı raporlama yetenekleri sunar.

• Kibana Dashboard Oluşturma: Kibana, sürükle-bırak arayüzü ile interaktif panolar oluşturmaya olanak tanır.
  • Log kaynağına göre filtreler (IP, tarih, log seviyeleri) oluşturulur.
  • Görsel grafikler (bar, pie, line) ile olay trendleri, en çok atak alan sistemler, en çok hata üreten uygulamalar gibi bilgiler sunulur.
  • Alarmlar ve kritik olaylar, yöneticilere yönelik özet raporlar halinde sunulabilir.
• Splunk Query Örneği (Search Processing Language – SPL): Splunk’ın kendi güçlü arama dili vardır.Splunk SPLindex=main sourcetype=syslog error OR failure | stats count by host, severity Bu sorgu, tüm main indeksindeki syslog kaynak tipinden “error” veya “failure” içeren logları bulur ve bunları ana bilgisayar ve önem derecesine göre gruplayarak sayısını gösterir.

3.9. SIEM Güvenlik ve Performans İpuçları

• Güvenli Log Toplama: Log kaynaklarından SIEM’e loglar, kimlik doğrulaması yapılmış ve şifreli kanallar (TLS, VPN) üzerinden aktarılmalıdır.
• Log Boyutuna Göre İndeksleme ve Arşivleme: Büyük hacimli loglar için indeksleme stratejileri (örneğin, zaman tabanlı indeksler) ve eski logların uygun maliyetli depolama alanlarına arşivlenmesi önemlidir.
• Yedekleme ve Felaket Kurtarma: SIEM veritabanı ve konfigürasyonlarının düzenli olarak yedeklenmesi ve bir felaket kurtarma planı bulunması zorunludur.
• Olay Müdahale Prosedürleri Entegrasyonu: SIEM’in ürettiği alarmlar, kurumun olay müdahale (Incident Response) prosedürleriyle entegre edilmelidir.
• Performans İzleme ve Optimizasyon: SIEM bileşenlerinin (Elasticsearch, Logstash vb.) kaynak kullanımı (CPU, RAM, disk I/O) sürekli izlenmeli ve optimizasyon yapılmalıdır.

3.10. Örnek Komutlar ve Snippetler (Toplu Bakım ve Kontrol)

• Syslog servisini yeniden başlat:Bashsudo systemctl restart rsyslog
• Logstash konfigürasyonlarını kontrol et (hataları tespit et):Bashsudo /usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/
• Wazuh agent durumu kontrol et:Bashsudo systemctl status wazuh-agent
• Elasticsearch indeks bilgisi:Bashcurl -X GET "localhost:9200/_cat/indices?v"
• Kibana erişim logları:Bashtail -f /var/log/kibana/kibana.log
• Splunk arama örneği:Splunk SPLsplunk search "index=main sourcetype=access_combined status=404" -earliest "-24h"

3.11. Kaynaklar ve İleri Okumalar

• Elastic SIEM Documentation: https://www.elastic.co/guide/en/siem/guide/current/index.html
• Wazuh Documentation: https://documentation.wazuh.com/
• Splunk Tutorial: https://docs.splunk.com/Documentation/Splunk/latest/SearchTutorial/AboutSplunk

---

4. İz Bırakmadan Erişim Mümkün mü? Logların Kalıcılığı ve Adli Bilişim Perspektifi

Günümüzün gelişmiş siber güvenlik ortamında, bir sisteme erişim sırasında hiçbir iz bırakmamak veya bırakılan izleri tamamen yok etmek, pratikte “imkansız” olarak kabul edilen bir durumdur. Güvenlik sistemleri ve altyapıları, bu tür izleri engellemek için sürekli olarak geliştirilse de, her aşamada loglama ve kayıt mekanizmaları bulunmaktadır. Bu durum, özellikle kurumların bilgi güvenliği, yasal uyumluluk ve olay müdahalesi süreçleri açısından kritik önem taşır.

Aşağıda, farklı sistem ve altyapı bileşenlerinin erişim izlerini bırakma riski ve bunun teknik temelleri, adli bilişim perspektifiyle değerlendirilmiştir.

4.1. RADIUS Sunucuları ve İz Kalıcılığı RADIUS (Remote Authentication Dial-In User Service) protokolü, kullanıcı kimlik doğrulama, yetkilendirme ve oturum muhasebesi işlemlerini merkezi olarak sağlar.

• İz Bırakma Riski: YÜKSEK
• Neden: Erişim süreci sırasında, özellikle oturum açma ve kapatma zamanları, kullanıcının atanan IP adresi, MAC adresi ve kullanılan port bilgileri RADIUS sunucusunda otomatik olarak ve değiştirilemez (immutable) bir şekilde kaydedilir. Bu kayıtlar, genellikle özel olarak tasarlanmış muhasebe loglarında (Accounting Logs) tutulur ve sıkı bir denetim altındadır. Veritabanı entegrasyonu durumunda, veritabanının kendi denetim logları da (audit trails) her türlü sorgulama veya silme girişimini kaydeder. Merkezi tutulmaları, tek bir noktadan denetlenebilirliği artırır ve manipülasyonu zorlaştırır.

4.2. Syslog Sistemleri ve İz Manipülasyon Riski Syslog, sistem ve ağ cihazlarından logların toplanmasını sağlayan temel protokoldür. Loglar genellikle merkezi bir sunucuda toplanır.

• İz Bırakma Riski: ORTA
• Neden: Syslog logları temelde metin dosyalarıdır veya basit veritabanlarında saklanır. Bu nedenle, yetkili bir sistem yöneticisi (root yetkisiyle) tarafından bu log dosyaları üzerinde doğrudan müdahale ve silme işlemleri yapılabilir. Ancak:
  • Metadata İzleri: Dosya boyutundaki ani düşüşler, son erişim/değişiklik zamanlarındaki (atime, mtime, ctime) değişiklikler gibi metadata izleri sistemde kalır ve adli incelemelerde (forensic analysis) tespit edilebilir.
  • Denetim Logları: Çoğu Linux sistemi, dosya sistemi erişimlerini ve kritik komutları denetim loglarına (auditd) kaydeder. Bir log dosyasının silinmesi komutu bu denetim loglarında bir iz bırakacaktır.
  • Log Aktarımı: Loglar merkezi bir SIEM sistemine aktarılıyorsa, kaynak sunucudaki silme işlemi, SIEM’deki log akışının aniden kesilmesine veya anormallikler içermesine neden olur ve bu durum otomatik olarak alarm üretebilir. Tamamen iz bırakmadan silmek, Syslog hizmetini durdurmak, diski sıfırlamak gibi daha radikal ve belirgin eylemler gerektirir.

4.3. Deep Packet Inspection (DPI) Sistemleri ve Yüksek İzleme Yeteneği DPI sistemleri, ağ trafiğini derinlemesine analiz ederek protokol ve içerik seviyesinde veri toplayan sistemlerdir.

• İz Bırakma Riski: YÜKSEK
• Neden: DPI, ağ üzerindeki hemen hemen tüm paketleri inceler ve anormal aktiviteleri tespit etmek için detaylı kayıtlar tutar. Bir kullanıcının erişim sırasında ürettiği trafik verilerinden (kaynak/hedef IP, port, protokol, uygulama, veri miktarı, bağlantı zamanlaması) kolaylıkla çıkarım yapılabilir ve erişim izleri hassas bir şekilde tespit edilebilir. DPI’ın yüksek seviyede görünürlük sağlaması, şifreli trafiğin bile (TLS fingerprinting gibi tekniklerle) belirli düzeyde sınıflandırılmasına olanak tanır. DPI tarafından üretilen loglar genellikle merkezi veritabanlarına veya SIEM sistemlerine yönlendirilir, bu da onların silinmesini çok daha zorlaştırır.

4.4. Veritabanı Sistemleri (Database – DB) ve Değişiklik Takibi Veritabanları, uygulama ve sistem loglarını, ayrıca işlem verilerini tutar.

• İz Bırakma Riski: ORTA
• Neden: Veritabanlarındaki loglar ve kayıtlar, yetkili kişilerce (DBA) SQL komutları aracılığıyla silinebilir veya değiştirilebilir. Ancak, modern kurumsal veritabanı sistemleri (PostgreSQL, Oracle, SQL Server) genellikle gelişmiş “denetim izi” (audit trails), “işlem günlüğü” (transaction logs) ve “geri alma günlükleri” (rollback segments) gibi mekanizmalara sahiptir. Bu mekanizmalar, veritabanı üzerinde yapılan her türlü değişikliği (INSERT, UPDATE, DELETE) kaydeder. Dolayısıyla, bir log kaydını silmek bile, bu işlemin kendisinin veritabanının dahili denetim loglarında bir iz bırakmasına neden olur. Yedekler de bu silme işleminden önceki durumu korur. Tamamen izsiz erişim teknik olarak zordur, çünkü veritabanı sistemleri veri bütünlüğünü ve denetlenebilirliği korumak üzere tasarlanmıştır.

4.5. SIEM Sistemleri ve Kapsamlı İz Kaydı SIEM (Security Information and Event Management) sistemleri, farklı kaynaklardan gelen logları toplar, normalize eder, ilişkilendirir ve kapsamlı güvenlik analizi yapar.

• İz Bırakma Riski: ÇOK DÜŞÜK (Yani iz bırakma olasılığı ÇOK YÜKSEK)
• Neden: SIEM sistemleri, tasarımları gereği, veri bütünlüğünü ve kayıtların değiştirilemezliğini (immutability) sağlamak üzere optimize edilmiştir. Loglar, birden fazla kaynaktan toplanır ve merkezi, genellikle dağıtık ve yedekli bir depolama mimarisine (örneğin Elasticsearch cluster) aktarılır. Bu sistemler sadece logları depolamakla kalmaz, aynı zamanda korelasyon motorları sayesinde anormallikleri ve saldırı imzalarını tespit edip alarm üretirler. Bir log kaynağında (örneğin bir sunucuda) logların silinmesi durumunda bile, SIEM bu logları zaten toplamış ve kendi değişmez deposuna kaydetmiş olabileceğinden, silinen kaydın kopyası SIEM’de kalır. Ayrıca, SIEM, bir log akışının aniden kesildiğini veya eksik olduğunu fark ederek alarm üretebilir. Bu nedenle, SIEM ortamlarında iz bırakmama ihtimali pratik olarak imkansızdır.

4.6. Sonuç: Modern Altyapılarda İz Bırakmama Çabalarının Sonuçları Yukarıdaki değerlendirmeler ışığında, modern bilgi teknolojileri altyapılarında yetkisiz ve iz bırakmadan erişim sağlamak pratikte mümkün değildir. Sistemlerin doğası gereği, özellikle güvenlik ve denetim amaçlı geliştirilen protokol ve sistemler (RADIUS, DPI, SIEM, veritabanı denetim logları) erişim olaylarını kaydetmekte ve bu kayıtlar erişim sonrası adli analizlerde kritik rol oynamaktadır. İz bırakmama çabaları, sistemdeki izlerin tamamen silinmesi veya manipüle edilmesi anlamına gelir ki bu da:

• Ek izlerin (dosya metadata değişiklikleri, denetim logları) oluşmasına neden olabilir.
• Sistemde anormallikler ve alarm durumları yaratabilir.
• Daha ileri düzey adli bilişim teknikleriyle (disk imajları, bellek analizleri) tespit edilme riskini artırır. Sonuç olarak, yasal ve etik olmayan yollarla logları silmeye veya manipüle etmeye çalışmak, yalnızca ek riskler ve daha ciddi hukuki sonuçlar doğuracaktır.

---

5. Sonuç ve Genel Değerlendirme

ISP loglarının yönetimi, günümüzün karmaşık siber güvenlik ve yasal uyumluluk ortamında kritik bir disiplindir. Bu kitapçıkta incelendiği üzere, RADIUS/AAA sunucularından Syslog sistemlerine, derin paket inceleme (DPI) çözümlerinden merkezi veritabanı depolama mekanizmalarına ve nihayetinde SIEM platformlarına kadar geniş bir yelpazede log verileri üretilmekte ve işlenmektedir.

Etkili log yönetimi, bir kurumun güvenlik duruşunu güçlendirmek, operasyonel verimliliği artırmak ve yasal düzenlemelere (KVKK, GDPR gibi) uyum sağlamak için vazgeçilmezdir. Loglar; güvenlik ihlallerinin tespitinde adli kanıt olarak, performans sorunlarının giderilmesinde tanı aracı olarak ve gelecekteki kapasite ihtiyaçlarının planlanmasında temel veri olarak hizmet eder.

Öte yandan, bu kitapçıkta vurgulandığı gibi, modern bilgi teknolojileri altyapılarında “iz bırakmadan” hareket etmek veya bırakılan izleri tamamen ortadan kaldırmak pratik olarak imkansızdır. Her müdahale, sistemin farklı katmanlarında yeni dijital izler bırakmaya eğilimlidir. SIEM gibi bütünleşik güvenlik sistemleri, bu izleri bir araya getirerek olayları korele etme ve görünürlüğü artırma yeteneğiyle, şüpheli faaliyetlerin tespitini önemli ölçüde güçlendirmektedir.

5.1. Etkili Log Yönetimi İlkeleri

• Merkeziyet: Logları tek bir noktada toplamak, analiz ve yönetim kolaylığı sağlar.
• Normalizasyon: Farklı formatlardaki logları tutarlı bir yapıya dönüştürmek, korelasyonu mümkün kılar.
• Otomasyon: Log toplama, depolama, rotasyon ve analiz süreçlerini otomatize etmek, insan hatasını azaltır ve verimliliği artırır.
• Güvenlik: Logların bütünlüğünü, gizliliğini ve erişilebilirliğini sağlamak için şifreleme, erişim kontrolleri ve yedekleme mekanizmaları uygulamak.
• Korelasyon: İlgili logları birleştirerek güvenlik olaylarının daha geniş bir bağlamını oluşturmak ve anormallikleri tespit etmek.
• Periyodik Denetim ve Gözden Geçirme: Logların düzenli olarak denetlenmesi, güvenlik kurallarının güncellenmesi ve sistemin uyumluluğunun kontrol edilmesi.

5.2. Gelecek Trendler ve Gelişmeler Log yönetimi alanı, Büyük Veri (Big Data) teknolojileri, yapay zeka (AI) ve makine öğrenimi (ML) entegrasyonu ile sürekli gelişmektedir. Bu teknolojiler, insan analistlerinin gözünden kaçabilecek karmaşık tehditleri ve anormallikleri tespit etme yeteneğini artırmaktadır. Güvenlik analitikleri, davranışsal analizler ve tehdit istihbaratı entegrasyonu, gelecekteki log yönetim sistemlerinin temelini oluşturacaktır.

Sonuç olarak, ISP’ler ve diğer büyük kurumlar için sağlam bir log yönetimi stratejisi, sadece teknik bir gereklilik değil, aynı zamanda operasyonel devamlılık, güvenlik ve yasal sorumlulukların yerine getirilmesi açısından kritik bir iş sürecidir. Bu kitapçık, bu karmaşık alana dair temel bir anlayış sunmayı ve dijital izlerin yönetimi konusundaki farkındalığı artırmayı ummaktadır.

KAYNAKÇA

---

1. Log Yönetimi ve SIEM Sistemleri

• Scarfone, K., & Mell, P. (2007). Guide to Computer Security Log Management (NIST SP 800-92). National Institute of Standards and Technology.
  https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf
• Bejtlich, R. (2013). The Practice of Network Security Monitoring: Understanding Incident Detection and Response. No Starch Press.
• Chuvakin, A., Schmidt, K., & Phillips, C. (2013). Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management. Syngress.
• Allen, J., Christie, A., Fithen, W., McHugh, J., Pickel, J., & Stoner, E. (2000). State of the Practice of Intrusion Detection Technologies. Carnegie Mellon Software Engineering Institute.
  https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5175

---

2. RADIUS, Syslog ve DPI Sistemleri

• Rigney, C., Willens, S., Rubens, A., & Simpson, W. (2000). Remote Authentication Dial In User Service (RADIUS). IETF RFC 2865.
  https://datatracker.ietf.org/doc/html/rfc2865
• Lonvick, C. (2001). The BSD Syslog Protocol. IETF RFC 3164.
  https://datatracker.ietf.org/doc/html/rfc3164
• Aiello, W., Bellovin, S. M., Blaze, M., Ioannidis, J., Keromytis, A. D., & Reiter, M. K. (2003). Efficient, DoS-Resistant, Secure Key Exchange for Internet Protocols. ACM Transactions on Information and System Security (TISSEC), 7(2), 242–273.
• Wang, H., & Khan, S. (2020). Deep Packet Inspection: Threats, Protection, and Technologies. Journal of Network and Computer Applications, 160, 102630.
  https://doi.org/10.1016/j.jnca.2020.102630

---

3. Log Silme, Anti-Forensics ve İz Manipülasyonu

• Harris, S. (2019). Gray Hat Hacking: The Ethical Hacker’s Handbook (5th ed.). McGraw-Hill Education.
• Casey, E. (2011). Digital Evidence and Computer Crime: Forensic Science, Computers and the Internet (3rd ed.). Academic Press.
• Rogers, M. K. (2006). Anti-Forensics: The Coming Wave in Digital Forensics. Digital Investigation, 3, Supplement, 1–3.
  https://doi.org/10.1016/j.diin.2006.06.003
• Baggili, I., Breitinger, F., & Marrington, A. (2015). Anti-forensics Techniques: A Survey and Evasion Trends. In Proceedings of the 2015 International Conference on Digital Forensics and Cyber Crime (ICDF2C). Springer.
• Mandia, K., Prosise, C., & Pepe, M. (2003). Incident Response and Computer Forensics (2nd ed.). McGraw-Hill.

---

4. Veritabanı Logları ve Silme Yöntemleri

• PostgreSQL Global Development Group. (2024). PostgreSQL Documentation – Logging Collector & Log Management.
  https://www.postgresql.org/docs/current/runtime-config-logging.html
• MongoDB Inc. (2023). MongoDB Security Manual – Audit Logs and Data Redaction.
  https://www.mongodb.com/docs/manual/core/auditing/
• Oracle Corporation. (2022). Oracle Database 21c Security Guide – Auditing and Log Management.
  https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/auditing.html

---

5. Uyumluluk ve Hukuki Çerçeve (Türkiye’den)

• Bilgi Teknolojileri ve İletişim Kurumu (BTK). (2020). İnternet Toplu Kullanım Sağlayıcılar Hakkında Yönetmelik.
  https://www.resmigazete.gov.tr/eskiler/2020/04/20200411-8.htm
• Kişisel Verileri Koruma Kurumu (KVKK). (2016). 6698 Sayılı Kişisel Verilerin Korunması Kanunu.
  https://www.kvkk.gov.tr/Icerik/6649/Kanun
• UYAP Bilişim Sistemi Log Yönetimi ve İnceleme Süreci – TUBİTAK Bilgem Yayınları (2021). (Kurumsal kullanım için sınırlı dağıtım)