mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-s3-a
This commit is contained in:
Translator
@@ -4,147 +4,147 @@
|
||||
|
||||
## Mise en réseau AWS en bref
|
||||
|
||||
Une **VPC** contient un **CIDR réseau** comme 10.0.0.0/16 (avec sa **table de routage** et son **ACL réseau**).
|
||||
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é** à la **VPC**, à la **table de routage** et à l'**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, les **interfaces réseau** attachées aux services (comme les instances EC2) sont **connectées** aux **sous-réseaux** avec des **groupes de sécurité**.
|
||||
Ensuite, des **Network Interface** attachées aux services (comme les instances EC2) sont **connectées** aux **sous-réseaux** avec des **security group(s)**.
|
||||
|
||||
Ainsi, un **groupe de sécurité** limitera les ports exposés des **interfaces réseau** qui l'utilisent, **indépendamment du sous-réseau**. Et une **ACL réseau** **limitera** les ports exposés à **l'ensemble du réseau**.
|
||||
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 **attribuer automatiquement des adresses IPv4 publiques**
|
||||
- Une **instance** créée dans un réseau dont les adresses IPv4 sont attribuées automatiquement peut en recevoir une
|
||||
- Une **passerelle Internet** doit être **attachée** à la **VPC**
|
||||
- Vous pouvez également utiliser des **Egress-only internet gateways**
|
||||
- Vous pouvez également avoir une **NAT gateway** dans un **sous-réseau privé** : il est alors possible de **se connecter à des services externes** depuis ce sous-réseau privé, mais il **n'est pas possible de les atteindre depuis l'extérieur**.
|
||||
- La NAT gateway peut être **publique** (accès à Internet) ou **privée** (accès à d'autres VPC)
|
||||
- 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)
|
||||
|
||||
.png>)
|
||||
|
||||
## 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 passerelles Internet pour accéder à Internet, des ACL, des groupes de sécurité, des IP...
|
||||
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...
|
||||
|
||||
### Sous-réseaux
|
||||
### Subnets
|
||||
|
||||
Les sous-réseaux aident à renforcer le niveau de sécurité. Le **regroupement logique de ressources similaires** facilite également la **gestion** de votre infrastructure.
|
||||
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 masque /16 à /28.
|
||||
- Un sous-réseau ne peut pas être dans plusieurs zones de disponibilité en même temps.
|
||||
- **AWS réserve les trois premières adresses IP hôtes** de chaque sous-réseau **pour** **un usage interne AWS** : la première adresse hôte est utilisée pour le routeur VPC. La deuxième adresse est réservée pour le DNS AWS et la troisième adresse est réservée pour un usage futur.
|
||||
- On appelle **sous-réseaux publics** ceux qui ont un **accès direct à Internet**, tandis que les sous-réseaux privés n'en ont pas.
|
||||
- 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.
|
||||
|
||||
### Tables de routage
|
||||
### Route Tables
|
||||
|
||||
Les tables de routage déterminent le routage du trafic pour un sous-réseau au sein d'une VPC. Elles déterminent quel trafic réseau est transféré vers Internet ou vers une connexion VPN. Vous trouverez généralement l'accès à :
|
||||
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 :
|
||||
|
||||
- VPC local
|
||||
- NAT
|
||||
- Passerelles Internet / Egress-only Internet gateways (nécessaires pour donner à une VPC l'accès à Internet).
|
||||
- Pour rendre un sous-réseau public, vous devez **créer** et **attacher** une **passerelle Internet** à votre VPC.
|
||||
- Endpoints VPC (pour accéder à S3 depuis des réseaux privés)
|
||||
- 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 ACL réseau sont des règles de pare-feu qui contrôlent le trafic réseau entrant et sortant d'un sous-réseau. Elles peuvent être utilisées pour autoriser ou refuser le trafic vers des adresses IP ou des plages spécifiques.
|
||||
**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 groupes de sécurité, mais c'est le seul moyen de couper complètement des reverse shells déjà établis. Une règle modifiée dans un groupe de sécurité n'arrête pas les connexions déjà établies.
|
||||
- Cependant, cela s'applique à l'ensemble du sous-réseau : faites attention en interdisant des éléments car des fonctionnalités nécessaires pourraient être perturbées.
|
||||
- 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.
|
||||
|
||||
### Groupes de sécurité
|
||||
### Security Groups
|
||||
|
||||
Les groupes de sécurité sont un **pare-feu** virtuel qui contrôle le trafic réseau entrant et sortant **vers les instances** dans une VPC. Relation 1 SG à N instances (généralement 1 pour 1).\
|
||||
Généralement, ils sont utilisés pour ouvrir des ports dangereux sur les instances, par exemple le port 22 :
|
||||
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 :
|
||||
|
||||
<figure><img src="https://lh5.googleusercontent.com/LliB7eb3cYfkEyOpyw1-eYgWsn2kq1yF6uRn5VYndvOuTvDlURimYx9UvuK8F2impTLmx50mid4MdTXE-Ljt2i_rxaIfnKUdji_hFjCdU9tdoW-axng9-W4tSL71gbbjrPQ7IYY5lAdH_G3UoMRMGGGOxQ=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### 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 tant que vous ne la libérez pas. En utilisant une Elastic IP address, vous pouvez masquer l'échec d'une instance ou d'un logiciel en réaffectant rapidement l'adresse à une autre instance de votre compte.
|
||||
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.
|
||||
|
||||
### Connexion entre sous-réseaux
|
||||
### Connection between subnets
|
||||
|
||||
Par défaut, tous les sous-réseaux ont l'**attribution automatique d'adresses IP publiques désactivée**, mais elle peut être activée.
|
||||
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 d'une VPC.**
|
||||
**Une route locale dans une table de routage permet la communication entre les sous-réseaux du VPC.**
|
||||
|
||||
Si vous **connectez un sous-réseau à un autre sous-réseau, vous ne pouvez pas accéder aux sous-réseaux connectés** à ce dernier ; vous devez créer une connexion directe avec eux. **Cela s'applique aussi aux passerelles Internet**. Vous ne pouvez pas passer par une connexion de sous-réseau pour accéder à Internet ; vous devez affecter la passerelle Internet à votre sous-réseau.
|
||||
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**, en utilisant IPv4 ou IPv6, comme s'ils faisaient partie du même réseau.
|
||||
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é peer établie, **les ressources d'une 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, donc elle est très disponible et sans goulot d'étranglement de bande passante. Comme **les connexions en peering fonctionnent comme si elles faisaient partie du même réseau**, il y a des restrictions concernant les plages de blocs CIDR pouvant être utilisées.\
|
||||
Si vous avez des plages CIDR **chevauchantes ou dupliquées**, vous **ne pourrez pas mettre en peering 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 entre VPC 2 et VPC 3 comme illustré, alors VPC 1 et 2 peuvent communiquer directement entre eux, tout comme VPC 2 et VPC 3 ; en revanche, VPC 1 et VPC 3 ne le pourraient pas. **Vous ne pouvez pas router via une VPC pour atteindre une autre.**
|
||||
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 communiquant entre différents sous-réseaux publics et privés, ainsi qu'entre différentes VPC via des connexions de peering. **VPC Flow Logs vous permettent de capturer les informations du trafic IP qui transitent entre les interfaces réseau de vos ressources au sein de votre VPC**.
|
||||
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 journaux d'accès S3 et CloudFront, les **données de logs générées par VPC Flow Logs ne sont pas stockées dans S3. Au lieu de cela, les données capturées sont envoyées vers CloudWatch Logs**.
|
||||
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 utilisez une connexion de peering VPC, vous ne pourrez voir les flow logs des VPC en peering que s'ils appartiennent au même compte.
|
||||
- Si vous exécutez encore des ressources dans l'environnement EC2-Classic, vous ne pouvez malheureusement 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 d'un 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 de la VPC, le trafic des instances à destination du serveur DNS Amazon.
|
||||
- Tout trafic destiné à l'adresse IP du routeur par défaut de la VPC et le trafic à destination et en provenance des adresses suivantes : 169.254.169.254 (utilisée pour la récupération des metadata d'instance) et 169.254.169.123 (utilisée pour le Amazon Time Sync Service).
|
||||
- Le trafic relatif à une licence d'activation Windows Amazon depuis une instance Windows
|
||||
- Le trafic entre une interface de network load balancer et une interface réseau d'endpoint
|
||||
- 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, une log stream différente est utilisée. Et dans chacune de ces streams, il y aura les données d'événements 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**.
|
||||
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
|
||||
|
||||
### Composants de base du VPN AWS
|
||||
### 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.
|
||||
- Il s'agit essentiellement d'un dispositif physique ou d'une application logicielle de votre côté de la connexion Site-to-Site VPN.
|
||||
- Vous fournissez des informations de routage et l'adresse IP publique de votre périphérique réseau (par exemple un routeur ou un pare-feu) à AWS pour créer un Customer Gateway.
|
||||
- Il sert de point de référence pour la configuration de la connexion VPN et n'entraîne pas de frais supplémentaires.
|
||||
- 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.
|
||||
- VPG est le point de terminaison du côté AWS pour la 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 connexion Site-to-Site VPN relie votre réseau on-premises à une VPC via un tunnel VPN sécurisé IPsec.
|
||||
- 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.
|
||||
- Généralement utilisé pour des connexions régulières et de long terme et facturé en fonction du volume de données transférées sur la connexion.
|
||||
- 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 les sessions VPN des clients.
|
||||
- Il sert à permettre à des appareils individuels (ordinateurs portables, smartphones, etc.) de se connecter en toute sécurité aux ressources AWS ou à votre réseau on-premises.
|
||||
- Il diffère du Site-to-Site VPN en ce qu'il est conçu pour des clients individuels plutôt que pour connecter des réseaux entiers.
|
||||
- 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ù les données peuvent transiter entre le réseau client et AWS.
|
||||
- **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 connexion VPN comprend deux tunnels VPN que vous pouvez utiliser simultanément pour une haute disponibilité.
|
||||
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 sur votre dispositif Customer gateway.
|
||||
- **Customer gateway device** : un dispositif 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 passerelle 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 vos réseaux on-premises. Vous utilisez un transit gateway ou un virtual private gateway comme passerelle pour le côté Amazon de la connexion Site-to-Site VPN.
|
||||
- **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 VPN AWS ne prend pas en charge la découverte du Path MTU (Path MTU Discovery).
|
||||
- Une connexion AWS VPN ne prend pas en charge Path MTU Discovery.
|
||||
|
||||
De plus, prenez en compte les éléments suivants lorsque vous utilisez Site-to-Site VPN.
|
||||
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, il est recommandé d'utiliser des blocs CIDR non chevauchants pour vos réseaux.
|
||||
- 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 <a href="#what-is-components" id="what-is-components"></a>
|
||||
|
||||
@@ -152,34 +152,34 @@ De plus, prenez en compte les éléments suivants lorsque vous utilisez Site-to-
|
||||
|
||||
#### 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 VPN clients sont terminées.
|
||||
- **Target network :** Un target network est le réseau que vous associez à un Client VPN endpoint. **Un sous-réseau d'une VPC est un target network**. Associer un sous-réseau à un Client VPN endpoint vous permet d'établir des sessions VPN. Vous pouvez associer plusieurs sous-réseaux à un Client VPN endpoint pour la haute disponibilité. Tous les sous-réseaux doivent appartenir à la même VPC. Chaque sous-réseau doit appartenir à une zone de disponibilité différente.
|
||||
- **Route :** Chaque Client VPN endpoint dispose d'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 fournisseur d'identité (IdP) qui est autorisé à accéder. 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 réseaux.
|
||||
- **Client :** L'utilisateur final se connectant au Client VPN endpoint pour établir une session VPN. Les utilisateurs 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 assigner les adresses IP des clients. Chaque connexion au Client VPN endpoint se voit attribuer une adresse IP unique provenant de la plage client CIDR. Vous choisissez la plage client CIDR, par exemple, `10.2.0.0/16`.
|
||||
- **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 sous-réseau à votre Client VPN endpoint, nous créons des interfaces réseau Client VPN dans ce sous-réseau. **Le trafic envoyé à la VPC depuis le Client VPN endpoint est acheminé via une interface réseau Client VPN**. Une traduction d'adresse source (SNAT) est ensuite appliquée, où l'adresse IP source provenant de la plage client CIDR est traduite vers l'adresse IP de l'interface réseau Client VPN.
|
||||
- **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 mener des analyses forensiques, analyser l'utilisation de votre Client VPN endpoint ou déboguer des problèmes de connexion.
|
||||
- **Self-service portal :** Vous pouvez activer un portail self-service 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.
|
||||
- **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 plages Client CIDR ne peuvent pas chevaucher le CIDR local** de la VPC dans laquelle le sous-réseau associé se trouve, ni aucune route ajoutée manuellement à la table de routage du Client VPN endpoint.
|
||||
- Les plages Client CIDR doivent avoir une taille de bloc d'**au moins /22** et ne doivent **pas être supérieures à /12.**
|
||||
- Une **partie des adresses** de la plage client CIDR est utilisée pour **prendre en charge 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.
|
||||
- La **plage client CIDR ne peut pas être modifiée** après la création du Client VPN endpoint.
|
||||
- Les **sous-réseaux** associés à un Client VPN endpoint **doivent être dans la même VPC**.
|
||||
- Vous **ne pouvez pas associer plusieurs sous-réseaux de la même zone de disponibilité à un Client VPN endpoint**.
|
||||
- Un Client VPN endpoint **ne prend pas en charge les associations de sous-réseaux dans une VPC à tenancy dédiée**.
|
||||
- Client VPN ne prend en charge que le trafic **IPv4**.
|
||||
- Client VPN n'est **pas** conforme aux Federal Information Processing Standards (**FIPS**).
|
||||
- Si l'authentification multi-facteur (MFA) est désactivée pour votre Active Directory, un mot de passe utilisateur ne peut pas être dans le format suivant.
|
||||
- **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 portail self-service n'est **pas disponible pour les clients qui s'authentifient en utilisant l'authentification mutuelle**.
|
||||
- Le self-service portal **n'est pas disponible pour les clients qui s'authentifient en utilisant mutual authentication**.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - S3, Athena & Glacier Enum
|
||||
# AWS - S3, Athena & Glacier Enumération
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,32 +6,32 @@
|
||||
|
||||
Amazon S3 est un service qui vous permet de **stocker de grandes quantités de données**.
|
||||
|
||||
Amazon S3 offre plusieurs options pour assurer la **protection** des données au repos. Les options incluent **Permission** (Policy), **Encryption** (Client et Server Side), **Bucket Versioning** et **MFA** **based delete**. L'**utilisateur peut activer** n'importe laquelle de ces options pour assurer la protection des données. La **réplication des données** est une fonctionnalité interne d'AWS où **S3 réplique automatiquement chaque objet à travers toutes les Availability Zones** et l'organisation n'a pas besoin de l'activer dans ce cas.
|
||||
Amazon S3 fournit plusieurs options pour assurer la **protection** des données au repos. Les options incluent **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** et **MFA** **based delete**. L'**utilisateur peut activer** n'importe laquelle de ces options pour assurer la protection des données. La **réplication des données** est une fonctionnalité interne d'AWS où **S3 réplique automatiquement chaque objet dans toutes les Availability Zones** et l'organisation n'a pas besoin de l'activer dans ce cas.
|
||||
|
||||
Avec des permissions basées sur les ressources, vous pouvez définir séparément les permissions pour les sous-répertoires de votre bucket.
|
||||
Avec des permissions basées sur la ressource, vous pouvez définir séparément des permissions pour des sous-répertoires de votre bucket.
|
||||
|
||||
### Bucket Versioning and MFA based delete
|
||||
|
||||
Lorsque le bucket versioning est activé, toute action qui tente de modifier un fichier générera une nouvelle version du fichier, en conservant également le contenu précédent. Donc, le contenu ne sera pas écrasé.
|
||||
Lorsque le versioning du bucket est activé, toute action qui tente de modifier un fichier génère une nouvelle version du fichier, en conservant également le contenu précédent. Ainsi, le contenu n'est pas écrasé.
|
||||
|
||||
De plus, le MFA based delete empêchera que des versions de fichiers dans le bucket S3 soient supprimées et empêchera également la désactivation du Bucket Versioning, de sorte qu'un attaquant ne pourra pas altérer ces fichiers.
|
||||
De plus, la suppression basée sur MFA empêchera la suppression des versions de fichiers dans le bucket S3 et empêchera également la désactivation du Bucket Versioning, de sorte qu'un attaquant ne pourra pas altérer ces fichiers.
|
||||
|
||||
### S3 Access logs
|
||||
|
||||
Il est possible **d'activer les logs d'accès S3** (qui par défaut sont désactivés) pour un bucket et d'enregistrer les logs dans un autre bucket afin de savoir qui accède au bucket (les deux buckets doivent être dans la même région).
|
||||
Il est possible d'**activer les logs d'accès S3** (qui sont désactivés par défaut) pour un bucket et d'enregistrer les logs dans un bucket différent afin de savoir qui accède au bucket (les deux buckets doivent être dans la même région).
|
||||
|
||||
### S3 Presigned URLs
|
||||
|
||||
Il est possible de générer une presigned URL qui peut généralement être utilisée pour **accéder au fichier spécifié** dans le bucket. Une **presigned URL ressemble à ceci** :
|
||||
Il est possible de générer une presigned URL qui peut généralement être utilisée pour **accéder au fichier spécifié** dans le bucket. Une **presigned URL ressemble à ceci**:
|
||||
```
|
||||
https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa
|
||||
```
|
||||
Une presigned URL peut être **created from the cli using credentials of a principal with access to the object** (si le compte que vous utilisez n'a pas accès, une presigned URL plus courte sera créée mais elle sera inutile)
|
||||
Une presigned URL peut être **créée depuis le cli en utilisant les credentials d'un principal ayant accès à l'objet** (si le compte que vous utilisez n'a pas accès, une presigned URL plus courte sera créée mais elle sera inutile)
|
||||
```bash
|
||||
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
|
||||
```
|
||||
> [!NOTE]
|
||||
> La seule permission requise pour générer une presigned URL est la permission accordée, donc pour la commande précédente la seule permission nécessaire pour le principal est `s3:GetObject`
|
||||
> La seule permission requise pour générer un presigned URL est la permission qui est accordée, donc pour la commande précédente la seule permission nécessaire pour le principal est `s3:GetObject`
|
||||
|
||||
Il est également possible de créer des presigned URLs avec **d'autres permissions** :
|
||||
```python
|
||||
@@ -48,16 +48,16 @@ ExpiresIn=3600
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
|
||||
<summary><strong>Chiffrement côté serveur avec les clés gérées par S3, SSE-S3</strong></summary>
|
||||
|
||||
Cette option nécessite une configuration minimale et toute la gestion des clés de chiffrement est assurée par AWS. Tout ce que vous devez faire est de **téléverser vos données et S3 s'occupera de tous les autres aspects**. Chaque bucket dans un compte S3 se voit attribuer une bucket key.
|
||||
Cette option requiert une configuration minimale et toute la gestion des clés de chiffrement est gérée par AWS. Tout ce que vous avez à faire est de **téléverser vos données et S3 s'occupe de tous les autres aspects**. Chaque bucket dans un compte S3 se voit attribuer une bucket key.
|
||||
|
||||
- Encryption:
|
||||
- Données de l'objet + DEK en clair créé --> Données chiffrées (stockées dans S3)
|
||||
- DEK en clair créé + S3 Master Key --> DEK chiffré (stocké dans S3) et le texte en clair est supprimé de la mémoire
|
||||
- Decryption:
|
||||
- DEK chiffré + S3 Master Key --> DEK en clair
|
||||
- DEK en clair + Données chiffrées --> Données de l'objet
|
||||
- Chiffrement :
|
||||
- Object Data + created plaintext DEK --> Encrypted data (stored inside S3)
|
||||
- Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) and plain text is deleted from memory
|
||||
- Déchiffrement :
|
||||
- Encrypted DEK + S3 Master Key --> Plaintext DEK
|
||||
- Plaintext DEK + Encrypted data --> Object Data
|
||||
|
||||
Veuillez noter que dans ce cas **la clé est gérée par AWS** (rotation seulement tous les 3 ans). Si vous utilisez votre propre clé, vous pourrez la faire tourner, la désactiver et appliquer des contrôles d'accès.
|
||||
|
||||
@@ -65,76 +65,76 @@ Veuillez noter que dans ce cas **la clé est gérée par AWS** (rotation seuleme
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
|
||||
<summary><strong>Chiffrement côté serveur avec les clés gérées par KMS, SSE-KMS</strong></summary>
|
||||
|
||||
Cette méthode permet à S3 d'utiliser le key management service pour générer vos data encryption keys. KMS vous offre une bien plus grande flexibilité sur la façon dont vos clés sont gérées. Par exemple, vous pouvez désactiver, faire pivoter et appliquer des contrôles d'accès au CMK, et auditer leur utilisation via AWS Cloud Trail.
|
||||
Cette méthode permet à S3 d'utiliser le key management service pour générer vos data encryption keys. KMS vous offre une bien plus grande flexibilité sur la gestion de vos clés. Par exemple, vous pouvez désactiver, faire tourner et appliquer des contrôles d'accès au CMK, et auditer leur utilisation via AWS Cloud Trail.
|
||||
|
||||
- Encryption:
|
||||
- S3 demande des data keys à KMS CMK
|
||||
- KMS utilise un CMK pour générer la paire DEK en clair et DEK chiffré et les envoie à S£
|
||||
- S3 utilise la clé en clair pour chiffrer les données, stocke les données chiffrées et la clé chiffrée et supprime de la mémoire la clé en clair
|
||||
- Decryption:
|
||||
- S3 demande à KMS de déchiffrer la data key chiffrée de l'objet
|
||||
- KMS déchiffre la data key avec le CMK et la renvoie à S3
|
||||
- S3 déchiffre les données de l'objet
|
||||
- Chiffrement :
|
||||
- S3 request data keys from KMS CMK
|
||||
- KMS uses a CMK to generate the pair DEK plaintext and DEK encrypted and send them to S£
|
||||
- S3 uses the paintext key to encrypt the data, store the encrypted data and the encrypted key and deletes from memory the plain text key
|
||||
- Déchiffrement :
|
||||
- S3 ask to KMS to decrypt the encrypted data key of the object
|
||||
- KMS decrypt the data key with the CMK and send it back to S3
|
||||
- S3 decrypts the object data
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
|
||||
<summary><strong>Chiffrement côté serveur avec des clés fournies par le client, SSE-C</strong></summary>
|
||||
|
||||
Cette option vous permet de fournir votre propre master key que vous utilisez peut-être déjà en dehors d'AWS. Votre clé fournie par le client serait alors envoyée avec vos données à S3, où S3 effectuerait le chiffrement pour vous.
|
||||
Cette option vous donne la possibilité de fournir votre propre master key que vous utilisez peut‑être déjà en dehors d'AWS. Votre clé fournie par le client serait alors envoyée avec vos données à S3, où S3 effectuerait le chiffrement pour vous.
|
||||
|
||||
- Encryption:
|
||||
- L'utilisateur envoie les données de l'objet + la clé client à S3
|
||||
- La clé client est utilisée pour chiffrer les données et les données chiffrées sont stockées
|
||||
- une valeur HMAC salée de la clé client est également stockée pour une validation future de la clé
|
||||
- la clé client est supprimée de la mémoire
|
||||
- Decryption:
|
||||
- L'utilisateur envoie la clé client
|
||||
- La clé est validée contre la valeur HMAC stockée
|
||||
- La clé fournie par le client est alors utilisée pour déchiffrer les données
|
||||
- Chiffrement :
|
||||
- The user sends the object data + Customer key to S3
|
||||
- The customer key is used to encrypt the data and the encrypted data is stored
|
||||
- a salted HMAC value of the customer key is stored also for future key validation
|
||||
- the customer key is deleted from memory
|
||||
- Déchiffrement :
|
||||
- The user send the customer key
|
||||
- The key is validated against the HMAC value stored
|
||||
- The customer provided key is then used to decrypt the data
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
|
||||
<summary><strong>Chiffrement côté client avec KMS, CSE-KMS</strong></summary>
|
||||
|
||||
De manière similaire à SSE-KMS, ceci utilise aussi le key management service pour générer vos data encryption keys. Cependant, cette fois KMS est appelé via le client et non S3. Le chiffrement a alors lieu côté client et les données chiffrées sont ensuite envoyées à S3 pour être stockées.
|
||||
Comme pour SSE-KMS, cela utilise également le key management service pour générer vos data encryption keys. Cependant, cette fois KMS est appelé par le client et non par S3. Le chiffrement a alors lieu côté client et les données chiffrées sont ensuite envoyées à S3 pour stockage.
|
||||
|
||||
- Encryption:
|
||||
- Le client demande une data key à KMS
|
||||
- KMS renvoie la DEK en clair et la DEK chiffrée avec le CMK
|
||||
- Les deux clés sont renvoyées
|
||||
- Le client chiffre ensuite les données avec la DEK en clair et envoie à S3 les données chiffrées + la DEK chiffrée (qui est sauvegardée en tant que metadata des données chiffrées dans S3)
|
||||
- Decryption:
|
||||
- Les données chiffrées avec la DEK chiffrée sont envoyées au client
|
||||
- Le client demande à KMS de déchiffrer la clé chiffrée en utilisant le CMK et KMS renvoie la DEK en clair
|
||||
- Le client peut maintenant déchiffrer les données chiffrées
|
||||
- Chiffrement :
|
||||
- Client request for a data key to KMS
|
||||
- KMS returns the plaintext DEK and the encrypted DEK with the CMK
|
||||
- Both keys are sent back
|
||||
- The client then encrypts the data with the plaintext DEK and send to S3 the encrypted data + the encrypted DEK (which is saved as metadata of the encrypted data inside S3)
|
||||
- Déchiffrement :
|
||||
- The encrypted data with the encrypted DEK is sent to the client
|
||||
- The client asks KMS to decrypt the encrypted key using the CMK and KMS sends back the plaintext DEK
|
||||
- The client can now decrypt the encrypted data
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
|
||||
<summary><strong>Chiffrement côté client avec des clés fournies par le client, CSE-C</strong></summary>
|
||||
|
||||
Avec ce mécanisme, vous pouvez utiliser vos propres clés fournies et un client AWS-SDK pour chiffrer vos données avant de les envoyer à S3 pour stockage.
|
||||
Avec ce mécanisme, vous pouvez utiliser vos propres clés fournies et utiliser un client AWS-SDK pour chiffrer vos données avant de les envoyer à S3 pour stockage.
|
||||
|
||||
- Encryption:
|
||||
- Le client génère une DEK et chiffre les données en clair
|
||||
- Ensuite, en utilisant son propre CMK personnalisé, il chiffre la DEK
|
||||
- soumet les données chiffrées + DEK chiffrée à S3 où elles sont stockées
|
||||
- Decryption:
|
||||
- S3 envoie les données chiffrées et la DEK chiffrée
|
||||
- Comme le client possède déjà le CMK utilisé pour chiffrer la DEK, il déchiffre la DEK puis utilise la DEK en clair pour déchiffrer les données
|
||||
- Chiffrement :
|
||||
- The client generates a DEK and encrypts the plaintext data
|
||||
- Then, using it's own custom CMK it encrypts the DEK
|
||||
- submit the encrypted data + encrypted DEK to S3 where it's stored
|
||||
- Déchiffrement :
|
||||
- S3 sends the encrypted data and DEK
|
||||
- As the client already has the CMK used to encrypt the DEK, it decrypts the DEK and then uses the plaintext DEK to decrypt the data
|
||||
|
||||
</details>
|
||||
|
||||
### **Enumeration**
|
||||
### **Enumération**
|
||||
|
||||
Une des principales méthodes traditionnelles pour compromettre des organisations AWS commence par compromettre des buckets accessibles publiquement. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
|
||||
Une des voies traditionnelles principales pour compromettre des organisations AWS commence par compromettre des buckets publics accessibles. **Vous pouvez trouver** [**des outils d'énumération de buckets publics sur cette page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
|
||||
```bash
|
||||
# Get buckets ACLs
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -229,9 +229,9 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
|
||||
|
||||
Vous pouvez accéder à un bucket S3 via un endpoint dual-stack en utilisant un nom d'endpoint virtual hosted-style ou path-style. Ceux-ci sont utiles pour accéder à S3 via IPv6.
|
||||
Vous pouvez accéder à un bucket S3 via un endpoint dual-stack en utilisant un nom d'endpoint de type virtual hosted-style ou path-style. Ceux-ci sont utiles pour accéder à S3 via IPv6.
|
||||
|
||||
Dual-stack endpoints use the following syntax:
|
||||
Les endpoints dual-stack utilisent la syntaxe suivante :
|
||||
|
||||
- `bucketname.s3.dualstack.aws-region.amazonaws.com`
|
||||
- `s3.dualstack.aws-region.amazonaws.com/bucketname`
|
||||
@@ -266,19 +266,19 @@ In the following page you can check how to **abuse S3 permissions to escalate pr
|
||||
|
||||
### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
|
||||
|
||||
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) il était possible de mettre en cache la réponse d'un bucket arbitraire comme si elle appartenait à un autre. Cela aurait pu être abusé pour modifier, par exemple, les réponses de fichiers javascript et compromettre des pages arbitraires utilisant S3 pour stocker du code statique.
|
||||
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) il était possible de mettre en cache la réponse d'un bucket arbitraire comme si elle appartenait à un autre. Cela pouvait être abusé pour modifier, par exemple, les réponses de fichiers javascript et compromettre des pages arbitraires utilisant S3 pour stocker du code statique.
|
||||
|
||||
## Amazon Athena
|
||||
|
||||
Amazon Athena is an interactive query service that makes it easy to **analyze data** directly in Amazon Simple Storage Service (Amazon **S3**) **using** standard **SQL**.
|
||||
Amazon Athena est un service de requêtes interactives qui facilite l'analyse des données directement dans Amazon Simple Storage Service (Amazon **S3**) en utilisant le standard **SQL**.
|
||||
|
||||
You need to **prepare a relational DB table** with the format of the content that is going to appear in the monitored S3 buckets. And then, Amazon Athena will be able to populate the DB from the logs, so you can query it.
|
||||
Vous devez **préparer une table DB relationnelle** avec le format du contenu qui va apparaître dans les buckets S3 surveillés. Ensuite, Amazon Athena pourra peupler la DB à partir des logs, afin que vous puissiez l'interroger.
|
||||
|
||||
Amazon Athena supports the **ability to query S3 data that is already encrypted** and if configured to do so, **Athena can also encrypt the results of the query which can then be stored in S3**.
|
||||
Amazon Athena prend en charge la capacité d'interroger des données S3 qui sont déjà chiffrées et, si configuré pour le faire, **Athena peut aussi chiffrer les résultats de la requête qui peuvent ensuite être stockés dans S3**.
|
||||
|
||||
**This encryption of results is independent of the underlying queried S3 data**, meaning that even if the S3 data is not encrypted, the queried results can be encrypted. A couple of points to be aware of is that Amazon Athena only supports data that has been **encrypted** with the **following S3 encryption methods**, **SSE-S3, SSE-KMS, and CSE-KMS**.
|
||||
**Ce chiffrement des résultats est indépendant des données S3 sous-jacentes interrogées**, ce qui signifie que même si les données S3 ne sont pas chiffrées, les résultats des requêtes peuvent l'être. Quelques points à noter : Amazon Athena ne supporte que les données qui ont été **chiffrées** avec les **méthodes de chiffrement S3 suivantes**, **SSE-S3, SSE-KMS, et CSE-KMS**.
|
||||
|
||||
SSE-C and CSE-C are not supported. In addition to this, it's important to understand that Amazon Athena will only run queries against **encrypted objects that are in the same region as the query itself**. If you need to query S3 data that's been encrypted using KMS, then specific permissions are required by the Athena user to enable them to perform the query.
|
||||
SSE-C et CSE-C ne sont pas supportés. De plus, il est important de comprendre qu'Amazon Athena n'exécutera des requêtes que contre des objets chiffrés qui se trouvent dans la même région que la requête elle-même. Si vous devez interroger des données S3 qui ont été chiffrées en utilisant KMS, alors des permissions spécifiques sont requises pour l'utilisateur Athena afin de lui permettre d'exécuter la requête.
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user