开源资产侦察灯塔ARL：一体化网络资产发现与信息收集平台实战指南

1. 项目概述：为什么我们需要一个“资产侦察灯塔”？

在网络安全领域，尤其是渗透测试和红队评估的初期，信息收集的广度和深度直接决定了后续行动的成败。想象一下，你面对的是一个庞大的企业网络，目标模糊，边界不清。传统的扫描工具要么功能单一，要么结果零散，你需要像拼图一样手动整合端口、服务、子域名、证书信息……这个过程不仅耗时，而且极易遗漏关键资产，导致评估范围不完整。这正是“资产侦察灯塔系统ARL”要解决的核心痛点。

ARL，全称Asset Reconnaissance Lighthouse，是一个开源的、一体化的网络资产侦察与信息收集平台。它不是一个简单的扫描器，而是一个“侦察指挥中心”。其核心价值在于，它将十几种常用的信息收集手段（如子域名枚举、端口扫描、服务识别、证书透明度日志查询、目录扫描等）集成在一个Web界面中，通过任务编排的方式自动化执行，并将所有结果进行关联、去重和可视化展示。最终，它为你呈现的是一张清晰的“资产地图”，告诉你目标有哪些域名、这些域名解析到哪些IP、这些IP开放了哪些端口和服务、甚至关联了哪些历史漏洞信息。对于安全工程师、渗透测试人员和企业安全运维团队而言，ARL极大地提升了资产发现和梳理的效率，让“侦察”阶段从体力活变成了技术活。

2. ARL系统核心架构与组件解析

要玩转ARL，不能只停留在点击按钮的层面，理解其内部组件如何协同工作，有助于我们在部署、调优和排错时得心应手。ARL的整体架构可以看作一个经典的分布式任务处理系统。

2.1 前后端分离与任务调度引擎

ARL采用前后端分离的设计。前端是一个Vue.js构建的Web界面，负责任务配置、结果展示和用户交互。后端核心是Python（Flask框架），它不直接执行繁重的扫描任务，而是扮演“调度中心”的角色。当你在前端创建一个资产侦察任务（比如针对一个主域名）后，后端API会接收这个任务，并将其分解成多个子任务，例如：子域名发现、端口扫描、服务识别等。

这些子任务会被放入一个消息队列（默认使用Redis）。这是ARL设计的关键，它实现了任务的异步处理和负载均衡。多个“工人”（Worker）进程会持续监听这个消息队列，一旦有新的子任务，就会领取并执行。这种设计使得ARL可以横向扩展：如果你觉得扫描速度慢，可以单独增加Worker的数量，而无需改动核心调度逻辑。

2.2 核心侦察插件与数据流

Worker执行的任务，实际上是在调用一个个独立的“插件”或“脚本”。ARL的强大之处就在于它集成了众多优秀的开源工具作为其侦察引擎：

1. 子域名枚举：综合使用了多种技术。包括利用在线API（如SecurityTrails, VirusTotal）、爬取证书透明度日志（Cert.sh）、进行字典爆破（使用massdns）以及利用DNS记录查询（如AXFR漏洞检测）。ARL会将这些来源的结果进行聚合去重，得到一份相对完整的子域名列表。
2. 端口扫描：底层通常依赖masscan进行全端口快速扫描，定位开放端口；再使用nmap对开放的端口进行服务版本探测和脚本扫描，获取更详细的信息（如HTTP标题、SSL证书、可能的漏洞指纹）。
3. WEB应用发现与爬虫：对于识别出的Web服务（80/443/8080等端口），ARL会调用爬虫（如crawlergo）进行深度抓取，以发现更多的链接、目录和参数。同时，它也会进行简单的目录爆破和敏感文件扫描。
4. 数据关联与存储：所有收集到的原始数据（域名、IP、端口、服务、标题、证书等）都会被解析并结构化地存入数据库（默认MongoDB）。ARL的后台逻辑会将这些数据关联起来，形成一个图谱。例如，点击一个IP地址，你可以看到这个IP上所有开放端口对应的域名；点击一个域名，可以看到它的所有历史解析记录和关联的证书。

注意：ARL集成的许多工具（如masscan, nmap）本身功能强大，但不当使用可能对目标造成压力甚至被视为攻击。务必确保你的扫描行为获得了合法授权。在内部资产梳理时，也建议设置合理的速率限制和并发数。

2.3 容器化部署的优势与考量

官方推荐的部署方式是使用Docker和Docker Compose。这带来了极大的便利性：

• 环境隔离：所有组件（前端、后端、Redis、MongoDB、Worker）都在独立的容器中运行，避免了与宿主机环境的依赖冲突。
• 一键部署：只需几条命令即可搭建完整系统，无需手动安装和配置Python、Node.js、Redis、MongoDB等复杂环境。
• 易于维护和升级：通过更新镜像版本即可完成系统升级。

然而，容器化也带来了一些需要关注的点：

• 资源占用：MongoDB和扫描任务（特别是masscan）可能消耗大量内存和CPU。你需要为Docker分配足够的资源（建议宿主机至少2核4G以上）。
• 数据持久化：必须将MongoDB的数据目录和任务日志目录通过“卷”（Volume）映射到宿主机，否则容器重启后所有扫描数据都会丢失。
• 网络模式：ARL的Worker容器需要能够访问外网以进行DNS解析和API查询，同时也要能扫描内网目标。需要理解Docker的网络模式（通常使用host模式或自定义桥接网络），确保网络连通性正确。

3. 从零开始：ARL的详细搭建与初始化配置

理论清晰后，我们进入实战环节。以下搭建过程基于Linux服务器（以Ubuntu 20.04为例），这是最推荐的生产环境。

3.1 基础环境准备与Docker安装

首先，确保服务器有稳定的网络连接和足够的资源。然后安装Docker引擎和Docker Compose。

# 更新系统包索引 sudo apt-get update # 安装必要的依赖包，允许apt通过HTTPS使用仓库 sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common # 添加Docker官方GPG密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - # 设置稳定版Docker仓库 sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" # 再次更新包索引并安装Docker CE sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 安装Docker Compose (以v2为例，可从GitHub release页面获取最新版本) sudo curl -L "https://github.com/docker/compose/releases/download/v2.23.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose # 验证安装 docker --version docker-compose --version

3.2 获取ARL并配置关键文件

从官方GitHub仓库拉取代码，其docker目录下包含了部署所需的所有文件。

# 克隆仓库（如果速度慢，可考虑使用代理或镜像源） git clone https://github.com/TophantTechnology/ARL.git cd ARL/docker

在启动前，最重要的配置文件是docker-compose.yml和.env文件（或config-docker.yaml）。你需要关注以下几点：

1. 修改默认密码：在.env或config-docker.yaml中，找到ARL_ADMIN_PASSWORD和ARL_USER_PASSWORD，务必修改默认的arlpass，设置强密码。
2. 配置MongoDB持久化：在docker-compose.yml中，查看MongoDB服务的volumes配置，确保类似- ./mongo/data/db:/data/db的映射存在。这将数据保存在宿主机的./mongo/data/db目录下。
3. 调整资源限制（可选但建议）：根据服务器性能，可以在docker-compose.yml中为worker和mongo服务增加资源限制，防止单个任务耗尽资源。

   worker: ... deploy: resources: limits: cpus: '2' memory: 4G

4. 配置扫描速率和并发（关键！）：在config-docker.yaml中，找到与扫描相关的配置，如masscan速率、nmap并发数等。对于内网扫描或授权测试，可以适当调高；对于外部或敏感目标，务必调低，避免触发防护。

   # 示例配置片段 port_scan: masscan_rate: 1000 # masscan扫描速率，包/秒 task: max_concurrent_task: 3 # 最大并发任务数

3.3 启动系统与初次登录

配置完成后，使用一条命令启动所有服务：

# 在ARL/docker目录下执行 docker-compose up -d

-d参数表示后台运行。首次启动会拉取镜像并创建容器，需要几分钟时间。你可以使用以下命令查看启动日志和状态：

# 查看所有容器状态 docker-compose ps # 查看实时日志（Ctrl+C退出） docker-compose logs -f

当所有容器状态均为running后，即可通过浏览器访问http://你的服务器IP:5003。使用默认用户名admin和你设置的密码登录。

实操心得：启动后如果无法访问，首先检查服务器防火墙是否放行了5003端口（sudo ufw allow 5003）。其次，用docker-compose logs arl重点查看arl容器的日志，常见错误包括数据库连接失败（检查MongoDB容器是否健康）、配置文件格式错误等。

4. ARL核心功能实战：执行一次完整的资产侦察任务

登录后，我们以一个虚构的授权测试目标example.com为例，演示一次标准流程。

4.1 任务创建与策略选择

在ARL前端，点击“任务”->“新建任务”。在任务页面，有几个关键配置项：

• 任务名称：自定义，便于识别，如“example_com_initial_scan”。
• 目标：输入主域名，如example.com。ARL也支持IP段（如192.168.1.0/24）和IP列表。
• 侦察选项：这是ARL的精华所在，决定了侦察的深度和广度。
  • 域名收集：必选。它决定了子域名枚举的强度。建议在初次全面侦察时勾选所有可用选项（证书获取、域名爆破、搜索引擎等）。
  • 端口扫描：必选。选择端口扫描策略。“TOP100”速度快，“全端口”更全面但耗时。对于重要目标，建议先进行“全端口”扫描。
  • 服务识别：必选。在端口扫描后，调用nmap进行服务详情探测。
  • 网站识别：对于识别出的Web服务，进行标题、状态码获取。
  • 网站爬虫：深度抓取网站内容，发现更多路径。对于大型网站，谨慎使用，可能产生大量请求。
  • 漏洞扫描（PoC）：调用内置的PoC库进行漏洞验证。在未明确授权的情况下，慎用此功能。
• 高级设置：这里可以设置任务优先级、自定义字典（用于子域名爆破）、排除的域名或IP等。

策略选择建议：对于外部资产梳理，一个平衡的策略是：开启所有域名收集选项，端口扫描选择“TOP1000”或自定义重要端口列表，开启服务识别和网站识别，暂时关闭深度爬虫和漏洞POC。先摸清资产轮廓，再针对性地进行深度扫描。

4.2 结果分析与资产梳理

任务提交后，可以在“任务列表”中查看状态。一个大型域名的完整扫描可能需要数小时甚至更久。完成后，点击进入任务详情。

ARL将结果分门别类地展示：

1. 域名列表：展示发现的所有子域名（如www.example.com,mail.example.com,dev.api.example.com）。你可以导出列表，或点击某个域名查看详情。
2. IP列表：展示所有解析到的IP地址，并关联其开放的端口。这里可以发现一个IP承载了多个域名（虚拟主机），或者一个域名有多个IP（负载均衡）。
3. 端口列表：以端口视角展示，例如所有开放了443端口的IP和域名。
4. 网站列表：专门展示Web服务，包含页面标题、状态码、指纹（如ThinkPHP,Spring Boot）、WAF识别结果等。这是后续Web渗透测试的重点入口。
5. 证书列表：展示从HTTPS服务获取的SSL证书信息，证书中可能包含其他未在DNS中直接列出的域名。
6. 资产组合：这是ARL的亮点功能，它自动将域名、IP、端口、服务关联成一个树状图或列表，让你一目了然地看到整个资产的结构。

分析技巧：重点关注以下几点：

• 意外的暴露面：是否在公网发现了测试环境（dev/test/staging）、后台管理系统（admin, manage）、老旧应用（phpMyAdmin, Jenkins）？
• 非常规端口：除了80/443，是否在8080、8443、7001等端口发现了Web服务？
• 服务指纹：识别出的中间件（Apache, Nginx, IIS）、框架（Spring, Django）、CMS（WordPress, Joomla）版本是否过旧，存在已知漏洞？
• 关联资产：通过一个已知IP或证书，发现一批未在前期情报收集范围内的关联域名。

4.3 数据导出与报告生成

ARL支持将各类结果以CSV或JSON格式导出，方便导入到其他工具（如Excel进行统计分析，或导入到漏洞管理平台）进行后续处理。虽然ARL本身不生成精美的渗透测试报告，但导出的结构化数据是编写报告“资产发现”章节最有力的素材。

你可以筛选出高风险资产（如暴露的管理后台、存在已知漏洞指纹的服务），将其单独导出，作为下一步漏洞验证和深度测试的目标清单。

5. 高级技巧与性能调优指南

当你能熟练完成基础扫描后，以下技巧能让你更好地驾驭ARL。

5.1 自定义字典与插件扩展

ARL的子域名爆破效果很大程度上依赖于字典的质量。系统内置了基础字典，但对于特定行业（如金融、教育）或大型企业，使用自定义字典效果更佳。

• 添加自定义字典：将你的字典文件（每行一个子域名前缀，如api,mobile,oa）放入宿主机某个目录，例如/opt/arl_custom_dict.txt。然后修改Worker容器的配置，在docker-compose.yml中，为worker服务添加一个卷映射，将宿主机字典目录挂载到容器内ARL字典路径下，并修改配置文件指向该字典。
• 集成外部工具：ARL的插件体系允许集成更多工具。例如，你可以编写脚本，让ARL在发现Web服务后自动调用xray或nuclei进行被动扫描。这需要对ARL的代码结构有一定了解，通常需要修改app/目录下的任务调度逻辑和Worker执行脚本。

5.2 分布式部署与大规模扫描

当需要扫描的资产量极大（如成千上万个IP段）时，单机ARL可能力不从心。此时可以考虑分布式部署。

核心思路是将Worker组件分布式部署。主节点（运行arl-web,arl-scheduler,redis,mongodb）负责任务分发和结果存储。多个从节点（只运行arl-worker）从主节点的Redis队列中拉取任务执行。关键配置在于所有节点的config-docker.yaml中的Redis和MongoDB连接地址，需要指向主节点。

# 从节点worker配置文件中 redis: host: “主节点IP” # 修改为实际IP port: 6379 password: “你的Redis密码” mongodb: host: “主节点IP” # 修改为实际IP port: 27017 username: “你的MongoDB用户” password: “你的MongoDB密码” db_name: “arl”

这样，扫描能力就与Worker节点数量成正比。你需要确保所有Worker节点网络都能访问到目标，并且能连通主节点的Redis和MongoDB。

5.3 安全加固与日常维护

ARL本身存储了大量敏感的资产数据，其安全性至关重要。

1. 修改默认密码：再次强调，这是第一步。
2. 限制访问IP：通过服务器防火墙（如ufw）或Web服务器（如Nginx反向代理）限制只有可信IP才能访问ARL的Web端口（5003）。
3. 启用HTTPS：使用Nginx反向代理，并为ARL配置SSL证书，避免登录凭证和传输数据被窃听。
4. 定期备份MongoDB数据：使用mongodump命令定期备份宿主机上映射的数据库目录。

   # 示例备份命令 docker exec arl_mongodb mongodump -u username -p password --authenticationDatabase admin --db arl --out /data/backup/ # 然后将容器内的备份文件复制出来

5. 监控资源与日志：使用docker stats监控容器资源占用。定期查看docker-compose logs，关注错误和警告信息。
6. 及时更新：关注GitHub仓库的Release，及时更新镜像以获取新功能和漏洞修复。更新前务必做好数据和配置的备份。

6. 常见问题排查与实战心得

即使按照教程操作，在实际部署和使用中仍会遇到各种问题。这里记录一些典型场景和解决思路。

6.1 部署与启动问题

问题1：执行docker-compose up -d后，容器不断重启或状态为unhealthy。

• 排查：使用docker-compose logs [服务名]查看具体日志。常见原因：
  • MongoDB启动失败：检查宿主机映射的数据目录权限，确保MongoDB容器有写入权限（sudo chown -R 999:999 ./mongo/data）。
  • Redis连接失败：检查.env文件中Redis密码配置是否与docker-compose.yml中一致。
  • 端口冲突：确保宿主机5003、27017等端口未被占用。
• 解决：根据日志错误信息搜索解决方案。一个万能方法是彻底清理后重试：docker-compose down -v（这会删除数据卷，慎用！），然后重新docker-compose up -d。

问题2：Web界面可以访问，但提交任务后一直处于“等待中”或“进行中”无进度。

• 排查：这通常意味着Worker没有正常工作。检查Worker容器日志：docker-compose logs worker。
• 常见原因：
  • 网络问题：Worker容器无法访问外网进行DNS解析或API查询。尝试在Worker容器内ping 8.8.8.8和curl https://example.com。如果不行，检查Docker网络配置，尝试将docker-compose.yml中worker的network_mode改为host（注意这会改变网络模式）。
  • 资源不足：Worker进程因内存不足被系统杀死。查看宿主机内存使用情况，增加Worker容器的内存限制或减少任务并发数。
  • 配置错误：config-docker.yaml中某些工具路径或参数配置错误。对比官方配置文件。

6.2 扫描功能相关问题

问题3：子域名收集结果非常少。

• 排查：首先确认目标域名是否有大量子域名。然后检查任务配置是否勾选了足够的“域名收集”选项。查看任务详情页的“域名收集”子任务日志。
• 可能原因：
  • API密钥失效或未配置：ARL的某些在线查询源（如SecurityTrails）需要API密钥。如果没有配置或密钥失效，该来源的结果会为空。检查配置文件中的API密钥部分。
  • 字典不够强：爆破依赖于字典。尝试使用更大、更专业的子域名字典。
  • 目标DNS防护：有些企业部署了DNS防火墙，会拦截字典爆破请求。

问题4：端口扫描速度极慢，或大量漏报。

• 排查：检查masscan的速率配置（masscan_rate）。速率设置过低会导致扫描慢，过高可能被目标屏蔽或丢包。
• 调整策略：
  • 对于内网扫描，可以将速率调至5000-10000。
  • 对于外网扫描，建议从1000开始，根据网络状况和目标响应调整。
  • 确保运行ARL的服务器本身网络带宽和性能足够。masscan是全速扫描工具，会占满指定速率。
  • 漏报可能是由于网络不稳定或目标防火墙拦截。可以尝试对单个IP进行多次扫描验证。

问题5：Web爬虫卡住或产生海量请求。

• 原因：爬虫陷入动态生成的无限链接（如日历、分页器），或网站规模本身很大。
• 应对：
  • 在任务高级设置中，合理设置爬虫的“最大爬取链接数”。
  • 针对大型扫描，可以先不开启爬虫，仅做网站识别。后续对重要的、特定的Web应用单独开启爬虫任务。
  • 使用“排除规则”过滤掉不必要的路径（如图片、CSS、JS文件后缀）。

6.3 使用经验与最佳实践

• 分阶段扫描：不要一次性对一个大型目标开启所有最强选项。建议：第一阶段，仅做域名收集和快速端口扫描，摸清资产范围。第二阶段，针对发现的IP和端口进行详细的服务识别。第三阶段，对关键的Web服务进行爬虫和漏洞POC扫描。
• 善用“资产组合”和“任务对比”：定期对同一目标进行扫描，并使用“任务对比”功能，可以快速发现新增或减少的资产（如新上线的测试服务器、下线的老旧系统），这对于持续监控和攻击面管理非常有价值。
• 数据是核心，定期备份：ARL产生的资产数据库是长期积累的成果。建立自动备份机制，备份MongoDB数据文件和配置文件。
• 法律与授权红线：这是最重要的“心得”。ARL是一个强大的工具，但工具本身无善恶。绝对禁止在未获得明确书面授权的情况下，对任何不属于你或你未拥有管理权限的网络资产进行扫描。即使在授权范围内，也应遵守测试时间窗口、扫描速率等约定，避免对目标业务造成影响。