Camera security question

[donb21]

After lots of searching, I haven't found much detail on why some Chinese made cameras were banned, and if ZoneMinder users are concerned about them. Most of the articles mention insecure back doors and generally taking over the camera. Why would we buy something like that?

However, some of these cameras are feature rich and very inexpensive; very hard to pass up. Is securing them as simple as putting them behind a firewall?

[mikb]

Why would we buy something like that?

Ignorance. In the nicest possible way It's not always possible to know that something is insecure until someone discovers it (having pulled apart the firmware to discover the permanent non-documented non-changeable test user, or observed unusual network traffic on their personal system as the camera calls home to China etc.) -- and only then does word spread. By then, thousands are in use. How would you know? And for a lot of people, it would never occur to them. They bought it, plugged it in, it worked. "Changing the default whatnow? No, we left it alone, as it worked!"

However, some of these cameras are feature rich and very inexpensive; very hard to pass up. Is securing them as simple as putting them behind a firewall?

Depends on the nature of the flaw. For cameras that have backdoors and security faults where an external user (internet) can get in on a default password because you didn't change it, then change it. Where there is a default account that you didn't know about, that has a fixed password, you can't change it, so firewall it.

The only problem with a firewall being a total solution -- what if the camera calls OUT to the Internet?

Most firewalls have a loose outgoing policy, because it is perceived the threat is outside, trying to get in. In this case, you have bought the threat, and placed it inside your network

The only way to guard against that is to tell the firewall that no packets are allowed out from the camera, to the internet. This may stop the camera working in some way (Time server, DNS). If you have a camera that demands access to the cloud for operation, you can't lock that down. So don't buy them.

[donb21]

That's pretty much what I thought. Securing against the known issues may not be very difficult, but, I don't know what I don't know. There are entire industries dedicated to finding and guarding against stuff like this (think about the Stuxnet story). Rather than playing whac-a-mole with the hack of the week, I think I'll look for a camera company that isn't playing that game.

So, the starting point would be to look for non-suspect hardware, which pretty much rules out anything built in certain places. I'm guessing there are lots; so far I've found Axis, Amcrest, and Pelco. Any others I should consider?

[paulgault]

Hi, I'm new to IP cams and ZM. I have an old laptop in the loft with ZM on it and my new super cheap Chinese IP cam and POE injector have finally arrived from AliExpress, so I'm having a play.
I've been browsing the forum a while now and there does seem to be a recurring concern brought up about the cameras dialling home for unknown reasons!
Thanks to mikb for their previous post. nice clear overview. appreciated.
When I'm ready to install cameras in my driveway and garden for real I'm struggling to decide if i should have the ZM laptop and cameras separate from my network and router, leaving them completely offline.
The reason why I'm unsure is that I don't really know what the drawbacks of setting things up this way would be. Sure, i won't be able to look at my driveway from a remote location but I don't think I'd really bother doing that anyway.
Does anyone else have their cameras offline?
If you have your cameras connected what cool features would you miss the most if you had to leave all your kit offline instead?
thanks for reading, Paul.

[Farm_Server]

If the camera has a way to access it from an app or outside the local network then they are using a reverse proxy of some kind which is always keeping a connection open through your firewall. In Reolink's case it is just an Nginx reverse proxy which you can see if you try and log in before they finish booting up. This means it is maintaining some kind of connection to Reolink just like a Ring camera is maintaining some kind of connection with AWS that allows you to contact it and view the feed from any device. You are given the option to disable this in Reolink by deselecting the UID checkbox in its menu but I don't trust that being the only outgoing connection these cameras are making either.

To address the concerns about this it can be done with network segmentation and firewall rules. For instance, my cameras use PoE and travel into my zoneminder server directly, not into a switch with a bunch of other local devices attached. My zoneminder server has outbound firewall rules that block the cameras based on their MAC addresses and only allows outbound connections made by the server's NIC. That NIC goes into my firewall appliance using its own LAN subnet. Firewall rules there block connections to anything other than the server MAC itself and allows inbound connections to zoneminder for remote viewing. Keeping zoneminder on its own subnet can offer protection for your other devices using the same firewall appliance in case a device on your network(or the zoneminder box itself) gets pwned and uses it to attack other machines on your netowrk.

This way, the cameras themselves would have to have some kind of software built into them that can crack through the zoneminder server firewall and then gain root privileges onto the entire machine to even begin making outbound connections to 'wherever'. This can be deemed unlikely because whatever exploits are baked into the camera firmware could get exposed and wasting a good exploit on the offchance you can see a live feed of my yard seems wasteful.

If I was very concerned about this I could also create rules on my firewall appliance that only allows incoming connections from specific MAC addresses (like my phone and laptop) so even if this poor RLC-410 can pwn the zoneminder box all by itself it can only send data out. Again this would be extremely unlikely. If it was aware of what was going on it would then have to pwn both the zoneminder box AND the firewall appliance which would use alot of really good exploits on the off chance they really wanted to live stream my lawn.

A far more likely scenario is that someone finds the zoneminder login page if you are using a domain name or DDNS to reach zoneminder. They would then need to find a way of hacking that and using privilege escalations to take control of your zoneminder box. Then it is far more likely just to be used for a botnet to steal bitcoin and dick pics and not State sponsored surveillance.

You could mitigate this by logging in via a VPN or something similar but then maybe your not tech savy family wont be able to use it and complain(a real problem). Or you could have the zoneminder box connected to an always on VPN and use DDNS and host the domain through the VPN exit IP. This would hide where the actual server is located, an IP search would just show up as some data center somewhere. So if someone was scanning that VPN provider, got to your zoneminder page, exploited a flaw in zoneminder or apache and got into the cam feeds, they could view the stream of your lawn all day but not really know where it is unless they spent the time deducing it by analyzing the images. In the other direction, if the super hacking software suite in the RLC-410 was able to pwn your entire network it would also report back that your lawn was in some data center.

So much of this is basically basic network construction and honest threat modeling about what you are really likely to encounter, and what can be done to mitigate it.

Some good Samaritan could come out with an open source firmware for webcams, one could assume they are all made in the same district in China and are using the same basic parts. Similar to DDWRT or OpenWRT provides for routers. But there does not seem to be much enthusiasm for that.

[EmillyElizabeth]

Hey there, apologies for bumping an old thread, but I'm on the hunt for some info about Chinese-made cameras too. I agree, they are very tempting because of their low prices, but security is definitely a concern. I appreciate the tips on securing them with network segmentation and firewall rules.
I actually stumbled upon this thread because I was doing some research on Live streaming software for my security camera. I found a website that might be helpful for those looking for software to stream their camera footage.
As a new member of this forum, I'm still trying to figure out the best way to navigate and find useful information. Thanks for the tips and insight on camera security!

[RonRN18]

I know that for many, my solution is not feasible, but I run numerous VLANs at my home. I have my primary LAN, that I run all of my computers and file sharing on. I also have a VLAN for guests, a VLAN for IoT devices, a VLAN for several web servers, and a VLAN for cameras. With the exception of the cameras VLAN, all of the VLANs have Internet access. I intentionally do NOT give access to cameras to access the Internet. Even if there was some type of backdoor "call home" capability, it will fail. Now that I say that, I am now wondering if that is what is going on with my latest camera that crashes at least once an hour... maybe it is trying to call home and can't connect, so it crashes.

[mikb]

I know that for many, my solution is not feasible, but I run numerous VLANs at my home. I have my primary LAN, that I run all of my computers and file sharing on. I also have a VLAN for guests, a VLAN for IoT devices, a VLAN for several web servers, and a VLAN for cameras. With the exception of the cameras VLAN, all of the VLANs have Internet access. I intentionally do NOT give access to cameras to access the Internet. Even if there was some type of backdoor "call home" capability, it will fail. Now that I say that, I am now wondering if that is what is going on with my latest camera that crashes at least once an hour... maybe it is trying to call home and can't connect, so it crashes.

If you are savvy enough to separate your network like that, then if you really want to know if the camera is calling home -- put something running tcpdump, WireShark or similar on that VLAN. Observe the traffic. Work out how to exclude packets that are the cameras talking to your ZM system (if src or dest IP address = ZM system IP address). Anything left over is worth looking at -- cameras broadcasting or accessing unknown IP addresses.

I would not be surprised to find that some lazy coding (or down right malicious coding!) means that the camera can't cope when it's not allowed to talk to some secret server. Either, hard coded name server, time server or something like that at the most basic. Or, an actual "spy-central" check-in

[RonRN18]

I know that for many, my solution is not feasible, but I run numerous VLANs at my home. I have my primary LAN, that I run all of my computers and file sharing on. I also have a VLAN for guests, a VLAN for IoT devices, a VLAN for several web servers, and a VLAN for cameras. With the exception of the cameras VLAN, all of the VLANs have Internet access. I intentionally do NOT give access to cameras to access the Internet. Even if there was some type of backdoor "call home" capability, it will fail. Now that I say that, I am now wondering if that is what is going on with my latest camera that crashes at least once an hour... maybe it is trying to call home and can't connect, so it crashes.

If you are savvy enough to separate your network like that, then if you really want to know if the camera is calling home -- put something running tcpdump, WireShark or similar on that VLAN. Observe the traffic. Work out how to exclude packets that are the cameras talking to your ZM system (if src or dest IP address = ZM system IP address). Anything left over is worth looking at -- cameras broadcasting or accessing unknown IP addresses.

I would not be surprised to find that some lazy coding (or down right malicious coding!) means that the camera can't cope when it's not allowed to talk to some secret server. Either, hard coded name server, time server or something like that at the most basic. Or, an actual "spy-central" check-in

Apparently "calling home" was not apparently the reason for the crash. I was watching the network activity of the camera and did learn something interesting. For my router/firewall, I am using pfSense Plus. In pfSense, I run my own DNS server that operates between Cloudflare DNS servers and downstream devices with pfBlockerNG blocking some domains. In the different DHCP servers, I assign only my DNS server as the only one to give downstream devices. My camera obtained its network information from DHCP but in addition to the DNS server I assigned, it also added 8.8.8.8 to its list of DNS servers. I first realized this when I was seeing the camera reach out on port 53 to 8.8.8.8 and not get a response... because it has no Internet access. I had already told my DHCP server to assign a statically assigned IP number to the camera based on its MAC address but I changed the camera from DHCP to static and got rid of 8.8.8.8 as an alternate DNS server. After doing so, I was no longer seeing the attempts to connect to an Internet IP address. Because I only pass a few pin-hole ports between my camera network to my other VLANs, the camera was getting a few ICMP errors, as I believe it was trying to reach back out to devices that were connected to it.

I still do not know the cause of my camera's frequent crashes.

[mikb]

but in addition to the DNS server I assigned, it also added 8.8.8.8 to its list of DNS servers.

Yeah, I've seen that sort of thing. One of my cheap NAS devices ignores the NTP time server I set up. It has a box to put your own CHOICE of IP address in there. So I set my own firewall (which also has an NTP server facing inward).

It ignores the setting and continues to connect to "something.chinese.com" as the NTP server. This is not helpful. So I put a fake fixed local DNS entry in my firewall that says "something.chinese.com" resolves to my firewall -- and that stopped that!

They are probably trying to be "helpful" by adding a back-stop. It would be better if they only *used* that back-stop if the IP address you listed failed.