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

Eén van de functies op een Palo Alto Networks Next Generation Firewall is Wildfire. Dit is een extra beveiliging tegen Malware bestanden die nog niet door virusscanners herkend worden.

Wildfire is er in 2 vormen. De standaard vorm die iedereen met een Palo Alto Networks firewall kan gebruiken en de gelicentieerde vorm daarvan.

Binnen de standaard vorm kunnen bestanden (onder andere .exe bestanden) die binnen de datastroom aangetroffen worden geüpload worden naar de Wildfire Cloud omgeving. Daar worden dergelijke bestanden uitgevoerd binnen een Sandbox. Binnen deze Sandbox wordt bijgehouden wat het bestand allemaal doet en wat er verandert. Op basis van de acties van het bestand wordt dan een oordeel geveld of het bestand malware is (Malicious) of niet (Benign).

Het onderzoek van de file wordt beschikbaar gemaakt via het support portal van Palo Alto Networks in een rapport. Vanzelfsprekend wordt de informatie die Palo Alto Networks op deze manier verzamelt gebruikt om de virusscanner engines en de URL filtering categorieën aan te passen.

De gelicentieerde vorm voorziet in dezelfde mogelijkheden als de standaard vorm. Daarbij is er echter de mogelijkheid om meerdere file-typen te laten onderzoeken (onder andere .pdf bestanden en .apk bestanden van Google Play). Daarnaast is het rapport is geïntegreerd in de interface van de Palo Alto Networks firewall (vanaf versie 6.0.0). De resultaten worden snel gepubliceerd door middel van Wildfire Dynamic Updates naar alle Palo Alto Network firewalls met licentie. Deze firewalls kennen hierdoor de malicious bestanden en zullen deze blokkeren.

Hoe stel je dit in

In deze blog laat ik zien hoe je Wildfire in kunt stellen op de firewall. Allereerst moet ingesteld worden welke cloud gebruikt wordt en welke gegevens er gelogd moeten worden.

Daarna moet er een Security Profile aangemaakt worden dat gebruikt kan worden binnen de Security Policies. Het onderstaande screenshot laat de instellingen zien om alle ondersteunde bestandtypes door te sturen naar de Wildfire Cloud. In dit geval worden alleen de gedownloade bestanden doorgestuurd, de geüploade bestanden worden buiten beschouwing gelaten.

Tenslotte moet dit Security Profile nog gekoppeld worden aan de security regel waar het verkeer doorheen loopt.

Deze settings zijn voldoende om Wildfire te laten werken.

Wat zie je gebeuren

Als de firewall nu een bestand tegenkomt dat niet bekend is zal het aangeboden worden aan de Wildfire Cloud. De acties daarvan zijn te zien in het ‘Data Filtering’ log.

Door de integratie met het support portal van Palo Alto Networks, mits de licentie is aangeschaft, zijn de resultaten ook terug te zien in de logging van de firewall. Deze zijn terug te vinden onder ‘Wildfire Submissions’.

Daarbij is het handig om de laatste kolom toe te voegen aan het overzicht, daardoor is in één oogopslag te zien of het om ‘Benign’ of ‘Malicious’ software gaat. Door middel van het vergrootglas aan het begin van de regel is het gehele rapport op te vragen.

Extra dynamische updates

Zoals gezegd zal een firewall met licentie een voordeel hebben, doordat deze sneller op de hoogte wordt gebracht van malicious files. Stel dat iemand op de wereld de file al een keer gedownload heeft door een Palo Alto Networks firewall heen, dan zullen alle andere Palo Alto Networks firewalls deze file ook blokkeren. De frequentie waarmee deze dynamische update wordt opgehaald is in te stellen onder de normale dynamische updates.

Als het niet werkt?

Natuurlijk hoort bij al deze instellingen ook nog de controle of één en ander goed werkt. Via de CLI kan dit gedaan worden met onder andere het onderstaande commando.

Wat te doen!

Felton adviseert al haar klanten om, ook al heb je geen licentie, Wildfire aan te zetten. De input die Palo Alto Networks ontvangt uit deze bestanden wordt namelijk ook gebruikt om het URL filter en de Anti Virus Engine van Palo Alto Networks te verbeteren. Daarnaast adviseren wij ook om, als je je zorgen maakt over geavanceerde malware, de licentie aan te schaffen. Op die manier is een netwerk zo snel en zo goed mogelijk beschermd.

Hulp of advies nodig? Wij staan u graag te woord!

Auteur: Rian van Weeghel – Security Consultant Felton BV