Estou fazendo um curso sobre AWS. O que estou tentando fazer é configurar uma VPC com dois servidores Linux. Configurei o VPC com duas sub-redes. Coloquei um servidor em cada um. A ideia é que uma sub-rede seja pública e a outra seja privada.
Criei duas Network ACLs e associei uma a cada sub-rede.
Posso usar SSH da minha máquina para o servidor na sub-rede pública. Quando tento fazer SSH para o servidor em minha sub-rede privada, estou obtendo um tempo limite de conexão.
Não tenho certeza de quais regras preciso definir em minhas duas Network ACLs para que o SSH funcione. Alguém pode ajudar? Dado que estou aprendendo, eu apreciaria uma explicação de por que as regras deveriam ser, e não apenas quais deveriam ser as regras.
Eu tenho uma VPC chamada MyVPC com CIDR 10.0.0.0/16
Minha primeira sub-rede é chamada MyVPCSub1 CIDR 10.0.1.0/24
Minha segunda sub-rede é chamada MyVPCSub2 CIDR 10.0.2.0/24
Eu tenho uma tabela de rotas chamada MyInternetRoute associada às rotas MyVPCSub1 são:
|Dest |Targ |
|10.0.0.0/16 |local |
|0.0.0.0/0 |igw |
Eu tenho uma tabela de rotas chamada MyPrivate associada ao MyVPCSub2. As rotas são:
|Dest |Targ |
|10.0.0.0/16 |local |
Eu tenho uma Network ACL chamada MyWeb associada ao MyVPCSub1 com regras:
Entrada:
| # | Type | Protocol | Ports | Source | A/D
| 99 | HTTP | TCP | 80 | {My IP}/32 | D
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A
| 200 | HTTPS| TCP | 443 | 0.0.0.0/0 | A
| 300 | SSH | TCP | 22 | {My IP}/32 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Saída:
| # | Type | Protocol | Ports | Source | A/D
| 50 | ALL | ALL | ALL | 0.0.0.0/0 | A
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A
| 200 | HTTPS | TCP | 443 | 0.0.0.0/0 | A
| 300 | Custom | TCP | 1024-65535 | 0.0.0.0/32 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Eu tenho uma Network ACL chamada MyPrivate associada ao MyVPCSub2 com regras:
Entrada:
| # | Type | Protocol | Ports | Source | A/D
| 100 | ALL | ALL | ALL | 0.0.0.0/0 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Saída:
| # | Type | Protocol | Ports | Source | A/D
| 100 | ALL | ALL | ALL | 0.0.0.0/0 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Responder1
A primeira coisa é definir o que significam alguns dos termos.
NACLS - Listas de Controle de Acesso à Rede, são um estadomenosfiltro de pacotes aplicado no nível da sub-rede. É importante ter em mente o aspecto “sem estado”, pois isso significa que você precisa ser explícito para todo o tráfego que entra e sai da sub-rede. Por exemplo, com uma abordagem de regra 'state-full' (que é o que o Security Group na AWS aplica), você pode simplesmente especificar o tráfego de entrada do TCP/22 para SSH e ele permitirá automaticamente o tráfego de saída. Com NACLS este não é o caso, você precisará especificar uma regra em cada direção para permitir a passagem do tráfego.
Grupos de Segurança - estes são grupos de estadoscompletoregras que podem ser aplicadas a uma ou mais instâncias em uma VPC. Observe que eles se aplicam no nível da instância. O grupo de segurança pode ser comparado a um firewall tradicional com estado completo, mas como é aplicado no nível de instância individual, você pode segregar instâncias umas das outras, mesmo dentro da mesma sub-rede, o que é bom. E como eles são state-full, se você quiser permitir o tráfego em um servidor (por exemplo, TCP/22 para SSH), você não precisa se preocupar em criar uma regra de saída correspondente, a plataforma cuida disso automaticamente, então eles são muito mais fáceis de gerenciar – o que também significa menos chances de erros.
Existe uma bela tabela que compara esses dois:Comparação de segurança de VPC
Há também um belo diagrama nessa página que mostra a ordem das coisas sendo aplicadas ao tráfego, dependendo da direção do fluxo... então verifique isso.
Então em termos de sub-redes temos:
Sub-rede pública - nos termos da AWS, é simplesmente uma sub-rede que possui uma tabela de rotas anexada que possui uma rota 0.0.0.0/0 por meio de um gateway de Internet anexado
Sub-rede privada - é o oposto, ou seja,nãotenha uma rota 0.0.0.0/0 por meio de um gateway de Internet conectado. Observe que ele ainda pode ter uma rota 0.0.0.0/0 por meio de um gateway NAT ou proxy semelhante em seu ambiente, mas não direto.
A questão é: quando você tem NACLS e grupos de segurança - quais você usa. A AWS descreve os NACLs como uma “camada opcional de segurança para sua VPC”. E é verdade que em geral os Grupos de Segurança são suficientes, são mais flexíveis e proporcionam a mesma proteção. Na minha experiência, há alguns casos típicos em que vejo NACLS usado:
- Buracos negros para malfeitores conhecidos - se você foi atacado por um intervalo de IP específico, é uma abordagem fácil apenas adicionar um NACL que bloqueia completamente a origem do IP/sub-rede.
- Como forma de delegar o controle às equipes - a equipe de segurança aplica configurações NACL amplas (por exemplo, permitindo apenas o tráfego de redes corporativas confiáveis) e, em seguida, permite que as equipes de operações/desenvolvimento configurem suas próprias regras de grupo de segurança. Dessa forma, mesmo que o engenheiro tente abrir o grupo de segurança em sua instância para teste na Internet, o NACL irá bloqueá-lo. Você pode usar o IAM para restringir quem pode modificar NACLs, mas conceder acesso às equipes para controlar todo o resto. Ele atua como uma excelente barreira para erros de configuração incorreta em ambientes maiores.
A AWS também fornece algumas orientações sobre vários cenários de configuração disponíveis aqui:Regras de Network ACL recomendadas para sua VPC
Minha orientação, porém, é que normalmente os grupos de segurança fornecem proteção adequada, são mais fáceis de entender e configurar e são mais flexíveis e granulares em sua aplicação. Os NACLs fornecem uma proteção extra para erros humanos ou configurações mais avançadas, mas para uso básico eles normalmente não são usados. Portanto, presumo por que a AWS se refere a eles como "opcionais".
Eu deixaria os NACLs em sua configuração padrão (permitiria todo o tráfego de entrada e saída) e, em vez disso, focaria nos grupos de segurança por enquanto, pois usar NACLs como segunda camada apenas adicionará uma camada extra de complexidade que talvez não seja necessária no seu cenário. Do ponto de vista do aprendizado, é bom saber que eles estão lá, não têm estado, se aplicam no nível da sub-rede e se aplicam após a decisão de roteamento e antes dos grupos de segurança no tráfego que entra em uma sub-rede.
Em relação à sua situação específica, como você está usando NACLs, você precisa se lembrar que elas sãomenos. Portanto, todos os fluxos de tráfego que entram e saem da sub-rede precisam ser contabilizados – a principal razão pela qual os Grupos de Segurança são muito mais fáceis. Então no seu caso você tem:
- Tráfego para seu servidor público em TCP/22 a partir do seu IP - sim - entrada da regra nº 300
- Retorne o tráfego do seu servidor público em uma porta alta para o tráfego SSH de retorno - sim - regra nº 50 de saída (mas não a regra nº 300 - veja abaixo)
- Tráfego da sua sub-rede pública de saída para sua sub-rede privada em TCP/22 - sim - regra nº 50 de saída
- Tráfego de entrada na sub-rede privada vindo da pública - sim - regra nº 100 de entrada
- Retorne o tráfego do seu servidor privado para o servidor público na sub-rede privada - sim - regra nº 100 de saída
- Retorne o tráfego do seu servidor privado para o servidor público nopúblicosub-rede - ah - não, não existe uma regra para permitir a porta alta (a porta efêmera que o cliente ssh está usando no servidor público para iniciar a conexão com o servidor privado) de volta do servidor privado.
Você precisa adicionar uma regra como a regra nº 300 (mas observe que você formatou o IP de origem um pouco errado - veja abaixo) na sua ACL de sub-rede pública de saída, mas vinculada, com uma origem da sub-rede privada. Então, supondo que seus grupos de segurança estejam bem configurados, você deve estar pronto.
Espero que ajude.
Para adicionar - conforme a outra resposta - a regra nº 300 no conjunto de regras de saída da sub-rede pública está formatada incorretamente. Deveria ser 0.0.0.0/0 e não 0.0.0.0/32, no entanto, no seu caso, você não estava acertando isso, pois a regra nº 50 é atingida primeiro e permite todo o tráfego de qualquer maneira - então, embora não funcionasse, era na verdade não está causando o seu problema.
Responder2
ACLs não têm estado.
Sua sub-rede “pública” provavelmente está bloqueando o caminho de retorno da sua conexão SSH da sub-rede privada. Você também precisa de uma regra equivalente à sua saída para todas as portas no lado de entrada, embora possa restringir isso ao intervalo de sub-rede 10.0.2.0/24.
Editado para adicionar: Além disso, a regra de saída para 0.0.0.0/32 está errada. A menos que seu IP seja exatamente 0.0.0.0, não funcionará.