MAC设备能通过iCloud远程控制？为什么机器学习解决网络安全问题总是失败？应用接口服务如何部署在DMZ? | 总第122周

渗透技巧 2年前 (2021) admin

679 0 0

‍‍

0x1 本周话题TOP3

话题1：大家有关注这个问题不，公司给员工配置的办公电脑，比如MAC电脑，员工可能会在这个电脑上登录自己的iCloud账号，如果人员离职后，设备交还到IT部门后，IT人员直接重装系统，该员工是可以通过iCloud远程擦除这台设备的数据的（在iCloud云端，该设备认为是属于这个人的）？

A1:我们遇到了，咨询了苹果官方客服，在交付IT部门后，需要按照官方的一个操作流程，解绑iCloud账号，设备就不会被这个iCloud用户控制。这是我们之前没有关注到的一个领域，说明在iCloud，他才不知道你归属谁，重装系统依然被iCloud管，然后也能同步走，是一个风险。

A2:我们ops对于mac归还设备处理是交还给IT部门后，按照苹果官方的设备解绑操作步骤解绑，然后就可以重置系统了。官网有解绑操作的步骤，即注销apple id。

A3:考虑上一套企业级的mdm吧，icloud都把公司数据备份到个人云端了，不应该只看眼前IT的困难。解绑只是关闭了“查找我的设备”及远程擦除一系列问题，没解决个人iCloud的问题，员工在别的设备登录iCloud，照样可以把数据下下来。

mac电脑这个特点的风险更是在数据泄露方面，之前还真没关注过。有些公司禁用个人云盘，这个不好落地吧。这个要看决心和想好提供跟云盘一样的解决方案，不好一刀切。

禁止员工用云盘，那自己就要提供接受外来大文件的解决方案，还有一个取巧的方法，留一个你管的住的云盘口子，其他封了。比如几年前百度云盘的上传链接和下载链接是不一样的，qq中转站下载是不需要登录的，把上传接口封了，把qq登录封了，就能达到管控的目的，又不影响下载，测完再监控个上行流量就够了。最近几年没跟进过还有没有效，三网隔离一了百了。

话题2：为什么机器学习解决网络安全问题总是失败：不合理的评估指标

相关链接：

https://toooold.com/2021/11/13/why_ml_fails_security_evaluation_cn.html?continueFlag=856e1f39aba8670f5d9aef324fb00f67

A1：没有正确的目标就没有正确的指标，习惯性都是抄论文。安全就是要找出异常，那首先要知道正常是什么？谁来定义正常？安全是保障业务为目标的，所以正常的定义应该由业务定，业务定了，让业务把异常的给安全，捞出真正的异常，再回吐业务，该是这个逻辑吧。所以评价是由业务来评价。安全到底捞出的异常有没有价值，捞出确认的到底占比是多少，准确率、召回率都得靠业务来定指标计算方式吧。

A2:文章重点强调了一点：不要混淆目标和指标。偏离目标的指标设计，会导致无谓的成本损耗（人力投入、人才流失）。不过有时候也是悖论，需要有试错的过程。

推开来看，不仅是网络安全机器学习，研发效能也是一样。在度量时，都涉及到大量的指标，如果找不到平衡点，很可能导致“面向指标编程”，人类在这方面的智慧无比内卷。

无论该模型的优化目标是否正确合理，聪明的数据科学家可以将建模工作做的很出色，而脱离了合理的指标，优化的越好带来的错误就越多，其最终带来的商业损失和工作的挫败感需要更多的代价来平复。

A3:本文作者甚至观察到，某些安全团队一方面排斥数据模型的检测结果，一方面从数据模型的结果提取规则加入自己的检测库，通过提高分母的办法让数据科学团队的独立检出率保持在较低水平。安全团队口中的“机器学习没有用”和数据科学团队提出的“安全团队又当运动员又当裁判员”等观点均来源于此，这些无意义的内部竞争消耗了多个团队的精力和信任，最终造成了公司层面的人员流失和经济损失。独立检出这一指标带来了割裂团队阻止合作的诅咒。

MAC设备能通过iCloud远程控制？为什么机器学习解决网络安全问题总是失败？应用接口服务如何部署在DMZ? | 总第122周

A4:安全工作，个人理解还是需要扎扎实实，在于体系和日日夜夜滴水之功。实际我一直有疑问的就是，现在提用机器学习做检测，算法的可解释性到底咋样？

验证的成本很高。误报率没见过低的，尤其是基于流量的。所以回到本质，机器学习到底是个啥，感觉现在机器学习更多被用来做一些统计维度的检测。

A5:我觉得写的挺好啊，作者强调的是，失败的原因是评估指标不合理。误报率低，本身就是对模型不理解。初步的机器学习，偏统计数据挖掘。

例如某 WAF 产品以自己每天为客户防御多少亿次攻击为指标，而不是以产品的易用易部署、低成本高吞吐、低延迟等更能反映其商业目标的指标。这样的“防御多少亿次攻击”的“想当然”的指标看似容易量化，但其荒谬程度就好比某消防站以扑灭多少次火灾为绩效考核标准一样，失去目标的指标对商业价值没有意义。

A6:万一误报下的准确率有多高，这才是应该问的。误报率—实际不该作为机器学习的指标的，那个是结果，而且是拆分的细分结果项。指标是要分层的，就跟你的目标是分层的。

我感觉大家还是产品思维，机器学习只是个底层的模块，为啥要跟整个产品或者项目的评价挂钩这么深，又不是做一个机器学习产品。底层的模块，底层处理的结果，可以按通用的来看，数据和模型的分层做好了，逻辑上是需要对机器学习的结果再做一层处理的。

A7:刚才也想说，用分层的方式，更能合理使用各类数据，而不是直接丢进去跑算法，实际再检测某些输出某些指标之前，对数据先做预处理和过滤会比较好。

举个例子，一个tcpdump出来上百维的东西数据，预处理之后保留主要特征也至少50个特征。就是50维的空间。这个时候人工上吧，分类检测，就两分类。机器学习就像一把刀只是一个工具，本意是让数据说话，让数据揭示事实。但执刀人出发点或者目标有问题那数据就是用来作秀的。

A8：这里问题也有可能是搞算法理解的安全业务场景，和搞攻防对抗、入侵检测的同学理解的业务场景指标存在偏差。就如同很难找到懂业务的大数据专家一样，也很难奢求数据科学家懂业务懂安全。

或者也可以认为是内部协作机制的问题。好的协作，应该不需要要求协作方懂自己的业务的，用其更中立的数据挖掘结果，而不是影响他让他带目的性的去挖掘。这跟咨询公司写报告一样，同样的数据，咨询公司很多老江湖，都是先预设问题，再从数据里面找能支持问题和结论的数据。

最起码在组织架构上目标应该是一致的，而不是互相拆台，那结果必然不尽如人意。

从大家的评论中，群友们普遍认为这篇文章说了一些通用的误区，而不是针对网络安全领域的：

一个是数据科学家自嗨，类似大专院校科研的产研用脱节问题；
二是目标导向下，产生的指标偏差导致的结果偏差，这是屁股决定脑袋，内卷的问题。

话题3：请教个问题，C端用户通过浏览器访问公司A系统的页面，页面的静态资源部署在DMZ区域，但页面里的接口地址又是部署在内网，我们要求开发把接口服务也部署在DMZ，但对方说无法拆分，这种问题有啥解决思路么?

A1：这个问题我们也遇到的，目前互联网应用越来越多，原来没有互联网需求的内网服务器，现在也有出向或者入向的互联网访问需求了。全都拆分到DMZ区不现实，Nginx直接转发貌似把流量直接引入内网了，NG漏洞也不少，要是被搞定了就悲剧了。跟开发那边PK好几次了，希望他们DMZ的服务器上，用API的方式请求内部服务，但被拒绝了，说改造很麻烦。

A2:堵不住的，应用微服务化之后这种场景更甚，应该在早期将这些需求引导到一个统一的api网关上去实现，否则随着业务增长这些口子会越来越多，越来越分散。自己建的系统，一开始搞统一的API网关当然可以，一堆老系统不好搞。

好多外购系统都有这个问题，不能分离部署，只能往外移了。这已经是许多公司，特别互联网公司的常态了吧，这种场景会越来越多，传统的边界概念会越来越模糊，关键这些口子要做要好鉴权和细分授权，有了统一网关你后续可以做管控。

A3:还有个疑问，比如A系统页面需要先登录才可以使用，用户在浏览器输入完用户名/密码，点提交，这个请求由前端的代码(部署在192.168.1.1这台服务器上)，提交给后端的代码(部署在192.168.1.2这台服务器上)，然后后端代码去查询数据库(部署在192.168.1.3这台服务器上），我理解用户到1.1(获取前端资源)，1.1请求1.2(前端调后端接口），1.2请求1.3(后端查询或写入数据库)，这应该是独立的三段请求，但我们架构跟我说用户点了提交之后，是用户直接调用后端接口1.2去请求数据库，前端页面是不处理请求逻辑的，是这样吗？

A4:那是因为web容器没有拆分， 1.2(api -> controller -> service -> db)，按你的描述就是代码在一个web容器，如tomcat。安全的做法，就是dmz不用nginx反向代理：user –》 dmz web容器，http请求卸载，校验参数，协议转换 –》 tcp 到核心网应用服务器（比如grpc、dubbo）。对于外购，要不就按标准化架构改造，要不就整体迁移到dmz，目的就是http原生请求不要直接打到核心网。