déc 30

Allez, fin d’année, on se fait quand même un post pour relater deux évènements non négligeables en matière de sécurité, à savoir deux failles de sécurité. Il en sort régulièrement, sur tout un tas d’applications, alors je ne cite que ces deux là mais beaucoup d’autres mériterai le droit de citation également.

Mes camarades de NBS System ont repéré une faille de D.O.S sur Magento qui est en cour de traitement chez Varien et qui ne sera donc rendu publique que lorsqu’elle sera patchée. Nous allons ici nous intéresser à Os commerce et Memcached.

Faille OS-commerce

Pour ceux qui tournent encore en OS-commerce, Milworm reporte une méchante faille de sécurité sur le célèbre framework. L’auteur (Flyh4t) propose un exploit effectif sur les version 2.2 RC2a au moins. Il est probable que d’autres versions soient vulnérables. Ca date du 31/08 mais bon, vu la vitesse à laquelle se patch le parc Français quand il y a une vulnérabilité… (cf la vulnérabilité sur le DNS de Kaminsky ou on a encore 8% du parc en non patché). Plus d’info ici.

Faille Memcached

On continue en musique avec un bon gros trou de sécurité qui fait mal, sur Memcached. Alors là, c’est plus critique car nombreuses, très nombreuses, sont les plateformes qui utilisent Memcached, sur Magento comme ailleurs, ce système de cache est populaire.

Et pan le memcached :  http://www.securityfocus.com/bid/35989

C’est goutu, frais, long en bouche et fruité, mais non ce n’est pas un bourgogne, c’est memcached qui a un bon overflow… Wahouuu le pire du pire, l’overflow et pas qu’un seul. La faille date du 7/08 à l’origine mais elle a été mise en jour le 14/12 pour être beaucoup plus générique.

Ça ne touche cependant « officiellement » que les distribution Linux suivantes (à ce jour) : les suze, redhat, parus, mandrake et danga. En général, un overflow dans un code en C, ce n’est pas fondamentalement lié à la distribution mais plus au code que la distribution a compilé pour son usage. Cela signifie globalement que le code source de memcached est susceptible de contenir des overflows et donc qu’avoir son propre système au dessus pour protéger votre infrastructure, ca ne fera pas de mal.

Les personnes sérieuses en infogérance installent GRsec & Pax quand ils mettent des serveurs Linux en visibilité sur Internet, notamment parceque PHP contient pas mal d’overflow et que tout démon est susceptible d’en connaitre, comme une fois de plus le montre cette faille de Memcached.

Grsecurity, l’anti Overflow

Je ne serai donc trop vous recommander d’utiliser GRsec sur vos environnement de production puisque c’est la seule façon de se protéger à 99% contre les heap & stack overflow, off by one et autres « boundary check errors ».

Rappelons que quelqu’un qui réussit une attaque par overflow va prendre le contrôle de la zone d’exécution  du programme ainsi que ses droits pour ouvrir un shell à distance. Une fois cela fait, même si le démon tournait en www-user ou avec un autre utilisateur non privilégié, l’escalade vers le compte root prend 90% du temps moins de 5 minutes. Les overflows sont donc l’une des plus grande menace possible sur un système si ce n’est la plus grande puisqu’ils mènent quasi tout le temps à une compromission totale du serveur.

Pour ceux qui découvrent GRsec : vous pouvez voir un (très) vieux howto que j’avais écris il y a 5 ans ici mais qui vous expliquera déjà au moins la base. Sinon le site de Grsecurity.net vous donnera de l’info aussi.

Sincèrement, exposer un serveur linux sur le net sans le protéger contre les overflows c’est un peu comme aller se faire une partie échangiste « thaïlando-congolaise » sans capote, disons qu’il existe un risque…

écrit par Philippe Humeau \\ tags: , ,

déc 20

Javascript et PHP sont-ils des sources de ralentissements ?


Je vais me faire des amis avec un titre comme celui-là :)

Maintenant, au-delà de la provoque, menons une analyse objective.

Nous avons, de nos jours, (au moins) deux gros goulots d’étranglement lorsque nous nous adressons à un site Web :

  • Javascript du coté du client
  • PHP du coté du serveur.

Analyse…

Parlons de Javascript…

En général, je m’intéresse plus aux performances des serveurs que des clients au sens « navigateurs ». En réalité, la performance des clients est en générale très liée à celle des serveurs pour être plus précis. Mais le serveur ne peux pas toujours tout.

Notamment les browsers encaissent plus ou moins bien le Javascript et surtout beaucoup de Javascript.

Opera, Chrome, Firefox, Internet Explorer et leurs copains ont une tendance très nette à réagir différemment (je n’apprends rien aux développeurs Web) et surtout à réagir plus ou moins bien et plus ou moins vite en interprétation de Javascript. De plus, ces différences se cumulent avec des comportements très différents d’un browser à l’autre, notamment le nombre de requêtes concurrentes (nombres d’éléments de la page chargé en parallèle).

Tous les sites récents utilisent énormément de Javascript et ont donc une belle tendance à charger la mule, surtout quand on a plusieurs onglets d’ouverts sur plusieurs sites, on a tout de suite des machine virtuelle javascript au sein des navigateurs qui se mettent à grossir.

Ok, so what ? Qu’est ce que j’y peux me réponde les développeurs…

Eh bien beaucoup de choses en fait. Déjà, un framework c’est bien mais ca n’empêche pas de réfléchir. Faire confiance aveuglément sans regarder le dessous des cartes, c’est ce qui mène au gâchis de ressources.

Optimiser ces points (comme d’autres), c’est ce que j’appelle la « culture atari / amiga ». En gros, à l’époque, les développeurs avaient des machines identiques, des machines avec des limites et on pensait à tirer le meilleur partie du Hardware, on optimisait son programme à la goutte prêt, on passait au plus proche du matériel pour faire des choses que les concepteurs de ces machines n’avaient même pas imaginé.

De nos jours, on prend un framework, on instancie un objet et hop, derrière ca pédale mais c’est plus mon problème… Revenons à Javascript.

Des soucis de tableaux !

Il y a de nombreuses sources de maux dans Javascript, langage qui devient incontournable sur le Web depuis 5 ans. Mais lorsque les sites traitent de sujets plus complexes ou offres de nouveaux raffinement, ce qui était « une brique parmi d’autres » devient plus sensible.

Commençons par un soucis simple de Javascript : les tableaux.

Allouer un tableau en JS déclenche des mécanismes très différents d’un malloc en C. Allons y ! Sous IE, la logique de traitement est la suivante :

var my_array = new Array();

for (i = 0; i < 100000; i ++)

my_array[i] = i;

1°) Je crée un objet array qui est une table de hashage.

2°) Comme une table de hashage est un objet générique, je lui crée un attribue length (taille) et on le met à 0

3°) La boucle fait, pour chaque valeur de i

  • Une conversion de i en string (chaine de caractère, en gros i= « i »)
  • Ajoute un clef de hash pour chaque couple « chaine i », i
  • Réajuste la valeur de length

OMG. Donc, rien que pour assigner une valeur au tableau, on a fait 3 opérations (dont deux totalement inutile si on a codé un jour en C).

Pour compléter le tableau, les allocations réelles de mémoire ne sont pas continues car les tableaux sont gérés sous la forme de « sparse » array.

C’est avantageux en terme d’usage réel de la RAM car les blocks vides ne sont pas alloués, par contre les allocations ne sont pas contigüe. Du coup, les accès à ces blocks de données ne se font pas à la suite et n’utilise pas certains mécanismes de prédiction des processeurs ou certains caches des OS. De plus les entrées du tableau ne sont pas indexées.

Bon, maintenant, on a tout pour faire une usine à gaz de compétition !

Pour résoudre ce premier point, sous IE 8, le « sparse array » est détecté comme étant dense ou non. En gros il est très peuplé ou non. Pour que l’heuristique de IE8 comprenne que c’est un « dense sparse array », il faut que ce tableau soit d’une taille explicite (en théorie mais un autre blog ne dénote pas de différence de perfs sur ce point) par contre, il faut en initialiser tous les éléments. Le défaut c’est que toute la RAM est allouée et le coté « sparse » disparait.

Sur un gros PC ce n’est pas si dramatique mais sur un téléphone portable, ouch… Du coup, initialiser l’ensemble du tableau n’est pas toujours la bonne option. Un comportement optimal serait de détecter le navigateur et de lui proposer un Javascript optimisé pour le ratio Rapidité, consommation de CPU & RAM, logique de traitement. Une sorte de librairie optimisée de gestion des tableaux, dépendante de la plateforme qui l’exécute.

En termes d’impacts c’est non négligeable !

Quelques très bon liens pour ceux que ca intéresse. Le premier blog a d’ailleurs de très bons papiers d’une manière générale !

http://www.outofwhatbox.com/blog/2009/11/javascript-array-performance-initialize-to-optimize/

http://www.outofwhatbox.com/blog/2009/12/javascript-array-performance-and-why-it-matters/

http://blogs.msdn.com/jscript/archive/2008/03/25/performance-optimization-of-arrays-part-i.aspx

PHP et les performances : plantons le décor


Revenons à nos serveurs ! Dans une infrastructure Magento, ce qui pompe dur au niveau des performances, c’est PHP et de très loin.

Il faut évidemment de la RAM pour accélérer les accès et traiter les données mais les appels PHP coutent très chers. Et c’est bien logique car le Web est coincé dans un incroyable paradoxe.

Les langages interprétés (comme PHP) sont très adaptés à certains traitements mais d’une manière générale, pour tous les traitements répétitifs ou massifs, on les évite.

L’idée c’est que dans la rapidité des langages, l’échelle est très claire :

Les compilés :

Les langages ASM/C et C++ sont compilés et (donc) très rapides. On décrit le code et cela se transforme en Opcode directement interprétables et optimisables par le processeur. Tous les caches deviennent super efficaces (L1/L2/L3 du processeur notamment) et le programme traite les données au fil de l’eau et au fil du temps. Le programme se charge en mémoire, il ne s’arrête que quand on lui demande et peut sommeiller le temps d’attendre son prochain traitement.

Assembleur : niveau processeur directement, très peu voir pas d’interprétation, vitesse maximale.

C : Le code produit par un compilateur C est très proche de l’assembleur et donc extrêmement rapide. Pour autant cela reste un langage relativement évolué, contrairement à l’assembleur on a pas à tout écrire de zéro, des librairies existent, des includes, du code un peu évolué d’une manière générale.

C++ : Un langage C évolué et Objet. On monte encore un peu dans les couches, on fait de l’objet et du fonctionnel, on en est plus à la douce barbarie redoutablement efficace de l’assembleur mais ca reste un code qui, une fois compilé, est redoutablement efficace.

Très peu souples en typage ou en gestion de la mémoire, ces trois langages compilés, pour ne citer qu’eux, sont extrêmement rapides !

La machines virtuelles :

Ce sont des programmes qui crée un environnement permettant d’exécuter d’autres programmes en leur sein. L’intérêt essentiel est de s’affranchir de la couche en dessous, en gros le programme devient portable partout. Si la VM existe pour l’environnement matériel cible, le programme tournera (presque) à l’identique sans rien redévelopper. L’inconvénient, comme toute forme de virtualisation, c’est que la VM consomme de la ressource pour créer cette couche d’abstraction, bilan ces langages ne sont pas toujours des foudres de guerre.

Java et autres JVM

Java est le plus connu des langages tournant dans une machine virtuelle, la JVM. C’est un bon langage, objet, évolué et indépendant du matériel mais il souffre de devoir être compilé tout en étant pas aussi rapide qu’un autre langage compilé.

Les « interprétés » :

Aïe. Perl, PHP et de nombreux copains à eux sont des langages dits « interprétés ». A chaque fois qu’il est lancé, le programme (test.php par exemple) est lu par un interpréteur externe (php par exemple), le fichier est parcouru, compilé à la volée quelque part, mais une fois finit, on repart de zéro. Le fichier programme à interpréter est donc lu à chaque fois et le programme qui le lit, l’interpréteur, est un programme qui est lui chargé à chaque exécution aussi.

PHP :

Un des plus célèbres. Zend au dessus est en fait composé de PHP objet évolué au sein d’un Framework, encore une couche d’abstraction. Donc si l’on compare avec nos précédents amis, Zend c’est le C++, Php le C sauf que tout cela est lu/chargé/parsé/interprété puis exécuté en continu. C’est un peu comme si on avait à se taper la compilation a chaque fois qu’on lance le programme… En fait l’image est très exacte puisque c’est quasiment exactement ce qui se passe. Bilan, les langages interprété c’est pratique, facile à maintenir et programmer, on s’affranchit de tous les aspects un peu rigoureux d’allocation mémoire ou de gestion des taches de bases mais le coût en terme de performances est énorme.

PS : Javascript est un langage de scripting interprété tournant dans une machine virtuelle (navigateur)… Tout pour gagner J

Vers un PHP compilé ?


Comme signalé plus haut, l’interprété c’est consommateur et pas adapté aux traitements récurrents. Maintenant si l’on considère une architecture d’hébergement Web, que se passe-t-il.

Admettons que le site soit en Magento, on a un framework de deuxième niveau, qui repose sur un framework de premier niveau (Zend) qui repose sur un langage interprété objet (PHP5) qui repose sur un interpréteur (Php) qui lui-même est compilé et s’adresse en assembleur au processeur.

Ajoutez un peu de virtualisation là-dessus et avant qu’une requête ne passe à travers tout ce maillage, vous avez perdu une quantité de puissance tout proprement hallucinante !

En soit, aucun reproche au fait d’utiliser PHP ou sa syntaxe, par contre, soyons clairs l’approche est juste complètement aberrante. En fait si on essayait de faire pire, le seul moyen, ca serait de faire tourner l’interpréteur php dans une JVM…

Et oui, ce n’est pas anodin mais bien dramatique. A chaque fichier PHP que vous chargez, l’interpréteur est lancé. A chaque fichier php de chargez, vous provoquez toute la cascade de compilation, d’accès disque, d’exécution. Quand un visiteur passe, il provoque donc des centaines de lancement du programme PHP qui va interpréter autant de fichiers… C’est une boucherie, une hémorragie de puissance pour finalement un problème très bête.

Le problème ce n’est pas Magento, Zend ou les fichiers PHP en soit. Sortons de la barbarie de l’assembleur, vive l’objet et tout et tout, on développe plus vite, on réutilise du code, on capitalise des librairies ! C’est l’avancement logique, l’avenir, donc ca va continuer à se développer. Par contre, pourquoi on ne compile pas tout cela ?

La charge CPU des serveurs serait juste divisée par un facteur 10 à vue de nez… C’est à ce point négligeable ? Plus clairement, sur un serveur, au lieu d’accueillir 20 000 personnes par jours par exemple, on en accueillerait 200 000. Avec le même serveur. L’approximation est un peu grossière mais pas outrancière non plus.

Le Web, qui par essence provoque des milliers de lecture et interprétation de fichier de programme, utilise un système d’interprétation, ce qui est la pire façon de faire, ce qui est le plus consommateur possible. Voici le paradoxe.

Si je me la faisais à la Yann Arthus-Bertrand, je redirais « alors pourquoi toi, homo sapiens sapiens, ne compile tu pas tes langages Web ?». Es-tu conscient des ressources gâchées par cette hérésie et de l’impact, de l’empreinte carbone, de cette approche incompréhensible ? Tu veux vraiment défoncer les puits de soleil ? Tu es un inconscient pathologique, un criminel notoire, un serial-gâcheur ? Ooops, je m’emporte… Yann (dont j’aime beaucoup le travail mais un peu moins la voix monocorde) n’irait pas jusque là !

« Pourquoi ne compile t’on pas ? », bon ok, j’arrête de faire mon YAB…

Je n’ai rien contre les développeurs, qui n’y peuvent pas grand-chose si ce n’est optimiser leur code (ca serait déjà un bon début pour certain ceci étant). Ce qui me froisse par contre, c’est que l’on a pas encore de solutions parfaitement mûres pour corriger ce point.

Des soucis assez complexes de conception sont au rendez-vous pour passer du PHP de l’état interprétable à l’état compilé. Mais ne vous y trompez pas, le Graal est au bout de la route.

Plusieurs initiatives sont en cour de développement par des gens talentueux que je ne peux qu’encourager dans cette voie : Roadsend et PHC (Php compiler mais qui paraît à l’arrêt) semblent être les leaders dans cette voie.

http://www.phpcompiler.org/

http://www.roadsend.com/home/index.php?pageID=compiler

L’autre approche possible serait un cache plus efficace, pas uniquement des opcodes comme APC mais bien des pages rendues, du résultat de l’interprétation PHP. C’est ce vers quoi se dirige Zend Server, c’est une bonne première transition mais le compilateur serait bien LA solution !

En conclusion


Je dirais que PHP et surtout le modèle interprété qui va avec et Javascript et surtout l’implémentation qui en ait faite des les navigateurs autant que dans le code de certaines pages Web, sont deux problèmes.

Ces deux axes de progression nous apporteraient un Web plus rapide, souple et agréable d’utilisation. Le réseau n’est plus réellement une limite, les processeurs sont suffisamment puissants alors deux cas sont possibles :

- Quelques personnes douées arrivent au bout de ces deux problèmes

- Tout le monde se contente de ce qu’on a, on enterre la logique d’optimisation de l’époque atari & amiga, on tue les phoques et la banquise en consommant inutilement des ressources informatiques précieuses. On compense par plus de puissance, plus de ressources consommées, plutôt que de mieux utiliser.

Un classique me direz-vous ?

écrit par Philippe Humeau \\ tags: , , , , , ,

déc 18

Bonjour à toutes & à tous,

Suite à notre réunion du CAB hier soir, voici un rapide compte rendu.

Uservoice & Roadmap de la version CE


Les retours par Uservoice vont être stoppés pour commencer la partie intégration des requêtes les plus fréquentes. Le uservoice sera surement réactivé plus tard mais l’équipe Varien a déjà largement assez de feedbacks pour bosser un an !

Release de la 1.4 en Community Edition


Varien continue sa restructuration interne et c’est la cause principale du retard de la version 1.4 Community Edition. Gabriel & moi avons été très directs pour dire à Varien que c’était une préoccupation majeure de la communauté ce retard mais Yoav nous a expliqué la raison de ce décalage qui est plutôt logique. Le principe c’est que la CE est le socle de la EE donc la majorité du tronc de la 1.6 en EE est ou sera présent dans la CE, notamment les optimisations de codes.

Mais pour des raisons de déménagement de l’équipe de Kiev, Misha et ses collaborateur ont été un peu ralentie dans leur travail. Yoav nous garantie une CE 1.4 finale pour la première semaine de janvier 2010 au plus tard.

Communauté, localisation, arrondis, docs/wiki


Ensuite la conversation à tourné sur les problématique d’arrondie des sommes et de frontaux / back office multilingues (par exemple français / allemand / italien en frontal et allemand en backoffice).

Koby Oz nous a lui parlé de l’effort qui va être fait par Varien pour montrer l’effort communautaire et promouvoir les outils de contribution, qui existe déjà, mais qui sont trop peu visibles. Apparemment, une section complète du site de Varien sera dédiée à ce point prochainement.

Un effort concernant la Doc et les traductions va être mené. Il se concentrera spécifiquement sur les aspects liés au Wiki pour « faire partager ce que vous avez tous dans la tête » à dit Koby aux CAB. Le savoir, les tips & tricks et toutes les formes de partages sont encouragé, Varien souhaite pousser ce Wiki qui « vivotte ».

Magento LE, Light Edition


Une des informations importantes également, c’est que Yoav confirme ce qu’il nous a dit lors de Bargento 3, il y aura une Magento LE, Light Edition. Le but est d’avoir un milieu de gamme entre la CE et la EE, qui soit à même de concurrencer tout autre produit de E-commerce sur ce segment de tarif. « More than the others for a better price ». Cette licence permettrait, peut être, la mutualisation, pour apporter Magento low cost au plus grand nombre et à des coûts très intéressants. Pas de date de release pour cette LE pour le moment puisque Varien continue se restructurer en interne mais une équipe dédiée y travaille déjà.

Koby & Yoav nous ont redit que l’important dans l’immédiat, c’était de permettre aux petites entreprises de passer à Magento puisque le produit à eu mauvaise presse à une époque sur ce segment (ce qui semble maintenant peu justifié vu les progrès de Magento en un an). Varien concentre donc ses efforts dans ce sens à tous les niveaux, optimisation du code, l’Academy pour fournir des développeurs, les fonctionnalités en constante augmentation de la CE et prochainement de la LE, etc…

Il y a eu quelques autres sujets mais je ne me souviens plus de tout et certaines personnes avaient un micro un peu déficient, je n’ai donc pas tout compris lors de leurs interventions.

écrit par Philippe Humeau \\ tags: , ,

déc 17

Bonjour à toutes & à tous,

Aujourd’hui, pas de grand article de 3 pages, juste quelques news  :

1°) Une Fan Page sur Facebook

Je vous annonce la création d’une Fan page de Bargento sur Facebook.
Vous pouvez retrouver votre évènementiel préféré sur Facebook à cette adresse.

2°) Deuxième news du jour : un module de gestion des conflits Magento Connect

Cette bonne idée nous vient de maisondulogiciel et s’appelle « Magento Extension Conflict ». Le but de cette extension est justement de vérifier si on part vers un Armaguédon en installant telle et telle extension ou si ca devrait bien se passer. D’après le site de l’éditeur :

« Extension Conflict est conçu pour aider les développeurs Magento à identifier les conflits entre les modules installés sur leur serveur.

Avec Extension Conflicts, les développeurs peuvent également soumettre le fichier config.xml d’une autre extension afin de vérifier qu’aucun conflit avec une autre extension ne se pose et ce, sans avoir à installer le nouveau module. »

Je dois bien avouer que nous ca nous a pas trop traumatisés mais je suppose que de nombreux développeurs vont apprécier la chose :) Rappelons en passant que ceux qui demandaient à corps et à cris une gestion de stocks dans Magento peuvent aussi jeter un œil sur le site du même éditeur qui s’est visiblement intéressé au problème. Attention cependant, la première extension est gratuite, la seconde (stock) est payante.

3°) CAB Meeting de Décembre 2009

Ce soir, on discute au CAB (Community Advisory Board). C’est l’endroit où les personnes impliquée dans la communauté Magento peuvent échanger des points de vu avec l’équipe Varien. On a Roy & Yoav qui viennent assez souvent nous rejoindre mais c’est Koby Oz le porte parole.

En France, Varien à 3 CAB : Gabriel Bouhatous, Fançois Ziserman et moi même Philippe Humeau. Si vous voulez que nous relayons un message, n’hésitez pas à nous en faire part.

Pour information, Gabriel & moi avons planifié de pousser une bonne gueulante sur la sortie ver CE 1.4.0.

On est en béta 1 depuis le 6 octobre 2009 alors que la version EE a déjà fait 2 évolutions. Comme on a défendu haut et fort que la EE avait sa place et n’était pas une menace pour la CE, on défendra ce soir la CE comme il se doit, l’éditeur doit y apporter le même soin, le même suivi, qu’à la EE.

Bien sûr, si on a un peu de news ce soir, je vous publie ca rapidement !

écrit par Philippe Humeau \\ tags: ,

déc 11

Un ennemi à part !


Le problème est, ma foi, assez simple :

En sécurité informatique, on sait de nos jours parer à la grande majorité des menaces. Si on se concentre sur la partie serveur et sur Linux, Grsex / Pax, un coup de hardening, un kernel statique et optimisé, du chroot et ma foi on est déjà pas mal…

Les démons comme apaches et Mysql, ainsi que les interprêteurs comme PHP ou Perl, sont protégés contre leurs ennemis intimes : les overflows. Les droits séparés, les arborescences protégées, les connexions filtrées, que peut on faire de plus ? Par exemple séparer le back office sur un autre vhost pour ajouter un htaccess afin de le protéger, auditer le site contre les vulnérabilités classiques, XSS, SQL injection etc…

Well… Que reste t’il, un ou deux mécanismes à protéger mais… Le D.D.O.S, c’est fatal.

Know your ennemy !


La D.D.O.S – Distributed Denial Of Services – c’est la grande frayeur de n’importe quel E-commerçant, de n’importe quel site gagnant de l’argent en ligne et surtout, de votre infogérant…

Un déni de service distribué consiste à envoyer des milliers, des dizaines de milliers, des centaines de milliers de requêtes simultanément. Si l’on limite la réflexion aux sites Web, il suffit, en général, de faire 10 à 50 000 connexions simultanées pour mettre à genou un serveur et/ou la connexion Internet des serveurs.

Ces innombrables connexions arrivent, en général, depuis des machines compromises, de partout dans le monde. Ces machines sont compromises par des vers, par exemple Confliker ou d’autres plus discrets, qui sommeillent dans des PC depuis des mois, à l’écoute des ordres. Ces machines, appelées Zombies, font partie de réseaux nommés Botnets.

Ensuite, c’est malheureusement d’une simplicité diabolique. Un script kiddy (ou même un vrai hacker) paye quelques poignées de dollars et loue tout simplement la puissance d’un botnet. Combien de machines, combien de temps, quelles commandes doit être lancée. Simple, terriblement efficace, imparable…

Les machines reçoivent les ordres et en quelques minutes, des centaines milliers de connexions pleuvent sur le site ciblé.

Comment éviter une D.D.O.S ?


Une D.D.O.S se base, pas essence, sur des machines compromises, la plupart du temps des bêtes PC de particuliers.

Evidemment, nous ne pouvons avoir une action sur ces machines directement. Les désinfecter à distance n’est pas possible, pas plus que cela ne serait autorisé du reste.

Ensuite, bloquer ces machines une par une dans un firewall est aussi inutile qu’impossible. Impossible à cause du volume, inutile car bloquer ces connexions n’empêchera pas le pirate d’en envoyer d’autres, d’en envoyer plus et de toute façon, si ce ne sont pas les serveurs qui craquent, ca sera la connexion Internet des serveurs.

Damned, we are done ?

Non. Plutôt que d’étudier le problème sous l’angle de ce qu’on ne peut pas faire, voyons plutôt ce que nos assaillants ne peuvent pas faire :

Il n’est pas possible pour le pirate de réellement patcher le noyau des machines Windows compromises. Si un ver se comportait de cette façon, il serait beaucoup moins efficace (capté par des anti virus) et beaucoup moins portable (selon les versions de Windows). Donc, les vers tournent en général au dessus, dans la couche logicielle. Résultat, ils sont obligés de faire ce que la couche du dessous demande…

Et c’est là que ce situe la faille de ces attaques, de ces vers. Si l’on arrive à forcer les machines à arrêter d’envoyer des paquets en utilisant une subtilité du protocole TCP, le driver de la carte réseau sera obligé d’agir et cet ensemble est lui directement au niveau noyau, donc prioritaire sur la couche logicielle :)

Voila un début solution semble t’il…

Tarpit : du goudron et des plumes !

Règle number one du Blog : plus c’est long, moins c’est lu… Je vais donc faire court et je ne vais pas non plus vous expliquer comment paramétrer un noyau linux et le compiler, de même pour le binaire iptables. Vous trouverez le noyau ici : ftp.kernel.org et pas mal de guide de survie en googlant.

Sinon j’en ai écris un il y a longtemps, mais ca devrait vous aider, ca se trouve ici. il y a des choses tout à fait dépassées, des choses inexactes dans les exemples de firewall mais je n’ai pas eu le temps de le corriger. Ceci étant, vous pouvez partir de là. vous aurez besoin de  recompiler aussi le binaire iptables en passant par la patch-o-matic, tout est expliqué ici.

Mais pourquoi Iptables et Tarpit sont nos amis ?

La règle TARPIT, et il existe d’autres moyens de faire cela évidemment, permet d’informer nos gentils PC zombies qu’ils sont priés d’attendre qu’on les recontacte avant de nous envoyer le prochain paquet réseau. Les machines Windows, comme la plupart des OS récents du reste, respecte le « window resizing ».

Quand on règle la fenêtre (window) de communication à une taille de zéro, la machine distante reste dans un état d’attente, jusqu’à ce que l’on remette une taille normale à la window TCP.

Mais que se passe t’il si l’on ne remet jamais la fenêtre à une taille normale ? Eh bien la machine reste en attente… Et c’est là que la solution se situe. La connexion se bloquera jusqu’à ce que l’OS fasse le ménage dans ses connexions inertes !

Ca peut prendre du temps… pas mal de temps en fait, quand bien même notre machine distante s’acharnerait en refaisant une connexion, à chaque nouvelle tentative, elle bloquera un peu plus sa propre « stack tcp », son propre système de gestion du réseau… Ca va prendre un peu de temps mais ca va bien ralentir l’attaque, d’autant plus que la plupart des machines ne réessayeront pas puisque la connexion n’est pas morte, elle est juste « en pause ».

Comment et à qui appliquer le Tarpit ?

Simplement en 1° scotchant la connexion attaquante 2° en dropant le paquet pour ne pas nous encombrer inutilement. Histoire de faire simple, on va se créer une règle qui fait ca en une fois.

iptables -N TARPIT_DROP
iptables -A TARPIT_DROP  -j TARPIT
iptables -A TARPIT_DROP  -j DROP

Ok mais si on fait un tarpit de tout le trafic entrant avec un iptables -I INPUT -P TARPIT_DROP ou la même chose en FORWARD, on va perdre tout le trafic entrant, y compris les vrais clients du site… C’est peut être un peu désagréable pour les personnes qui n’y sont pour rien.

Afin de trier le bon grain de l’ivraie, il va nous falloir être plus malin que les « bots », les zombies, qui nous attaquent. Il est possible de faire un peu de trie avec des IDS comme Snort par exemple ou sinon d’analyser les logs et les requêtes, ou encore même le rythme des connexions.

Quand on y réfléchit, il est assez simple de reconnaitre un bot car il fait toujours la même chose en général (par exemple un get /blabla.php) et/ou utilise une fréquence précise (par exemple toutes les 5 secondes).

Si l’on utilise un IDS, c’est lui qui pilotera les règles de firewalling (flex rules) directement quand il détecte un comportement anormal. Si l’on souhaite utiliser un parser de logs, il est très simple de lui donner la « pattern » de l’attaque (par exemple un get /blabla.php toutes les 5 secondes) et d’interdire toutes les machines utilisant cette pattern.

Si c’est une page spécifique qui est visée (blabla.php par exemple) il est aussi possible de détecter dans le contenu du paquet (sauf en https) le mot blabla et d’interdire, en fait de tarpiter les machines l’appelant. Certes, les personnes appelant réellement pour de bonnes raisons la page blabla vont être déçues, mais les autres vont être bloquées aussi. Si ca a lieu sur la homepage, cette méthode n’est pas applicable, mais sinon :

iptables -I INPUT -p tcp -s 0.0.0.0/0 –dport 80 -m string –string « blabla » –j TARPIT

Il nous reste d’autres possibilités, avec les mod geoip par exemple ou encore en tarpitant les connexions entrantes qui sont des réseaux similaires (49.230.xxx.xxx par exemple)

Il est possible de limiter en fonction du nombre de paquets et du type de paquets reçus par secondes. Iptables en fait est une usine à idées sans limite. Les attaques peuvent prendre plusieurs formes mais la réponse peut aussi être assez polymorphe à sa manière avec Iptables !

-m limit –limit 2/second –dport 80 –syn -j ACCEPT

Utiliser un mélange subtile des parameters limit et burst-limit peut permettre d’enrayer les flots de paquets réseau trop « soutenu ».

Mélanger subtilement –string pour identifier le contenu et –limit pour le rythme, –state pour l’état de la connexion et d’autres tests, cela peut aussi permettre des résultats intéressants en terme de détection :

iptables -I INPUT -p tcp –dport 80 –m string –string “blabla” –m limit –limit 1/6s –limit-burst 1 –m recent –name DDOSbot –set
iptables –I INPUT FORWARD -p tcp –dport 80 -m recent –name badguy –set -j TARPIT_DROP

iptables –I INPUT -m state –state NEW –m limit –limit 1/6s –limit-burst 1-j TARPIT_DROP

Là par contre, on a beaucoup limité les personnes qui sont tarpitées, en fait à celle faisant une nouvelle connexion plus souvent que toutes les 6 secondes ou si elles appellent la chaine blabla à la même fréquence. Encore une variante ?

iptables -I INPUT -m state –state NEW -m recent –update –seconds 20 –hitcount 4 -j DROP

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j RETURN
Le parametre “Syn cookie” dans le noyau permet aussi de s’assurer qu’un petit malin ne nous flood pas à coup de SYN uniquement car s’il ne donne pas suite à sa connexion, elle ne sera pas maintenue, c’est un élément de protection indispensable. Et si notre assaillant est très « vieux jeu » et votre réseau très vétuste, qu’il utilise un ping flood, iptables -A INPUT -p icmp -m limit --limit  1/s --limit-burst 1 -j ACCEPT, devrait limiter se velléités. 
Si vous vous passez d’un IDS, vous aurez à analyser vous-même l’attaque, sa méthode et sa forme afin de déterminer la méthode la plus adaptée pour y répondre.  
L’analyse est un point vital et Tarpit une réponse fatale. 

More fun with Tarpit ?

Bon soyons clairs, on peut aller plus loin dans le fun.

Par exemple une personne qui scanne les machines va utiliser un scanner qui va soit utiliser des séquences TCP connues (SYN scan, Xmas Scan etc..) ou même un enchainement de ports, linéaire (1,2,3 etc…), spécifique croissant (21,22,23,25,80 par exemple) ou aléatoire (443,22,53,80,21 par exemple).

Dans tous ces cas, on peut utiliser un démon comme knocked par exemple, un démon de port knocking, pour identifier une séquence de scan. Une fois qu’on l’a identifié, le port knocker est censé ouvrir la connexion pour la personne qui a fait la bonne séquence. Faisons l’inverse puisque c’est un pirate, interdisons lui l’accès et au passage tarpitons le un petit coup…

Le plus drôle c’est qu’on va maintenir son IP en Tarpit et donc provoquer une connexion bloquée par port scanné et là… assez rapidement… sa machine va sévèrement bloquer du coté réseau :)

Alors, au final, Tarpit, c’est fun non ? Il existe de nombreuses autres options que vous pourrez trouver dans le kernel ou dans la patch-o-matic, toutes peuvent donner lieu à des mélanges très utiles.

écrit par Philippe Humeau

déc 01

Problématique


Les grandes marques sont de plus en plus présentes sur Internet par l’entremise de leurs sites web marchands. Ces marques sont capables de générer des trafics colossaux sur une journée, tout particulièrement pendant des périodes particulières comme les soldes.

De plus, les grands rendez vous sont souvent les mêmes pour les sites de E-commerce ce qui fait que tous consomment beaucoup de ressources en même temps.

Les trois grands types de ressources consommées pendant ces pics de charge sont les suivants : réseau (bande passante), processeur, RAM.

Que faire lors de ces soldes, lors de ces pics et surtout pour ces grandes marques ?

Passer de 100 000 Visiteurs uniques par jour à 500 000 relève du possible pour ces grands compte. En contrepartie, passer de 3 serveurs frontaux à 15, juste pour des pics temporaires, semble couteux et peu pertinent dans le long terme, sans compter le gachis de ressources.

Le Cloud (computing)


Le cloud computing est une solution technique qui permet l’usage de ressources de type CPU / RAM, Bande passante « au compteur ». Vous payez ce que vous consommer. Il y a un coût rémanent pour l’hébergement de fichiers sur le Cloud mais il est très réduit.

Cette solution de payement à la ressource réellement consommée est donc un moyen très adapté de ne mettre en place des ressources que quand cela est nécessaire et de ne facturer que ce qui est consommer.

Plusieurs Cloud existent, Amazon S3, Rackspace etc…

Du simple C.D.N à l’infrastructure


Le C.D.N veut dire Content Distribution Network. En résumé, les données statiques, images, films, css, html simple peuvent vous être fournit depuis un lieu proche de vous plutôt que depuis l’autre coté de l’océan. Ceci améliore la rapidité de chargement mais également déleste les serveurs centraux en les allégeant du travail « idiot » de distribution de fichiers.

La première utilisation des Clouds a été ce CDN, les pionniers du décentralisé étant par exemple Akamaï. Mais de nos jours, les ténors comme Amazon ou Google ont rationalisé des infrastructures beaucoup plus vastes et complexes que ce qui avait été conçu jusque là. Ils ont mis en place des systèmes spécifiques, allant parfois même jusqu’à faire développer leur propre hardware.

Une fois la puissance rationalisée et déployable à loisir, il est devenu simple pour ces ténors de « revendre » leur capacité d’accueil. Nous sommes alors passé du simple CDN à de la capacité d’accueil réelle avec, notamment, l’ajout de systèmes de base de donnée.

E.T.C (*) : Extend to Cloud, le cloud pour Magento


Chez NBS System, on a dû très tôt trouver des solutions à ce problème. Les grands comptes étant de plus en plus nombreux à basculer sous Magento et il était indispensable de proposer une solution rationnelle pour les accueillir.

Les éléments étant réunis, le projet E.T.C : Extend To Cloud était lancé. Une discussion avec Yoav Kutner, pas mal de test et de R&D et voici E.T.C.

Le concept est, dans le principe, simple. Au moment où un site monte en volume de trafic, on instancie des parcelles du cloud pour accueillir une partie du trafic qui « déborde » de la capacité d’accueil physique, réelle. Si l’infrastructure physique permet d’accueillir 100 000 Visiteurs uniques par jour, l’E.T.C permet de multiplier par 4 à 5 cette capacité d’accueil.

Une fois les tests menés et les systèmes de déploiement / rétractation au point, il devient possible d’automatiser également la mise en place d’une extension vers
le Cloud (ETC) quand cela est nécessaire.

Conclusion


Évidemment, présenté comme cela, E.T.C c’est assez simple.

En pratique il existe pas mal de contraintes et de tests à mener. Les outils pour être complètement « élastique » sont assez technique à réaliser. Pour être francs, la R&D est « un peu » coriace mais le résultat est à la hauteur du boulot fournit !

Une capacité unique d’accueil, sans multiplier les serveurs à l’infini, mais qui peut, de manière élastique, s’auto dimensionner pour répondre à des très fortes charges temporaires. Bien évidemment il y a un coût de setup assez minime et ensuite subsiste uniquement un coût d’usage qui est très très nettement plus intéressant que le fait de multiplier les serveurs ;)

L’offre est disponible dès ce mois de décembre  2009.

(*) E.T.C (Extend To Cloud) est une marque et une technologie NBS System.

écrit par Philippe Humeau