简介灯塔ARL资产侦察系统V2.6.2保姆级部署教程面向安全团队、渗透测试人员及安全研究员解决互联网资产快速发现与基础资产库构建问题。系统支持域名/IP资产发现、端口扫描、服务识别、资产分组管理、任务策略配置、周期任务调度以及站点变化监控、文件泄漏检测并可集成nuclei PoC与WebInfoHunter适合攻防演练、安全巡检等场景。资源为PDF文档共1个文件压缩包大小631KB内容涵盖Docker环境部署、镜像加速器配置针对Docker Hub受限提供可用方案、docker-compose安装、ARL项目下载、数据卷创建及镜像启动等完整步骤并配有命令示例和注意事项降低上手门槛。已有2744人学习/下载是安全从业者快速搭建资产侦察平台的精简参考。 这两年给团队搭资产盘点最深的感受是很多“资产”压根不在你的台账里。明明主域名都登记过可一个旧项目的子域名、一条被遗忘的DNS解析记录都可能让内部服务器意外暴露在公网上。后来我用ARL灯塔搭了一套资产侦察系统把域名和IP段喂进去定时跑任务新增子域、端口变化在首页就能看到。ARLAsset 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-composeARL也可以源码部署但源码部署要解决Python版本、系统依赖、MongoDB连接、任务Worker等一堆环境问题。新机器上手光排依赖就要花不少时间。docker-compose的好处是MongoDB、Web服务、任务Worker这三个角色都写在了compose文件里一条命令就能拉起来数据卷直接挂在宿主机上升级回滚不会动到底层数据。而且ARL本身只依赖MongoDB作为核心存储不需要像部署其他企业平台那样再单独准备Redis、PostgreSQL等组件。compose文件里数据库和服务端都已经编排好这对快速落地非常友好。你只需要保证宿主机有Docker和docker-compose剩下的就是拉代码、改配置、启动。2. 部署前的服务器和Docker环境2.1 硬件配置和系统选型先给一份我实际使用的参考配置如果你的任务量不大可以适当降低但不建议太低。项目最低配置推荐配置CPU2核4核内存4GB8GB磁盘20GB50GB以上建议SSD系统Ubuntu 18.04 / CentOS 7Ubuntu 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 composev2插件这没关系命令格式去掉横杠、加个空格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默认管理端口是5003HTTPS协议访问。如果这台服务器上5003已经被占用或者你不想用默认端口就在compose文件里改映射例如映射到8443ports: - 8443:50033.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 --tail200 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比如使用国内公共DNSdns: - 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环境稳定跑起来把第一个任务的结果看明白。本文还有配套的精品资源点击获取