Comprendre le flux de paquets avec l'architecture Cato SPACE

Cet article explique le flux des paquets pour les moteurs de sécurité dans le PoP basé sur l'architecture Single Pass Cloud Engine (SPACE) de Cato.

Vue d'ensemble

L'architecture SPACE de Cato examine et traite les flux de trafic avec un service unique. Ce service comprend plusieurs moteurs de réseau et de sécurité qui analysent et traitent simultanément les flux de trafic. Cette architecture évite les limitations de la combinaison de plusieurs solutions ponctuelles avec le chaînage de services. Le passage unique pour un flux minimise la latence et améliore les performances globales du réseau. Chaque PoP peut effectuer ces décisions de réseau et de sécurité en utilisant tous les services et moteurs SPACE de Cato.

Les moteurs de sécurité et de réseau ont un accès complet aux données pour le flux de trafic et évaluent simultanément et partagent les données entre eux avec un contexte partagé. Les moteurs fonctionnent en parallèle, il n'y a pas de priorité pour qu'un moteur évalue le trafic par rapport à un autre. Les moteurs sont situés dans chaque PoP et peuvent partager les données sans attendre les informations d'un moteur dans un autre emplacement physique.

Par exemple, une règle de pare-feu bloque les appareils macOS, cependant le moteur de pare-feu ne peut pas obtenir ces données à partir du premier paquet et attend plus de données. Lorsqu'un autre moteur identifie l'appareil comme macOS, alors le pare-feu bloque le flux conformément à l'action de la règle.

Résumé des services réseau et de sécurité SPACE

Cette section répertorie les services et moteurs réseau et de sécurité dans le PoP qui sont appliqués aux différentes phases du flux de paquets.

Politiques et moteurs Cato
- Pare-feu - Politique de pare-feu pour les pare-feux Internet et WAN
- Réseau - Politique des règles réseau pour le routage et la priorité QoS
- IPS/SAM - Protections IPS et Surveillance d'activité suspecte (SAM)
- Contrôle d'application - Identification des applications pour la politique de contrôle d'application
  - Contrôle d'application gen2 - Règles pour les applications basées sur l'accès : autoriser ou bloquer
  - Contrôle d'application gen3 - Règles pour les applications basées sur des actions granulaires : téléversement, téléchargement, et ainsi de suite
- TLSi - Inspection TLS pour le trafic HTTPS et chiffré
- DLP - Inspection de contenu pour la politique de Protection contre la perte de données (DLP)
- AM/NGAM - Anti-Malware et Next-Gen Anti-Malware scannant les fichiers attachés pour les logiciels malveillants
Données de flux de trafic et protocoles
- Identification des applications - Divers critères sont utilisés pour identifier l'application spécifique pour les politiques de sécurité ou de réseau
- OS - Système d'exploitation (OS) pour l'appareil, par exemple avec la Politique de Posture de l'Appareil ou la Politique de Connectivité Client
- Classe Client - Type d'applications clients qui s'exécutent sur le système d'exploitation qui a créé ce flux réseau (par exemple, Chrome)
- URLF - Filtrage URL pour les catégories Cato basé sur l'URL du site Web
- File_type - Pour CASB et DLP, pièce jointe de fichier dans la direction du téléversement ou du téléchargement

Flux de paquets TCP avec SPACE

Ceci est un exemple d'un flux HTTP typique avec les éléments suivants :

Chronologie - Différentes phases du flux de trafic
Champs disponibles - Données disponibles pour la phase de chronologie spécifique
Moteur Cato - Moteur SPACE capable d'analyser le flux et ensuite de prendre l'action appropriée (bloquer ou autoriser)
Données de flux de trafic - Pour chaque phase, données utilisées pour évaluer le flux de trafic

Vous pouvez voir une liste des détails ci-dessous, Détails d'un exemple de flux TCP.

Exemple d'identification d'application à partir d'un flux de trafic

Ceci est un exemple de flux de trafic pour une règle qui inclut l'application Slack, et montre les informations disponibles à chaque étape.

Premier paquet - TCP
```
Source - 10.10.2.107
Port source - 55477
IP de destination - 3.68.124.168
Port de destination - 443
Protocole - TCP
Réponse DNS - 3.68.124.168 - slack.com (réponse optionnelle)
```
Ceci est l'information de flux de trafic disponible basée sur ce premier paquet d'exemple :
- 5 tuple - ne peut pas identifier que le trafic est connecté à l'application Slack
- Réponse DNS - Basé sur les flux précédents, les moteurs savent déjà que le nom de domaine pour cette IP de destination est slack.com
- ASN - basé sur l'IP de destination, le moteur de sécurité peut identifier l'ASN
- Identification des applications inclut : tcp
Le moteur attend des informations supplémentaires du handshake TLS avant de pouvoir terminer l'identification de l'application Slack.
handshake_tls
```
"En-tête TLS"
"hôte_sni": "slack.com"
"raison de l'exception d'inspection prédéfinie": "aucune"
"chaîne_formatée_ja3": "771,4865-4866-4867-49195-49199-49196-4920…"
```
Ceci est l'information de flux de trafic disponible basée sur cet exemple de handshake_tls :
- En-tête TLS et port serveur 443 - correspond au protocole TLS
- SNI est slack.com - correspond à l'identification de l'application Slack de Cato
  
  SNI est également envoyé au filtrage URL, et correspond aux catégories Informations professionnelles, Informatique et technologie, Réseaux sociaux
- Classe Client est JA3 - classe le client comme un navigateur basé sur l'empreinte TLS
- Inspection TLS ou action de contournement - basée sur la Classe Client et l'identification de l'application
- Identification des applications inclut : tcp, tls, slack
HTTP
```
"url" : "upload.slack.com:
"nom_hôte" : "slack.com"
"Type de contenu" : "application/pdf"
"Disposition du contenu" : form-data; nom="fichier"; nom_fichier="sample-data.pdf"
"Longueur du contenu" : "52765"
```
Dans cet exemple de flux, les informations suivantes sont disponibles basées sur les données HTTP :
- Identification des applications inclut : tcp, tls, http, slack
- Inspection TLS décrypte le flux et identifie que le nom_hôte du serveur Slack est slack.com
- En-tête HTTP - correspond au protocole HTTP
  
  Ceci est un exemple courant où l'hôte_HTTP correspond au SNI, et il n'y a pas de changement pour l'identification de l'application
- URL - le préfixe d'upload fournit plus de granularité, et peut correspondre à l'action de téléversement dans la Politique de Contrôle d'Application
- Type de contenu, Disposition du contenu, Longueur du contenu - fournissent des informations sur le nom, la taille, et le type de fichier
- Actions de la Politique de Contrôle d'Application :
  - Appliquer une politique n'utilisant que le locataire Slack de l'entreprise
  - Contrôle de fichier basé sur le type de fichier
    
    Anti-Malware et NG Anti-Malware ne scannent les fichiers que dans la direction du téléchargement.
Corps HTTP
```
"Corps HTTP payload" : "Le Fichier lui-même"
```
Par exemple, la politique DLP applique l'interdiction d'utiliser des données de carte de crédit dans les messages Slack.
- L'identification de l'application est complétée pour l'application Slack. Il est identifié comme un trafic appartenant à la Catégorie social.
- Lorsque le contenu du fichier est prêt, ces moteurs analysent le contenu du fichier :
  - Le moteur DLP scanne le contenu basé sur la Politique de Contrôle des Données
  - Anti-Malware et NG Anti-Malware scannent les fichiers dans la direction du téléchargement

Politiques et Moteurs Cato

Cette section explique la politique de sécurité Cato et les moteurs qui analysent et agissent sur le flux de trafic.

Politiques de pare-feu et de réseau

Les politiques de Pare-feu WAN, de Pare-feu Internet, et de Règles Réseau sont souvent capables d'évaluer un flux de trafic sur le premier paquet. Par exemple, des règles basées sur les données du 5-tuple. Cependant, pour les règles qui correspondent à des applications spécifiques, telles que Azure ou Slack, des données supplémentaires du flux de trafic sont nécessaires pour que le moteur évalue le flux. Cela signifie que la phase à laquelle le moteur évalue le flux dépend des paramètres de la règle spécifique.

Pour plus d'informations sur les types de règles de pare-feu, voir Internet et WAN Firewall Policies – Best Practices.

Exemple de premier paquet pour règle réseau simple et règle de pare-feu complexe

Cet exemple montre comment les moteurs PoP évaluent un flux de trafic différemment pour une règle réseau simple qui utilise des adresses IP et des ports, et une règle de pare-feu complexe pour les applications Azure. Le moteur réseau est capable d'évaluer le flux basé sur le premier paquet, mais le PoP attend les données supplémentaires pour que le moteur de pare-feu finalise son analyse.

Exemple de Règle Réseau

La règle réseau suivante concerne le trafic pour la Source comme une Plage d'adresses IP avec la plage de ports 8000 - 8010, et le trafic est évacué via l'emplacement PoP de Londres.

Le moteur de réseau est capable d'évaluer la décision de routage pour le flux de trafic basé sur le 5-tuple.

Exemple de Règle de Pare-feu WAN

La règle de pare-feu WAN suivante autorise le trafic qui a la même Source que la plage d'adresses IP pour la règle réseau ci-dessus, et pour les utilisateurs qui sont membres du groupe d'utilisateurs RnD. De plus, la règle concerne les applications Azure pour les services HTTP(S), TLS, FTP, et TFTP.

Le moteur de pare-feu ne peut pas évaluer le trafic sur le premier paquet, car il doit confirmer l'identité de l'utilisateur, les applications Azure, et les services pour le flux. Une fois que le moteur termine l'évaluation et que le flux répond à tous les critères, le moteur autorise le flux. Le PoP applique également la décision de routage basée sur le premier paquet.

Filtrage URL et Catégories Cato

Le service de filtrage URL fonctionne en analysant l'URL d'un site Web et en la comparant à une base de données de sites Web connus ou suspectés malveillants ou inappropriés. Ce service peut également analyser le contenu du site Web lui-même pour déterminer ses catégories, telles que le contenu pour adultes, les jeux d'argent, les réseaux sociaux, ou les médias en streaming.

Pour plus d'informations sur les catégories, voir Working with Categories.

Inspection TLS

Le moteur d'Inspection TLS est impliqué lors de la phase tls_handshake du flux de paquets. La décision d'inspecter ou non le flux est irréversible et se déroule en deux étapes :

Étape 1 - La première charge utile du paquet client_hello donne une indication initiale si le moteur d'Inspection TLS va inspecter ce flux de trafic
Étape 2 - Le client_hello est entièrement analysé, et l'action de la politique d'Inspection TLS est appliquée (inspecter ou contourner le flux)

Pour les flux HTTPS, il est possible qu'il y ait une décision de bloquer le paquet basé sur l'étape 1. Cependant, le moteur continue de communiquer et d'établir une connexion TLS pour présenter la bonne page de blocage de pare-feu ou IPS à l'utilisateur final.

IPS

Le moteur IPS continue de fonctionner pendant la durée de vie du flux de trafic. Il inspecte des articles spécifiques disponibles à différentes étapes, et intervient sur le contenu qui correspond positivement à une Protection IPS. Vous pouvez considérer l'IPS comme une loupe, toujours en attente de mises à jour du trafic et fournissant continuellement des informations au moteur observé sur le flux.

L'exemple suivant montre différentes informations disponibles à différentes étapes du flux :

Le protocole du flux est HTTP
Basé sur la charge utile, il y a du TLS
Il y a un client_hello qui utilise la suite de chiffrement TLS 1.3 TLS_AES_256_GCM_SHA384

Différentes protections IPS peuvent correspondre à n'importe n'importe lequels des éléments ci-dessus, puis agir sur le flux de trafic à cette phase.

Protection DNS

La Protection DNS fait partie du moteur IPS et fonctionne sur le flux DNS pour la demande et la réponse (sans aucune connexion au transport, par exemple TCP ou UDP).

Pendant la demande DNS, le nom de domaine est analysé et évalué pour la réputation du domaine et les flux statiques. Puis, lors de la réponse DNS, l'IP résolue et le contenu sont analysés pour un contenu potentiellement malveillant. La politique de Protection DNS est appliquée à tout contenu correspondant (bloquer ou autoriser le flux de trafic).

Contrôle d'Application

Le moteur de Contrôle d'Application inspecte le trafic et applique les actions pour la politique de Contrôle d'Application, et il est évalué à chaque nouvelle transaction HTTP (demande et réponse).

Pour les applications gen2, un proxy TLS et HTTP est requis pour compléter l'identification de l'application.

Pour les règles qui incluent les exigences de sécurité et de conformité :

En se basant sur les données contextuelles d'autres moteurs de réseau et de sécurité, le moteur de Contrôle d'Application peut évaluer ces exigences lors de la phase tls_inspection
Il est également possible que le moteur puisse obtenir cette information depuis le SNI, et n'a pas besoin du TLS ou de l'identification complète de l'application (DPI de couche 7) pour évaluer l'application

DLP

Le moteur DLP inspecte le contenu du flux de trafic et est une extension du moteur de Contrôle d'Application. Lorsque la politique spécifie un type de fichier ou une taille de fichier, le moteur doit alors inspecter les métadonnées de l'application et la charge utile pour ces caractéristiques de fichier :

Le moteur évalue le type de fichier et vérifie s'il correspond à la liste des fichiers pris en charge pour l'inspection du contenu.
Ensuite, l'identification de l'application gen3 est finalisée pour identifier les signatures de contenu spécifiques pour les champs qui stockent le contenu et les données inspectés.
Le contenu est inspecté et vérifié pour voir s'il correspond au profil de contenu défini.

Anti-Malware et NG Anti-Malware

Les moteurs Anti-Malware et SentinelOne NG Anti-Malware scannent les pièces jointes de fichier sur le trafic entrant (téléchargement de fichiers) pour les malwares connus et inconnus. Le type de fichier est basé sur la réponse HTTP, ou la demande pour le trafic FTP.

Seules les applications et services HTTP, HTTPS et FTP sont scannés.

Le moteur vérifie si l'application correspond à une règle dans la politique Anti-Malware.
Le fichier est comparé à ces listes de fichiers :
1. La List d'autorisation configurée dans l'Application de gestion Cato - ces fichiers sont autorisés à être téléchargés.
2. La liste de blocage gérée par l'équipe de sécurité Cato - ces fichiers sont bloqués.
Les fichiers sont scannés par les moteurs Anti-Malware et NG Anti-Malware, et le verdict est rendu : malveillant, suspect ou bénin.
L'action appropriée pour la politique Anti-Malware est appliquée au fichier.

FAQ pour Politiques et Moteurs Cato

Le Filtrage d'URL s'applique-t-il au trafic WAN ?

Non, le Filtrage d'URL est uniquement pour le trafic Internet et n'est pas appliqué au trafic de compte sur le WAN.

Quelle est la différence entre les paramètres de Restriction Géographique pour les politiques de pare-feu et les politiques IPS ?

Le paramètre Dispositif dans les pare-feux WAN et Internet vous permet de définir le pays d'origine pour les règles granulaires. Cependant, il n'y a pas de contrôle sur le pays de destination.

L'onglet Restriction Géographique dans la politique IPS définit le trafic restreint qui est soit la source ou la destination. Cependant, IPS est une politique globale pour l'ensemble du compte, et vous ne pouvez pas appliquer les paramètres de restriction géographique pour des sites ou objets spécifiques.

Détails du Flux TCP Exemple

Chronologie - Premier paquet
1. Champs disponibles - quintuplet, nom d'hôte (dname)
2. Moteur Cato - Pare-feu, Réseau, IPS/SAM
3. Données du flux de trafic - Identification de l'application, Classe de Client, OS
Chronologie - tls_handshake
1. Champs disponibles - suite_de_chiffrement, nom d'hôte (SNI)
2. Moteur Cato - IPS/SAM, Contrôle d'Application gen2, TLSi, Pare-feu, Réseau
3. Données du flux de trafic - Identification de l'application, Classe de Client, URLF
Chronologie - Headers HTTP
1. Champs disponibles - en-têtes, URL, nom d'hôte (en-tête hôte)
2. Moteur Cato - Contrôle d'Application gen3, IPS/SAM
3. Données du flux de trafic - Type de fichier (téléversement), OS
Chronologie - Corps HTTP
1. Champs disponibles - demande HTTP, corps HTTP
2. Moteur Cato - Contrôle d'Application gen3, DLP, IPS/SAM
3. Données du flux de trafic - Type de fichier (téléversement), Identification de l'application
Chronologie - Réponse HTTP
1. Champs disponibles - en-têtes de réponse HTTP, corps de réponse HTTP
2. Moteur Cato - AM/NGAM, Contrôle d'Application gen3, DLP, IPS/SAM
3. Données du flux de trafic - Type de fichier (téléchargement), Identification de l'application