灯塔ARL资产侦察系统部署实战：Docker Compose一键搭建指南

简介灯塔ARL资产侦察系统V2.6.2是一款面向安全团队与渗透测试人员的互联网资产发现与管理工具支持域名和IP资产整理、端口扫描、服务识别、站点指纹识别、资产监控及nuclei PoC调用等能力能有效帮助用户摸清资产暴露面并发现薄弱点可广泛用于安全合规检查、攻防演练及渗透测试前期的资产梳理场景。针对该版本部署资源包为单个PDF文档大小631KB以保姆级图文形式完整给出基于Docker与docker-compose的一键部署流程包括yum环境更新、Docker安装、镜像加速器配置、docker-compose两种安装方式、ARL项目下载、容器存储卷创建及镜像拉取等关键操作并专门说明2024年7月后Docker Hub无法使用时的加速器选择与配置方法可让读者避开常见坑点快速完成系统搭建。资源既适合初次接触灯塔ARL的入门用户也可为安全研究人员提供可复用的部署参考目前已有2744人学习下载。1. 先搞清楚ARL是什么适合什么场景灯塔ARLAsset Reconnaissance Lighthouse是我接触过的一线资产侦察工具里部署门槛最低、功能覆盖面最完整的一套开源系统。它解决的问题非常聚焦当你手上有一堆域名、一个IP段、或者一个企业名称时怎么快速把这些资产全部“翻”出来并且给每一类资产打好指纹、端口、服务、状态等标签。这套东西在安全测试前期的资产梳理阶段能省掉至少一个下午的人工翻找时间。ARL核心使用Python/Django开发后端任务队列走Celery数据落到MongoDB缓存用Redis整体通过Docker Compose编排。V2.6.2这个版本把不少旧版里“装完跑不起来”的毛病修掉了尤其是一键部署的体验做了很大的提升。我之前在V2.4版本上踩过不少环境坑而迁移到V2.6.2之后基本就是“拉镜像、起容器、配账号”三步收工。这套系统适合谁用我认为是三类人一是甲方安全团队用来做企业侧互联网暴露面盘点二是乙方测试人员项目授权后的前期信息收集环节三是对资产测绘、攻击面管理感兴趣的个人学习者。只要你需要回答“这个域名背后有多少子域名、多少端口、跑着什么服务、用的什么组件版本”这类问题ARL都属于值得优先尝试的方案。注意无论哪种角色使用时一定要记住一条底线只对你拥有管辖权限或者拿到书面授权的资产做测试。把资产侦察工具用在未经授权的目标上这不是技术问题是合规和法律责任问题。2. 部署前准备硬件、系统、Docker环境一次讲清2.1 主机配置参考ARL是“全自动跑任务”的架构扫描任务一旦开起来CPU、内存、磁盘的消耗会同时上来。我自己长期使用的配置是4核8G的云主机跑常规域名资产发现和端口扫描没问题。如果你的目标是比较大的IP段或者大量域名建议直接上8核16G。磁盘一定要给够ARL跑完的截图、HTML报告、扫描过程中的临时文件全部落在本地目录里一个中型项目的产出随随便便几百MB磁盘建议至少预留100GB。系统层面我用的是Ubuntu 20.04和22.04CentOS 7.9也验证过都能稳定跑。需要注意的是CentOS上默认的iptables规则和SELinux偶尔会干扰容器端口映射安装过程中如果访问页面不通优先排查这两个点。2.2 Docker与Compose安装ARL V2.6.2要求Docker引擎和Docker Compose插件都正常可用。旧版那种将docker-compose作为独立Python安装包的方式我建议彻底放弃直接使用Docker官方推荐的Compose V2方案。Ubuntu系统下安装命令如下# 移除可能存在的旧版本 sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG key和源 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装docker-ce和compose插件 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 验证 docker --version docker compose version做完上面的步骤你的机器上就有了docker compose注意中间有空格这个子命令。ARL部署文件里默认用的即是docker-compose up -d如果你的系统执行的是带横杠的旧版命令建议加一个软链接统一语法避免后面每次手滑sudo ln -s /usr/bin/docker-compose /usr/local/bin/docker-compose2.3 镜像拉取加速配置ARL部署需要拉取tophanttech/arl主镜像加上MongoDB、Redis等基础镜像总下载体积在1GB上下。如果你的服务器拉公共镜像仓库速度不理想强烈建议先配置Registry Mirror加速器否则很容易出现“拉镜像卡了半小时卡死”的尴尬局面。编辑Docker守护进程配置sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json EOF { registry-mirrors: [https://你常用云厂商提供的加速地址] } EOF sudo systemctl daemon-reload sudo systemctl restart docker加速地址填你使用云厂商控制台里显示的专属镜像加速域名即可。这一步看似不起眼实际上能救回大量时间。3. docker-compose一键部署完整实操3.1 目录规划与部署文件获取我习惯在根目录下建一个专门的部署目录把ARL相关的配置、数据、日志全部隔离起来后续备份和迁移非常方便mkdir -p /opt/arl cd /opt/arlARL V2.6.2的部署只需两份文件一份是docker-compose.yml负责编排容器一份是config-docker.yaml负责告诉ARL容器如何连接MongoDB和Redis以及控制扫描线程、并发数等参数。这两份文件从项目官方仓库的docker目录里获取。下载完成后先不要急着启动先看一眼内容确认里面声明的镜像版本和本地环境没有明显冲突。我这边调整后的compose编排结构大致如下version: 3 services: mongodb: image: mongo:4.0.28 container_name: arl_mongodb restart: always volumes: - ./mongo_data:/data/db networks: - arl_network redis: image: redis:5.0.14 container_name: arl_redis restart: always volumes: - ./redis_data:/data networks: - arl_network arl: image: tophanttech/arl:latest container_name: arl_master restart: always ports: - 5003:5003 volumes: - ./arl_data:/code/arl_data - ./config-docker.yaml:/code/app/config.yaml environment: - TZAsia/Shanghai depends_on: - mongodb - redis networks: - arl_network networks: arl_network: driver: bridge这段配置有几个点需要解释一下。第一数据目录都通过volume挂在宿主机上容器删了数据还在这是所有Docker应用的基本素养。第二ARL容器不仅映射了5003端口还通过depends_on保证MongoDB和Redis先启动。第三config-docker.yaml被挂载到容器内的/code/app/config.yaml这样后续调参数只需要改宿主机上的文件再重启ARL容器即可不用进容器里折腾。3.2 启动服务文件就位后一条命令拉起来docker compose up -d第一次执行会把所有镜像拉下来并创建容器耗时取决于网络状况通常在3到10分钟。启动完成后用docker compose ps看容器状态docker compose ps正常的输出应该是三个容器都是Up状态并且arl_master显示Up的时间持续增加而不是反复重启。如果某个容器卡在Restarting状态一定不要急着反复执行up -d先看日志docker compose logs --tail100 arl_master日志里最常见的问题是ARL容器连不上MongoDB或者Redis这种场景下需要确认config-docker.yaml中连接串里的主机名是否和compose里的service名一致。在同一个自定义桥接网络中容器之间直接用service名互访即可不要写localhost因为每个容器默认的网络命名空间是隔离的。3.3 初始化管理员账号并登录ARL V2.6.2首次启动后需要做一次管理员初始化。访问https://服务器IP:5003浏览器会提示证书不受信任这是正常现象。ARL默认用的是自签名证书选择继续访问即可。进入页面后系统会让你设置管理员邮箱和密码这一步就完成了账号初始化。曾经旧版默认账号是admin/arlpass网上很多教程还在这样写但V2.6.2版本已经改成首次访问自行设置了。初始化完成后使用设置好的管理员账号登录系统你会看到左侧完整的功能菜单任务管理、资产组、子域名、站点、端口、POC插件、首页监控、定时任务等。到这里部署工作就结束了整个流程如果顺利的话不会超过15分钟。4. 核心配置解析搞懂每一项再动手4.1 关键参数说明config-docker.yaml里有一些直接影响任务执行效率的参数。我摘出几个重点说明配置项作用我的建议celery_worker_concurrencyWorker并发进程数默认即可CPU核数不多的机器调大了反而容易OOMnmap_scan_concurrencyNmap并发扫描任务数建议5-10别一次拉满domain_asset_task_interval域名资产定时发现间隔按需调整短了会被封IPport_scan_interval端口扫描任务间隔按需调整expire_time站点指纹缓存过期时间默认很够用如果你的机器只有4G内存建议把并发参数整体压到默认的一半否则扫大目标时MongoDB吃内存涨得飞快轻则任务变慢重则整个Docker守护进程被系统OOM Killer杀掉。4.2 修改默认访问端口和时区有些场景下5003端口不方便直接暴露需要在docker-compose.yml里改映射关系。比如映射到8443ports: - 8443:5003时区在ARL容器里默认是UTC这会导致任务时间、日志时间比北京时间慢8小时。我建议在compose文件的环境变量中显式配置TZenvironment: - TZAsia/Shanghai修改完任何配置后执行docker compose up -d --force-recreate强制重建容器让配置生效。4.3 首次使用前的几个安全习惯部署完成后我强烈建议马上做三件事第一修改访问端的系统防火墙只放行你自己的办公网IP到5003端口的访问权限不要对全公网开放因为ARL的Web服务默认是HTTPS自签证书如果暴露公网很容易被各类扫描器盯上做口令爆破第二如果服务器上跑了其他应用注意Docker端口映射是否有冲突第三定期备份mongo_data和arl_data两个目录这两个目录里存的是任务结果和报告别的丢了可以再跑这俩丢了哭都来不及。5. 部署踩坑记录与排查技巧5.1 镜像拉取超时或失败这个问题几乎每个用户都会遇到。现象是执行docker compose up -d后卡在Pulling image半天不动最后报timeout。解决办法就是本文第2.3节说的配置加速器。另外docker pull时也单独验证一下基础镜像docker pull mongo:4.0.28 docker pull redis:5.0.14 docker pull tophanttech/arl:latest先把三个镜像都拉齐再执行compose启动成功率会高很多。5.2 ARL容器反复重启如果docker compose ps里ARL容器一直在Restarting大概率是配置文件内容没读对。常见情况是你网上下载的config-docker.yaml里MongoDB连接串写的IP是内网旧地址不是当前compose网络里的service名。打开配置文件检查以下两个关键连接配置mongo_server: mongodb mongo_port: 27017 redis_server: redis redis_port: 6379这里的主机名必须和compose里定义的service名保持一致。还有一种情况是宿主机的/code/arl_data目录权限不对导致ARL容器内写入失败日志会直接报PermissionError。解决办法chmod -R 755 /opt/arl/arl_data5.3 登录后初始化页面样式错乱这个问题的根源基本是浏览器缓存了旧版静态资源。在地址栏强制刷新一次CtrlShiftR基本能解。如果还不行在浏览器开发者工具里看一下有没有资源请求失败偶尔是自签证书导致的混合内容拦截把对应域名加入安全例外即可。5.4 常见错误速查表现象原因解决办法容器反复重启配置中MongoDB/Redis主机名写错改为compose中service名页面无法访问防火墙或安全组未放行5003检查云安全和本机iptables扫描任务卡在pendingWorker并发数设置过高或Celery断了重启ARL容器并调低并发子域名解析失败系统DNS配置异常在宿主机配置公共DNS后重建容器报告导出为空数据目录权限或磁盘满检查arl_data空间并修复权限6. 实操体验使用思路与效率技巧6.1 一次完整的资产侦察流程部署完成后我通常的流程是先建一个资产组把目标域名填入开启子域名收集任务。ARL会自动通过字典枚举、证书透明度日志、DNS解析等方式把相关子域名翻出来。这步跑完后系统会自动对发现的域名解析出IP随后可以一键下发端口扫描和网站指纹识别任务。任务跑完后在“站点”模块里能看到每个网站的指纹信息、标题、状态码和截图资产全貌一目了然。这个流程非常依赖任务之间的串联调度ARL做得好的地方是“任务链”概念一个任务完成后自动触发后续任务不需要人工手动挨个点。我第一次用的时候从填域名到拿到完整资产清单全程大概20分钟。6.2 资源占用与性能表现我长期跑ARL的这台临时4核8G机器同时开3个域名资产发现任务和5个端口扫描任务docker stats观察下来内存占用稳定在4GB左右CPU使用率在80%上下波动。如果你只有2G内存的机器建议只跑子域名收集和指纹识别端口扫描任务放到高配机器上执行否则OOM风险很高。6.3 给新手的几点建议第一别一上来就扫大IP段先拿一两个自己名下的域名练手把ARL的资产组、任务、报告模块跑明白再上量级。第二ARL的指纹库更新频率不算快扫描结果里的指纹命中率不可能100%它给你的是线索不是你做判断的全部依据。第三部署完一定记得把登录密码存在可靠的密码管理器里这个系统里存的资产信息本身就是敏感数据泄露了比丢失服务器还麻烦。我用ARL最大的体会是资产侦察的核心不是扫描器本身多厉害而是你能不能把资产梳理成可维护、可追踪、可回溯的结构化数据。ARL的价值恰恰在于它把“发现”和“管理”耦合在了一套系统里。部署门槛已经降得很低了剩下能拉开差距的是你怎么理解资产、怎么定义范围、怎么从结果里提炼出对业务有价值的信息。工具是杠杆思路才是支点。本文还有配套的精品资源点击获取