Je suis administrateur d’un serveur dédié hébergé par Oxyd et aujourd’hui, la machine ne répondant plus, on l’a rebootée. Depuis ce reboot, apache plante régulièrement, donc on est passé sur apache 2 et on a détécté des problèmes, en particulier un compte “roott” avec un uid de 0
Ce dédié offrait des access shell et maintenant heberge des sites web et des serveurs IRC
Bien sur ce compte a été viré, mais j’aimerai être sur qu’il n’y a pas de chances que ça recommence, j’aimerais donc savoir comment être sur que la machine n’a pas de séquelles
chkrootkit n’a rien donné, et la je bloque
J’aimerais aussi bien pouvoir trouver l’origine du problème, j’ai trouvé ça dans les logs : [fixed]fai/s8204.oxyd.net/install-20050106_164126/cfengine.log:Inserting roott:56hNVqht51tzc:0:0:root:/root:/bin/bash[/fixed], on voit la date du 2005_01_06, qui est le jour ou le dédié a été installé, mais rien d’autre de bien interessant
Quand une machine a été hacké. LA solution la plus sage est encore de tout réinstallé. On ne peut jamais etre sur qu’il n’existe pas de processus invisible fonctionnant ou que sais-je encore.
Un pirate pro saura par ailleur virer les traces de son passage via les log ou le bash_history.
Franchement, je te conseille le réinstaller et de remettre ensuite la sauvegarde de ton site.
Néanmoins, auparavant, essaie de trouver comment ce compte a été créer et par quel exploit. (Apache ? php ?noyau ? ssh ?)
Bonne enquete
En effet, pas de bol, mais la première c’était une machine perso, sous mandrake, sans firewall, et la première distrib que j’avais jamais installée, la moitié des fichiers de confs devaient être en 777 :lol: ça ne m’a donc pas étonné, et même arrangé (enfin si ce n’est le fait que j’ai du la réinstaller la veille de mon départ en vacances)
Mais la c’est un dédié auquel je n’ai pas access :-\ enfin on va peut-être en changer, ça fera une bonne raison de tout remettre à 0, mais en attendant, ce sera mode dégradé
En fait, j’ai l’impression que le roott n’a pas de rapport avec nos problèmes, je pense plutôt à une sorte de DDOS (y’a pleins de DNS différents, genre des sites de hentai, des sites de fan club de foot qui génèrent des erreurs 404 dans nos logs), et ce roott a été créé le jour de l’install de la machine, un pirate s’en serait surement servi avant, si ça se trouve c’est un système d’admin de l’hebergeur, j’attends de ses nouvelles là …
dans le doute, on efface tout on recommence. C’est comme ca que je procède et c’est à mes yeux le seul moyen de lutter contre les backdoor, les intentions et techniques des pirates étant imprévisibles. . je sais c’est contraignant (vécu) surtout qd on ne sais pas jusqu’ou elle a ete compromise (peut-etre pas ?). Le plus dur est donc de fixer la limite du doute… La je pense qu’elle est clairement franchie.
TROLLPS : si tu choisi cette solution, profites-en pour mettre un OS solide /me sors
Si les logs ont été modifiés/effacés, c’est dommage.
Fait une liste de ce qui est ouvert sur ce serveur et demande toi, port par port, si tu peux avoir confiance ou non. Par exemple, ssh est globalement sûr (pas parano) mais si un utilisateur crois que “toto” est un bon mot de passe, tu as un pb.
Une école ultra connue dont le tairait le nom ici c’est fait voler son fichier de mots de passe à cause d’un compte utilisateur muni d’un mdp trivial : Résultat, il a fallu contacter tous les gens qui avaient des comptes dans cette école et leur demander de changer de mdp (facilement 2 ou 3000 personnes je pense). Si un seul ne l’a pas fait, un petit débordement de tampon une fois loggé et hop… Bref, ça fait tache…
Il ne vaudrait pas mieux générer soi-même les mots de passe et les donner aux utilisateurs, histoire d’être sûr?
Pour en revenir à l’hisoire, si les logs sont sur le serveur lui-même ils n’ont aucune valeur puisque le pirate a pu écrire dedans. Normalement dans ce cas on boot avec un livecd qui va faire des hachages sur les fichiers clé du serveur, mais comme tu n’as pas fait ces hachages ca ne servira pas. Conclusion: comme déjà dit, il faut réinstaller.
T’imagine la tête ptite secrétaire qui sait déjà même pas où est le bouton pour éteindre l’écran si tu lui dis que son nouveau mot de passe c’est ça : 5fy6Og@-$43A ???
(joke ;)).
. je sais c’est contraignant (vécu) surtout qd on ne sais pas jusqu’ou elle a ete compromise (peut-etre pas ?). Le plus dur est donc de fixer la limite du doute… La je pense qu’elle est clairement franchie.