Après avoir mis en place votre infrastructure réseau sur le cloud AWS, il vous faut, en tant qu’administrateur, la surveiller et déboguer en cas de panne (par exemple si l’instance EC2 n’est plus accessible depuis Internet). Cette partie a pour but de vous montrer les outils à connaître, qui vous seront également utiles pour la certification.
Connectez-vous à une instance dans un sous-réseau privé
Imaginons que nous ayons installé des instances EC2 dans des sous-réseaux privés, par exemple des instances qui forment une base RDS Custom. Nous détectons que l’une d’entre elles présente un bug. Pour l’analyser, nous souhaitons nous y connecter en direct depuis notre poste grâce à un tunnel SSH, comme indiqué dans l’image ci-dessous. Or, une instance EC2 dans un sous-réseau privé n’est pas accessible depuis Internet !
A - L’admin ne peut pas accéder directement en SSH à l’instance privée car elle n’est pas accessible depuis Internet.
Pour y remédier, vous devez utiliser un hôte bastion (bastion host). C’est une instance EC2 installée dans un sous-réseau public auquel vous pouvez accéder en SSH depuis votre poste. Connecté à cet hôte, vous vous connectez en SSH à l’instance EC2 installée dans le sous-réseau privé. Le fonctionnement est présenté dans l’image suivante :
A - Le groupe de sécurité de l’hôte bastion doit autoriser sur le port 22 le trafic entrant depuis l’adresse IP de l’admin.
B - Le groupe de sécurité de l’instance privée doit autoriser sur le port 22 le trafic entrant depuis l’adresse IP privée de l’hôte ou de son groupe de sécurité.
C - L’admin se connecte en SSH à l’hôte bastion.
D - L’admin est connecté en SSH à l’hôte bastion. Depuis cet hôte, il se connecte en SSH à l’instance privée.
Il faudra configurer les groupes de sécurité des deux instances :
pour le groupe de sécurité de l’hôte bastion, acceptez le trafic entrant sur le port 22 uniquement pour l’adresse IP de l’admin.
pour le groupe de sécurité de l’instance EC2 privée, acceptez le trafic entrant sur le port 22 uniquement pour l’adresse IP privée de l’hôte ou de son groupe de sécurité.
A - L’hôte bastion assume un rôle d’instance qui lui donne l’autorisation de récupérer la clé privée SSH contenue dans le secret.
B - L’admin stocke la clé privée SSH pour se connecter à l’hôte bastion.
C - La clé privée pour se connecter à l’instance privée est stockée dans un secret.
D - L’admin peut récupérer la clé privée SSH de l’instance privée, et s’y connecter depuis l’hôte bastion.
Testez la connectivité entre des ressources
Il est très fréquent dans une infrastructure réseau de rencontrer des problèmes de connectivité entre composants. Par exemple, une instance EC2 dans un sous-réseau public n’accède pas à Internet. L’outil Analyseur d'accessibilité de VPC (VPC reachability analyzer) vous permet d’exécuter des analyses réseaux pour déterminer si une ressource est accessible par une autre. Après l’analyse, l’outil vous indique si elle a échoué ou réussi. Si elle a réussi, l’analyseur d'accessibilité affiche le chemin indiquant toutes les ressources AWS traversées pour atteindre la destination. Sinon, l'analyseur d'accessibilité identifie le composant bloquant. C’est un outil très utile et efficace pour déboguer une infrastructure réseau !
L’image ci-dessous montre l’architecture réseau entre notre serveur d’API et la passerelle internet. Testons notre configuration réseau avec l’analyseur d’accessibilité.
Sur la console AWS, vous pouvez créer et exécuter une analyse (qui coûte environ 10 centimes d’euros), comme ci-dessous, en indiquant l’instance EC2 du serveur d’API comme source et la passerelle internet comme destination.
Pour vous montrer la pertinence de cet outil, j’ai réalisé deux tests.
Dans le premier, j’ai supprimé, dans la table de routage du sous-réseau, la route qui dirige le trafic pour Internet vers la passerelle internet. Ainsi, ce test d’accessibilité a échoué.
Dans le second test, j’ai rétabli la route et lancé l’analyse, qui a réussi.
Voici dans l’image ci-dessous le statut des tests :
En consultant chaque test, on peut voir sous forme de graphes le chemin emprunté pour atteindre la passerelle internet et à quel niveau cela a échoué.
Dans le cas du premier test, on constate bien que la table de routage pose problème :
A contrario, on voit tous les composants traversés dans le second test pour atteindre la passerelle internet :
Analysez le trafic IP dans votre VPC
Si nous prenons le cas du site web de The Green Earth Post, on s’attend à des milliers de consultations par jour venant de nos lecteurs mais aussi de nos partenaires. Toutes ces consultations génèrent un trafic IP volumineux. Il est important d’analyser ce trafic pour détecter des anomalies de connectivité, mais aussi des potentielles attaques informatiques venant d’adresses IP publiques suspectes. Les journaux de flux VPC (VPC Flow Logs) permettent de capturer des informations sur le trafic IP circulant vers et depuis les interfaces réseau des ressources installées dans votre VPC. Cela inclut également les informations réseau à partir des interfaces gérées par AWS : RDS, ElastiCache, Redshift, les passerelles NAT, les passerelles de transit, les équilibreurs de charge, etc.
Les données de journaux de flux peuvent être publiées dans Amazon S3 ou Amazon CloudWatch Logs (que nous verrons dans la prochaine partie). Dans l’architecture réseau que nous avons étudié dans les chapitres précédents, voici comment ce service s’y intègre :
Avec Athena et QuickSight, vous pouvez interroger et analyser vos données de journaux de flux stockées dans un compartiment S3.
Dans le cas où les données sont envoyées vers CloudWatch Logs, vous pouvez utiliser CloudWatch Logs Insights pour les analyser.
A - Définir des alertes pour faire de la notification;
B - Analyser les logs avec Insights.
Ci-dessous un exemple de données collectées au format par défaut :
Et voici le tableau explicatif de chaque élément de cet exemple.
Version | Compte ID | Interface ID | IP source | IP destination | Port source | Port destination | Procole | Paquets | Bytes | Date de début | Date de fin | Action | Statut du log |
2 | 123456789012 | eni-1234b8ca123456749 | 172.31.16.129 | 172.31.16.22 | 20642 | 22 | 6 | 20 | 4246 | 1419240010 | 1419240070 | ACCEPT | OK |
2 | 123456789012 | eni-1234b8ca123456749 | 172.31.9.68 | 172.31.9.11 | 49762 | 3389 | 6 | 20 | 4246 | 1419240010 | 1419240070 | REJECT | OK |
La première ligne indique que le trafic SSH (port de destination 22, protocole TCP) vers l'interface réseau eni-1234b8ca123456749 du compte 123456789012 a été autorisé.
La deuxième ligne indique que le trafic RDP (port de destination 3389, protocole TCP) vers l'interface réseau eni-1234b8ca123456749 du compte 123456789012 a été rejeté.
À l'aide de ces données, nous pouvons identifier quelles sont les adresses IP et les ports qui posent des problèmes. Ainsi, on peut en déduire si des groupes de sécurité et/ou NACL sont mal configurés. Il est également possible de détecter des comportements suspects voire malveillants si une adresse IP source semble effectuer des requêtes d’attaques informatiques.
Inspectez le trafic réseau dans votre VPC
Après avoir capturé et analysé les adresses IP du trafic réseau avec les journaux de flux de VPC, on souhaite maintenant capturer le contenu des paquets réseaux reçus et envoyés par nos instances EC2 pour des analyses a posteriori. Ceci est utilisé dans la sécurité du réseau, la surveillance des performances du réseau, la gestion de l'expérience client et le dépannage du réseau.
Pour réaliser cette capture, AWS met à disposition la fonctionnalité de mise en miroir du trafic VPC (VPC Traffic Mirroring). Elle consiste à copier le trafic réseau de l'interface réseau Elastic (ENI) d'une instance EC2 vers une cible à des fins d'analyse. La cible peut être une autre interface réseau élastique (ENI), attachée à une appliance de surveillance s'exécutant sur une instance EC2, ou un équilibreur de charge réseau (NLB), qui équilibre le trafic sur plusieurs instances d'une appliance de surveillance. Cette appliance s’exécute dans le même VPC ou dans un autre VPC avec l’appairage de VPC activé. Des outils open source de surveillance de trafic, tels que Zeek et Suricat, peuvent être installés dans l’appliance de surveillance.
Une appliance de surveillance est un appareil de surveillance qui reçoit des paquets réseau d'un autre appareil et analyse ensuite ces paquets avec un logiciel pour des raisons de sécurité et de qualité de service.
En capturant les données brutes des paquets nécessaires à l'inspection du contenu, la mise en miroir du trafic VPC vous évite d’installer un agent logiciel (un programme qui accomplit des tâches) pour acquérir le trafic réseau depuis/vers les instances EC2.
Voici ci-dessous le fonctionnement d’un système de surveillance grâce à la mise en miroir de trafic de VPC :
Vous pouvez observer dans ce screencast tous les outils dont je vous ai parlé dans les 3 dernières sections de ce chapitre :
À vous de jouer !
Pour apprendre à utiliser les méthodes de surveillance et de débug vues précédemment, vous allez dans un premier temps tester la méthode de l’hôte bastion et, dans un second temps, tester que le serveur d’API a bien accès à Internet :
Testez la méthode de l’hôte bastion avec une instance privée à installer. Supprimez l’instance privée à la fin du test.
Pour vérifier comment le faire, vous pouvez revisiter le premier screencast du chapitre.
Faites un test d’accessibilité entre l’instance EC2 qui héberge le serveur d’API et la passerelle internet.
Vous pouvez vérifier si vous avez bien fait les étapes 2 et 3 en regardant ce screencast :
En résumé
Un hôte bastion vous permet de vous connecter en SSH depuis votre poste à une instance EC2 déployée dans un sous-réseau privé.
L’analyseur d'accessibilité de VPC vous permet de déterminer si une ressource est accessible par une autre.
Les journaux de flux de VPC vous aident à analyser le trafic IP dans votre VPC.
La mise en miroir de VPC vous permet de collecter les paquets réseaux que vous pouvez analyser avec une appliance de surveillance.
Dans le prochain chapitre, nous verrons comment optimiser le réseau du site web !
