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

Présentation

Par défaut, le trafic LAN derrière un site est envoyé via le WAN au PoP pour inspection du trafic. Cela signifie que pour les hôtes derrière le même site, le trafic est envoyé via la dernière étape au PoP, puis renvoyé au même site. Vous pouvez également utiliser le Socket comme pare-feu LAN pour segmenter le trafic localement, sans avoir besoin d'un appareil de pare-feu tiers.

Le pare-feu LAN Socket Next Gen vous permet d'appliquer des contrôles de politique de la couche 2 à la couche 7 (couche application) au trafic est-ouest tout en routant et segmentant le trafic derrière le site. Le routage du trafic localement garantit également que des environnements critiques tels que OT et IoT peuvent continuer à fonctionner sur le réseau local, même si la connexion Internet est interrompue.

Le pare-feu LAN est une politique au niveau du compte qui vous permet de configurer des règles pour appliquer des politiques à l'échelle de l'entreprise sur plusieurs sites, sans configurer manuellement chaque site. Pour plus d'informations sur la configuration des Règles de pare-feu LAN de nouvelle génération, voir Gestion de la Politique de déploiement du Socket Pare-feu LAN de nouvelle génération.

La politique de pare-feu Socket Next Gen LAN au niveau du compte prend également en charge les sous-politiques et le contrôle d'accès basé sur les rôles (RBAC), vous permettant de déléguer la gestion de règles spécifiques à différents admins tout en gardant un contrôle centralisé sur le reste de la politique. En savoir plus ici.

Pour plus d'informations sur le débit du Pare-feu LAN de nouvelle génération pour différents Types de Socket, voir Seuils et Limites de Cato Cloud.

Cas d'Utilisation

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 obtenir des informations sur le débit du Pare-feu LAN de nouvelle génération pour différents Types de Socket, consultez cet article.

Pré-requis

• Le Socket Next Gen LAN Firewall est uniquement disponible pour les comptes qui n'ont pas de politique de pare-feu LAN de site actuelle configurée. À l'avenir, Cato convertira les politiques de pare-feu LAN de site actuelles en la politique de Socket Next Gen LAN Firewall.

• Supporté à partir de Socket v22 et vers le haut à l'Use Case

Concepts fondamentaux

Cette section explique les concepts de base pour comprendre le rôle et les capacités du pare-feu LAN de couche 7.

Types de trafic

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.

Trafic WAN vs LAN au sein du même site

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.

• Si cela correspond à une règle, le Socket route le trafic vers la destination locale sans l'envoyer au PoP.

• Si le trafic ne correspond pas à une règle de pare-feu LAN, il est envoyé au PoP pour être traité par le pare-feu WAN ou Internet.

Pour plus d'informations sur la définition du trafic LAN, voir ci-dessous, La Politique de 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.

Règles de pare-feu de couche 7 vs règles de pare-feu de couche 2-4

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 du trafic défini pour utiliser le transport LAN (voir ci-dessous, La Politique de 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.

La politique de pare-feu LAN

Le Socket applique la politique de pare-feu LAN en déterminant d'abord une décision de routage pour le trafic LAN - qu'il soit envoyé au PoP ou routé localement. Ensuite, les règles de pare-feu LAN sont appliquées pour déterminer si le trafic est bloqué ou autorisé.

Pour mettre cela en œuvre, la politique de pare-feu LAN comprend des règles de réseau LAN et de pare-feu LAN. Les règles de réseau LAN définissent comment le Socket route le trafic, localement sur le LAN, ou comme trafic WAN envoyé à un PoP. Une fois une règle de réseau LAN correspondante et définit le Transport comme LAN, les règles de pare-feu LAN associées déterminent si le trafic est autorisé ou bloqué, et le Socket applique la règle. Si le trafic ne correspond à aucune règle de réseau LAN, il est traité comme trafic WAN et envoyé au PoP.

Les règles de pare-feu LAN sont liées à une seule règle de réseau LAN, garantissant que les actions de pare-feu sont spécifiques au trafic défini par cette règle de réseau LAN.

Les sections suivantes décrivent les caractéristiques des règles de réseau LAN et de pare-feu LAN.

Règles réseau LAN

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 réseau LAN mais ne correspond pas à une règle de Pare-feu LAN, il est bloqué.

Règles de pare-feu LAN

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.

Sous-politiques

Une politique de pare-feu LAN est composée d'une politique principale et d'un nombre quelconque de sous-politiques. Toutes les règles qui ne sont pas à l'intérieur d'une sous-politique appartiennent à la politique principale lorsque vous définissez les permissions admin.

• Chaque sous-politique est ancrée par une règle de portée dans la politique principale. La règle de portée est une règle du réseau LAN dont les conditions (par exemple, Site Source = Paris) définissent quand les règles de la sous-politique sont appliquées au trafic.

• Une sous-politique contient ses propres règles réseau LAN ordonnées et ses règles de pare-feu LAN. L'action de la première règle correspondante est appliquée au trafic.

• Chaque sous-politique est traitée comme une entité séparée pour RBAC, vous permettant de donner aux différents admins Voir ou Modifier l'accès à différentes sous-politiques.

• Par défaut, une règle de nettoyage optionnelle ANY ANY est ajoutée à la fin de la sous-politique, utilisant l'action Bloquer pour correspondre au comportement par défaut de la politique de pare-feu LAN. Cette règle de nettoyage est uniquement appliquée au trafic qui correspond à la règle de portée de la sous-politique et ne correspond à aucune autre règle dans cette sous-politique.

• Vous pouvez ajouter des sections pour les règles à l'intérieur d'une sous-politique.

• Les sous-politiques ne peuvent pas contenir d'autres sous-politiques (aucun emboîtement).

• Vous ne pouvez pas déplacer des règles ou des sections entre des sous-politiques, ni entre une sous-politique et la politique principale.

• Un admin avec accès à une sous-politique peut voir sa règle de portée même s'il n'a pas accès à la politique principale.

• Les numéros de règles restent cohérents dans toute la politique, même lorsque certains admins ne peuvent pas voir certaines sous-politiques. En conséquence, les admins sans autorisations de vue pour des sous-politiques spécifiques peuvent voir des lacunes dans la numérotation des règles.

Note : Les règles à l'intérieur d'une sous-politique qui ont des conditions ANY sont uniquement appliquées au trafic qui correspond également à la règle de portée de la sous-politique. Cela signifie qu'une règle avec ANY ANY Block n'impacte pas le trafic qui ne correspond pas à la règle de portée.

Exemple : Une entreprise avec des équipes réseau régionales peut créer une sous-politique par région, définie par site source, afin que chaque admin régional gère uniquement les règles de pare-feu LAN pour ses propres sites et ne puisse pas modifier les règles appartenant à d'autres régions ou à la politique principale.

Publication des modifications

La politique de pare-feu LAN a une seule action Publier qui couvre la politique principale et toutes ses sous-politiques :

• Le nombre de modifications en attente est affiché comme un seul compteur à travers la politique principale et toutes les sous-politiques.

• La publication engage toutes les modifications en attente à travers la politique en une seule révision, y compris les modifications effectuées par d'autres admins dans les sous-politiques auxquelles vous n'avez pas accès.

• Un admin ayant accès à Modifier seulement certaines sous-politiques peut toujours modifier et publier leurs modifications autorisées.

Comprendre le compte des hits

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 nombre de 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 :

• Le nombre approximatif d'événements générés par chaque règle dans la politique de déploiement

• À quelle fréquence la règle est activée par rapport à d'autres règles (classées par percentile)

Ces valeurs sont mises à jour 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 :

• Bleu : 0 - 24ème percentile

• Vert : 25ème - 49ème percentile

• Orange : 50ème - 74ème percentile

• Rouge : 75ème -100ème percentile