Il arrive qu’une tâche de maintenance ordinaire se transforme en incident de production. C’est le cas classique lorsqu’on lance un script automatisé pour rapatrier ou migrer quelques gigaoctets de données via un flux FTP non chiffré, et que l’hébergeur coupe instantanément l’accès au serveur ou à l’hébergement mutualisé pour suspicion de piratage. Deux sites web tombent au tapis sans préavis, laissant l’administrateur face à un support client souvent ralenti par les procédures de sécurité.
Pourquoi les heuristiques d’OVH déclenchent un blocage brutal
Chez OVH, comme chez la majorité des grands hébergeurs d’infrastructures, la surveillance du trafic réseau repose sur des sondes de détection d’intrusion (IDS) et des règles automatisées strictes. Ces systèmes surveillent en continu la charge des commutateurs, les volumes de paquets et les modèles de requêtes suspectes.
Lorsqu’un script transfère des milliers de fichiers via FTP (File Transfer Protocol), plusieurs signaux d’alerte peuvent être activés simultanément :
- Multiplication excessive des connexions simultanées : le protocole FTP standard ouvre un canal de contrôle (port 21) et un port éphémère pour chaque transfert de fichier. Un transfert parallèle mal bridé génère un pic brutal de connexions sortantes ou entrantes ressemblant fortement à une attaque par déni de service ou à un balayage de ports.
- Exfiltration massive de données : un serveur qui se met soudainement à émettre un volume inhabituel de données vers une IP distante active les filtres anti-botnet. L’hébergeur suppose que la machine a été compromise pour dérober une base ou des fichiers sensibles.
- Signature de trafic non sécurisé : l’utilisation de scripts personnalisés sur des protocoles anciens présente souvent des anomalies dans les en-têtes ou le rythme d’émission, ce qui entraîne l’isolement automatique de l’hôte (mise en réseau de secours ou désactivation temporaire de l’instance).
Dans ce contexte de coupure brutale sans prévenir chez OVH, la procédure d’urgence isole la machine pour éviter de contaminer le reste de l’infrastructure mutualisée.
La procédure pour rétablir le service
Lorsque la coupure survient, contacter immédiatement la hotline de niveau 1 donne rarement des résultats instantanés, car les équipes de support généraliste n’ont pas la main directe sur les filtres de sécurité automatisés de la cellule Abuse.
- Consulter l’espace client (section Sécurité / Abuse) : un ticket automatique est généralement ouvert avec le rapport de détection. Ce document précise l’heure exacte de l’incident, l’adresse IP incriminée et un extrait des logs réseau ayant déclenché l’alerte.
- Arrêter immédiatement le script ou la connexion réseau : assurez-vous que la source de la perturbation est neutralisée. Si vous utilisez un client monté manuellement, comme lorsqu’on choisit de monter un lecteur FTP sous Windows, fermez les sessions persistantes pour éviter d’aggraver l’évaluation automatique de votre adresse IP.
- Répondre directement au ticket d’incident de sécurité : inutile de s’emporter. Il faut fournir une explication technique concise : l’origine de l’opération (sauvegarde légitime), l’outil utilisé, l’adresse IP de destination et les mesures correctives prises (bridage de débit, passage sur un tunnel chiffré). La cellule sécurité réactive généralement l’accès plus vite lorsqu’elle constate une maîtrise technique de la situation.
Comment transférer de gros volumes sans se faire bannir
Pour éviter ces interruptions de service pénalisantes, quelques règles d’administration système s’imposent :
Privilégiez systématiquement SFTP ou rsync via SSH avec chiffrement plutôt que le protocole FTP historique. Avec rsync, vous pouvez limiter le débit pour ne pas saturer l’interface réseau :
rsync -avz –bwlimit=5000 /var/www/ user@destination:/backup/
Pensez également à regrouper vos fichiers en une archive compressée unique avant l’envoi. Le transfert d’un seul fichier de 5 Go génère un flux continu, propre et prévisible, alors que le transfert de 100 000 images individuelles bombarde le pare-feu de micro-connexions assimilables à une attaque.
Sur un serveur dédié ou un VPS, si l’incident persiste au niveau de la couche réseau malgré la levée du blocage, pensez à inspecter les messages du noyau via un debug avec dmesg pour vérifier si la carte réseau virtuelle n’est pas restée bridée par le sous-système de virtualisation.
