Risposte seconda verifica - a.a. 2009-2010

Prima parte

• 1- il nameserver che deve essere utilizzato dalla resolver library viene indicato dal file /etc/resolv.conf
  
• 2 - le richieste al nameserver sono inviate con trasporto UDP sulla porta 53
• 3 - la zona di cui un DNS è autorevole rappresenta l'insieme dei Resource Record relativi a nomi a dominio le cui query al DNS (gestite da un qualunque nameserver) sono risolte unicamente da quel nameserver specifico
  
• 4 - il nameserver utilizzato dalla resolver library contatta quello autorevole per il dominio richiesto mediante il meccanismo della recursione, ossia iterando la richiesta verso una sequenza di nameserver, a partire da quelli root, in cui ad ogni query si scopre il nameserver autorevole per il livello inferiore
• 5 - il RR NS indica il nome a dominio del nameserver autorevole per il dominio di livello inferiore, mentre invece i glue record sono RR di tipo A, che permettono di conoscere l'indirizzo IP corrispondente, e sono usati quando questo nome a dominio è esso stesso nella zona delegata, rendendo di fatto impossibile altrimenti la risoluzione del suo indirizzo
• 6 - il dominio di secondo livello in-addr.arpa è dedicato al processo di risoluzione inversa, permettendo di conoscere (eseguendo una query per il RR di tipo PTR) i nomi a dominio a partire dagli indirizzi IP. I suoi livelli inferiori rappresentano, appunto, gli indirizzi IP, scritti da sinistra a destra.
  
• 7 - gli indirizzi dinamici assegnati da un server DHCP si possono conciliare con i nomi a dominio in accordo ai meccanismi detti DynDNS, che permettono di aggiungere (e rimuovere) dinamicamente ad un nameserver un RR, consentendo quindi l'indirizzabilità a livello applicativo anche di computer che non hanno sempre lo stesso indirizzo IP
  
• 8 - il RR MX indica il nome a dominio del computer che ospita il server SMTP di destinazione per il dominio richiesto
• 9 - l'intestazione Content-type permette di specificare il MIME Type del body della email, o di un suo allegato, e può essere ripetuta più volte nel caso di messaggi Multipart, ogni parte dei quali può assumere un diverso Content-type
• 10 - la codifica base64 è un particolare Content-Transfer-Encoding: che rappresenta contenuti binari usando solo caratteri a 7 bit, ovvero sequenze di bytes ognuno dei quali ha il bit più significativo a zero. Si ottiene suddividendo prima il contenuto in gruppi di 6 bit, quindi usando ogni gruppo come un indice in una tabella di 64 elementi che lo mette in corrispondenza con un simbolo del'alfabeto ascii, e infine producendo la sequenza di caratteri risultante
  
• 11 - i primi 128 codici del set di caratteri ISO 8859-1 corrispondono a simboli grafici uguali a quelli individuati dall'alfabeto ascii per gli stessi codici
• 12 - un HMAC crittografico si calcola disponendo di una funzione hash (SHA-1 o MD5) e di un segreto condiviso, per generare una etichetta Message Authentication Code (MAC), calcolando l'hash della concatenazione tra il messaggio da trasmettere ed il segreto, e trasmettendolo assieme al messaggio. Dato che la stessa operazione può essere svolta in ricezione, l'HMAC offre un servizio di integrità ed autenticazione, consentendo di verificare che il messaggio non è stato alterato, e che l'ha inviato il detentore del segreto
• 13 - Mentre per ottenere la confidenzialità mediante algoritmi di crittografia simmetrica occorre che entrambe le parti condividano una stessa chiave, gli algoritmi a chiave pubblica permettono a chi invia di conoscere solo la chiave pubblica di chi deve ricevere, il quale essendo l'unico detentore della corrispondente chiave privata, è l'unico a poter decrittografare il messaggio
  
• 14 - uno scambio di Diffie-Hellman permette a due parti di calcolare, oltre che una coppia di chiavi pubblica e privata per ciascuna parte, anche un segreto condiviso uguale per le due parti, senza doverlo quindi comunicare. In tal modo la crittografia può essere svolta con un algoritmo simmetrico, più veloce di quelli a chiave pubblica
  
• 15 - per verificare che i dati riportati in un certificato X.509 sono veri, occorre disporre della chiave pubblica della Certification Authority che l'ha firmato, oltre ovviamente ad essere sufficientemente sicuri che la chiave sia veramente della CA, e che la CA abbia svolto tutti i controlli necessari prima di firmare il certificato. Dopo di che, possiamo confidare nella autenticità di ciò che riceviamo, e possiamo crittografare messaggi da far leggere solo all'altra parte.
  

Seconda parte

• dalla analisi con wireshark del traffico catturato osserviamo che
  
• 16 - sono assegnati 3 indirizzi IP, ovvero 30.0.0.103, 30.0.0.102, e 30.0.0.166
• 17 - il server DHCP è in ascolto sulla porta 67, mentre i clients usano la porta 68
  
• 18 - sono offerti quali valori di Lease Time di 12 ore, ed un indirizzo di broadcast 30.0.255.255
  
• 19 - dopo aver ricevuto il Discover, e prima dell'offerta, il server DHCP controlla che l'indirizzo IP non sia già in uso, per evitare che poi siano due computer a rispondere alle richieste ARP per lo stesso indirizzo. Per questo, prima invia a suavolta tre richieste ARP a distanza di un secondo l'una dall'altra, in modo da accertarsi che l'indirizzo non sia già usato in ambito locale, e quindi emette anche un ICMP Echo Request (o ping) in modo da estendere il controllo oltre i confini del default gateway.
• 20 - il codepoint Unicode pari a 0xF2 e corrispondente alla lettera ò, scritto in binario, risulta pari a 11110010, e quindi si applica il caso della seconda riga della tabella di conversione UTF-8,producendo come risultato due bytes, 110xxxxx 10xxxxxx, in cui al posto delle x vanno (partendo da destra) i bit del codepoint, ossia 11000011 10110010, che in esadecimale sono rappresentati come 0xC3 0xB2 

Terza parte

• 21 - il nameserver utilizzato da pc1 è 192.160.0.11, ossia dnslug
• 22 - il nome del NS autorevole per .net è dnsnet.net, ed il suo IP è 192.168.0.2. dnsroot conosce queste risposte in virtù della loro presenza nei suoi files di zona, sia per quanto riguarda la delega del primo livello (net. IN  NS  dnsnet.net.), sia grazie al glue record (dnsnet.net. IN A 192.168.0.2), come verificabile nel file lab_email/dnsroot/etc/bind/dbroot
• 23 - alla seconda query la recursione non avviene più, in quanto la risposta è ormai contenuta nella cache di dnslug
• 24 - stiamo chiedendo il RR di tipo NS per conoscere il nameserver autorevole per il TLD .org
• 25 - non otteniamo risposta in quanto l'opzione -r del comando host impedisce di eseguire la ricorsione; dunque la query, inviata a dnslug, non può propagarsi fino a dnsroot
  
• 26 - perché la richiesta sia esaudita, dovremmo indirizzarla direttamente a dnsroot, con il comando host -r -t ns org.  192.168.0.5. A quanto pare, però, non si ottiene lo stesso risposta, almeno finché non si elimina l'opzione -r. Sniffando nuovamente il traffico, osserviamo che in effetti dnsroot, pur disponendo dei glue record che contengono la risposta, se non può verificarne il contenuto perché gli è stata proibita la recursione, risponde in modo negativo. Infatti, qualora si rimuova il -r, sempre sniffando, osserviamo che dnsroot inoltra la query a dnsorg (192.168.0.1), che è autorevole per .org, e dunque può autorevolemente rispondere con il RR NS per .org
  
• 27 - per scoprire il mail exchanger per il dominio lugroma3.org possiamo impartire il comando host -t mx lugroma3.org, ottenendo lugroma3.org MX 5 mail.lugroma3.org
• 28 - per evitare di dover delegare la zona labint.org ad un nuovo nameserver, la risoluzione per il nome a dominio www.labint.org può essere inserita direttamente nei master files del nameserver autorevole per .org, e cioè in quelli di dnsorg, editando il file lab_email/dnsorg/etc/bind/db.org, ed inserendovi il RR www.labint A 192.168.0.33. Per quanto riguarda la risoluzione inversa, invece, occorre inserire in lab_email/dnsroot/etc/bind/db.192.168.0 il RR 33 PTR www.labint.org. Dopo aver crashato e ri-lancianto il laboratorio, eseguendo da una qualunque VM il comando host www.labint.org oppure host 192.168.0.33 otteniamo ora le risposte corrette.
  
• 29 - spedire per email i files di configurazione modificati ad alef@alef.labint, indicando di quali VM si tratta, firmando l'email con la propria chiave privata, ed allegando la propria chiave pubblica
• 30 - la parte alternative è costituita di due sottoparti, di cui la prima con Content-Type: text/plain, e la seconda con Content-Type: text/html
• 31 - le sequenze del tipo =E0, =93, =92 sono il risultato della Content-Transfer-Encoding: quoted-printable, e rappresentano caratteri del charset windows-1252 estranei all'alfabero ASCII, codificati inserendo dopo il segno di = l'equivalente esadecimale del codice del carattere corrispondente
  
• 32- Il comando per invertire la trasformazione base64 è base64 -d pippo.b64 > pippo.pdf, ed il nuovo file ha dimensione 107,4 kB (109999 byte)