内容提要

本案例集内容取材于CSNA网络分析技术专家在工作中的实际分析案例，按照案例对应的领域，分为

业务性能管理与网络安全分析两部分。

第一部分 业务性能管理

本部分主要面向网络丢包、网络高时延、连接失败、传输速度慢、间歇性卡顿、偶发性访问异常、应

用交易失败、应用异常中断、环路等网络故障及业务性能异常问题的分析思路与解决方法。

第二部分 网络安全分析

本部分主要围绕APT攻击、关基设施攻击、0-Day漏洞发现、Web网站渗透、漏洞利用、邮件数据窃

取、社工钓鱼、溯源反制、DDoS攻击、挖矿勒索等危害网络空间安全行为进行发现、分析和取证的过程。

本案例集内容中涉及的网络流量分析产品：如科来业务性能管理系统（UPM）、科来网络回溯分析系

统（RAS）、科来网络全流量安全分析系统（TSA）、科来网络数据安全管理与分析平台（BFC）等均可通过

科来微信公众号申请免费试用。另外，科来其他产品，包括：科来云魔方智能云网分析平台（CMC）、科

来工控安全监测与审计系统（CPS）、科来网络分析系统（CSNAS）、科来网络元数据采集审计系统（MDP）

等产品也可通过科来微信公众号申请免费试用。

科来为方便广大技术爱好者学习，在官网及科来微信公众号中提供免费软件、视频教程及更多学习

资料的下载，如果您需要技术支持，亦可通过科来微信公众号联系我们。

科来致力于网络流量分析技术的推广，希望将更多技术研究成果与分析思路分享给在校师生。因此，

本案例集免费提供给广大高校师生，欢迎致电科来领取。

本案例集为非卖品，不以任何形式出售，未经科来书面许可，不得以任何方式复制、修改或抄袭本案例集

部分或全部内容。

版权所有，侵权必究。

如本案例集中有缺损问题，您可以联系科来进行调换。

科来服务热线：400 6869 069

©2003-2023 科来网络技术股份有限公司 版权所有 保留所有权利

自 序

科来自2003年成立至今，始终坚持以技术为核心的自主研发及创新，不断深化产品

功能与优化服务，逐步形成了以运维、安全、云、工控为重点的产品线，同时在为用户

服务的过程中积累了大量网络分析实战经验与典型案例，这些案例对科来甚至网络流

量分析技术本身都具有深远的意义。

本案例集的案例为科来对所遇到的各类问题做出的解决方案，其意义不仅仅是对案

例进行解析，确切地讲，它提供了解决各种问题的分析思路，有举一反三的作用。掌握

了这些知识，也就具备了解决大部分网络安全与业务性能问题的能力。

科来于2005年开办了CSNA网络分析认证培训，该培训是基于科来对网络协议的见

解与行业内二十年的实战经验累积，对业务性能管理、罕见网络安全事件样本的深度分

析总结发展而来。学员通过培训，能够熟练掌握网络分析技术，同时掌握解决90%以上

的网络运维与网络安全问题的思路。CSNA网络分析认证培训开办至今已经培养了众多

优秀的网络分析技术人才，学员广泛就业于关系国计民生行业的重要岗位。一直以来，

科来积极联系各大高校，义务进行技术知识传播，推出各类资料帮助在校学生快速入门。

同时，我们坚信在理论知识的基础上，配合实战案例的学习，能够显著提高毕业生市场

竞争力。

最后，感谢为此案例集贡献内容的所有技术工程师，是他们始终如一的奉献与坚持

成就了此书；还要感谢科来忠实粉丝的一贯支持与帮助，你们的热情是科来勇往直前的

动力。同时，科来希望大家能够将自己实际遇到的案例整理分享出来，为更多人提供解

决实际问题的思路和方法，您可以投稿到：support@colasoft.com.cn，我们将予以答谢。

前 言

我们正身处在高度信息化社会、网络社会，更加多样、复杂且重要的数据和信息以

网络流量的形态在第五空间中互传互通。 “十四五”规划纲要中提出迎接数字时代，

激活数据要素潜能，推进网络强国建设，加快建设数字经济、数字社会、数字政府，以

数字化转型整体驱动生产方式、生活方式和治理方式变革；同时，随着“两法一条例”

的发布和实施进一步说明，网络的深度应用和安全性对社会的影响深度前所未有。

“等保2.0”、“关键信息基础设施安全保护条例”反映出国家对重要关基单位的网

络安全保障要求上升到更高层次；“数据安全法”、“个人信息保护法”则体现了国家对

网络数据安全的重视程度。在网络攻击技术与手段愈发复杂多样的大背景下，传统的网

络安防体系难以进行有效防御。科来认为网络流量分析技术是保障网络安全的有效手

段，因为再高级的攻击都会留下网络痕迹，而网络攻击者的行为和我们正常的网络访问

行为所产生的数据是不一样的。通过对网络全流量的分析能够及时发现网络异常行为，

从而做到对网络威胁的全面感知。

网络流量分析技术不仅是保障网络安全的有效手段，在业务性能管理方面同样发挥

巨大的作用。运维的根本是保障业务的持续高效运行，而业务表现在网络中则是川流不

息的数据。如今，我们要面对传输在庞大网络、云网络、云上云下多网络等复杂多样性

网络环境中的业务数据，只有实现对网络中的全流量进行实时的、智能的、高度可视的

监控与分析时，才能够提升对复杂业务系统运维的能力和效率，降低故障排查的时间成

本，使运维人员更加从容主动的应对核心业务的运维需求。

那么，如何在遭受网络攻击时，实现对网络异常行为的取证及数据再现？如何在业

务性能出现异常时，迅速定位异常根源，及时止损定责？如何在学习网络分析技术时，

了解实战中会遇到的问题及解决思路？《CSNA网络分析经典实战案例》将通过对各类

典型实战案例的汇总分析，为您解答上述疑问。

目 录

第一部分 业务性能管理

第1章 * 如何快速定位应用系统无法访问问题 .................................................................1

第2章 * 如何定位两地联调中出现的业务互访异常故障根源......................................6

第3章 * 如何定位营销秒杀活动卡顿的问题....................................................................11

第4章 * 如何保障远程视频会议顺利进行.........................................................................18

第5章 * 如何解决二维码扫描读取等待问题....................................................................24

第6章 * 如何定位迁移后的核心业务访问缓慢问题 ......................................................29

第7章 * 如何分析工业场景中网络故障的危急事件......................................................34

第8章 * 如何分析容灾系统传输慢的原因.........................................................................39

第9章 * 如何发现无规律性HTTP交易失败故障真相....................................................44

第10章* 如何定位网络访问出现的高延迟问题................................................................48

第11章* 如何解决业务系统文件上传失败问题................................................................57

第12章* 如何分析数字程控交换机无规律中断现象 ......................................................62

第13章* 如何定位网站中APP下载失败的故障原因 .......................................................66

第14章* 如何定位门户网站访问缓慢问题.........................................................................71

第15章* 如何分析监控画面通过内网调用超时问题 ......................................................79

第16章* 如何定位医疗系统中偶发卡顿问题....................................................................87

第17章* 如何定位压力测试中的故障问题.........................................................................91

第18章* 如何解决网络身份认证系统信息上传故障 ......................................................96

第19章* 如何发现大型网络中路由环路问题................................................................. 100

第20章 定位支付交易失败率高的原因.......................................................................... 106

第21章 解决“双十一”前夕支付宝业务交易失败问题.......................................... 112

第22章 如何定位应用中断的根源................................................................................... 120

第23章 如何解决SSL访问缓慢问题................................................................................. 128

第24章 如何解决远程VPN连接失败问题 ..................................................................... 135

第25章 如何解决业务应用访问失败的问题................................................................. 139

第26章 如何找出偶发性系统宕机的根源 ..................................................................... 146

第27章 为何企业的OA系统访问缓慢 ............................................................................ 155

第28章 如何解决C/S架构应用访问缓慢问题.............................................................. 162

第29章 如何找出ERP访问缓慢或宕机的根源............................................................. 167

第30章 如何分析无盘客户端无法正常启动................................................................. 175

第二部分 网络安全分析

第31章* 如何通过识别资产发现境外IP入侵关基单位的隐秘行为........................ 185

第32章* 如何发现与分析某OA系统的0-Day漏洞攻击............................................... 191

第33章* 如何分析攻防场景中的入侵成功行为............................................................. 199

第34章* 如何发现与分析某APT组织的窃取数据攻击 ............................................... 205

第35章* 如何溯源扩线针对邮箱服务器的攻击行为 ................................................... 209

第36章* 如何分析微信社工钓鱼成功的后续攻击行为............................................... 215

第37章* 如何研判OA系统在攻防场景中出现的1-Day漏洞利用攻击.................... 229

第38章* 如何分析攻防场景中的攻击探测行为............................................................. 233

第39章* 如何发现并溯源攻防场景中的Webshell攻击行为........................................ 240

第40章* 如何分析下级单位被“拿下”后向上级单位发起的攻击........................ 246

第41章* 如何对数据库UDF提权攻击进行溯源取证................................................... 254

第42章* 如何发现利用WebLogic反序列化漏洞的攻击行为...................................... 261

第43章* 如何对攻防场景中“断网”故障根因进行分析.......................................... 266

第44章* 如何通过流量分析发现攻击并溯源反制被控“肉鸡”............................. 272

第45章* 如何发现利用Apache Shiro漏洞的攻击行为.................................................. 281

第46章* 如何发现内网中被控的“挖矿”主机............................................................. 288

第47章* 如何通过流量分析发现勒索病毒的传染源 ................................................... 292

第48章* 如何分析网络出口设备遭受的DDoS攻击...................................................... 295

第49章* 如何找出造成传输层拒绝服务的攻击行为 ................................................... 302

第50章 如何分析邮件系统遭受的攻击行为................................................................. 307

第51章 如何分析入侵门户网站的攻击行为................................................................. 313

第52章 如何分析恶意篡改网站内容的攻击行为........................................................ 320

第53章 如何发现利用DNS放大攻击服务器的行为................................................... 326

第54章 如何找出造成应用层拒绝服务的攻击行为................................................... 330

第55章 如何找出内网被控主机........................................................................................ 334

第56章 如何找出ARP病毒攻击 ........................................................................................ 341

附录

科来解决方案............................................................................................................................ 347

CSNA网络分析认证培训....................................................................................................... 353

科来公开课................................................................................................................................. 355

《网络攻击与防范图谱》..................................................................................................... 356

《网络通讯协议图》 .............................................................................................................. 357

目录中有“*”标识为新增案例

同步讲解视频请扫描下方二维码观看

第一部分

业务性能管理

《数字中国建设整体布局规划》中，明确要求构筑自立自强的数字技术创新体系，筑牢可信可控

的数字安全屏障，通过数字化方式提升效率，持续推进科技赋能与科技转型。数字化时代，业务与科

技的融合正在进一步加深，运维的根本是保障业务的连续性，并确保高效、稳定的运行。

越来越多的企业通过大数据技术、核心业务上云为用户提供更加灵活高效的服务。一方面，随着

网络技术的深度应用，大流量场景增加，业务与系统之间的访问关系变的错综复杂，增加了故障出现

的风险及处理难度；另一方面，业务系统从传统的物理机时代向云化、微服务化发展，集中的交易系

统正在被不断拆分成多个独立的交易模块，增强云上云下业务的可观测性迫在眉睫。

科来通过全流量分析技术对网络中的流量进行实时的、智能的、完全可视的采集与分析，并率

先在国产化高传输流量采集与实时分析处理技术上取得突破，满足对关键业务运维的大流量承接与处

置、实时监控分析、用户体验等高要求。同时，科来打造以业务为核心，覆盖云网上下的网络、业务、

交易一体化的全链路可视化解决方案，通过全面详细的业务应用性能状态指标，实时监控应用系统的

运行质量，在多云多网的复杂环境下主动发现业务运行异常、潜在风险，快速定位故障、清除隐患。

科来在网络性能管理与监控方面的创新，能够帮助用户实现从被动运维到主动运维的转变，通过技术

创新，赋能用户业务发展，让企业拥有更强的商业洞察能力。

随着网络的高速发展，用户网络环境中的网络、安

全设备越来越多，业务流量在网络设备中的传输路径越

来越复杂。

当用户访问出现异常，业务系统维护人员往往在定

位故障上使用的时间远远超出解决故障的时间。本案例

介绍如何通过科来业务性能管理系统快速发现业务故障

原因。

1.1 问题描述

某单位的 OA 系统 10.X.X.95 近期出现了故障，用

户从外网或内网访问 OA 办公系统的部分模块时，频繁

出现无法访问的故障。由于该单位部署了科来业务性能

解决方案，因此决定采用 UPM+RAS 设备对故障原因进

行分析。

1.2 分析过程

使用 UPM 系统对 OA 系统整日流量趋势进行回溯

分析，业务系统流量整体较小亦均衡，但曾出现短时间

的流量突增。经过与该单位运维人员沟通得知，该时间

点的突增是运维人员下载文件，属于正常现象。

如何快速定位应用系统

无法访问问题

第 1 章

第 1 章 如何快速定位应用系统无法访问问题

2

图 1-1

对 OA 服务器的整日网络状态进行分析，当天的客户端 RTT 趋势较为平稳，最高

值 1.66ms，平均值 703us，当天访问的客户端网络时延较好。

图 1-2

再观察当天的服务器 RTT 趋势，最高值 1.8ms，平均值 387us，当天访问的服务器

网络时延较好。

图 1-3

客户端和服务器的 RTT 整体较好，说明在取样分析的当天，网络状况优秀，因此

可以排除网络故障原因导致的异常。

再观察服务器的窗口大小，窗口大小指标往往可以预示着服务器的硬件性能。取一

天的数值进行分析，该日的服务器平均窗口大小为 59.3KB，出现 0 窗口事件次数为 0，

服务器性能较好，因此可以排除服务器硬件原因导致的异常。

图 1-4

第 1 章 如何快速定位应用系统无法访问问题

3

接下来对 OA 系统交易状态进行分析，当天共产生 7333 次交易，1 次交易失败（无

响应），交易成功率为 99.99%，OA 系统应用层平均响应事件为 1.13s，交易峰值为 95

次/秒。通过趋势图观察，发现应用的并发请求数和应用响应时间基本成正比，请求数

上升的时候服务器平均响应时间亦随之上升，基本属于正常情况。

图 1-5

对 7333 次交易按照请求的 URL 进行分类汇总分析，发现部分 URL 会出现响应时

间长，经咨询运维人员属于正常现象，该部分 URL 需要查询历史数据导致响应时间会

较长。

图 1-6

对 OA 系统在当天响应的状态码进行统计，有 15.96%的响应是以 403 响应的，该

部分响应状态异常。

第 1 章 如何快速定位应用系统无法访问问题

4

图 1-7

将部分用户的原始流量下载至本地进行详细数据流解码分析，发现每次在出现 403

请求后，用户的下一次访问就会跳转到 login.ashx 页面，如图所示：

图 1-8

HTTP 响应码为 403 的会话数据流如下图所示：

图 1-9

用户登录成功的会话数据流如下图所示：

图 1-10

第 1 章 如何快速定位应用系统无法访问问题

5

综上所述，网站的登录和认证功能正常。但经过日志中可以看出，该用户在登录成

功后，又被 OA 系统响应 403 状态码，要求登录。

再取多个被用户访问异常记录深入分析，发现服务器响应 403 的原因是用户的登

录状态异常；用户初始登录时提交一次登录信息显示登录正常，登录后再次访问服务器

却要求用户重登录。

1.3 分析结论

通过对应用的流量与交易状态分析，确认用户无法访问的原因为服务器记录用户登

录状态异常，用户访问应用服务器频繁被提醒未授权状态，重复登录导致无法访问现象。

建议系统管理员对该服务器的应用状态检查，调整 session id 验证与保持机制，避

免出现用户登录后丢失登录信息导致用户重复登录。

1.4 价值

在本案例中，使用科来业务性能解决方案，该方案具备将多个探针流量进行统一汇

集、集中展示、集中回溯统计等功能。在本次故障排除中，无需分析底层数据包，通过

指标展示即可排除网络原因与服务器性能原因。通过归类汇集分析，发现网络中 403 响

应码数量较多，再结合原始数据流交互，能够为快速定位到问题原因。

当企业发展到一定规模后，经常需要在不同地区

开设分支机构，如分公司或办事处等，包括集团性企业。

随之而来的是总部与分支机构的互联，实现应用系统、

业务系统的资源共享，实现企业互联的统一管理。对于

异地数据的互联互通，由于各地运营商、数据转发设备

很难做到统一，导致部署维护难度较大，在两地联调过

程中经常会遇到问题。由于之间节点繁多，对问题的定

位有很大难度。

下面的故障案例中涉及到一个知识点——MTU

（Maximum Transmission Unit），直译为最大传输单元，

表示转发设备物理接口能够处理并发的最大长度包。

MTU 在实际应用中并不多见，但被忽略的往往就是问

题产生的关键因素。

2.1 问题描述

A 单位和 B 单位之间即将上线一个互访业务（称

为 X 业务），X 业务上线前需要测试验证，因此 AB 两

家单位的业务负责人分别各自搭建节点设备：A 单位是

发起访问端，即客户端；B 单位是接收访问端，即应用

服务端。

测试环境很快搭建完毕，AB 两家单位合作联调，

起初顺风顺水，但随后便不断出现访问异常现象。不论

测试多少遍，A 单位的客户端始终无法收到 B 单位的

第 2 章

如何定位两地联调中出现的

业务互访异常故障根源

第 2 章 如何定位两地联调中出现的业务互访异常故障根源

7

服务端响应数据。双方业务人员很快进行了跳过远程网络的本地验证，发现本地验证都

没有问题。至此，业务人员明确把问题抛给了网络，为了能够明确问题根源，双方网络

人员决定通过流量分析排查定位问题。

2.2 分析过程

图 2-1

1）A 单位部署有流量采集点，分别是 Client 连接 SW 交换机的镜像点 1 和 FW 防

火墙连接的 RT 路由器镜像点 2。问题发生时，分析同一条异常 TCP 会话，发现两个采

集点的数据时序交互一致，可以排除 A 单位 FW 造成问题的可能。观察解码后的异常

TCP 会话，发现 TCP 三次握手正常，连接能够正常建立，数据请求也正常发出并观察

到了数据回复包，但收到的数据回复包序列号 Seq=2892134097，按照同方向数据包序

列号连续性原则，服务器应该发完上一个确认 ack（Seq=2892132649）后，发送序列号

Seq=2892132649 的数据包，但实际并未看到，如下图。

图 2-2

第 2 章 如何定位两地联调中出现的业务互访异常故障根源

8

2）进一步观察发现，收到的数据回复包序列号 Seq=2892134097 减去上一个确认

Ack 序列号 Seq=2892132649，差值正好是 1448，可能存在 TCP 载荷长度为 1448 的数

据包。随后查看了所有异常会话，发现数据包交互现象一致，推测回复的数据包中首个

载荷为 1448 字节的数据包未被转发过来丢弃掉了。如下图。

图 2-3

3）什么原因造成会话中只是一个 1448 字节数据包无法正常转发过来，而后续字节

为 920 的数据包却能够正常收到呢？是否由于 1448 字节的数据包在经过封装 TCP 包

头（最长 20 字节）、IP 包头（最长 20 字节）后由于数据转发设备 MTU 过小导致不能

转发呢？当然这只是猜测，如果成立，需要明确一个前提条件，即数据包是否 DF 置位？

即不允许分片。TCP 会话在三次握手建链时（SYN 包与 SYN/ACK 包 IP 头部 DF 标志

位）会协商数据包是否超过网络转发设备接口 MTU 不允许分片而直接丢弃。经查验，

发现确实两端在建立 TCP 会话时设置了 DF 位，满足第一条件，如下图。

图 2-4

图 2-5

第 2 章 如何定位两地联调中出现的业务互访异常故障根源

9

4）另外需要确定的问题是，从 B 单位 Server X.X.2.50 到 A 单位 Client X.X.100.103

路径中网络设备数据包发出方向的路径 MTU 大致的范围是多少？（注：MTU 只在网

络设备接口数据发出方向作用，因此你可以在上述图中观察到，从反方向 A 单位至 B

单位的传输路径中 1448 字节数据包能够正常转发）

确定这一问题可以通过 PING 大包测试路径 MTU 的范围。分析人员在 Client

X.X.100.103 端执行 PING 大包测试，CMD 输入 ping X.X.2.50 -f -l 1460（-f 为要求 DF

置位，-l 为指定应用数据长度），ping 结果显示不通，说明路径 MTU＜20（IP 包头）+8

（ICMP 包头）+1460（应用数据长度）=1488 字节，这也证明了 1448 字节数据包在分

装 TCP 包头和 IP 包头各 20 字节后（20+20+1448=1488）确实无法正常转发；然后输入

ping X.X.2.50 -f -l 1448 可以 ping 通，说明路径 MTU＞20（IP 包头）+8（ICMP 包头）

+1448（应用数据长度）=1476 字节，即从 Server 到 Client 这一转发方向的路径 MTU：

1476＜MTU＜1488。

2.3 分析结论

1）由于 TCP 层将应用数据分段后的 1448 字节数据包经过 TCP 头部、IP 头部的封

装， 在 Server 到 Client 这一数据包传输方向上，路径 MTU 处于 1476＜MTU＜1488，

同时数据包 DF 置位，从而被路径中某个网络设备丢弃。

2）因 TCP 连接建立经过 A 单位 FW，分析人员尝试在此 FW 上配置修改 TCP MSS

值为 1024。MSS，即最大报文尺寸，是 TCP 将应用数据（数据包 Payload 部分）切分

时的最大长度，此参数会在 TCP 三次握手时进行协商，协商结果两端采用两者间最小

值。FW 配置 MSS 参数协商功能后，能够主动参与识别并修改三次握手过程中 SYN 包

的 MSS 值，在 TCP 建链过程中充当中间人作用。应用数据被 TCP 层切分小于 1448 字

节，即 1024+20+20=1064，低于 MTU 即可实现正常转发。经修改后验证，Client 立刻

正常收取到服务器全部回复数据，删除此配置，故障问题复现。问题原因最终得到明确

证实。注：限于篇幅，无法展开描述分片与分段的区别以及 MSS 的详细概念、作用及

原理等知识，如需深入了解可以在互联网上检索阅读相关技术资料。

3）对于此问题的解决方法，通过设置转发路径中间 4 层设备的 MSS 参与协商功能

并不推荐，因为此功能对于绝大多数网络厂商设备为全局生效，这会造成经过此防火墙

但未涉及问题转发路径的其它业务受到影响，虽然业务依旧可以正常访问，但无需增多

的小包数量极大影响数据转发效率；最合理有效的方法是在 Client 和 Server 端任意一

端修改内核配置或注册表等，将一端IP MTU值设置为小于中间路径的MTU的值即可。

具体配置也可以在互联网上查找相关技术资料。

第 2 章 如何定位两地联调中出现的业务互访异常故障根源

10

2.4 价值

流量分析技术是网络工程师在运维过程中最直接、最有效的故障分析手段之一。借

助数据包级交互分析，可以清晰还原问题发生场景；深入结合协议交互原理，在有限的

故障现象信息中，快速分析并准确定位故障根因，大大减少了运维工程师面对“疑难杂

症”和“甩锅问题”时的困难及无助，成为运维人员手中解决故障问题的有效利器。

随着网上支付的兴起，手机银行业务成了各银行关

注的重点。为了吸引客户，电商及银行经常会举行营销

秒杀活动，手机银行营销秒杀活动能否稳定运行，直接

关系到用户体验。本案例将详细讲解如何通过科来业务

性能管理系统迅速精准定位故障节点。

3.1 问题描述

某银行 10 点开始进行营销秒杀活动，手机银行营

销秒杀界面出现访问卡顿情况。

运维人员通过部署的科来业务性能管理系统梳理

出手机银行业务的访问逻辑，如下图所示。

如何定位营销秒杀活动

卡顿的问题

第 3 章

第 3 章 如何定位营销秒杀活动卡顿的问题

12

图 3-1

同时对该业务做了手机银行关键性能指标的实时监控视图。

图 3-2

第 3 章 如何定位营销秒杀活动卡顿的问题

13

图 3-3

图 3-4

3.2 分析过程

回溯问题时段的网络关键指标变化，发现网络传输性能指标基本正常，但应用响应

时间较大。

第 3 章 如何定位营销秒杀活动卡顿的问题

14

图 3-5

图 3-6

第 3 章 如何定位营销秒杀活动卡顿的问题

15

在网络时延基本不变的情况下，应用响应时延明显增大，多段对比可知，应用响应

时延增大的主要原因是因为渠道营销支持 APP 响应时间增大导致，平均达到 600ms 以

上；问题时段数据包表现如下。

图 3-7

应用响应时间有些已经达到了 2-3 秒。

与此同时还发现 SSL 卸载之后 WAF 两个抓包点的会话数目不同，WAF 前 167

条 TCP 会话。

图 3-8

第 3 章 如何定位营销秒杀活动卡顿的问题

16

WAF 后 10183 条。

图 3-9

解码分析看到客户端发出的数据包 TTL 不一样，WAF 前为 255，WAF 后为 64，明

显有中间设备做了七层代理，一个 TCP 会话中的多个交易被拆分为多个 TCP 会话。

向客户反馈问题后，客户立刻协调人员排查这个问题，发现某厂商的 WAF 针对该

IP 的保护机制会导致 SSL 卸载后被聚合起来的会话重新拆分。如果会话数目较多会对

F5 的性能有所影响。先前 SSL 卸载后会话被聚合在一起也是出于优化 F5 性能考虑的。

关闭 WAF 针对该 IP 的保护机制后，F5 性能有明显提升。

图 3-10

第 3 章 如何定位营销秒杀活动卡顿的问题

17

图 3-11

3.3 分析结论

通过以上分析，可以得出结论，营销秒杀活动界面访问卡顿问题是由于渠道营销支

持 APP 响应时间较大导致。除此之外，还发现了一个由于 WAF 拆分会话影响 F5 性能

的巨大隐患。

3.4 价值

科来通过对全流量的解码分析，辅以图形化的界面将业务的访问关系梳理出来，使

业务访问可视化，然后通过自定义秒级监控业务的关键指标，在故障发生的第一时间定

位问题点，快速高效的解决问题，极大提升了运维人员的工作效率。同时通过指标的多

段对比，发现隐藏在网络中的其他风险，保障业务系统安全稳定的运行。

如需纸质版资料可扫描下方二维码关注科来

回复“案例集”或添加小编申请领取

第二部分

网络安全分析

中国信息安全测评中心发布的《全球高级持续性威胁（APT）态势报告》中指出，针对我国的APT

攻击持续上升，其中关键信息基础设施单位是APT攻击重要目标，并在未来有更明显趋势。面对以网

络攻击、丧失功能、数据泄漏等为目的的关基风险，关基单位要做到确保关键业务连续运行及重要数

据不被窃取破坏。

科来在流量检测与分析技术领域持续保持自主可控、深入研究，率先实现国产化高传输采集与实

时分析处理能力，掌握该领域核心技术。科来认为，再高级的攻击，都会产生网络流量，网络安全防

御的能力取决于安全感知能力，安全感知能力的重点在于对未知安全威胁的感知。通过科来全流量分

析技术能够为用户提供“上帝视角”，感知未知威胁，实现对网络攻击回溯及入侵的研判和取证。同

时，科来在被动流量识别与资产分析、主动监测预警与防御方面有着多年丰富经验，能帮助用户更清

晰详尽的掌握资产情况。针对关基安全防护，科来能够有效收敛关基资产暴露面，提供攻击手段溯源

取证分析，对告警进行深度研判，为攻击溯源和取证提供最直接、最重要的证据。同时提供供应链安

全、通信网络安全及数据安全保障能力，为关基保护全面构建防护安全体系。科来全流量安全解决方

案帮助用户构建自适应网络安全架构，实现对网络全方位无死角的监控与防护。

目前，科来全流量安全解决方案的应用场景包括：关基保护、资产识别与梳理、攻防研判、安全

事件回查、异常流量检测、网络数据的完整记录、阻断防御、态势感知、元数据安全防护、工控安全

等，该解决方案已经在政府、金融、能源、运营商等行业广泛应用。

在攻防对抗中经常提及“知彼知己百战不殆”，\"知

己\"是对自身的深入了解，只有准确清晰的认知，才能

更好地发挥长处，避免暴露短板。关基设施是黑客攻击

的主要目标，当关基单位对于网络上的资产无法进行

清晰的识别时，会导致暴露面扩大、威胁监测滞后等问

题出现，便给了攻击者可乘之机。

31.1 问题描述

某能源单位在执行日常安全任务时对资产进行梳

理，通过科来设备进行资产识别，筛选出一批小流量业

务资产，为进行暴露面收缩做准备。过程中通过对比资

产画像及其行为习惯后发现了一个流量极小的业务资

产存在异常，并结合流量进行关联分析最终发现威胁

事件。

第 31 章

如何通过识别资产发现境外

IP 入侵关基单位的隐秘行为

第 31 章 如何通过识别资产发现境外 IP 入侵关基单位的隐秘行为

186

31.2 分析过程

首先从资产会话热力图中对各资产流量大小分布情况进行快速确认，可确定小流量

资产范围，联系管理人员确认后开始分析，以进行暴露面收缩。从会话热力图中发现了

一个流量以及会话非常小的资产，经查询 IP 为 XXX.XXX.XX.17。

图 31-1

该资产并不活跃，根据资产自查梳理结果中的“资产表”查看资产具体信息，该资

产只开放了一个 80 端口，且流量极小，周一至周日均不足 1MB。

图 31-2

第 31 章 如何通过识别资产发现境外 IP 入侵关基单位的隐秘行为

187

通过对比该资产的资产画像及其行为习惯后发现存在访问异常，结合科来网络全流

量安全分析系统，分析该资产在统计时间段内的流量情况，发现有境外 IP 对该资产进

行访问。

图 31-3

分析后发现，荷兰的一个 IP XXX.XX.XX.25 于某日晚间成功访问该资产的 80 端

口，请求的页面较为可疑，类似命令执行。

图 31-4

在收到服务端的确认后客户端便关闭了连接。

第 31 章 如何通过识别资产发现境外 IP 入侵关基单位的隐秘行为

188

图 31-5

将时间范围扩大，发现有同网段的境外 IP XXX.XX.XX.219 于某日下午同样访问了

该资产。

图 31-6

对数据包进行分析后发现，该境外 IP 向资产的 80 端口传输了一段加密数据。

图 31-7

第 31 章 如何通过识别资产发现境外 IP 入侵关基单位的隐秘行为

189

图 31-8

根据威胁情报查询该境外 IP 后发现其为恶意 IP 地址并对其进行流量分析，发现其

对同一网段内多个资产的 80、443 端口进行了扫描。选择分析了其中流量数据较大的资

产 XXX.XX.XX.253 。

图 31-9

发现双方成功建立了 TCP 连接并传输了加密数据。联系该设备管理人员进一步对

终端进行排查，并将发现异常的相关资产纳入长期观察目标，从资产的流量、行为、内

容等方面进行针对性的长期监测。

第 31 章 如何通过识别资产发现境外 IP 入侵关基单位的隐秘行为

190

31.3 分析结论

通过科来资产被动流量识别方式对关基单位资产进行全面梳理，通过资产画像发现

资产异常行为，即使流量极小的业务资产也不会遗漏并实现数据留存。经过对产生流量

数据的一系列分析，确认为境外恶意行为，管理员对该资产进行紧急排查，并将该资产

纳为长期流量监控目标。

31.4 价值

科来资产被动流量识别解决企业资产、关基资产发现难、感知难的问题。这种方式

能够发现任何有网络活动的资产，不存在由于反探测技术或安全防护导致识别被阻断

的问题。解决了主动扫描探测时静默资产不在线导致无法发现的难点。另外，旁路部署

被动采集无需对目标网络进行扫描，可以避免对业务造成影响。

同时，科来将对资产的识别、画像、监测三个环节串联结合，通过对关基资产的识

别解析、习惯记录、多维监测，发现资产隐藏风险，监测异常行为，确保了该关基单位

关键业务、系统和服务的安全，避免了业务中断、数据泄露的风险。

软件存在 0-Day，这已是不争的事实，但可怕的不

是漏洞存在的先天性，而是 0-Day 的不可预知性。人们

掌握的安全漏洞知识越来越多，就有更多的漏洞被发

现和利用。企业一般会使用防火墙、入侵检测系统和防

病毒软件来保护关键业务的 IT 基础设施，这些系统提

供了良好的第一级保护，但是尽管安全人员尽了最大

的努力，仍不能避免遭受 0-Day 漏洞攻击。面对 0-Day

真的只有坐以待毙吗？当通过全流量的采集与分析拥

有对未知威胁的感知能力后，我们便有机会斩断悬在

头上的这柄“达摩克里斯之剑”。

32.1 问题描述

某大型企业的 OA 办公系统遭受恶意攻击，由于

该企业部署了科来网络全流量分析设备，完整记录了

攻击全过程。在这起恶性事件中，工程师在进行网络安

全分析的过程中发现系统 0-Day 漏洞。

第 32 章

如何发现与分析某 OA

系统的 0-Day 漏洞攻击

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

192

32.2 分析过程

32.2.1 分析首次攻击行为

09:00 左右攻击者对 OA 系统进行暴破攻击，并不停变换互联网地址进行用户

名、密码暴破；

09:16:52 发现 IPX.X.X.7 链接 URL/seeyon/htmlofficeservlet 进行 POST 上传操作并

成功，如下图。

图 32-1

此时，工程师已经可以确认这是系统存在的一个漏洞，并立即与软件厂商进行沟通，

双方对该漏洞看法达成一致后不久，工程师便得到了相应的补丁。

【随后，该软件厂商对外公布了软件存在的一个漏洞，描述如下：“某某 OA 系统

的一些版本存在任意文件写入漏洞，远程攻击者在无需登录的情况下可通过向

URL/seeyon/htmlofficeservletPOST 精心构造的数据即刻向目标服务器写入任意文件，写

入成功后可执行任意系统命令进而控制目标服务器。”】

工程师所发现的“链接 URL/seeyon/htmlofficeservlet 进行 POST 上传操作并成功”正

是 0-Day 的位置，这是一个典型的 0-Day 漏洞。

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

193

这是后话，我们继续看工程师接下来的分析和操作：

通过还原会话流，发现 X.X.X.7 上传 WebShell，并使用变异 base64 方式加密：

图 32-2

09:17:17 及 09:17:24 发现 X.X.X.7 成功连接 test123456.jsp

图 32-3

之后执行查看当前用户名的指令，服务器成功返回

图 32-4

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

194

09:19:17 攻击者弃用攻击 X.X.X.7，并使用多个 IP 进行连接 WebShell，每个 IP 仅

连接 2-4 次。

图 32-5

经过一系列列目录操作后，将 test123456.jsp 复制到 login-ref1.jsp：

图 32-6

攻击者利用 login-ref1.jsp 执行的命令，将上传的 WebShell（test123456.jsp）删除，

如图：

图 32-7

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

195

执行ShellCode：

图 32-8

通过对上传到服务器的 Powershell 样本进行分析，确认这是 MSF 框架生成的

Payload，CS 和 MSF 都能用，CC 回连 IP 是：114.X.X.X:X。

图 32-9

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

196

通过查询该 IP 是来自北京某 vps 地址，由于 114.X.X.0/24 网段已经被封禁，未能

成功回连。

本案例发生在 9：17 左右，9：30 左右就已经发现相关攻击行为，进行 IP 地址封

禁、服务器删除 WebShell，但攻击者不停更换 IP，并且 WebShell 在内存中执行，未能

完全清除，直到 10：10 执行 ShellCode 左右，发现仍存在相关问题，重启服务器并禁

止访问 WebShell 路径及/seeyon/htmlofficeservlet 路径后，并且更新官方修复补丁，进行

修复。

32.2.2 攻击者再次发起攻击

在 18：31 左右，58.X.X.133 尝试绕过防护访问/htmlofficeservlet 的目录，未成功。

图 32-10

第二次攻击以/seeyon/js/../htmlofficeservlet 进行尝试绕过成功，并且再次成功上传

相同的 WebShell，test123456.jsp，如下图。

图 32-11

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

197

随即，攻击者不停变换攻击 IP，连接 WebShell，并且成功执行远程命令。

图 32-12

攻击者进行查看网卡信息、查看主机 Host 名称、查看主机目录等一系列操作，并

尝试控制受害主机进行违规外联测试，进行进行 ping X.X.X.X 主机、telnet X.X.X.X 主

机的 80 端口等操作。

图 32-13

攻击方并试图从 45.X.X.209 上下载恶意程序，尝试失败后又尝试连接 45.X.X.209

的 TCP 443、8443 等端口，由于服务器配置了严格的策略，所有主动外联尝试均未成

功。攻击方成功上传 she.jsp、shell1.jsp 等木马，但是均被发现。

图 32-14

第 32 章 如何发现与分析某 OA 系统的 0-Day 漏洞攻击

198

32.3 分析结论

系统先后经历两次进攻，第一次攻击行为发生后，工程师重启服务器并禁止访问

WebShell 路径及/seeyon/htmlofficeservlet 路径，随后修复补丁；第二次发现攻击行为后，

将所有绕过路径进行拦截，清除恶意 WebShell，完全修复漏洞及恶意程序。

32.4 价值

网络全流量分析技术能够帮助用户：

1、“看的全”——不仅仅能够发现常见的异常攻击，同样能够发现新型的未知威胁；

2、“看的清”——帮助用户完整还原攻击行为，分析攻击线索，评估处置效果；

3、“看的准”——为后续安全评估及取证提供全量原始数据包取证；

这将赋能网络的全方位安全感知能力，实现网络监测无死角。

网络入侵是无声无息的，如果没有相关设备的监测

与告警，等待网络管理员的可能不是攻击者的叫嚣，而

是监管方的通报。诚然，攻击链中的部分环节可能触发

监测设备的检测规则，产生碎片化的攻击告警。在发现

碎片化的告警信息后，如何完整还原攻击者的攻击链，

成为了防守方的难题。

“网络流量记录着一切真相，再高级的攻击也会留

下痕迹。”通过科来网络回溯分析技术，即使只有碎片化

的告警信息，科来也能够还原攻击者入侵的完整攻击链。

33.1 问题描述

某金融单位进行攻防演练，上午十点相关安全厂商

人员发现金融单位某系统被攻击方植入了 WebShell 木

马，单位相关负责人对此十分重视。

第 33 章

如何分析攻防场景中的

入侵成功行为

第 33 章 如何分析攻防场景中的入侵成功行为

200

33.2 分析过程

因触发告警的失陷主机为 X.X.56.100，无攻击 IP 地址信息。因此通过科来网络全

流量安全分析系统对 X.X.56.100 的 IP 会话进行回溯查询。发现 X.X.1.10 和 X.X.1.131

两个 IP 与 X.X.56.100 的交互流量较大，如下图所示：

图 33-1

针对这两个地址产生的会话内容进行重点分析。利用告警设备产生的 WebShell 文

件名 1.txt 信息，分别对两台主机的相关流量进行检索，发现 X.X.1.131 无相关流量。

对 X.X.1.10 主机的流量进行分析，发现历史流量中存在与 1.txt 有关的 URL 访问

行为。这些流量是未触发相关安全设备告警的“正常流量”，如下图所示：

图 33-2

第 33 章 如何分析攻防场景中的入侵成功行为

201

对1.txt有关的URL请求进行数据流分析，发现了SQL查询语句，并发现了X.X.1.10

是一个代理 IP，其背后的真实 IP 为 X.X.204.204。

图 33-3

再对其真实 IP X.X.204.204 进行回溯分析，发现其曾经进行过更改密码的行为，且

执行成功。与该系统的负责人及相关账号的使用者进行确认，该账号本人并没有进行过

数据库查询和密码更改的操作。

图 33-4

既然本人没有进行过操作，那么上述行为一定是攻击者所为。攻击者更改了密码后，

获得权限。向前分析，攻击者为什么可以对数据库进行操作？

很可能攻击者已经上传了相关木马获得了权限。于是 SQL 修改密码前一段时间的

POST 上传流量进行重点分析，发现了攻击者的上一步动作。

第 33 章 如何分析攻防场景中的入侵成功行为

202

图 33-5

对 URL 请求日志进行分析发现攻击者有获取全部环境属性的行为，并且上传了

test.jsp。

图 33-6

攻击者上传 test.jsp 后，多次尝试请求访问 test.jsp 文件，在凌晨 3：54 分左右请求

成功，成功后攻击者停止了操作。

第 33 章 如何分析攻防场景中的入侵成功行为

203

图 33-7

上午 10 点左右，攻击者利用 WebShell 操作数据库时，被防守方的安全设备发现，

并触发告警。至此，攻击者的攻击链被完整还原。

图 33-8

第 33 章 如何分析攻防场景中的入侵成功行为

204

33.3 分析结论

科来团队发现了可疑的数据库操作行为后，对告警信息进行回溯，攻击者在凌晨利

用 SQL 查询漏洞，修改了网站用户的登录密码，并上传 WebShell 文件，在上午 10 点

对 WebShell 文件进行利用与开展后续攻击行为。成功还原了攻击者的攻击手法并上报

客户及时处置。

33.4 价值

利用全流量回溯分析技术，可以将攻击者任何的蛛丝马迹还原，为防守方对攻击行

为回溯、攻击链还原提供有力依据。进行取证加分，并及时发现和处置防守暴露点位，

收敛攻击面，建立纵深防御体系，防止进一步丢分。

如需纸质版资料可扫描下方二维码关注科来

回复“案例集”或添加小编申请领取

第三部分

附录

➢ 科来解决方案

➢ CSNA网络分析认证培训

➢ 科来公开课

➢ 《网络攻击与防范图谱》

➢ 《网络通讯协议图》

347

科来解决方案

业务性能管理解决方案

科来业务性能管理解决方案，由前端数据采集探针（英文简称“RAS”）与后端统一性能管理分析

平台（英文简称“UPM”）组成，该解决方案提供了整合端到端的交互数据可视化及分析能力，实现了

从故障发现到定位根源，再到追溯取证的网络故障处理流程。

RAS 可分布式部署在用户网络的各个重要汇聚节点，通过交换机端口镜像或流量分流设备等方式

实时采集、存储与分析全部的网络通信数据，实时采集分析网络及业务的关键性能指标；后端的 UPM

分析平台对 RAS 进行集中管理和配置，并对 RAS 采集的数据进行集中分析和展现。

方案价值

➢ 提升复杂业务系统运维的能力和效率

通过系统强大的主动及自动化性能分析能力，智能发现关键业务系统的网络、主机、应用性能下

降，快速分析影响性能的原因并对问题发生点进行隔离，从而有效防止业务整体性能水平降低，使运

维人员更加从容主动的应对关键业务网络运维需求。

➢ 降低故障排查时间成本

提供基于业务视图的性能可视化，系统对每一个支撑业务系统的应用及网络性能下降都能够及时

反馈出对业务的影响，并定位问题所在，从而帮助运维人员迅速排除故障，极大的缩短了排障时间。

➢ 降低人员投入成本

提供基于业务的统一性能管理，能够对支撑整个业务的网络及应用性能进行自动化实时监控和分

析，摆脱了传统的孤立依赖人工的性能监控模式，实现自动化与智能化的业务网络性能管理，有效的

降低人力投入成本。