企业官网建设流程全解析

• 渗透测试
• 网络安全
• 应用安全

reconFTW 是一个完全基于 Bash 构建的自动化侦察框架，面向漏洞赏金猎人、渗透测试人员和安全研究人员，以一条命令串起 70+ 外部安全工具，完成子域枚举、Web 探测、OSINT 收集与漏洞扫描的全流程。本篇技术指南以仓库根目录的 CLAUDE.md 为骨架，结合 reconftw.sh、modules/、lib/、reconftw.cfg 与 tests/ 的源码实现，为你拆解它的技术栈、命名约定、生命周期与检查点机制、分层架构、并行执行模型以及反模式清单，帮助你在阅读源码、二次开发或扩展模块时快速建立全局认知。

项目定位与核心价值

reconFTW的核心承诺是：Run one command, get a complete recon picture of a target——运行一条命令，获得目标"被动、主动、漏洞"三个层面的完整侦察视图，且全程支持可断点续跑（resumable checkpoints）、结构化输出与零手工干预的工具编排。

从架构角度看，它的核心能力可以归纳为四点：

• 编排 70+ 外部工具：Go、Python、Rust 生态的安全工具被统一调度，覆盖子域枚举、Web 探测、OSINT、漏洞扫描等阶段；
• 结构化输出树：每个目标在Recon/<domain>/下生成稳定目录层级，可被下游脚本与解析器直接消费；
• 分布式扩展：可选 Axiom 集群执行，将扫描任务分发到多台 VPS；
• 自动化闭环：AI 报告、增量/监控模式、Slack/Telegram/Discord 通知，实现"零接触"的持续侦察。

技术栈与运行环境

语言构成

reconFTW 的三层语言体系分工明确（见 CLAUDE.md）：

运行时依赖

• 操作系统：Linux（Debian/Ubuntu/RHEL/Arch）或 macOS（Apple Silicon / Intel）；Docker 镜像基于ubuntu:24.04（见 Docker/Dockerfile）；
• CPU 架构：ARM64/aarch64、ARMv6l/v7l、x86_64 均受支持；
• macOS 特殊要求：必须通过 Homebrew 安装gnu-getopt、coreutils（提供gtimeout）、gnu-sed，系统自带 BSD 版本不被支持；
• 资源下限：约 5GB 磁盘空间（Go 缓存 + 工具 + 仓库），约 1GB 内存（Go 编译）；
• Bash ≥ 4.3：lib/parallel.sh中wait -n依赖此版本；macOS 系统自带 bash 3.2，需 Homebrew bash。

工具安装体系

工具按安装方式分为五类，在 CLAUDE.md 中有完整清单：

• Go 工具（go install @latest）：subfinder、puredns、dnsx、httpx、nuclei、katana、ffuf、naabu、dalfox、notify、interactsh-client等约 55 个；
• Python 工具（uv tool install）：dnsvalidator、interlace、wafw00f、commix、waymore、arjun、gqlspection等；
• 仓库克隆 + Python venv（venv/bin/python3运行）：dorks_hunter、CMSeeK、cloud_enum、Spoofy、msftrecon、SSTImap等；
• 仓库克隆 + Go 编译：ghleaks、nomore403、JSA等；
• 系统级工具（apt/brew/yum）：nmap、massdns、jq、whois、sqlmap、testssl.sh、medusa等；另有 Rust 工具smugglex（HTTP 请求走私检测）通过 Cargo 安装。

值得注意的设计取舍：多数 Go 工具通过go install @latest安装，没有版本锁定（lockfile 不存在），CLAUDE.md 明确将其标注为"已知的供应链风险"——这一点在二次开发或生产部署时需要自行权衡。

配置体系

配置系统分三层（配置来源与优先级见 CLAUDE.md）：

1. reconftw.cfg：约 350 个运行时变量，在 CLI 解析之后被 source；
2. secrets.cfg（gitignored，自动 source）：API Key 与 Token 与主配置分离，仓库提供secrets.cfg.example模板；
3. $CUSTOM_CONFIG：可选的用户自定义配置覆盖层。

关键配置项示例（均可在 reconftw.cfg 中核对）：

OSINT=true # 整个 OSINT 模块开关（L123） SUBDOMAINS_GENERAL=true # 整个子域模块开关（L152） VULNS_GENERAL=false # 漏洞模块开关，注释明确说明"非常侵入且缓慢"（L266） HTTPX_RATELIMIT=150 # httpx 速率限制（L397） NUCLEI_RATELIMIT=150 # nuclei 速率限制（L398） FFUF_RATELIMIT=0 # ffuf 不限速（L399） AI_REPORT_TYPE="md" # AI 报告格式 md|txt（L455） EXPORT_FORMAT="" # 扫描结束导出 json|html|csv|all，空=禁用（L482） WORDLISTS_DIR="${DATA_DIR}/wordlists" # 词表目录（L22）

速率限制与线程数并非写死的：线程数通过AVAILABLE_CORES=$(nproc)自动探测并按工具乘以系数；CLI 参数覆盖统一使用CLI_*变量，在reconftw.cfgsource 之后重新应用，保证 CLI 优先级永远高于配置文件。此外还提供三套预设配置：config/reconftw_full.cfg（全量扫描）、config/reconftw_quick.cfg（快速扫描）、config/reconftw_stealth.cfg（低噪音）。

CLI 入口：getopt 解析与模块加载

reconftw.sh 是唯一入口，职责链条为：Bootstrap → macOS 重执行 → 模块加载 → getopt 解析 → 配置 source → CLI 覆盖重应用 → 模式分发。

macOS 兼容的重执行逻辑

在 reconftw.sh，脚本检测到自身在 macOS 上以脚本方式运行（BASH_SOURCE[0] == $0）时，会依次探测/opt/homebrew/bin/bash（Apple Silicon）与/usr/local/bin/bash（Intel），找到 bash 主版本 ≥ 4 的实例后用exec重新执行自己；随后 reconftw.sh 校验gnu-getopt、coreutils、gnu-sed三个 Homebrew formula 是否存在并注入 PATH。

模块加载顺序

库文件与模块文件采用显式依赖顺序source（见 reconftw.sh）：

lib/validation.sh → lib/common.sh → lib/ui.sh → lib/parallel.sh → modules/utils.sh → modules/core.sh → modules/osint.sh → modules/subdomains.sh → modules/web.sh → modules/vulns.sh → modules/axiom.sh → modules/modes.sh

顺序本身即契约：utils.sh必须最先加载以提供基础工具，modes.sh必须最后加载以编排其他全部模块。设计上不存在循环依赖，全部代码驻留在同一个 shell 进程中。

全量 CLI 选项

getopt 长选项解析位于 reconftw.sh，完整选项列表如下（CLAUDE.md 原文完整继承）：

domain, list, recon, subdomains, passive, all, web, osint, zen, deep, help, vps, vps-count, ai, check-tools, health-check, quick-rescan, incremental, adaptive-rate, dry-run, parallel, no-parallel, monitor, monitor-interval, monitor-cycles, refresh-cache, gen-resolvers, force, export, report-only, no-report, parallel-log, quiet, verbose, no-color, log-format, show-cache, banner, no-banner, legal

两点实现细节值得留意：

• normalize_vps_count_args()（reconftw.sh）将历史遗留的-v 20语法规范化为-v --vps-count 20，保证向后兼容；
• --source-only（reconftw.sh）允许只加载全部模块而不执行任何侦察逻辑，测试套件的setup()依赖此入口，相关用法可见 tests/unit/test_verbosity.bats。

编码约定：函数、变量与模块命名

Source Guard 模式

每个库文件顶部用_*_LOADED标记实现幂等加载，允许模块被多次 source（测试重载、--source-only）而不重复执行：

• lib/common.sh：[[ -n "$_COMMON_SH_LOADED" ]] && return 0
• lib/parallel.sh：[[ -n "$_PARALLEL_SH_LOADED" ]] && return 0
• lib/ui.sh：[[ -n "${_UI_SH_LOADED:-}" ]] && return 0

（注意lib/validation.sh例外：它使用错误码守卫而非_LOADED标记。）

函数命名三段式

• 公开模块函数：snake_case且带模块上下文前缀，如sub_passive、sub_crt、geo_info；
• 私有辅助函数：下划线前缀，如_print_status、_print_error、_parallel_emit_job_output；
• UI 层函数：ui_前缀，如ui_init、ui_header、ui_summary、ui_batch_end；
• 生命周期包装：start_func/end_func必须成对出现在每个侦察函数的顶部与底部；
• 校验函数：validate_*/sanitize_*，集中在 lib/validation.sh 与 modules/utils.sh。

变量命名约定

• 配置开关：SUBPASSIVE、SUBCRT、PARALLEL_MODE、OUTPUT_VERBOSITY；
• 运行时状态：LOGFILE、SCRIPTPATH、DIFF、DRY_RUN、AXIOM；
• 错误码（readonly，定义于 reconftw.sh）：E_SUCCESS=0、E_GENERAL=1、E_MISSING_DEP=2、E_INVALID_INPUT=3，以及扩展的E_NETWORK=4、E_DISK_SPACE=5、E_PERMISSION=6、E_TIMEOUT=7、E_CONFIG=8。

校验函数清单

lib/validation.sh 提供的校验函数（行号已验证）：

modules/utils.sh 中还提供sanitize_domain()（剥离 URL 组件、小写化、拒绝注入）、is_in_scope_host()（锚定主机名范围检查，防止子串误报）、filter_in_scope_urls()（基于 Python3 的 URL 范围检查，含 scheme/userinfo/host）。对应的安全测试见 tests/security/test_injection.bats、tests/security/test_scope_validation.bats。

函数生命周期与断点续跑机制

这是 reconFTW 最核心的工程机制，直接决定"中断后能否续跑"。

start_func / end_func

• start_func name desc（modules/core.sh）：写入 LOGFILE、设置函数级起始时间戳、在OUTPUT_VERBOSITY >= 2时输出 INFO，并创建.inprogress_<fn>哨兵文件用于崩溃遗留检测；
• end_func message name [status]（modules/core.sh）：计算耗时、输出状态行、touch 检查点文件、移除.inprogress_哨兵。状态参数支持info|warn|error|good|OK|WARN|FAIL|SKIP|SKIP_CONFIG|SKIP_NOINPUT|CACHE_HIT以及兼容旧调用的位置交换形式。

文件检查点（Resumability）

• 检查点文件位于Recon/<domain>/.called_fn/.<funcname>；
• 每个函数入口测试[[ ! -f "$called_fn_dir/.${FUNCNAME[0]}" ]] || [[ $DIFF == true ]]，end_func通过touch写入哨兵；
• DIFF=true（增量模式）会绕过检查点强制重执行；
• lib/common.sh 提供更干净的封装should_run()：if should_run "FLAG_VAR"; then，同时检查功能开关与检查点（DIFF模式下忽略检查点）。

语义要点（CLAUDE.md 明确强调）：检查点文件在end_func时"touch-once"，意味着被中断的函数在下次调用时会从头重跑，部分输出文件不会被检测——这是设计使然，不是缺陷。

日志与脱敏

• 所有工具输出重定向到$LOGFILE：command ... 2>>"$LOGFILE" >/dev/null；
• 可选结构化 JSON 日志：log_json level func message [key=val]（STRUCTURED_LOGGING=true）；
• redact_secrets()在写日志前擦除REDACT_VARS与REGISTERED_SECRETS中的敏感值；任何秘密值必须先register_secret "$value"再记录。相关安全测试见 tests/security/test_redact_secrets.bats。

架构分层与组件职责

CLAUDE.md 将代码库划分为五个层次：

各模块的职责分工（见 CLAUDE.md 组件表，均已与源码核对）：

• 模式编排modules/modes.sh：start/end、工作流函数recon、passive、all、vulns、osint、subs_menu、webs_menu、zen_menu、monitor_mode；
• 函数生命周期modules/core.sh：start_func/end_func、检查点、日志、通知、报告、插件、健康检查；
• 子域枚举modules/subdomains.sh：全部sub_*函数、subtakeover、zonetransfer、s3buckets、geo_info；
• Web 分析modules/web.sh：webprobe_full、screenshot、nuclei_check、fuzz、jschecks、urlchecks、waf_checks及 20+ 个函数；
• 漏洞扫描modules/vulns.sh：xss、ssrf_checks、sqli、crlf_checks、lfi、ssti、smuggling、fuzzparams、nuclei_dast等；
• OSINTmodules/osint.sh：domain_info、ip_info、emails、google_dorks、github_leaks、github_actions_audit、cloud_enum_scan等；
• 共享工具modules/utils.sh：run_command、sed_i、deleteOutScoped、validate_config、cache_*、checkpoint_*、circuit_breaker_*、速率自适应；
• Axiom 分布式modules/axiom.sh：axiom_launch、axiom_shutdown、axiom_selected、resolvers_update、ipcidr_target；
• 并行执行lib/parallel.sh：parallel_funcs、_throttle_jobs、job 心跳、进度实时显示、日志模式输出；
• UI 呈现lib/ui.sh：_print_status、_print_msg、_print_section、ui_header、ui_summary、TTY 检测、颜色管理、JSONL 输出。

关键抽象：统一工具闸门 run_command

CLAUDE.md 指出所有外部工具调用必须经由run_command <binary> <args>，而非直接执行。查看 modules/utils.sh 的实现，可以发现它承担了五个横切职责：

1. DRY-RUN 预览：DRY_RUN=true时打印将执行的命令（自动对-token-string、apiKey=、Authorization: Bearer做 REDACTED 脱敏）并返回 0，不实际执行；
2. Axiom 分发：命令名以axiom-开头时转交_run_axiom_command_with_detection；
3. Proxychains 透明路由：PROXYCHAINS=true且命令适用时，通过_proxychains_bin前置-q（可选-f指定配置）；若二进制缺失则响亮失败（warn 并跳过），而不是静默直连——这正是操作者启用代理的初衷；
4. 自适应速率限制：ADAPTIVE_RATE_LIMIT=true时转交run_with_adaptive_rate；
5. 调试日志：DEBUG_LOG设置时，按OUTPUT_VERBOSITY决定tee到调试日志或追加写入。

并行执行模型

单进程 + 后台子 shell

框架整体是单线程 Bash，并行只发生在parallel_funcs这一层：它把相互独立的模块函数作为后台子 shell 并行启动，用wait -n（bash 4.3+）做任务节流（_throttle_jobs），上限为PARALLEL_MAX_JOBS（实际值经_parallel_effective_max_jobs换算）。lib/parallel.sh 的实现细节：

• 每个 job 的输出写入$dir/.tmp/parallel/<func>.<pid>.<rand>.log，并单独记录结束时间戳；
• 函数不存在时打印 warn 并跳过；
• 并行失败计数会累加到RECON_OSINT_PARALLEL_FAILURES并设置RECON_PARTIAL_RUN=true。

parallel_funcs N func_a func_b func_c被recon()、osint()、vulns()用于运行相互独立的函数组。

输出模式与 verbosity

终端输出受OUTPUT_VERBOSITY控制，三个档位在 CLAUDE.md 中有明确定义：

• 0（quiet）：仅打印错误与最终摘要，横幅被抑制；
• 1（normal，默认）：打印 OK/WARN/FAIL/SKIP 状态行；
• 2（verbose）：以上全部 + INFO 消息 +start_func消息 + PID 信息。

并行日志另有四种模式：summary（每完成一个 job 输出一行徽章）、tail（每个 job 日志的最后PARALLEL_TAIL_LINES行，默认 20，失败时翻倍）、full（每个 job 的完整捕获 stdout）、jsonl-strict（强制OUTPUT_VERBOSITY=0，只输出机器可读 JSONL）。UI 相关的快照测试见 tests/unit/test_ui_snapshots.bats。

入口点与输出目录

三个关键入口点

输出目录的公共契约

Recon/<domain>/目录树是公共契约：子目录名与文件名被下游管道、脚本与解析器消费，重命名属于破坏性变更。start()在运行任何模块函数前cd "$dir"（进入目标输出目录），因此模块内的相对路径都相对于目标目录解析；reconftw.sh在此之前捕获startdir=${PWD}。

架构约束与反模式清单

必须遵守的约束

• 全局状态：所有配置变量、目标变量（domain、dir、called_fn_dir、LOGFILE）、结果计数器都是模块级全局变量，任何被 source 的函数都可读写——没有封装；
• 无子 shell 隔离：模块是被 source 的函数而非子进程，模块内return只是返回函数，而exit会杀死整个 shell；
• save/restore 模式：工作流函数若覆盖模块开关全局变量，必须保存并在结束时恢复（典型范式见passive()，CLAUDE.md 标注于 modules/modes.sh）；
• 单操作者：每个目标运行只为一个用户设计，无锁、无多用户状态、不支持对同一目标目录并发运行；
• CI 预算分层：集成全量测试每周 cron 跑一次，单元 + 冒烟测试每次 push 跑——新增重型集成测试必须尊重这一分工。

反模式清单（CLAUDE.md 明令禁止）

1. 绕过run_command直接调用外部工具——会丢失 dry-run、代理、速率限制与调试日志的横切能力；
2. 手工写检查点文件——检查点必须由end_func统一创建；
3. 跳过检查点守卫[[ ! -f "$called_fn_dir/.${FUNCNAME[0]}" ]] || [[ $DIFF == true ]]——会破坏断点续跑语义；
4. 工作流函数覆盖配置全局变量后不保存/恢复——会污染后续所有函数的执行环境。

错误处理与容错设计

• ERR trap：start()中注册的 ERR trap 会把函数名、行号与命令写入$LOGFILE并调用explain_err()（modules/modes.sh）；
• 并行失败累加：parallel_funcs非零退出会累加失败计数并置RECON_PARTIAL_RUN=true，让上层知晓本次为部分成功；
• Axiom 故障转移：run_module_with_axiom_failover（modules/modes.sh）捕获 Axiom 中途失败并在本地重试；
• 熔断器：circuit_breaker_is_open/circuit_breaker_record_failure（modules/utils.sh）针对持续失败的工具实现熔断；
• 磁盘满保护：start_func开头的_check_disk_mid_run在写任何状态前中止（见 modules/core.sh 的实现注释）；
• 健康检查：./reconftw.sh --health-check可一键验证运行环境。

工程化与质量保障

框架通过 Makefile 与 pre-commit 钩子维持工程质量：

• bats-core（Bash Automated Testing System）：单元测试在 tests/unit/，安全测试在 tests/security/，集成测试在 tests/integration/；
• shellcheck（error 级）：make lint，pre-commit 钩子强制执行；
• shfmt（4 空格缩进、-bn、-ci）：make fmt；
• semgrep：仅在 CI 运行（.github/workflows/semgrep.yml）。

代表性测试文件可直接深入研读：检查点与生命周期逻辑见 tests/unit/test_common.bats，校验函数见 tests/unit/test_validation.bats 与 tests/unit/test_validation_extended.bats，并行执行见 tests/unit/test_parallel.bats，监控模式见 tests/unit/test_monitor.bats。

总结：理解 reconFTW 的三个思维模型

读完整份架构与约定，可以用三个思维模型快速掌握这个框架：

1. "检查点即进度"：一切可续跑能力建立在end_func的 touch-once 检查点之上，DIFF模式是唯一强制重跑的开关；
2. "run_command 即边界"：所有外部工具调用收敛在单一闸门，dry-run、Axiom、proxychains、自适应限速与脱敏全部在此横切；
3. "全局变量即 API"：模块之间没有隔离层，配置开关、目标状态、结果计数器都是全局的，因此"save/restore 覆盖的全局变量"是每个工作流函数必须遵守的第一纪律。

对于想要为 reconFTW 新增模块或工具的开发者，推荐的入手路径是：先阅读 modules/modes.sh 了解工作流编排 → 以sub_*或webprobe_full为模板学习start_func/end_func/should_run的生命周期写法 → 所有工具调用一律走run_command→ 新增配置项按CLI_*覆盖模式接入 reconftw.cfg → 用 bats 单元测试与 shellcheck 守住质量底线。

• 渗透测试
• 网络安全
• 应用安全