Comme annoncé précédemment nous avons prévu la fin du support de Php 4 sur Celeonet à compter du 31 mai 2010.

Depuis plusieurs mois déjà, tous les domaines ou sous-domaines créés depuis votre interface client utilisent par défaut Php 5 quelle que soit votre offre.

Le 7 juin 2010, tous les domaines et tous les sous-domaines seront automatiquement migrés en Php 5 pour les offres mutualisées. Cependant, nous vous laisserons toujours, dans un premier temps, la possibilité de revenir au langage de script Php 4 depuis votre interface client. Les tableaux descriptifs de nos offres seront alors modifiés en conséquence.

Fin juin, les plateformes mutualisées actuelles seront remplacées par de nouvelles infrastructures compatibles avec notre nouvel interface client, alias v2. A partir de leurs mises en production, Php 4 ne sera plus disponible.

Les serveurs dédiés et virtuels ne sont pas concernés puisque l’utilisation de Php 4 ne peut avoir d’impact que sur leurs propres sites.

L’Équipe technique.

Nous vous annoncions en juillet 2007 la fin programmée de Php 4.

Depuis le 8 août 2008, la version 4 de Php n’est plus supportée par php.net et en toute logique plus aucun correctif de sécurité n’est publié.

Celeonet va donc progressivement ne plus proposer que la version 5.2.X qui exécute sans problème les scripts écrits pour Php 4. La version 5.3, qui préfigure le futur Php6, ne sera pas déployée massivement puisque la compatibilité ascendante des scripts n’est pas assurée.

Afin d’effectuer une transition en douceur tous les domaines ou sous-domaines nouvellement créés exécute Php 5.2 dans les environnements mutualisés, virtuels et dédiés.

A compté du 31 mai 2010, Php 4 sera définitivement supprimé de nos offres d’hébergement mutualisées.

Nous vous encourageons vivement à migrer vos sous-domaines en version 5, cette opération est simple et s’effectue via l’interface client Celeonet, Onglet “Domaines”, icônes “Gestion des sous-domaines et des versions”.

Initialement développé pour Joomla, Spyclic propose l’ajout d’un pluggin sur votre CMS.

A quoi sert ce pluggin ?
Il génère un fichier xml contenant les noms et versions de votre CMS et de ses composants, le serveur Spyclic va interroger régulièrement ce fichier et vous informer de toute faille de sécurité qui pourrait affecter votre site, bien pratique.

Attention Spyclic ne fait que vous prévenir des failles qui affectent votre site, il ne les corrige pas à votre place

Sur leur forum :

En savoir plus sur spyclic
Suite à de nombreux mails, je détaille le fonctionnement de Spyclic.

En fait, en vous inscrivant sur ce site, vous allez pouvoir ajouter un ou plusieurs sites.

Pour chaque site, un composant adapté vous sera proposé en fonction du CMS que vous utilisez.

Si vous installez ce composant sur votre site, il génère un fichier XML que vous pouvez protéger par un mot de passe.

Notre bot va chercher ce fichier XML plusieurs fois par jour et vous avertit par mail si un de vos composants n’est plus à jour.

De notre coté, nous mettons à jour très régulièrement notre base car nous gérons une vingtaine de sites sous Joomla.

Ce service est bien entendu complètement gratuit et nous vous invitons à l’utiliser pour lutter contre le piratage.

N’hésitez pas à nous faire un retour sur ce composant.

Pour éviter que votre site ou votre CMS ne soit un jour hacké, le plus simple est bien-entendu de le mettre à jour régulièrement

Beau discours, certes, mais prenons l’exemple du blog de Celeonet propulsé jusqu’à très récemment par Wordpress 2.5.

Ce moteur de blogs connait de nombreuses attaques depuis juin 2008 et nécessite impérativement une mise à jour vers la version 2.6.2. Nous ne sommes pas passés au travers et certains d’entre vous auront pu constater la disparition régulière du dernier article posté ou l’apparition dans son corps de liens vers des sites de Viagra etc…

Il est alors nécessaire de se poser les bonnes questions et de réagir de façon à rétablir le site dans son état de fonctionnement normal.

1°) Les choses à ne pas faire si votre site a été hacké.

a) Rétablir son site depuis la dernière sauvegarde : Si votre site a été hacké c’est qu’il présente une faille, le rétablir dans sa configuration initiale ne sert à rien, la faille sera toujours présente.

b) Supprimer la manifestation du hack : Comme pour le point a) il ne suffit pas de supprimer les méfaits du hackeur pour combler la faille.

c) Ecraser son site avec la dernière version du CMS utilisé : Mauvaise idée, rien ne vous garanti que le hackeur ne s’est pas ouvert une porte sur votre site pour le modifier à sa guise.

d) Ne pas prendre pour parole d’évangile les solutions “miracles” de certains contributeurs. Ils sont tous biens intentionnés mais peuvent parfois manquer de compétences. Par précaution travaillez toujours sur un espace de test pour vos mises à jours.

1°) Les choses à faire si votre site a été hacké.

a) Avant même de tenter de comprendre ce qui s’est passé, faites un état des lieux de votre site et notez tous les points anormaux (qui sont anormaux pas qui vous semble anormaux).
- Une page a-t-elle était modifiée ?
- Ma base de données est-elle toujours intègre ?
- Des pages ou des fichiers ont-ils été ajoutés sur mon site ?
etc…

b) Activez dans votre panel client l’accès aux logs Apache si cela n’est pas déjà fait. Cette opération ne vous permettra pas d’avoir de l’information sur le hack mais vous permettra d’en obtenir s’il se reproduisait.

b-bis) Vos logs sont déjà actifs ? S’ils ne sont pas trop volumineux fouillez les à la recherche de requêtes webs anormales ou générant de nombreuses erreurs 404. Attention ceci peut être long et laborieux, c’est peut-être la dernière étape à réaliser.

c) Rendez-vous ensuite sur le site de la communauté éditant votre CMS, dans 99.9% des cas vous constaterez que vous n’êtes pas un cas isolé et que d’autres utilisateurs rencontrent le même problème. Une faille est en générale corrigée par une nouvelle version du CMS.

N’hésitez pas à réinstaller complètement la nouvelle version “vierge” sur un emplacement de test, Celeonet vous permet de créer des sous-domaines et des bases de données distinctes, c’est le moment de mettre à profit cette fonctionnalité.

Cette procédure est plus longue mais aussi plus sûre. Vous pourrez ensuite mettre en production cette nouvelle version en modifiant la cible de votre domaine depuis votre interface client.

d) Sauvegardez le site et vos bases de données hackés en local sur votre PC (il pourra toujours vous être utile pour récupérer vos thèmes personnalisés ou vos bibliothèques d’images).

e) Changez vos mots de passe en respectant les règles suivantes :
- longueur minimale de 8 caractères,
- 1 ou plusieurs caractères spéciaux,
- 1 ou plusieurs chiffres,
- mixez minuscules et majuscules.

(N’oubliez pas qu’il va vous falloir vous en souvenir, optez pour un moyen mémo-technique).

3°) Que faire quand tout se passe mal ?

Garder son calme C’est primordial.

Il se peut que rien ne se passe bien lors de votre mise à jour, nous l’avons vécu lors du passage de wordpress 2.5 à la version 2.6.0

Si les mises à jours sont majeures ce risque est une quasi-certitude. Changement de format de la base de données, perte d’éléments graphiques, plugins utilisés non compatibles avec la nouvelle version, modifications majeures dans le fonctionnement du CMS, perte du design etc…

Le pire étant lorsque la nouvelle version ne corrige pas la faille, ce qui était le cas de la version 2.6.0 de Wordpress, même chose en 2.6.1, pour arriver à une correction en version 2.6.2.

Il n’y a alors pas de solution miracle, du temps vous sera nécessaire pour que votre site soit à nouveau totalement fonctionnel.

Edit du 16/09/2008 : Misère, la version 2.6.2 ne corrige pas le bug