Support for AES256 and SHA256

[delboy1966]

Your question

glpi-agent uses Net::SNMP to do its SNMP queries, but we have devices that use auth and priv encrytpion types AES256 and SHA256. And the very latest version of NET::SNMP doesn't support those.

The issue is the USM.pl file in the modules Perl directory. I've found a couple of posts in the Internet that say they have patched versions of USM and I've tried them, but they still fail, I suspect the postings were years ago and not related to the version of Net::SNMP we have installed, 6.0.1.

I've even tried to get ChatGPT to rewrite our current USM.pm file, but with mixed results, ultimately it still doesn't work.

We have SNMP v5.9 unix package installed, which doesn't support them. So, is there a way to get glpi-agent to use unix snmp instead? Or has anyone got a patched USM.pm file from Net::SNMP V6.0.1 that works?

I suspect this might be a common thing shortly as people and companies are hardening their devices even more.

[g-bougard]

Hi @delboy1966

I still answer to such problem here: #974

You're probably right about USM.pm. In the upstream project, there's a patch shared for this file here: https://rt.cpan.org/Public/Bug/Display.html?id=148740

Is it the one you tried ? If not, here is the 6.0.1 patched version: USM.pm-patched.zip

You should be able to test it with glpi-netinventory script setting privprotocol to aes256c. If you can test it and it works, I can investigate to include it into GLPI-Agent code source.

[delboy1966]

Hi @g-bougard

Thanks for the prompt reply.

I've tried the USM.pm you have provided and it doesn't seem to work, I beleive its because it doesn't support SHA256, at least thats the error message I'm getting back when I'm testing it with my test script using Net::SNMP

my ($session, $error) = Net::SNMP->session(
    -hostname     => '192.168.1.1',
    -version      => '3',
    -username     => 'snmpuser',
    -authprotocol => 'sha',
    -authpassword => '@uthP@ssw0rd',
    -privprotocol => 'cfb256aes',
    -privpassword => 'Pr1vP@ssw0rd',
    -timeout      => 5,
    -debug        => 2,

And if I try to use SHA instead, I get

Session creation failed: Received usmStatsWrongDigests.0 Report-PDU with value 40662 during synchronization

Any advice?

Thanks
);

[g-bougard]

Have you tried setting aes256c as privprotocol as I proposed ? To me cfb256aes will still trigger the wrong protocol.

[g-bougard]

Okay, I found this patch: https://www.mail-archive.com/[email protected]/msg106148.html

And here is the new patched version (including the previous one): USM.pm-patched-v2.zip

You should be able to set authprotocol to sha224, sha256, sha384 or sha512 to fit your need.

[delboy1966]

Thaks for that.

I've tried the new one and its giving me an error I've had before, over the past 3 days of trying to find a tix.

ERROR: The authProtocol "1.3.6.1.6.3.10.1.1.5" is unknown during discovery

And I'm not sure why.

[g-bougard]

Please share the full output, including the command. To me it seems this can happen if you use cfb256aes in place of aes256c as privprotocol.

[delboy1966]

This is the glpi-inventory line I am using, replacing the actual username and passwords.

glpi-netinventory --host 10.108.226.1 --credentials version:3,username:snmpuser,authprotocol:SHA256,authpassword:@uthp@55word,privprotocol:cfb256aes,privpassword:Pr1vp@55word

and this is the ouput

[error] #1, SNMP communication error: The authProtocol "1.3.6.1.6.3.10.1.1.5" is unknown during discovery
<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
  <CONTENT>
    <DEVICE>
      <ERROR>
        <ID>0</ID>
        <MESSAGE>SNMP communication error: The authProtocol "1.3.6.1.6.3.10.1.1.5" is unknown during discovery</MESSAGE>
      </ERROR>
    </DEVICE>
    <MODULEVERSION>6.6</MODULEVERSION>
    <PROCESSNUMBER>1</PROCESSNUMBER>
  </CONTENT>
  <DEVICEID>foo</DEVICEID>
  <QUERY>SNMPQUERY</QUERY>
</REQUEST>

No matter what SHA protocol I use, it always come back with the OID relating to that protocol in the error message.

Can glpi not revert to unix snmp? Most of the software/scripts we use for other stuff does. And I see this as being more common as Cisco force people to use SHA256 and AES256 on new hardware.

[g-bougard]

As I said, you persist to use cfb256aes in place of aes256c. Your commandline should be:

glpi-netinventory --host 10.108.226.1 --credentials version:3,username:snmpuser,authprotocol:sha256,authpassword:@uthp@55word,privprotocol:aes256c,privpassword:Pr1vp@55word

Anyway, I tried to update USM.pm in this new version to support other sha related digest for all the privprotocol: USM.pm-patched-v3.zip
As I can't test it myself, I hope I did no mistake on it.

[delboy1966]

Hi

If I use aes256c it fails.
looking at the regex for "my $protocols" it has

'(?:(?:cfb)?256-?)aes(?:-?128)?',

So it accepts cfb256aes.

I've tested your new version, and it works a treat.
Thanks very much for all your help.

[delboy1966]

Actually, apologise.
It does work with aes256c, I was getting confused with another fix I was working on.
But as I said, your one works fine.

[g-bougard]

I must check now if I can integrate it in GLPI-Agent code.

[g-bougard]

Here is an integration attempt: SNMP-v3-sha256-aes256-Support.zip

This archive contains 3 files:

• lib/GLPI/Agent/SNMP/Security/USM.pm is a new file to put under new lib/GLPI/Agent/SNMP/Security folder. It is intended to be loaded before Net::SNMP tries to load Net::SNMP::Security::USM.
• lib/GLPI/Agent/SNMP/Live.pm replaces the current one so it loads our update USM version before it is loaded by Net::SNMP.
• share/html/toolbox/credentials-edit.tpl replaces the ToolBox credentials edit to support new protocols. You don't need it if you don't use ToolBox interface.

You have to unzip the 3 files from the archive into your current glpi-agent installation. Can you rollback your current USM.pm module and try my GLPI-Agent integration ?

If it works as expected, I'll integrate it in nightly build so it will be added to next version. Also we will update glpi-inventory plugin to also support these protocols.

[delboy1966]

Does this version also work with aes and sha protocols?
If so, how do I reference them, as I can't get aes and sha to work.

Just we have switches that use those protocols.

Thanks

[g-bougard]

Yes, they are.

For authprotocol, accepted values should be: md5, sha (for sha1), sha224, sha256, sha384 & sha512

For privprotocol, accepted values should be: des, 3des, cfb128-aes, cfb192-aes, cfb256-aes, aes192c & aes256c

As I understood, cfb128-aes & cfb192-aes are for the "draft" version and aes192c & aes256c for the Cisco version.

[delboy1966]

I have it working now with AES and SHA.

It was strange, it worked and when I tried again directly afterwards it came back with authentication error. Tried another couple of times and same thing. Then when I tried it 20 seconds later it worked. Very strange, I'll have to do some testing when I get back into work on Monday.

I can't see it being Net::SNMP, but can't be certain, maybe connection issue? Will try from another box on Monday. Be good if someone else could try the new USM.pm file, with both sets of protocols on 2 different devices.

Doesn't glpi-agent just use Net:SNMP? So if the new USM.pm file is present it should work, shouldn't it?

I'd like to get the GLPI GUI interface changed to allow selecting AES256 and SHA256, in the Credentials interface. Not sure how that would work, as you have to specify aes256c and not aes256 on the command line.

[g-bougard]

Check my integration proposal in answer to a previous comment: #991 (reply in thread)

[delboy1966]

As soon as I get back into work on Monday, I will give it a try.

[delboy1966]

I got into work this morning and wanted to do some testing on the new USM.pm before implementing your fix for glpi-agent, because of the oddness I saw on Friday.

It works fine for SHA256 and AES256. But seeing some strange stuff when it comes to SHA and AES.

I can run unix snmp to a router that is using SHA256 and AES256 protocols with no problems, I can run it a number of time, one after the other and get a response back.
But if I run glpi-inventory or a test script using Net::SNMP it doesn't always work, I'd say 1 time in 5.

When it fails on glpi-inventory it gives the error

SNMP communication error: authentication error on host 10.108.164.1

When it fails running my test script using Net::SNMP it gives the error

_debug: [965] Net::SNMP::PDU::_process_var_bind_list(): { 1.3.6.1.6.3.15.1.1.5.0 => Counter: 185 }
error: [1065] Net::SNMP::PDU::_report_pdu_error(): Received usmStatsWrongDigests.0 Report-PDU with value 185
error: [398] Net::SNMP::Dispatcher::_transport_response_received(): Received usmStatsWrongDigests.0 Report-PDU with value 185
error: [2586] Net::SNMP::ANON(): Received usmStatsWrongDigests.0 Report-PDU with value 185 during synchronization
debug: [2636] Net::SNMP::discovery_synchronization_cb(): synchronization failed
ERROR: Received usmStatsWrongDigests.0 Report-PDU with value 185 during synchronization

I've tried from a number of different boxes and against a number of different routers, and they all give the same results.
I would be interested to see if others are getting the same results using SHA and AES protocols with glpi-inventory.
I want this to be 100% reliable as a fix, not just for me but the community using GLPI.

From my digging, and process of elimination it might be something to do with the engine ID handshake not being handled correctly in Net::SNMP. Does this make any sense?

[delboy1966]

I've been testing this most of the day, and trying to find out why its now failing most of the time using AES/SHA, and I've not found out why.

All I know is if I replace the patched version of USM.pm with the original USM.pm that came with Net::SNMP, it works everytime with the same glpi-netinvenory command line, but then we are back at square one with it not working with AES256/SHA256.

The only thing I have found that works with all protocols is unix snmp v5.9. Would it make sense to have glpi-agent and glpi inventory to use unix snmp?

[g-bougard]

Let me resume what you mean and tell me if I'm wrong somewhere:

• SHA256 and AES256 works well
• SHA and AES (i.d. SHA1 + AES128) no more works as expected as it fails randomly around 1 time in 5.
• When failing, your script reports a usmStatsWrongDigests error

As far I understand, the error means the remote device answered it didn't authenticate the sent message as the digest is wrong. I deeply reviewed the modified code and for now I don't see where is the mistake. But as perl library for SHA1 digest has been changed, maybe something is different in the logic. I must dive more deeply in that libraries, maybe I'll found something.

I guess also you didn't check if md5 digest still works or not. And also you didn't test with DES or 3DES.

[delboy1966]

Hi @g-bougard

Yes that is exactly what is happening.

No, I haven't tested with MD5, DES, or 3DES, as I have no devices to test against.

Hopefully you can find where its failing and fix it. I guess falling back to Unix SNMP isn't something you want to do?

[g-bougard]

Can you use the attached version to test if the problem could be related to how digest is handled ?
USM.pm-patched-v4-debug.zip

This version only test if hmac_sha1 is consistent with previous algorithm and will produce an error if it find something unexpected. IMHO, I just expect no error here, but who knows.

Also be careful to check you're using right username, password, authprotocol & privprotocol. I can't verify that as you didn't share the run command on last output.

[g-bougard]

I finally found the problem. With the sha protocols patch, the protocol list hash is set to:

   my $protocols = {
      '(?:hmac-)?md5(?:-96)?',           AUTH_PROTOCOL_HMACMD5,
      quotemeta AUTH_PROTOCOL_HMACMD5,   AUTH_PROTOCOL_HMACMD5,
      '(?:hmac-)?sha(?:-?1|-96)?',       AUTH_PROTOCOL_HMACSHA,
      quotemeta AUTH_PROTOCOL_HMACSHA,   AUTH_PROTOCOL_HMACSHA,
      '(?:hmac-)?sha(?:-?224)?',         AUTH_PROTOCOL_HMACSHA224,
      'usmHMAC128SHA224AuthProtocol',    AUTH_PROTOCOL_HMACSHA224,
      quotemeta AUTH_PROTOCOL_HMACSHA224,AUTH_PROTOCOL_HMACSHA224,
      '(?:hmac-)?sha(?:-?256)?',         AUTH_PROTOCOL_HMACSHA256,
      'usmHMAC192SHA256AuthProtocol',    AUTH_PROTOCOL_HMACSHA256,
      quotemeta AUTH_PROTOCOL_HMACSHA256,AUTH_PROTOCOL_HMACSHA256,
      '(?:hmac-)?sha(?:-?384)?',         AUTH_PROTOCOL_HMACSHA384,
      'usmHMAC256SHA384AuthProtocol',    AUTH_PROTOCOL_HMACSHA384,
      quotemeta AUTH_PROTOCOL_HMACSHA384,AUTH_PROTOCOL_HMACSHA384,
      '(?:hmac-)?sha(?:-?512)?',         AUTH_PROTOCOL_HMACSHA512,
      'usmHMAC384SHA512AuthProtocol',    AUTH_PROTOCOL_HMACSHA512,
      quotemeta AUTH_PROTOCOL_HMACSHA512,AUTH_PROTOCOL_HMACSHA512,
   };

I felt strange with that code when I saw it the first time. It finally triggered me when I remember the provided "sha" protocol in authprotocol params is checked to find the hash value for the protocol by running the keys list against the "sha" via a regexp... Here you have one thing to know: when getting the keys of the hash, they are not sorted and their order is totally random.
Then look carefully the keys:

    (?:hmac-)?sha(?:-?1|-96)?
    (?:hmac-)?sha(?:-?224)?
    (?:hmac-)?sha(?:-?256)?
    (?:hmac-)?sha(?:-?384)?
    (?:hmac-)?sha(?:-?512)?

... All matches the "sha" string... mixed with the random order, it means if you set just "sha" in authprotocol, USM will randomly choose between AUTH_PROTOCOL_HMACSHA, AUTH_PROTOCOL_HMACSHA224, AUTH_PROTOCOL_HMACSHA256, AUTH_PROTOCOL_HMACSHA384 or AUTH_PROTOCOL_HMACSHA512 protocol value.

So with the current USM.pm, this should work if you set authprotocol to "sha1", "sha-1" or "hmac-sha-1". With that value, the protocol can only be AUTH_PROTOCOL_HMACSHA.

Then, this is simple to fix. Here is the fixed USM which will always use AUTH_PROTOCOL_HMACSHA if authprotocol is set to "sha" without a following number: USM.pm-patched-v5.zip
For example, I replaced '(?:hmac-)?sha(?:-?256)?' by '(?:hmac-)?sha-?256'.

And here the integration into GLPI-Agent:
SNMP-v5-sha256-aes256-Support.zip

[g-bougard]

I was able to test and validate using this snmpsimulator.
It also permitted me to reproduce your last problem.

So I just published GLPI-Agent integration: next nightly build will so support newer protocols.

Next step is to prepare a PR for glpi-inventory plugin.

[delboy1966]

Hi @g-bougard

That's great news.

I'm away from my PC now, but can test in a live environment in the morning.

Once you have sorted glpi-inventory, can the GPLI GUI be updated to include the new protocols in the drop down for SNMP Credentials, so they map to the correct ones in the new USM.pm?

[g-bougard]

If you're talking about GLPI-Agent ToolBox, this is the case in current nightly build and it still was with the "SNMP-v5-sha256-aes256-Support.zip" archive where I updated the concerned html template.

For glpi-inventory plugin, as I said, I'll prepare another patch to be integrated in a future version.

Just one point, I modified the integration to only load updated USM replacement if current installed Net::SNMP library is in version 6.0.1. This is the case for recent linux distro and in MacOS & Windows builds. I don't know if it could work with older version.

[delboy1966]

This morning I copied your modified USM.pm to Net::SNMP and run glpi-netinventory with both pairs of protocols, 256 and none 256, and it was perfect, returned data every time.

I then unzipped the support zip file in the glpi-agent directory, and run the glpi-netinventory commands again, again both returned data fine.
Although I did get 2 warning messages when running the commands, even though data was returned ok.

Use of uninitialized value in split at /usr/share/glpi-agent/lib/GLPI/Agent/SNMP/Live.pm line 58.
Use of uninitialized value in string ne at /usr/share/glpi-agent/lib/GLPI/Agent/SNMP/Live.pm line 60.

Not sure if its anything to worry about.

[delboy1966]

Ah, its the version on one of our glpi boxes,.
The one running 1.13-1 gives the warning lines, the one running 1.14-2 doesn't give the warnings.

I'll update to the newer version.

[g-bougard]

Yes, the support zip file really only targets nightly builds and v1.15, but it should works also on 1.14. I'm not surprised you got an issue on 1.13.

You can also directly try latest nighty build: https://nightly.glpi-project.org/glpi-agent/

[delboy1966]

Yep, I will do that with the nightly build.

I was refering to this part of the GLPI GUI

Or will the update to glpi-inventory plugin change this?

[g-bougard]

This is glpi-inventory plugin and as I said I'll work on a patch too.

Actually, I wanted first to share the result of our work to leave a better trace here: michal-josef-spacek/Net-SNMP#2

[g-bougard]

Well, I forgot credentials support is now integrated in GLPI O:), so this will be a GLPI Patch.

[g-bougard]

Here is the patch for GLPI v10.0.19: snmpv3-protocols-glpi-update.zip

It should also work on older versions. It also fixes an issue where choosing 3-DES as privprotocol is not transmitted to glpi-agent.

[g-bougard]

I just published a PR for GLPI v10 with this patch: glpi-project/glpi#20575

[delboy1966]

Just to confirm I run this from /var/www/glpi with

patch -p0 snmpv3-protocols-glpi-update.patch

[delboy1966]

Ignore that, I got it now.
Its applied and works fine

[delboy1966]

Hi @g-bougard

Just an update for you.
I created new creds in the GLPI GUI after applying the patch and assigned it to a couple of IP Ranges that have devices using 256 protocols.
And those devices have updated in GLPI now.

So, thanks for fixing this and your patience.
Top job