Comprendre le flux de paquets avec l'architecture Cato SPACE

Cet article explique le flux de 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 inclut 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 chaînage de services. Le passage unique pour un flux minimise la latence et améliore la performance globale du réseau. Chaque PoP peut prendre 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 accès complet aux données pour le flux de trafic et évaluent et partagent simultanément des données entre eux avec un contexte partagé. Les moteurs fonctionnent en parallèle, aucune priorité n'est donnée pour qu'un moteur évalue le trafic par rapport à un autre. Les moteurs sont situés dans chaque PoP et peuvent partager des données sans attendre des informations d'un moteur situé à un emplacement physique différent.

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 du premier paquet et attend plus d'informations. Lorsqu'un moteur différent identifie l'appareil comme étant 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 réseau et de sécurité et les moteurs 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 de règles réseau pour l'acheminement et la priorité QoS
- IPS/SAM - Protections IPS et Surveillance de l'activité suspecte (SAM)
- Contrôle des applications - Identification des applications pour la politique de contrôle des applications
  - Contrôle des applications gen2 - Règles pour les applications basées sur l'accès : autoriser ou bloquer
  - App Control gen3 - Règles pour les applications basées sur des actions granulaires : upload, download, etc
- 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 - Analyse Anti-Malware et Anti-Malware de nouvelle génération des fichiers joints dans le sens du téléchargement pour détecter des malwares
Données de flux de trafic et protocoles
- Identification des applications - Divers critères sont utilisés pour identifier l'application spécifique pour des politiques de sécurité ou de réseau
- OS - Système d'exploitation (OS) pour l'appareil, par exemple avec Device Posture ou la politique de Connectivité Client
- Type de client - Type d'applications client s'exécutant sur le système d'exploitation ayant créé ce flux réseau (par exemple, Chrome)
- URLF - Filtrage d'URL pour les catégories Cato basé sur l'URL du site
- File_type - Pour CASB et DLP, fichier joint dans le sens de l'upload ou du download

Flux de paquets TCP avec SPACE

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

Chronologie - Différentes phases du flux de trafic
Champs disponibles - Données disponibles pour la phase spécifique de la chronologie
Moteur Cato - Moteur SPACE capable d'analyser le flux et de prendre ensuite 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 de l'exemple de flux TCP.

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

Voici un exemple d'un flux de trafic pour une règle qui inclut l'application Slack, et montre quelles informations sont disponibles à chaque étape.

Premier paquet - TCP
```
Source - 10.10.2.107
Source port - 55477
Dest IP - 3.68.124.168
Dest port - 443
Protocol - TCP
DNS response - 3.68.124.168 - slack.com  (réponse optionnelle)
```
Voici les informations de flux de trafic disponibles basées 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
- L'identification de l'application inclut : tcp
Le moteur attend des informations supplémentaires du handshake TLS avant de pouvoir compléter l'identification de l'application Slack.
tls_handshake
```
"En-tête TLS"
"sni_host": "slack.com"
"raison de contournement de l'inspection prédéfinie": "aucune"
"ja3_formatted_str": "771,4865-4866-4867-49195-49199-49196-4920…"
```
Voici les informations de flux de trafic disponibles basées sur cet handshake TLS d'exemple :
- 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
  
  Le SNI est également envoyé à l'URLF, et correspond aux catégories Informations d'entreprise, Informatique et Technologie, Social
- Type de client est JA3 - classifie le client en tant que navigateur basé sur l'empreinte digitale TLS
- Inspection TLS ou action de bypass - basée sur le Type de Client et l'identification de l'application
- L'identification de l'application inclut : tcp, tls, slack
HTTP
```
"url" : "upload.slack.com:
"host_name" : "slack.com"
"Content-Type" : "application/pdf"
"Content-Disposition" : form-data; name="file"; filename="sample-data.pdf"
"Content-Length" : "52765"
```
Dans ce flux d'exemple, les informations suivantes sont disponibles en se basant sur les données HTTP :
- L'identification de l'application inclut : tcp, tls, http, slack
- L'Inspection TLS déchiffre le flux et identifie que le nom d'hôte du serveur Slack est slack.com
- En-tête HTTP - correspond au protocole HTTP
  
  Ceci est un exemple courant où HTTP_host correspond au SNI, et il n'y a aucun changement pour l'identification de l'application
- URL - le préfixe de téléchargement offre plus de granularité, et peut correspondre à l'action de téléchargement dans la politique de contrôle des applications
- Content-Type, Content-Disposition, Content-Length - fournissent des informations sur le nom, la taille et le type du fichier
- Actions de la politique de contrôle des applications :
  - Appliquer une politique qui utilise uniquement le locataire Slack de l'entreprise
  - Contrôle de fichier basé sur le type de fichier
    
    Anti-Malware et NG Anti-Malware n'analysent que les fichiers dans le sens du téléchargement.
Corps HTTP
```
"Corps HTTP payload" : "Le fichier lui-même"
```
Par exemple, la politique DLP applique qu'aucune donnée de carte de crédit ne peut être utilisée dans les messages Slack.
- L'identification de l'application est complétée pour l'application Slack. Elle est identifiée comme un trafic appartenant à la Catégorie sociale.
- Lorsque le contenu du fichier est prêt, ces moteurs analysent le contenu du fichier :
  - Le moteur DLP analyse le contenu basé sur la politique de contrôle des données
  - Anti-Malware et NG Anti-Malware analysent les fichiers dans le sens du téléchargement

Politiques et moteurs Cato

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

Politiques de pare-feu et de réseau

Le pare-feu WAN, le pare-feu Internet et les politiques de règles réseau peuvent souvent évaluer un flux de trafic dès le premier paquet. Par exemple, des règles basées sur des données de la 5-tuple. Cependant, pour les règles correspondant à 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 pour 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 de 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 de 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 de réseau peut é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 est pour le trafic pour la Source sous forme de plage IP avec la plage de ports 8000 - 8010, et le trafic est sortant via le PoP de Londres.

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

Exemple de règle de pare-feu WAN

La règle de pare-feu WAN suivante permet le trafic avec la même Source que la plage 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 est pour 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. Après que le moteur ait terminé l'évaluation et que le flux respecte tous les critères, le moteur permet le flux. Le PoP applique également la décision de routage basée sur le premier paquet.

Filtrage d'URL et catégories de Cato

Le service de filtrage d'URL fonctionne en analysant l'URL d'un site web et en la comparant avec une base de données de sites web malveillants ou inappropriés connus ou suspecté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, le jeu, 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 inspectera 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ée sur l'étape 1. Cependant, le moteur continue de communiquer et d'établir une connexion TLS pour présenter la page de blocage de pare-feu ou IPS correcte à l'utilisateur final.

IPS

Le moteur IPS continue de fonctionner pendant la durée de vie du flux de trafic. Il inspecte des éléments spécifiques disponibles à différentes étapes et agit sur le contenu qui correspond positivement à une protection IPS. Vous pouvez considérer l'IPS comme une loupe, attendant constamment des mises à jour du trafic et fournissant continuellement des informations au moteur sur ce qui a été vu dans le flux.

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

Le protocole pour le flux est HTTP
Basé sur le payload, il y a 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 pourraient correspondre à n'importe lequel des éléments ci-dessus et ensuite 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 requête et la réponse (sans aucune connexion au transport, par exemple TCP ou UDP).

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

Contrôle d'Apps

Le moteur de Contrôle d'Apps inspecte le trafic et applique les actions pour la politique de Contrôle d'Applications, et il est évalué sur chaque nouvelle transaction HTTP (requête et réponse).

Pour les applis gen2, TLS et proxy HTTP sont requis pour compléter l'identification de l'appli.

Pour les règles incluant des exigences de sécurité et de conformité :

Basé sur des données contextuelles provenant d'autres moteurs de réseau et de sécurité, le moteur de Contrôle d'Apps peut évaluer ces exigences pendant la phase tls_inspection
Il est également possible que le moteur puisse obtenir cette information à partir du SNI, et ne nécessite pas TLS ou une identification complète de l'appli (DPI de couche 7) pour évaluer l'appli

DLP

Le moteur DLP inspecte le contenu du flux de trafic et est une extension du moteur de Contrôle d'Apps. Lorsque la politique spécifie un type de fichier ou une taille de fichier, alors le moteur doit inspecter les métadonnées de l'appli et la charge utile pour ces caractéristiques du 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'appli gen3 est finalisée pour identifier les signatures de contenu spécifiques pour les champs qui stockent le contenu et les données inspectées.
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 NG Anti-Malware de SentinelOne scannent les pièces jointes 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 requête 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 liste d'autorisation configurée dans l'application de gestion Cato - ces fichiers peuvent être téléchargés.
2. La liste de blocages gérée par l'équipe de sécurité de Cato - ces fichiers sont bloqués.
Les fichiers sont scannés par les moteurs Anti-Malware et NG Anti-Malware, et le verdict est renvoyé : malveillant, suspect ou bénin.
L'action appropriée de la politique Anti-Malware est appliquée au fichier.

FAQ pour Politiques et Moteurs de Cato

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

Non, le Filtrage d'URL est uniquement pour le trafic Internet et ne s'applique pas 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 de l'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 aucun 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, l'IPS est une politique globale pour tout le 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 de Exemple

Chronologie - Premier paquet
1. Champs disponibles - 5-tuple, nom d'hôte (dname)
2. Moteur de Cato - Pare-feu, Réseau, IPS/SAM
3. Données de flux de trafic - Identification d'Apps, Classe de Client, OS
Chronologie - négociation_tls
1. Champs disponibles - suite de chiffrement, nom d'hôte (SNI)
2. Moteur de Cato - IPS/SAM, Contrôle d'Apps gen2, TLSi, Pare-feu, Réseau
3. Données de flux de trafic - Identification d'Apps, Classe de Client, Filtre d'URL
Chronologie - en-têtes_HTTP
1. Champs disponibles - en-têtes, URL, nom d'hôte (en-tête d'hôte)
2. Moteur Cato - Contrôle d'App gen3, IPS/SAM
3. Données de flux de trafic - Type_fichier (upload), OS
Chronologie - Corps_HTTP
1. Champs disponibles - Requête_HTTP, Corps_HTTP
2. Moteur Cato - Contrôle d'App gen3, DLP, IPS/SAM
3. Données de flux de trafic - Type_fichier (upload), Identification d'App
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'App gen3, DLP, IPS/SAM
3. Données de flux de trafic - Type_fichier (download), Identification d'App