Skip to main content


配置思科的日志系统

2013-12-20 17:17 浏览:

  企业级日志系统是记录整个企业级网络设备(包括服务器、路由器、交换机、防火墙、入侵检测、入侵防御等)所产生的行为的,对发现和修复网络故障、安全违例事件的追查、网络犯罪证取、性能监视等有着不可忽视的作用。所以,收集各种网络设备上的日志有着重要的价值。实现收集日志需理解如下知识点:

 

n收集日志的范围。

n日志消息的组成。

n日志消息的编码。

n集中收集日志的组件。

n日志文件类型的相互转换。

 

关于收集日志的范围:

   包括服务器操作系统的日志、路由器与交换机的日志、防火墙的日志、入侵检测与入侵防御的日志。服务器与操作系统的日志:服务器与操作系统的日志是记录服务器与操作系统中硬件、软件问题的信息,同时还可以监视系统中发生的事件。用户可以通过它来检查错误发生的原因,或者寻找受到攻击时攻击者留下的痕迹。路由器与交换机的日志:路由器与交换机的日志是记录路由器与交换机的运行状况的,如接口状态、安全警告、环境条件、CPU处理率及路由器的其他事件都可以被一台集中日志服务器收集并分析。防火墙的日志:防火墙的日志能够让网络管理员清晰地检测到是否有非法攻击者正在对企业网络进行攻击,而且也能够允许网络管理员基于通信的关键信息对日志进行过滤,快速取得防火墙日志的核心内容。入侵检测系统与入侵防御系统的日志:日志记录是入侵检测与入侵防御设备的一个重要特征,这些设备都提供了精确的日志记录功能。比如,当网络正在受到攻击或者入侵时,系统将产生攻击报警或错误信息,会把相应的事件进行归档和分类,再根据不同紧急程度或破坏程度向网络管理员提出报警,让网络管理员能及时防御网络违例事件。

 

关于日志消息的组成:

   一个通用的日志消息组成大概分成3个部分:等级代码、日志头文件和日志信息文本。等级代码表示设备或操作系统产生日志信息的严重级别;日志头文件包含产生日志事件的时间、产生日志的网络元件名称、IP地址等;日志信息文本包括一个文本消息的说明和与该说明有关的附加信息,一般这个部分的长度小于或者等于1024B,如果没有经过特殊处理,该信息以明文的方式进行传递,如图10.44所示。

 

 

日志消息的编码:

  日志消息的设备和严重级别信息要用十进制数字编码。很多的操作系统的常驻进程和普通进程都指定了一个设备编号,如图10.45所示。表1所示的是常规被定义的日志消息编码与对应的说明。如果一个消息或进程没有被明确指定一个设备编号,那么它就可以使用本地的设备号或本地用户级的设备号。例如:没有被思科列入常驻进程消息的日志将使用一个名为“local7”的本地设备号对日志消息进行编码,当然也可以更改。

 

关于集中收集日志的组件:

   集中收集日志的优势在于与其把各个设备产生的关键信息分散地放置在设备本地,不如考虑集中地收集和存储这些重要信息。“分散网络管理不如集中网络管理;分散安全管理不如集中安全管理”,即到达每台产生日志的本地查看日志事件,不如在一个物理位置统一查看日志事件,这样会更方便和高效。

   集中收集日志的组件有3个部分:日志消息产生源、收集协议、日志软件。通常日志消息的产生源是一个网络元件,可以是服务器、路由器、交换机、防火墙、入侵检测或者入侵防御系统等。收集协议是指将网络元件所产生的日志消息运载到日志收集平台的一个通信协议。它是网络元件与日志软件之间的一种通信方式,如Syslog就是使用UDP的514号端口来运载日志消息。日志软件是指集中收集网络上各种设备所产生日志的用户应用平台(通常也叫做日志服务器),它可以直接与用户进行交互,提供用户随时查看具体某个时间段、某个IP地址所产生的具体日志信息等,还可以对收集的日志进行分类与过滤管理,从而方便用户快速地搜索并排除与故障相关的核心日志。

 

关于日志文件类型的相互转换:

   一般情况下,日志文件的格式有两种:一种是基于Windows的日志文件格式;另一种是基于Syslog的日志文件格式。基于Syslog的日志文件格式是UNIX或Linux操作系统所支持的一种日志文件格式,大多数情况下网络设备(路由器、交换机)所产生的日志格式都是基于Syslog格式,比如思科就是使用syslog格式日志。Windows的日志只支持3种类型分类,具体如表2所示。而Syslog日志格式定义了8种类型的日志级别,具体如表3所示。

 

 

  值得关注的第一个问题:如果需要部署集中收集日志,那么针对上述情况提出一个问题:既然Windows与网络设备、UNIX、Linux的日志分别使用两种不同方式的日志类型,那么怎样对两种不同类型的日志进行集中收集呢?因为在一个真实的企业级网络环境中,应该既有Windows服务器,也有UNIX、Linux服务器,还有网络设备。那么,如何做到将不同日志文件类型做转换与收集呢?

 

   首先,虽然Windows有产生日志和收集本地主机日志的功能,但是它不具备将企业级网络当中的各种不同网络元件所产生的日志进行集中收集的功能。如果需要对企业级网络中的日志进行集中收集,那么需要部署一个集中收集日志的服务端。这种服务端的应用软件有很多,有商业版本的、有免费版本的,如KiWi Syslog就是一个免费的集中收集日志的服务端软件。Kiwi Syslog 软件是基于 Windows 的Syslog 服务器解决方案之一。这些产品的安装与配置非常简单,提供功能丰富的解决方案来接收、记录、显示并转发各种网络设备(如路由器、交换机、UNIX 主机及其他启用Syslog 的设备)的Syslog 消息

 

  值得关注的第二个问题:现在使用Syslog软件解决了集中收集日志服务端的问题,接下来需要解决的是,Syslog是基于Syslog日志消息类型的软件,这与基于“Windows事件查看器”里面的日志类型不是一种格式,那么,怎么才能把Windows所产生的日志类型转换成Syslog能够理解的日志类型显得非常重要?

 

   基于Windows日志客户端的NTSyslog是安装在Windows上的日志客户端软件,是一款相当不错的软件。NTSyslog不会用自身的方式去创建日志消息,它会采取一种非常干净的做法——将Windows自身产生的日志信息转化成一种Syslog能够识别和兼容的格式,然后再把转换后的格式发送到Syslog服务器进行集中存储与管理。这样既不会产生多余的非Windows系统产生的日志,又能让Syslog服务器理解它。

 

演示:配置控制台日志并保存到buffered区域

 

演示目标:配置控制台日志并保存到buffered区域。

演示环境:如下10.47所示的演示环境。

 

演示背景:默认情况下路由器或者交换机所产生的日志消息会直接发送到控制台,但是不会保存,在该演示实验中,将调整路由器向控制台发送日志消息的等级、关闭控制台日志功能、将控制台日志保存到缓冲区。

演示步骤:

 

第一步:默认情况下,思科的路由器会将上述表3中等级为0、1、2、3、4、5、6的日志消息显示到控制台(console),比如:当您退出全局配置模式、关闭或者激活接口时,都会有日志消息出现在控制台上,如下图10.48所示,这样做的目标是方便随时提醒管理员现在的操作和设备当前的状态,发到控制台(console)的日志,是临时的,路由器不会保存它。控制台默认不将7级日志(debug)显示到控制台,是为了考虑对路由器性能产生的额外过大开销的问题,因为这样做会在路由器的控制台上显示每条消息。

有时侯管理员可能会嫌控制台出现太多的日志信息使整个显示不太清爽,此时您可以订制,些等级的日志可以显示在控制台上,如下所示的配置指示路由器R1只像控制台发送0、1、2、3重要的日志消息,不再向控制台发送4、5、6类型的日志消息,当完成配置后其结果如下10.49所示,此时,管理员退出或进入全局配置模式,手工关闭接口都不会再向控制台发送相关日志消息,只有激活接口时,报告了类型3的日志。

 

要求只将类型3以上的日志发送给控制台:

R1(config)#logging console 3* 向控制台发送0、1、2、3等级的日志。

 

第二步如果您不希望控制台出现任何日志消息,可以使用如下配置关闭向控制台发送日志消息的功能,关闭后再操作路由器R1,如下图10.50所示,任何操作都不会再有消息提示,建议管理员不这样做,除非您自认是真正的专家并清晰的知道路由器当前的每个状况,不然会为您在配置过程中的故障排除产生难度,这好比是给狙击手蒙上了双眼。

 

关闭控制台的日志提示功能:

R1(config)#no logging console* 不向控制台(console)发送任何日志

 

第三步:控制台产生的日志所产生的日志消息是一种即时消息,不会做保存,思科的路由器可以将日志消息保存在缓冲区(buffered)中,这个保存是暂时的,它会随路由器的重新启动而丢失所保存的日志消息,因为它是从路由器RAM中获得暂存空间,一般建议:如果路由器的RAM过16MB,那么建议将日志缓冲区的大小设置为32KB或者64KB,具体配置如下所示:

 

关于配置日志消息缓冲区的指令:

R1(config)#logging on* 开启日志记录功能

R1(config)#logging buffered 64000* 定义保存日志消息的缓冲区大小为64K。

 

当完成上述配置后,现在可以为路由器R1的E1/0接口配置IP地址,并活动接口,然后通过show logging指令查看保存在缓存区中的日志信息,如下图10.51所示,可明显看出配置日志缓冲的大小,并记录了接口状态变化的日志。

本文出自 “无名的基督” 博客