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

This commit is contained in:
Translator
2026-02-27 14:14:24 +00:00
parent 14a3772538
commit c7dc340941
2 changed files with 145 additions and 145 deletions
@@ -2,179 +2,179 @@
{{#include ../../../../banners/hacktricks-training.md}}
## AWS Networking in a Nutshell
## AWS Networking em Resumo
A **VPC** contém um **network CIDR** como 10.0.0.0/16 (com sua **routing table** e **network ACL**).
Uma **VPC** contém um **network CIDR** como 10.0.0.0/16 (com sua **routing table** e **network ACL**).
Essa rede VPC é dividida em **subnetworks**, então uma **subnetwork** está diretamente **relacionada** com a **VPC**, **routing table** e **network ACL**.
Depois, **Network Interface**s ligadas a serviços (como instâncias EC2) são **conectadas** às **subnetworks** com **security group(s)**.
Então, as **Network Interface**s anexadas a serviços (como instâncias EC2) são **conectadas** às **subnetworks** com **security group(s)**.
Portanto, um **security group** limitará as portas expostas das network **interfaces que o usam**, **independentemente da subnetwork**. E um **network ACL** irá **limitar** as portas expostas para toda a **rede**.
Portanto, um **security group** limitará as portas expostas das **network interfaces que o utilizam**, **independentemente da subnetwork**. E um **network ACL** irá **limitar** as portas expostas para a **rede inteira**.
Além disso, para **acessar a Internet**, há algumas configurações interessantes a checar:
Além disso, para **acessar a Internet**, há algumas configurações interessantes a verificar:
- Uma **subnetwork** pode **auto-assign public IPv4 addresses**
- Uma **instance** criada na rede que **auto-assign IPv4 addresses pode receber um**
- Uma **subnetwork** pode **auto-atribuir endereços IPv4 públicos**
- Uma **instance** criada na rede que **auto-atribui endereços IPv4 pode receber um**
- Um **Internet gateway** precisa estar **attached** à **VPC**
- Você também pode usar **Egress-only internet gateways**
- Você também pode ter um **NAT gateway** em uma **private subnet** para que seja possível **conectar a serviços externos** a partir dessa private subnet, mas **não é possível alcançá-los de fora**.
- Você também pode ter um **NAT gateway** em uma **private subnet** para que seja possível **conectar a serviços externos** a partir dessa private subnet, mas **não é possível alcançá-los a partir do exterior**.
- O NAT gateway pode ser **public** (acesso à internet) ou **private** (acesso a outras VPCs)
![](<../../../../images/image (274).png>)
## VPC
Amazon **Virtual Private Cloud** (Amazon VPC) permite que você **lance recursos AWS em uma rede virtual** que você definiu. Essa rede virtual terá várias subnets, Internet Gateways para acessar a Internet, ACLs, Security groups, IPs...
Amazon **Virtual Private Cloud** (Amazon VPC) permite que você **inicie recursos AWS em uma rede virtual** que você definiu. Essa rede virtual terá várias subnets, Internet Gateways para acessar a Internet, ACLs, Security groups, IPs...
### Subnets
Subnets ajudam a impor um nível maior de segurança. **Agrupamento lógico de recursos similares** também ajuda a manter uma **facilidade de gerenciamento** na sua infraestrutura.
Subnets ajudam a reforçar um nível maior de segurança. **Agrupamento lógico de recursos similares** também facilita a **gestão** da sua infraestrutura.
- CIDR válidos vão de uma máscara /16 até uma máscara /28.
- Uma subnet não pode estar em diferentes availability zones ao mesmo tempo.
- **AWS reserva os três primeiros endereços IP de host** de cada subnet **para uso interno da AWS**: o primeiro endereço de host é usado pelo roteador da VPC. O segundo endereço é reservado para o DNS da AWS e o terceiro endereço é reservado para uso futuro.
- São chamadas de **public subnets** aquelas que têm **acesso direto à Internet, enquanto private subnets não.**
- CIDRs válidos vão de uma máscara /16 até /28.
- Uma subnet não pode estar em diferentes Availability Zones ao mesmo tempo.
- **A AWS reserva os três primeiros endereços IP de host** de cada subnet **para uso interno da AWS**: o primeiro endereço de host é usado para o roteador da VPC. O segundo endereço é reservado para o DNS da AWS e o terceiro endereço é reservado para uso futuro.
- São chamadas **public subnets** aquelas que têm **acesso direto à Internet, enquanto private subnets não têm.**
### Route Tables
Route tables determinam o roteamento de tráfego para uma subnet dentro de uma VPC. Elas determinam qual tráfego de rede é encaminhado para a internet ou para uma conexão VPN. Você normalmente encontrará acesso a:
- Local VPC
- VPC local
- NAT
- Internet Gateways / Egress-only Internet gateways (necessários para dar acesso à Internet a uma VPC).
- Para tornar uma subnet pública você precisa **criar** e **attachar** um **Internet gateway** à sua VPC.
- Internet Gateways / Egress-only Internet gateways (necessários para dar à VPC acesso à Internet).
- Para tornar uma subnet pública você precisa **criar** e **anexar** um **Internet gateway** à sua VPC.
- VPC endpoints (para acessar S3 a partir de redes privadas)
### ACLs
**Network Access Control Lists (ACLs)**: Network ACLs são regras de firewall que controlam o tráfego de rede de entrada e saída para uma subnet. Elas podem ser usadas para permitir ou negar tráfego para endereços IP ou faixas específicas.
**Network Access Control Lists (ACLs)**: Network ACLs são regras de firewall que controlam o tráfego de rede de entrada e saída para uma subnet. Elas podem ser usadas para permitir ou negar tráfego para endereços IP específicos ou intervalos.
- É mais frequente permitir/negarchar acesso usando security groups, mas essa é a única forma de cortar completamente shells reversos já estabelecidos. Uma regra modificada em um security group não interrompe conexões já estabelecidas.
- Contudo, isso se aplica a toda a subnetwork cuidado ao bloquear coisas, pois funcionalidades necessárias podem ser interrompidas.
- É mais frequente permitir/negar acesso usando security groups, mas essa é a única forma de cortar completamente reverse shells já estabelecidos. Uma regra modificada em um security group não interrompe conexões já estabelecidas.
- No entanto, isso se aplica à subnetwork inteira — tenha cuidado ao proibir coisas, pois funcionalidades necessárias podem ser afetadas.
### Security Groups
Security groups são um **firewall** virtual que controla o tráfego de rede de entrada e saída para instâncias em uma VPC. Relação 1 SG para M instâncias (geralmente 1 para 1).\
Geralmente isso é usado para abrir portas perigosas em instâncias, como a porta 22 por exemplo:
Geralmente isso é usado para abrir portas perigosas nas instâncias, como a porta 22 por exemplo:
<figure><img src="https://lh5.googleusercontent.com/LliB7eb3cYfkEyOpyw1-eYgWsn2kq1yF6uRn5VYndvOuTvDlURimYx9UvuK8F2impTLmx50mid4MdTXE-Ljt2i_rxaIfnKUdji_hFjCdU9tdoW-axng9-W4tSL71gbbjrPQ7IYY5lAdH_G3UoMRMGGGOxQ=s2048" alt=""><figcaption></figcaption></figure>
### Elastic IP Addresses
Um _Elastic IP address_ é um **endereço IPv4 estático** projetado para cloud computing dinâmico. Um Elastic IP address é alocado para sua conta AWS, e é seu até que você o libere. Ao usar um Elastic IP address, você pode mascarar a falha de uma instância ou software remapeando rapidamente o endereço para outra instância na sua conta.
Um _Elastic IP address_ é um **endereço IPv4 estático** projetado para computação em nuvem dinâmica. Um Elastic IP address é alocado para sua conta AWS, e é seu até que você o libere. Usando um Elastic IP address, você pode mascarar a falha de uma instância ou software remapeando rapidamente o endereço para outra instância na sua conta.
### Connection between subnets
### Conexão entre subnets
Por padrão, todas as subnets têm a **atribuição automática de public IP addresses desligada**, mas isso pode ser ativado.
Por padrão, todas as subnets têm a **atribuição automática de endereços IP públicos desativada**, mas isso pode ser ativado.
**Uma rota local dentro de uma route table permite comunicação entre subnets da VPC.**
Se você está **conectando uma subnet com outra subnet diferente você não pode acessar as subnets conectadas** à outra subnet; você precisa criar conexão diretamente com elas. **Isso também se aplica a internet gateways**. Você não pode passar por uma conexão de subnet para acessar a internet, é preciso atribuir o internet gateway à sua subnet.
Se você está **conectando uma subnet com outra subnet você não pode acessar as subnets conectadas** com a outra subnet; você precisa criar conexão com elas diretamente. **Isso também se aplica a internet gateways**. Você não pode passar por uma conexão de subnet para acessar a internet; você precisa atribuir o internet gateway à sua subnet.
### VPC Peering
VPC peering permite que você **conecte duas ou mais VPCs entre si**, usando IPV4 ou IPV6, como se fizessem parte da mesma rede.
Uma vez estabelecida a conectividade de peering, **recursos em uma VPC podem acessar recursos na outra**. A conectividade entre as VPCs é implementada através da infraestrutura de rede existente da AWS, e por isso é altamente disponível sem gargalos de largura de banda. Como **peered connections operam como se fossem parte da mesma rede**, há restrições quanto aos ranges de CIDR que podem ser usados.\
Se você tiver **CIDR sobrepostos ou duplicados** para suas VPCs, então **você não poderá fazer o peering entre as VPCs**.\
Cada AWS VPC **se comunicará apenas com seu peer**. Por exemplo, se você tiver um peering entre VPC 1 e VPC 2, e outra conexão entre VPC 2 e VPC 3 conforme mostrado, então VPC 1 e 2 poderão se comunicar diretamente, assim como VPC 2 e VPC 3; no entanto, VPC 1 e VPC 3 não poderão. **Você não pode rotear através de uma VPC para chegar a outra.**
Uma vez estabelecida a conectividade de peering, **recursos em uma VPC podem acessar recursos na outra**. A conectividade entre as VPCs é implementada por meio da infraestrutura de rede existente da AWS, portanto é altamente disponível sem gargalos de banda. Como **peered connections operam como se fizessem parte da mesma rede**, há restrições quanto aos intervalos de CIDR que podem ser usados.\
Se você tiver **CIDR sobrepostos ou duplicados** para suas VPCs, então **você não poderá fazer peering entre as VPCs**.\
Cada AWS VPC **se comunicará somente com seu peer**. Por exemplo, se você tiver uma peering connection entre VPC 1 e VPC 2, e outra entre VPC 2 e VPC 3 conforme mostrado, então VPC 1 e 2 poderiam se comunicar diretamente, assim como VPC 2 e VPC 3; entretanto, VPC 1 e VPC 3 não poderiam. **Você não pode rotear através de uma VPC para chegar a outra.**
### **VPC Flow Logs**
Dentro da sua VPC, você pode potencialmente ter centenas ou até milhares de recursos todos se comunicando entre diferentes subnets públicas e privadas e também entre diferentes VPCs através de VPC peering connections. **VPC Flow Logs permitem capturar informações de tráfego IP que fluem entre suas network interfaces dos recursos dentro da sua VPC**.
Dentro da sua VPC, você potencialmente pode ter centenas ou até milhares de recursos todos se comunicando entre diferentes subnets públicas e privadas e também entre diferentes VPCs através de VPC peering connections. **VPC Flow Logs permitem capturar informações de tráfego IP que fluem entre suas network interfaces dos seus recursos dentro da sua VPC**.
Diferentemente dos logs de acesso do S3 e do CloudFront, os **dados de log gerados por VPC Flow Logs não são armazenados no S3. Em vez disso, os dados de log capturados são enviados para CloudWatch logs**.
Ao contrário dos logs de acesso do S3 e dos logs de acesso do CloudFront, os **dados de log gerados por VPC Flow Logs não são armazenados em S3. Em vez disso, os dados de log capturados são enviados para CloudWatch logs**.
Limitações:
- Se você estiver executando uma VPC peered connection, então você só poderá ver flow logs das VPCs peered que estejam na mesma conta.
- Se você ainda estiver executando recursos dentro do ambiente EC2-Classic, então infelizmente você não consegue recuperar informações das interfaces deles.
- Uma vez que um VPC Flow Log tenha sido criado, ele não pode ser alterado. Para modificar a configuração do VPC Flow Log, você precisa deletá-lo e então recriar um novo.
- O seguinte tráfego não é monitorado nem capturado pelos logs: tráfego DHCP dentro da VPC, tráfego de instâncias destinado ao Amazon DNS Server.
- Qualquer tráfego destinado ao endereço IP do roteador padrão da VPC e tráfego de e para os seguintes endereços, 169.254.169.254 (usado para coletar instance metadata) e 169.254.169.123 (usado para o Amazon Time Sync Service).
- Se você estiver executando uma conexão VPC peered, então você só poderá ver flow logs de VPCs peered que estejam na mesma conta.
- Se você ainda estiver executando recursos no ambiente EC2-Classic, então infelizmente você não consegue recuperar informações das interfaces deles.
- Uma vez que um VPC Flow Log é criado, ele não pode ser alterado. Para modificar a configuração do VPC Flow Log, você precisa deletá-lo e então recriar um novo.
- O seguinte tráfego não é monitorado e capturado pelos logs: tráfego DHCP dentro da VPC, tráfego de instâncias com destino ao Amazon DNS Server.
- Qualquer tráfego com destino ao endereço IP do roteador padrão da VPC e tráfego de/para os seguintes endereços, 169.254.169.254 que é usado para coletar metadata da instância, e 169.254.169.123 que é usado para o Amazon Time Sync Service.
- Tráfego relacionado à ativação de licença do Amazon Windows a partir de uma instância Windows.
- Tráfego entre uma network load balancer interface e uma endpoint network interface.
- Tráfego entre uma interface de network load balancer e uma endpoint network interface.
Para cada network interface que publica dados no CloudWatch log group, será usado um log stream diferente. E dentro de cada um desses streams, haverá os dados de evento do flow log que mostram o conteúdo das entradas do log. Cada um desses **logs captura dados durante uma janela de aproximadamente 10 a 15 minutos**.
Para cada network interface que publica dados no CloudWatch log group, será usado um log stream diferente. E dentro de cada um desses streams, haverá os eventos de flow log que mostram o conteúdo das entradas do log. Cada um desses **logs captura dados durante uma janela de aproximadamente 10 a 15 minutos**.
## VPN
### Basic AWS VPN Components
### Componentes básicos do AWS VPN
1. **Customer Gateway**:
- Um Customer Gateway é um recurso que você cria na AWS para representar seu lado de uma conexão VPN.
- É essencialmente um dispositivo físico ou aplicativo de software no seu lado da Site-to-Site VPN connection.
- Você fornece informações de roteamento e o endereço IP público do seu dispositivo de rede (como um roteador ou firewall) à AWS para criar um Customer Gateway.
- Serve como um ponto de referência para configurar a conexão VPN e não gera cobranças adicionais.
- É essencialmente um dispositivo físico ou uma aplicação de software do seu lado da conexão Site-to-Site VPN.
- Você fornece informações de roteamento e o endereço IP público do seu dispositivo de rede (como um roteador ou firewall) para a AWS para criar um Customer Gateway.
- Serve como ponto de referência para configurar a conexão VPN e não gera cobranças adicionais.
2. **Virtual Private Gateway**:
- Um Virtual Private Gateway (VPG) é o concentrador VPN no lado Amazon da Site-to-Site VPN connection.
- Ele é attached à sua VPC e serve como o destino da sua conexão VPN.
- Um Virtual Private Gateway (VPG) é o concentrador VPN no lado Amazon da conexão Site-to-Site VPN.
- Ele é anexado à sua VPC e serve como o destino para sua conexão VPN.
- VPG é o endpoint do lado AWS para a conexão VPN.
- Ele lida com a comunicação segura entre sua VPC e sua rede on-premises.
3. **Site-to-Site VPN Connection**:
- Uma Site-to-Site VPN connection conecta sua rede on-premises a uma VPC através de um túnel VPN seguro IPsec.
- Esse tipo de conexão requer um Customer Gateway e um Virtual Private Gateway.
- É usado para comunicação segura, estável e consistente entre seu data center ou rede e seu ambiente AWS.
- Tipicamente usado para conexões regulares e de longo prazo e é cobrado com base na quantidade de dados transferidos pela conexão.
- Normalmente usado para conexões regulares e de longo prazo e é cobrado com base na quantidade de dados transferidos pela conexão.
4. **Client VPN Endpoint**:
- Um Client VPN endpoint é um recurso que você cria na AWS para habilitar e gerenciar sessões de client VPN.
- Ele é usado para permitir que dispositivos individuais (como laptops, smartphones, etc.) conectem-se com segurança a recursos AWS ou sua rede on-premises.
- Difere do Site-to-Site VPN pois é projetado para clientes individuais em vez de conectar redes inteiras.
- Com Client VPN, cada dispositivo cliente usa um software cliente VPN para estabelecer a conexão segura.
- Um Client VPN endpoint é um recurso que você cria na AWS para habilitar e gerenciar sessões de VPN de clientes.
- É usado para permitir que dispositivos individuais (como laptops, smartphones, etc.) se conectem com segurança a recursos AWS ou à sua rede on-premises.
- Difere do Site-to-Site VPN pelo fato de ser projetado para clientes individuais em vez de conectar redes inteiras.
- Com Client VPN, cada dispositivo cliente usa um software cliente VPN para estabelecer uma conexão segura.
### Site-to-Site VPN
**Conecte sua rede on premisses com sua VPC.**
**Conecte sua rede on-premises com sua VPC.**
- **VPN connection**: Uma conexão segura entre seu equipamento on-premises e suas VPCs.
- **VPN tunnel**: Um link criptografado onde dados podem passar da rede do cliente para a AWS ou vice-versa.
Cada VPN connection inclui dois VPN tunnels que você pode usar simultaneamente para alta disponibilidade.
- **Customer gateway**: Um recurso AWS que fornece informações à AWS sobre seu customer gateway device.
- **Customer gateway device**: Um dispositivo físico ou aplicativo de software no seu lado da Site-to-Site VPN connection.
- **Virtual private gateway**: O concentrador VPN no lado Amazon da Site-to-Site VPN connection. Você usa um virtual private gateway ou um transit gateway como o gateway para o lado Amazon da Site-to-Site VPN connection.
- **Transit gateway**: Um hub de trânsito que pode ser usado para interconectar suas VPCs e redes on-premises. Você usa um transit gateway ou virtual private gateway como o gateway para o lado Amazon da Site-to-Site VPN connection.
- **Customer gateway**: Um recurso AWS que fornece informações à AWS sobre seu dispositivo customer gateway.
- **Customer gateway device**: Um dispositivo físico ou aplicação de software do seu lado da conexão Site-to-Site VPN.
- **Virtual private gateway**: O concentrador VPN no lado Amazon da conexão Site-to-Site VPN. Você usa um virtual private gateway ou um transit gateway como o gateway para o lado Amazon da conexão Site-to-Site VPN.
- **Transit gateway**: Um hub de trânsito que pode ser usado para interconectar suas VPCs e redes on-premises. Você usa um transit gateway ou virtual private gateway como o gateway para o lado Amazon da conexão Site-to-Site VPN.
#### Limitations
#### Limitações
- IPv6 traffic não é suportado para VPN connections em um virtual private gateway.
- Tráfego IPv6 não é suportado para conexões VPN em um virtual private gateway.
- Uma AWS VPN connection não suporta Path MTU Discovery.
Além disso, considere o seguinte quando usar Site-to-Site VPN.
Além disso, considere o seguinte ao usar Site-to-Site VPN.
- Ao conectar suas VPCs a uma rede on-premises comum, recomendamos que você use blocos CIDR não sobrepostos para suas redes.
### Client VPN <a href="#what-is-components" id="what-is-components"></a>
**Conecte da sua máquina à sua VPC**
**Conecte-se da sua máquina à sua VPC**
#### Concepts
#### Conceitos
- **Client VPN endpoint:** O recurso que você cria e configura para habilitar e gerenciar sessões de client VPN. É o recurso onde todas as sessões client VPN terminam.
- **Client VPN endpoint:** O recurso que você cria e configura para habilitar e gerenciar sessões de VPN de clientes. É o recurso onde todas as sessões de Client VPN terminam.
- **Target network:** Uma target network é a rede que você associa a um Client VPN endpoint. **Uma subnet de uma VPC é uma target network**. Associar uma subnet a um Client VPN endpoint permite que você estabeleça sessões VPN. Você pode associar múltiplas subnets a um Client VPN endpoint para alta disponibilidade. Todas as subnets devem ser da mesma VPC. Cada subnet deve pertencer a uma Availability Zone diferente.
- **Route**: Cada Client VPN endpoint tem uma route table que descreve as rotas de rede de destino disponíveis. Cada rota na route table especifica o caminho para o tráfego a recursos ou redes específicas.
- **Authorization rules:** Uma authorization rule **restrige os usuários que podem acessar uma rede**. Para uma rede especificada, você configura o grupo do Active Directory ou do identity provider (IdP) que tem permissão de acesso. Somente usuários pertencentes a esse grupo podem acessar a rede especificada. **Por padrão, não existem authorization rules** e você deve configurá-las para permitir que usuários acessem recursos e redes.
- **Client:** O usuário final conectando-se ao Client VPN endpoint para estabelecer uma sessão VPN. Usuários finais precisam baixar um OpenVPN client e usar o Client VPN configuration file que você criou para estabelecer a sessão VPN.
- **Client CIDR range:** Um range de endereços IP do qual serão atribuídos endereços IP aos clientes. Cada conexão ao Client VPN endpoint recebe um endereço IP único do client CIDR range. Você escolhe o client CIDR range, por exemplo, `10.2.0.0/16`.
- **Route**: Cada Client VPN endpoint tem uma route table que descreve as rotas de destino de rede disponíveis. Cada rota na route table especifica o caminho para o tráfego para recursos ou redes específicas.
- **Authorization rules:** Uma authorization rule **restrige os usuários que podem acessar uma rede**. Para uma rede especificada, você configura o Active Directory ou o grupo do identity provider (IdP) que tem permissão de acesso. Apenas usuários pertencentes a esse grupo podem acessar a rede especificada. **Por padrão, não existem authorization rules** e você deve configurar authorization rules para permitir que usuários acessem recursos e redes.
- **Client:** O usuário final conectando-se ao Client VPN endpoint para estabelecer uma sessão VPN. Os usuários finais precisam baixar um cliente OpenVPN e usar o arquivo de configuração do Client VPN endpoint que você criou para estabelecer a sessão VPN.
- **Client CIDR range:** Um intervalo de endereços IP a partir do qual atribuir endereços IP aos clientes. Cada conexão ao Client VPN endpoint recebe um endereço IP único do client CIDR range. Você escolhe o client CIDR range, por exemplo, `10.2.0.0/16`.
- **Client VPN ports:** AWS Client VPN suporta as portas 443 e 1194 tanto para TCP quanto para UDP. O padrão é a porta 443.
- **Client VPN network interfaces:** Quando você associa uma subnet com seu Client VPN endpoint, criamos Client VPN network interfaces nessa subnet. **O tráfego enviado para a VPC a partir do Client VPN endpoint é enviado através de uma Client VPN network interface**. Então é aplicado Source network address translation (SNAT), onde o endereço IP de origem do client CIDR range é traduzido para o endereço IP da Client VPN network interface.
- **Client VPN network interfaces:** Quando você associa uma subnet ao seu Client VPN endpoint, criamos Client VPN network interfaces nessa subnet. **O tráfego enviado à VPC a partir do Client VPN endpoint é enviado através de uma Client VPN network interface**. Em seguida é aplicada tradução de endereço de origem (SNAT), onde o endereço IP de origem do client CIDR range é traduzido para o endereço IP da Client VPN network interface.
- **Connection logging:** Você pode habilitar connection logging para seu Client VPN endpoint para registrar eventos de conexão. Você pode usar essas informações para realizar forense, analisar como seu Client VPN endpoint está sendo usado ou depurar problemas de conexão.
- **Self-service portal:** Você pode habilitar um self-service portal para seu Client VPN endpoint. Clientes podem entrar no portal web usando suas credenciais e baixar a versão mais recente do Client VPN endpoint configuration file, ou a versão mais recente do client fornecido pela AWS.
- **Self-service portal:** Você pode habilitar um self-service portal para seu Client VPN endpoint. Clientes podem fazer login no portal web usando suas credenciais e baixar a versão mais recente do arquivo de configuração do Client VPN endpoint, ou a versão mais recente do cliente fornecido pela AWS.
#### Limitations
#### Limitações
- **Client CIDR ranges cannot overlap with the local CIDR** da VPC na qual a subnet associada está localizada, ou com quaisquer rotas adicionadas manualmente à route table do Client VPN endpoint.
- Client CIDR ranges devem ter um bloco de tamanho de pelo **menos /22** e não devem **ser maior que /12.**
- Uma **porção dos endereços** no client CIDR range é usada para **suportar o modelo de disponibilidade** do Client VPN endpoint, e não pode ser atribuída a clientes. Portanto, recomendamos que você **atribua um bloco CIDR que contenha o dobro do número de endereços IP que são necessários** para permitir o número máximo de conexões simultâneas que planeja suportar no Client VPN endpoint.
- **Client CIDR ranges não podem se sobrepor com o CIDR local** da VPC na qual a subnet associada está localizada, ou com quaisquer rotas adicionadas manualmente à route table do Client VPN endpoint.
- Client CIDR ranges devem ter um tamanho de bloco de **pelo menos /22** e não devem **ser maiores que /12.**
- **Uma porção dos endereços** no client CIDR range é usada para **suportar o modelo de disponibilidade** do Client VPN endpoint, e não pode ser atribuída a clientes. Portanto, recomendamos que você **atribua um bloco CIDR que contenha o dobro do número de endereços IP que são necessários** para permitir o número máximo de conexões simultâneas que você planeja suportar no Client VPN endpoint.
- O **client CIDR range não pode ser alterado** após a criação do Client VPN endpoint.
- As **subnets** associadas a um Client VPN endpoint **devem estar na mesma VPC**.
- Você **não pode associar múltiplas subnets da mesma Availability Zone a um Client VPN endpoint**.
- Um Client VPN endpoint **não suporta associações de subnet em uma VPC com tenancy dedicada**.
- Client VPN suporta apenas **IPv4**.
- Client VPN **não é** compliant com Federal Information Processing Standards (**FIPS**).
- Se multi-factor authentication (MFA) estiver desabilitado para seu Active Directory, uma senha de usuário não pode estar no seguinte formato.
- Um Client VPN endpoint **não suporta associações de subnet em uma VPC com tenancy dedicado**.
- Client VPN suporta **apenas tráfego IPv4**.
- Client VPN **não é** compatível com Federal Information Processing Standards (**FIPS**).
- Se a autenticação multifator (MFA) estiver desabilitada para seu Active Directory, uma senha de usuário não pode ter o seguinte formato.
```
SCRV1:<base64_encoded_string>:<base64_encoded_string>
@@ -6,34 +6,34 @@
Amazon S3 é um serviço que permite que você **armazene grandes quantidades de dados**.
Amazon S3 fornece múltiplas opções para alcançar a **proteção** dos dados em repouso. As opções incluem **Permissão** (Policy), **Criptografia** (Client and Server Side), **Bucket Versioning** e **MFA** **based delete**. O **usuário pode habilitar** qualquer uma dessas opções para alcançar a proteção dos dados. **Replicação de dados** é uma funcionalidade interna da AWS onde **S3 replica automaticamente cada objeto por todas as Availability Zones** e a organização não precisa habilitá-la nesse caso.
Amazon S3 oferece múltiplas opções para alcançar a **proteção** dos dados em repouso. As opções incluem **Permissão** (Policy), **Criptografia** (lado do cliente e do servidor), **Bucket Versioning** e **exclusão baseada em MFA**. O **usuário pode ativar** qualquer uma dessas opções para alcançar a proteção dos dados. **Replicação de dados** é uma funcionalidade interna da AWS onde **S3 automaticamente replica cada objeto através de todas as Availability Zones** e a organização não precisa ativá-la nesse caso.
Com permissões baseadas em recursos, você pode definir permissões para sub-diretórios do seu bucket separadamente.
Com permissões baseadas em recursos, você pode definir permissões separadamente para subdiretórios do seu bucket.
### Bucket Versioning and MFA based delete
### Bucket Versioning e exclusão baseada em MFA
Quando bucket versioning está habilitado, qualquer ação que tente alterar um arquivo dentro de um arquivo gerará uma nova versão do arquivo, mantendo também o conteúdo anterior do mesmo. Portanto, não sobrescreverá seu conteúdo.
Quando o Bucket Versioning está habilitado, qualquer ação que tente alterar um arquivo gerará uma nova versão do arquivo, mantendo também o conteúdo anterior. Portanto, ele não sobrescreverá o conteúdo.
Além disso, MFA based delete impedirá que versões de arquivos no bucket S3 sejam deletadas e também que o Bucket Versioning seja desabilitado, de forma que um atacante não poderá alterar esses arquivos.
Além disso, a exclusão baseada em MFA impedirá que versões de arquivos no bucket S3 sejam excluídas e também impedirá que o Bucket Versioning seja desativado, de modo que um atacante não poderá alterar esses arquivos.
### S3 Access logs
É possível **habilitar S3 access login** (que por padrão está desabilitado) em um bucket e salvar os logs em um bucket diferente para saber quem está acessando o bucket (ambos os buckets devem estar na mesma região).
É possível **ativar o S3 access login** (que por padrão está desabilitado) para algum bucket e salvar os logs em um bucket diferente para saber quem está acessando o bucket (ambos os buckets devem estar na mesma região).
### S3 Presigned URLs
É possível gerar uma presigned URL que geralmente pode ser usada para **acessar o arquivo especificado** no bucket. Uma **presigned URL looks like this**:
É possível gerar uma presigned URL que geralmente pode ser usada para **acessar o arquivo especificado** no bucket. Uma **presigned URL se parece com isto**:
```
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
```
Uma presigned URL pode ser **criada pelo cli usando credentials de um principal com acesso ao object** (se a account que você usar não tiver acesso, uma presigned URL mais curta será criada, mas será inútil)
Uma URL pré-assinada pode ser **criada a partir da cli usando credenciais de um principal com acesso ao objeto** (se a conta que você usa não tiver acesso, uma URL pré-assinada mais curta será criada, mas será inútil)
```bash
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
```
> [!NOTE]
> A única permissão necessária para gerar uma URL pré-assinada é a permissão que está sendo concedida, portanto, para o comando anterior a única permissão necessária ao principal é `s3:GetObject`
>
> Também é possível criar URLs pré-assinadas com **outras permissões**:
> A única permissão necessária para gerar um presigned URL é a permissão que está sendo concedida, então para o comando anterior a única permissão necessária pelo principal é `s3:GetObject`
Também é possível criar presigned URLs com **outras permissões**:
```python
import boto3
url = boto3.client('s3').generate_presigned_url(
@@ -44,97 +44,97 @@ ExpiresIn=3600
```
### Mecanismos de Criptografia do S3
**DEK significa Data Encryption Key** e é a chave que é sempre gerada e usada para criptografar os dados.
**DEK significa Chave de Criptografia de Dados (Data Encryption Key)** e é a chave que é sempre gerada e usada para criptografar dados.
<details>
<summary><strong>Criptografia no lado do servidor com chaves gerenciadas pelo S3, SSE-S3</strong></summary>
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
Esta opção requer configuração mínima e todo o gerenciamento das chaves de criptografia é feito pela AWS. Tudo o que você precisa fazer é **fazer upload dos seus dados e o S3 cuidará de todos os demais aspectos**. Cada bucket em uma conta S3 recebe uma bucket key.
Esta opção requer configuração mínima e todo o gerenciamento das chaves de criptografia usadas é feito pela AWS. Tudo o que você precisa fazer é **fazer upload dos seus dados e o S3 cuidará de todos os outros aspectos**. Cada bucket em uma conta S3 recebe uma chave de bucket.
- Criptografia:
- Dados do objeto + DEK em texto claro criado --> Dados criptografados (armazenados dentro do S3)
- DEK em texto claro criado + S3 Master Key --> DEK criptografado (armazenado dentro do S3) e o texto em claro é apagado da memória
- Descriptografia:
- DEK criptografado + S3 Master Key --> DEK em texto claro
- DEK em texto claro + dados criptografados --> Dados do objeto
- Encryption:
- 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
- Decryption:
- Encrypted DEK + S3 Master Key --> Plaintext DEK
- Plaintext DEK + Encrypted data --> Object Data
Por favor, note que neste caso **a chave é gerenciada pela AWS** (rotação apenas a cada 3 anos). Se você usar sua própria chave, poderá rotacionar, desabilitar e aplicar controle de acesso.
Por favor, note que neste caso **a chave é gerenciada pela AWS** (rotacionamento apenas a cada 3 anos). Se você usar sua própria chave você poderá rotacionar, desabilitar e aplicar controle de acesso.
</details>
<details>
<summary><strong>Criptografia no lado do servidor com chaves gerenciadas pelo KMS, SSE-KMS</strong></summary>
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
Este método permite que o S3 use o Key Management Service para gerar suas data encryption keys. O KMS oferece muito mais flexibilidade sobre como suas chaves são gerenciadas. Por exemplo, você pode desabilitar, rotacionar e aplicar controles de acesso à CMK, e auditar o uso delas usando AWS CloudTrail.
Este método permite que o S3 utilize o Key Management Service para gerar suas data encryption keys. KMS oferece muito mais flexibilidade sobre como suas chaves são gerenciadas. Por exemplo, você pode desabilitar, rotacionar e aplicar controles de acesso ao CMK, e auditar seu uso usando AWS Cloud Trail.
- Criptografia:
- S3 solicita as data keys ao KMS CMK
- KMS usa uma CMK para gerar o par DEK em texto claro e DEK criptografado e os envia para o S3
- S3 usa a chave em texto claro para criptografar os dados, armazena os dados criptografados e a chave criptografada e apaga da memória a chave em texto claro
- Descriptografia:
- S3 solicita ao KMS a descriptografia da data key criptografada do objeto
- KMS descriptografa a data key com a CMK e a envia de volta ao S3
- S3 descriptografa os dados do objeto
- Encryption:
- 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
- Decryption:
- 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>Criptografia no lado do servidor com chaves fornecidas pelo cliente, SSE-C</strong></summary>
<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
Esta opção dá a você a oportunidade de fornecer sua própria master key que você talvez já use fora da AWS. Sua chave fornecida pelo cliente então seria enviada com seus dados para o S3, onde o S3 realizaria a criptografia para você.
Esta opção lhe dá a oportunidade de fornecer sua própria master key que você já pode estar usando fora da AWS. Sua chave fornecida pelo cliente seria então enviada junto com seus dados para o S3, onde o S3 realizaria a criptografia para você.
- Criptografia:
- O usuário envia os dados do objeto + chave do cliente para o S3
- A chave do cliente é usada para criptografar os dados e os dados criptografados são armazenados
- um valor HMAC salgado da chave do cliente também é armazenado para validação futura da chave
- a chave do cliente é excluída da memória
- Descriptografia:
- O usuário envia a chave do cliente
- A chave é validada contra o valor HMAC armazenado
- A chave fornecida pelo cliente é então usada para descriptografar os dados
- Encryption:
- 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
- Decryption:
- 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>Criptografia no lado do cliente com KMS, CSE-KMS</strong></summary>
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
De forma semelhante ao SSE-KMS, isto também usa o Key Management Service para gerar suas data encryption keys. Entretanto, desta vez o KMS é chamado pelo cliente, não pelo S3. A criptografia então ocorre no lado do cliente e os dados criptografados são enviados ao S3 para armazenamento.
Semelhante ao SSE-KMS, este também usa o Key Management Service para gerar suas data encryption keys. Porém, desta vez o KMS é chamado pelo cliente e não pelo S3. A criptografia então ocorre no lado do cliente e os dados criptografados são enviados ao S3 para armazenamento.
- Criptografia:
- O cliente solicita uma data key ao KMS
- KMS retorna o DEK em texto claro e o DEK criptografado com a CMK
- Ambas as chaves são retornadas
- O cliente então criptografa os dados com o DEK em texto claro e envia ao S3 os dados criptografados + o DEK criptografado (que é salvo como metadata dos dados criptografados dentro do S3)
- Descriptografia:
- Os dados criptografados com o DEK criptografado são enviados ao cliente
- O cliente solicita ao KMS a descriptografia da chave criptografada usando a CMK e o KMS envia de volta o DEK em texto claro
- O cliente agora pode descriptografar os dados criptografados
- Encryption:
- 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)
- Decryption:
- 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>Criptografia no lado do cliente com chaves fornecidas pelo cliente, CSE-C</strong></summary>
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
Usando este mecanismo, você pode utilizar suas próprias chaves fornecidas e usar um cliente AWS-SDK para criptografar seus dados antes de enviá-los ao S3 para armazenamento.
- Criptografia:
- O cliente gera um DEK e criptografa os dados em texto claro
- Em seguida, usando sua própria CMK customizada, criptografa o DEK
- envia os dados criptografados + DEK criptografado ao S3, onde são armazenados
- Descriptografia:
- S3 envia os dados criptografados e o DEK
- Como o cliente já possui a CMK usada para criptografar o DEK, ele descriptografa o DEK e então usa o DEK em texto claro para descriptografar os dados
- Encryption:
- 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
- Decryption:
- 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>
### **Enumeração**
Uma das formas tradicionais de comprometer organizações AWS começa explorando buckets publicamente acessíveis. **Você pode encontrar** [**enumeradores de buckets públicos nesta página**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
Uma das maneiras tradicionais de comprometer organizações AWS começa comprometendo buckets publicamente acessíveis. **Você pode encontrar** [**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>
@@ -229,7 +229,7 @@ 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>
É possível acessar um bucket S3 através de um endpoint dual-stack usando um nome de endpoint em virtual hosted-style ou path-style. Estes são úteis para acessar o S3 via IPv6.
Você pode acessar um bucket S3 através de um endpoint dual-stack usando um nome de endpoint em estilo virtual hosted ou path-style. Eles são úteis para acessar o S3 via IPv6.
Dual-stack endpoints usam a seguinte sintaxe:
@@ -238,13 +238,13 @@ Dual-stack endpoints usam a seguinte sintaxe:
### Privesc
Na página seguinte você pode verificar como **abuse S3 permissions to escalate privileges**:
Na página a seguir você pode verificar como **abusar permissões do S3 para escalar privilégios**:
{{#ref}}
../aws-privilege-escalation/aws-s3-privesc/README.md
{{#endref}}
### Unauthenticated Access
### Acesso não autenticado
{{#ref}}
../aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
@@ -262,7 +262,7 @@ Na página seguinte você pode verificar como **abuse S3 permissions to escalate
../aws-persistence/aws-s3-persistence/README.md
{{#endref}}
## Other S3 vulns
## Outras vulnerabilidades do S3
### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
@@ -270,17 +270,17 @@ Na página seguinte você pode verificar como **abuse S3 permissions to escalate
## Amazon Athena
Amazon Athena é um serviço de query interativo que facilita **analisar dados** diretamente no Amazon Simple Storage Service (Amazon **S3**) **usando** **SQL** padrão.
Amazon Athena é um serviço interativo de consulta que facilita a **análise de dados** diretamente no Amazon Simple Storage Service (Amazon **S3**) **usando** **SQL** padrão.
Você precisa preparar uma tabela relacional DB com o formato do conteúdo que aparecerá nos buckets S3 monitorados. Em seguida, o Amazon Athena será capaz de popular o DB a partir dos logs, permitindo que você faça consultas.
Você precisa **preparar uma tabela relacional DB** com o formato do conteúdo que vai aparecer nos buckets S3 monitorados. Então, o Amazon Athena será capaz de popular o DB a partir dos logs, permitindo que você o consulte.
Amazon Athena suporta a capacidade de consultar dados S3 que já estão criptografados e, se configurado para isso, o Athena também pode criptografar os resultados da consulta, os quais podem então ser armazenados no S3.
Amazon Athena suporta a **capacidade de consultar dados do S3 que já estão criptografados** e, se configurado para isso, **Athena também pode criptografar os resultados da consulta que então podem ser armazenados no S3**.
**Essa criptografia dos resultados é independente dos dados S3 consultados subjacentes**, o que significa que mesmo que os dados S3 não estejam criptografados, os resultados da consulta podem ser criptografados. Alguns pontos a observar: o Amazon Athena só suporta dados que tenham sido **criptografados** com os **seguinte métodos de criptografia do S3**, **SSE-S3, SSE-KMS, and CSE-KMS**.
**Essa criptografia dos resultados é independente dos dados S3 subjacentes consultados**, o que significa que mesmo que os dados do S3 não estejam criptografados, os resultados da consulta podem ser criptografados. Alguns pontos a observar são que o Amazon Athena só suporta dados que foram **criptografados** com os **seguintes métodos de criptografia do S3**, **SSE-S3, SSE-KMS, and CSE-KMS**.
SSE-C e CSE-C não são suportados. Além disso, é importante entender que o Amazon Athena só executará consultas contra objetos criptografados que estejam na mesma região da própria consulta. Se você precisar consultar dados S3 que foram criptografados usando KMS, permissões específicas são exigidas para o usuário do Athena permitir que ele execute a consulta.
SSE-C e CSE-C não são suportados. Além disso, é importante entender que o Amazon Athena só executará consultas contra **objetos criptografados que estejam na mesma região da própria consulta**. Se você precisar consultar dados do S3 que foram criptografados usando KMS, permissões específicas são exigidas pelo usuário do Athena para permitir que ele execute a consulta.
### Enumeration
### Enumeração
```bash
# Get catalogs
aws athena list-data-catalogs