Newsgroup: it.comp.os.linux.sys
Titolo: SpamAssassin e URIBL...

 
Ho seguito con estrema attenzione la discussione che c'è stata qui a seguito
dell'ultimo spamrun. I miei ringraziamenti in particolare a Skull per quanto
fa!
 
Sono su debian wheezy, quindi SA 3.3.2-5+deb7u2 .
 
Non conoscevo DBL, ma (pensavo, perlomeno) di usare da tempo delle URIBL nel
mio SpamAssassin, in particolare la mia configurazione era:
 
  skip_rbl_checks 1		# Perchè lo faccio a livello di SMTP, exim
 
  #skip_uribl_checks 0		# è il default
 
  score URIBL_BLACK 3		# Queste derivano da una chiaccherata con MdI
  score URIBL_RED 0
  score URIBL_JP_SURBL 3
  score URIBL_AB_SURBL 3
  score URIBL_OB_SURBL 3
  score URIBL_WS_SURBL 3
  score URIBL_SBL 3
 
e a cui ho aggiunto, per l'intanto:
 
  score URIBL_DBL_SPAM 3
 
 
A quel punto mi sono messo a ''guardare'' i log, ma non ''beccavo'' nulla
con 'DBL'; guardando meglio, ho visto che non ho mai (ultime 4 settimane)
''beccato'' nulla con ''URIBL''. Direi molto strano...
 
 
Ho verificato con 'spamassassin -D --lint' e il modulo sembra essere
caricato senza errori (in particolare, non vedo segnalazioni di mancanza di
moduli perl).
Ho provato a commentare (ergo, =0) skip_rbl_checks, ma non è cambiato nulla
comunque.
 
 
Dove sbaglio? Grazie.
 
-- 
  Alla fiera dell'est, per due soldi
  un topolino mio padre compro`				(A. Branduardi)

 fa!
 
 > A quel punto mi sono messo a ''guardare'' i log, ma non ''beccavo'' nulla
 > con 'DBL'; guardando meglio, ho visto che non ho mai (ultime 4 settimane)
 > ''beccato'' nulla con ''URIBL''. Direi molto strano...
 >
 
 
io ho aggiornato tutti i mailserver con quelle configurazioni, e questo 
è l'esito di un mailserver più soggetto a spam (vuoi perchè ha molte 
caselle, vuoi perchè ha contatti con diverse nazioni, etc..)
 
cat /var/log/
mail.info
 | grep "reject" | grep "xbl" | wc -l
47
cat /var/log/
mail.info
 | grep "reject" | grep "dbl" | wc -l
5
cat /var/log/
mail.info
 | grep "reject" | grep "sbl" | wc -l
0
 
Ovviamente prendi questi numeri con beneficio d'inventario, i log sono 
stati ruotati da poco.
 
 
 
Per la cronaca, in fase di envelope, postfix è stato settato così 
(relativamente alle dbl di spamhaus):
 
	reject_rbl_client 
xbl.spamhaus.org
=127.0.0.[4;5]
	reject_rhsbl_client 
dbl.spamhaus.org
=127.0.1.[2..99]
         reject_rhsbl_helo 
dbl.spamhaus.org
=127.0.1.[2..99]
         reject_rhsbl_sender 
dbl.spamhaus.org
=127.0.1.[2..99]
	reject_rbl_client 
sbl.spamhaus.org
=127.0.0.3
 
e spamassassin così:
 
if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only) 
    #URIBL_DBL_SPAM
urirhssub       URIBL_DBL_SPAM   
dbl.spamhaus.org
.       A 127.0.1.10[2-6]
body            URIBL_DBL_SPAM   eval:check_uridnsbl('URIBL_DBL_SPAM')
describe        URIBL_DBL_SPAM   Contains an URL listed in the DBL blocklist
tflags          URIBL_DBL_SPAM   net domains_only
score           URIBL_DBL_SPAM   6
endif           #URIBL_DBL_SPAM
 
quindi
cat /var/log/
mail.info
 | grep "reject" | grep "URIBL_DBL_SPAM" | wc -l
0
 
 
 
 
Considerazioni:
 
non vedo blocchi sbl, però c'è da dire che il reject dovrebbe essere 
FIFO, quindi semplicemente magari le xbl rifiutano la maggior parte 
della roba, le dbl il resto e a sbl non rimane nulla... magari mettendo 
in testa sbl i log restituirebbero altre statistiche.
Mentre in fase di analisi non becco nulla, ma del resto probabilmente 
vale il discorso di prima, l'sbl fa già il suo lavoro con postfix (che è 
anche meglio, visto che l'email nemmeno entra).
 
 
 
PS: per lo spam da libero, non sottovalutare questa custom rules 
(perfettamente funzionante così come skull l'ha postata), per me è stata 
una salvezza, almeno per questa ondata e per questo momento:
 
header CUSTOM_OGGETTO01 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d AM/i
score CUSTOM_OGGETTO01 100.0
header CUSTOM_OGGETTO02 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d PM/i
score CUSTOM_OGGETTO02 100.0
 
 
 
 
 

 score CUSTOM_OGGETTO02 100.0
 
 
FTR, potevi facilmente condensare in una unica REGEXP:
 
 
header CUSTOM_OGGETTO01 Subject =~ /\d\d?\/\d\d?\/2015 \d\d?:\d\d:\d\d
[AP]M/i
 
 

 [AP]M/i
 
vero, ci avevo pensato ma alla fine avevo fatto tutti i test con due 
regole e per pigrizia ho lasciato così :)
 

 blocklist
 
ah no, ok, l'avevo erroneamente intesa come una wildcard. boh, le lascio 
tutte e 5 e pace, tanto non arrivo di sicuro alle 100.000 query/giorno a 
cui fa riferimento la licenza, sto anni luce sotto. Poi del resto non 
sono nemmeno sicuro lui faccia davvero 5 query, teoricamente se 
spamassassin fa delle query dns pure, dovrei avere in cache il 
risultato. o mi sbaglio?
 
 
La cosa bizzarra è che, pur spulciando in lungo ed in largo tutte le faq 
delle dbl di spamhaus, non ho trovato come testare solo il range 
102-106. 
dbltest.com
 restituirà sempre e comunque 127.0.1.2. Alla 
peggio, alla prima email contenente quel link, me lo segno per fare i test.
 

 peggio, alla prima email contenente quel link, me lo segno per fare i test.
 
Temo di non seguirti...
 


 
mi ero posto il problema di testare delle singole sottocategorie 
specifiche (ad esempio 127.0.1.104), ma mi sembra sia solo possibile 
fare la query di test per l'esito generico 127.0.1.2.
 
Questo perchè la 127.0.1.2 la rifiuto da postfix, ma le 102-106 da 
spamassassin in fase di analisi (quindi volevo vedere se funzionassero 
solo queste chiamate in causa in questa fase).

 solo queste chiamate in causa in questa fase).
 
la query è sempre e comunque per un dominio. Come
 
bofhland.org.dbl.spamhaus.org
 
 
per dire:
 
$ dig +noall +comments +answ a 
bofhland.org.dbl.spamhaus.org
.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54899
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 
 
O, volendo usare una query che è supposta tornare sempre "listed":
 
 
$ dig +noall +comments +answ a 
test.dbl.spamhaus.org
.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22968
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; ANSWER SECTION:
test.dbl.spamhaus.org
.	60	IN	A	127.0.1.2
 
 
 
Indipendentemente dal fatto che tu sia interessato ai record "cattivi"
(127.0.1.x con 1<x<99) o a quelli "semplicemente abusati" (con x>100),
la query che esegui è sempre la stessa.
 
E' poi il tuo lato a prendere decisioni diverse a seconda del
(eventuale) A record ottenuto in risposta.
 
 
Oppure non capisco la domanda (il che è abbastanza plausibile...)

 (eventuale) A record ottenuto in risposta.
 
certo.
 
immagina però di avere due interrogazioni, uno subito da postfix con il 
range 2-6, e uno successivamente da spamassassin con il range 102-106.
 
Succederà che qualcosa verrà rifiutata subito, e qualcosa dopo, 
analizzando il contenuto dell'email come per prassi di spamassassin.
 
 
detto questo, io utilizzo un metodo per vedere se le rbl dentro 
*spamassassin* funzionano: mando in pasto a spamc una bella email di 
spam (con tutto il possibile):
 
spamc -y -d 127.0.0.1 -p 783 < /tmp/spam.eml
 
e spamc mi risponde con i controlli che trova. All'interno dell'email 
ho, tra le altre cose, un bel link 
http://dbltest.dbl.spamhaus.org
 e lui 
non mi da nulla di dbl, perchè la query con esito 127.0.1.2 io non la 
controllo da spamassassin (che ha il range 102-106), ma solo da postfix 
nella fase antecedente.
 
 
ad ogni modo non è importante, ed ho risolto: ho preso i domini 
contenuti nella prima email beccata dai controlli 102-106 e l'ho 
aggiunto all'email di "test" che do in pasto a spamc per vedere se 
funziona tutto, ed ora testo le dbl anche in quelle sottocategorie. e 
pace. :)
 
 
 
 
 
 
 

 anche meglio, visto che l'email nemmeno entra).
 
...le regole sugli URI mi paiono estremamente più ''ricche'' si quelle sugli
IP chiamanti, quindi, scusa, ma questa cosa non riesco a farmela passare
così...
 
 
Oggi ho abilitato tutto:
 
 #skip_rbl_checks 1
 
 score URIBL_BLACK 3
 score URIBL_RED 0
 score URIBL_JP_SURBL 3
 score URIBL_AB_SURBL 3
 score URIBL_OB_SURBL 3
 score URIBL_WS_SURBL 3
 score URIBL_SBL 3
 
 score URIBL_DBL_SPAM 3
 score URIBL_DBL_PHISH 3
 score URIBL_DBL_MALWARE 3
 score URIBL_DBL_BOTNETCC 3
 score URIBL_DBL_ABUSE_SPAM 3
 score URIBL_DBL_ABUSE_REDIR 3
 score URIBL_DBL_ABUSE_PHISH 3
 score URIBL_DBL_ABUSE_MALW 3
 score URIBL_DBL_ABUSE_BOTCC 3
 
e non ho uno solo score che contenga una URIBL_* ...
 
 
Mah...
 
-- 
 Ragazzi, lavoriamo per il Signore:
 la paga non è un granchè, ma la pensione è roba dell'altro Mondo!!!
					(letta su una maglietta, da Stefy)

 e non ho uno solo score che contenga una URIBL_* ...
 
che query hai messo? non vorrei tu abbia copiato dal mio messaggio 
precedente. come giustamente diceva skull, l'espressione [2-6] non viene 
letta da spamassassin, vanno fatte righe separate 127.0.1.102, 103, 104 etc.
 

 messaggio transitato per smtp leciti ma proveniente d uno non lecito.
 
E' chiamato "deep header parsing", per la cronaca.
Ha alcuni caveat, perchè non tutte le dnsbl sono adatte a questo genere
di utilizzo.
 
In particolare, PBL (e, in generale, le "derivate dynablock") non ha
senso in questo contesto, mentre XBL ha senso applicarla quando lo
stesso IP non è al tempo stesso anche in PBL (o, almeno, ha senso
abbassare lo score associato a XBL se l'IP è anche in PBL)[1].
 
 
L'approccio è utile particolarmente per casi come quelli di cui al
thread precedente: botnet che inietta attraverso relay leciti; si cerca
di matchare ragionevolmente bene caratteristiche del body o degli
header, e si associa (META) la regola risultante con la condizione che
l'IP di iniezione sia -ad esempio- in XBL (è pur sempre un bot...).
 
Se usato con le dovute cautele, è un approccio estremamente utile,
particolarmente se si ha accesso a dati "raffinati". Tipo: non solo si
sa che l'IP ospita un bot, ma si sa anche quale tipologia di bot, in
modo da limitarne l'applicazione a bot che siano noti per sfruttare
SMTP-AUTH abusati (cutwail in primis).
 
 
 
[1] Ovviamente mi riferisco solamente al caso in cui l'IP in questione
*non* sia last-hop; ma se postfix applica già sia XBL che PBL il
problema non si pone, in teoria...
 

 Mah...
 
Ho provato a inviarmi una email con all'interno il link:
 
 
http://www.dbltest.com/
 
 
ed è passata senza alcun score URIBL_*...
 
-- 
  Microsoft is to Software as McDonalds is to Cuisine.


 
una domanda: il mailserver come risolve le query dns? passando da un 
server dns di un provider o direttamente?
 
dig che dice facendo la query di test?

 dig che dice facendo la query di test?
 
Sembra funzionare:
 
 gaio@armitage:~$ dig +noall +comments +answ a 
dbltest.com.dbl.spamhaus.org
.
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8119
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 20, ADDITIONAL: 0
 
 ;; ANSWER SECTION:
 
dbltest.com.dbl.spamhaus.org
. 60 IN	A	127.0.1.2
 
-- 
  Io chiedo quando sara` che l'uomo potra` imparare
  a vivere senza ammazzare e il vento si posera`	(F. Guccini)

 di utilizzo.
 
Immagino. Giusto per la tua esperienza, ti sei fatto una idea di score che
possono essere applicati qui in italia con efficacia?
 
-- 
  If SMB was an animal it would go wolf and most people would have shot it
  or put it down humanely.				(Rod Boyce)

 letta da spamassassin, vanno fatte righe separate 127.0.1.102, 103, 104 etc.
 
Uso sa-update, e ho verificato che negli update le query sono corrette.
 
-- 
  Le vie del Signore sono infinite.
  E' la segnaletica che lascia a desiderare...

 possono essere applicati qui in italia con efficacia?
 
Non saprei rispondere in maniera semplice, perchè da tempo non uso XBL
in quanto tale, in quel ruolo, ma una lista specificamente composta dai
soli IP ospitanti bot noti per abusare SMTP-AUTH...
 
Ma, come detto, se dovessi farlo oggi (come lo feci in passato), non lo
farei "a tappeto", ma solo in corrispondenza di altri indicatori che
facciano pensare ad un utilizzo abusivo dell'account.
E temo che canali pubblici quale questo siano inadatti a dare dettaglio
di cosa e come...

 di cosa e come...
 
Capisco. ;-)
 
-- 
  Voi avevate voci potenti, lingue allenate a battere il tamburo
  voi avevate voci potenti, adatte per il vaffanculo	(F. De Andre`)