Forum Linux.debian/ubuntu Piratage de mon serveur et détection d'intrusion

Posté par . Licence CC by-sa
Tags :
2
7
nov.
2014

Bonjour à tous,
J'ai un Virtual Private Server (VPS) Debian7 chez OVH qui héberge du mail (postfix+dovecot) et du web (apache2). Je n'ai pas vraiment de connaissance pour administrer ce genre de service et j'ai configuré le bouzin en suivant les divers tutos sur le net.

J'ai reçu une alerte de ovh qui m'a signalé une activité anormale de mon vps. Par précaution, Ovh l'a alors mis en quarantaine. Du coup, j'ai fait un reset et j'ai réinstallé le bazard avec une config plus secure. J'ai récupéré un back-up complet de l'ancien système et j'aimerais bien investiguer les logs pour savoir Comment-pourquoi-quand-… le pirate est entré de mon système.

Je ne sais pas trop par où commencer !
Quelqu'un pourrait-il m'aider à démarrer ?

Merci !

  • # Logs

    Posté par . Évalué à -1.

    Bonjour,

    Il faudrait commencer par fouiller un peu dans les logs : firewall, accès ssh, système…

    • [^] # Re: Logs

      Posté par . Évalué à 2.

      Il faudrait commencer par fouiller un peu dans les logs : firewall, accès ssh, système…

      c'est un peu le sens de sa question :

      et j'aimerais bien investiguer les logs pour savoir Comment-pourquoi-quand-… le pirate est entré de mon système.

      • [^] # Re: Logs

        Posté par (page perso) . Évalué à 7.

        Faisons l'hypothèse que le pirate est entré par une faille d'un site php, et qu'il a utilisé ton système pour spammer le monde.

        Tu n'auras rien dans les logs ssh, rien dans les logs système : et pour cause, le système tourne comme a son habitude, sauf que le code exécuté n'est plus le même.

        Par contre, tu auras des traces dans le serveur mail (envoi des mails depuis la machine locale) et dans les logs du serveur web (mais qui peuvent être plus compliquée à identifier).

        Tu devrais également avoir des traces dans /tmp (téléchargement d'un code perl ou php stocké sur place).

        As tu plus d'info sur cette « activité anormale » ?

        • [^] # Re: Logs

          Posté par . Évalué à 3.

          Autre hypothèse: si le pirate a trouvé le mot de passe d'un compte, il a pu se connecter par exemple en SSH… On pourrait peut-être retrouver des traces dans /var/log/auth.log… sauf si le pirate a effacé ces traces.

      • [^] # Re: Logs

        Posté par . Évalué à 0.

        Ah oui autant pour moi…

        Donc autre question, qu'aviez-vous en place comme sécurité sur votre système ?

        • [^] # Re: Logs

          Posté par . Évalué à 1. Dernière modification le 07/11/14 à 15:03.

          Honnêtement, j'ai fait ça à minima avec juste un firewall. C'est juste un serveur de test qui n'héberge aucune données sensibles mais j'aimerais bien savoir comment l'intru est passé et ce qu'il a fait.

          • [^] # Re: Logs

            Posté par (page perso) . Évalué à 3.

            Honnêtement, j'ai fait ça à minima avec juste un firewall. C'est juste un serveur de test qui n'héberge aucune données sensibles

            La plupart des attaquants ne sont pas intéressés par les données qui peuvent se trouver sur une machine ; c’est la machine elle-même qui les intéresse.

  • # Solution [enfin... je crois]

    Posté par . Évalué à 2.

    Bonjour,
    Merci pour vos conseils. J'ai vérifié les mails (les logs de postfix) puis les authentifications (/var/log/auth).

    Je pense avoir trouvé la façon dont l'intru a pénétré le serveur. Le pirate a dû intercepter un mail où je communique à un utilisateur son mot de passe. Il ne restait alors plus qu'au pirate de trouver le bon login. Avec les indices contenus dans le mail, le pirate a essayé une série de logins possibles… Jusqu'à tomber sur le bon !

    En ce moment même le pirate des caraïbes continue son cirque mais j'ai changé les mots de passe de tous les utilisateurs.
    Grrrrrrr….. C'est une bonne leçon !

    • [^] # Re: Solution [enfin... je crois]

      Posté par (page perso) . Évalué à 3.

      Une des premières choses que je fait sur un nouveau serveur :

      • copier ma clef publique ssh sur le serveur
      • désactiver la connexion ssh par mot de passe
      • installer fai2ban

      Ça limite déjà les risques…

      • [^] # Re: Solution [enfin... je crois]

        Posté par . Évalué à 3.

        D'ailleurs, s'il a eu accès à un compte, il faut vérifier s'il n'a pas lui aussi laisser un clé publique. Ce qui lui permetterait de se reconnecter malgrès le changement de mots de passe.

        Les clés publiques sont contenues dans le fichier $HOME/.ssh/authorized_keys .

  • # Pas forcément une intrusion

    Posté par . Évalué à 1.

    Es tu certain qu'il s'agit d'une intrusion ?

    Quand OVH t'envois ce genre de message c'est parce qu'ils on découvert une activité suspecte sur la bande passante, tu devrais avoir un extrait des logs dans le mail qui aide à l'investigation.

    Je suggère plutôt une mauvaise configuration de postfix qui serait en open relay permettant à n'importe qui d'envoyer massivement du spam via ton serveur.
    Comme tu précise avoir configuré ton serveur sans trop en maîtriser les subtilités, c'est sur ce point que j'investiguerais en premier, sans pour autant exclure les autres pistes citées ci-dessus.

    tu peux faire un test rapide ici : mxtoolbox

    Ce principe de configuration "permissive" n'est pas valable uniquement pour postfix, j'ai par exemple récemment eu ce genre de problème avec une instance elasticsearch qui autorisait l'utilisation de l'API publiquement, ce qui à servit de maillon amplificateur dans une attaque DDOS.


    Quand à ton scénario d'un email intercepté et d'une déduction du couple login / mot de passe par l’attaquant à partir du contenu de ce mail, mise à part une attaque ciblée spécifiquement contre toi, j'en doute franchement.

    Pour tes logs ssh, c'est normal pour un serveur ssh autorisant la connexion par mot de passe et qui tourne sur le port 22 de voir de nombreuse tentative de connexion.
    Il n'est pas impossible non plus qu'une attaque par brute force ssh durant des jours / semaines ai fonctionné avec un mot de passe faible.

    Installe fail2ban pour envoyer aux oubliettes les nuisibles qui grattent à ta porte.

    Tu peux également configurer fail2ban grâce aux nombreux filtres par défaut ou en créer des personnalisés pour protéger ton serveur web et mail des attaques les plus courantes.

    • [^] # Re: Pas forcément une intrusion

      Posté par . Évalué à 1. Dernière modification le 08/11/14 à 09:27.

      Es tu certain qu'il s'agit d'une intrusion ?

      Non en effet, je ne suis sûr de rien.

      Quand OVH t'envois ce genre de message c'est parce qu'ils on découvert une activité suspecte sur la bande passante, tu devrais avoir un extrait des logs dans le mail qui aide à l'investigation.

      Voila la notification que j'ai reçu d'ovh : http://pastebin.com/PyzWezyE (les "xxxxxx" représentent l'ip du serveur).
      J'avoue ne pas trop comprendre de quoi il s'agit. Est-ce des tentatives de login ssh ?

      Je suggère plutôt une mauvaise configuration de postfix qui serait en open relay permettant à n'importe qui d'envoyer massivement du spam via ton serveur.

      Non j'ai fait attention à ça. Le smtp est interdit, seul le smtp par TLS avec authentification est autorisé. J'ai regardé les logs du mail et je n'ai rien détecté d'anormal.

      Quand à ton scénario d'un email intercepté et d'une déduction du couple login / mot de passe par l’attaquant à partir du contenu de ce mail, mise à part une attaque ciblée spécifiquement contre toi, j'en doute franchement.

      C'est vrai que ce scénario fait un peu théorie du complot. Mais ce qui me fait pencher sur ce scénario c'est cela : http://pastebin.com/RXzgKmD0 (extrait du /var/log/auth).
      J'héberge sur ce serveur mon petit neveu Ernest. Étant donné son âge, il est impossible qu'il se soit loggé par ssh à 4h du matin. Par contre, le robot semblait connaître le mot de passe à l'avance puisqu'il a réussi à se connecter dés la première tentative.

      Bien sûr, ce ne sont que des suppositions et je ne suis sûr de rien.

      PS : Merci pour le conseil fail2ban !

      • [^] # Re: Pas forcément une intrusion

        Posté par . Évalué à 2.

        Voila la notification que j'ai reçu d'ovh : http://pastebin.com/PyzWezyE (les "xxxxxx" représentent l'ip du serveur).
        J'avoue ne pas trop comprendre de quoi il s'agit. Est-ce des tentatives de login ssh ?

        si tu regardes les logs,
        c'est ta machine (srcIp:srcPort) qui tente de se connecter sur les autres (dstIp:dstPort) sur le port 22
        c'est donc ta machine qui scanne les autres et tente d'entrer chez elles.

        il y a donc quelqu'un qui scanne les machines voisinnes.

        tu peux limiter cela en bloquant avec le parefeu la destination du port 22 en sortie de ta machine,
        evidemment cela devient contraignant si tu utlises toi meme cette machine pour faire du SSH vers d'autres machines (celle de tes clients par exemple)

        • [^] # Re: Pas forcément une intrusion

          Posté par . Évalué à 1.

          Merci,
          J'ai compris le truc de travers.

          Alors quelqu'un s'est bien introduit dans ma machine et s'en sert de relais pour scanner les machines voisines.
          Du coup, comment puis-je avoir (à partir des logs de ma machine) plus d'informations sur ces tentatives de connection (utilisateur, date, etc…) ?

          Encore merci pour votre aide.

          • [^] # Re: Pas forcément une intrusion

            Posté par . Évalué à 2.

            Du coup, comment puis-je avoir (à partir des logs de ma machine) plus d'informations sur ces tentatives de connection (utilisateur, date, etc…) ?

            ben dans les logs de ta machine, tu as les infos, il faut juste filtrer.

            • dans l'extrait ovh, tu as une date/heure d'attaque vers d'autres machines. on peut esperer que leur outil est 'rapide' donc l'attaque sortante a demarré peu de temps avant.

            tu peux deja regarder de ce coté là.

            • ensuite, tu as reinstallé la machine, mais tu as peut-etre fait une sauvegarde "verolée" pour pouvoir l'analyser.

            regarde dans cette sauvegarde quels seraient les fichiers utilisés lors de cette attaque,
            s'il le faut tu reinstalles la sauvegarde dans une machine virtuelle avec un reseau bidon sur lequel il n'y a rien d'autre,
            avec de la chance, les scripts d'attaque se lanceront quand meme, tu pourras alors investiguer avec ps, top (enfin si ceux-ci n'ont pas été modifiés), tu vas alors trouver des noms de programmes/scripts.

            ils vont avoir une date, generalement celle de la depose du fichier sur ta machine
            avec cette date tu sauras quand l'attaque de ta machine a eu lieu.

            • puis tu retournes dans les logs pour savoir comment elle s'est passée.

            enfin tout ca en esperant que l'attaque entrante n'ait pas eu lieu y 6 mois (sauf serveur critique, on garde rarement 6 mois de logs)

      • [^] # Re: Pas forcément une intrusion

        Posté par (page perso) . Évalué à 3.

        C'est vrai que ce scénario fait un peu théorie du complot. Mais ce qui me fait pencher sur ce scénario c'est cela : http://pastebin.com/RXzgKmD0 (extrait du /var/log/auth).
        J'héberge sur ce serveur mon petit neveu Ernest. Étant donné son âge, il est impossible qu'il se soit loggé par ssh à 4h du matin. Par contre, le robot semblait connaître le mot de passe à l'avance puisqu'il a réussi à se connecter dés la première tentative.

        Si tu regardes le reste de l’extrait de /var/auth/log, tu peux constater que juste avant, la même adresse (185.25.151.145 — qui n’est probablement pas celle de la machine de ton petit neveu, tu peux essayer un whois dessus pour voir à qui elle appartient) a essayé successivement "erling", "erma", "ermolaev" (sans succès puisque ta machine n’a pas de comptes utilisateurs avec ces noms). Après avoir réussi à se connecter avec "ernest", elle a d’ailleurs continué avec "ernest21" et "ernestina"…

        Ça ressemble donc beaucoup plus à un scan bête et méchant avec un dictionnaire de noms d’utilisateurs qu’à une attaque ciblée.

        Quant à savoir comment l’attaquant a pu trouver le mot de passe de "ernest" à la première tentative de connexion avec ce nom-là : es-tu sûr que c’est la première tentative ? Je soupçonne que tu si tu remontes plus loin dans les logs, tu en verras beaucoup d’autres.

        Pour éviter que la même chose ne se reproduise, fail2ban est effectivement une bonne solution. Éviter les mots de passe trop faibles serait aussi une bonne chose, et se passer de mots de passe pour n’utiliser que l’authentification par clefs en serait une encore meilleure.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.