APRENDER. PRATICAR. EVOLUIR.Começa pelo fluxo observado
Num exemplo fictício de APS, um agente em 192.0.2.10 envia HTTPS para 198.51.100.20:443. O pedido de mudança deve identificar a origem efetiva, o destino, o protocolo e a porta, a interface e o sentido onde a ACL será aplicada. Se existir NAT ou um proxy, confirma os endereços vistos naquele ponto; não deduzas a ordem de processamento a partir do diagrama lógico. Separa acesso ao router de tráfego que atravessa o router. Uma ACL de interface e um controlo de acesso à linha VTY têm pontos de aplicação diferentes. Recolhe uma amostra do fluxo antes de escrever a regra, incluindo a resposta e as dependências necessárias.
Ordem, sequência e regras ocultadas
O exercício permite TCP de 192.0.2.0/24 para um único host na porta 443. Uma negação abrangente na sequência 5 impede que esse fluxo chegue à permissão na sequência 10. Se a negação estiver na sequência 20, o primeiro match continua a decidir. A ausência de match termina no deny implícito da ACL de filtragem usada no exemplo. Uma alteração pode falhar mesmo quando a regra correta existe: pode estar depois de outra que já abrange os mesmos pacotes. Antes de mover uma regra, identifica que outros fluxos mudam de decisão e testa-os. Uma exceção de manutenção deve ter âmbito, responsável e condição de remoção definidos.
Wildcards e posição da porta
Na correspondência de endereços, cada bit zero da wildcard exige igualdade e cada bit um é ignorado. Para a base 192.0.2.0, 0.0.0.255 cobre o último octeto; 0.0.0.0 seleciona o endereço exato. A wildcard 0.0.0.254 é diferente de uma máscara /24: mantém o bit menos significativo e, com esta base, seleciona os valores pares do último octeto. O modelo verifica .0 e .254 como matches, .3 e 192.0.3.2 como não matches. Uma porta depois do destino filtra a porta de destino; uma porta depois da origem filtra a de origem. Não transfiras a regra do pedido para a resposta sem trocar os papéis dos extremos.
Permitir o pedido não cria estado de sessão
No modelo, o pedido TCP usa 51000 como porta de origem e 443 como destino; a resposta usa 443 como origem e 51000 como destino. Aplicar a mesma ACL à resposta não cria uma permissão automática. Uma regra de retorno pode corresponder ao servidor e à porta de origem, mas isso não equivale a um firewall com estado. O keyword established de uma ACL TCP clássica verifica ACK ou RST; não demonstra que o equipamento observou um handshake válido. O modelo aceita um pacote ACK de uma sessão que nunca registou, precisamente porque não mantém sessões. Este resultado ensina o limite do predicado, não uma garantia sobre toda a arquitetura de segurança.
Aceitação com testes positivos e negativos
O excerto original abaixo é para leitura de IOS XE, sem execução num equipamento Cisco. Primeiro constrói e revê a ACL completa; confirma o ponto de aplicação antes de a associar a uma interface. A matriz de aceitação deve incluir o fluxo autorizado, uma origem fora do âmbito, outra porta e outro destino, além do retorno. Compara contadores numa janela conhecida com a evidência da transação; um contador acumulado não prova que o pedido atual passou. Regista falhas de dependências, como resolução de nomes ou autenticação, antes de alargar permissões. O modelo Python da aula seguinte executa estas decisões sem rede, mas não valida hardware, fragmentos, IPv6 ou o comportamento de NAT.
! Original IOS XE reading exercise only; not executed on Cisco hardware.
ip access-list extended APS-HTTPS
10 permit tcp 192.0.2.0 0.0.0.255 host 198.51.100.20 eq 443
20 deny ip any any
! Do not attach this illustrative ACL without the complete flow inventory.
! Inspection example:
show ip access-lists APS-HTTPS
Sequência 5 deny ip any any oculta a permissão HTTPS da sequência 10.
Armadilhas comuns
Confundir ACL de interface com VTY; inverter porta de origem e destino; ignorar a primeira regra; tratar established como inspeção com estado.
Tópicos relacionados: Observação e diagnóstico da rede · Segurança da infraestrutura e acesso ao equipamento
Segue o pacote real, identifica a primeira decisão e testa também o que deve continuar bloqueado.
Referência: IP Access List Overview · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise