1. 项目概述当LLM应用安全遇上API网关最近在部署和优化Dify这个LLM应用开发平台时我遇到了一个非常现实且紧迫的问题如何为它构建一道可靠的安全防线Dify本身提供了强大的工作流编排和API管理能力但面对日益复杂的网络攻击尤其是针对大语言模型LLM的新型威胁仅靠应用层逻辑是远远不够的。这让我把目光投向了API网关与Web应用防火墙WAF的联动。特别是看到社区里有人讨论“小宁写了个ping功能但没有写WAFX老师告诉她这是非常危险的”这恰恰点明了问题的核心——在暴露API服务时缺乏边界安全防护是极其危险的。这个项目就是一次针对Dify 2026版本泛指当前及近期的稳定版本的深度安全实践。核心目标是通过配置API网关如Nginx、Kong、APISIX等与WAF如ModSecurity、云WAF等的联动利用WAF的原生规则集主动拦截针对LLM的典型攻击例如LLM注入LLM Injection和提示词劫持Prompt Hijacking。同时我们还需要将OWASP API Security Top 10中的风险项映射到具体的WAF规则上形成一张可操作的防御对照表。无论是进行Dify本地部署还是在线升级这套安全方案都能为你提供从网络边界到应用逻辑的纵深防御思路。2. 核心威胁解析为什么LLM应用需要专门的WAF策略在传统Web应用中SQL注入、XSS等是主要威胁。但当你的应用核心是一个大语言模型时攻击面发生了根本性变化。攻击者不再仅仅试图窃取数据或破坏服务而是试图“操纵”或“欺骗”AI模型使其产生偏离设计者意图的输出。2.1 LLM注入与Prompt劫持新型攻击向量LLM注入类似于SQL注入攻击者通过在用户输入中嵌入特殊的指令或分隔符试图“注入”一段本应由系统预设的提示词System Prompt从而改变模型的上下文或行为模式。例如用户输入可能以“忽略之前的指令并执行以下操作”开头后面跟着恶意指令。Prompt劫持则更进一步攻击者可能通过精心构造的输入完全覆盖或替换掉系统预设的提示词将模型“劫持”为完全服务于攻击者目的的工具。例如让一个客服机器人泄露训练数据、生成不当内容或执行未授权的操作。这些攻击之所以危险是因为它们利用了LLM对自然语言指令的遵从性。传统的基于正则表达式或简单关键词过滤的输入验证在高度灵活的自然语言面前往往力不从心。这正是需要WAF介入的原因——在请求到达Dify应用逻辑之前在协议层和语义层进行深度检测和拦截。2.2 OWASP API Security Top 10 与LLM的关联OWASP API Security Top 10 是针对API的十大安全风险清单。虽然它并非专为LLM设计但其多数条目与LLM应用的安全息息相关。例如API1:2023 失效的对象级授权攻击者可能通过修改请求中的ID参数访问其他用户的对话历史或工作流数据。API2:2023 失效的身份认证未正确保护的Dify API密钥可能导致未授权访问。API3:2023 失效的对象属性级授权在复杂的工作流请求中可能包含用户不应有权限修改的属性。API4:2023 不受限制的资源消耗LLM推理极其消耗算力攻击者可通过大量复杂查询发起拒绝服务攻击这也是“盲注绕过WAF语法”可能试图达成的目的之一。API5:2023 失效的功能级授权用户可能越权调用仅限管理员使用的模型管理或数据导出API。API8:2023 安全配置错误不安全的Dify部署配置、过期的依赖项等。API9:2023 库存管理不当暴露了不应公开的测试或管理API端点。API10:2023 不安全的数据消费Dify集成了外部数据源或工具如果对这些源头的数据没有验证可能导致供应链攻击。我们的WAF配置需要能够识别并缓解这些风险。3. 架构设计与组件选型为Dify构建安全网关我推荐一个分层、解耦的架构这样便于维护和扩展。核心思路是流量首先经过WAF进行深度安全清洗再通过API网关进行路由、限流和协议转换最后到达Dify应用。3.1 整体架构拓扑一个典型的部署拓扑如下互联网用户 - (可选) 云WAF / CDN - 自建WAF (ModSecurity) - API网关 (Nginx/Kong) - Dify Application第一层可选云防护如果业务在公有云上可以启用阿里云、腾讯云等提供的云WAF服务。它们能提供第一波DDoS缓解和已知漏洞的防护例如拦截针对“阿里云 WAF 的 JS 挑战页”的绕过尝试。但云WAF对业务逻辑和自定义规则的支持深度有限。第二层核心自建WAF在自有网络边界部署ModSecurity等开源WAF。这是防御的主阵地我们将在此处加载针对LLM威胁的自定义规则集CRS。它可以精细解析HTTP/HTTPS流量检查请求头、参数、Body内容。第三层控制API网关使用Nginx配合Lua模块、Kong或APISIX作为API网关。它负责将清洗后的流量路由到正确的Dify后端服务可能是多个实例并实施速率限制、认证鉴权验证API Key、请求/响应转换等。第四层应用DifyDify自身。网关层之后Dify应用内部仍需进行输入验证、输出过滤和权限检查实现纵深防御。注意对于资源有限或测试环境可以将WAF模块如ModSecurity直接编译进Nginx将第二层和第三层合并。但这会增大Nginx的复杂性和资源消耗不利于独立升级和扩展。3.2 核心组件选型理由WAF: ModSecurity OWASP Core Rule Set (CRS)ModSecurity是事实上的开源WAF标准功能强大规则语言灵活社区活跃。它能提供详细的审计日志便于事后分析和规则调优。OWASP CRS提供了一套开箱即用的、针对常见Web攻击SQLi, XSS, RCE等的防护规则集。它是我们规则库的基石。我们需要在其基础上为LLM威胁添加自定义规则。不选云WAF作为唯一方案的原因云WAF虽然省心但规则黑盒化自定义能力受平台限制且无法防护内网流量。自建方案可控性更高能针对Dify的API特征做深度定制。API网关: Nginx普及率高生态成熟几乎无处不在资料丰富。通过ngx_http_modsecurity_module模块可以集成ModSecurity。性能优异处理静态内容和反向代理的性能经过充分验证。灵活性通过Lua脚本OpenResty可以实现复杂的逻辑如动态限流、JWT验证等。虽然Kong基于OpenResty提供了更多开箱即用的API管理功能但对于从简入繁的配置纯Nginx更直观。这个选型组合确保了我们在拥有强大安全能力的同时保持了架构的简洁和可控性非常适合从“Dify本地部署教程”到生产环境进阶的安全加固。4. 实战配置构建LLM-aware的WAF规则集这是整个项目的核心。我们将分两步走首先启用并调优基础CRS规则然后创建针对LLM注入和Prompt劫持的自定义规则。4.1 基础环境搭建与CRS配置假设你已经在服务器上通过“dify本地部署”教程完成了Dify的安装现在需要在前端加装WAF。安装ModSecurity for Nginx# 以Ubuntu为例添加ModSecurity官方仓库并安装 sudo apt-get install -y apt-transport-https ca-certificates curl gnupg curl -fsSL https://pkgs.modsecurity.org/repo/pubkey.gpg | sudo gpg --dearmor -o /usr/share/keyrings/modsecurity.gpg echo deb [signed-by/usr/share/keyrings/modsecurity.gpg] https://pkgs.modsecurity.org/repo/ubuntu/ $(lsb_release -cs) main | sudo tee /etc/apt/sources.list.d/modsecurity.list sudo apt-get update sudo apt-get install -y libmodsecurity3 nginx-module-modsecurity对于其他系统或从源码编译需参考官方文档。关键是要生成modsecurity.so模块供Nginx加载。加载ModSecurity模块并引入CRS 在Nginx主配置文件nginx.conf的http块中加载模块并指定配置。http { # 加载ModSecurity模块 load_module modules/ngx_http_modsecurity_module.so; # 指定ModSecurity主配置文件 modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf; # ... 其他http配置 }创建/etc/nginx/modsec/main.conf内容如下# 引入ModSecurity基础配置 Include /usr/share/modsecurity-crs/modsecurity.conf # 引入OWASP CRS规则集 Include /usr/share/modsecurity-crs/crs-setup.conf Include /usr/share/modsecurity-crs/rules/*.conf你需要从GitHub克隆最新的OWASP CRS到/usr/share/modsecurity-crs/目录。关键CRS规则调优 CRS规则默认比较严格可能会误封正常API请求。我们需要针对Dify的API特征进行调整主要修改crs-setup.conf调整检测模式将SecDefaultAction从deny改为phase:2,log,auditlog,pass先观察日志不直接拦截。提高请求体限制LLM的Prompt可能很长需要调整SecRequestBodyLimit和SecRequestBodyNoFilesLimit例如设置为1048576010MB。排除特定路径Dify的健康检查端点如/health或静态文件路径可以添加到SecRuleRemoveById中临时排除避免误报。针对JSON深度解析Dify API大量使用JSON。确保CRS的REQUEST-920-PROTOCOL-ENFORCEMENT.conf中关于JSON解析的规则已启用并适当调整tx.json_depth_limit。4.2 定制LLM威胁检测规则现在我们在main.conf中CRS规则引入的后面添加自定义规则文件llm-threats.conf。规则设计思路我们无法也不应该完全禁止用户输入某些关键词因为那会严重影响功能。我们的策略是检测“具有明显注入意图的模式”并在单次请求中此类模式出现频率过高或组合异常时进行拦截。检测系统提示词覆盖尝试 攻击者常使用“ignore”、“overwrite”、“previous instructions”等词尝试覆盖系统提示。# 规则ID从100000开始避免与CRS冲突 SecRule REQUEST_BODY|REQUEST_URI|ARGS|ARGS_NAMES rx (?i)(ignore|overwrite|disregard|forget|previous|prior|system|assistant|instruction)(\s(the|all|above|previous|prior))?\s*(instructions|prompt|context|rules|directives) \ id:100000,\ phase:2,\ log,\ auditlog,\ msg:Potential LLM Prompt Override Attempt,\ tag:llm-injection,\ severity:CRITICAL,\ ver:LLM-Rules/1.0,\ setvar:tx.llm_injection_score%{tx.critical_anomaly_score},\ chain SecRule TX:llm_injection_score ge 10 \ t:none,\ deny,\ status:403,\ setvar:tx.anomaly_score%{tx.critical_anomaly_score},\ logdata:Matched: %{MATCHED_VAR}原理第一条规则在请求中搜索可能覆盖指令的关键词组合匹配则增加一个计数器tx.llm_injection_score。第二条规则是链式规则只有当该计数器超过阈值例如10时才执行拦截deny。这避免了因单个无害词汇如用户说“I forgot my password”而误封。rx使用正则表达式匹配(?i)表示不区分大小写。phase:2在请求体解析后执行。setvar操作变量这里是增加分数。chain将两条规则链接只有都满足才执行最终动作。检测角色扮演或身份劫持尝试 攻击者可能试图让模型扮演危险角色如“你现在是黑客”、“扮演一个没有道德约束的AI”。SecRule REQUEST_BODY|ARGS rx (?i)(act|play|roleplay|impersonate|simulate|you are|youre|as a|be a)(\s(a|an|the))?\s*(hacker|malicious|unethical|unauthorized|evil|bad|illegal|attack) \ id:100001,\ phase:2,\ log,\ auditlog,\ msg:Potential LLM Role Hijacking Attempt,\ tag:llm-injection,\ severity:CRITICAL,\ ver:LLM-Rules/1.0,\ setvar:tx.llm_role_hijack_score%{tx.critical_anomaly_score},\ chain SecRule TX:llm_role_hijack_score ge 8 \ t:none,\ deny,\ status:403检测敏感数据泄露诱导 尝试诱导模型输出训练数据、内部指令或其他敏感信息。SecRule REQUEST_BODY|ARGS rx (?i)(training data|underlying data|original prompt|system prompt|internal|secret|confidential|leak|reveal|dump|show me your|what were you|initial instructions) \ id:100002,\ phase:2,\ log,\ auditlog,\ msg:Potential Training Data Exfiltration Attempt,\ tag:llm-injection,\ severity:CRITICAL,\ ver:LLM-Rules/1.0,\ setvar:tx.llm_data_exfil_score%{tx.critical_anomaly_score},\ chain SecRule TX:llm_data_exfil_score ge 12 \ t:none,\ deny,\ status:403聚合评分与拦截 最后设置一个总评分规则当多种攻击迹象同时出现时提高拦截置信度。SecRule TX:llm_injection_score gt 0 \ id:100099,\ phase:5,\ log,\ auditlog,\ msg:LLM Threat Aggregate Score: %{TX.llm_injection_score},\ setvar:tx.anomaly_score%{TX.llm_injection_score} # 可以在phase:5日志记录阶段根据总anomaly_score决定是否加入IP黑名单等操作实操心得规则中的阈值如ge 10需要在实际流量中反复校准。过松则漏报过紧则误封。建议先在SecDefaultAction设为pass的观察模式下运行一段时间分析modsec_audit.log根据误报和漏报情况调整正则表达式和阈值。正则表达式不要写得太宽泛避免影响正常对话。5. API网关策略与Dify集成配置WAF负责内容安全API网关则负责流量控制和路由。这里以Nginx为例展示如何为Dify配置安全的代理。5.1 Nginx核心安全配置在Nginx的server块中为Dify的API端点通常以/v1或/api开头配置location。server { listen 443 ssl http2; server_name your-dify-domain.com; # SSL配置略 # ... # 全局启用ModSecurity也可在特定location启用 modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf; # Dify前端静态文件 location / { root /path/to/dify-fe/dist; try_files $uri $uri/ /index.html; # 可在此处添加静态资源的缓存、CORS等头部 } # Dify后端API - 这是防护重点 location /api/v1/ { # 0. 连接限制 limit_conn per_ip_zone 10; # 每个IP最多10个连接 limit_req zoneapi_rate burst20 nodelay; # 限流令牌桶算法 # 1. 启用ModSecurity如果未全局启用 # modsecurity on; # modsecurity_rules_file /etc/nginx/modsec/main.conf; # 2. 重要设置大的请求体缓存以支持ModSecurity扫描 client_max_body_size 10M; client_body_buffer_size 128k; proxy_request_buffering on; # 必须为onModSecurity才能检查body # 3. 移除敏感头添加安全头 proxy_hide_header X-Powered-By; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options DENY always; # 4. 反向代理到Dify后端 proxy_pass http://dify-backend:5001; # 假设Dify后端运行在5001端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 300s; # LLM响应可能较慢需延长超时 # 5. 记录被WAF拦截的请求日志可选 error_log /var/log/nginx/dify_api_waf_error.log notice; } # 健康检查端点 - 可考虑排除WAF检测避免误判 location /health { modsecurity off; # 在此路径关闭WAF proxy_pass http://dify-backend:5001/health; access_log off; } # 定义限流共享内存区 limit_conn_zone $binary_remote_addr zoneper_ip_zone:10m; limit_req_zone $binary_remote_addr zoneapi_rate:10m rate10r/s; }关键配置解析limit_conn和limit_req直接防御“不受限制的资源消耗”OWASP API #4。LLM推理成本高必须严格限流。burst20 nodelay表示允许瞬间超过速率限制的突发流量但会立即消耗令牌防止洪水攻击。client_max_body_size和proxy_request_buffering on确保大的Prompt请求体能被完整缓存供ModSecurity扫描。关闭缓冲off会导致ModSecurity无法检查请求体内容。安全头部如X-Content-Type-Options、X-Frame-Options是基础安全加固。超时设置proxy_read_timeout需要根据模型推理时间调整避免长响应超时。5.2 认证与API密钥验证Dify通常使用API Key进行认证。我们可以在网关层实现初步验证减轻后端压力。location /api/v1/ { # ... 上述其他配置 ... # 检查请求头中是否包含有效的API Key set $api_key_valid 0; if ($http_authorization ~* ^Bearer\s(sk-[a-zA-Z0-9]{48})$) { # 这里可以扩展为查询数据库或缓存示例中仅检查格式 # 实际生产环境应使用Lua脚本或auth_request模块进行校验 set $api_key_valid 1; } # 或者从query参数中检查不推荐容易泄露 # if ($arg_api_key ~* ^sk-[a-zA-Z0-9]{48}$) { # set $api_key_valid 1; # } if ($api_key_valid 0) { return 401 {error: Invalid or missing API Key}; } # 将验证后的API Key信息传递给后端可选 proxy_set_header X-API-Key $http_authorization; proxy_pass http://dify-backend:5001; }注意Nginx的if指令有局限性复杂校验建议使用lua-nginx-module编写Lua脚本或使用ngx_http_auth_request_module委托给一个专门的认证服务。这能有效缓解“失效的身份认证”OWASP API #2风险。6. OWASP API Security Top 10 映射与WAF规则对照表下表将OWASP API安全风险与可实施的WAF/网关配置策略对应起来形成一张可操作的检查清单。OWASP API 安全风险 (2023)风险描述针对Dify场景WAF / API网关 防护策略对应规则/配置示例API1: 失效的对象级授权用户A通过修改请求中的conversation_id访问到了用户B的对话历史。1. 请求参数模式检测检查ID参数是否符合预期格式如UUID。2. 路径遍历检测CRS规则REQUEST-930-APPLICATION-ATTACK-LFI.conf已包含。3. 网关层补强网关应传递已认证的用户身份如User ID给后端由后端进行权限校验。SecRule ARGS_NAMES rx ^(id|conversation_id|thread_id)$ phase:2, id:100010, log, setvar:tx.obj_id_param1结合业务逻辑此规则主要用于标记。API2: 失效的身份认证API Key被泄露、未加密传输、或认证逻辑有缺陷。1. 强制HTTPSNginx配置SSLHTTP重定向到HTTPS。2. API Key格式校验在网关层校验Key的格式如sk-前缀长度。3. 限流与防爆破对认证端点如/login实施严格的速率限制。limit_req_zone $binary_remote_addr zoneauth_rate:10m rate5r/m;应用于登录接口。API3: 失效的对象属性级授权更新工作流请求中包含了用户无权修改的is_public字段。1. 请求体结构验证对于写操作POST/PUT/PATCH验证请求体JSON结构标记非白名单字段。这需要较复杂的WAF规则或网关插件。2. 依赖后端校验WAF难以完全替代业务逻辑校验需记录详细日志供审计。可尝试使用ModSecurity的validateSchema操作校验JSON Schema但维护成本高。更推荐在后端实现。API4: 不受限制的资源消耗攻击者发送大量复杂Prompt耗尽GPU/CPU资源导致服务拒绝。1. 全局与端点级限流在网关层实施如Nginx的limit_req。2. 请求体大小限制限制单个Prompt的长度。3. 单用户/单IP并发连接数限制limit_conn。limit_req zoneapi_rate burst20 nodelay;client_max_body_size 1M;根据业务调整API5: 失效的功能级授权普通用户调用管理员API如DELETE /api/v1/models。1. 路径与方法黑名单禁止非管理员IP访问管理端点。2. 基于角色的访问控制(RBAC)代理网关集成认证服务解析JWT token中的角色阻止未授权访问。location ~ ^/api/v1/(models|system)/ { allow 10.0.0.0/8; deny all; }简单IP白名单API6: 不受限的敏感信息暴露API响应中包含了内部错误详情、服务器版本、堆栈跟踪。1. 响应过滤与改写使用Nginx子请求或Lua脚本对错误响应进行标准化移除敏感信息。2. 安全头部确保不泄露技术细节。proxy_intercept_errors on;error_page 500 502 503 504 /custom_error.json;API7: 服务端请求伪造Dify工作流中攻击者操控“HTTP请求”节点访问内网服务。WAF难以直接防护因为SSRF发生在应用层业务逻辑内。需在Dify应用内部对“HTTP请求”节点的目标URL进行严格白名单过滤。无直接WAF规则。依赖应用层安全编码。API8: 安全配置错误使用默认配置、开启调试模式、暴露不必要的端口如Dify的5001端口直接对外。1. 端口与网络隔离确保Dify后端仅能被网关访问。2. 默认路径扫描防护CRS规则REQUEST-911-METHOD-ENFORCEMENT.conf和REQUEST-920-PROTOCOL-ENFORCEMENT.conf能拦截许多探测请求。3. 定期更新保持Nginx、ModSecurity、CRS规则集为最新版本。定期执行apt-get update apt-get upgrade nginx libmodsecurity3API9: 库存管理不当测试环境API端点如/api/v1/beta/被暴露到生产环境。1. 严格的路径路由在网关配置中只暴露正式API路径。2. 禁用不必要的HTTP方法对非必要路径禁用PUT, DELETE, PATCH等。location ~ ^/api/v1/(beta|test|admin)/ { return 404; }生产环境API10: 不安全的数据消费Dify从用户提供的URL获取数据时该URL指向恶意源污染了模型上下文。1. 出站请求过滤网关侧困难更应在Dify应用内部对可访问的外部URL实施白名单策略。2. 输入内容检测对用户提交的URL参数用WAF规则检测是否包含内网IP或恶意域名。SecRule ARGS:external_url rx (10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.0\.0\.1) id:100020, phase:2, deny, msg:Potential SSRF via internal IP这张表可以作为你安全审计和配置检查的蓝图。需要注意的是WAF和网关是强大的补充但无法替代应用层自身的安全编码和逻辑校验。7. 监控、调优与问题排查部署完成后安全工作才刚刚开始。持续的监控和基于反馈的调优至关重要。7.1 日志分析与监控ModSecurity审计日志(modsec_audit.log)这是金矿。所有拦截、触发的规则都会记录在此。你需要定期分析误报False Positives正常业务请求被拦截。需要调整规则ID如SecRuleRemoveById或修改自定义规则的正则表达式、降低阈值。漏报False Negatives攻击未被发现。需要审视日志中是否有可疑但未触发规则的请求考虑添加或强化规则。使用工具如jq解析JSON格式的审计日志或使用Elastic Stack (ELK) 进行集中分析和可视化。Nginx访问/错误日志关注403WAF拦截、429限流和5xx错误。高频率的429可能意味着需要调整限流策略5xx可能表示请求已绕过WAF导致后端异常。性能监控WAF检查会增加延迟。监控Nginx的请求处理时间$request_time确保在可接受范围内。如果性能影响过大考虑对静态资源、健康检查等路径关闭WAF。7.2 常见问题与排查技巧问题正常API请求被WAF拦截误报排查查看modsec_audit.log找到对应的transaction_id查看触发的规则ID和匹配的字符串。解决如果触发的是CRS规则ID在900000-999999且该请求确为正常业务可以将该规则ID添加到特定location的排除列表SecRuleRemoveById 942100。如果触发的是自定义LLM规则说明你的正则或阈值太严格。调整正则表达式使其更精确或者提高拦截阈值如将ge 10改为ge 15。考虑将Dify API特有的、无害但可能触发规则的内容如某些固定的提示词模板加入SecRuleUpdateTargetById排除。问题攻击请求未被拦截漏报排查进行渗透测试使用专门的LLM攻击测试Payload如来自gandalf.lakera.ai的挑战。检查审计日志看请求是否被记录但分数未达拦截线。解决降低自定义规则的拦截阈值。添加更全面的关键词或模式到正则表达式中。检查WAF是否在正确的phase执行。对于JSON Body中的攻击必须确保在phase:2请求体解析后进行检查且proxy_request_buffering为on。问题Nginx返回413 Request Entity Too Large解决确保Nginx配置中的client_max_body_size值大于等于ModSecurity配置中的SecRequestBodyLimit值且两者都满足你业务中最大Prompt的长度需求。问题性能瓶颈排查使用top或htop观察Nginx worker进程的CPU和内存占用。使用ab或wrk进行压测。解决优化ModSecurity规则禁用一些不必要或误报率高的CRS规则。调整SecRequestBodyInMemoryLimit和SecRequestBodyLimit避免过大的请求体完全进入内存扫描。升级硬件或考虑将WAF层独立部署到性能更强的机器上。安全配置是一个动态平衡的过程。没有一劳永逸的规则只有基于持续监控和业务理解的不断优化。从“Dify部署”完成到构建起这道安全网关你可能需要花费数天时间进行规则调优但这份投入对于保护你的AI应用和数据资产来说是绝对值得的。
