That is why isolate the cameras from the internet so that are cameras are not viewable by anyone. We would even do that with an OPENIPC camera.
Good IPCameras that support OpenIPC
- Thread starter 90total
- Start date
That is why isolate the cameras from the internet so that are cameras are not viewable by anyone. We would even do that with an OPENIPC camera.
forlotto
n3wb
You could do that some folks need remote access to their NVR while they are away. NVR's are notorious for having firmware that setup secondary networks that provide their cameras access to the outside more or less. I guess you could have an SSH server you could access to access the bridge or something...
I am curious of how your network setup looks to accomplish this and still have the ability to remotely view your cameras.
OPENIPC is useful never the less.
I am curious of how your network setup looks to accomplish this and still have the ability to remotely view your cameras.
OPENIPC is useful never the less.
We host a VPN and VPN back into our network.
ipcamtalk.com
ipcamtalk.com
How to Secure Your Network (Don't Get Hacked!)
Many camera networks are unsecure, even those installed by professionals. This guide gives basic instruction in how to secure a camera network from the most common types of attacks. Perhaps the most important rule of securing a computer network is to not forward ports to unsecure services...
VPN Primer for Noobs
The internet is a force of nature; no video surveillance system made was designed to be exposed to those forces.. NEVER FORWARD PORTS to your NVR or Cameras, doing such things not only exposes you to severe security problems, but everyone else on the internet too.. Hackers dont want your video...
forlotto
n3wb
Yeah, nothing new under the sun there you seem to be a pretty active and helpful dude though thanks for your replies 
Do you know if there is a list of Camera hardware somewhere that supports OpenIPC anyways?
By model rather than chip.
My main cam is the sunba illuminauti actually pretty good camera cost a fortune when I first purchased it. Been going strong. The rest of my cams are just cheapies to be honest they are good enough if your going to pull down my driveway you'll be seen no doubt. Auto Tracking Auto Zoom works decent to focus on someones plate.
Are there any cameras the store sells that do the same thing high speed auto tracking auto zoon PTZ type? What cameras are you using? I'm kinda digging the cheap CTRONICS solar cameras as well these guys have some interesting cameras for the molah for tough spots where there is no power.
Do you know if there is a list of Camera hardware somewhere that supports OpenIPC anyways?
By model rather than chip.
My main cam is the sunba illuminauti actually pretty good camera cost a fortune when I first purchased it. Been going strong. The rest of my cams are just cheapies to be honest they are good enough if your going to pull down my driveway you'll be seen no doubt. Auto Tracking Auto Zoom works decent to focus on someones plate.
Are there any cameras the store sells that do the same thing high speed auto tracking auto zoon PTZ type? What cameras are you using? I'm kinda digging the cheap CTRONICS solar cameras as well these guys have some interesting cameras for the molah for tough spots where there is no power.
Last edited:
The Automation Guy
Known around here
We ALL agree that CCTV device's (and really any "IOT" device's) firmwares are very insecure. If they don't have backdoors installed, then they certainly have other security exploits in them that could be used by hackers to access/take over a device. These exploits are rarely patched in OEM firmware even if the exploits are publicly announced - and odds are there are plenty of exploits that have been found, but not publicly announced. However using open source firmware doesn't guarantee that exploits don't exist (they are just as susceptible to non-public exploits as anything else), it's just that they should hopefully be found and patched quicker than OEM firmware.
Therefore the "best practices" of this community is to ALWAYS isolate your camera network (which includes cameras and the NVR) from the internet AND the rest of your network. This means the camera network should never be accessible from outside of your local network and the devices on the camera network should never be able to access anything else on your local network or anything outside of your network (ie the "internet"). It doesn't matter if you are using OEM firmware or open source firmware - THIS SHOULD BE THE STANDARD! To make a long story short, you should never rely on your CCTV device's firmware to provide network "security".
This can be accomplished through physically isolating those devices from the rest of the network by creating a completely separate network segment, or "virtually" isolating them using VLANs in your network design. When set up properly, this type of network design will protect your CCTV system from outside threats/communication and protect the rest of your network from inside threats. Furthermore, if you need to access ANY part of your network (including the camera network) from outside of your local network, then you absolutely need to be using a self hosted VPN or other secure/encrypted method. "Port forwarding" ports to unencrypted services is NOT a secure practice and should NEVER be practiced on any network for any reason.
Now that being said, swapping out your OEM firmware for open source firmware isn't a bad thing. I actually do this with some of my other IOT devices. There are plenty of IOT devices that require the internet to work correctly and using an open source firmware with these devices can improve security in these situations. Luckily cameras do not fall into that category because we can isolate the camera network from everything else and they will still function property. Therefore the use of open source firmware is really not that important on a purely "security" basis. If the open source firmware offers some features/settings that aren't available with OEM firmware, then certainly using them can make your life easier and potentially provide better performance. But the choice to move to open source firmware for CCTV should be based on performance, not security. Given the fact that so few cameras work with open source firmware, it seems silly to limit yourself to these devices. Until I see cameras with open source firmware out performing cameras with OEM firmware, I'll be using OEM firmware because I want the best performance possible. I already know my system is completely secure based on how I have my network set up and I'll never need to rely on my CCTV device's firmware to provide that network security.
Therefore the "best practices" of this community is to ALWAYS isolate your camera network (which includes cameras and the NVR) from the internet AND the rest of your network. This means the camera network should never be accessible from outside of your local network and the devices on the camera network should never be able to access anything else on your local network or anything outside of your network (ie the "internet"). It doesn't matter if you are using OEM firmware or open source firmware - THIS SHOULD BE THE STANDARD! To make a long story short, you should never rely on your CCTV device's firmware to provide network "security".
This can be accomplished through physically isolating those devices from the rest of the network by creating a completely separate network segment, or "virtually" isolating them using VLANs in your network design. When set up properly, this type of network design will protect your CCTV system from outside threats/communication and protect the rest of your network from inside threats. Furthermore, if you need to access ANY part of your network (including the camera network) from outside of your local network, then you absolutely need to be using a self hosted VPN or other secure/encrypted method. "Port forwarding" ports to unencrypted services is NOT a secure practice and should NEVER be practiced on any network for any reason.
Now that being said, swapping out your OEM firmware for open source firmware isn't a bad thing. I actually do this with some of my other IOT devices. There are plenty of IOT devices that require the internet to work correctly and using an open source firmware with these devices can improve security in these situations. Luckily cameras do not fall into that category because we can isolate the camera network from everything else and they will still function property. Therefore the use of open source firmware is really not that important on a purely "security" basis. If the open source firmware offers some features/settings that aren't available with OEM firmware, then certainly using them can make your life easier and potentially provide better performance. But the choice to move to open source firmware for CCTV should be based on performance, not security. Given the fact that so few cameras work with open source firmware, it seems silly to limit yourself to these devices. Until I see cameras with open source firmware out performing cameras with OEM firmware, I'll be using OEM firmware because I want the best performance possible. I already know my system is completely secure based on how I have my network set up and I'll never need to rely on my CCTV device's firmware to provide that network security.
Last edited:
forlotto
n3wb
OK camera security does matter even if you isolate it on a network. There could be methodologies used via the firmware to create bridges to other subnets on your network or to your VPN server. Network "isolation" doesn't guarantee security you still need security of device firmware.
Bottom line is no matter how much we preach about isolation people will not do it because often it is too expensive or difficult for them and not practical so it is for those people that it makes common sense that we should not give up on device security.
Device security is something we just can't ignore you can continue to make the case you don't need it I disagree!
Just like DDWRT, OPENWRT, and Tomato after market firmware on cameras and open source development is important you can downplay this all you want but the answer is NO you can't make any case that will convince me it is not important!
Weather it is to enable better control of IR light intensity or frame or bit rate adjustments switching from VBR to CBR or improving detection of humans to reduce false alarms. This is a security camera form while I agree networking security is part and parcel to the picture claiming that security of device is not important is Denial of sorts!
Don't think for a moment that many of these large corporations that got hacked didn't use network isolation practices in fact they did in many cases and bridges were either made or exploited. Equipment firmware had holes in it even equipment for businesses with checksums on their firmware was able to be exploited Cisco was a big one. I wonder do you even understand what has all been done. Are you aware of what happened in Ukraine recently with their cameras being hacked? I seriously question anyone who thinks device security isn't important and live out this falsehood especially when they want to lecture on basic network security.
Did you know that often even whitelisting of MAC ID's a good practice doesn't guarantee security. If you have an insecure device on any subnet on your network with firmware on it you are unaware of you are instantly at a disadvantage and a risk. Device security is important this is my lesson for you to learn. Especially if you have a hard coded password for access!
Bottom line is no matter how much we preach about isolation people will not do it because often it is too expensive or difficult for them and not practical so it is for those people that it makes common sense that we should not give up on device security.
Device security is something we just can't ignore you can continue to make the case you don't need it I disagree!
Just like DDWRT, OPENWRT, and Tomato after market firmware on cameras and open source development is important you can downplay this all you want but the answer is NO you can't make any case that will convince me it is not important!
Weather it is to enable better control of IR light intensity or frame or bit rate adjustments switching from VBR to CBR or improving detection of humans to reduce false alarms. This is a security camera form while I agree networking security is part and parcel to the picture claiming that security of device is not important is Denial of sorts!
Don't think for a moment that many of these large corporations that got hacked didn't use network isolation practices in fact they did in many cases and bridges were either made or exploited. Equipment firmware had holes in it even equipment for businesses with checksums on their firmware was able to be exploited Cisco was a big one. I wonder do you even understand what has all been done. Are you aware of what happened in Ukraine recently with their cameras being hacked? I seriously question anyone who thinks device security isn't important and live out this falsehood especially when they want to lecture on basic network security.
Did you know that often even whitelisting of MAC ID's a good practice doesn't guarantee security. If you have an insecure device on any subnet on your network with firmware on it you are unaware of you are instantly at a disadvantage and a risk. Device security is important this is my lesson for you to learn. Especially if you have a hard coded password for access!
Last edited:
We agree with you and we are not blind that whitelisting and isolating only goes so far, but as @The Automation Guy correctly points out, there isn't a camera out there with the performance we need that runs opensource. If there were, we would be doing it in heart beat. Most of us if we have a router that supports open source, we have done just that to the router.
Granted I am no genius, but I even took apart a camera on the ideal MP/sensor ratio and tried to do something with just the sensor with opensource and got nowhere fast.
But the only open-source cameras I have seen or have seen people post about here are cheap stuff working with a Pi and as such are very limited in application as it is just the lens module and could never be placed outside in that condition, etc.
It seems more of a hobby than real world application at this point. Maybe it will get there, but it isn't there now for a camera to put outside and perform well in low light conditions.
So until that happens, we mitigate as best we can with the cameras that perform as we need. Are they completely risk free, no, but I will take my system that the cameras are on their own NIC and completely different subnet, along with a VLAN of the computer the camera NIC goes to over the performance of open source cameras at the moment.
Playing in your basement with a lot of light, yeah you can make it work, but once you expect it to perform well outside and in low light conditions, they just are not there yet.
Granted I am no genius, but I even took apart a camera on the ideal MP/sensor ratio and tried to do something with just the sensor with opensource and got nowhere fast.
But the only open-source cameras I have seen or have seen people post about here are cheap stuff working with a Pi and as such are very limited in application as it is just the lens module and could never be placed outside in that condition, etc.
It seems more of a hobby than real world application at this point. Maybe it will get there, but it isn't there now for a camera to put outside and perform well in low light conditions.
So until that happens, we mitigate as best we can with the cameras that perform as we need. Are they completely risk free, no, but I will take my system that the cameras are on their own NIC and completely different subnet, along with a VLAN of the computer the camera NIC goes to over the performance of open source cameras at the moment.
Playing in your basement with a lot of light, yeah you can make it work, but once you expect it to perform well outside and in low light conditions, they just are not there yet.
Last edited:
forlotto
n3wb
Yes you should Secure your network as others have stated over and over!
Last edited:
forlotto
n3wb
Lets get back on Topic.
The Original poster or OP asked what the cameras were that support OPENIPC!!!
No one has provided any content other than me to this question!
I am only aware of OPENIPC supported list containing a list of camera SOC's not a list of camera's.
Is anyone aware of a list or partial list of cameras supported by model rather than SOC's when it comes to OPENIPC?
Just because you may not care about device security does not mean that it is right or that others should not!!!
@wittaj yeah I feel the same way the big problem is you don't know what a camera is doing on a network it could easily take advantage of a network even if on a different subnet or an NVR these cameras are essentially mini servers on your network no matter the subnet a combination of this or a simple exploit in your networking equipment firmware and your best practices are out the window. Glad you are aware of that security of device is also of importance.
I am curious so what your saying is you are using the OPEN IPC firmware and it is having issues with night vision outdoors where it may not be as refined as say the original firmware that was on the camera?
I feel the more people we get going on this the more things will improve device security will improve, device operation will also improve and maybe even become better as a result all in time really.
OPENIPC is not our enemy by any stretch of the means and we shouldn't treat it as so!
The Original poster or OP asked what the cameras were that support OPENIPC!!!
No one has provided any content other than me to this question!
I am only aware of OPENIPC supported list containing a list of camera SOC's not a list of camera's.
Is anyone aware of a list or partial list of cameras supported by model rather than SOC's when it comes to OPENIPC?
Just because you may not care about device security does not mean that it is right or that others should not!!!
@wittaj yeah I feel the same way the big problem is you don't know what a camera is doing on a network it could easily take advantage of a network even if on a different subnet or an NVR these cameras are essentially mini servers on your network no matter the subnet a combination of this or a simple exploit in your networking equipment firmware and your best practices are out the window. Glad you are aware of that security of device is also of importance.
I am curious so what your saying is you are using the OPEN IPC firmware and it is having issues with night vision outdoors where it may not be as refined as say the original firmware that was on the camera?
I feel the more people we get going on this the more things will improve device security will improve, device operation will also improve and maybe even become better as a result all in time really.
OPENIPC is not our enemy by any stretch of the means and we shouldn't treat it as so!
smile4theIPC
n3wb
Glad to see the activity here. A few observations:
The case has been made for IPcamtalk.com to support the use of open source IPC firmware (such as OpenIPC). This site does seem to be tops in the field so it's entirely appropriate that a discussion like this take place here first.
There apparently is a lot of potential for growth in this endeavor, largely because no other site has taken it on lol.
Specific needs may include:
It's really up to the site owner(s)/admin(s) to decide on whether to go this direction. Perhaps they wholeheartedly embrace the idea, or maybe prefer the whole thing go away lol. A declaration either way would be helpful.
The case has been made for IPcamtalk.com to support the use of open source IPC firmware (such as OpenIPC). This site does seem to be tops in the field so it's entirely appropriate that a discussion like this take place here first.
There apparently is a lot of potential for growth in this endeavor, largely because no other site has taken it on lol.
Specific needs may include:
- At minimum, a table of correctly identified IPC offerings with hardware and corresponding FW listed for each.
- As that table is populated, discussion with comparison of notes will occur so, a place for that to happen.
- Common procedures and other info can be posted in a wiki space.
- Code development would likely occur elsewhere, but a more technical area in support of those efforts may be useful.
It's really up to the site owner(s)/admin(s) to decide on whether to go this direction. Perhaps they wholeheartedly embrace the idea, or maybe prefer the whole thing go away lol. A declaration either way would be helpful.
forlotto
n3wb
I agree 100% I'd like to see a future in Cameras where proprietary firmware and restrictions can be subverted. For a number of reasons the fact that people think they are safe just because they are on another subnet really blows my mind it's somewhat like there is a disconnect in the understanding in networks and exploitation of networks relies on subverting these measures. While I don't disagree we should do what we can having a firmware we don't know what it is doing at it's base is a security threat it is possible to stage attacks find a bridge do some mac spoofing or cloning create another bridge knock the bridge offline gain connectivity and so forth it might not be precisely the way but it is done subnets are hacked information is stolen and if you have highly skilled people in these areas making firmware with hardware with phone connectivity its like that phone is probably a potential bridge as well.
Its a good idea to know what is in your firmware it is a good idea not to have hard coded passwords that stay there and instead have a way to manually erase the flash and upload known or at least code that can be studied and updated. And in reality one could just use the USB connection or include a simple programming port for this if the hurdle is a little bit of solder and understanding TX has to be hooked to RX and you need proper voltage usually 5v or 3v and a ground and some software to communicate and upload erase or download firmware settings.
To be against this is a bit troubling to me why would you not wish to attempt to keep firmware secure that is the premise for my whole why not question. I'd much rather have OpenIPC on my camera "If it works well" as other have stated but I'm willing to forgo having it working perfect at first in order to have that portion a bit more secure and safe it's always a bit of a slow burn with Open Stuff until someone brings the right fuel.
However, I do think IPCamTalk and Open IPC working together would be the proper fuel mixture so to speak.
Its a good idea to know what is in your firmware it is a good idea not to have hard coded passwords that stay there and instead have a way to manually erase the flash and upload known or at least code that can be studied and updated. And in reality one could just use the USB connection or include a simple programming port for this if the hurdle is a little bit of solder and understanding TX has to be hooked to RX and you need proper voltage usually 5v or 3v and a ground and some software to communicate and upload erase or download firmware settings.
To be against this is a bit troubling to me why would you not wish to attempt to keep firmware secure that is the premise for my whole why not question. I'd much rather have OpenIPC on my camera "If it works well" as other have stated but I'm willing to forgo having it working perfect at first in order to have that portion a bit more secure and safe it's always a bit of a slow burn with Open Stuff until someone brings the right fuel.
However, I do think IPCamTalk and Open IPC working together would be the proper fuel mixture so to speak.
The Automation Guy
Known around here
Well since that comment is clearly directed at me, I'll bite.
I don't disagree that in a perfect world we would have access to open source firmware on all of our cameras. As I have previously noted, I use open source firmware on other devices (many IOT devices for example). I certainly support open source firmware efforts. I don't think a single person on this forum would say that supporting open source efforts is a bad thing.
However given the piss poor support of open source firmware currently in the CCTV world, I am not going to limit my camera choices to only cameras that support open source firmware. To do so would severely limit the effectiveness of my CCTV system. Am I taking a higher risk by using OEM firmware vs open source firmware? Sure, but that risk is mitigated to a large extent by isolating those devices. To the best of my knowledge, there has never been a CCTV firmware exploit that has been able to cross over network segments - at least with the camera brands I use. That's not to say it can't or won't happen, but I am more than willing to "risk" using OEM firmware because it allows me a much better selection of cameras which ensures I can maximize the actual performance of my CCTV system vs limiting myself to cameras that support open source because they all tend to have less than adequate performance.
Currently your choices are to have a camera system that uses open source cameras that likely won't perform well 40% of the time (anytime it is low/no light) but have a 99% chance your camera won't be hacked, or you can use cameras with OEM software that works well 95% of the time and has a 94% chance your camera won't be hacked (when appropriate security steps have been taken). Obviously those numbers have been made up by me and are unsupported, but they are closer to the truth than not. My point is that there is no argument that the odds of needing usable CCTV footage at night is MUCH greater than the odds of being hack over OEM firmware when you have taken appropriate security measures to isolate those cameras.
My hope is that one day there are enough good quality cameras that support open source firmware that we don't have to choose "security" over performance, but that day is not today.
Last edited:
forlotto
n3wb
OpenIPC is simply an alternative firmware. No one is forced to use it and that shouldn't be the case. It would be no different than if I loaded my router with DDWRT. There is obvious benefits to this not all routers are supported and at first WRT firmware was very limited to the WRT54G if memory serves me right.
It almost appears if things are being conflated slightly I get your stance and you are 100% correct there is nothing stopping anyone from waiting until there is a firmware worth using.
But would it sure don't hurt to allow people the ability to discuss and test and try different firmware here I believe it would give both communities a boost both your community and the OPENIPC community to some degree just to simply have say a small area on the forum to visit to see that OPENIPC exists and can be talked about.
Leave the OEM firmware on cameras unless it has a benefit for you but at the same time I can't imagine a reason to oppose an open firmware and restrict the growth in this space. Everything carries some intention I can't imagine a realistic intentional silencing of OPENIPC or not trying to foster growth in that space.
A simple discussion section, or a link back to OPENIPC more or less which I am not affiliated with I just happened to find them while in search of just like I found this website by mistake and purchased Blue Iris from it. Will I ever use Blue Iris ehhh well my cameras are not supported at current but with OPENIPC maybe they will be someday. I could go out and buy all new cameras or I could complain until the cows come home about the lack of support however, I am well aware that development takes time. This is one other reason why OPENIPC can be pretty powerful and helpful as it evolves. So many people that buy cameras are saddled with hardware they wish they didn't get for one reason or another the main thing is the way companies lock things down and don't have ONVIF support even though clearly the chip implicitly supports H264 and H265/+ when the hardware specs clearly state that and you know its a matter of firmware that is blocking ONVIF type access its a bit of a crapshoot. But this is a common problem I see in the camera space.
For one reason or another camera distributors love having implicit control and the ability to restrict the use of the owner of the property while also having huge security issues within their firmware. I'll be rather honest as well quite often people DO NOT no matter how much I preach about network configuration it is hard to get people on board with proper configuration of network don't know what it is I think it is the fact of having to buy more equipment in many cases and running all the extra lines associated with it and having to drill more holes in their home and pay for and run more wire just simply not being practical for them I mean thats a home gamer in general with a lot of stuff they have limited resources and limited bandwidth.
As far as the security threat again I will pose to you what was done in Ukraine wouldn't have been done if there were hard coded passwords there are websites dedicated to finding cameras with these hard coded passwords allowing people a window into their yard or homes and it is hard to get people to understand this. So what happened was Russia took over the cameras on isolated subnets and used the cameras during war time. Not that I'm pro either side but this is one great example that is out in the wild where camera firmware did have an impact on how swiftly their cameras were compromised. Its not just camera firmware it is networking equipment firmware we've seen a lot of attacks in the recent years at hardware level like BroadPWN for broadcom chips.
This is exactly why we shouldn't just overlook the gaping holes in camera firmware there is a concern to be had. And yes there was some study with camera firmware on hackaday can't recall the brand but there were brands that setup their own network outside of the network using the NVR the phone app and such all in conjunction so while you may not be aware of these types of threats just knowing that it is possible makes it all the more likely it will be done as tensions between countries are at an all time high and this presents a larger danger. So we shouldn't likely just say well lets just leave firmware alone because well it works good and I can't get the night vision working right the truth is it will come in time if the company can do it so can open firmware if we take the proper steps to foster that innovation.
It is your choice I couldn't imagine not fostering innovation in this space at the very least unless there is some kind of agreement you are under with hikvision or something that prevents you from doing so I mean why not help these guys along give them SDK's and such I just don't get it really and why is there an incessant need in this space it would seem to have such restrictive practices I've seen cases where IR light intensity adjustment was removed from certain cameras after two years of use and the company just crawfished and made up a bunch of excuses as to why the feature was disabled on that camera.
The expansion of my view would be that OpenIPC at some point could make IPCamTalk Camera's better it could improve sales of devices and foster innovation and improve upon camera security over time. Also when you no longer wish to support a device when it has reached End Of Service Terms it can have a continued support mechanism to at least help tamp down on possible forms of exploitation that may arise from a critical vulnerability of a device that is simply at end of service life in the grander scheme of things this is important for all it is important not to alienate the bitter clingers if we haven't learned nothing we should have learned this much by now.
I mean you can only lead a horse to water.
It almost appears if things are being conflated slightly I get your stance and you are 100% correct there is nothing stopping anyone from waiting until there is a firmware worth using.
But would it sure don't hurt to allow people the ability to discuss and test and try different firmware here I believe it would give both communities a boost both your community and the OPENIPC community to some degree just to simply have say a small area on the forum to visit to see that OPENIPC exists and can be talked about.
Leave the OEM firmware on cameras unless it has a benefit for you but at the same time I can't imagine a reason to oppose an open firmware and restrict the growth in this space. Everything carries some intention I can't imagine a realistic intentional silencing of OPENIPC or not trying to foster growth in that space.
A simple discussion section, or a link back to OPENIPC more or less which I am not affiliated with I just happened to find them while in search of just like I found this website by mistake and purchased Blue Iris from it. Will I ever use Blue Iris ehhh well my cameras are not supported at current but with OPENIPC maybe they will be someday. I could go out and buy all new cameras or I could complain until the cows come home about the lack of support however, I am well aware that development takes time. This is one other reason why OPENIPC can be pretty powerful and helpful as it evolves. So many people that buy cameras are saddled with hardware they wish they didn't get for one reason or another the main thing is the way companies lock things down and don't have ONVIF support even though clearly the chip implicitly supports H264 and H265/+ when the hardware specs clearly state that and you know its a matter of firmware that is blocking ONVIF type access its a bit of a crapshoot. But this is a common problem I see in the camera space.
For one reason or another camera distributors love having implicit control and the ability to restrict the use of the owner of the property while also having huge security issues within their firmware. I'll be rather honest as well quite often people DO NOT no matter how much I preach about network configuration it is hard to get people on board with proper configuration of network don't know what it is I think it is the fact of having to buy more equipment in many cases and running all the extra lines associated with it and having to drill more holes in their home and pay for and run more wire just simply not being practical for them I mean thats a home gamer in general with a lot of stuff they have limited resources and limited bandwidth.
As far as the security threat again I will pose to you what was done in Ukraine wouldn't have been done if there were hard coded passwords there are websites dedicated to finding cameras with these hard coded passwords allowing people a window into their yard or homes and it is hard to get people to understand this. So what happened was Russia took over the cameras on isolated subnets and used the cameras during war time. Not that I'm pro either side but this is one great example that is out in the wild where camera firmware did have an impact on how swiftly their cameras were compromised. Its not just camera firmware it is networking equipment firmware we've seen a lot of attacks in the recent years at hardware level like BroadPWN for broadcom chips.
This is exactly why we shouldn't just overlook the gaping holes in camera firmware there is a concern to be had. And yes there was some study with camera firmware on hackaday can't recall the brand but there were brands that setup their own network outside of the network using the NVR the phone app and such all in conjunction so while you may not be aware of these types of threats just knowing that it is possible makes it all the more likely it will be done as tensions between countries are at an all time high and this presents a larger danger. So we shouldn't likely just say well lets just leave firmware alone because well it works good and I can't get the night vision working right the truth is it will come in time if the company can do it so can open firmware if we take the proper steps to foster that innovation.
It is your choice I couldn't imagine not fostering innovation in this space at the very least unless there is some kind of agreement you are under with hikvision or something that prevents you from doing so I mean why not help these guys along give them SDK's and such I just don't get it really and why is there an incessant need in this space it would seem to have such restrictive practices I've seen cases where IR light intensity adjustment was removed from certain cameras after two years of use and the company just crawfished and made up a bunch of excuses as to why the feature was disabled on that camera.
The expansion of my view would be that OpenIPC at some point could make IPCamTalk Camera's better it could improve sales of devices and foster innovation and improve upon camera security over time. Also when you no longer wish to support a device when it has reached End Of Service Terms it can have a continued support mechanism to at least help tamp down on possible forms of exploitation that may arise from a critical vulnerability of a device that is simply at end of service life in the grander scheme of things this is important for all it is important not to alienate the bitter clingers if we haven't learned nothing we should have learned this much by now.
I mean you can only lead a horse to water.
The Automation Guy
Known around here
I don't disagree. However there is a big difference between someone saying, "Let's have a discussion about open source firmware" and someone saying, "Open source is the only viable option and it's mind blowing that people would use OEM firmware." Your statements have been much closer to the second than the first. I am also going to make counter arguments when I feel like someone is twisting the truth to push their agenda. To this point......
This isn't the first time you mentioned Ukraine as an example of how hackers (Russia) "took over cameras on isolated subnets and used the cameras during war time ". I've found ZERO proof that the hackers had to cross over isolated subnets. Take this article as an example (China's Hikvision, Dahua Security Cameras Heighten Risks Of Russian Attacks On Ukraine). It talks about how two cameras - one in a condo and another overlooking a parking garage - were used by Russia to "to spy on the Defense Forces in the capital." However the article goes on to say the cameras "are usually just connected to the Internet and are already relatively outdated -- that is, with software that has not been updated for a long time and has many known vulnerabilities." The article even goes on to say that "Manufacturers’ “basic” camera software means that “hackers -- or, in this case, the Russian special services – who are scanning the Internet can find this camera and gain access to it." That sure doesn't sound like hackers had to penetrate a network across multiple isolated network segments. It sure sounds like the cameras had a direct and two way connection to the the internet which is unfortunately how the majority of people set up their cameras out of ignorance to the risks.
Since you seem to have focused in on this idea that CCTV OEM firmware is so insecure that it allows hackers to penetrate isolated network segments and use the camera as a launching point to hop to other VLANs/network segments, I'd like you to post one verifiable instance of this happening.... I'm not talking about exploits in general, but an actual verifiable instance where 1) outside hackers (not someone on the local network) were able to access and exploit a CCTV device that was properly isolated from the internet and other network segments using just the CCTV OEM firmware (ie they didn't have access to the overall network through another hack because if they have already compromised the larger network, the security issue doesn't lie with the CCTV firmware) and 2) used that exploit to hop VLAN or other network segmentation setups and access other parts of the network that were normally isolated from the CCTV camera. Heck, I would actually be surprised if you can find a single instance of situation #1 occurring. But to proof your point that OEM firmware is so insecure that it allows network segmentation hopping, you really should have no trouble finding an example where both situations occurred.
Last edited:
Where did we say opensource is unimportant?
Where did we say we don't support opensource?
Many folks here use GitHub extensively and you can't get any more opensource than that repository of opensource work.
As @The Automation Guy said you are twisting what is being said to fit your narrative.
Many folks here with routers that support Merlin or Tomato do just that.
Many folks here use opensource to use many of their other devices.
And sometimes a good opensource solution doesn't exist and we have to accept the risk and the goal at that point is to minimize and mitigate as much risk as necessary.
And sometimes Opensource has vulnerabilities as well. OpenVPN has shown vulnerabilities as well.
Driving a car can be dangerous. We mitigate the risk by wearing a seatbelt, but even then bad things can happen.
Do you have a mobile phone that is running open source firmware?
Same with these cameras - we support opensource, but up to this point they flat out cannot cut it for what we use them for. As I have said, the opensource cameras I have seen are more hobby than reality if you need to use them outside and in low light conditions. Will that change - possibly. But right now their low light performance with an object in motion is as poor or poorer as the cloud-based solutions on the market.
So we use cameras that can work in low light environments and then mitigate the risk the best we can. We totally isolate the cameras from the internet and the rest of our system via VLAN or dual NIC. We assign bogus gateways and point the camera back to itself for the DNS servers.
Folks here run every imaginable tool to sniff traffic on their network and would notice in a heartbeat if something was out of line with their cameras.
I have yet to see someone here show that they have crossed subnets. Can it happen, sure anything is possible.
Where did we say we don't support opensource?
Many folks here use GitHub extensively and you can't get any more opensource than that repository of opensource work.
As @The Automation Guy said you are twisting what is being said to fit your narrative.
Many folks here with routers that support Merlin or Tomato do just that.
Many folks here use opensource to use many of their other devices.
And sometimes a good opensource solution doesn't exist and we have to accept the risk and the goal at that point is to minimize and mitigate as much risk as necessary.
And sometimes Opensource has vulnerabilities as well. OpenVPN has shown vulnerabilities as well.
Driving a car can be dangerous. We mitigate the risk by wearing a seatbelt, but even then bad things can happen.
Do you have a mobile phone that is running open source firmware?
Same with these cameras - we support opensource, but up to this point they flat out cannot cut it for what we use them for. As I have said, the opensource cameras I have seen are more hobby than reality if you need to use them outside and in low light conditions. Will that change - possibly. But right now their low light performance with an object in motion is as poor or poorer as the cloud-based solutions on the market.
So we use cameras that can work in low light environments and then mitigate the risk the best we can. We totally isolate the cameras from the internet and the rest of our system via VLAN or dual NIC. We assign bogus gateways and point the camera back to itself for the DNS servers.
Folks here run every imaginable tool to sniff traffic on their network and would notice in a heartbeat if something was out of line with their cameras.
I have yet to see someone here show that they have crossed subnets. Can it happen, sure anything is possible.
Last edited:
forlotto
n3wb
Irrespective, the questions still remain...
What I don't get is why we shouldn't want firmware security?
What I also don't get is why we should be forced into "cloud recording"?
What I also don't get is why functionality disabling through firmware is a thing among camera vendors?
Why not simply just pledge some support by allowing OpenIPC discussions just a little space or section on the forum possibly?
Also why not do away with the methodologies of hardcoded passwords?
And the original posters question still is unanswered as well which has been hijacked drawing me into conversation again as to why you want to know or why you shouldn't rather than getting a straight answer because personally the ole high horse isn't that high for me I honestly don't have the answer I admit it wish I did I'm also curious as to what camera models support OpenIPC. Best I can find is you have to disassemble the camera and look at your camera chip to see if OpenIPC supports it.
This is also where discussion would be helpful people could share what model cameras are working with OpenIPC and their results and maybe even contribute to improvements.
It is happening in the camera space all of these things sure it may not be all happening with your vendors in particular but this is a space to discuss cameras I'll be honest I'm not beholden to a particular vendor all cameras come from china all people have different needs many don't need the highest possible quality or the best night vision it is why there are so many cameras that fit so many needs but through open firmware this may improve in time I feel. There are many interesting vendors in the space. Obviously ONVIF venders are preferred because it is an OPEN thing isn't it? Anyone can introduce an NVR or software to interface with it seeing as how ONVIF is an open standard Some food for thought.
Sorry I don't have the specifics on the CVE stuff wish I could provide that but really its not relevant we know how it can happen we know that it does happen with government agencies and financial institutions crossing subnets is not a new tact for hackers and why not put a lid on the pot of gold with a lock rather than leaving it open with a hard coded password to rehash this is futile. A phone application can be used as a bridge network equipment is also susceptible at its base that is all we have to know at the end of the day security is the mitigation of plausible scenarios if you stop iterating at one step in the chain your system becomes insecure. Don't leave an open pot of gold put it in a safe otherwise it's like leaving a bucket full money on the park bench and believing that if people visit the park they won't take any in perpetuity you wait long enough someone is going to find it and take it.
What I don't get is why we shouldn't want firmware security?
What I also don't get is why we should be forced into "cloud recording"?
What I also don't get is why functionality disabling through firmware is a thing among camera vendors?
Why not simply just pledge some support by allowing OpenIPC discussions just a little space or section on the forum possibly?
Also why not do away with the methodologies of hardcoded passwords?
And the original posters question still is unanswered as well which has been hijacked drawing me into conversation again as to why you want to know or why you shouldn't rather than getting a straight answer because personally the ole high horse isn't that high for me I honestly don't have the answer I admit it wish I did I'm also curious as to what camera models support OpenIPC. Best I can find is you have to disassemble the camera and look at your camera chip to see if OpenIPC supports it.
This is also where discussion would be helpful people could share what model cameras are working with OpenIPC and their results and maybe even contribute to improvements.
It is happening in the camera space all of these things sure it may not be all happening with your vendors in particular but this is a space to discuss cameras I'll be honest I'm not beholden to a particular vendor all cameras come from china all people have different needs many don't need the highest possible quality or the best night vision it is why there are so many cameras that fit so many needs but through open firmware this may improve in time I feel. There are many interesting vendors in the space. Obviously ONVIF venders are preferred because it is an OPEN thing isn't it? Anyone can introduce an NVR or software to interface with it seeing as how ONVIF is an open standard
Some food for thought. Sorry I don't have the specifics on the CVE stuff wish I could provide that but really its not relevant we know how it can happen we know that it does happen with government agencies and financial institutions crossing subnets is not a new tact for hackers and why not put a lid on the pot of gold with a lock rather than leaving it open with a hard coded password to rehash this is futile. A phone application can be used as a bridge network equipment is also susceptible at its base that is all we have to know at the end of the day security is the mitigation of plausible scenarios if you stop iterating at one step in the chain your system becomes insecure. Don't leave an open pot of gold put it in a safe otherwise it's like leaving a bucket full money on the park bench and believing that if people visit the park they won't take any in perpetuity you wait long enough someone is going to find it and take it.
The Automation Guy
Known around here
Again, no one is saying we don't want firmware security. The vast majority of us simply don't place firmware security over camera peformance - especially when we can minimize our risk of exposure to firmware exploits by taking some logical networking architecture steps. Honestly using a camera that can't provide reliable identifiable footage in every condition is giving someone more "false security" that what we accept using OEM firmware.
Who is talking about "cloud recording" No one on this forum is going to suggest cloud recording. In fact we steer people away from using any sort of "cloud service" when it comes to CCTV (or anything for that matter).
I don't know exactly what you mean by this. The firmware I use seems to be pretty fully featured. I guess it is possible that opensource firmware could provide more functionality, but that would be a pleasant surprise vs the primary reason to use it.
Has anyone (it doesn't have to be you) actually tried to reach out to the forum owner/moderator to discuss this? "Talking" about doing something and actually reaching out to the people that can make it happen are two different things.
No argument there. However your camera has to be exposed to outside users before they can use a password to gain access to it. So this is one of those "security flaws" that most of us have mitigated through our network design.
That's because no one knows the answer or has started uncovering that information. As you have found, it seems that you have to disassemble the camera to check the chip. Just because this forum is dedicated to CCTV use doesn't mean its members are comfortable opening up their own devices to accomplish this for the benefit of the larger user base. Why don't you start a database with this information as you uncover it?
Last edited:
In addition to everything @The Automation Guy pointed out so not worth repeating, you are also hung up on the idea that using a phone app to view your cameras makes it open to hacking.
Many of us use Blue Iris and view our camera video feed via an app that a member here created that is available on github. Keep in mind we are viewing the camera feed, not accessing the actual camera itself or its proprietary app.
Also, I think you have a disconnect as to what we do here since you mention why do we have to be dependent on cloud based recording and firmware disabling capacities. Statements that are not applicable to most here.
That to me tells me your experience is with cloud based solutions.
My cameras have never touched the internet and in fact are completely set up on a laptop that has ZERO internet access. I am recording just fine. My camera works the same today as when I first bought it.
Contrast that to say a Zmodo camera that needs internet access to work and then they decide to disable AI years later unless you subscribe to their service. Those aren't the cameras we use here.
And nobody here is shutting down the open-source discussion like you seem to think. Just because we have said the current cameras that support it doesn't fit our needs doesn't mean we have banned the discussion here. You are taking our comments on it not ready for prime time the wrong way.
Many of us use Blue Iris and view our camera video feed via an app that a member here created that is available on github. Keep in mind we are viewing the camera feed, not accessing the actual camera itself or its proprietary app.
Also, I think you have a disconnect as to what we do here since you mention why do we have to be dependent on cloud based recording and firmware disabling capacities. Statements that are not applicable to most here.
That to me tells me your experience is with cloud based solutions.
My cameras have never touched the internet and in fact are completely set up on a laptop that has ZERO internet access. I am recording just fine. My camera works the same today as when I first bought it.
Contrast that to say a Zmodo camera that needs internet access to work and then they decide to disable AI years later unless you subscribe to their service. Those aren't the cameras we use here.
And nobody here is shutting down the open-source discussion like you seem to think. Just because we have said the current cameras that support it doesn't fit our needs doesn't mean we have banned the discussion here. You are taking our comments on it not ready for prime time the wrong way.
forlotto
n3wb
Excellent thank you both for pledging favor of support for Open Source IPC's not saying that you are happy with where they are that's fair but the fact that we can have the discussion makes all the difference.
Yeah I mean the only cameras I have that are not in service at the moment are my old Zmodo's I was talking about but they could serve a decent purpose if there were OpenIPC for them I can disassemble them and get chip numbers not a problem I take apart stuff and fix stuff for a living like that so sure I could at least contribute that much however I've taken them Apart and looked at the data set and these cameras are currently not supported. It would be nice if manufactures included processor information in the description just like a phone or a tablet does that would be helpful! Now as far as other units as I get them I can void warranties I presume.
But it would be good to have some names of supported camera models. This is a list of the recommended SOC's supported thus far.
Goke GK7205V200 #0x42000000Generate an installation guideGoke GK7205V2100x42000000Generate an installation guideGoke GK7205V3000x42000000Generate an installation guideGoke GK7605V1000x42000000Generate an installation guideHiSilicon HI3516EV2000x42000000Generate an installation guideHiSilicon HI3516EV3000x42000000Generate an installation guideIngenic T210x80600000Generate an installation guideIngenic T31AL0x80600000Generate an installation guideIngenic T31L0x80600000Generate an installation guideIngenic T31N0x80600000Generate an installation guideIngenic T31X0x80600000Generate an installation guideIngenic T31ZL0x80600000Generate an installation guideIngenic T31ZX0x80600000Generate an installation guideIngenic T40N0x80600000Generate an installation guideIngenic T40XP0x80600000Generate an installation guideSigmaStar SSC30KD0x21000000Generate an installation guideSigmaStar SSC30KQ0x21000000Generate an installation guideSigmaStar SSC3330x21000000Generate an installation guideSigmaStar SSC3350x21000000Generate an installation guideSigmaStar SSC335DE0x21000000Generate an installation guideSigmaStar SSC3370x21000000Generate an installation guideSigmaStar SSC337DE0x21000000Generate an installation guideSigmaStar SSC338Q0x21000000 Generate an installation guide
Took apart one for starters:
Zmodo IBH23 that model has the ANYKA AK3918EV300 SOC or MCU depending on how you wish to word it.
And as luck would have it all 6 of them are the same was really hoping they were different models so I could disassemble more! I presume when she warms up I'll have to tear the couple that I have down and take them apart so I can grab that data as well.
I have a sunba illuminauti and some other model that is solar powered I want to say CTronics they make some interesting cameras to serve specific niches like solar powered. It surely makes one curious without a doubt. I'm half tempted to go do it as I'm typing at the moment but It'll have to wait kinda windy and chili and don't want to lose the screws in the grass and snow did it once trying to change the SD card in er fricking thing is a beast though I love the illuminauti I almost bought some of the turret cameras from here but I wasn't too sure on how comparable they would be.
Things like adjustable IR intensity is useful on many camera models if we had open source firmware I imagine there are other hidden gems we could find like that ability to record in h264 or h265 being disabled and allowing either or maybe other features like streaming types or securing the stream somehow via cryptographic means hard saying I'm sure there is a lot that could come from open source if we use the old pink matter between the ears I know ridding hard coded passwords would be nice but who knows maybe better motion detection less false reports who knows I mean possibility is there once you have access to things.
Yeah I mean the only cameras I have that are not in service at the moment are my old Zmodo's I was talking about but they could serve a decent purpose if there were OpenIPC for them I can disassemble them and get chip numbers not a problem I take apart stuff and fix stuff for a living like that so sure I could at least contribute that much however I've taken them Apart and looked at the data set and these cameras are currently not supported. It would be nice if manufactures included processor information in the description just like a phone or a tablet does that would be helpful! Now as far as other units as I get them I can void warranties I presume.
But it would be good to have some names of supported camera models. This is a list of the recommended SOC's supported thus far.
Goke GK7205V200 #0x42000000Generate an installation guideGoke GK7205V2100x42000000Generate an installation guideGoke GK7205V3000x42000000Generate an installation guideGoke GK7605V1000x42000000Generate an installation guideHiSilicon HI3516EV2000x42000000Generate an installation guideHiSilicon HI3516EV3000x42000000Generate an installation guideIngenic T210x80600000Generate an installation guideIngenic T31AL0x80600000Generate an installation guideIngenic T31L0x80600000Generate an installation guideIngenic T31N0x80600000Generate an installation guideIngenic T31X0x80600000Generate an installation guideIngenic T31ZL0x80600000Generate an installation guideIngenic T31ZX0x80600000Generate an installation guideIngenic T40N0x80600000Generate an installation guideIngenic T40XP0x80600000Generate an installation guideSigmaStar SSC30KD0x21000000Generate an installation guideSigmaStar SSC30KQ0x21000000Generate an installation guideSigmaStar SSC3330x21000000Generate an installation guideSigmaStar SSC3350x21000000Generate an installation guideSigmaStar SSC335DE0x21000000Generate an installation guideSigmaStar SSC3370x21000000Generate an installation guideSigmaStar SSC337DE0x21000000Generate an installation guideSigmaStar SSC338Q0x21000000 Generate an installation guide
Took apart one for starters:
Zmodo IBH23 that model has the ANYKA AK3918EV300 SOC or MCU depending on how you wish to word it.
And as luck would have it all 6 of them are the same was really hoping they were different models so I could disassemble more! I presume when she warms up I'll have to tear the couple that I have down and take them apart so I can grab that data as well.
I have a sunba illuminauti and some other model that is solar powered I want to say CTronics they make some interesting cameras to serve specific niches like solar powered. It surely makes one curious without a doubt. I'm half tempted to go do it as I'm typing at the moment but It'll have to wait kinda windy and chili and don't want to lose the screws in the grass and snow did it once trying to change the SD card in er fricking thing is a beast though I love the illuminauti I almost bought some of the turret cameras from here but I wasn't too sure on how comparable they would be.
Things like adjustable IR intensity is useful on many camera models if we had open source firmware I imagine there are other hidden gems we could find like that ability to record in h264 or h265 being disabled and allowing either or maybe other features like streaming types or securing the stream somehow via cryptographic means hard saying I'm sure there is a lot that could come from open source if we use the old pink matter between the ears I know ridding hard coded passwords would be nice but who knows maybe better motion detection less false reports who knows I mean possibility is there once you have access to things.
Last edited: