Uma ACL, no contexto dos produtos Cisco, é um recurso do IOS que permite a você filtrar determinados pacotes, exatamente como um firewall faria porém de uma maneira muito mais simplificada e com menos recursos. Utilizando ACLs no seu equipamento você pode filtrar tentativas de conexões indo/vindo de/para hosts específicos; pode bloquear completamente um determinado protocolo antes de tal requisição entrar na sua rede (claro que isso depende do posicionamento da ACL); controlar atualizações enviadas por protocolos de roteamento, etc. Enfim, ACLs tem uma importância enorme e você tem que saber como trabalhar com elas seja para ser um profissional melhor seja para passar nos exames de certificação.

Aqui você vai entender melhor o que é uma ACL e uma descrição geral de quais são os seus tipos e funcionalidades. Também vou tentar mostrar alguns exemplos simples de uso de cada uma das ACLs.

Mas, o que são as ACLs?

Em redes modernas, o administrador se preocupa não apenas com disponibilidade mas também com a segurança. É necessário que se estabeleça um controle de quais tipos de pacotes podem passar de uma rede para outra; quais hosts externos podem se comunicar com os nossos; quais são os hosts confiáveis para nos enviar atualizações de rotas, etc. Enfim, é necessário um maior controle à fim de decidir se é ou não uma boa ideia permitir que determinado tráfego atravesse as suas redes.

Para esta finalidade existem muitas soluções, dentre as quais a mais conhecida é o firewall. Geralmente presente tanto em qualquer sistema operacional (como uma funcionalidade nativa ou como uma aplicação instalada separadamente) quanto em appliances especializadas, este tipo de software pode ser extremamente complexo e exigir um poder de processamento considerável do hardware sobre o qual está sendo executado já que cada pacote deve ser comparado com uma série de regras.

Como uma solução menos complexa e com menos funcionalidades, roteadores (e também alguns outros tipos de dispositivos) são capazes de fazer um filtro básico dos pacotes que passam por ele. Isto se chama ACL – Access Control Lists (Listas de Controle de Acesso).

Access Control Lists são conjuntos de regras para filtrar pacotes, permitindo ou negando que eles sigam em frente. Tais listas podem ser criadas com vários objetivos em mente: impedir determinado host de enviar pacotes para uma rede, permitir acesso via SSH à um dispositivo apenas partindo de determinada máquina, determinar qual tráfego será criptografado por um túnel VPN ou mesmo determinar qual tráfego será analisado pelo módulo de IPS de um Cisco ASA. Além disso, ACLs também podem ajudar a mitigar alguns tipos de ataques:

• IP spoofing;
• DoS (Denial of Server) através de TCP SYN;
• Proteção contra ataques Smurf;
• Além de atuar como um filtro de mensagens ICMP.

Bem básico, porém bastante útil de se ter na borda da sua rede, diminuindo o tráfego a ser analisado pelos firewalls internos.

Quais os tipos de ACLs?

Existem três “tipos” diferentes de ACLs no IOS:

• ACLs standard: Esta é a lista mais básica, com menos funcionalidades. Filtram apenas através do endereço IP de origem. Os números de identificação deste tipo de ACL vão de 1 a 99 e de 1300 a 1999. Este tipo de ACL deve ser posicionada o mais próximo possível do destino do tráfego.
• ACLs extended: Além de filtrarem através dos endereços de IP de origem e destino, também permitem que se filtre o tráfego através de portas e protocolos. Os números de identificação deste tipo de ACL vão de 100 a 199 e de 2000 a 2699. Este tipo de ACL deve ser posicionada o mais próximo possível da origem.
• ACLs named: ACLs named (ou nomeadas) têm as mesmas características que ACLs extended, e permitem que você use um nome mais intuitivo para a ACL como allow_rh_out, deny_dmz_out, etc. Além disso, este tipo de ACL também oferece modos de edição mais avançados facilitando a vida do administrador. Os nomes utilizados para identificar este tipo de ACL não podem conter espaços ou pontuação e devem começar com uma letra.

Embora as ACLs tenham alguns detalhes diferentes, todas compartilham o mesmo método de análise: cada pacote é comparado com cada uma das regras presentes na ACL *EM ORDEM* e a ação descrita na primeira regra que “casar” com o pacote será tomada. Ou seja, a ordem das regras aqui pode fazer a diferença entre uma rede que funciona 100% ou você tendo que fazer hora extra pra descobrir o quê está bloqueando a troca de rotas OSPF entre os seus roteadores :).

Outra coisa importantíssima que é verdade em todos os tipos de ACL: sempre há uma regra “deny all” implícita no final de todas as ACLs. Ou seja, uma ACL sem nenhuma regra irá bloquear absolutamente todos os pacotes que são comparados com ela. Portanto muito cuidado quando for aplicar uma ACL em uma interface.

Um outro detalhe que pode salvar sua vida: por padrão, ACLs não são stateful. Existe uma maneira de se modificar este comportamento, como veremos mais para frente.

 

NOTA: Lembre-se sempre que a ordem das regras faz toda a diferença quando o IOS está tentando descobrir o que fazer com um determinado pacote. Também não se esqueça de que há uma regra DENY ALL oculto no final de TODAS as ACLs. Portanto uma ACL vazia irá bloquear todo o conteúdo onde for aplicada.

Sobre a direção dos fluxos de dados

Não basta apenas criar uma ACL para que o tráfego passe a ser corretamente filtrado: você precisa definir a direção e a interface onde esta ACL será aplicada.

Mas como assim “direção”? Existem duas direções de tráfego em roteadores:

• inbound: Todo o tráfego vindo da rede e entrando no roteador através de uma de suas interfaces de roteamento.
• outbound: Todo o tráfego saindo de alguma interface do roteador e indo para a rede.

Para deixar ainda mais claro:

 

Uma coisa que deve ser observada e que vai influenciar diretamente no seu design de ACL: é permitida apenas uma ACL por protocolo, por direção e por interface. Ou seja, você não pode ter duas ACLs que trabalhem com TCP, na direção inbound na mesma interface. É uma ACL ou a outra, nunca ambas.

NOTA: Guarde isso na sua cabeça já, para evitar problemas: É permitida apenas UMA ACL por PROTOCOLO, por DIREÇÃO e por INTERFACE. Repita isso como um mantra para nunca mais esquecer! :)

Wildcard masks

Para definir quais sub-redes serão afetadas por uma determinada regra de ACL, você vai precisar usar a wildcard mask. Neste tipo de máscara 0 e 255 tem sentidos exatamente opostos à máscara de sub-rede que você já está acostumado (pelo menos espero que já esteja, hehehe).

Neste tipo de máscara, um bit 0 quer dizer que o octeto tem que “casar” exatamente e um bit 1 é ignorado (pode ser qualquer coisa). Ou seja, exatamente o contrário do que se faz quando se usa uma máscara de sub-rede normal. Porém, o valor dos bits continua o mesmo: da esquerda para a direita eles valerão 128, 64, 32, 16, 8, 4, 2, 1, respectivamente.

NOTA: Se você estiver configurando uma ACL em um ASA ou PIX, *não* use wildcard masks. Use a máscara normal.

Dois exemplos simples para você pegar o jeito:

Digamos que você precisa de uma wildcard mask que reconheça todos os IPs da rede 192.168.0.0/24. A máscara seria 0.0.0.255:

• Os três primeiros 0s indicam que é obrigatório que 192.168.0 esteja presente no endereço IP do pacote sendo analisado.
• O .255 indica que naquele octeto qualquer número é válido.

Para identificar um conjunto de subredes é a mesma coisa. Suponhamos que você quer que todas as redes entre 192.168.16.0/24 a 192.168.31.0/24 sejam afetadas por uma regra. A wildcard seria 0.0.15.255:

• Os dois primeiros 0s indicam que é obrigatório que 192.168 esteja presente
• 15 é a soma dos bits para que as subredes desejadas casem com a regra
• 255 indica que o último octeto não importa e vai casar qualquer que seja o número lá.

O assunto de wildcard masks é bem extenso e complexo, e exige um post só para ele. Por enquanto, vou ficar por aqui para não deixar o post muito longo. Se você precisa de mais ajuda entendendo este tipo de máscara, sugiro que faça uma pesquisa no Google por textos de apoio.

Criando uma ACL

Bom, agora você já tem uma boa base teórica sobre as ACLs e já pode sair criando as suas para proteger o seu ambiente. Nesta seção, vou mostar um exemplo para cada tipo de ACL existente no IOS para você ter uma ideia de como cada uma delas trabalha.

Criando uma ACL standard

Como dito anteriormente, as ACLs standard são o tipo mais básico de ACLs. Elas permitem apenas que você filtre o tráfego através dos endereços IP de origem, nada mais. Obviamente, esta falta de funcionalidades faz com que ACL’s standard sejam o tipo mais fácil de configurar.

Qualquer tipo de ACL é criada no modo de configuração global através do comando “access-list”. Para exemplificar o uso do comando, vamos começar criando uma ACL para negar qualquer coisa vinda do host 192.168.1.34:

Osiris(config)# access-list 1 deny 192.168.1.34 0.0.0.0

A linha acima é bem simples:

• 1: Como dito anteriormente, ACLs standard têm que ser numeradas de 1 a 99 ou de 1300 a 1999. Aqui escolhi arbitrariamente o número 1;
• deny: Esta é a ação que será tomada com o pacote que casar com a regra da ACL. Neste caso, o pacote será negado pelo roteador. Você também poderia ter colocado “permit” para que o pacote passasse pelo firewall ou “remark”, que não é bem uma ação – ele permite a você adicionar um comentário na ACL (veremos com mais detalhes mais à frente);
• 192.168.1.34 0.0.0.0: Este é o IP de origem e a wildcard mask, que neste caso casa apenas com este host específico.

Agora, vamos permitir todo o tráfego vindo do host 192.168.1.35, adicionar esta entrada na mesma ACL 1 utilizada anteriormente:

Osiris(config)# access-list 1 allow 192.168.1.35 0.0.0.0

Pronto! Agora a ACL 1 está parecida com o seguinte:

deny 192.168.1.34 0.0.0.0

allow 192.168.1.35 0.0.0.0

Lembre-se que nas ACLs os comandos vão sendo adicionados de acordo com a ordem em que você define e que a ordem faz muita diferença. Portanto, estude muito bem as suas possibilidades antes de sair adicionando as entradas.

E se você quisesse adicionar um comentário para facilitar o entendimento da ACL? Você consegue fazer isso utilizando a ação “remark”:

Osiris(config)# access-list 1 remark Permitindo o host do chefe

Você pode ver o comentário através do comando show running-config. O comentário que você vai digitar deve ter no máximo 100 caracteres.

Em alguns casos, pode ser interessante você logar quando um pacote casar com uma regra. A opção “log” permite a você fazer isso:

Osiris(config)# access-list 1 deny 192.168.1.2 0.0.0.0 log

Agora, sempre que alguma coisa casar com a regra acima uma mensagem informacional vai ser enviada para o console.

Antes de terminarmos a parte sobre ACLs standard, existem dois “atalhos” que você deveria conhecer: host e any.

O atalho host permite que você defina que o endereço que vem à seguir se refere à um host, sem precisar digitar a wildcard mask dele. Por exemplo, imagine a seguinte regra:

Osiris(config)# access-list 1 deny 192.168.1.1 0.0.0.0

Ela poderia ser reescrita da seguinte maneira:

Osiris(config)# access-list 1 deny host 192.168.1.1

E pronto, assim você não corre o risco de cometer um erro digitando a wildcard mask. O outro atalho é o “any”. Este atalho faz com que uma regra case com qualquer host, por exemplo:

Osiris(config)# access-list 1 allow any

Vai fazer com que o roteador permita que os pacotes de qualquer origem sejam enviados para o destino.

Essas são as opções de ACLs standard. Elas são bem simples pois não se pode definir protocolos e, como consequência, não se pode definir a porta. Por isso este tipo de ACL deve ser aplicada o mais próximo possível do destino, para garantir que os hosts negados neste tipo de ACL não sejam negados em redes às quais eles deveriam ter acesso.

NOTA: Lembre-se que ACLs standard devem sempre ser aplicadas próximo ao destino!

Criando uma ACL extended

Como você viu, as ACLs standard são extremamente simples porém oferecem pouquíssimas funcionalidades e isso pode acabar fazendo falta para você em vários casos.

Quando você precisa ser mais específico (permitir que tráfego HTTP do host A porém negar tráfego SMTP deste mesmo host), você deve recorrer às ACLs extended. Nessas, você pode especificar portas e protocolos para controlar o tráfego.

O modo de criação de uma ACL extended não difere em nada do das ACLs standard. Porém, existem mais opções que você pode usar com as extended. Por exemplo, vamos fazer uma regra para bloquear tráfego HTTP saindo do host 192.168.0.1 e indo para o host 192.168.0.2:

Osiris(config)# access-list 100 deny tcp host 192.168.0.1 192.168.0.2 eq 80

Explicando em detalhes:

• access-list 100: você já conhece o comando access-list para criar ACLs. O 100 está aqui pois esta ACL é extended e, como você deve se lembrar, o número de ACLs extended é de 100 a 199 e de 2000 a 2699. Aqui escolhi 100 arbitrariamente.
• deny: é a ação desta regra. Ela irá negar pacotes que casarem com ela.
• tcp: aqui estamos definindo o protocolo. As opções de protocolo são ahp, eigrp, esp, gre, icmp, igmp, ip, ipinip, nos, ospf, pcp, pim, tcp e udp. Basta selecionar o protocolo correto e colocar o nome dele na linha.
• host 192.168.0.1: é o mesmo atalho explicado anteriormente. Ao invés de colocarmos uma wildcard mask para dizer que 192.168.0.1 é um host, colocamos a palavra-chave “host”. Este é o IP da origem.
• 192.168.0.2: é o endereço IP do destino.
• eq 80: diz que esta regra só se aplica quando a porta for igual à 80. Outros operadores que você pode usar são gt (a regra só casa com portas acima do número especificado), lt (a regra só casa com portas abaixo do número especificado), neq (a regra só casa quando a porta *NÃO* for a que foi especificada), range (a regra casa apenas quando a porta especificada no pacote está no intervalo de portas especificado na linha de comando). Além destes também existem alguns outros com finalidades diferentes. Por exemplo, established (veremos mais à diante), log (que como vimos mostra uma mensagem quando o pacote casa com a regra), rst (casa com pacotes que tem o flag TCP RST ativado, fin (mesma coisa do RST), etc. Opções aqui abundam :)

Agora, mais um exemplo para deixar clara a diferença entre standard e extended: podemos fazer uma outra regra e dizer que tráfego SMTP (porta 25/TCP) deve ser aceito quando o destino for o host 192.168.0.2 e a origem 192.168.0.1:

Osiris(config)# access-list 100 permit tcp host 192.168.0.1 192.168.0.2 eq 25

Agora, o tráfego HTTP entre estes hosts será negado pelo roteador, porém tráfego SMTP poderá passar normalmente. Vale lembrar que em alguns casos você pode usar o nome do protocolo ao invés da porta. Por exemplo, ao invés de 23 usar “telnet”. Porém, nem todas as portas serão reconhecidas utilizando este método e você vai precisar usar o número da porta nestes casos (alguns exemplos de protocolos nomeados são domain (DNS), finger, ftp (21), ftp-data (20), nntp, irc).

Apenas para demonstrar uma funcionalidade um pouco diferente, vamos negar todos os pacotes de 192.168.0.3 cujos números de porta dos pacotes estejam no intervalo de 22 a 80 para qualquer destino:

Osiris(config)# access-list 100 deny tcp host 192.168.0.3 range 22 80 any

Como você pode ver, com isso você tem um controle muito melhor sobre o tráfego e pode fazer filtros mais inteligentes. Aplicar esta ACL à uma interface do roteador não é nem um pouco diferente do método utilizado com as ACLs standard. Apenas preste atenção ao número da ACL que você está aplicando para não cometer erros.

NOTA: Lembre-se que ACLs extended devem sempre ser aplicadas próximo à origem!

Criando uma ACL named

Quando a sua rede é pequena, uma ACL nomeada 113, 225, 10 pode não ser um grande problema. Porém, e quando você gerencia mais de 500 ACLs em roteadores diferentes? Aí a coisa complica bastante, né? Para descobrir o quê uma ACL faz você vai ter que sair correndo atrás de uma documentação (e também torcer para que alguém tenha documentado a ACL!). Seria muito mais fácil se você pudesse simplesmente se referir às ACLs por nomes, como por exemplo permit_rh_internet ou deny_dmz_rede_interna. Apenas por estes nomes você já tem uma ideia do que essas ACLs vão fazer.

Além disso, ACLs standard e extended apresentam algumas dificuldades quando você as está editando. Elas não permitem a você remover uma linha ou adicionar uma ACE antes de outra já existente. Isso pode ser bastante inconveniente.

Neste tópico você vai ver que uma ACL nomeada pode ser tanto do tipo standard quanto extended: é você quem vai escolher isso.

O processo de criação de uma ACL nomeada é um pouco diferente. Quando você cria uma nova, você vai entrar num modo específico para edição de ACL como se fosse um editor de textos. Como um primeiro exemplo, vamos criar uma lista nomeada standard e adicionar algumas regras:

Osiris(config)# ip access-list standard permite_estacao_chefe

Osiris(config-std-nacl)# permit host 192.168.1.10

Como você pode perceber, você não precisa da parte do comando “access-list 1″ já que tudo isso foi dito quando você entrou no modo de edição da ACL nomeada. E também, perceba que você define se será standard ou extended logo no comando ip access-list. Quando terminar, basta digitar “exit” e a sua ACL será salva.

NOTA: Aplicar uma ACL nomeada à uma interface não diferencia em nada do processo utilizado para as outras ACLs.

Agora vamos criar uma ACL nomeada extended. Vamos chamá-la de nega_http:

Osiris(config)# ip access-list extended nega_http

Osiris(config-ext-nacl)# deny tcp host 192.168.0.6 host 192.168.0.254 eq 80

Mais uma vez note que você não precisa digitar o comando inteiro como em uma lista numerada: basta digitar apenas a “parte que importa” do comando.

Ok, agora já entendemos como criar a ACL nomeada. Mas e para editá-las? Ok, digamos que nós criamos a lista nega_http há alguns meses e agora queremos adicionar um novo item no topo da lista, na posição 1. Como fazemos? Primeiro, vamos abrir a lista para edição:

Osiris(config)# ip access-list extended nega_http

Osiris(config-ext-nacl)#

Pronto, entramos no modo de edição. Agora, basta executarmos o seguinte comando para adicionar a nova regra no topo:

Osiris(config-ext-nacl)# 1 permit tcp host 192.168.0.6 host 192.168.0.10 eq 80

Pronto, agora esta nova regra está no topo da ACL como desejado. Para conferir a ordem, vá para o modo EXEC do roteador e execute o comando:

Osiris# show access-list nega_http

Extended IP access list nega_http

1 permit tcp host 192.168.0.6 host 192.168.0.10 eq www

10 deny tcp host 192.168.0.6 host 192.168.0.254 eq www

Ok, mas e para adicionar uma regra entre estas duas? Simples, basta informar um número de ordem qualquer entre 1 e 10:

Osiris(config-ext-nacl)# 2 permit tcp host 192.168.0.4 eq 80 any

Veja:

Osiris# show access-list nega_http

1 permit tcp host 192.168.0.6 host 192.168.0.10 eq www

2 permit tcp host 192.168.0.4 eq www any

10 deny tcp host 192.168.0.6 host 192.168.0.254 eq www

Regra adicionada entre as já existentes. Agora, vamos remover a regra número 2:

Osiris(config-ext-nacl)# no 2

Pronto, regra removida:

Osiris# show access-list nega_http

Extended IP access list nega_http

1 permit tcp host 192.168.0.6 host 192.168.0.10 eq www

10 deny tcp host 192.168.0.6 host 192.168.0.254 eq www

Acredito que eu tenha conseguido deixar claras as vantagens de se usar listas nomeadas ao invés de listas numeradas. Lembrando que o posicionamento ideal da ACL nomeada vai depender se ela é standard ou extended. Ela irá seguir as mesmas regras destes tipos que já foram vistos anteriormente.

Como aplicar uma ACL existente à uma interface?

Agora que você já criou a ACL, chegou a hora de começar a usá-la. Você pode criar quantas ACLs quiser (dentro dos limites comentados anteriormente, claro), mas se não aplicá-las a uma interface elas nunca serão utilizadas. Ou seja, uma ACL criada porém não aplicada não influencia no tráfego.

Depois de decidir a direção na qual ela será aplicada e escolher a interface mais adequada:

Osiris# configure terminal

Osiris(config)# interface Serial 0/0

Osiris(config-if)# ip access-group 1 out

O terceiro comando acima vai fazer com que a ACL 1 seja aplicada na interface Serial 0/0 filtrando tráfego de saída (out). No seu ambiente, substitua o “1″ pelo nome ou número da ACL que você vai usar e defina se o sentido certo é in ou out.

Atenção: assim que você apertar enter no comando “ip access-group” a ACL irá imediatamente começar a filtrar o tráfego. Portanto você precisa ter MUITA certeza do que está fazendo para não acabar dando um tiro no pé!

Como remover uma ACL de uma interface?

Depois de aplicar uma ACL em uma interface, obviamente você não precisa deixar ela lá para o resto da vida! Remover uma ACL de uma interface é bem simples, basta adicionar um “no” na frente do comando que você usou para colocá-la lá:

Osiris(config-if)# no access-list 102

Considerando que a ACL 102 estivesse aplicada na interface acima, ela teria sido removida com o comando mostrado. Simples, não? :)

Deixando uma ACL “stateful” usando com a opção established

Antes de começar, um aviso:

NOTA: Uma ACL que usa a palavra-chave “established” não é, nem de longe, um substituto para um firewall stateful. Não se esqueça disso!

Ou seja, o stateful da ACL não é um stateful “de verdade”.

Dito isso, vamos lá. Usando a opção “established” o tráfego relacionado com uma conexão já estabelecida é automaticamente permitido, sem que você tenha que criar uma outra entrada na ACL para que o tráfego de volta possa passar pelo roteador corretamente. O parâmetro “established” só pode ser usado com ACLs extended, por motivos que a esta altura já devem ser óbvios para você, não? :)

O comando muda pouquíssimo quando se usa o established:

Osiris(config)# access-list 103 permit tcp host 192.168.0.2 host 200.200.200.1 established

Assim, o tráfego que volta para o host será automaticamente permitido pois a conexão partiu do nosso host interno, que é confiável. Porém, é um pouco perigoso isso já que, como foi dito logo no começo, a ACL faz verificações muito básicas. O problema é que a ACL vai apenas verificar se a flag indicando que a conexão está estabelecida foi ativada no cabeçalho TCP sem questionar qualquer referência de que a conexão tenha sido estabelecida corretamente usando o “three-way handshake” do TCP. Ou seja, com uma ferramenta que permita a você criar um pacote será possível enganar o roteador facilmente.

Controlando o tráfego gerado pelo próprio dispositivo através de ACLs

Você também pode criar uma ACL para controlar e filtrar o tráfego gerado pelo próprio roteador. Ou seja, pode definir que hosts podem se conectar via Telnet ou SSH, por exemplo. Criar a ACL propriamente dita para controlar este tráfego não é diferente de criar uma ACL qualquer. O que muda é o modo como você aplica esta ACL na interface.

Como já vimos anteriormente, para aplicar a ACL para controlar o tráfego que passa pelo roteador (mas que não foi gerado por ele) você usa o comando “ip access-group” no modo de configuração da interface. Para controlar o tráfego gerado pelo roteador, você usa o comando “acess-class” no modo de configuração da linha:

Osiris(config-line)# access-class acl-que-vai-ser-aplicada direção

Lembre-se que para permitir o acesso SSH para o roteador, você também precisa configurar a linha vty. Portanto, a ACL que vai controlar este acesso deve ser aplicada da maneira descrita acima. Leia o meu post sobre configuração de SSH em roteadores Cisco para esclarecer alguma dúvida que você tenha.

Como gerenciar as ACLs

Ok, você criou, aplicou a ACL nas interfaces e agora tudo está de acordo com o que você queria. Como gerenciar as ACLs existentes no seu dispositivo?

Gerenciar uma grande quantidade de ACLs é um pouco incômodo já que não existe uma ferramenta intuitiva para atingir este objetivo. Tudo vai precisar ser feito pela linha de comando, por isso é de extrema importância que você dê nomes claros e significativos para todas as suas ACLs: na hora de gerenciar isso já vai facilitar bastante a sua vida.

Para ver quais são as ACLs existentes no dispositivo (aplicadas a interfaces ou não), execute o seguinte comando:

Osiris# show access-lists

Standard IP access list permite_estacao_chefe

10 permit 192.168.1.10

Extended IP access list 100

10 deny tcp host 192.168.0.3 range 22 www any

Extended IP access list nega-http

Extended IP access list nega_http

1 permit tcp host 192.168.0.6 host 192.168.0.10 eq www

10 deny tcp host 192.168.0.6 host 192.168.0.254 eq www

Desta maneira, o comando irá listar todas as ACLs existentes no dispositivo. Se você quiser listar uma específica:

Osiris# show access-lists 100

Extended IP access list 100

10 deny tcp host 192.168.0.3 range 22 www any

Considerando que você queira ver apenas as regras da ACL 100. Porém, e se você tiver criado apenas ACLs nomeadas (named)? Este comando também te ajuda:

Osiris# show access-lists NomeDaACL

Assim, apenas a ACL cujo nome foi especificado na linha de comando será exibida para você.

Ok, com o comando show access-lists você consegue verificar todas as ACLs que existem no seu roteador. Mas como você descobre qual ACL está aplicada em uma determinada interface? Simples, com o seguinte comando:

Osiris# show ip interfaces NomeDaInterface

Entre vários outros detalhes, você verá uma linha similar à seguinte:

Outgoing access list is PermiteRH

Inbound access list is NegaOps

Depois de descobrir qual ACL está aplicada na interface, basta executar o comando show access-lists para ver o conteúdo da ACL e descobrir o que ela faz.

Conclusão

Como tudo que envolve Cisco, ACL é um assunto que pode ser tornar complicado muito facilmente e é praticamente inesgotável. O post cobriu uma parte bem básica para que você comece a trabalhar com elas e tenha base para ir se aprofundando conforme a necessidade apareça.

Ficou com alguma dúvida? Achou um erro? Deixe um comentário!

Não há posts relacionados a este!