Newsgroup: it.comp.os.linux.sys
Titolo: Spam in uscita da virus

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?
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 Con postfix che si può fare?
 
Io ho risolto con policyd e mettendo poi uno smarthost per il delivery che fa rate limit con exim. In questo modo ho due punti di controllo e se mi mettono in blacklist lo smarthost il server rimane attivo.

 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... :-P
 
[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.


'spè che è lunedì mattina e ho preso solo 3 caffè..
Se ti mettono in bl lo smarthost i tuoi clienti non inviano comunque email 
perché quello va in bl
O mi son perso qualcosa (considera che ho pure fame)?


 O mi son perso qualcosa (considera che ho pure fame)?
 
Ho un check ogni 10 minuti che mi avvisa se il mio relay va in BL e un monitoraggio sulla lunghezza della coda e sui bounce


Ok, ora è più chiaro


 
Mi ci vorrebbe per alcuni clienti codesta modalità
 
Quello che vedo è (comunque) che lo spam o è calato di volume (e quindi è in 
minor percentuale rispetto alle email arrivate al server) oppure le bl son 
sempre meno efficaci (spam-stats mi dice che il 77% di quello che arriva è 
stato consegnato e mi pare troppo.. ho le solite zen, spamhaus e barracuda 
più 2 controlli sull'helo presi in una certa mailing lists...(c'è anche da 
considerare che alcuni ip telecom, aruba ecc sono in whitelist).
 
C'è qualche altra spam farm da buttare fuori senza alcuna remora?


 C'è qualche altra spam farm da buttare fuori senza alcuna remora?
 
Diverse, ma a meno di non seguire l'andamento delle sorgenti di spam da
vicino (e quindi sapere quando rimuovere i blocchi applicati nonchè
essere pronti ad aprire pinhole in caso di FP), non consiglierei di
agire in proprio.
 


 
Guarda Skull, se vuoi approfondire, una carissima persona ha appena 
scritto sul suo blog un articolo interessantissimo che, come al solito, 
diventa un preferito irrinunciabile :-))


Prrrt :-P
 

 
 
Beccato uno oggi grazie alla segnalazione di AOL.. ma vista la quantità di 
email inviate mi aspetto una bussatina da spamhaus e company.
Tra le altre cose era il solito phishing con allegato scr zippato ma nessuna 
delle firme di clamav si è sentito in dovere di intervenire..
Volevo evitare spamassassin ma mi sa che mi tocca (anche se nel mio caso mi 
sa che devo evitare i filtri bayesiano
 
PS: son contento di averti dato uno spunto per il blog ;;
