无论是我们使用的个人计算机还是服务器都为我们提供了强大的日志记录功能。例如系统日志，可以为我们记录系统硬件、软件和系统问题的信息，用户可以通过它来检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。

而服务器日志，则主要包括访问日志和错误日志。访问日志记录了该服务器所有的请求的过程，主要记录的是客户的各项信息，如访问时间、内容、地址等。错误日志则记录服务器出错的细节等数据。同时，这些日志记录信息也为安全事件的取证分析提供了强有力的证据和溯源的渠道。

我们以Web服务器为例。最常见的Apache HTTP Server一般会为我们提供两个主要的日志文件 – access.log和error.log。access.log记录所有文件请求。如果访问者请求www.example.com/main.php，则日志文件中将添加以下条目。

从以上日志可以看出，一个访问者在2016年4月16日的07:44分成功请求了main.php文件。

试想该访问者请求的不是一个普通文件，而是一个转储数据库的文件例如dump_database.php。如果没有日志文件，那么我们可能永远不会发现有人或许已经将我们的重要数据窃取了。

下面让我通过一个简单的示例来为大家演示下，如何通过一个日志文件溯源web应用的攻击者。

调查

我们假设我们运行的一个最新的WordPress站点受到了黑客的攻击，并且该站点运行在没有任何补丁问题的Ubuntu服务器上。

在接到任务后，为了防止系统及其当前的日志状态发生改变，以及阻止攻击者可能的远程访问和与其他机器的网络交互，我们的分析取证小组首先对服务器进行了“离线”操作。

注：按照正常流程我们需要创建一个当前系统的副本，但由于我们是以演示为目的故跳过该步骤的操作，我们将直接以原始数据为演示对象。

寻找蛛丝马迹

在调查取证之前，我们首先要知道哪些证据是我们所需要的。通常攻击者都会直接访问一些“隐藏”或特殊的文件，或需要身份验证的管理区域，远程执行代码，SQL注入，文件包含，跨站点脚本（XSS）等异常行为，这就表明有攻击者可能利用了漏扫工具或手工对我们的站点进行了探测。

这里我们假设我们的access.log日志文件保存完好并且可用。

access.log往往是一个相当大的文件，通常包含了数千条的请求记录。

面对数量如此庞大的记录信息，如果我们每一行都去仔细查看显然不是个明智的选择。因此，我们可以将一些没有什么太大价值的数据给去除掉，例如图像、CSS、JavaScript这类文件。

由于我们的演示站点为WordPress，所以我们可以通过筛选的方式找出所有具有WordPress特征的access.log记录。

以上命令将过滤access.log，并只显示包含wp-admin的字符串的记录，wp-admin是WordPress的默认后台管理文件夹，wp-login则是WordPress（wp-login.php）登录文件的一部分。最后的POST将筛选出所有通过POST方法发送的HTTP请求，这些请求很可能是在提交登录表单。

筛选完成后以下的日志记录引起了我们的注意：

我们看到IP为84.55.41.57的访问者，成功访问了WordPress的管理后台。

针对该IP我们继续筛选有关它的信息：

我们得到了以下过滤内容：

让我们来分析一下这些记录。

攻击者访问登录界面。

84.55.41.57 - GET /wordpress/wp-login.php 200

攻击者提交了登录表单（使用POST方法的HTTP请求），并被重定向（302 HTTP状态代码）。

84.55.41.57 - POST /wordpress/wp-login.php 302

攻击者被成功重定向到了wp-admin（WordPress仪表盘），这意味着攻击者成功进行了身份验证。

84.55.41.57 - GET /wordpress/wp-admin/ 200

攻击者导航到了主题编辑器。

84.55.41.57 - GET /wordpress/wp-admin/theme-editor.php 200

攻击者试图通过编辑404文件将恶意代码插入到该页面，但由于缺乏写入权限最终没能成功。

84.55.41.57 - GET /wordpress/wp-admin/theme-editor.php?file=404.php&theme= twentysixteen 200

攻击者访问了插件安装程序。

84.55.41.57 - GET /wordpress/wp-admin/plugin-install.php 200

攻击者安装并激活了文件管理器插件。

攻击者使用文件管理器插件上传了一个名为r57.php的文件，这很可能是一个PHP webshell脚本。

日志表明攻击者运行r57 shell脚本。查询字符串？1（攻击者运行了phpinfo();）和？28（攻击者获取到了服务列表）可以看出攻击者并没有发现什么感兴趣的东西。

攻击者的最后一个动作是通过文件管理器插件编辑主题的索引文件，并用“HACKED！”替换了其中的内容。

基于上述信息，我们可以大致判断攻击者对我们的站点做了什么操作。但这里有个非常重要的点绝对不能忽略，那就是假设我们的管理员密码并没有泄露，攻击者也没有尝试过暴破，那么攻击者又是如何获取到我们的登录凭证的呢？

当前的access.log文件并没有为我们提供任何线索。不过，我们分析的对象不仅限于这一个access.log文件。Apache HTTP Server为我们循环归档了旧的日志文件。打开/var/log/apache2/目录我们可以看到4个额外的日志文件。

首先，我们筛选出所有IP为84.55.41.57的日志记录。可以看到，其中几条记录显示我们的自定义插件遭到了SQL注入攻击。

假设该插件是站点管理员在网上随意复制粘贴创建的。该脚本旨在根据给定的ID检查用户的有效性。该插件在网站的主页上暴露了一个表单，该表单向

/wordpress/wp-content/plugins/custom_plugin/check_user.php发送了一个AJAX GET请求。

通过对check_user.php脚本的分析发现，脚本写得并不严谨且存在SQL注入漏洞。

从access.log中的记录数量和注入语句判断，攻击者很可能是借助了某类SQL注入工具来利用该SQL注入漏洞。

在本文我们将不会深入探讨SQL注入攻击，以及如何修复SQL注入漏洞，想要了解更多内容可以点击该链接。以下是我们在当前日志中发现的记录：

以上的这些信息表明了，我们的数据库已经受到了严重的威胁并且我们的重要数据可能也已经被攻击者所窃取。

分析

通过以上的日志分析，我们已经可以大致的还原攻击者的攻击路径了。如下：

但还有一些问题我们仍没有答案，比如背后攻击者的真实身份是什么。在这一点上我们只获取到了攻击者的IP地址，但该IP地址极有可能是攻击者使用的一个代理/匿名IP（如Tor）。

在本文的示例中攻击者为我们留下了大量的证据和记录，而在实际环境中攻击者可能会清除所有的关键信息，这势必会加大调查人员的取证难度。

总的来说导致这次SQL注入攻击，归根于自定义WordPress插件中不安全的代码编写。其次，如果网站管理员能够定期对网站进行安全检查，那么也能在一定程度上避免此类事件的发生。

一如既往的学习，一如既往的整理，一如即往的分享。

推荐文章++++

*Pystinger - 使用Webshell绕过防火墙进行流量转发

*webshell后门分析

*从Web日志还原SQL注入拖走的数据