Flux RSS25 10 2007 | Utiliser un CMS, oui mais…
Certains passages de cette news sont ironiques ou humoristiques, merci de les considérer comme tels.
De nombreux sites sont maintenant développés sur la base de CMS (Content Management System) tel que Joomla!, PhpNuke etc…Ces derniers permettent de disposer d’un site personnalisable sans avoir à investir du temps et de l’argent dans des développements lourds. Mais la situation n’est pas idyllique, loin de là. Ne nous leurrons pas, nous avons tous tendance à appliquer le précepte « Tant que cela marche, je ne touche plus », certes, mais Internet n’est pas figé et certaines personnes disposent du temps nécessaire pour chercher à nuire gratuitement.
Prenons l’exemple de Joomla!, script extrêmement populaire et déployé par nombre de webagencies ou de particuliers, ce CMS est extrêmement modulaire et couvre donc une multitude de besoins. Il est développé par une communauté nombreuse et dynamique mais il souffre d’un mal propre à son mode de développement et à sa popularité. Les sources de ce CMS sont libres, elles sont donc analysées et fouillées en permanence par des hackers et des crackers. Et bien entendu ces derniers découvrent et exploitent régulièrement des failles de sécurité. L’exploitation d’une faille peut avoir plusieurs conséquences :
1er cas :
La moins répandue, contrairement à une idée reçue, est le défaçage. Un beau matin vous vous connectez à votre site, ce dernier n’affiche plus le descriptif de votre société mais un joyeux :
« Hacked By ToTo, i’m the king of the world » ou un tract politique contre la guerre en Irak ou l’impérialisme américain, blabla…
Vous n’avez plus qu’à effacer le contenu de votre compte ftp, à réinstaller votre site avec les dernières versions du script et à changer vos mots de passe.J’insiste sur la réinstallation et non pas une restauration de sauvegardes. En effet, à ma connaissance, une sauvegarde n’a jamais corrigé une faille de sécurité dans un CMS.
2ème cas :
Tant qu’à nuire autant ajouter un peu de perversité à l’action. Votre CMS contient une faille, c’est dommage à plus forte raison puisque vous ne le savez pas (vous l’auriez comblée sinon). Sachez qu’il est alors possible d’utiliser votre compte pour des actions multiples et variées :
- L’upload de fichiers vidéos ou de mp3 pour qu’ils puissent être partagés entre le plus grand nombre de personnes malveillantes. Si c’est pas sympa de penser aux petits collègues ?
- L’implantation d’un vers qui aura pour mission de scanner le net pour trouver d’autres CMS non mis à jour et de préparer une attaque par Deny Of Service contre des serveurs des méchants impérialistes américains déjà cités.
Et là , cela commence à nous gêner pour diverses raisons :
- en mutualisé, cela à un impact direct sur la qualité d’affichage des sites hébergés sur la même infrastructure : lorsque 90% de la puissance d’un cluster est utilisée pour scanner le net, elle ne sert pas à générer des pages Php,
- suspendre un site ne nous fait jamais plaisir, pas plus qu’au client concerné,
- c’est tout de même dommage que vous ayez des problèmes avec la justice à cause d’une simple faille ? Ah oui, le compte vous appartient vous êtes donc pénalement responsable de son utilisation, c’est tout à fait logique. Sachez qu’en général ce type de problème se traite directement entre ISP pour plus de rapidité.
Cependant la personne morale ou physique ciblée par l’attaque peut légalement se retourner contre vous, un gestionnaire qui voit son serveur plier sous un flood fait rarement preuve de compréhension ou de tolérance. Nous ne l’avons jamais fait, mais Celeonet est tout à fait en droit de se retourner légalement contre vous pour détournement de l’utilisation d’un système informatique. Vous avez de la chance d’être notre client, nous savons que ce n’est pas volontaire 
« En général », ne veut pas dire systématiquement, je ne garde pas un excellent souvenir de mon entretien d’août 2005 avec les représentants d’un service de l’état (qui n’aime pas la publicité) concernant un site sous Joomla! qui présentait une faille sur l’upload de fichiers. Je vous rassure son propriétaire n’est pas en prison mais je ne pense pas qu’il garde un souvenir ému de cette affaire.
Un article bien long pour arriver aux conclusions suivantes si vous utilisez un CMS :
1) Vérifiez régulièrement qu’aucune nouvelle version de votre CMS n’a été publiée, si tel n’est pas le cas, mettez votre CMS à jour.
2) Même punition pour les modules tiers, vérifiez qu’aucune alerte de sécurité n’est publiée sur le site de l’équipe de développement, si tel n’est pas le cas, les mettre à jour.
3) Vous avez fait développer votre site par une société tierce, vous ne vous êtes jamais posé de questions sur les mises à jours (c’est mal !), peut-être est-il temps de vous renseigner sur la possibilité d’obtenir un contrat de maintenance auprès de votre prestataire ?
4) Vous avez mis en place un CMS sur votre espace Celeonet et franchement tout ça est assez obscur pour vous. Il est temps de marcher vers la lumière et de consulter les forums de l’éditeur de votre CMS.
Questions / réponses fréquentes :
C’est trop tard mon site est hacké ! (Vous n’auriez pas pu publier cette note hier, non ? Damned !)
Il ne vous reste plus qu’à identifier la faille et à la corriger, n’hésitez pas à mettre à jour le CMS, ses modules etc… Remettre une sauvegarde ne sert à rien, la faille serait à nouveau exploitée.
Comment savoir que mon site est hacké et exécute des routines perl ?
Idéalement, il faudrait que vous connaissiez le nom, la taille, la date de mise à jour de tous les fichiers de votre Ftp et que chaque jour vous effectuiez une vérification afin de vérifier que rien n’a été modifié Bon, dans les faits vous recevrez un mail de Yann ou de Mickael.
Dans le cas de suspension de sites voilà les questions que nous pose en général le client :
Mon site a été suspendu ou ma fonction mail() a été suspendue, j’en ai été informé par Yannick, Mickael ou Yann (au choix) [...] que puis je faire ?
C’est très simple, tout est résumé dans cet article.
Quelles sont les preuves de ce que vous avancez ?
Les comptes clients sont liés à un compte UNIX, en cas d’exécution d’une routine Perl le nom du compte y est associé. De même les mails générés par la fonction mail() sont tracés, le compte expéditeur est donc identifiable sans ambiguïté. Depuis peu, nous joignons une copie d’écran dans nos mails afin qu’aucune suspension arbitraire ne puisse pas être suspectée.
Aparté : Je ne vois pas quel serait notre intérêt de suspendre au hasard un compte client mais à priori ceci ne coule pas de source pour tout le monde.
J’ai identifié et corrigé la faille, comment remettre mon site en ligne ?
Privilégiez l’utilisation de l’interface de support pour décrire le problème et la manière dont vous l’avez corrigé, dans les plus brefs délais l’un de nos techniciens rétablira votre site.
Il est impératif que mon site soit en ligne, je ne veux/peux pas corriger cette faille dans l’immédiat.
Il est clair que nous ne laisserons pas un site en ligne si celui gêne l’affichage d’autres sites mutualisés, optez pour un serveur virtuel ou dédié. L’impact d’une exploitation se limitera alors à vos sites, attention ceci ne peut être qu’une solution temporaire dans l’attente d’une correction rapide.
C’est honteux, je change d’hébergeur !!!! (en général en majuscule et avec une crispation sur certains caractères spéciaux).
Mon préféré Il aurait été préférable d’identifier et de corriger la faille de votre CMS, mais ceci règle au moins le problème à notre niveau si ce n’est au vôtre.
Dans le cas d’une suspension, il est certain que vous éprouvez rarement une grande joie en recevant le mail de notification mais il est intéressant de garder à l’esprit en rédigeant votre mail que :
- les menaces, insultes etc… ne sont pas des arguments qui seront pris en compte pour le rétablissement de votre site,
- qu’il est nécessaire de décrire la correction apportée et qu’elle soit crédible pour que le site soit rétablit,
- que vous êtes le webmaster de vos sites et que vous en assumez toute la responsabilité, cela implique qu’en aucun cas nous ne procéderons à des recherches sur votre compte pour identifier la faille et encore moins la corriger,
- qu’il faut privilégier l’utilisation du panel de support, un ingénieur ou un technicien travaille rarement 24h/24, 7j/7,
- que le caractère répétitif des suspensions d’un même compte entraineront une analyse de plus en plus poussée des corrections apportées.
A titre informatif 3 comptes sur 5334 existants ont été suspendus en octobre pour ce type de problème. Ce sont les réponses des clients concernés qui ont suscité la rédaction de cette news.
By Kynerion, 25 octobre 2007 @ 17:31
Si je ne m’abuse (et je ne m’abuse pas), bon nombre de scripts proposés depuis l’espace membre sont complètement dépassés, qu’il s’agisse de CMS (SPIP, Xoops), de blogs (DotClear, Nucleus, TextPattern), ou de forums (Phpbb et PunBB). N’est-il pas dangereux de permettre l’installation « à la volée » de scripts non mis à jour donc contenant des failles?
>> Vous ne vous abusez pas, sur tous ces scripts ceux posant des problèmes de sécurité sont mis à jour régulièrement. Les autres présentent des améliorations de développement mais pas de faille de sécurité. Nous n’avons pas encore planifié la refonte de l’installeur de scripts mais nous y pensons très sérieusement, ce dernier présente l’inconvénient majeur de ne pas pouvoir mettre à jour les CMS dont la structure de la base de données a subi une modification lors de l’upgrade.
By harcher81, 25 octobre 2007 @ 18:58
Intéressant comme billet sur votre blog, je trouve cela très bien de votre part que vous informez les utilisateurs sur les risques de l’utilisateur de CMS. Mais bon, même une CMS mis à jour peut être hacker d’une manière ou l’autre. (en autre avec des mots de passes de basse sécuriter (comme des passes de 5caractères))
>> Ou un mot de passe identique au login
Ne pas oblier que même les sites n’utilisant pas de CMS peut être piraté, quoique cela soit beaucoup plus rare, puisqu’il faut utilisé une faille, mais comme la source n’est pas disponible cela rend le travail plus dure.
By David Anqeaume, 25 octobre 2007 @ 19:26
La problématiques des MAJ des CMS, cela fait deux bonnes années que j’y travaille, pourquoi, tout simplement, parce que la majorité des clients refusent de prendre un contrat de maintenance (c’est trop cher, bof, le site fonctionne très bien comme cela, il n’y a aucun intérêt, quoi les mises à jours ne sont pas comprises dans l’hébergement??…)
Et puis, n’ayant que peux d’envie de me pastiller les MAJ sur tous les CMS installés pour mes clients, j’ai opté pour le dév d’un CMS « multi-sites », certes, il a probablement des « failles » (et même très certainement), mais il n’est pas « opensources », donc ces dernières sont plus difficilement accessibles aux scripts-kiddies (les abr**tis qui n’y connaissent rien, et qui se font passer pour de grands hackeurs grà¢ces aux outils tout fait).
L’installation est unique pour tous mes clients, et dès que j’effectue une MAJ, elle est effective pour tous mes clients.
Actuellement, on me demande d’installer cet outil sur des serveurs différents, je travaille donc sur une autre solution : un outil de MAJ automatique. Je sais très bien que les clients ne feront pas eux-même leur mise à jour dans la plupart des cas.
>> Nous suivons la même voie concernant l’installeur de scripts Celeo.
Tiens au passage, quelqu’un ne connais pas un bon truc pour crypter le code, histoire de le rendre encore plus « difficilement » piratable?
>> Zend encoder, mais il nécessite que le « decodeur » soit installé sur le serveur web.
By Jefekoi, 25 octobre 2007 @ 20:19
Bonjour,
C’est bien tout ça, moi j’utilise Joomla et lorsque Celeonet m’indique « une mise à jour a été efectuée dans le script « Joomla » , alors j’en fait de même.
Idem pour les forum PhPBB
Celeonet, il serait bien de connaitre les sites des personnes hebergé chez vous, et pourquoi pas faire un Top Site Celeonet
@+
Cordialement
>> L’idéal serait que la mise à jour se fasse seule, en mode piloté si le webmaster le souhaite.. A creuser..
By Jefekoi, 25 octobre 2007 @ 21:26
Oui ca aussi , il faut regarder pour Joomla si il y a une mise à jour à faire via l’admin il y a un lien pour verifier, c’est pas vraiment compliquer ou alors via l’admin de PhpBB c’est idem …
By François NAUTRE, 26 octobre 2007 @ 1:07
Excellent article, bravo et merci.
Simplement un peu énervé par les mentalités « open source => ça craint niveau sécurité »…
1) Open Source (du moins libre) => beaucoup de monde qui a les yeux sur le code, donc bien sûr les hackers, toussa… mais surtout une grande communauté pour détecter les failles __et les corriger rapidement__
2) Les scripts « propriétaires » obscurs, comme des forums commerciaux en PHP par exemple, installés sur des comptes d’hébergement, ne sont pas explicitement open source, mais on peut quand-même récupérer les sources sur le compte, et donc les étudier.
Personnellement, je fais plus facilement confiance à un système dont la sécurité repose sur un code ouvert avec un grand nombre de relecteurs, qu’à un système dont la sécurité repose sur le caractère « boite noire » du code, c’est-à -dire sur le fait que personne ne sait vraiment « comment ça fonctionne dedans »
Le problème est similaire à celui des systèmes d’exploitation…
By David Anseaume, 26 octobre 2007 @ 11:15
Moi, j’ai plutà´t tendance à être agacé par les pro-opensources qui ont souvent des oeillères et qui ne voient ce qu’ils ne veulent voir. (surtout que je me sent un peu attaqué par tes propos vu que je suis le seul à parler de solution propriétaire).
Le problème évoqué ici est surtout à propos de mises à jours non effectuées par les utilisateurs, du coup que le système soit opensources ou pas, le problème reste le même.
Les outils opensources ne proposent pas de vrai système de mise à jour automatique et pour cause, la version installé par un utilisateur lambda est souvent une version « customisée » et toute mise à jour automatique risque de mettre en péril le fonctionnement du site.
La solution pour laquelle j’ai opté : c’est un outil développé par moi-même, mais donc les clients finaux n’ont pas accès au FTP, la seule personne qui a accès à ce dernier (hormis l’hébergeur, mais là je fais confiance à l’équipe de Céléonet) c’est moi. Le code n’est donc pas diffusé, sur un produit non répandu.
Sans accès au code, la découverte des failles est plus difficiles et surtout représente que peu d’intérêts pour un hacker (il ne peux s’en servir à grande échelle).
Bien sûr cela ne m’empêche pas de faire la chasse aux bugs et aux failles de sécurité, je continue chaque jours à travailler sur cet outil pour l’améliorer et faire en sorte qu’il soit le plus fiable possible, mais en ayant fait un outil multisites (c’est certes pas aussi customisable qu’on le voudrait, mais cela convient à la majorité de mes clients), les mises à jours sont directement appliquées à tous les sites de mes clients.
Certains cms existants proposent bien des fonctionnalités d’alertes de mise à jour, mais la majeure partie des utilisateurs n’en ont cure, ou ne savent pas les installer, et ils ont rarement envie pour payer une presta de mise à jour, alors que pour eux tout semble fonctionner, le fameux précepte “Tant que cela marche, je ne touche plusâ€
Maintenant quand à l’argument :
1) Open Source (du moins libre) => beaucoup de monde qui a les yeux sur le code, donc bien sûr les hackers, toussa… mais surtout une grande communauté pour détecter les failles __et les corriger rapidement__
Nous ne leurrons pas, la majorité des membres des communautés ces plus pour :
1. Utiliser ce qui à été développé par d’autres (la communauté est certes souvent très grande, mais il y en a beaucoup qui ne font que se servir sans comprendre comment cela fonctionne
2. Développer des modules / plugins, il y a qu’a voir par exemple la quantité incroyable de modules qu’il y a pour Oscommerce (dont de nombreux redondants). Assez peu de communautés mettent en place un système d’officialisations de module (qui garantirait une plus grande compatibilité entre chaque modules)
Il reste quand même après cela quelques membre de la communauté qui vont traquer les failles et les corriger, mais ceux la ne sont pas en général aussi nombreux que tu sembles le penser.
En conclusion, les deux solutions ont leurs avantages et leur inconvénients, la solution miracle n’existe pas.
By RV, 29 octobre 2007 @ 8:52
Bonjour,
Perso je suis membre de l’equipe de dev de GuppY un CMS Open-Source. Mon sentiment sur cela est partage mais je vais essayer de le faire passer ici.
Tout CMS peut avoir des failles (on en a en moyenne une pas ans chez GuppY) elles sont corrigées, nous avertissons, envoyons des newsletter pour avertit les utilisateurs, ecrivons des nouvelles, …
Cetains utilisateurs, ont peur de leur ordinateur, et du changement. et malgré les avertissement ne font rien, et certains découvrent aujourd’hui que leur site set pour du phishing, ou autre spam, mais ne sont pas étonnés d’utiliser une version d’un produit qui à 2 ans. Même microsoft sort régulièrement des patchs, Les distributions linux aussi s’améliorent et parfois comblent des failles.
Nous il nous manque une SSII ou SSLL qui ferait du service autour de GuppY pour orienter les perdus vers eux pour la maintenance, car pour faire de l’assistance personnalisée il faut être à temps plein sur le produit, ce qui est impossible pour une equipe de dev benevole.
Je suis donc plutà´t d’accord avec l’equipe.
Celeonet heberge même certains sites officiels de GuppY donc mis à jours correctement sans soucis !!
By mailou, 9 novembre 2007 @ 20:48
Bonjour,
Par hasard je viens de lire cet article, trés intéressant et à méditer, j’utilise spip comme cms et je n’ai pas l’impression de me trouver dans ce cas et pourtant j’ai plusieurs sites de créé pour des associations.
By REDSKIN, 14 novembre 2007 @ 16:36
Depuis l’ouverture du blog , je suis ce qui s’y ecrit
EH NON ! Le client n’est pas responsable….
>> Il serait bon de ne pas lire les articles en diagonal avant de poster un commentaire
sauf du contenu de son site web.
Chere CELEONET TEAM je vous aime bien (la preuve j’ai laissé pas mal de mes clients chez vous) mais vous devez fournir la sécurité necessaires de vos serveurs.
Or que dit un scan secu.sur les votres : DES FAILLES DE PARTOUT ! des mises à jours jamais faites……etc…et j’en passe.
mais bon personne n’est parfait. et le moins que vous puissiez faire joomla ou pas joomla…c’est une disponibilté et une sécurité totale de vos serveurs..car contrairement à ce que vous dites , nous : nous pouvons prouver que la faille (quand elle existe vient de chez vous) alors soyez indulgents et restez celeonet qu’on a connu à ses débuts : réactifs et à la pointe
>> Lorsqu’un upload via une faille d’un CMS est effectuée sur un site pour y exécuter des scripts malicieux je pense que nous ne pouvons pas y faire grand chose (à part sensibiliser nos clients par ce type d’articles par exemple). Si nous parlons de serveurs et d’upgrade Php ou Apache je crois qu’il va falloir creuser un peu plus le sujet avant de balancer des énormités dans les commentaires.
Une nouvelle version de Php ou d’Apache n’a pas forcément pour objet de combler une faille, il peut s’agir de corriger un bug dans une fonction ou le fonctionnement du service. Qui dit faille ne dit pas exploitabilité distante et c’est bien le fait de pouvoir exploiter une faille à distance qui nous intéresse. Il ne faut pas oublier non plus que Celeo propose un service d’hébergement et que nous ne pouvons pas nous comporter en « cowboys » du net par respect pour nos clients. Nous pourrions interdire register_globals à On par exemple ? Ou les fonctions system(), exec() etc ? Combien de sites ne s’en remettraient pas ? Nous préférons opter pour des solutions « intelligentes » comme la possibilité de personnaliser son php.ini qui est en version secure avant la personnalisation mais qui permet une certaine souplesse pour les webmasters dont les sites ont besoins de paramètres particuliers pour fonctionner.
Le seul point de notre infrastructure qui mérite une modification profonde est le cluster 1, ce dernier est bridé sur certains points afin, justement, d’assurer la sécurité des sites qu’il contient. Ce dernier sera mis à nos standards matériels et logiciels avant la fin de l’année.
By David Anseaume, 18 novembre 2007 @ 14:05
Arf, il y en a qui doutent de rien.
C’est comme si tu disais que tu n’avais pas à faire l’entretien de ta voiture pour rouler en toute sécurité, et que c’est à la DDE de faire en sorte que les routes soient plus sure.
Il est inadmissible de rendre responsable l’hébergeur quand c’est l’applicatif que l’on utilise qui est faillible.
By BLANCHON Vincent, 28 décembre 2007 @ 1:08
J’ai toujours détesté les CMS et ça me rassure dans l’idée que je fais bien de ne jamais en utilisé.
mais ils ont l’air très mécontents …
Seulement 3 comptes sur 5000 ça fait pas beaucoup de clients mécontents
>> Nous ne parlons pas de clients mécontents mais de comptes hackés et de la réaction que suscite les éventuelles suspensions de compte.
bah faut faire attention sur l’utilisation des CMS, on est content de trouver de l’Open Source mais c’est pas dit que c’est sans faille.
Ca fait plaisir de lire ce genre d’article quand on entend des personnes dire « Pourquoi tu te fais chier à faire un site alors qu’un CMS te facilite le travail ? » J’aurais une meilleure réponse maintenant lol
By rezki, 6 janvier 2008 @ 1:24
Oui, un top sites des CMS sur Celeonet, je vous assure que ce serait bien.
>> Je ne suis pas sûr d’avoir compris votre commentaire. Pouvez-vous développer ?
By FunZZ, 12 janvier 2008 @ 22:28
Je ne suis pas chez Celeo mais je dois dire que mon hébergeur a tendance à brider pas mal de choses pour sécuriser leurs serveurs.
Cela devient relativement pénible lorsqu’ on en a besoin.
Communiquer sur le sujet est plus intelligent je pense.
Mais en mutu ça n’est pas évident à gérer…