File Integrity Monitoring (FIM) Nedir? Dosya Bütünlüğü İzleme Rehberi

FIM nedir ve neden gereklidir?

FIM, sistemin “olması gereken” halini kaydedip sonraki her değişikliği bu kayda göre değerlendiren bir güvenlik kontrolüdür. Gereklidir, çünkü saldırganların kalıcılık kurmak, yetki yükseltmek veya iz silmek için yaptığı işlerin çoğu bir dosyayı değiştirmek demektir.

Bir saldırgan sisteme girdikten sonra genellikle iz bırakır: yeni bir kullanıcı ekler, authorized_keys dosyasına kendi SSH anahtarını yazar, zamanlanmış görev oluşturur, bir sistem dosyasını değiştirir ya da web dizinine bir betik bırakır. MITRE ATT&CK bu davranışları ayrı teknikler olarak tanımlar; örneğin SSH Authorized Keys (T1098.004) ve Cron (T1053.003). Bu adımlar ağ trafiğinde zor görülür, ama dosya sisteminde açık bir iz bırakır. FIM tam da burada çalışır: şifreli bir oturumla içeri giren saldırganın ne yaptığını, sunucunun kendi dosya sisteminden gösterir.

• Saldırı tespiti — Yetkisiz değişiklikleri, kalıcılık mekanizmalarını ve sisteme bırakılan zararlı dosyaları ortaya çıkarır.
• Değişiklik yönetimi — Planlı değişikliklerin gerçekten yapıldığını, plansız olanların da fark edildiğini gösterir.
• Uyumluluk — PCI DSS v4.0, kritik dosyalardaki yetkisiz değişiklikleri tespit eden bir mekanizma ister (Gereksinim 11.5.2) ve buna örnek olarak FIM araçlarını gösterir. FIM kayıtları ISO 27001 gibi çerçevelerdeki değişiklik yönetimi ve izleme kontrolleri için de kanıt üretir.
• Adli inceleme — Bir olaydan sonra hangi dosyanın ne zaman değiştiğini gösteren kayıt, saldırının zaman çizelgesini kurmayı kolaylaştırır.

FIM nasıl çalışır? Temel durum, hash ve değişiklik tespiti

FIM önce izlenen dosyaların temel durumunu (baseline) çıkarır: her dosyanın kriptografik hash değeri, boyutu, izinleri, sahibi ve değişiklik zamanı kaydedilir. Sonraki her kontrolde aynı öznitelikler yeniden hesaplanır; temel durumdan bir fark varsa değişiklik olayı üretilir.

Neden hash karşılaştırması?

Değişiklik zamanı ve dosya boyutu kolayca taklit edilebilir; saldırganlar dosya tarihlerini eski haline getirebilir. MITRE ATT&CK bu yönteme Timestomp (T1070.006) der. SHA-256 gibi bir kriptografik hash ise dosyanın içeriğinden hesaplanır; tek bir bayt değişse bile sonuç tamamen farklı olur. Bu yüzden içerik değişikliğinin güvenilir göstergesi hash karşılaştırmasıdır.

Gerçek zamanlı izleme mi, periyodik tarama mı?

• Gerçek zamanlı izleme — İşletim sisteminin dosya olaylarını kullanır (Linux’ta inotify veya auditd, Windows’ta dosya sistemi bildirimleri ve denetim olayları). Değişiklik anında görülür ve kullanıcı ile süreç bilgisini yakalamak kolaylaşır.
• Periyodik tarama — Dosyaları belirli aralıklarla yeniden hash’ler. Kaynak kullanımı öngörülebilirdir, ancak iki tarama arasında oluşturulup silinen bir dosya gözden kaçabilir.

Birçok ekip ikisini birlikte kullanır: kritik yapılandırma dosyaları için anlık izleme, büyük ikili dosya dizinleri için zamanlanmış tarama.

Linux’ta hangi dosyalar izlenmeli?

Linux’ta öncelik kimlik doğrulama ve yetki dosyaları, SSH yapılandırması, zamanlanmış görevler, servis tanımları ve sistem ikili dosyalarıdır. Web sunucusu çalışan makinelerde web kök dizini ve sunucu yapılandırması da listeye eklenmelidir.

Paket yöneticisiyle kurulan dosyalar için ek bir kontrol imkânı da vardır: rpm -Va (RHEL ailesi) ve debsums (Debian/Ubuntu) kurulu dosyaları paket veritabanındaki özetlerle karşılaştırır. Bu araçlar sürekli izleme yapmaz, ama bir şüphe anında hangi sistem dosyalarının paketten farklılaştığını hızla gösterir.

/proc ve /sys gibi sanal dosya sistemlerini kapsam dışında bırakın; /tmp gibi sürekli değişen dizinleri ise yalnızca belirli desenlerle izleyin (örneğin yeni çalıştırılabilir dosyalar). Log dosyaları sürekli büyüdüğü için klasik hash karşılaştırması orada çok gürültü üretir; logların bütünlüğü daha çok merkezi toplama ve arşivlerin hash ile zaman damgasıyla korunmasıyla sağlanır. Bu konuyu log yönetimi rehberimizde ele alıyoruz.

Windows’ta hangi dosyalar izlenmeli?

Windows’ta sistem dizinleri, başlangıç klasörleri, zamanlanmış görevler, hosts dosyası ve IIS web dizinleri öncelikli adaylardır. Kalıcılık yöntemlerinin bir kısmı kayıt defterinde (registry) yaşadığı için, kullandığınız araç destekliyorsa ilgili anahtarları da kapsama alın.

Kayıt defterinde en çok izlenen yerler, oturum açılışında program çalıştıran Run ve RunOnce anahtarları, servis tanımlarının bulunduğu Services anahtarı (HKLM\SYSTEM\CurrentControlSet altında) ve güvenlik ilkelerine ait anahtarlardır. Bunlar dosya olmadığı için her FIM aracı kapsamaz; kapsamıyorsa Windows olay günlüklerindeki kayıt defteri denetim olaylarını (ör. Event ID 4657) SIEM üzerinden takip edebilirsiniz.

Windows’ta dosya erişimini yerel olarak denetlemek için nesne erişimi denetiminin açılması ve ilgili klasörlere SACL tanımlanması gerekir; bu durumda erişimler Event ID 4663 ile kaydedilir. Sysmon kullanıyorsanız dosya oluşturma olayları (Event ID 11) da değerli bir kaynaktır. Bu olaylar tek başına içerik karşılaştırması yapmaz, ama bir FIM uyarısına kullanıcı ve süreç bağlamı eklemek için çok işe yarar.

FIM ile webshell ve fidye yazılımı nasıl tespit edilir?

Webshell, web dizinine yazılan yeni ya da değiştirilmiş bir betik dosyasıdır; FIM bunu dosya oluştuğu anda görür. Fidye yazılımı ise kısa sürede çok sayıda dosyanın içeriğini değiştirir ve dosyaları yeniden adlandırır; FIM bu olağandışı değişiklik hacmini fark edebilir.

Webshell

MITRE ATT&CK’te T1505.003 olarak geçen webshell, saldırganın web sunucusu üzerinden komut çalıştırmasını sağlar. Genellikle bir dosya yükleme açığı, zafiyetli bir eklenti veya ele geçirilmiş bir yönetim hesabıyla yerleştirilir. FIM açısından tipik belirtiler şunlardır:

• Web kök dizininde, özellikle yükleme (uploads) klasörlerinde yeni bir .php, .jsp, .aspx veya .ashx dosyası
• Mevcut bir betiğe eklenmiş birkaç satırlık kod; dosya farkı (diff) bu satırları doğrudan gösterir
• Web sunucusu hesabının (www-data, IIS uygulama havuzu) yazdığı çalıştırılabilir dosya
• Dağıtım penceresi dışında, değişiklik kaydı olmadan yapılan değişiklik

Webshell dosyaları çoğu zaman meşru bir dosya adı taşır (header.php, upload.aspx gibi) ve içerik olarak gizlenmiş olabilir; bu yüzden ada veya imzaya değil, “bu dizinde bu dosya neden yeni?” sorusuna dayanan FIM yaklaşımı etkilidir. Tespit ve müdahale adımlarını webshell rehberimizde ayrıntılı anlatıyoruz.

Fidye yazılımı

Fidye yazılımı (T1486) dosyaları şifrelediği için hash değerleri topluca değişir, çoğu zaman dosyalar yeni bir uzantıyla yeniden adlandırılır ve dizinlere fidye notu bırakılır. FIM tarafında bu, aynı süreçten kısa sürede gelen yüzlerce değişiklik ve yeniden adlandırma olayı olarak görünür. Dosya paylaşımlarında ve kritik veri dizinlerinde değişiklik hacmine eşik koyan bir kural, şifrelemenin erken aşamasında uyarı üretebilir. FIM bir önleme aracı değildir; erken uyarının değeri, müdahalenin hızına bağlıdır.

Beklenen ve yetkisiz değişiklikler nasıl ayrılır?

Her değişiklik saldırı değildir; yamalar, paket güncellemeleri ve uygulama dağıtımları da dosya değiştirir. Ayrımın yolu değişikliği bağlamıyla değerlendirmektir: kim yaptı, hangi süreçle, ne zaman ve onaylı bir değişiklik kaydıyla eşleşiyor mu?

• Değişiklik pencereleri — Planlı bakım saatlerindeki değişiklikleri düşük önem derecesiyle kaydedin; pencere dışındaki aynı değişiklik yüksek önemle uyarı üretsin.
• Kullanıcı ve süreç bağlamı — Paket yöneticisinin (apt, dnf, Windows Update) yaptığı değişiklik ile etkileşimli bir kabuktan yapılan değişiklik aynı riski taşımaz.
• Dosya farkı — Yapılandırma dosyalarında hangi satırın değiştiğini görmek, yalnızca “dosya değişti” bilgisinden çok daha hızlı karar verdirir.
• Önem derecesi ve kapsam — /etc/shadow veya sudoers değişikliğini kritik, bir uygulama önbelleğindeki değişikliği bilgi seviyesinde tutun; gereksiz dizinleri kapsamdan çıkarın.
• Temel durumu güncelleme — Onaylanan değişiklikten sonra temel durumu yenileyin; aksi halde aynı değişiklik her kontrolde yeniden uyarı üretir.

Değişiklik yönetimi sürecinizle (ör. bir talep veya değişiklik kaydı numarası) eşleşmeyen her yüksek önemli olay, en azından bir analistin bakması gereken bir kayıttır. Bu disiplin hem güvenlik hem de denetim için aynı kanıtı üretir.

FIM ve SIEM birlikte nasıl kullanılır?

FIM bir dosyanın değiştiğini söyler; SIEM ise bu değişikliği aynı zaman aralığındaki oturum açma, ağ ve süreç olaylarıyla birleştirerek ne anlama geldiğini gösterir. Birlikte kullanıldığında tek bir dosya değişikliği, uçtan uca bir saldırı zincirinin parçası olarak görülebilir.

Örneğin FIM, bir sunucuda authorized_keys dosyasının değiştiğini bildirir. Tek başına bu, bir yöneticinin rutin işlemi olabilir. Ancak SIEM aynı sunucuda birkaç dakika önce yabancı bir IP’den çok sayıda başarısız SSH denemesi ve ardından başarılı bir giriş gördüyse, olay kaba kuvvet saldırısının (T1110) ardından kalıcılık kurma girişimi olarak değerlendirilir.

08:41:12  sshd  Failed password for root from 203.0.113.45 port 52114 ssh2
08:41:13  sshd  Failed password for root from 203.0.113.45 port 52130 ssh2
          ...   (300+ failed attempts within minutes)
08:47:55  sshd  Accepted password for deploy from 203.0.113.45 port 53001 ssh2
08:48:20  fim   MODIFIED /home/deploy/.ssh/authorized_keys  user=deploy  sha256 changed

• Korelasyon — FIM olayını kimlik doğrulama, ağ ve süreç loglarıyla aynı zaman çizelgesine yerleştirir.
• Zenginleştirme — Olaydaki IP adresini tehdit istihbaratıyla karşılaştırır, varlığın önemini ve risk puanını ekler.
• Saklama ve arama — FIM geçmişini diğer loglarla birlikte saklar; aylar sonra yapılan bir incelemede de sorgulanabilir.
• Olay yönetimi — Uyarıyı sorumlusu ve durumu takip edilen bir olaya dönüştürür; müdahale adımları aynı kayıtta toplanır.

Logchase’te dosya bütünlüğü izleme SIEM ile aynı platformda çalışır: Linux ve Windows’taki değişiklikler SHA-256 karşılaştırması, dosya farkı, kullanıcı ve süreç bilgisiyle kaydedilir; dosya olaylarını aynı zamandaki giriş, süreç ve ağ olaylarıyla birlikte inceleyebilirsiniz.