RFC 5676
Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
📜 RFC 5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications 💖
Network Working Group 🌸 Request for Comments: 5676
Authors: J. Schoenwaelder (Jacobs University Bremen), A. Clemm (Cisco Systems), and A. Karmakar (Cisco Systems India Pvt Ltd) 🧚
Category: Standards Track ✨ Date: October 2009 📅
Obsoletes and updates: the header doesn't list any RFCs that this one obsoletes or updates. 🫶
Abstract ✨
Okay so this memo defines a portion of the Management Information Base (MIB), which is the info store that network management protocols use across the Internet community. 🦋 Specifically, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. Iconic. 💅
Status of This Memo 🎀
This document is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements. 🙈 For the standardization state and status of this protocol, check the current "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌈
Copyright Notice 💜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please actually read these, bestie, because they describe your rights and restrictions for this document. 📖 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, same as described in the BSD License. 🔥
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . . 2
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Relationship to Other MIB Modules . . . . . . . . . . . . . . 4
6. Relationship to the SNMP Notification to SYSLOG Mapping . . . 6
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 211. Introduction 🦋
Okay, so SNMP ([RFC3410], [RFC3411]) and SYSLOG [RFC5424] are two widely used protocols for communicating event notifications. 💖 Co-existence of several management protocols in one operational environment is possible, but some environments need every event notification to be collected by a single system daemon, like a SYSLOG collector or an SNMP notification receiver, through one single management protocol. 🎀 In those environments, event notifications have to be translated between management protocols. Main character problem, honestly. ✨
This document defines an SNMP MIB module that represents SYSLOG messages, and it sends SYSLOG messages as SNMP notifications to SNMP notification receivers. 🌸
2. The Internet-Standard Management Framework 🧚
If you want a detailed overview of the documents describing the current Internet-Standard Management Framework, look at section 7 of RFC 3410 [RFC3410]. 📚
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). 💅 Objects in the MIB are defined using the mechanisms of the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. 🫶
3. Conventions 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔥
4. Overview 🌈
SYSLOG messages get translated to SNMP by a SYSLOG-to-SNMP translator. This translator acts as a SYSLOG collector [RFC5424] and implements a MIB module according to the SNMP architecture [RFC3411]. 🧚 The translator might be tightly coupled to an SNMP agent, or it might interface with an SNMP agent through a subagent protocol. 🦋
After initialization, the SYSLOG-to-SNMP translator listens for SYSLOG messages. When it receives a message, the message is parsed to extract information as described in the MIB module. A conceptual table gets populated with information pulled from the SYSLOG message, and then a notification may be generated. ✨
The MIB module is organized into a group of scalars and two tables. The syslogMsgControl group contains two scalars: one controls the maximum size of SYSLOG messages recorded in the tables, and the other controls whether SNMP notifications are generated for SYSLOG messages. 💖
--syslogMsgObjects(1)
|
+--syslogMsgControl(1)
|
+-- Unsigned32 syslogMsgTableMaxSize(1)
+-- TruthValue syslogMsgEnableNotifications(2)The syslogMsgTable has one entry for each recorded SYSLOG message. The basic fields of SYSLOG messages, along with message properties, are represented in different columns of the conceptual table. 🌸
--syslogMsgObjects(1)
|
+--syslogMsgTable(2)
|
+--syslogMsgEntry(1) [syslogMsgIndex]
|
+-- Unsigned32 syslogMsgIndex(1)
+-- SyslogFacility syslogMsgFacility(2)
+-- SyslogSeverity syslogMsgSeverity(3)
+-- Unsigned32 syslogMsgVersion(4)
+-- SyslogTimeStamp syslogMsgTimeStamp(5)
+-- DisplayString syslogMsgHostName(6)
+-- DisplayString syslogMsgAppName(7)
+-- DisplayString syslogMsgProcID(8)
+-- DisplayString syslogMsgMsgID(9)
+-- Unsigned32 syslogMsgSDParams(10)
+-- OctetString syslogMsgMsg(11)The syslogMsgSDTable has one entry for each structured data element parameter contained in a SYSLOG message. Since structured data elements are optional, the relationship between the syslogMsgTable and the syslogMsgSDTable ranges from one-to-zero to one-to-many. 🍓
--syslogMsgObjects(1)
|
+--syslogMsgSDTable(3)
|
+--syslogMsgSDEntry(1) [syslogMsgIndex,
| syslogMsgSDParamIndex,
| syslogMsgSDID,
| syslogMsgSDParamName]
|
+-- Unsigned32 syslogMsgSDParamIndex(1)
+-- DisplayString syslogMsgSDID(2)
+-- DisplayString syslogMsgSDParamName(3)
+-- SyslogParamValueString syslogMsgSDParamValue(4)5. Relationship to Other MIB Modules 💜
The NOTIFICATION-LOG-MIB [RFC3014] provides a generic mechanism for logging SNMP notifications, so that lost SNMP notifications can be dealt with, for example after transient communication problems. Applications can poll the notification log to check that they haven't missed important SNMP notifications. 👑
The MIB module defined in this memo provides a mechanism for logging SYSLOG notifications. This extra SYSLOG notification log exists because (a) SYSLOG messages might not lead to an SNMP notification (this is configurable), and (b) SNMP notifications might not carry all the information associated with a SYSLOG notification. 🧚
The MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], SNMP-FRAMEWORK-MIB [RFC3411], and SYSLOG-TC-MIB [RFC5427]. 🎀
The textual convention SyslogParamValueString uses the UTF-8 transformation format of the ISO/IEC IS 10646-1 character set, which is defined in [RFC3629]. 🌈
6. Relationship to the SNMP Notification to SYSLOG Mapping 🦋
A companion document, [RFC5675], defines a mapping of SNMP notifications to SYSLOG messages. This section talks about the possibilities of using both specifications together. ✨
A SYSLOG collector that implements the SYSLOG-MSG-MIB module and the mapping of SNMP notifications to SYSLOG messages may be configured to translate received SYSLOG messages that contain SNMP notifications back into the original SNMP notification. In this case, the relevant tables of the SYSLOG-MSG-MIB won't be populated for SYSLOG messages carrying SNMP notifications. This setup lets operators build a forwarding chain where SNMP notifications are "tunneled" through SYSLOG messages. 🚇 Because of size restrictions on SYSLOG transports, plus the more verbose textual encoding SYSLOG uses, the SNMP notification content might get truncated when it's tunneled through SYSLOG, so the resulting SNMP notification may be incomplete. 💀
An SNMP management application that supports the SYSLOG-MSG-MIB and the mapping of SNMP notifications to SYSLOG messages may process information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message representing the SYSLOG message recorded in the SYSLOG-MSG-MIB module. This setup lets operators build a forwarding chain where SYSLOG messages are "tunneled" through SNMP messages. A notification receiver can work out whether a syslogMsgNotification contained all the structured data element parameters of a SYSLOG message. 🔍 If parameters are missing, a forwarding application MUST retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular polling of the SYSLOG-MSG-MIB can take care of any lost SNMP notifications. 🫶
7. Definitions 💅
SYSLOG-MSG-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString, TruthValue
FROM SNMPv2-TC
OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE
FROM SNMPv2-CONF
SyslogFacility, SyslogSeverity
FROM SYSLOG-TC-MIB;
syslogMsgMib MODULE-IDENTITY
LAST-UPDATED "200908130800Z"
ORGANIZATION "IETF OPSAWG Working Group"
CONTACT-INFO
"Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de>
Jacobs University Bremen
Campus Ring 1
28757 Bremen
Germany
Alexander Clemm
<alex@cisco.com>
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Anirban Karmakar
<akarmaka@cisco.com>
Cisco Systems India Pvt Ltd
SEZ Unit, Cessna Business Park,
Sarjapur Marathahalli ORR,
Bangalore, Karnataka 560103
India"
DESCRIPTION
"This MIB module represents SYSLOG messages as SNMP objects.
Copyright (c) 2009 IETF Trust and the persons identified as
authors of the code. All rights reserved.🦋 to be continued in part 2, bestie 💖
okay so we're still in the MIB module, and this bit is the license fine print at the end of the MODULE-IDENTITY description 🙈 it's legal stuff, but the REVISION line is cute because it's just the one initial version, lowkey iconic 🎀
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 5676; see
the RFC itself for full legal notices."
REVISION "200908130800Z"
DESCRIPTION
"Initial version issued as part of RFC 5676."
::= { mib-2 192 }
-- textual convention definitionsokay now the textual conventions, and the first one is giving DateAndTime energy 💖 it's basically the same vibe, except the subseconds go down to microseconds instead of deciseconds, and a zero-length string is allowed to mean "no value here" ✨ the table below breaks down every single field, so read it slowly bestie 🧚
SyslogTimeStamp ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d"
STATUS current
DESCRIPTION
"A date-time specification. This type is similar to the
DateAndTime type defined in the SNMPv2-TC, except the
subsecond granulation is microseconds instead of
deciseconds and a zero-length string can be used
to indicate a missing value.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8-10 microseconds* 0..999999
8 11 direction from UTC '+' / '-'
9 12 hours from UTC* 0..13
10 13 minutes from UTC 0..59
* Notes:
- the value of year is in network-byte order
- the value of microseconds is in network-byte order
- daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone
information (fields 11-13) is not present."
SYNTAX OCTET STRING (SIZE (0 | 10 | 13))the second one is SyslogParamValueString, and it's all about UTF-8 📚 the vibe is "expect literally any code point from 0x00000000 to 0x7fffffff, but malformed or overlong byte sequences are NOT it" 🙅♀️ the bit about characters vs octets is so important because the length is counted in bytes, not letters, so a single emoji 🦋 can take up several octets
SyslogParamValueString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "65535t"
STATUS current
DESCRIPTION
"The value of a SYSLOG SD-PARAM is represented using the
ISO/IEC IS 10646-1 character set, encoded as an octet string
using the UTF-8 transformation format described in RFC 3629.
Since additional code points are added by amendments to the
10646 standard from time to time, implementations must be
prepared to encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not correspond to the
valid UTF-8 encoding of a code point or that are outside this
range are prohibited. Similarly, overlong UTF-8 sequences
are prohibited.
UTF-8 may require multiple bytes to represent a single
character / code point; thus, the length of this object in
octets may be different from the number of characters
encoded. Similarly, size constraints refer to the number of
encoded octets, not the number of characters represented by
an encoding."
REFERENCE
"RFC 3629: UTF-8, a transformation format of ISO 10646"
SYNTAX OCTET STRINGnow the object definitions 🎀 this is where the actual MIB objects live, and they're grouped under syslogMsgMib with notifications, objects, and conformance branches, plus a control subtree for the table limit and the on/off switch 💜 the table itself is basically a rolling buffer of recent SYSLOG messages, and the index is a counter that wraps around 🌸
-- object definitions
syslogMsgNotifications OBJECT IDENTIFIER ::= { syslogMsgMib 0 }
syslogMsgObjects OBJECT IDENTIFIER ::= { syslogMsgMib 1 }
syslogMsgConformance OBJECT IDENTIFIER ::= { syslogMsgMib 2 }
syslogMsgControl OBJECT IDENTIFIER ::= { syslogMsgObjects 1 }
syslogMsgTableMaxSize OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of SYSLOG messages that may be held in
syslogMsgTable. A particular setting does not guarantee that
there is sufficient memory available for the maximum number
of table entries indicated by this object. A value of 0 means
no fixed limit.
If an application reduces the limit while there are SYSLOG
messages in the syslogMsgTable, the SYSLOG messages that are
in the syslogMsgTable for the longest time MUST be discarded
to bring the table down to the new limit.
The value of this object should be kept in nonvolatile
memory."
DEFVAL { 0 }
::= { syslogMsgControl 1 }
syslogMsgEnableNotifications OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether syslogMsgNotification notifications are
generated.
The value of this object should be kept in nonvolatile
memory."
DEFVAL { false }
::= { syslogMsgControl 2 }
syslogMsgTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslogMsgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing recent SYSLOG messages. The size of the
table is controlled by the syslogMsgTableMaxSize object."
::= { syslogMsgObjects 2 }
syslogMsgEntry OBJECT-TYPE
SYNTAX SyslogMsgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry of the syslogMsgTable."
INDEX { syslogMsgIndex }
::= { syslogMsgTable 1 }
SyslogMsgEntry ::= SEQUENCE {
syslogMsgIndex Unsigned32,
syslogMsgFacility SyslogFacility,
syslogMsgSeverity SyslogSeverity,
syslogMsgVersion Unsigned32,
syslogMsgTimeStamp SyslogTimeStamp,
syslogMsgHostName DisplayString,
syslogMsgAppName DisplayString,
syslogMsgProcID DisplayString,
syslogMsgMsgID DisplayString,
syslogMsgSDParams Unsigned32,
syslogMsgMsg OCTET STRING
}
syslogMsgIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A monotonically increasing number used to identify entries in
the syslogMsgTable. When syslogMsgIndex reaches the maximum
value (4294967295), the value wraps back to 1.
Applications periodically polling the syslogMsgTable for new
entries should take into account that a complete rollover of
syslogMsgIndex will happen if more than 4294967294 messages
are received during a poll interval."
::= { syslogMsgEntry 1 }
syslogMsgFacility OBJECT-TYPE
SYNTAX SyslogFacility
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The facility of the SYSLOG message."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.1)
RFC 5427: Textual Conventions for Syslog Management"
::= { syslogMsgEntry 2 }
syslogMsgSeverity OBJECT-TYPE
SYNTAX SyslogSeverity
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The severity of the SYSLOG message"
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.1)
RFC 5427: Textual Conventions for Syslog Management"
::= { syslogMsgEntry 3 }
syslogMsgVersion OBJECT-TYPE
SYNTAX Unsigned32 (0..999)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The version of the SYSLOG message. A value of 0 indicates
that the version is unknown."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.2)"
::= { syslogMsgEntry 4 }
syslogMsgTimeStamp OBJECT-TYPE
SYNTAX SyslogTimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The timestamp of the SYSLOG message. A zero-length
string is returned if the timestamp is unknown."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.3)"
::= { syslogMsgEntry 5 }
syslogMsgHostName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The hostname and the (optional) domain name of the SYSLOG
message. A zero-length string indicates an unknown hostname.
The SYSLOG protocol specification constrains this string to
printable US-ASCII code points."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.4)"
::= { syslogMsgEntry 6 }
syslogMsgAppName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..48))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The app-name of the SYSLOG message. A zero-length string
indicates an unknown app-name. The SYSLOG protocol
specification constrains this string to printable US-ASCII
code points."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.5)"
::= { syslogMsgEntry 7 }
syslogMsgProcID OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..128))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The procid of the SYSLOG message. A zero-length string
indicates an unknown procid. The SYSLOG protocol
specification constrains this string to printable
US-ASCII code points."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.6)"
::= { syslogMsgEntry 8 }
syslogMsgMsgID OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The msgid of the SYSLOG message. A zero-length string
indicates an unknown msgid. The SYSLOG protocol specification
constrains this string to printable US-ASCII code points."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.2.7)"
::= { syslogMsgEntry 9 }
syslogMsgSDParams OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of structured data element parameters
carried in the SYSLOG message. This number effectively
indicates the number of entries in the syslogMsgSDTable.
It can be used, for example, by a notification receiver
to determine whether a notification carried all
structured data element parameters of a SYSLOG message."
::= { syslogMsgEntry 10 }
syslogMsgMsg OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The message part of the SYSLOG message. The syntax does not
impose a size restriction. Implementations of this MIB module
may truncate the message part of the SYSLOG message such that
it fits into the size constraints imposed by the implementation
environment. Such truncations can also happen elsewhere in the
SYSLOG forwarding chain.
If the first octets contain the value 'EFBBBF'h, then the rest
of the message is a UTF-8 string. Since SYSLOG messages may be
truncated at arbitrary octet boundaries during forwarding, the
message may contain invalid UTF-8 encodings at the end."
REFERENCE
"RFC 5424: The Syslog Protocol (Sections 6.1 and 6.4)"
::= { syslogMsgEntry 11 }
syslogMsgSDTable OBJECT-TYPE
SYNTAX SEQUENCE OF SyslogMsgSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing structured data elements of SYSLOG
messages."
::= { syslogMsgObjects 3 }
syslogMsgSDEntry OBJECT-TYPE
SYNTAX SyslogMsgSDEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry of the syslogMsgSDTable."
INDEX { syslogMsgIndex, syslogMsgSDParamIndex,
syslogMsgSDID, syslogMsgSDParamName }
::= { syslogMsgSDTable 1 } SyslogMsgSDEntry ::= SEQUENCE {
syslogMsgSDParamIndex Unsigned32,
syslogMsgSDID DisplayString,
syslogMsgSDParamName DisplayString,
syslogMsgSDParamValue SyslogParamValueString
}
syslogMsgSDParamIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object indexes the structured data element parameters
contained in a SYSLOG message. The first structured data
element parameter has the index value 1, and subsequent
parameters are indexed by incrementing the index of the
previous parameter. The index increases across structured
data element boundaries so that the value reflects the
position of a structured data element parameter in a
SYSLOG message."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.3.3)"
::= { syslogMsgSDEntry 1 }
syslogMsgSDID OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name (SD-ID) of a structured data element. The SYSLOG
protocol specification constrains this string to printable
US-ASCII code points."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.3.2)"
::= { syslogMsgSDEntry 2 }
syslogMsgSDParamName OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of a parameter of the structured data element. The
SYSLOG protocol specification constrains this string to
printable US-ASCII code points."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.3.3)"
::= { syslogMsgSDEntry 3 }
syslogMsgSDParamValue OBJECT-TYPE
SYNTAX SyslogParamValueString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of the parameter of a SYSLOG message identified by
the index of this table. The value is stored in the unescaped
format."
REFERENCE
"RFC 5424: The Syslog Protocol (Section 6.3.3)"
::= { syslogMsgSDEntry 4 }
-- notification definitions
syslogMsgNotification NOTIFICATION-TYPE
OBJECTS { syslogMsgFacility, syslogMsgSeverity,
syslogMsgVersion, syslogMsgTimeStamp,
syslogMsgHostName, syslogMsgAppName,
syslogMsgProcID, syslogMsgMsgID,
syslogMsgSDParams, syslogMsgMsg }
STATUS current
DESCRIPTION
"The syslogMsgNotification is generated when a new SYSLOG
message is received and the value of
syslogMsgGenerateNotifications is true.
Implementations may add syslogMsgSDParamValue objects as long
as the resulting notification fits into the size constraints
imposed by the implementation environment and the notification
message size constraints imposed by maxMessageSize [RFC3412]
and SNMP transport mappings."
::= { syslogMsgNotifications 1 }
-- conformance statements
syslogMsgGroups OBJECT IDENTIFIER ::= { syslogMsgConformance 1 }
syslogMsgCompliances OBJECT IDENTIFIER ::= { syslogMsgConformance 2 }
syslogMsgFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for implementations of the
SYSLOG-MSG-MIB."
MODULE -- this module
MANDATORY-GROUPS {
syslogMsgGroup,
syslogMsgSDGroup,
syslogMsgControlGroup,
syslogMsgNotificationGroup
}
::= { syslogMsgCompliances 1 }
syslogMsgReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for implementations of the
SYSLOG-MSG-MIB that do not support read-write access."
MODULE -- this module
MANDATORY-GROUPS {
syslogMsgGroup,
syslogMsgSDGroup,
syslogMsgControlGroup,
syslogMsgNotificationGroup
}
OBJECT syslogMsgTableMaxSize
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT syslogMsgEnableNotifications
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { syslogMsgCompliances 2 }
syslogMsgNotificationCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for implementations of the
SYSLOG-MSG-MIB that do only generate notifications and do not
provide a table to allow read access to SYSLOG message
details."
MODULE -- this module
MANDATORY-GROUPS {
syslogMsgGroup,
syslogMsgSDGroup,
syslogMsgNotificationGroup
}
OBJECT syslogMsgFacility
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgSeverity
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgVersion
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgTimeStamp
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgHostName
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgAppName
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgProcID
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgMsgID
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgSDParams
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgMsg
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
OBJECT syslogMsgSDParamValue
MIN-ACCESS accessible-for-notify
DESCRIPTION
"Read access is not required."
::= { syslogMsgCompliances 3 }
syslogMsgNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
syslogMsgNotification
}
STATUS current
DESCRIPTION
"The notifications emitted by this MIB module."
::= { syslogMsgGroups 1 }
syslogMsgGroup OBJECT-GROUP
OBJECTS {
-- syslogMsgIndex,
syslogMsgFacility,
syslogMsgSeverity,
syslogMsgVersion,
syslogMsgTimeStamp,
syslogMsgHostName,
syslogMsgAppName,
syslogMsgProcID,
syslogMsgMsgID,
syslogMsgSDParams,
syslogMsgMsg
}
STATUS current
DESCRIPTION
"A collection of objects representing a SYSLOG message,
excluding structured data elements."
::= { syslogMsgGroups 2 }
syslogMsgSDGroup OBJECT-GROUP
OBJECTS {
-- syslogMsgSDParamIndex,
-- syslogMsgSDID,
-- syslogMsgSDParamName,
syslogMsgSDParamValue
}
STATUS current
DESCRIPTION
"A collection of objects representing the structured data
elements of a SYSLOG message."
::= { syslogMsgGroups 3 }
syslogMsgControlGroup OBJECT-GROUP
OBJECTS {
syslogMsgTableMaxSize,
syslogMsgEnableNotifications
}
STATUS current
DESCRIPTION
"A collection of control objects to control the size of the
syslogMsgTable and to enable/disable notifications."
::= { syslogMsgGroups 4 }
END8. Usage Example ✨
okay so this example is giving 🎀 it shows a totally valid SYSLOG message with structured data in it. the otherwise-unprintable Unicode byte order mark (BOM) gets shown as "BOM" so we can actually read it 🫶
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] BOMAn application event log entry...this one message lowkey ends up making entries in both the syslogMsgTable and the syslogMsgSDTable 🦋 (string indexes are written as strings here just so it's easier to read, bestie 💖)
syslogMsgIndex.1 = 1
syslogMsgFacility.1 = 20
syslogMsgSeverity.1 = 5
syslogMsgVersion.1 = 1
syslogMsgTimeStamp.1 = 2003-10-11,22:14:15.003,+0:0
syslogMsgHostName.1 = "mymachine.example.com"
syslogMsgAppName.1 = "evntslog"
syslogMsgProcID.1 = "-"
syslogMsgMsgID.1 = "ID47"
syslogMsgMsg.1 = "BOMAn application event log entry..."
syslogMsgSDParamValue.1.1."exampleSDID@32473"."iut"
= "3"
syslogMsgSDParamValue.1.2."exampleSDID@32473"."eventSource"
= "Application"
syslogMsgSDParamValue.1.3."exampleSDID@32473"."eventID"
= "1011"9. IANA Considerations 🌸
the IANA has assigned the value "192" under the 'mib-2' subtree 🧚 and recorded that assignment in the SMI Numbers registry 💜
10. Security Considerations 🔐✨
okay bestie, this section is SERIOUS but also kinda iconic, so let's go. 💅 There are a bunch of management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Those objects can be sensitive or vulnerable in some network environments, and SET operations in a non-secure environment without proper protection can have a negative effect on network operations. 😭 These are the tables and objects, and why they're sensitive:
syslogMsgTableMaxSize: this one controls how many entries are kept in the syslogMsgTable. If somebody sneaks in and changes it, they can either cause increased memory consumption (by setting it to a large value) or turn off the ability to retrieve notifications with GET class operations (by setting it to zero). 🙈 That could be used to hide traces of an attack, which is so not it.syslogMsgEnableNotifications: this one enables notifications. Unauthorized changes to disable notification generation can be used to hide an attack by stopping management apps that use SNMP from getting real-time notifications about events carried in SYSLOG messages. Unauthorized changes to enable notification generation may be used as part of a denial-of-service attack against a network management system if, for example, the SYSLOG-to-SNMP translator accepts unauthorized SYSLOG messages. 💀
Some of the readable objects in this MIB module (the ones with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable in some environments. So it's important to control even GET and/or NOTIFY access to these objects, and possibly even encrypt their values when sending them over the network via SNMP. 🔒 Here's the breakdown:
syslogMsgTableMaxSize,syslogMsgEnableNotifications: these objects tell you whether SYSLOG messages are forwarded as SNMP notifications, and how many messages get kept in the syslogMsgTable. An attacker could use that info to plan actions aimed at hiding their attack activity. 🕵️♀️syslogMsgFacility,syslogMsgSeverity,syslogMsgVersion,syslogMsgTimeStamp,syslogMsgHostName,syslogMsgAppName,syslogMsgProcID,syslogMsgMsgID,syslogMsgSDParams,syslogMsgMsg,syslogMsgSDParamValue: these carry the content of SYSLOG messages, and the SYSLOG-message-oriented security considerations of [RFC5424] apply. 🎀 The big worry is that an attacker who gets access to SYSLOG messages via SNMP can use what they learn to compromise a machine or do other damage. So it's really desirable to configure SNMP access control rules that enforce a consistent security policy for SYSLOG messages. 🧚
SNMP versions before SNMPv3 did not include adequate security. 😤 Even if the network itself is secure (for example by using IPsec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Yikes. 🙃
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). 🌸
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and enable cryptographic security. 🦋 It's then a customer/operator responsibility to make sure that the SNMP entity giving access to an instance of this MIB module is configured so that only principals (users) with legitimate rights can GET or SET (change/create/delete) the objects. 👑
Using the security features of the SNMPv3 framework secures the transport of SYSLOG data via SNMP only. So it is RECOMMENDED that deployments use SYSLOG security mechanisms too, to prevent attackers from adding malicious SYSLOG data to the MIB tables. 🛡️🫶
11. Acknowledgments 💖
The editors wish to thank the following people for their super helpful comments on various versions of this document: Martin Bjorklund, Washam Fan, Rainer Gerhards, Wes Hardacker, David Harrington, Tom Petch, Juergen Quittek, Dan Romascanu, and Bert Wijnen. 🌈🙌
12. References 📚
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", RFC 2579, STD 58, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999.
- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
- [RFC5427] Keeni, G., "Textual Conventions for Syslog Management", RFC 5427, March 2009.
- [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", RFC 5675, October 2009.
12.2. Informative References
- [RFC3014] Kavasseri, R., Ed., "Notification Log MIB", RFC 3014, November 2002.
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses 🦋
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
EMail: j.schoenwaelder@jacobs-university.de
Alexander Clemm Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA
EMail: alex@cisco.com
Anirban Karmakar Cisco Systems India Pvt Ltd SEZ Unit, Cessna Business Park, Sarjapur Marathahalli ORR, Bangalore, Karnataka 560103 India
EMail: akarmaka@cisco.com
📦 where this page comes from
- ietf: rfc5676 2009-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms