Day04 Web应用蜜罐系统堡垒机运维API内外接口第三方拓展架构部署影响
我的博客园笔记
一、蜜罐系统
1、基本概念
- 主动防御技术：蜜罐是入侵检测技术的重要发展方向，通过模拟存在漏洞的主机或服务，诱骗攻击者进行攻击，从而延缓其对真实目标的攻击，并为取证分析提供线索。
- 本质：一个包含漏洞的诱骗系统，伪装成正在运行的系统，等待攻击者攻击。
2、核心特点
- 高度敏感：对任何异常活动都能感知并持续大量报警，攻击行为几乎必然触发告警。
- 捕捉攻击细节：能够记录攻击者的完整行为（如
whoami、nmap探测等），协助攻击溯源和分析攻击链。
3、主要价值
- 延缓攻击：消耗攻击者大量时间在伪目标上，延缓对真实系统的攻击。
- 取证分析：记录攻击者的探测与入侵行为，为研究攻击手法、溯源提供依据。
- 双重价值：即“延缓攻击 + 取证分析”。
4、典型部署与使用建议
- 推荐工具：HFish（免费且好用，官网 https://hfish.net/#/），部署简单，文档丰富；对安全要求更高的企业可选商业版。
- 报警配置：必须配置报警通道（企业微信、钉钉、飞书、邮件等），确保能通过手机第一时间收到告警。
- 覆盖范围：在不同业务区域（特别是做了网络隔离的区域）都部署蜜罐节点，保证每个网络区域都能被蜜罐系统覆盖。
5、典型应用场景
金融系统：常与堡垒机配合使用，形成“入口防御 + 攻击取证”的纵深防御体系。
6、蜜罐的特征识别（攻击者视角）
攻击者可通过以下方式识别蜜罐，从而规避或测试：
- 端口扫描和识别：若目标提供非标准的服务或存在不寻常的端口（例如开放端口与宣称的服务不匹配），可能是蜜罐。
- 缺少真实数据：系统内缺少真实的数据或文件（如假文档、空日志），可能为蜜罐。
- 受限制的功能：部分系统功能被禁用或受到限制（例如无法执行常见命令、拒绝写文件），可能为蜜罐。
- 反向 WHOIS 查询：通过 WHOIS 查询域名所有者，若关联到安全公司或已知蜜罐部署方，则为可疑。
- 非正常的响应时间：系统响应时间与正常情况明显不同（过快或过慢），可能存在蜜罐。
二、堡垒机运维
https://www.jumpserver.org/
1、基本概念
堡垒机：也叫跳板机（Jump Server），但功能远强于传统跳板机。它是一种集中式运维安全管控系统，部署在企业内部网络与核心资产（服务器、数据库、网络设备等）之间，强制所有运维、开发人员的访问都先经过它，从而实现对身份认证、权限控制、操作审计的统一管理。
2、核心作用
- 集中入口：切断对服务器的直接访问，所有运维必经堡垒机，减少攻击面。
- 强认证与细授权：统一身份验证，并精确控制谁能访问哪台服务器的哪个账号及执行哪些命令。
- 全程审计：对操作行为实时录像、回放，记录所有输入输出，便于事后追溯与高危命令告警。
- 密码托管与隔离：统一管理服务器账号密码，自动轮换，用户不接触真实密码。
- 提升效率：实现单点登录、批量运维，简化日常操作。
3、安全影响（从红队角度看）
- 增加了攻击成本：不能直接碰后端资产，需要花费时间研究堡垒机本身。
- 提供了新的攻击面：堡垒机的软件漏洞、配置缺陷、会话管理弱点都可能被利用，一旦得手，红队获得的是对整个基础设施的最高控制权，等同于拿到了“内网万能钥匙”。
三、API 接口
1、基本概念
API 的全称是Application Programming Interface，中文叫做应用程序编程接口。
简单来说，API 就像是不同软件程序之间沟通的“信使”或“桥梁”。它定义了一套规则，允许一个软件去请求另一个软件的数据或功能，而不需要知道对方内部是如何实现的。
2、作用
- 提高效率：程序员不用“重新发明轮子”。需要支付功能？直接调用支付宝或微信支付的 API 就行。需要地图？调用高德或谷歌地图的 API。
- 促进协作：不同的团队可以独立开发自己的部分，只要彼此之间的 API 约定不变。前端和后端、不同公司的系统都能通过 API 协作。
- 保持安全：API 像一个“门卫”，系统可以精确控制哪些数据可以访问、谁有权限访问，而无需暴露整个数据库。
- 构建生态：公司和开发者可以开放自己的 API，让第三方开发者创造出新的应用和服务。比如，微信开放登录 API，让无数 App 可以用微信账号登录。
3、常见的 API 类型
- Web API：通过互联网（HTTP协议）访问，是最常见的类型。比如你调用 OpenAI 的 API 来生成文本，用的就是 Web API。
- 操作系统 API：让你编写的程序能调用系统功能，比如 Windows API 可以创建文件或窗口。
- 库/框架 API：你使用的编程语言自带的函数或类，比如 Python 的
print()函数，本质上也是一个 API。
4、对安全测试的影响
- 攻击面转移与扩大
安全测试的关注点从传统的 UI 界面（页面、表单）下沉到接口层。大量业务逻辑和数据交换直接通过 API 完成，测试必须覆盖请求参数、报文头、负载等隐藏入口，否则会漏掉关键漏洞。 - 认证与授权成为测试重心
API 常使用 API Key、JWT、OAuth 等机制，这些实现不当会导致越权风险（水平/垂直越权）、Token 伪造等。安全测试需专门设计篡改 Token、替换用户 ID 等用例，不再仅依赖登录/退出流程。 - 注入漏洞的载体更加多样
除了传统 SQL 注入，API 广泛接收 JSON、XML、URL 参数等格式，衍生出JSON 注入、NoSQL 注入、XXE等新型注入测试点。测试工具和方法需要相应升级。 - 业务逻辑缺陷更突出
由于 API 可被任意顺序、任意频率调用，绕过步骤、重放请求、并发竞态等逻辑漏洞成为高风险区。这类问题难以被自动化扫描器发现，依赖人工或半自动化场景测试。