Proteger seu servidor Ollama: autenticação, proxy reverso, exposition

#Por que proteger Ollama é urgente

O Ollama não possui autenticação nativa. O daemon escuta e atende requisições, ponto final: ele parte do pressuposto de que apenas um cliente de confiança na máquina local se comunica com ele. Esse modelo funciona enquanto o acesso permanece restrito a http://localhost:11434. O problema surge assim que uma variável de ambiente é alterada para tornar o serviço acessível pela rede — uma ação comum para conectar uma interface remota ou outra máquina.

Ao definir OLLAMA_HOST como 0.0.0.0, você instrui o daemon a escutar em todas as interfaces de rede. Se a porta 11434 não estiver filtrada por um firewall, a API fica aberta para toda a rede local, ou até para a internet inteira, caso a máquina tenha um IP público ou um redirecionamento de porta no roteador. Sem senha, sem token: qualquer pessoa pode enviar requisições, baixar ou excluir seus modelos e consumir os recursos da sua GPU.

#O que a API Ollama realmente expõe

Antes de proteger qualquer coisa, é necessário entender a extensão da superfície de ataque. A API Ollama não é apenas um endpoint de chat: é uma API de administração completa, sem distinção de privilégios. Um cliente anônimo tem exatamente os mesmos direitos que você.

/api/generate et /api/chat

Geração de texto. Usa sua GPU à vontade e tem acesso a todos os prompts — portanto, potencialmente a dados sensíveis inseridos por suas próprias aplicações.

/api/tags

Lista todos os modelos instalados. Um atacante sabe imediatamente o que você hospeda, incluindo seus possíveis fine-tunes internos.

/api/pull

Baixa qualquer modelo de um registro. Um terceiro pode ocupar todo o espaço do seu disco ou instalar um modelo malicioso.

/api/delete

Remove modelos. Exclusão de dados possível sem autenticação.

/api/create et /api/push

Criação de modelos a partir de um Modelfile e envio para um registro. Apropriação completa da instância.

/v1/*

Camada compatível com OpenAI na mesma porta. A mesma ausência de controle de acesso; pode ser usada por qualquer cliente OpenAI padrão.

#Verificar se o seu Ollama está exposto

Comece com um diagnóstico honesto. O objetivo: saber em quais interfaces o daemon está escutando e se a porta pode ser acessada de fora. Três verificações, da mais local à mais externa.

Primeiro, verifique em quais endereços o processo está escutando. Escutar em 127.0.0.1 é uma configuração adequada; escutar em 0.0.0.0 ou em um endereço IP de rede significa que o serviço aceita conexões remotas.

# Voir sur quelle interface Ollama écoute (Linux)
ss -tlnp | grep 11434

# Alternative si ss n'est pas disponible
sudo lsof -i :11434

# Vérifier la variable qui contrôle l'écoute
systemctl show ollama --property=Environment 2>/dev/null | grep -i host
echo $OLLAMA_HOST

Em seguida, teste a partir de outra máquina da rede. Substitua IP_DU_SERVEUR pelo endereço local da máquina que executa o Ollama. Se o comando retornar a lista de modelos, a instância está acessível pela rede — o que é aceitável em uma LAN confiável, mas nunca sem filtragem no acesso pela internet.

# Depuis un autre poste du réseau local
curl http://IP_DU_SERVEUR:11434/api/tags

# Réponse = liste JSON des modèles => l'instance répond aux tiers

Por fim, verifique a exposição pública. Se a sua máquina tiver um IP público ou um redirecionamento de porta ativo, procure por ela em um mecanismo de busca de dispositivos como Shodan ou Censys. Uma consulta simples à porta 11434 e ao banner do Ollama revela se a sua instância já está indexada. Você também pode testar seu IP público diretamente.

# Récupérer votre IP publique
curl -s https://api.ipify.org; echo

# Tester si le port 11434 répond depuis internet (depuis un réseau externe,
# ex. partage 4G du téléphone, pas depuis le LAN)
curl http://VOTRE_IP_PUBLIQUE:11434/api/tags

#Etapa 1 — Voltar a escutar em localhost

A primeira medida, e muitas vezes a única necessária, consiste em restaurar o comportamento padrão do Ollama: escutar apenas na interface de loopback. Não há motivo para expor a porta diretamente se você colocar um proxy reverso à frente dele. O proxy se comunicará com o Ollama localmente, e o mundo externo se comunicará apenas com o proxy.

No Linux, o Ollama é executado como um serviço systemd. A variável OLLAMA_HOST é configurada por meio de uma substituição da configuração do serviço (override), que permanece após as atualizações do pacote.

1. 01
   Editar a configuração de sobrescrita do serviço

   Abra o editor de sobrescrita do systemd para o serviço ollama. Isso cria um arquivo drop-in limpo sem alterar o serviço original.
2. 02
   Forçar a escuta local

   Defina OLLAMA_HOST como 127.0.0.1:11434. O daemon então recusará qualquer conexão vinda da rede.
3. 03
   Recarregar e reiniciar

   Recarregue a configuração do systemd e depois reinicie o serviço para aplicar a variável.
4. 04
   Confirmar

   Verifique novamente com ss -tlnp | grep 11434: o endereço deve ser 127.0.0.1 e não 0.0.0.0

# Ouvre un éditeur pour un drop-in override
sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama

# L'écoute doit revenir sur 127.0.0.1
ss -tlnp | grep 11434

#Etapa 2 — Adicionar autenticação via reverse proxy

Como o Ollama não oferece autenticação, delegamos essa responsabilidade a um proxy reverso colocado à frente dele. O proxy exige uma identificação, verifica o tráfego e então o encaminha ao Ollama localmente. Duas opções comprovadas: Caddy (configuração mínima, TLS automático) e nginx (amplamente utilizado, muito bem documentado).

#Opção A — Caddy (recomendado pela simplicidade)

Caddy gerencia o TLS automaticamente via Let's Encrypt e oferece autenticação básica em poucas linhas. Gere primeiro um hash da senha e depois use esse hash no Caddyfile. Nunca armazene a senha em texto claro.

# Génère un hash bcrypt à coller dans le Caddyfile
caddy hash-password --plaintext 'VotreMotDePasseFort'

ollama.mondomaine.fr {
    # Authentification basique (utilisateur : admin)
    basic_auth {
        admin $2a$14$le_hash_genere_ci_dessus
    }

    # Relais vers Ollama en local
    reverse_proxy 127.0.0.1:11434
}

Com um nome de domínio apontando para o seu IP público e as portas 80/443 abertas, o Caddy obtém e renova sozinho o certificado TLS. O cliente deverá fornecer o identificador em cada requisição pelo cabeçalho Authorization.

# L'accès nécessite désormais des identifiants
curl -u admin:VotreMotDePasseFort https://ollama.mondomaine.fr/api/tags

#Opção B — nginx

O nginx exige um arquivo de senhas separado, gerado com htpasswd, seguido de um bloco server que aplica a autenticação e encaminha as requisições para o Ollama. Isso é mais verboso, mas muito comum, especialmente quando o nginx já atende outros serviços.

# Paquet apache2-utils (Debian/Ubuntu) ou httpd-tools (Fedora)
sudo htpasswd -c /etc/nginx/.ollama_htpasswd admin

server {
    listen 443 ssl;
    server_name ollama.mondomaine.fr;

    ssl_certificate     /etc/letsencrypt/live/ollama.mondomaine.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.mondomaine.fr/privkey.pem;

    location / {
        auth_basic           "Ollama";
        auth_basic_user_file /etc/nginx/.ollama_htpasswd;

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;

        # Le streaming des tokens ne doit pas être bufferisé
        proxy_buffering off;
        proxy_read_timeout 600s;
    }
}

#Etapa 3 — Criptografar o tráfego (TLS)

A autenticação básica transmite o identificador codificado em base64: sem TLS, ele circula quase em texto claro e é facilmente capturado. Portanto, a criptografia do transporte não é opcional quando você sai do localhost. Dois cenários, dependendo de você ter um nome de domínio público ou não.

Domínio público + portas 80/443

Let's Encrypt via Caddy (automático) ou certbot para nginx. Certificado reconhecido, sem aviso no navegador, renovação automática.

Rede interna sem domínio público

Certificado autoassinado ou autoridade interna (mkcert). Os clientes devem confiar no certificado, mas o tráfego permanece criptografado na rede local.

Atrás de uma VPN

O túnel VPN já cifra tudo. O TLS continua recomendado como defesa em profundidade, mas é menos crítico, pois ninguém de fora consegue acessar o proxy.

# Obtenir et installer le certificat, avec renouvellement automatique
sudo certbot --nginx -d ollama.mondomaine.fr

# Tester le renouvellement à blanc
sudo certbot renew --dry-run

#Etapa 4 — Acesso remoto bem configurado: VPN e Tailscale

A pergunta mais importante: você realmente precisa expor o Ollama na internet? Na grande maioria dos casos, não. Você quer acessá-lo a partir dos seus próprios dispositivos, não pela web aberta. Uma rede privada (VPN) atende exatamente a essa necessidade sem jamais expor a porta publicamente.

O Tailscale é a opção mais simples: ele cria uma rede mesh criptografada (WireGuard) entre suas máquinas, com IPs privados estáveis. O Ollama passa então a escutar apenas na interface Tailscale, e somente seus dispositivos autenticados na sua tailnet podem acessá-lo. Nenhum redirecionamento de porta, nenhum IP público exposto.

1. 01
   Instalar o Tailscale no servidor

   Instale o cliente e conecte a máquina ao seu tailnet. Ela recebe um endereço IP privado no formato 100.x.y.z, acessível apenas por seus outros dispositivos autenticados.
2. 02
   Vincular o Ollama à interface Tailscale

   Configure OLLAMA_HOST com o IP do Tailscale da máquina (ou mantenha 127.0.0.1 e exponha o serviço via Tailscale Serve). A porta é acessível apenas no tailnet.
3. 03
   Instalar o Tailscale nas suas máquinas clientes

   Suas outras máquinas entram no mesmo tailnet e acessam o Ollama pelo endereço IP 100.x.y.z dele, onde quer que você esteja, sem abrir nenhuma porta no roteador.
4. 04
   Verificar o isolamento

   A partir de uma rede externa fora da tailnet, a porta deve ser totalmente inacessível. Esse é o comportamento esperado.

# Installation (Linux)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Récupérer l'IP Tailscale de la machine
tailscale ip -4

# Exposer Ollama proprement dans le tailnet (HTTPS + identité tailnet)
tailscale serve --bg 11434

Se você faz questão de uma VPN tradicional, o WireGuard auto-hospedado oferece o mesmo resultado com mais controle: você configura o túnel, vincula o Ollama à interface wg0 e a porta permanece invisível a partir da internet. A escolha entre Tailscale e WireGuard puro depende principalmente da ponderação entre simplicidade e soberania total da infraestrutura.

#Reforço complementar da segurança da rede

Além do proxy e da VPN, algumas medidas de defesa em profundidade limitam os danos em caso de configuração incorreta. O princípio orientador: nunca depender de uma única camada.

Firewall rigoroso

Bloqueie o tráfego de entrada na porta 11434 em todas as interfaces, exceto loopback e VPN. Com ufw: bloquear a porta 11434 por padrão, permitir acesso apenas a partir da sub-rede Tailscale/WireGuard.

Sem redirecionamento de porta

Nunca configure o encaminhamento da porta 11434 no modem/roteador. Se você tiver configurado um “para testar”, remova-o: essa é a causa número 1 de instâncias expostas.

Limitação da taxa de requisições

No proxy reverso, aplique uma limitação da taxa de requisições para mitigar um possível abuso mesmo após a autenticação (nginx limit_req, Caddy rate_limit).

Senhas fortes e rotação

A segurança da autenticação básica depende apenas da robustez da senha. Use senhas longas e troque-as se um computador cliente for comprometido.

Registro

Ative os logs de acesso do proxy para detectar tentativas anômalas. Uma instância saudável recebe apenas suas requisições.

# Refuser l'accès direct au port depuis le réseau
sudo ufw deny 11434

# N'autoriser que le sous-réseau Tailscale (exemple)
sudo ufw allow from 100.64.0.0/10 to any port 11434

sudo ufw status verbose

#Solução de problemas

403 Forbidden atrás do proxy

O Ollama rejeita o cabeçalho Host. Force o valor de Host para localhost:11434 no proxy ou defina OLLAMA_ORIGINS para autorizar seu domínio.

O streaming trava ou chega de uma só vez

O proxy mantém a resposta em buffer. Desative o buffering (proxy_buffering off no nginx) e aumente o timeout de leitura para gerações longas.

curl funciona, mas não a partir de outra máquina

O Ollama ainda está escutando em 127.0.0.1 enquanto o proxy está em outro lugar, ou o firewall está bloqueando a porta 443 do proxy. Verifique ss -tlnp e as regras do ufw.

Falha no certificado Let's Encrypt

A porta 80 deve estar acessível pela internet para a validação HTTP-01, e o domínio deve apontar para o endereço IP correto. Verifique o DNS e a abertura da porta 80.

Tailscale: Ollama inacessível no tailnet

Ollama escuta em 127.0.0.1 sem tailscale serve. Vincule OLLAMA_HOST ao IP 100.x ou exponha o serviço usando tailscale serve 11434.

Ainda visível no Shodan após a correção

O índice leva tempo para se atualizar. Confirme primeiro você mesmo, a partir de uma rede externa, que a porta está fechada; a indexação será atualizada depois.

#Para se aprofundar

Proteger o acesso é apenas uma parte do conjunto. Estes guias complementam este guia nos aspectos de implantação e conformidade:

Implantar um chatbot de IA para sua equipe na intranet

O caso de uso típico em que esse reforço de segurança se aplica: Ollama + Open WebUI com múltiplos usuários por trás de um proxy reverso autenticado.

Implantar um LLM em produção com Docker Compose

Stack completa Ollama + Traefik em que o proxy reverso e o isolamento de rede são gerenciados desde a concepção.

LLM local e RGPD: conformidade na proteção de dados privados nas empresas

A contrapartida regulatória: uma exposição não controlada também representa um risco de vazamento de dados pessoais que deve ser documentado.