Trovare ogni dispositivo che invia ancora mail con SMTP basic auth

Microsoft ha annunciato il ritiro della Basic authentication per SMTP AUTH in Exchange Online, e i dispositivi che smettono di funzionare per primi sono quelli di cui nessuno ricorda la configurazione: scanner, stampanti multifunzione e vecchi application server con la password di una casella digitata in un modulo web. Il calendario del ritiro è stato aggiornato, quindi per le scadenze attuali consulti l'ultimo annuncio di Microsoft invece di fidarsi della data riportata in un articolo di blog, questo compreso. Il lavoro di inventario è lo stesso, qualunque sia la data.

Perché questo fronte è ancora aperto

La Basic authentication era già stata disattivata in Exchange Online per Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover e per i client Outlook. SMTP AUTH è stato lasciato com'era dove veniva utilizzato, e disattivato nei tenant in cui non lo era.

Oltre il 97 percento degli attacchi di credential stuffing e oltre il 99 percento degli attacchi di password spray sfrutta la legacy authentication, secondo l'analisi di Microsoft nella sua guida al blocco della legacy authentication.

SMTP AUTH è utilizzato dai client POP3 e IMAP4 che devono anche inviare, e da applicazioni, server di reportistica e dispositivi multifunzione che generano posta.

Individuare ciò che lo usa ancora

Potrebbe non trovare nulla. Se i security defaults sono attivi, SMTP AUTH è già disattivato in Exchange Online, e lo è anche per le organizzazioni create dopo gennaio 2020, a meno che qualcuno non lo abbia abilitato per singola casella.

In caso contrario, parta dai sign-in log. Nel Microsoft Entra admin center vada su Entra ID > Monitoring & health > Sign-in logs, aggiunga la colonna Client App e filtri sui protocolli di legacy authentication. Ripeta l'operazione nella scheda User sign-ins (non-interactive), perché i dispositivi raramente effettuano accessi interattivi. Il workbook Sign-ins using legacy authentication aiuta nel triage.

Poi esamini le caselle. Le impostazioni per singola casella prevalgono su quella a livello di organizzazione, quindi elenchi le caselle in cui SMTP AUTH è abilitato esplicitamente:

$Users = Get-CASMailbox -ResultSize unlimited
$Users | where {$_.SmtpClientAuthenticationDisabled -eq $false}

Un valore vuoto significa che la casella segue l'impostazione dell'organizzazione, che si verifica con Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled. Controlli poi la pagina "scan to email" della stampante, le impostazioni di notifica dell'ERP, gli strumenti di monitoraggio e di backup e ogni script pianificato che invia un report.

Associ ogni riscontro a un responsabile e annoti l'indirizzo mittente, la porta, se il mittente è ospitato da una terza parte e se i destinatari sono interni o esterni. Questi dati servono per scegliere la soluzione sostitutiva.

A cosa deve migrare ciascun mittente

La destinazione giusta dipende da cosa sa fare il mittente, da dove gira e a chi scrive.

Microsoft raccomanda OAuth per il client SMTP submission, e indica HVE per la posta solo interna e Azure Communication Services Email per la posta interna ed esterna. Con un mail server on-premises è possibile anche eseguire il relay attraverso di esso, usando la Basic authentication verso di esso oppure un relay anonimo (non un open relay).

Verifichi prima i volumi. L'invio con OAuth è limitato a 10.000 destinatari al giorno e 30 messaggi al minuto. L'SMTP relay non è soggetto a tali limiti, anche se ne ha di propri ragionevoli, e HVE non ha limiti di destinatari o di frequenza dei messaggi per la posta interna.

Stampanti e scanner

Controlli prima il firmware, perché un aggiornamento del produttore potrebbe aggiungere OAuth. In caso contrario, la soluzione abituale è l'SMTP relay basato su connettore. Non richiede una casella con licenza, si autentica tramite certificato TLS (raccomandato) oppure tramite un IP pubblico statico non condiviso con un'altra organizzazione, e usa la porta 25 verso il Suo endpoint MX.

Il relay non salva nella Posta inviata e non aggira l'anti-spam, quindi la posta sospetta può essere filtrata. Microsoft raccomanda l'inserimento di una voce nel record SPF, e Lei può verificare il record con il nostro verificatore DMARC e SPF. Un dispositivo che usa di default la porta 465 non supporta le versioni TLS richieste dal client SMTP submission, e uno privo di TLS 1.2 non può usarlo affatto.

Sistemi ERP e altre applicazioni

Le applicazioni line-of-business come un ERP sono le più difficili, perché il codice di invio della posta appartiene al fornitore. Chieda se il prodotto supporta OAuth 2.0 per SMTP o la Graph API. In caso contrario, il relay tramite connettore è la soluzione di ripiego, a condizione che l'applicazione giri nella Sua rete.

Se è il fornitore a ospitarla, il relay è escluso: la tabella di Microsoft indica l'SMTP relay come l'unico metodo che non supporta i mittenti ospitati da terze parti. Il fornitore può usare il client SMTP submission con OAuth, HVE se la posta è destinata solo a destinatari interni, oppure Azure Communication Services Email. Anche Direct Send funziona per i mittenti ospitati, ma non è autenticato, quindi aggiorni il Suo record SPF per consentire al fornitore di inviare a nome del Suo dominio.

Se l'applicazione invia con un indirizzo diverso da quello della casella che effettua l'accesso, conceda il permesso Send As. Senza di esso i messaggi rimbalzano con 5.7.60 SMTP; Client doesn't have permissions to send as this sender.

Script

Per gli script sotto il Suo controllo, Microsoft indica la Graph API come alternativa per la posta autenticata, oppure è possibile implementare OAuth 2.0 verso gli endpoint IMAP, POP o SMTP.

Da dove cominciare

1. Estragga gli accessi legacy dai sign-in log di Entra, interattivi e non interattivi, ed elenchi le caselle in cui SmtpClientAuthenticationDisabled è $false.
2. Assegni un responsabile a ogni mittente e registri i suoi destinatari (interni o esterni), la porta, il supporto TLS e se è ospitato da una terza parte.
3. Scelga una destinazione dalla tabella qui sopra, provi un dispositivo per tipo ed effettui il passaggio di ciascuno solo dopo un messaggio di prova riuscito.
4. Dopo la migrazione, esegua Set-TransportConfig -SmtpClientAuthenticationDisabled $true. Una casella ancora impostata su $false prevale su tale impostazione, quindi imposti ciascuna su $null (segue l'organizzazione) oppure su $true con Set-CASMailbox. Riesegua il filtro -eq $false per dimostrare che non ne restano e confermi il valore dell'organizzazione con Get-TransportConfig.
5. Crei una policy di Conditional Access che blocchi la legacy authentication, impostata prima su Report-only, con almeno un account di emergenza escluso.

Se dall'inventario emergono più elementi di quanti ne possa migrare in tempo, il nostro team di consulenza può aiutarLa con la valutazione e il piano di passaggio.