Plainte pour abus VPS : que signifie ce signalement ?

Ce qu’est réellement une plainte pour abus concernant un VPS

Une plainte pour abus concernant un VPS est un signalement au sujet d’un trafic réseau provenant de votre adresse IP. Il est envoyé au contact abuse publié pour le bloc d’adresses concerné, puis votre hébergeur vous le transmet avec un délai pour répondre. Le contact publié appartient à l’entreprise qui détient l’espace d’adressage. La première personne à lire un signalement concernant votre serveur n’est donc presque jamais vous. Votre hébergeur associe l’adresse IP et l’horodatage à votre compte, puis vous le transmet.

La notification ne prouve pas que vous avez agi volontairement. L’adresse IP est le seul identifiant dont dispose l’auteur du signalement. Une application compromise qui envoie du spam à 03:00 génère le même signalement qu’une personne qui envoie du spam à 03:00. C’est pourquoi la réponse est l’élément important. On vous demande quelle était la source du trafic et quelles mesures vous avez prises.

Qui envoie le signalement et comment arrive-t-il sur votre hôte

Chaque bloc d’adresses IP publiques est enregistré auprès d’un registre Internet régional (RIR) : RIPE NCC, ARIN, APNIC, LACNIC ou AFRINIC. Chaque enregistrement publie un contact abuse, et c’est à cette adresse que les signalements sont envoyés. Vous pouvez consulter le même enregistrement que l’expéditeur :

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

Les enregistrements RIPE contiennent un objet de rôle abuse-c: qui comporte une ligne abuse-mailbox:. Les enregistrements ARIN contiennent OrgAbuseEmail:. Toute adresse publiée à cet endroit reçoit la plainte. C’est pourquoi un signalement concernant votre serveur arrive sur votre hôte et non dans votre boîte de réception.

Le signalement est généralement envoyé par une machine. Quatre catégories couvrent presque tous les cas rencontrés :

• Scanners automatisés et honeypots. Une machine enregistre une tentative de connexion depuis votre adresse IP et envoie un signalement avec l’extrait du journal en pièce jointe.
• Boucles de rétroaction (FBL) gérées par les fournisseurs de messagerie. Un destinataire clique sur le bouton de signalement comme courrier indésirable, puis une copie du message revient au format ARF (abuse reporting format), un format de courrier structuré conçu pour être analysé par des machines.
• Agents chargés des droits d’auteur. Ils surveillent les essaims torrent ou parcourent les URL publiques, puis envoient une notification DMCA (digital millennium copyright act) indiquant un fichier, votre adresse IP et un horodatage en UTC.
• Opérateurs de blocklists et ingénieurs réseau. Ils envoient un court message contenant les lignes problématiques extraites de leurs propres journaux.

Comme la plupart des premiers signalements sont générés automatiquement, un argument dans la réponse ne sert à rien. Un fait, en revanche, est déterminant : ce qui fonctionnait et à quel moment cela s’est arrêté.

Pourquoi l’avis comporte-t-il un délai

Votre hôte est lui aussi un locataire. Son espace d’adressage se trouve derrière des opérateurs upstream et dans des bases de réputation gérées par d’autres acteurs. Les signalements qui restent sans réponse dégradent la réputation de tout le bloc, et pas seulement celle de votre adresse. Le délai indiqué est donc une pression répercutée vers vous. Respectez le délai mentionné dans l’avis et considérez-le comme réel.

Lorsqu’un dossier sans réponse entraîne une mesure, il s’agit généralement d’une null route : le trafic vers cette adresse IP est abandonné en amont, ou bien l’instance est suspendue. Le déclencheur est normalement l’absence de réponse, et non l’événement initial. Les mesures appliquées par un hébergeur donné, ainsi que leurs délais, sont définies dans sa propre policy et dans l’avis lui-même. Ce sont les deux seuls documents qui font foi. N’agissez donc pas sur la base de ce qu’affirme un forum au sujet de ce qu’un fournisseur autoriserait.

Courrier sortant indésirable : pourquoi mon VPS envoie-t-il des messages que je n’ai pas envoyés ?

Le rapport indique que votre adresse IP a remis des messages à une spamtrap, ou que des destinataires ont marqué vos messages comme indésirables. Quatre sources couvrent la plupart des cas : une application web dotée d’un formulaire d’envoi sans limitation de débit, un identifiant SMTP divulgué désormais utilisé par un tiers, un serveur de messagerie qui relaie les messages d’hôtes qui ne devraient pas y être autorisés, ou un compte d’accès volé sur une application de newsletter. Commencez par la file d’attente, car un expéditeur compromis y est généralement visible :

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

Une file d’attente contenant des milliers de messages destinés à des adresses que vous ne reconnaissez pas signifie que la machine envoie des messages. Déterminez ensuite qui s’est authentifié :

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

Un compte dont le nombre de connexions est très supérieur à celui des autres correspond à l’identifiant divulgué. Si /var/log/mail.log n’existe pas, rsyslog n’est pas installé sur le système et les mêmes lignes se trouvent dans le journal : sudo journalctl -t postfix --since '2 days ago'.

Si aucun compte ne s’est authentifié, l’expéditeur est un processus local. Vérifiez les règles de relais et les connexions ouvertes :

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

Une installation standard de Postfix sur Debian ou Ubuntu ne relaie pas les messages pour des tiers. Elle devient un open relay lorsque mynetworks est élargi manuellement à l’ensemble d’un sous-réseau d’hébergement, car tous les autres tenants de ce sous-réseau sont alors autorisés à envoyer des messages via votre serveur. Toute connexion au port 25 détenue par un processus qui n’est pas votre serveur de messagerie indique qu’un script envoie lui-même des messages. C’est généralement ce que fait une application PHP compromise.

Interrompez le flux avant d’enquêter, et conservez les éléments de preuve :

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

sudo postsuper -d ALL vide la file d’attente et détruit également l’historique des messages envoyés. Effectuez donc d’abord la copie. Faites ensuite tourner tous les identifiants utilisés par l’application, mettez l’application à jour et recherchez ce que l’intrus a laissé derrière lui. Un incident de spam et une compromission correspondent le plus souvent au même événement. Suivez donc les étapes de récupération d’un VPS compromis au lieu de vous contenter de vider la file d’attente.

Analyse des ports et brute force : à quoi ressemble un conteneur compromis

Ce rapport contient des lignes provenant des journaux d’un autre opérateur. Elles ressemblent à ceci :

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

La cause est presque toujours un service que vous pensiez protégé par le pare-feu. Docker est souvent en cause. La publication d’un port avec -p 6379:6379 écrit des règles dans les chaînes DOCKER-USER et nat. Ces chaînes sont évaluées avant les règles d’ufw. Par conséquent, ufw deny 6379 ne bloque pas le trafic et la base de données répond à tout Internet.

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

Tout ce qui se trouve dans ss -ltnp et qui est lié à 0.0.0.0 ou [::] écoute sur l’adresse publique. Publiez plutôt le port sur l’adresse loopback, -p 127.0.0.1:6379:6379, lorsque seul l’hôte doit y accéder. Le choix de l’emplacement initial de la base de données est une décision distincte. L’article exécuter la base de données dans Docker ou sur l’hôte présente les compromis correspondants.

Pour vérifier si votre propre serveur effectue actuellement une analyse :

sudo ss -tnp state syn-sent

De nombreuses connexions semi-ouvertes vers des destinations très différentes indiquent qu’une analyse sortante est en cours. Un journal du kernel qui se remplit de nf_conntrack: table full, dropping packet indique la même chose sous un autre angle : quelque chose ouvre beaucoup plus de connexions que ce serveur n’a de raison d’en ouvrir.

Reconstruisez un conteneur compromis au lieu de tenter de le nettoyer. Vous ne pouvez pas prouver que rien d’autre n’a été modifié à l’intérieur. Reconstruisez-le donc à partir d’une image de confiance, restaurez uniquement les données auxquelles vous faites confiance et faites tourner les clés détenues par ce conteneur.

Mentions de droits d’auteur : quel fichier ont-elles réellement vu

Une notification DMCA indique une URL ou un info hash de torrent, votre adresse IP et un horodatage en UTC. Deux causes couvrent presque tous les cas : un répertoire que le serveur web expose publiquement et qui contient des fichiers multimédias, ou un client torrent qui continue de seeder une fois le téléchargement terminé.

Comparez l’horodatage avec l’access log. Le format combined des logs nginx place le status dans le champ 9 et le chemin demandé dans le champ 7 :

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

Avant de conclure qu’aucun contenu n’a été servi, vérifiez l’horloge. La notification est en UTC, tandis que vos logs utilisent le fuseau horaire du serveur. Un décalage de quelques heures vous fait rechercher la mauvaise période et conduit à un faux négatif :

timedatectl
sudo timedatectl set-timezone UTC

Corrigez ensuite la cause. Supprimez ou restreignez le fichier, désactivez le directory listing avec autoindex off; dans le bloc location de nginx, et liez le client torrent à une interface qui n’est pas l’interface publique. Répondez en indiquant le fichier, la modification effectuée et l’heure à laquelle vous l’avez appliquée. Si vous pensez que la réclamation elle-même est infondée, il s’agit d’une question juridique entre vous et l’expéditeur, et la notification indique comment la contester. Votre hébergeur n’est pas la partie chargée de trancher cette question. Un ticket qui conteste le bien-fondé de la réclamation n’aboutira pas.

Listes de blocage : pourquoi mes e-mails sortants ne sont-ils plus envoyés ?

Ce problème se manifeste souvent sans qu’aucun e-mail ne vous parvienne. Les e-mails sortants cessent simplement d’être acceptés, et le message de retour indique la raison :

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

Vérifiez une inscription en inversant les quatre octets de l’adresse IP, puis en interrogeant la zone de la liste :

dig +short 10.113.0.203.zen.spamhaus.org

Une réponse vide signifie que votre adresse n’y figure pas. Une réponse 127.0.0.x signifie qu’elle y figure, et le dernier octet indique quelle sous-liste correspond. Une réponse dans la plage 127.255.255.x signifie que la requête a été refusée au lieu de recevoir une réponse, généralement parce qu’elle est passée par un grand résolveur public, auquel le service gratuit ne répond pas. Relancez la requête depuis le résolveur du serveur pour obtenir un résultat fiable.

Le retrait de la liste se demande sur le site de l’opérateur, et non auprès de votre hébergeur. Il ne reste effectif que si vous corrigez d’abord la source du problème, car le piège qui vous a inscrit vous inscrira de nouveau au message suivant. Deux autres points déterminent ensuite si les e-mails peuvent être remis. Votre enregistrement PTR, c’est-à-dire le nom DNS inverse de l’adresse IP, est géré par votre hébergeur. Demandez-lui d’en définir un qui résout vers la même adresse, puis utilisez ce nom comme valeur de HELO. Une adresse réattribuée après avoir été utilisée par un autre client peut aussi conserver un historique que vous n’avez pas créé. Il est donc utile de vous renseigner avant de passer une semaine à réécrire la configuration DNS. La configuration correcte des enregistrements SPF (sender policy framework) et DKIM (domainkeys identified mail), ainsi que de la politique DMARC qui les associe, est expliquée de bout en bout dans le guide pour gérer votre propre serveur de messagerie avec Mailcow.

L’infrastructure de relais, où les e-mails d’abus font partie du travail

Si vous exploitez un nœud de sortie Tor, un VPN public ou un proxy pour d’autres personnes, les plaintes concernant du trafic que vous n’avez pas généré font partie des coûts normaux d’exploitation. Votre objectif est que l’infrastructure ressemble clairement à un relais, et non à un serveur compromis. Configurez un reverse DNS avec un nom explicite, servez sur le port 80 une courte page d’information qui explique l’usage de l’adresse, répondez rapidement aux e-mails d’abus avec la même explication et utilisez les options de configuration du logiciel pour bloquer les ports à l’origine du plus grand nombre de signalements. Exécutez ce service sur sa propre adresse IP, et si possible dans sa propre instance, afin qu’une null route appliquée à cette adresse ne rende pas votre application web indisponible. Demandez l’autorisation à votre hébergeur avant de commencer, car les règles varient selon l’entreprise et parfois selon le bloc IP. Cette question doit être posée à l’hébergeur, pas dans un fil de discussion sur un forum. Exploiter un nœud de sortie Tor sur un VPS présente en détail l’exit policy et la page d’information.

Comment répondre pour clôturer le ticket

• Publiez une adresse de contact réellement consultée. La RFC 2142 définit abuse@ et postmaster@ sur votre domaine comme les adresses que les signalements essaient en premier. Hébergez cette boîte aux lettres ailleurs que sur le serveur qu’elle protège, car une instance suspendue ne peut pas envoyer le message vous informant de sa suspension.
• Conservez les journaux assez longtemps pour pouvoir répondre. Il est impossible de répondre à un signalement concernant du trafic datant de douze jours si le journal a été renouvelé après sept jours. Vérifiez journalctl --disk-usage, définissez MaxRetentionSec=90d dans /etc/systemd/journald.conf, puis exécutez sudo systemctl restart systemd-journald. Les journaux web et mail sont renouvelés selon leur propre calendrier sous /etc/logrotate.d/.
• Utilisez UTC sur le serveur, afin qu’un horodatage indiqué dans un signalement corresponde à celui de vos journaux, sans calcul intermédiaire.
• Séparez ce qui attire les réclamations de ce que vous ne pouvez pas perdre. Placez la messagerie sur une adresse, l’application web sur une autre et les services de relais sur leur propre instance. Toute action visant une adresse IP s’applique à tout ce qui se trouve derrière celle-ci.
• Répondez dans le délai imparti, même si l’enquête n’est pas terminée. Une réponse d’attente indiquant une échéance constitue une réponse complète pour le premier échange.

Une première réponse qui permet de clôturer la plupart des tickets doit être courte et précise :

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.

Indiquez ce que vous savez et ce qui reste à établir. Le silence donne l’impression que le serveur n’est pas maintenu, et la procédure d’escalade existe pour les serveurs qui ne sont pas maintenus. La responsabilité de ces opérations dépend entièrement du produit que vous avez acheté. C’est la différence pratique entre l’hébergement VPS managé et non managé. Avec une offre non managée, le locataire constitue l’équipe de sécurité.

À quoi cela ressemble lorsque tout se passe bien

Une plainte pour abus est d’abord un problème d’acheminement. Un signalement concernant une adresse est envoyé à la partie responsable de cette adresse, puis transmis à la personne qui peut résoudre le problème. Les éléments que vous contrôlez sont votre adresse de contact, la durée de conservation de vos journaux, la répartition de vos services entre les adresses IP et la rapidité avec laquelle vous répondez. Si ces éléments sont correctement configurés, la plupart des notifications se terminent après un seul échange. Ces mêmes pratiques répondent à la question plus générale de la sécurité de l’hébergement VPS, car un serveur qui n’est pas surveillé finit dans les journaux de quelqu’un d’autre.

FAQ

Une plainte pour abus signifie-t-elle que mon VPS a été piraté ?

Pas à elle seule, mais c’est le premier point à vérifier. Le signalement prouve uniquement que du trafic est sorti de votre adresse IP. Le spam sortant et le port scanning proviennent bien plus souvent d’une application ou d’un conteneur compromis que du propriétaire du compte. Vérifiez donc d’abord la mail queue avec sudo postqueue -p et les sockets en écoute avec sudo ss -ltnp. Les signalements liés aux droits d’auteur et aux blocklists sont différents : ils indiquent généralement quelque chose que vous exécutez volontairement.

De combien de temps est-ce que je dispose pour répondre à une notification d’abus ?

Le délai figure dans la notification reçue et varie selon l’hébergeur et la catégorie du signalement. Les signalements liés aux droits d’auteur et aux spam traps ont généralement les délais les plus courts. Considérez le délai indiqué comme impératif et envoyez une courte réponse d’attente avant son expiration, même si vous êtes encore en train d’identifier la cause. Pour la personne qui traite le ticket, l’essentiel est de savoir qu’une personne s’en occupe et que le trafic a cessé.

Mon adresse IP figure sur une blocklist. Mon hébergeur peut-il la supprimer ?

Non. Le retrait est effectué par l’opérateur de cette liste, sur son propre site, et votre hébergeur n’a aucun contrôle sur sa base de données. En revanche, votre hébergeur contrôle l’enregistrement PTR, c’est-à-dire le nom DNS inverse de votre adresse IP. Il est utile de faire cette demande séparément au même moment. Corrigez le problème d’envoi avant de demander le retrait de la liste, car le spam trap qui vous a ajouté à la liste vous y ajoutera de nouveau au prochain message.

Dois-je expliquer à mon hébergeur ce qui s’est réellement passé ?

Vous devez lui fournir assez d’informations pour clôturer le ticket : quelle était la source du problème et quand il a cessé. Vous n’avez pas à fournir un rapport forensique ni les données de vos utilisateurs. Une réponse vague est pire qu’une réponse courte, car la personne qui traite le ticket ne peut pas considérer le problème comme résolu si elle ne voit pas ce qui a changé.

Puis-je ignorer un signalement automatisé provenant d’un scanner ?

Non. Les signalements automatisés sont comptabilisés. Des signalements répétés concernant une même adresse IP augmentent le score associé à tout le bloc d’adresses de votre hébergeur, ce qui peut transformer un incident limité en escalade. Votre réponse peut tenir en un paragraphe. Le système qui génère automatiquement le signalement ne la lit généralement jamais, mais la personne qui traite le ticket chez votre hébergeur la lit. C’est elle qui décide du traitement réservé à votre instance.