企业官网建设流程全解析

简介：灯塔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是什么，适合什么场景

灯塔ARL（Asset 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.04，CentOS 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-compose

2.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/arl

ARL 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: - TZ=Asia/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 --tail=100 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里有一些直接影响任务执行效率的参数。我摘出几个重点说明：

如果你的机器只有4G内存，建议把并发参数整体压到默认的一半，否则扫大目标时MongoDB吃内存涨得飞快，轻则任务变慢，重则整个Docker守护进程被系统OOM Killer杀掉。

4.2 修改默认访问端口和时区

有些场景下5003端口不方便直接暴露，需要在docker-compose.yml里改映射关系。比如映射到8443：

ports: - "8443:5003"

时区在ARL容器里默认是UTC，这会导致任务时间、日志时间比北京时间慢8小时。我建议在compose文件的环境变量中显式配置TZ：

environment: - TZ=Asia/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_data

5.3 登录后初始化页面样式错乱

这个问题的根源基本是浏览器缓存了旧版静态资源。在地址栏强制刷新一次（Ctrl+Shift+R）基本能解。如果还不行，在浏览器开发者工具里看一下有没有资源请求失败，偶尔是自签证书导致的混合内容拦截，把对应域名加入安全例外即可。

5.4 常见错误速查表

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的价值恰恰在于它把“发现”和“管理”耦合在了一套系统里。部署门槛已经降得很低了，剩下能拉开差距的，是你怎么理解资产、怎么定义范围、怎么从结果里提炼出对业务有价值的信息。工具是杠杆，思路才是支点。

本文还有配套的精品资源，点击获取