I Web Server: configurazione e gestione della sicurezza · Si tratterà brevemente la crittografia...
Transcript of I Web Server: configurazione e gestione della sicurezza · Si tratterà brevemente la crittografia...
Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica
Elaborato finale in Calcolatori Elettronici I
I Web Server: configurazione e gestione della sicurezza
Anno Accademico 2017/2018
Candidato: Pasquale Fabozzi matr. N46002734
Indice
Indice ................................................................................................................................................... II Introduzione ......................................................................................................................................... 3 Capitolo 1: Web Server ........................................................................................................................ 4
1.1 Storia .......................................................................................................................................... 5 1.1.1 CERN httpd ......................................................................................................................... 5 1.1.2 Introduzione ai Server LAMP ............................................................................................. 5
1.2 Software principali ..................................................................................................................... 6
1.2.1 Apache HTTP Server .......................................................................................................... 6 1.2.2 Apache Tomcat ................................................................................................................... 7
1.2.3 Microsoft IIS ....................................................................................................................... 7 1.2.4 WildFly ............................................................................................................................... 7 1.2.5 WebSphere .......................................................................................................................... 7
1.2.6 WebLogic ............................................................................................................................ 8 1.2.7 Nginx ................................................................................................................................... 8
1.2.8 Google Server ..................................................................................................................... 8 Capitolo 2: Server LAMP .................................................................................................................... 9
2.1 Linux ........................................................................................................................................ 10 2.1.1 Download .......................................................................................................................... 10 2.1.2 Installazione ...................................................................................................................... 11
2.2 Apache Tomcat ........................................................................................................................ 15
2.2.1 Pattern MVC ..................................................................................................................... 19 2.2.2 Installazione ...................................................................................................................... 20 2.2.3 Configurazione .................................................................................................................. 21
2.3 MySQL..................................................................................................................................... 23
2.3.1 Download e installazione .................................................................................................. 23 2.4 PHP .......................................................................................................................................... 24
Capitolo 3: Configurazione Web Server con HTTPS ........................................................................ 26
3.1 Il protocollo HTTP ................................................................................................................... 26 3.2 Sicurezza nelle reti ................................................................................................................... 27 3.3 Il protocollo HTTPS................................................................................................................. 29 3.4 Configurazione di Apache Tomcat con HTTPS ...................................................................... 30
3.4.1 Creazione del certificato ................................................................................................... 30
3.4.2 Configurazione di Tomcat con SSL .................................................................................. 31 Conclusioni ........................................................................................................................................ 33 Bibliografia ........................................................................................................................................ 34
3
Introduzione
I web server oggigiorno sono molto diffusi e presenti in ogni tipo di applicazione web.
In questo elaborato si tratteranno i web server e la loro configurazione con cenni sui
problemi di sicurezza. Nel primo capitolo si introdurranno i web server con dei cenni
sulla loro origine e sul primo web server progettato e realizzato. Nello stesso capitolo
si spiegheranno le configurazioni più utilizzate e si descriveranno brevemente i web
server più diffusi. Nel secondo capitolo si tratterà l'installazione di una particolare
configurazione di web server che è la più diffusa e con prestazioni elevate. Nel terzo
capitolo si introdurranno alcune problematiche di sicurezza con le proprietà di una
comunicazione sicura e come garantirle. Si tratterà brevemente la crittografia e si
descriverà il protocollo HTTPS per comunicazioni sicure. Alla fine si configurerà il
web server installato nel capitolo 2 per accettare connessioni sicure.
4
Capitolo 1: Web Server
Con “Web Server” si intende sia un’applicazione software, sia il computer su cui è in
esecuzione. Il computer prende il nome di host. Un Web Server è utilizzato per
diffondere contenuti sul web. In particolare esso si occupa di rispondere alle richieste
dei client utilizzando il protocollo HTTP. Quindi un Web Server deve essere sempre
online per poter essere raggiungibile dai client e servire le loro richieste. Un client in
genere è un web browser che invia richieste HTTP all’indirizzo e alla porta del web
server. Dall’altra parte il web server riceve le richieste HTTP, le elabora e risponde
inviando un pagina in formato HTML. Le pagine web possono essere sia statiche, sia
dinamiche. Le pagine statiche sono scritte in HTML e contengono tutti I contenuti da
mostrare all’utente finale. Le pagine dinamiche, invece, sono pagine scritte non solo in
HTML ma anche in altri linguaggi come PHP o ASP. Questi linguaggi definiscono
delle istruzioni per generare il contenuto della pagina richiesta. Con le pagine
dinamiche è il web server che processa le istruzioni mostrando all’utente finale i
contenuti generati dinamicamente. Processare le istruzioni lato server è molto comodo
per l’utente finale poichè ha bisogno solo di un browser (e non di altri software) per
visualizzare i contenuti richiesti; inoltre questo comporta un risparmio di tempo e di
banda.
5
1.1 Storia Lo sviluppo del web server è dovuto al fisico e informatico Tim Berners-Lee. Egli, nel
1989, ebbe l’idea di utilizzare la gestione ipertestuale in modo da avere un metodo più
veloce e semplice per permettere lo scambio di informazioni del CERN (Conseil
européen pour la recherche nucléair). Nel 1990, con Robert Cailliau, presentò un
progetto da cui scaturì il primo web server (“CERN httpd”), il linguaggio HTML e il
protocollo HTTP.
1.1.1 CERN httpd
Il primo web server fu sviluppato in linguaggio C su un computer NeXT con sistema
operativo NeXTSTEP basato su Unix. In seguito fu esportato su altri sistemi operativi
Unix-like o emulatori unix. Inoltre poteva essere configurato come proxy, ossia come
intermediario. La prima versione fu la 0.1 e venne rilasciata nel 1991. Nello stesso anno
Berners-Lee rese disponibile il codice sorgente sul sito FTP del CERN. La prima
versione era un software di pubblico dominio, cioè liberamente accessibile. In seguito
lo sviluppo fu continuato dal W3C (World Wide Web Consortium) che si focalizzò sullo
sviluppo di un server Java-based (basato sul linguaggio Java). Quest’ultimo fu
rilasciato sotto la licensa del MIT (Massachusetts Institute of Technology).
1.1.2 Introduzione ai Server LAMP
I server LAMP sono dei web server configurati su un sistema operativo Linux. Questo
tipo di server è caratterizzato da un web server, tipicamente Apache, eseguito su una
macchina Linux-based. I server LAMP permettono di avere pagine dinamiche. Apache,
però, non può interpretare i contenuti dinamici, ma sa che per questo compito è
disponibile un interprete PHP che ha accesso ad un database MySQL. L’interprete
6
PHP, accedendo al database, elabora il codice sorgente ricevuto e invia i riusltati ad
Apache che provvede a mostrarli nel browser utente. I server LAMP quindi sono
convenienti e veloci ed è per questo che sono molto utilizzati.
1.2 Software principali Esistono molte applicazioni software che implementano le funzionalità di un web
server. Alcune di esse sono open source, ossia utilizzabili senza l’acquisto di una
licenza, altre sono proprietarie. I web server più diffusi sono i seguenti:
• Apache HTTP Server
• Apache Tomcat
• Microsoft IIS
• WildFly
• WebSphere
• WebLogic
• Nginx
• Google Server
1.2.1 Apache HTTP Server
Apache http Server è un web server open source e ne esistono varie versioni. E’
disponibile per quasi ogni sistema operativo ed è il web server più utilizzato. Supporta
contenuti dinamici, infatti è possibile integrare linguaggi di scripting come PHP. Viene
molto utilizzato nei server LAMP. Recentemente sono stati rilasciati web server che
hanno tempi di risposta minori. Il metodo di gestione delle risorse è basta su un
approccio orientato ai thread e ai processi.
7
1.2.2 Apache Tomcat
E’ un web server open source sviluppato in linguaggio Java. Apache Tomcat è utile per
creare contenuti lato server con Java. Inoltre con un apposito connettore può essere
icluso in un altro web server. Più che un web server, esso è un programma Java che
estende le funzionalità di un server. Tuttavia può rispondere a qualsiasi tipo di richesta
e può essere impiegato comunemente come web server. Gestisce pagine dinamiche
tramite Java oltre che PHP o ASP. Apache Tomcat non implementa tutte le specifiche
JavaEE.
1.2.3 Microsoft IIS
E’ un web server sviluppato dalla Microsoft. In passato era un componente di Windows
Server. In alcuni sistemi operativi Windows può essere installato in un secondo
momento. Funziona solo su server Windows.
1.2.4 WildFly
Precedentemente noto come JBoss AS è un application server open source. Esso
implemeta tutte le specifiche JavaEE. E’ interamente realizzato in Java
1.2.5 WebSphere
E’ un application server sviluppato da IBM. E’ molto utilizzato come software
middleware per eseguire applicazioni e-business attraverso la tecnologia web.
8
1.2.6 WebLogic
Web server sviluppato dalla BEA Systems poi acquistato da Oracle. Implementa le
specifiche JavaEE.
1.2.7 Nginx
E’ anch’esso un server web open source. Nginx è un software che offre più di un solito
web server. Infatti può essere utilizzato per reverse proxy o load balancing. La gestione
delle richieste è asincrona basata su eventi, in netta contrapposizione ad Apache che
usa un modello orientato ai thread nella gestione delle risorse. Grazie a questo metodo
di gestione delle risorse riesce a gestire molte sessioni simultanemamente.
1.2.8 Google Server
E’ il web server utilizzato da Google per le sue applicazioni.
9
Capitolo 2: Server LAMP
Lo stack LAMP (figura 1) è un insieme di software utilizzati dai web server. I web
server sono ospitati su sistemi operativi Linux. LAMP è un acronimo e sta appunto per
Linux, Apache, MySQL e PHP. Come si può notare dalla sigla, un server LAMP si
avvale di quattro software principali:
Figura 1 LAMP Stack
a. Linux: sistema operativo che costituisce il primo livello. È la base dello
stack.
b. Apache: il secondo livello si trova immediatamente sopra quello di
Linux. Quindi è formato da un web server responsabile di tradurre le
richieste del web browser al corretto sito web.
c. MySQL: il terzo livello ospita uno o più database. MySQL memorizza
dati che possono essere interrogati da uno script per costruire il sito web.
MySQL di solito si trova sopra il livello di Linux affianco ad Apache.
In alcune configurazioni è anche possibile avere MySQL in un server
10
separato.
d. PHP: il quarto e ultimo livello è essenzialmente un livello composto da
script scritti in PHP o linguaggi di programmazione web simili. I siti
web e le applicazioni web sono eseguite in questo livello.
Un server LAMP utilizza software free e open-source. Ci sono delle varianti che si
distinguono per i particolari tipi di componenti. Infatti come sistema operativo, oltre
Linux, si può scegliere di utilizzare Windows (server WAMP) o Mac (server MAMP).
Si può scegliere di utilizzare altri web server al posto di Apache, come ad esempio
Nginx. I database più utilizzati sono MySQL e MariaDB, mentre per gli interpreti dei
linguaggi di scripting, oltre PHP, si hanno Perl, Ruby o Python.
2.1 Linux Linux è un sistema operativo open-source. Esistono diverse versioni di Linux sia
desktop che server. Le distribuzioni linux sono tantissime e differiscono per i software
installati di default, le configurazioni iniziali, per l'orientamento alla facilità d'uso o
all'ottimizzazione delle risosre del computer.
2.1.1 Download
Il download di Linux è molto semplice. Innanzitutto è necessario scegliere la
distribuzione da utilizzare. Scegliamo ad esempio la distribuzione Ubuntu. Per poter
scaricare questa distribuzione è necessario andare sul sito ufficiale di Ubuntu
(www.ubuntu-it.org) , navigare fino alla sezione ‘Download’ e segliere la versione a
32 o 64 bit (figura 2).
11
Figura 2 Pagina download Ubuntu 18.10 a 64 bit
Una volta scaricato, otterremo un file in formato ISO di circa 2 GB (figura 3).
Figura 3 File scaricato
Si può procedere all’installazione.
2.1.2 Installazione
L’installazione può avvenire su macchina fisica o su macchina virtuale. Installare un
sistema operativo su macchina virtuale ha molti vantaggi dal punto di vista della
sicurezza. Iniziamo dicendo che una macchina virtuale è un’astrazione di una macchina
fisica. Tuttavia la macchina virtuale è pur sempre un software e come tale deve essere
eseguita su un sistema operativo installato su macchina fisica. Se il sistema operativo
installato su una macchina virtuale termina in modo anomalo la propria esecuzione (a
causa di errori o malfunzionamenti) esso non provoca il crash di tutta la macchina
fisica, ma solo della macchina virtuale dedicata a quel sistema operativo. Quindi si può
utilizzare una macchina fisica come host per una o più macchine virtuali. Al giorno
d’oggi questo meccanismo è molto utilizzato perchè è particolarmente robusto in
termini di sicurezza. La virtualizzazione di una macchina porta però con sè una serie di
problematiche (come virtualizzazione dei processori, virtualizzazione delle porte di
I/O, ecc.) che nel corso degli anni sono state risolte e ne ha reso possibile l’impiego su
larga scala. L’installazione di un sistema operativo su macchina virtuale avviene nello
stesso modo dell’installazione su macchina fisica. L’unica differenza sta nella parte
12
iniziale dell’installazione in quanto per installare un sistema operativo su macchina
virtuale non richiede la scrittura del file immagine ISO su un dsupporto fisico quale
CD, DVD o chiavetta USB bootable. All’avvio del programma di installazione bisogna
selezionare una lingua (figura 4) e avviare l'installazione.
Figura 4 Scelta della lingua
In seguito viene richiesto di scegliere un layout per la tastiera (figura 5).
Figura 5 Scelta del layout della tastiera
13
Al passo successivo viene richiesto se installare una versione normale oppure una
minima (figura 6).
Figura 6 Scelta del tipo di installazione
Si sceglie se usare l'intero disco o partizionare un disco (figura 7). Bisogna confermare
la scelta effettuata (figura 8).
Figura 7 Scelta della partizione
14
Figura 8 Conferma installazione
Si sceglie il fuso orario (figura 9).
Figura 9 Fuso orario
L'ultimo passo è impostare un profilo (figura 10).
Figura 10 Impostazione profilo utente
15
Infine si riavvia il sistema (figura 11).
Figura 11 Installazione completata
Al primo avvio si lancia il comando in figura 12 per aggiornare i software installati.
Figura 12 Comando di aggiornamento
A questo punto il sistema operativo è installato.
2.2 Apache Tomcat Apache Tomcat è l’application server più diffuso insieme al web server Apache.
Apache Tomcat è utilizzato insieme ad Apache HTTP Server per sviluppare
applicazioni web particolarmente complesse. Per lo sviluppo di applicazioni web
semplici è possibile utilizzare anche solamente Apache Tomcat poiché può essere
utilizzato anche da web server. L’utilizzo della coppia Apache HTTP Server-Apache
Tomcat è comodo in applicazioni molto vaste per separare la parte statica (da gestire
con Apache HTTP Server) dalla parte dinamica (da gestire con Apache Tomcat).
Apache Tomcat è un software molto stabile ed affidabile, è open source ed è basato su
Java. Java è un linguaggio di programmazione nato proprio per web per rendere le
applicazioni utilizzabili da tutte le tipologie di dispositivi (computer, smartphone,
tablet, …). Apache Tomcat è un Servlet Container e un JSP Engine, quindi è un motore
in grado di eseguire applicazioni web sul server. Apache Tomcat è costituito da una
serie di elementi:
1) Elementi di alto livello
16
a. Server: rappresenta l’intero Servlet Container.
b. Service: è la combinazione di uno o più componenti Connector. Uno o più di
questi possono essere inclusi in un elemento Server.
2) Esecutori
a. Executor: rappresenta un pool di thread condiviso fra i componenti di
Tomcat. Implementa l’interfaccia org.apache.catalina.Executor.
Fa parte del Service. Per poter essere prelevato dai connettori, deve apparire
prima degli elementi Connector nel file server.xml
3) Connettori
a. HTTP/1.1: è un connettore che supporta il protocollo HTTP/1.1. Inoltre
abilita Tomcat a funzionare come un web server.
b. HTTP/2: utilizza un protocollo HTTP migliorato che prende il nome di
HTTP/2. Questi connettori utilizzano I/O non bloccante utilizzando dei
thread dal pool a disposizione.
c. AJP: serve per comunicare con un web server tramite il protocollo AJP. Si
utilizza per integrare Tomcat in una esistente installazione di Apache.
Supporta il load balancing.
4) Contenitori
a. Context: rappresenta un’applicazione web eseguita in un particolare host
virtuale. Si possono avere più context anche con lo stesso path ma tutti
devono avere nomi diversi. Un context con path uguale ad una stringa di
lunghezza zero (stringa vuota) rappresenta l’applicazione web di default per
quel virtual host.
b. Engine: rappresenta l’intero meccanismo di elaborazione delle richieste
associato ad un particolare service. Riceve e processa tutte le richieste da uno
o più connettori e restituisce la risposta completa da trasmettere all’utente
17
finale. In un elemento service ci può essere un solo elemento engine seguito
dai corrispettivi connettori.
c. Host: rappresenta un virtual host. È un’associazione fra il nome simbolico
della rete del server e il particolare server su cui Tomcat esegue. Il nome di
rete deve essere registrato nel DNS (Domain Name Service). Nel caso in cui
si vogliano associare più nomi simbolici al particolare server si configurano
degli alias. In un engine ci può essere un solo host col nome defaultHost.
d. Cluster: Fornisce delle repliche delle sessioni e repliche degli attributi dei
context. È necessario un controllo su cosa accade per non perdere la fedeltà.
In pratica ad ogni aggiornamento devono essere aggiornate tutte le repliche
altrimenti non si ha più consistenza dei dati. Per poter avere un cluster è
necessaria una rete sicura come una rete LAN privata, una VPN (Virtual
Private Network) o una IPSEC (IP Security).
5) Componenti innestati
a. CookieProcessor: è un componente che converte i cookie ricevuti in modo
da poter essere acceduti e inoltre aggiunge cookie alla risposta.
b. CredentialHandler: è usato per confrontare le credenziali ricevute con quelle
memorizzate. Inoltre, è usato per memorizzare delle nuove credenziali
quando si aggiunge un utente o quando si cambia la password di un utente.
c. GlobalResources: definisce le risorse JNDI globali del server.
d. JarScanner: si utilizza questo componente per scansionare le applicazioni
web da file JAR. Viene utilizzato durante l’inizio di una applicazione web
per identificare quali file processare per inizializzare l’applicazione.
e. JarScanFilter: è un componente che filtra i risultati di JarScanner. Si utilizza
per saltare la scansione di file che si sa che non sono rilevanti per i risultati.
f. Listeners: definisce un componente che esegue determinate azioni quando si
18
verifica uno specifico evento.
g. Loader: è un componente che carica le classi java e le risorse per
l’applicazione.
h. Manager: è un componente utilizzato per creare e mantenere sessioni HTTP.
i. Realm: è un database di username, password e ruoli assegnati a ciascun
utente.
j. Resources: rappresenta tutte le risorse disponibili per l’applicazione web.
Include classi, file JAR, HTML, ecc. Di default esse sono inserite nella
cache.
k. SessionIdGenerator: rappresenta il componente che genera l’id della
sessione usato da un’applicazione in una sessione HTTP.
l. Valve: è un componente inserito nella pipeline di processamento delle risorse
per il determinato container.
6) Elementi Cluster
a. Manager: estensione dela manager di sessione ed è responabile di come la
sessione è replicata.
b. Channel: componente principale di un piccolo framework. Gestisce un
insieme di componenti e insieme creano una comunicazione di gruppo.
c. Channel/Membership: componente utilizzato per individuare in modo
dinamico altri componenti.
d. Channel/Sender: responsabile della consegna di messaggi in uscita dal
cluster sulla rete.
e. Channel/Receiver: responsabile della ricezione di messaggi. E' differente dal
Sender per disaccoppiare la logica di come i messaggi sono inviati da come
sono ricevuti. E' molto simile ai connettori.
f. Channel/Interceptor: architettura per intercettare messaggi e notifche di
19
gruppi.
g. Valve: funzionano come gli altri valve di Tomcat.
h. Deployer: distribuisce o meno applicazioni web sugli altri nodi del cluster.
i. ClusterListener: permette di essere in ascolto sui messaggi ricevuti dai
componenti del cluster.
7) Altri
a. System properties: insieme di proprietà che possono essere settate per
modificare il comportamento di default di Apache Tomcat.
b. JASPIC: definisce una SPI (Service Provider Interface) tramite la quale i
provider di autenticazione, che implementano i meccanismi di autenticazione
dei messaggi, possono essere integrati nei contenitori di elaborazione dei
messaggi delle applicazioni web del server.
2.2.1 Pattern MVC
La progettazione e la gestione delle applicazioni web è resa più semplice seguendo dei
pattern. Un pattern è una soluzione progettuale ad un problema ricorrente. Il pattern più
diffuso nell'ambito dello sviluppo delle applicazioni web è il pattern MVC (figura 13)
basato su tre livelli:
1. Model (modello): è ciò che si vuole rappresentare e può essere modificato
dall'utente. Esso rappresenta lo stato dll'applicazione web.
2. View (viste): rappresenta il modo in cui si rappresenta il modello o parte di
esso. Sono delle interfacce utente.
3. Control (controllo): rappresenta le possibilita di interazione, cioè racchiude la
logica applicativa dell'applicazione stessa modificando il modello.
20
Figura 13 Pattern MVC
Un esempio classico di utilizzo di questo pattern è nella galleria del cellulare. In questo
caso si ha che la vista sono le foto che si possono vedere e il modello è costituito dai
file delle varie foto. Quando l'utente elimina una foto dalla galleria, genera un'azione
elaborata dal control. Al termine dell'elaborazione il control segnala al model che c'è
stata una modifica. A questo punto il model capisce se la modifica ha effetto sui suoi
file e, in caso affermativo, notifica al control le eventuali modifiche. Il control provvede
ad effettuare un aggiornamento della vista.
2.2.2 Installazione
L'installazione di Apache in Ubuntu richiede vari passggi. Innanzitutto per poter
eseguire Apache Tomcat è necessario installare un Java Runtime Environment (JRE)
attraverso il seguente comando (figura 14):
Figura 14 Comando installazione di JRE
Apache Tomcat può essere scaricato in qualsiasi formato dal sito
"https://tomcat.apache.org/download-90.cgi".
Per l'installazione su linux si scarica l'archivio "tar.gz" (figura 15).
Figura 15 Archivio di Apache Tomcat
21
Si lanciano i seguenti comandi (figura 16) (figura 17):
Figura 16 Comando per spostare l'archivio di Apache Tomcat in un'altra cartella
Figura 17 Comando per decomprimere l'archivio di Apache Tomcat
2.2.3 Configurazione
Apache si configura tramite direttive scritte su file di testo. Questi file di testo sono
raggruppati nella cartella di installazione di Tomcat. Dopo ogni modifica ad uno di
questi file è necessario riavviare il server.
La prima cosa da impostare sono delle variabili d'ambiente presenti nel file "profile"
della cartella "/etc" (figura 18).
Figura 18 Settaggio variabili d'ambiente
Portandosi nella cartella "bin" della directory di Apache e si avvia il server (figura 19).
Collegandosi attraverso un browser all'indirizzo IP "http://127.0.0.1:8080/" si può
verificare la corretta installazione del server (figura 20). Per arrestare il server si lancia
il comando in figura 21.
Figura 19 Comando di avvio di Apache Tomcat
22
Figura 20 Pagina iniziale di Apache Tomcat
Figura 21 Comando di arresto di Apache Tomcat
Creiamo un utente "all" che assume i ruoli più importanti inserendo le righe di figura
22 nel file "tomcat-users.xml" della cartella "conf" di Apache Tomcat.
Figura 22 Lista di utenti
All'interno del file "server.xml" si trovano una serie di impostazioni utili come ad
esempio il numero di porta su cui Tomcat accetta le connessioni (8080 di default), il
23
protocollo da utilizzare, il time-out della connessione (figura 23).
Figura 23 Parte del file server.xml
2.3 MySQL MySQL è un RDBMS (Relational Database Management System) composto da un
client e un server disponobili sia per ambienti Unix sia Windows.
2.3.1 Download e installazione
L'installazione di MySQL si esegue installandi i repository (figura 24) e lanciando il
comando di installazione (figura 25).
Figura 24 Comando di aggiunta dei repository di MySQL
Figura 25 Comando installazione MySQL
Si può testare la connessione al database (figura 26) e mostrare tutti i database presenti
(figura 27).
Figura 26 Connessione al database
Figura 27 Output che mostra i database presenti in MySQL
24
Per gestire il database si può usare la linea di comando oppure installare 'interfaccia
grafica MySQL Workbench (figura 28) e connettersi al database (figura 29).
Figura 28 Comando installazione MySQL Workbench
Figura 29 Connessione al database con MySQL Workbench
2.4 PHP PHP (Hypertext Preprocessor) è un linguaggio di scripting di alto livello ideato per la
rpogettazione di pagine web dinamiche. E' un software open-source. Si utilizza per
sviluppare applicazioni lato server. Riprende la sintassi del linguaggio C e del
linguaggio Perl. Supporta la programmazione ad oggetti. E' in grado di interfacciarsi
con vari DBMS tra cui MySQL e Oracle. Inoltre può essere integrato con altri linguaggi
tra cui Java e .NET. Nel corso degli anni PHP ha originato diverse falle nella sicurezza.
La maggior parte di queste falle sono state causate dai programmatori che abusavano
delle funzionalità messe a disposizione da PHP. Queste funzionalità in determinati
25
utilizzi generavano gravi vulnerabilità. Un esempio sono gli abusi di Register Globals
(registri globali) che se usati in modo errato generavano delle backdoor nel programma
PHP. Per evitare questi problemi le versioni successive di PHP hanno via via rimosso
queste funzionalità. PHP, a differenza del C, è un linguaggio interpretato e non
compilato.
26
Capitolo 3: Configurazione Web Server con HTTPS
Un web server serve richieste attraverso il protocollo HTTP. Questo protocollo invia e
riceve messaggi in chiaro quindi chiunque può leggerli e/o modificarli.
3.1 Il protocollo HTTP HTTP (HyperText Transfer Protocol) è un protocollo al livello applicazione del web.
E' definito in RFC 1945 e RFC 2616. E' implementato sia nel client sia nel server.
Esso definisce la struttura dei messaggi e la modalità con cui client e server si
scambiano i messaggi. HTTP utilizza TCP (Transfer Control Protocol) al livello di
trasporto. HTTP non ha memoria di stato perchè i server HTTP non mantengono
informazioni sui client. In alcuni casi è utile avere una memoria di stato per non creare
troppe connessioni TCP. Per avere memoria di stato si utilizzano i Cookie. Un
messaggio HTTP è in formato ASCII quindi leggibile attraverso un editor di testo. Il
messaggio di richiesta (figura 30) è formato da cinque righe ciascuna con un ritorno a
capo. La prima riga è una riga di richiesta, mentre le altre sono di intestazione. Il
metodo di richiesta può essere GET, POST, HEAD, PUT e DELETE. Il più utilizzato
è GET. Le altre righe contengono delle informazioni quali la lingua, il browser, l'host.
HEAD è simile a GET ma con HEAD il server non invia gli oggetti richiesti. Un
messaggio di risposta (figura 31), invece, è formato da più righe di cui una di stto, sei
27
di intestazione e altre di numero imprecisato che costituiscono il corpo del documento.
La riga di stato presenta la versione del protocollo, un codice di stato e un messaggio
di stato. Le righe di intestazione contengono varie informazioni come la data e l'ora di
invio, la lunghezza del corpo del messaggio, la data dell'ultima modifica dell'ogetto.
Figura 30 Messaggio di richiesta HTTP
Figura 31 Messaggio di risposta HTTP
3.2 Sicurezza nelle reti La sicurezza di un web server è strettamente legata alla sicurezza nelle reti. Una
comunicazione sicura deve avere le seguenti quattro proprietà:
1) Riservatezza: solo mittente e destinatario dovrebbero riuscire a capire il
28
contenuto del messaggio trasmesso. Il messaggio può però essere intercettato
per questo deve essere cifrato prima di essere trasmesso.
2) Integrità: durante la trasmissione il messaggio non deve subire delle alterazioni
casuali o volute.
3) Autenticazione: il mittente e il destinatario devono essere sicuri dell'identità del
loro interlocutore.
4) Sicurezza operativa: deve essere garantita nelle istituzioni che hanno accesso a
Internet per proteggere segreti commerciali, evitare il tracciamento della
configurazione interna e attacchi DoS.
La prima proprietà è garantita attraverso l'uso della crittografia per cifrare il messaggio
in modo che solo mittente e destinatario possano leggerlo decifrandolo. Esistono vari
metodi di crittografia. Il metodo di crittografia più utilizzato è quello a chiave pubblica.
Con questo metodo il server mette a disposizione di tutti gli utenti (anche chi attacca)
una chiave di crittografia che viene appunto definita chiave pubblica. Il client che vuole
inviare un messaggio al server cifra il messaggio utilizzando la chiave pubblica fornita
dal server. L'algoritmo di crittografia da eseguire è detto RSA e sfrutta le operazioni
aritmetiche in modulo n per cifrare il messaggio. Il destinatario utilizza la chiave
privata (nota solo a lui) per decifrare il messaggio utilizzando sempre le operazioni
aritmetiche in modulo n. L'algoritmo di cifratura e decifratura è sempre lo stesso. Infatti
per cifrare il messaggio si esegue l'algoritmo sul messaggio usando la chiave pubblica.
La decifratura avviene applicando l'algortimo sul messaggio cifrato usando la chiave
privata.
La seconda proprietà si può garantire attraverso l'utilizzo di una funzione hash e di un
segreto codiviso. La funzione hash calcola una checksum da accodare al messaggio.
L'utilizzo della sola funzione hash non basta perchè un utente malevolo può modificare
il messaggio, ricalcolare la checksum e inviarlo al server. Allora si utilizza anche un
29
segretto condiviso, ossia una stringa di bit da concatenare al messaggio prima di
eseguire la funzione hash. Il client, quindi, invia il messaggio, il segreto condiviso e la
checksum calcolata su messaggio e segreto condiviso (questa checksum prende il nome
di MAC, message authentication code). Nelle reti, per migliorare la sicurezza, si
utilizza una firma digitale (chiave nota solo a chi invia il messaggio) per garantire
l'originalità di un documento. Il MAC non può essere utilizzato per la firma digitale in
quanto sarebbe noto sia dal mittente sia dal destinatario. La cifratura a chiave pubblica,
invece, usa una chiave pubblica e una privata che sono uniche. Il destinatario può
verificare l'autenticità del mittente applicando l'algoritmo RSA e ottenendo il
messaggio. Questo tipo di crittografia, però, è computazionalmente operoso. La firma
digitale è utilizzata per la certificazione della chiave pubblica che è utilizzata in
protocolli di sicurezza di rete come SSL. Tuttavia un utente malevolo può cifrare un
messaggio con la propria chiave privata e allegare la propria chiave pubblica fingendosi
qualcun altro. Per evitare questo problema ci sono delle autorità di certificazione (CA)
che stabiliscono le relazioni tra una chiave pubblica e un'entità. La CA verifica l'identità
e rilascia un certificato con chiave pubblica e informazioni di identificazione globali e
uniche del suo propietario. Questo certificato è firmato digitalmente dalla CA.
3.3 Il protocollo HTTPS Il protocollo HTTPS è un protocollo di comunicazione sicura. La comunicazione
avviene sulla porta 443 (di default). Utilizza un protocollo HTTP in una connessione
criptata al livello di trasporto (con TLS o SSL). SSL (Secure Socket Layer) fu il primo
protocollo di sicurezza introdotto. Non era molto robusto per poter essere decifrato
dalle autorità giudiziarie, ma abbastanza robusto da proteggere da utenti con minori
disponibilità di risorse. In seguito fu introdotto il protocollo TLS (Transport Layer
30
Security). TLS consente ad applicazioni client/server di comunicare attraverso una rete
evitando la manomissione dei dati, la falsificazione e l'intercettazione. Nei browser
l'autenticazione TLS è unilaterale, ossia è solo il server ad autenticarsi. Il browser
valida il certificato del server controllando che la firma digitale sia valida e riconosciuta
da una CA nota. Fatto ciò il browser considera sicura la trasmissione. In applicazioni
aziendali si utilizza un protocollo TLS bilaterale in cui entrambe le parti si autenticano
in modo sicuro. In quest'ultimo tipo di autenticazione è necessario che anche il client
posieda un certificato digitale. TLS è costituito da tre fasi:
1) Il client e il server negoziano un protocollo di cifratura da utilizzare nella
comunicazione, un protocollo per lo scambio delle chiavi, l'algortimo di
autenticazione e il MAC.
2) Scambio delle chiavi e autenticazione.
3) Cifratura simmetrica e autenticazione dei messaggi.
L'algoritmo per lo scambio delle chiavi e quello per l'autenticazione normalmente sono
algoritmi.
3.4 Configurazione di Apache Tomcat con HTTPS Spesso capita di dover attivare il protocollo HTTPS su Tomcat. Per fare ciò è necessario
prima di tutto creare un certificato. La creazione di un certificato è molto complicata,
ma per le operazioni di test se ne può creare uno in modo semplice.
3.4.1 Creazione del certificato
Per creare un certificato dobbiamo rpima di tutto creare un file "keystore" attraverso
un programma chiamato "keytool". Bisogna recarsi nella cartella bin della JDK (Java
31
Development Kit) (figura 32) e lanciare il comando del programma (figura 33).
Figura 32 Spostamento nella cartella bin di JDK
Figura 33 Generazione file keystore
Bisogna inserire una serie di informazioni (figura 34).
Figura 34 Informazioni per la generazione del file keystore
A questo punto si ottiene un file come quello in figura 35.
Figura 35 Keystore file
3.4.2 Configurazione di Tomcat con SSL
Per configurare Tomcat all'utilizzo di SSL bisogna aprire il file "server.xml" nella
cartella "conf" della directory di installazione di Tomcat. Poi occore trovare il
frammento di codice in figura 36, decommentarlo e modificarlo come in figura 37.
Figura 36 Linee di codice da trovare nel file "server.xml"
32
Figura 37 Linee di codice modificate
Alla fine salviamo e testiamo collegandoci all'indirizzo "https://localhost:8443/".
Visualizziamo la pagina principale di Apache Tomcat in modalità sicura (figura 38). Il
server sarà accessibile sia tramite HTTP sia tramite HTTPS.
Figura 38 Pagina principale in HTTPS
33
Conclusioni
Si è visto come poter installare un server LAMP e come configurarlo in HTTPS. Ai
conclude dicendo che questa è solo una breve panoramica sui web server e sulla loro
sicurezza poiché l’argomento trattato è molto ampio e sono presenti innumerevoli altri
problemi di sicurezza con relative soluzioni. Inoltre un web server può essere
configurato in altri modi aggiungendo magari un mail server o un server FTP per il
trasferimento di file. Tutte queste altre configurazioni possono essere integrate in uno
stesso web server per ottenere un server paragonabile a quelli utilizzati dai siti di oggi.
Inoltre è possibile creare ridondanza come nei maggiori server di oggi.
34
Bibliografia
[1] James F. Kurose, Keith W. Ross, Reti di calolatori e Internet: un approccio
top-down, Pearson, 2013, 784.
[2] Liquid Web Inc., https://liquidweb.com/
[3] 1&1 Internet SE, https://www.1and1.it/, 18-10-2016
[4] Apache Tomcat, https://tomcat.apache.org/
[5] Mr. Webmaster, https://www.mrwebmaster.it/