La sicurezza informatica nelle applicazioni di rete

1
La sicurezza informaticanelle applicazioni di
rete

• Roberto CecchiniGARR-CERTSINM 2000Lecce, 2-4
  Ottobre 2000

2
GARR-CERT

• Il servizio
• istituito nel Marzo 1999, pienamente operativo da
  Giugno 1999
• 8 unità 2 a tempo pieno e 6 a tempo parziale,
  sede centrale a Firenze
• Gli utenti sono tutte le istituzioni afferenti
  alla rete GARR.
• I compiti
• rispondere alle segnalazioni di incidenti,
  avvertire ed assistere gli utenti coinvolti e
  seguire gli sviluppi
• diffondere informazioni sulle vulnerabilità più
  comuni e sugli strumenti di sicurezza da
  adottare
• gestire corsi di aggiornamento tecnico
• provare strumenti esistenti, e svilupparne di
  nuovi per esigenze specifiche.
• Coordinamento con gli altri CSIRT Europei

3
GARR-CERT chi siamo

• Membri
• Roberto Cecchini (coordinatore) ltRoberto.Cecchini_at_
  fi.infn.itgt
• Claudio Allocchio ltClaudio.Allocchio_at_elettra.tri
  este.itgt
• Paolo Amendola ltPaolo.Amendola_at_ba.infn.itgt
• Luca dell'Agnello ltluca.dellagnello_at_cnaf.infn.it
  gt
• Francesco Gennai ltFrancesco.Gennai_at_iat.cnr.itgt
• Enrico Morandi ltEnrico.Morandi_at_fi.infn.itgt
• Francesco Palmieri ltfpalmier_at_unina.itgt
• Andrea Pinzani ltAndrea.Pinzani_at_fi.infn.itgt

4
GARR-CERT procedura di gestione incidenti

• http//www.cert.garr.it/incidenti.php3(approvata
  dallOTS GARR il 20/12/99)
• GARR-CERT invia una comunicazione di apertura
  incidente ai responsabili locali coinvolti e
  allAPM
• se il problema non viene risolto GARR-CERT invia
  all'APM la richiesta di filtraggio sul router di
  connessione alla rete GARR
• se l'APM non interviene entro i tempi richiesti,
  GARR-CERT invia al GARR-NOC la richiesta di
  filtraggio sul router di accesso al GARR.
• Tempi di intervento richiesti
• open mail relay 3 giorni
• nodi origine di azioni ostili (port scan,
  attacchi, ecc.) 1 giorno
• router utilizzati per attacchi DoS (ad es. smurf)
  perché erroneamente configurati 1 ora.

5
GARR-CERT servizi

• Server web http//www.cert.garr.it/
• Mailing list
• cert_at_garr.it
• gli iscritti sono i membri di GARR-CERT
• riceve anche i mail diretti ad abuse_at_garr.it
• chiunque può (e dovrebbe) usarlo per segnalare
  incidenti.
• sicurezza_at_garr.it
• segnalazione di allarmi di sicurezza
• comunicazioni di interesse generale
• iscrizione aperta a tutti (maggiori dettagli sul
  server web).
• Documenti (reperibili sul server web).
• Security Alerts
• Controllo vulnerabiltà (su richiesta dellAPM).

6
Mi hanno compromesso! (1/2)

• Staccate la macchina dalla rete e lavorate in
  single user
• potrebbe essere meglio staccare la corrente!
• molto probabilmente ps, ls, find, netstat, ecc.
  non sono affidabili
• Provate a seguire le tracce dellintruso (qualche
  volta si dimentica di ripulirle)
• messages, xferlog, wtmp, maillog, ecc.
• molto consigliabile che i file di log vengano
  salvati anche su unaltra macchina
• shell history file.
• Fate un backup il più completo possibile (anche a
  fini legali)
• in alternativa smontate (e conservate) il disco.

7
Mi hanno compromesso! (2/2)

• Cercate di scoprire come è entrato lintruso
• Modificate tutte le password
• Se lintruso è diventato root (cosa abbastanza
  probabile)
• reinstallate il sistema operativo (allultima
  versione e allultima patch!)
• è molto difficile altrimenti essere sicuri che
  non siano rimaste backdoor
• controllate lesistenza di file suid/gid nelle
  directory utente
• attenzione a riutilizzare i vecchi file di
  configurazione
• Quali altre macchine potrebbero essere state
  compromesse?
• usavate .rhost (o simili)?
• che accessi sulla rete locale sono stati fatti
  durante la compromissione?

8
Come segnalare lincidente

• Inviate un mail a cert_at_garr.it (o riempite il
  modulo online su http//www.cert.garr.it/) con
  (potete usare la chiave PGP di GARR-CERT se
  desiderate una maggiore riservatezza)
• data e ora (con timezone e precisione del vostro
  clock)
• descrizione dellincidente
• come essere contattati
• estratti dai log e eventuali file lasciati
  dallintruso
• se oltre 500k non li spedite, limitatevi a dire
  che li avete verrete richiamati
• permesso (o diniego) di diffondere la vostra
  identità.
• Riceverete un mail di conferma apertura incidente
  e verrete tenuti aggiornati sugli sviluppi fino
  alla chiusura.
• Valutate lipotesi di una denuncia alla Polizia
  Postale (anche solo a fini cautelativi).

9
Incidenti segnalati a GARR-CERT
10
Sicurezza necessità di base

• Riservatezza
• la comunicazione è stata intercettata?
• Autenticazione
• il mio interlocutore è veramente chi dice di
  essere?
• Integrità
• i dati ricevuti sono proprio quelli spediti?
• Non ripudio
• il mio interlocutore può negare di aver detto
  quello che ha detto?
• Disponibilità
• il mezzo di comunicazione è stato reso
  inutilizzabile?

11
Tipi di attacchi

• Ormai chiunque può diventare un hacker.
• Spesso i sistemi in rete sono mal gestiti o
  addirittura abbandonati.
• IPv4 non è stata progettata pensando alla
  sicurezza delle applicazioni
• spoofing
• session hijacking
• man-in-the-middle
• Denial of Service (DoS)
• SYN flood, mail bombing, ping flood, ecc. ecc.
• sniffing
• analisi del traffico.
• Con IPv6 le cose dovrebbero andare meglio...

12
Protezioni

• Host
• strumenti di intrusion detection e controllo
• COPS, Tiger, tripwire, swatch
• personal firewall
• ipf, ipchains
• scanner
• nmap, sara, nessus
• Reti locali
• packet filter e firewall
• network intrusion detection
• Protocolli di connessione
• IPSec
• SSH
• SSL/TLS
• PGP, S/MIME

13
Firewall

• Dei dispositivi tra due reti con le seguenti
  proprietà
• tutto il traffico deve passare attraverso il
  firewall
• solamente il traffico autorizzato dalla politica
  locale di sicurezza può attraversarlo.
• Di solito supportano proxy per applicazioni tcp
• telnet, ftp, http, ecc.
• Diverse tipologie
• dual homed host
• screened home host
• screened subnet.

14
Cosa filtrare (o bloccare)?

• default deny stance o default permit stance?
• http//www.cert.org/security-improvement/practices
  /p058.html
• porte da considerare con attenzione (la lista è
  parziale vedere il documento sul server web di
  GARR-CERT)
• ftp
• telnet
• smtp
• domain
• bootp
• tftp
• http 
• pop2/pop3/imap 
• sunrpc
• nntp 
• nbios-ns/nbios-dgm/nbios-ssn  
• snmp/snmptrap 
• exec/login/shell
• syslog 
• printer 
• mountd 

15
Packet filter

• Un device (ad es. un router) che controlla ogni
  pacchetto IP in arrivo per decidere se inoltrarlo
  o no.
• I filtri si basano sulle seguenti informazioni
  (dallheader del pacchetto)
• tipo di protocollo
• porte
• indirizzi sorgente e destinazione
• flag e opzioni tcp.
• Possono anche mantenere informazioni sulle
  sessioni tcp e udp (stateful inspection devices).

16
Firewall dual homed host

• Nessun routing tra rete esterna ed interna
• Sul firewall packet filtering e proxy services
• Single point of failure

17
Firewall screened subnet

• Massimo grado di sicurezza
• I router operano come packet filter vincolando il
  percorso dei pacchetti
• Su DMZ pacchetti per e da solo il Bastion Host
  (BH)
• I due router possibilmente diversi

BH
DMZ
18
Firewall limitazioni

• È sempre possibile accesso non autorizzato alla
  rete esterna via modem
• Scarsa protezione dagli attacchi dallinterno
• Scarsa o nessuna protezione da virus, applet
  Java, e controlli ActiveX
• Si possono utilizzare tunnel per evitare le
  protezioni

19
Crittografia

• La crittografia risponde alle esigenze di
  sicurezza.
• Riservatezza
• cifratura.
• Autenticazione
• firma digitale
• certificati.
• Integrità
• one-way hash (message digest).
• Non ripudio
• Integrità e Autenticazione.

20
Riservatezza cifratura

• Converte un testo in chiaro in uno
  inintelligibile.
• Richiede almeno una chiave (un numero).
• Può essere di due tipi
• simmetrica (a chiave privata)
• relativamente veloce
• come recapitare la chiave ai corrispondenti in
  modo sicuro?
• asimmetrica (a chiave pubblica)
• lenta si usa di solito insieme a quella
  simmetrica
• senza il problema della trasmissione della chiave
  privata.

21
Cifratura a chiave privata

• Richiede una chiave segreta nota solo ai
  corrispondenti
• La stessa chiave serve per cifrare e decifrare il
  messaggio
• Come trasferire la chiave in modo sicuro?
• Per n utenti il numero delle chiavi è O(n2).

22
Cifratura a chiave pubblica

• Ogni utente ha due chiavi generate
  contemporaneamente una privata e una pubblica
• dalla chiave pubblica è praticamente impossibile
  scoprire quella privata
• quello che si cifra con una, si può decifrare
  solo con laltra.
• Non è necessario nessuno scambio di chiavi
  segrete
• il mittente cifra con la chiave pubblica del
  destinatario
• il destinatario decifra con la propria chiave
  privata.
• Per n utenti il numero di chiavi è O(n)

23
Integrità one-way hash

• Funzioni che hanno in ingresso un messaggio di
  lunghezza variabile e producono una stringa di
  lunghezza fissa (hash).
• È praticamente impossibile trovare un messaggio
  che produca un hash specificato.
• Modificando anche un solo bit del messaggio si
  ottiene un hash completamente diverso.

24
Autenticazione firma digitale

• A calcola lhash del messaggio e lo cifra con la
  sua chiave privata lhash cifrato è la firma
  digitale
• A invia il messaggio e lhash a B.
• B ricalcola lhash sul messaggio e lo confronta
  con quello cifrato da A.
• Se i due hash sono uguali, il messaggio non è
  stato modificato e A non può ripudiarlo.

25
Autenticazione certificati

• La firma digitale rende sicuro un messaggio se
• la chiave privata di A non è stata compromessa
• B è in possesso della vera chiave pubblica di A.
• La convalida delle chiavi pubbliche viene fatta
  tramite i certificati unautorità esterna
  (Certification Authority) garantisce
  dellautenticità delle chiavi pubbliche.
• Due modelli esistenti
• X.509 organizzazione gerarchica
• PGP web of trust

26
Certificati X.509

• Un certificato X.509 è composto fondamentalmente
  da
• informazioni sul propietario
• la data di scadenza
• la chiave pubblica del proprietario
• informazioni sullautorità garante (la
  Certification Authority o CA)
• Il certificato è firmato dalla CA
• cioè il certificato contiene anche un hash del
  suo contenuto, cifrato con la chiave privata
  della CA.

27
CA catene gerarchiche e fiducia

• Anche le CA hanno un proprio certificato.
• Una CA può garantire anche altre CA, di livello
  inferiore
• catene gerarchiche di certificati.
• Allorigine della catena c è una Root CA, che ha
  un certificato auto-firmato (root certificate).
• I certificati delle CA sono largamente
  pubblicizzati, quindi difficili da falsificare.

28
Root CA

• I browser contengono preinstallati alcuni root
  certificates
• visibili sotto Signers nel menu Security
  (Communicator).
• Si possono aggiungere, eliminare e modificare i
  certificati.

29
Public Key Infrastructure (PKI)

• Una o più Certification Authority organizzate
  gerarchicamente o via web of trust
• Politica di emissione dei certificati
  Certificate Practice Statement (CPS)
• Emette certificati per server e utenti finali
  (eventualmente per altre CA)
• Mantiene una Certificate Revocation List (CRL)
• Gestisce servizi WWW e LDAP
• Gestione delle chiavi private
• Generazione
• via browser
• via hardware ad es. SmartCard
• Custodia
• Hard disk (insicuro!)
• SmartCard
• IETF Working Group PKI X.509 e Simple PKI

30
Protocolli (1/3)

• Network level
• trasparenti per le applicazioni, che non devono
  essere modificate
• il network layer deve essere modificato
• Transport level
• viene fornita una libreria di funzioni che può
  essere utilizzata dai progammi applicativi
• necessaria la modifica dei programmi applicativi
• Application level
• trasparenti per la rete
• i servizi di sicurezza devono essere
  individualmente inclusi in ogni applicazione
• necessaria la modifica dei programmi applicativi

31
Protocolli (2/3)

• La lista non è esaustiva.
• network level
• PPTP (Microsoft et al., giugno 1996)
• permette di incapsulare protocolli non IP, ad es.
  IPX e NEtBEUI
• password in chiaro o cifrate (LAN Manager hash
  e Windows NT hash)
• Versione Microsoft del Challenge Handshake
  Authentication Protocol (MS-CHAP).
• L2F (Cisco, Aprile 1996), L2TP (IETF PPP Working
  Group, Maggio 1998)
• IP Security Architecture per IPv4 e IPv6 (IPsec)
• cifratura e autentificazione
• luso pricipale è nella creazione di reti private
  (VPN) e per la connessione sicura dei road
  warriors alle intranet aziendali
• trasport level
• Secure Shell (SSH), v1 e v2
• Secure Sockets Layer (SSL) / Transport Layer
  Security (TLS)
• application level
• S/MIME, PGP
• SMTP, DNS, ecc.
• Kerberos (V4 e V5)
• DCE

32
Protocolli (3/3)
33
IPsec

• Autenticazione e cifratura al livello network
• Authentication Header (AH)
• autentifica ogni pacchetto
• Encapsulating Security Payload (ESP)
• cifra i dati in ogni pacchetto
• Internet Key Exchange (IKE)
• protocollo di negoziazione
• metodi di autentificazione
• metodi di cifratura
• consente scambio sicuro di chiavi

34
IPsec end-to-end

• AH
• campi variabili TOS, Frg offset, TTL,
• ESP
• autentificazione facoltativa
• lIP header non è protetto

Authentication Header
autenticato
(tranne per i campi variabili)
Encapsulated Security Payload
35
IPsec tunnel
Gli indirizzi A e B non sono visibili allesterno
dei gateway 1 e 2
36
Prodotti che supportano VPN con IPsec

• S/WAN (Linux)
• http//www.freeswan.org
• Windows 2000
• Router (e firewall)
• VPNC associazione di aziende con prodotti VPN
• http//www.vpnc.org
• circa 30 membri

37
SSH

• Rimpiazza telnet e i comandi r (rlogin, rshell)
• Versione 1 e Versione 2 (IETF SECSH Working
  Group)
• nella versione 1 richiede una distribuzione
  manuale delle chiavi di host e utenti
• protegge da
• IP spoofing
• IP source routing
• DNS spoofing
• sniffing
• man-in-the-middle
• tunneling traffico tcp e X11
• compressione dei dati (facoltativa, utile per
  connessioni lente).
• Ulteriori informazioni
• http//www.ssh.com/
• http//www.openssh.com/

38
SSL/TLS

• Secure Sockets Layer (SSL) sviluppato da Netscape
  Communications
• Lultima versione (V3.0) è del Marzo 1996
• Netscape Communicator, Internet Explorer.
• Transport Layer Security (TSL) Working Group
  (IETF)
• versione 1.0 del Gennaio 1999 (RFC 2246).
• Utilizza certificati X.509
• Può essere usato per ogni applicazione TCP (ad
  es. HHTP, Telnet, FTP, POP3, IMAP)
• usato da praticamente tutti i server web
  sicuri https//..
• le vecchie applicazioni insicure possono essere
  usate in modalità tunnel (ad es. stunnel
  http//www.stunnel.org)\
• Non interagisce bene con firewall/proxy
  (man-in-the-middle)
• SSL tunneling protocol
• http//www.openssl.org/

39
S/MIME

• Permette di inviare e-mail MIME firmati e
  crittografati
• Suppportato (tra gli altri) da Communicator e
  Outlook
• Utilizza certificati X.509

40
Certificato utente
41
Messaggio (firmato e crittografato)