FTP, SMTP/POP3, DNS, reti P2P - SisInfLab

Transcript

Telematica II
A.A. 20062006-07
•
•
•
•
Sommario
Protocollo FTP
Posta Elettronica (SMTP, POP3, IMAP)
Protocollo DNS
Reti peer-to-peer, BitTorrent
1 di 100
Protocolli di livello applicativo
M. Ruta
Telematica II
A.A. 20062006-07
File Transfer Protocol (FTP)
• Consente il trasferimento di file tra due host
• Utilizza 2 connessioni TCP:
– Connessione di controllo: utilizzata per
trasferire informazioni di controllo tra client e
server
– Connessione dati: utilizzata per il
trasferimento dei file
2 di 100
M. Ruta
Telematica II
A.A. 20062006-07
FTP Client
FTP (2)
FTP Server
TCP control connection
(port 21)
TCP data connection (port 20)
File System
locale
File System
remoto
•La connessione di controllo è persistente ed identifica una sessione
(necessaria autenticazione mediante login/logout)
•La connessione dati non è persistente, nell’ambito di una sessione, per ogni
file trasferito è creata una nuova connessione dati (il server è in ascolto sulla porta
20 in attesa di nuove connessioni)
3 di 100
M. Ruta
Telematica II
FTP (3)
A.A. 20062006-07
User Interface
User protocol
interpreter
User data
transfer function
Control
connection
Data
connection
Client
4 di 100
Server protocol
interpreter
Server data
transfer function
Server
M. Ruta
Telematica II
A.A. 20062006-07
FTP: autenticazione
• FTP richiede l’autenticazione dell’utente remoto il quale deve
possedere un account sul server
•A discrezione del server esiste anche la possibilità di
autenticare un utente anonimo (anonymous FTP)
•User name: anonymous
•Password:qualsiasi (generalmente mail address)
•Numero limitato di risorse
•Diritti limitati (generalmente è negato il permesso w)
• FTP non è stateless, infatti le connessioni TCP devono essere
associate all’account dell’utente loggato (vincolo sul massimo
numero di utenti loggati)
5 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Rappresentazione dei dati (1)
• File Type:
– È possibile impostarlo in fase di configurazione della connessione
•
•
•
ASCII (default)
EBCDIC (mainframe IBM)
Binary
attualmente è difficile che si adoperi
FTP per trasferire file testuali
– Local file type: il numero di bit per byte è specificato dal sender
A way of transferring binary files between hosts with different byte
sizes. The number of bits per byte is specified by the sender. For
systems using 8-bit bytes, a local file type with a byte size of 8 is
equivalent to the image file type
6 di 100
M. Ruta
Telematica II
A.A. 20062006-07
• Structure:
– File Structure (default): il file è un flusso di byte contigui
– Record Structure: utilizzata solo con file di testo (ASCII o
EBCDIC)
– Page Structure: ogni pagina è trasmessa in modo numerato
7 di 100
M. Ruta
Telematica II
A.A. 20062006-07
• Transmission mode:
– Stream mode (default): il file è trasferito come un
flusso di byte contigui
– Block mode: il file è trasferito come flusso di
blocchi, ognuno dei quali è preceduto da un header
– Compressed mode: basato su Run-Length Encoding
(RLE) di sequenze del medesimo byte
RLE is a simple compression algorithm. It consists of the process of
searching for repeated runs of a single symbol in an input stream, and
replacing them by a single instance of the symbol and a run count
8 di 100
M. Ruta
Telematica II
A.A. 20062006-07
• Le implementazioni più comuni di client e server FTP su
piattaforme UNIX adottano le seguenti convenzioni:
–
–
–
9 di 100
File Type: ASCII o binary
Structure: file
Transmission mode: stream mode
M. Ruta
Telematica II
A.A. 20062006-07
Comandi FTP (NVT ASCII)
Comando
Descrizione
AUTH protocol
Imposta l’algoritmo di cifratura prima dell’autenticazione
ABOR
Annulla il precedente comando ed ogni trasferimento dati
CD directory
Cambia indirizzario di riferimento
LIST filelist
Lista files o directory
PASS password
Specifica la password
PORT n1,n2,…n6
Indirizzo IP del Client (n1.n2.n3.n4) e porta (256*n5+n6)
QUIT
Disconnessione dal server
RETR filename
Richiede un file
STOR filename
Fa l’upload di un file
SYST
Restituisce il tipo di S.O. del server
TYPE type
Specifica il modo di trasferimento: A=(ASCII) I=(binario)
USER username
Specifica lo username
10 di 100
M. Ruta
Telematica II
Repliche FTP
A.A. 20062006-07
Reply
Descrizione
1yz
Positive preliminary reply (l’azione sta partendo ma è necessaria un’altra replica
prima di un nuovo comando)
2yz
Positive completion reply (un nuovo comando può essere inviato)
3yz
Positive intermediate reply (il comando è stato accettato ma deve essere inviato
un altro comando per continuare) [es. login]
4yz
Transient negative completion reply (la richiesta non è stata accettata, l’errore è
temporaneo, si può ritentare in seguito)
5yz
Permanent negative completion reply
x0z
Syntax error
x1z
Information
x2z
Connections
x3z
Autentication and accounting
x4z
Unspecified
x5z
Filesystem status
11 di 100
M. Ruta
Telematica II
A.A. 20062006-07
•
•
•
•
•
•
•
•
•
Repliche FTP: esempi
125 Data connection already open; transfer starting
200 Command OK
214 Help message
331 Username OK, password required
425 Can’t open data connection [problemi derivanti dalla connessione di rete]
452 Error writing file [problemi derivanti dalla mancanza di permessi adeguati]
500 Syntax error (unrecognized command)
501 Syntax error (invalid arguments)
502 Unimplemented MODE type
12 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Gestione delle connessioni (1)
• La connessione dati è utilizzata per
–
–
–
Inviare un file da server a client
Inviare un file da client a server
Inviare un elenco di file o directory dal server al client (list)
• Una nuova connessione dati è creata per ogni file da
trasferire
13 di 100
M. Ruta
Telematica II
A.A. 20062006-07
• La creazione della connessione dati è sotto il controllo
del client
• Esistono 2 modalità di gestione della connessione:
– Attiva
– Passiva
• Modalità attiva:
– Il client sceglie un numero di porta > 1024 su cui
mettersi in ascolto
– Il client invia al server, tramite il comando PORT, il
connessione di
numero di porta scelto
controllo
– Il server avvia una connessione dati sulla porta ricevuta
connessione
(dal lato server il numero di porta è 20)
dati
14 di 100
M. Ruta
Telematica II
A.A. 20062006-07
• Modalità passiva:
– È il server a mettersi in ascolto per una connessione
– Si usa il comando PASV per effettuare la commutazione.
– E’ utile nel caso in cui il client si trovi dietro un firewall o un NAT e
quindi non può accettare connessioni in ingresso
– In questa modalità il server si mette in ascolto su una data porta ed
aspetta una connessione dal client
– La risposta a questo comando comprende il numero di porta su cui è in
ascolto il server
15 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di sessione FTP
220 (vsFTPd 2.0.1)
AUTH KERBEROS_V4
530 Please login with USER and PASS.
USER michi
331 Please specify the password.
PASS ciao
230 Login successful.
[avvio sessione]
SYST
215 UNIX Type: L8
[L8 = Linux]
PASV
227 Entering Passive Mode (127,0,0,1,157,77)
LIST
150 Here comes the directory listing.
…
…
226 Directory send OK.
TYPE I
200 Switching to Binary mode.
RETR prova.txt
150 Opening BINARY mode data connection for prova.txt (0 bytes.
…
226 File send OK.
QUIT
221 Goodbye.
16 di 100
M. Ruta
Telematica II
A.A. 20062006-07
No.
Time
1 0.000000
Source
193.204.59.21
Esempio di sessione FTP (2)
Destination
193.204.59.227
Protocol Info
TCP
32786 > ftp(21) [SYN] Seq=0 Ack=0
2 0.000083
193.204.59.227 193.204.59.21
TCP
ftp(21) > 32786 [SYN, ACK] Seq=0 Ack=1
3 0.000135
193.204.59.21
TCP
32786 > ftp [ACK] Seq=1 Ack=1
4 0.016440
193.204.59.227 193.204.59.21
FTP
ftp > 32786 Response: 220 (vsFTPd 2.0.1)
193.204.59.21
FTP
32786 > ftp Request: PASV
193.204.59.227
…
…
21 9.862311
193.204.59.227
22 9.862756 193.204.59.227 193.204.59.21
FTP
ftp > 32786 Response: 227 Entering Passive
Mode (127,0,0,1,157,77) Passive port: 40269 (157*256+77)
…
24 9.876359
193.204.59.21
25 9.876406
26 9.876430
17 di 100
193.204.59.227
TCP
32787 > 40269 [SYN]
193.204.59.227 193.204.59.21
TCP
40269 > 32787 [SYN, ACK]
193.204.59.21
TCP
32787 > 40269 [ACK]
193.204.59.227
M. Ruta
Telematica II
A.A. 20062006-07
No.
Time
27 9.876767
Source
193.204.59.21
Esempio di sessione FTP (3)
Destination
Protocol Info
193.204.59.227 FTP
32786 > ftp(21) Request: LIST
28 9.884313
193.204.59.227 193.204.59.21
directory listing.
FTP
ftp > 32786 Response: 150 Here comes the
29 9.889893
193.204.59.227 193.204.59.21 FTP-DATA 40269 > 32787 FTP Data:
drwx-----3 500
500
4096 Apr 14 15:47 Desktop\r\n-rwxr--r-500
958906 Apr 13 11:03 apt-0.5.15cnc6-1.1.fc3.fr.i386.rpm\r\ndrwxr-xr-x
500
4096 Apr 14 16:06 bin\r\n-rw-r
1 500
2 500
…
31 9.890257
OK.
193.204.59.227 193.204.59.21
FTP
ftp > 32786 Response: 226 Directory send
…
…
67 88.612774
193.204.59.21
68 88.613092
193.204.59.227 193.204.59.21
18 di 100
193.204.59.227 FTP
FTP
32786 > ftp Request: QUIT
ftp > 32786 Response: 221 Goodbye.
M. Ruta
Telematica II
A.A. 20062006-07
Client FTP
• Su tutti i sistemi Windows ed Unix, esiste un client ftp testuale,
richiamabile digitando:
ftp <nome_host>
• Digitando il comando help si può ottenere la lista dei comandi
• Esistono molti altri client grafici quali: WS_FTP, FileZilla, GFTP, …
• Anche molti browser web possono essere usati come client FTP
19 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Server FTP
• Un esempio di server FTP open-source disponibile per
Linux è vsFTPd (Very Secure FTP daemon)
• Dopo l’installazione del server, verrà creato un utente
ftp, con una propria home directory
• A questo punto il server è già in grado di funzionare. Se
si prova un login anonimo, verrà mostrato il contenuto
della home directory dell’utente ftp
20 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Configurazione di vsFTPd
• Si agisce sul file testuale vsftpd.conf, contenuto nella directory /etc
• Principali direttive:
–
–
–
–
–
21 di 100
max_clients: massimo numero di client che si possono connettere
max_per_ip: massimo numero di connessioni da uno stesso indirizzo IP
anonymous_enable: abilita l’accesso agli utenti anonimi
local_enable: abilita l’accesso agli utenti locali
anon_upload_enable: consente agli utenti anonimi di fare l’upload di
file
M. Ruta
Telematica II
A.A. 20062006-07
Posta Elettronica
• E’ basata su due componenti:
– User agent: applicativi client utilizzati dall’utente per comporre, inviare
e leggere messaggi
– Mail server: contengono i messaggi in ingresso/uscita degli utenti e
gestiscono le mailbox
• I principali protocolli utilizzati sono:
– SMTP (Simple Mail Transfer Protocol): protocollo utilizzato dai mail
server per il trasferimento dei messaggi
– invio dei messaggi da client a server
– interazione tra differenti mail server
– POP3/IMAP: protocolli per l’accesso alle mailbox
– POP3=Post Office Protocol ver. 3
– IMAP=Internet Message Access Protocol (si differenzia da POP3 perché consente
una migliore interattività con un mail server)
22 di 100
M. Ruta
Telematica II
Posta Elettronica (2)
A.A. 20062006-07
User
SMTP
Mail Server 1
Message queue
Agent 1
User
Agent 2
POP3/IMAP
session
User 1
User 2
Mail Server 2
Flusso del
messaggio
Mail Box
Message queue
•La disciplina della coda di messaggi sui mail server dipende dalla configurazione degli stessi
•Una mail box è fisicamente rappresentata da un file contenente i messaggi utente sul server
23 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Message
Sender
(SMTP Client)
SMTP
Message
Receiver
(SMTP Server)
SMTP session
Mail Client
Mail Server
Message queue
TCP connection
Port 25
• Struttura client/server del protocollo e modello di interazione request/response
• In linea generale è richiesta una procedura di autenticazione tra client e server
(allo scopo di evitare fenomeni di spamming)
Mail Box
•Basata su IP del client (pool di indirizzi autorizzati)
•Basata su accounting utente con meccanismi crittografici (SSL)
• Protocollo di tipo testuale command-based con comandi aventi sinossi del tipo
nomecomando [parametri]
24 di 100
M. Ruta
Telematica II
A.A. 20062006-07
•
•
•
•
•
•
•
•
Comandi SMTP
HELO <sender host name>
– identifica il client presso il mail server locale (esso mantiene un pool di IP
validi o garantisce autenticazione mediante username e password)
MAIL From: <sender of the message>
– identifica il mittente del messaggio mediante il suo indirizzo e-mail
RCPT To: <recipient of the message>
– specifica il destinatario del messaggio mediante il suo indirizzo e-mail
DATA <Body of the mail>
– specifica il contenuto del messaggio (chiuso da “.” in corrispondenza
dell’ultima linea di testo)
– contiene anche gli header (subject, cc, ccn)
QUIT
– chiude la sessione
RSET
– annulla il trasferimento corrente
VRFY <recipient to be verified>
– consente di verificare l’esistenza dell’indirizzo del destinatario
NOOP
– non esegue nessuna operazione, ma forza il server a rispondere con OK
– è adoperato per verificare che il server sia ancora in attività
25 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Risposte SMTP
220 <domain> servizio pronto
comando completato
250 comando completato con successo
con successo
251 utente non locale; la mail verrà inoltrata
354 iniziare l’inserimento del corpo della mail; terminare con richiesta di
interazione
<CRLF>.<CRLF>
421 <domain> servizio non disponibile
comando completato con
450 mailbox non disponibile
errori reversibili
451 errore locale nel processing
500 errore di sintassi: comando sconosciuto
501 errore di sintassi negli argomenti
comando completato con
502 comando non implementato
554 transazione fallita
26 di 100
errori irreversibili
M. Ruta
Telematica II
A.A. 20062006-07
Formato di un messaggio
Aprendo un messaggio SMTP con un editor di testo è possibile visualizzarne la struttura:
Envelope
MAIL From: <mittente>
RCPT To: <destinatario>
Headers
Received: by sun.tuc.noao.edu.
Date: Mon, 19 Jul 1993 12:47:31
Subject: testing
Body
Testo della mail
.
27 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di sessione SMTP
220 vsmtp1alice.tin.it ESMTP Service (7.0.027) ready
HELO [193.204.59.21]
250-vsmtp1alice.tin.it
MAIL FROM:<[email protected]> SIZE=329
250 MAIL FROM:<[email protected]> OK
RCPT TO:<[email protected]>
250 RCPT TO:<[email protected]> OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Message-ID: <[email protected]>
Date: Mon, 25 Jun 2007 11:48:06 +0200
From: Michele Ruta <[email protected]>
28 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di sessione SMTP
User-Agent: Mozilla Thunderbird 1.0.2-1.3.2
(X11/20070624)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [email protected]
Subject: prova
Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
Content-Transfer-Encoding: 7bit
.
250 <425E31F5001C5BCE> Mail accepted
QUIT
29 di 100
M. Ruta
Telematica II
A.A. 20062006-07
No.
…
Time
Esempio di sessione SMTP (2)
Source
Destination
24 4.457803
193.204.59.21 62.211.72.21
25 4.490016
ACK]
62.211.72.21
26 4.490115
193.204.59.21 62.211.72.21
Protocol Info
TCP
32791 > smtp(25) [SYN]
193.204.59.21 TCP
smtp(25) > 32791 [SYN,
TCP
32791 > smtp(25) [ACK]
27 4.520047 62.211.72.21 193.204.59.21 SMTP
smtp(25) > 32791
Response: 220 vsmtp1alice.tin.it ESMTP Service (7.0.027) ready
28 4.520125 193.204.59.21 62.211.72.21
Seq=1 Ack=55
TCP
32791 > smtp [ACK]
29 4.542552 193.204.59.21 62.211.72.21
HELO [193.204.59.21]
SMTP
32791 > smtp Command:
30 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di sessione SMTP (3)
…
…
219 32.733377 193.204.59.21 62.211.72.21
SMTP
32791 > smtp QUIT
220 32.749257 62.211.72.21 193.204.59.21 SMTP
221 vsmtp1alice.tin.it QUIT
smtp > 32791 Response:
221 32.749322 62.211.72.21
ACK]
smtp > 32791 [FIN,
193.204.59.21 TCP
222 32.788971 193.204.59.21 62.211.72.21
TCP
32791 > smtp [ACK]
225 32.893038 193.204.59.21 62.211.72.21
ACK]
TCP
32791 > smtp [FIN,
193.204.59.21 TCP
smtp > 32791 [ACK]
226 32.904869 62.211.72.21
31 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Multipurpose Internet Mail Extensions
(MIME)
• Estensioni utili per trasferire contenuti differenti dal testo
ASCII (immagini, audio, video, etc …)
• Sono basate su header aggiuntivi che caratterizzano i
contenuti del messaggio
32 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Header MIME
• Mime-Version: versione dello standard
• Content-Type: tipo di contenuto
–
–
–
–
text/plain : testo puro
text/html : testo html (formattazione avanzata)
image/jpeg : immagine jpeg
video/mpeg : video mpeg
• Content-Transfer-Encoding: tipo di codifica idonea al
contenuto del messaggio
33 di 100
M. Ruta
Telematica II
POP3
A.A. 20062006-07
•Struttura client/server del protocollo e
modello di interazione request/response
•È richiesta una procedura di
autenticazione tra client e server
•allo scopo di identificare
univocamente una mailbox
•basata su accounting utente mediante
inserimento di username e password
User
Agent
POP3/IMAP
session
User
Mail Server
Message queue
•Protocollo di tipo testuale commandbased con comandi aventi sinossi del tipo
nomecomando [parametri]
•Risposta di tipo testuale priva di codici
numerici di riferimento
34 di 100
M. Ruta
Telematica II
A.A. 20062006-07
POP3: comandi principali
• USER <username>
– identifica l’utente
• PASS <password>
– fornisce la password
• STAT
– mostra il mailbox status (numero di messaggi). Avvia una transazione
• LIST
– lista dei messaggi (ordinale di ciascun messaggio e spazio occupato)
• RETR n
– recupera il messaggio “n” dal server
• DELE n
– marca il messaggio “n” da cancellare (verrà cancellato nella fase di
update)
• TOP nmsg nlinee
– mostra solo “nlinee” linee del messaggio “nmsg”
• QUIT
– cancella i messaggi marcati da cancellare e chiude la connessione
35 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di sessione POP3
+OK dovecot ready.
USER michi
+OK
PASS ciao
+OK Logged in.
STAT
+OK 6 25642
LIST
+OK 6 messages:
1 4935
2 1218
3 1218
36 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Return-Path: <[email protected]>
X-Original-To: [email protected]
X-Original-To: [email protected]
Delivered-To: [email protected]
Delivered-To: [email protected]
Received: from localhost (aspoliba.poliba.it [192.168.1.2])
Received: from localhost (aspoliba.poliba.it [192.168.1.2])
by mail.poliba.it (Postfix) with ESMTP id 37D82EA46B
by mail.poliba.it (Postfix) with ESMTP id 37D82EA46B
for <[email protected]>; Fri, 22 Jun 2007 17:55:30 +0200 (CEST)
Received: from mail.poliba.it ([192.168.1.3])
Received: from mail.poliba.it ([192.168.1.3])
by localhost (aspoliba.poliba.it [192.168.1.2]) (amavisd-new, port 10024)
by localhost (aspoliba.poliba.it [192.168.1.2]) (amavisd-new, port 10024)
with ESMTP id 18629-06-5 for <[email protected]>;
with ESMTP id 18629-06-5 for <[email protected]>;
Fri, 22 Jun 2007 18:11:21 +0200 (CEST)
Fri, 22 Jun 2007 18:11:21 +0200 (CEST)
Received: from mail.cs.umn.edu (mail.cs.umn.edu [128.101.35.202])
Received: from mail.cs.umn.edu (mail.cs.umn.edu [128.101.35.202])
by mail.poliba.it (Postfix) with ESMTP id 1DB2EEB3F4
by mail.poliba.it (Postfix) with ESMTP id 1DB2EEB3F4
Received: from localhost (localhost [127.0.0.1])
Received: from localhost (localhost [127.0.0.1])
by augustus.cs.umn.edu (Postfix) with ESMTP id 8936C5C4E7
by augustus.cs.umn.edu (Postfix) with ESMTP id 8936C5C4E7
for <[email protected]>; Fri, 22 Jun 2007 10:49:58 -0500 (CDT)
for <[email protected]>; Fri, 22 Jun 2007 10:49:58 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.umn.edu
X-Virus-Scanned: amavisd-new at cs.umn.edu
Received: from mail.cs.umn.edu ([127.0.0.1])
Received: from mail.cs.umn.edu ([127.0.0.1])
by localhost (mail.cs.umn.edu [127.0.0.1]) (amavisd-new, port 10024)
by localhost (mail.cs.umn.edu [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id Gn8SN8sNSg1Z; Fri, 22 Jun 2007 10:49:52 -0500 (CDT)
with LMTP id Gn8SN8sNSg1Z; Fri, 22 Jun 2007 10:49:52 -0500 (CDT)
Received: from sabinus.cs.umn.edu (sabinus.cs.umn.edu [128.101.35.203])
Received: from sabinus.cs.umn.edu (sabinus.cs.umn.edu [128.101.35.203])
by mail.cs.umn.edu (Postfix) with ESMTP id B27805C4E8;
by mail.cs.umn.edu (Postfix) with ESMTP id B27805C4E8;
Fri, 22 Jun 2007 10:49:45 -0500 (CDT)
Fri, 22 Jun 2007 10:49:45 -0500 (CDT)
Received: (from www-r@localhost)
Received: (from www-r@localhost)
by sabinus.cs.umn.edu (8.9.3/8.9.0) id KAA14168;
by sabinus.cs.umn.edu (8.9.3/8.9.0) id KAA14168;
Fri, 22 Jun 2007 10:49:44 -0500 (CDT)
Fri, 22 Jun 2007 10:49:44 -0500 (CDT)
Date: Fri, 22 Jun 2007 10:49:44 -0500 (CDT)
Date: Fri, 22 Jun 2007 10:49:44 -0500 (CDT)
Message-Id: <[email protected]>
Message-Id: <[email protected]>
Subject: early registration for ICEC'07 64
Subject: early registration for ICEC'07 64
From: [email protected]
From: [email protected]
Cc: [email protected]
Cc: [email protected]
Reply-to: [email protected]
Reply-to: [email protected]
X-Virus-Scanned: amavisd-new at poliba.it
X-Virus-Scanned: amavisd-new at poliba.it
X-UIDL:
\,Q"!~#F"!ooF"!;2B"!
Protocolli
di livello applicativo
M. Ruta
X-UIDL: \,Q"!~#F"!ooF"!;2B"!
Esempio di sessione POP3 (2)
4 3080
5 4512
6 10679
.
RETR 1
+OK 4935 octets
Received: from mail.cs.umn.edu (mail.cs.umn.edu
[128.101.35.202]) by mail.poliba.it (Postfix) with
ESMTP id 1DB2EEB3F4 for <[email protected]>; Fri,
22 Jun 2007 17:55:03 +0200 (CEST)
.
QUIT
+OK Logging out.
37 di 100
Telematica II
A.A. 20062006-07
No.
Time
Source
Destination
4458 6.968872 193.204.59.21 193.204.49.50
pop3(110) [SYN] Seq=0 Ack=0
Prot
TCP
Info
32796 >
4464 6.974523 193.204.49.50 193.204.59.21 TCP
32796 [SYN, ACK] Seq=0 Ack=1
pop3 >
4465 6.974601 193.204.59.21 193.204.49.50 TCP
pop3 [ACK] Seq=1 Ack=1
32796 >
4469 6.976746 193.204.49.50 193.204.59.21 POP
32796 Response: +OK dovecot ready.
pop3 >
4470 6.976813 193.204.59.21 193.204.49.50 TCP
pop3 [ACK] Seq=1 Ack=21
32796 >
38 di 100
M. Ruta
Telematica II
A.A. 20062006-07
4479 6.990839 193.204.59.21 193.204.49.50 POP
pop3 Request: USER mruta
…
32796 >
4482 6.994185 193.204.49.50 193.204.59.21 POP
32796 Response: +OK
…
pop3 >
4515 7.038836 193.204.59.21 193.204.49.50 POP
pop3 Request: RETR 1
…
32796 >
4517 7.043860 193.204.49.50 193.204.59.21 POP pop3 >
32796 Response: +OK 4935 octets
Return-Path: [email protected] Received: from
mail.cs.umn.edu (mail.cs.umn.edu [128.101.35.202]) by
mail.poliba.it (Postfix) with ESMTP id 1DB2EEB3F4 for
<[email protected]>; Fri, 22 Jun 2007 17:55:03 +0200
(CEST)
.
39 di 100
M. Ruta
Telematica II
A.A. 20062006-07
No.
Time
4664 7.262057
Request: QUIT
Source
193.204.59.21
Destination
Prot Info
193.204.49.50 POP 32796 > pop3
4665 7.264080 193.204.49.50
Response: +OK Logging out.
193.204.59.21
POP
pop3 > 32796
4666 7.265700
[FIN, ACK]
193.204.49.50
193.204.59.21
TCP
pop3 > 32796
4667 7.265720
[ACK]
193.204.59.21
193.204.49.50
TCP
32796 > pop3
4674 7.274250
[FIN, ACK]
193.204.59.21
193.204.49.50
TCP
32796 > pop3
4675 7.275973
[ACK]
193.204.49.50
193.204.59.21
TCP
pop3 > 32796
…
40 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Internet Message Access Protocol (IMAP)
• E’ un protocollo per accedere a messaggi di mail su un server
remoto
• A differenza di POP3, è pensato per la manipolazione delle
mailboxes online, senza bisogno di scaricare in locale i messaggi
• Consente l’accesso ad una stessa mailbox da più PC
contemporaneamente
• Consente di:
–
–
–
–
41 di 100
Creare, eliminare e rinominare mailbox
Controllare l’arrivo di nuovi messaggi
Rimuovere messaggi
Effettuare ricerche all’interno dei messaggi
M. Ruta
Telematica II
A.A. 20062006-07
DNS: Domain Name Service
• Realizza una corrispondenza fra gli indirizzi IP numerici ed i nomi logici
–
–
•
sisinflab.poliba.it Æ 193.204.49.75
www.google.it Æ 66.233.183.104
Alias di posta: fornisce l’indirizzo IP o l’hostname del Mail Server di un dominio
– [email protected] (query MX)
• Esso consiste di:
– uno schema gerarchico di nominazione, basato sul concetto di dominio
(domain)
– un database distribuito che implementa lo schema gerarchico di
nominazione
– un protocollo per il mantenimento e la distribuzione delle informazioni
sulle corrispondenze
– Interrogazione tra DNS
– Interrogazione client/DNS
42 di 100
M. Ruta
Telematica II
A.A. 20062006-07
top level
domains
second level
domains
conversione
IP-hostname
arpa
Organizzazione dello spazio dei nomi
com
edu
gov
in-addr
noao
140
tuc
252
sun
13
int
mil
net
org
ae
…
Ciascuna
Ciascunalabel
label
può
essere
può esserelunga
lunga
63
63caratteri
caratteri
us
…
zw
va
reston
cnri
sun.tuc.noao.edu.
Fully Qualified Domain Name
(FQDN)
cnri.reston.va.us.
33
33.13.252.140.in-addr.arpa.
generic domains
43 di 100
country domains
M. Ruta
Telematica II
A.A. 20062006-07
Organizzazione dello spazio dei nomi (2)
•
I top level domains vengono gestiti direttamente dal NIC (Network
Information Center) che ha sede in ogni nazione e si incarica
dell'assegnazione e del mantenimento dei nomi a dominio nel country code
Top Level Domain “it” (ISO 3166)
•
Per le altre zone (nodi dell’albero DNS) , il NIC delega la gestione alle
singole organizzazioni
•
Per ciascuna zona ci deve essere un server primario (autoritativo per
quella zona) ed uno o più secondari per scopi di ridondanza
• Un server autoritativo gestisce direttamente le corrispondenze di un dominio
(garanzia di una conversione corretta)
• I server secondari mantengono copia delle corrispondenze aggiornata
dinamicamente mediante query periodiche al DNS primario (allineamento
automatico dei dati)
•
Per servire il nodo radice esistono i cosiddetti root name server
44 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Root name server
• Vi sono 13 root name server al mondo
• Essi corrispondono al dominio di livello piu alto: . (punto, o root)
• Ogni root name server mantiene le corrispondenze con gli indirizzi
dei top level domains
45 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Principio di funzionamento
• L’ host host1.poliba.it desidera
conoscere l’indirizzo IP di
Root name server
host2.mydomain.eu
Contatta il server DNS locale,
dns.poliba.it
dns.poliba.it contatta un name
server di livello superiore o il root
name server se necessario
dns.poliba.it
Il root name server contatta il top
dns.mydomain.eu
level domain .eu il quale conoscce
l’indirizzo del name server di
riferimento, dns.mydomain.eu
Ogni host è registrato in almeno
due name server assoluti
host1.poliba.it
host2.mydomain.eu
Questo meccanismo di risoluzione è
ricorsivo
46 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Local
name
server
Risoluzione iterativa
Root
name
server
• Occupazione di banda da parte del
client moltiplicata
• Maggiore carico computazionale sul
client
• Dal punto di vista del client è
preferibile la soluzione ricorsiva, ma
la soluzione iterativa potrebbe essere
a minore delay
Query
Authoritative
name server
47 di 100
Iterative
Reply
Authoritative
Reply
M. Ruta
Telematica II
A.A. 20062006-07
Risposta non autoritativa
Root
name
server
• Le cache dei local name server
contengono precedenti risoluzioni
• Riduzione dei delay
• Possibile non completa correttezza
Local
name
server
dei risultati a causa di meccanismi
fraudolenti di alterazione delle cache
DNS
• È indispensabile distinguere risposte
autoritative da risposte non
autoritative
I DNS
implementano
meccanismi di
caching
48 di 100
Query
Non Authoritative
Reply
M. Ruta
Telematica II
Formato di un messaggio DNS
A.A. 20062006-07
15 16
0
Identificazione
identifcativo univoco intero
a 16 bit del messaggio
(transaction ID)
31
Flags
Numero di
domande
Numero di
Risposte RR
Numero di
RR assoluti
Numero di
RR aggiuntivi
Domande
(numero di domande variabile)
Un
UnResource
ResourceRecord
Record(RR)
(RR)
èèuna
struttura
dati
atta
una struttura dati attaaa
contenere
contenereuna
unareply
replyDNS
DNS
risposte autoritative
Resource Record (RR)
49 di 100
Risposte
(numero variabile di RR)
Assoluti
proprietà generali del
pacchetto
(richiesta/risposta)
la variabilità del contenuto
impone la presenza di una
intestazione
risposte convenzionali
Resource Record (RR)
Informazioni aggiuntive
M. Ruta
Telematica II
Flags
A.A. 20062006-07
QR opcode AA TC RD RA
1
4
1 1
1 1
3
rcode
4
QR 0: query, 1: risposta
opcode 0: standard query (name→IP), 1: query inversa (IP→name), 2: server status,
3: …
AA 1: name server autoritativo per il dominio nella query
TC 1: le dimensioni della risposta superano 512 byte (massima dimensione PDU
UDP)
RD 1: query ricorsiva, 0: query iterativa
RA 1: il server supporta la risoluzione ricorsiva
rcode return code. 0: nessun errore, 3: errore nel nome (3 bit non adoperati)
50 di 100
M. Ruta
Telematica II
Formato del Resource Record (RR)
A.A. 20062006-07
0
15 16
31
nome dominio
tipo
classe
time-to-live
lunghezza dati
dati
tipo: 1 indica che è richiesto un indirizzo IP per quel nome di dominio (query di tipo A, name2IP), 12
indica che si richiede l’hostname corrispondente ad un indirizzo IP (PTR query, IP2name)
classe: normalmente è 1 per gli indirizzi Internet
time-to-live: tempo (in secondi) per cui il RR sarà nella cache del resolver (client)
lunghezza dati: numero di byte del campo dati
51 di 100
M. Ruta
Telematica II
Pacchetto di query tipo A
A.A. 20062006-07
No.
1405
Time
Source
3.853009 193.204.59.21
Destination
193.204.49.36
Protocol Info
DNS
Standard query A
www.google.it
DNS primario dominio poliba.it
Flags: 0x0100
0... ....
.000 0...
.... ..0.
.... ...1
.... ....
.... ....
(Standard
.... ....
.... ....
.... ....
.... ....
.0.. ....
...0 ....
query)
Messaggio non eccedente 512 B
= Response: Message is a query
= Opcode: Standard query (0)
= Truncated: Message is not truncated
= Recursion desired: Do query recursively
= Z: reserved (0)
= Non-authenticated data OK:
Queries/Answers/Authority/Additional
Q/A/AA/AD: 1/0/0/0
Queries
Name: www.google.it: type A, class IN
Risposte non autoritative ammesse
Query in classe 1 (INternet)
52 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Pacchetto di risposta
No.
Time
Source
Destination
Protocol Info
1406 3.857705 193.204.49.36 193.204.59.21
DNS
Standard query response
CNAME www.google.com CNAME www.l.google.com A 66.249.85.104 A 66.249.85.99
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not
authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 4
Authority RRs: 4
Additional RRs: 4
53 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Pacchetto di risposta (2)
Canonical Name record (alias)
Answers
www.google.it: type CNAME, class IN, TTL
3d1h1m19s, cname www.google.com
www.google.com: type CNAME, class IN, TTL 8m18s,
cname www.l.google.com
www.l.google.com: type A, class IN, TTL 23s, addr
66.249.85.104
www.l.google.com: type A, class IN, TTL 23s, addr
66.249.85.99
Address record, corrispondenza diretta con un IP
54 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Pacchetto di risposta (3)
Corrispondenza con gli IP negli additional record
Authoritative nameservers
l.google.com: type NS, class IN, ns b.l.google.com
l.google.com: type NS, class IN, ns c.l.google.com
l.google.com: type NS, class IN, ns d.l.google.com
l.google.com: type NS, class IN, ns a.l.google.com
Additional records
b.l.google.com: type A, class IN, addr 64.233.179.9
c.l.google.com: type A, class IN, addr 64.233.161.9
d.l.google.com: type A, class IN, addr 64.233.183.9
a.l.google.com: type A, class IN, addr 216.239.53.9
55 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Pointer Query
•
Dato l’indirizzo IP di una macchina, si vuole conoscere l’hostname
•
A questo scopo si utilizza la parte del namespace in-addr.arpa
•
Il nome DNS corrispondente, ad esempio, all’indirizzo IP 140.252.13.33 è
33.13.252.140.in-addr.arpa
•
Sulle macchine Unix è possibile usare il seguente comando per fare questa
query:
host 140.252.13.34
Name: svr4.tuc.nao.edu
56 di 100
M. Ruta
Telematica II
A.A. 20062006-07
No.
1457
Time
2.292224
Source
193.204.59.21
Esempio di PTR Query
Destination
193.204.49.36
Prot. Info
DNS
Standard query PTR
227.59.204.193.in-addr.arpa
User Datagram Protocol, Src Port: 4943 (4943), Dst Port: domain (53)
Domain Name System (query)
Transaction ID: 0x0004
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is
unacceptable
Questions: 1, Answer RRs: 0, Authority RRs: 0, Additional RRs: 0
Queries
227.59.204.193.in-addr.arpa: type PTR, class IN
57 di 100
M. Ruta
Telematica II
A.A. 20062006-07
No. Time
1461 2.299882
Esempio di PTR Query: risposta
Source
193.204.49.36
Destination
193.204.59.21
Protocol Info
DNS
Standard query response PTR
dee227.poliba.it
User Datagram Protocol, Src Port: domain (53), Dst Port: 4943 (4943)
Domain Name System (response)
Transaction ID: 0x0004
Flags: 0x8580 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.... .1.. .... .... = Authoritative: Server is an authority for domain
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not
authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 4
Additional RRs: 4
58 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di PTR Query: risposta (2)
Answers
227.59.204.193.in-addr.arpa: type PTR, class IN, dee227.poliba.it
Name: 227.59.204.193.in-addr.arpa
Type: PTR (Domain name pointer)
Class: IN (0x0001)
Time to live: 12 hours
Data length: 18
Domain name: dee227.poliba.it
59 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di PTR Query: risposta (3)
Authoritative nameservers
59.204.193.in-addr.arpa: type NS, class IN, ns cstar.poliba.it
59.204.193.in-addr.arpa: type NS, class IN, ns server2.garr.net
59.204.193.in-addr.arpa: type NS, class IN, ns anthares.poliba.it
59.204.193.in-addr.arpa: type NS, class IN, ns dns2.nic.it
Additional records
cstar.poliba.it: type A, class IN, addr 193.204.49.36
server2.garr.net: type A, class IN, addr 131.154.1.11
anthares.poliba.it: type A, class IN, addr 193.204.49.37
dns2.nic.it: type A, class IN, addr 193.205.245.8
60 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Query MX (Mail eXchange)
• Quando un messaggio e-mail viene inviato via Internet, il Mail
Transfer Agent (MTA) del mittente effettua una query DNS di tipo
MX per il nome di dominio del destinatario, che è la porzione
dell’indirizzo e-mail che segue la "@“
• Questa query restituisce una lista di host name dei mail exchange
servers che sono in grado di accettare la posta in ingresso per quel
dominio, insieme ad un preference number. L’MTA iniza ad inviare la
posta al server con preference number più basso
• Il meccanismo di query MX fornisce la possibilità di avere mail
servers multipli per un singolo dominio
61 di 100
M. Ruta
Telematica II
Comando nslookup
A.A. 20062006-07
• Comando nslookup
– Effettua una query al DNS per ottenere l’indirizzo IP a partire da un
dato hostname:
$ nslookup sisinflab.poliba.it
Server:
Address:
193.204.49.36
193.204.49.36#53
sisinflab.poliba.it
canonical name = www-cirp.poliba.it.
Name:
www-cirp.poliba.it
Address: 193.204.59.75
62 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Comando host
• Comando host
– Conversione hostname → indirizzo IP:
$ host sisinflab.poliba.it
sisinflab.poliba.it is an alias for www-cirp.poliba.it
www-cirp.poliba.it has address 193.204.59.75
– Conversione indirizzo IP → hostname:
$ host 193.204.59.227
227.59.204.193.in-addr.arpa domain name pointer
dee227.poliba.it
63 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Comando host (2)
Il comando host può essere anche utilizzato per query di
tipo MX:
$ host -t MX poliba.it
poliba.it mail is handled by 10 mail.poliba.it
poliba.it mail is handled by 20 anthares.poliba.it
64 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Comando dig
• Il comando dig (domain information groper) è un
flessibile strumento per interrogare i name server
• Sintassi:
dig name type
dove name è il nome della risorsa
type è il tipo di query (A, PTR, CNAME, MX, …)
65 di 100
M. Ruta
Telematica II
A.A. 20062006-07
$
Esempio di query di tipo A con dig
dig sisinflab.poliba.it A
; <<>> DiG 9.3.1 <<>> sisinflab.poliba.it A
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15837
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4,
ADDITIONAL: 4
;; QUESTION SECTION:
;sisinflab.poliba.it.
;; ANSWER SECTION:
sisinflab.poliba.it.
cirp.poliba.it.
www-cirp.poliba.it.
193.204.59.75
66 di 100
IN
A
43200
IN
CNAME
43200
IN
A
www-
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di query di tipo A con dig (2)
;; AUTHORITY SECTION:
poliba.it.
poliba.it.
poliba.it.
poliba.it.
604800
604800
604800
604800
IN
IN
IN
IN
NS
NS
NS
NS
cstar.poliba.it.
server2.garr.net.
anthares.poliba.it.
dns2.nic.it.
;; ADDITIONAL SECTION:
cstar.poliba.it.
server2.garr.net.
anthares.poliba.it.
dns2.nic.it.
43200
74326
172800
74049
IN
IN
IN
IN
A
A
A
A
193.204.49.36
193.206.141.38
193.204.49.37
193.205.245.8
;;
;;
;;
;;
Query time: 5 msec
SERVER: 193.204.49.36#53(193.204.49.36)
WHEN: Mon May 29 15:51:49 2006
MSG SIZE rcvd: 236
67 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di PTR query con dig
dig 75.59.204.193.in-addr.arpa PTR
; <<>> DiG 9.3.1 <<>> 75.59.204.193.in-addr.arpa PTR
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
28478
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY:
4, ADDITIONAL: 4
;75.59.204.193.in-addr.arpa.
IN
;; ANSWER SECTION:
75.59.204.193.in-addr.arpa. 43200 IN
cirp.poliba.it
68 di 100
PTR
PTR
www-
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di PTR query con dig (2)
59.204.193.in-addr.arpa.
cstar.poliba.it.
server2.garr.net.
anthares.poliba.it.
dns2.nic.it.
;;
;;
;;
;;
604800
604800
604800
604800
43200
73768
172800
73491
IN
IN
IN
IN
NS
NS
NS
NS
cstar.poliba.it.
server2.garr.net.
anthares.poliba.it.
dns2.nic.it.
IN
IN
IN
IN
A
A
A
A
193.204.49.36
193.206.141.38
193.204.49.37
193.205.245.8
Query time: 7 msec
SERVER: 193.204.49.36#53(193.204.49.36)
WHEN: Mon May 29 16:01:08 2006
MSG SIZE rcvd: 236
69 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di query MX con dig
dig poliba.it MX
; <<>> DiG 9.3.1 <<>> poliba.it MX
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14562
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL:
5
;poliba.it.
;; ANSWER SECTION:
poliba.it.
poliba.it.
70 di 100
172800
172800
IN
MX
IN
IN
MX
MX
10 mail.poliba.it.
20 anthares.poliba.it.
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di query MX con dig (2)
poliba.it.
poliba.it.
poliba.it.
poliba.it.
604800
604800
604800
604800
IN
IN
IN
IN
NS
NS
NS
NS
cstar.poliba.it.
server2.garr.net.
anthares.poliba.it.
dns2.nic.it.
mail.poliba.it.
anthares.poliba.it.
cstar.poliba.it.
server2.garr.net.
dns2.nic.it.
43200
172800
43200
73632
73355
IN
IN
IN
IN
IN
A
A
A
A
A
193.204.49.50
193.204.49.37
193.204.49.36
193.206.141.38
193.205.245.8
;;
;;
;;
;;
Query time: 7 msec
SERVER: 193.204.49.36#53(193.204.49.36)
WHEN: Mon May 29 16:03:24 2006
MSG SIZE rcvd: 240
71 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Il comando whois
Per ottenere informazioni sulla registrazione di un certo dominio, si utilizza il comando whois
(interrogazione al livello del NIC):
$ whois poliba.it
domain:
org:
descr:
admin-c:
tech-c:
postmaster:
zone-c:
zone-c:
nserver:
nserver:
nserver:
dom-net:
dom-net:
dom-net:
dom-net:
remarks:
72 di 100
poliba.it
Politecnico di Bari
Technical University
CP1399-ITNIC
VG371-ITNIC
LG804-ITNIC
VG371-ITNIC
LG804-ITNIC
193.204.49.36 deecom04.poliba.it
dns2.nic.it
area.area.ba.cnr.it
193.204.48.0 193.204.49.0 193.204.50.0
193.204.52.0 193.204.53.0 193.204.54.0
193.204.56.0 193.204.57.0 193.204.58.0
193.204.60.0 193.204.61.0 193.204.62.0
Fully-managed
193.204.51.0
193.204.55.0
193.204.59.0
193.204.63.0
M. Ruta
Telematica II
A.A. 20062006-07
Il comando whois
mnt-by:
created:
expire:
source:
GARR-MNT
before 960129
20170129
IT-NIC
person:
address:
address:
address:
nic-hdl:
source:
Carmine Pappalettere
DPPI - Politecnico di Bari
viale Japigia, 182
I-70126 Bari
CP1399-ITNIC
IT-NIC
person:
address:
address:
address:
nic-hdl:
source:
Valentino Gratton
CECAP - Politecnico di Bari
via Orabona, 4
I-70125 Bari
VG371-ITNIC
IT-NIC
person:
address:
address:
address:
nic-hdl:
source:
Luigi Gatto
CECAP - Politecnico di Bari
via Orabona, 4
I-70125 Bari
LG804-ITNIC
IT-NIC
73 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Server DNS BIND
• Il più diffuso server DNS è BIND (Berkeley Internet Name Domain
server). Il daemon del server viene chiamato named
• Ci sono 2 configurazioni tipiche:
– Authoritative-only nameserver
• Risolve solo gli indirizzi del dominio per cui è autoritativo
– DNS caching server
• Risolve tutti gli indirizzi, memorizzandoli in una cache. Non è autoritativo
• Può essere installato su una macchina personale per velocizzare le richieste
DNS grazie al caching
74 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Configurazione di un caching name server
Il file di configurazione principale è /etc/named.conf:
// directory dove vengono cercati i file di configurazione
options {
directory "/var/named";
};
// nel file root.hints ci sono gli indirizzi IP dei root name servers
zone "." {
type hint;
file "root.hints";
};
// Questo comando significa che stiamo definendo la zona
// 0.0.127.in-addr.arpa, che il nostro è il server primario e che le
// informazioni per questa zona sono memorizzate in un file chiamato
// pz/127.0.0.
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
75 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Configurazione di una zona
Il file di configurazione di una zona ha il seguente formato (file pz/127.0.0). In esso sono definiti 3
Resource Records: SOA (Start of Authority), NS (Name server) e PTR
$TTL 3D
// descrive la zona, il suo name server, il responsabile, la versione del file(1),
// impostazioni per il caching, il name server secondario ed il TTL
@
IN
SOA
ns.linux.bogus. hostmaster.linux.bogus. (
1
; Serial
8H
; Refresh
2H
; Retry
4W
; Expire
1D)
; Minimum TTL
// dice che il name server autoritativo per questo dominio è ns.linux.bogus.
NS
ns.linux.bogus.
// dice che l’host 127.0.0.1 ha come hostname localhost
1
PTR
localhost.
76 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Reti peer-to-peer
• Una rete di computer peer-to-peer (P2P) sfrutta
principalmente la potenza di calcolo e la bandwidth di
tutti i partecipanti alla rete piuttosto che concentrarla su
un relativamente piccolo numero di server
• Tali reti sono utili per diversi scopi:
– File sharing
– Trasmissione di dati in realtime, come ad esempio traffico
telefonico o di videoconferenza
77 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Reti peer-to-peer (2)
• Una rete peer-to-peer “pura” non prevede il concetto di
client o server, ma solo nodi peer paritetici che a
seconda dei casi agiscono sia da "client" che da "server"
per gli altri nodi della rete
• Questo modello di organizzazione della rete differisce da
quello client-server dove solitamente la comunicazione è
verso o da un server centrale
78 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Classificazione
• Reti peer-to-peer pure:
– I peer agiscono come client e server
– Non esiste un server centrale che gestisce la rete
– Non esiste un router centrale
• Reti peer-to-peer ibride:
– Hanno un server centrale che mantiene le informazioni sui peers
– I peer si occupano della memorizzazione delle risorse, rendono
note al server centrale le risorse condivise e consentono il
download delle risorse ai peer che le richiedano
79 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Vantaggi delle reti P2P
•
Una caratteristica importante delle reti peer-to-peer è che tutti i client
forniscono risorse quali bandwidth, storage, e capacità di calcolo
•
Al crescere del numero di peer, la capacità totale del sistema aumenta di
conseguenza. Ciò non è vero per una architettura client-server con un
numero fisso di server, in cui aggiungere nuovi client potrebbe significare
trasferimento dati più lento per tutti gli utenti
•
La natura distribuita delle reti peer-to-peer aumenta la robustezza in caso di
guasti replicando i dati su peer multipli, e – nelle reti P2P pure –
consentendo ai peer di trovare i dati senza utilizzare un index server
centralizzato
•
Configurazione dinamica della rete, mancata necessità di apparati costosi
80 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Attacchi alle reti P2P
• poisoning attacks (fornire file i cui contenuti sono diversi da quelli
descritti, possibilità di effettuare un’anteprima)
• polluting attacks (inserire chunk/pacchetti “cattivi” in un file valido)
• defection attacks (utenti o software che fanno uso della rete senza
contribuire ad essa condividendo risorse, penalizzazione di utenti
non partecipativi)
• inserimento di virus nei dati trasportati (i file scaricati potrebbero
essere infetti da virus o malware)
• malware nel software di rete stesso (il software distribuito contiene
spyware: clamoroso il caso kazaa che contiene spyware)
81 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Attacchi alle reti P2P (2)
• denial of service attacks (attacchi che rendono la rete molto lenta
saturandola di richieste tanto da farla apparire come fuori servizio)
• filtering (gli operatori di rete potrebbero impedire il transito dei
pacchetti delle rete p2p imponendo restrizioni su alcune delle porte
più tipicamente adoperate)
• identity attacks (identificare gli utenti della rete e perseguirli
legalmente approfittando del passaggio in chiaro degli IP)
• spamming (inviare informazioni non richieste agli utenti attraverso
la rete)
82 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Esempio di rete P2P: BitTorrent
• BitTorrent è un protocollo per reti P2P ibride progettato per
distribuire grandi quantità di dati senza far uso di costosi server e
senza necessitare di grande larghezza di banda
• E’ stato ideato nel 2001 da Bram Cohen
• Si basa sul principio che durante il trasferimento di un file, chi
scarica lascia inutilizzata la propria banda in uscita:
• BT risolve lo spreco facendo sì che un client faccia scaricare lo
stesso file ad altri client, usando la propria banda in upload
83 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Schema di funzionamento di BT
Seeder
Tracker
Leechers
Connessione al Tracker
Download dal Seeder
84 di 100
Scambio file tra Leechers
M. Ruta
Telematica II
A.A. 20062006-07
Funzionamento di BT
•
Si scarica, da un web server, un file .torrent contenente informazioni sul
file che si vuole scaricare
•
Si usa il client BT per aprire il file .torrent e collegarsi al Tracker, un
server che contiene la lista dei Seeder (client che dispongono di tutto il file)
e dei Leecher (client che dispongono solo di una parte del file)
•
Il download vero e proprio avviene sia dai Seeder che dagli altri Leecher
•
Quindi la macchina di un utente fa sia da client che da server in riferimento
a sessioni diverse
•
E’ necessario un server centrale (Tracker) per coordinare lo scambio dei file
•
Il vantaggio è quello di “spalmare” il consumo di banda visto che il tracker è
solo un lookup service rispetto a FTP (alcune distribuzioni Linux vengono
diffuse via BitTorrent)
85 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Limiti del protocollo
• BitTorrent non offre ai suoi utenti l’anonimato. Poichè i tracker
mantengono una lista dei nodi che condividono file, è possibile
ottenere l’indirizzo IP sia degli utenti correnti ed anche di quelli che
hanno condiviso file in precedenza (utilizzo di file di log)
• In mancanza di seeder un download non può essere portato a
conclusione
• Un tracker è un single point of failure
– Ridondanza dei tracker per migliorare l’affidabilità
• Gli utenti che condividono i file hanno poco incentivo a diventare
seeder dopo che hanno completato il loro download. Ciò si traduce
in una minore possibilità di ottenere i torrent più vecchi
86 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Paragone con altri sistemi P2P
• Il metodo usato da BitTorrent per distribuire i file è simile a quello
della rete eDonkey2000, ma i nodi di quest’ultima rete solitamente
condividono e scaricano un maggiore numero di file
• La bandwidth disponibile in upload per ciascun trasferimento è
ridotta di conseguenza (ciò è critico specie per connessioni digitali
DSL asimmetriche)
• I trasferimenti su BitTorrent sono solitamente molto veloci, poiché
ogni istanza del client si concentra nel trasferimento di un singolo
file
• Molti nuovi sistemi P2P hanno dei meccanismi per incentivare
l’upload dei file. Ad esempio eMule ha un sistema di crediti in cui un
nodo “ringrazia” gli altri nodi che gli forniscono file incrementando la
loro priorità nella sua coda
87 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Paragone con altri sistemi P2P (2)
• BitTorrent non fornisce un metodo per indicizzare i file condivisi. La
conseguenza di ciò è che pochi web server sono disposti ad ospitare
i file .torrent
• Sono disponibili un minor numero di file rispetto alla rete eDonkey
che ingloba un servizio di indicizzazione
• Recentemente, Bram Cohen ha rilasciato un proprio BitTorrent
search engine, che cerca i torrent nei più diffusi tracker BitTorrent,
anche se esso non ospita i file torrent stessi
• Uno degli obiettivi per la prossima versione 4.1.2 di BitTorrent è
l’uso di tracker distribuiti, che eliminerebbe il single point of failure
del sistema
88 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Codifica bencoding
• Tutti i dati presenti nel file torrent usano la codifica
bencoding
• Le stringhe sono codificate nel seguente modo:
<lunghezza stringa (decimale)>:<string data>
Esempio: 4:spam rappresenta la stringa "spam“
• Gli interi sono codificati nel seguente modo:
i<intero decimale in ASCII>e
Esempio: i3e rappresenta l’intero "3“
89 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Codifica bencoding (2)
• Le liste sono codificate nel seguente modo:
l<valori bencoded>e
Esempio: l4:spam4:eggse rappresenta la lista: ["spam", "eggs"]
• I dizionari sono codificati come coppie chiave/valore:
d<bencoded string><bencoded element>e
Esempio: d3:cow3:moo4:spam4:eggse rappresenta il dizionario:
{ "cow" ⇒ "moo", "spam" ⇒ "eggs" }
90 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Struttura del file .torrent
• Il contenuto del file .torrent è un dizionario bencoded, contenente le
seguenti chiavi:
– info(*) : un dizionario che descrive il file da scaricare
– announce(*): announce URL del tracker
– creation date: data di creazione del file (intero in formato UNIX epoch
[in sec a partire da 1/1/1970])
– comment: stringa con i commenti dell’autore
– created by: nome e versione del programma usato per generare il file
*: voce obbligatoriamente presente
91 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Struttura del file .torrent (2)
• Il dizionario info contiene le seguenti voci:
–
–
–
–
length(*): lunghezza del file in byte (intero)
md5sum: stringa di 32 caratteri hex con la md5 sum del file
name(*): nome del file (stringa)
piece length(*): lunghezza in byte di ciascun “pezzo” in cui è
suddiviso il file (intero)
– pieces (*): valore di hash a 20 byte calcolato con SHA1 per
ciascun chunk (meccanismo di error control a fingerprint)
• Info può contenere anche informazioni su file multipli
associati allo stesso file .torrent
92 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Protocollo usato dal tracker
• Il tracker è un servizio che risponde alle richieste HTTP GET
• GET consente di passare dei parametri (separati da “&”) con la
richiesta HTTP purché la loro dimensione non ecceda 1024 byte
(massima dimensione di una richiesta di un URI). I parametri
risultano essere visibili
• Le richieste includono delle metriche fornite dai client che aiutano il
tracker a mantenere delle statistiche globali
• Le risposte contengono una lista di peer che contengono il file da
scaricare
• I parametri vengono codificati nella URL (contenuta nel file .torrent)
93 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Parametri della richiesta
• info_hash: 20-byte SHA1 hash del valore del campo info nel
.torrent
• peer_id: stringa di 20-byte usata come ID per il client, generata
allo startup del client
• port: numero della porta su cui il client è in ascolto (tipicamente
6881-6889)
• uploaded: numero totale di byte trasferiti in upload
• downloaded: numero di byte scaricati
• left: numero di byte da scaricare
• event: uno tra i valori started, completed, stopped che indicano lo
stato del trasferimento
• ip: indirizzo IP del client (opzionale). Il tracker può comunque
dedurlo dalla connessione TCP
94 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Formato della risposta
• Il tracker risponde con un documento nel tipo MIME
text/plain contenente un dizionario bencoded con le
seguenti chiavi:
– failure reason: motivo del problema (se presente le altre chiavi
potrebbero non essere presenti)
– interval: intervallo, in secondi, che il client deve attendere
prima di mandare una nuova richiesta al tracker
•• Meccanismo
Meccanismodidicontrollo
controllodella
dellabanda
banda
– tracker id:• identificativo
univoco
del
tracker
• IIclient
clientpossono
possonomandare
mandareuna
unarichiesta
richiestaalaltracker
trackerprima
prima
– complete: numero
dei
peer
con
il
file
completo
(
seeders
)
del
termine
specificato,
solo
se
viene
invocato
un
evento
del termine specificato, solo se viene invocato un evento
(ad
stopped
completed)
se
– incomplete: numero
dei peer
conooparti
di file o(oleechers
) ha
(adesempio
esempio
stopped
completed)
seililclient
client
ha
bisogno
didiconoscere
un
maggior
di peer
bisogno
conoscere
unseguenti
maggiornumero
numero
– peers: è una lista
di dizionari
con le
chiavi: di peer
• peer id, ip, port
95 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Peer wire protocol
• Il peer protocol facilita lo scambio dei chunk come
descritto nel file .torrent
• Un client deve mantenere informazioni di stato per
ciascuna connessione attiva on un altro peer remoto:
– choked: indica se il peer remoto ha messo in stato di “choked”
questo client. Quando accade ciò il peer remoto non accetta
richieste da questo client
– interested: indica se il peer remoto è interessato a qualcosa
che il nodo corrente ha da offrire. E’ una notifica che il peer
remoto inizierà a richiedere blocchi quando il client lo pone in
stato “unchoked”
96 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Peer wire protocol (2)
• Un blocco viene scaricato dal client quando questo è
interessato in un peer, e quel peer non ha messo il client
in choking
• Viene fatto l’upload di un blocco da un client ad un peer
quando il client non ha messo in stato di choking il peer,
e quel peer è interessato al client
• E’ importante per il client tenere i suoi peer informati se
è interessato a blocchi da essi posseduti
97 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Message flow
• Il peer wire protocol consiste di un handshake iniziale
• Dopo questo, i peer comunicano attraverso uno scambio
di messaggi a lunghezza prefissata
98 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Handshake
• L’handshake è un messaggio obbligatorio e deve essere
il primo messaggio trasmesso dal client
• La sintassi è:
<pstrlen><pstr><reserved><info_hash><peer_id>
–
–
–
–
pstrlen: lunghezza di <pstr>, come singolo raw byte
pstr: stringa che identifica il protocollo
reserved: 8 byte riservati. (attualmente posti a 0)
info_hash: 20-byte SHA1 hash del valore del campo info nel file
torrent
– peer_id: 20-byte string usata come ID per il client
99 di 100
M. Ruta
Telematica II
A.A. 20062006-07
Formato dei messaggi
• Tutti i restanti messaggi del protocollo hanno la
seguente struttura:
<length prefix><message ID><payload>
length prefix è un valore a 4 byte big-endian
message ID è un singolo carattere
• Ad esempio il messaggio di choke:
choke: <len=0001><id=0>
unchoke: <len=0001><id=1>
interested: <len=0001><id=2>
100 di 100
M. Ruta

FTP, SMTP/POP3, DNS, reti P2P - SisInfLab

Transcript

Documenti analoghi

grappa ruta - Bertagnolli

Politecnico_Azioni_di_orientamento

Il blog non è soggetto a registrazione

Visualizza

Publiredazionale Repubblica

Serge Leroueil, PhD, P.Eng

software - Maurizio Gambino.it

Word processor - Prof. Crescenzio Gallo

Introduzione