Introdução
A aplicação de pedidos da Corner Shop lê e cria registros em um banco PostgreSQL privado. A página funciona, mas Visitor também consegue acessar o banco diretamente. Uma aplicação funcionando não comprova que a fronteira do banco está segura.
Você comparará conexões reais, restringirá o encaminhamento no Gateway preparado e preservará pedidos e um serviço público de status. Basta saber usar o terminal. Pessoas e registros são sintéticos. Os três nós de terminal são contêineres com namespaces de rede separados, compartilhando o kernel de uma instância; não são VMs independentes.
Siga um pedido e seu caminho de rede
Nesta etapa, você criará um pedido real e comparará dois caminhos até seu banco. A aplicação é o programa voltado ao cliente; o banco armazena os registros. Abra Order Page, encontre seed: Green tea, digite practice-1 em Order reference e clique em Create tea order. A nova linha fica armazenada no PostgreSQL, não apenas na página.
O mapa mostra o endereço IP de cada nó, que identifica um destino na rede. Uma porta identifica um serviço nesse endereço. PostgreSQL escuta em 172.28.20.10:5432; o serviço público separado usa 8001. App Client (172.28.10.20) precisa do banco. Visitor (172.28.10.30) precisa apenas do status público.
Alterne para App Client. O utilitário preparado tcp-probe abre uma conexão TCP real e espera no máximo três segundos. Os argumentos são endereço de destino e porta:
tcp-probe 172.28.20.10 5432
Espere TCP OPEN. Isso prova alcance, não permissão de leitura. psql é o cliente de consultas do PostgreSQL. O comando fornece a senha de treinamento apenas a esta execução. A string entre aspas agrupa servidor, porta, usuário, banco e limite de conexão de três segundos. -c executa o SQL entre aspas; SELECT lê as colunas indicadas de orders, e ORDER BY ordena o resultado. O ponto e vírgula encerra a instrução.
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Localize practice-1 e Green tea. A credencial propositalmente conhecida continuará igual para isolar a mudança de rede.
Alterne para Visitor e repita os dois comandos:
tcp-probe 172.28.20.10 5432
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Ambos funcionam: o cliente indevido consegue conectar e ler pedidos sintéticos. Uma senha inválida produziria erro de autenticação depois de alcançar PostgreSQL; a porta continuaria exposta.
Uma rota informa para onde um nó envia pacotes. Consulte a rota preparada de Visitor até o banco:
ip route get 172.28.20.10
Os campos importantes são via 172.28.10.254 (Gateway) e src 172.28.10.30 (Visitor). App Client usa o mesmo gateway com outra origem. A rota de retorno do banco aponta para a outra interface de Gateway, 172.28.20.254. Nenhum cliente possui interface direta na rede do banco. As rotas são infraestrutura preparada: não as altere. O pedido real é o ponto de verificação desta etapa; não se entrega relatório.
Permita apenas o caminho da aplicação até o banco
Nesta etapa, você filtrará pacotes que atravessam Gateway. Alterne para Gateway. iptables edita regras do filtro de pacotes do kernel. Uma cadeia é uma lista ordenada: a primeira decisão correspondente prevalece. FORWARD processa tráfego que atravessa o nó, enquanto INPUT trata tráfego destinado ao próprio nó. O ambiente conecta FORWARD à cadeia do laboratório LAB_FORWARD; sua regra permissiva inicial causa a exposição.
Inspecione as regras. -n mantém endereços numéricos, -v inclui contadores e -L lista a cadeia:
iptables -nvL LAB_FORWARD
Altere somente LAB_FORWARD neste terminal. Preserve regras do host, rotas, credenciais e serviços. As regras têm efeito imediato e duram esta sessão. Quatro decisões substituirão a regra permissiva. A cadeia superior preparada nega tudo que ficar sem correspondência.
-F esvazia a cadeia indicada. Os serviços encaminhados ficam brevemente bloqueados enquanto você adiciona regras; terminal e interface Order Page continuam acessíveis. Se errar a digitação, recomece neste esvaziamento e insira as quatro regras completas.
iptables -F LAB_FORWARD
As respostas também precisam voltar. Por exemplo, a resposta do banco segue para App Client, portanto o destino já não é a porta do banco. -A acrescenta ao fim, -m conntrack usa rastreamento de conexões, e --ctstate ESTABLISHED,RELATED identifica respostas ou tráfego relacionado a conexões já permitidas. -j ACCEPT permite o pacote correspondente:
iptables -A LAB_FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Agora permita novas conexões da aplicação. -s corresponde à origem, -d ao destino, -p tcp seleciona TCP e --dport corresponde à porta de destino. Um endereço individual representa exatamente aquele nó:
iptables -A LAB_FORWARD -s 172.28.10.20 -d 172.28.20.10 -p tcp --dport 5432 -j ACCEPT
Posicione a rejeição geral do banco depois da exceção da aplicação. Sem -s, ela abrange outras origens. REJECT --reject-with tcp-reset recusa explicitamente TCP, em vez de deixar o cliente esperar até o tempo limite:
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 5432 -j REJECT --reject-with tcp-reset
Por fim, preserve a porta pública separada para ambos os clientes. Permiti-la não expõe a porta do banco:
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 8001 -j ACCEPT
Liste o resultado:
iptables -nvL LAB_FORWARD
A ordem é: respostas, acesso da aplicação ao banco, rejeição geral do banco e status público. Uma rejeição antes da exceção também bloquearia a loja. Os contadores só aumentam quando tráfego correspondente realmente atravessa Gateway; a existência de uma regra não comprova sucesso. Atualize Order Page: App Client deve mostrar OPEN, Visitor BLOCKED, o status PUBLIC STATUS OK, e os pedidos devem continuar carregando.
Teste novamente a segurança e a loja
Nesta etapa, você confirmará a matriz de conexões e concluirá outro pedido real. Em App Client, abra uma nova conexão:
tcp-probe 172.28.20.10 5432
Espere TCP OPEN. Repita a leitura com a mesma credencial:
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Alterne para Visitor:
tcp-probe 172.28.20.10 5432
Espere TCP BLOCKED e uma explicação de conexão recusada. Esse comando retorna falha intencionalmente. Um descarte silencioso gera um tempo limite; ambos impedem uma nova conexão, mas o tempo limite sozinho não identifica a causa. Se App Client também falhar, confira a ordem e o tratamento de respostas no Gateway.
curl recupera um recurso web. --max-time 4 limita a solicitação inteira a quatro segundos; -f trata erros HTTP como falhas, -s oculta o progresso e -S mantém os erros visíveis. Em Visitor, teste o serviço público diferente:
curl --max-time 4 -fsS http://172.28.20.10:8001/status.txt
Espere PUBLIC STATUS OK. Bloquear todos os pacotes encaminhados violaria esse requisito mesmo fechando o caminho até o banco.
Abra Order Page, crie practice-2 e confirme os dois pedidos de exercício. Isso usa a conexão real da aplicação com o banco após o reparo. Atualize novamente: Visitor deve continuar bloqueado. Contadores ajudam no diagnóstico, mas um pedido bem-sucedido e os testes de permitir/bloquear são a evidência real. Não pare PostgreSQL nem altere sua senha para fazer uma consulta malsucedida do visitante parecer uma correção de segurança.
Resumo
Você seguiu um pedido até PostgreSQL, comparou dois clientes roteados, aplicou regras ordenadas de encaminhamento e testou segurança e disponibilidade. Um erro de senha difere de uma conexão TCP bloqueada. Ao fechar um caminho exposto, preserve a aplicação legítima e os outros serviços.
