O que faz: mostra a foto atual do ASN — identidade (nome, numero, maintainers, tags) e um resumo da Higiene. E somente leitura: a edicao fica no painel Cadastro e o detalhe dos checks no painel Operacao.

Por que importa: e a tela de entrada para conferir, num relance, quem e o ASN e se ele esta saudavel, antes de mergulhar em cada modulo.

Ganho de governanca: um ponto unico e confiavel de consulta rapida, sem risco de editar algo sem querer.

O que e: um passo-a-passo das boas praticas que a ferramenta nao consegue provar sozinha (DNSSEC, AS-path, coerencia RFC 1786, deny-by-default). Cada guia explica o que e, como fazer e como conferir.

Como usar: faca o que a guia orienta, confira, e clique em "Marcar: fiz e revisei". O item passa a valid (atestado por voce, com data) aqui e tambem na lista BCOP do painel MANRS.

Importante: a atestacao e um track proprio (Conformidade BCOP atestada) e nao altera o score das 4 acoes MANRS — ele continua refletindo so o que e medido. O DNS reverso tem verificacao automatica (botao abaixo).

O que faz: cria ou edita o registro local do ASN — identidade, maintainers (mntner) e tags. E a fonte de verdade local que alimenta os checks de Higiene e os demais modulos.

Por que importa: dado consistente aqui (nome certo, maintainer certo) eleva o score e evita retrabalho; dado errado se propaga para IRR, PeeringDB e relatorios.

Ganho de governanca: um cadastro unico e rastreavel, base para automatizar o resto com seguranca.

O que e: um placar de 0 a 100% que mede o quanto o ASN esta "em ordem". Ele soma varios checks objetivos sobre inventario, contatos, IRR, RPKI, PeeringDB e GeoFeed. Nao e nota de prova — e um checklist vivo de conformidade.

Como o placar e calculado: cada check recebe um estado, e o score e a porcentagem de checks validos sobre o total (hoje 17 checks em 6 modulos, todos com o mesmo peso). Subir o score = transformar amarelo e vermelho em verde.

Os tres estados (a parte que mais importa):

• valid (verde): comprovado e conforme — conta para o score.
• needs review (amarelo): pendencia — falta preencher ou confirmar. Nao e erro, mas nao pontua.
• invalid (vermelho): ausente ou em conflito — e o que derruba o score e o que voce ataca primeiro.

O que cada modulo verifica (e por que importa):

• Inventario: o ASN existe na base local — a ancora de todo o resto.
• Contatos (tecnico, abuse, NOC, peering): quem e acionado em incidente ou abuso. Abuse desatualizado = reclamacao que nunca chega a voce.
• IRR (source, AS-SET, aut-num, objetos RPKI invalidos): seus upstreams montam o filtro de rota a partir disso. Objeto ausente ou invalido = prefixo filtrado e rota que nao propaga.
• RPKI (publish-only, ROAs, horario): o ROA assina qual ASN pode originar cada prefixo. Sem ROA, o bloco fica exposto a sequestro de rota; "publish-only" e o modo seguro, que nao altera politica BGP.
• PeeringDB (AS-SET, prefix-limits): IXPs e peers usam para montar a sessao e o limite de prefixos. Divergencia trava ou derruba o peering.
• GeoFeed (URL, entradas, limite 5 MB): a geolocalizacao correta dos seus blocos — exatamente o que o submenu GeoFeed trata.

Como usar no dia a dia: nao e obrigatorio cravar 100%. Ataque o vermelho primeiro (erro real), depois o amarelo (pendencia). O ganho de governanca e ter, numa tela so, uma foto auditavel de quao publicavel e confiavel o seu ASN esta.

O que e: um placar de prontidao do ASN frente as 4 acoes MANRS (a norma de fato para seguranca de roteamento) e a itens do BCOP do NIC.br. E uma lente separada do score de Higiene: aqui o foco e roteamento seguro.

As 4 acoes MANRS: Filtering (filtrar rotas suas e de clientes), Anti-spoofing (BCP 38/SAV, nao deixar sair IP de origem falsa), Coordination (contato tecnico/NOC atualizado no RIR e no PeeringDB) e Global Validation (publicar suas rotas em IRR e ROAs em RPKI para terceiros validarem).

Como ler: verde = pronto, amarelo = pendencia, vermelho = ausente. A "Cobertura ROA" cruza, offline, suas rotas (route/route6) com as ROAs: aponta rota sem ROA (ficaria Unknown/Invalid), rota mais especifica que o maxLength (ficaria Invalid) e ROA com maxLength permissivo demais (RFC 9319, convida hijack por more-specific).

Por que importa: e a base do que upstreams e IXPs cobram de um ASN saudavel. Esta lente rastreia os criterios do Desafio BCOP 2026 do NIC.br que da para checar de forma declarativa (100% RPKI Valid, anti-spoofing, IPv6, presenca no IX.br, site institucional) na lista BCOP abaixo; o DNSSEC entra como lembrete (nao verificavel offline). Filtering vira "valid" quando voce tem AS-SET + route objects e seus anuncios proprios nao ficam RPKI Invalid: geramos o prefix-list (de SAIDA) por bgpq4 em Cisco/Huawei VRP8/JunOS/BIRD. A Acao 2 (Anti-spoofing) vira "valid" quando voce registra a evidencia do CAIDA Spoofer ou do SIMET (IPv4+IPv6) e o resultado (bloqueou) abaixo. Em Bogons (referencia) ha o filtro de ENTRADA (nega bogons + seus prefixos) pronto para download.

O que e: a politica de roteamento do seu ASN. AS-IN = o que voce ACEITA de cada upstream (from AS<up> <pref> accept ANY); AS-OUT = o que voce ANUNCIA (to AS<up> announce AS<seu>) — sintaxe RFC 1786.

Como usar: "Detectar upstreams" puxa os vizinhos eBGP do seu roteador (marca os provaveis upstreams = quem te envia tabela cheia); confirme/ajuste ou adicione um AS manualmente; clique em "Gerar" e cole o texto nos campos AS-IN e AS-OUT do Registro.br.

Objetivo: validar o caminho de SAIDA do seu ASN ate a internet — "minha rota ate la fora tem loop?". Por isso o alvo e um destino EXTERNO conhecido: 8.8.8.8 (Google), 9.9.9.9 (Quad9), 1.1.1.1 (Cloudflare) ou um dominio (dns.google — resolvido no servidor). Nao e para varrer o seu proprio bloco — para o loop do agregado (IPs nao usados que quicam) use o Static loop mais abaixo, que faz a varredura do bloco inteiro.

O que e: um loop de roteamento faz o pacote quicar entre roteadores; cada salto reduz o TTL ate zerar (ICMP Time Exceeded) — a "morte por TTL". No traceroute, aparece como os mesmos hops se repetindo sem nunca chegar ao destino.

Como testar: clique em "Rodar route-loop agora" (o servidor traceia um destino externo e valida), rode num PoP da rede, ou cole a saida de traceroute -n -m 40 <alvo> / mtr -n --report <alvo> no modo manual.

Por que importa: traz fidelidade real (teste de dentro da rede) e cobre com precisao a metrica "Routing loops" do Qrator. Cada ASN tem seu historico aqui; no futuro, proxies dentro de cada rede alimentam o dash global.

O que e: um agregado anunciado (ex.: /22) com os /24 em rota estatica pro cliente, mas SEM rota de descarte (null/blackhole) pro agregado. Pacote pra um IP NAO usado do bloco nao casa com nenhum /32 e volta pelo default — quica borda↔BNG ate o TTL/Hop Limit zerar. Um atacante varre seu bloco, acha esse IP e dispara — amplificacao de dentro pra fora.

Deteccao (precisa, sem ECMP/falso-positivo): fping -gae <seu-bloco>. Todo IP que volta ICMP Time Exceeded esta em loop (RFC 792 / ICMPv6 RFC 4443). IP normal nao usado responde timeout ou unreachable, NUNCA "Time Exceeded".

Correcao: rota de descarte do agregado no BNG/CGNAT — RouterOS: /ip route add dst-address=<agregado> type=blackhole distance=254 (IPv6: type=unreachable). Os /32 dos clientes ativos prevalecem. (Ref.: wiki Brasil Peering Forum — Static Loop.)

O que faz: lista os contatos do ASN por papel — tecnico, abuse, NOC e peering — com origem e status de validacao.

Por que importa: o contato de abuse e o canal por onde chegam as denuncias (spam, ataque, IP comprometido); tecnico e NOC tratam da operacao; peering cuida dos acordos. Contato desatualizado = incidente que nao chega a voce e reputacao do bloco em risco.

Boa pratica: use e-mail de papel (noc@, abuse@), nao pessoal — assim nao depende de uma unica pessoa.

Ganho de governanca: responsabilidade clara e resposta rapida a incidentes.

O que faz: guarda os dados da empresa do ASN — nome, site, endereco, redes sociais e CNPJ.

Sincronizacao: site/endereco/aka/redes sociais espelham a Org no PeeringDB (vem no import e poderao ser escritos de volta na Etapa 3). O CNPJ e local — o PeeringDB nao tem esse campo; a fonte oficial e o Registro.br.

O que faz: concentra os objetos de roteamento. No IRR voce mantem os objetos RPSL (route/route6, as-set, aut-num, mntner, person, role); em RPKI, os ROAs planejados. O modo e publish-only — publica e edita objetos, sem alterar politica BGP.

Por que importa: seus upstreams e IXPs montam o filtro de prefixos a partir do IRR — rota sem objeto route/route6, ou fora do AS-SET, costuma ser barrada e nao propaga. O ROA assina qual ASN pode originar cada prefixo; sem ROA, o bloco fica exposto a sequestro de rota (route hijack).

RPSL e RPKI: o IRR fala RPSL, a linguagem dos objetos (RFC 2622); o RPKI usa ROA (RFC 9582) e os roteadores aplicam Route Origin Validation (RFC 6811). O AS-SET aceita nome hierarquico (ex.: AS65000:AS-CUSTOMERS).

Ganho de governanca: rotas que propagam de forma previsivel e origem comprovada — menos filtragem indevida e menos vulnerabilidade.

Entrada: o seu mail server encaminha o e-mail cru da caixa abuse@/security@ para o webhook da plataforma (token X-Abuse-Token). Nada sai pra fora.

Classificacao: a plataforma extrai IPs/portas/horario (UTC), identifica o tipo (NTP/DNS/amplificacao, scan, spam, phishing…) e o mapeia para a taxonomia do CERT.br (DoS/Fraude/Invasao/Scan/Web/Outros).

Bloco: liga o IP ofensor ao seu route object e marca o bloco como conhecido do CERT.br. Voce trata pela fila (novo → resolvido).

O que faz: publica ROAs (autorizam seu ASN a originar seus prefixos) com um Krill proprio, sob o Registro.br (modelo delegado).

Bootstrap (uma vez): gere o Child Request aqui, cole no painel Registro.br (Titularidade → ASN → Configurar RPKI), traga o Parent Response. Idem Publisher Request → Repository Response (Publicacao Remota).

ROA minimal (RFC 9319): maxLength = tamanho do prefixo. Maior habilita sequestro de sub-prefixo; menor invalida o anuncio.

Tempo (~1h): apos criar/alterar ROA, validadores levam ate ~1h para enxergar (o IRR/RADB so revalida ROA a cada 1h).

Ganho de governanca: RPKI e IRR conversando — as ROAs saem dos mesmos prefixos que voce ja registra no IRR.

O que faz: mostra o perfil publico do ASN no PeeringDB (AS-SET, limites de prefixo IPv4/IPv6, presenca em IXPs) e aponta divergencias com o seu inventario.

Por que importa: peers e IXPs consultam o PeeringDB para montar a sessao e definir o prefix-limit. AS-SET divergente do IRR, ou prefix-limit baixo demais, trava ou derruba o peering; alto demais enfraquece a protecao contra vazamento de rota.

Ganho de governanca: perfil publico coerente com o IRR — peering aprovado mais rapido e com menos suporte manual.

O que faz: edita localmente os campos da Rede do PeeringDB (AS-SET do IRR, tipo, escopo, trafego, protocolos, looking glass, politica) e o menu Configuration (Allow IXP Update / Notify).

Allow IXP Update: autoriza o IXP a manter seus registros de netixlan via o IX-F member export. Notify On IXP Update: avisa por e-mail quando um import IX-F mudar seus dados.

Sincronizacao: aqui e local; escrever de volta no PeeringDB (PUT) e a Etapa 3.

O que e: a Organization API key (com permissao READ-WRITE em net/org) que o PeeringDB te deu. E por organizacao — vale para este ASN e qualquer outro da MESMA org. Para um ISP de outra org, selecione o ASN dele e cole a key daquela org.

Seguranca: a key fica so no servidor, cifrada em repouso (Fernet, chave derivada do session_secret) e NUNCA aparece de volta aqui — so o status. Sem ela, o "Enviar ao PeeringDB" da erro 400.

O que faz: escreve de volta no PeeringDB (PUT) os campos da Rede e da Organizacao que voce editou aqui e que diferem do PeeringDB. Direcao unica: inventario → PeeringDB.

Seguranca: "Pre-visualizar" so mostra o diff (nao escreve nada). "Enviar" exige ASN_PLATFORM_ENABLE_EXTERNAL_WRITES=true e a org API key com permissao de escrita no .env. CNPJ e geocode nunca saem. POC e netixlan ficam para a proxima etapa.

O que faz: resume a capacidade de cada integracao externa (TC IRR, PeeringDB, RPKI/Krill, provedores de GeoIP) e em que modo ela esta — leitura, publish-only ou escrita habilitada.

Por que importa: deixa explicito o que e seguro por padrao (read-only / publish-only) e o que exige credencial ou ativacao para escrever de fato, evitando acao destrutiva sem querer.

Ganho de governanca: transparencia sobre o que o sistema pode tocar no mundo externo — mudanca consciente e auditavel.