syslog.conf配置文件详解

 LINUX保存了系统中所发生事件的详细记录,这些记录称作日志文件或消息文件.可以查阅日志文件来确定系统当前状态,观察入侵者踪迹,寻找某特定程序(或事件)相关的数据.
        syslogd与klogd(监控linux内核提交的消息)守护进程负责记录,发送系统或工具产生的信息,二者的配置文件都是/etc/syslog.conf.当系统内核或工具产生信息时,通过调用相关函数将信息发送到syslogd或klogd守护进程.syslogd与klogd守护进程会根据/etc/syslog.conf中的配置信息,对消息的去向作出处理.

 

        说明：
        syslog.conf是syslogd进程的配置文件,将在程序启动时读取,默认位置是/etc/syslog.conf.这个配置文件中的空白行和以"#"开头的行将被忽略."facility.level"部分也被称为选择符(seletor). seletor和action之间使用一个或多个空白分隔.它指定了一系列日志记录规则.规则的格式如下:
        seletor(facility.level)    action

        选择符(seletor)(选择符由 facility 和 level 两部分组成,之间用一个句点(.)连接)

        A.facility 指定了产生日志的子系统,可以是下面的关键字之一:
                关键字              值       解释
                kern                0        内核信息,首先通过 klogd 传递.
                user                1        由用户程序生成的信息.
                mail                2        与电子邮件有关的信息.
                daemon              3        与 inetd 守护进程有关的信息.
                auth                4        由 pam_pwdb 报告的认证活动.
                syslog              5        由 syslog 生成的信息.
                lpr                 6        与打印服务有关的信息.
                news                7        来自新闻服务器的信息.
                uucp                8        由 uucp 生成的信息.(uucp = unix to unix copy)
                cron                9        与 cron 和 at 有关的信息.
                authpriv           10        包括私有信息(如用户名)在内的认证活动
                ftp                11        与 FTP 有关的信息.
                                12-15        系统保留
                local0 ~ local7  16-23        由自定义程序使用,例如使用 local5 做为 ssh 功能
                mark                         syslog内部功能用于生成时间戳.
                *                            通配符代表除了 mark 以外的所有功能
        在大多数情况下,任何程序都可以通过任何facility发送日志消息,但是一般都遵守约定俗成的规则.比如,只有内核才能使用"kern"facility.

 

        B.level指定了消息的优先级,可以是下面的关键字之一(降序排列,严重性越来越低)：
                关键字               值        解释
                emerg                0        系统不可用
                alert                1        需要立即被修改的条件
                crit                 2        (临界)阻止某些工具或子系统功能实现的错误条件
                err                  3        阻止工具或某些子系统部分功能实现的错误条件
                warning              4        预警信息
                notice               5        具有重要性的普通条件
                info                 6        提供信息的消息
                debug                7        不包含函数条件或问题的其他信息
                none                          (屏蔽所有来自指定设备的消息)没有优先级,通常用于排错
                *                             除了none之外的所有级别
        facility部分可以是用逗号(,)分隔的多个子系统,而多个seletor之间也可以通过分号(;)组合在一起.
        注意:多个组合在一起的选择符,后面的会覆盖前面的,这样就允许从模式中排除一些优先级.
        默认将对指定级别以及更严重级别的消息进行操作,但是可以通过下面2个操作符进行修改.
                等于操作符(=)表示仅对这个级别的消息进行操作,不等操作符(!)表示忽略这个级别以及更严重级别的消息.这两个操作符可以同时使用,不过"!"必须出现在"="的前面.

 

 

        动作(action)
        动作确定了syslogd与klogd守护进程将日志消息发送到什么地方去.有以下几种选择：
        普通文件        使用文件的绝对路径来指明日志文件所在的位置,例如：/var/log/cron.
        终端设备        终端可以是/dev/tty0~/dev/tty6,也可以为/dev/console.
        用户列表        例如动作为“root hackbutter”,将消息写入到用户root与hackbutter的计算机屏幕上.
        远程主机        将信息发往网络中的其他主机的syslogd守护进程,格式为“@hostname”.

 

 

        配置文件的语法说明
                (1)    *用作设备或优先级时,可以匹配所有的设备或优先级.
                (2)    *用作动作时,将消息发送给所有的登录用户.
                (3)    多个选择器可在同一行中,并使用分号分隔开,且后面的会覆盖前面的.如,uucp,news.crit.
                (4)    关键字none用作优先级时,会屏蔽所有来自指定设备的消息.
                (5)    通过使用相同的选择器和不同的动作,同一消息可以记录到多个位置.
                (6)    syslog.conf文件中后面的配置行不会覆盖前面的配置行,每一行指定的动作都独立的运作.

 

 

        实例详解：
        //将info或更高级别的消息送到/var/log/messages,除了mail,authpriv,cron以外.
        //其中*是通配符,代表任何设备；none表示不对任何级别的信息进行记录.
        *.info;mail.none;authpriv.none;cron.none                /var/log/messages

        //将mail设备中的任何级别的信息记录到/var/log/maillog文件中,这主要是和电子邮件相关的信息.
        mail.*                                                  -/var/log/maillog
 
        //将authpirv设备的任何级别的信息记录到/var/log/secure文件中,这主要是一些和权限使用相关的信息.
        authpriv.*                                              /var/log/secure

        //将cron设备中的任何级别的信息记录到/var/log/cron文件中,这主要是和系统中定期执行的任务相关的信息.
        cron.*                                                  /var/log/cron

        //将任何设备的emerg(系统不可用)级别的信息发送给所有正在系统上的用户.
        *.emerg                                                 *

        //将uucp和news设备的crit(临界)级别的信息记录到/var/log/spooler文件中.
        uucp,news.crit                                          /var/log/spooler

        //将和系统启动相关的信息记录到/var/log/boot.log文件中.
        local7.*                                                /var/log/boot.log

 

 

详细情况可参见：RFC3164
附RFC3164:

Network Working Group                                         C. Lonvick
Request for Comments: 3164                                 Cisco Systems
Category: Informational                                      August 2001

                        The BSD syslog Protocol

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes the observed behavior of the syslog protocol.
   This protocol has been used for the transmission of event
   notification messages across networks for many years.  While this
   protocol was originally developed on the University of California
   Berkeley Software Distribution (BSD) TCP/IP system implementations,
   its value to operations and management has led it to be ported to
   many other operating systems as well as being embedded into many
   other networked devices.

Table of Contents

   1. Introduction....................................................2
   1.1 Events and Generated Messages..................................3
   1.2 Operations of the Message Receivers............................5
   2. Transport Layer Protocol........................................5
   3. Definitions and Architecture....................................5
   4. Packet Format and Contents......................................7
   4.1 syslog Message Parts...........................................8
   4.1.1 PRI Part.....................................................8
   4.1.2 HEADER Part of a syslog Packet..............................10
   4.1.3 MSG Part of a syslog Packet.................................11
   4.2 Original syslog Packets Generated by a Device.................12
   4.3 Relayed syslog Packets........................................12
   4.3.1 Valid PRI and TIMESTAMP.....................................13
   4.3.2 Valid PRI but no TIMESTAMP or invalid TIMESTAMP.............13
   4.3.3 No PRI or Unidentifiable PRI................................14
   5. Conventions....................................................14
   5.1 Dates and Times...............................................15
   5.2 Domain Name and Address.......................................15
   5.3 Originating Process Information...............................15
   5.4 Examples......................................................16
   6. Security Considerations........................................18
   6.1 Packet Parameters.............................................19
   6.2 Message Authenticity..........................................19
   6.2.1 Authentication Problems.....................................19
   6.2.2 Message Forgery.............................................20
   6.3 Sequenced Delivery............................................20
   6.3.1 Single Source to a Destination..............................20
   6.3.2 Multiple Sources to a Destination...........................21
   6.3.3 Multiple Sources to Multiple Destinations...................21
   6.3.4 Replaying...................................................22
   6.4 Reliable Delivery.............................................22
   6.5 Message Integrity.............................................22
   6.6 Message Observation...........................................22
   6.7 Message Prioritization and Differentiation....................23
   6.8 Misconfiguration..............................................24
   6.9 Forwarding Loop...............................................24
   6.10 Load Considerations..........................................25
   7. IANA Considerations............................................25
   8. Conclusion and Other Efforts...................................25
   Acknowledgements..................................................26
   References........................................................27
   Author's Address..................................................28
   Full Copyright Statement..........................................29

1. Introduction

   Since the beginning, life has relied upon the transmission of
   messages.  For the self-aware organic unit, these messages can relay
   many different things.  The messages may signal danger, the presence
   of food or the other necessities of life, and many other things.  In
   many cases, these messages are informative to other units and require
   no acknowledgement.  As people interacted and created processes, this
   same principle was applied to societal communications.  As an
   example, severe weather warnings may be delivered through any number
   of channels - a siren blowing, warnings delivered over television and
   radio stations, and even through the use of flags on ships.  The
   expectation is that people hearing or seeing these warnings would
   realize their significance and take appropriate action.  In most
   cases, no responding acknowledgement of receipt of the warning is
   required or even desired.  Along these same lines, operating systems,
   processes and applications were written to send messages of their own
   status, or messages to indicate that certain events had occurred.
   These event messages generally had local significance to the machine
   operators.  As the operating systems, processes and applications grew
   ever more complex, systems were devised to categorize and log these
   diverse messages and allow the operations staff to more quickly
   differentiate the notifications of problems from simple status
   messages.  The syslog process was one such system that has been
   widely accepted in many operating systems.  Flexibility was designed
   into this process so the operations staff have the ability to
   configure the destination of messages sent from the processes running
   on the device.  In one dimension, the events that were received by
   the syslog process could be logged to different files and also
   displayed on the console of the device.  In another dimension, the
   syslog process could be configured to forward the messages across a
   network to the syslog process on another machine. The syslog process
   had to be built network-aware for some modicum of scalability since
   it was known that the operators of multiple systems would not have
   the time to access each system to review the messages logged there.
   The syslog process running on the remote devices could therefore be
   configured to either add the message to a file, or to subsequently
   forward it to another machine.

   In its most simplistic terms, the syslog protocol provides a
   transport to allow a machine to send event notification messages
   across IP networks to event message collectors - also known as syslog
   servers.  Since each process, application and operating system was
   written somewhat independently, there is little uniformity to the
   content of syslog messages.  For this reason, no assumption is made
   upon the formatting or contents of the messages.  The protocol is
   simply designed to transport these event messages.  In all cases,
   there is one device that originates the message.  The syslog process
   on that machine may send the message to a collector.  No
   acknowledgement of the receipt is made.

   One of the fundamental tenets of the syslog protocol and process is
   its simplicity.  No stringent coordination is required between the
   transmitters and the receivers.  Indeed, the transmission of syslog
   messages may be started on a device without a receiver being
   configured, or even actually physically present.  Conversely, many
   devices will most likely be able to receive messages without explicit
   configuration or definitions.  This simplicity has greatly aided the
   acceptance and deployment of syslog.

1.1 Events and Generated Messages

   The writers of the operating systems, processes and applications have
   had total control over the circumstances that would generate any
   message.  In some cases, messages are generated to give status. These
   can be either at a certain period of time, or at some other interval
   such as the invocation or exit of a program.  In other cases, the
   messages may be generated due to a set of conditions being met.  In
   those cases, either a status message or a message containing an alarm
   of some type may be generated.  It was considered that the writers of
   the operating systems, processes and applications would quantify
   their messages into one of several broad categories.  These broad
   categories generally consist of the facility that generated them,
   along with an indication of the severity of the message.  This was so
   that the operations staff could selectively filter the messages and
   be presented with the more important and time sensitive notifications
   quickly, while also having the ability to place status or informative
   messages in a file for later perusal.   Other options for displaying
   or storing messages have been seen to exist as well.

   Devices MUST be configured with rules for displaying and/or
   forwarding the event messages.  The rules that have been seen are
   generally very flexible.  An administrator may want to have all
   messages stored locally as well as to have all messages of a high
   severity forwarded to another device.  They may find it appropriate
   to also have messages from a particular facility sent to some or all
   of the users of the device and displayed on the system console.
   However the administrator decides to configure the disposition of the
   event messages, the process of having them sent to a syslog collector
   generally consists of deciding which facility messages and which
   severity levels will be forwarded, and then defining the remote
   receiver.  For example, an administrator may want all messages that
   are generated by the mail facility to be forwarded to one particular
   event message collector.  Then the administrator may want to have all
   kernel generated messages sent to a different syslog receiver while,
   at the same time, having the critically severe messages from the
   kernel also sent to a third receiver.  It may also be appropriate to
   have those messages displayed on the system console as well as being
   mailed to some appropriate people, while at the same time, being sent
   to a file on the local disk of the device.  Conversely, it may be
   appropriate to have messages from a locally defined process only
   displayed on the console but not saved or forwarded from the device.
   In any event, the rules for this will have to be generated on the
   device.  Since the administrators will then know which types of
   messages will be received on the collectors, they should then make
   appropriate rules on those syslog servers as well.