Dédié compromis?

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Dédié compromis?

patapouf

Bonjour à tous!

Je suis ce forum depuis un moment, il m'a beaucoup aidé pour installer un serveur mail/torrent/owncloud entre autre. J'interviens habituellement sous un autre pseudo (patatra) mais j'ai perdu mon mot de passe et malheureusement, je crois que mon dédié SoYouStart qui héberge le serveur mail a été compromis ce qui m'empêche de récupérer le mot de passe

Bref, je me tourne vers vous pour avoir de l'aide, savoir si mon serveur a réellement été compromis ou si je me fais des films.
Voilà donc ce qu'il s'est passé :

Ce midi, impossible d'accéder à mes mails, erreur de timeout sur Evolution, j'essaie donc de passer via le webmail, impossible. Connexion owncloud et rutorrent ok. J'essaie de me connecter en ssh afin de redémarrer les services et là, impossible.

ssh me demande un mot de passe alors que j'utillise une connexion par clef privée. Je tente donc webmin, impossible de me connecter. Soit, pas bon mais je tente quand même le reboot sauvage via l'interface d'administration SoYouStart, ça ne change rien, impossible de se connecter, ni en ssh, ni via webmin.
Je lance donc le mode rescue du serveur, je me connecte puis chroot sur le serveur. Je ne sais pas trop quoi faire, je regarde vite fait les logs mais sans savoir trop où chercher.
Au final je vois plusieurs erreurs d'authentification (je m'en serais douté :/) mais surtout un truc bizarre. Il semble que la plupart de mes utilisateurs unix aient disparus!! Je vérifie donc /etc/passwd, et effectivement :

REDIS0006ok@

root:x:0:0:root:/root:/bin/bash
ram:x:1000:1000:,,,:/home:/bin/bash
sshd:x:114:65534::/var/run/sshd:/usr/sbin/nologin
nobody:x:114:65534::/var/run/sshd:/usr/sbin/nologin



0<

Plus d'utilisateurs ssh/torrent/postfix/www-data/... !!!!!

Donc, désolé pour le pavé, mais, pouvez-vous m'aider à y voir plus clair? Éventuellement m'aider à sauver ce qui peut l'être? Pour l'instant je laisse le rescue activé en attendant. J'ai quelques connaissances mais j'avoue être un peu dépassé

Merci d'avance pour votre aide!

turak

Essaie de voir si tu trouves pas un fichier bash.history lié à un user restant (root ou nobody) pour voir si quelque chose de spécifique a été fait.

http://guide.ovh.com/MachineHackee

après je vois pas trop quoi d'autres regarder..

patapouf

Merci de ta réponse,

Rien dans le .bash_history de root...

La mention à REDIS dans le /etc/passwd est-elle normale?

coom

Ca pue le serveur dédié hacké. A ta place, backup des datas restantes et on reformat la machine au complet. Change tes mots de pass, et essaye de sécuriser un peu plus ton dédié.

Un truc qui permet déja de bien blinder la machine :
- SSHd sur un port en random
- Empecher les scanner de port de trouver le port (portsentry)

Ca suffit déja a bloquer la plupart des bots et autre script kiddies.. Ca, ajouté au fait que je n'autorise la connexion en SSH que depuis certaines IPs, tu blinde déja pas mal la sécurité du dédié.

patapouf

Hmmm

c'est bien ce que je me disais..

Je pensais être pas mal au niveau sécu : root ssh désactivé, ssh avec clé privée uniquement, port ssh modifié, ... insuffisant malheureusement semble-t-il..

Jedediah

Ca me parait étrange quand même qu'avec une sécurité comme la tienne tu ais pu te faire "hacker" ainsi.
Tu es sûr que tu n'as pas laissé traîner une faille quelque-part ?

coom

Ca dépend un peu d'ou il se connecte .. Je suis étudiant en informatique, et l'authentification par clé privée sans aucun mot de passe a montré ses faiblesses a un camarade de notre classe : il est parti en pause café sans avoir prit sa clé USB avec lui. Il a suffit de 30 secondes pour cloner sa clef SSH, et 30 secondes de plus sous WireShark pour connaitre l'IP et le port de sa box linux, qui ont été compromis en 5 min a peine.

La sécurité en informatique doit se voir comme une suite de maillons qui forment une chaîne : si un seul des maillons est compromis, la chaîne est brisée est la sécurité tombe.

patapouf

Y'a un truc bizarre dans les logs concernant prosody (messagerie instantanée), peut-être une faille de ce côté..
Sinon, le seul truc récent que j'ai fait sur le serveur c'est tenter l'installation de RuFy via ce thread

EDIT : et connexion uniquement depuis chez moi, mais comme tu dis, il suffit d'un maillon faible pour que tout foire...

jean-luc

coom wrote:Ca dépend un peu d'ou il se connecte .. Je suis étudiant en informatique, et l'authentification par clé privée sans aucun mot de passe a montré ses faiblesses a un camarade de notre classe : il est parti en pause café sans avoir prit sa clé USB avec lui. Il a suffit de 30 secondes pour cloner sa clef SSH, et 30 secondes de plus sous WireShark pour connaitre l'IP et le port de sa box linux, qui ont été compromis en 5 min a peine.

La sécurité en informatique doit se voir comme une suite de maillons qui forment une chaîne : si un seul des maillons est compromis, la chaîne est brisée est la sécurité tombe.

Salut;

Même une clef sans mdp (déconseillé ça protège de l'usage de la clef), sauf a la laisser traîner, même en 2048, c'est inviolable avec les moyens actuels, et surtout dans un temps raisonnable :

http://security.stackexchange.com/questions/4518/how-to-estimate-the-time-needed-to-crack-rsa-encryption
http://superuser.com/questions/881063/how-long-would-it-take-to-break-a-1024-bit-openpgp-encrypted-email

Et encore même en ayant la clef privée, faut trouver l'ip correspondante (ou domaine) ??? sur un réseau local : oui; sur le net si il s'agit d'un dédié...???

Trouver le port ssh une fois que l'on a la clef et l'ip, reste ensuite un jeu d'enfants...ce qui prouve l'inutilité de la délocalisation du port ssh sauf à réduire les logs (sécurité par l'obscurité ???).

lokiii

Aurais tu un petit wordpress d'installer par hasard ?
J'avoue qu'avec un port ssh random, un portsentry et un minimum de fail2ban, c'est tendu de se faire péter "facilement"...
Après, peut être as tu laissé trainer tes logs quelque part ? un couple login / mdp utilisé à la fois sur ton dédié et sur un site internet par exemple ?

coom

jean-luc wrote:Une clef, sauf a la laisser traîner, même en 2048, c'est inviolable avec les moyens actuels, et surtout dans un temps raisonnable

Euh oui, c'est un peu ce que j'ai dis dans mon post : il est allé en pause café en laissant sa clé USB raccordé a son poste, ce qui, en entreprise, se vérifie très souvent. Un peu comme les mots de pass complexe, tellement, qu'ils se retrouvent "noté" sur un post-it, collé a l'ecran.

jean-luc wrote: Et encore même en ayant la clef privée, faut trouver l'ip correspondante (ou domaine) ??? sur un réseau local : oui; sur le net si il s'agit d'un dédié...???

Oui, la encore, c'est exactement ce que je viens de dire .. En réalité, beaucoup se pensent protegés, mais se connectent depuis des environnement qui ne sont pas propices à le faire (Cybercafé, entreprise, a la fac, etc ..). Il faut se mettre dans la tête que sur un LAN, on est jamais réellement protégés.

Même en bossant a l'informatique, je ne me connecte JAMAIS a mes serveurs depuis le LAN de l'entreprise..

patapouf

Ah oui, effectivement, un wordpress installé à la demande d'un coloc.. Des failles connues? (j'ai installé le wordpress pour le coloc mais ne m'y suis jamais intéressé, bêtise?!?)

Et non, pas de couple login/mdp commun au dédié et à des sites internet

coom

patapouf wrote: Des failles connues?

Des failles ... ? Dans wordpress ... ?

Euh .. Plus d'un millier depuis sa création. Tu as même des scanners de vulnerabilités wordpress en ligne (je pense a wpscan...).

D'ailleurs, tu en a la liste ici :

http://www.wordpressexploit.com/

Deux de plus depuis hier

Par contre, je ne vois pas en quoi un exploit dans WordPress aurait pu mener a compromettre ton dédié.. Si tu as fais les choses "correctement", alors WordPress se trouvait dans /var/www, et etait éxécuté par le compte de service qui fait tourner ton serveur web, donc même en "cassant" ton WP : pas d'accès root, mais un accès www-data, qui la encore, si tu as bien fait les choses, ne sait pas lire un /etc/passwd ou un /etc/shadow..

Enfin bref, on en revient a ce que je disais : il faut que tout soit nickel.. Un mauvais chmod, un mauvais chown, et c'est toute la sécurité de ton dédié qui est potentiellement compromise.

patapouf

bien bien bien... Voilà, on veut faire plaisir aux colocs... Bordel

Je regarderais les logs nginx/wordpress quand j'aurais fini mes sauvegardes..

coom

Si la personne a effectivement obtenu l'accès root de ton serveur, alors la première chose qu'elle a fait est probablement d'avoir installé un rootkit, pour ensuite mieux effacer les traces.

Si j'etais toi je ne m'attarderai pas trop a essayer de trouver le responsable, a moins d'avoir éventuellement accès a des logs d'un firewall qui se trouve en amont de ton dédié et que le hacker n'a pas pu compromettre.

En tout cas, je compatis. C'est très désagréable comme truc : l'impression que quelqu'un s'est introduit chez soit n'est jamais une expérience agréable a vivre..

patapouf

Merci, pour ton aide et ta compassion! J'avoue avoir été un peu désemparé en découvrant tout ça. Mais comme tu dis, retrouver le responsable (si tant est que ce soit possible) ne m'apporterait pas grand chose de plus.

Bref, vu que je suis probablement parti pour tout réinstaller, j'envisageais d'utiliser Docker. Quelques conseils à donner?

coom

Bien lire les tutos, pour comprendre comment ça fonctionne, et ne pas hésiter a se monter un "clone" de ta machine en VM, que tu snapshote une fois que tout est OK. Ca te permet en cas de pépin de rapidement revenir a un environnement sain et fonctionnel sans avoir à se refrapper toute la conf du dédié si soucis tu rencontres.

lokiii

Ensuite, c'est pas parce que tu utilises Docker que le system qui le fait tourner est fiable et secure ^^
L'utilisation de Docker ne dispense pas de la sécurisation du system hôte.
Mais c'est vrai que tes applis dockées ne permettront pas de foutre en l'air ton system

patapouf

Merci pour vos réponses, je vais bien étudier Docker cette nuit, et j'essaierais d'installer tout ça demain.

Pour le moment j'ai encore une petite question à vous poser. Comment puis-je faire pour sauvegarder ma base SQL sachant que j'accède à mon système via le chroot du mode rescue de soyoustart (donc aucun service n'est démarré sur le serveur) et qu'en plus de ça je n'ai plus d'utilisateur mysql...
Puis je simplement copier mon /var/lib/mysql/ ? Ça me parait trop simple..

EDIT :

Je me réponds à moi même :

Cela est visiblement possible.
**Stopper mysql sur le nouveau serveur.
**Copier /var/lib/mysql et chown -R mysql:mysql
**Copier /etc/mysql/
**Redémarrer mysql
**mysql_upgrade -u root -p

Quelqu'un peut-il confirmer?