Archive for the 'INL' Category

Page 2 of 2

Peerfuse

Il y a maintenant plus d'un mois j'ai débuté avec lodesi un projet intitulé Peerfuse, qui est un système de fichiers distribué peer-to-peer.

Le projet est découpé en deux sous projets distincts (possédant une base de code commune) :

  • peerfuse-net pour un réseau sur Internet avec des inconnus. La principale utilisation à laquelle on pense, est un but similaire à Emule, à part qu'au lieu d'avoir un espace par utilisateur, ici tout le monde partage le même espace. Ceci permet l'échange de vidéos, photos, musiques, programmes, images CD de distributions Linux, etc.
  • peerfuse-lan pour un réseau avec ses propres machines. Il permet par exemple de partager une partition /usr/local entre divers machines. Ainsi chacunes de ces machines possède virtuellement un grand nombre d'applications, et elles ne sont récupérées que lorsqu'on les utilise effectivement.

Le principe en surface est simple :

  • C'est un système de fichier, c'est à dire qu'il n'y a pas de GUI (bon en fait on en fera probablement une pour aider à effectuer certaines tâches).
    Il suffit donc de lancer peerfuse avec la commande mount sur un point de montage qui sera l'espace partagé.
  • Il n'y a pas de serveur central, lorsque l'on rejoint le réseau, il suffit de se connecter sur l'un des peers, qui va nous mettre en relation avec tous les autres.
  • La partition montée est commune à tout le monde. C'est à dire que l'arborescence présente dans le point de montage sera le même pour tout le monde.
    Lorsque l'on souhaite partager un fichier avec le reste du monde, il suffit donc de le copier vers le point de montage, et ainsi chaque utilisateur y verra le fichier et pourra le lire ou le copier à son tour (ce qui effectue un téléchargement).
  • Il y a tout de même un système de permissions, comme sur tout système de fichier unix.
    Sur peerfuse-net, chaque peer possède un UID, et chaque fichier qu'il crée aura pour propriétaire cet uid. Après les permissions unix s'appliquent comme d'habitude. Les groupes seront également supportés, avec le principe qu'un utilisateur est propriétaire du groupe au GID = UID. C'est donc lui qui ajoute des personnes à son groupe.
    Sur peerfuse-lan, les permissions du système unix sont concervées. Ainsi root sur une machine pourra voir root sur les autres machines.
  • Une autre puissance de peerfuse est de permettre un travail collaboratif. En effet, les fichiers sont modifiables par ceux qui en ont la permission. Il est ainsi facile d'imaginer qu'un projet soit créé sur un réseau peerfuse, dans un dossier où seul le groupe G a droit d'écriture dessus. Tous les membres de ce groupe pourront modifier et faire évoluer ce projet.
    Attention toute fois, pour des projets d'ampleur tels que des logiciels, il est préférable d'utiliser un système de gestion de version tel que Subversion. En effet, peerfuse ne gère pas l'historique des versions, ni les accès concurrents à un même fichier (la dernière écriture gagne).
  • Peerfuse fonctionne en mode déconnecté, c'est à dire que même lorsque l'on est déconnecté du réseau, on peut lancer peerfuse et ajouter des fichiers, en supprimer, en modifier, etc. Lors de la prochaine reconnexion au réseau, les changements seront appliqués.
  • Tous les échanges sont sécurisés, utilisant SSL pour les connexions.
    peerfuse-net renforce encore les systèmes de sécurité, avec signatures de tous les messages et fichiers, encryptage des fichiers accessible que par une partie des utilisateurs (propriétaire ou groupe), certificat délivré par une autorité afin d'assurer l'authenticité de tel utilisateur, etc.
  • Les transferts seront effectués probablement en UDP pour peerfuse-lan, afin de gagner un débit optimal.
  • Ces transferts seront effectués dans la limite du possible en streaming. Le but est de pouvoir lire une vidéo de façon totalement transparente même lorsqu'elle n'est pas encore sur la machine locale. Si le débit du transfert est plus rapide que celui de la vidéo, aucune différence ne sera faite.

C'est un projet assez novateur et dont les tentatives similaires (mais n'ayant pas le tiers des fonctionnalités que nous proposons) sont toutes tombées à l'eau. Je pense que Laurent et moi avons la volonté suffisante pour que ça ne soit pas le cas avec ce projet.

Cependant, comme on peut l'imaginer, il y a énormément de problèmes de sécurité dans peerfuse-net qui peuvent se poser, en raison de la présence éventuelle de malfaiteurs. Nous en avons déjà résolu une grande partie, mais il reste encore quelques sujets mineurs sur lesquels plancher.

Développement

Nous recherchons tout de même des développeurs afin de nous aider sur le projet, car il y a du boulot. Cela dit, je pense qu'on atteindra une première version stable et incomplète de peerfure-lan rapidement, étant donné qu'il ne pose plus de problèmes de sécurité, et qu'il manque uniquement les transferts des fichiers.

Vous pouvez récupérer les sources grâce à :

$ svn co https://piggledy.org/svn/peerfuse/trunk peerfuse

Login: anonymous
Password: <Enter>

Vous trouverez la base commune dans common/, la partie concernant peerfuse-net dans peerfuse-net/ et je vous laisse deviner où se trouve le code de peerfuse-lan.
La documentation se trouve dans doc/, cependant ne lisez pas proto.html qui est complètement dépassé maintenant.

Lisez plutôt peerfuse-net/PROTOCOL et doc/pfnet.proto.

N'hesitez pas à nous rejoindre sur le salon IRC #peerfuse@freenode. Une mailing list sera bientôt mise en place.

Plus d'informations sur http://peerfuse.org.

Mutt et ses amis

J'utilisais KMail jusqu'alors pour lire mon courrier, cependant le manque de raccourcis claviers et de souplesse de celui-ci m'ont fait passer à un superbe MUA qu'est Mutt.

mutt.png

Introduction

Tout d'abord il faut oublier ce que vous savez sur les clients mails tout en un. En effet, Mutt part du principe qu'il doit assurer uniquement la fonction minimale d'un client mail, c'est à dire afficher les mails. Il passe par d'autres programmes pour récupérer les mails, les envoyer, les filtrer, les écrire, etc.

Cependant, dans les dernières versions, il est tout de même possible de l'utiliser pour faire ces actions (SMTP POP3 et IMAP), mais nous allons faire avec des outils externes, c'est plus drôle.

Personnellement j'ai choisi les programmes suivants :

  • postfix pour envoyer les mails en relayant au serveur SMTP de mon FAI. L'intérêt pour moi est qu'il me sert également comme serveur MX pour lmes domaines afin de stocker dans ma boite système.
  • fetchmail pour récupérer les mails POP de mes différents comptes.
  • procmail pour trier mes mails dans les différents dossiers.

Il est à noter enfin que tout (y compris mutt) se trouve sur le serveur pour pouvoir accéder à ma boite mail depuis n'importe où.

Compilation

J'ai choisi de recompiler la dernière version à cette date de Mutt (1.5.17) afin d'appliquer un patch permettant d'avoir une sidebar avec la liste des dossiers, ce qui simplifie l'utilisation.
J'ai activé après les options suivantes pour la compilation :

$ ./configure --with-sasl --with-slang --enable-hcache --enable-imap --with-ssl

Ainsi que vous pouvez le voir, j'ai activé le support d'IMAP afin de jouir des fonctionnalités de celui-ci pour mon compte IMAP.

Maildir

Pour récupérer les mails que vous aviez avec votre ancien client mail, si ce dernier supportait le format Maildir il est aisé de récupérer le répertoire et de l'utiliser. J'ai mis le miens en tant que ~/Mail/.

Petite subtilité pour KMail, la gestion des sous répertoires est un peu chiante, en effet ils sont dans ~/Mail/.inbox.directory/, pareil pour les sous sous répertoires, etc. Personnellement j'ai tout déplacé afin que chaque répertoire soit directement dans ~/Mail/. Ainsi j'ai :

3 rom1@sunigav ~/Mail $ ls
cache    ircu       maa-commits  sent-mail      Taches
CoderZ   libcaca    mail.sh      server.rdl.fr  Tâches
Gunther  libodbc++  MenAreAnts   Spam           Wormux
inbox    listen.sh  Nekeme

Nous verrons l'intérêt des scripts mail.sh et listen.sh plus tard.

Postfix

Rien de spécial à faire, installez le et configurer (simple, personnellement c'est l'installeur Debian qui m'a posé les bonnes questions).

Fetchmail

Créez le fichier ~/.fetchmailrc et remplissez le avec vos comptes à la manière :

set postmaster "rom1"
set bouncemail
set no spambounce
set properties ""
poll pop.pro.proxad.net with proto POP3
       user 'ident' there with password 'pass' is 'rom1' here ssl
poll pop.1and1.fr proto POP3
        user 'ident' there with password 'pass' is 'rom1' here ssl
...

N'oubliez pas de chmod 600 le fichier, en effet il contient vos mots de passe en clair !

Lancez maintenant fetchmail en démon en compte utilisateur avec la commande suivante :

$ fetchmail -d 30 -a -m "/usr/bin/procmail -Y -d %T"

Fetchmail va récupérer les mails toutes les trente secondes et va les passer à procmail.

Procmail

Créez le fichier ~/.procmailrc et remplissez le de la manière suivante :

# caractère verbeux de procmail ; mettre 'yes' permet d'avoir des messages
# supplémentaires
VERBOSE=no

SHELL=/bin/sh

# chemin d'accès aux exécutables ; en mettre le minimum, pour n'accéder qu'aux
# programmes indiqués dans le fichier de configuration
PATH=/bin:/usr/bin:/usr/local/bin

# répertoire où seront stockés les mails ; s'assurer que votre MUA sait y
# accéder aussi
MAILDIR=/home/rom1/Mail

# si procmail n'arrive pas à délivrer le courrier, cette boîte sera utilisée
# en dernier ressort : il vaut mieux définir cette variable !
ORGMAIL=/home/rom1/emergency-inbox

# boîte de réception par défaut
DEFAULT=$MAILDIR/inbox/new

# fichier de log de procmail ; si vous définissez cette variable,
# procmail gardera une trace de son exécution dans le fichier
# indiqué. À consulter périodiquement !
LOGFILE=$MAILDIR/.procmail.log

# Fichiers de règles à inclure
INCLUDERC=/home/rom1/.procmail/spam.rc
INCLUDERC=/home/rom1/.procmail/ml.rc

Les fichiers de règles doivent juste contenir les règles les unes à la suite des autres. Voici un exemple simple de quelques règles :

:0
* ^Subject: .*libcaca.*
$MAILDIR/libcaca/new

:0
* ^Subject: .*Your partner will worship you for it.*
$MAILDIR/Spam/new

:0
* ^To: .*menareants.*
$MAILDIR/MenAreAnts/new

Il faut tout d'abord écrire une première ligne avec :0 (ajouter à cela quelques flags si nécessaire), ensuite une ou plusieurs lignes commençant par * contenant une regexp, et enfin l'action à mener dans le cas où toutes les regexp matchent. Notez que là c'est très basique, les possibilités sont immenses. Par exemple dans un avenir proche je compte le coupler avec spamassassin.
Voir la doc de postfix.

Mutt

Le plus chiant reste la configuration de Mutt. J'ai personnellement été fouillé de tous les côtés, pompé des bouts de configurations d'autres personnes, lu la doc, etc. C'est tellement paramétrable que c'est pas facile d'y arriver tout seul au début je pense.

Ma config (malgré sa taille) reste basique et va probablement évoluer au fur et à mesure de mon utilisation.

Voici les différents fichiers :

  • .muttrc - Configuration principale qui contient les options générales
  • gpg.rc - Configuration GPG. En theorie il n'y a que la clef à changer dans pgp_sign_as
  • mailboxes.rc - Contient les définitions des différentes boites, ainsi que du compte IMAP. Ainsi qu'on peut le voir, je ne l'ai pas encore configuré, mais les paramètres commentés peuvent être utile comme base
  • theme.rc - Thème de mutt

Je ne commenterai pas plus que ça, après tout la doc de Mutt est très complète là dessus.

En tous cas relisez chaque paramètre et personnalisez, ne prenez pas ça comme une configuration fonctionnelle. Mutt a la particularité justement que personne n'aura exactement les mêmes besoins et donc la même conf.

Indicateur de nouveaux mails

Il est toujours très plaisant d'avoir une indication des nouveaux mails sur une partie visible en permanence de son bureau. La subtilité ici est que Mutt est lancé sur une autre machine.

La solution que j'ai trouvé est super crade, mais elle marche, ce qui est déjà ça.
L'idée est d'écouter un port côté serveur et de balancer le nombre de nouveaux mails et de couper la connexion. Côté client il suffit donc de se connecter à ce port pour récupérer la valeur.

Voici donc l'uniligne ~/Mail/listen.sh :

#!/bin/sh
while [ 1 ]; do socat EXEC:"/home/rom1/Mail/mail.sh" TCP4-LISTEN:4875,reuseaddr; done

Comme vous pouvez le voir, on peut faire plus sexy. Il exécute le script ~/Mail/mail.sh dont le contenu est le suivant :

#!/bin/sh
find ~/Mail/ | grep new | grep -v "new$" | grep -v Spam | wc -l

La séparation est nécessaire car socat exécute un fichier et pas des commandes (utilisation de execvp() et non de system()). De toute façon je trouve pas ça plus mal de séparer les deux, ça permet de réutiliser mail.sh ailleurs.

Vous pouvez constater que mail.sh est carrément dégueulasse, mais bon on fait avec. Notez le grep -v Spam qui permet de ne pas compter les éventuels nouveaux mails qui se situent dans le dossier Spam.

Côté client il suffit de faire exécuter la commande suivante :

socat TCP4:sunigav:4875 STDOUT

Merci en tous cas à lodesi pour l'astuce du socat car je connais aussi mal bash que les chiens qui lechent leur gode.

Conclusion

Voilà un super Mutt fonctionnel, qui envoie, reçoit et trie les mails, lit avec elinks les mails HTML (malheureusement il y en a) et m'affiche un indicateur dans la statusbar de ion3 :

mutt1.png

Pensez à bien configurer mailcap pour les applications à utiliser.

Nulog 2.0 is out

BForCoderz

Bonjour,

Comme tout le monde le sait, les serveurs d'IRCube cryptent les noms d'hôtes. La partie cachée est celle avant le premier '.', et est remplacée par un hash MD2 ou MD5 de 32 bits sous forme hexadécimale.
Qui n'a jamais rêvé, à la place de 341B0FB4.w86-194.abo.wanadoo.fr, d'avoir un nom d'hôte cryptée tel que CACA.mondomaine.com, 1337.mondomaine.com, 69.mondomaine.com ou encore B00B.mondomaine.com ?

Ceci est maintenant possible, grâce à BForCoderz !

En effet, ce petit programme permet de mettre en oeuvre la technique du bruteforce, qui consiste à tester le maximum de possibilités afin de trouver laquelle correspond à l'hostname cryptée donnée.

Cette méthode peut paraître à première vue longue, mais justement BForCoderz met en oeuvre un système permettant de partager les opérations. Il utilise en effet une architecture client/serveur permettant de répartir les calculs sur différentes machines.
Il est donc pour cela nécessaire de lancer un serveur et divers clients reliés à lui, en attente d'opérations. Inutile de préciser qu'il ne sert à rien de lancer plus d'un client par processeur, ce qui ne ferait ralentir plus qu'autre chose.

Une fois le réseau mis en place, il vous suffit de vous connecter en telnet au serveur et de lancer une recherche, le serveur s'occupe du reste et vous remontera les divers résultats.
Il est à noter que j'ai également implémenté un système de masques qui permet de spécifier la forme des hosts à tester (par exemple %$-$-$-$ pour un hôte tele2 style b13-145-44-142.cust.tele2.fr). Vous trouverez plus d'informations sur le site de BForCoderz

Voici l'exemple d'une IRCubienne qui a choisie de renoncer à son hostname proxad.net, pour prendre à la place un hostname crypté bien plus sexy :

Utadah_Bay (~Syphaiwon@CACA.vaginus.org) has joined #IRCube

Notez qu'il faut pour cela posséder une IP fixe et avoir un fournisseur d'accès qui autorise la mise d'un reverse DNS autre que *.fai.com.

Enfin, ce projet a été étudié pour être le plus rapide possibles, grâce à diverses micro-optimisations, et ce même avec l'utilisation des masques. Ceux qui sont intéressés peuvent lire le code source disponible, et éventuellement contribuer. Je rajouterai qu'il n'y a absolument aucune vérification au niveau de la sécurité (bufferoverflow par exemple, même si il est très peu probable d'arriver à l'exploiter). En effet ce n'est actuellement pas primordial et pour une utilisation normale ça ne devrait pas poser de problèmes.

Pour plus d'informations et pour télécharger BForCoderz, visitez la page consacrée au projet : http://romain.peerfuse.org/projects/bforcoderz

Romain.

P.S.: Les plus perspicaces (et cons) d'entre vous se seront posé la question de l'éventualité de décrypter les hostnames d'IRCube. Je peux affirmer que cela risque d'être très dur. En effet, il faut savoir que le hash MD2 ou MD5 tient sur 128 bits, mais qu'on le tronque sur 32 bits, et que donc il y a un grand nombre de collisions (voir sur la page du projet). Vous obtiendrez cependant certes une liste restreintes (ou non) d'hostnames, mais il vous faudra tous les tester afin de déterminer laquelle est la bonne, ce qui réduit un peu l'intérêt.

Nulog 2

Bonjour,

D'ici quelques jours devrait paraître Nulog 2, une interface d'analyse de logs pare-feu Netfilter que j'ai développé au sein de mon stage chez INL.

Voici en avant première une screenshot :

nulog-newstyle.png

Comme vous pouvez le voir, Nulog 2 supporte les fonctionnalités suivantes :

  • Page d'accueil entièrement personnalisable
  • Affichage de "cadre" déplaçable et pliables
  • Les cadres peuvent contenir des tableaux, des histogrammes ou des camemberts
  • Utilisation d'AJAX pour une meilleurs interactivité avec l'utilisateur
  • Export des données en CSV
  • Gestion des logs de NuFW, le pare-feu authentifiant d'INL
  • Recherche par clics intuitive au sein de l'interface, par la cumulation des filtres (par exemple: "utilisateur Progs" -> "host 192.168.0.50" -> "port destination 25")
  • Interface multi-langage
  • Bien d'autres fonctionnalités qu'il serait vain d'exprimer

Il a été développé en Python, grâce aux frameworks Twisted et Nevow.




Bear