# 关于 ollama 的 11434 等端口 的“漏洞”
*开源技术栏*

Ollama 11434 端口安全漏洞 无需担心，11434 无 apikey 导致算力泄露事件的问题
我们提供了完整的分析及解决方案

## 目录

[TOC]


![35b66030ec00d0ef86da5c83b317666d7586d97697ddf9f7d6c153d03fcd5376](https://diskmirror.lingyuzhao.top/DiskMirrorBackEnd/FsCrud/downLoad/4/Binary?fileName=Article/Image/4120249802229778/35b66030ec00d0ef86da5c83b317666d7586d97697ddf9f7d6c153d03fcd5376.webp)


# 一、安全风险原因

> 请注意，此问题几乎无法对服务器造成任何伤害，不必因此惊慌，营销号傻*，将此问题夸大其词，如果您完全知道如何处理此问题，请移步~

> 本教程虽然探讨的是关于 ollama 的 11434 端口泄露问题，本质上都是端口无校验导致的问题，此文章适用于所有端口无校验因此的算力或数据泄露情况！

## 1 无APIKey验证机制

Ollama默认开放的11434端口未强制要求APIKey验证，任何能访问该端口的客户端均可直接调用API接口4。这使得攻击者可通过扫描IP和端口发起未授权访问，导致模型滥用、数据泄露或服务资源耗尽1。

## 2 暴露敏感操作接口

该端口提供模型管理、生成等核心功能，若未设防，攻击者可：

## 3 任意下载/删除模型

窃取生成内容
发起DDoS攻击导致服务瘫痪
默认网络配置宽松
部分部署场景下（如Docker容器），11434端口可能直接暴露在公网，加剧风险2。

# 二、修复方案

## 1 网络层防护

```
# 使用防火墙限制访问IP（示例）
sudo ufw allow from 192.168.1.0/24 to any port 11434
```
通过IP白名单机制限制访问范围，仅允许可信网络访问2。

## 2 反向代理+认证
使用Nginx添加Basic Auth：
```
server {
    listen 443 ssl;
    location / {
        proxy_pass http://localhost:11434;
        auth_basic "Ollama API";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}
```
生成密码文件：`htpasswd -c /etc/nginx/.htpasswd username`

## 3 容器化部署增强
在docker-compose中配置网络策略：
```
Yaml
services:
  ollama:
    networks:
      - internal_network
    environment:
      - OLLAMA_HOST=0.0.0.0:11434

networks:
  internal_network:
    internal: true
```

禁止外部直接访问，仅允许内部服务通信。

## 4 客户端集成认证

调用时添加自定义Header：

```Python
import requests
response = requests.post(
    "http://localhost:11434/api/generate",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={"model": "llama2", "prompt": "Hello"}
)
```
需配合服务端中间件进行验证。当发现携带信息不符合 直接不处理！

## 5 更换云或其它本地框架

您可以更换使用 [码本API](https://www.lingyuzhao.top/b/Article/377388518747589)，也可以使用其它的三方框架，他们或许提供了一些更好的方案!

------
***操作记录***
作者：[zhao](https://www.lingyuzhao.top//index.html?search=4 "zhao")
操作时间：2025-03-14 17:43:31 星期五 【时区：UTC 8】
事件描述备注：保存/发布
 中国 天津 
[](如果不需要此记录可以手动删除，每次保存都会自动的追加记录)