IP Kamera Trafik Matrisi: Port, Protokol ve ACL Kuralı Tasarımı

Kamera trafiğini ayrı VLAN’a almak işin yarısıdır. Diğer yarısı, bu segmentle ağın geri kalanı arasında hangi trafiğe izin verileceğine karar vermektir. Sahada en sık gördüğümüz kural “kayıt sunucusuyla her şey serbest” satırıdır; bu satır segmentasyonu kâğıt üzerinde bırakır. Aşağıda kamera, NVR/VMS ve altyapı servisleri arasındaki gerçek akışları port ve protokol bazında bir matrise dökmeyi, bu matristen en az yetkili ACL türetmeyi, Cisco IOS örneğini ve kuralları sayaçlarla doğrulamayı anlatıyoruz.

Kamera sistemindeki trafik akışları

Kurumsal kamera sistemlerinde matrisi çıkarmadan önce akışların yönünü doğru okumak gerekir; kural, bağlantıyı kimin başlattığına göre yazılır. Yön yanlışsa kural da yanlıştır.

• Kayıt sunucusu → kamera: RTSP oturumu (DESCRIBE, SETUP, PLAY), ONVIF/HTTP(S) yapılandırma ve PTZ komutları. Bağlantıyı kayıt sunucusu başlatır.
• Kamera → kayıt sunucusu: RTP/UDP kullanılıyorsa medya paketleri, kameradan sunucunun SETUP sırasında bildirdiği istemci portlarına gider. Olay bildirimi push modundaysa kamera VMS’in olay portuna bağlantı başlatır.
• Yönetim istasyonu → kamera: web arayüzü veya üretici yönetim aracı.
• Kamera → altyapı: DHCP, NTP, varsa DNS, syslog, SMTP.
• İzleme sistemi → kamera: SNMP sorgusu, ICMP; kameradan izleme sunucusuna SNMP trap.
• İstemci → kayıt sunucusu: operatörler ve mobil istemciler kameraya değil VMS’e bağlanır. Kameraya doğrudan izleyici erişimi matriste yer almaz.

Son madde tasarımın omurgasıdır: kamera segmentine yalnız kayıt sunucusu, yönetim istasyonları ve izleme sistemi erişir. Segmentasyonun gerekçesini kamera VLAN’ı neden gerekli yazısında anlattık.

Port ve protokol matrisi: RTSP, ONVIF, HTTP(S), NTP

Tablo yaygın varsayılanları gösterir. Portlar kamera ve VMS üreticisine göre değişir; tabloyu kendi kurulumunuzda doğruladığınız değerlerle doldurun.

Kaynak → Hedef	Protokol / port	Amaç	Not
Kayıt sunucusu → kamera	TCP 554	RTSP oturumu	RTSP 1.0 varsayılan portu
Kamera → kayıt sunucusu	UDP, dinamik	RTP/RTCP medya	Port aralığı VMS ayarından gelir
Kayıt sunucusu → kamera	TCP 80 / 443	ONVIF, yapılandırma, PTZ	Mümkünse yalnız 443
Yönetim → kamera	TCP 443	Web arayüzü	Belirli istasyonlar
Kamera → NTP sunucusu	UDP 123	Zaman senkronu	Kayıt zaman damgası ve sertifika geçerliliği için kritik
Kamera → DHCP	UDP 67/68	Adres alma	Statik adreste gerekmez
İzleme → kamera	UDP 161, ICMP	SNMP sorgusu, erişilebilirlik	SNMPv3 tercih edilir
Kamera → syslog / izleme	UDP 514, UDP 162	Log ve SNMP trap	TLS üzerinden syslog için TCP 6514
Kamera ↔ kamera segmenti	UDP 3702 multicast	ONVIF WS-Discovery	Segment dışına taşınmaz

RTSP’nin akış davranışı RFC 2326 içinde tanımlıdır: SETUP isteğinde istemci client_port, kamera yanıtında server_port bildirir ve RTP ile RTCP ardışık iki UDP portu kullanır. Medya portu bu yüzden kuralda sabit bir değer olarak değil, VMS’in kullandığı istemci port aralığı olarak yazılır. Sahada “görüntü gelmiyor ama RTSP bağlantısı kurulu” arızasının tipik nedeni, 554’e izin verip UDP medya aralığını unutmaktır. RTSPS ve HTTPS’e geçişte değişen portlar için IP kamera ve NVR’da HTTPS ve sertifika yönetimi rehberine bakabilirsiniz. Canlı izleme multicast ile dağıtılıyorsa IGMP ve multicast grup adresleri de matrise girer; bu senaryoyu kamera ağında multicast ve IGMP snooping yazısında ele aldık.

Üreticiye özgü portlar nasıl tespit edilir

Birçok kamera ve NVR, standart portların yanında kendi istemci yazılımı veya SDK’sı için ek portlar açar; örneğin bazı üreticilerde TCP 8000 veya TCP 37777 varsayılan SDK portlarıdır. VMS’ler de kayıt sunucusu, yönetim sunucusu, mobil sunucu ve olay servisi için kendine özgü portlar kullanır. Tespit için üç kaynak birlikte kullanılır:

1. Üretici dokümanı: VMS ve kamera üreticisinin port listesi. Sürümle değişebildiği için kullandığınız sürüme ait dokümana bakın.
2. Laboratuvar taraması: test kamerasında tüm TCP portlarını tarayın ve her açık portun neye ait olduğunu belirleyin. Gereksiz portu kameradan kapatmak, kurala eklemekten iyidir.
3. Gerçek trafik: VMS’e kamera eklerken, canlı izleme, kayıttan oynatma, PTZ ve olay testleri sırasında paket kaydı alın. Doküman eksik kalabilir. Paket kaydı yalan söylemez.

# Laboratuvardaki test kamerasında tüm TCP portları
nmap -Pn -sT -p- 10.20.30.250

# Windows tabanlı kayıt sunucusunda kameralarla kurulu RTSP bağlantıları
Get-NetTCPConnection -RemotePort 554 -State Established |
  Select-Object LocalAddress, LocalPort, RemoteAddress

# Linux tabanlı kayıt sunucusunda aynı kontrol
ss -tn state established '( dport = :554 )'

ONVIF keşfi (WS-Discovery) 239.255.255.250 adresine UDP 3702 ile gönderilen multicast sorgulara dayanır ve normalde VLAN sınırını geçmez. Kayıt sunucusu farklı bir VLAN’daysa kameraları IP adresiyle ekleyin; keşif için segment sınırını açmayın. ONVIF servis ve profil yapısının ayrıntıları ONVIF spesifikasyonlarında yer alır.

Matristen ACL kuralı türetme

Matrisin her satırı bir kurala dönüşür; matriste olmayan hiçbir akışa izin verilmez. Türetirken şu ilkeleri izleyin:

• Kaynak ve hedefi daraltın: “kamera ağı → any” yerine “kamera ağı → kayıt sunucusu IP’leri”. Kayıt sunucusu kümesi için nesne grubu kullanın.
• Yönü doğru kurun: durumsuz ACL’de kameradan dönen TCP trafiği için established anahtar sözcüğü kullanılabilir. Bu yalnız ACK/RST bayraklarına bakar, gerçek oturum takibi yapmaz; bunu bilerek kullanın.
• Medya taşımasını sadeleştirin: VMS ve kamera destekliyorsa RTP’yi RTSP bağlantısı içinde TCP üzerinden taşımak (interleaved) UDP port aralıklarını kurallardan çıkarır. Bedeli, paket kaybında TCP yeniden iletiminin gecikme ve takılma yaratabilmesidir; yerel ağda genellikle kabul edilebilir.
• Segment içini unutmayın: SVI üzerindeki ACL aynı VLAN içindeki kameralar arası trafiği görmez. Kameraların birbirine erişimini kesmek için katman 2 yöntemi gerekir (Cisco’da switchport protected, private VLAN veya VLAN erişim listesi).
• İnternete çıkışı açıkça reddedin: listenin sonunda örtük ret olsa bile, firewall’da kamera ağından internete çıkışı ayrı ve loglanan bir kural olarak tanımlamak izlemeyi kolaylaştırır.

Örnek ACL yapılandırması

Örnek topoloji: kamera VLAN’ı 10.20.30.0/24 (Vlan30), kayıt sunucusu 10.20.40.10, NTP 10.20.40.5, syslog 10.20.40.6, izleme sunucusu 10.20.40.7, DHCP sunucusu 10.20.40.3, yönetim istasyonları 10.20.50.0/28. VMS’in RTP istemci port aralığı örnek olarak 50000–50999 alınmıştır. Adresler ve port aralıkları örnektir.

ip access-list extended KAMERA-GIRIS
 remark M01-M02 kamera -> kayit sunucusu: RTSP ve HTTPS yanitlari
 permit tcp 10.20.30.0 0.0.0.255 eq 554 host 10.20.40.10 established
 permit tcp 10.20.30.0 0.0.0.255 eq 443 host 10.20.40.10 established
 remark M03 kamera -> kayit sunucusu: RTP/RTCP
 permit udp 10.20.30.0 0.0.0.255 host 10.20.40.10 range 50000 50999
 remark M04 kamera -> yonetim: HTTPS yanitlari
 permit tcp 10.20.30.0 0.0.0.255 eq 443 10.20.50.0 0.0.0.15 established
 remark M05-M08 altyapi servisleri
 permit udp any eq bootpc any eq bootps
 permit udp 10.20.30.0 0.0.0.255 host 10.20.40.5 eq ntp
 permit udp 10.20.30.0 0.0.0.255 host 10.20.40.6 eq syslog
 permit udp 10.20.30.0 0.0.0.255 eq snmp host 10.20.40.7
 permit udp 10.20.30.0 0.0.0.255 host 10.20.40.7 eq snmptrap
 permit icmp 10.20.30.0 0.0.0.255 host 10.20.40.7 echo-reply
 deny   ip any any log
!
ip access-list extended KAMERA-CIKIS
 permit tcp host 10.20.40.10 10.20.30.0 0.0.0.255 eq 554
 permit tcp host 10.20.40.10 10.20.30.0 0.0.0.255 eq 443
 permit udp host 10.20.40.10 range 50000 50999 10.20.30.0 0.0.0.255
 permit tcp 10.20.50.0 0.0.0.15 10.20.30.0 0.0.0.255 eq 443
 permit udp host 10.20.40.5 eq ntp 10.20.30.0 0.0.0.255
 permit udp host 10.20.40.7 10.20.30.0 0.0.0.255 eq snmp
 permit icmp host 10.20.40.7 10.20.30.0 0.0.0.255 echo
 deny   ip any any log
!
interface Vlan30
 ip helper-address 10.20.40.3
 ip access-group KAMERA-GIRIS in
 ip access-group KAMERA-CIKIS out

Açıklamalardaki M01, M02… değerleri matris satır numaralarıdır; denetimde her kuralın hangi iş ihtiyacından geldiği izlenebilir. Bu örnekte HTTP (80) bilinçli olarak yoktur; VMS’iniz ONVIF için HTTP kullanıyorsa ya VMS’i HTTPS’e taşıyın ya da kuralı yalnız kayıt sunucusu için ekleyin. Olay bildirimi push modundaysa kameradan VMS olay portuna giden kural da eklenmelidir. DHCP yanıtları için çıkış listesinde kural yoktur: ip helper-address kullanıldığında sunucu yanıtı switch’in kendi adresine gelir ve kameraya giden paketi switch kendisi üretir; Cisco IOS’ta cihazın kendi ürettiği trafik çıkış ACL’ine tabi değildir. Durum takibi yapan bir firewall’da aynı mantık daha az kuralla yazılır: yalnız bağlantıyı başlatan yön tanımlanır, dönüş trafiği oturum tablosundan izlenir.

Kural doğrulama ve test

1. İşlev testi: her kamera grubu için canlı izleme, kayıt, kayıttan oynatma, PTZ, olay alarmı, saat senkronu ve izleme sisteminin erişimi tek tek kontrol edilir.
2. Sayaç kontrolü: show ip access-lists KAMERA-GIRIS ile her satırın isabet sayısına bakın. Hiç isabet almayan izin kuralı ya gereksizdir ya da yanlış yazılmıştır; ret satırındaki beklenmeyen isabetler eksik bir akışa veya istenmeyen bir davranışa işaret eder.
3. Negatif test: kullanıcı ağındaki bir test istemcisinden kameralara erişim denenir; sonuç “filtered” olmalıdır.
4. Log incelemesi: log anahtar sözcüğü eşleşen paketleri işlemciye yönlendirir ve loglama hız sınırlıdır. Devreye alma döneminde kullanın, sonrasında kalıcı izlemeyi akış verisi veya firewall logu ile yapın.

# Kullanıcı ağındaki test istemcisinden negatif test
nmap -Pn -p 80,443,554,8000,37777 10.20.30.12

Ret satırına düşen trafiği güvenlik olayı olarak izlemek için kamera ağında anomali izleme rehberindeki alarm kurallarını bu matrisle birlikte kullanabilirsiniz.

Değişiklik yönetimi ve dokümantasyon

• Tek doğruluk kaynağı: matris, sürüm kontrolünde tutulan bir tablo veya dosyadır. ACL ve firewall kuralları ondan türetilir; tersi değil.
• Her satırda sahip ve gerekçe: hangi sistem için, kim istedi, hangi tarihe kadar geçerli.
• Değişiklik tetikleyicileri: yeni VMS sürümü, yeni kamera modeli, kayıt sunucusu taşıma ve yeni entegrasyon (geçiş kontrolü, analitik sunucusu) matris güncellemesi gerektirir.
• Periyodik gözden geçirme: isabet almayan kurallar ve süresi dolan geçici izinler temizlenir. Genel kural temizliği yaklaşımı için firewall kural temizliği yazısı tamamlayıcıdır.

Kamera segmentleri için trafik matrisini çıkarma, ACL ve firewall kurallarını tasarlama ve devreye alma testlerini birlikte yürütmek için kamera VLAN ve ağ segmentasyonu ile kamera siber güvenlik sıkılaştırması hizmetlerimize bakabilirsiniz.

Sık sorulan sorular

IP kameralar için standart bir port listesi var mı?

Kısmen. RTSP için TCP 554, HTTP için 80, HTTPS için 443, NTP için UDP 123 ve ONVIF keşfi için UDP 3702 yaygın varsayılanlardır. RTP medya portları ise oturumda dinamik belirlenir; üreticiye özgü SDK portları ve VMS portları da değişir. Liste her kurulumda doğrulanmalıdır.

ONVIF keşfi neden başka VLAN’dan çalışmıyor?

ONVIF cihaz keşfi WS-Discovery ile UDP 3702 üzerinden 239.255.255.250 multicast adresine gönderilen sorgularla yapılır ve bu trafik normalde router’lardan geçmez. Kayıt sunucusu farklı VLAN’daysa kameraları IP adresiyle ekleyin; keşif için segment sınırını açmayın.

Kamera VLAN’ı içinde kameraların birbirleriyle konuşması engellenebilir mi?

Evet. SVI üzerindeki ACL aynı VLAN içindeki trafiği görmez. Kameralar arası trafiği kesmek için Cisco’da switchport protected, private VLAN veya VLAN erişim listesi gibi katman 2 yöntemleri kullanılır; tasarımdan sonra kayıt sunucusu ve ağ geçidine erişimin bozulmadığını test edin.

Durumsuz ACL mi yoksa firewall mı kullanılmalı?

Küçük ve tek yönlü akışlarda switch ACL’i yeterli olabilir. RTP/UDP medya, dinamik portlar ve olay bildirimleri devreye girdiğinde durum takibi yapan bir firewall veya RTSP’yi TCP üzerinden taşıyan bir yapı kural sayısını azaltır ve hata payını düşürür.