relay Archive

Questa parte funge da approfondimento, propongo un tweak per aumentare la sicurezza e le prestazioni del nostro MTA...

Una volta messo in piedi il nostro servizio di relay di posta, dobbiamo farci la croce e prepararci a quando verremo letteralmente invasi dallo spam.

Circa un buon 60-70% del volume di spam in entrata verrà filtrato con successo da spamassassin, ma non è abbastanza soprattutto su server con alti picchi di traffico.

Ed è soprattutto a questa tipologia di server che servirà questo tutorial, chi "bazzica" infatti da tempo nell'ambiente sistemistico linux, sa bene come spamassassin non è un assassino solo per lo spam, ma anche per la cpu quando il traffico inutile diviene importante.

E' necessario quindi effettuare ulteriori controlli, per arrivare addirittura al punto in cui lo spam non riesce nemmeno ad entrare nel server, vediamo come:

FQDN Check e RBL:

Il primo passo sta nell'applicare alcune policy, di modo che postfix in fase di connessione faccia alcuni check, qualora uno di questi non andasse a buon fine la mail verrà rifiutata; editiamo quindi /etc/postfix/main.cf

### Checks to remove badly formed email smtpd_helo_required = yes strict_rfc821_envelopes = yes disable_vrfy_command = yes unknown_address_reject_code = 554 unknown_hostname_reject_code = 554 unknown_client_reject_code = 554 smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, regexp:/etc/postfix/helo.regexp, permit ### When changing sender_checks, this file must be regenerated using postmap , to generate a Berkeley DB smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/helo_client_exceptions check_sender_access hash:/etc/postfix/sender_checks, reject_invalid_hostname, ### Can cause issues with Auth SMTP, so be weary! reject_non_fqdn_hostname, ################################## reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination, # Add RBL exceptions here, when changing rbl_client_exceptions, this #file must be regenerated using postmap , to generate a #Berkeley DB check_client_access hash:/etc/postfix/rbl_client_exceptions, reject_rbl_client cbl.abuseat.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rhsbl_sender dsn.rfc-ignorant.org, check_policy_service inet:127.0.0.1:60000 permit

con queste direttive forniamo prima di tutto una lista di blacklist dalle quali postfix può controllare se l'ip di provenienza è già segnalato come ip di spam, ed inoltre alcune policy di errore definitivo (554), per determinati eventi.Se eventualmente vogliamo estendere la lista di rbl possiamo reperire altri link qui.Adesso dobbiamo creare il file /etc/postfix/helo.regexp ed inserirci queste stringhe:

/^subdomain\.host\.com$/ 550 Don't use my own hostname /^xxx\.yyy\.zzz\.xxx$/ 550 Don't use my own IP address /^\[xxx\.yyy\.zzz\.xxx\]$/ 550 Don't use my own IP address /^[0-9.]+$/ 550 Your software is not RFC 2821 compliant /^[0-9]+(\.[0-9]+){3}$/ 550 Your software is not RFC 2821 compliant

con questo file riusciamo a bloccare gli spammers che provano a presentarsi con un helo impersonando il nostro stesso server, oppure che inviano traffico che non rispetta l'rfc 2821.Possiamo creare un file di eccezioni, per ip che possono by-passare il check fqdn di cui sopra, creiamo quindi il file /etc/postfix/helo_client_exceptions:

#These client IP addresses are allowed to bypass fqdn checks # Some Comment to identify IP address below #www.xxx.yyy.zzz OK

A volte capita che alcuni server non siano capaci di mandare in maniera corretta il comando di helo, e quindi dobbiamo inserire il loro ip in questa lista per permettergli di fare traffico con noi. ATTENZIONE: ogni qualvolta questo file viene modificato, lo si deve ricaricare in postfix col comando:postmap /etc/postfix/helo_client_exceptionsAdesso creiamo il file /etc/postfix/rbl_client_exceptions:

## Some Random comment #www.xxx.yyy.zzz OK

con questo file creiamo un database di eccezioni di ip dal controllo rbl, anche questo va ricaricato con postmap. Finito questo ricarichiamo postfix e apprestiamoci ad applicare un ultimo meccanismo di antispam (il mio preferito).

Policy di greylisting:

Recentemente è stata introdotta una tecnica di prevenzione antispam, che consente di ridurre il volume di spam di oltre il 90%. Tale tecnica si chiama greylisting e si basa su un concetto molto semplice:Gli spammer non hanno a disposizione cluster di relay di posta, molto spesso fanno uso di script che si collegano direttamente ai server destinatari e mandano migliaia e migliaia di mail ad altrettanti indirizzi, una sola volta, non interessa infatti quante ne giungono a destinazione, interessa solo generare traffico e sovraccaricare i server; e soprattutto non possono star li a riprovare ad ogni email fallita, in quanto sanno bene che molte di quelle sono email non più esistenti magari, il tentativo quindi viene fatto una sola volta.Quando invece viene mandata una mail attraverso un sistema di posta, noi ci colleghiamo all'smtp del nostro fornitore di servizi internet, tale server tiene la nostra mail in coda e tenta di contattare il server di posta destinatario, qualora il tentativo di relay della mail non avesse successo, il server mittente fa in automatico altri tentativi ad intervalli di tempo regolari (3/4 tentativi massimo dipende dalla configurazione), falliti anche questi la mail viene cestinata ed al mittente viene ritornato un messaggio d'errore.Il principio di greylist si basa proprio su questo, inizialmente io rifiuto tutte le mail dando un errore di tipo temporaneo (440), cosi il mittente sa che "ho un problema temporaneo sul server" e quindi dovrà riprovare tra un pò, nel frattempo registro il suo hostname ed il suo ip, come "temporaneamente bannato"; di default questo avviene per un arco massimo di 5 minuti, che sono variabili in base alla conf.Passati i 5 minuti quando il mittente riprova a mandarmi la mail, io alla connect vedo che quell'host con quell'ip è già stato greylistato, quindi non riapplico la policy e lo lascio passare ai successivi controlli antivirus/antispam.Un messaggio di spam quindi viene rigettato sin da prima che esso entri sul server, quando lo script dello spammer mi contatta io inizialmente gli rifiuto tutto, tanto lo script non rifarà un altro tentativo e la mail non entrerà mai sul mio server :D e spamassassin non commette svariati omicidi sulla mia cpu ;)Vediamo quindi come impostare il greylisting su postfix, i repo ci vengono in aiuto:apt-get install postgreypoi editiamo il file /etc/default/postgrey inserendo un parametro alla stringa POSTGREY_OPTS:POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=60"inserendo il parametro --delay infatti abbassiamo il tempo di "ban" che di default è di 5 minuti (che secondo me è troppo) e 60 secondi. Poi riavviamo postgrey:

/etc/init.d/postgrey restart

Adesso dobbiamo dire a postfix di fare ciò che gli dice postgrey prima di qualsiasi operazione, editiamo il file /etc/postfix/main.cf ed aggiungiamo le righe:

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:60000

adesso ricarichiamo la conf in postfix:postfix reloadFinito, ammirate la purezza e la pace che regnano nella vostra casella di posta totalmente priva di spam :DCon questo abbiamo anche concluso la serie di tutorials sulla messa in piedi di un relay di posta. Recapitolando ora abbiamo a disposizione un server smtp, con un efficace sistema antispam ed antivirus, contornato da un completo pannello di controllo per la gestione dei domini e degli amministratori, un servizio di webmail, e la possibilità di far autenticare i nostri utenti via pop ed imap con o senza ssl, cosa volere di più dalla vita? Un Lucano??!! O_o

Full Story