AWS - VPC & Networking Informations de base

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Mise en réseau AWS en bref

Un VPC contient un network CIDR comme 10.0.0.0/16 (avec sa table de routage et son ACL réseau).

Ce réseau VPC est divisé en sous-réseaux, donc un sous-réseau est directement lié au VPC, à la table de routage et à l’ACL réseau.

Ensuite, des Network Interface attachées aux services (comme les instances EC2) sont connectées aux sous-réseaux avec des security group(s).

Par conséquent, un security group limitera les ports exposés des interfaces réseau qui l’utilisent, indépendamment du sous-réseau. Et un ACL réseau limitera les ports exposés pour l’ensemble du réseau.

De plus, pour accéder à Internet, il y a quelques configurations intéressantes à vérifier :

• Un sous-réseau peut auto-attribuer des adresses IPv4 publiques
• Une instance créée dans le réseau qui auto-attribue des adresses IPv4 peut en obtenir une
• Une Internet gateway doit être attachée au VPC
• Vous pouvez aussi utiliser des Egress-only internet gateways
• Vous pouvez aussi avoir une NAT gateway dans un sous-réseau privé afin qu’il soit possible de se connecter à des services externes depuis ce sous-réseau privé, mais il n’est pas possible d’y accéder depuis l’extérieur.
• La NAT gateway peut être publique (accès à Internet) ou privée (accès à d’autres VPCs)

VPC

Amazon Virtual Private Cloud (Amazon VPC) vous permet de lancer des ressources AWS dans un réseau virtuel que vous avez défini. Ce réseau virtuel comportera plusieurs sous-réseaux, des Internet Gateways pour accéder à Internet, des ACLs, des security groups, des IPs…

Subnets

Les subnets aident à renforcer le niveau de sécurité. Le regroupement logique de ressources similaires facilite également la gestion de votre infrastructure.

• Les CIDR valides vont d’un netmask /16 à un netmask /28.
• Un subnet ne peut pas être dans différentes zones de disponibilité en même temps.
• AWS réserve les trois premières adresses IP d’hôte de chaque subnet pour l’usage interne d’AWS : la première adresse d’hôte est utilisée pour le routeur VPC. La seconde adresse est réservée pour le DNS AWS et la troisième adresse est réservée pour un usage futur.
• On parle de public subnets pour ceux qui ont un accès direct à Internet, tandis que les subnets privés n’en ont pas.

Route Tables

Les tables de routage déterminent le routage du trafic pour un subnet au sein d’un VPC. Elles déterminent quel trafic réseau est acheminé vers Internet ou vers une connexion VPN. Vous y trouverez généralement l’accès vers :

• Le VPC local
• Le NAT
• Les Internet Gateways / Egress-only Internet gateways (nécessaires pour donner l’accès à Internet à un VPC).
• Pour rendre un subnet public, vous devez créer et attacher une Internet gateway à votre VPC.
• Des VPC endpoints (pour accéder à S3 depuis des réseaux privés)

ACLs

Network Access Control Lists (ACLs) : Les ACLs réseau sont des règles de pare-feu qui contrôlent le trafic réseau entrant et sortant vers un subnet. Elles peuvent être utilisées pour autoriser ou refuser le trafic vers des adresses IP ou des plages spécifiques.

• Il est plus fréquent d’autoriser/refuser l’accès en utilisant des security groups, mais c’est la seule façon de couper complètement des reverse shells établis. Une règle modifiée dans un security group n’arrête pas les connexions déjà établies.
• Cependant, cela s’applique à l’ensemble du sous-réseau : soyez prudent lorsque vous interdisez des choses, car des fonctionnalités nécessaires peuvent être perturbées.

Security Groups

Les security groups sont un pare-feu virtuel qui contrôle le trafic réseau entrant et sortant vers les instances dans un VPC. Relation 1 SG à N instances (généralement 1 à 1).
Généralement, cela sert à ouvrir des ports dangereux sur des instances, comme le port 22 par exemple :

Elastic IP Addresses

Une Elastic IP address est une adresse IPv4 statique conçue pour le cloud computing dynamique. Une Elastic IP address est allouée à votre compte AWS, et vous appartient jusqu’à ce que vous la libériez. En utilisant une Elastic IP address, vous pouvez masquer la défaillance d’une instance ou d’un logiciel en remappant rapidement l’adresse vers une autre instance de votre compte.

Connection between subnets

Par défaut, tous les subnets ont l’attribution automatique d’adresses IP publiques désactivée, mais cela peut être activé.

Une route locale dans une table de routage permet la communication entre les sous-réseaux du VPC.

Si vous connectez un subnet avec un autre subnet, vous ne pouvez pas accéder aux subnets connectés avec l’autre subnet, vous devez créer une connexion directe avec eux. Cela s’applique aussi aux Internet gateways. Vous ne pouvez pas passer par la connexion d’un subnet pour accéder à Internet ; vous devez assigner l’Internet gateway à votre subnet.

VPC Peering

Le VPC peering vous permet de connecter deux VPC ou plus ensemble, en utilisant IPv4 ou IPv6, comme s’ils faisaient partie du même réseau.

Une fois la connectivité de peering établie, les ressources d’un VPC peuvent accéder aux ressources de l’autre. La connectivité entre les VPC est mise en œuvre via l’infrastructure réseau AWS existante, elle est donc hautement disponible sans goulot d’étranglement de bande passante. Comme les connexions en peering fonctionnent comme si elles faisaient partie du même réseau, il existe des restrictions concernant les plages de blocs CIDR que vous pouvez utiliser.
Si vous avez des plages CIDR qui se chevauchent ou sont dupliquées pour vos VPC, alors vous ne pourrez pas faire de peering entre les VPC.
Chaque VPC AWS ne communiquera qu’avec son pair. Par exemple, si vous avez une connexion de peering entre VPC 1 et VPC 2, et une autre connexion entre VPC 2 et VPC 3 comme montré, alors VPC 1 et 2 pourraient communiquer directement entre eux, tout comme VPC 2 et VPC 3 ; cependant, VPC 1 et VPC 3 ne pourraient pas. Vous ne pouvez pas router à travers un VPC pour atteindre un autre.

VPC Flow Logs

Au sein de votre VPC, vous pouvez potentiellement avoir des centaines voire des milliers de ressources qui communiquent entre différents sous-réseaux publics et privés et aussi entre différents VPCs via des connexions de peering. Les VPC Flow Logs vous permettent de capturer les informations de trafic IP qui circulent entre les interfaces réseau de vos ressources au sein de votre VPC.

Contrairement aux logs d’accès S3 et aux logs d’accès CloudFront, les données de logs générées par les VPC Flow Logs ne sont pas stockées dans S3. À la place, les données de logs capturées sont envoyées vers CloudWatch logs.

Limitations :

• Si vous exécutez une connexion VPC en peering, alors vous ne pourrez voir les flow logs des VPC en peering que s’ils sont dans le même compte.
• Si vous exécutez encore des ressources dans l’environnement EC2-Classic, alors malheureusement vous ne pouvez pas récupérer d’informations depuis leurs interfaces.
• Une fois qu’un VPC Flow Log a été créé, il ne peut pas être modifié. Pour modifier la configuration du VPC Flow Log, vous devez le supprimer puis en recréer un nouveau.
• Le trafic suivant n’est pas surveillé ni capturé par les logs : le trafic DHCP au sein du VPC, le trafic des instances à destination du serveur DNS Amazon.
• Tout trafic destiné à l’adresse IP du routeur par défaut du VPC et le trafic vers et depuis les adresses suivantes ne sont pas capturés : 169.254.169.254 (utilisée pour la collecte des metadata d’instance) et 169.254.169.123 (utilisée pour le Amazon Time Sync Service).
• Trafic relatif à une licence d’activation Windows Amazon depuis une instance Windows.
• Trafic entre une interface de network load balancer et une interface d’endpoint réseau.

Pour chaque interface réseau qui publie des données dans le groupe de logs CloudWatch, elle utilisera un flux de logs différent. Et à l’intérieur de chacun de ces flux, il y aura les événements de flow log qui montrent le contenu des entrées de log. Chacun de ces logs capture des données pendant une fenêtre d’environ 10 à 15 minutes.

VPN

Basic AWS VPN Components

1. Customer Gateway :

• Un Customer Gateway est une ressource que vous créez dans AWS pour représenter votre côté d’une connexion VPN.
• C’est essentiellement un dispositif physique ou une application logicielle de votre côté de la connexion Site-to-Site VPN.
• Vous fournissez les informations de routage et l’adresse IP publique de votre équipement réseau (comme un routeur ou un pare-feu) à AWS pour créer un Customer Gateway.
• Il sert de point de référence pour configurer la connexion VPN et n’entraîne pas de coûts supplémentaires.

2. Virtual Private Gateway :

• Un Virtual Private Gateway (VPG) est le concentrateur VPN du côté Amazon de la connexion Site-to-Site VPN.
• Il est attaché à votre VPC et sert de cible pour votre connexion VPN.
• Le VPG est le endpoint côté AWS pour la connexion VPN.
• Il gère la communication sécurisée entre votre VPC et votre réseau on-premises.

3. Site-to-Site VPN Connection :

• Une Site-to-Site VPN connection connecte votre réseau on-premises à un VPC via un tunnel VPN sécurisé IPsec.
• Ce type de connexion nécessite un Customer Gateway et un Virtual Private Gateway.
• Il est utilisé pour une communication sécurisée, stable et cohérente entre votre centre de données ou réseau et votre environnement AWS.
• Typiquement utilisé pour des connexions régulières et long terme et facturé en fonction de la quantité de données transférées sur la connexion.

4. Client VPN Endpoint :

• Un Client VPN endpoint est une ressource que vous créez dans AWS pour activer et gérer des sessions VPN clients.
• Il est utilisé pour permettre à des appareils individuels (comme des laptops, smartphones, etc.) de se connecter de manière sécurisée aux ressources AWS ou à votre réseau on-premises.
• Il diffère de la Site-to-Site VPN en ce qu’il est conçu pour des clients individuels plutôt que pour connecter des réseaux entiers.
• Avec Client VPN, chaque appareil client utilise un logiciel client VPN pour établir une connexion sécurisée.

Site-to-Site VPN

Connectez votre réseau on-premises à votre VPC.

• VPN connection : Une connexion sécurisée entre votre équipement on-premises et vos VPCs.
• VPN tunnel : Un lien chiffré où des données peuvent passer du réseau client vers ou depuis AWS.

Chaque VPN connection inclut deux VPN tunnels que vous pouvez utiliser simultanément pour la haute disponibilité.

• Customer gateway : Une ressource AWS qui fournit des informations à AWS concernant votre appareil customer gateway.
• Customer gateway device : Un appareil physique ou une application logicielle de votre côté de la connexion Site-to-Site VPN.
• Virtual private gateway : Le concentrateur VPN du côté Amazon de la connexion Site-to-Site VPN. Vous utilisez un virtual private gateway ou un transit gateway comme gateway pour le côté Amazon de la connexion Site-to-Site VPN.
• Transit gateway : Un hub de transit qui peut être utilisé pour interconnecter vos VPCs et réseaux on-premises. Vous utilisez un transit gateway ou virtual private gateway comme gateway pour le côté Amazon de la connexion Site-to-Site VPN.

Limitations

• Le trafic IPv6 n’est pas pris en charge pour les connexions VPN sur un virtual private gateway.
• Une connexion AWS VPN ne prend pas en charge Path MTU Discovery.

De plus, prenez les éléments suivants en considération lorsque vous utilisez Site-to-Site VPN.

• Lors de la connexion de vos VPCs à un réseau on-premises commun, nous recommandons d’utiliser des blocs CIDR non chevauchants pour vos réseaux.

Client VPN

Se connecter depuis votre machine à votre VPC

Concepts

• Client VPN endpoint : La ressource que vous créez et configurez pour activer et gérer les sessions VPN clients. C’est la ressource où toutes les sessions Client VPN se terminent.
• Target network : Un target network est le réseau que vous associez à un Client VPN endpoint. Un subnet d’un VPC est un target network. Associer un subnet à un Client VPN endpoint vous permet d’établir des sessions VPN. Vous pouvez associer plusieurs subnets à un Client VPN endpoint pour la haute disponibilité. Tous les subnets doivent provenir du même VPC. Chaque subnet doit appartenir à une Availability Zone différente.
• Route : Chaque Client VPN endpoint possède une table de routage qui décrit les routes réseau de destination disponibles. Chaque route dans la table de routage spécifie le chemin pour le trafic vers des ressources ou réseaux spécifiques.
• Authorization rules : Une authorization rule restreint les utilisateurs qui peuvent accéder à un réseau. Pour un réseau spécifié, vous configurez le groupe Active Directory ou identity provider (IdP) autorisé à l’accès. Seuls les utilisateurs appartenant à ce groupe peuvent accéder au réseau spécifié. Par défaut, il n’y a pas de authorization rules et vous devez configurer des authorization rules pour permettre aux utilisateurs d’accéder aux ressources et aux réseaux.
• Client : L’utilisateur final se connectant au Client VPN endpoint pour établir une session VPN. Les utilisateurs finaux doivent télécharger un client OpenVPN et utiliser le fichier de configuration Client VPN que vous avez créé pour établir une session VPN.
• Client CIDR range : Une plage d’adresses IP à partir de laquelle attribuer des adresses IP aux clients. Chaque connexion au Client VPN endpoint se voit attribuer une adresse IP unique à partir du client CIDR range. Vous choisissez le client CIDR range, par exemple, 10.2.0.0/16.
• Client VPN ports : AWS Client VPN prend en charge les ports 443 et 1194 pour TCP et UDP. Le port par défaut est 443.
• Client VPN network interfaces : Lorsque vous associez un subnet à votre Client VPN endpoint, nous créons des Client VPN network interfaces dans ce subnet. Le trafic envoyé au VPC depuis le Client VPN endpoint est envoyé via une Client VPN network interface. La traduction d’adresse réseau source (SNAT) est alors appliquée, où l’adresse IP source provenant du client CIDR range est traduite vers l’adresse IP de la Client VPN network interface.
• Connection logging : Vous pouvez activer la journalisation des connexions pour votre Client VPN endpoint afin d’enregistrer les événements de connexion. Vous pouvez utiliser ces informations pour effectuer des analyses forensics, analyser comment votre Client VPN endpoint est utilisé, ou déboguer des problèmes de connexion.
• Self-service portal : Vous pouvez activer un self-service portal pour votre Client VPN endpoint. Les clients peuvent se connecter au portail web avec leurs identifiants et télécharger la dernière version du fichier de configuration du Client VPN endpoint, ou la dernière version du client fourni par AWS.

Limitations

• Les client CIDR ranges ne peuvent pas se chevaucher avec le CIDR local du VPC dans lequel se trouve le subnet associé, ou avec toute route ajoutée manuellement à la table de routage du Client VPN endpoint.
• Les client CIDR ranges doivent avoir une taille de bloc d’au moins /22 et ne doivent pas être supérieurs à /12.
• Une partie des adresses dans le client CIDR range est utilisée pour soutenir le modèle de disponibilité du Client VPN endpoint, et ne peut pas être attribuée aux clients. Par conséquent, nous recommandons d’attribuer un bloc CIDR contenant deux fois le nombre d’adresses IP nécessaires pour permettre le nombre maximal de connexions simultanées que vous prévoyez de supporter sur le Client VPN endpoint.
• Le client CIDR range ne peut pas être modifié après la création du Client VPN endpoint.
• Les subnets associés à un Client VPN endpoint doivent être dans le même VPC.
• Vous ne pouvez pas associer plusieurs subnets de la même Availability Zone à un Client VPN endpoint.
• Un Client VPN endpoint ne prend pas en charge les associations de subnets dans un VPC à tenancy dédiée.
• Client VPN prend en charge uniquement le trafic IPv4.
• Client VPN n’est pas conforme aux Federal Information Processing Standards (FIPS).
• Si l’authentification multi-facteurs (MFA) est désactivée pour votre Active Directory, un mot de passe utilisateur ne peut pas être au format suivant.

SCRV1:<base64_encoded_string>:<base64_encoded_string>

• Le self-service portal n’est pas disponible pour les clients qui s’authentifient en utilisant mutual authentication.

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.