Voir une IP blacklistée fait partie de la vie d’hébergeur, le quotidien pour les plus gros ou les plus permissifs. Néanmoins, c’est une première pour LRob en 10 ans d’existence !
Les plus positifs d’entre vous diront que c’est la rançon de la gloire… Forcément, plus le volume augmente, plus le risque de voir une activité non autorisée sur un site augmente. Les plus critiques feront un scandale. Quoi qu’il en soit, chez LRob, on fait le choix de la transparence. Alors on répond à toutes vos interrogations.
Que s’est-il passé et quelles solutions mettons-nous en œuvre ? Réponses.
Découverte du blacklisting sur AbuseIPDB
Dimanche 13 Octobre, j’ai été alerté par mon client Météo Centre que son site était bloqué par l’antivirus MalwareBytes en version payante (merci à eux pour cette alerte).
Face à cette anomalie, l’urgence est sonnée pour LRob. Que l’on soit Dimanche ou le jour de Noël : j’ai immédiatement vérifié son site qui n’avait aucun souci, puis investigué auprès de MalwareBytes. La cause du blocage a été donnée en 1h seulement (bravo au support MalwareBytes) : l’IPv4 du serveur hébergeant ce site est blacklistée sur AbuseIPDB pour requêtes malveillantes. Mais manifestement, le souci provient d’un autre site.
Coup de cœur pour AbuseIPDB
Toutes les blacklists ne se valent pas (CF : SPFBL), néanmoins, AbuseIPDB est un vrai projet bien fait et sérieux.
Dans cette mauvaise nouvelle, la découverte de cette blacklist communautaire été un coup de cœur : non-seulement celle-ci m’avait permis de détecter une anomalie sur mon serveur, mais il était facile de contribuer. C’est pourquoi LRob a immédiatement rejoint AbuseIPDB pour contribuer à reporter les IP attaquantes et aider la communauté mondiale des sysadmins en retour.
Mais le plus important était cependant de stopper la source des requêtes malveillantes. Alors d’où venaient-elles ?
Une cause inattendue
Bien-sûr, j’ai immédiatement cherché la cause de ces requêtes émanant d’un de mes serveurs. Si c’est un client, cela n’est pas toléré. Si c’est un site piraté, celui-ci devait être coupé et réparé immédiatement… Si c’est une intrusion serveur, c’est gravissime. J’ai donc entamé les recherches et ce que j’ai trouvé à la fois anodin et inhabituel.
Il ne vous aura pas échappé que LRob effectue la réparation et la sécurisation de sites WordPress piratés depuis plusieurs années avec succès. Cela amène de nombreux clients à choisir un hébergement web LRob pour bénéficier de la réparation à prix réduit et d’un support à toute épreuve.
Mais récemment, un nouveau site réparé m’a joué un mauvais tour : une récidive. Un site réparé s’est à nouveau fait pirater, ce qui ne m’était encore jamais arrivé sur mes hébergements.
Cela entrant dans la garantie de 90 jours, j’ai donc réparé à nouveau ce site sans aucun frais. Mais les attaques, bien que moins fréquentes, continuaient d’arriver sur AbuseIPDB.
Au bout de 3 jours de recherches de logs infructueuses au cours des journées et soirées, j’ai finalement analysé l’ensemble du trafic réseau sur le serveur (un travail de titan), jusqu’à remonter un des processus (programmes) anormaux lancés en tant que l’utilisateur système de ce site. Eurêka ! Je tiens là la cause originelle du problème.
Comment est-ce possible ?
Je le sais désormais, dès son arrivée, ce site contenait en fait des programmes (pas juste des scripts PHP mais bel et bien des programmes) malveillants, qui ont réussi à s’exécuter dès l’importation du site. Cela signifie que même une fois supprimés, et même avec le site désactivé, les programmes malveillants continuaient de tourner. Les hackers ont donc pu utiliser cela comme vecteur d’attaque même après la réparation du site. Ils ont également pu réécrire des fichiers malveillants, générant la récidive visible.
Comme ces programmes ne tournaient pas directement via le serveur web habituel, mais indépendamment, il était impossible de détecter leur activité via les logs du serveur web, rendant la détection plus difficile (raison pour laquelle aura fallu en dernier recours analyser le trafic réseau, ce qui est inhabituel). D’autant plus que ce type de programme n’est même pas sensé pouvoir s’exécuter et pour cause : la fonction « PHP exec() » qui permet de les lancer est sensée être désactivée… Mais elle ne l’était pas pour ce client en raison d’une configuration spécifique (corrigée depuis). J’avais déjà vu ce souci sur d’autres serveurs et si ça n’avait pas été le mien, j’aurais pensé à regarder directement les process lancés et j’aurais trouvé le souci en 30 minutes… Mais ici, comme cela n’était pas sensé arriver, ça m’a pris 3 jours. Les joies du métier !
La solution immédiate
Tous les process (programmes en cours d’exécution) douteux ont bien-sûr été sauvegardés pour investigation, puis stoppés. Un checkup complet du site a été refait et une vérification manuelle 3x par jour a été mise en place pour s’assurer qu’aucune récidive n’avait lieu.
Situation actuelle
A l’heure où j’écris ces lignes, plus aucune attaque n’est reportée sur AbuseIPDB, mais la blacklist n’a pas encore été levée.
Delisting
La demande de delisting a été effectuée le jour même de la découverte du souci, et peut prendre entre 7 et 10 jours à être levée. C’est lent, et ce serait là le seul défaut d’AbuseIPDB. L’impact de ce blacklisting est heureusement assez faible en attendant cette levée.
Aucun autre site touché
Grâce à l’excellente isolation des sites web appliquée sur mes hébergements, le site piraté était cantonné à lui-même et n’a pas pu avoir d’impact sur les autres sites hébergés.
Des solutions supplémentaires à long terme
L’impact de ce blacklisting est très minime et pour preuve : seul Météo Centre m’a remonté ce souci, car ce site est probablement le plus populaire que j’héberge, ce qui leur permet de rapidement être notifiés de ce type d’informations. Merci encore à eux et à MalwareBytes pour leur réactivité dans la remontée d’informations pertinentes.
Néanmoins, il est possible un jour que certains clients souhaitent la possibilité d’éviter totalement que leur site ne soit hébergé sur une IP blacklistée à cause d’un tiers site web. Pour cela, la solution est l’adresse IP dédiée.
C’est pourquoi prochainement, je vais lancer l’option IP dédiée disponible pour tous les hébergements web LRob.
Cela nécessite quelques préparatifs car l’ajout de multiples IP sur un serveur dédié n’est pas anodin. De plus il faut que j’estime et définisse le prix de l’option. Lorsque l’option sera lancée, chaque client LRob pourra bénéficier d’une IPv4 et IPv6 dédiée s’il le souhaite.
Avec un peu d’imagination, cela pourrait également permettre des migrations de serveur sans changement d’IP, grâce aux « IP Failover » (plus coûteuses mais plus flexibles, elles peuvent être transportées d’un serveur à un autre, tant que le fournisseur de serveur reste inchangé). Cela devrait plaire à mes revendeurs n’ayant pas la main sur la zone DNS de tous leurs clients… !
L’importance de la transparence
Un service où il n’y a jamais aucune anomalie n’existe pas en ce monde. Bien-sûr, j’aurais pu cacher ce souci mineur et un seul client l’aurait remarqué. Mais chez LRob, on fait le choix montrer notre engagement à gérer toute anomalies avec rigueur et dévotion.
La transparence est la base de la confiance. Et je vous remercie pour votre confiance.
Laisser un commentaire