Continuing the discussion from Wireless baby monitor hacked, baby insulted:
I’d love to get more info on a secure way to do this. While I’m technically inclined, I haven’t had any networking training, so…not dumbed down, but not overly technical. I’d like to have exterior cameras for security, but don’t want to compromise security by installing unsecure cameras.
I’d start with the assumption that any reasonably priced camera (and a downright shameful percentage of the ‘oh-so-fancy-and-expensive’ ones) is simply broken beyond any repair that you could DIY or that the manufacturer is competent and motivated enough to do. Some are more broken than others; but it simply isn’t a safe assumption that any of them can be trusted on the public internet.
On the LAN side, it’s more a matter of your paranoia; but a second router (or a more sophisticated model with support for multipl SSIDs and VLANs, your call) is pretty cheap. Given the risk of compromised hosts on your LAN (either yours, after a spot of bad browsing luck, or god-knows-what from friends/relatives who want to get on the internet), why risk it over $50?
So, all cameras on their own dedicated network (if you went with two routers) or on their own VLAN (if you went with one more sophisticated one). Access to that network should be only through an SSH tunnel or VPN(SSH tunnels are a bit more elegant, since you can tunnel individual ports; but are less well supported on non-unixlike systems, while VPNs are a bit clunkier, since they tunnel everything; but basically all OSes, even mobile ones, support a variety of VPN options.
If you go with SSH, any router that supports OpenWRT should be ready to go once you configure the SSH daemon correctly (keypair auth is best. If you must use a password, make it good). If you want a VPN, you’ll need to do some additional work this is one implementation.
Unless you have a static IP, you’ll also need dynDNS so that you can actually find your network, any router supported by OpenWRT can handle this, a surprising number of proprietary vendor firmwares can as well. Once that is set, you either SSH tunnel or VPN connect to the router handling your cameras, and away you go.
It doesn’t hurt to do what you can with the cameras’ “security” settings, setting passwords, updating firmware, etc. probably won’t make them worse; but is largely secondary. In case any of the cameras you buy try to do something fancy (eg. tunneling back to the mothership so that the vendor can offer a ‘super-convenient’ “cloud monitoring” account or some nonsense like that), it would probably also be a good idea to configure the firewall rules on your camera router to explicitly reject all incoming and outgoing traffic except your SSH or VPN. You don’t want the cameras doing anything stupid.
As for local connectivity, WPA2-AES (Probably just PSK, Radius is a pain in the ass unless you’ve got a lot of clients to deal with) on the wireless, reasonable caution on anything hardwired(albeit mostly out of concern for weather and squirrels and stuff, if you have ninjas tapping your ethernet cables physically, you have other problems…)
fuzzyfungus, is this based on specific knowledge about how easily compromised consumer cameras are, or rather just that it’s safer to make such an assumption? Or something in between?
Thanks for your guidance on how to set up a secure solution.
I’ve only read about IP cameras(and assisted with a fancy-consultants-involved project at work, and yes, embarassing numbers of default passwords remained set, despite the fancy consultants, until we eventually just fixed it in-house); but I’ve done a fair amount of basic exploit assessment of other embedded devices at similar price points(embedded print servers, little NAS boxes, set-top video streamer widgets, routers(on the LAN side, they are mostly hardened up on the WAN side), thin clients, projectors, assorted management cards, etc.) and it’s pretty embarrassing.
I’m hardly some kind of hardcore hacker, so my ‘basic assessment’ pretty much boiled down to examining the firmware(either on the device, if you could get access to the system directly, or through opening firmware update files) and checking versions. If the newly released firmware contained antique, known vulnerable, versions of web browsers or other components, that was scored as a bad thing (but a very, very common one). If the device had a local interface or a web interface I’d try a few directory traversal and command injection attacks, just to see if they left anything really stupid open (and I’m not very good, so anything I could attack that way I figured was totally doomed, anything I couldn’t might not be totally doomed). I’d also google around to see if there were any known or documented backdoor/vendor service/otherwise idiotic accounts Finally, I’d just script-kiddie them with Nessus/OpenVAS and see what happened: since I was using not-terribly-cutting edge vulnerability descriptions, anything that threw red flags there got the full force of my skepticism eyebrow, since those tests were only of vulnerabilities that were already known, and frequently already fixed in the mainline version of the program. A surprising number of embedded devices didn’t even stay up while being probed, and simply stopped responding until the power was forcibly pulled and restored(by contrast, subjected to the same tests, Windows, Linux, and OSX desktop systems, patched up to date but not otherwise hardened, just shrugged).
So, I’m hardly an expert security research type; but I know enough to exploit more embedded systems than makes me comfortable, and operate on the assumption that if people screwed up the basics, such that I can get in, the subtle, elegant, vulnerabilities are probably a total clusterfuck, albeit one that somebody talented probably hasn’t poked yet(you hope).
I’m a network admin, and I’m using one of these Foscam cameras at home as a baby monitor (just upgraded the firmware!)
I agree with everything that fuzzyfungus says in principle - these are cheap, generally insecure devices, and you want to segment them as far as possible. Ideally I’d have mine behind ssh.
Unfortunately one of the big features for us is that we can view the camera from our mobiles. There are plenty of ios and android apps for this, and it’s great to check on the little one when we’re out. To do this properly you’d need to set up a proper VPN and set up your phones to join the VPN when they’re out. As well as being somewhat complex, this is a bit less reliable (e.g. when connecting back to the VPN from mobile).
One other alternative I’m looking at is to reverse proxy the web request behind another device. Something like a properly secured raspberry pi using HTTP certificate based authentication, which passes things back to the webcam itself. Again though, slightly more complex to configure.
For now I’m just logging whenever anyone accesses it, which will give me a good idea of how likely it is to be attacked.
This topic was automatically closed after 1283 days. New replies are no longer allowed.
