FleetDM + osquery ile Sunucu Envanteri ve Güvenlik Sinyalleri

Kurumsal altyapıda “envanter” çoğu zaman statik bir Excel veya CMDB kaydıdır. Üretim ise dinamiktir: paket sürümü değişir, kernel parametresi güncellenir, yeni kullanıcı eklenir, beklenmeyen port açılır. Bu yüzden ben envanteri “liste” değil, sorgulanabilir canlı gerçek olarak tasarlamayı severim.

osquery bunu mümkün kılar: işletim sistemini bir veritabanı gibi sorgularsınız. FleetDM ise osquery’i yüzlerce/binlerce node’a yönetilebilir biçimde yayar.

Mimari: Minimum bileşenlerle “işleyen” kurulum

FleetDM’in pratik minimum mimarisi:

• Fleet server
• MySQL (state)
• Redis (queue/cache)
• osquery agent (host’larda)

Üretimde iki tavsiye:

1. Fleet’i ayrı bir yönetim segmentinde çalıştırın (her yerden erişilen “genel servis” gibi davranmasın)
2. TLS’yi standardize edin (reverse proxy ile ya da doğrudan Fleet üzerinde)

Agent dağıtımı: “kur” değil, “yaşat”

Agent tarafında hedef:

• Kurulum otomasyonla (örn. Ansible, salt, cloud-init)
• Enrollment secret yönetimi (rotasyon planı)
• “Offline host” sinyali (agent yok mu, host yok mu?)

Pratik yaklaşım:

1. Agent’ı paket yöneticisi veya signed binary ile kur
2. Enrollment secret’i dosya/secret store’dan ver
3. Systemd ile servisleştir (restart policy + kaynak sınırı)
4. İlk gün label/segment mantığını kur (prod/pilot/dev gibi)

Query pack tasarımı: “her şeyi” değil, karar üreteni

Başlangıçta her şeyi sorgulamak caziptir ama sürdürülemez. Ben pack’leri üçe ayırırım:

• Inventory (günde 1): kernel, OS version, package list, disk/mount
• Security baseline (saatte 1): SSH config, sudoers değişimi, kritik dosya hash
• Hunt / incident (geçici): belirli IOC, process, port, persistence

Örnek: kritik SSH sinyalleri

SELECT
  key,
  value
FROM ssh_configs
WHERE key IN ('PermitRootLogin', 'PasswordAuthentication', 'PubkeyAuthentication');

Örnek: beklenmeyen dinleyen port’lar

SELECT
  p.pid,
  p.name,
  l.address,
  l.port,
  l.protocol
FROM listening_ports l
JOIN processes p ON l.pid = p.pid
WHERE l.port NOT IN (22, 80, 443);

Operasyonel akış: Sinyali nereye akıtacağım?

Fleet/osquery tek başına “kayıt” üretir. Değer üretmesi için sinyali şu üç yere bağlayın:

• Log pipeline (ör. Vector/OTel → arama + arşiv)
• Alerting (eşik/istatistik: yeni kullanıcı, yeni port, baseline sapması)
• Runbook (alarm geldiğinde ilk 5 adım)

Benim sahada işleyen kuralım: sorgu + alarm + runbook üçlüsü yoksa, o sorgu bir süre sonra unutulur.

Performans ve maliyet: Agent’ı “gürültüsüz” tut

Sık yapılan hatalar:

• Dakikada bir processes gibi ağır tabloları taramak
• Tüm host’larda aynı sıklıkla aynı sorguyu koşturmak
• Query sonucunu olduğu gibi SIEM’e akıtıp maliyeti patlatmak

Çözüm:

• Sıklığı düşür (inventory günlük)
• Label bazlı farklılaştır (prod daha sık, dev daha seyrek)
• Özetle (delta gönder, tam liste gönderme)

Incident sırasında kullanım: “hunt paketi” ile kontrollü arama

Incident’ta osquery çok iş görür ama kural şu: geçici pack.

• IOC hash’leri
• Şüpheli process isimleri
• Persistence noktaları (cron, systemd, rc scripts)

Olay bittiğinde pack’i kapatın. “Incident sorguları” kalıcı kaldıkça maliyet ve risk birikir.

Sonuç

FleetDM + osquery, kurumsal altyapıda envanteri “doküman” olmaktan çıkarıp, operasyon ve güvenlik için ortak bir sorgu katmanına dönüştürür. Doğru kurulduğunda; drift’i, beklenmeyen port’ları, baseline sapmalarını ve incident sinyallerini hızlıca görünür kılar. Yanlış kurulduğunda ise gürültü üretir. Bu yüzden küçük başlayın, karar üreten pack’lerle büyütün.