高中作文网站,Wordpress如何调用搜索框,个人网站做什么资源赚钱,做公司网站的服务费入什么费用前言 如何知道自己所在的企业是否被入侵了#xff1f;是没人来“黑”#xff0c;还是因自身感知能力不足#xff0c;暂时还无法发现#xff1f;其实#xff0c;入侵检测是每一个大型互联网企业都要面对的严峻挑战。价值越高的公司#xff0c;面临入侵的威胁也越大#x… 前言 如何知道自己所在的企业是否被入侵了是没人来“黑”还是因自身感知能力不足暂时还无法发现其实入侵检测是每一个大型互联网企业都要面对的严峻挑战。价值越高的公司面临入侵的威胁也越大即便是Yahoo这样的互联网鼻祖在落幕被收购时仍遭遇全量数据失窃的事情。安全无小事一旦互联网公司被成功“入侵”其后果将不堪想象。 基于“攻防对抗”的考量本文不会提及具体的入侵检测模型、算法和策略那些希望直接照搬“入侵策略”的同学可能会感到失望。但是我们会将一部分运营思路分享出来请各位同行指点如能对后来者起到帮助的作用那就更好了也欢迎大家跟我们交流探讨。 入侵的定义 典型的入侵场景 黑客在很远的地方通过网络远程控制目标的笔记本电脑/手机/服务器/网络设备进而随意地读取目标的隐私数据又或者使用目标系统上的功能包括但不限于使用手机的麦克风监听目标使用摄像头偷窥监控目标使用目标设备的计算能力挖矿使用目标设备的网络能力发动DDoS攻击等等。亦或是破解了一个服务的密码进去查看敏感资料、控制门禁/红绿灯。以上这些都属于经典的入侵场景。 我们可以给入侵下一个定义就是黑客在未经授权的情况下控制、使用我方资源包括但不限于读写数据、执行命令、控制资源等达到各种目的。从广义上讲黑客利用SQL注入漏洞窃取数据或者拿到了目标域名在ISP中的帐号密码以篡改DNS指向一个黑页又或者找到了目标的社交帐号在微博/QQ/邮箱上对虚拟资产进行非授权的控制都属于入侵的范畴。 针对企业的入侵检测 企业入侵检测的范围多数情况下比较狭义一般特指黑客对PC、系统、服务器、网络包括办公网、生产网控制的行为。 黑客对PC、服务器等主机资产的控制最常见的方法是通过Shell去执行指令获得Shell的这个动作叫做GetShell。 比如通过Web服务的上传漏洞拿到WebShell或者利用RCE漏洞直接执行命令/代码RCE环境变相的提供了一个Shell。另外通过某种方式先植入“木马后门”后续直接利用木马集成的SHELL功能对目标远程控制这个也比较典型。 因此入侵检测可以重点关注GetShell这个动作以及GetShell成功之后的恶意行为为了扩大战果黑客多半会利用Shell进行探测、翻找窃取、横向移动攻击其它内部目标这些区别于好人的特性也可以作为重要的特征。 有一些同行包括商业产品喜欢报告GetShell之前的一些“外部扫描、攻击探测和尝试行为”并美其名曰“态势感知”告诉企业有人正在“试图攻击”。在笔者看来实战价值并不大。包括美团在内的很多企业基本上无时无刻都在遭受“不明身份”的攻击知道了有人在“尝试”攻击如果并不能有效地去行动无法有效地对行动进行告警除了耗费心力之外并没有太大的实际价值。 当我们习惯“攻击”是常态之后就会在这样的常态下去解决问题可以使用什么加固策略哪些可以实现常态化的运营如果有什么策略无法常态化运营比如需要很多人加班临时突击守着那这个策略多半在不久之后就会逐渐消逝掉。跟我们做不做这个策略并没有本质上的区别。 类似于SQL注入、XSS等一些不直接GetShell的Web攻击暂时不在狭义的“入侵检测”考虑范围建议可以划入“漏洞”、“威胁感知”等领域另行再做探讨。当然利用SQL注入、XSS等入口进行了GetShell操作的我们仍抓GetShell这个关键点不必在乎漏洞入口在何处。 “入侵”和“内鬼” 与入侵接近的一种场景是“内鬼”。入侵本身是手段GetShell只是起点黑客GetShell的目标是为了之后对资源的控制和数据的窃取。而“内鬼”天然拥有合法的权限可以合法接触敏感资产但是基于工作以外的目的他们对这些资源进行非法的处置包括拷贝副本、转移外泄、篡改数据牟利等。 内鬼的行为不在“入侵检测”的范畴一般从内部风险控制的视角进行管理和审计比如职责分离、双人审计等。也有数据防泄密产品DLP对其进行辅助这里不展开细说。 有时候黑客知道员工A有权限接触目标资产便定向攻击A再利用A的权限把数据窃取走也定性为“入侵”。毕竟A不是主观恶意的“内鬼”。如果不能在黑客攻击A的那一刻捕获或者无法区分黑客控制的A窃取数据和正常员工A的访问数据那这个入侵检测也是失败的。 入侵检测的本质 前文已经讲过入侵就是黑客可以不经过我们的同意来操作我们的资产在手段上并没有任何的限制。那么如何找出入侵行为和合法正常行为的区别将其跟合法行为进行分开就是“入侵发现”。在算法模型上这算是一个标记问题入侵、非入侵。 可惜的是入侵这种动作的“黑”样本特别稀少想通过大量的带标签的数据有监督的训练入侵检测模型找出入侵的规律比较难。因此入侵检测策略开发人员往往需要投入大量的时间去提炼更精准的表达模型或者花更多的精力去构造“类似入侵”的模拟数据。 一个经典的例子是为了检测出WebShell安全从业人员可以去GitHub上搜索一些公开的WebShell样本数量大约不到1000个。而对于机器学习动辄百万级的训练需求这些数据远远不够。况且GitHub上的这些样本集从技术手法上来看有单一技术手法生成的大量类似样本也有一些对抗的手法样本缺失。因此这样的训练试图让AI去通过“大量的样本”掌握WebShell的特征并区分出它们原则上不太可能完美地去实现。 此时针对已知样本做技术分类提炼更精准的表达模型被称为传统的特征工程。而传统的特征工程往往被视为效率低下的重复劳动但效果往往比较稳定毕竟加一个技术特征就可以稳定发现一类WebShell。而构造大量的恶意样本虽然有机器学习、AI等光环加持但在实际环境中往往难以获得成功自动生成的样本很难描述WebShell本来的含义多半描述的是自动生成的算法特征。 另一个方面入侵的区别是看行为本身是否“授权”而授权与否本身是没有任何显著的区分特征的。因此做入侵对抗的时候如果能够通过某种加固将合法的访问收敛到有限的通道并且给该通道做出强有力的区分也就能大大的降低入侵检测的成本。例如对访问来源进行严格的认证无论是自然人还是程序API都要求持有合法票据而派发票据时针对不同情况做多纬度的认证和授权再用IAM针对这些票据记录和监控它们可以访问的范围还能产生更底层的Log做异常访问模型感知。 这个全生命周期的风控模型也是Google的BeyondCorp无边界网络得以实施的前提和基础。 因此入侵检测的主要思路也就有2种 根据黑特征进行模式匹配例如WebShell关键字匹配。根据业务历史行为生成基线模型对入侵行为做异常对比非白既黑如果业务的历史行为不够收敛就用加固的手段对其进行收敛再挑出不合规的小众异常行为。入侵检测与攻击向量 根据目标不同可能暴露给黑客的攻击面会不同黑客可能采用的入侵手法也就完全不同。比如入侵我们的PC/笔记本电脑还有入侵部署在机房/云上的服务器攻击和防御的方法都有挺大的区别。 针对一个明确的“目标”它被访问的渠道可能是有限集被攻击的必经路径也有限。“攻击方法”“目标的攻击面”的组合被称为“攻击向量”。 因此谈入侵检测模型效果时需要先明确攻击向量针对不同的攻击路径采集对应的日志数据才可能做对应的检测模型。比如基于SSH登录后的Shell命令数据集是不能用于检测WebShell的行为。而基于网络流量采集的数据也不可能感知黑客是否在SSH后的Shell环境中执行了什么命令。 基于此如果有企业不提具体的场景就说做好了APT感知模型显然就是在“吹嘘”了。 所以入侵检测得先把各类攻击向量罗列出来每一个细分场景分别采集数据HIDSNIDSWAFRASP应用层日志系统日志PC……再结合公司的实际数据特性作出适应公司实际情况的对应检测模型。不同公司的技术栈、数据规模、暴露的攻击面都会对模型产生重大的影响。比如很多安全工作者特别擅长PHP下的WebShell检测但是到了一个Java系的公司…… 常见的入侵手法与应对 如果对黑客的常见入侵手法理解不足就很难有的放矢有时候甚至会陷入“政治正确”的陷阱里。比如渗透测试团队说我们做了A动作你们竟然没有发现所以你们不行。而实际情况是该场景可能不是一个完备的入侵链条就算不发现该动作对入侵检测效果可能也没有什么影响。每一个攻击向量对公司造成的危害发生的概率如何进行排序解决它耗费的成本和带来的收益如何都需要有专业经验来做支撑与决策。 现在简单介绍一下黑客入侵教程里的经典流程完整过程可以参考杀伤链模型 入侵一个目标之前黑客对该目标可能还不够了解所以第一件事往往是“踩点”也就是搜集信息加深了解。比如黑客需要知道目标有哪些资产域名、IP、服务它们各自的状态如何是否存在已知的漏洞管理他们的人有谁以及如何合法的管理的存在哪些已知的泄漏信息比如社工库里的密码等…… 一旦踩点完成熟练的黑客就会针对各种资产的特性酝酿和逐个验证“攻击向量”的可行性下文列举了常见的攻击方式和防御建议。 高危服务入侵 所有的公共服务都是“高危服务”因为该协议或者实现该协议的开源组件可能存在已知的攻击方法高级的攻击者甚至拥有对应的0day只要你的价值足够高黑客有足够的动力和资源去挖掘那么当你把高危服务开启到互联网面向所有人都打开的那一刻就相当于为黑客打开了“大门”。 比如SSH、RDP这些运维管理相关的服务是设计给管理员用的只要知道密码/秘钥任何人都能登录到服务器端进而完成入侵。而黑客可能通过猜解密码结合社工库的信息泄露、网盘检索或者暴力破解获得凭据。事实上这类攻击由于过于常见黑客早就做成了全自动化的全互联网扫描的蠕虫类工具云上购买的一个主机如果设置了一个弱口令往往在几分钟内就会感染蠕虫病毒就是因为这类自动化的攻击者实在是太多了。 或许你的密码设置得非常强壮但是这并不是你可以把该服务继续暴露在互联网的理由我们应该把这些端口限制好只允许自己的IP或者内部的堡垒主机访问彻底断掉黑客通过它入侵我们的可能。 与此类似的MySQL、Redis、FTP、SMTP、MSSQL、Rsync等等凡是自己用来管理服务器或者数据库、文件的服务都不应该针对互联网无限制的开放。否则蠕虫化的攻击工具会在短短几分钟内攻破我们的服务甚至直接加密我们的数据甚至要求我们支付比特币进行敲诈勒索。 还有一些高危服务存在RCE漏洞远程命令执行只要端口开放黑客就能利用现成的exploit直接GetShell完成入侵。 防御建议 针对每一个高危服务做入侵检测的成本较高因为高危服务的具体所指非常的多不一定存在通用的特征。所以通过加固方式收敛攻击入口性价比更高。禁止所有高危端口对互联网开放可能这样能够减少90%以上的入侵概率。 Web入侵 随着高危端口的加固黑客知识库里的攻击手法很多都会失效了。但是Web服务是现代互联网公司的主要服务形式不可能都关掉。于是基于PHP、Java、ASP、ASP.NET、Node、C写的CGI等等动态的Web服务漏洞就变成了黑客入侵的最主要入口。 比如利用上传功能直接上传一个WebShell利用文件包含功能直接引用执行一个远程的WebShell或者代码然后利用代码执行的功能直接当作Shell的入口执行任意命令解析一些图片、视频的服务上传一个恶意的样本触发解析库的漏洞…… Web服务下的应用安全是一个专门的领域道哥还专门写了本《白帽子讲Web安全》具体的攻防场景和对抗已经发展得非常成熟了。当然由于它们都是由Web服务做为入口所以入侵行为也会存在某种意义上的共性。相对而言我们比较容易能够找到黑客GetShell和正常业务行为的一些区别。 针对Web服务的入侵痕迹检测可以考虑采集WAF日志、Access Log、Auditd记录的系统调用或者Shell指令以及网络层面Response相关的数据提炼出被攻击成功的特征建议我们将主要的精力放在这些方面。 0day入侵 通过泄漏的工具包来看早些年NSA是拥有直接攻击Apache、Nginx这些服务的0day武器的。这意味着对手很可能完全不用在乎我们的代码和服务写成什么样拿0day一打神不知鬼不觉就GetShell了。 但是对于入侵检测而言这并不可怕因为无论对手利用什么漏洞当入口它所使用的Shellcode和之后的行为本身依然有共性。Apache存在0day漏洞被攻击还是一个PHP页面存在低级的代码漏洞被利用从入侵的行为上来看说不定是完全一样的入侵检测模型还可以通用。 所以把精力聚焦在有黑客GetShell入口和之后的行为上可能比关注漏洞入口更有价值。当然具体的漏洞利用还是要实际跟进然后验证其行为是否符合预期。 办公终端入侵 绝大多数APT报告里黑客是先对人办公终端下手比如发个邮件哄骗我们打开后控制我们的PC再进行长期的观察/翻阅拿到我们的合法凭据后再到内网漫游。所以这些报告多数集中在描述黑客用的木马行为以及家族代码相似度上。而反APT的产品、解决方案多数也是在办公终端的系统调用层面用类似的方法检验“免杀木马”的行为。 因此EDR类的产品邮件安全网关办公网出口的行为审计APT产品的沙箱等联合起来可以采集到对应的数据并作出相似的入侵检测感知模型。而最重要的一点是黑客喜欢关注内部的重要基础设施包括但不限于AD域控、邮件服务器、密码管理系统、权限管理系统等一旦拿下就相当于成为了内网的“上帝”可以为所欲为。所以对公司来说重要基础设施要有针对性的攻防加固讨论微软针对AD的攻防甚至还发过专门的加固白皮书。 入侵检测基本原则 不能把每一条告警都彻底跟进的模型等同于无效模型。入侵发生后再辩解之前其实有告警只是太多了没跟过来/没查彻底这是“马后炮”等同于不具备发现能力所以对于日均告警成千上万的产品安全运营人员往往表示很无奈。 我们必须屏蔽一些重复发生的相似告警以集中精力把每一个告警都闭环掉。这会产生白名单也就是漏报因此模型的漏报是不可避免的。 由于任何模型都会存在漏报所以我们必须在多个纬度上做多个模型形成关联和纵深。假设WebShell静态文本分析被黑客变形绕过了在RASP运行时环境的恶意调用还可以进行监控这样可以选择接受单个模型的漏报但在整体上仍然具备发现能力。 既然每一个单一场景的模型都有误报漏报我们做什么场景不做什么场景就需要考虑“性价比”。比如某些变形的WebShell可以写成跟业务代码非常相似人的肉眼几乎无法识别再追求一定要在文本分析上进行对抗就是性价比很差的决策。如果通过RASP的检测方案其性价比更高一些也更具可行性一些。 我们不太容易知道黑客所有的攻击手法也不太可能针对每一种手法都建设策略考虑到资源总是稀缺的。所以针对重点业务需要可以通过加固的方式还需要常态化监控加固的有效性让黑客能攻击的路径极度收敛仅在关键环节进行对抗。起码能针对核心业务具备兜底的保护能力。 基于上述几个原则我们可以知道一个事实或许我们永远不可能在单点上做到100%发现入侵但是我们可以通过一些组合方式让攻击者很难绕过所有的点。 当老板或者蓝军挑战某个单点的检测能力有缺失时如果为了“政治正确”在这个单点上进行无止境的投入试图把单点做到100%能发现的能力很多时候可能只是在试图制造一个“永动机”纯粹浪费人力、资源而不产生实际的收益。将节省下来的资源高性价比的布置更多的纵深防御链条效果显然会更好。 入侵检测产品的主流形态 入侵检测终究是要基于数据去建模比如针对WebShell的检测首先要识别Web目录再对Web目录下的文件进行文本分析这需要做一个采集器。基于Shell命令的入侵检测模型需要获取所有Shell命令这可能要Hook系统调用或者劫持Shell。基于网络IP信誉、流量payload进行检测或者基于邮件网关对内容的检查可能要植入网络边界中对流量进行旁路采集。 也有一些集大成者基于多个Sensor将各方日志进行采集后汇总在一个SOC或者SIEM再交由大数据平台进行综合分析。因此业界的入侵检测相关的产品大致上就分成了以下的形态 主机Agent类黑客攻击了主机后在主机上进行的动作可能会产生日志、进程、命令、网络等痕迹那么在主机上部署一个采集器也内含一部分检测规则就叫做基于主机的入侵检测系统简称HIDS。 典型的产品OSSEC、青藤云、安骑士、安全狗Google最近也发布了一个Alpha版本的类似产品 Cloud Security Command Center。当然一些APT厂商往往也有在主机上的Sensor/Agent比如FireEye等。网络检测类由于多数攻击向量是会通过网络对目标投放一些payload或者控制目标的协议本身具备强特征因此在网络层面具备识别的优势。 典型的产品Snort到商业的各种NIDS/NIPS对应到APT级别则还有类似于FireEye的NX之类的产品。日志集中存储分析类这一类产品允许主机、网络设备、应用都输出各自的日志集中到一个统一的后台在这个后台对各类日志进行综合的分析判断是否可以关联的把一个入侵行为的多个路径刻画出来。例如A主机的的Web访问日志里显示遭到了扫描和攻击尝试继而主机层面多了一个陌生的进程和网络连接最后A主机对内网其它主机进行了横向渗透尝试。 典型的产品LogRhythm、Splunk等SIEM类产品。APT沙箱沙箱类产品更接近于一个云端版的高级杀毒软件通过模拟执行观测行为以对抗未知样本弱特征的特点。只不过它需要一个模拟运行的过程性能开销较大早期被认为是“性价比不高”的解决方案但由于恶意文件在行为上的隐藏要难于特征上的对抗因此现在也成为了APT产品的核心组件。通过网络流量、终端采集、服务器可疑样本提取、邮件附件提炼等拿到的未知样本都可以提交到沙箱里跑一下行为判断是否恶意。 典型产品FireEye、Palo Alto、Symantec、微步。终端入侵检测产品移动端目前还没有实际的产品也不太有必要。PC端首先必备的是杀毒软件如果能够检测到恶意程序一定程度上能够避免入侵。但是如果碰到免杀的高级0day和木马杀毒软件可能会被绕过。借鉴服务器上HIDS的思路也诞生了EDR的概念主机除了有本地逻辑之外更重要的是会采集更多的数据到后端在后端进行综合分析和联动。也有人说下一代杀毒软件里都会带上EDR的能力只不过目前销售还是分开在卖。 典型产品杀毒软件有Bit9、SEP、赛门铁克、卡巴斯基、McAfee EDR产品不枚举了腾讯的iOA、阿里的阿里郎一定程度上都是可以充当类似的角色入侵检测效果评价指标 首先主动发现的入侵案例/所有入侵 主动发现率。这个指标一定是最直观的。比较麻烦的是分母很多真实发生的入侵如果外部不反馈我们又没检测到它就不会出现在分母里所以有效发现率总是虚高的谁能保证当前所有的入侵都发现了呢但是实际上只要入侵次数足够多不管是SRC收到的情报还是“暗网”上报出来的一个大新闻把客观上已经知悉的入侵列入分母总还是能计算出一个主动发现率的。 另外真实的入侵其实是一个低频行为大型的互联网企业如果一年到头成百上千的被入侵肯定也不正常。因此如果很久没出现真实入侵案例这个指标长期不变化也无法刻画入侵检测能力是否在提升。 所以我们一般还会引入两个指标来观测 蓝军对抗主动发现率已知场景覆盖率蓝军主动高频对抗和演习可以弥补真实入侵事件低频的不足但是由于蓝军掌握的攻击手法往往也是有限的他们多次演习后手法和场景可能会被罗列完毕。假设某一个场景建设方尚未补齐能力蓝军同样的姿势演习100遍增加100个未发现的演习案例对建设方而言并没有更多的帮助。所以把已知攻击手法的建成覆盖率拿出来也是一个比较好的评价指标。 入侵检测团队把精力聚焦在已知攻击手法的优先级评估和快速覆盖上对建设到什么程度是满足需要的要有自己的专业判断参考入侵检测原则里的“性价比”原则。 而宣布建成了一个场景的入侵发现能力是要有基本的验收原则的 该场景日均工单 X单峰值 Y单当前所有场景日平均XX峰值 YY超出该指标的策略不予接收因为过多的告警会导致有效信息被淹没反而导致此前具备的能力被干扰不如视为该场景尚未具备对抗能力。同一个事件只告警首次多次出现自动聚合。具备误报自学习能力。告警具备可读性有清晰的风险阐述、关键信息、处理指引、辅助信息或者索引便于定性不鼓励Key-Value模式的告警建议使用自然语言描述核心逻辑和响应流程。有清晰的说明文档自测报告就像交付了一个研发产品产品文档和自测过程是质量的保障。有蓝军针对该场景实战验收报告。不建议调用微信、短信等接口发告警告警和事件的区别是事件可以闭环告警只是提醒统一的告警事件框架可以有效的管理事件确保闭环还能提供长期的基础运营数据比如止损效率、误报量/率。策略人员的文档应当说明当前模型对哪些情况具备感知能力哪些前提下会无法告警考验一个人对该场景和自己模型的理解能力。通过前述判断可以对策略的成熟度形成自评分0-100自由大致估算。单个场景往往很难达到100分但那并没有关系因为从80分提升到100分的边际成本可能变的很高。不建议追求极致而是全盘审视是否快速投入到下一个场景中去。 如果某个不到满分的场景经常出现真实对抗又没有交叉的其它策略进行弥补那自评结论可能需要重审并提高验收的标准。至少解决工作中实际遇到的Case要优先考虑。 影响入侵检测的关键要素 讨论影响入侵检测的要素时我们可以简单看看曾经发生过哪些错误导致防守方不能主动发现入侵 依赖的数据丢失比如HIDS在当事机器上没部署安装/Agent挂了/数据上报过程丢失了/Bug了或者后台传输链条中丢失数据。策略脚本Bug没启动事实上我们已经失去了这个策略感知能力了。还没建设对应的策略很多时候入侵发生了才发现这个场景我们还没来得及建设对应的策略。策略的灵敏度/成熟度不够比如扫描的阈值没达到WebShell用了变形的对抗手法。模型依赖的部分基础数据错误做出了错误的判断。成功告警了但是负责应急同学错误的判断/没有跟进/辅助信息不足以定性没有行动起来。所以实际上要让一个入侵事件被捕获我们需要入侵检测系统长时间、高质量、高可用的运行。这是一件非常专业的工作超出了绝大多数安全工程师能力和意愿的范畴。所以建议指派专门的运营人员对以下目标负责 数据采集的完整性全链路的对账。每一个策略时刻工作正常自动化拨测监控。基础数据的准确性。工单运营支撑平台及追溯辅助工具的便捷性。可能有些同学会想影响入侵检测的关键要素难道不是模型的有效性么怎么全是这些乱七八糟的东西 实际上大型互联网企业的入侵检测系统日均数据量可能到达数百T甚至更多。涉及到数十个业务模块成百上千台机器。从数字规模上来说不亚于一些中小型企业的整个数据中心。这样复杂的一个系统要长期维持在高可用标准本身就需要有SRE、QA等辅助角色的专业化支持。如果仅依靠个别安全工程师很难让其研究安全攻防的时候又兼顾到基础数据质量、服务的可用性和稳定性、发布时候的变更规范性、各类运营指标和运维故障的及时响应。最终的结果就是能力范围内可以发现的入侵总是有各种意外“恰好”发现不了。 所以笔者认为以多数安全团队运营质量之差其实根本轮不到拼策略技术。当然一旦有资源投入去跟进这些辅助工作之后入侵检测就真的需要拼策略了。 此时攻击手法有那么多凭什么先选择这个场景建设凭什么认为建设到某程度就足够满足当下的需要了凭什么选择发现某些样本而放弃另一些样本的对抗 这些看似主观性的东西非常考验专业判断力。而且在领导面前很容易背上“责任心不足”的帽子比如为困难找借口而不是为目标找方法这个手法黑客攻击了好多次凭什么不解决那个手法凭什么说在视野范围内但是要明年再解决 如何发现APT 所谓APT就是高级持续威胁。既然是高级的就意味着木马很大可能是免杀的不能靠杀毒软件或者普通的特征发现利用的漏洞也是高级的加固到牙齿可能也挡不住敌人进来的步伐攻击手法同样很高级攻击场景可能我们都没有见过。 所以实际上APT的意思就约等于同于不能被发现的入侵。然而业界总还有APT检测产品解决方案的厂商在混饭吃他们是怎么做的呢 木马免杀的他们用沙箱人工分析哪怕效率低一些还是试图做出定性并快速的把IOC威胁情报同步给其它客户发现1例全球客户都具备同样的感知能力。流量加密变形对抗的他们用异常检测的模型把一些不认识的可疑的IP关系、payload给识别出来。当然识别出来之后也要运营人员跟进得仔细才能定性。攻击手法高级的他们还是会假定黑客就用鱼叉、水坑之类的已知手法去执行然后在邮箱附件、PC终端等环节采集日志对用户行为进行分析UEBA试图寻找出用户异于平常的动作。那么我们呢笔者也没有什么好的办法可以发现传说中的“免杀”的木马但是我们可以针对已知的黑客攻击框架比如Metasploit、Cobalt Strike生成的样本、行为进行一些特征的提取。我们可以假设已经有黑客控制了某一台机器但是它试图进行横向扩散的时候我们有一些模型可以识别这个主机的横向移动行为。 笔者认为世界上不存在100%能发现APT的方法。但是我们可以等待实施APT的团队犯错只要我们的纵深足够的多信息足够不对称想要完全不触碰我们所有的铃铛绝对存在一定的困难。 甚至攻击者如果需要小心翼翼的避开所有的检测逻辑可能也会给对手一种心理上的震慑这种震慑可能会延缓对手接近目标的速度拉长时间。而在这个时间里只要他犯错就轮到我们出场了。 前面所有的高标准包括高覆盖、低误报强制每一个告警跟进到底“掘地三尺”的态度都是在等待这一刻。抓到一个值得敬佩的对手那种成就感还是很值得回味的。 所以希望所有从事入侵检测的安全同行们都能坚持住即使听过无数次“狼来了”下一次看到告警依然可以用最高的敬畏心去迎接对手告警虐我千百遍我待告警如初恋。 AI在入侵检测领域的正确姿势 最近这两年如果不谈AI的话貌似故事就不会完整。只不过随着AI概念的火爆很多人已经把传统的数据挖掘、统计分析等思想比如分类、预测、聚类、关联之类的算法都一律套在AI的帽子里。 其实AI是一种现代的方法在很多地方有非常实际的产出了。以WebShell的文本分析为例我们可能需要花很长很长的时间才能把上千个样本里隐含的几十种样本技术类型拆分开又花更长的时间去一一建设模型是的在这样的场景下特征工程真的是一个需要更长时间的工作。 而使用AI做好数据打标的工作训练、调参很快就能拿到一个实验室环境不那么过拟合的模型出来迅速投产到生产环境上。熟练一点可能1-2个月就能做完了。 在这种场景下AI这种现代的方法的确能极大地提高效率。但问题是前文也提到过了黑客的攻击黑样本、WebShell的样本往往极其稀缺它不可能是完备的能够描述黑客入侵的完整特征的。因此AI产出的结果无论是误报率还是漏报率都会受训练方法和输入样本的影响较大我们可以借助AI但绝对不能完全交给AI。 安全领域一个比较常见的现象是将场景转变成标记问题要难过于通过数学模型把标记的解给求出来。此时往往需要安全专家先行算法专家再跟上而不能直接让算法专家“孤军奋战”。 针对一个具体的攻击场景怎么样采集对应的入侵数据思考这个入侵动作和正常行为的区别这个特征的提取过程往往决定了模型最终的效果。特征决定了效果的上限而算法模型只能决定了有多接近这个上限。 此前笔者曾见过一个案例AI团队产出了一个实验室环境效果极佳误报率达到1/1000000的WebShell模型但是投放到生产环境里初期日均告警6000单完全无法运营同时还存在不少漏报的情况。这些情况随着安全团队和AI工程师共同的努力后来逐渐地解决。但是并未能成功的取代原有的特征工程模型。 目前业界有许多产品、文章在实践AI但遗憾的是这些文章和产品大多“浅尝辄止”没有在真实的环境中实践运营效果。一旦我们用前面的标准去要求它就会发现AI虽然是个好东西但是绝对只是个“半成品”。真正的运营往往需要传统的特征工程和AI并行也需要持续地进行迭代。 未来必然是AI的天下但是有多少智能前面可能就要铺垫多少人工。愿与同行们一起在这个路上继续探索下去多多交流分享。 关于美团安全 美团安全部的大多数核心开发人员拥有多年互联网以及安全领域实践经验很多同学参与过大型互联网公司的安全体系建设其中也不乏全球化安全运营人才具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”有受邀在Black Hat等国际顶级会议发言的讲者当然还有很多漂亮的运营妹子。 目前美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系这套体系构建于零信任架构之上横跨多种云基础设施包括网络层、虚拟化/容器层、Server 软件层内核态/用户态、语言虚拟机层(JVM/JS V8)、Web应用层、数据访问层等并能够基于大数据机器学习技术构建全自动的安全事件感知系统努力打造成业界最前沿的内置式安全架构和纵深防御体系。 随着美团的高速发展业务复杂度不断提升安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地同时为更多的安全从业者提供一个广阔的发展平台并提供更多在安全新兴领域不断探索的机会。 安利个小广告 美团安全部正在招募Web二进制攻防、后台系统开发、机器学习算法等各路小伙伴。如果你想加入我们欢迎简历请发至邮箱zhaoyan17meituan.com 具体职位信息可参考这里 美团安全应急响应中心MTSRC主页security.meituan.com
