Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-s3-a

src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md

@@ -1,102 +1,102 @@
-# AWS - VPC & Netzwerk Grundlegende Informationen
+# AWS - VPC & Networking Grundlegende Informationen
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## AWS Netzwerk kurz erklärt
+## AWS Networking im Überblick
 
-Eine **VPC** enthält einen **Network CIDR** wie 10.0.0.0/16 (mit seiner **Routing-Tabelle** und **Network ACL**).
+Eine **VPC** enthält einen **Netzwerk-CIDR** wie 10.0.0.0/16 (mit seiner **Routing-Tabelle** und **network ACL**).
 
-Dieses VPC-Netzwerk wird in **Subnetze** unterteilt, daher ist ein **Subnetz** direkt mit der **VPC**, der **Routing-Tabelle** und der **Network ACL** verknüpft.
+Dieses VPC-Netzwerk ist in **Subnetze** unterteilt, daher ist ein **Subnetz** direkt mit der **VPC**, der **Routing-Tabelle** und der **network ACL** verknüpft.
 
-Dann werden **Network Interface**s, die an Dienste (wie EC2-Instanzen) angehängt sind, mit **Subnetzen** und **Security Group(s)** verbunden.
+Network Interfaces, die an Dienste (z. B. EC2-Instanzen) angehängt sind, sind mit den **Subnetzen** verbunden und nutzen **Security Group(s)**.
 
-Daher wird eine **Security Group** die exponierten Ports der sie verwendenden **Network Interfaces** beschränken, **unabhängig vom Subnetz**. Und eine **Network ACL** wird die exponierten Ports für das **gesamte Netzwerk** einschränken.
+Daher begrenzt eine **Security Group** die exponierten Ports der Netzwerkschnittstellen, die sie verwenden, **unabhängig vom Subnetz**. Und eine **network ACL** begrenzt die exponierten Ports für das **gesamte Netzwerk**.
 
-Außerdem gibt es, um auf das Internet zuzugreifen, einige interessante Konfigurationen zu prüfen:
+Außerdem gibt es einige interessante Konfigurationen, die man prüfen sollte, um auf das Internet zuzugreifen:
 
 - Ein **Subnetz** kann **automatisch öffentliche IPv4-Adressen zuweisen**.
-- Eine im Netzwerk erstellte **Instance**, wenn das Subnetz **Auto-Assign IPv4-Adressen** aktiviert hat, kann eine erhalten.
-- Ein **Internet gateway** muss an die **VPC** **angeschlossen** sein.
-- Man kann auch **Egress-only internet gateways** verwenden.
-- Man kann auch ein **NAT gateway** in einem **privaten Subnetz** haben, sodass es möglich ist, von diesem privaten Subnetz aus **auf externe Dienste zuzugreifen**, aber es ist **nicht möglich, von außen auf sie zuzugreifen**.
-- Das NAT gateway kann **public** (Zugang zum Internet) oder **private** (Zugang zu anderen VPCs) sein.
+- Eine **Instanz**, die in einem Subnetz erstellt wird, das **automatisch IPv4-Adressen zuweist**, kann eine solche Adresse erhalten.
+- Ein **Internet gateway** muss an die **VPC** **angehängt** werden.
+- Es können auch **Egress-only internet gateways** verwendet werden.
+- Man kann auch ein **NAT gateway** in einem **privaten Subnetz** haben, sodass aus diesem privaten Subnetz heraus eine Verbindung zu externen Diensten möglich ist, es aber **nicht möglich ist, von außen darauf zuzugreifen**.
+- Das NAT gateway kann **öffentlich** (Zugriff auf das Internet) oder **privat** (Zugriff auf andere VPCs) sein.
 
 ![](<../../../../images/image (274).png>)
 
 ## VPC
 
-Amazon **Virtual Private Cloud** (Amazon VPC) ermöglicht es Ihnen, **AWS-Ressourcen in einem von Ihnen definierten virtuellen Netzwerk zu starten**. Dieses virtuelle Netzwerk wird mehrere Subnetze, Internet Gateways zum Zugriff auf das Internet, ACLs, Security Groups, IPs ... enthalten.
+Amazon **Virtual Private Cloud** (Amazon VPC) ermöglicht es Ihnen, **AWS-Ressourcen in ein von Ihnen definiertes virtuelles Netzwerk zu starten**. Dieses virtuelle Netzwerk hat mehrere Subnetze, Internet Gateways für den Internetzugang, ACLs, Security Groups, IPs...
 
 ### Subnets
 
-Subnets helfen, ein höheres Maß an Sicherheit durchzusetzen. Die **logische Gruppierung ähnlicher Ressourcen** erleichtert außerdem die **Verwaltung** Ihrer Infrastruktur.
+Subnetze helfen, ein höheres Maß an Sicherheit durchzusetzen. Die **logische Gruppierung ähnlicher Ressourcen** erleichtert auch die **Verwaltung** Ihrer Infrastruktur.
 
-- Gültige CIDR reichen von einer /16-Netzmaske bis zu einer /28-Netzmaske.
+- Gültige CIDR sind von einer /16-Netzmaske bis zu einer /28-Netzmaske.
 - Ein Subnetz kann nicht gleichzeitig in verschiedenen Availability Zones liegen.
-- **AWS reserviert die ersten drei Host-IP-Adressen** jedes Subnetzes **für** **interne AWS-Nutzung**: Die erste Host-Adresse wird für den VPC-Router verwendet. Die zweite Adresse ist für AWS DNS reserviert und die dritte Adresse ist für zukünftige Verwendung reserviert.
-- Als **public subnets** werden jene bezeichnet, die **direkten Zugang zum Internet** haben, während private Subnets dies nicht tun.
+- **AWS reserviert die ersten drei Host-IP-Adressen** jedes Subnetzes **für** **interne AWS-Nutzung**: Die erste Host-Adresse wird vom VPC-Router verwendet. Die zweite Adresse ist für AWS DNS reserviert und die dritte Adresse ist für die zukünftige Nutzung reserviert.
+- Subnetze, die **direkten Zugriff auf das Internet haben**, werden als **public subnets** bezeichnet, während private Subnetze dies nicht tun.
 
 ### Route Tables
 
-Routing-Tabellen bestimmen das Routing des Datenverkehrs für ein Subnetz innerhalb einer VPC. Sie bestimmen, welcher Netzwerkverkehr an das Internet oder an eine VPN-Verbindung weitergeleitet wird. Üblicherweise finden Sie Einträge für:
+Route Tables bestimmen die Routing-Entscheidungen für ein Subnetz innerhalb einer VPC. Sie legen fest, welcher Netzwerkverkehr an das Internet oder eine VPN-Verbindung weitergeleitet wird. Üblicherweise findet man Routen zu:
 
-- Lokale VPC
+- Lokales VPC
 - NAT
-- Internet Gateways / Egress-only Internet Gateways (benötigt, um einer VPC Zugang zum Internet zu geben).
-- Um ein Subnetz öffentlich zu machen, müssen Sie ein **Internet gateway** für Ihre VPC **erstellen** und **anhängen**.
-- VPC Endpoints (um von privaten Netzwerken auf S3 zuzugreifen)
+- Internet Gateways / Egress-only Internet Gateways (benötigt, um einer VPC Zugriff auf das Internet zu geben).
+- Um ein Subnetz öffentlich zu machen, müssen Sie ein **Internet gateway** **erstellen** und an Ihre VPC **anhängen**.
+- VPC Endpoints (um z. B. S3 aus privaten Netzwerken zu erreichen)
 
 ### ACLs
 
-**Network Access Control Lists (ACLs)**: Network ACLs sind Firewall-Regeln, die eingehenden und ausgehenden Netzwerkverkehr zu einem Subnetz steuern. Sie können verwendet werden, um Verkehr zu bestimmten IP-Adressen oder Bereichen zu erlauben oder zu verweigern.
+**Network Access Control Lists (ACLs)**: Network ACLs sind Firewall-Regeln, die eingehenden und ausgehenden Netzwerkverkehr zu einem Subnetz kontrollieren. Sie können verwendet werden, um Verkehr zu bestimmten IP-Adressen oder -Bereichen zu erlauben oder zu blockieren.
 
-- Es ist am häufigsten, Zugriff über Security Groups zu erlauben/verweigern, aber dies ist die einzige Möglichkeit, bereits etablierte Reverse Shells vollständig zu unterbrechen. Eine geänderte Regel in einer Security Group stoppt bereits etablierte Verbindungen nicht.
-- Allerdings gilt dies für das gesamte Subnetz — seien Sie vorsichtig beim Sperren von Dingen, da benötigte Funktionalitäten gestört werden könnten.
+- Am häufigsten wird der Zugriff mit Security Groups erlaubt/abgelehnt, aber ACLs sind die einzige Möglichkeit, bereits etablierte Reverse Shells vollständig zu unterbrechen. Eine geänderte Regel in einer Security Group stoppt bereits etablierte Verbindungen nicht.
+- Allerdings gilt dies für das gesamte Subnetz; seien Sie vorsichtig beim Sperren, da dadurch benötigte Funktionalität gestört werden könnte.
 
 ### Security Groups
 
-Security Groups sind eine virtuelle **Firewall**, die eingehenden und ausgehenden Netzwerk**verkehr zu Instanzen** in einer VPC kontrolliert. Beziehung 1 SG zu mehreren Instanzen (meist 1 zu 1).  
-Normalerweise wird dies verwendet, um gefährliche Ports in Instanzen zu öffnen, wie zum Beispiel Port 22:
+Security Groups sind eine virtuelle **Firewall**, die den eingehenden und ausgehenden Netzwerkverkehr zu Instanzen in einer VPC kontrolliert. Verhältnis 1 SG zu mehreren Instanzen (normalerweise 1 zu 1).\
+Üblicherweise werden damit gefährliche Ports in Instanzen geöffnet, wie zum Beispiel Port 22:
 
 <figure><img src="https://lh5.googleusercontent.com/LliB7eb3cYfkEyOpyw1-eYgWsn2kq1yF6uRn5VYndvOuTvDlURimYx9UvuK8F2impTLmx50mid4MdTXE-Ljt2i_rxaIfnKUdji_hFjCdU9tdoW-axng9-W4tSL71gbbjrPQ7IYY5lAdH_G3UoMRMGGGOxQ=s2048" alt=""><figcaption></figcaption></figure>
 
 ### Elastic IP Addresses
 
-Eine _Elastic IP address_ ist eine **statische IPv4-Adresse**, die für dynamisches Cloud-Computing vorgesehen ist. Eine Elastic IP-Adresse wird Ihrem AWS-Konto zugewiesen und gehört Ihnen, bis Sie sie freigeben. Durch die Verwendung einer Elastic IP-Adresse können Sie das Versagen einer Instanz oder Software verschleiern, indem Sie die Adresse schnell einer anderen Instanz in Ihrem Konto neu zuweisen.
+Eine _Elastic IP address_ ist eine **statische IPv4-Adresse**, die für dynamisches Cloud-Computing vorgesehen ist. Eine Elastic IP-Adresse wird Ihrem AWS-Konto zugewiesen und gehört Ihnen, bis Sie sie freigeben. Durch die Verwendung einer Elastic IP-Adresse können Sie das Versagen einer Instanz oder Software kaschieren, indem Sie die Adresse schnell einer anderen Instanz in Ihrem Konto zuordnen.
 
 ### Verbindung zwischen Subnetzen
 
-Standardmäßig ist in allen Subnetzen die **automatische Zuweisung öffentlicher IP-Adressen deaktiviert**, kann aber aktiviert werden.
+Standardmäßig ist die **automatische Zuweisung öffentlicher IP-Adressen für alle Subnetze deaktiviert**, kann aber aktiviert werden.
 
-**Eine lokale Route innerhalb einer Routing-Tabelle ermöglicht die Kommunikation zwischen VPC-Subnetzen.**
+**Eine lokale Route innerhalb einer Route Table ermöglicht die Kommunikation zwischen VPC-Subnetzen.**
 
-Wenn Sie **ein Subnetz mit einem anderen Subnetz verbinden**, können Sie nicht auf die Subnetze zugreifen, die mit dem anderen Subnetz verbunden sind; Sie müssen Verbindungen direkt mit ihnen erstellen. **Das gilt auch für Internet Gateways.** Sie können nicht über eine Subnetzverbindung gehen, um auf das Internet zuzugreifen; Sie müssen das Internet Gateway an Ihr Subnetz zuweisen.
+Wenn Sie **ein Subnetz mit einem anderen Subnetz verbinden**, können Sie nicht automatisch auf die Subnetze zugreifen, die mit dem anderen Subnetz verbunden sind; Sie müssen direkte Verbindungen zu ihnen erstellen. **Dies gilt auch für Internet Gateways**. Sie können nicht über eine Subnetz-Verbindung auf das Internet zugreifen; das Internet Gateway muss Ihrem Subnetz zugewiesen werden.
 
 ### VPC Peering
 
-VPC Peering erlaubt es Ihnen, **zwei oder mehr VPCs miteinander zu verbinden**, unter Verwendung von IPv4 oder IPv6, als wären sie Teil desselben Netzwerks.
+VPC Peering ermöglicht es Ihnen, **zwei oder mehr VPCs miteinander zu verbinden**, unter Verwendung von IPv4 oder IPv6, als wären sie Teil desselben Netzwerks.
 
-Sobald die Peer-Konnektivität hergestellt ist, **können Ressourcen in einer VPC auf Ressourcen in der anderen zugreifen**. Die Verbindung zwischen den VPCs wird durch die bestehende AWS-Netzinfrastruktur implementiert und ist daher hochverfügbar ohne Bandbreitenengpässe. Da **peered-Verbindungen so arbeiten, als wären sie Teil desselben Netzwerks**, gibt es Einschränkungen hinsichtlich der verwendbaren CIDR-Blockbereiche.  
-Wenn Sie **sich überlappende oder identische CIDR**-Bereiche für Ihre VPC haben, **können Sie die VPCs nicht peeren**.  
-Jede AWS VPC wird **nur mit ihrem Peer** kommunizieren. Zum Beispiel: Wenn Sie eine Peering-Verbindung zwischen VPC 1 und VPC 2 haben und eine weitere Verbindung zwischen VPC 2 und VPC 3, dann können VPC 1 und 2 direkt miteinander kommunizieren, ebenso VPC 2 und VPC 3, jedoch könnten VPC 1 und VPC 3 nicht miteinander kommunizieren. **Sie können nicht durch eine VPC routen, um zu einer anderen zu gelangen.**
+Sobald die Peering-Verbindung hergestellt ist, **können Ressourcen in einer VPC auf Ressourcen in der anderen zugreifen**. Die Konnektivität zwischen den VPCs wird über die vorhandene AWS-Netzwerkinfrastruktur implementiert und ist daher hochverfügbar ohne Bandbreitenengpässe. Da **peered connections so agieren, als wären sie Teil desselben Netzwerks**, gibt es Einschränkungen bei den verwendbaren CIDR-Blockbereichen.\
+Wenn Sie **überlappende oder gleiche CIDR**-Bereiche für Ihre VPCs haben, können **Sie die VPCs nicht peeren**.\
+Jede AWS VPC **kommuniziert nur mit ihrem Peer**. Zum Beispiel: Wenn Sie eine Peering-Verbindung zwischen VPC 1 und VPC 2 haben und eine weitere Verbindung zwischen VPC 2 und VPC 3 wie gezeigt, dann könnten VPC 1 und VPC 2 direkt miteinander kommunizieren, ebenso VPC 2 und VPC 3; VPC 1 und VPC 3 könnten jedoch nicht kommunizieren. **Sie können nicht durch eine VPC routen, um zu einer anderen zu gelangen.**
 
-### **VPC Flow Logs**
+### VPC Flow Logs
 
-Innerhalb Ihrer VPC könnten sich Hunderte oder sogar Tausende von Ressourcen befinden, die zwischen verschiedenen Subnetzen sowohl öffentlich als auch privat sowie zwischen verschiedenen VPCs über VPC Peering-Verbindungen kommunizieren. **VPC Flow Logs ermöglichen es Ihnen, IP-Verkehrsinformationen zu erfassen, die zwischen den Netzwerkinterfaces Ihrer Ressourcen innerhalb Ihrer VPC fließen**.
+Innerhalb Ihrer VPC könnten Hunderte oder Tausende von Ressourcen sein, die zwischen verschiedenen Subnetzen (öffentlich und privat) und auch zwischen verschiedenen VPCs über VPC Peering-Verbindungen kommunizieren. **VPC Flow Logs ermöglichen es Ihnen, IP-Verkehrsinformationen zu erfassen, die zwischen den Network Interfaces Ihrer Ressourcen innerhalb Ihrer VPC fließen**.
 
-Im Gegensatz zu S3 Access Logs und CloudFront Access Logs werden die **durch VPC Flow Logs generierten Logdaten nicht in S3 gespeichert. Stattdessen werden die erfassten Logdaten an CloudWatch Logs gesendet**.
+Im Gegensatz zu S3 Access Logs und CloudFront Access Logs werden die **durch VPC Flow Logs erzeugten Logdaten nicht in S3 gespeichert. Stattdessen werden die erfassten Logdaten an CloudWatch Logs gesendet**.
 
 Einschränkungen:
 
-- Wenn Sie eine VPC Peering-Verbindung betreiben, können Sie nur Flow Logs der Peered VPCs sehen, die sich im selben Account befinden.
-- Wenn Sie weiterhin Ressourcen in der EC2-Classic-Umgebung betreiben, können Sie leider keine Informationen von deren Interfaces abrufen.
-- Sobald ein VPC Flow Log erstellt wurde, kann es nicht geändert werden. Um die Konfiguration eines VPC Flow Logs zu ändern, müssen Sie es löschen und neu erstellen.
-- Der folgende Verkehr wird von den Logs nicht überwacht und erfasst: DHCP-Verkehr innerhalb der VPC, Verkehr von Instanzen, der an den Amazon DNS-Server gerichtet ist.
-- Jeglicher Verkehr, der an die IP-Adresse für den VPC-Standardrouter gerichtet ist, sowie Verkehr zu und von den folgenden Adressen: 169.254.169.254 (wird zum Sammeln von Instance-Metadata verwendet) und 169.254.169.123 (wird für den Amazon Time Sync Service verwendet).
+- Wenn Sie eine VPC Peering-Verbindung betreiben, können Sie nur Flow Logs von gepeerten VPCs sehen, die sich im selben Account befinden.
+- Wenn Sie Ressourcen im EC2-Classic-Umfeld betreiben, können Sie leider keine Informationen von deren Schnittstellen abrufen.
+- Sobald ein VPC Flow Log erstellt wurde, kann es nicht geändert werden. Um die VPC Flow Log-Konfiguration zu ändern, müssen Sie es löschen und neu erstellen.
+- Folgender Verkehr wird nicht von den Logs überwacht oder erfasst: DHCP-Verkehr innerhalb der VPC, Verkehr von Instanzen, der für den Amazon DNS-Server bestimmt ist.
+- Jeglicher Verkehr, der an die IP-Adresse des VPC-Standardrouters gerichtet ist, sowie Verkehr zu und von den folgenden Adressen: 169.254.169.254 (wird zur Abfrage von Instance-Metadaten verwendet) und 169.254.169.123 (wird für den Amazon Time Sync Service verwendet).
 - Verkehr im Zusammenhang mit einer Amazon Windows-Aktivierungslizenz von einer Windows-Instanz.
 - Verkehr zwischen einer Network Load Balancer-Schnittstelle und einer Endpoint Network Interface.
 
-Für jedes Network Interface, das Daten an die CloudWatch-Loggruppe veröffentlicht, wird ein eigener Log-Stream verwendet. Und innerhalb jedes dieser Streams befinden sich die Flow-Log-Event-Daten, die den Inhalt der Logeinträge zeigen. Jeder dieser **Logs erfasst Daten in einem Fenster von ungefähr 10 bis 15 Minuten**.
+Für jede Network Interface, die Daten an die CloudWatch-Loggruppe veröffentlicht, wird ein eigener Log Stream verwendet. Innerhalb jedes dieser Streams befinden sich die Flow Log-Event-Daten, die den Inhalt der Logeinträge zeigen. Jeder dieser **Logs erfasst Daten in einem Zeitfenster von ungefähr 10 bis 15 Minuten**.
 
 ## VPN
 
@@ -104,82 +104,82 @@ Für jedes Network Interface, das Daten an die CloudWatch-Loggruppe veröffentli
 
 1. **Customer Gateway**:
 - Ein Customer Gateway ist eine Ressource, die Sie in AWS erstellen, um Ihre Seite einer VPN-Verbindung darzustellen.
-- Es ist im Wesentlichen ein physisches Gerät oder eine Softwareanwendung auf Ihrer Seite der Site-to-Site VPN-Verbindung.
-- Sie geben Routing-Informationen und die öffentliche IP-Adresse Ihres Netzwerkteils (wie eines Routers oder einer Firewall) an AWS, um ein Customer Gateway zu erstellen.
-- Es dient als Referenzpunkt für die Einrichtung der VPN-Verbindung und verursacht keine zusätzlichen Gebühren.
+- Es ist im Wesentlichen ein physisches Gerät oder eine Software-Anwendung auf Ihrer Seite der Site-to-Site VPN-Verbindung.
+- Sie geben Routing-Informationen und die öffentliche IP-Adresse Ihres Netzwerkgeräts (z. B. eines Routers oder einer Firewall) an AWS an, um ein Customer Gateway zu erstellen.
+- Es dient als Referenzpunkt für das Einrichten der VPN-Verbindung und verursacht keine zusätzlichen Gebühren.
 2. **Virtual Private Gateway**:
 - Ein Virtual Private Gateway (VPG) ist der VPN-Konzentrator auf der Amazon-Seite der Site-to-Site VPN-Verbindung.
-- Es ist an Ihre VPC angeschlossen und dient als Ziel für Ihre VPN-Verbindung.
-- VPG ist der AWS-seitige Endpunkt für die VPN-Verbindung.
+- Es ist an Ihre VPC angehängt und dient als Ziel für Ihre VPN-Verbindung.
+- VPG ist der AWS-seitige Endpunkt der VPN-Verbindung.
 - Es übernimmt die sichere Kommunikation zwischen Ihrer VPC und Ihrem On-Premises-Netzwerk.
 3. **Site-to-Site VPN Connection**:
-- Eine Site-to-Site VPN-Verbindung verbindet Ihr On-Premises-Netzwerk mit einer VPC durch einen sicheren IPsec-VPN-Tunnel.
-- Für diese Art von Verbindung sind ein Customer Gateway und ein Virtual Private Gateway erforderlich.
+- Eine Site-to-Site VPN-Verbindung verbindet Ihr On-Premises-Netzwerk mit einer VPC über einen sicheren IPsec-VPN-Tunnel.
+- Diese Art der Verbindung erfordert ein Customer Gateway und ein Virtual Private Gateway.
 - Sie wird für sichere, stabile und konsistente Kommunikation zwischen Ihrem Rechenzentrum oder Netzwerk und Ihrer AWS-Umgebung verwendet.
-- Typischerweise für regelmäßige, langfristige Verbindungen genutzt und basierend auf der übertragenen Datenmenge abgerechnet.
+- Typischerweise für regelmäßige, langfristige Verbindungen verwendet und nach der über die Verbindung übertragenen Datenmenge abgerechnet.
 4. **Client VPN Endpoint**:
 - Ein Client VPN Endpoint ist eine Ressource, die Sie in AWS erstellen, um Client-VPN-Sitzungen zu ermöglichen und zu verwalten.
 - Sie wird verwendet, um einzelnen Geräten (wie Laptops, Smartphones usw.) den sicheren Zugriff auf AWS-Ressourcen oder Ihr On-Premises-Netzwerk zu ermöglichen.
-- Sie unterscheidet sich von Site-to-Site VPN dadurch, dass sie für einzelne Clients ausgelegt ist und nicht für die Verbindung ganzer Netzwerke.
+- Sie unterscheidet sich vom Site-to-Site VPN, da sie für einzelne Clients und nicht für die Verbindung ganzer Netzwerke ausgelegt ist.
 - Bei Client VPN verwendet jedes Client-Gerät eine VPN-Client-Software, um eine sichere Verbindung herzustellen.
 
 ### Site-to-Site VPN
 
-**Verbindet Ihr On-Premises-Netzwerk mit Ihrer VPC.**
+**Verbinden Sie Ihr On-Premises-Netzwerk mit Ihrer VPC.**
 
 - **VPN connection**: Eine sichere Verbindung zwischen Ihrer On-Premises-Ausrüstung und Ihren VPCs.
-- **VPN tunnel**: Ein verschlüsselter Link, über den Daten vom Kundennetzwerk zu oder von AWS übertragen werden können.
+- **VPN tunnel**: Eine verschlüsselte Verbindung, über die Daten vom Kundennetzwerk zu oder von AWS übertragen werden können.
 
-Jede VPN-Verbindung enthält zwei VPN-Tunnel, die Sie gleichzeitig für Hochverfügbarkeit verwenden können.
+Jede VPN-Verbindung beinhaltet zwei VPN-Tunnel, die Sie gleichzeitig für hohe Verfügbarkeit nutzen können.
 
 - **Customer gateway**: Eine AWS-Ressource, die AWS Informationen über Ihr Customer Gateway-Gerät bereitstellt.
-- **Customer gateway device**: Ein physisches Gerät oder eine Softwareanwendung auf Ihrer Seite der Site-to-Site VPN-Verbindung.
-- **Virtual private gateway**: Der VPN-Konzentrator auf der Amazon-Seite der Site-to-Site VPN-Verbindung. Sie verwenden ein virtual private gateway oder ein transit gateway als Gateway für die Amazon-Seite der Site-to-Site VPN-Verbindung.
-- **Transit gateway**: Ein Transit-Hub, das verwendet werden kann, um Ihre VPCs und On-Premises-Netzwerke zu verbinden. Sie verwenden ein transit gateway oder virtual private gateway als Gateway für die Amazon-Seite der Site-to-Site VPN-Verbindung.
+- **Customer gateway device**: Ein physisches Gerät oder eine Software-Anwendung auf Ihrer Seite der Site-to-Site VPN-Verbindung.
+- **Virtual private gateway**: Der VPN-Konzentrator auf der Amazon-Seite der Site-to-Site VPN-Verbindung. Sie verwenden ein Virtual Private Gateway oder ein Transit Gateway als Gateway für die Amazon-Seite der Site-to-Site VPN-Verbindung.
+- **Transit gateway**: Ein Transit-Hub, der verwendet werden kann, um Ihre VPCs und On-Premises-Netzwerke zu verbinden. Sie verwenden ein Transit Gateway oder Virtual Private Gateway als Gateway für die Amazon-Seite der Site-to-Site VPN-Verbindung.
 
 #### Einschränkungen
 
-- IPv6-Verkehr wird für VPN-Verbindungen auf einem virtual private gateway nicht unterstützt.
-- Eine AWS VPN-Verbindung unterstützt keine Path MTU Discovery.
+- IPv6-Verkehr wird für VPN-Verbindungen an einem Virtual Private Gateway nicht unterstützt.
+- Eine AWS VPN-Verbindung unterstützt kein Path MTU Discovery.
 
-Berücksichtigen Sie außerdem Folgendes, wenn Sie Site-to-Site VPN verwenden.
+Berücksichtigen Sie außerdem Folgendes bei der Verwendung von Site-to-Site VPN.
 
-- Beim Verbinden Ihrer VPCs mit einem gemeinsamen On-Premises-Netzwerk empfehlen wir, nicht überlappende CIDR-Blöcke für Ihre Netzwerke zu verwenden.
+- Wenn Sie Ihre VPCs mit einem gemeinsamen On-Premises-Netzwerk verbinden, empfehlen wir die Verwendung nicht überlappender CIDR-Blöcke für Ihre Netzwerke.
 
 ### Client VPN <a href="#what-is-components" id="what-is-components"></a>
 
-**Verbindung von Ihrem Gerät zu Ihrer VPC**
+**Verbinden Sie sich von Ihrem Gerät mit Ihrer VPC**
 
 #### Konzepte
 
-- **Client VPN endpoint:** Die Ressource, die Sie erstellen und konfigurieren, um Client-VPN-Sitzungen zu ermöglichen und zu verwalten. Es ist die Ressource, an der alle Client-VPN-Sitzungen terminiert werden.
-- **Target network:** Ein Target Network ist das Netzwerk, das Sie mit einem Client VPN endpoint assoziieren. **Ein Subnetz einer VPC ist ein Target Network**. Das Assoziieren eines Subnetzes mit einem Client VPN endpoint ermöglicht es Ihnen, VPN-Sitzungen herzustellen. Sie können mehrere Subnetze mit einem Client VPN endpoint für Hochverfügbarkeit assoziieren. Alle Subnetze müssen aus derselben VPC stammen. Jedes Subnetz muss zu einer anderen Availability Zone gehören.
-- **Route:** Jeder Client VPN endpoint hat eine Routing-Tabelle, die die verfügbaren Zielnetzwerkrouten beschreibt. Jede Route in der Routing-Tabelle gibt den Pfad für den Datenverkehr zu bestimmten Ressourcen oder Netzwerken an.
-- **Authorization rules:** Eine Authorization Rule **beschränkt die Benutzer, die auf ein Netzwerk zugreifen können**. Für ein bestimmtes Netzwerk konfigurieren Sie die Active Directory- oder Identity Provider (IdP)-Gruppe, die Zugriff hat. Nur Benutzer, die zu dieser Gruppe gehören, können auf das angegebene Netzwerk zugreifen. **Standardmäßig gibt es keine Authorization Rules** und Sie müssen Authorization Rules konfigurieren, um Benutzern den Zugriff auf Ressourcen und Netzwerke zu ermöglichen.
-- **Client:** Der Endbenutzer, der sich mit dem Client VPN endpoint verbindet, um eine VPN-Sitzung herzustellen. Endbenutzer müssen einen OpenVPN-Client herunterladen und die von Ihnen erstellte Client VPN-Konfigurationsdatei verwenden, um eine VPN-Sitzung herzustellen.
-- **Client CIDR range:** Ein IP-Adressbereich, aus dem Client-IP-Adressen zugewiesen werden. Jede Verbindung zum Client VPN endpoint erhält eine eindeutige IP-Adresse aus dem Client CIDR-Bereich. Sie wählen den Client CIDR-Bereich, zum Beispiel `10.2.0.0/16`.
+- **Client VPN endpoint:** Die Ressource, die Sie erstellen und konfigurieren, um Client-VPN-Sitzungen zu ermöglichen und zu verwalten. Dies ist die Ressource, an der alle Client-VPN-Sitzungen terminiert werden.
+- **Target network:** Ein Target Network ist das Netzwerk, das Sie mit einem Client VPN Endpoint assoziieren. **Ein Subnetz aus einer VPC ist ein Target Network**. Die Zuordnung eines Subnetzes zu einem Client VPN Endpoint ermöglicht es Ihnen, VPN-Sitzungen herzustellen. Sie können mehrere Subnetze einem Client VPN Endpoint zuordnen, um hohe Verfügbarkeit zu erreichen. Alle Subnetze müssen aus derselben VPC stammen. Jedes Subnetz muss zu einer anderen Availability Zone gehören.
+- **Route:** Jeder Client VPN Endpoint hat eine Route Table, die die verfügbaren Zielnetzwerkrouten beschreibt. Jede Route in der Route Table gibt den Pfad für Verkehr zu bestimmten Ressourcen oder Netzwerken an.
+- **Authorization rules:** Eine Authorization Rule **beschränkt die Benutzer, die auf ein Netzwerk zugreifen können**. Für ein angegebenes Netzwerk konfigurieren Sie die Active Directory- oder Identity Provider (IdP)-Gruppe, die Zugriff hat. Nur Benutzer, die dieser Gruppe angehören, können auf das angegebene Netzwerk zugreifen. **Standardmäßig gibt es keine Authorization Rules** und Sie müssen Authorization Rules konfigurieren, damit Benutzer auf Ressourcen und Netzwerke zugreifen können.
+- **Client:** Der Endbenutzer, der sich mit dem Client VPN Endpoint verbindet, um eine VPN-Sitzung herzustellen. Endbenutzer müssen einen OpenVPN-Client herunterladen und die Client VPN Konfigurationsdatei verwenden, die Sie erstellt haben, um eine VPN-Sitzung herzustellen.
+- **Client CIDR range:** Ein IP-Adressbereich, aus dem Client-IP-Adressen zugewiesen werden. Jede Verbindung zum Client VPN Endpoint erhält eine eindeutige IP-Adresse aus dem Client CIDR Range. Sie wählen den Client CIDR Range, z. B. `10.2.0.0/16`.
 - **Client VPN ports:** AWS Client VPN unterstützt die Ports 443 und 1194 für sowohl TCP als auch UDP. Standardmäßig ist Port 443.
-- **Client VPN network interfaces:** Wenn Sie ein Subnetz mit Ihrem Client VPN endpoint assoziieren, erstellen wir Client VPN Network Interfaces in diesem Subnetz. **Verkehr, der vom Client VPN endpoint an die VPC gesendet wird, wird über ein Client VPN Network Interface gesendet**. Dann wird Source Network Address Translation (SNAT) angewendet, wobei die Quell-IP-Adresse aus dem Client CIDR-Bereich in die IP-Adresse des Client VPN Network Interface übersetzt wird.
-- **Connection logging:** Sie können Connection Logging für Ihren Client VPN endpoint aktivieren, um Verbindungsereignisse zu protokollieren. Sie können diese Informationen für forensische Untersuchungen, zur Analyse der Nutzung Ihres Client VPN endpoints oder zur Fehlerbehebung bei Verbindungsproblemen verwenden.
-- **Self-service portal:** Sie können ein Self-Service-Portal für Ihren Client VPN endpoint aktivieren. Clients können sich im webbasierten Portal mit ihren Anmeldeinformationen anmelden und die neueste Version der Client VPN endpoint-Konfigurationsdatei oder die neueste Version des von AWS bereitgestellten Clients herunterladen.
+- **Client VPN network interfaces:** Wenn Sie ein Subnetz mit Ihrem Client VPN Endpoint assoziieren, erstellt AWS Client VPN network interfaces in diesem Subnetz. **Verkehr, der vom Client VPN Endpoint an die VPC gesendet wird, wird über ein Client VPN network interface geleitet**. Es wird Source Network Address Translation (SNAT) angewendet, wobei die Quell-IP-Adresse aus dem Client CIDR Range auf die IP-Adresse des Client VPN network interface übersetzt wird.
+- **Connection logging:** Sie können Connection Logging für Ihren Client VPN Endpoint aktivieren, um Verbindungsereignisse zu protokollieren. Sie können diese Informationen für forensische Analysen, zur Analyse der Nutzung Ihres Client VPN Endpoints oder zur Fehlerbehebung bei Verbindungsproblemen verwenden.
+- **Self-service portal:** Sie können ein Self-Service-Portal für Ihren Client VPN Endpoint aktivieren. Clients können sich mit ihren Anmeldedaten in das webbasierte Portal einloggen und die neueste Version der Client VPN Endpoint-Konfigurationsdatei oder die neueste Version des von AWS bereitgestellten Clients herunterladen.
 
 #### Einschränkungen
 
-- **Client CIDR ranges dürfen sich nicht mit dem lokalen CIDR** der VPC überschneiden, in der sich das assoziierte Subnetz befindet, oder mit Routen, die manuell zur Routing-Tabelle des Client VPN endpoints hinzugefügt wurden.
-- Client CIDR-Bereiche müssen eine Blockgröße von **mindestens /22** haben und dürfen **nicht größer als /12** sein.
-- Ein **Teil der Adressen** im Client CIDR-Bereich wird verwendet, um das **Verfügbarkeitsmodell** des Client VPN endpoints zu unterstützen und kann nicht an Clients vergeben werden. Daher empfehlen wir, einen CIDR-Block zu wählen, der die doppelte Anzahl der IP-Adressen enthält, die erforderlich sind, um die maximale Anzahl gleichzeitiger Verbindungen zu unterstützen, die Sie planen.
-- Der **Client CIDR Bereich kann nach der Erstellung des Client VPN endpoints nicht geändert werden**.
-- Die **Subnetze**, die mit einem Client VPN endpoint assoziiert sind, **müssen sich in derselben VPC befinden**.
-- Sie **können nicht mehrere Subnetze aus derselben Availability Zone mit einem Client VPN endpoint assoziieren**.
-- Ein Client VPN endpoint **unterstützt keine Subnetzassoziationen in einer VPC mit dedizierter Tenancy**.
+- **Client CIDR ranges dürfen sich nicht mit dem lokalen CIDR** der VPC, in der das assoziierte Subnetz liegt, oder mit Routen, die manuell zur Route Table des Client VPN Endpoints hinzugefügt wurden, überlappen.
+- Client CIDR Ranges müssen eine Blockgröße von **mindestens /22** haben und dürfen **nicht größer als /12** sein.
+- Ein **Teil der Adressen** im Client CIDR Range wird verwendet, um das Verfügbarkeitsmodell des Client VPN Endpoints zu unterstützen, und kann nicht an Clients zugewiesen werden. Daher empfehlen wir, einen CIDR-Block zuzuweisen, der die doppelte Anzahl der IP-Adressen enthält, die erforderlich sind, um die maximale Anzahl gleichzeitiger Verbindungen zu ermöglichen, die Sie unterstützen möchten.
+- Der **Client CIDR Range kann nach Erstellung des Client VPN Endpoints nicht geändert werden**.
+- Die **Subnetze**, die mit einem Client VPN Endpoint assoziiert sind, **müssen sich in derselben VPC** befinden.
+- Sie **können nicht mehrere Subnetze aus derselben Availability Zone** mit einem Client VPN Endpoint assoziieren.
+- Ein Client VPN Endpoint **unterstützt keine Subnetz-Assoziationen in einer VPC mit dedizierter Tenancy**.
 - Client VPN unterstützt nur **IPv4**-Verkehr.
 - Client VPN ist **nicht** Federal Information Processing Standards (**FIPS**) **konform**.
-- Wenn die Multi-Faktor-Authentifizierung (MFA) für Ihr Active Directory deaktiviert ist, darf ein Benutzerpasswort nicht im folgenden Format vorliegen.
+- Wenn die Multi-Factor Authentication (MFA) für Ihr Active Directory deaktiviert ist, darf ein Benutzerpasswort nicht im folgenden Format vorliegen:
 
 ```
 SCRV1:<base64_encoded_string>:<base64_encoded_string>
 ```
 
-- Das Self-Service-Portal ist **nicht verfügbar für Clients, die sich mit mutual authentication authentifizieren**.
+- Das Self-Service-Portal ist **nicht verfügbar** für Clients, die sich mit gegenseitiger Authentifizierung (mutual authentication) authentifizieren.
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md

@@ -4,36 +4,36 @@
 
 ## S3
 
-Amazon S3 ist ein Service, der es dir ermöglicht, **große Mengen an Daten zu speichern**.
+Amazon S3 ist ein Service, der es Ihnen ermöglicht, **große Datenmengen zu speichern**.
 
-Amazon S3 bietet mehrere Optionen, um den **Schutz** von Daten im Ruhezustand zu erreichen. Die Optionen umfassen **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** und **MFA** **based delete**. **Der Benutzer kann** eine oder mehrere dieser Optionen aktivieren, um den Datenschutz zu gewährleisten. **Data replication** ist eine interne Funktion von AWS, bei der **S3 automatisch jedes Objekt über alle Availability Zones repliziert**, und die Organisation muss sie in diesem Fall nicht aktivieren.
+Amazon S3 bietet mehrere Optionen, um den **Schutz** von Daten im Ruhezustand zu erreichen. Zu den Optionen gehören **Permission** (Policy), **Encryption** (Client- und Server-seitig), **Bucket Versioning** und **MFA** **based delete**. Der **Nutzer kann** jede dieser Optionen aktivieren, um den Schutz der Daten zu erreichen. **Datenreplikation** ist eine interne Funktion von AWS, bei der **S3 automatisch jedes Objekt über alle Availability Zones repliziert** und die Organisation dies in diesem Fall nicht aktivieren muss.
 
-Mit ressourcenbasierten Berechtigungen kannst du Berechtigungen für Unterverzeichnisse deines Buckets separat festlegen.
+Mit ressourcenbasierten Berechtigungen können Sie Berechtigungen für Unterverzeichnisse Ihres Buckets separat festlegen.
 
 ### Bucket Versioning and MFA based delete
 
 Wenn Bucket Versioning aktiviert ist, erzeugt jede Aktion, die versucht, eine Datei zu ändern, eine neue Version der Datei und behält auch den vorherigen Inhalt bei. Daher wird der Inhalt nicht überschrieben.
 
-Außerdem verhindert MFA based delete, dass Versionen von Dateien im S3-Bucket gelöscht werden, und verhindert auch das Deaktivieren von Bucket Versioning, sodass ein Angreifer diese Dateien nicht verändern kann.
+Außerdem verhindert MFA based delete, dass Versionen von Dateien im S3-Bucket gelöscht werden, und dass Bucket Versioning deaktiviert wird, sodass ein Angreifer diese Dateien nicht verändern kann.
 
 ### S3 Access logs
 
-Es ist möglich, **S3 access login** (standardmäßig deaktiviert) für einen Bucket zu aktivieren und die Logs in einem anderen Bucket zu speichern, um nachzuvollziehen, wer auf den Bucket zugreift (beide Buckets müssen sich in derselben Region befinden).
+Es ist möglich, **enable S3 access login** (standardmäßig deaktiviert) für einen Bucket zu aktivieren und die Logs in einem anderen Bucket zu speichern, um zu wissen, wer auf den Bucket zugreift (beide Buckets müssen in derselben Region sein).
 
 ### S3 Presigned URLs
 
-Es ist möglich, eine presigned URL zu erzeugen, die normalerweise verwendet werden kann, um **auf die angegebene Datei zuzugreifen** im Bucket. Eine **presigned URL sieht so aus**:
+Es ist möglich, eine presigned URL zu generieren, die üblicherweise dazu verwendet werden kann, **auf die angegebene Datei zuzugreifen** im Bucket. Eine **presigned URL sieht so aus**:
 ```
 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
 ```
-Eine presigned URL kann **created from the cli using credentials of a principal with access to the object** (wenn das Account, das Sie verwenden, keinen Zugriff hat, wird eine kürzere presigned URL erstellt, die jedoch nutzlos ist).
+Eine presigned URL kann über die CLI mit den Anmeldeinformationen eines Principals erstellt werden, der Zugriff auf das Objekt hat (wenn das Konto, das Sie verwenden, keinen Zugriff hat, wird eine kürzere presigned URL erstellt, die jedoch nutzlos ist)
 ```bash
 aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
 ```
 > [!NOTE]
-> Die einzige benötigte Berechtigung, um eine presigned URL zu generieren, ist die Berechtigung, die vergeben wird, sodass für den vorherigen Befehl die einzige vom Principal benötigte Berechtigung `s3:GetObject` ist
->
-> Es ist auch möglich, presigned URLs mit **anderen Berechtigungen** zu erstellen:
+> Die einzige erforderliche Berechtigung, um eine presigned URL zu erzeugen, ist die Berechtigung, die vergeben wird. Für den vorherigen Befehl ist die einzige Berechtigung, die der principal benötigt, `s3:GetObject`
+  
+Es ist auch möglich, presigned URLs mit **anderen Berechtigungen** zu erstellen:
 ```python
 import boto3
 url = boto3.client('s3').generate_presigned_url(
@@ -42,99 +42,99 @@ Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'},
 ExpiresIn=3600
 )
 ```
-### S3 Verschlüsselungsmechanismen
+### S3-Verschlüsselungsmechanismen
 
-**DEK bedeutet Data Encryption Key** und ist der Schlüssel, der immer erzeugt und zum Verschlüsseln von Daten verwendet wird.
+**DEK bedeutet Data Encryption Key** und ist der Schlüssel, der immer generiert und zum Verschlüsseln von Daten verwendet wird.
 
 <details>
 
-<summary><strong>Serverseitige Verschlüsselung mit von S3 verwalteten Schlüsseln, SSE-S3</strong></summary>
+<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
 
-Diese Option erfordert minimale Konfiguration und alle Verwaltungsaufgaben der verwendeten Verschlüsselungsschlüssel werden von AWS übernommen. Alles, was Sie tun müssen, ist, **Ihre Daten hochzuladen und S3 kümmert sich um alle anderen Aspekte**. Jedem Bucket in einem S3-Konto ist ein Bucket-Key zugewiesen.
+Diese Option erfordert minimale Konfiguration; die gesamte Verwaltung der verwendeten Verschlüsselungsschlüssel wird von AWS übernommen. Alles, was Sie tun müssen, ist, **Ihre Daten hochzuladen — S3 übernimmt den Rest**. Jeder Bucket in einem S3-Account erhält einen Bucket-Key.
 
 - Verschlüsselung:
-- Object Data + erstellter Plaintext-DEK --> Verschlüsselte Daten (in S3 gespeichert)
-- Erstellter Plaintext-DEK + S3 Master Key --> Verschlüsselter DEK (in S3 gespeichert) und der Plaintext wird aus dem Speicher gelöscht
+- Object Data + erstellter plaintext DEK --> Verschlüsselte Daten (in S3 gespeichert)
+- Erstellter plaintext DEK + S3 Master Key --> Verschlüsselter DEK (in S3 gespeichert) und der Plaintext wird aus dem Speicher gelöscht
 - Entschlüsselung:
-- Verschlüsselter DEK + S3 Master Key --> Plaintext-DEK
-- Plaintext-DEK + verschlüsselte Daten --> Object Data
+- Verschlüsselter DEK + S3 Master Key --> Plaintext DEK
+- Plaintext DEK + verschlüsselte Daten --> Object Data
 
-Bitte beachten Sie, dass in diesem Fall **der Schlüssel von AWS verwaltet wird** (Rotation nur alle 3 Jahre). Wenn Sie Ihren eigenen Schlüssel verwenden, können Sie rotieren, deaktivieren und Zugriffskontrollen anwenden.
+Bitte beachten Sie, dass in diesem Fall **der Schlüssel von AWS verwaltet wird** (Rotation nur alle 3 Jahre). Wenn Sie Ihren eigenen Schlüssel verwenden, können Sie rotieren, deaktivieren und Zugriffssteuerung anwenden.
 
 </details>
 
 <details>
 
-<summary><strong>Serverseitige Verschlüsselung mit von KMS verwalteten Schlüsseln, SSE-KMS</strong></summary>
+<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
 
-Diese Methode erlaubt S3, den Key Management Service zu verwenden, um Ihre Data Encryption Keys zu erzeugen. KMS bietet Ihnen deutlich mehr Flexibilität bei der Verwaltung Ihrer Schlüssel. Zum Beispiel können Sie die CMK deaktivieren, rotieren und Zugriffskontrollen darauf anwenden sowie deren Nutzung mit AWS Cloud Trail überwachen.
+Diese Methode erlaubt S3, den Key Management Service zur Generierung Ihrer Data Encryption Keys zu nutzen. KMS bietet deutlich mehr Flexibilität in der Schlüsselverwaltung. Zum Beispiel können Sie den CMK deaktivieren, rotieren und Zugriffssteuerungen anwenden sowie die Nutzung mit AWS CloudTrail überwachen.
 
 - Verschlüsselung:
-- S3 fordert Data Keys von der KMS-CMK an
-- KMS verwendet eine CMK, um das Paar Plaintext-DEK und verschlüsselten DEK zu erzeugen und sendet sie an S3
-- S3 verwendet den Plaintext-Schlüssel, um die Daten zu verschlüsseln, speichert die verschlüsselten Daten und den verschlüsselten Schlüssel und löscht den Plaintext-Schlüssel aus dem Speicher
+- S3 fordert bei KMS Data Keys an (vom CMK)
+- KMS verwendet einen CMK, um das Paar aus plaintext DEK und verschlüsseltem DEK zu erzeugen und sendet diese an S3
+- S3 verwendet den plaintext DEK, um die Daten zu verschlüsseln, speichert die verschlüsselten Daten und den verschlüsselten Schlüssel und löscht den plaintext DEK aus dem Speicher
 - Entschlüsselung:
 - S3 bittet KMS, den verschlüsselten Data Key des Objekts zu entschlüsseln
-- KMS entschlüsselt den Data Key mit der CMK und sendet ihn an S3 zurück
-- S3 entschlüsselt die Objektdaten
+- KMS entschlüsselt den Data Key mit dem CMK und sendet ihn an S3 zurück
+- S3 entschlüsselt die Objekt-Daten
 
 </details>
 
 <details>
 
-<summary><strong>Serverseitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln, SSE-C</strong></summary>
+<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
 
-Diese Option gibt Ihnen die Möglichkeit, Ihren eigenen Master-Schlüssel zu verwenden, den Sie möglicherweise außerhalb von AWS einsetzen. Ihr kundenseitig bereitgestellter Schlüssel würde dann zusammen mit Ihren Daten an S3 gesendet, wo S3 die Verschlüsselung für Sie durchführt.
+Diese Option gibt Ihnen die Möglichkeit, Ihren eigenen Master-Key zu verwenden, den Sie möglicherweise bereits außerhalb von AWS einsetzen. Ihr vom Kunden bereitgestellter Schlüssel würde zusammen mit Ihren Daten an S3 gesendet, wo S3 dann die Verschlüsselung für Sie übernimmt.
 
 - Verschlüsselung:
-- Der Nutzer sendet die Object Data + Customer Key an S3
+- Der Nutzer sendet die Objekt-Daten + Customer Key an S3
 - Der Customer Key wird verwendet, um die Daten zu verschlüsseln, und die verschlüsselten Daten werden gespeichert
-- Ein gesalzener HMAC-Wert des Customer Key wird ebenfalls zur späteren Schlüsselvalidierung gespeichert
+- Ein gesalzener HMAC-Wert des Customer Keys wird ebenfalls zur späteren Schlüsselvalidierung gespeichert
 - Der Customer Key wird aus dem Speicher gelöscht
 - Entschlüsselung:
 - Der Nutzer sendet den Customer Key
 - Der Schlüssel wird gegen den gespeicherten HMAC-Wert validiert
-- Der vom Kunden bereitgestellte Schlüssel wird dann verwendet, um die Daten zu entschlüsseln
+- Der vom Kunden bereitgestellte Schlüssel wird dann zum Entschlüsseln der Daten verwendet
 
 </details>
 
 <details>
 
-<summary><strong>Clientseitige Verschlüsselung mit KMS, CSE-KMS</strong></summary>
+<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
 
-Ähnlich wie bei SSE-KMS nutzt dies ebenfalls den Key Management Service, um Ihre Data Encryption Keys zu erzeugen. Allerdings wird KMS hier vom Client und nicht von S3 aufgerufen. Die Verschlüsselung findet also clientseitig statt und die verschlüsselten Daten werden anschließend an S3 zur Speicherung gesendet.
+Ähnlich wie bei SSE-KMS verwendet dies ebenfalls den Key Management Service zur Generierung Ihrer Data Encryption Keys. Allerdings wird KMS hier vom Client und nicht von S3 aufgerufen. Die Verschlüsselung findet clientseitig statt und die verschlüsselten Daten werden anschließend an S3 zur Speicherung gesendet.
 
 - Verschlüsselung:
-- Client fordert einen Data Key von KMS an
-- KMS liefert den Plaintext-DEK und den mit der CMK verschlüsselten DEK
-- Beide Schlüssel werden zurückgegeben
-- Der Client verschlüsselt die Daten mit dem Plaintext-DEK und sendet die verschlüsselten Daten + den verschlüsselten DEK an S3 (der verschlüsselte DEK wird als Metadaten der verschlüsselten Daten in S3 gespeichert)
+- Client fordert bei KMS einen Data Key an
+- KMS liefert den plaintext DEK und den mit dem CMK verschlüsselten DEK zurück
+- Beide Keys werden zurückgegeben
+- Der Client verschlüsselt die Daten mit dem plaintext DEK und sendet an S3 die verschlüsselten Daten + den verschlüsselten DEK (welcher als Metadatum der verschlüsselten Daten in S3 gespeichert wird)
 - Entschlüsselung:
-- Die verschlüsselten Daten mitsamt dem verschlüsselten DEK werden an den Client gesendet
-- Der Client bittet KMS, den verschlüsselten Schlüssel mit der CMK zu entschlüsseln, und KMS sendet den Plaintext-DEK zurück
+- Die verschlüsselten Daten mit dem verschlüsselten DEK werden an den Client gesendet
+- Der Client bittet KMS, den verschlüsselten Schlüssel mit dem CMK zu entschlüsseln, und KMS liefert den plaintext DEK zurück
 - Der Client kann nun die verschlüsselten Daten entschlüsseln
 
 </details>
 
 <details>
 
-<summary><strong>Clientseitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln, CSE-C</strong></summary>
+<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
 
-Mit diesem Mechanismus können Sie Ihre eigenen bereitgestellten Schlüssel nutzen und einen AWS-SDK-Client verwenden, um Ihre Daten vor dem Senden an S3 zu verschlüsseln.
+Mit diesem Mechanismus können Sie eigene Schlüssel verwenden und einen AWS-SDK-Client einsetzen, um Ihre Daten vor dem Senden an S3 zu verschlüsseln.
 
 - Verschlüsselung:
-- Der Client erzeugt einen DEK und verschlüsselt die Plaintext-Daten
-- Dann verschlüsselt er den DEK mit seiner eigenen CMK
-- Sendet die verschlüsselten Daten + den verschlüsselten DEK an S3, wo sie gespeichert werden
+- Der Client generiert einen DEK und verschlüsselt die Plaintext-Daten
+- Dann verschlüsselt er den DEK mit seinem eigenen CMK
+- Sendet die verschlüsselten Daten + den verschlüsselten DEK an S3, wo beides gespeichert wird
 - Entschlüsselung:
-- S3 sendet die verschlüsselten Daten und den DEK
-- Da der Client bereits die CMK besitzt, die zum Verschlüsseln des DEK verwendet wurde, entschlüsselt er den DEK und nutzt den Plaintext-DEK, um die Daten zu entschlüsseln
+- S3 sendet die verschlüsselten Daten und den verschlüsselten DEK
+- Da der Client bereits den CMK besitzt, der zur Verschlüsselung des DEK verwendet wurde, entschlüsselt er den DEK und verwendet den plaintext DEK, um die Daten zu entschlüsseln
 
 </details>
 
 ### **Enumeration**
 
-Eine der traditionellen Hauptmethoden, um AWS-Organisationen zu kompromittieren, beginnt damit, öffentlich zugängliche buckets auszunutzen. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
+One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
 ```bash
 # Get buckets ACLs
 aws s3api get-bucket-acl --bucket <bucket-name>
@@ -227,18 +227,18 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
 }
 ## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
 ```
-### Dual-Stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
+### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
 
-Sie können auf einen S3-Bucket über einen Dual-Stack-Endpoint zugreifen, indem Sie entweder einen virtual hosted-style oder einen path-style Endpoint-Namen verwenden. Diese sind nützlich, um S3 über IPv6 zu erreichen.
+Sie können über einen dual-stack Endpoint auf einen S3-Bucket zugreifen, indem Sie entweder einen virtual hosted-style oder einen path-style Endpoint-Namen verwenden. Diese Endpoints sind nützlich, um über IPv6 auf S3 zuzugreifen.
 
-Dual-Stack-Endpunkte verwenden die folgende Syntax:
+Dual-stack Endpoints verwenden folgende Syntax:
 
 - `bucketname.s3.dualstack.aws-region.amazonaws.com`
 - `s3.dualstack.aws-region.amazonaws.com/bucketname`
 
 ### Privesc
 
-Auf der folgenden Seite können Sie nachsehen, wie man **abuse S3 permissions to escalate privileges**:
+Auf der folgenden Seite können Sie nachlesen, wie man **abuse S3 permissions to escalate privileges**:
 
 {{#ref}}
 ../aws-privilege-escalation/aws-s3-privesc/README.md
@@ -262,23 +262,23 @@ Auf der folgenden Seite können Sie nachsehen, wie man **abuse S3 permissions to
 ../aws-persistence/aws-s3-persistence/README.md
 {{#endref}}
 
-## Other S3 vulns
+## Andere S3-Schwachstellen
 
 ### 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) war es möglich, die Antwort eines beliebigen Buckets so zu cachen, als würde sie zu einem anderen gehören. Dies hätte zum Beispiel missbraucht werden können, um JavaScript-Dateiantworten zu verändern und beliebige Seiten zu kompromittieren, die S3 zum Speichern statischen Codes nutzen.
+[**Laut dieser Forschung**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) war es möglich, die Antwort eines beliebigen Buckets so zwischenzuspeichern, als gehöre sie zu einem anderen. Dies hätte beispielsweise missbraucht werden können, um die Antworten von JavaScript-Dateien zu verändern und beliebige Seiten zu kompromittieren, die S3 zur Speicherung statischen Codes verwenden.
 
 ## Amazon Athena
 
-Amazon Athena ist ein interaktiver Query-Service, der es einfach macht, Daten direkt in Amazon Simple Storage Service (Amazon S3) mit standard SQL zu analysieren.
+Amazon Athena ist ein interaktiver Abfrageservice, der es einfach macht, Daten direkt in Amazon Simple Storage Service (Amazon **S3**) mit standardmäßigem **SQL** zu analysieren.
 
-Sie müssen eine relationale DB-Tabelle vorbereiten, die das Format des Inhalts beschreibt, der in den überwachten S3-Buckets erscheinen wird. Anschließend kann Amazon Athena die DB aus den Logs befüllen, sodass Sie Abfragen ausführen können.
+Sie müssen eine relationale DB-Tabelle vorbereiten, die dem Format des Inhalts entspricht, der in den überwachten S3-Buckets erscheinen wird. Anschließend kann Amazon Athena die DB aus den Logs befüllen, sodass Sie Abfragen durchführen können.
 
-Amazon Athena unterstützt die Möglichkeit, S3-Daten abzufragen, die bereits verschlüsselt sind, und wenn entsprechend konfiguriert, kann Athena auch die Ergebnisse der Abfrage verschlüsseln, die dann in S3 gespeichert werden können.
+Amazon Athena unterstützt die Möglichkeit, bereits verschlüsselte S3-Daten abzufragen. Falls entsprechend konfiguriert, kann Athena außerdem die Ergebnisse der Abfrage verschlüsseln, die dann in S3 gespeichert werden können.
 
-Diese Verschlüsselung der Ergebnisse ist unabhängig von den zugrunde liegenden abgefragten S3-Daten, das heißt selbst wenn die S3-Daten nicht verschlüsselt sind, können die abgefragten Ergebnisse verschlüsselt sein. Ein paar Punkte, die zu beachten sind: Amazon Athena unterstützt nur Daten, die mit den folgenden S3-Verschlüsselungsmethoden verschlüsselt wurden: SSE-S3, SSE-KMS und CSE-KMS.
+Diese Verschlüsselung der Ergebnisse ist unabhängig von den zugrundeliegenden abgefragten S3-Daten, das heißt selbst wenn die S3-Daten nicht verschlüsselt sind, können die abgefragten Ergebnisse verschlüsselt sein. Ein paar Punkte, die zu beachten sind: Amazon Athena unterstützt nur Daten, die mit den folgenden S3-Verschlüsselungsmethoden verschlüsselt wurden: **SSE-S3, SSE-KMS, und CSE-KMS**.
 
-SSE-C und CSE-C werden nicht unterstützt. Außerdem ist es wichtig zu verstehen, dass Amazon Athena Abfragen nur gegen verschlüsselte Objekte ausführt, die sich in derselben Region wie die Abfrage selbst befinden. Wenn Sie S3-Daten abfragen müssen, die mit KMS verschlüsselt wurden, sind spezifische Berechtigungen für den Athena-Benutzer erforderlich, damit dieser die Abfrage ausführen kann.
+SSE-C und CSE-C werden nicht unterstützt. Darüber hinaus ist es wichtig zu verstehen, dass Amazon Athena Abfragen nur gegen verschlüsselte Objekte ausführt, die sich in derselben Region wie die Abfrage befinden. Wenn Sie S3-Daten abfragen müssen, die mit KMS verschlüsselt wurden, sind spezifische Berechtigungen für den Athena-Benutzer erforderlich, damit dieser die Abfrage durchführen kann.
 
 ### Enumeration
 ```bash