Le contrôle vocal avec Raspberry Pi + S.A.R.A.H.

Bonjour,

Dans cet article, je vais vous montrer comment contrôler les GPIOs de votre Raspberry préféré avec la voix. A la fin de cet article, votre vie peut en être bouleversée à différents niveaux :

  • vous passez pour un fou qui parle tout seul dans son salon
  • vous ne vous levez plus jamais de votre canapé pour allumer une lampe
  • vous quittez votre femme pour une dénommée Sarah

Passons à la présentation de nos deux projets qui vont révolutionner votre vie, vous l’aurez compris dans le titre, je parle du Raspberry Pi et de S.A.R.A.H. Voici un exemple de ce qu’on va obtenir :

S.A.R.A.H. tire son nom de l’excellente série Eureka. Ce projet a pour vocation de rassembler et de faire communiquer tout les objets connectés tels que les SmartTV, Nabaztag, box TV, etc., ainsi que les différentes informations que l’on peut récupérer sur le net grâce à des API voir même sans API (PhantomJS) comme la météo, des infos sur Wikipédia, etc. Un des grands avantages de S.A.R.A.H. est l’intégration de la reconnaissance vocale ou gestuelle ( Kinect ).  Un autre  avantage est l’écriture de plugins qui est extrêmement simple et ne nécessite que des connaissances basiques de XML et de JS.

S.A.R.A.H. sera donc le point central du projet ( le cerveau ?) qui vas nous permettre de connecter notre voix avec les GPIOs de notre Raspberry Pi.

Le Raspberry Pi, quant à lui, n’est plus à présenter mais, si c’est encore le cas, voici quelques liens qui vont vous aider :

Ce petit ordinateur est tellement flexible en termes d’utilisation que ça fait de lui notre meilleur ami pour ce genre de projet. Le contrôle de ses entrées/sorties se font simplement par script python ou même pas simple commande bash.

relaisA partir de là, il suffit de connecter ce que l’on souhaite sur ses entrées/sorties. Personnellement, j’ai branché un capteur de température, 3 DEL, un détecteur de mouvement ainsi qu’une carte relais que j’ai relié à une prise 220 V . Vous trouverez facilement des plans de montage sur Internet. Voici un exemple sur un excellent blog que je vous conseille de suivre : http://blog.idleman.fr/?p=1623.

lego_raspberry
Si vous faites comme moi et que vous branchez votre Raspberry avec du 220 V, je vous conseille la plus grande prudence en ce qui concerne l’isolation et l’accessibilité du circuit. Pour ma part, en plus de l’isolation, je lui ai construit un petit boîtier en LEGO qui évite de laisser la carte à l’air libre.

Une fois nos périphériques connectés aux différents GPIOs de notre Raspberry, il nous faut rendre accessibles les GPIOs à S.A.R.A.H. Pour cela, j’ai écrit un petit projet python https://github.com/bewiwi/py-script qui permet d’exécuter un script depuis une requête HTTP. Il est fourni avec le script rb.py qui permet de contrôler les GPIOs en mode sortie ou de lire le statut d’une entrée.

Pour l’installation et l’utilisation, rendez-vous dans l’article précédent : L’Apéiseur de script

Pour l’utilisation avec les GPIOs, nous utiliserons des requêtes comme celle ci-dessous qui va activer la sortie de la GPIO 23 :

curl "http://192.168.1.2:8080/rb.py?s=1&i=23"

et pour la désactiver :

curl "http://192.168.1.2:8080/rb.py?s=0&i=23"

L’avantage de passer par cette surcouche HTTP est la simplicité d’ajout de nouveaux capteurs. Pour exemple, en plus du contrôle des GPIOs, j’ai aussi un simple script qui me permet de consulter la température de mon capteur.

Une fois le contrôle effectué depuis nos requêtes HTTP, il ne nous reste plus qu’a écrire le lien entre S.A.R.A.H. et notre Raspberry par le biais d’un petit plugin en 3 fichiers tout simple :

  • rb.prop
  • rb.js
  • rb.xml

Le fichier rb.prop définit le plugin avec son type, son nom, ses arguments

{
  "modules" : {
    "rb" : {
      "description": "Sarah controle mon raspberry",
      "version" : "1.0",
      "rb_http": "http://192.168.1.2:8080/"
    }
  }
}

Dans ce fichier on peut définir le lien vers l’API de notre service de contrôle des GPIOs. Ce lien sera aussi modifiable dans l’interface de S.A.R.A.H.

La définition de la grammaire vocale est définie dans le fichier rb.xml :

<grammar version="1.0" xml:lang="fr-FR" mode="voice" root="ruleRb" xmlns="http://www.w3.org/2001/06/grammar" tag-format="semantics/1.0">
<rule id="ruleRb" scope="public">
<example>Sarah allume la guirlande</example>
<tag>out.action=new Object(); </tag>
 
<item>Sarah</item>
<one-of>
<item>Allume<tag>out.action.status="1";</tag></item>
<item>Demarre<tag>out.action.status="1";</tag></item>
<item>Stop<tag>out.action.status="0";</tag></item>
<item>Eteint<tag>out.action.status="0";</tag></item>
<item>Arrete<tag>out.action.status="0";</tag></item>
</one-of>
 
<item repeat="0-1">
<one-of>
<item>la guirlande<tag>out.action.gpio="25";</tag></item>
<item>la lampe<tag>out.action.gpio="21";</tag></item>
</one-of>
</item>
 
<tag>out.action._attributes.tts = "En cours";</tag>
<tag>out.action._attributes.uri="http://127.0.0.1:8080/sarah/rb";</tag>
</rule>
</grammar>

La définition de la grammaire est très simple. Ici on définit différentes syntaxes qui définiront les arguments passés au script JS. Ici, les mots « Allume » et « Demarre » vont permettre de spécifier le statut souhaité à 1 et les mots « Stop », »Eteint » et « Arrete » permettent de passer le statut à 0. Dans le même esprit, les mots « la lampe » définissent le GPIO numéro 21 et « la guirlande » le GPIO 25.

Et pour finir le fichier rb.js qui est exécuté et qui appellera notre service :

exports.action = function(data, callback, config, SARAH){
  // Retrieve config
  config = config.modules.rb;
  if (!config.rb_http){
    console.log("No link http found for RB");
    callback({'tts' : 'La config est invalide'});
    return;
  }
  console.log('api :'+config.rb_http);
  var url = config.rb_http+'rb.py?s='+data.status+'&i='+data.gpio;
  var request = require('request');
  request({ 'uri' : url }, function (err, response, body){
 
  if (err || response.statusCode != 200) {
    callback({'tts': "L'action a échoué"});
    return;
  }
    callback({'tts' : 'Fait !'});
  });
}

Concrètement, une fois la configuration ( l’adresse HTTP de l’api ) renseignée dans l’interface de S.A.R.A.H., il suffit de respirer un grand coup et de dire : « Sarah, allume la guirlande ».

Bon bidouillage à tous,

Download :
Le plugin S.A.R.A.H. : rb-sarah
(EDIT : Il manquait un paramètre pour le contrôle des GPIOs dans rb.js merci @guiguiabloc)

Source / Lien externe :

L’Apéiseur de script

Bonjour à tous,

Comme beaucoup de gens, j’ai craqué il y a plusieurs mois pour un RaspberryPi. Je m’en sers principalement pour l’utilisation des GPIOs. Le contrôle des différentes entrées/sorties en est vraiment simplifié avec l’utilisation des différentes librairies python. Le problème c’est que c’est simple uniquement en local. Par conséquent, j’ai ajouté une interface HTTP à mes différents scripts de contrôle. A force de l’utiliser et surtout après la découverte du projet S.A.R.A.H, le besoin de rendre mes scripts simplement exécutables depuis un appel HTTP a été décuplé. C’est pourquoi l’idée « d’apéiser » mes scripts a surgit.

Image1

 

L’apéiseur de scripts est disponible ici : https://github.com/bewiwi/py-script et fonctionne très simplement.

Une fois le projet récupéré, il suffit de mettre les scripts dans le dossier « script » du projet et de lancer le script avec la commande suivante :

./start.py

Ensuite on peut facilement exécuter nos différents scripts disponibles dans le dossier en contactant le service (port 8080) avec le nom du script :

#curl "http://127.0.0.1:8080/test.sh?t=23&p=1&c=%20er0er&t=sd"
ok ceci est un test
arg : -p 1 -c er0er -t 23

On constate que les arguments GET sont transformés en paramètres du script. Comme certains l’auront déjà compris, il y a potentiellement un problème de sécurité et de droit. Les scripts sont exécutés avec l’utilisateur qui a lancé le script (attention à root) et les scripts peuvent être exécutés par n’importe qui possédant le lien http.

Le projet est fourni avec le script de test présenté ci-dessus ainsi qu’un script python pour contrôler les GPIOs en sortie que j’utilise personnellement avec le projet S.A.R.A.H que je vous conseille fortement d’aller voir.

Le Libre en entreprise

Le monde des logiciels libres propose de nombreuses solutions performantes pour les particuliers et les entreprises. Or, certaines entreprises restent réticentes à ces outils pour certaines raisons.

Partant de cette conclusion, j’ai fondé mon mémoire de fin d’études sur l’utilisation du Libre en entreprise. Ce document a été écrit à partir de mon expérience dans une entreprise utilisant principalement des logiciels issus de la communauté du Libre. Il a pour principal but de faire changer les mentalités sur le Libre et pourquoi pas vous distraire un peu.

Je vous invite à m’envoyer vos retours concernant ce document par twitter : @bewiwi , mail : contact[at]bibabox.fr ou un commentaire ci-dessous.

Il ne me reste plus qu’à vous souhaiter une bonne lecture

Download : LeLibreEnEntreprise

Lutter contre le SPAM avec DKIM et SPF

Il y a fort longtemps, dans une lointaine galaxie nommée Internet, les serveurs SMTP (Simple Mail Transfer Service) relayaient les e-mails sans poser de questions. Puis les vilains SPAMMEURS ont débarqué et il fallut commencer à tout repenser. Nous allons voir ici comment s’est organisée la lutte contre ces êtres démoniaques et pourquoi il est devenu essentiel de mettre en place des technologies telles que SPF et DKIM pour prouver que les e-mails que vous envoyez proviennent bien de votre serveur SMTP et pas d’un autre.

Quel est le rôle du serveur SMTP dans l’envoi et la réception de mail ? Ce dernier est appelé MTA (Mail Transfer Agent) et il est voué à distribuer les e-mails que vous envoyez à leurs destinataires et à recevoir (stocker d’une manière cohérente sur le serveur) ceux que vous recevez. Le MTA est le seul élément indispensable pour envoyer et recevoir des e-mails, les serveurs POP/IMAP sont des services mis en place pour permettre à l’utilisateur de récupérer les e-mails sur le serveur SMTP à l’aide d’un client (Client lourd : Outlook, Thunderbird, Mail… , Webmail, Smartphone …).

Les serveurs SMTP les plus connus et utilisés sont l’historique Sendmail et ses petits frères Postfix Exim Qmail. Les exemples de configuration que vous pourrez trouver dans la suite de l’article sont issus de Postfix.

Comment le serveur SMTP fait-il pour savoir où acheminer le courrier ? Simple comme bonjour, il interroge la zone DNS du domaine — partie à droite de l’@ dans une adresse mail — qu’il souhaite joindre à la recherche d’un enregistrement MX (Mail Exchanger) qui pointe vers l’IP du serveur mail chargé de collecter le courrier pour ce domaine. Si vous cherchez à envoyer un mail à cam@bibabox.fr, votre serveur SMTP va chercher où envoyer le mail dans la zone DNS de bibabox.fr. Vous pouvez faire le test vous-même à l’aide de la commande Nslookup.

> nslookup -q=mx bibabox.fr

bibabox.fr MX preference = 1, mail exchanger = mx0.ovh.net
bibabox.fr MX preference = 100, mail exchanger = mxb.ovh.net

Vous noterez la présence de deux enregistrements MX qui diffèrent par leur « préférence » ou « priorité ». Ici non plus rien de bien sorcier, on commence par essayer de joindre le serveur avec la priorité la plus basse, et s’il ne répond pas on passe au serveur avec une priorité plus haute jusqu’au premier serveur qui répond. A noter qu’il serait sûrement préférable de laisser tomber les enregistrements MX au profit des enregistrements SRV, qui proposent plus de fonctionnalités, comme la répartition de charge ou encore la possibilité de spécifier le port où est hébergé le service.

Pour l’image, le MTA c’est un peu la poste, la société s’occupe de transférer le courrier d’un bureau de poste (serveur) à un autre en se basant sur votre adresse (e-mail) où le code postal fait office de champ MX permettant de savoir dans quel bureau de poste envoyer le courrier. Le MUA c’est votre facteur, il délivre le courrier qui arrive au bureau de poste dans votre boîte aux lettres (Ordinateur, Téléphone, PDA …). L’intérêt de l’échange de mail sur l’échange postal c’est que l’on peut facilement recevoir le courrier à plusieurs endroits simultanément en laissant une copie du message sur le serveur pour une durée plus ou moins longue.

Tout comme la poste, par défaut le serveur SMTP ne cherche pas à vérifier l’adresse de l’émetteur, ni plus qu’il ne cherche à authentifier la personne utilisant le service. Une bagatelle pour les Spammeurs et autres individus malveillants agissant sur la toile. La première chose à faire est donc d’implémenter les mécanismes de sécurité dont vous avez besoin afin que votre serveur SMTP ne devienne pas un relais-ouvert utilisable par le premier venu. Les systèmes de configuration des serveurs mails disposent de mécanismes permettant d’accepter ou de rejeter l’envoi d’un mail en se basant sur la configuration du client ou sur la destination. Les directives de configuration smtpd_client_restrictions ou smtpd_recipient_restrictions (Postfix) permettent par exemple de faire ce travail. C’est pourquoi la valeur de ce genre de directives est extrêmement importante et ne doit en aucun cas être laissée au hasard. Si votre serveur SMTP est ouvert sur internet, il vous faudra aussi certainement mettre en place un mécanisme d’authentification tel que SASL, afin que seuls les utilisateurs disposant d’une boîte mail — et donc d’un couple login/mot de passe associé — sur votre serveur puissent l’utiliser. Bien entendu, comme en SMTP tout passe en clair et que vous n’avez pas envie que quelqu’un puisse attraper votre mot de passe ou lire les mails que vous envoyez, il faudra mettre en place une surcouche SSL/TLS avec un certificat valide pour avoir enfin un service sécurisé à proposer à vos utilisateurs.

Votre serveur SMTP est maintenant sécurisé et seuls les utilisateurs authentifiés sont autorisés à l’utiliser, le courrier qui en sort peut donc être considéré comme légitime. Mais puisqu’il est possible d’envoyer des mails sans aucune vérification de l’identité de l’expéditeur via n’importe quel serveur non sécurisé, qu’est-ce-qui prouve à votre destinataire que le courrier qu’il vient de recevoir de vous est bien légitime ? Puisque notre serveur est considéré comme digne de confiance, on va donc chercher à établir l’identité du serveur qui a envoyé le message et à vérifier qu’il s’agit bien d’un serveur digne de confiance. C’est exactement le but des enregistrement DNS SPF et DKIM.

SPF (Sender Policy Framework) est une norme de vérification du nom de domaine de l’expéditeur d’un mail, normalisé dans la RFC4408. SPF vise à réduire les possibilités d’usurpation en publiant, dans le DNS, un enregistrement (de type SPF ou, autrefois, de type TXT) indiquant les adresses IP des serveurs qui sont autorisées à envoyer du courrier pour le domaine considéré. Quand le serveur SMTP de destination reçoit le mail, il peut faire une vérification de ce type, auquel cas soit il décide de refuser purement et simplement le mail soit il peut l’accepter tout de même. Il peut encore décider de notifier l’utilisateur — en rajoutant une ligne dans le corps du message par exemple — ou l’administrateur. Plus généralement cela va surtout influer sur le score que l’anti-spam mis en place chez votre destinataire accorde à votre message et c’est ce dernier qui décidera du sort de ce message. La décision à prendre en cas d’échec de la vérification ou d’absence d’enregistrement SPF appartient à la solution mise en place par l’administrateur. Gardez simplement à l’esprit qu’aujourd’hui encore, seul un trop faible pourcentage des domaines comportent un enregistrement SPF avant de rejeter tout les mails qui ne remplissent pas cette condition.

exemple d’enregistrement SPF :

v=spf1 a mx ptr ip4:1.2.3.4 mx:mail.exemple.com ~all

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un mail, normalisé par l’IETF (Internet Engineering Task Force) dans le RFC 4871 pour palier aux faiblesses de SPF. DKIM a été produit par un consortium industriel en 2004. Il intègre et améliore DomainKeys de Yahoo! et Identified Internet Mail de Cisco. Il est à noter que d’autres acteur majeurs de l’Internet et des systèmes d’information ont pris part au projet, IBM, Microsoft, PGP Corporation, Sendmail, StrongMail Systems … Le but final de la solution est le même que pour SPF : lutter contre le spam et l’usurpation d’identité. On trouve des implémentations libres prêtes à être couplées aux principaux MTA. Le projet le plus abouti à ce jour semble être OpenDKIM.

Exemple d’enregistrement DKIM :

mail._domainkey.example.com. IN TXT « v=DKIM1; k=rsa; p=MEwwPQRJKoZIhvcNADAQCQADOwAwOAIxANPpYHdE2tevfEpvL1Tk2dDYv0pF28/f5MxU83x/0b sn4R4p7waPaz1IbOGs/6bm5QIDAQAB »

Mais qu’apporte DKIM par rapport à SPF ?

SPF se base sur des adresses IP — ou des blocs d’adresses IP — pour vérifier la provenance du message. Seulement, et contrairement à ce qu’essaie de nous faire croire le gouvernement français et sa HADOPI , une adresse IP n’est pas une preuve irréfutable, et il est relativement facile ou en tous cas loin d’être impossible d’usurper une adresse IP sur un réseau. Cette technique s’appelle le spoofing. C’est pourquoi on a recours ici à un système cryptographique asymétrique. On génère une paire de clefs, on stocke la clef publique dans un enregistrement de type TXT de la zone DNS concernée, et on stocke bien précieusement la clef privée sur le serveur. A chaque fois que le serveur SMTP va envoyer un mail, il va chiffrer une petite partie du message à l’aide de sa clef privée. A la réception du message, le serveur SMTP qui détecte ce champ va chercher à le déchiffrer avec la clef publique disponible dans la zone DNS du domaine de l’expéditeur. Si l’opération aboutit, il peut alors assurer que le message reçu provient bien d’un serveur possédant la clef privée. Il devient ainsi impossible — sauf cas du vol de la clef privée — d’usurper l’identité d’un serveur SMTP. Ici aussi les décisions qui découlent de la vérification sont à définir par l’administrateur (acceptation, rejet, notification à l’utilisateur ou à l’administrateur …).

Voici comment Gmail notifie ses utilisateurs du résultat de ses tests :

Mais alors pourquoi mettre en place de telles solutions puisque tout le monde ne le fait pas ? Tout da’bord car ça fait clairement partie des « Best Practices ». Ensuite, c’est un geste citoyen qui permet de réduire globalement le fléau qu’est le spam — c’est bien pour cela qu’autant d’acteurs industriels se sont rassemblés autour du projet. Enfin, vous gagnerez de précieux points dans les mécanismes anti-spams mis en place chez vos destinataires, ainsi le nombre de vos messages qui finira dans les boîtes de courriers indésirables se trouvera réduit.

Certes, DKIM et SPF authentifient le domaine, mais quid de la partie gauche, le nom d’utilisateur ? Comment vérifier l’authenticité non pas du serveur qui a envoyé le mail mais de l’utilisateur ? Ici pas vraiment de choix, il vous faudra recourir à un système de chiffrage et/ou de signature de données tel que PGP ou S/MIME pour authentifier le message et assurer ainsi la confidentialité et/ou l’intégrité de la transmission.

Si vous souhaitez vous renseigner un peu plus sur les technologies anti-spam, je vous conseille de faire un tour sur ce site.

http://www.altospam.com/fr/panorama-des-technologies-antispam.php

Raccourciceurs d’URL et nombre de combinaisons possibles

Aujourd’hui un collègue m’a demandé comment fonctionnaient les raccourciceurs d’url tels que bit.ly ou tinyurl et dont une liste quasi-exhaustive est disponible ICI

Effectivement les URL retournées par bit.ly sont du type http://bit.ly/Ux7eFJ soit seulement 6 caractères alphanumériques. On est dès lors en droit de se demander pendant combien de temps il est possible de stocker une URL dans ces conditions car visuellement parlant 6 caractères ça fait peu.

Le principe de fonctionnement d’un raccourciceur d’URL est simple, une base de donnée bien indexée contient les liens URL courtes -> URL longues, puis une page PHP se charge de récupérer la valeur courte passée par l’URL et génère en retour une redirection HTTP HTML ou Javascript vers la page ciblée.

Pour dimensionner le système et générer les URL les plus courtes possibles il faut donc faire un compromis entre le nombre de caractères et le nombre d’URL maximum que l’on souhaite pouvoir gérer. On cherche donc à trouver le nombre de combinaisons possible à partir d’un jeu de caractères donné et du nombre de caractères choisi — Pour le cas de bit.ly nous avons 6 caractères à choisir dans un jeu de 62 caractères ( 26 minuscules + 26 majuscules + 10 chiffres ). Le concept mathématique correspondant à ce problème de logique combinatoire est l’arrangement avec répétition soit comment trouver le nombre de combinaisons possibles où les caractères peuvent être répétés ( tirages avec remise ) et où l’ordre des tirages est significatif ( Ux7eFJ != xUe7JF ). La formule qui permet de résoudre ce problème est extrêmement simple, il s’agit simplement de calculer n^k avec n le nombre de caractères et k le nombre d’éléments du jeu de caractère.

Dans le cas de bit.ly nous obtenons 62^6 = 56 800 235 584 possibilités. On comprend ainsi qu’un faible nombre de caractères suffit à générer un nombre suffisant d’url. Ajoutons à cela les possibilité d’augmenter encore la taille du jeu de caractère en ajoutant les caractères spéciaux — attention ici aux risque d’incompatibilité — en gérant le dédoublonnage — on ne génère pas une nouvelle URL courte si l’URL longue existe déjà en base — en limitant la validité des URL dans le temps ou encore la suppression des plus vielles / moins utilisées des URL lorsque la limite est atteinte.

Exemples pour le jeu alphanumérique ( 62 caractères ) :

62 ^ 2 = 3844 possibilités
62 ^ 3 = 238 328 possibilités
62 ^ 4 = 14 776 336 possibilités
62 ^ 5 = 916 132 832 possibilités
62 ^ 6 = 56 800 235 584 possibilités
62 ^ 7 = 3 521 614 606 208 (3.52 x 10^12) possibilités
62 ^ 8 = 218 340 105 584 896 (2.18 x 10^14) possibilités

Proxy : méthodes de déploiement

 

Bonjour,

En entreprise, utiliser un proxy web devient quasiment obligatoire. Je ne reviendrais pas ici sur l’installation de ce proxy (ici : Squid) mais uniquement sur la méthode de déploiement sur les machines clientes.
A ce jour j’ai recensé 3 differentes méthodes pour diffuser un proxy. Chacune de ces méthodes a des points forts, des points faibles et des coûts différents.

 

Méthode 1 : Gateway
Cette méthode consiste à rediriger tout le trafic de la machine cliente sur le serveur hébergeant Squid. Il faudra dans ce cas autoriser le trafic à ressortir et rediriger le port 80 sur le port d’écoute de Squid. Dans ce cas on peut imaginer que le serveur est aussi un pare-feu. Cette méthode peut être utilisée dans les petites entreprises avec peu de trafic car elle nécessite un serveur passerelle qui peut coûter cher selon la charge qu’il doit subir.
Plus d’information

 

Méthode 2 : GPO/http_proxy
Pour cette méthode on utilisera les très connues GPO pour les postes clients windows et pour les clients GNU/Linux nous utiliserons les variables d’environnements $http_proxy,$https_proxy et aussi $no_proxy. Cette méthode implique que les windows soient inclus dans un domaine et d’avoir un accès sur les machines linux pour affecter les variables.
Plus d’information sur la variable http_proxy

 

Méthode 3 : wpad.dat et proxy.pac
Cette méthode correspond au mode « Détection automatique des paramètres du réseau » de Firefox. En gros le navigateur va chercher sur le réseau un fichier (wpad.dat) qui contient les paramètres d’utilisation du proxy. Cette méthode ne possède pas spécialement de point faible à part sa mise en place plus complexe. Par contre le fichier wpad.dat peut être paramétré de façon très pointue, permettant un filtrage accru.
Plus d’information sur le déploiement wpad

 

Ces méthodes peuvent être contournées par l’utilisateur (surtout si il est root sur sa machine) c’est pourquoi il ne faut pas oublier de couper le port 80 et 443 en provenance de votre réseau sur votre passerelle de sortie.

 

 

Host-Proof Hosting et confidentialité des données sur internet

 

 

Il y a 10 ans, mes données étaient toujours toutes avec moi, sur un disque dur, une clef usb, un ZIP… Aujourd’hui, mes emails sont stockés chez Google avec Gmail et Microsoft avec Live, les documents sont sur Google Docs, le code source sur GitHub ou GoogleCode, mes flux RSS sur GoogleReader, mes données personnelles réparties entre Facebook, Twitter, Deezer, Soundcloud,… et tout ceci continue de plus belle avec l’arrivée de produits comme Dropbox, GoogleMusic,… Maintenant je ne suis même plus capable de vous dire dans quel pays mes données sont réellement archivées, traitées, transmises.

 

Une des problématiques majeures du cloud computing — hors l’accès obligatoire à internet — est la multiplication des logins nécessaires pour accéder à l’ensemble des données que vous avez disséminées un peu partout sur la toile, c’est pourquoi je voulais essayer Passpack.com depuis longtemps. Passpack est un applicatif (site) web dédié à la centralisation et à la gestion de mots de passe qui en proposant des fonctionnalités intéressantes comme le One-Click-Login, la génération de mots de passe aléatoires, le renouvellement ou encore le partage de mot de passe entres utilisateurs, Passpack.com est devenu une des références en la matière.

 

Je ne souhaite pas ici m’étendre sur l’éternel débat du bien fondé ou non de cette solution – à vous de faire votre choix — mais je vais vous présenter le concept cryptographique qu’ils utilisent pour stocker les mots de passe afin que vous puissiez appréhender leur approche : le Host-proof hosting.

 

Comme dit précédemment,  la quantité de données envoyées par un utilisateur en direction de systèmes d’information tiers a été décuplée, mais surtout les utilisateurs sont prêt à faire confiance et à envoyer des données sensibles (numéro de carte de crédit,… ). Vous souvenez-vous il y à encore quelques années, quand la plupart de vos proches trouvaient dangereux de faire un achat sur internet ?

 

On vous rabâche que le « petit cadenas » (HTTPS) signifie que l’échange est sécurisé. Certes la confidentialité et l’intégrité des données durant l’échange client-serveur sont assurées par les technologies SSL/TLS qui permettent de se protéger notamment du sniffing. Mais est ce bien suffisant ? Ce « petit cadenas » doit-il nous donner une totale confiance dans le site ? La réponse est bien évidement non, une fois l’échange terminé les données sont stockées et accessibles en clair aux personnes — qu’elles soient malveillantes ou non — ayant accès à l’infrastructure hébergeant le site.

 

Richard Schwartz, qui a co-développé le concept d’Host-proof hosting nous résume le problème de la confiance en ces quelques mots : « Trust in web applications only extends as far as trust in whoever is hosting it », en français : « La confiance d’un utilisateur pour un applicatif web ne peut excéder la confiance qu’il a pour les gens qui l’hébergent ».

 

L‘Host-proof hosting permet de résoudre ce problème en chiffrant les données sensibles avec une clef connue uniquement par l’utilisateur. Tout le chiffrement est exécuté coté client avant l’envoi des données, les hébergeurs sont donc en possession de données chiffrées qu’ils sont incapables de déchiffrer sans que l’utilisateur ne leur fournisse la clef. De même les données retournées par le serveur sont déchiffrées coté client.

Host-Proof Hosting

 

La sécurité du procédé repose sur les algorithmes, la qualité et la longueur de clef choisie — ce qui reste un compromis entre sécurité, performance et praticité — mais sachez qu’avec de bons paramètres il faudra encore plusieurs milliers d’années pour venir à bout des algorithmes de cryptographie symétriques les plus courants AES, BLOWFISH, RC4 et rendre intelligible les données.

 

Passpack à mis à disposition des développeurs une API Javascript simple et efficace dédiée à la mise en place de ce modèle de sécurité, ça se passe ici.

 

Dans la réalité la sécurité du concept repose sur la qualité de sa mise en œuvre, il faut à tout prix empêcher à quiconque de pouvoir accéder à la clef personnelle d’un utilisateur. En général on a tendance à protéger le serveur des données arbitraires qu’il peut recevoir (injections SQL/PHP/XSS/… ), cependant dans le cas des applicatifs de type Host-proof nous allons aussi chercher à protéger le client puisque c’est lui qui reçoit la sacro-sainte clef. Deux catégories de vulnérabilités s’offrent à nous, celles où l’on attaque directement le client dans ce cas l’attaquant doit récupérer la clef personnelle ainsi que le couple login/mot de passe de sa victime et celles où l’on attaque le serveur. Dans ce cas l’attaquant doit avoir un accès au média où les données sensibles sont stockées ainsi que la clef de l’utilisateur à qui appartient les données.

 

Dans le premier cas c’est à la sécurité de l’environnement de scripting du navigateur — et sur ce point il est juste de s’interroger car ces environnements ne sont pas vraiment réputés pour être sans faille — que l’on va s’attaquer. On veillera ainsi à ce que l’applicatif client soit capable de vérifier lui même son intégrité grâce à une somme de contrôle — stockée sur un ou plusieurs serveurs tiers. Le but est ensuite de limiter les risques au maximum, il serait par exemple de bonne augure de veiller à ne pas stocker la clef en mémoire. Il faut être conscient que le risque-zéro n’existe pas, les Keylogger/Rootkits/Spyware/Phishings/… sont légions et que vous ne pouvez pas directement lutter contre. Il est donc nécessaire d’avertir au maximum l’utilisateur sur ces menaces afin qu’il ne place pas son entière confiance uniquement sur ce concept.

 

Dans le second cas, l’attaquant a déjà réussi à prendre le contrôle du serveur web — tout du moins assez pour pouvoir modifier le contenu qu’il renvoie — et il a aussi accès aux données sensibles — vous pouvez prendre le cas d’un admin malveillant — tout ce qu’il manque à l’attaquant c’est la clef correspondant aux données qu’il souhaite rendre intelligibles. Il doit donc modifier le comportement du site pour que ce dernier lui renvoie la clef lorsque l’utilisateur la saisit soit en modifiant le code HTML — ajout d’un formulaire par exemple — soit en modifiant le code de l’applicatif client. La protection la plus efficace reste la mise en place d’un simple contrôle d’intégrité et de comportement de la page réalisé avec par une machine tierce en continu pour remonter une alerte en temps réel et stopper le service ce qui limite drastiquement les risques de transmission de données. On peut aussi imaginer un mécanisme demandant à l’utilisateur de vérifier lui-même l’intégrité du contenu. On essayera aussi de rendre aussi inintelligible que possible le lien entre les données et l’utilisateur à qui elles appartiennent. L’utilisation de mécanismes distribués permet de mitiger ce type de risque en demandant à l’attaquant de prendre le contrôle de plusieurs systèmes, ce qui se révèle rapidement impossible, qui plus est dans le cadre d’une solution ou la sécurité des données est au cœur des préoccupations.

 

Comment savoir si un site à mis en place une solution de type Host-proof hosting pour protéger mes données ? Ici pas de petit cadenas, à vous de vous faire votre idée et de faire confiance ou non à ce site. Premièrement, le site doit vous demander régulièrement une clef secrète puisqu’il ne la stocke pas, ensuite il va falloir aller voir directement au niveau des données échangées avec le serveur et vérifier que les données sensibles ne passent pas en clair — l’extension Firebug pour Firefox fera merveilleusement bien l’affaire.

 

Le concept est donc viable mais requiert que son implémentation ne laisse « aucune » chance à l’attaquant de récupérer la clef ce qui relève du domaine du possible — le nombre de principe permettant de mitiger suffisamment le risque étant assez élevé — mais demande un travail et une surveillance accrus de la sécurité car la moindre faille peut compromettre tout l’ensemble.

 

LCMP : Linux Cherokee MariaDB PHP un serveur web qui tient la route

Aujourd’hui je vais vous présenter un remplaçant pour le traditionnel LAMP : Linux Apache MySQL PHP.
Historiquement et incontestablement leader du marché de l’hébergement web, l’assemblage LAMP assure aujourd’hui la robustesse et la fiabilité de la toile à travers le monde, cependant il reste toujours intéressant de découvrir les autres technologies disponibles.

Notre but est d’héberger des applicatif web PHP, nous allons évidemment rester sur des technologies compatibles GNU\Linux libres.
Le but ici n’est pas la performance ultime mais plus le confort d’utilisation pour l’admin-web lambda.

Coté serveur web :

Vous connaissez certainement le populaire NGinx comme concurrent à Apache, mais ce serveur HTTP est assez spécifique et surtout utilisé pour délivrer du contenu HTML statique ou servir de reverse proxy. On peut aussi parler de Lighttpd mais son déclin par rapport aux autres solutions — en terme de part de marché — n’est pas des plus rassurant et c’est en prenant en compte le critère confort d’utilisation que je me suis tout de suite tourné vers Cherokee.

Cherokee est un serveur HTTP cross-plateform sous licence GPL écrit en C, il met en avant un design modulaire léger et haute-performance. Innovation intéressante, Cherokee dispose d’une interface web d’administration « cherokee-admin » qui permet de modifier graphiquement la configuration du serveur.

L’exécution de PHP se fait via FastCGI. Contrairement au mod_php5 d’Apache qui intègre directement le langage dans le serveur HTTP sous forme de module, FastCGI est une technique permettant de déléguer la génération de la page demandée à un programme tiers, dans notre cas « php-cgi ». Ceci donne aussi la possibilité à Cherokee de délocaliser et de répartir l’exécution du code sur un ou plusieurs serveurs dédiés.

L’installation se fait grâce au gestionnaire de paquet :

apt-get install cherokee cherokee-mod-rrd cherokee-doc

Vous pouvez d’ores et déjà vous connecter sur le port 80 de votre machine et découvrir le « It’s Works » version cherokee :

Vous pouvez maintenant démarrer l’interface web d’administration et vous y connecter sur le port indiqué ( 9090 ) avec le mot de passe fourni. Lorsque vous aurez fini vos modifications, un « CTRL+C » vous permettra d’arrêter l’interface.

#cherokee-admin -b
Login:
User: admin
One-time Password: goixKrnGLTtV4nZt
Web Interface:
URL: http://localhost:9090/

Cette interface d’administration super-intuitive est aussi simple que complète et vous permet de régler le moindre détail de la configuration de votre serveur web en quelques clics. On y retrouve les principaux paramètres que l’on connait sur Apache et le plus souvent sous la même dénomination. Autant dire que l’on n’est pas trop dépaysé, on trouve en plus des innovations intéressantes telles que le load-balancing php/mysql, un mécanisme permettant de générer des url temporaires jetables pour le téléchargement de fichiers, de nouveaux mécanismes d’authentification comme PAM ( Utilisateurs Système ) ou même une liste user/mdp gérée en dur dans la configuration ; le tout étant, qui plus est, fort bien documenté.

Pour installer le support PHP rien de plus simple, il suffit d’installer le package php-cgi :

#apt-get install php5-cgi php5-mysql

Dans l’onglet vServer (vHost) rajoutez maintenant une règle (Behavior) PHP dans le vServer par défaut ou créez un nouveau vServer de type PHP. Cliquez ensuite sur « sauvegarder » et le serveur vous proposera de redémarrer le service pour charger la configuration.

Cherokee peut collecter des statistiques sur vos différents vServer et vous les restituer sous forme de graphique — uniquement si vous avez installé le package « cherokee-mod-rrd » — ce qui donne une bonne vue d’ensemble de la consommation de bande passante ou du nombre de requête mais ne remplacera absolument pas une vraie solution de monitoring/supervision.

On notera la présence de template de vServer pour les applicatifs web les plus connus que ce soit des CMS (Drupal, Joomla, WordPress), des serveurs d’applications ( Glassfish, ColdFusion ), des plateformes de développement ( Symphony, Zend, Django, RubyOnRails ), des langages de programation ( PHP, .Net avec Mono ) ou encore d’autres applicatifs comme SugarCRM ou PhpBB ainsi que pour les configurations de redirection, proxy, contenu statique, …

Je vous conseille de jeter un coup d’œil à l’aide — disponible uniquement si vous avez installé le package « cherokee-doc ». Plutôt bien construite, elle propose même des liens vers des screencasts détaillants la plupart des fonctionnalités.

Pour conclure, Cherokee est un serveur web très proche d’Apache dans sa philosophie — son nom vous avait peut-être mis la puce à l’oreille — mais extrêmement plus agréable et rapide à configurer. Niveau performance rien à redire pour ce petit serveur web qui s’en sort très bien puisqu’il est souvent présenté comme au moins 2 fois plus rapide que son homologue.

Coté BDD :

Depuis le rachat de MySQL ( Sun ) par Oracle, j’ai envie de me tourner vers MariaDB.
Réalisé par Michael Widenius qui n’est autre que le principal auteur de MySQL, MariaDB actuellement en version 5.2.6 est un Fork libre de MySQL sous licence GPL.

Complétement compatible avec un MySQL de même version , MariaDB propose un nouveau moteur de base de donnée « crash safe » nommé Maria pour remplacer innoDB et MyIASM. Le code de MariaDB a été également optimisé, les requêtes complexes devraient être plus rapides, de nombreux cas d’interblocage sont corrigés et on notera l’arrivée en avance de fonctionnalité comme le « thread pool » prévu pour le futur MySQL 6.0 qui « permet d’ores et déjà de charger les requêtes de façon plus efficace ».

L’installation se déroule le plus simplement du monde après avoir rajouter ce dépôt dans le fichier /etc/apt/sources.list :

# MariaDB repository list
deb http://mirror.switch.ch/mirror/mariadb/repo/5.1/debian squeeze main
deb-src http://mirror.switch.ch/mirror/mariadb/repo/5.1/debian squeeze main

Sans oublier d’importer la clef du dépôt :

apt-key adv –recv-keys –keyserver keyserver.ubuntu.com 1BB943DB

 

Enfin il reste à installer le méta-paquet mariadb-server pour obtenir la dernière version disponible ( ici 5.1 ) :

apt-get update
apt-get install mariadb-server

On essaye de se connecter à la base et normalement tout roule :

root@webserver:~# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 31
Server version: 5.1.55-MariaDB-mariadb98~squeeze-log (MariaDB – http://mariadb.com/)

This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

MariaDB [(none)]>

Bref au niveau de l’installation c’est exactement comme mysql, premier point rassurant pour un admin habitué à ce dernier.

Nous allons maintenant installer PhpMyAdmin et WordPress pour vérifier la compatibilité et la fiabilité de l’assemblage.

PhpMyAdmin :

Primo : télécharger la dernière version des sources sur le site http://phpmyadmin.org

Secondo : les décompresser dans le répertoire de votre convenance ( /var/www/phpmyadmin par exemple).

Tertio : créer un vServer de type PHP pointant sur ce répertoire dans l’interface d’administration Cherokee.

That’s it :)

WordPress :

On récupère directement les dernières sources comme ceci :

wget http://fr.wordpress.org/latest-fr_FR.zip

On les décompresse dans le répertoire de notre choix ( /var/www/wordpress par exemple)

On crée un vServer de type WordPress pointant sur ce répertoire dans l’interface d’administration Cherokee.

On crée une base de donnée WordPress — via phpmyadmin ;) — avec un utilisateur wordpress disposant de tous les droits sur cette base.

Normalement a ce stade, il ne reste plus qu’à se connecter à WordPress pour faire l’installation. Cependant, la valeur par défaut des colonnes de type « date » choisie par wordpress est ’0000-00-00 00:00:00′ — ce qui il faut l’avouer ne représente pas réellement une date concrète — or elle n’est pas acceptée par MariaDB. On va donc remplacer les occurrences de cette date dans le code WordPress avec cette ligne de commande :

cd /var/www/wordpress
find . -type f -name ‘*.php’ -ls -exec sed -i s/0000-00-00\ 00:00:00/1000-01-01\ 00:00:00/ {} \;

Pour les explications détaillées du problème et pour aller plus loin dans la configuration ( passage au moteur de BDD Maria, optimisations,…), c’est ici : http://byte-consult.be/2011/06/07/running-wordpress-nginx/

La « Full Compatibility » assurée par Michael Widenius ne serait elle qu’un mythe ? Rassurez vous, dans 99% des cas vous n’aurez pas le moindre souci.

L’installation se déroule maintenant sans aucun problème :)

Conclusion :

Le test est plutôt réussi, Cherokee-admin est un vrai plus pour l’admin-web et les fonctionnalités supplémentaires qu’il propose sont vraiment intéressantes. MariaDB propose un bon nombre d’options qui permettent d’optimiser la fiabilité du stockage de vos données ce qui est essentiel. Niveau performance — même si ce n’est pas le but premier — on se retrouve devant un système assez léger et plutôt réactif face à la charge, reste à voir si ça pourrait suivre le rythme dans un environnement de production. Personnellement le manque effectif d’utilisateurs m’interdit un déploiement en production car la perte de temps générée par la résolution des problèmes non documentés serait colossale. Par contre je l’ai déjà adopté à la maison et je ne peux que vous conseiller de faire de même ;)