Cameradar

Last reviewed Sep 13, 2026 · 892 words

Run Cameradar against your camera VLAN before you wire a single feed into an NVR, because there is a real chance it prints a working rtsp://admin:admin@ URL for at least one device you thought was locked down. It is a single Go binary, 128 MB of RAM is generous, and one Docker command scans a /24 in a few minutes. It is not surveillance software. It is the audit you do once when you set up the video surveillance stack and again every time a new camera arrives.

What one scan actually does

Cameradar has three stages. It discovers hosts with RTSP ports open (554 and 8554 by default, configurable) using nmap under the hood. It then tries a dictionary of stream paths against each one, because every vendor hides the stream behind a different route (/live, /h264, /Streaming/Channels/101, /cam/realmonitor?channel=1&subtype=0 and dozens more). Finally it tries a dictionary of username and password pairs, the tired defaults that ship on cheap hardware and never get changed. The output is a table per camera: address, port, the route it found, whether the credentials worked, and the full URL if they did.

docker run -t ullaakut/cameradar -t 192.168.20.0/24

Add -p 554,8554,8000 to widen the port list, -s 3 to slow the nmap timing on a network that drops packets, and -c creds.json or -r routes.json to supply your own dictionaries. The bundled dictionaries are JSON files and you will want to extend them with your vendor's known route once you learn it.

Read the output as a to-do list, not a report

A row that says the route was found but authentication failed is good news: the camera is answering RTSP but not with a password Cameradar knows. A row with a full URL means that camera is watchable by anyone on that network segment with the same list, which includes every piece of malware that ever scanned for IoT devices. Fix order, from what I have seen work:

Change the credentials on the camera itself, not just in your NVR config. Many budget cameras keep a separate RTSP password from the web-admin password, and the RTSP one is the default. Then re-run the scan; if it still finds the stream, the device has a hard-coded account and it does not belong on a network with anything else on it. Then move on to the network: cameras should live on a VLAN with no route to the internet and no route to your workstation, with the NVR being the only thing allowed to talk to them. Cameradar cannot fix that for you but it will tell you which devices to prioritise.

It is a brute-force tool, so treat it like one

Two operational cautions. First, some cameras lock the RTSP service or reboot after a burst of failed logins, so scan during the day when a 2-minute outage does not matter, and expect a Hikvision or Dahua with lockout enabled to go dark briefly. Second, only scan networks you own or administer. Cameradar is small and polite, but a port scan plus credential guessing against someone else's equipment is unauthorised access in most jurisdictions, and the Docker image does not make it less so.

Cameradar also only speaks RTSP. It does not probe ONVIF, HTTP admin panels, or the proprietary cloud protocols that many consumer cameras use for their phone apps. A clean Cameradar run means your RTSP surface is clean; it says nothing about the web UI still running firmware from 2019.

Where it sits next to Frigate and go2rtc

Once the feeds are secured, the route and credential Cameradar found are exactly the strings you paste into go2rtc or into a Frigate config. That is the practical payoff: no more guessing which of 8 candidate stream paths a camera uses. Frigate is the bigger project and the one I would build the actual recording and detection on; Cameradar is a 10-minute pre-flight check that lives in your notes, not a service you keep running. There is no daemon mode and no dashboard, which the catalogue rightly flags as command-line oriented, and I consider that a feature. An auditing tool that stays resident is one more thing to secure.

Keep it in the toolkit for the annual re-check

Camera firmware updates occasionally reset RTSP credentials or expose a new stream route. Cheap replacement cameras arrive with defaults again. A calendar reminder to run one scan every 6 months, and once after any new device, costs about the time it takes to make a coffee and catches the class of mistake that ends up on Shodan.

What I'd do

Run Cameradar from a laptop plugged into the camera VLAN the day the cameras go in, fix every device that returns a full URL, and put the routes it discovered straight into go2rtc or Frigate. Then firewall the VLAN so only the NVR can reach it, and re-scan twice a year. I would not spend money on a commercial camera-audit product for a home or small-office deployment; for a 5,175-star free tool that does the one check that matters, Cameradar is enough.