Non, ce n’est pas un titre « putaclic », je déteste ça !
Un nouveau service sans « putaclic »
En tant qu’hébergeur de services publics, j’ai récemment mis en place Send, un service gratuit et open source pour le partage de fichiers. Pour la petite histoire, il s’agit d’un fork de Firefox Send, un projet que Mozilla a malheureusement abandonné. Heureusement, la communauté a repris le flambeau pour le maintenir à jour et en vie.
Send est un service web de partage de fichiers chiffré de bout en bout. En plus du client web, il existe des clients pour une utilisation en ligne de commande (ffsend), pour les appareils Android et même un plugin pour Thunderbird. C’est super pratique pour échanger de gros fichiers par email.
Rien à dire : l’installation est simple, l’utilisation est intuitive, et ça fonctionne parfaitement.
Pour l’instant, je ne lui ai pas alloué une énorme quantité d’espace disque. J’aime observer la manière dont mes services sont utilisés. En général, ils trouvent leur public sans pour autant être massivement sollicités.
J’ai débuté avec 64 Go d’espace disque. Mon instance a été ajoutée à la page GitHub des instances publiques le 23 juillet, ce qui signifie qu’elle a été déployée la veille.
Tout se déroulait sans accroc, avec des sauvegardes régulières. J’ai été surpris de constater que le service avait atteint 9,46 Go de données le 14/08/2025. C’est une belle preuve de son utilité après seulement trois semaines de mise en ligne.
Le mystère de l’arrêt inattendu
Quelques jours plus tard, j’ai reçu une alerte : le service était à l’arrêt ! C’était étrange, mes services ne s’arrêtent jamais de cette manière. C’était en pleine journée, j’étais occupé, alors je n’ai pas cherché à comprendre. J’ai simplement relancé le service, et il a démarré sans problème.
Un ou deux jours se sont écoulés, et rebelote ! Une nouvelle alerte m’a prévenu que le service s’était encore arrêté. Même situation : j’étais au travail, et je ne pouvais pas enquêter immédiatement. J’ai simplement relancé le service en me disant que je m’en occuperais dans la soirée.
À mon retour le soir, j’ai tout de suite compris le problème. Mon espace disque de 64 Go était complètement saturé, en « full » rouge ! Je n’ai pas de capture d’écran des ressources de mon conteneur LXC, mais j’en ai une des sauvegardes qui raconte la suite de l’histoire.
Pendant mes investigations, le conteneur LXC Send s’est arrêté. J’ai tenté de le relancer, mais pour la première fois, j’ai eu une erreur.
run_buffer: 571 Script exited with status 1
lxc_init: 845 Failed to run lxc.hook.pre-start for container "122"
__lxc_start: 2034 Failed to initialize container "122"
TASK ERROR: startup for container '122' failedLa source du problème
C’est là que j’ai eu ma confirmation : l’erreur signalait bien un disque plein. Si un jour, vous rencontrez cette erreur, pensez à vérifier l’espace de stockage physique de votre hôte ou le disque virtuel de votre machine virtuelle.
À ce moment-là, j’ai décidé de replonger dans la documentation de Send pour m’assurer que j’avais bien compris le fonctionnement, notamment la purge et la suppression des fichiers une fois les liens expirés. En parallèle, j’ai ouvert une discussion sur le GitHub de Send pour poser ma question. Dans l’attente d’une réponse, j’ai augmenté la taille du disque du conteneur de 64 Go à 128 Go pour que le service puisse redémarrer.
Voici la question que j’ai posée sur GitHub…
Autrement dit…
Bonjour. J’ai une instance Send publique. L’instance est reprise chez vous sous le domaine send.blablalinux.be, et tout fonctionne correctement. Plusieurs fois, le service s’est arrêté, j’ai été prévenu par une alerte. À chaque fois, c’est simplement que le disque de stockage est plein. J’ai une question. Je sais très bien que les liens vers les fichiers expirent une fois la première limite atteinte. Soit le nombre de jours, soit le nombre de téléchargements. Mais après cela, le fichier est-il supprimé du disque ? Existe-t-il une tâche de nettoyage automatique qui s’en charge ? Sinon, je ne pourrai pas suivre le rythme niveau stockage.
Mode de stockage : production ou développement ?
Dès le début de ma recherche de solution, j’ai reçu des questions concernant le mode de stockage utilisé. La première était simple : « Est-ce que Send est exécuté en mode développement ou en mode production ? »
Dans la documentation, il est expliqué que :
- En mode développement, les fichiers sont stockés directement sur le disque.
- En mode production, ils sont stockés dans Redis et un bucket S3.
Pour ma part, j’ai une configuration hybride. Je suis en mode production avec Redis, mais j’utilise le stockage local au lieu d’un bucket S3 ou MinIO.
Il poursuit en disant…
Les fichiers ne sont supprimés que dans des cas spécifiques. Plus précisément, lorsqu’un utilisateur supprime le fichier ou lorsqu’il épuise le nombre maximal de téléchargements avant l’expiration du fichier.
… et que…
Dans tous les autres cas, vous êtes responsable du nettoyage des fichiers. Cela se fait normalement via une tâche cron.
C’est là que j’ai créé une série de tâches cron pour couvrir l’ensemble des durées.
0 * * * * find /root/send/uploads/ -name 1-\* -mmin +60 -exec rm {} \;
0 * * * * find /root/send/uploads/ -name 1-\* -mmin +1440 -exec rm {} \;
0 * * * * find /root/send/uploads/ -name 3-\* -mmin +4320 -exec rm {} \;
0 * * * * find /root/send/uploads/ -name 5-\* -mmin +7200 -exec rm {} \;
0 * * * * find /root/send/uploads/ -name 7-\* -mmin +10080 -exec rm {} \;
0 * * * * find /root/send/uploads/ -name \*-\* -mmin +43200 -exec rm {} \;Je vous donne le lien vers la discussion complète qui est maintenant archivée. Plein d’autres choses a été dit.
https://github.com/timvisee/send-docker-compose/issues/25
Mais le tournant, c’est ceci…
L’escalade du problème
Alors que je tentais de comprendre la situation sur GitHub, la situation a empiré. Mon disque de 128 Go, dont j’avais doublé la taille quelques heures plus tôt, était à son tour saturé !
Une nouvelle alerte m’a informé que le service était de nouveau à l’arrêt. Cette fois, impossible de le relancer : j’ai reçu le même message d’erreur que la dernière fois.
En parallèle, j’ai évoqué sur GitHub mes doutes quant à un abus de mon service. En analysant les logs de Nginx Proxy Manager (NPM), j’ai pu identifier une adresse IP bien précise : 185.112.35.143. Le problème, c’est que Fail2ban n’avait rien fait. L’utilisateur ne faisait pas de tentatives d’intrusion ou de force brute. Il utilisait le service de manière normale, mais de façon excessive. Apparemment, l’abus était commis à l’aide d’un client autre que le client web.
Le blocage de l’adresse IP
C’est là que j’ai eu ma confirmation. La personne avec qui j’échangeais m’a dit avoir remarqué le même comportement de la part de cette adresse IP, qu’elle qualifiait de « misérable ».
J’ai alors pris la décision de bloquer définitivement cette adresse IP. Mais pas avec Fail2ban, car le bannissement n’est que temporaire. J’ai préféré utiliser iptables pour un blocage permanent.
Pour un blocage immédiat, j’utilise cette commande.
iptables -A DOCKER-USER -s 185.112.35.143 -j DROPEnsuite, j’installe le paquet iptables-persistent avec cette commande.
apt install iptables-persistentLors de la configuration, répondez par « oui » lorsque le système vous demande si vous souhaitez sauvegarder les règles IPv4 et IPv6 actuelles. Ces règles seront alors enregistrées dans les fichiers rules.v4 et rules.v6.
Une fois cette étape passée, vous devez ouvrir le fichier /etc/iptables/rules.v4 pour y effacer les règles créées automatiquement par Fail2ban. Il est crucial de les retirer, car Fail2ban les gère de manière dynamique pour bloquer les adresses IP de manière temporaire, et elles ne doivent pas être conservées de manière statique.
La riposte s’organise
J’ai d’abord pensé que tout était réglé. J’ai bloqué la première adresse, et le calme est revenu. Mais la trêve fut de courte durée. J’ai rapidement constaté que le même utilisateur avait basculé sur une autre adresse IP, mais issue de la même plage.
Sans hésiter, j’ai bloqué cette nouvelle adresse. C’est à ce moment-là que j’ai réalisé que c’était une bataille sans fin. La personne sur GitHub m’a confirmé que de nombreuses adresses IP, et même des plages entières, étaient utilisées. J’ai donc pris une décision radicale : bloquer la plage complète.
iptables -A DOCKER-USER -s 185.112.35.0/24 -j DROPUn petit whois sur l’adresse IP 185.112.35.143 😉
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://docs.db.ripe.net/terms-conditions.html
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '185.112.35.0 - 185.112.35.255'
% Abuse contact for '185.112.35.0 - 185.112.35.255' is 'abuse@asiatech.ir'
inetnum: 185.112.35.0 - 185.112.35.255
netname: IR-ASIATECH-DC
descr: Asiatech Data Transmission company
descr: No.37, Miremad, Motahari street, Tehran, Iran, 1587843111
descr: FCP license 100-94-16
descr: Tel: +982191011100
descr: Fax: +982191011200
country: IR
admin-c: ATMN-RIPE
tech-c: ATTC-RIPE
status: ASSIGNED PA
mnt-by: ASIATECH-MNT
created: 2019-08-18T08:50:29Z
last-modified: 2020-03-31T14:49:53Z
source: RIPE
role: Asiatech NOC - Management Area
address: No.37, Miremad, Motahari street, Tehran, Iran
admin-c: SY88-RIPE
tech-c: SY88-RIPE
abuse-mailbox: abuse@asiatech.ir
nic-hdl: ATMN-RIPE
mnt-by: ASIATECH-MNT
created: 2014-09-27T09:16:24Z
last-modified: 2020-03-28T07:06:37Z
source: RIPE # Filtered
role: Asiatech NOC - Technical Area
address: No.37, Miremad, Motahari street, Tehran, Iran
admin-c: SY88-RIPE
tech-c: SY88-RIPE
abuse-mailbox: abuse@asiatech.ir
nic-hdl: ATTC-RIPE
mnt-by: ASIATECH-MNT
created: 2014-09-27T09:09:28Z
last-modified: 2020-03-28T06:49:35Z
source: RIPE # Filtered
% Information related to '185.112.35.0/24As43754'
route: 185.112.35.0/24
origin: As43754
mnt-by: ASIATECH-MNT
created: 2018-03-06T06:20:36Z
last-modified: 2018-03-06T06:20:36Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.118.1 (ABERDEEN)Les autres plages d’adresses IP qui pourraient être utilisées, peuvent être trouvées ICI.
Je rappelle l’adresse GitHub de la discussion complète…
https://github.com/timvisee/send-docker-compose/issues/25
Au cas où elle venait à disparaître, la voici en capture…
Le mot de la fin
Je m’excuse pour les inconvénients que cet incident a pu engendrer sur le service.
Héberger des services publics à la maison est une véritable passion, mais cela demande un investissement considérable. Ce genre de mésaventure, causée par des personnes qui ne respectent pas un service gratuit, pourrait en décourager plus d’un.
Mais cela ne m’empêchera pas de continuer à le faire et de continuer à partager ce que je fais. J’espère que l’histoire de cette mésaventure pourra servir à d’autres.
Merci de m’avoir lu.
Le lendemain
Je vérifie si le service Send n’est plus abusé 😉
Vidéo bonus
Envie d’envoyer un fichier sans quitter ton terminal ? 💻 C’est possible !
Je suis super content de te faire découvrir ffSend 🐧, l’utilitaire en ligne de commande qui me permet d’envoyer des fichiers sur le service Send directement depuis ta console. 🚀 Fini les clics, place à la magie du terminal ! ✨
Dans cette vidéo 🎥, je te montre comment installer et utiliser ffSend en quelques commandes seulement. C’est simple, rapide et super pratique ! 🔥