Boas Praticas para Protecao de Roteadores e Switches

Introdução

Este artigo tem como proposta disseminar conhecimentos e boas práticas para a proteção de equipamentos roteadores e switches ("ativos de rede") das infraestruturas de provedores de acesso de Internet, em especial citando as situações e os mecanismos de mitigação correspondentes recomendados tanto pela indústria quanto pelos principais fabricantes para a proteção das infraestruturas de redes do provedor.

Durante a elaboração deste artigo eu poderia ter optado por ir diretamente ao ponto e citado os casos e ferramentas, mas resolvi detalhar bastante e buscar fornecer um aspecto absolutamente didático. Portanto a sua leitura será longa e produtiva, pois muitas informações bacanas estão disponibilizadas aqui com o propósito de transferir o melhor conhecimento possível. Espero que você curta a leitura deste artigo e que seu conteúdo seja bastante útil para o seu projeto de infraestrutura Ethernet/IP. Ah! Não se esqueça: participe das listas de discussão do Brasil Peering Forum!

Uma breve dissertação sobre a segurança da informação

Antes mesmo de falarmos de boas práticas, é necessário frisar que a segurança da informação é uma área absurdamente ampla e que permeia diversos componentes tecnológicos e processuais que se fazem presentes nas organizações nos dias atuais. "A força de uma corrente é tão boa quanto a de seu elo mais fraco" - esta é uma daquelas frases que fazem um sentido absurdo nas vidas dos profissionais que trabalham com Tecnologia da Informação e Comunicação. Simplesmente não há uma única ferramenta ou um pequeno conjunto de procedimentos ou ações que promoverá boa segurança geral; isto é impraticável! Um firewall de 1 milhão de reais na sua rede não te trará - sozinho - a devida segurança, assim como o blackholing de tráfego DoS por mecanismos específicos ou a mitigação de DDoS em sua própria infraestrutura ou realizando isto via um parceiro externo, embora fundamentais para a realidade dos provedores para incidentes de segurança da categoria "(in)disponibilidade", sem dúvidas, enfim, estas estratégias apenas atendem a algumas das diversas possibilidades de ocorrências de incidentes de segurança. Um único procedimento ou o emprego de alguns procedimentos apenas, por mais sofisticados que sejam, muito provavelmente não serão capazes de proteger o seu negócio contra uma magnitude de possibilidades envolvendo incidentes de segurança. E é bom você e o seu provedor ficarem atentos quanto a isto.

A segurança da informação, devido a sua natureza absurdamente ampla, profunda e complexa, precisa ser estudada minuciosamente e considerada adequadamente para toda a organização e seus componentes, os quais, por sua vez, incluem computadores, sistemas operacionais, os recursos e serviços disponíveis nestes sistemas, bancos de dados, infraestruturas de redes (se abríssemos um paralelo aqui, a gama de componentes, apenas na questão "redes", por si só, já seria um tema para uma dissertação de tamanho descomunal!), além do próprio ser humano, que é o principal e primeiro elemento da cadeia de riscos e de situações relacionadas aos incidentes de segurança. Dentre dezenas de outras áreas funcionais, sistêmicas, operacionais e processuais.

Se desenvolvêssemos conceitos sobre as quatro áreas primárias da segurança (Confidencialidade, Integridade, Autenticidade, e Disponibilidade), descobriríamos que, através de ações de assessment de segurança usando múltiplos procedimentos, frameworks e ferramentas, tais como uma análise qualitativa de riscos, dentre muitos outros, todo o nosso aparato tecnológico parece-se mais como um queijo suíço: repleto de "brechas", vulnerabilidades, e com alta probabilidade de ocorrência de problemas, e, em muitos casos, com alto impacto em termos de consequências. Toda empresa - pouco importa o seu tamanho ou porte - precisa analisar corretamente estas questões envolvendo as propriedades da segurança e os estados da informação: processamento, armazenamento, transmissão, e, ultimamente, os dados ou informações consumidas ou utilizadas, e por quais indivíduos, usando quais ferramentas e por quais métodos. As empresas precisam observar as medidas de segurança estudadas e em alinhamento com instrumentos e processos adequados. Dos instrumentos e processos, os quais ditam os rumos da governança da informação nestas empresas, temos, por exemplo, as políticas de segurança, os procedimentos, as tecnologias e ferramentas construídas e arranjadas em regime de compatibilidade e aderência do projeto técnico, das políticas supracitadas, e da governança da segurança como um todo, além dos múltiplos esforços de educação e treinamento de clientes, usuários, funcionários, colaboradores, terceirizados, etc., para fins de prevenção.

Entenda que este artigo não é um curso sobre segurança da informação (e nem me atreveria a fazer isto aqui!) e ao mesmo tempo não oferece um conjunto completo de recomendações que prevê todas as possibilidades e situações. Ao invés disto, este artigo disseminará conhecimentos e boas práticas que são bastante viáveis no ponto de vista de adoção ou implementação, e considerando uma diversidade interessante de situações que são um tanto específicas para a realidade dos provedores de Internet do Brasil. Ao adotar as práticas aqui recomendadas, o seu provedor experimentará um aumento substancial da segurança dos componentes participantes e afetados pelas proposições deste artigo. E, consequentemente, o seu provedor experimentará uma redução drástica de riscos e das probabilidades de sofrer incidentes de segurança sobre estas áreas funcionais aqui disseminadas.

Áreas de interesse deste artigo

Conforme citado anteriormente, este artigo não abordará todas as situações, mas promoverá boa dissertação sobre situações de risco e seus mecanismos de mitigação correspondentes. Estas situações e mecanismos estão categorizados conforme ilustrado a seguir:

Áreas funcionais com mecanismos de proteção propostos.

Conhecendo os tipos de tráfego, áreas sistêmicas e modelos de processamento e encaminhamento de pacotes

Entendo que este artigo ficará bem melhor se, antes de ir ao ponto e citar os cenários e ferramentas, eu buscar esclarecer alguns fundamentos sobre as arquiteturas de roteadores. Apresentarei aqui conceitos de funcionamento de roteadores em uma rede. Comecemos com uma melhor compreensão sobre os tipos de pacotes que percorrem uma infraestrutura.

OBS: caso o seu entendimento seja bem básico sobre como funciona o roteamento IP e as funções gerais de roteadores e switches, recomendo a leitura do seguinte artigo: Fundamentos de Roteamento para Provedores.

Esclarecendo os tipos de tráfego na perspectiva de roteadores

Pacotes do Plano de Dados

Representa todo o tráfego que que é gerado pelos usuários e que devem ser roteados pelo seu equipamento. Na perspectiva do roteador, o endereço IP de destino é para um serviço de trânsito, ou seja, o pacote não tem como destino final o próprio roteador. É o que melhor define o principal trabalho realizado por roteadores na rede, e não há muito o que citar aqui além do óbvio.

Pacotes do Plano de Controle (Control Plane)

Representa todo o tráfego que é produzido pelos próprios roteadores, particularmente, neste caso específico e exemplificado aqui, os pacotes oriundos dos processos de software correspondente aos protocolos de roteamento. Por exemplo, em uma rede onde o protocolo de roteamento interior for o OSPF, o qual por sua vez é transportado pelo próprio protocolo IP (número do protocolo é o 89), diversos tipos de mensagens são trocadas entre os roteadores OSPF através de suas adjacências ou vizinhanças. Por exemplo, pacotes Hello (Type 1), DBD (Type 2), Link-State Request (Type 3), Link-State Update (Type 4), Link-State Acknowledgement (Type 5). Ou seja, são pacotes produzidos por um processo OSPF de um roteador e que tem como destino o processo de software OSPF de outros roteadores, especificamente as adjacências diretamente conectadas. Outro exemplo clássico, o protocolo BGP-4, o qual é transportado pelo protocolo TCP na porta 179. O BGP-4 emprega pacotes tais como o Open (Type 1), Update (Type 2), Notification (Type 3), Keepalive (Type 4), Route Refresh (Type 5). Ou seja, os pacotes produzidos pelo processo BGP de um roteador são destinados a outros roteadores rodando o BGP-4, seja uma vizinhança interna (iBGP) ou externa (eBGP), diretamente conectados ou por multihop nestes dois tipos de vizinhanças.

Os pacotes produzidos pelos protocolos de roteamento em um roteador tem sempre como destino ou interesse outros roteadores rodando aquele mesmo protocolo de roteamento. O tráfego é classificado aqui como tráfego do plano de controle.

Há outros exemplos de pacotes do plano de controle, mas pretendo não estender-me muito além do necessário para concluir o artigo. Todavia, estes exemplos incluiriam o ARP e NDP (IPv6) para fins de descoberta de vizinhos, resolução de endereços IPv4 e IPv6 para endereços físicos, e como mecanismo de pré-computação de adjacências para posterior programação das estruturas de encaminhamento de pacotes do plano de dados dos roteadores. Outros exemplo de protocolos do plano de controle incluem mecanismos ou protocolos auxiliares para maximizar a disponibilidade da rede com o devido acionamento de uma convergência mais rápida dos IGP ou do BGP, o que seria o caso de um protocolo/serviço tal como o Bidirectional Forwarding Detection (BFD). Ou um protocolo para prover uma segurança adicional contra falhas de comunicação bidirecional em nível mais "físico", o que seria o caso do protocolo Unidirectional Link Detection (UDLD). Ou um protocolo para aumentar a disponibilidade da função de default gateway de usuários de uma VLAN (ex: HSRP, VRRP, GLBP). Até mesmo no caso do MPLS, temos protocolos tais como o Label Distribution Protocol (LDP) e o Resource Reservation Protocol for Traffic Engineering (RSVP-TE). Os pacotes BPDU do Spanning Tree Protocol (STP) são outros exemplos clássicos de tráfego do plano de controle.

Todos os exemplos citados acima são clássicos de pacotes do plano de controle. As duas ilustrações a seguir mostram a troca de pacotes entre dois roteadores com o protocolo de roteamento OSPF.

Pacotes do plano de controle: o pacote Hello do OSPF

Pacotes do plano de controle: os pacotes DBD, LSR, LSU e LSAck do OSPF

A seguir, uma ilustração demonstrando o funcionamento do protocolo BFD:

Pacotes do Plano de Gerenciamento (Management Plane)

São exemplos deste tipo de tráfego todos os pacotes oriundos de serviços de gerenciamento e que tenham como o destino o próprio roteador. Obviamente não são classificados com tráfego de gerenciamento na perspectiva de um determinado roteador se o endereço IP de destino destes pacotes não for, obviamente, o próprio roteador. Nestes casos, seria um pacote de trânsito comum

Há uma gama muito grande de protocolos e serviços que são comunicados entre administradores de rede e os roteadores para diversas funções necessárias nas questões de gerenciamento de configurações, falhas, diagnósticos, monitoramento, etc. Exemplos aqui incluem os protocolos Telnet, SSH, SNMP, TFTP e FTP (para transferir software e configurações), NTP, NetFlow, OAM (CFM, E-OAM, MPLS OAM) e tantos outros. Protocolos tais como o Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP) são outros dois exemplos de protocolos de gerenciamento, embora apresentem funções interessantes que viabilizam outras tecnologias necessárias para certos projetos (ex: divulgação da VLAN de Voz (voice vlan) para endpoints).

Assim como os pacotes de tráfego do tipo "plano de controle", os pacotes do plano de gerenciamento tem como destino processos de software em execução no próprio roteador. No entanto, o tráfego de gerenciamento para o roteador (e não o tráfego de gerenciamento de trânsito, onde o destino não é o próprio roteador) não tem relação com a manutenção das estruturas de comutação e de encaminhamento de pacote, exceto, claro, quando tratando-se de ações administrativas envolvendo a configuração de rotas e similares.

Exemplo do protocolo SNMP como tráfego do plano de gerenciamento

Pacotes do Plano de Serviços (Service Plane)

São pacotes gerados por serviços que podem operar exclusivamente por software ou contar com o auxílio de componentes de hardware especializado (CPU dedicada, ASIC, SDRAM...) para as suas funções e processamento, visando melhor desempenho e escalabilidade. Exemplos clássicos aqui temos tráfego de encapsulamento GRE e outras técnicas de tunelamento, além de tráfego IPsec e SSL, dentre outros exemplos. O MPLS L2VPN, apesar de estar mais próximo e alinhado com o tráfego de plano de controle (troca de prefixos e sinalização de labels a serem utilizados) não deixa de ter um "pé" nesta categoria de tráfego.

Outros protocolos e serviços bem conhecidos que podem ser representados ou categorizados como tráfego do plano de serviços incluem o PPPoE e o L2TP, além de outros. O PPPoE, solução bastante tradicional e utilizada pela maioria dos provedores de acesso de Internet do Brasil, é um exemplo bastante clássico e está demonstrado a seguir:

Ilustração exemplificando os procedimentos usados pelo PPPoE

Esclarecendo como o processamento de pacotes de cada tipo de tráfego é realizado pelos roteadores

A partir do momento que você passou a compreender os tipos de tráfego, ficará mais fácil explicar o trabalho que os roteadores realizam sobre os tipos de pacotes na questão "processamento".

É importantíssimo deixar bem claro que há muitas diferenças na forma em que os diversos modelos de equipamentos roteadores, de diversos fabricantes, realizam as funções que serão descritas a seguir. Mesmo quando lidando com equipamentos de um mesmo fabricante há muitas diferenças nas formas em que os pacotes são processados, sejam estes pacotes de trânsito, ou com interesse ao plano de controle ou ao plano de gerenciamento. No entanto, é possível "generalizar", pois estas funções de processamento existem em praticamente qualquer equipamento roteador.

Uma breve explicação sobre os planos de controle e de dados

Para que eu consiga elaborar melhor as explicações sobre o processamento de pacotes, receio ser necessário antecipar algumas informações complementares para agregar mais valor ao tema e esclarecer outras coisas. Para você compreender isto melhor, enquanto o plano de controle hospeda os processos de software referentes aos protocolos de roteamento, juntamente com suas respectivas tabelas e estruturas de dados (ex: OSPF tem a tabela de vizinhos e o LSDB. O BGP tem a tabela de vizinhos e a tabela (de rotas) BGP. O LDP mantém a tabela de labels (LIB). Etc.), além de outras estruturas de dados tais como a tabela ARP (o ARP cache) e a própria tabela de roteamento (RIB), além de muitas coisas que suprimirei por aqui, o plano de dados, por sua vez, possui informações mais "enxutas", específicas e otimizadas para as funções de encaminhamento de pacotes. A principal estrutura de dados mantida no plano de dados é a Forwarding Information Base (FIB) que aponta adjacências e interface de saída, juntamente com outras instruções necessárias para a reescrita de cabeçalhos L2 (ex: tag de VLAN, MTU, endereços MAC de origem e destino). E é justamente e geralmente na FIB onde ocorre o "roteamento" do pacote. Mas isto depende muito da plataforma, do vendor, e das tecnologias empregadas na concepção de arquitetura daquele equipamento, pois há várias técnicas de processamento de pacotes, por exemplo:

• Process Switching: todo o processamento de pacotes é realizado por interrupções de software
• Route Caching: o processamento do pacote sendo feito por software, mas com o reaproveitamento das instruções referentes à reescrita de cabeçalhos mantidas em memória, visando desonerar o processamento da CPU.
• Silicon Switching e Optimum Switching: primeiros esforços da indústria em tratar os pacotes em uma camada mais especializada. Proprietário ("vendor specific"), legado e não mais utilizado.
• Topology-based Switching:

Em outras palavras, em equipamentos de "classe", o processamento de pacotes se dá em hardware especializado e estas plataformas contam com excepcional separação sistêmica entre estes dois principais planos (controle e dados). Se você conseguiu entender ou absorver esta informação, estaremos bem sincronizados então sobre as explicações envolvendo o processamento de pacotes. Ah, a propósito, a ilustração a seguir exemplifica os planos de controle e de dados:

Em algumas plataformas de roteadores, todo o plano de controle é centralizado e fica hospedado em um módulo específico, tal como um módulo de supervisor e controle do tipo "Supervisor", ou "Route Switch Processor" ou "Route Processor". Mas há plataformas onde ocorre uma modularização e distribuição interessantes dos processos de software dos protocolos, onde os protocolos de roteamento ficam neste módulo RSP/RP, mas outros protocolos são "offloaded" para os próprios line cards do equipamento, tais como o ARP, BFD, ICMP das interfaces locais do line card, NetFlow, CFM, CDP, LLDP e outros.

Na maioria das plataformas do mercado o processamento de pacotes também é centralizado e representado por um módulo físico à parte ou componentes integrados. Mas há roteadores no mercado que fazem também a distribuição do plano de dados para os line cards, sendo que cada line card teria neste caso as suas próprias instâncias independentes de FIB e todo o resto necessário para processar o pacote. O encaminhamento de pacotes pode ocorrer em 1, 1,5 ou 2 estágios, mas isto varia muito de acordo com o equipamento em questão.

Como as estruturas de encaminhamento de dados (ex: RIB, mRIB, LIB) são definidas primeiro no plano de controle e, depois, publicadas no plano de dados (ex: FIB+ADJ) depende muito do modelo do roteador. No entanto, posso ilustrar talvez aqui como funcionaria numa plataforma Cisco ASR 9000 à título de curiosidade ou referência, e suprimindo as complexidades envolvidas nos diversos procedimentos empregados (Bulk Content Downloader (BCDL), mecanismos IPC como o Group Services Protocol (GSP) e seus FGIDs, NetIO, Management e Execution Agents (MA, EA), etc.):

Ilustração de componentes dos planos de controle e de dados de um roteador Cisco ASR 9000

Processamento de pacotes de trânsito

Retornando à linha de raciocínio original. O processamento de pacotes de trânsito idealmente deve ocorrer na área sistêmica denominada plano de dados ou data plane. Conforme citado anteriormente, o plano de dados hospeda as estruturas de encaminhamento de pacotes com disposição eficiente para a realização de ações de processamento (pipeline) de pacotes, sendo que, em equipamentos de classe "carrier grade", estas estruturas são sempre mantidas em silício especializado.

No entanto, não é porque as funções de encaminhamento de pacotes ocorrem no plano de dados que em 100% dos casos o processamento de pacotes ocorrerá no hardware ou no silício especializado (ex: um ASIC ou FPGA top). Há situações onde os pacotes precisam sofrer tratamento por interrupções de software, e forneço alguns exemplos aqui:

• Pacotes com TTL assinalados com "1", o que provocará a expiração do pacote em trânsito naquele roteador
  • Não somente o processamento tem que ser feito em muitos roteadores, não todos, por software aqui, mas, de qualquer forma, o router precisa gerar a mensagem ICMP Type/Code correspondente para sinalizar isto para o remetente do pacote, e isto também é feito por software.
• Pacotes fragmentados
  • Pois a fragmentação e remontagem dos pacotes é de fato feita por software.
• Pacotes com opções especiais (ex: IP Router Alert (RFC 6398)), indicando que os roteadores no meio do caminho devam inspecionar detalhadamente o pacote. O Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), e General Internet Signaling Transport (GIST) são exemplos de protocolos/serviços cujos os pacotes utilizam esta marcação no cabeçalho IP.
• Em muitas plataformas mais "low end", o logging habilitado sobre listas de controle de acesso (ACL) obriga todo o processamento do pacote a ocorrer por interrupções de software.
• Pacotes cuja adjacência (next hop e interface de saída) seja desconhecida.

Processamento de pacotes destinados ao próprio roteador

O processamento de pacotes oriundos de protocolos de roteamento tem como destino o próprio roteador, e isto é ainda mais verdadeiro ainda com os protocolos de roteamento interiores. Se o seu roteador receber um pacote do OSPF mas não tiver o OSPF habilitado naquela interface, o equipamento simplesmente descartará o pacote. Agora se a interface estiver habilitada para este protocolo, o pacote é aceito e encaminhado internamente pelo equipamento até ser recebido pela thread destinatária, o qual, por sua vez, validará as instruções e consumirá os dados daquele pacote. Um pacote de BGP, por outro lado, se o endereço de destino não for o próprio roteador o equipamento roteará o pacote normalmente como se fosse um pacote de trânsito, ou seja, diretamente pelo plano de dados e tudo mais. Agora, se o pacote do BGP tiver como destino o próprio roteador, o pacote, ao ser recebido pela interface, tratado pela NPU mapeada àquela interface, fará um "punt" do pacote para que ele percorra internamente o equipamento até a thread correspondente do processo BGP em execução lá no módulo de supervisão e controle (RSP ou RP).

Em algumas plataformas, todo o tráfego "for us", ou seja, destinado ao próprio roteador, é tratado neste módulo RSP ou RP centralizado. Já em outras plataformas (posso citar um exemplo aqui? Plataformas baseadas no Cisco IOS XR (ex: ASR 9000)), alguns pacotes "for us" serão encaminhados (punted) para os processos correspondentes no módulo RSP/RP (o caso do protocolo de roteamento e de gerenciamento) enquanto outros pacotes de protocolos tais como o ARP e o NetFlow, para exemplificar com estes, são processados por software diretamente no próprio line card, ou seja, o plano de controle e (parte) de gerenciamento são distribuídos nestes equipamento. Enfim, sugiro que você estude o (seu) equipamento de seu vendor para conhecer as miudezas de cada caso.

Defenda o seu equipamento: proteção contra ataques de negação de serviço

Considerando todas as explicações fornecidas anteriormente, está na hora de exemplificarmos algumas situações e citarmos algumas ferramentas clássicas para melhorar a segurança de seu próprio roteador.

Mitigação de ataques lançados contra o plano de controle do seu roteador com o policiamento de control plane

A situação:

Indivíduos mal intencionados procuram sabotar a CPU do seu roteador com o envio de múltiplas requisições (inválidas ou não) para os seus protocolos de roteamento. Ou seja, eles inundam o seu processo de roteamento com o envio de muitos pacotes, o que frequentemente resulta em instabilidades no seu plano de controle, indisponibilidade do equipamento e, consequentemente, da rede.

Alguns engenheiros de rede configuram ACLs específicas para a classificação do tráfego e as aplica nas interfaces de conexão externa para tentar mitigar este risco. Nada contra o emprego de ACLs e similares nestas interfaces, inclusive isto pode e deve ser feito para proteger a rede contra determinados tipos de tráfego para certos destinos. No entanto, este procedimento é pouco útil para a proteção do plano de controle, pois não conseguimos policiar os volumes de pacotes e dados chegando até os processos de software referentes aos protocolos de roteamento. É nesta hora que pensamos em uma solução ou ferramenta mais específica: o Policer de Plano de Controle.

O nome pode variar conforme o fabricante, mas o "Control Plane Policer" ou "Control Plane Policing" (CoPP e também o dCoPP) são ferramentas mais adequadas para a mitigação do risco indicado aqui nesta seção do artigo. Como exatamente o CoPP interage e funciona no seu equipamento, isto variará bastante conforme cada modelo ou tipo de roteador. Tentarei generalizar aqui ou talvez fornecer casos com plataformas específicas e bem conhecidas.

O CoPP é um recurso que permite o administrador da rede a gerenciar como os fluxos de tráfego serão tratados pelos processos de software do plano de controle, basicamente prevenindo que o alto volume de tráfego indesejado não vá saturar a CPU (do módulo RSP ou RP, por exemplo), o que afetaria a estabilidade da rede. A exaustão de recursos de uma Route Processor poderá trazer efeitos bastante indesejáveis tanto para a performance e disponibilidade do próprio equipamento quanto da rede como um todo. Não somente pacotes de protocolos de roteamento podem ser lançados em alto volume contra o control plane do seu equipamento: o mesmo poder ocorrer com pacotes destinado a serviços de gerenciamento e por uma variedade grande de protocolos e serviços, tais como SNMP, HTTP, SSH, Telnet, NTP, e outros. Ou seja, o CoPP acaba sendo bem útil para os tipos de tráfego "for us" de controle (protocolos de roteamento), gerenciamento (SSH, SNMP, etc.) e serviços (CDP, LLDP, GRE, IPsec e outros).

Como o CoPP funciona:

O CoPP faz a proteção do Route Processor do roteador através do tratamento dos recursos de processamento como entidade separada com a sua própria interface de entrada ("ingress interface"), vinculada justamente na "porta de entrada" do plano de controle. Ao invés de vincularmos uma ACL numa interface física, vincularemos uma policy mesmo numa interface lógica denominada control-plane, que policia todos os fluxos de tráfego que tem como destino apenas o módulo RP. Desta forma, o roteador não precisa ficar investigando todos os pacotes em trânsito, mas apenas aqueles que tem como destino um processo hospedado no módulo RP (ou seja, adjacências "punted" para o tráfego com interesse local).

Em termos de configuração, o CoPP é configurado de forma muito similar à uma política de QoS com a ferramenta de policiamento de taxa (police ou policing). Neste caso, configura-se as classes de tráfego, envolve as ACLs de classificação indicando os endereços IP de origem, organiza a policy autorizando volumes mais confortáveis vindos de endereços IP de origem confiáveis enquanto, ao mesmo tempo, punindo o tráfego de origem ilícita, o qual será descartado sumariamente no hardware e sem envolver qualquer interrupção de software para estes descartes. Exemplos de classes de tráfego de um CoPP típico:

• Routing: deverão pertencer a esta classe de tráfego pacotes oriundos de protocolos de roteamento, especialmente os de origem autorizada/confiável.
• Management: deverão pertencer a esta classe de tráfego pacotes destinados a serviços de gerenciamento habilitados no roteador, especialmente os de origem autorizada/confiável.
• Normal: aqui seriam classificados o tráfego geral esperado, exceto roteamento e gerenciamento, tais como mensagens ICMP Time-Exceeded, Echo-Request, Echo-Reply, Packet-too-big, Port-unreachable e outros, além de pacotes de GRE e outros.
• Undesirable: deverão ser classificados aqui todos os pacotes de tráfego claramente malicioso, tais como certos TCP RSTs, pacotes fragmentados (isto é, após você redefinir e revalidar o MTU na sua rede, pois você realmente não quer pacotes fragmentados no seu control plane...), e outros tipos de tráfego malicioso.
• Catch-All-IP: todo o resto que não tiver sido identificado nas classes anteriores será identificado aqui.

O CoPP ilustrado:

Ilustração do Control Plane Policing (CoPP)

Caso de estudo com o Control Plane Policing (CoPP) para mitigação de ataques contra o plano de controle em plataforma Cisco IOS

Neste caso de estudo, demonstraremos a configuração do CoPP em uma plataforma baseada no Cisco IOS (um roteador Cisco clássico, tradicional). Afinal de contas, seria bom fornecer um exemplo ou modelo, certo? Mesmo que seja de um vendor apenas, o mais importante é você conhecer que esta ferramenta existe e muito provavelmente pode estar disponível no seu equipamento não-Cisco.

No cenário a seguir, muito simples: um provedor (ISP) com estes roteadores em sua planta. A subrede iP representando o NOC/operação é o 10.254.254.0/24, e a subrede IP representando alguns serviços essenciais de segurança, DNS e autenticação (ex: TACACS+) é o 10.253.253.0/24. A rede IP que representa todas as interfaces Loopback é a 192.168.168.0/24, e a rede IP que representa as conexões /30 entre os roteadores é a 192.168.1.0/24. Vejamos como seria feita uma configuração sobre este cenário:

Exemplificando uma configuração de CoPP típica (parte 1)

Exemplificando uma configuração de CoPP típica (parte 2)

Algumas observações importantes com relação ao cenário/exemplo acima: 1) a ferramenta e toda a sintaxe, assim o "como funciona", é exclusivamente Cisco IOS. 2) as configurações das taxas de policing requer conhecimentos por parte do administrador, tais como os protocolos de roteamento e gerenciamento envolvidos e a modelagem da rede para estabelecer os volumes de tráfego estimados.

Caso de estudo com o de policiamento de plano de controle para mitigação de ataques contra o plano de controle em plataforma Cisco IOS XR (ex: ASR 9000)

O software Cisco IOS XR, que turbina plataformas tais como o Cisco ASR 9000, Cisco CRS-3 e CRS-X, Cisco NCS 540, Cisco NCS 5500, e outros modelos, em nada se assemelha ao Cisco IOS clássico/legado ou ao moderno e arrojado Cisco IOS XE (ASR 1000, ASR 920, ASR 903, switches Catalyst, e outros) no que diz respeito às "miudezas" e o funcionamento interno. São arquiteturas brutalmente distintas!

Para explicar como funciona um recursos como o CoPP num roteador Cisco ASR 9000, eu teria que antecipar algumas informações sobre a arquitetura deste equipamento; coisa bem rápida aqui:

1. O Cisco IOS XR Software não pode ser executado em qualquer roteador, no sentido que o hardware precisa ser feito para aquele software, e vice-versa. Conceito de "unha e carne".
2. A arquitetura do Cisco IOS XR Software é brutalmente modularizada e originalmente com uma abordagem POSIX. Tanto as configurações quanto as funções de encaminhamento de pacotes são distribuídas em todo o sistema:
   1. Não há uma "startup-config", um arquivo de configuração persistente "flat" contendo toda a configuração a ser carregada no equipamento durante o seu boot. A configuração persistente do IOS XR é composta por múltiplos arquivos em formato binário proprietário que, quando lançadas na memória durante o boot, são alocadas e possuem um formato de namespace de Unix (versões 5.x) e Linux (versões 6.x+). Se você não conhece ou não sabe o que é um namespace, seria algo similar ao Registry do Windows, só que muito melhor, claro. No entanto, o SysDB é particionado e distribuído em todo o sistema.
      1. O serviço que toma conta ou administra as configurações é o SysDB, e há três processos servidores dele: Shared (configurações globais do roteador, inclusive protocolos de roteamento e afins), Admin (configurações do Admin Plane, tais como process carving e placement, a parte energética, e coisas mais "físicas"), Local (configurações de um nó (ex: RSP, Line Card)).
      2. A configuração dos line cards é mantida pelo processo SysDB servidor dos line cards. Por exemplo, configurações de endereços IP, MTU, tag de VLAN, etc., são configurações mantidas e conhecidas apenas por aquele Line Card. Os demais módulos Line Cards e RSP/RP não conhecem estas configurações.
      3. Este conceito de particionamento e distribuição de configurações promove um princípio de escalabilidade massiva da plataforma para configurações em ambientes muito grandes, pois o módulo RSP só precisa deter configurações detalhadas de suas próprias portas e das configurações globais dos processos relacionados aos protocolos, enquanto cada line card só precisa conhecer e manter configurações detalhadas de suas próprias interfaces. Ou seja, uma distribuição do "peso" em todos os nós do sistema.
   2. Enquanto muitos dos roteadores no mercado possuem uma abordagem centralizada para as funções de processamento de pacotes, os quais são feitos em um módulo específico ou em componentes centralizados, uma plataforma com o IOS XR já possui uma abordagem distribuída para estas mesmas funções:
      1. O módulo RSP não precisa manter as tabelas de adjacências. As adjacências são sempre locais, e cada line card só precisa manter a sua tabela AIB referente às adjacências por interfaces que são locais ao próprio line card. E cada line card faz isto de forma independente. Ganha-se muito em escalabilidade.
      2. A maioria dos roteadores normalmente fazem um estágio de processamento de pacotes, enquanto roteadores baseados no Cisco IOS XR operam em dois estágios, em algo que chamamos de two-stage forwarding.

Um comparativo entre as duas abordagens através de uma ilustração talvez seja mais apropriado! Vejamos:

Comparativo entre arquiteturas de encaminhamento centralizado e distribuído

Você deve estar perguntando-se: "mas o que tem isto a ver com o foco do artigo?". Na verdade, não muito, exceto se você estiver interessado em saber como funciona um "CoPP" numa plataforma como o Cisco ASR 9000, pois aí, neste caso, faz todo o sentido explicar um pouco da plataforma!

Conhecendo o Local Packet Transport Services (LPTS)

Se eu citasse que o LPTS é o serviço de proteção do plano de controle de roteadores baseados no Cisco IOS XR Software, eu não estaria errado. No entanto, o LPTS faz bem mais que isto.

Enquanto o LPTS é melhor conhecido por sua habilidade em proteger e "blindar" o plano de controle de tráfego indesejado, o mecanismo é ao mesmo tempo um componente fundamental na infraestrutura do IOS XR e serve a múltiplos propósitos e funções. A origem do LPTS foi a necessidade de efetivamente gerenciar o tráfego enviado para o router em um sistema que possui uma arquitetura amplamente distribuída e com várias CPU ativas simultaneamente. Mas foquemos aqui na parte que diz respeito à proteção do plano de control. As principais funções do LPTS nesta questão:

1. Controlar o fluxo de recebimento pacotes fragmentados que tem como destino endereços IP do próprio roteador.
2. Controlar o fluxo de recebimento de pacotes oriundos de protocolos IGP.
3. Controlar o fluxo de recebimento de pacotes oriundos do protocolo BGP.
4. Fazendo o mesmo com relação a todo e qualquer protocolo (ex: LDP, RSVP, PIM, etc.) com destino ao próprio roteador.
5. Controlar o fluxo de recebimento de pacotes oriundos de protocolos de gerenciamento (ex: Telnet, SSH, SNMP, RADIUS, TACACS+), além de muitos outros (ex: NTP, CDP, LLDP, etc.).
6. Filtrar e policiar todo o tipo de tráfego destinado ao próprio roteador, o tráfego "for-us".

Ilustração do LPTS como mecanismo "CoPP" para um roteador Cisco ASR 9000

O LPTS já vem implementado, pronto mesmo, para a maioria dos projetos com este tipo de equipamento. Os valores/taxas padrão de cada policer do LPTS costumam a atender bem a uma diversidade muito grande de cenários e situações. No entanto, em casos específicos, você certamente terá que ajustar algumas destas policers para atender as suas necessidades. Por exemplo:

• Ajuste da quantidade de pacotes de requisições de ARP destinadas à pilha local de cada line card, pois o ARP roda diretamente no line card e os valores padrões talvez não atendam as necessidades de certos tipos de conexões externas (ex: IX em São Paulo tem altíssimo volume de tráfego ARP, e as policers padrão do LPTS podem ser inadequadas para lidar com isto).
  • Ainda na questão do ARP, outra situação: volume de tráfego ARP proveniente de domínios L2 muito grandes de uma L2VPN/Bridge Domain.
• Se há a expectativa de processamento de pacotes fragmentados em índices elevados, fatalmente você deverá ajustar os policers correspondentes. No entanto, idealmente, procure refazer o seu projeto de infraestrutura para acomodar melhor o tráfego sem que haja necessidades de fragmentação de pacotes.

Embora as ferramentas citadas aqui (CoPP/dCoPP e LPTS) sejam específicas de plataformas Cisco, fique atento: muito provavelmente o seu equipamento possui uma ferramenta ou recurso disponível para a mesma necessidade!