Forum Programmation.SQL Mysql piraté

Posté par  . Licence CC By‑SA.
Étiquettes :
2
29
mar.
2016

Bonjour,

Je travaille dans une petite association et depuis quelques jour des bénévoles qui s'inscrivent sur notre site reçoivent des emails frauduleux les invitants à renvoyer des informations personnelles.

Notre site Web s'appuie sur 2 frontaux APACHE et une bases MySQL.
Savez vous comment je peux détecter des piratages de notre base de données?

Est-ce qu'il y a une possibilité d'obtenir les logs des requêtes Mysql effectuées depuis 20 jours avec l'adresse IP qui a envoyé ces requêtes et la date?

Merci de votre aide.

Orwell

  • # au pif

    Posté par  . Évalué à 3.

    tu as les logs de mysql dans /var/log/mysql ?
    bon chez moi il n'y a que les error.log

    il doit falloir fouiller un peu dans le fichier de config de mysql pour savoir.

    sinon le plus simple, c'est deja de changer tous les mots de passe (ftp, ssh, mysql), y compris celui de l'appli web qui se connecte à mysql

    c'est contraignant mais c'est la meilleure technique
    verifier aussi que le fichier de configuration de l'appli ne soit pas lisible depuis le navigateur web (ce qui expose le login/pass de la base)

    • [^] # Re: au pif

      Posté par  . Évalué à 3.

      De mémoire, si l'attaquant est passé par apache, il doit y avoir un fichier /var/log/apache/access, qui liste les URIs visitées avec un horodatage (ou est-ce un timestamp?).

      Après, pour vérifier la BDD… ça va être plus compliqué, surtout si l'attaque à injecté du code dans les schémas (c'est ce que je ferais perso, si je devais faire un malware, avec des hook sur les requêtes). Bref: faire un backup des données SQL pertinentes et réinstaller la BDD à partir d'une version sûre me semble un minimum.

      Après, il faut se souvenir que les email ne garantissent pas l'expéditeur… ça me semble peu probable que les mails soient envoyés à partir de l'association, mais qui sait? Il suffit qu'ils aient récupéré la liste des mails, d'une façon ou d'une autre. D'ailleurs, c'est probablement pour ça qu'ils envoient un mail pour récupérer le password. S'ils avaient l'accès à la DB ça ne servirait à rien.

      • [^] # Re: au pif

        Posté par  . Évalué à 5.

        un horodatage (ou est-ce un timestamp?)

        Sauf erreur de ma part un "timestamp" et un « horodatage » désigne la même chose, le premier est le mot anglais, le deuxième le mot français.

    • [^] # Re: au pif

      Posté par  (site web personnel) . Évalué à 1.

      Le seul moyen dans MySQL d'avoir un log des connexion est d'activer le general log. Donc si general_log est 'OFF', tu n'auras pas de log des connexions à MySQL.
      Activer le general_log en production peut être dangereux, car comme chaque requête est loggée, cela peut générer une charge importante sur un serveur avec beaucoup d'activité.
      Il est aussi possible de logger les échecs de connexion (pour détecter une tentative de brute-force par exemple) en configurant le niveau de warning pour qu'il soit supérieur ou égal à 2.

  • # Re: Forum Programmation.SQL— Mysql piraté

    Posté par  (site web personnel) . Évalué à 4.

    Est-ce qu'il y a une possibilité d'obtenir les logs des requêtes Mysql effectuées depuis 20 jours avec l'adresse IP qui a envoyé ces requêtes et la date?

    ton mysql est ouvert sur l'exterieur ?!

    • [^] # Re: Forum Programmation.SQL— Mysql piraté

      Posté par  . Évalué à 4.

      Vu en milieu « professionnel », réalisé par des « experts » :

      GRANT ALL PRIVILEGES to *.* FROM root@'%' WITH GRANT OPTIONS;

      « Et voilà chers clients ! Ça marche ! »

      Tu m’étonnes…

      Bien évidemment inutile de dire qu’à ce niveau là MySQL écoute sur 0.0.0.0…

    • [^] # Re: Forum Programmation.SQL— Mysql piraté

      Posté par  . Évalué à 1.

      Euh, en fait y a un truc genre F5 ensuite si j'ai bien compris 2 apaches et sur les apaches mysql est installé aussi.
      Je sais pas comment les 2 mysql communiquent entre aux, s'ils se répliquent genre master<=>master.
      Sinon non il est pas directement ouvert sur l'extérieur.

  • # hop

    Posté par  (site web personnel) . Évalué à 1.

    Si ce n'est pas une asso religieuse, pas contre des libertés et autre du genre, je propose mes services (gratuitement).

    Sinon,
    Si ton code est accessible en écriture pour l'utilisateur propriétaire du process apache, il y a de forte chance pour qu'il se soit fait véroler.

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

    • [^] # Re: hop

      Posté par  . Évalué à 1. Dernière modification le 29 mars 2016 à 22:14.

      Merci M.Poil

      Non nous ne sommes pas une association religieuse ni de gens qui veulent restreindre les libértés ;-).
      J'apprécie beaucoup ta proposition, toutefois il est plus formateur pour moi de chercher et d'explorer les pistes et conseils que je trouve ici que de faire intervenir qqu'un qui me m'apprendra peut être plein de truc sur le coup mais des trucs que j'oubliai ensuite…

      • [^] # Re: hop

        Posté par  (site web personnel) . Évalué à 1.

        Pas de soucis, regarde dans ton index.php, ton config.php ou autre fichier inclus dans toutes tes pages si tu n'as pas un code malicieux.
        Si c'est un CMS, le mieux est de repartir d'une base saine, tu sauvegardes, redéploies le code dans sa dernière version. Tu cherches ensuite en base si tu n'as pas un compte privilégié non souhaité.
        Puis tu appliques une politique de sécurité sur tes fichiers, généralement sur des dossiers 2750 en utilisateur : gestionnaire_du_site, groupe apache (ou www-data) et 640 sur les fichiers. Seules les dossiers devant être accessible en écriture devant être en 2770 (ou apache:apache en 750). Tu peux également jouer avec les ACLs (pré-requis dans certains cas, ex sur du symfony2)

        Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

  • # To protect and to serve

    Posté par  . Évalué à 3. Dernière modification le 30 mars 2016 à 17:57.

    Voilà mes petits conseils :
    0/ Mettre à jour :
    Sur quoi se repose le site ? SPIP ? Joomla ? Wordpress ? Galette ?
    Du coup il faudrait mettre à jour la solution utilisée, si ce n'est pas une "fait maison", pour supprimer le "code malicieux".
    1/ A titre préventif pour l'avenir, installer fail2ban sur les serveurs web et le configurer entre autres pour bloquer :
    - les injections SQL via http
    - les attaques brute force en ssh
    2/ Diagnostiques :
    - Reproduire le problème : s'inscrire avec une adresse email dragoncrypt jupimail par exemple, voir à quel moment l'email frauduleux est envoyé, si c'est instantané ou pas, essayer d'en déduire la page web potentiellement "vérolée"
    - Depuis quand les emails frauduleux sont diffusés ? pour chercher les fichiers modifiés depuis cette date dans la racine des serveurs web (exemple si c'est depuis 90 jours : "find /var/www/ -type f -mtime -90")

    Voilà pour l'instant, ne connaissant pas votre niveau en Unix/Linux, ni solution utilisée pour votre site associatif.

    • [^] # Re: To protect and to serve

      Posté par  . Évalué à 1.

      Salut,
      Merci beaucoup pour ses explications.
      Mon stage chez eux est terminé mais j'ai gardé des contacts je leur demanderai si ça se produit encore. Dans ce cas je leur dirai ce que tu m'as conseillé.

Suivre le flux des commentaires

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