Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 18141 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Astaro SNMP Trap OIDs

firebear_01
Hi all (espacially all Support employees of Sophos),
there are some posts to this but no Solution:
In the SNMP traps send by the UTM (9.104-17 and all earlier Versions) the strukture of the Packets seems to have a problem.
The OID in the Value-Section of the trap send from an UTM9, wich is taken maybe by snmptt, for example is iso.3.6.1.4.1.9789.0.1500 for a failed ssh login (wich seems wrong).
In the Ent-Value-Section (wich is an extension only in my understanding) the UTM is sending the right OID for example iso.3.6.1.4.1.9789.1500.2.6 wich is the right OID for  a failed ssh login.
In the MIB downloadable from the UTM it is correct. But snmptt says it is an unknown trap because of the above behavior.
Since the year 2005 there are posts in this Forum but no Solution.
Could anyone explain this ?
Has anybody running snmptt with an Sophos UTM?

Output of snmptt in snmpttunknown.log:


Thu Aug 15 20:33:16 2013: Unknown trap (iso.3.6.1.4.1.9789.0.1500) received from astaro.anyone.de at: 
Value 0: astaro.anyone.de
Value 1: 192.168.250.250
Value 2: 5:23:06:46.00
Value 3: iso.3.6.1.4.1.9789.0.1500
Value 4: 192.168.250.250
Value 5: 
Value 6: 
Value 7: 
Value 8: 
Value 9: 
Value 10: 
Ent Value 0: iso.3.6.1.4.1.9789.1500.2.6=[astaro.anyone.de][WARN][006]
Ent Value 1: iso.3.6.1.6.3.18.1.3.0=192.168.250.250
Ent Value 2: iso.3.6.1.6.3.18.1.4.0=public
Ent Value 3: iso.3.6.1.6.3.1.1.4.3.0=iso.3.6.1.4.1.9789


and in the MIB of Astaro (downloaded from 9.104-17)


#
EVENT WARN-006 iso.3.6.1.4.1.9789.1500.2.6 "Status Events" Normal
FORMAT Failed SSH login $*
SDESC
Failed SSH login
Variables:
EDESC
#


Yes i know this maybe is a case for the Sophos Support - but not if i am the only one with this Problem.

Thanks
firebear


This thread was automatically locked due to age.
  • 0
    Can you confirm via packet capture that the UTM is actually sending an extra .0 in the OID? I just tested locally, and the message being sent by my UTM is exactly this: "1.3.6.1.4.1.9789.1500.2.6"
  • 0
    Hi,
    I've solved the problem modifying the source code of snmptt, adding a special condition for Astaro :

      $var[0] = $tempvar[0];                # hostname
      $var[1] = $tempvar[1];                # ip address
      $var[2] = $tempvar[3];                # uptime
      $var[3] = $tempvar[5];                # trapname / OID - assume first value after uptime is
              # the trap OID (value for .1.3.6.1.6.3.1.1.4.1.0)

      # Astaro
      print "Astaro\n";
      if ($tempvar[5] eq ".1.3.6.1.4.1.9789.0.1500") {
            $var[3] = $tempvar[6];
      }

      $var[4] = "";  # Clear ip address from trap agent
      $var[5] = "";  # Clear trap community string
      $var[6] = "";  # Clear enterprise
      $var[7] = "";  # Clear securityEngineID
      $var[8] = "";  # Clear securityName
      $var[9] = "";  # Clear contextEngineID
      $var[10] = ""; # Clear contextName
  • 0
    Seems like an snmptt parsing issue...
  • 0 in reply to giuliano37
    Hi,
    I've solved the problem modifying the source code of snmptt, adding a special condition for Astaro :
      # Astaro
      print "Astaro\n";
      if ($tempvar[5] eq ".1.3.6.1.4.1.9789.0.1500") {
            $var[3] = $tempvar[6];
      }



    Same problem here (9.208-8), thanks for the fix.
  • 0
    Hi,

    This fix is working for Nagios.

    But i cant make it work with Centreon (FAN 2.4).

    Here what i get from the unknowntrap log :

    Without the fix : 

    Thu Mar  5 12:09:00 2015: Unknown trap (.1.3.6.1.4.1.9789.1500) received from 192.168.1.83 at:
    Value 0: 192.168.1.83
    Value 1: 192.168.1.83
    Value 2: 0:21:59:17.00
    Value 3: .1.3.6.1.4.1.9789.1500
    Value 4: 192.168.1.83
    Value 5:
    Value 6:
    Value 7:
    Value 8:
    Value 9:
    Value 10:
    Ent Value 0: .1.3.6.1.4.1.9789.1500.1.5=[labutm.lab.local][INFO][005]


    After the fix :

    # Astaro
    print "Astaro\n";
    if ($tempvar[5] eq ".1.3.6.1.4.1.9789.1500") {
    $var[3] = $tempvar[6];
    }

    Thu Mar  5 14:33:41 2015: Unknown trap (.1.3.6.1.4.1.8072.4.0.2) received from 192.168.1.83 at:
    Value 0: 192.168.1.83
    Value 1: 192.168.1.83
    Value 2: 0:0:00:02.52
    Value 3: .1.3.6.1.4.1.8072.4.0.2
    Value 4: 192.168.1.83
    Value 5: public
    Value 6: .1.3.6.1.4.1.8072.4
    Value 7:
    Value 8:
    Value 9:
    Value 10:

    Something's really messed up.

    Does anyone know how to make it work with Centreon?

    Can anyone share the good/modified files?
  • 0
    Same problem with 9.315-2 any solutions?
Unfiltered HTML