如何利用网站 WEB 日志分析追查网站攻击者

摘要

本博客前段时间出了不少问题，在解决问题途中，找到很多不错的文章，特整理记录下来以备不时之需，同时也希望能给遇到相关问题的沃友们起到抛砖引玉的作用。

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

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

一、WEB 日志结构

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

1、Apache 采用的 NCSA 日志格式。

2、IIS 采用的 W3C 日志格式。

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

接着我们来看一条 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 管理器中配置，如下图：

下面是 IIS 的 W3C 扩展日志格式：

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

二、WEB 日志安全分析原理

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

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

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

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

三、WEB 日志安全分析思路

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

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

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

四、WEB 日志安全分析技巧

WEB 日志文件通常比较大，包含的信息也比较丰富，当我们对 WEB 日志进行安全分析时，我们通常只关注包含攻击特征的日志，其他的日志对于我们来说是无用的，这时我们可以通过手工或借助工具来将我们关注的日志内容提取出来单独分析，以提高效率。

在日志分析中经常用到的几个命令有“find”，“findstr”，“grep”，“egrep”等，关于这几个命令的用法请自行查找相关资料。

1、将数据提交方式为“GET”的日志提取出来

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

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

五、实例分析：如何通过分析 WEB 日志追踪攻击者

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

1、背景介绍

某日，公司网站服务器 WEB 目录下突然多了一个名为 shell.php.jpg 的文件，经过查看文件内容，发现该文件是一个网站后门文件，也就是常说的 WebShell，于是怀疑网站被黑客入侵。

接下来网站管理员通过分析 WEB 日志，并结合其他一些情况，成功追踪到了攻击者，还原了整个攻击过程，在这个过程中还发现了网站存在的安全漏洞，事后及时修复了漏洞，并对网站进行了全面的安全检测，提高了网站的安全性。

2、分析思路

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

3、分析过程

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

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

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

（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 这个页面，该页面是一个添加友情链接的页面：

通过分析网站源码，发现该页面上传图片处存在一个文件上传漏洞，攻击者正是利用这个漏洞上传了一个名为 shell.php.jpg 的后门文件，并且利用 Apache 的解析漏洞成功获取到一个 WebShell。

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。

六、实例分析：利用 IIS 日志追查 BBS 网站入侵者

如果你是网管你会如何去追查问题的来源呢？程序问题就去查看“事件查看器”，如果是 IIS 问题当然是查看 IIS 日志了！

系统文件夹的 system32 低下的 logfile 有所有的 IIS 日志，用来记录服务器所有访问记录，因为是虚拟主机的用户，所以每个用户都配置独立的 IIS 日志目录，从里面的日志文件就可以发现入侵者入侵 BBS 的资料了，所以下载了有关时间段的所有日志下来进行分析，发现了很多我自己都不知道资料，这下子就知道入侵者是怎么入侵我的 BBS 了。

1、IIS 日志的分析

从第一天里日志可以发现入侵者早就已经对我的 BBS 虎视耽耽的了，而且不止一个入侵者这么简单，还很多啊，头一天的 IIS 日志就全部都是利用程序扫描后台留下的垃圾数据。

看上面的日志可以发现，入侵者 61.145.***.***利用程序不断的在扫描后台的页面，似乎想利用后台登陆漏洞从而进入 BBS 的后台管理版面，很可惜这位入侵者好像真的没有什么思路，麻木的利用程序作为帮助去寻找后台，没有什么作用的入侵手法。

查看了第二天的日志，开始的时候还是普通的用户访问日志没有什么特别，到了中段的时候问题就找到了，找到了一个利用程序查找指定文件的 IIS 动作记录。

从上面的资料发现入侵者 61.141.***.***也是利用程序去扫描指定的上传页面，从而确定入侵目标是否存在这些页面，然后进行上传漏洞的入侵，还有就是扫描利用动网默认数据库，一些比较常用的木马名称，看来这个入侵者还以为我的 BBS 是马坊啊，扫描这么多的木马文件能找着就是奇迹啊。

继续往下走终于被我发现了，入侵者 61.141.***.***在黑了我网站首页之前的动作记录了，首先在 Forum 的文件夹目录建立了一个 Myth.txt 文件，然后在 Forum 的文件夹目录下再生成了一只木马 Akk.asp

日志的记录下，看到了入侵者利用 akk.asp 木马的所有操作记录。

详细入侵分析如下：

GET /forum/akk.asp – 200

利用旁注网站的 webshell 在 Forum 文件夹下生成 akk.asp 后门

GET /forum/akk.asp d=ls.asp 200

入侵者登陆后门

GET /forum/akk.asp d=ls.asp&path=/test&oldpath=&attrib= 200

进入 test 文件夹

GET /forum/akk.asp d=e.asp&path=/test/1.asp&attrib= 200

利用后门在 test 文件夹修改 1.asp 的文件

GET /forum/akk.asp d=ls.asp 200
GET /forum/akk.asp d=ls.asp&path=/lan&oldpath=&attrib= 200

进入 lan 文件夹

GET /forum/akk.asp d=e.asp&path=/lan/index.html&attrib= 200

利用编辑命令修改 lan 文件夹内的首页文件

GET /forum/akk.asp d=ls.asp 200
GET /forum/akk.asp d=ls.asp&path=/forum&oldpath=&attrib= 200

进入 BBS 文件夹（这下子真的进入 BBS 目录了）

POST /forum/akk.asp d=up.asp 200
GET /forum/akk.asp d=ls.asp&path=/forum&oldpath=&attrib= 200
GET /forum/myth.txt – 200

在 forum 的文件夹内上传 myth.txt 的文件

GET /forum/akk.asp d=ls.asp&path=/forum&oldpath=&attrib= 200
GET /forum/akk.asp d=e.asp&path=/forum/myth.txt&op=del&attrib= 200
POST /forum/akk.asp d=up.asp 200
GET /forum/myth.txt – 200

利用后门修改 Forum 文件夹目录下的 myth.txt 文件。

之后又再利用旁注网站的 webshell 进行了 Ubb.asp 的后门建立，利用 akk.asp 的后门修改了首页，又把首页备份，晕死啊，不明白这位入侵者是怎么一回事，整天换 webshell 进行利用，还真的摸不透啊。

2、分析日志总结

入侵者是利用工具踩点，首先确定 BBS 可能存在的漏洞页面，经过测试发现不可以入侵，然后转向服务器的入侵，利用旁注专用的程序或者是特定的程序进行网站入侵，拿到首要的 webshell，再进行文件夹的访问从而入侵了我的 BBS 系统修改了首页，因为是基于我空间的 IIS 日志进行分析，所以不清楚入侵者是利用哪个网站哪个页面进行入侵的！

不过都已经完成的资料收集了，确定了入侵 BBS 的入侵者 IP 地址以及使用的木马，还留下了大量入侵记录，整个日志追踪过程就完毕了。

点评：

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

原文链接：http://www.mahaixiang.cn/seoyjy/1379.htm