如今,不可否认的是网络犯罪已逐渐进入人们的生活,为人们所重视。无论何时,随意浏览新闻都能看到新漏洞的发现,或者是敏感信息的泄露、窃取等。因此,任何企业董事会都应该尽早加强网络安全防御。

960x0 (3).jpg

然而,即使现在网络威胁来势汹涌,但是网络安全防御仍然不够。通常而言,当最佳安全实践有可能干扰业务效率或整体生产力时,业务优先级往往是高于安全优先级的。对于许多CSO和CISO来说,资金不足是另一个值得普遍关注的问题,董事会根本没有准备好,没有为他们提供真正需要的预算和资源,来确保他们的业务安全。

企业需要有长远考虑

在短期内,减少安全资金以促进业务的其他领域发展似乎是个好主意,但这是一个很大的风险,一旦高管人员也受到攻击,后果更加不堪设想。例如,尽管在年度预算周期内,额外拨出50万英镑作为新的安全资源投入似乎并不可行,但与数据泄露后面临的数百万英镑的罚款、法律费用和缓解费用相比,这显得相形见绌。

英国航空公司(British Airways)在其网站上称遭到“复杂的恶意犯罪袭击”之后,就被信息专员办公室(ICO)罚款1.83亿英镑,因为在此期间,约有50万名客户的详细信息泄露。

这样的例子强调了通过实施网络安全实践来确保长期安全性和合规性的重要性,这些实践首先能做的就是防止此类数据泄露。另一种更为主动的方法就是将网络安全实践整合到更广泛的业务策略中去,这可以大大减少数据丢失,并使安全团队能够更迅速、更准确地应对任何真实存在的威胁。

随着越来越多的组织依靠软件应用程序来发展业务,所以保护这些应用程序变得十分必要。因此,采用一种系统的、基于风险的方法在软件开发生命周期(SDLC)的早期评估和解决网络安全漏洞,而不是出现漏洞后才这样做。

业务和安全目标必须保持一致

安全方法与整个组织的方法结合才是最有效的。但是很多时候,一旦将安全性纳入SDLC会对开发时间或者发布窗口有不利影响时,便会被重新考虑。

当补救漏洞所需的时间威胁到重要应用程序的发布时,安全团队就会承受压力。如果不能通过令人信服的业务案例来推迟发布,并解决安全问题,那么风声将不胫而走。

risk-management.jpg

风险在有效安全决策中的作用

在上述情况下,安全团队需要能够迅速让高层决策者认识到所涉及的风险以及无法修复漏洞的潜在后果。这既需要对应用程序的预期业务目标有扎实的理解,又需要有以决策者能够理解的方式来构成论点的能力,而不是给他们一堆的安全术语。最好的方法之一是基于风险的方法,该方法有两个主要阶段。

第一阶段包括全面评估当前正在开发的所有Web应用程序,并建立严格的监视流程以快速识别漏洞。在此阶段进行彻底检查至关重要,因为如果只是遗漏了一个应用程序,或者一个系统没有安全保护,那么它将为网络罪犯创造一个新的潜在风险。

完成第一阶段后,便可以开始第二阶段,将业务影响纳入战略规划过程。通过正确定义特定漏洞可能造成的潜在损失,并帮助高级管理人员以通俗易懂的方式理解这些损失。不仅可以帮助满足对有效安全性的需求,还可以根据整个组织的风险级别对活动进行更精细的调整。

采用基于SaaS的方法进行应用程序扫描

在整个SDLC中采用基于SaaS的方法进行应用程序扫描,安全团队可以持续评估生产过程中的风险,而不仅仅是几个关键点。因此,当与业务活动优先级合理结合时,可以评估更为准确的风险状况,公司各层级也可以接受。

关于有效的安全性,对于安全团队来说,让整个组织企业理解是很重要的。采用基于风险的方法可以做到这一点,通常将复杂的漏洞和分析转换成对所有人,特别是对高级管理人员有意义的术语,有助于他们理解。然后进行适当的讨论,采取合理的、正确的决策,从而使整个公司受益,并使公司免受众多网络威胁的侵害。

*参考来源:Helpnetsecurity,Sandra1432编译,转载请注明来自FreeBuf.COM

企业组织必须采取一种“Security by Design”(安全设计方法),以最佳姿态应对物联网所带来的威胁。

毋庸置疑,物联网(IoT)和工业物联网(IIoT)的兴起为企业组织带来了新的发展机遇,但同时,它们也为企业组织带来了巨大的网络安全风险以及不断扩大的攻击面。然而,一项针对企业组织对其物联网设备的风险暴露情况进行的调查发现,许多公司仍未意识到使用连接设备时所面临的风险范围,并且对这些威胁的管理表现出非常滞后的状态。

安全专家建议,企业组织应该采取一种“Security by Design”(安全设计方法)来设计和部署物联网(IoT)和工业物联网(IIoT)产品。这种方法涉及默认将网络安全实践纳入产品的设计以及实施环境中。

Security by Design(安全设计)通过在构建产品的首个环节解决安全问题,达到节省时间并降低成本的效果。在一项针对各行业和职位的4,200多名专业人士的调查中,近一半(48%)的受访者表示,在开发或部署联网产品或设备时,必须将DevSecOps嵌入到整个生命周期中,而且团队在整个部署过程中都需要进行法律、采购以及合规性方面的工作。

十大物联网安全风险

以下是企业组织必须解决的当前物联网环境所产生的十大安全风险:

1. 没有安全和隐私计划;

2. 缺乏所有权/管理权来推动安全和隐私;

3. 安全性未纳入产品和生态系统的设计中;

4. 对工程师和架构师的安全意识和培训不足;

5. 缺乏IoT / IIoT以及产品安全和隐私资源;

6. 对用于检测安全事件的设备和系统监控不足;

7. 缺乏市场后监管/实施安全和隐私风险管理;

8. 缺乏产品可见性或没有完整的产品库存;

9. 识别和处理现场和遗留产品的风险;

10. 没有经验/不成熟的事件响应过程。

德勤会计师事务所(Deloitte&Touche LLP)网络风险服务的物联网安全负责人Sean Peasley在一份新闻稿中表示:

“安全性必须嵌入到运营计划的DNA中,以敦促企业创造出出色且安全的产品。如今,各种各样的产品正在成为网络的一部分:从烤箱到即时炊具,从3D打印机到汽车。企业组织必须考虑实际存在的问题,并将这些新挑战视为优先处理事项。”

如何创建物联网Security by Design(安全设计)

德勤公司公布的调查结果发现,许多企业(41%)表示,他们正在寻求行业和专业团体的指导,以便在其业务中创建安全设计。另有28%的受访者表示,他们期望监管实体和机构能够首先制定标准,而22%的受访者表示,他们已经在企业内部开展了自己的安全性做法。

德勤分析师表示,企业组织应该首先寻求了解同行的最佳实践和标准,然后再向监管机构寻求指导。

大约30%的受访者表示,他们没有使用过一套明确的产品网络安全要求,而只有28%的受访者表示,他们使用了行业定义的框架,41%的受访者表示,他们使用的是客户的框架,这表明行业在采用网络安全标准方面还有漫长的道路要走。

安全专家认为,对于寻求将设计安全性实施到物联网产品中的企业来说,需要考虑如下五个因素:

1. 了解产品安全性的当前状态并制定网络战略

无论是设计联网产品还是购买此类产品在内部实施,都必须要评估产品(包括其生产的数据)的保护方式,并制定网络战略以推动改进。

2. 建立安全设计实践

通过需求、风险评估、威胁建模和安全测试,将设计安全性集成到产品本身的设计或生态系统体系结构的设计之中。

3. 从顶层设定基调

确保合适的人员参与并拥有流程的所有权——从领导到相关的产品安全主题专家再到产品开发设计团队。

4. 拥有一支专业的团队,并为他们提供充足的资源

不要指望企业安全团队在缺乏任务资源的情况下能够顺利完成任务。建立一支专业的团队,该团队需要具备基于产品的经验,并根据需要为其提供培训,以帮助他们积累知识。

5. 利用行业可用资源

与其为您的设备供应商开发和提供独特的调查问卷,还不如使用公开的行业资源来得方便直接。

威胁不断加剧,你准备好了吗?

2020 年,随着 5G 部署持续推出,攻击也将接踵而至。无论何时,互联的东西越多,安全问题就越多。而让情况变得复杂的是,很多工业环境都部署着过时的遗留设备。恶意黑客将开始针对这些环境,带来严重后果,比如对配置的非授权修改——可致工业过程未按既定方式运转,因而造成工业事故、断电,甚至环境灾难。

没有哪个产品设计者会想创建出毫无安全性可言的联网产品。幸运的是,鉴于目前物联网安全所获得的关注度,情况正在不断改善。“Security by Design”(安全设计方法)也逐渐被行业认同并付诸实践中。

企业组织必须采取一种“Security by Design”(安全设计方法),以最佳姿态应对物联网所带来的威胁。

毋庸置疑,物联网(IoT)和工业物联网(IIoT)的兴起为企业组织带来了新的发展机遇,但同时,它们也为企业组织带来了巨大的网络安全风险以及不断扩大的攻击面。然而,一项针对企业组织对其物联网设备的风险暴露情况进行的调查发现,许多公司仍未意识到使用连接设备时所面临的风险范围,并且对这些威胁的管理表现出非常滞后的状态。

安全专家建议,企业组织应该采取一种“Security by Design”(安全设计方法)来设计和部署物联网(IoT)和工业物联网(IIoT)产品。这种方法涉及默认将网络安全实践纳入产品的设计以及实施环境中。

Security by Design(安全设计)通过在构建产品的首个环节解决安全问题,达到节省时间并降低成本的效果。在一项针对各行业和职位的4,200多名专业人士的调查中,近一半(48%)的受访者表示,在开发或部署联网产品或设备时,必须将DevSecOps嵌入到整个生命周期中,而且团队在整个部署过程中都需要进行法律、采购以及合规性方面的工作。

十大物联网安全风险

以下是企业组织必须解决的当前物联网环境所产生的十大安全风险:

1. 没有安全和隐私计划;

2. 缺乏所有权/管理权来推动安全和隐私;

3. 安全性未纳入产品和生态系统的设计中;

4. 对工程师和架构师的安全意识和培训不足;

5. 缺乏IoT / IIoT以及产品安全和隐私资源;

6. 对用于检测安全事件的设备和系统监控不足;

7. 缺乏市场后监管/实施安全和隐私风险管理;

8. 缺乏产品可见性或没有完整的产品库存;

9. 识别和处理现场和遗留产品的风险;

10. 没有经验/不成熟的事件响应过程。

德勤会计师事务所(Deloitte&Touche LLP)网络风险服务的物联网安全负责人Sean Peasley在一份新闻稿中表示:

“安全性必须嵌入到运营计划的DNA中,以敦促企业创造出出色且安全的产品。如今,各种各样的产品正在成为网络的一部分:从烤箱到即时炊具,从3D打印机到汽车。企业组织必须考虑实际存在的问题,并将这些新挑战视为优先处理事项。”

如何创建物联网Security by Design(安全设计)

德勤公司公布的调查结果发现,许多企业(41%)表示,他们正在寻求行业和专业团体的指导,以便在其业务中创建安全设计。另有28%的受访者表示,他们期望监管实体和机构能够首先制定标准,而22%的受访者表示,他们已经在企业内部开展了自己的安全性做法。

德勤分析师表示,企业组织应该首先寻求了解同行的最佳实践和标准,然后再向监管机构寻求指导。

大约30%的受访者表示,他们没有使用过一套明确的产品网络安全要求,而只有28%的受访者表示,他们使用了行业定义的框架,41%的受访者表示,他们使用的是客户的框架,这表明行业在采用网络安全标准方面还有漫长的道路要走。

安全专家认为,对于寻求将设计安全性实施到物联网产品中的企业来说,需要考虑如下五个因素:

1. 了解产品安全性的当前状态并制定网络战略

无论是设计联网产品还是购买此类产品在内部实施,都必须要评估产品(包括其生产的数据)的保护方式,并制定网络战略以推动改进。

2. 建立安全设计实践

通过需求、风险评估、威胁建模和安全测试,将设计安全性集成到产品本身的设计或生态系统体系结构的设计之中。

3. 从顶层设定基调

确保合适的人员参与并拥有流程的所有权——从领导到相关的产品安全主题专家再到产品开发设计团队。

4. 拥有一支专业的团队,并为他们提供充足的资源

不要指望企业安全团队在缺乏任务资源的情况下能够顺利完成任务。建立一支专业的团队,该团队需要具备基于产品的经验,并根据需要为其提供培训,以帮助他们积累知识。

5. 利用行业可用资源

与其为您的设备供应商开发和提供独特的调查问卷,还不如使用公开的行业资源来得方便直接。

威胁不断加剧,你准备好了吗?

2020 年,随着 5G 部署持续推出,攻击也将接踵而至。无论何时,互联的东西越多,安全问题就越多。而让情况变得复杂的是,很多工业环境都部署着过时的遗留设备。恶意黑客将开始针对这些环境,带来严重后果,比如对配置的非授权修改——可致工业过程未按既定方式运转,因而造成工业事故、断电,甚至环境灾难。

没有哪个产品设计者会想创建出毫无安全性可言的联网产品。幸运的是,鉴于目前物联网安全所获得的关注度,情况正在不断改善。“Security by Design”(安全设计方法)也逐渐被行业认同并付诸实践中。

前言

这次介绍的是一篇发表在安全顶会NDSS 2020上的一篇paper,其针对文件上传漏洞的场景,实现了一款动态fuzz的工具FUSE,并利用其发现了现有33个CMS的15 CVE。

背景介绍

首先提几个关键的缩写含义,对于漏洞分类上,可以大致为两类,即:

UFU:为Unrestricted File Upload的缩写,含义即任意文件上传。

UEFU:为Unrestricted Executable File Upload的缩写,含义即任意可执行文件上传。

但这两类可能有一个子集的包含关系,UEFU应该为UFU的子集,因为我们上传的文件未必是可执行的。

然后是对于上传的恶意文件,我们也可以分为两类:

CE:为code execution的缩写,含义即为代码执行。

PCE:为potential code execution的缩写,含义即为潜在的任意代码执行。

一类就是代码执行的文件,这个非常容易理解,比如我们常见的一句话木马,而潜在代码执行的文件,可以理解成js等,需要引入或者满足一定条件的触发才会让其产生威胁。

而至于文件上传漏洞,作为一种危害性大,案例多的web漏洞,应该大家都比较熟悉了。那么其出现漏洞的位置也是多样化的,例如后缀名过滤产生的问题:

2020-03-27-10-07-36.png

我们可以看到黑名单过滤产生了2个弊端:第一是黑名单中的后缀名可能会有遗漏,第二是此处黑名单匹配并未使用大小写通配,从而会导致大小写Bypass。

同样的,漏洞也可能会是Content-Type过滤产生的问题:

2020-03-27-10-08-11.png

例如上述代码中,我们看到其会对Content-Type进行过滤,而Content-Type并不能真实反映文件的内容,是可通过burp等抓包工具进行拦截修改的,所以同样会产生安全隐患。

那么对于文件上传出现漏洞的多样性,其实对攻击者的探测产生了一些麻烦,我们在黑盒的情况下或者在找到上传点的情况下,可能需要通过大量的猜测和探测才能找到正确的Bypass模式,但实际上很多时候这是一种低效率的行为,有没有可能有一款类似sqlmap的工具,来自动化的fuzz上传接口呢?于是便有了FUSE这款工具。

工具设计

我们首先看一下工具的架构:

2020-03-27-10-10-26.png

那么实际上该工具的重点就在于其如何产生有效的payload和验证payload的攻击是否生效,首先我们先看其如何有效的产生payload:

2020-03-27-10-18-13.png

我们注意到,在一次文件上传的请求里,其实有很多位置是我们可以进行伪造更改的,因此作者将常见的文件上传bypass技巧归纳为如下多种模式:

2020-03-27-10-16-35.png

比如M3更改content-type,M4更改文件名后缀等等,当然我们肯定存在后端检测文件上传时,既检测content-type,又检测文件名后缀的情况,因此作者会对其进行排列组合进行测试:

2020-03-27-12-22-53.png

测试的时候,假如我们选定的seed模式为M1、M2、M3,那么工具会生成如上排列组合的模式,依次进行探测,从第一不修改任何参数进行恶意文件上传,到按照M1M2M3模式修改所有参数进行上传,当然如果其中某一种上传成功,那么自然不会去尝试包含这一种修改的修改,例如:

2020-03-27-12-25-50.png

当M1测试后,如果M1测试成功,我们的恶意文件已上传,那么则不会去尝试M1M3的组合,因为没有意义,其应该一定为成功。

当然这里可能涉及到相互冲突的问题,假设M1M3一起修改,可能会有冲突,所以考虑到这样的问题,工具也会进行筛选操作,例如M1和M2一起会产生冲突,那么M1M2和M1M2M3这两种排列组合不会进行组合修改。

2020-03-27-12-24-29.png

了解了payload的生成方式,我们再来看一下如何获取恶意文件上传后的路径,以用于检测是否攻击成功:

2020-03-27-10-16-00.png

工具有相应的config文件,其可以指定上传成功后的路径前缀,或者response里的路径url,以此正则去提取上传后的文件路径。当然作为一种修复文件上传漏洞的方案,常看见到文件名更改和路径的隐藏,上传者无法知道文件传到了何处,其文件名是什么。那么对于这一种情况,作者使用了一个文件监视器:

2020-03-27-12-30-26.png

该监视器运行在攻击目标服务器上,时刻监视该服务器上的文件创建。也是因为这一点,我个人认为FUSE可能更像一款动态fuzz的漏洞发掘工具,而非一款典型的渗透测试工具,因为这一需求我们在渗透测试中是肯定不会满足的,如果都有目标服务器的控制权限了,那么也没必要进行攻击了。所以这款工具的目标,更像去挖掘一些开源现有cms的文件上传漏洞。

然后是工具的运行逻辑:

2020-03-27-10-16-13.png

这就比较清晰了,即排列组合上述的payload,然后进行不断的上传测试,通过访问上传后的路径,判断文件是否上传成功。

实验结果

工具的作者关注点在于4种文件:php、html、xhtml、js,故此根据这4种文件,作者进行上传,以测试其是否允许CE或者PCE文件的上传。

首先数据集上,作者选取了33个CMS,并找到其中的文件上传点,然后利用工具进行动态fuzz,得到如下结果:

2020-03-27-10-16-57.png

我们从结果里可以看到,其中有9个cms是需要文件监视器的,即上传后的文件路径和文件名难以被攻击者直接获取。同时我们发现PCE中只有php和js,这可能是因为php文件虽然上传成功,但未必能被直接解析,其可能受到.htaccess的影响,而导致其只能是潜在的代码执行文件,可能需要配合任意文件删除漏洞,才能发挥作用。而对于js,其一般是需要被html等调用触发,才能造成一系列的攻击,故其也作为了一种PCE文件。

当然除此之外,该工具有测试尝试上传了.htaccess文件,我们知道.htaccess是可以更改apache子目录配置的,其可以指定将jpg后缀按照php进行解析等,很容易导致组合拳形式的bypass,所以对其的测试是很有必要的,我们也可以看到在上述CMS中,有6个CMS是允许.htaccess上传的,这是相当危险的。

后记

FUSE这款工具我个人认为,其定义应该为文件上传界的sqlmap,但由于其较强的约束条件,可能在实战黑盒测试中作用有限,应对会修改文件名和文件路径,或做隐藏的安全保护,是比较难以突破的。

工具开源在:https://github.com/WSP-LAB/FUSE

前言

这次介绍的是一篇发表在安全顶会NDSS 2020上的一篇paper,其针对文件上传漏洞的场景,实现了一款动态fuzz的工具FUSE,并利用其发现了现有33个CMS的15 CVE。

背景介绍

首先提几个关键的缩写含义,对于漏洞分类上,可以大致为两类,即:

UFU:为Unrestricted File Upload的缩写,含义即任意文件上传。

UEFU:为Unrestricted Executable File Upload的缩写,含义即任意可执行文件上传。

但这两类可能有一个子集的包含关系,UEFU应该为UFU的子集,因为我们上传的文件未必是可执行的。

然后是对于上传的恶意文件,我们也可以分为两类:

CE:为code execution的缩写,含义即为代码执行。

PCE:为potential code execution的缩写,含义即为潜在的任意代码执行。

一类就是代码执行的文件,这个非常容易理解,比如我们常见的一句话木马,而潜在代码执行的文件,可以理解成js等,需要引入或者满足一定条件的触发才会让其产生威胁。

而至于文件上传漏洞,作为一种危害性大,案例多的web漏洞,应该大家都比较熟悉了。那么其出现漏洞的位置也是多样化的,例如后缀名过滤产生的问题:

2020-03-27-10-07-36.png

我们可以看到黑名单过滤产生了2个弊端:第一是黑名单中的后缀名可能会有遗漏,第二是此处黑名单匹配并未使用大小写通配,从而会导致大小写Bypass。

同样的,漏洞也可能会是Content-Type过滤产生的问题:

2020-03-27-10-08-11.png

例如上述代码中,我们看到其会对Content-Type进行过滤,而Content-Type并不能真实反映文件的内容,是可通过burp等抓包工具进行拦截修改的,所以同样会产生安全隐患。

那么对于文件上传出现漏洞的多样性,其实对攻击者的探测产生了一些麻烦,我们在黑盒的情况下或者在找到上传点的情况下,可能需要通过大量的猜测和探测才能找到正确的Bypass模式,但实际上很多时候这是一种低效率的行为,有没有可能有一款类似sqlmap的工具,来自动化的fuzz上传接口呢?于是便有了FUSE这款工具。

工具设计

我们首先看一下工具的架构:

2020-03-27-10-10-26.png

那么实际上该工具的重点就在于其如何产生有效的payload和验证payload的攻击是否生效,首先我们先看其如何有效的产生payload:

2020-03-27-10-18-13.png

我们注意到,在一次文件上传的请求里,其实有很多位置是我们可以进行伪造更改的,因此作者将常见的文件上传bypass技巧归纳为如下多种模式:

2020-03-27-10-16-35.png

比如M3更改content-type,M4更改文件名后缀等等,当然我们肯定存在后端检测文件上传时,既检测content-type,又检测文件名后缀的情况,因此作者会对其进行排列组合进行测试:

2020-03-27-12-22-53.png

测试的时候,假如我们选定的seed模式为M1、M2、M3,那么工具会生成如上排列组合的模式,依次进行探测,从第一不修改任何参数进行恶意文件上传,到按照M1M2M3模式修改所有参数进行上传,当然如果其中某一种上传成功,那么自然不会去尝试包含这一种修改的修改,例如:

2020-03-27-12-25-50.png

当M1测试后,如果M1测试成功,我们的恶意文件已上传,那么则不会去尝试M1M3的组合,因为没有意义,其应该一定为成功。

当然这里可能涉及到相互冲突的问题,假设M1M3一起修改,可能会有冲突,所以考虑到这样的问题,工具也会进行筛选操作,例如M1和M2一起会产生冲突,那么M1M2和M1M2M3这两种排列组合不会进行组合修改。

2020-03-27-12-24-29.png

了解了payload的生成方式,我们再来看一下如何获取恶意文件上传后的路径,以用于检测是否攻击成功:

2020-03-27-10-16-00.png

工具有相应的config文件,其可以指定上传成功后的路径前缀,或者response里的路径url,以此正则去提取上传后的文件路径。当然作为一种修复文件上传漏洞的方案,常看见到文件名更改和路径的隐藏,上传者无法知道文件传到了何处,其文件名是什么。那么对于这一种情况,作者使用了一个文件监视器:

2020-03-27-12-30-26.png

该监视器运行在攻击目标服务器上,时刻监视该服务器上的文件创建。也是因为这一点,我个人认为FUSE可能更像一款动态fuzz的漏洞发掘工具,而非一款典型的渗透测试工具,因为这一需求我们在渗透测试中是肯定不会满足的,如果都有目标服务器的控制权限了,那么也没必要进行攻击了。所以这款工具的目标,更像去挖掘一些开源现有cms的文件上传漏洞。

然后是工具的运行逻辑:

2020-03-27-10-16-13.png

这就比较清晰了,即排列组合上述的payload,然后进行不断的上传测试,通过访问上传后的路径,判断文件是否上传成功。

实验结果

工具的作者关注点在于4种文件:php、html、xhtml、js,故此根据这4种文件,作者进行上传,以测试其是否允许CE或者PCE文件的上传。

首先数据集上,作者选取了33个CMS,并找到其中的文件上传点,然后利用工具进行动态fuzz,得到如下结果:

2020-03-27-10-16-57.png

我们从结果里可以看到,其中有9个cms是需要文件监视器的,即上传后的文件路径和文件名难以被攻击者直接获取。同时我们发现PCE中只有php和js,这可能是因为php文件虽然上传成功,但未必能被直接解析,其可能受到.htaccess的影响,而导致其只能是潜在的代码执行文件,可能需要配合任意文件删除漏洞,才能发挥作用。而对于js,其一般是需要被html等调用触发,才能造成一系列的攻击,故其也作为了一种PCE文件。

当然除此之外,该工具有测试尝试上传了.htaccess文件,我们知道.htaccess是可以更改apache子目录配置的,其可以指定将jpg后缀按照php进行解析等,很容易导致组合拳形式的bypass,所以对其的测试是很有必要的,我们也可以看到在上述CMS中,有6个CMS是允许.htaccess上传的,这是相当危险的。

后记

FUSE这款工具我个人认为,其定义应该为文件上传界的sqlmap,但由于其较强的约束条件,可能在实战黑盒测试中作用有限,应对会修改文件名和文件路径,或做隐藏的安全保护,是比较难以突破的。

工具开源在:https://github.com/WSP-LAB/FUSE

本文是对一次钓鱼事件的分析,在下水平实在不高,请路过的高手勿喷。像网络钓鱼这种违法事件时不时地出现在我们身边,下面是本人的亲身经历。

昨天在刷空间时看到同学发了这么一条消息,留言?

打开看看,嗯,不对啊,我俩18年6月加的好友啊,这是什么情况?

带着满脑子问号,扫码进去,瞬间就警惕了。

先瞎输一气,发现我的输入法不对劲啊,我用的讯飞输入法不长这样啊?

结果进去了?!跳转到QQ空间手机网页版。难不成是钓鱼?复制用浏览器打开,发现域名不对,果然是钓鱼。

用电脑打开看看

百度?302重定向,emmm……摁F12看看,分析一下响应日志,果然有发现

从这里不难发现我们现在访问的网址只不过是一个转发脚本,真正的页面是红线画的,302重定向就是他发出的。访问一下看看,同样也是被重定向到百度。

手机访问直接进入钓鱼页面

明白了,网页写了判断,如果是手机就正常访问,如果是电脑就跳转到百度。用chrome模拟移动设备访问。

成功访问,但是我发现键盘使不了了,密码框输不进去,禁用键盘,弹出了一个虚拟键盘让你输入账号密码

可以肯定这是为手机而量身定做的钓鱼网站。从代码中可以看出,红线部分的“u”表示QQ号码,“p”表示密码。黑线框起来的部分是生成虚拟键盘的代码,太长,就展开了一段。

这段是跳转url,应该是用来提交信息的。

啊,一大串的字符串,看样子是BASE64加密的,BASE64在线解密https://www.bejson.com/enc/base64/

看样子这是层unicode,还要转换一下,转换之前需要把所有“%”号替换成“\”号。在线unicode转中文https://www.bejson.com/convert/unicode_chinese/

文字显示出来了

如法炮制,解密所有字符串

没什么可利用的东西。

随便输个账号密码,发现先是访问了一个php页面然后跳转到H5QQ空间。这个dnf.php就应该是用来提交信息的。

查一下域名,竟然是企业办的。但是www打不开。反查下whois,结果我惊了,这个人名下的域名有十万多个….站长之家http://tool.chinaz.com/

ping一下,再查询一下IP信息,确定没有CDN。

直接访问IP,好熟悉的一幕,这不是宝塔吗?

访问默认8888端口试试,确实是宝塔,但是没有安全入口和账号密码什么的,就我这水平,搞他是不可能的。22端口开放了,ssh爆破希望渺茫,888端口虽然开放但是找不到phpmyadmin,php mysql注入判断还被拦截……

突然想起他的提交页面,呵呵,搞不死他也得搞残他,必须得搞搞他!打开xshell,连接了我的云服务器,vim写了一个脚本,

代码如下

#!/bin/bash
i=1  #定义变量
until ((i>10000))  #让脚本连续执行10000次
do  #开始循环
    function rand(){
        min=$1
        max=$(($2-$min+1))
        num=$(($RANDOM+1000000000))
        echo $(($num%$max+$min))
                   }  #生成长度为十位的随机数
        name=$(rand 1000000000 9999999999)  #定义QQ账号,1000000000-999999999的随机数
        pwd=$(head -c 9 /dev/random | base64)  #定义密码,12位的随机字符串
        curl -v 'https://cdn.tldcnm.com/dnf.php?u='$name'&p='$pwd'' \  #提交post请求,发送虚假账号密码信息,好好填充一下他的数据库,并在执行时输出实时信息
          -H 'authority: cdn.tldcnm.com' \
          -H 'upgrade-insecure-requests: 1' \
          -H 'user-agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.43 Mobile Safari/537.36' \  #这里我们模拟成移动终端设备,否则可能提交不成功
          -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
          -H 'sec-fetch-site: same-origin' \
          -H 'sec-fetch-mode: navigate' \
          -H 'sec-fetch-user: ?1' \
          -H 'sec-fetch-dest: document' \
          -H 'referer: https://cdn.tldcnm.com/' \
          -H 'accept-language: zh-CN,zh;q=0.9' \
          -H 'cookie: PHPSESSID=cddh7cie2m1a8lmcqch2avtf37' \
          --compressed
        sync
        echo 3 > /proc/sys/vm/drop_caches  #清理缓存,节省空间
done  #循环结束

bash测试一下,看到输出信息,post提交成功并且连续提交10000次。由于脚本发起的post请求跟正常访问页面一样,不属于DDOS,宝塔和防火墙不会拦截,返回302则表明提交成功(提交成功后会被重定向,所以返回302)。为了提高效率我用两台服务器多线程一起跑,估计数据库里找到真实的账号密码得费老劲了,全被无用的虚假数据淹没了。

问了一下朋友关于这张钓鱼二维码图片的事,他表示并不知情,很有可能中病毒了。同时也告诉了其他扫过这个码的人,通知他们及时地修改密码,保证自己的隐私和财产安全!

最后总结一下防钓经验:只要是让你输入账号密码,就要考虑是不是钓鱼网站,尽可能使用一键登录或者扫码登陆避免密码泄漏的风险。访问时看看网址域名,如果不是QQ官方域名而且没有快捷、一键登录选项那绝大多数都是钓鱼的。本人已经将此信息提交到360举报平台,阻止更多的人上当受骗。希望每一个被钓鱼的朋友都把钓鱼网站举报,让360,腾讯等安全平台及时提醒并拦截正在访问钓鱼页面的人,防止更多的人上当受骗!

净化网络环境,维护互联网安全,从我们每一个人做起!

加油武汉,加油地球,病毒必败!

*本文作者:一个神秘的人,转载请注明来自FreeBuf.COM

【全球动态】

1.沙特在美国从事监听活动,追踪其公民手机位置

据英国《卫报》报道,一名举报人向《卫报》展示了数百万份其所称的“秘密追踪请求”,表明沙特阿拉伯似乎在利用全球移动通讯网络的弱点,追踪其公民在美国各地的旅行情况。据专家介绍,这名举报人正在试图揭露七号信令系统(SS7)的漏洞。[阅读原文]

2.俄语黑客攻击两家欧洲制药公司

1月下旬,俄语黑客利用恶意软件攻击了至少两家欧洲制药公司。根据攻击工具,可以看出黑客可能是像Silence和TA505这样的以金钱为目标的组织团体。[外刊-阅读原文]

3.美政府被曝利用移动广告定位数据研究新冠病毒传播

3月30日消息,据外媒报道,据知情人士透露,美国疾病控制和预防中心(CDC)已与全美各州和地方政府合作,追踪人们的手机位置数据,借以研究新型冠状病毒的传播趋势。[阅读原文]

4.FTC警告VoIP提供商停止推进冠状病毒诈骗

美国联邦贸易委员会(FTC)警告九家VoIP服务提供商不要协助旨在利用冠状病毒的公众焦虑而进行的非法呼叫,这种非法呼叫会增加诈骗和传播虚假信息。这9家公司都必须通过电子邮件向FTC发送采取的具体行动。[外刊-阅读原文]

5.Elizabeth Warren 竞选团队开源其软件

美国民主党总统候选人 Elizabeth Warren 上个月因选情不佳而退出,其竞选团队刚刚宣布开源在竞选中使用的软件,并为使用开源软件节省资金而感到自豪。Warren 竞选团队的技术部门依赖于开源技术,也希望回报社区,因此决定将其重要的项目开源供任何人使用。[阅读原文]

6.美国多家顶级大学和微软结盟:用AI和超级计算机攻克新冠病毒

据国外媒体报道,美国多家顶级大学和微软结盟,用人工智能(AI)和超级计算机攻克新冠病毒。这个新研究联盟被称为“C3.ai数字转型研究所”(简称C3.ai DTI),该联盟的成员包括普林斯顿大学、卡内基梅隆大学、麻省理工学院、加州大学、伊利诺伊大学、芝加哥大学、C3.ai和微软。[阅读原文]

【安全事件】

1.部分企业采购间谍软件监视远程工作的雇员

新冠疫情让许许多多的人远程工作,间谍软件的销量也随之大涨,企业试图利用间谍软件来维持一定程度的安全性和生产力。监视软件公司 InterGuard 的 CEO Brad Miller 表示,企业使用间谍软件不是因为缺乏信任。然而,企业这么做其实就是缺乏对雇员的信任。[阅读原文]

2.App Store出现色情应用,社交榜排名27

苹果App Store出现一款App,里充斥着大量色情淫秽内容,年龄分级只有4+。该App在App Store免费社交榜排名27位,应用简介里有着“未满18岁禁入”、“岛国大片”、“国产爽片”等字样。[阅读原文]

3.Vivaldi 浏览器将内建广告与跟踪拦截器

在多个浏览器内建广告拦截器后,Vivaldi 浏览器也开始内建广告与跟踪拦截器。跟踪拦截器使用了 DuckDuckGo Privacy Essentials 浏览器扩展同样的列表,列表基于 DuckDuckGo Tracker Radar 跟踪器雷达的数据集生成。 [阅读原文]

4.黑客开始利用Zoom的爆火来传播恶意软件

在冠状病毒爆发后,人们越来越多地使用家庭和在线通信平台(例如Zoom变得越来越流行),利用使用量的激增,网络犯罪分子通过注册新的虚假“ Zoom”域和恶意的“ Zoom”可执行文件来诱骗人们在其设备上下载恶意软件。[外刊-阅读原文]

5.美国中小企业遭遇以行政捐助为诱饵的网络钓鱼

攻击者试图模仿美国小企业管理局(U.S.SBA)进行网络钓鱼,通过邮件向小企业发送Remcos RAT负载。这是利用小企业在疫情期间的财务问题,诱使他们点开行政捐助的恶意附件。[外刊-阅读原文]

6.DLA Piper:2020年1月数据泄露调查报告

从2018年5月25日到2020年1月27日,各企业向欧洲经济区内的数据保护监管机构通报的个人数据泄露事件共有160921起。此期间,平均每天收到247份违规通知。[阅读原文]

【优质文章】

1.信安标委:《网络安全标准实践指南—移动互联网应用程序(App)个人信息安全防范指引(征求意见稿)》

为帮助App运营者了解和重视个人信息保护合规常见问题,采取相应措施持续提升App个人信息保护水平,秘书处组织编制了《网络安全标准实践指南—移动互联网应用程序(App)个人信息安全防范指引(征求意见稿)》。[阅读原文]

2.构建全链路内容风控体系,解决内容安全难题

近几年,内容安全已成为全球性互联网生态治理难题。互联网平台多媒体内容爆发带来海量信息的同时,也泥沙俱下裹挟有大量不良有害信息。日前,国家互联网信息办公室发布了《网络信息内容生态治理规定》。[阅读原文]

3.黑客攻击WHO世界卫生组织,然而这只是冰山一角

随着新冠病毒在国外爆发,国外黑客组织通过仿造新冠疫情的相关信息,不断向全球各国企业,政府组织机构发起网络攻击,根据国外某媒体相关报道,从3月中旬开始一个名叫DarkHotel的高级黑客组织通过钓鱼和垃圾邮件手法攻击WHO世界卫生组织。[阅读原文]

*本文内容收集自全球范围内的媒体与刊物,制作者对其完整性负责,但不对其真实性和有效性负责。

*标注为【外刊】的内容主要来源为英语国家的媒体与刊物,部分内容需要注册免费账号后方可阅读。

3月30日,北京指掌易科技有限公司(以下简称:指掌易),对外宣布完成B+轮亿级融资。本轮融资由秋石资本旗下基金领投,该基金专注于互联网及IT产业投资。秋石资本目前还管理多支并购和定增基金,在海外并购及上市公司重组方面经验丰富,累计管理规模逾40亿元。随着本次B+轮融资的注入,指掌易将持续加强公司团队建设,包括研发、营销、服务体系,更精细地打磨产品,为用户提供更优质的产品和服务。

图片 1.png近年来,随着移动互联网、大数据、云计算、5G等快速发展,移动安全市场前景广阔。指掌易因专业的研发实力,和贴合用户业务需求的创新型解决方案,备受资本青睐。此前,指掌易于2018年底完成高成资本领投的B轮融资。截至目前,指掌易累计获得超过5亿元人民币融资。

作为移动业务安全专家,指掌易专注于移动业务安全领域,为政企用户提供一站式移动业务安全整体解决方案。2018年,指掌易在行业内率先提出了“移动业务安全框架(SAME,Secured Architecture for Mobile Enterprise)”理念。在该框架理念指导下,自主研发了移动业务智能安全平台(MBS,Mobile Business Smart-security Platform),与各行业移动业务场景的需求相结合,充分保护用户个人隐私的同时,为用户业务数据提供全方位的防护,并在安全、效率和易用性三者之间取得良好的平衡。该平台有效帮助政企用户安全、合规开展业务,对数据进行可视化呈现,提升安全运维效率。

指掌易创始人王伟表示,“指掌易作为一家技术驱动型高新技术企业,拥有自主研发的核心底层技术。自成立到现在的定位和目标一直比较坚定,专注于为政企用户提供安全服务,安全赋能业务移动化。移动化作为数字化转型的必经阶段,尤其是今年年初的疫情,更让社会各界切实体会到移动办公带来的价值。非常荣幸,在这个特殊的时期,仍能够得到秋石资本的认可和支持。未来指掌易会继续加大在技术研发的投入力度,与行业伙伴一起,为用户提供更加专业的产品和服务,促进我国网络安全产业升级发展。“

秋石资本创始合伙人沈伟表示,“移动互联网已深刻影响着人们的生活习惯和工作方式,在企业数字化转型背景下,员工自带设备(BYOD,Bring Your Own Device)逐渐成为主流趋势,移动化已经从常见办公场景渗透到核心业务场景,移动业务安全需求日益提高。国内企业服务市场开始进入快速发展期,指掌易基于自主研发技术,服务多行业多场景快速落地,可以满足政企移动化过程中多种安全需求。作为本次融资的领投方,秋石资本关注企业服务市场成长期投资机会,高度认可指掌易的安全理念和管理团队,相信随着5G商用推进和物联网发展,指掌易在移动安全市场能够继续保持领先优势、大有可为。”

2019年资本市场不断降温,而指掌易能够在短期内顺利完成本轮融资,不但得益于领先行业的技术方案,更是金融、运营商、制造、军队、政府、物流、大型互联网等行业领域标杆客户的认可。截至目前,凭借专业的产品和优质的服务,指掌易已成功服务中国平安、广东农信、海南农信、苏州银行、重庆银行、西安银行;新疆电信、江苏电信;京东方、友达光电;万科集团、伊利集团、上汽集团、五粮液集团、圆通速递、东方航空、滴滴出行等近千家行业客户。

在本轮融资之后,指掌易将持续加强产品研发和技术创新的投入,精细化打造产品矩阵,为用户提供更加完整且专业的产品和解决方案。同时,也将进一步拓展完善营销以及服务体系,快速响应客户需求,为用户提供高效、专业地本地化服务支持。

3月30日,北京指掌易科技有限公司(以下简称:指掌易),对外宣布完成B+轮亿级融资。本轮融资由秋石资本旗下基金领投,该基金专注于互联网及IT产业投资。秋石资本目前还管理多支并购和定增基金,在海外并购及上市公司重组方面经验丰富,累计管理规模逾40亿元。随着本次B+轮融资的注入,指掌易将持续加强公司团队建设,包括研发、营销、服务体系,更精细地打磨产品,为用户提供更优质的产品和服务。

图片 1.png近年来,随着移动互联网、大数据、云计算、5G等快速发展,移动安全市场前景广阔。指掌易因专业的研发实力,和贴合用户业务需求的创新型解决方案,备受资本青睐。此前,指掌易于2018年底完成高成资本领投的B轮融资。截至目前,指掌易累计获得超过5亿元人民币融资。

作为移动业务安全专家,指掌易专注于移动业务安全领域,为政企用户提供一站式移动业务安全整体解决方案。2018年,指掌易在行业内率先提出了“移动业务安全框架(SAME,Secured Architecture for Mobile Enterprise)”理念。在该框架理念指导下,自主研发了移动业务智能安全平台(MBS,Mobile Business Smart-security Platform),与各行业移动业务场景的需求相结合,充分保护用户个人隐私的同时,为用户业务数据提供全方位的防护,并在安全、效率和易用性三者之间取得良好的平衡。该平台有效帮助政企用户安全、合规开展业务,对数据进行可视化呈现,提升安全运维效率。

指掌易创始人王伟表示,“指掌易作为一家技术驱动型高新技术企业,拥有自主研发的核心底层技术。自成立到现在的定位和目标一直比较坚定,专注于为政企用户提供安全服务,安全赋能业务移动化。移动化作为数字化转型的必经阶段,尤其是今年年初的疫情,更让社会各界切实体会到移动办公带来的价值。非常荣幸,在这个特殊的时期,仍能够得到秋石资本的认可和支持。未来指掌易会继续加大在技术研发的投入力度,与行业伙伴一起,为用户提供更加专业的产品和服务,促进我国网络安全产业升级发展。“

秋石资本创始合伙人沈伟表示,“移动互联网已深刻影响着人们的生活习惯和工作方式,在企业数字化转型背景下,员工自带设备(BYOD,Bring Your Own Device)逐渐成为主流趋势,移动化已经从常见办公场景渗透到核心业务场景,移动业务安全需求日益提高。国内企业服务市场开始进入快速发展期,指掌易基于自主研发技术,服务多行业多场景快速落地,可以满足政企移动化过程中多种安全需求。作为本次融资的领投方,秋石资本关注企业服务市场成长期投资机会,高度认可指掌易的安全理念和管理团队,相信随着5G商用推进和物联网发展,指掌易在移动安全市场能够继续保持领先优势、大有可为。”

2019年资本市场不断降温,而指掌易能够在短期内顺利完成本轮融资,不但得益于领先行业的技术方案,更是金融、运营商、制造、军队、政府、物流、大型互联网等行业领域标杆客户的认可。截至目前,凭借专业的产品和优质的服务,指掌易已成功服务中国平安、广东农信、海南农信、苏州银行、重庆银行、西安银行;新疆电信、江苏电信;京东方、友达光电;万科集团、伊利集团、上汽集团、五粮液集团、圆通速递、东方航空、滴滴出行等近千家行业客户。

在本轮融资之后,指掌易将持续加强产品研发和技术创新的投入,精细化打造产品矩阵,为用户提供更加完整且专业的产品和解决方案。同时,也将进一步拓展完善营销以及服务体系,快速响应客户需求,为用户提供高效、专业地本地化服务支持。

本文将为大家介绍docker守护进程的相关安全配置项目。

一、测试环境

1.1 安装 CentOS 7

CentOS Linux release 7.7.1908 (Core)

升级内核,重启

# yum update kernel
[[email protected] docker]# uname -a
Linux localhost 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[[email protected] docker]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)

1.2 安装 docker ce 19.03

# yum install -y yum-utils device-mapper-persistent-data lvm2
# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# yum install -y docker-ce

[[email protected] docker]# docker --version
Docker version 19.03.8, build afacb8b

二、 守护进程安全配置

默认没有配置文件,需要单独创建/etc/docker/daemon.json,下面配置都是在该文件上进行配置,本地的测试示例。

{
    "icc": false,
    "log-level": "info",
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "10m",
        "max-file":"5",
        "labels": "somelabel",
        "env": "os,customer"
    },
    "iptables": true,
    "userns-remap": "default",
    "userland-proxy": false,
    "experimental": false,
    "selinux-enabled": true,
    "live-restore": true,
    "no-new-privileges": true,
    "cgroup-parent": "/foobar",
    "seccomp-profile": "/etc/docker/seccomp/default-no-chmod.json",
    "tls": true,
    "tlsverify": true,
    "tlscacert": "/etc/docker/CA/ca.pem",
    "tlscert": "/etc/docker/CA/server-cert.pem",
    "tlskey": "/etc/docker/CA/server-key.pem"
}

2.1 配置通过 HTTPS 和证书认证访问 Docker 守护进程

服务器证书 
创建 HOST,定义域(IP 也可以),会根据域来生成对应的证书,一般用于注册证书当中的 CN:

创建证书目录:

$ mkdir -p /etc/docker/dockerd/CA && cd /etc/docker/dockerd/CA

生成 key 证书,并填写两次 key 证书密码:

$ openssl genrsa -aes256 -out ca-key.pem 4096

生成 ca 证书,需要输入注册证书基础信息:

$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem

创建 server 证书:

$ openssl genrsa -out server-key.pem 4096

$ openssl req -subj "/CN=localhsot" -sha256 -new -key server-key.pem -out server.csr

设定证书指定的 IP 地址:

$ echo subjectAltName = DNS:localhost,IP:127.0.0.1 >> extfile.cnf

将 Docker 守护程序密钥的扩展使用属性设置为仅用于服务器身份验证:

$ echo extendedKeyUsage = serverAuth >> extfile.cnf

生成 server cert 证书:

$ openssl x509 -req -days 3650 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf

客户端证书
创建客户端证书:(还是当前目录)

$ openssl genrsa -out key.pem 4096
$ openssl req -subj '/CN=localhost' -new -key key.pem -out client.csr

要使密钥适合客户端身份验证,请创建扩展配置文件:

$ echo extendedKeyUsage = clientAuth >> extfile.cnf

生成 client cert 证书:

$ openssl x509 -req -days 3650 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

使用
对证书赋予相应的权限:

$ chmod -v 0400 ca-key.pem key.pem server-key.pem
$ chmod -v 0444 ca.pem server-cert.pem cert.pem

[[email protected] CA]# ls
ca-key.pem ca.pem ca.srl cert.pem client.csr extfile.cnf key.pem server-cert.pem server.csr server-key.pem

服务端配置/etc/docker/daemon.json

"tls": true,
"tlsverify": true,
"tlscacert": "/etc/docker/CA/ca.pem",
"tlscert": "/etc/docker/CA/server-cert.pem",
"tlskey": "/etc/docker/CA/server-key.pem"

客户端配置
设置客户端证书到当服务器上,并放置到相应的位置:

$ cp -v {ca,cert,key}.pem ~/.docker
$ export DOCKER_HOST=tcp://$HOST:2376 DOCKER_TLS_VERIFY=1

通过如下方式模拟测试:

$ curl https://$HOST:2376/images/json \
   --cert ~/.docker/cert.pem \
   --key ~/.docker/key.pem \
   --cacert ~/.docker/ca.pem
 
[{"Containers":-1,"Created":1540777343,"Id":"sha256:55e7b305dc477345434ce3bd3941940481f982eea31c8f28c0670d59c63d544b","Labels":nu

2.2 使用namespace隔离技术

namespace是一种隔离技术,docker就是使用隔离技术开启特定的namespace创建出一些特殊的进程,不过使用namespace是有条件的。系统会创建dockremap,通过/etc/subuid和/etc/subuid对应的id值,映射到容器中去;实际情况还是使用的是dockremap普通权限,达到自动隔离的效果。

首先修改/etc/sysctl.conf

# echo "user.max_user_namespaces=15076" >> /etc/sysctl.conf

/etc/docker/daemon.json增加配置项"userns-remap": "default"

修改此项配置需要慎重,如果是已经部署了一套docker环境,启用此选项后,会切换到隔离环境,以前的docker容器将无法使用!

[[email protected] docker]# cat /etc/subuid
dockremap:100000:65536

2.3 设置 docker 的分区

为容器创建单独的分区,默认分区在\var\lib\docker\,包含本地镜像、容器、网络等相关的东西。

[[email protected] docker]# ls /var/lib/docker 
100000.100000  builder  buildkit  containers  image  network  overlay2  plugins  runtimes  swarm  tmp  trust  volumes

可以使用"data-root": ""配置默认的分区位置。

2.4 限制默认网桥容器之间的流量

当启动 Docker 服务时候,默认会添加一条转发策略到 iptables 的 FORWARD 链上。策略为通过( ACCEPT )还是禁止( DROP ),取决于配置 --icc=true (缺省值)还是 --icc=false 。如果手动指定 --iptables=false 则不会添加 iptables 规则。
默认情况下,默认网桥上同一主机上的容器之间允许所有网络通信,如果不需要,限制所有容器间的通信。 将需要通信的特定容器链接在一起,或者创建自定义网络,并且仅加入需要与该自定义网络进行通信的容器。

配置限制默认网桥上容器之间的流量"icc":false

2.5 配置日志

配置集中的远程日志,设置日志进程--log-level级别为info,日志记录格式 json,本地日志记录

"log-level": "info",
"log-driver": "json-file",
"log-opts": {
  "max-size": "10m",
  "max-file":"5",
  "labels": "somelabel",
  "env": "os,customer"
},

配置远程日志

Docker 日志记录驱动程序接收容器日志并将其转发到远程目标或文件。 默认的日志记录驱动程序是json-file。 它将容器日志以JSON格式存储在本地磁盘上。 Docker具有用于记录日志的插件体系结构,因此有用于开源工具和商业工具的插件:

Journald–将容器日志存储在系统日志中.

Syslog Driver–支持UDP,TCP,TLS

Fluentd –支持将TCP或Unix套接字连接到fluentd

Splunk – HTTP / HTTPS转发到Splunk服务器

Gelf – UDP日志转发到Graylog2

示例 fluent

 {
   "log-driver": "fluentd",
   "log-opts": {
     "fluentd-address": "fluentdhost:24224"
   }
 }

使用 syslog

{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "udp://1.2.3.4:1111"
  }
}

2.6 设置 ulimit

{
    "default-ulimits": {
        "nofile": {
            "Name": "nofile",
            "Hard": 64000,
            "Soft": 64000
        }
    }
}

2.7 设置 cgroup

--cgroup-parent选项允许设置用于容器的默认cgroup父级。 如果未设置此选项,则对于fs cgroup驱动程序,默认为/docker;对于systemd cgroup驱动程序,默认为system.slice
如果cgroup有一个正斜杠(/),则cgroup在根cgroup下创建,否则cgroup在守护程序cgroup下创建。
假设守护程序在cgroup daemoncgroup中运行,则--cgroup-parent=/foobar/sys/fs/cgroup/memory/foobar中创建一个cgroup,而使用--cgroup-parent=foobar则创建 /sys/fs/cgroup/memory/daemoncgroup/foobar中创建 cgroup。
systemd cgroup驱动程序对–cgroup-parent具有不同的规则。 Systemd按切片表示层次结构,切片的名称对树中的位置进行编码。 因此,systemd cgroup的--cgroup-parent应为切片名称。 名称可以包含一系列用短划线分隔的名称,这些名称描述了从根切片到切片的路径。 例如,--cgroup-parent=user-a-b.slice表示容器的内存cgroup在/sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-<id>.scope中创建。
也可以使用容器运行来设置,使用docker create和docker run上的--cgroup-parent选项,会优先于守护程序上的--cgroup-parent选项。

2.8 配置 seccomp

使用的测试配置文件,禁止在 Docker 里使用chmod命令
https://github.com/docker/labs/blob/master/security/seccomp/seccomp-profiles/default-no-chmod.json

[[email protected] docker]# docker run --rm -it alpine sh
/ # ls bin  etc  lib  mnt  proc  run  srv  tmp  var
dev  home  media  opt  root  sbin  sys  usr / # touch foo.sh
/ # chmod +x foo.sh
chmod: foo.sh: Operation not permitted
/ # exit

实际可以完成禁止、允许、告警某些系统相关的调用,参考:https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl

2.9 配置支持无守护程序的容器

--live-restore确保 docker 守护进程关闭时不影响容器。

测试时再关闭 docker 守护进程后,nginx 容器仍能正常提供访问。
snipaste20200315_212215

2.10 禁用 docker 的实验性功能

设置"experimental": false

2.11 限制容器通过 suid 或 sgid 提权

no-new-privileges安全选项可防止容器内的应用程序进程在执行期间获得新的特权。

举例:有一个在映像中设置了 setuid/setgid 位的程序,例如sudo,容器中的进程也具有执行该程序的(文件)权限,试图通过诸如setuid/setgid之类的设施获取特权的任何操作将被拒绝。

三、守护进程配置示例说明(Linux)

{
    "authorization-plugins": [],//访问授权插件
    "data-root": "",//docker数据持久化存储的根目录,默认为/var/lib/docker
    "dns": [],//DNS服务器
    "dns-opts": [],//DNS配置选项,如端口等
    "dns-search": [],//DNS搜索域名
    "exec-opts": [],//执行选项
    "exec-root": "",//执行状态的文件的根目录
    "experimental": false,//是否开启试验性特性
    "features": {},//启用或禁用特定功能。如:{"buildkit": true}使buildkit成为默认的docker镜像构建器。
    "storage-driver": "",//存储驱动器类型
    "storage-opts": [],//存储选项
    "labels": [],//键值对式标记docker元数据
    "live-restore": true,//dockerd挂掉是否保活容器(避免了docker服务异常而造成容器退出)
    "log-driver": "json-file",//容器日志的驱动器
    "log-opts": {
        "max-size": "10m",
        "max-file":"5",
        "labels": "somelabel",
        "env": "os,customer"
    },//容器日志的选项
    "mtu": 0,//设置容器网络MTU(最大传输单元)
    "pidfile": "",//daemon PID文件的位置
    "cluster-store": "",//集群存储系统的URL
    "cluster-store-opts": {},//配置集群存储
    "cluster-advertise": "",//对外的地址名称
    "max-concurrent-downloads": 3,//设置每个pull进程的最大并发
    "max-concurrent-uploads": 5,//设置每个push进程的最大并发
    "default-shm-size": "64M",//设置默认共享内存的大小
    "shutdown-timeout": 15,//设置关闭的超时时限
    "debug": true,//开启调试模式
    "hosts": [],//dockerd守护进程的监听地址
    "log-level": "",//日志级别
    "tls": true,//开启传输层安全协议TLS
    "tlsverify": true,//开启输层安全协议并验证远程地址
    "tlscacert": "",//CA签名文件路径
    "tlscert": "",//TLS证书文件路径
    "tlskey": "",//TLS密钥文件路径
    "swarm-default-advertise-addr": "",//swarm对外地址
    "api-cors-header": "",//设置CORS(跨域资源共享-Cross-origin resource sharing)头
    "selinux-enabled": false,//开启selinux(用户、进程、应用、文件的强制访问控制)
    "userns-remap": "",//给用户命名空间设置 用户/组
    "group": "",//docker所在组
    "cgroup-parent": "",//设置所有容器的cgroup的父类
    "default-ulimits": {
        "nofile": {
            "Name": "nofile",
            "Hard": 64000,
            "Soft": 64000
        }
    },//设置所有容器的ulimit
    "init": false,//容器执行初始化,来转发信号或控制(reap)进程
    "init-path": "/usr/libexec/docker-init",//docker-init文件的路径
    "ipv6": false,//支持IPV6网络
    "iptables": false,//开启防火墙规则
    "ip-forward": false,//开启net.ipv4.ip_forward
    "ip-masq": false,//开启ip掩蔽(IP封包通过路由器或防火墙时重写源IP地址或目的IP地址的技术)
    "userland-proxy": false,//用户空间代理
    "userland-proxy-path": "/usr/libexec/docker-proxy",//用户空间代理路径
    "ip": "0.0.0.0",//默认IP
    "bridge": "",//将容器依附(attach)到桥接网络上的桥标识
    "bip": "",//指定桥接IP
    "fixed-cidr": "",//(ipv4)子网划分,即限制ip地址分配范围,用以控制容器所属网段实现容器间(同一主机或不同主机间)的网络访问
    "fixed-cidr-v6": "",//(ipv6)子网划分
    "default-gateway": "",//默认网关
    "default-gateway-v6": "",//默认ipv6网关
    "icc": false,//容器间通信
    "raw-logs": false,//原始日志(无颜色、全时间戳)
    "allow-nondistributable-artifacts": [],//不对外分发的产品提交的registry仓库
    "registry-mirrors": [],//registry仓库镜像加速地址
    "seccomp-profile": "",//seccomp配置文件
    "insecure-registries": [],//配置非https的registry地址
    "no-new-privileges": false,//禁止新优先级
    "default-runtime": "runc",//OCI联盟(The Open Container Initiative)默认运行时环境
    "oom-score-adjust": -500,//内存溢出被杀死的优先级(-1000~1000)
    "node-generic-resources": ["NVIDIA-GPU=UUID1", "NVIDIA-GPU=UUID2"],//对外公布的资源节点
    "runtimes": {
        "cc-runtime": {
            "path": "/usr/bin/cc-runtime"
        },
        "custom": {
            "path": "/usr/local/bin/my-runc-replacement",
            "runtimeArgs": [
                "--debug"
            ]
        }
    },//运行时
    "default-address-pools":[
        {"base":"172.80.0.0/16","size":24},//默认的dhcp分配地址
        {"base":"172.90.0.0/16","size":24}
    ]
}

*本文原创作者:白河·愁 ,本文属于FreeBuf原创奖励计划,未经许可禁止转载