ARL食用指南

一、部署前环境准备

1. 核心依赖：Docker + Docker Compose（插件版）

Kali 2025 默认预装 Docker，但需确认 Docker Compose 插件版 可用（避免独立包冲突）：

# 验证 Docker 是否运行
sudo systemctl status docker
# 验证 Docker Compose 插件版（无横杠，官方推荐）
docker compose version

问题1：Docker Compose 安装冲突（独立包 vs 插件版）

• 现象：执行 sudo apt install docker-compose 时提示“trying to overwrite…”
• 解决：使用系统预装的插件版，无需安装独立包；若已安装独立包，先卸载冲突组件：

  # 卸载冲突的独立包
  sudo apt remove -y docker-compose
  # 确保插件版可用
  sudo apt install -y docker-compose-plugin

二、配置 Docker 国内加速器（解决镜像拉取慢/中断）

Docker 默认拉取国外镜像源，必须配置国内加速器（你遇到过格式错误、源不稳定问题）。

1. 编辑 Docker 配置文件

# 打开配置文件（若不存在则自动创建）
sudo vim /etc/docker/daemon.json

2. 写入正确格式的加速源（避免逗号缺失）

正确配置（含国内稳定源）：

{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://docker.1panel.live",
    "https://hub.rat.dev",
    "https://docker.xuanyuan.me",
    "https://registry.cn-hangzhou.aliyuncs.com"  // 阿里云公共源（最稳定）
  ]
}

3. 使加速配置生效

# 重新加载配置
sudo systemctl daemon-reload
# 重启 Docker 服务
sudo systemctl restart docker
# 验证加速源是否生效
docker info | grep "Registry Mirrors" -A 5

• 生效标志：输出中显示配置的所有加速源。

三、克隆 ARL 代码

使用加速链接克隆 ARL 代码（你之前用的 gh.llkk.cc 加速）：

# 进入工具目录（自定义路径，示例为 ~/Web/web-tools）
cd ~/Web/web-tools
# 克隆代码（加速链接）
git clone git@github.com:ki9mu/ARL-plus-docker ARL
# 进入 ARL 目录（后续所有命令需在此执行）
cd ARL

四、拉取 ARL 依赖镜像（解决拉取中断问题）

ARL 依赖 3 个核心镜像：mongo:4.0.27、ki9mu/shadow-rabbitmq:latest、ki9mu/arl-ki9mu:v3.0.1。

1. 优先创建数据卷（持久化数据库数据）

docker volume create arl_db

2. 拉取镜像（避免批量拉取中断，可逐个拉取）

方法1：批量拉取（加速源稳定时用）

docker compose pull

方法2：逐个拉取（解决批量拉取反复中断）

# 拉取 MongoDB 镜像
docker pull mongo:4.0.27
# 拉取 RabbitMQ 镜像
docker pull ki9mu/shadow-rabbitmq:latest
# 拉取 ARL 核心镜像
docker pull ki9mu/arl-ki9mu:v3.0.1

问题3：镜像拉取反复中断

• 现象：拉取过程中自动退出，进度无法完成
• 解决：
  1. 补充阿里云加速源（见第二步）；
  2. 重启 Docker 后逐个拉取镜像；
  3. 若仍中断，切换网络（如手机热点）后重试。

3. 验证镜像是否拉取完成

docker images | grep -E "mongo:4.0.27|ki9mu/shadow-rabbitmq|ki9mu/arl-ki9mu"

• 成功标志：输出包含 3 个镜像的信息。

五、ARL 核心操作：启动/关闭/重启

所有命令需在 ARL 目录（~/Web/web-tools/ARL） 执行，确保能读取 docker-compose.yml 文件。

1. 启动 ARL（后台运行）

docker compose up -d

• 作用：启动所有依赖容器（MongoDB、RabbitMQ、ARL 核心服务），后台运行不占用终端。
• 验证启动成功：

  docker compose ps

  成功标志：所有容器 STATE 为 Up。

2. 关闭 ARL（停止所有服务）

docker compose down

• 作用：停止并销毁所有容器（数据不会丢失，因为数据存在 arl_db 数据卷中）。
• 场景：长时间不使用时关闭，节省系统资源。

3. 重启 ARL（修改配置后用）

docker compose restart

• 作用：重启所有容器，适用于修改 ARL 配置后生效。

4. 查看 ARL 运行状态

docker compose ps

• 输出说明：
  • NAME：容器名称（如 arl_web 是 Web 界面容器）；
  • STATE：Up 表示运行中，Exited 表示已停止；
  • PORTS：端口映射（如 0.0.0.0:5003->443/tcp 表示 5003 端口映射到 HTTPS 服务）。

5. 查看 ARL 日志

# 查看所有容器日志（实时输出）
docker compose logs -f
# 查看单个容器日志（如 Web 容器，排查访问问题）
docker compose logs -f web
# 查看 MongoDB 容器日志（排查数据库问题）
docker compose logs -f mongodb

• 场景：容器启动失败（STATE 为 Exited）时，通过日志定位报错原因。

六、访问 ARL 系统

1. 正确访问地址

从容器端口映射可知：arl_web 将主机 5003 端口映射到容器 443 端口（HTTPS），因此必须用 https 开头的地址：

https://127.0.0.1:5003

问题4：访问地址错误

• 现象：输入 http://127.0.0.1:5003 无法访问
• 解决：改用 https 开头的地址（因容器映射的是 HTTPS 端口）。

2. 处理浏览器“不安全提示”

ARL 使用自签 SSL 证书，浏览器会提示“连接不安全”：

• 操作：选择“高级”→“继续访问 127.0.0.1（不安全）”（仅本地访问，无风险）。

3. 浏览器Cookie问题

• 现象：重启ARL容器后，浏览器访问时出现”Network Error”，必须删除Cookie才能重新登录
• 原因：容器重建后新会话与旧Cookie不匹配，且自签名证书变更导致浏览器Cookie绑定失效
• 解决方案：
  • 强制刷新：按 Ctrl+Shift+R（跳过本地Cookie缓存）
  • 使用隐私窗口：按 Ctrl+Shift+P 打开隐私窗口访问
  • 自动清除Cookie：设置浏览器退出时自动删除Cookie（Firefox：about:preferences#privacy → Cookie和网站数据 → 退出Firefox时删除Cookie和网站数据）

✅ 推荐配置：
在Kali系统中，建议将Firefox设置为”退出时删除Cookie”，这样每次重启浏览器后都会自动清除旧Cookie，完全避免手动操作。操作路径：
菜单 → 设置 → 隐私与安全 → Cookie和网站数据 → 退出Firefox时删除Cookie和网站数据

4. 默认登录 ARL

使用默认账号密码：

• 账号：admin
• 密码：arlpass

七、ARL 日常使用教程

ARL 是资产侦察系统，核心用途是 发现目标资产、识别指纹、扫描漏洞，以下是新手必备的基础操作：

1. 核心功能界面介绍

登录后首页分为 5 个核心模块：

• 「任务管理」：创建/启动/停止扫描任务；
• 「资产搜索」：查询已发现的资产（域名、IP、端口、服务等）；
• 「指纹管理」：查看已识别的应用指纹（如 Nginx、Tomcat、MySQL 等）；
• 「PoC 管理」：查看可利用的漏洞 PoC（无需手动上传，默认内置常用 PoC）；
• 「系统设置」：配置扫描线程、超时时间、邮件通知等。

2. 创建第一个资产侦察任务

步骤1：进入「任务管理」→ 点击「新建任务」

步骤2：填写任务信息（重点配置）

配置项	填写说明
任务名称	自定义（如“测试目标资产侦察”）
目标	输入要扫描的目标（支持多个，用换行/逗号分隔）： - 单个 IP：192.168.1.100； - 网段：192.168.1.0/24； - 域名：example.com； - 子域名爆破：*.example.com（自动爆破子域名）
端口扫描	选择扫描类型： - 常用端口：适合快速扫描； - 全端口：扫描所有 65535 端口（耗时久）； - 自定义端口：输入需要扫描的端口（如 80,443,3389,22）
扫描线程	新手建议默认（50 线程），线程越多扫描越快，但容易触发目标防护规则
其他选项	勾选“子域名爆破”“端口扫描”“指纹识别”“PoC 扫描”（按需选择）

步骤3：启动任务

点击「确认创建」→ 任务列表中找到刚创建的任务 → 点击「启动」。

步骤4：查看扫描结果

• 任务状态变为「运行中」，等待扫描完成（时间取决于目标数量和端口范围，10 分钟~数小时不等）；
• 扫描完成后，点击任务名称 → 查看详细结果：
  • 「资产列表」：已发现的 IP、域名、端口、服务（如 80/tcp http Nginx 1.21.0）；
  • 「指纹识别」：目标使用的应用程序、框架（如 Tomcat、WordPress、MySQL）；
  • 「PoC 结果」：已识别的漏洞（如弱密码、未授权访问、CVE 漏洞）；
  • 「导出报告」：支持导出 HTML/PDF 格式报告（用于整理扫描结果）。

3. 常用操作：资产搜索与筛选

场景：快速查找特定资产

1. 进入「资产搜索」模块；
2. 输入筛选条件：
   • 按端口筛选：port:80（查找所有 80 端口开放的资产）；
   • 按服务筛选：service:http（查找所有 HTTP 服务）；
   • 按指纹筛选：fingerprint:Nginx（查找所有 Nginx 服务器）；
   • 按漏洞筛选：vuln:弱密码（查找存在弱密码漏洞的资产）；
3. 点击「搜索」即可查看匹配结果。

4. 安全注意事项

• 仅扫描 自己拥有权限的目标（如本地测试环境、授权测试目标），禁止扫描未授权的公网资产或他人服务器（违法违规）；
• 扫描公网目标时，降低扫描线程（如 20 线程），避免触发目标的 DDoS 防护规则；
• 定期备份 ARL 数据（数据存储在 arl_db 数据卷中，可通过 Docker 备份数据卷）。

八、常见问题汇总

问题现象	解决方案
Docker Compose 安装提示”overwrite”冲突	卸载独立包 docker-compose ，使用系统预装的插件版 docker compose （无横杠）
Docker 加速配置不生效	检查 daemon.json 格式（逗号是否正确），重启 Docker 后用 docker info 验证
镜像拉取反复中断	补充阿里云加速源，重启 Docker 后逐个拉取镜像
访问 http://127.0.0.1:5003 无法打开	改用 https://127.0.0.1:5003 （容器映射的是 HTTPS 端口）
容器启动后状态为 Exited	查看日志：docker compose logs 容器名（如 docker compose logs web），重新拉取对应镜像后启动
扫描任务无法启动	检查 RabbitMQ 容器是否正常运行（arl_rabbitmq 状态为 Up），重启 ARL 后重试
扫描结果为空	目标可能未开放端口，或扫描规则过严，尝试选择”全端口扫描”+”子域名爆破”后重新扫描
每次重启ARL后需删除浏览器Cookie才能访问	原因：容器重建后新会话与旧Cookie不匹配，且自签名证书变更导致浏览器Cookie绑定失效 解决方案： - 强制刷新：按 Ctrl+Shift+R（忽略本地Cookie缓存） - 隐私窗口：按 Ctrl+Shift+P 打开隐私窗口访问 - 自动清除：设置浏览器退出时删除Cookie（Firefox：about:preferences#privacy → Cookie和网站数据 → 退出Firefox时删除Cookie和网站数据）

💡 补充说明：
此问题本质是浏览器对HTTPS证书的Cookie绑定机制导致。当您使用 docker compose down 停止服务后，ARL容器会销毁所有会话数据并重新生成自签名证书。浏览器保留的旧Cookie与新证书不匹配，导致认证失败。上述三种解决方案中，设置浏览器退出时自动清除Cookie是最彻底的解决方式，无需每次手动操作。

九、后续优化

1. 修改默认密码：登录后进入「个人中心」→「密码修改」，输入旧密码 arlpass 和新密码；
2. 备份 ARL 数据：

   # 备份数据卷 arl_db 到本地目录（如 ~/arl_backup）
   docker run --rm -v arl_db:/source -v ~/arl_backup:/dest alpine cp -r /source/* /dest/

3. 更新 ARL 镜像：

   # 拉取最新镜像
   docker compose pull
   # 重启容器
   docker compose up -d