ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

theHarvester 安装指南:Kali 发行包、源码编译与 Docker Compose 部署全解析

theHarvester 安装指南:Kali 发行包、源码编译与 Docker Compose 部署全解析 theHarvester 安装指南Kali 发行包、源码编译与 Docker Compose 部署全解析【免费下载链接】theHarvesterE-mails, subdomains and names Harvester - OSINT项目地址: https://gitcode.com/GitHub_Trending/th/theHarvestertheHarvester 是一款用于渗透测试早期阶段的 OSINT 信息收集工具可采集邮箱、子域名与主机名。本文以仓库中的 安装文档 为主线完整覆盖三条安装路径——Kali Linux 发行包、基于uv的源码编译以及面向 HarvestView 可视化工作台的 Docker Compose 部署并深入源码与配置文件说明各安装环节背后的版本约束、依赖锁定与安全设计。读完本文你将能够根据自己的环境选择正确的安装方式完成工具自检并搭建一个具备 API 鉴权、只读文件系统与数据持久化的本地 HarvestView 服务。安装前置Python 3.14 与 uv 版本策略theHarvester 对运行时环境有严格约束要求 Python 3.14 及以上版本。这一约束同时体现在仓库的.python-version文件内容为3.14与 pyproject.toml 的requires-python 3.14声明中。仓库采用uv作为依赖管理工具.python-version的作用是让uv在同步依赖时自动选择 3.14 解释器无需手动指定。官方 README 中列出了当前发行包所对应的版本信息安装前建议核对。从源码角度看bin/theHarvester 启动脚本也会在运行时做一次防御性检查当sys.version_info (3, 14)时直接打印theHarvester requires Python 3.14 or newer并退出避免在不兼容解释器上运行导致不可预期的行为。另外需注意 pyproject.toml 中[tool.uv]的exclude-newer 7 days与python-preference managed配置前者限制了依赖解析时的版本时间窗后者让uv优先使用它管理的 Python 环境这解释了为什么推荐统一使用uv而非系统级pip。路径一Kali Linux 发行包安装Kali Linux 直接打包了 theHarvester使用系统包管理器即可完成安装sudo apt update sudo apt install theharvester theHarvester -htheHarvester -h既用于验证安装是否成功也用于确认工具入口命令可用。需要注意以下几点版本可能滞后发行包通常会落后于仓库当前 stable 版本或dev分支。安装后如果发现可用命令或数据源与仓库 README 描述不一致应先执行apt update更新索引并核对打包版本号。源码为准文档明确说明如果安装的命令或可用数据源与仓库不同先更新 Kali 并检查打包版本。对于需要最新数据源discovery 模块的场景推荐直接采用源码安装方式。路径二源码检出与 uv 依赖锁定从源码安装能保证你拿到与仓库完全一致的依赖版本官方推荐的命令序列为git clone https://github.com/laramies/theHarvester.git cd theHarvester uv sync uv run theHarvester -h依赖锁定机制uv sync依据仓库根目录的 uv.lock 安装锁定的运行时依赖。锁定文件的重要性体现在 pyproject.toml 的dependencies中——所有运行时依赖都采用精确版本号如aiohttp3.14.3、playwright1.60.0、fastapi0.138.1、sqlalchemy2.0.51而非范围约束这保证了锁定的运行依赖这一安装承诺可复现。贡献者模式安装开发依赖组普通用户只需uv sync安装运行时依赖如果你计划参与开发或运行测试则应安装全部开发依赖组uv sync --all-groups uv run pytest开发依赖定义在 pyproject.toml 的[dependency-groups]中包含pytest、pytest-asyncio、pytest-playwright、ruff、ty、httpx及类型标注包types-*等。pytest 的配置同样在 pyproject.toml 中testpaths [tests]指定测试根目录addopts --no-header --strict-markers -m not harvestview_e2e默认跳过需要真实浏览器的 HarvestView 端到端测试内置三个标记live_network需--run-live-network才会联网、provider_contract确定性离线契约测试、harvestview_e2e真实浏览器测试。控制台命令说明安装完成后可用的控制台命令由 pyproject.toml 的[project.scripts]声明命令入口函数用途theHarvestertheHarvester.theHarvester:main主程序OSINT 收集harvestviewtheHarvester.harvestview:mainHarvestView Web 工作台harvest-yieldstheHarvester.source_yields:main数据源产出分析注意仓库不存在根目录的theHarvester.py启动器。当前版本已迁移为标准的 Python 包结构入口位于 theHarvester/theHarvester.pybin/ 目录下的脚本仅作为兼容性启动壳。文档特别强调这一点避免用户在源码根目录寻找传统脚本而困惑。可选配置自托管 Tabulator 前端资源HarvestView 的 Web 界面默认从 CDNjs 加载 Tabulator 表格组件版本 6.5.2。对于需要完全隔离部署离线环境、内网的场景官方提供了将资源本地化的完整方案。下载锁定版本的 CDN 资源需要下载两个文件并放入theHarvester/lib/api/static/harvestview/目录该目录现有app.css、app.js、index.html等文件文件CDNjs 来源SRI 完整性哈希tabulator.min.csshttps://cdnjs.cloudflare.com/ajax/libs/tabulator-tables/6.5.2/css/tabulator.min.csssha512-t8I/asqzdu/MRgVLxVanQ/c5bhUA1qZ/zA432a/3nUh0kkd7P8Qch35wQvTODivf9D6Xv3h7F8p7ezcUyBOQrQtabulator.min.jshttps://cdnjs.cloudflare.com/ajax/libs/tabulator-tables/6.5.2/js/tabulator.min.jssha512-AF0YMSgc0Ui4IJPb4hJNSi16wFidZEQa6ZTCAeguF3h5glVnAPuz/JT2ai9ypKhsc9n6CEXBBtMdxsv1qrxg上表的 SRISubresource Integrity哈希可以在联网环境中校验下载文件的完整性保证离线部署的二进制与 CDN 完全一致。替换 index.html 中的 CDN 标签在联网环境中下载上述文件后编辑 theHarvester/lib/api/static/harvestview/index.html。当前该文件第 9 行与第 405 行分别引用了 CDN 的 CSS 与 JS均带integrity、crossorigin、referrerpolicy属性。将其替换为同源same-origin引用link relstylesheet href/static/harvestview/tabulator.min.css?v6.5.2 script src/static/harvestview/tabulator.min.js?v6.5.2/script同时必须移除本地标签中仅适用于 CDN 的integrity、crossorigin、referrerpolicy属性否则浏览器会因本地文件无法满足 SRI 校验而拒绝加载。复制资源后需要重新构建包或容器镜像让新文件进入运行环境。可选配置浏览器支持与截图功能HarvestView 的截图选项需要 Playwright 兼容的 Chromium 浏览器。安装命令uv run playwright install chromium在 Linux 上Playwright 可能会提示缺少系统依赖库此时应按照其打印的主机特定依赖安装指引逐项处理然后重新执行浏览器安装。这一依赖的取舍在源码中有所体现Baidu 数据源在可用时优先使用 Chromium否则回退到 HTTP 请求也就是说截图浏览器对于 Baidu 搜索是可选的增强项。仓库的 pyproject.toml 将playwright1.60.0列入运行时依赖而 Dockerfile 在构建镜像时执行了playwright install --with-deps --only-shell chromium即容器镜像已内置仅含 shell 的 Chromium供可选截图使用。路径三Docker Compose 部署 HarvestView第三种方式是使用 Docker Compose 部署 HarvestView 服务。关键前提容器镜像的入口是harvestview命令见 Dockerfile 的ENTRYPOINT [harvestview]与CMD [-H, 0.0.0.0, -p, 8000]它不会打开交互式的 theHarvester CLI只提供 Web 工作台与 API。首次启动创建操作员密钥git clone https://github.com/laramies/theHarvester.git cd theHarvester install -d -m 0700 .secrets openssl rand -hex 32 .secrets/operator-api-key chmod 0444 .secrets/operator-api-key docker compose up --build -d docker compose ps这套文件权限设计有两层含义目录0700在宿主机上保护密钥目录防止其他系统用户读取文件0444只读权限让容器内非特权用户进程Dockerfile 中创建了 uid/gid 10001 的theharvester用户并以USER theharvester运行能够读取其 bind-mount 到容器中的密钥副本。服务与 API 地址服务启动后访问 HarvestView 工作台HarvestViewhttp://127.0.0.1:5000/Swagger API 文档http://127.0.0.1:5000/docs查看日志与停止服务docker compose logs -f theharvester.svc.local docker compose down底层配置解析docker-compose.yml 中的服务名是theharvester.svc.local其安全与运行特性可从配置文件中逐项确认配置项值说明端口映射127.0.0.1:${THEHARVESTER_PORT:-5000}:8000容器 8000 端口仅发布到宿主机回环地址 127.0.0.1:5000默认端口可用环境变量THEHARVESTER_PORT覆盖文件系统read_only: true只读根文件系统容器用户非特权用户uid 10001见 DockerfileUSER theharvester能力收缩cap_drop: [ALL]no-new-privileges: true丢弃全部 Linux capabilities数据持久化volumetheharvester-data→/var/lib/theharvester存放运行记录runs.sqlite 与 run-artifacts见 Dockerfile 环境变量密钥注入secretsoperator-api-key通过THEHARVESTER_API_KEY_FILE: /run/secrets/operator-api-key注入本地代理THEHARVESTER_HARVESTVIEW_LOCAL_PROXY: enabled启用 HarvestView 本地代理配置挂载api-keys.yaml、proxies.yaml只读挂载对应仓库 theHarvester/data/ 下的示例文件临时目录tmpfs/tmp128mnoexec/nosuid/nodev提供可写临时空间而不落盘健康检查每 30s 请求/api/v1/runs见 DockerfileHEALTHCHECK使用配置的 API Key 验证Chromium镜像内置 chromium仅 shell支撑可选的截图捕获密钥文件的读取逻辑在 theHarvester/lib/api/auth.py 中实现_configured_api_key()优先读取环境变量THEHARVESTER_API_KEY未设置时再读取THEHARVESTER_API_KEY_FILE指向的文件内容去除首尾空白。Docker 部署走的是第二种方式——密钥文件位于/run/secrets/operator-api-key。鉴权与网络安全注意事项文档给出了两条硬性安全要求所有/api/v1/*路由均需鉴权。从 auth.py 可以看到受保护路由通过get_api_key依赖校验请求头X-API-Key或 cookietheharvester-api-key并使用secrets.compare_digest做常数时间比较防止时序攻击未配置 API Key 时直接返回 503。不要更改回环端口映射也不要将服务直接暴露给不受信任的网络——除非你额外配置 TLS 与网络访问控制。当前 compose 文件将端口绑定在127.0.0.1这是刻意为之的默认安全姿态。安装完成后的下一步安装并验证完成后可继续阅读 快速入门指南 了解工具的日常使用流程数据源凭证API Key按需配置即可具体参见 配置与 API 密钥——theHarvester 的多数数据源在未配置凭证时也可正常使用被动收集能力。安装方式选择建议场景推荐方式理由日常使用 CLI 收集Kali 发行包一条命令完成随系统更新需要最新数据源/参与开发源码 uv sync精确依赖锁定--all-groups支持测试开发需要可视化工作台、API、计划任务Docker Compose非特权容器 只读根文件系统 密钥注入开箱即用 HarvestView完全离线/隔离环境源码或 Docker 自托管 Tabulator替换 CDN 资源为同源引用配合 SRI 校验保证一致性无论选择哪条路径都建议以theHarvester -hCLI或访问 HarvestView 地址Web完成最终验证并牢记该工具应用于已获授权的渗透测试与安全研究场景。【免费下载链接】theHarvesterE-mails, subdomains and names Harvester - OSINT项目地址: https://gitcode.com/GitHub_Trending/th/theHarvester创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表