LINUX保存了系统中所发生事件的详细记录,这些记录称作日志文件或消息文件.可以查阅日志文件来确定系统当前状态,观察入侵者踪迹,寻找某特定程序(或事件)相关的数据.
syslogd与klogd(监控linux内核提交的消息)守护进程负责记录,发送系统或工具产生的信息,二者的配置文件都是/etc/syslog.conf.当系统内核或工具产生信息时,通过调用相关函数将信息发送到syslogd或klogd守护进程.syslogd与klogd守护进程会根据/etc/syslog.conf中的配置信息,对消息的去向作出处理.
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
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个操作符进行修改.
等于操作符(=)表示仅对这个级别的消息进行操作,不等操作符(!)表示忽略这个级别以及更严重级别的消息.这两个操作符可以同时使用,不过"!"必须出现在"="的前面.
关键字 值 解释
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”.
动作确定了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文件中后面的配置行不会覆盖前面的配置行,每一行指定的动作都独立的运作.
(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
//将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
mail.* -/var/log/maillog
//将authpirv设备的任何级别的信息记录到/var/log/secure文件中,这主要是一些和权限使用相关的信息.
authpriv.* /var/log/secure
//将cron设备中的任何级别的信息记录到/var/log/cron文件中,这主要是和系统中定期执行的任务相关的信息.
cron.* /var/log/cron
cron.* /var/log/cron
//将任何设备的emerg(系统不可用)级别的信息发送给所有正在系统上的用户.
*.emerg *
*.emerg *
//将uucp和news设备的crit(临界)级别的信息记录到/var/log/spooler文件中.
uucp,news.crit /var/log/spooler
uucp,news.crit /var/log/spooler
//将和系统启动相关的信息记录到/var/log/boot.log文件中.
local7.* /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
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.
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.
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.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.
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.
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.
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.
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.
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.