The SnortSnmpGuide

Glenn Mansfield Keeni,
Cyber Solutions Inc.
 

[Running snort and SNMP is a challenge, as it requires knowhow on two different systems one related to security and the other related to management. In the following we have tried to put together some guidelines that may be helpful for the beginner.]

Introduction

The snortSnmpPlugin enables snort to send snmp alerts (notifications in network management jargon) to the network managemement systems (NMS). The alerts can be traps (the alert will not be acknlowledged by the receiver) or informs (the alert will be acknowledged by the receiver). This adds significant power to the NMS by allowing it to monitor the security of the network. It also allows the snort sensor to exploit the features that are built into existing network management systems.

How it works

An SNMP notification carries information in the form of a set of name-value pairs. The names are, in management jargon, Object instance Identifiers (OID). Managed Objects (MO) are observables that are of interest to NMSs. (e.g. sensor location, alert message, attack source ...). MOs are uniquely identified by their OIDs. The MOs and their OIDs are defined in Management Information Base (MIB) modules.

The OIDs are organized in the form of a tree - the "global naming tree". each node in this tree has an identifier (something like a sibling sequence number) and a label. The identifier is unique among the siblings of a node. The concatenation of the identifiers of the nodes on the arch starting at the root and ending at a node is the OID of that node. The organization that has been assigned a node in the "global naming tree" is in charge of the subtree rooted at that node. Organizations in turn may delegate the administration of subtree(s) of the tree in their charge.

Snort.org has been assigned the unique node numbered 10234 under the enterprises node of the global naming tree. The OID of this node is 1.3.6.4.1.10234, the concatenation of the identifiers of the nodes on the arch starting from the root node to the node assigned to snort. (Going by the labels of the nodes the OID will look like iso.org.dod.internet.private.enterprises.snort). All Snort related MIBs will be defined under this node.

`

The snortMIB tree as it stands now is shown in Appendix-1.

 

Note: At present the MIB definitions are put under the experimental sub-tree - snortExp. Once we arrive at some (rough) consensus on the alerts and their contents we will move this to the snortIDS sub-tree.

The snortIDSAlertMIB

The MOs of interest have been defined in the snort intrusion detection alert MIB (snortIDSAlertMIB) described below. There are two tables and a list of Alerts. The tables are as follows.

 

sidaSensorTable: each row in this table describes a sensor application(snort). The rows are indexed by sidaSensorID - the sensor ID. sidaSensorID needs to be unique in the table ( and maybe in the security management domain, too).

 

sidaAlertTable: each row in this table describes an alert that has been generated by a sensor application. The rows are indexed by the originating sensor's ID (sidaSensorID) and the alertID needs to be unique for a sensor application

 

The sidaSensorTable contains the following Sensor related MOs.

[Objects in this table are indexed by the sidaSensorID.]

 

sidaSensorID

A unique identifier for the sensor (a number)

sidaSensorDescription

Description of the sensor

sidaSensorVersion

Version of the sensor

sidaSensorLocation

Location of the sensor

sidaSensorAddressType/span>

The Address Type of the following field

sidaSensorAddress

The Address of the sensor

sidaSensorInterfaceIndex

The ifIndex of the Interface on which sensor is sensing

sidaSensorManufacturer

The manufacturer of the Sensor

sidaSensorProductName

The name of the product

sidaSensorProductID

A pointer to the OID of the sensor

sidaSensorHashAlgorithm

The hash algorithm used to compute sidaAlertPacketPrint

 

The sidaAlertTable contains the following alert related MOs.

[Objects in this table are indexed by sidaSensorID and sidaAlertID]

 

sidaAlertID

/span>The Alert identifer (a number)

sidaAlertTimeStamp

/span>The time stamp of the alert

sidaAlertActionsTaken

/span>List of actions taken by the sensor

sidaAlertMsg

/span>Message associated with the rule that triggered the alert

sidaAlertMoreInfo

/span>Reference to more information on the alert (generally a URL).

sidaAlertSrcAddressType

/span>The address type of the following field

sidaAlertSrcAddress

/span>The address of the (apparent) source of the attack

sidaAlertDstAddressType

/span>The address type of the following field

sidaAlertDstAddress

/span>The address of the (apparent) destination of the attack

sidaAlertSrcPort

/span>The source port as seen in the attack packet

sidaAlertDstPort

/span>The destination port as seen in the attack packet

sidaAlertStartTime

/span>The time of the first attack

sidaAlertOccurrences

/span>The number of occurances of the attack since the time in sidaAlertStartTime.

sidaAlertImpact

/span>The evaluated impact of the events leading to the alert.

sidaAlertSrcAddressList

/span>The list of source addresses pertaining to this alert. This will be a null list (zero length string) if the list of source addresses are not known, not available or, not applicable

sidaAlertDstAddressList

/span>The list of destination addresses pertaining to this alert. This will be a null list (zero length string) if the list of destination addresses are not known, not available or, not applicable.

sidaAlertSrcPortList

/span>The list of source port numbers pertaining to this alert. This will be a null list (zero length string) if the list of source ports is not known, not available or, not applicable

sidaAlertDstPortList

/span>The list of destination port numbers pertaining to this alert. This will be a null list (zero length string) if the list of destination ports is not known, not available or, not applicable

sidaAlertScanDuration

/span>The duration of the scan being reported in the alert. This will have a value of -1 if the scan duration is not known, not available or, not applicable

sidaAlertScannedHosts

/span>The number of hosts scanned by the event reported in the alert. This will have a value of -1 if the number of scanned hosts is not known, not available or, not applicable

sidaAlertTCPScanCount

/span>The number of TCP scans seen inthe event reported in the alert. This will have a value of -1 if the number of TCP scans is not known, not available or, not applicable.

sidaAlertUDPScanCount

/span>The number of UDP scans seen inthe event reported in the alert. This will have a value of -1 if the number of UDP scans is notknown, not available or, not applicable

sidaAlertScanType

/span>The type of the scan Stealth or otherwise reported in the alert.

sidaAlertEventStatus

/span>The status of the event being reported in the alert. The alert may report the start or end of an event. It may also provide intermediate inProgress reports on an event

sidaAlertEventPriority

/span>The priority of the event being reported in the alert. This will have a value of -1 if the priority is not known, not available or, not applicable

sidaAlertSrcMacAddress

/span>The 802 MAC address seen in source address part of the datagram carrying packet which has caused this alert. This will be a zero length string if the source MAC address is not known, not available or, not applicable

sidaAlertDstMacAddress

/span>The 802 MAC address seen in destination address part of the datagram carrying packetwhich has caused this alert. This will be a zero length string if the destination MACaddress is not known, not available or, not applicable

sidaAlertProto

/span>The name corresponding to the protocol number seen in the header of the offending packet/datagram. In case the protocolnumber could not be interpreted the name is given as PROTONNN where NNN is the 3-digit zero-padded protocol number. This will be a zero length string if the protocol number is not known, not available or, not applicable

sidaAlertRuleID

/span>The ID of the snort rule that triggered the event. For Snort this corresponds to the Sid attribute of a signature. When unknown not available or, not applicable thevalue will be -1

sidaAlertRuleRevision

/span>The revision number ofthe rule that triggerred the event. For Snort this corresponds to the Rev attribute of a signature file. When unknown not available or, not applicable this value will be -1

sidaAlertPacketPrint

/span>The Hash of the invariant part of the packet that triggered the event. The hashing algorithm is specified in sidaSensorHashAlgorithm

 

Notifications

Presently the following notifications are supported:

 

sidaAlertGeneric-2 This is the notification sent when no specific notification is found for the event.

 

sidaAlertScanStatus-2 This notification reports that a scan is detected, in progress or terminated. The sidaScanEventStatus MO indicates the status of the scan - whether the start of a scan is detected, a scan is in progress or, a detected scan has terminated. The periodicity of the scan in progress alerts is implementation dependent.

 

The MOs in the sidaAlertGeneric-2 are

(M:Mandatory, O:Optional)

 

sidaAlertTimeStamp /span>

M

sidaAlertMsg

M

sidaAlertImpact

M

sidaSensorID

O

sidaAlertID

O

sidaAlertActionsTaken

O

sidaAlertMoreInfo /span>

O

sidaSensorAddressType

O

sidaSensorAddress

O

sidaAlertSrcAddressType

O

sidaAlertSrcAddress

O

sidaAlertDstAddressType

O

sidaAlertDstAddress

O

sidaAlertSrcPort

O

sidaAlertDstPort

O

sidaAlertEventPriority

O

sidaAlertSrcMacAddress

O

sidaAlertDstMacAddress

O

sidaAlertProto

O

sidaAlertRuleID

O

sidaAlertRuleRevision

O

sidaAlertPacketPrint

O

 

 

The MOs in the sidaAlertScanStatus-2 are

/span>(M:Mandatory, O:Optional)

 

/span>sidaAlertTimeStamp

M

/span>sidaAlertMsg

M

/span>sidaAlertImpact

M

/span>sidaAlertScanType

M

/span>sidaAlertEventStatus

M

/span>sidaSensorID

O

/span>sidaAlertID

O

/span>sidaAlertActionsTaken

O

/span>sidaAlertMoreInfo

O

/span>sidaSensorAddressType

O

/span>sidaSensorAddress

O

/span>sidaAlertSrcAddressType

O

/span>sidaAlertSrcAddress

O

/span>sidaAlertDstAddressType

O

/span>sidaAlertDstAddress

O

/span>sidaAlertSrcPort

O

/span>sidaAlertDstPort

O

/span>sidaAlertDstAddressList

O

/span>sidaAlertDstPortList

O

/span>sidaAlertEventPriority

O

/span>sidaAlertScanDuration

O

/span>sidaAlertScannedHosts

O

/span>sidaAlertTCPScanCount

O

/span>sidaAlertUDPScanCount

O

/span>sidaAlertSrcMacAddress

O

/span>sidaAlertDstMacAddress

O

/span>sidaAlertProto

O

/span>sidaAlertRuleID

O

/span>sidaAlertRuleRevision

O

/span>sidaAlertPacketPrint

O

 

If you are wondering why the sensorID and the alertID are optional, those values are present as part of the indices in the instance OID of every MO. Refer to the example below if you are still in doubt.

 

Note: Mandatory MOs and Optional MOs

 

Two categories of MOs are defined for the notifications.
The mandatory MOs will *always* be included in the notification and in the same
order as inwhich they appear in the definition of the corresponding NOTIFICATION object in the SNORT-ID-ALERT-MIB.

 

If the true value of a mandatory MO is unavailable (or unknown) an appropriate value will be assignedto the MO to indicate that. [Refer to the SNORT-ID-ALERT-MIB definitions in the MIBs directory for the default values of the MOs]

 

The handling of the optional MOs depends on the trap_snmp plugin options.

-         By default, all the MOs will be present in the notification. If the true value of an MO is not available or is unknown, a preassigned value will be supplied to indicate that. The place and order of the MOsin the notification is fixed.

[These notifications have the advantages of being fixed format and the disadvantage of being unnecessarily large.]

-         if the compact option 'c' is given as a parameter to the snmptrap-plugin, the MOs for which the values are unknown or not available will not be present in the

/span> notification. The ordering of the MOs does not change - but the place of the MOs

may change. [These notifications have the advantage of being compact (there

are no MOs without meaningful values in the notification) and the disadvantage of

being variable format.(variable format should not be a problem as an SNMP

notifications always contains the information in MO-Value pairs)]

 

The MIB implementation

There are two aspects of the MIB implementation.

In the simple case we just want to send SNMP alerts to a NMS or a Network Security Manager. This is simple because snort does the detection stuff and calls the snmpPlugin module to generate the corresponding snmp alert packet with the appropriate OID-value pairs. The snmp alert packet is then sent to the NMS.

 

In the more advanced case we may want an agent that interfaces with snort. This agent may manage the snort alert log database and respond toqueries from an NMS [or, maybe even to commands to control snort from the NMS]. Examples of such queries are -


What is the sensor location?

What is the interface the sensor is listening on ?

What were the actions taken by the sensor for alert AlertID nnn.


More ambitiously, the NMS may even command the agent to make snort reload a new set of signatures, and restart!

 

The present snortSnmpPlugin package does not contain such an agent implementation but it is really simple to do that. The relaease of that agent is slated for some future date

The Actual communication:

The actual communication between the snort and the NMS will use the Simple Network Management Protocol. There are two versions ofSNMP that are supported

Community-based SNMP version 2(SNMPv2C) and SNMP version 3 (SNMPv3).

Different levels of security are available to the user/administrator depending on the

version of the SNMP used.

In the least secure case -

SNMPv2c or,

SNMPv3 with no authentication and no privacy

plaintext password type access control is carried out.

In the most secure case -

SNMPv3 with authentication and privacy

stronger authentication using user/administrator specified authentication protocols

(SHA, MD5) and authentication passphrasesand,

privacy using user/administrator specified privacy protocols (DES) and

privacy passphrases is possible.

The security level selection will depend on the network and will require configuration of

the SNMP entities. (snort via snort.conf, and snmptrapd via. snmptrapd.conf).

Setting up Snort for generating SNMP alerts

You will need to set up the snort.conf with the appropriate parameters for snmp alert generation.

 

The SnmpTrapGenerator outputplugin requires several parameters.The parameters depend on the SNMP version that is used (and specified).

 

The general format of the snort.conf entry for the snortSnmp Plugin is

 

output trap_snmp: alert, <sensorID>, [NotificationOptions] {trap|inform} -v

<SnmpVersion> <Snmp Parameters>

 

where,

'alert' indicates that the alert facility of snort will be used.

<sensorID> is the identifier that uniquely identifies the snort application.

[NotificationOptions] are [c],[p[m|s]]

c : Generate compact notifications.

(Saves on bandwidth by not reporting MOs for which values are unknown, not

available or, not applicable. For details see below.)

By default this option is reset.

p : Generate a print of the invariant part of the offending packet. This can be

used to track the packet across the Internet.

By default this option is reset.

m : Use the MD5 algorithm to generate the packet print.

By default this algorithm is used.

s : Use the SHA1 algorithm to generate the packet print.

{trap|inform} indicates whether a trap is to be generated or an inform is to be

generated. <SnmpVersion> indicates the version of SNMP that is to be used. The

subsequent parameters depend on the SNMP version.

 

For SNMPv2c traps to

trap destination= myTrapListener

port=162

community = myCommunity

 

The snort.conf entry will be

 

/span> output trap_snmp: alert, 7, trap -v 2c -p 162myTrapListener myCommunity

/span>

For SNMPv2c informs to the same destination the snort.conf entry will be

 

output trap_snmp: alert, 7, inform -v 2c -p 162 myTrapListener myCommunity

 

With the compact option and the packet print option set for the samedestination the

snort.conf entry will be

/span>

output trap_snmp: alert, 7, cp, inform -v 2c -p 162 myTrapListener myCommunity

/span>

For SNMPv3 traps with

security name = snortUser

security level= authentication and privacy

authentication parameters :

authentication protocol = SHA ,

authentication pass phrase = SnortAuthPassword

privacy (encryption) parameters

privacy protocol = DES,

privacy pass phrase = SnortPrivPassword

trap destination= myTrapListener

 

the snort.conf entry will be (in one continuous line):

/span>

output trap_snmp: alert, 7, trap -v 3 -p 162 -u snortUser -l authPriv

-a SHA -A SnortAuthPassword -x DES -X SnortPrivPassword myTrapListener

/span>

For SNMPv3 informs with the same parameters the snort.conf entry will be

(in one continuous line):

output trap_snmp: alert, 7, inform -v 3 -p 162 -u snortUser -l authPriv

-a SHA -A SnortAuthPassword -x DES -X SnortPrivPassword myTrapListener

 

 

Setting up the Snmptrapd to receive the SnortSNMPAlerts

In the following we will refer to the snmptrapd application that comes with ucd-snmp package. We assume that it is installed in the default location and with the default configuration.

If you have snmptrapd from some other package refer to the relevant documentation. The

following discussion will not apply. {It will give you a general idea of the configuration

that you will need for the snmptrapd]

/span>

/span>1) SNMPv2c configuration

The default configuration will suffice. There are no specific controls or constraints for

receiving traps/informs.

However if you want to specify traphandlers to the snmptrapdsee (3) below.

 

/span>2) SNMPv3 configuration

You will need to configure the snmptrapd with the appropriate security users and

security levels

The security users and parameters are specified in the snmptrapd.conf file

(generally /var/ucd-snmp/snmptrapd.conf)

 

e.g. to make a user snortUser with security level ""authNoPriv" i.e.authentication will be

carried out but there will be no privacy

(encryption) - you will need to add the following line in /var/ucd-snmp/snmptrapd.conf:

/span>createUser snortUser {MD5|SHA} SnortAuthPassword

 

You need to choose between MD5 and SHA. SnortAuthPassword is the

secret pass phrase that will be used to authenticate snort to the

snmptrapd.

 

If securitylevel is "authPriv", then add the line

 

createUser snortUser {MD5|SHA} SnortAuthPassword DES SnortPrivPassword

 

Note: a. SNMPv3 pass phrases must be at least 8 characters long!

b. The snmptrapd will do the user creation and generate the keys from the

/span>passphrases. The entry in the /var/ucd-snmp/snmptrapd.conf containing the

secrets will be replaced with the entry containing the generated keys.

/span>3) If you want to configure your snmptrapd to pass on alerts of specific types to specific

handlers (scripts) you will need to edit the

snmptrapd.conf file (generally /usr/local/share/snmp/snmptrapd.conf).

Please refer to section "How do I handle traps and notifications?"

in http://www.net-snmp.org/FAQ.html. or the snmpdtrapd.conf manpages.

 

/span>4) Start snmptrapd

 

snmptrapd -P -Os

 

This will print the received alerts on the standard output:

 

Sample output

For AlertID = 7 from SensorID 7 the alert printed on the console by a ucd-snmp snmptrapd started with options (snmptrapd -P -Os ) will be something like

2001-08-01 21:21:00 megahira.priv.cysol.co.jp [192.168.0.11]:

sysUpTime.0= Timeticks: (52918825) 6 days, 2:59:48.25

snmpTrapOID.0= OID: sidaAlertGeneric

sidaSensorVersion.7 = Snort! <*- Version 1.8-RELEASE (Build 43)

sidaSensorAddressType.7.7 = unknown(0)

sidaSensorAddress.7.7 = "== NA =="

sidaAlertTimeStamp.7.7 = 996668460. 98668

sidaAlertMsg.7.7 = Scan

sidaAlertMoreInfo.7.7 = Protocol: ICMP

sidaAlertSrcAddressType.7.7 = ipv4(1)

sidaAlertSrcAddress.7.7 = "nnn.mmm.qqq.rr"

sidaAlertDstAddressType.7.7 = ipv4(1)

sidaAlertDstAddress.7.7 = "192.168.0.11"

/span>

[Unfortunately the actual display may not be as neatly formatted as above - some versions do not provide line breaks.]

 

REFERENCES

rfc1901Introduction to Community-based SNMPv2. SNMPv2 Working Group,

J. Case, K. McCloghrie, M. Rose & S. Waldbusser. January 1996.

rfc2574User-based Security Model (USM) for version 3 of the Simple

Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen.

April 1999.

ucd-snmp http://net-snmp.sourceforge.net/

snort http://www.snort.org/

 


Appendix-1

/span>[ This figure is autogenerated using the snmptranslate application that

comes with the ucd-snmp package]

 

+--snortMIB(10234)

|

+--snortIDS(1)

|

+--snortExp(2)

|

/span>+--snortIDSAlertMIB(1)

|

+--sidaSensorTable(1)

||

| +--sidaSensorEntry(1)

| |Index: sidaSensorID

| |

| +-- -R-- Integer32 sidaSensorID(1)

| |Range: 1..2147483647

| +-- -R-- StringsidaSensorDescription(2)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- StringsidaSensorVersion(3)

| |Textual Convention: SnmpAdminString

| | /span>Size: 0..255

| +-- -R-- StringsidaSensorLocation(4)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- EnumVal sidaSensorAddressType(5)

| |Textual Convention: InetAddressType

| |Values: unknown(0), ipv4(1), ipv6(2), dns(16)

| +-- -R-- StringsidaSensorAddress(6)

| |Textual Convention: InetAddress

| |Size: 0..255

| +-- -R-- Integer32 sidaSensorInterfaceIndex(7)

| |Textual Convention: InterfaceIndex

| |Range: 1..2147483647

| +-- -R-- StringsidaSensorManufacturer(8)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- StringsidaSensorProductName(9)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- ObjID sidaSensorProductID(10)

| +-- -R-- EnumVal sidaSensorHashAlgorithm(11)

|Values: other(1), md5(2), sha1(3), ripeMd160(4)

|

+--sidaAlertTable(2)

||

|+--sidaAlertEntry(1)

| |Index: sidaSensorID, sidaAlertID

| |

| +-- -R-- Integer32 sidaAlertID(1)

| |Range: 1..2147483647

| +-- -R-- StringsidaAlertTimeStamp(2)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- BitString sidaAlertActionsTaken(3)

| |Values: none(0), logged(1), alerted(2), blocked(3), tagged(4), tcpRstToSender(16), cpRstToReceiver(18), tcpRstToSenderAndReceiver(19), icmpNetUnreachToSender(20), icmpHostUnreachToSender(21), icmpPortUnreachToSender(22), icmpAllUnreachToSender(23)

| +-- -R-- StringsidaAlertMsg(4)

| | /span>Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- StringsidaAlertMoreInfo(5)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- EnumVal sidaAlertSrcAddressType(6)

| |Textual Convention: InetAddressType

| |Values: unknown(0), ipv4(1), ipv6(2), dns(16)

| +-- -R-- StringsidaAlertSrcAddress(7)

| |Textual Convention: InetAddress

| |Size: 0..255

| +-- -R-- EnumVal sidaAlertDstAddressType(8)

| |Textual Convention: InetAddressType

| |Values: unknown(0), ipv4(1), ipv6(2), dns(16)

| +-- -R-- StringsidaAlertDstAddress(9)

/span>| |Textual Convention: InetAddress

| |Size: 0..255

| +-- -R-- Integer32 sidaAlertSrcPort(10)

| +-- -R-- Integer32 sidaAlertDstPort(11)

| +-- -R-- StringsidaAlertStartTime(12)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- Counter sidaAlertOccurrences(13)

| +-- -R-- EnumVal sidaAlertImpact(14)

| |Values: unknown(1), badUnknown(2), notSuspicious(3), attemptedAdmin(4), successfulAdmin(5), attemptedDos(6), successfulDos(7), attemptedRecon(8), successfulReconLimited(9), successfulReconLargescale(10), attemptedUser(11), successfulUser(12)

| +-- -R-- StringsidaAlertSrcAddressList(15)

| |Textual Convention: SidaInetAddrList

| |Size: 0..1024

| +-- -R-- StringsidaAlertDstAddressList(16)

| |Textual Convention: SidaInetAddrList

| |Size: 0..1024

| +-- -R-- StringsidaAlertSrcPortList(17)

| |Textual Convention: SidaPortList

| |Size: 0..1024

| +-- -R-- StringsidaAlertDstPortList(18)

| |Textual Convention: SidaPortList

| |Size: 0..1024

| +-- -R-- Counter sidaAlertScanDuration(19)

| +-- -R-- Counter sidaAlertScannedHosts(20)

| +-- -R-- Counter sidaAlertTCPScanCount(21)

| +-- -R-- Counter sidaAlertUDPScanCount(22)

| +-- -R-- EnumVal sidaAlertScanType(23)

| |Values: unknown(0), other(1), stealth(2)

| +-- -R-- EnumVal sidaAlertEventStatus(24)

| |Values: unknown(1), start(2), inProgress(3), end(4)

| +-- -R-- Integer32 sidaAlertEventPriority(25)

| +-- -R-- StringsidaAlertSrcMacAddress(26)

| |Textual Convention: MacAddress

| |Size: 6

| +-- -R-- StringsidaAlertDstMacAddress(27)

| |Textual Convention: MacAddress

| |Size: 6

| +-- -R-- StringsidaAlertProto(28)

| |Textual Convention: SnmpAdminString

| |Size: 0..255

| +-- -R-- Integer32 sidaAlertRuleID(29)

| +-- -R-- Integer32 sidaAlertRuleRevision(30)

| +-- -R-- StringsidaAlertPacketPrint(31)

|Textual Convention: SnmpAdminString

|Size: 0..255

|

+--sidaAlertTypes(3)

||

| +--sidaAlertGeneric(1)

| +--sidaAlertScanStatus(2)

| +--sidaAlertGeneric-2(3)

|+--sidaAlertScanStatus-2(4)

|

+--sidaConformance(4)

|

+--sidaGroups(1)

||

| +--sidaAlertGroup(1)

||

| +--sidaNotificationGroup(2)

|

+--sidaCompliances(2)

|

+--sidaAlertCompliance(1)