Outis：自动化渗透测试侦察框架，整合Nuclei、Naabu等工具链

1. 项目概述：一个被低估的渗透测试利器

如果你在网络安全领域，特别是渗透测试和红队行动中摸爬滚打过一段时间，大概率会听说过或者用过像nmap、masscan这样的端口扫描器，也用过gobuster、dirsearch这样的目录枚举工具。这些工具都是单点作战的利器，但当你面对一个庞大的资产列表，需要执行一套标准化的、从信息收集到漏洞初筛的完整流程时，手动串联这些工具、处理各种输出格式、去重、整理报告，就成了一个极其繁琐且容易出错的过程。这正是SySS-Research/outis这个项目试图解决的问题。它不是一个全新的扫描器，而是一个高度集成化的“侦察与枚举框架”，其核心价值在于将多个顶尖的开源工具（我们称之为“引擎”）无缝整合到一个统一的、可扩展的流水线中。

我第一次接触outis是在一次大型的内部红队演练中。当时我们需要在短时间内对上千个域名和IP段进行初步的资产梳理和脆弱性迹象排查。手动操作根本不现实，而一些商业化的自动化平台又过于笨重且不灵活。outis的出现，就像是为这种场景量身定制的瑞士军刀。它用 Go 语言编写，这意味着单文件分发、跨平台兼容性好，而且执行效率非常高。它的设计哲学很清晰：“配置即流水线”。你通过一个 YAML 配置文件，定义好输入目标、选择要启用的引擎（比如用naabu做端口扫描，用httpx做 HTTP 服务探测，用nuclei做漏洞检测），并设置好引擎之间的数据传递关系，outis就会自动帮你调度执行，并将所有结果汇总到一个结构化的输出文件（如 JSON）中。

简单来说，outis扮演了“编排者”和“粘合剂”的角色。它把那些我们日常在命令行里敲来敲去的工具，变成了一个自动化流水线上的标准化“工人”，让渗透测试的初期侦察阶段变得前所未有的高效和可重复。对于安全顾问、企业内部的蓝队资产梳理人员，甚至是漏洞赏金猎人，outis都能显著提升工作效率，让你把精力更集中在深度分析和漏洞利用上，而不是浪费在工具链的拼接和数据处理上。

2. 核心架构与设计哲学解析

2.1 引擎化与流水线设计

outis最核心的设计思想就是“引擎（Engine）”和“流水线（Pipeline）”。理解这两个概念，是玩转outis的关键。

引擎是什么？在outis的语境下，一个引擎就是对某个特定安全工具（如nmap,subfinder,httpx）的一层封装。outis本身并不重复造轮子去实现端口扫描或子域名枚举的算法，而是专注于如何更好地调用和管理这些现有的、经过社区验证的顶级工具。每个引擎都负责三件事：

1. 接受输入：从上一个引擎的输出、或从初始目标列表中获取数据。
2. 执行任务：调用对应的命令行工具，并传递合适的参数。
3. 产生输出：将工具的执行结果，解析、格式化成一个outis内部统一的、结构化的数据格式（通常是 JSON 对象），传递给下一个引擎或作为最终输出。

例如，naabu引擎接收一个 IP 地址或域名，运行naabu命令进行端口扫描，输出格式为{“host“: “192.168.1.1“, “ports“: [“80“, “443“, “8080“]}。httpx引擎则接收一个host:port组合，探测 HTTP/HTTPS 服务，并提取标题、状态码、技术栈等信息，输出更丰富的资产画像。

流水线则是将这些引擎按照逻辑顺序串联起来的“工作流”。一个典型的侦察流水线可能是：输入目标->subfinder引擎(发现子域名) ->dnsx引擎(解析子域名到IP) ->naabu引擎(对IP进行端口扫描) ->httpx引擎(对开放的HTTP/HTTPS服务进行探测) ->nuclei引擎(对探测到的Web服务进行漏洞扫描)。

outis的配置文件就是用来定义这条流水线的。这种设计的巨大优势在于灵活性和可复用性。你可以为不同的场景创建不同的配置文件：一个用于快速的子域名枚举，一个用于深度的全网段端口扫描，另一个用于针对Web资产的漏洞普查。只需切换配置文件，就能执行完全不同的任务流。

2.2 配置驱动与声明式语法

outis强烈依赖于 YAML 配置文件。这是一种“声明式”的配置方法，你只需要告诉它“你想要什么”（What），而不需要详细指定“每一步怎么做”（How）。这降低了使用门槛，也使得配置易于版本管理和团队共享。

一个最简化的配置文件骨架如下：

# config.yaml input: - “example.com“ - “192.168.1.0/24“ engines: - name: naabu enabled: true # 引擎特定参数 args: - “-p“ - “80,443,8080,8443“ - name: httpx enabled: true # 指定输入来自上一个引擎 (naabu) 的输出 input-from: naabu args: - “-title“ - “-tech-detect“ - “-status-code“ output: file: “results.json“ format: “json“

在这个配置中，我定义了两个目标：一个域名和一个网段。流水线包含两个引擎：先运行naabu对目标进行指定端口的扫描，然后将naabu发现的host:port结果作为输入，传递给httpx进行详细的HTTP探测。最终所有结果会汇总输出到results.json文件。

注意：outis要求你系统中已经正确安装并配置了它所依赖的引擎工具（如naabu,httpx等），且这些工具的可执行文件位于系统的 PATH 环境变量中，或者你需要在配置文件中通过path字段指定其绝对路径。这是新手最容易踩的坑——配置文件写好了，一运行却报“找不到命令”。

2.3 输入与输出的标准化

outis的另一个精妙之处在于其内部的数据流标准化。不同工具的输出格式千奇百怪，outis通过为每个引擎编写“适配器”，将这些输出统一转换为内部标准格式。这带来了两个好处：

1. 引擎间无缝协作：naabu输出的端口列表，可以直接被httpx引擎理解并用作输入，无需你手动写脚本进行格式转换和拼接。
2. 统一的结果视图：无论流水线多么复杂，最终所有引擎产生的结果都会被收集、去重、合并，生成一个结构化的总输出文件（如JSON）。这个文件包含了从子域名、IP、开放端口、Web服务信息到漏洞发现的所有数据，极大方便了后续的数据分析和报告生成。

你可以把这个过程想象成一个标准化零件的装配线。每个引擎（工人）都按照统一的标准（接口）加工零件（数据），并将半成品传递给下一个工位。最终，流水线末端产出的是一件完整的、规格统一的产品（结构化报告）。

3. 核心引擎详解与实战配置

outis的强大，建立在它所集成的众多优秀引擎之上。下面我们来深入剖析几个最常用、最核心的引擎，并分享实战中的配置心得。

3.1 信息收集引擎：构建目标画像

在渗透测试中，信息收集的广度直接决定了攻击面的宽度。outis在此环节集成了多个神器。

subfinder + dnsx：子域名发现黄金组合subfinder引擎用于被动收集子域名，它聚合了数十个公开的数据源和API。配置时，关键在于管理API密钥和优化速率限制。

- name: subfinder enabled: true args: - “-all“ # 使用所有可用的源 - “-silent“ # 如果你有某些服务的API密钥，可以在这里通过环境变量或配置文件传递 # env: # - “GITHUB_TOKEN=your_token_here“

subfinder输出的是一堆域名。紧接着，你需要dnsx引擎来解析这些域名，获取真实的IP地址，并过滤掉无法解析的“死”域名。

- name: dnsx enabled: true input-from: subfinder # 输入来自subfinder的输出 args: - “-a“ # 查询A记录 - “-aaaa“ # 查询AAAA记录 (IPv6) - “-resp“ # 输出解析结果 - “-silent“

实操心得：对于大型目标，直接使用-all参数可能会产生巨量的子域名，导致解析步骤非常缓慢。我的经验是，在初次侦察时，可以先使用-sources参数指定几个速度快、质量高的源，如alienvault, certspotter, hackertarget。在深度评估时，再启用所有源。另外，将dnsx的解析结果进行去重（outis会自动做一部分），只保留唯一的IP，能显著减少后续端口扫描的目标数量。

naabu：闪电般的端口扫描器naabu是projectdiscovery出品的端口扫描器，以速度快著称。在outis中配置它，你需要仔细考虑端口列表和扫描策略。

- name: naabu enabled: true input-from: dnsx # 对dnsx解析出的IP进行扫描 args: - “-p“ # 指定端口 - “-“ # “-“ 代表扫描前1000个常见端口 # 更精细的配置示例： # - “-p 80,443,8080,8443,22,21,25,3306,5432,6379,27017“ # 常用Web和管理端口 - “-rate 1000“ # 发包速率，根据网络环境调整 - “-scan-all-ips“ # 如果输入是域名，解析所有IP并扫描 - “-silent“

• 端口选择策略：盲目扫描全端口（-p -）在时间充裕时可行，但通常效率低下。我通常会准备多个端口列表配置文件：

  • web_ports.txt:80,443,8080,8443,8888,9000等常见Web端口。
  • service_ports.txt:22,21,23,25,110,143,3306,3389,5432,6379,27017等常见服务端口。
  • top1000.txt: 保存naabu默认的top1000端口列表。 然后根据任务目标选择：-p - -p web_ports.txt,service_ports.txt。

• 速率控制：-rate参数至关重要。在内网扫描可以设置到5000甚至更高，在对公网资产扫描时，建议从1000开始，避免触发目标系统的安全防护或导致自己的IP被屏蔽。

3.2 服务探测与指纹识别引擎

发现开放端口后，下一步是识别其上运行的服务。httpx是这个领域的王者。

httpx：Web资产探测与指纹收集httpx不仅能快速探测HTTP/HTTPS服务，还能提取大量有价值的信息。

- name: httpx enabled: true input-from: naabu # 对naabu发现的host:port进行探测 args: - “-title“ # 提取页面标题 - “-status-code“ # 获取HTTP状态码 - “-tech-detect“ # 技术栈识别 (Wappalyzer) - “-content-length“ # 获取响应体长度 - “-web-server“ # 获取Web服务器类型 (如nginx, Apache) - “-cdn“ # 检测是否使用CDN - “-probe“ # 主动探测（默认也会） - “-silent“ - “-timeout 5“ # 超时设置，对于大规模扫描建议3-5秒 - “-threads 50“ # 并发线程数

httpx的输出是后续漏洞扫描和手工测试的宝贵入口点。-tech-detect识别出的框架（如Vue.js, Spring Boot, WordPress）能让你立刻知道该使用哪些针对性的测试工具和漏洞库。

注意事项：高并发（-threads）虽然快，但可能对目标网站造成压力，在合规测试中需谨慎。-timeout设置过短会导致漏报，设置过长会极大拖慢扫描速度。需要根据网络质量和目标响应情况做权衡。我通常在对内部资产扫描时使用-threads 100和-timeout 3，对外部资产则用-threads 30和-timeout 5。

3.3 漏洞检测引擎：自动化初筛

信息收集和服务识别完成后，自动化漏洞扫描是提升效率的下一步。nuclei是当前社区最活跃、模板最丰富的漏洞扫描器，与outis集成得天衣无缝。

nuclei：基于模板的精准漏洞扫描nuclei通过成千上万的YAML模板来定义检测规则，从信息泄露到RCE，覆盖范围极广。

- name: nuclei enabled: true input-from: httpx # 对httpx确认存活的Web服务进行扫描 args: - “-silent“ - “-severity low,medium,high,critical“ # 设置扫描的严重等级 - “-tags cve,misconfig,exposure“ # 按标签过滤模板 - “-etags sandbox,deprecated“ # 排除某些标签的模板 - “-rate-limit 150“ # 限制每秒请求数，避免被封 - “-bulk-size 25“ # 每次批量扫描的目标数 - “-timeout 5“ # 使用特定模板或目录 # - “-t /path/to/custom-templates“ # 自定义模板 # - “-t exposures/configs“ # 只扫描信息泄露类模板

• 模板管理：nuclei的强大在于其模板库，但全量扫描（不指定-tags或-t）会产生海量请求，且大部分不相关。强烈建议根据httpx识别出的技术栈进行针对性扫描。例如，如果httpx识别出WordPress，你可以在后续流水线中增加一个专门针对 WordPress 的nuclei引擎，使用-tags wordpress。或者，如果目标是 Java 应用，则使用-tags java,spring。

• 速率与风险控制：-rate-limit和-bulk-size是保护你和目标系统的关键参数。对生产环境进行未经授权的全速扫描是危险且不道德的。即使在授权测试中，也应从较低的速率开始（如50-100），观察系统负载和响应后再调整。

整合工作流示例： 一个完整的、针对Web资产的侦察与初扫流水线配置可能如下所示。这个配置实现了从域名到漏洞发现的端到端自动化：

# web_recon_pipeline.yaml input: - “target-company.com“ engines: # 阶段1：子域名枚举与解析 - name: subfinder enabled: true args: [“-silent“, “-sources alienvault,certspotter“] - name: dnsx enabled: true input-from: subfinder args: [“-a“, “-resp“, “-silent“] # 阶段2：端口扫描 (聚焦Web端口) - name: naabu enabled: true input-from: dnsx args: - “-p“ - “80,443,8080,8443,8888,9000,9443“ - “-rate 2000“ - “-scan-all-ips“ - “-silent“ # 阶段3：HTTP服务深度探测 - name: httpx enabled: true input-from: naabu args: - “-title“ - “-status-code“ - “-tech-detect“ - “-web-server“ - “-cdn“ - “-silent“ - “-threads 30“ - “-timeout 5“ # 阶段4：通用中高危漏洞扫描 - name: nuclei enabled: true input-from: httpx args: - “-silent“ - “-severity medium,high,critical“ - “-rate-limit 100“ - “-timeout 5“ output: file: “web_assets_full.json“ format: “json“

运行这个流水线只需要一条命令：outis -c web_recon_pipeline.yaml。接下来，你可以去喝杯咖啡，回来时，一个包含所有子域名、IP、开放端口、Web服务指纹和潜在中高危漏洞的完整报告就已经在web_assets_full.json里等着你了。

4. 高级用法与性能调优

当你能熟练配置基础流水线后，下一步就是追求更高效、更精准的扫描。这涉及到输入处理、引擎并行、结果过滤等高级技巧。

4.1 输入源的灵活运用

outis的input字段非常灵活，不仅支持直接写入目标，还支持从文件读取和从标准输入（stdin）读取。

从文件读取目标列表：这是处理大批量目标的标准做法。

input: file: “targets.txt“ # 每行一个目标，可以是域名、IP或CIDR

在targets.txt中，你可以混合各种格式：

example.com 192.168.1.1 10.0.0.0/24 app.staging.example.com

使用管道（Pipe）传递数据：outis完美支持 Unix 哲学。你可以用其他工具生成目标列表，直接通过管道传给outis。

# 使用 assetfinder 发现子域名，然后交给outis进行端口扫描和HTTP探测 assetfinder --subs-only target.com | outis -c port_and_http_scan.yaml -i -

对应的配置文件port_and_http_scan.yaml中，input部分可以留空或使用-占位，因为输入会从管道来。

# port_and_http_scan.yaml input: [] # 或 input: [“-“] engines: - name: naabu ... - name: httpx input-from: naabu ...

这种组合方式赋予了outis无限的扩展性，你可以用任何你喜欢的工具（如amass,findomain）来做初步的信息收集，然后将结果交给outis进行标准化的后续处理。

4.2 条件执行与引擎过滤

不是所有引擎都需要对所有目标运行。outis允许你根据条件启用或跳过某些引擎，这能节省大量时间。

基于端口的条件过滤：例如，我们只想对开放了80或443端口的目标运行httpx和nuclei。这可以通过在引擎配置中添加filters实现。

- name: httpx enabled: true input-from: naabu # 只处理端口为80或443的输入 filters: - “port in (80, 443)“ args: [...]

这里的port是naabu引擎输出数据中的一个字段。outis会在将数据传递给httpx之前，先应用这个过滤器。

基于协议或服务的过滤：更智能的做法是利用httpx初步探测的结果，来决定是否进行深度漏洞扫描。

- name: nuclei-critical enabled: true input-from: httpx # 只对httpx探测成功（有响应）且技术栈包含java或spring的目标，运行关键漏洞扫描 filters: - “status_code != 0“ # httpx探测成功 - “contains(technologies, ‘java‘) or contains(technologies, ‘spring‘)“ args: - “-severity critical“ - “-tags java,spring“ - ...

这个配置实现了一个精准的、分层的扫描策略：先广撒网（httpx），再针对高价值目标（特定技术栈）进行重点打击（nuclei-critical）。

4.3 性能调优与资源管理

处理成千上万个目标时，性能调优至关重要。主要从并发控制、超时设置和资源限制入手。

1. 引擎级并发：像httpx、nuclei这类网络请求密集型引擎，其内置的-threads或-c参数控制着其自身的并发数。设置过高会耗尽本地网络资源或导致误报（超时），设置过低则速度太慢。一个经验公式是：线程数 ≈ 本地CPU核心数 * 2 到 * 5。对于网络I/O密集型任务，可以稍高一些。

2. 全局并发与队列：outis本身也会管理引擎间的数据流。如果前一个引擎（如naabu）产生结果的速度远快于后一个引擎（如nuclei）的处理速度，数据会在内存中堆积。目前outis的版本对此控制有限，因此更需要通过限制上游引擎的产出（如naabu的-rate）和下游引擎的消费速度（如nuclei的-rate-limit）来取得平衡。

3. 超时设置：每个引擎的超时参数（如-timeout）必须合理。对于内部网络，可以设置得短一些（2-3秒）；对于公网目标，尤其是海外目标，建议设置为5-10秒。超时设置直接影响扫描的完整性和耗时。

4. 结果去重与合并：outis在输出最终结果前会进行一定程度的去重，但复杂的流水线仍可能产生大量重复条目（例如，同一个IP通过不同域名解析出来）。在扫描结束后，使用简单的脚本对输出的JSON文件进行二次处理，按IP和端口去重，能让你最终的分析列表更加清爽。

一个调优后的高性能配置片段可能如下：

engines: - name: naabu args: - “-p 80,443,8080,8443“ - “-rate 5000“ # 内网高速扫描 - “-timeout 2“ - “-retries 1“ - name: httpx input-from: naabu args: - “-threads 100“ # 高并发探测 - “-timeout 3“ - “-retries 1“ - name: nuclei input-from: httpx filters: - “status_code == 200“ # 只扫描返回200 OK的 args: - “-severity high,critical“ - “-rate-limit 50“ # 限制请求速率，保护目标 - “-bulk-size 10“ - “-timeout 5“ - “-retries 1“

5. 实战问题排查与经验沉淀

即使配置再完美，在实际运行中也会遇到各种问题。下面是我在大量使用outis过程中积累的一些常见问题与解决方案。

5.1 常见错误与解决方法

5.2 结果分析与后续集成

outis输出的 JSON 文件是一个宝库，但原始 JSON 可读性不强。你需要将其转化为更易读的报告或导入其他工具。

1. 使用jq进行快速分析jq是处理 JSON 的神器。以下是一些常用命令：

# 1. 提取所有发现的主机:端口 cat results.json | jq -r '.hosts[] | .host + “:“ + (.port|tostring)‘ | sort -u # 2. 提取所有HTTP服务的标题和状态码 cat results.json | jq -r ‘.hosts[] | select(.http != null) | “\(.host):\(.port) - [\(.http.status_code)] \(.http.title)“‘ # 3. 统计不同Web服务器和技术栈的出现次数 cat results.json | jq -r ‘.hosts[] | select(.http != null) | .http.web_server‘ | sort | uniq -c | sort -nr cat results.json | jq -r ‘.hosts[] | select(.http != null) | .http.technologies[]?‘ | sort | uniq -c | sort -nr # 4. 提取所有nuclei发现的漏洞，按严重等级排序 cat results.json | jq -r ‘.hosts[] | select(.vulnerabilities != null) | .vulnerabilities[] | “[\(.severity)] \(.name) - \(.host)“‘ | sort

2. 生成HTML报告你可以编写一个简单的 Python 脚本，使用Jinja2模板库，将 JSON 结果渲染成一个美观的 HTML 报告，包含表格、统计图表等，便于交付和演示。

3. 集成到其他平台将outis的 JSON 输出导入到其他安全平台，可以形成更完整的工作流。例如，可以将发现的资产导入到DefectDojo进行漏洞生命周期管理，或者导入到Elasticsearch+Kibana中构建一个实时的资产安全监控看板。

5.3 我的独家避坑技巧

1. 配置文件版本化：为你常用的扫描场景（如“外部Web资产普查”、“内部网络快速扫描”、“WordPress专项检测”）创建不同的配置文件（web_scan.yaml,internal_quick.yaml,wordpress.yaml），并使用 Git 进行管理。这保证了任务的可重复性和团队协作的一致性。

2. 分阶段扫描：不要试图用一个庞大的配置文件解决所有问题。将扫描分为多个阶段：

   • 阶段一（快速发现）：使用subfinder+dnsx+naabu（仅常见端口）快速绘制资产地图。
   • 阶段二（服务识别）：对阶段一的结果运行httpx，识别出所有Web服务。
   • 阶段三（针对性扫描）：根据httpx识别出的技术栈，运行多个并行的、针对性的nuclei扫描（如一个针对java，一个针对wordpress）。 这样做的好处是，如果阶段三的某个扫描因故中断，你不需要从头开始。

3. 善用-silent模式：几乎所有引擎都支持-silent参数，它只输出最终结果，不打印进度条等冗余信息。在将outis集成到自动化脚本或后台运行时，务必使用此模式，避免日志混乱。

4. 关注社区更新：outis及其依赖的引擎（尤其是nuclei）更新非常活跃。定期使用go install github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest等方式更新工具，并关注outis项目本身的 Release，新版本往往会带来性能提升、新引擎支持或重要的Bug修复。

5. 合法性是底线：outis是一个极其强大的工具，但能力越大，责任越大。绝对不要在未获得明确书面授权的情况下，对任何不属于你或你未被授权测试的网络和系统进行扫描。未经授权的扫描不仅是非法的，还可能对目标系统造成损害。始终在合规的范围内使用它，例如在授权的渗透测试、漏洞赏金计划或对你完全掌控的内部实验室环境中。