Access Control Lists - ACLs

Tópicos que tem ocorrido com mais freqüência são aqueles relacionados com segurança, apesar de ser um assunto mais freqüente em exames mais avançados como o CCNP e o CCIE. Na questão abaixo, um exemplo básico com Access Control Lists (ACLs), retirado do livro “CCNA Study Guide, Sixth Edition”, do Todd Lammle:

“You configure the following access list:

access-list 110 deny tcp 10.1.1.128 0.0.0.63 any eq smtp

access-list 110 deny tcp any eq 23

int ethernet 0

ip access-group 110 out

What will the result of this access list be?

A. Email and Telnet will be allowed out E0.

B. Email and Telnet will be allowed in E0.

C. Everything but email and Telnet will be allowed out E0.

D. No IP traffic will be allowed out E0.”

Na questão, uma lista de comandos do roteador é apresentada, e pede-se o resultado da execução de tal lista num roteador hipotético. Aqui deve-se ter sempre em mente uma interpretação recorrente nas provas da Cisco: que o que não constar da relação de comandos, presume-se que foi omisso. Ou melhor, a lista de comandos começa exatamente com a primeira sentença de “access-list ...”, e termina com “ip access-group 110 out”. O trecho então não é parte de uma entrada do administrador de rede, mas sim uma sequência completa e indivisível de comandos.

Os comandos de access-lists na questão acima são no formato “extended”, ou seja, são no formato que começa com a definição da ação (“deny” ou “permit”), o intervalo de hosts de origem, o intervalo de hosts destino e, possivelmente, condições que especificam em que porta a restrição vai se impor. As listas extended são numeradas com identificadores de 100 a 199, e com elas é possível filtrar pacotes por campos IP de camada 3 e até alguns serviços de camada 4 ou maior (WWW, Telnet, SMTP, etc.), o que amplia o espectro de usos possíveis para as ACLs, como por exemplo mitigar ataques Denial-of-Service (DoS), DoS Smurfs, IP Spoofing, etc. É possível estabelecer regras que serão aplicadas especificamente a pacotes TCP com a flag SYN setada, por exemplo, o que serve de ajuda contra ataques de SYN flood. Certo, apenas “mitigar”, não necessariamente impedir tais ataques, dada a dificuldade em definir regras sobre grupos de pacotes suspeitos num universo tão grande de possibilidades de ataques. Mas a utilidade das ACLs ainda assim é muito bem vinda e quebra alguns galhos.

Quando é preciso definir regras que se apliquem a apenas um par de hosts, como a sentença “access-list 110 deny ip host 172.16.10.3 host 172.16.20.5”, por exemplo, que bloqueia pacotes IP com campo de origem 172.16.10.3 e destino para 172.16.20.5, a tarefa é imediata. Contudo, é mais comum, na definição das regras de ACLs, quando é necessário que sejam aplicadas regras a um intervalo de hosts numa sub-rede, pode-se recorrer aos wildcards. Vamos dizer que queiramos aplicar determinada regra ao conjunto de hosts nas sub-redes de 192.168.113.0 até 192.168.140.0. Primeiro, calcule quantas sub-redes existem entre os endereços anteriores; diminuindo 113 de 140 (140 – 113), obtemos 27. Agora é preciso achar uma potência de 2 que seja maior ou igual a esse intervalo; temos que 32 é maior que 27 (16 é outra potência de 2, mas é menor que 27), e portanto nos serve para esse propósito. Esse valor é 32 é o tamanho do bloco, e quando diminuído de 1, nos traz o endereço de wildcard. Nesse caso, temos que o endereço de wildcard para esse intervalo é 0.0.31.255. O terceiro octeto, que guarda informações das sub-redes onde serão aplicadas a regra de ACL, tem valor 31, representado um bloco de 32 (192.168.113.0 até 192.168.145.0). Esse intervalo é maior do que o que o intervalo que queremos, mas serve ao propósito. O quarto octeto contêm um valor de 255, que permite a presença de qualquer valor, e nos garante que todos os hosts nessas sub-redes sejam também contemplados com a regra ACL.

De volta à questão, a primeira sentença aplica a regra de que será descartado qualquer pacote SMTP (porta 25) com origem em quaisquer dos hosts em 10.1.1.128 até 10.1.1.192 (wildcard = 0.0.0.63, bloco igual a 64). A segunda regra descarta todos os pacotes com destino ao serviço de Telnet (porta 23). Logo a seguir, essas 2 regras são aplicadas à interface E0 (ethernet0) para saída (“out”), ou seja, em “post-routing”, após o pacote ter sido roteado localmente no roteador e estar prestes a ser encaminhado para a interface de saída, as regras são aplicadas. A princípio, até aí tudo bem, temos 2 regras, uma que nega totalmente serviços para a porta 23, e outra que nega serviço SMTP (porta 25) para um conjunto de hosts. A alternativa C parece convidativa, mas algo vai errado na lista de acesso: se era esse o fim almejado pelo administrador (negar pacotes para serviços portas 23 e 25), ele deveria ter incluído a regra “permit ip any” no final da lista de acesso, porque a última regra é “deny ip any”, o que faria com que qualquer pacote tivesse o repasse concedido pela interface ethernet0. Devido à omissão dele, a interface E0 vai perder comunicação com o mundo. Alternativa D é a correta.

Sub-redes e Roteadores

Uma questão do exame CCNA muito interessante, que resume muitos dos conceitos sobre as funções básicas dos dispositivos de roteamento e segmentação em sub-redes:

“A router receives a packet on interface 172.16.45.66/26. The source IP of the packet is 172.16.45.127/26 and the destination is 172.16.46.191/26. How will the router handle the packet?

A. The destination is a host on another subnet, so the router will not forward the packet.

B. The destination is a host on the same subnet, so the router will forward the packet.

C. The destination is a broadcast address, so the router will not forward the packet.

D. The destination is a network address, so the router will forward the packet.”

A princípio, percebemos que todos os endereços IP são /26, ou seja, os 2 bits iniciais do quarto octeto são usados para identificação de sub-redes (24 < 26 < 32, ou seja, quarto octeto), e os 6 restantes são usados para host, o que nos dá um total de 4 sub-redes (2 bits de rede, elevado a 2) e 62 hosts (contando os endereços reservados para a base da rede, e para o broadcast da respectiva sub-rede, teríamos um total de 64). Como o número de sub-redes é bastante restrito, convêm que listemos cada um desses intervalos, para averiguarmos as condições de chegada desse pacote:

172.16.46.0 à 172.16.46.63 (0-63)

172.16.46.64 à 172.16.46.127 (64-127)

172.16.46.128 à 172.16.46.191 (128-191)

172.16.46.192 à 172.16.46.255 (192-255)

A matemática básica para a enumeração desses intervalos de sub-redes é simples: basta obter o comprimento de cada intervalo, calculando o espaço reservado para os hosts no endereço base acima: ou seja, 6 bits denotam um espaço de representação de 64, então a primeira sub-rede iniciará no IP terminado em 0, e terminará no IP terminado em 63 (63 – 0 + 1 = total de 64). O endereço inicial da próxima sub-rede será o último endereço válido para a sub-rede antecedente mais 1, ou melhor, 172.16.46.64 (63 + 1), e o endereço final será 64 (endereço inicial) mais o número de hosts nesse intervalo (64, igual para todas as sub-redes), menos 1, porque começamos a numeração com 0, desde o primeiro subintervalo. E assim, prossegue-se até que todos os intervalos tenham sido listados.

A partir da lista de sub-redes que fizemos, percebemos que o endereço de destino 172.16.46.191 é um endereço de broadcast. O endereço de broadcast será sempre o último numa dada sub-rede (por isso mesmo, não contabilizamos esse endereço na atribuição de um host válido dentro de uma determinada sub-rede – ele será sempre reservado para broadcast). Ora, temos que os roteadores segmentam as redes em domínios de broadcast, e por isso, não perpetuam pacotes incidentes em suas portas que tenham um endereço de broadcast como destino (popularmente falando, endereços de broadcast não são roteáveis). A letra C é a resposta.

Uma observação: veja que o endereço fonte do pacote direcionado pelo roteador, pertence à mesma sub-rede da interface do roteador, ou seja, a sub-rede de 172.16.46.64 até 172.19.46.127 ( 64 < 66 < 127 ). O que aconteceria se isso não fosse verdadeiro, se o endereço fonte estivesse em um segmento de rede divergente da que a interface do roteador pertença?

OSPF - Open Shortest Path First

Mais uma questão nos moldes das que são encontradas no exame CCNA, só que dessa vez envolvendo algoritmos de roteamento entre roteadores:

On the topic of the OSPF hello protocol; which of the statements below are true?
(Select two answer choices)
A. The OSPF Hello protocol provides dynamic neighbor discovery.
B. The OSPF Hello protocol detects unreachable neighbors in 90 second intervals.
C. The OSPF Hello protocol maintains neighbor relationships.
D. The OSPF Hello protocol negotiates the correct parameters between neighboring
interfaces.
E. The OSPF Hello protocol uses timers to elect the router with the fastest links at the
designated router.
F. The OSPF Hello protocol broadcast hello packets throughout the internetwork to
discover all routers that are running OSPF.


Resposta: A, C
O protocolo Hello do OSPF (Open Shortest Path First) serve como um meio de estabelecer as relações de vizinhança entre roteadores. É por meio desse tipo de pacote que se torna possível reconhecer potenciais roteadores numa vizinhança, e que poderão ser reconhecidos como "Neighbor Router", "Designated Router", ou "Backup Designated Router", e a partir dos quais serão construídas as listas de adjacências, de onde serão escolhidas as melhores rotas baseadas nos custos das interfaces de saída do roteador. O Hello serve tanto para estabelecer as vizinhaças, como também para mantê-las ativas, sempre que possível e para que rotas que se tornaram inválidas possam ser removidas. Além do protocolo Hello, o OSPF trabalha em conjunto com mais 4 mensagens: Database Description, Link State Request, Link State Update, Link State Ack.
A letra B se refere a um timer de 90 segundos, que não é utilizado pelo OSPF. Apesar disso, é necessário que o timing entre os pacotes Hello subsequentes estejam em sincronia, caso contrário não seria possível relações de vizinhança. (o OSPF usa algo com uma variante do "round-trip time", encontrada no TCP para descobrir de forma ativa quando um envio de pacote não chegou ao destino, e possivelmente não vai ser retransmitido). A letra E é falsa, porque o Hello não serve para identificar quem dos roteadores vizinhos possam estar usando ou não OSPF.