5 maggio 2026 · 10 min lettura
Intelligenza ArtificialeAgente AI di Nous Research in LXC con GPU passthrough e Ollama locale: i gotcha CUDA su Turing e perché qwen3:4b batte l'8b come cervello agentico.
Intelligenza ArtificialeMiroFish in locale sulla mia RTX 5080 via Ollama: simulazione multi-agente gratis. Il muro vero non era la GPU, ma il function-calling del modello.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
MoneyPrinterTurbo con Ollama self-hosting: cos'è, feature e setup Docker per generare video AI in locale gratis. Parte 1, con un asterisco su Pexels.
1.100. Tanti sono i server Ollama che Cisco ha trovato esposti pubblicamente su internet nel settembre 2025. Senza autenticazione. Senza firewall. Accessibili da chiunque.
Il punto non è che Ollama sia insicuro. Il punto è che "locale" e "privato" non sono sinonimi — e la distanza tra i due si misura in tre righe di configurazione che nessuno imposta.
Questo post non è un tutorial su come installare Ollama — se parti da zero, quella guida esiste già. Qui si parla di quello che sbaglia quasi tutti dopo l'installazione: le configurazioni di default che trasformano un setup pensato per la privacy in un colabrodo.
Partiamo da una premessa onesta. Ollama, nella sua forma base correttamente configurata, mantiene quello che promette: prompt e risposte non lasciano mai il dispositivo durante l'inferenza locale. La privacy policy lo dice esplicitamente — "We do not collect, store, transmit, or have access to your prompts, responses, model interactions, or other content you process locally" — e dal punto di vista dell'inferenza in sé, questa affermazione regge.
Ma la privacy non si difende solo durante l'inferenza. Si difende in ogni strato del sistema: come il server è esposto sulla rete, quali variabili d'ambiente sono attive, quale client si usa per accedere, cosa fa la GUI quando è aperta in background. Ognuno di questi strati ha le sue insidie — e le impostazioni di default di Ollama e Open WebUI ne lasciano aperti almeno quattro.
Conviene separare subito due livelli di rischio: quello della configurazione di rete (server Ollama esposto su WAN) e quello della configurazione applicativa (variabili d'ambiente che abilitano connessioni cloud). Il primo è più grave — espone direttamente i modelli. Il secondo è più sottile e più comune, perché si nasconde in default che sembrano innocui.
Il setup che vedi in quasi tutti i tutorial — quello che fa girare tutto in cinque minuti — lascia aperte quattro superfici di rischio che nessuno nomina. Non perché siano segrete: sono le impostazioni di default, e quasi nessuna guida le tocca perché l'obiettivo è far girare qualcosa, non farlo girare in modo sicuro. Ecco ognuna, con la causa e la correzione.
Ollama di default gira su 127.0.0.1:11434 — localhost only. Il problema comincia quando si vuole accedere da Open WebUI o da un altro container: molte guide indicano di impostare OLLAMA_HOST=0.0.0.0, che espone la porta su tutte le interfacce di rete. Se il firewall non è configurato correttamente, il server diventa raggiungibile dall'esterno.
Cisco ha trovato oltre 1.100 server in questa situazione. Circa il 19% ospitava modelli attivi. L'81% rimanente era dormiente ma comunque vulnerabile: chiunque poteva caricare modelli non autorizzati, leggere quelli esistenti, o manipolare la configurazione. La definizione di Cisco è diretta: "diffusa negligenza verso pratiche di sicurezza fondamentali come controllo degli accessi, autenticazione e isolamento della rete".
La soluzione corretta per un homelab su Proxmox LXC — come nel post su Ollama in LXC senza GPU — è assegnare un indirizzo IP fisso al container Ollama e impostare OLLAMA_HOST=<IP_INTERNO>, poi bloccare la porta 11434 sul firewall Proxmox verso la WAN. Open WebUI raggiunge Ollama sull'IP interno; nessun'altra macchina può farlo dall'esterno.
# /etc/systemd/system/ollama.service — configurazione sicura
[Service]
Environment="OLLAMA_HOST=192.168.1.50:11434" # IP fisso del container, MAI 0.0.0.0
# Firewall Proxmox: bloccare porta 11434 verso WAN
# Permettere solo tra container LXC sulla stessa subnetOllama Desktop v0.10.0 su Mac e Windows conteneva una vulnerabilità che permetteva a un sito web malevolo di scansionare le porte da 40.000 a 65.535, individuare la GUI aperta in background, e reindirizzare tutte le chat verso un server dell'attaccante — intercettando ogni messaggio in real-time. Un drive-by attack nel senso letterale: bastava aprire una pagina web con il codice malevolo mentre Ollama Desktop era in esecuzione.
Il fix è arrivato in v0.10.1 entro poche ore dalla disclosure del 31 luglio 2025. Buona gestione della risposta, ma il problema strutturale rimane: Ollama Desktop espone una superficie d'attacco che Ollama CLI server non ha. Se usi Ollama su un server headless — LXC, VM, macchina dedicata — questa classe di vulnerabilità non esiste.
Open WebUI ha una reputazione privacy-first abbastanza meritata: ANONYMIZED_TELEMETRY=false, DO_NOT_TRACK=true e SCARF_NO_ANALYTICS=true sono già i default nel Dockerfile. Il problema è che già disabilitato non significa tutto disabilitato. Ci sono almeno tre impostazioni critiche che rimangono attive e che nessuno tocca perché non sembrano problematiche a prima vista.
Il più insidioso è ENABLE_COMMUNITY_SHARING=true. Non è telemetria tecnica: è un meccanismo che permette di condividere contenuti — chat, configurazioni, preset — con la community Open WebUI. In un contesto dove stai usando l'LLM per elaborare dati aziendali o personali sensibili, questo default è un problema reale. Non è attivato di nascosto: c'è nella documentazione ufficiale. Va impostato esplicitamente a false.
Separato da questo, c'era un problema con Chromadb — il database vettoriale usato per il RAG in Open WebUI — che in alcune versioni tentava di inviare telemetria a PostHog (eventi ClientCreateCollectionEvent). La issue #15613 è stata aperta e il progetto afferma di aver disabilitato il comportamento nel codice. Se usi il RAG con Open WebUI, controlla la versione di Chromadb inclusa — è parte del controllo di sicurezza.
Prompt e risposte restano locali — questo è confermato. Ma Ollama client raccoglie comunque: versione app, conteggio richieste, indirizzo IP, informazioni su dispositivo e OS. Non è nulla di drammatico per uso personale, ma è un punto che la comunità ha sollevato esplicitamente nella issue #2567 (febbraio 2024): "Molti assumono Ollama sia un'alternativa privata ai servizi cloud LLM, quindi una telemetria non trasparente potrebbe essere fuorviante."
La issue è stata chiusa senza documentazione esaustiva su cosa viene inviato esattamente e quando. Nel luglio 2025 un altro sviluppatore enterprise ha aperto la issue #11442 perché non riusciva a trovare la privacy policy di Ollama. In contesto GDPR, dove molte PMI italiane citano la privacy come seconda barriera all'adozione AI, questo tipo di opacità ha un peso concreto.
La risposta pragmatica: usa Ollama come CLI server in un container isolato, senza accesso internet diretto se non per il pull iniziale dei modelli. Una volta che i modelli sono locali, il container Ollama non ha bisogno di connettersi a nulla.
La configurazione che segue consolida tutti i punti precedenti in un docker-compose.yml funzionante per Open WebUI su homelab. Non è una configurazione massimalmente restrittiva — è quella che bilancia usabilità e privacy in modo che un tecnico possa adottarla senza rinunciare a funzionalità essenziali. Ogni variabile ha un commento che spiega perché è impostata così.
# docker-compose.yml — Open WebUI privacy-first
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
ports:
- "127.0.0.1:3000:8080" # Solo localhost — accesso via VPN (Tailscale/NetBird)
volumes:
- open-webui:/app/backend/data
environment:
# Ollama: IP fisso del container, MAI 0.0.0.0
OLLAMA_BASE_URL: "http://192.168.1.50:11434"
# Telemetria — già default, ma esplicitare non fa male
ANONYMIZED_TELEMETRY: "false"
DO_NOT_TRACK: "true"
SCARF_NO_ANALYTICS: "true"
# Community sharing — NON è default sicuro, va impostato
ENABLE_COMMUNITY_SHARING: "false"
# Connessioni esterne — disabilitare tutto
OFFLINE_MODE: "true"
HF_HUB_OFFLINE: "1"
ENABLE_VERSION_UPDATE_CHECK: "false"
# CORS — restringere da wildcard *
CORS_ALLOW_ORIGIN: "http://localhost"
restart: unless-stopped
volumes:
open-webui:Due note su questa configurazione. Prima: ports: "127.0.0.1:3000:8080" — il bind su localhost anziché 0.0.0.0:3000 significa che Open WebUI non è raggiungibile direttamente dalla rete. L'accesso avviene tramite tunnel VPN (Tailscale o NetBird — zero porte aperte su internet, accesso remoto comunque disponibile). Seconda: OFFLINE_MODE=true disabilita anche il download automatico di modelli dall'interno dell'interfaccia. I modelli si caricano via CLI su Ollama — che è il comportamento corretto per un setup controllato.
Un setup privacy-first su CPU-only non è un ripiego. Per la maggior parte dei casi d'uso — chat, riassunti, classificazione testo, assistenza alla scrittura — i modelli piccoli sono più che sufficienti. Nel mio LXC su Ryzen 7 1800X (4 core): qwen2:0.5b a 15,5 token/s con 378MB RAM, llama3.2:1b a 13,6 token/s con 1.380MB RAM. Non è inferenza da data center, ma è un flusso di testo leggibile in tempo reale.
L'alternativa cloud ha un costo: tra $0,25 e $15 per milione di token in input, a seconda del modello. Per un'azienda che elabora documentazione interna, contratti, note, dati HR — il calcolo tra privacy e costo operativo si chiude rapidamente a favore del locale. L'AI locale per PMI con modelli piccoli è già una realtà funzionante, non una prospettiva futura.
C'è un aspetto compliance che quasi nessuno considera: l'AI Act europeo (rollout 2024-2026) categorizza i sistemi LLM in base all'uso. Chi usa un LLM locale per scopi personali o interni all'azienda non rientra nella definizione di "general purpose AI system provider" soggetto agli obblighi più stringenti. Il setup locale non è solo privacy — è compliance by design.
Un setup Ollama + Open WebUI configurato correttamente non richiede paranoia — richiede una checklist da eseguire una volta sola. I punti che seguono coprono le superfici di rischio emerse dalla ricerca: rete, configurazione applicativa, scelta del client. Nessuno richiede competenze avanzate. Richiedono solo di non fermarsi al "funziona".
Un test utile dopo la configurazione: avvia tcpdump sul container Open WebUI mentre invii un prompt. Se non compare traffico verso IP esterni, il setup funziona. Se compare qualcosa, hai una direzione precisa su cosa indagare.
Il concetto di locale non è binario. Non è locale o cloud. È locale con quale configurazione. Quei 1.100 server trovati da Cisco erano tutti installazioni locali. Nessuno di loro era cloud. Erano semplicemente configurati come se la rete non esistesse.
Fonti: Ollama Privacy Policy · Open WebUI Env Configuration · The Register: drive-by Ollama attack · The Register: 1.100+ server Ollama esposti (Cisco) · GitHub Issue #2567 — Ollama telemetry · GitHub Issue #15613 — Chromadb PostHog · Agenda Digitale — LLM open-weights e GDPR
| Variabile | Default | Cosa fa | Per privacy-first |
|---|---|---|---|
| ENABLE_COMMUNITY_SHARING | true | Permette condivisione contenuti con la community Open WebUI | false |
| ENABLE_VERSION_UPDATE_CHECK | true | Chiamate di rete per controllo aggiornamenti | false |
| OFFLINE_MODE | false | Permette connessioni esterne (download modelli, API) | true |
| HF_HUB_OFFLINE | 0 | Connessione attiva a HuggingFace Hub | 1 |
| CORS_ALLOW_ORIGIN | * | Wildcard: qualsiasi origin può chiamare l'API | http://localhost o IP specifico |