Como denunciar o tráfego abusivo vindo de uma saída VPN
Denuncie o abuso vindo de uma saída VPN: separe parar o tráfego de identificar uma pessoa, escolha o canal que pode agir e envie provas limitadas.
O tráfego de uma saída VPN pode ser abusivo sem dizer quem o enviou, e o relatório que você escreve depende de qual das três perguntas está respondendo. Parar o tráfego é tarefa sua hoje. Preservar as provas é um procedimento. Identificar uma pessoa exige um processo legal que você provavelmente não tem. Os relatórios falham quando esses três se misturam em uma única queixa, porque o destinatário só pode agir sobre a parte que lhe pertence.
Separe primeiro as três perguntas
Comece decidindo que resultado você quer. Se o objetivo é parar as requisições, hoje você pode bloquear a faixa de endereços, limitar a conta ou endurecer o endpoint, e o relatório de abuso é secundário. Se o objetivo é um registro que resista a uma auditoria, você precisa de carimbos de tempo, identificadores de requisição e um original sem edição guardado em local seguro. Se o objetivo é um nome por trás do endereço, você precisa do processo legal do operador ou de uma ordem judicial, e nenhuma queixa privada substitui isso.
Misturá-los produz o clássico relatório inutilizável: um parágrafo furioso, nenhum fuso horário, uma exigência de dados do assinante e nenhuma indicação do que o destinatário poderia fazer mesmo se quisesse ajudar. Esse relatório é encerrado sem ação, e o remetente conclui que as mesas de abuso não fazem nada. O destinatário não tinha nada sobre o que agir.
Escreva as três respostas antes de abrir o e-mail. Elas definem o tom, o tamanho e o pedido.
O que o endereço de saída prova e o que não prova
Um endereço associado a uma VPN diz onde o tráfego entrou na internet, não quem o originou. Uma saída comercial é compartilhada por muitos clientes ao mesmo tempo, e um NAT de nível de operadora à frente pode compartilhar um endereço público entre milhares de assinantes usando faixas de portas. A RFC 6269 descreve esse modelo de compartilhamento de endereços, e a consequência prática é que o endereço de origem mais um carimbo de tempo só podem identificar um assinante se o operador ainda mantiver o mapeamento para aquele momento.
Registre o que você pode provar. Isso significa o carimbo de tempo em UTC com o fuso original anotado, o endereço de origem, a porta de origem, o protocolo e o identificador da requisição, e se a ação veio de uma conta autenticada ou de uma requisição anônima. Guarde o registro bruto e depois produza uma cópia editada para o destinatário. Uma captura de tela é um substituto ruim para a linha original do log.
As janelas de retenção são curtas e variam por operador. Quanto antes você perguntar, mais provável é que o mapeamento ainda exista, e esse é o principal argumento para denunciar rápido mesmo quando você já mitigou o problema.
Escolha o canal que realmente pode agir
Existem três canais e eles não são intercambiáveis. A mesa de abuso do operador de saída pode investigar seu próprio cliente e pode suspender a conta. O contato de registro da faixa de endereços pode apontar o operador correto quando o registro whois está desatualizado ou pertence a um revendedor. As autoridades policiais tratam de crimes suspeitos, ameaças e comprometimentos graves, e só esse canal pode obrigar a revelação na maioria das jurisdições.
| Channel | What it can do | What it cannot do |
|---|---|---|
| Exit operator abuse desk | Investigate, warn or suspend the account | Disclose a subscriber to a private complainant |
| Registry contact | Identify the network holder and its abuse address | Act on the incident itself |
| Law enforcement | Preserve and compel records under legal process | Move faster than your own mitigation |
Duas condições escolhem o canal. O incidente está em curso, o que favorece mitigar primeiro e denunciar em paralelo, ou é histórico, o que favorece preservar as provas antes de tudo? Você precisa que o tráfego pare, o que qualquer um dos três pode influenciar, ou precisa de uma identidade, que só a via legal pode produzir? Uma terceira condição decide quanto detalhe enviar: um operador que administra a saída precisa de detalhes técnicos, enquanto um contato de registro só precisa da faixa de endereços e do problema.
Quando o incidente é um crime em curso, a mesa de abuso e as autoridades não são alternativas. Denuncie a ambas e avise o operador de que uma solicitação legal pode seguir, para que sua própria política de retenção seja acionada.
Escreva o relatório sobre o qual o destinatário pode agir
Mantenha a mensagem curta o suficiente para ler em um minuto. Um parágrafo diz o que aconteceu e quando, um bloco lista as provas com carimbos de tempo exatos, uma linha diz o que você já fez e uma linha diz o que pede. Coloque o pedido de número de referência do caso no final, para que um analista ocupado possa responder com um número em vez de uma conversa.
Remova os segredos da cópia que você envia. Senhas, tokens de sessão, dados pessoais não relacionados e nomes de host internos não ajudam o destinatário e aumentam sua própria exposição. Guarde o original sem edição em local com acesso restrito e um hash registrado se o incidente puder se tornar prova legal. Os comandos abaixo coletam os fatos públicos sobre um endereço antes de você escrever qualquer coisa.
whois 198.51.100.7 | grep -iE 'orgname|netrange|abuse'
dig +short -x 198.51.100.7
grep '198.51.100.7' /var/log/nginx/access.log | head -n 20Substitua o endereço que você realmente observou, e note que uma faixa de documentação como a acima não retornará um registro real. Se a saída do whois nomear um provedor de hospedagem em vez da marca VPN, esse provedor é o destinatário correto, porque detém a alocação do endereço e a relação com o cliente.
Trate a resposta e mantenha o registro
O silêncio não significa que nada aconteceu. Os operadores agem rotineiramente sobre um relatório sem avisar o denunciante, tanto porque não podem divulgar informações do cliente quanto porque sua política pode proibir. Um breve reconhecimento com número de caso é o máximo que você deve esperar, e um pedido de mais detalhes técnicos é um bom sinal, não um atraso.
Não publique uma acusação contra um endereço ou provedor enquanto um relatório estiver aberto. Apontar uma saída compartilhada como culpada pune todos os outros clientes dessa saída e pode prejudicar o caso se ele mais tarde chegar a um processo legal. O guia NIST de resposta a incidentes trata a procedência e a confidencialidade dos registros de incidente como parte da resposta, não como papelada posterior.
Feche o ciclo nos seus próprios registros: o que enviou, a quem, quando e o que mudou como resultado. É esse histórico que transforma o próximo incidente de uma correria em um procedimento com um primeiro passo conhecido.