企业官网建设流程全解析

不只是安装：用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"]

关键参数说明：

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 常见问题速查表

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