Cap
ito
lo: P
arte
pri
ma:
INFO
RM
AZI
ON
I GEN
ERA
LI
1
Corso di Sicurezza su reti II
Anno accademico 2007-2008
Prof. A. De Santis
Dott. L. Catuogno
Simulazione della rete Internet:
Gruppo CA
Versione 0.1
Cap
ito
lo: P
arte
pri
ma:
INFO
RM
AZI
ON
I GEN
ERA
LI
2
SOMMARIO Parte prima: INFORMAZIONI GENERALI ............................................................................................................................ 4
Parte seconda: SCHEDA TECNICA ...................................................................................................................................... 5
NTP ............................................................................................................................................................................. 5
CA ............................................................................................................................................................................... 5
Doveri di una CA .................................................................................................................................................... 6
Servizi offerti .......................................................................................................................................................... 6
Doveri del sottoscrittore ........................................................................................................................................ 7
Doveri di terze parti coinvolte ............................................................................................................................... 7
Certificati digitali .................................................................................................................................................... 7
Certificati X.509 ................................................................................................................................................. 7
Struttura del certificato ..................................................................................................................................... 8
Configurazione di OpenCA ..................................................................................................................................... 9
Inizializzazione della Certification Authority ..................................................................................................... 9
Creazione dell’amministratore .......................................................................................................................... 9
Creazione del certificato RA .............................................................................................................................. 9
Inizializzazione di RA ....................................................................................................................................... 10
MANUALE UTENTE............................................................................................................................................... 10
Sottomissione di una richiesta di certificato ................................................................................................... 10
Approvazione del certificato ........................................................................................................................... 10
Rilascio del certificato ..................................................................................................................................... 10
Ottenimento del certificato ............................................................................................................................ 10
Ottenere il certificato root .............................................................................................................................. 10
Aggiungere SR2camail come CA trusted ......................................................................................................... 11
Richiedere un certificato per un web server ................................................................................................... 11
Revocare un certificato ................................................................................................................................... 11
MAIL ......................................................................................................................................................................... 11
Introduzione ........................................................................................................................................................ 11
Implementazione di un servizio e-mail ................................................................................................................ 12
PREREQUISITI : ANATOMIA DI POSTFIX ............................................................................................................... 13
Cap
ito
lo: P
arte
pri
ma:
INFO
RM
AZI
ON
I GEN
ERA
LI
3
Parte terza: FASE DI SETUP .............................................................................................................................................. 15
Software Comuni ..................................................................................................................................................... 16
NTP ........................................................................................................................................................................... 16
CA ............................................................................................................................................................................. 16
mail .......................................................................................................................................................................... 16
INSTALLAZIONE SOFTWARE ......................................................................................................................................... 18
software Comuni ...................................................................................................................................................... 18
Scelta del Sistema Operativo ............................................................................................................................... 18
Installazione .................................................................................................................................................... 18
Aggiornamento................................................................................................................................................ 18
Hardening ........................................................................................................................................................ 18
Firewall ............................................................................................................................................................ 18
Scanning vulnerabilità note ............................................................................................................................. 19
NTP ........................................................................................................................................................................... 19
Installazione ca ......................................................................................................................................................... 19
Installazione web mail.............................................................................................................................................. 23
Installazione di MySQL: ................................................................................................................................... 23
Installazione di PostfixAdmin: ......................................................................................................................... 23
Installazione di Postfix: .................................................................................................................................... 26
Installazione delle componenti di Courier: ..................................................................................................... 28
Testare Courier-IMAP: ..................................................................................................................................... 29
Testare Courier-POP: ....................................................................................................................................... 29
Postfix SASL: .................................................................................................................................................... 30
Installazione di SquirrelMail ............................................................................................................................ 32
CONCLUSIONI ............................................................................................................................................................... 32
FONTI BIBLIOGRAFICHE ................................................................................................................................................ 35
CA ............................................................................................................................................................................. 35
MAIL ......................................................................................................................................................................... 35
Parte quarta: COMMESSE ................................................................................................................................................ 36
Cap
ito
lo: P
arte
pri
ma:
INFO
RM
AZI
ON
I GEN
ERA
LI
4
PARTE PRIMA: INFORMAZIONI GENERALI
NOME DEL GRUPPO CaMail
DENOMINAZIONE CA
COMPONENTI CAROTENUTO FRANCESCO 0521000582
D’AMATO ANGELO 0521000698
ELETTO ANTONIO 0521000742
SCARPA DARIO 0521000692
MISSIONE Implementazione e messa in esercizio di :
una certificate authority
un servizio di web mail
un server NTP
PROGETTO L’intenzione del gruppo è di realizzare la missione utilizzando tutti gli strumento Open Source
che risultino affidabili e facilmente reperibili e che naturalmente non comportano acquisto e
rinnovo delle licenze. La scelta principale per la realizzazione della CA è ricaduta
sull’infrastruttura OpenCA mentre per la realizzazione di un server Mail la scelta è stata
Postfix (come MTA) e courier-imap per il servizio di IMAP e squirrelMail come web Mail.
Come firewall verrà utilizzato il tool di sistema IPtables. I servizi devono essere tutti
accessibili via web (ad eccezione di NTP). Il provider WebMAIL deve supportare la
registrazione on-line degli utenti e l’utilizzo dei certificati client. Ulteriori tool per la sicurezza e
maggiori dettagli verranno forniti nelle fasi successivi.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
5
PARTE SECONDA: SCHEDA TECNICA
DESCRIZIONE SERVIZI NTP NTP è un protocollo per la sincronizzazione dei clock su sistemi distribuiti. E' progettato per funzionare su reti packet-
switched a latenza variabile, e usa la porta UDP 123 per lo scambio di dati. I server NTP sono organizzati in una
gerarchia di "strati" che permette di aumentare la precisione ed eliminare eventuali server scorretti: un server si
sincronizza confrontando il suo orologio con quello di altri server di strato inferiore o dello stesso strato. Tipicamente i
server di strato 1 sono sincronizzati con una fonte temporale esterna come un orologio atomico o radiocontrollato.
CA Si supponga che Alice e Bob vogliono scambiarsi messaggi firmati e crittografati; a tale scopo entrambi creano la loro
coppia di chiavi e le pubblicano su un keyserver. Alice scrive un messaggio per Bob, lo firma con la sua chiave privata
(di Alice) e lo cripta con la chiave pubblica di Bob, quindi il messaggio viene inviato. In ricezione Bob decripta il
messaggio con la sua chiave privata (di Bob) e verifica la firma con la chiave pubblica intestata ad Alice.
Bob a questo punto Bob sa due cose:
il messaggio era diretto a lui perché è riuscito a decifrarlo con la sua chiave privata
il messaggio è stato firmato con la chiave privata relativa alla chiave pubblica che lui ha usato per verificare la firma.
Si può osservare che Bob non ha la sicurezza che la chiave sia effettivamente di Alice. Pertanto una terza persona,
potrebbe intercettare la comunicazione in cui Alice passa la sua chiave a Bob e riesca a sostituire la chiave di Alice con
la sua chiave pubblica. In nessun modo Bob può scoprire questa “sostituzione”.
Le CA nascono per risolvere questo tipo di problema, ossia quello di verificare e garantire la corrispondenza fra chiave
e proprietario. Un utente pertanto richiede un certificato, la CA verifica la sua identità, quindi crea un documento
elettronico in cui sono contenuti:
i dati personali dell'utente
la chiave pubblica dell'utente
gli estremi della CA che ha rilasciato il certificato
gli indirizzi a cui può essere trovata la CRL.
Il documento viene firmato con la chiave pubblica della CA e pubblicato. Nell'esempio precedente supponiamo che
Alice e Bob si facciano firmare le loro chiavi da una CA che entrambi ritengono attendibile. In questo caso l'attacco di
una terza persona non è più fattibile in quanto non è in grado di riprodurre la firma della CA. Le CA commerciali sono
sottoposte ad una rigida regolamentazione e supervisione da parte dello Stato proprio a causa della sensibilità dei dati
personali che gestiscono. Le CA sono delle organizzazioni molto importanti nell'ambito del web dato che tutti i siti che
effettuano di transazioni sicure on-line (come quelle inerenti all'e-commerce), almeno per quanto riguarda
l'autenticazione dell'utente trasferiscono la comunicazione dal protocollo HTTP al protocollo HTTPS; all'atto della
negoziazione il client richiede il certificato del server e quindi viene instaurata la connessione protetta. Quando un
browser (ma anche un client di posta, ecc...) riceve un certificato, lo valida: Nel processo di validazione, si verifica che
tutto l'albero delle CA collegate al certificato sia fidato; un certificato può non essere attendibile per diversi motivi, tra
cui:
1. Il nome a cui è intestato il certificato non corrisponde al nome di chi lo ha presentato ( p.e. il dominio www.miodomino.com deve presentare un certificato che sia intestato a www.miodominio.com).
2. la data corrente non appartiene all'intervallo di validità del certificato. 3. Non tutte le CA che sono state coinvolte nel rilascio del certificato sono considerate attendibili.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
6
In genere i browser o i sistemi operativi contengono un elenco delle CA di primo livello e di livello intermedio che sono
ritenute attendibili e quindi sì "fidano" di quelle CA. Se tutte le CA coinvolte nel rilascio del certificato in esame sono
fidate, il certificato è ritenuto valido altrimenti viene chiesto all'utente cosa fare, ossia se accettarlo o meno. Il
problema di fidarsi o meno del certificato e quindi dell'entità che lo ha presentato viene passato all'utente. Per cui il
problema della fiducia rimane a completo carico dell'utente. È automatico, quindi, che i siti o le infrastrutture
utilizzino certificati da CA molto famose e note per la loro affidabilità.
DOVERI DI UNA CA
Considerando che la RA ha il compito di fornire, in quanto Autorità di Registrazione, l’autenticazione dell’identità del
soggetto, la convalida della corrispondenza tra una chiave pubblica e l’identità del richiedente, la conferma di tale
convalida nei confronti della CA, si è deciso, in seguito alla visione dei dovuti documenti, di far rivestire tali compiti alla
CA stessa; per cui i principali doveri di una CA sono:
autenticare l’identità del soggetto;
convalidare la corrispondenza tra una chiave pubblica e l’identità del richiedente, attraverso un metodo di verifica opportuno;
gestire le richieste di certificazione e l’emissione di nuovi certificati;
accettare e confermare le richieste di certificazione da parte di entità richiedenti un certificato;
rilasciare certificati sulla base delle richieste autenticate;
rendere pubblicamente disponibili i certificati emessi;
occuparsi delle richieste di revoca dei certificati e della revoca degli stessi;
accettare e confermare le richieste di revoca da parte di entità richiedenti;
rendere le CRL pubblicamente disponibili.
SERVIZI OFFERTI
Registrazione: questo è il processo attraverso il quale il richiedente si presenta alla CA, per cercare di ottenere un certificato; durante la procedura viene richiesto al soggetto di fornire i propri attributi, come il nome, l’indirizzo e-mail, il numero di telefono ed altre informazioni, seguendo le specifiche CPS (Certification Practices Statement) della CA; quindi la CA segue le linee guida specificate nel CPS, per verificare che i dettagli forniti dal soggetto siano corretti, prima di emettere il certificato;
Certificazione: è il processo attraverso il quale la CA emette un certificato che contiene la chiave pubblica del soggetto, lo pubblica in un repository pubblico ed accessibile a tutti permettendo di scaricarlo;
Revoca o annullamento: nella maggior parte dei casi, un certificato rimane valido fino a quando non viene raggiunta la data di scadenza. Ci sono, comunque, un certo numero di situazioni in cui è necessaria una revoca prematura del certificato, ad esempio:
o il soggetto ha cambiato nome; o un impiegato lascia la compagnia che ha emesso il certificato; o si è verificata una compromissione (o una sospetta compromissione) della chiave privata.
Il metodo stabilito per la revoca dei certificati include l’uso di una Certificate Revocation List (CRL), che raccoglie i
certificati revocati (normalmente ogni certificato è identificato da un numero seriale unico, assegnato nel momento
dell’emissione) ed è firmata, con tanto di data, dalla CA; la CA pubblica la CRL ad intervalli regolari, nello stesso
repository pubblico. Un certificato la cui corrispondente chiave privata sia stata compromessa deve essere revocato il
più presto possibile, subito dopo che la compromissione è stata scoperta; altrimenti, se la CRL non venisse pubblicata
per molti giorni, dopo la revoca del certificato, gli utenti non sarebbero a conoscenza del problema e potrebbero
accettare messaggi firmati da un intruso con la chiave privata rubata; comunque, anche se la CRL fosse pubblicata
immediatamente dopo la revoca, non ci sarebbe garanzia che gli utenti ne vengano a conoscenza in tempo. Una CRL
permette ai clienti ed ai server di controllare se l’entità con cui stanno dialogando possiede un certificato valido. Il CRL
è un file binario che contiene le seguenti informazioni:
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
7
lista di certificati revocati e ragione della revoca;
emissario della CRL;
data di emissione della CRL;
data di pubblicazione della prossima versione della CRL.
È importante specificare che quando la CA, che aveva originariamente emesso il certificato, lo revoca, firma
digitalmente la CRL: in questo modo, l’utente finale che controlla la CRL può essere sicuro dell’attendibilità delle
informazioni che la CRL contiene. Si accede ad una CRL quando si ha bisogno di usare un certificato contenente una
chiave pubblica per crittografare dati da inviare ad un particolare destinatario, o per verificare la firma digitale
presente in un messaggio ricevuto. Quando si ha una qualsiasi di queste due necessità, si eseguono le seguenti
operazioni:
si ottiene il certificato digitale richiesto;
si ottiene il numero seriale del certificato;
si ottiene la CRL (si accede al proprio repository locale di CRL);
si controlla la firma digitale della CRL, la data di pubblicazione e la data di prossima pubblicazione;
si controlla la CRL per determinare se il certificato che si intende usare è stato revocato o sospeso (basandosi sul numero seriale del certificato).
DOVERI DEL SOTTOSCRITTORE
Un utente deve comportarsi nel rispetto della Certification Practice Statements (CPS) della CA addetta al rilascio di
certificati. Tale accordo prevede:
lettura e rispetto delle procedure concordate;
opportuna custodia della propria chiave privata, in quanto unico possessore, nel caso in cui la sottoscrizione si riferisca a un singolo utente. Nel caso, invece, di una chiave privata rilasciata per un componente hardware o software, la custodia ed il controllo della chiave possono essere affidati alla responsabilità di più di una persona autorizzata;
autorizzazione al trattamento ed alla conservazione dei dati personali;
immediata notifica alla CA in caso di compromissione della chiave privata.
DOVERI DI TERZE PARTI COINVOLTE
Una parte coinvolta deve venire a conoscenza della CPS e della policy utilizzata, prima di trarre alcuna conclusione
sulla fiducia da riporre nell’utilizzo di un certificato emesso da una CA conforme. Essa, inoltre, deve controllare le CRL,
al momento di convalidare l’utilizzo dello stesso certificato.
CERTIFICATI DIGITALI
Un certificato digitale è un documento elettronico che associa l'identità di una persona ad una chiave pubblica. Viene
emesso da una autorità di certificazione riconosciuta secondo standard internazionali (X.509) e viene firmato con la
chiave privata dell'autorità. Gli enti che fanno da autorità devono sottostare a regole rigidissime per quanto riguarda
la gestione dei dati personali, pertanto si possono considerare sicuri.
I certificati garantiscono la tutela delle informazioni personali su Internet e consentono di proteggere il sistema da
programmi software non sicuri. Un certificato è un attestato che consente di verificare l'identità di una persona o la
protezione di un sito Web.
CERTIFICATI X.509
In crittografia, X.509 è uno standard ITU-T per le infrastrutture a chiave pubblica (PKI). X.509 definisce, fra le altre
cose, formati standard per i certificati a chiave pubblica ed un certification path validation algorithm.
Nel sistema X.509, una CA rilascia un certificato che accoppia una chiave pubblica ad un Nome Distintivo(Distinguished
Name) seguendo la tradizione del X.500, oppure ad un Nome Alternativo(Alternative Name) come potrebbe essere un
indirizzo e-mail o un record DNS.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
8
Un root certificate fidato di un'azienda può essere distribuito a tutti i dipendenti, per far si che possano usare la PKI
aziendale. Browser come Internet Explorer, Netscape/Mozilla ed Opera vengono distribuiti con alcuni root certificate
preinstallati, rendendo possibile il funzionamento dei certificati SSL di alcuni grossi distributori che hanno pagato per
questo servizio; in pratica chi sviluppa il browser determina quali CA sono terze parti fidate. Nonostante questi root
certificate possano essere eliminati o disabilitati, raramente gli utenti lo fanno.
X.509 include anche gli standard per le implementazioni di certificate revocation list (CRL, liste di revoca di certificati),
un aspetto spesso sottovalutato dei sistemi PKI. La modalità di controllo della validità di un certificato approvata
dall'IETF si chiama Online Certificate Status Protocol (OCSP).
STRUTTURA DEL CERTIFICATO
La struttura di un certificato digitale X.509 v3 è la seguente:
Certificato o Versione o Numero seriale o ID dell'algoritmo o Ente emettitore o Validità
Non prima Non dopo
o Soggetto o Informazioni sulla chiave pubblica del soggetto
Algoritmo per l'utilizzo della chiave pubblica Chiave pubblica
o Codice identificativo univoco dell'emittente (facoltativo) o Codice identificativo univoco del soggetto (facoltativo) o Estensioni (facoltativo)
Algoritmo di firma del certificato
Firma del certificato I codici identificativi univoci dell'emettitore e del soggetto sono stati introdotti nella versione 2, le "Estensioni" nella
versione 3.
Estensioni comuni per i file contenenti i certificati X.509:
.CER - certificato codificato con DER, a volte sequenze di certificati;
.DER - certificato codificato con DER;
.PEM - certificato codificato con Base64;
.P7B -
.P7C - struttura SignedData PKCS#7 senza dati, solo il/i certificato/i o la/le CRL (Certificate revocation list);
.PFX - vedi .p12
.P12 - PKCS#12, può contenere certificati e chiavi pubbliche e private (protette da password); PKCS #7 è uno standard per la firma o la crittazione (viene chiamata "imbustamento", "incapsulazione", "enveloping"
in inglese) dei dati. Poiché è necessario un certificato per verificare i dati firmati, è possibile includerli in una struttura
SignedData. Un file .P7C non è altro che una struttura SignedData "degenere" (senza dati firmati).
PKCS #12 è nato dallo standard PFX (Personal inFormation eXchange) ed è usato per scambiarsi oggetti pubblici e
privati all'interno dello stesso file. Un file .PEM può contenere certificati o chiavi private, racchiusi tra le apposite linee
BEGIN/END.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
9
CONFIGURAZIONE DI OPENCA
1. Connettiti alla ca http://www.camail.it/ca/ , saranno visibili una serie di tabs. Seleziona il tab Generale e l’oggetto Initialization all’interno. Viene visualizzata la pagina "OpenCA Init" con una serie di link organizzati in tre fasi:
INIZIALIZZAZIONE DELLA CERTIFICATION AUTHORITY
2. Clicca su Initialize the Certification Authority. Viene visualizzata la pagina "Init Certification Authority" 3. Clicca su Initialize Database. Ritorna alla pagina "Init Certification Authority" usando il bottone Back 4. Clicca su Generate new CA secret key. Questo link conduce alla pagina "Get Additional Parameters".
I valori di default sono: a. Encryption algorithm (des,des3,idea):des3 b. Asymmetric algorithm (rsa, dsa):rsa c. CA key size (in bits):4096
Clicca su OK
5. Inserisci la password CA Certificate Private Key nella pagina di login di CA. Questa password proteggerà CA private key e deve essere inserita per lavorare con CA. Dopo aver inserito la password clicca su OK. Il server creerà un paio di chiavi basate sui parametri che hai inserito; questa operazione può richiedere alcuni minuti. Quando la generazione della chiave è completata, uno screen mostrerà la chiave. Clicca su OK. Ritorna alla pagina "Init Certification Authority".
6. Clicca su Generate new CA Certificate Request . Riempi i campi con i parametri necessari per l’installazione. Clicca OK e conferma il DN generato dai parametri Si indicherà di inserire le credenziali, cioè la private key password generata nel passo precedente. Ritorna alla pagina "Init Certification Authority"
7. Clicca su Generate new CA Certificate Request . Riempi i campi con i parametri necessari per l’installazione. Clicca OK e conferma il DN generato dai parametri Si indicherà di inserire le credenziali, cioè la private key password generata nel passo precedente. Ritorna alla pagina "Init Certification Authority"
8. Clicca su Self Signed CA Certificate. Si indicherà di inserire il periodo valido per la CA, e di confermare le credenziali (private key password). Ritorna a "Init Certification Authority"
9. Clicca su Rebuild CA Chain. Dovresti avere una risposta di conferma. 10. Clicca su Export Configuration. 11. Clicca su OK.
CREAZIONE DELL’AMMINISTRATORE
11. Clicca su Create the initial CA certificate. Questo link conduce alla pagina "Init First User". Viene creato un certificato (e una coppia di chiavi) per identificare il CA Administrator
12. Clicca su Create a new request. Compila i dati utente/certificato come desideri. Il ruolo dovrebbe essere "CA Operator"..Il PIN sarà usato per proteggere la chiave privata del certificato sul server. Dai la conferma. Ritorna alla pagina "Init First User".
13. Clicca su Edit the request. Clicca su "Submit the changed request". Clicca su "Issue Certificate". Si indicherà di confermare le credenziali. Ritorna alla pagina "Init First User"
14. Clicca su Handle the request.. Seleziona "Certificate and Keypair" come p12 nella sezione "Operations"e clicca su "Download". Si indicherà la password per la chiave privata per questo certificato, che era stata generata come il PIN sopra. p12 sarà salvato e può essere importato nel browser per usarlo dopo.
CREAZIONE DEL CERTIFICATO RA
15. Clicca su Create the initial RA certificate. Questo link conduce alla pagina "Init First User". Questo passo permette di creare un certificato (e una coppia di chiavi) per identificare l’amministratore RA
16. Clicca su Create a new request. Riempi i dati utente / certificato come desideri. Il ruolo dovrebbere essere "RA Operator". Il PIN sarà usato per proteggere la chiave privata del certificato sul server. Dai la conferma. Non c’è bisogno di stampare le informazioni. Ritorna alla pagina "Init First User"
17. Clicca su Edit the request. Clicca su "Submit the changed request" e poi su "Issue Certificate e conferma. Ritorna alla pagina "Init First User".
18. Clicca su Handle the request.. Seleziona "Certificate and Keypair" come p12 nella sezione "Operations"e clicca su "Download".Si indicherà la password per la chiave privata per questo certificato, che era generata come il PIN. p12 sarà salvato e può essere importato nel browser per usarlo dopo.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
10
INIZIALIZZAZIONE DI RA
19. Connettiti a : http://www.camail.it/ra-node/. Saranno visibili una serie di tabs. Seleziona Administration e l’oggetto Server Init all’interno. Sarà visibile la pagina "Init New Node" con due link.
20. clicca su Import Configuration in "PKI Setup". Questo passaggio consente di rendere il certificato CA disponibile a RA e utenti pubblici
MANUALE UTENTE
SOTTOMISSIONE DI UNA RICHIESTA DI CERTIFICATO
1. Connettiti a www.camail.it/pub 2. Seleziona il tab User e l’oggetto Request a Certificate. Si visualizza la pagina "Basic Certificate Request" (le
stesse operazioni valgono più o meno anche tutte le altre tipologie di certificato) 3. Clicca su Request a certificate with automatic browserdetection. Appare la pagina "Basic Certificate Request" 4. Compila la pagina "Basic Certificate Request", selezionando il ruolo "User". Clicca su "Continue". Conferma la
richiesta. La keysize deve essere riselezionata. Cosa accade dopo dipende dal browser. Mozilla chiede di confermare la keysize e di inserire la master keystore password, che è la password che protegge la chiave private dell’utente. IE chiederà di selezionare il sistema di crittografia, possibilmente passando attraverso alcune decisioni che riguardano la chiave. Prendi nota del numero seriale della richiesta, lo userai per recuperare il certificato.
APPROVAZIONE DEL CERTIFICATO
1. Connettiti alla ra http://www.camail.it/ra/. Seleziona il tab Active CSRs e il nuovo item dentro di esso. Viene visualizzata una pagina di ricerca. Se non hai bisogno di modificare i livelli di sicurezza, puoi usare i parametri di ricerca di default. Clicca su "Search".
2. Dovrebbe comparire una lista di richieste. Clicca sul numero seriale della richiesta che vorresti effettuare. 3. Conferma che la richiesta che appare è quella che desideri e clicca su "Approve Without Signing”.
RILASCIO DEL CERTIFICATO
1. Connettiti a http://www.camail.it/ca/. Seleziona Usual Operations e Approved Certificate Requests. 2. Sono visualizzate una lista di richieste. Clicca sul numero seriale della richiesta che desideri. 3. Conferma che la richiesta che appare è quella che desideri e clicca su "Issue the Certificate". Conferma la
richiesta con la private key password.
OTTENIMENTO DEL CERTIFICATO
1. Connettiti a www.camail.it/pub 2. Seleziona il tab User e l’oggetto Get Requested Certificate. Inserisci il numero seriale e seleziona "Request's
Serial" dal box di selezione "Type of Serial". Clicca su OK. 3. Conferma che il certificato è presente :
con Mozilla (Edit->Preferences->Privacy and Security->Certificates->Manage Certificates)
con Internet Explorer (Tools->Internet Options->Content->Certificates->)
OTTENERE IL CERTIFICATO ROOT
1. Connettiti a www.camail.it/pub 2. Seleziona il tab CA Infos e l’oggetto Get CA Certificate. 3. Seleziona "CA-certificate in format CRT ". Con Mozilla devono essere eseguiti i seguenti passi:
confidare in questa CA per identificare siti web
confidare in questa CA per identificare emails di utenti
confidare in questa CA per identificare sviluppatori software
Clicca su OK.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
11
AGGIUNGERE SR2CAMAIL COME CA TRUSTED
Accedere a OpenCA e selezionare CA Infos -> Get CA certificate Il browser dovrebbe automaticamente proporre l'aggiunta della CA alla lista di quelle fidate.
RICHIEDERE UN CERTIFICATO PER UN WEB SERVER
Generare una chiave privata (da conservare con cura) con openssl, ad esempio utilizzando il comando openssl genrsa -out chiave.key 1024 Generare una CSR (certificate signing request) per la chiave privata generata:
openssl req -new -nodes -key chiave.key -out miosito.csr
Attenzione: specificare SR2camail (case sensitive) come Organization e il dominio (FQDN, comprensivo ad esempio di www) che si vuole autenticare come Common Name
Accedere ad OpenCA e selezionare User->Request Certificate
Selezionare Server Request
Caricare il file PEM della CSR generata precedentemente (miosito.csr nell'esempio).
Inserire le informazioni richieste, avendo cura di specificare Role: Web Server e una e-mail valida.
Quando gli operatori della CA approveranno la richiesta arriveranno delle e-mail di conferma alla mail specificata.
Scaricare il certificato dal link indicato nella mail o accedendo a OpenCA. Alcuni browser potrebbero dare problemi provando a installare il certificato piuttosto che scaricandolo. elinks è testato come funzionante (digitare l'indirizzo indicato nella mail e scegliere "save"). In alternativa, accedere a OpenCA e prelevare il certificato dalla lista dei certificati validi.
E' ora possibile configurare il proprio web server per l'utilizzo del certificato. Nel caso di Apache2 bisognerà indicare i path di chiave privata e certificato con queste direttive:
SSLCertificateFile /etc/apache2/ssl/certificato.pem
SSLCertificateKeyFile /etc/apache2/ssl/chiave.key
A questo punto i browser che considerano SR2camail come fidata non daranno alcun alert HTTPS nell'accesso al dominio.
REVOCARE UN CERTIFICATO
Per revocare un certificato sono necessari la propria chiave privata e il CRIN (pin per la revoca). Il CRIN viene inviato in una mail cifrata quando il certificato viene rilasciato dalla CA. Per ottenerlo occorre decifrare la mail, seguendo i seguenti passi:
accedere alla propria webmail e aprire il messaggio OpenCA Certificate and PIN information
selezionare View message details, Save Message
eseguire: openssl smime -decrypt -in smime.p7m -recip mioCert.pem -inkey
miaPrivKey.pem
dove mioCert.pem e miaPrivKey.pem sono rispettivamente il proprio certificato e la propria chiave privata. Decifrato il messaggio, accedere a OpenCA e utilizzare la funzione di revoca (User->Revoke Certificate), inserendo il CRIN quando richiesto.
INTRODUZIONE
La posta elettronica viene implementata in Internet attraverso la cooperazione di due tipi di sottosistemi:
Mail User Agent (MUA)
Mail Transport Agent (MTA)
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
12
Un MUA è un programma di gestione di posta (Outlook, Eudora, Mutt, etc.), operativo sul client, che deve:
Possedere un’interfaccia utente per l’inserimento, la composizione, la ricezione e la lettura dei messaggi.
Conoscere il protocollo per spedire i messaggi (SMTP) e quindi consegnarli ad una MTA per la trasmissione
Conoscere il protocollo POP3 e IMAP4
Conoscere la sintassi di composizione dei messaggi (RFC822 e MIME)
L’MTA funge da ponte tra due MUA, si occupa della ricezione di tutti i messaggi e del suo recapito, può essere
paragonato ad una centralina telefonica dove vengono smistate le chiamate.
L’MTA può essere:
un server SMTP (porta 25) che gestisce la spedizione e la ricezione dei messaggi verso e da altri server SMTP
Un server POP3 (porta 110) che gestisce la spedizione dei messaggi al client
un server IMAP4 (porta 143) che permette la gestione dei messaggi sul server dal client
I protocolli che garantiscono la maggior parte degli attuali servizi di posta elettronica sono l’SMTP, il POP3 e l’IMAP; tutti e tre sul livello Applicazione (cinque) come l’http, l’ftp e il dns.
IMPLEMENTAZIONE DI UN SERVIZIO E-MAIL
Il processo per portare una e-mail da una persona a un'altra all'interno di una rete o attraverso internet, comporta
l'utilizzo di diversi sistemi che cooperano tra loro. Ognuno di questi sistemi deve essere configurato correttamente.
Colui che spedisce una email utilizza un Mail User Agent (MUA), o client email, per spedire il messaggio attraverso uno
o più Mail Transfer Agents (MTA), l'ultimo dei quali lo consegnerà a un Mail Delivery Agent (MDA) per la consegna
nella casella di posta del destinatario, che la preleverà utilizzando un client email attraverso un server POP3 o IMAP.
OBBIETTIVI
L'obbiettivo è quello di installare un server di posta leggero e versatile come Postfix abbinato a Courier che invece
fornisce i sevizi di pop3, imap, pop3s, imaps e utilizza le Maildir. Per amministrare le caselle di posta ed i domini
utilizzeremo PostfixAdmin. I passi dell'installazione inizieranno con PostfixAdmin poiché fornisce delle tabelle
preconfezionate affinché Postfix funzioni correttamente e supporti features come il numero di alias e caselle di posta
predefinite per tutti i domini creati.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
13
Le caselle di posta, usando questo meccanismo, verranno create al primo messaggio di posta ricevuto. PostfixAdmin di
default invia un messaggio di benvenuto (settato nel suo file di configurazione) da parte dell'amministratore del
dominio appena viene creata la casella via web e quindi generalmente la creazione della Maildir avverrà in questo
momento
PREREQUISITI : ANATOMIA DI POSTFIX
Postfix è un MTA progettato per essere sicuro e veloce: esso è costituito da numerosi demoni, ognuno dei quali si
occupa di un processo ben definito, che interagiscono con i processi utenti (sendmail, postqueue, postsuper, e così
via) e un vasto numero di programmi eseguiti in background. Solo i programmi che sono eseguiti in background sono
controllati dal demone master. Il lavoro del demone master è determinare quale lavoro c’è da fare e indirizzarlo
all’appropriato programma. Questo design modulare permette un più alto livello di sicurezza perché ogni programma
è eseguito con i privilegi più bassi rispetto al task che devono compiere.
ANATOMIA DI POSTFIX: LE ELLISSI GIALLE RAPPRESENTANO I VARI PROCESSI, I RETTANGOLI GIALLI SONO I FILE DELLE MAILBOX O DELLE CODE DI
POSTA, QUELLI AZZURRI SONO I FILE DI CONFIGURAZIONE
Il processo master è un demone residente, che si occupa di richiamare di volta in volta gli altri processi: ad esempio, a
seguito di una richiesta di connessione SMTP, master invocherà il sottoprocesso smtpd, il quale si occupa di aprire
la connessione e di passare l'input al demone cleanup; quest'ultimo, a sua volta, si occupa di aggiungere (o
eventualmente modificare) eventuali header mancanti, per poi inserire il messaggio nella coda di arrivo.
Lo scopo di Postfix è quello di sostituire interamente Sendmail, mantenendone però in tutto e per tutto la
compatibilità: ciò significa che migrare un server da Sendmail a Postfix risulterà completamente trasparente ad ogni
altra applicazione! Come Sendmail, le mailbox corrispondono agli utenti di sistema operativo.
Potremmo immaginare l’intero sistema Postfix come un router. Questo potrebbe sembrare strano all’inizio, ma si
ricorda che il lavoro di un router è vedere l’ip di un pacchetto e determinare la destinazione dallo stesso indirizzo ip (e
possibilmente la sorgente), e poi scegliere la giusta interfaccia alla cui instradare il pacchetto verso la destinazione.
Postfix fa la stessa cosa con le mail , vede la destinazione del messaggio (l’ envelope recipient) e la sorgente (l’
envelope sender) per determinare l’applicazione che porterà il messaggio più vicino alla destinazione finale.
Cap
ito
lo: P
arte
sec
on
da:
SC
HE
DA
TEC
NIC
A
14
Vediamo più da vicino postfix continuando l’analogia fatta tra postfix e router; Postfix smista i messaggi da sorgenti
multiple e poi passa la mail a multiple destinazioni. Il messaggio potrebbe essere generato da sendmail in locale o
da connessioni SMTP o QMQP. La destinazione può essere, una mailbox locale o remota e il messaggio può essere
instradato tramite SMTP, LMTP o una pipe verso un programma.
Un router usa una tabella di routing che fa match tra indirizzi IP della rete per capire su quale interfaccia deve
inoltrare il pacchetto; Postfix fa la stessa cosa con l’indirizzo mail.
In Postfix, le tabelle di lookup usate dai routers, sono chiamate maps e vengono usate, non solo per capire dove inviare
la mail, ma anche per imporre restrizioni sui clients, mittenti e destinatari. La figura sottostante illustra tipi di mappe
come : aliases, virtual e transport.
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
15
PARTE TERZA: FASE DI SETUP
ORGANIZZAZIONE D’Amato Angelo – Eletto Antonio
Installazione della web mail con tutti i componenti necessari per fornire servizio
Carotenuto Francesco – Scarpa Dario
Installazione del servizio ntp e CA
RISORSE HARDWARE
processore : AMD Athlon 550 Mhz
Memoria Ram : 128MB
Scheda video : Matrox mga G200
Hard Disk : ATA Disk 19GB
Lettore cd : Philips 48X
Scheda di rete : VT86C100A di VIA Technolologies, Inc.
Scheda audio : Ensoniq 5880 audiopci
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
16
STRUMENTI SOFTWARE SOFTWARE COMUNI
DEBIAN Sistema Operativo
apache (apache ssl) 2.0 web server (comprendente moduli mod_ssl)
Mysql-server 5.0 database di riferimento per la gestione degli account di
posta e memorizzare i certificati
phpmyadmin 2.9.1.1-6 interfaccia web di gestione di mysql
Perl5 Linguaggio di script utilizzato da OpenCA e SquirrelMail
NTP
Ntpd Network time protocol
CA
OpenCA Framework che implementa il servizio web per gestire
una Certification Authority
postfix 2.3.8-2 Server MTA
NOTE
Postfix utilizza una serie di piccoli programmi per
effettuare il lavoro di delivery di posta, in opposizione a
sendmail che utilizza un approccio monolitico (un solo
programma effettua tutti i lavori). Il risultato di questa
tecnica e che risulta essere uno dei server mail più veloci
e sicuri (meno soggetto a bug in teoria). La
configurazione di questo server rispetto a sendmail è
molto più facile.
Cyrus SASL 2.1.21 SASL authentication daemon.
Procmail 3.22 Viene usato per filtrare la posta in ingresso. Permette agli
utenti di definire delle regole che vengono confrontate
con i messaggi di posta per realizzare delle funzioni
specifiche. E’ facilmente integrabile con l’ MTA.
Fetchmail 6.25 E’ un client IMAP e POP che dà la possibilità agli utenti di
scaricare automaticamente la posta da server remoti e di
salvarla nelle proprie caselle di posta locali.
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
17
SpamBayes 1.1a1 * (facoltativo) E’ uno strumento per la prevenzione dello spam
all'interno delle caselle di posta elettronica. Grazie a
questo software l'utente ha la possibilità di evitare di
scaricare le fastidiose email pubblicitarie ricevute per
email. Il programma rileva automaticamente le email
spazzatura e le elimina, facendo risparmiare grandi
quantità di tempo nella fase di download.
Mutt 1.4.2.1 * (facoltativo) E’ un programma leggero ma molto efficiente per leggere
la posta da console.
postfix Admin 2.2.0 Interfaccia web di gestione per postfix.
Courier-imap 4.0.4 E’ un server IMAP veloce e scalabile che supporta le
caselle in formato maildir . Si tratta dello stesso server
IMAP incluso nel più ampio progetto Courier, ma
configurato come server standalone per essere usato
insieme ad altri MTA, come per l'appunto Postfix.
Courier-authlib 0.57 E’ una libreria che fornisce un servizio di autenticazione
per le altre componenti di Courier.
squirrelMail E’ un' applicazione che implementa un client webmail in
grado di accedere ad un account di posta elettronica
utilizzando un comune browser web. (richiede imap-server,
perl, e php)
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
18
INSTALLAZIONE SOFTWARE SOFTWARE COMUNI
SCELTA DEL SISTEMA OPERATIVO
La scelta del SO è caduta su Debian Gnu/Linux 4.0 (Etch). Debian è una distribuzione che da sempre si
contraddistingue per l'accuratezza e la cautela con cui i pacchetti software vengono inseriti nel branch "stable" della
distribuzione, e per la velocità con cui vengono fornite le patch di sicurezza per tali software (attraverso il sistema di
gestione dei pacchetti del sistema, APT). Debian "stable" si rivela quindi una scelta sensata in ambito server, dove la
stabilità e la sicurezza dei servizi sono requisiti fondamentali da soddisfare (a scapito magari di qualche feature
disponibile solo nelle ultime versioni di una certa applicazione).
INSTALLAZIONE
Abbiamo proceduto con un'installazione base Debian piuttosto standard, dal CD-ROM principale della distribuzione
"stable" corrente, dopo averne verificato l'integrità calcolandone l'md5sum. Abbiamo prestato attenzione a
partizionare l'hard disk a nostra disposizione dividendo il file system, com'e' naturale su una macchina server, in modo
da limitare gli effetti di alcuni attacchi DoS. Se ad esempio il mailspool (o in genere una directory direttamente o
indirettamente user-writable) non è separata dal resto del file system, è possibile creare seri problemi al sistema col
semplice riempimento dello spazio su disco.
AGGIORNAMENTO
Completata la base-install, abbiamo rimosso i pacchetti non ritenuti utili e disattivato i servizi di rete attivi per default.
A questo punto abbiamo connesso la macchina a Internet e configurato APT per effettuare gli aggiornamenti di
sicurezza dai repository ufficiali Debian. Sebbene una fresh-install di Debian stable abbia buone probabilità di essere
"secure by default" per le policy adottate dalla distribuzione, è bene disattivare i servizi o negarne l'accesso tramite
firewall prima di collegare il sistema in rete, in modo da evitare di esporre servizi non aggiornati e quindi
potenzialmente vulnerabili nella finestra temporale dell'update.
Va ricordato che l'integrità dei pacchetti scaricati dai repository Debian via APT è automaticamente verificata tramite
un meccanismo di firma digitale.
HARDENING
Dati i presupposti della simulazione, abbiamo ovviamente ignorato gli accorgimenti relativi alla "sicurezza fisica" del
server, assumendo che, ad esempio, non sia da considerare l'eventualità che un attaccante possa accedere alla
macchina e fare il boot da un dispositivo rimovibile, o smontare l'hard disk e copiare/alterare dei file. Per il resto,
abbiamo operato una serie di piccoli accorgimenti seguendo il "Securing Debian Manual", cercando di ottenere un
buon compromesso tra usabilità/manutenibilità e sicurezza. Varie contromisure consigliate sono state ignorate
considerando il fatto che non è previsto l'accesso interattivo al sistema da parte di utenti (eccetto i membri del gruppo
in laboratorio). Alcuni accorgimenti possibilmente adatti al nostro contesto di esecuzione sono stati rimandati alla fase
di tu.
FIREWALL
Per questa fase di setup iniziale ci siamo affidati a un front-end di iptables molto semplice e intuitivo, firestarter. Ci
riserviamo di rifinire la configurazione manualmente durante la fase di tuning, per ora ci siamo limitati a bloccare tutte
le connessioni inbound eccetto quelle sulle porte dei servizi da rendere disponibili all'esterno:
porta 80 TCP (HTTP)
porta 443 TCP (HTTPS)
porta 123 UDP (NTP)
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
19
SCANNING VULNERABILITÀ NOTE
Una volta ultimata la configurazione dei servizi è stato fatto uno scan completo del sistema con nessus (con tanto di
plugins addizionali della sottoscrizione "free" offerta). Lo scan è stato ovviamente effettuato da un altro host
temporaneamente connesso alla LAN, per avere la prospettiva di un sistema client. Alcuni piccoli accorgimenti alla
configurazione di Apache sono stati effettuati in base al report di Nessus.
NTP
L'installazione del server NTP sotto Debian consiste nella semplice installazione del relativo pacchetto
apt-get install ntp
Dovendo rendere indipendente la nostra simulazione da Internet e quindi dall'aggiornamento subordinato ad altri
server NTP online, abbiamo poi configurato il daemon in modo che si considerasse di "strato 1" e comunicasse ai client
il valore del suo clock locale.
Anche se questo non sarà generalmente corretto, l'importante è che faccia da punto di riferimento al mini-world della
"nostra" Internet.
#modifiche a /etc/ntp.conf
INSTALLAZIONE CA Di seguito riportiamo i passi necessari alla realizzazione dell'installazione dell'infrastruttura OpenCA su un sistema
operativo Debian/Linux, questi passi sono stati ottenuti dopo svariate prove d'installazione effettuate, seguendo varie
guide trovate in rete, da un paio di queste sono riuscito a farne una che come risultato finale portasse ad una
installazione valida.
I repository dei pacchetti che ho usato sono quelli disponibili nella distribuzione. Occorre effettuare un aggiornamento
degli stessi prima di cominciare con l'installazione dei pacchetti necessari, utilizzando il comando apt-get update.
Dato che alcuni software saranno compilati da sorgenti, dobbiamo predisporre il sistema con i pacchetti adeguati:
apt-get install g++ gcc make libssl-dev ncftp ftp unzip bzip2 zip nmap ss
OpenCA richiede come prerequisiti alcuni pacchetti perl, necessari per il suo funzionamento:
apt-get install libwww-perl libxml-perl libxml-regexp-perl libdbi-perl \
perl perl-modules libldap2 libldap2-dev libdbd-mysql-perl \
libauthen-sasl-perl libx500-dn-perl libcgi-session-perl \
libconvert-asn1-perl libdigest-md2-perl libdigest-md4-perl \
libdigest-sha1-perl libio-socket-ssl-perl libio-stringy-perl \
libmime-lite-perl libmime-perl libmailtools-perl libnet-server-perl \
liburi-perl libxml-twig-perl libintl-perl libnet-ldap-perl \
libdigest-hmac-perl libgssapi-perl dbishell libintl-xs-perl \
libxml-sax-perl libcompress-zlib-perl libunicode-map8-perl \
libunicode-string-perl libterm-readline-gnu-perl \
libterm-readline-perl-perl libhtml-format-perl libtie-ixhash-perl \
libxml-xpath-perl perl-doc
server 127.127.1.0 #undisciplined local clock
fudge 127.127.1.0 stratum 1
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
20
Dato che la gestione/configurazione/richiesta dei certificati avverrà tramite interfaccia web, occorre installare anche
un webserver (Apache) e per sicurezza dei dati scambiati, abiliteremo il protocollo SSL. Per comodità mia ho aggiunto
anche il modulo php5, che non è comunque necessario al funzionamento di OpenCA.
apt-get install libapache-mod-perl libapache-mod-ssl libapache-mod-php5 \
php5-mysql php5-gd php-pear xml-core libft-perl php5-dev libgd-tools
Dobbiamo installare e configurare Apache in maniera tale da usare i moduli citati prima.
apt-get install apache
a2enmod perl
a2enmod php5
Per la registrazione delle informazioni personali e dei certificati, ci appoggiamo ad un db MySQL.
apt-get install mysql-server
Adesso possiamo procedere con l'installazione di OpenCA, che avverrà tramite i suoi sorgenti, Pertanto occorre
scaricarli ed estrarli. Per comodità saranno creati due file eseguibili per automatizzare le procedure di installazione.
cd /tmp
wget https://www.openca.org/alby/download?target=openca-0.9.3-rc1.tar.gz --no-
check-certificate
tar xvfz openca-0.9.3-rc1.tar.gz
cd openca-0.9.3-rc1
touch config_ra
touch config_ca
chmod 755 config_ra
chmod 755 config_ca
Creiamo il primo file per automatizzare l'installazione.
nano config_ra e, all'interno di esso, inseriamo:
Ora possiamo eseguirlo.
./config_ra
#!/bin/sh
./configure --prefix=/usr/local/openca --with-web-host=localhost \
--with-httpd-user=www-data --with-httpd-group=www-data \
--with-ext-prefix=/usr/local/openca.0.9.3 --with-htdocs-fs-prefix=/var/www/ \
--with-cgi-fs-prefix=/usr/lib/cgi-bin --with-ca-organization=TEST \
--with-ca-locality=Palermo --with-ca-country=IT \
--with-module-prefix=/usr/local/openca/modules --enable-dbi --disable-db \
--disable-rbac --with-hierarchy-level=ra \
--with-service-email-account=alessandro.pensato@areanetworking.it \
--with-db-type=mysql --with-db-name=openca --with-db-port=3306 \
--with-db-user=openca --with-db-passwd=openca
make
make install-ra
make install-pub
make install-node
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
21
Creiamo il secondo file per automatizzare l'installazione.
nano config_ca con all'interno:
make
make install-ca
make install-node
Eseguiamo anche questo:
./config_ca
Come detto in precedenza, useremo MySQL per memorizzare i dati personali e dei certificati, quindi occorre creare i
database.
mysql -uroot -p
create database openca;
create database openra;
grant all privileges on openca.* to openca@localhost identified by 'openca';
grant all privileges on openra.* to openra@localhost identified by 'openra';
exit;
Modifichiamo il file di configurazione di OpenCA. I relativi campi devono essere come i seguenti.
nano /usr/local/openca/OpenCA/etc/config.xml
#!/bin/sh
./configure --prefix=/usr/local/openca --with-web-host=localhost \
--with-httpd-user=www-data --with-httpd-group=www-data \
--with-ext-prefix=/usr/local/openca.0.9.3 --with-htdocs-fs-prefix=/var/www/ \
--with-cgi-fs-prefix=/usr/lib/cgi-bin --with-ca-organization=SR2camail \
--with-ca-locality=Salerno --with-ca-country=IT \
--with-module-prefix=/usr/local/openca/modules --enable-dbi --disable-db \
--disable-rbac --with-hierarchy-level=ca \
--with-db-type=mysql --with-db-name=openca --with-db-host=localhost \
--with-db-port=3306 --with-db-user=openca --with-db-passwd=openca
ca_organization SR2camail
ca_locality Salerno
ca_country IT
service_mail_account [email protected]
httpd_host localhost
httpd_port :443
dbmodule DBI
db_type mysql
db_name openca
db_host localhost
db_port 3306
db_user openca
db_passwd openca
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
22
Finaliziamo la configurazione di OpenCA e predisponiamo il sistema alla sua esecuzione ad ogni boot.
cd /usr/local/openca/OpenCA/etc/
./configure_etc.sh
cp /usr/local/openca/OpenCA/etc/openca_rc /etc/init.d/
cd /etc/init.d/
update-rc.d openca_rc defaults
./openca_rc start
Costruiamo la coppia di chiavi che saranno utilizzate dalla CA.
mkdir /etc/apache/ssl
cd /etc/apache/ssl
openssl req -x509 -newkey rsa:2048 -keyout cakey.pem -days 3650 -out cacert.pem
-nodes
Inoltre sono state necessarie effettuare alcuni passi fondamentali, per far si che OpenCA potesse funzionare
adeguatamente, sotto Apache 2, tali passi sono necessari per poter effettuare le seguenti operazioni:
Permettere ad Apache 2 di accettare richieste https.
Fare il redirect coatto, di richieste http in https.
Per quanto riguarda la prima operazione i passi compiuti sono essenzialmente: Fare una copia di '/etc/apache2/sites-
available/default' denominata solitamente 'ssl'
cd /etc/apache2/sites-available/
cp default ssl
Abilitare il sito, questo lo si può fare con un link simbolico alla configurazione da /etc/apache2/sites-enabled/. Per far
ciò Apache2 ha un comando specifico:
a2ensite ssl
Abilitiamo il modulo ssl in Apache2
a2enmod ssl
Aggiungere la seguente riga in /etc/apache2/ports.conf
Listen 443
Modificare /etc/apache2/sites-available/ssl come segue:
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
...
</VirtualHost>
Riavviare Apache2 digitando:
/etc/init.d/apache2 restart
Dalla barra del browser digitare https://localhost/
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
23
La seconda operazione invece consiste nell'aggiungere al file.htaccess le seguenti righe di configurazione:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Ed eseguire il seguente comando per poter avviare il modulo mod_rewrite, che consente di poter elaborare
e righe scritte sopra
a2enmod rewrite
INSTALLAZIONE WEB MAIL
INSTALLAZIONE DI MYSQL:
$ apt-get install mysql-server mysql-client
INSTALLAZIONE DI POSTFIXADMIN:
Occorre scaricare PostfixAdmin dal seguente link:
http://sourceforge.net/project/showfiles.php?group_id=191583&package_id=225300&release_id=595813
si tratta di un pacchetto di tipo deb appositamente compilato per debian può essere installato utilizzando la classica
utility dpkg. Dopo l’installazione viene generato automaticamente un link simbolico all’interno della document root
del server web Apache. Il programma infatti è direttamente accessibile attraverso una interfaccia web.
Prima di procedere copiamo il file di configurazione di esempio:
# cp $document-root/postfixadmin/config.inc.php.sample $document-root /postfixadmin/config.inc.php
settiamo i permessi giusti per i file e directory:
# chown -R www-data.www-data *
# cd $document-root /postfixadmin
# chmod 640 *.php *.css
# cd $document-root /postfixadmin/admin/
# chmod 640 *.php .ht*
# cd $document-root /postfixadmin/images/
# chmod 640 *.gif *.png
# cd $document-root /postfixadmin/languages/
# chmod 640 *.lang
# cd $document-root /postfixadmin/templates/
# chmod 640 *.tpl
# cd $document-root /postfixadmin/users/
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
24
# chmod 640 *.php
editiamo config.inc.php affinché sia come segue:
<?php if (ereg ("config.inc.php", $_SERVER['PHP_SELF'])) {
header ("Location: login.php"); exit;
} $CONF['configured'] = true; $CONF['postfix_admin_url'] = ''; $CONF['postfix_admin_path'] = ''; $CONF['default_language'] = 'it'; $CONF['database_type'] = 'mysql'; $CONF['database_host'] = 'localhost'; $CONF['database_user'] = 'pxadmin'; $CONF['database_password'] = 'password'; $CONF['database_name'] = 'postfix'; $CONF['database_prefix'] = ''; $CONF['admin_email'] = '[email protected]'; $CONF['smtp_server'] = 'localhost'; $CONF['smtp_port'] = '25'; $CONF['encrypt'] = 'md5crypt'; $CONF['generate_password'] = 'NO'; $CONF['page_size'] = '10'; $CONF['default_aliases'] = array ( 'abuse' => '[email protected]', 'hostmaster' => '[email protected]', 'postmaster' => '[email protected]', 'webmaster' => '[email protected]' ); $CONF['domain_path'] = 'YES'; $CONF['domain_in_mailbox'] = 'YES'; $CONF['aliases'] = '10'; $CONF['mailboxes'] = '10'; $CONF['maxquota'] = '10'; $CONF['quota'] = 'NO'; $CONF['quota_multiplier'] = '1024000'; $CONF['transport'] = 'NO'; $CONF['vacation'] = 'NO'; $CONF['vacation_domain'] = 'autoreply.camail.it'; $CONF['alias_control'] = 'NO'; $CONF['special_alias_control'] = 'YES'; $CONF['logging'] = 'YES'; $CONF['show_header_text'] = 'NO'; $CONF['header_text'] = ':: Postfix Admin ::'; $CONF['show_footer_text'] = 'YES'; $CONF['footer_text'] = 'Return to camail.it'; $CONF['footer_link'] = 'http://www.camail.it'; $CONF['welcome_text'] = <<<EOM Hi, Welcome to your new account. EOM; ?>
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
25
PostfixAdmin fornisce uno script per creare il database al quale si appoggeranno poi Postfix e Courier:
$ mysql -u root -p < $document-root/postfixadmin/DATABASE_MYSQL.TXT
Per motivi di sicurezza occorre rimuovere il file di configurazione setup.php subito dopo che questa sia stata eseguita:
$ rm $document-root/postfixadmin/setup.php
Bisogna poi configurare la password di accesso per la directory /admin del nostro server aggiungendo al file .htaccess
in $document-root/postfixadmin/admin le seguenti righe:
AuthUserFile /var/www/postfixadmin/admin/.htpasswd AuthGroupFile /dev/null AuthName "Postfix Admin" AuthType Basic <limit GET POST>
require valid-user </limit>
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
26
INSTALLAZIONE DI POSTFIX:
$ apt-get install postfix postfix-mysql
Per la configurazione occorre modificare il file /etc/postfix/main.cf come segue:
Ovviamente i parametri riguardanti uid e gid sono strettamente dipendenti dalle configurazioni del nostro sistema.
Vediamo invece ora i singoli file che abbiamo specificato nella configurazione di Postfix:
/etc/postfix/mysql_virtual_alias_maps.cf
home_mailbox = Maildir/ virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf virtual_gid_maps = static:113 virtual_mailbox_base = /usr/local/virtual virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf virtual_mailbox_limit = 51200000 virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf virtual_minimum_uid = 109 virtual_transport = virtual virtual_uid_maps = static:109 # Additional for quota support virtual_create_maildirsize = yes virtual_mailbox_extended = yes virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql_virtual_mailbox_limit_maps.cf virtual_mailbox_limit_override = yes virtual_maildir_limit_message = Sorry, the user's maildir has overdrawn his diskspace quota, please try again later. virtual_overquota_bounce = yes unknown_local_recipient_reject_code = 450
user = postfix password = postfix hosts = 127.0.0.1 dbname = postfix table = alias select_field = goto where_field = address
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
27
/etc/postfix/mysql_virtual_domains_maps.cf
/etc/postfix/mysql_virtual_mailbox_maps.cf
E’ quindi possibile riavviare Postfix e controllare che non dia errori nei log:
$ /etc/init.d/postfix restart $ cat /var/log/mail.log Apr 25 11:12:34 rproxy postfix/postfix-script: starting the Postfix mail system Apr 25 11:12:34 rproxy postfix/master[23274]: daemon started -- version 2.1.5
user = postfix password = postfix hosts = 127.0.0.1 dbname = postfix table = domain select_field = description where_field = domain
user = postfix password = postfix hosts = 127.0.0.1 dbname = postfix table = mailbox select_field = maildir where_field = username
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
28
INSTALLAZIONE DELLE COMPONENTI DI COURIER:
Anche queste possono essere installate attraverso il tool apt-get di Debian:
$ apt-get install courier-imap courier-pop courier-authdaemon courier-authmysql
Occorre modificare i seguenti file di configurazione:
/etc/courier/authdaemonrc
/etc/courier/authmysqlrc
Si può, a questo punto, riavviare courier-authdaemon:
$ /etc/init.d/courier-authdaemon restart
authmodulelist="authmysql " authmodulelistorig="authmysql" daemons=5 authdaemonvar=/var/run/courier/authdaemon
MYSQL_SERVER localhost MYSQL_USERNAME postfix MYSQL_PASSWORD postfix MYSQL_CRYPT_PWFIELD password MYSQL_DATABASE postfix MYSQL_GID_FIELD '113' MYSQL_HOME_FIELD '/usr/local/virtual/' MYSQL_LOGIN_FIELD username MYSQL_MAILDIR_FIELD maildir MYSQL_NAME_FIELD name MYSQL_OPT 0 MYSQL_PASSWORD postfix MYSQL_SERVER 127.0.0.1 MYSQL_SOCKET /var/run/mysqld/mysql.sock MYSQL_PORT 3306 MYSQL_UID_FIELD '109' MYSQL_USERNAME postfix MYSQL_USER_TABLE mailbox MYSQL_QUOTA_FIELD quota
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
29
TESTARE COURIER-IMAP:
# telnet mail.example.org 143 Trying 85.34.111.52... Connected to host52-111.pool8534.interbusiness.it. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA ACL ACL2=UNION XMAGICTRASH] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc. See COPYING for distribution information. AB LOGIN "[email protected]" "password" AB OK LOGIN Ok. BC SELECT "Inbox" * FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent) * OK [PERMANENTFLAGS (\Draft \Answered \Flagged \Deleted \Seen)] Limited * 2 EXISTS * 2 RECENT * OK [UIDVALIDITY 1114365001] Ok * OK [MYRIGHTS "acdilrsw"] ACL BC OK [READ-WRITE] Ok ZZZZ LOGOUT * BYE Courier-IMAP server shutting down ZZZZ OK LOGOUT completed Connection closed by foreign host.
TESTARE COURIER-POP:
$ telnet localhost 110 Trying 127.0.0.1... Connected to mail.example.org. Escape character is '^]'. +OK Hello there. user [email protected] +OK Password required. pass password +OK logged in QUIT Connection closed by foreign host.
Esiste la possibilità di installare le rispettive versioni di IMAP e POP in SSL con il comando:
$ apt-get install courier-pop-ssl courier-imap-ssl
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
30
Dopo il download ci troveremo davanti a questa schermata:
dopo la quale verranno generati i certificati.
Per una maggiore descrizione e utilizzo di essi si rimanda all'articolo sul sito:
http://www.sistemistiindipendenti.org/modules/news/article.php?storyid=84
POSTFIX SASL:
Un passo oramai obbligatorio è quello di configurare il nostro MTA per l'autenticazione SASL affinché solo utenti
autenticati possano inviare posta.
Installazione del supporto SASL:
$ apt-get install postfix-tls sasl2-bin libsasl2 libsasl2-modules*
Aggiungiamo le seguenti righe al file /etc/postfix/main.cf :
broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_rbl_client opm.blitzed.org, reject_rbl_client list.dsbl.org, reject_rbl_client bl.spamcop.net, reject_rbl_client sbl-xbl.spamhaus.org smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_security_options = noanonymous
SSL certificate required
POP and IMAP over SSL requires a valid, signed, X.509 certificate.
During the installation of courier-pop-ssl resp. courier-imap-ssl a
self-signed X.509 certificate will be generated if necessary. For
production use the X.509 certificate must be signed by a recognized
certificate authority, in order for mail clients to accept the
certificate. The default locations for this certificate is
/etc/courier/pop3d.pem resp. /etc/courier/imapd.pem.
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
31
Configuriamo ora il file smtpd.conf per dirgli che metodo di password check deve usare e il tipo di autenticatore da
usare. La posizione di questo file varia da distribuzione a distribuzione, nel caso di debian dovrà trovarsi al seguente
path:
/etc/postfix/sasl/smtpd.conf
NB. Il file non esiste e quindi va creato.
Ecco come dovrà apparire:
pwcheck_method:authdaemond
log_level: 10
mech_list: LOGIN PLAIN
authdaemond_path:/var/run/courier/authdaemon/socket
NB.Anche il percorso del socket di authdaemon cambia nelle varie distribuzioni. Spesso capita anche che i permessi
del socket non siano quelli giusti. Le solizioni funzionanti sono due:
$ chmod -R a+rwx /var/run/courier/authdaemon
altrimenti:
$ chown root.postfix /var/run/courier/authdaemon
Un esempio di autenticazione:
Apr 26 18:39:50 rproxy postfix/smtpd[16743]: connect from host84-
253.pool8248.interbusiness.it[82.48.253.84]
Apr 26 18:39:51 rproxy postfix/smtpd[16743]: 0D99A4FDFA: client=host84-
253.pool8248.interbusiness.it[82.48.253.84], sasl_method=PLAIN,
Apr 26 18:39:51 rproxy postfix/cleanup[26346]: 0D99A4FDFA: message-
id=<[email protected]>
Apr 26 18:39:51 rproxy postfix/qmgr[17882]: 0D99A4FDFA: from=<[email protected]>,
size=598, nrcpt=1 (queue active)
Apr 26 18:39:51 rproxy postfix/smtpd[16743]: disconnect from host84-
253.pool8248.interbusiness.it[82.48.253.84]
Apr 26 18:39:52 rproxy postfix/smtp[11935]: 0D99A4FDFA: to=<[email protected]>,
relay=mx.email.it[80.247.70.43], delay=2, status=sent (250 Ok: queued as 6A7D1100035)
Apr 26 18:39:52 rproxy postfix/qmgr[17882]: 0D99A4FDFA: removed
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
32
A questo punto dovreste essere in grado di usare il vostro server di posta per più domini e con una gestione molto più
semplificata.
INSTALLAZIONE DI SQUIRRELMAIL
Siamo arrivati alla fase finale del nostro lavoro inteso a offrire un servizio di web mail . La nostra attenzione è
ricaduta su SquirrelMail perché è una soluzione modulare, flessibile e semplice da installare e configurare tramite lo
script conf.pl . Questo servizio si appoggia completamente al protocollo IMAP (nel nostro caso offertoci da courier-
IMAP) . L’unica cosa che manca è la gestione delle iscrizioni di nuovi utenti e quello che si è dovuto fare è di
implementare una soluzione ad hoc.
CONCLUSIONI Concludendo la nostra esperienza con OpenCA, dobbiamo dire che questo si è rivelato (inaspettatamente) deludente
sotto vari aspetti.
l'installazione è macchinosa e forza ad effettuare manualmente una serie di passaggi che potrebbero
tranquillamente essere automatizzati
l'interfaccia è poco usabile e confonde facilmente gli utenti: procedure che dovrebbero essere ovvie non lo
sono
non è previsto alcun genere di controllo (tipo CAPTCHA) per evitare l'inserimento automatico di richieste
o Infatti la nostra CA è stata soggetta ad un attacco simile, che abbiamo risolto (approssimativamente,
per mancanza di tempo) con uno script per la ripulitura del database colpito.
o Una misura risolutiva di tale problema comporterebbe la modifica del front-end web di OpenCA (ad
esempio inserendo un CAPTCHA), ma probabilmente sarebbe meglio investire il tempo necessario a
tale modifica per cercare soluzioni alternative a OpenCA stesso, visti i suoi altri problemi.
** script cleaner.php *******************************************************************************
<?php
// cancella richieste new
mysql_connect("localhost", "root", "PASSHERE") or die(mysql_error());
mysql_select_db("openca") or die(mysql_error());
$query = "SELECT * FROM `request` WHERE STATUS = 'NEW'";
$res = mysql_query($query);
$mailbox = Array();
while ( $row = mysql_fetch_array($res) ) {
$mailfield = $row['dn'];
$start = stripos($mailfield, "=")+1;
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
33
$end = stripos($mailfield, ",");
$addr = substr($mailfield,$start, $end-$start);
$mailbox[] = $addr;
}
$query = "DELETE FROM `request` WHERE STATUS = 'NEW'";
mysql_query($query) or die(mysql_error());
mysql_select_db("postfix") or die(mysql_error());
// cancella mailboxes relative
foreach ($mailbox as $mb) {
$query = "DELETE FROM `mailbox` WHERE username = '$mb'";
mysql_query($query) or die(mysql_error());
$query = "DELETE FROM `alias` WHERE address = '$mb'";
mysql_query($query) or die(mysql_error());
$cmd = "rm -rf /usr/local/virtual/camail.it/".$mb."<br>";
echo $cmd;
}
?>
************************************************************************************************
non siamo riusciti in alcun modo a configurare la comunicazione di OpenCA col sottosistema di
posta: sebbene la documentazione preveda la possibilità di richiamare sendmail per trasmettere i
messaggi, la direttiva di configurazione coinvolta sembra non fare nulla. Il nostro workaround è stato
uno script in cron che ogni minuto legge i messaggi scritti da OpenCA in una sua directory "outbox",
li gira a postfix per l'invio e li sposta in una directory "sent".
** script mandamail.sh *****************************************************************************
#!/bin/sh
SENDMAIL=/usr/lib/sendmail
OPENCADIR=/usr/local/openca/OpenCA/var/mail
DEFAULT=$OPENCADIR/default
CRINS=$OPENCADIR/crins
OPENCADIRSENT=/usr/local/openca/OpenCA/var/mail/sent
DEFAULTSENT=$OPENCADIRSENT/default
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
34
CRINSSENT=$OPENCADIRSENT/crins
for x in $DEFAULT/*.msg
do
$SENDMAIL -t < $x
mv $x $DEFAULTSENT/
done
for x in $CRINS/*.msg
do
$SENDMAIL -t < $x
mv $x $CRINSSENT/
done
Cap
ito
lo: P
arte
ter
za: F
ASE
DI S
ETU
P
35
FONTI BIBLIOGRAFICHE CA [http://www.areanetworking.it/index_docs.php?title=Installazione_di_OpenCA]
[http://www.openca.org]
MAIL [http://www.linuxjournal.com/article/9454]
[http://www.pluto.it/files/journal/pj0201/postfix.htm]
[http://www.postfix.org/anatomy.html]
[http://postfixadmin.org]
Cap
ito
lo: P
arte
qu
arta
: CO
MM
ESSE
36
PARTE QUARTA: COMMESSE
Commessa 1 : access point NIC
DESCRIZIONE Era richiesto la realizzazione di una wi-fi area per l’aereoporto internazionale di Salerno
SOLUZIONE PROPOSTA Un access point offre la wi-fi area gestendo la registrazione degli utenti tramite
un’applicazione web accessibile a servizi.salernoflies.com che fa uso di transazioni sicure.
LAVORO COMPIUTO Abbiamo controllato la correttezza dei dati inseriti nella richiesta di certificato e provveduto ad
approvarla.
GRUPPI COINVOLTI NIC ha configurato l’access point, realizzato l’applicazione web e richiesto il certificato, che
noi abbiamo rilasciato.
Commessa 2 : tuttifrutti.it
DESCRIZIONE Era richiesto la realizzazione e il setup di un portale di e-commerce sicuro per la vendita di
frutta esotica. Il nostro ruolo è stato quello di fornire servizi di mail e rilasciare il certificato per
il web server.
SOLUZIONE PROPOSTA Sulla homepage di CaMail è descritta la procedura per richiedere una mailbox e per
effettuare una richiesta di certificato per web server, che è stata seguita dai webmaster di tutti
frutti.it
LAVORO COMPIUTO Abbiamo controllato la correttezza dei dati inseriti nella richiesta di certificato e provveduto ad
approvarla.
GRUPPI COINVOLTI ISP1 ha realizzato il portale web. Il NIC ha provveduto a registrare il dominio tuttifrutti.it e noi
abbiamo fornito mailbox e certificato.
