Tunas Akara
Kembali ke Blog

Checklist Hardening Firmware CCTV: Sebelum Kamera Live

oleh RayhanDiperbarui 6 menit baca
cctviot-securityfirmwarehardening
Checklist Hardening Firmware CCTV: Sebelum Kamera Live

Checklist Hardening Firmware CCTV: Sebelum Kamera Live

Di setiap instalasi yang saya audit, CCTV selalu jadi perangkat yang paling gampang dibobol. Penyebabnya sama di semua merek: firmware-nya dari pabrik memang dibiarkan terbuka. Hari commissioning — hari kamera baru disetel lalu diserahterimakan sebelum resmi dipakai — pun diperlakukan sebagai urusan gambar, bukan urusan keamanan. Installer memastikan gambar tampil jernih, lalu pindah ke titik berikutnya.

Menutup celah keamanan bawaan pabrik itu satu per satu, dengan sengaja — itulah arti hardening. Semua poin di bawah wajib beres sebelum kamera dinyatakan selesai. Tidak ada satu pun yang boleh ditunda.

Kredensial tidak cuma ada di login web

Ganti password admin di dashboard web — itu langkah yang semua orang ingat. Tapi itu baru satu pintu. Chipset di balik board DVR/NVR murah — Hisilicon, Anyka, dan sekelasnya — membawa akun lain yang tidak ikut berubah saat password dashboard diganti. Ada akun debug lewat Telnet atau SSH. Ada kredensial ONVIF yang terpisah. Ada juga URL stream RTSP yang bisa membawa username-password sendiri, lepas dari layar login.

Audit kredensial yang benar itu port scan ke perangkat, bukan mencoba-coba layar login. Di instalasi yang saya audit, temuan paling umum di hardening pass pertama selalu sama: port 23 Telnet dan 554 RTSP masih terbuka dengan setelan pabrik.

Versi firmware itu urusan satu fleet, bukan satu kamera

Cocokkan build firmware yang terpasang dengan halaman advisory vendor sebelum commissioning — jangan tunggu ada insiden. Patch TP-Link untuk CVE-2026-0629 menunjukkan persis apa yang ditangkap pemeriksaan ini: bypass autentikasi di alur password-recovery kamera VIGI C dan VIGI InSight. Siapa pun di LAN bisa me-reset password admin — tanpa verifikasi, tanpa kredensial apa pun.

Kamera murah dari puluhan merek sering cuma beda stiker; chipset dan SDK di dalamnya sama. Satu CVE di firmware chipset itu diam-diam berlaku untuk semuanya, apa pun tulisan di kardusnya. Karena itu, simpan inventaris model dan versi firmware per lokasi. Begitu advisory keluar, pertanyaan "kamera mana saja yang kena" harus terjawab dalam hitungan menit — bukan lewat pendataan ulang tiap lokasi.

Matikan tunnel cloud P2P

Bayangkan pintu belakang gudang yang sengaja tidak dikunci supaya kurir bisa masuk tanpa pencet bel. Tunnel P2P vendor persis seperti itu. Layanan cloud peer-to-peer ini — stack P2P berbasis UID di balik banyak aplikasi DVR white-label — menembus NAT untuk menghubungi server relay vendor. Seluruh aturan firewall di lokasi terlewati begitu saja.

Dan justru fitur ini yang paling sering dibiarkan menyala oleh installer. Fungsinya memang ada: pemilik rumah bisa memantau kamera dari HP tanpa repot port forwarding. Untuk kasus itu berguna. Untuk semua kasus lain, ia jalur langsung dari internet ke perangkat yang seharusnya tidak bisa disentuh dari luar.

Matikan lewat pengaturan firmware, jangan cuma dengan tidak memasang aplikasi vendornya. Koneksi keluarnya dibuka oleh tunnel itu sendiri.

Kunci subnet kamera dengan aturan default-deny

Loading diagram…

Kamera dapat VLAN sendiri, dengan dua aturan. Pertama, hanya host NVR atau VMS yang boleh membuka koneksi ke subnet itu. Kedua, tidak ada apa pun di subnet itu yang boleh membuka koneksi keluar ke internet.

Dua aturan itu menutup banyak lubang sekaligus. Tunnel P2P mati. Firmware yang mencoba menghubungi server update tak terverifikasi ikut terblokir. Kamera yang telanjur dibobol pun terkurung di segmennya — hanya bisa dijangkau dari host perekam, tidak pernah bisa menjangkau keluar.

Host NVR atau VMS-nya sendiri juga layak dikunci terpisah. Itu saya bahas di mengintegrasikan access control dan VMS dengan sistem sendiri.

Autentikasi tiap stream RTSP, lalu uji sendiri

Software VMS sering rewel dengan URL RTSP yang membawa kredensial. Installer yang dikejar waktu lalu mematikan autentikasi stream supaya gambarnya jalan dulu, dengan niat dibereskan belakangan.

Selama autentikasi mati, siapa pun di segmen jaringan yang sama bisa menonton stream itu diam-diam pakai RTSP client generik. Tanpa exploit. Cukup tahu URL-nya.

Ujinya langsung: arahkan player mentah ke URL stream-nya. VMS yang berhasil konek tidak membuktikan apa-apa — client kedua yang datang tanpa kredensial bisa saja ikut diterima.

Kirim log keluar dari perangkat

Web UI kamera bukan tempat tujuan log. Reset firmware, percobaan login gagal, dan perubahan konfigurasi harus mendarat di syslog atau SNMP trap collector di luar perangkat. Disiplin alur alert-nya sama dengan yang dipakai deployment kamera deteksi APD untuk memilah kejadian sungguhan dari noise.

Kamera yang di-factory-reset penyerang untuk menghapus konfigurasinya terlihat persis seperti kamera yang kehilangan listrik. Keduanya baru bisa dibedakan kalau ada pencatat di luar perangkat yang sempat merekam kejadiannya.

Intinya

Semua poin di atas gagal dengan cara yang sama kalau dilewati: senyap, sampai kameranya dipakai untuk hal lain di luar urusan video. Kredensial default, tunnel cloud yang menyala, dan RTSP tanpa autentikasi bukan kasus langka. Itu kondisi bawaan pabrik sebagian besar hardware CCTV.

Hardening artinya mematikan semuanya satu per satu, dengan sengaja, sebelum kamera boleh disebut selesai di-commissioning.

Artikel Terkait

Mau bangun hal serupa?

Jasa Pengembangan Backend IoT & Integrasi Multi-Protokol

Backend yang menyerap telemetri perangkat lintas MQTT, WebSocket, Modbus, dan BLE, lalu menyatukannya jadi dashboard real-time yang andal.

Lihat cara saya bisa bantu