Sécurité DNS

DNS Security est une fonction du pare-feu dans le nuage qui assure la protection des services DNS.

Le DNS est l'un des protocoles internet les plus utilisés pour la plupart des services, ce qui le rend vulnérable aux attaquants qui cherchent à l'exploiter. Ces attaquants utilisent des sites d'hameçonnage, des serveurs C&C et des logiciels malveillants sur des domaines New qui ne sont pas encore signalés comme malveillants. Par exemple, les domaines nouvellement enregistrés (NRD), les domaines générés par un algorithme (DGA), etc. Les attaquants peuvent également tenter de commander et de contrôler (C&C) et d'exfiltrer des données par le biais d'un tunnel DNS en utilisant un logiciel sur un hôte infecté pour encoder un contenu supplémentaire dans une requête DNS.

Cette fonction vous permet d'identifier et de bloquer les requêtes DNS malveillantes. Vous pouvez appliquer le blocage de domaine de manière catégorique pour empêcher vos utilisateurs de se connecter à des domaines dangereux. Cela vous permet d'arrêter ou de bloquer les connexions aux domaines nouvellement enregistrés (NRD), aux domaines DGA et à d'autres domaines qui ne sont pas encore considérés comme malveillants. Vous pouvez également autoriser ou bloquer les tunnels DNS et vous protéger contre les transferts de données non autorisés utilisant ces tunnels. Netskope met à jour la base de données des menaces toutes les 15 minutes pour protéger vos données contre les menaces les plus récentes.

Les serveurs DNS qui refusent de répondre sont traités comme des serveurs inaccessibles et résolus par Netskope DNS. Lorsque "Tout le trafic" est dirigé vers la plateforme Netskope SSE, que ce soit par le biais du client ou en utilisant des tunnels GRE ou IPSec, Cloud Firewall inspectera les paquets et identifiera les requêtes DNS envoyées sur des protocoles TCP ou UDP, permettant ainsi une sécurité DNS sur les requêtes DNS qui utilisent des ports non standard.

Les principales étapes de la configuration de la sécurité DNS sont les suivantes :

Une fois votre politique activée, toutes les menaces DNS détectées sont enregistrées dans les alertes. Si une configuration DNS de journalisation complète est définie à des fins de débogage, ces événements sont alors capturés sous Événements réseau.

Sécurité du DNS par le biais de la Netskope Client

Le site Netskope Client est capable d'orienter les requêtes DNS initialement destinées à un serveur DNS interne si les configurations d'orientation appropriées sont en place. Essentiellement, nous voulons configurer le contournement de pilotage par défaut "Plage d'adresses IP locales" sur "Contournement, sauf pour le trafic DNS" :

Le site Netskope Client est également capable d'exécuter des exceptions basées sur le contenu de la requête DNS elle-même. Ces exceptions sont appelées exceptions de pilotage "DNS" et indiquent au NSClient d'envoyer des requêtes directes correspondant au type d'enregistrement et au domaine configurés :

Les exceptions DNS sont obligatoires pour tous les domaines internes, car tous les domaines internes doivent être résolus par le serveur DNS local et, à ce titre, ils ne doivent pas être dirigés.

La sécurité DNS peut être activée uniquement pour le pilotage du "trafic Web". L'idée sous-jacente est que DNS Security peut être utilisé par les clients qui ne souhaitent pas utiliser d'autres fonctionnalités de CFW. Cette fonction est également très utile pour migrer par étapes de "Trafic Web" à "Tous les trafics".
La sécurité DNS peut également être activée ou désactivée lors de la gestion de "Tout le trafic" et peut être configurée de manière granulaire lorsque la gestion dynamique est activée.

Considérations sur l'IA générative

Le sinkholing DNS est une technique de sécurité qui redirige les requêtes DNS malveillantes vers une adresse IP contrôlée, souvent appelée « gouffre ». Cette méthode empêche les utilisateurs de se connecter à des domaines nuisibles en résolvant leurs requêtes à une IP qui fournit des messages d’avertissement ou enregistre l’activité, permettant aux organisations de surveiller et d’analyser les menaces potentielles.

Les événements associés à l'IA générative seront couverts par les cas suivants :

Case 1

Si GenAI est réglé sur Block et que les sous-catégories sont autorisées, tout domaine correspondant à la sous-catégorie et à la catégorie principale sera bloqué.

Case 2

Avec un GenAI sinkhole et la sous-catégorie GenAI autorisée, toutes les catégories et sous-catégories GenAI seront Sinkhole et les applications/catégories seront affichées en tant que GenAI, dans les autres catégories en tant que sous-catégories.

Case 3

Avec GenAI réglé sur Allow et la sous-catégorie GenAI réglée sur Block ou Sinkhole, les domaines dans les sous-catégories GenAI, les événements du réseau affichent les sous-catégories dans les événements, dans les options de l'application/catégorie et les autres catégories comme GenAI.

Case 4

Avec GenAI réglé sur Block, une sous-catégorie Sinkhole et une autre sous-catégorie Block, toutes les actions Block, app/category affiche GenAI et d'autres catégories en tant que sous-catégorie.

Comme l'action Sinkhole a la priorité la plus élevée : pour Sinkhole, l'application/catégorie affiche la GenAI - les sous-catégories et les autres catégories affichent la GenAI.

Case 5

Pour tous les événements du réseau Allow, l'application/catégorie affiche GenAI, et aucune sous-catégorie n'est affichée dans l'action Allow car il n'y a pas d'autre champ de catégorie.