[AG1111]

#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 2.1.1
#~ Url du site : paotredpagan.bzh
#~ Hébergeur / Soft : ovh
#~ Informations Système :
#~ ----------------------------------------------
#~ Cms Version: 2.1.1
#~ Installed Modules:
#~ CMSMailer: 5.2.4
#~ AdminSearch: 1.0
#~ FileManager: 1.5.2
#~ MenuManager: 1.50.2
#~ MicroTiny: 2.0.2
#~ ModuleManager: 2.0.1
#~ News: 2.50.3
#~ Search: 1.50.2
#~ ThemeManager: 1.1.8
#~ CGExtensions: 1.51
#~ JQueryTools: 1.3.8
#~ SiteMapMadeSimple: 1.2.8
#~ FormBuilder: 0.8.1.2
#~ Captcha: 0.5.2
#~ CMSContentManager: 1.1
#~ DesignManager: 1.1.1
#~ Navigator: 1.0.2
#~ Config Information:
#~ php_memory_limit:
#~ max_upload_size: 64000000
#~ url_rewriting: mod_rewrite
#~ page_extension:
#~ query_var: page
#~ auto_alias_content: true
#~ locale:
#~ set_names: true
#~ timezone: Europe/Paris
#~ permissive_smarty: false
#~ Php Information:
#~ phpversion: 5.6.20
#~ md5_function: On (Vrai)
#~ json_function: On (Vrai)
#~ gd_version: 2
#~ tempnam_function: On (Vrai)
#~ magic_quotes_runtime: Off (Faux)
#~ E_STRICT: 2048
#~ E_DEPRECATED: 8192
#~ test_file_timedifference: Aucune différence de date du système trouvée
#~ test_db_timedifference: Aucune différence de date du système trouvée
#~ create_dir_and_file: 1
#~ memory_limit: 512M
#~ max_execution_time: 300
#~ register_globals: Off (Faux)
#~ output_buffering: 4096
#~ disable_functions: _dyuweyrj4, _dyuweyrj4r, dl
#~ open_basedir:
#~ test_remote_url: Valable
#~ file_uploads: On (Vrai)
#~ post_max_size: 64M
#~ upload_max_filesize: 64M
#~ session_save_path: /tmp (0700)
#~ session_use_cookies: On (Vrai)
#~ xml_function: On (Vrai)
#~ xmlreader_class: On (Vrai)
#~ check_ini_set: On (Vrai)
#~ curl: On
#~ Performance Information:
#~ allow_browser_cache: Off (Faux)
#~ browser_cache_expiry: 60
#~ php_opcache: On (Vrai)
#~ smarty_cache: On (Vrai)
#~ smarty_compilecheck: Off (Faux)
#~ smarty_cache_udt: On (Vrai)
#~ auto_clear_cache_age: On (Vrai)
#~ Server Information:
#~ Server Software: Apache
#~ Server Api: fpm-fcgi
#~ Server Os: Linux 3.14.60-grsec-hosting-web-3.14 On x86_64
#~ Server Db Type: MySQL (mysql)
#~ Server Db Version: 5.5.46
#~ Server Db Grants: Impossible de trouver un privilège "GRANT ALL". Cela ne conduit pas nécessairement à des problèmes... Mais si vous avez des problèmes pour installer/retirer des modules ou ajouter/supprimer des éléments de contenu ou pages cela pourrait en être la cause.
#~ Permission Information:
#~ tmp: /home/randoker/paotredpagan.bzh/paotredpagan/tmp (0705)
#~ tmp_cache: /home/randoker/paotredpagan.bzh/paotredpagan/tmp/cache (0705)
#~ templates_c: /home/randoker/paotredpagan.bzh/paotredpagan/tmp/templates_c (0705)
#~ modules: /home/randoker/paotredpagan.bzh/paotredpagan/modules (0705)
#~ uploads: /home/randoker/paotredpagan.bzh/paotredpagan/uploads (0705)
#~ Masque de création de fichier (umask) : /home/randoker/paotredpagan.bzh/paotredpagan/tmp/cache (0705)
#~ config_file: 0444
#~ ----------------------------------------------
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Des scipts indésirables se retrouvent dans le code source de la page d'accueil du site, ce qui provoque l'arrêt de mes scripts, c'est comme cela que j'ai découvert le pb.

En consultant le wiki sur le sujet je me suis aperçu que mon .htacces était trop light, j' aurai besoin d'aide pour le mettre au point.
Mais avant cela, que dois-je faire pour supprimer ces scripts indésirable ?
La base de données peut-elle être impactée ? je n'ai rien vu à priori dans l'export sql, mais j'ai pu rater quelque chose.

Je pensais faire une réinstallation complète à partir des fichiers de la forge dans les version qui sont en cours avant de faire une mise à jour CMS et modules et modifer le .htacces.


Y a t'il d'autres solutions que le htaccess pour se prémunir contre de telles attaques ?


Merci d'avance pour vos réponses et sages conseils

Amicalement

Alain

[pierrepercee]

Tout un programme : Si Bess Passe par là, il te recommandera la lecture de son topo super bien foutu sur htaccess. C'est ici : cmsms securité

perso en plus des mises à jours régulières (enfin + ou moins j'avoue),

• -Je filtre un peu les url via htaccess pour dégager les chaînes le plus souvent suspectes.
  
• -Je change toujours le nom du répertoire d'admin (pas oublier dans config.php)
  
• -Je protège le répertoire Admin avec un htaccess (login+mot de passe)- Je mets le fichier contenant le has du mot de passe en dehors du répertoire adressable via un navigateur (à la racine de l'hébergement)
  
• -Je fais attention aux droits alloués sur les répertoires et les fichiers
  
• -J'utilise toujours des mots de passe de maniaque genre : mx5{{D£rgsD5PPpz
  
• -Je ne laisse pas la porte ouverte à des scripts externes, si exogène à CMSMS je les héberge en local
  

Je n'ai pas la prétention de maîtriser les aspects "sécurité". Cela requiert des compétences transverses dans des spécialités dont j'ai à peine entendu parler. Je suis simplement prudent et cela semble payer....

Pour ton problème je ferais un export de ta base. Avec un éditeur genre Notepad++ je tenterais de retrouver des morceaux de chaîne coupables en prenant soin de "bien formuler ta recherche" dans ce dump puis analyse par un bon antimalware/ antivirus.
Idem sur l'ensemble des dossiers et fichiers et en fonction du résultat....
Bon courage à toi cela peut paraître galère mais avec un peu de méthode c'est facilement jouable...

J'oubliais, toujours faire des sauvegarde régulières et persos (ne jamais compter sur celles de l'hébergeur: c'est une loi physique reconnue, le hack date toujours de la veille ou de l'avant veille de la dernière sauvegarde dispo :lol: )

[jce76350]

>2.1.1
déjà à la bourre de 2 versions maintenant c'est 2.1.3
ensuite le htacces modèle dans le dossier doc doit éviter un mini de problème.
Si un hébergement est infecté il faut mettre à nu tous les dossiers repartir de zéro en prenant soin de vérifier la(les) base de données sauvegardée.
Il y a un script de sa seigneurie qui permet de vérifier les fichiers régulièrement
Il existe chez certains hébergeur un protection complémentaire genre SiteLock.

[AG1111]

Merci à tous les 2 pour vos réponses.

Je me mets au travail et je vous tiens au courant de mes travaux.

Amicalement

Alain

[AG1111]

ouf. J'ai résolu le pb.

Je suis reparti d'une installation nouvelle dans un répertoire vide et une base de données vide. J'ai scanné tous les fichiers de uploads avant de les transférer sur le site et j'ai annalyser le dump de la base de données avant de la recharger.

j'en ai profité pour mettre à jour la version cms et celles des modules.

J'ai retrouvé un fonctionnement normal.
J'ai également mis en service les directives du htaccess.txt du répertoire doc.

Par contre j'ai encore un souci avec le renommage du répertoire admin comme le préconise Bess, renommage du répertoire et ajout d'une directive dans config.php.

Lorsque je fais cela, le site fonctionne mais je ne peux plus accéder à l'administration du site. Est-ce un fonctionnement normal ou devrais je pouvoir accéder à l'administration après avoir renommé le répertoire admin ?

[jce76350]

Par contre j'ai encore un souci avec le renommage du répertoire admin comme le préconise Bess, renommage du répertoire et ajout d'une directive dans config.php.

si ton dossier ex admin se nomme mon_admin_secret
Et que dans ton config.php $config['admin_dir'] ='mon_admin_secret';
cela fonctionne

maintenant si ton répertoire ex admin est aussi protégé par htaccess c'est la le problème
mais ça ne sert a rien si ton mot de passe est fort

[AG1111]

Merci JCE pour ta réponse. En effet ça marche, c'est moi qui ne réfléchis pas aussi bien qu'un miroir.

Mon problème est résolu, je modifie le premier poste

Merci pour votre aide

Amicalement

Alain