OVH Community, votre nouvel espace communautaire.

[Demande] Cherche requête pour supprimer les fichiers gif


cassiopee
06/02/2013, 16h09
Ah cool

steevejsk
06/02/2013, 16h02
Zut tu as raison mon forum est en multidom, maintenant avec le domaine principal tout les logs sont cliquables.
Bien vu Cassiopee .

cassiopee
06/02/2013, 15h53
Citation Envoyé par steevejsk
J'accède souvent à mon FTP, surtout ces derniers 30 jours, et je n'ai pas de logs!!!, ce n'est pas dû à mon offre Mutu Pro par hasard?
C'est pour le moins très étrange (mais bon, en ce moment chez OVH ... (*) )
Même avec un compte Perso on a ce genre de logs.

Es-tu sur le bon compte/nom de domaine ?

(pas de problème de sous-domaine ou encore un nom en ".fr" et un autre en ".com" ?)


(*) Cf là : http://forums.ovh.com/showthread.php?t=81123

Essaye peut-être de contacter "Alex.P" (qui travaille pour OVH), il pourra peut-être
rétablir tes fichiers de logs)

steevejsk
06/02/2013, 15h48
J'accède souvent à mon FTP, surtout ces derniers 30 jours, et je n'ai pas de logs!!!, ce n'est pas dû à mon offre Mutu Pro par hasard?

Nowwhat
06/02/2013, 15h45
Si, pendant un mois, personne
se connecte pas à SSH, il n'y aura pas des logs, donc pas d'info, donc pas de page
se connecte pas à FTP, il n'y aura pas des logs, donc pas d'info, donc pas de page

... mais bon, le log ftp ne peut être vide car les tâches de maintenance, mise à jour, sauvegardes, installation nécessite un accès FTP.
(je présume pas que tu travaille avec ce click-ftp-web-interface d'OVH ... trop chaint)

etc, etc.

D'ailleurs, SI un type possède l'accès FTP (login+ mot de passe) il aura aussi l'accès SSH.

steevejsk
06/02/2013, 15h10
Merci Cassiopee pour ces explication claires et précises.
Alors après m'avoir connecté sur ma page de logs, j'ai vu que mes logs se présentait de cette façon:
Statistiques brutes du 10/2012 : web - ftp - error - cgi - out - ssh
Statistiques brutes du 11/2012 : web - ftp - error - cgi - out - ssh
Statistiques brutes du 12/2012 : web - ftp - error - cgi - out - ssh
Statistiques brutes du 01/2013 : web - ftp - error - cgi - out - ssh
Statistiques brutes du 02/2013 : web - ftp - error - cgi - out - ssh

Et y a que la colonne (web) et (error) qui sont en bleu et sélectionnables, les autres non, c'est dû à mon hébergement? je suis en Pro.

cassiopee
06/02/2013, 12h25
Attention : il y a le fichier de logs "web" et il y a le fichier de logs "FTP".
C'est de ce dernier dont je parlais plus haut.

En principe, le fichier de log FTP ne devrait pas être si gros que ça.

Voilà à quoi ressemble le contenu du fichier de log FTP :

[2013 Jan 9 15:05:51] (?@82.83.84.85) [INFO] toto is now logged in
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [syst] []
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [feat] []
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [opts] [UTF8 ON]
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [pwd] []
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [type] [I]
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [pasv] []
[2013 Jan 9 15:05:51] (toto@82.83.84.85) [DEBUG] Command [mlsd] []
[2013 Jan 9 15:05:53] (toto@82.83.84.85) [DEBUG] Command [cwd] [www]
[2013 Jan 9 15:05:53] (toto@82.83.84.85) [DEBUG] Command [pwd] []
[2013 Jan 9 15:05:53] (toto@82.83.84.85) [DEBUG] Command [pasv] []
[2013 Jan 9 15:05:53] (toto@82.83.84.85) [DEBUG] Command [mlsd] []
[2013 Jan 9 15:05:58] (?@82.83.84.85) [INFO] toto is now logged in
[2013 Jan 9 15:05:58] (toto@82.83.84.85) [DEBUG] Command [opts] [UTF8 ON]
[2013 Jan 9 15:05:58] (toto@82.83.84.85) [DEBUG] Command [cwd] [/www]
[2013 Jan 9 15:05:58] (toto@82.83.84.85) [DEBUG] Command [pwd] []
[2013 Jan 9 15:05:58] (toto@82.83.84.85) [DEBUG] Command [type] [A]
[2013 Jan 9 15:05:58] (toto@82.83.84.85) [DEBUG] Command [pasv] []
[2013 Jan 9 15:05:58] (toto@82.83.84.85) [DEBUG] Command [stor] [download.php]
[2013 Jan 9 15:05:59] (toto@82.83.84.85) [NOTICE] /homez.399/toto//www/download.php uploaded (410 bytes, 24.59KB/sec)
"toto" est le login utilisateur, généralement dérivé du nom du site web chez OVH.
"82.83.84.85" est l'adresse IP à partir de laquelle est effectuée la connexion FTP.

Les lignes en gras permettent de voir qu'ici l'utilisateur s'est bien connecté et à
uploadé un fichier PHP nommé "download.php" à la racine du site web
(répertoire "www")

steevejsk
06/02/2013, 12h22
Hummmmm, je sens que je vais galérer!!
Dans les logs ovh, comment voir les ip de connexion? car c'est un énorme fichier texte!

cassiopee
06/02/2013, 10h47
Première démarche : s'assurer que le pirate n'a pas récupéré le login/mot de passe FTP
et qu'il passe par ce biais afin de revenir encore et encore dans le site.

Pour ça, il faut aller voir les fichiers de logs FTP là : https://logs.ovh.net

S'il y a des connexions FTP réussies à partir d'adresses IP inconnues et/ou lointaines,
c'est que le mot de passe FTP a été piraté. Très souvent ce sera parce qu'un malware est installé
dans le PC d'administration, et ce même si on y utilise un anti-virus. Le mieux est alors
d'utiliser plusieurs anti-virus (certains sont gratuits) afin de vérifier ce qu'il en est.

S'il n'y a pas de connexions FTP anormales, vraisemblablement le pirate passe par le web
et donc via une faille dans le script PHP. Ce peut être une faille dans le script principal
(ici vBulletin) mais également dans un plugin/addon/thème, etc. ajouté à ce programme principal.

La solution consiste à mettre à jour tous les logiciels PHP, plugins/addons utilisés
dans la toute dernière version possible.

Enfin, il se peut également qu'après un premier piratage réussi, même si on a comblé
correctement la faille, le pirate ait laissé un script PHP lui permettant de reprendre
facilement le contrôle du site web.

Repérer ce genre de scripts n'est pas facile pour quelqu'un dont ce n'est pas le métier.

mes fichiers joint sont stockés dans la Bdd, et la commande donnée dans le tuto concerne le ssh, donc l’hébergement.
Dans ce cas là, c'est tout à fait normal que la commande ne renvoie rien du tout

Y a t-il un moyen d'adapter la commande ssh pour qu'elle vise la Bdd?
Sans doute mais c'est du "sur mesure", on ne pourra pas facilement te donner
une commande MySQL équivalente car ça dépend de la base, de la façon dont
les données binaires des images sont encodées, etc.

et tout ça sans être sûr que le problème vienne de là.

steevejsk
06/02/2013, 10h31
Bonjour,
je reviens vers vous car le problème semble récurent, le problème revient après quelques heures.
J'ai tout fais ce qui est marqué dans le tuto pour éradiquer le problème, sauf la suppression du fichier gif corrompu, car mes fichiers joint sont stockés dans la Bdd, et la commande donnée dans le tuto concerne le ssh, donc l’hébergement.
Y a t-il un moyen d'adapter la commande ssh pour qu'elle vise la Bdd?

steevejsk
04/02/2013, 14h35
Le problème semble être réglé après avoir réuploader le fichier (crawlability_vbseo_vb4.xml), je suis entrain de mettre des htaccess dans les répertoires sensibles.
Merci les gars pour votre aide, vous êtes les meilleurs .

Nowwhat
04/02/2013, 12h01
Citation Envoyé par steevejsk
J'ai remarqué aussi que ça a une relation avec les cookies, car si je reviens en arrière après avoir été redirigé dans google, je reclique sur mon lien, mon forum s'ouvre normalement, mais si je supprime les cookies j'aurais encore la redirection!.
Si t'as un cookie, t'as le nom de ce cookie.
Donc: t'as que à localiser (une partie) de ce nom dans tes fichiers présent sur ton hébergement.
Sans accès SSH, télécharge ton site localement, et utilise un tool (genre Notepad++) qui te permet de chercher dans toutes les fichiers.

Il est possible que ne trouve pas ce nom de cookie dans ton code. Dans ce cas cherche aussi ceci: base64

cassiopee
04/02/2013, 11h41
Citation Envoyé par steevejsk
Je n'ai pas le souvenir d'avoir installé "Mobile Suite", en plus ça fait un bon moment que je n'ai pas touché à l'admin du forum vu que j'ai la version 4.2.0 qui est à jour!
Cf la réponse de Nowwhat, c'est une mise à jour (automatique peut-être ?) du forum
pour rendre compatibles vbSEO et cette "Mobile Suite", même si toi tu ne l'utilises pas,
ils font ça à titre préventif.

J'ai cherché (http://filestore72.info) dans ma base et dans les htaccess de Vbulletin et de Vbseo sans trouver la moindre trace.
Oui, c'était assez probable que ça soit crypté.

Plus qu'à trouver le ou les codes ajoutés ...

Peut-être par différence avec des fichiers plus anciens et sauvegardés ?

Ce n'est pas une garantie, mais tu peux aussi repérer des fichiers PHP ou autres,
modifiés récémment.



Au fait, petite traduction du texte explicatif que tu citais précédemment :

Ce que vous devez faire ...

Etape 1:

Ajouter un fichier .htaccess dans chaque répertoire accessible en écriture
où quelqu'un peut uploader une photo :

Code:
RedirectMatch 404 .*php\.
L'autre code que j'ai pour un ".htaccess" est celui là :

Code:

order allow,deny
deny from all
Je ne suis pas sûr de celui qui est le plus efficace
mais les deux devraient fonctionner. La plupart des gens
ont utilisé le second.

Heureusement, le fichier ".htaccess" a un effet récursif,
donc si vous le placez dans les répertoires vulnérables,
cela devrait résoudre le problème.

Les répertoires dans lesquels vous devez ajouter ce fichier sont :

customavatars
signaturepics
customprofilepics
attachments

Etape 2:

Uploader à nouveau le fichier "crawlability_vbseo.xml". Cela va purger le
cache et réparer immédiatement votre site ... tout dumoins si rien d'autre
n'a été compromis.

Etape 3:

Je dirais de désactiver tout upload vers votre serveur.
Ou au moins, de bien séparer vos utilisateurs en plusieurs groupes.

Ayez un groupe d'utilisateurs différents pour les membres "premiums",
(ou selon votre façon de répartir vos utilisateurs),
et n'autoriser que ceux là à uploader des fichiers,
pas pour les nouveaux utilisateurs et les spammeurs.

Si vous permettez aux nouveaux utilisateurs de faire des uploads,
vous vous exposez vous-même à ce genre d'attaques.

Etape 4:

Effacer de votre serveur tout fichier .gif malveillant

Pour se faire, connectez vous en ssh à votre serveur et tapez la commande :

Code:
find /home/main -regex '.*\.gif$' -exec grep php {} \;
Remplacez le "/home/main" par le répertoire racine de votre site.
Effacez les fichiers correspondants dans ces répertoires d'upload.
En général, je vérifie d'abord mais effacez les.


Etape 5:

Enfin, si vous avez été piraté, change les mots de passe. Juste au cas où.

......................

steevejsk
04/02/2013, 11h13
J'ai remarqué aussi que ça a une relation avec les cookies, car si je reviens en arrière après avoir été redirigé dans google, je reclique sur mon lien, mon forum s'ouvre normalement, mais si je supprime les cookies j'aurais encore la redirection!.

steevejsk
04/02/2013, 11h03
Citation Envoyé par cassiopee
Yep donc ne reste plus qu'à rechercher ailleurs.

Si tu es redirigé vers un site "www.toto.com", est-ce que tu as recherché la séquence "toto.com"
dans l'ensemble de ton site web ?
Je n'ai pas le souvenir d'avoir installé "Mobile Suite", en plus ça fait un bon moment que je n'ai pas touché à l'admin du forum vu que j'ai la version 4.2.0 qui est à jour!
J'ai cherché filestore72(point)info dans ma base et dans les htaccess de Vbulletin et de Vbseo sans trouver la moindre trace.

steevejsk
04/02/2013, 10h58
Citation Envoyé par Nowwhat
Un petit recherche dans le forum de ton CMS me donne:
http://www.vbseo.com/f77/vbulletin-m...ule-set-51265/
donc: non, t'as trouvé l'effet d'un mise à jour - rien s’alarment.

Ton .htaccess à l'air ok (car on trouve le même sur le net - Google te le confirmera).
Merci Nowwhat ça me rassure.

cassiopee
04/02/2013, 10h50
Yep donc ne reste plus qu'à rechercher ailleurs.

Si tu es redirigé vers un site "www.toto.com", est-ce que tu as recherché la séquence "toto.com"
dans l'ensemble de ton site web ?

cassiopee
04/02/2013, 10h48
Est-ce que tu n'aurais pas installé un programme "Mobile Suite" dans ton vBulletin ?

Nowwhat
04/02/2013, 10h47
Citation Envoyé par steevejsk
RewriteCond %{REQUEST_URI} !(admincp/|modcp/|cron|vbseo_sitemap|api\.php)

ça peux venir de là?
Un petit recherche dans le forum de ton CMS me donne:
http://www.vbseo.com/f77/vbulletin-m...ule-set-51265/
donc: non, t'as trouvé l'effet d'un mise à jour - rien s’alarment.

Ton .htaccess à l'air ok (car on trouve le même sur le net - Google te le confirmera).

steevejsk
04/02/2013, 10h28
Citation Envoyé par cassiopee
Très souvent ce genre de redirections sont faites via le fichier ".htaccess" à la racine du site web.

Donc déjà as-tu un tel fichier (ce qui pourrait par ailleurs être normal) et si oui,
quel est son contenu actuel ?
Bonjour, oui j'ai un fichier htaccess à la racine et voici son contenu:
Code:
# Comment the following line (add '#' at the beginning)
# to disable mod_rewrite functions.
# Please note: you still need to disable the hack in
# the vBSEO control panel to stop url rewrites.
RewriteEngine On

# Some servers require the Rewritebase directive to be
# enabled (remove '#' at the beginning to activate)
# Please note: when enabled, you must include the path
# to your root vB folder (i.e. RewriteBase /forums/)
RewriteBase /

RewriteCond %{HTTP_HOST} !^www\.monsite\.fr
RewriteRule (.*) http://www.monsite.fr/$1 [L,R=301]

RewriteRule ^((urllist|sitemap_).*\.(xml|txt)(\.gz)?)$ vbseo_sitemap/vbseo_getsitemap.php?sitemap=$1 [L]

RewriteCond %{REQUEST_URI} !(admincp/|modcp/|cron|vbseo_sitemap|api\.php)
RewriteRule ^((archive/)?(.*\.php(/.*)?))$ vbseo.php [L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !/(admincp|modcp|clientscript|cpstyles|images)/
RewriteRule ^(.+)$ vbseo.php [L,QSA]
J'ai remarqué que ce qui est en rouge ne y était pas dans mes anciennes sauvegardes!! avant c'était comme ça:
Code:
RewriteCond %{REQUEST_URI} !(admincp/|modcp/|cron|vbseo_sitemap)
ça peux venir de là?

cassiopee
03/02/2013, 22h52
Très souvent ce genre de redirections sont faites via le fichier ".htaccess" à la racine du site web.

Donc déjà as-tu un tel fichier (ce qui pourrait par ailleurs être normal) et si oui,
quel est son contenu actuel ?

steevejsk
03/02/2013, 22h45
Bonne question Cassiopee, en fait quand je clique sur mon forum depuis le résultat de google, on se redirige vers un autre site, ça se passa qu'une seule fois, c'est à dire si reclique sur mon forum depuis google une deuxième fois mon forum s'ouvre correctement.
J'ai fais une recherche sur le net et je suis tombé sur sur un sujet qui traite ce problème: http://www.vbseo.com/blogs/ig-r/goog...-359/?langid=2
Ils disent que c'est en relation avec Vbseo (un plugin qu'on ajoute à Vbulletin pour le SEO); et disent que c'est un fichier gif contenant un script qui profite du fonctionnement de Vbseo pour rediriger les clics vers ce site malveillant, et que c'est dù à un téléchargement d'un avatar en gif d'un spammeur.
J'ai fais une recherche sur tout les fichiers gif e mon forum, je n'ai trouvé aucun fichier suspect.
Peut etre le code est ailleurs? je ne sais pas comment régler ce problème.

cassiopee
03/02/2013, 11h50
Mais pourquoi penses-tu que c'est un gif qui pose problème ?

Si la commande n'a rien renvoyé, c'est qu'il n'y a pas de fichier gif contenant un code PHP.

Si tu parles de "redirection", ça me fait plutôt penser à un fichier ".htaccess"
corrompu/modifié ou encore à un code PHP/JS malveillant introduit dans un script PHP
ou Javascript.

steevejsk
03/02/2013, 02h55
Désolé les amis j'ai été pris par autres choses, en fait avec putty je n'ai eu aucun retour.
A la première tentative le logiciel m'avais donné une erreur de chemin, puis j'ai donné un autre chemin, et là il a mis quelques secondes d'attente puis m'a remis la ligne avec laquelle il a démarré, donc je pensait qu'il avait exécuté quelque chose, mais apparemment ce n'ai pas le cas, car j'ai toujours cette redirection sur google vers un site malveillant.
Comme je ne connais pas grand chose en prog, je vais faire l'idée de Gaston_phone, elle me parait plus facile pour moi.
Je vous tiendrais au courant, car je veux vraiment de me débarrasser de ce gif qui se sert de mon classement google pour affiché son site.
Je vais démarrer le transfère, merci beaucoup les gars pour votre réactivité.

cassiopee
01/02/2013, 23h30
Oui, pourquoi pas, si on n'a pas accès au ssh (compte perso) mais bon, autrement
il y a cette simple commande shell à taper.

Gaston_Phone
01/02/2013, 21h36
Citation Envoyé par cassiopee
Après ça dépend : si le contenu du dossier "www" représente 4-5 Go, le temps de re-uploader tout ça ...
Évidemment dans ce cas là.

Alors passer par un script PHP qui va explorer tous les dossiers.

une piste : glob — Recherche des chemins qui vérifient un masque.

cassiopee
01/02/2013, 21h27
Après ça dépend : si le contenu du dossier "www" représente 4-5 Go, le temps de re-uploader tout ça ...

Gaston_Phone
01/02/2013, 19h51
Une méthode que j'utiliserai personnellement :
  • Je téléchargerai sur mon micro, par FTP (FileZilla), la totalité du contenu du dossier /www.
  • Dans l'explorer je lancerai la recherche *.gif
  • J'obtiendrai ainsi la liste des fichiers incriminés ainsi que leur emplacement
  • Je supprimerai manuellement les fichiers gif douteux.
  • Par FTP, je viderai le contenu de /www
  • Par FTP, je transférerai le site expurgé dans /www.


cassiopee
01/02/2013, 19h29
C'est-à-dire ? La commande n'a rien affiché du tout en retour et t'a simplement rendu
la main ?

Alors soit tu ne "vise" pas le bon répertoire, soit il n'y a pas d'image gif
avec du code PHP à l'intérieur dans cette arborescence.

Normalement cette commande t'affiche les noms complets des fichiers gif
ayant une balise php à l'intérieur (c'est mieux que de supprimer directement
car cela permet de vérifier et de ne pas faire de faux positif, d'effacer un fichier
non impliqué.

steevejsk
01/02/2013, 18h46
Je viens d’exécuter la commande avec Putty, il ne m'a mis aucune erreur, mais aucune confirmation aussi!, je vais vérifier si ça a bien marché.
Merci beaucoup Cassiopee et Gaston_phone pour votre aide.

steevejsk
01/02/2013, 18h28
Citation Envoyé par cassiopee
Ok, donc ce n'est pas dans phpMyAdmin que ça se passe
(dans ce dernier, on tape seulement des requêtes SQL).

Il faut être connecté en SSH à ton site.

Cf là : http://guides.ovh.com/SshMutualise
Merci cassiopee, je vais lire tout ça.

cassiopee
01/02/2013, 18h20
Ok, donc ce n'est pas dans phpMyAdmin que ça se passe
(dans ce dernier, on tape seulement des requêtes SQL).

Il faut être connecté en SSH à ton site.

Cf là : http://guides.ovh.com/SshMutualise

steevejsk
01/02/2013, 18h18
Citation Envoyé par Gaston_Phone
Ne pas confondre dossiers et fichiers dans /www et les bases de données (phpmyadmin).

La commande "find" est à utiliser dans un environnement terminal ou via la commande system dans un script php.

Au fait quel hébergement as-tu : Perso, business, etc . ?
Je suis sur un hébergement Pro, oui je crois que je m’emmêle les pinceaux, à vrai dire je ne connais rien en programmation.
Pour faire simple, j'aimerais effacer tout les fichiers gif par une commande au lieu d'aller les chercher de partout, il existe une commande pour ça?

Gaston_Phone
01/02/2013, 18h11
Ne pas confondre dossiers et fichiers dans /www et les bases de données (phpmyadmin).

La commande "find" est à utiliser dans un environnement terminal ou via la commande system dans un script php.

Au fait quel hébergement as-tu : Perso, business, etc . ?

steevejsk
01/02/2013, 17h38
Je suis en mutualisé, et j'execute depuis Phpmyadmin, dans l'anglet "SQL" de ma BDD, c'est ce qu'il faut faire? ou je suis out?
Edit: je viens de tester dans l'anglet (Requête), ça me met en rour (Vous devez choisir au moins une colonne à afficher).
Désolé si je suis nul en programmation.

cassiopee
01/02/2013, 17h35
Es-tu bien connecté en SSH au mutualisé ? Tu n'exécutes pas cette commande
via un panel ou un script PHP ?

Je ne peux pas tester en mutualisé chez OVH mais la syntaxe est bonne,
vérifiée à l'instant dans une Release 2 d'OVH.

steevejsk
01/02/2013, 17h24
Merci cassiopee pour ta réponse, je vais tester.

Edit: ça ne marche pas, ça me met syntax invalide, peux etre je me trompe de chemin!!!
j'ai mis: find /www/(répertoire concerné) -name "*.gif" -exec grep php {} -ls \;

cassiopee
01/02/2013, 17h22
Plutôt comme ça :

Code:
find /home/main -name "*.gif" -exec grep php {} -ls \;
où "/home/main" est à remplacer par le répertoire à explorer.

Tu peux également te déplacer à la racine que tu veux explorer puis taper :

Code:
find . -name "*.gif" -exec grep php {} -ls \;
qui lui dit de démarrer sa recherche à partir du répertoire courant.

steevejsk
01/02/2013, 17h08
Bonjour,
je cherche une requête pour supprimer les fichiers gif de mon forum car hacké par un gif déguisé.
J'ai trouvé cette commande sur le net, mais ça ne marche pas:

Code:
find /home/main -regex '.*\.gif$' -exec grep php {} \;
Je suis en mutualisé, uelqu'un à une idée?

Merci pas avance.