网络日志分析场景二：谁动了我的文件

置顶 OpenSource SIM

已于 2024-12-18 09:26:24 修改

阅读量736

点赞数 23

文章标签：攻防演练网络安全 Linux

于 2024-12-12 09:33:15 首次发布

本文链接：https://blog.youkuaiyun.com/lcgweb/article/details/144416011

版权

本文描述了一起发生在电影特效公司的影视作品泄露案。IT经理张坤通过分析交换机、服务器日志及邮件信头等多方日志验证推测，最终还原了攻击事件的全貌。文件详细记录了张坤如何与团队成员合作，包括IT项目负责人周亮、网管王磊、网安顾问曹工和新员工小蒋，共同调查并解决这一安全事件。通过一系列的技术手段和逻辑推理，他们揭露了文件泄露的途径，并采取了相应的措施来防止进一步的泄露，同时也为追踪和识别泄露者提供了线索。这个故事强调了网络安全的重要性以及在面对数据泄露时，如何通过技术手段进行有效的调查和应对。

难度系数：★★★★★

关键日志： Apache访问日志、Squid访问日志、邮件头信息

思维导图

谁动了我的文件文章思维导图-优快云直播

谁动了我的文件文章思维导图

知识储备

本文所阐述的内容颇具挑战性，揭示了一个更为复杂的网络安全事件处理流程，其中所涉及的技术难题不仅要求技术人员拥有扎实的专业知识，还必须具备跨学科的能力和丰富的实战经验。阅读本文，读者需具备以下能力：

1.日志分析：

分析Apache访问日志、Squid访问日志、邮件头信息等，需要对这些日志的格式和内容有深入的理解。

从海量日志数据中提取有价值的信息，需要具备强大的数据分析能力和耐心。

2.网络追踪：

通过邮件头信息找到攻击者的IP地址，需要理解邮件传输过程中的各个环节以及如何通过邮件头信息追踪来源。

使用网络工具和技术（如ARP、ICMP、CDP等）来追踪非法接入点和确定设备的物理连接位置。

3.网络安全知识：

理解网络拓扑结构，以及如何在网络中定位和隔离故障设备。

熟悉SSH、FTP、Apache等网络服务的工作原理和日志记录方式。

4.系统和服务器管理：

对Linux服务器的管理，包括用户权限、服务配置和日志管理。

理解Squid代理服务器的配置和日志系统，以及如何从中提取有用的信息。

5.蜜罐技术：

设计和部署蜜罐系统来诱捕和分析黑客行为，这需要对网络安全防御和攻击技术都有深入的了解。

配置虚拟机和虚拟网络环境，以及相关的网络监控和数据分析工具。

6.合规性问题：

在追踪和识别泄露者的过程中，需要遵守相关的法律法规，确保调查过程的合法性。

7.应急响应：

在面对紧急的数据泄露事件时，如何快速响应并采取有效措施来控制损失和防止进一步的泄露。

故事人物关系

一、事件背景

在一个美丽的清晨，张坤驾驶着SUV行驶在上班路上，他拿了Groove Coverage的专辑，播放起了《God Is Girl》并调大了CD的音量，他加大油门，驾车向前方驶去。

张坤在一家电影特效公司上班，他刚刚被提升为IT经理，这对于他来说是一件无比兴奋的事情。目前他们公司正在制作《XX神拳》的特技效果，大家都为之共同努力工作。

每日清晨，他必饮一杯咖啡提神。今日亦不例外，手捧咖啡，他朝办公室稳步走去。

在半路上，他发现自己的办公室门前聚集了一大群人。曹工第一个看到了张坤，而接下来就是周亮和王磊。还没等张坤反应过来，他已被这三人拽进一间会议室。王磊开始讲述事件的要点，不过没有提及任何一个同事的名字。然后，王磊说道“老大，有人将《XX神拳》影片的机密信息散布了出去，在XX网上发布了1分钟的关于《XX神拳》的电影片段。”周亮对此非常关心，因为这些影视片段在昨天早晨才赶工完成。

张坤有点紧张，他抽了支烟，此刻他意识到已经发生的事情对于他们来说意味着什么。周亮的声音因激动而提高了几分：‘那些泄露的片段，正是观众翘首以盼的内容，可它们现在已经人尽皆知了！仅仅一个镜头，就足以让我们公司蒙受几十万元的直接经济损失！’曹工接过话茬，补充道：“电影制作公司已经明确表示，除非我们能彻底查清这件事并防止再次发生，否则他们将不再考虑将电影特效交给我们制作。”张坤这才明白过来，他们不仅失去了这部电影的特效渲染工作，如果消息传开的话，他们将失去更多的机会。

了解业务流程

张坤只是IT人员，并不熟悉动画渲染业务，他为了搞清楚公司业务流程，立刻询问了电影特效文件制作的所有环节，从工作时收到电影制作公司的电影文件，直到这些硬盘运回到电影制作公司。周亮一一叙述了整个过程，因为这些都是在他的监督之下完成的。制片公司将需进行后期制作的电影文件（采用非线性编辑的视频特效）存储于硬盘，王磊随后将这些内容复制到RAID阵列，并通过电子邮件通知后期制作小组。

后期制作小组的工作采取轮班工作方式，所以周亮打算查出昨天是谁处理过XX神拳的文件。后期制作团队完成任务后，将文件放置于服务器上的特定目录。待硬盘中存储足够多的文件，王磊才将硬盘上的文件送给电影制作公司。然后这些文件会被写入磁盘阵列上并离线保存，目前《Boxing》特效文件还没有存储到阵列。

公司内鬼所为？

调查工作进行到第二天清晨，还是没有得到有价值的线索，张坤认为有必要和王磊进行一次交谈以便进一步了解技术细节，但张坤心想“难道是王磊把视频转手卖给XX网站？他是那种人吗？”张坤必须得弄个水落石出。

王磊在公司创建之初就来工作，现已工作多年。他是后期制作团队的系统管理员。王磊和张坤之间联系不多，因为后期制作相对独立。王磊再次向张坤详尽阐述了整个过程，并表示愿意提供更多技术细节。他们的磁盘阵列直接与Linux服务器相连，且所有与该服务器相连的客户端均统一使用Linux系统。所有后期制作成员均通过Web浏览器选取并操作各自的文件，确保了同一电影文件不会同时被两个人处理。这些Web上的代码都是两年前由公司内部开发的，非常可靠。

张坤在与王磊交谈后，确信其并非作案者。一来，王磊不会因小失大，自毁前程；二来，张坤对其业务能力极为赞赏。无奈之下，张坤只得推翻先前的假设。与此同时，王磊正着手调查昨日检查硬盘的人员。

张坤回到办公室，苦思冥想下一步对策。此事似乎非内部员工所为，毕竟公司文化深厚。试想，《XX神拳》若广为人知，渲染农场公司必将迎来辉煌时刻。张坤决定仔细研究一下网络拓扑图，公司的网络拓扑图如图1所示，这是他的前任临走前留给他的，也许能够从中找到一些启示。

图1案例网络拓扑

但是，网络拓扑图似乎并没有给张坤太多帮助，局域网中只有几个VLAN。公司和互联网之间也有着非常标准的防火墙、DMZ区和代理服务器，一切看上去都很正常，调查工作陷入僵局。

这时，王磊来到张坤的办公室说，小蒋是昨天最后一个调取Boxing文件的员工。张坤立刻拿着记事本去找小蒋，打算一探究竟。

小蒋是公司的新员工，张坤曾经见过他几次，但并没有和他谈过话。小蒋向张坤详细说明了工作流程：他先从服务器上下载视频文件，随后进行修改，并最终将修改后的视频文件重新上传至服务器。当张坤询问具体的上传下载方式时，小蒋回答说是通过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的访问记录更是空白一片。

于是张坤一头雾水地回到了自己的办公室。王磊看到张坤并拦住了他，连忙询问是否有新的发现。然而，张坤只能无奈地告诉王磊，自己虽然发现了一些蛛丝马迹，但尚未得到确凿的证据，他会继续追查下去，一旦有了新的线索，定会第一时间向他汇报。

张坤又一次感到自己一整天都像是热锅里的蚂蚁。就在这时候，周亮来到了王磊的办公室。同样的事情发生了！急急忙忙说：“《XX神拳》的电影4K文件被发布在XX网上了”。看到经理这样的情形，王磊和张坤的心里怦怦直跳。

周亮说道影片视频文件是昨天晚上制作完成的，怎么这么快就泄露了呢？并督促他们赶紧调查清楚。这时张坤想到与XX网的网管联系，看看是哪个小子发布了这个视频。当和网管取得了联系后，网管对周亮说这些信息来自一位自称是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 +0800

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

以上信息说明了这封邮件是由 "zhen tom" 发送给 "tom@hotmail.com" 的，主题是 "test by webmail"，邮件通过 Yahoo Mail Web Service 发送，并且邮件在发送过程中经过了 Yahoo 和 Hotmail 的服务器。邮件的发送时间是中国标准时间（UTC+8）2010年9月24日23:17:48。

经过认真分析，张坤基本找到了他的IP地址,随后来到王磊的办公桌前，他想看看是否能够找到一些其他的信息，也许会有些头绪。张坤让王磊再次检查一下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

此时，看到这些内容，王磊的眼前一亮，张坤也惊喜地张大了嘴巴，也许他们找到了“凶手”。他们发现了一个异常的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

张坤发现有人浏览了很多文件（扩展名为avi)。在公司丢失更多的文件之前，张坤必须查清楚到底发生了什么。张坤向王磊报告了新的进展，王磊对此表示高兴，但同时也催促张坤尽快查明事情的真相。紧接着张坤回到了自己的座位上继续跟踪刚才日志上可疑IP。他感到十分振奋，因为‘嫌疑人’的踪迹已越来越清晰，尽管他还不确定从何入手。

他认为，要追踪到这个IP地址，最好的办法是确定它在物理上是如何连接到网络的。要做到这一点，就要把该机器连接到交换机的端口以便和机器的MAC地址匹配起来。

遗忘的Squid服务器

张坤首先通过发送ICMP echo请求到目标IP地址，然后根据ARP协议从本地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

2.追查交换机

接下来，我们需要确定该设备连接的是哪一台交换机。

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          SI      WS-C3550-4Gig 0/2

SW-419-1-3    Gig 3/3            168          SI      WS-C3550-4Gig 0/2

SW-440-1-4    Gig 3/1            173          SI      WS-C3550-4Gig 0/2

SW-440-2-4    Gig 3/2            143          SI      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

接着，根据综合布线时的跳线表就可直接到这台机器，最后shutdown该端口。

注意：对于管理人员而言，快速定位交换机端口并准确找出IP与MAC的对应关系是一项必备技能。熟练掌握上述方法，将极大提升故障排除的效率，达到事半功倍的效果。

张坤发现该系统连接在服务器交换机的第23端口，他立刻冲下大楼，直奔小机房。在Catalyst交换机前，他迅速找到了第23端口，并开始了细致的排查工作。可繁多杂乱的网线，一看就头疼，查找问题花去了张坤很多的时间。最后终于找到了连接的主机，张坤发现，该主机内部有两块网卡。他从杂乱的网线中挣脱出来，无奈地凝视着那台机器，机箱上赫然贴着一张标签：Squid Proxy Server。张坤心中顿时涌起一股不适，这台服务器至少有一年多未曾启用，自他升职以来都无人问津。

张坤目前还是无法确定黑客的入侵路径，而代理服务器的漏洞调查更是增加了调查的复杂性。王磊倒是给张坤提供了一些有用的线索，他把前任经理给他留下的服务器用户名及口令清单交给了张坤。张坤迅速返回座位，投入到工作中。他登录到Squid代理服务器，心中暗自祈愿，希望这次能有所发现。

三、互动问答

1）．在FTP和SSH日志中都没有找到充分的证据，这说明了什么？

2）．张坤使用跟踪代理服务器的方法是最好方法吗？

3）. 张坤是如何通过邮件头信息找到那个IP？

4）.如何通过网络工具查找？

5）.如何查询用户的来源信息？

四、疑点分析

张坤迅速地打开终端，用SSH登录到服务器，使用root用户和口令。成功登录系统了。张坤很容易就查到access.log文件，现在他可以查出任何一个登录过该服务器的人。

squidbox#ls -l /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服务器。通过日志文件，张坤清楚地知道黑客在昨天夜里访问过视频文件。他非常希望这个黑客能够在今晚再次造访，以便抓个正着。

张坤步入王磊的办公室，向其通报了相关消息。获悉“凶手”已被发现，王磊感到一阵释然，并期望能够深入挖掘黑客的更多资料。张坤提出建议，他们应当断开代理服务器与外网的连接，以防止黑客再度发起攻击。王磊对张坤的提议表示赞同，至少他们不能再让更多的视频文件外泄。张坤随后前往小机房，拔除了代理服务器连接互联网的网线。之后，他返回自己的工作位，决定开展一些侦查活动。他打算继续追踪这名黑客，并且决心要给予其适当的教训。鉴于此类入侵事件具有时效性，一旦错失良机，将难以弥补。于是，张坤决定部署一套蜜罐系统，以诱捕黑客，从而获取更多证据。

诱捕入侵者

由于公司的IDS设备不能随便动，所以他设计了蜜罐系统，下面的内容讲述了架设蜜罐系统的注意事项。

通常而言，蜜网由蜜网网关、入侵检测系统以及多个蜜罐主机共同构成。蜜网网关作为整个蜜网的控制中心，其上部署了多种工具软件，如IPTables、Snort、SebekServer、Walleye等，用于数据的重定向、捕获、控制与分析处理。

业务主机的访问流量不流经蜜网网关，而所有指向蜜罐的网络连接均被重定向器导向蜜网，使得攻击者难以察觉。本文所描述的，是在单一主机上模拟出整个蜜罐系统的解决方案，它是基于最新虚拟机软件VMware和虚拟蜜网技术，构建集网络攻击和防御实验于一体的网络安全平台，虚拟蜜网部分，除管理计算机外，其他都是基于虚拟机之上，安装虚拟机系统的宿主计算机（蜜网网关）的配置要求稍高，这样可更好地运行多个虚拟蜜罐操作系统。

五、接口描述

在虚拟蜜网网关中，供设置3个网络接口：

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

详情见架构图2-10所示。

图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地址得以最终确认，张坤因此松了一口气。接下来，需通过电信部门的协助，确定该IP地址对应的上网地点，进而查明申请电话号码、申请人住址及姓名。

六、疑难解析（邮件分析部分）

1）.日志分析

鉴于FTP或SSH日志文件中未发现异常活动迹象，调查人员在追踪服务器及被盗视频文件的日志时，初步调查主要聚焦于特定日志文件，而未对全部文件进行彻底审查。

2）.内网追踪

在局域网内追踪系统是一项复杂的工作。尽管张坤所采用的方法耗时较多，但其依然被认为是最佳方案。在初步调查过程中，张坤建议断开代理服务器的外部接口，以防止黑客再次通过该接口进行入侵。他提出了一个简便的解决方案：彻底从网络中断开该服务器的物理连接，鉴于该服务器并未投入使用。若将来需要使用该服务器，必须配置适当的ACL（访问控制列表），以防止互联网对内网的非法侵入。

3）．通过邮箱中发送的邮件信头信息分析

鉴于篇幅限制，本文仅对信头信息中对证据认定具有关键意义的字段进行深入分析。首先需要明确的是，信头信息是由发件人的邮件用户代理（MUA）、发件人及收件人的邮件服务器、以及在邮件处理过程中参与的中继邮件服务器依次添加的。而收件人的邮件用户代理（MUA）在最终收取邮件时通常不会对信头信息进行添加。因此，位于信头信息最下方的内容是系统最先添加的，而后续产生的信息则覆盖在先前信息之上。若信息的添加顺序与当事人所述的邮件发送、传输、接收过程存在不一致之处，则可对该邮件作为证据的有效性提出质疑。

Received: from web15604.mail.cnb.yahoo.com([202.165.102.5x]) by SNT0 -MC3 -F14.Snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);Sat 24 Sep 2010 08:17:50 -0700

说明：Received字段作为分析邮件传输历史的关键途径，由邮件服务器自动记录邮件在MTA上的传输轨迹，因此通常能够揭示真实的邮件传输过程。即便其他信头字段遭到伪造，通过分析Received字段所蕴含的信息，依然有可能发掘出伪造者的蛛丝马迹。

在邮件传递过程中，邮件通常需要通过其他邮件服务器（即中继服务器）进行中转，最终才能抵达收件人的邮件传输代理（MTA）。因此，邮件头部的Received字段通常会包含多个记录。在这些记录中，对于证据的认定具有重要意义的通常只有两个：最顶端的Received字段记录了邮件的“最后一站”，即邮件传递至收件人服务器的轨迹信息；而最底端的Received字段则记录了邮件的“第一站”，即邮件从邮件用户代理（MUA）传送到发件人服务器的轨迹信息。

本段Received字段，标记为邮件传输的“最后一站”，用于证实邮件已成功送达收件人服务器。

本字段表示该邮件是在服务器使用的时间2010 年9 月24 日08:17:50，即北京时间2010 年9 月24 日23:17:50，被一个自称为web15604.mail.cnb.yahoo.com（其IP 地址为202.165.102.58）的邮件服务器传送到域名为SNT0-MC3-F14.Snt0.hotmail.com 的邮件服务器，使用的软件是Microsoft SMTPSVC（内部版本号为6.0.3790.4675）。

Received: from [122.246.51.27] by web15604.mail.cnb.yahoo.com viaHTTP；Sat，24 Sep 2010 23:17:48 CST

说明：邮件头部的'Received'字段详细记录了邮件从发件人服务器至收件人服务器的传输路径，涵盖了途经的每个服务器的日期、域名或IP地址以及所使用的协议等详细信息。该字段对于追踪邮件的发送路径和验证发件人身份具有至关重要的作用。

本段表明该邮件是在服务器所使用的北京时间（即CST）2010年9月24日23时17分48秒，由IP地址为122.246.51.27的MUA工作站（该工作站未命名，因此from字段留空）通过网页（via HTTP）传送至域名为web15604.mail.cnb.yahoo.com的邮件服务器。

该字段揭示了邮件实际发送时间为北京时间2010年9月24日23时17分48秒，邮件是通过Web Mail发送的，因此未包含计算机名称，但包含了IP地址。经CNNIC查询，该IP地址为XXX分公司动态分配。

信头显示的发送时间为北京时间2010年9月24日23时17分48秒，邮件是通过雅虎Web Mail发送的，IP地址为电信动态分配，这验证了之前系统环境陈述的真实性。

请注意，方括号内的IP地址（122.246.51.27）并非邮件发送人直接提供，而是由发件人服务器在核查后获取的使用MUA发送邮件的计算机的IP地址，故可视为发送邮件计算机的真实IP地址。

X-Mailer:YahooMailWebService/0.8.114.317681

说明：X-Mailer 字段表达的一般是发件人使用的邮件处理程序的信息，该字段说明本邮件编辑时使用的是雅虎公司的Web Mail 程序YahooMailWebService，内部版本号为0.8.114.317681。

该信息与笔者陈述的第一份实例邮件是通过雅虎邮箱的Web Mail 发送的事实相符。

Message-ID: <1316877468.60773.YahooMail-Neo@web15604.mail.cnb.yahoo.com>

说明：Message-ID 字段通常由发件人的邮件服务器或中继邮件服务器赋予。在Received 字段中，有时也会出现ESMTP ID 号，但该ESMTP ID 号仅与特定服务器的邮件传输过程相关联。相比之下，Message-ID 字段始终伴随着邮件，可用于邮件的追踪。

此字段是向邮件服务提供商申请核查邮件原始信息时，用于追踪和定位邮件的关键线索。从本字段看，该ID 号是由发件人邮件服务器web15604.mail.cnb.yahoo.com 赋予的。

Date: Sat,24 Sep 2010 23:17:48 +0800（CST）

说明：若发件人通过Outlook、Foxmail等邮件客户端编辑邮件，则该字段记录的是发件人计算机时钟（即系统时间）所显示的发件人将邮件发送至邮件服务器的时间；若使用WebMail，则该字段记录的是WebMail系统根据邮件系统设定时间，在发件人编辑完成邮件并点击发送后，邮件传送至邮件服务器的时间。

该字段中的CST时间，从其前面的+0800标识来看，可以断定为中国标准时间。

本字段反映的邮件发送时间，若Received字段显示的发件人服务器接收邮件时间与邮件发送时间存在显著不合理差异（通常，邮件传输应在几秒内完成），则可能表明发件人计算机的系统时间与实际时间不一致，存在系统时间设置错误或被人为篡改的情况。

From: tom fei tom××××@yahoo.com.cn

说明：通过使用tomxxxx@yahoo.com.cn账号进行邮件发送，在邮件程序的地址簿中，该账号被标识为名为tom fei的联系人（即在发件人的邮件程序中，该邮件地址被记录为一个名为tom fei的人的邮箱地址）。

此字段仅提供了发件人所声称的发件地址和发件人姓名的信息。然而，根据已核实的信息，本邮件是通过雅虎电子邮局的网页邮箱程序（WebMail）进行编辑和发送的。在编辑过程中，雅虎电子邮局的网页邮箱程序不允许用户自定义发件人地址，并且在将邮件上传至发件人邮件服务器时，该程序亦不支持修改发件人地址或实现匿名发送。基于此，上述字段的真实性得到了验证。

Reply -To: tom fei tom@yahoo.com.cn

说明：回复地址为tomxxxx@yahoo.com.cn，收件人为tom fei。此回复地址由发件人指定，若错误可能导致回复邮件丢失。

Subject: test by webmail

说明：发件人赋予的邮件标题。

To: =?utf-8?B?6LS56ZyH5a6H?= tom@hotmail.com

说明：邮件的收件地址，除非是邮件收悉后进行修改，否则这一地址在发送时伪造的可能很小，否则邮件怎么发送到目的地呢？

4）FLUKE OptiView综合网络分析仪或Cisco Works 2000网络管理平台查找非法接入点。

5）.上网IP地址就是他的互联网访问“身份证”在十多年前，那时多数用户通过PSTN接入，调查这类用户的地址可以根据自动号码识别ANI技术获取用户的主叫电话号码，并通过RADIUS服务器，中存储的用户信息确定用户的接入来源；对于目前应用比较广泛的光纤宽带接入，用户接入来源的确认就没有那么直观了。主要问题在于语音业务与数据业务的分离，导致无法直接获取用户电话号码。

为了追踪用户的真实来源，必须借助电信内部的认证记录、计费记录、用户信息以及系统配置数据库，方能获取有价值的信息。如图3所示。

图3 RADIUS服务器交互过程

对于宽带用户使用PPPOE方式的网上犯罪行为，电信运营商需要配合公安局进行犯罪者的身份追查，而在技术层面需要提供的信息，通常就是用户的精确定位信息，也就是说，通过用户的上网记录、上网IP反向查询出用户上网的线路信息，然后进一步追踪到用户的身份。

下面举个例子，通常普通用户都是使用电信或联通接入网络，当开始获取动态IP，ISP会根据账号、密码随机在一个地址池中分配一个IP地址，与此同时记录以下时间信息，2013年2月28日18时30分29秒，101023123383894（账号），IP:202.107.2.x，操作系统Windows 7，拨号电话12345678（举例），当然实际记录信息比这个还要详细，在电信那里注册的电话号码就知道主人是谁。