Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Norbert_Bohusch
Advisor
Jump to solution

R81 - SNMP does not support SHA1 anymore

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.

1 Solution

Accepted Solutions
Norbert_Bohusch
Advisor

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! 

View solution in original post

(1)
18 Replies
G_W_Albrecht
Legend
Legend

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 ?

CCSE CCTE CCSM SMB Specialist
0 Kudos
Norbert_Bohusch
Advisor

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:

gaia-r81-snmp.png

 

 

 

 

 

 

 

G_W_Albrecht
Legend
Legend

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

CCSE CCTE CCSM SMB Specialist
PhoneBoy
Admin
Admin

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

0 Kudos
John_Fleming
Advisor

Des is still supported but not SHA1?

0 Kudos
PhoneBoy
Admin
Admin

Like I said, it's probably a bug.

0 Kudos
Norbert_Bohusch
Advisor

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! 

(1)
genisis__
Leader Leader
Leader

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

 

 

0 Kudos
Tal_Martsiano
Employee Alumnus
Employee Alumnus

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

0 Kudos
G_W_Albrecht
Legend
Legend

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...

CCSE CCTE CCSM SMB Specialist
0 Kudos
RamiShahar
Contributor

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

0 Kudos
nasa
Participant

no, the workaround does not work for MD5.

0 Kudos
genisis__
Leader Leader
Leader

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.

0 Kudos
genisis__
Leader Leader
Leader

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).

0 Kudos
J_Bailey
Explorer

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

0 Kudos
genisis__
Leader Leader
Leader

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

0 Kudos
Norbert_Bohusch
Advisor

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

0 Kudos
genisis__
Leader Leader
Leader

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.

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events