AI自动化渗透工具——STRIX部署指南

优质文章学习记录

— 12 min read
AI自动化渗透工具——STRIX部署指南

STRIX部署指南

项目概述

​ Strix是自主的AI代理，行为就像真正的黑客一样——它们动态运行你的代码，发现漏洞，并通过实际概念验证进行验证。专为开发者和安全团队打造，帮助他们快速、准确地进行安全测试，避免手动渗透测试的负担或静态分析工具的误报。

1.1核心特性

  • 开箱即用的完整黑客工具包
  • 协作与扩展的代理团队
  • 真正的验证是用PoC，而不是假阳性
  • 以开发者为中心的CLI和可作的报告
  • 自动修复与报告以加速修复

1.2核心架构分析

Strix的架构设计可以概括为四层:

┌─────────────────────────────────────────┐ │ 用户层：CLI/TUI交互界面 │ ├─────────────────────────────────────────┤ │ 智能层：StrixAgent + Multi-Agent协作 │ ├─────────────────────────────────────────┤ │ 工具层：12类专业工具（Browser/Proxy等） │ ├─────────────────────────────────────────┤ │ 运行时层：Docker沙箱 + 隔离环境 │ └─────────────────────────────────────────┘

第一层：用户层

  • 交互式TUI：基于Textual框架的终端UI，实时显示Agent状态、漏洞发现、工具调用
  • 非交互式CLI：适合CI/CD集成，直接输出扫描结果
# 交互式模式：适合开发者手动测试 strix --target ./app-directory # 非交互式模式：适合CI/CD流水线 strix -n --target https://your-app.com

开发阶段用交互模式调试，生产环境用非交互模式自动化。

第二层：智能层

这是Strix最核心的部分。它实现了一个多智能体协作系统，每个Agent都有明确的职责：

# 核心Agent基类的设计（简化版） class BaseAgent: def __init__(self, config): self.llm = LLM(config) # 大模型驱动 self.state = AgentState() # 状态管理 self.max_iterations = 300 # 最大迭代次数 async def agent_loop(self, task): while not self.state.should_stop(): # 1. LLM生成下一步行动 response = await self.llm.generate(conversation_history) # 2. 解析并执行工具调用 actions = parse_tool_invocations(response.content) result = await execute_tools(actions) # 3. 更新对话历史，继续推理 self.state.add_message("assistant", response.content) self.state.add_message("user", result)

注意几个关键设计：

  • 最大300次迭代：避免Agent陷入死循环
  • 对话历史管理：通过Memory Compressor压缩上下文，避免超出Token限制
  • 工具调用解析：从LLM输出中提取XML格式的工具调用指令

第三层：工具层

Strix给Agent配备了12类专业工具，覆盖渗透测试的各个环节：

工具类别功能描述典型场景
Browser自动化浏览器操作测试XSS、CSRF、点击劫持
ProxyHTTP流量拦截与分析抓包分析、请求重放
TerminalShell命令执行运行扫描工具（nmap/sqlmap）
Python动态代码执行编写自定义漏洞利用脚本
FileEdit代码修改与审计白盒测试中的代码修复
WebSearch联网搜索查询最新漏洞利用方法
Reporting漏洞报告生成创建标准化漏洞报告
AgentsGraphAgent协调管理创建子Agent、消息传递

每个工具都是通过装饰器注册到系统中：

@register_tool(sandbox_execution=True) def send_request(method: str, url: str, headers: dict, body: str): """使用代理发送HTTP请求""" manager = get_proxy_manager() return manager.send_simple_request(method, url, headers, body)

这种设计有两个好处：

  1. 插件化扩展：新增工具只需添加函数+注册装饰器
  2. 沙箱隔离：危险操作在Docker容器中执行，保证主机安全

第四层：运行时层

渗透测试工具本质上是"合法的黑客工具"，如果不加控制，可能对主机造成威胁。Strix的解决方案是：所有危险操作都在Docker容器中执行。

class DockerRuntime: def create_sandbox(self, agent_id, local_sources): # 1. 创建隔离容器 container = self.client.containers.run( STRIX_IMAGE, detach=True, cap_add=["NET_ADMIN", "NET_RAW"], # 网络权限 environment={ "TOOL_SERVER_PORT": tool_server_port, "TOOL_SERVER_TOKEN": token, # 认证Token } ) # 2. 启动工具服务器 container.exec_run( f"poetry run python strix/runtime/tool_server.py" ) return container.id

关键设计点：

  • 每个扫描任务一个独立容器：避免相互干扰
  • Token认证：Agent与容器通信需要验证身份
  • 网络隔离：容器无法访问主机网络（除非显式映射）

1.3核心功能展示

首次运行STRIX的时候，项目需要先调用sandbox的镜像，所以需要等几分钟才能看到可交互式的页面。运行的过程中使用

dockerps
在这里插入图片描述

可以看到正在运行的sandbox的镜像，以及他们在strix_run目录下输出的渗透报告

运行结果在运行完成之后，他会把本次运行使用的模型，已经输出和输出展示给我们做一个总结，如果用的是api调用的话，还会告诉我们这次渗透使用的tokens

在这里插入图片描述

文档输出在他任务完成之后我们可以要求他写一份报告给我们，因为这里我们给他的文件是springboot的一款扫描工具，所以他反馈给我们的并不是一个漏洞报告，而是更偏向一个操作指南的一个形式

最后的内容他会存放在strix_runs文件目录下之后我又把pikachu的靶场给了他让他测试，他通过scan的工具也可以扫出来一些比较简单的漏洞

具体要求这个是基于我们上面的指令以及ai的调入，我们可以在运行strix附上我们的需求，这个需求可以是一个md文件，也可以是一句话

在这里插入图片描述

是否启用全自动扫描这个和上面的区别就是加个参数 -n，这里就不列完整的代码了。这个模式下使用的是非交互式的界面，他会把输出报告的路径告诉我们，等他扫完我们去看一下就好了

扫描网址

strix -t http://172.17.20.19/pikachu/ -m quick

这个不知道是不是因为不在本地的原因，扫起来特别的慢

扫描本地文件

strix --target ./SpringBoot-Scan-2.7 -m quick

ps:这里调用的是可交互式的agent页面，所以下面是由输入框的

部署环境

2.1 系统要求

#操作系统 - Ubuntu 20.04+ - CentOS 8+ #软件依赖 - Python 3.12+ - Docker 20.10+ (可选，用于容器化部署) - Git 2.20+ (用于代码获取)# 硬件要求 内存：至少8GB，推荐16GB以上 存储：50GB可用磁盘空间 网络：稳定的互联网连接

2.2部署环境

python3 --version pip3 --version pipx

项目部署

3.1 STRIX的部署

  1. 首先是将strix的源码从github上面拉下来
  2. 接下来是最头疼的一步，即docker沙箱的拉取。沙箱的名字叫ghcr.io/usestrix/strix-sandbox:0.1.10，这个镜像有非常多的层，而且每层都非常大，拉取都要拉半天，本来是初次运行的时候项目会自动拉取，可是拉的实在是太慢了(具体原因后面分析)最后只能手动拉取

最后就是接入ollama，然后进行本地测试根据官方的API调用规则，我们可以在终端临时设置变量

exportSTRIX_LLM="ollama/gpt-oss:20b"exportLLM_API_BASE="http://172.17.250.247:11434"# echo 可以检查自己的设置的路径是否成功echo"$STRIX_LLM"echo"$LLM_API_BASE"

接下来就可以配置大模型了，这里我们使用的是公司的ollama

模型名称：gpt-oss:20b API链接：http://172.17.250.247:11434/

具体使用的话是可以看Local Models - Strix项目的官方api调用文档的，其中有提到本地的ollama以及LM Studio / OpenAI Compatible的调用

#ollamaexportSTRIX_LLM="ollama/qwen3-vl"exportLLM_API_BASE="http://localhost:11434"#LM Studio / OpenAI CompatibleexportSTRIX_LLM="openai/local-model"exportLLM_API_BASE="http://localhost:1234/v1"# Adjust port as needed

这里的话我们先调用ollama的接口进行测试

接着进行安装

# Install Strixcurl -sSL https://strix.ai/install |bash# Or via pipx pipx install strix-agent

3.2 STRIX的使用

详细指南

strix -h

可以看到各个参数是如何设置的

到基本用途

# Scan a local codebase strix --target ./app-directory # Security review of a GitHub repository strix --target https://github.com/org/repo # Black-box web application assessment strix --target https://your-app.com

扩展用途

# Grey-box authenticated testing strix --target https://your-app.com --instruction "Perform authenticated testing using credentials: user:pass"# Multi-target testing (source code + deployed app) strix -t https://github.com/org/app -t https://your-app.com # Focused testing with custom instructions strix --target api.your-app.com --instruction "Focus on business logic flaws and IDOR vulnerabilities"# Provide detailed instructions through file (e.g., rules of engagement, scope, exclusions) strix --target api.your-app.com --instruction-file ./instruction.md # 还可以设置扫描的速率 -m [quick，standard，deep]

部署难点

项目虽然运行起来简单，但是部署的过程中遇到了很多麻烦，且网上文献不算很多，大部分只能自己解决

4.1 本地模型部署

首先是本地大模型的部署，公司的ollama是在一台win下面跑的，ip段是172.17.250.247，但是公司一开始给的网段是在192.xxx.xxx.xxx下的，所以win可以ping通但是虚拟机下访问不了，且改为桥接模式下也不行。最后更改了主机的网络，用了另一台路由器，将ip放到了同一网段下172.17.xxx.xxx，在桥接模式下终于可以访问了。

4.2 docker中sandbox的拉取

这个是该项目的最大的难点，因为STRIX的工具非常齐全，所以他运行的沙箱也非常的大，由于该项目是国外的，如果按照他github上来的话根本拉不下来

​

在这里插入图片描述

查找了相关资料后，我听到有个说法是Linux 上通过临时命令 export HTTP_PROXY 设置的代理，对 curl 这些有用，但是对 docker pull 不起作用。所以就去学了一下在sys目录下设固定环境变量来走了代理，设完之后继续拉，一看速率，依旧龟速，所以这个方案也暴毙了。最后实在是拉不下来，我选择了用在win下面拉取之后再转到linux上，依旧是要开代理和换源，最后走的是南京大学的镜像拉的。但是也下了很久。

下完之后我们把镜像改成原来的名字，然后帮他压缩成一个压缩包发给kali

docker tag ghcr.nju.edu.cn/usestrix/strix-sandbox:0.1.10 ghcr.io/usestrix/strix-sandbox:0.1.10
在这里插入图片描述
docker save -o strix-sandbox.tar ghcr.io/usestrix/strix-sandbox:0.1.10

第二个问题就是我的kali其实不能直接往里面拖东西，装了vmtools也不行，所以这里我把docker的镜像压缩成一个tar文件，然后用wget下的，我在win本地把小皮开了，从而快速搭建了一个运行传输文件的网站

wget -c http:// 192.168.3.228/strix-sandbox.tar#这里一定要加上-c的指令，因为这个沙箱太大了，传输的时候非常容易中断，加上-c的指令之后可以接着上一次的继续传输sudodocker load -i strix-sandbox.tar

然后解压，这样镜像就总算是搞完了

在这里插入图片描述

总结

从扫描目标URL的方式来说，发现Strix还是有一定的可取之处，在扫描日志中发现它会调用目录爆破、SQLMAP等工具进行扫描，也会根据参数特征进行相应的测试，结果报告内容结构完整，在服务器性能允许+忽略token成本的前提下，应该可以获得不错的扫描效果。而对于扫描代码包进行源代码审计来说，Strix与Trae、Cursor等原生AI IDE来说，可能就不太有竞争力了。而且它太烧tokens，本地的AI如果不是有超大显存的支持下，根本没有什么太大的效果，最影响体验的地方是它跑的实在是太慢了

参考资料

  1. STRIX GitHub仓库：usestrix/strix：用于渗透测试的开源AI代理
  2. STRIX 本地api调用:Local Models - Strix
  3. Strix安全测试平台：从零搭建企业级AI渗透测试环境-ZEEKLOG博客
  4. Strix自动渗透测试平台搭建与使用-
  5. 【AI自动渗透】strix 使用记录 | CN-SEC 中文网

Read more

【花雕学编程】Arduino BLDC 驱动方案 —— MimiClaw（迷你小龙虾）+ ESP32 嵌入式组合机器人

【花雕学编程】Arduino BLDC 驱动方案 —— MimiClaw（迷你小龙虾）+ ESP32 嵌入式组合机器人

这是一套面向无刷电机（BLDC）、高度集成、可快速开发、支持本地智能的机器人开发组合。它将 ESP32 高性能主控 + MimiClaw 智能控制框架 + Arduino 生态易用性 + BLDC 无刷电机驱动 融为一体，是目前创客、实验室、竞赛、小型机器人领域最实用、最稳定、性价比极高的嵌入式机器人方案。 一、核心定义（专业版一句话解释） MimiClaw（迷你小龙虾）+ ESP32是一套基于 Arduino 开发环境、面向 BLDC 无刷电机控制、支持本地智能决策的嵌入式机器人控制系统。它以 ESP32 为硬件核心，以 MimiClaw 为控制大脑，实现无刷电机驱动、传感器融合、自主决策、无线通信、多关节机器人控制一体化。 简单说：ESP32 = 身体与算力MimiClaw = 思考与逻辑BLDC 无刷驱动 = 动力系统Arduino

FPGA模块如何助力现代工厂实现高速数据采集和实时处理

1. 工业 4.0 背景下的数据挑战 在智能制造的浪潮下，现代工厂正加速从“自动化”向“智能化”迈进。随着传感器部署密度的迅速上升，工厂内部产生的数据量呈几何级增长，涵盖结构化数据（如温度、湿度、压力）与非结构化数据（如图像、视频、音频）等多种类型，对数据采集与处理能力提出了前所未有的挑战： * 实时性要求高：在高速生产线、精密制造与运动控制等场景中，关键数据必须被及时采集与处理，以确保生产过程的高效运行与安全性。这不仅要求系统具备高速采集能力，更要求具备每秒处理百万乃至千万数据点的能力。 * 传输与处理带宽受限：庞大的原始数据若未经处理直接上传至数据中心或云端，将对网络带宽造成巨大负担，且传输延迟难以控制，极易影响系统响应速度和可靠性。 * 多协议兼容的复杂性：现代工厂常用的工业以太网、CAN、Profibus 等通信协议并存，系统需兼容上百种协议并实现无缝对接，大大增加了系统集成的复杂性。 2. FPGA 技术的核心优势 传统处理器架构逐渐难以胜任智能制造的核心需求。FPGA（现场可编程门阵列）凭借其强大的并行处理能力、毫秒级低延迟响应以及灵活可重构的架构，
【大模型应用篇】用 OpenClaw + 飞书打造 7x24 小时服务器运维机器人

【大模型应用篇】用 OpenClaw + 飞书打造 7x24 小时服务器运维机器人

前言 本文基于OpenClaw，也是最近超火的可在本地运行的AI Agent网关，记录从零搭建通过飞书对话管理服务器运维机器人的全过程。该机器人支持随时随地通过飞书查看服务器状态、检索日志、管理进程，其核心机制在于：由OpenClaw将聊天平台（飞书等）的消息路由至大模型，模型调用本地工具（如Shell、文件系统、浏览器）执行相应任务，最终将结果自动返回至飞书会话中，实现自动化运维交互。 架构概览 飞书 App (WebSocket 长连接)         ↕ OpenClaw Gateway (服务器上 systemd 常驻)         ↕ AI 模型 (DeepSeek v3.2/GLM 4.7)         ↕ 服务器 Shell (受白名单限制的命令执行) 核心组件： * OpenClaw Gateway：Agent 网关，管理会话、工具调用、渠道连接 * 飞书插件：通过

web3是什么，业务应用

Web3（或Web 3.0）是互联网发展的下一个阶段，核心愿景是构建一个去中心化、用户主导、无需信任中介的数字生态。它试图解决当前Web2（社交网络、电商平台等）的核心问题——数据与权力集中在少数大公司手中，让用户真正拥有自己的数字资产和身份。 一、Web3的核心逻辑：从“读/写”到“拥有” * Web1（1990s-2000s）：只读互联网（Read-only），用户只能获取信息（如门户网站、早期论坛），数据是静态的。 * Web2（2000s至今）：读写互联网（Read-write），用户可以互动（发朋友圈、写博客），但数据与权力归平台所有（比如微信存储你的聊天记录，抖音控制你的推荐算法）。 * Web3（正在演进）：读写+拥有互联网（Read-write-own），通过区块链技术让用户直接控制自己的数据、资产和身份（比如用NFT证明你是某件数字艺术品的所有者，用加密货币转账无需银行）。 二、Web3的核心特征