Conditional Silent Log

Conditional Silent Log Aksiyonu Nedir?

Conditional Silent Log aksiyonu, TR7 üzerinde çalışan vService'lerde belirlenen koşullar sağlandığında Syslog, SIEM sunucularına log gönderimini durdurarak ilgili istek/yanıtın loglara yazılmasını engeller. Bu aksiyon, istek (request) veya yanıt (response) aşamasında devreye alınabilir.

İstek (örn: /health)

↓

Koşul eşleşir

↓

Log'a yazılmaz · SIEM'e gönderilmez

Conditional Silent Log aksiyonu; yüksek hacimli, düşük değerli veya tekrarlayan trafiğin log yoğunluğunu artırdığı senaryolarda, SIEM ve log altyapısının gereksiz yüklenmesini önlemek amacıyla yaygın olarak kullanılır. Bu sayede loglar daha anlamlı olaylara odaklanır ve operasyonel görünürlük korunurken maliyet ve gürültü azaltılır.

Conditional Silent Log Aksiyonunun Önemi

Canlı ortamlarda loglar; izleme, olay müdahalesi, adli analiz ve uyumluluk açısından kritik öneme sahiptir. Ancak belirli trafik türleri (örneğin health-check istekleri, belirli IP aralıklarından gelen yoğun taramalar, bilinen bot trafiği veya belirli endpoint'lere yönelik tekrarlı istekler) loglarda gürültü oluşturarak gerçek olayların ayıklanmasını zorlaştırabilir.

Conditional Silent Log aksiyonu;

• Log gürültüsünü azaltır ve anlamlı olayların görünürlüğünü artırır,
• SIEM ve log altyapısının kaynak tüketimini düşürür,
• Yüksek trafik altında log kaynaklı performans etkisini minimize eder,
• Belirli senaryolarda operasyonel maliyetleri (saklama/indeksleme) azaltır,
• Log politikalarının vService seviyesinde kontrollü ve esnek şekilde uygulanmasını sağlar.

Bu nedenle Conditional Silent Log aksiyonu, TR7 üzerinde log yönetimi ve operasyonel sürdürülebilirlik açısından kritik bir kontrol mekanizmasıdır.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir Conditional Silent Log Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak Conditional Silent Log seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Conditions sekmesinden aksiyonun hangi koşul/koşullarda devreye gireceği belirlenir.
7. Add butonuna tıklanarak aksiyon eklenir.

Conditional Silent Log Aksiyonu Ekleme Formu

Conditional Silent Log Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan aksiyona benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak Conditional Silent Log seçilir.

INFO

Execution Level

Aksiyonun hangi aşamada çalıştırılacağını belirler.

Alan değiştirildiğinde Conditions alanı sıfırlanır (girilmiş koşullar silinir). On Response seçildiğinde koşul listesinde yalnızca yanıt aşamasında değerlendirilebilen kriterler sunulur. Aksiyon bir vService içinden ekleniyorsa bu alan otomatik dolar ve değiştirilemez; kayıttan sonra da değiştirilemez.

• On Request: Aksiyon, istek ilgili Kurum Servisine iletilmeden önce uygulanır. Bu seviye, istek üzerinde değişiklik yapılması veya Kurum Servisine ek bilgi iletilmesi gereken durumlarda kullanılır.
• On Response: Aksiyon, yanıt istemciye iletilmeden önce uygulanır. Bu seviye, istemciye gönderilen yanıt üzerinde düzenleme veya ekleme yapılması gereken durumlarda kullanılır.

INFO

Hit Counter Varsayılan: Kapalı

Hit Counter, aksiyonun her çalışmasını sayar (aksiyonun kendi koşuluyla birlikte değerlendirilir; Deny gibi sonlandırıcı aksiyonlarda bile sayım kaybolmaz). Aksiyon bazlı hız ve toplamlar, vService panosundaki Action Hits sekmesinde ve canlı istatistik ekranında görüntülenir; listelerde ayrıca bir kolon olarak görünmez. Sayaç kümülatiftir; elle sıfırlama arayüzü yoktur: sayılan aksiyon kümesi değiştiğinde veya vService yeniden yüklendiğinde sıfırdan başlar, geçmiş ise panoda hız (hit/s) olarak korunur.

INFO

Set Variable on Hit

Aksiyon her çalıştığında değeri atanacak bir değişken adı girilebilir (isteğe bağlı; varsayılan boş). Ad; harf, rakam ve alt çizgiden oluşabilir (en fazla 32 karakter). Aksiyon tetiklendiğinde değişken 1 değerine atanır ve aynı vService'teki diğer koşul ve aksiyonlarda %TR7VAR(ad) akıllı değişkeniyle okunarak zincirleme davranışlar kurulabilir.

INFO

Conditions

Bu alanda, ilgili aksiyonun hangi koşul veya koşullar sağlandığında devreye gireceği tanımlanır.

Bir veya birden fazla koşul eklenerek, and/or yapısı ile davranışın hedefli ve kontrollü şekilde uygulanması sağlanabilir.

Koşullar hakkında detaylı bilgi Conditions sayfasında yer alır.

WARNING

Bu alanda herhangi bir koşul tanımlanmazsa, ilgili aksiyon koşulsuz (Always) olarak çalışır. Bu durumda aksiyon, ilgili vService'e gelen tüm trafiğe uygulanır.

Canlı ortamlarda, koşul tanımlanmadan aksiyon kullanılması beklenmeyen durumlara (servis kesintilerine) yol açabilir. Bu nedenle aksiyon oluşturulurken mutlaka en az bir koşul tanımlanması önerilir.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

Operasyonel ve Güvenli Kullanım Önerileri

Conditional Silent Log aksiyonu, TR7 üzerinde log yönetimini sadeleştirmek için güçlü bir mekanizma sunar. Aşağıdaki öneriler, canlı ortamlarda güvenli ve kontrollü kullanım sağlar.

• Geç Oluşan Koşullara Dikkat Edin. Bot skoru veya WAF durumu gibi geç oluşan bilgilere bağlı koşullarda, daha önce sonlandırılan istekler (ör. koruma katmanı tarafından düşürülen trafik) yine loglanabilir; log susturma en güvenilir sonucu istek başında değerlendirilebilen koşullarla (path, kaynak IP, başlık) verir.
• Gürültü Üreten Trafikleri Hedefleyin. Health-check istekleri, belirli bot trafiği, tekrarlayan taramalar veya düşük değerli endpoint istekleri gibi log gürültüsü oluşturan trafik türlerinde kullanılmalıdır.
• Koşulları Minimum ve Net Tutun. Gereğinden geniş koşullar, kritik olayların loglanmamasına neden olabilir. Koşullar mümkün olduğunca hedefli ve doğrulanabilir şekilde tanımlanmalıdır.
• Kritik Endpoint'lerde Kullanımı Sınırlandırın. Kimlik doğrulama, yönetim arayüzleri, ödeme akışları ve hassas API'ler gibi kritik noktalarda logların kapatılması yerine daha seçici bir yaklaşım tercih edilmelidir.
• Canlı Ortamda Değişiklik Öncesi "Used In" Bilgisini Kontrol Edin. Bir Conditional Silent Log aksiyonunun hangi vService'lerde aktif olduğunu kontrol etmeden değişiklik yapılması, beklenmeyen görünürlük kaybına neden olabilir.
• SIEM ve Denetim Gereksinimlerini Göz Önünde Bulundurun. Uyumluluk ve denetim gereksinimi olan ortamlarda, hangi trafiklerin log dışı bırakılacağı operasyonel politikalar ile uyumlu olmalıdır.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: Health-Check İsteklerini Log Dışı Bırakma

Problem: Load balancer ve monitoring sistemleri her 5 saniyede bir /health, /status endpoint'lerine istek gönderiyor. Bu istekler günde yüz binlerce log kaydı oluşturarak SIEM'i ve log storage'ı gereksiz yere dolduruyor.

Çözüm: Health-check endpoint'lerine yapılan istekler log dışı bırakılarak SIEM gürültüsü azaltılır ve anlamlı olaylara odaklanılır.

Konfigürasyon:

• Execution Level: On Request
• Conditions:
  • Path = /health
  • OR Path = /status
  • OR Path = /ping

Sonuç:

• ✅ /health, /status, /ping istekleri → Log'lara yazılmaz, SIEM gürültüsü azalır.
• ✅ SIEM ve log storage → Anlamlı olaylara odaklanır, maliyet düşer.
• ❌ Diğer endpoint istekleri → Normal şekilde loglanmaya devam eder.

Senaryo 2: Prometheus/Grafana Metrics İsteklerini Filtreleme

Problem: Prometheus her 15 saniyede bir /metrics endpoint'ine istek atıyor. Bu yüksek frekanslı monitoring trafiği log dosyalarını şişiriyor ve gerçek kullanıcı trafiğini görmek zorlaşıyor.

Çözüm: Belirli monitoring IP'lerinden gelen /metrics isteklerini log dışı bırakın.

Konfigürasyon:

• Execution Level: On Request
• Conditions:
  • Path = /metrics
  • AND Source IP IN monitoring_servers (IP listesi: 10.10.50.10, 10.10.50.11)

Sonuç:

• ✅ Monitoring sunucularından /metrics isteği → Log'lara yazılmaz.
• ✅ Log dosyaları → Gerçek kullanıcı trafiğine odaklanır, analiz kolaylaşır.
• ❌ Diğer IP'lerden /metrics isteği → Normal şekilde loglanır (güvenlik için).

Senaryo 3: Statik Dosya İsteklerini Log Dışı Bırakma

Problem: CSS, JavaScript ve image dosyalarına yapılan istekler log hacminin %60-70'ini oluşturuyor. Bu statik dosyalar güvenlik açısından kritik değil ve log analizi zorlaşıyor.

Çözüm: Statik dosya uzantılarına sahip istekler log dışı bırakılarak log hacmi belirgin biçimde azaltılır.

Konfigürasyon:

• Execution Level: On Request
• Conditions:
  • Path ENDS WITH .css
  • OR Path ENDS WITH .js
  • OR Path ENDS WITH .png
  • OR Path ENDS WITH .jpg

Sonuç:

• ✅ .css, .js, .png, .jpg istekleri → Log'lara yazılmaz.
• ✅ Log hacmi → %60-70 oranında azalır, storage maliyeti düşer.
• ❌ Dinamik sayfa istekleri → Normal şekilde loglanır, güvenlik görünürlüğü korunur.

Senaryo 4: SEO Bot ve Crawler Trafiğini Filtreleme

Problem: Google, Bing ve diğer arama motorlarının bot'ları /robots.txt ve /sitemap.xml dosyalarını sürekli talep ediyor. Bu meşru bot trafiği gereksiz log kaydı oluşturuyor.

Çözüm: SEO bot'larının discovery endpoint'lerine yaptığı istekleri log dışı bırakın.

Konfigürasyon:

• Execution Level: On Request
• Conditions:
  • Path = /robots.txt
  • OR Path = /sitemap.xml

Sonuç:

• ✅ /robots.txt ve /sitemap.xml istekleri → Log'lara yazılmaz.
• ✅ Log gürültüsü → Azalır, bot trafiği yerine gerçek kullanıcı davranışı izlenir.
• ❌ Diğer sayfa istekleri → Normal şekilde loglanır.