Mettere in sicurezza il proprio server Ollama: autenticazione, reverse proxy, exposition

#Perché proteggere Ollama è urgente

Ollama non dispone di alcuna autenticazione nativa. Il demone resta in ascolto e gestisce le richieste, tutto qui: presuppone che a comunicare con lui sia soltanto un client fidato sulla macchina locale. Questo modello regge finché si rimane su http://localhost:11434. Il problema si presenta non appena si modifica una variabile d'ambiente per rendere il servizio accessibile dalla rete — un'operazione comune per collegare un'interfaccia remota o un'altra macchina.

Impostando OLLAMA_HOST su 0.0.0.0, si chiede al daemon di ascoltare su tutte le interfacce di rete. Se la porta 11434 non è filtrata da un firewall, l'API risulta accessibile a tutta la rete locale, o persino all'intera Internet se la macchina ha un IP pubblico o un inoltro di porta sul router. Nessuna password, nessun token: chiunque può inviare richieste, scaricare o eliminare i tuoi modelli e consumare le risorse della tua GPU.

#Ciò che l'API Ollama espone davvero

Prima di proteggere qualsiasi cosa, bisogna capire l'estensione della superficie di attacco. L'API Ollama non è soltanto un endpoint di chat: è un'API di amministrazione completa, senza distinzione di privilegi. Un client anonimo dispone esattamente degli stessi diritti che hai tu.

/api/generate et /api/chat

Generazione di testo. Consuma le risorse della tua GPU a volontà e vede passare tutti i prompt, quindi potenzialmente anche dati sensibili inseriti dalle tue stesse applicazioni.

/api/tags

Elenca tutti i modelli installati. Un attaccante sa immediatamente cosa ospiti, inclusi eventuali modelli sottoposti a fine-tuning interno.

/api/pull

Scarica qualsiasi modello da un registro. Un terzo può saturare il tuo disco o installare un modello malevolo.

/api/delete

Elimina modelli. È possibile distruggere dati senza alcuna autenticazione.

/api/create et /api/push

Creazione di modelli a partire da un Modelfile e invio a un registro. Controllo completo dell'istanza da parte di un soggetto non autorizzato.

/v1/*

Livello compatibile con OpenAI sulla stessa porta. La stessa assenza di controllo degli accessi lo rende utilizzabile da qualsiasi client OpenAI standard.

#Verificare se il tuo Ollama è esposto

Inizia con un'analisi onesta. Obiettivo: capire su quali interfacce il daemon ascolta e se la porta è raggiungibile dall'esterno. Tre verifiche, dalla più locale alla più esterna.

Per prima cosa, controlla su quali indirizzi il processo è in ascolto. L'ascolto su 127.0.0.1 è una configurazione sicura; l'ascolto su 0.0.0.0 o su un indirizzo IP di rete significa che il servizio accetta connessioni remote.

# 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

Poi prova da un'altra macchina della rete. Sostituisci IP_DU_SERVEUR con l'indirizzo locale della macchina Ollama. Se il comando restituisce l'elenco dei modelli, l'istanza è raggiungibile in rete — il che è accettabile su una LAN fidata, ma mai senza filtrare l'accesso da 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

Infine, controlla l'esposizione pubblica. Se la tua macchina ha un indirizzo IP pubblico o un inoltro di porta attivo, cercala su un motore di ricerca come Shodan o Censys. Una semplice ricerca sulla porta 11434 e sul banner di Ollama rivela se la tua istanza è già indicizzata. Puoi anche testare direttamente il tuo indirizzo IP pubblico.

# 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

#Passo 1 — Tornare all'ascolto su localhost

La prima misura, e spesso l'unica necessaria, consiste nel riportare Ollama al suo comportamento predefinito: ascoltare soltanto sull'interfaccia di loopback. Non c'è motivo di esporre direttamente la porta se poi metti un reverse proxy davanti. Il proxy comunicherà con Ollama in locale e il mondo esterno comunicherà soltanto con il proxy.

Su Linux, Ollama viene eseguito come servizio systemd. La variabile OLLAMA_HOST si configura tramite un override del servizio, che rimane valido anche dopo gli aggiornamenti del pacchetto.

1. 01
   Modificare l'override del servizio

   Apri l'editor di override systemd per il servizio ollama. Così viene creato un file drop-in pulito senza toccare il servizio originale.
2. 02
   Forzare l'ascolto locale

   Imposta OLLAMA_HOST su 127.0.0.1:11434. Il daemon rifiuterà quindi ogni connessione proveniente dalla rete.
3. 03
   Ricaricare e riavviare

   Ricarica la configurazione systemd e riavvia il servizio per applicare la variabile.
4. 04
   Confermare

   Controlla ancora con ss -tlnp | grep 11434: l'indirizzo deve essere 127.0.0.1 e non 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

#Passo 2 — Aggiungere un'autenticazione tramite reverse proxy

Poiché Ollama non gestisce l'autenticazione, questa responsabilità viene delegata a un reverse proxy posto davanti a Ollama. Il proxy richiede un identificativo, controlla il traffico e poi lo inoltra a Ollama in locale. Due opzioni collaudate: Caddy (configurazione minima, TLS automatico) e nginx (diffusissimo, ampiamente documentato).

#Opzione A — Caddy (consigliata per la semplicità)

Caddy gestisce automaticamente il TLS tramite Let's Encrypt e offre un'autenticazione di base in poche righe. Genera prima un hash della password, poi inserisci un riferimento a tale hash nel Caddyfile. Non memorizzare mai la password in chiaro.

# 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
}

Con un nome di dominio che punta al tuo indirizzo IP pubblico e le porte 80/443 aperte, Caddy ottiene e rinnova autonomamente il certificato TLS. Il client dovrà fornire l'identificativo a ogni richiesta tramite l'intestazione Authorization.

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

#Opzione B — nginx

nginx richiede un file di password separato, generato con htpasswd, e poi un blocco server che applica l'autenticazione e inoltra le richieste a Ollama. La configurazione è più verbosa, ma molto diffusa, soprattutto quando nginx gestisce già altri servizi.

# 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;
    }
}

#Passo 3 — Crittografare il traffico (TLS)

L'autenticazione di base trasmette l'identificativo codificato in base64: senza TLS, viaggia quasi in chiaro ed è facilissimo intercettarlo. La cifratura del trasporto non è quindi facoltativa non appena si esce da localhost. Due casi possibili, a seconda che tu abbia o meno un nome di dominio pubblico.

Dominio pubblico + porte 80/443

Let's Encrypt tramite Caddy (automatico) o certbot per nginx. Certificato riconosciuto, nessun avviso del browser, rinnovo automatico.

Rete interna senza dominio pubblico

Certificato autofirmato o autorità di certificazione interna (mkcert). I client dovranno considerare attendibile il certificato, ma il traffico rimane cifrato sulla LAN.

Dietro una VPN

Il tunnel VPN crittografa già tutto. TLS resta consigliato come misura di difesa in profondità, ma è meno critico perché nessuno dall'esterno può raggiungere il 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

#Passo 4 — Accesso remoto ben configurato: VPN e Tailscale

La domanda più importante: hai veramente bisogno di esporre Ollama su internet? Nella stragrande maggioranza dei casi, no. Vuoi accedervi dai tuoi dispositivi, non dal web aperto. Una rete privata (VPN) risponde esattamente a questa esigenza senza mai esporre pubblicamente la porta.

Tailscale è l'opzione più semplice: crea una rete mesh crittografata (WireGuard) tra le tue macchine, con indirizzi IP privati stabili. Ollama ascolta quindi soltanto sull'interfaccia Tailscale e solo i tuoi dispositivi autenticati nel tuo tailnet possono raggiungerlo. Nessun inoltro di porte, nessun indirizzo IP pubblico esposto.

1. 01
   Installare Tailscale sul server

   Installa il client e collega la macchina al tuo tailnet. Riceve un indirizzo IP privato in 100.x.y.z accessibile solo dai tuoi altri dispositivi autenticati.
2. 02
   Collegare Ollama all'interfaccia Tailscale

   Imposta OLLAMA_HOST sull'IP Tailscale della macchina (oppure mantieni 127.0.0.1 ed esponi il servizio tramite Tailscale Serve). La porta è raggiungibile solo all'interno del tailnet.
3. 03
   Installare Tailscale sui tuoi dispositivi client

   Le tue altre macchine si collegano allo stesso tailnet e raggiungono Ollama tramite il suo indirizzo IP 100.x.y.z, ovunque tu sia, senza aprire alcuna porta sul router.
4. 04
   Verificare l'isolamento

   Da una rete esterna fuori dal tailnet, la porta deve essere completamente inaccessibile. È il comportamento atteso.

# 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 preferisci una VPN classica, WireGuard auto-ospitato offre lo stesso risultato con maggiore controllo: configuri il tunnel, associ Ollama all'interfaccia wg0 e la porta rimane invisibile da internet. La scelta tra Tailscale e WireGuard senza componenti aggiuntivi dipende soprattutto dal compromesso tra semplicità e piena sovranità sull'infrastruttura.

#Misure aggiuntive per rafforzare la sicurezza della rete

Al di là del proxy e della VPN, alcune misure di difesa in profondità limitano i danni in caso di configurazione errata. Il principio guida: non affidarsi mai a un solo livello.

Firewall con regole restrittive

Blocca la porta 11434 in ingresso su tutte le interfacce tranne loopback e VPN. Con ufw: negare l'accesso alla porta 11434 per impostazione predefinita, consentirlo solo dalla sottorete Tailscale/WireGuard.

Nessun inoltro di porte

Non creare mai un port forwarding 11434 sulla box/routeur. Se ne hai uno «per testare», rimuovilo: è la causa n°1 delle istanze esposte.

Limitazione della frequenza delle richieste

Sul reverse proxy, applica una limitazione della frequenza delle richieste per mitigare un eventuale abuso anche dopo l'autenticazione (nginx limit_req, Caddy rate_limit).

Password forti e rotazione

La sicurezza dell'autenticazione di base dipende esclusivamente dalla robustezza del segreto. Usa password lunghe e cambiale se una postazione client viene compromessa.

Registrazione

Attiva i log di accesso del proxy per individuare tentativi anomali. Un'istanza sana riceve solo le tue richieste.

# 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

#Risoluzione dei problemi

403 Forbidden dietro il proxy

Ollama rifiuta l'intestazione Host. Imposta Host a localhost:11434 dal lato proxy, o definisci OLLAMA_ORIGINS per autorizzare il tuo dominio.

Lo streaming si blocca o arriva tutto in una volta

Il proxy accumula la risposta in un buffer. Disattiva il buffering (proxy_buffering off su nginx) e aumenta il timeout di lettura per le generazioni lunghe.

curl funziona, ma non da un'altra macchina

Ollama ascolta ancora su 127.0.0.1 mentre il proxy è altrove, oppure il firewall blocca la porta 443 del proxy. Controlla ss -tlnp e le regole ufw.

Il rilascio del certificato Let's Encrypt non riesce

La porta 80 deve essere raggiungibile da internet per la validazione HTTP-01, e il dominio deve puntare all'indirizzo IP corretto. Verifica il DNS e l'apertura della porta 80.

Tailscale: Ollama inaccessibile nel tailnet

Ollama è in ascolto su 127.0.0.1 senza tailscale serve. Associa OLLAMA_HOST all'IP 100.x oppure esponi il servizio tramite tailscale serve 11434.

Ancora visibile su Shodan dopo la correzione

L'indice impiega del tempo ad aggiornarsi. Verifica prima tu stesso, da una rete esterna, che la porta sia chiusa; l'indicizzazione si aggiornerà in seguito.

#Per approfondire

Mettere in sicurezza l'accesso è solo una parte del quadro. Queste guide approfondiscono i temi del deployment e della conformità trattati in questa guida:

Distribuire un chatbot IA per il proprio team sull'intranet

Il caso d'uso tipico a cui si applicano queste misure di rafforzamento della sicurezza: Ollama + Open WebUI multiutente dietro un reverse proxy autenticato.

Mettere un LLM in produzione con Docker Compose

Stack completa Ollama + Traefik dove il reverse proxy e l'isolamento di rete sono gestiti fin dalla progettazione.

LLM locale e GDPR: conformità in materia di dati privati in azienda

Il risvolto normativo: un’esposizione non controllata comporta anche un rischio di divulgazione di dati personali da documentare.