一项研究发现，超过1100个基于 Ollama 框架的大型语言模型（LLM）服务器因配置不当而暴露在公共互联网上。其中约20%的服务器正运行着易受未经授权访问的模型。这些发现揭示了在部署人工智能系统时，普遍忽视了基本的安全措施，如身份验证和网络隔离，并强调了为 LLM 基础设施制定标准化安全基线的紧迫性。
问题的根源：便利性优先于安全性
大型语言模型（LLM）的快速普及往往超过了相应安全措施的制定。许多自托管的 LLM 解决方案在上线时没有经过充分的安全加固，常常因为默认配置、缺少身份验证或网络隔离不足而暴露其服务端口。
这种现象不仅是部署习惯不佳的产物，也反映出整个生态系统在很大程度上优先考虑了易用性和性能，而非安全性。由此导致了不断扩大的攻击面，可能引发多种风险：
- 未经授权的 API 访问： 任何人都可以向没有身份验证的服务器提交查询。
- 模型提取攻击： 攻击者可通过反复查询来重建模型参数。
- 越狱和内容滥用： 操纵模型生成错误信息、恶意代码或有害内容。
- 资源劫持： 攻击者可以利用开放的模型进行免费计算，导致主机产生高昂成本。
- 后门注入和模型投毒： 利用不安全的端点引入恶意负载或远程加载不受信任的模型。
这项研究重点关注 Ollama 框架，因为它因其易用性和本地部署能力而广受欢迎。然而，其默认部署方式和文档并未明确强调安全最佳实践，使其成为一个值得分析的目标。
如何发现暴露的服务器
研究人员使用 Shodan（一个用于搜索联网设备的搜索引擎）来识别暴露的 Ollama 服务器，从而避免了直接扫描远程系统可能带来的道德和隐私风险。
该过程分为两个阶段：
- 识别服务器： 通过查询与 Ollama 相关的默认端口（
11434）和独特的网络签名（服务横幅）来发现潜在目标。 - 评估安全状况： 对每个已识别的端点进行程序化查询，以评估其是否需要身份验证或以其他方式限制访问。
研究人员发现，一个名为 Uvicorn 的轻量级 Python Web 服务器是另一个有力的指标。许多 Ollama 实例都使用它，其 HTTP 响应头中的 Server: "uvicorn" 字段成为一个可靠的次要识别特征。
主要发现：上千个实例暴露在外
扫描结果证实了最初的假设：大量 Ollama 服务器暴露在公网并易受攻击。
- 发现数量： 共识别出 1,139 个 易受攻击的 Ollama 实例。值得注意的是，超过1000个实例是在扫描开始后的10分钟内发现的，凸显了问题的普遍性。
- 地理分布： 大部分暴露的服务器位于美国（36.6%），其次是中国（22.5%）和德国（8.9%）。
- 活动模型： 在所有暴露的服务器中，有 214 个（约 18.8%） 正在托管活动模型并响应请求，其中最常见的是 Mistral 和 LLaMA。
- 休眠风险： 其余约80%的服务器虽然没有运行活动模型，但其接口仍然暴露，容易受到未经授权的模型上传或配置操纵等攻击。
一个额外的发现是，88.89%的暴露端点遵循了与 OpenAI 兼容的 API 结构。这种标准化虽然简化了互操作性，但也为自动攻击框架提供了便利，使其能够以最小的改动攻击多个平台。
关键的缓解策略
为保护 LLM 基础设施，必须采取分层的防御策略。
- 强制执行身份验证和访问控制： 这是最关键的一步。绝不能在没有安全 API 密钥或基于令牌的身份验证的情况下公开 LLM 服务器。最好将身份验证与基于角色的访问控制（RBAC）相结合。
- 网络分段和防火墙： 应将 LLM 端点部署在防火墙、VPC 或反向代理之后，并将其访问权限限制在受信任的 IP 范围或 VPN 内。
- 实施速率限制和滥用检测： 集成 API 网关来限制请求频率，可以有效阻止暴力破解、提示注入或资源劫持等自动化攻击。
- 禁用默认端口和混淆服务信息： 更改默认端口（如 Ollama 的 11434）并从 HTTP 响应中删除 “Ollama” 或 “uvicorn” 等识别信息，可以增加扫描和识别的难度。
- 保护模型上传渠道： 如果支持动态上传模型，该功能必须经过严格的身份验证和审计，以防止模型投毒或后门注入。
- 持续监控和自动化审计： 使用自动化工具定期检查 LLM 端点是否被公开、配置错误或缺少身份验证。