DNS sinkholing is een methode waarbij de Palo Alto Networks firewall ingrijpt in DNS verkeer en ervoor zorgt dat verdachte DNS verzoeken niet goed geresolved kunnen worden. Dit biedt extra beveiliging voor apparatuur in het netwerk. Door het gebruik van deze methode kan apparatuur namelijk niet bij malafide sites komen. DNS sinkholing wordt weliswaar vaak ingericht, maar niet optimaal. Vanuit onze ervaring en expertise demonstreren wij u graag de manier waarop wij dit inrichten.
De basis
In een typisch netwerk worden de volgende stappen ondernomen bij een DNS verzoek: Stap 1: een client vraagt aan de lokale DNS server om een bepaalde Fully Qualified Domain Name (FQDN) te resolven. Stap 2: dde DNS server vraagt deze FQDN (als hij niet in de cache zit) zijn upstream aan DNS server. Stap 3: de upstream DNS server antwoordt met het bijbehorende IP adres. Stap 4: de lokale DNS server neemt de FQDN op in zijn cache en het bijbehorende IP adres wordt doorgeven aan de client. Als DNS sinkholing aan wordt gezet op de firewall, wordt communicatiestroom 2 geïnspecteerd en wordt communicatiestroom 3 mogelijk aangepast.
Hieronder volgen de stappen waarmee dat gedaan wordt
Eerst moet er een anti-spyware profiel aangemaakt worden, meestal wordt daarvoor 1 van de bestaande profielen gekloond. Binnen dit profiel wordt vervolgens de DNS sinkholing functie aangezet.
Het genoemde IP adres is het adres dat de firewall gebruikt om verzoeken voor malafide FQDN’s te beantwoorden. Het IP adres dat hier gebruikt wordt (192.0.2.192) is een adres dat speciaal voor documentatie en testdoeleinden gebruikt mag worden. Het adres komt dus niet op internet voor en komt (als het goed is!) ook niet voor in interne netwerken bij bedrijven. Hierna moet dit profiel toegepast worden op de policy die het DNS verkeer vanaf de interne server toestaat richting internet. In dit geval is dat deze regel.
Door het toepassen van het profiel zal de firewall als er een malafide aanvraag voorbij komt ingrijpen. Stap 2 is dat het DNS proces afgebroken wordt, gevolgd door het zelf antwoorden via stap 3 met het ingestelde adres. Hiernaast staan 2 DNS queries naar de interne server, eerst voor een normale FQDN en daarna voor een malafide FQDN.
De malafide FQDN (stap 2) wordt keurig afgevangen en de firewall antwoord met het ingestelde adres naar de interne server toe (stap 3). Deze geeft dit adres vervolgens door aan de client (stap 4). Eén en ander is ook terug te zien in de threatlog op de firewall:
De daadwerkelijke gebruiker/PC achterhalen
Het vervelende hieraan is natuurlijk dat volgens bovenstaande log degene die de verkeerde FQDN heeft aangevraagd de interne DNS server is. Dat is volgens de firewall namelijk ook degene die dat daadwerkelijk gedaan heeft (stap 2). De PC die het oorspronkelijke verzoek gedaan heeft voor de malafide FQDN zal nadat hij hier antwoord op heeft gekregen vanuit de firewall en lokale DNS server (dus het 192.0.2.192 antwoord) proberen te communiceren met dat adres in plaats van het adres dat wereldwijd is geregistreerd in de DNS systemen. In de firewall is het vervolgens dan ook heel eenvoudig om te achterhalen wie er uiteindelijk met dit IP adres heeft gecommuniceerd. Hierdoor is te achterhalen welke machines er bijvoorbeeld geïnfecteerd zijn met een botnet dat gebruik maakt van een malafide FQDN’s.
Als voor dit soort verkeer een aparte policy wordt gemaakt waarop e-mail logging aan staat, is het zelfs mogelijk om op het moment dat een PC een malafide FQDM opvraagt een email te krijgen met de log waarin dan de naam van de eindgebruiker staat.
Op deze manier is het mogelijk om heel snel te reageren op het moment dat een machine in het netwerk besmet is en probeert niet vertrouwde websites op internet te benaderen.
Auteur: Rian van Weeghel – Security Consultant Felton BV