Syslog在网络管理中的应用



摘要
Syslog是一种工业标准的协议，可用来记录设备的日志。在UNIX系统，路由器、交换机等网络设备中，系统日志（System Log）记录系统中任何时间发生的大小事件。管理者可以通过查看系统记录，随时掌握系统状况。UNIX的系统日志是通过syslogd这个进程记录系统有 关事件记录，也可以记录应用程序运作事件。通过适当的配置，我们还可以实现运行syslog协议的机器间通信，通过分析这些网络行为日志，藉以追踪掌握与 设备和网络有关的状况。
关键词：Syslog，Syslogd，Priority（PRI），Facility，Severity，Header，Message（MSG），Timestamp。
1．引言
    电信运营商的网络庞大而复杂，其上运行着多种网络设备、主机系统以及业务应用。而且随着电信业的不断发展，各种新业务的推出，不同的系统纷纷建立，网络的 复杂性不断增长，使得被管理的对象在系统中不是集中的而是分散的。分布式的管理必然要求网络管理员在网络的协议层次结构上对系统管理做出重新的认识，通过 适当的策略实现集中式管理，实现事件的实时监控和快速响应的网络管理。传统的网络管理员关心的问题不单是安装配置、备份恢复、系统安全、性能优化等，还必 须从OSI模型不同的层次重新考虑系统管理的内容和形式，再加上承载业务的特点，侧重于事件监控和响应的建设是当今网络管理的主要方向。
2．网络管理的原则和要求
    从技术的角度来说，网络管理有两条原则：1、由于管理信息而带来的通行量不应明显的增加网络的通信量。2、被管理设备上的协议代理不应明显得增加系统处理 的额外开销，以致于该设备的主要功能都被削弱。网络管理的对象主要是构成网络的硬件和软件应用所组成。这一类包括工作站、服务器、网卡、路由器、网桥和集 线器等等。通常情况下这些设备都分散在不同的地方，另外由于设备众多，要做到实时实地管理需要大量的人力和物力。有什么办法可以对网络设备进行远程管理和状态进行预警呢？
3．集中式网络管理的实现
    实际工作中，由于管理员不可能7×24小时监视着网络设备，网络运行中可能会发生很多突发情况。因此，使用日志记录设备的报警信息十分重要，管理员可以借此对安全事件进行原因追查和故障排除等工作。以路由器为例，一般都会设定内存保留Syslog。但路由器的内存（Buffer）容量有限，大量事件发生 时，会覆盖之前的记录，不利于实时预警和报告。而对UNIX系统来说，由于管理设备的多样性和数量的缘故，一台台登录访问日志效率低下也不现实。所以有必要建立专门的日志服务器，通过Syslog服务，接收设备发送出的报警信息。
4．Syslog在网络管理中的应用
4.1. Syslog Protocol简介
    Syslog是一种工业标准的协议，可用来记录设备的日志。在UNIX系统，路由器、交换机等网络设备中，系统日志（System Log）记录系统中任何时间发生的大小事件。管理者可以通过查看系统记录，随时掌握系统状况。在UNIX系统里，被syslog协议接受的事件可以被记录 到不同的文件，还可以通过网络实现运行syslog协议的机器之间的信息传递。
Syslog已被许多日志函数采纳，它用在许多保护措施中——任何行为都可以通过syslog 记录事件。通过System Call，记录用户自行开发的应用程序的运行状况。日志系统的重点之一便是要研究及开发一些系统程序，例如logger等，将网络应用程序重要的行为向 syslog接口呼叫并记录为日志，大部分内部系统工具如邮件和打印系统都是如此生成信息的，许多新增的程序如Tcpwrappers和SSH也是如此工 作的。通过syslogd（负责大部分系统事件的daemon），系统事件可以写到一个文件或设备中，或给用户发送一个信息。它能记录本地事件或通过网络 记录远端设备上的事件。  

<!--[endif]-->
图1   Syslogd运作图
4.2. Syslog在网络管理方面应用
    Syslog协议提供了一个传递方式，允许一个设备通过网络把事件信息传递给事件信息接受者(也称之为日志服务器)。由于每个进程、应用程序和操作系统都 或多或少地被独立完成，在syslog信息内容会有一些不一致的地方。因此，协议中并没有任何关于信息的格式或内容的假设。这个协议就是简单地被设计用来 传送事件信息，但是事件已经被接受到不会被通知。Syslog协议和进程最基本原则就是简单，在协议的发送者和接受者之间不要求有严格的相互协调。事实 上， syslog信息的传递可以在接受器没有被配置甚至没有接受器的情况下开始。反过来，在没有被清晰配置或者定义的情况下，接收器也可以接收到信息。
    几乎所有的网络设备都可以通过syslog protocol将日志信息以UDP方式传送到远端服务器，远端接收日志服务器必须通过syslogd来监听UDP Port 514，并且根据syslog.conf中的配置来处理本机和接收访问系统的日志信息，把指定的事件写入特定档案中，供后台数据库管理和响应之用。也就是 说可以让任何所产生的事件都登录到一台或多台服务器上，以便后台数据库可以相对远端设备以Off-line的方法分析事件。

                            图2日志分析系统架构图
4.3. Syslog的格式说明
    设备必须通过一些规则来配置，以便显示或者传递事件信息。不管管理员决定怎样配置对事件信息的处理，把这些信息发送到syslog接受者的过程一般都由下面部分构成：决定哪个帮助信息要被发送，要被发送的级别，定义远程的接受者。
    被传输的syslog信息的格式主要有3个容易识别出来的部分，分别是PRI、HEADER、MSG。数据包的长度小于1024个 字节。PRI部分必须有3、4、5个字符，以“<”开头，然后是一个数字，并以“>”结尾。在方括号内的数字被称为优先级（Priority），由facility和severity两个值构成。信息中的facilities和severities通过十进制值进行数字的编 码。一些操作系统的后台监控程序和进程被分配一个facility值，那些没有分配一个facility值的进程和daemons将会使用“local use”的facilities值或者“用户级别”的facilities值。下面的表格表示被指定的Facilities值和对应的数字代码。
Numerical Code            Facility
0                    kernel messages                             
1                  user-level messages 
2                  mail system       
3                  system daemons                              
4                  security/authorization messages             
5                  messages generated internally by syslogd    
6                  line printer subsystem                      
7                  network news subsystem                      
8                  UUCP subsystem                              
9                  clock daemon                                
10                  security/authorization messages             
11                  FTP daemon                                  
12                  NTP subsystem                               
13                  log audit                                   
14                  log alert                                   
15                  clock daemon                                
16                  local use 0  (local0)                    
17                   local use 1  (local1)                       
18                   local use 2  (local2)                       
19                   local use 3  (local3)                       
20                   local use 4  (local4)                       
21                   local use 5  (local5)                       
22                   local use 6  (local6)                       
23                   local use 7  (local7)                       
                      表1    Syslog Message Facilities
每个信息优先级也有一个表示十进制Severity登记的参数, 下面的表格描述出他们和对应数值。
Numerical Code                 Severity
         
0                   Emergency
1                   Alert
2                   Critical
3                   Error
4                   Warning
5                   Notice
6                   Informational
7                         Debug
                           
表 2   Syslog Message Severities
    Priority（优先级） = facility * 8 + severity值。比如说，一个核心信息（facility=0）和一个Emergency的severity将会产生优先级为0。同样， 一个“local use 4”信息（facility=20）和一个Notice的severity（severity=5）将会产生165的优先级。
    标题（HEADER）部分由称为TIMESTAMP和HOSTNAME的两个域组成，PRI结尾的“>”会马上跟着一个 TIMESTAMP，任何一个TIMESTAMP或者HOSTNAME域后面都必须跟着一个空格字符。HOSTNAME包含主机的名称，若无主机名或无法 识别则显示IP地址。如果一个主机有多个IP地址，它通常会使用它传送信息的那个IP地址。TIMESTAMP是本机时间，采用的格式是“Mmm dd hh:mm:ss”表示月日时分秒。HOSTNAME域仅仅能够包括主机名称，Ipv4地址或者是信息产生者的Ipv6地址。
    MSG部分是Syslog数据包剩下的部分。这通常包含了产生信息进程的额外信息，以及信息的文本部分。MSG部分有两个域，分别为TAG域和 CONTENT域，TAG域的值是产生信息的程序或者进程的名称，CONTENT包含了这个信息的详细内容。传统上来说，这个域的格式较为自由，并且给出 一些时间的具体信息。TAG是一个不许超过32个字符的字母数字字符串，任何一个非字母数字字符都将会终止TAG域，并且被假设是CONTENT域的开 始。在大多数情况下，表示TAG结束的CONTENT域的第一个字符用左大括号( [ ],分号( : )或者是空格来表示。
4.3. Syslog的发送和接收
    接受端服务器收到发送给它的syslog数据包，它将检查它的有效PRI。如果第一次字符不是一个“<”，或者第三、第四或者第五不是一个 “>”，接收端将认为数据包没有包含有效的PRI。接着检查在标题部分的有效TIMESTAMP，从这些规则中，信息的接收一般有三个情况，下面给 出了这三个情况的通常属性，并列举了随后在这篇中什么地方会描写这些情况。
    有效的PRI and TIMESTAMP：在数据包中发现一个有效的PRI和TIMESTAMP，那么会接着检查数据包的内部配置，接收端必须根据数据包的优先级来还原，或者 在不对数据包做任何变化的情况下将它转发出去。这里要注意到的是接受端没有必要确认TIMSTIMP里面的时间，同时接收端也没有必要确认 HOSTANME的值和发送信息设备的主机名或者IP地址一致。
    有效的 PRI，但没有TIMESTAMP 或者TIMESTAMP无效：要是在数据包中发现一个有效的TIMESTAMP，那么必须马上添加一个TIMESTAMP和一个空格字符在PRI部分的结 尾的方括号内，它还必须添加一个HOSTNAME和空格字符在TIMESTAMP后面，接收到的信息包剩下的部分必须被当曾MSG的CONTENT域并附 加上，由于无法识别产生信息的设备所发出的进程，TAG的值无法被识别出来， 所以不会包含再里面。TIMESTAMP将会是接收端的本地时间，HOSTNAME是设备的名称，它被中继器所识别。如果名字如能被决定, 设备的IP地址将被使用到。要是中继器添加一个TIMESTAMP(或者同时添加TIMESTAMP和HOSTNAME)在PRI后面, 然后检 查是否数据包的总体长度仍然小于或等于1024个字节。如果数据包被扩展超过1024个比特, 中继器必须截去一部分数据包数据使它到达到1024比特。这将会导致原始数据包结尾部分重要信息的丢失. 所以，这就是产生的syslog数据包的PRI和HEADER部分包含在4.3节所记录的值和域之中的缘故。
    没有 PRI or 或者 PRI无法识别：如果收不到PRI或者PRI不可识别，除了必须插入一个优先级为13的PRI和我们在上面描述的TIMESTAMP，还必须插入一个 HOSTNAME。被接收到的数据包的全部内容将被认为是被传递的MSG的CONTENT并被添加在后面。一个不可识别的PRI的例子就是“< 00>”，这也许是一个信息的前4个字符。如果接收到这样的syslog信息，那么它的优先级将被中继器或收集者改为13，并且加入 TIMESTAMP。具体如下：
      原来接收到的信息
<00>...
被传递或识别的信息
<13>TIMESTAMP HOSTNAME <00>...
    如果中继器添加一个TIMESTAMP(或者同时添加一个TIMESTAMP和HOSTNAME)在PRI后面, 那么它将检查这个数据包的总体长度是否等于或者小于1024个比特。
    在UNIX文件系统里头，syslog设备依据两个重要的文件：syslogd（守护进程）和syslog.conf配置文件。习惯上，多数syslog信息被写到/var/adm或/var/log目录下的信息文件中（syslog或messages.*）。一个典型的syslog纪录包括生成程序的名 字和一个文本信息。它还包括一个设备和一个优先级范围（但不在日志中出现）。Syslog.conf的格式比较复杂，大家可以参考一下有关书籍（或者在主 机上man syslog.conf），主要是如下语句形式： facility、level、action。Facility代表各种服务，level代表syslog的认证级别，action代表的是针对前面信息 的处理动作。Action字段如果是@loghos（主机名或具体IP），则把信息发送到loghost，而不是本地的 /var/adm/messages。
4.4. 配置实例
4.4.1 UNIX à UNIX服务器
接收端设置：
我们采用一台Sun服务器作为日志接收服务器（Hostname：nmtest1-yd，IP为192.168.3.71）。一般情况下，UNIX系统的 本地系统日志都存放在/var卷下（Solaris系统默认存放在/var/adm/messages），当然我们也可以更改存放路径。根据需求，配置syslogd.conf文件，重启syslogd应用。监控应用多的话，message可能会增大很多，可以做一些简单的分类即可。
# vi   /etc/syslogd.conf
kern.crit  /dev/console       *把kern.crit、kern.alert及kern.emerg相关信息送到系统consle
authpriv.* /var/log/securelog   
mail.info;mail.!err /var/log/maillog   *把mail信息priority大于等于info，但priority为error除外的信息记录
发送端设置：（一台Sun服务器，IP为192.168.3.72）
指定好loghost，让后编辑/etc/syslog.conf，将原先的设定
*.info;mail.none;authpriv.none;cron.none[Tab]/var/log/messages
改成：
*.err;kern.debug;daemon.notice;mail.crit[Tab]/var/log/syslog@192.168.3.71
    保存后退出，在两台服务器上重启syslogd进程。在接收端和发送端上通过snoop监听514端口状况。可以发现有包进出。在nmtest1-yd上查看/var/log/syslog，可以发现：
Nov 23 18:17:25 [192.168.3.72.159.195] sendmail[17259]: unable to qualify my own domain name (nmtest2-yd) -- using short name
Nov 23 18:17:25 [192.168.3.72.159.195] sendmail[17895]: My unqualified host name (nmtest2-yd) unknown; sleeping for retry
Nov 23 18:17:25 [192.168.3.72.159.195] last message repeated 1 time
4.4.2 路由器à UNIX服务器
接收端设置：
我们采用一台Sun服务器作为日志接收服务器（Hostname：nmtest1-yd，IP为192.168.3.71），配置syslog.conf文件。
local0.info[Tab]/var/log/hw.log
保存退出，并生成hw.log空文件，touch /var/log/hw.log。
发送端设置：
router1# conf
router1(config)# logging on
router1(config)#loggin 192.168.3.71
router1(config)#logging facility local0
router1(config)#logging trap info
router1(config)#logging timestamps log datetime localtime  
在nmtest1-yd上查看/var/log/hw.log，可以发现：
Nov 18:17:25: %LINK-3-UPDOWN: Interface POS2/0/0, changed state to up
Nov 18:17:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed state to up
Nov 18:17:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/1, changed state to up
Nov 18:17:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0/0, changed state to up    
5. 结束语
    结合syslog进行集中式网络管理，应先了解系统日志运作原理，并且能够依照本身需求，灵活运用日志系统，打造一个适合自身的记录环境。这种方法也存在不足之处，由于syslog是以UDP方式传送，个别的日志消息可能会遗失；在网络设备崩溃的情况下，可能不会将最有用的信息发送到syslog服务器 上，这对于排除崩溃故障不是很有用；而且syslog日志服务器容易成为攻击者的目标，对于防范系统方面的攻击比较脆弱，需要特别注意。