Appunti sui servizi di rete storici

FTP 2
Come funziona FTP 2
Comandi FTP 3
FTP Attivo (e problemi) 4
FTP Passivo (soluzioni) 5

TELNET 6

EMAIL 9
MIME 11

WWW: World Wide Web 12

URL 12
HTML 12
HTTP 12

HTTP 13

Formato dei messaggi HTTP 14

Metodi HTTP 15
Codici di risposta (status code) 16
Connessione HTTP 17
Cookies 17
Autenticazione HTTP 18
Basic Authentication 18
Digest Authentication 19
Evoluzioni 20

Networking 101: Appunti di fine capitolo

morrolinux.it
 FTP
File Transfer Protocol

Il servizio di rete in questione è il “trasferimento file”, e come tale sarà composto di:
1. un client FTP
2. un server FTP
3. un protocollo applicativo: FTP

Come funziona FTP

FTP funziona sul protocollo di trasporto TCP e richiede 2 porte per funzionare:
● TCP/20: per il trasferimento file
● TCP/21: per il controllo

⇒ FTP è un protocollo “stateful”: mantiene lo stato della connessione

Il server FTP ricorderà, durante la sessione:

1. La directory in cui siamo
2. La nostra autenticazione (chi siamo)

Quando un utente vuole collegarsi ad un server FTP, userà il proprio client FTP per
mettersi in contatto col server.

Da riga di comando: ftp indirizzo.del.server.com

Ma esistono anche software con interfaccia grafica per fare ciò, come filezilla

Networking 101: Appunti di fine capitolo

morrolinux.it
 Comandi FTP
I comandi FTP non sono altro che “parole” di testo ASCII inviate sulla connessione di
controllo (aperta sulla porta 21).

L’autenticazione avviene con i comandi USER e PASS:

USER username
PASS password

Riepilogo dei comandi del protocollo FTP visti a lezione:

● “LIST”: per ricevere la lista dei contenuti della cartella attuale
● “CWD” (Change Working Directory) per spostarci in una cartella differente
● “RETR” (Retrive) per scaricare un file dal server
● “STOR” (store) per inviare un file sul server
(elenco completo)

A ciascuno di questi comandi il server risponde con un codice, come

● “331: username ok”
● “452: Error writing file“
● ...

Attenzione: FTP è considerato insicuro perché tutto ciò che è trasferito tra client e server
viene trasferito in chiaro (senza cifratura di alcun tipo!) ed è facilmente intercettabile.

Networking 101: Appunti di fine capitolo

morrolinux.it
 FTP Attivo (e problemi)

Nella sua accezione “classica” FTP è un protocollo attivo:

1. il client contatterà il server alla porta 21
2. stabilita la connessione, client e server inizieranno a scambiarsi messaggi
(comandi e codici di stato/errore) su questo canale.
3. Prima o poi il client chiederà di scaricare un file dal server, con il comando “GET”:

4. A questo punto, il server apre una nuova connessione TCP verso il client sulla
porta 20, per il trasferimento del file richiesto…

E qui sorgono i primi problemi:

Se il client è in una rete semi-privata

● La sua porta 20 non sarà direttamente esposta al pubblico e raggiungibile dal server!
● Inoltre Il server tenterà di aprire una nuova connessione verso la porta 20 del router
(pensando che sia il client)

Il problema è che il router non è in ascolto sulla porta 20, e trattandosi di una nuova
connessione, non è possibile fare SOURCE NATTING come per la navigazione web.

L’unica soluzione sarebbe fare DESTINATION NATTING, ovvero aprire una porta del router
che colleghi qualunque pacchetto ricevuto su tale porta al mio client.

La soluzione è stata introdotta nella variante “passiva” del protocollo FTP.

Networking 101: Appunti di fine capitolo

morrolinux.it
 FTP Passivo (soluzioni)
1. Il client inizia la connessione sulla porta di controllo (21)

2. Ad un certo punto richiede un file al server.

3. Il server, invece di aprire una connessione verso il client, rimane in attesa di una
nuova connessione su una delle sue porte libere, che comunica al client.
4. Il client apre una seconda connessione verso il server alla porta da lui specificata.

5. Ora il server può inviare al client il file richiesto tramite la connessione aperta.

In questo caso non ci sono problemi perché entrambe le connessioni (controllo e dati)
vengono aperte dal client.

Networking 101: Appunti di fine capitolo

morrolinux.it
 TELNET
Il protocollo TELNET opera su TCP ed è nato per il collegamento ad un terminale remoto.

Il funzionamento è semplice: tramite l’applicativo telenet, scriviamo:

telnet indirizzo.del.server.remoto

E siamo collegati ad una shell sul videoterminale remoto.

Telnet è in un certo senso il predecessore di ssh ma è ormai in disuso perché

considerato insicuro: tutto il traffico scambiato, come nel caso di FTP, è in chiaro, senza
nessun tipo di cifratura!

Anche TELNET è un protocollo “plaintext” ovvero la comunicazione avviene tramite

semplici messaggi di testo.

Per questa ragione, l’applicativo telnet può essere usato per collegarsi e dialogare con
qualunque altro server che usi un protocollo testuale, come appunto FTP:

Questo test è stato fatto su un server FTP pubblico: https://www.ietf.org/

(in realtà potete esplorarlo anche da browser tramite interfaccia web)

possiamo quindi collegarci con:

telnet ftp.ietf.org 21

USER anonymous
PASS qualunque
ci spostiamo in una cartella:
CWD ietf/ftpext/

e chiediamo al server di passare in modalità passiva prima di scaricare un file:

PASV

Networking 101: Appunti di fine capitolo

morrolinux.it
Riceviamo la risposta:

227 Entering Passive Mode (4,31,198,44,242,145).

Questi numeri sono indirizzo IP e porta a cui dobbiamo collegarci per ricevere il file:
IP: 4.31.198.44
Porta: dobbiamo moltiplicare la penultima cifra per 256 e sommarla all’ultima cifra:

Ora che conosciamo IP e porta sulla quale il server si è messo in ascolto, richiediamo il file
desiderato con il comando RETR (retrive):

RETR ftpext-charter.txt

Il server ci sta aspettando. Apriamo un’altra shell ed instauriamo il collegamento su quella

porta (sempre con telnet va bene):

Si tratta di un file di testo, quindi vedremo comparire a shell il contenuto del file...

Networking 101: Appunti di fine capitolo

morrolinux.it
...e la chiusura della connessione per il trasferimento dati.

Nella prima shell possiamo leggere i messaggi del server sulla connessione di controllo:
“150 Opening ASCII mode data..”
“226 Transfer complete”

Quando vogliamo terminare la connessione, scriviamo QUIT

Questo era solo un semplice esempio, con l’applicativo telnet possiamo “dialogare” con
qualunque servizio che usi un protocollo “testuale”!

Networking 101: Appunti di fine capitolo

morrolinux.it
 EMAIL
Concettualmente è piuttosto semplice: tutte le caselle mail con dominio morrolinux.it
risiedono sul mail server di morrolinux, stessa cosa per google.com e via dicendo.

Se invio una mail dal mio indirizzo info@morrolinux.it ad eva@gmail.com

1. Il mio programma di posta (MUA) inoltra l’email al mio mail server “locale”
(MX morrolinux.it)
2. Il mio mail server locale inoltra il messaggio al mail server responsabile di gmail.com
3. Il server di gmail.com “metterà” questa mail nella casella di eva.
4. Quando il MUA di eva scaricherà la posta dal mail server locale, vedrà la mia email.

Recap delle componenti viste a lezione:

● MUA: Mail User Agent (Outlook, Thunderbird, …)
● MSA: Mail Submission Agent (componente in ascolto per la ricezione di messaggi)
● MDA: Mail Delivery Agent (ES: Procmail, Dovecot, … )
● MTA: Mail Transfer Agent (ES: Postfix, Sendmail, …)

Cosa succede nel dettaglio (MITTENTE):

1. Sul mio mail server locale, il MSA riceve il messaggio dal client
2. Il MSA passa il messaggio al MTA
3. Il MTA lo inoltra al server mail di destinazione.

Il messaggio può anche passare per un server intermedio (relay) prima di raggiungere il
server di destinazione.

Networking 101: Appunti di fine capitolo

morrolinux.it
Cosa succede nel dettaglio (RICEVENTE):
4. Il MTA riceve il messaggio e lo passa al MDA
5. Il MDA può filtrare, categorizzare e ordinare i messaggi, sulla base del contenuto
6. Il MDA può analizzare il messaggio con programmi esterni come antivirus e antispam
7. Se è tutto OK, il MDA recapita il messaggio nella casella di Eva.

Quando Eva apre il MUA (Outlook), questo scaricherà dalla casella tutte le nuove mail.
Questo può avvenire con due protocolli diversi:
● POP3: “copia” le email dal server sul computer (e magari dopo le elimina dal server)
● IMAP: “consulta” la casella mail direttamente dal server, senza eliminare al termine.

ESEMPI PRATICI:
Invio di una mail con telnet. ⇒ Lezione 7.3.2
Spoofing di un messaggio ⇒ Lezione 7.3.3

Networking 101: Appunti di fine capitolo

morrolinux.it
 MIME
MIME (Multipurpose Internet Mail Extension) permette di comporre email contenenti caratteri
speciali e allegati in formato binario (foto, video, ecc…)

Vengono aggiunti alcuni campi all’header del messaggio per segnalare la presenza di
contenuti MIME per non “mandare in crisi” i programmi di posta:

● MIME-version: per la conformità alle specifiche

● Content-Type: descrive i dati nel corpo del messaggio per essere interpretati dal
MUA del destinatario
● Content-Transfer-Encoding: Tipo di codifica utilizzato
● Content-ID: per identificare ogni MIME univocamente
● Content-Description: descrizione testuale dell’oggetto (facoltativo)

Viene definita una boundary string: sequenza di caratteri che delimita inizio e fine di una regione.

Esempio:

MIME-Version: 1.0
Date: Sun, 1 Sep 2019 15:40:08 +0200
Message-ID: <CAOJ+Tdv8FbGEOFLKiY3jPKvxNSSLus02UsYHSss6Bp5i1+h1Ng@mail.gmail.com>
Subject: allegato di prova
From: Moreno <moreno@gmail.com>
To: morro <morro@gmail.com>
Content-Type: multipart/related; boundary="0000000000006e11d605917dfe59"

--0000000000006e11d605917dfe59
Content-Type: multipart/alternative; boundary="0000000000006e11d305917dfe58"
--0000000000006e11d305917dfe58
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=C3=A8 meglio se dai un'occhiata a questo screenshot:
[image: immagine.png]
--0000000000006e11d305917dfe58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>=C3=A8 meglio se dai un&#39;occhiata a questo screens=
hot:</div><div><br></div><div><div><img src=3D"cid:ii_k010v0pr0" alt=3D"imm=
agine.png" width=3D"452" height=3D"27"><br></div></div></div>
--0000000000006e11d305917dfe58--
--0000000000006e11d605917dfe59
Content-Type: image/png; name="immagine.png"
Content-Disposition: attachment; filename="immagine.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: ii_k010v0pr0
Content-ID: <ii_k010v0pr0>
AAAACXBIWXMAAA7EAAAOxAGGIZhGIZhzYBzYTEMwzAMw7AW5v8A4Qn+LbTfV8YAAAAASUVORK5CYII=
--0000000000006e11d605917dfe59--

L’ultima parte contiene l’allegato in codifica base64, uno standard per codificare contenuti
binari di qualunque tipo come caratteri stampabili.

Prova un encoder/decoder base64 online: https://www.base64encode.org/

Networking 101: Appunti di fine capitolo

morrolinux.it
 WWW: World Wide Web
Per realizzare la navigazione web sono necessari 3 ulteriori standard:
● URL: Uniform Resource Locator (un modo identificare le risorse univocamente)
● HTML: HyperText Markup Language (per descrivere le pagine web e link)
● HTTP: HyperText Transfer Protocol (protocollo per trasferire le pagine web/risorse)

URL
Può riferirsi a qualunque genere di risorsa e ha la seguente sintassi:

Ad esempio:

● schema: protocollo da vogliamo utilizzare

● host.dominio: hostname che vogliamo contattare
● percorso: percorso per raggiungere quella risorsa sul server indicato

La porta può anche essere specificata esplicitamente:

HTML
È un linguaggio di markup per la descrizione delle pagine web. Non segue rigide regole
per il posizionamento degli elementi ma lascia al browser l’interpretazione finale, quindi
la stessa pagina può apparire in modo diverso su browser differenti.

HTTP
Simile ad FTP, ma i comandi di controllo e il trasferimento dati avvengono nella stessa
connessione.

Networking 101: Appunti di fine capitolo

morrolinux.it
 HTTP
HTTP (HyperText Transfer Protocol): protocollo usato per la navigazione web.
Funziona su TCP e la porta di default è la 80.

Definizioni:
● User Agent (UA): il software che viene usato per la navigazione (ES: Firefox)
● Origin Server: il web server che fornisce la pagina richiesta.

NB: il protocollo HTTP prevede che una richiesta possa passare per più nodi, come Proxy,
Tunnel e Gateway per ragioni di performance e/o controllo e filtraggio.

Networking 101: Appunti di fine capitolo

morrolinux.it
 Formato dei messaggi HTTP
● La prima riga dell’header indica l’operazione (richiesta o risposta).
● Le righe seguenti contengono altri campi informativi utili.
● L’header è separato dal contenuto (payload) del messaggio con una riga vuota:

ES Header di una richiesta HTTP per “morrolinux.it”:

La prima riga riporta “GET <risorsa> <versione HTTP>”

Nell’header viene anche riportato

● Il nome del sito per cui si vuole ottenere la risorsa specificata
Host: morrolinux.it
● Lo user agent
● Altri dettagli di controllo sulla cache (accettiamo risposte cachate o meno, …)
● Lingua dell’utente (per i siti multilingua).

Networking 101: Appunti di fine capitolo

morrolinux.it
Il messaggio di risposta sarà:

<versione HTTP> <stato> seguito da

● Tipo di server che fornisce la risposta (nginx, apache, Microsoft IIS, … )
● Data della risposta
● Tipo di contenuto
● Transfer-encoding
● ...

Il corpo del messaggio è il contenuto della risorsa richiesta. In questo caso, la pagina web.

Metodi HTTP
I più importanti:
● GET: Richiede la risorsa indicata, come visto precedentemente.
● POST: Richiede una pagina indicata, ma diversamente da “GET” passa ad essa
informazioni aggiuntive nel payload del messaggio.
è usato per:
○ Inviare i dati compilati di un modulo
○ Commentare un post in un forum
○ …
● PUT: Invia il contenuto del payload al server.
○ Usato per creare o aggiornare una risorsa sul server
● DELETE: rimuovere una risorsa

Networking 101: Appunti di fine capitolo

morrolinux.it
 Codici di risposta (status code)
I codici di risposta sono divisi in categorie:
● 1xx - Richiesta ricevuta e il processing continua
○ 100 : Continue
○ 101 : Switching protocols (avvenuto upgrade tipo HTTP/1 → HTTP/1.1)
● 2xx - la richiesta è stata ricevuta, interpretata e accettata
○ 200 : Ok
○ ...
● 3xx - sono necessarie ulteriori azioni al fine di completare la richiesta
○ ...
○ 301 : Moved permanently (ad es. viene spostato/eliminato un dominio e il
server suggerisce una redirezione verso un nuovo indirizzo o la risorsa è
stata spostata ad un nuovo URL → header “location” indica dove)
○ 302 : Found
○ ...
● 4xx - la richiesta ha una sintassi errata o non può essere soddisfatta
○ 400 : Bad request (tipo richiesta malformata)
○ 401 : Unauthorized (non autenticato?)
○ 403 : Forbidden (risorsa non disponibile per noi)
○ 404 : Not found (il più conosciuto tra la plebe)
○ 408 : Request timeout
○ ...
● 5xx - Il server non è riuscito a soddisfare una richiesta apparentemente valida
○ 500 : Internal server error (parla da solo)
○ 501 : Not implemented
○ 502 : Bad gateway
○ …

Networking 101: Appunti di fine capitolo

morrolinux.it
 Connessione HTTP
● HTTP 1.0 apre una connessione TCP per ogni richiesta che viene chiusa dopo ogni
risposta.
● HTTP 1.1 (e succ.) apre una connessione alla prima richiesta per chiuderla solo
dopo un timeout in cui non avvengono altre richieste. (molto meglio!)

Cookies
HTTP non è in grado di collegare tra loro una serie di richieste provenienti dallo stesso
utente (è un protocollo stateless). Per mantenere uno “stato della connessione” si
utilizzano degli header HTTP aggiuntivi: “Cookie” e “Set-Cookie”.

Cookie: sono “variabili”, o meglio, associazioni “attributo = valore” che il server invia al
browser per mantenere informazioni sullo stato.

1. Il web server può aggiungere al messaggio di risposta un header “Set-cookie” per

dire al browser di ricordare una associazione “attributo=valore”.
2. Il browser, alle richieste successive, includerà questo attributo=valore sotto la voce
“Cookie”.

ESEMPIO visitando amazon.it

Header di risposta del server:

set-cookie: session-id=257-2964118-6343100; Domain=.amazon.it; Expires=Tue, 01-Jan-2036

08:00:01 GMT; Path=/
set-cookie: session-id-time=2084187201l; Domain=.amazon.it; Expires=Tue, 01-Jan-2036
08:00:01 GMT; Path=/
set-cookie:
session-token="WWUp1ez8smhIQ+vNENIiDZKC2eUtgMZnfJ7/bfno1tCRrAi2cImtCmZaESx59k5kbhfc6ARgxQUKJ4
6Ztq9tcN7WtCik8cJ039aJrma=="; Version=1; Domain=.amazon.it; Max-Age=515175006; Expires=Tue,
01-Jan-2036 08:00:01 GMT; Path=/

Networking 101: Appunti di fine capitolo

morrolinux.it
Header di richiesta del browser:

cookie: session-id=257-2964118-6343100;
session-token="WWUp1ez8smhIQ+vNENIiDZKC2eUtgMZnfJ7/bfno1tCRrAi2cImtCmZaESx59k5kbhfc6ARgxQUKJ4
6Ztq9tcN7WtCik8cJ039aJrma=="; session-id-time=2084187201l

Così Amazon sa che sono sempre io.

ESEMPI PRATICI:
Demo cookies, modalità sviluppatore e cookie stealing ⇒ Lezione 7.5.3

Autenticazione HTTP
L’autenticazione dell’utente è tipicamente gestita tramite tecnologie implementate nel sito
stesso, ma per i piccoli progetti in cui non è richiesta una autenticazione particolarmente
sicura, HTTP fornisce un meccanismo di autenticazione “basilare” in cui è richiesto
user:password cercando di accedere ad una “zona” protetta di un sito web identificata da
un “Realm” (regno) - possono esserci più “zone” identificate da “Realm” diversi:

Ci sono due varianti principali di questo meccanismo:

Basic Authentication
Username e password sono codificati in base64 ed inviati al server nell’header
Authorization della richiesta HTTP.

Authorization: Basic bW9ycm9saW51eDpTdXAzclBhc3N3MHJkIQ==

NB: NON sono crittografati! chiunque intercetti questo header HTTP potrà decifrare la
coppia user:password anche con un semplice tool online: https://www.base64encode.org/

Networking 101: Appunti di fine capitolo

morrolinux.it
 Digest Authentication
Username e password sono cifrati, e il server genera un codice monouso per la richiesta

Il browser invierà un messaggio con header:

Authorization: Digest username="guest",

realm="test",
nonce="1d1a9c217fe0c24fb81f6d1cad3031c4",
uri="/HTTP/Digest/",
response="0d99cf93a62e7eb25d60f3a0d760d768",

Il campo response contiene la password, così formata:

MD5( MD5(user:realm:pass):nonce:MD5(metodo:digest_uri) )

Ovvero:

MD5(MD5(guest:test:guest):1d1a9c217fe0c24fb81f6d1cad3031c4:MD5(GET:/HTTP/Digest/))

calcolando prima gli hash MD5 interni:

MD5(871a43cd67a0196cf4f801935973deb1:1d1a9c217fe0c24fb81f6d1cad3031c4:36a1333e1a989
06f378dba493613942e)

Risulta in: 0d99cf93a62e7eb25d60f3a0d760d768

Esercizio:
Provate voi stessi: https://jigsaw.w3.org/HTTP/Digest/
Calcolo MD5 online: https://www.md5online.org/
Decrypt MD5 online: https://www.md5online.org/md5-decrypt.html

Networking 101: Appunti di fine capitolo

morrolinux.it
 Evoluzioni
HTTPS (HTTP Secure): successiva implementazione del protocollo HTTP che fa uso di
crittografia asimmetrica per garantire l’integrità dei dati scambiati tra server e client
permettendo di scambiare dati tra i due in maniera cifrata.

video di approfondimento sulla crittografia asimmetrica.

Networking 101: Appunti di fine capitolo

morrolinux.it