Merci de vos réponses, vraiment !
Je fais dans la réponse groupée
- je viens de comprendre que les deux fichiers /wp-includes/js/tinymce/themes/advanced/skins/tmpfiles.php et /wp-includes/js/tinymce/skins/lightgray/fonts/tmpfiles.php sont
une erreur 301, une tentative d'accès web à des fichiers non-existants.
Donc, en fait, RIEN ne dit que l'IP en question soit liée aux fichiers donnant un accès shell présents dans ~/tmp
Et j'a n'ai aucun log d'IP voulant ouvrir des fichiers dans ~/tmp, ils ont été créés par un accès shell à un autre fichier qui les a créés après, mais le hacker n'a pas directement, depuis le web, ouvert ces fichiers, on dirait.
Le "seul" aspect préoccupant, en somme, c'est qui a bien pu créer, et comment, ces fichiers shell dans ~/tmp
- les fichiers dans ~/tmp ont été créés "ex nihilo", par un ou des fichiers inconnus
Cela fait deux séries de fichiers,
. un (ou des !) fichier(s) mystère, caché(s) quelque-part,
. les fichiers "vas-y trouve-les je m'en fous lol' dans ~/tmp
Le hacker a donc une "tour de contrôle" cachée quelque-part ailleurs dans mon hébergement.
Un autre fichier permettant de faire du shell et d'avoir accès à toutes les informations utilisateur.
- Je croyais que TOUT ce qui se fait en shell laisse une trace dans "history", et que seul l'utilisateur root peut en effacer des informations. Manifestement, je me trompais, vous me le confirmez, il est possible de faire ces créations/suppressions sans laisser la moindre trace loggée ?
- J'ai sans doute même trouvé ce qui m'a été installé, au moins en théorie :
http://thanat0s.trollprod.org/2013/0...r-php-du-pack/ (provoque une alerte Avast, mais c'est une page legit)
Screenshot issu de cette page :
http://thanat0s.trollprod.org/wp-con...gician_r57.png
Un fork possible de :
http://korben.info/c99-php-backdoor.html
- En l'état des choses, je ne nettoie pas encore mon site (suppression, réinstallation, changement mots de passe, etc), parce que, justement, je VEUX savoir par où c'est passé.
Imaginez que je supprime tout ce que je peux, que je réinstalle tout ce que je peux, que je change tous les mots de passe emails compris, pour découvrir un mois plus tard que le hacker est de retour. La perte de temps, la frustration !
Et en plus, c'est stimulant intellectuellement, ça compte, quand même (le genre d'attitude qu'on n'a, face à un hack, qu'après de nombreuses années à en prendre plein la tête et à apprendre sur le tas Même si ça aide d'avoir affaire à un hacker qui apparement se la joue discret et délicat, et ne veut pas jouer au con et tout supprimer ou transformer la machine à boîte à pédo/spam)
- j'ai cherché, au cas où, des traces "faciles", en faisant, depuis la racine du compte d'hébergement,
grep -r 'eval('
grep -r 'c99.'
grep -r 'rot13' .
grep -r 'base64_decode' .
grep -r 'uname -' .
grep -r 'r57' .
grep -r 'hasil' .
grep -r 'bajakan' .
grep -r 'pre-release' .
Et ça n'a retourné aucun résultat pertinent, ces expressions étaient seulement présentes dans des fichiers légitimes pour un emploi légitime.
Je ne dis pas qu'il n'existerait pas un bout de code exploitable de façon non-prévue, façon jolie faille non-encore patchée, hein, ça je n'ai honnêtement pas la compétence pour le dire.
@ Jejeleponey
- Je ne peux pas me baser sur les logs autour du moment de visite de l'IP incriminée. Trop de traffic, trop de choses loggées.
@ Monamiphil,
- tu as écrit «
Au sujet du dossier tmp, est-ce le dossier qui recoit les uploads des visiteurs qui desire partager du contenu sur le site?? Si tel est le cas, la faille que le hacker a tenter de faire est peut être la suivante: uploader un fichier qui devait dévoiler une faille et créer un ou des fichier(s) sur ton serveur et ensuite l'appeler via l'url qui retourne l'erreur 301. Cela voudrait dire que la faille qu'il a tenter d'utilisé n'a tout simplement pas fonctionné. »
Voyons les faits, des fichiers accessibles depuis le web (il s'agit du dossier /tmp d'un site web) permettent de faire du shell, et ils ont été placés là par quelque-chose ou quelqu'un.
Mais merci infiniment pour la mention de l'erreur 301, je n'avais pas réalisé que ces deux fichiers étaient
un échec, qu'ils n'avaient jamais existé tout court, et que, donc, l'IP ayant tenté d'accèder à eux était probablement juste un bot tentant sa chance, et pas celle de "mon" hacker.
Cela confirme qu'il n'y a eu aucun accès web à ces fichiers dans ~/tmp, donc on n'a pas de donnée IP valide.
- C'est un blog wordpress, l'inscription d'utilisateurs tiers n'est pas permise, donc en principe seul l'admin (moi) a le droit d'uploader des fichiers. A part des éventuels fichiers de session (wordpress en crée bien, non ?), il n'y a aucune raison valide pour que des fichiers soient créés dans ~/tmp
@Benoît934
- j'ai fail2ban aussi, il n'y a donc pas eu de bruteforce
- Tu as écrit «
Avec tout CMS je déconseille fortement d'avoir un dossier ou un fichier modifiable et executable par PHP, il est mieux de les modifier avec root. » -- Là je vais être franc, je n'ai aucune idée de si c'est blocable avec un site wordpress sans tout casser, si c'est blocable sur mon serveur, ou comment.
En tous cas, pas une bonne idée de chown root les fichiers d'admin s'il y a, peut-être, dedans, un fichier exploitable par le hacker pour créer des accès shell : là il aurait accès à tout le serveur et tous les sites web.
@ Cetic
- Il n'y a pas de fichier food.php sur l'hébergement, du moins à l'heure où j'écris ces lignes.
Une recherche dans l'accès log ne montre pas non plus d'accès web à quelque food.php que ce soit
@ Pprem
- Merci beaucoup pour la recommandation d'interdire l'exécution de fichiers dans le dossier /tmp !
Le hacker est cruel, il n'a pas créé de fichiers avec l'extension .php, donc on ne peut pas bloquer une simple extension.
Et forcer text/plain sur tous les fichiers pourrait, qui sait, causer des problèmes, allez savoir, s'il y a des usages légitimes.
- Je tenterais bien un .htaccess contenant juste "php_flag engine off" dans le dossier /tmp, c'est bon, ça, s'il te plaît ?
- Cela laisse malgré tout ouverte, béante, la question du "mais il a fait comment, le hacker, pour uploader des fichiers".
Et, bien pire, qui dit que le hacker ne peut pas faire uploader des fichiers dans un autre répertoire où l'exécution de php serait autorisée ? Tant que l'on ne trouve pas le moyen employé par le hacker pour placer ses fichiers shell, on craint ça...
@ TBC_Lyon
- En effet, je vais rajouter un .htaccess dans ~/tmp avec "php_flag engine off " pour bloquer l'exécution du php dans ce dossier , merci de confirmer Cetic Par contre, je ne peux pas "deny from all", si jamais c'est utile, je n'en sais rien et je ne peux pas prétendre être sûr que ça ne va rien casser.
- Renoncer aux htaccess en faveur du fichier virtual hosts. Je découvre tout juste la possibilité, je ne connaissais pas ! Wow O_o
Je me base sur
http://blog.stefanxo.com/2013/09/mov...ualhosts-file/ , et c'est apparemment bien utile, bien que bien complexe aussi.
S'il te plaît, je n'arrive pas à trouver l'information rapidement, est-il possible de, temporairement, "mixer" les deux, dire au virtual hosts une directive pour juste un répertoire (par exemple : php_flag engine off dans /home/lesitewebenquestion/tmp), sans devoir passer par la solution plus complexe consistant à renoncer entièrement aux .htaccess et faire tout dans le virtual hosts ?
***
Beaucoup de réponses, mais beaucoup de questions aussi ^^
Merci beaucoup, encore une fois, pour votre aide !