demonalex的狂人日记

[整理文]分析W3C扩展日志
整理人：demonalex


注：以下部分翻译自Microsoft网站--《W3C Extended Log File Format (IIS 6.0)》的解释。
******************************************************************************************
W3C扩展日志文件格式是IIS（Microsoft IIS）的默认日志格式，其内容编码为默认的ASCII文本。你可以通过IIS管理器选择各种
不同的字段包含在这种日志文件内，这样可以使你的日志内容更加人性化。其实系统是通过HTTP.sys句柄来处理W3C扩展日志的，
W3C内容格式完全是通过读取HTTP.sys的内核缓存进行筛选获取的。

下表中列出各种可选字段（“字段标识”列为实际参数名）及其描述，并通过Default列记录该字段是否默认被‘包含’了。
“字段”        “字段标识”       “描述”                                  “Default（Y/N ）”
日期             date              动作发生时的日期。                         Y
时间             time              动作发生时的时间（默认为UTC标准）。        Y
客户端IP地址     c-ip              访问服务器的客户端IP地址。                 Y
用户名           cs-username       通过身份验证的访问服务器的用户名。不包括匿名用户（用‘-’表示）。 Y
服务名           s-sitename        客户所访问的Internet服务名以及实例号。     N
服务器名         s-computername    产生日志条目的服务器的名字。               N
服务器IP 地址    s-ip              产生日志条目的服务器的IP地址。             Y
服务器端口       s-port            服务端提供服务的传输层端口。               Y
方法             cs-method         客户端执行的行为（主要是GET与POST行为）。  Y
URI Stem         cs-uri-stem       被访问的资源，如Default.asp等。            Y
URI Query        cs-uri-query      客户端提交的参数（包括GET与POST行为）。    Y
协议状态         sc-status         用HTTP或者FTP术语所描述的、行为执行后的返回状态。 Y
Win32状态        sc-win32-status   用Microsoft Windows的术语所描述的动作状态。N
发送字节数       sc-bytes          服务端发送给客户端的字节数。               N
接受字节数       cs-bytes          服务端从客户端接收到的字节数。             N
花费时间         time-taken        执行此次行为所消耗的时间，以毫秒为单位。   N
协议版本         cs-version        客户端所用的协议（HTTP、FTP）版本。对HTTP协议来说是HTTP 1.0或者HTTP 1.1。 N
主机             cs-host           客户端的HTTP报头（host header）信息。      N
用户代理         cs(User-Agent)    客户端所用的浏览器版本信息。               Y
Cookie           cs(Cookie)        发送或者接受到的cookie内容。               N
Referrer         cs(Referer)       用户浏览的前一个网址，当前网址是从该网址链接过来的。 N
协议底层状态     sc-substatus      协议底层状态的一些错误信息。               Y
 
关于status codes字段的更多详细资料请浏览：“http://go.microsoft.com/fwlink/?LinkId=14381”。
******************************************************************************************
注：其实我们对比一下实际操作会发现“Default”一列是与客观事实有些出入的:P。

下面我们就几个案例进行“还原”：
案例一：某网站http://www.test.com的日志ex050104.log的一段内容：
##########################################################################################
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2005-01-03 16:00:00
#Fields: date time cs-method cs-uri-stem cs-uri-query c-ip cs(Referer) sc-status sc-bytes cs-bytes time-taken
2005-01-01 16:02:22 GET /Enterprise/detail.asp id=1612186 70.25.29.53 http://www.test.com/searchout.asp 200 17735 369 4656
##########################################################################################
这里我们可以得到的资料是：这是一台装有IIS version 6的WEB服务器（通过#Software标识），版本是1.0（#Version标识），
生成日期是2005年1月3日的下午4点正（#Date标识），下面生成的W3C日志内容（通过#Fields标识）包括日期、时间、Client
 to Server的方法、读取的对象、参数、客户端的IP地址、客户端上一个访问的对象、服务返回的状态、Server to Client的
字节、Server接收到的字节、处理该条目的操作总共使用的时间。最后还原的结果是：
--------------------------------------------------------------------------------------
在2005年1月1日的下午4时2分22秒，70.25.29.53这个IP地址的客户端向我们的服务器提交了一个GET：
http://www.test.com/Enterprise/detail.asp?id=1612186
网址的请求，这个请求提交的网址可能是从http://www.test.com/searchout.asp链接过来的，本次操作返回“操作成功”应
答（成功完成操作），此次操作中服务端发送给客户端17735个字节的数据，服务端也接收到369个字节的数据，此次操作总共
花了4656毫秒。
--------------------------------------------------------------------------------------

从上面的知识点不难看到，其实我们要通过W3C扩展日志对HTTP应用层行为进行监控的话，以下几个字段的记录是必不可少的：
date、time、cs-method、cs-uri-stem、cs-uri-query、c-ip、cs-version、cs(User-Agent)、cs(Referer)、sc-status、
sc-bytes、cs-bytes、time-taken、cs-host、cs(Cookie)。解说一下：
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
date和time就不用说了；
cs-method与cs-uri-stem、cs-uri-query联合起来，很快就可以还原出c-ip究竟进行过怎么样的请求；
sc-status可以帮助我们辨别这个请求是否成功‘执行’，从而辨别现象与这个请求操作的依从性；
cs-version、cs(User-Agent)、cs(Referer)、cs-bytes、cs-host与cs(Cookie)可以作为一个类比的特征指纹，鉴别出一些非
正常的请求，如HTTP探测、HTTP DoS与CC等；
cs-bytes、sc-bytes与time-taken可以帮助我们辨别本次请求所耗费的各种资源的情况（如对带宽的影响、CPU/内存资源占用
的影响）。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

最后，一套行之有效的总结、归类、对比方法可以更快地帮你定位到问题的根源，例如：“通过多个cs-uri-query的值相同或
相似，且发生的时间点几乎一致等各种因素，判断其可能遭受过CC攻击”等，这样的案例常有存在，关键看各人的领悟了:P。