sur les conseils (avisés) de b_b, je vous fais part d'un problème rencontré sur un hébergement mutualisé OVH.
Ça fait 2 fois que je me fais désactiver un hébergement par les robots d'OVH pour suspicion de piratage : des fichiers de cache sont en cause car ils contiennent des codes moisis.
Après avoir creusé bien profond avec ledit b_b, il s'avère que ces codes correspondent aux paramètres passés en arguments des URL appelées lors de tentatives de piratage mais ces paramètre ne sont pas interprétés par SPIP car ils concernent d'autres CMS. Et comme ces fichiers ne sont pas des fichiers PHP, ils ne peuvent pas être interprétés par PHP en dehors des squelettes où il sont appelés. Mais quand même, le fait est qu'il y a des fichiers avec du base64_decode/encode stockés sur l'hébergement.
Dans les logs, on trouve des appels type http://spip.pastebin.fr/61331 ce qui génère des fichiers de cache type http://spip.pastebin.fr/61332 (voir L53)
Les paramètres moisis étant passés à l'environnement, on les retrouve, comme tout paramètre, dans le cache. Normal.
Après échange bien profond aussi avec le support tech, il s'avère que, même s'ils ne sont pas interprétés, ces codes sont interdits sur leurs mutus pour éviter tout problème, donc tant qu'il y aura des tentatives d'attaque, je me ferai fermer mon hébergement.
Donc, ma question est : est-ce que l'écran de sécurité ne pourrait pas bloquer ces appels illégitimes (et potentiellement dangereux) avec base64_decode/encode dedans ? Sinon, est-ce que vous voyez une autre solution ?
ayant eu à nouveau des tentatives (repérées avant de me faire désactivé hébergement ce coup-ci), je tente une petite relance.
Si le blocage ne peut se faire via l'écran de sécu car pas pertinent/possible/souhaitable (biffer les mentions inutiles), est-ce que vous voyez une autre solution ? Si les attaques viennent du même pays, les IP ne sont bien sûr jamais les mêmes, donc la solution du blocage des IP n'est pas possible. Une solution serait de diminuer la durée du cache pour ne pas que ces fichiers restent trainer trop longtemps, mais comment être sûr qu'ils soient bien supprimer ?
Aussi, je m'étonne que seulement 2 de mes sites (de la même structure qui plus est) soient impactés. b_b a fait le tour des siens et n'a pas trouvé de fichiers similaires. Si l'envie vous prend de chercher dans vos caches, voilà la commande : rgrep "base64_decode" dossier_site/tmp/cache/
Si le blocage ne peut se faire via l'écran de sécu car pas pertinent/possible/souhaitable (biffer les mentions inutiles), est-ce que vous voyez une autre solution ? Si les attaques viennent du même pays, les IP ne sont bien sûr jamais les mêmes, donc la solution du blocage des IP n'est pas possible. Une solution serait de diminuer la durée du cache pour ne pas que ces fichiers restent trainer trop longtemps, mais comment être sûr qu'ils soient bien supprimer ?
Aussi, je m'étonne que seulement 2 de mes sites (de la même structure qui plus est) soient impactés. b_b a fait le tour des siens et n'a pas trouvé de fichiers similaires. Si l'envie vous prend de chercher dans vos caches, voilà la commande > : rgrep "base64_decode" dossier_site/tmp/cache/
Je 'ai pas trouvé non plus sur les miens (cherché via xray).
Tu peux tuer les requêtes qui contiennent la chaîne par le htaccess
avec (pas testé) quelque chose comme ça :
Aussi, je m'étonne que seulement 2 de mes sites (de la même structure qui plus est) soient impactés. b_b a fait le tour des siens et n'a pas trouvé de fichiers similaires. Si l'envie vous prend de chercher dans vos caches, voilà la commande > : rgrep "base64_decode" dossier_site/tmp/cache/
Je 'ai pas trouvé non plus sur les miens (cherché via xray).
Serais-je l'heureux seul spipeur dans la base des sites de ces script kiddies, lucky me
Tu peux tuer les requêtes qui contiennent la chaîne par le htaccess
avec (pas testé) quelque chose comme ça :
je vois pas quels mauvais effets seconds il peut y avoir...
Je vais tester ça, oui pas bête, peut être avec base64_decode pour limiter les effets de bord car il y a des plugins qui utilisent base64, mais je ne sais pas s'ils passent par des urls...
