linux操作系统日志系统详解
日志对于安全来说，非常重要，他记录了系统每天发生的各种各样的事情，你可以通过他来检查错误发生的原因，或者受到攻击时攻击者留下的痕迹。日志主要的功能有：审计和监测。他还可以实时的监测系统状态，监测和追踪侵入者等等。下面大家与小编一起来学习一下linux操作系统日志系统详解吧。
linux操作系统日志系统
每个操作系统中都有自己的强大的日志功能，windows有，而linux同样也有;linux操作系统中的日志功能主要通过服务syslog来实现(RedHat6.0以后使用的是syslog-ng)，而syslog服务下有两个进程syslogd和klogd，这两个进程一个用来记录系统日志信息，一个用来记录内核日志信息;但是操作系统在运行中会产生非常多的日志信息，如果我们将这些信息都记录下来的话，那我们的磁盘I/O一定很繁忙，这对系统的性能有很大的影响，这就有违了我们的初衷，所以我们根据产生日志的来源和日志信息的重要性，将系统运行中所产生的日志进行分类;syslogd和klogd两个进程所记录的日志信息和详细程度又各有不同：
Klogd：记录了系统初始化时所产生并显示在物理终端上的信息，并保存在”/var/log/dmesg”文件中，我们可以使用“cat /var/log/dmesg”进行查看，也可以使用专门的命令“dmesg”进行查看
Syslogd：在系统初始化完成，将系统控制权转交给init，此时产生的日志信息都有syslogd记录，并存放在“/var/log/messages”文件中，主要保存的信息有“系统标准错误日志信息，非内核产生的引导信息，各个服务程序的子系统产生的信息等等”;在监控系统运行时一般使用“# tail -f /var/log/messages”来监控新生成的日志信息
但是系统运行中所产生的信息非常多，即使只记录这些信息，也有很大量;此时如果我们仍然将所有日志信息都保存在一个messages文件中，那么管理起来就非常困难了;那这怎么办呢?我们引进了另外一种技术“日志滚动”
日志滚动：当日志messages文件大小或时间到一定程度之后，将这个文件定义为messages.1，并重新创建一个新的messages文件，此时messages.1不再记录新的内容，只是存放以前的内容，如果新的messages文件再次达到这个标准之后，现在这个messages文件重命名为messages.1，原有的messages.1命名为messages.2，这样依次类推;但是这样一直滚动下去，很久以前的日志信息对我们现在管理已经没有很大用处了，所以我们可以定义只保留滚动多少次的日志文件;所以日志信息我们应该经常滚动，且一般定义多个标准
日志的滚动就是将这个日志文件进行切割，在redhat上有一个专门的命令可以完成这个动作：logrotate;系统上有一个专门的系统任务计划来完成日志切割“/etc/cron.daily”下有一个脚本叫做logrotate，这个命令的配置文件在“etc/logrotate.conf”下(定义了系统的日志滚动机制)
内容格式是：
weekly #全局定义每周滚动一次
rotate 4 #只保留四个滚动版本
include /etc/logrotate.d #上面几行是日志系统全局属性，下面是各个小系统的具体属性，执行时以局部属性为准;局部日志属性可定义多个
/var/log/wtmp { #定义这个子系统自己的日志滚动机制，日志存放文件
monthly #多长时间滚动一个
minsize 1M #日志文件最小1M
create 0664 root utmp #创建一个文件，权限是0664，属主是root，文件名是utmp
rotate 1 #只保留一个滚动版本
}
日志滚动的脚本文件：# vim /etc/cron.daily/logrotate
如果不自己定义，则按照全局定义的日志滚动属性，也可以在“/etc/logrotate.d/cups”文件下定义：
一些其他子系统产生的日志信息保存位置：
/var/maillog #邮件系统产生的日志信息
/var/log/secure #每个用户在登录时所产生的安全信息(什么时间谁以哪个用户来自哪个主机尝试登录，尝试了几次，这个文件经常查看)
syslog的配置文件在：/etc/syslog.conf
这个配置文件格式是：每一行都定义一个子系统产生的哪些级别的日志记录到什么位置
facility.priority action
Facility：日志来源
auth #认证子系统产生的
authpriv #权限授权子系统产生的
cron #任务计划子系统产生的
daemon #守护进程子系统产生的
kern #内核子系统产生的,定义klogd的记录内容
lpr #打印子系统产生的
mail #邮件子系统产生的
mark #标记子系统产生的
news #新闻子系统产生的
security #安全子系统产生的，与auth来源类似
syslog #定义syslog自己的要记录的
user #用户子系统所产生的的
uucp #Unix to unix cp子系统所产生的
local0-->local7 #用户自定义使用
* #所有来源
Priority(log level)日志级别：(级别越低记录的越详细)
debug #程序或系统的调试信息(记录非常详细，一般只在系统无法启动，排除错误时使用)
info #一般信息
notice #不影响系统正常功能，但需要注意的信息
warning/warn #可能影响系统功能，需要提醒用户注意的重要事件;这种信息可能会引起部分功能的运行
err/error #错误信息，已经影响系统部分功能;蓝色警报
crit #比较严重的信息;橙色警报
alert #必须马上处理的信息;红色警报
emerg/panic #导致系统不可用的信息;一般这一刻出现，下一刻系统就会down掉
* #所有日志级别，类似debug
none #和*相反，表示哪个级别都没有
Action(动作)指定日志记录的位置：
系统上的绝对路径 #普通文件，如/var/log/***
| #通过管道送给其他命令处理
终端 #显示在哪个终端(物理终端，虚拟终端，伪终端等等)
@HOST #远程主机;产生的日志信息，自己不记录，而传送给其他主机记录，一般用于日志服务器，可以增强当前服务器的安全;默认情况下只为自己记录日志信息
【如果要使得我们的服务器称为日志服务器，只需在“/etc/sysconfig/syslog”文件中的"SYSLOGD_OPTIONS="-r -m 0""这一行中添加一个“-r”选项，重新启动服务即可开启日志服务器功能】
用户 #产生的日志信息都发送给某个用户，如root
* #登录到系统上的所有用户，一般emerg级别的日志是这样定义的
syslog日志服务属性定义实例：
mail.info /var/log/maillog #将mail相关的级别为info及info以上级别的信息记录到/var/log/maillog文件中
auth.=info @10.0.0.1 #将auth相关的info级别的信息记录到10.0.0.1主机上，前提是10.0.0.1主机能够接收到其他主机发来的日志信息(此时只记录info级别)
user.!=error #记录与user相关的，但不记录error级别的信息，只记录其他所有级别
user.!error #与user.error相反，此时只记录比error级别低的日志信息
*.info #记录所有可能产生日志子系统的info级别及其以上级别的日志信息
mail.* #记录与mail所产生的所有级别的日志信息
*.* #记录所有日志信息
cron.info;mail.info #记录cron相关的info及以上级别的日志信息和mail相关的info和以上级别的日志信息，多个日志来源之间以“;”分号隔开
cron,mail.info #和上边是一个意思，如果两个日志来源的记录级别相同，可以缩写，来源之间以“,”逗号隔开
mail.*;mail.!=info #记录与mail相关的所有级别的日志信息，但不包括info级别的所有信息
Syslog的默认配置文件定义解释：
# cat /etc/syslog.conf
*.info;mail.none;authpriv.none;cron.none /var/log/messages #所有可能产生日志信息的子系统的info级别及以上级别的日志信息，都保存在messages文件中，但是不包括mail，authpriv，cron子系统的
authpriv.* /var/log/secure #所有用户授权的日志信息都记录到secure文件中
mail.* -/var/log/maillog #所有邮件子系统产生的日志信息都异步保存在maillog文件中，“-”表示异步写入，其他日志信息都要同步写入
cron.* /var/log/cron #所有任务计划的日志信息都记录到cron文件中
*.emerg * #无论系统上哪个程序产生emerg级别的信息，都立即通知给系统上的所有用户，马上就要down机了
uucp,new.crit /var/log/spooler #来自uucp和new子系统的crit级别的信息都保存在spooler文件中
local7.* /var/log/boot.log #自己定义的日志记录，此处系统默认定义的是系统引导信息，保存在boot.log文件中;但此处并没有���义谁向这个文件中填写，所以这个文件是空文件，我们需要在其他文件中定义这个日志信息要发送到local7中，才会写到boot.log文件中，一般意义不大
这个文件保存之后日志系统配置文件并不会立即生效，此时如果我们使用“service syslog restart”命令来重启日志服务，可能会使得其他一些正在记录日志信息的子系统不能完整的记录，所以我们一般使用“service syslog reload”来重读配置文件，并生效，相当与发送1号信号。