R81 - SNMP does not support SHA1 anymore

[Norbert_Bohusch]

Hi all,

I just noticed that R81 does not allow to configure SNMPv3 Users to authenticate using SHA1, only SHA256 and SHA512.

I mean it is good that the new ones are supported since R80.40, but disallowing SHA1 introduces problems with monitoring solutions and their predefined checks, which are not yet updated and don't allow configuration of SHA256 or SHA512.

Is there a supported way to enable SHA1 until we or the monitoring vendor has updated the relevant checks?

PS: I found also no hint about this in any document or SK.

[G_W_Albrecht]

Traditionally (and by default in current versions R80.40 & R81) MD5 is used - see sk90860: How to configure SNMP on Gaia OS for details ! SHA1 has only been introduced in R77.30 JT 75, and to use it for custom traps would need another HF to be installed.

sk106126: Best Practices - Monitoring of Security Gateways and Management Servers running on Gaia OS suggests to use MD5 / DES for SNMPv3. Here, it reads that in R80.40,  authentication protocols group were changed to be SHA1, SHA256, SHA512 (instead of MD5).

Can you confirm that only SHA256 & SHA512 are left for SNMP auth, with MD5 and SHA1 removed ?

[Norbert_Bohusch]

Here what you get for auto-completion, if you insert manually something different it throws an error:

nb-ckp-mgmt> add snmp usm user test security-level authPriv auth-pass-phrase vpn123 privacy-pass-phrase vpn123 privacy-protocol 

DES     AES     AES256

nb-ckp-mgmt> add snmp usm user test security-level authPriv auth-pass-phrase vpn123 privacy-pass-phrase vpn123 privacy-protocol AES authentication-protocol 

SHA256  SHA512

Through changing gaia DB with dbset (copy & paste from an older R80.x), I got it working after setting the password again.

Also through inline upgrades SHA1 is preserved and is working (that's what's working in my lab environment since months). But the issue appeared while using advanced upgrade at a customer.

Here also from WebUI:

[G_W_Albrecht]

This should be reported to TAC - i will start by giving feedback on sk106126 and sk90860 about SHA1 being unavailable in R81 fresh install...

[PhoneBoy]

I’m guessing this is a bug (not being able to set sha1) and we probably need a TAC case.

[John_Fleming]

Des is still supported but not SHA1?

[PhoneBoy]

Like I said, it's probably a bug.

[Norbert_Bohusch · Accepted solution]

Here a documentation of the workaround I used to get SHA1 working on R81 fresh installation:

1. Create SNMPv3 user with SHA256 and test it

r81-system> add snmp usm user checkmates security-level authPriv auth-pass-phrase Cpwins1! privacy-pass-phrase Cpwins1! privacy-protocol AES authentication-protocol SHA256
r81-syste# snmpwalk -v 3 -l authPriv -u checkmates -a SHA-256 -A Cpwins1! -x AES -X Cpwins1! 127.0.0.1 HOST-RESOURCES-MIB::hrSystemUptime.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (257555406) 29 days, 19:25:54.06

2. Get the Gaia DB config from an older system (R80.x)

r80.x-system# cat /config/active | grep auth:proto
snmp:v3:user:checkmates:auth:proto .1.3.6.1.6.3.10.1.1.3

3. Set Gaia DB setting on new system

r81-system# dbset snmp:v3:user:checkmates:auth:proto .1.3.6.1.6.3.10.1.1.3

4. Check that the Auth-Type has changed to SHA1

r81-system> show snmp usm user checkmates
Username checkmates
Permissions read-only
Security Level authPriv
Authentication Type SHA1
Privacy Type AES

5. Set the passwords again (else it will not work) and test with SHA1

r81-system> set snmp usm user checkmates security-level authPriv auth-pass-phrase Cpwins1! privacy-pass-phrase Cpwins1!
r81-system# snmpwalk -v 3 -l authPriv -u checkmates -a SHA -A Cpwins1! -x AES -X Cpwins1! 127.0.0.1 HOST-RESOURCES-MIB::hrSystemUptime.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (257576932) 29 days, 19:29:29.32

Hope that helps some of you! 

[genisis__]

Just tried this, and it failed at the last hurdle, note below that I'm using AES256

# snmpwalk -v 3 -l authPriv -u SNMPUSER -a SHA -A Test123# -x AES256 -X Test123# 127.0.0.1 HOST-RESOURCES-MIB::hrSystemUptime.0
snmpwalk: Decryption error

If I redo the configuration but use AES then it works.

# snmpwalk -v 3 -l authPriv -u SNMPUSER -a SHA -A Test123# -x AES -X Test123# 127.0.0.1 HOST-RESOURCES-MIB::hrSystemUptime.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (2398639) 6:39:46.39

Running R81 with JHFA23

[Tal_Martsiano]

Hi @Norbert_Bohusch ,

Indeed, SHA-1 was removed in this version (R81), we are still supporting SHA-1 existence in terms of upgrades etc.., means that a user who preform an in-place upgrade will not need to do any passwords changes for existing SNMP users.

New SNMP users will be created using stronger hash (as you've mentioned).

It seems there is a documentation gap regarding this behavioral change. we will close it ASAP.

Thanks,

Tal M

[G_W_Albrecht]

Please also include in the documentation gap the silent death of MD5 that is always mentioned as the default ! Apart from that, i see no sense in still supporting SHA-1 existence in terms of upgrades, causing old SNMP users to stay on an unsafe security level, but excluding adding new SNMP users using SHA-1 for legacy monitoring tools !

I would have prefered just adding SHA256 + SHA512 to the menu and giving an alert for SHA-1 or MD5 use...

[RamiShahar]

hello, does this WA works for MD5 users as well?

[genisis__]

Totally agree, its short sighted of Checkpoint to remove SHA-1 support,  this really should be added back in and leave it to the customer to decided there security policy on securing SNMP traffic.

[genisis__]

Is this really wise, surely support for SHA-1 should be kept.  In our case Solarwinds does not support SHA256 yet; it would make more sense to have three options, SHA-1, SHA256 & SHA512.

I've done a clean install of R81 with JHFA23 (JHFA25 has some odd issue related to GUI client not being authorised).

[J_Bailey]

sk174463 is out now describing the steps for the SHA1 / R81 workaround.

[genisis__]

I don't suppose anyone knows how to achieve the same thing on VSX?  

[Norbert_Bohusch]

Why do you think the same procedure is not available on VSX?

[genisis__]

the use of 'dbset' is not recommended when using VSX, least according to SK92770.

 I have relayed my observation to TAC, also SK174463 does not actually mention VSX and feel this SK should be updated with the correct procedure for VSX as well.

I'm hoping to get some response from TAC today are in the correctly supported workaround for VSX.