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: que é a base de tudo aquilo que os roteadores mais sofisticados utilizam atualmente. Esta modalidade de switching path implementa uma separação bem legítima entre os planos de controle e de dados, e as funções de encaminhamento de pacotes, assim como todo o pipeline de processamento de pacotes, se dá nesta área sistêmica, que é bastante especializada. Para efeitos comparativos ou referências, nas plataformas Cisco seria o Cisco Express Forwarding (CEF).

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" (RSP), "Route Processor" (RP), ou "Routing Engine" (RE). 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/RE, mas outros protocolos são "offloaded" para os próprios line cards do equipamento, tais como o ARP, BFD, ICMP, 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, tais como uma "Forwarding Engine" (Juniper), Embedded Services Processor (ESP, do Cisco ASR 1000), dentre outros casos. 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 os pacotes. 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 exatamente as estruturas de encaminhamento de dados são definidas primeiro no plano de controle (ex: RIB e LIB) e, depois, publicadas no plano de dados (ex: FIB/LFIB+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). 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 terá que ser feito por software em muitos roteadores, não todos, mas o roteador precisará também gerar a mensagem ICMP Type/Code correspondente para sinalizar isto para o remetente do pacote, e isto também será 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

Se o seu roteador receber um pacote de OSPF mas não tiver o OSPF habilitado naquela interface por onde o pacote foi recebido, 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, RP ou RE).

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 tais como o SSH, SNMP e HTTP) enquanto outros pacotes de protocolos tais como o ARP, ICMP e o NetFlow, para exemplificar com estes, são processados por software diretamente no próprio line card, ou seja, os planos de controle e (em 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ões externas 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 sature a CPU (do módulo RSP/RP, por exemplo), o que afetaria a estabilidade da rede. A exaustão de recursos de uma Route Processor ou Route Engine 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-se as ACLs de classificação indicando os endereços IP de origem e, finalmente, organiza-se 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 projeto 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 a 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 aqui é 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 LPTS para a mitigação de ataques contra o plano de controle de plataforma baseadas no 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 recurso 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. Em primeiro momento, o Cisco IOS XR Software não pode ser executado e não está disponível em qualquer roteador da Cisco, no sentido que o hardware precisa ser construído para aquele software, e vice-versa. Conceito de "unha e carne".
2. A arquitetura do Cisco IOS XR Software é drasticamente 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 apresentam 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, grosseiramente citando aqui, ao Registry (registro) do Windows. 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 uma interface tais como endereços IP, MTU, tag de VLAN, etc., são configurações mantidas e conhecidas apenas pelo Line Card desta interface. 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 controle. 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 de fábrica 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!

Mitigação de ataques lançados diretamente contra os protocolos de roteamento em execução no seu roteador

A proteção do plano de controle abordada no módulo anterior não anula a necessidade de adoção de mecanismos de segurança sobre os protocolos de roteamento, e vice-versa. Lembre-se do que foi dito no início do artigo: a segurança da informação tem uma natureza bastante modularizada na questão das ferramentas e recursos que devem ser observados para a redução de riscos e o aumento da proteção dos componentes desejados.

Neste contexto de proteção contra situações indesejáveis sobre os seus protocolos de roteamento, elencarei algumas das principais situações e ferramentas de mitigação correspondentes:

• Autenticação dos pacotes dos protocolos de roteamento interiores (IGP)
• Limitação de rotas IGP recebidas de um cliente em uma VRF
• Autenticação dos pacotes dos protocolos LDP e RSVP-TE
• Adoção das práticas discutidas pelo RFC 7454 / BCP 194 para proteger o BGP-4, o seu AS, e boa parte da Internet. Exemplos de iniciativas aqui incluem:
  • Autenticação dos pacotes do protocolo de roteamento BGP-4
  • Implementação do Generalized TTL Security Mechanism (GTSM) para o BGP-4
  • Limitação de prefixos recebidos de clientes para o BGP-4
  • BGP Route Flap Dampening
  • Políticas de roteamento com foco na segurança, evitando anúncio e recebimento de bogons e vazamento de rotas (route leaks)
• Complementar a segurança do seu BGP com base nas práticas discutidas no Mutually Agreed Norms for Routing Security (MANRS)

Autenticação dos pacotes dos protocolos de roteamento interiores (IGP)

Como boa prática, devemos proteger os protocolos de roteamento interiores contra a injeção de informações maliciosas. Há situações onde o indivíduo mal intencionado direciona pacotes para o seu protocolo de roteamento contendo instruções "válidas" que permitissem a formação de uma vizinhança ou adjacência, por exemplo, endereço IP mesma subrede, Area ID, e outros. A partir deste ponto, o equipamento ilícito ou não autorizado passaria a gerar anúncios que pudessem comprometer o plano de controle da sua rede, tais como o envio massivo de informações que saturassem o processamento dos equipamentos ou ainda o envio de informações que, após a computação por parte dos equipamentos, provocassem indisponibilidade na rede por meios de blackholing do tráfego.

E o procedimento de mitigação é absolutamente muito simples, fornecendo aqui um caso com o protocolo de roteamento OSPFv2.

O OSPFv2 suporta dois tipos de autenticação (type 1 - simple password (não recomendado), type 2 - MD5). A autenticação pode ser habilitada para todas as interfaces em uma Área, ou todas as interfaces e em todas as áreas OSPF de um roteador ABR, por exemplo, ou então habilitado interface por interface. Se o seu roteador suportar o gerenciamento de chaves via mecanismo similar a um "key chain", recomendamos este método para que você possa mais facilmente fazer o gerenciamento e troca periódica de chaves, e até mesmo automatizar este procedimento sem esforços.

É importante frisar que numa autenticação MD5 a senha pré-compartilhada entre dois roteadores não é "divulgada" no pacote do OSPF, apenas o hash é fornecido, o qual deverá ser matematicamente computado quando o roteador receber um pacote do OSPF. Ou seja, bastante seguro.

No caso do OSPFv3 (IPv6) o procedimento também existe e para o mesmo propósito ou finalidade. No entanto, os métodos são diferentes, pois o OSPFv3 implementa o IPsec conforme definido pelo RFC 4552 (Authentication/Confidentiality for OSPFv3) e, posteriormente, o OSPFv3 Authentication Trailer, conforme especificado pelo RFC 7166 (Supporting Authentication Trailer for OSPFv3).

O não cumprimento dessas recomendações expõe o seu backbone OSPF contra situações tais como:

• Ataques de eavesdropping, ou seja, o clássico Man-in-the-Middle
• Loops no roteamento da sua rede, e o fatal blackholing de grandes proporções de tráfego
• Falhas na convergência das tabelas de roteamento, provocando indisponibilidade de toda a rede.

Confira uma relação mais completa de situações no OSPF Security Vulnerabilities Analysis draft-ietf-rpsec-ospf-vuln-02.txt

Limitação de rotas IGP recebidas de um cliente em uma VRF

Em cenários de L3VPN, por exemplo, que emprega o Virtual Routing and Forwarding (VRF), as quais são, essencialmente, instâncias virtualizadas dos planos de controle e de dados por cliente/assinante, você realmente não tem que controlar ou não deve controlar quais anúncios aquela VRF receberá, pois tratam-se de redes de clientes e não suas. No entanto, como boa prática, é recomendado você estabelecer um limite confortável acerca de quantas rotas poderão existir na tabela de roteamento (RIB) daquela VRF; um limite que não prejudique o cliente e que ao mesmo tempo possa proteger o seu equipamento e grandes partes da sua rede contra atividade maliciosa originada a partir da rede interna do seu cliente.

Imagine um incidente de segurança na rede do seu cliente e que promove um aumento absurdo do LSDB (caso a sua relação PE-CE seja com o OSPF). Uma vez na sua VRF, a sua instância de OSPFv2 redistribuirá estas rotas OSPFv2 para o BGP-4, converterá estes prefixos BGP-4 da VRF para endereços VPNv4, e exportará estas rotas para outros roteadores PE do seu backbone poderem importar as rotas VPNv4 para as VRFs destinatárias correspondentes. Já imaginou? Diversos roteadores PE da sua rede podem ser severamente afetados e isto prejudicará muitos clientes que não tem qualquer relação ou participação com este problema!

Autenticação dos pacotes dos protocolos LDP e RSVP-TE

O protocolo Label Distribution Protocol (LDP) é usado para alocação e distribuição de labels em uma rede MPLS, assim como, também, em cenários de L2VPN MPLS conforme a implementação do draft Martini (LDP direcionado para sinalização de labels de VPN), referenciado no RFC 8077 (Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)).

Já o protocolo Resource Reservation Protocol for Traffic Engineering, conforme descrito no RFC 3209 original, e atualizado pelo RFC 5151 (Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions), é utilizado para fins de engenharia de tráfego com o MPLS, além de outras extensões para funções adicionais.

Ambos os protocolos desempenham uma função importantíssima no backbone MPLS dos operadores de telecomunicações e na maioria das redes dos provedores de acesso de Internet. Portanto é fundamental protegermos ambos os protocolos contra situações bastante indesejáveis.

Se comparado a uma infraestrutura de encaminhamento de pacotes puramente baseada no IP, onde os prefixos citados como endereços IP de destino são consultados contra uma tabela de encaminhamento de pacotes (ex: FIB), com alta possibilidade de haver spoofing destes endereços IP em uma rede de provedor, o MPLS é tranquilamente mais seguro neste sentido. O spoofing de MPLS labels é virtualmente impossível de ocorrer, desde que você autentique os pacotes LDP para as sessões ou vizinhanças entre os roteadores do provedor.

Uma vez que os enlaces de comunicação de dados na última milha (que conectam os roteadores CPE) não participam do MPLS, os pacotes provenientes de clientes não são consultados contra as estruturas de comutação baseadas em labels. Ou seja, o MPLS é uma tecnologia "core-facing" apenas, exceto em cenários InterAS ou Carrier Supporting Carrier (CsC). Isto simplifica bastante as ações requeridas para proteger o protocolo LDP em sua rede MPLS.

A autenticação do LDP deve ser feita para evitar problemas com o plano de controle. E isto é uma configuração muito simples com suporte ao hashing por MD5.

Já a autenticação do RSVP-TE, tão simples de implementar quanto a do LDP, está descrito no RFC 2747 (RSVP Cryptographic Authentication) e RFC 3097 (RSVP Cryptographic Authentication -- Updated Message Type Value).

O não cumprimento destas recomendações expõe o seu backbone MPLS contra as seguintes situações e riscos:

• Ataques de negação de serviço (DoS)
  • Manipulação não autorizada de mensagens do MPLS:
    • O MPLS emprega quatro tipos de mensagens: Discovery, Session, Advertisement, Notification.
    • A formação de uma vizinhança não autorizada (Discovery e Session) poderá ser o início do caos na sua rede.
    • O anúncio de informações incorretas sobre labels (Advertisement) poderá ser desastroso para o funcionamento de seu backbone.
    • A manipulação e processamento de mensagens de notificação (Notification) poderá ser desastroso para o seu backbone MPLS.
  • Exaustão da tabela de labels (LIB) dos roteadores MPLS do seu backbone.
    • Outra medida útil aqui, além da questão da autenticação, é permitir a alocação e distribuição de labels apenas referentes ao seu bloco IP de endereçamento das interfaces Loopback e no comprimento de host-routes, pois a maioria dos projetos MPLS realmente só precisa de labels para comunicação do roteamento recursivo do BGP. Mas cada caso é um caso; verifique o seu projeto.
  • Formação de loops de roteamento no backbone MPLS.

O RSVP-TE também possui os seus próprios desafios nesta questão de segurança, e é importante autenticar seus pacotes com os mecanismos próprios. Este protocolo emprega uma quantidade razoavelmente grande de tipos de mensagens, mas podemos categorizá-las em quatro tipos: Path, Resv, PathTear, ResvTear, PathErr, ResvErr, ResvConfirm

Você certamente não gostará nem um pouco de experimentar em sua rede modificações maliciosas de pacotes do LDP ou do RSVP-TE!

Autenticação dos pacotes do protocolo de roteamento BGP-4

Assim como devemos fazer para a autenticação dos pacotes dos protocolos de roteamento IGP, e para os protocolos LDP e RSVP-TE, quando utilizados, o protocolo de roteamento BGP-4 também suporta mecanismos confiáveis para a autenticação de seus pacotes. E devemos, sim, configurar a autenticação dos pacotes do BGP-4.

Há uma diversidade de situações de alto risco envolvendo a segurança do BGP-4 de seu roteador, e muitas delas conseguimos sanear com o uso da autenticação por MD5.

Na verdade, você deve ser bem mais amplo que simplesmente configurar a autenticação para o BGP-4: você deve observar as áreas e mecanismos citados pelo RFC 7454 (BGP Operations and Security).

Ou seja, a segurança do BGP depende mais que da autenticação, do uso do GTSM (que será discutido logo a seguir), e da limitação de rotas recebidas de clientes. Conforme o referido RFC, você deverá estar atento e projetar modificações no seu BGP-4 para as seguintes áreas:

• Proteção do BGP Speaker e das sessões BGP.
• Adotar políticas de roteamento consistentes para o BGP, e fazendo isto não apenas para selecionar caminhos e influenciar o tráfego do seu AS, mas para proteger o seu AS e outros AS, consequentemente de boa parte da Internet, contra anúncios bogons.

Portanto, certifique-se de observar as áreas de interesse mencionadas no RFC 7454 / BCP 194, além das práticas discutidas no MANRS, e proteja o seu BGP!

Implementação do Generalized TTL Security Mechanism (GTSM) para o BGP-4

É um mecanismo bastante recomendado para a segurança das sessões eBGP, também conhecido pelo nome de TTL Security Check, conforme BGP TTL Security Hack (BTSH).

O que você precisa entender sobre o TTL Security Check e como funciona:

Muitos engenheiros de redes configuram as suas sessões EBGP com autenticação MD5, inclusive recomendei isto há pouco neste mesmo artigo! Outros, nem isso. Em ambos os casos, o que deveria ser um mecanismo de proteção contra tentativas de sessões não autorizadas na verdade pode acabar sendo um “tiro no pé”. Por que? Porque indivíduos mal intencionados podem gerar milhares e milhares de pacotes BGP direcionados para endereços IP do roteador de Internet do seu provedor, e estes pacotes contendo hashes inválidos de MD5. Obviamente estes pacotes falharão e serão descartados pelo roteador, justamente pelo fato do MD5 estar incorreto, só que, no entanto, este procedimento é executado por interrupção de software. A vulnerabilidade aqui está na questão de aumento de processamento do roteador com potencial para uma negação de serviço. Ou seja, conforme citado anteriormente, o que deveria ser um mecanismo de proteção acaba sendo ao mesmo tempo um componente vulnerável.

A proposta do TTL Security Check é um tanto interessante: configuramos as sessões EBGP com um diâmetro específico, o qual deverá estar assinalado no campo TTL dos pacotes IP recebidos. O procedimento realiza a validação diretamente no cabeçalho IP e não na mensagem BGP autenticada pelo hash MD5, o que, comparando esforços computacionais, é bem menos intenso/oneroso no caso do TTL Security Check do que na computação do MD5 hash. Isto significa que o roteador gastará bem menos tempo validando o diâmetro do campo TTL. E, dependendo da plataforma, este mecanismo é acionado diretamente no hardware de um Line Card, ou seja, sem realmente qualquer envolvimento de interrupções de software.

Por que o TTL Security Check é eficiente? Bom, praticamente tudo no protocolo IP é “spoofável”, mas o spoofing do campo TTL do cabeçalho IP é muito difícil, literalmente impraticável. Suponhamos que você configure a sessão EBGP (após confirmar o diâmetro com o vizinho, se é uma sessão direta ou uma sessão EBGP Multihop de “n” saltos) informando que no campo TTL deverá constar “254 saltos restantes”, do contrário o pacote IP será sumariamente descartado: como um hacker lá da Rússia, China ou Índia conseguirá forjar um pacote IP com este diâmetro de 254 saltos restantes do campo TTL, se, a cada salto de caminho/roteador entre ele e o seu provedor haverá o decréscimo de “1” do campo TTL? Ou seja, impossível. Portanto o GTSM ou TTL Security Check é uma ferramenta muito interessante para proteger as suas sessões BGP.

Hardening das plataformas de roteadores e switches

A segurança do próprio sistema operacional do roteador ou do switch é indispensável para que sejam evitadas situações tais como:

• Impedir que o seu roteador forneça informações que possibilitem o mapeamento da sua infraestrutura para um indivíduo mal intencionado.
• Impedir que o seu roteador seja desabilitado ou sofra um ataque de negação de serviço.
• Impedir que o seu roteador seja configurado por um indivíduo não autorizado, e que esta configuração possibilite uma variedades de ações ilícitas (mineração de criptomoedas, eavesdropping, etc.).
• Impedir que o seu roteador não seja utilizado como plataforma de ataque contra a sua rede interna e a de clientes.
• Impedir que o seu roteador não seja utilizado como plataforma de ataques contra alvos externos.

Dentre as práticas que são recomendadas aqui, temos algumas coisas um tanto óbvias. Vejamos:

Desabilitar serviços desnecessários

Muitos equipamentos hospedam serviços que não estão sendo usados por você. Como prática geral da segurança da informação, tudo aquilo que você não estiver precisando deverá ser desabilitado por completo. Cada serviço que permitir uma comunicação pela rede pode conter ou apresentar vulnerabilidades que, uma vez comprometidas, podem trazer sérios incidentes de segurança para o seu ambiente.

Identifique todo e qualquer serviço que não seja necessário e simplesmente desabilite o serviço. Exemplos aqui incluem o servidor HTTP interno do roteador, além de coisas bem miúdas em muitos casos. Tem um caso conhecido de um protocolo chamado TP-Link Device Debug Protocol (tddp) que apresentou múltiplas vulnerabilidades ao longo dos anos, afetando milhares de usuários domésticos. Roteadores Cisco legados e de classe corporativa por muitos anos tiveram habilitados por padrão uma série de protocolos e serviços completamente inúteis para as necessidades atuais, inclusive aqueles bizarros serviços "small udp servers" (ex: echo, chargen, discard, etc.), fora serviços tais como source routing, PAD, bootp, e outros.

Independentemente do vendor, certifique-se de estudar a documentação do seu equipamento, realize testes de varredura de portas abertas, e proceda com a desabilitação de tudo aquilo que não for necessário.

Ajustar as configurações dos serviços necessários

Dissertarei nesta seção de forma mais objetiva.

• Precisa de SNMP? Ótimo (e óbvio que sim!).
  • Opte pelo SNMPv3.
    • O SNMPv3 implementa mecanismos de integridade, os quais asseguram que os pacotes não foram modificados em trânsito.
    • O SNMPv3 implementa mecanismos de autenticação seguros, assegurando a autenticidade do remetente da mensagem.
    • O SNMPv3 implementa mecanismos de confidencialidade, ou seja, as mensagens são criptografadas.
  • Caso não possa adotar o SNMPv3 agora, por algum motivo:
    • Não utilize o SNMPv1. Neste caso, opte pelo SNMPv2c.
    • Não utilize uma Community de "Write". Apenas Read. As mensagens do SNMPv2c não são criptografadas. Se algum indivíduo capturar pacotes na rede ele conseguirá descobrir a string da sua community de "write", e o caos estará instalado.
  • Independente do "sabor" do SNMP adotado, configure uma lista de controle de acesso (ACL) e especifique exatamente quais endereços IP de origem podem comunicar-se com o seu equipamento por SNMP. Esta ACL deverá estar vinculada ao próprio serviço SNMP.
• Precisa do serviço HTTP do roteador? Ótimo.
  • Não utilize HTTP. Utilize apenas o HTTPS.
  • Configure uma lista de controle de acesso (ACL), indicando exatamente quais endereços IP de origem podem comunicar-se com o seu roteador por este protocolo HTTPS. E vincule esta ACL para o serviço HTTPS.
• Precisa do Network Time Protocol (NTP), ou do Precision Time Protocol (PTP), ou do Synchronous Ethernet (SyncE), ou até mesmo de todos estes para o seu projeto?
  • Consulte as documentações necessárias para ajustar estes serviços de forma que os cenários fiquem bem seguros. Não teria como descrever estas questões aqui neste artigo. Há diversos mecanismos que devem ser observados para a utilização destas tecnologias/protocolos.
  • Configure listas de controle de acesso (ACL) para identificar quais serão as origens confiáveis para a troca de mensagens com estes protocolos com o seu roteador, fazendo o vínculo destas ACLs diretamente para estes serviços.
• Estes são apenas alguns exemplos. Fique atento quanto a outros protocolos e serviços necessários no seu equipamento.

Neste quesito de segurança dos serviços de gerenciamento por SSH, Telnet, SNMP e HTTP, em algumas plataformas, além das ACL vinculadas aos próprios serviços, há mecanismos de segurança adicionais que podem descartar tráfego não autorizado diretamente na NPU, lá no plano de dados. É o caso do recurso Management Plane Protection (MPP) de plataformas Cisco IOS XR. Verifique se o seu equipamento possui recurso similar. E não seria mau negócio modularizar a segurança destes serviços com a combinação e escalonamento destas estratégias e ferramentas!

Adotar mecanismos adicionais para a proteção contra protocolos e serviços naturalmente vulneráveis

Alguns protocolos e serviços são realmente muito indispensáveis em diversos projetos, mesmo sendo protocolos bastante vulneráveis contra uma variedade de situações. Cito alguns exemplos aqui:

• Dynamic Host Configuration Protocol, o famoso protocolo DHCP.
  • Estude e implemente mecanismos de DHCP Snooping para evitar ataques do tipo DHCP starvation + eavesdropping com a inserção de servidores DHCP não autorizados.
• Address Resolution Protocol, o ARP.
  • Estude e implemente mecanismos tipo Dynamic ARP Inspection (DAI) ou nome/tecnologia similar empregada pelo seu equipamento para coibir diversos tipos de incidentes, dentre os quais incidentes concebidos por Man-in-the-Middle, concebidos com spoofing de mensagens ARP e o envenenamento das tabelas ARP dos equipamentos e computadores.
• Spanning Tree Protocol, o protocolo STP.
  • O seu equipamento certamente deve suportar um mecanismo de proteção contra sequestro de Root Bridge! Um ataque muito simples de ser lançado contra os seus equipamentos, e com consequências desastrosas nas áreas de indisponibilidades e incidentes de segurança.
• Protocolos do tipo First Hop Redundancy Protocol (FHRP), dos quais figuram o VRRP, HSRP e GLBP.
  • Siga as boas práticas quanto a configuração destes protocolos, e configure também os mecanismos de autenticação dos pacotes, à exemplo do que fazemos para os protocolos de roteamento.

Adotar mecanismos adicionais para a segurança do plano de dados

O universo de possibilidades aqui é muito grande! Certamente não dará para estender-me muito neste artigo para esta seção. Apenas elencarei o óbvio por aqui:

• Em switches e nas VLANs de usuários, mecanismos de coibição de spoofing do endereço IP via recurso apropriado (o nome varia de acordo com o vendor, mas seria algo tipo IPSG).
• Nos roteadores de borda, mais precisamente nas interfaces L3 que servem como default gateway para o tráfego de seus assinantes, configure o recurso Unicast Reverse Path Forwarding (uRPF) para coibir o spoofing de endereços IP. Ao proceder com esta iniciativa, você estará dando uma enorme contribuição para toda a Internet, pois o spoofing de endereços IP é o maior vetor de ataques de negação de serviços distribuídos, o DDoS! Esta prática está bem citada no conjunto de boas práticas do MANRS.
• Onde desejado e aplicável, utilize listas de controle de acesso para proteger ainda mais o tráfego destinados aos blocos de endereços IPv4 e IPv6 da sua rede, posicionando estas ACLs estrategicamente nas interfaces externas e também nas interfaces virtuais dos assinantes autenticados por PPPoE, por exemplo.

Como recomendação final, certifique-se de centralizar todo o controle de acesso para os equipamentos da sua rede com um belo projeto que contempla uma infraestrutura PKI, servidores de segurança com TACACS+ e autorização externa de comandos, além de accounting e listas de controle de acesso (já citadas) para os serviços de gerenciamento habilitados e já ajustados nos seus equipamentos. Ficará bem mais fácil e bem mais seguro a centralização do gerenciamento de identidades (leia-se: contas de usuários operadores e administradores) da sua rede.

Vídeo "Boas Praticas para a Proteção da Infraestrutura de Redes do ISP"

Neste vídeo, publicado em nosso canal no YouTube, procuro fornecer uma visão mais didática de todo este artigo e fazendo isto através de uma linguagem fácil e acessível. Confira!

https://youtu.be/B6Et9MFU7cA

Espero que este artigo tenha sido útil! Até o próximo artigo!

Autor: Leonardo Furtado