|
The SnortSnmpGuideGlenn 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.] IntroductionThe 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 worksAn 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 snortIDSAlertMIBThe 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.]
The sidaAlertTable contains the following alert related MOs. [Objects in this table are indexed by sidaSensorID and sidaAlertID]
NotificationsPresently 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)
The MOs in the sidaAlertScanStatus-2 are /span>(M:Mandatory, O:Optional)
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. 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 interface the sensor is listening
on ? What were the actions taken by the sensor for
alert AlertID nnn.
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) |
|