在越来越关注攻防对抗实战防护能力的今天,在零信任网络被炒的越来越热的今天,我们重新审视按照这些新理念构建的纵深防御体系,结果发现依然问题重重:在堆砌了大量安全产品后依然发现在资产管理、漏洞安全运营到内部隔离等基础安全工作跟不上安全态势的变化。

就拿隔离来说,当攻击者有机会拿到内网一个跳板机,结果发现内网网络基本是畅通的;这两年的攻防对抗演练活动中这个问题的暴露尤为明显,原来奉行的内网基本安全的策略在攻防对抗中被「打」的体无完肤;同时随着内部网络的架构从传统的 IT 架构向虚拟化、混合云和容器化升级变迁,结果发现内部隔离不再是一件容易的事情。为了适应攻防对抗防护的要求、为了满足新的 IT 架构的要求,我们不得不再重新分析和审视隔离的重要性。

一、什么是微隔离

网络隔离并不是新的概念,而微隔离技术(Micro-Segmentation)是 VMware 在应对虚拟化隔离技术时提出来的,但真正让微隔离备受大家关注是从 2016 年起连续 3 年微隔离技术都进入 Gartner 年度安全技术榜单开始。在 2016 年的 Gartner 安全与风险管理峰会上,Gartner 副总裁、知名分析师 Neil MacDonald 提出了微隔离技术的概念。「安全解决方案应当为企业提供流量的可见性和监控。可视化工具可以让安全运维与管理人员了解内部网络信息流动的情况,使得微隔离能够更好地设置策略并协助纠偏。」

  2016年 2017年 2018年 2019年
Gartner历年来安全技术榜单中的云安全   软件定义边界SDP 软件定义边界SDP  
云访问安全代理CASB 云访问安全代理CASB 云访问安全代理CASB 云访问安全代理CASB
微隔离 微隔离 微隔离  
  云工作负载保护平台CWPP    
  容器安全   容器安全
    云安全配置管理CSPM 云安全配置管理CSPM

从微隔离概念和技术诞生以来,对其核心的能力要求是聚焦在东西向流量的隔离上(当然对南北向隔离也能发挥左右),一是有别于防火墙的隔离作用,二是在云计算环境中的真实需求。

微隔离系统工作范围:微隔离顾名思义是细粒度更小的网络隔离技术,能够应对传统环境、虚拟化环境、混合云环境、容器环境下对于东西向流量隔离的需求,重点用于阻止攻击者进入企业数据中心网络内部后的横向平移(或者叫东西向移动)。

微隔离系统的组成:有别于传统防火墙单点边界上的隔离(控制平台和隔离策略执行单元都是耦合在一台设备系统中),微隔离系统的控制中心平台和策略执行单元是分离的,具备分布式和自适应特点:

(1)策略控制中心:是微隔离系统的中心大脑,需要具备以下几个重点能力:

能够可视化展现内部系统之间和业务应用之间的访问关系,让平台使用者能够快速理清内部访问关系;

能够按角色、业务功能等多维度标签对需要隔离的工作负载进行快速分组;

能够灵活的配置工作负载、业务应用之间的隔离策略,策略能够根据工作组和工作负载进行自适应配置和迁移。

(2)策略执行单元:执行流量数据监测和隔离策略的工作单元,可以是虚拟化设备也可以是主机 Agent。

二、为什么需要微隔离

不少人提出来有 VLAN 技术、VxLAN 技术、VPC 技术,为什么还需要微隔离?在回答这个问题之前,我们先来看看这几个技术的定义和作用:

VLAN:即虚拟局域网,是通过以太网协议将一个物理网络空间逻辑划分成几个隔离的局域网,是我们目前做内部不同局域网段的一种常用技术;由于以太网协议的限制,VLAN 能划分的虚拟局域网最多只有 4096 个。

VxLAN:即虚拟扩展局域网,为了解决 VLAN 技术在大规模计算数据中心虚拟网络不足的问题而出现的技术,最多可支持 1600 万个虚拟网络的同时存在可适应大规模租户的部署。

VPC:Virtual Private Cloud,即虚拟私有云,最早由 AWS 于 2009 年发布的一种技术,为公有云租户实现在公有云上创建相互隔离的虚拟网络,其技术原理类似于 VxLAN。

从技术特点上看,VLAN 是一种粗粒度的网络隔离技术,VxLAN 和 VPC 更接近于微隔离的技术要求但还不是微隔离最终的产品形态。

我们来看一个真实的生产环境中的工作负载之间的访问关系:

从这张图中我们看到少数的几台工作负载都会有如何复杂的业务访问关系,那么当工作负载数量急剧上升时我们急需一套更加智能的隔离系统。以下是我们总结需要微隔离技术的几大理由:

实现基于业务角色的快速分组能力,为隔离分区提供基于业务细粒度的视角(解决传统基于 IP 视角存在较多管理上的问题);

在业务分组的基础上自动化识别内部业务的访问关系,并能通过可视化方式进行展示;

实现基于业务组之间的隔离能力、端到端的工作负载隔离能力、异常外联的隔离能力,支持物理服务器之间、虚拟机之间、容器之间的访问隔离;通过隔离全面降低东西向的横向穿透风险,支持隔离到应用访问端口,实现各业务单元的安全运行;

具备可视化的策略编辑能力和批量设置能力,支持大规模场景下的策略设置和管理;

具备策略自动化部署能力,能够适应私有云弹性可拓展的特性,在虚拟机迁移、克隆、拓展等场景下,安全策略能够自动迁移;

在混合云环境下,支持跨平台的流量识别及策略统一管理。

三、微隔离技术选型

目前市面上对于微隔离产品还没有统一的产品检测标准,属于一种比较新的产品形态。

Gartner 给出了评估微隔离的几个关键衡量指标,包括:

1)是基于代理的、基于虚拟化设备的还是基于容器的?

2)如果是基于代理的,对宿主的性能影响性如何?

3)如果是基于虚拟化设备的,它如何接入网络中?

4)该解决方案支持公共云 IaaS 吗?

Gartner 还给客户提出了如下几点建议:

1)欲建微隔离,先从获得网络可见性开始,可见才可隔离;

2)谨防过度隔离,从关键应用开始;

3)鞭策 IaaS、防火墙、交换机厂商原生支持微隔离;

从技术层面看微隔离产品实现主要采用虚拟化设备和主机 Agent 两种模式,这两种方式的技术对比如下表:

  虚拟化设备模式 主机 Agent 模式
策略执行单元 虚拟化设备自身的防火墙功能 调用主机自身的防火墙或内核自定义防火墙
策略智能管理中心 基于 SDN 的策略控制面板 自研的智能策略管控平台
采用的协议 实现(类)VxLan 相关协议 沿用系统自带的 IP 协议栈
对网络的改造 需要引入 SDN 相关的技术设备 无需改造
是否支持容器场景 较难支持 支持容器场景的隔离
是否支持混合云场景 较难支持,无法跨越多个云环境进行统一管控 容易支持,不受环境限制
是否支持漏洞风险关联 较难支持 可以跟主机应用资产进行关联,快速定位漏洞风险
成本 成本较高 成本适中

总体来说两种方案各有优缺点:

1. 如果环境中租户数量较少且有跨云的情况,主机 Agent 方案可以作为第一选择;

2. 如果环境中有较多租户分隔的需求且不存在跨云的情况采用 SDN 虚拟化设备的方式是较优的选择,主机 Agent 方案作为补充。

另外主机 Agent 方案还可以结合主机漏洞风险发现、主机入侵检测能力相结合,形成更立体化的解决方案,顺带提一句,目前我们的工作负载安全解决方案已经可以完全覆盖这个场景的需求。

四、企业如何执行微隔离实施工作

在成功部署微隔离中的最大拦路虎首推可见性问题。分隔粒度越细,IT 部门越需要了解数据流,需要理解系统、应用和服务之间到底是怎样相互沟通的。

同时需要建立微隔离可持续性。随着公司不断往微隔离中引入更多资产,负责团队需考虑长远发展,微隔离不是「设置了就可以丢开不管」的策略。这意味着,企业需设立长期机制以维持数据流的可见性,设置技术功能以灵活维护策略改变与实施要求;还意味着需清晰描述微隔离配置管理中各人都负责做些什么。

微隔离管理的角色和责任同样很重要。微隔离规则的改变应经过审查,类似配置控制委员会这种运营和安全团队可验证变更适当性的地方。

五、检验微隔离的效果

检验微隔离是否真正发挥效果,最直接的方式就是在攻防对抗中进行检验。我们可以模拟以下几个场景进行检验:

(1)互联网一台主机被攻陷后,能够触达内部多大范围的主机和工作负载;

(2)同一业务区域一台主机被攻陷后,能否攻陷该业务区域的其他主机和工作负载(所有工作负载都存在可以利用的漏洞);

(3)某一业务区域一台主机被攻陷后,能否触达跟该业务区域有访问关系的其他业务区域的核心主机和工作负载;

(4)内部一台主机被攻陷后,能够触达到域控主机以及能否攻陷域控主机(域控主机存在可以利用的漏洞);

(5)内部一个容器工作负载被攻陷后,能够触达内部其他多少个容器工作负载;能否通过该容器渗透到宿主主机;

(6)以上所有网络访问行为是否在微隔离系统中的策略智能管控平台上监测到,是否有明显报警标记。

 以上是我们可以总结的一些检测场景,安全部门还可以根据自身业务的实际情况模拟更多的攻防对抗场景进行检验,才能做到「知己知彼,百战不殆」。

*本文作者:安全狗,转载请注明来自FreeBuf.COM

网络安全领域的独特对抗属性给人工智能应用落地带来了重重困难,但我们并不认为这最终会阻碍人工智能成为网络安全利器。我们尝试分析了人工智能在网络安全应用里的潜在困难,并试着解决它们。

基于机器学习、深度学习的网络安全应用研究是近年来网络安全领域里的一个热门研究方向。从可见的资料上来看,安全专家已经在异常进程行为检测、恶意代码检测、网络入侵检测等方面进行了广泛的学术研究。但是我们的直观感受是,主流安全厂商并没有大规模部署和使用这些技术,市面上声称采用的机器学习、深度学习的安全产品也相当有限。相比于机器学习、深度学习在人脸识别、推荐系统、舆情监督等方面的大规模成功应用,其在网络安全领域表现平平必然存在某些特殊的原因。本文将深入探讨机器学习、深度学习等技术在网络安全领域的应用面对的困难及其相应对策。虽然这些困难并没有使机器学习、深度学习成为网络安全领域的一个不合适的工具,但这些困难却是导致业界没能大规模采用机器学习、深度学习技术的主要原因。同时又由于近年来媒体的报道更倾向于夸大人工智能技术的成果,而忽略它们所存在的缺陷和困难,显得导向偏颇。对此,与决策者而言不应该只被其表面的光鲜所迷惑,而应该对人工智能技术有足够清晰的认知,希望本文能为这方面的认知提供一个可探讨的方向。

注: 为了便于下文的表述,以下的内容将采用“人工智能系统”指代依靠机器学习或是深度学习实现的安全防护或检测系统。

困难1 确定一个真正需要用到人工智能的任务

人当人工智能上升为国家战略,深度学习成为新兴技术。对于公司决策层而言当前应思考在结合目前公司发展在当前阶段是否真正需要用到人工智能技术。

首先,需要对人工智能技术有足够清晰和深入的了解。在当前阶段,人工智能的实现是由数据驱动的。优秀的人工智能是建立在海量行业数据的支撑下。

其次,人工智能开发和应用阶段都是计算密集型的。虽然所需的软、硬件计算环境与传统的软件开发有着很大的区别,但其带来的好处也是相对可观。以机器学习为代表的人工智能具备高效、自动化、可拓展的特点,极大程度上可代替人工处理日常事务。

开启一项人工智能项目,最大的难题是如何确定一个真正需要用到人工智能技术且可具备顺利研发并落地条件的任务。

对策

决策者需要在了解人工智能工作机制和其优缺点的基础上去思考并确定是否要在特定任务中运用人工智能技术。而在时机、成本、团队、可行性、预期效果等方面则需要重点考虑。

时机。思考在解决某特定任务时运用传统技术是否遇到瓶颈和缺陷,进而不得不需要研发下一代技术。对此任务,除了人工智能方案是否有其他更行之有效且简便的方法可以解决。如果没有其他可行方案,是否已经为采用人工智能技术方案而做好了采集相关数据的工作,或随时可以进行数据采集。只有充分思考这些问题后才能基本确定是否运用人工智能技术的作为解决问题的方案。人工智能不是万能药,却是一种有效但更为复杂的灵丹。

成本。永远别低估人工智能系统的成本投入。无论是开发还是维护人工智能系统都需要大量的持续投入,包括算力资源投入、人力资源投入以及数据收集、整理、存储成本投入等。很多组织没有足够的资金承担这样大规模投放,所以导致项目中途夭折,前期心血付之东流;因此在项目开始前期,需慎重思考是否有足够的能力承担应有的成本投入。

团队。人工智能系统的软件工程团队包括问题领域的专家(主题专家)、数据科学家、数据架构师等专业人才。这些团队成员带来了算法选择、模型构建、模型定制和数据管道管理等方面的技能,而这些技能构成了人工智能系统的核心。他们共同把控着人工智能系统的性能、可伸缩性、带宽、资源管理和版本控制等方面的高要求。

可行性。可行性的评估需要决策者对特定任务的本质有足够深刻的理解。某项任务能否通过人工智能技术实现自动化,基本上取决于这项任务的本质、能采集到的数据,以及这两者之间的关系。深度学习知名人物吴恩达曾经提过一个经验的规律:“如果一个普通人做某项任务的过程中,只需要思考不超过一秒钟时间就可以想通,那么这项任务很有可能可以用 AI技术自动化,现在或者就在不远的将来”,那么对于网络安全领域,如果一个专业水平在平均值以上的安全技术人员在某项任务中经过短暂的思考时间就能想通,那么这项任务大概率也可以通过AI技术实现自动化。

预期效果。对于预期效果的预判,前提是你对自己定义的任务和问题主题理解足够清晰。思考并确定人工智能系统可接受的性能和效率下限,以便工程师迅速接受指令并明确地向此目标优化系统。当然优化后的系统也会不可避免的出现误报和漏报状况,为此需要尽早确定该任务对误报和漏报的敏感度、风险成本的承担范围和处置机制。人工智能系统同样存在被绕过的风险,对抗性在网络安全领域无处不在,为避免对抗样本发生,怎样保护人工智能系统免受攻击也是一个需要提前思考的问题。

困难2 数据泛滥,难以获取高质量的训练数据集

网络安全领域往往不缺乏数据。每天都有无数攻击事件发生,安全厂商的后台数据库每天都能收录无数的攻击数据。但是单单依靠数据的数量不足以支撑开发一个人工智能系统,况且这些数据中不可避免存在着显著的冗余。数据的质量才是真正人工智能的基石。当前人工智能还处于弱人工智能的发展阶段,人工智能来自于从海量数据中学习规则、模式、特征和经验。在机器学习实现的人工智能工程中,最大的性能改进一般来自于更高质量的数据,而不是更复杂的算法。对于所有人工智能系统来说,其训练数据集的质量包括三个层面:

一是数据的多样性,这要求所收集的数据包含所研究范围的各种类型数据;

二是数据的可靠性,即数据被准确标识为是何种类型何种属性的数据;

三是数据的数量,即在数据采集清理加工去重后,可靠的数据的数量。数量太少则无法训练出可靠的模型,尤其是采用深度学习等参数众多的复杂模型的时候。

数据的收集、清理、标注、保护、监视和维护统称为人工智能项目的数据管理,这将贯穿着从项目立项到项目落地、维护、迭代的整个生命周期,且需消耗巨大的时间和精力,这需要占整个项目8成以上的时间。有别于其他领域,网络安全领域的人工智能系统项目的数据管理,其成本和难度更大,主要是因为以下原因:

1. 变化的环境。变化的环境一方面体现在业务的多样性,导致的是白样本的多样性;另一方面体现在对抗环境下,导致的是恶意样本的对样性;

2. 私有、公开数据少,且公开数据有效性不好。因为不同场景不同用户的数据有差异,公开的数据的场景和你所面对的环境和场景可能差异巨大而不可用。算法工具通常是开源的,但是好的数据集通常是专有的。安全领域更是如此。安全厂商倾向于“隐藏”与安全相关的数据,因此通常无法获得具有代表性的准确标记数据(尤其是涉及流量数据)。拥有庞大优质的特定领域数据集可以成为竞争优势的重要来源。

3. 数据加工清洗标注专业性高。标注人脸识别、猫狗分类、垃圾邮件等任务的数据,但凡受过基础教育的人就能胜任,而网络安全则属于专业性高的行业,标注网络安全检测相关数据集需要专业的安全工程师才能胜任。

4. 黑样本种类稀缺,难以集全。这对于后续系统的可靠性造成很大的影响。IBM的肿瘤专家顾问系统Watson for Oncology由于提出的治疗方案及其相关建议不安全,被迫终止。经过研究人员研究发现,正是由于该软件只针对少数假设癌症患者—而非实际患者数据训练而成,采用的黑样本种类稀少,因此在可靠性方面存在严重的问题。在网络安全领域,如果数据的黑样本不够全面将导致类似的可靠性问题。

5. 数据的非结构性。网络安全领域所要处理的数据无论是网络流量、恶意代码还是恶意文件,大多都是非结构化的数据,对此数据的加工处理比结构化数据要复杂困难。

6. 数据清洗,自动化困难,工具少。

对策

1.商业合作框架下的数据资料共享

当然这前提是自己已经有相当的数据积累,合作共享才会成为可能,在网络安全领域的数据共享要避免触犯《网络安全法》等法律法规;

2.依赖现有检测工具实现一定程度的自动化数据采集与标注

现有的威胁检测工具对于相应的任务必然还是有相当的检测能力的,如果将其改造为自动化标注工具则可对应解决此问题;

3.随时应变,因地适宜

对于先收集数据还是先确定任务课题的问题,没有标准答案,不同组织选择可能不一样。有的组织在收集到大量数据后才去考虑能用这些数据做什么,有的组织先确定任务,列出所需的数据类型,再收集这些数据。对此顺序只要是可行的都是可以的。

困难3 需要付出昂贵的出错成本

在网络安全领域,人工智能往往应用于风险检测。与许多其他人工智能应用相比,风险检测出错的相对代价非常高。误报需要分析师花费昂贵的时间去核查所报告的风险事件,以确定它是否是良性的。即使是很小的误报率也会使风险监测系统失去实用性。如表1所示,假设我们开发出了一个准确率高达99%的风险监测模型,这样的准确率已在众多人工智能系统中属于高水准程度。那么,设想我们在某场景下部署了该模型,部署期间产生良性事件样本999900个,恶性事件样本100个,这是相对合理的设想,风险事件的发生相比于正常事件总是极小概率事件。而在这基础上,将会发生9999起错误的告警,这将导致一系列后果:轻则耗费分析师的时间成本,重则可能影响业务系统的正常运行。

  事件总数 告警次数 识别为良性
真恶意事件 100 99(正确的告警) 1
真良性事件 999900 9999(错误的告警) 989901

表1:某99%准确率检测系统告警数量

一方面,漏报产生的损害是直接的。绕过检测的风险可能对受防护的系统产生直接的损害,影响正常业务的开展,甚至会严重损害IT基础设施。我们认为如此高的出错成本是安全厂商需谨慎使用机器学习技术的最大原因。对此让我们进一步对比人工智能在其他领域产生错误分类的影响,相比之下可能会更有启发。

电商的推荐系统是运用人工智能最成功的领域之一。推荐系统很容易容忍错误,因为这些错误不会产生直接的负面影响。虽然对卖家来说好的推荐有可能增加销售额,但坏的建议除了失去交易机会需要做出更具诱惑力的推荐策略外,对于消费者而言并没有任何的伤害。

OCR技术相比之下也更容易容忍错误。通常可以用拼写和语法检查来剔除明显的错误,使用统计语言模型将概率与结果联系起来并对OCR系统的初始输出进行后处理。此外,用户还接受了培训,这可保证当输出文本有差异时,一定程度上可以让用户进行人工校对。相比手动验证安全事件告警,验证校对文字的识别结果并不需要专业的知识,这相比验证安全告警的成本和难度都低得多。

在不同行业不同场景中,人类对于人工智能在概率表现方面的期望值有所不同(在安全行业期望值高容错率低),这也是造成人工智能产品或技术在网络安全领域普及不够广泛的原因。总的来说,网络安全检测系统对错误数据的容忍更加严格,其他领域运用人工智能是在做加法,而网络安全领域运用人工智能更像是在做减法,挑战更加巨大。

特征提取方法 提取难度 识别准确率
字节码的n-grams特征 容易实现,成本低 60-80%
Opcodes 需要反编译文件,中等工作量和成本 85-95%
执行的API调用 工作量大,计算时间长 90-95%

表2:某恶意软件检测算法研究的预测精度

另一个挑战是模型复杂度与效率的矛盾。一般来说为了得到较低出错率的模型,模型的复杂度就不能太低,这样相应的复杂模型的运算量也较大。天下没有免费的午餐,如表2所示,更深入本质的特征虽然能带来更好的准确率,但是获取难度大,效率低。两者之间的取舍是一个巨大的挑战,尤其在安全风险监测系统,往往要求对风险能够快速实时响应。

对策

限制误报量是任何威胁检测系统的首要任务。朝着减少错误的方向迈出的最重要的一步是缩小系统的范围,也就是定义一个明确的检测目标。没有一个明确的目标,任何威胁检测系统都无法在不影响其检测率的情况下,获得可容忍的误报量。另外,使用更粗粒度的特征在适当的时间间隔内聚合或平均特征对于减少误报也是有用的。最后,我们可以通过在附加信息的支持下对它们进行后处理来减少误报。如果我们发现自动化后处理是不可行的,我们仍然可以通过向分析员提供额外的信息来加速人工检查过程,从而降低出错成本。

困难4 对抗环境

人工智能系统本身就是一个软件系统,难免存在可利用的漏洞,也是被攻击的天然目标,尤其是作为网络安全检测防护系统的一份子的时候,可以认为是处于对抗环境中。相比之下,OCR系统的用户不会试图在输入中添加干扰,甚至会主动提供更高质量的输入数据;淘宝用户也不会有太多的动机去误导商品推荐系统,这对他们毫无意义。然而在网络安全领域则恰恰相反,那些破坏、绕过、欺骗人工智能检测系统攻击者为了能够达到他们入侵的目的,他们有充分的动机。至少能从三个层面体现在对抗环境下机器学习系统的风险。

数据层面,典型的是投毒攻击。投毒攻击(poisoning attack)主要是对人工智能系统在训练模型时对需要的训练数据进行投毒,是一种破坏模型可用性和完整性的诱发型攻击。攻击者通过注入一些精心伪造的恶意数据样本,这些样本通常带有错误的标签和攻击的性质,用于破坏原有的训练数据的概率分布,从而使训练出的模型的分类或者聚类精度降低,达到破坏训练模型的目的。由于实际中应用人工智能系统的原始训练数据大多是保密的,一般不会被攻击者轻易修改,但很多系统为了增强适应能力需要定期收集新数据,进行重新训练实现模型更新,这时也就给了攻击者可趁之机。

  图 1:一种投毒攻击示意图

模型层面,模型的绕过风险,即存在对抗样本攻击。攻击者通过产生一些可以绕过人工智能检测系统的对抗样本,这些是可以成功地逃避安全系统检测的对抗样本,实现对系统的恶意攻击,给系统的安全性带来严重威胁。作为安全风险检测模型的存在的时候,人工智能系统的模型的输入数据变化很大,具有易变性。我们很难限制待检测的恶意软件的大小,没有理由限制待检测的恶意代码样本的行数,没办法限制要检测的网络流量的数据包内容,因此这就给了对抗样本更大的发挥空间。这个层面的对抗是最容易发生的,也是人工智能检测系统在对抗中最薄弱的环境,对抗之下会产生层出不穷的新攻击手法、攻击样本,因此网络安全领域应用的模型的迭代频率要比其他领域要高得多。试想,千百年以后,今天训练的猫狗分类模型到那时候也许还能用,但是对应的恶意软件、木马文件、攻击流量也在当前模型的能力范围之外产生了多个新形式。

框架层面,深度学习框架通常是包含数十万代码和众多依赖的复杂软件,几乎不可避免地存在已知或未知的bug。在国家信息安全漏洞库,能查到2019年上报的tensorflow相关漏洞信息8个(如图2所示)。Torch、Caffe等框架也存在漏洞,以及这些框架的常见依赖包numpy、opencv等均存在不少漏洞。对此,相关的安全研究已经复现了这些漏洞将会造成的拒绝服务、绕过检测和系统危害等风险。

图 2: tensorflow历史漏洞

所以,网络安全领域持续进行着一场军备竞赛:攻击者和防御者各自改进他们的工具和技术,以应对另一方设计的新技术。

对策

使用人工智能技术对于攻击者而言实际上是带来更多攻击面如算法、数据等。

在防护方面,可以考虑以下几点:

1. 对模型的输入做严格限制,设置进入模型的样本过滤条件。过滤条件根据任务的专业领域知识和模型训练过程中的设置总结。比如,某识别php类型webshell的模型可将输入设置为文件后缀.php或.txt且内容包含<?php。另一个可能思路,如训练过程中训练数据集单个样本最大为2MB,则可以添加过滤条件模型输入样本最大为2MB。

2. 从模型本身训练其辨别良性、恶意数据的能力。将已知对抗样本或自己构造的对抗样本数据添加到模型的训练数据集然后训练模型。

3. 在上线部署前,在对抗环境下测试和评估人工智能系统。在对抗性情景下或极端情况下测试系统,而不仅仅只是使用正常事件测试。比如使用噪声数据训练和测试评估模型的泛化能力和抗噪能力,在对抗环境下或使用投毒数据评估系统的对抗能力。当然也不用对对抗环境带来的风险过度担心,因为在绕过一个人工智能系统,攻击者需要付出大量的努力、时间和专业知识,这往往比绕过正则规则难得多。

困难5 模型可解释性及该如何取合

人工智能系统的输出比大多数其他系统需要更多的解释。因为人工智能系统引入的不确定性在用户的某些任务和场景下可能是不可接受的,往往需要跟客户沟通做出这种输出判断的依据和缘由。而在其他机器学习的应用中,解释性的问题可能就没那么重要。大多数图像类别识别的机器学习都可以忽视可解释性,因为图像属于什么类型是直观的,普通人可以毫不费劲地辨别结果的对与错。同样,垃圾邮件检测器将邮件归为垃圾邮件,也是很直观的任务并没有太大的解释空间。然而,作为安全风险检测应用,其检测结果往往是不直观的,至少对非网络安全专业的客户来说,这时候的解释输出是取得客户信赖的必要工作。假设人工智能系统能准确地发现以前未知的web服务器漏洞,而只报告为“主机的HTTP流量与正常配置文件不匹配”,即使对它的警报足够信任,运维人员也需要花费大量的额外精力来弄清楚发生了什么。

安全风险检测往往需要进一步指导相关人员快速评估和响应制定风险处置方案,且这过程附带着极高的出错成本,因此对检测结果的必要解释和正确解释是安全风险检测应用的一个基本要求,而这也保障了其的可用性。然而这里一切的困难在于我们如何向用户展示人工智能系统输出结果的信息,使他们能够正确的接收并理解这些信息,同时我们又不能展示过多信息,以防暴露过多模型信息给竞争对手或是被攻击者利用。更困难的是,人工智能模型的原始解释是包含一系列检测逻辑的数学术语,例如某变量超过给定阈值,对于非建模人员而言这些并不好理解,对于输出结果的利用也作用有限。怎样将这些数学语义的解释与业务的语义相互联系是一个更大的难题。

对策

1.  重新设计输出结果的解释性

现有的机器学习、深度学习模型输出解释技术往往是对特征的归因,如果直接展示这些信息很容易变相地为竞争对手或是攻击者提供模型的敏感信息,增大模型被绕过的风险。我们可以对结果重新归纳设计,隐含模型相关的细节,特别是数值相关信息要避免呈现,对于输出结果的可靠性程度和不确定性避免使用数值描述,我们可以用“低、中、高”等分级表述。

2. 解释结果的最重要的方面是理解它们的起源

一个好的解释常常需要在一个非常低的层次上把输入和输出联系起来。

困难6 难以全面评估

对于网络安全领域的人工智能系统而言,设计合理完整的评估方案并不容易,事实上可能比构建识别模型本身还更困难。全面评估的最重要的一步是获取适当的数据。在网络安全领域,评估人工智能系统面临的最重大挑战是缺乏适合的、公允的、且足够数据量的现成公共数据集。即使企业自己创建测试数据集,也是很难得到足够数量和足够全面的数据。以互联网流量为例,这是网络安全典型的检测对象。互联网流量是企业和组织的重要的私有资源,不会轻易共享。对于不同的组织不同的业务,网络流量具有多样性。在小型实验室网络中的流量特征和大型业务系统的流量会显著不同。即使在单个网络中,网络的最基本特征,如带宽、连接持续时间和应用程序组合,也会表现出巨大的变化性,使它们在短时间(从几秒到几小时)内流量特征差异也可能极大。更何况,大多数企业或组织并没有获取相当规模的网络流量的条件,即使通过模拟来采集,也会因为数据的真实性和相关性等对后续的人工智能系统带来难以评估的不利影响,小环境分析得出的结论往往不能推广到大环境分析。所以数据的不全面带来的是模型性能评估的不全面,也就是人工智能系统能检测到什么,不能检测到什么,可靠性是多少等等难以全面评估。

对策

不幸的是,目前对于解决缺乏评估数据的问题,并没有一个较好的方案。对于任何研究来说,需要承认自己的评估数据集可能带来的缺点。尽管很难,还是需要从大范围的环境中获取包含真实网络流量的数据集。理想情况下,我们获取了大量来自不同的网络的数据,因为没有数据集是完美的,所以在评估检测系统时,通常需要多个数据集来做支撑。要证明系统能够通过学习适应不同的环境,也需要使用来自多个来源的数据进行评估。对于类似于互联网流量多样性问题,一种可行的方法是采用聚合。虽然流量特征在中、小时间间隔内高度可变,但在较长时间段(小时到天,有时是周)内观察到的流量特征往往更加稳定。

困难7 机器学习难以部署和维护

精心设计研发的机器学习模块是与现有安全防护系统的其他部分集成,这会产生一系列问题和风险。

首先是兼容性问题。机器学习、深度学习研发和部署工具的推出时间往往比实现现有其他安全防护系统模块的工具时间要晚。Tensorflow 是2015年推出的,PyTorch是2017年才推出的,如果现有防护系统已运行多年,那么在集成中出现底层技术不兼容概率很大。

其次是安全业务流程的改变。目前的机器学习应用水平通常难以独立发展成一个成熟的安全防护应用,大多数时候会涉及与现有防护模块的互补和协作,这将需要重新设计相关的业务流程。

最后是保护机器学习模块的完整性和可用性。这可能需要依赖现有的系统保护机器学习模块核心组件不被破坏、篡改、偷窃等。因为对手获取越多关于模型的信息,绕过模型的成本越低,防护效果就越差。

网络安全是一个瞬息万变的领域。攻击者会变,他们的手段也不会总是相同,程序语言会升级换代,攻击武器也层出不穷。唯有模型跟着变化才能充分应对这些变化。所以从维护层面上而言,最核心的难题是更新频率高。在高频的更新要求下,人工智能系统的变化率和整个系统中的其他模块是不一致的。数据和模型频繁地更改,这意味着系统的其他部分也需要进行更改。收集数据、在需要时标记数据、不断调查和学习网络安全领域将是维护ML工具的持续需求。而在迭代过程中我们将面临着系统本来能识别检测的威胁在模型更新后反而检测不到的问题。考虑图3的简化模型,假设黑色圆圈是威胁样本,我们的第一个模型F(X)的准确率是(3+4)/10=70%,我们迭代模型到第二个模型G(X),其准确率是(5+4)/10=90%,准确率显然是提高了,但是左下角的黑圆圈样本是能被F(X)检测到的,反而准确率更高的G(X)却识别不出来。这在机器学习项目中经常出现。由于算法的优化目标是在指定数据集上准确率等指标做出全局最优解,在迭代过程中可能由于数据集增大了、减少了或是黑样本变多了,数据均衡和分布规律和之前不一样了,又或是模型的超参数做了调整等都会改变模型的决策边界从而导致这类情况发生。

图 3:模型迭代效果示意图

对策

开发团队应该充分在架构设计上考虑好安全性、可用性、可靠性、性能、可伸缩性等核心需求。尽可能实现松散耦合的部署方案,可以扩展或替换,以适应不可避免的数据和模型的变化和算法创新,从而减少每次的更新对系统其他模块或是系统基础结构的影响和更改。实现收集反馈闭环,跟踪人工智能系统生产环境下的输出,形成反馈工作流程,定期分析、反馈检测结果和性能指标,进行发现薄弱环境以指导下一步的迭代。应该尽可能使用自动化的方法来获取系统输出的人类反馈,并改进(即重新训练)模型。即时监控用户体验、尽早发现问题,例如以系统延迟或降低准确性的形式降低性能。即使是在低交互系统中,也要确保持续的人类参与,以监测计算机是否因无法编码而进行评估的判断(实际的、道德的、道德的、信任的、与风险相关的),以及是否存在模型篡改或系统误用的迹象。


参考资料

1.《Robin Sommer and Vern Paxson , “Outside theClosed World: On Using Machine Learning For NetworkIntrusion Detection”》2.《 Machine Learning in Cybersecurity a Guide》3.《Rules of ml》4.《人工智能赋能网络空间安全:模式与实践》5.《机器学习安全性问题及其防御技术研究综述》6. 《AIEngineering: 11 Foundational Practices Recommendations for decision makers fromexperts in software engineering, cybersecurity, and applied artifcialintelligence》

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

声明

本文仅供学习和研究,由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,海青实验室及文章作者不承担任何责任。

安全狗海青实验室拥有此文章的修改和解释权,如欲转载或传播,必须保证此文的完整性,包括版权声明在内的全部内容,未经海青实验室同意,不得任意修改或者增减此文章内容,不得以任何方式将其用于商业目的。

近日得到了红日安全团队制作的一套渗透测试靶场,由于笔者对内网和域渗透并不熟悉,正好借此来学习一下渗透测试的基本操作和流程。有意思的是,笔者在前台发现了一个SQL注入,并且使用了一个小trick,所以分享一下。

一、Web服务器的突破

整个网络服务起来以后,扫描了一下目标IP,查看了开放了哪些端口。

显然存在WEB应用,访问看看。(注:我没用扫描器,讲道理实战应该是没有yxcms这个目录的,我是看了一下靶机的文件结构)

当得知了是YXCMS的系统,那么剩下的就是收集该系统存在的已知漏洞,那问题是,版本号还不知道。在github上搜了一下这套系统的源码,查看了一下目录结构,发现有一个升级日志.txt。根据之前审计代码的经验,多数的CMS会有一个README和类似升级日志这样的文件,记录一下当前版本的一些信息。

试试访问看,果然有——这样就拿到了版本号,那接着就是找yxcms1.2.1版本的漏洞。

搜索后会发现有这么一个网站,预留的后台账户……我感觉这个靶场应该没有修改过这个密码,就拿这个弱密码去尝试了。

ok,成功进入后台,在后台可以看到编辑模板的地方,竟然还可以直接创建PHP文件,但是创建完的文件路径需要寻找,一时间我没找到,我是下载了源码在本地测试发现路径如下:

WWW\yxcms\protected\apps\default\view\default\a.php

可怜的kali只有一把C刀,感觉要找把好用的菜刀。

二、以代码审计的方式突破

显然,上述攻破WEB服务器的方式太过于走运:恰好就那么一个预留账号,还是默认密码,这种方式不具有普遍意义。既然我们已经能拿到对应版本的源码了,总该尝试一下以审计的方式,找出漏洞点拿下服务器。因为对该系统的框架不是很熟悉,笔者只了解到是个MVC架构,屋漏偏逢连夜雨,Xdebug在此时又出问题了,无法动态调试,于是就进行静态分析,不断打印输出exit。

目标:找到一个不需要验证的、或者普通用户权限的注入点,拿下管理员账号。

很快,在Index控制器下可以发现如下代码。其中变量code是可控,并且解密后赋值给变量$acc,再之后传入了find方法之中,为了构造出完整的POC进行注入,需要找到最终构造SQL语句的代码。

find方法定义在model.php文件,显然第一个参数是条件语句。那么如上以拼接的方式构造SQL语句,显然很有可能出现SQL注入的问题。

在cpModel.class.php中找到了find方法和select方法的定义,最终的查询条件是在select方法中构造,因此将构造好Where条件打印出来看看。

接着就是跟进query方法,在此构造完整的查询语句,并且执行,在此次打印出查询语句。

这样其实就已经抓住了SQL语句构造的关键点了,再回头看最初的一行代码:

$acc=cp_decode(urldecode($_GET['code']),config(‘ENCODE_KEY’));

显然,cp_decode是一个自定义的解密函数,代码如下

有解密自然就有加密。

思路很明显了,构造好SQL注入的payload,调用加密函数进行加密,然后传入,试试看。

payload:11' or '1'='1

加密后:

7e2bRaLd9061hM95hQB2apg0gw7kbOQcWLDFQWU9aPnWWi9%252FRgJFYj0eIYHmUiJ9JlQ

效果如下:解密之后拼接进SQL语句,显然,此处存在注入。

三、使用几行代码复活SQLmap

此时又面临了一个问题,如何自动化进行注入呢?作为一个脚本小子,自然想到使用SQLmap,可是有着自定义的加密函数,难不成要手撸一个python版的加密?然后再写SQLmap的tamper?太繁琐了!渗透神器在此竟然无用武之地?

其实,只需用几行代码就能复活神器!

在本地搭建一个flask平台接受SQLmap传递来的payload,然后去访问写有加密函数的PHP文件获取加密后的payload,最终再往目标网站上发包!

画了个大概的流程图:

flask平台代码如下:

from flask import Flask

from flask import request

import requests

php_url = "http://127.0.0.1/encode.php?payload={}" #加密函数文件

tar_url = "http://yxcmsapp/index.php?r=member/index/getpassword&code={}" #目标网站

app = Flask(__name__)

@app.route('/',methods=['GET'])

def getStr():

    payload = request.args.get('payload') # 接受SQLmap的payload

    print("payload is .........: {}".format(payload))

    print("Encoding ....")

    en_str = php_url.format(payload)

    rs = requests.get(en_str)# 将payload发送至加密函数文件进行加密

    print("Encoding payload......: {}".format(rs.text))

    print("attack!")

    attack_rs = requests.get(tar_url.format(rs.text)) #将加密后的payload发往目标站点

    return attack_rs.text

if __name__ == '__main__':

    app.run()

除去一些输出语句,总共就没几行代码。

加密函数文件内容直接复制过来,如下:

因为源程序中解码时调用了一次urldecode,所以要两次encode。

最后,使用SQLmap对flask平台进行SQL注入,效果如下。

最终,可以通过注入拿下管理员的账号,剩下的getshell的操作就和之前一样了。

值得一提的是,这套系统定义了一个in函数,用来防止SQL注入。可能开发者发现加密后的函数并不存在特殊字符就没用进行in函数的转义了吧,从而导致注入的产生。

上述的方法在很多场景下都可以使用,比如利用了JS对前端的一些参数加密后传输、表单收到Token保护等。如果不想分析原有的加密算法,就可以采用这种中转的方式进行攻击。拿了shell之后不知道该如何继续了,初体验就暂时到此结束。

已经WEB服务的大门已被攻破,在内网的操作这里就不作展开了。

四、总结

靶场其实是实际案例的一种映射,很多运维人员在建立企业网站时采用的就是此类的开源系统。的确,一键式的部署能够快速建站极其便利,但同时也带来了安全风险,譬如默认的管理员账号密码、系统版本信息、固定的网站目录等一些信息也随之暴露给攻击者。

因此、在广大用户选用开源系统快速建站的同时要注意选用安全性较高、积极维护的开源系统。关注该系统的历史版本是否存在漏洞,以及是否及时修补。有条件或者必要的情况下,可以对该系统进行一次代码审计排查隐患,也可以选择网站安全狗等系列WAF产品来抵御攻击。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

声明

本文仅供学习和研究,由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,海青实验室及文章作者不承担任何责任。

安全狗海青实验室拥有此文章的修改和解释权,如欲转载或传播,必须保证此文的完整性,包括版权声明在内的全部内容,未经海青实验室同意,不得任意修改或者增减此文章内容,不得以任何方式将其用于商业目的。

近日得到了红日安全团队制作的一套渗透测试靶场,由于笔者对内网和域渗透并不熟悉,正好借此来学习一下渗透测试的基本操作和流程。有意思的是,笔者在前台发现了一个SQL注入,并且使用了一个小trick,所以分享一下。

一、Web服务器的突破

整个网络服务起来以后,扫描了一下目标IP,查看了开放了哪些端口。

显然存在WEB应用,访问看看。(注:我没用扫描器,讲道理实战应该是没有yxcms这个目录的,我是看了一下靶机的文件结构)

当得知了是YXCMS的系统,那么剩下的就是收集该系统存在的已知漏洞,那问题是,版本号还不知道。在github上搜了一下这套系统的源码,查看了一下目录结构,发现有一个升级日志.txt。根据之前审计代码的经验,多数的CMS会有一个README和类似升级日志这样的文件,记录一下当前版本的一些信息。

试试访问看,果然有——这样就拿到了版本号,那接着就是找yxcms1.2.1版本的漏洞。

搜索后会发现有这么一个网站,预留的后台账户……我感觉这个靶场应该没有修改过这个密码,就拿这个弱密码去尝试了。

ok,成功进入后台,在后台可以看到编辑模板的地方,竟然还可以直接创建PHP文件,但是创建完的文件路径需要寻找,一时间我没找到,我是下载了源码在本地测试发现路径如下:

WWW\yxcms\protected\apps\default\view\default\a.php

可怜的kali只有一把C刀,感觉要找把好用的菜刀。

二、以代码审计的方式突破

显然,上述攻破WEB服务器的方式太过于走运:恰好就那么一个预留账号,还是默认密码,这种方式不具有普遍意义。既然我们已经能拿到对应版本的源码了,总该尝试一下以审计的方式,找出漏洞点拿下服务器。因为对该系统的框架不是很熟悉,笔者只了解到是个MVC架构,屋漏偏逢连夜雨,Xdebug在此时又出问题了,无法动态调试,于是就进行静态分析,不断打印输出exit。

目标:找到一个不需要验证的、或者普通用户权限的注入点,拿下管理员账号。

很快,在Index控制器下可以发现如下代码。其中变量code是可控,并且解密后赋值给变量$acc,再之后传入了find方法之中,为了构造出完整的POC进行注入,需要找到最终构造SQL语句的代码。

find方法定义在model.php文件,显然第一个参数是条件语句。那么如上以拼接的方式构造SQL语句,显然很有可能出现SQL注入的问题。

在cpModel.class.php中找到了find方法和select方法的定义,最终的查询条件是在select方法中构造,因此将构造好Where条件打印出来看看。

接着就是跟进query方法,在此构造完整的查询语句,并且执行,在此次打印出查询语句。

这样其实就已经抓住了SQL语句构造的关键点了,再回头看最初的一行代码:

$acc=cp_decode(urldecode($_GET['code']),config(‘ENCODE_KEY’));

显然,cp_decode是一个自定义的解密函数,代码如下

有解密自然就有加密。

思路很明显了,构造好SQL注入的payload,调用加密函数进行加密,然后传入,试试看。

payload:11' or '1'='1

加密后:

7e2bRaLd9061hM95hQB2apg0gw7kbOQcWLDFQWU9aPnWWi9%252FRgJFYj0eIYHmUiJ9JlQ

效果如下:解密之后拼接进SQL语句,显然,此处存在注入。

三、使用几行代码复活SQLmap

此时又面临了一个问题,如何自动化进行注入呢?作为一个脚本小子,自然想到使用SQLmap,可是有着自定义的加密函数,难不成要手撸一个python版的加密?然后再写SQLmap的tamper?太繁琐了!渗透神器在此竟然无用武之地?

其实,只需用几行代码就能复活神器!

在本地搭建一个flask平台接受SQLmap传递来的payload,然后去访问写有加密函数的PHP文件获取加密后的payload,最终再往目标网站上发包!

画了个大概的流程图:

flask平台代码如下:

from flask import Flask

from flask import request

import requests

php_url = "http://127.0.0.1/encode.php?payload={}" #加密函数文件

tar_url = "http://yxcmsapp/index.php?r=member/index/getpassword&code={}" #目标网站

app = Flask(__name__)

@app.route('/',methods=['GET'])

def getStr():

    payload = request.args.get('payload') # 接受SQLmap的payload

    print("payload is .........: {}".format(payload))

    print("Encoding ....")

    en_str = php_url.format(payload)

    rs = requests.get(en_str)# 将payload发送至加密函数文件进行加密

    print("Encoding payload......: {}".format(rs.text))

    print("attack!")

    attack_rs = requests.get(tar_url.format(rs.text)) #将加密后的payload发往目标站点

    return attack_rs.text

if __name__ == '__main__':

    app.run()

除去一些输出语句,总共就没几行代码。

加密函数文件内容直接复制过来,如下:

因为源程序中解码时调用了一次urldecode,所以要两次encode。

最后,使用SQLmap对flask平台进行SQL注入,效果如下。

最终,可以通过注入拿下管理员的账号,剩下的getshell的操作就和之前一样了。

值得一提的是,这套系统定义了一个in函数,用来防止SQL注入。可能开发者发现加密后的函数并不存在特殊字符就没用进行in函数的转义了吧,从而导致注入的产生。

上述的方法在很多场景下都可以使用,比如利用了JS对前端的一些参数加密后传输、表单收到Token保护等。如果不想分析原有的加密算法,就可以采用这种中转的方式进行攻击。拿了shell之后不知道该如何继续了,初体验就暂时到此结束。

已经WEB服务的大门已被攻破,在内网的操作这里就不作展开了。

四、总结

靶场其实是实际案例的一种映射,很多运维人员在建立企业网站时采用的就是此类的开源系统。的确,一键式的部署能够快速建站极其便利,但同时也带来了安全风险,譬如默认的管理员账号密码、系统版本信息、固定的网站目录等一些信息也随之暴露给攻击者。

因此、在广大用户选用开源系统快速建站的同时要注意选用安全性较高、积极维护的开源系统。关注该系统的历史版本是否存在漏洞,以及是否及时修补。有条件或者必要的情况下,可以对该系统进行一次代码审计排查隐患,也可以选择网站安全狗等系列WAF产品来抵御攻击。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

一、前言

大型企业的项目实施往往涉及到大量部门和分、子公司的协调配合,这带来了双方面的困难:在技术上,设备和系统分散且不统一,威胁因素和程度难以感知,决策层对于当前的安全态势难以描述和决策;在工作的推进方面,客户企业下属各单位的配合程度直接影响了项目实施的进展和质量,如何做好协调沟通工作、顺利推进项目实施,也是对安全行业极大的考验。

我们将在这篇文章里,结合我们曾经实施过的一些案例,探讨如何为大型企业部署实施大数据安全态势感知的项目。希望本文能够起到“抛砖引玉”的作用,如有更好的见解,望不吝赐教,笔者不胜感激。

二、项目背景

1、客户信息

客户是大型集团性企业,旗下拥有投资企业300余家,全资及控股投资企业逾200家,员工超万人。

2、项目目标

解决集团信息安全在横向安全体系方面的缺陷,实现全网安全感知、检测、预警及运维响应,结合安全服务,提升整体的安全运营水平,增强安全的主动防御能力。

项目总体目标

安全运行能力目标

运维能力目标

三、解决方案和实施

1、项目方案

经过分析,我们最终确定了这样的解决方案:

通过部署啸天网络安全态势感知系统、云眼主机入侵监测及安全管理系统,其中流量采集探针为啸天网络安全态势感知系统的功能模块,以硬件形式部署。

进行全网安全数据采集,利用大数据技术,结合威胁情报,实时发现网络及信息系统中潜在的安全威胁,呈现全网的安全态势,辅助集团安全运维人员和专业厂商安全团队开展威胁分析,提升主动防御能力。

2、人员保障

为保障项目顺利实施,我们组建了10人以上的项目团队,人员构成上包括了项目经理、实施工程师、安全研究员、安全服务工程师、研发工程师、测试工程师等岗位。

3、实施过程

总体部署架构如下图所示:

部署架构逻辑示意图

根据总体方案,将实施过程分为三个阶段:

第一阶段:软、硬件设备上线

在方案中,包含的软、硬件设备有:态势感知平台、EDR平台、流量分析设备,经过前期的交流与现场的评估,态势感知与EDR平台采用虚拟化服务器集群部署,具体部署态势架构如下图所示:

态势感知部署架构示意图

具体部署EDR架构如下图所示:

EDR部署架构示意图

经过一周的时间,流量设备上架,EDR平台部署、态势感知平台按照计划完成部署。

第二阶段:数据接入、日志泛化、调试

数据的接入调试是整个项目实施重点,新增的流量分析设备日志推送态势平台,EDR客户端部署、事件日志推送态势平台,原有的部分安全设备、安全系统(XX防火墙、XX交换机、等等)日志推送态势平台。

(1) 首月:进展缓慢

流量分析设备:在接入流量后,流量分析设备检测出集团内网各种异常事件,最严重的是近50台左右服务器和办公PC中挖矿病毒,内网访问恶意IP近100台,其他安全告警几百条。客户在看到数据后,为了梳理整个内网十分严峻的安全态势,与项目小组展开多次论证,不断调整整改处理方案。

EDR轻代理部署:经过项目小组多次协调测试部署,第一个月的部署量只有十几台。通过少量部署,我们总结出内网服务器存在几个通用问题,主要包括漏洞风险和入侵威胁两个方面。

漏洞风险:弱口令、危急高危系统漏洞、高危账号、配置缺陷

入侵威胁:病毒木马、网页后门、异常账号。

安全设备、安全管理系统日志泛化调优:在相关设备日志和安全管理系统日志推送到态势平台后,经过两周对平台上的事件做微调优化,关联引擎优化,让各类安全数据、态势要素进行综合分析评判,从多维度和指标化的形式来呈现,帮助管理层辅助决策和执行层运维指导。

(2) 次月:快速推进

项目的推进往往需要关键性的事件的推动,第二个月才开始,态势平台就告警了特大病毒安全事件,导致多个关键业务系统中断,所涉及服务器40台以上。

在发生重大安全事件后,我方项目组紧急启动应急机制协助客户处理,调配红方攻击团队、蓝方审计团队、项目组实施团队安全工程师,通宵制定出业务恢复方案、病毒检测处理方案、安全加固方案、事件分析方案,当晚恢复最关键三个业务系统,并做好安全加固、防护,连续三个昼夜,协助客户恢复所有波及的业务系统,并梳理出溯源结果,给出初步整改防护方案、后续整改防护方案。

此次突发安全事件使得安全防护无比紧迫,三天的时间核心区域服务器EDR部署到几百台,部署简易策略优化是一个复杂的过程,根据平台检测出的问题,经过双方梳理,接下来的工作分为整改、监控、防护。

整改:1.高危、危急漏洞通过平台修复(交付修复方案);2.大量弱口令限期整改;3.大量高危账号限期整改;4.配置缺陷限期整改;5.病毒木马清理;6.基线优化。

监控:1.异常登录监控;2.完整性监控;3.进程监控;4.操作审计监控;5.暴力破解监控。

防护:1.暴力破解防护;2.扫描防护;3.病毒防护;4.端口最小化防护;5.特殊服务器进程白名单防护。

第三阶段:扩大推广试运行

推广接入所有网络设备日志、所有服务器系统日志、所有应用网站日志,推广所有服务器EDR部署工作,平台安全数据治理工作。

四、项目成效

通过接入全网流量10G以上,部署EDR节点1000+,安全日志接入,分析出威胁事件800余条,处置安全问题资产:服务器200余台,PC终端300余台,态势平台发现大量穿透现有安全体系攻击威胁,经过项目组专项治理后网络安全态势恢复良好状态,每日失陷服务器降为0,每日失陷终端PC<3,整体安全处于可感知、可控制水平。

五、总结

大型企业的项目实施,所涉及非常多部门和分子公司协调,需要客户决策层强有力的支持。

安全事件是一把双刃剑,一方面给客户带来非常棘手的影响,但另一方面又能为项目推进带来质的变化。

态势感知平台是一个需要大量数据支撑的系统,而主机EDR能力恰恰能够为态势感知平台提供大量的关键数据。通过对海量的日志进行关联分、情境分析、智能分析,能够对关键信息基础设施的网络安全信息实时监测,对重大网络攻击实时感知,同时进一步探索对攻击破坏情况准确评估,做好对重点保卫目标的威胁、隐患及时预警和快速处置工作。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

声明

本文仅供学习和研究,由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,海青实验室及文章作者不承担任何责任。

安全狗海青实验室拥有此文章的修改和解释权,如欲转载或传播,必须保证此文的完整性,包括版权声明在内的全部内容,未经海青实验室同意,不得任意修改或者增减此文章内容,不得以任何方式将其用于商业目的。

攻击者可以快速的从文件上传功能点获得一个网站服务器的权限,所以一直是红蓝对抗中的“兵家必争之地”。而随着对抗不断升级,开发人员的安全意识的不断提高,多多少少也学会了使用黑名单或者白名单等一些手段进行防御,但刁钻的攻击者,依然发现了疏忽之处。本文以两个实例,简单介绍文件解压功能导致的getshell问题。

PHPOK CMS后台任意文件上传

首先,准备一个zip文件里,里面包含了一个PHP文件。然后,在导入模块中将zip文件上传。

在尝试的时候发现,导入模块失败了,但是查看文件夹内容,可以发现文件已经成功被写入了。

流程分析

从代码层面来看看整个流程是怎样的?

当我们点击导入模块时,浏览器会发送两条请求。先看第一条POST请求。根据PHPOK CMS路由分发的规则,可以定位到upload控制器中的zip方法。

而在43行处,引入了libs\upload.php文件并且调用zipfile()函数。

在第135行处,设定了文件后缀类型为zip,由于137行处的if条件不成立,流程进入140行,调用_save()方法。继续跟进_save()方法。

_save()方法在276行处使用file_ext()方法对传入的name参数也就是文件名进行后缀判断,而如果判断通过,则会在之后将压缩文件保存下来。跟进一下file_ext()方法。

在该方法中,设置了一个白名单,文件名只能是jpg,gif,png,zip中的其中一种。为什么包含zip呢?不管是程序执行到第186或者189行处,在前面就已经给这两个变量设置值为zip了,所以在白名单中自然包含了zip。 目前到此为止,整个上传流程没有什么问题,并且使用了白名单来限制后缀,所以只能上传zip压缩文件。接着再来看第二处请求

admin.php?c=module&f=import&zipfile=_cache%2Fa9414ae41044fc5a.zip&_=1570603538199

同样根据路由规则,可以定位到module控制器下的import方法

程序会接受到zipfile参数,是刚刚压缩包保存在缓存文件夹里的文件名。在第705行处判断了是不是存在这个压缩包,如果存在则在708行处进行解压。其中引入了libs/phpzip.php中的unzip函数进行解压。跟进unzip函数,程序实例化了ZipArchive类进行解压,而目标路径$to则是缓存文件夹。

到此不难看出问题,程序将压缩包中的文件解压出来之后,并未进一步的进行判断,以至于里面包含的 PHP文件可以绕过上传文件的限制,使得原本建立的安全防御土崩瓦解。

Jspxcms后台的zip解压功能目录穿越漏洞导致getshell

由于这套CMS做了相关防御配置,压缩包里像上文中直接加入JSP文件是无法执行的,会报403错误。因而想到使用目录穿越的方式,跳出JspxCM的根目录,并根据war包会自动解压的特点,从而getshell。

首先,建立一个恶意的war包,并且打成压缩包,如图所示。

然后点击“上传文件”按钮,上传test5.zip,如图所示。

紧接的使用解压功能,将上传的压缩包解压出来。点击“ZIP解压按钮”,如图所示。

此时,在服务器端查看webapps目录的变化,可以发现safedog.html和vul.war文件被解压到了网站根目录“webapps/ROOT”之外,如图所示。

访问上传的webshell,效果如下。

http://192.168.114.132:8080/vul/webshell.jsp?pwd=023&cmd=calc

流程分析

在后台登录之后,找到ZIP解压功能,通过BurpSuite进行抓包可以发现“解压文件”的接口调用情况,如图所示。

该接口对应了jspxcms-9.5.1-release-src/src/main/java/com/jspxcms/core/web/back/WebFileUploadsController.java的unzip方法,如图所示。

对unzip方法进行跟进,发现它的具体实现在/jspxcms-9.5.1-release-src/src/main/java/com/jspxcms/core/web/back/WebFileControllerAbstractor.java中。可以发现,在对zip文件进行解压的时候,调用了AntZipUtil类的unzip方法,如图所示。

对AntZipUtil类的unzip方法进行跟进,可发现该方法未对ZIP压缩包里的文件名进行参数校验,就进行文件的写入。这样的代码写法会引发“目录穿越漏洞”,如图所示。

总结

从上述两则实例来看,压缩包里包含着webshell颇有些特洛伊木马的味道。当程序对上传后缀限制的相当严格,例如上文提到的PHPOK CMS,已经使用白名单的机制只能上传四种后缀的文件,却依然因为对压缩文件的处理不当,导致整个防御机制的失效。在ZZZCMS中的实例,猜测开发者的本意是zip文件夹内的内容应该别可控的,但在目录穿越的加持下,超出了开发者的预期从而防御机制土崩瓦解。

那么如何防御呢?建议开发者在实现文件解压功能时考虑以下要点:

1)限制文件的扩展名(如采用白名单的方式);

2)限制文件的名称(以较为严谨的黑名单约束文件名);

3)限制文件的大小(以免遭受压缩包**的DDoS攻击)。

因此,在开发的各个环节,都要将安全意识贯彻其中。千里之堤毁于蚁穴,也正是这种细微之处的小问题,才使得攻击者有机可乘。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

一、前言

ATT&CK是今年国内安全行业的一个备受瞩目的火热概念,很多组织和厂商发布了文章阐释各自对于它的理解,甚至连不少甲方单位也开始关心起ATT&CK,不仅向安全厂商咨询其在这方面的研究成果,似乎也有意将其当做衡量厂商产品能力的一个维度——安全圈一时间颇有些“平生不识此概念,纵做安全也枉然”的氛围。

当然,这个现象很正常,ATT&CK作为一项来自国外的新技术概念,安全行业理所应当对其进行研究分析。但另一方面,当前业内对于ATT&CK的研究分析存在很多误解和片面的地方,因此我们从自己的角度出发对ATT&CK进行了一些探讨,希望能够还原其本来面目、消除过度的“神秘感”,重新审视这一技术的真正价值。当然作为一家之言,我们肯定也存在不客观的地方,是非对错,尽付公论。

二、ATT&CK

1、ATT&CK框架介绍

ATT&CK(Adversarial Tactics, Techniques & Common Knowledge)是MITRE公司开发的、基于真实环境观察攻方战术和技术的知识库。

MITRE是由美国政府资助的一个非盈利研发机构,向美国政府提供系统工程、研究开发和信息技术的支撑。并和美国国家标准与技术研究所(NIST)标准化组织合作制定相关安全标准,比如漏洞缺陷CVE、CWE编号规则以及威胁情报格式STIX。

MITRE ATT&CK框架内系统性的收集整合了整个攻击过程完整生命周期的攻击手法的知识库,并且这些攻击手法均来自于对真实安全事件的洞察。该框架把攻击者所采用的TTP(战术Tactics,技术Techniques,过程Procedures)系统性地组织起来。在每个战术项内又包含实现该战术目的的各种已知的攻击技术,同时在每项技术中详细描述了运用该技术的具体步骤和流程。

ATT&CK模型是在洛克希德-马丁公司提出的Kill Chain模型的基础上,构建了一套更细粒度、更易共享的知识模型和框架。现在经过几年的发展,整个矩阵内容变得丰富,被拆分为PRE-ATT&CK和ATT&CK for Enterprise,其中PRE-ATT&CK覆盖了Kill Chain模型的前两个阶段,包含了与攻击者尝试利用特定目标网络或系统漏洞进行相关操作有关的战术和技术。ATT&CK for Enterprise覆盖了Kill Chain的后五个阶段。

ATT&CK for Enterprise将网络安全事件划分为12个阶段。初始访问阶段、执行阶段、持久化阶段、提权阶段、防御规避阶段、凭证访问阶段、发现阶段、横向移动阶段、采集阶段、命令与控制阶段、渗出阶段、影响阶段。攻击手法和各阶段的映射关系如下图所示:

2、ATT&CK的能力

ATT&CK知识库被用作在政府以及网络安全产品和安全服务中开发特定威胁模型和方法的基础。同时也可用来检测EDR产品是否具备侦测APT的能力。现在主要被应用在模拟攻击、评估和提高防御能力、威胁情报提取和建模、威胁评估和分析四大方向上。

1、模拟攻击:基于ATT&CK进行红蓝攻防演练,进行红蓝军建设 ;

2、检测分析:基于具体的”技术“,有效增强检测能力,用于甲方安全建设;

3、威胁情报:使用ATT&CK框架来识别攻击组织,用于安全情报建设;

4、评估改进:将解决方案映射到ATT&CK威胁模型,发现并弥补差距,用于评估安全能力。

ATT&CK框架内整合的知识库为安全行业提供了一个标准,对已知的TTPs进行收集,促进安全产品的优化改进。本文将从 TTPs 的检测、分析提出关于 ATT&CK 框架在提升主机EDR检测能力的探索和思考。

3、ATT&CK落地环境

本文将要探讨的是ATT&CK框架在终端安全产品的落地和应用。ATT&CK的出现为终端安全产品的检测能力提供了一个明确的,可衡量,可落地的标准,改变防守方以往对于入侵检测常常会陷入不可知和不确定的状态中,有效的弥补自己的短板,通过检测攻击的技术,映射到ATT&CK的战术,清晰的了解攻击者所处攻击阶段。

另外如果能让终端安全产品具有针对TTP的检测能力,无疑能增强安全产品的核心检测能力,提高攻击检测的覆盖度和自动处置的精确度,避免被攻击者通过一些简单的变形绕过检测,因为针对TTP进行检测,意味着我们是在根据攻击者的行为进行检测。如果攻击者想要躲避检测就需要改变他们的行为,这需要研究一些新的技术和攻击手段,这意味着更高的难度和付出更大的成本。

而所有的攻击检测都是基于数据源和策略的特征匹配。我们如果需要检测某个攻击技术,首先需要获取到这项技术所对应的数据,这些数据就是当攻击者执行某项技术攻击主机或网络后,在主机或网络设备上留下的蛛丝马迹,他们所呈现的形式往往是各种日志,可能是系统或应用内置的日志,也可能是因为安全需要而特意录制的日志数据。在MITRE ATT&CK的每项技术描述中都有对应于该技术的数据源信息,它告诉我们可以从哪些类型的数据中找到攻击技术实施后所留下的痕迹。

4、数据分类

通过在STIX 2.0 GitHub存储库中,调用与ATT&CK对象和属性映射的STIX对象和属性,对数据源进行分析统计,共有59种。

下图是通过对每个数据源能检测的技术数量进行统计,并获取检测数量前十的数据源排行。

5、技术选择

除了检测数据源的获取,针对不同技术点的检测也有难易程度之分。场景复现时,有些只需要执行系统命令,公开工具,而有些是需要特制、专用工具,检测从常见命令程序监控,到深入系统内核调用,进程上下文监控。

(网图:检测攻击技术的难易表)

以及同一个工具不同的命令、不同形式的使用,可映射不同攻击阶段的不同技术,检测的技术点也是不一样的。以下为分析mimikatz工具映射的TTP。

三、Sysmon

1、Sysmon介绍

Sysmon是微软的一款免费的轻量级系统监控工具,最开始是由Sysinternals开发的,后来Sysinternals被微软收购,现在属于Sysinternals系列工具(带有微软代码签名)。它通过系统服务和驱动程序实现记录进程创建,网络连接以及文件创建时间更改的详细信息,并把相关的信息写入并展示在windows的日志事件里。经常有安全人员使用这款工具去记录并分析系统进程的活动来识别恶意或者异常活动。

Sysmon安装后分为用户态系统服务,驱动两部分,用户态通过ETW(Event Tracing for Windows)实现对网络数据记录,通过EventLog对驱动返回的数据进行解析,驱动部分则通过进、线程,模块的回调函数收集进程相关的信息,通过Minifilter文件过滤驱动和注册表回调函数记录访问文件、注册表的数据。

2、选择理由

从功能上来讲,Sysmon一旦安装在系统上,在驻留系统期间,可以监视系统活动并将其记录到Windows事件日志中。 与一般检测工具相比,Sysmon可以执行系统活动深度监视,并记录高级攻击的高可信度指标,是一款优秀的HIDS、EDR的主机入侵检测引擎。

稳定性方面超过大部分自研的驱动,功能完善,对性能影响较小,虽然功能强大但却有很多监控盲区。若加以自研Agent与其配之,便可弥补自身监控盲区及非查询功能等其他需求。

接下来的针对ATT&CK的技术检测主要依托sysmon的监控,测试从终端捕获事件数据进行分析。后面我将向您展示如何安装sysmon以及如何使用自定义配置来过滤噪声并获得威胁特征。

3、搭建环境测试

执行sysmon程序进行安装,用于生成日志监测数据。

模拟攻击环境,编写批处理文件,执行minikatz恶意程序(可用于从内存获取明文密码、黄金票据和****等)。

安装winlogbeat产品,帮助我们将Windows事件日志实时流式传输到我们的ELK存储。

打开winlogbeat.yml文件编辑其收集的日志类型。在-name:System后添加以一行:-name:Microsoft-windows-sysmon / operational

进行winlogbeat的配置测试,执行.\winlogbeat.exe -c .\winlogbeat.yml -configtest -e。测试正常后,开启服务,执行start-service winlogbeat。

处理遭受攻击后捕获系统监测数据,可用于二次分析处理。

建议优先考虑您在环境中当前可能看到的内容,而不是仅选择矩阵中的任何技术。例如,如果您的环境中正在运行Sysmon,并且正在收集“ ProcessCreate”事件,则可以优先考虑需要将“ Process Monitoring”或“ Process命令行参数”作为数据源的技术。

四、分析过程

在本文中,主要探讨通过利用minikatz技术来利用获取hash凭证或者传递的过程,这一类技术主要是通过命令行参数检测及程序运行上下文相关调用进行监测,然后通过对其特征进行提取,分析如何有效降低数据噪声,并模拟测试命令执行建立会话进行验证,不断提升工程化实施检测的效果。

以下通过调用系统API接口实时监测系统命令行程序调用接口,通过匹配命令行参数特征,模拟检测恶意攻击。

但是单纯通过匹配命令行参数特征,虽然能够匹配一定的攻击事件,但是也存在被容易绕过的现象。

1、Sysmon工具分析

我们可以借助Sysmonview 这类工具可以很好的将攻击者的行为,恶意程序执行过程完整呈现出来。有助于行为分析,特征提取。由下图可以分析,mimikatz执行过程中先后加载了cryptdll.dll、samlib.dll、hid.dll、WinSCard.dll、vaultcli.dll等动态链接库,并访问了系统lsass.exe进程。

但是被调用的这些dll是不是只有mimikatz才会调用的程序,是不是存在噪声,还是无法确定,可能存在某些程序也需要调用这些dll文件,还是需要进一步分析确认。

2、Sysmon数据平台分析

面对海量的数据日志,我们需要有个大的数据平台,进行分析,了解主机,进程、文件、网络、驱动、注册表、管道等一系列对象间的关联关系,分析比对,筛选出符合某些攻击技术的能够识别的最小唯一特征。

3、Sysmon规则分析

通过行为分析,初步提取特征后,我们可以通过sysmon规则进行特征匹配。

ATT&CK技术编号T1003-凭证转储可通过以下sysmon规则配置,进行监测。

或者通过yaml规则,进行配置检测。

在系统日志检测,结果成功捕获minikatz相关运行信息。

因为使用bat脚本来运行minikatz程序,所以下图显示命中技术T1036-混淆攻击的检测规则

像Mimikatz这样的凭证转储程序可以直接通过本地二进制程序文件执行,也可以通过Powershell直接加载到内存中运行,并从内存中读取其他进程的数据。分析查找这类程序时,可进一步分析提取进程请求特定的权限以读取LSASS进程的部分,用以检测何时发生凭证转储。辨别Mimikatz与其他程序使用的常见访问模式。

常见的Mimikatz GrantedAccess模式。

这些特征特定于Mimikatz当前版本的工作方式,因此对于Mimikatz的将来更新和非默认配置都是不可靠的。

EventCode=10

TargetImage=”C:\\WINDOWS\\system32\\lsass.exe”

(GrantedAccess=0×1410 OR GrantedAccess=0×1010 OR GrantedAccess=0×1438 OR GrantedAccess=0x143a OR GrantedAccess=0×1418)

CallTrace=”C:\\windows\\SYSTEM32\\ntdll.dll+*|C:\\windows\\System32\\KERNELBASE.dll+20edd|UNKNOWN(*)”

| table _time hostname user SourceImage GrantedAccess

以下是编号T1003凭证访问阶段战术凭证转储技术映射更细粒度多个子技术的sysmon配置语句。

以下为系统检测到键盘记录器创建文件的行为,可以通过检测异常行为,提升检测攻击的能力,发现主机侧更多的安全问题。

五、Sysmonhunter分析

利用Empire工具进行模拟测试,Empire是一款内网渗透测试利器,其跨平台的特性类似于Metasploit,有丰富的模块和接口,用户可以自行添加模块和功能,是针对PowerShell 利用较好的平台。

通过对终端监测的数据进行特征匹配处理,并将结果推送到Elasticsearch数据库,查看数据的录入情况。

通过分析查看dll的调用次数,分析文件是不是存在被正常程序调用的情况。

分析某些dll是只被某些程序调用,或是某些操作必须调用的过程,需要逐个分析,判断能够被当成特征工程的一个指标。

通过导入图数据库进行关联分析,蓝色表示程序,红色表示调用过程,黄色表示节点,绿色表示终端编号。

六、实际应用

结合产品进行检测,通过抽象提炼,完成了适当的分类,将攻击者的行为和具体的检测方式联系起来。通过抽象提炼,形成一个通用检测方法,让产品可以检测单项对抗行为及其目标。

1、单点测试

·测试框架应用

Atomic Red Team是一个简单测试库,每个安全团队都可以执行此测试来测试安全产品的检测能力。该测试库是映射到MITER ATT&CK框架的小型、高度可移植的检测测试框架。每个测试旨在映射特定的策略。

以下通过该交互式测试框架,检验EDR的检测能力。

任何攻击者进入内网最想要的是窃取尽可能多的凭据。如果他们能用凭证登录其他系统,就没必要在通过研究其他资产尚存的漏洞,进行测试攻击,所以主机凭据获取,历来都是兵家必争之地,不管是渗透测试、红蓝对抗还是护网行动,得凭证者得天下。故以下选取相关凭证获取相关攻击的应用检测。

·卷影副本操作

vssadmin用于创建/删除Windows驱动器的卷影副本的命令。卷影副本简单理解就是备份,您可以创建卷影副本备份和完全相同的文件副本。例如,以独占方式打开的数据库以及由操作员和系统活动打开的文件都可以通过命令在创建卷影副本过程中备份。可以使用卷影副本将SAM文件导出,配合SYSKEY利用mimikatz等工具获得NTLM Hash。也可以利用VSS卷影副本拷贝ntds.dit,ntds.dit是AD(活动目录)中的数据库文件,包含有关活动目录域中所有对象的所有信息,其中包含所有域用户和计算机帐户的密码哈希值。

以下是产品依据程序hash及进程行为分析后的检测情况。

·Mimikatz

mimikatz是法国人Gentil Kiwi编写的一款windows平台下的神器,它具备很多功能,其中最亮的功能是直接从 lsass.exe 进程里获取windows处于active状态账号的明文密码。mimikatz的功能不仅如此,它还可以提升进程权限,注入进程,读取进程内存,hash传递等等

以下是产品依据程序hash及进程行为分析后的检测情况。

·Procdump

Procdump是Windows工具包里的一款工具,由于有微软的官方签名,所以大部分杀软不会查杀。通过procdump导出lsass.exe的内存文件,在用mimikatz.exe在本地读取内存文件提取密码。

以下是产品依据程序hash及进程行为分析后的检测情况。

·Ntdsdump

Ntdsdump是NTDS.dit(活动目录数据库)密码快速提取工具,可通过从域控制器上导取的ntds.dit文件以及SYSTEM文件,离线获取域控制器上所有hash的神器。

以下是产品依据程序hash及进程行为分析后的检测情况。

2、场景测试

·勒索检测

模拟执行勒索程序后,通过提取行为特征,hash比对,匹配特征库,检测异常告警。

最终通过自动分析判定主机正遭受勒索病毒攻击。

七、持续演进

1、ATT&CK细化子攻击的粒度

虽然ATT&CK提供了一套系统的理论指导,但仍任然不能解决具体的检测点技术问题,没有描述技术的特定实现的方法。对于某些技术描述还是比较笼统,对于检测安全产品的检测覆盖率还是不够。ATT&CK的广度问题目前已经基本解决了,往后发展就是不断增加深度,不是一个测试用例就算覆盖一个指标了,而是一组测试用例可以验证一个指标的深度。

近期ATT&CK组织为了增强框架结构,开始对整个框架进行调优和重新设计,细化描述攻击技术的粒度,提出了子技术概念。子技术是一种更详细地描述技术的特定实现的方法。后期可以在技术列表中,查看可以执行技术的各种方式。例如凭据转储就是一个很好的例子。

在“凭据转储”的技术中,可以执行该操作的方式共计9个,例如Windows SAM和“缓存的凭据”。尽管最终结果每次都是相似的,但很多不同的行为都集中在一种技术中。对于子技术,我们将对其进行拆分,并拥有一种顶级的凭证转储技术,其下具有九种子技术,以更详细地介绍这些变化,以了解它们如何以特定方式应用于各个平台。

子技术将从.001开始,并随着每个新的子技术递增。例如,访问令牌操纵仍将是T1134,但是“令牌操纵/盗窃”将是T1134.001,“使用令牌创建进程” T1134.002,等等

对子技术所需的技术的进行深入分析,导致战术和技术之间归属位置的调整。可能会删减了一些不适合该策略核心定义的技术,例如“ 隐藏文件”和“目录”不适合“持久性”,以及一小部分需要弃用的技术,例如“ Hypervisor”,在该系统中,我们发现没有证明的用例概念。以及技术降级到子技术的调整。例如,由于我们添加了“ Pre-OS Boot” 技术,因此将现有的Bootkit技术作为其子技术移至其下方。

以下是将旧技术映射到新子技术的对应表

2、攻防检测对抗

ATT&CK在持续更新升级,攻击者也在不断寻找更隐蔽的方法,绕过传统安全工具的检测,因此防御者也不得不改变检测和防御方式。

就像上面我们用于入侵检测的sysmon检测引擎,很多人在安装Sysmon的过程中直接使用默认配置,不更改文件名、服务名、驱动名,在攻击者发现主机环境装有Sysmon后,通过对现有规则及对环境分析,结合具体情境使用绕过及阻断方式组合技术,可轻松突破Sysmon日志记录。所以防御方需要对sysmon进行隐藏,否则将影响对攻击者TTP检测,及入侵行为检测。

从战术、技术和过程(TTPs)的攻击层面分析,现在攻击者使用工具,往定制化、模块化、无文件落地发展,可绕过大部分传统的安全防护设备。例如以下工具运行不带任何参数可直接转储lsass.exe的内存。

这就需要依托安全厂商投入研究,研究分析得越透彻,攻击者绕过的难度就越高。尤其是针对现有的TTPs的研究,研究如何精确匹配攻击事件,我觉得这也是未来的趋势,往精准化检测前行,否则安全分析人员,将被淹没在各种设备海量的告警中,剪不断理还乱,当然这是个持续的过程,在攻防对抗中不断升级,不断演进。

3、大数据智能平台分析

往更深层次上讲,如果仅仅只为了发现特定的已知攻击行为而进行的检测会是什么样场景?一个新的特征,一个新的告警,一个新签名,一个接一个!是的,这很可能是作为安全分析师在每天工作中所经历的对于威胁的检测分析处理。我们是否想过,通过由几个开源框架组成的生态系统,自研启用高级分析功能来增强威胁检测能力,通过赋能机器学习,构建大数据智能分析平台,进一步发展根据数据做出预测或建议的分析技术,解决检测已知的威胁,通过关联分析,挖掘未知的威胁,提高检测率。

八、小结

随着 ATT&CK 框架的不断完善和延伸,应用的方向也会更广。就目前阶段,我们认为深入分析 ATT&CK的TPPs 能提高主机EDR产品对于入侵行为的检测和分析。ATT&CK是一个非常庞大的框架,我们将致力于实战,从多维度深入研究,不断提高检测的广度和准确率。欢迎对ATT&CK感兴趣的安全爱好者和我们一起交流讨论。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

前言

国内云计算技术目前已经较为成熟,进入了高速增长的阶段,利用云计算技术进行信息化建设已成为常态。目前国内多数用户还处于“混合云”场景下,即传统主机环境+内部私有云环境+公有云环境+容器环境(根据业务情况)。这种混合云场景衍生出了安全运营需求升级、所有权和控制权转变等问题,形成了管理机制的变化并引出安全责任共担机制等挑战。

近年来,随着网络攻防向攻击方倾斜,各类高危漏洞(0day、1day、Nday)快速武器化,APT定向攻击泛滥,勒索和挖矿(变种、难于检测发现)病毒肆虐猖獗,还能躲避基于规则式安全设备(软件)检测的新攻击技术手段,以及针对东西向的流量攻击等新增威胁,依靠防病毒手段实现的传统环境下主机安全解决方案已然无法有效应对云环境下面临的新安全挑战和安全威胁。如何进行有效的安全管理成为这些行业用户普遍关注的重要问题,并且在国内大规模攻防实战演练的推动下,这部分的安全需求显得尤为迫切。

面对这样的安全场景需求,我们年度安全报告用“云工作负载安全”来替代“主机安全”的范畴,以符合目前大部分行业用户进入混合云泛主机形态的IT场景。我们对“云工作负载安全”这类技术定义如下:

云工作负载:云计算场景下用来承载计算的工作节点,包括了传统服务器主机系统、虚拟机、私有云计算节点、公有云主机、Docker容器节点以及微服务等。

云工作负载安全:针对云工作负载的安全解决方案,能够在漏洞风险、入侵威胁监测、主动防御、快速响应以及安全管理等方面为云工作负载提供全面的保护。

在本年度安全报告中,我们通过“云工作负载2019年安全技术新特点”、“云工作负载2019年安全威胁分析”、“云工作负载安全产品在大型攻防演练中的价值”、“云工作负载未来技术发展趋势”4个章节来进行详细阐述。

一、云工作负载安全(泛主机安全)2019年技术新特点

CWPP(云工作负载安全平台)自Gartner2017年提出以后,每年都有不小的变化,在2019年,Gartner对工作负载(workload)进行了新的诠释,根据抽象度的不同分为物理机、虚拟机、容器和Serverless,安全能力图也从原来的11个能力删减到8个能力,并且将最底层的“运维习惯”与“加固、配置与漏洞管理”进行了整合,同时删掉了“蜜罐”能力,此外,由于数据的静态加密大部分情况下都有云厂商提供,因此“静态加密laas数据”这个能力也从能力金字塔中删掉了。值得注意的是,能力图加强了对威胁检测和响应的要求,也就是更加凸显了Server EDR能力的重要性。

image.png

通过参考Gartner最新更新的CWPP(云工作负载安全平台)中的技术要求,以及结合众多大型客户场景化和应用实践方案,总结了2019年以下技术新特点:

·SERVER EDR的技术产品应用

·主动防御技术在工作负载中的应用

·基于轻量Agent的微隔离技术应用

·漏洞主动发现及安全配置管理

·主机安全大数据分析能力

二、云工作负载安全(泛主机安全)2019安全威胁分析

1、云工作负载安全漏洞和补丁修复趋势

2019年,大量操作系统、虚拟化平台、容器等各种云工作负载的安全漏洞被披露,相关问题应该引起重视。

根据安全狗海青实验室对2019年公开的各类漏洞数据的整理结果显示,2019年全年共发布主机操作系统漏洞数量1086个,主流虚拟化平台(VMWare、Xen、VirtualBox、Hyper-V、QEMU)漏洞166个,容器( Docker)漏洞13个。

2、入侵威胁趋势

·暴破攻击事件数量居高不下

在黑客入侵手法中,暴力破解是技术成本低,成功率高,性价比较高的一种攻击手法。只需要有高质量的用户名和密码字典库即可借助暴破工具轻易实施攻击,且一旦暴破成功后就能获得极大的权限,倍受各类网络攻击者的喜爱。

·挖矿与勒索病毒热度不减

臭名昭著的网络安全威胁加密挖矿与勒索软件在今年依然保持活跃。勒索软件的攻击目标从“遍地撒网”演变成了“重点捞鱼”,高价值目标成了网络罪犯眼中的香饽饽,越来越多的定向攻击出现,特别是针对企事业单位。挖矿病毒攻击则更偏向于与僵尸网络结合,部分挖矿病毒携带传播模块,核心目的在于感染更多的用户电脑,尽可能将利益最大化。

·Webshell威胁形势依旧严峻

网站Webshell的检测和防护是一个老生常谈的问题了。2019年全年,我们不仅在Web防护端发现大量扫描Webshell和上传Webshell的行为,在主机内部也扫描出不少Webshell木马。据统计,安全狗全年共扫描出Webshell文件2,275,350个,通过云御(网站安全狗)拦截到的Webshell上传行为共24,424,837次,拦截针对Webshell的扫描行为14,545,681次。

image.png

·工作负载间的横向渗透攻击手段层出不穷

攻击者一旦进入到目标网络后,下一步就是在内网中进行横向移动,然后再获取数据。近年随着容器的大量使用,攻击者在云主机横向移动的基础上,增加了容器间横向移动的攻击形态。

·工作负载越权控制访问威胁种类繁多

越权控制访问也是攻击者进行内网横向移动中关键的一环,在新的网络环境下,存在主机层面提权、云主机虚拟化逃逸、容器到宿主机层的提权。

三、云工作负载安全(主机安全)在大型攻防演练中的价值

在近年兴起的红蓝对抗演练中,云工作负载安全保护平台起着相当大的作用。

红方视角

从外到内:从外部对蓝队暴露的攻击面发起实战化攻击。

从内到内:攻击者已突破到内部,进行内网平移和漫游。在内网中各个区域(如:业务区、办公区、生产区)寻找有价值的资产,对其进行攻击。

从内到外:属于后渗透阶段。该阶段指的是红方在拿下蓝方的内网主机权限后,对该机器权限的维持和渗透的”成果化”。此时红队一般会使用反弹shell、隐蔽隧道等方式回连自己的服务器地址。

蓝方视角

在上述攻防演练红方视角中,红方利用实际漏洞、风险隐患达到权限获取目的。针对于外到内、内到内、内到外三个对抗节点云工作负载安全起着重大的作用,主要从四个维度解决云工作负载安全防护问题。包含:

检测:僵木蠕病毒、风险缺陷检测、进程账号文件等行为

防护:系统层、网络层、应用层、数据层的安全保护

运营:补丁漏洞管理、资产配置管理、通讯流量可视化、合规基线核查

响应:全网分析溯源、危急事件处置

四、云工作负载安全(主机安全)技术发展趋势

1、容器安全

毫无疑问,容器是当前云计算的主流技术之一。Docker是当下容器技术的主流选择(2019年的市场占比达79%)。它与DevOps理念不谋而合,受到了企业推崇。然而,在“Docker容器的全生命周期”中存在诸多安全问题,下面对其中的重要管控点及相应的管控方法进行介绍。

2、微服务安全

随着互联网飞速发展,传统的“单体架构”在面对持续改进、快速部署等需求时显得力不从心,而“微服务架构”作为一种系统解决思路应运而生,方兴未艾。

单体架构与微服务架构的部分区别如下表所示。可推知,后者在解决一些复杂问题时放大了攻击面,引入了一些安全隐患。

image.png

为规避这些安全隐患,须从“安全开发”和“安全运维”两方面着手。

微服务架构伴随着软件架构的需求应运而生。这类Web应用所面对的安全问题也与传统单体应用有着异同点,对甲方的安全开发和安全运维以及乙方的安全产品研发和落地提出了新的要求和挑战。

3、ATT&CK在Server EDR中的应用

ATT&CK模型由MITRE公司在2013年提出, 并于2015年发布了第一款框架。其目的在于了解攻击和划分攻击类别,以确定对手如何运作,以及如何对主动攻击做出响应和攻击后的恢复。

·威胁狩猎

MITER ATT&CK是基于真实环境观察攻方战术和技术的知识库,ATT&CK框架可以应用于提高EDR产品的威胁捕获检测能力和处置能力。

·产品能力评估

使用MITER ATT&CK框架评估终端安全产品的能力,量化安全产品对于威胁的检测率以成为新一代的潮流。目前国外的部份厂商已经支持对ATT&CK框架中的部份TTP进行检测和发现。

对主机安全厂商而言,由于ATT&CK是以开源社区的方式运作,其攻击工具库会持续更新扩充,可以针对ATT&CK工具集中的相应工具进行测试并提升安全产品的检测能力。对于甲方而言,可以根据其ATT&CK情报集扩充自身的情报库数据以提升对攻击组织的发现能力与对安全产品的检测评估。2020年ATT&CK将成为所有安全专家用来了解和抵御攻击者发起攻击的必要工具。

报告全文可至右方链接免费下载:

https://pan.baidu.com/s/1YEUbsS18GL6-2Gnu00NSDQ

*本文作者:安全狗,转载请注明来自FreeBuf.COM

什么是微隔离?

随着云计算、虚拟化技术的快速发展,越来越多企业将数据与业务迁移到云计算环境。包含有敏感数据和业务的云计算工作负载,在云环境下网络边界变得模糊,传统防火墙、WAF、IPS等端点安全和网络安全手段在云环境下显得捉襟见肘。

云环境中南北向的数据通过防火墙的策略规则可以做到网络隔离,而东西向的数据,就会绕开防火墙。在过去,主要通过防火墙、虚拟本地网和访问控制列表做网络隔离。传统防火墙,一般是在防火墙上线部署的时候配置上相应的策略、防火墙隔离、策略的管理和隔离的动作都是发生在防火墙设备上的。在整个防火墙的生命周期内基本不做调整。这就导致传统防火墙隔离有以下几个缺陷:

(1)基于防火墙配置:策略的管理和隔离的动作都是发生在防火墙上,需要单独配置。

(2)极难维护:防火墙策略配置后,在整个防火墙生命周内基本不做调整。

(3)无法自适应防护:无法根据变化的网络环境,实时更新策略。

(4)业务和安全不可兼得:要安全,业务就无法快速交付;要业务就无法进行有效的安全管理。

(5)成本高昂:在每个交错的节点都搭建防火墙,增加成本,降低敏捷性。

面对这些困境,CWPP则成为云安全的关键环节。CWPP(云工作保护平台)是Gartner在2017年提出的基于主机安全的解决方案,作为一种专门针对服务器云工作负载的方案,它和网络边界上部署安全产品不同的是,云工作负载安全平台部署在操作系统层,因此可以横跨物理机、公有云、私有云、混合云等多种数据中心环境,部署方式更加灵活,更重要的是能够识别和处理云环境下东西向的网络流量,防护层面更加丰富。

Gartner2019年《云工作负载保护平台市场指南》数据显示,2018年35%的服务器工作负载已采取应用管控来取代杀毒软件,预计到2022年,这一比例将达到60%。2019年CWPP产品能力金字塔模型中,网络防火墙、可视化和微隔离作为核心工作负载保护策略。

2019年CW彩色文字PP产品能力金字塔

随着CWPP解决方案的提出,微隔离应运而生。与传统网络隔离最本质的区别在于微隔离系统的集中化和自动化。

集中化:微隔离把策略从每一个分散的控制点上给拿出来了,放在一个统一集中的地方进行设计,管理和维护。

自动化:安全管理者不必要了解下面的控制点在哪里,也不必再对每一个控制点进行策略配置和维护,这些工作都将由策略管理中心来自动完成。

微隔离如何设计?

设计理念

为了更好适配现代企业网络隔离的新需求,一种基于CWPP技术方案,通过在公有云、私有云、混合云模式下的服务器工作负载安装Agent,采集工作负载与工作负载之间的网络流量,并以可视化展示网络访问关系,根据业务需求设置访问控制策略的方案可能更为合适。

逻辑结构如下:

为实现主机动态策略管理及系统自适应,这个系统应该具备两大核心功能:

流量可视化

通过安装Agent采集上报网络访问流量日志,云端接收到访问流量日志后,展示在可视化界面。流量可视化作为设计规则策略的依据,可自动生成策略,进行业务分析,使得业务分析更加灵活和简便。

流量访问控制

用户在云端自定义微隔离策略规则,云端对规则进行计算处理后下发至Agent,agent将访问控制策略配置到防火墙策略中。

微隔离场景化解决方案

1)大型行业解决方案:

用户特点:极为重视安全,例如央企制造业,金融行业等。

解决方案:通过采用微隔离技术作为替换性技术在云计算环境下继续提供白名单的管理能力。业务系统通过微隔离“定义”白名单来进行网络策略管理的。

2)大型云计算行业解决方案:

用户特点:大规模云计算环境业务系统间进行隔离变得十分困难。VPC等能力随着体量的增长和变化频度的加快可用性变低。多种底层技术架构混合,使行业很难找到一种跨越所有技术架构的方式。

解决方案:采用微隔离技术在云计算环境,对混合云、多云条件下实现内部流量统一监控、安全策略统一管理,通过统一的业务流量拓扑,实现不同地点环境的主机安全管理。完成其业务隔离,区域隔离需求。

3)高安全需求行业解决方案:

用户特点:网络安全管理者对内部威胁防御重视。APT攻击以及勒索病毒的泛滥,南北向技术,外部攻击的防御已不能满足内部防御的需求。

解决方案:微隔离技术能识别、监控虚拟机之间、虚拟机与物理机之间的流量,发现内部的威胁,并对网络攻击在内部的横向行走进行防御。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM

一、前言

Docker通过把应用的运行时环境和应用打包在一起,解决了部署环境依赖等问题。它消除了编译、打包与部署、运维之间的鸿沟,有助于提高应用开发、运维效率。它与互联网企业推崇的DevOps理念不谋而合,已成为云计算的主流。

然而,在Docker容器的生命周期中存在着诸多安全问题。本文的主要内容是对“Docker容器生命周期”的安全问题及相应的改善方法进行浅析,希望这篇文章对业界有所补益,也希望各位读者予以批评指正!

二、浅析Docker容器生命周期安全问题

在Docker容器生命周期内的多个阶段均可能引入安全问题,本章将分模块对这些安全问题进行浅析。“Docker容器全生命周期安全管控”架构图 如图1所示。

5df9d19bdb5db.png

图1“Docker容器全生命周期安全管控”架构图

这张图片可以反映Docker对其核心——“镜像”的“Build, Ship and Run”(构建镜像、传输镜像与运行容器)操作;Docker的应用环境可被分为“非生产环境”和“生产环境”这两类。“非生产环境”与“Dev”(开发)强相关,而“生产环境”则与“Ops”(运维)强相关。“非生产环境”内的主要管控点是“镜像深度扫描”,在“生产环境”做容器编排时需要从“非生产环境”拉取并运行Docker镜像,因此“镜像运行控制”也是一个主要管控点。“生产环境”内的主要管控点是“容器系统入侵检测与防护”以及“容器网络入侵检测与防护”。同时,应在Docker容器全生命周期中的各个阶段将“合规基线问题”作为重要的管控点。下面从Docker容器安全的各个主要管控点出发,列举部分它们所应对的安全问题。

2.1 镜像深度扫描

在做镜像深度扫描时,应重视的安全问题包括但不限于:

镜像中的操作系统软件包与应用程序依赖项包含已知CVE漏洞

镜像的应用目录被植入Webshell

镜像敏感信息泄露

镜像完整性校验问题

Dockerfile中存在不安全的写法(Dockerfile是Docker镜像的构建脚本)

2.2 镜像运行控制

在做镜像运行控制时,应重视的安全问题包括但不限于:

镜像完整性校验问题

特权模式共享root权限

内存配额未被限制

CPU优先级未被限制

存储空间配额未被限制

在启用容器时使用Host网络模式

2.3 容器系统入侵检测与防护

在做容器系统入侵检测与防护时,应重视的安全问题包括但不限于:

未隔离文件系统

调用有漏洞的系统内核函数

拒绝服务攻击

2.4 容器网络入侵检测与防护

在做容器网络入侵检测与防护时,应重视的安全问题包括但不限于:

容器间的局域网攻击

Remote API接口安全

Docker缺陷架构与安全机制纰漏

微服务架构Web应用安全问题

2.5 安全合规基线

为了应对Docker安全问题,应重视的安全问题包括但不限于:

内核级别

网络级别

镜像级别

容器级别

文件限制

能力限制

2.6 Docker及其配套软件漏洞

在使用Docker及其配套软件时,应重视的安全问题包括但不限于:

Docker自身漏洞

K8S(Kubernetes)等编排应用自身漏洞

镜像仓库自身漏洞

注:Docker及其配套软件漏洞对Docker容器安全问题有着较深的影响,因而将之独立成一个管控点点。可将“所使用的Docker及其配套软件的版本不受已知漏洞影响”作为一条“安全合规基线”。

三、浅谈Docker容器安全现状改善方法

面对Docker容器安全的挑战,可以“分而治之”,对各个阶段的安全管控点进行管控。在实施管控时,也可划分优先级,优先考虑较为重要的管控点,推迟考虑较为次要的管控点(例如,“镜像运行控制”管控点与用户对Docker的使用方式有较大关联。可以在安全产品中对用户的危险操作进行告警,但不一定要进行阻断。Docker容器安全产品应注重对由用户的不安全使用方式催生的安全问题进行防御)。下面,结合行业实践经验梳理针对“镜像深度扫描”“容器系统入侵检测与防护”“容器网络入侵检测与防护”与“安全合规基线”的管控方法。

3.1 “镜像深度扫描”管控方法

在使用Docker镜像之前使用Docker镜像扫描器有助于发现Docker镜像的安全性问题。基于此,知名的开源镜像仓库Harbor就集成了镜像扫描器,如图2所示。

5df9d1988fcc5.png

图 2 知名开源镜像仓库Harbor集成了镜像扫描器

现有镜像扫描工具基本都具备了“对软件漏洞进行扫描”的基础功能。部分开源项目或商业平台具备如下特殊功能:

对木马、病毒、恶意软件或其他恶意威胁进行静态分析

对主流编程语言的代码安全问题进行静态发现(与开发工作流紧密结合)

对Dockerfile进行检查

对凭据泄露进行检查

因为Docker镜像是Docker容器的模板,所涉及的攻击面较大,并且有的安全风险不易被扫描器所发现,所以现阶段的“Docker镜像扫描”的做法仍不能保障Docker镜像的安全性,建议人工介入检查(可结合“docker inspect”与“docker history”等命令查看镜像的部分信息)。

3.2 “容器系统入侵检测与防护”管控方法

加强Docker容器与内核层面的隔离性有助于强化“容器系统入侵检测与防护”。比如Docker社区开发的安全特性、Linux运行时方案、异常行为检测应用以及“容器+全虚拟化”方案,如图3所示。

5df9d1983b279.png

图 3 “容器系统入侵检测与防护”管控方法

Docker社区开发了针对Linux的Cgroup和Namespce的安全特性(Cgroup可用于限制CPU、内存、块设备I/O(具体可参考“docker run”命令的参数);Namespace可用于对PID、mount、network、UTS、IPC、user等内核资源进行隔离;Cgroup对系统资源的隔离已经比较完善了,而Namespace的隔离还不够完善(甚至不可能完善,因为这是共享内核导致的固有缺陷)。

部分可借鉴的Linux运行时方案如下:

(1)Capability:令某程序拥有哪些能力;

(2)Selinux:定义了系统中每一个用户、进程、应用、文件访问及转变的权限,然后使用一个安全策略来控制这些实体(即用户、进程、应用和文件)之间的交互,安全策略指定了如何严格或者宽松地进行检查;

(3)Apparmor:设置执行程序的访问控制权限(可限制程序读/写某个目录文件,打开/读/写网络端口等);

(4)Secomp:应用程序的沙盒机制,以白名单、黑名单方式限定进程对系统进行调用;

(5)Grsecurity:linux内核补丁,增强内核安全性。

部分可借鉴的容器环境异常行为检测开源应用如下:

(1)Sysdig Falco:一款为云原生平台设计的进程异常行为检测工具,支持接入系统调用事件和Kubernetes审计日志

(2)cAdvisor:可以对节点机器上的资源及容器进行实时监控和性能数据采集,包括CPU使用情况、内存使用情况、网络吞吐量及文件系统使用情况

“容器+全虚拟化”方案也是“容器系统入侵防护”的有效方案,如果将容器运行在全虚拟化环境中(例如在虚拟机中运行容器),这样就算容器被攻破,也还有虚拟机的保护作用(目前一些安全需求很高的应用场景采用的就是这种方式)。

3.3 “容器网络入侵检测与防护”管控方法

Docker容器网络的安全问题可被划分为“网络安全防护”与“微服务Web应用安全”两类,“隔离”和“访问控制”等主要思路均有助于管控二者的安全问题。此外,仍可将部分现阶段较为成熟的安全技术应用到Docker场景中。在具体实施时,可依据Docker应用规模与实际的网络部署情况进行管控。分析如下:

Docker网络本身具备“隔离”和“访问控制”功能的网络安全机制,但存在“粒度较大”与“对安全威胁的感知能力不足”等缺陷,如图4所示。

5df9d19547814.png

图 4 Docker网络自身安全机制

为了弥补Docker网络的安全缺陷,一些商业化的端对端的Docker安全产品对网络集群进行了纵深防御,它们具备的功能特点包括了:

容器防火墙

运行时保护

网络深度数据包检测

攻击行为、异常行为告警

日志监控

多编排平台支持

网络流量可视化

部分厂商在实现上述功能点时,在产品中引入了机器学习方法,用于生成行为模式与容器感知网络规则。

Docker网络具有组网方案多样化、容器生命周期长短不一、应用场景多样化等特点。因而,应参照组网方案特点制定管控方法。笔者梳理的针对 “类传统单体应用”和“微服务架构应用”的入侵检测与防御思路如图5所示。

5df9d194603a0.png

图 5 Docker网络入侵检测与防护思路

首先来看 “类传统单体应用”的Docker网络集群的入侵检测和防护思路。以图6所示的微服务集群为例进行介绍。该集群里只有Nginx、Tomcat以及MySQL的3个容器。

5df9d19499a43.png

图 6 “类传统单体应用”的Docker网络集群的入侵检测和防护思路

注:图中的绿色虚线表示文件挂载或者Docker的cp命令等方式,通过这两种方式可以更便捷地在宿主机实时修改Nginx容器里的配置文件,调整Tomcat容器里的应用程序文件,或者对MySQL容器里的数据进行持久化。

为了对这套Docker Web应用进行入侵检测与防御,可考虑以下9点方法:

Iptables隔离

通过在宿主机侧对Docker网络集群外部做基于Iptables的隔离策略,可以限制攻击者对“容器在宿主机所映射端口”的访问,缩小受攻击面。

部署软WAF

通过在Docker网络集群的流量入口处做软WAF的部署(形态可以是宿主机软件或者Docker容器),可以在此处阻断、发现部分恶意流量。

部署RASP

通过在Java、PHP服务器Docker容器内部部署RASP产品,可以用之作为保护的最后一环,作为网络治理的一个补充小点。

Webshell扫描

通过在宿主机侧通过Webshell扫描引擎扫描来自Docker容器的“Web应用程序文件”(这些文件可通过“docker cp”命令或者“动态挂载”机制获得),有助于发现攻击者植入的Webshell。

日志分析

通过在宿主机侧通过ELK等日志分析分析来自Docker容器的日志文件(这些日志文件同样可通过“docker cp”或“动态挂载”等方式获得)。此外,单独运行Sidekick日志容器等做法有助于发现安全威胁。

识别中间人攻击

通过在Docker网络集群内部通过网络隔离是防止此类基于网络的攻击的有效方法,此方法可使得攻击者无法操纵或窃听主机及其他容器的网络流量;在这种情况下,OpenVPN(开放虚拟专用网络)提供了一种通过TLS(传输层安全协议)加密实现虚拟专用网络(VPN)的方法。

识别、阻断流向异常的流量

通过在Docker网络集群内部依据实际的网络拓扑图对网络进行“微分段”隔离(在“微服务架构”下,IP地址可能变换频繁,但是预先划分的网段不会变换频繁),或者对指定的网桥、网卡进行流量的DPI分析,有助于识别、阻断流向异常的流量。

识别拒绝服务攻击

通过在宿主机侧读取和Docker容器对应的cgroup文件系统相关文件的实时内容(网络、CPU、内存、磁盘),可以识别出拒绝服务攻击。

网络流量可视化

“网络流量可视化”是现有的“容器安全产品”的常见附加功能。该功能的功能可能依托于“对指定的网桥、网卡进行流量的DPI分析”。

接着来看“微服务架构应用”的Docker网络集群的入侵检测和防护思路。“微服务架构应用”与 “类传统单体应用”的显著区别包括了Docker容器数量较多、网络拓扑较复杂等方面。在这种生产场景下,K8S等平台可帮助用户进行大规模容器编排。可考虑使用的入侵检测和防护思路如下:

运用K8S原生或其第三方网络插件的网络策略

K8S原生的网络策略“NetworkPolicy”可为K8S的最基本操作单位“Pod”提供“IP地址/端口号”级

别的网络隔离。

注:K8S支持以“第三方网络插件”的形式选择网络方案,进而会影响网络策略的选择。例如,

NetworkPolicy须由实现了CNI接口的网络插件提供(如Calico、Cilium、Kube-route、Weave Net等等)。

关注微服务架构Web应用的接口“认证鉴权”问题

开发方应对微服务架构Web应用的认证鉴权等问题予以重视,降低接口被网络可互通的容器恶意访问的风险。常见的“认证鉴权”方案可包括:网关鉴权模式、服务自主鉴权模式、API Token模式。

以“组件化”的形式在微服务集群中部署Web安全应用

为了增加Docker网络集群的安全能力,可在Docker集群中部署Web安全应用(针对 “类单体Web应用”的做法仍可继续使用。比如,我司的网站安全狗可用于保护部署在Docker容器里的Web应用,如图7所示),此外也可考虑在容器集群中部署API网关容器(基于Nginx+Lua)、蜜罐容器或者资产发现与漏洞扫描器。

5df9d19729890.png

图 7 网站安全狗可以用于保护Docker容器

运用“Service Mesh”技术

Service Mesh(服务网格)技术弥补了K8S在微服务通信的短板,有助于对应用层做访问限制。服务网格是一个基础设施层,功能在于处理服务间通信,其主要职责在于负责实现请求的可靠传输。在实践中,服务网格通常实现为轻量级网络代理,通常与应用程序部署在一起,但是对应用程序透明。以开源应用Istio为例,它通过为整个服务网格提供行为洞察和操作控制满足微服务应用程序的多样化需求。它在服务网络中统一提供了流量管理、策略执行、服务身份和安全等关键功能。同时,Istio还可集成已有的ACL、日志、监控、配额、审计等功能。未来Service Mesh的融合架构模型如图8所示。

5df9d19575379.png

图8 未来Service Mesh融合架构

3.4 “安全合规基线”管控方法

为了应对Docker容器生命周期里的全问题,需要可操作、可执行的Docker安全基线检查清单,这个清单要清晰、可查、可维护,以供在生产环境中执行基础架构的安全检查和审计。

以下安全合规检查工具有较好的参考性:

docker-bench-security(与Docker官方及CIS推出的安全标准相配套,如图9所示)

Kube-bench(运行 CIS Kubernetes 基准测试,来检查 Kubernetes 部署的安全程度)

OpenPolicyAgent(将安全策略和最佳实践从特定的运行时平台解耦)

5df9d196713cd.png

图9 Docker-Bench-Security与官方白皮书配套

四、总结

经多年发展,Docker容器技术逐渐被接受并应用于DevOps和微服务等领域。然而在容器的生命周期内的多个阶段均可能引入安全问题。本文尝试对这些安全问题及相应的改善方法进行浅析。可以发现,为做好“Docker容器安全管控”工作,不应忽视镜像深度扫描、容器系统与容器网络的入侵检测与防护以及安全合规问题等环节。在面对上述环节时,可考虑借鉴、改造现有的网络安全技术。由于不同组织机构有着不同的Docker应用级别和技术选型,因而具体的实施方法会有不同。不同组织机构应结合自身情况,分阶段、分层(容器引擎层、编排调度层)选择适合的解决方案,以更好地保护Docker容器环境。

*本文作者:安全狗safedog,转载请注明来自FreeBuf.COM