Tag - sécurité

Entries feed - Comments feed

Last entries

Thu 28 Aug 2014

DNSSEC Validator supporte DANE !

Après une mise à jour récente de Firefox, j'ai découvert avec plaisir que le plug-in DNSEC Validator (qui s'appelle maintenant DNSSEC/TLSA Validator) supporte le protocole DANE. Avec ce plug-in, vous pouvez voir que mon domaine www.bentobako.org est correctement vérifié par DNSSEC (et pas par DANE). Ce plug-in est disponible pour les principaux navigateurs du marchés (Internet Explorer, Mozilla Firefox, Google Chrome, Opera et Apple Safari)

DANE (DNS-based Authentication of Named Entities), reposant sur DNSSEC, permet de valider un certificat SSL/TLS d'un serveur web (pour HTTPS), email ou autre sans besoin d'utiliser des « autorités » de certification qui font payer très cher et à la confiance douteuse. En d'autres termes, on n'utilise pas de PKI (Public Key Infrastructure, Infrastructure de clés publiques) mais directement des signatures des certificats dans les champs du DNS, champs eux-mêmes vérifiés pas DNSSEC (on peut aussi combiner PKI et DANE si on veut).

Chacun est maître de son infrastructure et permet à ses « clients » de vérifier qu'ils accèdent bien au bon serveur web, en toute sécurité. C'est à mon avis une petite révolution dans les moyens permettant de chiffrer et authentifier les communications sur Internet : la sécurité gérée de manière décentralisée et à coût zéro. Bien évidemment, le protocole n'est pas encore largement déployé, d'où mon intérêt pour le plug-in DNSSEC/TLSA Validator.

Pour plus de détails sur DANE, lire les excellents comptes-rendus des RFC 6394 et RFC 6698 de Stéphane Brotzmeyer.

Il ne me reste « plus » qu'à configurer tout ça sur mon serveur web. Quelqu'un connaît-il une documentation simple pour faire sa propre autorité de certification avec en plus la configuration de DANE ?

Tue 17 Dec 2013

Book review: Better Embedded System Software

better_embedded_system_software_cover.gif Better Embedded System Software is a very good book if you write software, and not only embedded software!

I discover this book when following the Toyota Unintended Acceleration case where Philip Koopman, the author of this book, was a plaintiff's expert. Philip Koopman is an Associate Professor at the Carnegie Mellon University.

Why is this book so good? Because it explains in daily words what should be the ideal software development process. And not only it details the ideal process, but it gives concrete, down to earth advices on how to improve your current process and software development habits.

The book is divided into 30 small chapters, following the order of the usual V cycle (overall process, requirements and architecture, design, implementation, verification and validation, critical system properties). The chapters are very short, about 10 pages, and relatively independent. This one of the great point of the book: it is easy to read a chapter, there is not need to allocate a long time slot for it. You can pick the chapter that is most interesting to you. And as the chapters are right to the point, you immediately get useful advices and you can immediately start to apply them on your own development.

The other great quality of this book is that the author has a strong background in embedded software development. Therefore the advices are realistic and graduated. The author knows that you are going to find barriers and limitations in your work environment and he helps against them. For example, there are two chapters on producing some documentation but not too much. Even if you cannot apply the whole set of advices, you nonetheless get some ideas on own to improve your current software and what could be done in later steps.

I am not an expert on all the topics presented in this book (that's why I bought it!) but for the domains I knew (e.g. concurrent programming), the advices seem balanced and appropriate.

Of course, 10 pages for a chapter is very short and some subjects are so wide that they would deserve a book on their own (e.g. safety and security). In that case, Koopman's book give useful pointers to continue your reading and the summary he gives is an excellent introduction to the topic.

As I said many times, we are currently making very bad software and we should improve this situation. Better Embedded System Software is the one the very few books that you should keep close to your table and consult on a regular basis.

If you cannot afford the book, some quite detailed slides on Avoiding the 43 Top software risks have been made available by Philip Koopman.

Wed 10 Oct 2012

  • David Mentré
  • Web

Cachez votre utilisation du web, utilisez HTTPS Everywhere

Vous le savez certainement, mais la quasi-totalité du temps, quand vous surfez sur le web, toutes les informations que vous envoyez ou recevez du site web que vous consultez sont consultables par quiconque entre ce serveur et vous. Ce quiconque peut être votre employeur, votre fournisseur d'accès, etc. Il a cependant un moyen de cacher ces informations en utilisant le protocole HTTPS, le "S" étant pour "Sécurisé" par rapport au protocole HTTP que vous utilisez par défaut.

Le problème ? La plupart des sites web, même s'ils offrent un accès en HTTPS à leur site, cachent son utilisation sous le tapis. Tous les parties du site ne sont pas en HTTPS ou vous démarrez en HTTPS mais revenez immédiatement en HTTP standard. C'est là qu'intervient l'extension pour Firefox HTTPS Everywhere développée par l'EFF (Electronic Frontier Foundation), association américaine de défense des droits dans le monde numérique. Cette petite extension possède une petite base de règles qui permet d'utiliser HTTPS dès que c'est possible et notamment sur la plupart des sites courants (Facebook, Google, etc.).

L'installation de cette extension est triviale et elle vous apporte un petit supplément de vie privée. N'attendez pas !

Thu 07 May 2009

Niadomo épisode 3 : installation d'un serveur web et d'un webmail

Ce billet est sous licence Art Libre 1.3.

Après le précédent épisode, nous continuons l'installation de notre serveur d'auto-hébergement. Au programme aujourd'hui :

  • un script pour enregistrer les commandes ;
  • l'installation du serveur web ;
  • l'installation d'un webmail ;
  • accéder à des applications graphiques sur le serveur.

Un ch'tit script pour enregistrer les commandes

Quand on gère à plusieurs un serveur, il est indispensable de garder une trace précise de ce que chacun fait. C'est pour cela que nous avons créé la commande nia-script, à appeler avant de faire toute manipulation sur la machine. Le principe de ce petit shell script est très simple : appeler la commande script en demandant l'enregistrement des commandes dans un fichier nommé d'après la date et l'heure courantes.

Nous créons donc le fichier /usr/local/bin/nia-script qui a le contenu suivant :

#!/bin/sh

nom=$(date +%FT%T)
chemin=/root/nia-scripts
script -t -a 2>$chemin/$nom.time $chemin/$nom.typescript

Les enregistrements de commandes sont faites dans le répertoire /root/nia-scripts/ avec des fichiers de nom du style 2009-05-05T23:14:34.typescript. Nous créons donc ce répertoire de tel sorte que son contenu soit accessible en lecture/écriture uniquement par les membres du groupe adm, c'est à dire les gentils administrateurs bénévoles que nous sommes :

 $ sudo mkdir /root/nia-scripts
 $ sudo chown root:adm /root/nia-scripts
 $ sudo chmod 770 /root/nia-scripts

Après tout ça, avoir de faire quoi que ce soit sur la machine, il suffit de faire..

 $ nia-script

...et toutes les commandes sont maintenant enregistrées.

Installation du serveur web Apache 2

apache_feather.png Pour le serveur web de notre hébergement, nous utilisons très classiquement Apache 2. Nous aurions pu utiliser un autre serveur web plus performant, mais comme nous voulons que chaque hébergé puisse relativement facilement influencer la configuration du serveur relative à son espace personnel, nous pensons que Apache avec ses .htaccess convient bien.

L'installation est on ne peut plus simple :

 $ sudo aptitude install apache2

Petit rappel de la configuration d'Apache 2 dans une Debian :

  • les fichiers qui compose le site web sont dans /var/www/, avec en particulier le fichier /var/www/index.html qui est la page web affichée par le serveur fraichement installé ;
  • les fichiers de configuration spécifique d'Apache doivent être installés dans /etc/apache2/conf.d/ ;
  • les modules disponibles sont visibles dans /etc/apache2/mods-available/ alors que les modules effectivement utilisés par le serveur sont visibles dans /etc/apache2/mods-enabled/ (par des liens symboliques sur les fichiers du répertoire mods-available/) ;
  • de manière similaire, les sites web disponibles sont visibles dans /etc/apache2/sites-available/ alors que les sites web effectivement servis par le serveur sont visibles dans /etc/apache2/sites-enabled/ (par des liens symboliques sur les fichiers du répertoire sites-available/).

Pour activer ou désactiver un module on utilise les commandes a2enmod et a2dismod. De même, pour activer ou désactiver un site on utilise les commandes a2ensite et a2dissite.

Pour améliorer la sécurité de notre serveur, nous décidons de rendre le serveur Apache moins verbeux (il ne donnera plus son numéro de version) et de désactiver certaines commandes inutiles du protocoles HTTP en utilisation courante (TRACE qui peut être utilisé pour des attaques). Pour ce faire nous éditons le fichier de config' après en avoir fait une sauvegarde préalable[1] :

 $ mkdir -p /root/etc/apache2/conf.d/
 $ cp /etc/apache2/conf.d/security /root/etc/apache2/conf.d/security.2009-05-04
 $ sudo vi /etc/apache2/conf.d/security

Et nous modifions son contenu pour avoir la configuration suivante :

 ServerTokens Prod
   :
 ServerSignature Off
   :
 TraceEnable Off

Un petit redémarrage du serveur permet de prendre en compte la configuration :

 $ sudo invoke-rc.d apache2 reload

Une hiérarchie web par utilisateur

Pour faciliter la mise à jour de contenu de nos membres auto-hébergés, nous utilisons une configuration assez classique où le contenu du répertoire ~/public_html/ de l'utilisateur toto est accessible à l'URL http://niadomo.net/~toto/.

Pour réaliser cette configuration, il suffit juste d'activer le module Apache userdir !

 $ sudo /usr/sbin/a2enmod userdir
 $ sudo invoke-rc.d apache2 restart

Et voilà ! ;-)

Serveur web accessible en connexion sécurisée HTTPS

Nous voulons pouvoir accéder de manière sécurisée à notre serveur web, en particulier pour les données sensibles comme le webmail ou les authentification. Nous utilisons pour se faire le module Apache ssl et le site web default-ssl (inactif par défaut). Nous n'avons pas le temps de configurer les redirections de HTTP vers HTTPS (pour éviter les erreurs de manipulation) donc pour l'instant notre serveur web sera accessible uniquement en HTTPS (en désactivant le site web par défaut : default).

 $ sudo /usr/sbin/a2enmod ssl
 $ sudo /usr/sbin/a2ensite default-ssl
 $ sudo /usr/sbin/a2dissite default
 $ sudo invoke-rc.d apache2 restart

Nous vérifions que notre site web est toujours accessible à l'URL https://niadomo.net.

Configuration du webmail SquirrelMail

squirrelmail_logo.png Comme webmail, nous avons décidé d'installer SquirrelMail. Nous aurions préféré RoundCube ou un autre webmail plus moderne mais RoundCube n'est pas disponible comme paquet Debian dans Lenny. Donc nous avons choisi la voie de la facilité. ;-)

L'installation est simple :

 $ sudo aptitude install squirrelmail

La configuration est tout aussi simple :

 $ sudo squirrelmail-configure

Dans le menu de configuration qui apparait, nous choisissons :

  • la configuration pré-réglée pour Dovecot, notre serveur IMAP : choix « D » puis « dovecot », puis « R » pour revenir au menu principal ;
  • nous installons les plugins suivants par le menu « Plugins » :
    • mail_fetch
    • newmail
    • filters
    • message_details
    • squirrelspell
    • calendar
    • administrator
    • spamcop
  • nous configurons pour que le logiciel soit en Français par défaut par le menu « Languages »
    • Default Language: fr_FR
    • Default charset: iso-8859-1

Pour le reste, nous conservons la configuration par défaut. Un petit « S » pour sauvegarder la configuration et « Q » pour quitter l'utilitaire squirrelmail-configure.

Pour que la traduction française fonctionne, il faut que la locale ISO-8859-1 soit disponible. Nous l'ajoutons donc à notre configuration :

 $ sudo dpkg-reconfigure locales

On a choisit d'ajouter toutes les locales françaises :

  • fr_FR
  • fr_FR.UTF-8
  • fr_FR@euro

Il faut ensuite configurer Apache pour qu'il serve maintenant le site SquirrelMail, ce qui se fait avec un simple lien :

 $ sudo ln -s /etc/squirrelmail/apache.conf /etc/apache2/squirrelmail.conf

Une dernière modification de sécurité ! Par défaut, SquirrelMail est accessible à l'URL standard http://niadomo.net/squirrelmail. Pour éviter les attaques trop aisées, nous utilisons une autre URL par défaut, par exemple « monecureuil ». Pour se faire il faut modifier le fichier de configuration Apache de SquirrelMail :

 $ sudo vi /etc/squirrelmail/apache.conf

Et y modifier la première ligne en :

 Alias /monecureuil /usr/share/squirrelmail

Un petit coup de redémarrage d'Apache ...

$ sudo invoke-rc.d apache2 restart

... et normalement notre nouveau webmail est accessible à l'URL http://niadomo.net/monecureuil.

Vérification de la configuration de SquirrelMail

La documentation de SquirrelMail[2] nous indique que l'on peut vérifier en local (c.-à-d. sur le serveur) la configuration de SquirrelMail en accédant à l'URL src/configtest.php :

 $ lynx https://127.0.0.1/monecureuil/src/configtest.php

Ce test nous indique que la configuration PHP5 magic_quotes_gpc doit être désactivée, ce que nous faisons :

 $ sudo vi /etc/php5/apache2/php.ini

Et nous modifions la ligne suivante en Off (au lieu de On) :

 magic_quotes_gpc = Off

Et voilà, nous avons maintenant un serveur web personnel et un webmail sécurisé à disposition ! Alors, c'est si difficile que ça l'auto-hébergement ? ;-)

Configuration pour utiliser une application graphique sur le serveur

Habituellement, sur un serveur, on ne met aucune application graphique et on utilise des éditeurs en mode texte comme vi ou nano pour éditer les fichiers de configuration. Quel que soit le système Unix que vous utiliserez, vous aurez toujours l'éditeur vi[3] à disposition donc il est recommandé de savoir au moins éditer trois lignes avec. ;-)

Mais bon, quand on débute, c'est parfois un peu compliqué donc voici les manipulations à faire pour pouvoir accéder à des applications graphiques (c.-à-d. utilisant le serveur X) sur votre serveur.

En premier lieu, installer le paquet xauth :

 $ sudo aptitude install xauth

Ensuite, lors de votre connexion en ssh sur le serveur, utilisez les options -X pour demander la propagation (forwarding) du terminal graphique X[4] et -C pour la compression :

 ssh -C -X toto@lumturo.niadomo.net

Et voilà, vous pouvez maintenant utiliser l'éditeur graphique qui vous convient, par exemple scite :

 $ sudo aptitude install scite
 $ sudo scite /etc/squirrelmail/apache.conf

Mais je le répète, c'est mieux d'apprendre les rudiments de vi et de se souvenir qu'il a deux modes : le mode qui bippe et le mode où l'on massacre son fichier. :-D

  • MàJ 2009-05-10: Ajout de la licence Art Libre pour ce billet.
  • MàJ 2009-08-18: correction typo.

Notes

[1] Nous utilisons pour l'instant une hiérarchie parallèle de fichiers de configuration dans /root/etc/... Une autre méthode plus robuste avec un gestionnaire de version sera utilisée par la suite.

[2] Documentation du paquet squirrelmail accessible dans /usr/share/doc/squirrelmail/README.Debian.gz.

[3] vi vient de Visual Editor. Ça peut vous surprendre mais vous n'avez jamais utilisé ed. ;-)

[4] Cela suppose que vous avez bien l'option X11Forwarding yes dans le fichier /etc/ssh/sshd_config de votre serveur.

Mon 20 Apr 2009

Faut-il repenser nos systèmes d'exploitation ?

Un système d'exploitation, c'est, à la louche, la grosse couche de logiciel entre le matériel et les applications. Il permet à ces applications de ne pas de soucier du matériel sous-jacent (peut importe le modèle de votre disque dur par exemple) et d'utiliser des interfaces standardisées pour dialoguer avec le matériel. Mais surtout, le système d'exploitation fournit des services utiles à un grand nombre d'applications :

  • contrôle du matériel : processeurs, disque dur, mémoire, etc. ;
  • système de fichier, pour organiser documents en fichiers et répertoires ;
  • pile réseau, pour accéder à Internet et toutes ses applications ;
  • contrôle des périphériques d'entrée/sortie : clavier, écrans, souris, cartes son, périphériques USB, etc.
  • etc.

Les systèmes d'exploitation libres (noyau Linux, noyaux *BSD) offrent peu ou prou les mêmes fonctionnalités, avec quelques avancées ici et là (par exemple un meilleur support des multi-processeurs). Mais fondamentalement, ils font tous la même chose, en s'en tenant aux principes des systèmes Unix définis dans les années 70 et en ajoutant quelques fonctionnalités liées à l'évolution du matériel, comme le branchement à chaud des périphériques.

Cependant, notre environnement informatique a évolué beaucoup ces dernières années et on peut s'interroger sur l'adéquation de nos systèmes avec ces évolutions. Ne faudrait-il pas re-penser nos systèmes d'exploitation de A à Z ?

Quelques pistes de réflexions.

La confidentialité des données sur nos machines. Pour protéger nos données d'accès indiscrets, il est nécessaire de chiffrer nos données sur nos disques durs, clés USB, mémoires flash, courriels, etc. Pour l'instant, c'est fait de manière plus ou moins ad-hoc, avec logiciels spécialisés comme GnuPG, des solutions uniques comme dans Firefox ou des couches logiciels comme encfs ou eCryptfs utilisé dans Ubuntu Jaunty pour chiffrer les répertoires personnels. Mais on devrait plutôt avoir une réflexion plus générale sur la confidentialité : comment la garantir ? Comment gérer les sauvegardes ? Comment gérer la pertes de mots de passe ? Comment les applications doivent être conçues pour garantir cette confidentialité ? Comment échanger des données de manière sûr au travers du réseau ? etc. Comme toutes les applications doivent gérer cette confidentialité, le système d'exploitation devrait avoir un rôle majeur, en fournissant des interfaces adaptées et simples d'emploi pour que le programmeur d'application offre une confidentialité satisfaisante sans être un spécialiste.

Les sauvegardes. La sauvegarde est une fonctionnalité de base en informatique : aucun système n'est fiable, aucun périphérique de stockage n'est pérenne. Qui n'a jamais perdu une version d'un document important maladroitement écrasée après une journée de travail ? Là aussi, le système d'exploitation devrait offrir un système de base rendant ces sauvegardes complètes, transparentes, efficaces et d'accès aisés. Un système de fichier récent comme ZFS va dans ce sens en offrant par exemple l'accès à différentes version d'un fichier ou d'un répertoire dans le temps.

La confidentialité des données sur le réseau. De plus en plus fréquemment, les données échangées sur Internet sont espionnées, analysées, pour des motifs « légitimes » ou délictueux. Toutes les applications communicantes doivent maintenant se prémunir contre les oreilles indiscrètes, tout en garantissant que les personnes ou serveurs à qui on envoie ou de qui on reçoit nos données sont bien les bonnes. Le système d'exploitation n'a-t-il pas son rôle à jouer ? Il pourrait centraliser les authentifications, qu'elles concernent le Web ou le courriel. Il pourrait garantir que des courriels adressés à certaines personnes soient obligatoirement chiffrés, indépendamment de l'application et d'éventuels oublis. Il pourrait chiffrer de manière opportuniste ses connexions avec d'autres ordinateurs, et ce de manière transparente pour l'utilisateur.

Le transfert des données en « zéro copie ». Lorsqu'on regarde un peu l'organisation d'un système d'exploitation, on est étonné du nombre de copies faites d'un même morceau de données. Une donnée est parfois copiée 3 à 4 fois pour passer par exemple d'un périphérique USB à une application utilisatrice, et ensuite de nouveau 2 à 3 fois pour être envoyée sur le réseau à partir de cette même application. Toutes ces recopies mémoires nuisent à la performance et consomment des ressources inutilement. Évidemment, sur nos PC sur-puissants, on ne s'en rend pas bien compte. Mais sur des plateformes légères comme les applications embarquées (PDA, netbook, lecteurs multimédias divers), le surcoût de telles recopies inutiles apparait plus clairement. C'est le système d'exploitation qui devrait fournir un système unifié d'échange de données sans recopies, à l'intérieur du système d'exploitation, entre le système et les applications et entre applications.

La gestion du multimédia. Le multimédia et les données temps réelles sont omniprésentes dans nos applications, venant de webcam, de micros, affichés dans des mini-vidéos de YouTube, etc. Le système d'exploitation devrait fournir des infrastructures qui garantissent que les médias sont correctement acheminés et synchronisés entre eux, que ce soit en local sur une machine ou entre différentes machines.

Je n'ai fait qu'esquisser quelques pistes de réflexions. Il y en a bien d'autres. Mon propos n'est pas d'être exhaustif ni exact (est-ce toujours le rôle du système d'exploitation ? Ou des bibliothèques ?) mais de titiller la réflexions de ceux qui s'intéressent à ce genre de problème. L'autre question importante, c'est comment intégrer cette réflexion dans les systèmes d'exploitation existants. Je vois mal refaire l'équivalent du noyau Linux à partir de zéro. Ou alors... ;-)