1. 为什么我要把端口扫描和LLM红队塞进同一个平台做安全的人大概都有这种体会工具越攒越多nmap、masscan、httpx、nuclei、sqlmap每个都单独跑扫完一轮下来资产清单在txt里漏洞结果在json里报告还得手动拼。更麻烦的是扫出来的东西越来越多真正需要人判断的那部分——比如某个端口暴露的服务到底有没有实际风险、某条报错信息是不是泄露了内部路径——反而被淹没在几千行输出里。我搭这个全栈安全作战平台的出发点很直接把“机器能干的活”交给扫描器把“需要判断的活”交给大模型中间用一条流水线串起来。这个平台的核心链路是资产发现 → 端口扫描 → 服务识别 → 指纹匹配 → 漏洞初筛 → LLM红队分析 → 报告生成。前半段是传统安全工具的主场后半段是AI大模型发挥的地方。我把它叫做“作战平台”而不是“扫描器”是因为它不只是扫还要做研判、做优先级排序、做攻击路径推演。适合谁看有一定安全基础、想把自己手头的零散工具整合成流水线的朋友也适合对AI大模型应用开发感兴趣、想找一个真实落地场景练手的人。哪怕你只是想知道“32G内存能不能跑本地大模型”这种问题后面我也会给实测数据。先说清楚一件事这个平台是自用和授权测试场景下的工具所有扫描行为都必须在你拥有明确授权的目标上进行。这一点不展开但它是前提。2. 整体架构设计与技术选型思路2.1 为什么采用“扫描器 大模型”双引擎而不是纯AI一开始我也想过能不能直接让大模型去“看”目标让它自己判断哪里有漏洞。实测下来这条路走不通原因有两个。第一大模型没有主动发起网络请求的能力它只能基于你喂给它的文本做推理你不可能让它自己去连一个端口。第二大模型的上下文窗口有限你把一个C段的扫描结果全塞进去它要么截断要么开始胡说。所以正确的分工是扫描器负责“采集事实”大模型负责“解读事实”。这个分工背后有个很重要的原则事实归工具判断归模型。端口开没开、banner是什么、HTTP响应头有哪些这些是客观事实用nmap、httpx这类工具拿到的结果比大模型猜的准一万倍。而“这个暴露的Redis未授权访问风险有多高”“这条报错信息可能对应什么类型的漏洞”“这几个低危漏洞组合起来能不能形成一条攻击链”这些是判断才是大模型的价值所在。我试过反过来让大模型直接根据域名猜开放端口结果它给我编了一个“通常80和443是开的”这种输出毫无意义。所以架构上必须坚持双引擎。2.2 全栈平台的分层结构整个平台我分成四层从下往上依次是采集层nmap做端口和service探测masscan做大规模快速扫描httpx做HTTP服务存活和指纹subfinder做子域名枚举。这一层全是命令行工具用Python的subprocess封装调用。处理层把各工具的输出统一成JSON格式做去重、归一化、关联。比如nmap扫到8080端口开放httpx确认是Tomcat处理层就把这两条信息合并成一条资产记录。分析层这是大模型介入的地方。把处理后的资产数据按目标分组构造prompt调用大模型做风险研判、漏洞推演、报告生成。展示层一个简单的Web界面用FastAPI做后端前端就是原生HTMLJS不搞复杂框架够用就行。为什么不用现成的扫描平台因为现成的平台要么太重要么不开放大模型接口。自己搭的好处是每一层都能按需替换比如你今天想换个指纹库明天想换个模型改一个模块就行。2.3 大模型选型本地部署还是调用API这是被问得最多的问题。我的建议是分场景场景推荐方案理由敏感目标、内网资产本地部署数据不出本地合规公开资产、批量扫描API调用省算力模型能力强学习练手本地小模型成本低可反复折腾生产环境高并发API 本地缓存平衡成本和速度本地部署这块我实测过几个配置。32G内存的机器跑7B级别的模型4bit量化是够的大概占用6-8G显存或内存推理速度在消费级显卡上能到每秒20-40个token。14B的模型4bit量化需要大概10-12G32G内存也能扛但速度会慢一些。再往上70B就别想了除非你有A100。所以“32G内存能装AI大模型”这个问题的答案是能装7B到14B的量化版本日常研判够用但别指望它有多强的推理能力。我自己的配置是本地跑一个14B的量化模型做初步研判和脱敏把脱敏后的结果再送给云端大模型做深度分析。这样既保证了敏感信息不外泄又利用了云端模型更强的能力。3. 核心模块拆解与实操要点3.1 端口扫描模块nmap和masscan怎么配合端口扫描是整个流水线的入口扫不全后面全白搭。我的做法是masscan打头阵nmap做精扫。masscan的优势是快扫一个B段的全端口1-65535在千兆网环境下大概几分钟。但它的缺点是服务识别能力弱只能告诉你端口开没开。所以流程是# 第一步masscan快速发现开放端口 masscan -p1-65535 --rate1000 -iL targets.txt -oJ masscan_result.json # 第二步提取开放端口交给nmap精扫 nmap -sV -sC -p 提取的端口列表 -iL targets.txt -oX nmap_result.xml这里有个坑要注意masscan的--rate参数不要设太高1000是相对安全的设到10000以上容易丢包反而扫不全。我试过用5000的rate扫一个C段结果漏了三个端口降到1000重扫就全了。另外masscan和nmap不要同时跑会互相干扰串行执行。nmap的-sV做版本探测-sC跑默认脚本这两个组合能拿到大部分服务的banner和基本信息。但-sC的脚本有些会触发目标告警授权测试里没问题但如果你不确定授权范围建议只用-sV。3.2 服务识别与指纹匹配httpx和自建指纹库端口开了不代表服务活着尤其是Web服务。httpx的作用就是确认HTTP/HTTPS服务是否真的在响应并提取标题、状态码、技术栈指纹。httpx -l urls.txt -title -status-code -tech-detect -json -o httpx_result.json-tech-detect用的是Wappalyzer的指纹库能识别出大部分常见CMS、框架、中间件。但实际用下来它的准确率大概在70%左右有些自研系统或者改过banner的服务识别不出来。所以我在处理层加了一个自建指纹库用正则匹配banner里的特征字符串。比如banner里有“Server: Apache-Coyote/1.1”就标记为Tomcat有“X-Powered-By: ThinkPHP”就标记为ThinkPHP。指纹匹配的优先级是自建库 httpx tech-detect 端口默认服务。因为自建库是我根据实际遇到的系统慢慢攒的针对性更强。3.3 LLM红队分析模块prompt怎么设计才不胡说这是整个平台最核心也最难调的部分。大模型不是安全专家你直接问它“这个目标有什么漏洞”它要么给你一堆泛泛而谈要么开始编造。我的经验是prompt必须做到三件事限定角色、提供事实、约束输出格式。我用的系统prompt大概长这样你是一名资深渗透测试工程师正在对授权目标进行安全评估。 你只能基于以下提供的事实信息进行分析不得编造任何未提供的信息。 如果信息不足以判断明确说明“信息不足建议进一步探测”。 事实信息 - 目标IP{ip} - 开放端口{ports} - 服务版本{services} - HTTP响应头{headers} - 页面标题{title} - 已知指纹{fingerprints} 请按以下格式输出 1. 风险点列表每条包含风险描述、依据的事实、风险等级高/中/低 2. 建议的下一步探测动作具体到工具和参数 3. 如果发现多个风险点分析它们之间是否存在组合利用可能这个prompt的关键在于“只能基于事实”和“信息不足要说明”。我试过不加这两条约束模型会自己脑补出“该服务器可能存在心脏滴血漏洞”这种没有依据的结论。加上约束后输出质量明显提升虽然偶尔还是会跑偏但至少不会凭空捏造。还有一个技巧是分步分析。不要一次性把所有资产丢给模型而是按目标分组每个目标单独分析。这样上下文更聚焦模型不容易混淆。如果目标很多可以先用一个轻量模型做初筛把明显没风险的过滤掉再把有疑点的送给大模型深度分析。3.4 报告生成从JSON到可读报告扫描结果最终要变成人能看的报告。我的做法是让大模型基于分析结果生成Markdown格式的报告包含执行摘要、资产清单、风险详情、修复建议四个部分。执行摘要用自然语言概括整体风险状况资产清单用表格呈现风险详情按等级排序修复建议要具体到操作步骤。这里有个细节修复建议不要让模型自由发挥而是给它一个知识库。我整理了一份常见漏洞的修复方案库模型生成建议时先从库里检索检索不到再让它自己写。这样既保证了建议的准确性又保留了灵活性。4. 完整实操流程从零跑通一条扫描链路4.1 环境准备与依赖安装先列一下我用的环境操作系统Ubuntu 22.04本地部署模型的话建议用这个驱动兼容性好Python3.10核心工具nmap 7.94、masscan 1.3.2、httpx 1.3.7、subfinder 2.6.3大模型本地用Ollama跑qwen2.5:14b云端用某API这里不具体说哪家避免广告嫌疑安装依赖# 安装Python依赖 pip install fastapi uvicorn requests jinja2 python-nmap # 安装Ollama本地模型 curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:14b # 验证模型可用 ollama run qwen2.5:14b 你好如果你的机器内存只有16G建议换成7B的模型14B会有点吃力。32G内存跑14B量化版是舒服的我实测推理时内存占用在12G左右留了足够余量给扫描工具。4.2 扫描流水线的串联整个流水线我用一个Python脚本串起来核心逻辑是import subprocess import json def run_masscan(targets): # 执行masscan返回开放端口 cmd fmasscan -p1-65535 --rate1000 -iL {targets} -oJ masscan.json subprocess.run(cmd, shellTrue, checkTrue) with open(masscan.json) as f: return json.load(f) def run_nmap(targets, ports): # 用nmap精扫 port_str ,.join(str(p) for p in ports) cmd fnmap -sV -p{port_str} -iL {targets} -oX nmap.xml subprocess.run(cmd, shellTrue, checkTrue) # 解析XML这里省略解析代码 return parse_nmap_xml(nmap.xml) def run_httpx(urls): cmd fhttpx -l {urls} -title -status-code -tech-detect -json -o httpx.json subprocess.run(cmd, shellTrue, checkTrue) with open(httpx.json) as f: return [json.loads(line) for line in f] def analyze_with_llm(asset_data): # 构造prompt调用大模型 prompt build_prompt(asset_data) response call_ollama(prompt) return response这个脚本跑一轮完整流程对一个C段254个IP的全端口扫描大概耗时masscan 5分钟nmap精扫 15分钟httpx 3分钟LLM分析 2分钟本地14B模型。总共25分钟左右。如果用云端APILLM分析能压缩到30秒以内。4.3 大模型调用的参数配置调用本地Ollama的代码import requests def call_ollama(prompt, modelqwen2.5:14b): url http://localhost:11434/api/generate payload { model: model, prompt: prompt, stream: False, options: { temperature: 0.3, # 低温度减少随机性 top_p: 0.9, num_predict: 2048 # 限制输出长度 } } resp requests.post(url, jsonpayload) return resp.json()[response]temperature设0.3是关键安全分析需要确定性不能让它自由发挥。我试过0.7同样的输入两次输出差异很大有的甚至互相矛盾。0.3就稳定多了。num_predict限制2048是为了防止模型输出太长实际分析结果一般1000字以内就够了。4.4 结果展示与报告输出Web界面我用FastAPI搭了一个简单的API前端用fetch调用。核心接口就三个/scan触发扫描、/status查进度、/report拿报告。报告用Jinja2模板渲染成HTML同时导出Markdown版本方便复制。报告里的风险等级我用颜色区分高危红色、中危橙色、低危黄色、信息蓝色。这个颜色映射是写死在模板里的不依赖模型输出避免模型把等级写错导致颜色混乱。5. 踩坑记录与常见问题排查5.1 大模型“幻觉”问题怎么压制这是最头疼的问题。即使加了“只能基于事实”的约束模型偶尔还是会编。我遇到过的典型幻觉包括编造不存在的CVE编号、把低危说成高危、建议的修复方案根本不可行。压制幻觉的手段我总结了三条第一事实信息结构化。不要用自然语言描述扫描结果而是用JSON格式喂给模型。结构化数据模型更难“误解”。比如不要写“目标开了80端口是nginx”而是写{port: 80, service: nginx, version: 1.18.0}。第二要求模型引用依据。在prompt里明确要求“每条风险必须引用具体的事实信息作为依据”。这样模型编造的时候会露馅因为它找不到对应的事实。第三后置校验。模型输出后用一个规则引擎做校验。比如模型说“存在CVE-2021-44228漏洞”规则引擎检查事实信息里有没有log4j的指纹没有就标记为“待人工确认”。这一步能过滤掉大部分幻觉。5.2 扫描速度与准确率的平衡masscan的rate、nmap的timing、httpx的并发数这三个参数直接影响扫描速度和准确率。我的经验值工具参数推荐值说明masscan--rate1000再高容易丢包nmap-T4T5太快会漏T3太慢httpx-threads50再高容易被封httpx-timeout10默认5秒太短这些值不是绝对的要根据目标网络质量调整。内网可以适当提高公网建议保守一点。我试过httpx开200并发扫公网结果一半的请求超时降到50就正常了。5.3 常见问题速查表问题现象可能原因解决方法masscan扫不到端口rate太高丢包降到1000重扫nmap -sV识别不出服务目标改了banner用自建指纹库补充httpx全部超时并发太高或被封降并发、加代理池大模型输出乱码上下文超限减少输入数据量大模型编造CVE幻觉加事实约束后置校验本地模型推理慢模型太大换7B或用量化版报告生成失败模板变量缺失检查JSON字段完整性5.4 几个独家避坑技巧技巧一扫描前先做存活探测。不要直接对整段做全端口扫描先用ping或TCP SYN探测筛出存活主机能省一半时间。我用的是nmap -sn做存活探测虽然慢一点但准确。技巧二大模型分析分批进行。一次不要超过10个目标否则上下文太长模型会“忘记”前面的内容。我试过一次性喂30个目标结果模型只分析了最后几个前面的直接忽略了。技巧三报告里的修复建议要人工过一遍。模型给的修复建议大部分是对的但偶尔会有“重启服务”这种万能答案。我现在的做法是模型生成后用关键词匹配检查是否包含具体操作步骤没有的话标记出来人工补充。技巧四本地模型和云端模型搭配用。本地模型做初筛和脱敏云端模型做深度分析。这样既保护了敏感数据又保证了分析质量。脱敏的规则很简单把IP替换成[IP_1]、[IP_2]把域名替换成[DOMAIN_1]分析完再替换回来。6. 平台后续可扩展的方向这个平台目前跑通的是“扫描→分析→报告”的主链路但安全作战远不止这些。我接下来打算加两个模块。一个是持续监控。现在的扫描是一次性的扫完就完了。实际场景里资产是变化的今天开的端口明天可能关了今天没漏洞明天可能上了新服务。我打算加一个定时任务每天凌晨跑一轮对比前一天的结果只把变化的部分送给大模型分析。这样既省算力又能及时发现新风险。另一个是攻击路径推演。现在的大模型分析是单目标独立的但实际上攻击往往是链式的从A目标的信息泄露拿到凭据用凭据登录B目标再从B目标横向到C目标。我打算把多个目标的分析结果汇总让大模型做跨目标的路径推演。这个难度比较大因为需要模型理解目标之间的网络关系但值得尝试。还有一个方向是接入更多扫描器。现在只集成了nmap、masscan、httpx后面想加nuclei做漏洞模板扫描、加sqlmap做注入检测。每加一个工具处理层就多一个数据源大模型的分析依据就更充分。但要注意的是工具越多噪声越大去重和关联的逻辑要跟上否则大模型会被垃圾数据淹没。最后说一个实际体会这个平台最大的价值不是自动化而是把人的注意力从“找问题”转移到“判断问题”。以前扫完一轮要花几个小时看结果现在大模型把明显没风险的过滤掉把有疑点的标出来我只需要看那几条就行。效率提升是实实在在的。但也要清醒认识到大模型目前还替代不了人的判断它更像一个不知疲倦的初级分析师能帮你做初筛但最终决策还得自己来。