作为一名即将毕业的网络安全专业学生，我深知完成一个既有深度又有亮点的毕业设计项目是多么具有挑战性。选题要么太泛，要么太旧；想用新技术，又怕时间不够；自己写的检测逻辑，总感觉不够“聪明”。最近，我尝试将大语言模型（LLM）引入到我的毕业设计项目中，用 AI 来辅助整个开发流程，效果出乎意料。这篇文章，我就来分享一下我的实战经验：如何利用 AI 工具，构建一个基于 Flask 和 Suricata 的轻量级入侵检测演示系统。

1. 毕业设计项目的那些“坑”

在动手之前，我们先盘一盘做网络安全毕设时常见的几个痛点，这也是我选择引入 AI 辅助的初衷。

1. 选题空泛，缺乏聚焦：很多同学会选“网络入侵检测系统”这样的大题目，但具体检测什么、防御什么逻辑，非常模糊，导致项目流于表面。
2. 技术栈陈旧，缺乏亮点：可能还在用着好几年前的攻击手段和防御代码，与当前快速发展的威胁态势脱节，答辩时很难出彩。
3. 攻防逻辑薄弱，纸上谈兵：自己编写的规则或检测逻辑往往比较单一，覆盖的场景有限，难以模拟真实的、复杂的攻击行为。
4. 数据匮乏，演示效果差：没有真实的网络流量或攻击数据包，演示时只能用简单的、人造的例子，说服力不足。
5. 工程完整性差：可能只关注核心算法，忽略了前后端交互、日志管理、可视化展示等工程化环节，项目看起来不像一个完整的“系统”。

2. AI 工具链选型：云端助手 vs. 本地大脑

确定了要用 AI 辅助，接下来就是选工具。目前主要有两类选择：云端编程助手和本地部署的大模型。

• 云端编程助手（如 GitHub Copilot）：优点是开箱即用，集成在 IDE 里，写代码、写注释、补全函数非常方便。它特别适合辅助完成项目中的通用代码部分，比如 Flask 的路由设置、前端页面模板、数据库连接等。缺点是，对于网络安全领域特定的知识，比如 Suricata 规则语法、特定漏洞的攻击载荷特征，它的生成结果可能不够精确或有些过时。

• 本地大语言模型（如 Llama 3、Qwen 等）：这是本次项目的重点。我们需要一个能理解我们需求、并生成专业安全内容的“大脑”。本地部署的 LLM 优点在于数据隐私性好，可以针对网络安全语料进行微调（如果资源允许），并且可以反复、深入地让它帮助我们进行“威胁建模”、“规则生成”和“代码解释”。虽然初始设置比 Copilot 麻烦，但对于生成领域特定的内容，可控性和针对性更强。

我的策略是结合使用：用 Copilot 加速通用开发，用本地 LLM 作为安全领域的“专家顾问”，负责生成核心的安全逻辑内容。

3. 核心实现：让 AI 成为我们的“安全分析师”

整个系统的架构很简单：一个 Flask 后端提供 Web 界面，用于提交检测需求、管理规则、展示告警；后台运行 Suricata 引擎，加载由 AI 生成的规则，对模拟流量或 PCAP 文件进行检测。

关键一步是如何让 AI 生成可用的 Suricata 规则。 这里分享我的 Prompt 设计思路和流程：

1. 角色设定与任务分解：我会给本地 LLM 一个清晰的指令，例如：“你现在是一名资深网络安全分析师，擅长编写 Suricata 入侵检测规则。请根据以下攻击描述，生成一条对应的 Suricata 规则。攻击描述：[例如：检测 HTTP 请求中是否存在典型的 SQL 注入攻击特征，如‘union select’、‘or 1=1’等]”。

2. 提供规则模板与约束：为了让 AI 的输出更规范，我会在 Prompt 中提供 Suricata 规则的基本结构模板，并强调关键字段（如 action, protocol, source/dest IP/port, msg, sid, rev, content 等）的写法。同时要求它必须为规则分配一个唯一的 sid，并给出清晰的告警信息(msg)。

3. 迭代优化与验证：AI 生成的第一版规则可能不完美。我会将生成的结果放到 Suricata 的测试命令 (suricata -T) 或在线校验工具中检查语法。如果有错误，将错误信息反馈给 AI，让它进行修正。这个过程本身也是学习 Suricata 规则语法的好机会。

4. 集成到 Flask 系统：在 Flask 后端，我设计了一个简单的接口。用户可以在 Web 界面输入自然语言描述的攻击场景（如“我想检测针对 Apache Struts2 的 S2-045 漏洞利用尝试”），后端将这个描述发送给本地 LLM 的 API。收到生成的规则后，将其保存到指定的规则文件，然后通过系统命令通知 Suricata 重新加载规则。

4. 代码展示：Flask 后端核心逻辑

下面是我项目中的部分核心代码，展示了如何将上述流程工程化。代码包含了关键注释，方便理解。

from flask import Flask, request, jsonify, render_template
import subprocess
import os
import requests  # 用于调用本地LLM API，例如Ollama
import re

app = Flask(__name__)

# 配置
SURICATA_RULE_PATH = ‘/etc/suricata/rules/my_ai_rules.rules‘
LLM_API_URL = ‘http://localhost:11434/api/generate‘  # 假设使用Ollama
LLM_MODEL = ‘llama3‘  # 或 qwen:7b 等

def call_llm_for_rule(prompt_text):
    """调用本地LLM生成Suricata规则"""
    payload = {
        “model“: LLM_MODEL,
        “prompt“: prompt_text,
        “stream“: False
    }
    try:
        response = requests.post(LLM_API_URL, json=payload)
        response.raise_for_status()
        result = response.json()
        # 从LLM的回复中提取规则文本，通常需要一些简单的文本清洗
        raw_rule = result.get(‘response‘, ‘’).strip()
        # 这里可以添加更复杂的解析逻辑，确保提取出完整的规则行
        # 例如，匹配以‘alert‘开头的行
        rule_match = re.search(r‘^(alert .*)$‘, raw_rule, re.MULTILINE)
        if rule_match:
            return rule_match.group(1)
        else:
            return None
    except Exception as e:
        print(f“调用LLM API失败: {e}“)
        return None

def validate_and_add_rule(new_rule):
    """验证规则语法并添加到规则文件"""
    if not new_rule:
        return False, “规则为空或生成失败“
    # 1. 语法校验 (简单示例，实际可用suricata -T 或更复杂的校验)
    # 这里我们检查基本结构
    if not new_rule.startswith(‘alert‘):
        return False, “规则必须以‘alert‘开头“
    # 更严格的校验可以调用 `suricata -T -l /tmp -S <临时规则文件>` 来实现
    # 2. 写入规则文件
    try:
        with open(SURICATA_RULE_PATH, ‘a‘) as f:
            f.write(f“\n{new_rule}\n“)
        # 3. 通知Suricata重载规则
        # 方法取决于你的Suricata部署方式，这里发送SIGHUP信号给进程是一种方式
        # 例如，如果知道进程ID: os.kill(pid, signal.SIGHUP)
        # 或者使用Suricata的unix socket控制接口
        subprocess.run([‘suricatasc‘, ‘-c‘, ‘reload-rules‘], capture_output=True, text=True)
        return True, “规则添加并重载成功“
    except Exception as e:
        return False, f“文件操作或重载失败: {e}“

@app.route(‘/‘)
def index():
    """渲染主页面"""
    return render_template(‘index.html‘)

@app.route(‘/generate_rule‘, methods=[‘POST‘])
def generate_rule():
    """接收自然语言描述，生成并部署规则"""
    data = request.json
    attack_description = data.get(‘description‘, ‘’)
    if not attack_description:
        return jsonify({‘success‘: False, ‘message‘: ‘请输入攻击描述‘})
    # 构建给LLM的Prompt
    prompt = f“““你是一名Suricata规则专家。请仅为以下攻击场景编写一条准确、有效的Suricata规则。
    规则必须完整，以‘alert‘开头，包含必要的协议、端口、内容匹配和清晰的msg信息。
    请为规则分配一个唯一的sid（例如从1000000开始）。
    攻击场景：{attack_description}
    只输出规则本身，不要有其他解释。“““
    # 调用LLM
    generated_rule = call_llm_for_rule(prompt)
    if generated_rule:
        # 验证并部署
        success, message = validate_and_add_rule(generated_rule)
        return jsonify({‘success‘: success, ‘message‘: message, ‘rule‘: generated_rule})
    else:
        return jsonify({‘success‘: False, ‘message‘: ‘AI规则生成失败‘})

@app.route(‘/alerts‘)
def get_alerts():
    """从Suricata的eve.json日志中读取最近的告警，用于前端可视化"""
    # 这里需要解析Suricata生成的eve.json日志文件
    # 示例中返回模拟数据
    # 实际项目中，你可以使用python的json库读取并过滤‘alert‘事件
    import json
    alerts = []
    try:
        with open(‘/var/log/suricata/eve.json‘, ‘r‘) as f:
            for line in f:
                try:
                    event = json.loads(line.strip())
                    if event.get(‘event_type‘) == ‘alert‘:
                        alerts.append({
                            ‘timestamp‘: event.get(‘timestamp‘),
                            ‘msg‘: event[‘alert‘][‘signature‘],
                            ‘src_ip‘: event.get(‘src_ip‘, ‘’),
                            ‘dest_ip‘: event.get(‘dest_ip‘, ‘’)
                        })
                except json.JSONDecodeError:
                    continue
    except FileNotFoundError:
        alerts = [{‘timestamp‘: ‘2023-10-01T12:00:00‘, ‘msg‘: ‘示例告警: HTTP潜在SQL注入攻击‘, ‘src_ip‘: ‘192.168.1.100‘, ‘dest_ip‘: ‘10.0.0.1‘}]
    return jsonify(alerts[-10:])  # 返回最近10条

if __name__ == ‘__main__‘:
    app.run(debug=True, host=‘0.0.0.0‘, port=5000)

5. 安全性考量：与 AI 协作的“红线”

让 AI 生成安全规则，本身就必须考虑安全。

1. 防止提示注入：我们的系统接收用户输入（攻击描述）并传给 LLM。必须警惕用户输入可能包含精心构造的、旨在“劫持”或“污染”AI 指令的恶意 Prompt。需要在后端对用户输入进行严格的过滤和长度限制，避免其改变我们预设的、赋予 AI 的“安全分析师”角色。

2. 确保生成规则的可验证性：绝不能“黑盒”式地信任 AI 生成的规则。必须建立验证流程：

   • 语法验证：如前所述，使用 Suricata 自带的测试工具进行语法检查。
   • 逻辑审阅：开发者必须理解规则在检测什么。AI 生成的每条规则，都需要人工复核其 content 字段是否准确匹配了所描述的攻击特征，其协议、端口设置是否合理。
   • 测试验证：在隔离的测试环境中，使用模拟攻击流量（如通过 scapy 构造数据包，或重放已知攻击的 PCAP 文件）来验证规则是否能正确触发告警，并且误报率在可接受范围内。

6. 生产环境避坑指南

毕业设计项目虽小，但以“准生产”的标准要求自己，能学到更多。

1. 避免过度依赖 AI 生成逻辑：AI 是强大的辅助，但不是决策主体。项目的核心架构、关键的数据流设计、安全边界定义，必须由你自己掌控。AI 生成的内容应被视为“初稿”或“建议”，需要经过你的专业判断和修改。

2. 人工复核是必须环节：尤其是安全规则。每条 AI 生成的规则，在部署前都必须经过你的逐行审阅。问自己：这条规则真的能检测到它声称的攻击吗？它的条件是否过于宽泛可能导致大量误报？它的 sid 是否与其他规则冲突？这个过程是加深你对检测技术理解的最佳途径。

3. 关注性能与效率：AI 生成规则时，可能会写出一些性能不佳的表达式（如过于复杂的正则表达式 pcre）。在将规则加入生产规则集前，需要评估其性能影响。Suricata 官方文档中有关于编写高效规则的指南，可以参考。

4. 做好版本管理与回滚：对 AI 生成的规则文件进行版本控制（如 Git）。当某次批量添加的 AI 规则导致 Suricata 性能下降或产生大量误报时，可以快速回滚到上一个稳定版本。

结尾思考

通过这个项目，我深刻体会到，AI 辅助开发不是替代开发者，而是将开发者从重复性、查找性的劳动中解放出来，让我们能更聚焦于架构设计、逻辑复核和创造性思考。对于算力有限的我们来说，构建一个“可解释”的 AI 安全辅助流程至关重要——即 AI 的每一步输出（生成的规则、代码）都是可审查、可验证、可追溯的。

未来，或许我们可以进一步探索：如何利用较小的、精调的领域模型，专门用于生成和优化安全检测规则？如何构建一个闭环系统，让 AI 不仅能生成规则，还能根据检测日志中的误报和漏报，自动优化已有的规则？这些问题，留待我和各位同行在未来的学习和实践中继续探索。希望我的这份实战笔记，能为你的毕业设计或下一个安全工具开发带来一些新的思路。