O que entra em uma lista, e como sai.

As entradas saem sozinhas: ninguém precisa lembrar de remover um endereço antigo. Uma que volta só entra na lista de novo após um novo avistamento.

Cada lista também tem uma versão mais rígida, -high, com menos entradas. Por padrão, exige pelo menos 10 sensores, avistamentos em três dias diferentes e uma checagem em uma fonte externa de reputação.

Formatos

• Texto puro, um endereço por linha, também em arquivos IPv4 e IPv6 separados.
• Scripts para nftables, ipset e MikroTik RouterOS.
• CSV e JSON com as datas: primeiro avistamento, último avistamento e expiração.
• Pacotes STIX 2.1 para as listas de saída.
• Listas de domínio vêm só em texto, CSV e JSON.

Assinado com minisign

Cada arquivo tem uma assinatura .minisig ao lado, feita com chaves Ed25519. A chave dos feeds é separada da chave que assina as mensagens da rede, então o vazamento de uma não pode forjar a outra. A chave pública está no README.txt junto às listas. Para conferir um arquivo:

minisign -Vm inbound.txt -P <public key>

Um firewall que carrega a URL pura não confere assinaturas. Use um espelho verificado, ou confira o arquivo antes.

Um apoio à defesa, não um veredito

Estar na lista é uma observação factual, não uma acusação contra a pessoa que tem o endereço. Muitos dispositivos listados estão comprometidos, por exemplo um roteador ou um NAS que outra pessoa controla. O que você bloqueia na sua própria rede é uma escolha sua.

As regras

São padrões. O hub pode mudá-los, e os valores em vigor estão em suckerpot-hub.selfhostr.io/v1/info.

• Pelo menos cinco sensores viram o endereço. Cada um foi cadastrado há pelo menos 14 dias e reportou em pelo menos 7 dos últimos 14 dias.
• Os avistamentos são em pelo menos dois dias diferentes, ou vêm de pelo menos dez sensores.
• Uma semana de cadastro não pode fornecer mais da metade da evidência, então sensores que entraram juntos não conseguem listar um endereço sozinhos.
• Se nenhuma fonte externa de reputação conhece um endereço, são necessários dez sensores em vez de cinco. O operador define essas fontes.
• Uma varredura ou uma simples conexão nunca põe um endereço na lista. Uma entrada de entrada exige um login, um comando, um download, uma tentativa de exploit ou muitos chutes de senha.
• Um host de malware exige um arquivo baixado que corresponda a uma família de malware conhecida, ou que seja um programa ou script executável, visto por pelo menos dois sensores. Uma URL dentro de um comando não basta.
• Um servidor de comando exige alta confiança da rede, e pelo menos duas amostras de malware diferentes, de pelo menos dois sensores, que apontem para ele.

Nunca listado

• Relés de saída da Tor. Milhares de pessoas dividem cada um.
• Grandes faixas de CDN e front-end de nuvem. Um só endereço pode servir milhares de sites.
• Resolvers DNS públicos e servidores raiz. Bloqueá-los quebra redes.
• Nomes de hospedagem compartilhada e de software como serviço. Bloqueá-los quebra o trabalho.
• Endereços privados e reservados, como a sua própria rede local.
• Scanners de pesquisa, que se anunciam.
• Endereços da lista de permissões, por exemplo após um pedido de remoção aceito.

Servidores de nuvem comuns não são excluídos, porque malware costuma morar neles. A expiração curta e a remoção após uma remoção limitam o dano quando um endereço é reutilizado. O número de endereços excluídos é público; os endereços em si não.

Freio de emergência

Se uma atualização fosse acrescentar ou remover mais da metade de uma lista, e pelo menos 200 entradas mudarem, nada é publicado. Os arquivos anteriores continuam no ar até um operador conferir a mudança. Isso impede que um lote ruim ou um bug mude o que o seu firewall bloqueia da noite para o dia.

Uma nova entrada espera seis horas depois de confirmada para aparecer. As listas são reconstruídas uma vez por hora.

• Nenhum endereço IP de membro. As listas guardam endereços de atacantes, não os dos sensores.
• Nenhum nome de membro, pseudônimo, ID de nó ou impressão digital.
• Nenhum horário exato de avistamento, só o dia.
• Nenhuma URL, amostra de malware ou texto livre nas listas.
• Nenhum registro de quem baixa uma lista. O site dos feeds não guarda log de acesso.
• Sem cookies, sem analytics e sem requisições a terceiros no site dos feeds.
• Sem conta e sem token.

Como pedir

1. Abra o formulário de pedido em https://suckerpot-feeds.selfhostr.io/v1/delist.html.
2. Digite o endereço ou nome de host, escolha um motivo e adicione detalhes se quiser (texto puro, no máximo 2.000 caracteres).
3. O formulário resolve antes um desafio de proof-of-work, que leva cerca de um segundo. Isso substitui um login e limita enxurradas de requisições.
4. Você recebe um número de pedido e um código de status. O código é mostrado uma única vez: guarde-o para conferir o status depois, na mesma página.

Motivos que você pode informar

• Eu opero este endereço e ele não estava atacando ninguém.
• É infraestrutura compartilhada, como uma CDN, um proxy ou um resolver.
• O problema foi corrigido ou limpo.
• O endereço agora pertence a outra pessoa.
• Outra coisa. Explique nos detalhes.

Consultar um valor

Você pode consultar qualquer endereço ou nome de host sem enviar um pedido, com a caixa de consulta na página do formulário ou com a chamada abaixo. A resposta indica cada lista que contém o valor, com as datas. A consulta tem limite de requisições.

GET https://suckerpot-feeds.selfhostr.io/v1/lookup?value=192.0.2.10

O que acontece depois

• Nosso objetivo é decidir cada pedido em até 72 horas.
• Uma entrada de entrada fica oculta enquanto o pedido estiver aberto.
• Uma entrada de saída continua listada até uma pessoa revisar o pedido. Essas entradas protegem mais, então não as removemos só com base em uma alegação.

Seus dados em um pedido

• O formulário não guarda o seu endereço IP.
• Os detalhes e o seu contato são usados só para responder, e apagados 30 dias após a decisão.
• Se um pedido ainda estiver aberto após 180 dias, os detalhes e o contato são apagados nesse momento. O registro do pedido em si é apagado 180 dias depois de feito.

• Só entradas confirmadas são denunciadas, nunca uma varredura ou uma simples conexão.
• Por padrão, um operador revisa cada denúncia antes do envio.
• As denúncias vão para o contato de abuso do dono da rede, encontrado em dados públicos de registro (RDAP).
• Uma denúncia leva só fatos: dias, serviços, contagens em faixas e quantos sensores viram. Nunca cita um membro.
• As denúncias saem pela VPN. Uma verificação de identidade recusa qualquer texto que cite o projeto ou o seu operador.
• Uma denúncia por alvo e por destinatário. O mesmo alvo não é denunciado de novo em 30 dias.

abuse.ch

Servidores de malware e de comando confirmados também podem ir para a abuse.ch, onde a URLhaus e a ThreatFox os listam para todos. É opcional e vem desligado por padrão. Hoje, uma pessoa revisa cada envio, e servidores de comando só são enviados depois que um operador os aprova. O registro de um envio concluído é mantido por 365 dias.