Introdução
Uma regra de firewall só é útil quando produz o limite de acesso pretendido e preserva o serviço necessário. Adicionar apenas uma regra de permissão sob uma política padrão ACCEPT não prova que alguém tenha sido restringido.
Este laboratório fornece um serviço Kali dedicado e dois clientes de prática. Você inspecionará o acesso inicial deles, aplicará regras ordenadas com base na origem no Kali, salvará e restaurará a política do exercício e testará os dois caminhos de cliente.
Observe a rede de treinamento antes de restringir o acesso
Nesta etapa, você testará duas perspectivas de clientes fornecidas e inspecionará o firewall que protege seu serviço de treinamento.
Este laboratório fornece uma pequena rede dedicada dentro da VM. O serviço de treinamento Kali está em 172.30.77.10:8080; o cliente permitido usa 172.30.77.20 e o cliente a bloquear usa 172.30.77.30. Ambos têm acesso inicialmente. Esses são endereços da rede de prática, não alvos públicos.
Comece no Terminal inicial do host Ubuntu. O comando preparado training-client faz uma solicitação a partir de um cliente de prática nomeado. Ele é executado no host, enquanto a administração do firewall ocorrerá dentro do Kali. Escolha o espaço de trabalho compartilhado:
cd /home/labex/project
Salve o estado HTTP inicial do cliente permitido:
training-client allowed > allowed-before.txt
cat allowed-before.txt
A linha de estado deve conter 200 OK. Registre o acesso inicial do outro cliente:
training-client blocked > blocked-before.txt
cat blocked-before.txt
Ele também deve informar 200 OK; o rótulo nomeia o cliente que você bloqueará, não seu estado inicial.
Agora entre no Kali para inspecionar seu firewall:
kali
Iptables avalia regras de filtragem de pacotes em cadeias. INPUT trata pacotes destinados a este ambiente, OUTPUT trata pacotes gerados localmente e FORWARD trata pacotes roteados. -L INPUT lista a cadeia de entrada; -n mantém endereços e portas numéricos, enquanto -v inclui contadores:
sudo iptables -L INPUT -n -v
A cadeia de prática tem inicialmente a política ACCEPT. Uma política de cadeia se aplica quando nenhuma regra já decidiu o destino do pacote. Neste laboratório, você adicionará regras restritas para o serviço dedicado, deixando inalteradas as políticas padrão e o firewall do host.
Aplique e salve uma política ordenada de serviço
Nesta etapa, você permitirá o cliente atribuído antes de rejeitar outras origens da rede de prática para o mesmo serviço.
Permaneça no Kali. -A INPUT acrescenta uma regra à cadeia de entrada, -p tcp corresponde a TCP, -s corresponde a um endereço de origem, --dport seleciona a porta de destino e -j escolhe a ação. Adicione primeiro a regra restrita de permissão:
sudo iptables -A INPUT -p tcp -s 172.30.77.20 --dport 8080 -j ACCEPT
Em seguida, rejeite outras origens da sub-rede dedicada de prática para essa mesma porta. O prefixo /24 identifica a faixa de rede 172.30.77.0:
sudo iptables -A INPUT -p tcp -s 172.30.77.0/24 --dport 8080 -j REJECT
As regras são avaliadas em ordem. A origem permitida corresponde à primeira regra ACCEPT que encerra a avaliação; o outro cliente de prática chega à regra REJECT posterior. Inverter essas regras rejeitaria também o cliente permitido. Outras portas e origens continuam seguindo a política padrão inalterada.
Mostre a ordem das regras e os contadores. --line-numbers inclui a posição de cada regra:
sudo iptables -L INPUT -n -v --line-numbers
A primeira regra deve permitir o cliente atribuído no TCP 8080, e a regra posterior deve rejeitar o tráfego restante da sub-rede de prática para esse serviço.
iptables-save exibe as regras ativas em um formato que pode ser restaurado. Salve a configuração deste exercício no espaço de trabalho compartilhado:
sudo iptables-save > /home/labex/project/training.rules
O operador < do shell fornece um arquivo como entrada padrão de um comando. iptables-restore lê essa configuração salva; aqui você restaura exatamente as regras do exercício que acabou de salvar:
sudo iptables-restore < /home/labex/project/training.rules
Isso opera somente no ambiente de rede Kali dedicado. Não limpe o firewall do host nem substitua políticas padrão para realizar uma restrição específica de serviço.
Verifique o acesso permitido e negado dos clientes
Nesta etapa, você testará a política a partir das duas origens de clientes e confirmará que o serviço de treinamento permanece disponível.
Retorne do Kali ao Terminal do host Ubuntu para usar as perspectivas de clientes fornecidas:
exit
O prompt do host mostra labex. Registre o novo resultado do cliente permitido:
training-client allowed > /home/labex/project/allowed-after.txt
cat /home/labex/project/allowed-after.txt
Ele ainda deve informar 200 OK.
Espera-se que o próximo comando falhe com uma conexão recusada ou outro erro de conexão: este é o cliente que você bloqueou deliberadamente. Continue após a falha intencional:
training-client blocked
Uma solicitação malsucedida do cliente bloqueado só é significativa enquanto o caminho permitido ainda funciona. Interromper o serviço web quebraria os dois caminhos e não demonstraria a política exigida.
Retorne ao Kali e inspecione os contadores após os testes:
kali
sudo iptables -L INPUT -n -v --line-numbers
Os contadores das regras relevantes devem ter aumentado. Você verificou o comportamento real do tráfego além do texto das regras, e o Terminal do host LabEx permanece disponível durante todo o exercício.
Resumo
Você inspecionou políticas de cadeias, adicionou regras ordenadas com base na origem para um serviço, salvou e restaurou a configuração do exercício e testou o acesso real de dois clientes. A origem permitida e o serviço permaneceram disponíveis, enquanto o acesso da origem designada foi negado.
