CODEWITHSUNDEEP
snmpnet-snmp
Allen McWongahey
Allen McWongahey

Reputation: 11

Having trouble with getting Enterprise traps to be encrypted with net-snmp

I am at a loss on this one.

I am using net-snmp version 5.7.3 and recently added support in the application to support SNMP v3.

SNMP GETS are working flawlessly with any combination of Auth and Priv protocol. I can see the encrypted PDU's when I capture with Wireshark and the MIB browser is able to decode and all works fine.

The problem I am having is with SNMP v3 traps. For the life of me I cannot get Enterprise traps to be encrypted. Wireshark capture shows them clearly going out in clear text.

Here is my relevant configuration:

In /etc/snmp/snmpd.conf I have:

master agentx
agentaddress udp:161
engineID 43f8513afdd8a1648e63a728be8625
rouser allenmcw priv
trapsess -v 3 -u allenmcw -a SHA -A <authPass>-x AES -X <privPass> <IP address>

In /usr/lib/snmp/snmpd.conf I have:

 usmUser 1 3 "43f8513afdd8a1648e63a728be8625" "allenmcw" "allenmcw" NULL .1.3.6.1.6.3.10.1.1.3 0x11c712fff7718594a12d2444a3356405a31b3c9c .1.3.6.1.6.3.10.1.2.4 0x11c712fff7718594a12d2444a3356405 0x
setserialno 746862596
##############################################################
#
# snmpNotifyFilterTable persistent data
#
##############################################################


    engineBoots 42
    oldEngineID "43f8513afdd8a1648e63a728be8625"

For trapsess I have tried the following variation as my understanding is that the passphrase, etc should be picked up with the usmUser entry.

trapsess -v 3 -u allenmcw -l authPriv

Note that this last option results in NO trap going out at all! The -l option should be valid based on all research I have done but it is not working for me.

It should be NOTED that the COLD start trap sent out by net-snmp itself IS getting encrypted, but NO enterprise level traps are.

I confess to being somewhat lost at this point as to what the problem could be.

Thanks for any guidance.

Allen

Upvotes: 1

Views: 490

Answers (1)

Allen McWongahey
Allen McWongahey

Reputation: 11

Have the solution. I suspect this occurred because in our environment we run a separate trap daemon to send all the enterprise traps.

Rather than have clear text passwords in the /etc/snmp/snmpd.conf the following will allow the trap daemon to use the HASHED version of the passwords which comes from /usr/lib/snmp/snmpd.conf

Here is the corrected trapsess line:

trapsess -v 3 -u allenmcw -3m 0x9d833d009db321cec1d2f1ed737bf11aff770fa1 -3M 0x9d833d009db321cec1d2f1ed737bf11a <IP address>

These hashed values were pulled from the other snmpd.conf referenced.

Upvotes: 0

Related Questions