O que significa uma reclamação de abuso no seu VPS

O que é, na prática, uma reclamação de abuso contra um VPS

Uma reclamação de abuso contra um VPS é um relatório sobre tráfego que saiu do seu endereço IP. O relatório é enviado para o contacto de abuso publicado para esse bloco de IP. Depois, o seu provedor encaminha-o para si e define um prazo para resposta. O contacto publicado pertence à empresa que detém o espaço de endereços. Por isso, quase nunca é você a primeira pessoa a ler um relatório sobre o seu servidor. O seu provedor associa o IP e o horário à sua conta e encaminha o relatório.

A notificação não prova que você fez algo deliberadamente. O endereço IP é o único identificador que o autor do relatório possui. Uma aplicação comprometida que envia spam às 03:00 produz o mesmo relatório que uma pessoa que envia spam às 03:00. Por isso, a resposta é a parte mais importante. É necessário informar qual foi a origem e o que foi alterado.

Quem envia o relatório e como ele chega ao seu host

Cada bloco de IP público está registado num registro regional da Internet (RIR): RIPE NCC, ARIN, APNIC, LACNIC ou AFRINIC. Cada registo publica um contacto de abuso, e é para esse endereço que os relatórios são enviados. Pode consultar o mesmo registo que o autor do relatório consulta:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

Os registos da RIPE contêm um objeto de função abuse-c: com uma linha abuse-mailbox:. Os registos da ARIN contêm OrgAbuseEmail:. O endereço publicado nesse campo recebe a reclamação. É por isso que um relatório sobre o seu servidor chega ao seu host, e não à sua caixa de entrada.

Normalmente, quem apresenta o relatório é uma máquina. Quatro tipos abrangem quase todos os casos que encontrará:

• Scanners automatizados e honeypots. Uma máquina regista uma tentativa de ligação a partir do seu IP e apresenta um relatório com o excerto do log anexado.
• Loops de feedback (FBL) operados por fornecedores de caixas de correio. O destinatário clica no botão de spam e uma cópia da mensagem regressa em ARF (formato de relatório de abuso), um formato de email estruturado para ser analisado por máquinas.
• Agentes de direitos de autor. Monitorizam enxames de torrents ou rastreiam URLs públicos. Em seguida, enviam um aviso DMCA (Digital Millennium Copyright Act) que identifica um ficheiro, o seu IP e um timestamp em UTC.
• Operadores de blocklists e engenheiros de rede. Enviam uma mensagem curta com as linhas problemáticas dos seus próprios logs.

Como a maioria dos primeiros relatórios é gerada automaticamente, uma argumentação na resposta não produz resultados. Um facto é decisivo: o que estava em execução e quando deixou de estar.

Por que o aviso vem com um prazo

O seu host também é um inquilino. O espaço de endereçamento dele fica atrás de operadoras upstream e dentro de bases de dados de reputação geridas por terceiros. As denúncias que ficam sem resposta aumentam a pontuação negativa de todo o bloco, e não apenas do seu endereço. Por isso, o prazo recebido é uma pressão que está a ser transmitida para si. Leia o período indicado no aviso e trate-o como real.

Quando há uma consequência para um caso sem resposta, normalmente ela é uma rota nula, o que significa que o tráfego para esse IP é descartado a montante, ou a suspensão da instância. O gatilho costuma ser o silêncio, e não o evento original. O que um host específico deve fazer e em que prazo está definido na política correspondente e no próprio aviso. Esses dois documentos são os únicos que devem ser citados. Não aja com base no que um fórum afirma que o provedor permite.

Spam de saída: por que o meu VPS está a enviar e-mails que não enviei

O relatório indica que o seu IP entregou e-mails a uma armadilha de spam ou que os destinatários marcaram as suas mensagens como lixo eletrónico. Quatro origens abrangem a maioria dos casos: uma aplicação web com um formulário de e-mail e sem limite de frequência, uma credencial SMTP exposta que outra pessoa está a utilizar, um servidor de e-mail que retransmite mensagens para hosts que não deveria e um login roubado numa aplicação de newsletters. Comece pela fila, porque um remetente comprometido normalmente fica visível aí:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Uma fila com milhares de mensagens para endereços que não reconhece significa que o servidor está a enviar e-mails. Em seguida, descubra quem se autenticou:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

Uma conta com uma contagem muito superior às restantes corresponde à credencial exposta. Se /var/log/mail.log não existir, o sistema não tem rsyslog instalado e as mesmas linhas estão no journal: sudo journalctl -t postfix --since '2 days ago'.

Se ninguém se autenticou, o remetente é um processo local. Verifique as regras de retransmissão e as ligações abertas:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Um Postfix padrão no Debian ou Ubuntu não retransmite mensagens para estranhos. Torna-se um open relay quando mynetworks é alargado manualmente para toda uma sub-rede de alojamento, porque todos os outros tenants dessa sub-rede passam a ter autorização para enviar através do seu servidor. Qualquer ligação à porta 25 pertencente a um processo que não seja o seu servidor de e-mail indica que um script está a enviar e-mails por conta própria, que é normalmente o comportamento de uma aplicação PHP comprometida.

Interrompa o fluxo antes de investigar e preserve as provas:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL esvazia a fila e também destrói o registo do que foi enviado, por isso faça primeiro uma cópia. Em seguida, altere todas as credenciais que a aplicação utiliza, atualize a aplicação e procure o que o intruso deixou para trás. Na maioria das vezes, um incidente de spam e um comprometimento são o mesmo evento. Por isso, siga os passos de recuperação de um VPS comprometido em vez de apenas limpar a fila.

Varredura de portas e força bruta: como é um container comprometido

Este relatório contém linhas dos logs de outro operador, com este aspeto:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

A causa quase sempre é um serviço que julgava estar protegido por firewall. Docker é um caso frequente. Publicar uma porta com -p 6379:6379 escreve regras nas chains DOCKER-USER e nat, que são avaliadas antes das regras do ufw. Por isso, ufw deny 6379 não a bloqueia e a base de dados responde a toda a Internet.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

Tudo em ss -ltnp associado a 0.0.0.0 ou [::] está a escutar no endereço público. Publique no endereço de loopback, -p 127.0.0.1:6379:6379, quando apenas o host precisar de lhe aceder. A decisão sobre onde a base de dados deve estar é independente, e executar a base de dados no Docker ou no host explica essa escolha.

Para verificar se o seu próprio servidor está a fazer uma varredura neste momento:

sudo ss -tnp state syn-sent

Muitas ligações semiabertas para vários destinos diferentes indicam uma varredura de saída em curso. Um log do kernel preenchido com nf_conntrack: table full, dropping packet indica o mesmo problema de outra perspetiva: algo está a abrir muito mais ligações do que este servidor teria qualquer motivo para abrir.

Reconstrua um container comprometido em vez de tentar limpá-lo. Não é possível provar que nada mais foi alterado no seu interior. Reconstrua-o a partir de uma imagem em que confia, restaure apenas dados em que confia e altere as chaves que esse container tinha.

Avisos de direitos de autor: que ficheiro foi realmente consultado

Um aviso DMCA identifica um URL ou um info hash de torrent, o seu IP e um timestamp em UTC. Quase todos os casos têm uma de duas causas: um diretório que o servidor web lista publicamente e que contém ficheiros multimédia, ou um cliente de torrent que continua a fazer seeding depois de concluir o download.

Compare o timestamp com o access log. O formato de log combinado do nginx coloca o status no campo 9 e o caminho do pedido no campo 7:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

Antes de concluir que nada foi servido, verifique o relógio. O aviso está em UTC e os seus logs usam o fuso horário do servidor. Por isso, um desfasamento de algumas horas pode fazer com que procure na janela errada e reporte um resultado falso negativo:

timedatectl
sudo timedatectl set-timezone UTC

Depois, corrija a causa. Remova ou restrinja o ficheiro, desative a listagem de diretórios com autoindex off; no bloco de localização do nginx e associe o cliente de torrent a uma interface que não seja a interface pública. Responda indicando o ficheiro, a alteração e a hora em que a efetuou. Se considerar que a própria alegação está errada, essa é uma questão jurídica entre si e o remetente, e o aviso indica como contestá-la. O seu host não é a entidade que decide essa questão, por isso um ticket a discutir o mérito da alegação não terá resultado.

Listagens em blocklists: por que deixou de funcionar o meu correio de saída

Este problema muitas vezes surge sem que receba qualquer mensagem. O correio de saída deixa simplesmente de ser aceite, e a mensagem de rejeição indica o motivo:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

Verifique uma listagem invertendo os quatro octetos do IP e consultando a zona da lista:

dig +short 10.113.0.203.zen.spamhaus.org

Uma resposta vazia significa que não está listado nessa lista. Uma resposta 127.0.0.x significa que está listado, e o octeto final indica qual sublista correspondeu. Uma resposta no intervalo 127.255.255.x significa que a consulta foi recusada, e não respondida, normalmente porque foi feita através de um resolver público de grande escala, que o serviço gratuito não disponibiliza. Execute novamente a consulta a partir do resolver do próprio servidor para obter um resultado real.

A remoção da listagem é feita no site do operador da lista, não através do seu host, e só se mantém se corrigir primeiro a origem do problema, porque a armadilha que o listou voltará a listá-lo na mensagem seguinte. Duas outras condições determinam se o correio volta a fluir. O seu registo PTR, o nome de DNS inverso do IP, é controlado pelo seu host. Peça-lhes que definam um nome que resolva para o mesmo endereço e use esse nome como HELO. Além disso, um endereço reutilizado de um inquilino anterior pode ter um histórico que não foi criado por si. Vale a pena perguntar sobre isso antes de passar uma semana a reescrever o DNS. A configuração correta dos registos SPF (sender policy framework) e DKIM (domainkeys identified mail), juntamente com a política DMARC que os associa, é explicada de ponta a ponta em o guia para executar o seu próprio servidor de correio com Mailcow.

Infraestrutura de relay, em que responder a mensagens de abuso faz parte do trabalho

Se executar um nó de saída Tor, uma VPN pública ou um proxy para terceiros, as reclamações sobre tráfego que não gerou são um custo operacional normal. O trabalho consiste em deixar claro que o sistema é um relay, e não um servidor comprometido. Configure o DNS reverso com um nome descritivo, disponibilize uma página curta de informação na porta 80 que explique a função do endereço, responda rapidamente às mensagens de abuso com a mesma explicação e use a política disponibilizada pelo software para bloquear as portas que geram mais relatórios. Execute o serviço no seu próprio endereço IP e, idealmente, na sua própria instância, para que uma rota nula aplicada a esse endereço não interrompa também a sua aplicação web. Consulte o seu provedor antes de começar, porque as regras variam entre empresas e, por vezes, entre blocos de IP. Essa é uma questão para o provedor, não para uma discussão num fórum. Executar um nó de saída Tor numa VPS explica detalhadamente a política de saída e a página de informação.

Como responder para fechar o ticket

• Publique um contacto que seja lido por uma pessoa. A RFC 2142 define abuse@ e postmaster@ no seu domínio como os endereços que os autores das denúncias tentam primeiro. Aloje essa caixa de correio noutro local que não seja o servidor que ela protege, porque uma instância suspensa não consegue enviar o aviso a informar que foi suspensa.
• Conserve os logs durante tempo suficiente para conseguir responder. Não é possível responder a uma denúncia sobre tráfego de doze dias atrás se o log foi rodado ao fim de sete dias. Verifique journalctl --disk-usage, defina MaxRetentionSec=90d em /etc/systemd/journald.conf e depois execute sudo systemctl restart systemd-journald. Os logs web e de correio rodam segundo o seu próprio calendário em /etc/logrotate.d/.
• Mantenha o servidor em UTC, para que um timestamp numa denúncia corresponda a um timestamp nos seus logs sem ser necessário fazer cálculos.
• Separe o que atrai denúncias do que não pode perder. Coloque o correio num endereço, a aplicação web noutro e os serviços de relay na sua própria instância. Uma ação aplicada a um IP afeta tudo o que está por trás dele.
• Responda dentro do prazo mesmo que a investigação ainda não esteja concluída. Uma resposta provisória com uma hora definida é uma resposta completa para a primeira ronda.

Uma primeira resposta que fecha a maioria dos tickets é curta e específica:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

Diga o que sabe e o que ainda não conseguiu determinar. O silêncio transmite a ideia de um servidor sem manutenção, e o processo de escalada existe para servidores sem manutenção. A responsabilidade por este trabalho depende do produto que comprou. Essa é a diferença prática entre alojamento VPS gerido e não gerido. Num plano não gerido, o cliente é a equipa de segurança.

Como isto funciona quando tudo corre bem

Uma denúncia de abuso é, antes de mais, um problema de encaminhamento. Um relatório sobre um endereço chega à entidade responsável por esse endereço e é encaminhado para a pessoa que pode resolver o problema. As partes sob o seu controlo são o seu endereço de contacto, a retenção dos logs, a forma como os seus serviços estão distribuídos pelos IPs e a rapidez com que responde. Se tratar destes pontos corretamente, a maioria das notificações termina após uma única troca de mensagens. Os mesmos hábitos ajudam a responder à questão mais ampla de se o alojamento VPS é seguro, porque um servidor que ninguém monitoriza é o que acaba nos logs de outra pessoa.

FAQ

Uma queixa de abuso significa que o meu VPS foi comprometido?

Não por si só, mas essa é a primeira hipótese que deve excluir. A denúncia prova apenas que saiu tráfego do seu IP. Spam enviado e varrimentos de portas resultam muito mais frequentemente de uma aplicação ou de um contentor comprometido do que do titular da conta. Por isso, verifique primeiro a fila de correio com sudo postqueue -p e os sockets em escuta com sudo ss -ltnp. As notificações de direitos de autor e de blocklists têm uma natureza diferente: normalmente apontam para algo que está a executar de forma intencional.

Quanto tempo tenho para responder a uma notificação de abuso?

O prazo está indicado na notificação que recebeu e varia consoante o fornecedor e a categoria. As denúncias de direitos de autor e de spam traps tendem a ter os prazos mais curtos. Considere o prazo indicado como efetivo e envie uma resposta breve de acompanhamento antes de expirar, mesmo que ainda esteja a investigar a causa. O que importa para a pessoa que trata do ticket é saber que alguém está a tratar do caso e que o tráfego parou.

O meu IP está numa blocklist. O meu fornecedor pode removê-lo?

Não. A remoção é feita pelo operador dessa lista, no próprio site, e o seu fornecedor não controla a respetiva base de dados. O seu fornecedor controla o registo PTR, o nome de reverse DNS do seu IP, e vale a pena fazer esse pedido separadamente ao mesmo tempo. Corrija o problema de envio antes de pedir a remoção, porque o spam trap que adicionou o seu IP à lista voltará a fazê-lo na mensagem seguinte.

Tenho de dizer ao meu fornecedor o que aconteceu realmente?

Tem de fornecer informação suficiente para fechar o ticket: qual foi a origem e quando parou. Não tem de fornecer um relatório forense nem os dados dos seus utilizadores. Uma resposta vaga é pior do que uma resposta curta, porque quem trata do caso não consegue ver o que mudou e não tem motivos para o considerar resolvido.

Posso ignorar uma denúncia automatizada de um scanner?

Não. As denúncias automatizadas são contabilizadas, e denúncias repetidas sobre um IP aumentam a pontuação contra todo o bloco de endereços do seu fornecedor. É isso que transforma um caso pequeno numa escalada. A sua resposta pode ter apenas um parágrafo. Normalmente, o sistema que enviou a denúncia nunca a lê, mas a pessoa que trata do ticket no seu fornecedor lê-a. É essa pessoa que decide o que acontece à sua instância.