Newsgroup: it.comp.os.linux.sys
Titolo: rbl affidabili

quali rbl mi consigliate di inserire in postfix?
 
reject_rbl_client 
bl.spamcop.net
,
reject_rbl_client 
sbl.spamhaus.org
,
reject_rbl_client 
dnsbl.sorbs.net
,
 
vanno bene?


Eliminerei la prima e l'ultima.
La prima perchè un po' troppo aggressiva e non adatta ad un filtraggio a
livello di envelope (ma in spamassassin va benone).
L'ultima perchè SORBS è sostanzialmente senza gestione da almeno 3 anni
(è stata acquisita fa GFI, che dopo averci perso tempo per un anno
cercando di cavarne qualcosa di vendibile, l'ha rivenduta appena ha
trovato qualcuno abbastanza pirl^H^H^H^Hcoraggioso -ProofPoint- da
pigliarsela, e ora questi ultimi stan provando disperatamente a
gestirla...), ed aveva già i suoi bei problemi quando veniva gestita.
 
In luogo di 
sbl.spamhaus.org
, userei 
zen.spamhaus.org
 (aggregato di SBL,
XBL e PBL).
 
Aggiungerei anche:
 
reject_rhsbl_helo 
dbl.spamhaus.org
=127.0.1.2
reject_rhsbl_client 
dbl.spamhaus.org
=127.0.1.2
reject_rhsbl_sender 
dbl.spamhaus.org
=127.0.1.2
 
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 


 
come al solito ti ringrazio.

 livello di envelope (ma in spamassassin va benone).
 
Sbaglio o la sua aggressività è aumentata da poco tempo a sta parte?
A parte i mesi iniziali, in cui era impossibile da usare (listava tutto
e tutti) da almeno 2 anni a sta parte la uso con successo se non fosse
per gli ultimi 2-3 mesi in cui sto notando un po troppa aggressività.
 
Han cambiato qualche policy?
 
-- 
Tu non puoi passare!
Sono un servitore del fuoco segreto e reggo la fiamma di Anor!
Il fuoco oscuro non ti servirà a nulla, fiamma di Udur!
Ritorna nell'ombra! TU NON PUOI PASSARE!

 Han cambiato qualche policy?
 
No, le policy sono sempre quelle: spamcop lista in funzione del ratio
spam/ham rilevato.
 
Ci sono però due condizioni al contorno che ne possono cambiare
sostanzialmente l'efficacia:
 
1) che lo spam è facile da rilevare (visto che spamcop raccoglie
segnalazioni), ma l'ham molto, molto meno...
I problemi "iniziali" (per anni, non mesi) di Spamcop eran relativi a
questo aspetto: per grossi mailserver di ISP regionali (come può essere
ad esempio Libero, che ha clientela internazionale estremamente scarsa
ma volumi comunque importanti) SpamCop rilevava quasi esclusivamente lo
spam, senza rilevare l'ham, con il risultato che mailserver di questo
genere venivano periodicamente listati.
 
2) che le metodologie di iniezione sono un moving target: le soglie che
fino a un paio d'anni fa venivan superate solo da macchine compromesse
oggi vengono superate anche da server con *account* compromessi. Via
trojan, spear-phishing, bruteforce ecc. E più grosso il server, maggiore
il numero di account compromessi.


 sostanzialmente l'efficacia:
[cut]
 
Ok, ma visto che lo spam evolve, si presuma debbano evolvere anche
le condizioni di listing, altrimenti, seguendo il tuo ragionamento,
tra un po di tempo spamhaus listerà il mondo intero perdendo di
efficacia.


 efficacia.
 
No, perchè spamhaus lista in funzione delle sue policy, non di quelle di
spamcop...
 
Peraltro, se le condizioni sono cambiate a tal punto da dover prevedere
nuove policy, si apre una nuova lista e la si affianca alla vecchia, non
si cambiano le policy della vecchia (come regola generale).
 
La ragione è che -banalmente- la maggior parte dei fruitori di DNSBL non
seguono in alcun modo l'evolversi di queste policy, e se gliele cambi
sotto il sedere, si ritrovano a fare qualcosa di diverso da quel che la
policy attuale suggerirebbe, riversando sui gestori della DNSBL delle
mancanze proprie e abbassando la qualità percepita della DNSBL stessa.
 
ORDB dice niente?


 mancanze proprie e abbassando la qualit percepita della DNSBL stessa.
 
Non dico cambiare in toto le policy, ma seguire maggiormente
l'evolversi
dello spam pur rispettando la policy.

 l'evolversi dello spam pur rispettando la policy.
 
 
Ma anche no.
Perchè la policy di spamcop (a meno di cambiarla in toto) basata sul
rapporto spam/ham.
Quindi un listing spamcop ti dà una indicazione di massima sulla
probabilità che una mail proveniente da un dato IP possa essere spam, ma
nulla più.
 
E -non a caso- anche nei suoi momenti di più fulgida efficienza le
policy di Spamcop hanno sempre sconsigliato l'utilizzo in reject.
 
Analogamente, un listing XBL ti dice che la mail proviene da un IP noto
per ospitare un trojan.
E al di là che l'effetto in termini di filtraggio possa essere simile
(ma il tasso di FP di XBL Spamcop se l'è sempre sognato, anche nei
"momenti buoni"), il *significato* del listing è profondamente diverso,
e l'utilizzo va commisurato anche (se non soprattutto) al significato.
 
"Seguire maggiormente l'evolversi dello spam",  quindi, significa
cambiare il significato stesso di un listing su Spamcop, e questo
difficilmente avverrà.
 
Anche perchè in realtà SCBL (che è in realtà il vero nome della DNSBL
cui ci riferiamo) è solamente una delle forme che i dati di Spamcop
prendono: l'intera sublist "SC" di SURBL è generata sulla base dei dati
di Spamcop, cosiccome parte dei database non-pubblici che Cisco
("proprietaria" di spamcop e di IronPort che la creò) poi utilizza per i
propri clienti sugli apparati IronPort.
 

 difficilmente avverr .
 
No, semplicemente basterebbe adottare un efficace sistema di
segnalazione ham, o almeno trovare il modo di dargli maggior peso.
Come hai già scritto, i server Libero veicolano milioni di mail,
magari poco verso l'estero. Se di questo poco il 90% è spam, SC lo
lista,
incurante del fatto che da quel server magari escono anche 45
milioni di mail ham al giorno.
 
In soldoni: Libero invia 50 milioni di mail al giorno. Questi 50
milioni,
100 (cento) email sono spam inviate verso spamcop, le altre 49.999.900
sono mail legittime inviate altrove.
SC listerà libero per l'eternità, perchè ha ricevuto solo spam percui
avrà sempre un rapporto 100:0.
 
reject sugli MX o scoring da qualche altra parte, il rapporto non
cambia

 milioni di mail ham al giorno.
 
Questo problema è stato risolto da parecchio tempo, e non ha nulla a che
fare con le problematiche attuali di spamcop.
 
Torna indietro di 3 post e rileggi.

 nulla pi .

 il rapporto sarà sempre positivo.
 
Riceve solo spam *dalle segnalazioni*.
 
La stima degli ham viene fatta per altre vie.
Hint: dai un occhio a chi è il registrant per senderbase.org...
 

 Hint: dai un occhio a chi il registrant per senderbase.org...
 
Cisco.
Ma a quanto pare, questo sistemino negli ultimi mesi è peggiorato,
perchè come ho scritto, ho usato SC in reject per almeno 2 anni
con un numero di FP trascurabile, negli ultimi 2 mesi a sta parte
invece sto avendo lamentele. Tutti server Telecom.

 invece sto avendo lamentele. Tutti server Telecom.
 
 
Il sistema è peggiorato perchè lo spam cambia comportamento (ho un deja vu).
 
D'altra parte se domani il 90% dei bot smettesse di inviare in
direct-to-mx, anche XBL perderebbe di gran parte della sua utilità...


 Il sistema è peggiorato perchè lo spam cambia comportamento (ho un deja vu).
 
E' proprio qui che non ti seguo.
Se sostanzialmente SC lista in base ad un rapporto spam/ham, in che modo
il comportamento dello spam può influenzare questo rapporto?
Indipendentemente dalla tipologia, lo spam è spam e l'ham resta ham,
cambiano le tecniche, ma sempre spam è.
 
Se il mio server prima inviava 100 spam e 10 ham, potrà cambiare il
modus operandi, ma il server continuerà ad inviare spam.
 
Pertanto, o è diminuita la quantità di ham che viene inviata tramite
un dato server, sfasando il rapporto, oppure e aumentato a dismisura
la quantità di spam uscente sempre da quel server, cambiando il rapporto
anche in questo caso.


 anche in questo caso.
 
Quotando il testo di una dozzina di post addietro:
 
«
2) che le metodologie di iniezione sono un moving target: le soglie che
fino a un paio d'anni fa venivan superate solo da macchine compromesse
oggi vengono superate anche da server con *account* compromessi. Via
trojan, spear-phishing, bruteforce ecc. E più grosso il server, maggiore
il numero di account compromessi.
»
 
 
Poi alzo bandiera bianca... :-P


 »
 
Maggiore è il server, maggiore è anche il numero di mail legittime,
si presume.
 
Il punto è un altro: non capisco in che modo possa essere affidabile
una blacklist come SC in scoring quando invece in reject non lo è.
 
Alla fine, ti ritroveresti con lo scoring di tutte le mail passanti
per Alice, rendendo di fatto inutile lo scoring stesso. Tanto vale
togliere la BL e non usarla.


 togliere la BL e non usarla.
 
Smetti di chiamarla "blacklist" e usa il termine "reputation provider",
vedrai che le cose tornano meglio ;-)
 
E' semplicemente una sorgente di informazioni che, sommate ad altre...


 E' semplicemente una sorgente di informazioni che, sommate ad altre...
 
No. Perchè te puoi sommare quel che vuoi, ma se il "reputation provider"
spara fuori dati non affidabili (qualunque sia il motivo) ti sfasa
l'intera sommatoria.
 
Se io avessi spamassassin tarato a 10 punti, 8 dei quali provengono
da varie fonti, gli attacco il "reputation provider" ed avrò sempre
i 2 punti extra che mi fan taggare la mail, visto che il reputation
provider identificherà sempre la mail come spam.
 
Pertanto, SC sarebbe inutile sia come scoring sia come reject. Cambia
il modo di utilizzo, ma non il risultato. Se i dati sono inaffadabili
lo restano indipendentemente da dove li andrai ad usare.


 lo restano indipendentemente da dove li andrai ad usare.
 
No. Prima di tutto perchè i dati "inaffidabili" sono altro. I dati (di
SCBL, XBL o PBL) hanno un significato, e l'utilizzo va orchestrato in
funzione di questo.
 
 
Se per una mail...
 
- SC ti dice che sta proveniendo da un server noto per avere un alto
tasso di abusi
 
- XBL ti dice che l'IP di iniezione (quello nell'ultimo received
listato) è noto per ospitare un trojan
 
- gli header contengono "firme" associate a spam (header malconci,
falsificati, noti per essere iniettati da bot, helo di iniezione
sospetti, ecc)
 
- il body contiene "firme" associate a spam (link, template, ecc)
 
 
...le probabilità che la mail non sia spam è pressochè nulla.
 
Questo perchè fintantochè incroci metriche tra loro ortogonali, le
probabilità di FP di ciascuna metrica si moltiplicano, e il prodotto di
termini inferiori ad 1 è sempre inferiore al più piccolo tra i fattori.
 
(il che assume che i ruleset siano scritti in modo adeguato, il che
spesso può non essere...)


 tasso di abusi
 
In caso di SC, SC ti dice che tutti i server Telecom hanno un alto
tasso di abusi, ok, può essere vero, ma ciò rende di fatto inutile
SC a livello Italiano.
 
Perchè se SC ti dice picche per ogni mail uscente da Telecom, tanto
vale staccare SC anche in scoring, altrimenti avresti i tuoi punteggi
sfasati verso l'alto sempre e comunque.


 reject_rhsbl_sender 
dbl.spamhaus.org
=127.0.1.2
 
Cosa vogliono dire quest'ultime uguali all'ip 127.0.1.2?


Le liste usate da postfix sono interrogate utilizzando il protocollo DNS
e forniscono in risposta dei record DNS del tipo richiesto.
In genere si richiedono record A, ma talvolta anche record TXT.
Se una query non è soddisfatta viene restituito un NXDOMAIN, mentre se
l'host o il dominio per cui facciamo l'interrogazione è esistente allora
il record conterrà un valore, in genere un IP della classe 
127.0.0.0/8
.
 
Per esempio supponendo di voler verificare se l'IP 95.245.150.150 (un ip
telecom a caso di Alice smart) è in zen possiamo dare il comando:
 
   root@fuppa:~ # dig +short 
59.173.245.95.zen.spamhaus.org
 
   127.0.0.11
 
Il risultato è un ip 127.0.0.11 che in questo caso sta ad indicare che
quel particolare IP è un ip dinamico non segnalato da un ISP.
 
Se per esempio prendiamo un altro IP a caso tra quelli rigettati dal mio
server di posta, il 46.98.74.182 e reinterroghiamo spamhaus, avremo:
 
   root@fuppa:~ # dig +short 
182.74.98.46.zen.spamhaus.org
 
   127.0.0.4
 
In questo caso il 127.0.0.4 ci comunica che l'ip in questione è in CBL.
(
http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage#200
)
 
L'ip restituito quindi serve a stabilire una certa qualità della
risposta; ci sono per esempio DNSBL che rispondono con il codice dello
stato di appartenenza dell'IP, altre che rispondono con il record TXT
contenente l'indirizzo di posta dell'abusedesk, ecc.ecc.
 
In postfix con quella nozione si dice di rigettare solo le mail per le
quali l'interrogazione con rispettivamente helo, client o sender della
dnsbl 
dbl.spamhaus.org
 restituisce un record A con valore 127.0.1.2 che
in questo caso significa che è un dominio spammoso.
(
http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20DBL#291
)
 
Per vedere altre info carine che si possono avere con le varie BL
disponibili fai un salto su:
http://multirbl.valli.org/lookup/
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left


Esaustivo, ti ringrazio molto.

 (
http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20DBL#291
)
 
Tutto esatto, ma ci sono due ragioni più stringenti, per limitare il
ruleset a quello specifico record A.
 
La prima è che, come visibile dalla tabellina che riporti nel link
sopra, DBL lista anche gran parte dei domini di URL shortener, per i
quali riserva un record A separato (127.0.1.3).
 
Se quindi non limitassi il check allo specifico record sopra riportato,
rigetteresti anche tutte le mail provenienti dai domini degli stessi:
 
enlil:~ skull$ dig +short a 
goo.gl.dbl.spamhaus.org
 
127.0.1.3
 
 
La seconda ragione, invece, ha a che fare con l'affidabilità e la
prevedibilità.
Alcuni operatori di DNS, infatti, decidono ad un certo punto di iniziare
ad effettuare l'hijack degli NXDOMAIN (ovvero delle risoluzioni DNS che
puntano a nomi inesistenti), restituendo all'utente -invece della
risposta nulla- un record che punta ad un loro servizio di ricerca.
 
Il senso (per loro) è monetizzare (con la pubblicità) anche gli errori
dell'utente, ma dal punto di vista di un utente che si appoggi a quei
DNS, significa che a *qualsiasi* query viene fornita una risposta
contenente un record A, anche se la risposta originale era un NXDOMAIN.
Se l'interrogazione in questione era verso una DNSBL, la differenza tra
NXDOMAIN e record A è la differenxa che passa tra "non listato" e
"listato": ergo viene considerata listata qualsiasi cosa.
 
Esempio (passato di qui):
 
http://groups.google.com/group/it.comp.os.linux.sys/browse_frm/thread/b5dedfc3f41a6704
 
 
Altro caso, con diverse ragioni ma simili -ma peggiori- risultati è il
fatto che il c.d. "Great Firewall of China" va a modificare alcune delle
query DNS che gli transitano attraverso, con risultati a volte
imprevedibili. Cosa che ha portato gli operatori di DNSBL a dismettere i
mirror che avevano in Cina, in quanto non potevano garantirne
l'affidabilità:
 
https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/003944.html
 
 
 
In entrambe le situazioni, quindi, limitare le azioni applicate da
postfix (o da spamassassin e/o qualsiasi altra cosa) ai soli record A
che la specifica DNSBL è attesa ritornare, come nell'esempio sopra,
serve a "tenere sotto controllo" l'eventuale insorgenza di problemi come
quelli citati, che hanno -quando avvengono- effetti dirompenti.
 
E' -in linea di massima- una misura consigliabile per chiunque non abbia
il completo controllo dell'infrastruttura che serve le DNSBL.
 
In altre parole: se non si hanno i propri mirror delle DNSBL, ma si
interrogano i mirror pubblici, è opportuno farlo..