S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

Nous avons laissé sept VPS sur Internet, ils sont attaqués 10 000 fois par jour en moyenne

Very Particular Service

Nous avons laissé sept VPS sur Internet, ils sont attaqués 10 000 fois par jour en moyenne

Un serveur, fraîchement installé et à peine connecté sur Internet, n’a que quelques dizaines de secondes de répit avant une première tentative d’accès frauduleux. Puis, la tempête ne s’arrête jamais, avec en moyenne plus de 10 000 tentatives par jour.

Le 09 mars à 09h33

Depuis plusieurs semaines, nous nous sommes lancés dans des tests et comparatifs de VPS (serveur privé virtuel). Nous en avons profité pour les laisser tourner, à vide ou presque. Ils sont dans leur configuration par défaut, avec le système d’exploitation installé lors de la livraison.

Quatre semaines plus tard, nous récupérons les logs des sept serveurs pour analyser les tentatives de connexion sur le port 22, celui pour SSH (Secure Shell). Ce dernier est « une méthode permettant d’envoyer, de manière sécurisée, des commandes à un ordinateur sur un réseau non sécurisé », rappelle Cloudflare. Via des logiciels comme PuTTY, par exemple, on peut se connecter à distance sur un serveur et réaliser toutes les opérations que l’on souhaite.

IBM précise que de son côté que « la plupart des robots automatisés tentent de se connecter à votre serveur SSH sur le port 22 en tant que root avec diverses combinaisons de force brute et de dictionnaire afin d’accéder à vos données ». Une connexion à distance en « root » laisserait l’intégralité de votre serveur à la merci des pirates.

Entre 6 500 et 14 000 tentatives par jour, en moyenne

Avez-vous un ordre d’idée du nombre de tentatives de connexion que subissent des serveurs sur Internet ? Selon nos mesures sur 25 jours d’expérimentation, la moyenne est aux alentours de… 10 000 attaques par jour et par serveur. Dans les logs, nous comptabilisons deux types d’événements. ECHEC, c’est-à-dire quand l’utilisateur existe, mais que le mot de passe est faux. ECHEC_USER_INVALIDE, quand l’utilisateur n’existe pas sur le serveur (le serveur ferme la connexion avant même de demander un mot de passe).

Voici un tableau récapitulatif des tentatives sur chacun des VPS :

Il reste 55% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (76)

votre avatar
@SébastienGavois Peux-tu confirmer, mais je subodore qu'ils ont été attaqués en IPv4 ?
votre avatar
Oui. IPv4 :chinois:
votre avatar
Normalement, en IPv6, c'est plus compliqué (le scan est impossible en théorie).

Par contre, si vous hébergez des services et que des noms de domaines pointent dessus, là, ce serait intéressant de voir s'il y a des attaques en IPv6 desssus.
votre avatar
Avez-vous regardé ce qu'il en était en IPv6 ?
votre avatar
pour suivre l'idée, les plages IPv4 des providers cloud sont prédictibles (AS) donc c'est certainement ping en continu quel que soit l'état provisionnedd ou pas de l'IP
votre avatar
Donc en auto hébergeant un serveur on serait moins exposé à ces attaques ?
votre avatar
Du tout, sur mon NAS j'avais négligé une règle sur le firewall, ~13 000 tentatives/jour. Toujours sur root ou admin avec des variantes chiffrées (admin123).
Souvent en provenance d'Allemagne chez un hébergeur.. de VPS.
votre avatar
même sans être prédictible, il y a suffisamment "peu" d'IPv4 (à peine 4 milliards) pour automatiser un scan régulier. Même une IP d'un FAI, il vaut mieux éviter de mettre quelque chose derrière sans protection ;)
votre avatar
même sans être prédictible, il y a suffisamment "peu" d'IPv4 (à peine 4 milliards) pour automatiser un scan régulier. Même une IP d'un FAI, il vaut mieux éviter de mettre quelque chose derrière sans protection ;)
Tu verrais le nombre de personnes très intéressées par wp-admin ou .env sur mon instance FreshRSS :mdr:
votre avatar
Il y a des solutions a cela. Changer le port de SSH n’améliore pas la sécurité mais réduit fortement le "bruit".
fail2ban avec des règles un peu strictes permet de bloquer les IP après 3 tentative de login infructueuses.
La technique du "port-knocking" permet de rendre indétectable le port ouvert pour SSH.
On peut utiliser la directive AllowGroups dans sshd_config pour que seuls les membres d'un groupe ne soit autorises a se connecter. Cela dégage tous les comptes robotiques présent et future.
Enfin il y a les bonnes pratique que l'on vois partout : "PermitRootLogin no", "PubkeyAuthentication yes", "PasswordAuthentication no".
Il existe des services de réputation d'IP qui vous donneront les IP qui attaquent en ce moment.
Exemple : https://iplists.firehol.org/?ipset=firehol_level2
votre avatar
Ce serait intéressant, en effet, de faire ces essais pour voir l'impact positif de l'une ou l'autre de ces contre-mesures.
votre avatar
Sur mon serveur j’ai mis en place du port-knocking, super efficace vu que le port est fermé en temps normal. Ou plutôt redirigé vers un serveur SSH fake pour faire un tarpit: github.com GitHub
En gros le faux server SSH accepte les connections mais la fait trainer pour que les bots restent coincé et gaspillent leur temps. Super fun !

Si on installe tous ça, ont pourra faire augmenter les coûts de ces scan !
votre avatar
Je ne connaissais pas le terme de "port knocking", par contre ce que tu décris ensuite est un "honey pot". J'ai déjà utilisé cela en prod il y a longtemps pour évincer les IP concernées des serveurs réels.
votre avatar
Super merci. Le formatage du fichier est compatible Fortigate :)
votre avatar
Utiliser un login non classique voir aléatoire et désactiver les autres comptes diminue déjà très fortement la surface d'attaque SSH, voir quasiment l'annule pour les attaques automatisées
votre avatar
Plus de 11 000 IP différentes [...]
Je trouve ça étrange qu'il y en a autant.
Si on somme les IP différentes vu pour chaque fournisseur, on arrive à 17 718 IP. Soit à peine plus que le nombre total d'IP différentes.
Ce qui veut dire qu'une bonne partie des IP sont spécialisées chez des fournisseurs de service, et pas qu'ils scannent l'intégralité du web / des fournisseurs.
votre avatar
Le port 22 est très scanné mais ce ne sont pas forcement des attaques dangereuses.
Selon Firehol levl2 on est plutôt entre 30k et 40k IP qui attaquent en ce moment.
https://iplists.firehol.org/?ipset=firehol_level2
votre avatar
j'y croyait pas, donc je suis allé voir le journal sur mon VPS (infomaniak), en effet, une tentative toutes les qq secondes... ( commande journalctl -f ), ca donne un peut le tournis d'imaginer la quantité de trafic nuisible qui traine sur internet...

La d'un coup, immense point positif à l'IP V6, qui va rendre ce genre de pêche au chalut impossible.
votre avatar
Avez-vous regardé ce que ça donne pour un serveur (NAS, Pi, ...) installé chez un particulier ?
votre avatar
Ça se fait également attaquer, dans des ordres de grandeurs similaires. Dès qu'un port est ouvert, c'est la foire...
votre avatar
Internet Storm Center surveille le survival time d'un PC non patché directement exposé sur Internet depuis 2003.
En 2010 c'était 20 minutes sous Windows, contre 40 minutes au début.
Je n'ai pas les derniers chiffres qui se sont raccourcis et doivent s'exprimer en secondes, mais l'idée est qu'il faut a minima patcher et protéger avant d'exposer, puis probablement réagir (bannissement, réputation IP...).
votre avatar
Impressionnant ces chiffres ! Et pourtant j'ai conscience que tout ce qui est accessible depuis le net est scanné et soumis à des tentatives de connexions. Je le vois avec mon NAS qui expose quelques services sur le web, mais heureusement je n'ai pas ce niveau d'attaque.
Y a pleins de manière de limiter la surface d'attaque d'un VPS. En l'occurence, de mon côté, au delà de changer le port et le username, je suis surtout très content de m'appuyer sur Netbird (Open Source, mais propose aussi une version SaaS avec un plan gratuit suffisant pour les particuliers) qui crée un réseau privé entre mes machines de confiance. Comme ça exit l'exposition du SSH et d'autres services déployés sur mon VPS sur le web, ils ne le sont qu'au travers de ce vnet privé.
votre avatar
J'ai un NAS Synology. Comment peut-on voir ces tentatives ? Y a t-il des choses à activer pour que ça apparaisse dans les logs ?
votre avatar
Je te réponds de mémoire mais il me semble que dans la partie administration, tu as une rubrique concernant le bannissement des adresses IP (le logo est les lettres IP dans un cercle rouge barré). Tu définis le nombre maxi de tentatives infructueuses et le laps de temps considéré avant de bannir une adresse IP. Tu peux voir dans le journal la liste des adresses bannies, les ré-autoriser (lorsque c'est toi ou un de tes utilisateurs qui s'est planté), et la raison du bannissement.
votre avatar
Tu peux avoirs des IP /range en liste blanche pour tes IP sur ton réseau interne.
Ca évite les problématique d'avoir besoin d'un pc pour débloquer un PC ^^

Sur les routeurs Syno, le principe de géoloc avec une map est inclus via Thread Prevention il me semble.
votre avatar
Sur un Synology tu vois ça dans le "Centre de journaux", onglet "Journaux", sélection "local" et "connexions". Si on a beaucoup de connexions, la Geo-IP dégrossi pas mal les tentatives illégitime.
votre avatar
Sur mon syno, c'est marrant car ça dépend des jours : certains jours j'ai des centaines de connexions (99% du temps ce sont des tentatives sous le log "admin"), et d'autres périodes, rien pendant des semaines. Là, par exemple, ça fait 15 jours rien. Je me demande ce que Synology préfiltre dans cette masse, mais apparemment ils doivent se faire déborder de temps en temps ?

Sinon, autre fun fact, les tentatives sont par batch espacées majoritairement entre 3 à 5 min. Y'a un facteur qui fait que les testeurs mettent ce délai ? Est-ce propre à Synology ?
votre avatar
Désolé je ne vois ton message que maintenant !
Comme l'ont dit les autres, dès que tu actives le bannissement d'IP sur ton syno, tu auras des stats sur le nombre d'IPs bloquées depuis la zone de notification notamment.
votre avatar
Du coup au boulot tu fais comment pour accéder à tes services ? On t'y laisse installer Netbird sans problème ?
votre avatar
Ce sont surtout des services de type n8n ou coolify que j'héberge actuellement sur ce VPS, qui tournent de manière autonome la majorité du temps. Donc normalement pas besoin d'y accéder du boulot.
Ah, et comme je suis freelance, j'ai de toute façon toujours mon laptop perso à portée de main, depuis lequel je peux m'y connecter.
votre avatar
Je pense que la suite logique de l'expérience est de mettre 123456 comme mot de passe root et de voir ce qui se passe.
Pour la science !
votre avatar
J’ai fait, même mieux : je suis en train de laisser passer dans une sandbox tous les users et mdp tentés par les bots et je capte ensuite les commandes lancées par les bots. Un article arrive (demain avec un peu de chance) ^^
votre avatar
Attention à ne pas les laisser lancer un make fire chez OVHcloud
votre avatar
Tu peut mettre un HoneyPot pour détecter les attaquants.
github.com GitHub
votre avatar
De mon côté (auto-hébergé), j'ai changé le port ssh, et j'ai configuré fail2ban pour bannir les gens sévèrement... De mémoire 24h pour le 1er, et 1 mois pour les suivants.
En laissant fail2ban avec une configuration par défaut, j'avais des IPs qui revenaient après quelques heures. Avec ça, je n'ai plus jamais eu d'IP qui récidive.

Aussi, quand j'ai des tentatives, je contacte parfois l'adresse email "abuse" dans le whois de l'IP. J'ai eu des bons retours de DigitalOcean, chez qui j'ai à mon avis contribué à éliminer des bots qui sévissaient chez eux vu que je n'ai plus eu de tentatives venant de leurs IPs depuis bien longtemps :-) .
votre avatar
Je ne suis pas aussi strict avec le fail2ban, je me suis retrouvé deux trois fois banni d’un de mes serveurs suite à une fausse manip, t’as l’air con ensuite à attendre.

Par contre, je confirme ce que dit l’article, et ça ne date pas d’hier. J’ai eu un serveur qui s’était mis à ramer tellement il recevait de tentatives sur le 22 (un atom chez ovhcloud, pas un foudre de guerre). Au final, le changement de port est le seul truc qui a fonctionné pour supprimer tout ce bruit et revenir à une charge « normale ».
votre avatar
Je ne suis pas aussi strict avec le fail2ban, je me suis retrouvé deux trois fois banni d’un de mes serveurs suite à une fausse manip, t’as l’air con ensuite à attendre.
Perso je ban à vie.
Mais même sans ça, il faut évidemment mettre ton IP en liste blanche…
votre avatar
Je ban sur 720 jours ou à vie suivant les possibilités des outils, sur Syno y'a des limites de temps pour certains ban :/

Mais bon, 720 jours ça laisse de quoi voir venir ^^
votre avatar
Et pour ça, faut une ip fixe. Pas toujours le cas quand tu dépends de ton FAI. Mais c’est vrai que maintenant, je pourrai (pas à l’époque).
votre avatar
Du coup il faut bien y penser si tu changes de FAI et donc d'IP fixe sinon c'est la cata ?
votre avatar
C'est sûr, mais bon avec un gestionnaire de mots de passe, c'est quasi impossible de se tromper de mot de passe…
votre avatar
De mon côté, j'ai le ssh sur un autre port que 22, et un endlessh sur le port 22. Ça n'améliore pas la sécurité en tant que tel, mais ça rend les logs nettement plus lisibles, ce qui est toujours bon.
votre avatar
Merci pour l'info sur endlessh
votre avatar
On m'a signalé cet autre projet: https://github.com/itskenny0/fail2ban-endlessh
votre avatar
Je vais aller voir merci :yes:
votre avatar
Comme je disais sur l'autre article : gang bang.
votre avatar
P'tite question, si la première tentative intervient au bout de 10 s, ça veut dire qu'on a très très peu de temps entre le moment où on allume le serveur pour la 1ère fois et le moment où on le sécurise (changement de port, désactivation de l'utilisateur root, fail2ban...), pour minimiser les risques (bien sûr une tentative ne veut pas dire un accès si l'authentification est suffisamment forte, mais le risque reste présent).
Comment procéder pour minimiser le risque ? Juste une authentification forte / clé et basta pour commencer ? Est-ce suffisant ? Y a-t-il des hébergeurs qui proposent d'autres solutions (genre login alternatif, fail2ban préinstallé et préconfiguré...), autre ?
votre avatar
Comment procéder pour minimiser le risque ? Juste une authentification forte / clé et basta pour commencer ? Est-ce suffisant ? Y a-t-il des hébergeurs qui proposent d'autres solutions (genre login alternatif, fail2ban préinstallé et préconfiguré...), autre ?
Généralement, les Cloud Provider proposent de changer le mot de passe du user ssh (qui n'est pas root, le nom peut être personnalisé) à l'installation. Tout comme un autre moyen est de ne pas exposer le serveur et par exemple whitelist son IP dans les règles réseau de la VM.

Editeuh du lendemain : les cloud provider proposent aussi de générer / upload une clé publique plutôt que de jouer à coup de password.
votre avatar
Même chose sur les firewall pro, J'en suis à 4900 adresses bloquées.

J'avais config un automatisme qui ajoutait automatiquement les IP dans un groupe d'adresses et dans une règle de pare-feu en blocage direct, sauf que visiblement sur forti, les groupes sont limités à 600 adresses IP :roll:
votre avatar
Faudrait un moyen d'exporter tout ça et réinjecter dans un txt. J'ai pas encore planché sur le sujet, pour l'instant j'utilise les connecteurs externes que j'alimente manuellement de temps en temps.
votre avatar
Pour ma part, de temps en temps je regroupe, en 50 blocs d'adresses je bloque à peu près 95% des adresses IP de ma liste de 4900. Et vu qu'une fois dans un bloc, elle sont rejetées directement, elles ne se recrées par en /32 par l'automate.

Je n'ai pas encore pris le temps de regarder plus en détail, pas très urgent vu que les forti jouent leur rôle et qu'il y a du MFA derrière. C'était plus pour réduire l'assiette et dépolluer un peu :)
votre avatar
Super idée :) Si tu as la liste des IP sources des attaques, il y a moyen d'avoir des stats sur les AS sources ? Voire un coup de Shodan sur un échantillon pour voir la tête des serveurs derriere les bots ?
votre avatar
Clairement, ce sont les AS qui m'intéressent. Perso, je ne filtre quasiment que des plages entières.

Exemple avec Facebook dans un set nftable:
set ip4_facebook {
type ipv4_addr
flags interval
elements = {
#AS32934 - Facebook
31.13.24.0/21,
31.13.64.0/18,
45.64.40.0/22,
57.141.0.0/20,
57.141.16.0/22,
57.141.20.0/23,
57.144.0.0/14,
66.220.144.0/20,
69.63.176.0/20,
69.171.224.0/19,
74.119.76.0/22,
102.132.96.0/20,
103.4.96.0/22,
129.134.0.0/17,
157.240.0.0/17,
157.240.192.0/18,
163.70.128.0/17,
163.77.132.0/23,
163.77.136.0/23,
173.252.64.0/18,
179.60.192.0/22,
185.60.216.0/22,
185.89.216.0/22,
204.15.20.0/22
}
}

set ip6_facebook {
type ipv6_addr
flags interval
elements = {
#AS32934 - Facebook
2620:0000:1c00::/24,
2a03:2880::/16
}
}

C'est beaucoup moins éparpillé en IPv6.
votre avatar
J'utilise les fichiers hosts.deny (avec sshd: ALL) et hosts.allow (avec les IP dont je me sers pour me connecter) sur mes serveurs. C'est pas bon ?
Sur mon NAS Syno, j'utilise le blocage automatique des IP comportant plus de 5 échecs de connection en moins de 5 minutes...
votre avatar
Personnellement, au vu du rythme de mise à jour de mon Syno et de l'absence de maîtrise sur l'OS, j'ai préféré ne surtout pas l'exposer et lui adjoindre un front sur une machine dont le patch management sera mieux suivi. Pas besoin d'un foudre de guerre ou une tour de 3m de haut, le serveur est en réalité un micro PC de 10x10cm, mon ex-HTPC (base Ryzen 5, initialement 8 GB de RAM boosté pour accueillir plusieurs containers, et son SSD changé aussi pour un plus grand) recyclé après l'avoir remplacé par un Steam Deck.

Et, accessoirement, cette machine est plus maitrisée en matière de ce qu'on peut configurer. Les outils Syno m'ont maintes fois déçu par leurs limitations chelou :craint: (donc il en est resté à faire son taff de base : NAS, point)
votre avatar
Pour ma part, la règle c'est jamais un NAS en direct sur internet (que ce soit un synology ou autre). En cas de failles (et c'est déjà arrivé plusieurs fois avec les synology), tu peux te retrouver avec le syno piraté, tes données victimes d'un ransomware, etc...

C'est toujours derrière un VPN comme WIreguard ^^
votre avatar
En règle générale, tu exposes ce que tu maîtrises :D
votre avatar
Ça doit faire 10 ans que j'en ai d'exposé. Sans le DDNS Synology et avec un vrai pare-feu je suis assez serein. Et en cas de crypto j'ai des backup ailleurs... donc si on investi/s'investi pas un minimum je recommanderai effectivement pas.

Quelques paquets n'évoluent plus mais fonctionnent toujours pour l'instant (Note, Audio, DNS, ...). La succession sera Joplin, Amperfy et Bind9 probablement. Par contre Active backup, Hyper Backup, c'est pas cher pour ce que c'est. J'aurai bien mis un Veeam CE mais l'appliance linux est soumise à licence. En tout cas je te l'accorde, sur la partie réseau Synology est vite bloquant.

Reste la partie messagerie, j'aimerai trop avoir mon serveur mais remplacer une box en France c'est galère et un peu aléatoire. Et ce juste pour profiter du port 25...
votre avatar
Reste la partie messagerie, j'aimerai trop avoir mon serveur mais remplacer une box en France c'est galère et un peu aléatoire. Et ce juste pour profiter du port 25...
Comment ça ?
votre avatar
Par défaut le port 25 est bloqué sur les routeurs grand public chez beaucoup de FAI. Si on veut s'en défaire le mieux c'est de remplacer le routeur par le sien sauf que pour que ça fonctionne, c'est plus ou moins complexe et ça nécessite des équipement avec parfois des capacités bien tordu. Même avec des pare-feu récent. Sauf qu'en plus de ça, on est pas tous égaux dans les prérequis. Certains arrive à faire sans parce que j'imagine que les équipement dans les "NRO" ne sont pas tous les mêmes. Actuellement une box Orange c'est compliqué avec un certain CoS6...
votre avatar
Faut passer chez Free 😅
votre avatar
Personne n'utilise Crowdsec ? Fail2ban only ?
votre avatar
Crowdsec je trouve ça un peu overkill pour mon usage et consommateur de RAM par rapport à fail2ban.
J'étais parti dessus quand j'ai migré mon dédié avec peu de RAM et les perfs n'étaient pas bonnes, ça a peut être changé depuis.
votre avatar
Ha moi c'est l'inverse. Fan2ban sur un log apache qui "bouge" un peu était catha.
Crowdsec (qui est codé en GO je crois) est quand même super bien foutus.
il catch des scénarios d'attaque que j'étais loin de pouvoir faire avec F2B, dispose de liste blanche d'ips etc.
J'ai supprimer F2B de tout mes serveurs.
votre avatar
Merci du retour, je referais des tests depuis le temps.
votre avatar
Comme je sais que j'ai affaire à une belle brochette de geek, il existe aussi Reaction, que je ne connais pas : https://framagit.org/ppom/reaction.
votre avatar
je connaissait pas non plus intéressant !
votre avatar
Petite anecdote : Lors de la toute première configuration de mon Raspberry Pi (qui me sert à host mes bots discords et leur petite DB), j'ai oublié de désactiver la connexion par mot de passe.
Bah un jour je me réveille et pouf. Impossible de me connecter en SSH ou mdp. Les filous avaient finir par y avoir accès, après 6 ou 7 mois en service.
En même temps, le mdp que j'avais vu était VRAIMENT pas fort.

Ah oui ma config sur le PI :

  • Blocage de la connexion par mot de passe

  • Clé token de secours pré-enregistré stocké dans Proton au cas où je dois me connecter d'un nouveau PC (et que je suis pas chez moi évidemment, vu que sinon il me suffit de connecter à un écran)

  • Fail2ban

  • Changement de port

  • ufw




PS: Vous utilisez quelle commande pour visualiser les tentatives de connexions ?
votre avatar
PS: Vous utilisez quelle commande pour visualiser les tentatives de connexions ?
C'est pas
fail2ban-client status <jail_name>
votre avatar
PS: Vous utilisez quelle commande pour visualiser les tentatives de connexions ?
Je suis également intéressé.
J'ai fail2ban sur une instance Yunohost (+ app pour visualiser les logs) et j'ai jamais vu une seule adresse IP bannie
votre avatar
A l'instant T : sudo fail2ban-client status sshd | grep Banned
il t'affiche la liste des clients bannis du jail sshd en temps réel.
Sinon les logs des actions (BAN/UNBAN) : sudo cat /var/log/fail2ban.log | grep fail2ban.action
votre avatar
fail2ban-client status sshd
Currently banned : 0
Total banned : 0
Concernant les logs, j'ai bien vu des "fail2ban.action" mais quand j'ai testé la commande avec le "grep", la console n'a plus jamais voulu répondre :transpi:

Après, j'ai désactivé le port 22 dans le pare-feu, ça doit aider :dd:
votre avatar
votre avatar
Les commentaires sont toujours aussi savoureux ! (Sans ironie)
De mon côté, sur mon vps, j'observe des tentatives de connexion en ssh depuis.... 127.0.0.1 ! Avec des users farfelus. Amis nextiens, qu'est-ce qui pourrait causer cela ?
votre avatar
Une attaque par rebond ? Un peu à la log4j de java il y a quelques années ? (histoire de prendre un exemple célèbre). Un composant un peu faiblard qui autoriserait ce genre de chose...

[edit] Après, ça peut aussi vouloir dire que le serveur est déjà compromis, et que ce n'est qu'une tentative parmi d'autres de faire de l'élévation de privilèges. Une surveillance accrue est de mise je pense.
votre avatar
Alors, j'ai trouvé le pot-aux-roses.

Je ne sais pas si vous connaissez rinetd mais cet exécutable de rien du tout permet d'écouter discrètement sur un port puis de rediriger les paquets vers une autre destination.

Mon VPS écoute sur 2222 pour les connexions SSH. Grâce à lsof -i :2222, j'ai pu observer un exécutable suspect, rinetd-bbr; alors, qu'il n'y aurait dû avoir que sshd dans mes résultats de lsof. Le binaire est localisé dans /usr/local/sbin/ avec un fichier de config /etc/rinetd.conf. Quelle ne fut pas ma surprise en voyant le contenu de ce fichier !

0.0.0.0 2223 127.0.0.1 2222
0.0.0.0 1443 0.0.0.0 443
0.0.0.0 21 127.0.0.1 21
0.0.0.0 10000 127.0.0.1 10000
0.0.0.0 10001 127.0.0.1 10001
0.0.0.0 10002 127.0.0.1 10002
0.0.0.0 10003 127.0.0.1 10003
0.0.0.0 10004 127.0.0.1 10004
0.0.0.0 10005 127.0.0.1 10005
0.0.0.0 10006 127.0.0.1 10006


Ainsi, ce gentil processus, lancé en service au démarrage, écoutait sur 2223 et redirigeait vers 2222 en tant que 127.0.0.1. Heureusement, mon ssh correctement configuré n'acceptait jamais la connexion pour l'utilisateur déclaré, à savoir root. C'est pour cela que les logs de sshd renvoyaient une tentative depuis 127.0.0.1 en tant que root. L'adresse distante de l'attaquant était offusquée derrière 127.0.0.1 !

sshd[771532]: User root from 127.0.0.1 not allowed because none of user's groups are listed in AllowGroups


Le firewall (iptables) a été pré-configuré par l'hébergeur de façon assez permissive. Ainsi, le port 2223 était ouvert également et permettait cette redirection fallacieuse.

À la fin de ces aventures forensics, je me demande bien quelle est l'origine de ce binaire (qui pointe d'ailleurs vers un sombre dépôt Github chinois). A-t-il été implanté par une faille de sécurité, ce qui a permis au pirate d'avoir sa "persistance" et qu'il cherchait ensuite à bouger "latéralement", c.-à-d. à obtenir une session root ? Ou bien est-ce un garde-fou de l'hébergeur qui cherche à maintenir un accès illégitime au VPS de ses clients ?

Quelle que soit la réponse, je ne l'aime pas...

Mon conseil : une fois un VPS souscrit, installez tout à la main et configurez tout vous-même !