简介：灯塔ARL资产侦察系统V2.6.2保姆级部署教程，面向安全团队、渗透测试人员及安全研究员，解决互联网资产快速发现与基础资产库构建问题。系统支持域名/IP资产发现、端口扫描、服务识别、资产分组管理、任务策略配置、周期任务调度，以及站点变化监控、文件泄漏检测，并可集成nuclei PoC与WebInfoHunter，适合攻防演练、安全巡检等场景。资源为PDF文档，共1个文件，压缩包大小631KB，内容涵盖Docker环境部署、镜像加速器配置（针对Docker Hub受限提供可用方案）、docker-compose安装、ARL项目下载、数据卷创建及镜像启动等完整步骤，并配有命令示例和注意事项，降低上手门槛。已有2744人学习/下载，是安全从业者快速搭建资产侦察平台的精简参考。 这两年给团队搭资产盘点，最深的感受是：很多“资产”压根不在你的台账里。明明主域名都登记过，可一个旧项目的子域名、一条被遗忘的DNS解析记录，都可能让内部服务器意外暴露在公网上。后来我用ARL灯塔搭了一套资产侦察系统，把域名和IP段喂进去，定时跑任务，新增子域、端口变化在首页就能看到。ARL（Asset Reconnaissance Lighthouse）开源、免费，V2.6.2这版用docker-compose一键部署很方便，从准备工作到跑通第一个任务，半小时左右就能完成。这篇文章就围绕V2.6.2的docker-compose部署，把前置环境、完整步骤、上线维护和排查思路一次讲透。
1. ARL到底解决什么问题
1.1 Excel台账永远比现实慢一步
很多团队对资产台账的理解还停留在“建一个Excel，谁负责谁维护”。但真实情况是：域名由好几个注册商管理，云服务器分散在不同账号，员工离职后交接表往往没人更新。结果就是，安全部门手里拿的不是实时地图，而是一张过期地图。ARL这类资产侦察系统，本质是把“我现在到底有哪些互联网资产”这个基础问题自动化：你告诉它域名、IP段，它定时去发现子域、开放端口、Web指纹，再汇总成资产列表。
这里要先说清楚一个边界：ARL定位是资产发现与梳理，不是漏洞扫描器。它帮你回答“有什么”，至于“有什么问题”，那是后续漏洞检测和评估的环节。使用这类工具，一定只针对自己有授权、归属本单位的资产去跑任务，未授权扫描的风险和法律责任都不是开玩笑的。
1.2 V2.6.2这版适合从哪开始了解
我用的V2.6.2，官方仓库默认就是按容器化方式组织的，拉下来改改配置就能跑。相比老版本，部署成本明显低，不再需要自己折腾Python虚拟环境、MongoDB连接、任务队列这些东西。ARL的核心能力大致可以分成四块：
- 子域名收集：通过证书透明日志、字典规则等途径，把主域名下的子域尽量收集全。
- 端口服务识别：对目标IP或域名常见的端口做探测，识别开放的服务类型。
- Web指纹识别：识别站点用的是什么CMS、框架、中间件，方便后续统一评估。
- 任务编排与展示：支持单个任务、周期任务，跑完的结果在资产列表、统计页统一展示。
这四块组合起来，就是一台相对完整的资产发现引擎。尤其适合攻防演练前、新业务上线时的自检：把自己名下的域名批量导进去，系统跑一遍，结果比人肉填表可靠得多。
1.3 为什么部署形式选docker-compose
ARL也可以源码部署，但源码部署要解决Python版本、系统依赖、MongoDB连接、任务Worker等一堆环境问题。新机器上手，光排依赖就要花不少时间。docker-compose的好处是，MongoDB、Web服务、任务Worker这三个角色都写在了compose文件里，一条命令就能拉起来，数据卷直接挂在宿主机上，升级回滚不会动到底层数据。
而且ARL本身只依赖MongoDB作为核心存储，不需要像部署其他企业平台那样再单独准备Redis、PostgreSQL等组件。compose文件里数据库和服务端都已经编排好，这对快速落地非常友好。你只需要保证宿主机有Docker和docker-compose，剩下的就是拉代码、改配置、启动。
2. 部署前的服务器和Docker环境
2.1 硬件配置和系统选型
先给一份我实际使用的参考配置，如果你的任务量不大，可以适当降低，但不建议太低。
| 项目 | 最低配置 | 推荐配置 |
|---|---|---|
| CPU | 2核 | 4核 |
| 内存 | 4GB | 8GB |
| 磁盘 | 20GB | 50GB以上，建议SSD |
| 系统 | Ubuntu 18.04+ / CentOS 7+ | Ubuntu 22.04 LTS |
内存是这个系统最容易出问题的地方。ARL跑子域名收集、端口扫描和页面快照时，Worker进程对内存的消耗会明显上升；如果机器只有2GB内存，MongoDB很容易被系统OOM杀掉，表现就是登录页502或者Mongo容器反复重启。磁盘方面也别只看初始占用，页面快照和扫描结果会慢慢累积，任务跑得勤的话，50GB都有可能告急。
系统版本尽量选新一点的LTS。老CentOS 7装新版本docker-compose有可能遇到glibc版本问题，虽然能解决，但没必要在一开始就给自己挖坑。
2.2 安装Docker和compose最省事的路径
ARL并不强制要求最新版本，Docker 19.0以上、Compose 1.29以上都可以。这里最推荐用系统包管理器安装，而不是直接用pip。
# Ubuntu / Debian sudo apt update sudo apt install docker.io docker-compose-plugin -y # CentOS / RHEL 类系统 sudo yum install docker-ce docker-compose-plugin -y安装完成后确认版本：
docker --version docker compose version docker-compose --version有些服务器上docker-compose命令不存在，只装了docker compose（v2插件），这没关系，命令格式去掉横杠、加个空格：docker compose up -d。文章后面我统一用docker-compose写法，你本地按实际可用的命令替换即可。
如果系统仓库里没有compose插件，或者版本太老，就需要手动下载二进制文件：
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-compose --version这个下载过程在部分网络环境下会比较慢，可以用可信的镜像加速站替换URL，或者在有网络的机器上提前下载好，再传到内网服务器。很多人在麒麟、国产化系统上离线部署时，就是这个思路：把docker和compose的安装包、ARL镜像tar包一起拷进去，离线安装加载。
2.3 镜像仓库加速与离线安装场景
Docker容器要跑起来，首先要有一堆镜像。ARL的compose文件里包含MongoDB、ARL Web、ARL Worker等镜像，全部从Docker Hub拉取。国内服务器直连Docker Hub经常很慢甚至超时，建议提前配置镜像加速器。
编辑/etc/docker/daemon.json：
{ "registry-mirrors": ["https://docker.m.daocloud.io"] }改完必须重启Docker才生效：
sudo systemctl daemon-reload sudo systemctl restart docker这里要注意：加速器属于第三方公共镜像服务，不同服务商长期可用性不一样，建议选择有备案、运维稳定的服务商，同时做好镜像校验。如果你所在的网络环境完全不能访问外网，那就走离线安装路线：在一台有网络且相同CPU架构的机器上，先把ARL相关镜像全部拉下来，然后导出成tar包：
docker-compose pull docker save -o arl-images.tar 镜像1 镜像2 镜像3把tar包拷贝到内网目标机器后加载：
docker load -i arl-images.tar之后再执行docker-compose up -d，就不会再去远程拉镜像了。
3. 用docker-compose把ARL V2.6.2跑起来
3.1 获取源码并确认compose文件内容
ARL的部署入口是官方GitHub仓库里的docker-compose相关文件。服务器上先把源码拉下来：
git clone https://github.com/TophantTechnology/ARL.git cd ARL ls -la如果git clone很慢，也可以在本地下载zip包再上传到服务器，效果一样。进入目录后重点看两个文件：docker-compose.yml和config-docker.yaml。前者定义了服务端口、容器编排和卷挂载，后者是ARL运行时的配置，包括密钥、扫描超时、任务参数等。
先用编辑器或cat看一眼compose文件里的端口映射。ARL默认管理端口是5003，HTTPS协议访问。如果这台服务器上5003已经被占用，或者你不想用默认端口，就在compose文件里改映射，例如映射到8443：
ports: - "8443:5003"3.2 改端口、密钥和扫描参数
端口是第一个要改的，紧接着是密钥。config-docker.yaml里有一项secret_key，默认值如果不变，在公网环境会有会话伪造风险，建议改成一段足够长的随机字符串：
openssl rand -hex 32把生成的字符串填到secret_key后面对应位置。这个密钥改动后需要重启服务才生效。
还有一个值得花时间看的是扫描参数。比如portscan相关的端口范围、线程数、超时时间。默认配置通常偏保守，先在默认参数下跑一遍，确认整个链路没问题后，再根据自己的机器配置适当调整。不要一上来就把并发拉到很高，小内存机器很容易被打挂。
3.3 启动容器并确认三个服务健康
配置改完后，先拉取镜像再启动容器：
docker-compose pull docker-compose up -d第一次启动会花一些时间，因为要下载镜像。启动完成后查看容器状态：
docker-compose ps正常情况下会看到MongoDB、arlweb、arlworker三个容器都处于running状态。如果某个容器启动后退出，立刻看日志：
docker-compose logs -f --tail=200 arlweb日志是最直接的线索，比瞎猜配置有效得多。等Web服务日志出现监听端口的提示后，再继续下一步。
3.4 初始化账号和验证首个任务
ARL默认管理员账号一般是admin/arlpass，登录地址是https://服务器IP:8443，注意是HTTPS协议。因为用的是自签名证书，浏览器会弹出不安全的提示，点继续访问即可。
登录进去后先别急着做一堆配置，我的习惯是马上添加一个任务来验证全链路。选一个自己名下的真实域名，任务策略勾上子域名和端口扫描，范围控制在小一点，任务提交后等几分钟去看结果。如果任务顺利完成，资产列表里有数据刷新，说明Web、MongoDB、Worker三个角色配合正常，部署就成功了。
4. 部署上线后我更关注的四件小事
4.1 默认密码和访问控制必须马上处理
ARL默认密码是公开的，部署完第一件事就是改密码。改完密码后，还要从网络层面收紧访问。如果这台服务器有公网IP，我强烈建议不要把这个管理页面直接暴露在公网上，安全组或云防火墙里只放行公司办公网段的IP访问8443端口。
系统层面如果开了firewalld或ufw，同步配置放行规则。日常运维可以走后端跳板机，或者用内网堡垒机统一管理登录权限，避免把系统管理入口直接暴露给全网。这个习惯和部署什么系统都无关，属于“上线前基本素养”。
4.2 数据卷备份别等出问题再想
ARL真正有价值的不是那个部署环境，而是它积累的数据：资产列表、指纹信息、任务记录、历史变更。这些数据全部存在MongoDB的数据目录里，容器一删，如果不提前备份，数据基本就没了。
我现在的备份方式是每天用cron执行一次逻辑备份，保留最近7天：
docker exec arl_mongodb mongodump --archive=/tmp/arl_backup_$(date +%F).gz --gzip docker cp arl_mongodb:/tmp/arl_backup_$(date +%F).gz /backup/备份文件尽量同步到其他机器，不要和主服务放在同一块磁盘上。数据备份这件事，平时感觉不到价值，真到了要恢复的时候才知道有多重要。
4.3 升级和回滚的基本流程
ARL迭代比较快，官方仓库更新后，升级流程很简单：
git pull docker-compose pull docker-compose up -d每次升级前至少完成两件事：备份数据库、备份当前的config-docker.yaml和compose文件。升级后如果发现新版本有问题，可以快速回滚：
git checkout 旧版本tag或commit docker-compose up -d --force-recreate只要数据卷没有手动删除，容器重建不会影响已有数据。不过配置文件的变更要自己比对，回滚时一并恢复旧配置。
4.4 跑成业务后怎么控制资源消耗
ARL跑起来后，最占资源的往往不是扫描本身，而是页面快照和大量资产的缓存。任务执行频繁，磁盘占用会像日志文件一样持续增长。我的处理方式是把定时任务频率控制在合理范围，比如重要业务域名每天跑一次，宽泛IP段每周扫一次，不要所有策略都设成每小时执行。
如果明显感觉到页面响应变慢，先去看内存和磁盘，清理历史任务和大体积快照；再不合理再考虑调低Worker并发。反过来，如果任务排队明显，也可以多起一个Worker实例，但前提是CPU和内存都有富余，否则只是把瓶颈从排队变成OOM。
5. 部署过程中常见的排查路径
5.1 镜像拉取超时，任务还没开始就卡住
这是所有人第一次部署时最容易碰到的问题，表现形式就是docker-compose up -d后长时间停在pull镜像阶段，日志一直在重试。原因基本都指向Docker Hub连接不稳定。处理方法在2.3节说过：配置镜像加速器后重启Docker，或者干脆离线load镜像包。
改完镜像加速器再启动前，可以先执行docker info确认镜像仓库配置已经生效。这个步骤很多人会漏掉，改完daemon.json不重启，后面还是慢，白白等半天。
5.2 Mongo容器反复重启或登录页502
如果登录页直接502，十有八九是MongoDB容器没起来，或者Web服务连接不上数据库。先看容器状态：
docker-compose ps如果Mongo容器一直restarting，优先怀疑内存不足。用下面的命令检查容器是否被系统OOM杀过：
docker inspect 容器ID --format '{{.State.OOMKilled}}'返回true就说明是真的被系统杀掉过，解决办法是加内存，或者给系统增加swap，然后重启容器。另一种常见情况是宿主机磁盘满了，MongoDB写不了数据也会反复退出，清理磁盘后恢复。
5.3 子域名和指纹结果不全
任务能跑完，但结果比预期少很多，这事也得看具体环节。子域名收集依赖多个数据来源，包括DNS解析、证书透明日志接口等，如果网络环境不稳定，部分外部接口请求失败，结果就会少。
可以试着在compose文件中给服务增加自定义DNS，比如使用国内公共DNS：
dns: - 223.5.5.5 - 119.29.29.29改完重启容器再跑一次任务。另外，ARL的指纹库和子域字典有时需要同步更新，记得定期拉代码或更新扩展库，否则新出现的框架、组件识别不出来，结果自然旧。
5.4 页面能开但任务一直排队
页面能打开，说明Web服务没问题；任务却一直排队，多半是Worker没在正常干活。看容器列表，如果arlworker容器状态异常或者根本没起来，重启它：
docker-compose restart arlworker如果重启后依然排队，去翻arlworker的日志，看是不是消息队列连接失败。这类问题多数是compose网络内部服务名解析出错，或者因为反复重启导致容器之间的网络残留异常。常见做法是docker-compose down后重新up -d，让容器在网络里重新注册一遍，很多时候比单独重启任何一个容器都有效。
ARL这套系统部署本身不复杂，真正花时间的往往是部署完之后的维护：备份策略、定时任务节奏、结果复盘。我自己的做法是先把一个真实业务域名跑上一周，拿结果跟现有台账做交叉比对，确认它对团队有实际帮助后再全量接入。数据慢慢变多以后，你还会遇到告警太多、磁盘涨得快这类新问题，那都是后话。当前最要紧的，就是把这套docker-compose环境稳定跑起来，把第一个任务的结果看明白。
本文还有配套的精品资源，点击获取
