La Rete Gnutella e il P2P Parte seconda Mauro Franceschi.

Presentazione sul tema: "La Rete Gnutella e il P2P Parte seconda Mauro Franceschi."— Transcript della presentazione:

1 La Rete Gnutella e il P2P Parte seconda Mauro Franceschi

2 I 5 DESCRITTORI DEL G-NET(Gnutella-Network) 1)PING 1)PING: I messaggi Ping non hanno associato alcun carico e hanno lunghezza 0. E quindi rappresentato soltanto da un Descriptor Header il cui campo Payload Descriptore il cui campo Payload Length siano entrambi fissati al valore 0. Un servent usa i Ping per conoscere lo stato della rete: un servent che riceva un pacchetto di questo tipo e tenuto a rispondere con un pacchetto Pong,

3 I 5 DESCRITTORI DEL G-NET(Gnutella-Network) 2)PONG 2)PONG : utilizzato come risposta al PING; contiene lindirizzo del servent (porta e ip)e informazioni circa lammontare dei dati condivisi (numero file condivisi e numero kb condivisi).

4 3)QUERY: utilizzato per inviare delle richieste; un servent che riceve un descrittore QUERY deve rispondere con un descrittore QUERYHIT se ha trovato corrispondenza con i dati richiesti. Minum speedSearch criteria Query(0x80) Minum Speed: indica la velocitaminima della connessione del peer da ricercare. Search Criteria: i criteri di ricerca del file richiesto. I 5 DESCRITTORI DEL G-NET(Gnutella-Network)

5 4)QUERYHIT : la risposta ad una QUERY; questo descrittore fornisce al destinatario abbastanza informazioni per acquisire i dati richiesti QueryHit(0x81)

6 Schema Query-QueryHit con download

7 5)PUSH 5)PUSH : un meccanismo utilizzato dai servent per effettuare connessioni dirette, qualora ci sia la presenza di un Firewall Un servent che riceve un messaggio Push si preoccupa di spedire la risorsa soltanto nel caso in cui l' identificatore di Servent corrisponda al proprio, negli altri casi si limita ad inoltrarlo come un comune messaggio Multicast. I 5 DESCRITTORI DEL G-NET(Gnutella-Network)

8 Qualora un servent (159.149.70.94) volesse scaricare una risorsa (Stairway to Heaven.txt) da un servent protetto da un Firewall (192.168.10.1) deve chiederne la spedizione tramite un messaggio Push. Messaggi Push permettono quindi di far comunicare servent quando uno solo dei due e protetto da un Firewall ma diventa inutile qualora lo siano entrambi. Una sessione tipica di utilizzo del protocollo di Push

9 GNUTELLA FASE 1 – CONNESSIONE Ogni SERVENT contiene già inglobato lindirizzo di un server di cache dove sono reperibili gli indirizzi di macchine attualmente connesse alla rete GNUTELLA Il SERVENT invia un PING ad una di queste macchine, che in BROADCAST lo passerà a tutte le macchine a cui è connessa Una volta inviati i PING le macchine disponibili cominceranno a mandare pacchetti PONG seguendo la strada fatta dai pacchetti PING Nei pacchetti PONG sono contenute info sul numero di files condivisi e il loro ammontare e anche sulla velocità di connessione dellhost che lo invia

10 GNUTELLA FASE 1 – CONNESSIONE

11 1 2 3 6 5 7 8 1: peer inizio 2&7: risposte Query QueryHit Non descriptor 4 Match Un servent richiede un file facendo il broadcasts di una Query. I Servents inoltreranno tutti i Query descriptors in arrivo a tutti i servents direttamente collegati ad esso, eccetto quello che gli ha inviato la Query. Un servent se riceve un descriptor che ha gia ricevuto in precedenza non inoltrera il descriptor Un servent risponderacon un QueryHit se ha trovato un riscontro(Match) nel suo database locale. QueryHit descriptors possono essere spediti solo lungo lo stesso cammino dal quale proviene il Query descriptor in arrivo9 Se il campo TTL e a zero,il descrittore non e inoltrato a nessuna connesione. GNUTELLA FASE 2 – RICERCHE

12 Il desiderio di mantenere lanonimato dei partecipanti della rete rende la stessa rete vulnerabile e le risorse potrebbero: Subire attacchi Dos e DDoS Essere corrotte Contenere Virus, Worm, Trojan Horse: esempio Mandragore – un worm Gnutella --Agisce come un servent e risponde a tutte le Queries --Fa una copia di se stesso rinominata per essere scaricato SICUREZZA NEL P2P 1

13 SICUREZZA NEL P2P 2- AUTENTICAZIONE DEI CONTENUTI Ogni volta che un file e scaricato bisogna fidarsi che il contenuto del file sia quello che effettivamente ci si aspettava. Non ce nessuna informazione addizionale nel file che avvisi lutente del reale contenuto del file. Lutilizzo attuale del protocollo Gnutella e del protocollo p2p in generale si basa essenzialmente sulla fiducia tra lutente che cerca e lutente che fornisce il file. Unalterazione puo essere innocua, oppure puo essere capace di introdurre codice virus, messaggi o altro.

14 Una possibile soluzione: Reputation System:X-Rep Revisione del processo di Peer : lopinione degli altri peer e usata per stabilire una reputazione per peers e files. Ovvero viene introdotto un meccanismo chiamato X-Rep : possiamo stabilire se quello che andremo a prelevare da un altro servent e quello che vogliamo effettivamente.

15 Fondamenti del Reputation System:X-Rep Ogni servent conserva delle informazioni sulla sua esperienza riguardo i files e gli altri servents e condivide questa esperienza con gli altri servents se essi ne fanno richiesta. Ogni servent ha un proprio servent_id che e una sorta di public key ottenuta tramite una funzione di hash sicura. La reputazione del Servent e associata al suo servent_id Ogni file ha associato un resource_id che e calcolato applicando una funzione di hash sicura al contenuto del file. Le reputazioni di un file sono accoppiate al suo resource_id.

16 Immagazzinamento della reputazione e calcolo dei voti 1 Ciascun servent mantiene un resource_repository che memorizza le sua opinioni riguardo i files e un servent_repository che riguarda i servents di cui ha esperienza. servent vota Un servent vota files e servents con cui ha avuto esperienza.I voti sono le sue opinioni su files e servents. I voti sono espressi sulla base delle informazioni disponibili nel suo resource_repository e servent_repository.

17 Immagazzinamento della reputazione e calcolo dei voti 2 resource_repository: insieme di coppie (resource_id,value) value= 0 o 1. servent_repository: insieme di triple (servent_id, num_plus, num_minus) num_plus rappresenta il numero di interazioni positive, num_minus le interazioni negative. Voto = 0 giudizio negativo o 1 giudizio positivo. Voto del servent =1, se num_plus>>num_minus. Voto del file = value.

18 Xrep:Polling Protocol Fase 1: Ricerca di una risorsa. P manda un Query message per cercare files, e i servents fanno il matching della richiesta con un QueryHit. Query ( Min_Speed, Search_criteria ) QueryHit (num_hit,IP,port,speed,Result_set,trailer,servent_id) Trailer: contiene i resource_ids dei files nel result set Initiator p Servent s

19 Xrep:Polling Protocol Fase 2: Scrutinio dei Voti P seleziona un file che sembra soddisfare al meglio la sua richiesta. P indice una votazione tra i peers circa la reputazione di un file e linsieme di servents che lo offrono. P invia un messaggio di votazione (Poll) dove vengono elencati gli identicativi di tutti questi servent, la chiave pubblica associata alla sessione di votazione. I servents che vogliono rispondere votano nel resource_id e servent_ids e mandano indietro una PollReply, crittografata con la pk inviatagli da P Initiator p Servent s Poll (resource_id, {servent_id 1… servent_id n }, PKpoll) PollReply ({(IP,port,Votes)} PKpoll )

20 Xrep:Polling Protocol Fase 3: Valutazione dei Voti e controllo di realizzabilita 1. p decripta i PollReply, eliminando quelli alterati. 2. p seleziona un insieme di votanti,li contatta direttamente, e aspetta il ritorno dei messaggi di conferma. Se non ci sono ancora risposte, allora p ripete il passo 2. Initiator p Servent s TrueVote ( Vote ) TrueVoteReply ( responses )

21 Fase 4: Controllo del migliore servent p non puo sempre scaricare file dal miglior servent S. p contatta il migliore servent S per controllare il fatto che esporti il file che p vuole scaricare. Initiator p Servent s AreYou (servent_id s, resource_id) AreYouReply({response} SKs, PK s )

22 Fase 5: Download della risorsa p seleziona un servent s, scarica il file r e lo controlla. Aggiorna il resource_repository & servent_repository Initiator pServent s download ( r ) resource ( r )

23 XRep: Security Considerations XRep permette di proteggere il P2P dai seguenti attacchi: – Self replication – Man in the middle

24 Self replication: Un servent potrebbe rispondere a tutte le Queries e provvedere a modificarne il contenuto. Persino i peers onesti, ignari del contenuto dannoso, potrebbero partecipare alla condivisione e.g. Mandragore – a Gnutella worm Cattiva reputazione del file. -- Worms modificano se stessi Non possono avere buone reputazioni. Controlla la reputazione del servent.

25 Man in the middle: A fa il broadcasts di una Query. B risponde con un QueryHit. E cambia IP e la Porta del QueryHit con IP e Porta di E, rimandandolo ad A. A puo scaricare da E. Il falso contenuto mandato da E non corrispondera al digest del file legittimo, cosi sara scartato. (Fase 5) A B E Query QueryHit QueryHit Modificato Download

26 Bibliografia Un sistema di sicurezza per ambienti peer-to-peer. Autore: Fabrizio Corneli. A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks. Autori:E. Damiani S. De Capitani di Vimercati S. Paraboschi P. Samarati F. Violante; url: http://seclab.dti.unimi.it/p2prep/