Praktični primeri – Modul 19 – Wireshark i analiza mrežnog saobraćaja

Ovaj dokument sadrži pet detaljno rešenih praktičnih primera i jedan integrativan poslovni scenario.

Primer 1 – Capture filter za ograničeno snimanje

Situacija: Potrebno je snimiti isključivo saobraćaj vezan za Ubuntu Server VM (192.168.56.20) iz Modula 18, izbegavajući snimanje ostatka mrežnog saobraćaja na istom interfejsu.

Capture filter:

host 192.168.56.20

Objašnjenje: Ovaj filter se unosi pre klika na „Start capture" (Tema 3) — Wireshark će snimati isključivo pakete gde je 192.168.56.20 izvorišna ili odredišna adresa, ignorišući sav ostali saobraćaj na tom interfejsu (npr. saobraćaj vašeg host računara ka internetu koji nema veze sa laboratorijskom vežbom).

Primer 2 – Display filter kombinacija za HTTPS ka konkretnom serveru

Situacija: Nakon snimanja saobraćaja bez capture filtera, potrebno je izolovati isključivo HTTPS saobraćaj ka serveru 93.184.216.34.

Display filter:

tls && ip.addr == 93.184.216.34

Objašnjenje: tls (Tema 12) izoluje TLS/HTTPS saobraćaj; ip.addr == 93.184.216.34 (Tema 4) dodatno filtrira na konkretnu adresu (u oba smera, izvor ili odredište). Operator && (logičko I) zahteva da oba uslova budu ispunjena istovremeno — rezultat je znatno uži, precizniji prikaz nego bilo koji od filtera pojedinačno.

Primer 3 – Identifikacija problema preko TCP handshake analize

Situacija: Klijent se žali da ne može da se poveže na interni server na portu 8080. Snimljen je saobraćaj tokom pokušaja.

Display filter:

tcp.port == 8080

Uočeno u snimku:

Klijent → Server: [SYN] Seq=0
Klijent → Server: [SYN] Seq=0  (retransmisija nakon 1s)
Klijent → Server: [SYN] Seq=0  (retransmisija nakon 2s)

Objašnjenje: Snimak pokazuje da klijent ponavlja SYN paket (Tema 9) bez ijednog SYN-ACK odgovora od servera. Ovo definitivno isključuje mogućnost da je problem u samoj aplikaciji (koja bi morala prvo da uspešno prihvati TCP konekciju pre bilo kakve greške na višem nivou) — problem je ili u tome da servis uopšte ne sluša na portu 8080, ili da firewall (Modul 16) na putu blokira SYN pakete pre nego što stignu do servera.

Primer 4 – Prepoznavanje retransmisija tokom sporog prenosa fajla

Situacija: SCP prenos velikog fajla ka Ubuntu Server-u (Modul 18) traje mnogo duže nego što bi trebalo za tu veličinu fajla i brzinu veze.

Display filter:

tcp.analysis.retransmission

Uočeno u snimku: 47 paketa označenih kao [TCP Retransmission] tokom prenosa od ukupno 2.400 paketa.

Objašnjenje: Odnos od 47 retransmisija na 2.400 paketa (skoro 2%) je znatno iznad onoga što bi se očekivalo na zdravoj lokalnoj mreži (obično ispod 0.1%) — ovo potvrđuje da spor prenos nije uzrokovan aplikacijom (SCP/SSH) samom po sebi, već gubitkom paketa negde na putanji (Tema 10, Modul 15 koncept packet loss-a), zahtevajući dalju istragu same mrežne infrastrukture (npr. VirtualBox mrežno podešavanje, ili namerno uvedeno kašnjenje preko tc netem iz Modula 18).

Primer 5 – SNI otkriva ime sajta i pored HTTPS enkripcije

Situacija: Bezbednosni tim želi da utvrdi koje sajtove je posetio uređaj tokom sumnjivog perioda, bez mogućnosti dekriptovanja HTTPS saobraćaja.

Display filter:

tls.handshake.type == 1

Uočeno u snimku:

Client Hello ... Server Name: firma-portal.rs
Client Hello ... Server Name: analytics.sumnjiv-domen.com

Objašnjenje: Filter tls.handshake.type == 1 (Tema 12) izoluje samo Client Hello pakete, u kojima SNI polje otkriva ime domena u čistom tekstu, pre nego što je enkripcija uspostavljena. Ovo omogućava bezbednosnom timu da identifikuje da je uređaj komunicirao sa sumnjivim domenom, bez ikakve potrebe da dekriptuje stvarni sadržaj te komunikacije — metapodaci (koji sajt, kada) ostaju vidljivi čak i kada je sadržaj potpuno zaštićen.

Poslovni scenario – Dijagnostika sporog internog portala

Kontekst: Zaposleni u firmi „Meridian Logistika" prijavljuju da je interni veb portal (hostovan na Ubuntu Server-u iz Modula 18) postao neuobičajeno spor tokom poslednje nedelje, iako sam server „izgleda" normalno opterećen.

Sistematska dijagnostika (Tema 15):

Zaključak: Dijagnostika je sistematski isključila mrežu (Koraci 1-4) kao uzrok, izolujući problem tačno na serversku aplikaciju (verovatno spor upit ka bazi podataka ili neefikasan kod koji generiše stranicu) — problem koji zahteva angažovanje razvojnog tima, ne mrežnog administratora, jer se veza uspostavlja i podaci prenose potpuno normalno; samo generisanje odgovora na serveru traje predugo.

Zašto ovakav redosled: Prateći sistematski princip iz Teme 15, tim je izbegao pogrešno trošenje vremena na mrežnu infrastrukturu (koja se pokazala potpuno ispravnom) i direktno usmerio dalju istragu ka pravom uzroku — jasna demonstracija vrednosti Wireshark analize kao alata koji razdvaja „mrežni" od „aplikativnog" problema, umesto nagađanja.