Rhosinjay-cyb/Microsoft-Sentinel

## 项目标题 使用 Microsoft Sentinel 管理安全运营 ## 目标 本项目的目的是在日志分析工作区中部署 Microsoft Sentinel，以利用其安全信息与事件管理（SIEM）以及安全编排、自动化和响应（SOAR）能力来管理安全运营，涵盖从收集各种 Azure 服务和资源的日志到通过剧本进行威胁修复的整个过程。 ## 使用的工具 Microsoft Sentinel（Azure 门户）、Microsoft Defender 门户 ## 实验环境搭建 * 在日志分析工作区中部署 Microsoft Sentinel * 通过诊断设置将 Azure Bastion 日志转发到 Sentinel 工作区 * 通过 Azure Activity 连接器启用 Azure Activity 日志的摄入 * 配置从虚拟机收集并转发 Windows 安全事件到 Sentinel 工作区 * 使用 Kusto 查询语言（KQL）查询开发并实现分析规则以增强威胁检测能力 * 实现 SOAR 工作流程以支持高效的安全事件修复 ## 架构图 ## 前言 本项目建立在之前关于 Azure 防火墙的项目之上，重点关注安全解决方案的运营（SecOps）方面，包括日志记录、监控、威胁检测和事件修复。必要时将引用以前的项目；然而，所有基础概念和配置都将得到清晰解释。Azure 防火墙在上一个项目中与其他 Azure 服务和资源（Azure Bastion、虚拟机、日志分析工作区）一起部署，以形成一个安全解决方案。本项目现在旨在通过将 Azure 防火墙、Azure Bastion、虚拟机（VM）和 Azure 订阅的日志摄入到集成 Sentinel 的工作区中，监控该安全解决方案以提高其效率和弹性，从而在环境中实现全面的安全监控和有效的威胁检测。Azure 防火墙的日志将用于监控网络流量和 Web 访问，以检测对受限或恶意网站的访问。另一方面，Azure Bastion 的日志将用于监控远程访问活动，以检测异常或未授权的访问。Azure Activity 将用于监控控制平面操作，以检测配置的篡改，例如防火墙策略的修改，而虚拟机的日志将用于监控操作系统和用户级事件，以检测暴力破解和账户劫持等攻击。 ## 采取的步骤 项目按以下顺序实施。 ### 1. 部署 Microsoft Sentinel 项目从在 Project-workspace（此日志分析工作区是在上一个项目中创建的，并且已配置为接收 Azure 防火墙日志）中部署 Microsoft Sentinel 开始，以拥有一个集成 Sentinel 的工作区。  ### 2. 日志摄入 随后，Azure Bastion 日志通过诊断设置（Project-BST-logs）转发到集成 Sentinel 的工作区。  Azure Bastion 日志存储在集成 Sentinel 工作区中的 MicrosoftAzureBastionAuditLogs 表中。确认工作区现在正在接收来自 Azure Bastion 的日志。  此外，包含在 Azure 订阅中执行的活动（包括对防火墙的任何更新）的 AzureActivity 日志通过 Azure Activity 连接器转发到集成 Sentinel 工作区。该过程从从内容中心安装 Azure Activity 连接器开始，并以配置连接器结束。  现在，Azure Activity 日志在集成 Sentinel 工作区中可见，如下所示。  为了将虚拟机上的日志摄入到集成 Sentinel 工作区，从内容中心安装了 Windows Security Event 解决方案。  然后通过连接器页面配置 Windows Security Event via Azure Monitor Agent (AMA)。  配置连接器的一个重要步骤是创建数据收集规则（DCR）。 这允许指定目标资源（VM）和从中收集的事件。  DCR 创建完成后，会自动在虚拟机上安装 AzureMonitorWindowsAgent 扩展。  注意：如果 DCR 是在 Microsoft Sentinel 中创建的，Windows 事件日志数据将存储在 SecurityEvent 表中；但如果 DCR 是在 DCRs 环境中创建的，则事件将存储在 Event 表中，而不会使用专门的安全解决方案。 连接器配置完成后，连接器的状态现在变为已连接，这意味着代理已在目标资源上安装，并准备好开始收集日志以转发到集成 Sentinel 工作区。图像还显示了表管理和 DCR 属性。  配置完成后，我注意到工作区没有接收日志，尽管连接器状态显示为已连接。经过不懈的排查，我意识到虚拟机位于防火墙之后（在上一个项目中，防火墙被部署用于控制虚拟机的出站流量，因此影响了虚拟机上的代理向集成 Sentinel 工作区发送日志的能力）。要允许防火墙放行流量，需要了解流量是如何从代理路由到集成 Sentinel 工作区的。 通常，流量从虚拟机路由到互联网上的 Azure Monitor 端点，然后到达工作区。因此，允许代理访问 Azure Monitor 端点将解决此问题。  网络规则用于通过在规则中指定 Azure Monitor 作为服务标签来允许代理流量访问 Azure Monitor。  配置完成后，观察到两个虚拟机上的代理现在正在向集成 Sentinel 工作区发送日志。  #### 2.1 检测到的暴力破解攻击 除了检查虚拟机的成功登录外，我还检查了失败的登录尝试，并发现了一些有趣的情况。我检测到一个正在进行的暴力破解攻击。我可以看到在短短几秒钟内尝试了数百个用户名。显然，攻击发生在我能够访问虚拟机的安全事件数据之前。这种经历本身就让我认识到对整个 IT 环境进行全面可见性的重要性。  在某些情况下，用户名中使用的语言和其他一些独特特征可能会提供关于攻击来源或攻击者人口统计特征的线索。  暴力破解攻击的发生是因为远程桌面协议（RDP）端口暴露在了互联网上，尽管流向该端口的流量被路由通过防火墙。从我的分析来看，攻击者的源 IP 来自 AzureFirewallSubnet 地址空间。攻击者能够通过防火墙的公共 IP 地址尝试连接到虚拟机，因为 DNAT 规则允许来自任何 IP 地址的连接，但连接并未成功。这使得 Azure Bastion 成为与直接通过 RDP 连接相比，更安全的远程连接虚拟机的选项。最后，通过阻止将 RDP 端口暴露到互联网来修复了攻击。  防止攻击的另一种建议是将源 IP 限制为特定批准的 IP 地址，而不是 DNAT 规则中的任何 IP 地址。这将阻止攻击者通过防火墙的公共 IP 建立连接，同时 RDP 端口仍然暴露于互联网。 ### 3. 创建分析规则 接下来的任务是创建分析规则，以检测摄入到集成 Sentinel 工作区中的多个日志中的安全威胁。首先，模拟了一个安全威胁并创建了一个分析规则来检测它。从 Azure Bastion 开始，使用另一个公共 IP 通过 Bastion 连接到虚拟机，模拟了一个异常或未授权 IP 通过 Azure Bastion 连接到虚拟机意味着安全威胁的场景。然后编写了一个 Kusto 查询语言（KQL）查询来检测它。之后，该查询被用于创建一个分析规则，该规则将在下次使用不同的公共 IP（而非受信任的 IP）时触发警报。  这里创建的警报规则类型是计划规则，这意味着查询将在指定的时间间隔运行以检测安全威胁。这里指定了警报的名称（Unusual IP - Bastion Access）以及创建过程中的其他步骤。创建警报规则的一个重要部分是实体映射，它通过添加有关警报详细信息的更多内容来丰富警报，为支持调查提供清晰的上下文，同时使其更易于修复。  规则创建后自动运行。由于威胁已被模拟，运行查询会生成一个警报。  还为其他日志创建了分析规则。 AzureActivity 表记录订阅中资源和服务的创建或更新。在这种情况下，监控防火墙策略，确保防火墙策略配置的篡改不会被忽视，从而防止破坏安全解决方案。为了模拟安全威胁，修改了防火墙策略，并使用该 KQL 查询进行威胁检测。  从查询创建的警报规则（防火墙策略修改）  警报规则的生成  下一个是防火墙日志，特别是应用程序规则。AZFWApplicationRule 表包含应用程序规则的日志数据，并对此进行查询以了解用户试图连接的受限 Web 应用程序的上下文，这些当然被拒绝了。 由于包含其他后台服务的域，最初用于检测威胁的 KQL 查询并不有效。  之后，通过减少误报并移除嘈杂的域来优化查询。  随后创建了分析规则（受限 WebApp 访问）  ... 以及使用该分析规则生成的警报  最后一部分是创建用于检测虚拟机中安全威胁的分析规则。这始于模拟一个场景，其中尝试访问 VM 的用户尝试了多次错误密码，但最终获得了访问权限。这种值得注意，因为它可能是合法用户忘记了密码，也可能是未授权用户试图多次尝试访问。因此，这种威胁需要尽快密切关注。威胁检测的 KQL 查询如下所示。  然后，使用该查询创建分析规则（可能的账户劫持）。  模拟安全威胁后，分析规则在规则创建完成后返回警报。  注意：还有随数据连接器一起提供的内置分析规则，例如 Azure Activity 数据连接器包含 14 个可用于促进威胁检测的规则。这些规则可以作为基础进行修改以适应您的应用程序。然而，我决定从 KQL 查询创建自己的规则，因为我需要确信该规则可以在创建分析规则之前检测到模拟的攻击。  ### 4. 实现 SOAR 为了促进由分析规则生成的安全警报的自动修复，利用了 Microsoft Sentinel 的 SOAR 功能。首先，从内容中心安装了包含各种基本剧本的 Sentinel SOAR Essentials 解决方案。  随后，配置了其中一个剧本（Send-basic-email），以便在触发警报时将包含事件详细信息的电子邮件发送给安全团队以实现快速响应。在这种情况下，剧本将配置为在检测到不寻常的 Bastion 访问时向安全团队成员发送事件详细信息的电子邮件。  剧本配置完成后，将其添加到活动剧本列表中。  随后实施了剧本的必要修改以适应其预期应用。  为了确保在生成警报后运行剧本，修改了生成警报的分析规则。  修改基本上是向分析规则的自动化选项卡添加自动化规则。剧本将在自动化规则中被调用，因此自动化规则充当分析规则和剧本之间的桥梁。  分析规则修改完成。  ### 5. 测试 SOAR 首先，通过使用与受信任 IP 不同的公共 IP（通过连接不同的互联网服务提供商更改了公共 IP）连接到 Azure Bastion 上的 HR-VM 来模拟安全威胁。  随后，分析规则生成了警报。  ... 并且剧本被触发，结果向安全团队成员发送了电子邮件通知以进行紧急响应。  ## 结论 本项目强调了 SIEM 和 SOAR 解决方案的重要性，它们不仅在保护设备方面，而且在随时间推移监控安全解决方案的有效性和弹性方面也至关重要。它还强调了从多个日志来源收集日志的相关性，以提供全面的可见性，实现跨来源关联，检测多样化的攻击向量，并支持自动化的安全事件响应，从而提高环境的整体安全态势。 ## 未来工作 在完成本项目期间，我探索了 Microsoft Sentinel 的关键领域，包括日志摄入、KQL 查询、分析规则创建、事件调查和使用剧本进行自动化，并能够高效地完成相关任务。这表明我对 Microsoft Sentinel 作为网络安全分析工具的熟悉程度和实践经验都很扎实。展望未来，更多的项目将侧重于深化事件调查方面的专业知识，并通过实施更高级的剧本来增强自动化能力，以支持安全运营。 ## 过去项目 https://rhosinjay-cyb.github.io/Azure-Firewall/

标签：AMSI绕过, Azure Bastion, Azure Sentinel, Azure 活动日志, Azure 防火墙, Diagnostic 设置, FTP漏洞扫描, KQL, Kusto 查询语言, Log Analytics 工作区, Microsoft Defender, Microsoft Sentinel, Playbook, SecOps, SOAR, Windows 安全事件, 云安全架构, 分析规则, 告警修复, 威胁检测, 安全信息与事件管理, 安全威胁, 安全编排, 安全运营, 安全运营平台, 扫描框架, 搜索引擎爬取, 日志收集, 日志转发, 自动化响应, 速率限制, 门户管理