2.6.11 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:

       http://www.employees.org/~lonvick/index.shtml -- Additional SYSLOG Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-28

Chris Lonvick <clonvick@cisco.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Steven Bellovin <smb@research.att.com>
Mailing Lists:
General Discussion: syslog-sec@employees.org
To Subscribe: majordomo@employees.org
In Body: subscribe syslog-sec your_email_address
Archive: http://www.mail-archive.com/syslog-sec@employees.org/
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 but undocumented security problems. For instance, the messages are unauthenticated and there is no mechanism to provide verified delivery and message integrity.

The goal of this working group is to document and address the security and integrity problems of the existing Syslog mechanism. In order to accomplish this task we will document the existing protocol. The working group will also explore and develop a standard to address the security problems.

Beyond documenting the Syslog protocol and its problems, the working group will work on ways to secure the Syslog protocol. At a minimum this group will address providing authenticity, integrity and confidentiality of Syslog messages as they traverse the network. The belief being that we can provide mechanisms that can be utilized in existing programs with few modifications to the protocol while providing significant security enhancements.

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.
AUG 00  Submit Syslog Authentication Protocol to IESG for consideration as a PROPOSED STANDARD.
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.
DEC 00  Revise drafts as necessary to advance these Internet-Drafts to Standards Track RFCs.
  • - draft-ietf-syslog-sign-09.txt
  • - draft-ietf-syslog-device-mib-03.txt
  • Request For Comments:
    RFC3164 I The BSD Syslog Protocol
    RFC3195 PS Reliable Delivery for Syslog

    Current Meeting Report

    WG: Security Issues in Network Event Logging (syslog)
    Chairs: Chris Lonvick
    Monday, March 18th, 2003 14:15-15:15 US/Pacific
    Minutes by: Marshall T. Rose
    Chris: Agenda
        Agenda Bashing - no changes
        Review of Charter and Status Update
        Review of Syslog MIB
        Wrap Up
    Chris: Review of Charter
        - Recall that our focus is about reliable delivery and 
        - RFC 3164: How syslog works
        - RFC 3195: Reliable Delivery: 3 implementations out there
        - draft-ietf-syslog-sign-09: looking solid, still lacking 
    "Security" and "IANA" considerations, one implementor has surfaced
        - draft-ietf-syslog-device-mib-03: to be discussed today
    Glenn: draft-ietf-syslog-device-mib
        - Questions to ask:
            1. Are the right knobs there?
            2. Are the knobs adequately defined?
        - Purpose of the MIB
            - monitoring syslog operation (stats on messages in/out)
            - system-wide parameters: read-write
            - process run-time parameters: read-write
            - process rules for message selection and actions: read-write
            - read-write objects move us from monitoring to 
        - MIB Design mimics this architecture
            - system group: models generic information for the service
            - parameters group: models processes that implement the daemon
            - control group: models the syslog.conf file
        - Security Considerations
            - insecure access can allow mis-configuration, start/stop it, etc. 
    (e.g., a bad idea given that syslog logs things like intruder 
            - mis-configuring tables may result in loss/flood of messages, 
    console spamming, attacking collectors, remove shell invocation, etc.
            - even R/O access is sensitive, e.g., reading counters.
        - TBD
            - DESCRIPTION/REFERENCE clauses
            - Is the MIB module set-consistent?
            - Editorial nits
            - Implemnet
        Mic: Security considerations can be addressed by access control in 
        David: Even with v3, only certain personnel should have access
        Tim: Why is the MIB so close to the BSD syslog 
        Chris: There's no requirement to do so, we just have a lot of info on 
    the BSD side of things. We'd certainly like to get info from non-BSD folks
        Mike: There may be a lot of duplication with the Host Resources MIB?  
    Also, what about SNMP notifications?
        Glenn: I've tried to avoid duplicating HR MIB functionality in the 
    SYSLOG MIB module.  I need to document this more.
        Mic: There needs to be a "no DNS lookup"
        Marshall: Can we talk about the decision to do configuration stuff?
        Mic: Often times, simply having the MIB modelling is useful 
    independent of actual SNMP implementation (e.g., encouraging syslog 
    implementors to have the same feature set, independent of the 
        Glenn: Even having just R/O access to the configuration 
    information is good. The design still remains consistent, 
        Mic: Many of the objects can probably be implemented without an 
    intrusive approach. We should take note of this in the conformance 
        Bert: Many operators aren't comfortable doing configuration via SNMP, 
    and there's interest in doing configuration other ways (cf., netconf). So, 
    there's a risk that even if you define the objects, they won't get 
    implemented for setting....
        Mic: Well, it may be used outside the operator community.
        David: I'm familiar with SNMP-manageable syslog stuff.
        Chris: How many people think we should be doing configurable stuff?  
    many hands
               How many people think we should be doing monitoring stuff?  one 
        Glenn: is there an impact on the MIB module if we just make 
    everything R/O?
        Bert: well, you can remove RowStatus objects, etc., so it would make 
    things simpler. but, we'll still review the mib in case someone chooses to 
    implement objects read-write.
        Steve: i look for what needs to be protected for both a read-only for 
    privacy, and read-write for other threats.
        Mic: i haven't had any customers ask for syslog 
    configuration, they want to use cli... so, i'd rather see a simpler mib, 
    that's faster to implement.
        Mic: it's important that standard protocols have standard knobs
        Steve: netconf uses 3195 for notifications, and we're interested in 
    finding out what interest there is in opening up 3195 for our needs.  is 
    there interest in this wg?
                       some hands go up, none opposed
    Chris: Wrapup
        Internationalization? Characters are currently us-ascii
        syslog-sign needs review
            - using rfc 3164 (timestamp, hostname, etc.)
            - need to update rfc3195 to reflect this
        Continue work on syslog-mib
        Folks may want to take a look at the 
    loganalysis@lists.shmoo.com list, many out of scope for us, but lots of 
    syslog stuff...
    Chris: Adjourn.