Dal modello alla rete: come esporre un server di inferenza locale senza aprire porte al caso

Il problema dell'esposizione di rete nell'inferenza locale

L'inferenza locale di IA implica l'esecuzione di un modello addestrato su infrastruttura propria, sia su un server dedicato che su un desktop. Lo scenario principale dell'inferenza distribuita prevede che un server modello compatibile con OpenAI funzioni su un host centralizzato e i client remoti inviino richieste al suo endpoint attraverso la rete. Questa topologia conferisce al server un ruolo centrale nella gestione della capacità di calcolo, dello storage dei modelli e dell'accesso alla rete per più client.

Il rischio principale sorge quando è necessario che il server sia accessibile da altri dispositivi della rete locale o da una rete privata virtuale (VPN) senza esporlo a internet. A differenza delle configurazioni di isolamento totale, dove il servizio ascolta solo su localhost, o delle audit di privacy che verificano l'integrità del file, questa guida si concentra sullo scenario intermedio: l'esposizione controllata. L'obiettivo è colmare il divario tra 'il server funziona su localhost' e 'posso usarlo dal mio portatile nella stessa rete in modo sicuro', fornendo una configurazione difensiva predefinita.

La distinzione tra isolamento totale ed esposizione controllata richiede una valutazione continua dei confini operativi. Mentre l'ascolto su localhost limita l'accesso ai processi locali, l'esposizione su una rete privata introduce variabili di rete che devono essere gestite attivamente. Il rischio non risiede solo nella raggiungibilità del servizio, ma nella potenziale dispersione di dati sensibili, come prompt, output o metadati del modello, attraverso canali non cifrati o non autorizzati. Pertanto, la configurazione difensiva deve considerare non solo la protezione del traffico in transito, ma anche la segregazione logica dei dati all'interno dell'infrastruttura, assicurando che ogni componente, dai log alle uscite, rimanga entro i limiti definiti dalla policy di sicurezza.

Configurazione dell'interfaccia di ascolto: bind address

L'indirizzo di binding (bind address) determina su quali interfacce di rete ascolta il server. Di default, strumenti come Ollama si legano a 127.0.0.1:11434, il che significa che solo i processi dello stesso host possono accedervi. Questo valore predefinito è corretto per la maggior parte dei casi e deve essere mantenuto se non è richiesto l'accesso remoto.

Per consentire l'accesso da altri dispositivi, è necessario modificare questo indirizzo. Impostare OLLAMA_HOST=0.0.0.0 o usare -p 11434:11434 in Docker pubblica il servizio su tutte le interfacce, inclusa quella pubblica se il firewall non lo blocca. Questo è estremamente pericoloso perché l'API di Ollama non include autenticazione integrata. Chiunque possa accedere alla porta può eseguire modelli, scaricarne altri o saturare la CPU/GPU. L'opzione consigliata per le reti private è impostare l'indirizzo dell'interfaccia specifica (ad esempio, l'IP della rete locale o l'indirizzo del tunnel VPN) anziché 0.0.0.0.

La scelta dell'indirizzo di binding influenza direttamente la superficie di attacco del server. L'uso di 0.0.0.0 espone il servizio a tutte le interfacce disponibili, aumentando significativamente il rischio in assenza di controlli perimetrali robusti. Al contrario, il binding su un indirizzo IP specifico riduce l'ambito di esposizione, limitando l'accesso a una singola interfaccia di rete. Questa restrizione è particolarmente rilevante in ambienti dove il server potrebbe essere collegato a più segmenti di rete, come in configurazioni con interfacce multiple o tunnel VPN. La selezione dell'indirizzo appropriato deve essere accompagnata da una verifica costante delle interfacce attive, per evitare che modifiche accidentali alla configurazione di rete possano esporre il servizio a segmenti non autorizzati.

Controlli di accesso: autenticazione e CORS

Un aspetto critico della sicurezza nei server di inferenza locale è la mancanza di autenticazione nativa in molti strumenti. Ollama, ad esempio, non include chiave API, login o limitazione di velocità. L'unica whitelist che ha, OLLAMA_ORIGINS, controlla solo quali origini del browser possono chiamarla (CORS); non impedisce a curl o a uno script da un'altra macchina di utilizzarla. Questo significa che l'autenticazione deve essere implementata a livello di rete o tramite un proxy inverso.

Per strumenti come LM Studio, la configurazione in modalità headless consente di abilitare il servizio in rete. Tuttavia, la verifica dell'ascolto sulla porta (predefinita 1234) deve essere eseguita con cura. Se è richiesta l'autenticazione, la migliore pratica è posizionare un proxy inverso (nginx, Traefik o Caddy) davanti al servizio. Il proxy termina TLS, richiede una password o un token, e poi invia le richieste al servizio locale su 127.0.0.1. In questo modo, il servizio di inferenza mantiene il binding su localhost e il proxy è l'unico processo che ascolta sulla porta pubblica o di rete locale.

L'implementazione di un proxy inverso introduce un livello di astrazione che separa la gestione dell'autenticazione dal servizio di inferenza. Questo approccio consente di mantenere il servizio di inferenza in uno stato di isolamento relativo, ascoltando solo su localhost, mentre il proxy gestisce la terminazione TLS e la verifica delle credenziali. La configurazione del proxy deve essere attentamente monitorata per garantire che le intestazioni HTTP vengano gestite correttamente, evitando potenziali vulnerabilità legate alla manipolazione delle richieste. Inoltre, la scelta del proxy e delle sue impostazioni di sicurezza deve essere allineata con le esigenze specifiche dell'ambiente, considerando fattori come la latenza aggiuntiva e la complessità della configurazione.

Protezione perimetrale: firewall e filtraggio delle porte

La configurazione del firewall dell'host è l'ultima linea di difesa per limitare l'accesso a porte specifiche e indirizzi IP autorizzati. Nei sistemi Linux, si possono usare ufw o iptables per restringere l'accesso alla porta 11434 (Ollama) o 1234 (LM Studio) solo agli indirizzi IP della rete locale o della VPN. In Windows, il Firewall di Windows con regole avanzate consente di definire regole di ingresso che consentano il traffico solo da intervalli di IP specifici.

È cruciale chiudere la porta nel firewall se non si sta utilizzando l'esposizione di rete. Se si configura OLLAMA_HOST=0.0.0.0 e si apre la porta nel firewall, si pubblica un server di inferenza senza autenticazione su tutto Internet. Gli scanner come Shodan indicizzano migliaia di istanze di Ollama aperte, e un'istanza esposta viene trovata e utilizzata impropriamente in poche ore. Pertanto, la regola d'oro è: non esporre direttamente la porta di inferenza senza un livello di autenticazione e cifratura.

La configurazione del firewall deve essere vista come un componente dinamico della strategia di sicurezza, soggetto a revisione periodica in base alle modifiche dell'infrastruttura. L'uso di strumenti come ufw o iptables consente di definire regole granulari, ma la loro efficacia dipende dalla correttezza e dall'aggiornamento costante delle regole. In ambienti con più interfacce di rete, è fondamentale assicurarsi che le regole di firewall siano applicate coerentemente a tutte le interfacce rilevanti, evitando configurazioni parziali che potrebbero lasciare aperture non intenzionali. La documentazione delle regole attive e la loro verifica regolare sono pratiche essenziali per mantenere l'integrità della protezione perimetrale.

Verifica empirica e scenari avanzati

La verifica empirica è essenziale per confermare che solo i client autorizzati possano connettersi e che il servizio non sia accessibile da internet. Da un dispositivo nella rete locale, si può usare curl per testare la connessione: curl http://IP_SERVITORE:11434/api/tags. Se la connessione viene rifiutata, il firewall o la configurazione del bind address sta funzionando correttamente. Da un dispositivo fuori dalla rete locale (ad esempio, usando una connessione mobile), la connessione deve fallire. Strumenti come netstat o ss sull'host consentono di verificare su quali interfacce il servizio sta ascoltando.

Per l'accesso remoto sicuro, l'uso di una VPN WireGuard self-hosted è l'opzione consigliata. Si imposta OLLAMA_HOST come l'indirizzo del tunnel (ad esempio, 10.8.0.1), e solo i peer della VPN potranno connettersi. Internet continua a non vedere nulla sulla porta di inferenza. In ambienti aziendali con più utenti, l'autenticazione deve essere gestita tramite un proxy inverso con integrazione con Active Directory o un sistema di identità centralizzato, assicurando che ogni utente abbia permessi specifici e che le credenziali siano memorizzate in un vault segreto approvato.

La verifica empirica non è un evento una tantum, ma un processo continuo che deve essere integrato nella routine di manutenzione dell'infrastruttura. I test di connessione da dispositivi autorizzati e non autorizzati devono essere ripetuti regolarmente per confermare che le configurazioni di sicurezza rimangano efficaci nel tempo. L'uso di strumenti di scansione esterna, come Shodan, fornisce una prospettiva indipendente sulla visibilità del servizio, aiutando a identificare eventuali esposizioni non intenzionali. In ambienti aziendali, la verifica deve essere estesa alla gestione delle credenziali e dei permessi, assicurando che l'accesso sia limitato a soli utenti autorizzati e che le credenziali siano gestite in modo sicuro, riducendo il rischio di compromissione.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.