Last Modified: 2003-01-28
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.
|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.|
|RFC3164||I||The BSD Syslog Protocol|
|RFC3195||PS||Reliable Delivery for Syslog|
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 authentication - 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 configuration - 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 detection...) - 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 SNMPv3 David: Even with v3, only certain personnel should have access Tim: Why is the MIB so close to the BSD syslog implementation? 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 management). Glenn: Even having just R/O access to the configuration information is good. The design still remains consistent, regardless. Mic: Many of the objects can probably be implemented without an intrusive approach. We should take note of this in the conformance statements. 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 hand 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 firstname.lastname@example.org list, many out of scope for us, but lots of syslog stuff... Chris: Adjourn.