Universitatea Transilvania din Brasov Retele de Calculatoare
Nume: Potorac Raducu Daniel Anul: IV Grupa: 4241 EA
Lucrarea de laborator nr.1.
Lucrul cu analizorul de protocoale de reţea Wireshark 1.
2.
Enumeraţi o serie de protocoale care apar în coloana de protocoale nefiltrate de la la pasul 7. UDP, TLSv1.2, TCP, SSDP, ICMPv7, DNS, ARP, HTTP Care este durata între transmiterea tr ansmiterea mesajului HTTP GET şi recepţionarea răspunsului HTTP GET? (În coloana “Time” din lista de pachete se măsoară timpul în sec unde din momentul începerii capturării. Pentru a se afişa timpul current se selectează submeniul “View/Display Format/Time of day”). 1.46906 ms
3.
Care este adresa de Internet pentru standards.ieee.org ? Care este adresa de Internet a computerului dumneavoastră? Adresa standards.ieee.org: 140.98.193.116 Adresa mea: 192.168.1.3
4.
Tipăriţi la imprimantă două mesaje „http” din pasul 9. Pentru aceasta selectaţi “Print” din meniul „File”, selectaţi „Selected Packet Only” şi „Print „Pri nt as displayed”, după care daţi comanda OK. 33 13:01:08.786905 192.168.1.3 standards.ieee.org HTTP 962 GET /about/get/802/802.3.html HTTP/1.1 Frame 33: 962 bytes on wire (7696 bits), 962 bytes captured (7696 bits) on interface 0 Ethernet II, Src: Giga-Byt_82:63:69 (74:d4:35:82:63:69), Dst: Fiberhom_6d:78:c0 (bc:c0:0f:6d:78:c0) Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst: standards.ieee.org (140.98.193.116) 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 948 Identification: 0x423b (16955) Flags: 0x02 (Don't Fragment) Fragment offset: 0 Time to live: 128 Protocol: TCP (6) Header checksum: 0x0000 [validation disabled] [Header checksum status: Unverified] Source: 192.168.1.3 (192.168.1.3) Destination: standards.ieee.org (140.98.193.116) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Transmission Control Protocol, Src Port: 61014, Dst Port: 80, Seq: 1, Ack: 1, Len: 908 Source Port: 61014 Destination Port: 80 [Stream index: 1] [TCP Segment Len: 908] Sequence number: 1 (relative sequence number) [Next sequence number: 909 (relative sequence number)] Acknowledgment number: 1 (relative ack number) 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) Window size value: 64952 [Calculated window size: 64952] [Window size scaling factor: -2 (no window scaling used)] Checksum: 0x1329 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK analysis] TCP payload (908 bytes) Hypertext Transfer Protocol 305 13:01:10.255995 2620:104:c000:8193::112 2a02:2f0e:d460:1389:e16d:113:36c6:9a2e HTTP 1105 HTTP/1.1 200 OK (text/html) Frame 305: 1105 bytes on wire (8840 bits), 1105 bytes captured (8840 bits) on interface 0 Ethernet II, Src: Fiberhom_6d:78:c0 (bc:c0:0f:6d:78:c0), Dst: GigaByt_82:63:69 (74:d4:35:82:63:69) Internet Protocol Version 6, Src: 2620:104:c000:8193::112 (2620:104:c000:8193::112), Dst: 2a02:2f0e:d460:1389:e16d:113:36c6:9a2e (2a02:2f0e:d460:1389:e16d:113:36c6:9a2e) Transmission Control Protocol, Src Port: 80, Dst Port: 61019, Seq: 37001, Ack: 1563, Len: 1031 Source Port: 80 Destination Port: 61019 [Stream index: 8] [TCP Segment Len: 1031] Sequence number: 37001 (relative sequence number) [Next
Lucrarea de laborator nr.1.
Lucrul cu analizorul de protocoale de reţea Wireshark 1.
2.
Enumeraţi o serie de protocoale care apar în coloana de protocoale nefiltrate de la la pasul 7. UDP, TLSv1.2, TCP, SSDP, ICMPv7, DNS, ARP, HTTP Care este durata între transmiterea tr ansmiterea mesajului HTTP GET şi recepţionarea răspunsului HTTP GET? (În coloana “Time” din lista de pachete se măsoară timpul în sec unde din momentul începerii capturării. Pentru a se afişa timpul current se selectează submeniul “View/Display Format/Time of day”). 1.46906 ms
3.
Care este adresa de Internet pentru standards.ieee.org ? Care este adresa de Internet a computerului dumneavoastră? Adresa standards.ieee.org: 140.98.193.116 Adresa mea: 192.168.1.3
4.
Tipăriţi la imprimantă două mesaje „http” din pasul 9. Pentru aceasta selectaţi “Print” din meniul „File”, selectaţi „Selected Packet Only” şi „Print „Pri nt as displayed”, după care daţi comanda OK. 33 13:01:08.786905 192.168.1.3 standards.ieee.org HTTP 962 GET /about/get/802/802.3.html HTTP/1.1 Frame 33: 962 bytes on wire (7696 bits), 962 bytes captured (7696 bits) on interface 0 Ethernet II, Src: Giga-Byt_82:63:69 (74:d4:35:82:63:69), Dst: Fiberhom_6d:78:c0 (bc:c0:0f:6d:78:c0) Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst: standards.ieee.org (140.98.193.116) 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 948 Identification: 0x423b (16955) Flags: 0x02 (Don't Fragment) Fragment offset: 0 Time to live: 128 Protocol: TCP (6) Header checksum: 0x0000 [validation disabled] [Header checksum status: Unverified] Source: 192.168.1.3 (192.168.1.3) Destination: standards.ieee.org (140.98.193.116) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Transmission Control Protocol, Src Port: 61014, Dst Port: 80, Seq: 1, Ack: 1, Len: 908 Source Port: 61014 Destination Port: 80 [Stream index: 1] [TCP Segment Len: 908] Sequence number: 1 (relative sequence number) [Next sequence number: 909 (relative sequence number)] Acknowledgment number: 1 (relative ack number) 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) Window size value: 64952 [Calculated window size: 64952] [Window size scaling factor: -2 (no window scaling used)] Checksum: 0x1329 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK analysis] TCP payload (908 bytes) Hypertext Transfer Protocol 305 13:01:10.255995 2620:104:c000:8193::112 2a02:2f0e:d460:1389:e16d:113:36c6:9a2e HTTP 1105 HTTP/1.1 200 OK (text/html) Frame 305: 1105 bytes on wire (8840 bits), 1105 bytes captured (8840 bits) on interface 0 Ethernet II, Src: Fiberhom_6d:78:c0 (bc:c0:0f:6d:78:c0), Dst: GigaByt_82:63:69 (74:d4:35:82:63:69) Internet Protocol Version 6, Src: 2620:104:c000:8193::112 (2620:104:c000:8193::112), Dst: 2a02:2f0e:d460:1389:e16d:113:36c6:9a2e (2a02:2f0e:d460:1389:e16d:113:36c6:9a2e) Transmission Control Protocol, Src Port: 80, Dst Port: 61019, Seq: 37001, Ack: 1563, Len: 1031 Source Port: 80 Destination Port: 61019 [Stream index: 8] [TCP Segment Len: 1031] Sequence number: 37001 (relative sequence number) [Next
sequence number: 38032 (relative sequence number)] Acknowledgment number: 1563 (relative ack number) 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) Window size value: 5798 [Calculated window size: 5798] [Window size scaling factor: -2 (no window scaling used)] Checksum: 0x647e [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK analysis] TCP payload (1031 bytes) TCP segment data (1031 bytes) [30 Reassembled TCP Segments (38031 bytes): #250(1412), #251(1412), #252(1412), #255(1412), #256(1412), #257(1412), #258(1412), #259(1412), #260(144), #268(1412), #269(1412), #270(1412), #272(1412), #273(1412), #274(1412), #275(1412), #276(] Hypertext Transfer Protocol Line-based text data: text/html
Lucrarea de laborator nr.2. Protocolul HTTP
1. Browser-ul este versiunea 1.0 sau 1.1? Ce versiune de HTTP ruleaz ă pe server? Versiunea 1.1. HTTP 1.1 2. Care limbi (dacă există) indică browser-ul că pot fi acceptate de către server? Engleza
3. Care este adresa IP a calculatorului dvs.? Dar a serverului tc.unitbv.ro?
4. Care este codul “status” întors de la server către browser? 200 OK 5. Când a fost modificat ultima oară pe server, fişierul HTML pe care îl descărcaţi? Mon, 03 Dec 2012 10:06:32 6. Câţi octeţi de payload sunt returnaţi către browser? 103 octeti 7. Priviţi fereastra “packet content”. Puteţi vedea vreun header în d atele care nu sunt afişate în fereastra packet-listing? Daca da, numiţi unul. Header Length 8. Priviţi prima cerere HTTP-GET de la browser către server. Vedeţi o linie “IF MODIFIED-SINCE” ?
9. Priviţi răspunsul serverului. A întors serverul în mod explicit conţinutul fişierului? Justificaţi.
10. Acum priviţi a doua cerere HTTP-GET de la browser către server. Vedeţi o linie “IF MODIFIED-SINCE” ? Dacă da, ce informaţie urmează după header-ul lui “IFMODIFIED-SINCE” ? Nu am o a doua cerere. 11. Priviţi al doilea răspuns al serverului. A întors serverul în mod explicit conţinutul fişierului? Justificaţi. 12. Câte mesaje de cerere HTTP GET au fost trimise de către browser? Un singur mesaj HTTP GET a fost trimis.
13. De câte segmente TCP care conţin date, a fost nevoie pentru a trimite singurul răspuns HTTP? 14. Care este codul status asociat răspunsului cererii HTTP GET? 200
15. Există vreo linie status HTTP în transmisiunea asociată cu cuvântul “Continuation” TCP? Nu exista. 16. Câte mesaje de cerere HTTP GET au fost trimise de către browser? Către care adresă? 2 measje catre 193.254.231.38 si 193.254.231.113
17. Puteţi spune dacă browser-ul a descărcat cele 2 imagini una după alta, sau au fost descărcate simultan de la cele două site-uri? Justificaţi. Au fost desacarcate succesiv 18. Care este răspunsul server-ului la primul mesaj HTTP GET ?
19. Când browser-ul trimite mesajul HTTP GET a doua oară, ce câmp nou apare în mesaj?
Lucrarea de laborator nr.3. Protocolul DNS
1. Rulaţi nslookup pentru a obţine adresa IP a unui web server din Asia.
2. Rulaţi nslookup pentru a determina servere “authoritative” DNS din Europa.
3. Rulaţi nslookup astfel încât unul dintre serverele DNS obţinute la punctul 2 să fie întrebat în legătură cu serverele de mail al Yahoo! Mail
4. Găsiţi întrebarea DNS şi mesajele de răspuns. Sunt trimise peste UDP sau TCP? Sunt trimise peste UDP 5. Care este portul destinaţie pentru mesajele cerere DNS? Care este portul sursă pentru mesajele de răspuns DNS? POrtul 53 pentru sursa si destinatie 6. La ce adresa IP este trimis mesajul cerere DNS? Folosiţi ipconfig pentru a vedea adresa serverului dvs local DNS. Apare aceeaşi adresă IP?
7. Examinaţi mesajul cerere DNS. Ce “fel” de întrebare DNS este? Mesajul întrebare conţine vreun “răspuns”? Intrebare Type A. fara raspuns. 8. Examinaţi mesajul DNS de răspuns. Câte “răspunsuri” sunt oferite? Ce conţine fiecare răspuns?
9. Priviţi pachetul TCP SYN trimis ulterior de către host. Adresa IP de destinaţie a pachetului SYN corespunde vreunei adrese IP oferită în mesajul de răspuns DNS? Primul pachet SYn e trimis catre 104.20.1.85 care este aceeasi cu adresa din mesajur DNS de raspuns 10. Această pagină web conţine imagini. Înainte de a descărca fiecare imagine, host -ul face alte cereri DNS? Nu contine imagini
11. Care este portul destinaţie pentru mesajul cerere DNS? Care este portul sursă a mesajului de răspuns DNS? Port 53. 12. La care adresă IP este mesajul cerere DNS trimis? Este aceasta adresa IP a serverului DNS local? Catre 192.168.1.1 adresa DNS proprie 13. Examinaţi mesajul cerere DNS. Ce “fel” de mesaj cerere este? Conţine vreun “răspuns” ? Queri type AAAA (IPv6 address) 14. Examinaţi mesajul de răspuns DNS. Câte “răspunsuri” sunt oferite? Ce conţine fiecare dintre aceste răspunsuri?
16. La care adresă IP este mesa jul cerere DNS trimis? Este aceasta adresa IP a serverului dvs DNS local? Catre 192.168.1.1 adresa DNS proprie 17. Examinaţi mesajul cerere DNS. Ce “fel” de mesaj cerere este? Conţine vreun “răspuns” ? Intrebare type NS, fara raspunsuri. 18. Examinaţi mesajul de răspuns DNS. Ce “nameservere” ale Universităţii oferă mesajul răspuns? Acest răspuns oferă şi adresele IP ale “nameserverelor” Universităţii? ns-b.unitbv.ro; ns.unitbv.ro; ns-a.unitbv.ro. Nu contine adresele IP 19. Faceți un screenshot.
20. La care adresă IP este mesajul cerere DNS trimis? Este aceasta adresa IP a serverului dvs DNS local? Dacă nu, care este corespondenta adresei IP? DNS-ul e trimis la 193.254.230.2 ns.uitbv.ro 21. Examinaţi mesajul cerere DNS. Ce “fel” de mesaj cerere este? Conţine vreun “răspuns” ? Intrebare type AAAA, fara raspunsuri 22. Examinaţi mesajul de răspuns DNS. Câte “răspunsuri” sunt oferite? Ce conţine fiecare dintre răspunsuri?
23. Faceţi un screenshot.
Lucrarea de laborator nr.4. Protocolul TCP
1. Care este adresa IP şi portul TCP folosite de computerul care transferă fişierul către “tc.unitbv.ro”? Puteţi selecta un mesaj HTTP şi explora detaliile pachetului TCP folosit pentru a transporta acest mesaj, folosind “details of the selected packet header window”?
2. Care este adresa IP a serverului “tc.unitbv.ro”? Pe care port trimite şi pe care primeşte segmente TCP pentru această conexiune? Dacă aţi putut să vă faceţi propriul trace, răspundeţi şi la întrebarea:
3. Care este adresa IP şi portul TCP folosite de computerul dvs. pentru a transfera fişierul la “tc.unitbv.ro”?
4. Care este numărul secvenţial al segmentului TCP SYN care este folosit pentru a iniţia conexiunea între computer şi “tc.unitbv.ro”? Ce anume din segment îl identifică drept un segment SYN?
5. Care este numărul secvenţial al segmentului SYNACK trimis de “tc.unitbv.ro” la computerul dvs., ca replică la SYN? Care este valoarea câmpului de confirmare în segmentul SYNACK? Cum a determinat “tc.unitbv.ro” valoarea? Ce anume din segment îl identifică drept un segment SYNACK?
6. Care este numărul secvenţial al segmentului TCP care conţine comanda HTTP POST? Pentru aceasta trebuie să căutaţi în “packet content field” şi să căutaţi un segment cu “POST” în câmpul DATA.
7. Priviţi segmentul TCP care conţine HTTP POST ca fiind primul segment în conexiunea TCP. Care sunt numerele secvenţiale în conexiunea TCP (inclusiv segmentul cu HTTP POST) ? La ce oră a fost trimis fiecare segment? Când a fost recepţionat ACK pentru fiecare segment? Dată fiind diferenţa dintre momentul în care a fost trimis fiecare segment TCP şi momentul în care i s -a răspuns cu o confirmare, care este valoarea RTT pentru fiecare dintre cele 6 segmente? Care este “ Estimated RTT Value” după recepţia fiecărui ACK?
8. Care este lungimea fiecăruia dintre cele 6 segmente TCP?
9. Care este valoarea minimă de “buffer space” văzută la recepţie pentru întregul trace? Datorită faptului că spaţiul buffer-ului este prea mic, transmiţătorul este limitat?
10. Există vreun segment retransmis în trace? Justificaţi răspunsul. Nu exista segmente retransmise 11. Câtă informaţie confirmă receptorul în ACK? Puteţi identifica cazurile pentru care receptorul confirmă (ACK) la fiecare segment recepţionat?
Lucrarea de laborator nr.5. Protocolul UDP
1. Din câmpul “packet content”, aflaţi lungimea (în biţi) a fiecărui câmp UDP header. 2 bytes 2. A cui lungime o reprezintă valoarea din câmpul “Lungime”? Verificaţi răspunsul cu pachetul UDP capturat. 8 byres header+ 42 bytes date 3. Care este numărul maxim de biţi care poate fi inclus într -un payload UDP? (216 – 1) – header bytes(8)= 65535 – 8 = 65527 bytes.
4. Care este cel mai mare număr posibil al source port -ului ? 216 – 1=65535
5. Care este numărul protocolului UDP? Răspundeţi în hexa şi în zecimal (puteţi să vă uitaţi în header-ul IP). 6. Căutaţi “UDP” în Google şi găsiţi câmpurile de unde se calculează UDP checksum. https://www.slashroot.in/how-is-tcp-and-udp-checksum-calculated 7. Priviţi o pereche de pachete UDP în care pr imul pachet este trimis de computerul dvs. iar al doilea pachet este replica primului pachet. Explicaţi legătura dintre numerele porturilor din cele 2 pachete. Portul sursă al pachetului UDP trimis de gazdă este același ca portul de destinație al pachetului de răspuns și, invers, portul de destinație al pachetului UDP trimis de gazdă este același ca portul sursă al pachetului de răspuns. 8. Capturaţi un mic pachet UDP. Verificaţi manual checksum-ul acestui pachet. Arătaţi cum aţi lucrat şi explicaţi fiecare pas.
Lucrarea de laborator nr.6. Protocolul IP
1. Selectaţi primul mesaj ICMP Echo Request trimis de computerul dvs. şi extindeţi partea de Internet Protocol a pachetului. Care este adresa IP a computerului dvs. ? 192.168.1.1 2. Care este valoarea câmpului “upper layer protocol” în header-ul pachetului IP? ICMP 3. Câţi octeţi sunt în header-ul IP? Câţi octeţi sunt în payload-ul datagramei IP? Justificaţi răspunsul. 20 de octeti in header IP 56 octeti lungime totala 36 octeti in payload 4. Această datagrama IP a fost fragmentată? Justificaţi răspunsul. Nu este fragmestat, deoarece “more fragments” din “flags” este setat pe 0 5. Care câmpuri din datagrama IP se schimbă întotdeauna de la o datagramă la următoarea, în această serie de mesaje ICMP? Se schimba Identification, time to live , header checksum 6. Care câmpuri rămân constante? Care câmpuri trebuie să rămână constante? Care câmpuri trebuie să se schimbe? De ce? Version, header length, source ip, destination ip, differential services, upper layer protocol raman constant Se schimba identification. Time to live, header checksum 7. Descrieţi modelul pe care-l vedeţi în valorile din câmpul Identification al datagramei IP. Modelul este că header-ul IP crește câmpurile Identification cu fiecare cerere ICMP Echo (ping). 8. Care este valoarea din câmpurile Identification şi TTL? Valoarea din câmpul Identification este 40316. Valoarea din câmpul TTL este 255. 9. Rămân aceste valori neschimbate pentru toate replicile ICMP TTL-exceeded trimise la computerul dvs. de la cel mai apropiat router? De ce?
Câmpul Identification se modifică pentru toate replicile ICMP TTL-exceeded, deoarece câmpul Identification este o valoare unică. Atunci când două sau mai multe datagrame IP au aceeași valoare de identificare, înseamnă că aceste datagrame IP sunt fragmente ale unei singure scale datagrame IP. Câmpul TTL rămâne neschimbat, deoarece TTL pentru primul ruter de hamei este întotdeauna același. 10. Găsiţi primul mesaj ICMP Echo Request care a fost trimis de către computerul dvs. după ce aţi schimbat Packet Size la 2000 în pingplotter . A fost acel mesaj fragmentat de-a
lungul mai multor datagrame IP? (Notă: dacă pachetul dvs. nu a fost fragmentat, folosiţi fişierul ip-ethereal-trace-1 din arhiva wireshark-traces.zip). Da a fost fragmentat 11. Tipăriţi primul fragment al datagramei IP fragmentate. Ce informaţie din header-ul IP indică faptul că datagrama a fost fragmentată? Ce informaţie din header-ul IP indică dacă acesta este primul sau ultimul fragment? Cât de lungă este această datagramă IP? Bitul de la câmpul ”More Fragments” din ”Flags” este setat la 1, indicând faptul că datagrama a fost fragmentată. Deoarece bitul de la câmpul ”Fragment offset” din ”Flags”este setat la 0, știm că acesta este primul fragment. Această primă datagramă are o lungime totală de 1500, inclusiv header-ul. 12. Tipăriţi al doilea fragment al datagramei. Ce informaţie din header-ul IP indică faptul că acesta nu este primul fragment? Există mai multe fragmente? Justificaţi răspunsul. Informația din header-ul IP care ne indică faptul că acesta nu este primul fragment este ”Fragment offset”, care are valoarea 1480. Acesta este ultimul fragment, din moment ce câmpul ”More fragments” din ”Flags” este setat la 0. 13. Care câmpuri se schimbă în header-ul IP între primul şi al doilea fragment? Total, legth, flags, fragment offset, header, checksum 14. Câte fragmente au fost create din datagrama originală? 3 fragmente 15. Ce câmpuri s-au schimbat în header-ul IP de la un fragment la altul? Fragment offset, header checksum, total length, flags, more fragments
Lucrarea de laborator nr.7. Protocolul NAT
1. Care este adresa IP a clientului? Adresa IP a clientului este 192.168.1.100 2. De fapt clientul comunică cu mai multe servere Google diferite pentru a implementa “safe browsing”. Serverul principal Google care are pagina principală Google, are adresa IP 64.233.169.104. Pentru a afişa doar cadrele care conţin mesaje HTTP care sunt trimise la / de la acest server Google, scrieţi “http&&ip.addr==64.233.169.104” la filtrul Wireshark.
3.
Priviţi acum mesajul HTTP GET trimis de la client la serverul Google (al cărui IP este 64.233.169.104) la momentul 7.102967. Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pe datagrama IP care transportă acest HTTP GET?
4.
La care moment este recepţionat mesajul corespunzător 200 OK HTTP de la serverul Google? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pe datagrama IP care transportă mesajul 200 OK HTTP? 5. Mesajul corespunzător 200 OK HTTP de la serverul Google este recepționat la momentul 7.158797. Adresa IP a sursei este 64.233.169.104, iar portul TCP al sursei este 80. Adresa IP a destinației este 192.168.1.100, iar portul TCP al destinației este 4335. 6. Ştim că înainte ca o comandă GET să poată fi trimisă unui server HTTP, TCP tr ebuie întâi să seteze o conexiune folosind “three-way SYN/ACK handshake”. La care moment este trimis, de la client către server, segmentul TCP SYN care setează conexiunea folosită de GET la momentul 7.102967 ? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pentru acest segment TCP SYN ? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pe datagrama IP ale ACK -ului trimis ca răspuns lui SYN ? La ce moment este acest ACK recepţionat la client? (Aici trebuie să scrieţi “tcp” la filtru). Pentru segmentul TCP SYN:
a) Segmentul TCP SYN care setează conexiunea folosită de GET la momentul 7.102967 este trimis, de la client către server, la momentul 7.075657. b) Adresa IP a sursei este 192.168.1.100, iar portul TCP al sursei este 4335. c) Adresa IP a destinației este 64.233.169.104, iar portul TCP al destinației este 80. Pentru ACK-ul trimis ca răspuns lui SYN: a) Adresa IP a sursei este 64.233.169.104, iar portul TCP al sursei este 80. b) Adresa IP a destinației este 192.168.1.100, iar portul TCP al destinației este 4335. c) Acest ACK este recepționat la client la momentul 7.108986. 7. În fişierul NAT_ISP_side, mesajul HTTP GET a fost trimis de la client către Google la 7.102967 (unde t = 7.102967 este timpul când mesajul a fost trimis, după cum a fost înregistrat în trace-ul NAT_home_side). La care moment apare mesajul în trace-ul NAT_ISP_side ? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pe datagrama IP care transportă acest HTTP GET (după cum s -a înregistrat în trace-ul NAT_ISP_side) ? Care dintre aceste câmpuri sunt aceleaşi şi care sunt diferite, faţă de răspunsul din întrebarea 3. ? Momentul la care apare mesajul în trace-ul NAT_ISP_side este 6.069168. Adresa IP a sursei este 71.192.34.104, iar portul TCP al sursei este 4335. Adresa IP a destinației este 64.233.169.104, iar portul TCP al destinației este 80. Campuri neschimbate din IP: port TCP sursa, IP destinatie, port tcp destinatie 8. Este vreun câmp din mesajul HTTP GET schimbat ? Care dintre câmpurile următoare din datagrama IP este schimbat: Version, Header Length, Flags, Checksum? Justificaţi răspunsurile. Nu exista nici un camp schimbat 9. În trace-ul NAT_ISP_side, la care moment a fost recepţionat mesajul 200 OK HTTP de la serverul Google? Care dintre aceste câmpuri sunt la fel, şi care sunt diferite faţă de răspunsul de la întrebarea 4 ? Momentul la care a fost recepționat mesajul 200 OK HTTP de la serverul Google este 6.117570. Campuri neschimbate, adresa ip sursa, port TCP sursasi destinatie 10. În fişierul NAT_ISP_side, la care moment a fost capturat segmentul client-to-server TCP SYN ţi segmentul server-to-client TCP ACK corespunzătoare segmentelor din întrebarea 5? Care sunt adresele IP şi porturile TCP ale sursei şi destinaţiei pentru aceste segmente? Care dintre aceste câmpuri sunt la fel şi care sunt diferite faţă de răspunsul la întrebarea 5? 10. Folosindu-vă de răspunsurile de la întrebările 1-8, completați tabela de translaţie NAT pentru conexiunea HTTP din întrebările de mai sus.
Pentru segmentul TCP SYN: a) Momentul la care a fost capturat segmentul client-to-server TCP SYN este 6.035475. b) Adresa IP a sursei este 71.192.34.104, iar portul TCP al sursei este 4335. c) Adresa IP a destinației este 64.233.169.104, iar portul TCP al destinației este 80.
d) Câmpurile neschimbate sunt: port TCP sursa si destinatie, adresa IP destinatie
e) Adresele IP ale surselor sunt diferite: 192.168.1.100 la întrebarea 5 și 71.192.34.104 la întrebarea 9. Pentru segmentul TCP ACK: a) Momentul la care a fost capturat segmentul server-to-client TCP ACK este 6.067775. b) Adresa IP a sursei este 64.233.169.104, iar portul TCP al sursei este 80. c) Adresa IP a destinației este 71.192.34.104, iar portul TCP al destinației este 4335. d) Câmpurile neschimbate sunt: Adresa IP a sursei; Portul TCP al sursei; Portul TCP al destinației;
e) Adresele IP ale destinațiilor sunt diferite: 192.168.1.100 la întrebarea 5 și 71.192.34.104 la întrebarea 9.
Lucrarea de laborator nr.8. Protocolul ICMP
1.Care este adresa IP a computerului dvs? Care este adresa IP a destinaţiei? destinatie 154.67.228.152 eu 192.168.1.1 2.De ce un pachet ICMP nu are numere de porturi pentru sursă şi destinaţie? Deoarece a fost proiectat să comunice informațiile din nivelul Rețea între host-uri și servere
3.Priviţi un pachet ping de cerere trimis de computerul dvs. Care sunt tipul şi codul numerelor de ICMP? Ce alte câmpuri mai are acest pachet ICMP? Câți octeţi sunt în câmpurile “checksum”, “sequence number” şi “identifier” ? Tipul ICMP 8, numar cod ICMP 0 pachetul icmp are: checksum, identifier BE si LE, sequence number BE si LE, data avem 2 octeti in checksum, sequence number si identifier 4.Priviţi pachetul corespunzător ping de răspuns. Care sunt tipul şi codul numerelor de ICMP? Ce alte câmpuri mai are acest pachet ICMP? Câţi octeţi sunt în câmpurile “checksum”, “sequence number” şi “identifier” ? Numărul tipului de ICMP este 0, iar numărul codului de ICMP este 0. pachetul contine checksum, identifier BE si LE, sequence number BE si LE, data
avem 2 octeti in checksum, sequence number si identifier
5..Care este adresa IP a computerului dvs? Care este adresa IP a destinaţiei? eu 192.168.1.1 destinatie 160.45.170.10 6.Dacă ICMP a trimis pachete UDP (ca în Unix/Linux), ar mai fi numărul protocolului IP, 01 pentru pachetele de probă? Daca nu, care ar fi? Nu. Dacă ICMP a trimis pachete UDP, atunci numărul protocolului IP ar trebui să fie 0x11.
7.Priviţi pachetul “ICMP echo” din imaginea dvs. Este diferit faţă de pachetele ICMP ping de cerere din prima parte a laboratorului? Dacă da, în ce fel? nu este diferit 8.Priviţi pachetul “ICMP error” din imaginea dvs. Are mai multe câmpuri decât pachetul ICMP echo. Ce este inclus în aceste câmpuri? Acest pachet conține header-ul IP și primii 8 octeți ai pachetului ICMP original
9.Priviţi ultimele 3 pachete ICMP primite de către PC-ul sursă. În ce fel sunt aceste pachete diferite de pachetele “ICMP error”? De ce sunt diferite? Ultimele trei pachete ICMP sunt mesaje de tipul 0 (răspunsul la ecou) și nu 11 (TTL expirat). Ele sunt diferite, deoarece datagramele au f ăcut tot drumul către host-ul destinație înainte ca TTL-ul să expire.
10.În măsur ătorile tracert, există vreun link a cărui întârziere este mult mai lungă decât a celorlalte? Priviți imaginea a patra, există acolo un link a cărui întârziere este mai lungă decât a altora? Bazându-vă pe numele routere-lor puteţi spune locaţia celor două routere de la capătul link-ului? Intre masuratoarea 3 si 4 brasov si Frankfurt
Lucrarea de laborator nr.9. Protocoalele Ethernet şi ARP
1. Care este adresa Ethernet pe 48b a computerului dvs?
2. Care este adresa destinaţie pe 48b din cadrul Ethernet? Este aceasta adresa Ethernet pentru “tc.unitbv.ro”? (Indiciu: răspunsul este nu). Ce dispozitiv are această adresă ca adresă pentru Ethernet? Atenţie la această întrebare !!! Bc:c0:of:6d:78:co 3. Scrieţi valoarea hexazecimală pentru câmpul de 2B “Frame-type”. Ce reprezintă în câmpul „flag” biţii a căror valoare este 0 (dar 1)?
4.
Câţi octeţi de la începutul cadrului Ethernet apar până la simbolul “G” în ASCII, din “GET” în cadrul Ethernet? 40 de octeti 5. Care este valoarea hexazecimală a câmpului CRC în acest cadru Ethernet? NU existe valoare hexa 6. Care este valoarea adresei sursă Ethernet? Este aceasta adresa computerului dvs, sau a lui “tc.unitbv.ro” (Indiciu: răspunsul este nu). Ce dispozitiv are aceasta drept adresa sa Ethernet? 00:0e:2e:59:33:f7. Adresa routerului 7. Care este valoarea adresei sursa Ethernet? Este această adresă Ethernet, adresa computerului dvs? 54:ee:75:c9:8a:f8. Adresa Ethernet a PC-ului 8. Scrieţi valoarea hexazecimală a câmpului de 2B “Frame type”’. În câmpul „flag”, ce înseamnă biţii a căror valoare este 0 (dar 1)? Frame type” este 0x0800. 9. Câţi octeţi de la începutul cadrului Ethernet apar până la simbolul ASCII “O”, din “OK” (de exemplu în HTTP response code), în acest cadru Ethernet? 54 de octeti 10. Care este valoarea hexazecimală a câmpului CRC în acest cadru Ethernet? Nu există valoarea hexazecimală pentru CRC
11. Scrieţi conţinutul cache-ului ARP. Ce reprezintă valoarea fiecărei coloane? Coloana ”Internet Address” conține adresele IP, coloana ”Physical Address” conține adresele MAC, iar coloana ”Type” indică tipul protocolului.
12. . Care sunt valorile hexazecimale pentru adresele sursă şi destinaţie din cadrul Ethernet care conţine mesajul de cerere ARP? Valoarea hexazecimală pentru adresa sursă este b8:70:f4:f9:da:77, iar valoarea hexazecimală pentru adresa destinație este ff:ff:ff:ff:ff:ff.
13. Scrieţi valoarea hexazecimală pentru câmpul de 2B Ethernet Frame type. Ce reprezintă biţii a căror valoare este 1 ? Frame type este 0x0806.
14. Descărcaţi specificaţiile ARP de la ftp://ftp.rfc-editor.org/innotes/std/std37.txt. Un alt studiu se afla şi la http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html a) Cu câți octeţi începe câmpul ARP opcode de la începutul cadrului Ethernet? 20 de octeti b) Care este valoarea câmpului opcode din porţiunea ARP-payload a cadrului Ethernet, prin care se face cererea ARP? Valoarea 1 c) Mesajul ARP conţine adresa IP a transmiţătorului? Adresa IP a transmițătorului este 192.168.8.18.
d) Unde apare “întrebarea” – adresa Ethernet a computerului a cărui adresă IP corespunzătoare este interogată? - în cererea ARP? În cererea ARP, ”întrebarea” – adresa Ethernet a computerului a cărui adresă IP corespunzătoare (în cazul meu 192.168.8.1) este interogată - apare în câmpul ”Target MAC Address”, care este setat la 00:00:00:00:00:00.
15. Acum găsiţi replica ARP care a fost trimisă ca răspuns cererii ARP. a) Cu câți octeţi începe câmpul ARP opcode de la începutul cadrului Ethernet? 20 de octeti b) Care este valoarea câmpului opcode din porţiunea ARP-payload a cadrului Ethernet, prin care se face răspunsul ARP? Valoarea câmpului opcode din porțiunea ARP-payload a cadrului Etherney este 2
c) Unde, în mesajul ARP, apare “răspunsul” la cererea ARP precedentă – adresa IP a computerului care are adresa Ethernet a cărui adresă IP corespunzătoare este interogată?
În mesajul ARP, ”răspunsul” la cererea ARP precedentă – adresa IP a computerului care are adresa Ethernet a cărui adresă IP corespunzătoare (în cazul meu 192.168.8.1) este interogată - apare în câmpul ”Sender MAC Address”, care are adresa Ethernet 00:30:05:82:84:b6.
16. Care sunt valorile hexazecimale pentru adresele sursă şi destinaţie din cadrul Ethernet care conţine mesajul „ARP reply”?
Valoarea hexazecimală pentru adresa sursă este: 00:30:05:82:84:b6. Valoarea hexazecimală pentru adresa destinație este: b8:70:f4:f9:da:77.
17. Deschideţi fişierul ethernet-trace-1 de pe CD). Primele două pachete ARP din aces t trace corespund unei cereri ARP trimisă de computerul pe care rulează Wireshark, şi replicii ARP trimisă către computerul cu Wireshark de către computerul cu “ARP-requested Ethernet address”. Dar mai există încă un computer în această reţea, după cum indică pachetul 6 – altă cerere ARP. De ce nu există o replică ARP (trimisă ca răspuns cererii ARP din pachetul 6) în trace? Apare cererea ARP la pachetul nr. 64, iar răspunsul apare la următorul pachet (nr. 65).
Lucrarea de laborator nr.10. Protocolul wireless 802.11
1. Care sunt SSID-urile celor două AP-uri care livrează cele mai multe dintre cadrele jalon din acest trace? SSID-ul primului AP este ”30 Munroe St.”, iar SSID-ul celui de-al doilea AP este ”linksys12”. 2. Care sunt intervalurile de timp dintre transmisia cadrelor jalon ale AP-ului Linksys_ses_24086? Dar pentru AP-ul 30 Munroe St.? (indiciu: acest interval este conţinut chiar în cadrul jalon) Intervalul jalon pentru ambele AP-uri sunt raportate în ”Beacon Interval” din ”IEEE 802.11 wireless LAN management frame” ca fiind de 0.1024 secunde.
3. Care (în notația hexa) este adresa MAC sursă a cadrului jalon din 30 Munroe St.? Reţineţi că sursa, destinaţia şi BSS-ul sunt 3 adrese folosite într-un cadru 802.11. Adresa MAC sursă a cadrului jalon din 30 Munroe St. este 00:16:b6:f7:1d:51.
4. Care (în notaţia hexa) este adresa MAC destinaţie a cadrului jalon din 30 Munroe St.? Adresa MAC destinație a cadrului jalon din 30 Munroe St. este ff:ff:ff:ff:ff:ff.
5. Care (în notaţia hexa) este ID-ul MAC BSS a cadrului jalon din 30 Munroe St.? ID-ul MAC BSS a cadrului jalon din 30 Munroe St. este 00:16:b6:f7:1d:51.
6. Cadrele jalon din AP-ul 30 Munroe St anunţă faptul că AP-ul poate suporta 4 “data rates” şi 8 “extended support rates” adiţionale. Ce sunt aceste “rates” ?
Cele 4 “data rates” pe care le poate suporta AP-ul 30 Munroe St . sunt 1, 2, 5.5 și 11 Mbps. Cele 8 “extended support rates” pe care le poate suporta AP-ul AP-ul 30 Munroe St . sunt 6, 9, 12, 18, 24, 36, 48 și 54 Mbps. 7. Găsiţi cadrul 802.11 care conţine segmentul SYN TCP pentru această primă sesiune TCP (care descarcă alice.txt). Care sunt trei câmpuri de adrese MAC din cadrul 802.11? Care adresă MAC din acest cadru corespunde host-ului wireless (daţi reprezentarea hexa a adresei MAC pentru host)? Dar AP-ului? Dar primului router (first-hop router)? Care este adresa IP a host-ului wireless care trimite acest segment TCP? Care este adresa IP destinaţie? Această adresă IP destinaţie corespunde host-ului, AP-ului, primului router, sau unui altui dispozitiv ataşat la rețea? Justificaţi răspunsul. Cele trei câmpuri de adrese MAC din cadrul 802.11 sunt: BSS id, source address, destination address
Adresa MAC care corespunde host-ului wireless este cea a sursei (00:13:02:d1:b6:4f). Adresa MAC care corespunde AP-ului este cea a lui BSS (00:16:b6:f7:1d:51).
Adresa MAC care corespunde primului router (first-hop router) este cea a destinației (00:16:b6:f4:eb:a8). Adresa IP a host-ului wireless care trimite acest segment este TCP este 192.168.1.109. Adresa IP destinație este: 128.119.245.12. Această adresă IP destinație corespunde serverului gaia.cs.umass.edu. Adresa MAC destinație a cadrului care conține SYN este diferită de adresa IP de destinație a pachetului IP conținut în acest cadru. 8. Găsiți cadrul 802.11 care conţine segmentul SYN ACK pentru această sesiune TCP. Care sunt trei câmpuri de adrese MAC din cadrul 802.11? Care adresă MAC din acest cadru corespunde host-ului? Dar AP-ului? Dar primului router? Adresa MAC a transmiţătorului din cadru corespunde adresei IP a dispozitivului care a trimis segmentul TCP încapsulat în această datagramă? Cele trei câmpuri de adrese MAC din cadrul 802.11 sunt: BSS id, source address, destination address
Adresa MAC care corespunde host-ului este cea a destinației (91:2a:b0:49:b6:4f). Adresa MAC care corespunde AP-ului este cea a lui BSS (00:16:b6:f7:1d:51). Adresa MAC care corespunde primului router este cea a sursei (00:16:b6:f4:eb:a8). Adresa IP a server-ului care a trimis segmentul TCP încapsulat este 128.199.245.12. Nu, adresa MAC a transmițătorului din cadru nu corespunde adresei IP a dispozitivului care a trimis segmentul TCP încapsulat în această datagramă.
9. Care două acţiuni sunt f ăcute (de exemplu cadre trimise) de c ătre host în trace-ul imediat după t=49, pentru a termina asocierea cu AP-ul 30 Munroe St care a fost iniţial activ atunci când a început captura trace-ului? (indiciu: una este o acţiune de layer IP, iar alta este de layer 802.11). Privind specificaţiile 802.11, există vreun alt cadru pe care v-aţi fi aşteptat să-l vedeți, dar care nu se vede aici? La t = 49.583615 un release DHCP este trimis de către gazdă către serverul DHCP (a cărui adresă IP este 192.168.1.1) în rețeaua pe care o părăsește host-ul. La t = 49.609617, host-ul trimite un cadru DEAUTHENTICATION (Type = Management frame (0), Subtype = 12). S-ar fi putut aștepta să fie trimisă o cerere de DISASSOCIATION.
10. Priviţi trace-ul şi căutaţi cadrele AUTHENTICATION trimise de la host către AP şi viceversa. Câte mesaje AUTHENTICATION sunt trimise de la host-ul wireless către AP-ul Linksys_ses_24086 (care are adresa MAC Cisco_Li_f5:ba:bb) care începe în jurul lui t=49? Primul mesaj AUTHENTICATION trimis de la host-ul wireless către AP-ul Linksys_ses_24086 este la momentul t = 49.638857 și, în total, sunt trimise 19 mesaje.
11. Se vede o replică AUTHENTICATION de la AP-ul Linksys_ses_24086 în trace? Nu se vede. 12. Acum să studiem ce se întâmplă dacă host-ul renunţă la a mai încerca să se asocieze cu AP-ul Linksys_ses_24086 şi acum încearcă să se asocieze cu AP -ul 30 Munroe St . Căutaţi cadrele AUTHENTICATION trimise de la host către ţi viceversa. La care momente de timp apare un cadru AUTHENTICATION de la
host către AP-ul 30 Munroe St, şi când apare un răspuns AUTHENTICATION trimis de la acel AP către host? (puteţi folosi expresiile de filtrare “wlan.fc.subtype == 11 si wlan.fc.type == 0 şi wlan.addr == IntelCor_d1:b6:4f” pentru a afişa doar cadrele AUTHENTICATION) La t = 63.168087 există un cadru AUTHENTICATION trimis de la 00:13:02:d1:b6:4f (host) la 00:16:b7:f7:1d:51 (AP). La t = 63.169071 există un cadru AUTHENTICATION trimis din direcția inversă de la AP la host. 13. Un cadru ASSOCIATE REQUEST şi un cadru ASSOCIATE RESPONSE corespunzător de la AP la host sunt folosite pentru ca hostul să se asocieze cu un AP. La care moment de timp apare un ASSOCIATE REQUEST de la host la AP -ul 30 Munroe St ? Când este trimis cadrul ASSOCIATE REPLY corespunzător? (puteţi folosi expresiile de filtrare wlan.fc.subtype<2 si wlan.fc.type == 0 si wlan.addr == IntelCor_d1:b6:4f p entru a a fişa d oar c adrele A SSOCIATE R EQUEST ş i ASSOCIATE RESPONSE) La t = 63.169910 există un cadru ASSOCIATE REQUEST trimis de la 00:13:02:d1:b6:4f (host) la 00:16:b7:f7:1d:51 (AP). La t = 63.192101 există un cadru ASSOCIATE RESPONSE trimis în direcția inversă de la AP la host.
14. Ce rate de transmisie doreşte host-ul să folosească? Dar AP-ul? Pentru a răspunde la aceste întrebări, trebuie să căutaţi în câmpurile de parametri ai cadrului de management 802.11 wireless LAN. Ratele de transmisie pe care hostul dorește să le folosească sunt următoarele: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48 și 54 Mbps. Aceste rate de transmisie sunt aceleași și la AP.
15. Care sunt adresele de BSS ID MAC ale transmiţătorului şi receptorului din aceste cadre? Care este scopul acestor două tipuri de cadre? (este bine să consultaţi aici referinţele online citate în acest laborator). La t = 2.297613 există un PROBE REQUEST trimis cu sursa 00:12:f0:1f:57:13, destinația ff:ff:ff:ff:ff:ff și BSS ID ff:ff:ff:ff:ff:ff. La t = 2.300697 există un PROBE RESPONSE trimis cu sursa 00:16:b6:f7:1d:51, destinația 00:12:f0:1f:57:13și BSS ID 00:16:b6:f7:1d:51. Un PROBE REQUEST este folosit de un host în scanare activă pentru a găsi un AP. Un PROBE RESPONSE este trimis de către AP către host-ul care trimite cererea
Lucrarea de laborator nr.11. Protocolul DHCP
1. Mesajele DHCP sunt trimise peste UDP sau peste TCP? Mesajele DHCP sunt trimise peste UDP.
2. Desenaţi o datagramă temporală ilustrând succesiunea primelor 4 pachete Discover/Offer/Request/ACK DHCP între client şi server. La fiecare pachet indicaţi porturile sursă şi destinaţie. Sunt aceleaşi porturi ca în exemplul de mai sus? Da, sunt aceleași porturi. 3. Care este adresa link-layer (de exemplu Ethernet) a computerului? Adresa link-layer a computerului este 54:ee:75:c9:8a:f8. 4. Ce valori din mesajul DHCP Discover diferenţiază acest mesaj de mesajul DHCP Request? Valoarea din mesajul DHCP care diferențiază acest mesaj de mesajul DHCP Request este cea de la Option: (53) DHCP Message Type. 5. Care este valoarea „Transaction-ID-ului” pentru fiecare dintre primele 4 mesaje (Discover/Offer/Request/ACK) DHCP ? Care este valoarea „Transaction-ID-ului pentru al doilea set (Request/ACK) de mesaje DHCP? Care este scopul câmpului Transaction-ID?
Valoarea „Transaction-ID-ului” pentru fiecare dintre primele 4 mesaje (Discover/Offer/Request/ACK) DHCP este 0xf186db36. Valoarea „Transaction-ID-ului” pentru al doilea set (Request/ACK) de mesaje DHCP este 0x5db53f5a. Un „Transaction-ID” este utilizat astfel încât serverul DHCP să poată face diferența între cererile clientului în timpul procesului de solicitare. 5. Un computer foloseşte DHCP pentru a obţine, printre altele, o adresă IP. Dar IP -ul unui computer nu este confirmat până la sfârșitul schimbului de 4 mesaje! Dacă adresa IP nu este setată până la sfârșitul schimbului celor 4 mesaje, atunci ce valori sunt folosite în datagramele IP în respectivul schimb? La fiecare dintre cele 4 mesaje DHCP (Discover/Offer/Request/ACK) indicaţi porturile sursă şi destinaţie care sunt transportate în datagrama IP. 6. Clientul și serverul DHCP folosesc ambele 255.255.255.255 ca adresă destinație. Clientul
utilizează adresa IP sursă 0.0.0.0, în timp ce serverul utilizează adresa IP actuală ca sursă. La mesajele DHCP Discover şi DHCP Request avem: - Portul sursă: 68; - Portul destinaţie: 67. La mesajele DHCP Offer şi DHCP ACK avem: - Portul sursă: 67; - Portul destinaţie: 68. 7. Care este adresa IP a serverului DHCP? Adresa IP a serverului DHCP este 192.168.0.1.
8. Ce adresă IP oferă serverul DHCP computerului dvs în mesajul DHCP Offer? Indicaţi care mesaj DHCP conţine adresa IP oferită. Serverul DHCP oferă computerului meu adresa IP 192.168.0.100. Mesajul DHCP cu ”DHCP Message Type *DHCP: Offer (2)+” conține adresa IP dorită. 9. În imaginea de mai sus, nu există “relay agent” între computer şi serverul DHCP. Care valori din trace indică absenţa unui “relay agent”? Există un “relay agent” în experiment? Dacă da, care este IP-ul lui? Adresa IP al “relay agent”-ului este 0.0.0.0, ceea ce indică absența unui “relay agent”. Nu, nu există niciun “relay agent” în experiment.s 10. Explicaţi scopul router-ului şi a măștii din mesajul DHCP Offer. Linia ”Option: (3) Router” indică clientului ce ar trebui să fie gateway-ul său implicit. Linia ”Option: (1) Subnet Mask” îi spune clientului care mască de subrețea ar trebui să o utilizeze.
11. În imaginile de mai sus, computerul cere adresa IP oferită în mesajul DHCP Request . Ce se întâmplă în experimentul vostru? În experimentul meu, host-ul solicită adresa IP oferită în mesajul DHCP Request. 12. Ce scop are “lease time” (timpul de închiriere)? Cât de mare este el în experimentul dvs? Timpul de închiriere reprezintă perioada în care serverul DHCP atribuie o adresă IP unui client. În timpul perioadei de închiriere, serverul DHCP nu va atribui IP-ul acordat clientului unui alt client, decât dacă este eliberat de client. Odată ce termenul de închiriere a expirat, adresa IP poate fi refolosită de serverul DHCP pentru a da unui alt client. În experimentul meu, timpul de închiriere este de 7 zile. 13. Care este scopul mesajului DHCP Release? Serverul DHCP oferă vreo confirmare a primirii cererii clientului? Ce s-ar întâmpla dacă mesajul DHCP release al clientului, s-ar pierde? Clientul trimite un mesaj DHCP Release pentru a-și anula leasing-ul pe adresa IP dată de serverul DHCP. Serverul DHCP nu trimite un mesaj înapoi către client, confirmând mesajul DHCP Release. Dacă mesajul DHCP Release de la client este pierdut, serverul DHCP va trebui să aștepte până când perioada de leasing va fi terminată pentru acea adresă IP până când nu ar putea fi reutilizată pentru alt client. 14. Ştergeţi filtrul bootp din Wireshark. A fost vreun pachet ARP trimis sau primit în perioada schimbului de pachete DHCP? Dacă da, explicaţi scopul pentru care există aceste pachete ARP. Nu, nu a fost trimis sau primit niciun pachet ARP în perioada schimbului de pachete DHCP.
Lucrarea de laborator nr.12. Protocolul SSL
1. Pentru fiecare dintre cele 8 cadre Ethernet, specificaţi sursa cadrului (client sau server), determinaţi numărul de tipuri de înregistrări SSL care sunt incluse în cadru, şi listaţi tipurile de înregistrări SSL care sunt incluse în cadru. Desenaţi o diagramă temporală între client şi server, cu o săgeată pentru fiecare înregistrare SSL.
2. Fiecare din înregistrările SSL începe cu aceleaşi 3 câmpuri (posibil cu valori diferite). Unul dintre aceste câmpuri este “content type” şi are lungimea de un octet. Listaţi toate 3 câmpurile şi lungimile lor.
Content Type – 1 octet; Version – 2 octeți; Length – 2 octeți.
3.
Extindeţi înregistrarea „ClientHello” ( dacă trace-ul conţine mai multe înregistrări “ClientHello”, extindeţi-o pe prima). Care este valoarea lui “content type”? ”content type” este 22. 4. Înregistrarea „ClientHello” conţine un “nonce” (sau “challenge”) ? Dacă da, care este valoarea challenge-ului în notaţia hexazecimală? Valoarea challenge-ului în notația hexazecimală este 66df784c048cd60435dc448989469909
5. Înregistrarea „ClientHello” face cunoscută “cyber suites” pe care le suportă? Dacă da, în
prima suită listată, care sunt: algoritmul public-key, algoritmul symmetric-key şi algoritmul hash? Da. În prima suită listată, avem RSA ( public-key), RC4 (symmetric-key) și MD5 (hash). 6. Găsiţi înregistrarea „ServerHello”. Există aici vreo informaţie care spune ce “cipher suite” s-a folosit? Care sunt algoritmii folosiți în suita care s-a ales? Da. În suita care s-a ales, avem RSA ( public-key), RC4 ( symmetric-key) și MD5 (hash).
7. Această înregistrare include un “nonce”? Dacă da, cât de lung este? Care este scopul nonce-urilor clientului şi serverului în SSL? Da, sub câmpul ”Random”. ”Nonce”-ul este lung de 32 de octeți (4 octeți pentru timp și 28 octeți pentru date). Scopul este de a preveni un atac de reluare.
8. Această înregistrare include un ID de sesiune. Care este scopul acestui ID? Scopul acestui ID este acela de oferi un identificator persistent unic pentru sesiunea SSL care este trimisă în mod clar. Clientul poate relua aceeași sesiune mai târziu utilizând IDul de sesiune furnizat de server când trimite ”ClientHello”.
9. Această înregistrare conţine o certificare, sau este această certificare inclusă într-o înregistrare separată? Încape această certificare într-un singur cadru Ethernet? Această înregistrare nu conține nici o certificare. Această certificare este inclusă întro înregistrare separată. Da, această certificare încape într-un singur cadru Ethernet.
10. Găsiţi înregistrarea “Client Key Exchange”. Conţine această înregistrare un secret “pre-master” ? La ce este folosit acest secret ? Este criptat? Daca da, cum? Cat de lung este acest secret? Da, această înregistrare conține un secret “pre-master”. Acest secret este folosit atât de server cât și de client pentru a face un secret ”master”, care este folosit pentru a genera chei de sesiune pentru MAC și criptare. Secretul este criptat folosind cheia publică a serverului, pe care clientul o extrage din certificatul trimis de server. Secretul are o lungime de 132 octeți.
11. Care este scopul înregistrării „Change Cipher Spec”? Câţi octeţi are înregistrarea din trace -ul vostru? Scopul înregistrării „Change Cipher Spec” este acela de a indica că conținutul următoarelor înregistrări SSL trimise de client (date, nu header) va fi criptat. Această înregistrare are o lungime de 6 octeți.
