Forced passwords and SNMP community strings change

Affected platforms: All platforms
Affected versions: 4.7.0, 5.3.0 and above

Network security vulnerabilities are constantly evolving as threat actors seek new and intuitive ways to gain access to a business’s network). Cambium Networks is constantly monitoring and preventing the equipment security risks.

Current changes follow recently discovered security risks in users authentication algorithms and equipment configurations via SNMP. They affect default password and SNMP communities behavior. Now they can be used in completely default configuration only. As soon as the user starts to prepare the radio for a network deployment all default passwords and SNMP communities must be changed.

Since FW 4.7.0 and 5.3.0 user passwords and SNMP Read-Write Community Strings should be at least 8 characters.

The SNMP remote access is disabled by default for the following scenarios:

  • If the radio is upgraded from Firmware versions 5.1.3 or below to 5.3-RC14 or newer Firmware version and default SNMP community strings are configured.
  • If the configuration file from 5.1.3 or earlier Firmware is restored to the device.
  • If the radio is reset to default on 5.3-RC14 or newer Firmware

Out of the box radio with 5.3.0 and default configuration:

  1. On the first GUI login with admin/admin credentials the next pop-up window is shown and you can not skip it:

  2. After password save SNMP access and user accounts except admin account are disabled:

    Next notification is shown:

If the radio is upgraded from 5.1.3 or to the below version, then the following notifications appears:

  1. If the admin user password is default, then the user gets a window to change it. Change the default password or disable the account.

  2. If one or both SNMP communities are default and SNMP access is disabled as shown below:

    The notification appears as shown below:

  3. After enabling SNMP Remote Access, a pop-up notification is shown as below:

  4. If the radio has non-default admin password, then the user can perform the operations.

To set SNMP access enabled, define community strings, enable accounts and set passwords via CnMaestro use next template:

"device_props": {
	"snmpRemoteAccess": "1",
	"snmpReadOnlyCommunity": "cambium123",
	"snmpReadWriteCommunity": "cambium123",
	"cambiumSysAccountsTable": [{
			"cambiumSysAccountsName": "admin",
			"cambiumSysAccountsHash": "$1$\/4mFIcf4$BDYKtSYVUkfl7rijAVG\/a1",
			"cambiumSysAccountsUID": "1000",
			"cambiumSysAccountsGID": "4",
			"cambiumSysAccountsDir": "\/tmp",
			"cambiumSysAccountsShell": "\/usr\/bin\/clish"
			"cambiumSysAccountsName": "installer",
			"cambiumSysAccountsHash": "$1$TzjSMihI$I4VIkvOX9.5mILd\/i9NlJ\/",
			"cambiumSysAccountsUID": "2000",
			"cambiumSysAccountsGID": "100",
			"cambiumSysAccountsDir": "\/tmp",
			"cambiumSysAccountsShell": "\/bin\/false"
			"cambiumSysAccountsName": "home",
			"cambiumSysAccountsHash": "$1$TzjSMihI$I4VIkvOX9.5mILd\/i9NlJ\/",
			"cambiumSysAccountsUID": "3000",
			"cambiumSysAccountsGID": "100",
			"cambiumSysAccountsDir": "\/tmp",
			"cambiumSysAccountsShell": "\/bin\/false"
			"cambiumSysAccountsName": "readonly",
			"cambiumSysAccountsHash": "$1$Y9oz6eRg$ysokBk9VZCGo4AN6WQgVF0",
			"cambiumSysAccountsUID": "4000",
			"cambiumSysAccountsGID": "100",
			"cambiumSysAccountsDir": "\/tmp",
			"cambiumSysAccountsShell": "\/bin\/false"
			"cambiumSysAccountsName": "dashboard",
			"cambiumSysAccountsHash": "$1$Y9oz6eRg$ysokBk9VZCGo4AN6WQgVF0",
			"cambiumSysAccountsUID": "5000",
			"cambiumSysAccountsGID": "100",
			"cambiumSysAccountsDir": "\/tmp",
			"cambiumSysAccountsShell": "\/bin\/false"


The only way to generate the hash is by changing the password on a radio and reading it from the configuration file.

Validate the json before loading it into cnMaestro!

Useful links about templates in cnMaestro:
How to use templates
How to create Templates in cnMaestro for ePMP radio


Hi thank you for addressing this.It might cause a bit more work for installers and will require installers to template out config but this is a very welcome addition.


So, updated network to 4.7-rc56 and now need to send a config template to re-enable all of the snmp on the radios. Thanks.

Your upgrade system needs to check for configured snmp communities, throw a flag if the strings are not long enough and make it that they need to be changed to continue or disable snmp if the communities are set to default. Not overwrite my configs because of some security issue that a properly setup network does not have.


I’ve updated the first post with a template to change passwords and SNMP communities.
All you need is to change 3 strings (read, write and admin password). Then paste it into your cnMaestro and then just two clicks to change it all around your network.

Is it so hard? If yes you can raise a support ticket any time you need help, assistance or just someone to hold your hand while you are configuring your network.

Can you stop being so disrespectful with your customers?

Thank you.

BTW, not everybody is using cnMaestro. Should I go on with your sarcasm and open 1K tickets?

1 Like

I’m sorry, guys! Monday morning coffee was too sarcastic…
I just wanted to say we are always ready to help!
Your input is very important for us and if you don’t see immediate reaction it means we need some time to investigate this information and take measures.


Unfortunately, forcing SNMP community string and passwords was the necessary measure.
Over the last several months we faced with massive hacking attacks to ePMP equipment all over the world and in all cases the access was hacked through default password of one of the user accounts or default SNMP community strings.
Hundreds of support tickets were processed and investigated before taking any actions.

As you know, we always had notification on UI that passwords and SNMP community strings must be changed once the device is turned on leaving all to the complete control of user.
Unfortunately it didn’t work and hundreds thousands of ePMP devices were operating with partially default credentials in the global network.

So we forced passwords and SNMP community strings change in software and tried to make it as user friendly as possible. That is common approach that all vendors are implementing nowadays.
We understand that it can cause inconveniences and needs some extra work to be done, but it’s vitally important and it is better to make these changes and spent some time now, then restoring access after hacker’s attack.

With great respect to each and every our customer we notified everyone in Release Notes and additionally directly in Downloads section on the web-site, posted that information in community and advised how to make required changes.

Hope for your understanding!
We are always opened to your feedback.

Thank you.

1 Like

Hi @Fedor,

as I wrote before, these changes are welcome. Really.
Problem is: these changes are mandatory before a very important upgrade, and we know about them only after RC-56(?) is out. This let us few time to manage this issue.
And if we ask for a delay (I think public beta are for a public feedback from us) or a rethinking all we got is:

and after saying “this is simplicistic, I think none of you have experience managing network of thousands of devices” I got

or the answer above, we can’t be happy.
Especially with this version, where we waited for months to have some news.


WOW, just wow.

Cambium: “Please provide suggestions and feedback”
Also Cambium: “if you do, we will ignore your suggestions and publicly mock you”


Your template is wonderful IF the radio has default settings and not already changed settings. I am not against adding security but proper security not security by enforcement. Simply using an access control list to provide snmp access from appropriate IP ranges is the first step in a layered security plan, further ensuring that the web interface has a system to prevent brute forcing of passwords with a long block time (denyhosts/fail2ban) go a long way to adding proper security.

I get the feeling that there is no want to even try to actually secure these devices, this forced half measue is good for only new radios but an snmp community of 16 characters long can be brute forced in about 2 days, a webpage password can be done just as fast without some form of enforcement which these radios severly lack. Even using the L3 firewall does not give us the ability to block web access nor define proper firewall rules as the framework is very limited.

If you look at the old Canopy and the newer pmp gear, an snmp control list is already implemented, so login brute force blocking is all that is needed and sadly most of the sub systems are already in place to provide this function.

Forcing string changes from defauly is the necessary measure, not disabling a function that is NOT in a default configuration.

I dont know if you noticed that so far no one has complained that the enforced admin password change and minimum length? We are complaining that your change in policy has broken our networks, caused a lot of extra work for those not using cnMaestro and a more than mild PITA for those of us that are, especially since we now have to go to each radio and re-enable our non-default snmp setting.

Instead of just simply complaining about a security policy that was badly implemented I offer a better way of getting this necessary security measure in place and that is to force the admin password be not default and if changed meet the minimum length requirement, if snmp is enabled make sure the community is not default and refuse to save the config until a) the communities are changed or b) snmp is disabled. This can be done with regular expressions that your web pages already use.

Going forward this type of security is just delaying the inevitable since there is no actual provisions to prevent brute forcing. SNMP requests should only come from a very controlled subset of IPs, so an access control list can be used to prevent snmp requests from all addresses but those on the list, Canopy radios have this. Web access just needs some method to prevent a script kiddie from trying every combination until they get in, denyhosts and fail2ban have done this for years and are light weight enough for even the old epmp1000 integrated radios to run.


Why not just enforce ACL on SNMP rather than 8 Char min.
We cannot upgrade to 4.7 as this will require full rework on all network monitoring across all devices.
Just because you have stupid users who don’t secure their network correctly does not mean you have to enforce snmp community min chars which is not in line with the RFC.


Relying on network ACLs for security unfortunately leaves you open to attacks from malware running on the trusted clients. I absolutely agree that ACLs are an important part of network security, but I think they should be used alongside strong passwords, not as a substitute.

" Relying on network ACLs for security unfortunately leaves you open to attacks from malware running on the trusted clients. I absolutely agree that ACLs are an important part of network security, but I think they should be used alongside strong passwords, not as a substitute."

ok lets look at this: ACLs actually do protect you from infections from trusted devices, ALCs only on the edge do not. ACLs must be on each device in the network that needs to be protected. The protection comes from a multi-layered approach that includes management device network isolation, limited access rights (ACLs) and proper software verification through lab testing. A properly secured and authenticated management network will not have the opportunity to become infected nor accessed from unauthorized network locations.

Having the SNMP/ssh/telnet process only work on the management vlan is also a step in the right direction. Adding that the web interface does not report login attempts to any log nor trap event makes it incumbent to utilize an access method such as radius-auth to even know that a login attempt has been mad on the SMs!

Breaking RFC to make a “security patch” is not actually a security measure. Since snmp connection attempts are not logged nor flagged/ trapped in any way, it is just a matter of time that an 8 character community will be cracked and no one will notice! An ACL will make sure those attempts can only come from a device within the correct IP range which would not be the entire IP subset of the network.
A community string is NOT a password, but a message identifier. Any snmp gathering program can broadcast and snmp request using the broadcast and multi-cast addresses and only those devices with the same community would respond. This allows for classified device queries based on community strings. Ultimately using a community string as a password is just security by obfuscation and provides no security what so ever, there is no backend to provide such security!

Considering these radios are linux based computers with a software defined radio and a very nice RF filter, it is very possible to include the tools needed to provide real security using already available methods that are in production use on thousands of linux based servers world wide! You are already using JSON parsing to modify config files and reload services, just need to extend the functions to add IPTables or NFTables constructs and the ability to isolate services to vlans.

I do agree that configuring long, complicated passwords on default users and disabling unused users for unconnected access is an important step as long as firmware upgrades also look for passwords that are not default and do not force changing already established passwords.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.