Video Nadzor Hardening: Bezbednost IP kamera, NVR/DVR i VMS sistema

Video nadzor je čest, a redovno potcenjen deo infrastrukture kad je bezbednost u pitanju — kamere i NVR uređaji se tipično posmatraju kao fizička, ne informatička oprema, instaliraju ih integratori fizičke bezbednosti, ne IT tim, i nakon instalacije retko ikad dobiju istu pažnju kao serveri, mrežna oprema ili radne stanice. Ova percepcija je opasna zabluda: IP kamera i NVR su, tehnički, potpunopravni umreženi računari sa sopstvenim operativnim sistemom, sopstvenim mrežnim interfejsom, i, kao što ćemo videti kroz konkretne primere u ovom tekstu, dugom istorijom ozbiljnih, aktivno iskorišćavanih ranjivosti.

Zašto je ovo ozbiljniji rizik nego što izgleda

Najbolja, najsvežija ilustracija ozbiljnosti ovog rizika je Nexcorium — Mirai varijanta botnet-a koju je FortiGuard Labs analizirao u aprilu 2026. godine, koja kompromituje TBK nadzorne DVR uređaje kroz ranjivost command injection tipa (CVE-2024-3721). Preko 600.000 kamera i 50.000 rekordera pogođenog modela nalazi se instalirano širom sveta — u bankama, državnim zgradama, maloprodajnim lancima. Ono što ovaj primer čini posebno poučnim jeste kako kompromitacija izgleda iz perspektive žrtve: kompromitovani uređaji nastavljaju da snimaju video potpuno normalno, dok istovremeno, u pozadini, izvode DDoS napade, pokušavaju brute-force pristup drugim uređajima na mreži, i šire se dalje lateralno — sve dok vlasnik nema apsolutno nikakav vidljiv znak da se bilo šta neuobičajeno dešava.

Ovo nije izolovan slučaj — isti obrazac (zastareli, "white-label" IP kamere i DVR uređaji regrutovani u Mirai varijante kroz nezakrpljene command injection propuste) ponavlja se godinama unazad, počev od originalnog Mirai napada iz 2016. koji je iskoristio hardkodirane, fabrički ugrađene lozinke u firmveru — lozinke koje korisnik nije mogao promeniti čak i da je hteo, jer su bile ugrađene direktno u kod uređaja, ne u konfiguraciju koju administrator kontroliše. Veliki deo tržišta jeftinijih, "white-label" kamera i DVR uređaja i danas deli isti osnovni hardver i softver od malobrojnih proizvođača komponenti u pozadini (npr. kineska kompanija XiongMai Technologies), što znači da jedna ranjivost u toj osnovnoj platformi pogađa desetine različitih brendova koji je prodaju pod sopstvenim imenom.

Prva, osnovna higijena — lozinke i firmver

Isti princip osnovne higijene koji smo ponovili kroz gotovo svaku prethodnu seriju na ovom blogu ima ovde možda i najdirektniju, empirijski dokazanu primenu — istorija botnet napada na kamere je gotovo u potpunosti priča o dva propusta: podrazumevanim lozinkama koje niko nije promenio, i zastarelom firmveru koji sadrži javno poznate, nezakrpljene ranjivosti.

Šta treba uraditi

• Promeniti podrazumevanu lozinku na svakoj kameri i NVR/DVR uređaju odmah po instalaciji, bez izuzetka — ovo uključuje i sekundarne, često zaboravljene naloge (ONVIF korisnik, FTP nalog za prenos snimaka, RTSP autentifikaciju) koje instalater ponekad ostavi na fabričkim vrednostima čak i nakon što je promenio glavnu, administratorsku lozinku
• Proveriti unapred, pre kupovine ili instalacije, da li konkretan model uređaja ima poznate, javno dokumentovane hardkodirane (backdoor) kredencijale koje korisnik ne može ukloniti — istorija pokazuje da ovakvi propusti nisu retkost, posebno kod jeftinijih, manje poznatih brendova, i predstavljaju propust koji nijedna količina "dobre" konfiguracije ne može ispraviti
• Uspostaviti redovan raspored provere i primene firmver ažuriranja — razuman polazni cilj je primena unutar 30 dana od objavljivanja, po istom principu discipline ažuriranja detaljno obrađenom kroz Windows i Linux Server hardening serije na ovom blogu, ovde sa dodatnim, otežavajućim faktorom da mnogi proizvođači kamera imaju znatno lošiju disciplinu i učestalost objavljivanja zakrpa od standardnih IT proizvođača
• Za uređaje čiji proizvođač više ne objavljuje firmver ažuriranja (prekinuta podrška, ugašena kompanija), tretirati to kao signal za zamenu opreme, ne kao stanje koje se može trajno tolerisati — uređaj koji nikad neće dobiti zakrpu za buduće otkrivene ranjivosti postaje sve rizičniji što duže ostaje u upotrebi
• Pri odabiru nove opreme, razmotriti razliku u bezbednosnoj zrelosti proizvođača kao faktor odluke, ne samo cenu i rezoluciju — proizvođači sa formalizovanim, dokumentovanim bezbednosnim razvojnim ciklusom i potpisanim, kriptografski verifikovanim firmverom nude realnu, merljivu prednost u odnosu na jeftiniji, "white-label" hardver bez ikakvog bezbednosnog programa iza sebe

Mrežna segmentacija — kamere ne pripadaju istoj mreži kao radne stanice i serveri

Isti princip segmentacije koji se provlači kroz svaku seriju na ovom blogu ima ovde direktnu, konkretnu primenu: video nadzor treba da živi na sopstvenom, izolovanom VLAN segmentu, potpuno odvojenom od standardne poslovne mreže. Razlog je dvostruk — kamere i NVR uređaji imaju istorijski lošu bezbednosnu reputaciju (opisanu ranije u tekstu), pa kompromitovana kamera ne treba da ima mrežni put ka osetljivijim delovima infrastrukture; i obrnuto, kompromitovana radna stanica ili server ne treba da ima nesmetan pristup video sistemu, koji često sadrži i sopstvene osetljive podatke (snimke koji mogu biti pravno relevantni, mogu prikazivati poslovno osetljive prostore ili procese).

Šta treba uraditi

• Postaviti sve kamere i NVR/VMS opremu na dedikovan VLAN, odvojen od korisničke, serverske, i upravljačke mreže opisanih kroz prethodne serije na ovom blogu
• Primeniti default-deny politiku na granici tog VLAN-a — eksplicitno dozvoliti isključivo saobraćaj koji je stvarno potreban (NVR/VMS koji povlači video sa kamera na standardnim portovima — RTSP na 554, ONVIF na 80/8080, HTTPS na 443), sa svime ostalim podrazumevano odbijenim, po istom "permit specific, deny all" obrascu opisanom u Firewall Hardening seriji na ovom blogu
• Blokirati direktan internet pristup sa kamera VLAN-a u potpunosti — kamere ne treba da imaju sopstveni izlaz ka internetu; ako je udaljen pristup video sistemu stvarno potreban, obezbediti ga kroz VPN ka NVR/VMS serveru, po istom principu opisanom u VPN Hardening tekstu na ovom blogu, nikad kroz direktno izlaganje kamere ili NVR-a internetu
• Imati na umu da se web interfejs uređaja i sam video stream (RTSP) često nalaze na različitim portovima — firewall pravilo koje dozvoljava pristup web interfejsu (radi administracije) ne dozvoljava automatski i sam prenos video streama, i obrnuto; oba puta zahtevaju eksplicitno, odvojeno razmatranje pri pisanju pravila
• Za veće instalacije sa stotinama kamera, razmotriti dodatnu podelu unutar samog video VLAN-a (npr. po lokaciji ili zgradi) kako WS-Discovery multicast saobraćaj (mehanizam kojim ONVIF uređaji najavljuju sopstveno prisustvo na mreži) ne bi neselektivno preplavio ceo, veliki segment odjednom

Napomena o riziku: uvođenje segmentacije na postojećoj, već instaliranoj infrastrukturi kamera nosi rizik privremenog prekida video nadzora ako redosled izmena nije pažljivo isplaniran — testirati svaku kameru nakon migracije na novi VLAN (potvrditi da NVR i dalje vidi live stream, da snimanje nastavlja bez prekida) pre nego što se stara mrežna konfiguracija ukine, po istom principu opreza koji se provlači kroz svaku operativno osetljivu mrežnu promenu opisanu kroz ovaj blog.

ONVIF i RTSP — razumeti razliku pre pisanja pravila

Ovo zaslužuje kratko tehničko objašnjenje, jer je čest izvor zabune koji direktno utiče na to kako se firewall pravila pravilno pišu. ONVIF je standard za interoperabilnost — kontrolni sloj koji uređajima različitih proizvođača omogućava međusobno otkrivanje, konfiguraciju, i pretplatu na događaje (npr. alarm pri detekciji pokreta). RTSP (Real Time Streaming Protocol) je odvojen, medijski sloj — protokol koji stvarno prenosi sam video sadržaj od kamere ka NVR-u ili aplikaciji koja ga prikazuje. Većina modernih ONVIF kamera koristi oba protokola zajedno, ali svaki pokriva potpuno drugačiju funkciju, i firewall pravilo koje dozvoljava jedan ne dozvoljava automatski i drugi.

Šta treba uraditi

• Uključiti HTTPS za ONVIF kontrolni saobraćaj gde uređaj to podržava (ONVIF podrazumevano koristi HTTP digest autentifikaciju, sa HTTPS dostupnim kao opcioni prekidač koji često nije uključen po difoltu) — bez ovoga, kredencijali putuju mrežom u čitljivom obliku, izloženi presretanju od strane bilo koga sa pristupom istom lokalnom mrežnom segmentu
• Onemogućiti root/glavni administratorski nalog na samoj kameri nakon što je namenski ONVIF korisnik konfigurisan na NVR strani — ovo ograničava koji nalog se stvarno koristi za rutinsku komunikaciju, umesto oslanjanja na najprivilegovaniji mogući nalog za svaku operaciju
• Rotirati lozinku dediciranog ONVIF korisničkog naloga redovno (razuman polazni obrazac je na 90 dana), po istom principu discipline rotacije opisanom kroz ranije serije na ovom blogu za servisne naloge
• Testirati RTSP i ONVIF konekcije odvojeno nakon svake mrežne izmene — ako kamera "izgleda dostupna" (npr. ping prolazi ili web interfejs je vidljiv), a NVR ne prikazuje video stream, prva stvar koju treba proveriti je da li firewall pravilo pokriva i RTSP port (554), ne samo port web interfejsa

Snimljeni materijal — zaštita podataka koji sistem generiše, ne samo pristupa njemu

Isti princip zaštite podataka u mirovanju i u prenosu koji se provlači kroz svaku seriju o backup infrastrukturi i bazama podataka na ovom blogu primenjuje se i na video snimke, koji nose sopstvenu, specifičnu vrednost i osetljivost — mogu biti pravno relevantan dokaz, mogu sadržati snimke osetljivih poslovnih prostora ili procesa, i u nekim jurisdikcijama podležu specifičnim zahtevima za zaštitu privatnosti i period čuvanja.

Šta treba uraditi

• Ograničiti pristup NVR/VMS administraciji i arhivi snimaka po istom principu least privilege koji se provlači kroz celu ovu seriju blogova — ne svako u organizaciji treba pristup istorijskim snimcima, samo uzak, jasno definisan krug osoba sa stvarnom poslovnom potrebom
• Logovati svaki pristup arhiviranim snimcima (ko je gledao koji snimak, kada, i, gde je funkcionalnost dostupna, da li je izvezen/preuzet) — ovo je posebno bitno kad snimci mogu poslužiti kao dokaz u internoj istrazi ili pravnom postupku, gde je lanac čuvanja dokaza (chain of custody) direktno relevantan
• Enkriptovati snimke u mirovanju gde platforma to podržava, posebno za sisteme koji čuvaju snimke van fizički kontrolisane lokacije (cloud VMS platforme) — isti princip opisan kroz Backup Infrastructure seriju na ovom blogu, ovde primenjen na video arhivu
• Definisati jasnu, dokumentovanu politiku perioda čuvanja (retention) usklađenu sa stvarnim poslovnim i regulatornim potrebama, ne čuvati snimke neograničeno "za svaki slučaj" — ovo i smanjuje rizik izloženosti u slučaju kompromitacije sistema, i olakšava usklađenost sa regulativama o zaštiti privatnosti koje često propisuju maksimalan period čuvanja video zapisa
• Za pristup daljinskim tehničarima ili integratorima radi održavanja, koristiti kontrolisan, vremenski ograničen pristup (idealno kroz jednokratnu, izolovanu virtuelnu radnu stanicu ili kontrolisan VPN pristup sa jasnim tragom aktivnosti), ne deljene, trajno aktivne VPN kredencijale koje eksterni tehničar zadrži neograničeno nakon što je posao završen

Video nadzor zaslužuje istu pažnju kao i svaki drugi mrežno povezan sistem obrađen kroz ovaj blog — princip koji se ponavlja kroz svaku prethodnu seriju ostaje jednako tačan i ovde: osnovna higijena (lozinke, ažuriranje), segmentacija, i disciplinovan pristup podacima koje sistem generiše određuju razliku između pouzdanog alata za fizičku bezbednost i tihe, neprimećene tačke ulaska u ostatak infrastrukture — tačno onog scenarija koji je Nexcorium botnet, i mnogi slični pre njega, godinama iznova dokazivao kao stvaran, ne teoretski rizik.