Geoportail, SNCF, ces lancement à succès ratés…

Les lancements sont nombreux et les effet d’annonce fatals ! Geoportail n’a pas vraiment pu etre accessible avant 1 semaine ou 2. Le site de la SNCF n’a dernierement pas survécu à la vente de billet TGV à 5? avec le prime le superbe resultat de 0 ventes en ligne ! mais oui ! La faute à qui ? trop de monde en même temps il parrait !

Je ne remets pas en cause ce fait car il est vrai que tout lancement conduit à un pic dramatique pour l’architecture… Mais si le fait est avéré, il est prévisible ! Qu’ont donc fait les chefs de ces projets pour palier à celà ?!? Pas grand chose semble-t-il, en tout cas je leur souhaite car les sommes investies en se sens l’ont été à pure perte vu le résultat !

La question que je me pose est la suivante : vaut-il mieux chercher à servir tout le monde avec une forte probabilité de ne servir personne ou servir une partie seulement des Internautes ? Il semble que ces CP aient choisi la première solution et cet article à pour but, vous l’aurez compris, de décrire comment employer la seconde.

J’ai en effet lu qu’avant l’opération TGV à 5 euros, la SNCF avait anticipé le pic en multipliant par 3 la capacité serveurs… Pour le résultat commercial donnée ci-dessus … c’est du gaspi ; je leur souhaite que celà s’inscrive dans un cadre d’extension global des capacités de leur infrastructure…. bref, la solution n’est pas de ce coté.

Ma vision de ce problème serait une approche différente ; les serveurs étant saturés par :

  • La saturation de la bande passante d’entrée, dûe aux très nombreuses requetes concurente; mais il ne semble pas que ce soit le facteur premier
  • La saturation des serveurs d’application, qui semble être plus directement concernée

S’attaquer à la seconde cause n’est pas vraiment compliqué, sans même multiplier le nombre de serveurs : actuellement, les applications web sont le genre de systèmes extrèmement lourds en consommation mémoire, requete de bdd, cpu. Elles sont l’accumulation des dizaines de couches logicielles : OS, JVM, bibliothèques diverses, jdbc, ejb, frameworks, jps / servlet de présentation … bref, à chaque ouverture de nouvelles sessions, tout ce petit monde se met en branle, réserve beaucoup de mémoire et consomme une quantité astronomique de temps CPU pour n’afficher qu’un bandeau, un menu et deux trois news … L’arrivée de milliers de connexions simultanées sature alors les ressources au point que l’application ne soit tout simplement plus accessible pour personne. La machine arrive rapidement dans un etat de saturation où son temps de réponse n’est plus lineaire mais exponnentiel ; autant dire que le serveur est planté.

Une bonne solution, économique, pour se sortir de cette situation est de protéger ces serveurs de la saturation en limitant le nombre d’utilisateur concurent pouvant accéder à l’application. Celà revient à limiter le nombre de sessions simultanées. Pour empécher la saturation, cette limitation sera prise en compte par un serveur différent dont le rôle, sera, par l’utilisation d’une technologie la plus légère possible, de recevoir toutes les demandes de connexion et de ne transmettre que celles pouvant etre traitées à l’application. Les autres etant renvoyées proprement sur une page d’erreur ou d’information.
L’utilisation d’une technologie légère est la clef de cette solution. J’imagine que les modes “cluster” de serveurs apaches doit pouvoir être configurable en ce sens en limitant le nombre de sessions par serveur : jusqu’a une certaine limite, les sessions sont redirigées vers l’application, les suivante vers une simple page HTML d’erreur.
Bref.. ce n’est qu’une ébauche de solution est il y en a de multiples autres, le tout etant d’y réfléchir et de prendre le problème par le bon bout, ce qui ne me semble pas etre souvant le cas !
La solution optimale serait d’intégrer ce genre de fonctionnalités dans des éléments réseaux matériels dédiés, ce qui existe peut etre, ou en tout cas ce ne serait pas très compliquer à construire pour des spécialistes.

Au passage ces solutions sont aussi une bonne protection contre les attaques en provenance des vers de type flood… ce sont donc des solutions toujours utiles, y compris hors lancement et campagne de promotion : un investissement durable.

En conclusion, les situations que j’ai évoqué et qui font la risée des utilisateurs me semblent majoritairement évitables. Leurs impacts peuvent être tout du moins amoidris et il me semble que ces problématiques doivent donc etres prises en compte plus sérieusement.

Revenir au double click sous KDE

Franchement …. le simple clic c’est chiant !! passer son temps à ouvrir des documents alors qu’on souhaite faire une selection multiple est gavant ! bref, retour aux concepts initiaux : le double clic… problème où est cette foutue option dans KDE !

Après quelques longues recherches : la solution est

  • Panneau de config de KDE
  • Périphérique / Souris
  • Option Simple/Doucle clic

Sauvé !

Propagation de virus au travers de Wifi (anticipation)

Le fait de voir toutes ses AP visibles depuis mon réseau Wifi me font imaginer une nouvelle façon de propager un virus … un système nouveau efficasse et totalement automatique … Bien sure c’est totalement imaginaire, mais peut etre l’avenir ?
Voici quelques idées un peu en vrac…
Les virus que je trouve les plus impressionnant et interressant (disons intellectuellement parlant uniquement) sont ceux qui sont capable de s’auto-répliquer sans action de la part de l’utilisateur : ils sont emis par des machines infectées qui vous attaquent presque au hazard quand vous vous connectez sur Internet par exemple, s’installent puis se répliquent …

Le voie de contamination par l’Internet est connue, est en partie protégée par les systèmes de NAT et firewall intégrées aux routeurs.
Il existe maintenant une nouvelle voie de propagation : nos point d’accès Wifi. En effet, un virus, une fois installé sur une machine pourrait etre capable de scanner l’entourage wifi de votre réseau puis de mettre en oeuvre les technique d’attaque connue pour pénétrer ces réseaux voisins. Il pourra ensuite s’y dubliquer et les copies attaqueront les reseaux voisins… et ainsi de suite.

Avec le maillage Wifi actuel fournit par nos provider hexagonaux, la propagation de la contamination, en ville pourrait etre rapide et très large.

Les applications sont très larges et depassent d’usage classique d’un virus en permettant aussi la creation d’un reseau urbain logique multi-point de sortie / anonymisation …

Tout celà est totalement imaginaire, à ne surtout pas mettre en oeuvre bien sure, mais je trouve l’idée assez interressante.

Pour exister il faut au moins :

  • Une faille exploitable permettant l’auto-réplication des virus
  • Une methode d’attaque Wifi simple et rapide pour le Wep (on l’a) et le WPA
  • Une compatibilité de cette attaque avec le matériel wifi répendu et fonctionnant sous Windows

Avantages :

  • la diffusion du virus est quasiement impossible à tracer
  • La diffusion du virus passera par la voie des airs grace aux machines mobiles, elle penetre de fait une bonne parties de protections de réseaux classique
  • Elle peut s’en prendre à des appareils mobiles pourquoi pas (téléphones, PDA)

Applications :

  • Espionnage et surveillance
  • Constitution d’un reseau anonyme et utilisable de n’importe où en milieu urbain
  • Constitution d’un reseau à très fort maillage et donc très resistant
  • Classique groupe de robots d’attaque…

Cryptage WEP – Comment fonctionne-t-il ?

Quelques lignes pour décrire le fonctionnement d’un cryptage de type wep …
Le WEP (Wired Equivalent Privacy (lol)) repose sur un cryptage simple de type XOR (ou exclusif) entre la chaîne initiale et une clef de même longueur. La dite clef est obtenue par un algorithme RC4 initialisé à partir d’une clef partagée et un IV (Initialization Vector) aléatoire ou tout au moins dynamique.

Le cryptage se fait de la façons suivante :
– L’emetteur choisit un IV de 24 bits qu’il concatène à la clef partagée. De cette façon nous obtenons 2^24 clefs différentes à partir d’une clef partagée statique, elle même de 104 bits (pour un total de 128 bits).
– Le RC4 est initialisé avec cette clef : le but du RC4 est de remplir un tableau de 256 octets avec cette clef, puis de piocher dans ce tableau des valeurs tout en les modifiant au fur et à mesure. Cette methode permet à partir d’un clef d’obtenir une suite unique et pseudo aléatoire de valeurs à sa sortie.
– La sortie du RC4 est ensuite utilisée pour crypter la chaîne à envoyer. Le RC4 genère un flow de bits (ou octets) infini, il est donc tout à fait adapté au cryptage de données de longueur variable comme des trames réseaux.
– La trame est émise vers le destinataire en incluant l’IV de sorte que le destinaitre soit capable de recréer la même suite RC4 pour décrypter le message.
– Le recepteur est donc à même de générer une clef de (dé)cryptage identique à l’emeteur, issue de RC4, il ne lui reste plus qu’à appliquer la même fonction que pour le cryptage puisque (N XOR K) XOR K = N avec N le message initial.

Voila comment celà se passe, comment celà est-il attaqué alors ?
– Tout d’abord, avec une seule clef partagée, il y a 16M de clefs générées, ce qui signifie que la véritable clef de cryptage issue du RC4 change régulièrement, pour ainsi dire à chaque trame ce qui complique la donne.
– Pour attaquer ce type de cryptage, il faut donc tout d’abord s’attaquer à la véritable clef de crytage issue de RC4 et l’identifier ; en identifier un maximum. Pour se faire il est nécessaire de connaitre des données claires et cryptées, récupérer la clef est alors simple, il suffit d’appliquer : (N XOR K) XOR N = K. Cette opération est possible sur certaines trames récurentes dont l’entete est connue des ARP par exemple, ce qui permet de connaitre les premiers octets de la suite.
– Une fois que l’on a collecté de multiples entêtes de clefs issues de RC4 avec leur partie IV associée, il reste à trouver quelles sont les clefs sources ayant le plus probablement conduit à cette génération et ainsi déterminer la clef partagée initiale.
– Cette approche est statistique puisque plusieurs clefs peuvent conduire au même début de suite issu de RC4 (et nous ne connaissons que le début !) Ainsi nous ne pouvons calculer que des suppositions sur le contenu initial du tableau RC4 et eliminer des solutions impossibles.
– De fait pour optimiser la recherche, il est nécessaire, soit d’avoir un maximum de trames et d’IV (de 500.000 à 3 M en général), soit d’avoir des suites plus longues issues du RC4.

Comment fonctionne WEP ?

C’est à grand renfort d’articles sur tout la toile qu’un nouveau POC (Proof Of Concept) vient annoncer que WEP est mort ! rien de bien nouveau en soit puisqu’on l’avait dejà tué depuis des années, mais cette fois la méthode est plus rapide, plus automatique et sans doute bientot à la portée de tous, ou presque.

Est-ce alarmant ? en soit, utiliser Wep est alarmant depuis bien longtemps, donc un peu plus un peu moins ? et si vous dormez sur vos deux oreiles malgré cela et bien continuez ! il n’y a pas de raisons ; le tout c’est d’en être concient, non ?

Qu’est ce que cette nouvelle methode de Bitau, Handley et Joshlack ? Elle repose en fait sur l’utilisation d’un utilitaire existant dans le protocole 802.11 (Wifi) : la fragmentation de trame ou plutot la défragmentation par l’AP. Le rôle de l’AP dans un réseau avec architecture est de recevoir les trames de tout le monde puis de les réémettre : ainsi si tout le monde capte l’AP, tout le monde peut communiquer, y compris si deux postes sont trop distants pour se joindre directement … L’AP etant un périphérique intelligent, lorsqu’il recoit des fragments de trames, il commence par les réunir en trame plus grosses avant de les réémettre. Alors comment cela nous aide-t-il a craquer une clef Wifi, c’est assez simple :
Avec le cryptage WEP, qui n’est autre qu’un simple XOR, il suffit de connaitre une chaine et son equivalent crypté pour connaitre la clef de cryptage, donc puisque nous captons des données cryptées, il nous faut connaitre leur equivalent non crypté pour connaitre la clef associée. Les protocoles de couches basse nous aident en celà : certaines trames LLC/SNAC, ARP ont des parties qui sont constantes et celles-ci sont identifiables par des tailles caractéristiques. En captant ces trames, nous avons des données cryptées et connaissons leur équivalent non crypté. Ainsi il est possible d’obtenir facilement quelques octets de la clef de cryptage (qui n’est cependant pas directment la clef partagée que l’utilisateur configure).
Cette étape accomplie, la nouvelle solution par fragmentation entre en jeu : les morceaux de clef que nous avons sont trop petits, la fragementation va nous permettre de les multiplier : il suffit de renvoyer plusieurs fois la trame reçue en l’indiquant fragmentée : connaissons la cryptée et son équivalent décryptée. L’AP va recevoir ces fragments, les décrypter et les assembler dans une nouvelle trame qu’il va crypter puis, enfin, réémettre cettre trame sur le réseau. Cette trame nous allons pouvoir l’écouter, nous connaissons sa version non cryptée puisqu’il s’agit de la concaténation du message precédent avec lui-même et l’AP vient de nous fournir sa version cryptée. Nous sommes donc à même, comme à l’étape 1 de connaitre la clef associée, mais cette fois nous n’avons plus 8 octets mais n*8 octets (avec n le nombre de framents).

En continuant ainsi il est possible d’obtenir une clef de cryptage valide suffisemment grande pour crypter n’importe quel paquet. Nous allons donc pouvoir emettre sur le réseau n’importe quel paquet, sans connaitre la clef partagée initiale mais simplement la suite issue du RC4. Cette facultée va nous permettre de générer du traffic valide vers le réseau et ainsi collecter un maximum de trames pour, par la suite, lancer une attaque sur ces informations et en déduire la clef partagée (type aircrack).
Cette methode, présentée ainsi est donc une solution plus rapide et encore imparable pour générer du traffic : le principe de defragmentation est à la base du protocole, il est difficile de le bloquer alors que bloquer les réémissions forcée d’une methode aireplay est assez courant. Par ailleurs, il permet de connaitre bcp plus de données de chaque chaînes cryptées (contrairement aux ARP habituels) et ainsi d’etre plus efficasse avec moins de trames.
Cette mehode reste totalement interdite à l’utilisation hors de son propre réseau privé puisqu’elle demande l’emission de données vers le réseau distant, ce qui implique une intrusion dans le dit système, Acte répréhensible par la lois.

Les auteurs de cette methode, proposent une autre alternative à la simple collecte d’informations en vue de connaitre la clef partagée ; en effet, ils proposent d’utiliser cette methode, associée à d’autres pour forcer l’AP à router des paquets cryptés vers l’Internet : dans ce cas, le paquet emis en direction de l’Internet est décrypté par l’AP avant d’etre envoyé sur la ligne (logique on sort du WLAN). Le site distant est alors un site amis du pirate qui va ainsi recevoir les données décryptées issues du réseau WLAN dit “sécurisé” … pas mal ! Le principe en est assez simple, il s’agit de créer une entête IP a destination du serveur sur l’Internet, de l’indiquer fragmenter et de réémettre un paquet crypté que l’on souhaite faire décrypter en l’indiquant comme étant la suite du précédent. L’AP va alors decrypter les deux, concaténer le paquet “secret” à notre entete IP, constater qu’il s’agit d’une trame pour l’extérieur et la router décryptée. Reste que ce type d’attaque est plus facile à tracer qu’un wardriving sauvage, rendu rapide par la methode.

Quid de l’implémentation ? Les auteurs proposent quelques sources de leur POC, la mise en oeuvre demande un contrôle au niveau le plus bas des cartes Wifi, pour, entre autre, gérer les flags permettant la fragmentation au niveau logiciel. Ces possibilités ne sont pas offertes sure toutes les puces ou demandent des workaround un peu touchy .. bref, pour l’instant 2 chips sont supportés dont le PRISM2. Il y a de fortes chances pour que d’autres arrivent.
Point vraiment interressant, ce qu’ils ont mis en oeuvre est totalement automatisé, contrairement à ce qui existe sur aircrack. Les outils aircrack ne peuvent pas etre mis entre toutes les mains, elle doivent toujours être averties : ligne de commandes, options compliquées… Une solution entierement automatisée pourrait etendre la chose aux pirate boutoneux du dimanche …
Il n’en reste pas moins que ca ne marche et ne marchera sans doute jamais que sous Linux et autre BSD ;o)

Déjà de la concurence dans les desktop léger !

Le concept n’existe pas encore, autant dire qu’aucune courbe de Garnet n’envisage même la chose et pourtant la concurrence s’annonce rude pour ce qui se nomme par abus de langage des OS légers, disons plutot des desktop legers ! Après eyeOs voici la venue de YouOS

Comme d’habitude, il s’agit surtout d’un démonstrateur de ce qui se fait en Ajax, on est encore loin d’un système utilisable tout les jours, applications très limitées, performances et compatibilité un peu légères. Comme eyeOs il s’agit surtout un POC (Proof Of Concept).

Et comme eyeOs ca ne marche pas trop mal en ce sens. Il semble que ce système soit porté par une entreprise qui doit donc y voir un avenir commercial, point plutôt intéressant et il est vrai qu’il n’y a pas de raison pour que ca ne le deviennent pas. Après tout emporter son espace personnel avec soit est plutôt un concept prometteur.

Ce qu’il manque avant tout à cela à mon avis est ce qui fédère un front-end graphique : des librairies de développement, des standards de communication pour que d’autres puissent développer des applications et ainsi dépasser les simples calculatrices et autres joujou ajax. Une architecture principalement basée sur les webservice avec une composante serveur très forte serait beaucoup plus intéressante que l’espèce de paquet de nouille javascript qui nous est présenté.

Bref le concept n’est donc pas nouveau mais récent, il n’est pas le premier, ça reste prometteur mais on attend de voir mieux, en tout cas cette concurrence devrait stimuler les développeurs !

USA, I’m back

Me voila aux States comme on dit, pour quelques jours de boulo, en soit je trouve ca assez allucinant : ce matin j’etais chez moi tranquilou et ce soir, l’ai traversé l’Atlantique, il est ici 18h enfin plutot 1h00 du mat à mon compteur personnel, mais j’ai fais la moitier du tour de la planete (en exagérant juste un peu) en moins de temps qu’il n’en faut pour rejoindre Marseille par un jour de grand départ … banal en un sens, allucinant en un autre.

Allucinant, c’est toujours le mot qui me vient à l’esprit avec les américains, je les avais laissé avec leur fromage en bombe et leur avocats plus faciles à trouver qu’un bureau de tabac chez nous… Je les retrouve 6 ans plus tard plutot pareil à première vue : j’ai fait le trajet avec à coté de moi une jeune fille (16-17 ans) qui a passé presque tout le trajet à lire une bible, comment dire… Enorme !!! et pas le genre de bouquin qu’on vous offre et que vous ouvrez de temps en temps pour faire plaisir, non, pas de celà monsieur, mais bien un exemplaire, lu, relu, commenté, annoté, taggé.. bref 2kg de papier dont chaque ligne a dû être compulsé avec délectation …. je ne sais pas trop comment appeler celà ? du fanatisme peut être ?
Hors mis ce premier fait marquant, j’ai retrouvé mes très chers produits garanti fat-free … et mon préféré : l’eau, garantie il y a 6 ans, sans sel ni graisse (des fois qu’on vous refile de l’eau de mer assaissonée à l’huile d’olive en guise d’eau minerale ?!?) Et bien vous ne devinerez jamais, elle est maintenant purifiée … quand je pense que nous on paye l’eau minerale 2 fois plus cher que l’eau de source parceque justement ya des trucs dedans… ben eux, il l’enlève le truc ! à se demander si des fois ca serait pas pour nous le revendre à part dans des cachetons ! Bref, on est pas très loins de la formule H2O brute dans la bouteille… Bref, j’imaginais même pas qu’on puisse avoir besoin de préciser que dans l’eau, ben ya que de l’eau…
L’autre point qui m’a subjugué est bien entendu la montée sécuritaire aux frontière, j’ai précédemment écrit un petit mot d’humeur sur le passeport électronique, et bien se dispositif que je trouve dejà assez intrusif et complété de nombreuses nouvelles mesures : prise l’empruntes et de photo à l’entrée du pays. Rien de choquant en soit puisque ce sont les règles, il faut les accepter, mais bon … j’espere qu’un serial killer n’empruntera pas la même chambre que moi dans un hotel ou que je ne vais pas passer dans le champ d’une camera 10 min avant ou après un hold-up… ca serait un truc à se retrouver en prison plus vite qu’un americain qui en serait sans doute l’auteur… ben oui, ca reste combien de temps une emprunte ? Bref, c’est un peu flippant, mais bon en France les empruntes sont bien prises lors de notre demande de carte d’identitée.

Voilà pour les petites piques, à part ca leur voitures qui me semblaient si grosses à l’époque semblent avoir diminuée de taille… est ce le lire de supper qui à doublé (sisi), le fait dêtre dans un autre état ou bien le fait que nous aussi nous nous soyons mis aux 4×4 urbains, en tout cas je ne suis cette fois moins choqué par la différence. Voila, sinon l’accueil du Français que je suis m’a semblé très sympa, courtois, les gens sont serviables, même l’officier des douanes et là pour le coup, je pense que c’est parceque je n’ai pas attéri au même endroi! héhé.
Aller .. un petit coup de CNN en attendant ma valise, histoire de ne pas me retrouver au boulo en short et en tong demain matin …

Dell L400 et configuration ACPI

Autant sur une machine de bureau, l’acpi on vit bien sans, autant sur un portable on frole de danger si ca ne marche pas correctement ; à mettre en rapport avec mes remarques sur la suse 10 et 10.1 qui m’on values quelques arrets pour surchauffe ! Une solution qui semble bien fonctionner : couper l’acpi au démarrage (acpi=off) lors du prompt de sorte à laisser le bios se débrouiller…

Pour faire plus propre, il est toutefois possible de “débugger son acpi” : en fait, dans les distro classiques, on va avoir une configuration acpi générique : elle fontionne bien dans beaucoup de cas, mais pas toujours (un portable standard ca existe ?). Il est alors possible de mettre à jour l’acpi pour qu’il supporte correctement la machine… En voici la recette, appliquée sur mon L400.

  • Se procurer le fichier DSDT adapté au portable. (Tout est dans ce fichier de description de l’acpi !). Pour se faire, il faut télécharger le fichier sur cette adresse en précisant le constructeur et la marque.
  • Il faut ensuite compiler se fichier à l’aide de l’utilitaire fournit par Intel ici en choisissant la version source unix. Il faudra d’abord compiler le compilateur (nécessite bison et flex) en lançant make dans le répertoire compiler. Il faudra ensuite compiler la DSDT précedemment télécharger avec la commande suivante :
    iasl -tc dsdt.asl ce qui devrait générer un fichier de type dsdt.hex qui n’est d’autre en fait qu’un fichier de type “.h”
  • L’etape suivante consiste à recompiler son noyau pour ce celà soit pris en compte. Tout d’abord preparrons un noyau : make clean ; make mprpoper; make cloneconfig puis lancer la configuration via X make xconfig
  • La configuration de la nouvelle DSDT est, sur les noyaux 2.6.13 plus simple que ce qui est décrit sur les HOWTO classiques : dans la rubrique Power management options/acpi/ il faut cocher Include Custom DSDT puis double clicker sur Custom DSDT Table file to include et entrez le chemin complet jusqu’au fichier .hex.
  • Il reste à compiler le noyau :make
  • Enfin, il faut recopier le noyau ainsi obtenu dans le répertoire /boot. le noyau se trouve dans le répertoire /usr/src/linux/arch/i386/boot sous le nom de bzImage, il sera compié dans /boot sous le nom de vmlinuz-xxxx-version-xxx-acpi par exemple (voir le format de celui existant) et il faudra alors mettre à jour le lien symbolique de vmlinuz.
  • Pour terminer… on reboote