Après 6 ans sans problème, j'ai un serveur dédié qui est hacké et bloqué chez OVH. Ce serveur utilise proxmox (basé sur debian) avec des containers LXC (dont 2 qui sont très vieillot)
J'avais une utilisation de plus de 15000 ipV6 identifié par la mac sur le serveur hôte en même temps et OVH a coupé mon service.
J'ai téléphoné à l'assistance et on m'a expliqué que l'on me donnera un accès rescue pour diagnostiquer et que je pourrais relancer mon serveur mais que si cela devait se reproduire, le contrat pouvait être rompu.
J'ai déjà un accès FTP (fourni par OVH) qui m'a permis de télécharger les log. Je ne trouve à première vue rien de suspect, notamment aucun accès SSH n'avait réussi (à part les miens) mais je ne remonte qu'au mois dernier.
Je lance donc une bouée de secours :
pouvez-vous m'indiquer des log/fichiers particuliers à consulter qui pourrait me mettre sur la piste (sachant que je n'ai consulté que ceux qui avait été modifié aujourd'hui) ?
que me conseillez-vous ? Essayez de relancer quand je pourrais (mais je risque une rupture de contrat) ou récupérer tous mes containers et refaire une installation ?
# usage du firewall
Posté par NeoX . Évalué à 3.
utilise le rescue pour activer le firewall de ton proxmox (ou IPtables)
relance en mode normal pour reprendre la main sur le proxmox et les VMs
regarde comment c'est possible d'avoir ces IPv6 sur une seule MAC
j'ai deja fait de multiples sessions de ressue/restart pour retrouver une machine stable, le temps de fouiller, tester une hypothèse, me faire couper car c'était pas ca, repartir en mode rescue, corriger un autre truc, etc
mais si tu répond au support que tu travailles dessus et que tu le fais vraiment, il ne m'ont jamais embêté pendant mes multiples restarts
[^] # Re: usage du firewall
Posté par matteli . Évalué à 1.
Merci pour les conseils.
La rupture de contrat, c'est si l'utilisation de 15000 ip devait se reproduire (peut être pas au prochain coup).
Je tente une hypothèse :
- un attaquant arrive à accéder au serveur il y a quelques mois (du coup pas de trace dans les logs qui ont été effacé)
- il y dépose un petit script pour créer des interfaces réseaux et faire son boulot
- OVH s'en rend compte et bloque mon serveur
Est-ce que je ne devrais pas retrouver quelques traces ?
[^] # Re: usage du firewall
Posté par Yves Bourguignon . Évalué à 3.
Tente une analyse avec rkhunter et chkrootkit
[^] # Re: usage du firewall
Posté par Anonyme . Évalué à 4.
et fait tourner lynis, dispo sur debian, donc j'imagine sur proxmox aussi mais je n'ai pas vérifié, pour découvrir où il y aurait pu avoir des trous dans ton système.
[^] # Re: usage du firewall
Posté par Anonyme . Évalué à 4.
après le conseil c'est de tous formater et de réinstaller, hélas. mais tu peux creuser pour regarder ce qui cloche
c'est délicat si il a ajouté ses propres binaires, il est possible que tu efface les traces. le journal des commandes passé dans bash, des nouveaux paquets dans /var/cache/apt/archives.
tiens j'ai une idée, tu fait le md5 du chaque fichier sur le disque, et tu le compare avec ta sauvegarde, ou une installation identique pour trouver ce qui cloche
regarde si il y a le paquet build-essential et essaye de trouver sa date d'installation, sauf si c'est toi qui l'a installé :).
# On efface tout et on recommence (proprement)
Posté par rahan . Évalué à 3.
Désolé d'être rabat-joie mais les bonnes pratiques te disent qu'en cas de compromission, il faut tout effacer pour repartir sur des bases saines. Tu t'assures que tu as sauvegardé les données puis tu formates et tu réinstalles tout proprement en t'assurant d'utiliser des sources sûres et à jour.
Une fois qu'un système a été compromis, il est très difficile de s'assurer qu'aucune porte dérobée n'a été laissée.
Une autre chose : tu changes tous les mots de passe. Tu peux considérer que tous le mots de passe utilisés sur les services de cette machine sont compromis. Il faut donc les changer ainsi que ceux que tu aurais réutiliser sur d'autres services.
Bon courage.
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 2.
En effet, j'arrête mes recherches.
J'ai bien trouvé un point faible.
Pour insérer ma clé de connexion ssh, j'avais provisoirement autorisé un accès par mot de passe et visiblement je n'ai jamais retiré le provisoire.
Mot de passe de 12 caractères quand même.
Est-ce que cela été la faille ?
Bref, on efface tout et on recommence. Il faut que ce soit fonctionnel pour jeudi matin 8h. Je suis large…
[^] # Re: On efface tout et on recommence (proprement)
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 06 janvier 2021 à 08:38.
J'en doute. Le login est-il un login standard (style "root", "admin"…) ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 1.
oui c'est root
[^] # Re: On efface tout et on recommence (proprement)
Posté par gUI (Mastodon) . Évalué à 3.
donc la prochaine fois, hygiène de base non négociable :
- pas de login root en SSH
- activer fail2ban (ça évite les tentatives multiples)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 2.
et tu fais comment tes mises à jour sans login root (avec without-password) ?
[^] # Re: On efface tout et on recommence (proprement)
Posté par Julien_J06 . Évalué à 5.
Hello,
Je dédie un utilisateur pour la connexion ssh (par clé publique/privée) puis je
su -pour installer fail2ban ;-)Julien_c'est_bien (y'a pas que Seb)
[^] # Re: On efface tout et on recommence (proprement)
Posté par gUI (Mastodon) . Évalué à 5.
Tu utilises n'importe quel utilisateur qui a accès à
sudo. En général le tout premier utilisateur qui est créé lors de l'installation.Par défaut
sshdrefuse les connexionsroot(tu as dû faire une modification pour l'autoriser), il y a une raison.Je n'ai jamais eu besoin d'autoriser root en SSH, et pourtant, je fais bien mes mises à jour :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 3.
Dans le template debian proposé par proxmox, sudo n'est pas installé par défaut, il n'y a qu'un utilisateur root et ssh est configuré avec root login without-password.
De toute façon, il y a vraiment un gain entre l'utilisateur root et un suoduser en terme de sécurité ?
[^] # Re: On efface tout et on recommence (proprement)
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 07 janvier 2021 à 08:46.
Il y a déjà un secret supplémentaire : trouver un login valide :)
Les scripts automatiques ne traitent que des logins standards. Avec un login simplement sur ton prénom t'es quasi certain que les scripts auto ne rentreront pas (pour une attaque ciblée sur toi, c'est autre chose, au contraire le prénom sera sûrement le premier truc essayé).
Ah c'est directement sur Proxmox… je ne sais pas les bonnes pratiques (je ne l'utilise que dans mon réseau local), mais non, activer le SSH pour root ne doit pas être la meilleure pratique, c'est certain.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: On efface tout et on recommence (proprement)
Posté par Anonyme . Évalué à 3.
si par hasard il trouve un login : john avec mots de passe 1234 par exemple, il faut qu'il fasse une escalade de privilège, c'est moins glamour que d’être root directement
comme dit plus haut ou plus bas, un petit 'su' ça fonctionne très bien
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 2.
Autre chose, je fais l'hypothèse que c'est le système hôte qui est compromis (les adresses ipv6 venait de là car c'est cette MAC qui a été identifié) et que mes containers sont sains.
Du coup je réinstalle proxmox et je restaure mes containers à partir de sauvegardes.
Cela vous parait raisonnable ?
[^] # Re: On efface tout et on recommence (proprement)
Posté par Anonyme . Évalué à 3. Dernière modification le 06 janvier 2021 à 08:02.
oui pas mal ,reste prudent et surveille bien tous cela. essaye de recuperer une sauvegarde chez toi avant tout. histoire de la pousser en cas de pb
[^] # Re: On efface tout et on recommence (proprement)
Posté par claudex . Évalué à 5.
J'imagine que ton proxmox fait routeur. Donc c'est normal qu'OVH voit l'ipv6 sur l'hôte mais elle peut très bien très bien être en fait sur un conteneur.
Pour les logs, c'est compliqué, l'attaquant a sûrement mis une porte dérobée. Regarde les process qui tournent (y compris dans tes conteneurs) pour voir s'il n'y en a pas un qui semble suspect. Il y a bien sûr moyen de cacher ça, mais les pirates font aussi des erreurs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 1.
oui mais j'ai une adresse ipv4 qui ne sert qu'à l'hôte.
Pour les containers, il passe par l'hôte mais avec une autre adresse failover.
Hors OVH a détecté le problème sur la mac associée à la 1ère adresse.
Les adresses failover utilisent une mac virtuelle qui est autre que la mac de mon hôte.
Mais ce n'est pas le cas des ipv6… Tu as donc peut être raison. L'ipv6 attendra.
[^] # Re: On efface tout et on recommence (proprement)
Posté par claudex . Évalué à 4.
Si tu fais un
ip -br -6 asur ton proxmox, tu vois les 1500 IP ?« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: On efface tout et on recommence (proprement)
Posté par matteli . Évalué à 1.
trop tard, je réinstalle.
# Le backup OVH
Posté par matteli . Évalué à 1.
Pour être sur de pas faire de conneries.
Si je réinstalle l'OS sur un serveur dédié d'OVH, le backup storage n'est pas réinitialisé.
Je vois pas bien à quoi cela servirait autrement mais n'ayant jamais fait la manip.
A l'occasion, je vous demanderais quelques conseils demain si certains passent par là.
[^] # Re: Le backup OVH
Posté par matteli . Évalué à 1.
Bon la réponse d'OVH si ça peut servir.
Évidement, le backup storage reste en l'état. Il n'y a qu'à refaire les accès sur l'hôte.
# porte dérobée
Posté par matteli . Évalué à 1.
Je réinstalle…
Ce qui est frustrant, c'est de ne pas savoir par où est entré l'assaillant.
Vu qu'il semblerait que son but était de se servir de mon serveur pour une attaque DDOS contre une autre cible et qu’apparemment il se foutait pas mal de mes données, j'imagine que c'est un bot qui a trouvé la faille.
Ce qui m'étonne c'est que mon hôte est un proxmox à jour et à part la faiblesse du mot de passe à 12 caractères laissé possible par erreur, je ne vois ce qu'il a pu exploiter pour entrer.
Ou alors, il est entré par un de mes containers (j'en avais certains pas à jour du tout) et de là, il a réussi à attendre l'hôte. Il semblerait que ce ne soit pas si difficile en LXC.
Cette dernière hypothèse vous parait crédible ?
[^] # Re: porte dérobée
Posté par NeoX . Évalué à 2.
comment geres-tu la mise en reseau des conteneurs ?
est-ce que tu as un reseau privé puis tu masques l'activité derriere un proxy sur le proxmox ?
ou tes conteneurs sont directement accessibles via une adresse MAC dédiée et une IP dédiée ?
auquel cas, OVH doit pouvoir te dire quelle MAC était porteuse du souci, et non pas "votre serveur est malveillant"
[^] # Re: porte dérobée
Posté par matteli . Évalué à 1.
Les 2 :
- réseau privé en ipv4
- accessible directement en ipv6
C'était la mac de l'hôte qui était porteuse du souci.
[^] # Re: porte dérobée
Posté par Anonyme . Évalué à 2. Dernière modification le 07 janvier 2021 à 20:27.
tu peux tenter de verifier ton mots de passe si il n'a pas fuité
https://haveibeenpwned.com/Passwords
le mieux c'est quand même par certificat pour les production, pour ssh tu peux ajouter fail2ban et un autre port pour être plus tranquille
[^] # Re: porte dérobée
Posté par matteli . Évalué à 1. Dernière modification le 08 janvier 2021 à 11:19.
C'était mon intention le certificat mais j'ai dû laisser un accès par mot de passe le temps d'importer la clé publique et j'ai oublié de retirer cette possibilité.
Malgré tout, je ne suis pas sur que ce soit l'hôte qui ait été pénétré.
C'était sans doute un container. Je les avais mis de côté car la mac détectée par OVH était la mac de mon hôte mais comme l'a fait fait remarquer Xavier, mon hôte fait routeur et c'est donc forcément sa mac qui apparaît pour les connexions sortantes.
Finalement, j'ai un peu paniqué et je voulais remettre en service rapidement le serveur. J'ai donc formaté sans chercher d'où venait le problème.
Si c'était à refaire, j'aurais prévenu mes utilisateurs que le serveur était out pour quelques jours et j'aurais pris un peu plus de temps.
# Et dans les containers ?
Posté par unam . Évalué à 2.
Salut, je passe par hasard et ne poste que rarement ici.
Qu'as tu dans ces conteneurs "vieillissants" ?
Un truc qui m'a fait tiquer c'est ça. N'aurais tu pas de vieux sites en php, ou une vieille version de php qui trainerait quelque part ?
Les conteneurs étaient biens étanches à l'hôte ? Pas de clé ssh ou de mdp à trainer quelque part ? (Or réseau évidemment).
[^] # Re: Et dans les containers ?
Posté par matteli . Évalué à 1.
oui clairement, j'ai deux containers avec debian 6. Pour la clé ssh, ce n'est que la publique.
J'en ai remis un en route car il est nécessaire mais j'ai coupé l'accès SSH.
# Merci
Posté par matteli . Évalué à 4.
Bon ça y est.
Tous les services importants sont repartis.
Merci à tous pour vos conseils et mots d'encouragement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.