TrocWeb Posté 21 Mai 2008 Posté 21 Mai 2008 Bonjour De temps en temps, je dirais une fois par mois maxi 2, mon dédié plante, si je suis présent je me rends sur manager puis j'effectue un reboot, puis il redémarre, parfois comme ce matin il plante, je reçois le mail de monitoring et 10 minutes après, il redémarre alors qu'aucun technicien d'Ovh n'est intervenu avez-vous aussi ce genre de problème, comment connaitre la cause de cela (Plesk) dans l'attente de votre aide Cordialement TrocWeb
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 As tu regardé si un de tes softs ne générait pas une erreur dans le /var/log ? Personnellement, un serveur entier qui plante, je n'ai jamais eu ca par contre, un processus qui tombe, la oui EDIT: regarde aussi plus particulièrement dans le /var/log/messages Tu dois trouver des infos sur ce qui aurait (si c'est le cas) pu planté ton kernel
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 (modifié) merci pour ton aide un beau charabia ce fichier lolll de ce que je connais il y a des tentatives de connection FTP en grand nombre puis le server redemarre May 21 09:04:32 nsxxxx proftpd[21740]: nsxxx.ovh.net (85.114.135.137[85.114.135.137]) - FTP session opened. May 21 09:04:32 nsxxx proftpd[21740]: nsxxx.ovh.net (85.114.135.137[85.114.135.137]) - FTP session closed. May 21 10:05:05 nsxxxx syslogd 1.4.1: restart. et plein de d'éssai de log Root May 21 03:59:25 nsxxx sshd[22686]: Authentication started for user root May 21 03:59:29 nsxxxx sshd(pam_unix)[22705]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.150.133.249 user=root May 21 03:59:29 nsxxxx sshd[22705]: Authentication started for user root May 21 03:59:32 nsxxxx sshd(pam_unix)[22724]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.150.133.249 user=root May 21 03:59:32 nsxxxxx sshd[22724]: Authentication started for user root May 21 03:59:36 nsxxxxx sshd(pam_unix)[22744]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.150.133.249 user=root Modifié 21 Mai 2008 par TrocWeb
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Oui ce genre de chose arrive souvent avec un serveur (je parle des attaques ) Moi par securité je met déja mon ssh sur un autre port mais en restant prudent avec ca Genre garder un shell root ouvert a côté en cas de mauvaise manipulation... Tu as souvent des robots qui scannent le port 22 pour trouver des machines mal sécurisées. Par exemple laisser le root en acces direct par ssh sans passer par un simple utilisateur suivi d'un su ou encore, d'utiliser des mots de pass faciles (dictionnaire). Pour le FTP, moi j'utilise vsftpd pcq j'avais eu une sale blague en debian 3.1 avec proftpd mais bon, maintenant je sais qu'il marche bien En fait il me lancait des thread mais ne les coupaient pas... Par contre de la a aller planter ta machine ainsi, ca me semble assez spécial... Essaie un ps aux | grep proftpd pour voir si il tue bien les thread qu'il peut lancer. Si tu vois une liste de 3km, la je crois qu'il y a souci... Je dis ca par expérience pcq ce que je suppose sans pour autant être celà, ca serait une saturation de la ram par des thread non arrêtés. Aussi, regarde l'ip qui cause cela a chaque fois et regarde si c'est la même ou si jamais elle est dynamique, de chez quel FAI ca provient. Si c'est toujours la même et quelle est statique, moi je la mettrais dans iptables le temps que la tempête passe... EDIT: oula sorry, je viens de voir, regarde l'heure entre la dernière tentative FTP et ton restart, je viens seulement de voir :-/ Ca laisse quasi une heure... A mon avis, ca n'est pas ca... Quand tu as redémarré ton serveur, tu l'as bien fait a 10h05? C'est juste pour moi être certain que ca vient de toi...
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 pas simple tous ca... quand le site décollera et générera des rentrés (car gratuit en ce moment) , je passerai par l'infogérance de Dan, j'en profiterai pour passer sur un offre encore plus puissant ce jour la dans l'immédiat faut que je parade a tous cela
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Oui c'est sur mais n'ayant jamais rencontré un tel problème, j'essaie aussi de trouver une solution... Tu sais a quelle heure ton serveur a planté exactement ou du moins, quand il ne répondait plus?
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 (modifié) oui à 10 h et des... par contre j'ai taper ta commande ps aux | grep proftpd (tel que) et me dit bad command (j'ai surement fait une boulette ) edit cest pas: ps -aux ? Modifié 21 Mai 2008 par TrocWeb
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Hmmm... pourtant chez moi, elle passe sans souci... C'est sous quelle distribution que tu es? Un truc m'étonne, c'est que si tu avais eu un kernel panic ou autre, on devrait trouver plus d'informations je pense. Je ne sais pas si tu sais récupérer ton /var/log/messages , /var/log/auth.log et celui de proftpd. Je veux bien les éplucher chez moi tranquillement pour voir si je trouve quelque chose dedans... EDIT: ps -aux va aussi mais il me sort une erreur de syntaxe du ou - devant le aux chez moi sous une debian...
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 merci pour ton aide, je quitte le pc pour plusieurs heures, je te tiens au courant dès mon retour avec mes remerciements par avance
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Oui je fais de mon mieux sur ce coup la... Je pense qu'on devrait attendre Dan. Je parie qu'il va nous sortir la solution en 5min...
Dan Posté 21 Mai 2008 Posté 21 Mai 2008 En cinq minutes peut-être pas. Mais j'ai eu un serveur infogéré qui rebootait sans raison toutes les heures... Un simple changement de noyau pour un noyau avec grsecurity a résolu son problème.
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Ha je ne connaissais pas grsecurity Faudra que je regarde ca quand j'aurai fini mon blocus "A restriction that allows a user to only view his/her processes" Waiiii je cherchais justement comment ils faisaient ca chez OVH ! Merci Dan !
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 (modifié) salut Dan comme l'indique Gecko64 la mémoire est peut-être saturé, enfin je ne sais pas trop, ce reboot et aléatoire.. une fois par mois, 2 ou 3 fois par mois, parfois 2 mois sans rien, je pense donc qu'à un moment ou à un autre, une sécurité et touché et le serveur se coupe automatiquement, enfin c'est mon avis, j'ai transmis le fichier messages à Gecko64 qui est surement plus calé que moi pour ce qui concerne le changement de noyaux lol..... heuuuuuu, quand je passerais commande à ton niveau tu pourras éventuellement t'en occuper, car, pour moi .....,je viens de jeter un oeil ... je vais m'en passer Modifié 21 Mai 2008 par TrocWeb
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 J'ai regardé mais je vois rien de spécial... Avant chaque redémarrage du système, on a toujours des événements différents... Une fois c'est une tentative de résolution de DNS qui échoue, une autre fois c'est une tentative d'intrusion ssh par dictionnaire ou encore par FTP... L'idéal je crois serait de voir tous les log du /var/log Ca me donnerait plus d'informations pour chercher une cause pouvant aboutir à ce genre d'ennui... Pour la compilation d'un kernel, oui il vaut mieux tester ca sur un PC de test à domicile avant de se lancer la dedans, crois moi Je m'y suis moi même plusieurs fois brulé les ailes au début
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 (modifié) merci pour ton aide je vais te joindre le fichier demandé, pour ce qui est de changer le noyau....... oublions cela Edi: je n'ai pas de fichier log Modifié 21 Mai 2008 par TrocWeb
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Non je parlais du dossier /var/log complet Tu fais une archive tar et ainsi dedans je pourrai consulter les log de tous les services qui tournent pour voir si ca n'est pas un d'entres eux qui est en cause... N'oublie pas de la compresser avant, ca compresse bien le texte sinon ca risque de peser lourd :-/
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 c'est immense tout les dossier et fichier la dedans....
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 Oui je sais... :-/ C'est pour ca qu'il est mieux de compresser en créant l'archive pour que cela prenne beaucoup moins de place Sinon, je te fais un accès sur un PC chez moi et on se le file en scp Ca permet de faire des transfères de données entre 2 serveurs au travers un tunnel sécurisé (ssh)
TrocWeb Posté 21 Mai 2008 Auteur Posté 21 Mai 2008 non t'embête pas je vais te le mettre sur le ftp ........ question n'y a t-il pas des donnés sensibles dans ce dossier comme des mots de pass utilisateurs, root ou autres... ?
Gecko64 Posté 21 Mai 2008 Posté 21 Mai 2008 A ma connaissance non... Les fichiers sensibles en général sont /etc/shadow et /etc/passwd ainsi que ceux qui sont pour la db mysql dans /var/lib/mysql Le /etc/shadow contient en fait la liste des utilisateurs du système et il est en lien intime avec /etc/passwd qui lui contient les mots de pass des utilisateurs. A l'époque, les mots de pass étaient aussi dans /etc/shadow mais par sécurité, cela a été modifié vers un autre fichier. Le /var/log lui contient que des logs système sans plus... Ce sont juste des événements qui viennent des différents processus tournant sur ton système. Tiens, je te met la commande scp si tu veux regarder: scp -r /var/log user_AT_host:/rep/ou/fichier/distant -r c'est quand on veut copier un répertoire complet d'un serveur vers un autre Dans notre exemple, il s'agira du dossier /var/log user étant l'utilisateur distant et le host est l'ip du serveur distant sur lequel on veut envoyer les données. Ensuite, il y a juste a respecter l'arborescence des répertoires Pour le ftp ca va alors mais je ne promet pas de regarder ce soir pcq il se fait déjà un peu tard EDIT: A mon avis tu n'es pas sous Linux Debian pcq le dossier de log apache est httpd chez toi alors que sous Debian, ils le nomme tout simplement apache2. C'est une Fedora même. Enfin ca ne change rien, du linux et des log ca reste le même. Je jette un oeil rapidement. EDIT2: Apparemment ton souci daterait du 12 aout 2007 si je ne me trompe pas. 070812 11:05:50 InnoDB: Database was not shut down normally! On remarque que mysql a plusieurs reprise a été mal arrêté dans le fichier de log. Je vois plusieurs causes possibles comme un kernel panic ou alors une saturation des ressources qui entrainerait le plantage complet du système... Je vais consulter le reste et donnerai des news si je trouve du nouveau, ou pas... EDIT3: J'ai bon faire le tour de tout les log, on voit juste qu'il se coupent brusquement a des moments mais sans laisser la moindre trace. Je me demande si la machine ne nous fait pas un kernel panic. Sinon note au passage, tu en ramasses des attaques pour rentrer par phpmyadmin, xamp et j'en passe. Ce genre de chose quand je le met sur un serveur, je sécurise toujours par un htacces par dessus. Une webradio ou j'étais admin adjoint avait eu ce genre de souci sauf que la, on s'était fait avoir. Enfin, ca n'était pas la partie du serveur que je gérais
TrocWeb Posté 22 Mai 2008 Auteur Posté 22 Mai 2008 (modifié) merci pour tes analyses il est normalement impossible de ce connecter sur phpmyadmin sans passer par le plesk, j' ai essayé à plusieurs reprises, je n'ai jamais trouvé comment concernant les attaques, je ne vois pas trop quoi faire pour bloquer cela, il est certains que ce n'est pas bon et que cela doit aussi ralentir le server Modifié 22 Mai 2008 par TrocWeb
Gecko64 Posté 22 Mai 2008 Posté 22 Mai 2008 Bha effectivement, ca fait des requêtes mais ca n'est pas non stop donc ca va encore
Kioob Posté 23 Mai 2008 Posté 23 Mai 2008 S'il s'agit vraiment d'un "kernel panic" un moyen de limiter la casse est d'ajouter un panic=N coté bootloader afin d'indiquer au kernel de rebooter après N secondes. Mais s'il s'agit d'un kernel OVH, la probabilité que ça coince sur leur matos me semble faible. Là comme ça, s'il n'y a absolument aucune trace dans les logs j'aurais plutôt vu un problème hardware...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant