CoPP no Cisco IOS-XE: proteger o plano de controle do roteador

Configurar CoPP no Cisco é o que separa um roteador de borda que aguenta um ataque de um que perde o BGP e o SSH no meio dele. CoPP (Control Plane Policing) é uma política de QoS aplicada ao tráfego que vai para a CPU do próprio roteador: sessões BGP, SSH, SNMP, ping, ARP. O tráfego que só atravessa o equipamento não passa por ela.

Neste guia, montado e testado em laboratório, a política é para roteadores IOS-XE como ISR 4000, ASR 1000 e Catalyst 8000. O roteiro: o que chega na CPU, as ACLs que separam o tráfego em classes, o policy-map com os limites, a aplicação no control-plane, a proteção da VTY e do SNMP e um jeito de testar sem perder o acesso. Os IPs e ASNs são de documentação.

Resposta rápida: os passos do CoPP no Cisco IOS-XE

1. Crie ACLs estendidas que descrevem o tráfego legítimo para o roteador: BGP com os peers, SSH e SNMP vindos do NOC, ICMP útil.
2. Crie uma ACL para o indesejado: SSH, Telnet, SNMP e BGP vindos de qualquer outra origem.
3. Amarre cada ACL a um class-map com match access-group name.
4. Monte o policy-map com um police por classe e um limite na class-default.
5. Aplique com control-plane e service-policy input, com um reload in agendado como rede de segurança.
6. Acompanhe os contadores com show policy-map control-plane e ajuste os limites.

O que chega na CPU do roteador

Num roteador IOS-XE, quase todo pacote é encaminhado pelo plano de dados, o processador de encaminhamento (QFP), sem passar pela CPU de controle. Vão para ela os pacotes destinados aos endereços do próprio roteador e alguns casos de exceção, como TTL expirado e ARP. É pouco tráfego em condições normais, mas a CPU tem capacidade pequena perto da do plano de dados.

Um ataque que mira o IP da interface de trânsito, um scan de SSH vindo da internet ou uma tempestade de ARP na LAN do IX disputa a mesma CPU que mantém o BGP de pé. Quando ela satura, os keepalives não saem a tempo, o hold timer expira e a sessão cai. O CoPP põe um limite em cada tipo de tráfego para que um deles não tome o espaço dos outros. A wiki do Brasil Peering Forum separa esse tráfego em grupos parecidos com estes:

Passo 1: ACLs que separam o tráfego

No CoPP no Cisco, as ACLs não bloqueiam nada sozinhas. Elas só dizem o que entra em cada classe: permit coloca o pacote na classe, deny deixa o pacote de fora para ser avaliado pela próxima. O cenário: AS64500, trânsito em 203.0.113.1, LAN de IX em 198.51.100.0/24, iBGP entre as loopbacks 192.0.2.1 e 192.0.2.2 e NOC em 192.0.2.64/27.

Roteamento

ip access-list extended COPP-ROTEAMENTO
 permit tcp host 203.0.113.1 host 203.0.113.2 eq bgp
 permit tcp host 203.0.113.1 eq bgp host 203.0.113.2
 permit tcp 198.51.100.0 0.0.0.255 host 198.51.100.50 eq bgp
 permit tcp 198.51.100.0 0.0.0.255 eq bgp host 198.51.100.50
 permit tcp host 192.0.2.2 host 192.0.2.1 eq bgp
 permit tcp host 192.0.2.2 eq bgp host 192.0.2.1
 permit ospf any any

Cada peer aparece duas vezes porque a sessão BGP pode ser aberta por qualquer um dos lados: numa linha a porta 179 é o destino, na outra é a origem. Na LAN do IX, a origem é a rede inteira, já que os route servers e os bilaterais ficam nela. Se você usa BFD ou LDP, acrescente as linhas correspondentes aqui (BFD em UDP 3784 e 3785, LDP em TCP e UDP 646); o que ficar de fora vai parar na class-default.

O IS-IS não é IP e não casa com uma ACL IP: confira na documentação da sua plataforma como ele é classificado no CoPP e acompanhe a class-default depois de aplicar.

Gerência

ip access-list extended COPP-GERENCIA
 permit tcp 192.0.2.64 0.0.0.31 any eq 22
 permit udp host 192.0.2.70 any eq snmp
 permit udp host 192.0.2.80 eq ntp any

SSH só da rede do NOC, SNMP só do servidor de monitoramento e as respostas do servidor NTP. Se você usa TACACS+ ou RADIUS, inclua as respostas dos servidores aqui também.

ICMP

ip access-list extended COPP-ICMP
 permit icmp any any echo
 permit icmp any any echo-reply
 permit icmp any any ttl-exceeded
 permit icmp any any unreachable

Ping e traceroute continuam funcionando, e o unreachable mantém a descoberta de MTU do caminho. Bloquear todo ICMP atrapalha mais o seu diagnóstico do que o atacante.

Indesejado

ip access-list extended COPP-INDESEJADO
 permit tcp any any eq 22
 permit tcp any any eq telnet
 permit udp any any eq snmp
 permit tcp any any eq bgp
 permit tcp any eq bgp any

Esta ACL pega SSH, Telnet, SNMP e BGP de qualquer origem. Parece contraditório com as ACLs anteriores, mas a ordem das classes no policy-map resolve: o tráfego legítimo já casou com roteamento ou gerência antes de chegar aqui. Só sobra o que veio de outro lugar.

Passo 2: class-map e policy-map do CoPP no Cisco

class-map match-any CM-ROTEAMENTO
 match access-group name COPP-ROTEAMENTO
class-map match-any CM-GERENCIA
 match access-group name COPP-GERENCIA
class-map match-any CM-ICMP
 match access-group name COPP-ICMP
class-map match-any CM-ARP
 match protocol arp
class-map match-any CM-INDESEJADO
 match access-group name COPP-INDESEJADO

Cada class-map aponta para uma ACL pelo nome. A classe de ARP usa match protocol arp, que o CoPP do IOS-XE aceita. O match-any não faz diferença com um critério só, mas deixa a classe pronta para receber um segundo.

policy-map PM-COPP
 class CM-ROTEAMENTO
  police cir 2000000 conform-action transmit exceed-action transmit
 class CM-GERENCIA
  police cir 1000000 conform-action transmit exceed-action drop
 class CM-ICMP
  police cir 128000 conform-action transmit exceed-action drop
 class CM-ARP
  police cir 256000 conform-action transmit exceed-action drop
 class CM-INDESEJADO
  police cir 8000 conform-action drop exceed-action drop
 class class-default
  police cir 512000 conform-action transmit exceed-action drop

• A ordem é a do policy-map. O pacote é testado de cima para baixo e fica na primeira classe que casar. Por isso roteamento e gerência vêm antes do indesejado.
• Roteamento com transmit nos dois lados. A classe só conta os pacotes. BGP de peer conhecido nunca é descartado; o BGP de origem estranha já foi para o indesejado.
• Gerência a 1 Mbps. Folga para SSH e polling SNMP. Se o seu Zabbix faz walks grandes, acompanhe os contadores e suba o valor.
• ICMP a 128 kbps e ARP a 256 kbps. Valores de partida. ARP numa LAN de IX grande pede mais, e os contadores mostram quanto.
• Indesejado com drop nos dois lados. O police com conform-action drop descarta tudo. O guia da Cisco diz que no CoPP só police e set são aceitos na política, e esse é o jeito de descartar mantendo os contadores.
• class-default limitada, não descartada. É ali que cai o protocolo que você esqueceu. Com limite, ele continua funcionando e aparece nos contadores.

Os números são pontos de partida para um roteador de borda pequeno. Não existe valor certo para todo mundo: depende da plataforma, do número de peers e do tamanho da tabela. Por isso o passo de verificação importa tanto quanto a configuração.

Passo 3: aplicar o CoPP no Cisco sem se trancar fora

control-plane
 service-policy input PM-COPP

Esta é a linha que liga a política. Antes de aplicar, garanta um caminho de volta caso a ACL de gerência esteja errada e o seu SSH caia na classe do indesejado:

reload in 15
configure terminal
control-plane
 service-policy input PM-COPP
end
show policy-map control-plane
reload cancel
copy running-config startup-config

1. reload in 15 agenda um reinício em 15 minutos. O roteador pede confirmação. Como a política ainda não foi salva, o reload volta a configuração anterior.
2. Aplique a política e abra uma segunda sessão SSH, sem fechar a primeira, para confirmar que a gerência continua entrando.
3. Confira os contadores e o estado do BGP.
4. Deu tudo certo: reload cancel e só então salve a configuração.

ACL na VTY e SNMPv3: a proteção que vem junto

O CoPP no Cisco limita a taxa, mas a ACL de gerência ainda deixa o SSH do NOC passar em qualquer quantidade até o limite. As camadas abaixo garantem que só quem deve consegue de fato abrir sessão.

Linhas VTY só para o NOC e só SSH

ip access-list standard VTY-NOC
 permit 192.0.2.64 0.0.0.31
line vty 0 4
 access-class VTY-NOC in
 transport input ssh

O access-class recusa a conexão de quem está fora da rede do NOC, e o transport input ssh desliga o Telnet. Confira quantas linhas VTY o seu equipamento tem com show running-config | section line vty e aplique em todas. Os filtros de show estão no post de comandos Cisco IOS básicos.

SNMPv3 com ACL

ip access-list standard SNMP-NMS
 permit host 192.0.2.70
snmp-server group NOC v3 priv access SNMP-NMS
snmp-server user zabbix NOC v3 auth sha SENHA-AUTH priv aes 128 SENHA-PRIV

O grupo usa o nível priv, com autenticação SHA e criptografia AES. A ACL SNMP-NMS amarra o acesso ao servidor de monitoramento. Troque as senhas de exemplo e remova as communities v1 e v2c que estiverem configuradas.

BGP com senha e GTSM

router bgp 64500
 neighbor 203.0.113.1 password SENHA-DO-PEER
 neighbor 203.0.113.1 ttl-security hops 1

A senha MD5 faz o roteador descartar segmentos TCP sem assinatura válida, o que dificulta um reset forjado da sessão. O ttl-security hops 1 exige que o pacote do peer chegue com TTL 254 ou maior, o que só acontece se ele estiver a um salto. Os dois lados precisam configurar o mesmo. Numa sessão já estabelecida, a senha nova só entra em vigor na próxima conexão, e a sessão cai quando o hold timer expirar se o peer ainda não tiver a mesma senha: combine a troca com ele antes.

Como verificar o CoPP no Cisco e ajustar os limites

show policy-map control-plane
show policy-map control-plane input class CM-INDESEJADO
show access-lists COPP-GERENCIA

Saída resumida da classe do indesejado, com valores de exemplo:

Control Plane
  Service-policy input: PM-COPP
    Class-map: CM-INDESEJADO (match-any)
      1843 packets, 110580 bytes
      Match: access-group name COPP-INDESEJADO
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 2 packets, 120 bytes; actions:
          drop
        exceeded 1841 packets, 110460 bytes; actions:
          drop

• Contadores subindo no indesejado mostram que alguém de fora está batendo no SSH, SNMP ou BGP. É o esperado num roteador com IP público.
• Exceeded na gerência ou no roteamento pede investigação: limite apertado demais ou ACL faltando uma origem legítima.
• Muito tráfego na class-default indica protocolo esquecido. Descubra qual é e crie uma classe para ele.
• O show access-lists mostra os acertos por linha e ajuda a ver qual regra está pegando o tráfego.

Deixe a política rodando alguns dias, anote os picos de cada classe e ajuste os limites com folga. Um ataque real é a pior hora para descobrir que o ARP da LAN do IX precisava do dobro.

E no Catalyst 9000?

Nos switches Catalyst 9000, o CoPP no Cisco funciona de outro jeito. Desde o IOS-XE 16.8.1a não é possível criar class-maps próprios para o plano de controle: existe uma política do sistema, a system-cpp-policy, e você só pode mudar a taxa do police das classes que já existem, sempre em pacotes por segundo. Nos roteadores IOS-XE (ISR 4000, ASR 1000, Catalyst 8000) é o contrário: a política do control-plane é sua, e é ela que este guia monta.

show policy-map system-cpp-policy
show platform hardware fed active qos queue stats internal cpu policer

O primeiro comando lista as classes do sistema e os limites atuais. O segundo mostra os contadores por fila da CPU. Nesse caso a proteção da gerência fica por conta da ACL na VTY e do SNMPv3, que funcionam do mesmo jeito.

No IPv6, a lógica é a mesma das ACLs acima, com ipv6 access-list e classes próprias. Se a borda tem BGP em IPv6, como numa porta de IX, não deixe esse tráfego cair na class-default; veja o post sobre como conectar o provedor ao IX.br.

Erros comuns ao configurar CoPP no Cisco

• Classe do indesejado antes da gerência. O SSH do NOC casa primeiro com permit tcp any any eq 22 e é descartado. A ordem do policy-map decide.
• Esquecer o iBGP ou o OSPF. A sessão entre loopbacks cai na class-default e passa a disputar espaço com qualquer coisa.
• Descartar a class-default. Parece mais seguro, mas derruba o primeiro protocolo que ninguém lembrou de classificar.
• Aplicar sem rede de segurança. Sem reload in ou console, um erro na ACL de gerência vira deslocamento até o equipamento.
• Achar que o CoPP segura volumétrico. Ele protege a CPU, não o link. Um ataque que enche o link de entrada precisa de outra resposta, como RTBH para conter DDoS.

Perguntas frequentes

O que é CoPP no Cisco?

É o Control Plane Policing: uma política de QoS aplicada ao tráfego destinado à CPU do roteador. Ela separa esse tráfego em classes e limita cada uma, para que um ataque ou um excesso de um protocolo não derrube BGP, SSH e os demais serviços do plano de controle.

O CoPP no Cisco afeta o tráfego dos clientes?

Não. Ele só atua sobre pacotes que vão para o próprio roteador. O tráfego que atravessa o equipamento segue pelo plano de dados sem passar pela política.

Como descartar uma classe no CoPP no Cisco IOS-XE?

Use police com conform-action drop e exceed-action drop. Na política de entrada do CoPP, só police e set são aceitos, e assim os contadores continuam mostrando quanto foi descartado.

Quais valores usar no police?

Não há valor universal. Comece com limites folgados, deixe a política rodando alguns dias e ajuste pelos picos que aparecem no show policy-map control-plane. Cada rede pede um ajuste próprio do CoPP no Cisco.

Dá para criar CoPP próprio no Catalyst 9000?

Não. Desde o IOS-XE 16.8.1a, o Catalyst 9000 só aceita a system-cpp-policy, em que você muda a taxa das classes do sistema em pacotes por segundo.

Conclusão

Montar CoPP no Cisco IOS-XE é separar o tráfego da CPU em classes, limitar cada uma e manter o legítimo antes do indesejado. Some a isso a ACL na VTY, o SNMPv3 e a senha com GTSM no BGP, e o roteador de borda passa a aguentar um scan ou uma tempestade de ARP sem perder as sessões.

Aplique com o reload in agendado, confira os contadores por alguns dias e ajuste os limites. Para a mesma ideia em outro fabricante, veja o post de segurança no Mikrotik RouterOS v7.

Leitura recomendada: Boas práticas para proteção de roteadores e switches, da wiki do Brasil Peering Forum (CC BY-NC 4.0).