你能从你们公司那一大堆的日志数据里找出要取证的目标吗？
 
　　现如今，你的整个网络所产生的大量日志数据足以把人吞没。所有的设备都在以纳秒为单位记录着整个企业网络里的一举一动。最大问题就变成如何才能从你的入侵检测器、防火墙分析器、日志解析器以及其它服务器上找出任何攻击的蛛丝马迹。
 
　　众所周知，稍有疏忽，那些能证明攻击事件的关键证据就可能在这其中的任何一资料库里湮灭。那么，该审查哪些地方呢？从何着手呢？下面就让我们介绍一些侦测技术，好让你知道哪些地方是需要特别留意的。
 
　　理论上来说，你首先应该根据一些条件减小目标范围。比如说根据某个可疑的时间范围，某个毫无意义的IP地址，或是那些只有管理员才能执行的操作，比如对组策略的改动。多条重复出现的日志记录，比如反复尝试输入错误密码，也是潜在威胁的体现。采用商业日志管理工具或服务也是个不错的办法，那样可以帮助你更好地找出目标，并且还能更深入地发掘日志里隐藏的威胁。

　　我们询问了数位专家以听取他们的见解和实际案例经验。出于隐私考虑，我们没法重现所有信息，但是这些安全应该足以让你知道如何下手搜寻这些重要信息。当然，这些例子只是冰山一角。商业工具能帮你锁定目标并把事件关联起来，而自己学着侦测这些可疑之处则有利于提高自己的技术水平。
 
　　案例1：未经授权的数据下载

　　有一家公司因经营不善破产倒闭。所有数据库管理权限都被冻结，任何资料都禁止删除。取证人员在一位经理的电脑上发现了这条记录。

　　这条日志显示有一位经理在系统被封锁后仍然用他的电脑从一个网站上下载了包含有用户信息的一个zip文件。
 
　　“一开始，我们甚至根本就不知道有这么一台Web服务器存在，它停放在外面。”接手这个案件的奥兰多电子发现(e-discovery)律师Ralph Losey说。他们就是根据日志文件里的踪迹发现了那个IP的服务器。

　　教训：这条记录惹人注意的原因一是因为它产生的时间段（冻结后，并且是在下班时间晚9点后），二是因为这个文件所请求的网站。分析师根据这条日志里的IP地址最终跟踪到了这位用户。所以一定要小心下载zip和其它类型的大文件，尤其是在大多数人都应该不在工作的下班时间段。
 
　　案例2：无法登录到网络

　　这个安全发生在一家正准备开始交易的证券经纪商。但是交易员们发现他们无法登陆进他们的电脑了。在这样的情况下，所有人都会问的一个问题就是：“在他们下班回家的这段时间里发生了什么，是谁做了这些手脚？”

　　各种各样的Windows服务器产生大量的日志数据使得这个问题变得非常棘手。在这个案例中， 我们使用SenSage 的日志管理工具过滤所有数据，以找出夜间在策略设置和群组帐户设置之前发生的关键事件。下面就是它找出来的那一条：

　　在这个案例中，最容易让人怀疑的就是活动目录(Active Directory),IT人员确定有人在前晚改动过组织单元(Organization Unit)。他们发现了一系列的组策略改动事件发生，包括上面提到的这一件。
 
　　在Windows环境下，对组策略对象的删除会产品一个566的事件ID，然后它会被记录下来，表示”删除“操作。
 
　　通过这份报告，经纪公司得以找出作出这一改动的管理员。最后发现这只是一个误操作，而不是恶意为之。
 
　　教训：现在许多公司都对允许公司目录应用程序的人数作出限制，同时，只要他们作了任何改动，都很有必要用普通用户去测试一下正常的操作是不是受到了影响。
 
　　案例3：前雇员仍有访问权限

　　我们知道，内部人员的威胁往往是最让人防不胜防的。在这个案例中，我们发现一位已经被解职的员工访问到了企业的虚拟专用网（VPN），并且还删除了重要了数据。这不仅仅是丢失数据的问题，它在其它方面也给我们许多警示。你得根据员工、时间、重复输入错误口令，或者是三者结合起来检索。让我们看看用RSA的enVision 日志分析器捕获的数据包：

　　不知怎的，用户DJohnson（参见下面示例中的高亮部分）成功通过了Cisco VPN的身份认证（可能是他的帐号还没有被禁用，或者是他通过社会工程学手段从服务台那里取得了暂时的访问权限）。我们使用了enVision的过滤功能来查找那些未验证用户，或是那些在短时间内多次重复尝试错误密码的用户。我们可以看到他删除了一个名为”现金流“的表格（见例子底部的高亮文本），这很可能是他为了掩盖之前所犯的错误。
 
　　教训：确保你们有一套完善的解雇程序，另外还要对服务台的工作人员多进行这方面的培训。
 
　　案例4：劫持用户会话

　　我们都知道，Web是一个不安全的媒介，但是我们该做些什么来增强它的安全性呢？这里有一个简单的示例演示了如何在硬盘的cookies里面劫用户的会话数据。这一幕发生在用户在线检查他的酒店帐单时。
 
　　通常情况下，当酒店的结算系统对用户进行身份验证时，他所住房间的信息就保存在了cookie里。你可以在本地硬盘上直接搜索这些cookie文件，如果你有内置的代理服务器的话，就更简单了。比如说Firefox下的Firebug和IE下的IE Watch，你可以用这两个工具来窥视当你连接到网站上有哪些cookie被创建了。

　　下面就是cookie文件的部分内容：

　　你能看到cookie包含两个与用户所住的412号房间相关的元素（参见21页高亮文字）。如果你把这两个地方都改成其它房间号，比如说312，然后保存该cookie，这样当你再打开在线帐单程序时，就能看到别的用户的帐户了。
 
　　教训：有时候不光是日志文件不安全。有一些设计得不好的Web应用程序把一些用户身份验证信息写到不安全的文件里，这也是很危险的。

　　案例5：对Web服务器的跨站脚本攻击

　　跨站脚本攻击实在是太常见了。有一些Web服务器对用户输入的验证不够严，黑客就可以乘机注入一些恶意内容引发一系列的问题。看看下面这段Javascript代码，它可以被填写到那些在线约会或交友网站的普通输入框里，而这些输入框本意是供普通用户修改个人信息用的。

　　这段代码还追加了一些特殊的有效载荷，因此每次用户访问这位用户的个人信息时，他自己的信息就会被不知不觉地发送给攻击者。这对所有查看了该用户个人信息的用户都会造成影响。以下是我们的Web服务器日志文件：

　　这些就是被植入了攻击代码的用户ID;黑体字部分是能窃取用户在浏览器中的输入的JavaScript代码。我们现在就可以假冒这些用户，甚至还可以修改他们的个人信息，用他们的身份与别人交往。
 
　　最厉害的一次跨站脚本攻击发生在数年前SamyMyspace蠕虫病毒爆发时（http://namb.la/popular/tech.html上有相关介绍 ） 。在不到一天时间内，黑客成功地感染了100多万用户。
 
　　教训：验证用户输入的内容！跨站脚本攻击是众所周知的，最好的措施就是让开发人员提高警惕，多加小心。
 
　　案例6：猜解root密码

　　我们大家都可能忘记密码，但是如果密码的强度不够会怎样呢？这是从日志管理厂商LogLogic的日志档案里选出来的一条。

　　这一条总共重复出现了有上千次（参见左下方的高亮文字），并且持续了数天。然后我们发现下面这一条，显示用户最终得到了正确的密码。

 
　　教训：不要使用弱口令，特别在面向Internet的SSH服务器上。就算你把所有的相关端口都禁用了，你也还应该小心恶意用户反复试探弱口令。