[SNMP4J] AuthenticationFailure notification with invalid V3 query

[Frank Fock]

Vivi,

I do not know what you have changed. The SampleAgent as
delivered with SNMP4J-Agent sends out the authenticationFailure
trap - without any changes to the code!

Sorry, I still not understand where the problem is...

Regards,
Frank

Vivi Zhang wrote:
> Thanks, Frank.
> 
> I did enabled the authenticationFailure trap, and able receive the 
> autheticationFailure trap when receive a query with bad v1 or v2 
> community string.
> 
> The SNMPv2MIB class in SNMP4J-AGENT listens to CounterEvent for handling 
> authentication failure for bad v1 and v2 community string.
> 
> SNMP4J does send out AuthenticationFailureEvent for V3 usmWrongDigest. 
> But the SNMPv2MIB class does not listen to AuthenticationFailureEvent. 
> The current framework doesn't have the code to capture the 
> AuthenticationFailureEvent and send out the notification.
> To make it work, I extended my code to listen to 
> AuthenticationFailureEvent, and send notification from my code.
> Thank you very much for your help.
> 
> Vivi
> 
> Frank Fock wrote:
>> My statement referred to the changes made in SNMP4J-Agent 1.3.1.
>> The change log for that version states clearly that the
>> authenticationFailure trap is no longer sent for usmNotInTimeWindow
>> and usmUnknownEngineID events only.
>>
>> The authentication failure trap is generated for usmWrongDigest,
>> for example (I used the SampleAgent). How did you test it?
>> Have you enabled the authenticationFailure trap?
>>
>> Regards,
>> Frank
>>
>> Vivi Zhang wrote:
>>> Frank:
>>>
>>> I misunderstood your reply.
>>>
>>> Your following statement really means : "I have removed the 
>>> generation of the authenticationFailure trap in SNMP4J-Agent 1.3.1 to 
>>> be more robust against DoS attacks. There is no benefit from having 
>>> generated these traps. "
>>>
>>>
>>> Now, back to my original question: how could I received an 
>>> authenticationFailure trap when a V3 user send a request with bad 
>>> password, or misspelled name?  I am able to receive an authentication 
>>> failure trap when the agent receive a query with bad V1 or V2 
>>> community string.
>>>
>>> Frank Fock wrote:
>>>> Vivi,
>>>>
>>>> I have problems to follow your thoughts.
>>>> SNMP4J-Agent is already (and still) sending
>>>> out authenticationFailure traps on SNMPV3
>>>> USM errors other than unknownEngineID and
>>>> notInTimeWindow. As you wrote, these are
>>>> excluded because of discovery and to
>>>> impede DoS attacks.
>>>>
>>>> So, where exactly is the problem?
>>>>
>>>> Regards,
>>>> Frank
>>>>
>>>> Vivi Zhang wrote:
>>>>> Frank:
>>>>>
>>>>> Thanks for your response.
>>>>>
>>>>> I am curious why you took the generation of the 
>>>>> authenticationFailure trap away for V3, but not V2 nor V1 
>>>>> authentication failure notification.  I downloaded the latest agent 
>>>>> code SNMP4J-Agent1.3.2. Seems it still supports V1 and V2c 
>>>>> authenticationFailure.   Should we let user choose if he wants to 
>>>>> have authentication failure notification?
>>>>>
>>>>>  From coding point of view,
>>>>> The api MPv3::prepareDataElements() associates detail error code  
>>>>> with the msgId so that it can be put in response pdu, returns 
>>>>> SnmpConstants.SNMP_MP_USM_ERROR  in case the variable "status" is 
>>>>> not SNMPv3_USM_OK.  If the api returns error code in variable 
>>>>> "status" back to its caller,  the 
>>>>> MessageDispatcherImpl::dispatchMessage() can fire authentication 
>>>>> failure event when status are not  
>>>>> SNMPv3_USM_UNKNOWN_ENGINEID            nor 
>>>>> SNMPv3_USM_NOT_IN_TIME_WINDOW :
>>>>> switch (status) {
>>>>>        case SnmpConstants.SNMP_MP_UNSUPPORTED_SECURITY_MODEL:
>>>>>        case SnmpConstants.SNMPv3_USM_UNSUPPORTED_SECURITY_LEVEL:
>>>>>        case SnmpConstants.SNMPv3_USM_UNKNOWN_SECURITY_NAME :
>>>>>        case SnmpConstants.SNMPv3_USM_ENCRYPTION_ERROR :
>>>>>        case SnmpConstants.SNMPv3_USM_DECRYPTION_ERROR :
>>>>>        case SnmpConstants.SNMPv3_USM_AUTHENTICATION_ERROR :
>>>>>        case SnmpConstants.SNMPv3_USM_AUTHENTICATION_FAILURE :
>>>>>        {
>>>>>          AuthenticationFailureEvent event =
>>>>>              new AuthenticationFailureEvent(this, incomingAddress,
>>>>>                                             sourceTransport, status,
>>>>>                                             wholeMessage);
>>>>>          fireAuthenticationFailure(event);
>>>>>          break;
>>>>>        }
>>>>> The switch statement does not list unknown engine id nor timeliness 
>>>>> error since we don't want send out an authentication failure trap 
>>>>> for discovery.
>>>>>
>>>>> Of course, we need implement authentication failure event listener 
>>>>> registering, and calling authentication notification as we receive 
>>>>> the event.
>>>>>
>>>>> Would this help us handling the authentication failure notification?
>>>>>
>>>>> Vivi
>>>>>
>>>>> Frank Fock wrote:
>>>>>> Hi Vivi,
>>>>>>
>>>>>> I have removed the generation of the authenticationFailure
>>>>>> trap in SNMP4J-Agent 1.3.1 to be more robust against DoS
>>>>>> attacks. There is no benefit from having generated these
>>>>>> traps.
>>>>>>
>>>>>> Regards,
>>>>>> Frank
>>>>>>
>>>>>> Vivi Zhang wrote:
>>>>>>> Frank:
>>>>>>>
>>>>>>> The email was send Oct 28.  I have not seen reply yet. Guess it 
>>>>>>> got lost. Let me try it again.
>>>>>>>
>>>>>>> I am trying to verify that SNMP4J will send out an authentication 
>>>>>>> failure notification when it receives an query with bad user 
>>>>>>> name, or bad password. Is there a way to verify the notification 
>>>>>>> works with SNMP4j test agent?
>>>>>>>
>>>>>>> I found a thread of conversation between you and Marek on: 
>>>>>>> http://fixunix.com/snmp/64320-wrong-authorization-alarm-trap-usm.html./ 
>>>>>>>
>>>>>>> "Indeed, AGENT++ did not generate authenticationFailure 
>>>>>>> notifications
>>>>>>> on usmWrongDigest and usmNotInTimeWindow failures. I have fixed 
>>>>>>> that bug
>>>>>>> and you can download the new version
>>>>>>> <http://fixunix.com/#> from http://www.agentpp.com" 
>>>>>>> <http://www.agentpp.com>/
>>>>>>>
>>>>>>> I am using AgenPro 2.7.2, SNMP4J is version 1.9.3c, and 
>>>>>>> SNMP4JAgent is version 1.2.1d.  Does this version contain your 
>>>>>>> fix? Or this version contains this bug?  Is there any option I 
>>>>>>> can choose during code generation phase to make authentication 
>>>>>>> failure notification?
>>>>>>>
>>>>>>> Could you explain which error codes will trigger the notification?
>>>>>>>
>>>>>>> Thanks for your help in advance.
>>>>>>>
>>>>>>> Vivi
>>>>>>>
>>>>>>> Vivi Zhang wrote:
>>>>>>>> Frank:
>>>>>>>>
>>>>>>>> I wonder how to make a notification recipient receive an 
>>>>>>>> authenticationFailure notification when an agent received an 
>>>>>>>> query with bad user name or bad password. When agent receives a 
>>>>>>>> v2 query with bad community string, the api SNMPv2Mib:: 
>>>>>>>> incrementCounter() calls notify api and send out 
>>>>>>>> notifications.   But when the agent receives a v3 query with bad 
>>>>>>>> username,  no notification is send out.
>>>>>>>>
>>>>>>>> I am using : SNMP4J is version 1.9.3c, and SNMP4JAgent is 
>>>>>>>> version 1.2.1d.
>>>>>>>>
>>>>>>>> This is second question. According to CHANGES.txt on snmp4j site:
>>>>>>>>
>>>>>>>> [2009-07-30] v1.3.1 (Requires SNMP4J v1.10.1)
>>>>>>>> ....
>>>>>>>> * Improved: Authentication failure traps are no longer
>>>>>>>>  sent on usmNotInTimeWindow and usmUnknownEngineID
>>>>>>>>  reports.
>>>>>>>>
>>>>>>>> I am wondering why?  If a user has a bad username, would that 
>>>>>>>> cause usmNotInTimeWindow error since the second part of 
>>>>>>>> discovery requires user credential?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Vivi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com