1 allegato(i)
5.1_ Restrizione dell'accesso ai siti di amministrazione.
Il file iRedMail.tips, riporta gli url dei siti configurati in apache e dai quali è possibile raggiungere la webmail e le altre applicazioni.
Ad eccezione della webmail, nessuno degli altri siti relativi ai vari tool di amministrazione hanno necessità di essere raggiunti dall'esterno. Inoltre, la maggior parte di questi tool sono i più noti strumenti di amministrazione disponibili nel mondo linux e pertanto, analizzando i log dei server pubblicati è frequente vedere dei tentativi di raggiungere le homepage di accesso da parte di scanner e bot di vario tipo.
E' quindi raccomandabile, come riportato anche nel wiki di iRedmail, restringere l'accessibilità di questi siti secondo le specifiche esigenze.
Quote:
Originariamente inviato da iRedMail.tips
Nel mio caso, tutti i siti devono essere raggiungibili solo dalla rete locale, ad eccezione della webmail che deve essere raggiungibile anche da internet.
Dagli url indicati nel file, si vede anche che l'installer ha utilizzato per tutti i siti (e per la generazione del certificato SSL) il nome host che ho scelto di non modificare: Poco male, funziona tutto ma è poco elegante e comporta una segnalazione di errore nel browser quando si accede via SSL ad uno dei siti.
Per correggere queste impostazioni, è necessario intervenire nella configurazione dei siti che si trova in apache. I files e le directory che ci interessano sono principalmente questi:
Apache & PHP:
* Configuration files:
- /etc/apache2
- /etc/apache2/apache2.conf
- /etc/apache2/conf.d/*
- /etc/php5/apache2/php.ini
* Directories:
- /usr/share/apache2
- /var/www
La restrizione di accesso ad un particolare sito/directory si può ottenere sfruttando il modulo di apache "authz_host". Per abilitarlo, è sufficiente lanciare il comando:
codice:
root@server:/etc/apache2# a2enmod authz_host
Enabling module authz_host.
Run '/etc/init.d/apache2 restart' to activate new configuration!
ma io ce lo avevo già abilitato.
La configurazione predefinita di apache prevede la creazione di un sito "default" che risponde a tutte le chiamate http che arrivano al server. I siti diventano due nel caso sia attivato anche il supporto ad SSL. La configurazione di questi siti è contenuta nei file disponibili nella directory "/etc/apache2/sites-available":
codice:
root@server:/etc/apache2# ls /etc/apache2/sites-available
default default-ssl
Il file "default" gestisce il sito che risponde alle chiamate http, il file default-ssl l'equivalente per il protocollo SSL. Ogni applicazione fà riferimento ad una specifica sottodirectory, ciascuna delle quali dotata di un proprio files di configurazione. Per restringere l'accesso a queste directory, è sufficiente modificare una direttiva contenuta nel relativo file di configurazione:
Quote:
Originariamente inviato da /etc/apache2/conf.d/iredadmin.conf
codice HTML:
WSGISocketPrefix /var/run/wsgi
WSGIDaemonProcess iredadmin user=iredadmin threads=15
WSGIProcessGroup iredadmin
AddType text/html .py
<Directory /usr/share/apache2/iredadmin/>
Order allow,deny
Allow from all
</Directory>
In questo file, è sufficiente sostituire la direttiva "Allow from all" con "Allow from 192.168.149.0/255.255.255.0" per specificare le reti da cui consentire l'accesso (ovviamente impostando il valore appropriato) separate da spazi. In alternativa, è possibile specificare singoli indirizzi IP o anche nomi host o specifici domini.
Nel caso venga tentato l'acceso da una rete/host non autorizzato, apache dovrebbe restituire questo risultato:
Ripetere uguale per i files "/etc/apache2/conf.d/awstats.conf" ed "/etc/apache2/conf.d/phpldapadmin".
Per "/etc/apache2/conf.d/phpmyadmin.conf" la procedura è leggermente diversa perchè è necessario aggiungere anche l'opzione "Order allow,deny", dato che di default non è presente.
In ultimo, ridurre al minimo indispensabile gli alias configurati nel file "default" e "default-ssl" può aiutare a ridurre la "superficie d'attacco" al server, che male non fà mai.
6.1_ Filtri antispam: SPF Check.
Ho accennato in precedenza alla creazione di un record SPF per il mio mailserver.
Di default, però, il plugin per il controllo del record SPF non è installato ne abilitato in postfix quindi io fornisco questa informazione agli altri server ma non ne faccio uso per verificare il mio traffico in ingresso. Il wiki di iRedMail fornisce le istruzioni per abilitare questo controllo in Postfix quindi ne approfitto e lo installo anche sul mio server (pagina ufficiale del progetto).
Come prima cosa, è necessario installare il plugin che effettua il controllo. Su Debian, si trova già pacchettizzato nei repository quindi per installarlo con le relative dipendenze è sufficiente lanciare il comando:
codice:
root@server:/home/matteo# apt-get install postfix-policyd-spf-python python-dns python-spf
Non è una versione "recentissima" (0.8.0-2) ed in "testing" è disponibile anche la 1.0x che richiede però un aggiornamento di python quindi per ora va bene così (Qui è eventualmente possibile reperire i .deb).
Il file di configurazione si trova nel percorso "/etc/postfix-policyd-spf-python/policyd-spf.conf" e si presenta così:
Quote:
Originariamente inviato da /etc/postfix-policyd-spf-python/policyd-spf.conf
# For a fully commented sample config file see policyd-spf.conf.commented
debugLevel = 1
defaultSeedOnly = 1
HELO_reject = SPF_Not_Pass
Mail_From_reject = Fail
PermError_reject = False
TempError_Defer = False
skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0//104,::1//128
Il modulo supporta anche diversi livelli di whitelist, le istruzioni di configurazione complete sono reperibili nella manpage con il comando "man 5 policyd-spf.conf". Altre utili informazioni per la gestione del whitelisting su postfix si possono trovare qui.
La configurazione di default è funzionante, per abilitarla è però necessario aggiungere un paio di istruzioni in postfix, seguendo le istruzioni del wiki o anche del link precedente:
- Editare il file "/etc/postfix/master.cf" ed aggiungere in fondo le seguenti istruzioni:
codice:
# SPF check
spfpolicy unix - n n - - spawn
user=nobody argv=/usr/bin/python /usr/bin/policyd-spf
- Editare il file "/etc/postfix/main.cf" ed aggiungere alla riga "smtpd_recipient_restrictions" la policy: "check_policy_service unix:private/spfpolicy" in una posizione adeguata (le istruzioni vengono eseguite in sequenza). La mia policy ora si presenta così:
codice:
smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unlisted_recipient, check_policy_service unix:private/spfpolicy, check_policy_service inet:127.0.0.1:7777, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_recipient_access, hash:/etc/postfix/accept_special, check_policy_service inet:127.0.0.1:10031
- Riavviare postfix.
[EDIT del 05∕02∕2013]
Mi è venuta la necessità di utilizzare il mio server di posta elettronica con un normale client anche dall'esterno della mia rete locale. Andando a configurare l'account mi sono reso conto che non potevo spedire messaggi in uscita. Il server mi rispondeva sempre così:
Quote:
Si è verificato un errore durante l'invio della posta. Il server di posta ha risposto: 5.7.1
: Recipient address rejected: Message rejected due to: SPF fail - not authorized. Please see SPF: Why. Controllare il destinatario del messaggio mia-email@fracassetti.it e riprovare.
In pratica, il plugin SPF rifiutava le mie stesse email perchè il client configurato, tentando una connessione SMTP al mio server per spedire la mail, si presentava con un IP diverso da quello indicato nel record SPF.
Come accennato in precedenza, la posizione in cui vengono inserite le istruzioni in postfix è fondamentale: Per risolvere il problema ho dovuto modificare l'istruzione precedente in modo che il controllo SPF sulle email in ingresso avvenisse dopo l'istruzione "permit_sasl_authenticated".
codice:
smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unlisted_recipient, check_policy_service inet:127.0.0.1:7777, permit_mynetworks, permit_sasl_authenticated, check_policy_service unix:private/spfpolicy, reject_unauth_destination, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_recipient_access hash:/etc/postfix/accept_special, check_policy_service inet:127.0.0.1:10031
In questo modo, le mail in ingresso vengono comunque verificate dal plugin SPF ma solo se la mail non arriva da un mittente autenticato. L'alternativa sarebbe quella di modificare il record SPF per risultare più permissivo ma, a mio parere, questa scelta ne annullerebbe l'efficacia.
6.2_ Filtri antispam: Greylisting.
Il Greylisting è uno strumento nella lotta allo spam tanto semplice quanto geniale.
Si basa e sfrutta il fatto che un mail server attendibile ha come scopo principale quello di garantire che il traffico email che gli viene affidato arrivi correttamente a destinazione mentre un mass-mailer per la generazione di spam ha interesse a raggiungere il maggior numero di utenti nel più breve tempo possibile: Mentre un mail server "vero" impiega le proprie risorse di banda e cpu per far si che tutti i messaggi vengano recapitati ai destinatari, a costo di provarci più volte, uno spammer ha come priorità che il messaggio raggiunga il più ampio numero possibile di destinatari, a costo di perderne qualcuno per strada.
Un server "vero" con greylisting abilitato, quindi, come prima cosa respinge al mittente ogni messaggio in ingresso, generalmente con un codice di errore che indica un rifiuto temporaneo (4XX), ad esempio:
codice:
Aug 28 21:06:55 server postfix/smtpd[20553]: NOQUEUE: reject: RCPT from smtp.mssupport.microsoft.com[131.107.1.37]: 450 4.7.1 : Recipient address rejected: Policy Rejection- Please try later.; from= to= proto=ESMTP helo=
- Se l'originatore del messaggio è un server "vero" (configurato decentemente) sicuramente, vedendosi rifiutare un messaggio, riproverà altre volte a recapitarlo. Tipicamente un server di posta tiene un messaggio in coda fino ad un paio di giorni (dipende dalle scelte dell'amministratore) per evitare che temporanei problemi di connettività o disservizi tecnici possano impedire il recapito di un messaggio.
- Se l'originatore del messaggio è uno spammer, tipicamente il messaggio respinto si perde nel nulla perchè il server mittente non ha, appunto, come priorità il recapito di ogni messaggio ma il recapito al maggior numero possibile di destinatari.
Il sistema greylisting si basa sulla generazione di una "tripletta" e cioè sulla registrazione in una base dati di 3 informazioni per ogni messaggio di posta in arrivo: Un riferimento del server emittente (tipicamente l'indirizzo ip), l'indirizzo e-mail del mittente e l'indirizzo e-mail del destinatario.
Queste informazioni vengono memorizzate dal server ricevente che incrementa un contatore nel caso arrivi un'altra mail con la medesima tripletta: Probabilmente, il server originario stà tentando nuovamente di consegnare il messaggio ma anche questa volta il messaggio potrebbe essere rifiutato. Il mittente, tipicamente, rimette il messaggio in coda e proverà a recapitarlo di nuovo dopo un intervallo di tempo di più lungo, magari dopo 15', 1h, 4h e 1giorno prima di rinunciare definitivamente e restituire al mittente un avviso di mancato recapito.
Dopo un numero di rimbalzi stabiliti dall'amministratore del server che riceve, la tripletta verrà considerata attendibile ed il messaggio, se supera gli altri controlli configurati, verrà preso in carico dal server ricevente per essere consegnato al destinatario. Inoltre, per un tempo stabilito, la tripletta verrà memorizzata e considerata attendibile in modo da non dover ripetere tutta la procedura di validazione per combinazioni risultate "trusted". La maggior efficacia di questo filtro si ottiene, ovviamente, con un tempo di validazione della tripletta piuttosto lungo ma questo ha il contro di ritardare la ricezione della mail da parte dei legittimi destinatari e la cosa non è generalmente ben accettata dagli utenti.
Ovviamente questo metodo, efficacissimo appena introdotto (poteva bloccare, da solo, oltre il 90% dello spam in arrivo), ha progressivamente perso efficacia: Gli spammers si sono fatti furbi ed hanno iniziato ad implementare per le loro spedizioni delle code o dei server smtp comuni.
Rimane ancora piuttosto efficace, soprattutto se usato in combinazione con gli altri filtri normalmente presenti su un server di posta. Inoltre richiede pochissime risorse se confrontato con i tradizionali sistemi di scan dei messaggi quindi costituisce ancora una delle prime linee più utili per "sgrossare" la quantità di spam da verificare con gli altri filtri.
iRedMail lo prevede installato e configurato di default: L'attivazione/disattivazione "server-wide" del filtro si fà direttamente dal file di configurazione del demone "policyd", editando il file "/etc/policyd.conf" ed impostando il valore "GREYLISTING" a "0" per disattivare il servizio ed a "1" per attivarlo, riavviando il demone per applicare le modifiche. Nello stesso file si trovano anche diverse opzioni per il tuning di questo servizio.
La versione "Pro" di iRedMail permette di abilitare/disabilitare il greylisting anche per singolo dominio o per singolo utente, tramite un comodo menù.
Riferimenti:
- greylisting.org.
- Wikipedia: Greylisting.
- iRedMail, attivazione/disattivazione del greylisting.
- Greylist e SPF con Exim e Postfix
7.1_ Creazione di una lista di distribuzione.
Non stò a parlare della configurazione dei singoli utenti di ciascun dominio: La versione free di iredadmin è relativamente limitata in quanto ad opzioni e funzionalità raggiungibili dall'interfaccia e la creazione di un nuovo utente è estremamente semplice.
Le versioni free di iredadmin, contrariamente alle controparti a pagamento, non dispone però di un'interfaccia per la configurazione di liste di distribuzione: E' comunque possibile procedere manualmente, seguendo le procedure documentate sul wiki di iredmail.
La procedura cambia in base allo specifico backend che si è scelto di utilizzare e non è comodissima. Però per un singolo dominio è comunque accettabile mentre, se i domini e gli indirizzi da gestire aumentano, è una di quelle funzionalità che giustificano il passaggio alla versione a pagamento.
Io ho installato la versione con backend LDAP e la documentazione ufficiale per questa procedura è reperibile qui.
La creazione di una lista di distribuzione si divide in due parti: consiste nella creazione di un oggetto nella struttura LDAP del dominio interessato e nella successiva aggiunta di ogni membro a questa lista. In assenza di iRedAdmin Pro, lo sviluppatore ha previsto l'installazione durante il setup di un noto tool per la gestione di queste strutture di dati da un'interfaccia web. Il tool si chiama phpLDAPAdmin, è un progetto opensource e, salvo modifiche post-installazione, è raggiungibile agli url "https://ip_del_server/phpldapadmin/" o "https://ip_del_server/ldap/" e per ottenere l'accesso amministrativo è necessario utilizzare la password del manager LDAP fornita in fase di installazione.
Un riepilogo di queste informazioni è comunque disponibile nel file "iRedMail.tips" generato dal tool di installazione di iRedMail.
L'interfaccia del tool mostra, sulla sinistra, il tree che costituisce la radice della directory, avente come root il domain indicato in fase di installazione per la struttura LDAP. All'interno del tree si trovano diversi oggetti tra cui l'oggetto "o=domains" che contiene tutti i domini virtuali che il server gestisce mentre sulla destra si trovano il dettaglio degli oggetti selezionati e i campi modificabili.
Come prima cosa, all'interno del tree "o=domains" individuare il dominio all'interno del quale si vuole creare la lista di distribuzione e selezionare il tree "o=Groups". Sulla destra, selezionare poi "Create a child entry" creare un nuovo oggetto all'interno di questo tree.
La guida sul sito ufficiale propone poi di selezionare il template "default" e successivamente "mailList" nel menù "ObjectClasses": Il template non l'ho trovato, mi risulta già selezionato come si può vedere dalle indicazioni riportate nel top del questo frame, probabilmente la guida si riferisce ad una versione più vecchia. Nella seconda ed ultima fase di questa procedura c'è da selezionare "mail" nel menù a tendina e compilare i sottostanti campi necessari.
Le informazioni di inserire, opportunamente ripartite nei relativi campi, sono: l'indirizzo email della lista di distribuzione ("Email"), i permessi di accesso a questa lista (una policy che definisce chi è autorizzato a scrivere alla lista di distribuzione), lo stato della lista (attivata/disattivata, "accountStatus"), un nome semplice per la visualizzazione ("cn" o Common Name) con un testo descrittivo (Description) ed i servizi per cui questo oggetto è autorizzato.
Le accessPolicy sono predefinite disponibili sono "public", "domain", "subdomain", "membersOnly", "moderatorsOnly", "memebersAndModeratorsOnly": sono gestite e documentate con un tool apposito, sempre facente parte di iRedMail. L'uso di queste policy è molto utile per ridurre la solita valanga di spam in ingresso, restringendo l'accesso solo agli utenti che ne hanno effettivo bisogno.
Un altro attributo su cui è necessaria una specifica sono gli "enabledService": La guida riporta per questo attributo 3 valori da inserire ma mi risulta che il tool permetta in realtà l'inserimento di un solo valore alla volta... Conviene quindi inserirne solo uno, aggiungendo i successivi solo in un secondo momento. La procedura mostrata nello screenshoot non mi risulta funzionante.
Inserite le informazioni si può cliccare sul pulsante "Create Object" e, verificata la correttezza, procedere con la creazione dell'oggetto. Una volta creato, può essere modificato per aggiungere i valori mancanti all'attributo "enabledService":
7.2_ Aggiunta di un utente "interno" alla lista di distribuzione.
La lista appena creata esiste ora come oggetto LDAP ma non è popolata: In assenza di membri assegnati, postfix tratterà la lista come un utente inesistente, restituendo nei log del server di posta il seguente errore:
codice:
Recipient address rejected: User unknown in virtual mailbox table;
L'appartenenza alla lista è gestita come attributo del singolo utente: Non è quindi possibile modificare aggiungere in un colpo solo tutti gli utenti (a meno, ad esempio, di modificare il template per i nuovi utenti, per rendere questo attributo parte degli attributi predefiniti del nuovo utente) ed è necessario agire aggiungendo un utente alla volta.
Espandendo il tree "ou=Users", sempre sotto il tree del dominio in cui stiamo creando la lista, è possibile individuare l'account che si vuole aggiungere e selezionarlo:
Se è la prima volta che l'utente viene aggiunto ad una lista, l'attributo "memberOfGroup" non sarà disponibile e dovrà essere aggiunto tramite la funzione "Add new attribute -> memberOfGroup" e valorizzando il campo compilabile con l'indirizzo email della lista, selezionando "Update Object" per salvare le modifiche. In caso contrario, sarà sufficiente aggiungere un valore all'attributo esistente, similmente a come fatto in precedenza per l'attributo "enabledService". Non ci sono particolare limitazioni al numero di liste a cui può essere aggiunto l'utente.
Dalla rubrica della webmail, se è stato precedentemente attribuito il valore "displayedInGlobalAddressBook" all'attributo "enabledService" della lista di distribuzione, è ora possibile verificare se il nuovo oggetto compare nell'elenco degli indirizzi disponibili nell'elenco indirizzi globale e se il funzionamento è quello atteso:
2 allegato(i)
7.3_ Aggiunta di un utente "esterno" al dominio alla lista di distribuzione.
La procedura precedente permette di gestire solo contatti email registrati all'interno del dominio specifico. Creare una lista che permetta di inoltrare messaggi ad indirizzi non appartenenti al dominio gestito dal server non è problematico ma segue una procedura leggermente diversa: La lista in sè è identica ma è necessario creare un oggetto "contatto email" nell'apposito tree "Externals" ed aggiungervi l'attributo "memberOfGroup", similmente a quanto visto in precedenza.
A queste liste, è possibile applicare gli stessi attirbuti e gli stessi valori visti in precedenza, sia per quanto riguarda le policy di accesso che per gli enabled services.
La procedura che cambia leggermente è la creazione del contatto email, che si fà espandendo il tree "Externals" e selezionando la tipologia "mailExternalUser".
Per aggiungere alla lista un utente interno già esistente, è sufficiente aprirne il profilo e aggiungere un "Value" all'attributo "memberOfGroup" dell'utente.