Qu'est-ce que le pare-feu LAN Socket Next Gen

Example Corp a 200 succursales mondiales qui utilisent le même design de réseau LAN. Cela inclut l'ID VLAN 10 pour les serveurs, et l'ID VLAN 20 pour les dispositifs OT critiques pour l'entreprise. L'équipe réseau décide de router le trafic entre ces VLAN localement, ce qui permet aux dispositifs OT et aux serveurs de continuer à communiquer même s'il y a une panne de l'ISP. En outre, ils souhaitent uniquement autoriser des protocoles spécifiques entre les VLANs.

L'équipe réseau crée une règle de réseau LAN avec le Site configuré comme un objet Groupe contenant les 200 sites pertinents, et le Transport configuré comme LAN pour router le trafic localement. Ensuite, ils créent une règle de pare-feu LAN sous la règle du réseau LAN, avec VLAN 10 et VLAN 20 configurés comme Source et Destination, et Direction en tant que Les deux. Sous Service/Port, ils configurent les protocoles qu'ils souhaitent autoriser, et l'Action est configurée comme Autoriser.

Cette règle unique de pare-feu LAN applique la politique à chacun des 200 réseaux locaux, sans avoir à configurer des règles séparées pour tous les sites.

Pour comprendre le rôle du pare-feu LAN et sa relation avec d'autres politiques Cato, il est important de comprendre que Cato identifie le trafic comme l'un des trois types différents : LAN, WAN ou Internet. Comprendre les distinctions et les caractéristiques de ces types de trafic est crucial pour une planification de politique optimale et l'utilisation des différentes politiques de pare-feu Cato. Pour plus d'informations, voir Commencer avec les pare-feu Cato.

Le trafic entre les hôtes au sein du même site peut être traité soit comme du trafic LAN (routé par le Socket et non envoyé au PoP), soit comme du trafic WAN (envoyé au PoP puis de retour au site), selon votre configuration. Le comportement par défaut pour le Socket est de router tout le trafic au PoP pour inspection et le PoP bloque ou autorise le trafic. Cependant, le trafic qui correspond à la politique de pare-feu LAN est routé localement et non envoyé au PoP.

Lorsque le trafic d'un hôte dans le LAN atteint le Socket, le Socket vérifie si le trafic correspond à une règle dans la politique de pare-feu LAN.

Pour plus d'informations sur la définition du trafic LAN, voyez ci-dessous, La Politique de déploiement du Pare-feu LAN.

Ce qui suit est un diagramme de machine d'état montrant comment le pare-feu LAN Socket gère le trafic d'un hôte sur le réseau local.

Le pare-feu LAN prend en charge l'inspection des couches 2 à 4 et de la couche 7 (couche application), vous permettant de contrôler le trafic en fonction des applications, services et contenu spécifique dans les applications. Par défaut, les sites prennent en charge la fonctionnalité de couche 2-4, et vous définissez dans la politique quels sites sont également activés avec des capacités de couche 7. Cette section décrit la différence entre le pare-feu de couche 2-4 et le pare-feu de couche 7.

Les pare-feux de couche 2-4 filtrent le trafic sur la base de critères de base tels que les adresses IP, les ports et les protocoles de la couche de transport comme TCP ou UDP. Pour ces critères, le pare-feu Socket peut décider de bloquer ou autoriser le trafic sur la base du premier paquet. Bien qu'efficace pour le contrôle de trafic de base, cette approche n'analyse pas les données réelles transmises dans les paquets.

Les pare-feux de couche 7 (couche application) inspectent la charge utile des paquets pour identifier des applications spécifiques, des domaines ou des protocoles. Par exemple, un pare-feu de couche 7 peut distinguer entre le trafic SMBv1 et SMBv3 ou identifier l'application spécifique générant le trafic (comme Office 365). Cette inspection plus approfondie permet une application de politique plus granulaire et un meilleur contrôle sur le trafic du réseau local. Cependant, parce que l'inspection de couche 7 nécessite l'analyse de paquets supplémentaires pour déterminer les données de l'application (par exemple, extraire un nom de domaine dans le trafic HTTP), et des ressources Socket plus importantes que le traitement de la couche 4. Cela doit être pris en compte lors de la planification de votre politique de pare-feu LAN d'entreprise et de la décision des sites à activer avec des capacités de couche 7.

Lorsque vous activez un site avec des capacités de couche 7, le Socket effectue une inspection approfondie des paquets sur le trafic, qu'une règle de Pare-feu LAN soit configurée ou non, tant qu'il y a un trafic défini pour utiliser le transport LAN (voir ci-dessous, La Politique de déploiement du Pare-feu LAN). Cela signifie que les données de couche 7 apparaissent dans les événements pour le trafic du site, y compris des champs tels que Application, Risque d'application et Application personnalisée.

Les règles de réseau LAN contrôlent quel transport (LAN ou WAN) est utilisé pour router le trafic entre divers hôtes ou segments de réseau. Il s'agit d'une politique globale configurée pour l'ensemble du compte, et non par sites spécifiques. Cela signifie que chaque règle peut être configurée pour s'appliquer à plusieurs sites du compte. Par exemple, si vous configurez plusieurs sites en utilisant la même configuration VLAN, vous pouvez créer une seule règle qui s'applique aux VLAN dans chaque site défini dans la règle.

Les règles de réseau LAN prennent des décisions de routage de couche 4 et n'utilisent pas la fonctionnalité de couche 7. Par exemple, vous pouvez définir des règles de réseau avec des conditions pour les sites, les VLAN ou les protocoles spécifiques, mais vous ne pouvez pas définir une condition basée sur l'application.

Une règle de réseau LAN peut être un parent de plusieurs règles de pare-feu LAN sous elle. Il y a une règle de blocage par défaut ANY-ANY configurée comme la dernière règle sous une règle de réseau LAN. Par conséquent, si le trafic correspond à une règle de réseau LAN, mais ne correspond pas à une règle de pare-feu LAN, il est bloqué.

Les règles de pare-feu LAN autorisent ou bloquent des types de trafic spécifiques, et suivent ces événements à des fins de surveillance et de conformité. Chaque règle de pare-feu LAN est directement liée à une règle de réseau LAN parent spécifique et est limitée à la portée du parent en termes de source et de destination. Les règles de pare-feu LAN prennent en charge jusqu'à la segmentation de couche 4 par défaut, y compris la segmentation basée sur les adresses MAC. De plus, pour les sites configurés pour la fonctionnalité de couche 7, les règles de pare-feu LAN peuvent inclure un filtrage intelligent du trafic basé sur des applications, des domaines et autres conditions de couche 7.

Il y a une règle de blocage par défaut ANY-ANY configurée comme la dernière règle sous chaque règle de réseau LAN. Par conséquent, si le trafic correspond à une règle réseau LAN mais ne correspond pas à une règle de Pare-feu LAN, il est bloqué. Ce comportement implicite impose une véritable approche de confiance zéro à la segmentation sur site en garantissant que seul le trafic explicitement autorisé peut traverser le réseau local.

Le compte des hits vous aide à identifier les règles inutilisées qui peuvent être supprimées d'une politique, et à optimiser la configuration des règles pour mieux correspondre à la portée du trafic requis. Le compte des hits pour une règle est basé sur le nombre d'événements générés par la règle. Si une règle ne génère pas d'événements, le compte des hits est zéro.

Le compte des hits contient deux nombres :

Ces valeurs sont mises à jour une fois toutes les 24 heures et sont basées sur les 14 derniers jours de trafic.

Vous pouvez rapidement identifier les règles avec le plus grand et le plus petit compte de hits, en fonction de la couleur de la barre de statut. Cette couleur reflète la fréquence à laquelle la règle est atteinte par rapport aux autres règles :

Réinitialisation et rafraîchissement du compteur de hits

Les valeurs de compte des hits sont mises à jour automatiquement toutes les 24 heures et sont basées sur les 14 derniers jours de trafic. À partir des trois points à la fin de chaque règle, vous pouvez réinitialiser ou rafraîchir le compte des hits pour une visibilité à jour. Cela vous permet de mesurer précisément l'efficacité des règles et de valider immédiatement l'activité des règles.

• Réinitialiser le compteur de hits pour une règle spécifique ramène le compte des hits à 0

• Rafraîchir le compteur de hits met à jour le compte des hits à la demande pour toutes les règles de politique