Mirroring-poort van Gigabit-switch gebruiken
Het instellen van een switch om het dataverkeer van een te analyseren netwerkapparaat door te sturen naar een andere poort lijkt vaak triviaal. Toch zijn er een paar dingen die je in gedachten moet houden om niets te missen.
Bij het diagnosticeren van netwerkproblemen zoals verbindingsonderbrekingen, langzame overdrachten, storingen tijdens het opbouwen van een verbinding en ook bij het optimaliseren van de netwerkcommunicatie is één zeer bepalende factor van invloed op het hele proces: de nauwkeurigheid van de meting.
Want zoals je misschien nog weet uit de natuurkundelessen: ‘meten is weten’ gaat niet altijd op. En dat geldt ook voor netwerkmetingen. Elke poging om een probleem te meten verandert dan onvermijdelijk de uitgangspositie in het netwerk, omdat het meetapparaat ook deel gaat uitmaken van dat netwerk en daar dus invloed op heeft. Dat kan nu eenmaal niet anders, dus moet je je altijd bewust zijn van de mate waarin de verandering van invloed is op de nauwkeurigheid van de meetgegevens. Anders worden de meetgegevens verkeerd beoordeeld, zal een analyse moeilijk zijn of zelfs mislukken. Je kunt de situatie een beetje vergelijken met het afsluiten van plaats delict: als de forensische afdeling onscherpe foto's maakt of zelfs de dop op de lens vergeet, wordt het latere werk van de rechercheurs een stuk lastiger.
SHARK ATTACK!
Natuurlijk gebruiken netwerkanalisten in plaats van foto's meestal de opensourcetool Wireshark om netwerkopnames te analyseren. Wireshark kan de meetgegevens ook zelf registreren en voor een latere analyse in bestanden opslaan. Als je daar beter naar kijkt, zul je zien dat Wireshark dat eigenlijk helemaal niet zelf doet, maar de meting overlaat aan de commandline-tool dumpcap. Zo’n commando ziet er als volgt uit: dumpcap -i
Als je weet dat het zo werkt, heb je een van de belangrijkste optimalisaties al binnen handbereik: in plaats van Wireshark als controlecentrum te gebruiken, met inbegrip van zijn GUI-overhead en misschien in sommige van de analysemodules op de loer liggende bugs, werk je rechtstreeks met
dumpcap. Dat start aanzienlijk sneller en werkt zeer betrouwbaar. Mocht de tool tijden een meting een keer crashen, dan kun je de eerder opgenomen data meestal nog wel in een tijdelijke map vinden en redden.
Tegenwoordig worden de netwerkmetingen meestal op drie verschillende manieren doorgevoerd. De meest voorkomende is het lokaal opnemen van de pakketten, oftewel op de computer die ze verstuurt en ontvangt. De tweede manier is het meten via een mirror-poort op een netwerkswitch (Switched Port Analyzer, daardoor ook wel SPAN-poort genoemd). De derde manier is het professioneel meten met een extra apparaat dat binnen de netwerklijn wordt aangesloten, namelijk met een Terminal Access Point (kortweg TAP). Netwerk-TAP’s behandelen we in een artikel in een volgende c’t.
Alle andere meetmethoden zijn daarbij meestal varianten van lokale metingen. Daarbij hoort bijvoorbeeld het opnemen op een pc met een bridge van twee netwerkkaarten, of de meer professionele meetoplossing waarbij de datapakketten door een meetkaart worden geleid.
LOKALE METINGEN ONNAUWKEURIG
Het meten op een te onderzoeken computer is eenvoudig in te stellen, omdat je geen andere apparaten nodig hebt en ook geen switch hoeft te configureren. Helaas levert dat de meest onnauwkeurige meetresultaten op van alle drie de methoden. Dat kan er in bepaalde probleemgevallen toe leiden dat de analyse mislukt, omdat je bij dergelijke scenario's de probleem-pc gebruikt om de data te laten opnemen. Bij een politieonderzoek zou je een verdachte ook niet zijn eigen gangen laten documenteren en dan alleen van die gegevens gebruik maken.
Het belangrijkste probleem met het rechtstreeks op het te analyseren systeem meten, is dat de gemeten data vaak niet overeenkomen met de werkelijke pakketten die de netwerkkaart via de kabel verzonden heeft. Ook het binnenkomend opgenomen dataverkeer kan door pc vervalst worden, hoewel dat niet zo vaak gebeurt. Een voorbeeld is de grootte van de netwerkpakketten. Daarbij moet je erop letten dat dumpcap de ethernet-checksums (FCS, Frame Check Sequence) niet mee opslaat. Elk door dumpcap opgeslagen normaal ethernetpakket wordt daarom met 4 bytes minder weergegeven dan het eigenlijk heeft na het verlaten van de ethernetkaart. Volgens de ethernetspecificatie moeten ze inclusief FCS ten minste 64 bytes groot zijn, met een maximum van 1518 bytes – Jumbo-frames uitgezonderd.
De groottes lijken bij veel lokale metingen niet te kloppen. Als je ervan uitgaat dat de geobserveerde verkeerde pakketgroottes het probleem zouden kunnen veroorzaken, ligt een verkeerde diagnose op de loer. Want meestal vallen de daadwerkelijk via de kabel verzonden pakketgroottes binnen de specificatie, maar dat kun je met een lokale meting niet zonder meer bevestigen of weerleggen.
Hetzelfde geldt voor de checksums, want bij lokale metingen bewaart dumpcap de uitgaande pakketten voordat hun checksum berekend wordt (meer precies: als de CRC-offloading van de netwerkkaart actief is, wat vaak het geval is). In plaats daarvan staat er in de checksum-velden van pakketten vaak provisorische en dus niet correcte informatie, zodat Wireshark vaak mislukte herberekeningen meldt. Dat geldt voor zowel IP-, TCP- als UDP-checksums.
In het verleden hebben die foutmeldingen voor enorme verwarring gezorgd bij gebruikers die de context niet kennen. Daarom controleren de huidige Wireshark-versies met de standaardinstellingen de checksums niet meer. Als je die functie nodig hebt, moet je die dan ook in het menu activeren. De instelling voor TCP-checksums vind je bijvoorbeeld in het menu ‘Edit / Preferences / Protocols / TCP / Validate the TCP checksum if possible’.
Trouwens: als je als serviceprovider een trace voor een klant analyseert, die optie inschakelt en vervolgens foutieve checksums vindt voor uitgaande pakketten, is dat een sterke aanwijzing dat je naar een lokale registratie kijkt. Een netwerkkaart gooit pakketten met foutieve checksums namelijk zelf weg, zodat die helemaal niet in de meetgegevens van een TAP- of SPAN-poort zouden mogen verschijnen.
Het checksum-probleem is typisch bij netwerkkaarten die deze taak (en andere) overnemen van de cpu van de computer. De instellingen ervoor zijn te vinden bij de driverconfiguratie van de kaart, meestal onder de naam ‘Checksum Offload’.
Je zou die functie kunnen uitschakelen om de checksumproblemen te verbergen, maar dat is niet aan te raden. Ten eerste verander je het scenario daarmee aanzienlijk, zodat de opname niet meer onder dezelfde omstandigheden plaatsvindt. Ten tweede reduceer je de netwerkprestaties van het systeem, want het ontlasten van de cpu is voor een snelle dataoverdracht vaak een vereiste.
SPIEGELTJE, SPIEGELTJE ...
Het komt er al met al op neer dat je voor een netwerkmeting, zelfs voor een eenvoudige taak, het beste een extra systeem kunt gebruiken dat niet zelf deelneemt aan de geobserveerde communicatie. Dat kan een server, een laptop of een speciaal meetsysteem zijn. Een gedetailleerd overzicht van opnamesystemen, inclusief hun geschiktheid voor verschillende eisen, vind je vanaf pagina 108.
Ongeacht welk systeem je kiest, ze hebben in eerste instantie allemaal hetzelfde probleem: ze moeten allemaal bij de pakketten kunnen, die bij de moderne ip-netwerken meestal via de switches worden verzonden. Die switches sturen de binnenkomende pakketten dan niet naar alle systemen die
erop zijn aangesloten, maar alleen naar de ethernetpoort waarop de ontvanger aangesloten is. Netwerkapparaten identificeren de ontvanger aan de hand van hun individuele MAC-adressen. Die kunnen worden gelezen met behulp van het Address Resolution Protocol (ARP) voor IPv4 en het Neighbor Discovery Protocol (NDP) voor IPv6.
De meeste managed switches kunnen eenvoudig worden geconfigureerd om pakketten die bestemd zijn voor een specifiek MAC-adres te kopiëren en naar een ander apparaat te sturen (port-mirroring). Oorspronkelijk is die functie ontwikkeld om de interne werking van de switches te controleren. Daarom kunnen veel modellen ook de pakketten spiegelen die naar of van de switch-cpu worden gestuurd.
Je kunt op de volgende manier bijvoorbeeld port-mirroring instellen bij een Ciscoswitch:
Switch(config)#monitor session 1 source interface gigabitEthernet 1/7 both Switch(config)#monitor session 1 destination interface gigabitEthernet 1/24
Normaal gesproken kun je vastleggen of een switch binnenkomende of uitgaande pakketten van de bronpoort moet spiegelen. Dat lijkt misschien ongebruikelijk, want je wilt bijna altijd beide verkeersrichtingen analyseren. Bij veel switches zijn echter ook VLAN’s geconfigureerd, oftewel dan zijn er meerdere netwerkstations samengevoegd tot groepen, zodat je bij de betreffende ethernetpoorten meteen hele VLAN’s kunt spiegelen.
Vooral als het een VLAN-poort is, is het aan te raden om alleen binnenkomende of uitgaande pakketten te spiegelen. Anders worden er snel duplicaten gemaakt, bijvoorbeeld als er twee apparaten van een VLAN op de switch zijn aangesloten. Dan krijg je elk pakketje twee keer: als het bij de switch aankomt en als het de switch weer verlaat. Hetzelfde fenomeen doet zich voor als je meer dan één poort als bron configureert en de aangesloten apparaten met elkaar communiceren.
Duplicaten zijn echter niet alleen vervelend omdat ze de opname opblazen en het moeilijk maken het overzicht te bewaren, maar ook omdat ze tot verkeerde conclusies kunnen leiden. De TCP-analysemodule van Wireshark herkent bijvoorbeeld duplicaten niet en rapporteert daarom vaak verkeerd over retransmissions. Ervaren analisten herkennen de duplicaten meestal aan het feit dat twee pakketten 100 procent identiek zijn, dus dat ook de IP-ID van twee pakketten identiek is.
Als je nog steeds duplicaten in een opname vindt, hoef je niet de IP-ID van elk pakket te controleren. Gebruik in plaats daarvan de commandline-tool editcap. Die is geïnstalleerd met Wireshark. Deze tool berekent
een MD5-hash voor alle pakket afzonderlijk en vergelijkt die met een configureerbaar aantal eerder ontvangen pakketten (duplicate window). Als editcap een of meer pakketten met dezelfde hash in dat window vindt, gaat het uit van een duplicaat en wordt dit verwijderd. Het uitvoeren van editcap -d -D 50 duplicates.pcapng noduplicates. pcapng zal uitvoer produceren in de vorm van 12538 packets seen, 6340 packets skipped with duplicate window of 50 packets.
Port-mirroring leidt alleen tot zinvolle resultaten als de betreffende switch zich in het communicatiepad van de betreffende pakketten bevindt en dit door een beheerder te configureren is. Switches in de lagere prijscategorie kunnen niet worden geconfigureerd, waardoor ze niet geschikt zijn voor dataverkeersregistratie. Helaas geldt dat ook voor veel gangbare kabel- en mobiele routers.
Onder de betere routers in dat opzicht behoren de op OpenWrt gebaseerde modellen zoals de Turris Omnia en de populaire Fritzboxen. Met een Fritzbox is het bijzonder makkelijk om het dataverkeer op te nemen. Om dat te doen, hoef je alleen maar de url http://fritz.box/html/capture.html dan in de browser in te typen en de gewenste interface te selecteren. De Fritzbox kopieert de data van de geselecteerde poort vervolgens naar de browsersessie. Als je de opname stopt, komen de gegevens op de schijf in de downloadmap van de browser in het gebruikelijke pcap-formaat terecht.
Daarbij moeten we wel opmerken dat sommige providers de mogelijkheden van hun apparaten in de firmware beperken. Maar als je een vergelijkbaar model in de winkel koopt, heb je daar geen problemen mee. Zelfs als je router het verkeer niet kan opnemen, is alles nog niet verloren. In dat geval kun je echter niet opnemen wat er in de router gebeurt, zodat de vraag onbeantwoord blijft wat er precies op zijn WAN-interface ontvangen en verzonden wordt. Hetzelfde geldt voor de wifi-interfaces. Het verkeer van de rest van het LAN kan echter makkelijk worden opgenomen door een goedkope managed switch tussen het LAN en de router aan te sluiten.
In het verleden installeerde je eenvoudigweg een hub in de te bewaken kabel en las je de data op een van de andere poorten mee. Dat wordt nu sterk afgeraden. Afgezien van het feit dat je die hubs eigenlijk alleen nog tweedehands tegenkomt, veranderen ze de netwerksituatie drastisch en onaanvaardbaar. Hubs vertragen het verkeer tot ongeveer 30 Mbit/s en werken slechts Half Duplex, wat leidt tot veel pakketbotsingen. Daarom zijn ze al lang uit bijna alle netwerken verbannen – en terecht.
In plaats daarvan wordt het gebruik van goedkope managed Gigabit-switches aanbevolen. De mirror-functie kan naar wens worden geconfigureerd of permanent aan specifieke poorten worden toegekend. Er zijn verschillende modellen met een mirrorfunctie en 5 tot 8 poorten verkrijgbaar vanaf zo’n 30 euro. Dat zijn onder meer de Netgear GS105Ev2 en de TP-Link TL-SG105E.
Als je een managed switch hebt waarvan de documentatie niet expliciet iets over port-mirroring vermeldt, zoek dan in de beheerinterface naar functies waarbij bron- en doelpoorten kunnen worden opgegeven. Bij het specificeren van de bronpoort moet je één of meerdere poorten kunnen definiëren. De doelpoort is die van het meetapparaat. Bij de meeste managed switches bevinden dergelijke functies zich in het diagnostische gebied.
VOOR- EN NADELEN VAN MIRRORING
Het grootste voordeel van het mirroren van poorten is dat de metingen vrijwel direct kunnen worden gestart zonder daar de lopende verbindingen voor te hoeven onderbreken. Dat is een groot voordeel. Het is voldoende om een meetapparaat aan te sluiten en de pakketten van de onderzochte communicatiepartners daar naartoe te sturen. Zelfs als de meting wordt beëindigd, wordt de werking niet verstoord. Daarom zijn meet- en analyseopstellingen via mirror-poorten bij veel bedrijfsnetwerken heel gebruikelijk. Bovendien is zo’n opstelling niet duur omdat je alleen een meetapparaat nodig hebt. Dat heb je ook nodig bij een op TAP gebaseerde meting.
Maar natuurlijk heeft port-mirroring ook nadelen. De gekopieerde pakketten zijn vaak niet 100 procent nauwkeurig, omdat het primaire doel van een switch de juiste werking van het netwerk is. Dat betekent dat als er prestatieproblemen zijn, de gespiegelde poort pakketten kan weglaten, de volgorde kan veranderen of pakketten met een aanzienlijke tijdsvertraging doorgeeft naar het meetapparaat.
Er zijn ook scenario's waarbij een switch zelf de mogelijke oorzaak zou kunnen zijn van de ontstane netwerkproblemen. Als die switch dan voor de meting wordt gebruikt, wordt het lastig het probleem te achterhalen. Als pakketten bijvoorbeeld niet aankomen bij een web- of mailserver, maar wel aanwezig zijn in de uplink naar de switch, is het onmogelijk om met behulp van port-mirroring te bewijzen of de pakketten door de switch worden geweigerd of toch echt naar de netwerkkaart van de server worden doorgestuurd. In die situatie helpt alleen een TAP.
Tot slot nog een advies uit onze vele jaren aan ervaring: controleer beter een keer te veel om er geheel zeker van te zijn dat je de juiste poorten hebt genoteerd en dat de beoogde uitvoerpoort daadwerkelijk ook echt vrij is. Helaas worden bij het spiegelen van poorten maar al te vaak de verkeerde poorten als bron of bestemming geconfigureerd. In het ergste geval kan dat leiden tot onderbrekingen in het netwerk, bijvoorbeeld als je de switch-uplink als uitvoerpoort zou definiëren. Hou dat zeker in het achterhoofd, want bij productienetwerken met tijds- of veiligheidskritische toepassingen kan dat tot zeer onaangename gevolgen leiden.