反黑战役之谁动了我的文件？-优快云博客

本文详细描述了一起广告公司内部文件泄露事件的调查过程，IT经理小李通过分析交换机、server日志和邮件信头，利用多方面日志内容验证了他的猜测。他最终通过FTP和SSH日志、邮件头信息、Webserver日志以及Squid代理服务器的访问记录，锁定了真正的黑客身份，并采取了相应的预防措施。文章提供了完整的事件流程和解决方案，旨在提高企业对网络安全事件的应对能力。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

一、事件背景

本文描写叙述了IT经理小李在一起广告公司文件泄露的案件中，通过对交换机、server日志和邮件信头进行分析，利用多方面日志内容验证了他的猜測，最后他将这些蛛丝马迹汇总起来，勾勒出了这次攻击事件的完整过程。

大家在看完事件的描写叙述后，是否知道在FTP和SSH日志中找到了什么线索？以下故事開始啦。

故事主人公小李在一家渲染农场（Render Farm）电影特效公司上班，前不久刚刚被提升为IT经理，这对于他来说是一件无比兴奋的事情。眼下他们公司正在制作《某电影》的特技效果，大家都为之共同努力工作。

他每天早上必须喝上一杯咖啡。今天。他拿着咖啡向办公室走去。被小周和小王叫进会议室。

接着。小王開始讲述事件的要点，只是没有提及不论什么一个同事的名字。然后，小王对小李说：“老大。有人将《某电影》的机密信息散布了出去，在某电影站点上公布了1分钟片长的电影片段。

”小周对此很重视，他让我们查出是谁干的（这些视频特效在昨天早晨刚完毕后期制作）。

小李有点紧张。此刻他意识到已经发生的事情对于他们来说意味着什么。小周大声说道：“泄露出去的片段是观众最期望看到的内容，但如今已经公诸于众了。单单是一个镜头就能让公司直接经济损失达数几十万元！”小曹接着补充说，电影制作公司将不会再把自己的电影特效交给他们制作，除非他们将这件事情查个水落石出，而且能防止其再次发生。

小李这才明确过来，他们不仅失去了这部电影的特效渲染工作，假设消息传开的话，他们将失去很多其它的机会。

二、了解业务流程

小李仅仅是IT人员，并不熟悉动画渲染业务，他为了搞清楚公司业务流程，立马询问了电影胶片制作的全部过程。从梦工厂收到电影制作公司的电影胶片。直到这些电影胶片运回到电影制作公司。

小周一一叙述了整个过程，由于这些都是在他的监督之下完毕的。制片公司将须要后期制作的电影胶片（需採用非线性编辑的视频特效）存放在硬盘上，小王将硬盘上的内容拷贝到RAID阵列上，然后给后期制作小组发电子邮件，告诉他们能够取胶片。

后期制作小组的工作採取轮班工作方式。所以小周打算查出昨天是谁处理过某某电影的视频。团队完毕后期制作。视频文件就被放在了server上的一个文件夹下。待硬盘中存储足够多的文件，小王才将硬盘上的文件送给电影制作公司。

然后这些文件会被写入磁盘阵列上并离线保存，眼下《某电影》视频内容还没有归档到阵列上。

三、公司内鬼所为？

调查工作进行到第二天清晨，还是没有得到有价值的线索。小李觉得有必要和小王进行一次交谈，以便进一步了解技术细节。小李心想：“难道是小王把视频卖给影迷站点？他是那种人吗？”小李必须得弄个水落石出。

小王在公司创建之初就来工作，现已工作多年。他是后期制作团队的系统管理员。小王和小李之间联系不多。由于后期制作相对独立。小王再一次向小李解释了全部的过程，他愿意提供很多其它的技术细节，他们的磁盘阵列和Linuxserver之间採用直连方式。与该server相连的全部client也清一色使用Linux系统。全部的后期制作成员都使用Web浏览器来获取他们想要操作的文件。而且挑出他们正在处理的文件，也就是说不可能两个人同一时候操作同一个电影胶片。

这些Web上的代码都是两年前由公司内部开发的，很可靠。

小李从与小王的谈话中确信他不会是作案者。首先。他不会为了贪图眼前的利益而毁掉自己的前程；其次，小李很观赏他的业务能力。

小李回到了自己的办公室，思考着下一步该怎么办。这似乎并不像内部职员所为。公司内有着良好的企业文化，如果《某某电影》这部惊人之作可以家喻户晓的话，渲染农场公司也会因此迎来自己的辉煌。小李决定细致研究一下网络拓扑图。公司的网络拓扑如图1所看到的。这是他的前任临走前留给他的。或许可以从中找到一些启发。

图1 案例网络拓扑

这张网络拓扑图似乎并没有给小李太多帮助，局域网中仅仅有几个VLAN。

公司内网和因特网之间也有防火墙、DMZ区和代理server，一切看上去都非常正常。调查工作陷入僵局。这时。小王来到小李的办公室说，小蒋是昨天最后一个调取某电影胶片文件的员工。

小李立马拿着记事本去找小蒋，打算一探到底。

小蒋是公司的新员工，小李以前见过他几次，但并没有和他谈过话。小蒋告诉小李他工作的整个过程：首先他将视频文件从server下载。然后对它进行编辑加工，接着就将改动过的文件再提交给server。小李询问上传下载的方法时，小蒋说是使用FTP下载。小李听到这条线索。他认为这或许就是问题所在。

于是。他接着问小蒋改动完文件后上传的时间。小蒋会议了一下说。“昨天是我太太生日，所以晚上下班比較准时。大约时间是在5:15～5:30”。

四、取证分析

小李决定先找小王查看后期server上的FTP日志。小王非常高兴事情有了新的进展，他帮助小李查询FTP日志文件。并登录了后期制作server。

# 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、80port通过，也就是仅仅同意通过SSH、FTP和Apache三种服务訪问。

于是小李又让小王检查在这些文件上传FTPserver之后的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

相同的结果。小李感到很失落。如今的问题是，没有人訪问过这些文件，那这些文件又是怎么泄漏出去的呢？接下来小王仅仅好查看Webserver日志文件，看看是否能查到一点线索。

#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范围之内，而属于一个静态server范围。

小李问小王是否知道哪一台server使用这个IP，小王不能确定。但这个IP一定不属于后期制作server群所在的VLAN。小李决定再细致查看一下Webserver日志文件。这次主要是看一看这个可疑的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地址在物理上是从哪里连上网络的。要做到这一点，就要把该机器连接到交换机的port以便和机器的MAC地址匹配起来。

五、遗忘的Squidserver

小李首先ping这个IP地址，然后从ARP表中得到这台机器的MAC地址。

1）.追查非法使用port

小李得到了重要的信息，他立马远程登录到server连接的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

从结果看这是通过千兆port连接。

我们看看邻居（这是核心交换机器的二级级联交换机）

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

然后依据综合布线时的跳线表就可直接到这台机器,接下来关闭该port。

注意：作为管理人员。高速定位交换机port。找出IP和MAC相应关系是必须掌握的一项技能，熟悉以上方法能为平时故障排除达到事半功倍的效果。

小李发现了这个系统就连在server交换机的第23个port上，于是冲下大楼直奔小机房。迅速来到Catalyst交换机前找到第23port，然后開始顺藤摸瓜。

可杂乱繁多的网线，一看就头疼，查找问题花去了小李非常多的时间。最后最终找到了连接的主机，小李发现，该主机内部有两块网卡。他从网线堆里爬出来，无奈地看着这台机子，机箱上面贴着一张发黄的旧标签，上面写着Squid Proxy Server。这时小李立马有种反胃的感觉，由于这台server至少1年多没有使用了，并且自从他升职后。这台server也确实没有使用过。

小李如今根本不能确定黑客究竟是从哪儿入侵的，代理server又为他们的调查出了一个难题。小王倒是给小李提供了一些实用的线索，他把前任经理给他留下的serverusername及口令清单交给了小李。小李迅速回到自己的座位開始工作。他登录到Squid代理server上，希望这一次能有所发现。

六、疑点分析

　　小李迅速打开终端。用SSH登录到server。使用root用户和口令。

成功登录系统了。小李非常easy就查到access.log文件，如今他能够查出不论什么一个登录过该server的人。

squidbox#1s -1 /usr/local/squid/logs/access.log

-rw-rw-r-- 1 squid squid 2838159 Sep 11 03:25 access.log

这时问题出现了，因为SQUIDserver工作时间长，squid.log的日志很庞大，查个IP也不是easy的事。怎样将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 --

显然。在公司网络以外的人通过代理server进入过后期制作的Webserver。通过日志文件，小李清楚地知道黑客在昨天夜里訪问过Hawk和Apple的胶片。他很希望这个黑客可以在今晚再次造訪，以便抓个正着。

小李赶紧跑到小王的办公室，把这个消息告诉了他。

找到了“凶手”。小王感到轻松了很多。同一时候希望可以找到很多其它关于这个黑客的信息。小李建议说，他们应该拔掉代理server外网的接口，防止黑客卷土重来。小王允许小李的建议，至少他们不能再泄露很多其它胶片文件。小李回到小机房，拔掉代理server外网口的网线（这段是连接互联网的）。然后回到自己的座位决定做一些侦察工作。他想继续跟踪这个黑客，而且一定要给他一点儿颜色看看。由于此类入侵事件具有时效性，错过这个村就没这个店。这时小李决定架设一套蜜罐系统来诱捕黑客，以便获得很多其它的证据。

七、诱捕入侵者

因为IDS等网络设备昂贵。他们所在的公司无力更换新的安全设备，所以他设计了虚拟机下的蜜罐系统,以下的内容讲述了架设蜜罐系统的注意事项。

普通情况下。蜜网由蜜网网关、入侵检測系统及若干个蜜罐主机组成。当中蜜网网关是控制蜜网网络的枢纽，在网关上安装多种工具软件，对数据进行重定向、捕获、控制和分析处理，如IPTables、Snort、SebekServer、Walleye等。訪问业务主机的流量不经过蜜网网关，而訪问蜜罐的网络连接。都由重定向器引向蜜网，而攻击者往往无法察觉。本文描写叙述的是在单一主机上模拟出整个蜜罐系统的解决方式，它是基于最新虚拟机软件VMware 9 和虚拟蜜网技术，构建集网络攻击和防御于一体的网络安全平台。虚拟蜜网部分。除管理计算机外。其它都是基于虚拟机之上。

安装虚拟机系统的宿主计算机（蜜网网关）的配置要求稍高，这样可更好地执行多个虚拟蜜罐操作系统。

接口描写叙述：在虚拟蜜网网关中。有3个网络接口：

eth0 是面向业务网络的外部接口。
eth1 是面向多虚拟蜜罐系统的内部接口。Eth0 和Eth1 在网桥模式，均无IP 地址，数据包经过网关时TTL 值也不会变化, 也不会提供自身的MAC 地址, 因此蜜网网关对于攻击者是透明不可见的。入侵者不会识别出其所攻击的网络是一个蜜网系统。
eth2 是用作远程管理，具有实际IP 地址，可把出入虚拟蜜罐系统的数据包及蜜网系统日志转发给一台作远程管理的主机。

架构详情如图2所看到的。

图2虚拟蜜罐架构图

架设好蜜网系统。就等神奇人再次造訪，以便获取很多其它有价值的日志信息。

小李先使用nslookup命令查看了该IP的DNSserver的主机名、域名、地址。

#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 最终找到了。小李松了口气。以下就要通过电信找到这个人是在哪里拨号上网的，就能找到申请电话、住址及姓名。

八、预防措施

在这个案例中。小李并没有意识到网络中存在这样一个代理server。这简直糟透了。假设你管理一个网络，最好对网络进行安全审计。前任IT管理员留下的网络结构图中清楚地指明了代理server，可是由于server没有上线，所以没有引起小李的注意。既然代理server并没有真正使用。所以应该及时与网络断开。

开放式代理server的最大问题是訪问控制列表的不合适的配置。

对于squid代理server来说，合适的设置应该是以下这样：

acl mynetwork src 192.168.1.0/255.255.255.0

http_access allow mynetwork

http_access deny all

在这个案例中。小李採取了适当的补救方法。虽然在開始的时候他的方法有些不得当。但当他開始怀疑代理server的时候，他就从网络中断开了该server的物理连接。

在server从物理上断开后，就能够開始仔细的检查。而不用操心黑客会再次通过代理server入侵。同一时候小李还应该考虑检查全部的日志文件，这样才可能全面评估这次入侵造成的损失。假设在事发之前小李安装了集中日志收集系统，或者是OSSIM开源安全信息平台，则对于这些日志查询与分析将变得easy多了。

转载于:https://www.cnblogs.com/mengfanrong/p/5109616.html