原创 张琦驹 2025-10-21 18:31 四川
本文针对微服务架构普及下攻击频发，而传统单体蜜罐存在 “适配微服务动态性差、监控覆盖不完整、易被指纹识别” 的问题，提出并实现基于 Kubernetes（K8s）的微服务 Web 蜜罐 HoneyKube，以填补微服务场景蜜罐技术空白。
原文标题：HoneyKube: Designing and Deploying aMicroservices-based Web Honeypot1、引言微服务架构（Microservices Architecture）因具备可扩展性、部署便捷性等优势，已成为亚马逊、Netflix 等企业级 Web 应用的主流架构，但分布式特性也引入新安全风险，针对容器化系统的攻击（如恶意 Docker 镜像传播、容器逃逸恶意软件）呈激增态势。传统入侵检测 / 防御系统多基于单体架构（Monolithic Architecture）设计，难以识别微服务特有的攻击模式（如跨 Pod 横向移动、Kubernetes（K8s）API 滥用）。蜜罐（Honeypot）是收集真实攻击数据的关键工具，然而现有蜜罐均基于单体架构，存在显著不足：一是无法模拟微服务 “多组件、动态编排” 的特性（如 K8s 的 Pod 调度、Service 抽象），攻击面与真实场景偏差大；二是监控能力局限，难以覆盖微服务间内部网络流量、K8s 集群级操作（如 Secrets 窃取、API 服务器未授权访问），无法捕捉完整攻击链；三是隐蔽性不足，易被攻击者通过 Shodan、HoneyScore 等工具 “指纹识别”，导致数据收集质量受限。为填补微服务蜜罐的技术空白，本文设计并部署了HoneyKube—— 基于微服务架构的 Web 蜜罐。通过构建高仿真微服务应用、四层动态监控体系（覆盖外部 / 内部网络流量、系统调用、集群日志），结合低可指纹性设计与安全防护机制，既模拟真实微服务场景吸引攻击者，又能安全可控地收集攻击数据，为微服务架构下的攻击模式分析、专用入侵检测系统设计提供实证支撑。2、微服务蜜罐的设计特性HoneyKube 以 “模拟真实微服务场景、全链路捕获攻击行为” 为核心目标，通过 “低可指纹性优化、四层动态监控构建、微服务高仿真与攻击面设计”，突破传统单体架构蜜罐局限，适配微服务分布式、动态化的技术特征。2.1 低可指纹性：规避蜜罐识别的设计策略识别蜜罐的 “隐蔽性” 是数据质量的前提，HoneyKube 通过多维度设计降低被攻击者识别的概率：蜜罐的 “隐蔽性” 是数据质量的前提，HoneyKube 通过多维度设计降低被攻击者识别的概率：真实应用基底改造：以谷歌云平台（Google Cloud Platform, GCP）开源微服务电商 Demo 为基础深度定制，修改前端 UI 布局消除 “演示应用” 视觉特征，新增用户登录 / 注册功能并联动 MySQL 数据库，构建 “用户 - 商品 - 数据” 的真实业务逻辑，使应用行为与生产级微服务高度契合；生产级 Kubernetes 集群复刻：集群架构严格遵循企业部署规范，核心组件如图 1 所示 —— 包含控制平面（负责微服务调度与状态管理）、节点（计算资源载体）、Pod（封装微服务容器的最小单元）、Service（为 Pod 分配固定访问 IP，适配 Pod 动态生命周期）、Ingress（通过负载均衡向公网暴露 HTTPS 服务，配置 Let’s Encrypt 证书），所有配置与真实微服务集群无差异；Shodan HoneyScore 验证：采用业界主流蜜罐指纹工具 HoneyScore（输入 IP 生成 “蜜罐概率”，取值 0.0~1.0，0.0 代表 “判定为真实系统”、1.0 代表 “判定为蜜罐”）测试，HoneyKube 最终得分为 0.0，证明其能有效规避主流侦察工具的识别。2.2 四层动态监控：覆盖微服务全攻击链路针对微服务 “分布式部署、多组件交互频繁” 的特性，HoneyKube 设计 “外部网络 - 内部网络 - 系统调用 - 集群日志” 四层监控体系，确保攻击行为从初始访问到横向移动均无盲区，整体监控逻辑如图 2 所示：外部网络流量监控：为每个微服务 Pod 部署 Sidecar 容器（与应用容器共享网络命名空间，不干扰应用运行），容器内运行 tcpdump 工具被动捕获公网与集群的交互流量（如攻击者的端口扫描、Web 页面访问、数据外发尝试等），捕获的网络包以 PCAP 格式存储于 PersistentVolume（PV），避免 Pod 重启导致数据丢失；内部网络流量监控：复用 Sidecar + tcpdump 方案，聚焦微服务间的内部通信流量（如前端 Pod 向 Flask API Pod 发起的请求、API Pod 与 MySQL Pod 的数据交互），重点捕捉攻击者突破初始 Pod 后，向其他微服务 “横向移动” 时的跨 Pod 访问行为；系统调用监控：在集群所有节点部署 Sysdig（内核级系统调用捕获工具）与 Falco（云原生入侵检测系统，Intrusion Detection System, IDS）协同工作 ——Sysdig 默认采用 “循环存储” 策略（仅保留固定数量的系统调用日志，旧日志自动覆盖），当 Falco 检测到可疑行为（如 SSH 登录成功、容器内出现挖矿命令）时，会触发 Sysdig 将后续 1000 秒的系统调用日志（SCAP 格式）持久化存储，确保攻击相关操作不遗漏；集群系统日志监控：收集三类核心日志 ——Kubernetes 审计日志（记录所有 Kubernetes API 调用，如 Pod 创建、Secrets 访问、Service 配置修改）、节点操作系统（Operating System, OS）日志（存储于 /var/log 目录，包含系统进程、用户操作记录）、SSH 登录日志（区分成功 / 失败登录尝试，记录登录用户名与来源 IP），通过三类日志的关联分析，可追溯攻击者对集群整体的影响（如是否导致 Pod 崩溃、是否尝试滥用 Kubernetes API）。2.3 微服务高仿真与攻击面注入为吸引攻击者深入操作并模拟真实攻击场景，HoneyKube 基于图 1 所示的 Kubernetes 集群架构，构建高仿真微服务集群，并针对性注入漏洞以扩大攻击面：微服务集群高仿真：基于 GCP 微服务 Demo 改造，最终形成由 14 个微服务构成的集群（分布于 4 个节点、14 个独立 Pod），涵盖前端 UI、Flask API、MySQL 数据库、支付流程模拟等典型电商模块，各微服务通过 Kubernetes Service 实现动态发现与通信，完全复现真实微服务的部署与交互逻辑；攻击面与漏洞注入：参考 Azure Kubernetes 威胁矩阵（类似 MITRE ATT&CK 框架的微服务专项版本），注入覆盖 “初始访问 - 代码执行 - 凭证获取 - 横向移动” 完整攻击链的漏洞：初始访问阶段：在前端 Pod 部署 SSH 服务并设置弱凭证（admin:password123），同时通过前端 Web 服务报错暴露 Golang 版本（v1.11.5，含 CVE-2019-9741 漏洞）；代码执行阶段：在 Flask API Pod 中不做用户输入过滤，允许 SQL 注入攻击；凭证获取阶段：授权前端 Pod 的 ServiceAccount 访问 Kubernetes Secrets（包含 MySQL 数据库凭证、其他 ServiceAccount 令牌）；横向移动阶段：在部分 Pod 预装 curl、wget 等工具，并允许 ServiceAccount 列出集群内所有 Service 与端点，方便攻击者探测网络，确保攻击者能沿攻击链深入操作。3、HoneyKube 的架构与框架实现HoneyKube 的核心价值源于 “微服务架构仿真 + 全链路监控联动 + 安全防护协同” 的框架设计，通过各组件的深度联动，既模拟真实微服务场景，又能安全可控地捕获攻击数据。3.1 微服务集群的架构基础HoneyKube 基于 Kubernetes 构建高仿真微服务集群，其架构核心组件与联动逻辑如图 1 所示，为蜜罐的 “真实性” 与 “攻击面” 提供支撑：核心组件构成：集群包含控制平面（负责 Pod 调度、Service 管理等集群编排）、4 个节点（作为微服务的计算载体）、14 个 Pod（每个 Pod 封装 1 个微服务，如前端 UI、Flask API、MySQL 数据库等）、Service（为 Pod 分配固定虚拟 IP，解决 Pod 动态重启后的访问问题）、Ingress（通过负载均衡向公网暴露 HTTPS 服务，配置 Let’s Encrypt 证书确保通信真实性）；组件联动逻辑：前端 UI Pod 接收公网请求后，通过 Service 转发至 Flask API Pod，API Pod 再通过另一个 Service 访问 MySQL Pod 进行数据交互，整个流程与真实微服务的 “请求 - 服务 - 数据” 链路完全一致，同时 Ingress 统一管理公网流量入口，确保外部访问体验与生产环境无差。3.2 监控组件的全链路联动四层监控体系的各组件并非孤立工作，而是通过 “数据流转 + 触发机制” 实现全链路联动，确保攻击行为从 “网络接入” 到 “集群影响” 均被捕获，其联动逻辑如图 2 所示：网络流量与系统调用的联动:Sidecar 容器捕获的 PCAP 流量中，若包含 SQL 注入、SSH 登录等可疑行为，会触发 Falco 生成警报；Falco 警报进一步触发 Sysdig 持久化后续系统调用日志，实现 “流量异常 → 系统行为追溯” 的联动（例如，当流量中出现 SQL 注入 payload 时，不仅能捕获网络包，还能通过系统调用日志还原攻击者在容器内执行的后续命令）；系统调用与集群日志的联动：Sysdig 捕获的系统调用（如攻击者尝试读取 K8s Secrets 文件），会与 K8s 审计日志中 “Secrets 访问 API 调用” 关联，同时结合节点 OS 日志中的文件访问记录，完整还原 “攻击者通过容器内操作 + K8s API 滥用” 的横向移动行为；存储与分析的联动：所有监控数据（PCAP、SCAP、日志）存储于 PersistentVolume（PV）后，可通过 kubectl 或专用分析工具（如 Elastic Stack）进行聚合分析，从 “单条日志 / 流量” 延伸到 “攻击链全流程” 的可视化与溯源。3.3 安全防护的协同机制为防止蜜罐被攻击者滥用（如作为跳板发起 DDoS、钓鱼攻击），HoneyKube 设计 “容器 - 网络 - 集群” 多层防护的协同机制，确保 “吸引攻击” 与 “安全可控” 的平衡：容器层防护与业务的协同：通过 Pod Security Context 配置（privileged: false 禁用特权容器、runAsNonRoot: true 以非 root 用户运行、allowPrivilegeEscalation: false 禁止权限提升），限制容器内攻击行为的影响范围，同时不破坏微服务的正常业务逻辑（如前端 Pod 仍可正常提供 Web 服务、API Pod 仍可访问数据库）；网络层防护与访问的协同：网络策略仅开放必要端口（入站 22/SSH、80/HTTP、443/HTTPS；出站仅允许 HTTP/HTTPS），阻断恶意流量外溢的同时，不影响微服务间的正常内部通信（如 Pod 间通过 Service 访问的流量不受限）；节点 SSH 仅授权监控服务器 IP 访问，避免攻击者通过节点 SSH 突破集群边界；集群层防护与监控的协同：启用 Kubernetes RBAC（基于角色的访问控制），限制 Pod 对 K8s API 的访问权限（如前端 Pod 的 ServiceAccount 仅能读取部分 Secrets，无法修改集群资源）；结合监控体系中 K8s 审计日志的实时分析，若发现异常 API 调用（如批量删除 Pod），可快速定位并拦截，实现 “防护 + 监控” 的闭环。4、实验评估为验证 HoneyKube 在 “真实攻击捕获、低可指纹性、安全可控” 方面的有效性，论文设计 “开放实验” 与 “受控实验” 双场景，结合数据统计与工具验证，全面评估蜜罐性能与攻击捕获能力。4.1 实验设计4.1.1 实验环境与基础配置实验基于谷歌 Kubernetes 引擎（Google Kubernetes Engine, GKE）部署，核心环境参数与架构支撑如下：集群配置：集群包含 1 个控制平面与 4 个节点，节点采用 E2 系列高 CPU 机型（4 核 vCPU、4GB 内存），操作系统选用 Ubuntu（而非 GKE 默认的 Container-Optimized OS），以支持 Sysdig 内核级系统调用捕获；蜜罐部署:基于图 1 所示的 Kubernetes 集群架构，部署 14 个微服务 Pod（含前端 UI、Flask API、MySQL 数据库等），通过 Ingress 暴露 HTTPS 服务（配置 Let’s Encrypt 证书），SSH 服务单独作为独立 Service 暴露（IP 通过 robots.txt 文件间接泄露给攻击者）；监控工具配置：Sidecar 容器运行tcpdump捕获流量（PCAP 格式存储于 PersistentVolume），节点部署 Sysdig（循环存储系统调用日志）与 Falco（触发日志持久化阈值设为 “SSH 登录”“异常命令执行” 等可疑行为）。4.1.2 伦理与变量控制伦理合规：实验前通过荷兰特文特大学（University of Twente）伦理委员会审批，所有受控实验参与者签署知情同意书，明确实验目的与操作边界；变量控制：开放实验与受控实验的蜜罐配置完全一致（微服务数量、漏洞类型、监控规则相同），仅公网访问权限差异（开放实验暴露公网，受控实验仅允许参与者 IP 访问），排除配置差异导致的实验偏差；安全防护兜底：启用 Pod Security Context（非 root 用户、禁用权限提升）、网络端口限制（仅开放 22/SSH、80/HTTP、443/HTTPS）、节点 SSH IP 白名单，防止攻击者滥用蜜罐发起对外攻击（如 DDoS、钓鱼）。4.1.3 实验类型与周期开放实验：将 HoneyKube 暴露于公网，通过 Ingress 接收 HTTPS 请求、独立 Service 接收 SSH 请求，持续 2 周，目标是捕获互联网中真实的自动化攻击（如 bots 扫描、暴力破解）；受控实验：仅允许两类参与者访问（本地 CTF 团队：无 Kubernetes 经验；中型安全公司红队：中高级微服务渗透经验），持续 3 周，目标是捕获针对性攻击（如人工利用微服务漏洞），参与者任务为 “渗透蜜罐并获取 MySQL 数据库中用户隐私信息”。4.2 核心实验结果4.2.1 数据收集结果：全链路攻击数据捕获实验共收集约 850GB 攻击相关数据，涵盖 “系统调用、网络流量、集群日志” 三类核心数据，具体统计如下：系统跟踪文件（SCAP）：占比约 94%（≈800GB），由 Sysdig 捕获，仅当 Falco 触发异常警报（如 SSH 登录成功、容器内出现 “miner”“curl” 等可疑命令）时持久化存储，记录攻击者在容器 / 节点内的系统调用（如文件读写、命令执行）；网络跟踪文件（PCAP）：占比约 1%（≈8GB），由 Sidecar 容器的tcpdump捕获，包含公网与集群的外部流量（如 SSH 暴力破解数据包）、微服务间的内部流量（如攻击者横向移动时的 Pod 间通信）；攻击链完整性：HoneyIoT-camera 能引导 87% 的攻击者完成 “攻击前检查→漏洞利用→恶意软件上传” 的完整流程，例如攻击者先访问/favicon.ico文件识别设备类型（TP-Link 相机），再利用 CVE-2020-12109 漏洞上传恶意脚本（如图 3 (a) 所示）；而对比组因响应逻辑生硬，仅 30%-40% 的攻击能进入漏洞利用阶段。攻击会话与交互深度：HoneyIoT-camera 共接收 29467 个攻击会话，平均每个会话包含 7.57 个攻击者请求数据包，显著高于基线蜜罐（26301 个会话，平均 4.97 个请求）与 Snare&Tanner（28660 个会话，平均 4.02 个请求），说明其动态响应能持续吸引攻击者，避免会话提前终止；集群日志：占比约 5%（≈42GB），含 Kubernetes 审计日志（≈40GB，记录 API 调用如 Secrets 访问、Pod 创建）、节点 OS 日志（/var/log 目录下的登录记录、进程日志）、SSH 登录日志（记录 11500 + 次 SSH 尝试的用户名与来源 IP）。4.2.2 可指纹性验证：规避蜜罐识别工具采用 Shodan HoneyScore 工具（分值范围 0.0~1.0，0.0 代表 “判定为真实系统”，1.0 代表 “判定为蜜罐”）评估 HoneyKube 的隐蔽性，结果如下：验证结果：HoneyKube 的 HoneyScore 得分为 0.0，被 Shodan 判定为 “真实微服务系统”，未触发任何蜜罐特征标记；核心原因：蜜罐基于 GCP 开源微服务 Demo 深度改造（无 “演示应用” 特征）、采用生产级 Kubernetes 配置（Ingress+HTTPS、Service 固定 IP），且无已知蜜罐的硬编码响应或特殊端口配置，与真实企业微服务集群无差异；对比意义：现有单体架构蜜罐（如 ICS 领域的 HoneyPLC）虽也能达到 0.0 分，但 HoneyKube 是首个在微服务架构下通过该验证的蜜罐，证明其适配微服务场景的隐蔽性设计有效。4.2.3 开放实验：公网自动化攻击行为分析开放实验（2 周）主要捕获互联网中自动化 bots 发起的攻击，核心攻击行为与数据统计如下：SSH 暴力破解：前端 Pod 的 SSH 服务记录 11500 + 次登录尝试，来自 200 + 个 distinct IP（覆盖 36 个国家），其中美国（2114 次）、越南（1946 次）、俄罗斯（757 次）为攻击来源 Top3（具体数据可参考表 1）；仅 12 次尝试成功登录（弱凭证admin:password123），且多数登录后立即断开（推测为 bots 扫描行为）；攻击行为特征：成功登录的攻击者中，部分尝试执行恶意操作 —— 如运行 “miner” 相关命令（试图挖掘门罗币）、用grep搜索挖矿进程、删除容器内/var/log目录下的系统日志（防御规避行为，对应 Azure K8s 威胁矩阵中的 “日志清除” 战术）；仅 1 例攻击存在命令延迟（如ls -la与sudo -i间隔 8 秒），推测为手动攻击（尝试连接 DHCP 服务器以持久化访问）；监控有效性：四层监控体系完整捕获攻击链 ——tcpdump捕获 SSH 暴力破解的网络包，Sysdig 记录挖矿命令与日志删除的系统调用，Kubernetes 审计日志追踪攻击者尝试访问 Secrets 的 API 调用，证明监控能覆盖 “初始访问→命令执行→防御规避” 全流程。4.2.4 受控实验：针对性微服务攻击行为分析受控实验（3 周）通过两类参与者模拟 “目标明确的攻击”，揭示微服务特有的攻击模式，核心发现如下：不同技术水平攻击者的行为差异：CTF 团队（无 K8s 经验）：以 “手动探测 + 暴力破解” 为主 —— 通过浏览前端页面寻找漏洞，对 SSH 服务发起root/admin用户名的暴力破解，依赖linPEAS（Linux 权限提升扫描工具）探索容器环境，偶然发现 Pod 内挂载的 ServiceAccount 令牌；红队（中高级 K8s 经验）：以 “自动化工具 + 微服务特性利用” 为主 —— 用nmap扫描集群端口，通过 SQL 注入（Flask API 未过滤输入）获取 MySQL 数据库凭证，借助peirates（Kubernetes 渗透工具）直接读取 K8s Secrets，进而列出集群内所有 Service 与端点，实现横向移动；微服务攻击链特征：参与者均需经历 “初始访问（SSH 弱凭证 / SQL 注入）→凭证获取（ServiceAccount 令牌 / Secrets）→横向移动（Pod 间通信）→目标达成（访问 MySQL 用户数据）”，与传统单体架构攻击（仅需突破单一入口）差异显著，且 K8s 专用工具（如peirates）能大幅提升攻击效率；监控捕获能力：Falco 成功触发所有关键攻击行为的日志持久化 —— 如 SQL 注入时的 “异常数据库查询”、peirates调用 K8s API 时的 “Secrets 访问”，Sysdig 记录的系统调用完整还原攻击者 “读取令牌→查询 API→访问数据库” 的操作序列。4.3 实验结论实验结果验证了 HoneyKube 的设计有效性，同时揭示微服务架构下的攻击特征，核心结论如下：低可指纹性与攻击捕获能力：HoneyScore 0.0 分证明其能规避主流蜜罐识别工具，850GB 全链路数据（系统调用、网络流量、集群日志）表明监控体系可完整捕获 “自动化攻击” 与 “针对性攻击” 的攻击链；微服务攻击模式差异：开放实验以自动化 bots 的 “暴力破解 + 简单恶意命令” 为主（与单体架构攻击相似），受控实验则体现微服务特有的 “K8s API 滥用、跨 Pod 横向移动”，需专用工具（如peirates）适配，为微服务安全防护提供实证依据；安全可控性：Pod 权限限制、网络端口过滤等措施有效阻断攻击者滥用行为（如未出现 DDoS 外发流量、容器逃逸），平衡 “高交互性” 与 “安全风险”；数据价值：开源的攻击数据集与源代码，填补 “微服务架构攻击数据” 的空白，为后续微服务入侵检测系统（IDS）设计、攻击模式分析提供支撑。5、总结本文针对微服务架构普及下攻击频发，而传统单体蜜罐存在 “适配微服务动态性差、监控覆盖不完整、易被指纹识别” 的问题，提出并实现基于 Kubernetes（K8s）的微服务 Web 蜜罐 HoneyKube，以填补微服务场景蜜罐技术空白。HoneyKube 核心设计包括：以谷歌云平台（GCP）微服务电商 Demo 改造 14 个微服务集群（4 节点 14Pod），复刻企业级部署逻辑；构建 “外部网络 - 内部网络 - 系统调用 - 集群日志” 四层监控，通过 Sidecar、Sysdig 与 Falco 联动捕获全链路攻击；搭配 Pod 权限限制、网络端口过滤防滥用，经 Shodan HoneyScore 验证得 0.0 分，判定为真实系统。实验通过开放与受控场景，累计收集 850GB 数据并开源。研究提供微服务蜜罐方案、填补数据集空白，未来将提取攻击模式、验证多容器平台通用性，优化漏洞与监控，支撑微服务安全防护。
原文作者：Chakshu Gupta, Thijs van Ede, Andrea Continella
原文链接：https://ris.utwente.nl/ws/portalfiles/portal/330389896/main.pdf
发表会议：2023 IEEE Security and Privacy Workshops (SPW)
笔记作者：张琦驹@安全学术圈
主编：黄诚@安全学术圈
编辑：张贝宁@安全学术圈
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com
专题最新征文
- 期刊征文 | 暗网抑制前沿进展 (中文核心)
期刊征文 | 网络攻击分析与研判 (CCF T2)
期刊征文 | 域名安全评估与风险预警 (CCF T2)
