Netwerkdata analyseren met TShark
Heb je wel eens in netwerklogbestanden zitten snuffelen zonder dat je wist waar je naar op zoek was? Met Wireshark wordt dat al snel een onoverzichtelijke boel. Je kunt er wel heel goed mee filteren, maar als je grote databestanden hebt, gaat dat allemaal ook erg traag. Dan kan TShark wat voorwerk voor je doen.
TShark is een commandline-tool die bij Wireshark hoort en over dezelfde logmogelijkheden beschikt. Je kunt er netwerklogs (ook wel traces of captures genoemd) net zo gedetailleerd mee filteren als met Wireshark. In tegenstelling tot die laatste GUItool kun je TShark ook aan andere shell-tools koppelen, waardoor het mogelijk wordt de output verder te verwerken. Dat vergemakkelijkt bijvoorbeeld het zoeken naar afwijkend gedrag van een client of helpt om sporadisch voorkomende fouten op te sporen. Securityexperts kunnen er daarnaast ook mee testen of een firewall gevoelig is voor bepaalde aanvallen.
De concepten zijn ook makkelijk privé voor allerlei analyses te gebruiken, bijvoorbeeld om te achterhalen met wie en waarom een smart-tv contact maakt via internet. Met de resultaten daarvan kun je dan, om maar eens wat te noemen, de filterlijsten van Pi-hole aanvullen.
Aan het begin van een analyse is het aan te raden om de informatie die in een trace zit te reduceren tot het meest wezenlijke. Filter er alleen de inhoud van bepaalde pakketvelden uit en zet die in een nieuw bestand. Net als bij Wireshark is de informatie ook met een displayfilter te isoleren, want TShark laat die per regel in de terminal zien. De output kun je met de commando’s sort en uniq sorteren.
VOORWAARDEN
Bij Linux kun je TShark als afzonderlijk element krijgen via het pakketbeheer (voor Debian is dat bijvoorbeeld sudo apt-get install tshark). Windows- en macOS-gebruikers kunnen TShark samen met Wireshark installeren met de installatie-image van de makers. Alle links en installatiebestanden staan bij de link aan het eind van dit artikel.
Windows heeft wel sort, maar uniq ontbreekt. Als je niet sowieso al het Cygwin-pakket gebruikt van Microsofts Linux-subsysteem voor Windows, kun je het installeren daarvan achterwege laten: uniq zit in de nog niet eens 1 MB grote toolverzameling UnxUtils, die je in een handomdraai geïnstalleerd hebt. Een tegenargument tegen de tools van Windows zelf en Microsofts Linuxsubsysteem is overigens ook dat veel back-upprogramma’s dergelijke installaties niet kunnen back-uppen.
De UnxUtils zijn wel voor het laatst in 2003 bijgewerkt. Maar uniq werkt in elk geval nog op Windows tot en met versie 10. Download het archief en pak het uit in de map C:\Program Files. Daarbij hernoem je het bestand sort.exe in die map naar sort2.exe om verwisselingen met het Windows-eigen commando te voorkomen. Het programma TShark staat bij Windows in principe in de map C:\Program Files\Wireshark. Bij macOS staat TShark normaal gesproken in /Applications/MacPorts/Wireshark.app/Contents/MacOS/tshark, bij Linux in /usr/bin.
Om ervoor te zorgen dat je tshark en uniq bij Windows zonder complete padaanduidingen kunt gebruiken, voeg je de bijbehorende mappen toe aan de omgevingsvariabelen van Windows. Typ bij het startmenu de eerste letters in van ‘De omgevingsvariabelen voor uw account bewerken’ en klik daarop. Klik in het deel Gebruikersvariabelen dubbel op het veld Path en voeg daar de beide paden toe met de knoppen Bewerken en Nieuw (zie de afbeelding op de volgende pagina). Als je dan een nieuw CMD-venster opent, moet je TShark kunnen starten zonder dat je het hele pad hoeft te typen.
Op een Mac volstaat het om aan de variabele PATH een submap toe te voegen voor de Wireshark-map. Open daarvoor het bestand ~/.bash_profile met een editor en voeg deze regels toe:
#PATH-variabele voor Wireshark-tools export PATH=$PATH:/Applications/Wireshark.app/ Contents/MacOS/
Onder Linux hoef je geen paden toe te voegen, daar volstaat het intypen van het commando.
WERKEN MET TSHARK
Je kunt TShark aansturen met een handvol commandline-opties. We noemen even kort de meest belangrijke en laten vervolgens zien hoe je die tot complete commando’s kunt samenvoegen en daar andere commando’s aan koppelt.
Net als Wireshark kan TShark het in- en uitgaande netwerkverkeer van je pc loggen. Met de optie -i selecteer je de interface waar je het dataverkeer van wilt loggen en met de optie -w bestandsnaam.pcap bepaal je waar de loggegevens in terecht moeten komen.
Eerdere logsessies kun je met de optie -r bestandsnaam.pcap aan het programma meegeven. Zonder
verdere parameters zal TShark echter niet veel meer doen dan de inhoud van de trace-file over het scherm heen laten zoeven. De van Wireshark bekende displayfilters kun je gebruiken met de optie -Y filterexpressie. Met -Y http.request filter je bijvoorbeeld alle HTTP-requests eruit. Geneste filtertaken kun je toevoegen door ze tussen aanhalingstekens te zetten.
Voor elk gefilterd pakket laat TShark de statusinformatie zien: het doorlopende nummer in de trace, de tijdstempel, source- en destination-IP, poortnummer en extra informatie. Met de optie -T files -e veldnaam
extraheert TShark de content van bepaalde velden.
Om bepaalde toepassingen mogelijk te maken, hebben we een ongeveer 55 MB groot voorbeeldbestand van een smart-tv van LG voorbereid, dat prima geschikt is om mee te oefenen en wat ervaring te krijgen in het werken met TShark. Het bestand kun je vinden via de link aan het eind van dit artikel.
In eerste instantie gaat het erom om de door een smart-tv benaderde HTTP-servers te achterhalen. Daarvoor filter je op de makkelijkste manier het veld http. host eruit (- T files -e http.host).
TShark toont dan elke treffer op een aparte regel in de volgorde zoals ze in de trace-file staan. Om op meerdere velden te filteren, zet je de optie -e veldnaam
meerdere keren achter elkaar.
Om andere displayfilters of veldnamen te gebruiken, test je dezelfde trace-file eerst in Wireshark. Syntaxisfouten worden door het programma in het rood getoond. Als er geen fouten in een filterexpressie zitten, verandert de kleur in groen.
In het Wireshark-voorbeeld op deze pagina is te zien dat hier de op UPnP gebaseerde Multicastcommunicatie genegeerd wordt ( http.host and not ip.dst == 239.0.0.0/8). Dat is aan te raden omdat sommige apparaten tijdens het loggen heel veel UPnP-berichten verzenden. Die hebben echter niets te maken met waarin je hier geïnteresseerd bent en storen dus alleen maar. Bovendien is te zien hoe je met een klik op het te onderzoeken veld (in het midden van het vensterdeel linksonder) Wireshark ertoe kunt brengen om de exacte veldnaam weer te geven (onderaan op de statusbalk). In dit geval gebruikt Wireshark http.host, oftewel de variabele voor de namen van de HTTP-servers.
De output van TShark kan afhankelijk van het dataverkeertype en de gebruikte filters kort en overzichtelijk zijn. Maar vaak worden het lange lijsten, bijvoorbeeld met benaderde domeinen, en niet zelden komen in een trace dezelfde domeinen telkens weer voor. Dan is het aan te raden om de TShark-uitvoer te sorteren met een paar Unix-commando’s. Dan kun je de samenhangen beter herkennen en zien wat de frequentieverdelingen zijn.
Het commando sort sorteert de lijst alfabetisch. Vaker voorkomende records staan dan netjes onder elkaar. Met uniq -c voeg je meerdere records samen, bijvoorbeeld doelen die de smart-tv vaker bezocht heeft. Daarbij zorgt de -c van count ervoor dat aan het begin van de regel een getal komt dat de frequentie aangeeft. Elk item neemt daardoor nog maar één regel in beslag. Met een daaropvolgend commando sort /R wordt de lijst gesorteerd van hoog naar laag op volgorde van het aantal bezoeken, oftewel als ranglijst.
Die hele werkwijze is makkelijk te automatiseren door de commando’s met behulp van pipes (|) te koppelen. Dat ziet er onder Windows compleet dan zo uit:
tshark -r lg-tv1.pcap -Y "(http.request and not ip.dst == 239.0.0.0/8)" -T fields -e http.host | sort | uniq -c | sort /R
Bij Linux en macOS gebruik je in plaats van dat laatste sort-commando dan sort -g -r. Een analyse van een smart-tv van Philips bracht aan het licht dat het apparaat veel webservers bezocht met behulp van HTTP-requests. Daar zitten natuurlijk wat verwachte servers bij, zoals die van Netflix, maar ook een aantal onbekende doelen, zoals zeasn.tv en smartclip.net – je smart-tv leeft blijkbaar zijn eigen leventje.
HTTPS ANALYSEREN
Ook verbindingen die met HTTPS versleuteld zijn, zijn te onderzoeken. Dat kan zelfs zonder al teveel moeite, want bij het HTTPS-verkeer zijn alleen de gebruiksdata versleuteld en niet de bij het opzetten van een verbinding verstuurde pakketten. Dat is handig omdat veel serverexploitanten via een enkel IPv4-adres meerdere domeinen aanbieden. Het gewenste domein staat dan in de header van een HTTP-request bij ‘Server Name Indication’. Op basis van die SNI levert de doelserver aan de browser het bij het opgevraagde domein behoren
de TLS-certificaat en daarna de opgevraagde website. Bovendien gebruiken ook load-balancers de SNI om bij complexe serveromgevingen de requests voor te sorteren en door te sturen.
Om HTTPS-servers uit een trace te isoleren, gebruik je als displayfilter tls.handshake.extensions_server_name. De optie voor het betreffende veld is -T fields -e tls.handshake.extensions_server_ name. Het totale Windows-commando inclusief sort- en
uniq- pipe ziet er dan als volgt uit:
tshark -r lg-tv1.pcap -Y tls.handshake. extensions_server_name -T fields -e tls.handshake.extensions_server_name | sort | uniq -c | sort /R
Daar komt net zo’n lijst uit als bij de onversleutelde webservers. Op die manier kun je de voor een deel ongewenste verbindingen van een smart-tv op het spoor komen.
TOEVOEGEN AAN PI-HOLE
De resultaten kun je vergelijken met de zwarte lijsten van Pi-hole. De kans dat je daar een nieuwe reclameserver bij vindt is niet zo groot, want de makers van Pi-hole werken hun blacklists continu bij.
Als je een adblocker gebruikt en de zwarte lijst daarvan uitbreidt met een twijfelachtig domein, moet je er rekening mee houden dat het ook een wel gewenste smart-tv-dienst zou kunnen zijn, wellicht bijvoorbeeld voor het automatisch updaten van de firmware. Houd dan ook als het even kan een lijst bij van eigen uitbreidingen van de zwarte lijst, zodat je ongewenste blokkeringen later makkelijker ongedaan kunt maken.
DIRECTE DNS-QUERY’S
Naast de HTTP(S)-doelen zijn er nog andere interessante kandidaten voor een dataverkeeranalyse. Het gaat dan met name om de source- en destination-IP-adressen, oftewel ipv6.src en ipv6.dst voor het IPv6-protocol en ip.src en ip.dst voor IPv4. Succesvoller zijn waarschijnlijk echter de DNS-query’s dns.qry.name, die onversleutelde query’s van alle clients zichtbaar maken, ongeacht of een client later verbindingen via HTTPS, SMTP of wat dan ook opbouwt.
In een van onze traces viel bijvoorbeeld op dat de smart-tv niet alleen de via DHCP in het LAN geconfigureerde DNS-server bevroeg, maar ook rechtstreeks met Googles DNS-resolver 8.8.8.8 communiceerde. Dat is niet de bedoeling. De fabrikant van de smart-tv treft waarschijnlijk geen blaam: volgens het veld dns. flags.rseponse == 0 kan je er vanuit gaan dat de Google-query’s afkomstig waren van de op de smart-tv geïnstalleerde Netflix-app en niet van het besturingssysteem van de tv.
WIRESHARK VERSNELLEN
Een van de handigste TShark-toepassingen is datareductie om het analyseren met Wireshark te versnellen. Wireshark doet namelijk lang over het werken met grote bestanden. Het duurt even voor je wat te zien krijgt, omdat het programma na elke aanpassing van het displayfilter het complete databestand opnieuw inlaadt. Om alle op dat moment geselecteerde pakketten van een 600 MB groot capture-bestand weer te geven, heeft zelfs een moderne computer met een i7-dualcore-processor en 16 GB RAM een flinke 40 seconden nodig – en dat dan elke keer als je iets aan de filterregels verandert.
Om al bij het loggen een beperkend capture-filter te gebruiken werkt echter contraproductief. Bij foutanalyses weet je in eerste instantie vaak namelijk niet waar je moet beginnen of waar je naar op zoek bent. Daarom is het adagio: zo veel mogelijk loggen als nog net haalbaar is.
Om daarna echter toch soepel met Wireshark te kunnen werken, moet je overwegen waar je wilt beginnen. Een goed startpunt kan bijvoorbeeld de DNS-communicatie zijn. Extraheer uit het grote logbestand dan ook eerst alle DNS-pakketten naar een nieuw bestand met het displayfilter udp.port eq 53 or tcp.port eq 53. De expressie dns zou veel simpeler zijn, maar dan krijg je alleen het DNS-verkeer te zien. Dan zou je bij bijvoorbeeld TCP-DNS-verkeer voor het opbouwen van de verbinding mislopen.
Gebruik daarom TShark voor het inlezen van het oorspronkelijke bestand samen met een filter om een kleinere variant aan te maken:
tshark -r inputfile.pcapng -Y "udp.port eq 53 or tcp.port eq 53" -w alleen-dns-traffic.pcapng Grote logbestanden kun je handig in segmenten verdelen, bijvoorbeeld in meerdere bestanden van elk 100 MB groot. Want als je het dataverkeer van zeer snelle interfaces met een hoge doorvoersnelheid wilt loggen, dan krijg je binnen de kortste keren met enorm grote databestanden te maken. Met TShark en een beetje handigheid kun je de verdachte of essentiële delen dan snel extraheren en aan Wireshark voeden in kleine porties.
Dat doe je, samen met een filtering, op eenvoudige wijze via een shell-script. Hieronder is dat een Windows-batch-bestand. Dat zet de gefilterde segmenten in een submap en zet daar ook de eveneens bij Wireshark horende tool mergecap bij:
for %a in (*.pcapng) do tshark -r %a -Y "udp. port eq 53 or tcp.port eq 53" -w subdir\%a cd subdir mergecap -w single-file.pcapng *.pcapng Systeembeheerders gebruiken TShark-analyses ook voor kwaliteitscontrole: als je bijvoorbeeld een openbare DNS-server exploiteert waarvoor mensen zich moeten authenticeren, dan kun je de door de clients gebruikte DNS-vlaggen uitlezen. Op die manier kun je degenen identificeren die ten onrechte recursieve DNS-query’s versturen ( dns.flags.recdesired).
IPV6-PERIKELEN
Als je servers beheert die ook met IPv6 werken, is het mogelijk om ICMPv6-foutcodes te analyseren. Die komen van backbone-routers en firewalls als ze niet in staat zijn om iets te doen met de IPv6-reply-pakketten van je servers. Mogelijke oorzaken zijn ontbrekende routes, routing-loops of blokkerende firewall-policy’s. Om fouten binnen je eigen netwerk uit te sluiten, helpt het om naar de details te kijken. Daarbij zijn de volgende twee velden relevant: -e icmpv6.type -e icmpv6.code.
Als daarin de fout ‘Type 1 Code 0’ zit, betekent dit dat ‘no route te destination’. Routers versturen die als ze een pakket door het ontbreken van een correcte route niet thuis kunnen brengen. Als je server die fout krijgt bij een poging om te antwoorden op een request vanuit internet, is het source-IPv6-adres wellicht vervalst of deugt de routing van het remote netwerk niet.
Daarbij betekenen ‘Typ 1 Code 3’ respectievelijk ‘address unreachable’ dat de laatste router in het pad dat het dataverkeer aflegt het doel-IPv6-adres (Layer 3) niet kon herleiden tot een MAC-adres (Layer 2). Dat kan liggen aan een verkeerd geconfigureerde IPv6stack van de client of het onbedoeld blokkeren van de
IPv6-Neighbour-Sollicitations, die noodzakelijk zijn voor een omzetting. In beide gevallen kan de client niet via IPv6 communiceren – wat blijkbaar nog niemand opgevallen is.
‘Typ 3 Code 0’ respectievelijk ‘hop limit exceeded in transit’ is de klassieker onder de ICMPv6-fouten. Dat duidt op een routing-loop waarbij het dataverkeer blijft hangen tussen twee routers. Je kunt met traceroute in elk geval achterhalen of die routers zich binnen jouw netwerk bevinden.
Dat dergelijke fouten dagelijks voorkomen is te zien bij een lijst van vier servers van de NTP-pool. Binnen 24 uur doken er duizenden ICMPv6-foutmeldingen op, die met het volgende script geëxtraheerd konden worden:
tshark -r ntp-outside.pcapng -Y "icmpv6" -T fields -e icmpv6.type -e icmpv6.code | sort | uniq -c
Verbazingwekkend genoeg traden er meteen zeven typen fouten op. Er zit blijkbaar nog iets niet helemaal goed bij de IPv6-implementaties van sommige netwerkbeheerders.
SECURITY-PROBLEMEN
Het voorbereiden van de data met TShark helpt ook bij het analyseren van security-problemen. We hebben bijvoorbeeld geprobeerd of de load-balancers van F5 Networks vatbaar zijn voor Logjam-aanvallen. Logjam maakt gebruikt van het feit dat oudere TLSimplementaties bij de Diffie-Hellman-sleutelovereenkomst openbare sleutels (Public Key) niet slechts eenmaal, maar meerdere malen gebruiken. Dit kunnen aanvallers niet alleen misbruiken om versleutelde content mee te lezen, maar om ook die te vervalsen.
Het startpunt van de analyse was Wireshark. In het logbestand zochten we vervolgens naar een pakket met het handshake-type ‘Server Key Exchange’. In de afbeel
ding staat daar een (1) bij. Toen we die als displayfilter hadden ingesteld (2), liet Wireshark de pakketten met hun inhoud zien. De identificatie van het veld (3) verscheen onderin op de statusbalk (4) toen we klikten op de Pubkey. Heel handig: met een rechter muisklik en ‘Apply as column’ voegt Wireshark dat veld als een extra kolom in bij het pakketoverzicht. Dan is al snel te zien dat de velden van de eerste vier records – oftewel de Pubkey’s – identiek zijn (5).
Daarmee is het probleem bewezen en heb je TShark eigenlijk niet meer nodig. Maar de trace-files zijn niet altijd met Wireshark te openen. Sommige staan op remote servers en als ze groot zijn, loont het amper om ze voor dergelijke analyses te versturen. Dan kun je TShark via SSH meteen op de remote computer gebruiken. De public keys identificeer je met de opties -Y tls. handshake.type == 12 en -T fields -e tls.handshake.ys en je sorteert de output vervolgens weer met sort | uniq -c | sort /R.
Het hangt sterk van het doel af welke pakketvelden je moet isoleren. TShark biedt je die mogelijkheid en zorgt ervoor dat je niet wegzakt in het moeras van een gigantisch trace-bestand. Met een paar stappen onderzoek je het internetverkeer van huisgenoten of van je IoT-apparaten – en dat zonder muis, zonder knip- en plakwerk en zonder Excel nodig te hebben.