Bloccare un’app dall’accesso a Internet su Windows Server

Se l’obiettivo è impedire a un’applicazione su Windows Server di parlare con Internet, il punto chiave è questo: non basta “spegnere il browser” o togliere la rete alla macchina. Bisogna decidere quale livello vuoi controllare, perché ogni app può uscire in modi diversi: binario diretto, servizio Windows, task schedulato, libreria che usa un altro processo, traffico su 80/443, DNS, aggiornamenti automatici, telemetria, API cloud.

In pratica hai quattro strade, da usare in combinazione quando serve: firewall in uscita, AppLocker o SRP per bloccare l’esecuzione, proxy o URL filtering per controllare domini e destinazioni, e isolamento di rete per contenere il blast radius. Se vuoi una soluzione pulita, parti dal firewall in uscita e verifica con log e connessioni reali. Se vuoi una soluzione robusta contro il riavvio del processo o l’uso di un servizio secondario, aggiungi regole più specifiche e auditing.

Decidere il livello giusto: processo, servizio o rete

La domanda corretta non è “come blocco Internet”, ma cosa vuoi impedire esattamente. Se vuoi fermare solo un’app specifica, il firewall in uscita è il primo strumento sensato. Se vuoi evitare che l’app parta proprio, AppLocker o Software Restriction Policies sono più netti. Se l’app è legittima ma non deve raggiungere certi domini, serve un proxy o un controllo DNS/URL. Se l’host è troppo esposto, la scelta più sicura è metterlo in una VLAN o subnet senza route verso Internet e aprire solo quello che serve verso servizi interni.

Su Windows Server, il problema più frequente è il falso senso di sicurezza: si blocca un eseguibile, ma l’app continua a uscire tramite un servizio helper, un aggiornatore, un runtime condiviso o un componente firmato da terze parti. Per questo conviene sempre osservare prima di cambiare: quali processi aprono socket, su quali porte, verso quali IP, con quale utente.

Verifica iniziale: quali processi stanno andando fuori

Prima di toccare policy o firewall, identifica il traffico reale. Su un server recente puoi partire da PowerShell e dai log del firewall. Se la macchina è già in produzione, evita di fare prove invasive: raccogli evidenza, poi applichi il blocco minimo reversibile.

Comandi utili per la fotografia iniziale:

Get-NetTCPConnection | Sort-Object -Property State,OwningProcess | Select-Object -First 50
Get-Process -Id <PID> | Select-Object Id,ProcessName,Path
Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object Name,DisplayName,Status

Se vuoi correlare processo e destinazione, il modo più veloce è osservare una connessione attiva e risalire al PID. In molti casi basta già questo per scoprire che l’app non parla direttamente con Internet, ma con un updater o con un componente di telemetria separato.

Per il firewall, verifica che il logging sia attivo. Il file tipico è %systemroot%\system32\LogFiles\Firewall\pfirewall.log. Se non contiene righe, abilita il logging prima di fare test:

Set-NetFirewallProfile -Profile Domain,Private,Public `
  -LogAllowed True -LogBlocked True -LogFileName '%systemroot%\system32\LogFiles\Firewall\pfirewall.log'

Questo non blocca nulla da solo, ma ti dà il minimo indispensabile per capire se il traffico è davvero quello che pensi. Senza log, rischi di costruire regole cieche.

Bloccare l’uscita con Windows Defender Firewall

La soluzione più pratica, quando vuoi impedire a una singola app di uscire, è una regola in uscita sul binario o sul servizio. È reversibile, auditabile e si presta bene a un test controllato. Il punto critico è scegliere il target corretto: percorso completo dell’eseguibile, servizio specifico o gruppo di porte/IP se l’app cambia binario spesso.

Esempio: blocco del binario C:\Program Files\Vendor\App\app.exe verso qualsiasi destinazione. Prima crea una regola di test con nome chiaro:

New-NetFirewallRule -DisplayName 'BLOCK App outbound' `
  -Direction Outbound -Action Block `
  -Program 'C:\Program Files\Vendor\App\app.exe' `
  -Profile Any -Enabled True

Se l’app gira come servizio, spesso è meglio legarla al servizio invece che al path, soprattutto quando il binario viene aggiornato o l’eseguibile cambia nome. In quel caso puoi usare il servizio come riferimento se la versione di Windows e il tipo di servizio lo permettono; altrimenti resta più affidabile il path del binario con hashing o controllo software più sopra nella catena.

Per verificare l’effetto, lancia una connessione che l’app tenta normalmente e controlla il log del firewall. Se la regola funziona, dovresti vedere il blocco in pfirewall.log e un errore di rete lato applicazione. Se invece il traffico continua, il binario che hai bloccato non è quello giusto: spesso c’è un helper, un servizio secondario o un runtime che apre la connessione al posto dell’app principale.

Un dettaglio operativo: le regole in uscita possono essere troppo larghe se lasci -Profile Any su server con più profili di rete. Va bene per il test iniziale, ma in produzione conviene restringere a Domain/Private/Public in base al contesto. Il blast radius è basso, ma comunque reale: una regola errata può tagliare aggiornamenti, licensing, telemetria o integrazioni necessarie.

Bloccare per servizio quando il processo cambia nome

Se l’app è eseguita da un servizio Windows e il vendor aggiorna spesso il binario, la regola per servizio è più stabile. Prima identifica il nome tecnico del servizio, non il display name. Il comando utile è:

Get-Service | Where-Object {$_.DisplayName -like '*Vendor*' -or $_.Name -like '*vendor*'} | Format-Table Name,DisplayName,Status

Se la tua versione di Windows e la modalità del servizio supportano il binding diretto, puoi creare una regola associata al servizio. Quando non è praticabile, la combinazione più solida resta: regola sul binario + auditing + controllo del percorso di installazione. In ambienti gestiti, è utile anche bloccare la modifica della cartella del programma tramite ACL, così il binario non viene sostituito senza autorizzazione.

Attenzione a un punto spesso ignorato: alcuni servizi usano account di sistema o account di dominio con privilegi elevati. Se blocchi l’uscita solo a livello di processo, ma il servizio può lanciare un child process o usare un componente firmato differente, il traffico può passare altrove. Per questo, quando il rischio è alto, affianca al firewall una policy di esecuzione: AppLocker o, in ambienti meno recenti, SRP.

AppLocker: impedire che parta il binario sbagliato

AppLocker non sostituisce il firewall: serve a impedire l’esecuzione di software non autorizzato. È utile se il problema è che l’app installa updater, plugin o tool di supporto che poi parlano con Internet. In quel caso puoi limitare l’esecuzione a una directory o a file firmati da un publisher specifico.

La logica corretta è: prima metti in modalità audit, poi osservi i blocchi che avverrebbero, poi converti in enforcement. Se vai subito in blocco, rischi di fermare componenti legittimi e perdere l’accesso remoto al server.

Le tracce da controllare sono nel Visualizzatore eventi, sotto Applications and Services Logs e i log di AppLocker. Lì vedi quale file sarebbe stato eseguito e con quale regola. Questo è molto più affidabile del “mi sembra che non navighi più”, perché ti dà l’oggetto preciso da correggere.

Controllare solo certi domini: proxy, DNS e URL filtering

Se l’app deve restare online ma non deve raggiungere Internet in modo libero, il firewall da solo non basta: blocca o consenti per IP e porta, ma non per dominio in modo nativo e pulito. Qui entrano proxy esplicito, secure web gateway o filtri DNS. È la strada giusta quando vuoi consentire solo endpoint specifici, ad esempio licenze, repository o API del vendor.

Con un proxy, l’app viene forzata a uscire solo attraverso un punto di controllo. Il vantaggio è l’ispezione e il logging centralizzato; lo svantaggio è che molte app server-side non supportano bene proxy autenticati o cambiano comportamento dietro proxy. Prima di imporlo, verifica la compatibilità dell’applicazione e del runtime.

Con il DNS filtering puoi bloccare domini noti senza toccare il binario. Però non è una misura completa: se l’app usa IP hardcoded o DNS-over-HTTPS, il filtro perde efficacia. Il DNS va visto come livello aggiuntivo, non come unica barriera.

Isolare il server: la soluzione più pulita quando il rischio è alto

Se il server ospita un’app che non deve avere alcun accesso diretto a Internet, la strategia più robusta è di rete: niente route verso l’esterno, solo accesso ai servizi interni necessari. In pratica metti il server in una subnet senza default gateway verso Internet o in una VLAN con egress controllato dal firewall perimetrale.

Questo approccio riduce gli errori applicativi, ma cambia il blast radius: se sbagli una route o una ACL, non rompi solo l’app, rompi anche aggiornamenti, NTP, CRL/OCSP, repository e qualunque dipendenza esterna. Per questo è la scelta giusta quando hai già chiarito le dipendenze e puoi documentarle. Se non le conosci, partire da qui è troppo aggressivo.

Per verificare l’assenza di egress, puoi controllare la tabella di routing e provare una destinazione esterna nota. La verifica minima è semplice: l’host non deve avere una route valida verso Internet, oppure il firewall perimetrale deve rifiutare il traffico in uscita e loggarlo.

Sequenza pratica consigliata

Se vuoi una procedura che minimizzi i rischi, usa questa sequenza:

1. Raccogli evidenza: PID, nome processo, servizio, destinazioni, log firewall.
2. Applica una regola in uscita sul binario o sul servizio, non sull’intera macchina.
3. Testa l’app e controlla pfirewall.log o Event Viewer per confermare il blocco.
4. Se il traffico passa da un componente diverso, aggiungi una regola mirata anche per quello.
5. Solo se l’app deve restare parzialmente online, affianca proxy o filtri DNS.
6. Se il requisito è “zero Internet”, passa all’isolamento di rete e documenta le eccezioni.

Questa sequenza funziona perché parte dal dato osservabile e non da una teoria sul comportamento dell’app. È il modo più rapido per evitare regole troppo permissive o troppo strette.

Rollback e manutenzione delle eccezioni

Ogni blocco va trattato come change controllato. Prima di applicare regole nuove, esporta la configurazione del firewall o annota esattamente il nome della regola. Il rollback minimo è la rimozione della regola o la disabilitazione temporanea. Esempio:

Get-NetFirewallRule -DisplayName 'BLOCK App outbound' | Remove-NetFirewallRule

Se stai operando in produzione, conserva anche il motivo dell’eccezione: dominio, IP, servizio o finestra temporale. Le eccezioni senza scadenza tendono a restare per anni e diventano debito tecnico e rischio di sicurezza. Conviene rivederle quando cambia la versione dell’app o quando il vendor introduce nuove dipendenze cloud.

Un buon criterio operativo è questo: se una regola di blocco ha più di un’eccezione non documentata, la policy è troppo fragile. A quel punto conviene rifare la mappa delle uscite e consolidare su pochi punti di controllo: firewall, proxy, DNS, segmentazione.

Errori tipici che fanno fallire il blocco

I casi più comuni sono ripetitivi. Primo: si blocca il processo sbagliato, perché l’app avvia un helper con nome diverso. Secondo: si consente il traffico verso un IP, ma il servizio cambia endpoint tramite CDN o bilanciamento. Terzo: si ignora il traffico DNS, e l’app continua a risolvere nomi anche se le connessioni TCP vengono bloccate. Quarto: si applica il blocco solo a un profilo di rete, mentre il server è su un altro profilo.

Il modo più veloce per falsificare queste ipotesi è guardare il log del firewall e il processo che genera la connessione. Se il traffico cambia processo, il problema è il target. Se cambia destinazione, il problema è la regola troppo specifica. Se la connessione fallisce ma l’app continua a fare retry, il blocco funziona e devi solo decidere se è il comportamento desiderato o un effetto collaterale da mitigare.

Scelta finale: cosa fare in pratica

Per un server Windows con una singola app da contenere, la scelta più equilibrata è quasi sempre questa: firewall in uscita sul binario o servizio, logging attivo, verifica dei processi reali, e solo dopo eventuale proxy o isolamento di rete. AppLocker entra in gioco se devi anche impedire l’esecuzione di componenti non autorizzati. Se invece il requisito è “nessuna uscita verso Internet”, la soluzione corretta è di rete, non solo host-based.

In sintesi: bloccare un’app dall’accesso a Internet su Windows Server non è un comando unico, ma una catena di controllo. Più conosci il traffico reale, meno eccezioni ti servono. Più è chiaro il requisito, più scegli il livello giusto senza trasformare il server in un puzzle difficile da mantenere.