Discussion:
Mail dictionary attack
(too old to reply)
Domenico Viggiani
2007-02-12 10:09:08 UTC
Permalink
Ciao a tutti,
ho notato che sul mio relay (sendmail) esterno passano centinaia di mail
indirizzate ad utenti inesistenti. Sul relay, non effettuo alcuna verifica
sull'indirizzo di destinazione e mi limito ad inoltrare tutti i messaggi al
server Exchange interno, a cui tocca l'onere di rimbalzare tutti i messaggi
indirizzati ad utenti inesistenti (i quali, a loro volta, torneranno
indietro perché i mittenti dello spam non esistono quasi mai).
Questioni:
1) vorrei verificare l'indirizzo di destinazione sul relay esterno, in
maniera da fermare la spazzatura al bordo e liberare Exchange da questo
carico inutile
2) è giusto fare bounce dei messaggi destinati ad utenti inesistenti,
generando un sacco di traffico inutile? Secondo RFC si ma qualcuno mi dice
di dropparli!

Per quanto riguarda il punto 1), stavo provando a verificare gli indirizzi
via LDAP, prima del relay, ma ho dei problemi con gli account locali.
Ho visto anche http://www.snertsoft.com/sendmail/milter-ahead/ ma è a
pagamento.

Idee? Suggerimenti?
--
Domenico Viggiani

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Marco d'Itri
2007-02-12 12:46:23 UTC
Permalink
On Feb 12, Domenico Viggiani <***@tiscali.it> wrote:

> 1) vorrei verificare l'indirizzo di destinazione sul relay esterno, in
> maniera da fermare la spazzatura al bordo e liberare Exchange da questo
> carico inutile
Non so se si può fare con sendmail, ma con postfix è molto facile.
Si può interrogare il database LDAP oppure postfix può "provare" a
consegnare la posta al server destinatario evitando completamente di
accettarla se scopre che l'indirizzo è inesistente (e tenendo una
cache).
Sto implementando una soluzione del secondo tipo per un ambiente in cui
non ho il controllo dei server di destinazione e funziona molto bene.

> 2) è giusto fare bounce dei messaggi destinati ad utenti inesistenti,
> generando un sacco di traffico inutile? Secondo RFC si ma qualcuno mi dice
> di dropparli!
Di cretini è pieno il mondo... :-)
L'unica soluzione corretta è rifiutare questa posta PRIMA che sia
accettata dal tuo mail server, in modo da non dovere generare un
rimbalzo.
Perché buttare via questa posta è una cattiva idea spero che sia ovvio,
il problema di generare rimbalzi come stai facendo ora è che vengono
inviati agli utenti incolpevoli i cui indirizzi sono falsificati dagli
spammer. Generando backscatter in questo modo il tuo server rischia di
finire in molte blacklist.

--
ciao,
Marco
GHERdO
2007-02-12 17:42:58 UTC
Permalink
Marco d'Itri wrote:

On Feb 12, Domenico Viggiani <***@tiscali.it> wrote:

>> 1) vorrei verificare l'indirizzo di destinazione sul relay esterno, in
>> maniera da fermare la spazzatura al bordo e liberare Exchange da questo
>> carico inutile
> Non so se si può fare con sendmail, ma con postfix Ú molto facile.
> Si può interrogare il database LDAP oppure postfix può "provare" a
> consegnare la posta al server destinatario evitando completamente di
> accettarla se scopre che l'indirizzo Ú inesistente (e tenendo una
> cache).
> Sto implementando una soluzione del secondo tipo per un ambiente in cui
> non ho il controllo dei server di destinazione e funziona molto bene.

Interessante. Un link alla documentazione ce l'hai?

--
lore
whiplash
2007-02-14 09:19:40 UTC
Permalink
GHERdO ha scritto:

>> Sto implementando una soluzione del secondo tipo per un ambiente in cui
>> non ho il controllo dei server di destinazione e funziona molto bene.
>
> Interessante. Un link alla documentazione ce l'hai?

Suppongo che Marco possa riferirsi a questo:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html
DrumFire
2007-02-13 15:19:47 UTC
Permalink
GHERdO ha scritto:
> Interessante. Un link alla documentazione ce l'hai?

Probabilmente ti conviene partire da qui:

http://www.postfix.org/SMTPD_POLICY_README.html

Con un policy server attivo riesci facilmente a gestire questo tipo
di controlli.
Giorgio Mura
2007-02-13 15:16:00 UTC
Permalink
Ciao a tutti,

qualcuno di voi ha esperienza positiva su content filter,
possibilmente appliance, che si possa mettere a valle di un router
senza intervenire sul firewall aziendale? Vorrei filtrare soltanto le
connessioni provenienti dal nostro futuro APN dedicato su cui si
concentreranno le connessioni UMTS remote, max 100 connessioni
contemporanee stimate, con una media di 20.
Grazie!
Ciao,

Giorgio
Federico Lombardo
2007-02-14 13:43:57 UTC
Permalink
> Ciao a tutti,

Bau,

> qualcuno di voi ha esperienza positiva su content filter,
> possibilmente appliance, che si possa mettere a valle di un router
> senza intervenire sul firewall aziendale?

Siamo nel 2007, pensare di mettere un fairuoll aziendale che abbia anche
le funzionalità di content filter no eh ?
:-)

> Vorrei filtrare soltanto leconnessioni provenienti dal nostro futuro APN
> dedicato su cui si
> concentreranno le connessioni UMTS remote, max 100 connessioni
> contemporanee stimate, con una media di 20.

Ce ne sono quanti ne vuoi, io mi sono trovato particolarmente bene con
Fortinet, te ne prendi uno di fascia basse ed ha tutto (pure l'auth NTML
in modalità trasparente).

il consiglio che ti do, se l'azienda è piccola, di prendere una soluzione
consolidata che abbia sopra FW, Content Protection e IDS/IPS,

vedi Fortinet, CrossBeam e compagnia cantante, ormai avere un'appliance
per ogni funzione è pleonastico amenochè tu non abbia necessità di
disponibilità del servizio a livello bancario o da infrastruttura critica,
cosa che, spero per te, non sia il tuo caso


:-)

baci & abbracci


Federico


Messaggio subliminale: AAA Cercasi HW per honeynet :-)



________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Giorgio Mura
2007-02-15 13:41:24 UTC
Permalink
At 14.43 14/02/2007, you wrote:
> > qualcuno di voi ha esperienza positiva su content filter,
> > possibilmente appliance, che si possa mettere a valle di un router
> > senza intervenire sul firewall aziendale?
>
>Siamo nel 2007, pensare di mettere un fairuoll aziendale che abbia anche
>le funzionalità di content filter no eh ?
>:-)

Siamo nel 2007, pensare che esistano realtà nelle
quali il Firewall e' appannaggio della casa madre
e che quindi ci siano disperati che non possono fare altrimenti no eh? ;-)

> > Vorrei filtrare soltanto leconnessioni provenienti dal nostro futuro APN
> > dedicato su cui si
> > concentreranno le connessioni UMTS remote, max 100 connessioni
> > contemporanee stimate, con una media di 20.
>
>Ce ne sono quanti ne vuoi, io mi sono trovato particolarmente bene con
>Fortinet, te ne prendi uno di fascia basse ed ha tutto (pure l'auth NTML
>in modalità trasparente).

Buone prestazioni?
Grazie mille, mi informo sui costi allora.

>il consiglio che ti do, se l'azienda è piccola, di prendere una soluzione
>consolidata che abbia sopra FW, Content Protection e IDS/IPS,

Purtroppo per i motivi di cui sopra ho dovuto splittare il tutto.

>vedi Fortinet, CrossBeam e compagnia cantante, ormai avere un'appliance
>per ogni funzione è pleonastico amenochè tu non abbia necessità di
>disponibilità del servizio a livello bancario o da infrastruttura critica,
>cosa che, spero per te, non sia il tuo caso

Purtroppo e' vero anche questo invece, per
fortuna c'e' criticita' solo dalle 8 alle 20.
Mi informo su Fortinet allora, grazie ancora del suggerimento.
Ciao

Giorgio

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Davide Sartori
2007-02-16 07:35:34 UTC
Permalink
>Siamo nel 2007, pensare che esistano realtà nelle
>quali il Firewall e' appannaggio della casa madre
>e che quindi ci siano disperati che non possono fare altrimenti no eh? ;-)

Ciao,
esistono, ma andresti sempre via, come si dice da noi, con una scarpa ed uno
zoccolo!
Se questo e' il problema, cambia anche il firewall con uno che ti permetta
di essere piu' libero!


> > Vorrei filtrare soltanto leconnessioni provenienti dal nostro futuro APN
> > dedicato su cui si
> > concentreranno le connessioni UMTS remote, max 100 connessioni
> > contemporanee stimate, con una media di 20.
>
>Ce ne sono quanti ne vuoi, io mi sono trovato particolarmente bene con
>Fortinet, te ne prendi uno di fascia basse ed ha tutto (pure l'auth NTML
>in modalità trasparente).

Netasq, fascia piccola azienda. C'e' un prodotto consigliato per 50
postazioni (ma non ha nessun limite software). Dovrebbe andare piu' che bene
per la tua realta'.


Davide Sartori
***@sartori2000.com




________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Guido Bolognesi [ Zen ]
2007-02-15 20:16:03 UTC
Permalink
On Wed, Feb 14, 2007 at 02:43:57PM +0100, Federico Lombardo wrote:
> vedi Fortinet, CrossBeam e compagnia cantante, ormai avere un'appliance
> per ogni funzione ? pleonastico amenoch? tu non abbia necessit? di
> disponibilit? del servizio a livello bancario o da infrastruttura critica,

Uhm.
La buzzword ad Infosecurity sembrava fosse UTM.
Tralasciando momentaneamente il fatto che c'erano da tempo apparati
in grado di fornire servizi di "UTM" e che il termine stesso secondo
Wikipedia e` stato coniato nel 2004[1], personalmente preferisco evitare.
Diciamo che parlo dal punto di vista di persona di operations in una
infrastruttura abbastanza grande, ma non credo che se da domani lavorassi
in azienda da 100 persone la penserei diversamente.
Le ragioni sono molteplici, principalmente il fatto che l'insieme
in questo caso non e` mai equivalente alla somma delle parti.

Un device che si trovi a dover fare
- packet filtering
- antivirus smtp
- antivirus http
- IDS/IPS
- controllo della navigazione
posso accettare che per le realta` _veramente piccole_ abbia un costo
minore alla somma tutte queste componenti prese singolarmente.
Ma:
- scala in modo orrendo
E` praticamente impossibile, a fronte della esigenza
di processare un numero maggiore di [pacchetti|mail|pagine]
aumentare la capacita` di una singola funzionalita`.
Bisogna passare all'appliance di potenza superiore, spesso
con costi non lineari (e magari per una sola funzionalita`).
- non e` possibile manutenere separatamente le componenti
Nel momento in cui dovro` aggiornare il motore dell'antivirus
per la posta, ad esempio, questo andra` ad impattare tutte le
funzionalita` (in misura maggiore o minore).
Nell'ipotesi che vada a buon fine e non richieda uno o piu`
riavvii del [motore|firewall].
Sperando sempre che il motore di antivirus che utilizza per
la posta non sia comune con quello che utilizza per le pagine
web, perche` invece che ritardare o bloccare un solo servizio
ne starei bloccando un'altro che, poverino, potrebbe continuare
a funzionare tranquillamente.
- non e` possibile _sostituire_ separatamente le componenti
un bel giorno decido che [cisco|checkpoint|juniper|netscreen
trendmicro|fortinet|...] non sono piu` miei amici, e voglio
cambiare (per mille motivi possibili, inutile che ne parliamo).
O semplicemente non sono sodisfatto di come operano: sono lenti
ad aggiornare le firme [antivirus|id/ps], una mia applicazione
ha problemi con il loro modo di fare packet filtering, chissa`.
Alcune cose sono sostituibili "facilmente", altre no.
- non e` possibile (per quello che so) segmentare l'utilizzo delle risorse
Se e` una giornata particolarmente ricca di virus nella posta
o nelle pagine web, perche` devo impattare anche sulla mia
capacita` di processare i pacchetti o analizzare il traffico?
L'antivirus e` un processo CPU intensive, l'ids abbastanza,
fare da proxy http no.
- non e` "distribuibile"
Posso volere che il proxy per la navigazione stia in parallelo
al firewall esterno. O che gli antivirus della posta stiano
vicini ai server, e solo l'antispam vicino ad Internet: chi l'ha
detto che le mail con i virus arrivano solo da Internet?
O potrei voler avere piu` di un firewall. Come fo?

Tutto questo senza contare la donna delle pulizie di turno[2] che stacca
il cavo di alimentazione del Grande Device e mi manda in crisi tutto invece
che di un [antivirus|smtp|proxy] di cui mi posso occupare domattina.

E` un compromesso che a mio modo di vedere si fa per questione meramente
economica, non certo di prestazioni, manutenzione, praticita`, efficacia;
poi magari nel giro di un anno o due mi dovro` ricredere e ne saro` ben
felice.

Scrivo di rado, ma quando lo faccio sono prolisso, eh? :)

---
[1] http://en.wikipedia.org/wiki/Unified_Threat_Management

[2] ok, ok. Non la donna delle pulizie. Ma qualcuno che lo fa prima
o poi c'e` sicuramente. No, "solo con il badge si entra in
sala macchine" non e` una risposta valida.

ciao,
--
guido . ***@jabber.linux.it . skype://zenmobile
Federico Lombardo
2007-02-17 12:01:53 UTC
Permalink
> Un device che si trovi a dover fare
> posso accettare che per le realta` _veramente piccole_ abbia un costo
> minore alla somma tutte queste componenti prese singolarmente.

Ma nemmeno tanto piccole eh ;-)

> Ma:
> - scala in modo orrendo
> E` praticamente impossibile, a fronte della esigenza
> di processare un numero maggiore di [pacchetti|mail|pagine]
> aumentare la capacita` di una singola funzionalita`.
> Bisogna passare all'appliance di potenza superiore, spesso
> con costi non lineari (e magari per una sola funzionalita`).

E per questo a prescindere che esistono le infrastrutture blade, ma poi
chiunque abbia un minimo di senno nel comprare una cosa del genere fa
degli accordi su dei trade-in.
Quale vendor vuoi che ti rifiuti una richiesta del genere se devi scalare
e quindi comprare piu` roba?

Se ti vai ad analizzare un business case, cmq sei sempre in riduzione di
costo, anche perche` avere un`appliance per ogni funzione non ti toglie
questi problemi di scalabilita` rapportata ai costi.

Poi, occhio, non mischiare problemi di "capacity planning" ed "it
financial management" con il fatto se la tecnologia sia capace o no di
farlo.

Nel caso di fortinet l`antispam e l`url filtering sono "puzzette" che la
macchina non ha minimamente bisogno di computare. il filtering lo fa in
ASIC.

forse posso seguirti sull`AV perimetrale e l`IDS/IPS, ma niente che tu non
possa trovare su apppliances dedicate a fare solo questo!

> - non e` possibile manutenere separatamente le componenti
> Nel momento in cui dovro` aggiornare il motore dell'antivirus
> per la posta, ad esempio, questo andra` ad impattare tutte le
> funzionalita` (in misura maggiore o minore).

Anche qui non hai del tutto ragione o cmq, anche qui rientra su quanto sei
stato bravo a progettare il tuo sistema. In infrastrutture mission
critical, ad esempio, potresti decidere di creare un`appliance virtuale
per ogni funzione, tralsciando il problema di cui sopra.

Ma ogni "manutenzione" che si rispetti, ha un cosidetto "roll-back" veloce
a piacere, quindi anche questa problematica io, sinceramente, non la vedo
cosi` preponderante come un tempo.

> Nell'ipotesi che vada a buon fine e non richieda uno o piu`
> riavvii del [motore|firewall].
> Sperando sempre che il motore di antivirus che utilizza per
> la posta non sia comune con quello che utilizza per le pagine
> web, perche` invece che ritardare o bloccare un solo servizio
> ne starei bloccando un'altro che, poverino, potrebbe continuare
> a funzionare tranquillamente.

Anche qui, e` un problema di progettazione iniziale, questo e` un rischio
che chiunque pone nel suo progetto.
in primis se hai problemi puoi disabilitare il motore in modo che non
impatti sugli altri processi, seconda cosa puoi sempre associare una blade
ad ogni funzione, mantenendo i vantaggi di consolidamento legati allo
chassis e la scalabilita` orizzontale.


> - non e` possibile _sostituire_ separatamente le componenti
> un bel giorno decido che [cisco|checkpoint|juniper|netscreen
> trendmicro|fortinet|...] non sono piu` miei amici, e voglio
> cambiare (per mille motivi possibili, inutile che ne parliamo).
> O semplicemente non sono sodisfatto di come operano: sono lenti
> ad aggiornare le firme [antivirus|id/ps], una mia applicazione
> ha problemi con il loro modo di fare packet filtering, chissa`.
> Alcune cose sono sostituibili "facilmente", altre no.

Bhe`, amico, questa e` una decisione strategica, ma rimane che secondo me
la contrazione dei costi che hai a fronte di un consolidamento del genere,
ti permette di avere ampi margini anche su qesta tematica.
Cmq puoi decidere di rinunciare al consolidamento e far fare a netscreen
solo il firewall ed aggiungere un`appliance che ti fa da antispam. Credimi
anche qui e` un problema di strategia IT, non c`e` nulla che te lo vieti.

> - non e` possibile (per quello che so) segmentare l'utilizzo delle risorse
> Se e` una giornata particolarmente ricca di virus nella posta
> o nelle pagine web, perche` devo impattare anche sulla mia
> capacita` di processare i pacchetti o analizzare il traffico?
> L'antivirus e` un processo CPU intensive, l'ids abbastanza,
> fare da proxy http no.

Puoi farlo, con crossbeam ne sono sicuro, con fortinet devo approfondire.

> - non e` "distribuibile"
> Posso volere che il proxy per la navigazione stia in parallelo
> al firewall esterno. O che gli antivirus della posta stiano
> vicini ai server, e solo l'antispam vicino ad Internet: chi l'ha
> detto che le mail con i virus arrivano solo da Internet?
> O potrei voler avere piu` di un firewall. Come fo?

Puoi creare "n" firewall virtuali ed "n" cacchilli virtuali per ogni cosa
che hai detto.

il problema e` sempre di capacity. Anzi, nel`esempio che hai fatto una
struttura consolidata ti viene proprio incontro.

> Tutto questo senza contare la donna delle pulizie di turno[2] che stacca
> il cavo di alimentazione del Grande Device e mi manda in crisi tutto
> invece
> che di un [antivirus|smtp|proxy] di cui mi posso occupare domattina.

Maddai, su... ora non facciamo fanta-esempi.
prima di tutto ormai esiste il concetto di strutture fault tolerant, anche
per quel che concerne le alimentazioni
Se c`e` anche la sola possibilita` remota che succeda una cosa del genere...
bhe` direi che il tuo problema che hai nel tuo ced e` un altro! ;-)


> E` un compromesso che a mio modo di vedere si fa per questione meramente
> economica, non certo di prestazioni, manutenzione, praticita`, efficacia;
> poi magari nel giro di un anno o due mi dovro` ricredere e ne saro` ben
> felice.

Bhe` fare sicurezza ICT vuol dire mitigare il rischio informatico in modo
"sostenibile" per l`azienda. Altrimenti sono tutti bravi a comprare
fort-knox per proteggere il numero 100 di dilan dog a colori ;-)

Io sono un fautore del consolidameto, se vuoi posso raccontarti delle mie
esperienze positive (grattatio pallorum omnia mala fugat) in ambienti non
precisamente "semplici"

;-)

Federico

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Skull
2007-02-13 15:44:52 UTC
Permalink
GHERdO wrote:

> Interessante. Un link alla documentazione ce l'hai?

Su google, "postfix address verification" -> "I'm Feeling Lucky"

Le stesse funzionalità le ha (da ancor prima di postfix) Exim.
Per altri MTA nin zo.
Marco Gaiarin
2007-05-08 15:02:29 UTC
Permalink
Mandi! Skull
In chel d? si favelave...

S> Le stesse funzionalità le ha (da ancor prima di postfix) Exim.

Segnalo solo questo:

http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html#SECTcallver

perch? come in molte altre cose magari exim non ? l'MTA eccelso, ma ha
il grosso vantaggio di essere molto 'educativo'.

Qui Exim 'conia' i termini callout/callforward/callback e ne da a mio
avviso una spiegazione eccelsa.

--
Vendere no, non passa tra i miei rischi,
non comprate i miei dischi e sputatemi addosso. (F. Guccini)
Marco d'Itri
2007-02-13 15:19:02 UTC
Permalink
On Feb 12, GHERdO <***@freemail.it> wrote:

> > Non so se si può fare con sendmail, ma con postfix è molto facile.
> > Si può interrogare il database LDAP oppure postfix può "provare" a
> > consegnare la posta al server destinatario evitando completamente di
> > accettarla se scopre che l'indirizzo è inesistente (e tenendo una
> > cache).
> > Sto implementando una soluzione del secondo tipo per un ambiente in cui
> > non ho il controllo dei server di destinazione e funziona molto bene.
> Interessante. Un link alla documentazione ce l'hai?
Non c'è molto da dire, questi sono i punti salienti della
configurazione:

smtpd_recipient_restrictions =
...
reject_unverified_recipient
permit_mx_backup
reject_unauth_destination

address_verify_map = btree:${queue_directory}/verify

--
ciao,
Marco
HF
2007-02-13 18:59:19 UTC
Permalink
> consegnare la posta al server destinatario evitando completamente di
> accettarla se scopre che l'indirizzo è inesistente (e tenendo una
> cache).

Parli di questo http://www.postfix.org/ADDRESS_VERIFICATION_README.html?
Il mio dubbio è: il gioco di contattare gli altri server per cercare
di scoprire se il mittente è valido, vale la candela? Considerando
l'alto numero di server che non sono sincronizzati con le basi utenti
e quindi accettano ogni messaggio.
Sarebbe interessante sapere quanto è grande la fetta di questi server.

--
Saluti
Davide Veneziano
http://www.vene.ws
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Skull
2007-02-14 11:17:18 UTC
Permalink
HF wrote:
>> consegnare la posta al server destinatario evitando completamente di
>> accettarla se scopre che l'indirizzo è inesistente (e tenendo una
>> cache).
>
> Parli di questo http://www.postfix.org/ADDRESS_VERIFICATION_README.html?
> Il mio dubbio è: il gioco di contattare gli altri server per cercare
> di scoprire se il mittente è valido, vale la candela? Considerando
> l'alto numero di server che non sono sincronizzati con le basi utenti
> e quindi accettano ogni messaggio.


Qui il discorso era diverso, e si parlava del senso opposto: effettuare
un address_verification sul mailhub per verificare se sulla macchina
destinazione l'utenza esiste.

E' una configurazione assai utile per evitare di generare backscatter
per mailhub che debbano effettuare consegna a server la cui base-dati
utenti non è conoscibile (es: ISP che instrada la posta di tutto il
dominio sul mailserver del cliente).



Ciò detto, il senso inverso qualcuno lo usa.

> Sarebbe interessante sapere quanto è grande la fetta di questi server.

Non troppo, ringraziando il cielo, e comunque è prassi rischiosa: fare
un sacco di tentativi di RCPT TO verso destinatari inesistenti è un
ottimo modo per camuffarsi da dictionary attack, con tutto quello che
questo può scatenare dal lato del server "testato"...
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Michele Orsenigo
2007-02-12 13:37:11 UTC
Permalink
On Monday 12 February 2007 11:09, Domenico Viggiani wrote:
> Ciao a tutti,
> ho notato che sul mio relay (sendmail) esterno passano centinaia di mail
> indirizzate ad utenti inesistenti. Sul relay, non effettuo alcuna verifica
> sull'indirizzo di destinazione e mi limito ad inoltrare tutti i messaggi al
> server Exchange interno, a cui tocca l'onere di rimbalzare tutti i messaggi
> indirizzati ad utenti inesistenti (i quali, a loro volta, torneranno
> indietro perché i mittenti dello spam non esistono quasi mai).
> Questioni:
> 1) vorrei verificare l'indirizzo di destinazione sul relay esterno, in
> maniera da fermare la spazzatura al bordo e liberare Exchange da questo
> carico inutile
> 2) è giusto fare bounce dei messaggi destinati ad utenti inesistenti,
> generando un sacco di traffico inutile? Secondo RFC si ma qualcuno mi dice
> di dropparli!
Se fai la verifica a livello di mail relay non hai questo problema perchè
interrompi la comunicazione immediatamente dopo il RCPT TO con un codice di
errore di tipo 5xx, il che è sufficiente per il server mittente a riportare
la notifica al SUO utente. (e tu non generi alcun traffico !!)

> Per quanto riguarda il punto 1), stavo provando a verificare gli indirizzi
> via LDAP, prima del relay, ma ho dei problemi con gli account locali.
LDAP è una buona scelta, ma sul come non ti so aiutare perchè io uso postfix
come mail relay ....

Ciao
--
Michele Orsenigo
***@4orsi.it
----------------
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Luca Berra
2007-02-13 11:04:35 UTC
Permalink
On Mon, Feb 12, 2007 at 11:09:08AM +0100, Domenico Viggiani wrote:
>Questioni:
>1) vorrei verificare l'indirizzo di destinazione sul relay esterno, in
>maniera da fermare la spazzatura al bordo e liberare Exchange da questo
>carico inutile
Ottima idea

>2) è giusto fare bounce dei messaggi destinati ad utenti inesistenti,
>generando un sacco di traffico inutile? Secondo RFC si ma qualcuno mi dice
>di dropparli!
Droppare la mail e' sempre la scelta sbagliata, immagina solo il caso in
cui una coversazione legittima viene droppata perche il mittente ha
semplicemente sbagliato a scrivere l'indirizzo.

altresi generare bounce per utenti inesistenti e':
- se il mittente del messaggio rimbalzato non esiste (dominio fasullo)
e' molto oneroso sulle risorse dei tuoi sistemi. code lunghissime.
- se il mittente del messaggio rimbalzato e' invece esistente e del
tutto estraneo alla cosa (backscatter mail) diventa molto fastidioso
per il povero malcapitato.

Semplicemente rifiutala con un 5xx alla frontiera. a questo punto sara'
l'smtp mittente a gestirla.

>Per quanto riguarda il punto 1), stavo provando a verificare gli indirizzi
>via LDAP, prima del relay, ma ho dei problemi con gli account locali.
se non dettagli i suddetti problemi difficilmente potrai avere conforto
dalla lista.

>Ho visto anche http://www.snertsoft.com/sendmail/milter-ahead/ ma è a
>pagamento.
>
>Idee? Suggerimenti?
ho abbandonato da tempo sendmail, quindi non sono aggiornatissimo su
quanto si puo' fare con quel coso.
In ogni caso se gli indirizzi sull'exchange non cambiano spesso puoi
utilizzare, a intervalli regolari, uno script con ldapsearch (su unix) o
con cvsde/ldifde su windows per esportare la lista dei destinatari
validi, unirla ad eventuali altre liste sul relay esterno e generare la
tua access map.

L.


--
Luca Berra -- ***@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Alessio L.R. Pennasilico
2007-02-12 15:31:07 UTC
Permalink
On Feb 12, 2007, at 11:09 AM, Domenico Viggiani wrote:

> Ciao a tutti,
> ho notato che sul mio relay (sendmail) esterno passano centinaia di
> mail
> indirizzate ad utenti inesistenti.

se ti consola è successo per diverso tempo da un paio di miei cienti,
dove i tentativi erano nell'ordine di 1 al secondo circa...

> Sul relay, non effettuo alcuna verifica
> sull'indirizzo di destinazione e mi limito ad inoltrare tutti i
> messaggi al
> server Exchange interno, a cui tocca l'onere di rimbalzare tutti i
> messaggi
> indirizzati ad utenti inesistenti (i quali, a loro volta, torneranno
> indietro perché i mittenti dello spam non esistono quasi mai).

uh :( molto male ... come già fatto notare ti tocca gestire un sacco
di traffico inutile oltre all'annoiare un sacco di "utenti
innocenti" (ne esistono? grin)

> Questioni:
> 1) vorrei verificare l'indirizzo di destinazione sul relay esterno, in
> maniera da fermare la spazzatura al bordo e liberare Exchange da
> questo
> carico inutile

di certo la scelta migliore. la stessa che adotto io :) non saprei
come fare con sendmail, ma google sono certo che ti fornirà i coretti
esempi :)

> 2) è giusto fare bounce dei messaggi destinati ad utenti inesistenti,
> generando un sacco di traffico inutile? Secondo RFC si ma qualcuno
> mi dice
> di dropparli!

io di solito tendo ad ascoltare le rfc e non gli amici :)
se rifiuti le mail destinate ad utenti inesistenti prima di
accettarle, demandi il bounce al server mittente. tu non ti
sovraccarichi di lavoro, lo spam-server spesso non "bouncia" mentre i
server veri di qualcuno che erroneamente ha scritto un indirizzo
errato generano il corretto avvertimento.

> Per quanto riguarda il punto 1), stavo provando a verificare gli
> indirizzi
> via LDAP, prima del relay, ma ho dei problemi con gli account locali.
> Ho visto anche http://www.snertsoft.com/sendmail/milter-ahead/ ma è a
> pagamento.

anche io avevo pensato ad ldap, ma sotto forti pressioni non mi va di
generare tante query (carico per il relay, il server ldap e traffico
di rete) e poi devo tenere presente la cache, etc etc etc.

personalmente ho adottato una politica nei casi "pesanti" per cui il
server di posta/il directory server esporta un file di testo con
l'elenco degli utenti, lo spara sul server di relay che ad orari
prestabiliti lo processa e lo trasforma in un "db locale" di utenti
accettati.
necessita un po' di cura la gestione degli errori per l'importazione
del file, ma ho delle macchine che fanno questo da qualche anno senza
perdere un colpo... pro lavora solo il relay molto velocemente,
contro, il delay quando aggiungi/rimuovi utenti.

un mayhem ed i tentativi che possono arrivare su una 16Mb/s ...
--
Let's pick up the pace, make the parties longer, and the skirt shorter.
Let's all go to hell in a fast car and keep it hot!
https://www.mayhem.hk - Key on pgp.mit.edu ID B88FE057
Domenico Viggiani
2007-02-14 11:31:01 UTC
Permalink
> -----Original Message-----
> From: ml-***@sikurezza.org
> [mailto:ml-***@sikurezza.org] On Behalf Of Alessio L.R.
> Pennasilico
>
> anche io avevo pensato ad ldap, ma sotto forti pressioni non
> mi va di generare tante query
> ...
> personalmente ho adottato una politica nei casi "pesanti" per
> cui il server di posta/il directory server esporta un file di
> testo con l'elenco degli utenti, lo spara sul server di relay
> che ad orari prestabiliti lo processa e lo trasforma in un
> "db locale" di utenti accettati.

Ok, ho fatto la stessa scelta.
Uno scriptino recupera da ActiveDirectory tutti gli indirizzi esistenti
tramite 'ldapsearch' e li inserisce in 'virtusertable'. Un'ultima riga con:
@mydomain.it error:5.1.1:"550 User unknown"
e il gioco e' fatto.


Grazie
Mimmo
Daniele Arduini
2007-02-14 23:17:08 UTC
Permalink
Il giorno 14/feb/07, alle ore 12:31, Domenico Viggiani ha scritto:
>> -----Original Message-----
>> From: ml-***@sikurezza.org
>> [mailto:ml-***@sikurezza.org] On Behalf Of Alessio L.R.
>> Pennasilico
>>
>> anche io avevo pensato ad ldap, ma sotto forti pressioni non
>> mi va di generare tante query
>> ...
>> personalmente ho adottato una politica nei casi "pesanti" per
>> cui il server di posta/il directory server esporta un file di
>> testo con l'elenco degli utenti, lo spara sul server di relay
>> che ad orari prestabiliti lo processa e lo trasforma in un
>> "db locale" di utenti accettati.
>
> Ok, ho fatto la stessa scelta.
> Uno scriptino recupera da ActiveDirectory tutti gli indirizzi
> esistenti
> tramite 'ldapsearch' e li inserisce in 'virtusertable'. Un'ultima
> riga con:
> @mydomain.it error:5.1.1:"550 User unknown"
> e il gioco e' fatto.
>

Piuttosto che in virtusertable forse intendevi in relay_recipient_maps?

http://www.postfix.org/postconf.5.html#relay_recipient_maps

Non conosco i numeri in gioco ma personalmente preferisco la tecnica
della verifica del recipient o una replica locale di LDAP.


ciao,
daniele
whiplash
2007-02-15 12:18:28 UTC
Permalink
Daniele Arduini ha scritto:

> Piuttosto che in virtusertable forse intendevi in relay_recipient_maps?

Sta utilizzando sendmail, non postfix...
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List
Domenico Viggiani
2007-02-15 13:04:40 UTC
Permalink
> > Uno scriptino recupera da ActiveDirectory tutti gli indirizzi
> > esistenti tramite 'ldapsearch' e li inserisce in 'virtusertable'.
>
> Piuttosto che in virtusertable forse intendevi in
> relay_recipient_maps?
No, io uso Sendmail e mi riferivo proprio a virtusertable!

> Non conosco i numeri in gioco ma personalmente preferisco la
> tecnica della verifica del recipient o una replica locale di LDAP
Ho circa 450 indirizzi di posta, con 10000 messaggi al giorno tutto
compreso.
Diciamo che con LDAP, non ci sono riuscito ma, a posteriori, penso che sia
meglio cosi'!


Ciao
Domenico
Continue reading on narkive:
Loading...