尧图网页设计 
简介一份针对灯塔ARL资产侦察系统V2.6.2的保姆级部署教程面向需要快速搭建资产侦察平台的安全团队、渗透测试人员及安全研究员。该教程聚焦Docker环境下的docker-compose一键部署从环境准备、依赖安装到容器编排均有清晰指引可帮助读者绕过Docker Hub禁用后的镜像加速器配置难题顺利完成系统落地。教程明确了2核4G与Docker容器的前置要求并针对2024年7月后Docker Hub无法直接使用的现状专门给出镜像加速器配置方法。教程为PDF格式共1个文件压缩包大小631KB轻量易存。目前已有2747人学习下载内容经过实践验证适合作为资产侦察系统上手的配套参考。除基础部署外还覆盖了docker-compose两种安装方式、容器存储卷创建、服务状态检查等关键细节并结合ARL自身的资产发现、资产管理、监控检测与工具集成特性说明部署后如何用于域名资产整理、端口扫描、漏洞风险发现等场景兼具部署与使用指导价值。1. 灯塔ARL资产侦察系统一条 docker-compose 命令拉起的资产测绘黑匣子安全团队做外网资产盘点、SRC资产归属梳理、企业资产合规检查的时候灯塔ARLAsset Reconnaissance Lighthouse这套资产侦察系统几乎是绕不开的工具。它把子域名枚举、端口服务识别、Web指纹探测、漏洞扫描全编排进一个Web界面建一个侦察任务就能批量跑资产。很多人卡在安装这一步——源码部署要配MongoDB、Redis、任务队列环境依赖一多翻车率直线上升。V2.6.2版本把整套服务打进了docker-compose编排文件Docker环境正常、内存给够的情况下一条命令就能把系统拉起来。这篇笔记写给两类人第一次接触ARL、想用最小成本把它跑起来的新手以及部署过老版本、想清干净数据卷再做一次整洁部署的熟手。下文从部署前条件讲起一直到验证和备份。2. 部署前的硬性条件内存分配、端口清单与 docker-compose 版本选择先别急着克隆仓库。ARL虽然用docker-compose一键部署但它不是单容器应用编排文件里同时要拉起MongoDB、Redis和ARL主服务三个核心组件。我见过太多人在2G内存的云主机上硬上结果MongoDB和Redis把内存吃光ARL主服务起不来看日志全是OOM。所以部署前把底账算清楚后面能少踩一半坑。2.1 组件构成与端口占用底账这套编排的组件结构大致如下MongoDB负责存资产数据和任务状态Redis转发任务队列ARL主服务同时扮演后端接口和Web前端的角色对外暴露一个HTTPS端口供浏览器访问。部署后最常用的入口是https://服务器IP:5003首次访问会提示证书不信任因为ARL用的是自签名证书属于正常现象点继续就行。端口冲突是部署环节最常见的失败原因。默认情况下编排文件会把服务端口映射到宿主机下面这张表列了三个容易打架的端口容器服务默认映射端口冲突典型场景ARL Web5003HTTPS已有其他Web服务占用5003MongoDB27017宿主机装了MongoDB或用过同类数据库工具Redis6379宿主机已有Redis实例或中间件自带Redis如果机器上已经跑了这三个端口里的任何一个不用先杀服务直接在编排文件里把映射改成不冲突的端口就行。我的习惯是MongoDB和Redis的端口映射只在调试时开生产环境改成只绑定127.0.0.1或者干脆只保留ARL Web的ports段数据库通过容器网络内部访问不暴露到宿主机。这样端口占用问题直接消掉一大半也顺手降低了数据库被外部直接连接的风险。2.2 docker engine 与 docker-compose 的版本匹配先检查机器上的Docker环境docker version --format {{.Server.Version}} docker compose version docker-compose version第一行看Docker引擎版本第二行看新版compose插件第三行看旧版独立二进制。我建议把Docker Engine升到20.10以上这套编排创建的容器网络和新版compose命令配合得更好。docker-compose现在有两种形态旧版的独立二进制docker-compose命令Python实现和新版的Docker官方插件docker compose命令Go实现。两者都能读docker-compose.yml但旧版在某些系统上有兼容性问题最常见的就是docker-compose up时直接报libz.so.1加载失败这个坑在避坑章节会专门展开。部署ARL建议优先用新版插件如果机器上已经装了旧版至少确认它能正常执行docker-compose help再往下走。内存方面ARL官方建议4G以上我心里给的最低线是4G8G最稳。MongoDB和Redis都是内存大户ARL主服务还要跑扫描子进程。有个细节如果云主机只有2G硬把compose拉起来大概率出现容器启动后一直重启日志里全是Out of memory。这时候与其调各种参数不如先把内存升上去这是性价比最高的解决方式。磁盘也不要太紧张——ARL跑一批任务后资产快照、漏洞报告、日志全写进数据卷几百个域名跑一轮下来几个G很正常。部署前确认挂载目录所在分区剩余空间在20G以上不然跑着跑着磁盘满了MongoDB会直接拒绝写入表现就是任务结果保存失败查日志才能看到磁盘配额错误。3. docker-compose 一键部署克隆、改编排、起服务的完整过程环境准备好之后部署本身其实就三条命令的事克隆仓库、改编排文件、up -d。但有一个新手容易踩的坑——官方仓库里的docker-compose.yml是通用配置直接拿起来跑端口、数据卷、镜像tag不一定适合你的机器。所以我把每一步拆开讲每一步都说明为什么要这么做。3.1 克隆仓库与编排文件调整先把项目仓库克隆到本地git clone https://github.com/TophantTechnology/ARL.git cd ARL ls -la克隆之后会看到docker-compose.yml和config目录。我一般先不急着跑花两分钟读一遍编排文件确认镜像tag、端口映射、数据卷挂载三个地方这三个地方也是后续出问题最多的地方。这个编排文件的核心结构大致是下面这样细节以你拉到的仓库实际内容为准services: mongo: image: mongo:4.0 container_name: arl_mongo restart: always volumes: - mongo_data:/data/db # 如果想避免端口冲突注释掉下面这行 # ports: # - 27017:27017 redis: image: redis:5.0 container_name: arl_redis restart: always # ports: # - 6379:6379 web: image: tophant/arl:2.6.2 container_name: arl_web restart: always depends_on: - mongo - redis ports: - 5003:5003 volumes: - arl_data:/opt/ARL volumes: mongo_data: arl_data:这个文件的几个注意点镜像tag不要用latest锁定到具体的版本号如2.6.2这样以后重建环境不会因为镜像更新导致行为不一致。depends_on只保证容器启动顺序不代表MongoDB内部初始化完成所以web容器第一次启动后可能会连不上数据库过一会儿重启web容器就好这是正常的。volumes段极其重要mongo_data和arl_data两个命名卷分别兜住数据库文件和ARL工作目录没有这块docker-compose down会把容器连同数据一起删干净后面避坑章节会展开讲。改端口时要看清楚改的是ports段左边宿主机端口右边容器内部端口不要动。比如把5003:5003改成8443:5003访问入口就变成https://IP:8443容器内部ARL还是走5003不用动任何配置。3.2 拉镜像、起服务与观察日志编排文件调整好之后正式启动docker compose pull docker compose up -d docker compose pspull先把三个镜像拉到本地也可以跳过直接 up -d但单独pull能提前暴露网络问题——镜像拉取超时、权限错误这类问题在pull阶段就能看到不用等compose试图创建容器时再翻车。up -d是后台模式启动ps查看容器状态。刚执行完up -d不要急着访问MongoDB初始化需要十几秒到半分钟尤其是首次创建数据卷的时候。这时候看日志比刷新页面更有用docker compose logs -f web日志里出现类似listening on port 5003或者Flask启动的提示后再开浏览器访问https://IP:5003。首次访问证书告警直接点继续就好。如果等了半分钟web日志还没动静大概率是mongo还没ready执行docker compose logs mongo docker compose restart web这一套是标准的启动顺序修正不是故障。ARL的编排就是web容器通常比数据库先启动靠restart: always机制自愈。如果重启两三次web容器仍然起不来就要往内存和端口两个方向查了对应避坑章节的5.2和5.3。登录界面出来后用默认账号admin/arlpass进系统。这里先别急着建任务下一章讲登录后的三个必做操作。4. 登录后的三件事改默认口令、调任务参数、建第一个侦察任务服务起来了只是开始。ARL的默认口令是公开写进文档的不马上改等于把自己的资产测绘平台敞开在公网上。登录之后我建议按下面这个顺序操作改口令确认任务策略参数再建第一个小范围的目标任务验证全链路。4.1 改默认口令与全局配置项系统设置里改admin密码改完立即用新密码重新登录一次确认写入数据库成功。这一步看起来多余但我真遇到过改完密码没退出过了两周发现密码没保存的情况——界面有反馈但没验证等于没改。除了密码config目录下的配置也要过一眼。ARL的主配置里和日常使用最相关的是这几项任务并发数、单目标扫描超时、日志保留级别。并发数默认值保守4G内存机器不调问题不大但如果目标列表很长可以适度往上调前提是观察CPU和内存余量。还有一个容易忽视的配置测试模式还是生产模式。如果是测试模式某些外部API的调用会被mock掉跑出来的资产数据不完整。配置文件的修改规则是改完重启web容器生效。命令docker compose restart web重启后登录态会失效重新登录就行。不要手动去动MongoDB里的记录ARL的配置和任务数据都有关联关系直接改库容易把任务状态搞成不一致到时候排错比改配置还花时间。4.2 创建第一个侦察任务策略、目标、验证闭环登录后的系统首页是任务列表右上角新建任务的表单主要填三块目标、策略、执行周期。目标格式支持域名、IP、URL每一行一个目标。第一个任务不要贪多挑一个自己公司的小域名或者测试域名甚至填一个IP段里的少量IP目标是验证全链路通不通不是跑一批结果出来。周期任务建议先关掉第一次用单次任务跑通了再改成周期执行。策略这里要细说。ARL的任务策略是多个检查项的开关组合常见的几个选项策略项作用建议端口扫描识别目标开放端口与服务版本首个任务勾选否则Web资产发现不了服务识别对端口对应的服务做指纹识别默认开启站点探测扫描HTTP服务并抓取页面状态开启Web资产没它不行指纹识别匹配Web框架与组件指纹开启这是资产归类的主要依据漏洞扫描基于POC模板做漏洞检测首次验证建议关掉范围确认后再开看到端口扫描这里可能有个疑问目标填域名端口扫描是怎么进行的ARL内部先做DNS解析把域名解析成IP再对IP做端口级探测。所以整个过程的耗时主要取决于目标和策略项数量一个小域名加默认策略正常半小时以内能出结果。任务提交后回到列表状态从等待变成正在执行最后变成已完成。还可以用docker compose logs --tail50 web看当前任务在执行哪个环节能直观看到端口扫描阶段和指纹识别阶段的输出。任务跑完后去资产列表看结果。ARL把结果分成IP资产、域名资产、站点资产几个维度站点资产里能看到指纹识别出来的中间件和框架。这里有个使用习惯每次任务跑完先别急着导出CSV先在界面里检查指纹结果是否合理——指纹识别是规则匹配规则库有覆盖不到的地方识别结果为空的站点很可能就是自研系统或小众框架后面可以手工补充指纹。4.3 外部测绘API的作用边界如果账户里开通了FOFA、Quake这类测绘平台的API可以在系统设置里把API key填进去。填完之后ARL会把外部测绘数据引入任务结果和本地主动扫描合并展示。要注意的是外部API主要补充的是历史测绘数据比如目标资产历史上开放过但现在已经关闭的端口本地扫描负责当前实时状态。首次使用不建议一上来就配API先用纯本地扫描把全链路摸熟再叠加外部数据源否则任务结果里混了两套数据新手分不清哪些是实时探测的哪些是历史归档。5. 部署避坑容器重启、502、任务卡 pending 的五个真实场景写这章之前我把自己和同事在ARL上碰到的问题梳理了一遍挑出最有代表性的五个按现象、原因、解决三步记在这里。每个坑都附了排查命令按顺序执行就能定位。5.1 docker-compose 命令直接报 libz.so.1 错误现象执行docker-compose up -d时终端报error while loading shared libraries: libz.so.1: failed to map segment from shared object命令完全跑不起来。原因旧版docker-compose是32位Python二进制在某些64位最小化系统上缺32位的libz动态库属于环境兼容问题和ARL本身无关。解决两条路任选。一是改用新版docker compose插件命令变成docker compose up -d不依赖libz二是在系统里补32位库Debian/Ubuntu执行apt install lib32z1。我推荐走第一条新版插件同样读docker-compose.yml没必要在一个即将废弃的二进制上纠缠。5.2 容器一直 Restarting日志全是 OOM现象docker compose ps看到web或mongo容器处于Restarting状态docker compose logs里能看到Out of memory关键字。原因最常见的是主机内存不够。MongoDB、Redis、ARL三个容器同时跑2G内存的小机器很容易触发内核OOM。解决先docker compose down停掉整套服务给机器加内存或交换分区再up -d。临时应急可以用swap但长时间跑ARL不推荐裸swapIO磨损和延迟都吃亏。确认是否被OOM杀过一条命令docker inspect --format {{.State.OOMKilled}} arl_web返回true就是被OOM杀过把内存加到位再重启不用去调compose里的参数那些都是治标不治本。5.3 浏览器访问 5003 出现 502现象页面提示502 Bad Gateway但docker compose ps看容器都是up状态。原因ARL的Web入口是Nginx反代到后端Flask服务502通常是后端进程还没ready或者内部崩溃Nginx拿不到上游响应。容器状态是up只代表进程在不代表服务通了。解决看日志定位docker compose logs --tail100 web如果日志里明确报连不上MongoDB按3.2节的做法重启web容器。如果日志一直在报任务队列连接异常检查Redis容器是否存活docker compose logs redis看一下有无报错。502这个症状九成出在依赖服务没就绪按mongo、redis、web的顺序排查基本一轮就能定位。5.4 重启后任务和资产数据全部消失现象docker compose down之后执行up -d登录进去发现任务列表是空的之前跑的资产数据全没了。原因编排文件里没有配置volumes或者volumes写的是容器内部路径但没挂载到宿主机或命名卷。ARL的所有持久化数据都存在容器内部文件系统容器被删重建时数据跟着一起消失。解决这是我在生产环境吃过的一次大亏。检查当前编排文件里有没有volumes段没有就补上参照3.1节mongo_data和arl_data的写法然后执行docker compose down docker compose up -d注意这一步是亡羊补牢已经丢的数据找不回来只能从之前的备份恢复。部署完ARL先做一次备份验证恢复流程确认数据卷真的在再往里跑任务。5.5 任务一直 pending不进入执行现象提交任务后状态一直停在待执行不管等十分钟还是半小时都没有变化。原因任务队列没有消费者。ARL的任务队列走Redisweb容器既是web服务也是worker如果Redis没通或者worker进程没起来任务就会一直堆在队列里。解决先看Redis容器状态和web容器日志docker compose logs redis docker compose logs web | grep -i celery日志里如果能看到worker启动信息那就是Redis连接问题如果完全没有worker相关的日志重启web容器让worker重新注册docker compose restart web还有一个少见但也碰过的情况任务目标格式写错比如填了带http://前缀的域名ARL解析不了任务提交后一直不进入队列。提交前确认目标行里只留域名、IP或URL不要混入多余字符。6. 部署后的自检与备份一份清单和一份后悔药服务跑起来、第一个任务也出了结果之后我建议在正式使用前花五分钟做一次自检再花十分钟把备份流程建立起来。自检是确认整套链路没有隐藏问题备份是给自己留后悔药——ARL的数据丢了才叫真难受。6.1 一套完整的自检清单按下面这个顺序过一遍任何一步异常都回看对应章节检查项操作预期Web登录浏览器访问HTTPS端口能出登录页并登录成功改密生效新密码退出重新登录能正常进入系统依赖连通docker compose logs web里无mongo/redis报错日志干净任务闭环建一个小范围任务跑完状态变为已完成且资产列表有数据数据持久化docker compose down up -d后登录任务还在自检环节里唯一一个有破坏性的动作是down再up但这步建议必须做。很多部署看起来正常其实数据全靠容器内部文件系统撑着一旦机器重启、Docker服务重启数据就没了。Down一次再up如果数据还在说明数据卷配置真的生效了。6.2 备份与恢复两条命令和一个习惯备份的本质是把数据卷内容打包带走。命名卷的实际位置可以用docker inspect查但更通用的做法是直接打tar包docker run --rm -v arl_data:/data -v $(pwd):/backup alpine tar czf /backup/arl_data_$(date %F).tar.gz -C /data . docker run --rm -v mongo_data:/data -v $(pwd):/backup alpine tar czf /backup/mongo_data_$(date %F).tar.gz -C /data .这两条命令分别把ARL工作目录和MongoDB数据目录打包到当前目录。恢复同样简单把tar包解压到临时目录再用volume挂载回容器即可。备份频率我建议至少一周一次跑重要批量任务前也手动做一次。一个简易的crontab就能解决每周一凌晨打包保留最近四周的备份0 3 * * 1 cd /opt/arl_backup docker run --rm -v arl_data:/data -v $(pwd):/backup alpine tar czf arl_data_$(date \%F).tar.gz -C /data . find . -name *.tar.gz -mtime 28 -delete这行脚本不复杂但能保证最坏情况下只丢一周数据。我从那次删掉数据卷之后每次部署完都会先跑一遍自检确认数据卷真的挂上了再在crontab里把备份挂上从那以后ARL再没出过需要找后悔药的事。希望帮到你。本文还有配套的精品资源点击获取 灯塔ARL资产测绘系统Docker Compose一键部署与避坑指南
简介一份针对灯塔ARL资产侦察系统V2.6.2的保姆级部署教程面向需要快速搭建资产侦察平台的安全团队、渗透测试人员及安全研究员。该教程聚焦Docker环境下的docker-compose一键部署从环境准备、依赖安装到容器编排均有清晰指引可帮助读者绕过Docker Hub禁用后的镜像加速器配置难题顺利完成系统落地。教程明确了2核4G与Docker容器的前置要求并针对2024年7月后Docker Hub无法直接使用的现状专门给出镜像加速器配置方法。教程为PDF格式共1个文件压缩包大小631KB轻量易存。目前已有2747人学习下载内容经过实践验证适合作为资产侦察系统上手的配套参考。除基础部署外还覆盖了docker-compose两种安装方式、容器存储卷创建、服务状态检查等关键细节并结合ARL自身的资产发现、资产管理、监控检测与工具集成特性说明部署后如何用于域名资产整理、端口扫描、漏洞风险发现等场景兼具部署与使用指导价值。1. 灯塔ARL资产侦察系统一条 docker-compose 命令拉起的资产测绘黑匣子安全团队做外网资产盘点、SRC资产归属梳理、企业资产合规检查的时候灯塔ARLAsset Reconnaissance Lighthouse这套资产侦察系统几乎是绕不开的工具。它把子域名枚举、端口服务识别、Web指纹探测、漏洞扫描全编排进一个Web界面建一个侦察任务就能批量跑资产。很多人卡在安装这一步——源码部署要配MongoDB、Redis、任务队列环境依赖一多翻车率直线上升。V2.6.2版本把整套服务打进了docker-compose编排文件Docker环境正常、内存给够的情况下一条命令就能把系统拉起来。这篇笔记写给两类人第一次接触ARL、想用最小成本把它跑起来的新手以及部署过老版本、想清干净数据卷再做一次整洁部署的熟手。下文从部署前条件讲起一直到验证和备份。2. 部署前的硬性条件内存分配、端口清单与 docker-compose 版本选择先别急着克隆仓库。ARL虽然用docker-compose一键部署但它不是单容器应用编排文件里同时要拉起MongoDB、Redis和ARL主服务三个核心组件。我见过太多人在2G内存的云主机上硬上结果MongoDB和Redis把内存吃光ARL主服务起不来看日志全是OOM。所以部署前把底账算清楚后面能少踩一半坑。2.1 组件构成与端口占用底账这套编排的组件结构大致如下MongoDB负责存资产数据和任务状态Redis转发任务队列ARL主服务同时扮演后端接口和Web前端的角色对外暴露一个HTTPS端口供浏览器访问。部署后最常用的入口是https://服务器IP:5003首次访问会提示证书不信任因为ARL用的是自签名证书属于正常现象点继续就行。端口冲突是部署环节最常见的失败原因。默认情况下编排文件会把服务端口映射到宿主机下面这张表列了三个容易打架的端口容器服务默认映射端口冲突典型场景ARL Web5003HTTPS已有其他Web服务占用5003MongoDB27017宿主机装了MongoDB或用过同类数据库工具Redis6379宿主机已有Redis实例或中间件自带Redis如果机器上已经跑了这三个端口里的任何一个不用先杀服务直接在编排文件里把映射改成不冲突的端口就行。我的习惯是MongoDB和Redis的端口映射只在调试时开生产环境改成只绑定127.0.0.1或者干脆只保留ARL Web的ports段数据库通过容器网络内部访问不暴露到宿主机。这样端口占用问题直接消掉一大半也顺手降低了数据库被外部直接连接的风险。2.2 docker engine 与 docker-compose 的版本匹配先检查机器上的Docker环境docker version --format {{.Server.Version}} docker compose version docker-compose version第一行看Docker引擎版本第二行看新版compose插件第三行看旧版独立二进制。我建议把Docker Engine升到20.10以上这套编排创建的容器网络和新版compose命令配合得更好。docker-compose现在有两种形态旧版的独立二进制docker-compose命令Python实现和新版的Docker官方插件docker compose命令Go实现。两者都能读docker-compose.yml但旧版在某些系统上有兼容性问题最常见的就是docker-compose up时直接报libz.so.1加载失败这个坑在避坑章节会专门展开。部署ARL建议优先用新版插件如果机器上已经装了旧版至少确认它能正常执行docker-compose help再往下走。内存方面ARL官方建议4G以上我心里给的最低线是4G8G最稳。MongoDB和Redis都是内存大户ARL主服务还要跑扫描子进程。有个细节如果云主机只有2G硬把compose拉起来大概率出现容器启动后一直重启日志里全是Out of memory。这时候与其调各种参数不如先把内存升上去这是性价比最高的解决方式。磁盘也不要太紧张——ARL跑一批任务后资产快照、漏洞报告、日志全写进数据卷几百个域名跑一轮下来几个G很正常。部署前确认挂载目录所在分区剩余空间在20G以上不然跑着跑着磁盘满了MongoDB会直接拒绝写入表现就是任务结果保存失败查日志才能看到磁盘配额错误。3. docker-compose 一键部署克隆、改编排、起服务的完整过程环境准备好之后部署本身其实就三条命令的事克隆仓库、改编排文件、up -d。但有一个新手容易踩的坑——官方仓库里的docker-compose.yml是通用配置直接拿起来跑端口、数据卷、镜像tag不一定适合你的机器。所以我把每一步拆开讲每一步都说明为什么要这么做。3.1 克隆仓库与编排文件调整先把项目仓库克隆到本地git clone https://github.com/TophantTechnology/ARL.git cd ARL ls -la克隆之后会看到docker-compose.yml和config目录。我一般先不急着跑花两分钟读一遍编排文件确认镜像tag、端口映射、数据卷挂载三个地方这三个地方也是后续出问题最多的地方。这个编排文件的核心结构大致是下面这样细节以你拉到的仓库实际内容为准services: mongo: image: mongo:4.0 container_name: arl_mongo restart: always volumes: - mongo_data:/data/db # 如果想避免端口冲突注释掉下面这行 # ports: # - 27017:27017 redis: image: redis:5.0 container_name: arl_redis restart: always # ports: # - 6379:6379 web: image: tophant/arl:2.6.2 container_name: arl_web restart: always depends_on: - mongo - redis ports: - 5003:5003 volumes: - arl_data:/opt/ARL volumes: mongo_data: arl_data:这个文件的几个注意点镜像tag不要用latest锁定到具体的版本号如2.6.2这样以后重建环境不会因为镜像更新导致行为不一致。depends_on只保证容器启动顺序不代表MongoDB内部初始化完成所以web容器第一次启动后可能会连不上数据库过一会儿重启web容器就好这是正常的。volumes段极其重要mongo_data和arl_data两个命名卷分别兜住数据库文件和ARL工作目录没有这块docker-compose down会把容器连同数据一起删干净后面避坑章节会展开讲。改端口时要看清楚改的是ports段左边宿主机端口右边容器内部端口不要动。比如把5003:5003改成8443:5003访问入口就变成https://IP:8443容器内部ARL还是走5003不用动任何配置。3.2 拉镜像、起服务与观察日志编排文件调整好之后正式启动docker compose pull docker compose up -d docker compose pspull先把三个镜像拉到本地也可以跳过直接 up -d但单独pull能提前暴露网络问题——镜像拉取超时、权限错误这类问题在pull阶段就能看到不用等compose试图创建容器时再翻车。up -d是后台模式启动ps查看容器状态。刚执行完up -d不要急着访问MongoDB初始化需要十几秒到半分钟尤其是首次创建数据卷的时候。这时候看日志比刷新页面更有用docker compose logs -f web日志里出现类似listening on port 5003或者Flask启动的提示后再开浏览器访问https://IP:5003。首次访问证书告警直接点继续就好。如果等了半分钟web日志还没动静大概率是mongo还没ready执行docker compose logs mongo docker compose restart web这一套是标准的启动顺序修正不是故障。ARL的编排就是web容器通常比数据库先启动靠restart: always机制自愈。如果重启两三次web容器仍然起不来就要往内存和端口两个方向查了对应避坑章节的5.2和5.3。登录界面出来后用默认账号admin/arlpass进系统。这里先别急着建任务下一章讲登录后的三个必做操作。4. 登录后的三件事改默认口令、调任务参数、建第一个侦察任务服务起来了只是开始。ARL的默认口令是公开写进文档的不马上改等于把自己的资产测绘平台敞开在公网上。登录之后我建议按下面这个顺序操作改口令确认任务策略参数再建第一个小范围的目标任务验证全链路。4.1 改默认口令与全局配置项系统设置里改admin密码改完立即用新密码重新登录一次确认写入数据库成功。这一步看起来多余但我真遇到过改完密码没退出过了两周发现密码没保存的情况——界面有反馈但没验证等于没改。除了密码config目录下的配置也要过一眼。ARL的主配置里和日常使用最相关的是这几项任务并发数、单目标扫描超时、日志保留级别。并发数默认值保守4G内存机器不调问题不大但如果目标列表很长可以适度往上调前提是观察CPU和内存余量。还有一个容易忽视的配置测试模式还是生产模式。如果是测试模式某些外部API的调用会被mock掉跑出来的资产数据不完整。配置文件的修改规则是改完重启web容器生效。命令docker compose restart web重启后登录态会失效重新登录就行。不要手动去动MongoDB里的记录ARL的配置和任务数据都有关联关系直接改库容易把任务状态搞成不一致到时候排错比改配置还花时间。4.2 创建第一个侦察任务策略、目标、验证闭环登录后的系统首页是任务列表右上角新建任务的表单主要填三块目标、策略、执行周期。目标格式支持域名、IP、URL每一行一个目标。第一个任务不要贪多挑一个自己公司的小域名或者测试域名甚至填一个IP段里的少量IP目标是验证全链路通不通不是跑一批结果出来。周期任务建议先关掉第一次用单次任务跑通了再改成周期执行。策略这里要细说。ARL的任务策略是多个检查项的开关组合常见的几个选项策略项作用建议端口扫描识别目标开放端口与服务版本首个任务勾选否则Web资产发现不了服务识别对端口对应的服务做指纹识别默认开启站点探测扫描HTTP服务并抓取页面状态开启Web资产没它不行指纹识别匹配Web框架与组件指纹开启这是资产归类的主要依据漏洞扫描基于POC模板做漏洞检测首次验证建议关掉范围确认后再开看到端口扫描这里可能有个疑问目标填域名端口扫描是怎么进行的ARL内部先做DNS解析把域名解析成IP再对IP做端口级探测。所以整个过程的耗时主要取决于目标和策略项数量一个小域名加默认策略正常半小时以内能出结果。任务提交后回到列表状态从等待变成正在执行最后变成已完成。还可以用docker compose logs --tail50 web看当前任务在执行哪个环节能直观看到端口扫描阶段和指纹识别阶段的输出。任务跑完后去资产列表看结果。ARL把结果分成IP资产、域名资产、站点资产几个维度站点资产里能看到指纹识别出来的中间件和框架。这里有个使用习惯每次任务跑完先别急着导出CSV先在界面里检查指纹结果是否合理——指纹识别是规则匹配规则库有覆盖不到的地方识别结果为空的站点很可能就是自研系统或小众框架后面可以手工补充指纹。4.3 外部测绘API的作用边界如果账户里开通了FOFA、Quake这类测绘平台的API可以在系统设置里把API key填进去。填完之后ARL会把外部测绘数据引入任务结果和本地主动扫描合并展示。要注意的是外部API主要补充的是历史测绘数据比如目标资产历史上开放过但现在已经关闭的端口本地扫描负责当前实时状态。首次使用不建议一上来就配API先用纯本地扫描把全链路摸熟再叠加外部数据源否则任务结果里混了两套数据新手分不清哪些是实时探测的哪些是历史归档。5. 部署避坑容器重启、502、任务卡 pending 的五个真实场景写这章之前我把自己和同事在ARL上碰到的问题梳理了一遍挑出最有代表性的五个按现象、原因、解决三步记在这里。每个坑都附了排查命令按顺序执行就能定位。5.1 docker-compose 命令直接报 libz.so.1 错误现象执行docker-compose up -d时终端报error while loading shared libraries: libz.so.1: failed to map segment from shared object命令完全跑不起来。原因旧版docker-compose是32位Python二进制在某些64位最小化系统上缺32位的libz动态库属于环境兼容问题和ARL本身无关。解决两条路任选。一是改用新版docker compose插件命令变成docker compose up -d不依赖libz二是在系统里补32位库Debian/Ubuntu执行apt install lib32z1。我推荐走第一条新版插件同样读docker-compose.yml没必要在一个即将废弃的二进制上纠缠。5.2 容器一直 Restarting日志全是 OOM现象docker compose ps看到web或mongo容器处于Restarting状态docker compose logs里能看到Out of memory关键字。原因最常见的是主机内存不够。MongoDB、Redis、ARL三个容器同时跑2G内存的小机器很容易触发内核OOM。解决先docker compose down停掉整套服务给机器加内存或交换分区再up -d。临时应急可以用swap但长时间跑ARL不推荐裸swapIO磨损和延迟都吃亏。确认是否被OOM杀过一条命令docker inspect --format {{.State.OOMKilled}} arl_web返回true就是被OOM杀过把内存加到位再重启不用去调compose里的参数那些都是治标不治本。5.3 浏览器访问 5003 出现 502现象页面提示502 Bad Gateway但docker compose ps看容器都是up状态。原因ARL的Web入口是Nginx反代到后端Flask服务502通常是后端进程还没ready或者内部崩溃Nginx拿不到上游响应。容器状态是up只代表进程在不代表服务通了。解决看日志定位docker compose logs --tail100 web如果日志里明确报连不上MongoDB按3.2节的做法重启web容器。如果日志一直在报任务队列连接异常检查Redis容器是否存活docker compose logs redis看一下有无报错。502这个症状九成出在依赖服务没就绪按mongo、redis、web的顺序排查基本一轮就能定位。5.4 重启后任务和资产数据全部消失现象docker compose down之后执行up -d登录进去发现任务列表是空的之前跑的资产数据全没了。原因编排文件里没有配置volumes或者volumes写的是容器内部路径但没挂载到宿主机或命名卷。ARL的所有持久化数据都存在容器内部文件系统容器被删重建时数据跟着一起消失。解决这是我在生产环境吃过的一次大亏。检查当前编排文件里有没有volumes段没有就补上参照3.1节mongo_data和arl_data的写法然后执行docker compose down docker compose up -d注意这一步是亡羊补牢已经丢的数据找不回来只能从之前的备份恢复。部署完ARL先做一次备份验证恢复流程确认数据卷真的在再往里跑任务。5.5 任务一直 pending不进入执行现象提交任务后状态一直停在待执行不管等十分钟还是半小时都没有变化。原因任务队列没有消费者。ARL的任务队列走Redisweb容器既是web服务也是worker如果Redis没通或者worker进程没起来任务就会一直堆在队列里。解决先看Redis容器状态和web容器日志docker compose logs redis docker compose logs web | grep -i celery日志里如果能看到worker启动信息那就是Redis连接问题如果完全没有worker相关的日志重启web容器让worker重新注册docker compose restart web还有一个少见但也碰过的情况任务目标格式写错比如填了带http://前缀的域名ARL解析不了任务提交后一直不进入队列。提交前确认目标行里只留域名、IP或URL不要混入多余字符。6. 部署后的自检与备份一份清单和一份后悔药服务跑起来、第一个任务也出了结果之后我建议在正式使用前花五分钟做一次自检再花十分钟把备份流程建立起来。自检是确认整套链路没有隐藏问题备份是给自己留后悔药——ARL的数据丢了才叫真难受。6.1 一套完整的自检清单按下面这个顺序过一遍任何一步异常都回看对应章节检查项操作预期Web登录浏览器访问HTTPS端口能出登录页并登录成功改密生效新密码退出重新登录能正常进入系统依赖连通docker compose logs web里无mongo/redis报错日志干净任务闭环建一个小范围任务跑完状态变为已完成且资产列表有数据数据持久化docker compose down up -d后登录任务还在自检环节里唯一一个有破坏性的动作是down再up但这步建议必须做。很多部署看起来正常其实数据全靠容器内部文件系统撑着一旦机器重启、Docker服务重启数据就没了。Down一次再up如果数据还在说明数据卷配置真的生效了。6.2 备份与恢复两条命令和一个习惯备份的本质是把数据卷内容打包带走。命名卷的实际位置可以用docker inspect查但更通用的做法是直接打tar包docker run --rm -v arl_data:/data -v $(pwd):/backup alpine tar czf /backup/arl_data_$(date %F).tar.gz -C /data . docker run --rm -v mongo_data:/data -v $(pwd):/backup alpine tar czf /backup/mongo_data_$(date %F).tar.gz -C /data .这两条命令分别把ARL工作目录和MongoDB数据目录打包到当前目录。恢复同样简单把tar包解压到临时目录再用volume挂载回容器即可。备份频率我建议至少一周一次跑重要批量任务前也手动做一次。一个简易的crontab就能解决每周一凌晨打包保留最近四周的备份0 3 * * 1 cd /opt/arl_backup docker run --rm -v arl_data:/data -v $(pwd):/backup alpine tar czf arl_data_$(date \%F).tar.gz -C /data . find . -name *.tar.gz -mtime 28 -delete这行脚本不复杂但能保证最坏情况下只丢一周数据。我从那次删掉数据卷之后每次部署完都会先跑一遍自检确认数据卷真的挂上了再在crontab里把备份挂上从那以后ARL再没出过需要找后悔药的事。希望帮到你。本文还有配套的精品资源点击获取