Newsgroup: it.news.net-abuse
Titolo: razor pyzor dcc

Salve a tutti,
volevo sapere la vostra opinione sui servizi antiphishing in oggetto
o altri equivalenti?
Funzionano? Hanno controindicazioni?
Sto facendo una qualche esperimento ed effettivamente mi
stanno tagliando tutto il phishing. Non vorrei però generassero
anche falsi positivi... insomma ne ne pensate?
-- 
Gerolamo 

 Funzionano? Hanno controindicazioni?
Rapporto risorse/risultati eccessivamente elevato, IMHO, e non di poco.

"Skull" ha scritto

Uh? ma intendi risorse-macchina (banda / cpu / ram) o risorse umane 
(continui tuning / gestione delle eccezioni / ...) ?
-- 
Gerolamo

 Uh? ma intendi risorse-macchina (banda / cpu / ram) o risorse umane 
Le prime.
Se uno ha quelle risorse da poter utilizzare, ci son oggetti altri 
approcci che, a parità di "consumi" garantiscono risultati migliori e 
decisamente "più flessibili".
Per parafrasare: se hai risorse macchina da buttare e gestisci poco 
traffico, male non fa e dubito avrai grossi problemi da FP. Se invece 
devi gestire discrete moli di traffico e devi star attento all'uso che 
fai dei sistemi, ti suggerirei vivamente di rivolgere l'attenzione ad 
approcci più efficaci e flessibili...

 l'attenzione ad approcci più efficaci e flessibili...
Beh... la domanda mi viene istintiva: ad esempio quali?
-- 
Gerolamo 

 Beh... la domanda mi viene istintiva: ad esempio quali?
Se già non lo fai, ad URI inspection. Parlando di phishing, ad esempio, 
un blocco "secco" delle mail contenenti URL listate da 
ph.surbl.org
 ha 
falsi positivi prossimi allo zero[1], e consente un utilizzo applicabile 
a N altre casistiche oltre.
Per estendere un po' il concetto, spostandolo sui "massimi sistemi", 
posso dire che IMHO la scelta degli strumenti deve mirare alla selezione 
di oggetti che permettano di stabilire un "collegamento" -dotato di un 
buon livello di confidenza- tra la singola mail e l'entità "malevola" 
che la manda e/o ha interesse a farla mandare, sia esso phisher o spammer.
Il fatto che la mail linki il sito rappresenta un collegamento di questo 
tipo, piuttosto forte. Il fatto che la mail arrivi da un server 
notoriamente abusato o in proprietà di spammer anche.
Il fatto che la mail invece abbia un determinato checksum, invece, è in 
pratica autoreferenziale alla mail stessa: altra mail che punti allo 
stesso phish non verrebbe "riconosciuta" e richiede che tutto il 
maccanismo riparta da capo...
E' proprio l'approccio sul quale questi meccanismi son pensati, IMHO, ad 
esser pensato male.
[1] con alcuni limiti dovuti all'implementazione con la quale le varie 
URIBL son pensate, ad essere sinceri. A riscrivere adesso da zero 
l'implementazione si potrebbero ottenere risultati molto migliori...

 IMHO, ad esser pensato male.
Beh... posto che sono in linea di massima d'accordo con te,
sicuramente non va bene se lo metti in cima ai controlli
che fai alla mail.
Ma secondo lo stesso principio, anche una scansione antivirus
sarebbe pensata male...
Diciamo che il valore aggiunto, mettendolo in fondo alla catena
dei filtri, potrebbe comunque darlo senza impattare
eccessivamente sui sistemi. Ma la mia è una impressione non
comprovata, per ora.
Ti ringrazio nuovamente per le dritte.
-- 
Gerolamo 

 o altri equivalenti?
Noi li usiamo all'interno della configurazione "del GARR" di
spamassassin (quindi antispam non solo antiphishing e ci troviamo bene).
Non e' facile dire quanto pesino ... nei primi tempi quando ci guardavo
non mi sembrava venissero usati molto spesso, ma se guardo adesso alla
statistica cumulativa di un paio d'anni vedo che le regole di
spamassassin triggerate in ordine decrescente di occorrenza sono
BAYES_99                376815
HTML_MESSAGE            325237
RAZOR2_CHECK            287931
RAZOR2_CF_RANGE_51_100  286511  ***
DCC_CHECK               220303  ***
DIGEST_MULTIPLE         189281
URIBL_JP_SURBL          186200  * CITATO
RCVD_IN_XBL             179757
RCVD_IN_BL_SPAMCOP_NET  168801
RCVD_IN_SORBS_DUL       148862
URIBL_SC_SURBL          144123  * CIT
URIBL_OB_SURBL          139819  * CIT
URIBL_SBL               124569  * CIT
RCVD_IN_NJABL_DUL       114742
FORGED_RCVD_HELO        109956
URIBL_WS_SURBL          101322  * CIT
MIME_HTML_ONLY          95006
URIBL_AB_SURBL          88325   * CIT
MIME_HTML_ONLY          95006
URIBL_AB_SURBL          88325   * CIT
EXTRA_MPART_TYPE        83177
PYZOR_CHECK             60722   ***
HELO_DYNAMIC_IPADDR     52828
btw noi siamo un dominio accademico, con un traffico di 1000-2000
messaggi al giorno di cui ca. 80% spam.
-- 
----------------------------------------------------------------------
nos...@mi.iasf.cnr.it
 is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

 messaggi al giorno di cui ca. 80% spam.
Io sono stabilmente oltre il 90%, con indirizzi per la
maggior parte aziendali.
-- 
Gerolamo 

 sarebbe pensata male...
Cambia l'entità delle risorse utilizzate, indubbiamente, ma non poi di 
molto: si tratta comunque di approcci che agiscono sul body...
Proprio in quanto tali, vengono chiamati in causa solamente dopo che il 
filtraggio a livello envelope (if any) ha già svolto la sua "scrematura".
Se quest'ultimo ha agito nella maniera più opportuna, hai già levato un 
90% circa di traffico entrante. Il restante 10% sarà composto più o meno 
da un 2% di spam e da tutto il resto di mail lecite.
Se anche un 1.8% viene fermato da altri controlli a livello di 
contenuto, ciò non toglie che razor/whatever si trova a maneggiare 
comunque un 8.2% del traffico complessivo, che lo riconosca come spam o 
meno...
E, a seconda di quanta "prestanza" puoi sacrificare, potrebbe non 
valerne la candela.
Poi, oh, son le mie opinioni e in alcuni dettagli posso essere un po' 
talebano.

 sarebbe pensata male...
Ni. ;-)
Ovvero: sì, in qualche misura è pensata male.
Dimostrazione ne sia il fatto che da me la scansione AV avviene al 
termine di tutti gli altri filtraggi, e il numero medio di messaggi 
beccati dall'AV si attesta tra i 20 e i 50 al giorno (a fronte di 2-2,5 
Mmsg/die). Non perchè io riceva solo quelli, ma perchè il filtraggio già 
eseguito sulla base di altre metriche li sega da solo quasi tutti...
Dopodichè, nonostante ciò, quello è un controllo che val la pena di 
eseguire comunque, banalmente per una questione di costi/benefici: i 
problemi potenzialmente dati da un virus che passa *non* sono gli stessi 
di uno spam che passa, di norma.

 ad esempio [...]
beh... son contento: è esattamente quello che faccio! :)
-- 
Gerolamo 

 o c'č qualcosa che mi sfugge ?
Si, ti sfugge a cosa serve il multithreading, quali vantaggi fornisce e in
quali ambiti e quali sono gli svantaggi.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 la mollo qui perchè ho idea che siamo OT
Sicuramente siamo OT ma per farla breve:
- perl non è molto friendly con i thread
- i thread (al limite) possono dare un vantaggio quando devi avere processi
concorrenti che appunto concorrono allo stesso scopo. Ogni analisi di SA
non è necessario che interagisca con le altre, fatta esclusione dello share
di alcuni dati che vengono comunque cacheati
- per quanto riguarda l'ottimizzazione della velocità con i thread, non
avresti grandi benefici perchè i child di SA sono pre-forkati. L'overhead
del fork rispetto ai thread è propri soprattutto in fase di lancio del
child.
- per quanto riguarda l'ottimizzazione della memoria, con i thread forse
potresti aver ragione. In C è una cosa, in perl un'altra. Imho sarebbe
comunque un casino da gestire.
Fondamentalmente a mio avviso SA risente di problemi alla base: è nato
tanto tempo fa, si è evoluto molto ma architetturalmente parlando è nato
limitato.


di uno spam che passa, di norma.
Mah, ho dei seri dubbi su questo. I clienti devono *comunque* avere un
antivirus (defense in depth!) quindi in un mondo sensato l'unico scopo
di un antivirus su un mail server sarebbe evitare che si riempano le
mailbox quando ci sono infezioni diffuse che generano tantissimo
traffico. Ma questo ormai non succede più, visto che la posta non è più
un buon vettore di infezione.
Ritengo che le risorse necessarie a clamav siano ben superiori ai suoi
reali benefici.
-- 
ciao, |
Marco |  The Italian Usenet Cabal, Abuse Department (TINC)
"It's about damn time that all of us who actually give a damn about Usenet
stand up and tell the people who don't to fuck off and die." -- Russ Allbery