Sygus.net

Aller au contenu | Aller au menu | Aller à la recherche

samedi, janvier 14 2012

Netzob : un outil de rétro-conception de protocoles de communication

Ce billet pour vous annoncer la sortie d’un outil libre de rétro-ingénierie de protocoles de communication : Netzob*. Il s’agit d’un projet sur lequel je travaille depuis plusieurs mois avec un collègue de travail (@Lapeluche), et qui vient combler un vide apparent en termes d’outils publics d’analyse de protocoles propriétaires.

Plusieurs cas d’usages sont visés à travers cet outil :

  • le développement d’une implémentation libre d’un protocole de communication propriétaire (ou non documenté) ;
  • l’analyse de sécurité (fuzzing “intelligent”, avec compréhension du protocole) sur des implémentations de protocoles propriétaires ;
  • la simulation de trafic réaliste de protocoles de communication propriétaires dans le but de tester des produits tiers (pare-feux, IDS, …) ;
  • l’analyse de flux de communication inconnus à la recherche de données sensibles ;
  • etc.

La version actuelle (0.3.1) fonctionne sous Linux, et implémente déjà pas mal de fonctionnalités permettant de capturer des messages depuis différentes sources, d’identifier le format des messages (inférence du vocabulaire) ainsi que la machine à états d’un protocole (inférence de la grammaire).

Les protocoles visés par cet outil ne sont pas simplement des protocoles réseau. L’objectif est de supporter un maximum de canaux de communication, comme le montre la figure suivante. Actuellement, l’outil support les flux réseau, les fichiers PCAP, les flux inter-processus et les fichiers structurés.

Flux de communication

Quelques slides présentent brièvement l’outil, les mécanismes et les algorithmes sous-jacents. Il existe également une petite vidéo présentant un panorama des fonctionnalité de Netzob (capture de données à partir d’un fichier, inférence du vocabulaire, construction de la grammaire puis simulation de trafic) sur un cas simple :

http://vimeo.com/34964757

Les infos utiles :

(*NETwork protocol modeliZatiOn By reverse engineering.)

samedi, juin 12 2010

SSTIC 2010 : quelle orientation pour la sécurité ?

Le SSTIC 2010 s'est terminé sur une remarque intéressante concernant la tendance qu'à la communauté de la sécurité à privilégier la recherche de vulnérabilité au détriment de l'élaboration de systèmes réellement sécurisés. Je pense qu'il faut distinguer deux choses :

  • la vision court terme : l'analyse de sécurité d'un système spécifique (site web, applications, COTS, etc.) et la nécessité, pour faire bouger les choses, de démontrer que des vulnérabilités sont effectivement exploitables ;
  • la vision moyen/long terme : la nécessité de créer des cadres sécurisés dans lesquels des erreurs de développement ou d'utilisation ne mettent pas en péril la sécurité des systèmes.

Je crois moyennement à l'éducation des utilisateurs et des développeurs aux bonnes pratiques de sécurité (hormis à quelques règles de base, et encore...). Même après de nombreuses séances de sensibilisation, de formation, ou de démonstration, par l'exemple, de l'existence de vulnérabilités, il restera toujours quelques personnes qui coderont avec les pieds, introduisant alors une faille dans le système. Bref, l'éducation de 100% des gens aux bonnes pratiques me semble illusoire comme objectif et comme horizon pour que la situation s'améliore significativement.

Il faut plutôt considérer les utilisateurs et développeurs d'applications comme des sources potentielles de vulnérabilités. Je pense donc que le petit monde de la sécurité doit avant tout s'atteler à créer des cadres dans lesquels les utilisateurs et les développeurs peuvent se tromper, faire des erreurs, sans mettre en péril la sécurité des systèmes. Autrement dit, créer des systèmes tolérants aux failles et créer des environnements de développement empêchant de coder avec les pieds. Les différents guides de bonnes pratiques et de recommandations sont biensur intéressants et nécessaires. Cependant, un vrai environnement de développement sécurisé devrait être capable d'imposer de lui-même ces règles. La porte dérobée introduite involontairement dans le challenge SSTIC est un exemple typique d'erreur de développement. Un environnement de développement sécurisé devrait être capable de détecter, par exemple, de telles mauvaises utilisations d'API crypto.

Pour des systèmes tolérants aux failles, il s'agit notamment d'atténuer le risque d'exploitation. Voici quelques exemples de mécanismes ou de pistes qu'il est pourtant possible de mettre en place pour tenter de se protéger des programmes vulnérables :

  • activer les différents mécanismes qui rendent difficiles les exploitations en mémoire (bit NX, DEP, PaX, ASLR, canaris, UDEREF, etc.) ;
  • mettre en place ces mêmes mécanismes au niveau noyau ;
  • sandboxer les processus (chroot, SECCOMP) et les drivers (avec l'IOMMU) ;
  • limiter les droits des processus (capabilities sous Linux, etc.) ;
  • sortir des systèmes monolithiques (dont la moindre faille dans un driver ou une sous-partie obscure du noyau expose l'ensemble du noyau), pour utiliser des OS à base de micro-noyau (L4, Hurd, Coyotos, etc.) combinant les principes de moindre privilège et de minimalité ;
  • etc., etc. ;
  • d'autres mécanismes restent encore à imaginer !

Il existe des OS ou des prototypes d'OS durcis (Qubes, Gentoo Hardened, SeL4, etc.). Ces exemples doivent devenir la norme dans les futurs déploiements ou devenir la base de travail pour les futurs OS opérationnels.

mercredi, juin 3 2009

La mémoire sous Linux : analyse de /dev/mem

Le système de fichiers /dev sous Linux offre un moyen élégant d'accéder directement aux périphériques d'une machine, et notamment à sa mémoire physique par l'intermédiaire de /dev/mem. L'objectif de ce billet est de présenter le fonctionnement de /dev/mem sur un Linux 2.6.26-2 tournant sur une architecture x86 32 bits, et de voir quelles sont les différentes restrictions d'accès.

/dev/mem offre un accès direct à la mémoire physique du système (mémoire RAM, mémoire graphique, BIOS, etc.). L'analyse de ce fichier peut être facilitée par la lecture d'un autre fichier spécial, /proc/iomem, qui présente le mapping des périphériques au sein de la mémoire physique. Le mapping sur le système étudié est le suivant :

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cffff : Video ROM
000e0000-000e17ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-3ffeffff : System RAM
00100000-002ba4ea : Kernel code
002ba4eb-0037661f : Kernel data
003bc000-0041f57f : Kernel bss
...

Autrement dit, le BIOS est accessible dans l'espace d'adressage physique 0x000f0000-0x000fffff, la mémoire graphique est mappée dans 0x000a0000-0x000cffff, et la mémoire RAM, mappée à partir de 16 Mo (c'est à dire dans la ZONE_NORMAL et dans la ZONE_HIGHMEM : voir cet ancien article), est atteignable entre 0x00100000 et 0x3ffeffff. Ce dernier espace fait 1 Go. Ca tombe bien, c'est précisément la taille de la mémoire RAM de la machine :

$ cat /proc/meminfo 
MemTotal:      1036084 kB
...

/proc/iomem nous informe également de l'emplacement du code du noyau et de ses segments de données .data et .bss. Les éléments du noyau (code et données) sont donc directement accessibles en lecture et en écriture par /dev/mem. Biensur, n'importe qui ne peut pas lire ce périphérique : il faut soit être root, soit donner la bonne capability à un processus non-root. Ce dernier cas de figure est typiquement adapté pour le serveur graphique X, qui dépend de /dev/mem pour récupérer des informations liées à la carte graphique, et dont son exécution avec les privilèges root n'est pas nécessaire (hormis pour l'accès à dev/mem). Il suffit de lui donner la capability CAP_SYS_RAWIO, qui autorise, notamment, l'accès à /dev/mem. Ensuite, il faut placer l'utilisateur exécutant le serveur X dans le groupe kmem. L'exemple suivant illustre la mise en place d'une capability propre à l'exécutable dd, lui permettant de lire dans /dev/mem sans la nécessité d'être exécuté en root.

$ cp /bin/dd /tmp/dd
$ sudo setcap cap_sys_rawio=ep /tmp/dd
$ cat /etc/group
...
kmem:x:15:sygus
...
$ /tmp/dd if=/dev/mem of=/tmp/mem.dump 
1835008+0 enregistrements lus
1835008+0 enregistrements écrits
939524096 bytes (940 MB) copied, 17,7379 s, 53,0 MB/s

L'accès à l'intégralité de la mémoire n'est néanmoins pas pertinent d'un point de vue sécurité : la compromission d'un processus root ou d'un processus ayant la capability CAP_SYS_RAWIO peut permettre à un attaquant d'accéder directement à tout le noyau. Il est heureusement possible de configurer Linux pour limiter l'accès à /dev/mem uniquement au premier Mo de mémoire physique et seulement aux pages mémoire ne correspondant pas à de la RAM (ce qui est suffisant pour faire tourner X). C'est d'ailleurs le comportement par défaut sur Ubuntu, mais pas sur Debian Lenny. La restriction d'accès au premier Mo s'active avec l'option CONFIG_NONPROMISC_DEVMEM introduite sur le 2.6.26 (ou CONFIG_STRICT_DEVMEM sur les versions de Linux depuis le 2.6.27) lors de la compilation du noyau. Voici le résultat d'une tentative de lecture de l'ensemble de /dev/mem :

$ sudo dd if=/dev/mem of=/tmp/mem2.dump 
dd: reading `/dev/mem': Operation not permitted
2056+0 records in
2056+0 records out
1052672 bytes (1.1 MB) copied, 0.149356 seconds, 7.0 MB/s

Hop, bloqué au premier Mo... Ou plus exactement au bout de 256+1 pages mémoires ; la dernière page mémoire étant considérée comme appartenant au BIOS par certains systèmes.

Il existe d'autres mécanismes restreignant l'accès à /dev/mem. Citons le patch GrSecurity qui intègre une protection de l'accès à /dev/mem : il empêche l'accès en écriture sur l'ensemble de la mémoire physique. GrSecurity réalise cependant une exception pour le processus correspondant au serveur X.

Bref, bien que /dev/mem ait longtemps été considéré comme une trou de sécurité important, il est possible de limiter de manière importante ses droits d'accès à la mémoire système (option CONFIG_STRICT_DEVMEM du noyau), ou de limiter l'accès en écriture (patch GrSecurity).

dimanche, juin 8 2008

La mémoire sous Linux : cartographie de la mémoire

La version 2.6.25 du noyau Linux a vu l'apparition d'une série de patchs écrits par Matt Mackall, qui permettent de connaitre précisément le mapping entre les pages virtuelles et les pages physiques, et tout ceci au niveau userland. Cela se fait par l'intermédiaire des fichiers spéciaux /proc/PID/pagemap, /proc/kpagecount et /proc/kpageflags. Le premier indique les adresses des pages physiques utilisées par un processus précis. Le second montre, pour chaque page physique, le nombre de pages virtuelles qui pointent dessus. En effet, la pagination permet de faire correspondre à une même page physique plusieurs page virtuelles appartenant à des processus différents. Enfin, /proc/kpageflags permet de connaitre le statut d'une page mémoire, qui peut être une combinaison des flags suivants :

#define KPF_LOCKED     0
#define KPF_ERROR      1
#define KPF_REFERENCED 2
#define KPF_UPTODATE   3
#define KPF_DIRTY      4
#define KPF_LRU        5
#define KPF_ACTIVE     6
#define KPF_SLAB       7
#define KPF_WRITEBACK  8
#define KPF_RECLAIM    9
#define KPF_BUDDY     10

Avec toutes ces infos, il est possible d'établir une cartographie de l'utilisation de la mémoire vive. C'est ce que fait l'outil Pagemap-Demo, développé par le même auteur que ces patchs. Le graphique suivant montre la mémoire virtuelle d'un processus (en l'occurence, firefox). On peut voir le segment de code (le ptit truc tout en haut à gauche), ainsi que le tas (le rectangle du haut), le pile et les différentes librairies (en bas). La correspondance avec le nom des segments est faite en lisant les informations délivrées par le fichier /proc/PID/maps. Il suffit donc de survoler un segment pour connaitre à quoi il correspond et sur quelle adresse nous sommes.

/proc/PID/pagemap

Le graphique suivant représente le même processus, firefox, mais après avoir ouvert de nombreux sites web. Le jaune indique les pages les plus récemment ajoutées.

/proc/PID/pagemap

Maintenant, on passe à l'affichage d'une cartographie de la mémoire physique :

/proc/kpagecount

Enfin, on peut connaitre clairement comment la mémoire est utilisée :

/proc/kpageflags

  • En blanc : les objets utilisés par l'allocateur slab au sein du noyau.
  • En rose : les pages ayant le flag dirty activé.
  • En bleu : les pages utilisées par l'algorithme LRU (Least Recently Used).

Le patch permet également de connaitre la quantité de mémoire physique partagée entre différents processus ainsi que la mémoire physique utilisée uniquement par un processus. Ceci permet d'obtenir une nouvelle valeur, le PSS (Proportional Set Size), qui indique le nombre de pages mémoires divisé par le nombre de processus qui l'utilisent. Une information pertinente pour évaluer la quantité de mémoire utilisée par un processus.

samedi, juin 7 2008

SSTIC 2008 : la sécurité s'invite à Rennes

Frédéric Guihéry Le microcosme de la sécurité informatique avait rendez-vous les 4, 5 et 6 juin à l'université de Rennes 1 pour une nouvelle édition du SSTIC. L'occasion pour des personnes d'horizons divers d'échanger et de présenter leurs recherches. Comme chaque année, et ce depuis 6 éditions (la 3ème pour moi), l'équipe du SSTIC nous propose une brochette de conférences couvrant les principaux thèmes de la sécurité des systèmes d'information : un peu d'organisationnel et de juridique, des présentations de projets (ERESI, GenDbg, SinFP) et pas mal d'analyses techniques avec aussi bien de la crypto, de la virologie, du reverse que des attaques matérielles, applicatives ou systèmes. L'accent a été clairement mis sur les techniques d'analyses statique et dynamique de code avec des conférences sur des méthodes de rétroingénierie et de déboguage noyau/processus. Des techniques très intéressantes, qui servent aussi bien les intêrets des attaquants (compréhension des vulnérabilités en analysant les patchs de sécurité) que des défenseurs (analyse de malwares pour comprendre comment ils se propagent sur nos systèmes).

En vrac, les points à retenir (ou pas...) :

  • la possibilité de faire évader de l'information grace aux variations de la vitesse de rotation sur les ventilos des processeurs.
  • Debian en a pris pour son grade à propos de la faille OpenSSL.
  • ivanlef0u n'est pas un bot IRC.
  • le bus Firewire doit définitivement être supprimé sur les machines. Bon ok, l'accès à la mémoire physique par DMA n'est pas nouveau, mais les utilisations possibles sont assez sympas.
  • il faut tout faire pour éviter les zombies.
  • le piégeage de processeur offre pas mal de possibilités d'attaques. Mais bon, si on va dans ce sens, on peut imaginer tout un tas de backdoor matérielles. A mon sens, l'hypothèse de départ est quand même à la limite d'être réaliste.
  • stopper les grands réseaux d'envois de spams/malwares est une utopie à partir du moment ou certains domaines et/ou plate-formes d'hébergements se situent dans des zones juridiquemet inatteignables.
  • chez INL, ils s'amusent plutôt bien.
  • le patch pour l'attaque de -nikoteen est le suivant : "so strong, that I can't get through". Et ça marche !!

Un point important cette année, est la volonté de pas mal d'équipes de recherche de diffuser librement les sources de leurs projets. Je pense notamment aux projets ERESI et SinFP, de même qu'à plusieurs outils présentés pendant les rumps sessions. De plus, en regardant les portables présents dans le public, il est frappant de voir qu'un bon nombre utilisent des OS libre, typiquement Linux, avec une majorité de Debian et d'Ubuntu. Il est donc clair que la communauté du logiciel libre est plutôt bien représentée dans le monde de la sécurité. J'ai d'ailleurs croisé quelques têtes aperçues au FOSDEM et aux RMLL.

Plus généralement, il est intéressant de voir que la sécurité "ouverte", par opposition à la sécurité par l'obfuscation, est prédominante dans ce genre de conférence. Le logiciel libre a donc un rôle important à jouer, aussi bien pour assurer l'indépendance technologique d'un état ou d'une société vis-à-vis de solutions propriétaires étrangères, que pour permettre une maîtrise du code exécuté, ce qui est d'autant plus important pour des solutions de sécurité. Et quoi qu'en disent les détracteurs du logiciel libre, qui ne se privent pas de rappeler leurs limites comme dans le cas de la faille OpenSSL/Debian, il n'est pas certain qu'une boîte diffusant un logiciel propriétaire similaire aurait annoncé publiquement et aussi rapidement les détails et les implications d'une telle vulnérabilité. Laissant ainsi leurs utilisateurs dans la méconnaissance du risque qu'ils encourent.

Le contexte légal et politique s'est également fait sentir lors de ce SSTIC, mais moins que l'an dernier, avec quelques remarques et questions du public concernant notamment les limitations que la loi nous impose quant aux investigations sur des binaires. En effet, la loi n'autorise le desassemblage que dans une optique d'intéropérabilité logicielle... et même pas matérielle (!). A ce sujet, je me demande si l'auteur d'un malware peut attaquer en justice une boîte qui aurait desassemblé son programme afin d'en étudier son mécanisme... Bref, qu'en est-il des labo de recherche par exemple chez EADS ou au Celar et de leur légitimité à faire du reverse ? Les intervenants du Celar ont malheureusement rapidement éludé la question.

Finalement, nous avons eu un SSTIC très bien organisé (avec une amélioration notable de l'enregistrement du mecredi matin !), une très bonne ambiance, que se soit pendant les confs, pendant les rumps ou lors du social event. Dommage que beaucoup soient repartis sur Paris rapidement, car la soirée du vendredi soir était... mémorable :)

vendredi, avril 25 2008

La mémoire sous Linux : analyse du fichier /proc/meminfo

Dans cet article, je vais tenter d'expliquer les différentes informations que le noyau Linux nous donne au travers du fichier /proc/meminfo. Comme support, je vais afficher les données qui concernent mon système. Il s'agit d'un noyau 2.6.24-1 dans une Debian unstable. Ma machine repose sur une architecure x86 en 32 bits et contient une barrette de 1 Go de mémoire RAM.

$ cat meminfo 
MemTotal:      1036256 kB
MemFree:        191256 kB
Buffers:         51824 kB
Cached:         468392 kB
SwapCached:           0 kB
Active:         398852 kB
Inactive:       404108 kB
HighTotal:      131008 kB
HighFree:          256 kB
LowTotal:       905248 kB
LowFree:        191000 kB
SwapTotal:      524280 kB
SwapFree:       524280 kB
Dirty:              44 kB
Writeback:           0 kB
AnonPages:      282736 kB
Mapped:          82108 kB
Slab:            22552 kB
SReclaimable:    14468 kB
SUnreclaim:       8084 kB
PageTables:       2232 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1042408 kB
Committed_AS:   880596 kB
VmallocTotal:   114680 kB
VmallocUsed:      7540 kB
VmallocChunk:   105972 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     4096 kB

Commençons par les premières lignes :

  • MemTotal : la quantité de mémoire vive utilisable (ma barrette fait 1 Go (1 073 742 Ko), mais il y a quelques Mo réquisitionnés par le noyau (visiblement 12 615 Ko)).
  • MemFree :la quantité de mémoire vive actuellement non allouée.
  • Buffers : la quantité de mémoire vive actuellement allouée dans des buffers.
  • Cached : la quantité de mémoire actuellement utilisée en tant que cache (par exemple, des caches pour les transferts vers et depuis le disque dur).
  • SwapCached : la quantité de mémoire actuellement sortie du swap, mais dont une copie est toujours présente dedans.
  • Active : la quantité de mémoire vive récemment utilisée.
  • Inactive : la quantité de mémoire qui n'a pas été utilisée depuis un certain temps (le noyau pioche d'abord dans ces pages s'il a besoin de mémoire).

Sur une architecture x86 32 bits, la mémoire physique est séparée en trois zones. D'une part, la zone ZONE_DMA, qui correspond aux adresses physiques de 0 à 16 Mo. D'autre part, la zone ZONE_NORMAL qui va de 16 à 896 Mo. Et enfin, la zone ZONE_HIGHMEM qui va de 896 à 4 Go (voire 64 Go avec l'extension PAE). Sur ma machine, la mémoire vive remplie donc les 2 premières zones, plus une partie de la ZONE_HIGHMEM.

  • HighTotal : la quantité de mémoire vive présente dans la zone ZONE_HIGHMEM.
  • HighFree : la quantité de mémoire vive non utilisée et présente dans la zone ZONE_HIGHMEM.
  • LowTotal : la quantité de mémoire vive présente dans le zone ZONE_NORMAL.
  • LowFree : la quantité de mémoire vive non utilisée et présente dans la zone ZONE_NORMAL.

Vérifions :

HighTotal + LowTotal = 131008 + 905248 = 1036256 = MemTotal
HighFree + LowFree = 252 + 57468 = 57720 = MemFree

Chouette, ça colle !

  • SwapTotal : la taille du swap.
  • SwapFree : la place disponible dans le swap.

Dans mon cas, le swap n'est pas du tout utilisé (en effet, OpenOffice n'est pas encore lancé... :). C'est également vérifiable avec l'utilitaire swapon :

$ sudo swapon -s
Filename           Type        Size    Used Priority
/dev/mapper/lvm-swap  partition  524280   0   -1
  • Dirty : la quantité de mémoire en attente d'être écrite sur le disque.
  • Writeback : la quantité de mémoire qui est actuellement en train d'être écrite sur le disque.
  • AnonPages : la quantité de mémoire allouée avec la fonction mmap() avec le flag MAP_ANONYMOUS.
  • Mapped : la quantité de mémoire allouée avec la fonction mmap() à partir de fichiers ou de devices.
  • Slab : la quantité de mémoire utilisée au sein du noyau, et allouée avec l'allocateur Slab, pour ses propres objets et structures.
  • PageTables : la quantité de mémoire utilisée en tant que table de pages pour gérer la pagination.
  • CommitLimit : une estimation de la quantité maximale de mémoire disponible pour être allouée.

Linux sépare la mémoire virtuelle en deux partie. Une première, de 3 Go, et qui contient l'espace d'adressage virtuel d'un processus. La seconde, qui elle fait 1 Go, et qui contient l'espace d'adressage noyau. C'est dans cet espace que seront mappés les zones ZONE_DMA et ZONE_NORMAL. Or, celles-ci ont une taille maximale cumulée de 896 Mo. Il est donc nécessaire d'avoir un autre espace, l'espace d'adressage virtuel du noyau, qui permet d'atteindre les 1 Go évoqués juste avant. La valeur VmallocTotal donne la taille de cet espace.

  • VmallocTotal : la quantité totale de mémoire de l'espace d'adressage virtuel du noyau.
  • VmallocUsed : la quantité de mémoire utilisée dans l'espace d'adressage virtuel du noyau.
  • VmallocChunk : le plus grand bloc contigu de mémoire virtuelle (et non physique) disponible dans l'espace d'adressage virtuel du noyau.
  • HugePages_Total : le nombre de hugepage allouée. Une hugepage est une page d'une grande taille (sisi :), utilisée par des programmes qui ont des besoins précis de mémoire.
  • HugePages_Free : le nombre de hugepage disponibles.
  • Hugepagesize : la taille d'une hugepage.

lundi, août 27 2007

Le libre-échange est-il libre ?

[ Voici une copie de l'article qui a été publié sur Agoravox il y a quelques jours et dans lequel je voulais avant tout remettre en cause la logique de la PAC ]

A l’heure du libre-échange et de l’ouverture des frontières, le protectionnisme américain et la politique agricole commune en Europe sont-elles bénéfiques pour la planète ?

Lire la suite...

mercredi, août 22 2007

Construire un système de commentaires pertinent

En parcourant les différents sites de médias, on peut noter qu'il existe une multitude de gestions des commentaires. Certains affichent les commentaires de façon linéaire, d'autres sous la forme d'arbre ou encore individualisés. Se pose alors le problème de la lisibilité lorsqu'un nombre important de contributions est envoyé. Tous ces systèmes ont leurs avantages et leurs défauts. Voici quelques exemples de systèmes de gestion de commentaires :

Lire la suite...

lundi, juillet 16 2007

RMLL - Le logiciel libre s'impose en France

[ Article paru sur Rue89 ]

Du 10 au 14 juillet, avaient lieu à l'université d'Amiens les rencontres mondiales du logiciel libre, connues également sous le diminutif RMLL. Une grande manifestation qui rassemblait, pour la 8ème édition, les différents acteurs du domaine. Ici, le monde associatif côtoie le monde de l'entreprise, le monde universitaire, le monde éducatif, les collectivités locales, les grandes administrations ainsi que les simples utilisateurs comme les passionnés. Bref, une vaste communauté où chacun y trouve son intérêt et tiens compte de l'intérêt des autres. Car c'est bien ça le logiciel libre : tout le monde a la liberté de contribuer, et chacun dispose des contributions des autres. Le parallèle avec l'encyclopédie Wikipédia est inévitable. D'ailleurs, les deux communautés sont très proches et sont liées par une même philosophie, celle du partage et de la création de biens communs.

Lire la suite...

mardi, juin 12 2007

La concurrence appliquée aux télécoms (1)

A la fin de mon précédent billet sur le libéralisme, j'avais terminé en pointant du doigt quelques termes moteurs de l'économie actuelle et fondateurs du néolibéralisme. Entre autre, j'avais initié une remise en cause du modèle économique basé sur la sacro-sainte concurrence. Cette bonne vieille concurrence qui, selon d'éminents économistes et prix nobels (Friedrich Hayek, Jean-Baptiste Say, Adam Smith... pour ne pas les citer), amène à une harmonie sociale et à un équilibre économique, à la condition, biensur, qu'aucun contrôle et qu'aucune régulation étatique n'aient lieu. Dans le cas contraire, chômage et inflation seraient alors inévitables. Voilà pour la théorie. En pratique, on en connaît plus ou moins les limites. On peut alors se poser la question de l'efficacité de la libre concurrence. Est-elle d'ailleurs saine dans tous les domaines ? dans les transports ? dans la santé ? dans l'éducation ? et dans... les télécoms ? Tiens donc, parlons des télécoms ! En plus, c'est un domaine qui est particulièrement riche en exemples (et puis je connais un peu mieux son histoire que celle de la santé).

Lire la suite...

mardi, juin 5 2007

SSTIC 2007 - Ou comment bourrer un amphi

Cette année, le SSTIC avait lieu à l'Université de Rennes 1 dans l'amphi Louis Antoine. Question dépaysement, j'ai vu pire... Car j'ai passé l'année dans le bâtiment d'en face. Coïncidence amusante sachant que la conférence doit normalement avoir lieu dans les locaux de l'ESAT. Mais, faute de place et voulant assurer un minimum de sécurité, un autre lieu a été choisi. A ce propos, la répartition des responsabilités a été finement choisi : l'ESAT, pour la co-organisation; Supelec, pour les repas; et l'Université pour l'infrastructure d'accueil. L'année prochaine, si nous allons prendre le pot à l'ENST et dormir à l'INSA, je crois qu'on aura presque fait le tour du campus :)

Lire la suite...

dimanche, mai 27 2007

La main invisible existe !

Non pas celle d'Adam Smith, à travers laquelle le marché s'autorégulerait de manière naturelle, sans l'action de l'état. Une croyance fondatrice du monde néolibéral actuel et présente jusqu'à la tête de notre pays. Sarkozy croit en effet en l'éthique du capitalisme. Notre nouveau président espère ainsi que les patrons des grandes entreprises arrêteront, de façon volontaire, d'abuser des stock-options, de délocaliser pour maximiser les profits ou de piller les richesses naturelles.

Lire la suite...

jeudi, mars 8 2007

OLPC : how about security ?

During the last week of February, I spent three days in Brussels, for the FOSDEM event. This is the biggest european meeting about free and open source software and it was the second time I went there (the first one was in 2005). The first track I had the chance to see, and not the least, was about the project One Laptop Per Child (known as OLPC). A project which has the ambition to propose a laptop for each child in the development world. The cost, 100$ per computer, would be paid by countries, societies and international organizations. A huge project in fact, because the product is not only seen as a way to make profit (for the campanies involved), but has for aim to provide a tool "desgned for learning learning". By this way, it might be able for them to get the knowledge to develop themself.

Lire la suite...

mardi, janvier 2 2007

DumbSpam : a dotclear plugin to stop spam in comments

I have written a small script which try to avoid the spam in comments posted in Dotclear blogs. It uses JavaScript events to detect any human activity (move of the mouse or press of a key) and send, using AJAX, a data to the server in order to inform it that the user is human. Then, the entire form is displayed and can be submitted. If no human activity is detected, the user is considered as a bot and can't see the entire form. It can't fill all the inputs and it will be rejected automatically by the server when the submit will take place because of a lack of informations.

The way to install this script is quite simple :

  • Get the file http://www.sygus.net/atwork/dumbspam/dumbspam-1.0.zip
  • Extract it and put the file form_ajax.php in the directory in which the current theme is. For example : /dotclear/themes/currentTheme/
  • Open the file /dotclear/themes/currentTheme/post.php and replace the line which call form.php :

<?php include dirname(FILE).'/form.php'; ?>

by

<?php include dirname(FILE).'/form_ajax.php'; ?>

It should work for the new bots which try to post spam. If the bot has already come, and has saved the form's page in his memory before the installation of the script, it can go beyond this protection. In this case, another modification is needed. If the weblog is new, obviously this problem doesn't exist.

So the modification is the following : in the file form_ajax.php, replace the line :

<input name="c_nom" id="c_nom" type="text" ...

by

<input name="c_nomform" id="c_nom" type="text" ...

And in the file /dotclear/layout/prepend.php, replace the line :

$c_nom = trim($_POST'c_nom');

by

$c_nom = trim($_POST'c_nomform');

Yes, you need to modify the core of dotclear ! I don't see any other solution.

vendredi, décembre 29 2006

Bot detection with AJAX

A really pain aspect of managing a website is the constant influx of bots which are dedicated to spam. Even a website with low traffic can be the target of a bot, since this website is linked by another one. The result is that the comments are wasted by spam and the read of an article with its responses become awful. Moreover, the situation is getting worst because of the increase of the number of bots and the ease of use of the programs behind these bots.

Many solutions are used to fight against bots, but each one has its own advantages/disavantages and efficiency. We can make two categories : solutions that try to avoid the bot for posting (captcha audio, video and text for example), and solutions that analyze the text submitted in a form in order to find out that it wasn't written by a human (bayesian filter for example).

The solution I am currently thinking about and I have tried to implement is part of the first category. It tries to detect the presence of a bot by using AJAX and Javascript technologies. Let's try to explain how it should work : by default, when a new connection is made, it is categorized as a bot until a human event is detected. This kind of event can be a move of the mouse or a press of a key. This is detected by the JavaScript event onMouseMove and onKeyPress. If such an event is made, we categorized the connection as being performed by a human. Then, we can allow it to post a comment, to keep surfing on our website or whatever we want.

The first implementation tells us who is human or not. Bots appear in red. It works by adding a new entry in a database when a new connection is made. And when a human event occurs, it updates this entry by telling that it's not a bot. I have made another implementation in which a form appears when the user moves the mouse or presses a key. I will try to adapt this script to Dotclear in order to make an antispam.

After two days of work on this website, the first script seems to work quite good, but I wonder how it could handle a high traffic website. Finally, to be critical, we can made two objections against this solution. The first one, which actually fits many other solutions, is that it works until a bot counter attacks. How can it do that ? By simulating the move of the mouse or the press of a key. In this case, maybe we which should analyze the speed of the mouse to detect how human it is... The other objection is that if JavaScript is not activated on the client browser, then our solution is useless. But fortunately, many browsers allow JavaScript by default.

The concurrence of such a solution with text analysis could be an even better solution as it doesn't affect accessibility (the main reproach of captchas), and if Javascript is not activated on the browser, there is another filter (on the text).

I will provide the full source code soon.

samedi, novembre 25 2006

How to mount a remote partition

Since I turned back on my server, I wanted to be able to mount its partitions on my laptop. I first tried nfs, but this program couldn't share each partition. Indeed, one of them was a fat32 partition and it appeared that nfs was not capable to share it. Actually, I couldn't see any files. The other problem I met with nfs is that I was not able to mount the partition through internet, in the aim to acces to my movie/music/share directory everywhere. I didn't find any solution to that, so I gave up.

After some research, I found a new way to share partition : by using a ssh filesystem. The implementation I installed is sshfs which is based on the API fuse. It can be found on the package list of Debian, or here It works very well and has the advantage to be secure because of the use of the protocole SSH. The latency is quite good and the bandwith depends naturally of the rate of the both endpoints of the connection.

Currently, I'm listening music 130km away from the server.

jeudi, novembre 2 2006

Let's talk french in english

During my year in Ireland, I tried to write down all the french words I could hear or read in an english context. These words could have been collected from TV programs, magazine sections or books. I found about 20 french words in the english language, but there are a lots more of course. Let's take a look at them :

  • Bouquet
  • Rendez-vous
  • Objet d'art
  • Cul-de-sac
  • Souvenir
  • Coulis
  • Coup d'état
  • Fiancé
  • Décolleté
  • Déjà-vu
  • Débat
  • Grotesque
  • Ennui
  • Camouflage
  • Espionnage
  • Réveil
  • Argot
  • Réverie
  • Gourmet
  • Promenade
  • Ballustrade
  • Soupe du jour

The funniest is Cul-de-sac which can be found on many road signs ! The first time I saw one like that, I was amazed. Coup d'état is quite surprising as well.

mardi, mars 7 2006

Trip in Donegal and Nothern Ireland

The last sunday, I made a one-day trip in the north of Ireland. We were seven to go : one spanish, one german and the rest of french. Our two cars first stopped in Londonderry, in Nothern Ireland, for the morning. Before to be there, I thought it was an ugly city because of the fight between catholic and protestant. Remember you that Londonderry is on the borderline between Ireland and Nothern Ireland (yeah like Dundalk), and this city is known to have a not so beautiful history (Bloody Sunday for example). I was therefore surprised to see a city with ramparts, gates and the town center between these ramparts seemed to be a very nice place. I was wondering why this city is sometimes called Derry and some other times called Londonderry. This is again because of the opposition between catholic and protestant. The first one call this city Derry and for the other one, it's Londonderry. But we were here at 11:00 on a sunday and everything was closed. Absolutely everything ! Impossible to find any open pub or café. Fortunately, after 20 minutes of walk, we found an hotel (4 stars hotel with limousine in front of, but not for us...) and we took a coffee. 6 pounds for seven coffee and tea, that could be worst :)

After this break, we left the Nothern Ireland and we came back in our Ireland, in the county Donegal. We made the next stop in a little beach called Inishowen Head. A lovely place, and nobody was there except us. The sun was shining and we felt a little bit warm ! We went then to the highest point of Ireland : Malin Head. A nice place with cliffs, but it began to rain and to snow. We didn't care about that and we were fighting against the strong wind. This remember me the Pointe-Du-Raz in France, in Bretagne. This is the westest place of France and there are also cliffs and strong wind and rain :) We tried to eat outside between two showers. It was a half-success because after a while, we decided to finish eating in the cars.

Then we went, with a bit of difficulty due to the bad irish roads and indications, to Grianan Aileach which is a moutains, or maybe a only bump (it's so difficult to call something a moutain when the top is only at 250 meters...), and on the top there is a stone fort. From this position, we had a pretty good vue of the surrounding landscape. But, it began again to snow and we felt awfully cold. So we came back home. We were in Dundalk at almost 21:00.

Finally it was a very nice trip. And in spite of the weather, we all enjoyed this day. But the next time, I should avoid making a party at home the day before to make a trip. Because sleeping 2 hours is not really sufficient !

vendredi, février 24 2006

Hugo Délire is back

Do you remember Hugo Délire ? It was a french emission, during the beginning of the 90's, presented by Karen Chéryl. Now, you remember ? No yet ? The aim of this game was to drive Hugo and to avoid obstacles. We could see this emssion on the third channel FR3. It was a pretty good success, and i used to watch this game a lot. But, since ten years, Hugo Délire disappeared and we didn't know what happened to him.

Now we know where he is living : on the irish channel TG4 on an emission in gaelic language for children. These are two pictures of the emission on which we can see Hugo accompanied with a strange character. I don't know who is the last character, i don't speak gaelic (not yet :-).

HugoHugo

jeudi, février 23 2006

My house in Dundalk

Today, i present you my irish house. I live in a quiet district close to the sea (ok ok, at least 3km to the sea). These are some pictures of my house.

One bedroomThe kitchenThe living room
The saloonThe entire house

There are five bedrooms, but actually only four are used. I live with one spanish (Manolo) and two germans (Mélanie and Christian). The last bedroom is used sometimes by family or friends.

- page 1 de 2