Partage
  • Partager sur Facebook
  • Partager sur Twitter

Problème SSH/ Shutdown (VPS Debian)

    31 juillet 2015 à 0:49:05

    Bonsoir à tous
    j'aimerais faire appel aux éventuels personne susceptible de m'aider, je suis prestataire d'un VPS Debian chez Firstheberg, cela fait un bon moment que je l'utilise sans rencontrer de problème particulier, néanmoins depuis prêt d'une semaine, je rencontre des problèmes persistants avec ma connexion SSH, et autant dire que c'est très pénalisant puisque je n'ai pas d'autres moyens d'accès au VPS.

    La première fois que cela m'est arrivé j'ignorais d'où venais le problème avant de mettre la main sur des logs via le logiciel vncViewer (même constat avec le port 22)
    <14> 2015-07-25T22:01:20.247Z GAETAN-PC vncviewer[5048]: ProxySettings: Using direct connection
    <14> 2015-07-25T22:01:20.247Z GAETAN-PC vncviewer[5048]: CConn: Connecting to 185.13.39.162::5901 (Direct TCP)
    <15> 2015-07-25T22:01:20.247Z GAETAN-PC vncviewer[5048]: TcpAddrConnector: Trying 185.13.39.162::5901
    <15> 2015-07-25T22:01:21.374Z GAETAN-PC vncviewer[5048]: FdIo: shutdown 0000000000599F90 (fd=784), flush false (tellHandler false)
    <11> 2015-07-25T22:01:21.374Z GAETAN-PC vncviewer[5048]: CConn: connection error: connect: Connection refused (10061)
    <14> 2015-07-25T22:01:21.374Z GAETAN-PC vncviewer[5048]: CConn: close: [System] Connexion refusée par l'ordinateur hôte

    Dans mon ignorance j'ai alors demandé un reboot puis contacté mon hébergeur qui m'a assuré que la connexions RDP/SSH était bien ouverte de leur côté et que le serveur ping. Le lendemain nous avons à nouveau échangé après avoir moi même échanger avec quelqu'un d'autre sur le web qui avançait alors que la connexion SSH était out, une avance qui s'est avéré pertinente puisque après avoir recontacté mon hébergeur, celui-ci a remarquer que cette fois-ci la connexions SSH était effectivement out et donc que je devais l'avoir désactiver d'une manière ou d'une autre. Peu après les techniciens de Firstheberg ont remis la connexions SSH en place sans me la facturer et après redémarrage des différents service (apache2 ; FTP ; BDD etc) tout re-fonctionnais, néanmoins je n'ai même pas eu l'occasion de prendre le temps d'aller étudier les logs que le problème s'est à nouveau reproduit.



     
    J'ai maintenant pu voir l'erreur en question à travers le screen "the system is going down for halt NOW!" et j'en déduis donc que celui-ci m'impose un shutdown sans me prévenir ... Ce qui éteint par la même occasion les autres services installer sur la machine, à commencer par la connexions SSH mais aussi le FTP ; apache ; la BDD etc

    J'aimerais donc savoir comment est-ce que je pourrais m'en sortir, mon expérience de Linux reste très modeste, bonne fin de soirée à tous.
    • Partager sur Facebook
    • Partager sur Twitter
      31 juillet 2015 à 7:58:58

      regarde si tu a encore de la ram ? si tu tape pas dans la swap

      si ton disque dur est pas plein deja

      • Partager sur Facebook
      • Partager sur Twitter

      On estime à environ 550 millions le nombre d'armes à feu actuellement en circulation. Autrement dit il y a un homme sur douze qui est armé sur cette planète. La seule question c'est … comment armer les onze autres ?

        31 juillet 2015 à 8:35:00

        Pas de souci particulier du côté du disque dur, il y a encore de la marge :).
        Par contre il y a de quoi se poser la question pour la mémoire effectivement, j'ai 4 go de dédier sur le VPS (je ne suis pas habitué à tirer de conclusion de ce genre de graphique) mais on dirait bien que la ram est solliciter au taquet effectivement ...
        Par contre je ne serais pas dire comment on en arrive à ce niveau là surtout avec les services annexes éteint.
        • Partager sur Facebook
        • Partager sur Twitter
          31 juillet 2015 à 12:35:29

          Salut,

          Que donne la commande "top" ?

          • Partager sur Facebook
          • Partager sur Twitter
            1 août 2015 à 19:48:05

            on y arrive au probleme de ram ,

            ce genre de probleme est souvent du a un problème de ram

            • Partager sur Facebook
            • Partager sur Twitter

            On estime à environ 550 millions le nombre d'armes à feu actuellement en circulation. Autrement dit il y a un homme sur douze qui est armé sur cette planète. La seule question c'est … comment armer les onze autres ?

            Anonyme
              1 août 2015 à 23:31:41

              Rednax a écrit:

              Salut,

              Que donne la commande "top" ?

              Yep essaye de voir si t'as pas un processus qui déconne un peu ...



              • Partager sur Facebook
              • Partager sur Twitter
                2 août 2015 à 10:53:58

                tu peux nous donner le resultat de la commande top ? ou free ?
                • Partager sur Facebook
                • Partager sur Twitter

                On estime à environ 550 millions le nombre d'armes à feu actuellement en circulation. Autrement dit il y a un homme sur douze qui est armé sur cette planète. La seule question c'est … comment armer les onze autres ?

                  2 août 2015 à 20:39:51

                  Merci beaucoup pour vos réponses, je pense qu'il y a deux lectures possible pour le graphique. Soit la ram est effectivement sollicité au taquet, soit elle n'est quasiment pas sollicité (au quelle cas il faudrait lire la barre bleu comme étant la ram utiliser et la barre rouge comme le maximum possible). Dans les deux cas on a que l'état du serveur actuellement et non au moment de l'incident (j'ai screen ce qu'il s'est passé du côté CPU à l'instant T mais pas du côté de la ram malheureusement).

                   Concernant les commandes top ou free, il faut avoir accès à la console graphique pour les utiliser, non ? Sans SSH c'est actuellement compliquer, je viens d'effectuer un balayage des ports via Zenmap sur mon PC Windows et voici ce qui en sort :



                  Je vais contacté mon hébergeur pour voir s'il peut me remettre le SSH pour la seconde fois, si celui-ci accepte il me faudra rapidement trouver et résoudre la cause du problème au risque de retourner à la case départ si l'erreur survient à nouveau :s. 

                  -
                  Edité par Dessicated 2 août 2015 à 20:44:14

                  • Partager sur Facebook
                  • Partager sur Twitter
                    3 août 2015 à 23:15:48

                    Salut,

                    Je ne sais pas si c'est moi mais ton graph sur la RAM ne dit pas grand chose. D’après la légende, on voit que tu as 4Go de RAM [maxmem] et 0 d'utilisé [mem] comme si ta machine était éteinte (ce qui est fort probable).

                    As-tu des log parlant ? Normalement la machine sait pourquoi elle s’arrête.

                    Cordialement,

                    Psy.



                    • Partager sur Facebook
                    • Partager sur Twitter
                      4 août 2015 à 23:26:21

                      Salut Psycotik,
                      bonne nouvelle mon hébergeur m'a remis la connexion SSH (pour combien de temps encore, je ne le sais pas,  j'ai subis un "Network Error : Software caused connection abort" venant de Putty tout à l'heure. La console veut jouer avec mes nerfs haha ^^.

                      Pour l'heure je n'ai rien constater d'étrange avec les commandes free/top, de mon côté j'ai réparer une erreur de débutant dans mon sources.list (dé-commenter deux ligne sarges liés à une installation de webmin alors que je suis sur wheezy. Webmin étant inactif je ne m'attarde pas trop sur son cas contrairement à mon FTP que je n'ai pas encore relancer car je le soupçonne d'avoir un rapport de cause à effet avec les derniers incidents.

                       On en arrive maintenant à ce qui nous intéresse : les logs. Et là j'avouerai être encore bien novice sur le sujet, j'ai un peu check tout ça avec la commande tail et j'ai installer logwatch mais dans les deux cas je doute que cela soit les meilleurs façon de consulter des logs, je vous donne donc mes résultats :

                      /var/log/wtmp : (crypter, normal ?)
                      http://gyazo.com/815ad10e3b98dab8b2b2a76cac1353f8
                      /var/log/messages :
                      http://gyazo.com/9c9ac21f1d5af8a882b0a5cff02fbdfc
                      Et enfin /var/log/syslog celui qui m'interpelle le plus car il est manifestement le résultat d'une intrusions (je n'étais pas connecté ce jours là et j'ai constater la perte de SSH le lendemain). Le screen m'intrigue d'autant plus que 2001 est le GID que j'utilise pour le FTP et que lorsque je fais un ls -l dans /var/log/ la plupart des users (même le syslog) apparaissent en ftpuser et je me demande si ils n'ont pas été modifier.
                      http://gyazo.com/dfb7ea16cdae241732bc7405a0bd8fcc

                      Enfin la commande sudo grep Failed /var/log/auth.log, me révèle que 4-5 IP essayait de se connecter dans une période assez élargis avant l'incident, des traditionnelles attaques par bruteforce ?

                       
                      • Partager sur Facebook
                      • Partager sur Twitter
                        5 août 2015 à 14:25:11

                        Salut,

                        A défaut de me prendre des coups de pelles en étant un peu HS, mais toutes ces erreurs dans ton syslog "de résolution IPV6" ne t'hérisse pas un peu les poils ? ^^

                        Si je ne me trompe pas, tu utilises BIND9

                        Solution : http://wiki.lomb.fr/DNS#IPV6

                        Si j'étais toi, je regarderais les upgrade possible ... parce que les logs ne sont pas très parlant concernant une coupure de service.

                        Et n'hésite pas à augmenter le niveau des logs de ton SSH. Option "LogLevel" dans le fichier conf de sshd, si je ne dis pas de bêtise ...

                        Tu n'aurais pas mis un fail2ban sur le port SSH en bloquant tout le monde en cas d'attaque brute ? (on ne sait jamais ^^)

                        Psy.

                        -
                        Edité par Psycotik 5 août 2015 à 14:25:47

                        • Partager sur Facebook
                        • Partager sur Twitter
                          8 août 2015 à 7:35:08

                          Effectivement cela me dérange pas mal d'autant plus que les requête ont été exécuté lorsque je n'étais pas connecté donc cela s'est fait indépendamment de ma volonté,  soit par un script/bot ou même le système. J'ai suivis le tutoriel, j'ai en revanche oublier de vérifier s'il y avait un problème ou pas sur mon adresse IPv4 avec dig. Je ne sais donc pas si cela fonctionnait avant le tutoriel ou non, mais dans tout les cas cela fonctionne bien. En revanche je ne sais pas d'ou sortent les autres tentatives de dig.


                          Je n'ai pas rencontré de nouveau problème avec SSH jusqu'à maintenant, en revanche au rayon des pistes si intrusion il y a eu j'ai :
                          bruteforce SSH
                          vncviewer (que je n'ai pas relancé depuis le shutdown) et sa connexion SSH pas toujours chiffré
                          le FTP (que je n'ai pas redémarrer non plus pour l'instant) 

                          Avec la commande last j'obtiens ceci (indépendamment de mes propres connexion) :

                          last -a -d -F -w -x
                           
                           
                          l'IP 0.0.0.0 correspond au système ici ? On voit bien le Shutdown à la seconde prêt. Je ne serrais dire à quoi tiens le "crash" du 28 en revanche.
                          J'ai du perdre SSH la première fois le 24 ou le 26, donc avant le crash affiché ici.

                          Je n'ai pas de fail2ban mais je prévois d'en installer un une fois tout ça régler, merci encore pour ton aide ^^.

                          -
                          Edité par Dessicated 8 août 2015 à 7:37:03

                          • Partager sur Facebook
                          • Partager sur Twitter
                            11 août 2015 à 11:23:29

                            un fail2ban  ne coupe pas le service ssh , il ban juste l'ip qui tente de bruteforce de facon temporaire
                            • Partager sur Facebook
                            • Partager sur Twitter

                            On estime à environ 550 millions le nombre d'armes à feu actuellement en circulation. Autrement dit il y a un homme sur douze qui est armé sur cette planète. La seule question c'est … comment armer les onze autres ?

                            Problème SSH/ Shutdown (VPS Debian)

                            × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                            × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                            • Editeur
                            • Markdown