通过WEB日志安全分析追踪攻击者

摘要：本文主要讲述了WEB日志安全分析时的思路和常用的一些技巧，并通过一个完整的实例讲述了在发生安全事件后，如何通过分析WEB日志并结合其他一些线索来对攻击者进行追踪。

本文主要讲述了WEB日志安全分析时的思路和常用的一些技巧，并通过一个完整的实例讲述了在发生安全事件后，如何通过分析WEB日志并结合其他一些线索来对攻击者进行追踪。

WEB日志作为WEB服务器重要的组成部分，详细地记录了服务器运行期间客户端对WEB应用的访问请求和服务器的运行状态。同样，攻击者对网站的入侵行为也会被记录到WEB日志中。因此，在网站日常运营和安全应急响应过程中，我们可以通过分析WEB日志并结合其他一些情况来跟踪攻击者，还原攻击过程。

WEB日志结构

在对WEB日志进行安全分析之前，我们需要先了解下WEB日志的结构。从目前主流WEB服务器支持的日志类型来看，常见的有两类：

1.Apache采用的NCSA日志格式，2.IIS采用的W3C日志格式。

其中，NCSA日志格式又分为NCSA普通日志格式（CLF）和NCSA扩展日志格式（ECLF）两类，具体使用哪一种可以在WEB服务器配置文件中定义。Apache也支持自定义日志格式，用户可以在配置文件中自定义日志格式，如在Apache中可以通过修改httpd.conf配置文件来实现，如图1。

图1

接着我们来看一条Apache的访问日志：

192.168.1.66 - - [06/Sep/2012:20:55:05 +0800] "GET /index.html HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0"

其具体的解释为：

192.168.1.66：表示客户端IP地址

[06/Sep/2012:20:55:05 +0800]：访问时间及服务器所在时区

GET：数据包提交方式为GET方式，常见的有GET和POST两种类型。

/index.html：客户端访问的URL

HTTP/1.1：协议版本信息

404：WEB服务器响应的状态码。404表示服务器上无此文件，200表示响应正常，500表示服务器错误。

287：此次访问传输的字节数

Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0：客户端浏览器和系统环境等信息。

IIS访问日志格式及保存路径可以在IIS管理器中配置，如下图2所示。

图2

下图3是IIS的W3C扩展日志格式。

图3

值得注意的是，IIS的W3C日志格式中的访问时间采用的是格林威治时间，和我们的北京时间差8个小时，而且没有办法修改。

WEB日志安全分析原理

通过上面的知识，我们知道WEB日志会记录客户端对WEB应用的访问请求，这其中包括正常用户的访问请求和攻击者的恶意行为。那么我们如何区分正常用户和恶意攻击者呢？通过大量的分析，我们发现攻击者在对网站入侵时，向网站发起的请求中会带有特定的攻击特征，如利用WEB扫描器在对网站进行漏洞扫描时往往会产生大量的404错误日志，如图4所示。

图4

当有人对网站进行SQL注入漏洞探测时，WEB访问日志中通常会出现如下日志，如图5所示：

图5

因此，我们可以通过分析WEB日志中是否存在特定的攻击特征来区分攻击者和正常用户的访问行为。

但是，WEB访问日志并不是万能的，有些攻击行为并不会被记录到WEB访问日志中，比如POST型SQL注入就不会记录在WEB访问日志中。这时我们就需要通过其他手段来监测这种攻击行为。

WEB日志安全分析思路

在对WEB日志进行安全分析时，可以按照下面两种思路展开，逐步深入，还原整个攻击过程。

一、首先确定受到攻击、入侵的时间范围，以此为线索，查找这个时间范围内可疑的日志，进一步排查，最终确定攻击者，还原攻击过程，如图6。

图6

二、一般攻击者在入侵网站后，通常会上传一个后门文件，以方便自己以后访问，我们也可以以该文件为线索来展开分析，如图7。

图7

WEB日志安全分析技巧

WEB日志文件通常比较大，包含的信息也比较丰富。当我们对WEB日志进行安全分析时，我们通常只关注包含攻击特征的日志，其他的日志对于我们来说是无用的。这时我们可以通过手工或借助工具来将我们关注的日志内容提取出来单独分析，以提高效率。在日志分析中经常用到的几个命令有”find”、”findstr”、”grep”和”egrep”等，关于这几个命令的用法请自行查找相关资料。

1.将数据提交方式为“GET”的日志提取出来，如图8

图8

上面这条命令的意思是从iis.log这个文件中查找存在GET字符的日志内容，并将结果保存到iis_get.log中，得到的结果如图9。

图9

2.查找WEB日志中是否存在利用IIS写权限漏洞的攻击行为，如图10。

图10

3.因为手工分析日志比较费时，而且效率比较低。因此，笔者自行开发了一款WEB日志安全审计工具，实现了WEB日志安全分析的自动化。大家可以到http://secsky.sinaapp.com/157.html地址去下载该软件，下面是该软件的界面和生成的分析报告，如图11和图12。

图11

图12

实例分析

上面我们讲了一些关于在WEB日志安全分析过程中经常用到的技巧，现在我们通过一个实例来完整的了解下如何通过分析WEB日志追踪攻击者，并还原攻击过程。

背景介绍

某日，公司网站服务器WEB目录下突然多了一个名为shell.php.jpg的文件，经过查看文件内容，发现该文件是一个网站后门文件，也就是常说的WebShell，于是怀疑网站被黑客入侵。接下来，网站管理员通过分析WEB日志，并结合其他一些情况，成功追踪到了攻击者，还原了整个攻击过程。在这个过程中还发现了网站存在的安全漏洞，并于事后及时修复了漏洞，对网站进行了全面的安全检测，提高了网站的安全性。

分析思路

根据目前得到的信息分析，得知WEB目录下存在一个可疑的文件，我们就以该文件为线索，先来查找都有哪些IP访问了该文件，然后并一步排查这些IP都做了哪些操作，最终确认攻击者以及他运用的攻击手段。

分析过程

1.首先找到存在的网站后门文件，也就是上面提到的WebShell文件，发现该文件是在2013年2月7日被创建的，如图13。

图13

2.我们先来查找下都有哪些IP访问了这个文件，可通过如下命令将相关日志内容提取出来，如图14和图15。

图14

图15

3.通过上图我们可以确定目前只有192.168.1.2访问了该文件。这个IP非常可疑，下面我们来查找下该IP都做了哪些操作，如图16和图17。

图16

图17

4.从上面的日志中我们可以看到这是典型的SQL注入。经过进一步分析，发现攻击者利用SQL注入获取到了网站后台管理员账号和密码。

192.168.1.2 - - [07/Mar/2013:22:50:21 +0800] "GET /leave_show.php?id=40%20and%201=2%20union%20select%20unhex(hex(concat(0x5e5e5e,group_concat(id,0x5e,user,0x5e,pwd,0x5e,userclass,0x5e,loginip,0x5e,logintimes,0x5e,logintime),0x5e5e5e))),0,0,0,0,0,0,0,0%20from%20(select%20*%20from%20(select%20*%20from%20admin%20where%201=1%20order%20by%201%20limit%201,100)%20t%20order%20by%201%20desc)t%20-- HTTP/1.1" 200 18859 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)"

5.接着攻击者利用获取到的账号成功进入了网站后台，详见下面的日志：

192.168.1.2 - - [07/Mar/2013:22:51:26 +0800] "GET /mywebmanage/web_manage.php HTTP/1.1" 200 5172 "http://192.168.1.107/mywebmanage/" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:51:44 +0800] "POST /mywebmanage/check.php HTTP/1.1" 200 47 "http://192.168.1.107/mywebmanage/web_manage.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:51:45 +0800] "GET /mywebmanage/default.php HTTP/1.1" 200 2228 "http://192.168.1.107/mywebmanage/check.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

6.然后攻击者访问了add_link.php这个页面，该页面是一个添加友情链接的页面，如图18。

图18

通过分析网站源码，发现该页面上传图片处存在一个文件上传漏洞，攻击者正是利用这个漏洞上传了一个名为shell.php.jpg的后门文件，并且利用Apache的解析漏洞成功获取到一个WebShell。关于Apache解析漏洞的详细情况可以查看笔者之前的一篇文章（http://secsky.sinaapp.com/89.html），对此漏洞有详细的描述。

192.168.1.2 - - [07/Mar/2013:22:53:40 +0800] "GET /mywebmanage/link/add_link.php HTTP/1.1" 200 3023 "http://192.168.1.107/mywebmanage/LeftTree.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:54:50 +0800] "POST /mywebmanage/link/add_link_ok.php HTTP/1.1" 200 77 "http://192.168.1.107/mywebmanage/link/add_link.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:55:48 +0800] "GET /link/shell.php.jpg HTTP/1.1" 200 359 "-" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:55:54 +0800] "POST /link/shell.php.jpg HTTP/1.1" 200 132 "http://192.168.1.107/link/shell.php.jpg" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

7.到这里，我们已经可以了解到攻击者的攻击过程了。具体如下：

首先对网站进行漏洞扫描，发现存在SQL注入漏洞利用SQL注入漏洞获取到网站后台管理员账号、密码及其他信息以管理员身份登录网站后台利用某页面存在的文件上传漏洞，成功上传一个名为shell.php.jpg的后门文件，并结合Apache的解析漏洞，成功获取到一个WebShell。

分析过程总结

通过上面对WEB日志进行的安全分析，我们不仅追踪到了攻击者，也查出了网站存在的漏洞。下面就应该将攻击者上传的后门文件删除掉，并修复存在的安全漏洞，然后对网站进行全面的安全检测，并对WEB服务器进行安全加固，防止此类安全事件再次发生。