Boas Praticas para Protecao de Roteadores e Switches - Histórico de revisão

Leonardo.furtado em 05h05min de 12 de maio de 2020

2020-05-12T05:05:20Z

Leonardo.furtado em 01h14min de 9 de janeiro de 2020

2020-01-09T01:14:55Z

Leonardo.furtado: Inclusão do link do vídeo correspondente

2019-10-29T08:23:23Z

Inclusão do link do vídeo correspondente

Leonardo.furtado: Inclusão das tags BCOPs e Roteamento

2019-04-07T07:54:38Z

Inclusão das tags BCOPs e Roteamento

Leonardo.furtado: Alteração final.

2019-04-07T07:19:39Z

Alteração final.

Mostrar alterações

Leonardo.furtado: Draft final

2019-04-07T05:56:15Z

Draft final

Mostrar alterações

Leonardo.furtado: Terceira edição (draft)

2019-04-07T00:33:57Z

Terceira edição (draft)

Leonardo.furtado: Segunda edição (incompleto)

2019-04-06T05:08:03Z

Segunda edição (incompleto)

Mostrar alterações

Leonardo.furtado: Draft/inicial

2019-04-06T02:20:55Z

Draft/inicial

Página nova

=== 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.

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.
[[Arquivo:Bpf-protecao-roteadores-2.jpg|centro|miniaturadaimagem|400x400px]]

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:
[[Arquivo:Bpf-protecao-roteadores-1.png|centro|miniaturadaimagem|800x800px|Áreas funcionais com mecanismos de proteção propostos.]]

=== Proteção do equipamento contra ataques de negação de serviço ===
Apresentando o conceito na perspectiva de funcionamento de roteadores em uma rede, comecemos com uma melhor compreensão sobre os tipos de pacotes que percorrem uma infraestrutura.

==== 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.
[[Arquivo:Bpf-protecao-roteadores-3.png|centro|miniaturadaimagem|700x700px|Pacotes do plano de controle: o pacote Hello do OSPF]]
[[Arquivo:Bpf-protecao-roteadores-4.png|centro|miniaturadaimagem|700x700px|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:
[[Arquivo:Bpf-protecao-roteadores-6.png|centro|miniaturadaimagem|700x700px]]

'''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.
[[Arquivo:Bpf-protecao-roteadores-5.png|centro|miniaturadaimagem|700x700px|Exemplo do protocolo SNMP como tráfego do plano de gerenciamento]]
'''Pacotes do Plano de Serviços'''

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:
[[Arquivo:Bpf-protecao-roteadores-7.png|centro|miniaturadaimagem|700x700px|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.

'''Processamento de pacotes de trânsito'''

O processamento de pacotes de trânsito idealmente deve ocorrer na área sistêmica denominada ''plano de dados'' ou ''data plane''. 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.

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). A ilustração a seguir exemplifica os planos de controle e de dados:

Quando tratando-se de pacotes IPv4/IPv6, na perspectiva do tráfego em uma rede, podemos categorizar estas transmissões sobre as seguintes partes interessadas:

← Edição anterior		Edição das 05h05min de 12 de maio de 2020
Linha 1:		Linha 1:
	=== Boas Práticas para a Proteção de Roteadores e Switches ===		=== Boas Práticas para a Proteção de Roteadores e Switches ===
		+
		+	==== Nota sobre direitos autorais, termo de uso e isenção de responsabilidade ====
		+	Consulte [[Direitos Autorais Licenca de Uso\|os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional]].
		+
	'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''		'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''

@@ Linha 1: / Linha 1: @@
 === 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.
@@ Linha 317: / Linha 320: @@
 Espero que este artigo tenha sido útil! Até o próximo artigo!
-'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''
+'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.furtado Leonardo Furtado]'''
 [[Categoria:BCOPs]]
 [[Categoria:Roteamento]]

@@ Linha 309: / Linha 309: @@
 * 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.
 Espero que este artigo tenha sido útil! Até o próximo artigo!

← Edição anterior		Edição das 07h54min de 7 de abril de 2019
Linha 313:		Linha 313:

	'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''		'''Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Leonardo.Furtado Leonardo Furtado]'''
		+	[[Categoria:BCOPs]]
		+	[[Categoria:Roteamento]]

@@ Linha 2: / Linha 2: @@
 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.
-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!
+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 '''<u>didático</u>'''. 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 ===
@@ Linha 75: / Linha 75: @@
 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:
+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.):
 [[Arquivo:Bpf-protecao-roteadores-10.png|centro|miniaturadaimagem|700x700px|Ilustração de componentes dos planos de controle e de dados de um roteador Cisco ASR 9000]]
@@ Linha 121: / Linha 121: @@
 * ''Catch-All-IP'': todo o resto que não tiver sido identificado nas classes anteriores será identificado aqui.
 O CoPP ilustrado:
-[[Arquivo:Bpf-protecao-roteadores-9.png|centro|miniaturadaimagem|700x700px|Ilustração do Control Plane Policing (CoPP)]]
+[[Arquivo:Bpf-protecao-roteadores-9a.png|centro|miniaturadaimagem|700x700px|Ilustração do Control Plane Policing (CoPP)]]
-Quando tratando-se de pacotes IPv4/IPv6, na perspectiva do tráfego em uma rede, podemos categorizar estas transmissões sobre as seguintes partes interessadas:
+===== Caso de estudo com o Control Plane Policing (CoPP) para mitigação de ataques contra o plano de controle em plataforma Cisco IOS =====