Risposte prima verifica - a.a. 2011-2012

Nome e Cognome __________________________________________________________________

Prima parte

1. viene instradato su eth2 perché coincide il prefisso, ed è il match più lungo
2. le quattro sottoreti di 10.10.192.0/19 hanno maschera di 21 bit, e precisamente i bit da 17 a 19 valgono 110 come per il terzo byte che in decimale è 192, a cui si concatena 00 o 01 o 10 o 11, e quindi gli indirizzi sono 10.10.192.0/21, 10.10.200.0/21, 10.10.208.0/21, 10.10.216.0/21
3. deve essere inpostato per eseguire il port forwarding, ossia inviare i pacchetti destinati alla porta su cui è in ascolto il servizio, al computer che lo ospita, modificando in transito l'indirizzo IP (privato) di destinazione: in questa fase, il router mantiene una tabella in cui ricorda porta ed IP del mittente del pacchetto inoltrato, in modo da poter effettuare la trasformazione inversa (scrivendo nell'IP mittente il proprio IP pubblico) per i pacchetti uscenti di risposta.
4. la finestra di trasmissione memorizza i pacchetti inviati e non ancora riscontrati, nel caso debbano essere ritrasmessi di nuovo. La sua dimensione è stabilita in base alla stima del round-trip-time, in base alla fase di slow-start ovvero di detezione di errori di trasmissione, ed in base al controllo di flusso su iniziativa del ricevente
5. nel caso del tcp viene ricevuto un pacchetto TCP di risposta, ma con il flag RST; nel caso dell'UDP di norma l'applicazione non è notificata, ma il mittente riceve comunque un pacchetto ICMP di tipo port unreachable
6. la select() è una istruzione bloccante che ritorna al chiamante quando si verifica un evento su di un insieme di socket (o più in generale, di file descriptors) e permette di avere un unico processo (o thread) per gestire in modo asincrono più collegamenti in atto
7. il comando netstat riferisce delle connessioni TCP (opzione -t) in essere, ovvero dei processi in ascolto (opzione -l, e -u per l'UDP). Il comando nmap effettua un portscan diretto verso un computer od una intera rete, e desume la presenza o meno di server in ascolto in base al tipo di risposta ottenuto
8. traceroute permette di individuare la sequenza di router attraversati dall'instradamento tra due host, inviando pacchetti con un TTL IP ridotto, in modo da suscitare nel router che lo scarta una risposta di tipo ICMP Time Exceeded
9. la recursione dei DNS avviene ponedo la stessa richiesta di risoluzione da nome ad IP ad una serie di diversi nameserver, a partire da uno dei root nameserver (autorevoli per la radice dello spazio dei nomi a dominio), proseguendo poi sui diversi livelli, scegliendo ogni volta un name server autorevole per quel livello
10. viene richiesto il RR di tipo PTR per la query relativa a 122.122.100.151.in-addr.arpa
11. si, è possibile inserire nei file di zona più RR di tipo A per lo stesso nome, anche se per quanto riguarda la risoluzione inversa, non è possibile inserire più RR PTR per lo stesso nome
12. /etc/resolv.conf, con la sintassi nameserver x.y.w.z
13. esegue una query al DNS chiedendo il RR di tipo MX per il nome a dominio della destinazione della email
14. un serve SMTP può evitare di comportarsi da OpenRelay se si rifiuta di accettare l'inoltro di email provenienti da indirizzi IP estranei alla propria zona di compentenza (ad es l'SMTP di un ISP accetta email solo dagli IP dell'ISP stesso), oppure richiedendo che si svolga un passaggio di autenticazione e quindi il mittente conosca un segreto condiviso
15. una DNS blackhole list serve a limitare il fenomeno dello spam, ed è per questo usata dai server SMTP. Consiste in un nome a dominio il cui DNS autorevole risponde a query relative ad indirizzi IP (formattati come avviene per le rischieste dei PTR): la risposta sarà positiva o negativa a seconda se sia stato segnalato o meno spam proveniente da quell'indirizzo. L'uso del DNS permette di distribuire questa informazione sui diversi nameserver di Internet
16. la rappresentazione UTF-8 del charset iso 8859-1 è del tipo 110xxxxx 10xxxxxx in cui al posto delle x vanno (a partire da destra) i bit del codepoint. Dato che 0xE7 = 11100111 allora il suo UTF-8 è 11000011 10100111 e cioè 0xC2 0xA7
17. l'intestazione email content transfer encoding serve ad indicare che la parte di email che segue è rappresentata mediante la trasformazione indicata, ad esempio base64, o 7 bit, o 8 bit, o quoted printable, il tutto per evitare di trasmettere byte con il bit più significativo ad uno, in ottemperanza alla definizione originale del protocollo SMTP - non necessario quindi se il server SMTP di destinazione supporta l'estensione 8BITMIME
18. si intende l'intervento di una terza parte che intercetta i messaggi da alice verso bob, li sopprime, e invia a bob nuovi messaggi falsi, e quindi fa lo stesso per i  messaggi da bob ad alice, in modo che i due in realtà si trovino entrambi a parlare con l'uomo nel mezzo, e non tra di loro come credono
19. un HMAC si ottiene concatenando ad un messaggio un segreto condiviso, e calcolando quindi un HASH del risultato. Il ricevente esegue la stessa operazione sul messaggio ricevuto, e confronta il risultato con l'hash ricevuto
20. il mittente crittografa il messaggio usando la chiave pubblica del destinatario designato, in modo che solo lui possa decrittare il messaggio, utilizzando la propria chiave privata.

Seconda parte

21. si osservano 4 conversazioni, tutte con 151.100.122.171, più delle comunicazione verso un indirizzo broadcast
22. osserviamo una sola conversazione ethernet unicast, quindi sembra solo una coppia
23. è l'host con indirizzo ethernet 00:13:c3:c1:e4:7f, dato che questo indirizzo è la destinazione eth di tutti i pacchetti emessi da 151.100.122.171
24. sono 16 conversazioni tcp
25. è richiesta la risoluzione di due nomi, it.wikipedia.org e upload.wikimedia.org
26. nel capture it.wikipedia.org è risolto come 145.97.39.155 mentre upload.wikimedia.org è risolto (dopo una o due indirezioni via un CNAME) come 145.97.39.156; attualmente il comando host fornisce (dopo indirezione) per questi nomi a dominio la risoluzione 91.198.174.225 e 91.198.174.234
27. la richiesta è il RR di tipo A per il nome it.wikipedia.org e la risposta (dopo indirezione) è 145.97.39.155. Nella sezione autorevole troviamo i nameserver autorevoli per i RR ricevuti, mentre nella seziona addizionale ci sono i rispettivi indirizzi
28. upload.wikimedia.org ha ricevuto 8 richieste

29. si osserva un rtt di circa 33 msec, valutati tra il syn ed il syn-ack, visto che uno va, e l'altro torna
30. mentre fino al 300 veniva inviato un ACK in corrispondenza di ogni pacchetto ricevuto, ora gli ack rallentano, ed interviene il meccanismo di controllo di flusso, dato che nelle intestazioni TCP degli ACK viene comunicata una dimensione di finestra via via minore, fino a quando questa non viene completamente chiusa al pacchetto 336. Evidentemente il computer ricevente in quei momenti aveva altro da fare, e non riusciva a tener dietro al traffico in ingresso. Finalmente a partire dal pacchetto 346 la finestra è riaperta.
31. la finestra è chiusa all'istante 31.19 e riaperta in 34.69, quindi resta chiusa per 3.5 secondi
32. la dimensione massima di finestra raggiunta è di 63712 bytes

33. nel subject non sono ancora attive le intestazioni MIME, e quindi si adotta la codifica di trasferimento encoded word, in cui è indicato il charset originario (ISO-8859-1), la codifica (Q=quotedprintable) e quindi il risultato, in cui ogni carattere accentato è rappresentato come =HH, dove HH è la rappresentazione esadecimale del codepoint iso-8859-1
34. le parti mixed sono delimitate con boundary che termina in "0xSpv". Troviamo due parti, la prima con un tipo multipart/related, e la seconda con l'immagine allegata
35. le sezioni multipart/related sono divise da un boundary che termina con "sknEz", e sono in 3. La prima contiene il messaggio, la seconda una immagine con Content-ID: <1336490539.10159.9.camel@cq>, la terza una immagine con Content-ID: <1336490442.10159.7.camel@cq>
    
36. il messaggio è costituito da un Content-Type: multipart/alternative, le cui parti sono divise da un confine che termina in "zeHv+". Nella prima parte troviamo la forma testuale del messaggio, e nella seconda la rappresentazione HTML. Notiamo come nell'HTML le immagini siano referenziate mediante il Content-ID con cui sono etichettate nelle parti related