|
Dimensione: 9037
Commento:
|
← Versione 44 del 16/03/2011 09.09.59 ⇥
Dimensione: 13960
Commento: corretto pagina nome utente causa conversione spazio con underscore
|
| Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
| Linea 1: | Linea 1: |
| In questa pagina inserisco delle prove riguardanti la creazione di nuovi wiki.[[BR]] se aveste dei commenti riguardanti i wiki che sto creando scrivete qui.[[BR]] ||<tablewidth="80%" #FFD700>Firma||<#FFD700 80%>Commento|| || || || [[BR]][[BR]]'''Squid``Guard''' -------- [[BR]] ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">'''Indice'''[[BR]] [[TableOfContents]]|| = SquidGuard = Squid``Guard è un plug-in che permette di controllare i siti che vengono visitati dagli utenti di Squid. Squid``Guard permette di reindirizzare l'utente ad una pagina specifica ogni volta che prova ad accedere ad alcuni domini che sono presente all'interno di una blacklist, una lista contenente i domini da bloccare. Questo plug-in serve, quindi, per filtrare i contenuti che attraversano il server proxy. == Installazione == ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Piccole/warning.png,,center)]] ||<style="padding:0.5em; border:none;">'''Per poter utilizzare questo plug-in bisogna prima aver installato squid, se cosi non fosse, installarlo seguendo questa guida:''' '''[http://wiki.ubuntu-it.org/Server/Proxy ServerProxy]''' || Prima di tutti assicurarsi di poter scaricare file dal repository Universe, se non lo abbiamo ancora attivato seguiamo la guida presente in questo wiki: [http://wiki.ubuntu-it.org/Repository/Ubuntu Repository Ubuntu ] [[BR]] [[BR]] Installazione di Squid``Guard {{{ sudo apt-get install squidguard }}} [[BR]] == Configurazione di Squid == Per poter utilizzare Squid``Guard dobbiamo modificare il file di configurazione di Squid in modo da indicare al programma dove risiede Squid``Guard. [[BR]] Apriamo il file di configurazione {{{ gksudo gedit /etc/squid/squid.conf }}} ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Piccole/note.png,,center)]] ||<style="padding:0.5em; border:none;">''Se volessimo modificare il file dal terminale o stessimo lavorando su di un server a cui siamo collegati, digitiamo'':[[BR]]'''''sudo nano /etc/squid/squid.conf''''' || Aggiungiamo la seguente riga per poter iniziare ad utilizzare Squid``Guard {{{ redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf }}} Adesso impostiamo chi è autorizzato ad eseguire l'accesso al server Proxy. Andiamo nella sezione http_access (si trova circa alla riga 1860) del file di configurazione. Decommentare le seguenti righe: {{{ #acl our_networks src 192.168.1.0/24 192.168.2.0/24 #http_access allow our_networks }}} Avendo modificato queste righe abbiamo abilitato tutti gli utenti della rete LAN, o meglio quelli che hanno un indirizzo IP compreso tra 192.168.1.1 e 192.168.1.255 e tra 192.168.2.1 e 192.168.2.255. == Configurazione di SquidGuard == Questa guida presenta solo una configurazione semplice per quanto riguarda Squid``Guard, per una configurazione più approfondita e dettagliata consiglio di visitare il sito ufficiale di Squid``Guard.[[BR]] Iniziamo a creare i database contenenti i siti che verranno bloccati. {{{ sudo mkdir /var/lib/squidguard/db/weapons/ gksudo gedit /var/lib/squidguard/db/weapons/domains }}} Con il primo comando abbiamo creato una cartella dove posizioneremo il file contenente la lista dei domini che verranno bloccati.[[BR]] Aggiungiamo alla lista i domini e poi salviamo il file. {{{ israeli-weapons.com uws.com glock.com }}} Impostiamo il possessore dei file che abbiamo scritto su ''proxy''. {{{ sudo chown proxy:proxy -R /var/lib/squidguard/db }}} Modifichiamo il file di configurazione di Squid``Guard. {{{ gksudo gedit /etc/squid/squidGuard.conf }}} Eliminiamo tutto dopo la riga: `logdir /var/log/squid`. [[BR]] Sostituiamo il testo eliminato con il seguente: {{{ dest weapons { domainlist weapons/domains } acl { default { pass !weapons redirect http://yourip/block.html } } }}} Digitiamo un altro comando per far diventrare i file scritti dei database leggibili da Squid``Guard. {{{ sudo squidGuard -C all }}} Assicuriamoci che l'utente ''proxy'' sia il possessore dei file {{{ sudo chown proxy:proxy -R /var/lib/squidguard/db }}} Creiamo la pagina .html alla quale verranno reindirizzate gli utenti che avranno tentato di connettersi a dei domini che abbiamo elencato nel file `/var/lib/squidguard/db/weapons/domains` {{{ gksudo gedit /var/www/block.html }}} ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Piccole/note.png,,center)]] ||<style="padding:0.5em; border:none;"> ''La posizione del file è stata è'' '''''/var/www''''' ''perchè solitamente questa è la directory principale del web server Apache. Se usassimo un'altra directory oppure volessimo posizionare il file altrove cambiamo il percorso del file''|| Attiviamo Squid e Squid``Guard {{{ squid -k reconfigure }}} == Risuluzione Problemi == Se all'avvio del server Squid ottenessimo il seguente errore:[[BR]] {{{ FATAL: Could not determine fully qualified hostname }}} Impostiamo il valore del tag ''visible_hostname'' cosi {{{ visible_hostname localhost }}} [[BR]] E' frequente che avvengano degli errori durante queste fasi. Di seguito sono riportate alcuni consigli per poterli risolvere.[[BR]] Prima di tutto cerchiamo quali e quanti processi sono attivi {{{ ps -e | grep squid }}} Il risultato di questo comando dovrebbe mostrare 2 processi di Squid e 5 di Squid``Guard. Se cosi non fosse riavviamo Squid. {{{ squid -k reconfigure }}} Ancora...se non visualizzassimo i 7 processi (2 di Squid e 5 di Squid``Guard) controlliamo il log file. {{{ tail /var/log/squid/squidGuard.log }}} Questo dovrebbe mostrarci quali problemi si sono verificati durante l'avvio del servizio. Nella parte successiva della guida ci viene mostrato come risolvere questi problemi. === SquidGuard, risoluzione problemi === Quando Squid``Guard viene avviato segue questa procedura: 1. Legge il file di configurazione 2. Legge il database o i file di testo contenente la lista dei domini 3. Scrive i log file Se Squid saltasse anche solo una di questi passaggi non partirebbe. [[BR]][[BR]] I seguenti problemi impedirebbero l'esecuzione di uno o più dei passaggi precedenti. * Il file di configurazione non è posizionato nel file specificato in `/etc/squid/squid.conf`. Assicuriamoci che Squid``Guard sia avviato con questa riga nel file di configuazione di Squid {{{ redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf }}} * I file dei database non sono posizionati nella directory specificata in `/etc/squid/squidGuard.conf`. Controlliamo che la seguente sia una delle prime righe nel fiel di configurazione di Squid``Guard. {{{ /var/lib/squidguard/db }}} * Il possessore dei logfile, dei file di configurazione o dei database non è corretto. Questi file dovrebbero appartenere all'utente e al gruppo `proxy` (nel caso stessimo usando Ubuntu), che è definito di default per Squid.[[BR]] Per controllare che questi siano posseduti dall'utente corretto, digitiamo i seguenti comandi {{{ sudo chown proxy:proxy /etc/squid/squidGuard.conf sudo chown -R proxy:proxy /var/lib/squidguard/db sudo chown -R proxy:proxy /var/log/squid/ }}} * I permessi dei file precedenti sono sbagliati, correggiamoli digitando altri comandi {{{ sudo chmod 644 /etc/squid/squidGuard.conf sudo chmod -R 640 /var/lib/squidguard/db sudo chmod -R 644 /var/log/squid/ sudo find /var/lib/squidguard/db -type d -exec chmod 755 \{\} \; -print sudo chmod 755 /var/log/squid }}} * E' presente una parentesi graffa ( { ) mal posizionata nel file `/etc/squid/squidGuard.conf` Errato: {{{ dest weapons { }}} Corretto: {{{ dest weapons { }}} [[BR]] Dopo aver risolto i problemi precedenti riavviamo Squid e Squid``Guard con le nuove impostazioni. {{{ squid -k reconfigure }}} Se avessimo ancora dei problemi avviamo Squid con {{{ squid -NCd1 }}} che avvia il server proxy in modalità verbose che mostrerà qualunque errore, che come sempre riguarderanno i permessi dei file. == Ulteriori risorse == * Documento originale: [wiki:Ubuntu/SquidGuard SquidGuard ] * Homepage di Squid``Guard: [http://www.squidguard.org/ www.squidguard.org] * Elenco di blacklist scaricabili: [http://www.squidguard.org/blacklists.html www.squidguard.org/blacklists.html] [[BR]][[BR]][[BR]] ------- Modifica da aggiungere alla guida del server ftp: (to be continued) |
## page was renamed from Alberto_Giudici/Prove1 ## page was renamed from Alberto Giudici/Prove In questa pagina inserisco delle prove riguardanti la creazione di nuovi wiki.<<BR>> Link utili per la creazione delle pagine:<<BR>> * [[http://wiki.ubuntu-it.org/GuidaWiki/StileDellePagine|StileDellePagine]] * [[http://wiki.ubuntu-it.org/AiutoSuModificaPagina|AiutoSuModificaPagina]] ------ MAIL SERVER <<Indice>> = Introduzione = Questa guida illustra come installare e configurare un server mail. È utile prendersi il tempo necessario per pianificare un corretto partizionamento del disco, possibilmente dedicando una partizione per `/var/log` e una per `/var/spool/mail`. La gestione della posta elettronica in rete coinvolge tre attori : * un client di posta, che è il programma deputato alla formattazione dei messaggi di posta; * un Mail Transport Agent, MTA, che è un server che si occupa di instradare la posta al destinatario; * un delivery agent, DA, che è il server che si occupa di consegnare la posta al destinatario. Il meccanismo di instradamento è basato sull'associazione fra dominio di posta elettronica e dominio DNS. Pertanto, il MTA per consegnare la posta verso il destinatario utilizzerà interrogazioni DNS per effettuare la localizzazione del DA del destinatario. Nei sistemi UNIX, il MTA usa il protocollo SMTP mentre i DA usano i protocolli POP3 o IMAP. La fondamentale differenza fra i protocolli per il DA è che POP3 è progettato per il download dei messaggi sulla postazione client del destinatario, mentre IMAP consente di mantenerli sul server. Entrambi tali protocolli presentano vantaggi e svantaggi. Inoltre, la configurazione qui presentata è arricchita con filtri anti-spam non nativi di '''postfix''' (si usa il prodotto '''spamassassin''') e con un software in grado di coordinare la scansione asincrona dei messaggi di posta attraverso l'uso dei filtri anti-spam e antivirus (questo prodotto è '''mailscanner'''). Verrà esaminata sia la configurazione del MTA per lo smistamento dei messaggi di utenti locali UNIX (ovvero gli utenti di sistema definiti con il comando '''adduser'''), che è quella che utilizza come backend un DB LDAP (ovvero un servizio di directory standardizzato con gestione degli account di utenti di rete). Di seguito sono riportate le guide per l'installazione e la configurazione di ognuno dei singoli programmi che compongono il mail server. (inserire collegamenti) * Postfix (Mail Transfert Agent) * Dovecot (Delivery Agent) * SquirrelMail (servizio webmail) * GPG (Gnu Privacy Guard) ------ --- Dovecot --- = Introduzione = Intro = Installazione = Da un terminale digitare: {{{ sudo apt-get -y install dovecot-pop3d dovecot-imapd }}} = Configurazione = Per la configurazione del DA si proceda come segue : Eseguite il comando: {{{ #vi /etc/dovecot/dovecot.conf }}} e modificate la riga protocols come segue : {{{ protocols = pop3 pop3s imap imaps }}} questo abiliterà i servizi pop3(s) e imap(s) alla'avvio di dovecot. A questo punto per avviare il vostro DA basta eseguire il comando : {{{ #/etc/init.d/dovecot start }}} ed esaminando l'output del comando '''ps -A|grep dovecot''' noterete che il servizio si è avviato con successo. ------ --- Squirrel Mail --- = Introduzione = intro = Installazione = Ora si procede all'installazione di apache2 e di squirrelmail con i comandi : {{{ sudo apt-get -y install apache2 sudo apt-get -y install squirrelmail }}} = Configurazione = Il servizio di posta elettronica fruibile dal browser Web, ''webmail'', richiede che siano installati il web server e il programma squirrelmail per l'accesso alle mailboxes attraverso il browser web. Per predisporre squirrelmail alla gestione della posta elettronica in modalità protetta (attraverso l'uso di certificati con SSL server-side) si userà il comando per generare un certificato per il server web : {{{ apache2-ssl-certificate -days 3650 }}} dove 3650 è la durata di validità del certificato (10 anni, cambiarlo a proprio piacimento se si vuole). A questo punto procedere all'aggiunta di un nuovo Virtual Host nel file '''/etc/apache2/sites-enabled/000-default''' come segue : {{{ <VirtualHost 192.168.0.1> SSLCertificateFile /etc/apache2/ssl/apache.pem DocumentRoot /usr/share/squirrelmail ServerName webmail.example.com </VirtualHost> }}} dove ovviamente si sosituiranno 192.168.0.1 e webmail.example.com con l'IP e l'alias name del server di posta web. Per sperimentare l'accesso attraverso imap da browser web non resta che eseguire i comandi : {{{ sudo /etc/init.d/dovecot start sudo /etc/init.d/apache2 start }}} ed immettere il comando da shell : {{{ firefox https://webmail.example.com:80 ed il gioco è fatto! }}} ------ --- Mail Scanner --- = Introduzione = Per ottenere un ulteriore livello di protezione sul vostro MTA e DA potete associare una scansione antivirus ed un filtro anti-spam che effettuino il controllo di ogni messaggio di posta smistato dal vostro sistema. = Installazione = Come detto vi occorre il software MailScanner e un AntiVirus (nell'esempio riportiamo Clamav) che si installano nel modo seguente : {{{ sudo apt-get -y install mailscanner sudo apt-get -y install clamav-daemon sudo apt-get -y install clamav-freshclam }}} Effettuata l'installazione si proceda con il comando : {{{ vi /etc/MailScanner/MailScanner.conf }}} e si modifichino le righe seguenti : {{{ VirusScanner''' = clamav %org-name%''' = Nome della vostra Azienda %report-dir%''' = /etc/MailScanner/reports/it QuarantineInfections''' = no Information Header Value''' = Informazioni personali dell'azienda Warning Is Attachment''' = no Notices Include Full Headers''' = yes Spam List''' = ORDB-RBL SBL+XBL EasyNet-DNSBL BLITZEDALL SORBS-DNSBL spamcop.net }}} a questo punto salvate e riavviate mailscanner con il comando : {{{ sudo /etc/init.d/mailscanner restart }}} Controllate il corretto avvio in `/var/log/syslog` e con il comando {{{ ps -A|grep mailscanner }}} ------ = Migliorare le prestazioni = Il performance tuning dipende da alcuni parametri del vostro mail server : * '''process availability''' * '''CPU speed''' * '''DNS lookup time''' * '''disk I/O speed''' * '''network throughput''' Come effettuare il tuning del '''process availability''' : * modificate il max numero di processi di postfix per rispondere ai picchi di carico in '''main.cf''' : {{{ default_process_limit = 100 }}} L'ottimizzazione procede attraverso l'analisi dei fattori che condizionano le prestazioni di un Mail Server , ovvero : * '''CPU limitation''' : se il carico sul vostro processore supera il 50% (esaminatelo con top ed individuate se la causa è imputabile ai processi di postfix) allora cambiate processore! * '''DNS lookup''' : poichè il primo passo per inoltrare emails sono queries DNS , se il tempo di risposta per una query DNS è alto pensate a ottimizzare il vostro DNS o meglio ancora implementate un caching NS al vostro interno per velocizzare le risoluzioni * '''Disk I/O limitation''' : usate dischi SCSI (postfix usa code di mail in /var/spool/mail e sposta i dati da una coda all'altra) e montate le partizioni con l'opzione noatime (postfix non usa i timestamps) = Sicurezza dei protocolli di posta = Il protocollo SMTP non è stato progettato per essere sicuro. Come vedete per spedire un messaggio di posta elettronica non è necessaria alcuna autenticazione da parte dell'utente , pertanto chiunque può tentare di sfruttare problemi di sicurezza di un server SMTP. Vi chiederete allora se è possibile utilizzare meccanismi di protezione per aumentare la sicurezza dei vostri servers SMTP,in particolare per crittografare un'intera sessione (ovvero dal primo all'ultimo bit). L'uso dei certificati digitali così come quello della Strong Authentication con SASL è possibile attraverso opportuni moduli messi a disposizione dai programmi di posta stessi , il problema è (per fare l'esempio della protezione tramite certificati) che ciò che verrà crittografato è il traffico fra il client ed il vostro server di posta , ma al di fuori del vostro server (ovvero fino al server SMTP che smista la posta per il dominio del destinatario) le comunicazioni avverranno in chiaro...questo a meno che anche il dominio remoto non utilizzi un sistema di certificati come il vostro. Questo perchè la protezione di una sessione SMTP con certificati richiede che tutte le entità che comunicano abbiano un certificato verificabile da una Root CA...pertanto se anche uno solo dei vostri destinatari non avrà un certificato , allora la comunicazione fra il vostro server di posta ed il server di posta di quel dominio avverrà in modo non protetto. E considerazioni analoghe possono essere fatte per i metodi di autenticazione forte che utilizzano la libreria SASL. Pertanto l'implementazione di meccanismi di protezione delle intere sessioni di posta è subordinata all'implementazione di una PKI globale (cioè estesa a tutti i domini di posta da voi raggiungibili) nel caso dei certificati digitali e di un protocollo SMTP che richieda l'autenticazione di default nel caso di SASL. Questo richiederà probabilmente un nuovo standard per le comunicazioni di posta. Pertanto dovete valutare se vale la pena implementare all'interno della vostra azienda la protezione delle sessioni SMTP con questi metodi. Questo potrebbe fare al caso vostro se volete proteggere le comunicazioni interne , ma quelle con l'esterno resteranno sempre esposte al rischio di attacchi e violazioni. Per fare un esempio concreto se state gestendo un sistema di posta fra N aziende consociate che si scambiano dati sensibili , allora potreste voler creare una PKI ed utilizzare i certificati emessi per garantire l'integrità e la confidenzialità delle informazioni scambiate durante le sessioni. Tuttavia deve esservi chiaro che tutte le sessioni di posta con domini esterni a tali consociate non saranno prote*tte. E per quanto riguarda i protocolli POP3 e IMAP , la cosa è anche peggiore. I clients POP3 e IMAP nella loro configurazione standard inviano le credenziali di autenticazione dell'utente di posta in chiaro sulla rete... Pertanto chiunque sarà in grado di catturarle avrà una facile base di accesso al vostro sistema. La protezione tramite SASL o certificati digitali è sempre possibile , ma come spiegato per essere realmente utile dovrebbe riguardare tutti i domini da cui ricevete la posta , non soltanto il vostro. Tuttavia se non è possibile assicurare una protezione globale di un'intera sessione di posta, la crittografia a chiave pubblica rende comunque possibile proteggere almeno i dati da voi scambiati in un messaggio...cioè il contenuto di tale messaggio oltre che file allegati. Questo è la'rgomento del paragrafo seguente. ------ --- GPG --- = Introduzione = GPG (Gnu Privacy Guard) è un programma che utilizza la crittografia a chiave asimmetrica per garantire la confidenzialità e l'integrità delle informazioni scambiate in un messaggio di posta. = Installazione = Per utilizzarlo dovete installare su tutte le postazioni client il pacchetto gpg con il comando : {{{ sudo apt-get -y install gpg }}} = Configurazione = Pertanto voi potete crittografare il contenuto di un messaggio di posta utilizzando la chiave pubblica dell'utente al quale volete spedirlo e firmare il file crittografato con la vostra chiave privata in modo da assicurarne l'autenticità. Descriviamo con un esempio pratico il flusso delle azioni che l'utente '''pippo@example.com''' deve fare per spedire un messaggio protetto all'utente '''pluto@prova.edu'''. * L'utente pippo crea la sua coppia di chiavi privata/pubblica con il comando {{{ gpg --gen-key }}} Selezionare '''1''' come algoritmo ('''ElGamal''') per poter utilizzare le chiavi per la cifratura e la firma. * pippo visualizza le chiavi create con il comando {{{ gpg --list-keys }}} * pippo esporta la sua chiave pubblica nel repository comune utilizzando il comando {{{ gpg --export -o pippo sftp pippo@publickeys:/keys/pippo }}} * pippo preleva la chiave pubblica di '''pluto@prova.edu''' dalla directory '''/keys''' sul server '''publickeys''' (che funge da repository comune di tutte le chiavi pubbliche degli utenti del sistema di posta comune) e la importa nel suo DB delle chiavi (generato con gpg --gen-key) {{{ sftp pippo@publickeys:/keys/pluto gpg --import pluto }}} questo metterà la chiave di pluto nella directory corrente di pippo. * pippo ora crittografa il messaggio di posta contenuto nel file '''README.txt''' con la chiave pubblica di pluto e lo firma con la sua chiave privata {{{ gpg -se -r pluto README.txt }}} * pippo spedisce il messaggio '''README.txt.gpg''' a pluto@prova.edu usando il suo mail server * pluto importa la chiave pubblica di pippo con il comando {{{ sftp pluto@publickeys:/keys/pippo gpg --import pippo }}} * l'utente pluto va a decifrare il messaggio con il comando {{{ gpg -o README.txt -d README.txt.gpg }}} * se pippo visualizza un messaggio del tipo '''Good signature...''' allora vuol dire che il messaggio non è stato alterato durante la consegna , altrimenti in caso di compromissione visualizzerà un messaggio del tipo '''Bad Signature...''' Autore : Cristiano Valli = Ulteriori risorse = * [[http://www.postfix.org/|Sito ufficiale del progetto Postfix]] * [[http://www.dovecot.org/|Sito ufficiale del progetto Dovecot]] * [[http://www.squirrelmail.org/|Sito ufficiale del progetto SquirrelMail]] |
| Linea 186: | Linea 356: |
| == Aggiungere utenti == Se si volessero aggiungere degli utenti per il server ftp si dovrebbero creare degli utenti del sistema. Prima di iniziare a crearli bisogna prendere alcune decisioni: * L'utente potrà accedere al terminale e/o al sistema come un utente normale? * Quale cartella sarà la home del nostro utente, ovvero quella a cui accederà dal ftp {{{ sudo useradd -d /dir -s /bin/false }}} |
CategoryHomepage |
In questa pagina inserisco delle prove riguardanti la creazione di nuovi wiki.
Link utili per la creazione delle pagine:
MAIL SERVER
Introduzione
Questa guida illustra come installare e configurare un server mail.
È utile prendersi il tempo necessario per pianificare un corretto partizionamento del disco, possibilmente dedicando una partizione per /var/log e una per /var/spool/mail.
La gestione della posta elettronica in rete coinvolge tre attori :
- un client di posta, che è il programma deputato alla formattazione dei messaggi di posta;
- un Mail Transport Agent, MTA, che è un server che si occupa di instradare la posta al destinatario;
- un delivery agent, DA, che è il server che si occupa di consegnare la posta al destinatario.
Il meccanismo di instradamento è basato sull'associazione fra dominio di posta elettronica e dominio DNS. Pertanto, il MTA per consegnare la posta verso il destinatario utilizzerà interrogazioni DNS per effettuare la localizzazione del DA del destinatario.
Nei sistemi UNIX, il MTA usa il protocollo SMTP mentre i DA usano i protocolli POP3 o IMAP.
La fondamentale differenza fra i protocolli per il DA è che POP3 è progettato per il download dei messaggi sulla postazione client del destinatario, mentre IMAP consente di mantenerli sul server. Entrambi tali protocolli presentano vantaggi e svantaggi.
Inoltre, la configurazione qui presentata è arricchita con filtri anti-spam non nativi di postfix (si usa il prodotto spamassassin) e con un software in grado di coordinare la scansione asincrona dei messaggi di posta attraverso l'uso dei filtri anti-spam e antivirus (questo prodotto è mailscanner).
Verrà esaminata sia la configurazione del MTA per lo smistamento dei messaggi di utenti locali UNIX (ovvero gli utenti di sistema definiti con il comando adduser), che è quella che utilizza come backend un DB LDAP (ovvero un servizio di directory standardizzato con gestione degli account di utenti di rete).
Di seguito sono riportate le guide per l'installazione e la configurazione di ognuno dei singoli programmi che compongono il mail server.
(inserire collegamenti)
- Postfix (Mail Transfert Agent)
- Dovecot (Delivery Agent)
SquirrelMail (servizio webmail)
- GPG (Gnu Privacy Guard)
--- Dovecot ---
Introduzione
Intro
Installazione
Da un terminale digitare:
sudo apt-get -y install dovecot-pop3d dovecot-imapd
Configurazione
Per la configurazione del DA si proceda come segue : Eseguite il comando:
#vi /etc/dovecot/dovecot.conf
e modificate la riga protocols come segue :
protocols = pop3 pop3s imap imaps
questo abiliterà i servizi pop3(s) e imap(s) alla'avvio di dovecot.
A questo punto per avviare il vostro DA basta eseguire il comando :
#/etc/init.d/dovecot start
ed esaminando l'output del comando ps -A|grep dovecot noterete che il servizio si è avviato con successo.
--- Squirrel Mail ---
Introduzione
intro
Installazione
Ora si procede all'installazione di apache2 e di squirrelmail con i comandi :
sudo apt-get -y install apache2 sudo apt-get -y install squirrelmail
Configurazione
Il servizio di posta elettronica fruibile dal browser Web, webmail, richiede che siano installati il web server e il programma squirrelmail per l'accesso alle mailboxes attraverso il browser web.
Per predisporre squirrelmail alla gestione della posta elettronica in modalità protetta (attraverso l'uso di certificati con SSL server-side) si userà il comando per generare un certificato per il server web :
apache2-ssl-certificate -days 3650
dove 3650 è la durata di validità del certificato (10 anni, cambiarlo a proprio piacimento se si vuole).
A questo punto procedere all'aggiunta di un nuovo Virtual Host nel file /etc/apache2/sites-enabled/000-default come segue :
<VirtualHost 192.168.0.1> SSLCertificateFile /etc/apache2/ssl/apache.pem DocumentRoot /usr/share/squirrelmail ServerName webmail.example.com </VirtualHost>
dove ovviamente si sosituiranno 192.168.0.1 e webmail.example.com con l'IP e l'alias name del server di posta web.
Per sperimentare l'accesso attraverso imap da browser web non resta che eseguire i comandi :
sudo /etc/init.d/dovecot start sudo /etc/init.d/apache2 start
ed immettere il comando da shell :
firefox https://webmail.example.com:80 ed il gioco è fatto!
--- Mail Scanner ---
Introduzione
Per ottenere un ulteriore livello di protezione sul vostro MTA e DA potete associare una scansione antivirus ed un filtro anti-spam che effettuino il controllo di ogni messaggio di posta smistato dal vostro sistema.
Installazione
Come detto vi occorre il software MailScanner e un AntiVirus (nell'esempio riportiamo Clamav) che si installano nel modo seguente :
sudo apt-get -y install mailscanner sudo apt-get -y install clamav-daemon sudo apt-get -y install clamav-freshclam
Effettuata l'installazione si proceda con il comando :
vi /etc/MailScanner/MailScanner.conf
e si modifichino le righe seguenti :
VirusScanner''' = clamav %org-name%''' = Nome della vostra Azienda %report-dir%''' = /etc/MailScanner/reports/it QuarantineInfections''' = no Information Header Value''' = Informazioni personali dell'azienda Warning Is Attachment''' = no Notices Include Full Headers''' = yes Spam List''' = ORDB-RBL SBL+XBL EasyNet-DNSBL BLITZEDALL SORBS-DNSBL spamcop.net
a questo punto salvate e riavviate mailscanner con il comando :
sudo /etc/init.d/mailscanner restart
Controllate il corretto avvio in /var/log/syslog e con il comando
ps -A|grep mailscanner
Migliorare le prestazioni
Il performance tuning dipende da alcuni parametri del vostro mail server :
process availability
CPU speed
DNS lookup time
disk I/O speed
network throughput
Come effettuare il tuning del process availability :
- modificate il max numero di processi di postfix per rispondere ai picchi di carico
in main.cf :
default_process_limit = 100
L'ottimizzazione procede attraverso l'analisi dei fattori che condizionano le prestazioni di un Mail Server , ovvero :
CPU limitation :
se il carico sul vostro processore supera il 50% (esaminatelo con top ed individuate se la causa è imputabile ai processi di postfix) allora cambiate processore!
DNS lookup :
poichè il primo passo per inoltrare emails sono queries DNS , se il tempo di risposta per una query DNS è alto pensate a ottimizzare il vostro DNS o meglio ancora implementate un caching NS al vostro interno per velocizzare le risoluzioni
Disk I/O limitation :
usate dischi SCSI (postfix usa code di mail in /var/spool/mail e sposta i dati da una coda all'altra) e montate le partizioni con l'opzione noatime (postfix non usa i timestamps)
Sicurezza dei protocolli di posta
Il protocollo SMTP non è stato progettato per essere sicuro.
Come vedete per spedire un messaggio di posta elettronica non è necessaria alcuna autenticazione da parte dell'utente , pertanto chiunque può tentare di sfruttare problemi di sicurezza di un server SMTP.
Vi chiederete allora se è possibile utilizzare meccanismi di protezione per aumentare la sicurezza dei vostri servers SMTP,in particolare per crittografare un'intera sessione (ovvero dal primo all'ultimo bit).
L'uso dei certificati digitali così come quello della Strong Authentication con SASL è possibile attraverso opportuni moduli messi a disposizione dai programmi di posta stessi , il problema è (per fare l'esempio della protezione tramite certificati) che ciò che verrà crittografato è il traffico fra il client ed il vostro server di posta , ma al di fuori del vostro server (ovvero fino al server SMTP che smista la posta per il dominio del destinatario) le comunicazioni avverranno in chiaro...questo a meno che anche il dominio remoto non utilizzi un sistema di certificati come il vostro.
Questo perchè la protezione di una sessione SMTP con certificati richiede che tutte le entità che comunicano abbiano un certificato verificabile da una Root CA...pertanto se anche uno solo dei vostri destinatari non avrà un certificato , allora la comunicazione fra il vostro server di posta ed il server di posta di quel dominio avverrà in modo non protetto.
E considerazioni analoghe possono essere fatte per i metodi di autenticazione forte che utilizzano la libreria SASL.
Pertanto l'implementazione di meccanismi di protezione delle intere sessioni di posta è subordinata all'implementazione di una PKI globale (cioè estesa a tutti i domini di posta da voi raggiungibili) nel caso dei certificati digitali e di un protocollo SMTP che richieda l'autenticazione di default nel caso di SASL.
Questo richiederà probabilmente un nuovo standard per le comunicazioni di posta.
Pertanto dovete valutare se vale la pena implementare all'interno della vostra azienda la protezione delle sessioni SMTP con questi metodi. Questo potrebbe fare al caso vostro se volete proteggere le comunicazioni interne , ma quelle con l'esterno resteranno sempre esposte al rischio di attacchi e violazioni.
Per fare un esempio concreto se state gestendo un sistema di posta fra N aziende consociate che si scambiano dati sensibili , allora potreste voler creare una PKI ed utilizzare i certificati emessi per garantire l'integrità e la confidenzialità delle informazioni scambiate durante le sessioni. Tuttavia deve esservi chiaro che tutte le sessioni di posta con domini esterni a tali consociate non saranno prote*tte.
E per quanto riguarda i protocolli POP3 e IMAP , la cosa è anche peggiore.
I clients POP3 e IMAP nella loro configurazione standard inviano le credenziali di autenticazione dell'utente di posta in chiaro sulla rete... Pertanto chiunque sarà in grado di catturarle avrà una facile base di accesso al vostro sistema.
La protezione tramite SASL o certificati digitali è sempre possibile , ma come spiegato per essere realmente utile dovrebbe riguardare tutti i domini da cui ricevete la posta , non soltanto il vostro.
Tuttavia se non è possibile assicurare una protezione globale di un'intera sessione di posta, la crittografia a chiave pubblica rende comunque possibile proteggere almeno i dati da voi scambiati in un messaggio...cioè il contenuto di tale messaggio oltre che file allegati.
Questo è la'rgomento del paragrafo seguente.
--- GPG ---
Introduzione
GPG (Gnu Privacy Guard) è un programma che utilizza la crittografia a chiave asimmetrica per garantire la confidenzialità e l'integrità delle informazioni scambiate in un messaggio di posta.
Installazione
Per utilizzarlo dovete installare su tutte le postazioni client il pacchetto gpg con il comando :
sudo apt-get -y install gpg
Configurazione
Pertanto voi potete crittografare il contenuto di un messaggio di posta utilizzando la chiave pubblica dell'utente al quale volete spedirlo e firmare il file crittografato con la vostra chiave privata in modo da assicurarne l'autenticità.
Descriviamo con un esempio pratico il flusso delle azioni che l'utente pippo@example.com deve fare per spedire un messaggio protetto all'utente pluto@prova.edu.
- L'utente pippo crea la sua coppia di chiavi privata/pubblica con il comando
gpg --gen-key
Selezionare 1 come algoritmo (ElGamal) per poter utilizzare le chiavi per la cifratura e la firma.
- pippo visualizza le chiavi create con il comando
gpg --list-keys
- pippo esporta la sua chiave pubblica nel repository comune utilizzando il comando
gpg --export -o pippo sftp pippo@publickeys:/keys/pippo
pippo preleva la chiave pubblica di pluto@prova.edu dalla directory /keys sul server publickeys (che funge da repository comune di tutte le chiavi pubbliche degli utenti del sistema di posta comune) e la importa nel suo DB delle chiavi (generato con gpg --gen-key)
sftp pippo@publickeys:/keys/pluto gpg --import pluto
questo metterà la chiave di pluto nella directory corrente di pippo.
pippo ora crittografa il messaggio di posta contenuto nel file README.txt con la chiave pubblica di pluto e lo firma con la sua chiave privata
gpg -se -r pluto README.txt
pippo spedisce il messaggio README.txt.gpg a pluto@prova.edu usando il suo mail server
- pluto importa la chiave pubblica di pippo con il comando
sftp pluto@publickeys:/keys/pippo gpg --import pippo
- l'utente pluto va a decifrare il messaggio con il comando
gpg -o README.txt -d README.txt.gpg
- se pippo visualizza un messaggio del tipo
Good signature...
allora vuol dire che il messaggio non è stato alterato durante la consegna , altrimenti in caso di compromissione visualizzerà un messaggio del tipo
Bad Signature...
Autore : Cristiano Valli
