Security Issues in Network Event Logging (syslog)


In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional SYSLOG Page

Last Modified: 2008-03-13

Additional information is available at tools.ietf.org/wg/syslog

Chair(s):

  • Chris Lonvick <clonvick@cisco.com>

  • David Harrington <ietfdbh@comcast.net>

    Security Area Director(s):

  • Tim Polk <tim.polk@nist.gov>
  • Pasi Eronen <pasi.eronen@nokia.com>

    Security Area Advisor:

  • Pasi Eronen <pasi.eronen@nokia.com>

    Mailing Lists:

    General Discussion: syslog@ietf.org
    To Subscribe: syslog-request@ietf.org
    In Body: in body: (un)subscribe
    Archive: http://www1.ietf.org/mail-archive/web/syslog/current/index.html

    Description of Working Group:

    Syslog is a de-facto standard for logging system events. However, the
    protocol component of this event logging system has not been formally
    documented. While the protocol has been very useful and scalable, it
    has some known security problems which were documented in the
    INFORMATIONAL RFC 3164.

    The goal of this working group is to address the security and integrity
    problems, and to standardize the syslog protocol, transport, and a
    select set of mechanisms in a manner that considers the ease of
    migration between and the co-existence of existing versions and the
    standard.

    Reviews have shown that there are very few similarities between the
    message formats generated by heterogeneous systems. In fact, the only
    consistent commonality between messages is that all of them contain
    the <PRI> at the start. Additional testing has shown that as long as
    the <PRI> is present in a syslog message, all tested receivers will
    accept any generated message as a valid syslog message. In designing a
    standard syslog message format, this Working Group will retain the
    <PRI> at the start of the message and will introduce protocol
    versioning. Along these same lines, many different charsets have been
    used in syslog messages observed in the wild but no indication of the
    charset has been given in any message. The Working Group also feels
    that multiple charsets will not be beneficial to the community;
    much code would be needed to distinguish and interpret different
    charsets. For compatibility with existing implementations, the Working
    Group will allow that messages may still be sent that do not indicate
    the charset used. However, the Working Group will recommend that
    messages contain a way to identify the charset used for the message,
    and will also recommend a single default charset.

    syslog has traditionally been transported over UDP and this WG has
    already defined RFC 3195 for the reliable transport for the syslog
    messages. The WG will separate the UDP transport from the protocol so
    that others may define additional transports in the future.

    The threats that this WG will primarily address are modification,
    disclosure, and masquerading. A secondary threat is message stream
    modification. Threats that will not be addressed by this WG are DoS and
    traffic analysis. The primary attacks may be thwarted by a secure
    transport. However, it must be remembered that a great deal of the
    success of syslog has been attributed to its ease of implementation and
    relatively low maintenance level. The Working Group will consider those
    factors, as well as current implementations, when deciding upon a
    secure transport. The secondary threat of message stream modification
    can be addressed by a mechanism that will verify the end-to-end
    integrity and sequence of messages. The Working Group feels that these
    aspects may be addressed by a dissociated signature upon sent messages.

    - A document will be produced that describes a standardized syslog
    protocol. A mechanism will also be defined in this document that will
    provide a means to convey structured data.

    - A document will be produced that describes a standardized UDP
    transport for syslog.

    - A document will be produced that requires a secure transport for the
    delivery of syslog messages.

    - A document will be produced to describe the MIB for syslog entities.

    - A document will be produced that describes a standardized mechanism
    to sign syslog messages to provide integrity checking and source
    authentication.

    Goals and Milestones:

    Done  Post as an Internet Draft the observed behavior of the Syslog protocol for consideration as an Informational Document.
    Done  Submit Syslog protocol document to IESG for consideration as an INFORMATIONAL RFC.
    Done  Post as an Internet Draft the specification for an authenticated Syslog for consideration as a Standards Track RFC.
    Done  Post an Internet Draft describing enhancements to the Syslog authentication protocol to add verification of delivery and other security services.
    Done  Submit Syslog Authentication Protocol Enhancement to IESG for consideration as a PROPOSED STANDARD.
    Nov 2006  Submit Syslog Device MIB to IESG for consideration as a PROPOSED STANDARD
    Nov 2006  Submit a document that defines a message signing and ordering mechanism to the IESG for consideration as a PROPOSED STANDARD
    Done  Submit Syslog UDP Transport Mapping to the IESG for consideration as a PROPOSED STANDARD
    Done  Submit Syslog Protocol to the IESG for consideration as a PROPOSED STANDARD
    Done  Submit Syslog TLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD

    Internet-Drafts:

    Signed syslog Messages (72860 bytes)
    Syslog Management Information Base (93468 bytes)
    The syslog Protocol (88426 bytes)
    Transmission of syslog messages over UDP (22373 bytes)
    TLS Transport Mapping for Syslog (30930 bytes)
    Textual Conventions for Syslog Management (23181 bytes)

    Request For Comments:

    The BSD Syslog Protocol (RFC 3164) (72951 bytes)
    Reliable Delivery for Syslog (RFC 3195) (60960 bytes)

    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.