随着大语言模型在企业级应用中的快速普及，AI 推理基础设施的安全边界正在经历前所未有的挑战。2026 年 1 月底，SentinelOne 与 Censys 的联合调查报告揭示了一个令人警醒的事实：超过 17.5 万个 Ollama 实例正在公网中暴露，分布于 130 个国家或地区，其中近半数启用了具备代码执行能力的工具调用功能。这一发现不仅暴露了开源 AI 部署框架在安全设计上的系统性缺陷，更揭示了攻击者如何利用自动化工具形成完整的犯罪产业链。
暴露规模与地理分布：从边缘到核心的基础设施危机
Ollama 作为最受欢迎的本地大语言模型部署框架之一，凭借其简洁的安装体验和跨平台支持，已被全球数百万开发者用于快速启动和运行 LLaMA、Mistral 等主流模型。然而，正是这种 "开箱即用" 的设计理念，使得安全配置往往被用户忽视。默认情况下，Ollama 仅监听本地回环地址 127.0.0.1:11434，这一隔离设计本意是确保服务仅限本地访问。然而，安全研究人员发现，只需将绑定地址修改为 0.0.0.0 或公网接口，一个完全开放且无需认证的 AI 推理端点便可能暴露于整个互联网。
SentinelOne 与 Censys 的联合调查揭示了这一风险的全球性规模。在 130 个被检测到存在暴露实例的国家或地区中，中国大陆以超过 30% 的占比位居首位，美国、德国、法国、韩国、印度、俄罗斯、新加坡、巴西和英国紧随其后。值得注意的是，这些暴露实例并非全部位于云端数据中心 —— 相当比例的 IP 段被识别为 residential（住宅网络），意味着大量普通用户的个人设备正在无意中成为 AI 推理服务的公共入口。这种分布特征不仅模糊了企业安全边界，更给传统的网络治理和威胁追踪带来了全新挑战。
认证机制缺失：设计理念与安全现实的鸿沟
深入分析 Ollama 的安全架构，不难发现其默认配置中缺少身份验证和访问控制功能这一核心问题。NSFOCUS 于 2025 年 3 月披露的 CNVD-2025-04094 漏洞公告明确指出，由于 Ollama 未默认启用身份认证机制，当用户将服务绑定地址从 127.0.0.1 改为 0.0.0.0 使其可被公网访问时，任何攻击者都可以直接调用其 API 接口，实现敏感模型资产的窃取、虚假信息的注入、系统配置的篡改，以及推理资源的滥用。
这一设计选择反映了开源工具开发中普遍存在的 "便捷优先" 思维。Ollama 的文档和用户指南更多聚焦于如何快速下载、运行和管理模型，而非如何安全地部署这些服务。对于企业安全团队而言，这意味着在将 Ollama 引入生产环境之前，必须额外投入精力设计和实施多层防护措施，包括但不限于 API 网关、OAuth2.0 认证、IP 白名单等。而许多个人开发者和小型团队往往缺乏这方面的安全意识和专业能力，导致大量未加防护的实例直接暴露于公网。
工具调用功能的威胁升级：从文本生成到系统控制
在 17.5 万个暴露实例中，近 48% 启用了工具调用（Function Calling）能力 —— 这一数据将安全风险从内容生成层面直接提升至系统控制层面。工具调用是现代大语言模型的核心能力之一，它允许模型通过预定义的接口与外部系统、API 和数据库进行交互，从而获取实时数据或执行特权操作。在企业级应用中，这一能力被广泛用于构建智能助手、自动化工作流和 API 集成。
然而，当具备工具调用能力的模型被部署在无认证的公网实例上时，威胁模型发生了根本性变化。SentinelOne 研究人员在报告中指出："文本生成端点可能产生有害内容，但启用了工具调用的端点可以执行特权操作。当这一能力与认证缺失和网络暴露相结合时，我们评估其构成了该生态系统中最高级别的安全风险。" 攻击者不再局限于诱导模型生成恶意文本，而是可以借助模型作为代理，直接调用内部 API、访问敏感数据，甚至在某些配置下执行任意代码。
更令人担忧的是，研究人员还发现了 201 个运行着 "去审查提示模板" 的实例，这些模板移除了模型内置的安全护栏，进一步放大了滥用的可能性。在部分案例中，模型名称本身即可能暴露部署方的身份信息，为定向攻击提供了情报基础。
自动化扫描工具的工程实现：从发现到利用的完整链条
攻击者对暴露实例的利用并非随机行为，而是依托于高度自动化的扫描和验证工具。Cisco 安全团队的研究提供了一个典型的工程实现范例：他们开发了一款基于 Python 的自动化工具，利用 Shodan 搜索引擎识别暴露的 Ollama 实例，并通过一系列精心设计的探测步骤评估其安全风险。
扫描流程的第一阶段利用 Shodan API 检索运行在 Ollama 默认端口 11434 上的主机，并通过服务横幅（banner）中的特征关键词进行精确匹配。研究人员还发现，运行 Uvicorn ASGI 服务器的实例往往是 Ollama 部署的重要指示器，因为 Ollama 的异步 API 服务依赖于这一 Python Web 服务器。第二阶段通过发送简单的 API 请求验证认证状态 —— 例如发送一个数学问题 "2+2 等于几"，若返回正确结果，则表明该实例接受无认证的任意请求。在 Cisco 的测试中，扫描在最初的 10 分钟内便识别出超过 1000 个暴露实例，最终确认 1139 个存在无认证访问风险的 Ollama 服务器，其中约 20%（214 个）正在活跃托管和响应模型请求。
这种工具化的攻击模式已被犯罪组织规模化利用。Pillar Security 近期披露的 "Operation Bizarre Bazaar" 行动展示了完整的 LLMjacking（LLM 劫持）产业链：威胁行为者系统性地扫描互联网寻找暴露的 Ollama、vLLM 和 OpenAI 兼容 API 端点，验证其响应质量以评估可用性，随后通过一个名为 silver.inc 的统一 LLM API 网关将这些被劫持的资源以折扣价转售给下游买家。这种 "一条龙" 服务模式标志着 AI 基础设施滥用已从理论风险演变为商业化的网络犯罪。
工程防护策略：从边缘到核心的纵深防御体系
面对上述威胁，安全团队需要采取系统性的纵深防御策略，而非依赖单一的安全控制措施。首要原则是严格限制 Ollama 服务的网络暴露范围。对于仅需本地访问的场景，应通过环境变量OLLAMA_HOST=127.0.0.1强制绑定至本地回环地址，并使用sudo netstat -tulpn | grep 11434定期检查确认无 0.0.0.0 或：：：的监听配置。若确实需要跨网络访问，则必须部署至少一层认证机制：可以通过 Nginx 等反向代理实现 OAuth2.0 或 API Key 认证，或者利用云服务商的安全组和防火墙配置 IP 白名单，仅允许受信任的 IP 段访问 11434 端口。
在网络层之上，API 网关的引入提供了额外的安全控制平面。Kong、Amazon API Gateway 等解决方案可实现细粒度的速率限制、请求审计和异常行为监控，有效遏制自动化扫描和资源滥用行为。同时，建议禁用默认端口并在 HTTP 响应头中隐藏 Ollama 和 Uvicorn 等标识信息，增加攻击者的指纹识别成本。
持续监控同样不可或缺。安全团队应定期使用 Shodan Alert API 或自定义脚本对组织资产进行暴露面扫描，及时发现意外暴露的实例。NSFOCUS 提供的 EZ 自动化渗透测试工具已支持 Ollama 服务识别和未授权访问风险检测，可作为日常安全评估的辅助手段。对于已部署的模型，应启用模型签名验证和来源校验机制，防止通过 API 上传恶意模型或注入后门。
结语：AI 基础设施安全的范式转变
Ollama 大规模暴露事件折射出 AI 基础设施安全领域的范式转变。传统的企业安全模型以云服务商提供的托管服务为中心，内置了完善的身份认证、网络隔离和监控体系。然而，以 Ollama 为代表的本地化开源工具打破了这一范式 —— 它们运行在企业安全边界之外，部署于云端和住宅网络交织的复杂环境中，依赖用户而非专业安全团队进行配置和管理。
SentinelOne 研究人员指出，"随着大语言模型被部署到边缘以将指令转化为行动，它们必须被视为与其他外网可访问基础设施同等的安全对象。" 这一观点为 AI 安全实践指明了方向：零信任架构、持续验证、最小权限等原则需要被全面应用于 AI 推理基础设施的每一层。对于安全团队而言，这意味着将 AI 服务纳入资产清单、建立专门的安全基线、并针对这一新兴攻击面发展专门的检测和响应能力。
资料来源：
- The Hacker News - "Researchers Find 175,000 Publicly Exposed Ollama AI Servers Across 130 Countries"（2026 年 1 月 30 日）
- Cisco Security Blog - "Detecting Exposed LLM Servers: A Shodan Case Study on Ollama"（2025 年 9 月 1 日）
- NSFOCUS - "Ollama Unauthorized Access Vulnerability Due to Misconfiguration (CNVD-2025-04094)"（2025 年 3 月 13 日）