近年来,大型语言模型(LLM)技术以前所未有的速度发展,并逐渐渗透到各行各业。与此同时,本地部署 LLM 的需求也日益增长。Ollama,作为一款便捷的本地大模型部署工具,因其易用性和对 DeepSeek 等先进模型的支持而备受开发者和技术爱好者的青睐。
然而,在追求技术便利的同时,安全风险往往容易被忽视。部分用户在本地部署 Ollama 服务后,可能由于配置不当或安全意识薄弱,使得 Ollama 服务端口暴露在互联网之上,为潜在的安全风险埋下了伏笔。本文将由浅入深地剖析这一安全隐患,并提供相应的防范措施。
1. Ollama 的便捷与潜在的安全隐患
Ollama 的出现,降低了本地部署和使用大型语言模型的门槛,用户可以轻松地在个人电脑或服务器上运行 DeepSeek 等高性能模型。这种便捷性吸引了大量用户,但同时也带来了一个不容忽视的问题:默认配置下的 Ollama 服务,可能存在被互联网非授权访问的风险。
具体来说,如果用户在部署 Ollama 服务时,没有进行必要的安全配置,例如限制监听地址或设置防火墙规则, 那么 Ollama 默认监听的 11434 端口就可能对外开放。这意味着,任何互联网用户都有可能通过网络访问到你的 Ollama 服务,并免费使用你的计算资源,甚至可能造成更严重的安全问题。
2. 如何发现互联网上暴露的 Ollama 服务?—— FOFA 搜索引擎
要了解互联网上 Ollama 服务暴露的程度,以及潜在的风险范围,我们需要借助网络空间搜索引擎。FOFA 就是这样一款强大的工具,它可以帮助我们快速检索并定位全球范围内公开暴露的网络服务。
通过精心构造 FOFA 搜索语句,我们可以有效地找到那些将 Ollama 服务端口暴露在互联网上的主机。例如,以下 FOFA 搜索语句可以用来查找开放 11434 端口且状态码为 200 的目标:
port="11434" && status_code="200"
执行上述搜索,FOFA 即可列出符合条件的目标 IP 地址,这些地址很可能运行着对外开放的 Ollama 服务。
3. 如何连接并“白嫖”开放的 Ollama 服务?—— ChatBox 与 Cherry Studio
一旦通过 FOFA 找到了开放的 Ollama 服务接口,接下来就可以使用客户端工具进行连接和交互。ChatBox 和 Cherry Studio 是两款常用的 AI 客户端软件,它们都支持连接 Ollama 服务,并进行模型调用和对话。
3.1 使用 ChatBox 连接开放 Ollama 服务
ChatBox 以其简洁易用而著称,连接开放 Ollama 服务的步骤非常简单:
- 下载并安装 ChatBox 客户端。
- 配置 API 地址: 在 ChatBox 设置中,将 API 地址设置为目标服务器的 IP 地址和端口,例如
http://目标IP:11434/
。 - 选择模型并开始对话: 配置完成后,即可选择模型并开始与远程 Ollama 服务进行对话。
3.2 使用 Cherry Studio 连接开放 Ollama 服务
Cherry Studio 功能更为全面,除了对话功能,还支持知识库管理等高级特性。连接步骤如下:
- 下载并安装 Cherry Studio 客户端。
- 配置 Ollama 接口: 在 Cherry Studio 的 “设置” → “模型服务” → “Ollama” 中,设置 API 地址为
http://目标IP:11434
。 - 添加并验证模型: 在模型管理页面添加目标模型,如 “deepseek-r1:1.5b”,并进行连接测试,成功后即可使用。
通过 ChatBox 或 Cherry Studio 等客户端,用户可以轻松连接到互联网上暴露的 Ollama 服务,并在未经授权的情况下免费使用他人的计算资源和模型能力。
随机获取了一个地址后,尝试原生支持读取 Ollama 模型的网页插件 Page Assist 中对话:
4. “免费午餐”背后的安全风险:算力盗用、数据泄露与法律隐患
看似“免费午餐”的背后,实则隐藏着诸多安全风险和潜在的法律问题:
- 算力盗用 (资源滥用): 最直接的风险就是 Ollama 服务提供者的 GPU 算力被他人无偿占用,导致资源浪费和性能下降。攻击者可能利用自动化脚本批量扫描并连接开放的 Ollama 服务,将其 GPU 变成训练恶意模型的 “血汗工厂”。
- 数据泄露: 如果 Ollama 服务中存储或处理了敏感数据,那么在开放的网络环境下,这些数据存在泄露的风险。用户的对话记录、训练数据等都可能在未加密的通道中传输,被恶意监听或窃取。
- 模型盗卖: 未加密的模型文件容易被下载和复制,如果 Ollama 服务中使用了具有商业价值的行业大模型,则可能面临模型被盗卖的风险,造成巨大的经济损失。
- 系统入侵: Ollama 服务自身可能存在安全漏洞,一旦被黑客利用,可能导致远程代码执行,攻击者可以完全控制受害者的服务器,将其变成僵尸网络的一部分,用于发起更大规模的网络攻击。
- 法律风险: 未经授权访问和使用他人的 Ollama 服务,甚至进行恶意利用,可能触犯相关法律法规,面临法律责任追究。
5. 中国用户更安全?—— 动态 IP 并非绝对屏障
有人认为, “中国用户由于独立 IP 持有量较少,因此在这种 ‘白嫖’ 风险中相对安全”。 这种观点具有一定的片面性。
诚然,与西方国家相比,中国家庭宽带用户使用动态 IP 的比例较高,这在一定程度上降低了暴露风险。动态 IP 的不确定性使得攻击者难以长期追踪和定位特定的用户。
但这绝不意味着中国用户可以高枕无忧。 首先,中国互联网环境中仍然存在大量的 Ollama 服务器,其中不乏使用固定 IP 的服务器。 其次,即使是动态 IP,在一定时间内也可能保持不变,攻击者仍然有可能在 IP 地址未更换的窗口期内进行攻击。 更重要的是,安全不能寄希望于 “运气” 或 “天然屏障”,而应该建立在主动的安全防护措施之上。
6. 本地 Ollama 服务安全防护指南:避免成为“肉鸡”
为了保护本地部署的 Ollama 服务不被他人滥用,用户需要采取积极有效的安全防护措施。以下是一些针对新手用户的操作指南:
6.1 限制 Ollama 服务监听地址
将 Ollama 服务的监听地址从默认的 0.0.0.0
修改为 127.0.0.1
,可以强制 Ollama 服务只监听来自本机的请求,拒绝来自外部网络的直接访问。 具体操作步骤如下:
- 查找配置文件: Ollama 的配置文件通常位于
/etc/ollama/config.conf
。打开该文件(如果不存在则需要创建),查找或添加bind_address
配置项。 - 修改绑定地址: 将
bind_address
的值设置为127.0.0.1
,并确保port
设置为11434
。完整的配置示例如下:bind_address = 127.0.0.1 port = 11434
- 保存并重启服务: 保存配置文件后,在终端中执行
sudo systemctl restart ollama
命令重启 Ollama 服务,使配置生效。
6.2 配置防火墙规则
通过配置防火墙规则,可以精确控制允许访问 Ollama 服务的 IP 地址范围和端口。 例如,可以只允许局域网内的 IP 地址访问 11434 端口, 阻止所有来自公网的访问请求。 以下分别介绍 Windows 和 Linux 环境下的防火墙配置方法:
Windows 环境配置步骤:
- 打开高级安全 Windows Defender 防火墙: 在 “控制面板” 中找到 “系统和安全”,点击 “Windows Defender 防火墙”,然后选择 “高级设置”。
- 创建新的入站规则: 在 “入站规则” 中点击 “新建规则…”,选择 “端口” 规则类型,点击 “下一步”。
- 指定端口和协议: 协议选择 “TCP”,特定本地端口设置为
11434
,点击 “下一步”。 - 选择操作: 选择 “允许连接”,点击 “下一步”。
- 配置作用域(可选): 可以根据需要配置规则作用域,一般保持默认设置即可,点击 “下一步”。
- 指定名称和描述: 为规则指定一个易于识别的名称(例如 “Ollama 服务端口限制”),并添加描述(可选),点击 “完成” 完成规则创建。
Linux 环境 (以 ufw 防火墙为例) 配置步骤:
- 启用 ufw 防火墙: 如果尚未启用 ufw,在终端中执行
sudo ufw enable
命令启用防火墙。 - 允许局域网访问: 执行
sudo ufw allow from 192.168.1.0/24 to any port 11434
命令,允许192.168.1.0/24
网段的 IP 地址访问 11434 端口。 请根据实际局域网网段修改 IP 地址范围。 - 拒绝其他访问(可选): 如果默认策略是允许所有外部访问,可以执行
sudo ufw deny 11434
命令,拒绝所有其他来源的 IP 地址访问 11434 端口。 - 查看防火墙状态: 执行
sudo ufw status verbose
命令,查看防火墙规则状态,确认配置已生效。
6.3 启用身份验证与访问控制
对于确需对外提供 Ollama 服务的场景,务必启用身份验证机制, 以防止未授权访问。 以下是一些常用的身份验证方法:
- HTTP 基本认证: 可以通过 Web 服务器(如 Apache 或 Nginx)配置 HTTP 基本认证。这种方式简单易用,但安全性相对较低,适用于对安全性要求不高的场景。 配置基本认证后,用户在访问 Ollama 服务时需要提供用户名和密码。
- API 密钥: 在 Ollama 服务前端增加 API 密钥验证机制。 客户端在请求 Ollama 服务时,需要在请求头或请求参数中包含预先设定的 API 密钥。 服务器端验证密钥的有效性,只有密钥正确的请求才会被处理。 这种方式比基本认证更安全,且易于集成到应用程序中。
- OAuth 2.0 等更高级的认证授权机制: 对于安全性要求更高的场景,可以考虑使用 OAuth 2.0 等更复杂的认证授权框架。 OAuth 2.0 提供了完善的授权和身份验证流程,支持多种授权模式,可以实现细粒度的访问控制。 但配置和集成 OAuth 2.0 相对复杂,需要一定的开发工作量。
选择哪种身份验证方式,需要根据 Ollama 服务的应用场景、安全需求以及技术实现成本等因素综合考虑。
6.4 使用反向代理
使用反向代理服务器(如 Nginx)可以作为 Ollama 服务的前端, 隐藏 Ollama 服务的真实 IP 地址和端口,并提供额外的安全防护功能,例如:
- 隐藏后端服务器: 反向代理服务器充当 Ollama 服务的 “门面”,外部用户只能看到反向代理服务器的 IP 地址,无法直接访问 Ollama 服务所在的真实服务器,从而提高了安全性。
- 负载均衡: 如果 Ollama 服务部署在多台服务器上,反向代理服务器可以实现负载均衡,将用户请求分发到不同的服务器,提高服务的可用性和性能。
- SSL/TLS 加密: 反向代理服务器可以配置 SSL/TLS 证书,实现 HTTPS 加密访问,保护数据传输的安全性。
- Web 应用防火墙 (WAF): 一些反向代理服务器集成了 WAF 功能,可以检测和防御常见的 Web 攻击,例如 SQL 注入、跨站脚本攻击 (XSS) 等,进一步增强 Ollama 服务的安全性。
- 访问控制: 反向代理服务器可以配置更灵活的访问控制策略,例如基于 IP 地址、用户身份、请求内容等进行访问控制。
7. 结语:安全意识与责任同行
Ollama 等本地部署大模型工具的普及,为技术创新和应用带来了便利,但同时也对网络安全提出了新的挑战。 “免费使用” 互联网上暴露的 Ollama 服务看似诱人,实则暗藏风险。 这种行为不仅可能触犯法律法规和网络道德,更可能对自身和他人的网络安全造成威胁。
对于 Ollama 服务部署者而言,提升安全意识,采取必要的安全防护措施,是保护自身算力资源和数据安全, 也是维护健康网络环境的责任所在。 切勿因为一时的疏忽,将自己的服务器变成 “算力肉鸡”,甚至成为网络攻击的帮凶。
在享受技术红利的同时,每一位互联网用户都应当时刻保持警惕, 树立正确的网络安全观, 共同构建安全、可信、可持续的 AI 应用生态。
风险再次警示:请立即检查并加固你的 Ollama 服务!安全无小事!
DeepSeek 模型和 Ollama 工具的流行,无疑是人工智能技术发展的一个缩影。 但技术进步的道路上,安全永远是不可忽视的基石。 请 Ollama 用户立即检查你的本地部署配置, 评估潜在的安全风险, 并采取必要的加固措施。 亡羊补牢,犹未为晚。
对于尚未安装 Ollama 或正在考虑部署 Ollama 的用户,也务必充分认识到本地部署大模型工具的安全风险, 审慎评估自身的技术能力和安全防护水平, 在确保安全的前提下合理使用。 切记,网络安全,人人有责,防范于未然,才是最佳策略。