Aula 14: ACLs — Listas de Controle de Acesso Padrão e Estendidas

Aula 14: ACLs — Listas de Controle de Acesso Padrão e Estendidas

Por

Bem-vindo à décima quarta aula do curso Cisco IOS — Do Zero ao Avançado. Hoje mergulhamos em um dos pilares da segurança de redes Cisco: as ACLs (Access Control Lists, ou Listas de Controle de Acesso). Se você acompanhou as aulas anteriores, já domina o roteamento estático e dinâmico, configurou VLANs, trunking e sabe como os pacotes trafegam entre sub-redes. Agora chegou o momento de exercer controle granular sobre esse tráfego — decidir exatamente quem passa, quem é bloqueado, qual protocolo é permitido e em qual direção a filtragem ocorre.

As ACLs são, sem exagero, a primeira linha de defesa em milhares de infraestruturas ao redor do mundo. Elas atuam como um firewall stateless embutido no IOS, permitindo que você filtre pacotes com base em endereços IP de origem, destino, portas TCP/UDP, protocolos e muito mais. Dominar ACLs é um divisor de águas na carreira de qualquer profissional de redes: é a diferença entre um administrador que apenas “liga” dispositivos e um engenheiro que realmente protege o perímetro da organização. Em nossos projetos na JRT Technology Solutions, utilizamos ACLs diariamente para segmentar ambientes críticos, isolar servidores de dados sensíveis e implementar políticas de acesso zero-trust na borda da rede.

Nesta aula, você vai aprender a diferença fundamental entre ACLs padrão e estendidas, compreender a lógica da máscara wildcard (um conceito que costuma confundir até profissionais experientes), aplicar ACLs em interfaces com as direções inbound e outbound, e interpretar cada linha de uma access-list como um analista forense lê um log. Vamos construir cenários reais: bloquear uma sub-rede inteira, liberar apenas SSH para um servidor de gerência, filtrar tráfego ICMP e até mesmo proteger o plano de controle do roteador com ACLs aplicadas às linhas VTY.

Ao final desta aula, você será capaz de projetar, implementar e depurar ACLs em qualquer ambiente Cisco IOS. Saberá exatamente quando usar uma ACL numerada ou nomeada, como posicionar a ACL na topologia para máximo desempenho e como evitar os erros mais comuns que derrubam a conectividade de redes inteiras por um simples descuido com a máscara wildcard ou com a regra deny any implícita no final de toda ACL. Prepare seu terminal, abra o Packet Tracer, GNS3 ou seu equipamento físico — porque esta é uma aula 100% prática.

O que você vai aprender nesta aula

  • O conceito fundamental de ACLs e sua função como filtro de pacotes no Cisco IOS
  • A diferença crítica entre ACLs padrão (standard) e ACLs estendidas (extended)
  • A anatomia da máscara wildcard e como calculá-la corretamente para qualquer cenário
  • Como criar e aplicar ACLs numeradas e nomeadas em interfaces de rede
  • O significado das direções inbound e outbound e como escolher a correta
  • Filtragem avançada baseada em portas TCP/UDP, protocolos ICMP e flags estabelecidas
  • Aplicação de ACLs em linhas VTY para proteger acesso remoto ao roteador
  • Interpretação dos comandos show access-lists e show ip interface para verificação
  • Boas práticas de posicionamento, ordenação de regras e documentação de ACLs

Pré-requisitos e Ambiente

Para extrair o máximo desta aula, você precisa ter concluído as aulas anteriores do curso, especialmente a Aula 10 (Roteamento Estático) e a Aula 12 (VLANs e Roteamento Inter-VLAN). É indispensável que você saiba navegar pelos modos do IOS (user EXEC, privileged EXEC, global configuration e interface configuration) e que compreenda o conceito de sub-redes IPv4. Você vai precisar de:

  • Um roteador Cisco com IOS 15.x ou superior (físico ou virtualizado no GNS3/EVE-NG)
  • Opcionalmente, um switch Cisco para conectar hosts de teste
  • Acesso via console ou telnet/SSH ao equipamento
  • Dois ou três hosts Linux ou Windows para gerar tráfego de teste e verificar os bloqueios
  • Ferramentas como ping, traceroute, telnet e nmap instaladas nos hosts

A topologia de referência que utilizaremos ao longo da aula é a seguinte: um roteador R1 com três interfaces — GigabitEthernet0/0 (rede 192.168.10.0/24), GigabitEthernet0/1 (rede 192.168.20.0/24) e GigabitEthernet0/2 (rede 172.16.0.0/28). Na rede 192.168.10.0/24 temos um servidor web (192.168.10.10), um servidor SSH (192.168.10.20) e clientes comuns. Na rede 192.168.20.0/24 temos estações de trabalho que não devem acessar o servidor web. A rede 172.16.0.0/28 é uma DMZ onde reside um servidor DNS (172.16.0.5). Todas as configurações de IP e roteamento já estão funcionais — o foco da aula é exclusivamente a camada de filtragem com ACLs.

Fundamentos das ACLs — O que são e como o IOS as processa

Uma ACL (Access Control List) é uma lista sequencial de instruções que dizem ao roteador “permita este tráfego” ou “bloqueie aquele tráfego”. Cada linha da ACL é chamada de ACE (Access Control Entry). O roteador processa as ACEs na ordem exata em que aparecem — da primeira para a última — e toma uma decisão na primeira correspondência encontrada. Isso significa que a ordem das regras importa, e muito. Se você colocar um permit any na primeira linha, todas as regras abaixo dele serão completamente ignoradas, porque o pacote já terá sido “casado” e a decisão tomada.

Existem dois grandes tipos de ACLs no Cisco IOS: as ACLs padrão (standard), que filtram baseando-se unicamente no endereço IP de origem do pacote, e as ACLs estendidas (extended), que podem filtrar por origem, destino, protocolo, portas TCP/UDP, flags e até tipo de mensagem ICMP. A numeração (ou nome) da ACL indica ao IOS qual tipo você está criando. ACLs padrão numeradas usam os intervalos 1–99 e 1300–1999. ACLs estendidas numeradas usam 100–199 e 2000–2699. Alternativamente, você pode usar ACLs nomeadas, que são mais flexíveis e permitem edição linha a linha — algo impossível nas ACLs numeradas tradicionais.

Um conceito absolutamente central — e que responde por cerca de 40% dos problemas em produção — é a máscara wildcard. Diferente da máscara de sub-rede, onde bits “1” representam a porção de rede e bits “0” a porção de host, na máscara wildcard a lógica é invertida: bits “0” significam “verifique este bit — ele deve corresponder exatamente” e bits “1” significam “ignore este bit — qualquer valor serve”. A máscara wildcard é calculada subtraindo cada octeto da máscara de sub-rede de 255. Por exemplo, uma sub-rede /24 (máscara 255.255.255.0) tem wildcard 0.0.0.255. Uma sub-rede /28 (máscara 255.255.255.240) tem wildcard 0.0.0.15. Na JRT Technology Solutions, sempre recomendamos que os engenheiros pratiquem esse cálculo mentalmente até que se torne automático.

A última regra de toda ACL é a negação implícita (implicit deny). Mesmo que você não a escreva, o IOS insere automaticamente um deny any no final de cada access-list. Isso significa que, se um pacote não corresponder a nenhuma das ACEs de permissão, ele será descartado silenciosamente. Esse comportamento é a base da segurança — mas também a causa de inúmeros incidentes quando o administrador esquece de incluir um permit para tráfego essencial, como protocolos de roteamento ou keepalives.

Tabela 1 — Comparativo entre ACLs Padrão e Estendidas
Característica ACL Padrão ACL Estendida
Intervalos numéricos 1–99 e 1300–1999 100–199 e 2000–2699
Critério de filtragem Apenas IP de origem Origem, destino, protocolo, porta, flags
Posicionamento ideal Próximo ao destino (para evitar bloqueios indevidos) Próximo à origem (para filtrar antes que o tráfego atravesse a rede)
Complexidade Baixa Alta
Uso típico Bloquear uma sub-rede específica de acessar outra Permitir apenas HTTPS para um servidor, bloquear ping, filtrar tráfego por aplicação
Edição de regras Não suportada (numerada); suportada (nomeada) com sequência Não suportada (numerada); suportada (nomeada) com sequência

ACLs Padrão — Mão na massa: criando, aplicando e verificando

Vamos começar com o cenário mais simples e fundamental: uma ACL padrão que bloqueia todo tráfego originado da rede 192.168.20.0/24 com destino à rede 192.168.10.0/24. Note que, por se tratar de uma ACL padrão, só podemos especificar a origem. A decisão de onde aplicar — e em qual direção — é crucial. Como a ACL padrão olha apenas a origem, ela deve ser posicionada o mais próximo possível do destino, para evitar que hosts legítimos de outras redes sejam bloqueados indevidamente. Aplicaremos a ACL na interface GigabitEthernet0/0 (que serve a rede de destino 192.168.10.0/24) na direção outbound.

  1. Acesse o modo privileged EXEC: Digite enable e forneça a senha se necessário.
  2. Entre no modo global configuration: Execute configure terminal.
  3. Crie a ACL padrão numerada 10: O comando é access-list 10 deny 192.168.20.0 0.0.0.255. A máscara wildcard 0.0.0.255 corresponde exatamente à sub-rede /24. Em seguida, adicione access-list 10 permit any para garantir que todo o restante do tráfego seja permitido.
  4. Entre no modo de configuração da interface: interface gigabitEthernet 0/0.
  5. Aplique a ACL na direção outbound: Execute ip access-group 10 out.
  6. Retorne ao privileged EXEC com end e salve a configuração com write memory.
! === Criação da ACL Padrão 10 ===
R1> enable
R1# configure terminal
R1(config)# access-list 10 deny 192.168.20.0 0.0.0.255
R1(config)# access-list 10 permit any
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# description LAN_Servidores_192.168.10.0/24
R1(config-if)# ip access-group 10 out
R1(config-if)# end
R1# write memory

Building configuration...
[OK]
R1#

Vamos detalhar cada linha. access-list 10 deny 192.168.20.0 0.0.0.255 cria a primeira ACE da lista número 10, instruindo o roteador a negar qualquer pacote cujo endereço IP de origem pertença à rede 192.168.20.0/24. A máscara wildcard 0.0.0.255 diz ao IOS: “compare os três primeiros octetos exatamente (192.168.20) e ignore o último octeto (qualquer valor de 0 a 255)”. A segunda linha access-list 10 permit any é explicitamente necessária porque, sem ela, a negação implícita bloquearia todo o tráfego — inclusive o da própria rede 192.168.10.0/24 e de outras redes que porventura existam. O comando ip access-group 10 out aplica a ACL à interface na direção de saída, ou seja, analisa os pacotes que estão prestes a deixar a interface em direção aos hosts da rede 192.168.10.0/24.

Antes de prosseguirmos para as ACLs estendidas, um aviso importante sobre a direção inbound vs outbound: a direção é sempre relativa ao roteador. Inbound significa que o pacote é analisado assim que chega à interface, antes de ser roteado. Outbound significa que o pacote é analisado após a decisão de roteamento, quando está prestes a ser transmitido pela interface de saída. Na ACL padrão acima, se aplicássemos in na interface da rede de origem (GigabitEthernet0/1), o efeito seria o mesmo para o tráfego da 192.168.20.0/24, mas com um risco: qualquer tráfego dessa rede seria bloqueado antes mesmo de chegar à tabela de roteamento, afetando potencialmente outros destinos. Por isso a regra de ouro: ACLs padrão, sempre outbound e próximas ao destino.

ACLs Estendidas — A arte da filtragem granular

Agora elevamos o nível. As ACLs estendidas permitem especificar não apenas a origem, mas também o destino, o protocolo e, nos casos de TCP e UDP, as portas de origem e destino. Isso abre um leque impressionante de possibilidades. Em nossos projetos na JRT Technology Solutions, raramente utilizamos ACLs padrão em ambientes de produção; as estendidas são a norma, pois oferecem precisão cirúrgica. Sem elas, você não consegue, por exemplo, permitir que um único host acesse o servidor web na porta 443 enquanto bloqueia todo o restante do tráfego.

O formato geral de uma ACE estendida é: access-list <número> <permit|deny> <protocolo> <origem> <wildcard-origem> [porta-origem] <destino> <wildcard-destino> [porta-destino] [opções]. Vamos construir três cenários progressivos, do mais simples ao mais complexo, sempre na mesma topologia.

Cenário 1: Permitir que o host 192.168.10.20 (servidor SSH) receba conexões SSH (porta 22 TCP) vindas de qualquer lugar, mas bloquear qualquer outro tráfego destinado a ele. Queremos também permitir que o servidor web 192.168.10.10 receba apenas HTTPS (porta 443 TCP). Criaremos a ACL estendida 110 e a aplicaremos na interface GigabitEthernet0/0 com direção inbound.

! === ACL Estendida 110 — Filtragem por serviço ===
R1# configure terminal
R1(config)# access-list 110 permit tcp any host 192.168.10.20 eq 22
R1(config)# access-list 110 permit tcp any host 192.168.10.10 eq 443
R1(config)# access-list 110 deny ip any host 192.168.10.20
R1(config)# access-list 110 deny ip any host 192.168.10.10
R1(config)# access-list 110 permit ip any any
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# no ip access-group 10 out
R1(config-if)# ip access-group 110 in
R1(config-if)# end
R1# write memory

Dissecando cada ACE: access-list 110 permit tcp any host 192.168.10.20 eq 22 — o número 110 indica ACL estendida; permit tcp porque SSH opera sobre TCP; any representa qualquer origem (0.0.0.0 255.255.255.255); host 192.168.10.20 é uma abreviação para 192.168.10.20 0.0.0.0 (máscara wildcard que casa exatamente com esse IP); eq 22 especifica a porta de destino igual a 22. A segunda linha faz o mesmo para HTTPS na porta 443. As linhas de deny ip any host bloqueiam qualquer outro tráfego IP (TCP, UDP, ICMP, etc.) destinado aos servidores. Finalmente, permit ip any any garante que o restante do tráfego flua normalmente. Note que removemos a ACL 10 anterior com no ip access-group 10 out — uma interface só pode ter uma ACL por direção e por protocolo.

Cenário 2: Filtragem de ICMP. Queremos permitir apenas echo-reply (respostas de ping) da rede 192.168.10.0/24 para a rede 192.168.20.0/24, mas bloquear echo-request (solicitações de ping) originadas da 192.168.20.0/24. Isso impede que os usuários da rede 192.168.20.0/24 façam ping nos servidores, mas permite que vejam as respostas caso os servidores os pingem.

! === ACL Estendida 120 — Controle de ICMP ===
R1# configure terminal
R1(config)# access-list 120 deny icmp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 echo
R1(config)# access-list 120 permit icmp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 echo-reply
R1(config)# access-list 120 permit ip any any
R1(config)# interface gigabitEthernet 0/1
R1(config-if)# ip access-group 120 in
R1(config-if)# end

O argumento echo após o destino refere-se ao tipo ICMP 8 (echo-request). O echo-reply é o tipo ICMP 0. O IOS aceita tanto os nomes quanto os números. Aplicamos a ACL na interface da rede de origem (GigabitEthernet0/1) na direção in, bloqueando os echo-requests assim que entram no roteador — seguindo a recomendação de posicionar ACLs estendidas próximo à origem. A última linha com permit ip any any é crucial; sem ela, até o tráfego web seria bloqueado.

ACLs Nomeadas — Flexibilidade e edição em tempo real

ACLs numeradas têm uma limitação severa: você não pode remover ou inserir uma ACE no meio da lista sem apagar a ACL inteira e recriá-la. Em ambientes de produção, isso é inviável — imagine derrubar centenas de regras para corrigir uma linha. As ACLs nomeadas resolvem esse problema permitindo a edição por número de sequência. Vamos criar uma ACL nomeada que consolida nossas políticas.

! === ACL Nomeada "FILTRO_SERVIDORES" ===
R1# configure terminal
R1(config)# ip access-list extended FILTRO_SERVIDORES
R1(config-ext-nacl)# 10 permit tcp any host 192.168.10.20 eq 22
R1(config-ext-nacl)# 20 permit tcp any host 192.168.10.10 eq 443
R1(config-ext-nacl)# 30 deny ip any host 192.168.10.20
R1(config-ext-nacl)# 40 deny ip any host 192.168.10.10
R1(config-ext-nacl)# 50 permit ip any any
R1(config-ext-nacl)# exit
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# ip access-group FILTRO_SERVIDORES in
R1(config-if)# end

Repare no prompt (config-ext-nacl) — é o submode de configuração de ACL nomeada estendida. Os números 10, 20, 30, 40, 50 são sequências que determinam a ordem de processamento. Se posteriormente você precisar inserir uma regra entre a 20 e a 30, basta usar 25 permit tcp any host 192.168.10.30 eq 80 e a nova ACE será inserida na posição correta. Para remover uma ACE específica, use no 30 (remove a sequência 30). Isso é impossível com ACLs numeradas, onde o no access-list 110 apaga a lista inteira.

Tabela 2 — Operadores de Porta em ACLs Estendidas
Operador Significado Exemplo Equivalente numérico
eq Igual a (exatamente esta porta) eq 22 Porta 22 apenas
gt Maior que (greater than) gt 1023 Portas 1024–65535
lt Menor que (less than) lt 1024 Portas 0–1023
neq Diferente de (not equal) neq 80 Todas exceto a 80
range Intervalo inclusivo range 20 21 Portas 20 e 21 (FTP)

ACLs em Linhas VTY — Protegendo o acesso ao roteador

Um dos usos mais críticos das ACLs é a proteção do plano de controle do próprio roteador. As linhas VTY (Virtual Teletype) controlam acessos via Telnet e SSH. Sem uma ACL aplicada às VTY, qualquer host que consiga alcançar o roteador pode tentar login — um vetor de ataque gravíssimo. Vamos configurar uma ACL que permita SSH apenas a partir do host de gerência 192.168.10.100 e negue tudo o mais.

! === ACL para Proteção das Linhas VTY ===
R1# configure terminal
R1(config)# ip access-list standard GERENCIA_VTY
R1(config-std-nacl)# permit host 192.168.10.100
R1(config-std-nacl)# deny any
R1(config-std-nacl)# exit
R1(config)# line vty 0 15
R1(config-line)# access-class GERENCIA_VTY in
R1(config-line)# transport input ssh
R1(config-line)# login local
R1(config-line)# end
R1# write memory

O comando access-class GERENCIA_VTY in aplica a ACL padrão às linhas VTY, restringindo as conexões de entrada. Diferente de interfaces, onde usamos ip access-group, nas linhas VTY o comando é access-class. A ACL é do tipo padrão porque nas VTY só nos interessa a origem da conexão. A diretiva transport input ssh garante que apenas SSH seja aceito (bloqueando Telnet, que transmite senhas em texto claro). login local força o uso da base de usuários local do roteador. Em nossos projetos na JRT Technology Solutions, combinamos essa ACL com AAA via TACACS+ para um controle ainda mais rigoroso.

Verificando a Instalação / Testando a Configuração

Após aplicar qualquer ACL, a verificação é obrigatória. O IOS oferece comandos específicos para visualizar o conteúdo das ACLs, contabilizar os matches (acertos) de cada ACE e inspecionar quais ACLs estão aplicadas em cada interface. Acompanhe os comandos e as saídas esperadas.

! === Comandos de Verificação ===
R1# show access-lists
R1# show access-lists FILTRO_SERVIDORES
R1# show ip interface gigabitEthernet 0/0 | include access list
R1# show ip interface gigabitEthernet 0/1 | include access list
R1# show running-config | section access-list
R1# show running-config | section line vty

R1# show access-lists
Standard IP access list GERENCIA_VTY
    10 permit 192.168.10.100 (15 matches)
    20 deny any (142 matches)
Extended IP access list FILTRO_SERVIDORES
    10 permit tcp any host 192.168.10.20 eq 22 (8 matches)
    20 permit tcp any host 192.168.10.10 eq 443 (52 matches)
    30 deny ip any host 192.168.10.20 (3 matches)
    40 deny ip any host 192.168.10.10 (12 matches)
    50 permit ip any any (947 matches)
Extended IP access list 120
    10 deny icmp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 echo (27 matches)
    20 permit icmp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 echo-reply (19 matches)
    30 permit ip any any (1341 matches)

R1# show ip interface gigabitEthernet 0/0 | include access list
  Outgoing access list is not set
  Inbound  access list is FILTRO_SERVIDORES

R1# show ip interface gigabitEthernet 0/1 | include access list
  Outgoing access list is not set
  Inbound  access list is 120

O campo matches é um tesouro para troubleshooting. Ele mostra quantos pacotes foram avaliados e casaram com cada ACE. Se uma regra que você esperava ver funcionando tem zero matches, algo está errado — ou o tráfego não está chegando, ou uma regra anterior já o capturou. A saída do show ip interface revela exatamente qual ACL está aplicada e em qual direção. Note que nossa ACL 10 original foi removida, por isso Outgoing access list is not set.

Para testar na prática, recomendamos este roteiro de validação:

  1. Do host 192.168.20.50, tente ping 192.168.10.10. Deve falhar (bloqueado pela ACL 120, echo).
  2. Do host 192.168.10.10, execute ping 192.168.20.50. Deve ter sucesso, e a resposta (echo-reply) será visível. Verifique os matches na ACL 120 — a linha 20 deve incrementar.
  3. De um host qualquer (exceto 192.168.10.100), tente ssh -l admin 192.168.10.1 (assumindo que 192.168.10.1 é o IP da interface do roteador). Deve falhar com “Connection refused” ou timeout. A ACL GERENCIA_VTY bloqueia.
  4. Do host 192.168.10.100, execute ssh -l admin 192.168.10.1. Deve apresentar o prompt de senha. Sucesso.
  5. Do host 192.168.10.10 (servidor web), acesse curl -k https://192.168.10.10 localmente. Tráfego loopback não passa pela ACL, então funciona. De um host externo, acesse http://192.168.10.10 (porta 80). Deve falhar — apenas 443 está liberada.

Erros Comuns e Como Resolver

  • Erro 1: Regra correta, mas ordem errada — o tráfego é bloqueado pela negação implícita ou por uma ACE anterior.
    Sintoma: Pacotes esperados não passam, mesmo com uma ACE permit na lista.
    Causa: Uma ACE deny anterior capturou o pacote antes que ele chegasse à regra de permissão. Exemplo: deny ip any any na linha 10 e permit tcp any host 192.168.10.10 eq 80 na linha 20 — a segunda nunca será alcançada.
    Solução: Use show access-lists para ver a ordem das sequências. Reorganize as ACEs colocando as permissões específicas antes das negações genéricas. Se for ACL nomeada, utilize ip access-list resequence para renumerar com intervalos maiores (ex: passo 20) e reordenar manualmente.
  • Erro 2: Máscara wildcard incorreta — a sub-rede não é casada como esperado.
    Sintoma: ACL não bloqueia (ou bloqueia demais) hosts de uma sub-rede.
    Causa: Confusão entre máscara de sub-rede e wildcard. Usar 0.0.0.255 para uma /24 está correto, mas usar 0.0.0.7 para uma /29 (quando o correto seria 0.0.0.7)… na verdade, wildcard de /29 é 255.255.255.248 -> wildcard = 0.0.0.7. O erro mais comum é usar 0.0.0.248 ou 0.0.0.255 para uma /29, capturando hosts a mais ou a menos.
    Solução: Sempre confira: wildcard = 255.255.255.255 – máscara de sub-rede. Para /29 (255.255.255.248), wildcard = 0.0.0.7. Use calculadoras online até internalizar. Lembre-se: na wildcard, 0 = “deve casar”, 1 = “ignore”.
  • Erro 3: Esquecer o “permit any” (negação implícita derruba tudo).
    Sintoma: Após aplicar a ACL, todo o tráfego para — inclusive protocolos de roteamento como OSPF ou EIGRP.
    Causa: A ACL não tem uma ACE permit ip any any no final. A negação implícita bloqueia inclusive os hellos dos protocolos de roteamento, derrubando adjacências.
    Solução: Sempre termine ACLs aplicadas a interfaces de trânsito com permit ip any any, a menos que a política exija bloqueio total. Se você usa protocolos de roteamento dinâmico, adicione ACEs explícitas para permiti-los: permit ospf any any (protocolo 89) ou permit eigrp any any (protocolo 88) antes de negar qualquer coisa.
  • Erro 4: Aplicar ACL na direção errada (inbound vs outbound).
    Sintoma: A ACL parece não surtir efeito, ou bloqueia tráfego que deveria ser permitido.
    Causa: O administrador aplicou a ACL in na interface de destino, mas o tráfego está entrando por outra interface e saindo pela interface onde a ACL está out (ou vice-versa). O processamento inbound ocorre antes do roteamento; outbound, depois.
    Solução: Desenhe o fluxo do pacote no papel. Se a origem está conectada à interface G0/1 e o destino à G0/0, uma ACL in em G0/1 analisa o pacote antes de rotear; uma ACL out em G0/0 analisa depois de roteado. Ambas funcionam, mas os critérios de origem/destino na ACL não mudam — a ACL sempre avalia o pacote original (origem real, destino real). O problema geralmente está em achar que in na interface de destino inverte origem e destino — não inverte.
  • Erro 5: Não remover ACLs antigas antes de aplicar novas.
    Sintoma: Comportamento inesperado, regras conflitantes.
    Causa: Uma interface pode ter uma ACL inbound e outra outbound simultaneamente. Se você aplicou uma ACL numerada antiga e depois aplica uma nomeada na mesma direção, a antiga é substituída. Mas se eram direções diferentes (uma in, outra out), ambas coexistem e interagem de forma difícil de depurar.
    Solução: Sempre execute show ip interface <int> | include access list para verificar quais ACLs estão aplicadas e em quais direções. Remova explicitamente com no ip access-group <nome> <in|out> antes de aplicar novas.

Boas Práticas e Dicas Avançadas

Ao longo de centenas de implantações na JRT Technology Solutions, consolidamos um conjunto de práticas que evitam dores de cabeça e garantem que as ACLs sejam sustentáveis a longo prazo. A primeira e mais importante: documente cada ACE. Embora o IOS não tenha um campo de comentário nativo nas ACLs numeradas, você pode usar remark nas ACLs nomeadas. Exemplo: remark Permitir SSH para servidor de gerência seguido da ACE correspondente. Isso transforma uma sopa de números IP em uma política legível por qualquer pessoa da equipe.

Segunda prática: utilize intervalos de sequência generosos. Ao criar ACLs nomeadas, numere as ACEs com passos de 20 ou 50 (10, 30, 50, 70… ou 100, 200, 300…). Isso deixa espaço para inserir regras intermediárias sem precisar reescrever toda a lista. Em equipamentos com software anterior ao IOS 12.4(20)T, ACLs nomeadas também não permitiam inserção — mas qualquer versão moderna suporta. Se você herdar um ambiente com ACLs numeradas e precisar editá-las, copie o show running-config | section access-list para um editor de texto, faça as alterações, remova a ACL antiga (no access-list <número>) e recrie-a já com as correções. Faça isso em janela de manutenção.

Terceira: cuidado com o tráfego de retorno. ACLs estendidas no IOS são stateless — cada pacote é avaliado independentemente. Se você permite tráfego TCP de A para B na porta 80, o tráfego de retorno (B para A, porta de origem aleatória) NÃO está automaticamente permitido, a menos que sua ACL tenha uma ACE que o cubra ou que você utilize o recurso de established. A palavra-chave established em uma ACE TCP verifica se o pacote tem os flags ACK ou RST setados, indicando que pertence a uma conexão já estabelecida. Exemplo: access-list 130 permit tcp any 192.168.10.0 0.0.0.255 established permite apenas respostas, não novas conexões. Use com sabedoria.

Quarta prática: teste em ambiente controlado antes da produção. Um erro de ACL pode isolar você do equipamento remotamente — o famoso “trancar-se do lado de fora”. Ao aplicar ACLs em linhas VTY, sempre mantenha uma sessão de console aberta como backup. Se a ACL bloquear seu IP, você precisará do console para reverter. Em nossos projetos, configuramos um reload in 10 antes de aplicar ACLs críticas remotamente; se algo der errado e perdermos conectividade, o roteador reinicia e volta à configuração anterior (desde que você não tenha salvo). Após confirmar o funcionamento, execute reload cancel e write memory.

Quinta: ACLs e fragmentação IP. Por padrão, o IOS avalia apenas o fragmento inicial (que contém os cabeçalhos de camada 4) contra ACLs estendidas que especificam portas. Os fragmentos subsequentes são permitidos automaticamente, pois não carregam informação de porta. Isso pode ser uma brecha de segurança. Para mitigar, versões modernas do IOS suportam ip access-list logging denied fragments ou regras explícitas com fragments. Se seu ambiente lida com tráfego fragmentado (VPNs, NFS, alguns túneis), estude esse tópico adicional.

Resumo da Aula 14

Nesta aula densa e 100% prática, você dominou as ACLs — listas de controle de acesso — no Cisco IOS. Aprendemos que as ACLs são filtros sequenciais processados na primeira correspondência, com uma negação implícita ao final. Exploramos as ACLs padrão (intervalos 1–99, 1300–1999), que filtram apenas por IP de origem e devem ser posicionadas próximas ao destino, e as ACLs estendidas (100–199, 2000–2699), que operam com granularidade de origem, destino, protocolo e portas, sendo ideais para aplicação próxima à origem. Desvendamos a máscara wildcard — a inversão da máscara de sub-rede — e praticamos o cálculo para sub-redes /24, /28 e /29.

Configuramos cenários reais: bloqueio de sub-redes inteiras com ACL padrão, filtragem de serviços (SSH, HTTPS) com ACL estendida, controle de ICMP por tipo de mensagem, e proteção das linhas VTY com access-class. Implementamos ACLs nomeadas e compreendemos suas vantagens de edição por sequência. Verificamos cada configuração com show access-lists e show ip interface, interpretando os contadores de matches para diagnóstico. Cobrimos os cinco erros mais comuns — ordem incorreta das ACEs, wildcard errada, esquecimento do permit any, direção inbound/outbound equivocada e conflitos entre ACLs antigas e novas — com soluções práticas para cada um.

Tabela 3 — Referência Rápida de Comandos de ACL
Comando Modo Descrição
access-list <1-99> permit|deny <origem> <wildcard> Global config Cria ACE de ACL padrão numerada
access-list <100-199> permit|deny <protocolo> <orig> <wc> <dest> <wc> [eq <porta>] Global config Cria ACE de ACL estendida numerada
ip access-list standard|extended <nome> Global config Cria ACL nomeada e entra no submode apropriado
ip access-group <acl> in|out Interface config Aplica ACL a uma interface na direção especificada
access-class <acl> in|out Line config (VTY) Aplica ACL a linhas VTY
show access-lists [<nome|número>] Privileged EXEC Exibe todas as ACLs e contadores de matches
show ip interface <int> | include access list Privileged EXEC Mostra ACLs aplicadas à interface
no access-list <número> Global config Remove ACL numerada inteira

Na Aula 15 — Network Address Translation (NAT) no Cisco IOS, vamos conectar tudo o que aprendemos sobre roteamento e ACLs ao mundo real, configurando NAT estático, dinâmico e PAT (sobrecarga) para prover acesso à Internet a redes privadas. Veremos como as ACLs desempenham papel fundamental na definição do tráfego “interessante” que dispara traduções NAT. Prepare-se: será a aula que transforma seu laboratório em uma rede verdadeiramente conectada ao mundo externo.

Se você deseja aprofundar seus conhecimentos com treinamentos hands-on, implementações guiadas ou suporte especializado em Cisco IOS, a JRT Technology Solutions está à disposição. Nossos especialistas utilizam diariamente as técnicas apresentadas nesta aula para projetar e manter infraestruturas seguras e de alto desempenho para clientes de todos os portes. Deixe seu comentário abaixo com dúvidas ou cenários que gostaria de ver explorados — sua participação enriquece o curso e ajuda a comunidade de profissionais de TI a crescer.

Quer aprender na prática com especialistas?

A JRT Technology Solutions oferece treinamentos e implementação de Cisco IOS para equipes corporativas.



Falar no WhatsApp

Deixe um comentário