Wrong authorization alarm (trap) in USM?
I have a question concerning SNMPv3 and its USM model. We were asked
if it is possible that an agent generates an alarm (trap) during
failed authorization (when authorized v3 message has wrong MAC code).
Our reasoning is as follows: First, such a capability would require
quite advanced logic in agent. It would be a bad idea to send such a
trap every time a message has wrong MAC (it could be caused e.g. by
transmission errors since UDP checksum, even if present, is not as
reliable as HMAC). Thus, some time/threshold limit would be needed,
otherwise agents could flood managers with such traps (during DoS
attack). Finally, we are not aware of such a standard mechanism for
Thus, it seems that the only possibility would be to periodically
check USM counters (more precisely, usmStatsWrongDigests and perhaps
other counters, like usmStatsDecryptionErrors) and react to
significant changes of their values. We will not have source IP
address of the attacker(s), but such addresses, even if provided by
agent in a trap, due to UDP, may be fake and may vary often. So they
are not too valuable.
I would be grateful for explanations.
Re: Wrong authorization alarm (trap) in USM?
Indeed, AGENT++ did not generate authenticationFailure notifications
on usmWrongDigest and usmNotInTimeWindow failures. I have fixed that bug
and you can download the new version from [url]http://www.agentpp.com[/url]
As you can add custom variable bindings to the end of a notification's vb
list, you can add the IP address of the offending message to the
although the authenticationFailure notification definition does not
standard variable bindings.
In order to be able to add your own variable binding to the
notification sent by AGENT++, you can subclass RequestList and overwrite
the RequestList::authenticationFailure method. This method is called by
when such a failure is detected, with the source address of the message and
the error code identifying the failure cause.
Hope this helps.
Marek Malowidzki wrote:
>firstname.lastname@example.org wrote in message news:<Pine.BSF.email@example.com>...
>Yes, indeed, I overlooked it (it seemed to me that something like this
>exists but I could not recall what exactly). However, there are some
>problems. First, after some discussion, we think that it could be
>valuable to have IP addresses of the attacker(s) (for reasons
>presented below). authenticationFailure operates above IP and does not
>provide anything like that (which is quite obvious, from the point of
>view of SNMP, and quite dissappointing from our point of view).
>I am not sure if a brute-force attack through a network is really
>feasible, but let's assume so (the network and agent are fast, delays
>are negligible, etc.) Then, an attacker would like to know the result
>- which attempt succeeded - so, it must specify a source IP address so
>that it could read agent's responses (in the simplest case, from its
>LAN segment). However, assuming that an attacker has read access to a
>MIB (e.g., SNMPv1 is enabled for read access), and a MIB contains a
>leaf that could be set to some arbitraty value, then this leaf'value
>could be used to find out which attack attempt succeeded (the variable
>set using random source IP addresses and then after a number of
>attempts, a single "innocent" read with SNMPv1). But in our case, we
>are interested in SNMPv3(with authentication)-only environment. Thus,
>source IP addresses could help a bit in detecting an attacker.
>Additionally, we noticed that our Agent++-based agent genetares
>authenticationFailure traps (v1 or v2c, depending on configuration)
>when we set wrong community string. But no trap is generated when we
>set invalid SNMPv3 autentication password. Is this a problem with our
>agent or is this behavior correct (i.e., agent is not required to
>generate traps when SNMPv3 is in use)?
>And one more question: in the newest RFC-3418, the description for
>authenticationFailure has been changed to "While all implementations
>of SNMP entities MAY be capable of generating this trap...". Does it
>suggest that a conformant agent may completely restrain from
>generation of these traps (when snmpEnableAuthenTraps is set to
>> 2) Generation of an authentication failure notification
>> on each failure is not a good thing due to DoS
>> 3) Other, more sophisticated approaches are needed.