记一次分布式XDR测试的坑点总结

部署篇

1、虚拟化部署：深信服超融合资源时CPU/内存一定要多配！一定要多配！一定要多配！

千万不要顶着XDR部署硬件要求进行借测，很容易出现XDR虚拟机异常挂起。

避坑点：以江淮本次XDR测试为例，借测超融合aServer-R-2105（CPU：2*10核20线程，内存：4*32GB）搭建XDR虚拟机时已经无法满足三台虚拟机同时起机，最终三台物理服务器加配了14*32GB内存条才勉强带起XDR集群+3台靶机环境。

2、虚拟化部署：XDR系统盘、数据盘对存储策略有一定优化要求，此处部署建议优先创建对应的存储策略，在部署虚拟机时系统盘及数据盘选择对应的存储策略。

避坑点：如果先创建虚拟机，再选择存储策略，以长鑫存储当时测试为例，每台虚拟机两块数据盘，每块5TB，转换时间在60分钟以上，耗时耗力。

方案设计篇

测试方案绝对不能够使用售前系统默认拉出来的，如果方案迟迟无法确定下来的话，至少需要售前协助确认终端如何联动及信息上报、网络侧流量如何收集、如何营造安全事件完整故事线、是否需要展示soar和工单能力、soar能力如何展现（联动什么设备、测试什么事件）、GPT是检测大模型还是辅助运营大模型等等。

避坑点：切记如果效果需要展示的很深，比如完整故事线+soar剧本+工单，建议尽量部署有我司的STA+aES+AF，当然客户很关注三方联动能力的，需要产线给个明确的答复，到底能够做到哪一步的安全能力呈现及安全能力联动，不然现场出不来结果，会特别棘手，排查起来很容易感觉到无从下手。

功能测试篇

1、三方数据接入质量确认，如果想要形成安全事件，数据源的接入尤为重要，数据源接入日志必须能够达到有效的3级效果；

2、三方数据接入真实有效，还需要在组件接入一段时间之后近一步确认是否可以满足；

避坑点：安全告警中在“数据源”选项，可以查看客户比较关注的数据源设备是否正常（比如，源目IP级告警名称、引擎等），江淮XDR测试最初“关联分析”中可以看到每天日志接收正常，但是并未解析，导致客户关注的三方的设备的日志无法进一步分析 ；

可通过在“关联分析”中，调整三方设备解析规则为“other”、“ai”等，如果三方产品在支持列表，尽可能解析规则选择对应产品。

3、XDR针对安全事件的形成条件相对比较苛刻，比如某台主机感染病毒并不会定义为安全事件，如果要定义安全事件，那么这台主机的病毒必须要下一步外链成功或者横向扩散的事件存在，所以，如果三方设备接入观察一段时间没有任何安全事件，排查数据的接入解析也没有问题，可以考虑自定义安全事件，如下；

4、XDR租户控制台登录界面，也就是443端口登录界面，不具备自动退出能力；

避坑点：江淮XDR测试时想当然的以为这里可以调整时间，就可以实现控制台倒计时自动退出，最终研发确认8443端口管理平台界面具备退出能力，443端口租户平台界面压根没设计退出能力。

5、很多时候攻击真实有效，并且可以达到攻击效果，但是在XDR安全事件中无法完整展示攻击故事线，甚至攻击只能在“安全告警”菜单栏中展示；

原因：常规的攻击一般多为明文攻击形式，所以在呈现整个故事线的过程中相对会比较完成，但是针对口令暴力破解或者mstsc远程登录等都是加密过程，最终会导致此类事件出现误判。

避坑点：针对加密类的数据传输一定要做好客户预期把控，特别是客户内网业务采用加密证书访问的业务，想要真实侦测到业务系统的交付流量信息时，需要将解密证书导入到STA，进行流量解密。

6、目前XDR测试虽然能够支持很多三方设备对接，但是想要效果呈现最直接，还是建议至少有STA+aES的网端侧流量才能性能完成的故事线，外加攻击机+靶机进行测试用例测试，现实环境中客户为攻击机和靶机提供的多为同一套虚拟化环境，这样最终会导致攻击机对靶机进行攻击时的流量侧，甚至端侧（如不用我司aES）都没有任何数据上传，那么XDR将如同瞎子一样，不会展示任何攻击效果。

避坑点：在搭建攻击机+靶机的环境时，需要注意攻击机到靶机的流量要能够清晰的镜像给STA，测试用例中牵涉到横向渗透，所以最好的方式是靶机和两台攻击机搭建在三个不同的虚拟化环境，并且把虚拟化平台流量镜像至探针STA，不过这种大概率客户不认可，所以aES提出了流量镜像的模式，但是现场测试几乎没有效果。

最佳建议：为了更好的体现测试效果，建议借测三台超融合（资源一定不要卡点、资源一定不要卡点、资源一定不要卡点！！！），然后在里面搭建vSTA+aES，攻击机和靶机既可以安装aES，也可以做流量镜像给STA，那在攻击机跑攻击数据时，基本就没有问题。

7、靶机和攻击机的搭建，建议按照社区上传的“【指导书03】分布式XDR本地靶场环境使用指导书”，但是玉衡靶机系统存在一个问题，URL需要完全按照文档中进行填写，不然就打不开靶机控制台，当时反复删除测试都不行。

避坑点：特别是后面的‘/login/’，一个字符都不能少，少了就打不开靶机控制台。

8、为了形成完整的攻击故事线，售前在制定方案时一般会按照“【指导书03】分布式XDR本地靶场环境使用指导书”中的如下几种测试用例进行测试，特别是2.2.4.2子项中的横向测试用例。

避坑点：如果要测试如上四种样例，手册中的环境验证一定要提前验证，并且确保验证可以通过，不通过可以联系总部何星或者董彬进行支持，因为攻击机一旦对靶机执行了相关攻击流程，XDR便会记录相关安全事件，如果攻击不完整，将会导致呈现出来的事件不具备此类事件名称，如果同一攻击反复打，也会导致事件名称不能按照攻击类型显示，比如2.2.4.2子项打了多次，最终可能显示不出来类似于带有“Shiro”之类的攻击事件，导致无法呈现效果，总部给的答复是建议只攻击一次不要重复攻击，如果实在没有就看攻击故事线和关键节点是否具备相关类似现象即可，为此江淮曾多次搭建靶机和攻击机进行反复测试，调整这个环境很耗费时间。（不知道是否是环境问题，当时做了快照的克隆恢复，导致靶机机业务各种拉不起来，各种不通，所以每次都要重新部署靶机）

9、XDR作为运营平台，客户在测试过程中会出现很多需要解答的问题点，而且在进行测试用例测试时，也会遇到很多不可控的问题，建议至少两名技服一起过去，一人专注于测试用例的测试及问题解决，一人专注于收集客户疑问并拉通交付专家或者解决方案专家进行客户的答疑。

10、XDR平台内部存在K8S和dock容器等技术，所以在服务启动及稳定性方面存在太多不可控因素，如在超融合通过一体机搭建分布式环境，建议硬件调整时，严格按照超融合硬件关机流程执行（比如虚拟机打快照、先关机等等），一旦XDR虚拟机出现多次异常关机等情况，将会导致底层服务各种异常，后端研发需要拉通一大堆不同模块的人员耗时去处理。

团队协作篇

XDR测试过程中，团队协作尤为重要，因为市面上相关资料特别多，有的客户会从网上爬很多资料作为整合测试方案（如江淮），有的客户可能图省事，不提供任何测试建议；以上无论哪种情况，其实对我们XDR测试效果呈现都是不利的，此时，需要技术专家或者售前专家以权威身份给到客户指导性意见，比如客户整合的测试方案是否合理、客户设想的运营平台的功能是否能够满足、竞争对手设计的竞争性测试方案我司该如何规避等。

分布式XDR测试，从技服和效果侧出发，建议超融合虚拟化部署，先内部搭建一套分布式XDR+vSTA+aES+靶机+攻击机，先通过靶机打出来效果，再基于客户的个性化需求进行组件接入测试调优！！！