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/