别让DeepSeek坑了你！本地部署模型真的安全吗？

1. 前言

自从ChatGPT掀起全球热潮之后，DeepSeek（深度求索）迅速崛起，成为又一现象级的AI产品。根据国内AI产品排行榜的最新统计，DeepSeek在上线短短20天内，日活跃用户数便突破了惊人的2000万，达到2215万。这股热潮不仅让DeepSeek火遍全球，也让其线上服务遭遇了前所未有的挑战：大规模的DDoS流量攻击频繁导致网页和API服务中断，甚至一度让用户无法完成注册。与此同时，由于在线用户激增，官方经常显示“服务器繁忙，请稍后再试”的提示，让不少用户望而兴叹。

面对如此热情的用户群体，许多人开始探索在本地部署DeepSeek模型的方法。然而，完整版的DeepSeek模型文件体积巨大，达到671B，对显存的要求极高。为此，许多教程推荐使用千问、Llama等蒸馏小模型，如32B和70B版本，以实现本地部署。

尽管市面上充斥着各种部署指南，本文的重点并不在于技术细节，而是聚焦于作者在尝鲜过程中发现的一些潜在安全风险，由于部署模型的机器上一般拥有较大算力，这些风险可能对数据安全和系统稳定性构成严重威胁，不容小觑。

2. 你的Ollama安全么？

Ollama是一个开源框架，专为在本地机器上便捷部署和运行大型语言模型（LLM）而设计。在众多教程中，Ollama以其一键部署的优点，深受欢迎。Ollama类似docker，也拥有模型仓库，包含一系列预先训练好的大型语言模型，用户可以直接选用这些模型应用于自己的应用程序，无需从头训练或自行寻找模型源。同时，Ollama还提供了一套简洁的 API，使得开发者能够轻松创建、运行和管理大型语言模型实例，降低了与模型交互的技术门槛。

在Ollama的配置中，可以调整API绑定情况，可以看到，默认情况下，Ollama API接口绑定在localhost:11434上：

通过API，可以直接和Ollama及部署的大模型进行交互，如下是查看当前机器运行模型的情况：

利用API向大模型提问经典问题：What color is the sky at different times of the day?

1

curl -X POST http://localhost:11434/api/generate -H "Content-Type: application/json" -d "{\"model\": \"deepseek-r1:70b\",\"prompt\": \"What color is the sky at different times of the day? Respond using JSON\",\"format\": \"json\",\"stream\": false}"

可以看到，Ollama的接口竟然没有鉴权，可以直接访问。为了方便调用，有开发者直接将API端口暴露出来，一旦将该端口暴露到公网，攻击者就可以直接利用接口调用模型，消耗资源造成浪费。利用Fofa进行搜索，看到Ollama API 公网暴露数量约4W+，搜索语法如下：

1

body="Ollama is running"

利用国外暴露的Ollama API接口，直接调用DS模型：

此外，根据Ollama官方文档，利用API还可以Push、Pull、Delete模型，危害较大：

在一些古早版本的Ollama上，还存在路径穿越导致的RCE问题，WIZ研究团队以做过相关研究，在此不做赘述，链接：https://www.wiz.io/blog/probllama-ollama-vulnerability-cve-2024-37032

API未授权这么严重的问题，为什么Ollama官方并没有进行修复呢？深入分析文档发现，官方推荐的部署方式是利用反向代理，进行访问限制，如通过nginx进行白名单过滤：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

server {
    listen 8080; # 代理监听端口
    server_name your_server_ip_or_domain;

    location / {
        proxy_pass http://127.0.0.1:11434; # Ollama 默认运行端口
        proxy_set_header Host $host;
        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;

        # 访问限制 - 只允许特定IP访问
        allow 192.168.1.100;
        deny all;
    }
}

不止Ollama，常见的LM Studio也有类似的问题，LM Studio支利用API与本地模型进行交互：

在fofa上搜索相关资产：

利用未授权的API与模型交互：

3. 模型保住了，就真的安全了么？

前面已经通过Ollama部署了一个本地LLM模型，假设我们也将Ollama API接口做了保护，那么就真的安全了么？

尽管 Ollama 能够在本地部署模型服务，以供其他程序调用，但其原生的对话界面是在命令行/API 中进行的，用户无法方便与 AI 模型进行交互，因此，开发者通常利用第三方的WebUI应用来使用 Ollama，以获得更好的体验。整体架构如下：

常见的UI框架有：LobeChat、Open WebUI、Enchanted、chatbox等，作者在选取较为火热的LobeChat框架作为研究对象进行展开。LobeChat 作为一款开源的 LLMs WebUI 框架，支持全球主流的大型语言模型，并提供精美的用户界面及卓越的用户体验。该框架支持通过本地 Docker 运行，亦可在 Vercel、Zeabur 等多个平台上进行部署。用户可通过配置接口地址，轻松实现集成。

根据LobeChat官方文档，其提供了Docker 镜像，几分钟部署自己的聊天机器人。快速部署模式：

https://github.com/lobehub/lobe-chat/blob/main/README.zh-CN.md#b-%E4%BD%BF%E7%94%A8-docker-%E9%83%A8%E7%BD%B2

部署好的截图：

可以看到，默认情况下整个系统并没有进行鉴权，用户可以直接使用前端页面。细心的读者可能已经看到，在运行docker镜像的时候，有一个ACCESS_CODE字段，根据官方文档，这个字段是应用的解锁密码，具体功能是当使用聊天功能时，需要用户输入该密码才能开启：

这里存在两个问题：

1、如果用户未配置ACCESS_CODE，攻击者可以直接调用LLM进行聊天。

2、如果用户配置了ACCESS_CODE，但使用的是官方提供的lobe66默认密码，攻击者也可以获取控制权。

那么再看一下公网上LobeChat的暴露情况：title="LobeChat"

可以看到，约有1w+资产部署在公网，根据前面的风险点，尝试调用：

除此之外，还有些类似的前端平台，如Llama Coder：title=“Llama Coder”

Serge：title=="Serge - Powered by LLaMA"

4. 设置了复杂密码，这回该安全了吧！？

根据前面提到的风险点，即便我们为前端设置了复杂密码来保护 LLM 不被其他用户调用，这就真的万无一失了吗？

进一步探索Lobechat官方提供的部署方式，还存在一种进阶部署模式docker-compose：

https://github.com/lobehub/lobe-chat/blob/main/docker-compose/local/docker-compose.yml

这种部署方式和SSO相结合，供企业 / 组织内部使用，统一管理用户授权。官方提供的CAS应用为：casdoor。Casdoor‌ 是一个轻量级的身份认证和授权平台，支持多种协议（如OIDC、OAuth2、SAML、CAS等），并提供单点登录（SSO）功能。它支持多种登录方式，包括密码登录、短信/邮件验证码登录以及社交登录（如Google、GitHub等）‌。

部署截图如下：

如果统一身份认证平台存在漏洞，那么后果不堪设想。作者在最近的漏洞预警工作中，跟踪到Casdoor‌≤1.811.0的一个任意用户添加漏洞，在未授权情况下，攻击者可以通过添加用户接口添加管理员用户，获取系统控制权。本地环境复现：

添加管理员用户，并在casdoor统一身份认证后台登录：

至此，系统级控制权+LLM操控权限双重沦陷，敏感模型及算力遭“立体化收割”。

在进一步对公网上的资产进行浏览时发现，有部分LLM代理聚合平台（汇聚全球AI模型API，灵活选择OpenAI、GPT、Claude等顶级模型API，实现敏捷开发）前端采用Lobechat部署，并利用CAS统一身份认证实现付费用户与免费用户角色划分，一旦此类平台失陷，攻击者可获取全平台SK资源，调用任意模型API，造成重大经济损失。

5. 进阶使用：模型微调工具也不安全吗？

对于普通大众来说，进行大模型的预训练或者全量微调遥不可及。由此，催生了各种参数高效微调技术，让科研人员或者普通开发者有机会尝试微调大模型。‌模型微调‌是指对预训练好的大型语言模型（LLM）进行进一步训练，使用更小、更具体的数据集，以增强其在特定领域任务上的表现。微调的目的是将通用模型转变为专用模型，弥合通用预训练模型与特定应用需求之间的差距，确保语言模型更贴近人类的期望。‌

常见的微调工具有：Llama-Factory、Unsloth、Swift、Firfly、Xtuner等。

这里以Llama-Factory为例，Llama-Factory提供了Web UI模式，可以实现使用零代码微调百余种大模型，WebUI 主要分为四个界面：训练、评估与预测、对话、导出。开启Web UI的命令：

1

llamafactory-cli webui

利用指纹搜索公网开放的webui：body="LLaMA Board"，存在同样的问题。

6. 模型应用部署的“最后一击”

在模型微调完成后，需要部署成应用方便用户使用。Gradio是一个创新的Web平台，让开发者能够为他们的模型建立交互式演示界面。该平台通过提供易于使用的界面来简化模型的展示过程，使得非专业用户也能轻松地体验和利用前沿的机器学习技术。用户可以通过简单的Python代码，快速创建出交互式的Web应用界面。Gradio支持多种输入和输出选项，包括文本、图像和音频等数据类型。产品不仅支持Jupyter笔记本的嵌入，还可以通过生成的公开链接让其他用户远程互动，或者将应用托管在Hugging Face上。

Gradio应用指纹：icon_hash="55115683"

以其中一个为例，调用后端模型：

事实上，官方以提供简易认证的方式增强Gradio的安全性，但仍有大量实例未授权在公网暴露：

1
2
3
4
5
6
7
8
9

demo
 .queue(concurrency_count=3)
 .launch(server_name='0.0.0.0',
         server_port=8082,
         show_api=False,
         share=False,
         inbrowser=False,
         auth=("zhangsan", '123456'),
         )

7. 总结

这篇文章从热度较高的DeepSeek模型本地部署入手，主要讨论了在本地部署DeepSeek模型时可能遇到的安全风险。文章通过分析推理框架部署安全到前端UI框架，从模型微调工具到应用部署，揭示了几个潜在的安全问题，希望为读者在本地化部署大模型时提供有价值的安全参考和应对策略。