Resumo

  • A comunidade bem conhecida BLACKHOLE é uma solicitação consultiva para descartar tráfego destinado ao prefixo marcado. O receptor decide se a honra, com acordo prévio na sessão, autorização de prefixo e configuração local explícita.
  • O RTBH por destino instala uma rota mais específica para uma ação de descarte. O ataque deixa de ocupar o enlace, porém todos os pacotes legítimos para o mesmo endereço também são eliminados.
  • A prova precisa ligar UPDATE bruto, autorização, incidente, ROV, import policy, contenção, RIB, FIB, contadores, pacotes, retirada e restauração. Sessão Established não demonstra que a rota produziu o efeito correto.

Proteger a rede desligando um destino

Considere um caso sintético. Um cliente de trânsito sofre um ataque volumétrico contra 203.0.113.19. O enlace de acesso satura antes que um firewall do cliente possa ajudar. O cliente anuncia 203.0.113.19/32 ao provedor com BLACKHOLE. A sessão foi previamente habilitada para o serviço, e o provedor reconhece que o cliente pode anunciar 203.0.113.0/24.

O /32 é aceito e resolvido para descarte nos roteadores de entrada. O ataque para de atravessar o circuito; o tráfego legítimo para o host também. Outros endereços do /24 continuam disponíveis. A vítima foi sacrificada para proteger capacidade e serviços vizinhos.

Mais tarde, uma automação anuncia 203.0.113.91/32, endereço de uma aplicação saudável no mesmo agregado. Peer, cobertura e comunidade são válidos. Se essas forem as únicas verificações, uma solicitação tecnicamente correta executa uma intenção de incidente errada. Nenhuma sessão cai; o serviço simplesmente deixa de receber pacotes.

O exemplo não descreve uma falha pública. Ele revela uma lacuna real: poder anunciar dentro de um bloco não prova que alguém autorizou o descarte daquele host, naquele momento, por aquele incidente.

Um significado comum não é uma ordem universal

A IANA registra BLACKHOLE como 0xFFFF029A, normalmente exibido como 65535:666. A RFC 7999 define a comunidade como well-known, transitive e advisory para blackholing por destino. O valor único reduz códigos privados e erros de operação entre provedores.

Ainda assim, aceitar e honrar, ou ignorar, é escolha de cada operador. Em relação bilateral, as duas redes devem concordar antes do uso. Sem diretiva explícita, o equipamento não deveria descartar só porque reconhece o código.

O emissor, portanto, não administra remotamente o plano de encaminhamento do receptor. Ele anexa um pedido. O receptor verifica sessão, prefixo e política e decide se há delegação suficiente. Uma rede pode entender a comunidade e não oferecer o serviço; um coletor pode armazená-la sem encaminhar tráfego.

Essa divisão concretiza a especificação inicial mínima de Heng Lu. O núcleo compartilhado é pequeno: valor estável e semântica de pedido de descarte. Oferta comercial, elegibilidade, região, duração e ação permanecem locais. A decisão futura localizada permite adotar ou recusar sem que uma instituição transforme a recusa em invalidade. A adoção voluntária exige implementação e uso: RFC e registro IANA, sozinhos, não descartam pacote algum.

A melhor rota pode significar não entregar

A RFC 5635 descreve uma rota para interface null ou discard. Uma política faz o prefixo anunciado resolver para esse next hop. Como a rota é mais específica, os pacotes são descartados perto dos ingressos, antes de consumirem capacidade até o cliente.

A rota pode estar correta, ser selecionada e aparecer na Loc-RIB, enquanto a consequência programada é a não entrega. Loc-RIB não prova alcançabilidade normal e tampouco prova o blackhole sem observar FIB e resolução de next hop em cada classe de entrada.

O custo é explícito: RTBH por destino elimina ataque e tráfego legítimo para a vítima. O ganho é reduzir dano colateral ao restante da rede. Por isso, um relatório precisa separar capacidade protegida de disponibilidade da vítima. Queda na utilização do enlace pode demonstrar contenção bem-sucedida e, simultaneamente, indisponibilidade total do serviço.

Sem essa separação, “mitigado” vira um eufemismo para “desligado”. A decisão executiva deve declarar qual ativo está sendo preservado e quem suporta o sacrifício.

Dois controles da RFC e um controle que BGP não carrega

Em uma relação bilateral, o receptor só deve honrar BLACKHOLE se o prefixo estiver coberto por prefixo igual ou menos específico que o vizinho está autorizado a anunciar. Também deve haver acordo para honrar o sinal naquela sessão específica.

O primeiro controle impede que um cliente descarte endereços alheios. O segundo impede que qualquer peering se torne canal de desligamento. Eles definem espaço e relação.

Não definem completamente a intenção. Um /32 incorreto ainda pertence ao /24 autorizado. Credenciais podem ser comprometidas. Um pedido antigo pode reaparecer após o ataque. O UPDATE não traz um registro verificável com aprovador, serviço, motivo, expiração e responsável pela retirada.

O terceiro controle precisa existir no sistema operacional: identidade do solicitante, incident ID, prefixo exato, serviço, justificativa, escopo, hora, vencimento e withdrawal owner. Tudo deve ser ligado ao peer, AFI/SAFI e versão da política que processaram a rota.

O filtro responde se o cliente pode anunciar naquela faixa. O registro do incidente responde se alguém autorizado quis sacrificar aquele destino agora. Aprovação sem filtro permite erro de digitação; filtro sem contexto entrega à automação uma autorização permanente sobre todo o bloco.

A precisão do host route exige uma exceção controlada

A RFC 7999 recomenda o prefixo mais específico possível, normalmente /32 para IPv4 e /128 para IPv6. Isso limita endereços colaterais. Porém, políticas públicas costumam rejeitar rotas mais longas que /24 e /48.

O serviço RTBH abre uma exceção intencional: aceita o host route do cliente para descarte local, mas impede que ele vire rota comum da Internet. A exceção deve juntar agregados autorizados, comprimentos admitidos, sessão, comunidade, região e ação.

Mais específico não significa automaticamente correto. Um único IP pode hospedar DNS, autenticação ou controle. Um /24 talvez seja necessário num ataque amplo, mas sacrifica muitos destinos. Comprimento é uma decisão de blast radius.

Também são necessários limites semânticos: quantidade simultânea, endpoints protegidos, tempo máximo e ingressos autorizados. Um maximum-prefix comum não reconhece que uma rota destrutiva pode causar mais impacto que milhares de rotas normais.

Conter o more-specific destrutivo

A RFC 7999 recomenda adicionar NO_ADVERTISE, NO_EXPORT ou controle semelhante. Pela RFC 1997, NO_ADVERTISE bloqueia anúncio a qualquer outro peer; NO_EXPORT permite distribuição interna, mas proíbe ultrapassar o AS ou a confederação.

O provedor pode precisar distribuir a rota a todos os ingressos ou apenas às regiões da origem do ataque. O controle deve refletir o grafo real. Uma contenção estreita demais impede a defesa; larga demais deixa o host route escapar.

O vazamento é perigoso mesmo onde BLACKHOLE é ignorado: longest-prefix match pode atrair tráfego. Onde é honrado, outro AS pode passar a descartar. Por isso a RFC 5635 recomenda filtros de egresso.

A documentação atual do FRRouting informa que NO_ADVERTISE é adicionado automaticamente quando BLACKHOLE é recebido. Isso comprova um comportamento do FRR, não de todos os vendors e releases. Outra implementação pode exigir política; uma regra que substitui communities pode apagar a proteção.

A verificação é Adj-RIB-Out após policy para cada classe de vizinho. Configuração mostra intenção; a rota anunciada mostra o que o equipamento executaria.

Autenticar o canal não autentica a intenção

BLACKHOLE viaja no atributo clássico COMMUNITIES, que pode ser modificado por política local. A RFC 7999 alerta que BGP não impede especificamente a adição, remoção ou alteração dessas comunidades, e BGPsec não resolve isso. Adição não autorizada pode produzir negação de alcançabilidade.

Proteger a sessão reduz falsificação do peer, mas não prova que o alvo foi escolhido corretamente. RPKI valida prefixo, AS de origem e maxLength; não assina a comunidade nem a decisão de descarte.

Um /32 legítimo pode resultar RPKI Invalid se a ROA autoriza somente o /24. A RFC 7999 exige que a validação de origem não bloqueie acidentalmente blackholes legítimos. Isentar toda rota marcada seria perigoso, pois um atributo mutável viraria bypass. Estender todas as ROAs até /32 ou /128 também amplia quais more-specifics podem validar.

Um Internet-Draft individual de 2022 propôs uma RPKI Discard Origin Authorization para separar essas permissões. O documento expirou e não possui posição formal do IETF. Ele registra a lacuna, não fornece um controle padronizado já implantado.

A confiança atual é composta: identidade de peer, filtro exato, tratamento ROV explicado, comunidade, autorização de incidente, escopo local e FIB observada. Nenhum item substitui os demais.

Quatro controles diferentes

RTBH por destino descarta tudo para a vítima. RTBH por origem combina discard route e uRPF para falhar a verificação do source address nos ingressos. A RFC 5635 diz que a comunidade de destino não deve ser reutilizada e recomenda que triggers por origem venham de sistemas locais de mitigação.

FlowSpec distribui regras de match e action em outra NLRI; a RFC 7999 exclui BLACKHOLE desse uso. Sinkhole redireciona para observação. Scrubbing tenta preservar tráfego legítimo. Blackhole por destino apenas elimina.

O registro deve nomear o mecanismo e o resultado esperado. Se o objetivo é manter a vítima online, RTBH por destino é último recurso para capacidade, não evidência de continuidade.

Evidência do UPDATE até o silêncio

Antes da ativação, registrar customer, exact session, AFI/SAFI, prefixos, comprimentos, community, exclusões, regiões, regra ROV, tempo máximo e dono da retirada.

Para cada trigger, preservar:

  1. UPDATE bruto, horário, peer, AS_PATH, origem, next hop e communities;
  2. entrada exata do filtro e sua fonte;
  3. estado ROV e regra aplicada;
  4. termo de importação, contenção e mudança de next hop;
  5. Adj-RIB-In, escolha Loc-RIB e motivo;
  6. FIB de cada ingresso com ação discard;
  7. contadores com equipamento, interface, semântica e baseline;
  8. pacotes antes e depois da fronteira;
  9. Adj-RIB-Out de cada vizinho que não pode receber a rota;
  10. withdrawal, remoção FIB, retorno da rota comum e sondas de serviço.

O UPDATE prova entrada; policy log, decisão; RIB, seleção; FIB, instrução; pacotes, consequência. Saída prova contenção. Recuperação prova que a autoridade terminou.

Um indicador único não distingue rota não selecionada, next hop não resolvido, metade da frota sem FIB ou estado stale após withdrawal. A RFC recomenda conservar UPDATEs BLACKHOLE; auditoria completa também guarda policy, FIB, contadores e aprovação.

Testar o sacrifício e a devolução

Um prefixo canário deve atravessar cada tipo de sessão, família, região, plataforma e release. O teste aceita o caso autorizado e recusa prefixo externo, sessão errada e comprimento indevido. Confere contenção, descarte FIB, contadores, efeito limitado e restauração após retirada.

Pausar sem incidente vivo, com endpoint protegido, ROV inexplicável, contenção ausente, exportação eBGP, divergência de FIB, ausência de expiry ou de withdrawal owner. Reverter diante de serviço errado, escopo maior, vazamento, perda além do prefixo ou impossibilidade de reconstruir o ato.

Withdrawal inicia a reversão. Ela só termina quando toda FIB remove o discard, a rota normal volta, as sondas entregam e o enlace permanece controlado. O forwarding pode ser reversível; a responsabilidade não é recuperável se as evidências expirarem.

Fontes