原创：反黑战役之谁动了我的文件？

cgweb

反黑战役之谁动了我的文件？

一、事件背景
本文描述了IT经理小李在一起广告公司文件泄露的案件中，通过对交换机、服务器日志和邮件信头进行分析，利用多方面日志内容验证了他的推测，最后他将这些蛛丝马迹汇总起来，勾勒出了这次攻击事件的完整过程。大家在看完事件的描述后，是否知道在FTP和SSH日志中找到了什么线索？下面故事开始啦。
故事主人公小李在一家渲染农场（Render Farm）电影特效公司上班，前不久刚刚被提升为IT经理，这对于他来说是一件无比兴奋的事情。目前他们公司正在制作《某 电影》的特技效果，大家都为之共同努力工作。他每天早上必须喝上一杯咖啡。今天，他拿着咖啡向办公室走去。被小周和小王叫进会议室。接着，小王开始讲述事件的要点，不过没有提及任何一个同事的名字。然后，小王对小李说：“老大，有人将《某电影》的机密信息散布了出去，在某电影网站上发布了1分钟片长的电影片段。”小周对此非常**，他让我们查出是谁干的（这些视频特效在昨天早晨刚完成后期制作）。
小李有点紧张，此刻他意识到已经发生的事情对于他们来说意味着什么。小周大声说道：“泄露出去的片段是观众最期望看到的内容，但现在已经公诸于众了！单单是一个镜头就能让公司直接经济损失达数几十万元！”小曹接着补充说，电影制作公司将不会再把自己的电影特效交给他们制作，除非他们将这件事情查个水落石出，并且能防止其再次发生。小李这才明白过来，他们不仅失去了这部电影的特效渲染工作，如果消息传开的话，他们将失去更多的机会。

二、了解业务流程
小李只是IT人员，并不熟悉动画渲染业务，他为了搞清楚公司业务流程，立刻询问了电影胶片制作的所有过程，从梦工厂收到电影制作公司的电影胶片，直到这些电影胶片运回到电影制作公司。小周一一叙述了整个过程，因为这些都是在他的监督之下完成的。制片公司将需要后期制作的电影胶片（需采用非线性编辑的视频特效）存放在硬盘上，小王将硬盘上的内容复制到RAID阵列上，然后给后期制作小组发电子邮件，告诉他们可以取胶片。
后期制作小组的工作采取轮班工作方式，所以小周打算查出昨天是谁处理过某某电影的视频。团队完成后期制作，视频文件就被放在了服务器上的一个目录下。待硬盘中存储足够多的文件，小王才将硬盘上的文件送给电影制作公司。然后这些文件会被写入磁盘阵列上并离线保存，目前《某电影》视频内容还没有归档到阵列上。

三、初步调查：公司内鬼所为？
调查工作进行到第二天清晨，还是没有得到有价值的线索。小李认为有必要和小王进行一次交谈，以便进一步了解技术细节。小李心想：“难道是小王把视频卖给影迷网站？他是那种人吗？”小李必须得弄个水落石出。
小王在公司创建之初就来工作，现已工作多年。他是后期制作团队的系统管理员。小王和小李之间联系不多，因为后期制作相对独立。小王再一次向小李解释了所有的过程，他愿意提供更多的技术细节，他们的磁盘阵列和Linux服务器之间采用直连方式，与该服务器相连的所有客户端也清一色使用Linux系统。所有的后期制作成员都使用Web浏览器来获取他们想要操作的文件，并且挑出他们正在处理的文件，也就是说不可能两个人同时操作同一个电影胶片。这些Web上的代码都是两年前由公司内部开发的，非常可靠。
小李从与小王的谈话中确信他不会是作案者。首先，他不会为了贪图眼前的利益而毁掉自己的前程；其次，小李非常赞赏他的业务能力。
小李回到了自己的办公室，思考着下一步该怎么办。这似乎并不像内部职员所为。公司内有着良好的企业文化，假设《某某电影》这部惊人之作能够家喻户晓的话，渲染农场公司也会因此迎来自己的辉煌。小李决定仔细研究一下网络拓扑图。公司的网络拓扑如图1所示，这是他的前任临走前留给他的，也许能够从中找到一些启示。



图1 案例网络拓扑
这张网络拓扑图似乎并没有给小李太多帮助，局域网中只有几个VLAN。公司内网和因特网之间也有防火墙、DMZ区和代理服务器，一切看上去都很正常，调查工作陷入僵局。这时，小王来到小李的办公室说，小蒋是昨天最后一个调取某电影胶片文件的员工。小李立刻拿着记事本去找小蒋，打算一探究竟。
小蒋是公司的新员工，小李曾经见过他几次，但并没有和他谈过话。小蒋告诉小李他工作的整个过程：首先他将视频文件从服务器下载，然后对它进行编辑加工，接着就将修改过的文件再提交给服务器。小李询问上传下载的方法时，小蒋说是使用FTP下载。小李听到这条线索，他觉得这也许就是问题所在。于是，他接着问小蒋修改完文件后上传的时间。小蒋会议了一下说，“昨天是我太太生日，所以晚上下班比较准时，大约时间是在5:15～5:30”。

四、取证分析
小李决定先找小王查看后期服务器上的FTP日志。小王很高兴事情有了新的进展，他帮助小李查询FTP日志文件，并登录了后期制作服务器。
# grep xiaojiang xferlog
Mon Sept 10 04:48:18 2010 1 1.example.com 147456 /var/ftp/pubinfo/bdsq/file2.jpg  b_oa xiaojiang ftp 0*i
“好，这说明小蒋是正常上传文件的。但是之后会不会又有人调取过呢？”
#grep jer xferlog
Mon Sept 10 04:48:18 2010 1 1.example.com 147456 /completed/ hawk.avi b_oa Jer ftp 0*i
小李有点糊涂了。小蒋是正常上传文件的，在这之后再没人访问过，至少没人再通过FTP访问过。小李一头雾水地回到了自己的办公室。小王看到小李并拦住了他，连忙询问是否有新的发现。然而小李只能对他解释说发现了一些可疑之处，但还没有得到证实，小李又一次感到自己一整天都像是热锅上的蚂蚁。就在这时候，小周来到了小王的办公室。同样的事情发生了！ 急急忙忙说：“又有一部制作好的片头视频被发布在某电影网站上了”。看到经理这样的情形，小王和小李的心里砰砰直跳。小周说道视频文件是昨天晚上制作完成的,怎么这么快就泄露了呢？这时小李想到联系某电影网站的网管联系，看看是谁发布了这个视频。当和网管取得了联系后，从网管说这些信息来自一位自称是个Tom的人，他的电子邮件地址是tom@yahoo.com.cn。
下面小李开始利用这封邮件的邮件头信息找到他的IP电子邮件证据认定的实例分析，他找到了下列邮件头信息：
Received: from web15604.mail.cnb.yahoo.com（［202.165.102.x］） by SNT0 -MC3 -F14.Snt0.hotmail.com with Microsoft SMTPSVC（6.0.3790.4675）；Sat，24 Sep 2010 08:17:50 -0700
Received: from [122.246.51.2x] by web15604.mail.cnb.yahoo.com viaHTTP；Sat，24 Sep 2010 23:17:48 CST
X-Mailer:YahooMailWebService/0.8.114.317681
Message-ID: <1316877468.60773.YahooMail-Neo@web15604.mail.cnb.yahoo.com>
Date: Sat，24 Sep 2010 23:17:48 +0800（CST）
From: zhen tom@yahoo.com.cn
Reply -To: tom fei tom @yahoo.com.cn
Subject: test by webmail
To: =?utf-8?B?6LS56ZyH5a6H?= tom@hotmail.com
经过认真分析、反复核对，小李基本确定了他的IP地址,而且他利用OSINT tools工具箱中的Maltego CE工具输入该电子邮件地址，经过简单配置，系统开始搜索到有关这个邮箱更多的信息。小李来到小王的办公桌前，想看看是否能够找到一些其他的信息，也许会有些头绪。小李让小王再次检查一下FTP日志。
#grep apple1.avi xfelog
Mon Sept 10 04:48:18 2010 1 postprod 147456/completed/apple1.avi b_oa\lex ftp 0*i
同样，在工作人员上传完文件之后没有人再访问过这些文件。小李问小王是否还有其他的方法能够获取这些文件。小王解释说，这台主机设置了防火墙，只允许21、22、80端口通过，也就是只允许通过SSH、FTP和Apache三种服务访问。于是小李又让小王检查在这些文件上传FTP服务器之后的SSH日志文件。
Sep 10 17:24:58 postprod sshd[3211]:Accepted password for wanglei from 192.168.0.3 port 49172 ssh2
Sep 10 18:03:18 postprod sshd[3211]:Accepted password for wanglei from 192.168.0.3 port 49172 ssh2
Sep 10 22:13:38 postprod sshd[3211]:Accepted password for wanglei from 192.168.0.3 port 49172 ssh2
同样的结果，小李感到非常失落。现在的问题是，没有人访问过这些文件，那这些文件又是怎么泄漏出去的呢？接下来小王只好查看Web服务器日志文件，看看能否查到一点线索。
#grep hawk.avi /var/log/apache/
192.168.1.11--[10/Sep/2010:23:55:36 -0700] "GET /completed/hawk.avi HTTP/1.0"200 2323336
小王的眼睛亮了起来，小李也惊喜地张大了嘴巴，192.168.1.11这个地址是公司内网地址，也许他们找到了“凶手”！他们发现了一个异常的IP地址，他之前从来没有见过这个IP（192.168.1.11）地址。这个IP不属于DHCP范围之内，而属于一个静态服务器范围。小李问小王是否知道哪一台服务器使用这个IP，小王不能确定。但这个IP一定不属于后期制作服务器群所在的VLAN。小李决定再仔细查看一下Web服务器日志文件，这次主要是看一看这个可疑的IP地址：
# grep `192.168.1.11`  /var/log/apache/
192.168.1.11--[10/Sep/2010:23:50:36 -0700] "GET /index.html HTTP/1.0"200 2326
192.168.1.11--[10/Sep/2010:23:55:36 -0700] "GET /completed/index.html HTTP/1.0" 200 2378
192.168.1.11--[10/Sep/2010:23:51:36 -0700] "GET /completed/movie-cab.avi  HTTP/1.0 " 200 1242326
192.168.1.11--[10/Sep/2010:23:52:24 -0700] "GET /completed/hawk.avi HTTP/1.0" 200 2323336
192.168.1.11--[10/Sep/2010:23:55:36 -0700] "GET /completed/apple1.avi HTTP/1.0"200 642326
192.168.1.11--[10/Sep/2010:14:00:38 -0700] "GET /completed/pool.avi HTTP/1.0"200 662326
192.168.1.11--[10/Sep/2010:23:55:36 -0700] "GET /completed/less.avi HTTP/1.0"200 2552326
小李发现有一个人浏览了很多文件。在公司丢失更多的文件之前，小李必须查清楚到底发生了什么。小李告诉了小王新的进展，他为此很高兴，不过他希望小李能尽快找到事情的最终答案。小李回到了自己的座位上继续跟踪刚才日志上的可疑IP。他感到非常兴奋，因为“嫌疑人”更近了，尽管他还并不清楚该从何开始。他认为追捕到这个IP地址的最佳办法是找到这个IP地址在物理上是从哪里连上网络的。要做到这一点，就要把该机器连接到交换机的端口以便和机器的MAC地址匹配起来。

五、遗忘的Squid服务器
小李首先ping这个IP地址，然后从ARP表中得到这台机器的MAC地址。
1）.追查非法使用端口
小李得到了重要的信息，他立刻远程登录到服务器连接的Cisco交换机上。经过几次尝试以后，有了重大的突破。
我们使用ping命令看看他机器网卡的MAC地址是多少。
Interface: 192.168.3.41 on Interface 0x1000003
Internet Address  Physical Address  Type
192.168.1.1         00-30-ab-04-26-dd   dynamic
192.168.1.11        00-0d-56-21-af-d6    dynamic
从本机的ARP缓存里看这个可疑IP地址的MAC地址为00-0d-56-21-af-d6，登录交换机一看果然还是这个地址。
BJ-SW#show arp | in 192.168.1.11
Internet  192.168.1.11              3   000d.5621.afd6  ARPA   Vlan20
下一步，我们要知道他的机器是接到哪台交换机器上。
BJ-SW#show mac-address-table dynamic address 000d.5621.afd6
Unicast Entries
vlan   mac address     type        protocols               port
-------+---------------+--------+---------------------+--------------------
  20    000d.5621.afd6   dynamic ip,ipx                 GigabitEthernet3/2
从结果看这是通过千兆端口连接。我们看看邻居（这是核心交换机器的二级级联交换机）
BJ-SW-419-1-4#sh cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
SW-419-2-3    Gig 3/4            152          S I      WS-C3550-4Gig 0/2
SW-419-1-3    Gig 3/3            168          S I      WS-C3550-4Gig 0/2
SW-440-1-4    Gig 3/1            173          S I      WS-C3550-4Gig 0/2
SW-440-2-4    Gig 3/2            143          S I      WS-C3550-2Gig 0/2
终于找到它了，在SW-440-2-4 Gig 3/2 143 SI WS-C3550-2Gig 0/2 上，下面我们直接登录到SW-440-2-4这台交换机，输入MAC查找。
SW-440-2-4#show mac-address-table dynamic address 000d.5621.afd6
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  20    000d.5621.afd6    DYNAMIC     Fa0/23
Total Mac Addresses for this criterion: 1
然后根据综合布线时的跳线表就可直接到这台机器,接下来关闭该端口。
注意：作为管理人员，快速定位交换机端口，找出IP和MAC对应关系是必须掌握的一项技能，熟悉以上方法能为平时故障排除达到事半功倍的效果。
    小李发现了这个系统就连在服务器交换机的第23个端口上，于是冲下大楼直奔小机房，迅速来到Catalyst交换机前找到第23端口，然后开始顺藤摸瓜。可杂乱繁多的网线，一看就头疼，查找问题花去了小李很多的时间。最后终于找到了连接的主机，小李发现，该主机内部有两块网卡。他从网线堆里爬出来，无奈地看着这台机子，机箱上面贴着一张发黄的旧标签，上面写着Squid Proxy Server。这时小李立刻有种反胃的感觉，因为这台服务器至少1年多没有使用了，而且自从他升职后，这台服务器也确实没有使用过。
小李现在根本不能确定黑客到底是从哪儿入侵的，代理服务器又为他们的调查出了一个难题。小王倒是给小李提供了一些有用的线索，他把前任经理给他留下的服务器用户名及口令清单交给了小李。小李迅速回到自己的座位开始工作。他登录到Squid代理服务器上，希望这一次能有所发现。

六、疑点分析
　　小李迅速打开终端，用SSH登录到服务器，使用root用户和口令。成功登录系统了。小李很容易就查到access.log文件，现在他可以查出任何一个登录过该服务器的人。
squidbox#1s -1  /usr/local/squid/logs/access.log
-rw-rw-r-- 1 squid squid 2838159 Sep 11 03:25 access.log
这时问题出现了，由于SQUID服务器工作时间长，squid.log的日志非常庞大，查个IP也不是容易的事，如何将access.log的IP提取出来呢？小李使用以下命令：
squidbox#awk ‘{print$3;}’ access.log
    小李看到了他最不愿看到的事---该文件最后一次修改的时间是今天的凌晨3：00。现在应该看看这个文件：
squidbox# tail  /usr/local/squid/logs/access.log
892710014.016 14009 10.100.4x.5x TCP_MISS/304 126 GET http://192.168.2.3/completed/less.avi --
    显然，在公司网络以外的人通过代理服务器进入过后期制作的Web服务器。通过日志文件，小李清楚地知道黑客在昨天夜里访问过Hawk和Apple的胶片。他非常希望这个黑客能够在今晚再次造访，以便抓个正着。
小李赶紧跑到小王的办公室，把这个消息告诉了他。找到了“凶手”，小王感到轻松了许多，同时希望能够找到更多关于这个黑客的信息。小李建议说，他们应该拔掉代理服务器外网的接口，防止黑客卷土重来。小王同意小李的建议，至少他们不能再泄露更多胶片文件。小李回到小机房，拔掉代理服务器外网口的网线（这段是连接互联网的）。然后回到自己的座位决定做一些侦察工作。他想继续跟踪这个黑客，并且一定要给他一点儿颜色看看。因为此类入侵事件具有时效性，错过这个村就没这个店。这时小李决定架设一套蜜罐系统来诱捕黑客，以便获得更多的证据。

七、反击--诱捕入侵者
     由于IDS等网络设备昂贵，他们所在的公司无力更换新的安全设备，所以他设计了虚拟机下的蜜罐系统,下面的内容讲述了架设蜜罐系统的注意事项。
     一般情况下，蜜网由蜜网网关、入侵检测系统及若干个蜜罐主机组成。其中蜜网网关是控制蜜网网络的枢纽，在网关上安装多种工具软件，对数据进行重定向、捕获、控制和分析处理，如IPTables、Snort、SebekServer、Walleye等。访问业务主机的流量不经过蜜网网关，而访问蜜罐的网络连接，都由重定向器引向蜜网，而攻击者往往无法察觉。本文描述的是在单一主机上模拟出整个蜜罐系统的解决方案，它是基于最新虚拟机软件VMware 9 和虚拟蜜网技术，构建集网络攻击和防御于一体的网络安全平台。虚拟蜜网部分，除管理计算机外，其他都是基于虚拟机之上。安装虚拟机系统的宿主计算机（蜜网网关）的配置要求稍高，这样可更好地运行多个虚拟蜜罐操作系统。
接口描述：在虚拟蜜网网关中，有3个网络接口：
eth0 是面向业务网络的外部接口。
eth1 是面向多虚拟蜜罐系统的内部接口，Eth0 和Eth1 在网桥模式，均无IP 地址，数据包经过网关时TTL 值也不会变化, 也不会提供自身的MAC 地址, 因此蜜网网关对于攻击者是透明不可见的，入侵者不会识别出其所攻击的网络是一个蜜网系统。
eth2 是用作远程管理，具有实际IP 地址，可把出入虚拟蜜罐系统的数据包及蜜网系统日志转发给一台作远程管理的主机。
架构详情如图2所示。




图2虚拟蜜罐架构图
架设好蜜网系统，就等神秘人再次造访，以便获取更多有价值的日志信息。小李先使用nslookup命令查看了该IP的DNS服务器的主机名、域名、地址。
#nslookup 10.100.4x.5x
Server: ns1.movie.com
Address: 10.1.1.11
Name:   chewie.someisp.ru
Address: 10.100.4x.5x
经过综合分析，比较邮件头信息和蜜罐系统中找到的IP，完全吻合，这回发送者IP 终于找到了，小李松了口气。下面就要通过电信找到这个人是在哪里拨号上网的，就能找到申请电话、住址及姓名。

八、预防措施
在这个案例中，小李并没有意识到网络中存在这样一个代理服务器，这简直糟透了。如果你管理一个网络，最好对网络进行安全审计。前任IT管理员留下的网络结构图中清楚地指明了代理服务器，但是因为服务器没有上线，所以没有引起小李的注意。既然代理服务器并没有真正使用，所以应该及时与网络断开。
开放式代理服务器的最大问题是访问控制列表的不合适的配置。对于squid代理服务器来说，合适的设置应该是下面这样：
acl mynetwork src 192.168.1.0/255.255.255.0
http_access allow  mynetwork
http_access deny all
    在这个案例中，小李采取了适当的补救方法。尽管在开始的时候他的方法有些不得当，但当他开始怀疑代理服务器的时候，他就从网络中断开了该服务器的物理连接。在服务器从物理上断开后，就可以开始细致的检查，而不用担心黑客会再次通过代理服务器入侵。同时小李还应该考虑检查所有的日志文件，这样才可能全面评估这次入侵造成的损失。如果在事发之前小李安装了集中日志收集系统，或者是OSSIM开源安全信息平台，则对于这些日志查询与分析将变得容易多了。