{"id":1159,"date":"2026-06-18T18:03:54","date_gmt":"2026-06-18T21:03:54","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/06\/18\/aula-14-acls-listas-de-controle-de-acesso-padrao-e-estendida\/"},"modified":"2026-06-18T18:03:54","modified_gmt":"2026-06-18T21:03:54","slug":"aula-14-acls-listas-de-controle-de-acesso-padrao-e-estendida","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/06\/18\/aula-14-acls-listas-de-controle-de-acesso-padrao-e-estendida\/","title":{"rendered":"Aula 14: ACLs \u2014 Listas de Controle de Acesso Padr\u00e3o e Estendidas"},"content":{"rendered":"

Bem-vindo \u00e0 d\u00e9cima quarta aula do curso Cisco IOS \u2014 Do Zero ao Avan\u00e7ado<\/strong>. Hoje mergulhamos em um dos pilares da seguran\u00e7a de redes Cisco: as ACLs<\/strong> (Access Control Lists, ou Listas de Controle de Acesso). Se voc\u00ea acompanhou as aulas anteriores, j\u00e1 domina o roteamento est\u00e1tico e din\u00e2mico, configurou VLANs, trunking e sabe como os pacotes trafegam entre sub-redes. Agora chegou o momento de exercer controle granular sobre esse tr\u00e1fego \u2014 decidir exatamente quem passa, quem \u00e9 bloqueado, qual protocolo \u00e9 permitido e em qual dire\u00e7\u00e3o a filtragem ocorre.<\/p>\n

As ACLs s\u00e3o, 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\u00ea filtre pacotes com base em endere\u00e7os IP de origem, destino, portas TCP\/UDP, protocolos e muito mais. Dominar ACLs \u00e9 um divisor de \u00e1guas na carreira de qualquer profissional de redes: \u00e9 a diferen\u00e7a entre um administrador que apenas “liga” dispositivos e um engenheiro que realmente protege o per\u00edmetro da organiza\u00e7\u00e3o. Em nossos projetos na JRT Technology Solutions, utilizamos ACLs diariamente para segmentar ambientes cr\u00edticos, isolar servidores de dados sens\u00edveis e implementar pol\u00edticas de acesso zero-trust na borda da rede.<\/p>\n

Nesta aula, voc\u00ea vai aprender a diferen\u00e7a fundamental entre ACLs padr\u00e3o<\/strong> e estendidas<\/strong>, compreender a l\u00f3gica da m\u00e1scara wildcard<\/strong> (um conceito que costuma confundir at\u00e9 profissionais experientes), aplicar ACLs em interfaces com as dire\u00e7\u00f5es inbound<\/strong> e outbound<\/strong>, e interpretar cada linha de uma access-list como um analista forense l\u00ea um log. Vamos construir cen\u00e1rios reais: bloquear uma sub-rede inteira, liberar apenas SSH para um servidor de ger\u00eancia, filtrar tr\u00e1fego ICMP e at\u00e9 mesmo proteger o plano de controle do roteador com ACLs aplicadas \u00e0s linhas VTY.<\/p>\n

Ao final desta aula, voc\u00ea ser\u00e1 capaz de projetar, implementar e depurar ACLs em qualquer ambiente Cisco IOS. Saber\u00e1 exatamente quando usar uma ACL numerada ou nomeada, como posicionar a ACL na topologia para m\u00e1ximo desempenho e como evitar os erros mais comuns que derrubam a conectividade de redes inteiras por um simples descuido com a m\u00e1scara wildcard ou com a regra deny any<\/strong> impl\u00edcita no final de toda ACL. Prepare seu terminal, abra o Packet Tracer, GNS3 ou seu equipamento f\u00edsico \u2014 porque esta \u00e9 uma aula 100% pr\u00e1tica.<\/p>\n

O que voc\u00ea vai aprender nesta aula<\/h3>\n
    \n
  • O conceito fundamental de ACLs<\/strong> e sua fun\u00e7\u00e3o como filtro de pacotes no Cisco IOS<\/li>\n
  • A diferen\u00e7a cr\u00edtica entre ACLs padr\u00e3o<\/strong> (standard) e ACLs estendidas<\/strong> (extended)<\/li>\n
  • A anatomia da m\u00e1scara wildcard<\/strong> e como calcul\u00e1-la corretamente para qualquer cen\u00e1rio<\/li>\n
  • Como criar e aplicar ACLs numeradas e nomeadas em interfaces de rede<\/li>\n
  • O significado das dire\u00e7\u00f5es inbound<\/strong> e outbound<\/strong> e como escolher a correta<\/li>\n
  • Filtragem avan\u00e7ada baseada em portas TCP\/UDP, protocolos ICMP e flags estabelecidas<\/li>\n
  • Aplica\u00e7\u00e3o de ACLs em linhas VTY para proteger acesso remoto ao roteador<\/li>\n
  • Interpreta\u00e7\u00e3o dos comandos show access-lists<\/strong> e show ip interface<\/strong> para verifica\u00e7\u00e3o<\/li>\n
  • Boas pr\u00e1ticas de posicionamento, ordena\u00e7\u00e3o de regras e documenta\u00e7\u00e3o de ACLs<\/li>\n<\/ul>\n

    Pr\u00e9-requisitos e Ambiente<\/h3>\n

    Para extrair o m\u00e1ximo desta aula, voc\u00ea precisa ter conclu\u00eddo as aulas anteriores do curso, especialmente a Aula 10 (Roteamento Est\u00e1tico)<\/strong> e a Aula 12 (VLANs e Roteamento Inter-VLAN)<\/strong>. \u00c9 indispens\u00e1vel que voc\u00ea saiba navegar pelos modos do IOS (user EXEC<\/strong>, privileged EXEC<\/strong>, global configuration<\/strong> e interface configuration<\/strong>) e que compreenda o conceito de sub-redes IPv4. Voc\u00ea vai precisar de:<\/p>\n

      \n
    • Um roteador Cisco com IOS 15.x ou superior (f\u00edsico ou virtualizado no GNS3\/EVE-NG)<\/li>\n
    • Opcionalmente, um switch Cisco para conectar hosts de teste<\/li>\n
    • Acesso via console ou telnet\/SSH<\/strong> ao equipamento<\/li>\n
    • Dois ou tr\u00eas hosts Linux ou Windows para gerar tr\u00e1fego de teste e verificar os bloqueios<\/li>\n
    • Ferramentas como ping<\/strong>, traceroute<\/strong>, telnet<\/strong> e nmap<\/strong> instaladas nos hosts<\/li>\n<\/ul>\n

      A topologia de refer\u00eancia que utilizaremos ao longo da aula \u00e9 a seguinte: um roteador R1<\/strong> com tr\u00eas interfaces \u2014 GigabitEthernet0\/0<\/strong> (rede 192.168.10.0\/24), GigabitEthernet0\/1<\/strong> (rede 192.168.20.0\/24) e GigabitEthernet0\/2<\/strong> (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\u00e7\u00f5es de trabalho que n\u00e3o devem acessar o servidor web. A rede 172.16.0.0\/28 \u00e9 uma DMZ onde reside um servidor DNS (172.16.0.5). Todas as configura\u00e7\u00f5es de IP e roteamento j\u00e1 est\u00e3o funcionais \u2014 o foco da aula \u00e9 exclusivamente a camada de filtragem com ACLs.<\/p>\n

      Fundamentos das ACLs \u2014 O que s\u00e3o e como o IOS as processa<\/h3>\n

      Uma ACL<\/strong> (Access Control List) \u00e9 uma lista sequencial de instru\u00e7\u00f5es que dizem ao roteador “permita este tr\u00e1fego” ou “bloqueie aquele tr\u00e1fego”. Cada linha da ACL \u00e9 chamada de ACE<\/strong> (Access Control Entry). O roteador processa as ACEs na ordem exata em que aparecem \u2014 da primeira para a \u00faltima \u2014 e toma uma decis\u00e3o na primeira correspond\u00eancia encontrada. Isso significa que a ordem das regras importa, e muito<\/strong>. Se voc\u00ea colocar um permit any<\/strong> na primeira linha, todas as regras abaixo dele ser\u00e3o completamente ignoradas, porque o pacote j\u00e1 ter\u00e1 sido “casado” e a decis\u00e3o tomada.<\/p>\n

      Existem dois grandes tipos de ACLs no Cisco IOS: as ACLs padr\u00e3o<\/strong> (standard), que filtram baseando-se unicamente no endere\u00e7o IP de origem do pacote, e as ACLs estendidas<\/strong> (extended), que podem filtrar por origem, destino, protocolo, portas TCP\/UDP, flags e at\u00e9 tipo de mensagem ICMP. A numera\u00e7\u00e3o (ou nome) da ACL indica ao IOS qual tipo voc\u00ea est\u00e1 criando. ACLs padr\u00e3o numeradas usam os intervalos 1\u201399<\/strong> e 1300\u20131999<\/strong>. ACLs estendidas numeradas usam 100\u2013199<\/strong> e 2000\u20132699<\/strong>. Alternativamente, voc\u00ea pode usar ACLs nomeadas<\/strong>, que s\u00e3o mais flex\u00edveis e permitem edi\u00e7\u00e3o linha a linha \u2014 algo imposs\u00edvel nas ACLs numeradas tradicionais.<\/p>\n

      Um conceito absolutamente central \u2014 e que responde por cerca de 40% dos problemas em produ\u00e7\u00e3o \u2014 \u00e9 a m\u00e1scara wildcard<\/strong>. Diferente da m\u00e1scara de sub-rede, onde bits “1” representam a por\u00e7\u00e3o de rede e bits “0” a por\u00e7\u00e3o de host, na m\u00e1scara wildcard a l\u00f3gica \u00e9 invertida: bits “0” significam “verifique este bit \u2014 ele deve corresponder exatamente” e bits “1” significam “ignore este bit \u2014 qualquer valor serve”. A m\u00e1scara wildcard \u00e9 calculada subtraindo cada octeto da m\u00e1scara de sub-rede de 255. Por exemplo, uma sub-rede \/24 (m\u00e1scara 255.255.255.0) tem wildcard 0.0.0.255. Uma sub-rede \/28 (m\u00e1scara 255.255.255.240) tem wildcard 0.0.0.15. Na JRT Technology Solutions, sempre recomendamos que os engenheiros pratiquem esse c\u00e1lculo mentalmente at\u00e9 que se torne autom\u00e1tico.<\/p>\n

      A \u00faltima regra de toda ACL \u00e9 a nega\u00e7\u00e3o impl\u00edcita<\/strong> (implicit deny). Mesmo que voc\u00ea n\u00e3o a escreva, o IOS insere automaticamente um deny any<\/strong> no final de cada access-list. Isso significa que, se um pacote n\u00e3o corresponder a nenhuma das ACEs de permiss\u00e3o, ele ser\u00e1 descartado silenciosamente. Esse comportamento \u00e9 a base da seguran\u00e7a \u2014 mas tamb\u00e9m a causa de in\u00fameros incidentes quando o administrador esquece de incluir um permit<\/strong> para tr\u00e1fego essencial, como protocolos de roteamento ou keepalives.<\/p>\n\n\n\n\n\n\n\n\n\n\n
      Tabela 1 \u2014 Comparativo entre ACLs Padr\u00e3o e Estendidas<\/caption>\n
      Caracter\u00edstica<\/th>\nACL Padr\u00e3o<\/th>\nACL Estendida<\/th>\n<\/tr>\n<\/thead>\n
      Intervalos num\u00e9ricos<\/td>\n1\u201399 e 1300\u20131999<\/td>\n100\u2013199 e 2000\u20132699<\/td>\n<\/tr>\n
      Crit\u00e9rio de filtragem<\/td>\nApenas IP de origem<\/td>\nOrigem, destino, protocolo, porta, flags<\/td>\n<\/tr>\n
      Posicionamento ideal<\/td>\nPr\u00f3ximo ao destino (para evitar bloqueios indevidos)<\/td>\nPr\u00f3ximo \u00e0 origem (para filtrar antes que o tr\u00e1fego atravesse a rede)<\/td>\n<\/tr>\n
      Complexidade<\/td>\nBaixa<\/td>\nAlta<\/td>\n<\/tr>\n
      Uso t\u00edpico<\/td>\nBloquear uma sub-rede espec\u00edfica de acessar outra<\/td>\nPermitir apenas HTTPS para um servidor, bloquear ping, filtrar tr\u00e1fego por aplica\u00e7\u00e3o<\/td>\n<\/tr>\n
      Edi\u00e7\u00e3o de regras<\/td>\nN\u00e3o suportada (numerada); suportada (nomeada) com sequ\u00eancia<\/td>\nN\u00e3o suportada (numerada); suportada (nomeada) com sequ\u00eancia<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      ACLs Padr\u00e3o \u2014 M\u00e3o na massa: criando, aplicando e verificando<\/h3>\n

      Vamos come\u00e7ar com o cen\u00e1rio mais simples e fundamental: uma ACL padr\u00e3o<\/strong> que bloqueia todo tr\u00e1fego originado da rede 192.168.20.0\/24 com destino \u00e0 rede 192.168.10.0\/24. Note que, por se tratar de uma ACL padr\u00e3o, s\u00f3 podemos especificar a origem. A decis\u00e3o de onde aplicar \u2014 e em qual dire\u00e7\u00e3o \u2014 \u00e9 crucial. Como a ACL padr\u00e3o olha apenas a origem, ela deve ser posicionada o mais pr\u00f3ximo poss\u00edvel do destino, para evitar que hosts leg\u00edtimos de outras redes sejam bloqueados indevidamente. Aplicaremos a ACL na interface GigabitEthernet0\/0<\/strong> (que serve a rede de destino 192.168.10.0\/24) na dire\u00e7\u00e3o outbound<\/strong>.<\/p>\n

        \n
      1. Acesse o modo privileged EXEC:<\/strong> Digite enable<\/strong> e forne\u00e7a a senha se necess\u00e1rio.<\/li>\n
      2. Entre no modo global configuration:<\/strong> Execute configure terminal<\/strong>.<\/li>\n
      3. Crie a ACL padr\u00e3o numerada 10:<\/strong> O comando \u00e9 access-list 10 deny 192.168.20.0 0.0.0.255<\/strong>. A m\u00e1scara wildcard 0.0.0.255 corresponde exatamente \u00e0 sub-rede \/24. Em seguida, adicione access-list 10 permit any<\/strong> para garantir que todo o restante do tr\u00e1fego seja permitido.<\/li>\n
      4. Entre no modo de configura\u00e7\u00e3o da interface:<\/strong> interface gigabitEthernet 0\/0<\/strong>.<\/li>\n
      5. Aplique a ACL na dire\u00e7\u00e3o outbound:<\/strong> Execute ip access-group 10 out<\/strong>.<\/li>\n
      6. Retorne ao privileged EXEC<\/strong> com end<\/strong> e salve a configura\u00e7\u00e3o com write memory<\/strong>.<\/li>\n<\/ol>\n
        ! === Cria\u00e7\u00e3o da ACL Padr\u00e3o 10 ===\nR1> enable\nR1# configure terminal\nR1(config)# access-list 10 deny 192.168.20.0 0.0.0.255\nR1(config)# access-list 10 permit any\nR1(config)# interface gigabitEthernet 0\/0\nR1(config-if)# description LAN_Servidores_192.168.10.0\/24\nR1(config-if)# ip access-group 10 out\nR1(config-if)# end\nR1# write memory\n<\/code><\/pre>\n
        Building configuration...\n[OK]\nR1#\n<\/code><\/pre>\n
        Vamos detalhar cada linha. access-list 10 deny 192.168.20.0 0.0.0.255<\/strong> cria a primeira ACE da lista n\u00famero 10, instruindo o roteador a negar qualquer pacote cujo endere\u00e7o IP de origem perten\u00e7a \u00e0 rede 192.168.20.0\/24. A m\u00e1scara wildcard 0.0.0.255<\/strong> diz ao IOS: “compare os tr\u00eas primeiros octetos exatamente (192.168.20) e ignore o \u00faltimo octeto (qualquer valor de 0 a 255)”. A segunda linha access-list 10 permit any<\/strong> \u00e9 explicitamente necess\u00e1ria porque, sem ela, a nega\u00e7\u00e3o impl\u00edcita bloquearia todo o tr\u00e1fego \u2014 inclusive o da pr\u00f3pria rede 192.168.10.0\/24 e de outras redes que porventura existam. O comando ip access-group 10 out<\/strong> aplica a ACL \u00e0 interface na dire\u00e7\u00e3o de sa\u00edda, ou seja, analisa os pacotes que est\u00e3o prestes a deixar a interface em dire\u00e7\u00e3o aos hosts da rede 192.168.10.0\/24.<\/p>\n
        Antes de prosseguirmos para as ACLs estendidas, um aviso importante sobre a dire\u00e7\u00e3o inbound vs outbound<\/strong>: a dire\u00e7\u00e3o \u00e9 sempre relativa ao roteador. Inbound<\/strong> significa que o pacote \u00e9 analisado assim que chega \u00e0 interface, antes de ser roteado. Outbound<\/strong> significa que o pacote \u00e9 analisado ap\u00f3s a decis\u00e3o de roteamento, quando est\u00e1 prestes a ser transmitido pela interface de sa\u00edda. Na ACL padr\u00e3o acima, se aplic\u00e1ssemos in<\/strong> na interface da rede de origem (GigabitEthernet0\/1), o efeito seria o mesmo para o tr\u00e1fego da 192.168.20.0\/24, mas com um risco: qualquer tr\u00e1fego dessa rede seria bloqueado antes mesmo de chegar \u00e0 tabela de roteamento, afetando potencialmente outros destinos. Por isso a regra de ouro: ACLs padr\u00e3o, sempre outbound<\/strong> e pr\u00f3ximas ao destino.<\/p>\n
        ACLs Estendidas \u2014 A arte da filtragem granular<\/h3>\n
        Agora elevamos o n\u00edvel. As ACLs estendidas<\/strong> permitem especificar n\u00e3o apenas a origem, mas tamb\u00e9m 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\u00e3o em ambientes de produ\u00e7\u00e3o; as estendidas s\u00e3o a norma, pois oferecem precis\u00e3o cir\u00fargica. Sem elas, voc\u00ea n\u00e3o consegue, por exemplo, permitir que um \u00fanico host acesse o servidor web na porta 443 enquanto bloqueia todo o restante do tr\u00e1fego.<\/p>\n
        O formato geral de uma ACE estendida \u00e9: access-list <n\u00famero> <permit|deny> <protocolo> <origem> <wildcard-origem> [porta-origem] <destino> <wildcard-destino> [porta-destino] [op\u00e7\u00f5es]<\/strong>. Vamos construir tr\u00eas cen\u00e1rios progressivos, do mais simples ao mais complexo, sempre na mesma topologia.<\/p>\n
        Cen\u00e1rio 1:<\/strong> Permitir que o host 192.168.10.20 (servidor SSH) receba conex\u00f5es SSH (porta 22 TCP) vindas de qualquer lugar, mas bloquear qualquer outro tr\u00e1fego destinado a ele. Queremos tamb\u00e9m 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\u00e7\u00e3o inbound<\/strong>.<\/p>\n
        ! === ACL Estendida 110 \u2014 Filtragem por servi\u00e7o ===\nR1# configure terminal\nR1(config)# access-list 110 permit tcp any host 192.168.10.20 eq 22\nR1(config)# access-list 110 permit tcp any host 192.168.10.10 eq 443\nR1(config)# access-list 110 deny ip any host 192.168.10.20\nR1(config)# access-list 110 deny ip any host 192.168.10.10\nR1(config)# access-list 110 permit ip any any\nR1(config)# interface gigabitEthernet 0\/0\nR1(config-if)# no ip access-group 10 out\nR1(config-if)# ip access-group 110 in\nR1(config-if)# end\nR1# write memory\n<\/code><\/pre>\n
        Dissecando cada ACE: access-list 110 permit tcp any host 192.168.10.20 eq 22<\/strong> \u2014 o n\u00famero 110 indica ACL estendida; permit tcp<\/strong> porque SSH opera sobre TCP; any<\/strong> representa qualquer origem (0.0.0.0 255.255.255.255); host 192.168.10.20<\/strong> \u00e9 uma abrevia\u00e7\u00e3o para 192.168.10.20 0.0.0.0 (m\u00e1scara wildcard que casa exatamente com esse IP); eq 22<\/strong> 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<\/strong> bloqueiam qualquer outro tr\u00e1fego IP (TCP, UDP, ICMP, etc.) destinado aos servidores. Finalmente, permit ip any any<\/strong> garante que o restante do tr\u00e1fego flua normalmente. Note que removemos a ACL 10 anterior com no ip access-group 10 out<\/strong> \u2014 uma interface s\u00f3 pode ter uma ACL por dire\u00e7\u00e3o e por protocolo.<\/p>\n
        Cen\u00e1rio 2:<\/strong> Filtragem de ICMP. Queremos permitir apenas echo-reply<\/strong> (respostas de ping) da rede 192.168.10.0\/24 para a rede 192.168.20.0\/24, mas bloquear echo-request<\/strong> (solicita\u00e7\u00f5es de ping) originadas da 192.168.20.0\/24. Isso impede que os usu\u00e1rios da rede 192.168.20.0\/24 fa\u00e7am ping nos servidores, mas permite que vejam as respostas caso os servidores os pingem.<\/p>\n
        ! === ACL Estendida 120 \u2014 Controle de ICMP ===\nR1# configure terminal\nR1(config)# access-list 120 deny icmp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 echo\nR1(config)# access-list 120 permit icmp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 echo-reply\nR1(config)# access-list 120 permit ip any any\nR1(config)# interface gigabitEthernet 0\/1\nR1(config-if)# ip access-group 120 in\nR1(config-if)# end\n<\/code><\/pre>\n
        O argumento echo<\/strong> ap\u00f3s o destino refere-se ao tipo ICMP 8 (echo-request). O echo-reply<\/strong> \u00e9 o tipo ICMP 0. O IOS aceita tanto os nomes quanto os n\u00fameros. Aplicamos a ACL na interface da rede de origem (GigabitEthernet0\/1) na dire\u00e7\u00e3o in<\/strong>, bloqueando os echo-requests assim que entram no roteador \u2014 seguindo a recomenda\u00e7\u00e3o de posicionar ACLs estendidas pr\u00f3ximo \u00e0 origem. A \u00faltima linha com permit ip any any<\/strong> \u00e9 crucial; sem ela, at\u00e9 o tr\u00e1fego web seria bloqueado.<\/p>\n
        ACLs Nomeadas \u2014 Flexibilidade e edi\u00e7\u00e3o em tempo real<\/h3>\n
        ACLs numeradas t\u00eam uma limita\u00e7\u00e3o severa: voc\u00ea n\u00e3o pode remover ou inserir uma ACE no meio da lista sem apagar a ACL inteira e recri\u00e1-la. Em ambientes de produ\u00e7\u00e3o, isso \u00e9 invi\u00e1vel \u2014 imagine derrubar centenas de regras para corrigir uma linha. As ACLs nomeadas<\/strong> resolvem esse problema permitindo a edi\u00e7\u00e3o por n\u00famero de sequ\u00eancia. Vamos criar uma ACL nomeada que consolida nossas pol\u00edticas.<\/p>\n
        ! === ACL Nomeada \"FILTRO_SERVIDORES\" ===\nR1# configure terminal\nR1(config)# ip access-list extended FILTRO_SERVIDORES\nR1(config-ext-nacl)# 10 permit tcp any host 192.168.10.20 eq 22\nR1(config-ext-nacl)# 20 permit tcp any host 192.168.10.10 eq 443\nR1(config-ext-nacl)# 30 deny ip any host 192.168.10.20\nR1(config-ext-nacl)# 40 deny ip any host 192.168.10.10\nR1(config-ext-nacl)# 50 permit ip any any\nR1(config-ext-nacl)# exit\nR1(config)# interface gigabitEthernet 0\/0\nR1(config-if)# ip access-group FILTRO_SERVIDORES in\nR1(config-if)# end\n<\/code><\/pre>\n
        Repare no prompt (config-ext-nacl)<\/strong> \u2014 \u00e9 o submode de configura\u00e7\u00e3o de ACL nomeada estendida. Os n\u00fameros 10, 20, 30, 40, 50<\/strong> s\u00e3o sequ\u00eancias que determinam a ordem de processamento. Se posteriormente voc\u00ea precisar inserir uma regra entre a 20 e a 30, basta usar 25 permit tcp any host 192.168.10.30 eq 80<\/strong> e a nova ACE ser\u00e1 inserida na posi\u00e7\u00e3o correta. Para remover uma ACE espec\u00edfica, use no 30<\/strong> (remove a sequ\u00eancia 30). Isso \u00e9 imposs\u00edvel com ACLs numeradas, onde o no access-list 110<\/strong> apaga a lista inteira.<\/p>\n\n\n\n\n\n\n\n\n\n
        Tabela 2 \u2014 Operadores de Porta em ACLs Estendidas<\/caption>\n
        Operador<\/th>\nSignificado<\/th>\nExemplo<\/th>\nEquivalente num\u00e9rico<\/th>\n<\/tr>\n<\/thead>\n
        eq<\/strong><\/td>\nIgual a (exatamente esta porta)<\/td>\neq 22<\/strong><\/td>\nPorta 22 apenas<\/td>\n<\/tr>\n
        gt<\/strong><\/td>\nMaior que (greater than)<\/td>\ngt 1023<\/strong><\/td>\nPortas 1024\u201365535<\/td>\n<\/tr>\n
        lt<\/strong><\/td>\nMenor que (less than)<\/td>\nlt 1024<\/strong><\/td>\nPortas 0\u20131023<\/td>\n<\/tr>\n
        neq<\/strong><\/td>\nDiferente de (not equal)<\/td>\nneq 80<\/strong><\/td>\nTodas exceto a 80<\/td>\n<\/tr>\n
        range<\/strong><\/td>\nIntervalo inclusivo<\/td>\nrange 20 21<\/strong><\/td>\nPortas 20 e 21 (FTP)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        ACLs em Linhas VTY \u2014 Protegendo o acesso ao roteador<\/h3>\n
        Um dos usos mais cr\u00edticos das ACLs \u00e9 a prote\u00e7\u00e3o do plano de controle<\/strong> do pr\u00f3prio roteador. As linhas VTY<\/strong> (Virtual Teletype) controlam acessos via Telnet e SSH. Sem uma ACL aplicada \u00e0s VTY, qualquer host que consiga alcan\u00e7ar o roteador pode tentar login \u2014 um vetor de ataque grav\u00edssimo. Vamos configurar uma ACL que permita SSH apenas a partir do host de ger\u00eancia 192.168.10.100 e negue tudo o mais.<\/p>\n
        ! === ACL para Prote\u00e7\u00e3o das Linhas VTY ===\nR1# configure terminal\nR1(config)# ip access-list standard GERENCIA_VTY\nR1(config-std-nacl)# permit host 192.168.10.100\nR1(config-std-nacl)# deny any\nR1(config-std-nacl)# exit\nR1(config)# line vty 0 15\nR1(config-line)# access-class GERENCIA_VTY in\nR1(config-line)# transport input ssh\nR1(config-line)# login local\nR1(config-line)# end\nR1# write memory\n<\/code><\/pre>\n
        O comando access-class GERENCIA_VTY in<\/strong> aplica a ACL padr\u00e3o \u00e0s linhas VTY, restringindo as conex\u00f5es de entrada. Diferente de interfaces, onde usamos ip access-group<\/strong>, nas linhas VTY o comando \u00e9 access-class<\/strong>. A ACL \u00e9 do tipo padr\u00e3o porque nas VTY s\u00f3 nos interessa a origem da conex\u00e3o. A diretiva transport input ssh<\/strong> garante que apenas SSH seja aceito (bloqueando Telnet, que transmite senhas em texto claro). login local<\/strong> for\u00e7a o uso da base de usu\u00e1rios local do roteador. Em nossos projetos na JRT Technology Solutions, combinamos essa ACL com AAA via TACACS+ para um controle ainda mais rigoroso.<\/p>\n
        Verificando a Instala\u00e7\u00e3o \/ Testando a Configura\u00e7\u00e3o<\/h3>\n
        Ap\u00f3s aplicar qualquer ACL, a verifica\u00e7\u00e3o \u00e9 obrigat\u00f3ria. O IOS oferece comandos espec\u00edficos para visualizar o conte\u00fado das ACLs, contabilizar os matches (acertos) de cada ACE e inspecionar quais ACLs est\u00e3o aplicadas em cada interface. Acompanhe os comandos e as sa\u00eddas esperadas.<\/p>\n
        ! === Comandos de Verifica\u00e7\u00e3o ===\nR1# show access-lists\nR1# show access-lists FILTRO_SERVIDORES\nR1# show ip interface gigabitEthernet 0\/0 | include access list\nR1# show ip interface gigabitEthernet 0\/1 | include access list\nR1# show running-config | section access-list\nR1# show running-config | section line vty\n<\/code><\/pre>\n
        R1# show access-lists\nStandard IP access list GERENCIA_VTY\n    10 permit 192.168.10.100 (15 matches)\n    20 deny any (142 matches)\nExtended IP access list FILTRO_SERVIDORES\n    10 permit tcp any host 192.168.10.20 eq 22 (8 matches)\n    20 permit tcp any host 192.168.10.10 eq 443 (52 matches)\n    30 deny ip any host 192.168.10.20 (3 matches)\n    40 deny ip any host 192.168.10.10 (12 matches)\n    50 permit ip any any (947 matches)\nExtended IP access list 120\n    10 deny icmp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 echo (27 matches)\n    20 permit icmp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 echo-reply (19 matches)\n    30 permit ip any any (1341 matches)\n\nR1# show ip interface gigabitEthernet 0\/0 | include access list\n  Outgoing access list is not set\n  Inbound  access list is FILTRO_SERVIDORES\n\nR1# show ip interface gigabitEthernet 0\/1 | include access list\n  Outgoing access list is not set\n  Inbound  access list is 120\n<\/code><\/pre>\n
        O campo matches<\/strong> \u00e9 um tesouro para troubleshooting. Ele mostra quantos pacotes foram avaliados e casaram com cada ACE. Se uma regra que voc\u00ea esperava ver funcionando tem zero matches, algo est\u00e1 errado \u2014 ou o tr\u00e1fego n\u00e3o est\u00e1 chegando, ou uma regra anterior j\u00e1 o capturou. A sa\u00edda do show ip interface<\/strong> revela exatamente qual ACL est\u00e1 aplicada e em qual dire\u00e7\u00e3o. Note que nossa ACL 10 original foi removida, por isso Outgoing access list is not set<\/strong>.<\/p>\n
        Para testar na pr\u00e1tica, recomendamos este roteiro de valida\u00e7\u00e3o:<\/p>\n
          \n
        1. Do host 192.168.20.50, tente ping 192.168.10.10<\/strong>. Deve falhar (bloqueado pela ACL 120, echo).<\/li>\n
        2. Do host 192.168.10.10, execute ping 192.168.20.50<\/strong>. Deve ter sucesso, e a resposta (echo-reply) ser\u00e1 vis\u00edvel. Verifique os matches na ACL 120 \u2014 a linha 20 deve incrementar.<\/li>\n
        3. De um host qualquer (exceto 192.168.10.100), tente ssh -l admin 192.168.10.1<\/strong> (assumindo que 192.168.10.1 \u00e9 o IP da interface do roteador). Deve falhar com “Connection refused” ou timeout. A ACL GERENCIA_VTY bloqueia.<\/li>\n
        4. Do host 192.168.10.100, execute ssh -l admin 192.168.10.1<\/strong>. Deve apresentar o prompt de senha. Sucesso.<\/li>\n
        5. Do host 192.168.10.10 (servidor web), acesse curl -k https:\/\/192.168.10.10<\/strong> localmente. Tr\u00e1fego loopback n\u00e3o passa pela ACL, ent\u00e3o funciona. De um host externo, acesse http:\/\/192.168.10.10<\/strong> (porta 80). Deve falhar \u2014 apenas 443 est\u00e1 liberada.<\/li>\n<\/ol>\n
          Erros Comuns e Como Resolver<\/h3>\n
            \n
          • \n        Erro 1: Regra correta, mas ordem errada \u2014 o tr\u00e1fego \u00e9 bloqueado pela nega\u00e7\u00e3o impl\u00edcita ou por uma ACE anterior.<\/strong>
            \n        Sintoma:<\/em> Pacotes esperados n\u00e3o passam, mesmo com uma ACE permit<\/strong> na lista.
            \n        Causa:<\/em> Uma ACE deny<\/strong> anterior capturou o pacote antes que ele chegasse \u00e0 regra de permiss\u00e3o. Exemplo: deny ip any any<\/strong> na linha 10 e permit tcp any host 192.168.10.10 eq 80<\/strong> na linha 20 \u2014 a segunda nunca ser\u00e1 alcan\u00e7ada.
            \n        Solu\u00e7\u00e3o:<\/em> Use show access-lists<\/strong> para ver a ordem das sequ\u00eancias. Reorganize as ACEs colocando as permiss\u00f5es espec\u00edficas antes das nega\u00e7\u00f5es gen\u00e9ricas. Se for ACL nomeada, utilize ip access-list resequence<\/strong> para renumerar com intervalos maiores (ex: passo 20) e reordenar manualmente.\n    <\/li>\n
          • \n        Erro 2: M\u00e1scara wildcard incorreta \u2014 a sub-rede n\u00e3o \u00e9 casada como esperado.<\/strong>
            \n        Sintoma:<\/em> ACL n\u00e3o bloqueia (ou bloqueia demais) hosts de uma sub-rede.
            \n        Causa:<\/em> Confus\u00e3o entre m\u00e1scara de sub-rede e wildcard. Usar 0.0.0.255<\/strong> para uma \/24 est\u00e1 correto, mas usar 0.0.0.7<\/strong> para uma \/29 (quando o correto seria 0.0.0.7<\/strong>)… na verdade, wildcard de \/29 \u00e9 255.255.255.248 -> wildcard = 0.0.0.7. O erro mais comum \u00e9 usar 0.0.0.248<\/strong> ou 0.0.0.255<\/strong> para uma \/29, capturando hosts a mais ou a menos.
            \n        Solu\u00e7\u00e3o:<\/em> Sempre confira: wildcard = 255.255.255.255 – m\u00e1scara de sub-rede. Para \/29 (255.255.255.248), wildcard = 0.0.0.7. Use calculadoras online at\u00e9 internalizar. Lembre-se: na wildcard, 0 = “deve casar”, 1 = “ignore”.\n    <\/li>\n
          • \n        Erro 3: Esquecer o “permit any” (nega\u00e7\u00e3o impl\u00edcita derruba tudo).<\/strong>
            \n        Sintoma:<\/em> Ap\u00f3s aplicar a ACL, todo o tr\u00e1fego para \u2014 inclusive protocolos de roteamento como OSPF ou EIGRP.
            \n        Causa:<\/em> A ACL n\u00e3o tem uma ACE permit ip any any<\/strong> no final. A nega\u00e7\u00e3o impl\u00edcita bloqueia inclusive os hellos dos protocolos de roteamento, derrubando adjac\u00eancias.
            \n        Solu\u00e7\u00e3o:<\/em> Sempre termine ACLs aplicadas a interfaces de tr\u00e2nsito com permit ip any any<\/strong>, a menos que a pol\u00edtica exija bloqueio total. Se voc\u00ea usa protocolos de roteamento din\u00e2mico, adicione ACEs expl\u00edcitas para permiti-los: permit ospf any any<\/strong> (protocolo 89) ou permit eigrp any any<\/strong> (protocolo 88) antes de negar qualquer coisa.\n    <\/li>\n
          • \n        Erro 4: Aplicar ACL na dire\u00e7\u00e3o errada (inbound vs outbound).<\/strong>
            \n        Sintoma:<\/em> A ACL parece n\u00e3o surtir efeito, ou bloqueia tr\u00e1fego que deveria ser permitido.
            \n        Causa:<\/em> O administrador aplicou a ACL in<\/strong> na interface de destino, mas o tr\u00e1fego est\u00e1 entrando por outra interface e saindo pela interface onde a ACL est\u00e1 out<\/strong> (ou vice-versa). O processamento inbound ocorre antes do roteamento; outbound, depois.
            \n        Solu\u00e7\u00e3o:<\/em> Desenhe o fluxo do pacote no papel. Se a origem est\u00e1 conectada \u00e0 interface G0\/1 e o destino \u00e0 G0\/0, uma ACL in<\/strong> em G0\/1 analisa o pacote antes de rotear; uma ACL out<\/strong> em G0\/0 analisa depois de roteado. Ambas funcionam, mas os crit\u00e9rios de origem\/destino na ACL n\u00e3o mudam \u2014 a ACL sempre avalia o pacote original (origem real, destino real). O problema geralmente est\u00e1 em achar que in<\/strong> na interface de destino inverte origem e destino \u2014 n\u00e3o inverte.\n    <\/li>\n
          • \n        Erro 5: N\u00e3o remover ACLs antigas antes de aplicar novas.<\/strong>
            \n        Sintoma:<\/em> Comportamento inesperado, regras conflitantes.
            \n        Causa:<\/em> Uma interface pode ter uma ACL inbound e outra outbound simultaneamente. Se voc\u00ea aplicou uma ACL numerada antiga e depois aplica uma nomeada na mesma dire\u00e7\u00e3o, a antiga \u00e9 substitu\u00edda. Mas se eram dire\u00e7\u00f5es diferentes (uma in, outra out), ambas coexistem e interagem de forma dif\u00edcil de depurar.
            \n        Solu\u00e7\u00e3o:<\/em> Sempre execute show ip interface <int> | include access list<\/strong> para verificar quais ACLs est\u00e3o aplicadas e em quais dire\u00e7\u00f5es. Remova explicitamente com no ip access-group <nome> <in|out><\/strong> antes de aplicar novas.\n    <\/li>\n<\/ul>\n
            Boas Pr\u00e1ticas e Dicas Avan\u00e7adas<\/h3>\n
            Ao longo de centenas de implanta\u00e7\u00f5es na JRT Technology Solutions, consolidamos um conjunto de pr\u00e1ticas que evitam dores de cabe\u00e7a e garantem que as ACLs sejam sustent\u00e1veis a longo prazo. A primeira e mais importante: documente cada ACE<\/strong>. Embora o IOS n\u00e3o tenha um campo de coment\u00e1rio nativo nas ACLs numeradas, voc\u00ea pode usar remark<\/strong> nas ACLs nomeadas. Exemplo: remark Permitir SSH para servidor de ger\u00eancia<\/strong> seguido da ACE correspondente. Isso transforma uma sopa de n\u00fameros IP em uma pol\u00edtica leg\u00edvel por qualquer pessoa da equipe.<\/p>\n
            Segunda pr\u00e1tica: utilize intervalos de sequ\u00eancia generosos<\/strong>. Ao criar ACLs nomeadas, numere as ACEs com passos de 20 ou 50 (10, 30, 50, 70… ou 100, 200, 300…). Isso deixa espa\u00e7o para inserir regras intermedi\u00e1rias sem precisar reescrever toda a lista. Em equipamentos com software anterior ao IOS 12.4(20)T, ACLs nomeadas tamb\u00e9m n\u00e3o permitiam inser\u00e7\u00e3o \u2014 mas qualquer vers\u00e3o moderna suporta. Se voc\u00ea herdar um ambiente com ACLs numeradas e precisar edit\u00e1-las, copie o show running-config | section access-list<\/strong> para um editor de texto, fa\u00e7a as altera\u00e7\u00f5es, remova a ACL antiga (no access-list <n\u00famero><\/strong>) e recrie-a j\u00e1 com as corre\u00e7\u00f5es. Fa\u00e7a isso em janela de manuten\u00e7\u00e3o.<\/p>\n
            Terceira: cuidado com o tr\u00e1fego de retorno<\/strong>. ACLs estendidas no IOS s\u00e3o stateless<\/strong> \u2014 cada pacote \u00e9 avaliado independentemente. Se voc\u00ea permite tr\u00e1fego TCP de A para B na porta 80, o tr\u00e1fego de retorno (B para A, porta de origem aleat\u00f3ria) N\u00c3O est\u00e1 automaticamente permitido, a menos que sua ACL tenha uma ACE que o cubra ou que voc\u00ea utilize o recurso de established<\/strong>. A palavra-chave established<\/strong> em uma ACE TCP verifica se o pacote tem os flags ACK ou RST setados, indicando que pertence a uma conex\u00e3o j\u00e1 estabelecida. Exemplo: access-list 130 permit tcp any 192.168.10.0 0.0.0.255 established<\/strong> permite apenas respostas, n\u00e3o novas conex\u00f5es. Use com sabedoria.<\/p>\n
            Quarta pr\u00e1tica: teste em ambiente controlado antes da produ\u00e7\u00e3o<\/strong>. Um erro de ACL pode isolar voc\u00ea do equipamento remotamente \u2014 o famoso “trancar-se do lado de fora”. Ao aplicar ACLs em linhas VTY, sempre mantenha uma sess\u00e3o de console aberta como backup. Se a ACL bloquear seu IP, voc\u00ea precisar\u00e1 do console para reverter. Em nossos projetos, configuramos um reload in 10<\/strong> antes de aplicar ACLs cr\u00edticas remotamente; se algo der errado e perdermos conectividade, o roteador reinicia e volta \u00e0 configura\u00e7\u00e3o anterior (desde que voc\u00ea n\u00e3o tenha salvo). Ap\u00f3s confirmar o funcionamento, execute reload cancel<\/strong> e write memory<\/strong>.<\/p>\n
            Quinta: ACLs e fragmenta\u00e7\u00e3o IP<\/strong>. Por padr\u00e3o, o IOS avalia apenas o fragmento inicial (que cont\u00e9m os cabe\u00e7alhos de camada 4) contra ACLs estendidas que especificam portas. Os fragmentos subsequentes s\u00e3o permitidos automaticamente, pois n\u00e3o carregam informa\u00e7\u00e3o de porta. Isso pode ser uma brecha de seguran\u00e7a. Para mitigar, vers\u00f5es modernas do IOS suportam ip access-list logging denied fragments<\/strong> ou regras expl\u00edcitas com fragments<\/strong>. Se seu ambiente lida com tr\u00e1fego fragmentado (VPNs, NFS, alguns t\u00faneis), estude esse t\u00f3pico adicional.<\/p>\n
            Resumo da Aula 14<\/h3>\n
            Nesta aula densa e 100% pr\u00e1tica, voc\u00ea dominou as ACLs<\/strong> \u2014 listas de controle de acesso \u2014 no Cisco IOS. Aprendemos que as ACLs s\u00e3o filtros sequenciais processados na primeira correspond\u00eancia, com uma nega\u00e7\u00e3o impl\u00edcita ao final. Exploramos as ACLs padr\u00e3o<\/strong> (intervalos 1\u201399, 1300\u20131999), que filtram apenas por IP de origem e devem ser posicionadas pr\u00f3ximas ao destino, e as ACLs estendidas<\/strong> (100\u2013199, 2000\u20132699), que operam com granularidade de origem, destino, protocolo e portas, sendo ideais para aplica\u00e7\u00e3o pr\u00f3xima \u00e0 origem. Desvendamos a m\u00e1scara wildcard \u2014 a invers\u00e3o da m\u00e1scara de sub-rede \u2014 e praticamos o c\u00e1lculo para sub-redes \/24, \/28 e \/29.<\/p>\n
            Configuramos cen\u00e1rios reais: bloqueio de sub-redes inteiras com ACL padr\u00e3o, filtragem de servi\u00e7os (SSH, HTTPS) com ACL estendida, controle de ICMP por tipo de mensagem, e prote\u00e7\u00e3o das linhas VTY com access-class<\/strong>. Implementamos ACLs nomeadas e compreendemos suas vantagens de edi\u00e7\u00e3o por sequ\u00eancia. Verificamos cada configura\u00e7\u00e3o com show access-lists<\/strong> e show ip interface<\/strong>, interpretando os contadores de matches para diagn\u00f3stico. Cobrimos os cinco erros mais comuns \u2014 ordem incorreta das ACEs, wildcard errada, esquecimento do permit any<\/strong>, dire\u00e7\u00e3o inbound\/outbound equivocada e conflitos entre ACLs antigas e novas \u2014 com solu\u00e7\u00f5es pr\u00e1ticas para cada um.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
            Tabela 3 \u2014 Refer\u00eancia R\u00e1pida de Comandos de ACL<\/caption>\n
            Comando<\/th>\nModo<\/th>\nDescri\u00e7\u00e3o<\/th>\n<\/tr>\n<\/thead>\n
            access-list <1-99> permit|deny <origem> <wildcard><\/strong><\/td>\nGlobal config<\/td>\nCria ACE de ACL padr\u00e3o numerada<\/td>\n<\/tr>\n
            access-list <100-199> permit|deny <protocolo> <orig> <wc> <dest> <wc> [eq <porta>]<\/strong><\/td>\nGlobal config<\/td>\nCria ACE de ACL estendida numerada<\/td>\n<\/tr>\n
            ip access-list standard|extended <nome><\/strong><\/td>\nGlobal config<\/td>\nCria ACL nomeada e entra no submode apropriado<\/td>\n<\/tr>\n
            ip access-group <acl> in|out<\/strong><\/td>\nInterface config<\/td>\nAplica ACL a uma interface na dire\u00e7\u00e3o especificada<\/td>\n<\/tr>\n
            access-class <acl> in|out<\/strong><\/td>\nLine config (VTY)<\/td>\nAplica ACL a linhas VTY<\/td>\n<\/tr>\n
            show access-lists [<nome|n\u00famero>]<\/strong><\/td>\nPrivileged EXEC<\/td>\nExibe todas as ACLs e contadores de matches<\/td>\n<\/tr>\n
            show ip interface <int> | include access list<\/strong><\/td>\nPrivileged EXEC<\/td>\nMostra ACLs aplicadas \u00e0 interface<\/td>\n<\/tr>\n
            no access-list <n\u00famero><\/strong><\/td>\nGlobal config<\/td>\nRemove ACL numerada inteira<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
            Na Aula 15 \u2014 Network Address Translation (NAT) no Cisco IOS<\/strong>, vamos conectar tudo o que aprendemos sobre roteamento e ACLs ao mundo real, configurando NAT est\u00e1tico, din\u00e2mico e PAT (sobrecarga) para prover acesso \u00e0 Internet a redes privadas. Veremos como as ACLs desempenham papel fundamental na defini\u00e7\u00e3o do tr\u00e1fego “interessante” que dispara tradu\u00e7\u00f5es NAT. Prepare-se: ser\u00e1 a aula que transforma seu laborat\u00f3rio em uma rede verdadeiramente conectada ao mundo externo.<\/p>\n
            Se voc\u00ea deseja aprofundar seus conhecimentos com treinamentos hands-on, implementa\u00e7\u00f5es guiadas ou suporte especializado em Cisco IOS, a JRT Technology Solutions<\/strong> est\u00e1 \u00e0 disposi\u00e7\u00e3o. Nossos especialistas utilizam diariamente as t\u00e9cnicas apresentadas nesta aula para projetar e manter infraestruturas seguras e de alto desempenho para clientes de todos os portes. Deixe seu coment\u00e1rio abaixo com d\u00favidas ou cen\u00e1rios que gostaria de ver explorados \u2014 sua participa\u00e7\u00e3o enriquece o curso e ajuda a comunidade de profissionais de TI a crescer.<\/p>\n
            \n
            Quer aprender na pr\u00e1tica com especialistas?<\/p>\n
            A JRT Technology Solutions oferece treinamentos e implementa\u00e7\u00e3o de Cisco IOS para equipes corporativas.<\/p>\n
              
            \n    <\/svg>
            \n    Falar no WhatsApp
            \n  <\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
            Aprenda sobre ACLs no Cisco IOS: descubra como usar listas de controle de acesso padr\u00e3o e estendidas para otimizar sua rede. Clique e saiba mais!<\/p>\n","protected":false},"author":1,"featured_media":1158,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[9],"tags":[1982,1985,1984,138,1983,22],"class_list":["post-1159","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-conectividade","tag-acl-cisco","tag-acls-estendidas","tag-acls-padrao","tag-cisco-ios","tag-listas-de-controle-de-acesso","tag-seguranca-de-rede"],"_links":{"self":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/posts\/1159","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1159"}],"version-history":[{"count":0,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/posts\/1159\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/media\/1158"}],"wp:attachment":[{"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jrtx.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}