AICA Corso IT Administrator: modulo 5 AICA © 2005 1 EUCIP IT Administrator Modulo 5 - Sicurezza...

AICA © 2005 1

AICACorso IT Administrator: modulo 5

EUCIP IT AdministratorModulo 5 - Sicurezza Informatica

3 - Autenticazione e controllo di accesso

Alberto Bosio

AICA © 2005 2


Autenticazione

• Per un qualsiasi soggetto, l'autenticazione rappresenta l'atto di dimostrare la propria identità. I metodi a disposizione ricadono all'interno di queste tre casistiche:

• Il soggetto possiede qualcosa: chiavi elettroniche, chiavi hardware o smart card;

• Il soggetto conosce qualcosa: password o PIN; • Il soggetto ha una determinata caratteristica o

comportamento: biometria. • E' bene chiarire che, visto le differenze sostanziali esistenti fra i

vari metodi, utilizzare l'uno o l'altro dovrebbe sempre derivare da un'attenta analisi del bene da proteggere.

AICA © 2005 3


Problema

• IDENTIFICAZIONE INIZIALE:– Attacchi di Social Engineering mirano a prendere l'identità di

qualcun'altro. Metodo classico, più usato, più facile e con maggiori successi !!!

AICA © 2005 4


Principali metodi

• Procedure di identificazione (lato client)– Login/password testuali

– Chiavi hardware • Smartcard, chiavi USB, ...

– Sistemi biomedici

• Metodi di autenticazione– Password

– Two Factor Athentication

– Certificati digitali

– Certificati digitali e Password policy

– Autenticazione biometrica

AICA © 2005 5


Password

• Sistema più diffuso• Richiede un solo fattore di identificazione• Poco costoso• Sistema debole

– Password guesting

– Sniffing delle password

AICA © 2005 6


Password

• username+password: metodo classico per autenticazione su elaboratori

• Cambiare la password con ragionevole frequenza• Scegliere una password facile a ricordarsi, lunga a sufficienza

(almeno 8 caratteri), non banale:– Password casuale

– Inserire numeri e maiuscole in una parola o frase:

inghilterra -> 1ngH1ltE99a

AICA © 2005 7


Password

• Mai usare la stessa password per due diversi elaboratori o username

• Mai usare password = username• In Unix/Linux usare shadow file e MD5• Usare regolarmente un Password Cracker• Se il file di password (cifrate) viene rubato/copiato, cambiare

immediatamente tutte le password

AICA © 2005 8


OTP (One-Time Passwords)

• Idea originale:– Bell Labs

– sistema S/KEY

– implementazione di pubblico dominio

• implementazioni commerciali con generatori automatici hardware (autenticatore)

AICA © 2005 9


Come fornire password OTP agli utenti?

• per uso su postazioni “stupide” o insicure:– password pre-calcolate e scritte su un foglio

– autenticatori hardware (criptocalcolatrici)

• per uso su postazioni sicure e intelligenti:– programmi di calcolo

– eventualmente integrati col sw (telnet, ftp, ...) o hw (modem) di comunicazione

AICA © 2005 10


Il sistema S/KEY

• RFC-1760• l’utente sceglie un segreto S (il seme)• l’utente calcola N one-time password:

P1 = h (S)

P2 = h (P1) = h( h(S) )

. . .

• l’utente inizializza il server di autenticazione con• l’ultima password (es. P100)

AICA © 2005 11


Il sistema S/KEY

• il server chiede le password in ordine inverso: P99? X

h (X) = P100 ?

memorizza X

• in questo modo il server non deve conoscere il segreto del client

• RFC-1760 usa MD4 (possibili altre scelte)• implementazione public-domain per Unix, MSDOS,

Windows, MacOs

AICA © 2005 12


Problemi delle OTP

• scomode da usare in assoluto• scomode da usare per accesso a servizi multipli basati su

password (es. POP con check periodico della posta)• costose se basate su autenticatori hardware• non possono essere usate da un processo ma solo da un

umano

AICA © 2005 13


Problemi degli autenticatori hardware

• denial-of-service: tentativi falliti appositamente per negare l’accesso

• social engineering: telefonata per denuciare smarrimento e chiedere l’inizializzazione di una nuova carta

AICA © 2005 14


Two Factor Athentication

• Più robusto della semplice password• L’utente deve conoscere il proprio PIN • L’utente deve possedere un dispositivo di autenticazione

– Token, SmartCard

–SmartCard:

–Carta elettronica dotata di una ROM e di un processore

–In grado di memorizzare i dati anagrafici e le chiavi private

AICA © 2005 15


SmartCard

• Token: una chiave elettronica• SmartCard: un mini processore su di una carta elettronica

(formato carta di credito) in grado di memorizzare una Chiave Privata in forma cifrata– È necessario un PIN per decifrare la Chiave Privata che poi usa per

cifrare i dati in ingresso

– Data un'Impronta genera una Firma Digitale

– Autentica usando challengeresponse (nonce)

AICA © 2005 16


SmartCard

• Carta + PIN: due modi di autenticazione• Sicuro quanto è sicuro l'elaboratore a cui si collega (esistono

già attacchi che permettono di prendere possesso della SmartCard e farle firmare ciò che si vuole (un contratto, un bonifico ...), per debolezza degli applicativi e del Sistema Operativo dell'elaboratore; compariranno nei prossimi Virus per Windows? )

AICA © 2005 17


Certificati digitali

• Problemi legati alla sicurezza• Il certificato è memorizzato su disco rigido

AICA © 2005 18


Certificati digitali e Password policy

• Maggior livello di protezione quando vengono emmessi da una CA– Verifica dell’identità dell’utente

• Gestione centralizzata dei certificati– Regole per le password (almeno 10 caratteri)

AICA © 2005 19


Autenticazione biometrica

• Riconoscimento di caratteristiche uniche dell’individuo:– Retina

– Impronta digitale

– Voce

– Volto

– ...

AICA © 2005 20


Autenticazione biometrica

• Simile a Token o SmartCard,• ma invece di un oggetto viene verificato:

– L'impronta digitale

– L'iride

– I lineamenti del viso

– ...

• Si può associare ad un Token con PIN per ottenere tutti i 3 metodi di autenticazione

• Attenzione: è controverso quanto la biometria sia sicura se usata da sola

AICA © 2005 21


Sistemi di autenticazione di rete

• Problematiche– Il passaggio di credenziali via rete deve essere protetto

• Crittografato• Credenziali one-time• Challenge response

• Esempi:– Unix : utilizzo di password cifrate (algoritmo crypt) registrate in

/etc/passwd• Max 8 caratteri

– Utilizzo shadow password (hash MD5)• /etc/shadow

AICA © 2005 22


Autenticazione in rete : Protocolli

• PAP– Password Authentication Protocol

– Password in chiaro

• CHAP– Challenge Handshake Authentication Protocol

– Sfida simmetrica

• EAP– Extensible Authentication Protocol

– Aggancio a meccanismi esterni (sfide…)

AICA © 2005 23


PAP

• Password Authentication Protocol• RFC-1334• User-id e password inviate in chiaro• Autenticazione solo all’attivazione del collegamento• Pericoloso!

AICA © 2005 24


CHAP

• RFC-1994 “PPP Challenge Handshake Authentication Protocol (CHAP)”

• Meccanismo a sfida simmetrico (basato sulla password)• Sfida iniziale obbligatoria, possibile ripetere la richiesta

(con sfida diversa) durante la comunicazione• Chi supporta sia CHAP sia PAP, deve prima offrire CHAP

– Provider

AICA © 2005 25


EAP

• RFC-2284 “PPP Extensible Authentication Protocol (EAP)”• Framework flessibile di autenticazione a livello data-link• Tipi di autenticazione predefiniti:

– MD5-challenge (simile a CHAP)

– OTP

– generic token card

• Altri tipi possono essere aggiunti:– RFC-2716 “PPP EAP TLS authentication protocol”

– RFC-3579 “RADIUS support for EAP”

AICA © 2005 26


OTP

• Le OTP (One time Password In Everything) sono delle parole chiave utilizzate ai fini di autenticazione che hanno validità per una sola specifica login – Non esiste il problema che siano compromesse, in quanto come

sono usate non sono più valide.

• Le OTP vengono generate a partire da una passphrase, un seed (seme), e un numero di sequenza che ad ogni login viene decrementato, fino a quando non arriverete a 0 e sarà quindi necessario generare un nuovo numero di sequenza.

AICA © 2005 27


Autenticazione Tramite Token

• Security Token Service: servizio che rilascia i token (credenziali di autorizzazione ed autenticazione) sulla base delle informazioni (proof of identity) fornite dal Policy Decision Point.

AICA © 2005 28


Autenticazione Tramite Token

• Il Consumer ottiene la risorsa, previa autenticazione tramite un terzo attore di cui entrambe le parti (Seller e Consumer) ripongono fiducia.

• Questo modello generale supporta diversi modelli più specifici: – liste di controllo accessi (ACL),

– identity management,

– Etc…

• permette l'utilizzo di tecnologie esistenti – i certificati a chiave pubblica X.509,

– ticket Kerberos condivisi

– password digests.

AICA © 2005 29


Autenticazione per applicazioni distribuite

• RPC: Remote Procedure Call– Nasce su UNIX, un processo in esecuzione su un host può

chiedere l’esecuzione di una procedura da parte di un processo eseguito su un altro host

– I servizi di rete sono visti come una collezione di uno o più programmi remoti

• Ciascun programma remoto implementa una o più procedure remote• Le chiamate e i paramtrei sono specificate nei protocolli

AICA © 2005 30


Remote Procedure Call

• Esempio : Sistema RPC in ambiente SUN– Il client invia un messaggio di richiesta

• Call message : sono inclusi i parametri della procedura

– Il client aspetta (bloccato) la risposta del server• Reply message : sono inclusi i risultati della procedura

• L’autenticazione è mutua:– Il mess. del client contiene :

• Credenziale, verificatore

– Il mess. del server contiene :• Verificatore di risposta

AICA © 2005 31



• Ogni campo è costituito da:

– Flavor : contiene valori (NULL, UNIX, SHORT o DES)

– Body : fino a 400 byte di informazioni di autenticazione

flavor body

AICA © 2005 32



• UNIX:– client :

• credenziale:– Identificatore della transazione

– Nome della workstation

– UID

– GID

• Verificatore:– NULL

– server : convalida le credenziali, risponde con NULL o SHORT• Verficatore :

– SHORT : fornisce al client un codice per una successica autenticazione

AICA © 2005 33



• Problemi:– Non esite controllo sulle credenziali del client !

• Schema di autenticazione DES:– Sulle macchine deve essere attivo il demone keyserv (sia client che

server)

– L’utente deve avere una coppia di chiavi • La pubblica è disponibile sul server di amministrazione della rete

– Consente l’autenticazione mutua del client e del server• Un campo verificatore contiene un timestamp cifrato dal client e

decifrato dal server

AICA © 2005 34


Single Sign on

• Problema:– Rete eterogenea (windows, unix, machintosh, ...) richiede l’utilizzo

di molteplici login e password per i diversi sistemi

– Necessità continua di autenticarsi su differenti servizi

• Architettura Single Sign-On (SSO)– Consente all’utente di autenticarsi un’unica volta per poi accedere a

tutti i servizi cui l’utente è accreditato

AICA © 2005 35


Kerberos

• Sviluppato da IBM e MIT nel 1983• Realizza un meccanismo SSO• Il cane mitologico kerberos aveva 3 teste

– Autenticazione

– Autorizzazione

– Accounting

• Standardizzato in RFC 1510

AICA © 2005 36


Kerberos

• Usa un sistema di autenticazione di tipo trusted third party– I soggetti (principal) sono

• Utenti • Servizi

– I soggetti si autenticano tra loro tramite un server centrale • KDC (Key Distribution Center)

AICA © 2005 37


Kerberos

• Un principal è un’entità alla quale un autenticatore kerberos può assegnare dei ticket

• Ogni principal è identificato da un nome univoco– Costituito da tre sezioni

• Primary/instance@realm

AICA © 2005 38


Kerberos

• Dove:– Primary : identifica il principal

• Nel caso di un utente il primary è lo username dell’utente stesso

– Instance : completa il primary (può essere NULL)• stefano@realm• stefano/autore@realm

– Realm : indica l’ambiente (rete o dominio) gestito dal KDC• Si usa il nome del dominio in caratteri maiusculi

– [email protected]

AICA © 2005 39


Kerberos : funzionamento

• Un principal (un utente) invia una richiesta di autenticazione al KDC

• Il KDC crea ul TGT (Ticket Granting Ticket) e lo invia al principal– Cifrato con la chiave pubblica del principal

• Se il principal vuole autenticarsi presso un altro principal (server) invia il TGT al KDC

• Il KDC risponde (al principal) con credenziali – valide per l’autenticazione a quel server

– Cifrate con la chiave del richiedente

– Ticket + chiave temporanea (chiave di sessione)

• Il principal trasmette un ticket al server– Identità + authenticator (timestamp e chiave di sessione)

AICA © 2005 40


Kerberos : funzionamento

• Il server ottiene dal KDC la chiave di sessione per quel ticket e la verifica

• L’autenticazione può anche essere mutua (two-way)– Il server si identifica a sua volta al client

AICA © 2005 41


Kerberos : struttura

• Due servizi indipendenti– Authentication Server (AS) : gestisce il database delle chiavi

• Fornisce il TGT

– Ticket Granting Server (TGS) : verifica i TGT rispondendo con chiavi di sessione

AICA © 2005 43


Kerberos

• Può essere utlizzato per autenticazioni tra realm diverse• Ogni realm ha un KDC server

– Autentica i propri principal

• Esistono chiavi inter-realm tra i server KDC – Il KDC del realm A diviene un principal per il KDC del realm B e

viceversa

AICA © 2005 44


Controllo D'accesso

• DAC (Discretionary Access Control) : controllo di accesso discrezionale. Concessione e revoca dei diritti di accesso a discrezione degli utenti– Utenti

– Gruppi di utenti

– Esiste un super utente (amministratore) che può modificare i permessi dei files senza sottostare a vincoli

AICA © 2005 45


Controllo D'accesso

• MAC (Mandatory Access Control) : controllo di accesso obbligatorio. Sistemi ad alta sicurezza

• Amministratore che definisce l’accesso a seconda del tipo risorsa e del livello di sicurezza desiderato.

• RBAC (Role-based Access Control) : controllo di accesso basato sui ruoli. Simile al MAC, ma l’accesso dipende dal ruolo dell’utente in quanto facente parte di un organizzazione.

• È l’organizzazione non l’individuo a possedere la risorsa.

AICA © 2005 46


Controllo D'accesso

• Controllare l'accesso alle risorse (lettura di dati, scrittura, esecuzione di un programma, utilizzo di una struttura hardware ...) mediante la definizione di privilegi.

• Metodo più semplice – ACL (Access Control List) che definiscono quali sono le azioni che

possono essere condotte su ogni risorsa da parte di un utente.

• Problemi :– Ogni azienda possiede policy di sicurezza proprie spesso

supportate da tecnologie differenti.

– La gestione dei diritti di autorizzazione estesa su più sistemi e tecnologie.

– WS-Security definisce un layer di astrazione che permette a infrastrutture differenti di "cooperare in piena fiducia".

AICA © 2005 47


Database e Controllo D'accessoMySQL

• RDBMS (Relational Database Management System)• Il controllo degli accessi avviene tramite grant table

– Tabelle di sistema che mantengono informazioni sugli utenti

TABELLA INFORMAZIONI

User Utenti registrati

Db Db ai quali può accedere un utente

Host Host dai quli ci si può connettere

Tables_priv Priviliegi a livello tabella

Colums_priv Priviliegi a livello colonna

AICA © 2005 48


Database e Controllo D'accesso MySQL

• I privilegi sono concessi e/o revocati tramite i comandi – Grant

– Revoke

– Modificando a mano (con i comandi SQL) le grant table• Occorre ricaricare le tabelle con i comandi mysqladmin reload,

mysqladmin flushprivileges

AICA © 2005 49


Database e Controllo D'accesso SQL server

• Necessaria autenticazione attraverso il SO su cui è installato SQL server

• Due modalità di autenticazione– Windows Authntication Mode : gli utenti locali non forniscono user e

pass in quanto sono già autenticati da windows• Occorre solo specificare i privilegi delgi utenti

– Mixed Mode : creo un account di login, salvati nella tabella syslogins

AICA © 2005 50



• Privilegi basati sui ruoli• Un ruolo è una collezione di privilegi

– Assegnare all’utente un ruolo implica assegnare tutti i privilegi assegnati a quel ruolo

• Tre categorie di ruoli– Public role : stabilisce i permessi di default

• Non può essere eliminato

– Fixed server roles : ruoli predefiniti trasversali ai vari database• Non sono modificabili e non èà possibile aggiungerne di nuovi

– Fixed database roles : validi all’interno del contesto di un singolo database

• Ruoli predefiniti non modificabili, concessi agli account utente

AICA © 2005 51



– User defined database roles : è possibile creare nuovi ruoli• Validi sui singoli database

– Application roles : ruoli per l’accesso ai dati dipendednti dalle applicazioni

• Si creano i ruoli e i permessi associati all’applicazione• L’applicazione attiverà sp_setapprole per ottenere i permessi• Non posso attribuirli al singolo utente

• In SQL server oltre a grant e revoke esiste anche il privelgio deny– Nega un accesso anche se esiste un grant che lo consentirebbe

AICA Corso IT Administrator: modulo 5 AICA © 2005 1 EUCIP IT Administrator Modulo 5 - Sicurezza...

Documents

Transcript of AICA Corso IT Administrator: modulo 5 AICA © 2005 1 EUCIP IT Administrator Modulo 5 - Sicurezza...