Page 1 of 1

SNMPv3 Trap Receiving

PostPosted: Tue Aug 13, 2019 7:37 am
by maglaubig
I'd like to say that SNMPv3 is great for securing checks, I just wish the setup of Nagios XI for SNMPv3 trap receivers sucked less. I even went so far as to think maybe SNMPv1 was a good idea for sending traps and it all boils down to that understandable (given the SNMPv3 spec) but irritating and frustrating discovery of the EngineID of the SNMP trap sender. Wildcards for the EngineID would solve this issue, but that's against the spec of SNMPv3 from what I understand.

I ultimately put snmptrapd.service into debug mode so it would output to the screen which led me, rather indirectly through logs, to the EngineID I was looking for. To implement this in its entirety, I will have to create a user in snmptt.conf for every device I want to monitor. This is nobody's fault, just the way SNMPv3 works from what I understand.

In my case I was working with an APC PDU and to say that APC was light on documentation regarding SNMPv3 traps is being kind. Rather than putting this on a manufacturer which sells its own product for monitoring and alerting, or describing the alert configs being my bane and making me an all around sad panda, maybe there is a way NagiosXI can help?

Maybe these few ideas will lead to someone coming up with better ones.

1. In the SNMP Trap Interface page under the Admin section, have another tab for received traps that failed auth and log the sending IP and EngineID there. Even if I didn't use it to discover the EngineID, I'd like to know if my NagiosXI is ignoring traffic.

2. Another tab same in the same place as #1, build a matrix of EngineIDs that can be associated with a single SNMPv3 username and password combo (including AuthPriv).

Re: SNMPv3 Trap Receiving

PostPosted: Thu Aug 15, 2019 7:36 am
by scottwilkerson
I'll pass this to the developers to see if either of these are possible to implement in the future.