Cuma 17:45, Yeni VM Fark Edilmedi
Finans ekibi Çarşamba günü yeni bir SQL Server VM ayağa kaldırmış. Hostname: FIN-SQL03. IP: 192.168.20.58. Ancak IT ekibinizin envanter sistemine girilmemiş. Cuma 17:45'te bu sunucuda çalışan bir uygulama port 1433'e anormal yüksek sorgu yükü oluşturuyor. SIEM'iniz bu IP'yi tanımıyor — event gelmiyor, alarm kurulmuş değil, device kategorisi yok. İki gün boyunca görünmez kalmış bir varlık. Pazartesi sabahı yönetici soruyor: "Bu sunucu neden sistemde değildi?"
Orta ölçekli Türk firmalarında — özellikle 100-500 cihaz bandında — manuel envanter tutmak artık yetişmiyor. Her hafta yeni VM ayağa kalkıyor, yeni endpoint ekleniyor, yeni VLAN açılıyor. Excel listesi güncellenmemiş, CMDB haftalar geride. IT Manager veya Sysadmin bu boşluğu kapatmak için weekend'lerde nmap çıktıları topluyor, port scan sonuçlarını elle işliyor. ShamashAi Discovery modülü tam bu noktada devreye girer: 4 katmanlı mimari (Survey, Probe, Recognition, Adapter) ile ağınızdaki tüm cihazları otomatik keşfeder, kategorize eder ve dbo.devices tablosuna kaydeder.
Bu yazıda ShamashAi'nin Discovery motorunun nasıl çalıştığını, hangi katmandan hangi veri toplandığını ve AI fallback mekanizmasının ne zaman devreye girdiğini detaylı olarak inceleyeceğiz.
Katman 1: Survey — Wizard ve İlk Girdi
Discovery süreci L1 Survey katmanında başlar. Bu katman tamamen kullanıcı girdisi alır; hiçbir network çağrısı yapmaz. Web arayüzünde açılan wizard 12 adımdan oluşur:
1. Sites (Lokasyonlar): Merkez, Şube-1, Şube-2 gibi fiziksel veya mantıksal site tanımları. 2. Kategoriler: Server, Network, Endpoint, IoT, Cloud gibi cihaz kategorileri. 3. Anchor Cihazlar: Bilinen kritik cihazlar — domain controller, core switch, firewall. Bu cihazlar diğer katmanlarda referans noktası olarak kullanılır. 4. IP Aralıkları: Taranacak subnet'ler (CIDR formatında, örn. 192.168.10.0/24). 5. Tarama Penceresi: Hangi gün/saat aralığında tarama yapılacağı (off-peak saatler önerilir). 6. Kimlik Bilgileri: SNMP community string, Windows WinRM kullanıcı/parola, SSH key. 7. Hariç Tutulan IP'ler: Taranmaması gereken hassas sistemler (eski medikal cihaz, OT segment). 8. Agent Önceliği: Eğer bir cihaza agent kuruluysa, survey atla (agent zaten detaylı bilgi gönderir). 9. Proxy/NAT Bilgisi: Şube erişimi için gerekirse proxy IP. 10. VLAN Map: Hangi VLAN'ın hangi kategoriye ait olduğu (opsiyonel). 11. Notification: Discovery tamamlandığında kime mail gönderilecek. 12. Onay ve Zamanlama: Hemen başlat veya cron pattern ile tekrarla.
Wizard tamamlandığında L1 Survey verisi dbo.discovery_surveys tablosuna yazılır. Bu tablo, sonraki katmanlar için girdi deposu işlevi görür. L1'in amacı: insan bilgisini sisteme aktarmak. Sysadmin bildiği anchor cihazları işaretler, IT Manager kritik subnet'leri belirler. Wizard burada biter, artık otomatik katmanlar devreye girer.
Katman 2: Probe — Ağ Taraması ve Banner Bilgisi
L2 Probe katmanı, L1'de tanımlanan IP aralıklarını tarar. ShamashAi agent'ları (Windows, Linux, Docker) bu işi dağıtık olarak yapar — her site'da en az bir agent probe görevini üstlenir. Tarama süreci şu portlara odaklanır:
- 22 (SSH): Linux/Unix sunucular, network cihazları.
- 80/443 (HTTP/HTTPS): Web sunucuları, yönetim panelleri.
- 161 (SNMP): Switch, router, firewall, printer.
- 514 (Syslog): Log server, SIEM collector.
- 5985 (WinRM): Windows PowerShell remoting.
- 8080/8443 (Alt HTTP): Application server, Tomcat, Jenkins.
Server header okunur (örn. Server: nginx/1.18.0). SNMP açıksa sysDescr OID'i sorgulanır (örn. Cisco IOS Software, C2960 Software). SSH portunda banner string alınır (örn. SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5).
Probe sonuçları dbo.probe_results tablosuna yazılır:
sql SELECT ip_address, open_ports, http_banner, snmp_sysdescr, ssh_banner, probe_timestamp FROM dbo.probe_results WHERE survey_id = @survey_id AND open_ports IS NOT NULL;
Bu sorgu, hangi IP'de hangi portların açık olduğunu ve banner bilgilerini listeler. L2'nin çıktısı: ham ağ verisi. Henüz cihaz tipi veya vendor belli değil — sadece "192.168.10.50'de port 443 açık, banner 'nginx' içeriyor" bilgisi var.
Katman 3: Recognition — Önbellekten AI'ya Kademeli Tanıma
L3 Recognition katmanı, L2'den gelen ham veriyi yorumlar ve cihaz tipini belirler. Bu katman üç aşamalı kademeli çalışır:
3.1. Cache Lookup (Sıfır Network Call)
Önce dbo.recognition_cache tablosuna bakılır. Eğer aynı banner veya SNMP sysDescr daha önce görülmüşse, cache'den sonuç döner. Örneğin:
sql SELECT device_type, vendor, model FROM dbo.recognition_cache WHERE http_banner_hash = HASHBYTES('SHA2_256', @http_banner) OR snmp_sysdescr_hash = HASHBYTES('SHA2_256', @snmp_sysdescr);
Bu sorgu, banner'ın hash'ini alır ve daha önce bu hash için kaydedilmiş tanıma sonucu varsa döner. Cache hit oranı genellikle %60-70 civarındadır (tipik Türk şirketlerinde sık kullanılan Cisco, HPE, Fortinet cihazları cache'de mevcuttur). Cache hit olursa hiçbir external çağrı yapılmaz — milisaniyeler içinde sonuç döner.
3.2. Regex Pattern Matching
Cache miss olursa, regex pattern kütüphanesi devreye girer. ShamashAi'de 200+ regex pattern tanımlıdır. Örnekler:
Cisco IOS Software, C(\d{4}) Software→ vendor=Cisco, model=C2960FortiGate-(\d{2,4}\w?)→ vendor=Fortinet, model=FortiGate-60EServer: Microsoft-IIS/(\d+\.\d+)→ device_type=WebServer, vendor=MicrosoftHP ProCurve Switch (\d{4})→ vendor=HP, model=ProCurve2824
3.3. AI Fallback
Hem cache miss hem pattern match başarısız olursa, AI fallback devreye girer. ShamashAi burada POST /ai/investigate-event endpoint'ini çağırır ve banner verisini Claude API'ye gönderir:
javascript // Node.js Fastify route (backend) fastify.post('/ai/recognize-device', async (request, reply) => { const { http_banner, snmp_sysdescr, ssh_banner } = request.body;
const prompt = ` Banner bilgisi: HTTP: ${http_banner || 'yok'} SNMP: ${snmp_sysdescr || 'yok'} SSH: ${ssh_banner || 'yok'}
Bu cihazın vendor, device_type, model bilgisini JSON formatında döndür. Format: {"vendor": "...", "device_type": "...", "model": "..."} `;
const aiResponse = await anthropic.messages.create({ model: 'claude-3-5-sonnet-20241022', max_tokens: 300, messages: [{ role: 'user', content: prompt }] });
const parsed = JSON.parse(aiResponse.content[0].text); // Cache'e ekle await db.query(` INSERT INTO dbo.recognition_cache (http_banner_hash, vendor, device_type, model, source) VALUES (HASHBYTES('SHA2_256', @banner), @vendor, @device_type, @model, 'ai') `, { banner: http_banner, vendor: parsed.vendor, device_type: parsed.device_type, model: parsed.model });
return reply.send(parsed); });
AI fallback %10-15 oranında kullanılır. Claude, özellikle yeni veya nadir görülen vendor'lar (örn. Çinli IoT cihazları, yerli firewall'lar) için başarılı sonuç verir. AI'nin döndürdüğü sonuç da cache'lenir, böylece aynı cihaz bir dahaki taramada cache hit olur.
3.4. Manuel Sınıflandırma
AI bile tanıyamazsa (örneğin banner tamamen generic veya boş), cihaz dbo.devices tablosuna device_type = 'UNKNOWN' ile kaydedilir. Web arayüzünde "Tanınmayan Cihazlar" panelinde listelenir. Sysadmin burada manuel olarak vendor ve tip girer; kaydedildiğinde regex pattern kütüphanesine ekleme önerisi sunulur (opsiyonel).
Katman 4: Adapter — Vendor-Spesifik Eklentiler
L4 Adapter katmanı, L3'te tanınan cihazdan daha detaylı bilgi toplar. Bu katman vendor-specific plugin mimarisi kullanır. Her adapter, IDiscoveryAdapter interface'ini implement eder:
csharp // .NET 8 interface (agent tarafında) public interface IDiscoveryAdapter { string VendorName { get; } Task<DeviceDetail> CollectAsync(string ipAddress, Credential credential); bool CanHandle(string vendor, string deviceType); }
ShamashAi'de şu adapter'lar mevcuttur:
- fortinet: FortiGate firewall'lardan config backup, policy sayısı, firmware versiyonu toplar (REST API kullanır).
- windows-ad: Domain controller'dan kullanıcı sayısı, GPO listesi, replikasyon durumu toplar (PowerShell remoting kullanır).
- microsoft-graph: M365 tenant bilgisi, lisans sayısı, risky user'lar toplar (Graph API kullanır).
- cisco-ios: Switch/router'dan VLAN listesi, interface durumu, ARP tablosu toplar (SSH + screen scraping kullanır).
Vendor: Fortinet Device Type: Firewall IP: 192.168.1.1 Credential: admin kullanıcısı mevcut
Bu cihazdan hangi ek bilgi toplanabilir? Hangi API veya protokol kullanılmalı? JSON formatında öner.
AI, "REST API /api/v2/monitor/system/status endpoint'ini dene" gibi öneri döner. Bu öneri dbo.adapter_suggestions tablosuna kaydedilir; admin onaylarsa yeni adapter geliştirilir veya generic HTTP adapter kullanılır.
Adapter sonuçları dbo.device_details tablosuna yazılır:
sql SELECT d.hostname, d.ip_address, dd.firmware_version, dd.policy_count, dd.interface_status, dd.collected_at FROM dbo.devices d INNER JOIN dbo.device_details dd ON d.device_id = dd.device_id WHERE d.vendor = 'Fortinet' AND dd.collected_at > DATEADD(day, -1, GETUTCDATE());
Discovery Akışı: Uçtan Uca Örnek
250 cihazlı bir firma için tipik bir Discovery akışı:
1. Pazartesi 09:00: IT Manager wizard'ı açar, 3 subnet (192.168.10.0/24, 192.168.20.0/24, 10.0.1.0/24) tanımlar. Anchor cihaz olarak DC01 (192.168.10.5) ve FW01 (192.168.1.1) işaretler. Tarama Çarşamba 02:00'da başlatılır. 2. Çarşamba 02:00: L2 Probe başlar. Her subnet'te agent port scan yapar. Toplam 380 IP taranır (250 cihaz + bazı IP'ler çoklu interface). 3. Çarşamba 02:45: Probe tamamlanır. 250 cihazda açık port bulunur, 180'inde banner bilgisi toplanır. 4. Çarşamba 03:00: L3 Recognition başlar. 120 cihaz cache hit (Cisco, HP, Fortinet). 40 cihaz regex match (Microsoft IIS, Nginx). 15 cihaz AI fallback (yerli firewall, IP kamera). 5 cihaz UNKNOWN. 5. Çarşamba 03:30: L4 Adapter başlar. 8 FortiGate için fortinet adapter çalışır. 12 Windows Server için windows-ad adapter çalışır. 3 M365 tenant için microsoft-graph adapter çalışır. 6. Çarşamba 04:00: Discovery tamamlanır. IT Manager'a mail gider: "245 cihaz tanındı, 5 cihaz manuel sınıflandırma bekliyor."
SOAR Entegrasyonu: Discovery Sonrası Otomasyon
Discovery motoru, dbo.devices tablosuna yeni cihaz eklediğinde SOAR engine'e event gönderir:
javascript // Event payload { "event_type": "NEW_DEVICE_DISCOVERED", "device_id": "e9f7c8d2-4a1b-4c9e-8f2d-3b5e6a7c8d9e", "ip_address": "192.168.20.58", "vendor": "Microsoft", "device_type": "Server", "site": "Merkez", "discovered_at": "2026-10-19T03:15:20Z" }
SOAR playbook'ları bu event'e tepki verebilir:
- Compliance Check: Yeni sunucu ISO 27001 A.8.1 (varlık envanteri) için otomatik dbo.audit_log'a yazılır.
- Agent Kurulum: Eğer cihaz Windows/Linux ise, otomatik agent deployment başlatılır (POST /soar/deploy-agent).
- Firewall Rule: Yeni cihaz için otomatik firewall kuralı önerilir (örn. server segmentinde ise sadece port 443 dışarıya açık olmalı).
- Notification: IT Manager'a Slack veya mail ile bildirim gönderilir.
sql INSERT INTO dbo.soar_actions (action_type, target_device_id, payload, status) VALUES ( 'DEPLOY_AGENT', 'e9f7c8d2-4a1b-4c9e-8f2d-3b5e6a7c8d9e', '{"install_path": "C:\\\\Program Files\\\\ShamashAi", "site": "Merkez"}', 'PENDING' );
Compliance ve Kanıt: Discovery Logları
KVKK Madde 12 ve ISO 27001:2022 Annex A.8.1, varlık envanterinin güncel tutulmasını zorunlu kılar. ShamashAi Discovery, her tarama sonucunu dbo.audit_log tablosuna yazar:
sql SELECT action, details, performed_at, performed_by FROM dbo.audit_log WHERE action IN ('DISCOVERY_STARTED', 'DEVICE_ADDED', 'DEVICE_UPDATED') AND performed_at > DATEADD(month, -3, GETUTCDATE()) ORDER BY performed_at DESC;
Denetim sırasında GET /compliance/evidence endpoint'i çağrılarak Discovery timeline'ı PDF olarak alınabilir. Rapor şu bilgileri içerir:
- Hangi tarihte hangi subnet tarandı.
- Kaç cihaz eklendi, kaç cihaz güncellendi.
- Hangi cihazların agent'ı var, hangilerinin sadece probe ile keşfedildi.
- Manuel sınıflandırma bekleyen cihazlar ve bunların ne kadar süredir bekledikleri.
Performans: 500 Cihazlık Ağda Tarama Süresi
AfnTeknoloji'nin iç testlerinde (sanal lab ortamı, 500 cihaz simülasyonu):
- L1 Survey: Kullanıcı wizard'ı 5-10 dakikada doldurur (insan faktörü).
- L2 Probe: 500 IP, 8 port, 3 paralel agent → ortalama 15 dakika.
- L3 Recognition: Cache hit %65, regex %25, AI %10 → ortalama 8 dakika (AI çağrıları paralel yapılır).
- L4 Adapter: 50 cihaz için adapter çalışır → ortalama 12 dakika.
Next.js Arayüzü: Discovery Paneli
Web arayüzünde Discovery paneli, şu bileşenleri içerir:
javascript // Next.js component (frontend) import { useQuery } from '@tanstack/react-query';
export default function DiscoveryPanel() { const { data: surveys } = useQuery({ queryKey: ['discovery-surveys'], queryFn: () => fetch('/api/discovery/surveys').then(r => r.json()) });
const { data: unknownDevices } = useQuery({ queryKey: ['unknown-devices'], queryFn: () => fetch('/api/devices?type=UNKNOWN').then(r => r.json()) });
return ( <div className="grid grid-cols-2 gap-4"> <div> <h3>Tarama Geçmişi</h3> {surveys?.map(s => ( <div key={s.survey_id}> <span>{s.created_at}</span> <span>{s.discovered_count} cihaz</span> <span>{s.status}</span> </div> ))} </div> <div> <h3>Manuel Sınıflandırma Bekleyenler</h3> {unknownDevices?.map(d => ( <div key={d.device_id}> <span>{d.ip_address}</span> <button onClick={() => classifyDevice(d.device_id)}> Sınıflandır </button> </div> ))} </div> </div> ); }
Panel, gerçek zamanlı (WebSocket üzerinden) tarama ilerlemesini gösterir. IT Manager, tarama devam ederken kaç cihazın tarandığını, kaçının tanındığını canlı takip edebilir.
Limitler ve Dürüst Notlar
- OT/ICS Cihazlar: Endüstriyel kontrol sistemleri (PLC, SCADA) için adapter bulunmuyor. Bu cihazlar UNKNOWN olarak listelenecektir; manuel sınıflandırma veya özel geliştirme gerekir.
- Şifreli Trafik: HTTPS banner grab için SSL certificate parse yapılır, ancak mutual TLS veya client cert gerektiren sistemlerde banner okunamaz. Bu cihazlar sadece port durumu ile kaydedilir.
- Cloud SaaS: ShamashAi on-prem çalıştığından, AWS/Azure gibi public cloud'daki VM'leri doğrudan tarayamaz. Cloud provider API entegrasyonu (AWS Systems Manager, Azure Arc) ayrı lisans gerektirir ve dokümantasyon henüz tamamlanmamıştır.
- MAC Address Takibi: L2 Probe MAC adresi toplamaz (ARP tablosu her cihazdan sorgulanmaz). MAC bazlı tracking için switch/router adapter'ı gereklidir; şu anda sadece Cisco IOS adapter bu özelliği destekler.
- Tarama Frekansı: Continuous discovery (gerçek zamanlı, her 5 dakikada bir tarama) henüz mevcut değil. Minimum tarama aralığı 1 saattir. Daha sık tarama network yükü oluşturabilir; pilot kapsamında değerlendirilir.