Kamera Ağında Anomali İzleme: Trafik Tabanı ve Olağan Dışı Davranış

Bir kullanıcı bilgisayarının ağ davranışı her gün değişir; bir IP kameranınki yıllarca neredeyse aynı kalır. Aynı kayıt sunucusuyla, aynı portlardan, yaklaşık aynı bit hızıyla konuşur. Bu öngörülebilirlik, kamera ağını anomali tespiti için en elverişli segmentlerden biri yapar. Kuralı yazmak kolay; zor olan doğru temel çizgidir. Aşağıda akış verisi, DHCP, DNS ve switch loglarıyla kamera trafiğinin temel çizgisini çıkarmayı, şüpheli davranış göstergelerini, örnek alarm kurallarını ve SIEM tarafında alarm yorgunluğunu nasıl önleyeceğinizi anlatıyoruz.

Kamera trafiği neden izlemeye elverişlidir

Tipik bir kurumsal kurulumda kameranın konuştuğu sistemler sınırlıdır:

• Kayıt sunucusu (NVR/VMS): RTSP oturumunu genellikle kayıt sunucusu başlatır (TCP 554). Medya ya aynı TCP bağlantısı içinde ya da RTP/UDP ile kameradan sunucuya akar.
• Altyapı servisleri: NTP, DHCP, bazen DNS, syslog ve SNMP.
• Yönetim: belirli yönetim istasyonlarından HTTPS ile erişim.
• Olay bildirimi: bazı kurulumlarda kameradan VMS’e veya SMTP sunucusuna olay iletimi.

Bu listenin dışındaki her bağlantı ya yanlış yapılandırmadır ya da incelenecek bir olaydır. Üçüncü bir ihtimal yok. Kullanıcı ağında “yeni hedef IP” her saniye görülür; kamera ağında aylarca görülmeyebilir. Bu yüzden basit kurallar bile düşük yanlış alarmla çalışır. İzin verilen akışları önceden tanımlamak için IP kamera trafik matrisi ve ACL tasarımı rehberindeki matrisi izleme tarafında da referans alın.

Temel çizgi (baseline) nasıl çıkarılır

1. Kapsamı belirleyin: kamera VLAN’larını, kayıt sunucularını ve yönetim istasyonlarını isim ve IP olarak listeleyin. Akış analiz aracında bunları ayrı varlık grupları olarak tanımlayın.
2. Veri toplayın: en az bir tam haftayı kapsayın. Gece/gündüz bit hızı farkı (gece görüntüsündeki gürültü VBR’de bit hızını yükseltebilir), hafta sonu ve bakım günleri verinin içinde görünmeli.
3. Akışları sınıflandırın: kaynak grubu, hedef grubu, protokol ve hedef port bazında gruplayın. Beklenen akışları “izinli” olarak işaretleyin.
4. Beklenmeyenleri ayıklayın: genel DNS sunucularına sorgu, internete NTP, üretici bulut alan adları gibi akışlar çoğunlukla varsayılan ayarlardan gelir. Sahada ilk haftanın en sık bulgusu budur. Gereksizse kapatın, gerekiyorsa açıkça belgeleyin.
5. Kamera başına profil çıkarın: ortalama ve tepe bit hızı, oturum sayısı, bağlanan istemci sayısı. Bit hızı hesabının mantığı için kamera ağı bant genişliği hesabı rehberine bakabilirsiniz.

Temel çizgi kalıcı değildir. Yeni kamera eklendiğinde, firmware güncellemesinden sonra veya VMS sunucusu taşındığında gözden geçirilmelidir. Gözden geçirilmeyen temel çizginin sonu bellidir: ilk büyük değişiklikte ya kurallar susturulur ya da alarm yağmuru başlar.

Veri kaynakları: NetFlow, sFlow, DHCP, DNS, switch logları

Kaynak	Ne gösterir	Kamera ağında kullanım
NetFlow v9 / IPFIX	Akış bazında kaynak, hedef, port, bayt	Yeni hedef, yeni port, hacim değişimi
sFlow	Örneklenmiş paket başlıkları ve sayaçlar	Yüksek hacimli eğilimler; kısa ve küçük akışları kaçırabilir
Firewall logları	İzin ve ret kararları	Segment dışına çıkış denemeleri
DHCP logları	Yeni MAC, yeni kiralama	Kamera VLAN’ına giren bilinmeyen cihaz
DNS logları	Sorgulanan alan adları	Bulut servisi veya komuta-kontrol alan adı
Switch syslog	Link durumu, MAC hareketi, port güvenliği, 802.1X	Kablo sökme, cihaz değişimi, MAC kopyalama

Akış verisini mümkünse kamera VLAN’ının ağ geçidi olan L3 arayüzden veya segment firewall’undan alın; erişim switch’lerinde Flexible NetFlow desteği model ve lisansa bağlıdır. Akış protokollerinin farkları için ağ sitemizdeki NetFlow, sFlow ve IPFIX karşılaştırması yazısına bakabilirsiniz. Cisco IOS XE üzerinde kamera VLAN arayüzü için temel bir Flexible NetFlow yapılandırması (adresler örnektir):

flow record KAMERA-KAYIT
 match ipv4 source address
 match ipv4 destination address
 match ipv4 protocol
 match transport source-port
 match transport destination-port
 collect counter bytes long
 collect counter packets long
!
flow exporter KAMERA-EXP
 destination 10.10.5.20
 source Vlan30
 transport udp 2055
!
flow monitor KAMERA-MON
 record KAMERA-KAYIT
 exporter KAMERA-EXP
!
interface Vlan30
 ip flow monitor KAMERA-MON input

Toplayıcı tarafında NetFlow v9 ve IPFIX (RFC 7011) şablon tabanlıdır; toplayıcı, dışa aktarıcının şablonunu almadan kayıtları çözemez. Yeni bir dışa aktarıcı eklendiğinde ilk dakikalarda veri görünmemesinin nedeni genellikle budur. Arıza değil, bekleme süresi. Veri hiç gelmiyorsa konsolda ilk bakılacak yer exporter’ın kaynak arayüzü ile toplayıcı arasındaki UDP 2055 yoludur; araya giren bir ACL veya firewall kuralı bu trafiği sessizce düşürebilir.

Şüpheli davranış göstergeleri

Gösterge	Olası anlam	Önem
Kameradan internete bağlantı denemesi	Açık P2P/bulut ayarı veya komuta-kontrol bağlantısı	Yüksek
Kameradan kamera VLAN’ı içinde çok sayıda IP’ye bağlantı	Tarama, solucan benzeri yayılma	Kritik
Kameradan TCP 23/2323 veya 22’ye giden bağlantılar	IoT botnetlerinin bilinen yayılma davranışı	Kritik
Kayıt sunucusu dışında bir hosttan RTSP veya web erişimi	Yetkisiz izleme veya keşif	Yüksek
Bir kameranın bit hızında belirgin ve kalıcı değişim	Ayar değişikliği, ek akış, veri sızdırma	Orta
Yeni MAC adresi veya kameranın MAC’inin başka portta görünmesi	Cihaz değişimi veya MAC kopyalama	Yüksek
Kameradan beklenmeyen DNS sorguları	Bulut servisi, güncelleme kontrolü veya kötü amaçlı alan adı	Orta
Mesai dışı yönetim arayüzü girişleri ve başarısız oturum açma dizileri	Parola deneme, yetkisiz yönetim	Yüksek

Tablodaki göstergelerin hiçbiri tek başına kesin kanıt değildir; ama kamera ağında her biri incelemeyi hak eder. Özellikle kameradan kamera VLAN’ı içinde çok sayıda IP’ye bağlantı ile Telnet portlarına giden trafik birlikte görülüyorsa beklemeyin.

Örnek alarm kuralları

Aşağıdaki kurallar ürün bağımsız mantık olarak yazılmıştır; kendi SIEM veya akış analiz aracınızın sorgu diline çevirin. KAMERA_NET, KAYIT_SUNUCULARI ve YONETIM ifadeleri tanımlı varlık gruplarını temsil eder.

KURAL-1  Internete cikis
  kaynak IN KAMERA_NET  VE  hedef NOT IN RFC1918
  VE hedef NOT IN (224.0.0.0/4, 255.255.255.255, 169.254.0.0/16)
  -> her olayda alarm (firewall ret logu dahil)

KURAL-2  Yatay tarama
  kaynak IN KAMERA_NET  VE  hedef IN KAMERA_NET
  VE 5 dakikada farkli hedef IP sayisi > 10
  -> kritik alarm

KURAL-3  Yetkisiz izleyici
  hedef IN KAMERA_NET  VE  hedef_port IN (554, 80, 443)
  VE kaynak NOT IN (KAYIT_SUNUCULARI, YONETIM)
  -> yuksek alarm

KURAL-4  Bilinmeyen cihaz
  DHCP kiralama VLAN = kamera  VE  MAC NOT IN kamera_envanteri
  -> yuksek alarm

KURAL-5  Bit hizi sapmasi
  kamera bazinda 1 saatlik ortalama bit hizi
  > temel cizginin 2 kati  VEYA  < temel cizginin yarisi (30 dk surerse)
  -> orta alarm, kamera saglik alarmlariyla iliskilendir

KURAL-1’deki multicast, yayın ve link-local istisnası, WS-Discovery, SSDP ve DHCP gibi yerel trafiğin yanlış alarm üretmesini önler. Eşik değerleri örnektir; temel çizginizdeki gerçek dağılıma göre ayarlayın. KURAL-5’in alt eşiği aynı zamanda bir arıza belirtisidir: lens kapatılması, kameranın donması, kodlayıcının takılması. Bu tür erişilebilirlik ve görüntü kaybı alarmları için kamera sağlık izleme: SNMP, ONVIF olayları ve görüntü kaybı alarmı rehberini kullanın. İki izleme hattını aynı olay kaydında ilişkilendirmek gereksiz çift alarmı önler.

SIEM entegrasyonu ve alarm yorgunluğu

• Varlık bağlamı: SIEM’e kamera envanterini (IP, MAC, model, konum, sahip) aktarın. Konum yazmayan alarm, sahadaki ekibe önce “hangi kamera?” sorusunu sordurur; müdahale süresi orada kaybedilir.
• Bakım pencereleri: firmware güncellemesi ve toplu yapılandırma işleri, değişiklik kaydı üzerinden bastırma penceresi olarak tanımlanır. Ancak bastırma “internete çıkış” gibi en ağır kuralları asla kapsamamalıdır.
• Toplama ve gruplama: aynı kameradan tekrar eden olaylar tek alarm altında toplanır. Aynı anda çok sayıda kamerada görülen davranış ise ayrıca yükseltilir; ya toplu bir yapılandırma hatasıdır ya da yayılan bir saldırı.
• Sahiplik: alarm kime gidiyor? Kamera sistemi yükleniciye, ağ BT’ye aitse yönlendirme kuralları önceden yazılmalı. Sahipsiz alarm kapanmaz.
• Saklama: akış ve log verisinin saklama süresi olay incelemesi ihtiyacına göre belirlenir; kayıtlarda kişisel veri bulunabileceği için kurum politikasına uygun olmalıdır.

Olay şüphesinde ilk adımlar

1. Doğrulayın: alarmı üreten akışı, ilgili kameranın envanter kaydını ve son değişiklik kayıtlarını yan yana koyun. Planlı bir işlemle açıklanıyorsa kapatın ve kuralı gözden geçirin.
2. İzole edin, kapatmayın: kamerayı fişten çekmek yerine switch portunu karantina VLAN’ına alın veya erişimini ACL ile kesin. Cihaz açık kaldıkça kurduğu bağlantılar gözlenebilir ve üretici destekliyorsa sistem logu veya tanı paketi alınabilir. Yeniden başlatma bu geçici izleri siler.
3. Trafiği kaydedin: switch’te SPAN/port aynalama ile kameranın trafiğini bir analiz istasyonuna yönlendirip kısa süreli paket kaydı alın.
4. Kapsamı belirleyin: aynı modelde veya aynı firmware’de olan diğer kameralarda aynı göstergeyi arayın; kayıt sunucusu ve yönetim istasyonu loglarını kontrol edin. Tek kamera nadiren tek kalır.
5. Temizleyin ve sıkılaştırın: üreticinin önerdiği yöntemle firmware’i yeniden yükleyin, tüm kimlik bilgilerini ve sertifikaları yenileyin, açılmış servisleri kapatın; kamerayı ancak izleme altında üretime alın.

Kamera ağında akış izleme, alarm kuralları ve SIEM entegrasyonunu mevcut izleme altyapınıza eklemek için kamera ağ izleme ve arıza alarmı hizmetimize; segmentasyon ve servis sıkılaştırması tarafı için kamera siber güvenlik sıkılaştırması sayfasına bakabilirsiniz.

Sık sorulan sorular

Kamera ağında anomali izleme için ayrı bir NDR ürünü şart mı?

Şart değil. Kamera trafiği çok öngörülebilir olduğu için switch veya firewall’dan alınan NetFlow/sFlow verisi, DHCP ve DNS logları ve SIEM’de yazılmış basit kurallar önemli göstergelerin çoğunu yakalar. NDR ürünleri ölçek ve otomatik profil çıkarma avantajı sağlar.

Temel çizgi ne kadar sürede oluşturulmalı?

En az bir tam haftalık iş döngüsünü kapsamalı; gece ve gündüz farkı, hafta sonu ve planlı bakım dönemleri görülene kadar veri toplanmalıdır. Sonrasında temel çizgi her değişiklik ve firmware güncellemesinden sonra gözden geçirilir.

Kameranın internete çıkmaya çalışması her zaman saldırı mıdır?

Hayır. Açık bırakılmış P2P bulut, firmware güncelleme kontrolü veya genel NTP sunucusu ayarı da bu davranışı üretir. Ancak kurumda bu trafiğe ihtiyaç yoksa ayar kapatılmalı ve kalan her deneme incelenmelidir.

Şüpheli bir kamerayı hemen kapatmak doğru mu?

Genellikle önce izole etmek daha doğrudur. Kamerayı kapatmak cihazdaki geçici izleri siler; portu karantina VLAN’ına almak veya erişimi ACL ile kesmek yayılmayı durdururken trafik kaydı ve inceleme imkânı bırakır.