Quando sai de casa de manhã, (provavelmente) tranca as portas atrás de si. Num cenário normal, apenas as pessoas que têm as chaves para destrancar a sua porta devem ter acesso à sua casa. Fazemo-lo por razões de segurança. Da mesma forma, podemos querer controlar quem/quem tem acesso a diferentes partes da nossa rede e uma das formas de o fazermos é utilizando Listas de Controlo de Acesso (ACLs).
Neste artigo, faremos uma profunda mergulho nas ACLs, conforme aplicável ao controlo de acesso à rede. Iremos considerar a estrutura de uma ACL, como as ACLs são processadas, e também como aplicar ACLs configuradas. Além disso, para tornar este artigo tão prático quanto possível, consideraremos um estudo de caso onde configuraremos ACLs num dispositivo Cisco IOS. O conhecimento deste estudo de caso pode ser aplicado em dispositivos de outros fornecedores.
Nota: as ACLs não são úteis apenas para fins de filtragem; elas também encontram aplicação noutras áreas como a configuração de tradução de endereços de rede (NAT), combinando quais as rotas a anunciar/aceitar em protocolos de encaminhamento dinâmicos, encaminhamento baseado em políticas, e muitas mais. Além disso, as ACLs não se restringem à ligação em rede, pois são também utilizadas noutros sistemas, tais como sistemas de ficheiros para controlar o acesso a ficheiros/objectos.
Listas de Controlo de Acesso
O que é uma Lista de Controlo de Acesso?
Apenas como diz a frase, uma Lista de Controlo de Acesso (ACL) é uma lista que controla o acesso. Isto significa que, quando utilizada para controlo de acesso à rede, as ACLs determinam quais os anfitriões que podem (ou não podem) aceder a outros dispositivos/destinos. Isto é normalmente feito numa base por pacote, o que significa que cada pacote é verificado em relação à ACL para determinar se permite ou nega esse pacote.
Nota: as ACLs podem ser usadas para verificar vários campos num pacote incluindo a Camada 2 (por exemplo, endereços MAC), Camada 3 (por exemplo, endereços IPv4), Camada 4 (por exemplo, número de porta TCP), e assim por diante. Neste artigo, vamos restringir a nossa discussão à Camada 3+. Além disso, a maioria das ACLs são consideradas “stateless”, o que significa que cada pacote num fluxo é considerado por si só, ao contrário da filtragem stateful que mantém o registo do estado de uma ligação.
estrutura das ACLs
Como já dissemos, uma ACL é uma lista, o que significa que é uma lista de algo. Em termos técnicos, dizemos que uma ACL é uma lista de Entradas de Controlo de Acesso (ACEs), com cada entrada contendo critérios de correspondência para um determinado pacote.
Baseado nesta descrição, uma ACL pode ser dividida em duas partes principais:
- ACL Identificação que é tipicamente um nome ou um número. Como veremos mais adiante, as LCA também podem ser identificadas pelo seu tipo.
- um número de entradas de controlo de acesso que são tipicamente identificadas por números sequenciais.
Access Control Entries (ACEs)
ACEs constituem a maior parte de uma LCA com cada LCA contendo uma a tantas entradas permitidas por um determinado dispositivo. Sem prestar atenção ao tipo específico de uma LCA, uma LCA é composta do seguinte:
- Uma identificação que é normalmente um número de linha. Por exemplo, o primeiro ACE no ACL configurado num router Cisco IOS tem um número de linha de 10 por defeito; o seguinte tem um número de linha de 20; e assim por diante.
- Uma acção a ser executada para um pacote que corresponda à entrada. Normalmente, isto ou é “permitir” ou “negar”.
- Em alguns casos, o protocolo e a informação da porta a ser correspondida num pacote. Por exemplo, um ACE pode corresponder a todo o tráfego IP enquanto outro ACE corresponde apenas ao tráfego HTTP.
- A fonte a ser correspondida. Este é normalmente o endereço (IP) da fonte do pacote. Pode ser um único endereço, uma gama de endereços, uma sub-rede, ou mesmo qualquer endereço.
li>O destino a ser correspondido. Este é normalmente o endereço (IP) do destino do pacote. Pode ser um único endereço, uma gama de endereços, uma sub-rede, ou mesmo qualquer endereço.
Keep, tendo em mente que os componentes de origem e destino dos ACEs são subjectivos, dependendo da direcção do pacote. Considere o diagrama abaixo:
Existem dois cenários que podemos considerar da perspectiva do router, R1:
- se o PC1 inicia a comunicação com o PC2 (e.ping de PC1 para PC2), a fonte do tráfego é 192.168.1.100 enquanto o destino é 192.168.2.200.
li>Se o PC2 inicia a comunicação com o PC1 (por exemplo, ping de PC2 para PC1), a fonte do tráfego é 192.168.2.200 enquanto o destino é 192.168.1.100.
ACL Processing
Quando um pacote é verificado em relação a uma ACL, aplicam-se as seguintes regras de processamento:
- As ACEs numa ACL são verificadas por ordem de cima para baixo. Isto significa que o ACE #10 será verificado antes do ACE #20.
- Se um pacote não corresponder a um ACE, é verificado em relação à entrada seguinte no ACL.
- Se um pacote corresponder a um ACE, é verificado em relação a toda a ACL pára e a acção especificada no ACE correspondente é aplicada ao pacote.
- Se um pacote não corresponder a nenhuma entrada numa ACL, a maioria das implementações ACL irá negar/desligar este pacote porque existe uma entrada de negação implícita no final de cada ACL.
Vamos tomar um exemplo para compreender estas regras de processamento. Imagine que temos uma ACL com as seguintes entradas:
- Seq #1: Permitir ICMP de 192.168.1.100 a 192.168.2.200
- Seq #2: Negar ICMP de qualquer fonte a qualquer destino
- Seq #3: Permitir tráfego HTTP de 192.168.1.100 para qualquer destino
- Seq #4: Permitir tráfego HTTPS de 192.168.1.0/24 para qualquer destino
Q1: O que irá acontecer a um pacote de ping de 192.168.1.100 a 192.168.2.200?
A1: Como o ping se baseia no ICMP, o pacote de 192.168.1.100 a 192.168.2.200 será permitido porque corresponde ao ACE com o Seq #1.
Q2: O que acontecerá a um pacote de ping de 192.168.1.50 a 192.168.2.200?
A2: O pacote será verificado em relação ao LCA a partir da Seq #1. Como não corresponde a esta entrada, a próxima entrada (Seq #2) será verificada. Esta entrada nega o ICMP de qualquer fonte para qualquer destino. Uma vez que este é um pacote ping (i.e. ICMP) e a origem se qualifica como “qualquer” e o destino também se qualifica como “qualquer”, o pacote será negado.
Q3: O que acontecerá a um pacote HTTPS de 192.168.1.50 a 41.1.1.1?
A3: Este pacote não coincidirá com as três primeiras entradas da LCA. No entanto, irá corresponder à 4ª entrada porque é um pacote HTTPS, com uma fonte contida na sub-rede 192.168.1.0/24, e um destino que se qualifica como “qualquer”. Portanto, este pacote será permitido.
Q4: O que acontecerá a um pacote HTTP de 192.168.1.50 a 41.1.1.1?
A4: Este pacote não corresponderá a nenhuma entrada nesta LCA (apenas 192.168.1.100 é permitido enviar tráfego HTTP). Por conseguinte, será negado assumindo que a regra de “negação implícita” se aplica a esta ACL.
Aplicar ACLs
Apenas por ser ineficaz instalar uma fechadura na sua porta e sair de casa sem trancar a porta, configurar ACLs sem as aplicar é também inútil. Quando usadas para controlo/filtragem de acesso à rede, as ACLs são normalmente aplicadas em interfaces de dispositivos, dispositivos como routers, switches multicamadas, firewalls, e assim por diante.
Geralmente falando, uma ACL pode ser aplicada em duas direcções numa interface:
- Inbound: Isto aplica-se aos pacotes que entram na interface
- Saída: Isto aplica-se aos pacotes que saem da interface
Porque compreender que direcção aplicar LCA pode ser difícil, tomemos um exemplo. Na imagem abaixo, o PC1 está ligado à interface Fa0/0 de R1 enquanto o PC2 está ligado à interface Fa0/1 de R1.
Agora, imagine que queremos aplicar uma ACL em R1 de modo a que apenas o tráfego ping (ICMP) do PC1 para o PC2 seja permitido; onde podemos aplicar essa ACL?
- Primeiro, podemos aplicar essa ACL na interface Fa0/0 na direcção de entrada. Isto porque o tráfego de ping do PC1 para o PC2 entrará em R1 a partir da sua interface Fa0/0.
- Alternativamente, podemos aplicar esta ACL na interface Fa0/1 no sentido da saída. Isto porque o tráfego de ping do PC1 para o PC2 sairá do R1 através da sua interface Fa0/1.
Tip: Algo que aprendi há algum tempo atrás e que pode ajudar na compreensão das direcções de ACL é pensar em si próprio como um router. Levanta-te e estica os braços ao teu lado como se estivesses a formar uma cruz: o tráfego que entra dos teus dedos no teu corpo está a entrar enquanto o tráfego que sai do teu corpo para os teus dedos está a sair.
Case Study: ACLs em dispositivos Cisco IOS
Em dispositivos Cisco IOS, existem dois tipos de ACLs (no mínimo):
- ACLs padrão que correspondem apenas ao endereço de origem
- ACLs estendidas que podem corresponder numa combinação de protocolos, endereços de origem/destino, portas de origem/destino, opções, e assim por diante.
Nota: Cisco tem outros tipos de ACLs, tais como ACLs baseadas no tempo, ACLs reflexivas, ACLs dinâmicas, e assim por diante. Contudo, estas estão para além do âmbito deste artigo.
Independentemente do tipo, as ACLs nos dispositivos Cisco IOS podem ser nomeadas (por exemplo, “TESTACL”) ou numeradas (por exemplo, 100). Note que se usar ACLs numeradas, existem intervalos de números particulares para ACLs padrão e alargadas.
Ao especificar os endereços de origem e destino numa ACL na configuração do IOS da Cisco, usa-se algo chamado Máscara também conhecida como Máscara Inversa ou Máscara Wildcard. No nível básico, a máscara wildcard é apenas a máscara de sub-rede invertida, ou seja, 1s torna-se 0 e 0s torna-se 1. Por exemplo, a máscara correspondente de wildcard para a máscara de sub-rede 255.255.255.0 é 0.0.0.255.
Para a máscara de wildcard, 0 significa “deve combinar” enquanto que 1 é um bit de “não importa”. Por exemplo, uma rede 10.1.1.0 com uma máscara de wildcard de 0.0.0.3 irá corresponder ao tráfego dos endereços IP 10.1.1.1 até 10.1.1.3.
Nota: Também coincidirá com 10.1.1.1.0 mas como este é um endereço de rede, não é um endereço de origem válido num pacote.
P>Vamos utilizar a seguinte configuração de laboratório para o nosso estudo de caso:
P>Pode construir esta topologia em GNS3 ou Packet Tracer. Os endereços IP foram configurados em todas as interfaces e o EIGRP está a funcionar na rede de tal forma que existe conectividade entre todos os dispositivos:
R1:
R2:
R3:
Para testar a conectividade, vou pingar o R3 a partir das interfaces de loopback do R2:
Criar ACLs no Cisco IOS
Vamos agora configurar uma ACL no R1 de modo a que as seguintes condições sejam cumpridas:
- Tudo o tráfego ICMP a partir de 192.168.10.0/24 a qualquer destino deve ser permitido
- Todo o outro tráfego ICMP deve ser negado
- Todo o tráfego IP de 192.168.20.0/24 a 192.168.30.0/24 deve ser permitido
- Os dispositivos na rede 192.168.10.0/24 devem ser capazes de se ligar ao 192.168.30.1 host usando SSH; Telnet deve ser negado.
- todo o outro tráfego deve ser negado
Para configurar uma LCA num dispositivo Cisco IOS, usamos os seguintes passos:
- Definir a LCA usando um nome ou número. Tenha em mente que ACL nomeadas são mais fáceis de editar. O comando para configurar uma ACL nomeada é ip access-list < nome da ACL>
- Configurar ACEs sob a ACL usando a sintaxe básica: <protocolo>< rede de origem><source wildcard mask><destination network><destination wildcard mask><opções>/li>>li>Go sob a interface necessária e aplique a LCA usando o comando ip access-group <ACL name>
Por isso, a configuração para o conseguir em R1 é a seguinte:
ip access-list extended EXAMPLE_ACLpermit icmp 192.168.10.0 0.0.0.255 anydeny icmp any anypermit ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.1 eq 22!interface FastEthernet0/0ip access-group EXAMPLE_ACL in!
Há algumas coisas a notar sobre esta configuração:
- configurei uma ACL chamada “EXAMPLE_ACL”. Esta ACL é alargada porque preciso de corresponder em vários campos.
- Podemos usar a palavra-chave “any” para corresponder a qualquer endereço
- Podemos usar a palavra-chave “host” para corresponder a um único endereço
- Podemos especificar uma porta a corresponder usando palavras-chave tais como “eq” que significa igual a, “gt” que significa maior que, e assim por diante.
- Não neguei explicitamente todo o outro tráfego – a regra “negação implícita” no final de cada ACL Cisco negará qualquer tráfego que não seja correspondido por esta ACL
- Apliquei esta ACL na direcção de entrada na interface Fa0/0. Também poderia tê-la aplicado na direcção de saída na interface Fa0/1.
Verificar ACLs
P>Posso visualizar a configuração e estatísticas de ACL usando o comando mostrar ip access-lists ou mostrar access-lists:
p>
Nota a numeração: começa a 10 e cada nova entrada é adicionada abaixo da entrada anterior. Posso usar o comando mostrar interface ip para ver as ACLs aplicadas numa interface:
Nota: Pode aplicar até duas ACLs numa interface, uma em cada direcção.
Editando ACLs
No entanto, ao aplicar este ACL, criei um problema entre R1 e R2:
A relação EIGRP foi terminada porque os pacotes EIGRP estão a ser negados pela regra de “negação implícita” no final da LCA. Precisamos de resolver esta questão permitindo explicitamente os pacotes EIGRP no nosso ACL.
Aviso: É preciso ter cuidado ao editar uma ACL, uma vez que são adicionados novos ACEs no fundo da ACL (antes da negação implícita). Contudo, com ACLs nomeadas, pode especificar o número da linha onde pretende que seja colocada uma entrada.
No nosso caso, não importa onde adicionamos a entrada para permitir o tráfego EIGRP, uma vez que não há outra entrada que afecte esse tráfego antes da regra de negação implícita. Contudo, só para ver como adicionar entradas em qualquer linha de uma ACL, vamos adicionar a entrada “permitir qualquer entrada” na linha 5 da nossa ACL:
Cool! A nossa relação EIGRP está de volta.
Testar ACLs
P>Podemos agora ir em frente para testar o nosso ACL. Lembre-se que ao testar ACLs, deve não só testar o que deve estar a funcionar, mas também o que NÃO deve estar a funcionar.
Teste 1: Ping de 192.168.10.1 a 192.168.30.1 deve ser permitido por causa da entrada da linha ACL 10.
Podemos verificar os contadores na nossa ACL para ver se este tráfego foi correspondido pela ACL:
Test 2: Ping de 192.168.20.1 a 192.168.30.1 deve falhar devido à entrada da linha ACL 20.
Test 4: SSH de 192.168.10.1 a 192.168.30.1 deve ser permitido por causa da entrada de linha ACL 40.
Teste 5: Telnet de 192.168.10.1 a 192.168.30.1 deve falhar por causa da regra de negação implícita.
Podemos verificar as contagens na LCA para assegurar que o tráfego atinge realmente a LCA:
/p>
verificar a LCA para garantir que o tráfego chegou realmente até elesh2>Sugestões de ajuda para as LCA
Aqui estão algumas dicas para ajudar na sua implementação da LCA:
- Desde que a correspondência numa ACL seja interrompida uma vez que uma entrada seja correspondida, coloque as suas entradas mais específicas no topo da ACL e as mais genéricas abaixo.
Por exemplo, se colocar a:deny icmp any any
entrada antes da
permit icmp host 1.1.1.1 any
entrada, tráfego ICMP da 1.1.1.1 hospedeiro também será negado.
- Desde que as ACLs sejam pesquisadas de cima para baixo, deverá colocar o tráfego mais parecido com o que mais lhe agrada em direcção ao topo da ACL. Isto reduzirá o tempo de pesquisa e o consumo de recursos.
- Pode usar observações para tornar as suas ACLs mais legíveis, isto é, para que possa compreender o que faz uma determinada entrada e porque é que ela existe.
- Na medida do possível, aplique uma ACL o mais próximo possível da fonte de tráfego. Não vale a pena que o tráfego atravesse toda a rede apenas para ser negado. Note-se que esta dica pode não ser aplicável a ACLs.
- Se tiver dinheiro para isso, aplique uma ACL de entrada em vez de saída. Isto porque os pacotes já são processados (por exemplo, consulta da tabela de encaminhamento) antes de serem verificados através de uma ACL de saída. Porquê desperdiçar recursos de processamento apenas para mais tarde deixar cair o tráfego? Claro que há alturas em que isto não pode ser ajudado.
Conclusion
Isto leva-nos ao fim deste artigo onde analisámos as Listas de Controlo de Acesso em detalhe, concentrando-nos na forma como são utilizadas para filtragem da rede. Vimos que as LCA são constituídas por Entradas de Controlo de Acesso (ACE) que permitem ou negam tráfego com base em certos critérios.
Discutimos regras de processamento para LCA: de cima para baixo; parar uma vez feita uma correspondência. Também analisámos como as ACLs podem ser aplicadas a interfaces tanto na direcção de entrada como na direcção de saída. Finalmente, analisámos um estudo de caso sobre a implementação de ACLs em dispositivos Cisco IOS, juntamente com sugestões úteis.
0 comentários