Archives mensuelles : octobre 2003

Quelle sécurité informatique ?

Dans un article de « the Atlantic », l’expert en sécurité Bruce Schneier expose sa philosophie en matière de sécurité et notamment de sécurité informatique. Après une période d’enthousiasme excessif pour les technologies de chiffrement en tant que solution absolue pour la sécurité informatique, Bruce Schneier a constaté que, davantage que la « force » d’une technologie de sécurité, il convient d’évaluer les conséquences de ses défaillances. Et si il est bien une règle reconnue en matière de sécurité, c’est qu’il n’existe pas de sécurité absolue. Les défaillances doivent être considérées comme inévitables et donc gérées. Bref, la diminution de l’alea (probabilité d’occurence d’un incident) ne suffit pas pour pouvoir gérer le risque. Il faut également évaluer l’enjeu (les conséquences de l’incident) (risque = enjeu * alea).
C’est pourquoi M. Schneier se méfie des solutions technologiques aux problématiques de sécurité nationale face au terrorisme : elles peuvent « mal » défaillir alors que des mesures plus simples et « défaillant mieux » seraient non seulement plus sûres mais aussi moins coûteuses. Il convient selon lui de se méfier d’une stratégie de sécurité consistant à s’appuyer sur le secret entourant un dispositifs de sécurité ; les systèmes de sécurité reposant sur le secret défaillent mal, en général. Selon Schneier, pour concevoir un système de sécurité, il convient d’abord de répondre à la question des finalités (pourquoi concevoir un tel système) mais aussi celle des conséquences de la mise en place de ce système, en particulier lorsqu’il défaille.
Par exemple, si votre sécurité informatique repose sur un système à base d’empreinte digitale ultra-moderne, que faites-vous lorsqu’une personne malveillante dérobe une copie de votre empreinte ? Lorsque votre carte bleue est volée, la banque peut faire opposition et vous donner une toute nouvelle carte. Mais on ne peut pas en faire autant avec vos doigts ! De même, mettre en place des cartes d’identité sécurisées aux USA n’aurait pas empêché les terroristes du World Trade Center d’entrer sur le territoire : ce n’était leur identité qu’il fallait pouvoir authentifier (ils sont entrés aux USA sous leur véritable identité) mais leurs intentions. Enfin, Bruce Schneier estime qu’appuyer la sécurité nationale américaine sur des systèmes centralisés et massivement informatisés n’est pas la manière la plus sûre de faire, étant donnée la faiblesse générale de la sécurité des réseaux informatiques. Même les réseaux nationaux sécurisés et non connectés à l’Internet ont été l’objet de contaminations par les récents vers et virus de Windows et d’Outlook. Il suffit qu’un utilisateur y ait connecté son portable après que celui-ci a été contaminé sur le Net. Sans compter les mesures de sécurité contournées par les utilisateurs lorsque ceux-ci décident de privilégier leur confort d’utilisateur et leur productivité à l’application de règles trop contraignantes.
Schneier recommande de privilégier les mesures physiques et humaines aux mesures informatiques. Il donne plusieurs suggestions concernant la sécurisation des vols aériens vis-à-vis des actes de terrorisme. Dans la même veine, Schneier explique que les systèmes de sécurité doivent s’appuyer sur le comportement des gens (et non contraindre celui-ci) : c’est pourquoi le moyen le plus efficace pour prévenir le vol de sa voiture consiste non pas à l’équiper d’un système ultraperfectionné mais à la garer dans un parking gardé ou dans un quartier bien fréquenté dans lequel les gens remarqueraient toute effraction. Et la formation des personnes (et donc des utilisateurs informatiques) semble le meilleur levier pour la sécurité, y compris la sécurité informatique.

Java = 4×4 (la suite)

Philip Greenspun affirme que Java est le 4×4 des langages de programmation : surpuissant et trop gourmand en ressources pour un usage quotidien. Sur Slashdot, les commentaires sont allés bon train. Il a été précisé que l’observation de Greenspun se limite au contexte du développement Web classique. Je retiens de cette discussion les points suivants. :

  • Java, en soi : Dire que Java est un 4×4 ne signifie pas que Java n’est jamais un bon choix. Pour certains usages, rien ne vaut un 4×4. Mais pas pour aller déposer les enfants à l’école. Java permet aussi bien de développer des applications qui sont executées dans les téléphones portables que des systèmes d’intégration d’applications d’entreprises de grande échelle. C’est pourquoi Java serait surchargé de sophistication inutile (« bloatware ») pour chacun de ces usages. Java fournit une solution homogène à presque tous les types de problèmes applicatifs rencontrés dans l’entreprise mais au prix d’une complexité et d’un coût accrus.
  • Java et Python : Comparer Java à Perl ou à Lisp est une erreur, le langage le plus comparable est plutôt Python (ou C#). Pour faire un site web simple, Python serait préférable à Java. De même pour des activités plus expérimentales.
  • Java et PHP : Un avis récurrent est : « PHP pour le Web, Java pour les applications requérant des traitements logiques très complexes côté serveurs ».
  • Java et VB : L’avantage principal de Java (par rapport au langage C# ou VB.Net de Microsoft) est la portabilité. Visual Basic est préférable à Java dans tous les cas où l’on a besoin d’une riche interface graphique pour l’utilisateur (en client-serveur) et où l’application à développer ne doit pas tourner ailleurs que dans Windows. VB (pas forcément VB.Net) manque cruellement de certaines fonctionnalités ce qui oblige trop souvent le développeur à réinventer la roue.
  • Perl : Perl est extraordinairement puissant (permet de faire des choses très sophistiquées en un nombre de lignes de code très réduit) mais les développements sont difficiles à maintenir car le code est peu lisible lorsque toute la puissance de Perl est mise en oeuvre.
  • JSP : la manière dont le code Java est mélangé au code HTML de présentation dans la technologie JSP rend le tout difficile à maintenir. Le système de modélisation de pages (templates) de JSP comporte le risque intrinsèque de laisser les développeurs créer des applications immaintenables. Une grande rigueur de développement est donc nécessaire. On rencontre le même type de risque avec les technologies de scripting similaires (PHP, ASP, DTML) mais la manière de faire avec JSP ajouterait à cela des défauts dus au fait que Java n’a pas été conçu spécifiquement pour ce type d’usages : plus de lignes à coder et à maintenir, complexité accrue, adéquation moindre aux besoins Web classiques…

Un article critique au sujet de Java : Java’s Cover.

Wifi selon PCMag

Un article de PC Mag très complet fait le point sur l’état des technologies et produits Wifi de « grande consommation ». Voici ce que j’en retiens :

  • Les normes Wifi sont les suivantes : 802.11a (adapté à un contexte d’entreprise), 802.11b (le Wifi « classique »), 802.11b+ (à peine un peu plus performant que le 802.11b), 802.11g (le futur-déjà-présent du Wifi, plus performant et compatible avec 802.11b).
  • La norme 802.11g, plus performante que 802.11b, n’est pas encore stabilisée mais elle est implémentée dans nombre de points d’accès Wifi, pour lesquelles une mise à jour via des firmware sera disponible une fois que la norme aura été stabilisée et officialisée. 802.11g est un bon choix pour le particulier ou la PME qui veut s’équiper d’un point d’accès, du moment que la mise à jour via firmware ne fait pas peur.
  • Les fonctionnalités de sécurité à attendre d’un point d’accès Wifi sont les suivantes : chiffrement des communications par le protocole WEP avec des clefs les plus longues possibles (au moins 128 bits), désactivation de la diffusion de l’identifiant réseau SSID, filtrage des accès selon les adresses MAC. Il convient d’activer ces 3 mesures de sécurité lorsque l’on installe un réseau Wifi. Un standard 802.11i est en cours de préparation pour introduire dans Wifi plusieurs mesures de sécurité obligatoires : un framework d’authentification (802.11x), des systèmes de gestion des clefs de chiffrement, et deux protocoles pour renforcer WEP : TKIP et AES. En attendant la norme 802.11x, une norme intermédiaire est en cours de préparation : la technologie WPA (qui renforce WEP). WPA est conçue pour pouvoir être déployée dans un point d’accès via une mise à jour du firmware.
  • Toutes ces mesures de sécurité peuvent être contournées par un pirate très compétent et motivé : une clef WEP peut être cassée si votre réseau est mis sur écoute avec un logiciel comme AirSnort, l’identifiant réseau SSID peut être visible pour n’importe quelle personne qui le capte à moins que sa diffusion ne soit désactivée par le point d’accès, une adresse MAC peut être usurpée (spoofing). Mais mettre en oeuvre toutes ces mesures, c’est mieux que rien. En effet, sans ces mesures de sécurité, n’importe quel passant ou voisin peut librement accéder à vos services réseaux Wifi et donc essayer de se connecter à votre ordinateur, à votre fournisseur d’accès Internet, etc.
  • Les produits suivants sont à éviter pour le particulier qui veut acheter un point d’accès (moi, par exemple) : Linksys WRT55AG (le plus cher, super qualité et super performance mais s’appuie sur du 802.11a dont je n’ai pas besoin d’où le prix), ZyXEL ZyAir B-2000 (car ne supporte que le 802.11b, même si c’est un produit très complet et riche en fonctionnalités), Belkin F5D7230-4 (cher et peu performant), Buffalo AirStation WBR-G54 (le moins performant de tous les points d’accès étudiés dans l’article), Adaptec Ultra Wireless Access Point (performant, mais on peut avoir un point d’accès avec fonction de routeur en plus pour le même prix chez Adaptec également ou bien comme le Netgear ME102), D-Link DI-614+ (802.11b+ pas plus performant que les 802.11b et moins que les 802.11g), Hawking H-WR258 (produit « au mieux médiocre »), Linksys WAP11 (bon rapport qualité-prix mais 802.11b seulement), Microsoft MN-500 (le moins cher mais l’un des moins performants, et pas facile à configurer, ne fonctionne pas avec un PC en Windows 2000), Netgear ME102 (802.11b pas mauvais, qui peut s’utiliser en bridge, mais manque d’une interface d’administration Web et l’utilitaire client est trop incomplet), Siemens SpeedStream 2524 (riches en fonctionnalités mais mauvaises performances), U.S. Robotics 2249 (802.11b+ pas plus performant que le 802.11b, simple à utiliser, support du WEP 256 bits mais pas de possibilité d’antenne externe), Cisco Aironet 1200 series (plutôt pour l’entreprise car 802.11a/b), Proxim AP-2500 (pour l’entreprise, 802.11a/b), 3Com AP8700 (idem)
  • Les produits suivants peuvent être envisagés :
    • D-Link DI-624 : prix moyen, facile à installer et utiliser, administration à distance, paramétrage très complets (ports, IP, filtres, bases de règles, VPN) et reporting sur le traffic, mais n’a pas de mode « g-only » si bien que si un client s’associe au réseau en 802.11b, les performances des clients en 802.11g chutent significativement
    • SMC Barricade g 2804WBR : nombreuses fonctionnalités NAT dont « address mapping » et « port forwarding », possibilité d’utiliser des antennes à gain élevé, simple à installer pour le novice, WEP 128 bits, NAT, broadcast ESSID désactivable, filtrage par adresse MAC, fournit un mode « g-only ».
    • NetGear WG602 : prix attrayant, performant et riche en fonctionnalités de sécurité, fournit une interface d’administration distante via le Web, fournit un mode « g-only ».
  • Pour les antennes externes, il faut d’abord vérifier que le point d’accès (ou la carte Wifi) permet d’en connecter une. Les prises pour antennes externes sur les points d’accès sont habituellement de type « SMA ». Il existe quatre familles d’antennes. Plus leur faisceau d’émission est étroit plus elles portent loin et fournissent un gain élevé et plus leur prix est également élevé :
    • les antennes dipoles omnidirectionnelles, 4 à 6 dBi, de l’ordre de 30 euros, émettent dans toutes les directions autour de leur axe mais essentiellement dans un plan perpendiculaire à l’axe (il faut éviter d’être dans l’axe car le signal y est plus faible)
    • les antennes directionnelles, de l’ordre de 40 euros, émettent dans un cone de 30 degré environ, bien adaptées pour couvrir une salle de conférence ou une rangée de bureaux
    • les antennes Yagi, de l’ordre de 130 euros, émettent un faisceau d’environ 15 degré, à gain élevé, bien adaptées pour connecter un bâtiment à un autre sur un campus par exemple
    • les anntennes paraboliques ou « à grille » ont un faisceau de quelques degrés seulement (4 ou plus généralement), certaines paraboles sont adaptées aux situations à grand vent mais restent encombrantes et très visibles, elles sont bien adaptées pour connecter deux bâtiments séparées d’un ou deux kilomètres (voire plus dans certains cas)

    L’article de PCMag fournit de nombreuses références de documentations pour construire soit-même son antenne.

Requête HTTP par Javascript côté client

Vous voulez que du code Javascript, côté client (exécuté dans le navigateur), génère une requête HTTP vers un serveur, récupère le résultat puis le traite et poursuive ainsi son exécution. Comment faire ? Il faut utiliser un objet httpRequest présent dans le DOM. Ce type d’interface est apparemment en cours de spécification dans le standard DOM du W3C (au sens du standard « DOM Level 3 Load & Save »). MS IE et Mozilla implémente tous les deux cet objet même si le code pour l’instancier diffère un tout petit peu. Il existe plusieurs documentations qui expliquent plus en détails comment faire.

Java est aux langages de programmation ce que les 4×4 sont aux voitures

Java est le 4×4 des langages de développement : ultra-puissant, tout-terrain (sauf lorsqu’il s’agit de faire un Paris-Dakar), énorme consommateur (de temps de développement et de ressource machine). Comme les conductrices de 4×4 en centre ville, certaines sociétés utilisent Java à contre-emploi.
JSP est la technologie Java de loin la plus simple au sein de la spécification J2EE. Pourtant, d’après Philip Greenspun, professeur d’informatique au MIT, même les étudiants informaticiens du MIT ont du mal à la mettre efficacement en oeuvre tellement elle est complexe au regard du type de problème qu’elle est sensée traiter. D’après Philip Greenspun, un projet Web simple utilisant Java coûtera 5 fois plus, sera deux fois plus longs à livrer et sera plus dur à maintenir que si il utilisait un langage de scripting tel que PHP ou Perl. Mais les développeurs et les managers se sentiraient rassurés à l’idée qu’avec Java ils pourraient, au moins en théorie, résoudre des problèmes informatiques d’une complexité très importante, même si cela ne correspond pas à la situation qu’ils ont à traiter au quotidien.

Le culte du « Non Disclosure Agreement »

Depuis l’époque des start-ups, une idée reçue a fait le tour du monde : pour garantir le succès d’un projet d’entreprise, il faudrait engager tous les partenaires du projet à maintenir celui-ci dans un secret absolu. L’engagement pris se traduisait par un contrat de non divulgation (le « NDA ») qu’il fallait signer, bien entendu, avant de prendre connaissance des renseignements à ne pas révéler. Sur le carnet « Dispatches from the Frozen North », on peut apprendre à démonter cette mode du NDA, à rendre les entrepreneurs plus humbles (tâche ô combien difficile étant donné le surdimensionnement d’ego caractéristique de cette activité) et à se concentrer sur les facteurs clefs du succès d’un projet d’entreprise.

Wifi : points d’accès D-Link et Linksys

Dans ma recherche d’un bon point d’accès Wifi pour chez moi, j’ai lu un article sur le point d’accès D-Link DI-624. Ce point d’accès fait également routeur, serveur DHCP, firewall avec DMZ et filtres en entrée et en sortie. 217 euros HT en juin 2003 d’après Décision Micro.
Le Linksys WRT54G, quant à lui, fait switch 10/100 full duplex 4 ports, serveur DHCP, routeur NAT avec support du VPN, cryptage WEP 128 bits et filtrage par adresses MAC.

Intelligence collective, le projet

Pierre Lévy, à l’Université d’Ottawa, présente son projet de recherche sur l’intelligence collective : créer un modèle théorique qui permet de représenter et de gérer l’intelligence collective d’un système sous la forme des échanges de savoirs qui le traversent et des réseaux qui les sous-tendent. Pierre Lévy projette d’implémenter ce modèle sous la forme d’un logiciel opensource. Ce logiciel permettra de représenter graphiquement ces savoirs et réseaux, de les valoriser et donc de les échanger au sein d’une économie nouvelle. Le logiciel se présentera comme une sorte de jeu de plateau (jeu de l’oie, mandala, …).

Surveiller la performance d’un site sans infrastructure de test

Pour surveiller ou mesurer la performance d’un site web, on utilise généralement des sondes, agents ou scripts qui, installées sur une machine, simulent l’activité d’un utilisateur et mesurent les temps de réponse et autres indicateurs de performances (taille des pages, bande passante, …). Ceci rend les campagnes de test difficiles à mettre en oeuvre (coût de la conception et du paramétrage mais également coût du déploiement et de l’installation). Et cela rend le bénéfice ephémère puisque les agents de tests qui sont déployés ne sont généralement pas maintenus en place. Lorsqu’ils sont maintenus en place, on parle d’infrastructure de supervision. Le coût de la maintenance et de l’exploitation d’une infrastructure d’agents de supervision est significativement élevé puisqu’il s’agit de maintenir une architecture d’agents distribués. Il s’agit alors de superviser l’infrastructure de supervision !
Pour contourner cette difficulté, dans le cas où l’on ne cherche pas à obtenir des mesures détaillées et approfondis et où l’on souhaite privilégier la durabilité du dispositif de surveillance et sa maintenabilité, une astuce peut être employée : recourir à des agents qui ne sont pas déployés sur des postes clients distants mais qui résident dans du code exécuté côté client depuis une page web. On recourt alors aux technologies ActiveX ou applets Java ou bien encore, si l’on souhaite respecter un standard plus ouvert (mais moins sophistiqué) : Javascript. Il s’agit donc de recourir à un agent de test et de mesure en Javascript :