Newsgroup: it.comp.os.linux.sys
Titolo: consiglio soluzione anti-spam lato server

Ciao.
volevo un consiglio per una soluzione anti-spam lato server..
Ho un mta su postfix+vm-pop3d+owm e vado di rbl e regex...
non sono molto d'accordo per una soluzione anti-virus +anti-sapm lato server
come in passato Mizio
mi aveva detto ma purtroppo la mia azienda mi sta facendo pressione affinchè
studi una politica di sicurezza lato server.
La loro giustificazione è sta ta quella di dirmi che tutte le aziende oggi
giorno centralizzano policy di sicurezza mail lato server..
e quindi anche noi.....forse potrebbe bastare un mail scanner...
Quale le migliori soluzioni?
Voi che dite?
Mizio ci  6?
Ciao
Giuseppe

 Quale le migliori soluzioni?
Non esiste la "soluzione", esistono vari accorgimenti. L'antivirus io
lo vedo meglio sul client, magari con un sistema di aggiornamento da
server cosi' tutti i client sono sempre aggiornati e vedi chi non ha
l'aggiornamento a posto. Per lo spam la marcatura sul server e' la
sola cosa che puoi fare. E rimvuoere gli allegati.
Davide
-- 
PL/1, "the fatal disease", belongs more to the problem set than to the
solution set.
		-- E. W. Dijkstra

 Quale le migliori soluzioni?
Come detto, prima bisogna definire gli obiettivi.
Per un primo passo, clamav e amavisd-new si inseriscono benissimo
in postfix senza grossi patemi e non costan nulla.
Clamav non becca tutto, ma potrebbe anche essere sufficiente ad un
filtraggio grossolano. Se vuoi buone garanzie, usa anche un buon AV
commerciale che abbia una versione linux ben supportata e veloce
(soprattutto se hai traffico elevato).
I miei due cents...
-- 
cat: .signature: No such file or directory

 Quale le migliori soluzioni?
io uso amavisd-new con spamassassin e clam
ho quasi del tutto eliminato le regexp (tengo solo quelle per bloccare
allegati pericolosi: exe, pif, scr, com, bat, ecc...) di postfix e
faccio un moderato uso 'bloccante' delle rbl con postfix
(vedi un vecchio - ma non poi molto - thread al riguardo e il sito
http://www.securitysage.com/antispam
 )
con alcuni controlli aggiuntivi di spamassassin presi da
http://www.rulesemporium.com/rules.htm
 
direi che spam ne arriva davvero poco ad account che prima ricevevano
15-20 mail di spam al giorno.
(io stesso uso questo account di posta reale per testare le regole, ne
blocca ben piu' di 20 al giorno e non ne passa nemmeno uno)
se puoi metti in piedi un minimale bind locale su cui imposti le zone
slave dei dns su cui si fanno i controlli rbl...
-- 
Ciao, Manuel
Vorrei fare con te quello che la primavera fa con i ciliegi.
		-- Pablo Neruda

 fosco/sottovalutato/problematico, ecc.
Mi spiego meglio volevo dire che un anti virus lato server non mi sembra
adatto perchè
1) penso cha vada  ad assorbire troppe risorse
2) non vorrei che gli utilizzatori trascurano la sicurezza del oro client
solo perchè esiste una soluzione av lato server
Per quanjto riguarda la soluzione anti-spam capisco che non esiste altra
soluzione se non lato server
ma ho paura di generare troppi falsi positivi...
Forse proprio perche penso di non riuscire a configurare correttamente il
filtro....ma è solo una mia insicurezza
L'anno scorso infatti prorpio questo è quello che mi è capitato......fino al
punto che mi sono venuti a dire che è meglio
che la mail vengano recapitate senza troppi controlli anche a costo di
sopportare un pò di spam...
adesso invece il vento è cambiato ricevono troppo spam e vogliono la
soluzione lato server....
Che volete farci?
Ciao
Giuseppe

 ma ho paura di generare troppi falsi positivi...
Questo pericolo e' sempre li', ed infatti il concetto non e' di
_eliminare_ lo spam, ma marcarlo per poterlo distinguere piu'
facilmente.
Davide
-- 
An American's a person who isn't afraid to criticize the President but
is always polite to traffic cops.

 soluzione lato server....
E' anche un effetto del fatto che il rapporto segnale/rumore nelle
comunicazioni via email è in continuo calo.
Attualmente da noi siamo (sul medio termine) attorno al 77 % di traffico
rigettato. Solo un anno fa eravamo nemmeno al 65... e se andiamo indietro
di 4-5 anni a pensarci fa paura...


 facilmente.
Qui in realtà andiamo su due scuole di pensiero drasticamente divergenti.
L'operazione di marking pone il problema della soluzione dei falsi
positivi interamente sul groppone del ricevente.
Quello di reject su smtp lo pone dal lato del mittente sotto forma di
mancato recapito.
Tra le due cose, onestamente, preferisco la seconda. Inutile che ho un
sistema antispam per evitare le rogne all'utente se poi è l'utente che se
lo deve scavusciare per cavarne fuori il segnale residuo...
Poi c'è la questione del carico macchina. Eliminare il rumore *prima* di
doverlo trattare, permette di ridurre sensibilmente il carico a valle del
sistema. Se così non fosse quelle 60000 mail di cui all'altro messaggio
diventerebbero 200.000... e il dimensionamento sarebbe decisamente diverso...


 doverlo trattare
Quando decidi che e' spam lo hai gia' trattato.
Davide
-- 
"The sooner all the animals are dead, the sooner we'll find their
money."
		-- Ed Bluestone, "The National Lampoon"

 Quando decidi che e' spam lo hai gia' trattato.
HUH?
Ricapitoliamo i passetti:
Client -> SERVER SMTP
Il server effettua check sul mittente, sul suo ip, e sui suoi header e
stabilito che è spam risponde
552 Appenditi a 'sto stendardo
E lo manda a fare un giro.
1) non ho fatto alcuna analisi di contenuti (spamassassin succhia risorse
a bomba...)
2) non ho pasato l'antivirus sullo stesso.
Cosa avrei trattato?


 Il server effettua check sul mittente, sul suo ip, e sui suoi header e
No, momento, qui' stiamo parlando di due cose diverse.
Io sto' parlando di trattare lo spam che ricevi, non quelli che mandi.
Ergo, e' SERVER SMTP -> SERVER SMTP, e nella maggior parte dei casi
il check sugli header passa, e' il check sul resto che fallisce.
Davide
-- 
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
		-- Mark Twain

 il check sugli header passa, e' il check sul resto che fallisce.
Non direi:
http://stats.spin.it/cgi-bin/spamstats
okkio alla lineetta grigia su in cima... ovviamente è l'ultima applicata...
Non direi che ferma poco...


 Non direi che ferma poco...
Forse anche troppo... il 72%.
Davide
-- 
The only really decent thing to do behind a person's back is pat it.

 Forse anche troppo... il 72%.
Ehm...il grafico è quello *sotto* :-)
72% è il totale giornaliero (di notte arriva solo spam..)


 
http://stats.spin.it/cgi-bin/spamstats
doh!
che cosa usi per generare questi grafici delle statistiche?
grazie,
a.

 grazie,
E' un mailgraph molto rimaneggiato.
http://people.ee.ethz.ch/~dws/software/mailgraph/



Usa mailgraph, e se magari mi dice anche come mai il mio mailgraph mi 
mette in una unica categoria le mail respinte dalle rbl (ho tolto il 
commento nel codice) e quelle SPAM mi segna 0 mi fa un favore :-)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	Prima di parlare collegare la spina del cervello,
	 leggere e in caso di schermata blu riavviare.

 commento nel codice) e quelle SPAM mi segna 0 mi fa un favore :-)
semplice: mi son rifatto tutto il blocco delle regex sulle ragioni di
reject :-P
Per altro, non rigettiamo con il messaggio generico di postfix, ma con
messaggi personalizzati, per cui dovevo smandrupparmelo lo stesso...
Visto che dovevo farlo, ho direttamente aumentato il numero di tracce
mantenute nel DB rrd, per contenere tutto quello di cui volevo un
dettaglio.
Ne è venuto fuori qualcosa che con mailgraph ha mantenuto giusto qualche
parentela (ovvero il cgi che poi genera il grafico), tanto che è venuto a
gratis anche questo (appena messo in linea, mancano ancora tutti i
commenti alle metodologie di analisi, la pagina-contenitore con le
presentazioni, ecc...)
http://stats.spin.it/cgi-bin/blstats
Bye...
