HW蓝队/红军——安全布防

EDR的配置和使用

什么是EDR

端点、端点检测与响应中心、可视化展现三个部分
端点检测和响应是一种主动式端点安全解决方案通过记录终端与网络事件(例如用户，文件，进程，注册表，内存和网络事件)，并将这些信息本地存储在端点或集中数据库。结合已知的攻击指示器(Indicators of Compromise，lOCs)、行为分析的数据库来连续搜索数据和机器学习技术来监测任何可能的安全威胁，并对这些安全威胁做出快速响应，还有助于快速调查攻击范围，并提供响应能力。

EDR产品能力点

预测：risk assessment(风险评估)；anticipatethreats(预测威胁）；baseline security posture(基线安全态势)
防护：harden systems(强化系统)；isolate system(隔离系统)；prevent attacks(防止攻击)
检测：detect incidents(检测事件)；confirm and prioritize risk(确认风险并确定优先顺序)；contain incidents(包含事件)
响应：remediate(补救)；design policychange(设计规则变更)；investigate incidents(调查事件)

EDR工作原理

使用EDR技术以后，它就会使用先进的算法来分析系统上单个用户的行为，允许它记住和连接他们的活动。(检测)
感知到你系统中某个特定用户的异常行为。数据会立即被过滤、丰富和监控，以防出现恶意行为的迹象。这些迹象触发了警报，调查就开始了——确定攻击是真是假。(调查)
如果检测到恶意活动，算法将跟踪攻击路径并将其构建回入口点。(关联跟踪)
该技术将所有数据点合并到称为恶意操作(MalOps)的窄类别中，使分析人员更容易查看(可视化)
在发生真正的攻击事件时，客户会得到通知，并得到可采取行动的响应步骤和建议，以便进行进一步调查和高级取证。如果是误报，则警报关闭，只增加调查记录，不会通知客户。(处理)

EDR安全模型

资产发现：定期通过主动扫描、被动发现、手工录入和人工排查等多种方法收集当前网络中所有软硬件资产，包括全网所有的端点资产和在用的软件名称、版本，确保整个网络中没有安全盲点
系统加固：定期进行漏洞扫描、补丁修复、安全策略设置和更新端点软件清单，通过软件白名单限制未经授权的软件运行，通过主机防火墙限制未经授权的服务端口开放，并定期检查和清理内部人员的账号和授权信息。
威胁检测：通过端点本地的主机入侵检测和借助云端威胁情报、异常行为分析、攻击指示器等方式，针对各类安全威胁，在其发生前、发生中、发生后进行相应的安全检测动作。
响应取证：针对全网的安全威胁进行可视化展示，能够针对安全威胁自动化地进行隔离、修复和补救，自动完成安全威胁的调查、分析和取证工作，降低事件响应和取证分析的技术门槛，不需要依赖于外部专家即可完成快速响应和取证分析。

EDR检测威胁

EDR 保护用户免受无文件型的恶意软件，恶意脚本，或被窃取的用户凭证的攻击它被设计用来跟踪攻击者使用的技术、策略和过程。
它不仅可以了解攻击者如何侵入你的网络，还可以检测他们的活动路径:他们如何了解你的网络，如何转移到其他机器上，并试图在攻击中实现他们的目标。
可以避免的情况：
- 恶意软件(例如:犯罪软件、勒索软件等)
- 无文件型攻击
- 滥用合法应用程序
- 可疑的用户活动和行为

EDR优劣

优势

EDR具有精准识别攻击的先天优势;
EDR完整覆盖端点安全防御全生命周期;
EDR能够兼容各类网络架构;
EDR辅助管理员智能化应对安全威胁;

局限性

EDR的局限性在于并不能完全取代现有的端点安全防御技术。
EDR与防病毒、主机防火墙、主机入侵检测、补丁加固、外设管控、软件白名单等传统端点安全防御技术属于互补关系，并不是取代关系。

EDR所使用的技术

关联分析

应用场景：在EDR中，端点采集的各类安全运行数据是终端安全工作中防御、检测和响应的重要依据;对海量终端安全数据进行自动智能化的关联分析，追溯其攻击过程寻找漏洞源和攻击源，是有效防御和确保终端安全的重要途径和方法。
目标：大数据关联分析的主要目标是不丢失终端安全相关的重要信息，并通过分析原始终端安全数据而形成全局、缜密、连贯的攻击视图。
针对APT：为应对APT攻击的极强持续性和阶段性，关联分析过程中应尽量收集各层面、各阶段的全方位信息，同时适量将时间窗口拉大，通过宽时间域数据分析提取具有内在关联的若干属性，识别出攻击发生的时间、地点、攻击类型和强度等信息。

攻击场景重构技术

在EDR中，攻击场景重构通过对关联规则及知识的形式化表述，将庞杂，无序的安全数据流转换为结构化、易于理解的攻击场景，将反映攻击过程和意图的场景图呈现出来，发现攻击者的攻击策略和目的，甚至推测漏报的告警和预测下一步可能的攻击行为，以协助管理人员获取更有价值的网络安全信息。

数字取证技术

计算机、网络、电子设备等数字设备中的数字证据，进行确认、保护、提取归档的过程。在EDR中，数字取证要克服云计算环境进行取证、智能终端取证、大数据取证等关键技术，自动定位和采集端点人侵电子证据，降低取证分析的技术门槛，提高取证效率及其分析结果的准确性，为端点安全事件调查、打击网络犯罪提供技术支持。

智能沙箱技术

沙箱(Sandbox)：是针对可疑代码进行动态行为分析的关键技术，通过模拟各类虚拟资源创建严格受控和高度隔离的程序运行环境，运行并提取可疑代码运行过程中的行为信息，实现对未知恶意代码的快速识别。
支撑沙箱隔离的技术是重定向技术:重定向技术就是在可疑代码样本的地址空间中拦截相关操作，并将可能导致的更改重定位到虚拟资源(虚拟文件系统、虚拟硬件系统、虚拟注册表系统、句柄虚拟化)之上。通过重定向技术，恶意代码的任何修改都不会破坏到真实的用户系统。智能沙箱的检测包括了静态分析、动态分析以及相应智能数据解析几个过程，最终形成输出报告，判定可疑代码的安全属性。

机器学习技术

机器学习：是一门多学科交叉知识，是人工智能领域的核心，专门研究计算机如何模拟实现人类的学习行为，通过获取新的技能知识重组已有的知识体系，并不断完善自身性能。在大规模数挖掘处理中，可以自动分析获得规律，然后利用这些规律预测未知的数据。
机器学习算法的分类应用步骤:分类器训练和模型检测。首先利用训练集文件的向量型及其类别标记生成分类器，其次利用分类模型对待检测挖掘进行分类检测，通过将分类结果与真实样本数挖掘进行比对，评估分类器的效果，最后根据结果进一步完善分类器。
EDR中的机器学习：在EDR中，机器学习主要应用于端点用户和软件的正常行为和异常行为的提取，通过捕获大量的端点静态和动态的用户和软件行为特征向量，采用机器学习的思想进行端点用户和软件行为的训练建模和分类检测，得出该使用场景下用户和软件的正常和异常行为知识库，而利用知识库可以更加高效地检测出端点的异常行为。

HIDS的配置和策略调优

HIDS（主机型入侵检测系统）

主机型入侵检测系统作为计算机系统的监视器和分析器，它并不作用于外部接口，而是专注于系统内部，监视系统全部或部分的动态的行为以及整个计算机系统的状态。

HIDS工作原理

当使用HIDS技术的时候，符合传统的C/S架构，在完成Agent的安装以后就可以作为计算机系统的监视器和分析器，HIDS产品并不作用于外部接口而是专注于系统内部，监视系统全部或部分的动态的行为以及整个计算机系统的状态。
工作预期符合一个假说，当一个成功的入侵者一般而言都会留下他们入侵的痕迹。这样，计算机管理员可以察觉到一些系统的修改，HIDS能检测并报告出检测结果。

HIDS与EDR对比

指标项	EDR	HIDS
面向对象	面向终端（PC机）为主	面向主机（服务器）为主
功能点	侧重检测与响应一体	侧重入侵检测行为
资源占用	高	低
系统入侵性	中等	低
维护难度	中等	中等
安全性	高	高

国内外主机安全需求

国内对于主机安全的需求更多从安全合规角度出发，更多需要满足如基线检测能力、恶意文件防护能力、安全事件事后审计能力等。
国外对于主机安全的需求更多从安全场景角度出发，更多需要满足如一体化安全运营(产品联动能力)、主机适配性(容器、公有云兼容性)、数据安全场景等。

HIDS产品配置思路

成功安装Agent，保证HIDS产品处于正常运行状态
依次配置需要的功能项用于面对各种潜在的风险威胁问题
配置产品日志外发用于统一管理运营相关产品
持续优化HIDS产品配置，对于安全事件告警进行优化管理

配置项

web Shell

为有效检测WebShell上传的攻击行为，需要有效配置该功能。默认会自动对 Web目录进行识别，无需手动添加

在WebShell 策略配置中开启“配置控制开关
将检测模式调整成“精准模式”
添加额外扫描路径增加/tmp或C:\User等路径

命令审计

为有效检测和记录潜在的命令操作行为，需要在命令记录配置中开启相关功能。

在中策略配置中开启“配置控制开关”
开启替换系统bash、监控进程创建。
将智能检测引擎下的规则检测灵敏度改为高。
将靶标系统单独使用命令白名单策略，开启学习模式，24h后调整成告警模式

syslog

将日志转发给态势感知需要用到

针对HW行为优化重点配置

重点在于护网前中期相关配置

护网行动的目标是尽可能保护靶标系统不失分或者在失分的情况下尽可能多的发现攻击痕迹进行溯源反制。常常会以更高强度的检测与防护来应对对应的演练。
在原有有效配置上进一步开启高防的相关策略配置，主要调整配置有命令审计、蜜罐诱捕、针对入侵行为的自动响应。

WAF

基本原理

WAF是Web应用程序防火墙的缩写，是一种保护Web应用程序免受各种攻击的技术WAF的基本原理是在Web应用程序与客户端之间添加一层拦截层，检查进出Web应用程序的数据，过滤掉恶意数据，阻止攻击。WAF可以通过以下三种方式进行检查：

签名检查：WAF可以根据已知攻击的签名，来检查Web应用程序的流量。如果流量包含已知攻击的签名，WAF将拒绝该请求。
行为分析：WAF可以根据Web应用程序的预期行为，来检查流量。如果流量的行为与预期不符，WAF将拒绝该请求。
机器学习：WAF可以使用机器学习算法来检查流量。WAF将学习Web应用程序的行为模式，并识别异常流量。

优化WAF策略

确保请求在到达应用程序之前得到检查
定期审查WAF日志以识别误报和漏报
调整WAF规则以确保它们适用于应用程序

中期-HW前WAF调优

日志的分析与处理

日志分类

攻击检测日志
频率控制日志
扩展插件日志
系统操作日志
访问日志

日志归档功能及使用场景介绍

功能：通过将一段时间之前的无需在界面上查看的日志归档为文件，提升查看筛选效率。
场景：在HW场景下，减少界面上展示的日志，提升筛选和查看效率，避免出现性能问题

系统配置

基础配置

服务器时间一定要准确
syslog等告警尽量配置
如果有配置高可用，确认配置同步正常
patch及时打上/引擎及时更新

站点配置

IP获取方式一定要准确
cookie防护配置
记录访问日志，以便事后分析

常见攻击及漏洞自测

无害的常见攻击样例对配置好的WAF进行测试，查看系统是否能正常拦截并记录日志，分析误报和漏报情况。
对漏洞进行扫描(推荐免费的工具:xray)，检查系统和WAF对漏洞的防御情况。
雷池支持一些针对特定的框架、组件、服务的攻击检测

日志筛选能力

以攻击检测日志为例:可从多个维度筛选(ID、事件ID、国家和地区、省份、协议、来源IP、目的端口、域名、URL路径、攻击类型、风险等级、动作、时间等)，并根据字段的不同可选择不同的筛选方式，如“包含”、“不包含”、“大于”、“等于”“属于网段”等，普通筛选的多个筛选条件间是“与”的关系。
也可以进行基于es语句高级筛选。

漏报拦截

确定有漏报，需要拦截
需要拦截指定可能存在隐患的请求如http://www.aaa.com/api/userlist?id=存在逻辑漏洞waf默认策略不能做防护的

误报放行

分析日志发现疑似误报，在日志详情里查看检测日志详情
确认误报之后可以直接在页面右上角消除误报
自动生成自定义规则，也可以根据生成的规则修改之后确定。

防护设置

规则

自定义规则调优的两个方向

降误报：如若业务本身有传JS、传Java、PHP序列化数据，以及传某种特定的SQL的完整语句等情况。可通过修改引擎模块配置或通过自定义规则加白来解决
降漏报：通常为因地制宜的解决未支持的识别的CVE漏洞(有的漏洞利用方式不太好设定一个通用的规则去防护)，以及过于宽松的防护设置。

根据实际应用场景来添加一些适用的规则时应考虑

该规则在当前业务下是否容易误报，若容易误报则只开观察模式。
仅添加匹配业务类型的规则，减少过多规则造成的性能损耗。

webshell

冰蝎是常见加密通信的webshell，冰蝎的第一个响应包body为秘钥，长度为16的字符串。此规则尝试发现该行为
Weevely：根据抓包分析，此工具特征并不明显，但观察得出，如果攻击者执行命令成功，数据会存放在响应包body的<0b00e2b0>标签里。此规则尝试发现该行为:

基础的误报调优

XSS、SQL注入攻击了解的业务情况，调整“非注入型攻击”配置，避免误报
判断是否有允许的机器人类型，可进行对应的配置，避免误报

通常发现和溯源会有得分，所以建议开启如下配置

关闭的检测模块可以打开，设置为只记录日志。
已开启的模块日志记录阈值调低。
打开HTTP响应处理

防火墙

基本原理

防火墙是一种保护计算机网络免受未经授权访问的技术。防火墙的基本原理是在网络边界处建立一道屏障，通过检查进出网络的数据包，来判断是否允许该数据包通过。防火墙可以根据以下几个因素来判断数据包的合法性：

源IP地址
目标IP地址
协议
端口

防火墙策略配置

防火墙的策略配置是指根据网络环境和安全需求，为防火墙配置不同的访问控制策略以保护网络安全。
以下是一些常见的防火墙策略配置方法：

禁止所有未经授权的访问：防火墙应该禁止所有未经授权的访问，只允许特定的IP地址和端口号访问网络。
针对不同区域的流量设置不同的规则：根据不同区域的安全需求，为不同的流量设置不同的规则。
审查和更新防火墙规则：防火墙规则需要定期审查和更新，以确保网络安全策略与最新的威胁和技术保持同步。
实时监控流量：防火墙需要实时监控网络流量，及时发现异常行为。

区域隔离

内部网络和外部网络隔离：内部网络应该与外部网络隔离
服务隔离：将不同的服务隔离在不同的区域中，如Web服务器、数据库服务器
用户隔离：将不同的用户隔离在不同的区域中，如员工、客户
数据隔离：将敏感数据隔离在不同的区域中，如个人身份信息、财务信息

部署模式

原则

通常准备时间较短，需结合自身情况，选择能快速部署上线的的模式
为了最小化对业务的影响，最好选用高可用的方式，并提前规划好WAF的上线下线方式。
集中管理，检测节点分组覆盖网络出口
为了达到更好的拦截效果，尽可能串联进链路
考虑部署异构的设备，交叉验证

反向代理模式

修改F5/负载均衡/dns等设备的难度比较小的客户;
业务没有要求必须获取socket为源IP;
业务有突增需求;
业务可以接受改变现有网络拓扑;

路由代理模式

基本和反代一致
希望通过反向代理进行请求检测，而业务服务器需要直接从socket拿到客户端IP
客户有F5，F5按mac地址回源
改变源端口&源mac

透明代理

适用环境

要求不改变现有网络拓扑
要求检测HTTPS流量

模式特性

不改变现有网络拓扑
客户端和雷池建立握手，雷池使用客户端的IP作为源IP跟WEB Server建立TCP连接，对WEBServer完全透明
雷池WAF作为中间人的角色，支持SSL证书卸载
支持返回指定拦截页面
支持链路聚合/vlan
改变源端口
支持链路的硬件bypass（需要硬件支持）
区分IN流量和OUT流量
支持bot防护

透明桥

要求不改变现有网络拓扑
有VLAN并且是单层VLAN
不要求检测HTTPS流量
要求对全部HTTP流量进行检测
不要求攻击拦截页面

模式特性

不改变现有网络拓扑
不改变源IP&源mac&源端口等
客户端和Web Server建立TCP
不支持SSL证书卸载，对非HTTP报文不检测直接放行
使用发送TCP Reset报文或丢包的方式拦截攻击，不支持拦截页面。
支持多进多出，链路聚合模式下雷池前后端设备协商聚合模式
支持链路的硬件bypass(需硬件支持)
不区分IN流量/OUT流量
服务器响应检测不能做阻断

流量镜像

适用环境

要求不改变网络拓扑和网络架构
要求只对HTTP流量
不做阻断或不考虑阻断成功率
交换机支持镜像

嵌入式

适用环境

要求不改变网络拓扑和网络架构
已经有nginx，且可以在nginx加模块（反代由nginx实现）
nginx如果加载第三方非开源模块，能够提供模块源码

模式特性

不改变原有网络拓扑
支持https流量检测
需要在客户nginx上加载t1k模块

现场值守

过滤扫描器日志

在实际场景中，WAF 的攻击日志可能绝大多数都是扫描器请求，一些手动测试的但是更危险的请求可能会被淹没在扫描器请求中，所以我们需要想办法排除掉扫描器的请求，一般可能会有以下几种情况：

扫描器特征在请求头中，或者说扫描器没有隐藏自身的特征
1. 如：GET /HTTP/1.1Host:192.168.30.83:3080User-Agent: sqlmapAccept: */*Accept-Encoding: gzip, deflate
2. 这种情况下，如果机器人检测模块开启，这类请求都会被识别为“机器人攻击”，如果希望过滤掉这类请求，只需要在日志筛选出排除掉对应攻击类型即可。
扫描器隐藏了特征，无法从请求内容看出是否扫描器
1. 一种缓解的方法是先整体浏览一下攻击日志，如果发现短时间内某个 IP 发出了大量的请求,比如1分钟发了 1000 个请求;或者以很均匀的速率在发出攻击请求，比如每秒发5 个攻击请求。那么该 IP 则很有可能对应的是一个扫描器，这种情况下可以再日志筛选中针对 IP进行排除。
2. 另一种缓解方式是:开启主动的机器人检测。通过 JS challenge、滑块等需要客户端主动验证的机制来缓解机器人行为。
一般客户现场会部署多种设备
1. 如 WAF/蜜罐/日志审计&态势感知WAF和蜜罐联动：waf将攻击请求跳转给蜜罐，攻击者直接进蜜罐，蜜罐抓信息，后期溯源
2. WAF和日志审计联动：WAF将日志通过syslog发给日审，日审统一查看多台设备日志，提高工作效率
3. WAF和态势感知联动：WAF将日志通过syslog发给态感，态感根据多设备综合研判，再通过OPENAPI方式再WAF上做自动封禁，提高封禁效率
4. 可将多种检测设备日志通过syslog等方式集合到 ELK/日志易等设备，进行多维度研判WAF检测HTTP攻击；IPS/IDS检测入侵攻击行为；邮件网关检测邮件安全

容器安全

镜像&编排安全

容器镜像安全概括

镜像漏洞和合规性问题：需要确保镜像中不存在任何已知的漏洞，并符合相关的合规标准。
保护镜像仓库的安全：需要采取措施来保护镜像仓库，防止未经授权的访问和潜在的攻击。
容器运行时保护：包括限制容器的权限、监控容器的行为、以及及时修复容器中的安全漏洞。
保护主机操作系统：这包括及时更新操作系统的补丁、配置适当的访问控制和防火墙规则，以及监控主机的安全状态。

镜像漏洞和合规性问题

定期更新镜像：及时更新镜像中的软件组件和依赖库，以修复已知的安全漏洞。
自动化扫描工具：使用自动化扫描工具来检测镜像中的安全漏洞，并及时采取修复措施。
安全审查流程：建立安全审查流程，确保所有镜像都经过审查，并符合相关的合规标准。
漏洞管理系统：建立漏洞管理系统，跟踪和管理镜像中的漏洞，并及时修复或替换受影响的镜像。

容器运行时保护

最小特权原则：将容器的权限限制到最低限度，只赋予其执行必要操作所需的权限
安全配置：确保容器的配置文件和环境变量设置正确，以减少潜在的安全风险。
容器监控：使用容器监控工具来监视容器的行为，及时检测异常活动或潜在的安全威胁。
安全更新和修复：定期更新容器中的软件组件和操作系统补丁，修复已知的安全漏洞。

保护主机操作系统

及时更新补丁：定期更新主机操作系统的补丁，以修复已知的安全漏洞。
强化访问控制：配置适当的访问控制和身份验证机制，限制对主机的访问权限。
防火墙规则：设置防火墙规则，限制对主机的网络访问，防止未经授权的访问和攻击
安全监控：实施安全监控机制，及时检测和响应主机上的安全事件和异常行为

容器编排问题

确保编排工具的安全性，以及正确配置和管理容器的网络和访问控制

安全编排工具：选择安全可靠的容器编排工具，确保其具有强大的安全功能和漏洞修复能力。
网络隔离：配置和管理容器的网络隔离，限制容器之间的通信和访问权限。
访问控制：设置适当的访问控制策略，确保只有授权的用户或服务可以访问和操作编排工具

容器编排工具风险

管理访问权限不受限制

风险：许多编排工具在设计时都假设，与其交互的所有用户都是管理员，并且管理员应具有对整个环境的控制能力。然而，在许多情况下，单个编排工具可以运行许多不同的应用，每一个由不同的团队管理，并具有不同的敏感性级别。如果提供给用户和不同分组的访问权限不局限于其特定需求，恶意或粗心的用户可能会影响或破坏编排工具管理的其它容器的运行。
措施：特别是由于编排工具广泛的控制范围，编排工具应运用最小授权访问模式，在这种模式下，只授权用户其工作职责所要求的在特定主机、容器和镜像上执行特定操作的权力。

未经授权访问

风险：编排工具通常有自己的身份鉴别目录服务，这可能与组织机构内部已经使用的常见目录不同。这可能导致编排工具中帐户管理实践薄弱，并且存在“孤立”帐户，因为这些系统缺乏严格的管理。由于很多此类帐户在编排工具中享有很高特权，入侵这些账户可能会导致整个系统范围遭到入侵。容器使用的数据存储卷通常是由编排工具管理的，而且不是主机特定的数据存储卷。由于容器可以在群集中任一给定节点上运行，而该容器内应用所需的数据必须是容器可用的数据，无论它运行哪台主机上。与此同时，许多组织机构管理的数据在静态下是必须加密的，以防止未经授权的访问。
措施：应严格控制对集群范围内的管理帐户的访问权限，因为这些账户能够影响环境中所有资源。组织机构应采用强有力的身份验证方法，如要求多因素身份验证，而不仅仅是单一口令。组织机构应尽可能对现有的目录系统实行单点登录。单点登录简化了编排工具的验证过程，更便于用户使用强大的身份验证凭证，并集中对访问进行审计，提高异常检测的效率。对静止数据加密的传统方法通常涉及到使用基于主机的功能，这可能与容器不兼容。因此，组织机构应使用用于容器数据的加密工具，从而让无论运行于哪个节点上的容器都能够适当地访问数据。这种加密工具应使用 NIST SP800-111[19]中定义的加密方法，对于非授权访问和篡改提供相同的壁垒。

容器间网络流量隔离效果差

风险：在大多数容器化环境中，各个单独节点之间的流量是通过虚拟覆盖网络路由。该覆盖网络通常由编排工具管理，通常对现有的网络安全和管理工具是不透明的。可能更严重的是，共享同一虚拟网络的不同应用存在流量风险。如果不同敏感级别的应用，诸如面向公众的网站和内部财务管理应用，使用同一虚拟网络，敏感的内部应用面临网络攻击的风险更大。例如，如果面向公众的网站被入侵，攻击者可能会利用共享网络来攻击财务应用。
措施：应配置好编排工具，根据敏感度级别将网络流量分配到不同的虚拟网络中。虽然按照应用进行细分也是可以的，但对大多数组织机构和用例来说，简单地依据敏感度级别定义网络，也能充分降低风险，将复杂度控制在可管理的范围内。例如，面向公众的应用可以共享一个虚拟网络，内部应用可以使用另一种，并且两者之间的通信应通过几个明确确定的接口来实现。

混合不同敏感度级别的工作负载

风险：编排工具通常重点关注工作负载规模和密度的管理。这意味着，在默认情况下，编排工具可以将不同敏感度级别的工作负载置于同一主机上。例如，在默认配置下，编排工具可能将一个运行面向公众的 Web 服务器的容器与运行处理敏感财务数据的容器置于同一台主机上，只是因为该主机在部署时恰巧有最多可用资源。在 Web 服务器有严重漏洞的情况下，这可能会提高处理敏感财务数据的容器面临的入侵风险。
措施：应配置好编排工具，按照敏感度级别将对特定主机集合上的部署隔离开来。用于实现这个要求的具体方法因所使用的编排工具不同而异，但通用模型定义的规则可防止将高敏感度工作载荷放在运行较低敏感度载荷的同一主机上。

编排工具节点可信

风险：维护环境中各节点之间的信任时需要特别小心。编排工具是最基本的节点。编排工具配置不当可能让编排工具和所有其它容器技术组件面临更大风险。可能后果的示例包括：
- 未经授权的主机加入集群并运行容器。
- 集群中单个主机被入侵意味着整个集群被入侵——例如，如果用于认证的密钥在所有节点中共享
- 编排工具和 DevOps 人员、管理员和主机之间的通信是未加密和未认证的。
措施：应配置好编排平台，提供创建安全环境所需的功能，以便运行应用。编排工具应确保将节点安全地引入集群在整个生命周期内保持身份标识不变，并且还可以提供节点及其连接状态的完整清单。组织机构应确保编排平台的设计具有足够的弹性，让单个节点的入侵不会损害集群的整体安全。被入侵的节点必须能够从集群中嗝离并移除，而不会破坏或降低整个群集的运行情况。最后，组织机构应选择能够让集群成员之间相互验证网络连接，并对集群内流量进行端到端加密的编排工具。由于容器的可移植性，许多时候会对组织机构不直接控制的网络进行跨网络部署，因此默认安全的方式对于该场景尤为重要。

CI集成

持续集成是软件开发的一种工作方式。这意味着当不同的程序员为一个项目编写代码时，他们的更改会定期组合或集成到项目中。此过程有助于及早发现问题和错误，使软件更加可靠。CI的目标是确保软件始终准备好发布，无论有多少人正在开发它。

容器基线安全

安全容器

安全容器的技术本质就是隔离。gVisor和Kata Container是比较具有代表性的实现方式，目前学术界也在探索基于IntelSGX的安全容器。
简单地说，gVisor是在用户态和内核态之间抽象出一层，封装成API，有点像user-mode kernel，以此实现隔离。Kata Container采用了轻量级的虚拟机隔离，与传统的VM比较类似，但是它实现了无缝集成当前的Kubernetes加Docker架构。我们接着来看gVisor与Kata Container的异同。

gVisor

gVisor是用Golang编写的用户态内核，或者说是沙箱技术，它主要实现了大部分的systemcall。它运行在应用程序和内核之间，为它们提供隔离。gVisor被使用在Google云计算平台的App Engine、Cloud Functions和Cloud ML中。gVisor运行时，是由多个沙箱组成，这些沙箱进程共同覆盖了一个或多个容器。通过拦截从应用程序到主机内核的所有系统调用，并使用用户空间中的Sentry处理它们，gVisor充当guest kernel的角色，且无需通过虚拟化硬件转换可以将它看做vmm与guest kernel的集合，或是seccomp的增强版。

Kata Container

Kata Container的Container Runtime是用hypervisor ，然后用hardware virtualization实现，如同虚拟机。所以每一个像这样的Kata Container的Pod，都是一个轻量级虚拟机，它拥有完整的Linux内核。所以KataContainer与VM一样能提供强隔离性，但由于它的优化和性能设计，同时也拥有与容器相媲美的敏捷性。

容器安全基线建立

主机层面配置

为容器文件提供独立的分区：独立分区主要的好处在于容易重置，挂载点安全可以容易统一处理
确保受信用户可以控制Docker守护进程：Docker Daemon是采用root用户启动的，如果启动容器的用户仍然采用root，用户就可以直接挂载根目录到容器中，造成安全信息泄露。
监测审计Docker守护进程：采用系统检测命令auditctl增加对Docker守护进程的安全审计工作。因为当前containerd、cri-o的流行，所以注意审计应用名称是否正确，确保审计对象的正确性。
审计Docker目录和文件

Docker Daemon程序层面

限制容器网络数据流量的入口到指定的网络接口
配置日志级别为info
允许Docker修改iptables
避免非加密镜像仓库被使用
确保cgroup配置正常
开启用户命名空间
确保Docker Daemon守护进程配置了TLS认证
确保aufs驱动不被使用了。
确保热恢复特性开启
确保Useriand proxy关闭
生产环境关闭试验性特性开关

Docker Daemon程序配置文件层面

确保docker.service文件所有者设置为root:root.文件权限配置644或者更
小
docker.socket文件所有者设置为root:root，文件权限配置644或者更小;
/etc/docker日录设置为root:root，目录权限配置644或者更小;
确保Docker守护进程的认证证书设置为root:root文件权限配置400或者更小;
确保TLS根证书设置为root:root，文件权限配置444或者更小;
确保镜像仓库认证证书设置为root:root，文件权限配置444或者更小;
确保Docker socket文件设置为root:docker，文件权限配置660或者更小;
确保daemon.json文件设置为root:root，文件权限配置644或者更小;
确保etc/default/docker文件设置为root:root，文件权限配置644或者更小;

容器镜像和构建文件层面

为容器创建一个独立的用户：其实不需要用户映射，只需要在基础系统镜像中创建一个用户就可以保证足够的用户安全。
使用认证的基础系统镜像：基础系统镜像是最基础的环境，安全问题可以尽量杜绝Docker Hub有现成的基础系统镜像。

容器运行时层面

确保AppArmor或者SELinux被启用：主机级别的安全套件能加固容器。
Linux Kernel能力被有效限制：限制Linux Kernel能力可以保证容器安全。

Docker Swarm集群层面

Swarm集群特性是docker强制加上的，并且无法自己关闭。从生产角度来看由于Kubernetes提供了更全面的集群能力。此swarm集群能力可以屏蔽不使用。

审核Docker文件和目录 | 安全审计

描述：除了审核常规的Linux文件系统和系统调用之外，还审核所有与Docker相关的文件和目录。Docker守护程序以“root”特权运行。其行为取决于某些关键文件和目录。如/var/lib/docker、/etc/docker、docker.service、docker.socket、/usr/bin/docker-containerd、/usr/bin/docker-runc等文件和目录。

加固建议：在/etc/audit/audit.rules与/etc/audit/rules.d/audit.rules文件中添加以下行：

1
2
3

-w /var/lib/docker -k docker
-w /etc/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker-w /usr/lib/systemd/system/docker.socket -k docker-w /usr/bin/docker-containerd -k docker-w /usr/bin/docker-runc -k docker

然后，重新启动audit程序。例如service auditd restart

限制容器之间的网络流量 | 服务配置

描述：默认情况下，同一主机上的容器之间允许所有网络通信。如果不需要，请限制所有容器间的通信。将需要相互通信的特定容器链接在一起。默认情况下，同一主机上所有容器之间都启用子不受限制的网络流量。因此，每个容器都有可能读取同一主机上整个容器网络上的所有数据包。这可能会导致意外和不必要的信息泄露给其他容器。因此，限制容器间的通信。
加固建议：在守护程序模式下运行docker并传递’–icc=false’作为参数。

将容器的根文件系统挂载为只读 | 服务配置

描述：容器的根文件系统应被视为“黄金映像”，并且应避免对根文件系统的任何写操作。您应该显式定义用于写入的容器卷。您不应该在容器中写入数据。属于容器的数据量应明确定义和管理。在管理员控制他们希望开发人员在何处写入文件和错误的许多情况下，这很有用。
加固建议：添加--read-only标志，以允许将容器的根文件系统挂载为只读。可以将其与卷结合使用，以强制容器的过程仅写入要保留的位置。您应该按以下方式运行容器：docker run --interactive --tty--read-only --volume <writable-volume><Container lmage Name or lD><Command>，如果是k8s或其他容器编排软件编排的容器，请按照相应的安全策略配置或忽略。

K8S基线安全

四个原则

用可靠的策略管理配置合规

在整个开发生命周期中持续应用安全策略和相关的行业基线检查是K8S安全的重要第一步。例如，策略不允许在集群中运行任何具有根权限的容器，或者禁止Kubernetes API服务器被公众访问。
如果违反了此策略，这意味着您的配置错误，将导致不可接受的安全风险。利用像开放策略代理(OPA)这样的策略框架和像互联网安全中心(CIS)这样的行业基线检查，可以帮助加强K8S环境，并防止错误配置进入生产环境。先设置你的策略和基线而不是闲置，定期检查以确保它们能持续满足安全合规。

实施安全护栏

K8S的安全工作从开发过程开始。大多数为云原生平台开发的团队都在使用基础设施即代码(laC)来构建和配置他们的系统。如果您的用户是其中之一，您应该建议他们将其扩展为策略即代码。这意味着团队可以在整个软件开发生命周期中应用相同的安全策略。例如，开发人员可以在其工作站、持续集成/持续交付(CI/CD)管道、容器镜像注册中心和K8S环境中扫描代码安全。利用对开发人员友好的工具可以帮助将安全性无缝地集成到开发过程中。开源的laC静态代码扫描器，如Terrascan，可以帮助确保只有安全的代码进入您的环境。
它通过扫描用于提供Docker、Arm和Terraform等laC的代码来做到这一点。这有助于发现作为本地测试周期一部分的漏洞。此外，Terrascan还允许您监控已配置的云基础设施，以应对配置漂移。Terrascan已经被全世界用户广泛使用，所以你可以使用Terrascan沙箱直接扫描代码，或者在GitHub repo中检查。

理解和修复容器镜像漏洞

修复容器镜像漏洞可能是一个挑战，因为很难看到在您的环境中实际运行了什么。K8S的仪表盘不会告诉你太多;你需要知道你的镜像包含了什么内核/应用/依赖，以及它们是如何构建的许多开发人员使用通用的基本镜像，并称之为“好”镜像。不幸的是，未检查过的通用镜像可能会让您容易受到攻击–而且在内核/注册表和主机级别上的漏洞和风险更加复杂。开发人员通常会跳过这种镜像安全检查，因为它会降低他们的开发速度。但事实是，如果他们不习惯检查过时的操作系统(OS)镜像、错误的设置、权限问题、嵌入的凭据和口令、弃用或未验证的包、不必要的服务和公开的端口，他们只是把问题交给别人。是的，他们的工作可能进行得更快，但他们的实践减慢了整个软件交付过程。
一些常见的安全风险：
- 在镜像中：不受支持的软件版本，嵌入代码的密码，使用不安全的镜像。
- 在仓库中：过时的镜像，不安全的身份验证，缺乏安全测试
- 在主机中：不受限的网络策略、薄弱的访问控制、未加密的数据卷和存储、不安全的主机和基础设施

暴露管理

当您实现了前三个原则，就是时候开始全面地关注您的基础设施了。并不是所有的政策都适用于所有的情况，那么你是如何适用你的排除条款呢?并不是每个漏洞都是关键的，那么您如何优先考虑修复和自动补救呢?这些问题可以引导你在工作中不再被动并且更积极主动。
最终，安全可见性是管理K8S和云原生环境中的安全的核心。您需要能够识别配置何时偏离了安全基线，并随时识别失败的策略和错误配置。只有这样，你才能得到你的攻击面的全貌。

K8S基线

该工具是使用Go语言完成，而测试文件则兼容于YAML格式，其测试结果也能支持JSON格式，方便使用者整合其他的自动化工具。在执行完测试任务后，系统除了告诉开发者Kubernetes未通过哪些测试外，也会给予如何改善的建议，例如移除K8s上某个不安全的配置设置建议，或者限制配置文件的权限等。下载地址如下：https://github.com/aquasecurity/kube-bench

K8S安全基线检查

确保将`--read-only-port`参数设置为0 | 访问控制

描述：Kubelet流程提供了只读API。对此只读API提供了未经身份验证的访问，该访问可能会检索有关群集的潜在敏感信息。影响：删除只读端口将需要重新配置使用该端口的所有服务，以使用主要的Kubelet API。默认值:默认情况下，--read-only-port设置为10255/TCP。
加固建议：
- 在每个节点上编辑<kubelet_启动文件>文件，新增/修改，KUBELET ARGS参数设置为--read-only-port=0
- 如果您是kubeadm启动、在KUBELET SYSTEM PODS ARGS参数中添加--read-only-port=0 该项可能需与apiserver联动配置，有影响业务的可能性，请k8s管理员专门配置，或忽略如您已经使用systemctl管理工具，可以执行命令 systemctl status kubelet命令查看启动文件路径，默认为/usr/lib/systemd/system/kubelet.service.d 修改后重启生效例如systemctl restart kubelet

确保`--anonymous-auth =false` | 访问控制

描述：启用后，未被其他配置的身份验证方法拒绝的请求将被视为匿名请求。然后，这些请求由Kubelet服务器处理。您应该依靠身份验证来授权访问并禁止匿名请求。
加固建议：在每个节点上编辑<kubelet_config>文件，并将KUBELET_ARGS参数设置为--anonymous-auth =false

确保将kubelet文件权限设置为644或更严格 | 文件权限

描述：kubelet文件控制各种参数，这些参数设置了工作节点中kubelet服务的行为。您应该限制其文件权限以维护文件的完整性。该文件只能由系统上的管理员写入。
加固建议：运行命令chmod 644 <kubelet config>stat -c %a <kubelet _config>查看配置文件权限是否为644<kubelet config>可能存在以下路径：
1
2
3
4
/etc/kubernetes/kubelet.conf, /var/lib/kubelet/kubeconfig, /etc/kubernetes/kubelet-kubeconfig, /var/snap/microk8s/current/credentials/kubelet.config

确保将kubelet文件权限设置为`root:root` | 文件权限

描述：kubelet文件控制各种参数，这些参数设置了工作节点中kubelet服务的行为。您应该设置其文件所有权以维护文件的完整性。该文件应归root:root拥有。
加固建议：执行命令 chown root:root <kubelet_config>修改文件为root所有执行命令，statc %U:%G <kubelet_config>查看是否修改成功
可能存在以下路径
1
2
3
4
/etc/kubernetes/kubelet.conf /var/lib/kubelet/kubeconfig /etc/kubernetes/kubelet-kubeconfig /var/snap/microk8s/current/credentials/kubelet.config

确保将`--client-ca-file`参数设置为适当的值 | 身份鉴别

描述：需要在apiserver和kubelet上配置TLS 从apiserver到kubelet的连接用于获取pod的日志，(通过kubectl)连接到正在运行的pod，以及使用kubelet的端口转发功能这些连接在kubelet的HTTPS端点处终止。默认情况下，apiserver不会验证kubelet的服务证书，该证书会使连接受到中间人攻击，并且无法在不受信任和/或公共网络上运行。启用Kubelet证书身份验证可确保apiserver在提交任何请求之前可以对Kubelet进行身份验证。
加固建议：编辑文件，新增/修改.--client-ca-file=<path/to/client-ca-file>

确保`--authorization-mode`参数未设置为`AlwaysAllow` | 身份鉴别

描述：默认情况下，Kubelet允许所有经过身份验证的请求(甚至是匿名请求)，而无需来自apiserver的明确授权检查。您应该限制这种行为，并且只允许明确授权的请求未经授权的请求将被拒绝。
加固建议：编辑<kubelet_启动文件>添加/修改为--authorization-mode=Webhook或其他值要求--authorization-mode的值不能为AlwaysAllow。

确保`-streaming-connection-idle-timeout`参数未设置为0 | 服务配置

描述：设置空闲超时可以确保您免受拒绝服务攻击，不活动的连接以及临时端口的耗尽。注意:默认情况下，--streaming-connection-idle-timeout设置为4小时，对于您的环境而言可能太高了。适当地设置此设置将另外确保在为合法用例提供服务后，此类流连接超时。默认情况下，--streaming-connection-idle-timeout设置为4小时。
加固建议：编辑<kubelet 启动文件>增加/修改选项--streaming-connection-idle-timeout

容器微隔离技术

应用场景

数据中心安全：在大规模数据中心环境中，微隔离技术可以用于将不同的应用、服务或租户隔离开来，确保它们的通信和数据在逻辑上是相互隔离的。这样可以防止恶意活动或攻击在数据中心内部传播，并保护敏感数据免受未经授权的访问。
云安全：云环境中的微隔离技术可以帮助云服务提供商实现多租户环境下的隔离。通过将不同的租户或用户隔离在独立的微隔离区域中，可以防止攻击者跨租户进行攻击，同时提供更细粒度的访问控制和安全策略，确保每个租户的数据和应用在云环境中得到保护。
工业控制系统(ICS)安全：微隔离技术在工业控制系统中也有广泛的应用。工业控制系统通常包含许多关键的设备和系统,如SCADA(Supervisory Control and Data Acquisition)系统。通过使用微隔离技术，可以将不同的工控设备和系统进行隔离，避免横向传播的攻击，并提供更强的安全保护，确保工业控制系统的稳定和可靠运行。
物联网(IoT)安全：物联网中的设备数量庞大且多样化，安全风险也相应增加。微隔离技术可以应用于物联网环境中的设备隔离，将设备划分为不同的微隔离区域，限制设备之间的通信和访问，防止攻击者通过一个受感染的设备入侵整个物联网系统虚拟化环境安全:微隔离技术在虚拟化环境中也有重要应用。在虚拟化平台中，通过将虚拟机或容器隔离在独立的微隔离区域中，可以提供更强的虚拟机互相隔离和安全性，避免恶意虚拟机对其他虚拟机或宿主机的攻击。
综上所述，微隔离技术的主要应用场景包括数据中心安全、云安全、工业控制系统安全、物联网安全以及虚拟化环境安全。这些场景都需要细粒度的隔离和访问控制，以保护关键系统和数据免受攻击和未经授权的访问。

微隔离能力分类与介绍

微隔离的实现方式是将数据中心内部所有的业务按照特定的原则划分为若干微小区域(称为微分段)，在区域的边界侧存在若干网络层节点，根据动态策略分析对这些节点执行访问控制，从逻辑上可实现微小区域之间的隔离，因而这些节点被称为策略强制点(Policy Enforcement Points，PEPS)。这些PEP节点可将云计算网络中大量的微小区域隔离开，从市限制恶意攻击者的横向移动，减少业务系统被攻破的可能性。

微隔离客户端：主要包括流量信息收集和策略执行两个部分。向控制中心反馈当前网络中的业务流量信息，实时上报业务动态，接收控制中心下发的策略控制指令，执行安全策略动作。
微隔离控制中心：主要包括管理引擎和策略管理两个控制块。管理引擎接收客户端发送的流量数据，并根据这些信息建立业务模型，交由策略管理模块分析当前网络形势，进行多维度策略运算，动态生成安全策略，并下发给客户端执行，通过流量自学习实现策略自适应。
与传统网络不同在于，微隔离架构不再存在内、外网的概念，而是将数据中心网络隔离成了很多微分段。节点如要访问微分段内其他节点的资源，都需要经过微隔离客户端的认证，如果节点身份认证不通过，或不具备访问权限，会被客户端拦截。

#渗透 #安全

HW蓝队/红军——安全布防

https://www.xuchang.dev/post/2cbc6cfa

作者

许畅

发布于

2024年5月25日

许可协议

HW蓝队/红军——防守统筹组织上一篇

描述NGFW数据包转发流程Server-map 下一篇