Como Auditar Logs de Federação do Mastodon para Identificar Padrões de Spam

Administradores de instâncias Mastodon frequentemente notam um aumento repentino de spam ou conteúdo indesejado na timeline federada. Esse tráfego geralmente se origina de servidores remotos específicos que ignoram os filtros de conteúdo locais. O Mastodon registra cada ação de federação recebida em um arquivo de log estruturado, mas a maioria dos administradores não examina esses dados em busca de padrões de spam. Este artigo explica como localizar, ler e analisar os logs de federação do Mastodon para identificar fontes de spam e bloqueá-las antes que afetem seus usuários.

Por que Padrões de Entrada de Spam Aparecem nos Logs de Federação

O Mastodon usa o protocolo ActivityPub para trocar mensagens entre instâncias. Quando um usuário remoto publica conteúdo, a instância dele envia uma requisição HTTP POST para sua instância. Seu worker Sidekiq processa essa requisição e armazena o conteúdo no banco de dados. Os logs de federação registram cada etapa desse processo, incluindo o domínio do remetente, o tipo de atividade e o código de status HTTP retornado.

Servidores de spam enviam um alto volume de requisições em um curto período, geralmente com conteúdo idêntico ou quase idêntico. Eles também podem enviar payloads JSON malformados que causam erros de processamento. Ao auditar os logs, você pode detectar três padrões comuns de spam: erros repetidos 422 Unprocessable Entity do mesmo domínio, um pico repentino de atividades Create de um único servidor e uma alta proporção de entregas com falha em relação às bem-sucedidas.

Localização e Formatos dos Arquivos de Log

O Mastodon grava logs de federação em vários locais, dependendo do método de implantação. Para instâncias baseadas em Docker, os logs são armazenados dentro do contêiner e podem ser acessados com docker logs mastodon-web. Para instalações com systemd, use journalctl para visualizar os logs do Sidekiq. Os logs padrão baseados em arquivo estão em /var/log/mastodon/ com nomes como production.log e sidekiq.log. Cada entrada de log contém um timestamp, ID do processo, nível de gravidade e uma mensagem estruturada que inclui o tipo de atividade ActivityPub e o domínio do ator.

Passos para Auditar Logs de Federação em Busca de Padrões de Spam

Os passos a seguir pressupõem que você tenha acesso SSH ao seu servidor Mastodon e possa executar comandos como um usuário com privilégios sudo. Se você usa um serviço de hospedagem gerenciada do Mastodon, pode ser necessário solicitar acesso bruto aos logs ao seu provedor.

1. Abra uma sessão de terminal no seu servidor Mastodon
   Use SSH para conectar ao servidor que executa sua instância Mastodon. Por exemplo: ssh admin@seu-ip-do-servidor. Se você usa Docker, primeiro anexe ao contêiner mastodon-web: docker exec -it mastodon-web bash.
2. Visualize logs de federação em tempo real com journalctl
   Execute sudo journalctl -u mastodon-sidekiq -f --since "24 hours ago". Este comando mostra a saída de log ao vivo do serviço Sidekiq. Pressione Ctrl+C para parar a saída. Para logs baseados em arquivo, execute tail -f /var/log/mastodon/sidekiq.log.
3. Filtre entradas de log para workers de processamento ActivityPub
   Em uma janela de terminal separada, execute sudo journalctl -u mastodon-sidekiq --since "24 hours ago" | grep "ActivityPub::ProcessingWorker". Isso isola entradas que mostram sua instância processando atividades recebidas. Cada linha inclui o domínio do ator, o tipo de atividade e o status.
4. Identifique domínios com altas taxas de erro
   Execute sudo journalctl -u mastodon-sidekiq --since "24 hours ago" | grep -E "422|500|503" | awk '{print $NF}' | sort | uniq -c | sort -nr. Este comando conta quantas respostas de erro HTTP seu servidor retornou, agrupadas por domínio. Um domínio com mais de 50 erros em 24 horas é provavelmente uma fonte de spam.
5. Verifique padrões de conteúdo duplicado
   Execute sudo journalctl -u mastodon-sidekiq --since "24 hours ago" | grep "Create" | grep -oP 'actor\":\"[^"]+' | cut -d'"' -f2 | sort | uniq -c | sort -nr | head -20. Isso lista os 20 principais domínios que enviaram atividades Create. Se um domínio aparecer centenas de vezes, examine seu conteúdo manualmente.
6. Bloqueie o domínio de spam pelo painel de administração
   Faça login na sua instância Mastodon como administrador. Vá em Preferências > Administração > Moderação > Federação. Digite o domínio problemático na caixa de pesquisa. Clique no nome do domínio e selecione Bloquear domínio. Confirme a ação. Isso impede todas as atividades futuras desse domínio.
7. Crie um script para automatizar a detecção de padrões
   Salve o script a seguir como /usr/local/bin/spam-audit.sh e torne-o executável com chmod +x /usr/local/bin/spam-audit.sh. Execute-o diariamente via cron para receber alertas por e-mail.

#!/bin/bash
LOG_ENTRIES=$(sudo journalctl -u mastodon-sidekiq --since "24 hours ago" | grep "ActivityPub::ProcessingWorker" | wc -l)
ERROR_COUNT=$(sudo journalctl -u mastodon-sidekiq --since "24 hours ago" | grep -E "422|500|503" | wc -l)
TOP_DOMAIN=$(sudo journalctl -u mastodon-sidekiq --since "24 hours ago" | grep "Create" | grep -oP 'actor\":\"[^"]+' | cut -d'"' -f2 | sort | uniq -c | sort -nr | head -1)
echo "Total de eventos de federação: $LOG_ENTRIES"
echo "Total de respostas de erro: $ERROR_COUNT"
echo "Principal candidato a domínio de spam: $TOP_DOMAIN"

Problemas Comuns ao Auditar Logs de Federação

Nenhum Log Aparece Após Executar journalctl

Se o journalctl não retornar saída, verifique se o serviço mastodon-sidekiq está em execução: sudo systemctl status mastodon-sidekiq. Se o serviço estiver inativo, inicie-o com sudo systemctl start mastodon-sidekiq. Para usuários Docker, certifique-se de que o contêiner está em execução: docker ps | grep mastodon-web.

Log Contém Muitos Erros 422 de Servidores Legítimos

Um erro 422 Unprocessable Entity pode ocorrer quando uma instância remota envia um payload ActivityPub válido que sua instância rejeita devido a uma regra local, como um requisito de aviso de conteúdo. Verifique a mensagem de erro na entrada do log. Se a mensagem disser “Record invalid” ou contiver um erro de validação, o servidor remoto provavelmente não é spam. Bloqueie apenas domínios que mostrem um padrão de erros idênticos repetidos sem conteúdo válido.

Domínios de Spam Mudam com Frequência

Operadores de spam alternam domínios para evitar bloqueios. Em vez de bloquear cada domínio manualmente, use o recurso Moderação > Federação > Lista de permissões para restringir a federação a um conjunto selecionado de instâncias confiáveis. Essa é uma medida drástica que reduz a descoberta, mas elimina o spam completamente. Alternativamente, use a variável de ambiente MASTODON_FEDERATION_ALLOWLIST para aplicar uma lista de permissões no nível da aplicação.

Comparação de Métodos de Auditoria de Logs de Federação do Mastodon

Item	journalctl (systemd)	Logs baseados em arquivo	Logs Docker
Comando	journalctl -u mastodon-sidekiq -f	tail -f /var/log/mastodon/sidekiq.log	docker logs mastodon-web –tail 50
Saída em tempo real	Sim	Sim	Sim
Pesquisa histórica	Sim, com flag –since	Sim, com grep	Não, precisa redirecionar para arquivo
Uso de espaço em disco	Baixo (journal do systemd)	Alto (texto não compactado)	Médio (arquivos JSON do Docker)
Melhor para	Implantações baseadas em systemd	Servidores Linux tradicionais	Configurações Docker Compose

Após identificar e bloquear domínios de spam usando o processo de auditoria de logs de federação, sua instância fornecerá conteúdo mais limpo aos usuários. Execute o script de auditoria semanalmente para detectar novas fontes de spam precocemente. Para proteção avançada, combine o bloqueio de domínios com o recurso Preferências > Administração > Moderação > Denúncias para permitir que os usuários denunciem contas suspeitas diretamente.