Početna › Wireshark i analiza mrežnog saobraćaja › Teorija
💾

Teorija – Modul 19 – Wireshark i analiza mrežnog saobraćaja

Napomena: svaka tema u ovom dokumentu sadrži sedam elemenata: (1) jednostavno objašnjenje, (2) stručno objašnjenje, (3) primer iz svakodnevnog života, (4) primer iz poslovnog IT okruženja, (5) praktičnu vežbu ili napomenu, (6) najčešće greške, (7) pitanje za proveru znanja.

Podsetnik o nameni: Sve tehnike u ovom modulu primenjuju se isključivo na sopstvenoj laboratorijskoj mreži, radi razumevanja protokola i dijagnostike sopstvenih sistema.

Tema 1 – Instalacija Wireshark-a i Npcap

1. Jednostavno objašnjenje

Wireshark je program koji prikazuje mrežni saobraćaj, ali mu je potrebna dodatna komponenta koja mu zapravo omogućava da „vidi" taj saobraćaj na nivou operativnog sistema.

2. Stručno objašnjenje

Wireshark sam po sebi je samo prikazivač i analizator paketa — stvarno hvatanje (capture) saobraćaja sa mrežne kartice zahteva poseban drajver koji ima pristup mrežnom interfejsu na niskom nivou. Na Windows-u, to je Npcap (naslednik starijeg WinPcap-a); na Linux/macOS sistemima, to je libpcap, obično već ugrađen u sistem, ali sa zahtevom da korisnik ima odgovarajuće dozvole (na Linux-u, članstvo u wireshark grupi, Modul 18 koncept dozvola primenjen na pristup mrežnom interfejsu). Bez ove komponente, Wireshark se pokreće, ali ne prikazuje nijedan dostupan interfejs za snimanje.

3. Primer iz svakodnevnog života

Wireshark bez Npcap-a/libpcap-a je kao TV bez antenskog kabla — uređaj radi, ali nema signal da prikaže, jer mu nedostaje fizička veza sa izvorom.

4. Primer iz poslovnog IT okruženja

Novi analitičar koji instalira Wireshark na svom Windows laptopu, ali tokom instalacije slučajno odustane od instalacije Npcap komponente (misleći da je opciona), primećuje da lista interfejsa u Wireshark-u ostaje potpuno prazna — čest, lako izbegnut problem obrađen u uputstvo-za-instalaciju-alata.md.

5. Praktična vežba / napomena

Proverite da li je Wireshark ispravno instaliran prema koracima u uputstvo-za-instalaciju-alata.md — pri pokretanju, na početnom ekranu treba da vidite listu dostupnih interfejsa sa malim grafikonima saobraćaja pored njih.

6. Najčešće greške

  • Preskakanje instalacije Npcap komponente na Windows-u tokom Wireshark instalacije.
  • Na Linux-u, pokušaj pokretanja Wireshark-a bez odgovarajućih dozvola (bez dodavanja korisnika u wireshark grupu, Modul 18) — rezultuje praznom ili ograničenom listom interfejsa.

7. Pitanje za proveru znanja

P: Zašto Wireshark sam po sebi ne može da snima mrežni saobraćaj bez dodatne komponente poput Npcap-a? O: Wireshark je prikazivač/analizator paketa; stvarno hvatanje saobraćaja sa mrežne kartice na niskom nivou zahteva poseban drajver (Npcap na Windows-u, libpcap na Linux/macOS-u) koji ima pristup interfejsu ispod nivoa običnih aplikacija.

Tema 2 – Mrežni interfejsi i promiscuous mode

1. Jednostavno objašnjenje

Pre snimanja, potrebno je izabrati koji mrežni „ulaz" (interfejs) da se posmatra — pogrešan izbor znači da ćete snimati potpuno pogrešan (ili nikakav) saobraćaj.

2. Stručno objašnjenje

Wireshark prikazuje sve dostupne mrežne interfejse sistema (fizičke i virtuelne, npr. VirtualBox Host-only adapter, Modul 17-18) sa live grafikonom aktivnosti pored svakog — pomaže da se identifikuje koji interfejs zaista nosi saobraćaj koji vas zanima. Promiscuous mode je režim mrežne kartice u kome ona prosleđuje sve primljene frejmove operativnom sistemu, ne samo one adresirane direktno njoj (podrazumevano ponašanje van promiscuous mode-a) — koristan na huabovima ili portovima za mirroring (SPAN port, Modul 16 koncept), ali na modernim svič-baziranim mrežama, promiscuous mode na jednom portu i dalje ne vidi saobraćaj namenjen drugim portovima svič-a, jer svič šalje frejmove samo na port odredišne MAC adrese (Modul 8).

3. Primer iz svakodnevnog života

Biranje interfejsa je kao biranje na koji prozor da gledate da biste videli ulicu — ako gledate kroz pogrešan prozor (interfejs koji nije povezan na relevantnu mrežu), nećete videti ništa korisno bez obzira koliko pažljivo posmatrate.

4. Primer iz poslovnog IT okruženja

Analitičar koji pokušava da snimi saobraćaj između dva servera u VirtualBox Internal Network-u (Modul 17) mora da snima na host-only ili internal interfejsu koji odgovara toj virtuelnoj mreži, ne na fizičkom Wi-Fi adapteru laptopa — pogrešan izbor interfejsa rezultuje snimkom sopstvenog, nepovezanog saobraćaja.

5. Praktična vežba / napomena

Na svom računaru otvorite Wireshark i pregledajte listu dostupnih interfejsa — identifikujte koji odgovara vašoj fizičkoj mreži, a koji virtuelnim VirtualBox adapterima korišćenim u Modulima 17-18.

6. Najčešće greške

  • Snimanje na pogrešnom interfejsu (npr. Wi-Fi umesto Ethernet-a, ili obrnuto) i zaključivanje da „mreža ne generiše nikakav saobraćaj".
  • Pretpostavka da promiscuous mode na modernom svič-u omogućava snimanje celokupnog saobraćaja mreže — svič i dalje ograničava vidljivost na osnovu MAC adresne tabele, osim ako nije eksplicitno konfigurisan port mirroring.

7. Pitanje za proveru znanja

P: Zašto promiscuous mode na portu modernog sviča ne garantuje da ćete videti sav saobraćaj cele mreže? O: Svič po dizajnu šalje unicast frejmove samo na port koji odgovara odredišnoj MAC adresi (Modul 8) — promiscuous mode omogućava mrežnoj kartici da prihvati sve frejmove koje fizički primi, ali ne menja to koje frejmove joj svič uopšte prosleđuje, osim ako je konfigurisan poseban port mirroring/SPAN.

Tema 3 – Capture filteri

1. Jednostavno objašnjenje

Capture filter određuje koji saobraćaj Wireshark uopšte snima, primenjen pre nego što snimanje počne — sve što ne odgovara filteru se nikad i ne zapisuje.

2. Stručno objašnjenje

Capture filteri koriste BPF (Berkeley Packet Filter) sintaksu, primenjenu na nivou operativnog sistema/drajvera pre snimanja — paketi koji ne odgovaraju filteru se nikad ne beleže niti troše memoriju/disk prostor. Osnovna sintaksa: host <adresa> (samo saobraćaj ka/od te adrese); net <mreža>/<prefiks> (saobraćaj ka/od cele mreže); port <broj> (saobraćaj na tom portu); tcp/udp/icmp/arp (samo taj protokol); kombinacije preko and/or/not (npr. host 192.168.1.10 and tcp). Capture filteri su korisni kada se snima na zauzetoj mreži gde bi snimanje svega generisalo ogromnu, teško pregledljivu datoteku — ali imaju manu da se ne mogu retroaktivno primeniti na saobraćaj koji je propušten pre nego što je filter definisan.

3. Primer iz svakodnevnog života

Capture filter je kao selektivni portir na ulazu u zgradu koji odmah vraća sve posetioce koji ne odgovaraju unapred definisanim kriterijumima — oni nikad i ne uđu u zgradu (ne beleže se), za razliku od pretraživanja već postojeće evidencije svih koji su ušli.

4. Primer iz poslovnog IT okruženja

Analitičar koji snima saobraćaj na zauzetom serverskom segmentu sa hiljadama paketa u sekundi koristi capture filter host 192.168.1.10 da snimi isključivo saobraćaj ka/od jednog konkretnog servera koji dijagnostikuje, izbegavajući da nepotrebno hvata i analizira saobraćaj stotina drugih, nepovezanih uređaja na istom segmentu.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, koristićete capture filter host <adresa-vaše-VM> da ograničite snimanje isključivo na saobraćaj vezan za vašu laboratorijsku virtuelnu mašinu.

6. Najčešće greške

  • Pokušaj izmene capture filtera nakon što je snimanje već počelo, očekujući da će filter retroaktivno „očistiti" već snimljen saobraćaj — capture filter deluje samo na budući, ne prošli saobraćaj u toj sesiji.
  • Mešanje capture filter sintakse sa display filter sintaksom (Tema 4) — iako slične, imaju različita pravila (npr. host naspram ip.addr).

7. Pitanje za proveru znanja

P: Zašto se capture filter mora definisati pre početka snimanja da bi imao efekta na taj konkretan paket? O: Capture filter se primenjuje na nivou operativnog sistema/drajvera u trenutku kada paket stiže — paketi koji ne odgovaraju filteru se nikad i ne zapisuju u snimak, pa naknadna izmena filtera ne može „vratiti" i primeniti se na pakete koji su već stigli i bili odbačeni pre te izmene.

Tema 4 – Display filteri

1. Jednostavno objašnjenje

Display filter ne menja šta je snimljeno — samo određuje šta se prikazuje na ekranu iz već snimljenog saobraćaja, i može se menjati koliko god puta želite bez gubitka podataka.

2. Stručno objašnjenje

Display filteri koriste sopstvenu, moćniju sintaksu (ne BPF kao capture filteri) i primenjuju se nakon snimanja, na već uhvaćene pakete — mogu se menjati proizvoljno, bez gubitka bilo kog podatka, jer samo kontrolišu prikaz, ne sam čin snimanja. Osnovna sintaksa koristi polja protokola: ip.addr == 192.168.1.10 (paketi ka/od te adrese); tcp.port == 443; http; dns; arp; icmp. Logički operatori: && (and), || (or), ! (not). Poređenja: ==, !=, >, <. Wireshark vizuelno potvrđuje ispravnost sintakse (zelena pozadina polja filtera = ispravna sintaksa, crvena = greška) pre nego što se filter uopšte primeni.

3. Primer iz svakodnevnog života

Display filter je kao pretraga po ključnoj reči u već sačuvanom, kompletnom video-nadzornom snimku — snimak (svi podaci) ostaje netaknut i kompletan, a vi samo menjate koji delovi se trenutno prikazuju na ekranu, koliko god puta želeli.

4. Primer iz poslovnog IT okruženja

Analitičar koji je snimio sav saobraćaj bez capture filtera (Tema 3) zatim koristi niz različitih display filtera na istom snimku — prvo dns da proveri DNS upite, zatim tcp.flags.syn == 1 da vidi sve pokušaje uspostavljanja TCP konekcije, bez potrebe da ponovo snima saobraćaj za svaku novu analizu.

5. Praktična vežba / napomena

Nakon što snimite saobraćaj u laboratorijskoj vežbi ovog modula, primenite redom display filtere arp, icmp, dns, i tcp.flags.syn == 1 na isti snimak, bez ponovnog pokretanja snimanja.

6. Najčešće greške

  • Zaboravljanje razlike u sintaksi između capture (host 192.168.1.10) i display (ip.addr == 192.168.1.10) filtera — kucanje capture sintakse u display polje (ili obrnuto) rezultuje greškom ili neočekivanim ponašanjem.
  • Ignorisanje crvene pozadine polja filtera (znak sintaksne greške) i čuđenje zašto filter „ne radi".

7. Pitanje za proveru znanja

P: Zašto se display filter može menjati proizvoljno mnogo puta na istom snimku, dok se capture filter praktično ne može retroaktivno menjati? O: Display filter samo kontroliše šta se prikazuje iz već snimljenih, sačuvanih podataka — ništa se ne gubi menjanjem filtera. Capture filter kontroliše šta se uopšte snima u trenutku dolaska paketa — paketi odbačeni pre izmene filtera su trajno izgubljeni za tu sesiju snimanja.

Tema 5 – Analiza ARP saobraćaja

1. Jednostavno objašnjenje

ARP saobraćaj u Wireshark-u izgleda tačno onako kako je opisan u teoriji (Modul 2) — jedan broadcast zahtev i jedan unicast odgovor, sada vidljivi kao stvarni paketi.

2. Stručno objašnjenje

Filter arp izoluje ARP saobraćaj (Modul 2). Tipičan par: ARP Request — „Who has 192.168.1.1? Tell 192.168.1.10", poslat kao broadcast (odredišna MAC ff:ff:ff:ff:ff:ff); ARP Reply — „192.168.1.1 is at aa:bb:cc:dd:ee:ff", poslat kao unicast direktno onome ko je pitao. U Wireshark-u, klik na paket i širenje Address Resolution Protocol sekcije u donjem panelu prikazuje tačna polja (Sender MAC/IP, Target MAC/IP) koja odgovaraju teorijskom opisu ARP protokola.

3. Primer iz svakodnevnog života

Posmatranje ARP saobraćaja u Wireshark-u je kao gledanje snimka nekoga ko glasno pita „ko živi na broju 5?" (broadcast) i osobe koja odgovara direktno njemu „ja, evo me" (unicast) — apstraktan koncept iz teorije postaje doslovno vidljiv događaj.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje sumnju na ARP spoofing (Modul 16) snima saobraćaj sa filterom arp i proverava da li za istu IP adresu (npr. gateway) postoje višestruki, konfliktni ARP odgovori sa različitih MAC adresa u kratkom vremenskom periodu — jasan znak potencijalnog napada.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, snimićete saobraćaj i pokrenuti ping ka novom, ranije nekontaktiranom uređaju na mreži, zatim primeniti filter arp da vidite tačan ARP Request/Reply par koji prethodi ICMP saobraćaju (Tema 6).

6. Najčešće greške

  • Očekivanje ARP saobraćaja za svaku komunikaciju — ARP se dešava samo kada uređaj nema već keširan MAC unos za odredišnu IP adresu (ARP keš, sličan konceptu iz Windows/Linux arp -a, Moduli 17-18); ponovljena komunikacija ka istoj adresi u kratkom periodu neće generisati novi ARP saobraćaj.
  • Zaboravljanje da je ARP Request broadcast (vidljiv svim uređajima na segmentu), dok je Reply unicast (vidljiv samo pošiljaocu i primaocu, osim ako se snima na portu sa mirroring-om).

7. Pitanje za proveru znanja

P: Zašto se ARP saobraćaj ne pojavljuje za svaku pojedinačnu komunikaciju sa već poznatim uređajem? O: Uređaji čuvaju ARP keš (mapiranje IP → MAC) određeno vreme nakon prve rezolucije — ponovljena komunikacija ka istoj IP adresi u tom periodu koristi već keširanu MAC adresu, bez potrebe za novim ARP Request/Reply parom.

Tema 6 – Analiza ICMP saobraćaja

1. Jednostavno objašnjenje

ICMP saobraćaj u Wireshark-u prikazuje tačno one Echo Request/Reply parove koje generiše ping komanda (Moduli 2, 17, 18), sa svim detaljima koji inače nisu vidljivi u samom terminalu.

2. Stručno objašnjenje

Filter icmp izoluje ICMP saobraćaj. Tipičan par: Echo (ping) request (Type 8) i Echo (ping) reply (Type 0), sa poljima Identifier i Sequence number koja povezuju svaki zahtev sa odgovarajućim odgovorom (korisno kada ima više paralelnih ping sesija). Wireshark takođe prikazuje Time kolonu koja pokazuje tačno vreme između zahteva i odgovora — precizniju verziju iste latencije koju ping komanda ispisuje u terminalu (Moduli 15, 17, 18), ali sada vidljivu na nivou pojedinačnog paketa, uključujući IP zaglavlje (TTL, Modul 11) svakog paketa.

3. Primer iz svakodnevnog života

Analiza ICMP-a u Wireshark-u je kao gledanje štoperice i detaljnog zapisa svakog pojedinačnog „viknuo sam i čuo odjek" pokušaja, umesto da samo pročitate sažet rezultat („4 od 4 uspešna, prosečno vreme 2ms") na kraju.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje povremeno spor odgovor na ping snima saobraćaj tokom testa i upoređuje Time vrednosti pojedinačnih ICMP paketa — otkriva da su vremena uglavnom niska (1-2ms), ali povremeno naglo skoče na 200ms, ukazujući na jitter (Modul 15) koji sažet rezultat ping komande u terminalu ne bi jasno prikazao.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, primenite filter icmp na snimak iz Teme 5 i identifikujte Identifier/Sequence number polja koja povezuju svaki Request sa odgovarajućim Reply paketom.

6. Najčešće greške

  • Zaboravljanje da ICMP Echo Request/Reply nema koncept „porta" (za razliku od TCP/UDP) — povezivanje zahteva i odgovora se vrši preko Identifier/Sequence number polja, ne portova.
  • Mešanje ICMP Type 8 (request) i Type 0 (reply) brojeva — lako zapamtiti da je „echo" simetričan par, ali vredi znati tačne numeričke vrednosti pri čitanju sirovih detalja paketa.

7. Pitanje za proveru znanja

P: Koja dva polja u ICMP Echo paketima omogućavaju povezivanje konkretnog Request-a sa odgovarajućim Reply-jem, posebno kada ima više paralelnih ping sesija? O: Identifier i Sequence number.

Tema 7 – Analiza DNS saobraćaja

1. Jednostavno objašnjenje

DNS saobraćaj u Wireshark-u pokazuje tačan upit koji je klijent poslao i tačan odgovor koji je DNS server vratio, uključujući sve detalje koje nslookup/dig (Moduli 13, 17, 18) prikazuju u sažetom obliku.

2. Stručno objašnjenje

Filter dns izoluje DNS saobraćaj (Modul 13), tipično preko UDP porta 53. Tipičan par: DNS Query (sadrži traženo ime i tip zapisa, npr. A) i DNS Response (sadrži odgovor, uključujući IP adresu i TTL vrednost zapisa). Polje Transaction ID povezuje svaki upit sa odgovarajućim odgovorom (analogno Identifier polju kod ICMP-a, Tema 6) — bitno kada se prati DNS saobraćaj sa mnogo paralelnih upita. Wireshark prikazuje kompletnu strukturu DNS odgovora (Answer, Authority, Additional sekcije, isti koncept kao dig izlaz iz Modula 18), uz mogućnost da se u istom snimku vidi i sam naredni saobraćaj (npr. TCP handshake, Tema 9) ka IP adresi koju je DNS upravo vratio — direktno demonstrirajući da rezolucija imena prethodi stvarnoj komunikaciji.

3. Primer iz svakodnevnog života

DNS analiza u Wireshark-u je kao gledanje snimka nekoga ko prvo pita imenik za broj telefona (DNS upit), dobija odgovor (DNS odgovor), i tek onda bira taj broj (naredna TCP konekcija) — svi koraci vidljivi jedan za drugim u tačnom hronološkom redosledu.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje zašto korisnik ne može da pristupi internom sajtu snima saobraćaj tokom pokušaja pristupa i filtrira sa dns — ako DNS odgovor sadrži pogrešnu ili zastarelu IP adresu (visok TTL sa starim podatkom), problem je jasno izolovan na DNS nivo, pre nego što se uopšte pokuša bilo kakva TCP konekcija.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, snimićete saobraćaj tokom pristupa veb sajtu preko imena i primeniti filter dns da vidite tačan upit/odgovor par, zatim primetiti sledeći TCP SYN paket (Tema 9) upućen baš onoj IP adresi koju je DNS vratio.

6. Najčešće greške

  • Zaboravljanje da DNS odgovor može sadržati više IP adresa za isto ime (round-robin DNS ili više servera) — naredna TCP konekcija ide ka jednoj od njih, ne nužno prvoj u listi.
  • Mešanje DNS upita (port 53) sa mDNS ili drugim sličnim protokolima koji koriste drugačije portove/adrese — filter dns u Wireshark-u može obuhvatiti oboje ako nije dodatno precizirano.

7. Pitanje za proveru znanja

P: Koje polje u DNS paketima povezuje konkretan upit sa odgovarajućim odgovorom? O: Transaction ID.

Tema 8 – Analiza DHCP DORA procesa

1. Jednostavno objašnjenje

Ceo DORA proces (Discover, Offer, Request, Acknowledge, Modul 13) postaje vidljiv kao tačno četiri paketa u Wireshark-u, tačno onim redosledom kako je opisano u teoriji.

2. Stručno objašnjenje

Filter bootp (ili dhcp, zavisno od verzije Wireshark-a — DHCP je istorijski izgrađen na BOOTP protokolu) izoluje DHCP saobraćaj (UDP portovi 67/68, Modul 13). Snimak prikazuje tačno četiri paketa u DORA redosledu: DHCP Discover (broadcast, klijent traži server), DHCP Offer (server nudi adresu), DHCP Request (broadcast, klijent potvrđuje izbor), DHCP Acknowledge (server zvanično dodeljuje). Klik na svaki paket i širenje Bootstrap Protocol sekcije prikazuje tačna polja — dodeljenu IP adresu, opcije poput Router (Option 3) i DNS Server (Option 6), potpuno usklađene sa konceptima iz Modula 13.

3. Primer iz svakodnevnog života

Snimanje DORA procesa je kao gledanje snimka celog procesa iznajmljivanja hotelske sobe iz Modula 13 (pitanje na recepciji, ponuda, potvrda, zvanično useljenje) — sada doslovno vidljivo, korak po korak, umesto samo teorijski opisano.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje zašto klijent dobija adresu od pogrešnog (rogue) DHCP servera (Modul 16) snima DHCP saobraćaj i proverava izvorišnu MAC/IP adresu DHCP Offer paketa — ako dolazi sa neočekivanog uređaja, to potvrđuje prisustvo neovlašćenog servera, dopunjujući dijagnostiku koja bi se inače oslanjala samo na DHCP snooping log zapise.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, snimićete saobraćaj tokom ipconfig /renew (Windows) ili ekvivalentne akcije na Linux klijentu (Modul 18), primenićete filter bootp, i identifikovati sva četiri DORA paketa po redosledu.

6. Najčešće greške

  • Pokretanje snimanja nakon što je klijent već dobio adresu — DORA proces se neće ponoviti dok klijent ne zatraži novu adresu (release/renew) ili se ne restartuje.
  • Zabuna između bootp i dhcp filtera u različitim verzijama Wireshark-a — oba obično rade, ali vredi proveriti koji je tačan naziv u vašoj instaliranoj verziji.

7. Pitanje za proveru znanja

P: Zašto morate ručno pokrenuti ipconfig /release i /renew (ili ekvivalent) da biste snimili DORA proces u laboratorijskoj vežbi, umesto da samo pokrenete Wireshark na već aktivnom klijentu? O: DORA proces se dešava samo kada klijent traži novu IP adresu — ako klijent već ima važeću, aktivnu adresu, neće ponovo pokretati ceo proces dok se lease ne oslobodi/istekne ili se eksplicitno ne zatraži obnavljanje.

Tema 9 – TCP three-way handshake

1. Jednostavno objašnjenje

Pre nego što bilo koja stvarna TCP komunikacija (HTTP, SSH, itd.) počne, dešavaju se tačno tri paketa koja uspostavljaju vezu — vidljivi u Wireshark-u kao prepoznatljiv obrazac na početku svake TCP konekcije.

2. Stručno objašnjenje

Filter tcp.flags.syn == 1 prikazuje sve pakete koji pokušavaju da uspostave TCP konekciju. Three-way handshake: (1) SYN — klijent šalje paket sa SYN flag-om, predlažući svoj inicijalni sequence number; (2) SYN-ACK — server odgovara sa SYN i ACK flag-ovima istovremeno, potvrđujući klijentov sequence number (+1) i predlažući svoj sopstveni; (3) ACK — klijent potvrđuje serverov sequence number (+1), i konekcija je uspostavljena. U Wireshark Info koloni, ovo se prikazuje čitljivo kao [SYN], [SYN, ACK], [ACK] sa odgovarajućim Seq/Ack brojevima u zagradama. Ovaj obrazac prethodi svakoj TCP-baziranoj komunikaciji — HTTP (Tema 11), HTTPS (Tema 12), SSH (Moduli 7, 18), SMTP, itd.

3. Primer iz svakodnevnog života

Three-way handshake je kao standardan protokol pre početka telefonskog poziva: „Halo, čujete li me?" (SYN), „Da, čujem vas, čujete li vi mene?" (SYN-ACK), „Da, čujem" (ACK) — tek nakon ove kratke potvrde oba smera veze, stvarni razgovor (podaci) počinje.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje zašto se veb aplikacija „zamrzava" pri povezivanju filtrira tcp.flags.syn == 1 i primećuje da klijent šalje SYN paket, ali nikad ne stiže SYN-ACK odgovor — jasno izolujući problem na mrežnu dostupnost ili firewall (Modul 16) blokadu servera, ne na samu aplikaciju koja se možda čak ni ne pokreće.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, snimićete saobraćaj tokom pristupa veb serveru (iz Modula 18 laboratorijske vežbe) i identifikovati tačan SYN/SYN-ACK/ACK niz pre prvog HTTP GET zahteva (Tema 11).

6. Najčešće greške

  • Zaboravljanje da nedostatak SYN-ACK odgovora (samo ponovljeni SYN paketi od klijenta) ukazuje na potpunu nedostupnost servera/porta (npr. firewall blokada), ne na „spor" server koji bi ipak na kraju odgovorio.
  • Mešanje redosleda SYN/SYN-ACK/ACK — sva tri paketa imaju specifičnu, nepromenljivu ulogu i redosled u handshake-u.

7. Pitanje za proveru znanja

P: Šta obično znači kada se u snimku vidi ponovljeni SYN paket od klijenta ka istom serveru, bez ijednog SYN-ACK odgovora? O: Server (ili nešto na putu, npr. firewall) ne odgovara na pokušaj konekcije — port je verovatno zatvoren, blokiran, ili server nije dostupan, uzrokujući da klijent ponovo šalje SYN pakete očekujući odgovor koji ne stiže.

Tema 10 – TCP retransmisija

1. Jednostavno objašnjenje

Kada TCP paket ne stigne na odredište (ili potvrda o prijemu ne stigne nazad), pošiljalac ga ponovo šalje — ova ponovljena slanja su vidljiva u Wireshark-u i često direktan znak problema na mreži.

2. Stručno objašnjenje

TCP garantuje pouzdanu isporuku (Modul 2) — ako pošiljalac ne primi ACK potvrdu u očekivanom vremenskom roku, retransmituje (ponovo šalje) taj segment. Wireshark automatski prepoznaje i posebno označava (crno-crvenom bojom u Packet List-u, i eksplicitnom napomenom u Info koloni) pakete klasifikovane kao [TCP Retransmission], [TCP Dup ACK], ili [TCP Out-Of-Order]. Filter tcp.analysis.retransmission izoluje sve retransmisije u snimku. Česti uzroci retransmisija: gubitak paketa (packet loss, Modul 15) na mreži, preopterećenje (zagušenje) linka ili uređaja, i visoka latencija koja izaziva da pošiljalac „misli" da je paket izgubljen pre nego što potvrda uopšte stigne nazad (lažna retransmisija). Veliki broj retransmisija u snimku je jedan od najpouzdanijih indikatora problema sa mrežnim kvalitetom (dopunjuje koncepte latencije/jitter/packet loss iz Modula 15).

3. Primer iz svakodnevnog života

TCP retransmisija je kao ponovno slanje pisma kada niste dobili potvrdu o prijemu u očekivanom roku — možda je originalno pismo izgubljeno usput, možda je potvrda o prijemu izgubljena na povratku, ili ste jednostavno bili nestrpljivi i pismo je zapravo stiglo, samo je potvrda kasnila.

4. Primer iz poslovnog IT okruženja

QA inženjer koji istražuje zašto je prenos velikog fajla neočekivano spor snima saobraćaj i filtrira tcp.analysis.retransmission — otkriva desetine retransmisija tokom prenosa, potvrđujući da uzrok sporosti nije sama aplikacija, već gubitak paketa negde na putanji (potencijalno WAN link iz Modula 15, ili preopterećen uređaj na putu).

5. Praktična vežba / napomena

Ako ste u laboratorijskoj vežbi Modula 18 koristili tc netem da simulirate gubitak paketa na Ubuntu Server-u, snimite saobraćaj tokom SCP prenosa fajla dok je ta simulacija aktivna i primenite tcp.analysis.retransmission da vidite direktnu posledicu tog gubitka.

6. Najčešće greške

  • Tumačenje svake pojedinačne retransmisije kao ozbiljnog problema — povremena retransmisija je normalna pojava čak i na zdravoj mreži; veliki broj retransmisija tokom kratkog perioda je pravi signal za uzbunu.
  • Mešanje [TCP Retransmission] sa [TCP Dup ACK] — potonje znači da je primalac dobio pakete van redosleda i traži ponovno slanje konkretnog nedostajućeg segmenta, blisko povezan, ali tehnički drugačiji signal.

7. Pitanje za proveru znanja

P: Navedite dva tipična uzroka TCP retransmisije. O: Gubitak paketa na mreži (packet loss) i preopterećenje/zagušenje linka ili uređaja na putu (takođe: visoka latencija koja izaziva prevremenu, „lažnu" retransmisiju).

Tema 11 – Analiza HTTP saobraćaja

1. Jednostavno objašnjenje

HTTP saobraćaj putuje neenkriptovan, u čistom tekstu — Wireshark može doslovno da prikaže tačan sadržaj zahteva i odgovora, uključujući bilo kakve podatke poslate preko njega.

2. Stručno objašnjenje

Filter http izoluje HTTP saobraćaj (Modul 2). Wireshark prikazuje GET/POST zahteve (sa putanjom, header-ima poput Host, User-Agent) i odgovore (status kod poput 200 OK ili 404 Not Found, Content-Type, sadržaj). Desni klik na HTTP paket → Follow → HTTP Stream rekonstruiše kompletnu razmenu (zahtev i odgovor) u čitljivom formatu, uključujući celokupan HTML/tekst sadržaj koji je prenet — direktna demonstracija zašto je HTTP (bez TLS-a) nebezbedan za bilo kakve osetljive podatke (lozinke, lične podatke), jer bi svako ko presretne saobraćaj mogao doslovno da ih pročita na isti način na koji ih Wireshark ovde prikazuje.

3. Primer iz svakodnevnog života

HTTP saobraćaj je kao razglednica poslata poštom — svako ko je fizički rukuje (poštar, bilo ko na putu) može pročitati kompletan sadržaj, jer ništa nije zapečaćeno niti skriveno.

4. Primer iz poslovnog IT okruženja

Bezbednosni tim koji sprovodi internu edukaciju o rizicima HTTP-a snima saobraćaj tokom namernog pristupa staroj, internoj HTTP (ne HTTPS) aplikaciji i koristi Follow HTTP Stream da zaposlenima doslovno pokaže svoje sopstvene, ranije unete podatke u čitljivom tekstu — snažna, direktna demonstracija zašto je migracija na HTTPS prioritet.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, pristupićete veb serveru iz Modula 18 preko običnog HTTP-a, snimiti saobraćaj, i koristiti Follow HTTP Stream da vidite kompletan zahtev i HTML odgovor u čitljivom obliku.

6. Najčešće greške

  • Iznenađenje što se lozinke/podaci uneti preko HTTP formulara vide u čistom tekstu — ovo je upravo očekivano, suštinsko ograničenje neenkriptovanog protokola, ne greška u Wireshark-u.
  • Zaboravljanje da HTTP zahtev/odgovor par može biti razbacan preko više TCP segmenata (Tema 9-10) u Packet List-u — Follow HTTP Stream automatski sastavlja kompletnu poruku iz svih relevantnih segmenata.

7. Pitanje za proveru znanja

P: Zašto Wireshark može doslovno da prikaže sadržaj HTTP zahteva/odgovora (uključujući eventualne lozinke), dok to nije moguće za HTTPS saobraćaj (Tema 12)? O: HTTP prenosi podatke neenkriptovano, u čistom tekstu — Wireshark (kao i bilo ko drugi ko presretne saobraćaj) može direktno pročitati sadržaj. HTTPS enkriptuje sadržaj preko TLS-a, čineći ga nečitljivim bez odgovarajućeg ključa za dekriptovanje.

Tema 12 – Analiza HTTPS saobraćaja i TLS handshake

1. Jednostavno objašnjenje

HTTPS saobraćaj je enkriptovan, pa Wireshark ne može da pročita stvarni sadržaj — ali proces uspostavljanja te enkriptovane veze (TLS handshake) i dalje je vidljiv, i sadrži korisne informacije.

2. Stručno objašnjenje

Filter tls (ili istorijski ssl) izoluje TLS saobraćaj. Nakon TCP three-way handshake-a (Tema 9), TLS handshake sledi: Client Hello (klijent predlaže podržane verzije TLS-a i enkripcijske algoritme, i ključno — šalje SNI, Server Name Indication u čistom tekstu, otkrivajući koje ime domena klijent pokušava da dosegne, čak i pre enkripcije); Server Hello (server bira algoritam i vraća svoj sertifikat); razmena ključeva; i konačno enkriptovana Application Data — od tog trenutka nadalje, Wireshark vidi samo nečitljive, enkriptovane bajtove, bez obzira na to koliko puta pokušate Follow TLS Stream. Ključna praktična posledica: metapodaci (koji server, kada, koliko podataka) ostaju vidljivi čak i preko HTTPS-a, dok sadržaj ostaje zaštićen.

3. Primer iz svakodnevnog života

TLS handshake je kao gledanje dvoje ljudi koji se dogovaraju o tajnom kodu pre nego što počnu razgovor (vidljivo da razgovaraju, o čemu se dogovaraju oko koda, čak i koje ime jedan izgovori drugom pre početka), ali nakon toga ceo razgovor prelazi na taj tajni kod koji vi ne razumete — vidite da razgovor traje i koliko dugo, ali ne i sadržaj.

4. Primer iz poslovnog IT okruženja

Bezbednosni tim koji analizira mrežni saobraćaj radi otkrivanja potencijalno kompromitovanog uređaja ne može da pročita sadržaj HTTPS konekcija ka sumnjivim serverima, ali i dalje može da vidi SNI polje u Client Hello paketima — otkrivajući tačno koja imena domena je uređaj pokušavao da dosegne, što je često dovoljno da se identifikuje komunikacija sa poznatim zlonamernim serverom, bez potrebe da se ikada dekriptuje stvarni sadržaj.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, posetićete bilo koji HTTPS sajt, snimiti saobraćaj, primeniti filter tls.handshake.type == 1 (Client Hello), i pronaći SNI polje koje otkriva ime sajta koji ste posetili — zatim pokušajte Follow TLS Stream na narednim paketima i uporedite (nečitljiv) rezultat sa čitljivim HTTP primerom iz Teme 11.

6. Najčešće greške

  • Pretpostavka da HTTPS u potpunosti skriva sve informacije o komunikaciji — SNI, veličina i vreme paketa, i IP adrese oba kraja i dalje ostaju vidljivi metapodaci.
  • Pokušaj da se „dekriptuje" TLS saobraćaj bez privatnog ključa servera (ili unapred deljenih session ključeva) — bez toga, sadržaj ostaje trajno nečitljiv u Wireshark-u, po dizajnu TLS protokola.

7. Pitanje za proveru znanja

P: Koja informacija ostaje vidljiva u čistom tekstu čak i u TLS Client Hello paketu, pre nego što enkripcija stvarno počne? O: SNI (Server Name Indication) — ime domena koje klijent pokušava da dosegne, neophodno serveru da zna koji sertifikat/sajt da ponudi pre nego što je enkriptovani kanal uspostavljen.

Tema 13 – Follow TCP Stream

1. Jednostavno objašnjenje

Follow TCP Stream uzima sve pojedinačne pakete jedne konekcije i sastavlja ih u jedan čitljiv „razgovor" između klijenta i servera, umesto da se ručno prelistava paket po paket.

2. Stručno objašnjenje

Desni klik na bilo koji TCP paket → Follow → TCP Stream filtrira sve pakete te konkretne konekcije (identifikovane kombinacijom izvorišne/odredišne IP adrese i porta, Modul 2) i prikazuje ih kao jedinstven, hronološki tok podataka, sa bojnim razlikovanjem smera (tipično crveno za jedan smer, plavo za drugi) — mnogo lakše za razumevanje toka razgovora nego ručno prelistavanje desetina pojedinačnih paketa u Packet List-u. Ovo je generalizacija koncepta specifičnog za HTTP (Tema 11) na bilo koji TCP protokol — radi identično za SSH (Modul 7, 18, iako je sadržaj enkriptovan i nečitljiv, isti princip kao TLS iz Teme 12), SMTP, FTP, ili bilo koji drugi TCP-bazirani protokol.

3. Primer iz svakodnevnog života

Follow TCP Stream je kao transkript celog telefonskog razgovora sastavljen iz pojedinačnih, vremenski razbacanih zvučnih isečaka — umesto da slušate isečke jedan po jedan i sami pokušavate da sklopite ko je šta rekao i kada, dobijate već sastavljen, hronološki uređen transkript.

4. Primer iz poslovnog IT okruženja

Administrator koji dijagnostikuje neuobičajeno ponašanje starije, internom mrežnom protokolu bazirane aplikacije (bez gotove Wireshark podrške za taj specifičan protokol) koristi generičku Follow TCP Stream funkciju da rekonstruiše celokupnu razmenu bajtova, ručno tumačeći strukturu poruka na osnovu poznavanja protokola, kada specijalizovan display filter za taj protokol ne postoji.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, primenite Follow TCP Stream i na HTTP konekciju (Tema 11, čitljivo) i na SSH konekciju (ako je snimljena, Moduli 7/18) ka istom serveru — uporedite čitljivost sadržaja u oba slučaja.

6. Najčešće greške

  • Pokušaj korišćenja Follow TCP Stream na UDP saobraćaju (npr. DNS, DHCP) — funkcija je specifična za TCP; za UDP postoji odvojena „Follow UDP Stream" opcija sa sličnim principom.
  • Zaboravljanje da Follow TCP Stream prikazuje sirov sadržaj konekcije — za enkriptovane protokole (TLS, SSH), i dalje ćete videti samo nečitljive, enkriptovane bajtove, ne stvarnu poruku.

7. Pitanje za proveru znanja

P: Šta Follow TCP Stream radi drugačije od običnog pregleda pojedinačnih paketa u Packet List-u? O: Filtrira i sastavlja sve pakete jedne konkretne TCP konekcije u jedinstven, hronološki uređen prikaz sa vizuelnim razlikovanjem smera komunikacije, umesto da administrator ručno prelistava i mentalno sklapa desetine pojedinačnih paketa.

Tema 14 – Statistics meni (Conversations, I/O Graph)

1. Jednostavno objašnjenje

Statistics meni daje pregled saobraćaja „iz vazduha" — ko je sa kim komunicirao i koliko, ili kako se ukupan obim saobraćaja menjao tokom vremena — umesto pregleda paket po paket.

2. Stručno objašnjenje

Statistics → Conversations prikazuje agregiran pregled svih parova komunikacije (po IP adresi, ili po TCP/UDP konekciji), sa ukupnim brojem paketa i bajtova razmenjenih u svakom pravcu — koristan za brzo identifikovanje koji uređaj ili konekcija generiše najviše saobraćaja, bez ručnog prebrojavanja pojedinačnih paketa. Statistics → I/O Graph prikazuje grafikon obima saobraćaja (paketi ili bajtovi u sekundi) tokom vremena — koristan za vizuelno identifikovanje kada je došlo do naglog skoka ili pada u saobraćaju, što se zatim može upariti sa specifičnim vremenskim opsegom za detaljniju analizu paket po paket.

3. Primer iz svakodnevnog života

Conversations je kao sažet spisak „ko je sa kim najviše telefonirao ovog meseca i koliko dugo" umesto slušanja svakog pojedinačnog poziva. I/O Graph je kao grafikon ukupne telefonske aktivnosti tokom dana — brzo pokazuje kada je bilo „najprometnije" bez potrebe da se pregleda svaki pojedinačan poziv.

4. Primer iz poslovnog IT okruženja

Administrator koji istražuje zašto je mreža bila „spora" tačno u 14:32 prethodnog dana (na osnovu prijave korisnika) prvo koristi I/O Graph da vizuelno pronađe taj tačan trenutak u dugom, višesatnom snimku, zatim primenjuje display filter (Tema 4) ograničen na taj kratak vremenski opseg da detaljno analizira šta se tačno dešavalo paket po paket u tom prozoru.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, otvorite Statistics → Conversations na svom snimku i identifikujte koji par IP adresa je razmenio najviše podataka; zatim otvorite I/O Graph i identifikujte da li postoji vidljiv skok tokom faze prenosa velikog fajla (SCP, Modul 18).

6. Najčešće greške

  • Oslanjanje isključivo na Conversations/I/O Graph bez ikad „silaska" na nivo pojedinačnih paketa — agregirani pregled pokazuje da postoji anomalija, ali retko objašnjava zašto; za pravi uzrok potrebna je dublja analiza (Teme 9-10).
  • Zaboravljanje da I/O Graph podrazumevano prikazuje sav saobraćaj u snimku — za fokusiranu analizu, korisno je prvo primeniti display filter (Tema 4), pa tek onda otvoriti I/O Graph koji poštuje trenutno primenjen filter.

7. Pitanje za proveru znanja

P: Kako biste kombinovali I/O Graph i display filtere da efikasno pronađete uzrok kratkotrajnog problema u dugom, višesatnom snimku? O: Prvo koristite I/O Graph da vizuelno identifikujete tačan vremenski period kada je došlo do anomalije (skoka/pada saobraćaja), zatim primenite display filter fokusiran na taj uski vremenski opseg (i eventualno konkretne uređaje/protokole) da detaljno analizirate pakete iz tog perioda, umesto da ručno pretražujete ceo, dugačak snimak.

Tema 15 – Sistematska dijagnostika uzroka sporog rada

1. Jednostavno objašnjenje

Kombinacija svega naučenog u ovom modulu čini sistematski pristup pronalaženju zašto je nešto sporo — od širokog pregleda, preko sužavanja na sumnjiv period, do konkretnog uzroka na nivou pojedinačnih paketa.

2. Stručno objašnjenje

Sistematski redosled dijagnostike sporog rada koristeći Wireshark: (1) Statistics → I/O Graph (Tema 14) — identifikovati da li postoji vidljiv pad protoka ili neuobičajen obrazac tokom perioda spornog rada; (2) tcp.analysis.retransmission (Tema 10) — proveriti da li postoji značajan broj retransmisija, ukazujući na gubitak paketa/zagušenje; (3) dns (Tema 7) — proveriti da li DNS rezolucija neočekivano dugo traje pre prve TCP konekcije; (4) tcp.flags.syn == 1 (Tema 9) — proveriti da li TCP handshake uopšte uspeva brzo, ili se ponavlja bez odgovora; (5) Follow TCP/HTTP Stream (Teme 11, 13) — pregledati stvarni sadržaj razmene za znakove sporih odgovora aplikacije same po sebi (za razliku od mrežnog problema). Ovaj redosled kombinuje agregiranu (Statistics) i detaljnu (display filteri, Follow Stream) analizu, dopunjujući CLI-bazirane dijagnostičke pristupe iz Modula 17-18 vizuelnim, paket-po-paket uvidom koji CLI alati sami po sebi ne pružaju.

3. Primer iz svakodnevnog života

Sistematska Wireshark dijagnostika je kao istraga saobraćajne gužve — prvo pogledate širu sliku (kamere sa satelita, I/O Graph) da vidite gde je gužva najgušća, zatim proverite da li ima nezgoda (retransmisije) na tom mestu, zatim proverite da li semafori (DNS/handshake) uopšte rade ispravno, i na kraju, ako ništa od toga ne objašnjava problem, proveravate da li je sam izvor gužve nešto sporo unutar jednog vozila (aplikacija).

4. Primer iz poslovnog IT okruženja

Tim koji dijagnostikuje žalbe korisnika na „spor" interni portal prati tačno ovaj redosled: I/O Graph ne pokazuje ništa neobično (isključuje mrežno zagušenje kao glavni uzrok), tcp.analysis.retransmission pokazuje samo par retransmisija (normalno, ne problem), dns pokazuje brzu rezoluciju, TCP handshake je brz — ali Follow HTTP Stream otkriva da server sam treba nekoliko sekundi da generiše odgovor pre slanja bilo kakvih podataka, izolujući problem konačno na aplikaciju/bazu podataka na serveru, ne na mrežu.

5. Praktična vežba / napomena

U laboratorijskoj vežbi ovog modula, provežbaćete kompletan redosled na snimku koji uključuje namerno unetu simulaciju gubitka paketa (preko tc netem iz Modula 18), potvrđujući svaki korak dijagnostičkog procesa na stvarnom primeru.

6. Najčešće greške

  • Preskakanje širokog pregleda (Statistics) i direktan „ronilan" u pojedinačne pakete bez ikakvog vodiča gde tačno tražiti problem u dugom snimku.
  • Zaustavljanje dijagnostike čim se pronađe bilo kakva retransmisija ili anomalija, bez provere da li je njihov broj/učestalost zaista značajna u odnosu na ukupan obim saobraćaja — vodi ka pogrešnim zaključcima o uzroku.

7. Pitanje za proveru znanja

P: Zašto sistematska dijagnostika sporog rada počinje širokim, agregiranim pregledom (Statistics), umesto direktnim pregledom pojedinačnih paketa? O: U dugom snimku sa hiljadama paketa, ručno pregledanje svakog pojedinačnog paketa bez vodiča je neefikasno — agregirani pregled (I/O Graph, Conversations) brzo usmerava pažnju na koji vremenski period ili koji par uređaja je verovatno vezan za problem, nakon čega se detaljna analiza (display filteri, Follow Stream) fokusira samo na taj relevantan deo snimka.

Rezime modula

  • Wireshark zahteva Npcap/libpcap za stvarno snimanje; izbor ispravnog interfejsa je ključan preduslov, uz razumevanje ograničenja promiscuous mode-a na svič-baziranim mrežama.
  • Capture filteri (BPF sintaksa) ograničavaju šta se snima, primenjeni pre snimanja i ne mogu se retroaktivno menjati; display filteri kontrolišu šta se prikazuje iz već snimljenog, i mogu se slobodno menjati.
  • ARP, ICMP, DNS i DHCP saobraćaj u Wireshark-u vizuelno potvrđuju teorijske koncepte iz ranijih modula (2, 13) — vidljivi kao stvarni parovi zahtev/odgovor sa tačnim poljima.
  • TCP three-way handshake (SYN, SYN-ACK, ACK) prethodi svakoj TCP komunikaciji; retransmisije (tcp.analysis.retransmission) su pouzdan indikator problema sa mrežnim kvalitetom.
  • HTTP saobraćaj je čitljiv u potpunosti preko Follow HTTP Stream; HTTPS/TLS enkriptuje sadržaj, ali SNI i metapodaci ostaju vidljivi u Client Hello fazi.
  • Follow TCP Stream generalizuje princip čitljive rekonstrukcije razgovora na bilo koji TCP protokol; Statistics meni (Conversations, I/O Graph) pruža agregiran pregled saobraćaja.
  • Sistematska dijagnostika sporog rada kombinuje širok pregled (Statistics) sa detaljnom analizom (retransmisije, DNS, handshake, Follow Stream) da precizno izoluje uzrok problema.

Mermaid dijagram

graph TD
    A["1. Statistics -> I/O Graph<br/>(širok pregled)"] --> B["2. tcp.analysis.retransmission<br/>(gubitak paketa?)"]
    B --> C["3. dns filter<br/>(spora rezolucija?)"]
    C --> D["4. tcp.flags.syn==1<br/>(handshake uspeva?)"]
    D --> E["5. Follow TCP/HTTP Stream<br/>(spor odgovor aplikacije?)"]

Dodatni izvori (opciono)

  • Wireshark User's Guide (wireshark.org)
  • RFC 793 – Transmission Control Protocol
  • RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3