How Do You Handle Password Assignment Of 200+ Cameras?

Originally a question from the IP Camera Passwords - Axis, Dahua, Samsung post.

So what to do for setting the passwords of 200 IP cameras? Hopefully not the vendor default. Even if you set a strong password, presumably you are going to push the same password to all cameras using the camera manufacturer's utility? Is that typical? If so, does anyone consider that a security risk?


Closed domain. Not worth the effort...

Can you elaborate? Do you mean since your IP cameras are on a closed network, it is not worth the effort to assign them non default passwords or?

Yes, that's what I meant.

I think it's typical to use the same password on all cameras in a system. I can think of some systems in my past which used three vendors' cameras but all the same password.

Is it a risk? Sure. If one is compromised, they all are. The question is how much of a risk is one being compromised? Assigning a unique password to every single camera is a bit impractical just because documentation gets pretty particular at that point. Ideal? Yes. Necessary? Probably not.

We have 200+ cameras, 7 NVR servers (soon to be 8), multiple workstations on a private VLAN and do not use the manufacturer default for any password. We use a fairly long and complex single password for all cameras with the exception of one manufacturer's devices which only allows 8 characters. Our password for those is complex, however. On the cameras that have a built-in viewer and/or user account that cannot be deleted, we change that password to be the same as the administrative password.

For us, only admins are authorized to change camera settings. The admin password is known by only two people, and if one of us leaves someone will spend a day changing passwords. We do the same with the admin accounts for our VMS application, servers, and workstations.

We do not consider this a security vulnerability any more than a domain administrator would consider the domain admin password a vulnerability. It does, however, require that we be diligent in protecting that password. If someone (e.g., integrator/installer) needs access to a device's settings we allow it only through the VMS and they are given a temporary user account that is strictly limited to the specific device(s) they need access to. If the VMS can't access the particular camera settings then we do the configuration with input from the integrator/installer.

Our camera VLAN is private and cannot be seen from outside our network and from only a select few other VLANs on that network. We consider the risk of hacking very low. Not zero, but low.

Kevin, thanks for sharing Informative!

We have been keeping the camera switch segregated from the "normal" switched network when possible and only allowing a second NIC in the server to connect to the "normal" network. This way, only the server itself is actually able to connect to the cameras themselves. Sure, you still have the risk of the server being compromised, but that is always a risk as long as the network is connected to the internet. Proper firewalls and VLANS should help prevent server discovery anyways.

Batch password change by manufacture's utility. You can also add ip filtering + Mac filtering to limit direct ipc access.

As for security risk, psasword should be batched in before installation.

Since your cameras are on a private network then I consider it an acceptable practice to have the same strong password. That approach should be fine either via a VLAN or a physical private network.

For folks whose cameras are not on a private network, then yes I would utilize different strong passwords for each camera — even if it’s painful.

One of our staff (an ex-programmer) developed our own customised scan tool that finds almost any camera/device we need.. We can roll out passwords using his tool very quickly, as well as set IP address, see a thumbnail of the image and various other useful, time saving features. Its sooo handy and saves many hours when we are on-site. For example, the last thing we do is click one button and the tool will go and take an "as installed" full res image of all the cameras and store it in in our documentation area.

Cameron,

Would this tool be available to other's ?

No not really.. its not ready for commercial production and its very much designed for our company. Was more a case of highlighting that with IP CCTV you can automate/code a large amount of the process to meet your standard installs.

The tool works well for us, perhaps some smart developer will see my comments and make something for the industry??

ok, understood. thanks

Regardless of using passwords, don't overlook the ability to protect all cameras by implementing switchport security based on learned, or assigned MAC addresses. Then of course you have to be vigilant and monitor the environment over time. Any changes in the MAC tables or disables ports needs an thorough investigation. To properly monitor the health of ports, RFC2613 on your switches is the feature, and perhaps one of the best tools we found for port monitoring is manageengine oputils, and intravue.

Else, another celebrity video clip could end up on youtube.

All those high end security solutions are worthwhile in an enterprice corporate network with all the alerting and monitoring tools active.. But for the most part CCTV systems are often on isolated networks, do not have IT onboard or the client does not wish for such complexity and monitoring.

Your solution certainly has merit from an IT perspective, MAC address blocking and ACL's and the like are great, but the implementation and ongoing setup/monitoring is a cost only a minority would be happy with.

Another one that some people might appreciate (which is high-end also) is that some cameras etc will support RADIUS type for network authentication. Why not have your network security granted by authentication processes.. Again the overhead can be a bit much but if you need that level it would certainly provide significant additional security on the network.

Actually, most managed L2 switches support MAC filtering simply by enabling the features once all the working cameras are up and running. Turn no MAC filtering, and their is a learned feature, and that's it. If your IP cameras and VMS support APIPA addressing, you can further simplify the lan by not using DHCP, or assigning Static IP addresses. You can install a small IP based camera system very quickly, and know that only your cameras will remain on the private camera network. The two tools I mentioned are sold on the number of supported IP addresses, and may have a free trial tool.

To seperate your company from your competition, you should at least discuss the idea of adding more security, and let them say no.

A question that I have related to this issue - are there cameras that have the ability to email on failed log-in attempts?

That's something I recently wondered, too, and I've been looking and there don't seem to be many. Dahua is one of few, which we covered in a recent article. Hikvision also allows it.

Axis, Bosch, Sony, Avigilon, Samsung, and Arecont do not, as far as I have seen.

Thanks Ethan - as the system administrator of a relatively large video surveillnace system, I do want to mention to any of the representatives from camera companies that this is a feature that could be a differentiator when making camera decisions. Additional features that either provide additional security and/or provide notification when security breaches are attempted are needed as IP cameras are essentially small computers residing on our corporate networks.

That would assume the private LAN has access to an SMTP email server to bounce email off off, and that might imply the LAN has a router in place, and that greatly increases the security footprint. regardless of the system being a video network, or an IT LAN, enabling MAC protection via learning, is perhaps the easist thing to suggest to a client regardless of size, to limit plug in access to the LAN and/or cameras. VLANS are great too, but more complex that simple MAC learned security on a small LAN... If you have a multi-homed (dual NIC) VMS then the LAN side can have access to email systems, and let the VMS advise you when cameras fail...

There are multiple problems waiting for a VMS to tell you when a camera fails.

1. Most do not integrate camera tampering alarms at all. So moving a camera or blacking it out without disconnecting it will do nothing on the VMS side.

2. Even if they do, by the time a camera goes down, it's too late. Video is lost.

I'm not saying it's highly likely someone is going to hack all through your network and drop a camera simply by logging into it. I am going to say that it's nice that some manufacturers give you the option to detect the failed login, as it's quicker warning that something is up than waiting for a failure.

From my experience, since 84' supporting LAN's of all sizes, email has never been a reliable tool. There are many problems with email, and they include, the mail module isn't very smart, and a failed email never retries, the smtp mail server, must accept relays, and that's a no-no. We've found managing thousands of desktops, and hundreds of servers, we prefer to monitor systems on L2/L3 and manage the exceptions, and opposed to looking at email to see if things are good or bad... That takes a lot of human eyeballs..

Personally, I've suggested long ago to my preferred VMS vendor to develop a mechanism to dynamically assign a password from within the VMS package. IE, the superadministrator sets a camera password scheme, and it's pushed to the camera on bootup and registration. SIP, has had this technology for some time. Also it would be the berries, if they can set an authorized remote access password source IP address or IP address Range. This is common in LAN environment where you have routed VLANS.