keshavdv / unifi-cam-proxy

Enable non-Ubiquiti cameras to work with Unifi NVR
MIT License
1.72k stars 236 forks source link

Security Question #82

Closed m4tt075 closed 3 years ago

m4tt075 commented 3 years ago

I just stumbled over this project and am highly interested in it. I just have one security question: My understanding is that the Protect cameras are isolated into their own VLAN when they are adopted into the Protect system to separate their network from the rest, i.e. the management VLAN. Is it possible to isolate the proxy and the cams on their own VLAN here, too? Has any of you tried and achieved that? Any insights appreciated...

keshavdv commented 3 years ago

AFAIK, nothing in Unifi Protect will do that automatically for you. As an example, the UNVR isn't even a routing device and would have no ability to "configure" the rest of the network. The proxy itself is network agnostic. As long as the proxy can talk to both the camera and the Protect host, you can use any creative variations of VLANs or VPNs and still have it work.

m4tt075 commented 3 years ago

Thanks for your quick response, @keshavdv. I think the Unifi controller recognizes the Protect cams and configures the network accordingly. But it doesn't matter. I'd definitely like to isolate the cams, or more precisely, the switch ports connecting the IP cams, into their own VLAN.

I've seen that someone on this forum runs your proxy on the UDMP itself, which - thanks to your information - should allow me to achieve the desired state. I'll try and test and report back if this is of interest to others.

From what I've read so far, accessing the video streams on my non-branded Dahua cam might even be the bigger hurdle. I cannot even figure out what b****y model it is! ;-)

tsspmq commented 3 years ago

Protect (on a UNVR or UDM-Pro) only provisions settings like image, alerts, motion, etc without any regards to intervlan communications. Its up to you to set up the LAN security. They will take whatever LAN settings are on the switch port they are plugged into (or WiFi).

For finding out the model, have you tried the magic box URLs?

http://user:password@ipaddress/magicBox.cgi?action=getDeviceType http://user:password@ipaddress/magicBox.cgi?action=getHardwareVersion http://user:password@ipaddress/magicBox.cgi?action=getSerialNo http://user:password@ipaddress/magicBox.cgi?action=getMachineName http://user:password@ipaddress/magicBox.cgi?action=getSystemInfo

That should help you find the real model number of the device.

m4tt075 commented 3 years ago

Understood. Thanks, @tsspmq! I'll deal with the security aspects once I get the video streams running. Retrospectively, I think I was overenthusiastic posting this question... ;-)

And many thanks for the magic box URLs. I've not been able to produce output though. I've tried to put them into a webbrowser as well as with curl trying basic and digest authentification, but the response is always the same "404 Not Found". Either I'm not querying the API correctly, or that API has been removed together with the branding. Crikey!

tsspmq commented 3 years ago

Chances are they arent Dahua or have seriously crippled firmware. Lorex/Amcrest cameras respond to those URLs and we know those are. I assume you have looked around ipcamtalk forums?

m4tt075 commented 3 years ago

I agree. Something is wrong with those cams. They may well have fallen from some truck somewehre. The one I'm testing right now is the "good" one...
Yes, I've stumbled over that forum while I was trying to read up on the whole IPC topic. Good idea. Will try...

I've played around with frigate/mqtt in the meantime. 2 of the 3 IPCs, including the one I've been testing here, seem to work. Might provide a workable backup solution. But not really satisfactory...

Thanks for your help, @tsspmq. Much appreciated!

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.