Comment évaluer l'efficacité de la configuration NGFW

La tâche la plus fréquente consiste à vérifier l'efficacité de votre pare-feu. Pour cela, il existe des outils et services gratuits proposés par des entreprises spécialisées dans les NGFW.

Par exemple, ci-dessous, on peut voir que l'entreprise Palo Alto Networks offre la possibilité directement depuis le portail de support de lancer une analyse des statistiques du pare-feu — rapport SLR ou analyse de conformité aux meilleures pratiques — rapport BPA. Ce sont des outils en ligne gratuits, qui peuvent être utilisés sans installation.

CONTENU

Expedition (Outil de migration)
Optimiseur de politiques
Zero Trust
Cliquons sur Unused
Cliquons sur Unused App
Cliquons sur No Apps Specified
Et qu'en est-il de l'apprentissage automatique
UTD

Expedition (Outil de migration)

Une option plus complexe pour vérifier vos configurations — télécharger un outil gratuit Expedition (anciennement Outil de migration). Il se télécharge comme appliance virtuelle sous VMware, aucune configuration n'est requise — il suffit de télécharger l'image et de la déployer sous l'hyperviseur VMware, de l'exécuter et d'accéder à l'interface web. Cet outil mérite un développement distinct, rien que le cours à son sujet dure 5 jours, tant il y a de fonctions actuellement, y compris l'apprentissage automatique et la migration de diverses configurations de politiques, NAT et objets pour différents fabricants de pare-feu. Je reviendrai sur l'apprentissage automatique plus en détail plus bas dans le texte.

Optimiseur de politiques

Et la solution la plus pratique (IMHO), dont je parlerai aujourd'hui en détail — l'optimiseur de politiques intégré directement dans l'interface de Palo Alto Networks. Pour le démontrer, j'ai installé un pare-feu chez moi et écrit une simple règle : permettre tout vers tout. En principe, je vois parfois de telles règles même dans des réseaux d'entreprise. Évidemment, j'ai activé tous les profils de sécurité NGFW, comme on peut le voir dans la capture d'écran :


Sur la capture d'écran ci-dessous, un exemple de mon pare-feu domestique non configuré est montré, où presque toutes les connexions tombent dans la dernière règle : AllowAll, ce qui est visible dans les statistiques de la colonne Hit Count.

Zero Trust

Il existe une approche de la sécurité appelée Zero Trust. Cela signifie que nous devons autoriser les connexions nécessaires pour les personnes au sein du réseau et interdire toutes les autres. En d'autres termes, nous devons ajouter des règles claires concernant les applications, les utilisateurs, les catégories d'URL, les types de fichiers ; inclure toutes les signatures IPS et antivirus, activer le sandboxing, la protection DNS, utiliser les IoC provenant des bases disponibles de Threat Intelligence. En somme, il y a un bon nombre de tâches à accomplir lors de la configuration d'un pare-feu.

À propos, l'ensemble minimum de configurations nécessaires pour le Palo Alto Networks NGFW est décrit dans l'un des documents SANS : Palo Alto Networks Security Configuration Benchmark — je recommande de commencer par cela. Et bien sûr, il existe un ensemble de meilleures pratiques pour la configuration du pare-feu de la part du fabricant : Best Practice.

Donc, j'ai eu un pare-feu à la maison pendant une semaine. Voyons quel trafic il y a dans mon réseau :


Si nous trions par nombre de sessions, le plus de sessions sont créées par bittorent, suivi de SSL, puis QUIC. Cela inclut des statistiques sur le trafic entrant et sortant : il y a beaucoup de scans externes de mon routeur. Il y a 150 applications différentes dans mon réseau.

Tout cela a été autorisé par une seule règle. Regardons maintenant ce que le Policy Optimizer en dit. Si vous avez regardé ci-dessus la capture d'écran de l'interface avec les règles de sécurité, vous avez vu en bas à gauche une petite fenêtre qui me suggère qu'il existe des règles qui peuvent être optimisées. Cliquons là-dessus.

Que montre le Policy Optimizer :

• Quelles politiques n'ont pas du tout été utilisées, depuis 30 jours, 90 jours. Cela aide à décider de les supprimer complètement.
• Quelles applications étaient indiquées dans les politiques, mais n'ont pas été trouvées dans le trafic. Cela permet de supprimer les applications inutiles des règles d'autorisation.
• Quelles politiques autorisaient tout, alors que des applications passaient réellement, qu'il serait préférable d'indiquer clairement selon la méthode Zero Trust.

Cliquons sur Unused.

Pour montrer comment cela fonctionne, j'ai ajouté quelques règles et elles n'ont pas encore autorisé un seul paquet aujourd'hui. Voici leur liste :

Il est possible qu'avec le temps, du trafic transite par là et qu'elles disparaissent de cette liste. Et si elles restent dans cette liste pendant 90 jours — vous pouvez décider de supprimer ces règles. Chaque règle représente une opportunité pour un hacker.

Il existe un véritable problème lors de la configuration d'un pare-feu : un nouvel employé, en consultant les règles du pare-feu, constate qu'il n'y a aucun commentaire et s'interroge sur la raison pour laquelle cette règle a été créée, si elle est réellement nécessaire, s'il est possible de la supprimer : que faire si quelqu'un est en congé et que, dans 30 jours, le trafic recommence à provenir du service qui lui est nécessaire ? Cette fonctionnalité l'aide donc à prendre une décision : personne ne l'utilise — supprimer !

Cliquons sur Unused App.

Nous cliquons dans l'optimiseur sur Unused App et voyons que des informations intéressantes s'ouvrent dans la fenêtre principale.

Nous constatons qu'il existe trois règles où le nombre d'applications autorisées et le nombre d'applications réellement passées par cette règle diffèrent.

Nous pouvons cliquer et voir la liste de ces applications et comparer ces listes.
Par exemple, cliquons sur le bouton Compare pour la règle Max.

Il est visible que les applications facebook, instagram, telegram, vkontakte ont été autorisées. Mais le trafic n'a réellement circulé que sur certaines sous-applications. Il faut comprendre que l'application facebook contient plusieurs sous-applications.

La liste complète des applications NGFW peut être consultée sur le portail applipedia.paloaltonetworks.com et dans l'interface même du pare-feu dans la section Objects->Applications, et dans la recherche tapez le nom de l'application : facebook, ce qui donnera ce résultat :

Ainsi, certaines de ces sous-applications NGFW ont été vues, tandis que d'autres ne l'ont pas été. En réalité, vous pouvez interdire et autoriser séparément différentes sous-fonctions de Facebook. Par exemple, autoriser la consultation des messages, mais interdire le chat ou le transfert de fichiers. Par conséquent, le Policy Optimizer en parle et vous pouvez décider : autoriser non pas toutes les applications de Facebook, mais seulement celles de base.

Ainsi, nous avons compris que les listes sont différentes. Vous pouvez faire en sorte que les règles n'autorisent que les applications qui ont réellement circulé sur le réseau. Pour cela, vous cliquez sur le bouton MatchUsage. Cela donne ceci :

Et vous pouvez également ajouter des applications que vous jugez nécessaires — le bouton Add dans la partie gauche de la fenêtre :

Ensuite, cette règle peut être appliquée et testée. Félicitations !

Cliquons sur No Apps Specified.

Dans ce cas, une fenêtre importante pour la sécurité s'ouvrira.

De telles règles, où l'application de niveau L7 n'est pas explicitement indiquée, sont probablement très nombreuses dans votre réseau. J'ai également une telle règle dans mon réseau — je me souviens l'avoir créée lors de la configuration initiale, spécialement pour montrer comment fonctionne le Policy Optimizer.

Sur l'image, on voit que la règle AllowAll a laissé passer un total de 220 Go de trafic entre le 9 et le 17 mars, alors qu'il y a en tout 150 applications différentes dans mon réseau. Et c'est encore peu. En général, un réseau d'entreprise de taille moyenne abrite entre 200 et 300 applications différentes.

Ainsi, une seule règle laisse passer pas moins de 150 applications. Cela signifie généralement que le pare-feu est mal configuré, car, en règle générale, une seule règle autorise entre 1 et 10 applications pour différents objectifs. Voyons quelles sont ces applications : cliquons sur le bouton Compare :

Le plus merveilleux pour un administrateur dans la fonction Policy Optimizer est le bouton Match Usage — vous pouvez créer, d'un simple clic, une règle qui inclut les 150 applications. À la main, cela prendrait un temps considérable. Le nombre de tâches pour un administrateur, même dans mon réseau de 10 appareils, est énorme.

J'ai chez moi 150 applications différentes qui transmettent des Go de trafic ! Et vous, combien en avez-vous ?

Que se passe-t-il dans un réseau de 100 appareils, 1000 ou même 10000 ? J'ai vu des pare-feu avec 8000 règles, et je suis très heureux que les administrateurs disposent maintenant de ces outils d'automatisation pratiques.

Certaines applications que j'ai vues et que le module d'analyse des applications L7 dans le NGFW a montrées ne vous seront pas nécessaires dans votre réseau, donc vous pouvez tout simplement les supprimer de la liste des règles autorisant, ou bien dupliquer les règles avec le bouton Clone (dans l'interface principale) et dans une règle autoriser les applications, tandis que dans l'autre, bloquer celles qui ne sont pas nécessaires dans votre réseau. Parmi ces applications, on trouve souvent bittorrent, steam, ultrasurf, tor, des tunnels cachés comme tcp-over-dns, et d'autres.

Et cliquons sur une autre règle — que pouvons-nous y voir :

Oui, ici se trouvent des applications typiques pour le multicast. Nous devons les autoriser pour que le streaming vidéo sur le réseau fonctionne. Cliquons sur Match Usage. Parfait ! Merci, Policy Optimizer.

Et qu'en est-il de l'apprentissage automatique ?

Il est actuellement à la mode de parler d'automatisation. Ce que j'ai décrit précédemment est très utile. Il existe une autre fonctionnalité dont je dois parler. C'est la fonctionnalité d'apprentissage automatique intégrée dans l'utilitaire Expedition, déjà mentionné ci-dessus. Dans cet utilitaire, il est possible de transférer des règles de votre ancien pare-feu d'un autre fabricant. De plus, il est possible d'analyser les journaux de trafic existants de Palo Alto Networks et de proposer quelles règles écrire. Cela ressemble à la fonctionnalité Policy Optimizer, mais dans Expedition, elle est encore plus étendue et une liste de règles déjà prêtes vous est proposée — il vous suffit de les approuver.
Pour tester cette fonctionnalité, il existe un laboratoire — nous l'appelons test drive. Ce test peut être effectué en accédant aux pare-feu virtuels, que les employés de Palo Alto Networks à Moscou mettront en service à votre demande.

Vous pouvez envoyer une demande à l'adresse Russia@paloaltonetworks.com en mentionnant dans votre demande : « Je souhaite faire le UTD sur le processus de migration ».

En réalité, il existe plusieurs versions de travaux de laboratoire appelés Unified Test Drive (UTD) et toutes sont disponibles à distance après demande.

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Voulez-vous que quelqu'un vous aide à optimiser les politiques de votre pare-feu?

• Oui

• Non

• Je le ferai moi-même

Personne n'a encore voté. Il n'y a pas d'abstention.

Source : habr.com