Visto che oramai son scritte, tantovale riciclarle qui, dove magari possono essere integrate e corrette nel tempo (e magari popolano anche queste pagine altrimenti scevre di novità)…Inizio con questa, passata su it.comp.os.linuxsys:
Hola, capita che qualche cliente si becchi uno worm di quelli che invia le
credenziali email per spammare.
Il server ovviamente lo fa inviare (ha login e password corretti) e le
botnet nuove sono abbastanza intelligenti da non inviare troppe email
insieme (per non sovraccaricare il server) e magari le spediscono fuori
orario ufficio (così vengono beccati dopo qualche giorno).
Oltre a decapitare il cliente (è comunque una azione postuma) che si può
fare?
Avevo pensato ad un controllo che bloccasse invii da classi di ip diverse
(chessò, invii da 10 classi ip differenti in 12 ore) ma è un approccio forse
un po’ troppo grossolano (c’è comunque un filtro di fail2ban o un milter
adatto?)
Con postfix che si può fare?
E’ un argomento che è già stato affrontato a più riprese in passato,
perlopiù in altri lidi.
Una soluzione facile e veloce (in particolare del tipo “fire and
forget”) di fatto non c’è, soprattutto perché ognuno ha esigenze e
soglie di intervento diverse, in funzione degli utenti che ha.
Ergo è difficile ipotizzare una soluzione che sia adatta a tutti.
Ad esempio, la soluzione di segare “invii da 10 classi ip differenti in
12 ore” forse si adatta ai tuoi utenti, ma basta una mailbox “di ruolo”
utilizzata da più persone con diverse connessioni (o addirittura in giro
per il mondo) e il presupposto che fai crolla.
Quel che ti posso dire è come è normalmente affrontato il problema su
installazioni di scala ISP, che è ovviamente dove il problema è più sentito.
Per questa tipologia di utenze ci sono anche soluzioni commerciali
precotte e piuttosto potenti (come alternativa al “fai da te”), ma hanno
inevitabilmente un costo, e nemmeno basso (sicché vengono di solito
scelte soprattutto da grossi ISP con scarso skill interno; perlopiù
telco, soprattutto in “paesi emergenti”)[1].
Sarà un po’ lunga… 😐
Parti con il ridefinire gli obiettivi, perché in realtà ne hai due,
anche se non te ne rendi conto:
1) segare le utenze abusate il più velocemente possibile
2) salvaguardare la reputazione dei tuoi mailserver d’uscita
onde evitare che il normale delivery venga eccessivamente penalizzato (anche
perché entrare in determinate liste è molto facile; uscirne può essere
molto difficile)
1. Segare le utenze abusate il più velocemente possibile
Quel che puoi fare qui dipende molto dalle caratteristiche delle tue
utenze e delle tue installazioni. Alcune prassi -come quella che
ipotizzi- sono attuabili per alcune utenze ma non per altre. Ci sono due
cose, tuttavia, che sono circa universali.
1a) reject outbound, purchè in prequeue
alcune tipologie di email abusive possono essere individuate
praticamente a colpo sicuro sulla base di specifiche firme. E’ il caso
delle email con payload virale, ma anche di molto “semplice spam” che fa
riferimento a risorse specifiche e note.
SaneSecurity (ad esempio) colleziona una buona quantità di database per
clamav, ergo una accurata selezione dei DB con basso indice di FP può
essere applicato a questo livello, purchè la mail venga fermata prima
dell’ingresso in coda (quindi milter, nel tuo caso) nella sessione tra
MUA e MSA.
1b) filtering outbound, senza azione immediata
il tipo di filtraggio sui contenuti che operi sulla posta in ingresso lo
puoi applicare (con alcune modifiche) anche sulla posta in ingresso all’MSA.
Quel che vuoi che cambi, tuttavia, è l’azione.
– Se l’analisi della mail porta ad individuare un messaggio con una
“spammosità” particolarmente alta, vorrai riservare un “trattamento
particolare” al singolo messaggio, che vediamo al punto 2.
– Per score più bassi ma comunque con un “indice di spammosità”
peroccupante, quel che ti interessa, più che il singolo messaggio, è la
media ottenuta dagli invii eseguiti per tramite delle stesse
credenziali: se un determinato utente SMTP-AUTH inizia a inviare “tanti
messaggi spammosi” (fermati con le risorse al punto 1a oppure
“abbastanza spammosi da essere sospetti”), è il caso di riservare a
tutti i messaggi di tale utente lo stesso trattamento cautelativo sopra
applicato al singolo MAS (Messaggio Assai Spammoso).
– Se il numero di “messaggi spammosi” sale sopra un certo livello, ha
senso sospendere l’utenza in toto.
Nota che la definizione di “tanti” e “certo livello” vanno tarati in
funzione della singola realtà, e l’unica è simulare e/o sperimentare
quali siano i valori più adatti a te.
2. Salvaguardare la reputazione dei tuoi server di uscita
I Messaggi Assai Spammosi che ti entrano in coda oramai li devi consegnare.
Altrettanto vale per i messaggi non particolarmente spammosi ma
iniettati da una utenza probabilmente compromessa: anche se tu non sei
riuscito ad identificarli come spam, è assai plausibile che lo siano. Se
li consegni, la reputazione dei tuoi punti di uscita ne soffre
inevitabilmente.
Quel che abitualmente si fa, per salvare -nei limiti del possibile-
capra e cavoli, è dedicare uno o più sistemi al delivery della monnezza.
Quindi: email che sono plausibilmente spam (ma per cui non hai certezza
assoluta) e/o provenienti da account possibilmente compromessi (per i
quali devi necessariamente avere “più statistica” prima di decidere se
applicare o meno la sospensione dell’account) verranno instradati
attraverso questo/i altro/i sistema/i.
Ovviamente, questo sistema è destinato ad avere una reputazione assai
meno buona del sistema principale, ed è esattamente quello il suo scopo…
Alcuni operatori richiedono addirittura espressamente agli operatori di
DNSBL di includere gli IP di questi sistemi nelle loro liste, in maniera
preventiva.
Tirando le somme: gran parte di ciò che compone l’architettura sopra
descritta esiste già, a costo zero.
Clamav e SpamAssassin per l’inspection dei messaggi, ad esempio.
I milter in grado di applicarli alla sessione SMTP prima dell’ingresso
in coda ache.
Postfix ha tutti i meccanismi necessari all’instradamento condizionale,
e altrettanto vale per qualsiasi MTA non-giocattolo.
Quel che manca (e che poi ognuno implementa in proprio) è un meccanismo
che mantenga la necessaria statistica dello spam/ham emesso da ciascuna
utenza SMTP-AUTH, e la formula da applicare a tale statistica per
decidere se una determinata utenza è “pulita”, “forse compromessa” o “da
sospendere”, che come detto può dipendere in maniera sostanziale
dall’ambiente.
Un caveat va aggiunto per quanto riguada SpamAssassin: IMHO, il ruleset
di default è costruito su assunti deliranti[2] e va fortemente
aggiustato, sia per renderlo più performante (alcuni test sono
estremamente lenti ed hanno una efficienza prossima allo zero), sia per
renderlo più efficace (ad esempio, gli score associati a diverse DNSBL
sono ridicolmente bassi). Se vuoi ottenere risultati decenti devi
personalizzarlo fortemente, ma questo vale sia per la posta in ingresso
che per quella in uscita, ergo non è specifico del topic.
<berserk mode off>
[1] http://www.mailchannels.com/ se ne vuoi una. Non prendo provvigioni;
giusto per chiarire…
[2] non entro nel merito del perché. Al di là del fatto che non
servirebbe a nulla (been there, seen that), sarebbe comunque poco
cortese fuori da ML SA-oriented.
Skull's blog 
Leave a Reply