这次我们来看一个名为Mangudai的开源项目。它是一个无代理Agentless的攻击面管理Attack Surface Manager工具专门为小型技术团队设计。简单来说它帮你自动发现、监控和管理你的互联网资产如域名、子域名、IP、端口、证书等找出潜在的安全风险而无需在你的服务器或资产上安装任何代理程序。对于资源有限、安全人手不足的团队来说手动维护资产清单和监控安全暴露面是件耗时且容易出错的事。Mangudai 的核心价值在于自动化这个过程。它通过集成多种公开数据源和扫描引擎持续地为你绘制攻击面地图并识别出诸如暴露的敏感服务、过期的SSL证书、配置错误或未使用的资产等问题。本文将带你快速了解 Mangudai 的核心能力、部署方式以及如何用它来提升团队的基础安全水位。我们会重点关注它的无代理架构优势、对硬件资源的低要求、一键启动的便捷性以及如何通过其API或定期任务实现自动化监控。如果你正在为资产梳理和外部攻击面管理发愁这个工具值得一试。1. 核心能力速览Mangudai 作为一个轻量级的攻击面管理方案其设计目标非常明确易部署、低开销、自动化。下表概括了它的核心特性能力项说明项目类型开源攻击面管理ASM平台核心架构无代理Agentless通过外部扫描和API集成收集数据无需在目标资产安装任何软件。主要功能1.资产发现自动发现域名、子域名、IP地址、云资源等。2.漏洞与风险识别检测开放的敏感端口如SSH、RDP、数据库、过期的SSL/TLS证书、配置错误等。3.攻击面可视化提供仪表盘和资产关系图直观展示暴露面。4.持续监控支持定时任务持续监控资产变化和新出现的风险。部署方式支持Docker Compose一键部署也提供源码部署选项。硬件门槛资源要求低。作为主要进行信息收集和关联分析的工具对CPU和内存消耗不大。实测在2核CPU、4GB内存的Linux服务器上可流畅运行。无需GPU。数据存储默认使用SQLite适合小型团队也支持PostgreSQL以应对更大数据量。是否支持API是。提供RESTful API可用于集成到CI/CD流水线、自动化脚本或其它安全平台。是否支持批量任务是。支持通过配置定义扫描任务可定时或手动触发对一批资产进行扫描。适合场景初创公司、小型研发团队、安全工程师个人、需要快速梳理互联网资产并建立基础安全监控的团队。2. 适用场景与使用边界Mangudai 最适合谁安全人员不足的小团队没有专职安全工程师但开发或运维团队需要承担基础的安全资产管理工作。初创公司或快速成长的业务互联网资产域名、云服务器、API服务快速增加手工维护的Excel表格早已跟不上变化。希望实现安全左移的DevOps团队希望在CI/CD或基础设施即代码IaC流程中加入对外部攻击面的自动化检查。个人安全研究者或顾问用于管理多个客户或项目的资产进行持续的安全评估。它能解决什么问题资产黑洞“我们到底有多少个对公网开放的服务” Mangudai 可以帮你回答这个问题。风险滞后新上线的测试服务器忘了关防火墙直接暴露了22端口某个域名的SSL证书半年后过期无人知晓。Mangudai 的持续监控能及时发现这类问题。手工操作效率低下定期手动运行nmap、subfinder等工具然后整理结果耗时耗力且容易遗漏。它的使用边界与注意事项无代理扫描的局限性由于无需安装代理Mangudai 主要依赖于外部扫描和公开数据源。这意味着它可能无法发现深藏在内网、没有任何对外端口的资产也无法获取资产内部的操作系统、软件版本等详细信息除非该服务本身对外暴露了信息。它更侧重于“外部攻击者能看到什么”。扫描合规性在使用Mangudai扫描任何资产前你必须确保拥有对该资产进行扫描的合法授权。扫描自有资产是安全的但绝对禁止在未获得明确书面授权的情况下扫描任何不属于你的IP地址、域名或网络空间。未经授权的扫描可能违反《网络安全法》等相关法律法规并被视为恶意攻击行为。非实时防御工具Mangudai 是一个攻击面管理和风险发现工具而不是实时入侵检测系统IDS或防火墙。它告诉你哪里门没关好但不会主动帮你把门关上或击退入侵者。信息准确性依赖数据源其发现结果的广度和准确性部分依赖于集成的第三方数据源如子域名枚举库、证书透明度日志的更新速度和覆盖面。3. 环境准备与前置条件部署 Mangudai 非常简单对运行环境的要求也很宽松。基础环境要求操作系统推荐 Linux (如 Ubuntu 20.04/22.04, CentOS 7/8) 或 macOS。Windows 系统可通过 WSL2 或 Docker Desktop 运行。容器环境Docker与Docker Compose。这是最推荐的一键部署方式。备选方案如果选择源码部署需要Python 3.8和Node.js 16环境。网络服务器需要能正常访问互联网以下载Docker镜像、调用外部API如用于子域名发现的公共API以及扫描目标资产。硬件最低配置 1核CPU、2GB内存、10GB磁盘空间即可启动。为了更好的体验和处理更多资产建议使用2核CPU、4GB内存。权限运行 Docker 需要sudo权限或当前用户属于docker用户组。部署前检查清单更新系统包管理器并安装必要工具如git,curl。# Ubuntu/Debian sudo apt update sudo apt install -y git curl # CentOS/RHEL sudo yum install -y git curl安装 Docker 和 Docker Compose。# 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER newgrp docker # 或退出终端重新登录使组权限生效 # 安装Docker Compose插件推荐 sudo apt install -y docker-compose-plugin # Ubuntu # 或下载独立版本 sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose验证安装。docker --version docker compose version # 如果使用插件 # 或 docker-compose --version # 如果使用独立版本4. 安装部署与启动方式最快捷的方式是使用项目提供的docker-compose.yml文件一键启动所有服务。步骤 1获取项目代码git clone https://github.com/mangudai-project/mangudai.git # 请替换为实际仓库地址 cd mangudai注意由于网络搜索材料未提供确切仓库地址此处为示例。请以项目官方文档或GitHub仓库为准。步骤 2配置环境变量通常项目会提供一个环境变量示例文件如.env.example。你需要复制并修改它。cp .env.example .env编辑.env文件根据你的需求调整配置。关键配置可能包括SECRET_KEY: 用于加密的密钥务必修改为强随机字符串。DATABASE_URL: 数据库连接字符串。使用默认的SQLitesqlite:///data/mangudai.db对于小团队起步足够。外部API密钥如果你需要集成 Shodan, SecurityTrails, Censys 等付费或高限额服务以增强发现能力在此处填入你的API密钥。扫描速率限制为避免对目标造成压力或被封禁可以配置扫描线程数、延迟等参数。步骤 3使用 Docker Compose 启动docker compose up -d这个命令会在后台拉取必要的镜像如前端、后端、数据库等并启动所有容器。步骤 4验证服务状态docker compose ps你应该看到所有服务状态均为running。同时查看日志以确保没有启动错误docker compose logs -f backend # 查看后端日志 docker compose logs -f frontend # 查看前端日志步骤 5访问 Web 界面服务启动后默认情况下前端Web界面通常运行在http://你的服务器IP:3000或http://localhost:3000。后端API服务可能在另一个端口如8000。 打开浏览器访问对应的地址。首次访问可能需要创建管理员账户。至此Mangudai 的核心服务应该已经运行起来了。整个启动过程如果网络通畅通常在5-10分钟内完成。5. 功能测试与效果验证启动成功后我们通过几个核心功能来验证Mangudai是否工作正常。5.1 添加资产与扫描范围测试目的验证系统能否接受资产输入并开始发现流程。登录Web界面使用首次创建的管理员账户登录。添加资产在界面上寻找如 “Assets”, “Targets”, “Scopes” 或 “Projects” 的菜单。定义范围添加一个你要监控的根域名例如example.com或一个IP地址段例如192.0.2.0/24。请务必使用你拥有或已获授权测试的资产。启动发现任务保存资产后通常会有 “Scan”, “Run Discovery”, “Start Monitor” 等按钮。点击它启动第一次攻击面发现。预期结果任务状态变为“进行中”或“已排队”。稍后时间取决于资产数量在资产列表或仪表盘中能看到新发现的子域名、IP地址等信息。5.2 查看攻击面仪表盘测试目的验证数据聚合与可视化功能。进入主仪表盘Dashboard页面。观察关键指标例如资产总数域名、主机、服务。发现的高风险问题数量如开放的高危端口。证书过期预警。资产随时间的变化趋势图。预期结果仪表盘应清晰展示整体安全态势的概览。对于新添加的资产数据可能从零开始增长。5.3 验证端口与服务发现测试目的验证Mangudai的基础扫描能力。在资产详情页找到一台已发现的主机IP地址。查看该主机的“端口”或“服务”标签页。检查它是否识别出了常见的开放端口如80/http, 443/https, 22/ssh, 3389/rdp等及对应的服务横幅banner。预期结果能够正确列出开放的端口和推测的服务信息。这是评估外部暴露面的关键。5.4 测试SSL证书监控测试目的验证对安全配置的监控能力。找到一个使用HTTPS端口443的资产。查看其详情寻找“证书”、“SSL”或“安全”相关的信息板块。检查其中是否包含了证书颁发者、有效期起止日期等信息。预期结果能够正确获取并显示SSL证书信息。如果添加了一个证书即将过期的域名系统应该能产生相应的告警或风险项。5.5 触发一次手动扫描任务测试目的验证定时/手动任务调度功能。找到“扫描任务”、“定时任务”或“作业”管理页面。创建一个新的扫描任务关联到你之前添加的资产范围。选择扫描类型如“全量发现”、“增量监控”、“端口扫描”。立即执行该任务。预期结果任务成功加入队列并执行。在任务历史或日志中可以看到执行状态成功/失败和概要结果。执行完成后相关资产的数据应得到更新。判断成功的标准以上操作均能顺利完成且界面能返回符合预期的数据资产列表非空、端口信息正确、证书信息可读、任务状态正常。如果任何一步出现长时间空白、错误提示或任务失败则需要进入排查环节。6. 接口 API 与批量任务Mangudai 的自动化能力很大程度上通过其 API 和任务系统体现。6.1 API 接口调用后端服务通常会提供 REST API用于程序化交互。接口启动方式API服务随docker compose一起启动。默认地址可能是http://localhost:8000/api/v1/具体请查看项目文档或环境配置。基础调用示例Python 假设你需要通过API获取所有资产列表。import requests import json # 配置API地址和认证信息以Bearer Token为例 API_BASE_URL http://YOUR_SERVER_IP:8000/api/v1 API_TOKEN your_api_token_here # 需要在Web界面生成 headers { Authorization: fBearer {API_TOKEN}, Content-Type: application/json } # 示例1获取所有资产 def get_assets(): url f{API_BASE_URL}/assets/ try: response requests.get(url, headersheaders, timeout30) response.raise_for_status() # 检查HTTP错误 assets response.json() print(f获取到 {len(assets)} 个资产) # 处理资产数据... return assets except requests.exceptions.RequestException as e: print(f请求失败: {e}) return None # 示例2添加一个新资产范围域名 def add_domain_asset(domain): url f{API_BASE_URL}/assets/ payload { name: domain, type: domain, target: domain, description: Added via API } try: response requests.post(url, jsonpayload, headersheaders, timeout30) response.raise_for_status() print(f成功添加资产: {domain}) return response.json() except requests.exceptions.RequestException as e: print(f添加资产失败: {e}) return None if __name__ __main__: # 使用示例 # get_assets() # add_domain_asset(api-test.yourcompany.com)关键API端点可能包括需根据实际项目文档确认GET /assets/– 列出资产POST /assets/– 创建资产GET /scanjobs/– 列出扫描任务POST /scanjobs/– 创建扫描任务GET /findings/– 获取发现的风险项6.2 批量任务与集成批量资产导入如果你已有资产列表CSV文件可以编写脚本读取文件并循环调用POST /assets/API 进行批量导入。CI/CD 集成可以在部署新服务的CI/CD流水线末尾调用Mangudai API将该服务对应的新域名或IP添加到监控范围实现安全监控的自动化纳入。定时扫描配置这是Mangudai的核心功能之一。通常在Web界面或通过API配置频率每天、每周或每月执行。范围针对全部资产或特定标签的资产。扫描深度全量发现或仅增量检查变化。 配置好后系统会自动在预定时间触发扫描任务更新资产和风险数据。批量任务处理建议速率限制在调用API或配置扫描时注意设置合理的间隔避免对目标系统或自身API造成压力。错误处理在自动化脚本中务必加入重试机制和异常捕获记录失败任务以便后续补入。结果处理API返回的扫描结果可能很详细考虑将其与团队的告警平台如Slack,钉钉,企业微信或工单系统集成实现风险自动提单。7. 资源占用与性能观察Mangudai 作为无代理扫描器其资源消耗主要发生在主动扫描期间。日常监控状态下消耗很低。日常闲置状态 启动所有Docker容器后使用docker stats命令观察整体内存占用通常在1GB ~ 2GB之间取决于数据量CPU使用率接近0%。这对于一台轻量级云服务器来说压力很小。主动扫描期间 当触发全端口扫描或深度子域名枚举时资源消耗会有明显峰值。CPU负责执行扫描任务的容器可能命名为scanner,worker等CPU使用率会升高可能达到50%-100%单核持续时间取决于扫描目标数量。内存扫描器进程内存占用会增加但通常也在可控范围内每个进程数百MB。网络I/O会产生大量的对外网络连接用于端口探测、HTTP请求等。性能优化与观察建议控制扫描并发在环境配置文件中找到关于并发线程、进程数的设置如MAX_SCAN_THREADS,WORKER_CONCURRENCY根据你的服务器性能和网络带宽进行调整。从小并发开始测试。分时段扫描将大型扫描任务安排在业务低峰期例如凌晨避免扫描流量影响正常业务或触发目标的防护策略。使用增量扫描对于已监控的资产配置为只扫描变化部分如新发现的子域名、新开放的端口而非每次都全量扫描可以极大减少资源消耗和时间。监控Docker容器使用docker compose logs -f [service-name]可以实时查看特定服务的日志了解任务执行状态和错误信息。使用docker stats可以实时查看资源占用。数据库性能如果资产数量增长到数万级别SQLite可能会成为瓶颈。此时应考虑按照官方文档将数据库迁移至PostgreSQL以获得更好的性能。8. 常见问题与排查方法在部署和使用过程中你可能会遇到以下典型问题。问题现象可能原因排查方式解决方案docker compose up -d失败1. Docker或Docker Compose未正确安装。2. 端口被占用。3..env配置文件有语法错误或路径错误。1. 运行docker --version和docker compose version验证。2. 查看命令输出错误信息。3. 检查docker compose logs看具体哪个服务启动失败。1. 重新安装Docker环境。2. 修改docker-compose.yml中的端口映射如将3000:3000改为3001:3000。3. 检查.env文件确保变量值格式正确文件路径存在。Web界面无法访问1. 服务未成功启动。2. 防火墙/安全组阻止了端口访问。3. 容器内部服务崩溃。1.docker compose ps查看容器状态。2.curl -I http://localhost:3000在服务器内部测试。3.docker compose logs frontend查看前端日志。1. 根据日志修复错误后重启服务docker compose restart。2. 配置服务器防火墙和安全组放行对应端口如3000, 8000。3. 检查前端依赖或配置问题。扫描任务长时间无结果1. 网络问题无法访问外部API或目标。2. 扫描配置错误如目标格式不对。3. 任务队列Worker没有运行。1. 进入扫描器容器docker exec -it mangudai-scanner bash尝试ping或curl测试网络。2. 查看任务详情和日志docker compose logs scanner。3. 检查Worker服务状态。1. 确保服务器有外网访问能力检查DNS设置。2. 确认输入的资产目标是有效的域名或IP。3. 重启Worker服务docker compose restart worker。发现资产数量远少于预期1. 使用的免费数据源有限制或已失效。2. 扫描深度设置过浅。3. 目标域名设置了防护如CDN、子域名枚举防护。1. 检查配置文件中关于子域名发现模块的日志。2. 尝试使用多个不同的发现工具或配置。3. 手动使用其他工具如subfinder验证。1. 考虑配置更强大或付费的API密钥如SecurityTrails, Censys。2. 调整扫描策略增加字典或递归深度。3. 了解这是无代理扫描的固有局限可结合内部CMDB数据补充。API调用返回401/403错误1. API Token未提供或已过期。2. Token权限不足。3. 请求头格式错误。1. 检查代码中的API_TOKEN是否正确。2. 在Web界面重新生成Token并测试。3. 使用curl命令简化测试curl -H Authorization: Bearer TOKEN http://api-url/assets/。1. 使用正确的Token并确保其在请求头的Authorization字段中。2. 检查用户角色是否具有API访问权限。3. 参照官方API文档修正请求格式。数据库磁盘空间增长过快1. 扫描结果和历史数据积累。2. 日志未配置轮转。1.docker exec进入数据库容器查看表大小。2. 检查Docker卷的磁盘使用情况docker system df。1. 在Web界面或通过API定期清理历史扫描数据如果功能支持。2. 配置日志轮转策略。3. 考虑将数据库迁移至有更好管理功能的PostgreSQL。9. 最佳实践与使用建议为了让 Mangudai 在你的环境中稳定、有效且安全地运行遵循以下实践建议从小范围开始首次部署时不要一次性添加所有公司资产。先添加1-2个你完全掌控的测试域名或IP段验证整个流程发现、扫描、告警工作正常并观察资源消耗。仔细配置扫描策略速率限制务必设置合理的扫描延迟和并发数体现良好的“网络公民”意识避免对目标网络造成干扰。避开敏感时段将深度扫描安排在业务维护窗口。使用白名单如果某些IP或域名明确不需要扫描如第三方服务将其加入排除列表。资产标签化管理为资产打上标签如production、staging、aws、department-xx。这便于后续按环境、团队或重要性进行筛选、统计和制定不同的扫描策略。建立处理流程Mangudai 发现了风险然后呢建议建立闭环流程风险分级根据端口风险等级、证书过期紧急程度等对发现的问题进行分级。自动通知配置将中高风险问题自动推送到团队聊天工具如钉钉、飞书群。工单集成对于需要跟进处理的问题最好能自动创建Jira、Trello或内部工单并指派给相应的负责人如运维、开发。定期审计与复核误报处理定期查看已关闭的风险确认是真实修复还是误报。对于误报可以在系统中标记或添加规则排除提高未来报警的准确性。资产盘点每季度或每半年利用Mangudai生成的资产报告与团队的CMDB或资产清单进行交叉核对确保没有“幽灵资产”。安全与合规第一授权扫描再次强调扫描必须获得明确授权。将扫描范围严格限定在自有或已获书面授权的资产内。保护Mangudai自身Mangudai本身存储了资产和风险信息需确保其服务访问安全如设置强密码、启用HTTPS、限制访问IP。敏感信息处理Mangudai可能会发现暴露的敏感信息如调试页面、备份文件。对这些信息的处理要符合公司数据安全政策。10. 总结Mangudai 为小型技术团队提供了一个非常实用的攻击面管理入口。它的无代理架构使得部署和上手极其简单避免了在复杂异构环境中安装代理的麻烦。Docker Compose一键启动的特性让它在几分钟内就能跑起来快速看到效果。虽然其发现能力依赖于外部数据源和扫描但对于梳理互联网暴露资产、发现常见的配置疏忽如高危端口、过期证书已经足够。对于刚开始构建安全体系的团队我建议按以下路径尝试快速部署找一台测试服务器按照本文的Docker Compose步骤先把服务跑起来。功能验证添加一个你熟悉的测试域名完整走一遍“添加-扫描-查看结果-处理风险”的流程理解其工作模式。小范围试点选择一个非核心的业务系统或测试环境将其资产纳入监控跑1-2个扫描周期观察稳定性和准确性。流程集成尝试将其API与你们的运维通知系统如钉钉机器人打通实现风险自动告警。最容易踩的坑往往是网络配置容器无法访问外网和扫描策略过于激进导致IP被临时封锁。因此初期务必保守配置并密切关注日志。这个项目本身也在迭代中你可以关注其后续版本看是否会集成更多扫描引擎、提供更丰富的风险库以及更强大的报表功能。对于有开发能力的团队其开源特性也允许你们根据自身业务需求进行二次开发比如集成内部CMDB数据源或定制专属的风险检测规则。将攻击面管理自动化是迈向主动安全的第一步。Mangudai 提供了一个轻量级的起点建议收藏本文在需要时参照部署和配置。 开源无代理攻击面管理工具Mangudai：轻量部署与自动化安全监控实践
这次我们来看一个名为Mangudai的开源项目。它是一个无代理Agentless的攻击面管理Attack Surface Manager工具专门为小型技术团队设计。简单来说它帮你自动发现、监控和管理你的互联网资产如域名、子域名、IP、端口、证书等找出潜在的安全风险而无需在你的服务器或资产上安装任何代理程序。对于资源有限、安全人手不足的团队来说手动维护资产清单和监控安全暴露面是件耗时且容易出错的事。Mangudai 的核心价值在于自动化这个过程。它通过集成多种公开数据源和扫描引擎持续地为你绘制攻击面地图并识别出诸如暴露的敏感服务、过期的SSL证书、配置错误或未使用的资产等问题。本文将带你快速了解 Mangudai 的核心能力、部署方式以及如何用它来提升团队的基础安全水位。我们会重点关注它的无代理架构优势、对硬件资源的低要求、一键启动的便捷性以及如何通过其API或定期任务实现自动化监控。如果你正在为资产梳理和外部攻击面管理发愁这个工具值得一试。1. 核心能力速览Mangudai 作为一个轻量级的攻击面管理方案其设计目标非常明确易部署、低开销、自动化。下表概括了它的核心特性能力项说明项目类型开源攻击面管理ASM平台核心架构无代理Agentless通过外部扫描和API集成收集数据无需在目标资产安装任何软件。主要功能1.资产发现自动发现域名、子域名、IP地址、云资源等。2.漏洞与风险识别检测开放的敏感端口如SSH、RDP、数据库、过期的SSL/TLS证书、配置错误等。3.攻击面可视化提供仪表盘和资产关系图直观展示暴露面。4.持续监控支持定时任务持续监控资产变化和新出现的风险。部署方式支持Docker Compose一键部署也提供源码部署选项。硬件门槛资源要求低。作为主要进行信息收集和关联分析的工具对CPU和内存消耗不大。实测在2核CPU、4GB内存的Linux服务器上可流畅运行。无需GPU。数据存储默认使用SQLite适合小型团队也支持PostgreSQL以应对更大数据量。是否支持API是。提供RESTful API可用于集成到CI/CD流水线、自动化脚本或其它安全平台。是否支持批量任务是。支持通过配置定义扫描任务可定时或手动触发对一批资产进行扫描。适合场景初创公司、小型研发团队、安全工程师个人、需要快速梳理互联网资产并建立基础安全监控的团队。2. 适用场景与使用边界Mangudai 最适合谁安全人员不足的小团队没有专职安全工程师但开发或运维团队需要承担基础的安全资产管理工作。初创公司或快速成长的业务互联网资产域名、云服务器、API服务快速增加手工维护的Excel表格早已跟不上变化。希望实现安全左移的DevOps团队希望在CI/CD或基础设施即代码IaC流程中加入对外部攻击面的自动化检查。个人安全研究者或顾问用于管理多个客户或项目的资产进行持续的安全评估。它能解决什么问题资产黑洞“我们到底有多少个对公网开放的服务” Mangudai 可以帮你回答这个问题。风险滞后新上线的测试服务器忘了关防火墙直接暴露了22端口某个域名的SSL证书半年后过期无人知晓。Mangudai 的持续监控能及时发现这类问题。手工操作效率低下定期手动运行nmap、subfinder等工具然后整理结果耗时耗力且容易遗漏。它的使用边界与注意事项无代理扫描的局限性由于无需安装代理Mangudai 主要依赖于外部扫描和公开数据源。这意味着它可能无法发现深藏在内网、没有任何对外端口的资产也无法获取资产内部的操作系统、软件版本等详细信息除非该服务本身对外暴露了信息。它更侧重于“外部攻击者能看到什么”。扫描合规性在使用Mangudai扫描任何资产前你必须确保拥有对该资产进行扫描的合法授权。扫描自有资产是安全的但绝对禁止在未获得明确书面授权的情况下扫描任何不属于你的IP地址、域名或网络空间。未经授权的扫描可能违反《网络安全法》等相关法律法规并被视为恶意攻击行为。非实时防御工具Mangudai 是一个攻击面管理和风险发现工具而不是实时入侵检测系统IDS或防火墙。它告诉你哪里门没关好但不会主动帮你把门关上或击退入侵者。信息准确性依赖数据源其发现结果的广度和准确性部分依赖于集成的第三方数据源如子域名枚举库、证书透明度日志的更新速度和覆盖面。3. 环境准备与前置条件部署 Mangudai 非常简单对运行环境的要求也很宽松。基础环境要求操作系统推荐 Linux (如 Ubuntu 20.04/22.04, CentOS 7/8) 或 macOS。Windows 系统可通过 WSL2 或 Docker Desktop 运行。容器环境Docker与Docker Compose。这是最推荐的一键部署方式。备选方案如果选择源码部署需要Python 3.8和Node.js 16环境。网络服务器需要能正常访问互联网以下载Docker镜像、调用外部API如用于子域名发现的公共API以及扫描目标资产。硬件最低配置 1核CPU、2GB内存、10GB磁盘空间即可启动。为了更好的体验和处理更多资产建议使用2核CPU、4GB内存。权限运行 Docker 需要sudo权限或当前用户属于docker用户组。部署前检查清单更新系统包管理器并安装必要工具如git,curl。# Ubuntu/Debian sudo apt update sudo apt install -y git curl # CentOS/RHEL sudo yum install -y git curl安装 Docker 和 Docker Compose。# 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER newgrp docker # 或退出终端重新登录使组权限生效 # 安装Docker Compose插件推荐 sudo apt install -y docker-compose-plugin # Ubuntu # 或下载独立版本 sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose验证安装。docker --version docker compose version # 如果使用插件 # 或 docker-compose --version # 如果使用独立版本4. 安装部署与启动方式最快捷的方式是使用项目提供的docker-compose.yml文件一键启动所有服务。步骤 1获取项目代码git clone https://github.com/mangudai-project/mangudai.git # 请替换为实际仓库地址 cd mangudai注意由于网络搜索材料未提供确切仓库地址此处为示例。请以项目官方文档或GitHub仓库为准。步骤 2配置环境变量通常项目会提供一个环境变量示例文件如.env.example。你需要复制并修改它。cp .env.example .env编辑.env文件根据你的需求调整配置。关键配置可能包括SECRET_KEY: 用于加密的密钥务必修改为强随机字符串。DATABASE_URL: 数据库连接字符串。使用默认的SQLitesqlite:///data/mangudai.db对于小团队起步足够。外部API密钥如果你需要集成 Shodan, SecurityTrails, Censys 等付费或高限额服务以增强发现能力在此处填入你的API密钥。扫描速率限制为避免对目标造成压力或被封禁可以配置扫描线程数、延迟等参数。步骤 3使用 Docker Compose 启动docker compose up -d这个命令会在后台拉取必要的镜像如前端、后端、数据库等并启动所有容器。步骤 4验证服务状态docker compose ps你应该看到所有服务状态均为running。同时查看日志以确保没有启动错误docker compose logs -f backend # 查看后端日志 docker compose logs -f frontend # 查看前端日志步骤 5访问 Web 界面服务启动后默认情况下前端Web界面通常运行在http://你的服务器IP:3000或http://localhost:3000。后端API服务可能在另一个端口如8000。 打开浏览器访问对应的地址。首次访问可能需要创建管理员账户。至此Mangudai 的核心服务应该已经运行起来了。整个启动过程如果网络通畅通常在5-10分钟内完成。5. 功能测试与效果验证启动成功后我们通过几个核心功能来验证Mangudai是否工作正常。5.1 添加资产与扫描范围测试目的验证系统能否接受资产输入并开始发现流程。登录Web界面使用首次创建的管理员账户登录。添加资产在界面上寻找如 “Assets”, “Targets”, “Scopes” 或 “Projects” 的菜单。定义范围添加一个你要监控的根域名例如example.com或一个IP地址段例如192.0.2.0/24。请务必使用你拥有或已获授权测试的资产。启动发现任务保存资产后通常会有 “Scan”, “Run Discovery”, “Start Monitor” 等按钮。点击它启动第一次攻击面发现。预期结果任务状态变为“进行中”或“已排队”。稍后时间取决于资产数量在资产列表或仪表盘中能看到新发现的子域名、IP地址等信息。5.2 查看攻击面仪表盘测试目的验证数据聚合与可视化功能。进入主仪表盘Dashboard页面。观察关键指标例如资产总数域名、主机、服务。发现的高风险问题数量如开放的高危端口。证书过期预警。资产随时间的变化趋势图。预期结果仪表盘应清晰展示整体安全态势的概览。对于新添加的资产数据可能从零开始增长。5.3 验证端口与服务发现测试目的验证Mangudai的基础扫描能力。在资产详情页找到一台已发现的主机IP地址。查看该主机的“端口”或“服务”标签页。检查它是否识别出了常见的开放端口如80/http, 443/https, 22/ssh, 3389/rdp等及对应的服务横幅banner。预期结果能够正确列出开放的端口和推测的服务信息。这是评估外部暴露面的关键。5.4 测试SSL证书监控测试目的验证对安全配置的监控能力。找到一个使用HTTPS端口443的资产。查看其详情寻找“证书”、“SSL”或“安全”相关的信息板块。检查其中是否包含了证书颁发者、有效期起止日期等信息。预期结果能够正确获取并显示SSL证书信息。如果添加了一个证书即将过期的域名系统应该能产生相应的告警或风险项。5.5 触发一次手动扫描任务测试目的验证定时/手动任务调度功能。找到“扫描任务”、“定时任务”或“作业”管理页面。创建一个新的扫描任务关联到你之前添加的资产范围。选择扫描类型如“全量发现”、“增量监控”、“端口扫描”。立即执行该任务。预期结果任务成功加入队列并执行。在任务历史或日志中可以看到执行状态成功/失败和概要结果。执行完成后相关资产的数据应得到更新。判断成功的标准以上操作均能顺利完成且界面能返回符合预期的数据资产列表非空、端口信息正确、证书信息可读、任务状态正常。如果任何一步出现长时间空白、错误提示或任务失败则需要进入排查环节。6. 接口 API 与批量任务Mangudai 的自动化能力很大程度上通过其 API 和任务系统体现。6.1 API 接口调用后端服务通常会提供 REST API用于程序化交互。接口启动方式API服务随docker compose一起启动。默认地址可能是http://localhost:8000/api/v1/具体请查看项目文档或环境配置。基础调用示例Python 假设你需要通过API获取所有资产列表。import requests import json # 配置API地址和认证信息以Bearer Token为例 API_BASE_URL http://YOUR_SERVER_IP:8000/api/v1 API_TOKEN your_api_token_here # 需要在Web界面生成 headers { Authorization: fBearer {API_TOKEN}, Content-Type: application/json } # 示例1获取所有资产 def get_assets(): url f{API_BASE_URL}/assets/ try: response requests.get(url, headersheaders, timeout30) response.raise_for_status() # 检查HTTP错误 assets response.json() print(f获取到 {len(assets)} 个资产) # 处理资产数据... return assets except requests.exceptions.RequestException as e: print(f请求失败: {e}) return None # 示例2添加一个新资产范围域名 def add_domain_asset(domain): url f{API_BASE_URL}/assets/ payload { name: domain, type: domain, target: domain, description: Added via API } try: response requests.post(url, jsonpayload, headersheaders, timeout30) response.raise_for_status() print(f成功添加资产: {domain}) return response.json() except requests.exceptions.RequestException as e: print(f添加资产失败: {e}) return None if __name__ __main__: # 使用示例 # get_assets() # add_domain_asset(api-test.yourcompany.com)关键API端点可能包括需根据实际项目文档确认GET /assets/– 列出资产POST /assets/– 创建资产GET /scanjobs/– 列出扫描任务POST /scanjobs/– 创建扫描任务GET /findings/– 获取发现的风险项6.2 批量任务与集成批量资产导入如果你已有资产列表CSV文件可以编写脚本读取文件并循环调用POST /assets/API 进行批量导入。CI/CD 集成可以在部署新服务的CI/CD流水线末尾调用Mangudai API将该服务对应的新域名或IP添加到监控范围实现安全监控的自动化纳入。定时扫描配置这是Mangudai的核心功能之一。通常在Web界面或通过API配置频率每天、每周或每月执行。范围针对全部资产或特定标签的资产。扫描深度全量发现或仅增量检查变化。 配置好后系统会自动在预定时间触发扫描任务更新资产和风险数据。批量任务处理建议速率限制在调用API或配置扫描时注意设置合理的间隔避免对目标系统或自身API造成压力。错误处理在自动化脚本中务必加入重试机制和异常捕获记录失败任务以便后续补入。结果处理API返回的扫描结果可能很详细考虑将其与团队的告警平台如Slack,钉钉,企业微信或工单系统集成实现风险自动提单。7. 资源占用与性能观察Mangudai 作为无代理扫描器其资源消耗主要发生在主动扫描期间。日常监控状态下消耗很低。日常闲置状态 启动所有Docker容器后使用docker stats命令观察整体内存占用通常在1GB ~ 2GB之间取决于数据量CPU使用率接近0%。这对于一台轻量级云服务器来说压力很小。主动扫描期间 当触发全端口扫描或深度子域名枚举时资源消耗会有明显峰值。CPU负责执行扫描任务的容器可能命名为scanner,worker等CPU使用率会升高可能达到50%-100%单核持续时间取决于扫描目标数量。内存扫描器进程内存占用会增加但通常也在可控范围内每个进程数百MB。网络I/O会产生大量的对外网络连接用于端口探测、HTTP请求等。性能优化与观察建议控制扫描并发在环境配置文件中找到关于并发线程、进程数的设置如MAX_SCAN_THREADS,WORKER_CONCURRENCY根据你的服务器性能和网络带宽进行调整。从小并发开始测试。分时段扫描将大型扫描任务安排在业务低峰期例如凌晨避免扫描流量影响正常业务或触发目标的防护策略。使用增量扫描对于已监控的资产配置为只扫描变化部分如新发现的子域名、新开放的端口而非每次都全量扫描可以极大减少资源消耗和时间。监控Docker容器使用docker compose logs -f [service-name]可以实时查看特定服务的日志了解任务执行状态和错误信息。使用docker stats可以实时查看资源占用。数据库性能如果资产数量增长到数万级别SQLite可能会成为瓶颈。此时应考虑按照官方文档将数据库迁移至PostgreSQL以获得更好的性能。8. 常见问题与排查方法在部署和使用过程中你可能会遇到以下典型问题。问题现象可能原因排查方式解决方案docker compose up -d失败1. Docker或Docker Compose未正确安装。2. 端口被占用。3..env配置文件有语法错误或路径错误。1. 运行docker --version和docker compose version验证。2. 查看命令输出错误信息。3. 检查docker compose logs看具体哪个服务启动失败。1. 重新安装Docker环境。2. 修改docker-compose.yml中的端口映射如将3000:3000改为3001:3000。3. 检查.env文件确保变量值格式正确文件路径存在。Web界面无法访问1. 服务未成功启动。2. 防火墙/安全组阻止了端口访问。3. 容器内部服务崩溃。1.docker compose ps查看容器状态。2.curl -I http://localhost:3000在服务器内部测试。3.docker compose logs frontend查看前端日志。1. 根据日志修复错误后重启服务docker compose restart。2. 配置服务器防火墙和安全组放行对应端口如3000, 8000。3. 检查前端依赖或配置问题。扫描任务长时间无结果1. 网络问题无法访问外部API或目标。2. 扫描配置错误如目标格式不对。3. 任务队列Worker没有运行。1. 进入扫描器容器docker exec -it mangudai-scanner bash尝试ping或curl测试网络。2. 查看任务详情和日志docker compose logs scanner。3. 检查Worker服务状态。1. 确保服务器有外网访问能力检查DNS设置。2. 确认输入的资产目标是有效的域名或IP。3. 重启Worker服务docker compose restart worker。发现资产数量远少于预期1. 使用的免费数据源有限制或已失效。2. 扫描深度设置过浅。3. 目标域名设置了防护如CDN、子域名枚举防护。1. 检查配置文件中关于子域名发现模块的日志。2. 尝试使用多个不同的发现工具或配置。3. 手动使用其他工具如subfinder验证。1. 考虑配置更强大或付费的API密钥如SecurityTrails, Censys。2. 调整扫描策略增加字典或递归深度。3. 了解这是无代理扫描的固有局限可结合内部CMDB数据补充。API调用返回401/403错误1. API Token未提供或已过期。2. Token权限不足。3. 请求头格式错误。1. 检查代码中的API_TOKEN是否正确。2. 在Web界面重新生成Token并测试。3. 使用curl命令简化测试curl -H Authorization: Bearer TOKEN http://api-url/assets/。1. 使用正确的Token并确保其在请求头的Authorization字段中。2. 检查用户角色是否具有API访问权限。3. 参照官方API文档修正请求格式。数据库磁盘空间增长过快1. 扫描结果和历史数据积累。2. 日志未配置轮转。1.docker exec进入数据库容器查看表大小。2. 检查Docker卷的磁盘使用情况docker system df。1. 在Web界面或通过API定期清理历史扫描数据如果功能支持。2. 配置日志轮转策略。3. 考虑将数据库迁移至有更好管理功能的PostgreSQL。9. 最佳实践与使用建议为了让 Mangudai 在你的环境中稳定、有效且安全地运行遵循以下实践建议从小范围开始首次部署时不要一次性添加所有公司资产。先添加1-2个你完全掌控的测试域名或IP段验证整个流程发现、扫描、告警工作正常并观察资源消耗。仔细配置扫描策略速率限制务必设置合理的扫描延迟和并发数体现良好的“网络公民”意识避免对目标网络造成干扰。避开敏感时段将深度扫描安排在业务维护窗口。使用白名单如果某些IP或域名明确不需要扫描如第三方服务将其加入排除列表。资产标签化管理为资产打上标签如production、staging、aws、department-xx。这便于后续按环境、团队或重要性进行筛选、统计和制定不同的扫描策略。建立处理流程Mangudai 发现了风险然后呢建议建立闭环流程风险分级根据端口风险等级、证书过期紧急程度等对发现的问题进行分级。自动通知配置将中高风险问题自动推送到团队聊天工具如钉钉、飞书群。工单集成对于需要跟进处理的问题最好能自动创建Jira、Trello或内部工单并指派给相应的负责人如运维、开发。定期审计与复核误报处理定期查看已关闭的风险确认是真实修复还是误报。对于误报可以在系统中标记或添加规则排除提高未来报警的准确性。资产盘点每季度或每半年利用Mangudai生成的资产报告与团队的CMDB或资产清单进行交叉核对确保没有“幽灵资产”。安全与合规第一授权扫描再次强调扫描必须获得明确授权。将扫描范围严格限定在自有或已获书面授权的资产内。保护Mangudai自身Mangudai本身存储了资产和风险信息需确保其服务访问安全如设置强密码、启用HTTPS、限制访问IP。敏感信息处理Mangudai可能会发现暴露的敏感信息如调试页面、备份文件。对这些信息的处理要符合公司数据安全政策。10. 总结Mangudai 为小型技术团队提供了一个非常实用的攻击面管理入口。它的无代理架构使得部署和上手极其简单避免了在复杂异构环境中安装代理的麻烦。Docker Compose一键启动的特性让它在几分钟内就能跑起来快速看到效果。虽然其发现能力依赖于外部数据源和扫描但对于梳理互联网暴露资产、发现常见的配置疏忽如高危端口、过期证书已经足够。对于刚开始构建安全体系的团队我建议按以下路径尝试快速部署找一台测试服务器按照本文的Docker Compose步骤先把服务跑起来。功能验证添加一个你熟悉的测试域名完整走一遍“添加-扫描-查看结果-处理风险”的流程理解其工作模式。小范围试点选择一个非核心的业务系统或测试环境将其资产纳入监控跑1-2个扫描周期观察稳定性和准确性。流程集成尝试将其API与你们的运维通知系统如钉钉机器人打通实现风险自动告警。最容易踩的坑往往是网络配置容器无法访问外网和扫描策略过于激进导致IP被临时封锁。因此初期务必保守配置并密切关注日志。这个项目本身也在迭代中你可以关注其后续版本看是否会集成更多扫描引擎、提供更丰富的风险库以及更强大的报表功能。对于有开发能力的团队其开源特性也允许你们根据自身业务需求进行二次开发比如集成内部CMDB数据源或定制专属的风险检测规则。将攻击面管理自动化是迈向主动安全的第一步。Mangudai 提供了一个轻量级的起点建议收藏本文在需要时参照部署和配置。