Wrong authorization alarm (trap) in USM? - SNMP

This is a discussion on Wrong authorization alarm (trap) in USM? - SNMP ; Hi all, 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Wrong authorization alarm (trap) in USM?

  1. Wrong authorization alarm (trap) in USM?

    Hi all,

    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.


  2. Re: Wrong authorization alarm (trap) in USM?

    Hi Marek,

    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 http://www.agentpp.com

    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
    define any
    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.

    Frank Fock

    Marek Malowidzki wrote:

    >dperkins@snmpinfo.com wrote in message news:...
    >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
    >> attacks
    >> 3) Other, more sophisticated approaches are needed.


+ Reply to Thread