Slide

Elemen& di Sicurezza & Privatezza Lezione 6-­‐7 -­‐ I meccanismi di protezione offer& da un sistema opera&vo: autorizzazione e controllo degli accessi A.A. 2011/2012 1 Corso: Sicurezza & Privatezza © Danilo Bruschi B. Lampson “… there are three basic mechanisms for implemen&ng security. Together, they form the gold standard for security (since they all begin with Au): •  Authen%ca%ng principals, answering the ques&on “Who said that?” or “Who is geXng that informa&on?”. Usually principals are people, but they may also be groups, machines, or programs. •  Authorizing access, answering the ques&on “Who is trusted to do which opera&ons on this object?”. •  Audi%ng the decisions of the guard, so that later it’s possible to figure out what happened and why. A.A. 2011/2012 2 Corso: Sicurezza & Privatezza © Danilo Bruschi Terminologia di riferimento •  SoggeX (subjects): en&tà aXve •  uten&, processi, ... •  OggeX (objects): en&tà passive •  file o risorse •  Operazioni di Accesso (rights): accesso a memoria (read, write), accesso a file, invocazione di metodi in un sistema a oggeX A.A. 2011/2012 3 Corso: Sicurezza & Privatezza © Danilo Bruschi USER e PRINCIPAL (R. Sandhu) PRINCIPAL USER Real World User Unit of Access Control and Authoriza&on Il sistema auten&ca un utente facendo riferimento ad un principal A.A. 2011/2012 4 Corso: Sicurezza & Privatezza © Danilo Bruschi USER e PRINCIPAL JOE.TOP-­‐SECRET JOE.SECRET JOE JOE.CONFIDENTIAL JOE.UNCLASSIFIED USER A.A. 2011/2012 PRINCIPALS 5 Corso: Sicurezza & Privatezza © Danilo Bruschi USER e PRINCIPAL •  L’associazione USER à Principal dovrebbe essere del &po uno-­‐a-­‐mol& •  Un utente può avere più principal associa& •  Ogni principal deve essere associato ad un unico utente •  In questo modo è possibile profilare con precisione le aXvità di un utente A.A. 2011/2012 6 Corso: Sicurezza & Privatezza © Danilo Bruschi PRINCIPAL e SUBJECT •  Un soggeio è un processo eseguito su richiesta di un principal •  In un certo istante t un principal può essere idle, o avere più soggeX, ad esso riconducibili, in esecuzione A.A. 2011/2012 7 Corso: Sicurezza & Privatezza © Danilo Bruschi PRINCIPAL e SUBJECT Mail Applica&on Word Processor JOE.TOP-­‐SECRET Spreadsheet Database Applica&on PRINCIPAL A.A. 2011/2012 SUBJECTS 8 Corso: Sicurezza & Privatezza © Danilo Bruschi PRINCIPAL e SUBJECT •  Di solito (ma non sempre) •  Ogni soggeio è associato ad un solo principal •  TuX i soggeX di un principal hanno gli stessi diriX •  In questo caso l’associazione subject à principal è un’associazione uno-­‐a-­‐uno, ed I due conceX possono essere assimila& A.A. 2011/2012 9 Corso: Sicurezza & Privatezza © Danilo Bruschi Poli&ca di Sicurezza •  Poli&ca di sicurezza è un termine usato in diversi ambi& e che denota documen& di varia natura, tra i mo& significa& che assume vi è anche quello di documento o modalità che: •  Definisce per ogni soggeio di un dato sistema le operazioni che può svolgere su ciascun oggeio del sistema stesso A.A. 2011/2012 10 Corso: Sicurezza & Privatezza © Danilo Bruschi Confiden&ality Policy •  Regolamenta: •  La classificazione dell’informazione •  L’accesso all’informazione •  Trasferimento delle informazioni ed eventualmente dei diriX di accesso •  La modifica nel tempo dei diriX di accesso •  Molto diffuse in ambi& militari/gov. A.A. 2011/2012 11 Corso: Sicurezza & Privatezza © Danilo Bruschi Integrity Policy •  Definisce come può essere modificata l’informazione •  Le en&tà che possono modificare i da& •  Le condizioni che regolano la modifica dei da& •  I &pi di modifiche concessi •  Esempi: •  Acquis& che superano €1000 devono essere vidima& dal responsabile •  Separa%on of du%es •  Sviluppate principalmente in ambi& commerciali A.A. 2011/2012 12 Corso: Sicurezza & Privatezza © Danilo Bruschi Availability Policy •  Descrivono i servizi che devono essere forni& e le modalità con cui gli stessi devono essere eroga& •  Il servizio di posta eleironica deve essere erogato ai soli uten& interni, e rimanere aXvo 24x7 ad eccezione di due ore richieste per la manutenzione svolta la domenica pomeriggio A.A. 2011/2012 13 Corso: Sicurezza & Privatezza © Danilo Bruschi Security Mechanism •  Meccanismo •  Un disposi&vo o una procedura che forza il sistema a comportarsi coerentemente a quanto specificato nella poli&ca o in parte di essa •  Esempio: •  Poli&ca: gli studen& non devono copiare i loro homework •  Meccanismo: disabilita l’accesso ai file di un utente da parte di tuX gli altri uten& A.A. 2011/2012 14 Corso: Sicurezza & Privatezza © Danilo Bruschi Operazioni di accesso •  Bell-­‐LaPadula definiscono 4 diriX di accesso • 
• 
• 
• 
execute read append, nota anche come blind write write •  Una possibile correlazione con le operazioni precedentemente definite è execute append observe alter A.A. 2011/2012 X 15 read X write X X Corso: Sicurezza & Privatezza © Danilo Bruschi Operazioni di accesso: Unix •  Operazioni di accesso applicate ad una •  read: di un file directory •  Tre operazioni di accesso •  read: lista dei file •  write: crea o rinomina file della directory •  execute: cerca file nella directory •  write: su un file •  execute: un file A.A. 2011/2012 16 Corso: Sicurezza & Privatezza © Danilo Bruschi Chi definisce le poli&che? •  Chi decide le poli&che? Tre schemi: •  DAC (Discre&onary access control): ciascun proprietario (owner) di una risorsa decide chi e come può accedere alla risorsa stessa. •  MAC (Mandatory Access Control): esiste una poli&ca a livello centralizzato che stabilisce tuio per tuX. •  RBAC(Role Based Access Control): gli accessi agli oggeX di un sistema sono deia& da regole che dipendono dai ruoli che gli uten& ricoprono all’interno del sistema (studente, docente) A.A. 2011/2012 17 Corso: Sicurezza & Privatezza © Danilo Bruschi Come rappresen&amo una poli&ca? •  Il SO deve applicare le poli&che di sicurezza a questo proposito vanno individuate opportune struiure che: •  Consentano di definire con precisione le operazioni di accesso (access rights) per ogni coppia soggeio-­‐oggeio •  Possano essere facilmente ed efficientemente u&lizzate in sistemi con un elevato numero di sogge&-­‐oggeX A.A. 2011/2012 18 Corso: Sicurezza & Privatezza © Danilo Bruschi Matrice degli accessi •  Consente di specificare per ogni coppia soggeio-­‐oggeio le operazioni di accesso consen&te: • 
• 
• 
• 
• 
A.A. 2011/2012 S : insieme dei soggeX O : insieme degli oggeX A : insieme delle operazioni di accesso Matrice: M = (Mso)s∈S,o∈O Ogni elemento di M specifica le operazioni che il soggeio s può eseguire sull oggeio o 19 Corso: Sicurezza & Privatezza © Danilo Bruschi Matrice degli Accessi O1
O2
O3
S1
S2
S3
S1
Own
S4
A.A. 2011/2012 Write
Read
Write
S2
S3
Execute
Append
Own
Execute
Read
execute
Read
20 Corso: Sicurezza & Privatezza © Danilo Bruschi Matrice degli Accessi •  La matrice degli accessi è: •  Un conceio astraio, •  Un u&le strumento teorico •  Non adaia per essere direiamente implementata e quindi poco adaia per la ges&one della sicurezza A.A. 2011/2012 21 Corso: Sicurezza & Privatezza © Danilo Bruschi Capability •  Focus sul soggeio: •  DiriX di accesso memorizza& con i soggeX •  capability ≡ righe della matrice degli accessi •  SoggeX possono assegnare diriX ad altri soggeX •  SoggeX possono assegnare il diriio di assegnare diriX •  Cri&cità •  Come verifico chi può accedere ad uno specifico oggeio? •  Come revoco un diriio di accesso ad un oggeio? A.A. 2011/2012 22 Corso: Sicurezza & Privatezza © Danilo Bruschi Access Control List (ACL) •  Focus sugli oggeX: •  I diriX di accesso sono memorizza& insieme ad un oggeio •  ACLs ≡ colonne delle matrice degli accessi •  Implementate nella maggior parte dei SO commerciali, anche se in versioni semplificate Cri&cità: •  Come iden&fichiamo i diriX di accesso di un soggeio? •  Nella definizione di poli&che di sicurezza è più naturale fare riferimento ai soggeX A.A. 2011/2012 23 Corso: Sicurezza & Privatezza © Danilo Bruschi Gruppi •  Associare un elevato numero di uten& alla stessa ACL può essere molto noioso •  È solitamente possibile accorpare nomi di uten& equivalen& dal punto di vista dei diriX di accesso ad un oggeio, in gruppi, e inserire i nomi dei gruppi all interno delle ACL A.A. 2011/2012 24 Corso: Sicurezza & Privatezza © Danilo Bruschi Gruppi & Negazioni •  I Gruppi sono un livello intermedio tra uten& e oggeX users!
groups!
objects!
•  In alcuni casi sono introdoie le negazioni per ridurre i diriX di qualche partecipante al gruppo users!
groups!
objects!
A.A. 2011/2012 25 Corso: Sicurezza & Privatezza © Danilo Bruschi Ruoli •  In alcune applicazioni par&colari vi possono essere operazioni di accesso molto più complesse di read/write/delete •  Queste operazioni sono definite airaverso procedure che possono essere applicate a oggeX con un certo &po •  Un ruolo è una collezione di procedure assegnate a uten& •  Un utente può avere più ruoli, e lo stesso ruolo può appartenere a più uten& •  RBAC controllo degli accessi &pico del livello applicazioni A.A. 2011/2012 26 Corso: Sicurezza & Privatezza © Danilo Bruschi Audit log •  Anche il sistema configurato con maggiore accuratezza può essere oggeio di un intrusione •  In questo caso è indispensabile possedere il maggior numero di informazioni sullo stato del sistema nel momento dell’intrusione •  Il S.O fornisce queste informazioni airaverso i file di log •  Audit è l’operazione di controllare i file di log ai fini di individuare operazioni anomale A.A. 2011/2012 27 Corso: Sicurezza & Privatezza © Danilo Bruschi Audi&ng •  Contribuisce a rilevare o individuare le cause (post-­‐mortem) di un tenta&vo di violazione della poli&ca di sicurezza (security breach) •  Si traia di memorizzare in forma più o meno deiagliata gli even& più significa&vi in fase di auten&cazione e autorizzazione •  L’operazione è svolta a due livelli: •  Sistema •  Applicazione A.A. 2011/2012 28 Corso: Sicurezza & Privatezza © Danilo Bruschi Il modello di riferimento autorizzazione ACL soggeio richiesta Reference Monitor oggeio Log A.A. 2011/2012 29 Corso: Sicurezza & Privatezza © Danilo Bruschi Security Audi&ng Policies •  Il numero di even& “cri&ci” da memorizzare è potenzialmente molto grande •  Le poli&che di audi&ng devono individuare, in questo insieme gli even& più cri&ci e significa&vi, per un certo ambito •  Il problema principale da considerare è la non repudia&on degli even& memorizza& A.A. 2011/2012 30 Corso: Sicurezza & Privatezza © Danilo Bruschi CASO DI STUDIO: MECCANISMI DI PROTEZIONI IN UNIX A.A. 2011/2012 31 Corso: Sicurezza & Privatezza © Danilo Bruschi Introduzione •  Analizziamo i principali meccanismi di protezione messi a disposizione dalle versioni standard di UNIX considerando i seguen& aspeX: •  Processo di iden&ficazione/auten&cazione •  Sistema per il controllo dell esecuzione del codice privilegiato •  Sistema di controllo degli accessi •  Sistema di audit/monitoring A.A. 2011/2012 32 Corso: Sicurezza & Privatezza © Danilo Bruschi Iden&ficazione •  Gli uten& sono iden&fica&, al momento del login, airaverso uno user name che può contenere sino a 8 caraieri •  Nell ambito del sistema opera&vo ogni utente viene invece iden&ficato con un numero intero (16 bit) chiamato user id o UID A.A. 2011/2012 33 Corso: Sicurezza & Privatezza © Danilo Bruschi Auten&cazione •  Il meccanismo di auten&cazione adoiato da Unix è la password (in alcune versioni limitata a 8 caraieri) •  La password è memorizzata in forma cifrata (crypt(3)) nel file /etc/shadow •  Password uguale a blank significa no password •  Password uguale a * significa che l’utente non può effeiuare il login A.A. 2011/2012 34 Corso: Sicurezza & Privatezza © Danilo Bruschi /etc/passwd username:passwd:UID:GID:full_name:directory:shell!
root:x:0:0:Herr und Meister:/root:/bin/bash!
bin:*:1:1:bin:/bin:/bin/bash!
daemon:x:2:2:daemon:/sbin:/bin/bash!
Lp:*:4:7:lp daemon:/var/spool/lpd:/bin/bash!
News:*:9:13:News system:/etc/news:/bin/bash!
Uucp:*:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash!
at:x:25:25::/var/spool/atjobs:/bin/bash!
wwwrun:x:30:65534:Daemon user for apache:/tmp:/bin/bash!
squid:x:31:65534:WWW proxy squid:/var/squid:/bin/bash!
ftp:x:40:2:ftp account:/usr/local/ftp:/bin/bash!
firewall:x:41:31:firewall account:/tmp:/bin/false!
named:x:44:44:Nameserver Daemon:/var/named:/bin/bash!
tapico:x:501:100:Thomas Prizzi:/home/tapico:/bin/bash!
A.A. 2011/2012 35 Corso: Sicurezza & Privatezza © Danilo Bruschi /etc/shadow username:passwd:last:may:must:warn:expire:disable:reserved!
root:$1$CQoPk7Zh$370xDLmeGD9m4aF/ciIlC.:14425:0:99999:7:::
bin:*:14425:0:99999:7:::
daemon:*:14425:0:99999:7:::
adm:*:14425:0:99999:7:::
lp:*:14425:0:99999:7:::
sync:*:14425:0:99999:7:::
shutdown:*:14425:0:99999:7:::
halt:*:14425:0:99999:7:::
mail:*:14425:0:99999:7:::
news:*:14425:0:99999:7:::
uucp:*:14425:0:99999:7:::!
A.A. 2011/2012 36 Corso: Sicurezza & Privatezza © Danilo Bruschi Superuser •  Ogni sistema Unix prevede l esistenza di almeno un utente privilegiato il cui nome è root con UID=0 noto anche come superuser •  Quando opera il superuser tuX i controlli di sicurezza sono disabilita& •  Il superuser può svolgere in un sistema Unix quasi tuie le aXvità A.A. 2011/2012 37 Corso: Sicurezza & Privatezza © Danilo Bruschi Superuser •  L account di root è u&lizzato: •  Dal sistema opera&vo per svolgere una serie di aXvità: ges&one file, ges&one memoria, ges&one processi, ges&one processo di login, ecc. ecc. •  Dall amministratore di sistema: per la ges&one degli account, per la configurazione dei servizi, ecc. ecc. A.A. 2011/2012 38 Corso: Sicurezza & Privatezza © Danilo Bruschi Superuser •  È buona norma per l amministratore di sistema non usare l account di root per accedere al sistema •  È possibile da ogni account diventare root, conoscendo al rela&va password, usando il comando su A.A. 2011/2012 39 Corso: Sicurezza & Privatezza © Danilo Bruschi Gruppi •  Due o più uten& che condividono gli stessi privilegi possono essere accorpa& in un gruppo •  I gruppi hanno un nome e un iden&fica&vo numerico (GID), quest ul&mo è contenuto nei record del file /
etc/passwd •  I gruppi sono defini& nel file /etc/group •  In alcune versioni di Unix un utente può appartenere solo ad un gruppo A.A. 2011/2012 40 Corso: Sicurezza & Privatezza © Danilo Bruschi /etc/group root:x:0:root!
bin:x:1:root,bin,daemon!
daemon:x:2:root,bin,daemon!
sys:x:3:root,bin,adm!
adm:x:4:root,adm,daemon!
tty:x:5:!
disk:x:6:root!
lp:x:7:daemon,lp!
mem:x:8:!
kmem:x:9:!
wheel:x:10:root,wpollock,rabaut!
mail:x:12:mail,postfix!
A.A. 2011/2012 41 Corso: Sicurezza & Privatezza © Danilo Bruschi Controllo degli accessi •  Il sistema di controllo degli accessi in Unix è basato sull’approccio DAC con ACL •  TuX gli oggeX del sistema sono file •  I soggeX sono tuX i processi riconducibili ad un utente presente nel file /etc/passwd •  Le operazioni eseguibili su un file sono: •  Read (r) •  Write (w) •  Execute (x) A.A. 2011/2012 42 Corso: Sicurezza & Privatezza © Danilo Bruschi Accessi ai file •  Per rendere più ges&bili le ACL, dato un oggeio, l’insieme dei soggeX è par&zionato in tre categorie: il proprietario dell’oggeio, il suo gruppo di appartenenza e il resto del mondo •  Ad un file sono associate diverse informazioni per effeiuare il controllo degli accessi: permissions links owner group size date time name!
drwxr-xr-x 26 root bin 2048 Feb 11 20:35 . -rwxr--r-- 1 root bin 11023 Feb 10 20:25 INSTALL!
A.A. 2011/2012 43 Corso: Sicurezza & Privatezza © Danilo Bruschi Accessi ai file •  I permessi di accesso sono rappresenta& come una stringa di 9 caraieri logicamente suddividibili in 3 gruppi: •  Il primo gruppo esprime le modalità di accesso per l owner •  Il secondo esprime le modalità di accesso per il gruppo •  Il terzo esprime le modalità di accesso per il resto del mondo •  Es.: -­‐ rwx r-­‐x r-­‐-­‐ A.A. 2011/2012 44 Corso: Sicurezza & Privatezza © Danilo Bruschi Accessi ai file •  Si è soli& considerare la suddeia stringa come una stringa di tre terzeX di bit e quindi rappresentarla sinte&camente airaverso tre cifre oiali •  Es.: •  r-­‐x-­‐w-­‐r-­‐-­‐ corrisponde a 524 A.A. 2011/2012 45 Corso: Sicurezza & Privatezza © Danilo Bruschi Protezioni delle risorse •  Le risorse del sistema come: stampan&, memoria, terminali sono controllate, come per i file, airaverso l opportuna configurazione dei bit di controllo •  Ques& oggeX sono infaX rappresenta& nel sistema airaverso i seguen& file: • 
• 
• 
• 
/dev/console /dev/mem /dev/kmem /dev/iy A.A. 2011/2012 46 Corso: Sicurezza & Privatezza © Danilo Bruschi Protezione delle risorse •  Se i bit di protezione di /dev/mem sono rwx-­‐-­‐-­‐rw-­‐ sarà possibile per un qualunque utente accedere al contenuto della memoria •  /dev/iy: ne viene generata una copia al momento della login. Se fosse RW per il resto del mondo, ogni utente del sistema potrebbe accedervi e interceiare le operazioni svolte crw-rw-rwcrw-rw-rwcrw--w---crw--w---crw-rw-rw-
1
1
1
1
1
root
root
dbruschi
dbruschi
root
wheel
wheel
tty
tty
wheel
4,
4,
16,
16,
4,
A.A. 2011/2012 47 47
48
0
1
49
19
19
19
19
19
Mar
Mar
Mar
Mar
Mar
10:33
10:33
16:58
16:56
10:33
ttyrf!
ttys0!
ttys000!
ttys001!
ttys1!
Corso: Sicurezza & Privatezza © Danilo Bruschi Directory •  Nel caso di directory (par&colari &pi di file) le modalità di accesso assumono i seguen& significa&: •  Read: consente di elencare i file presen& nella directory •  Write: consente di aggiungere o eliminare file dalla directory •  Execute: consente di accedere ai file presen& nella directory A.A. 2011/2012 48 Corso: Sicurezza & Privatezza © Danilo Bruschi Controllo degli accessi in Unix •  Dominio di protezione: un insieme di coppie (oggeio, diriX) ognuna delle quali specifica l'oggeio e il soioinsieme delle operazioni su di esso autorizzate •  In Unix una coppia <UID, GID> iden&fica un dominio di protezione, caraierizzato da tuX gli oggeX (file) con lo stesso UID e GID A.A. 2011/2012 49 Corso: Sicurezza & Privatezza © Danilo Bruschi Controllo degli accessi in Unix •  In fase di creazione un processo eredita UID e GID (deX Real UID e GID) dell’utente che lo ha creato, ques& da& determinano il suo dominio di protezione •  Durante l’esecuzione un processo può però avere la necessità di accedere a risorse al di fuori del suo dominio (stampan&, video, directory, ecc.) •  Per consen&re ques& accessi è necessaria una modifica (temporanea) del dominio di protezione A.A. 2011/2012 50 Corso: Sicurezza & Privatezza © Danilo Bruschi SETUID •  Per consen&re questa modifica si introducono due varian& al modello sopra descriio: •  BIT S su file •  Effec&ve UID, GID •  Accanto a real UID e GID si introducono altri due valori: effec&ve UID e GID •  Il dominio di protezione di un processo è determinato dai valori di effec&ve UID e GID A.A. 2011/2012 51 Corso: Sicurezza & Privatezza © Danilo Bruschi File con BIT S •  Si traia di programmi che quando accedu& modificano l’effec&ve uid (gid) del processo che li esegue, ponendolo uguale a quello del loro proprietario (&picamente root) •  Ques& file sono facilemente riconoscibili perché nei terzeX rela&vi all owner e/o al gruppo la posizione riservata alla modalità di esecuzione può assumere anche il valore s cioè: r-­‐s-­‐ws-­‐-­‐-­‐-­‐ -r-xr-xr-x
-r-sr-xr-x
-r-xr-xr-x
-r-sr-xr-x
A.A. 2011/2012 1
1
1
1
root
root
root
root
wheel
wheel
wheel
wheel
238576
134816
50784
93376
52 12
12
12
25
Ott
Ott
Ott
Giu
2010
2010
2010
2010
pax!
ps!
pwd!
rcp!
Corso: Sicurezza & Privatezza © Danilo Bruschi Log File • 
• 
• 
• 
System oriented Applica&on specific Varian& in funzione delle versioni UNIX Memorizza& nelle directory /var/adm/ o /var/
log A.A. 2011/2012 53 Corso: Sicurezza & Privatezza © Danilo Bruschi File di log •  /usr/adm/lastlog: con&ene informazioni sull’ul&ma login effeiuata da ciascun utente •  /var/adm/utmp: indica gli uten& aiualmente connessi si legge con il comando who!
•  /var/adm/wtmp: archivio storico che &ene traccia di tuX i login/logout effeiua& sul sistema, si legge con il comando last!
•  /var/adm/acct: memorizza tuX i comandi svol& sul sistema •  Syslog logging facility fornita da mol& sistemi Unix che consente a diverse applicazioni di sistema di memorizzare i propri log in apposi& file defini& in fase id configurazione (/
etc/syslog.conf) A.A. 2011/2012 54 Corso: Sicurezza & Privatezza © Danilo Bruschi Syslog •  I sistemi unix usano il demone standard syslogd (rfc3164) per definire cosa e dove inviare i messaggi genera& dai servizi e dalle applicazioni •  La maggior parte degli appara& di rete è in grado di inviare i propri messaggi di diagnos&ca tramite il protocollo syslog •  Non tuie le applicazioni però supportano l’invio dei messaggi via syslog •  Generalmente i log risiedono sul sistema che li genera! A.A. 2011/2012 55 Corso: Sicurezza & Privatezza © Danilo Bruschi Altri file di log •  Accanto a ques& file di log di sistema vanno considera& anche quelli genera& da altre applicazioni: • 
• 
• 
• 
• 
• 
• 
• 
An&virus Firewall Router IDS Server Web Mail server TCP dump … A.A. 2011/2012 56 Corso: Sicurezza & Privatezza © Danilo Bruschi Verso log centralizza& •  Definire su ogni sistema le poli&che per la ges&one dei log •  Cosa, Come, Dove e per quanto tempo mantenere i log •  Dover accedere sul sistema interessato per analizzare i log •  Nel caso di servizi ridonda& (es: hip, proxy, smtp, etc.) occorre verificare i log su tuX i server che offrono lo stesso servizio •  Maggiore difficolta’ nell’analisi, report e archiviazione •  Possibili “DOS” che puntano al blocco di un servizio per esaurimento dello spazio disco (se i log sono sul disco sistema…) •  I log sono modificabili da eventuali intrusi… •  Ogni cambio di poli&ca comporta dover riconfigurare tuX i sistemi! A.A. 2011/2012 57 Corso: Sicurezza & Privatezza © Danilo Bruschi Log Server •  Server dedicato a collezionare tuX i file di log significa&vi sul sistema •  Spesso i file di log sono cataloga& adoiando opportuni parser •  È oramai prassi quella di u&lizzare DBMS (mysql, postgres, Oracle, ecc.) per memorizzare in modo sistema&co le informazioni contenute nei file di log A.A. 2011/2012 58 Corso: Sicurezza & Privatezza © Danilo Bruschi Log Analyzer: logrep A.A. 2011/2012 59 Corso: Sicurezza & Privatezza © Danilo Bruschi Log analyzer: Lire A.A. 2011/2012 60 Corso: Sicurezza & Privatezza © Danilo Bruschi Log Analyzer: Epylog A.A. 2011/2012 61 Corso: Sicurezza & Privatezza © Danilo Bruschi Log Analyzer Commerciali A.A. 2011/2012 62 Corso: Sicurezza & Privatezza © Danilo Bruschi Tool di supporto •  La configurazione di un sistema rispeiando correiamente i parametri di sicurezza è molto difficile •  Per supportare gli amministratori di sistema in questo compito sono sta& sviluppa& alcuni tool automa&ci di vulnerability assessment (security scanner) A.A. 2011/2012 63 Corso: Sicurezza & Privatezza © Danilo Bruschi Vulnerability Scanners •  Sono so~ware applica&vi che analizzano un sistema al fine di individuarne le vulnerabilità note •  Creano report e suggerimen& •  Il primo vulnerabiliry scanner è stato SATAN agli inizi degli anni 1990s •  ProdoX più recen& sono •  SARA – un’evoluzione di SATAN (UNIX) •  SAINT – un prodoio comerciale(UNIX) •  Nessus – fornisce un linguaggio di script per scrivere e condividere security tes&ng (UNIX, Linux) •  Microso~ Baseline Security Analyzer – da Microso~, aggiornato con il database delle vulnerabilità più recen& 64 Penetra&on Tes&ng •  Penetra&on tes&ng è un’aXvità di &po preven&vo usata in fase di audi&ng •  Si prova a soioporre il sistema ad una serie di aiacchi al fine di individuarne vulnerabilità •  Esistono oggi professionis& dedica& allo svolgimento di penetra&on test •  White hat •  Lo svolgimento di un penetra&on tes&ng richiede un’autoirzzazione esplicita da parte del propietario del sistema “viXma” 65 Integrity Checking •  Integrity checking •  Man&ene un database con tuX gli hash degli oggeX cri&ci del sistema •  Tripwire è il prodoio principalmente usato in questo contesto •  Usato per file o sistemi in cui è possibile inviduare un nucleo significa&vo di oggeX sta&ci 66 MECCANISMI DI PROTEZIONE IN WINDOWS A.A. 2011/2012 67 Corso: Sicurezza & Privatezza © Danilo Bruschi Introduzione •  Analizziamo i principali meccanismi di protezione messi a disposizione da W2K in relazione ai seguen& aspeX: •  Processo di iden&ficazione/auten&cazione •  Sistema di controllo degli accessi •  Sistema di audit/monitoring A.A. 2011/2012 68 Corso: Sicurezza & Privatezza © Danilo Bruschi Domini •  Dominio: un insieme di macchine e uten& che vengono accorpa& per oXmizzare e rendere più sicura la loro ges&one •  Domain controller (PDC): una macchina che fornisce i servizi di sicurezza a tuX i sistemi del dominio •  Un domain può avere più di un PDC •  Local Security Authority (LSA): la componente di sistema opera&vo che opera localmente e genera il SID in caso di logon locale A.A. 2011/2012 69 Corso: Sicurezza & Privatezza © Danilo Bruschi Principal •  Nel contesto del controllo degli accessi in windows le en&tà aXve sono indicate come principal e possno essere: • 
• 
• 
• 
• 
Uten& locali Uten& di dominio Gruppi Alias macchine A.A. 2011/2012 70 Corso: Sicurezza & Privatezza © Danilo Bruschi Iden&ficazione •  TuX principal hanno un iden&fica&vo human readable e un iden&ficato machine readable deio SID (security iden&fier) •  Gli uten& sono iden&fica&, airaverso uno user name che può contenere sino a 20 caraieri •  I gruppi possono avere nomi sino a 63 caraieri •  I sistemi possono avere nomi sino a 15 caraieri A.A. 2011/2012 71 Corso: Sicurezza & Privatezza © Danilo Bruschi Security Iden&fiers •  SID format: S-­‐R-­‐I-­‐SA-­‐SA-­‐SA-­‐N •  S: leiera S •  R: revision number (currently 1) •  I: iden&fier authority (48-­‐bit) •  SA: subauthority (32-­‐bit) •  N: iden&ficatore unico nell ambito dello spazio dei nomi dell authority •  E.g. Guest S-­‐1-­‐5-­‐21-­‐<domain>-­‐501 •  <domain>: 96-­‐bit iden&ficatore della macchina creato durante l installazione A.A. 2011/2012 72 Corso: Sicurezza & Privatezza © Danilo Bruschi Principal •  World (Everyone) •  SYSTEM S-­‐1-­‐1-­‐0 S-­‐1-­‐5-­‐18 •  Il SO viene eseguito sul proprio hardware come S-­‐1-­‐5-­‐18; su altre macchine nel dominio gli viene assegnato un SID specifico del dominio di appartenenza •  Administrator S-­‐1-­‐5-­‐21-­‐<domain>-­‐500 •  creato durante l installazione del sistema A.A. 2011/2012 73 Corso: Sicurezza & Privatezza © Danilo Bruschi SoggeX & Tokens •  Ogni principal da luogo a più processi o thread che per conto del principal svolgono le diverse aXvità sul sistema, queste en&tà sono i deie soggeX •  L’elenco dei privilegi •  Ad ogni soggeio, quando creato, viene associato un access token (opportuna stringa di bit) che iden&fica univocamente un soggeio: •  Il token con&ene le informazioni dei principal associa& al soggeio •  Il token con&ene le informazioni A.A. 2011/2012 74 Corso: Sicurezza & Privatezza © Danilo Bruschi Access Token A.A. 2011/2012 75 Corso: Sicurezza & Privatezza © Danilo Bruschi Contenu& access token •  Airibu& iden&fica&vi ed autorizza&vi: user SID, i SID di tuX i gruppi a cui il principal appar&ene •  Miscellanea: logon session ID, token ID, modifica&on ID, token type, expira&on &me (unused), impersona&on level •  Alcuni di ques& campi sono read only, altri possono essere modifica& A.A. 2011/2012 76 Corso: Sicurezza & Privatezza © Danilo Bruschi Privilegi •  Descrivono le operazioni che un soggeio può compiere su risorse di sistema, e vanno dis&nte dai diriX di accesso che determinano le operazioni che possono essere svolte su oggeX standard •  I privilegi sono assegna& a uten&, gruppi e alias e sono a livello di singola macchina e non di dominio A.A. 2011/2012 77 Corso: Sicurezza & Privatezza © Danilo Bruschi Esempi di Privilegi Back up files and directories Generate security audits Manage and audit security log Take ownership of files and other objects Bypass traverse checking Enable computer and user accounts to be trusted for delega&on •  Shut down the system • 
• 
• 
• 
• 
• 
A.A. 2011/2012 78 Corso: Sicurezza & Privatezza © Danilo Bruschi OggeX •  Sono le en&tà che, in relazione alle operazioni di accesso, svolgono un ruolo passivo: •  Execu&ve objects: processes, threads,… •  File system objects: files, directories •  Registry keys, printers, … •  Securable object hanno un security descriptor •  Security descriptor per built-­‐in objects sono ges&& dall O/S •  Possibilità di personalizzare Security descriptor per so~ware applica&vo A.A. 2011/2012 79 Corso: Sicurezza & Privatezza © Danilo Bruschi Security descriptor A.A. 2011/2012 80 Corso: Sicurezza & Privatezza © Danilo Bruschi Security Descriptor (SD) Owner SID"
Primary Group SID"
DACL"
SACL"
• 
• 
• 
• 
Owner: (discussed below) Primary Group: per POSIX compa&bility DACL: elenca chi (SID) può fare cosa SACL: definisce la poli&ca di audit A.A. 2011/2012 81 Corso: Sicurezza & Privatezza © Danilo Bruschi Owner •  Un SD con&ene il SID dell’owner dell’oggeio •  L owner deve essere un principal •  Ad ogni oggeio viene assegnato un owner nel momento della creazione •  L owner possiede sempre i diriX READ_CONTROL e WRITE_DAC •  L ownership può essere oienuta anche airaverso il privilegio Take ownership of files and other objects (SeTakeOwnershipPrivilege) A.A. 2011/2012 82 Corso: Sicurezza & Privatezza © Danilo Bruschi Security Descriptor •  Il security descriptor viene assegnato ad un oggeio dall owner •  Se l owner non esegue questa operazione il sistema opera&vo provveda ad assegnare all oggeio dei SD di default A.A. 2011/2012 83 Corso: Sicurezza & Privatezza © Danilo Bruschi Permessi •  È l’autorizzazione esplicita a svolgere un’operazione (access right) su un oggeio specifico •  L’owner di un oggeio può autorizzare chiunque a svolgere sull’oggeio stesso una qualunque operazione (DACL) •  Se un’autorizzazione non è esplicitamente data, si intende negata •  Ogni permesso autorizzato dal proprietario di un oggeio è memorizzato in un ACE (Access control list entry) memorizzata nel security descriptor associato all’oggeio A.A. 2011/2012 84 Corso: Sicurezza & Privatezza © Danilo Bruschi Access Mask Each bit corresponds to an access right — a par&cular opera&on or set of opera&ons that can be performed on the object. Turning a bit on in a desired access mask signals that the thread requests the right to perform the corresponding opera&on. Turning a bit on in the access mask for an ACE signals that the corresponding opera&on is either allowed or denied, depending on the type of ACE. A.A. 2011/2012 85 Corso: Sicurezza & Privatezza © Danilo Bruschi Generic Access Rights A.A. 2011/2012 86 Corso: Sicurezza & Privatezza © Danilo Bruschi Standard Access Rights A.A. 2011/2012 87 Corso: Sicurezza & Privatezza © Danilo Bruschi Altri Permessi •  SACL: consentono la leiura e la modifica delle operazioni di audit •  Object specific: definiscono diriX di accesso specifici e variabili per ogni &pologia di oggeio A.A. 2011/2012 88 Corso: Sicurezza & Privatezza © Danilo Bruschi Object specific access rights A.A. 2011/2012 89 Corso: Sicurezza & Privatezza © Danilo Bruschi DACL •  DACL è una lista di access control entries (ACEs) •  Formato di un ACE : •  Type: posi&vo (adds permission), nega&vo (denies permission) o system audit •  Inheritance mask •  Access Mask: permission (32-­‐bit mask) •  SID (individual, group, alias) A.A. 2011/2012 90 Corso: Sicurezza & Privatezza © Danilo Bruschi Null DACL •  Empty DACL: nobody is granted any permission •  No DACL (NULL DACL): everybody gets all access AA. 2007/2008 Corso: Sicurezza 1 © Danilo Bruschi Auten&cazione •  Fase airaverso la quale viene stabilito il binding tra un principal e un soggeio •  In W2K esistono due modalità di auten&cazione in funzione del &po di accesso richiesto: •  Locale: •  In questo caso il meccanismo più usato è la password •  Di rete o dominio • 
• 
• 
• 
NTLM Kerberos V5 SSL/TLS Cer&fica& digitali A.A. 2011/2012 92 Corso: Sicurezza & Privatezza © Danilo Bruschi Access control •  Una decisione di accesso considera i seguen& elemen&: •  Per il soggeio che richiede l accesso: le credenziali memorizzate nel token •  Per l oggeio che deve essere acceduto: gli airibu& memorizza& nel SD •  Le operazioni di accesso richieste: fornite soioforma di bit mask •  Non sempre tuX i parametri sono considera& •  L operazione di verifica viene realizzata dall API AccessCheck A.A. 2011/2012 93 Corso: Sicurezza & Privatezza © Danilo Bruschi Auten&cazione locale •  Per potersi auten&care su un sistema un utente deve possedere un account nel Security Account Manager (SAM) •  In fase di auten&cazione le credenziali (password, cer&ficato digitale, ecc.) sono raccolte dal sistema e passate a LSA •  LSA passa le credenziali cifrate ad un authen&ca&on package che ne verifica la veridicità accedendo a SAM A.A. 2011/2012 94 Corso: Sicurezza & Privatezza © Danilo Bruschi Auten&cazione locale •  Se le credenziali sono correie sono res&tui&, a LSA, il SID dell’utente e quello di tuX i gruppi a cui appar&ene •  Con i suddeX da& LSA costruisce il SID che verrà u&lizzato dai soggeX genera& dal principal per accedere alle risorse del sistema secondo le modalità previste dai meccanismi di controllo degli accessi A.A. 2011/2012 95 Corso: Sicurezza & Privatezza © Danilo Bruschi Autorizzazione •  Quando un soggeio deve accedere ad un oggeio, il SRM analizza il token del soggeio e la rela&va richiesta di accesso e il SD dell’oggeio •  Se il SD non ha DACL (NULL DACL) l’accesso viene autorizzato •  Se SID è l’owner del file A.A. 2011/2012 96 Corso: Sicurezza & Privatezza © Danilo Bruschi Access Check •  Accumulo dei permessi: per ogni ACE presente nella DACL di SD: •  grant access: quando ACE con&ene un SID uguale a quello del soggeio e l’access mask contenuta nell’ACE corrente insieme alle access mask di tuX i “previously checked matching ACE” con&ente tuX i permessi presen& nell’access mask del soggeio •  deny access quando un ACE nega&vo viene incontrato con una delle richieste avanzate dal soggeio, o quando si raggiunge la fine della DACL senza aver potuto garan&re tuX i permessi al soggeio A.A. 2011/2012 97 Corso: Sicurezza & Privatezza © Danilo Bruschi Access Token A.A. 2011/2012 98 Corso: Sicurezza & Privatezza © Danilo Bruschi Logging •  W2K ha la possibilità di effeiuare il log di mol& even& del sistema •  Per una maggiore facilità di ges&one ques& log sono suddivisi su sei diversi file di log A.A. 2011/2012 99 Corso: Sicurezza & Privatezza © Danilo Bruschi Logging (1) •  Applica&on: rela&vo agli even& genera& dalle applicazioni o programmi •  System: tuX gli even& prodoX da W2K •  Security: con&ene tuX gli even& correla& alla sicurezza del sistema (accesso di uten&, tenta&vi di abusare di privilegi, ecc.) su questo file scrive solo il sistema per evitare flooding A.A. 2011/2012 100 Corso: Sicurezza & Privatezza © Danilo Bruschi Logging (2) • 
• 
• 
• 
Directory Service: tuX gli even& lega& al DS File replica&on DNS TuX ques& log sono presen& solo se è presente il relal&vo servizio A.A. 2011/2012 101 Corso: Sicurezza & Privatezza © Danilo Bruschi Logging •  Il logging in W2K viene aXvato eseguendo due passi: •  AXvando una high level audi&ng policy che specifica le aXvità che vogliamo registrare •  AXvando l audit sui singoli oggeX del sistema: cioè definendo su quali oggeX le azioni definite al passo precedente devono essere svolte A.A. 2011/2012 102 Corso: Sicurezza & Privatezza © Danilo Bruschi Logging •  Un problema da considerare nelle poli&che di logging è la dimensione del file di log • 
• 
• 
• 
Overwrite events Overwrite events older that x days Do not overwrite events Halt when the log is full A.A. 2011/2012 103 Corso: Sicurezza & Privatezza © Danilo Bruschi