Proteja o banco de relatórios

Introdução

Uma aplicação de relatórios lê pedidos sintéticos de outro banco PostgreSQL. External Probe também alcança esse banco atualmente. A página de relatórios deve continuar disponível enquanto você fecha esse caminho indevido.

Este Challenge começa em um ambiente independente. Aplique os testes de conexão, a inspeção de rotas e as regras ordenadas de Gateway do laboratório a outro mapa de endereços e outra porta do banco.

Proteja o banco de relatórios

Situação atual

Abra Order Page para ver pedidos, mapa de rede e observações de conexão ao vivo. Report Client é o nó legítimo da aplicação; External Probe representa um cliente indevido. Gateway controla o tráfego encaminhado. Os contêineres têm namespaces de rede separados e compartilham o kernel de uma instância.

Escopo

Altere apenas a cadeia LAB_FORWARD do Gateway em execução. Não mude rotas, endereços, credenciais, configuração do banco, código ou serviços. A cadeia superior FORWARD já está conectada e nega o que ficar sem correspondência. As regras devem durar esta sessão; persistência após reiniciar está fora do escopo.

Origem	Destino	Resultado exigido
Report Client `172.29.10.40`	Banco `172.29.20.15:5544`	Permitir leituras PostgreSQL reais
External Probe `172.29.10.50`	Banco `172.29.20.15:5544`	Bloquear novas conexões TCP
Ambos os clientes	Status público `172.29.20.15:8001`	Permitir

O próximo salto dos clientes é 172.29.10.254; o banco responde por 172.29.20.254. Os dados fixos são usuário shopapp, senha training-only, banco shop, tabela orders, colunas id e item. tcp-probe ADDRESS PORT, ip route get ADDRESS, psql e curl funcionam como ensinado. A aplicação usa a mesma credencial.

Referência: -A acrescenta ao fim, -s corresponde à origem, -d ao destino, -p tcp ao protocolo, --dport à porta de destino, e -j escolhe a ação. -F CHAIN esvazia apenas essa cadeia; -nvL CHAIN lista regras numéricas e contadores. Respostas precisam de rastreamento de conexões. Uma negação ampla antes de uma permissão específica prevalece.

Seu objetivo

O banco de relatórios deve aceitar o cliente legítimo e recusar novas conexões TCP de External Probe, mantendo a página e o status público funcionando. O banco e sua credencial devem permanecer inalterados.

Critérios de aceitação

Report Client lê linhas reais por PostgreSQL em 5544, com a credencial fixa.
External Probe não estabelece uma nova conexão TCP com essa porta.
External Probe continua recebendo PUBLIC STATUS OK em 8001; os pedidos de relatórios continuam carregando.
Existe o pedido practice-2 com item Green tea, criado em Order Page após a mudança. Não é necessário entregar relatório ou captura.

Dicas

Qual origem deve entrar na exceção?

Use o cliente que realmente abre a conexão com o banco, não o endereço do navegador ou de Gateway. O mapa e ip route get identificam essa origem.

Por que o tráfego legítimo parou?

Compare a primeira regra correspondente, a porta de destino e o tratamento de respostas. A porta difere do laboratório. Você pode reconstruir a cadeia após um erro de digitação.

Um erro de autenticação comprova contenção?

Uma rejeição de senha significa que PostgreSQL estava acessível. Teste o caminho proibido com TCP e o permitido com uma consulta real. Teste o status público separadamente.

Resumo

Você transferiu a filtragem do gateway para outro cliente e porta, preservando relatórios apoiados no banco e o status público. Testes funcionais de permitir/negar comprovam o resultado; um gateway permissivo, banco parado ou senha inválida não atendem ao objetivo.