De transparantie van het IoT vergroten met de SPIN PCAP-reader

SPIN: een korte introductie

SPIN staat voor Security and Privacy for In-home Networks. SIDN Labs creëerde SPIN om de privacy- en beveiligingsproblemen met het IoT te helpen aanpakken. IoT-apparaten worden bijvoorbeeld nog steeds ingelijfd bij botnets die kunnen worden gebruikt voor DDoS-aanvallen. Daarbij komt dat IoT-apparaten de privacy van de gebruiker vaak niet respecteren, iets wat niet altijd duidelijk is voor de eindgebruiker. Daarom vinden wij het nodig om gebruikers in staat te stellen inzicht te krijgen in wat hun IoT-apparaten doen (bijvoorbeeld wat betreft de soorten gegevens die de apparaten over hen verzamelen en waar ze die naartoe sturen) en de mogelijkheid te geven om hun thuisnetwerken te beschermen.

Met SPIN ervaart een gebruiker meer transparantie. Het is bijvoorbeeld mogelijk om live netwerkverkeer te inspecteren dat door IoT-apparaten wordt gegenereerd. Daarnaast hebben gebruikers met SPIN meer controle over hun IoT-apparaten, omdat SPIN hen in staat stelt ‘in te grijpen’ in het netwerkverkeer van die apparaten, bijvoorbeeld door een domeinnaam te blokkeren.

SPIN wordt meestal geïmplementeerd door het te installeren op een thuisrouter, zoals te zien is in Figuur 1. SPIN kan dan al het netwerkverkeer van de IoT-apparaten zien (en zo nodig manipuleren). Technisch gesproken is een proces dat de SPIN-daemon wordt genoemd en wordt uitgevoerd op de thuisrouter, verantwoordelijk voor het analyseren van het netwerkverkeer. De SPIN-daemon doet dit door verschillende soorten informatie (door verkeersmetingen verkregen) uit de kernel van het besturingssysteem te extraheren, zoals de domeinnaam waarmee een IoT-apparaat verbinding maakt. Daarnaast kan de SPIN-daemon de kernel instrueren om bepaalde verkeersstromen te blokkeren. In het volgende gedeelte van deze blogpost gaan we dieper in op de soorten informatie die SPIN analyseert en hoe gebruikers die informatie kunnen benutten.

Analyse van het netwerkverkeer

In dit gedeelte van de blogpost bespreken we de soorten informatie die SPIN verzamelt om inzicht te krijgen in wat een apparaat precies doet. We doen dit aan de hand van een voorbeeld, waarbij we uitleggen wat de gebruiker ziet als er gewerkt wordt met de webinterface van SPIN. De volgende screenshot toont het netwerkverkeer van een aantal apparaten zoals gevisualiseerd door SPIN.

Lokale apparaten vs. externe hosts

Het eerste wat we zien als we naar de SPIN-webinterface kijken (zie Figuur 2), is een aantal knooppunten en pijlen. De knooppunten vertegenwoordigen hosts, terwijl een pijl verkeer tussen 2 hosts aangeeft. We zien wat grijze knooppunten, maar ook blauwe en groene. Als een knooppunt grijs is, wil dat zeggen dat de host een apparaat in het lokale netwerk is, terwijl de andere knooppunten externe hosts zijn waarmee het apparaat verbinding maakt. Het is nuttig om dit onderscheid te maken, omdat sommige acties van SPIN alleen op lokale apparaten kunnen worden toegepast. Een PCAP-bestand downloaden van het verkeer van een apparaat is bijvoorbeeld alleen mogelijk bij lokale apparaten.

Gelukkig is het niet moeilijk om vast te stellen of een host waarmee we praten een lokaal apparaat is of niet. Hosts in een IPv4-netwerk maken gebruik van het Address Resolution Protocol (ARP) om het MAC-adres van hosts in hetzelfde subnet te bepalen. De resultaten van dit protocol worden opgeslagen in de ARP-tabel. Als we de adressen in de ARP-tabel inspecteren, kunnen we zien welke toebehoren aan lokale apparaten. Voor hosts waarmee de verbinding via IPv6 verloopt, gebruiken we de tegenhanger van ARP, het Neighbor Discovery Protocol (NDP).

Met wie praten apparaten?

Hiervoor kijken we naar de pijlen tussen de knooppunten in de SPIN-webinterface (zie Figuur 2). Deze pijlen geven verkeersstromen tussen de knooppunten (hosts) aan. SPIN gebruikt flow records om de verkeersstromen weer te geven. Flow records bevatten over het algemeen het IP-adres van de bron en van de bestemming, het transportlaagprotocol en de poortnummers van de transportlaag, indien van toepassing. Daarnaast bevatten ze tellers die het aantal waargenomen pakketten en bytes weergeven. Hierdoor geven ze een gestructureerd overzicht van het waargenomen netwerkverkeer.

Namen omzetten in IP-adressen

Hosts op het internet communiceren met elkaar met behulp van IP-adressen. IP-adressen zijn voor mensen echter niet erg handig om mee te werken. In de praktijk wordt een verbinding met een IP-adres doorgaans voorafgegaan door een DNS-zoekactie om het desbetreffende IP-adres te verkrijgen. Daarom kijken we ook naar DNS-verkeer. Op die manier kunnen we een IP-adres koppelen aan de domeinnaam die werd gebruikt om dat adres op te zoeken. In de screenshot (zie Figuur 2) is bijvoorbeeld te zien dat de receiver verbinding maakt met youtu.be. Onder de motorkap wordt youtu.be omgezet naar een groot aantal IP-adressen, bijvoorbeeld 2a00:1450:400e:804::200e.

Live netwerkverkeer vastleggen

Nu we weten in welke soorten informatie we geïnteresseerd zijn als we verkeer analyseren, kunnen we kijken hoe SPIN die informatie voor de analyse van live netwerkverkeer precies verzamelt.

De procedure met betrekking tot de ARP- en NDP-tabellen is simpel: om de zoveel tijd scant de SPIN-daemon de tabellen op nieuwe vermeldingen om te zien of er nieuwe apparaten op het netwerk zijn verschenen. SPIN slaat gegevens van alle apparaten op in een tabel-achtige structuur en raadpleegt deze tabel als het wil weten of er een nieuw apparaat bij is gekomen.

SPIN verzamelt de flow records met behulp van het Netfilter Connection Tracking System in de Linuxkernel. Zoals de naam al aangeeft, houdt dit systeem het verkeer bij dat door de router stroomt. Informatie over de bijbehorende verbindingen (bijvoorbeeld het aantal waargenomen bytes en pakketten) kan vanuit de kernel worden geëxporteerd naar de user space. Deze informatie heeft van zichzelf al een flow record-achtige structuur, die ook geschikt is voor onze doeleinden.

Om ervoor te zorgen dat we DNS-verkeer kunnen analyseren, instrueren we Netfilter om pakketten te registreren op poort 53. Door Netfilter geregistreerde pakketten kunnen worden geïnspecteerd door gebruikersruimteprogramma's. Door van deze mogelijkheid gebruik te maken, kunnen we DNS-verkeer naar de SPIN-daemon sturen, zodat we de inhoud van DNS-pakketten kunnen analyseren en waar nodig gepaste actie kunnen ondernemen.

Opgeslagen netwerkverkeer inspecteren

Tot voor kort ondersteunde SPIN uitsluitend het vastleggen van live netwerkverkeer. Het is echter ook handig om netwerkverkeer uit het verleden te kunnen inspecteren, bijvoorbeeld als een gebruiker opgeslagen netwerkverkeer van een derde partij wil onderzoeken. Om dat mogelijk te maken, kan netwerkverkeer worden geregistreerd en opgeslagen in PCAP-bestanden. De PCAP-bestandsindeling is in feite de norm; veel populaire tools voor het analyseren van netwerkverkeer (bijvoorbeeld tcpdump en Wireshark) kunnen PCAP-bestanden lezen en/of schrijven. We zouden SPIN ook graag gebruiken voor het analyseren van netwerkverkeer dat is opgeslagen in PCAP-bestanden.

Ter ondersteuning van de analyse van opgeslagen netwerkverkeer hebben we enkele wijzigingen aangebracht in SPIN. De belangrijkste wijziging in de SPIN-daemon is de toevoeging van een tweede manier waarop SPIN informatie over netwerkverkeer opdoet. Waar het in de praktijk op neerkomt, is dat we een interface aan de SPIN-daemon hebben toegevoegd waarmee we de 3 soorten informatie waar we het over gehad hebben (wijzigingen in de ARP- en NDP-tabellen, flow records en DNS-pakketten) kunnen [aanvoeren/sturen/communiceren] naar de SPIN-daemon. De PCAP-reader extraheert die informatie uit de PCAP-bestanden en stuurt deze naar de SPIN-daemon (met behulp van de nieuwe interface).

Een nieuwe PCAP-reader

De PCAP-reader is een nieuw programma binnen de SPIN-software. Het leest een PCAP-bestand, extraheert de 3 soorten informatie (wijzigingen in ARP- en NDP-tabellen, flow records en DNS-pakketten) uit de pakketten in het PCAP-bestand en stuurt die informatie op de opgenomen snelheid naar de SPIN-daemon. De PCAP-reader is een afzonderlijk programma; het levert de relevante informatie aan een SPIN-daemon die al actief is, via UNIX-domeinsockets. Laten we eens kijken naar hoe de PCAP-reader de informatie uit een PCAP-bestand extraheert.

Het extraheren van de flow records is simpel: voor elk pakket in het PCAP-bestand kunnen we de relevante informatie (IP-adressen, poortnummers, enz.) extraheren, een flow record samenstellen en dit versturen naar de SPIN-daemon. Momenteel stuurt de PCAP-reader voor elk pakket een ‘digest’ naar de SPIN-daemon. We denken na over manieren om dat proces efficiënter te maken; hier komen we in het laatste gedeelte van deze blog op terug.

Wat betreft DNS-pakketten is de aanpak van de PCAP-reader niet veel anders dan die van de SPIN-daemon. De PCAP-reader analyseert pakketten op poort 53 en als er namen worden gevonden die aan IP-adressen zijn gekoppeld, worden die doorgegeven aan de SPIN-daemon.

Het emuleren van de ARP- en NDP-tabellen is iets lastiger. Tijdens het lezen van een PCAP-bestand hebben we geen toegang tot de ARP- en NDP-tabellen van het apparaat waarop het verkeer is vastgelegd. Bovendien kunnen we uit het PCAP-bestand niet opmaken wat bijvoorbeeld de netwerkconfiguratie van het apparaat in kwestie was. Hier zijn meerdere oplossingen voor, elk met zijn eigen voor- en nadelen.

De eerste optie is de methode die momenteel in de PCAP-reader is geïmplementeerd. Bij deze aanpak wordt gezocht naar ARP- en NDP-antwoorden. Ter verduidelijking: een ARP-antwoord wordt verzonden als antwoord op een ARP-verzoek. Een apparaat kan een ARP-verzoek uitzenden als degene die het verzoek doet, wil weten welk MAC-adres wordt gebruikt door het IP-adres in het verzoek. Een ARP-antwoord bevat het antwoord op die vraag. Als in het PCAP-bestand een ARP-antwoord wordt waargenomen, weten we dat het IP-adres in het antwoord toebehoort aan een apparaat dat zich op het lokale netwerk bevindt. Vervolgens geeft de PCAP-reader deze informatie door aan de SPIN-daemon. Een voordeel van deze aanpak is dat het gemakkelijk te implementeren is. Een nadeel is dat we tijdens het opnieuw afspelen van een PCAP-bestand niet altijd van tevoren weten dat een waargenomen IP-adres toebehoort aan een lokaal apparaat; dat kunnen we pas achterhalen als ook een ARP-antwoord is waargenomen.

Een andere methode voor het inspecteren van ARP- en NDP-pakketten zou zijn om het PCAP-bestand in 2 stappen te verwerken. Tijdens de eerste stap zouden we het PCAP-bestand in zijn geheel scannen op ARP- en NDP-antwoorden en noteren welke adressen daarbij betrokken zijn. Vervolgens zouden we tijdens de tweede stap het PCAP-bestand opnieuw kunnen doorlopen en pas dan alle pakketten die we waarnemen ook echt verwerken. Aangezien we na de eerste stap zouden weten welke IP-adressen toebehoren aan lokale apparaten, zouden we in staat zijn om die informatie door te spelen aan de SPIN-daemon voordat het lokale apparaat pakketten daadwerkelijk zou verzenden. Deze methode zou de SPIN-daemon een nauwkeuriger beeld geven van het netwerkverkeer dan de methode die we nu hanteren. Daarom zijn we van plan om deze methode ook te implementeren, maar het kan zijn dat we hem pas standaard inschakelen als we alle implicaties van het altijd in 2 stappen verwerken van het PCAP-bestand hebben afgewogen.

Tot slot zou het niet nodig zijn om het PCAP-bestand te scannen op ARP- en NDP-pakketten als SPIN zou weten welke IP-bereiken tot het lokale netwerk behoren. De gemakkelijkste manier om dat te implementeren zou zijn om de gebruiker de informatie te laten verstrekken wanneer het PCAP-bestand opnieuw wordt afgespeeld voor SPIN. Daarvoor zou echter meer netwerkspecifieke informatie van de gebruiker nodig zijn. SPIN zou de desbetreffende informatie mogelijk ook kunnen afleiden uit netwerkconfiguratiebestanden. Zo'n implementatie zou natuurlijk uiterst platformspecifiek zijn. Geen van beide opties lijkt op het eerste gezicht ideaal; we zijn daarom nog aan het nadenken over de beste manier om het probleem op een gebruikersvriendelijke manier op te lossen.

Momenteel wordt er één bericht gestuurd voor elke soort informatie die de PCAP-reader tegenkomt.

Wijzigingen in de SPIN-daemon

Dat is dus hoe de PCAP-reader aan de 3 soorten informatie (wijzigingen in ARP- en NDP-tabellen, flow records en DNS-pakketten) komt. We hebben echter nog steeds een manier nodig om die informatie bij de SPIN-daemon te krijgen, aangezien SPIN tot nu toe alleen met live netwerkverkeer heeft gewerkt. Dat is waar een pas ontwikkelde voorziening met de naam external source (extsrc) om de hoek komt kijken. extsrc opent bij het opstarten een UNIX-domeinsocket. De PCAP-reader (en andere programma's) kan de 3 soorten informatie op deze UNIX-domeinsocket plaatsen om de SPIN-daemon te informeren over de verschillende soorten netwerkactiviteit. extsrc injecteert deze berichten dan in het systeem.

Het diagram in Figuur 3 laat zien hoe alle onderdelen samenkomen. Rechtsboven wordt de uitwisseling tussen de kernel en de SPIN-daemon weergegeven. Dat bestond al vóór het werk dat we in deze blogpost beschrijven. De rest van het diagram toont (in blauw) de nieuwe onderdelen die in deze blogpost zijn geïntroduceerd: de UNIX-domeinsocket van de nieuwe voorziening extsrc en de PCAP-reader die van die socket gebruikmaakt om informatie met de SPIN-daemon te delen.

Conclusie en toekomstig werk

In deze blogpost hebben we een overzicht gegeven van hoe SPIN netwerkverkeer analyseert. Daarnaast hebben we je kennis laten maken met een manier waarop SPIN eerder opgeslagen netwerkverkeer kan analyseren, een nieuwe functie die we onlangs aan de opensourcesoftware van SPIN hebben toegevoegd. Samen zorgen SPIN's voorzieningen voor het vastleggen van live verkeer en de PCAP-reader ervoor dat het IoT transparanter wordt voor eindgebruikers.

We hebben al wat ideeën over hoe we de PCAP-reader in de toekomst kunnen verbeteren. Als we bijvoorbeeld ondersteuning toevoegen voor het uitvoeren van de PCAP-reader op een andere host dan de host van de SPIN-daemon, kunnen we de verzameling van live netwerkverkeer (door de PCAP-reader) scheiden van de analyse van netwerkverkeer (wat nog steeds wordt gedaan door de SPIN-daemon). Dat zou ons in staat stellen om een groot aantal verzamelingsknooppunten binnen een netwerk uit te voeren, waarna we de analyse zouden kunnen uitvoeren op een centraal knooppunt. Op dit moment is de PCAP-reader al in staat om naar een netwerkinterface te luisteren en wat daar wordt waargenomen te rapporteren aan de SPIN-daemon. Wat nog ontbreekt, is dat de PCAP-reader via het netwerk verbinding zou moeten kunnen maken met een actieve SPIN-daemon. Dat is een van de punten op ons verlanglijstje.

Een andere mogelijke verbetering, die eenvoudiger te implementeren zou zijn, is het regelen van de snelheid waarmee de PCAP-reader verkeer opnieuw afspeelt. In de huidige situatie speelt de PCAP-reader de pakketten opnieuw af op de geregistreerde snelheid of zo spoedig mogelijk. Een nieuwe optie zou bijvoorbeeld kunnen zijn dat pakketten 2 keer zo snel opnieuw worden afgespeeld.

We zijn ook van plan om te werken aan het optimaliseren van de PCAP-reader. Zoals we al beschreven, stuurt de PCAP-reader voor elk pakket een bericht naar de SPIN-daemon. Ten koste van enige complexiteit in de PCAP-reader kunnen we het aantal berichten dat moet worden uitgewisseld tussen de PCAP-reader en de SPIN-daemon aanzienlijk verminderen. In plaats van informatie over netwerkverkeer onmiddellijk te verzenden, zou de PCAP-reader bijvoorbeeld elke seconde een update kunnen sturen. Dan zouden we één bericht per seconde kunnen sturen in plaats van één bericht per pakket.

De PCAP-reader maakt deel uit van SPIN versie 0.12, dus klik op de link als je interesse hebt. We zijn benieuwd wat je ervan vindt! Laat het ons weten als je ons werk gebruikt of als je suggesties of opmerkingen hebt.