1
月
在社区成长 1 月
LEVEL 1
1 XP
一、背景与问题定义
在安全运营、代码审计和威胁分析场景中，大模型最适合承担“信息整理、上下文关联、初步研判和报告生成”，而不应被当作可以独立做出最终安全结论的黑盒扫描器。实际环境中的日志数量大、字段不统一、告警重复率高，安全分析人员往往需要在多个系统之间反复查询：终端告警、身份认证日志、Web 访问日志、漏洞库、资产清单以及历史处置记录彼此割裂。大模型可以帮助分析人员把这些信息组织成时间线，并基于内部知识库给出可解释的研判建议。
本文以一个完全本地、可授权的实验环境为例，搭建一个面向安全运营的威胁分析助手。目标不是让模型自动封禁 IP 或直接修改生产配置，而是让它完成以下任务：一是从结构化日志中提取实体和行为；二是关联内部处置手册与漏洞知识；三是区分事实、推断和未知信息；四是输出可复核的风险评分、证据链和下一步建议。整个流程强调最小权限、数据脱敏、检索增强、规则校验和人工审批。
二、总体原理
一个可靠的安全分析链路可以拆成五层。
第一层是数据采集层。收集本地靶场中的身份认证日志、Web 服务器访问日志、主机检测日志和资产信息。采集时保留事件时间、主机、账号、源地址、动作、结果等必要字段，避免把无关的个人信息直接送入模型。
第二层是规范化层。不同系统的字段名称和时间格式通常不一致，需要统一为内部事件模型。例如将 user、username、account 统一为 account，将 src_ip、client_ip 统一为 source_ip，并将时间转换为 UTC 或统一时区。没有规范化，模型很容易把同一事件误认为多个事件。
第三层是检索增强层，也就是 RAG。把经过审核的内部材料切分并建立向量索引，例如告警处置手册、资产重要性说明、漏洞验证标准、账号异常判定规则和历史复盘报告。模型回答时只能把检索结果作为参考，并要求引用文档名称、版本和段落，而不是凭记忆生成结论。
第四层是分析与校验层。模型负责生成候选结论，但风险分数、时间窗口、IP 格式、事件数量和是否满足规则，应由确定性代码进行校验。例如模型说“同一账号在十分钟内从两个国家登录”，程序必须自行读取结构化事件并验证，而不能只相信模型的自然语言描述。
第五层是处置层。高风险操作必须进入人工审批队列。模型可以建议“暂时提高监控级别”或“请求值班人员复核”，但不能直接执行隔离主机、删除账号、修改防火墙规则等破坏性动作。对于实验环境，也建议先使用模拟动作和 dry-run 模式。
三、前置条件
1. 一台本地 Linux 主机或虚拟机，建议至少 8 GB 内存；如果使用较大的本地模型，应根据模型规模增加内存或显存。
2. Python 3.10 及以上版本，Docker 可选。
3. 一个本地推理服务，例如 Ollama、llama.cpp server 或其他兼容 OpenAI API 的推理服务。模型只需要具备较好的中文理解、结构化输出和长文本处理能力。
4. 一批自建的脱敏日志，禁止直接使用生产中的账号、Cookie、令牌、客户数据或内部密钥。
5. 一个经过审核的知识库目录，例如 docs/response_playbook、docs/asset_policy 和 docs/vulnerability_notes。
6. 明确的实验授权范围。本文所有测试均针对本地文件、模拟日志和授权靶场，不针对任何真实互联网目标。
四、构造本地实验数据
先创建目录：
mkdir -p security-lab/{logs,docs,output}
创建一份模拟认证日志 logs/auth.jsonl，每行一个 JSON 事件：
{"ts":"2025-01-15T09:00:00Z","account":"alice","source_ip":"192.0.2.10","country":"CN","result":"success","host":"vpn-lab-01"}
{"ts":"2025-01-15T09:06:00Z","account":"alice","source_ip":"198.51.100.20","country":"US","result":"success","host":"vpn-lab-01"}
{"ts":"2025-01-15T09:07:00Z","account":"alice","source_ip":"198.51.100.20","country":"US","result":"failed","host":"vpn-lab-01"}
其中 192.0.2.0/24 和 198.51.100.0/24 是文档示例地址，适合实验使用。再创建一份处置手册 docs/response_playbook.md，明确写出内部规则，例如：同一账号在十五分钟内从不同地理区域成功登录，标记为“需要复核”，但不能直接认定为账号被盗；VPN 出口、代理和移动网络可能造成地理位置误判；只有在设备指纹、登录时间和行为序列等证据一致时，才可以提高置信度。
五、实施一个最小可用分析器
安装基础依赖：
python -m venv .venv
source .venv/bin/activate
pip install requests pydantic python-dateutil
如果使用本地推理服务，可以让服务监听本机地址，例如 http://127.0.0.1:11434。下面的示例采用兼容聊天接口的形式，重点展示数据边界和校验方法，而不是绑定某个具体模型。
首先编写确定性规则，避免让模型自行计算关键事实：
from datetime import datetime
from dateutil.parser import isoparse
import json
def load_events(path):
events = []
with open(path, encoding="utf-8") as f:
for line in f:
if line.strip():
events.append(json.loads(line))
return events
def find_impossible_travel(events, window_minutes=15):
groups = {}
for event in events:
if event.get("result") != "success":
continue
groups.setdefault(event.get("account"), []).append(event)
findings = []
for account, items in groups.items():
items.sort(key=lambda x: isoparse(x["ts"]))
for left, right in zip(items, items[1:]):
delta = (isoparse(right["ts"]) - isoparse(left["ts"])).total_seconds() / 60
if delta <= window_minutes and left.get("country") != right.get("country"):
findings.append({
"type": "different_country_success",
"account": account,
"first": left,
"second": right,
"window_minutes": delta
})
return findings
这里的规则只生成“不同国家成功登录”这一事实，不直接生成“账号已失陷”。这是一个非常重要的边界：检测事实和安全结论必须分开。后续可以增加设备指纹、ASN、VPN 标识、失败次数和资产敏感等级等字段，但每一项都应有来源。
六、接入 RAG 的安全方式
知识库不要直接把所有文件拼接到提示词中。推荐先按标题、段落和版本切分，建立元数据，例如文档名称、发布日期、适用产品、审核人和失效时间。检索时使用“事件类型、资产标签、账号类型和关键词”组成查询，并保留少量高相关片段。
提示词可以采用如下结构：
系统要求：你是安全运营分析助手。只能根据输入事件和提供的知识片段进行分析。必须把结果分为“已确认事实”“合理推断”“尚未确认”。禁止编造不存在的日志字段、漏洞编号、用户身份或处置结果。不要执行任何系统操作。若证据不足，必须明确说明需要补充哪些数据。
输入事件：放入经过字段筛选的 JSON。
规则计算结果：放入程序已经验证的 findings。
知识片段：放入带有文档名和版本的检索结果。
输出格式：事件摘要、证据列表、风险等级及理由、误报可能性、建议补充的数据、建议处置动作、引用文档。
在生产实现中，建议使用 Pydantic 或 JSON Schema 验证模型输出。例如风险等级只能是 low、medium、high、unknown，建议动作只能从“继续观察”“人工联系账号所有者”“提高日志采样”“创建工单”等枚举值中选择。任何不符合 schema 的结果都应进入重试或人工队列，而不是直接写入工单系统。
七、把模型输出变成可审计结果
每次分析至少保存以下内容：输入事件的哈希值、数据时间范围、检索到的文档版本、提示词模板版本、模型名称、模型输出、规则校验结果、人工最终结论和处置时间。这样在误报或漏报复盘时，可以回答“模型当时看到了什么”和“知识库当时是什么版本”。不要只保存最终摘要，否则无法定位问题来自数据、检索、提示词还是模型本身。
可以使用如下命令对输出进行基本检查：
python -m json.tool output/analysis.json
sha256sum logs/auth.jsonl output/analysis.json
如果结果需要写入 SIEM 或工单系统，先写入隔离队列，由人工确认后再流转。对于批量分析任务，应设置单次最大日志条数、最大输入字符数和超时限制，防止异常日志导致资源耗尽。
八、评测方法
安全场景不能只看文本是否通顺。建议建立包含正常登录、共享出口、VPN 切换、撞库模拟日志、服务账号批量任务和时间戳异常等案例的评测集。每个案例标注事实字段、正确风险等级、允许的处置建议和不应出现的结论。
重点指标包括：事实抽取准确率、关键字段遗漏率、风险等级宏平均 F1、证据引用正确率、无依据断言率、结构化输出通过率和人工采纳率。对于高风险场景，还要单独统计“危险建议率”，例如模型是否在证据不足时建议禁用账号。评测集应定期加入线上复盘案例，但必须先脱敏。
可以采用双重判定：规则程序判断关键事实是否正确，安全人员判断解释和建议是否合理。不要使用另一个大模型作为唯一裁判，因为模型之间可能共享同样的偏差。
九、风险与注意事项
第一，提示词注入。日志、工单或提交内容可能包含“忽略之前规则”等文本。所有外部文本都必须被视为不可信数据，放在明确的数据区，不允许改变系统规则。检索文档也需要审核和版本控制。
第二，敏感信息泄露。账号、邮箱、内网域名、令牌和源代码都应尽量脱敏。尤其不能把 SSH 私钥、云平台密钥、Cookie 和完整客户数据放入调试日志。推理服务、向量库和监控系统应设置访问控制。
第三，自动化误处置。模型产生的“建议封禁”“建议删除”只能作为候选动作，必须由权限分离的人工角色审批。对外部系统的写操作应默认关闭，采用 dry-run、回滚和审计机制。
第四，时间和身份关联错误。跨系统关联时要处理时区、夏令时、NTP 漂移、账号别名和共享账号。任何无法确认的匹配都应标记为不确定，而不是强行合并。
第五，知识库过期。旧版处置手册可能导致错误建议。每篇文档应有负责人、审核周期和失效标记，检索结果中必须包含版本信息。
十、常见问题
问题一：模型能否直接替代 SOC 分析员？不能。它可以减少检索和整理成本，但最终判断仍需要结合资产价值、业务背景和人工经验。
问题二：使用更大的模型是否一定更准确？不一定。输入数据质量、规则设计、检索召回和输出校验往往比单纯扩大模型规模更重要。
问题三：为什么不让模型直接读取所有原始日志？因为会增加敏感数据暴露、上下文污染和成本，也会让模型更难区分关键证据。应先过滤字段、聚合事件，再提供必要上下文。
问题四：模型说“高危”就应该立即处置吗？不应该。应检查它引用的事件是否真实存在、风险规则是否满足、资产是否重要，以及是否存在共享出口、自动化任务等合理解释。
问题五：RAG 是否能消除幻觉？不能。RAG 只能提供可引用的上下文，仍需限制输出格式、执行事实校验并保留人工复核。
十一、总结
将大模型用于网络安全，核心不是把更多自动化动作交给模型，而是建立一条可验证、可回溯、可降级的分析链路。确定性程序负责事实计算，RAG 负责提供经过审核的组织知识，大模型负责解释和整理，schema 校验负责约束输出，人工审批负责最终高风险决策。对于 Hacker Ai 板块关注的部署与可靠性问题，建议优先从本地、脱敏、只读、可审计的威胁分析助手开始，再通过评测集验证效果，最后逐步接入工单和安全运营流程。只要始终坚持授权范围、最小权限和证据优先，这类系统才能真正降低分析负担，而不是把新的不确定性引入安全体系。
在安全运营、代码审计和威胁分析场景中，大模型最适合承担“信息整理、上下文关联、初步研判和报告生成”，而不应被当作可以独立做出最终安全结论的黑盒扫描器。实际环境中的日志数量大、字段不统一、告警重复率高，安全分析人员往往需要在多个系统之间反复查询：终端告警、身份认证日志、Web 访问日志、漏洞库、资产清单以及历史处置记录彼此割裂。大模型可以帮助分析人员把这些信息组织成时间线，并基于内部知识库给出可解释的研判建议。
本文以一个完全本地、可授权的实验环境为例，搭建一个面向安全运营的威胁分析助手。目标不是让模型自动封禁 IP 或直接修改生产配置，而是让它完成以下任务：一是从结构化日志中提取实体和行为；二是关联内部处置手册与漏洞知识；三是区分事实、推断和未知信息；四是输出可复核的风险评分、证据链和下一步建议。整个流程强调最小权限、数据脱敏、检索增强、规则校验和人工审批。
二、总体原理
一个可靠的安全分析链路可以拆成五层。
第一层是数据采集层。收集本地靶场中的身份认证日志、Web 服务器访问日志、主机检测日志和资产信息。采集时保留事件时间、主机、账号、源地址、动作、结果等必要字段，避免把无关的个人信息直接送入模型。
第二层是规范化层。不同系统的字段名称和时间格式通常不一致，需要统一为内部事件模型。例如将 user、username、account 统一为 account，将 src_ip、client_ip 统一为 source_ip，并将时间转换为 UTC 或统一时区。没有规范化，模型很容易把同一事件误认为多个事件。
第三层是检索增强层，也就是 RAG。把经过审核的内部材料切分并建立向量索引，例如告警处置手册、资产重要性说明、漏洞验证标准、账号异常判定规则和历史复盘报告。模型回答时只能把检索结果作为参考，并要求引用文档名称、版本和段落，而不是凭记忆生成结论。
第四层是分析与校验层。模型负责生成候选结论，但风险分数、时间窗口、IP 格式、事件数量和是否满足规则，应由确定性代码进行校验。例如模型说“同一账号在十分钟内从两个国家登录”，程序必须自行读取结构化事件并验证，而不能只相信模型的自然语言描述。
第五层是处置层。高风险操作必须进入人工审批队列。模型可以建议“暂时提高监控级别”或“请求值班人员复核”，但不能直接执行隔离主机、删除账号、修改防火墙规则等破坏性动作。对于实验环境，也建议先使用模拟动作和 dry-run 模式。
三、前置条件
1. 一台本地 Linux 主机或虚拟机，建议至少 8 GB 内存；如果使用较大的本地模型，应根据模型规模增加内存或显存。
2. Python 3.10 及以上版本，Docker 可选。
3. 一个本地推理服务，例如 Ollama、llama.cpp server 或其他兼容 OpenAI API 的推理服务。模型只需要具备较好的中文理解、结构化输出和长文本处理能力。
4. 一批自建的脱敏日志，禁止直接使用生产中的账号、Cookie、令牌、客户数据或内部密钥。
5. 一个经过审核的知识库目录，例如 docs/response_playbook、docs/asset_policy 和 docs/vulnerability_notes。
6. 明确的实验授权范围。本文所有测试均针对本地文件、模拟日志和授权靶场，不针对任何真实互联网目标。
四、构造本地实验数据
先创建目录：
mkdir -p security-lab/{logs,docs,output}
创建一份模拟认证日志 logs/auth.jsonl，每行一个 JSON 事件：
{"ts":"2025-01-15T09:00:00Z","account":"alice","source_ip":"192.0.2.10","country":"CN","result":"success","host":"vpn-lab-01"}
{"ts":"2025-01-15T09:06:00Z","account":"alice","source_ip":"198.51.100.20","country":"US","result":"success","host":"vpn-lab-01"}
{"ts":"2025-01-15T09:07:00Z","account":"alice","source_ip":"198.51.100.20","country":"US","result":"failed","host":"vpn-lab-01"}
其中 192.0.2.0/24 和 198.51.100.0/24 是文档示例地址，适合实验使用。再创建一份处置手册 docs/response_playbook.md，明确写出内部规则，例如：同一账号在十五分钟内从不同地理区域成功登录，标记为“需要复核”，但不能直接认定为账号被盗；VPN 出口、代理和移动网络可能造成地理位置误判；只有在设备指纹、登录时间和行为序列等证据一致时，才可以提高置信度。
五、实施一个最小可用分析器
安装基础依赖：
python -m venv .venv
source .venv/bin/activate
pip install requests pydantic python-dateutil
如果使用本地推理服务，可以让服务监听本机地址，例如 http://127.0.0.1:11434。下面的示例采用兼容聊天接口的形式，重点展示数据边界和校验方法，而不是绑定某个具体模型。
首先编写确定性规则，避免让模型自行计算关键事实：
from datetime import datetime
from dateutil.parser import isoparse
import json
def load_events(path):
events = []
with open(path, encoding="utf-8") as f:
for line in f:
if line.strip():
events.append(json.loads(line))
return events
def find_impossible_travel(events, window_minutes=15):
groups = {}
for event in events:
if event.get("result") != "success":
continue
groups.setdefault(event.get("account"), []).append(event)
findings = []
for account, items in groups.items():
items.sort(key=lambda x: isoparse(x["ts"]))
for left, right in zip(items, items[1:]):
delta = (isoparse(right["ts"]) - isoparse(left["ts"])).total_seconds() / 60
if delta <= window_minutes and left.get("country") != right.get("country"):
findings.append({
"type": "different_country_success",
"account": account,
"first": left,
"second": right,
"window_minutes": delta
})
return findings
这里的规则只生成“不同国家成功登录”这一事实，不直接生成“账号已失陷”。这是一个非常重要的边界：检测事实和安全结论必须分开。后续可以增加设备指纹、ASN、VPN 标识、失败次数和资产敏感等级等字段，但每一项都应有来源。
六、接入 RAG 的安全方式
知识库不要直接把所有文件拼接到提示词中。推荐先按标题、段落和版本切分，建立元数据，例如文档名称、发布日期、适用产品、审核人和失效时间。检索时使用“事件类型、资产标签、账号类型和关键词”组成查询，并保留少量高相关片段。
提示词可以采用如下结构：
系统要求：你是安全运营分析助手。只能根据输入事件和提供的知识片段进行分析。必须把结果分为“已确认事实”“合理推断”“尚未确认”。禁止编造不存在的日志字段、漏洞编号、用户身份或处置结果。不要执行任何系统操作。若证据不足，必须明确说明需要补充哪些数据。
输入事件：放入经过字段筛选的 JSON。
规则计算结果：放入程序已经验证的 findings。
知识片段：放入带有文档名和版本的检索结果。
输出格式：事件摘要、证据列表、风险等级及理由、误报可能性、建议补充的数据、建议处置动作、引用文档。
在生产实现中，建议使用 Pydantic 或 JSON Schema 验证模型输出。例如风险等级只能是 low、medium、high、unknown，建议动作只能从“继续观察”“人工联系账号所有者”“提高日志采样”“创建工单”等枚举值中选择。任何不符合 schema 的结果都应进入重试或人工队列，而不是直接写入工单系统。
七、把模型输出变成可审计结果
每次分析至少保存以下内容：输入事件的哈希值、数据时间范围、检索到的文档版本、提示词模板版本、模型名称、模型输出、规则校验结果、人工最终结论和处置时间。这样在误报或漏报复盘时，可以回答“模型当时看到了什么”和“知识库当时是什么版本”。不要只保存最终摘要，否则无法定位问题来自数据、检索、提示词还是模型本身。
可以使用如下命令对输出进行基本检查：
python -m json.tool output/analysis.json
sha256sum logs/auth.jsonl output/analysis.json
如果结果需要写入 SIEM 或工单系统，先写入隔离队列，由人工确认后再流转。对于批量分析任务，应设置单次最大日志条数、最大输入字符数和超时限制，防止异常日志导致资源耗尽。
八、评测方法
安全场景不能只看文本是否通顺。建议建立包含正常登录、共享出口、VPN 切换、撞库模拟日志、服务账号批量任务和时间戳异常等案例的评测集。每个案例标注事实字段、正确风险等级、允许的处置建议和不应出现的结论。
重点指标包括：事实抽取准确率、关键字段遗漏率、风险等级宏平均 F1、证据引用正确率、无依据断言率、结构化输出通过率和人工采纳率。对于高风险场景，还要单独统计“危险建议率”，例如模型是否在证据不足时建议禁用账号。评测集应定期加入线上复盘案例，但必须先脱敏。
可以采用双重判定：规则程序判断关键事实是否正确，安全人员判断解释和建议是否合理。不要使用另一个大模型作为唯一裁判，因为模型之间可能共享同样的偏差。
九、风险与注意事项
第一，提示词注入。日志、工单或提交内容可能包含“忽略之前规则”等文本。所有外部文本都必须被视为不可信数据，放在明确的数据区，不允许改变系统规则。检索文档也需要审核和版本控制。
第二，敏感信息泄露。账号、邮箱、内网域名、令牌和源代码都应尽量脱敏。尤其不能把 SSH 私钥、云平台密钥、Cookie 和完整客户数据放入调试日志。推理服务、向量库和监控系统应设置访问控制。
第三，自动化误处置。模型产生的“建议封禁”“建议删除”只能作为候选动作，必须由权限分离的人工角色审批。对外部系统的写操作应默认关闭，采用 dry-run、回滚和审计机制。
第四，时间和身份关联错误。跨系统关联时要处理时区、夏令时、NTP 漂移、账号别名和共享账号。任何无法确认的匹配都应标记为不确定，而不是强行合并。
第五，知识库过期。旧版处置手册可能导致错误建议。每篇文档应有负责人、审核周期和失效标记，检索结果中必须包含版本信息。
十、常见问题
问题一：模型能否直接替代 SOC 分析员？不能。它可以减少检索和整理成本，但最终判断仍需要结合资产价值、业务背景和人工经验。
问题二：使用更大的模型是否一定更准确？不一定。输入数据质量、规则设计、检索召回和输出校验往往比单纯扩大模型规模更重要。
问题三：为什么不让模型直接读取所有原始日志？因为会增加敏感数据暴露、上下文污染和成本，也会让模型更难区分关键证据。应先过滤字段、聚合事件，再提供必要上下文。
问题四：模型说“高危”就应该立即处置吗？不应该。应检查它引用的事件是否真实存在、风险规则是否满足、资产是否重要，以及是否存在共享出口、自动化任务等合理解释。
问题五：RAG 是否能消除幻觉？不能。RAG 只能提供可引用的上下文，仍需限制输出格式、执行事实校验并保留人工复核。
十一、总结
将大模型用于网络安全，核心不是把更多自动化动作交给模型，而是建立一条可验证、可回溯、可降级的分析链路。确定性程序负责事实计算，RAG 负责提供经过审核的组织知识，大模型负责解释和整理，schema 校验负责约束输出，人工审批负责最终高风险决策。对于 Hacker Ai 板块关注的部署与可靠性问题，建议优先从本地、脱敏、只读、可审计的威胁分析助手开始，再通过评测集验证效果，最后逐步接入工单和安全运营流程。只要始终坚持授权范围、最小权限和证据优先，这类系统才能真正降低分析负担，而不是把新的不确定性引入安全体系。