不只是安装：用Docker Compose深度配置你的ARL灯塔，实现定时任务与结果持久化

在渗透测试和红队行动中，资产收集的效率直接影响着整个项目的进度。ARL（Asset Reconnaissance Lighthouse）作为一款开源的资产侦察工具，已经证明了自己在自动化信息收集方面的价值。但大多数教程止步于"安装成功"的层面，对于真正需要将ARL投入生产环境的用户来说，这远远不够。

想象一下这样的场景：你花费数小时完成的扫描结果，因为虚拟机的意外关闭而全部丢失；或者你需要定期对客户资产进行监控，却不得不每天手动启动扫描任务。这些问题不解决，ARL就永远只能停留在"玩具工具"的层面。本文将带你突破这个瓶颈，通过Docker Compose的深度配置，实现 扫描数据持久化 和 定时任务自动化 ，让ARL真正成为你安全运维体系中的可靠组件。

1. 理解ARL的Docker架构

ARL默认的Docker Compose配置已经考虑到了基本的使用场景，但为了满足生产环境需求，我们需要先理解其内部服务架构：

version: '3'
services:
  arl:
    image: tophant/arl:latest
    ports:
      - "5003:5003"
    volumes:
      - arl_db:/data/db
    depends_on:
      - mongodb
  mongodb:
    image: mongo:4.0
    volumes:
      - arl_db:/data/db
volumes:
  arl_db:

这个配置揭示了三个关键点：

1. ARL服务与MongoDB服务分离，符合微服务架构原则
2. 使用Docker卷 arl_db 存储数据库数据
3. 默认只暴露Web界面端口(5003)

实际生产中的痛点 ：

• 默认配置下，删除容器会导致扫描任务配置丢失
• 扫描结果仅存储在容器内部，无法直接备份或分析
• 缺乏自动化的任务调度机制

2. 实现扫描数据的持久化存储

数据持久化是生产环境部署的首要考量。我们将通过三种级别的持久化方案，满足不同场景需求。

2.1 基础方案：宿主机目录映射

修改 docker-compose.yml 中的volumes部分：

services:
  mongodb:
    volumes:
      - /opt/arl_data/db:/data/db
  arl:
    volumes:
      - /opt/arl_data/config:/app/config

关键目录说明：

• /data/db ：MongoDB数据存储位置（扫描结果）
• /app/config ：ARL配置文件位置（任务配置）

验证持久化效果 ：

# 启动服务
docker-compose up -d

# 创建测试任务并执行
curl -X POST "https://localhost:5003/api/task" -H "Content-Type: application/json" -d '{"target":"example.com"}'

# 删除容器
docker-compose down

# 重新启动后检查任务是否存在
curl "https://localhost:5003/api/tasks"

2.2 进阶方案：多环境数据隔离

对于需要管理多个客户或项目的场景，建议采用以下目录结构：

/opt/arl_data/
├── client_a/
│   ├── db/
│   └── config/
├── client_b/
│   ├── db/
│   └── config/
└── templates/
    └── docker-compose.template.yml

通过环境变量动态指定数据目录：

services:
  mongodb:
    volumes:
      - ${CLIENT_DATA_DIR}/db:/data/db
  arl:
    volumes:
      - ${CLIENT_DATA_DIR}/config:/app/config

启动时指定客户端：

CLIENT_DATA_DIR=/opt/arl_data/client_a docker-compose up -d

2.3 专业方案：分布式存储集成

对于企业级部署，可以考虑接入NFS或Ceph等分布式存储系统：

services:
  mongodb:
    volumes:
      - nfs_volume:/data/db
volumes:
  nfs_volume:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.100,rw
      device: ":/path/to/nfs/share"

3. 配置定时扫描任务

自动化任务调度能显著提升资产监控效率。以下是三种主流的实现方案。

3.1 方案一：Docker内置重启策略

适用于简单的定时全量扫描：

services:
  arl:
    restart: unless-stopped

配合脚本实现定时任务：

#!/bin/bash
# arl_scheduler.sh

# 停止服务
docker-compose down

# 清理旧数据（可选）
rm -rf /opt/arl_data/db/*

# 启动新扫描
docker-compose up -d

然后配置cron：

0 3 * * * /path/to/arl_scheduler.sh

3.2 方案二：API触发特定任务

更精细化的控制可以通过ARL的REST API实现：

# arl_api_client.py
import requests
import json

API_URL = "https://localhost:5003/api"
AUTH = ("admin", "arlpass")

def create_task(target):
    response = requests.post(
        f"{API_URL}/task",
        json={"target": target},
        auth=AUTH,
        verify=False  # 自签名证书时需要
    )
    return response.json()

# 示例：每周一扫描example.com
if __name__ == "__main__":
    create_task("example.com")

配置systemd服务单元：

# /etc/systemd/system/arl-scan.service
[Unit]
Description=ARL Weekly Scan

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /path/to/arl_api_client.py

[Install]
WantedBy=multi-user.target

配合timer定时触发：

# /etc/systemd/system/arl-scan.timer
[Unit]
Description=Run ARL scan every Monday

[Timer]
OnCalendar=Mon *-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

3.3 方案三：Kubernetes CronJob

对于容器化程度较高的环境：

# arl-cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: arl-weekly-scan
spec:
  schedule: "0 2 * * 1"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: arl-client
            image: curlimages/curl
            command:
            - /bin/sh
            - -c
            - |
              curl -X POST "https://arl-service:5003/api/task" \
                -H "Content-Type: application/json" \
                -d '{"target":"example.com"}' \
                -u admin:arlpass -k
          restartPolicy: OnFailure

4. 生产环境优化配置

让ARL在复杂环境中稳定运行需要额外的配置调优。

4.1 资源限制与性能优化

services:
  arl:
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 4G
    environment:
      - WORKER_COUNT=4
      - TASK_TIMEOUT=3600

  mongodb:
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 2G
    command: ["mongod", "--wiredTigerCacheSizeGB=1.5"]

关键参数说明：

参数	推荐值	作用
WORKER_COUNT	CPU核心数×2	并发任务处理能力
TASK_TIMEOUT	根据任务调整	防止长时间挂起
wiredTigerCacheSizeGB	可用内存的70%	MongoDB性能优化

4.2 网络与安全配置

services:
  arl:
    networks:
      - arl_internal
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.arl.rule=Host(`arl.internal.example.com`)"
      - "traefik.http.routers.arl.tls=true"

  mongodb:
    networks:
      - arl_internal
    ports: []  # 不暴露外部端口

networks:
  arl_internal:
    internal: true

安全增强措施：

1. 修改默认管理员密码
2. 配置TLS证书
3. 设置IP访问白名单
4. 定期备份数据卷

4.3 监控与日志收集

services:
  arl:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

  prometheus-exporter:
    image: bitnami/mongodb-exporter
    environment:
      - MONGODB_URI=mongodb://mongodb:27017
    ports:
      - "9216:9216"

日志分析示例：

# 查看最近错误日志
docker-compose logs --tail=100 arl | grep -i error

# 监控数据库性能
curl -s http://localhost:9216/metrics | grep 'mongodb_connections_current'

5. 故障排查与维护技巧

即使配置完善，生产环境中仍可能遇到各种问题。以下是一些实战经验总结。

5.1 常见问题速查表

症状	可能原因	解决方案
任务长时间排队	WORKER_COUNT设置过小	增加worker数量或升级硬件
扫描结果不完整	目标反爬机制触发	调整扫描速率和超时设置
Web界面无法访问	证书问题或端口冲突	检查端口映射和TLS配置
数据库连接失败	MongoDB未正常启动	检查日志和资源限制

5.2 数据备份与恢复

备份脚本示例：

#!/bin/bash
# arl_backup.sh

BACKUP_DIR="/opt/arl_backups"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# 锁定数据库写入
docker-compose exec mongodb mongod --eval "db.fsyncLock()"

# 创建备份
docker-compose exec mongodb mongodump --out=/tmp/arl_backup
docker cp $(docker-compose ps -q mongodb):/tmp/arl_backup $BACKUP_DIR/arl_$TIMESTAMP

# 解锁数据库
docker-compose exec mongodb mongod --eval "db.fsyncUnlock()"

# 保留最近7天备份
find $BACKUP_DIR -type d -mtime +7 -exec rm -rf {} \;

恢复流程：

# 停止服务
docker-compose down

# 恢复数据
docker-compose run --rm mongodb mongorestore --drop /data/backup/arl_latest/

# 启动服务
docker-compose up -d

5.3 版本升级策略

ARL的迭代更新可能引入不兼容变更，推荐采用蓝绿部署策略：

1. 备份当前数据
2. 在新目录部署新版本
3. 测试确认功能正常
4. 切换流量到新版本
5. 观察一段时间后下线旧版本

# 示例升级命令
git pull origin master
docker-compose pull
docker-compose down
docker-compose up -d --force-recreate