Issue #1. Security Considerations need to be addressed.
The Securities Considerations scetion should address
matters relative to READONLY access of the MIB as well
as other threats too.
Action: The present Security Considerations section
contains the text appended below. The above concerns
are addressed. Have me missed anything ?
Status: Waiting on community input
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
7. Security Considerations
Syslog plays a very important role in the computer and network
security of an organization. SyslogMIB defines several managed
objects that may be used to monitor configure and control syslog
processes. As such improper manipulation of the objects represented
by this MIB may lead to an attack on an important component of the
computer and network security infrastructure. The objects in
syslogParamsTable, syslogAllowedHostsTable, syslogCtlSelectionTable,
syslogCtlLogActionTable, syslogCtlUserActionTable
syslogCtlFwdActionTable, syslogCtlPipeActionTable may be
misconfigured to cause syslog messages to be diverted or lost. A
misconfiguration may also result in a DoS attack on a user or
service. There are a number of management objects defined in this
MIB module with a MAX-ACCESS clause of read-write and/or read-create.
Such objects may be considered sensitive or vulnerable in some
network environments. The support for 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 their
sensitivity/vulnerability:
o syslogParamsTable: the objects in this table describe the
configuration of the syslog processes. The syslogParamsProcessStatus
may be used to start stop or suspend the syslog process itself.
o syslogAllowedHostsTable: the objects in this table describe the hosts
from which syslog messages will be accepted. Improper configuration may
lead to loss of messages from an important source or a flood of messages
from a, potentially rogue, source.
o syslogCtlSelectionTable: the objects in this table describe selection
rules for messages. Improper configuration may lead to loss of relevant
messages or the collection of useless, potentially ill-intentioned,
messages.
o syslogCtlLogActionTable: the objects in this table describe the actions
that will be carried on a received syslog message. Misconfiguration may
lead to loss of important messages or misdirection of messages.
o syslogCtlUserActionTable: Objects in this table describe the users that
will be notified. It may be misconfigured to prevent a user from
receiving an important message or to spam a user's console.
o syslogCtlFwdActionTable: Objects in this table describe the forwarding
action that will carried out on messages. It may be misconfigured to
prevent important messages from reaching their destinations or to direct
a DoS attack on a specific destination. It may also be misconfigured to
send syslog messages to an improper destination - resulting in a breach
of user's privacy.
o syslogCtlPipeActionTable: objects in this table describe the commands
that will be invoked to process a log message. This may be misconfigured
to cause arbitrary programs to be invoked on the syslog receiver.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o syslogProcTable: objects in this table carry sensitive information. The
counters may reveal information about the deployment and effectiveness
of the relevant security systems. The counters may be analyzed to tell
whether the security systems are able to detect an event or not.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
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 to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
