当前位置: 首页 > 图文教程 > 服务器 > 安全防护 > 多服务器的日志合并统计(2)

安全防护
网站被入侵后需做的检测
防范WEB SHELL
检测 Unix是否被入侵最快捷的方法
防范SQL指令植入式攻击
怎样搞好IIS的安全?
ASP+Access的安全隐患及对策
三步堵死SQL注入漏洞
跨站式SQL注入技巧
网站服务器通用和专用保护方法比较分析(1)
网站服务器通用和专用保护方法比较分析(2)
网站服务器通用和专用保护方法比较分析(3)
黑客的木马:Web应用程序
偷看ASP原码的6种方法
入侵动易2005
有关IIS HACK的一些方法整理
净化网络 让不良内容远离80端口
给WIN2003 IIS SQL服务器安全加固
巧用KWF 打造与众不同的VPN服务器
FSO 安全隐患解决办法
ASP木马Webshell安全解决办案

安全防护 中的 多服务器的日志合并统计(2)


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-10-29   浏览: 48 ::
收藏到网摘: n/a

{2} 日志的轮循机制:

  让我们关心一下数据源问题:webalizer其实是一个按月统计的工具,支持增量统计:因此对于大型的服务,我可以按天将apache的日志合并后送给webalizer统计。WEB日志是如何按天(比如每天子夜00:00:00)截断呢?

  如果你每天使用crontab:每天0点准时将日志备份成accesserials_log_yesterday


  mv /path/to/apache/log/accesserials_log
    /path/to/apache/log/accesserials_log_yesterday



  的话:你还需要:马上运行一下:apache restart 否则:apache会因为的日志文件句柄丢失不知道将日志记录到哪里去了。这样归档每天子夜重启apache服务会受到影响。

  比较简便不影响服务的方法是:先复制,后清空


  cp /path/to/apache/log/accesserials_log /path/to/apache/log/accesserials_log_yesterday
  echo >/path/to/apache/log/accesserials_log



  严肃的分析员会这样做发现一个问题:

  但cp不可能严格保证严格的0点截断。加入复制过程用了6秒,截断的accesserials_log_yesterday日志中会出现复制过程到00:00:06期间的日志。对于单个日志统计这些每天多出来几百行日志是没有问题的。但对于多个日志在跨月的1天会有一个合并的排序问题:


  [31/Mar/2002:59:59:59 +0800]
  [31/Mar/2002:23:59:59 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]


  
  要知道[01/Apr/2002:00:00:00 这个字段是不可以进行“跨天排序”的。因为日期中使用了dd/mm/yyyy,月份还是英文名,如果按照字母排序,很有可能是这样的结果:排序导致了日志的错误


  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [01/Apr/2002:00:00:00 +0800]
  [31/Mar/2002:59:59:59 +0800]
  [31/Mar/2002:59:59:59 +0800]
  [31/Mar/2002:23:59:59 +0800]
  [31/Mar/2002:59:59:59 +0800]
  [31/Mar/2002:23:59:59 +0800]



  这些跨天过程中的非正常数据对于webalizer等分析工具来说简直就好像是吃了一个臭虫一样,运行的结果是:它可能会把前一个月所有的数据都丢失!因此这样的数据会有很多风险出现在处理上月最后一天的数据的过程中。

  问题的解决有几个思路:

  1 事后处理:

  所以一个事后的处理的方法是:用grep命令在每月第1天将日志跨月的日志去掉,比如:


  grep -v "01/Apr" accesserials_log_04_01 > accesserials_log_new



  修改SORT后的日志:所有跨天的数据去掉。也许对日志的事后处理是一个途径,虽然sort命令中有对日期排序的特殊选项 -M(注意是:大写M),可以让指定字段按照英文月份排序而非字母顺序,但对于apache日志来说,用SORT命令切分出月份字段很麻烦。(我尝试过用 "/"做分割符,并且使用“月份” “年:时间”这两个字段排序)。虽然用一些PERL的脚本肯定可以实现,但最终我还是放弃了。这不符合系统管理员的设计原则:通用性。 并且你需要一直问自己:有没有更简单的方法呢?还有就是将日志格式改成用TIMESTAMP(象SQUID的日志就没有这个问题,它的日志本身就是使用TIMESTAMP做时间时间戳的),但我无法保证所有的日志工具都能识别你在日期这个字段使用了特别的格式。

  2 优化数据源:

  最好的办法还是优化数据源。将数据源保证按天轮循,同一天的日志中的数据都在同一天内。这样以后你无论使用什么工具(商业的,免费的)来分析日志,都不会因为日志复杂的预处理机制受到影响。

  首先可能会想到的是控制截取日志的时间:比如严格从0点开始截取日志,但在子夜前1分钟还是后一分钟开始截取是没有区别的,你仍然无法控制一个日志中有跨2天记录的问题,而且你也无法预测日志归档过程使用的时间。

  因此必须要好好考虑一下使用日志轮循工具的问题,这些日志轮循工具要符合:

  1 不中断WEB服务:不能停apache=>移动日志=>重启apache
  2 保证同一天日志能够按天轮循:每天一个日志00:00:00-23:59:59
  3 不受apache重启的影响:如果apache每次重启都会生成一个新的日志是不符合要求的
  4 安装配置简单