How to handle forced security changes during software update

[MW_WISP]

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…

Hi @aka

although I think it is a good thing to force the management of passwords and communities, this can lead to heavy interventions on the management of an existing network.
For example, modify of a community must be done on the device, management software, monitoring, etc. etc.

Can we ask to rethink, before the final version, to review the mandatory implementation of these rules?

Thank you

[aka (Andrii)]

I don’t think I’ve got you right.

Do you mean not to force passwords and communities change? If yes, then you can prepare it in your own temp before upgrading your network.

[MW_WISP]

@Andrii_Khmelnytskyi

you can prepare it in your own temp before upgrading your network.

Thank you for your answer.

I don’t think any of you have experience managing thousands devices, because that “you can prepare your network” is simplistic and inadequate.

Bye

[aka (Andrii)]

Yeap! We have just the experience of creating those devices and management tools for them.

Passwords and communities are changed by one single template in CnMaestro.

Are you using Radius authentication? What issues are yo expecting?

[Douglas_Generous]

Andrii,

I think what is meant that if these are currently set to non-default, do not force the change since the operator has already made the required changes.

Changes I would prefer over the current security measures:

For SNMP, setup an authorized IP subnet where snmp request should come from and drop all other requests not from that subnet.

Webpage access requires more than simple long passwords, if you are not providing a banning method with reporting then it is still just a matter of time before the password is cracked. Longer passwords will take longer but the lack of control and active reporting makes this useless in terms of security. Having an ACL of sorts or a system similar to the old DenyHosts system would actually prevent unauthorized access.