Tout administrateur système ou gestionnaire de site web a déjà connu ce moment de solitude : une tâche d’arrière-plan anodine est lancée, puis quelques minutes plus tard, les alertes de monitoring tombent. Le serveur ne répond plus, le service web est désactivé et l’hébergeur indique avoir neutralisé la machine ou l’accès web pour suspicion d’attaque ou activité anormale. Chez OVH comme chez d’autres acteurs du cloud, ce mécanisme de défense automatisé peut parfois transformer une simple opération de maintenance en arrêt de production imprévu.
Pourquoi un transfert massif déclenche-t-il les sondes d’alerte ?
Lorsqu’on lance une sauvegarde ou une migration vers une autre infrastructure en s’appuyant sur des protocoles bruts comme le FTP, le comportement réseau généré ressemble fortement à une anomalie. Les sondes de sécurité périmétrique surveillent les variations brutales de trafic :
- La multiplication des sessions concurrentes : un client FTP configuré sans limitation ouvre souvent plusieurs dizaines de connexions parallèles pour paralléliser l’envoi de fichiers. Pour un pare-feu mutualisé, ce comportement s’apparente à une attaque par force brute ou un déni de service distribué.
- L’exfiltration soudaine de données : un débit montant inhabituel sur un port non sécurisé déclenche des règles heuristiques destinées à stopper la fuite de données après l’intrusion d’un pirate.
- L’envoi massif de petits fichiers : le protocole FTP génère des requêtes TCP répétées pour chaque fichier transféré, ce qui sature la table des états de connexion (conntrack) et alerte les systèmes de protection anti-DDoS.
Comment réagir face à une mise en quarantaine ?
Lorsque le service est subitement coupé, la première priorité consiste à identifier le statut exact du serveur dans la console de gestion de l’hébergeur. Dans bien des cas, la machine ou l’hébergement mutualisé est basculé automatiquement en mode secours (rescue) ou en accès restreint.
Pour traiter rapidement l’incident avec les équipes techniques du support :
- Consultez l’alerte d’incident : le ticket généré automatiquement par la plateforme contient généralement un extrait des logs réseau ayant motivé la coupure (adresses IP sources, ports ciblés, volume constaté).
- Fournissez les éléments de preuve : confirmez immédiatement que l’IP cliente à l’origine du flux vous appartient et qu’il s’agit d’une opération administrative planifiée et non d’un botnet.
- Démontrez l’absence de compromission : indiquez les vérifications effectuées en amont (absence de processus malveillants, logs d’accès système propres).
Les méthodes pour transférer ses données sans risquer la coupure
Pour éviter les suspensions abusives, il est crucial de professionnaliser la manière dont les gros volumes sont déplacés entre deux environnements.
Avant d’initier une migration, il est recommandé de contrôler précisément l’espace et la typologie des fichiers à transférer, par exemple en apprenant à afficher la taille d’un répertoire en ligne de commande. Cela permet d’estimer la charge réseau et de segmenter les opérations par lots.
Si vous devez maintenir des transferts de fichiers ponctuels sur un poste de travail, veillez à restreindre la bande passante et le parallélisme, notamment lorsque vous décidez de monter un lecteur FTP sous Windows, car l’explorateur a tendance à multiplier les requêtes transparentes en arrière-plan.
Pour les transferts réguliers et les synchronisations de serveurs, délaissez impérativement le protocole FTP historique. Privilégiez des outils pensés pour l’administration système comme SFTP ou une synchronisation différentielle. Vous pouvez notamment configurer une sauvegarde distante propre en vous appuyant sur Rsync avec Synology ou un serveur Linux distant. Rsync ne maintient qu’un seul tunnel chiffré via SSH, limite la surcharge de sessions TCP et réduit drastiquement les risques de faux positifs auprès des firewalls des hébergeurs.
