XXX局科来分析报告v1.0.doc

科来网络回溯分析测试报告 XXX科来网络分析系统测试报告2017年12月目录1.测试概要31.1.需求分析31.2.测试目标42.设备部署63.XXX骨干出口73.1.总体流量概要73.2.应用流量排名73.3.IP地址流量排名93.4.IP会话流量排名113.5.TCP会话流量排名123.6.端口访问统计分析134.Web server业务访问质量分析144.1 业务访问量分析144.2 最慢语句追踪165.网络流量可视化监控及异常事件回溯195.1 网络流量可视化监控195.2 异常事件一：流量突发分析225.3 异常事件二：异常TCP连接行为255.4 异常事件三：伪造IP高危DNS请求285.5 异常事件四：ICMP攻击315.6 异常事件五：DNS查询异常346. 告警设置376.1 服务器与网络时延预警376.2 流量突发预警386.3 主机扫描预警396.4 TCP异常通信预警406.5 CIFS蠕虫攻击告警416.6 DDOS攻击预警426.7 邮件安全预警436.8 可疑域名检查461. 测试概要1.1. 需求分析随着网络与应用信息化的全面建设和快速发展，网络中承载了越来越多的关键业务及应用。XX很多业务实现了网络化运营。确保应用访问质量以及网络安全稳定高效的运行已经成为支撑XXX运营的关键。保障网络与应用的安全稳定高效的运行，一直是维护部门的主要任务。但如今网络和应用日益复杂，出故障的可能性也越大，造成的损失也越大；而且现今网络攻击越来越普遍和隐蔽。如何能够迅速的定位网络中的故障，找出攻击者成为网络管理人员头疼的问题。实践证明网络分析能实时的监控和分析网络运行情况，及时发现网络的异常和安全异常行为，快速定位分析网络和应用问题，同时提供强大的安全分析功能，是保障网络安全高效持续运行的非常有效的手段。传统的便携式网络分析产品虽然能够对网络安全事件进行分析。但是，面对越来越复杂的网络安全问题，如何从海量的网络数据中快速发现异常，如何在网络故攻击发生后快速重现攻击现象，并找出攻击源，如何提供长期的数据存储并快速提取历史数据进行精细的数据挖掘分析，是当前网络管理面临的新的挑战，便携式实时网络分析产品面对新的网络管理需求时，存在以下不足：u y 无法实现长期的原始数据保存；u y 无法实现持续的流量监控；u y 无法查看分析历史通讯数据；u y 无法还原历史攻击现象；u y 无法进行网络链路统一集中管理；u y 故障回溯分析能力欠缺；针对新的网络管理挑战，科来软件提供了高性能的网络回溯分析系统，使用灵活、简单的系统架构，实现了长期、大容量的数据存储、历史数据回溯及持续的网络流量监控，为企业网络管理提供了全新的解决方案。1.2. 测试目标测试产品科来网络回溯分析系统RAS5022X；测试时间2017/xx/xx-xx/xx测试目标XXX承载着重要的业务系统，能否有效的运行将影响到业务系统各个环节的协调，因此保障系统网络能够高效、安全的同时，还需要能够监控到网络中承载的业务的流量特征、运行状况，体现运维的核心价值：1. 弥补现有管理手段的空白：网络与应用是互相依托的，都会对用户的业务体验造成影响，现有网络设备由网管工具进行监控，而应用系统则由系统本身的日志进行监控，这两个数据无法进行关联分析；而科来网络回溯分析系统可以从网络角度，通过网络时延、服务器应用语句处理时延、丢包、误码等量化指标来衡量用户的业务体验，弥补现有管理的空白；2. 生产应用梳理：理清网络中各种业务系统流量，从而掌握网络资源占用情况，及时发现异常流量或新上线业务；3. 生产应用监控：通过长期监控分析，建立关键生产应用的安全生产的运行基线，并建立合理的告警阀值，主动的发现生产业务的异常；4. 生产业务性能分析：需要对用户指定的自定义应用进行实时监控和质量分析，能够实时显示及事后分析关键应用的重要通讯质量指标，如：网络响应时间、服务响应时间、通讯会话数量等等。实现主动化、数据化的精细业务质量监控与分析；5. 运维价值展现：横向和纵向的多维度的展现网络运维的价值，流量最大的业务系统排序，每个业务主要有哪些用户在用；流量最大的用户排序，最繁忙的用户主要在跑什么业务系统；6. 网络安全监控：通过7*24小时的监控，发现流量最大的内网/外网主机，分析网络中是否存在攻击、病毒、异常流量等安全隐患。7. 智能预警：根据网络与业务系统的健康基准，设置各种针对业务系统的性能与安全预警，主动的发现问题。2. 设备部署部署方式采用端口镜像（Monitor）旁路方式接入XXX骨干业务出口流量（不会影响原有网络与应用结构）测试设备本次测试采用的设备为科来网络回溯分析服务器RAS5022X， RAS5000系列产品针对大、中型企业网络，RAS5000提供了高达10000Mbps流量的线速捕获，采用RAID5/RAID6存储技术，存储容量最高可达24TB，冗余电源，可热插拔驱动器，提供双口RJ45及双口SFP数据采集网卡。硬件参数指标： 捕获性能：10000Mbps流量实时捕获 管理配置口：双口 RJ45 Ethernet 数据采集口：双口千兆RJ45/双口千兆SFP 数据存储性能：10000Mbps RAID模式：RAID5/RAID6 硬盘：122T SATA23. XXX骨干出口3.1. 总体流量概要从图中框选部分（2017/12/04 00:0012/05 00:00）可以看到，监控区每天流量不大，09:0017:00是一个流量高峰区，峰值流量接近30Mbps，05:00左右流量最低为10Mbps。2017/12/04 00:0012/05 00:00产生总流量187GB，65127字节的数据包占大多数，从TCP数据包类型看来，TCP同步包数量是TCP同步确认包的两倍，TCP重置包也较多。另外非IP流量中，组播流量占比较大3.2. 应用流量排名WEB应用的总字节数最大，有108.90GB；其次是未知TCP应用，总字节数有48.93GB；从总字节数TOP10网络应用的柱状图看来，监控区域中，大部分业务都是基于WEB应用；在监控时间段中，web应用总共108GB，其中XX.XX.32.47占34GB，XX.XX.34.40占25GB，XX.XX.33.48占12GB往下挖掘到对应的IP会话，可以看到web应用产生流量最大的IP会话为XX.XX.33.48XX.XX.27.228与XX.XX.32.59XX.XX.154.33.3. IP地址流量排名IP地址按照总字节数排序，XX.XX.32.47的总字节数达到44.56GB，第二多的XX.XX.33.48为36.96GB；对XX.XX.32.47进行挖掘，发现很多主机都会与它有数据交互，交互IP会话为10244个，交互数据最多IP地址是XX.XX.120.232为3.93GB对内网IP地址的总字节数进行排序，XX.XX.114.17排在了第一位，但数据量不大；只有10MB3.4. IP会话流量排名IP会话流量排名中，XX.XX.33.48XX.XX.27.228、XX.XX.33.48XX.XX.239.58、XX.XX.32.47XX.XX.120.232位于前三，总字节数分别为7.3GB、4.5GB和3.9GB总字节数TOP10的IP会话柱状图；3.5. TCP会话流量排名TCP会话按总字节数排序，发现靠前的基本是访问XX.XX.176.61的36809端口， 总字节数TOP10的TCP会话柱状图；3.6. 端口访问统计分析对端口访问的总字节数进行排序，三个web应用占据前三，其中XX.XX.32.47的8080端口和XX.XX.34.40的8081端口总字节数特别大，分别为33.35GB和25.07GB；柱状图更明显看出XX.XX.32.47的8080端口和XX.XX.34.40的8081端口的较大访问量；4. Web server业务访问质量分析业务性能监控原理：将TCP会话数据流重组，便可通过时延、丢包、重传等参数判断服务器与网络的性能。例如：通过三次握手，可以判断客户端网络时延与服务器端网络时延；对与客户端的每一次请求，我们都可以计算服务器花了多长时间查询、多长时间响应，如下图：4.1 业务访问量分析流量负载：web server流量负载峰值出现在中午12点时段，峰值流量不超过4.0Mbps，目前负载不高监控时间段（2017/11/30 00:00 - 2017/12/00 00:00） 一天流量最大客户端是XX.XX.49.186，产生数据261MB，如下图：服务器端一天产生流量6.21GB，如下图：4.2 最慢语句追踪Web server访问质量分析，选取2017/11/30 20:40:00-22:30:00查看最大响应时间为23s，明显过大，选取其中一组TCP会话（XX.XX.56.85 与XX.XX.33.171）进行深入分析，如下图：对TCP会话进行数据流重组，查看交易时序图，客户端post请求后服务器回复ACK，但过了20s后才响应客户端请求的数据，如下图：对数据包进行解码，查看客户端post的具体内容，如下图：此次post完整语句如下：POST /BusAPI.asmx/GetStationLicense?ticket=54fd563c4819e6da9d9371d4185332fd&Lineid=140724025343935 HTTP/1.1再选取另一组会话（XX.XX.91.104与XX.XX.33.171），进行深入分析，如下图：对TCP交易进行数据流重组，客户端post请求后服务器回复ACK，但过了20s后才响应客户端请求的数据，如下图：对数据包进行解码，查看客户端post的具体内容，如下图：客户端post的完整语句如下：POST /BusAPI.asmx/GetStationLicense?ticket=87eeec651df9ce898490a12b42e95b8c&Lineid=161225013720786 HTTP/1.1小结：两次相同时间，不同客户端post请求后服务器都很快回复了ACK，但接下来服务器响应客户端请求的内容时出现很大延时，两次均为20s左右，这两次客户端请求的语句完全相同，目前web server访问量还不大就出现这么大的延时，这是非常不正常的，请与应用开发人员联系优化此语句。5. 网络流量可视化监控及异常事件回溯5.1 网络流量可视化监控流量负载监控：XXX骨干业务出口流量主要集中,平均流量持续在20Mbps左右，偶尔也有些突发，大概在50 Mbps左右，可以通过流量回溯，追踪突发的源头，从而判断是否为异常，下图为(2017/11/27-12/01)的流量趋势图。正常时间最高流量约50Mbps，最低流量约15Mbps。如下图：一天流量概要信息（2017/11/29 00:00:00-11/30 00:00:00）：一天流量分布，可以看出流量峰值在中午12点下班后流量会降低一些，如下图:一天产生的总数据为205GB，如下图：从IP流量占比中可以看出，主要流量为单播，如下图：数据包大小分布可以看出，小包流量居多，占到了62%，如下图：小结：监控时间段（2017/11/29 00:00:00-11/30 00:00:00），流量峰值出现在中午,平均流量持续在20Mbps左右，偶尔也有些突发，大概在50 Mbps左右，一天产生的总数据为205GB，主要流量为单播，小包流量居多，占到了62%。网络流量实时可视化监控：通过对数据包进行7层的深度检查，我们可以掌握网络实时监控状态：1） 流量负载及趋势变化：流量大小、数据包速率及TCP连接等健康指标；2） TOP 网段监控：掌握是哪些部门、各网点在访问系统状况；3） TOP应用监控：掌握哪些业务系统使用频率高、是否存在非业务流量；4） TOP主机：掌握哪些用户流量最大，及时发现异常客户端；5） 实时预警：及时掌握网络突发、攻击、网络及应用时延下降、应用访问失败等异常状况：这些统计数据及通信数据包也会被记录在回溯分析系统中，这样对于过去发生的异常事件，我们也可以通过回溯挖掘分析。5.2 异常事件一：流量突发分析突发流量回溯：2017/11/28号 14:10-14:50时间段出现一次流量突发，回溯到该时间段发现，突发持续了四十分钟左右，流量峰值达到100Mbps, 主要应用为“未知TCP应用”，总字节数大约为10.86GB，主要IP地址为XX.XX.34.41和XX.XX.70.8414:10-14:50未知TCP应用产生13GB数据，如下图：查看IP会话发现是XX.XX.34.41向XX.XX.70.84发送了9GB数据，如下图：查看TCP会话发现XX.XX.70.84采用随机端口与XX.XX.34.41的8010和8011端口通信，如下图：通过数据流重组复现整个交易过程，如下图：再对其数据流进行解码，如下图：小结：2017/11/28号 14:10-14:50时间段出现一次流量突发，突发持续了四十分钟左右，流量峰值达到100Mbps, 主要应用为“未知TCP应用”， TCP会话XX.XX.70.84采用随机端口与XX.XX.34.41的8010和8011端口通信，主要XX.XX.34.41向XX.XX.70.84发送了9GB数据。5.3 异常事件二：异常TCP连接行为TCP建立连接时，客户端会发一个“同步请求包”，服务器回应一个“同步确认包”，正常情况下，这两个参数应该是一致。 测试期间2017/12/03 09:50-10:40发现XX.XX.34.56发送了568661个TCP同步包但只收到303个TCP同步确认包，相差很大，如下图：位于广州移动IP:XX.XX.34.56主要向位于美国IP: 43和位于荷兰IP：89发送TCP同步包，如下图： 查看TCP会话，发现IP：XX.XX.34.56在一分钟内与IP：43进行了2972次会话，如下图：进一步分析，发现XX.XX.34.56采用随机端口尝试连接43的8090端口，并且这些随机端口逐渐增大，非常有规律，如下图：对TCP会话进行数据流重组，查看交易时序图看到都是XX.XX.34.56发送的SYN同步包，但都没有得到回应，如下图：小结：广州移动IP:XX.XX.34.56通过随机端口一直向美国IP: 43的8090端口发起连接请求 ，但都没有得到回应，请确认这种尝试主动外连的行为是否正常。5.4 异常事件三：伪造IP高危DNS请求查看链路警报发现在2017/11/30 00:40:00-03:30:00时间段产生可疑域名警报314455条，如下图：对可疑警报进行回溯分析，发现IP-55一直向XX.XX.33.50发送DNS查询请求，如下图：对XX.XX.33.50进行历史回溯分析：发现11/27 22:00-11/28 08:00、11/29 01:00:-08:00和11/29 23:00-11/30 05:00这些时间段都出现了-55向XX.XX.33.50进行DNS查询的现象，如下图：进行数据解码，可以看到DNS查询负载35字节，内容为 k9s.ru，如下图：查看DNS请求日志，如下图：小结：XX.XX.123.1-XX.XX.123.255一直向XX.XX.33.50发送DNS查询请求，IP地址这样规律增大是有问题的，极有可能是伪造的，这种行为是危险的，建议查明原因排除潜在危险。5.5 异常事件四：ICMP攻击选中时间段2017/12/01 16:34:40 16:34:53，发现有11条警报日志产生，选中相应警报日志进行回溯分析，如下图：ICMP流量占比很大，对ICMP应用进行回溯分析，选中时间段2017/12/01 16:34:35-16:34:49，发现这个时间段IP：XX.XX.32.182流量明显大于其他IP，如下图：对XX.XX.32.182进行单独回溯分析，选中时间段2017/11/30 06:00-18:00，这一时间段ICMP共产生了3.44GB数据，如下图：选中时间段2017/11/30 14:50-15:10，二十分钟产生了101MB的ICMP流量，如下图：对这101MB的ICMP流量进行深入挖掘分析，发现XX.XX.32.182向大量公网地址发送ICMP包，每个ICMP包大小在500字节，远大于普通的ICMP包，如下图： 查看矩阵试图，得知XX.XX.32.182二十分钟向496个公网IP发送了195830个数据包共101MB，均为ICMP包，XX.XX.32.182疯狂向大量随机公网IP发送ICMP包，这是非常不正常的，极有可能是被病毒感染。小结：XX.XX.32.182向大量公网地址发送ICMP包，2017/11/30 14:50-15:10，二十分钟向496个公网IP发送了195830个数据包共101MB，均为ICMP包，包大小在500字节远大于普通ICMP数据包，XX.XX.32.182疯狂向随机大量公网IP发送ICMP包，2017/11/30 06:00-18:00这一时间段ICMP共产生了3.44GB数据这是非常不正常的，极有可能是被病毒感染。建议尽快对XX.XX.32.182进行病毒查杀。5.6 异常事件五：DNS查询异常查看监控时间段2017/12/04 22:54-12/05 00:14:00，发现DNS应用产生163MB数据，流量占比很大，这是不正常的对DNS应用进行回溯分析，可以看到产生流量最大的IP地址是XX.XX.34.56，对XX.XX.34.56进行单独回溯分析，选中时间段2017/12/04 22:37-23:32看到DNS应用产生流量最多为109MB对这109MB的DNS数据进行数据包解码分析，发现XX.XX.34.56请求的DNS域名均为www.nspod.tk和www.amason.ff，对流量第二多的未知TCP应用进行分析查看TCP会话，XX.XX.34.56一直在请求网址www.amason.cf和www.nspod.tk，都是只发了两个数据包，没有收到回包查看TCP交易时序图，XX.XX.34.56向94（www.amason.cf）发送SYN包但都被RST掉小结：选中各个时段进行分析发现XX.XX.34.56主要流量都是由DNS应用产生，XX.XX.34.56一直在请求域名www.amason.cf和www.nspod.tk，产生了大量无用的DNS查询包和SYN包占用网络带宽，请确认这种通讯行为是否正常6. 告警设置6.1 服务器与网络时延预警我们可以根据三次握手响应时延、丢包问题去发现网络问题如“客户端网络时延异常”预警：“三次握手平均时延超过100毫秒”同时“三次握手平均客户端时延超过100毫秒”；出发该预警的客户端，肯定是网络质量除了问题服务器“响应质量下降”预警：通过这段时间的监控我们了解到“WEB服务器”平均响应时延不超过200ms，那么如果“TCP交易数量”超过10000pps、“平均响应时延”超过1000毫秒，则说明由于业务量上升，服务器的质量严重下降：随着我们对业务系统的深入了解，我们可以设置更多这样有针对性的预警，及时发现业务体验的变化，快速的定制应对的策略。6.2 流量突发预警测试的过程中，我们梳理出生产业务流量，如果某天出现“未知TCP流量”突发，很可能就是网络异常：6.3 主机扫描预警设置目的：发现针对网段特定服务端口的主机扫描行为，这种行为会短时间内向某网段所有IP的特定TCP端口发起连接请求，一般每秒会超过100个SYN包，但不会持续很长时间。设置方法：这是一个高级警报设置，类型为“任意应用警报”，触发条件为“每秒数据包数=100”AND“平均包长=50”AND“接收TCP同步确认包=50”AND“发送TCP同步确认包15”），触发时间为1秒。补充说明：这个警报和“主机扫描”警报配合可以快速定位发起主机扫描的IP地址，同一时间发生主机扫描和TCP通信异常警报，基本可以判断是TCP通信异常的IP地址发起的主机扫描；一些P2P应用有时会触发这个警报。6.5 CIFS蠕虫攻击告警设置目的：网络中存在利用CIFS漏洞传播的蠕虫时，利用此警报及时发现。设置方法：简单警报设置，类型为“单个应用警