Le Blog Amazon Web Services

Utilisation de solutions de sécurité et AWS Transit Gateway pour sécuriser le trafic réseau entrant

Introduction

Les applications exposées sur Internet présentent par nature une plus grande surface d’attaque et sont exposées à des catégories de menace auxquelles des applications non-exposées sur Internet ne sont pas soumises. Disposer de protections nécessaires aux attaques visant ce type d’applications et pouvoir en minimiser leur impact est au coeur de toute politique de sécurité.

La mise en place d’éléments de pare-feu que l’on retrouve traditionnellement sur AWS comme les Security Groups et les Network Access Control Lists (NACLs) limitent la surface d’attaque exposée et permettent de bloquer le trafic depuis et vers la source ainsi que la destination de l’attaque. Il est également possible d’utiliser AWS Web Application Firewall permettant l’inspection en profondeur des paquets réseau liés au trafic web, filtrant ainsi le trafic identifié comme malicieux tel que le cross-scripting (XSS) et les injections SQL.

En Novembre 2020, nous avons  lancé un nouveau service, AWS Gateway Load Balancer, permettant d’exposer des fonctionnalités de sécurité réseau « as a service ». AWS Gateway Load Balancer propose de mettre à disposition des flottes d’appliances tierces de manière hautement disponible et à l’échelle créant ainsi de nouvelles manières de délivrer des solutions de virtualisation de fonction réseau (NFV – Network Function Virtualization).

Certains de nos clients ont cependant des besoins supplémentaires qui vont au delà de ce qui est proposé par ces contrôles de sécurité réseau comme par exemple des fonctionnalités d’inspection de paquets en profondeur (DPI – Deep Packet Inspection), de détection de protocoles applicatifs, du filtrage de nom de domaine ou encore de système de prévention d’intrusion (IPS – Intrusion Prevention System).

AWS Network Firewall couvre les fonctionnalités mentionnées précédemment en offrant un pare-feu managé, stateful et utilisable à l’échelle couplé à un système de prévention d’intrusion pour votre Amazon VPC. Il est également possible d’opter pour des solutions additionnelles d’IDS/IPS tiers utilisant des algorithmes basés sur le comportement, les statistiques ou les signatures afin de détecter et de contenir des attaques réseaux ou de logiciels malveillants de type Trojan. Enfin, vous pouvez choisir parmi une variété d’instances de pare-feu tiers disponibles au travers de l’AWS Marketplace pour surveiller et analyser le trafic réseau, les journaux ainsi que les accès et identifier tout trafic qui serait généré par un logiciel malveillant. Sans oublier comme mentionné précédemment, l’utilisation de Security Groups ou des NACLs pour minimiser la surface d’attaque.

Comme vous pouvez le voir, il existe de nombreuses options à considérer. Dans cet article, nous allons nous focaliser sur un cas bien spécifique : l’utilisation d’instances de pare-feux tiers afin d’effectuer une inspection en profondeur des paquets réseaux entrant dans le cadre d’applications utilisant des communications TLS de manière centralisée. Nous allons pour cela considérer une architecture multi-tiers qui utilise des Application Load Balancer (ALB) et des instances de pare-feu dans un Auto Scaling Group. Le tier applicatif sera lui distribué sur plusieurs Amazon VPCs, possiblement dans plusieurs comptes et connecté à l’aide d’une AWS Transit Gateway. Cette architecture permet également de passer à l’échelle le tier d’inspection et le tier applicatif indépendamment l’un de autre.

Architecture

Regardons maintenant l’architecture cible et sa fonctionnalité d’inspection de paquets entrants. Dans l’approche proposée, on utilise trois Amazon VPCs mais le design peut s’étendre à n’importe quel nombre d’Amazon VPCs et/ou comptes AWS. Dans un premier Amazon VPC DMZ sont créés des instances de pare-feu au sein d’un Auto Scaling Group et un Application Load Balancer externe (connecté à Internet) qui permet d’y distribuer le trafic entrant. Nous centralisons ainsi tout le trafic provenant d’Internet dans l’Amazon VPC DMZ qui est ensuite connecté à des Amazon VPCs contenant le tier applicatif en utilisant une AWS Transit Gateway.

Architecture générale, solutions de sécurité et AWS Transit Gateway pour sécuriser le trafic réseau entrant

La règle du “listener” de l’ALB externe est configurée pour segmenter le trafic à destination des applications. Pour chaque application servie au travers des pare-feux situés dans le même Auto Scaling Group, on créera un Target Group configuré avec un port unique lié au besoin de ladite application. Le trafic provenant d’Internet et à destination des applications commencera donc par traverser l’ALB externe sur le port configuré au niveau du listener (par exemple sur le port 80). En fonction de l’en-tête de l’hôte contenue dans la requête, l’ALB déterminera alors sur quel Target Group et port (qui est défini de manière personnalisée) il devra faire suivre le trafic. On configurera également sur les pare-feux des règles de NAT basées sur le port utilisé pour faire suivre le trafic entrant vers le service destinataire en effectuant du PAT (“Port Address Translation”). Un exemple de ce type de trafic est illustré dans le schéma ci-dessous :

 

Segmentation des flux de trafic traversants un répartiteur de charge d'application

Segmentation des flux de trafic traversants un répartiteur de charge d’application et des Target Groups au moyen d’un jeu de règles du Listener de l’ALB

Lors de la création d’une nouvelle application, un message est publié dans une file d’attente de messagerie Amazon SQS présente dans le compte DMZ. Ce message déclenche alors une fonction AWS Lambda qui configurera les règles de NAT correspondantes sur les pare-feux. A titre d’exemple, nous allons ici montrer comment mettre cela en place avec un pare-feu Palo Alto mais l’architecture présentée peut être utilisée avec n’importe quel fournisseur de pare-feu partenaire dont l’accès est spécifié dans la section de conclusion de cet article.

Implémentation

Aperçu des templates utilisés :

Pare-feu – firewall-template.yaml

  • Ce template déploie un répartiteur de charge accessible depuis Internet (ici un ALB) et des pare-feux VM-Series de Palo Alto. Ces Pare-feux sont placés dans un Auto Scaling Group couvrant deux zones de disponibilité;
  • L’ALB accessible depuis Internet distribue le trafic entrant dans l’Amazon VPC sur les pare-feux précédemment créés.

AWS Transit Gateway – transit-gateway.yaml, transit-gateway-attachment.yaml et transit-gateway-propagations.yaml

  • Ces templates assurent la connectivité entre l’Amazon VPC DMZ et les Amazon VPC des applications

Application – application-template.yaml

  • Ce template déploie un répartiteur de charge interne pour les instances d’application situées dans un Amazon VPC spécifié. Vous avez le choix de créer un Application Load Balancer ou un Network Load Balancer (NLB).

Règles du Listener – alb-rules.yaml

  • Ce template met en place la configuration nécessaire au support de multiples applications. Il met à jour les règles existantes du Listener de l’ALB connecté à Internet et fait suivre le trafic dans un Target group spécifique en se basant sur des paramètres de l’entête de l’hôte comme le nom DNS.

Puisque nous utilisons ici des pare-feu Palo Alto, les pré-requis suivant sont nécessaires pour le déploiement utilisant Panorama :

  • Panorama,
  • Clé d’API Panorama,
  • Clé VM-Auth Panorama,
  • Fichiers d’amorçage (bootstrap).

Description des pré-requis :

Panorama

  • Permet le management centralisé des machines virtuelles et peut être configuré comme collecteur de journaux,
  • Le mode Panorama est utilisé pour gérer de multiples pare-feux Palo Alto,
  • Configuration des interfaces réseau Panorama en utilisant DHCP.

Clé d’API Panorama

  • Pré-requis pour permettre à une fonction AWS Lambda de configurer Panorama avec des options de template et de « device group »,
  • La clé est ensuite utilisée pour authentifier les APIs,
  • Permet la création d’un clé d’API en utilisant des requêtes GET ou POST avec l’adresse IP de Panorama, les droits d’administration ainsi que le paramètre « type=keygen ». Il est possible d’exécuter cette commande depuis n’importe quelle machine hôte pouvant joindre l’adresse IP de Panorama (Panorama_IP_address).

curl -k -X GET 'https://<*Panorama_IP_address*>/api/?type=keygen&user=<username>&password=<password>'

ou

curl -k -X POST 'https://<*Panorama_IP_address*>/api/?type=keygen&user=<username>&password=<password>'

Lorsque la requête est exécutée avec succès la réponse retourne status= »success » ainsi que la clé d’API au sein de l’élément key. Des informations complémentaires sont disponibles ici.

La clé VM-Auth peut être générée en utilisant la commande suivante de la CLI de Panorama :

Request bootstrap vm-auth-key generate lifetime <1-8760>

ou via un appel à l’API de Panorama:

https://<Panorama_IP_address>/api/?type=op&cmd=<request><bootstrap><vm-auth-key><generate><lifetime><number-of-hours></lifetime></generate></vm-auth-key></bootstrap></request>

Fichiers d’amorçage

  • Contient un exemple de fichier init-cfg.txt provenant de GitHub aidant à appliquer une configuration basique aux pare-feux VM-Series,
  • Effectue un changement des interfaces réseau du pare-feu VM-Series pour que le trafic non approuvé utilise AWS ENI comme eth0,
  • Se connecte à Panorama et effectue la configuration du device group et du template. Des informations détaillées sur les pré-requis sont disponibles ici.

Étapes de déploiement

Le déploiement de la solution consiste principalement en cinq étapes dont voici un aperçu :

1. Configuration du template de pare-feu

  • Création des instances de pare-feu dans un Auto Scaling Group,
  • Initialisation des instances de pare-feu en utilisant les configurations permettant de les enregistrer auprès de Panorama,
  • Création d’un ALB externe (accessible depuis Internet) que l’on associe ensuite à l’Auto Scaling Group des instances de pare-feu,
  • Création d’une file de message Amazon SQS permettant de surveiller le lancement de nouvelles applications créées avec le template d’application présenté précédemment,
  • Création d’une fonction AWS Lambda pour surveillant l’arrivée de nouveaux messages dans la file de message Amazon SQS liés à la création d’un répartiteur de charge d’application. Lorsqu’un tel message est reçu, la fonction Lambda crée une nouvelle règle NAT sur les VM de pare-feu dans l’Auto Scaling Group.

2. Création d’une AWS Transit Gateway (TGW) partagée avec les comptes/VPC des applications

  • Dans cette étape la TGW sera créée avec deux domaines de routages :
    • Le domaine de routage DMZ VPC,
    • Le domaine de routage Spoke VPC,
  • La TGW est ensuite partagée avec les autres comptes AWS au travers de AWS Organizations.

3. Configuration du template Application

  • Création des ressources nécessaires à l’application,
  • Création d’un répartiteur de charge interne chargé de distribuer le trafic de l’application,
  • Publication des messages dans la file Amazon SQS créée dans lors de l’étape 1 permettant d’automatiser la création des règles de NAT sur les pare-feux pour chaque application.

4. Etablir la connectivité entre le VPC DMZ et les les compte/VPC des applications

  • Dans cette étape nous allons permettre la connectivité entre le VPC DMZ et les VPC des applications qui peuvent se situer soit dans le même compte soit dans des comptes différents,
  • La fonction AWS Lambda créée par le template s’assure que les attachements de la TGW soient taggés, associés au bon domaines de routage et que les propagations de routes nécessaires sont bien faites.

5. Mise à jour de la règle du Listener en fonction des répartiteurs de charge des applications existants 

  • Lors de cette étape on configure la règle du Listener du répartiteur de charge externe afin de distinguer le trafic en se basant sur l’URL de l’hôte,
  • On crée ensuite différents Target Groups contenant le même jeu d’instances de pare-feu situées dans l’Auto Scaling Group mais chaque application se verra mappée à un port de Target Group unique.

Le détail de ces étapes de déploiement sont disponible sur aws-samples-repository.

Suppression des ressources

Après avoir testé et validé avec succès cette solution, toutes les ressources déployées à l’aide de templates AWS CloudFormation doivent être supprimées pour éviter des coûts inutiles. Il suffit pour cela de se rendre dans la section du service AWS CloudFormation dans console AWS, d’identifier les stacks utilisées puis de les supprimer.
Note : Si vous avez fait le test en utilisant plusieurs comptes, il est nécessaire d’effectuer cette phase de nettoyage sur l’ensemble des comptes.

Conclusion

Dans cet article nous avons introduit une solution utilisant des pare-feu tiers situés dans un Auto Scaling Group et une AWS Transit Gateway afin d’inspecter le trafic entrant chiffré et le filtrer en fonction de pré-requis de politique de sécurité. Ceci à été implémenté en créant les ressources suivantes :

  • Un Amazon VPC DMZ contenant les instances de sécurité inspectant le trafic Internet entrant (les pare-feux),
  • Une AWS Transit Gateway qui permet de centraliser les communications entre les VPC contenant les différentes application et l’Amazon VPC DMZ.

Nous avons ici utilisé des pare-feux Palo Alto pour effectuer l’inspection du trafic, mais il est possible de déployer d’autres solutions de sécurité similaires depuis l’un des nombreux ISV faisant parti du réseau de partenaires AWS depuis l’AWS Marketplace. Vous trouverez également dans l’AWS Marketplace des solutions de répartiteur de charge tiers qui pourraient vous être utiles.

Article original contribué par Shiva Vaidyanathan et Mayuresh Joshi.