Hoe werkt privacyvriendelijke DNS-logging op de resolvers van SURFdomeinen?

Om mogelijke aanvallen en besmettingen beter te kunnen detecteren en opsporen, is het handig om DNS-logging te kunnen doorzoeken. Omdat DNS-logs privacygevoelig zijn, heeft SURF een systeem ontwikkeld waarbij het mogelijk is om DNS-data met zo veel mogelijk behoud van privacy van de eindgebruikers te loggen. In deze blog leg ik uit hoe deze privacyvriendelijke DNS-logging technisch werkt.

Aanleiding privacyvriendelijke DNS-logging

Als een bij SURF aangesloten instelling getroffen is door een cyberaanval, willen andere instellingen weten of de daders mogelijk ook hun infrastructuur zijn binnengedrongen. Een van de bronnen om te raadplegen zijn DNS-logs: overzichten van domeinnamen die door eindgebruikers of systemen zijn opgevraagd. Veel instellingen gebruiken de DNS-servers van SURF via SURFdomeinen en daarvoor werden deze logs eerder niet vastgelegd. Op verzoek van de instellingen heeft SURF een systeem ontwikkeld om dit doen, maar met zo veel mogelijk behoud van privacy van de eindgebruikers.

Privacy-by-design

Hoewel de DNS-verzoeken nuttig kunnen zijn voor het beschermen van de gebruikers van het SURF-netwerk, zijn ze ook privacygevoelig. Ze laten bijvoorbeeld zien welke websites een gebruiker heeft bezocht. Het is daarom belangrijk om zorgvuldig met deze data om te gaan en een privacy-by-design-aanpak te volgen bij het beschikbaar stellen van DNS-logging.

Om beveiligingsproblemen te detecteren hoeven we niet alle DNS-verzoeken van een individuele gebruiker te weten; we hoeven alleen te weten welke gebruikers een kwaadaardige domeinnaam hebben opgevraagd. We hebben daarom een systeem ontwikkeld waarbij we precies dit afdwingen met behulp van cryptografische technieken: het is alleen mogelijk om in de DNS-logging te zoeken op basis van een domeinnaam. We slaan echter niet de opgevraagde domeinnaam op, maar alleen afgeleide informatie hiervan, gebaseerd op een zogenaamde hash. We combineren deze hash met een geheime sleutel, zodat alleen personen met toegang tot deze sleutel de benodigde hash kunnen berekenen (voor de kenners: we gebruiken HMAC-SHA256).

Logdata veilig opgeslagen door middel van hashing

Met een hash-algoritme kan voor een gegeven tekst (zoals een domeinnaam) een schijnbaar willekeurige code worden berekend. Dit werkt echter niet de andere kant op: voor een code kan je niet eenvoudig terugrekenen welke tekst hierbij hoort. Je kan dus wel makkelijk berekenen dat voor surf.nl de bijbehorende hash 92A406...683887 is, maar je kan dus niet zomaar achterhalen welke domeinnaam hoort bij de hash C75871...93D2B2.

Het systeem slaat de informatie over de gebruiker versleuteld op – met behulp van het cryptografische algoritme ChaCha20Poly1305. Deze informatie kan alleen worden ontsleuteld als deze gebruiker een domeinnaam heeft opgevraagd waarnaar gezocht wordt in het systeem. De sleutel die wordt gebruikt om de gebruikersinformatie op te slaan, berekenen we namelijk door een geheime sleutel te combineren met de opgevraagde domeinnaam. Als je deze domeinnaam niet weet, kan je de benodigde sleutel niet achterhalen en de gebruikersinformatie dus niet ontsleutelen.

In Figuur 1 zie je een voorbeeld van de informatie die we opslaan. De opgevraagde domeinnaam (malware.evil.nl) en het hoofddomein (evil.nl) worden zodanig opgeslagen dat deze niet meer kunnen worden ontsleuteld (ook niet met de rode respectievelijk groene sleutel) en alleen kunnen worden gebruikt voor het opzoeken van data. Om de informatie over de client (192.0.2.123) die de domeinnaam heeft opgevraagd te kunnen ontsleutelen is zowel de blauwe sleutel als de opgevraagde hoofddomeinnaam (evil.nl) nodig om de benodigde gele sleutel te kunnen berekenen. Het is later dus wel mogelijk om op te zoeken wie malware.evil.nl heeft opgevraagd, maar niet welke domeinnamen de gebruiker met IP-adres 192.0.2.123 allemaal heeft opgevraagd.

De domeinnaam malware.evil.nl wordt gehasht samen met een rode sleutel, evil.nl wordt gehasht samen met een groene sleutel, evil.nl wordt met een paarse sleutel combineerd tot een gele sleutel die vervolgens wordt gebruikt om het IP adres 192.0.2.123 te versleutelen. Deze hashes en versleutelde data worden samen met het tijdstip opgeslagen in de database.
Figuur 1: Voorbeeld van de opgeslagen data

Procedurele maatregelen om privacy van eindgebruikers te beschermen

Verder treffen we nog een aantal procedurele maatregelen om de privacy van eindgebruikers zo veel mogelijk te beschermen: alleen leden van SURFcert krijgen toegang tot het systeem, en alle zoekopdrachten in het systeem worden bijgehouden in een auditlog. Dit auditlog zal regelmatig worden nagelopen, waarbij degene die de zoekopdracht heeft uitgevoerd moet verantwoorden waarom deze is uitgevoerd. Verder worden alle logdata maximaal negentig dagen bewaard.

Met deze technische en procedurele maatregelen hebben we een systeem ontwikkeld dat SURFcert de mogelijkheden geeft om beveiligingsproblemen op te sporen, terwijl we tegelijk de privacy van de gebruikers zoveel mogelijk beschermen doordat het gedrag van individuele gebruikers niet kan worden gevolgd.

Auteur

Reacties

Dit artikel heeft 0 reacties