↓跳到主要内容
  1. Posts/

十万火急：云上应急响应概述

·
云 安全建设 应急响应
目录

对工作中的云上应急响应流程进行总结整理。

场景 #

云上应急响应场景大致可以分为三类，依出现频率从高到低排序如下：

  1. Web 入侵：通过 Web 应用/框架/配置漏洞发起攻击，从而实现入侵的场景
  2. 授权入侵：通过社工、OSINT 等间接方式获取授权信息，如账号密码、AK 等，在不进行攻击的情况下实现入侵的场景
  3. 网络入侵：通过非 Web 应用层漏洞，如 OS 漏洞、通信协议漏洞等实现入侵的场景

这三种场景在传统应急响应中同样存在，但第二种场景到了云上变得极为常见，主要原因在于：

  1. 利用难度变得非常低：AK 泄露屡见不鲜，攻击者可以通过多种方式获取到企业的 AK 等凭证
  2. 危害性更高：权限配置不当的 AK 等凭证可以让攻击者轻松接管整个云环境

流程 #

应急响应的 PDCERF 模型将应急响应流程分为 6 个阶段：准备（Preparation）、检测（Detection）、抑制（Containment）、根除（Eradication）、恢复（Recovery）、跟踪（Follow-up）。根据实际工作场景需要，我们对上述流程进行了一些调整：准备阶段融入到日常工作中，检测阶段细分为发现异常和事件确认两个流程，根除、恢复阶段合并为事件处理流程，并且在中间添加了入侵分析流程。

1. 发现异常 #

  1. 主动发现：通过云安全产品告警发现，以云安全中心为主
  2. 被动发现：由客户或第三方主动告知异常情况发现，此时客户或第三方与对接人员同步，随后对接人员联络指定的应急人员进行事件确认

异常事件可以简单分为如下几类：

  1. 网络攻击事件：暴力破解、漏洞扫描和利用等
  2. 恶意程序事件：挖矿程序、病毒、远控木马、勒索软件等
  3. Web 恶意代码事件：Webshell、网页挂马、暗链植入等
  4. 业务安全事件：数据库篡改、信息泄露等

2. 事件确认 #

  1. 主动发现的情况下，根据产品告警信息中包含的事件类型、资产信息等判断是否属于应急事件、是否需要处理
  2. 被动发现的情况下，由客户提供异常信息、受影响的资产信息等，应急人员根据这些信息判断是否属于应急事件、是否需要处理

这一过程中可能需要应急人员与对接人员和客户沟通。如果最终判断无需处理，则可以进一步调查，确认是否存在潜在安全隐患，并反馈给对接人员和客户，结束本次应急响应；如果判断为需要处理，则需判断处理方式，如远程处理/现场处理等。

事件确认流程以快速信息收集为主，例如：

  • 通过 top 命令检查进程 CPU/内存占用，挖矿程序通常会有极高占用率
  • 通过 ps 或 tasklist 命令检查进程列表中是否存在可疑进程，如反弹 shell 进程等
  • 通过 netstat、lsof 等网络相关命令查看系统网络连接状态、开放端口等

对于信息泄露类应急事件，应与客户确认是否属于客户的相关信息，以及数据敏感程度、影响范围等。

3. 抑制止损 #

确认事件需要处理后，建议优先保存快照从而保留证据（如有必要可进行数据备份），并快速确定影响范围。随后尝试多种方式阻断攻击：

  1. 通过云安全产品阻断攻击
    1. 与客户确认能否停止服务隔离主机/网段，如果允许则立即通过 ECS 安全组阻断主机/网段所有流量
    2. 尽量优先分析出攻击源 IP 与外联 IP，并在 CFW 中添加策略阻断入方向攻击源 IP 和出方向外联 IP
  2. 手动阻断攻击
    1. 清除可疑进程和文件
    2. 断开可疑网络连接
    3. 关闭非必要的端口和服务
    4. 切换业务到备用集群

对于信息泄露类应急事件，可以通过截图、网页备份等方式保留证据。随后尽快定位泄漏人员并要求删除相关信息，同时尽快停用/更换泄露的敏感信息。

4. 入侵分析 #

由客户提供受影响资产的登录方式及管理员权限，应急人员通过深入检查系统日志、端口、服务、进程、文件等确定攻击路径，例如：

  • 收集被感染文件/恶意程序样本，并进行静态/动态分析
  • 通过 Everything 或 find 检查文件相关时间
  • 通过 ps 或 Process Explorer 检查进程相关时间
  • 通过任务管理器、计算机管理、资源监视器、注册表编辑器等工具辅助分析
  • 通过 netstat、lsof 等网络相关命令检查网络状态
  • 通过 cat /etc/passwd 或 net user 检查后门用户
  • 通过 chkrootkit、rkhunter 检查可疑驱动
  • 通过 crontab、/etc/cron.d/0hourly、/etc/cron.hourly/0anacron、/var/spool/cron 等检查可疑计划任务
  • 通过 chkconfig 检查服务自启动状态
  • 通过 last、find 或事件查看器查看系统日志、系统安全日志、系统审计日志、业务日志、安全软件日志、第三方流量日志等

这一部分同样以信息收集为主，主要目的是通过确定攻击时间、攻击来源、攻击目标、攻击手段、攻击者行为等信息，拼凑和推导出攻击方式、攻击者意图、漏洞类型、攻击链路等，从而了解事件全貌，并进行相关的修复和加固。对于信息泄露类应急事件，需要排查泄露的信息是否被恶意利用。

5. 事件处理 #

确认入侵原因后，应急人员需进一步清除系统中的恶意进程、文件、服务、Web 页面等，恢复被篡改的数据与配置，并恢复业务正常运行。此外，还可以对入侵进行溯源，并协助修复造成入侵的漏洞。

需要注意，由于涉及对系统本身的修改，这一过程需要由客户授权后进行；若过程中对业务产生较大影响，可以用快照进行回滚。

6. 总结报告 #

应急人员根据本次应急流程整理出一份应急报告，并反馈给客户；或由对接人员反馈至客户。如果发现漏洞（或端口暴露/配置不当/其他问题等）且客户愿意配合修复，则可在修复后进行复测，确保攻击入口被封堵。

原则 #

  • 最大程度降低影响，第一时间恢复业务
  • 优先收集容易丢失的信息
  • 获取关键性证据，如样本、端口、进程、文件、流量等
  • 避免在过程中造成二次灾害

常见攻击入口/配置问题 #

根据过往经验，应急事件常常由以下配置问题引发：

  • Web 应用漏洞
    • Java 应用漏洞
      • 主流 Java 框架：Shiro, Fastjson, Log4j, Jenkins, Spring Boot, Tomcat, Dubbo, Druid, Swagger…
      • RuoYi
      • XXL-Job
    • 其他应用漏洞
      • UEditor
      • 国产 OA
      • 文件上传漏洞
      • 业务逻辑漏洞
    • 应用后台弱口令
  • AK 泄露
  • 重要端口对公网开放
    • SSH/RDP/Redis/Docker 最多
  • 弱口令
    • SSH/RDP/Redis/Jenkins/SQLServer/应用后台管理员 弱口令最多
    • 其他服务包括 RDS、Oracle、VPN 账号、域用户等
    • 变体：多台服务器共用密码/密钥
  • 缺少日志
    • WAF 日志
      • 无 WAF
      • 日志未开启
      • 域名未接入
      • 未开启源站保护（攻击者可不经过 WAF 直接访问源站）
      • 日志记录不完整，如未记录 POST Body
      • 日志容量不足导致过往日志被覆盖，影响排查
    • Web 访问日志
    • Redis 日志
↑