# De eerste capture analyseren

## Voorbereiding

We gaan een simpele eerste capture doen van het bezoek van een webpagina. Eerst zien we wat er allemaal mogelijk is en waar we rekening moeten mee houden bij het bekijken van een capture om vervolgens wat dieper op de capture zelf in te gaan.

Gelieve dus de volgende stappen mee te volgen om zo al een eerste keer te oefenen met *Wireshark*

Voer eerst de volgende commands uit op de commandline:

```
ipconfig/flushdns
arp -d
```

Start je *Wireshark* capture

Bezoek nu de website: <http://www.bob.be> en stop de capture nadat de website ingeladen is, bewaar deze dan ook al voor de zekerheid. *CTRL + S* of *File* en vervolgens *save as* .

De capture informatie die we nu hebben zal van vele factoren afhangen, zoals bv:

* Waar is er gecapteerd in het netwerk?
* Welke browser gebruiken we?

## De factoren

### Waar is er gecaptured geweest?

In dit geval kennen we de locatie van waar er gecaptured is. Maar hoe kunnen we dat nog achterhalen? Voor die momenten dat er een capture door een collega gebeurd is of je de capture enkele weken later herbekijkt.

Door het IP te resolven kan ik al zien dat mijn client de telenet DNS servers heeft aangesproken. ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFb5byp1kh-1KvFS%2Fdns-resolve.PNG?generation=1568801886520934\&alt=media)

Door naar het Mac-adres te kijken kan ik zien dat het gesprek zich afspeelt tussen een *Intel \_NIC en een \_CompaLbr* .

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFb7WMI1FHSDlfq4%2Fmacresolve.PNG?generation=1568801886537718\&alt=media)

Een beetje zoekwerk en we komen uit op een firma die netwerkapparatuur maakt en oa de Docsis-modems die Telenet ook gebruikt: <http://www.icbn.com.tw/category1s/category1_small_lists_en/category2_id:3>

De TTL (Time To Live) verklapt ons ook al dat de capture gemaakt is op de client machine en niet op de server. Vermits de TTL 128 is, moet deze capture wel gebeurt zijn op het LAN-segment waar het packet begon.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFb9dBi3zPZ9WfZ8%2FTTL-ip.PNG?generation=1568801886527059\&alt=media)

Voor een overzicht van gekende TTL's van Operating Systems: <http://subinsb.com/default-device-ttl-values> .

Al deze bovenstaande informatie moet samen geëvalueerd worden, enkel aan de hand van de TTL kan je natuurlijk niet per sé alles zien. Tenzij je de TTL bekijkt van een Syn-packet, dan kan je al haast zeker zijn dat je goed zit.

### Welke browser gebruiken we?

Mijn computer zit tsjokvol software die zichzelf updaten wanneer ze de kans hebben of voor andere doeleinden netwerkverbindingen leggen. Als je eigen computer teveel ruis veroorzaakt, zal dat het capteren van data wat ingewikkelder maken.

Bijvoorbeeld: Hieronder het verschil tussen chrome en firefox.

Chrome is in dit geval uitgerust met tal van plugins en heeft toegang tot een door-en-voor google speciaal ontwikkeld protocol, QUIC, dat in werking treed zodra je Chrome begint te gebruiken. <https://www.chromium.org/quic> . ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbBoQMOJ59KUT1h%2Fchrome-capture.PNG?generation=1568801886572625\&alt=media)

Deze Firefox is een verse installatie zonder addons of andere toevoegingen. Het verschil is meteen merkbaar: het binnenhalen van [www.bob.be](http://www.bob.be) is zo goed als één van de eerste packetten die Wireshark toont (na de dns query van het domein) ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbD1mTlyEtVcuBD%2Ffirefox-capture.PNG?generation=1568801886600942\&alt=media)

## De datastroom bekijken

### Display filters

Er passeert veel ruis aan onze netwerkkaart, dus zullen we van onze *display filters* moeten gebruikmaken om snel de juiste data tevoorschijn te toveren.

*Display filters* kunnen altijd aangepast worden naar wens en de mogelijkheden zijn legio.

Maar welke filter zouden we gebruiken als we onze traffiek tussen onze computer en de website [www.bob.be](http://www.bob.be) willen analyseren?

We zouden kunnen filteren op het http protocol

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbFYc5PNBmNkHSV%2Fhttpfilter.PNG?generation=1568801886542254\&alt=media)

Of op tcp poort 80

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbHRGMP-vJ7zDwB%2Fport80.PNG?generation=1568801886528149\&alt=media)

Of op destination port 80

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbJYvKXu2w2FWZQ%2Fdestporteq80.PNG?generation=1568801886571810\&alt=media)

Een iets alternatieve schrijfwijze voor destination port 80

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbLF2q74zBHiJhW%2Fdestport80.PNG?generation=1568801886545890\&alt=media)

Ik wacht wel even tot je ze zelf allemaal hebt geprobeerd.

...

...

...

Ok, dat gaf verschillende resultaten weer, niet waar?

* Filteren op enkel http geeft ons enkel de data van de website, zonder onze tcp-packetten met onze handshake en acks.
* Filteren op poort 80 geeft ons wel al die informatie.
* De alternatieve schrijfwijze geeft ons gewoon hetzelfde als het vorig punt.

### Met wat moeten we dan filteren?

De algemene tcp poort 80 filter is niet slecht en snel gemaakt, maar geeft ons ook potentieel informatie over andere connecties, dus meer ruis.

Bij twijfel kan je altijd zoeken naar het begin van de conversatie tussen 2 pc's. De TCP- handshake is daarvoor de uitgelezen plek of misschien de http GET-request ? Probeer het zelf.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbNPr3G63oG-uT6%2Ffollow-tcp-stream.PNG?generation=1568801886592755\&alt=media) Vervolgens krijg je een venster met iets soortgelijks te zien: ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbP6Ufo6JXgAVWZ%2Ffollow-tcp-resultaat.PNG?generation=1568801886743524\&alt=media) Je kan gewoon op *close* klikken en voila, *Wireshark* heeft zelf een filter aangemaakt. ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbRrH8JUtVPw3bQ%2Ffollowtcpstream.PNG?generation=1568801886601515\&alt=media)

Deze filter is uniek aan de trace, dus die kan je niet zomaar overnemenin andere traces.

Hiermee hebben we dan eindelijk onze filter die we nodig hebben... of toch niet?

### Helaas, het filteren is nog niet gedaan

Het lijkt erop dat we alles hebben kunnen filteren van ons bezoek aan de website, maar niets is minder waar. De optie *conversations* zal dat snel duidelijk maken.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbTHBy_RmTjbhqg%2FConversations.PNG?generation=1568801886559034\&alt=media)

Er zijn meerdere tcp-conversaties

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbVaj_VS-UPwcwr%2Fconversations-tcp.PNG?generation=1568801886607274\&alt=media)

Ofwel gaan we dus alle tcp streams moeten achterhalen en een filter maken met met de operator "or"

`tcp.stream eq 1 or tcp.stream eq 2 or tcp.stream eq 3`

of we houden het simpelweg op een filter gebaseerd op source en destination IP-adres. Zoals in het voorbeeld hieronder.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbX6W1-fLDpHxuQ%2Fip-filter.PNG?generation=1568801886590656\&alt=media)

`ip.addr eq 192.168.0.196 and ip.addr eq 86.39.65.24`

### Display filter "oeps"

We hadden ook kunnen filteren op bijvoorbeeld destination IP-adres (zelfde resultaat als destination tcp port 80) maar die lijkt niet te werken? ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbZEfzIQiKq2DOz%2Fdestipaddress.PNG?generation=1568801886557671\&alt=media) Of toch wel! ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbao-03x2MOnxnp%2Fipdestionationdns.PNG?generation=1568801886563157\&alt=media)

Eenmaal de *name resolution* functie is ingeschakeld, kan je blijkbaar niet altijd meer IP-adres gebruiken, maar moet je de hostname gebruiken in combinatie met *ip.dst\_host*.

## Visuele hulp

Sinds een van hun 2.x versies hebben de Wireshark ontwikkelaars een aantal visuele hulpmiddelen toegevoegd aan hun programma. Kleine onopvallende zaken die een schat aan informatie bevatten

### De No. kolom

Deze kolom bevat niet enkel het nummer van een frame, maar ook een aantal markeringen waar je snel kan overkijken. Zo zal bij het selecteren van een *TCP 3-way handshake*, Wireshark je aanduiden tot waar deze sessie loopt.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbcjyDp-PRQ71Rm%2Finfo-kolom.PNG?generation=1568801886560741\&alt=media)

Dat is niet alles, zoek in je trace waar je een *GET / HTTP/1.1 http-packet* hebt.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbep2_5G2T1cp_F%2Finfo-kolom2-1.PNG?generation=1568801886600681\&alt=media)

Hierbij zal Wireshark je zeggen waar, op applicatieniveau, de client en de webserver met elkaar communiceren en antwoorden komen op *GET \_en waar een nieuwe \_GET* start. ![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbgwrefHB1gb-KZ%2Finfo-kolom2.PNG?generation=1568801886604025\&alt=media)

Dat is niet alles, bij een DNS-request zal hij ook aanduiden waar het antwoord op die request is. Bij een snelle verbinding is dat meestal de volgende lijn, zoals in deze foto. Dus dat valt wel mee.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbi_grF0t0YUzlM%2Finfo-kolom3.PNG?generation=1568801886520823\&alt=media)

Bij het opvolgen van ACKs geeft hij ook een visuele markering. In deze screenshot heb ik *frame 24* aangeduid, dat een ACK is op de data van *frame 18*

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbkajdPMr_ItpW0%2Finfo-kolom4.PNG?generation=1568801886663568\&alt=media)

### De scrollbar

Een andere toevoeging is de scrollbar waarop je kan zien waar er zich slechte frames bevinden. Heel handig bij grote capture-bestanden. Als je natuurlijk een zorgeloze capture in je handen hebt, zal je deze markeringen niet hebben.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbmWYF9bttYumIO%2Fscrollbar.PNG?generation=1568801886574982\&alt=media)

Als ik naar de dikke zwarte lijn scroll, kom ik uit bij een aantal zwarte frames, dit zou kunnen duiden op een probleem.

![](https://3625099638-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lp2rB1yW0MPkGBRhu8j%2F-Lp2rE09CJS_2cpP8jY7%2F-Lp2sFbo-rUL5I6upozc%2Fscrollbar2.PNG?generation=1568801886650079\&alt=media)
