Da anni Microsoft Defender for Endpoint protegge i server Linux in produzione, ma fino a poco tempo fa le workstation Linux restavano un punto cieco per molti team di sicurezza. È una lacuna che pesa soprattutto nelle aziende dove sviluppatori, SRE e data engineer lavorano ogni giorno su Ubuntu o Fedora, spesso con privilegi elevati e accesso diretto a repository, pipeline CI/CD e credenziali cloud. Con l’estensione in Public Preview del supporto ai desktop Linux, Microsoft chiude questo gap portando sulle workstation lo stesso stack EDR già maturo lato server.

Vediamo cosa cambia davvero, quali sono i requisiti aggiornati a ottobre 2026 e come impostare l’onboarding in pratica.

Cosa cambia con la Public Preview

La novità principale non è tecnica ma di perimetro: tutte le distribuzioni già supportate sui server Linux lo sono ora anche sui desktop, con gli stessi pacchetti, gli stessi metodi di deployment e le stesse funzionalità di sicurezza. Non esiste quindi un “Defender per desktop” diverso da quello server: cambia solo la classificazione del dispositivo.

Defender for Endpoint assegna automaticamente a ogni macchina Linux il ruolo di Server o Workstation in base a diversi segnali di sistema (presenza di un ambiente desktop, pattern di utilizzo, ecc.). Se i segnali non sono conclusivi, il dispositivo viene classificato come Server per impostazione predefinita — un dettaglio da verificare subito dopo l’onboarding, perché incide direttamente sulla licenza richiesta:

• Workstation: richiede una licenza Defender for Endpoint Plan 2, inclusa anche in Microsoft 365 E5 ed E7.
• Server: richiede Defender for Servers Plan 1/2, Defender for Endpoint for Servers, oppure Defender for Business servers (solo PMI).

Le funzionalità disponibili includono antivirus, EDR completo, threat analytics e advanced hunting, vulnerability management, live response e device isolation, tutto centralizzato nella stessa console Defender usata per Windows e macOS.

Distribuzioni supportate e requisiti

Il requisito minimo di kernel resta 3.10.0-327, con systemd richiesto come system manager (le varianti SystemV o Upstart non sono supportate). Per la device isolation servono iptables/ip6tables oppure le loro varianti -nft.

Requisiti hardware minimi: 1 vCPU, 1 GB di RAM e 2 GB di spazio disco (di più per carichi intensivi). Da notare un avviso di deprecazione: il supporto per Amazon Linux 2 su ARM64 termina il 31 ottobre 2026 — chi lo usa deve pianificare la migrazione subito.

Come fare l’onboarding

Il flusso resta quello classico basato su repository Microsoft. Su una distribuzione RPM-based, ad esempio:

sudo yum install yum-utils
sudo yum-config-manager --add-repo=https://packages.microsoft.com/config/[distro]/[version]/[channel].repo
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
yum makecache
sudo yum install mdatp

dove [channel] è prod, insiders-fast o insiders-slow secondo le proprie esigenze di aggiornamento. Su Debian/Ubuntu la logica è identica con apt al posto di yum. Dopo l’installazione del pacchetto, va scaricato dal portale Defender (Impostazioni > Gestione dispositivi > Onboarding) il pacchetto di onboarding specifico ed eseguito sulla macchina per collegarla al tenant.

Per deployment su più macchine, Microsoft mette a disposizione il Defender Deployment Tool for Linux (GA da luglio 2026), che unifica installazione, onboarding, upgrade e disinstallazione, valida i prerequisiti, supporta repository locali e integra la Device Timeline. In alternativa, resta disponibile il repository microsoft/mdatp-xplat su GitHub con script pronti per Ansible e Puppet.

Verificare lo stato dell’agente

mdatp health
mdatp health --field real_time_protection_enabled
mdatp health --field org_id
mdatp health --field cloud_enabled
mdatp health --field definitions_status

Testare il rilevamento

curl -o ~/eicar.com.txt https://www.eicar.org/download/eicar.com.txt
mdatp threat list

Se la protezione in tempo reale è attiva, il file EICAR viene intercettato e messo in quarantena immediatamente, e l’incidente compare nel portale Defender.

Attenzione a questi dettagli in produzione

• Fanotify: eseguire Defender insieme ad altre soluzioni basate su fanotify in modalità blocking (diversa da FAPolicyD su RHEL/Fedora) non è supportato e può causare comportamenti imprevedibili, inclusi blocchi del sistema. In questi casi occorre impostare l’antivirus in modalità passive.
• Utente mdatp: l’installazione crea un utente di sistema con UID/GID casuali. Se serve un valore prevedibile (ad esempio per policy di hardening), va creato manualmente prima dell’installazione con shell /usr/sbin/nologin.
• Proxy: sono supportati solo proxy statici o trasparenti. PAC, WPAD, proxy con autenticazione e SSL inspection non sono supportati: per l’ispezione SSL va creata un’eccezione che lasci passare il traffico diretto verso gli URL di Defender.

Conclusione

Per i team che gestiscono flotte Linux miste tra server e workstation di sviluppo, questa estensione chiude un divario di visibilità reale: avere EDR, vulnerability management e device isolation anche sui laptop degli sviluppatori — spesso il vettore più sottovalutato — significa poter correlare un’anomalia su una workstation con un incidente osservato sui server, nella stessa console. Essendo ancora in Public Preview, vale la pena pilotarla su un gruppo di macchine non critiche prima di estenderla a tutta la flotta, verificando in particolare la classificazione automatica server/workstation e l’impatto di eventuali altre soluzioni basate su fanotify.

Fonte: Petri.com – Microsoft Brings Defender for Endpoint to Linux Desktops in Public Preview, con dati tecnici aggiornati dalla documentazione ufficiale Microsoft Learn.