Splunk'ı Claude'a Bağlamak

 

Yapay zekâ bir SIEM'in içine girdiğinde ne olur? Doğal dil ile indeks sorgulama, sourcetype keşfi ve canlı healthcheck, gerçek bir lab ortamından notlar. *

 

Giriş: "Terminal Yorgunluğu" ve Bir Fikir

 

SOC'de yeterince yıl geçirdikten sonra fark edersiniz: asıl yorgunluk alarm sayısından değil, bağlam değiştirme maliyetinden gelir. Splunk'ta bir sorgu açarsınız, sonucu analiz edersiniz, başka bir sekmeye geçersiniz, tekrar dönersiniz. Bu döngü saatlerce sürer.

Bir gün şunu düşündüm: Splunk'a doğal dil ile konuşabilsem ne olurdu? "Son 24 saatte 4625 eventlerini getir, system kullanıcılarını dışla" diyebilsem? Cevap, Model Context Protocol (MCP) ile geldi.

Bu makale o serüveni anlatıyor, kurulumdan, canlı ortamdaki gerçek bulgulara kadar.

 

MCP Nedir? Neden Önemli?

 

MCP (Model Context Protocol), büyük dil modellerini dış araçlara ve veri kaynaklarına bağlayan açık bir standarttır. Anthropic tarafından geliştirilmiştir.

Bunu şöyle düşünebilirsiniz: Claude bir danışman, MCP ise o danışmanın ofisinizdeki sistemlere erişim kartı. Danışmanınız artık sadece sizi dinlemiyor, kendi bilgisayarınızdaki veri tabanına da bakabiliyor.

SOC perspektifinden MCP'nin önemi şu: SIEM'iniz artık bir metin kutusuna dönüşüyor. SPL bilmeden soru sorabilirsiniz, ama SPL biliyorsanız çok daha hızlı hareket edebilirsiniz.

 

Ortam ve Kurulum

 

Test ortamım:

- 1 Search Head (Linux, Splunk 9.4.4)

- 3 Indexer — idx1, idx2, idx3 (cluster mode)

- 1 Heavy Forwarder — hf

- 1 Windows Client — ZZ-sanal (Universal Forwarder ile)

- 1 Ubuntu Client — UF kurulu

 

Adım 1: MCP Server Kurulumu

Splunkbase’den Splunk MCP Server uygulamasını indirip Splunk Enterprise’a yükleyin. Kurulumdan sonra Splunk’u yeniden başlatın. Bu entegrasyonda Splunk’un resmi MCP Server uygulaması (Splunkbase App #7931, v1.1.0 -- https://splunkbase.splunk.com/app/7931) kullanılmıştır.

 

Adım 2: Rol ve Yetkilendirme

Rol adı tam olarak mcp_user olmalıdır. Splunk MCP Server bu ismi spesifik olarak arar; farklı isimde bir rol, doğru capability’lere sahip olsa bile çalışmaz.

Gerekli capability’ler: mcp_tool_execute (sorgu çalıştırma), mcp_tool_admin (tool yönetimi ve token oluşturma için).

 

Adım 3: Encrypted Token Oluşturma

Token’lar sadece MCP Server App içinden oluşturulmalıdır. Splunk’un standart Settings → Tokens sayfasından veya REST API ile oluşturulan token’lar sessizce reddedilir, hata mesajı vermez, sadece çalışmaz.

MCP Server App’i açın, “Create Token” butonuna tıklayın. Audience alanı otomatik olarak “mcp” gelir, değiştirilemez. Oluşturulan encrypted token sadece bir kez gösterilir, hemen kopyalayın.

 

Adım 4: Tool’ları Aktifleştirme

Kurulumdan sonra bazı MCP endpoint’leri varsayılan olarak kapalı gelir. Bağlantı sağlıklı görünür, handshake tamamlanır, splunk_get_info bile veri döner ama diğer tool’lar (SPL çalıştırma, AI Assistant vb.) client tarafında sessizce görünmez. Hata mesajı, uyarı yoktur.

MCP Server App → Settings ekranından ihtiyacınız olan tüm tool’ları açıkça etkinleştirin.

 

Adım 5: Claude Desktop Konfigürasyonu

claude_desktop_config.json dosyasına aşağıdaki konfigürasyonu ekleyin:

{

  "mcpServers": {

    "splunk-mcp-server": {

      "command": "cmd",

      "args": [

        "/c", "npx", "-y", "mcp-remote",

        "https://<SPLUNK_HOST>:8089/services/mcp",

        "--header",

        "Authorization: Bearer <ENCRYPTED_TOKEN>"

      ],

      "env": {

        "NODE_TLS_REJECT_UNAUTHORIZED": "0"

      }

    }

  }

}

 

Windows’a özel önemli notlar:

Config dosyası konumu: Claude Desktop Microsoft Store’dan kuruluysa config dosyası standart %APPDATA%\Claude\ yolunda değildir. Store sandbox path’indedir: C:\Users\<kullanıcı>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\. En güvenilir yöntem, Claude Desktop içindeki Settings → Developer → Edit Config butonunu kullanmaktır.

npx path sorunu: Node.js, C:\Program Files\nodejs\ gibi boşluk içeren bir dizine kuruluysa "command": "npx" başarısız olur. Çözüm: "command": "cmd" ile args’ın başına "/c", "npx" eklemektir.

PowerShell Execution Policy: npx çalıştırabilmek için Execution Policy’nin RemoteSigned olması gerekir: Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Self-signed sertifika: Test/lab ortamında self-signed sertifika kullanılıyorsa NODE_TLS_REJECT_UNAUTHORIZED=0 env değişkeni gereklidir. Production’da mutlaka CA-signed sertifika kullanın.

 

Adım 6: Bağlantıyı Test Etme

Claude Desktop’u tamamen kapatıp yeniden açın (system tray’den sağ tık → Quit). Settings → Developer ekranında splunk-mcp-server bağlantısı görünmeli. Başarılı bağlantıda yeşil durum göstergesi, başarısızlıkta kırmızı “failed” etiketi görünür.

İlk test sorusu basit: “Bana tüm indeksleri sırala.”

 

İlk Gerçek Test: İndekslerin Keşfi

Bağlantı kurulduktan sonra Claude’a yönelttiğim ilk soru şuydu:

“Bana bütün indeksleri sırala.”

Claude, arka planda şu sorguyu çalıştırdı:

| rest /services/server/info splunk_server=*

Ve geri dönen sonuç:

Ortamda 4 Splunk sunucusu (1 search head + 3 indexer) ve 20 unique indeks var.

 

İndeks	Tür	Toplam Boyut	Olay Sayısı
_internal	dahili	~20 GB	177M+
_audit	dahili	—	510K
main	sistem	~50 MB	49.8M
indextest	test	—	587K
oswinsec	güvenlik	0 MB	0
crowdstrike	güvenlik	0 MB	0
winwef	güvenlik	0 MB	0

 

İlk bulgular hemen dikkat çekiciydi. Güvenlik indeksleri; oswinsec, crowdstrike, winwef sistemde tanımlı ama içleri boş. Veri akışı hiç başlamamış ya da kesilmiş demekti.

 

4625 Araştırması: Başarısız Girişimler

Bir SOC analistinin en sık sorduğu soru: “Başarısız oturum açma denemeleri var mı?”

Claude’a şunu söyledim:

“Bana 4625’leri system kullanıcılarını dışlayacak şekilde son 24 saatteki hareketi getir.”

Claude otomatik olarak şu SPL’i oluşturup çalıştırdı:

index=oswinsec EventCode=4625

NOT (TargetUserName IN ("SYSTEM", "LOCAL SERVICE",

     "NETWORK SERVICE", "ANONYMOUS LOGON", "-")

     OR TargetUserName="*$")

| timechart span=1h count AS failures

 

Sonuç: 0 kayıt.

Claude duraksayıp kendi kendine bir soruşturma başlattı. Sırasıyla şunları sorguladı:

-- Hangi indekste WinEventLog var?

index=* sourcetype=WinEventLog | stats count by index

 

-- Peki bu host son 30 günde ne gönderdi?

index=main sourcetype=WinEventLog | stats count by LogName

 

Ortaya çıkan tablo şaşırtıcıydı:

Log Adı	Olay Sayısı
Security	16.848
Application	1.074
System	402

 

Security log geliyordu ama 4625 hiç yoktu. Ve son veri tarihi: 20 Nisan 2026. Yani 7 günlük bir veri boşluğu vardı.

Claude’un teşhisi:

“İki olası neden: (1) Audit Policy’de ‘Logon Failures’ auditing kapalı, (2) UF servisi 20 Nisan’dan beri çalışmıyor.”

Bu, bir analistin manuel olarak yapacağı araştırmayı Claude’un otomatik olarak gerçekleştirmesiydi. Araç çağrısı, bulgu, hipotez doğrulama döngüsü, her şey doğal dil konuşması içinde.

 

Sourcetype Keşfi: Beklenmedik Bulgular

Bir sonraki adım daha ilginçti:

“Sourcetype’ları çıkart.”

Claude iki ayrı sorgu çalıştırdı hem genel indeksler hem de dahili (_*) indeksler için. Toplam 46 unique sourcetype döndü.

 

taopenctiaddon:log — 563K olay, ama yanlış indekste

OpenCTI add-on’u aktif ve veri üretiyor. Ancak veriler _internal indeksine düşüyor bu, konfigürasyon hatası. CTI telemetrisi main veya özel bir cti indeksine akmalı.

phantom_retry + phantom_configuration

Splunk SOAR (eski Phantom) entegrasyonu kurulu. phantom_retry’da 7.325 kayıt var — bu sayı başarısız playbook aksiyonlarını işaret edebilir. SOAR bağlantısının sağlığı sorgulanmalı.

linux_secure — 560K olay, ama indextest’te

560 bin Linux auth log’u bir test indeksinde yaşıyor. Bu kasıtlı mı, yoksa bir prod hatasının işareti mi?

skyhigh:dlp:audit

McAfee/Skyhigh DLP telemetrisi başlamış ama yalnızca 108 kayıt var. Yeni kurulum mu, yoksa veri akışı zayıf mı?

splunk:ta:o365:log

O365 TA kurulu ama log’ları _internal’e düşüyor. O365 verisi için indeks tanımı eksik.

 

Healthcheck: Ortamın Nabzı

En kapsamlı test buydu:

“Splunk’ta healthcheck yapar mısın?”

Claude sekiz farklı sorgu çalıştırarak ortamın tüm boyutlarını taradı.

Sunucu Durumu

Sunucu	Sürüm	Health	Roller
searchhead	9.4.4	🟢 green	search head, deploy server, kv_store
idx1	9.4.4	🟡 yellow	indexer, cluster peer
idx2	9.4.4	🟡 yellow	indexer, cluster peer
idx3	9.4.4	🟡 yellow	indexer, cluster peer
hf	—	görünür	heavy forwarder

 

Üç indexer’ın da yellow durumda olması kritik bir bulguydu.

Disk Kullanımı

Sunucu	Sıkıştırılmış	Ham Boyut
idx2	7.2 GB	20.5 GB
idx3	6.4 GB	19.3 GB
idx1	5.8 GB	19.3 GB

 

Sıkıştırma oranı ~2.7:1 normal aralıkta.

CPU Kullanımı (Son 1 Saat)

Tüm sunucularda CPU %3’ün altında. Yük açısından sorun yok.

 

Error Log Analizi (Son 24 Saat)

Kaynak	Sunucu	Sayı	Seviye
ExecProcessor	searchhead	72	ERROR
SSLCommon	searchhead	296	WARN
HttpListener	searchhead	317	WARN
DiskMon	idx3	49	WARN
CMSlave	idx2, idx3	4	ERROR

 

Kritik Bulgular

1. Indexer’lar yellow — cluster replikasyon sorunu muhtemel. CMSlave hataları idx2 ve idx3’te görünüyor. Bucket replikasyon faktörü veya peer durumu bozulmuş olabilir. Splunk Web’deki Settings → Indexer Clustering ekranından doğrulanması gerekiyor.

2. SSL uyarıları — 613 adet, tek günde. SSLCommon + HttpListener kombinasyonu yüksek sayıda uyarı üretmiş. Süresi yaklaşan/dolmuş sertifika, eski TLS versiyonu veya cipher mismatch olabilir.

3. idx3 DiskMon — diğerlerinden belirgin şekilde yüksek. idx3’te disk I/O veya doluluk uyarıları diğer indexer’lardan çok daha fazla. Disk kapasitesi kritik eşiğe yaklaşıyor olabilir.

 

Bu Entegrasyon Ne İşe Yarar?

Keşif hızı. Bir ortama yeni geldiğinizde indeks yapısını, sourcetype dağılımını ve genel sağlık durumunu dakikalar içinde öğrenebilirsiniz.

Hipotez üretme. Claude sadece sorgu sonucu döndürmüyor; bulguları yorumluyor ve sonraki adımı öneriyor. “4625 yok” derken aynı zamanda “audit policy’yi kontrol et” diyor.

SPL öğrenme eğrisi. Analistler için mükemmel bir öğretmen. “Bu sonucu nasıl aldın?” diye sorulabilir, Claude SPL’i açıklar.

Healthcheck otomasyonu. Sekiz farklı sorguyu art arda çalıştırıp sonuçları bütünleşik bir rapor olarak sunmak manuel yapılsaydı 30-45 dakika sürerdi.

Sınırlar

Gerçek zamanlı alarm değil. Claude’u bir detection engine olarak kullanmayın. Sorgular anında çalışır ama sürekli izleme için değil.

rest komutu kısıtlı. Bu entegrasyonda bazı Splunk REST API uç noktaları erişilebilir değildi. Cluster detayları için Splunk Web’e geçmek gerekti.

Hassas veri farkındalığı. Claude’a gönderdiğiniz her şey bir API çağrısına dönüşüyor. Kurumsal ortamlarda hangi verilerin paylaşıldığına dikkat edilmeli; özellikle kimlik bilgileri ve kişisel veri içeren log satırları.

 

Sonuç

Bu entegrasyon benim için bir araç değil, bir bakış açısı değişikliği oldu. SOC’de yıllardır “daha hızlı sorgu” peşinde koşuyorduk. Oysa asıl kazanım daha iyi soru sormak olabilir, hatta en iyi kazanım bu olur.

Claude, Splunk’u bir sorgu motoru olmaktan çıkarıp bir konuşma ortağına dönüştürüyor. “4625 var mı?” yerine “Bu ortamda kimlik doğrulama telemetrim neden eksik?” sorusunu soruyorsunuz ve cevap peşinden geliyor.

Kurulum Sorun Giderme Rehberi

Aşağıdaki tablo, kurulum sırasında karşılaşılan sorunları ve çözümlerini içerir:

Sorun	Neden	Çözüm
Claude Desktop’ta server görünmüyor	Config dosyası yanlış konumda (Store vs standart kurulum)	Edit Config butonu ile doğru dosyayı açın
"C:\Program is not recognized" hatası	Node.js yolu boşluk içeriyor	command: "cmd", args başına "/c", "npx" ekleyin
npx SecurityError / PSSecurityError	PowerShell Execution Policy kısıtlaması	Set-ExecutionPolicy -Scope CurrentUser RemoteSigned
Server disconnected / TLS hatası	Self-signed sertifika reddediliyor	env bloğuna NODE_TLS_REJECT_UNAUTHORIZED=0 ekleyin
Bağlantı var ama tool görünmüyor	Server-side tool’lar kapalı	MCP Server App → Settings’ten tool’ları aktifleştirin
Token çalışmıyor	Token, Settings → Tokens sayfasından oluşturulmuş	MCP Server App içinden yeni encrypted token oluşturun
Connection refused	Port 8089 kapalı veya firewall engeli	Test-NetConnection ile 8089 erişimini doğrulayın

 

Kâmil Akdağ, MSc *Bu makalede yer alan tüm veriler gerçek bir test lab ortamından alınmıştır.