Le pare-feu sensible au contexte améliore la visibilité au niveau de l'application et vous aide à remplacer le problème de perméabilité des applications. La visibilité au niveau de la couche d'application vous permet de mieux surveiller les charges de travail du point de vue de la ressource, de la conformité et de la sécurité.
Les règles de pare-feu ne peuvent pas consommer d'ID d'application. Le pare-feu sensible au contexte identifie les applications et met en place une microsegmentation pour le trafic est-ouest, indépendant du port que l'application utilise. Des règles de pare-feu sensible au contexte ou basé sur l'application peuvent être configurées en définissant des objets de service de couche 7. Une fois les objets de service de couche 7 définis dans les règles, vous pouvez configurer des règles avec le protocole spécifique, des ports et leur définition d'application. La définition de la règle peut être basée sur plus de 5 tuples. Vous pouvez également utiliser le gestionnaire de règles d'application pour créer des règles de pare-feu sensible au contexte.
Le pare-feu sensible au contexte est pris en charge à partir de NSX Data Center for vSphere 6.4.
Tous les clusters d'hôtes d'une infrastructure existante gérée par NSX Data Center for vSphere doivent être mis à niveau vers NSX Data Center for vSphere 6.4.0 ou version ultérieure.
Types de pare-feu
Le pare-feu effectue une action basée sur un en-tête ou une combinaison de différents en-têtes de paquets L2, L3, L4 et L7 qui sont ajoutés aux données à mesure qu'il se déplace à travers chaque couche du modèle TCP/IP.
Dans le pare-feu de couche 3 ou 4, l'action est effectuée uniquement en fonction des adresses IP source/de destination, du port et du protocole. L'activité des connexions réseau est également suivie. Ce type de pare-feu est appelé pare-feu avec état.
Le pare-feu de couche 7 ou sensible au contexte peut faire tout ce que font les pare-feu de couche 3 et 4. De plus, il peut inspecter intelligemment le contenu des paquets. Par exemple, une règle de pare-feu de couche 7 peut être écrite pour refuser toutes les demandes HTTP d'une adresse IP spécifique.
Définition de règle et capture de paquets
Vous pouvez créer des règles de plus de 5 tuples pour le pare-feu sensible au contexte. Vous pouvez continuer d'ajouter autant de tuples que nécessaire pour créer la règle correcte. Le protocole et l'utilisateur sont les seuls attributs pris en charge, et vous pouvez avoir un utilisateur ou un protocole par règle. Ils peuvent se trouver dans les champs SRC/DEST standard, ou être ajoutés à la fin pour les attributs supplémentaires.
Il existe 7 tuples dans la règle suivante :
| Source | Destination | Service | Direction | Action | Attributs |
|---|---|---|---|---|---|
| location-set-1 | Iport-set-1 | HTTPS | INOUT | Autoriser | TLS-V10 |
Lorsqu'un pare-feu sensible au contexte est configuré pour la machine virtuelle, les attributs DPI (Distributed Deep Packet Inspection) doivent également correspondre aux 5 tuples. C'est là que les règles sont traitées et validées à nouveau et que la règle correcte est trouvée. En fonction de l'action, un flux est créé ou abandonné.
Voilà comment une règle est traitée pour un paquet entrant :
- Lorsque vous entrez un filtre DFW, les paquets sont recherchés dans le tableau de flux basé sur 5 tuples.
- Si aucun flux/état n'est trouvé, le flux est comparé au tableau de règles basées sur 5 tuples et une entrée est créée dans le tableau de flux.
- Si le flux correspond à une règle avec un objet de service de couche 7, l'état du tableau de flux est marqué comme « DPI en cours ».
- Le trafic pointe ensuite vers le moteur DPI. Le moteur DPI détermine le APP_ID.
- Une fois le APP_ID déterminé, le moteur DPI renvoie l'attribut qui est inséré dans le tableau de contexte pour ce flux. L'indicateur « DPI en cours » est supprimé et le trafic ne pointe plus sur le moteur DPI.
-
Le flux (maintenant avec APP-ID) est réévalué par rapport à toutes les règles qui correspondent à l'APP_ID, en commençant par la règle d'origine qui a été mise en correspondance en fonction des 5 tuples, et en s'assurant qu'aucune règle L4 correspondante n'est prioritaire. La mesure appropriée est prise (autoriser/refuser) et l'entrée de tableau de flux est mise à jour en conséquence.
Il est possible d'avoir une règle de pare-feu sensible au contexte exactement comme une règle L3 ou L4, sans vraiment définir le contexte. Si c'est le cas, l'étape de validation peut être effectuée pour appliquer le contexte, qui peut disposer d'autres attributs.
Workflow du pare-feu sensible au contexte
