Is AES-256-C encryption supported?

Hello Team,

Is AES-256-C encryption supported in check_mk version 2.3 ?

Regards,
Dinesh

Hi @dineshinspace,

can you be a bit more precise with your request?

Checkmk has many different components and features that rely on Encryption. Which feature do you mean, and can you explain the reason behind your request, please?

Regards
Norm

Hi @Norm , I have some firewalls which need to be monitored via SNMP AES-256-C encryption.

Pls guide.

Regards,
Dinesh

Hi @dineshinspace,

thanks for the clarification.

In Checkmk 2.3 you should be able to monitor your Firewalls:

Regards
Norm

1 Like

No - AES-256-C - means AES-256 with Cipher Feedback and this is not a standardized protocol for SNMP.
If he can select real AES-256 without the C then it should work.

3 Likes

Oh, didn’t know that. Thanks for the info! :sweat_smile:

The problem here is that AES-192 and AES-256 is no defined standard for SNMPv3, it has only draft status since 25 years :rofl:

If you dig deeper you will find the recommendations to use SNMP over TLS.
https://snmp.com/protocol/dtls.shtml
I don’t know what vendors are supporting this and how fast or slow the answers are :smiley:
One point for the TLS - all the documents are RFCs and no draft.

2 Likes

Thanks @andreas-doehler for the information.

This means i have to set only AES-256 on firewall device to communicate with Checkmk .

Regards,
Dinesh

Hi @andreas-doehler ,

Checked with Cisco vendor for setting only AES-256 instead of AES-256-C. As per vendor AES-256-C is the default encryption mode even if they assigned AES-256, call will be made with AES-256-C only.

Below are the Make & Model and version which are not able to monitor with checkmk.

Make & Model OS
CISCO CATALYST 1000-24T Version 15.2(7)E7
CISCO Cat2960-24TT Version 12.2(55)SE12
CISCO CATALYST C9300L Version 16.12.4

Please guide as not able to monitor with AES-256 encryption.

Regards,
Dinesh

Hello @andreas-doehler,

Which mode from below list we are supporting for AES-256 ?

  • ECB mode: Electronic Code Book mode.
  • CBC mode: Cipher Block Chaining mode.
  • CFB mode: Cipher FeedBack mode.
  • OFB mode: Output FeedBack mode.
  • CTR mode: Counter mode.

Regards,
Dinesh

Why not try? I don’t know what these means.

:slight_smile: These are modes of AES encryption. Cisco is currently supporting CFB mode. monitoring tool has to be connect with CFB mode if need to monitor.

Again you only need to try the different settings and you can cross check with snmpwalk manually on command line.
If you know a working snmpwalk command then you can configure the same settings inside CheckMK.
It is not really a problem of CheckMK, more of the SNMP by itself.
All these extensions are mostly vendor specific and no IETF standard.

2 Likes

I am in the same boat. I am able to monitor Cisco devices with SNMPv3 and AES-128. I saw AES-256 support was added in CheckMP 2.3 so I am attempting to use it but can’t get it to connect and work with Cisco devices. Does anyone know what specific settings we need on the Cisco side and what settings we need on the CheckMK side?

Thanks!

At the moment (CMK 2.3) only the event console can handle all the SNMP privacy protocols.

    CBC-DES
    AES-128
    3DES-EDE
    AES-192                 aka AES-192-C
    AES-256                 aka AES-256-C
    AES-192-Blumenthal      aka AES-192
    AES-256-Blumenthal      aka AES-256

The confusing naming comes from the pysnmp library.

I don’t know why the SNMP fetcher don’t support these protocols.
Only a guess is, NET-SNMP does not support the Cisco variants.
And with this you cannot use the same SNMP rules for RAW and enterprise versions.
But again this is more a question for @martin.hirschvogel :wink:

Thanks for the answer. Is full support on the roadmap?

Short:
Andreas is completely right with his main statements: net-snmp which we use either directly (classic) or via Python bindings (inline, commercial editions only) does not officially support the requested privacy protocols… at least not in the UI.

Long and more complicated answer:
The Event Console uses pysnmp as backend which uses the mentioned privacy protocols with cfb such as aes-256-cfb by default.
We actually implemented pysnmp also for our regular snmp monitoring in Checkmk 1.6.0. However, we eventually dropped the support during beta phase (or even before? I cannot remember exactly) as the performance turned out to be significantly slower than net-snmp. For many customers, calling hundreds of snmp devices, this was no option and would have produced more problems than solving.

net-snmp itself relies on openssl that in general has an implementation for aes with cfb. It turns out that net-snmp indeed provides that as “AES-256-C”. It’s just does not default to this variant like pysnmp does. Additionally, it’s not even mentioning this option in the manpage nor in the command help. One can only see that in the code itself: net-snmp/snmplib/snmpusm.c at master · net-snmp/net-snmp · GitHub (line 198-202)

Conclusion: It looks like that it is possible to support that option. If we want to do that highly depends on the stability of this feature in net-snmp. Also, it’s very unfavorable that Cisco uses (or abuses?) their market power to push such non-standardized protocols instead of pushing a standard in IETF.
Next steps: Could you please create an idea on our portal to have that in an official place to see, what we can do (and when)?

2 Likes

Is there a way to use AES256C in the meantime? It’s a requirement from our Network Security team to use AES256 on our ciscos’. Otherwise we can’t continue with CheckMK.

Should be possible out of the box if that’s what you meant :

Cisco uses AES256C, AES256 doesn’t work. Cisco uses special encryption with Cypher feedback known as AES256C. Fortinet for example could use this too.