HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:23:04 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 05 Nov 1996 00:15:00 GMT ETag: "2e614e-2b5b-327e8704" Accept-Ranges: bytes Content-Length: 11099 Connection: close Content-Type: text/plain INTERNET DRAFT J. Abela Expires: May 4, 1997 HSC 4 November 1996 Universal Format for Logger Messages Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents a format to describe system events for logging purpose. Some of the features presented here are in use with the common syslog facility, but most of them are lost in the crowd of syslog format freedom. Introduction At the beginning, logs were scanned by the administrator after an incident to detect the failure cause. With the increasing concern on computer security, and wide area network manangement, the need for automated log examination, extraction and reporting has grown. The Universal Logger Message (ULM) format presented here is a set of guidelines to formalize the semantics of such messages. Syntax The ABNF for ULM is: log_file ::= *(log_line LF) log_line ::= field *(SP field) Abela [Page 1] RFC 1 Universal Logger Messages 4 November 1996 field ::= field_name "=" field_value field_name ::= ALPHA *(ALPHA_EXT) field_value ::= 1*(ALPHA_EXT) / string string ::= QUOTE *(ANY_BUT_Q / esc_quote) QUOTE esc_quote ::= "\" QUOTE ANY_BUT_Q ::= ALPHA_EXT ::= ALPHA / DIGIT / "." / "_" / "-" QUOTE ::= ALPHA ::= DIGIT ::= LF ::= SP ::= Fields The following rules should apply regarding fields: (1) Each field name should be unique in a given log event. If two or more fields have the same name in a unique ULM, the expected result is undefined. (2) The case should not be significant for field names. Thus, DATE and dAtE fields both describe the same information in a given ULM. (3) Each field type sould be registered and have an associated field value format. Mandatory Fields The following fields should be present in any ULM: LEVEL, HOST, PROG, DATE. Abela [Page 2] RFC 1 Universal Logger Messages 4 November 1996 LEVEL value.level ::= "Emergency" / "Alert" / "Error" / "Warning" / "Auth" / "Security" / "Usage" / "Important" / "Info" The level field specifies the importance and category of the ULM. The signification for the different values are: Emergency A panic condition. It should be broadcast to all users. Alert A condition that should be corrected immediately. Error A system error. This level and the previous ones are reserved for system conditions. Warning Program error. The program has detected an incorrect behaviour of his own. To clarify the differences between these last levels: Absence of a system configuration file is an Error, failed assert is a Warning, and erroneous data given by a user is never anything more than an Info: typing typos is just a normal behaviour. Auth An authentification failed. Potential senders for such an ULM could be su and login. Security A standard protection was raised against what could be an intrusion. A connection denial based on the remote network address falls into this category. Usage Normal, standard, authorized day-to-day usage information. Important Abela [Page 3] RFC 1 Universal Logger Messages 4 November 1996 Important information which could be critical, but is not yet. A configuration change is an important information. Info The Info level is for somewhat superfluous informations. These informations are not hot, they are not to be accounted, they are not to be billed. If a daemon says it has reloaded it's configuration file after receiving a signal, the log level for that event is Info. HOST value.host ::= string The HOST field contains the name of the host which issues the ULM. PROG value.prog ::= string The PROG field contains the name of the software component which issues the ULM. If a software component is a member of a software suite, it should be expressed in a hierachical, as in: "suite.component.subcomponent". DATE value.date ::=
The DATE field contains the instantaneous date of the event. If the event last a sufficient amount of time, different ULM sould be issued, each marked with its own date. Optional Fields The following fields could be added in any ULM. Any application reading log files should be aware of these: DURATION, PROCESS, ID, SOURCE.IP, SOURCE.FQDN, SOURCE.NAME, SOURCE.PORT, SOURCE.USER, DEST.IP, DEST.FQDN, DEST.NAME, DEST.PORT, DEST.USER, SENT.VOLUME, SENT.COUNT, RECEIVED.VOLUME, RECEIVED.COUNT, TTY, DOCUMENT, MESSAGE. DURATION value.duration ::= [[[] ] ] The DURATION indicates the duration of the event whose end is Abela [Page 4] RFC 1 Universal Logger Messages 4 November 1996 given by the DATE field. This field is mandatory if the ULM announces the end of an event for which another ULM was issued at the beginning. PROCESS value.process ::= integer In a multi-tasking environment, this field specifies the process id which issued de ULM. On some systems, this id may not be unique, but it should however be unique on the specified HOST, over the specified DURATION, if appropriate. Thus, the ULM announcing the end of a session should specifiy the duration of the session, and guarantee that all the ULM issued between the beginning of the session and this ULM with the same HOST value and the same PROCESS values concern to this session. ID value.id ::= string The ID field is a system reference to the concerned document. It could be a mail or Usenet news message-id, or an incremented counter. It should not be mistaken with the DOCUMENT field, which a user-level name. SOURCE.IP value.source.ip ::= ipv4 / ipv6 ipv4 ::= byte- integer "." byte-integer "." byte-integer "." byte-integer The SOURCE.IP field contains the IP number of the source host. Other SOURCE.* fields could describe network source address in other realms (IPX, X25, ...). The SOURCE.* fields all contain informations about the host connected, connecting, or trying to connect. SOURCE.FQDN value.source.fqdn ::= string Fully Qualified Domain Name for the source host. SOURCE.NAME value.source.name ::= string Abela [Page 5] RFC 1 Universal Logger Messages 4 November 1996 Generic name qualifying the source host, if fqdn is not available. For example, "local" qualifies a host, but is not an FQDN. SOURCE.PORT value.source.port ::= integer Port number for TCP, UDP or another protocol. SOURCE.USER value.source.user ::= string User name or user id. DEST.IP DEST.FQDN DEST.NAME DEST.PORT DEST.USER All the DEST.* fields have the same signification as the SOURCE.* fields, except that they qualify the destination. SENT.VOLUME SENT.COUNT RECEIVED.VOLUME RECEIVED.COUNT Nnumber of bytes and count (of articles, or files) sent, and received, from the source point of view. TTY value.tty ::= string The tty field describes the physical connection of a user to the host. DOCUMENT value.document ::= string The document field is the name of an accessed document, like the path of an ftp file, the name of a newsgroup, or the non-host part of an URL. MESSAGE value.message ::= string The MESSAGE field is the only field which should contain arbitrary data. Any important information which doesn't fit any Abela [Page 6] RFC 1 Universal Logger Messages 4 November 1996 of the other standard fields could be stored here. Use of the message field for an information which does fit another standard field is forbidden. Other more fields Any other field of interest could be added, but it sould be registered first to the Internet Assigned Number Authority (IANA). Security Considerations ULM includes no security functions. However, sites should worry about the vulnerabilites of their logging architecture, especially when networks are used to transport ULM, as these messages may be critical for the security. Author's Address Jerome Abela Herve Schauer Consultant 142, rue de Rivoli 75039 Paris cedex 01 France Phone: (+33) 146 38 89 90 EMail: Jerome.Abela@hsc.fr Abela [Page 7]