Modelli per i servizi Internet
I servizi telematici, fruibili attraverso Internet, sono generalmente organizzati secondo il modello di interazione denominato client-server.
Questo modello definisce due entità distinte, sulla base dei rispettivi ruoli dei partecipanti al servizio:
- client (utente o sistema che richiede il servizio);
- server (gestore o sistema che fornisce il servizio).
Prima di poter accedere a un servizio applicativo è necessario che il gestore attivi preliminarmente un opportuno software (applicazione server), in grado di accettare ed evadere le richieste degli utenti.
La stazione di lavoro collegata alla rete Internet, su cui viene attivata l’applicazione server, viene indicata semplicemente come Server.
Nella configurazione di ciascun server è fondamentale stabilire le regole per la fruizione del servizio da parte degli utenti.
L’utente interessato ad accedere al servizio, deve provvedere ad avviare sulla propria macchina un secondo componente software (applicazione client) e contattare il server designato.
La stazione di lavoro su cui viene attivata l’applicazione client, viene indicata semplicemente come Client.
In accordo a tale modello, è generalmente responsabilità del client avviare il processo.
Il principio di funzionamento di un client può essere descritto come segue:
- attende i comandi dall’utente prima di compiere ogni azione;
- invia la richiesta formulata dall’utente al server indicato;
- attende risposta dal server;
- presenta all’utente la risposta pervenuta (oppure, in caso di interazione incompleta, un alternativo messaggio di errore).
Le applicazioni server sono generalmente più complesse delle applicazioni client.
La maggiore complessità deriva fondamentalmente dal fatto che molti server sono progettati per poter elaborare più risposte contemporaneamente.
Un server Internet deve inoltre assicurare agli utenti un accesso al servizio privo di interruzioni.
Conseguentemente, le stazioni di lavoro chiamate a ospitare server devono essere opportunamente dimensionate e attrezzate per poter garantire elevate prestazioni e affidabilità.
Le differenze tra client e server non si limitano solo alle componenti hardware, ma riguardano i sistemi operativi coinvolti, e il principio stesso di funzionamento del software utilizzato.
Quando una stazione server è in grado di processare più richieste contemporaneamente, l’applicazione viene definita concorrente; quando invece è in grado di servire solo un client alla volta, viene definita iterativa.
Un server iterativo esegue ciclicamente i seguenti passi:
- aspetta la richiesta di servizio da un generico client;
- processa la richiesta ricevuta dal client;
- invia la risposta elaborata al client;
- torna allo stato iniziale di attesa.
Le richieste che giungono al server iterativo, quando non si trova nello stato di attesa, possono subire sorti diverse:
- possono essere inserite in un buffer e processate quando il server ha evaso le richieste giunte precedentemente;
- possono essere scartate, rifiutando il servizio al client che ne ha fatto richiesta.
La seconda eventualità può accadere anche se si prevede l’impiego di aree di buffer, per memorizzare temporaneamente la coda delle richieste pendenti.
I buffer usati, per la memorizzazione delle richieste, sono necessariamente di dimensione finita.
Una richiesta che giunge con il buffer nella condizione di saturazione viene ovviamente scartata.
Se l’applicazione server non ha riservato sufficienti risorse per la gestione dell’evento “rifiuto del servizio”, lo scarto della richiesta può avvenire addirittura senza che il client venga avvisato.
In certi casi, la saturazione di un’area buffer o il semplice tentativo di trovare posto nel buffer a una richiesta malformata, possono far generare eccezioni operative creando grossi problemi alla stazione server.
Per evitare di rimanere per un tempo indefinito in attesa di una risposta che non sarà mai spedita, è opportuno che il client implementi, in maniera indipendente, una procedura per uscire dallo stato di attesa e inviare una nuova richiesta alla stazione server.
Il massimo periodo di attesa stabilito viene generalmente definito timeout.
Un’analisi superficiale può far credere che la politica di rifiutare il servizio, in caso di risorse temporaneamente impegnate, possa risultare insoddisfacente per molti utenti e, quindi, che servizi del genere non siano molto diffusi.
In realtà, esistono numerosi servizi in cui le richieste pendenti non vengono memorizzate, preferendo aspettare che il client, alla scadenza del timeout, richieda nuovamente il servizio, se ancora interessato.
Questa filosofia è la più adatta per tutti quei servizi in cui la validità temporale della risposta è estremamente limitata.
In certi casi (per esempio per il servizio DNS) il client può essere istruito a inviare le richieste successive a stazioni server diverse, ottenendo un rudimentale meccanismo per bilanciare l’utilizzo delle risorse ed eliminare i single “point of failure”.
La mancata fruibilità di un servizio si presenta in tal caso solo se tutti i server preposti all’erogazione del servizio risultano al momento indisponibili.
Un server concorrente opera invece in accordo ai seguenti passi:
- aspetta la richiesta di servizio da un generico client;
- lancia un nuovo processo per gestire la richiesta pervenuta (tale processo è figlio del processo precedente; il processo figlio ha una durata di vita pari al tempo necessario al trattamento della specifica richiesta);
- il processo figlio processa la richiesta del client;
- il server torna allo stato iniziale di attesa;
- il processo figlio invia la risposta elaborata al client, dopo di che termina.
La possibilità di attivare server concorrenti è legata alle funzionalità del sistema operativo adottato sul server.
Il vantaggio di questo tipo di server è quello di poter trattare contemporaneamente più richieste, ripartendo le risorse tra tutti i processi concorrenti.
Il problema di esaurire le risorse permane anche in server concorrenti.
In questo caso risulta necessario, tanto dimensionare correttamente i buffer delle richieste pendenti, quanto stabilire il numero massimo di processi figli che possono essere attivi allo stesso istante sul server.
I servizi Internet che hanno ottenuto maggiore diffusione, poggiano tutti sul modello di interazione appena descritto (o su qualche variante).
Anche i servizi utilizzati per comunicazioni peer-to-peer, che apparentemente coinvolgono due entità paritetiche (utenti), in realtà si sviluppano secondo il modello client-server.
Per la realizzazione di questi servizi esistono due possibili soluzioni:
- le due stazioni si configurano automaticamente, una come client l’altra come server, per permettere lo scambio dati tra gli utenti;
- entrambi gli utenti dispongono di due applicazioni, contemporaneamente attive sulla propria stazione, una con funzioni di client e l’altra con funzioni di server.
A parte l’eccezione rappresentata da tali servizi peer-to-peer, il diverso ruolo rivestito dalle due entità coinvolte nel servizio le rende oggetto di attacchi di natura profondamente diversa.
Per questo motivo, le debolezze e le possibili contromisure per stazioni client e server dovranno essere analizzate separatamente.
Nonostante questo è indispensabile che il rischio associato all’impiego di client e server sia affrontato congiuntamente, nell’ambito di una complessiva politica di sicurezza dall’organizzazione a cui tali sistemi appartengono.
La politica di sicurezza altro non è che un piano completo che descrive l’atteggiamento che l’organizzazione intende mantenere nei confronti della sicurezza informatica.
Il piano può risultare anche molto complesso e generalmente definisce i meccanismi necessari per scambiare in maniera sicura informazioni tra gli utenti; le linee guida da seguire per una corretta gestione delle macchine che ospitano le applicazioni client e server; le soluzioni da implementare per ottenere una protezione adeguata dei dati memorizzati su server e di quelli mantenuti su client.
Una variante molto diffusa del modello client-server è il modello “client-server con cache”.
Generalmente un client mantiene localmente solo le informazioni correnti, o quelle di cui un utente richiede espressamente la conservazione.
Nel paradigma client-server con cache, il client non scarta le risposte ottenute dal server (dopo averle presentate all’utente), ma le memorizza automaticamente in locale per un impiego futuro.
In questo modo le richieste successive possono essere risolte localmente senza altri accessi alla stazione server.
Il client con cache segue un ciclo costituito dai seguenti passi:
- attende comandi dall’utente prima di compiere ogni azione;
- controlla se la richiesta dell’utente è già stata recentemente processata (ed esiste una informazione temporalmente valida memorizzata nella cache locale);
- se l’informazione in cache esiste presenta questa all’utente e termina;
- se l’informazione non esiste invia una specifica richiesta al server;
- attende la risposta del server;
- presenta all’utente la risposta pervenuta dal server (o in caso di interazione incompleta un alternativo messaggio di errore);
- memorizza le informazioni nella cache locale per successive interrogazioni e termina.
La presenza di una copia delle informazioni in cache, introduce una vulnerabilità in più rispetto al modello client-server di base.
La modifica del contenuto della cache locale di un client non ben protetto produce lo stesso danno, per l’utente, della sostituzione dei dati memorizzati su un server gestito in maniera corretta.
L’effetto nocivo dell’azione dell’attaccante è in tal caso limitato agli utenti che utilizzano la cache alterata.
La cache può essere utilizzata anche come area locale dove trasferire preventivamente dal server le informazioni collegate, in qualche maniera, alla richiesta corrente effettuata dall’utente.
L’esperienza dimostra, infatti, che argomenti collegati alla risposta corrente sono generalmente richiesti dall’utente nelle interrogazioni successive.
Aver trasferito preventivamente sulla piattaforma dell’utente tali informazioni, riduce nel complesso i tempi di accesso al servizio ma aumenta la quantità di informazioni che possono essere oggetto di alterazioni sul client.
Un’altra variante al modello client-server, con un impatto significativo anche a livello di sicurezza, è rappresentata dal modello “accesso tramite proxy server”.
Secondo questo modello, esiste una terza entità coinvolta nel servizio, denominata proxy, che si interpone tra le altre stazioni.
Questa entità si interfaccia infatti sia con il client sia con il server, agendo da intermediario durante l’accesso al servizio.
Il proxy è responsabile di accettare le richieste da parte di uno o più client e inoltrarle alle stazioni server.
Le risposte delle stazioni server vengono consegnate al proxy, che si fa carico di trasferirle successivamente ai client interessati.
In certi casi il proxy deve anche farsi carico di individuare il server che dispone di una specifica risorsa (come nella risoluzione dei nomi simbolici associati all’URL richieste in ambito di accesso al World Wide Web).
La stazione che agisce da proxy può ospitare una cache, un’area comune che può essere utilizzata da molteplici client al posto o in aggiunta alle loro cache locali.
Il proxy e i dati memorizzati nella sua cache possono essere oggetto di attacchi.
L’unico modello alternativo al client-server, che ha riscontrato una certa diffusione, è il modello di servizio broadcast.
Nonostante questo sia stato sviluppato per consentire servizi di distribuzione di informazioni in ambienti profondamente diversi da quello delle reti telematiche (per esempio TV e radio) questo modello ha ottenuto un certo riscontro anche nella realizzazione di servizi informativi accessibili via Internet.
A differenza di quanto avviene con il modello client-server, in cui il reperimento delle informazioni avviene soltanto al momento dell’invio delle richieste da parte del client, con il modello broadcast, le piattaforme che gestiscono il servizio inviano le informazioni in maniera non sollecitata.
Tali informazioni vengono raccolte dalle piattaforme client e memorizzate localmente, in attesa di essere utilizzate dagli utenti.
Questo tipo di servizio richiede generalmente un banda trasmissiva maggiore di quanto necessario con interazioni client-server, ma offre il beneficio di minimizzare i tempi di accesso alle informazioni per gli utenti che trovano già le informazioni disponibili sulla macchina locale al momento della richiesta.
Una naturale evoluzione di tale modello è rappresentata dal servizio multicast.
In tale modello la diffusione delle informazioni entro una sottorete è condizionata alla presenza/assenza di almeno un’entità registrata al servizio in quella stessa sottorete.
Le problematiche di sicurezza di un servizio Internet, basato sul modello di diffusione broadcast o multicast, sono per molti versi simili a quelle relative ai servizi realizzati secondo il già citato modello client-server con cache.
