1. 项目概述为什么我们需要一个开源的攻击面管理平台如果你是一名安全工程师、运维负责人或者正在管理一个拥有多个域名、服务器和云服务的团队那么“攻击面”这个词对你来说一定不陌生。简单来说攻击面就是你所有暴露在互联网上的资产它们就像你家房子的门窗数量越多、越不牢固被入侵的风险就越大。过去我们可能靠Excel表格手动记录IP和域名用几个独立的扫描器定期跑一下漏洞。但随着业务上云、微服务化、容器化资产变得动态、分散且数量庞大这种“手工业”模式彻底跟不上了。资产自己都说不清有哪些谈何安全这就是“攻击面管理”火起来的原因。它不是一个新工具而是一套从“看见”到“管理”的完整方法论和工程体系。核心目标就一个持续、自动化地发现、盘点、评估和收敛你暴露在外的所有数字资产风险。市面上的商业ASM平台功能强大但往往价格不菲且可能涉及数据合规问题。因此一个功能完备、能够自主掌控的开源攻击面管理平台对于许多技术团队而言有着巨大的吸引力。它意味着你可以用可控的成本构建一个贴合自身业务流、与内部系统深度集成的自动化安全运营中心。我最近花了不少时间研究和实践这类开源方案目标是搭建一套能自动发现资产、持续扫描漏洞、并量化风险的系统。这不仅仅是部署几个工具更是对现有安全运维流程的一次重塑。下面我就把自己从零搭建、踩坑、优化的全过程和核心思考分享出来希望能给同样在探索这条路的你提供一个可落地的参考框架。2. 核心架构设计与技术选型思路搭建一个ASM平台本质上是在构建一个自动化的工作流引擎。它的输入是各种可能的资产线索如公司主域名、IP段、证书透明度日志等经过一系列处理发现、识别、关联、评估最终输出结构化的资产清单和风险报告。整个架构可以拆解为四个核心层。2.1 数据采集与发现层这是整个系统的“眼睛”。目标是尽可能全地发现属于你的资产。单一数据源必然有遗漏必须多源互补。1. 被动发现无侵入式这种方式不会主动向目标发送探测包而是通过收集公开情报来发现资产非常隐蔽且不会对目标造成压力。子域名枚举这是最核心的起点。工具选型上subfinder、amass、assetfinder是主流。我推荐组合使用因为它们的底层数据源如Virustotal、SecurityTrails、Censys等API以及各类公开数据集各有侧重。可以将它们封装成一个任务定期对根域名进行扫描合并去重后得到子域名列表。证书透明度CT日志查询crt.sh是一个宝藏。任何申请了SSL/TLS证书的域名都会被记录在这里。通过查询你的组织名称、邮箱后缀常常能发现一些被遗忘的测试、临时域名。可以用curl配合jq解析crt.sh的API实现自动化查询。网络空间测绘引擎API如fofa、shodan、zoomeye、Censys。通过搜索特定的特征如备案号、公司名称、特有的HTTP标题、JS文件来发现资产。这部分需要API密钥且有查询频率限制适合作为补充和深度发现的手段。2. 主动发现有状态扫描在被动发现的基础上对存活的资产进行更深度的探测以识别其真实的服务、端口和技术栈。端口扫描nmap是毋庸置疑的王者。但对于大规模、高频度的扫描其速度是瓶颈。我的方案是先用masscan进行全端口高速扫描-p1-65535获取开放的端口列表再针对这些开放端口使用nmap进行精细化的服务和版本探测-sV。这样兼顾了速度和深度。Web应用指纹识别识别出Web服务后需要知道它是什么WordPressJenkinsK8s Dashboard。Wappalyzer的逻辑可以本地化但更高效的是使用nuclei的technologies模板或者专门的工具如whatweb、webanalyze。准确的指纹信息是后续漏洞扫描的重要前提。注意主动扫描务必谨慎必须在获得明确授权的前提下进行。扫描自己公司的资产没问题但绝对不要扫描任何非授权目标。错误的扫描可能触发对方的IDS/IPS甚至构成法律风险。建议在扫描策略上设置合理的延迟--max-rate和并发数。2.2 资产管理与关联层发现的海量原始数据IP、域名、端口、服务需要被清洗、去重、关联最终形成有业务意义的“资产”对象。这是从“数据”到“情报”的关键一步。1. 数据标准化与存储所有发现的数据需要存入一个中心化的数据库。简单项目可以用SQLite但考虑到资产数量可能上万且关系复杂我选择了PostgreSQL。设计几张核心表assets表核心资产表每条记录代表一个逻辑资产如一个Web应用。字段包括资产ID、名称、类型域名/IP、重要性等级、所属业务部门、负责人等。domain表存储域名信息与assets关联。ip_address表存储IP地址信息与assets关联。ports表存储端口扫描结果IP、端口、协议、服务、版本与ip_address关联。web_technologies表存储Web指纹信息与assets关联。2. 资产关联逻辑这是最体现工程能力的地方。一个IP上可能有多个域名虚拟主机一个域名可能解析到多个IPCDN、负载均衡。简单的ping或nslookup不够。域名解析关联定期对发现的域名进行A/AAAA/CNAME记录解析将解析到的IP与域名关联。注意处理CNAME链。反向解析关联对发现的IP进行PTR记录查询有时能发现未在正向枚举中的域名。证书关联从HTTPS服务中提取证书的Subject Alternative Name (SAN) 字段里面可能包含其他关联域名。内容关联爬取页面从JavaScript文件、注释、HTML标签中的链接发现新的主机名或API端点。通过以上关联我们才能回答“这个IP上到底跑了哪些业务”和“这个业务都部署在哪些IP上”这两个关键问题。2.3 漏洞评估与风险量化层资产清点完毕后需要对它们进行“体检”即漏洞扫描。这里要避免盲目全量扫而是基于资产信息进行精准、高效的扫描。1. 漏洞扫描引擎集成通用漏洞扫描nuclei是目前社区最活跃、模板最丰富的漏洞扫描器。它基于YAML模板覆盖了从CVE漏洞到错误配置、暴露敏感信息等各类风险。我将它作为核心扫描引擎通过调用其命令行传入目标列表进行扫描。Web专项扫描xray、goby等在Web漏洞发现方面有独特优势可以作为补充。对于关键的Web业务可以集成这些工具进行深度扫描。弱口令检测集成hydra或medusa针对常见的服务SSH, RDP, MySQL, Redis等进行弱口令爆破。这部分必须极其谨慎严格控制字典和频率最好在授权测试环境先行验证策略避免触发账号锁定。2. 风险量化模型扫描出一堆漏洞如何确定先修哪个需要一套简单的风险量化模型。一个可操作的模型是风险值 资产重要性权重 × 漏洞严重等级 × 可利用性系数资产重要性权重根据资产所属业务核心交易、内部管理、测试环境手动或自动打标分为高(3)、中(2)、低(1)。漏洞严重等级直接采用扫描器输出的等级如Critical, High, Medium, Low并映射为数字4,3,2,1。可利用性系数结合漏洞是否有公开EXP、是否在互联网暴露、是否需要认证等因素给予一个系数如1.5, 1.2, 1.0。计算后风险值高的工单优先推送给运维人员修复。这个模型虽然简单但能有效解决“海量漏洞无从下手”的困境。2.4 任务调度与自动化流水线上述所有步骤——发现、扫描、关联、评估——需要被有序地组织起来定期自动执行。这就是任务调度层的工作。1. 编排工具选型CeleryRedis是经典的分布式任务队列组合灵活但需要一定的开发量。对于更追求“开箱即用”的流水线体验我选择了Apache Airflow。Airflow 以DAG有向无环图的方式定义工作流每个步骤是一个Operator可视化程度高自带重试、报警、日志等功能。优势任务依赖关系清晰失败处理机制完善有Web UI便于监控。劣势资源消耗相对较大学习曲线略陡。2. 设计核心DAG我设计了一个主DAG按以下顺序执行子域名发现任务并行调用多个子域名枚举工具结果去重后存入数据库。域名解析任务对新增和已有的域名进行批量解析更新IP关联关系。端口扫描任务对新增和发生变化的IP进行masscannmap扫描。Web指纹识别任务对开放80/443等Web端口的服务进行指纹识别。漏洞扫描任务这是一个动态生成的任务组。Airflow 可以根据数据库中“待扫描”的资产列表动态创建多个并发的nuclei扫描子任务每个子任务处理一批资产极大提升扫描效率。报告生成任务汇总本次扫描周期的所有发现和漏洞生成HTML或Markdown格式的报告并通过邮件或Webhook发送到钉钉/飞书群。这个DAG可以设置为每天或每周定时执行实现真正的“7x24小时自动化攻击面监控”。3. 关键模块的实操部署与配置细节理论讲完我们进入实战环节。我会以最典型的组合为例展示如何部署和配置核心模块。3.1 基于SubfinderAmass的资产发现模块部署这两个工具是子域名发现的黄金搭档。建议在Linux服务器上部署。1. 安装与配置# 安装Go语言环境如果尚未安装 wget https://golang.org/dl/go1.21.0.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.21.0.linux-amd64.tar.gz echo export PATH$PATH:/usr/local/go/bin ~/.bashrc source ~/.bashrc # 安装 subfinder go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinderlatest sudo cp ~/go/bin/subfinder /usr/local/bin/ # 安装 amass go install -v github.com/owasp-amass/amass/v3/...master sudo cp ~/go/bin/amass /usr/local/bin/2. 配置API密钥为了获得更好的发现效果需要配置一些免费的商业API密钥。编辑~/.config/subfinder/provider-config.yamlbinaryedge: - api-key-here censys: - api-id-here - api-secret-here certspotter: [] # ... 其他配置对于amass将密钥写入~/.config/amass/config.ini。这些密钥可以从它们的官网申请通常有免费的额度对于个人或中小规模扫描足够使用。3. 编写发现脚本创建一个discover.sh脚本实现多工具调用和结果合并#!/bin/bash DOMAIN$1 DATE$(date %Y%m%d) OUTPUT_DIR./results/$DATE mkdir -p $OUTPUT_DIR echo [*] 开始发现子域名: $DOMAIN # 1. 使用 subfinder subfinder -d $DOMAIN -silent -o $OUTPUT_DIR/subfinder.txt # 2. 使用 amass (被动模式) amass enum -passive -d $DOMAIN -o $OUTPUT_DIR/amass.txt # 3. 合并、去重、排序 cat $OUTPUT_DIR/subfinder.txt $OUTPUT_DIR/amass.txt | sort -u $OUTPUT_DIR/all_subdomains.txt echo [] 发现完成。共找到 $(wc -l $OUTPUT_DIR/all_subdomains.txt) 个子域名。结果保存在: $OUTPUT_DIR/all_subdomains.txt运行./discover.sh example.com即可启动发现。实操心得免费API有速率限制在脚本中最好加入sleep间隔避免被禁。对于非常重要的资产可以考虑购买一些数据源的商业订阅数据质量和数量会提升一个档次。3.2 集成Nuclei进行精准漏洞扫描Nuclei的强大在于其社区模板。我们需要保持模板更新并设计高效的扫描策略。1. 安装与模板更新# 安装 nuclei go install -v github.com/projectdiscovery/nuclei/v2/cmd/nucleilatest sudo cp ~/go/bin/nuclei /usr/local/bin/ # 首次运行自动下载最新模板到 ~/.local/nuclei-templates nuclei # 后续更新模板 nuclei -update-templates2. 编写扫描脚本直接对成千上万个目标进行全模板扫描是不现实的耗时且会产生大量无关结果。应该根据资产指纹进行针对性扫描。#!/bin/bash TARGETS_FILE$1 # 输入目标文件每行一个URL OUTPUT_FILE./scan_results/nuclei_$(date %s).json # 策略先进行快速、低侵入的扫描再针对特定技术栈深度扫描 echo [*] 阶段1: 扫描信息泄露、配置错误等低风险模板 (tags: config, exposure, misconfig) nuclei -l $TARGETS_FILE -t ~/.local/nuclei-templates/ -tags config,exposure,misconfig -severity low,medium,high,critical -o $OUTPUT_FILE -json # 假设我们有一个文件记录了资产的技术栈例如 wordpress_assets.txt if [ -f wordpress_assets.txt ]; then echo [*] 阶段2: 针对WordPress资产进行深度扫描 nuclei -l wordpress_assets.txt -t ~/.local/nuclei-templates/technologies/wordpress/ -severity medium,high,critical -o $OUTPUT_FILE -json -merge fi echo [] 扫描完成。结果已保存至: $OUTPUT_FILE3. 结果解析与入库Nuclei的JSON输出结构清晰可以编写一个Python脚本解析结果并存入之前设计的PostgreSQL漏洞表中。关键字段包括host,info.name漏洞名称,info.severity等级,info.description,matcher-name匹配的模板等。注意事项Nuclei模板社区贡献者众多质量参差不齐。在正式用于生产环境前务必在测试环境中验证模板的准确性和可靠性避免误报干扰团队。可以建立一个“已验证模板库”只使用经过确认的模板。3.3 使用Airflow编排自动化流水线这是将各个模块串联成自动化系统的“大脑”。1. 安装Airflow使用官方推荐的pip安装方式并选择PostgreSQL作为元数据库。# 设置Airflow家目录和Python路径 export AIRFLOW_HOME~/airflow pip install apache-airflow[postgres,celery] --constraint https://raw.githubusercontent.com/apache/airflow/constraints-2.7.0/constraints-3.8.txt # 初始化数据库 airflow db init # 创建管理员用户 airflow users create \ --username admin \ --firstname Admin \ --lastname User \ --role Admin \ --email adminexample.com # 启动Web服务器和调度器 airflow webserver --port 8080 -D airflow scheduler -D访问http://your-server-ip:8080即可看到Airflow UI。2. 编写资产发现DAG在$AIRFLOW_HOME/dags目录下创建asm_asset_discovery.py。from datetime import datetime, timedelta from airflow import DAG from airflow.operators.bash import BashOperator from airflow.operators.python import PythonOperator import sys sys.path.append(/path/to/your/scripts) from db_utils import save_subdomains_to_db # 假设你有一个处理数据库的模块 default_args { owner: security, depends_on_past: False, start_date: datetime(2023, 10, 1), email_on_failure: True, email_on_retry: False, retries: 1, retry_delay: timedelta(minutes5), } dag DAG( asm_asset_discovery, default_argsdefault_args, description自动发现和更新资产, schedule_intervaltimedelta(days1), # 每天执行一次 catchupFalse, ) # 任务1: 执行子域名发现脚本 discover_task BashOperator( task_idrun_subdomain_discovery, bash_commandcd /opt/asm-scripts ./discover.sh example.com , dagdag, ) # 任务2: 解析结果并存入数据库 (依赖任务1) def process_discovery_results(**context): # 这里可以读取 discover.sh 生成的結果文件 result_file /opt/asm-scripts/results/latest/all_subdomains.txt with open(result_file, r) as f: subdomains [line.strip() for line in f if line.strip()] # 调用自定义函数将子域名列表存入数据库并标记为新发现的 save_subdomains_to_db(subdomains, sourcedaily_scan) return fProcessed {len(subdomains)} subdomains. process_task PythonOperator( task_idprocess_and_store_results, python_callableprocess_discovery_results, dagdag, ) # 任务3: 对新发现的域名进行解析和端口扫描 (依赖任务2) portscan_task BashOperator( task_idrun_port_scan_for_new_assets, bash_commandcd /opt/asm-scripts python3 port_scanner.py --targets new, # 假设这个脚本会从DB读取“新资产”进行扫描 dagdag, ) # 定义任务依赖关系 discover_task process_task portscan_task通过Airflow UI你可以清晰地看到这个DAG的运行状态、日志和任务依赖图。4. 常见问题、性能优化与避坑指南在实际搭建和运行过程中你会遇到各种各样的问题。下面是我踩过的一些坑和总结的优化经验。4.1 扫描性能与资源瓶颈问题全端口扫描或大规模HTTP探测时速度慢占用大量网络和CPU资源甚至可能影响线上业务。解决方案分层分级扫描不要每次都扫全部。将资产分为核心、重要、一般等级别。核心资产每天全端口扫一般资产每周只扫常见端口如top 1000。合理配置扫描参数masscan: 使用--max-rate 1000限制发包速率避免打满带宽。使用-p1-65535但配合--excludefile排除已知的不可能开放的端口段。nmap: 使用-T4加速时序对于大量目标使用-n禁止DNS解析可后续单独做。nuclei: 使用-c 50控制并发线程数使用-rl 150限制每秒请求数做个“文明”的扫描器。分布式扫描如果资产数量极大数万IP以上考虑分布式架构。可以用Celery或自己写一个简单的任务分发系统让多个扫描节点从中心队列领取任务。Airflow的CeleryExecutor也能实现一定程度的分布式任务执行。4.2 数据去重与资产关联混乱问题同一个物理服务器因为CDN、负载均衡而有多个IP同一个服务因为容器化而IP频繁变化导致资产数据重复、关系混乱。解决方案定义“唯一资产”标识不要单纯用IP或域名作为资产唯一标识。可以尝试组合业务系统名 主要访问入口域名。IP和端口作为该资产的“属性”而非“身份”。引入“资产标签”系统为资产打上标签如env:production,team:infra,platform:k8s。通过标签来管理和筛选比硬编码的字段更灵活。建立变更审计记录资产每一次的端口、服务、指纹变更。这不仅能用于关联历史还能发现异常变动例如测试环境的服务突然出现在生产IP上。4.3 漏洞误报与告警疲劳问题扫描器报出一大堆漏洞但很多是误报或者是不影响当前环境的低危漏洞导致安全团队和运维团队产生“告警疲劳”忽视真正的威胁。解决方案建立漏洞验证流程对于高风险漏洞不能直接提单。安全团队需要人工或通过自动化POC脚本进行验证确认其真实存在且可利用。设置漏洞白名单/例外对于已确认是误报、已接受风险或已有其他控制措施的漏洞在平台中设置白名单避免重复告警。但必须附上理由和有效期。告警分级与聚合不要一个漏洞发一个告警。可以按“资产”或“漏洞类型”进行聚合每天或每周发送一份摘要报告。对于紧急的、可远程利用的Critical漏洞则立即通过电话或即时通讯工具通知。与CMDB/ITSM集成将确认的漏洞自动创建为运维工单如Jira Ticket并指派给相应的资产负责人。打通修复流程形成闭环。4.4 系统的可持续运营与维护问题系统搭建时热火朝天但运行一段时间后因为无人更新规则、无人处理告警、扫描脚本失效而荒废。解决方案文档与交接详细记录系统的架构、部署步骤、配置项、数据流和运维手册。这是项目可持续的基础。定期维护日历将以下事项列入日历每周更新一次nuclei模板和所有子域名发现工具的源。每月检查一次各个API密钥的额度。每季度回顾一次扫描策略和资产分类规则根据业务变化进行调整。指标监控监控系统本身监控扫描任务的执行成功率、平均耗时、数据库增长情况、API调用失败率等。系统自身的健康度决定了它能否长期提供服务。搭建一个开源ASM平台是一个典型的“DevSecOps”工程实践。它没有银弹需要你根据自身的技术栈、业务规模和安全需求不断调整和迭代。从最简单的“定期跑脚本发邮件”开始逐步加入资产库、工作流、风险量化最终形成一个与你的云平台、CI/CD管道、运维体系深度集成的安全基础设施。这个过程本身就是对团队安全能力的一次彻底升级。
