Guide / security
Provare l'antispam quando il filtro ignora la posta interna
GTUBE non produceva nessuna intestazione SCL, e il filtro aveva ragione. Due invii identici con esiti opposti, e una riga di log mancante che prova tutto.
Il piano era semplice: attivare gli agenti antispam nativi di Exchange, mandare un messaggio di prova contenente GTUBE, e guardare comparire l’intestazione SCL.
Non è comparsa nessuna intestazione. Il filtro sembrava rotto. Stava funzionando esattamente come previsto, e scoprire perché ha prodotto il risultato più utile di questa parte del laboratorio.
Attivare gli agenti
Su un server Cassette postali non sono installati per impostazione predefinita, e un’interfaccia non c’è.
cd $env:ExchangeInstallPath\Scripts
.\Install-AntispamAgents.ps1
Restart-Service MSExchangeTransport
Get-TransportAgent
Il filtro che non filtrava
Non è un limite. È quello che fa qualunque sistema antispam serio: filtrare la corrispondenza fra colleghi che si sono già autenticati costerebbe elaborazione su ogni messaggio interno per intercettare una categoria di minaccia che l’autenticazione ha già affrontato.
La conseguenza per chi collauda è la parte da interiorizzare: l’antispam non si può provare dall’interno dell’organizzazione. Nessuna quantità di GTUBE farà scattare niente, perché il messaggio non arriva mai all’agente che dovrebbe assegnargli un punteggio.
Arrivare come arriva lo spam
Il rimedio è smettere di essere attendibili: aprire una sessione SMTP non autenticata direttamente verso la porta 25.
PowerShell non lo fa digitando al prompt — interpreta quello che scrivi come comandi propri invece di inoltrarlo come dialogo SMTP grezzo. Serve un socket TCP.
$socket = New-Object System.Net.Sockets.TcpClient("<indirizzo del server>", 25)
$stream = $socket.GetStream()
$writer = New-Object System.IO.StreamWriter($stream)
$reader = New-Object System.IO.StreamReader($stream)
$writer.AutoFlush = $true
function Send-Line($cmd) { $writer.WriteLine($cmd) }
function Read-Response() {
Start-Sleep -Milliseconds 1000
while ($stream.DataAvailable) { $reader.ReadLine() }
}
La lettura bloccante che congelava la sessione
È più profondo di quanto sembri. Scrivere un client SMTP richiede di conoscere la macchina a stati del protocollo, non solo la sequenza dei comandi: dove il server parla e dove tace di proposito. È esattamente la conoscenza che usare un client di posta già pronto nasconde del tutto, ed è il motivo per cui costruirne uno rozzo insegna più che leggerne la descrizione.
Il risultato opposto: EICAR
Stesso laboratorio, stesso invio interno, agente diverso.
Un file di prova EICAR allegato a un messaggio interno ha confermato il comportamento opposto: l’agente Malware ispeziona tutta la posta, compresa quella interna.
Il motivo è il modello di minaccia. Lo spam arriva da fuori per definizione — un mittente interno autenticato non ti manda posta commerciale non richiesta. Il malware non funziona così: un allegato pericoloso può benissimo arrivare dall’account compromesso di un collega, che è uno dei modi più comuni in cui arriva davvero.
La riga di log che non c’era
Il messaggio EICAR inviato internamente non è mai arrivato. Il log di tracciatura mostrava RECEIVE e SUBMIT — e poi più niente.
Vale ben oltre questa prova. In un sistema che registra ogni passaggio, l’evento mancante localizza un guasto meglio di quelli presenti — a patto di sapere quali eventi aspettarsi. Che è un buon argomento per studiare la pipeline prima del formato dei log.
Due indicazioni di Microsoft che vale la pena tenere
Rifiutare presto invece di mettere in quarantena. I messaggi intercettati dal filtro connessioni, dal filtro destinatari e dal filtro mittente vanno rifiutati subito. Per due motivi: se hai configurato esplicitamente un mittente come bloccato non c’è ragione di continuare a elaborarne la posta, e più un messaggio avanza nella pipeline più variabili devono valutare gli agenti rimanenti. Rifiutare presto i casi ovvi libera risorse per quelli ambigui.
Partire dai valori predefiniti e misurare. Si comincia dalle impostazioni di fabbrica per ridurre al minimo i falsi positivi, si misura quanto spam e quanti falsi positivi arrivano davvero, e si aumenta l’aggressività in base agli attacchi che si ricevono — non a quelli che si immaginano.