Esempio - Dmi Unipg

Sicurezza dei sistemi
informatici
Master di I° livello in
Sistemi e Tecnologie per la sicurezza
dell'Informazione e della Comunicazione
Quarta lezione
6/6/2007
Contenuto





Classificazione dei livelli di sicurezza di un
S.O.
Sicurezza su Windows
Sicurezza su Unix
Sistemi per la Intrusion Detection
Sicurezza nei database
Classificazione della sicurezza dei
sistemi di calcolo



Orange Book. Documento pubblicato dal
Dipartimento della Difesa americano (D.O.D)
Sono specificate quattro categorie di
sicurezza:A, B, C, D (in ordine decrescente).
Categoria D. Non ha livelli di sicurezza.

Esempi MS-DOS, Windows 3.1.
Classificazione


Categoria C. Suddivisa in C1 e C2:
C1. La Trusted Computing Base consente:





Esempio: Unix
C2. La TCB consente


Autenticazione degli utenti (password). I dati di
autenticazione sono protetti rendendoli inaccessibili agli
utenti non autorizzati.
Protezione dei dati e programmi propri di ogni utente.
Controllo degli accessi a oggetti comuni per gruppi di
utenti definiti
oltre a quanto definito per la C1, il controllo degli accessi
su una base individuale.
Esempio UNIX, Windows NT e 2000.
Classificazione

Categoria B. Suddivisa in B1, B2 e B3



B1. La TCB consente, oltre a quanto definito in C2,
l’introduzione dei livelli di sicurezza (modello Bell-La
Padula). Almeno due livelli.
B2. La TCB estende l’uso di etichette di riservatezza ad
ogni risorsa del sistema, compresi i canali di
comunicazione.
B3. La TCB consente la creazione di liste di controllo degli
accessi in cui sono identificati utenti o gruppi cui non è
consentito l’accesso ad un oggetto specificato.
Classificazione

Categoria A. Suddivisa in A1 e classi
superiori


A1. E’ equivalente a B3, ma con il vincolo di
essere progettato e realizzato utilizzando metodi
formali di definizione e verifica.
Un sistema appartiene ad una classe superiore ad
A1 se è stato progettato e realizzato in un impianto
di produzione affidabile da persona affidabile
Cronologia di Windows: MS DOS





1981 MS-DOS 1.0 per IBM PC
1983 versione 2.0
1986 versione 3.0
sempre per 16 bits, line-oriented e single-user
Windows 2.x/3.x è semplicemente una GUI
per MS-DOS
Cronologia di Windows:
Windows 9x

Windows 95 e 98 continuano ad avere molto
in comune con MS-DOS




molte parti sono a 16 bit
hanno lo stesso file system
diversità: integrazione del networking nel SO
(problemi legali)
nessuna sicurezza:

condivisione degli spazi di memoria di tutti gli
utenti
Cronologia di Windows:
Windows NT


Negli ultimi anni 80 parte windows NT
Indipendente da MS-DOS, nasce nel ‘93




fiasco sul mercato, piccolo successo come server
NT 4.0 (1996) --> 16 M di codice C e C++
NT 5.0 (Windows 2000) --> 29 M di codice
Possiede molte più features di Unix (window
e GUI sono nel SO, ha codice per architetture
diverse e per versioni diverse....)
Libreria Win32 API




è una libreria molto vasta di procedure che
possono effettuare chiamate di sistema o anche
possono operare semplicemente in user mode
moltissime API grafiche
garantisce la compatibilità con i SO
precedenti
Per contrasto, Unix definisce un numero
esiguo di chiamate che restano fisse nelle
diverse versioni
Come funzionano le API di Win32



Le invocazioni di procedure Win32 creano
oggetti (file, processi, thread ecc)
La chiamata restituisce un handle all’oggetto
che può essere utilizzato in altre chiamate
E’ un po’ object-oriented: c’è
l’incapsulamento, l’oggetto è manipolato
(solo) con le funzioni previste
Il registry



E’ un database che contiene tutte le
informazioni di configurazione
hardware/software/sicurezza che sono
necessarie al boot
è una specie di file system con directory e file
generalmente molto piccoli
il registry è diviso in sezioni (ROOT KEYS),
che contengono directories (keys) che a loro
volta possono contenere subkeys o valori (file
di testo)
Root keys






HKEY_LOCAL_MACHINE
HKEY_USERS
HKEY_PERFORMANCE DATA
HKEY_CLASSES_ROOT
HKEY_CURRENT_USER
HKEY_CURRENT_CONFIG
Manipolare il registry




il registry è in formato proprietario, si
manipola quindi (solo) con un registry editor,
cioè regedit.exe
L’integrità del registry è importante
hives e keys hanno liste di permessi per i
gruppi predefiniti
Per default non l’audit non si fa, ma è previsto
Procedure per manipolare il registry

Esistono procedure win32 API per manipolare
il registry:





RegCreateKeyEx (crea un nuovo key)
RegOpenKeyEx (ottiene un handle)
RegEnumKeyEx (enumera le key)
RegQueryValueEx (ricerca)
Il registry è protetto accuratamente, la sua
corruzione implica il reinstallo dell’intero
sistema
Caratteristiche di sicurezza in NT






login sicuro con misure anti-spoofing (al CTRL-ALTDEL è chiamato il driver della tastiera che a sua volta
chiama un programma di sistema “genuino”)
controllo degli accessi discrezionale
accesso privilegiato
protezione dello spazio degli indirizzi di ciascun
processo
prima dell’uso le pagine di memoria vengono
azzerate
audit
Gruppi e permessi



Windows NT prevede molti utenti e gruppi
predefiniti (i loro permessi di default sono nel
Registry)
Cio è molto utile per distribuire le
responsabilità della gestione del sistema su
vari utenti
Anche l’insieme dei permessi è più ampio:

oltre a read write ed execute, si può concedere take
ownership, change permissions, delete,….
Permessi in Windows










DELETE The right to delete the object.
READ_CONTROL The right to read the information in the object's security
descriptor, not including the information in the SACL.
SYNCHRONIZE The right to use the object for synchronization. This
enables a thread to wait until the object is in the signaled state. Some object
types do not support this access right.
WRITE_DAC The right to modify the DACL in the object's security
descriptor.
WRITE_OWNER The right to change the owner in the object's security
descriptor.
FILE_ADD_FILE For a directory, the right to create a file in the directory.
FILE_ADD_SUBDIRECTORY For a directory, the right to create a
subdirectory.
FILE_ALL_ACCESS All possible access rights for a file.
FILE_APPEND_DATA For a file object, the right to append data to the file.
For a directory object, the right to create a subdirectory.
FILE_CREATE_PIPE_INSTANCE For a named pipe, the right to create a
pipe.
Permessi in Windows












FILE_DELETE_CHILD For a directory, the right to delete a directory and all
the files it contains.
FILE_EXECUTE For a native code file, the right to execute the file. This
access right given to scripts may cause the script to be executable, depending
on the script interpreter.
FILE_LIST_DIRECTORY For a directory, the right to list the contents of the
directory.
FILE_READ_ATTRIBUTES The right to read file attributes.
FILE_READ_DATA For a file object, the right to read the corresponding file
data. For a directory object, the right to read the corresponding directory data.
FILE_READ_EA The right to read extended file attributes.
FILE_TRAVERSE For a directory, the right to traverse the directory. By
default, users are assigned the BYPASS_TRAVERSE_CHECKING
privilege, which ignores the
FILE_TRAVERSE access right.
FILE_WRITE_ATTRIBUTES The right to write file attributes.
FILE_WRITE_DATA For a file object, the right to write data to the file. For
a directory
object, the right to create a file in the directory.
FILE_WRITE_EA The right to write extended file attributes. [...]
Vantaggi

Questa maggiore ricchezza di permessi di
utenti e di gruppi, assieme al meccanismo di
incapsulamento delle funzioni di sistema di
Win32, rende possibile eseguire molti dei
compiti usuali di amministrazione con
permessi non di root
Architettura


Ogni utente (gruppo, host e server) ha un SID :
è un numero che consiste di una breve
intestazione e di un intero lungo (univoco)
quando un utente inizia un processo, riceve un
SAT (Security Access Token)
SAT





Security ID: identifica un utente in maniera univoca.
Group SID: Una lista dei gruppi ai quali l’utente appartiene
ai fini del controllo degli accessi. Un gruppo è un insieme di
ID di utente. Ogni gruppo ha un unico SID.
Privilegi: Una lista di servizi di sistema “security sensitive”
che l’utente può chiamare. Esempio creare token.
Default owner: se l’utente genera un nuovo oggetto può
specificare se il proprietario dell’oggetto è l’utente stesso o
un gruppo cui l’utente appartiene.
Default ACL: lista iniziale di protezione associata agli
oggetti che l’utente crea. La lista può essere
successivamente modificata
Controllo

ogni volta che il processo chiede di usare una
risorsa, il S.O. usa


Il SAT del processo e
Il Security Descriptor della risorsa stessa
Security Descriptor




Flags: definiscono il tipo ed i contenuti di un descrittore.
 Esempio: se sono contenute o no SACL e DACL.
Owner:il proprietario dell’oggetto può essere un
individuo o un gruppo. Il proprietario può cambiare i
contenuti della DACL.
Discretionary Access Control List (DACL): determina
quali utenti e con quali operazioni possono accedere
all’oggetto.
 E’ costituita da una lista di access control entries
(ACEs).
System Access Control List(SACL):specifica quali tipi di
operazioni sull’oggetto generano audit messages.
ACE



Access Control Entry: contiene un SID
individuale o di gruppo e una maschera di
accesso che definisce i diritti che sono
garantiti al SID.
La maschera contiene quattro bit per indicare i
diritti di accesso di lettura, scrittura,
esecuzione e tutti i diritti.
Altri bit indicano ulteriori diritti
Esempio
file
SID
GSID
ACL
SACL
deny
pippo
111111
allow
franz
11000
allow
everyone
10000
audit
franz
111111
Scansione delle ACL

La scansione si ferma alla prima ACE in cui
corrisponde l’user o il group SID del processo che
chiede di usare la risorsa





se è DENY allora NO
altrimenti ci deve essere ALLOW dell’operazione richiesta
I DENY sono sempre all’inizio
per successive operazioni rivolte alla stessa risorsa si
usa la stessa ACE
Per default


ACL assente => accesso sempre permesso
ACL vuota => accesso sempre negato
File cifrati





in Windows NT il file system permette di crittare i
file mediante una chiave di 128 bit (diversa per ogni
file)
la chiave è usata per crittare il file (blocco a blocco)
la chiave cifrata con la chiave pubblica dell’utente è
inserita nel Registry
per decrifare il file c’è bisogno della chiave segreta
dell’utente
Se il file deve essere condiviso, la chiave di cifratura
è cifrata con le chiavi pubbliche di tutti gli utenti che
vi possono accedere
Cronologia di Unix





1960-70 MIT, Bell Labs e GE lavorano al S.O.
MULTICS
Bell lascia il progetto e Ken Thompson inizia
lo sviluppo di Unix
Sviluppato in C su PDP-11 ‘74
Portabilità attraverso quella del compilatore C
Networking con TCP/IP
Cronologia di Unix




release 2.0 di Linux in ‘96 0.5M
molto software viene portato su Linux
esiste una GUI (KDE)
Linux simile a Unix, condivide con
quest’ultimo circa l’80% delle chiamate di
sistema
Login e password




ogni utente autorizzato ha login e password ed
identificato con userID e groupID
le password sono criptate con una funzione one-way
sono contenute in un file (spesso /etc/passwd)
accessibile (rw) solo da root
questo file è separato da quello di profilo (spesso
/etc/profile) che contiene le azioni specifiche da
eseguire al login che è accessibile dall’utente
UID e GID


UID sono interi a 16 bit (0-65535)
UID speciali




0 = root,
1 = daemon (lp)
9 = audit
i GID sono simili:


0 = system
1 = daemon per device...
Utente Root

root può fare quasi tutto, tranne recuperare le
password (nessuno lo può fare)




può essere qualsiasi utente
può montare e smontare file systems decidendo gli
accessi consentiti
quindi root è anche un punto debole:
conviene separare i diversi compiti del system
manager usando altri utenti come daemon per
il networking
Punti importanti sulla sicurezza
in Unix


la politica degli accessi è espressa tramite
ACL semplificate
Il metodo per consentire ad un processo di
accedere a risorse per cui non avrebbe i
permessi è l’invocazione controllata
File system in Unix


Unix organizza i file in una struttura ad albero,
i nodi interni sono folder (comunque file) e le
foglie sono i file semplici
ogni file nella directory è un puntatore ad un inode che contiene varie informazioni

mode, link counter,uid, gid dell’owner,
time, block count, posizione fisica
ACL in Unix
12 bit ℓ
link counter
rwx
r--
r--
permessi permessi permessi di
dell’owner del gruppo tutti gli altri
dell’owner
Controllo delle ACL

quando un processo (UID e GID) chiede di
accedere un file:



i permessi vengono esaminati da sinistra a destra,
se UID è l’owner del file allora valgono i primi 3
bit
se il GID è quello dell’owner del file allora vale la
seconda terna
altrimenti vale la terza terna
Directory


ogni utente ha una home ed altre directory si
creano con mkdir
Le directory hanno permessi come i file ma
con i seguenti significati:



x= è richiesto per entrare (cd) nella directory e per
aprire file in essa (non si può fare ls)
w= creare e distruggere file
r= si può fare ls
Invocazione controllata



in Unix è possibile specificare che un
eseguibile E quando viene invocato da un
processo P non prende lo UID e GID di P bensì
quelli del creatore di E
se questo è root o un utente con privilegi
particolari allora questi vengono “prestati”
all’utente di P
un tale programma si chiama SETUID o
SETGID
Invocazione controllata


l’invocazione controllata è il modo in cui
UNIX media TUTTE le richieste di accesso
alle risorse
Per ogni richiesta avviene l’invocazione di un
processo di sistema eseguito come root (o
utente speciale) che controlla che la richiesta
sia autorizzata e, se lo è, esegue l’azione
richiesta e poi ritorna all’utente
Esempio


gestione di una stampante lp
/dev/lp



ma se definiamo un programma stampa(lp) che
accede alla stampante e tale che:



owner un daemon (lp)
ACL rw- --- --- nessuno a parte lp può usare la stampante
il suo owner sia il daemon lp
e sia SETUID,
allora ogni utente può usare la stampante e SOLO con
stampa(lp)
Invocazione ed incapsulamento


ogni utente può usare l’invocazione controllata per
ottenere incapsulamento
se l’utente U ha un file X che vuole proteggere, cioè
vuole che venga consultato solo con un dato
programma PX, allora può fare così:



crea utente UX owner di PX e di X (con permessi rw) e
rende PX SETUID
poi rende PX eseguibile da Y
Y eseguendo PX diventa UX e quindi può accedere a
X
SETUID

Un comando con SETUID root è passwd





cambia la password
deve accedere al file delle password crittate
Un altro è login
chmod 4/// nome --> SUID all’esecuzione
chmod 2/// nome --> SGID all’esecuzione
Processo di login







riceve login e passwd
codifica la passwd e controlla che sia corretta
nel profile trova l’ambiente (sh, csh, ksh…)
apre input e output standard
esegue setuid e setgid dell’utente
esegue la shell e termina
la shell continua con UID e GID giuste
1. ogni comando nella shell inizia un processo
che eredita la UID e GID della shell
2. ogni file che viene creato riceve quella UID e
GID
3. quando un processo tenta di accedere per la
prima volta ad un file la UID e GID sono
usate per controllare se l’accesso è consentito
4. il processo riceve un file descriptor e nelle
successive operazioni, non ci sono più
controlli
5. se il modo di un file cambia, il cambiamento
entra in effetto dopo la chiusura
Protezione delle device




sono come files e quindi hanno i loro permessi:
/dev/mem mappa della memoria fisica
/dev/kmem mappa della memoria virtuale
il system manager non deve lasciare permessi
pericolosi
Possono condurre ad attacchi al livello
sottostante
mount


mount serve per montare file systems:
offre opzioni di sicurezza



-r = read only
nosuid = mettere a 0 tutti i SUID e SGID bit
noexec = nessun binario può essere eseguito
Auditing

ricorda i fatti rilevanti per la sicurezza in un
file protetto:



per scoprire l’intrusione
per rispondere all’intrusione (pericoloso)
oltre a restringere l’accesso al file di log,
conviene mandarlo su altre macchine o
stamparlo
Auditing e SETUID


i programmi SETUID mettono in crisi
l’auditing perchè viene ricordato l’UID del
processo che è diverso da quello dell’utente
che richiede l’operazione
abbiamo visto che ci sono comandi del sistema
per risalire alla UID e GID reale


uid=getuid(), gid=getgid() // reale
uid=geteuid(), gid=getegid() // effettivo
Problemi con l’invocazione
controllata

Il meccanismo dell’invocazione controllata si
presta ad un attacco molto pericoloso ed usato
di frequente:


Stack overflow
L’intruder acquisisce i diritti di root e può
causare molti danni...
Access Control List in Unix



Al pari delle ultime versioni di Windows,
anche in Unix è possibile usare le ACL,
descritte secondo lo standard POSIX
Non tutte le versioni di Unix e di Linux
supportano tale standard
Comunque non tutte le applicazioni
controllano le ACL
Posix ACL

Tipi di ACL entry






Owner user::rwx
Named user user:name:rwx
Owning group group::rwx
Named group group:name:rwx
Mask mask::rwx
Others other::rwx
Posix ACL

ACL minime



Contengono solo tre entry
Sono equivalenti ai bit di permesso di UNIX
tradizionale
ACL estese



Hanno più di tre ACL entry
Contengono una mask entry
Possono contenere qualunque numero di named
user e di named group entries
Funzionamento delle ACL


Le ACL minime funzionano come al solito
Le ACL estese hanno il seguente funzionamento


Tutti i named user e i named group entrano a far parte della
classe group
Bisogna distinguire fra:



permessi della classe group
ACL entry della classe group
I permessi della classe group sono contenuti nella
maschera e rappresentano un "upper bound" ai permessi
che possono essere ottenuti dalle entry della classe gruppo
Esempio

Con i seguenti permessi






user::rw
group::r
others::r
user:jane:rwx
mask:rw
l’utente jane ha diritti rw
ACL di default

Come vengono ereditate le default ACL?



la default ACL viene copiata nella access ACL dei nuovi
file
la default ACL viene copiata nella default ACL delle nuove
directory
Ulteriori dettagli

quando un file viene creato



possono essere specificati dei diritti di accesso
viene effettuata l'intersezione tra questi e la default ACL
se una directory non ha default ACL, si utilizza il
meccanismo tradizionale UNIX (umask, etc.)
Intrusion detection


Un meccanismo estremamente importante da
utilizzare per controllare la sicurezza di un
sistema è quello degli IDS (Intrusion Detection
System)
Si può fare a livello di host (HIDS) e a livello
di network (NIDS)
Principi di base


Distinguere situazioni normali da quelle
anomale
L’utente in condizioni normali



si comporta in modo più o meno prevedibile
non compie azioni atte a violare la sicurezza
i propri processi compiono solo azioni permesse
Scopi di un IDS




Scoprire un ampia gamma di intrusioni, sia già
note che non note
Scoprirle velocemente, non necessariamente in
tempo reale
Presentare i report delle analisi in formato
semplice e facilmente comprensibile
Essere accurato, evitando possibilmente falsi
positivi e falsi negativi
Modelli per l’IDS

Detection di anomalie


Detection di uso malevolo


Si conosce cosa quali sequenze di azioni possono
essere intrusioni
Detection in base a specifiche


Sequenze di azioni non usuali possono essere
intrusioni
Si conoscono le situazioni derivanti da intrusioni
I modelli possono essere statici o adattivi
Modelli per la scoperta di anomalie

Si analizzano insiemi di caratteristiche del
sistema confrontando i valori con quelli attesi
e segnalando quando le statistiche non sono
paragonabili a quelle attese



Metriche a soglia
Momenti statistici
Modelli di Markov
Metriche a soglie

Contare il numero di volte che un evento si
presenta



Ci si aspetta tra m e n occorrenze
Se il numero cade al di fuori, c’è un’anomalia
Esempio

Windows: blocco dopo k tentativi di login falliti. Il
range è (0, k–1).

k o più tentativi destano sospetto
Problematiche


E’ difficile trovare l’intervallo corretto
Talvolta si possono creare situazioni in cui
l’intervallo diventa molto più grande

Esempio utenti francesi che usano una tastiera
americana
Momenti statistici

L’analizzatore calcola la deviazione standard (i
primi due momenti) o altre misure di
correlazione (momenti di ordine superiore)


Se i valori misurati di un certo momento cadono al
di fuori di un certo intervallo vi è un’anomalia
Problematiche

I profili possono evolvere nel tempo, si possono
“pesare” opportunamente i dati o alterare le regole
di detection
Esempio: IDES

Developed at SRI International to test Denning’s
model



Represent users, login session, other entities as ordered
sequence of statistics <q0,j, …, qn,j>
qi,j (statistic i for day j) is count or time interval
Weighting favors recent behavior over past behavior


Ak,j sum of counts making up metric of kth statistic on jth day
qk,l+1 = Ak,l+1 – Ak,l + 2–rtqk,l where t is number of log entries/total
time since start, r factor determined through experience
Example: Haystack



Let An be nth count or time interval statistic
Defines bounds TL and TU such that 90% of values for
Ais lie between TL and TU
Haystack computes An+1
Then checks that TL ≤ An+1 ≤ TU
 If false, anomalous
Thresholds updated



Ai can change rapidly; as long as thresholds met, all is well
Modelli di Markov



L’ipotesi è che la storia passata influenzi la prossima
transizione di stato
Le anomalie sono riconosciute da sequenze di eventi,
e non sulle occorrenze di singoli eventi
Il sistema deve essere addestrato per riconoscere
sequenze valide



l’addestramento è svolto con utenti non anomali
l’addestramento produce migliori risultati con una quantità
maggiore di dati
i dati dovrebbero coprire tutti le sequenze normali del
sistema
Esempio: TIM



Time-based Inductive Learning
Sequence of events is abcdedeabcabc
TIM derives the following rules:
R1: abc (1.0)
R4: de (1.0)

R3: ce (0.5)
R6: ed (0.5)
Seen: abd; triggers alert


R2: cd (0.5)
R5: ea (0.5)
c always follows ab in rule set
Seen: acf; no alert as multiple events can follow c

May add rule R7: cf (0.33); adjust R2, R3
Sequenze di chiamate di sistema



Forrest: definisce il normale andamento in
termini di sequenze di chiamate di sistema
(tracce)
Negli esperimenti è in grado di distinguere
sendmail e lpd da altri programmi
Si addestra il sistema con un insieme di tracce
e si cerca se la traccia corrente è anomala
Problematiche ulteriori

Modelli statistici



spesso si usa la distribuzione gaussiana
alternative sono clusterizzazione e tecniche non
parametriche
Selezione di feature


CPU versus I/O
selezione automatica
Modelli per il misuso



Si controlla se una sequenza di istruzioni da
eseguire è già nota essere potenzialmente
dannosa per la sicurezza del sistema
La conoscenza è rappresentata mediante regole
e il sistema controlla se la sequenza soddisfa
una di queste regole
Non si possono scoprire intrusioni non note
precedentemente
Esempi di IDS a regole



IDIOT monitorizza i log cercando sequenze di
eventi che corrispondono ad attacchi
STAT analizza le transizioni di stato,
concentrandosi sul modo come alcuni privilegi
sono ottenuti
NFR controlla il traffico di rete, analizzando e
filtrando i pacchetti
Modelli mediante specifiche

Si determina se una sequenza di azioni viola
una specifica di come un programma o un
sistema dovrebbe funzionare
Architettura di un IDS

E’ essenzialmente un sistema di auditing sofisticato



Agente è una sorta di logger; it gathers data for analysis
Direttore è un analizzatore; analizza i dati ottenuti dagli
agenti secondo regole interne
Notificatore ottiene i risultati dal direttore e compie alcune
azioni



Può semplicemente notificare messaggi agli amministratori
Può riconfigurare gli agenti
Può attivare meccanismi di risposta
Agente


Ottiene le informazioni e le invia al direttore
Può mettere le informazioni in altre forme




Preprocessing dei record per estrarre parti rilevanti
Può cancellare informazioni non necessarie
Il direttore può richiedere all’agente ulteriori
informazioni
Si distinguono in agenti host e agenti network
Direttore

Colleziona le informazioni inviate dagli agenti


Analizza le informazioni rimanenti per
determinare se si è sotto attacco


Elimina i record ridondanti o non necessari
Usa le tecniche viste prima
Gira su un sistema separato

Non influenza le performance dei sistemi
monitorati
Notificatore


Accetta le informazioni dal direttore
Prende le decisioni appropriate



Notificare messaggi agli amministratori
Rispondere all’attacco
Spesso usano delle GUI
Combining Sources: DIDS

I monitoraggi di host e di network non sono
generalmente sufficienti da soli a scoprire
alcuni tipi di attacchi



Un’attaccante prova a fare telnet con vari login: i
IDS network lo scoprono, ma non gli IDS host
L’attaccante prova entrare senza la password: gli
IDS host lo rilevano, ma non quelli di rete
DIDS usa gli agenti sugli host da monitorare
ed un monitor di rete
Risposte alle intrusioni


Prevenzione: l’attacco deve essere scoperto
prima del completamento
Una tecnica è il Jailing: far credere
all’attaccante che l’intrusione è andata a buon
fine ma confinare le sue azioni in un dominio
in cui non può fare danni (o causarne pochi)


far scaricare file corrotti o falsi
imitare il sistema vero
Risposta alle intrusioni

Trattamento delle intrusioni






preparazione
identificazione
contenimento (passivo/attivo)
eradicazione
recupero
seguito (apprendimento)
Sicurezza nei database


La protezione dei dati di un database necessita
di strumenti particolari, alcuni dei quali
mutuati da quelli usati in altri settori
Gli obiettivi sono comunque gli stessi



Integrità
Confidenzialità
Disponibilità
Requisiti di sicurezza







Integrità fisica del DB: immunità ai guasti di
sistema e di dispositivo
Integrità logica del DB: preservazione della
struttura del database
Integrità degli elementi: accuratezza dei dati
Auditability: tenere traccia delle operazioni
Controllo degli accessi
Autenticazione degli utenti
Disponibilità
Integrità del database


E’ garantita in gran parte dal DBMS, oltre che
dal S.O.
Strumenti fondamentali sono




log delle transazioni su memoria stabile
copie di backup effettuate regolarmente
Update a due fasi
Meccanismi standard


ripresa a caldo
ripresa a freddo
Integrità degli elementi



Controllo della corrispondenza tra i tipi dei
campi e i valori
Controllo degli accessi
Log dei cambiamenti
Auditability

Tenere traccia delle operazioni svolte sul DB
ha un duplice scopo



garantire l’integrità fisica del DB
accesso incrementale ai dati
Problemi nella granularità delle operazioni da
tracciare
Controllo degli accessi



Normalmente i database relazionali usano
sistemi DAC per il controllo degli accessi
La primitiva GRANT permette di concedere
diritti su tabelle agli utenti
I diritti standard sono





SELECT
INSERT
UPDATE
DELETE
REFERENCES
Controllo degli accessi

E’ possibile specificare la clausola WITH
GRANT OPTION



il diritto può essere propagato
Il diritto può essere revocato con la primitiva
REVOKE
I diritti solitamente sono memorizzati (insieme
agli altri metadati) nelle tabelle di sistema
Controllo degli accessi




Come nei SO, anche nei DB esiste il concetto
di amministratore: l’utente DBA
Ha il diritto di creare e cancellare utenti
Ha il diritto di accesso a tutto il database
Può concedere e revocare diritti al pari del
possessore
Controllo degli accessi


Alcuni DBMS, tra cui PostgreSQL,
consentono l’uso di RBAC
E’ possibile creare dei ruoli




ruolo utente
ruolo gruppo
I diritti si assegnano al ruolo
Si può assegnare il diritto ad assumere un
ruolo
Uso delle viste


E’ possibile creare delle viste per restringere
l’accesso solo ad alcuni dati di una tabella
E’ possibile quindi rendere accessibile a
determinati utenti solo la vista e non la tabella
da cui proviene
Autenticazione degli utenti



Gli utenti sono autenticati con meccanismi
simili a quelli visti per i S.O.
I DBMS di solito non si fidano
dell’autenticazione del S.O., la effettuano
autonomamente
Le informazioni degli utenti sono memorizzate
nelle tabelle di sistema
Disponibilità

La disponibilità deve essere garantita
disciplinando opportunamente gli accessi
concorrenti ed evitando che un processo
“maligno” monopolizzi il DB
Dati sensibili


I database possono contenere dati sensibili, che
non dovrebbe essere accessibili al pubblico
Un problema sorge quando i dati sensibili sono
una parte dei dati, ad esempio



alcuni record di una tabella
alcuni campi di una tabella
Possono esistere vari gradi di sensibilità a
seconda del motivo per cui il dato è dichiarato
sensibile
Accesso ai dati sensibili

Livelli in base alla sicurezza e alla precisione





Non disclosed
Non può essere trovato attraverso altre query
Potrebbe essere recuperato da altre query
Restituito come risultato
Problema dell’inferenza
Tipi di disclosure





Dato esatto: x vale 12
Limiti inferiori o superiori: x è compreso tra
10 e 15
Risposte negative: x non vale 11
Esistenza: Caio possiede un cellulare
Valore probabile: x vale 10 con probabilità
0.25
Problema dell’inferenza


E’ possibile ottenere dati sensibili attraverso
l’uso di query opportune che non producono
dati sensibili
Tale problema è sentito nei database statistici


fornire pubblicamente dati aggregati a scopi
statistici
evitare l’accesso ai singoli record
Esempio
Name
Position
Salary
Age
Matt
Teacher
50K
33
Leonard
Teacher
50K
50
Holly
Principal
60K
37
Heidi
Aide
20K
20
Celia
Teacher
40K
45
Esempio


SELECT SUM(SALARY) WHERE
POSITION=‘TEACHER’ si può eseguire
senza problemi
poi SELECT SUM(SALARY) WHERE
POSITION=‘TEACHER’ AND AGE > 40 non
si può eseguire perchè (per differenza con la
prima) troviamo lo stipendio di Matt
Soluzione


La soluzione è quella di tenere traccia di tutte
le interrogazioni effettuate e di proibire le
interrogazioni che conducono, tramite i
risultati di quelle precedenti, ad accedere ai
dati di uno (o pochi) record
Esistono metodi per inferire dati da somme,
medie, conteggi, mediane, ecc.
Altre soluzioni

Un altro approccio è quello di usare dati
opportunamente modificati prima di calcolare
le query



esclusione di alcuni dati
campionamento casuale
perturbazione casuale dei dati
Database multilivello




Si supera la distinzione binaria tra dati
sensibili e non sensibili
Ogni singolo dato del DB può avere un grado
di sicurezza
Una tupla può essere vista come
<v1, c1, v2, c2, ..., vn, cn, ct>
I ci rappresentano il livello di sicurezza del
dato vi e ct il livello di sicurezza dell’intera
tupla
Esempio
Nome
Età
Rossi U
27
C
10K
S
A
C
Verdi U
30
C
20K
S
C
TS
Neri U 42
Bond TS 35
C
TS
100K
85K
TS A
TS A
C
TS
Gialli U
C
120K
TS A
C
50
Stip.
Cred.
Si usa il modello di Bell-La Padula (U<C<S<TS)
Esempio

La tabella in lettura per un utente C è
Nome
Rossi U
Età
27
C
Stip.
10K
Verdi U
Neri U
Gialli U
Cred.
A
S
30
C
20K
S
TS
42
50
C
C
TS A
TS A
C
C
C
Esempio


La stessa tabella può essere vista in modi
diversi a seconda del grado di sicurezza
dell’utente
Allo stesso modo si dovranno controllare gli
accessi in scrittura (proprietà * del modello di
Bell-La Padula): ad esempio un utente TS non
può scrivere un dato con sicurezza S, C o U
Realizzazione

Esistono vari modi per realizzare un database
multilivello



Partizionamento: le tabelle sono memorizzate (e
utilizzate) separatamente
Cifratura di campi sensibili
Marcatura con lock di integrità