Geekfault » internet

Yubikey : la petite clé qui assure

LeCoyote — Thu, 14 Apr 2011 10:30:54 +0000

Yubikey, c’est une petite clé USB un peu spéciale. Une petite pastille tactile sur le dessus permet de générer un mot de passe à usage unique, qu’un service distant saura utiliser pour vous identifier ou non. C’est pratique, c’est sûr (si c’est bien utilisé), et c’est assez geek pour qu’on en parle.

Le problème

Les mots de passe se multiplient comme des petits pains, surtout chez les geeks. Comme il est impensable de tous les noter dans un petit calepin ou d’utiliser le même partout (on est d’accord ?), il faut sans cesse en inventer de nouveaux et les retenir.

Par ailleurs, si on veut être un peu sérieux, il faut se méfier du terminal que l’on utilise, surtout s’il appartient à un tiers. Qui vous dit que le vilain admin du cyber-café n’a pas un vilain keylogger sur toutes ses machines ? Plus fourbe, qui vous dit qu’il n’y a pas un vilain keylogger malware installé sur le laptop de votre [maman|grand-père|hamster] que vous utilisez en ce moment, “pour dépanner” ? Sans parler d’attaques type MitM et autres joyeusetés …

Arrive la Yubikey. Sans être une solution miracle à tous les problèmes de mot de passe, c’est une façon élégante de se simplifier la vie.

La Yubikey, en bref

Yubikey 2.0, by Yubico

Plutôt que de vous pointer vers le manuel de la Yubikey, je vais en synthétiser quelques passage pour commencer.

La Yubikey fonctionne sur n’importe quel matériel équipé d’un port USB hôte et tournant sous à peu près n’importe quel système d’exploitation supportant un clavier USB (sous Linux, le support HID suffit) : en effet, elle fonctionne en émulant des frappes clavier, sans avoir recours à un driver particulier.

À chaque utilisation, la clé génère une chaîne de caractères unique (appelée OTP pour One Time Password), basée entre autres choses sur une identité propre à la clé, un compteur non-volatile, une horloge et un nombre aléatoire. Cette chaîne est ensuite chiffrée à l’aide d’une clé AES de 128 bits et envoyée à l’hôte. Exemples :

[cc]fifjgjgkhchbirdrfdnlnghhfgrtnnlgedjlftrbdeut
fifjgjgkhchbgefdkbbditfjrlniggevfhenublfnrev
fifjgjgkhchblechfkfhiiuunbtnvgihdfiktncvlhck[/cc]

(on constate que les 12 premiers caractères sont toujours les mêmes : il s’agit là de l’identité de la Yubikey)

De l’autre côté, elle sera déchiffrée à l’aide de la même clé AES. De par l’usage d’un chiffrement symétrique, la sûreté de l’ensemble repose sur une bonne protection de la clé AES. Celle-ci est stockée dans une mémoire non volatile intégrée au microcontrolleur et n’est pas accessible, la configuration de la Yubikey se faisant en écriture seule. Pour récupérer la clé, il faudrait éventuellement sonder physiquement la puce ou analyser son comportement, ce qui implique de casser physiquement la Yubikey et de disposer de matériel de pointe. En d’autres termes, si ce n’est pas complètement adapté aux agents secrets, c’est probablement suffisamment sûr pour le geek moyen que je suis.

Le résultat est enfin vérifié par un serveur de validation : soit celui de Yubico, soit un serveur fait maison. La validation tient compte de plusieurs critères, au-delà de la simple identité. Notamment, la valeur du compteur est examinée : si elle est inférieure ou égale à la dernière valeur reçue, l’OTP est rejeté comme étant un “rejeu” d’un OTP plus ancien.

L’ensemble se résume au schéma suivant (cliquer pour agrandir) :

Fonctionnement de base de la Yubikey

Une application doit donc être configurée (ou modifiée) afin d’accepter un login Yubikey. Comme nous utilisons du logiciel libre, ça se fait en général assez facilement. Nous allons donc voir comment utiliser la Yubikey sous Linux de façon basique, puis nous verrons la configuration dune clé pour une utilisation “indépendante” avec serveur de validation maison.

Utilisation simple

De base, nous utiliserons les services de validation de Yubico. Il s’agit ici de configurer simplement Linux pour identifier un utilisateur en utilisant sa clé.

Application n°1 : login Linux

Tout bon Linux moderne utilise en général Linux-PAM pour tout ce qui touche à l’identification utilisateur. Et comme Yubico a la bonne idée de proposer un module PAM, c’est ce que nous allons utiliser.

Il y a trois dépôts à aller chercher pour construire notre module PAM : celui de la bibliothèque yubico-c-client, celui de l’outil de configurationyubikey-personalization, et enfin yubico-pam lui-même. Pour la suite, je suppose que vous avez déjà git d’installé, en sus des outils habituels (automake, gcc …), et que vous savez aller installer une dépendance manquante (comme curl) au besoin.

Compilations

On commence par compiler la bilbiothèque client.
[cc][smokey@moira yubi]$ git clone https://github.com/Yubico/yubico-c-client
Cloning into yubico-c-client…
remote: Counting objects: 397, done.
remote: Compressing objects: 100% (194/194), done.
remote: Total 397 (delta 233), reused 319 (delta 201)
Receiving objects: 100% (397/397), 94.17 KiB, done.
Resolving deltas: 100% (233/233), done.
[smokey@moira yubi]$ cd yubico-c-client/
[smokey@moira yubico-c-client]$ autoreconf –install
[smokey@moira yubico-c-client]$ ./configure
[smokey@moira yubico-c-client]$ sudo make install
[smokey@moira yubico-c-client]$
[/cc]
Rien que du très classique. La bibliothèque est installée comme il se doit dans /usr/local/lib. Je vous laisse d’ailleurs faire exactement la même chose avec yubikey-personalization dans un répertoire à côté, vous êtes grands après tout.

On peut maintenant répéter l’opération avec yubico-pam, à une astuce près : la dépendance ykpers-1 (yubikey-personalization) a été ajoutée très récemment et se vérifie via pkg-config. Il faut donc indiquer à ce dernier où trouver le fichier .pc qui va bien via la variable d’environnement PKG_CONFIG_PATH. Ce qui donne :
[ccW][smokey@moira yubico-pam]$ cd ..
[smokey@moira yubi]$ git clone https://github.com/Yubico/yubico-pam
[smokey@moira yubi]$ cd yubico-pam/
[smokey@moira yubico-pam]$ autoreconf –install
[smokey@moira yubico-pam]$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig ./configure
[smokey@moira yubico-pam]$ sudo make install
[smokey@moira yubico-pam]$[/ccW]

Le module est installé dans /usr/local/lib/security. Pour que PAM puisse l’utiliser, il faut le mettre au bon endroit (et donc être root) :
[cc]# mv /usr/local/lib/security/pam_yubico.so /lib/security/[/cc]

Configuration de PAM

Il faut maintenant indiquer à PAM que l’on veut pouvoir utiliser l’OTP de la Yubikey. Pour ce faire, on modifie /etc/pam.d/login pour y faire ajouter la ligne suivante :
[cc]auth sufficient pam_yubico.so id=16[/cc]
Attention : si vous n’êtes pas très familiers avec PAM, sachez qu’il faut ajouter cette ligne au bon endroit. Je vous recommande de la mettre juste au-dessus de celle du module pam_unix.so. Si vous la placez trop haut, étant donné que le module est ici sufficient (suffisant), il shuntera les modules auth suivants, même s’ils sont required (requis) : pam_securetty ou pam_nologin seraient par exemple rendus inefficaces, ce qui PEUT être grave OU PAS. À vous de voir

Variantes possibles :

avec debug (conseillé en cas de souci)
[cc]auth sufficient pam_yubico.so id=16 debug[/cc]
avec gestion centralisée des identités
[cc]auth sufficient pam_yubico.so id=16 authfile=[/cc]

Note : pour observer les messages de debug, il suffit de créer le fichier /var/run/pam-debug.log et de le rendre inscriptible à tous.

Pour finir, il faut renseigner le système sur l’identité des yubikeys des utilisateurs. Il y a deux façons de le faire :

individuellement : il faut alors créer ~/.yubico/authorized_yubikeys pour chaque utilisateur ;
globalement : le fichier peut se trouver n’importe où, du moment que le chemin correspond à celui passé à authfile= ci-dessus évidemment.

Dans les deux cas, le format du fichier est :
[cc]::…[/cc]
Pour le fichier global, ayez soin d’utiliser une ligne par enregistrement utilisateur. L’ID de chaque Yubikey peut facilement être récupéré en prenant les 12 premiers caractères de n’importe quel OTP généré.

Si tout s’est bien passé, au prochain login, vous devriez voir quelque chose dans ce genre :

Application n°2 : authentification à 2 facteurs avec SSH

L’authentification à 2 facteurs est basée, comme son nom l’indique, sur deux moyens d’authentification différents. Ici, nous sommes dans le cas typique de “ce que l’on connaît” (un mot de passe classique) combiné avec “ce que l’on détient” (la Yubikey). Les deux seront combinés pour former un mot de passe hybride, que l’on va charger pam_yupico de valider. En image, ça donne ça :

Fonctionnement de l'authentification à 2 facteurs avec SHS et PAM

La marche à suivre est sensiblement la même que précédemment, sauf bien entendu pour ce qui est de la configuration de PAM. Ici, on va s’intéresser logiquement à /etc/pam.d/sshd. Tout d’abord, on y ajoute la ligne suivante :
[cc]auth required pam_yubico.so id=16[/cc]
Par rapport à tout-à-l’heure, l’utilisation de la Yubikey est ici requise au lieu d’être suffisante. Du coup, on ne risque plus de shunter d’autre modules, mais il faut tout de même placer cette ligne AVANT celle de pam_unix.so.

Ensuite, il faut modifier les paramètres du module pam_unix.so. Celui-ci peut être configuré directement dans /etc/pam.d/sshd (ex. Archlinux), ou être appelé par un @include pointant sur /etc/pam.d/system-auth (ex. Gentoo) ou /etc/pam.d/common-auth (ex. Debian) : à vous d’adapter en fonction de ce que vous avez sous les yeux. L’important est d’ajouter l’option try_first_pass, de façon à ce que la ligne ressemble à ceci :
[cc]auth required pam_unix.so try_first_pass nullok[/cc]

Une fois ces modifications faites, il ne reste plus qu’à vous connecter à la machine distante comme d’habitude ; mais au lieu de taper simplement Entrée pour valider le mot de passe, on va rajouter l’OTP de la Yubikey. En d’autres termes, au lieu de faire mot_de_passe+Entrée, on fait mot_de_passe+toucher_la_yubikey.

Et ça marche ! Sauf si bien sûr vous avez oublié de préciser PasswordAuthentication yes dans votre /etc/ssh/sshd_config … c’était pour voir si vous suiviez

Login SSH. Par défaut, SSH propose d'utiliser la clé publique s'il en trouve une : taper entrée pour passer à l'étape suivante.

Utilisation avancée

Dans cette partie, un peu plus technique, nous allons aborder la configuration d’une Yubikey et le montage d’un serveur de validation. Mais avant tout …

ATTENTION

La Yubikey est “write-only”. Ceci signifie que lors d’une opération de configuration, les réglages précédents sont irrémédiablement perdus. Notamment, si vous écrasez la configuration par défaut, votre clé ne pourra plus vous identifier auprès de Yubico.
Par ailleurs, si vous décidez de protéger la clé par un code d’accès, et que vous oubliez ce code, vous aurez gagné un joli bout de plastique très décoratif …

Ceci dit, passons aux choses sérieuses.

Configuration de la clé

Sous Linux, le seul outil disponible pour l’instant est en ligne de commande. Si ça vous fait peur, il y a des équivalent pour clicodrome Windows ou Mac OS. Choisissez ici celui qui vous convient le mieux

Le dépôt de l’outil de configuration (ou personalization en anglais) est ici : https://github.com/Yubico/yubikey-personalization.git. Je ne reviens pas sur la procédure d’installation, elle est identique aux précédentes et détaillée sur le wiki du projet. D’ailleurs, si vous avez suivi la partie sur la configuration de PAM, vous l’avez déjà installé

Une fois compilé, je vous engage vivement à jeter un oeil à l’aide en ligne : [cci]ykpersonalize -h [/cci]

L’option la plus importante à mes yeux est -1 ou -2 : c’est ainsi que l’on choisit la configuration que l’on souhaite modifier. En effet, les Yubikeys version 2.0 et plus possèdent deux “emplacements” différents, contre un seul dans la première version. Par défaut sur une clé 2.0 par exemple, l’emplacement 1 est paramétré pour une identification OTP auprès des serveurs de Yubico, et l’emplacement 2 est vide.

Le paramétrage le plus fréquemment rencontré est d’assigner un mot de passe statique à la configuraion 2, mot de passe qui sera accessible par un contact long (≃ 2s). La manipulation est ici très simple :
[cc lines="16"]smokey@moira:~$ sudo ykpersonalize -2
Password:
Firmware version 2.0.2 Touch level 1792 Program sequence 6

Passphrase to create AES key: crévindiou
Configuration data to be written to key configuration 2:

fixed: m:
uid: h:000000000000
key: h:459b2b6c6f4c511d543919efbad3051a
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags: STATIC_TICKET|STRONG_PW1|STRONG_PW2|MAN_UPDATE
extended_flags:

Commit? (y/n) [n]:[/cc]
Il ne reste plus qu’à valider par un “y” pour sauvegarder la configuration.
Notez que vous n’êtes pas obligés de taper des bêtises (comme mon “crévindiou”) pour créer la clé AES. Le résultat sera ici un mot de passe statique du style :
[cci]è(IFejhdkkjnvrtbdeggeffvbknvbulg[/cci].

Note : Pourquoi sudo ? tout simplement parce que les permissions de /dev/bus/usb/xxx/yyy n’autorisent en général pas l’utilisateur lambda à écrire sur un port USB.

Il est également possible de créer une configuration “OTP Yubikey” similaire à la configuration par défaut. Je fais ici le choix d’utiliser l’emplacement 2, afin de conserver la configuration d’origine dans l’emplacement 1. Or, l’outil ykpersonalize considère par défaut que l’option -2 va de pair avec une configuration statique ; il faut donc désactiver les options liées au mot de passe statique pour écrire une configuration OTP dans l’emplacement 2 (d’où les 4 options -o-xxx). Si ce n’est pas clair, faites tourner “à vide” (sans écrire) ykpersonalize avec -1 et -2, et observez les différents config_flags. Ici, ça nous donne :
[ccW lines="16"]smokey@moira:~/tmp/yubiserve$ sudo ykpersonalize -2 -o-static-ticket -o-strong-pw1 -o-strong-pw2 -o-man-update -ofixed=cccccccccccc
Firmware version 2.0.2 Touch level 1792 Program sequence 6

Passphrase to create AES key:
Configuration data to be written to key configuration 2:

fixed: m:cccccccccccc
uid: h:000000000000
key: h:8ebfe5cd3dad48f2c5008d686ea5b384
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags:
extended_flags:

Commit? (y/n) [n]: y
smokey@moira:~/tmp/yubiserve$
[/ccW]

La configuration 2 de la clé est donc faite pour l’identité cccccccccccc et avec la clé AES 8ebfe5cd3dad48f2c5008d686ea5b384. Nous allons voir maintenant comment utiliser cette configuration avec un serveur de validation maison.

Serveur de validation “maison”

Comme me le faisait remarquer un certain Spyou, confier à un tiers la vérification du droit d’accès à son infrastructure n’est probablement pas l’idée du siècle. Mon infrastructure se limite à peu de choses, mais tant qu’à faire, autant garder la vérification en interne. Il s’agit donc maintenant de monter son propre serveur de vérification. Yubico en référence quelques-uns, je vais ici détailler l’installation et la configuration du plus simple, YubiServe. Et quand je dis simple, je pèse mes mots : le tout tient en 2 scripts Python

Avant tout, je vous recommande d’éviter la version 3.1, qui (chez moi en tout cas) contient des “?” partout là où on attend des tabulations. Je vais donc partir du trunk svn :
[cc]svn checkout http://yubico-yubiserve.googlecode.com/svn/trunk/ yubiserve[/cc]

Ceci fait, suivons les instructions du README.
Tout d’abord, on crée un certificat SSL :
[ccW]openssl req -new -x509 -keyout yubiserve.pem -out yubiserve.pem -days 365 -nodes[/ccW]

Ensuite, si vous avez installé Python 2 et 3 sur votre système, il vous faudra peut-être modifier un peu les scripts dbconf.py et yubiserve.py : soit pour faire pointer l’interpréteur vers python2, soit pour modifier l’appel au module sqlite en sqlite3. Par défaut, YubiServe utilisera une base sqlite (déjà présente d’origine), mais il suffit de modifier le fichier de configuration (yubiserve.cfg) pour utiliser une base MySQL à la place.

Il est temps maintenant d’ajouter une clé au serveur. Utilisons donc dbconf.py, qui prend en arguments un “nickname” permettant d’identifier facilement la clé, ainsi que l’uid et la clé AES utilisés lors du paramétrage (cf. plus haut).
[ccW]smokey@moira:~/tmp/yubiserve$ ./dbconf.py -ya smokey cccccccccccc 000000000000 8ebfe5cd3dad48f2c5008d686ea5b384
Key ‘smokey’ added to database.
smokey@moira:~/tmp/yubiserve$[/ccW]
On en profite pour ajouter aussi l’identité cccccccccccc dans le /home/utilisateur/.yubico/authorized_yubikeys qui va bien.

Lançons le serveur :
[cc]smokey@moira:~/tmp/yubiserve$ ./yubiserve.py
HTTP Server is running.
[/cc]

Il ne reste plus qu’à essayer le tout, en faisant pointer un navigateur sur http://127.0.0.1:8000/, ce qui donne normalement ceci :

Il suffit alors d’envoyer l’OTP dans le champ prévu à cet effet pour obtenir le résultat :

Ça fonctionne ! Mais comment faire en sorte d’interroger ce serveur ? Nous allons voir le cas du module PAM, configuré dans la partie précédente.

PAM + Serveur de validation maison

Rappelez-vous, la configuration ressemblait à ça :
[cc]auth required pam_yubico.so id=16[/cc]
Nous allons la transformer en ça :
[ccW]auth required pam_yubico.so id=1 debug url=http://127.0.0.1:8000/wsapi/2.0/verify?id=%d&otp=%s[/ccW]

Par ailleurs, vous aurez remarqué que l’on a précisé un id en argument à pam_yubico. Cet id numérique sera passé via l’URL au serveur de validation : il faut donc qu’il soit défini côté serveur. Nous allons donc ajouter une clé d’API :
[cc]smokey@moira:~/tmp/yubiserve$ ./dbconf.py -aa test-ssh
New API Key for ‘test2′: ‘WGZydWozbHQyVW9BM092cy9nMTk=’
Your API Key ID is: 1[/cc]
Bien entendu, notre “API Key ID” est 1 seulement si c’est le premier à être créé ; l’important est qu’il existe.

C’est fini ! On peut maintenant s’identifier auprès de PAM avec la clé re-configurée par nos soins.

N’oublions pas …

Il serait imprudent de penser que la Yubikey est la réponse à tout. Elle n’est qu’un élément de plus dans une stratégie de sûreté qui se doit d’être solide par ailleurs (c’est toujours le maillon le plus faible qui compte). Si votre login est connu et que vous n’utilisez *que* la Yubikey pour vous connecter, c’est déjà beaucoup moins sûr qu’un schéma à 2 facteurs.

Par ailleurs, comme la Yubikey fonctionne en émulant une saisie clavier, son comportement dépendra du type de clavier utilisé sur le terminal ; si la plupart des dispositions classiques (azerty/qwerty) ne devraient pas poser problème, il en est tout autrement pour les dispositions plus “exotiques” (comme bepo) ou utilisant des caractères non-latins (cyrilliques par exemple). Ce n’est pas un point bloquant en soi, vu qu’il suffit de changer temporairement la configuration du clavier, mais je me devais de le souligner, vu qu’on m’avait posé la question.

Conclusion et informations additionnelles

Tout comme une clé SSH avec un user-agent, une Yubikey permet d’éviter de taper des mots de passe à chaque login. C’est un gain de temps et de tranquillité d’esprit. C’est aussi une sécurité supplémentaire car les mots de passe générés ne sont pas réutilisables, ce qui invalide toute forme d’attaque par rejeu. Cerise sur le gâteau, on trouve déjà pas mal de solutions logicielles libres, venant de Yubico ou d’ailleurs, permettant de tirer le maximum de sa clé. Que demander de plus ?

Liens

Le site de Yubico, le fabricant : http://www.yubico.com/
Le lien direct Yubikey du site : http://www.yubico.com/yubikey
La bibliothèque Yubico-C : https://github.com/Yubico/yubico-c-client
L’outil de configuration : https://github.com/Yubico/yubikey-personalization
Le module Yubico-PAM : https://github.com/Yubico/yubico-pam
Le HOWTO pour SSH : https://github.com/Yubico/yubico-pam/wiki/YubikeyAndSSHViaPAM

Si vous avez aimé ce post...

La petite guerre du Warez

Reverse SSH : accéder à un serveur derrière un NAT/Firewall

Tito — Sat, 19 Feb 2011 14:30:35 +0000

Le SSH tout le monde le sait, c’est magique. Mais malheureusement ça ne marche pas OOTB. On a tous en tête plusieurs situations où on s’est dit “Damn, si seulement j’avais un accès SSH sur cette machine”, la machine étant inaccessible parce que derrière un firewall ou routeur NAT que vous ne contrôlez pas.

Imaginez avoir accès en SSH à la machine de ce noob qui ne sait pas configurer son NAT. Ou bien vous assurer que votre laptop soit toujours joignable en SSH peu importe la connexion sur laquelle il est…

Cette conférence du DEF-Con m’a interloqué : comment le mec a repris la main sur une machine qui était probablement derrière un NAT? Peut-être grâce au reverse SSH !

Principe de fonctionnement

Le principe est assez simple : c’est l’ordinateur derrière le NAT (nous l’appellerons distant) qui doit établir la première connexion. Il établit en fait un tunnel SSH vers vous (nous l’appellerons local) et ainsi en remontant le tunnel dans l’autre sens on accède très facilement à la destination.

On suppose donc que la connexion SSH vers l’ordinateur local est aisée (serveur dédié ou NAT bien configuré).

Avantages

Plus besoin de connaître ou de modifier la configuration du réseau sur lequel est branché distant pour pouvoir y établir une connexion SSH. Tant que le port 22 est ouvert en outgoing ça fonctionnera (on peut même envisager de déplacer le serveur de local sur un port moins restreint tel que le 80 ou 443)
Plus besoin de connaître l’IP où se trouve distant, c’est lui qui établit le contact vers local

Vérifiez la configuration du serveur SSH local

Il faut que le serveur sur local autorise les tunnels (/etc/ssh/sshd_config) :
AllowTcpForwarding yes

Let’s go!

Sur distant (la machine inaccessible), créez le tunnel :
distant$ ssh -NR 22222:localhost:22 user@local
Bien entendu local est l’IP de votre machine et user est un utilisateur qui y a accès.

Une fois le tunnel établi, il ne vous reste plus qu’à remonter le tunnel pour établir la connexion SSH depuis local :
local$ ssh -p 22222 user@127.0.0.1

Service au démarrage

Avec autossh (disponible dans le package manager de votre distro préférée) et une connexion SSH sans mot de passe, vous pouvez très facilement créer un script de démarrage sur distant pour que le tunnel soit toujours récréé sans intervention humaine :
# autossh -i /path/to/privateKey.rsa -NR 22222:localhost:22 user@local

Il vous suffit d’ajouter cette commande dans vos scripts de boot (/etc/rc.local par exemple).

Aller plus loin

Ici nous utilisons du SSH pour ouvrir l’accès à un serveur SSH, mais on pourrait envisager d’ouvrir l’accès à n’importe quel serveur qui tournerait sur distant, par exemple un serveur web pour du monitoring Munin :
distant$ ssh -NR 22280:localhost:80 user@local local$ firefox "http://127.0.0.1:22280"

Vous l’aurez compris, vous pouvez aussi centraliser sur votre serveur (“local”) des tunnels venant de tous les n00bs que vous aidez régulièrement, l’astuce est de remplacer 22222 dans les diverses commandes citées sur cette page par un autre code de port compris entre 1024 et 65535. Et de maintenir une liste exhaustive de ceux-ci !

Si vous avez aimé ce post...

La nouvelle mode Geek : avoir son domaine .42

bragon — Sun, 19 Dec 2010 18:16:50 +0000

Ça claque à mort non d’avoir un nom de domaine en .42 ?
Vous l’avez rêvé ! Ils l’ont fait !
En clin d’œil à H2G2, pour épater un peu Marvin, et parce que la réponse universelle doit bien être ré-solvable quelque part sur le net

Pour le moment pure expérimentation de la 42registry de ce .42, juste avant de peut être conquérir le monde ! (L’univers et le reste !)

Pourquoi on vous parle de ça ?

Bah parce que la 42registry.org ils sont cool, on les aimes bien, et on a envie de les aider.
C’est des fous, et nous chez GeekFault on aime bien les fous.

Vous pouvez d’ailleurs remarquer que si vous savez résoudre les domaines en .42 http://geekfault.42 est disponible.

Vous pouvez d’ailleurs remarquer que vous pouvez venir nous parler de geekfault ou de 42registry sur Geeknode : 4.irc.42 / salon #geekfault / et salon : #42

Votre humble serviteur est également lisible sur son .42 : http://bragon.42

Erf, je sais pas résoudre les domaines en .42, comment je fais ?

3 méthodes pour le moment :
- Je possède mon propre serveur DNS bind9
- Je possède mon propre serveur DNScache DJBDNS.
- Je veux utiliser des serveurs DNS open qui savent résoudre .42

Je possède Bind

Et bah je rajoute à mon named.conf (ou named.conf.local selon les distribs):

zone “42″ IN { type forward; forwarders {81.93.248.69; 81.93.248.68; 91.194.60.196; 193.17.192.53; }; };

Je reload bind, et roulz.
/etc/init.d/bind9 reload
ou
/etc/init.d/named reload

J’ai DJB … Oui Je sais ….

cd /services/dnscache echo 91.191.147.246 > root/servers/42 echo 91.191.147.243 >> root/servers/42 svc -t /services/dnscache

Je suis un pauvre pommé, j’ai pas de serveur de nom

Et bien j’utilise les openDNS de GeekNode.org :

On édite /etc/resolv.conf
nameserver 81.93.248.69 nameserver 81.93.248.68

Hey mec ? Comment je réserve mon .42 ?

Gros poulet ! t’es pas déjà sur : http://42registry.org, tout est expliqué en long en large et en travers !
Alors va vite réserver ton .42 et faire passer le message.

Merci à la team 42registry pour tout l’poisson !

(Et surtout à Colin qui se reconnaîtra ;D)

Liste des domaines enregistrés

Ils sont disponible ici : http://bragon.42/42.txt

Si vous avez aimé ce post...

Devenez miroir de Wikileaks sans risque (corrigé)

Tito — Sat, 04 Dec 2010 23:14:55 +0000

Bon, d’habitude on se refuse de parler politique sur Geekfault… Mais on ne peut pas se taire plus longtemps sur ce qui se passe du côté de Wikileaks. En tant que geeks nous devons nous lever et protester contre ces atteintes à la liberté d’expression sur Internet.

Wikileaks a aujourd’hui publié sa solution à la censure : le mirroring. Si Wikileaks est consultable sur des centaines de noms de domaine et des centaines d’IPs, il sera d’autant plus difficile de tous les faire taire.

A noter que cet article, bien qu’entièrement orienté autour de ce sujet, s’applique aussi si vous souhaitez offrir à quelqu’un un accès SSH chrooté et aux commandes limitées.

Mise à jour : Mes mesures de sécurité étaient trop optimistes : Rsync n’utilise pas du SFTP mais doit pouvoir lancer un serveur Rsync sur sa destination en SSH. Voici donc une nouvelle version de cet article, testé et approuvé.

Le problème

Pour décentraliser la chose, les administrateurs de Wikileaks demande à tous les volontaires de leur offrir un accès en SSH à leur serveur pour pouvoir y pousser un miroir de Wikileaks et le garder à jour grâce à Rsync.

Ca qui m’a dérangé c’est le fait de donner un accès SSH à des inconnus sur mon serveur. Mais la solution existe : CHROOTER ce compte à un endroit où il ne peut faire aucun mal au système. Voici comment faire.

Attention : cet article ne porte bien évidemment pas sur la sécurisation de votre serveur. Il présente juste une manière d’éviter que les administrateurs de Wikileaks (que vous ne connaissez pas) aient trop de libertés sur votre serveur (et, oui, je suis paranoïaque sur le coup).

NB : Si vous souhaitez devenir très simplement un miroir Wikileaks et que vous leur faites entièrement confiance, les étapes “Créer l’utilisateur“, “Configurer un nom de domaine et un VirtualHost” et “Soumettre votre miroir à Wikileaks” sont suffisantes.

Sécuriser OpenSSH

On va donner à Wikileaks (ou toute personne ayant leur clé RSA privée) un accès SSH sur notre serveur. Mais on ne veut prendre aucun risque : cet accès n’aura aucune autre possibilité que de déposer des fichiers là où on l’y autorise, c’est-à-dire dans sa home.

Pour cela, modifiez votre fichier /etc/ssh/sshd_config. Vérifiez d’abord que vous avez ces trois lignes qui autorisent la connexion avec une clé publique RSA.
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys

Dernièrement, à la fin du fichier créez une nouvelle règle d’override telle que celle-ci :
Match user wikileaks ChrootDirectory /home/wikileaks X11Forwarding no AllowTcpForwarding no
Cette règle est assez explicite et fait simplement en sorte que l’utilisateur wikileaks soit Chrooté dans sa home. Redémarrez SSHd.

Créer l’utilisateur

Rien de bien sorcier :
# mkdir /home/wikileaks # useradd -d /home/wikileaks -s /bin/bash wikileaks # chown wikileaks:wikileaks /home/wikileaks

Ensuite autorisons la connexion des administrateurs de Wikileaks :
# su - wikileaks $ mkdir ~/.ssh $ wget http://wikileaks.ch/id_rsa.pub -O ~/.ssh/authorized_keys $ chmod 600 ~/.ssh/authorized_keys

Pour finir, n’oublions pas de créer le répertoire où sera hébergé le miroir :
$ mkdir ~/www

Créer l’environnement chroot

Pour qu’un chroot fonctionne correctement, il faut que sa racine appartienne à root. Nous créons aussi les deux répertoires indipensables à l’exécution d’un rsync : /bin et /lib.
# chown root:root /home/wikileaks # mkdir /home/wikileaks/bin # mkdir /home/wikileaks/lib

Ensuite copions les binaires nécessaires pour faire un Rsync :
# cp `which bash` /home/wikileaks/bin/bash # cp `which rsync` /home/wikileaks/bin/rsync

Pour que ces binaires fonctionnent, il faut aussi copier les librairies nécessaires. Pour lister ces librairies vous pouvez exécuter un ldd puis copiez une à une ces libraires
# ldd `which bash` `which rsync` # cp /lib/libncurses.so.5 /home/wikileaks/lib/ ...
Attention : si votre serveur est un système 64bits il faudra créer le dossier /home/wikileaks/lib64/ et le peupler avec les librairies venant de /lib64.

Un dummyshell

Oui, je suis d’accord, les commandes internes de bash c’est encore trop! Nous permettons un accès SSH qui pourrait potentiellement lancer une fork bomb par exemple. Nous allons donc créer un shell stupide qui ne permet que de lancer un serveur Rsync. Créez le fichier /home/wikileaks/bin/dummyshell :
#!/bin/bash if (( $# == 0 )); then printf "%s\n" "shell access is disabled. sorry." exit 1 elif (( $# == 2 )) && [[ $1 == "-c" && $2 == "rsync --server"* ]]; then exec $2 fi

Il faut ensuite le rendre exécutable et utilisé comme shell par défaut de l’utilisateur :
# chmod +x /home/wikileaks/bin/dummyshell # ln -s /home/wikileaks/bin/dummyshell /bin/dummyshell # usermod -s /bin/dummyshell wikileaks
C’est maintenant officiel, l’utilisateur wikileaks ne peut rien faire de plus que lancer un serveur Rsync ! Et il y a aussi la sécurité du Chroot.

Test

Je vous recommande de tester le tout, pour être sûr que Wikileaks pourra uploader son site sur votre serveur. Pour cela ajoutez votre propre clé RSA dans une nouvelle ligne de /home/wikileaks/.ssh/authorized_keys et tentez d’envoyer un fichier :
$ rsync -ave ssh test.html wikileaks@votreServeur:/www

Vous pouvez également éprouver la sécurité en tentant de vous connecter en SSH ou d’exécuter une commande en SSH -t.

Configurer un nom de domaine et un VirtualHost

Je suppose que vous vous en sortirez sur ce point-là : créez un nom de domaine (ou un sous-domaine) pour votre miroir et configurez votre serveur web en conséquence.

Le DocumentRoot à spécifier est bien /home/wikileaks/www

Profitez-en pour empêcher l’exécution de scripts sur le répertoire :
AllowOverride None Options -ExecCGI

Soumettre votre miroir à Wikileaks

Rendez-vous sur http://46.59.1.2/mass-mirror.html et soumettez votre miroir !

Sous “absolute path where we should upload the html data” mettez simplement “/www/”.

Normalement Wikileaks pushera l’entièreté du site sur votre serveur. Félicitations, vous défendez la liberté d’expression sans risque majeur pour votre serveur !

Si vous avez aimé ce post...

Ifconfig.me, connaitre son IP publique en un rien de temps

roidelapluie — Thu, 12 Aug 2010 10:03:07 +0000

Beaucoup d’entre nous sont le plus souvent connectés en NAT derrière un routeur ou connectés derrière un proxy, voire un VPN. Difficile donc de connaitre son IP publique ou son ISP en quelques instants. Certes, pas mal de sites de type «What is my IP?» permettent d’accéder à ce genre d’infos, mais ma préférence va vers ifconfig.me.

Si vous ouvrez cette URL depuis un navigateur internet, vous y verrez les informations habituelles que ce genre de site offre: IP, ISP, informations sur le navigateur, et géolocalisation de l’IP. Ce n’est pas cela qui rend ce site pratique et indispensable.

Ifconfig.me a la particularité d’être utilisable en ligne de commande, avec le célèbre client cURL. Prenons un exemple simple:

$ curl ifconfig.me

Renverra l’adresse IP publique directement. Ni plus, ni moins. Pas besoin d’ouvrir un navigateur internet, ni de devoir parcourir une page à la recherche de l’élément recherché.

Il existe d’autres commandes, telles que:

$ curl ifconfig.me/host $ curl ifconfig.me/ua $ curl ifconfig.me/all

Ces trois commandes renverront respectivement l’éventuel hostname lié à votre IP publique, votre user agent et l’ensemble des infos données par le site. La liste complète des commandes est disponible sur le site.

Si vous avez aimé ce post...

Eeegw – part III – Quality Of Service aka QOS

bragon — Mon, 24 May 2010 15:53:13 +0000

La Quality Of Service (QOS) , qualité de service en français, intervient principalement au niveau 3 du modèle OSI.
Il faut donc placer ses scripts de QOS sur la passerelle de votre réseau, c’est la raison pour laquelle, mettre en place de la QOS sur la eeegw prend tout son sens.

N’hésitez pas à revenir sur les précédents articles sur la eeegw :
eeegw part I
eeegw part II

Si vous avez besoin d’un rafraîchissement sur le concept, je vous oriente vers la page Qualité de service de Wikipedia.

La partie qui clairement nous intéresse ici est décrite au chapitre Ordonnancement :
L’ordonnancement désigne l’ensemble des méthodes visant à modifier l’ordre de départ des paquets, en remplacement de la règle du « premier arrivé, premier servi ».

Une de ses applications les plus courantes consistera ainsi à donner priorité à certains types de trafic.

Grosso modo j’ai mis en place de la QOS sur ma eeegw car j’en avais marre que mes communications SIP (Téléphonie voir futur article :p) ne soient pas de bonne qualité, lors d’upload de pièces jointes via mon mailer ou lorsque j’avais besoin d’utiliser beaucoup d’upload en même temps qu’une communication téléphonique.

Voici mon tout premier script de QOS, ill date un peu et est loin de bien fonctionner
Je vous le montre afin que vous voyez un peu à quoi on s’attaque en parlant de QOS :

Script de QOS exemple1 basé sur HTB

#!/bin/bash

#Constantes
LOCALNET="213.41.xx.xx/255.255.255.255"
MARKPRIO1="1"
MARKPRIO2="2"
MARKPRIO3="3"
MARKPRIO4="4"
MARKPRIO5="5"
MARKPRIO6="6"
MARKPRIO7="7"

IFACE=eth0

UPRATE="8mbit"
DOWNRATE="0.8mbit"

PRIORATE1="5mbit"
PRIORATE2="3mbit"
PRIORATE3="2mbit"
PRIORATE4="0.5mbit"

QUANTUM1="12187"
QUANTUM2="8625"
QUANTUM3="5062"
QUANTUM4="1500"

BURST1="1000k"
BURST2="400k"
BURST3="200k"
BURST4="10k"

CBURST1="300k"
CBURST2="200k"
CBURST3="10k"
CBURST4="1k"

iptables -t mangle -F OUTPUT
iptables -t mangle -F FORWARD

iptables -t mangle -A FORWARD -p icmp -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p icmp -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A INPUT -p icmp -j MARK --set-mark $MARKPRIO1

iptables -t mangle -A FORWARD -p tcp --dport 22 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p tcp --dport 22 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A INPUT -p tcp --dport 22 -j MARK --set-mark $MARKPRIO1

iptables -t mangle -A FORWARD -p tcp --dport 687 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p tcp --dport 687 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A INPUT -p tcp --dport 687 -j MARK --set-mark $MARKPRIO1

iptables -t mangle -A FORWARD -p udp --dport 687 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p udp --dport 687 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A INPUT -p udp --dport 687 -j MARK --set-mark $MARKPRIO1

iptables -t mangle -A FORWARD -p tcp --dport 5060 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p tcp --dport 5060 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A INPUT -p tcp --dport 5060 -j MARK --set-mark $MARKPRIO1

iptables -t mangle -A FORWARD -p udp --dport 5060 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A OUTPUT -p udp --dport 5060 -j MARK --set-mark $MARKPRIO1
iptables -t mangle -A INPUT -p udp --dport 5060 -j MARK --set-mark $MARKPRIO1

iptables -t mangle -A FORWARD -p tcp --dport 25 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A OUTPUT -p tcp --dport 25 -j MARK --set-mark $MARKPRIO3

iptables -t mangle -A FORWARD -p tcp --dport 143 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A OUTPUT -p tcp --dport 143 -j MARK --set-mark $MARKPRIO3

iptables -t mangle -A FORWARD -p tcp --dport 80 -j MARK --set-mark $MARKPRIO2
iptables -t mangle -A OUTPUT -p tcp --dport 80 -j MARK --set-mark $MARKPRIO2
iptables -t mangle -A INPUT -p tcp --dport 80 -j MARK --set-mark $MARKPRIO2

iptables -t mangle -A FORWARD -p tcp --dport 443 -j MARK --set-mark $MARKPRIO2
iptables -t mangle -A OUTPUT -p tcp --dport 443 -j MARK --set-mark $MARKPRIO2
iptables -t mangle -A INPUT -p tcp --dport 443 -j MARK --set-mark $MARKPRIO2

iptables -t mangle -A FORWARD -p tcp --dport 21 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A OUTPUT -p tcp --dport 21 -j MARK --set-mark $MARKPRIO3
iptables -t mangle -A INPUT -p tcp --dport 21 -j MARK --set-mark $MARKPRIO3

ifconfig $IFACE txqueuelen 128

tc qdisc add dev $IFACE root handle 1:0 htb default 103 r2q 1
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate $UPRATE burst $BURST1 cburst $CBURST1

tc class add dev $IFACE parent 1:1 classid 1:101 htb rate $PRIORATE1 ceil $UPRATE quantum $QUANTUM1 burst $BURST1 cburst $CBURST1 prio 0
tc class add dev $IFACE parent 1:1 classid 1:102 htb rate $PRIORATE2 ceil $UPRATE quantum $QUANTUM2 burst $BURST2 cburst $CBURST2 prio 1
tc class add dev $IFACE parent 1:1 classid 1:103 htb rate $PRIORATE3 ceil $UPRATE quantum $QUANTUM3 burst $BURST3 cburst $CBURST3 prio 2
tc class add dev $IFACE parent 1:1 classid 1:104 htb rate $PRIORATE4 ceil $P2PRATE quantum $QUANTUM4 burst $BURST4 cburst $CBURST4 prio 3

tc filter add dev $IFACE parent 1:0 protocol ip prio 0 handle $MARKPRIO1 fw classid 1:101
tc filter add dev $IFACE parent 1:0 protocol ip prio 1 handle $MARKPRIO2 fw classid 1:102
tc filter add dev $IFACE parent 1:0 protocol ip prio 2 handle $MARKPRIO3 fw classid 1:103
tc filter add dev $IFACE parent 1:0 protocol ip prio 3 handle $MARKPRIO4 fw classid 1:104

tc qdisc add dev $IFACE parent 1:101 sfq perturb 16 quantum $QUANTUM1
tc qdisc add dev $IFACE parent 1:102 sfq perturb 16 quantum $QUANTUM2
tc qdisc add dev $IFACE parent 1:103 sfq perturb 16 quantum $QUANTUM3
tc qdisc add dev $IFACE parent 1:104 sfq perturb 16 quantum $QUANTUM4

Ce script est loin d’être optimisé.
Son but était de marquer via iptables certain type de flux, afin de les faire passer via des règles de tc/qdisc pour en limiter la bande passante. il utilise HTB (voir plus loin)
Ce script manque clairement de flexibilité.

Soyons clairs, la QOS sous GNU/Linux est un cauchemar à gérer.
Autre concept à bien avoir en tête, vous ne pouvez gérer la QOS que de votre lien sortant, en aucun cas vous ne pouvez gérer ce qui rentre via votre lien. Par analogie, vous ne pouvez pas contrôler la pluie qui tombe dans votre piscine, par contre vous pouvez contrôler l’eau que vous enlevez, et l’eau que vous décidez de rajouter.
Il existe quelques bidouilles afin de réussir tout de même à gérer ce trafic entrant, nous allons essayer de vous présenter ça un peu plus loin dans l’article.

Nous allons donc utiliser Mangle de iptables (pour qos.sh) ainsi que la fonction de mark des packets de iptables.
Il faut donc aller activer cela dans le noyau.

# # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y

Scheduler / Ordonnanceur

Mise en place des outils

En tout premier lieu vous aurez besoin de iptables et de iproute2
iproute2 est une suite d’utilitaires en ligne de commande qui vous permettent de manipuler les structures kernel liées aux couches réseau de votre machine.

Gentoo :

emerge -av iproute2 iptables

Debian :
apt-get install iptables iproute2

Verifiez que vous avez bien l’utilitaire tc :


eeegw:~# tc

Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }

       tc [-force] -batch file

where  OBJECT := { qdisc | class | filter | action | monitor }

       OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -p[retty] | -b[atch] [file] }

Traduction du manuel de tc

Les “classful qdiscs” sont :

CBQ

“Class Based Queueing” implémente une hierarchie de classes. il contient des éléments de shaping comme des fonctions de prioritisations. Le shape est calculé à partir de latence et de taille de packets

HTB

“Hierarchy Token Bucket”
HTB permet de garantir de la bande passante a une classe, définir des limites entre les classes et de fixer des priorités entre elles.

PRIO

PRIO qdisc n’effectue pas de traffic shapping en tant que tel, il permet juste de fixer des priorités entre les différents type de protocoles transitant dans le lien.
PRIO permet de classifier les classes qui prennent en priorité de la bande passante, en ne laissant aux autres que ce qui reste de bande passante disponible.

Qu’est-ce qu’une classe

Une classe forme, en fait, un arbre avec des branches.
Le but est de former une classe root qui va permettre de faire rentrer tout le trafic et, en fonction des protocoles, on va faire passer le traffic dans différentes branches.

ici nous définissons nos classes root :

## On met en place la classe root pour la BP disponible.
/sbin/tc qdisc add dev $EXTERNAL_IFACE root handle 1: cbq avpkt 1000 bandwidth $BNDWIDTH
## Match ici l'upload de la connexion
/sbin/tc class add dev $EXTERNAL_IFACE parent 1: classid 1:1 cbq rate ${UPLINK}kbit allot 1500 prio 5 bounded isolated

Datagrame IPv4 et Type Of Service : TOS

Tableau des TOS possible dans un Datagram IPv4

Binaire	Décimal	Signification
1000	8	Minimise le Délai (Minimize delay) (md)
0100	4	Maximalise le Débit (Maximize throughput) (mt)
0010	2	Maximalise la Fiabilité (Maximize reliability) (mr)
0001	1	Minimalise le Coût Monétaire (Minimize monetary cost) (mmc)
0000	0	Service Normal

TOS	Binaire	Décimal	Signification	Priorité Linux	Bande
0×0	0000	0	Service Normal	0 Best Effort	1
0×2	0001	1	Minimise le Coût Monétaire (mmc)	1 Filler	2
0×4	0010	2	http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI	0 Best Effort	1
0×6	0011	3	mmc+mr	0 Best Effort	1
0×8	0100	4	Maximalise le Débit (mt)	2 Masse	2
0xa	0101	5	mmc+mt	2 Masse	2
0xc	0110	6	mr+mt	2 Masse	2
0xe	0111	7	mmc+mr+mt	2 Masse	2
0×10	1000	8	Minimise le Délai (md)	6 Interactive	0
0×12	1001	9	mmc+md	6 Interactive	0
0×14	1010	10	mr+md	6 Interactive	0
0×16	1011	11	mmc+mr+md	6 Interactive	0
0×18	1100	12	mt+md	4 Int. Masse	1
0x1a	1101	13	mmc+mt+md 4 Int. Masse 1	4 Int. Masse	1
0x1c	1110	14	mr+mt+md	4 Int. Masse	1
0x1e	1111	15	mmc+mr+mt+md	4 Int. Masse	1

Exemple de ce qu’on peut faire avec TOS

L’intérêt de la QoS sous Linux est très souvent associé à la priorisation de flux interactifs via iptables.
Par exemple, vous ne souhaitez pas que votre session ssh lag à cause d’un utilisateur qui est en train de monopoliser la bande passante de votre réseau en téléchargeant une bande annonce sur internet ?
Nous allons ici, à titre d’exemple, optimiser les trafics courants avec iptables, à savoir ssh :

# Priorisation des connexions ftp et ssh
iptables -A PREROUTING -t mangle -p tcp -sport ssh -j TOS -set-tos Minimize-Delay
# On donne un maximum de débit aux transferts scp
iptables -A PREROUTING -t mangle -p tcp -sport ssh -j TOS -set-tos Maximize-Throughput

Voici le script de QOS final basé sur CTB et PRIO (celui que j’utilise en production)

#!/bin/bash
### Script de reservation de bande passante par bragon

## On fixe quelques variables

EXTERNAL_DOWNLINK_KBPS="6400"
## je sais downloader à  ~800ko/s ma limite est donc a 6400 Kbps
EXTERNAL_DL_IPSEC_KBPS="1024"
EXTERNAL_DL_PPTP_KBPS=""
EXTERNAL_DL_ICA_KBPS=""
EXTERNAL_DL_TSE_KBPS="128"
EXTERNAL_DL_SMTP_KBPS="512"
EXTERNAL_DL_HTTP_KBPS="1024"
EXTERNAL_DL_OTHERTCP_KBPS="2048"
EXTERNAL_DL_OTHERTCP_PORT="2048"
## je sais uploader à environ 80Ko/s je fixe donc ma limite a 512 afin d'être sûr de ne pas engendrer de lag.
EXTERNAL_UPLINK_KBPS="512"
EXTERNAL_UL_IPSEC_KBPS=""
EXTERNAL_UL_IPSEC_SHARE=""
EXTERNAL_UL_PPTP_KBPS=""
EXTERNAL_UL_PPTP_SHARE=""
EXTERNAL_UL_ICA_KBPS=""
EXTERNAL_UL_ICA_SHARE=""
EXTERNAL_UL_TSE_KBPS="512"
EXTERNAL_UL_TSE_SHARE="512"
EXTERNAL_UL_SMTP_KBPS="256"
EXTERNAL_UL_SMTP_SHARE="256"
EXTERNAL_UL_HTTP_KBPS="32"
EXTERNAL_UL_HTTP_SHARE=""
EXTERNAL_UL_OTHERTCP_KBPS=""
EXTERNAL_UL_OTHERTCP_SHARE=""
EXTERNAL_UL_OTHERTCP_PORT=""
EXTERNAL_UL_VOIP_KBPS="256"
EXTERNAL_UL_VOIP_SHARE="isolated"
EXTERNAL_DEV_BANDWIDTH="" 

## CE script de QOS s'applique à toutes les interface dans MON cas cela convient.
## Je vous conseille de retirer votre interface LAN du match si vous avez plusieurs interfaces reseau.
## La commande va permettre de lister toutes les interfaces et d'appliquer les regles de QOS dessus.
## On match aussi les interfaces tap

if [ -n "$EXTERNAL_DOWNLINK_KBPS" ] && [ -n "$EXTERNAL_UPLINK_KBPS" ] && echo $INTERFACE | egrep -q "(eth[023]|ppp[0-9]|ippp0|tap[0-3])" ; then

#In kilobits
DOWNLINK=$EXTERNAL_DOWNLINK_KBPS
UPLINK=$EXTERNAL_UPLINK_KBPS
BNDWIDTH=$EXTERNAL_DEV_BANDWIDTH

if [ -z "$BNDWIDTH" ]; then
    BNDWIDTH="100mbit"
fi

## on clean deja les parametres en tout premier lieu
## On vide toutes les regles pouvant deja etre en place.
/sbin/tc qdisc del dev $EXTERNAL_IFACE root    2> /dev/null > /dev/null
/sbin/tc qdisc del dev $EXTERNAL_IFACE ingress 2> /dev/null > /dev/null

# install root CBQ # On met en place la policy root, les autres policies seront liées à celle-ci
## cbq avpkt : la taille moyenne des packets en bytes sont necessaire afin de calculer l'idle maximum
## bandwidth rate : pour determiner l'idle time cbq doit forcement connaitre la bande passante de l'interface physique.
/sbin/tc qdisc add dev $EXTERNAL_IFACE root handle 1: cbq avpkt 1000 bandwidth $BNDWIDTH

## allot bytes : utile pour calculer le temps de transmission des packets entre tables, valeur liée à avpkt
/sbin/tc class add dev $EXTERNAL_IFACE parent 1: classid 1:1 cbq rate ${UPLINK}kbit allot 1500 prio 5 bounded isolated

# voip (udp sip 5060 et asterisk 4569)
## Tout ce qui match cette règle possede une reservation CBQ de $EXTERNAL_UL_VOIP_KBPS | priorité numéro 1 !
if [ -n "$EXTERNAL_UL_VOIP_KBPS" ]; then
/sbin/tc class add dev $EXTERNAL_IFACE parent 1:1 classid 1:5 cbq rate ${EXTERNAL_UL_VOIP_KBPS}kbit allot 1600 prio 1 avpkt 1000 $EXTERNAL_UL_VOIP_SHARE

## pfifo : pure 'premier entré premier sortie' qdisc, évite la congestion de packet dans la classid 1:5
/sbin/tc qdisc add dev $EXTERNAL_IFACE parent 1:5 handle 5: pfifo limit 10

 # sip prioritaire 5 !
## filter: utile afin de savoir dans quel classfull qdisc, un packet va etre envoye.
## on peut filter les packets a partir de leur TOS : Type Of Service
/sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 5 u32 match ip sport 5060 0xffff match ip protocol 17 0xff flowid 1:5
/sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 5 u32 match ip dport 5060 0xffff match ip protocol 17 0xff flowid 1:5

# rtp (tos 0x10 et udp) (voir le tableau recap de TOS)
/sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 5 u32 match ip tos 0x10 0xff match ip protocol 17 0xff flowid 1:5

let UPLINK=UPLINK-EXTERNAL_UL_VOIP_KBPS
fi

# SMTP
if [ -n "$EXTERNAL_UL_SMTP_KBPS" ]; then
 /sbin/tc class add dev $EXTERNAL_IFACE parent 1:1 classid 1:44 \
 cbq rate ${EXTERNAL_UL_SMTP_KBPS}kbit allot 1600 prio 1 avpkt 1000 $EXTERNAL_UL_SMTP_SHARE
 /sbin/tc qdisc add dev $EXTERNAL_IFACE parent 1:44 handle 44: sfq perturb 10

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 44 u32 \
 match ip dport 25 0xffff match ip protocol 6 0xFF match ip firstfrag flowid 1:44

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 44 u32 \
 match ip dport 2525 0xffff match ip protocol 6 0xFF match ip firstfrag flowid 1:44

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 44 u32 \
 match ip dport 587 0xffff match ip protocol 6 0xFF match ip firstfrag flowid 1:44

let UPLINK=UPLINK-EXTERNAL_UL_SMTP_KBPS
fi

# HTTP
if [ -n "$EXTERNAL_UL_HTTP_KBPS" ]; then
 /sbin/tc class add dev $EXTERNAL_IFACE parent 1:1 classid 1:46 \
 cbq rate ${EXTERNAL_UL_HTTP_KBPS}kbit allot 1600 prio 1 avpkt 1000 $EXTERNAL_UL_HTTP_SHARE
 /sbin/tc qdisc add dev $EXTERNAL_IFACE parent 1:46 handle 46: sfq perturb 10

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 46 u32 \
 match ip dport 80 0xffff match ip protocol 6 0xFF match ip firstfrag flowid 1:46
 let UPLINK=UPLINK-EXTERNAL_UL_HTTP_KBPS
fi

# OTHERTCP
if [ -n "$EXTERNAL_UL_OTHERTCP_KBPS" ]; then
 /sbin/tc class add dev $EXTERNAL_IFACE parent 1:1 classid 1:48 \
 cbq rate ${EXTERNAL_UL_OTHERTCP_KBPS}kbit allot 1600 prio 1 avpkt 1000 $EXTERNAL_UL_OTHERTCP_SHARE
 /sbin/tc qdisc add dev $EXTERNAL_IFACE parent 1:48 handle 48: sfq perturb 10

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 48 u32 \
 match ip dport $EXTERNAL_UL_OTHERTCP_PORT 0xffff match ip protocol 6 0xFF match ip firstfrag \
 flowid 1:48
 let UPLINK=UPLINK-EXTERNAL_UL_OTHERTCP_KBPS
fi

if [ $UPLINK -gt 0 ]; then

# classe interactive
/sbin/tc class add dev $EXTERNAL_IFACE parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit allot 1600 prio 2 avpkt 1000
/sbin/tc qdisc add dev $EXTERNAL_IFACE parent 1:10 handle 10: sfq perturb 10

 # TOS Minimum Delay (ssh, NOT scp) in 1:10: donc on lui donne un priorité de 1000
 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 1000 u32 match ip tos 0x10 0xff  flowid 1:10

 # ICMP (ip protocol 1) dans la classe interactive 1:10 donc on lui donne un priorité de 1001
 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1:0 protocol ip prio 1001 u32 match ip protocol 1 0xff flowid 1:10

 # Pour accélérer le downaload lorsqu'un upload est en court il faut bien faire les ACK dans la classe interactive.

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1: protocol ip prio 1002 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10

# classe bulk

 /sbin/tc class add dev $EXTERNAL_IFACE parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
   allot 1600 prio 3 avpkt 1000
 /sbin/tc qdisc add dev $EXTERNAL_IFACE parent 1:20 handle 20: sfq perturb 10

 /sbin/tc filter add dev $EXTERNAL_IFACE parent 1: protocol ip prio 1003 u32 \
   match ip dst 0.0.0.0/0 flowid 1:20

else
 echo "Error: no bandwidth left for uplink on $EXTERNAL_IFACE: $UPLINK" 1>&2
 /sbin/tc qdisc del dev $EXTERNAL_IFACE root    2> /dev/null > /dev/null
fi

#
# Il faut ralentir les download afin d'éviter que l'ISP mette en queue ce qui engendre le lag
# Les ISP ont tendance à avoir des queues énormes afin d'être sûrs que les downloads seront rapides.
#
# police ingress:

/sbin/tc qdisc add dev $EXTERNAL_IFACE handle ffff: ingress

# voip
# tout ce qui est voip ne doit pas être limité, donc on fait un match simple
# iax2

/sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 5 u32 \
  match ip sport 4569 0xffff match ip protocol 17 0xff flowid :1
 /sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 5 u32 \
  match ip dport 4569 0xffff match ip protocol 17 0xff flowid :1

# sip # priorite 5 !
/sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 5 u32 \
  match ip sport 5060 0xffff match ip protocol 17 0xff flowid :1
/sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 5 u32 \
  match ip dport 5060 0xffff match ip protocol 17 0xff flowid :1

/sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 5 u32 \
match ip sport 5061 0xffff match ip protocol 17 0xff flowid :1

# rtp (tos 0x10 et udp) # priorte 5 !
/sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 5 u32 \
  match ip tos 0x10 0xff match ip protocol 17 0xff flowid :1

# SMTP
if [ -n "$EXTERNAL_DL_SMTP_KBPS" ]; then
 /sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 44 u32 \
 match ip sport 25 0xffff match ip protocol 6 0xFF match ip firstfrag \
 police rate ${EXTERNAL_DL_SMTP_KBPS}kbit burst 10k drop flowid :1
 let DOWNLINK=DOWNLINK-EXTERNAL_DL_SMTP_KBPS
fi

# HTTP
if [ -n "$EXTERNAL_DL_HTTP_KBPS" ]; then
 /sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 46 u32 \
 match ip sport 80 0xffff match ip protocol 6 0xFF match ip firstfrag \
 police rate ${EXTERNAL_DL_HTTP_KBPS}kbit burst 10k drop flowid :1
 let DOWNLINK=DOWNLINK-EXTERNAL_DL_HTTP_KBPS
fi

# OTHERTCP qui ne matchent pas les règles précédentes
if [ -n "$EXTERNAL_DL_OTHERTCP_KBPS" ]; then
 /sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 48 u32 \
 match ip sport $EXTERNAL_DL_OTHERTCP_PORT 0xffff match ip protocol 6 0xFF match ip firstfrag \
 police rate ${EXTERNAL_DL_OTHERTCP_KBPS}kbit burst 10k drop flowid :1
 let DOWNLINK=DOWNLINK-EXTERNAL_DL_OTHERTCP_KBPS
fi

##règles de burst
if [ $DOWNLINK -gt 0 ]; then
 /sbin/tc filter add dev $EXTERNAL_IFACE parent ffff: protocol ip prio 1000 u32 \
 match ip src 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
else
 echo "Error: no bandwidth left for downlink on $EXTERNAL_IFACE: $DOWNLINK" 1>&2
 /sbin/tc qdisc del dev $EXTERNAL_IFACE ingress 2> /dev/null > /dev/null
fi

# initial if (are the 2 required variables defined?)
fi

N’hésitez pas à le tester, il déboite

Si vous avez aimé ce post...

maintenir son DNS menteur avec Adblock

ckg — Tue, 11 May 2010 16:39:21 +0000

Filtrer les web-espions (google analytics, xiti …) n’est qu’un début. Le nombre de fichiers javascript, css et images en tout genre destinés à vous profiler est non négligeable, mais le pire est en fait le nombre de publicités pourrissant votre expérience utilisateur. Comment peut-on intégrer dans bind9, les filtres adblock que l’on a construit minutieusement ?

Les régies de publicité ne sont pas honnêtes, elles proposent de la pornographie (bon ça c’est pas grave), des jeux en ligne (ça ne touche que les cons qui croient gagner face à un logiciel), des faux antivirus (là c’est moins drôle) voire des mouchards (là je ne ris plus du tout).
Filtrer les pubs est parfois considéré comme une attitude hostile vis à vis de l’éditeur du contenu que vous vous apprêtez à consommer. Vous refusez la contrepartie d’un service gratuit, vous êtes fourbes, vous mériteriez d’aller casser des cailloux à Cayenne et qu’on fasse un lolcat avec votre chien.

Dans cette page nous allons capitaliser sur le travail bienveillant des furieux de chez yoyo.org, utiliserons les excellentes listes de fanboy et de liam une liste adblock polonaise et nous finirons par intégrer la liste adblock de notre profil firefox.
Les trois source seront formatées en un fichier de configuration pour notre DNS menteur.

Chez yoyo.org

Chez yoyo ils sont très geek. Il est possible de télécharger une liste toute prête des données qui nous intéresse. Ce qui nous importe le plus, c’est le formulaire de la section adservers. Nous allons choisir le format de sortie “AdBlock” pour le champ “list ad server hostnames:”.
Nous invoquerons cette liste par l’URL suivante http://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblock pour ne plus avoir à faire du clic-clic lors des mises à jour.

L’objectif est d’obtenir des hosts de cette liste, ce qui se fait très simplement par :
curl -s 'http://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblock' | egrep '^[a-z0-9]*\.[a-z0-9]*' | sort -u
Ce qui donne :
a.collective-media.net a.consumer.net (...) kliks.nl klipads.dvlabs.com (...) zintext.com zmedia.com
Le site pgl.yoyo.org est très riche, la section adservers est une mine d’information pour le filtrage responsable en environnement réseau très hétérogènes.

Liste adblock polonaise

Commençons par une digression sur la Creative Commons : c’est un concept de licence que je n’apprécie pas. La notion de paternité pour un fichier de configuration me sidère.
Les excellentes listes adblock de Fanboy et Liam sont en CC NC BY SA, leur réutilisation est incompatible avec la licence initiale (WTFPL) compatible avec la licence utilisée par Geekfault pour les articles. Bref, nous allons nous orienter vers une liste plus amicale.

Ce qui nous emmène à l’utilisation de la liste du site AdblockList.org (en polonais).
Voici les 4 structures possibles :
(...)


http://*.statcounter.com/*
(...)
http://partner.ceneo.pl/pp/*

(...) |http://mklik.gazeta.pl/* (...) ||nuggad.net/* (...)
La différence entre webespion.com, |webespion.com et ||webespion.com est documenté dans la section filters de AdblockPlus.
Ce qui nous conduit a l’expression régulière suivante :
'^|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$'
Utilisable par exemple comme ceci :
$ curl -s http://adblocklist.org/adblock-pxf-polish.txt | egrep '^\|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$'


http://r.reklama.biz/*
http://*stats.wordpress.com/*
|http://mklik.gazeta.pl/*
http://rek.www.wp.pl/*
http://kropka.onet.pl/*
http://csr.onet.pl/*

||nuggad.net/* (...)
Avec perl nous allons, en une seule ligne (merci madx), regrouper le egrep ET nettoyer la sortie
$ curl -s http://adblocklist.org/adblock-pxf-polish.txt | perl -ne 'm;^\|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^\|{0,2}(http://)?\*?.?([^/#]*)/; && print $2."\n";' r.reklama.biz stats.wordpress.com mklik.gazeta.pl rek.www.wp.pl kropka.onet.pl csr.onet.pl nuggad.net (...)

La liste adblock de notre profil Firefox

Maintenant que nous savons sélectionner depuis une liste adblock, les filtres intégrables à bind9 et que nous savons nettoyer nous pouvons parcourir la liste adblock dans nos profils firefox :
$ (for i in ~/.mozilla/firefox/*/adblockplus/patterns*; do perl -ne 'm;^|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^|{0,2}(http://)?*?.?([^/#]*)/; && print $2." <-- ".$_."n";' < $i;done;) | sort -u | less
Ce qui donne chez moi :
(...) 5killspyware.eu <-- ||5killspyware.eu/ 5l2o8.com <-- ||5l2o8.com/ 5mariasara.cn <-- ||5mariasara.cn/ 5may2009.com <-- ||5may2009.com/ 5removespyware.com <-- ||5removespyware.com/ 5rublei.com <-- ||5rublei.com/ 5w90.co.cc <-- ||5w90.co.cc/ 5we5.com <-- ||5we5.com/ 5yttrre.cn <-- ||5yttrre.cn/ 6-tube-world.com <-- ||6-tube-world.com/ 60sys60.cn <-- ||60sys60.cn/
On peut donc parcourir la liste temporaire et regarder si il n'y a pas trop de faux positifs. A plusieurs milliers de lignes (21282 très précisément sur mes profils firefox) il ne faut pas hésiter à faire un lecture étalée dans le temps.
Normalement il n'y aura pas trop de surprises, nous obtenons une liste de hosts correctes comme ceci :
(for i in ~/.mozilla/firefox/*/adblockplus/patterns*; do perl -ne 'm;^|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^|{0,2}(http://)?*?.?([^/#]*)/; && print $2."n";' < $i;done;) | sort -u

Création du fichier blackhole.conf

Pour rappel, notre structure de blackhole.conf est:
zone "HOTE_A_FILTRER" { type master; notify no; file "null.zone.file"; };
Nous savons que la commande pour extraire HOTE_A_FILTRER avec :

la liste de chez yoyo :

curl -s 'http://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblock' | egrep '^[a-z0-9]*\.[a-z0-9]*'

la liste adblock polonaise :

curl -s http://adblocklist.org/adblock-pxf-polish.txt | perl -ne 'm;^\|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^\|{0,2}(http://)?\*?.?([^/#]*)/; && print $2."\n";'

notre liste adblock maison :

(for i in ~/.mozilla/firefox/*/adblockplus/patterns*; do perl -ne 'm;^\|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^\|{0,2}(http://)?\*?.?([^/#]*)/; && print $2."\n";' < $i;done;)

Nous pouvons donc écrire notre générateur de blackhole.conf en une seule ligne (bash) :
(for i in `((curl -s 'http://pgl.yoyo.org/adservers/serverlist.php?hostformat=adblock' | egrep '^[a-z0-9]*\.[a-z0-9]*');(curl -s http://adblocklist.org/adblock-pxf-polish.txt | perl -ne 'm;^\|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^\|{0,2}(http://)?\*?.?([^/#]*)/; && print $2."\n";');(for i in ~/.mozilla/firefox/*/adblockplus/patterns*; do perl -ne 'm;^\|{0,2}(http://)?[^/.]+.[^/#]+/[^/$a-z0-9]*$; && m;^\|{0,2}(http://)?\*?.?([^/#]*)/; && print $2."\n";' < $i;done;) ) | sort -u `; do echo "zone "$i" { type master; notify no; file \"null.zone.file\"; };";done;)> blackhole.conf

Conclusion

Nous voila donc avec un blackhole.conf prêt a être injecté dans notre bind9 local comme expliqué dans l'article de base du dns menteur.

J'attire votre attention sur le fait que cette liste brute a de grandes chances de ne pas être tout à fait conforme à votre utilisation du web. Sur plus de 22000 entrées (ce qui est mon cas), il y a de grandes chances d'avoir des doublons genre xyz.webespion.org et webespion.org par exemple.
Le principal risque des listes adblock est le faux-positif, ce risque est transmis intégralement. Je vous invite à manier tout ceci avec prudence.

Si vous avez aimé ce post...

DNS menteur, une autre méthode anti-curieux

ckg — Sat, 24 Apr 2010 13:30:37 +0000

StatsCounter, SiteMeter, Google Analytics & Urchin, Xiti… sont les plus populaires des outils de statistiques proposés aux webmestres. Ils sont très simples à mettre en œuvre et proposent des résultats très pertinents.

L’intérêt de ces outils est surtout le profilage à des fins techniques (versions, systèmes d’exploitations et résolutions des navigateurs…) et à des fins de positionnement sur le web (liens directs, liens indirects, durée moyenne de lecture).

La contre-partie de la gratuité de ces outils est la valorisation commerciale de vos profils. Le webmestre rémunère l’éditeur du service avec votre profil… sans votre consentement.

D’un point de vue éthique, ce procédé est peu honorable. D’un point de vue technique c’est guère mieux : augmentation sensible du nombre de requêtes, charge processeur superflue, stockage de cookies inutile, bande passante gaspillée.

WebSpy : l’autre côté obscur de la Force

Comment fonctionne le profilage sur le Ternet ? Est-ce généralisé ? Est-ce grave ? Quels sites profilent qui ? Quelles méthodes sont employées ? Quels types de sites communiquent aux méchants espions ? Comment maitriser ces informations sortantes ? Comment assurer cette maitrise sur un logiciel, une machine, un réseau ?

Évidemment, LA réponse universelle s’applique à toutes ces questions. Mais ne nous privons pas d’une approche plus technique en prenant comme sujet d’étude Geekfault. Il parait que c’est vendeur de critiquer Google, ne boudons pas notre plaisir et stigmatisons son outil de statistiques : Google Analytics.

Plan de l’article

Dans la section suivante, nous allons illustrer et quantifier ce gâchis avec des outils simples d’accès. Si vous êtes déjà adepte du NoScript, Adblock, Privoxy, Squid+adzap vous pouvez aller directement au chapitre 5.
Après avoir abordé les protections individuelles, nous traiterons des protections collectives de type proxies filtrants.
On abordera ensuite le vif du sujet avec le filtrage par DNS menteur de manière théorique pour mieux appréhender cette autre protection collective.
Le principe sera ensuite présenté dans deux scenarii avec bind : Gentoo/Linux + Lighttpd et FreeBSD + Apache.
On fera un bref récapitulatif des avantages et des inconvénients de chaque solutions et on rendra à César ce qui appartenait a feu CiteWeb dans la conclusion.

Bonne lecture !

Présentation et quantification de la nuisance

Cette nuisance est pénalisante sur les faibles configurations et les gadgets comme les smartphones et les consoles portables. Elle est également perceptible sur les lignes ADSL à faible débit.

Une navigation “vanilla” c’est en fait ça :

La première étape pour afficher la page d’accueil de Geekfault est la résolution du nom de domaine en adresse IP par un DNS externe :
Une connexion directe sur la machine par HTTP permet de récupérer le fichier index (typiquement index.php) :
Le navigateur lit cette page pour établir la liste des fichiers à télécharger en plus (js,png,css,…) et la liste des éléments externes au site (dont ceux des web-espions). Les éléments externes doivent d’abord être recherchés par leur adresse IP toujours avec un DNS externe :
Le navigateur télécharge et traite les fichiers présents sur le serveur de Geekfault :
En même temps que l’étape 4, le navigateur télécharge les éléments tiers. Dans la réalité ça donne ça : Vous êtes fichés !

Bande passante

Vous pouvez visualiser la bande passante consommée avec des outils externes comme WebsiteOptimization & SearchMetrics ou des outils intégrés aux navigateurs comme YSlow, PageSpeed illustré ici : ou les outils de monitoring de Webkit illustré ici :

Protections individuelles

Lorsque une protection individuelle existe, elle est généralement simple à mettre en place. De manière générale, la simplicité convoie son lot d’inconvénients, ici il n’y aura pas d’exceptions…

Filtrage au niveau du navigateur

Le cas le plus fréquent est l’extension (Firefox, Chromium, Safari) au navigateur ou carrément intégré comme Opera. Les navigateurs de mobiles, consoles ou carrément intégrés à des applications ne sont généralement pas éligibles à cette méthode. Les points 1 à 4 sont identiques à la navigation Vanilla.

Le navigateur télécharge et traite les fichiers externes sauf les éléments filtrés:
~~Ça y’est vous êtes fichés !~~Mission accomplie, mais sans grande classe, nous n’avons protégé qu’une partie de nos terminaux.

Au niveau du fichier /etc/hosts

Cas valable pour Linux,*BSD, *Solaris et Mac OS X (< 10.6). Les systèmes d'exploitations de mobiles, consoles, ne sont généralement pas éligibles à cette méthode. Les points 1 à 3 sont identiques à la navigation Vanilla.

Les éléments externes doivent d’abord être recherchés par leur adresse IP toujours avec /etc/hosts en premier et les adresses non résolues sont transmises au DNS externe :
Le navigateur télécharge et traite les fichiers externes. Si il n’y a pas de serveur HTTP en écoute sur l’ip spécifiée dans le /etc/hosts vous allez au devant de ralentissements du navigateur ainsi que des messages d’erreur :
~~Ça y’est vous êtes fichés !~~Mission accomplie, mais sans grande classe, nous n’avons protégé qu’une partie de nos terminaux.

Qu’en conclure ?

En QHSE les protections individuelles montrent très rapidement leurs limites. Dans le cas présenté dans cette section, on se retrouve devant des difficultés non négligeables comme des extensions de logiciels non portables aux autres logiciels, la modification de fichiers systèmes réservés aux administrateurs, la difficile synchronisation des filtres entre plusieurs terminaux.
La plus difficile reste le déploiement de ces techniques sur les terminaux verrouillés comme les téléphones, les consoles portables, les TV.

Proxies filtrants

Si le responsable du réseau est un pratiquant du FLOSS il utilisera très certainement une solution à base de proxies filtrants tels que Privoxy, Squid ou encore Polipo (je vous conseille l’excellent article de bragon).

Fonctionnement générique d’un proxy filtrant

Nous sommes toujours dans notre scénario d’une visite de courtoisie sur Geekfault.

La première étape pour afficher la page d’accueil de Geekfault est la résolution du nom de domaine en adresse IP par un DNS externe (configuration par défaut des navigateurs et des proxies communs) :
Une connexion INdirecte sur la machine par HTTP permet de récupérer le fichier index (typiquement index.php) à travers un proxy:
Le navigateur lit cette page pour établir la liste des fichiers à télécharger en plus (js,png,css, …) et la liste des éléments externes au site (dont ceux des web-espions). Les éléments externes doivent d’abord être recherchés par leur adresse IP toujours avec un DNS externe :
Le navigateur télécharge et traite les fichiers présents sur le serveur de Geekfault :
En même temps que l’étape 4, le navigateur tente de télécharger les éléments tiers, mais le proxy filtrant l’en empêchera.

Qu’en conclure ?

Le proxy filtrant est la solution généralement la plus efficace. Les filtres à base d’expression régulières permettent un action chirurgicale sans égal, la contrepartie est que pour proxifier une centaine de poste client la machine doit être correctement dimensionnée.
Comme nous le rappelle khemael le proxy transparent çaymal® mais c’est le prix à payer pour protéger les terminaux qui ne proposent pas de réglages relatifs au proxy (au hasard une TV…).
Le dernier inconvénient est que les systèmes espions ne communiquent pas tous sur HTTP.

Les avantages l’emportant largement sur les inconvénients, la popularité de ce système est facilement compréhensible. Néanmoins il existe une autre approche basée sur les DNS menteurs que nous allons aborder dans le prochain chapitre.

DNS menteur

Dans notre réseau, le DNS est donné automatiquement aux terminaux par DHCP. Dans le scenario qui suit le DNS interne ne sera pas un modèle de franchise. Dans certains cas il refusera d’interroger un DNS externe et affirmera que certains noms de domaine, pourtant externes à notre réseau, ont une adresse IP locale que l’on appellera blackhole. Le DNS ment !

Pour éviter d’avoir des messages d’erreurs dans les navigateurs, il y a un serveur HTTP en écoute sur blackhole.

Scénario

Nous sommes toujours dans notre scénario d’une visite de courtoisie sur Geekfault.

La première étape pour afficher la page d’accueil de Geekfault est la résolution du nom de domaine en adresse IP par un DNS externe (configuration par défaut des navigateurs et des proxies communs) :
Une connexion directe sur la machine par HTTP permet de récupérer le fichier index (typiquement index.php) :
Le navigateur lit cette page pour établir la liste des fichiers à télécharger en plus (js,png,css, …) et la liste des éléments externes au site (dont ceux des web-espions). Les éléments externes doivent d’abord être recherchés par leur adresse IP toujours avec un DNS externe :
Le navigateur télécharge et traite les fichiers présents sur le serveur de Geekfault :
En même temps que l’étape 4, le navigateur tente de télécharger les éléments tiers. Mais les requêtes initialement destinées aux web-espions échoueront sur blackhole .

Qu’en conclure ?

La protection par DNS menteur est très économe en terme de puissance : le mécanisme se limite à quelques requêtes DNS que le client cachera et une requête HTTP sur un fichier vide qui contient par exemple ceci :

Le filtrage par DNS est en tout-ou-rien. Ou le domaine est bloqué ou tout passe, nous sommes bien loin de la souplesse apportée par les expressions régulières du chapitre précédent. En revanche cette méthode permet de filtrer ce qui n’est pas HTTP.
Passons maintenant à la pratique avec deux systèmes d’exploitation et deux serveurs HTTP distincts.

Cas n°1 Gentoo/Linux + Lighttpd

Notre premier cas s’applique actuellement à un réseau domestique/tpe sous ma responsabilité. L’environnement est hétérogène avec de l’environnement propre, terreux et sale, des téléphones et consoles sous environnement sale. Une fonera (double SSID) est présente. Les serveurs DNS et HTTP sont sur une machine en Gentoo/Linux.

Bind9

Il existe pléthore de cours sur le Ternet pour en monter un en 5 minutes douche comprise. Je vais considérer que vous avez déjà un daemon DNS interne fonctionnel.
À la fin de votre /etc/namedb/named.conf ajoutez ceciinclude "antistats.conf";
Éditez ensuite /etc/namedb/antistats.conf
zone "addfreestats.com" { type master; notify no; file "null.zone.file"; }; zone "estats.com" { type master; notify no; file "null.zone.file"; }; zone "freestats.com" { type master; notify no; file "null.zone.file"; }; zone "goldstats.com" { type master; notify no; file "null.zone.file"; }; zone "google-analytics.com" { type master; notify no; file "null.zone.file"; }; zone "gostats.com" { type master; notify no; file "null.zone.file"; }; zone "hitometer.com" { type master; notify no; file "null.zone.file"; }; zone "indexstats.com" { type master; notify no; file "null.zone.file"; }; zone "masterstats.com" { type master; notify no; file "null.zone.file"; }; zone "megastats.com" { type master; notify no; file "null.zone.file"; }; zone "revstats.com" { type master; notify no; file "null.zone.file"; }; zone "rightstats.com" { type master; notify no; file "null.zone.file"; }; zone "sitemeter.com" { type master; notify no; file "null.zone.file"; }; zone "stats.blogger.com" { type master; notify no; file "null.zone.file"; }; zone "stats.wordpress.com" { type master; notify no; file "null.zone.file"; }; zone "stats4all.com" { type master; notify no; file "null.zone.file"; }; zone "superstats.com" { type master; notify no; file "null.zone.file"; }; zone "topstats.com" { type master; notify no; file "null.zone.file"; }; zone "topstats.net" { type master; notify no; file "null.zone.file"; }; zone "www-google-analytics.l.google.com" { type master; notify no; file "null.zone.file"; }; zone "xiti.com" { type master; notify no; file "null.zone.file"; }; zone "analytics.engagd.com" { type master; notify no; file "null.zone.file"; }; zone "histats.com" { type master; notify no; file "null.zone.file"; };
Éditez ensuite /etc/namedb/null.zone.file
$TTL 3600 @ IN SOA . hostmaster.. ( 2010041800 3600 3600 3600000 3600 ) @ IN NS blackhole. @ IN A 192.168.1.127 * IN A 192.168.1.127
Adaptez à votre environnement, notamment votre SOA, le TTL et les autres délais. Ne prêtez pas attention à loopback. et utilisez plutôt vos valeurs “normales”. En ce qui concerne blackhole il faut que ce nom pointe réellement vers l’ip choisie (ici 192.168.1.127) et vice versa : que l’ip choisie soit résolue en blackhole. Rien de bien extraordinaire dans une configuration de DNS local.

Il faut ensuite relancer Bind9 et normalement nous avons ceci :
$ host -v -t A xiti.com Trying "xiti.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22544 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:

;xiti.com.			IN	A
;; ANSWER SECTION:

xiti.com.		60	IN	A	192.168.1.127
;; AUTHORITY SECTION:

xiti.com.		60	IN	NS	blackhole.

Received 65 bytes from 192.168.1.210#53 in 1 ms
Bingo ! Le domaine xiti.com est résolu en 192.168.1.127 comme prévu. Mais également :
$ host -v -t A er.erer.Erer.xiti.com Trying "er.erer.Erer.xiti.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17999 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:

;er.erer.Erer.xiti.com.		IN	A
;; ANSWER SECTION:

er.erer.Erer.xiti.com.	60	IN	A	192.168.1.127
;; AUTHORITY SECTION:

xiti.com.		60	IN	NS	blackhole.

Received 78 bytes from 192.168.1.210#53 in 1 ms
Nous avons donc un filtre de type *.xiti.com !

Adresse IP locale

J'ai choisi 192.168.1.127 pour une raison arbitraire. Gentoo permet de l'assigner automatiquement dans /etc/conf.d/net
# cat /etc/conf.d/net config_eth0=( "dhcp" "192.168.1.127" )
Ce qui me permet d'avoir eth0 par dhcp (il y a des raisons ) et créer eth0:1 avec pour IP 192.168.1.127 dès le boot de la machine.
# ifconfig eth0 Lien encap:Ethernet HWaddr 00:11:2f:00:00:00 inet adr:192.168.1.210 Bcast:192.168.1.255 Masque:255.255.255.0 (...) eth0:1 Lien encap:Ethernet HWaddr 00:11:2f:3e:e0:b8 inet adr:192.168.1.127 Bcast:192.168.1.255 Masque:255.255.255.0 (...)
Cette étape est purement optionnelle, vous avez le droit de pourrir les logs de votre serveur web avec des requêtes qui ne lui sont pas destinées.

Lighttpd

Ajouter ceci à votre /etc/lighttpd/lighttpd.conf
$SERVER["socket"] == "192.168.1.127:80" { server.name = "blackhole." url.rewrite = ( ".*" => "/index.html" ) server.document-root = "/var/www/localhost/blackhole/" accesslog.filename = var.logdir + "/blackhole-access.log" }
Il faut bien entendu adapter a votre sauce, server.errorlog n'est a priori pas nécessaire.
Finalement on obtient ceci
192.168.1.16 www.google-analytics.com - [18/Apr/2010:19:29:51 +0200] "GET /ga.js HTTP/1.1" 200 14 "http://geekfault.org/2010/04/12/les-autres-nouveautes-de-html-5/3/" "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3"

Cas n°2 FreeBSD + Apache

Notre second cas s'applique actuellement à un sous réseau autonome d'une moyenne entreprise sous ma responsabilité. L'environnement est hétérogène avec de l'environnement propre (pas assez), terreux (surtout) et sale (peu), des téléphones et diverses machines outils sous environnement sale. Les serveurs DNS et HTTP présentés ici sont sur une machine virtualisée FreeBSD. Ces services sont isolés du serveur principal.

Bind9

Il existe pléthore de cours sur le Ternet pour en monter un en 5 minutes douche comprise. Je vais considérer que vous avez déjà un daemon DNS interne fonctionnel.
À la fin de votre /var/named/etc/namedb/named.conf ajoutez ceciinclude "antistats.conf";
Éditez ensuite /var/named/etc/namedb/antistats.conf
zone "addfreestats.com" { type master; notify no; file "null.zone.file"; }; zone "estats.com" { type master; notify no; file "null.zone.file"; }; zone "freestats.com" { type master; notify no; file "null.zone.file"; }; zone "goldstats.com" { type master; notify no; file "null.zone.file"; }; zone "google-analytics.com" { type master; notify no; file "null.zone.file"; }; zone "gostats.com" { type master; notify no; file "null.zone.file"; }; zone "hitometer.com" { type master; notify no; file "null.zone.file"; }; zone "indexstats.com" { type master; notify no; file "null.zone.file"; }; zone "masterstats.com" { type master; notify no; file "null.zone.file"; }; zone "megastats.com" { type master; notify no; file "null.zone.file"; }; zone "revstats.com" { type master; notify no; file "null.zone.file"; }; zone "rightstats.com" { type master; notify no; file "null.zone.file"; }; zone "sitemeter.com" { type master; notify no; file "null.zone.file"; }; zone "stats.blogger.com" { type master; notify no; file "null.zone.file"; }; zone "stats.wordpress.com" { type master; notify no; file "null.zone.file"; }; zone "stats4all.com" { type master; notify no; file "null.zone.file"; }; zone "superstats.com" { type master; notify no; file "null.zone.file"; }; zone "topstats.com" { type master; notify no; file "null.zone.file"; }; zone "topstats.net" { type master; notify no; file "null.zone.file"; }; zone "www-google-analytics.l.google.com" { type master; notify no; file "null.zone.file"; }; zone "xiti.com" { type master; notify no; file "null.zone.file"; }; zone "analytics.engagd.com" { type master; notify no; file "null.zone.file"; }; zone "histats.com" { type master; notify no; file "null.zone.file"; };
Éditez ensuite /var/named/etc/namedb/null.zone.file
$TTL 3600 @ IN SOA . hostmaster.. ( 2010041800 3600 3600 3600000 3600 ) @ IN NS blackhole. @ IN A 192.168.4.127 * IN A 192.168.4.127
Adaptez à votre environnement, notamment votre SOA, le TTL et les autres délais. Ne prêtez pas attention à loopback. et utilisez plutôt vos valeurs "normales". En ce qui concerne blackhole il faut que ce nom pointe réellement vers l'ip choisie (ici 192.168.4.127) et vice versa : que l'ip choisie soit résolue en blackhole. Rien de bien extraordinaire dans une configuration de DNS local.


;; QUESTION SECTION:

;xiti.com.			IN	A
;; ANSWER SECTION:

xiti.com.		60	IN	A	192.168.4.127
;; AUTHORITY SECTION:

xiti.com.		60	IN	NS	blackhole.

Received 65 bytes from 192.168.4.10#53 in 1 ms
Bingo ! Le domaine xiti.com est résolu en 192.168.4.127 comme prévu. Mais également :
$ host -v -t A er.erer.Erer.xiti.com Trying "er.erer.Erer.xiti.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17999 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:

;er.erer.Erer.xiti.com.		IN	A
;; ANSWER SECTION:

er.erer.Erer.xiti.com.	60	IN	A	192.168.4.127
;; AUTHORITY SECTION:

xiti.com.		60	IN	NS	blackhole.

Received 78 bytes from 192.168.4.210#53 in 1 ms
Nous avons donc un filtre de type *.xiti.com !

Adresse IP locale

J'ai choisi 192.168.4.127 pour une raison arbitraire. Freebsd permet de l'assigner (par exemple) via /etc/rc.local
$ cat /etc/rc.local ifconfig ed0 inet 192.168.4.127 alias
Ce qui me permet d'avoir une deuxième IP pour ed0 avec pour valeur 192.168.1.127, dès le boot de la machine.
$ ifconfig ed0 ed0: flags=8843 metric 0 mtu 1500 ether 00:be:ef:00:fa:ce inet 192.168.4.10 netmask 0xffffff00 broadcast 192.168.4.255 inet 192.168.4.127 netmask 0xffffffff broadcast 192.168.4.127 media: Ethernet autoselect (10baseT/UTP)
Cette étape est purement optionnelle, vous avez le droit de pourrir les logs de votre serveur web avec des requêtes qui ne lui sont pas destinées.

Apache

Créez /usr/local/etc/apache22/Includes/blackhole.conf et
Listen 192.168.4.127:80 Listen 192.168.4.127:443

Options +MultiViews AddOutputFilterByType DEFLATE text/html LogLevel alert CustomLog /var/log/httpd-blackhole combined ServerAdmin webmaster@dummy-host.example.com DocumentRoot /usr/local/www/apache22/data/www/blackhole ErrorDocument 404 /index.php ServerSignature Off
Le premier listen est intelligible, le 2ème nécessite un peu de bidouille. Le MultiViews permet de correctement intercepter les arborescences dans blackhole. Le 404 permet de nous orienter vers index.php (préférez un index.xhtml).

macbookpro - - [19/Apr/2010:11:48:42 +0200] "GET /hit.xiti?s=345082&s2=2&p=News::Commenter::mac-apple-jobs-bkuray-youtube&hl=11x48x43&lng=en-US&jv=1&r=1440x900x24x24&re=1440x678&ref=http://www.generation-nt.com/mac-apple-jobs-bkuray-youtube-actualite-999491.html HTTP/1.1" 404 38 "http://www.generation-nt.com/commenter/mac-apple-jobs-bkuray-youtube-actualite-999491.html" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100418 Namoroka/3.6.5pre"

Conclusion

Ce système présente des limites et ses avantages. Laissez-vous tenter par l'expérience et approfondissez le sujet !

Limites évidentes

La principale limite concerne les web-espions qui utilisent des IP plutot que des noms de domaine.
Le principal effet de bord est le filtrage non désiré de CSS ou des JavaScripts importants pour un site BIEN mais hébergés par un site MAL (merci les scripts eye-candy hebergés chez google !), la réciproque est aussi un effet de bord : avoir des fichiers non désirés mais nécessaires sur un site BIEN (grrrr le tracking de Viadeo).
Bind9 doit être rechargé à chaque modifications, vous pouvez également l'adosser à une base de données type mysql pour gagner en souplesse d'administration. La granularité des filtres est très approximative : appelons un chat, un chat, c'est une technique de bourrin (c'est tout moi ça).

Gains immédiats

Pour commencer la charge cpu daemon dns + daemon http est amortie au delà d'une dizaine de surfeur des bahines (concept antérieur au surfeur niçois).

Le combat contre les web-espions ne se limite pas à l'HTTP, on peut envisager de filtrer les espions qui téléphonent à la maison via un autre protocole voire à un autre niveau sous-jacent (UDP).

Le plus grand avantage que j'y trouve est éthique : avec ce système vous ne serez jamais tenté de faire le bâtard en privant vos administrés de leur pause méritée. Non ce n'est pas faire le BOFH mais la sous-merde exécutante, nuance. Les astuces pour modifier le fichier /etc/hosts se rependront et vous passerez pour une buse.

Pour finir, le dns-menteur peut être positionné en complément d'un proxy filtrant, soulageant ce dernier de requêtes superflues. Le gain de performance pourrait être l'occasion d'un autre article .

Liens pour approfondir

Le concept original (2001) est à mettre au crédit de feu pub.CiteWeb.net sous license WTFPL. Merci aux petits gars de yoyo.org pour les noms de domaine.

Si vous avez aimé ce post...

Les autres nouveautés de l’HTML 5

Tito — Sun, 11 Apr 2010 23:14:32 +0000

Quand on parle de la dernière version de l’HTML introduite par le W3C, beaucoup le résument à l’élément . Pourtant, le W3C a introduit de nombreux autres balises, attributs et API pour mieux coller au web d’aujourd’hui, ainsi que des innovations qui vont permettre de rattraper l’écart entre les applications natives et les WebApps tout en rendant le web plus accessible.

Allez, les balises audio et video

D’accord, on en a assez parlé, mais ça constitue une bonne introduction à cet article Parmi les nombreuses innovations de l’HTML 5 qui vont permettre au web de se séparer d’Adobe Flash Player (vous savez, cette extension qui fait planter tous les navigateurs et bouffe au moins un des cores de votre CPU), les tags et sont les plus connus. Insérer une vidéo dans un article est maintenant devenu aussi simple qu’y insérer une image :
Mais quelle saloperIE, ton navigateur ne supporte pas les vidéos HTML 5 Mais installe un vrai navigateur rooooh! Get Firefox!Remarquez la rétro-compatibilité avec les navigateurs HTML4 : puisqu’ils ne vont pas interpréter ce tag, ils afficheront un gentil petit mot. Pensez éventuellement à y mettre un lien vers http://getFirefox.com ^_^ .

Bien sûr ces balises ont des attributs et une API qui leur sont propre, mais ce n’est pas le sujet de l’article.

La limitation du codec

La grosse limitation pour ces attributs est l’implémentation des codecs. Les principaux navigateurs libres n’implémentent que des codecs libres (Ogg Theora+Vorbis) mais par exemple Safari ou même Android n’implémentent que le h264. La W3C ne résoud pas ce problème, ce serait comme imposer le PNG dans les éléments alors que le JPEG (propriétaire) est largement répandu.

Sa solution est donc de fournir les vidéos dans les deux formats, pour que tous les navigateurs compatibles HTML 5 puissent les décoder:

Malheureusement la plupart des éditeurs vont privilégier un seul format, que ce soit par idéologie ou par contraintes techniques (temps de conversion, espace de stockage). Déjà aujourd’hui YouTube, dans sa beta HTML 5, ne diffuse ses vidéos que en h264, ce qui le rend incompatible avec, entre autres, Firefox.

La balise canvas

Un canvas n’est pas un dessin à proprement parler mais une zone possédant une API complète pour dessiner des formes en 2D grâce à un JavaScript. Rien de mieux qu’un petit exemple je pense :

Et si vous avez un navigateur compatible, vous devriez voir le résultat ci-contre.

L’API permet de tracer des rectangles, des ronds, des traits, des pixels et même d’insérer des images ou du texte. On peut aussi jouer avec des ombres, des flous ou des dégradés de couleurs. Très pratique pour faire des manipulations de style sur un texte par exemple :

Pour être exact c’est une image, mais elle a été générée par votre navigateur (comment ça c’est moche? xD)

Et puis comme c’est basé sur le JavaScript, l’image générée peut être entièrement dynamique comme ce plotter dynamique ou le très impressionnant 3D Walker.

Standardisation de Google Gears

Le HTML 5 a intégré en standard de nombreuses nouveautés introduites par Google Gears :

Mettre en cache des pages et scripts pour un accès hors-ligne
Stocker localement des données
Faire tourner les scripts en arrière-plan
Laisser les applications interagir naturellement avec votre environnement

Ces fonctionnalités étaient les prémices du rapprochement les applications natives et les WebApps. On aime ou on aime pas, mais la standardisation du W3C permettra d’accélérer ce phénomène proche du Cloud Computing.

Accès hors-ligne

En HTML 5 il est très aisé de forcer un navigateur à garder des données en cache et ainsi permettre au visiteur de revoir cette page même s’il n’a plus de connexion. Il suffit de créer un fichier manifeste page.manifest listant les fichiers et scripts à garder en cache :
CACHE MANIFEST CACHE: page.htm style.css image.jpg script.js

Ensuite il suffit de rajouter l’attribut au tag HTML :

Et voilà, page.htm, style.css, image.jpg et script.js seront accessibles même hors ligne!

Base de donnée locale

Le HTML 5 définit une nouvelle API JavaScript window.localStorage qui permet de stocker des données dans la mémoire du navigateur. Ses deux principales méthodes sont très simples:
window.localStorage.setItem(key, value); window.localStorage.getItem(key);
Le localStorage est lié à un nom de domaine et les données stockées le restent même si l’utilisateur quitte son navigateur et revient plus tard. Si vos données n’ont pas besoin d’une telle persistance, vous pouvez aussi profiter de l’API sessionStorage qui, comme vous l’aurez compris, permet de stocker des informations tant que l’utilisateur n’a pas quitté le site.

La plupart des navigateurs permettent à chaque domaine de deuxième niveau de stocker 10Mo, mais le W3C recommande de demander l’autorisation de l’utilisateur si l’application a besoin de plus de place.

Attention, même s’ils se ressemblent, le Storage et les cookies n’ont pas la même utilité : n’oubliez pas que les cookies sont envoyés vers le serveur à chaque requête, ce qui pourrait rendre le trafic trop important si vous stockez de nombreuses données. À l’opposé, les données du Storage restent en local, accessibles via JavaScript.

Finalement, pour faire du vrai traitement de bases de données, il suffit de combiner le localStorage avec un JSON ou implémenter votre propre version de l’interface Database standardisée par le W3C.

Scripts en tâche de fond

Lorsqu’il exécute une opération très lourde, un JavaScript immobilise toute la page web. Parfois même l’interface du navigateur ne répond plus tant que le script n’a pas terminé. Heureusement en HTML 5, l’API Worker permet de profiter de faire tourner de tels scripts en tâche de fond.
var worker = new Worker("worker.js"); worker.postMessage(0); /* Lance le Woker avec le paramètre 0 */ worker.onmessage = function (evt) { /* Action lorsque le Worker a fini */ alert(evt.data); };

Et le worker.js :
onmessage = function (evt) { // evt.data est le paramètre 0 for (var i=evt.data, il=1000001; i postMessage(i); }; };
Ce code va nécessiter pas mal de travail au cours de ses 1 000 000 itérations mais ne devrait pas immobiliser le navigateur.

Remplacer une application desktop

Finalement, les WebApps peuvent s'enregistrer elles-même pour gérer les liens vers un certain protocole ou un certain type de fichiers. On peut ainsi imaginer un client IRC en ligne qui reconnait les liens irc:// ou un éditeur de documents qui ouvre un nouvel onglet plutôt qu'OpenOffice lorsqu'il y a un lien vers un .odt :
navigator.registerProtocolHandler("irc", "https://www.example.com/?uri=%s", "Client IRC en ligne"); navigator.registerContentHandler("application/vnd.oasis.opendocument.text", "http://www.example.com/?uri=%s", "Lecteur de documents en ligne");
Malheureusement, pour des raisons de sécurité, un site ne peut s'enregistrer que pour ses propres liens : si vous tombez sur un lien irc:// sur Geekfault.org vous ne serez pas redirigé vers example.com.

Géolocalisation

Très intéressant sur le web qui devient de plus en plus mobile aujourd'hui, l'HTML 5 intègre une API qui permet d'aisément obtenir les coordonnées géographiques du visisteur :

Normalement le navigateur demande à l'utilisateur l'autorisation d'envoyer sa position. Sur un iPhone par exemple, elle sera calculée grâce à la puce GPS. Sur un navigateur desktop, la méthode est variable (triangulation WiFi, puce GPS, services de localisation d'IP ou simplement demander l'adresse de l'utilisateur).

ContentEditable

(Attention, paragraphe très... personnel ^^) Alors là je suis fan de cette fonctionnalité : elle permet de rendre n'importe quelle partie d'une page éditable. On voyait ça apparaître de plus en plus dans les applications en ligne, et maintenant c'est standardisé et extrêmement facile à mettre en place. La preuve? Essayez de cliquer sur ce paragraphe !

Et en plus c'est du WYSIWYG ! Essayez Ctrl+B ou Ctrl+I (sous Chromium) ! Et voilà le code source qui m'a permis de faire ça :

Owi, édite-moi

Je vois déjà toutes les possibilités ouvertes par une fonctionnalité si simple à mettre en place, comme par exemple corriger une erreur dans nos articles ou modifier une page de WikiPédia en deux clics.

Nouveaux inputs

Essentiellement dans le soucis de rendre le web encore plus accessible (aux handicapés) et aux système d'auto-remplissage, le HTML 5 intègre une dizaine de nouveaux types d'inputs textuels : tel, search, url, email, datetime, date, month, week, time, datetime-local, number et color. Les navigateurs sont supposés proposer une interface à l'utilisateur comme par exemple un calendrier pour remplir un datetime, mais ni Chromium ni Firefox ne semble s'y conformer pour l'instant.

On remarque aussi l'apparition de l'input range qui vient combler une déficience qui forçait souvent à avoir recours à une librairie JavaScript.

Autres nouvelles balises

Le W3C introduit dans l'HTML 5 de nombreuses nouvelles balises, dont voici la liste exhaustive

section, article, aside, hgroup, header, footer, nav encadrent les principaux contenus d'une page web typique. On abandonne ainsi l'utilisation constante de, par exemple,
figure et son sous-élément figcaption permettent de lier une légende à une image ou une vidéo
embed a pour but de remplacer object lors de l'insertion de Flash ou de Java (dans les rares cas où ce sera nécessaire)
mark encadre un mot ou un texte important pour, par exemple, le surligner en CSS
progress est l'élément à privilégier si vous affichez la progression d'une tâche
meter représente une mesure telle que l'utilisation du disque
time représente une date et/ou une heure
ruby, rt, rp permet d'intégrer des annotations ruby (WTF?)
command représente une commande que l'utilisateur peut invoquer
details encadre un complément d'information ou des contrôles supplémentaires que l'utilisateur peut obtenir sur demande
keygen permet de fournir une clé de contrôle pour la vérification de la validité des données
output encadre une zone où un script affichera son résultat

La plupart de ces nouveaux éléments sont liés à l'accessibilité mais peuvent aussi présenter un avantage de lors de la création de scripts complexes.

Et nouveaux attributs

Je vouais ai déjà parlé de contentEditable mais il y a beaucoup d'autres nouveaux attributs standards en HTML 5.

contextmenu permet de lier un menu au clic droit sur un élément
draggable détermine si un élément peut être soumis au drag & drop. Cette fonctionnalité est malheureusement soumise à controverse à cause de sa complexité, c'est pourquoi je ne l'ai pas abordé dans l'article.
hidden est un boléen qui remplace sa fonction homonyme en style ou CSS. L'intérêt? Cacher les éléments même dans les navigateurs pour malvoyants qui n'interprètent pas les styles.
item et itemprop et subject permettent de regrouper des éléments
spellcheck est un boléen qui spécifie si la correction orthographique mérite d'être activée sur un élément

Finalement, vous pouvez lier n'importe quel attribut personnalisé (ce qui peut être pratique pour certains scripts) sans contredire les standards du W3C (et donc passer les tests des validateurs) à condition que cet attribut commence par data-.

Conclusion

Avec ce nouveau standard encore à l'état de brouillon, le W3C réduit la nécessité des applets (Flash, Java) et rend le web plus accessible tout en permettant aux applications web (WebApps) d'être plus puissantes, plus faciles à coder et de vraies alternatives aux applications natives de votre ordinateur.

Si toutes les recommandations ne sont pas encore adoptées par les navigateurs, même ceux en avance sur les normes, les possibilités actuelles sont déjà très intéressantes et à prendre en compte pour tous vos prochains développements HTML/JavaScript.

Sources

Il y a encore quelques autres nouveautés dont je ne vous ai parlé, mais j'espère vous avoir donné un bon aperçu des incroyables innovations de l'HTML 5. Si vous en voulez une liste complète, je vous renvoie au site du W3C, tous les liens sont dans les sources ci-dessous.

Si vous avez aimé ce post...

Filtrer ses mails ! Un cauchemard !

bragon — Fri, 09 Apr 2010 17:18:10 +0000

Le but de ce howto est de vous présenter ma façon de filtrer mes mails de tous mes comptes pop/imap, afin de les centraliser dans une même interface.
Afin de filtrer les mails qui arrivent nous allons utiliser “sieve” un merveilleux ajout disponible dans le packet dovecot, qui permet de filtrer les messages directement AVANT qu’ils arrivent dans la casserole IMAP.

Les mails sans rangement c’est immangeable, ceci est une petite recette d’assaisonnement

Centraliser mes mails m’apporte plusieurs choses :

- Faciliter le filtrage.
- Faciliter le rangement dans différents dossiers.
- Effectuer un backup de tous mes comptes IMAP/POP.
- Faire apprendre à mon antispam mes différents réglages.

Cette recette ne couvre pas l’installation de Apache + php + MySQL
Nous supposons ici que vous savez faire ce type d’installation.

Cette recette ne couvre pas non plus l’utilisation de mutt (je mettrai tout de même en ligne ma configuration).
En effet, l’utilisation de mutt mérite un article à lui seul !

Postulat1 : Les mails seront stockés dans cette recette ici : /home/utilisateur/.maildir
Postulat2 : Nous supposons que vous avez plusieurs comptes email à rapatrier.
Postulat3 : Nous supposons que vous disposez d’une machine GNU/Linux sous Gentoo et/ou Debian pour effectuer ce howto.
Postulat4 : Nous supposons que vous stockez vos mails dans le format Maildir ! (se reporter au Howto Sur la conversion mbox => maildir en cas de soucis) Allez lire : http://geekfault.org/2010/04/09/maildir-mbox-la-migration/

Résultat une fois que la recette est en place

Logiciels nécessaires pour “MailFiltrés”

MySQL-5

Apache-2.2

Php-5.2

RoundCube + plugins “Report Junk” et “Manage Sieve”

Dovecot (pop/imap) + Sieve + ManageSieve

SpamAssassin + MySQL

Postfix

mutt + sidebar

Fetchmail

Remplir la casserole

Pour trier le manger dans la casserole nous devons tout d’abord la remplir !

Pour effectuer ce howto il nous faut tout d’abord des emails.
Il va donc nous falloir configurer fetchmail.
Attention ne pas lancer fetchmail de suite ! Sinon vous risquez de rapatrier les emails sans même les faire passer dans la moulinette avant de les déposer dans les bons compartiments de la casserole !

Récupérer les ingrédients et les mettre dans la casserole

* Gentoo
USE="ssl" emerge -av net-mail/fetchmail

* Debian
apt-get install fetchmail

* .fetchmailrc

## les mails mondomaine.info poll pop.geekmx.org protocol pop3 username bragon@mondomaine.info password "" #mda '/usr/bin/procmail -d %T' ### petit commentaire pour vous faire voir comment faire pour faire passer vos mails dans la moulinette procmail avant de les donner à manger à dovecot !! mda "/usr/libexec/dovecot/deliver" is 'bragon' here ### Nom de l'utilisateur local pour déposer les mails. keep ### Laisses mes mails sur l'imap distant ! Mechant !


## ensuite on recup les mails geeknode

poll pop.geekmx.org

protocol pop3

username utilisateurvalide@g33kn0de.org

password ""

mda "/usr/libexec/dovecot/deliver"

is 'bragon' here

keep
## apres on passe au compte gmail

poll imap.gmail.com

proto imap

user "bragon.unuser@gmail.com"

password ""

ssl

keep

mda "/usr/libexec/dovecot/deliver"

is 'bragon' here
## On synchronise le compte blackberry pour virification

#poll imap.geekmx.org

#proto imap

#user "unuser@undomaine.info"

#password ""

#ssl

#keep

#mda "/usr/libexec/dovecot/deliver"

#is 'bragon' here
## preparation pour les mails EW

#

poll trucmail.euro-web.fr

protocol imap

username "truc.plop[_at_]euro-web[point_dot]fr" ## Mettre ici une vraie adresse mail

password "" ## Mettre ici un vrai mot de passe.

folder 'INBOX.sdf' ## Recupère spécifiquement un dossier IMAP

folder 'INBOX.task'

folder 'INBOX.sysadmin'

folder 'INBOX.netavous'

folder 'INBOX.frnog'

folder 'INBOX.TODO'

folder 'INBOX' ## Recupère le dossier imap principal

keep ## Laisse les mails sur le serveur

mda "/usr/libexec/dovecot/deliver" ## Utilise dovecot en tant que deliver local

is 'bragon' here ## Mets les mails dans le répertoire courant de l'utilisateur bragon.

Filtrer / Découper les ingrédients Juste avant la casserole

emerge -av =net-mail/dovecot-1.2.6
ou
apt-get install dovecot # Je crois que de base dans Debian dovecot est compilé avec sieve.

* Flag de compilation nécéssaire pour dovecot : “berkdb bzip2 ipv6 maildir managesieve mysql pam sieve ssl zlib -caps -cydir -dbox -doc -kerberos -ldap -mbox -postgres -sqlite -suid -vpopmail”

Via ces directives de compilation dovecot supporte maintenant les fichiers de filtrage “.sieve”
Il vous suffit de déposer n’importe quel fichier sieve dans /home/utilisateur/sieve pour que dovecot utilise vos filtres.

Voici un exemple de syntaxe : tamereenshortsurunCISCO7603.sieve

# rule:[cron] elsif anyof (header :contains "Subject" "root@gn", header :contains "From" "root@astaroth", header :contains "From" "bragon@tobold", header :contains "From" "root@aec-ri.com", header :contains "From" "root@mail.geekmx.org", header :contains "From" "root@bender") { fileinto "cron"; }

Second exemple de syntaxe : tonpapaesttellementvieuxque….sieve

# rule:[SYSADMIN ML] elsif anyof (header :contains "From" "sysadmin@domaine.net", header :contains "Subject" "Liste Franophone Administrateur systeme") { fileinto "boulot.sysadmin"; redirect "smartphone[at]bragon[point]info"; ## Mettre ici une adresse mail valide } # rule:[Debian Security Advertise] elsif anyof (header :contains "Subject" "[SECURITY][DSA") { fileinto "boulot.dsa"; }

Virer les ingrédients moisis en les mettant dans un compartiment de la casserole

emerge -av =mail-filter/spamassassin-3.2.5-r2

* Flag de compilation nécessaire pour spamassassin : "berkdb ipv6 mysql ssl -doc -ldap -postgres -qmail -sqlite -tools"

* Voir les configurations de spamd ci-après.

Renvoyer certains ingrédients au cuisinier

emerge -av =mail-mta/postfix-2.6.5

* Flag de compilation nécessaire pour postfix : "dovecot-sasl ipv6 mysql pam ssl -cdb -hardened -ldap -mbox -nis -postgres -sasl (-selinux) -vda"

* Voir le fichier de configuration main.cf ci-après.

Le postfix me sert uniquement pour transférer certaines régles sieve vers une autre adresse mail.
Cette adresse mail est popé via mon smartphone.
Ainsi je reçois N'importe ou Certains mails qui "matchent" une régle de filtrage spécifique !

Le postfix peut me servir également à faire réply dans l'interface roundcube ou mutt . (mais je l'utilise rarement car ce postfix n'a ni domainkeys ni spf pour mes domaines pro / geeknode / gmail) Et le mail bien que délivré arrivera dans la boite à spam du correspondant fréquemment.

Ce postfix n'est là que pour dépanner, et pour transférer mes mails super important via mon smartphone.

Faire mijoter à feu doux !

Placer ce crontab pour l'utilisateur qui va devoir récupérer les mails.

crontab -e */10 * * * * /usr/bin/fetchmail > /dev/null 2>&1

Les mails vont donc être récupérés toutes les dix minutes, et directement déposés dans le MDA ( Mail Délivery Agent).
Le MDA de ma configuration fetchmail étant dovecot, et dovecot lisant tous mes filtres, cela devrait bien se passer

Présentation sur un joli plat du résultat.

La configuration de dovecot aka "Le déversoir"

base_dir = /var/run/dovecot/ protocols = imap managesieve ## Je suppose que vous n'avez pas besoin de pop pour votre interface centralisé. shutdown_clients = yes disable_plaintext_auth = no ssl = no ## ce howto ne couvre pas la sécurité de l'imap


# Si vous désirez utiliser seulement TLS

## Pour le moment ce HowTo n'a pas été pensé pour le SSL, mais on peut très facilement l'ajouter.

## disable_plaintext_auth = yes

## ssl = yes

## ssl_cert_file = /var/qmail/control/servercert.pem

## ssl_key_file = /var/qmail/control/servercert.pem
login_dir = /var/run/dovecot/login

login_process_per_connection = yes

login_greeting = Imap ready.

mail_debug = no

mail_uid = 1000

mail_gid = 100

first_valid_uid = 1000 ### Premier utilisateur système

last_valid_uid = 1001 ### Vous pouvez mettre en place cet imap pour plus de deux utilisateurs en augmentant cette directive.

first_valid_gid = 100

last_valid_gid = 1000

mail_location = maildir:~/.maildir ### Expliqué dans le postulat de l'introduction
## on active le deliver local
protocol lda {

  postmaster_address = bragon[at_at_at]bragon[dot_point_dot]info ### Mettre ici une adresse mail valide !!!

  # remember to give proper permissions for these files as well

  log_path = /var/log/dovecot-deliver-errors.log

  info_log_path = /var/log/dovecot-deliver.log

  #auth_socket_path = /var/run/dovecot/auth-master

mail_plugins = sieve

}
## On log correctement

##

## Logging

##

# Log file to use for error messages, instead of sending them to syslog.

# /dev/stderr can be used to log into stderr.

log_path = /var/log/dovecot/error
# Log file to use for informational and debug messages.

# Default is the same as log_path.

info_log_path = /var/log/dovecot/info
protocol imap {

         listen = 81.93.247.***:143 ### Mettre l'ip de la machine ici

        login_executable = /usr/libexec/dovecot/imap-login

        mail_max_userip_connections = 10

        mail_plugin_dir = /usr/lib/dovecot/imap

        mail_plugins = quota imap_quota

}
plugin {

        quota = maildir:User quota

          # Used by both the Sieve plugin and the ManageSieve protocol

          sieve=~/.dovecot.sieve ## Répertoire ou serons stockés les regles de filtrage de dovecot.

          sieve_dir=~/sieve         ## Répertoire ou serons stockés les regles de filtrage de l'utilisateur  (elles sont lu par dovecot)        
}
protocol managesieve {

  # Specify an alternative address:port the daemon must listen on

  # (default: *:2000)

listen = 81.93.247.***:2000 ## ip de votre box à mettre ici
  managesieve_logout_format = bytes ( in=%i : out=%o )

}
plugin {

  # Used by both the Sieve plugin and the ManageSieve protocol

  sieve=~/.dovecot.sieve

  sieve_dir=~/sieve

}
auth_verbose = yes

auth_debug = yes
auth default {                  ### On se log ici directement à la base d'utilisateur unix du système courant.

        mechanisms = plain login
passdb pam { args = "*"

}
userdb passwd { args = blocking=yes 
}
}

Configuration de .muttrc aka le rouleau à patisserie

Placer ce fichier .muttrc à la racine du répertoire utilisateur :


### pour voir les sous dossiers
set spoolfile="/home/bragon/.maildir/"

set folder="/home/bragon/.maildir/"

set mask="!^\\.[^.]"

set record="+.Sent"

set postponed="+.Drafts"
mailboxes ! + `\

for file in /home/bragon/.maildir/.*; do \

  box=$(basename "$file"); \

  if [ ! "$box" = '.' -a ! "$box" = '..' -a ! "$box" = '.customflags' \

      -a ! "$box" = '.subscriptions' ]; then \

    echo -n "\"+$box\" "; \

  fi; \

done`
### activer la sidebar de mutt

macro index c "?" "open a different folder"

macro pager c "?" "open a different folder"
# Sidebar

set sidebar_visible=yes

set sidebar_width=50

color sidebar_new yellow default
# ctrl-n, ctrl-p to select next, prev folder

# ctrl-o to open selected folder

bind index \Cp sidebar-prev

bind index \Cn sidebar-next

bind index \Cb sidebar-open

bind pager \Cp sidebar-prev

bind pager \Cn sidebar-next

bind pager \Cb sidebar-open
## mon editeur est emacs et je t'emmerde !!!

set editor="emacs -nw"

Configuration de postfix aka "Le renvoyeur"

queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = //usr/lib/postfix data_directory = /var/lib/postfix mail_owner = postfix myhostname = tobold.mondomaine.info mydomain = tobold.mondomaine.info myorigin = $myhostname


unknown_local_recipient_reject_code = 550
debug_peer_level = 2
debugger_command =

         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin

         ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = /usr/share/doc/postfix-2.6.5/html
manpage_directory = /usr/share/man
sample_directory = /etc/postfix
readme_directory = /usr/share/doc/postfix-2.6.5/readme

home_mailbox = .maildir/

Configuration SpamAssassin/MySQL

* Afin de générer un bon local.cf utilisez : http://www.yrex.com/spam/spamconfig.php

* Insérer dans une base MySQL
CREATE TABLE userpref ( username varchar(100) NOT NULL default '', preference varchar(50) NOT NULL default '', value varchar(100) NOT NULL default '', prefid int(11) NOT NULL auto_increment, PRIMARY KEY (prefid), KEY username (username) ); CREATE TABLE bayes_expire ( id int(11) NOT NULL default '0', runtime int(11) NOT NULL default '0', KEY bayes_expire_idx1 (id) ) TYPE=MyISAM;


      CREATE TABLE bayes_global_vars (

          variable              varchar(30)     NOT NULL default '',

          value                 varchar(200)    NOT NULL default '',

          PRIMARY KEY           (variable)

          ) TYPE=MyISAM;
      INSERT INTO bayes_global_vars VALUES ('VERSION','3');
      CREATE TABLE bayes_seen (

          id                    int(11)         NOT NULL default '0',

          msgid                 varchar(200) binary NOT NULL default '',

          flag                  char(1)         NOT NULL default '',

          PRIMARY KEY           (id,msgid)

          ) TYPE=MyISAM;
      CREATE TABLE bayes_token (

          id                    int(11)         NOT NULL default '0',

          token                 char(5)         NOT NULL default '',

          spam_count            int(11)         NOT NULL default '0',

          ham_count             int(11)         NOT NULL default '0',

          atime                 int(11)         NOT NULL default '0',

          PRIMARY KEY           (id, token),

          INDEX (id, atime)

          ) TYPE=MyISAM;
      CREATE TABLE bayes_vars (

          id                    int(11)         NOT NULL AUTO_INCREMENT,

          username              varchar(200)    NOT NULL default '',

          spam_count            int(11)         NOT NULL default '0',

          ham_count             int(11)         NOT NULL default '0',

          token_count           int(11)         NOT NULL default '0',

          last_expire           int(11)         NOT NULL default '0',

          last_atime_delta      int(11)         NOT NULL default '0',

          last_expire_reduce    int(11)         NOT NULL default '0',

          oldest_token_age      int(11)         NOT NULL default '2147483647',

          newest_token_age      int(11)         NOT NULL default '0',

          PRIMARY KEY           (id),

          UNIQUE bayes_vars_idx1 (username)

          ) TYPE=MyISAM;
      CREATE TABLE awl (

          username              varchar(100)    NOT NULL default '',

          email                 varchar(200)    NOT NULL default '',

          ip                    varchar(10)     NOT NULL default '',

          count                 int(11)         default '0',

          totscore              float           default '0',

          PRIMARY KEY           (username,email,ip)

          ) TYPE=MyISAM;

* secret.cf


##(Tell Spamassassin to use MySQL for bayes data

bayes_store_module              Mail::SpamAssassin::BayesStore::SQL

bayes_sql_dsn                   DBI:mysql:sa:localhost:3306

bayes_sql_username              sa

bayes_sql_password              somepwd
##(Tell Spamassassin to use MySQL for AWL data

auto_whitelist_factory          Mail::SpamAssassin::SQLBasedAddrList

user_awl_dsn                    DBI:mysql:sa:localhost:3306

user_awl_sql_username           sa

user_awl_sql_password           somepwd

* local.cf

# SpamAssassin config file for version 3.x # NOTE: NOT COMPATIBLE WITH VERSIONS 2.5 or 2.6 # See http://www.yrex.com/spam/spamconfig25.php for earlier versions # Generated by http://www.yrex.com/spam/spamconfig.php (version 1.50)


# How many hits before a message is considered spam.

required_score           5.0
# Change the subject of suspected spam

rewrite_header subject         [SPAM]
# Encapsulate spam in an attachment (0=no, 1=yes, 2=safe)

report_safe             1
# Enable the Bayes system

use_bayes               1
# Enable Bayes auto-learning

bayes_auto_learn              1
# Enable or disable network checks

skip_rbl_checks         0

use_razor2              1

#use_dcc                 1

use_pyzor               1
# Mail using languages used in these country codes will not be marked

# as being possibly spam in a foreign language.

# - english french

#ok_languages            en fr

# Mail using locales used in these country codes will not be marked # as being possibly spam in a foreign language. #ok_locales en fr

Ajouter les clous de girofles dans RoundCube

http://www.tehinterweb.co.uk/roundcube/#pisieverules

Il vous faut installer les plugins ManageSieve et ReportasJunk
Suivez la documentation officielle, elle s'en sortira mieux que moi afin de vous expliquer tout cela.

Laissez refroidir

Voilà c'est prêt !

Awesome non ?

Si vous avez aimé ce post...

Maildir mbox – La migration

pistache — Fri, 09 Apr 2010 17:16:18 +0000

Traditionellement, les serveurs UNIX utilisent mbox pour stocker les mails. Pour mbox, chaque dossier de votre boîte mail (Reçu, Envoyés, Archive, Corbeille, etc) est representé par un fichier, ou tout les mails sont enregistrés à la suite, séparés par une ligne vide.

Ce format, très simple à utiliser, pose de nombreux problèmes. Premièrement, on ne peut pas faire d’accès parallèles, même sur des mails différents, puisque le fichier est le même (problème de verrou). Deuxièment, les serveurs POP/IMAP (comme Dovecot) ont souvent un support limité de mbox. Dovecot est obligé de placer un mail “interne” dans la boîte, pour garder l’arborescence et l’organisation des dossiers. Courier ne supporte pas mbox.

L’avantage principal de mbox, c’est le fait qu’il soit très répandu. Il est supporté par tout les MUA (mailutils/mail, bsd-mailx, mutt, emacs, Kmail, thunderbird, evolution). Mais les problèmes récurrents qu’il pose ont poussé le principal développeur de qmail a créer un nouveau format : Maildir.

Maildir

Avec Maildir, chaque mail est un fichier, et chaque dossier de la boîte mail, un répertoire. Attention, c’est un peu plus compliqué que ça. Les mails ne sont pas directement enregistrés dans boîte/mail :

Le MDA enregistre le mail dans boîte/tmp/unique (“unique” est un nom de fichier unique généré a partir de données pseudo-aléatoires)
Une fois que le mail est écrit, le MDA le déplace dans boîte/new/unique
Le MUA le déplace dans boîte/cur/unique une fois qu’il voit qu’un nouveau message est arrivé dans boîte/new/

Pourquoi ? Ce comportement est utilisé pour éviter que le MUA voit un mail incomplet (car le MDA est encore en train de l’écrire), ce qui peut arriver si la machine est surchargée, si le Maildir est sur un serveur distant (NFS,FTP), voire même si le mail est gigantesque.

Maildir et procmail

Le but de cet article n’est pas d’expliquer comment configurer un MDA pour qu’il enregistre les mails en Maildir, mais malgré tout je fais une petite encartade pour les gens qui utilisent procmail. Le code suivant dans /etc/procmailrc permet de dire à procmail de mettre par défaut (cela peut donc être supplanté par une directive contraire dans le ~/.procmailrc) :
DEFAULT=$HOME/Maildir/
Aussi, si vous n’utilisez pas encore procmail je vous conseille d’y migrer rapidement :

Plus besoin de toucher à la configuration du MTA pour changer les méthodes de livraison des mails
Les utilisateurs peuvent écrire leurs propres règles pour leurs boîtes mails (pour avoir des boîtes séparées pour certains mails, par exemple)
Si vous changez de MTA vous pouvez toujours garder la même configuration, à condition de dire à votre MTA d’utiliser procmail

Configuration de mutt

mutt gère très bien les Maildirs, mais il faut le configurer. Dans le .muttrc, rajoutez :
# pour dire à mutt de que mbox est un Maildir set mbox_type=Maildir # pour dire à mutt que les chemins relatifs (avec +) sont dans "~/Maildir/" set folder="~/Maildir/" # pour dire à mutt que les mails arrivent dans Maildir/ set spoolfile="~/Maildir/" # les mails archivés (pas nouveau) seront envoyés dans +Mailbox # (+ est remplacé par la variable folder). set mbox="+Mailbox"


# remplacez par votre propre choix (ce n'est pas un tutorial de la configuration de mutt)

# on indique à mutt d'envoyer les mails de ~/Maildir/ dans la boîte indiquée par la variable "mbox"

set move="ask-yes"

# ce code montre la puissance de mutt (inclure des scripts shell dans sa configuration) # ouvrir tous les dossiers qu'il trouve dans ~/Maildir/ mailboxes ! + `\ for file in ~/Maildir/.*; do \ box=$(basename "$file"); \ if [ ! "$box" = '.' -a ! "$box" = '..' -a ! "$box" = '.customflags' \ -a ! "$box" = '.subscriptions' ]; then \ echo -n "\"+$box\" "; \ fi; \ done`
On note qu’il faut créer les boîtes mails dans ~/Maildir/, ainsi que le Maildir en lui-même (même si procmail peut le créer tout seul, et que si vous avez converti vos mbox il existe déjà). On va créer la boîtes “Mailbox” (utilisé par mutt avec set mbox=”+Mailbox”).
cd # on se place dans $HOME mkdir Maildir # on crée Maildir (ça sera peut-être déjà fait) cd Maildir mkdir cur new tmp # on crée une arborescence Maildir mkdir .Mailbox # on crée une nouvelle boite cd .Mailbox mkdir cur new tmp
On note que :

La boîte principale, ou les mails entrants sont enregistrés par le MDA, est à la racine du Maildir
Les sous-dossiers de la boîte, commencent tous par un .

Vous pouvez maintenant démarrer mutt, et exploiter votre mbox (pour naviguer dans les boîtes, utilisez “y”)

Migrer des boîtes mbox en Maildir

Pour migrer les mbox en Maildir, le script perfect_maildir.pl est parfait, et son usage est simple :
./perfect_maildir.pl path_to_Maildir/ < mbox

pam_mail.so et You have new mail

Vous avez peut-être déjà remarqué que quand vous vous ouvrez un shell, vous avez un beau message "You have new mail" qui indique de nouveaux mail dans /var/mail/$USER. Cet avertissement est geré par pam_mail.so, un module de PAM qui permet de faire ça. Si on utilise Maildir il est intéressant de dire à pam_mail.so d'aller vérifier les nouveaux mails dans le Maildir. Cette configuration se fait dans /etc/pam.d/ sous Debian et Gentoo. Tout d'abord éditer le fichier login, et trouver cette ligne :
session optional pam_mail.so standard
Remplacer par :
session optional pam_mail.so standard dir=~/Maildir
Je recommande d'effectuer aussi la manipulation pour le fichier "ssh".

Normalement PAM devra modifier la variable d'environnement MAIL à Maildir/, si par hasard ce comportement ne marche pas (en fonction de la configuration de PAM) il y a toujours moyen d'ajouter
MAIL=Maildir/
dans /etc/environment.

Faire fonctionner la commande "mail"

La commande mail est le moyen le plus simple de lire ses mails sous unix. Vous constaterez probablement que votre commande mail ne marche plus (même avec MAIL=Maildir/), car elle ne supporte pas Maildir. Mais il y a plusieurs versions de cette commande, la plus répandue étant celle de bsd (bsd-mailx avec Debian). Je vous conseille d'installer une autre version, appellée "heirloom-mailx" (sous Debian), voire "nail", qui supporte très bien les Maildir.

Liens relatifs

Configurer Maildir et Dovecot
man pam_mail
la première spécification de Maildir (a changé depuis)

Ironiquement j'ai trouvé beaucoup de mes renseignements sur bugs.debian.org :

Si vous avez aimé ce post...

L’email : un vilain petit cafardeur !

ckg — Sat, 13 Mar 2010 18:49:26 +0000

Votre architecture réseau ne regarde pas vos correspondants, cependant vous avez donné aux plus curieux d’entre eux quelques bribes d’information à votre insu : ip interne, dns interne, chaîne de mta…

Nous allons voir un exemple récent, déterminer quels logiciels font les pies et finir par quelques réglages de ces derniers.

Quelques définitions rapides :

MUA : Mail User Agent, c’est l’agent coté utilisateur. Thunderbird que j’évoque dans cet article, Evolution, KMail, mutt, mail et sendEmail sont quelques exemples.
MTA : Mail Transfer Agent, le serveur smtp. Sendmail que j’évoque dans cet article, postfix, qmail, exim sont les plus connus, mais ssmtp et OpenSMTPd sont des alternatives montant en puissance.
MDA : Mail Delivery Agent, c’est le logiciel qui remet les emails dans les comptes utilisateurs. Procmail est le plus connu.
RFC : Request For Comment, un texte de référence. Le texte nous intéressant ici est la RFC 5321 http://tools.ietf.org/html/rfc5321

Cas concret

Décortiquons ensemble un email envoyé par un de mes fournisseurs. Il n’y a rien d’exceptionnel dans cette section qui n’ait déjà été maintes fois abordé dans la presse informatique vulgarisée.

L’email en question

From - Mon Jan 18 17:07:56 2010 (…) Return-Path: Received: from smtp20.msg.oleane.net (smtp20.mail.priv [172.17.20.138]) by mail03.msg.oleane.net with LMTP id H7q6321w; Mon, 18 Jan 2010 17:07:52 +0100 Received: from smtp20.msg.oleane.net (localhost [127.0.0.1]) by smtp20.msg.oleane.net (MX-ASAV) with ESMTP id o0IG7pk9022097; Mon, 18 Jan 2010 17:07:51 +0100 Received: from abc.correspondant.com (abc.correspondant.com [81.211.11.111]) by smtp20.msg.oleane.net (MX) with ESMTP id o0IG7ndC021964; Mon, 18 Jan 2010 17:07:49 +0100 Received: from PC1.correspondant.fr ([192.168.69.50]) (authenticated user monsieur@correspondant.fr) by abc.correspondant.com (Kerio MailServer 6.7.0 patch 1); Mon, 18 Jan 2010 17:10:15 +0100 Subject: RE: GeekFault Date: Mon, 18 Jan 2010 17:07:48 +0100 Message-ID: In-Reply-To: From: "Monsieur CORRESPONDANT" Sender: "Monsieur CORRESPONDANT" To: "Monsieur DESTINATAIRE" Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal User-Agent: Kerio Outlook Connector (6.7.0.7695) MIME-Version: 1.0 X-MimeOLE: Produced by Kerio Outlook Connector (6.7.0.7695) Content-Type: multipart/mixed; boundary=MIXED-MIME-355913937-24773-delim X-Spam-Flag: NO X-PMX-Spam: Probability=13% X-Spam-Level: X X-PFSI-Info: PMX 5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2010.1.18.155416 (no virus found)

Comment le lire ?

La RFC 5321 section 4.4 précise que le Mail Transfert Agent (mta) se DOIT, et avant toutes autres opérations de transfert, d’inclure une trace « Received » ou « timestamp ». L’ordre des « Received » se lit donc de bas en haut.

Nous apprenons que notre « correspondant » a émis son email depuis son « PC1 » 192.168.69.50 (IPV4) . On devine aisément son système d’exploitation, c’est celui qui donne des noms de machines en majuscules.

Jouons au jean-kevin

On déduit du mix « .fr »/ « .com » que notre sujet d’étude n’est pas très familier avec les dns et c’est sans doute la raison pour laquelle il n’en a pas en interne. Il n’est pas non plus familier avec ntp. Visiblement notre sujet d’étude n’est pas familier avec certains services réseaux.

Attardons nous quelques secondes sur le 3ème mta rencontré, OBS utilise un mta du nom de « localhost [127.0.0.1] », nous sommes dans une application minimaliste de la section 4.4 de la RFC 5321. Pourquoi être resté a minima, contrairement aux autres mta ? Le terme MX-ASAV nous donne un indice : AntiSpam AntiVirus … ce mta est vraisemblablement inaccessible il n’y a aucune raison de fournir plus de détails.

Que retenir de cette partie ?

Nous n’avons donc rien appris de bien intéressant car nous ne cherchons rien de particulier. Détails à priori inintéressants, mais avez-vous vraiment envie d’en faire profiter le reste de vos correspondants ?

Dompter son Mail Transfer Agent (mta)

Je suis un utilisateur satisfait de sendmail (www.sendmail.org) depuis quelques années maintenant. Je vais donc vous parler de ce ~~magnifique et ô combien trollifère~~ mta.

Quel périmètre et que dit la RFC ?

Comme précisé dans la première partie, notre périmètre d’action est restreint : du (mua) jusqu’au dernier mta sous notre responsabilité.
La RFC précise que pour des raisons de traçabilité un mta ne doit pas procéder à de la destruction de « Received »/« timestamp ». Comprenez qu’en prenant la responsabilité de couper une partie de la chaîne de réponse vous devez vous engager à garder une trace dans votre système.

Ne modifiez rien si :

Vous n’avez pas d’outils de logs fiables
Vous n’êtes pas sûr de toutes les machines en amont de votre mta
Vous êtes backup-MX
Vous n’êtes pas sûr de toutes les utilisateurs en amont de votre mta
Vous n’êtes pas sûr de toutes les logiciels en amont de votre mta
Vous n’êtes pas sûr de ce que votre mta va supprimer, il serait DOMMAGE de supprimer des informations concernant les mails entrants (ceux venant du Great Ternet)

Pesez-bien cette décision, agissez en responsable. Si vous êtes sous FreeBSD vous pouvez recevoir une synthèse par mail quotidienne et la coupler à un daemon syslog sur une autre machine.

`hostname`.cf & `hostname`.mc

Nous allons jeter un oeil dans la configuration de sendmail (`hostname`.cf ) au niveau de la gestion du HEADER. Nous trouvons sans difficulté ceci :
HReceived: $?sfrom $s $.$?_($?s$|from $.$_) $.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.) $.by $j ($v/$Z)$?r with $r$. id $i$?{tls_version} (version=${tls_version} cipher=${cipher} bits=${cipher_bits} verify=${verify})$.$?u for $u; $|; $.$b$?g (envelope-from $g)$.

Que nous pouvons réduire à :
HReceived: id $i; $b

Modifier `hostname`.cf est généralement une mauvaise idée, sendmail vous propose l’utilisation de macro m4, autant en profiter. Voici donc la correspondance dans `hostname`.mc
define(`confRECEIVED_HEADER',`id $i; $b')

Comparaisons de configurations

Commençons par faire un email vide de test :
$ cat mail.txt helo toi mail from: rcpt to: data subject:Ok ok .
Que nous utilisons comme ceci :
$ nc localhost 25 < mail.txt
Avec un sendmail en configuration par défaut, le correspondant reçoit :
Received: by machin.ath.cx with ESMTP id o2BK1BKu031170; Thu, 11 Mar 2010 21:01:11 +0100 Received: from toi (localhost [127.0.0.1]) by bidule.ath.cx (8.14.3/8.14.3) with SMTP id o2BK13FB043209 for ; Thu, 11 Mar 2010 21:01:03 +0100 (CET) (envelope from qualite@bidule.ath.cx) Date: Thu, 11 Mar 2010 21:01:03 +0100 (CET) From: Qualite MessageId: <201003112001.o2BK13FB043209@bidule.ath.cx>
Avec le nouveau HReceived nous obtenons :
ReturnPath: Received: by machin.ath.cx with ESMTP id o2BJxVBK031165; Thu, 11 Mar 2010 20:59:31 +0100 Received: id o2BJxOpC042941; Thu, 11 Mar 2010 20:59:24 +0100 (CET) Date: Thu, 11 Mar 2010 20:59:24 +0100 (CET) From: Qualite

Que retenir de cette partie ?

Vous conviendrez que notre mta est devenu moins bavard.
Nous avons ici abordé sendmail, mais il existe par exemple postfix qui, dixit bragon, "Tout ce que fait sendmail, postfix le fait en mieux". Je pense que vous n'aurez pas de difficulté a porter cette modification dans le conf de postfix, peut-être que LeCoyote nous honorera d'un commentaire à ce sujet .
Autre point à noter, il n'a été question QUE de `hostname`.(mc|cf) et pas de `hostname`.submit.(mc|cf) qui n'est en aucune manière concerné par cet article.

Dompter son Mail User Agent (mua)

Dompter son mta, c'est bien, mais que fait-on lorsque nous n'avons pas la main dessus ?

Thunderbird

Mes mails pros sont gérés par OBS et j'utilise comme mua Thunderbird qui a la mauvaise idée de transmettre l'ip ou le hostname lors du HELO (ou EHLO) ce qui donne par exemple ceci :
Received: from [192.168.5.12] (*.fr [217.1.2.3]) (authenticated) by smtp05.msg.oleane.net (MTA) with ESMTP id o1QB4km3010343 for Fri, 26 Feb 2010 12:04:46 +0100
Que l'on peut transformer en :
Received: from truc.org (*.fr [217.1.2.3]) (authenticated) by smtp06.msg.oleane.net (MTA) with ESMTP id o2BGsI5N007702 for Thu, 11 Mar 2010 17:54:18 +0100
Grâce à la clef de configuration de type string :
mail.smtpserver.smtp1.hello_argument
Que vous devrez créer dans le about:config du Thunderbird, et ceci pour tous vos mail.smtpserver bien entendu.

Que retenir de cette partie ?

Votre mua aussi peut donner des informations à votre insu. C'est inutilement idiot, une ip locale ne peut en aucun cas être une information pertinente pour le mta à l'autre bout de la connexion.

Conclusion

De manière générale les réglages par défaut des applications concernées ne sont pas pertinents sur le point abordé dans ce billet. Il est très important de pouvoir changer comme bon nous semble certains réglages que nous trouvons inappropriés.
Très logiquement, les mua/mta à sources fermées, certains cités de-ci de-là dans l'article, ne sont pas les plus simples à dompter.
Certains réglages ne sont pas prévus par les développeurs initiaux et ne le seront probablement jamais. Utilisons-en d'autres qui nous garantissent la liberté n°1 !

Les mauvaises pratiques chez les autres mua/mta populaires

Ils sont bavards :

Mail.app
Entourage
Live Mail
Yahoo

Les bonnes pratiques chez les autres mua/mta populaires

Ils sont discrets :

Gmail
mutt
Thunderbird en changeant un réglage

Cette liste n'est pas exhaustive, il s'agit des logiciels utilisés ou par moi ou par mes correspondants.

Si vous avez aimé ce post...

nginx et python – le perfect setup

pistache — Mon, 01 Mar 2010 11:47:32 +0000

Python est devenu assez à la mode, pour le développement web, ces dernières années avec l’arrivée de frameworks web comme Django, Pylons et web.py. On le voit souvent utilisé sur apache2, avec mod_python, ou sur des serveurs Python dediés à ça (CherryPy, etc)

Je cherche depuis longtemps un moyen de faire du Python sur HTTP. J’ai mis pas mal de temps mais je pense avoir trouvé une configuration sympa.

Je vous propose ici d’essayer nginx, un serveur HTTP (entre autres), très performant et beaucoup plus léger/rapide que apache2. Il est très efficace pour faire du reverse-proxy (c’est à dire être utilisé en frontal/load-balancer devant un serveur HTTP, et lui transmettre les requêtes en faisant du cache et le cas échéant du load-balancing).

La configuration de nginx est très simple, et la documentation est très complète : wiki.nginx.org. L’installation de nginx est facile, il est inclus dans la plupart des distributions actuelles, donc à vos emerge/apt-get.

apt-get install nginx

nginx ne gère pas le python nativement. Il y a plusieurs solutions cependant :

Faire du proxy vers un serveur qui gère le python, comme apache2. On perd la majeure partie de l’intêret de nginx, cependant.
Faire du FastCGI vers un serveur FastCGI. C’est la solution la plus fréquente, en utilisant fcgi.py ou flup
Faire du WSGI. C’est un protocole de communication entre serveurs HTTP et applications Python. Solution aussi assez fréquente.
Faire du proxy vers un serveur qui gère le python de manière native. C’est une solution moins fréquente mais très pratique.

Avant même de penser à choisir une des solutions ici présentes, il faut les comparer entre elles.

nginx => apache2 => python

L’ennui de cette solution c’est : apache2. Utiliser nginx pour forwarder à apache2 est presque inutile. Presque ? Oui, car on peut dire à nginx de garder les fichiers statiques pour lui. Cependant, le gain de cette méthode est assez minime, et ce n’est intéressant que pour faire du load balancing sur plusieurs apaches.

le FastCGI

FastCGI c’est une norme, pour faire traiter du contenu dynamique par une application externe. Donc le support du FastCGI tout seul est inutile, il faut aussi quelque chose pour gérer derrière.

J’ai testé flup, un framework Python léger. Le résultat : ça marche, méééé c’est lent. Je tournais autour de 35/50 requêtes par seconde, et l’utilisation en mémoire vive était phénoménale, 150 mégas pour 1000 requêtes. (bien sur ces chiffres n’auront de valeur que lorsqu’ils seront comparés aux autres).

FastCGI est sympa pour faire une configuration “vite”. C’est d’ailleurs la seule solution viable, à ma connaissance pour faire du PHP sur nginx, à part le proxy vers un autre serveur HTTP.

Bref, FastCGI ne m’a pas convaincu. Et mes tests avec les autres solutions m’ont donné raison. Toujours avec moi ? On passe au WSGI !

le WSGI

WSGI is the Web Server Gateway Interface. It is a specification for web servers and application servers to communicate with web applications (though it can also be used for more than that). It is a Python standard, described in detail in PEP 333.

le WSGI, c’est le standard pour le Web Python. Il n’y a qu’à consulter wsgi.org pour se rendre compte que c’est tout un monde. Il consiste en un ensemble de normes (nom de variables, par exemple) pour permettre au serveur d’exécuter un fichier codé en Python.

Le standard pour le WSGI sur les serveurs HTTP grand public, c’est le mod_wsgi de apache2. Il a été porté sur nginx, mais c ‘est une #@!## infame, qui ne marche que sur les vieilles versions et qui n’a pas été mise à jour depuis bientôt 2 ans et demi (cf. hg.mperillo.ath.cx/nginx/mod_wsgi/). J’ai obtenu des performances d’environ 133 requêtes par seconde avec, ce qui est déjà mieux que FastCGI, pour ceux qui suivent . Par contre, dès que j’ai voulu avancer un peu avec (toucher à la configuration, et surtout, passer à une version supérieure de nginx), j’ai été confronté à ses limites (et aux #@!## de faute de frappe dans le code source)

D’autant plus que l’auteur de mod_wsgi pour apache2 et l’auteur de mod_wsgi pour nginx reconnaissent ses limitations, respectivement ici et ici. Le premier document est très intéressant pour comprendre un peu l’architecture de nginx et ses différences avec apache2. En effet, le mod_wsgi pour nginx a été codé à partir de celui pour apache2, et il subit les différences d’architecture entre apache2 et nginx.

Attention, je ne remet absolument pas à cause le WSGI ici, juste l’implémentation de mod_wsgi dans nginx.

Parce que justement, un projet super récent, c’est…. uWSGI ! uWSGI sert à combler le manque de support du WSGI dans nginx, en rajoutant un module, meilleur que mod_wsgi. Il nécessite donc de recompiler nginx. Il y a encore une autre solution, nommée gunicorn, qui ne nécessite pas de recompiler nginx. C’est un serveur HTTP minimal qui gère le WSGI nativement. uwsgi offre plus de fonctionalitées que gunicorn, mais gunicorn a l’air assez dynamique (dans le développement), et est plus facile à utiliser (pas de recompilation, support de Django natif). Au niveau des performances, je me suis amusé à faire cette comparaison :

Comparaison des performances entre uwsgi et gunicorn en fonction du niveau de parallélisme

On constate plusieurs choses :

Les performances augmentent en utilisant 2 workers à la place d’un, mais au delà, le gain est ridicule, puis inexistant. Le nombre 2 est dépendant du nombre de coeurs de la machine, et le nombre de workers à utiliser ne sera pas le même sous un bi-socket octocore, bien évidemment. Les meilleures performances étaient obtenues en utilisant gunicorn+3workers.
La différence est vraiment minime, gunicorn est en moyenne légèrement au dessus de uwsgi.
Ces tests sont réalisés sur une application Django. Les performances augmentent en utilisant des frameworks plus légers comme web.py, bien évidemment.

uwsgi dispose de plus de fonctionalitées, comme par exemple une interface d’administration de serveur wsgi dans Django. Je vais ici expliquer l’installation et la configuration des deux solutions.

Ici je vais couvrir l’installation et la configuration de uwsgi et gunicorn avec Django et web.py, même si c’est bien sur adaptable avec d’autres frameworks supportant le wsgi (liste sur wsgi.org/wsgi/Frameworks).

Installation et configuration de uwsgi

Sous Debian :

1) Rajouter les dépots source, par exemple :

deb-src http://ftp.gr.debian.org/debian/ squeeze main contrib non-free

2) Télécharger la source

apt-get source nginx tar -zxvf nginx_*.orig.tar.gz cd nginx-* tar -zxvf nginx_*.debian.tar.gz

2) Télécharger uwsgi

cd ..


wget http://projects.unbit.it/downloads/uwsgi-0.9.4.2.tar.gz

tar -zxvf uwsgi-0.9.4.2.tar.gz

3) Modifier le paquet source de nginx pour y ajouter uwsgi. Il faut éditer le fichier nginx-*/debian/rules, trouver le bloc qui commence par ./configure et ou se trouvent toutes les options de compilation, et y ajouter

--add-module=$(CURDIR)/../uwsgi-0.9.4.2/nginx/

$(CURDIR)/../uwsgi-0.9.4.2/nginx/ est le chemin vers le dossier du module dans la source de uwsgi

4) maintenant, dans le dossier de la source de nginx, faites (pas besoin de root) :

dpkg-buildpackage

5) installer le .deb généré ainsi (en tant que root maintenant)

dpkg -i ../nginx-*.deb

6) Dernière étape : compiler uWSGI (le binaire en lui-même, qui va communiquer avec nginx par le biais du module)

cd ../uwsgi-0.9.4.2/ && make && make install && cp uwsgi_params /etc/nginx/

Cette dernière commande (le cp uwsgi_params…) sert à placer un fichier de configuration du module uwsgi exemple dans le repertoire de nginx.

Sous les autres distributions :

Il faut télécharger la source de nginx et de uwsgi, compiler nginx avec le module uwsgi (dans le répertoire nginx de la source de uwsgi), puis compiler uwsgi.

On a maintenant un serveur uWSGI et un nginx avec le module uwsgi. Il va maintenant falloir dire à nginx de transférer les requêtes au serveur uWSGI, avec une commande uwsgi_pass. Par exemple, dans la section server d’un de vos vhost (/etc/nginx/sites-enabled/default, par exemple, sous Debian) :

location / { include uwsgi_params; uwsgi_pass unix:///tmp/uwsgi.sock; }

Il faut ensuite créer une application WSGI, par exemple, pour le framework web.py :

import web


urls = (

    '/.*', 'hello',

    )
class hello:

    def GET(self):

        return "Hello, world."

application = web.application(urls, globals()).wsgifunc() applications = {'/': application }

Pour Django :

import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() applications = {'/': application }

Nommez ce fichier wsgi.py et placez le dans le repertoire ou vous allez placer votre code (pour Django, dans le repertoire du projet, évidemment). Si vos nerfs n’ont pas encore lâché ici, allez prendre une petite pause de 5 minutes à titre préventif, et reprenez. Maintenant, on va démarrer un serveur uWSGI. Placez vous dans le répertoire de votre fichier wsgi.py, et faites :

uwsgi -s /tmp/uwsgi.sock -C -w wsgi -p2 -L

Explications : le -s indique ou placer le socket (ça pourrait aussi être une adresse au format hôte:port, pour un usage distant). Le -w wsgi indique de charger le fichier wsgi(.py), le -p2 indique de démarrer 2 processus, et le -L désactive l’envoi des requêtes à stdout (=>flood).

Si vous allez à l’adresse de votre serveur web, vous devriez voir votre application Python en face de vous ! Vous voilà en train d’utiliser nginx+uwsgi+python.

En annexe, je rappelle que uwsgi est aussi utilisable avec apache et lighttpd.

Aussi, dans le dossier source de uwsgi, vous trouverez des templates pour un module d’administration de Django, à installer dans le repertoire des templates de l’administration de Django (si, si).

Installation et configuration de gunicorn

gunicorn est carrèment plus facile à installer. Il est codé en python, donc pas de compilation, seulement un easy_install :

easy_install gunicorn

La configuration est tout aussi facile, il suffit de cela dans la configuration du vhost dans nginx :

location / { proxy_pass http://unix:/tmp/gunicorn.sock }

On démarre ensuite gunicorn. Pour Django, gunicorn dispose d’un support intégré, il vous suffit de vous placer dans le répertoire de votre projet, puis :

gunicorn_django -b unix:/tmp/gunicorn.sock --workers=2

Pour web.py, il faut créer un module :

import web


urls = (

    '/.*', 'hello',

    )
class hello:

    def GET(self):

        return "Hello, world."

application = web.application(urls, globals()).wsgifunc()

Il faut ensuite démarrer le serveur Gunicorn. En étant dans le repertoire ou se trouve le module web.py (le fichier donc le code vient avant, là, au-dessus, oui), :

gunicorn -b unix:/tmp/gunicorn.sock --workers=2 wsgi

Je vous invite à consulter ce lien : gunicorn.org/tuning.html, pour vous permettre d’augmenter les performances de gunicorn.

Annexe

Fichiers statiques

location /admin-media {alias /usr/lib/pymodules/python2.5/django/contrib/admin/media;}

location /static {root /var/www/byteflow;}

Ces deux lignes, à rajouter après le “location /” avec uwsgi_pass ou proxy_pass (selon votre configuration) indiquent à nginx de traiter les fichiers statiques directement. Il faut bien évidemment adapter à votre configuration.

Munin

Vous pouvez trouver des plugins nginx pour munin ici. Je n’ai pas trouvé de plugin munin pour uwsgi/gunicorn, mais je pourrais peut-être en faire un si je trouve le temps.

Plusieurs serveurs

Si par hasard vous avez plusieurs serveurs gunicorn/uwsgi répartis sur plusieurs machines , vous pouvez les utiliser en déclarant une section

upstream nom {}

dans nginx, contenant les adresses des serveurs distant (hôte:port ou emplacement du socket) et en utilisant “nom” comme argument à uwsgi_pass et proxy_pass.

Conclusion

Ces deux architectures sont très pratiques pour faire tourner du python dans un serveur web, ici nginx. uwsgi dispose de plus de fonctionalités, mais la plupart (template d’admin Django, memory profiling) pourraient facilement être ajoutées à gunicorn, qui est beaucoup plus léger à installer/configurer/maintenir (2 commandes et 3 lignes de configuration dans nginx). J’ai les deux personellement sur mon serveur, j’ai eu à alterner entre les deux pour écrire cet article, et c’est pas bien dur, un daemon à arrêter, un autre à démarrer, et changer une ligne dans la configuration de nginx.

Liens

wsgi.org

gunicorn.org/

projects.unbit.it/uwsgi/

irc.freenode.org/#gunicorn

nginx.org/

djangoadvent.com/

www.django-fr.org/

www.djangoproject.com/

webpy.org/

Je tiens à remercier la communauté Geek{node|fault}, le chan irc #gunicorn, les développeurs de gunicorn qui sont très aimables, ainsi que Amandarn qui m’a aidé pour certains détails.

Si vous avez aimé ce post...

Chromium: l’adolescence de l’enfant de google.

koolfy — Fri, 26 Feb 2010 22:39:55 +0000

Chromium (Chrome pour la version estampillée Google) est un projet né dans le buzz absolu, mais aussi dans le plus simple appareil. Lors de sa naissance, tout lui manquait: le support de flash, un support java, des plugins (et donc un moyen de se prémunir des publicités envahissantes), des thèmes, un semblant de stabilité et surtout une version linux native !

Attentifs à son existence post-buzz, nous avons déjà couvert sa naissance sur Linux, le début de son apprentissage, et le moment semble venu de marquer un nouveau chapitre dans l’évolution du navigateur : l’adolescence.

Au risque de synthétiser les deux premiers articles, il semble nécessaire de ré-établir le contexte et la genèse de ce projet, afin de mieux en comprendre le parcours.

Attention : Cette page reprends ma vision personnelle du contexte de la sortie de Chrome/Chromium et a pour objectif de poser le décor pour la suite de l’article. Cette page n’engage donc que moi et n’est pas nécessaire à la suite de l’article, si vous n’êtes pas d’accord avec mon point de vue, ne vous énervez pas : passer à la page 2

Avant la conception

Le monde des navigateurs n’était pas rose, Internet Explorer avait le rôle du père violent, un échec total qui ne parvenait à maintenir son autorité que par la force de son poing et la violence de ses pratiques anti-concurrentielles, Safari était ignoré par au moins 90% du marché, Opera était un refuge obscur que l’on trouve presque par hasard, une sorte de soupe de bonnes idées (très) mal arrangées, et de choix intéressants, mais pas concluants.

Et Firefox là-dedans ? Il fut d’abord envoyé par la Mozilla Foundation en tant que messie venu se dresser contre l’hégémonie d’Internet Explorer, et prêcher la bonne parole du Logiciel Libre et des standards dans cet océan de code propriétaire.

Firefox fut rapide, Firefox fut efficace, Firefox fut puissant, Firefox fut multi-plateforme, Firefox fut meilleur. Il engrangea ainsi à juste titre des utilisateurs par poignées, une solide réputation, un écosystème de plugins et devint même le porte-flambeau de la lute pour la percée du Logiciel libre au delà de Linux, au delà des geeks : dans la vie quotidienne du grand public, au nez et à la barbe des logiciels propriétaires.
(petit témoignage humoristique représentant la place de Firefox dans nos esprits en ces temps-là)

Mais ce qui s’apparenta d’abord à de l’adoration et à de l’amour inconditionnel, commença à perdre de sa fraicheur à partir et au delà de Firefox 2.0. Il commença à perdre de sa légèreté, à traîner la patte, à s’approprier toute la mémoire RAM de nos systèmes et la retenir en otage, et à ne plus convenir à de plus en plus d’utilisateurs. Alors, tout naturellement (et surtout sous Linux), chacun partit en quête d’un navigateur plus léger, plus rapide, quitte à sacrifier quelques avantages de Firefox, mais à travers les 4 ou 5 petits projets inaboutis, chacun revint bredouille et se rendit à deux évidences : “Firefox reste un excellent navigateur”, et “Il n’existe pas d’alternative viable à l’Alternative.”

Et peu à peu, les utilisateurs se rendirent compte que la concurrence au sein des alternatives à Internet Explorer et aux navigateurs propriétaires était tout simplement inexistante, et que chacun avait un choix simple à faire : “Le mal, ou Firefox.”

naissance d’un navigateur, d’un buzz et d’un imparfait.

L’annonce et la sortie initiale de la toute première mouture du navigateur firent un fracas monumental. Ce que Google annonçait était purement et simplement une alternative à Firefox, et ses points forts et principaux arguments étaient très exactement les reproches faits à Firefox : la gestion de la mémoire RAM, la réactivité, la vitesse des rendus, le moteur JavaScript. Chrome les réalisait d’emblée.

Les frustrés et les curieux se jetèrent sur Chrome et déclarèrent dans les premiers jours avoir définitivement abandonné Firefox, et fait de Chrome leur navigateur par défaut. Dans les premiers jours seulement car comme notre premier article sur l’arrivée de Chromium (le parent/jumeau Opensource de chrome) sur Linux l’indiquait, même plus d’un an après la sortie du navigateur, ses carences en faisaient plus une PoC (Proof of Concept) qu’un navigateur viable dans la vie de tous les jours, c’est ainsi que le buzz s’éteignit, et que seuls les utilisateurs les moins exigeants continuèrent de l’utiliser quotidiennement.
Le pic d’utilisation de Chrome retomba largement, et tout le monde ou presque se retourna vers Firefox.

Malgré les désenchantements, Chromium était là, et alors qu’il luttait contre l’oubli, certains, dont une partie de la rédaction de Geekfault, restaient persuadés qu’il devait être suvi car il n’avait pas seulement sa place, mais était une nécessité dans l’équilibre concurrentiel des navigateurs.

Un écosystème de plugins en bonne santé.

La principale lacune de Chromium, c’était l’absence d’un système de plugins. Quand il fut implémenté, la question restait entière : est ce que l’API de plugins permettrait une intégration aussi efficace qu’avec Firefox ? Allait-elle parvenir à créer une communauté de développeurs de plugins comparable à la communauté de Firefox ?

Aujourd’hui, la réponse est claire : oui.
Au 26 février 2010, le site de référencement des plugins Chromium recense 2990 plugins, et évolue à une vitesse régulière d’à peu près 30-40 plugins par semaine.
Leur intégration au browser est parfaite et prévue pour ne pas affecter l’ergonomie ni les preformances du browser, on sent qu’un réel effort a été fait dans ce sens, contrairement par exemple au système de Widgets d’Opera (qui m’a traumatisé.)

Les plugins rencontrés sont assez variés, il en existe forcément pour checker vos mails google, ou servir d’interface intégrée à des sites comme Picasa, Twitter, Facebook, Slashdot, Google Buzz, Icanhascheezburger, il en existe pour “rendre plus esthétique/ergonomique” des sites comme Facebook ou Netvibes, et biensur la catégorie des plugins qui imitent des plugins déjà existants et très prisé sur Firefox.

Cependant, si cet écosystème évolue rapidement et est en bonne santé, il faut être réaliste : il en est à ses balbutiements. En effet, la plupart des extensions pour Chromium sont très basiques, il en existe un très grand nombre qui ne sont qu’un script .js de 15 lignes ne s’appliquant qu’au site l’ayant créé. Ça gonfle le nombre de plugins listés sur le site, mais ça ne pousse pas leur qualité globale vers de haut. Il est vrai qu’il existe quelques plugins ayant évolué très vite, et donc qui sont à la fois stables, utiles, efficaces et complets, mais il faut encore les chercher attentivement, et parcourir la liste de tous les plugins vous révèlera que 80% des plugins sont encore des petits scripts baclés à l’utilité douteuse.

Geekfault ne vous oublie pas, et prévoit un article reprenant les 10 plugins les plus indispensables de Chromium, Stay Tuned !

Déjà un plugin d’ad blocking puissant, efficace et en évolution constante

Même s’il en existe plusieurs, celle qui se démarque est AdBlock (accompagné de son “tray-icon” séparé du moteur).

Il permet un filtrage efficace des publicités, même très agressivement incrustées dans les pages, non seulement grâce à une intégration parfaite des “Filter List Suscriptions” comme l’Easylist (plus une liste particulière propre à Chromium), mais également grâce à un système un peu particulier de filtrage manuel des pubs récalcitrantes.

Si une pub est passée à travers les mailles du filet, vous pouvez bien évidemment l’indiquer à AdBlock, qui vous présentera alors un petit cadre avec une “SlideBar” à faire glisser vers la droite jusqu’à ce que la pub disparaisse. AdBlock va dès lors appliquer des règles de filtrages de plus en plus violentes sur l’élément jusqu’à atteindre le parfait compromis entre le filtrage de la pub et l’affichage correct du reste de la page. Une fois l’élément filtré et les nouvelles règles enregistrées, elles deviennent disponibles dans la page de configuration du plugin, éditables à tout moment. Il en va de même pour les exceptions de type “Whitelist”.

Vous trouverez également plusieurs options sympatiques, comme la possibilité de laisser passer les pubs textuelles qui ne vous dérangent pas (comme celle de Google), ou de filtrer les pubs incrustées dans les vidéos de Youtube (option encore en Beta)

Son principal défaut actuellement est de ne pas empêcher les pubs de se charger: en effet, en l’absence de règles de blocking intégrées à Chromium, les plugins de filtrage de pubs en sont actuellement réduites à les “cacher” par des règles de CSS. Si ce procédé épargne vos yeux et votre CPU, il n’en est pas de même pour votre bande passante.
Heureusement, (et contrairement à ce que beaucoup de paranoïaques prédisaient) Google ne compte pas mettre de bâtons dans les roues des plugins de filtrage de pubs, au contraire, et pour les plus sceptiques d’entre vous, un simple coup d’oeil au site du projet Chromium vous apprendra que la fonction en question est en développement actif.

L’équipe d’AdBlock est donc bien évidemment à l’affût, et n’attends que son implémentation définitive pour l’intégrer dans son procédé de filtrage.

Un plugin de type “Firebug” ? Mieux, un outil intégré au Navigateur !

Beaucoup de Web Developpers ont peur de quitter Firefox par crainte de perdre leur meilleur ami : Firebug.

Il n’en est rien ! Chromium a intégré un outil de développement surpuissant au navigateur.
Celui-ci intègre entre-autres une console javascript, un affichage structuré de la source d’une page, des outils de chronométrage des chargement des différents éléments d’une page, de profiling des ressources consommées par chaque élément de la page, ainsi que plusieurs outils que je ne comprends pas du tout, n’ayant aucune notion de développement web

Bien que toujours inférieur à Firebug, cet outil est déjà très complet, en évolution constante, et totallement suffisant pour ne pas se retrouver “tout nu”.
Il existe déjà quelques petites extensions permettant de le compléter un peu, mais celles-ci sont anecdotiques et encore très minimalistes.

Un développement (trop ?) dynamique

Le développement de Chromium est tout sauf lent. Avec un rythme d’environ 100 révisions par jour, se tenir à jour est une mission quotidienne… et dangereuse.

En effet, Chromium étant une version “git” permanente, se ruer sur la toute dernière révision n’est pas forcément une bonne idée.
Au menu : erreurs de rendu, régressions dans l’interface graphique, corruption occasionnelle de certains plugins, boucles infinies dans le CPU, fuites de mémoire (parfois de l’ordre de la fontaine, voire du Titanic), ou simplement disparition de certaines fonctionnalités le temps de les recoder complètement (comme par exemple les “pin tab”)…

Heureusement, les distributions font souvent leur packaging de façon intelligente et proposent des versions snapshot reconnues “stables”, plus ou moins à jour, permettant un compromis tout à fait convenable. Il est toutefois déconseillé de s’aventurer hors de ces packages, si on veut pouvoir continuer à utiliser Chromium comme navigateur principal.

La communauté autour du développement est abondante, et les développeurs réactifs, même s’ils ne peuvent pas être partout à la fois et qu’ils ont beaucoup de travail rien qu’avec l’énorme quantité de patch à webkit que Chromium intègre.
Cependant leur ordre de priorité fait que souvent les bugs spécifiques à Linux sont plus coriaces et trainent plus longtemps, ou simplement que les features sont d’abord achevées sur les versions Windows, quelques jours/semaines avant les versions Linux.

Google Chrome vs Chromium, une fois pour toutes.

Deux ans après, je croise tous les jours des gens qui attribuent à Chromium des reproches de Chrome, et qui n’ont toujours pas clairement assimilé la distinction entre les deux.

Sur la page de clarification des deux projets :

Tableau comparatif des deux navigateurs

Pour faire simple :
Google héberge le projet Chromium, et paye une équipe de développeurs centraux sur le projet Chromium. Ceux-ci (aidés de la communauté) font des patch webkit, des ajouts de fonctionnalités, des améliorations de performances, de réactivité, de l’interface graphique… en bref : font avancer le navigateur.
Ce navigateur (Chromium), est sous licence libre (BSD pour la plupart).

Une fois que tous les objectifs nécessaires à une Milestone (déterminée par l’équipe de dev de Google) sont atteint, Google fait un Copier/Coller de tout le code de Chromium, “fork” le projet Chromium, y ajoute le code qui attribue un identifiant unique à chaque installation du navigateur, qui envoie les données de navigation à Google, et ce genre d’ “améliorations” made in Google, y ajoute des codecs propriétaires (h.264, mp3, etc), et enfin, fait une annonce de la sortie de la nouvelle version de Chrome : Chrome-[version_antérieure ++] !
Puis on lance le développement de Chromium-[version_de_Chrome ++], et le cycle recommence.
Le tout distribué sous licence propriétaire (comme le permet la licence BSD de Chromium).

En résumé, Chromium n’envoie pas vos informations de navigation à votre insu à Google, c’est Chrome qui s’en charge !
D’ailleurs Google met un point d’honneur à se détacher «le plus possible» du développement de Chromium : ils hébergent le projet (comme beaucoup d’autres sur code.google.com), salarient les développeurs principaux, et évidemment décident de la direction que le projet prends (vu que c’est à fortiori la direction que Chrome prendra), mais c’est «tout» !
Dans le code de Chromium il n’apparait aucune mention à Google ni à Chrome, aucune information n’est envoyée à Google, ces liens sont établis dans Chrome.

Le code source est disponible en téléchargement, les développeurs sont ouverts aux contributions, aux suggestions et même aux réclamations de la communauté autour du site du projet, ce ne sont pas des nazis ayant vendu leur âme et leurs principes à Google (enfin, ils sont payés par google mais) ils sont plus préoccupés par la qualité et l’efficacité de leur navigateur que par l’hégémonie de leur employeur.

Les seuls moments où on sent l’influence de Google derrière eux résident dans les choix d’implémentation orientés vers la branche Chrome OS du projet, ou dans les objectifs du navigateur (ex: quand un dev refuse un patch qui ralentit le lancement du navigateur de 100ms (!)).

J’espère que la distinction est désormais claire dans l’esprit de chacun.

Chromium, prêt à voler de ses propres ailes.

Après avoir utilisé Chromium pendant plusieurs mois, et vécu tous les constats faits en page 2, je peux maintenant affirmer que Chromium a enfin ce qu’il faut pour être un navigateur principal pour l’utilisateur moyen à avancé.

Biensur il est encore inférieur à Firefox en plusieurs points (souvent la maturité des plugins proposés), mais il a enfin gagné sa place parmi les navigateurs principaux, et surtout, est enfin sorti de son aura de “Projet inachevé” et de “Proof of Concept” qui l’aura suivi pendant près de deux années.

Pour toutes ces raisons, je le conseille à beaucoup de gens qui se plaignent de Firefox, ou simplement qui ont d’autres priorités dans leurs exigences, tout en reconnaissant que pour beaucoup de gens encore, Firefox reste le meilleur choix.

Si vous avez aimé ce post...

DenyHosts pour empêcher le bruteforce sur SSH

Lord — Wed, 24 Feb 2010 10:31:35 +0000

Ras le bol de voir des tentatives de connexion sur votre SSH ? Il existe plusieurs logiciel pour vous en prémunir avec en tête de liste le célèbre Fail2ban qui permet de protéger SSH ainsi que la plupart des autres serveurs logguant l’authentification. Mais alors pourquoi choisir DenyHosts ? DenyHosts se limite à la protection SSH mais sa force provient de deux fonctionnalités : utiliser un système de synchronisation entre plusieurs DenyHosts ( je ne l’aborde pas ), mais également le partage des IP incriminées. Afin de récupérer des IP à blacklister et de d’offrir les siennes afin de se fabriquer une blacklist évolutive.

Un attaquant vera son adresse IP inscrite dans le fichier /etc/hosts.deny l’empêchant de se logguer.

Installation

Gentoo

emerge denyhosts

Debian et dérivés

aptitude install denyhosts

Red Hat et consorts

yum install denyhosts

Configuration

/etc/denyhosts

#Doit pointer vers votre fichier logguant les tentatives de connexions SECURE_LOG = /var/log/auth.log


#Doit pointer vers votre fichier de blacklist

HOSTS_DENY = /etc/hosts.deny

BLOCK_SERVICE  = sshd
#Nombre d'essai avant d'être bloqué pour une connexion non root

DENY_THRESHOLD_INVALID = 5

DENY_THRESHOLD_VALID = 5
#Nombre d'essai avant d'être bloqué pour une connexion en temps que root

DENY_THRESHOLD_ROOT = 3

DENY_THRESHOLD_RESTRICTED = 1

WORK_DIR = /var/lib/denyhosts

SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES

HOSTNAME_LOOKUP=YES

LOCK_FILE = /var/run/denyhosts.pid
#Vers quelle adresse email signaler une attaque infructueuse

ADMIN_EMAIL = votre@mail

SMTP_HOST = localhost

SMTP_PORT = 25

SMTP_FROM = DenyHosts 

SMTP_SUBJECT = DenyHosts Report

SYSLOG_REPORT=YES
#temps avant la remise à zéro du compteur

AGE_RESET_VALID=5d

AGE_RESET_ROOT=10d

AGE_RESET_RESTRICTED=25d

AGE_RESET_INVALID=10d

RESET_ON_SUCCESS = yes

DAEMON_LOG = /var/log/denyhosts

DAEMON_LOG_TIME_FORMAT = %b %d %H:%M:%S

DAEMON_LOG_MESSAGE_FORMAT = %(asctime)s - %(name)-12s: %(levelname)-8s %(message)s

DAEMON_SLEEP = 30s

DAEMON_PURGE = 1h

#Ces dernières lignes permettent d'utiliser le partage d'IP. On peut se limiter au partage montant ou descendant #C'est purement facultatif mais je vous le recommande. SYNC_SERVER = http://xmlrpc.denyhosts.net:9911 SYNC_UPLOAD = yes SYNC_DOWNLOAD = yes

Puis pour le lancer :
/et/init.d/denyhosts start

Sous Gentoo pour le lancer automatiquement au boot vous devez l’ajouter à votre « rc par défaut » :
rc-update add denyhosts default

Logs

Allons faire un tour dans les logs de DenyHosts pour voir à quoi s’attendre.

Exemple de synchro où l’on récupère des IP à blacklister :

Feb 20 04:42:43 - denyhosts : INFO received new hosts: ['217.10.117.161', '194.185.200.156', '91.75.180.114', '202.141.132.50', '60.248.91.64', '211.100.42.83', '202.165. 177.203', '211.155.227.171', '58.221.34.18', '88.191.15.133', '210.51.36.162', '220.165.28.66', '91.205.74.41', '61.178.74.43', '202.117.54.134', '74.127.18.195', '195.250.39.6 6', '216.229.160.194', '122.70.147.103', '200.195.168.194', '202.44.11.60', '94.190.187.113', '213.5.64.164', '201.116.98.210', '163.13.175.44', '119.149.189.199', '93.152.156. 13', '125.7.209.4', '210.51.48.71', '88.117.234.162', '217.97.185.35', '217.20.183.73', '117.41.228.195', '201.20.186.222', '79.39.6.98', '221.165.162.4', '211.72.171.76', '209 .255.67.10', '80.203.122.116', '12.152.124.2', '70.169.201.74', '202.5.95.205', '217.219.67.131', '65.98.97.98', '218.241.155.144', '80.14.186.105', '96.31.68.39', '218.108.247 .138', '61.138.217.19', '82.230.95.10']

Ajout d’un attaquant + upload au serveur central :

Feb 21 09:25:31 - denyhosts : INFO new denied hosts: ['81.7.171.15'] Feb 21 09:43:01 - sync : INFO sent 1 new host

Reset du compteur en cas de login réussi :

Feb 21 11:35:03 - loginattempt: INFO resetting count for: 10.0.0.3

Liens

Site officiel
Statistiques mondiales de DenyHosts

Si vous avez aimé ce post...

EeeGW – ZE retour du détour ! – Proxycache.

bragon — Sat, 20 Feb 2010 18:44:39 +0000

Vous vous souvenez dans l’article : http://geekfault.org/2009/12/31/construire-sa-gateway-from-scratch/ Je vous ai parlé de plein de petits ajouts afin de rendre votre eeegw MUST.

Je vous avais parlé de :

Pouvoir mettre en place un proxy transparent pour votre connexion pour mettre en cache les pages les plus souvent demandées et ainsi économiser de la bande passante.

Finalement j’ai trouvé le soft parfait pour faire ça : http://www.pps.jussieu.fr/~jch/software/polipo/

Choix du soft de proxy cache

Pourquoi ne pas avoir choisi squid ?

- Parce qu’il est trop gourmand en ressource pour la eeegw.
- Parce que sa conf est imbittable pour un non initié.

Pourquoi avoir choisi Polipo ?

- Parce qu’il consomme que dalle en ressource et en espace disque.
- Parce que sa configuration est assez implicite.
- Polipo à toutes les fonctions d’un bon web proxy.
- Polipo est parfaitement adapté aux petits reseaux, mais pourrait parfaitement fonctionner sur un gros réseau bien qu’il n’ai pas spécialement été design dans ce but.
- Polipo sait filtrer, ainsi si on souhaite totalement interdire facebook.com ou msn.con/live.com sur son reseau On peut très facilement.
- Polipo sait causer ipv4 et ipv6, Ainsi polipo peut être utilisé en tant que bridge pour permettre aux clients ipv6 d’accéder à l’internet v4 et vis et versa.
- Polipo sait parler SOCKS, ainsi il peut très facilement se coupler (ou s’accoupler au choix :p) avec tor afin de surfer de façon anonyme.

Installation et configuration de Polipo

Sur eeegw rien de plus simple :

apt-get install polipo

Allé on va le configurer : /etc/polipo/config


proxyAddress = "::0"        # both IPv4 and IPv6

# proxyAddress = "0.0.0.0"    # IPv4 only

proxyPort = 8118

# If you are enabling 'proxyAddress' above, then you want to enable the

# 'allowedClients' variable to the address of your network, e.g.

allowedClients = 127.0.0.1, 10.0.69.0/24

# Uncomment this if you want your Polipo to identify itself by

# something else than the host name:

proxyName = "polipo.eeegw.bragon.info"

# Uncomment this if you want to use a parent SOCKS proxy:

# socksParentProxy = "localhost:9050"

# socksProxyType = socks5

### Memory

### ******

# Uncomment this if you want Polipo to use a ridiculously small amount

# of memory (a hundred C-64 worth or so):

# chunkHighMark = 819200

# objectHighMark = 128

# Uncomment this if you've got plenty of memory:

chunkHighMark = 50331648

objectHighMark = 16384

## me permet d'acceder a http://10.0.69.250:8118/polipo/index pour voir ce qui est mis en cache

disableIndexing = false

disableServersList = false

### HTTP

### ****

# Note that PMM is somewhat unreliable.
pmmFirstSize = 16384

pmmSize = 8192
# Suggestions from bragon

maxConnectionAge = 10m

maxConnectionRequests = 1024

serverMaxSlots = 16

serverSlots = 4

tunnelAllowedPorts = 1-65535

/etc/polipo/forbidden

microsoft.com live.com msn.com hotmail.fr hotmail.com facebook.fr facebook.com

Laissez le fichier option de base.

On peut faire feu

/etc/init.d/polipo start

http://ip.eeegw:8118/polipo/

Vous pourrez ainsi voir la configuration ainsi que pas mal de chose étant mis en cache.

http://ip.eeegw:8118/polipo/index?

Le choix s’offre à vous

Deux solutions :
- Soit vous dites à vos clients d’utiliser dans leur firefox/chromium comme proxy : ip.polipo:8118
- Soit via une règle iptables vous dites simplement à votre eeegw que tout traffic sortant via le port 80 doit d’abord passer par polipo.

Croyez moi vous allez économiser de la bande passante

Si vous avez aimé ce post...

IPv6 pour les nuls^Wgeeks

LeCoyote — Wed, 17 Feb 2010 11:55:19 +0000

À moins d’avoir passé les 6 dernières années sous un gravillon, ou de n’avoir vraiment aucun intérêt pour les protocoles Internet (on ne vous juge pas !), vous avez probablement entendu parler d’IPv6. Seulement voilà : on en dit du bien ou du mal, mais sait-on exactement ce qu’est IPv6 après tout ? Voici le premier d’une petite série d’articles destinés à lever le voile.

Qu’est-ce qu’IPv6 ?

Comme vous le savez certainement, Internet aujourd’hui repose essentiellement sur IPv4. Pour lui succéder, IPv6 (ou IPng, bien que cette deuxième dénomination soit moins fréquente) a été conçu il y a bien longtemps déjà. Sa mise en service était prévue en 1996 !
Bizarrerie d’Internet, IPv5 n’a pas grand chose à voir avec les deux autres ; pour les curieux, il s’agit du Stream Protocol ST-II, qui est décrit ici.
Alors qu’une adresse IPv4 ressemble à 81.93.247.142, une adresse IPv6 ressemble plutôt à 2001:758:1664::42 … mais nous y reviendrons plus tard.

Pourquoi remplacer IPv4 ?

Disons-le tout net, IPv4 marche encore très bien (aux dernières nouvelles en tous cas). Mais comme une adresse IPv4 est codée sur 32 bits, IPv4 ne peut adresser que 2³² hôtes, soit un peu plus de 4 milliards de machines diverses et variées. La quantité d’adresses disponibles, qui semblait suffisante il y a 30 ans, diminue constamment, sans compter qu’une bonne partie de ces adresses sont réservées et ne peuvent être allouées. Selon certaines estimations, l’espace d’adresses IPv4 sera épuisé d’ici 2011/2012.

Par ailleurs, la plupart des FAI grand public attribuent en général UNE adresse IPv4 publique par abonné … et encore. Si vous êtes derrière un routeur ou une *box, sauf cas particulier, vous pouvez dire adieu à l’adresse IP publique : le routeur fera probablement du NAT (Network Address Translation). Et s’il s’agit d’une connexion Internet mobile, là encore, il n’y aura probablement pas d’IP publique au bout de la ligne.
Or, selon la définition que l’on donne à Internet, ne pas avoir d’adresse IP publique c’est ne pas être sur Internet (c’est en tout cas l’opinion de Benjamin Bayart, président de FDN).
Par ailleurs, le NAT c’est bien gentil, mais ça complique très nettement la vie dès qu’il s’agit de faire du peer-to-peer (la technologie au sens large) ou de la VoIP par exemple.

Enfin, de façon générale, IPv6 apporte de nombreuses améliorations par rapport à IPv4 : il a été conçu de manière à permettre une répartition plus facile de son espace d’adressage, à effectuer un routage plus efficace, à mieux supporter le multicast ou encore à intégrer un concept de mobilité pour les terminaux nomades : autant de bonnes raisons de migrer !

Avant d’aller plus loin, voici un petit brin de théorie visant à exposer les bases d’IPv6. Après cela, nous verrons comment se doter d’IPv6 à la maison, et nous aborderons enfin quelques-unes des améliorations évoquées précédemment ainsi que certains aspects plus pointus de l’utilisation et de la configuration.

Généralités sur les adresses

Pour commencer, les adresses IPv6 sont codées sur 128 bits, ou encore 16 octets. Il y a donc 2¹²⁸ adresses possibles, soit environ 3.4×10³⁸, c’est-à-dire environ 5×10²⁸ adresses pour chacun des 6.5 milliards d’habitants de la planète (en 2006, source Wikipedia).
Selon l’hypothèse la plus conservatrice, un foyer connecté à Internet pourrait recevoir environ 18 … milliards … de milliards d’adresses publiques : 18 x 10¹⁸, ou 2⁶⁴ plus exactement. Par foyer. On devrait pouvoir tenir le coup.

Comme ça n’est pas très pratique d’écrire 128 bits sous forme décimale (essayez, vous verrez …), on utilise une représentation hexadécimale : les digits sont groupés par 4, les groupes sépares par des “:”, et les zéros non-significatifs peuvent être omis tant que ça reste non-équivoque. Exemples :

3FFE:1123:4567:89AB:CDEF:1234:5678:9ABC
2001:7a8:b285::1 ; ici les zéros superflus ont été remplacés par “::”, ce qui ne peut être fait qu’une seule fois dans l’écriture de l’adresse pour éviter toute ambiguïté. Cette adresse équivaut donc à 2001:07A8:B285:0000:0000:0000:0000:0001 ;
::1 ; c’est l’équivalent du bon vieux 127.0.0.1, la boucle locale (pas celle de FT, vous l’aurez compris) ;
:: ou ::/0; l’adresse la plus simple à écrire sans aucun doute, c’est le pendant du 0.0.0.0 (/0) d’IPv4 ;
::ffff:81.93.247.142 ; petite entorse à la règle, il est acceptable d’utiliser la notation décimale IPv4 quand on écrit une adresse IPv4 “mappée” en IPv6 (attention, ça ne marche pas partout) ;
2001:7a8:b285::12::34 n’est PAS une adresse valide. Les :: sont équivoques, on ne sait pas exactement où se situe le 12 au milieu de l’adresse.

ping6 vers le site de GeekFault depuis un serveur voisin

La notation CIDR (en “slash”) fonctionne sur le même principe qu’en IPv4 : le suffixe /X signifie qu’une adresse appartient à un réseau dont les X premiers bits sont fixés (partie réseau de l’adresse donc) et les 128-X derniers bits sont réservés à l’hôte. Par exemple, 2001:7a8::/32 désigne le réseau dont les 32 premiers bits sont 2001:7a8 (en l’occurrence il s’agit du FAI français Nerim), tandis que ::/0 représente n’importe quelle adresse IPv6. On peut dire que 2001:758:1664::42 et 2001:758:1664::57 sont deux hôtes probablement différents mais appartenant au même sous-réseau 2001:758:1664::/64, lui même appartenant à 2001:758:1664::/48. Un sous-réseau de taille 64 est normalement situé sur un même brin physique.

Les 16 premiers bits d’une adresse IPv6 nous renseignent sur son type d’utilisation, par exemple 2001 pour les adresses attribuées de façon permanente, ou 3FFE pour le 6bone expérimental aujourd’hui obsolète. Deux cas particuliers sont à noter : le préfixe 2002::/16 identifie les adresse 6to4 (un protocole de transition pour ceux qui sont privés d’IPv6), tandis que le préfixe fe80::/10 est réservé aux adresses locales (un peu à l’image de 169.254.0.0/16) ou “link-local” ; ces adresses locales ne sont utilisables que sur un même segment du réseau local ou sur une connexion point-à-point.

Pour pouvoir continuer à utiliser des noms symboliques plutôt que des adresse littérales, il faut que le DNS soit lui aussi IPv6-ready. Dans la pratique, un serveur DNS délivre des enregistrements AAAA pour la recherche directe (conversion de nom en adresse IPv6) et utilise les zones .ip6.arpa pour les recherches inverses. Par exemple :
[cc]geeknode@ircd ~ $ dig +short -t aaaa www.kame.net
2001:200:0:8002:203:47ff:fea5:3085
geeknode@ircd ~ $ dig +short -x 2001:200:0:8002:203:47ff:fea5:3085
orange.kame.net.
geeknode@ircd ~ $[/cc]

Dernière astuce à noter, il arrive de devoir (ou de vouloir) taper une adresse IP littérale dans un navigateur, dans un fichier de configuration, ou à d’autres endroits où le caractère “:” est déjà utilisé (pour spécifier le numéro de port par exemple). Dans ce genre de cas, il est possible d’indiquer une adresse IPv6 littérale en l’encadrant par des crochets, comme par exemple [2001:758:1664::42].

Maintenant que l’on connaît un peu mieux les différents types d’adresses IPv6 et que nous savons à quoi elles ressemblent, nous allons faire un tour du côté de la configuration.

Auto-Configuration sans état

L’une des nouveautés d’IPv6, c’est la possibilité pour l’OS de configurer automatiquement une interface réseau. Certes, IPv4 le fait déjà assez bien avec l’aide du DHCP, mais il s’agit là d’une configuration dite “avec état”, ou “stateful” : le serveur DHCP tient à jour une liste des clients configurés et des adresses IP disponibles. Nous allons aborder ici la configuration automatique “sans état”, ou “stateless”.

Dès lors que le protocole IPv6 est disponible et si l’auto-configuration est activée, l’OS va chercher ses réglages tout seul. La première étape consiste à monter une adresse link-local sur l’interface considérée. Pour cela, on utilise le préfixe fe80::/10 et l’adresse MAC de l’interface ; par une subtile transformation, les 48 bits de cette adresse vont donner les 64 bits de droite de l’adresse locale. Cette transformation est simple :

on part de l’adresse MAC, 00:18:F8:CC:CC:20 par exemple (ici un Linksys WRT54GL) que l’on sépare en deux blocs de 24 bits par le milieu : 00:18:F8 et CC:CC:20 ;
on inverse la valeur du 7è bit du premier groupe, appelé “universel/local” ; 0×00 en binaire donne 00000000, qui devient 00000010 après l’inversion du 7è bit, et donc 0×02 de retour en hexa ;
on réunit le groupe ainsi modifié et le deuxième groupe du début en insérant au milieu les octets FFFE, ce qui donne au final les 64 bits 02:18:F8:FF:FE:CC:CC:20 ;

Génération de la partie hôte de l'adresse à partir de l'adresse MAC

Il ne reste plus qu’à ajouter le préfixe link-local pour obtenir l’adresse : fe80::0218:f8ff:fecc:cc20/64.

Avant d’utiliser cette adresse, il faut vérifier son unicité sur le lien réseau. C’est l’une des applications du Neighbour Discovery Protocol, nommément la Duplicate Address Detection (DAD). Le protocole NDP repose sur ICMPv6, qui pour l’occasion se dote de nouveaux types de messages. L’un d’eux, “Neighbour Solicitation”, sert justement à vérifier que l’adresse que l’on s’apprête à utiliser n’est pas déjà attribuée à quelqu’un d’autre sur le lien. Lorsqu’une interface est montée est que son adresse locale potentielle (ou “tentative” dans le jargon) a été déterminée, l’hôte envoie un paquet “Neighbour Solicitation” à destination de cette même adresse et attend une réponse éventuelle. S’il n’y en a pas, l’adresse est considérée comme disponible et devient utilisable sur l’interface considérée.

Jusqu’ici, nous avons tout de même obtenu une adresse utilisable sur le LAN sans l’aide d’un DHCP. Cependant, pour sortir du LAN, il nous manque encore deux éléments : un routeur et une adresse IPv6 globale routable. Là encore c’est grâce à NDP que l’on va y arriver.
Un routeur IPv6 envoie périodiquement sur le réseau des messages NDP dits “Routeur Advertisement” (RA pour faire court) qui contiennent entre autres informations le préfixe réseau à utiliser pour l’auto-configuration ainsi que l’adresse du routeur. L’hôte peut également envoyer un message “Router Solicitation” à une adresse multicast spéciale dite “all routers” valable sur le lien (link-local), ff02::2 ; le routeur doit répondre à cette requête par un RA. L’hôte utilise alors le même mécanisme que pour déterminer l’adresse link-local, mais en utilisant cette fois-ci le préfixe annoncé par le routeur.
Après vérification (DAD), l’adresse unicast globalement unique et routable ainsi obtenue est validée pour de bon, et l’adresse du routeur enregistrée comme passerelle par défaut : bienvenue sur la toile-v6 !

Il est temps maintenant de passer à la pratique

IPv6 en pratique

Dans la vraie vie, tout le monde est plus ou moins égal face à IPv6. Les plus chanceux (abonnés Nerim, FDN, Free dans une moindre mesure) ont de l’IPv6 natif (ou presque) directement sur leur interface WAN (fût-elle xDSL ou FTTH). Pour les autres, il faudra utiliser des méthodes basées sur les tunnels, comme le 6to4 ou Teredo (article à venir …).

Quoi qu’il en soit, un abonné recevra de son FAI (ou de son fournisseur de tunnel) un préfixe de la forme 2001:7a8:b285::/48. Le FAI se charge de router tout ce préfixe vers la ligne de l’abonné, et ce dernier se débrouille pour faire le reste. Comme il n’y a en général qu’une seule ligne chez l’abonné, par laquelle passe tout le trafic, il faut un routeur.

Fabuleux, vous en avez probablement déjà un. Mais est-il seulement IPv6-aware ? À moins d’avoir une FreeBox, la réponse est probablement “non” : le support IPv6 dans ce genre de matériels est pour le moins anecdotique. Le geek IPv6-friendly va donc se monter une petite bécane sous Linux (ou flasher son WRT54GL par exemple) avec le support IPv6 compilé dedans. On peut certainement faire pareil avec *BSD, mais je ne parle pas de ce que je ne connais pas

Le routeur fait en général au moins trois choses chez un particulier, quatre si on a du bol :

il fournit la connexion au WAN, fût-ce par ADSL, câble, fibre ou autre ;
il route les paquets, c’est quand même pas banal, avouez-le ;
il aide à se configurer les postes clients ;
en option, il fait du filtrage.

Pour la connexion au WAN, le plus facile reste l’IPv6 natif. En effet, en ajoutant simplement une ligne contenant ipv6 , à son /etc/ppp/options, pppd se charge de négocier une IPv6 link-local avec le pair d’en face.

Pour le routage, c’est là encore désarmant de simplicité :
[cc lang="bash"]echo 1 > /proc/sys/net/ipv6/conf/all/forwarding[/cc]
Félicitations : le routeur est maintenant capable de relayer les paquets à qui de droit. Bien sûr, libre à vous d’ajouter ça au sysctl.conf pour faciliter les choses.

Il faut ensuite informer les postes clients de la disponibilité d’IPv6 et à les configurer. On peut bien sûr utiliser l’auto-configuration stateful, avec DHCPv6, ou stateless, dont on a parlé au chapitre précédent. Cette dernière méthode requiert l’utilisation sur le routeur de radvd, pour Router ADVertisement Daemon. Après l’avoir installé selon la méthode de votre choix (apt-get, emerge, tar …), il vous faudra éditer le fichier de configuration (en général /etc/radvd.conf ou approchant), dont voici un example :
[cc]interface br-lan
{
AdvSendAdvert on;
MaxRtrAdvInterval 60;
# AdvLinkMTU 1492;

prefix 2001:7a8:b285::1/64
{
};
};[/cc]

Le fichier comporte au moins une définition d’interface ; ici, il s’agit de l’interface br-lan d’un WRT54GL sous OpenWRT. Dans l’ordre, les 4 premières options servent à indiquer que le service doit envoyer des RA et répondre aux sollicitations sur l’interface, les RA sont au maximum espacés de 60 secondes, et le MTU annoncé sur le lien est fixé à 1492 (option désactivée ici, mais très utile si vous êtes en PPPoE sur l’interface WAN). Vient ensuite une définition de préfixe, ici de longueur 64, qui ne contient ici aucune option particulière : les options par défaut conviendront parfaitement.

Enfin, pour le filtrage, il existe sous Linux le pendant IPv6 d’iptables, tout simplement nommé ip6tables. Tout comme en IPv4, il est possible de faire du conntrack en IPv6, moyennant un kernel “pas trop vieux” (ça ne marchera pas avec un 2.4 par exemple). La principale différence avec l’IPv4 est bien sûr l’absence du NAT : tout ou presque se passera directement dans la table FORWARD

Nous n’avons pas encore parlé de la configuration des postes clients, et il y a une raison très simple à cela : par défaut, il n’y a rien à faire. Du moment que le routeur est configuré correctement, l’OS client saura s’auto-configurer comme nous l’avons vu au chapitre précédent. Comme IPv6 est utilisé en priorité chaque fois que c’est possible, l’accès aux services disponibles se fera automatiquement et de façon transparente pour l’utilisateur final.

Nous voici arrivés à la fin de cette introduction à IPv6. Moyennant un petit temps de prise en main, ce “nouveau” protocole ne devrait pas poser trop de soucis à ceux qui ont déjà quelques notions de réseaux IP. Quelques points à retenir :

la forme des adresse doit maintenant vous être familière, attention simplement à l’écriture compacte (placement des “::”) et aux préfixes particuliers (2002::, fec0::, fe80:: …) ;
ICMPv6 joue un grand rôle dans IPv6, le NDP se substituant ainsi pour partie à ARP et DHCP ;
un routeur sous linux avec un démon radvd suffira à faire profiter de l’IPv6 à votre LAN.

Cet article est j’espère le premier d’une série sur le sujet. Il y a en effet d’autres aspects à aborder ou certains problèmes à évoquer (comme le souci du pMTU par exemple) et un ou deux mythes à casser (non, IPv6 ne ralentit pas votre connexion !). À bientôt !

Si vous avez aimé ce post...

EeeGW : Créer soi-même une passerelle réseau

bragon — Thu, 31 Dec 2009 11:44:59 +0000

Le routeur-passerelle (gateway, en anglais) est le lien entre votre réseau local et l’Internet. Sans doute utilisez-vous simplement la box fournie par votre FAI ou un autre modem-routeur acheté en magasin, mais installer et configurer soi-même son gateway présente de nombreux avantages.

Je vous présente via cet article ma transformation d’un EeePC, qui ne me servait à rien, en routeur-passerelle réseau. Je vous présente mon travail, mais il est très facile d’adapter ce travail à votre utilisation et à votre propre machine afin de la transformer en un super routeur Linux qui tue tout

Article illustré par l’exemple

Cette documentation est adapté à mon LAN qui est paramétré sur le subnet 10.0.69.0/24. Le eeegw, comme je l’appelle, prend donc l’adresse 10.0.69.250/24 est sera la gateway de mon réseau afin que mes autres machines puissent accéder à l’internet.

À quoi ça sert de monter sa propre Gateway ?

Ne pas avoir à redémarrer sa connexion internet chaque fois qu’on a envie de toucher aux règles de firewalling. En effet les box des FAI nécessitent de redémarrer pour prendre en compte de nouveaux paramètres
Ne pas avoir une boite noire à la place de routeur : on peut surveiller son réseau et savoir quels sont les packets qui y passent
Pouvoir loguer via iptables et ulogd par exemple (futur article)
Pouvoir grapher via rrdtool / Mrtg la bande passante qui passe par vos liens
Pouvoir héberger un petit blog (par exemple) directement sur votre passerelle
Pouvoir mettre en place un proxy transparent pour votre connexion pour mettre en cache les pages les plus souvent demandées et ainsi économiser de la bande passante (futur article)
Savoir exactement ce qui se passe avec votre connexion internet
Mettre en place des outils de détection d’attaques sur votre réseau via SNORT (futur article)

Choisir le bon matériel

N’importe quel ordinateur avec un tant soit peu de puissance est suffisant pour faire un bon gateway, il suffit que cette machine soit munie de plusieurs interfaces réseau.

Durant des années j’ai eu en tant que passerelle un PII 266Mhz muni de 128MB de ram et d’un disque dur de 2Go. Pour cette nouvelle gateway j’ai choisi le EeePC 7″ que j’ai baptisé eeegw

Pourquoi ce choix? Parce que le EeePC dispose de beaucoup d’avantages à être transformé en Gateway :

Il est muni d’une batterie donc non affecté par une coupure de courant éventuelle
Il dispose d’une interface réseau ethernet et d’une interface wifi
La carte wifi intégrée est une Atheros et supporte donc (via le pilote madwifi) les multi wireless WAN
Sa puissance est honorable (512 de RAM / 900Mhz / 4Go de SSD)
On peut très facilement installer une distribution GNU/Linux dessus
On peut installer un serveur web dessus en toute tranquillité
Son matériel est pleinement supporté par le noyau Linux
Sa consommation est très faible, permettant donc d’être allumé 24/24 sans détruire son budget EDF

Installer la bonne distribution

Si comme moi vous souhaitez transformer un EeePC, je vous conseille Debian. Personnelement j’aurais bien choisi Gentoo, mais le EeePC prendrait trop de temps à compiler, et ne refroidit pas spécialement bien.

Installer la distribution Debian sur un EeePC est très bien documenté, il vous suffit de créer une clée usb bootable. Je vous renvoie à la documentation de Debian : EeeDebian.

Glossaire des packets Debian nécessaires pour ce howto

iproute
iptables
apache2
munin munin-node
wireless-tools

Se connecter aux FAI sur les interfaces concernées

Je dispose pour ma part d’une connexion au web fournie via le fournisseur d’accès Nerim (j’établis donc la connexion en PPPoE comme avec la plupart des fournisseurs ADSL). Je dispose d’une seconde connexion via du WiFi fourni par un de mes voisins (qui accepte que je me serve de sa connexion).

Ne vous inquiétez pas si vous n’avez qu’une seule connexion, ou si vous avez Free+Numericable ou n’importe quelle autre combinaison, cet article est facilement adaptable à votre configuration.

Connexion PPP

Configurez la connexion PPPoE:
/etc/ppp/peers/dsl-provider
# Minimalistic default options file for DSL/PPPoE connections noipdefault defaultroute replacedefaultroute hide-password #lcp-echo-interval 30 #lcp-echo-failure 4 noauth persist #mtu 1492 #persist #maxfail 0 #holdoff 20 plugin rp-pppoe.so eth0 user "plopplop@adslc.fai.fai" usepeerdns

Et enregistrez vos identifiants:
/etc/ppp/chap-secret
# Secrets for authentication using CHAP # client server secret IP addresses "plopplop@adslc.fai.fai" * "mdpdelamortquituedevotreFAI"

Et créez le script qui initiera cette connexion:
/etc/eeegw/fai.sh
#!/bin/bash /usr/sbin/pppd call dsl-provider

Placez ensuite ce script fai.sh dans les régles de pre-up du fichier Debian /etc/network/interfaces. Votre connexion ppp sera ainsi demarré au boot de la eeegw. Voir, pour exemple, le mien en fin d’article.

Finalement, un script pour s’assurer que votre connexion PPP est bien up avec votre fournisseur d’accès ADSL. Il est lancé via un cron toutes les 5 minutes ainsi, si la connexion tombe, ce script lui permettra de se relancer automatiquement.
/etc/eeegw/nerim.sh
#!/bin/bash


#SERVERS="62.4.16.36 feth1-0-thevenin.nerim.net www.nerim.net hsrp1-telehouse.nerim.net feth0-0-julo.nerim.net"

SERVERS2=irc.geeknode.org

STATUS_LINK=0
USER=`id -u`
if [ ! "$USER" = "0" ];

then

  echo "you're not root, you can't check adsl."

  exit

fi
if [ -f /var/run/checkadsl ]

then

  echo already running

  exit

fi
if ! /sbin/ifconfig ppp0 > /dev/null

then

  echo "No pppd running. Restarting NOW."

  killall pppd

  /etc/init.d/networking restart

  exit

fi
touch /var/run/checkadsl
## recupere l'ip du peer

ip=$(/sbin/ifconfig  ppp0 | /bin/grep "P-t-P" | /usr/bin/cut -d":" -f3 | /usr/bin/cut -d" " -f1)

SERVERS=$ip
for i in $SERVERS;

do

  ping -c 3 $i

#1>/dev/null 2>/dev/null

  if [ "$?" = "0" ];

  then

    STATUS_LINK=1

    rm -f /var/run/checkadsl

    echo "exit c est ok on passe au deuxieme test"

  exit 0

  fi

done
# on sen bat du test maintenant

if [ "$STATUS_LINK" = "0" ];

then

  echo "ADSL Link DOWN. Restarting NOW."
  /etc/init.d/net.ppp0 restart

  rm -f /var/run/checkadsl

fi

rm -f /var/run/checkadsl

Connexion wifi

Voici une simple configuration de l’interface WiFi. Je vous renvoie à la documentation adaptée pour plus de détails.

Placez la clé wep dans /etc/eeegw/fb.key puis créez le script
/etc/eeegw/wifi.sh
#!/bin/bash wlanconfig ath0 destroy wlanconfig ath0 create wlandev wifi0 wlanmode sta sleep 5 ifconfig ath0 up iwconfig ath0 essid freebox key `cat /etc/eeegw/fb.key` dhclient ath0

Ajoutez /etc/eeegw/wifi.sh à vos régles pre-up du fichier /etc/network/interfaces

Autre type de connexion

Si par exemple vous êtes chez Free, je vous conseille de monter votre Freebox en mode bridge. Ainsi votre eeegw n’aura plus qu’à effectuer un bound dhcp sur eth0 afin d’obtenir l’IP publique Free et tous les packets arriveront donc directement sur votre eeegw.

Pour redispatcher la connexion, vous pouvez soit le faire via une seconde carte réseau sur votre eeegw (ou votre pc équivalent), soit transformer votre eeegw en point d’accès WiFi! Transformer un eeepc en eeeap est expliqué ici : eeeAP

Faire fonctionner les deux connexions ensemble

Plusieurs choix s’offrent à vous:

Vous n’avez qu’un seul lien vers une seule connexion internet. Passez directement à l’étape suivante.
Vous avez deux connexions web qui ont le même débit et vous souhaitez partager symétriquement le débit
Vous avez deux connexions web qui n’ont pas le même débit et vous souhaitez partager asymétriquement le débit
Vous avez deux connexions web qui ont ou pas le même débit : une en tant que connexion principale et l’autre en secours ou pour certaines routes en particulier

Personnellement j’utilise cette dernière solution, mais je vais aussi vous expliquer les deux autres possibilités de répartiton.

Activer IP Forwarding

Quel que soit les choix que vous ferrez par la suite vous avez besoin d’activer ip_forward dans votre noyau.

Indispensable pour que votre routeur fonctionne!
/etc/sysctl.conf
net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1

Et rechargez la configuration:
# sysctl -p

Distribuer sur deux connexions ayant le même poids

Imaginons que nous ayons FAI-1 derrière eth1 et FAI-2 derrière eth2. Ce deux connexions sont relativement identiques et nous souhaitons donc simplement distribuer équitablement le traffic et ainsi profiter du débit des deux connexions.

eth1: net=192.168.1.0/24, IP=192.168.1.130, Gateway=192.168.1.1
eth2: net=192.168.2.0/24, IP=192.168.2.131, Gateway=192.168.2.1

ip route add 192.168.1.0 dev eth1 src 192.168.1.130 table fai1 ip route add default via 192.168.1.1 table fai1


ip route add 192.168.2.0 dev eth2 src 192.168.2.131 table fai2

ip route add default via 192.168.2.1 table fai2
ip route add 192.168.1.0 dev eth1 src 192.168.1.130 ip route add 192.168.2.0 dev eth2 src 192.168.2.131
ip rule add from 192.168.1.130 table fai1

ip rule add from 192.168.2.131 table fai2

ip route add default scope global nexthop via 192.168.1.1 dev eth1 weight 1 nexthop via 192.168.2.1 dev eth2 weight 1

Distribuer sur deux réseaux de poids différents

Petit schéma explicatif de ce qu’on peut espérer faire avec une passerelle comme eeegw

(schéma a compléter)

Un script pour loadbalancer les connexions sur deux wan ayant différents poids : Notre eeegw devient multi lien ou dualwan

#!/bin/bash


##ip rule flush
## recupere l'ip du peer

peer=$(/sbin/ifconfig  ppp0 | /bin/grep "P-t-P" | /usr/bin/cut -d":" -f3 | /usr/bin/cut -d" " -f1)
ip route add ${peer} dev ppp0 table uplink1

#ip route add default via 213.41.185.56 table uplink1
ip route add 192.168.0.0/24 dev ath0 src 192.168.0.12 table uplink2

#ip route add default via 192.168.1.1 table uplink2
ip rule add from 192.168.0.12 table uplink2

ip rule add from 213.41.185.56 table uplink1

ip route add default scope global nexthop via 192.168.0.254 dev ath0 weight 1 nexthop via ${peer} weight 3

Le but du script share_wan.sh est d’enlever les deux routes par defaut engendré par le faite de se connecter en ppp et avec dhcp sur le wifi.
Ensuite il faut mettre en route par defaut soit le lien ppp soit le lien wifi.
La dernière ligne sert a donner un poids de 3 à la connexion Nerim et un poid de 1 à la connexion wifi.

Ainsi on enverra 3 fois plus de packets à Nerim qu’au WiFi.

/etc/eeegw/share_wan.sh
#!/bin/bash ip route del default dev ppp0 scope link ip route del default via 192.168.0.254 dev ath0 ip route add default scope global nexthop via 192.168.0.254 dev ath0 weight 1 nexthop via ${peer} weight 3

Routes par defaut / routes statiques

J’utilise ce système de route static via mon script route_static.sh pour définir via quel FAI je préfère me rendre pour tel ou tel service. C’est très pratique. (Je rappelle que j’utilise le cas numero 4, c’est à dire que ma connexion ppp est ma connexion principale, mais la connexion wifi ne me sert que ne backup au cas ou, et pour des routes particulières).

/etc/eeegw/route_static.sh
#!/bin/bash


## recupere l'ip du peer PPP

peer=$(/sbin/ifconfig  ppp0 | /bin/grep "P-t-P" | /usr/bin/cut -d":" -f3 | /usr/bin/cut -d" " -f1)
# telephone passe par la connexion ppp

ip route add 81.93.243.132 via ${peer}

# vpn perso passe par la connexion wifi ip route add 81.93.247.160 via ${peer} ip route add 193.47.184.2 via ${peer} ip route add 94.23.219.37 via 192.168.0.254

Serveur DHCP

L’eeegw doit donner des IPs via DHCP aux différentes machines du réseau.
# apt-get install dhcpd

/etc/dhcp3/dhcpd.conf
# option definitions common to all supported networks... option domain-name "lucifer.bragon.info"; option domain-name-servers 8.8.8.8;


ddns-update-style none;
authoritative;
default-lease-time 86400;

max-lease-time 86400;
subnet 10.0.69.0 netmask 255.255.255.0 {

  range 10.0.69.10 10.0.69.199;

 option routers 10.0.69.250;

}

# Réservations host satanas { hardware ethernet 00:02:b3:21:40:c0; fixed-address 10.0.69.18; option routers 10.0.69.250; option broadcast-address 10.0.69.255; }

Rajouter des VPN

Vous pouvez bien sûr rajouter des connexions VPN sur votre eeegw.
En effet cela vous permettra de directement propager la connectivité au VPN à toutes les machines de votre lan.
Pour se faire je vous renvoi vers les articles de target0 et moi même concernant les VPN.

http://geekfault.org/2009/10/04/allocation-dipv6-over-openvpn/
http://geekfault.org/2009/09/24/allocation-dadresses-ipv4-publiques-over-vpn/

Quality Of Service / tc qdisc

La qualité de service sur le reseau est très importante si vous ne voulez pas que vos utilisateurs se plaignent de lags.

Par exemple lorsqu’un appel en VoIP est émit, il est très désagréable de se mettre à laguer tout d’un coup car un de vos collaborateurs envoie un e-mail avec une pièce jointe énorme. Pour éviter d’avoir ce genre de désagrements, il faut mettre des priorités sur le traffic entrant et sortant.

J’ai décidé de faire un article prochainement afin de vous expliquer comment je gère la QOS de ma eeegw.

Firewalling

/etc/eeegw/firewall.sh
#!/bin/bash # REMISE à ZERO des règles de filtrage iptables -F iptables -t nat -F


# DEBUT des "politiques par défaut"

# Je veux que les connexions entrantes soient bloquées par défaut

iptables -P INPUT DROP
# Je veux que les connexions destinées à être forwardées soient acceptées par défaut

iptables -P FORWARD ACCEPT
# Je veux que les connexions sortantes soient acceptées par défaut

iptables -P OUTPUT ACCEPT
# FIN des "politiques par défaut"

# Pas de filtrage sur l'interface de "loopback"

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -i eth0 -j ACCEPT
#on ne filtre pas les vpn

iptables -A INPUT -i tap0 -j ACCEPT

iptables -A INPUT -i tap1 -j ACCEPT

iptables -A INPUT -i ethylix0 -j ACCEPT
# J'accepte le protocole ICMP (i.e. le "ping")

iptables -A INPUT -p icmp -j ACCEPT
# J'accepte le protocole IGMP (pour le multicast)

iptables -A INPUT -p igmp -j ACCEPT
# J'accepte les packets entrants relatifs ? des connexions d?j? ?tablies

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#ssh

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

iptables -A INPUT -p tcp --dport 2605 -j ACCEPT
#apache

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
#tftp

iptables -A INPUT -p udp --dport 69 -j ACCEPT
#mon smtp

iptables -A INPUT -p tcp --dport 25 -j ACCEPT
#vpn

iptables -A INPUT -p tcp --dport 7777 -j ACCEPT
# voip

#iptables -A INPUT -p tcp --dport 5060 -j ACCEPT

#iptables -A INPUT -p tcp --dport 5061 -j ACCEPT
# supervision zabbix
iptables -A INPUT -p tcp --dport 10050 -j ACCEPT

iptables -A INPUT -p tcp --dport 10051 -j ACCEPT
#Munin

iptables -A INPUT -p tcp --dport 4949 -j ACCEPT
# La règle par défaut pour la chaine INPUT devient "REJECT" (il n'est pas possible de mettre REJECT comme politique par défaut)

#iptables -A INPUT -j REJECT
#forward de la connection

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

iptables -t nat -A POSTROUTING -o ath0 -j MASQUERADE

iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE

iptables -t nat -A POSTROUTING -o tap1 -j MASQUERADE

iptables -t nat -A POSTROUTING -o ethylix0 -j MASQUERADE

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o ppp0 --clamp-mss-to-pmtu

Le but du script de firewall est d’être lancé une première fois, puis d’être sauvegardé comme la Debian-Way le suggère. Pocédons donc comme suit :
# sh /etc/eeegw/firewall.sh # iptables-save > /etc/network/firewall
Ainsi au boot des interfaces la machine lancera les règles iptables sauvegardées.

Firewall en sortie

NB : Dans cette exemple le firewall n’agit qu’en entrée, c’est à dire que par defaut nous laissons tout sortir sur le réseau. Vous pourriez sans aucun soucis filtrer en sortie.

Exemple de regles de filtrage en sortie :
# A mettre en début de script pour n'accepter explicitement QUE ce qui est autorisé. iptables -P OUTPUT DROP

# Règles output fonctionnement de base iptables -A OUTPUT -p tcp -o eth0 --dport domain -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --dport domain -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --dport ntp -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --dport ntp -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --dport rsync -j ACCEPT iptables -A OUTPUT -p udp -o eth0 --dport rsync -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --dport http -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --dport smtp -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --dport ssh -j ACCEPT iptables -A OUTPUT -p tcp -o eth0 --dport ftp -j ACCEPT

Explication fonctionnement du NAT

Imaginons que vous ayez un serveur FTP sur la machine A.
Imaginons que vous ayez un serveur Web sur la machine B.
Afin qu’un client puisse s’y connecter en venant de l’internet vous ne pouvez pas lui donner comme adresse afin de s’y connecter une des ip de votre LAN, mais l’ip que vous a attribué le FAI lors de votre connexion à celui-ci.
Le NAT est le fait que la eeegw sache vers quelle machine transmettre le traffic de tel ou tel service.
Ainsi le client établi une connexion FTP vers votre IP publique, la connexion FTP arrive sur votre eeegw qui va savoir qu’il faut qu’elle transmette ce traffic vers la machine A.

Pour plus d’explication sur comment faire ça, allez voir la partie firewall de la documentation.
Pour plus d’explication n’hésitez pas à aller lire la documentation Wikipédia sur le sujet.

Régles de NAT

Vous avez besoin d’ouvrir un port sur votre eeegw qui redirige sur une des machines de votre lan ?
Rien de plus simple. Procédez comme suit si vous avez par exemple un serveur web derrière 10.0.69.1 :

# iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 80 -j DNAT --to 10.0.69.1:80

Ensuite on save la nouvelle régle dans les régles devant se lancer au boot :
# iptables-save > /etc/network/firewall

Votre nouvelle règle de NAT/Firewall est donc automatiquement activée sans avoir à faire quoi que ce soit de plus sur votre eeegw.

Automatiser le lancement des scripts eeegw_script au boot

/etc/network/interfaces
auto lo iface lo inet loopback


# The primary network interface

allow-hotplug eth0

iface eth0 inet static

        address 10.0.69.250

        netmask 255.255.255.0

        network 10.0.69.0

        broadcast 10.0.69.255

        pre-up iptables-restore -c /etc/network/firewall
auto ath0

iface ath0 inet dhcp

wireless_mode Managed

pre-up /etc/eeegw/wifi.sh pre-up /etc/eeegw/nerim.sh pre-up /etc/eeegw/route_static.sh pre-up /etc/eeegw/ethylix.sh pre-up /etc/eeegw/QOS/qos.sh

Et si on monitorait /graphait tout ça ?

Exemple de graph que l’on va pouvoir obtenir grace à ce super howto (vu mensuel de ma connexion internet) :

Second Exemple: vue journalière de l’utilisation d’une connexion par un vpn.

Installation

# apt-get install munin apache2 munin-node # cd /usr/share/munin/plugins/ # ls

Repérez ici les choses qu’il serait intéressant de grapher sur votre munin puis :
# cd /etc/munin/plugins # ln -s /usr/share/munin/plugins/acpi # ln -s /usr/share/munin/plugins/apache_processes # ln -s /usr/share/munin/plugins/cpu # ln -s /usr/share/munin/plugins/df # ln -s /usr/share/munin/plugins/swap [....]

/etc/munin/munin.conf
[localhost.localdomain] address 127.0.0.1 use_node_name yes

Relancez munin-node
# /etc/init.d/munin-node restart

Ça devrait grapher tout simplement comme ça sous debian (l’installation sous gentoo demande un peu plus de délicatesses). Pour plus de détails : http://eeegw-ip-adresse/munin.

Sortie de ifconfig

ath0 Link encap:Ethernet HWaddr 06:15:af:8d:37:37 inet adr:192.168.0.12 Bcast:192.168.0.255 Masque:255.255.255.0 adr inet6: fe80::415:afff:fe8d:3737/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13848732 errors:0 dropped:0 overruns:0 frame:0 TX packets:4385032 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:1482140328 (1.3 GiB) TX bytes:307281227 (293.0 MiB)


eth0      Link encap:Ethernet  HWaddr 00:1f:c6:28:71:9e

          inet adr:10.0.69.250  Bcast:10.0.69.255  Masque:255.255.255.0

          adr inet6: fe80::21f:c6ff:fe28:719e/64 Scope:Lien

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:256988818 errors:0 dropped:0 overruns:0 frame:4160

          TX packets:258912344 errors:0 dropped:0 overruns:0 carrier:6

          collisions:0 lg file transmission:1000

          RX bytes:3516383801 (3.2 GiB)  TX bytes:0 (0.0 B)

          MÃ©moire:fbfc0000-fc000000 
ethylix0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet adr:194.110.69.23  P-t-P:194.110.69.17  Masque:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:4099 errors:0 dropped:0 overruns:0 frame:0

          TX packets:3932 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:500

          RX bytes:286787 (280.0 KiB)  TX bytes:399957 (390.5 KiB)
lo        Link encap:Boucle locale

          inet adr:127.0.0.1  Masque:255.0.0.0

          adr inet6: ::1/128 Scope:HÃ´te

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:4493171 errors:0 dropped:0 overruns:0 frame:0

          TX packets:4493171 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:0

          RX bytes:532519851 (507.8 MiB)  TX bytes:532519851 (507.8 MiB)
ppp0      Link encap:Protocole Point-Ã -Point

          inet adr:213.41.185.56  P-t-P:62.4.16.251  Masque:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1

          RX packets:6108340 errors:0 dropped:0 overruns:0 frame:0

          TX packets:4219070 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:3

          RX bytes:2251583910 (2.0 GiB)  TX bytes:836111670 (797.3 MiB)
tap0      Link encap:Ethernet  HWaddr 00:ff:b7:de:c8:b4

          inet adr:10.0.1.2  Bcast:10.0.1.255  Masque:255.255.255.0

          adr inet6: 2001:758:f00:8:2ff:b7ff:fede:c8b4/64 Scope:Global

          adr inet6: fe80::2ff:b7ff:fede:c8b4/64 Scope:Lien

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:4716451 errors:0 dropped:0 overruns:0 frame:0

          TX packets:2796718 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 lg file transmission:100

          RX bytes:4275489693 (3.9 GiB)  TX bytes:358571500 (341.9 MiB)
tap1      Link encap:Ethernet  HWaddr 00:ff:63:b8:57:ea

          inet adr:81.93.X.X  Bcast:81.93.X.X  Masque:255.255.255.128

          adr inet6: 2001:758:f00:cafe:2ff:63ff:feb8:57ea/64 Scope:Global

          adr inet6: fe80::2ff:63ff:feb8:57ea/64 Scope:Lien

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:43229918 errors:0 dropped:0 overruns:0 frame:0

          TX packets:26631144 errors:0 dropped:1826 overruns:0 carrier:0

          collisions:0 lg file transmission:100

          RX bytes:3891532561 (3.6 GiB)  TX bytes:4009241435 (3.7 GiB)

wifi0 Link encap:UNSPEC HWaddr 00-15-AF-8D-37-37-65-74-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:226972539 errors:0 dropped:0 overruns:0 frame:6623910 TX packets:5796868 errors:44600 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:280 RX bytes:2128136633 (1.9 GiB) TX bytes:515534254 (491.6 MiB) Interruption:18

Sortie de iproute

194.110.69.17 dev ethylix0 proto kernel scope link src 194.110.69.23 216.165.129.135 via 192.168.0.254 dev ath0 140.211.166.134 via 192.168.0.254 dev ath0 213.186.33.19 via 192.168.0.254 dev ath0 149.20.20.135 via 192.168.0.254 dev ath0 130.239.17.6 via 192.168.0.254 dev ath0 94.23.219.37 via 192.168.0.254 dev ath0 217.23.9.148 via 192.168.0.254 dev ath0 204.152.191.39 via 192.168.0.254 dev ath0 78.41.233.57 via 192.168.0.254 dev ath0 213.251.172.23 via 192.168.0.254 dev ath0 156.56.247.195 via 192.168.0.254 dev ath0 62.4.16.251 dev ppp0 proto kernel scope link src 213.41.185.56 81.93.247.0/25 dev tap1 proto kernel scope link src 81.93.247.10 193.200.171.0/24 via 81.93.247.1 dev tap1 10.0.69.0/24 dev eth0 proto kernel scope link src 10.0.69.250 91.199.232.0/24 via 81.93.247.1 dev tap1 10.0.1.0/24 dev tap0 proto kernel scope link src 10.0.1.2 195.190.3.0/24 via 81.93.247.1 dev tap1 192.168.0.0/24 dev ath0 proto kernel scope link src 192.168.0.12 193.200.226.0/24 via 81.93.247.1 dev tap1 91.198.105.0/24 via 81.93.247.1 dev tap1 91.209.245.0/24 via 81.93.247.1 dev tap1 193.200.181.0/24 via 81.93.247.1 dev tap1 78.41.232.0/21 via 81.93.247.1 dev tap1 91.191.144.0/20 via 81.93.247.1 dev tap1 81.93.240.0/20 via 81.93.247.1 dev tap1 169.254.0.0/16 dev eth0 scope link metric 1000 10.0.0.0/8 via 10.0.1.1 dev tap0 default dev ppp0 scope link

Ma eeegw en production

Les liens interessants

http://upload.wikimedia.org/wikipedia/fr/3/3e/Netfilter_schema.png
http://wiki.gcu.info/doku.php?id=linux:openvpn_multi-listeners_debian
Dual wan Cisco
http://www.dslreports.com/forum/remark,16388383?hilite=ip+sla
Antenne wifi externe sur sa eeegw
http://chris.olstrom.com/blog/howto/setup-dual-wan/
http://tldp.org/HOWTO/Traffic-Control-HOWTO/
http://markmail.org/message/aronyjanpuxenvug
http://lartc.org/howto/lartc.rpdb.multiple-links.html

Si vous avez aimé ce post...

Facebook s’apprêterait à lancer son serveur XMPP

Tito — Mon, 14 Dec 2009 05:50:16 +0000

Le 14 mai 2008, un développeur Facebook annonçait qu’ils travaillaient sur un serveur XMPP (Jabber) compatible avec son système de chat, permettant ainsi à tout le monde d’utiliser un client de messagerie instantannée classique pour chatter sur Facebook.

Depuis cette annonce, nous n’avions plus de nouvelles. Mais au début du mois dernier ProcessOne annonçait avoir découvert un serveur XMPP hébergé sur chat.facebook.com !

Attention : Cet article est sujet aux trolls sur l’utilité des réseaux sociaux

Une vieille idée

Facebook a lancé son système de chat le 7 avril 2008, via son interface web. Dès le début on s’est vite rendus compte qu’elle n’était pas très stable et nous obligeait à garder l’onglet Facebook ouvert en permanence.

Et le 14 mai, un développeur annonce qu‘ils développent activement une interface XMPP compatible avec ce chat. Pourtant, depuis ce post, on n’en a plus entendu parler (malgré les nombreux groupes, wish reports et lettres ouvertes le réclamant).

Mais une très bonne idée

Dès le lancement du chat Facebook, celui-ci a rencontré un grand succès. Après tout, quel est l’intérêt d’un IM si ce n’est de parler avec ses amis? Et Facebook connait, à priori, une grande partie de ceux-ci. J’ai personnellement remarqué que la plupart de mes contacts avaient délaissé MSN pour n’utiliser plus que ce chat Facebook.

Mais évidemment on se heurte vite aux limites des web-apps : lenteurs, instabilités, utilisation d’un navigateur, absence de notifications et encore instabilités! Je suppose que c’est ce qui a motivé les développeurs à utiliser un vrai protocole de messagerie instantannée.

Le XMPP

Le serveur de chat de Facebook découvert par ProcessOne a été déployé sur chat.facebook.com (port 5222, port standard serveur-client pour Jabber) et répond aux requêtes de type XMPP!

Nous ne pouvons que saluer le choix de Facebook pour ce protocole libre et déjà supporté par une multitude de clients de messagerie instantannée, aussi bien desktops que mobiles!

Le XMPP n’a malheureusement jamais connu le succès escompté, loin derrière Yahoo! Messenger et Microsoft Live Messenger aux protocoles propriétaires mal implémentés dans nos logiciels libres. Facebook va peut-être redorer un peu le blason de ce protocole délaissé en lui apportant ses 350 millions d’utilisateurs.

On regrettera tout de même que, selon les scans de ports, Facebook n’a pas activé le server-to-server qui aurait permis aux utilisateurs du chat Facebook de communiquer avec des utilisateurs de réseaux Jabber concurrents et vice-versa.

À quand le déploiement public?

Même si le serveur de type ejabberd modifié répond aux requêtes de connexion, il répond toujours par la négative. Facebook n’a pas encore fait d’annonce publique, sans doute parce que le service est actuellement en phase de tests.

L’existence de ce serveur est encourageante, mais on est en droit de se demander si les administrateurs de Facebook valideront sa mise en service puisqu’ils n’ont, à priori, aucun moyen de le monétiser…

Si vous avez aimé ce post...

Backup d’un compte Gmail

Tito — Sat, 24 Oct 2009 00:58:50 +0000

Il y a quelques jours, Google a dû désactiver un compte e-mail légitime. Immédiatement je me suis imaginé dans cette situation insoutenable que serait la perte de toute ma correspondance depuis deux ans !

En effet aujourd’hui je préfère faire confiance à Google pour conserver mes messages plutôt que risquer la perte de ceux-ci après un crash de mon disque dur. Mais comment tout de même faire un backup mensuel de mon compte Google Apps?

Gmail Backup

Je suis tombé sur un projet intéressant : Gmail Backup, compatible Windows et Linux. Pour Linux vous aurez le choix entre la ligne de commande et une petite interface en wxPython.

L’interface graphique est très simple d’utilisation puisqu’elle vous demande votre adresse Gmail, mot de passe et dossier où enregistrer le backup. On peut éventuellement demander de ne sauvegarder qu’une certaine période dans le temps.

L’interface en ligne de commande est tout aussi puissante, et très pratique si vous souhaitez faire vos backups sur un serveur SSH.

Sauvegarder tout le compte : ./gmail-backup.sh backup /dossier/où/backup user@gmail.com password
Sauvegarder du 28/02/2008 au 31/08/2009 : ./gmail-backup.sh backup /dossier/où/backup user@gmail.com password 20080228 20090831
Restaurer un backup : ./gmail-backup.sh restore /dossier/où/backup user@gmail.com password

IMAP Backup

Personnellement j’ai une confiance totale en Google pour conserver mes données (Troll inside). Si toutefois vous êtes chez un autre prestataire, le seul moyen efficace que j’aie trouvé pour faire un backup est d’utiliser un client e-mail tel que Thunderbird.

Si vous êtes intéressé par un tel backup, je vous renvoie à d’autres sites:

En anglais et très bien illustré
Ou en français si vous êtes vraiment allergique à l’anglais

Geekfault » internet

Yubikey : la petite clé qui assure

Le problème

La Yubikey, en bref

Utilisation simple

Application n°1 : login Linux

Compilations

Configuration de PAM

Application n°2 : authentification à 2 facteurs avec SSH

Utilisation avancée

ATTENTION

Configuration de la clé

Serveur de validation “maison”

PAM + Serveur de validation maison

N’oublions pas …

Conclusion et informations additionnelles

Liens

Si vous avez aimé ce post...

Reverse SSH : accéder à un serveur derrière un NAT/Firewall

Principe de fonctionnement

Avantages

Vérifiez la configuration du serveur SSH local

Let’s go!

Service au démarrage

Aller plus loin

Si vous avez aimé ce post...

La nouvelle mode Geek : avoir son domaine .42

Pourquoi on vous parle de ça ?

Erf, je sais pas résoudre les domaines en .42, comment je fais ?

Je possède Bind

J’ai DJB … Oui Je sais ….

Je suis un pauvre pommé, j’ai pas de serveur de nom

Hey mec ? Comment je réserve mon .42 ?

Liste des domaines enregistrés

Si vous avez aimé ce post...

Devenez miroir de Wikileaks sans risque (corrigé)

Le problème

Sécuriser OpenSSH

Créer l’utilisateur

Créer l’environnement chroot

Un dummyshell

Test

Configurer un nom de domaine et un VirtualHost

Soumettre votre miroir à Wikileaks

Si vous avez aimé ce post...

Ifconfig.me, connaitre son IP publique en un rien de temps

Si vous avez aimé ce post...

Eeegw – part III – Quality Of Service aka QOS

Script de QOS exemple1 basé sur HTB

Scheduler / Ordonnanceur

Mise en place des outils

Traduction du manuel de tc

Qu’est-ce qu’une classe

Datagrame IPv4 et Type Of Service : TOS

Tableau des TOS possible dans un Datagram IPv4

Exemple de ce qu’on peut faire avec TOS

Si vous avez aimé ce post...

maintenir son DNS menteur avec Adblock

Plan du site

Chez yoyo.org

Liste adblock polonaise

La liste adblock de notre profil Firefox

Création du fichier blackhole.conf

Conclusion

Si vous avez aimé ce post...

DNS menteur, une autre méthode anti-curieux

WebSpy : l’autre côté obscur de la Force

Plan de l’article

Présentation et quantification de la nuisance

Une navigation “vanilla” c’est en fait ça :

Bande passante

Protections individuelles

Filtrage au niveau du navigateur

Au niveau du fichier /etc/hosts

Qu’en conclure ?

Proxies filtrants

Fonctionnement générique d’un proxy filtrant

Qu’en conclure ?

DNS menteur

Scénario