Navigo késako ?

Le Navigo est le billet électronique qui sera à terme utilisé par tous les franciliens dans tous les transports en commun. La technologie du Navigo (nom de code Calypso) est une carte à microprocesseur (comme sur votre carte bleue) dotée d'une antenne lui permettant de communiquer sans contact avec le valideur. La mémoire de la puce contient quant à elle un numéro d'identification unique, toutes les informations relatives à l'abonnement, ainsi que celles relatives à l'abonné (nom, adresse, parait-il photo numérisée).

Lorsque le contact avec le valideur est établie, un enregistrement part vers les bases de données du transporteur, puis vers celles du STIF. Le premier jeu de base est sensé servir à détecter les fraudes, le second à établir des statistiques pour "améliorer" les services. Admettons.

Cet enregistrement, qui file je ne sais où, contient les données de passage (localisation, heure, etc) ainsi que le numéro d'identification de la carte. Et déjà à ce stade, deux problèmes se posent...

Conservation des données

Le premier, évident, est celui concernant le rapprochement que l'on peut faire entre ce numéro magique et les coordonnées de l'usager, permettant théoriquement de connaître ses déplacements urbains. A cela le STIF a toujours répondu que, suivant maintenant scrupuleusement les directives de la CNIL, la durée de conservation de ces enregistrements n'est plus que de 48h. L'informaticien que je suis se dit déjà que cela doit être un paramétrage facile à changer "en cas de besoin". Le citoyen lui, est un peu gêné de savoir que, même pour "seulement" 48h, une petite cartographie le concernant est réalisable. Faut pas que l'histoire se répète ou qu'une bombe explose dans Paris sinon ça va être le drame...

Maintenant l'informaticien reprend le dessus et se demande bien ce que veut dire "effacé". Après quelque recherche il semble que l'effacement soit tout relatif mais néanmoins efficace puisqu'il s'agirait de celui du numéro d'identification. Il ne resterait donc plus que les données horaires et géographiques, toujours utiles au STIF pour ses statistiques, un peu moins aux transporteurs, mais admettons...

Good evening, John Anderton

Le second problème, un peu moins évident celui-là, est posé par la carte en elle-même. C'est bien gentil de faire disparaître tout contact, mais qu'est-ce qui m'assure, à moi citoyen, que les données qu'elle contient ne peuvent être lues à mon insu ? Ceux qui rigolent en pensant aux porteurs de navigo qui frottent désespérément leur carte "sans contact" sur la borne se disent qu'il y a peu de risque de ce côté là. Mais en fait ce n'est pas tout à fait exact.

En effet, petit rappel sur le principe même du RFID, ce n'est pas la carte qui fournit l'énergie permettant les échanges, mais la borne. L'émission de radio-fréquence va fournir à la carte le jus nécessaire à l'activation de la puce et l'établissement d'un dialogue. En augmentant l'énergie émise, on augmente la distance possible. Et à ce stade rien n'empêche, théoriquement parlant, d'activer les puces par une borne placée dans la rue par exemple. Comme cela peut être pratique dans certains contextes... genre un passage de manif. Mais cela n'arrive qu'en chine ce genre de choses, admettons...

Mais l'histoire a eu un heureux dénouement, dont CNIL a pu à juste titre s'enorgueillir ,lorsqu'est arrivé le "Navigo Découverte". Ce passe sera par la suite plus connu sous le nom de "Navigo Anonyme" car fonctionnant comme notre bonne vieille carte orange, en deux morceaux et sans vilaines données stockées à l'intérieur. Un anonymat qui n'est pas gratuit celui-là, il vous en coûtera 5€. Admettons...

lapsus linguae

Mais revenons plutôt à l'effacement tout relatif de nos données vieilles de plus de 48h. Récemment Actuchomage.org s'est ému de la "vente forcée" de passes Navigo aux demandeurs d'emploi franciliens et a envoyé, par courrier, une demande d'explication au STIF. Je passe sur la qualité contre-argumentaire irréprochable de la réponse du STIF, avec citations latines et tout. Prêtons plutôt oreille au contrepoint, je veux dire au "punctus contra punctum".

En pratique, les entreprises de transport procèdent, le plus rapidement possible après la validation (au maximum quelques heures, les délais dépendant du flux), à un codage réalisé sur le numéro de série. Le procédé de chiffrement rend impossible tout rapprochement avec un numéro de dossier commercial et donc avec l'identité du porteur. Cette anonymisation est irréversible et concerne aussi bien le passe Navigo personnalisé que le passe Navigo Découverte

Pour le coup, c'est l'informaticien qui est intrigué. Déjà il se dit que de nos jours il peut s'en passer des choses en "quelques heures maximum". Mais ce qui a réellement attiré mon attention, c'est que je croyais que le fameux numéro de série était effacé, et voilà maintenant qu'il serait chiffré ? Et qui plus est par un procédé irréversible ? Mon dieu mais je n'imaginais même pas qu'une telle technique existait sur terre. Pour moi chiffrement implique déchiffrement sinon je ne vois pas bien l'intérêt de la manoeuvre. Un cryptage avec un nombre aléatoire comme clef ? faut être un peu tordu tout de même...

Mais dans le cas d'un lapsus plutôt révélateur cela voudrait surtout dire qu'en réalité les données sont belle et bien conservées, et ce "Ad Vitam Eternam"... Elles resteront là, attendant sagement que la nécessité aidant, le fameux identifiant puisse révéler qui se cache derrière le cryptique numéro d'identification. Un jour qui n'arrivera jamais, admettons...

Conclusion

Comme souvent dans les nombreuses histoires de fichiers qui troublent notre citoyenne quiétude, ce n'est pas plus l'information stockée que l'encadrement de son usage qui devrait inquiéter. Quitte à en braquer quelques-un, je me moque royalement de savoir si mes orientations, même sexuelles, puissent être consignées quelque part si je peux 1/ Avoir accès à l'ensemble des informations qui me concernent, 2/ Pouvoir obtenir rectification de mes données, 3/ Avoir le contrôle sur qui a le droit ou pas de les consulter. Ou alors, dans le cadre d'une procédure légale, l'absolue et inaltérable assurance sur qui, et dans quelles circonstances précises, a le pouvoir de les consulter.

.htaccess vs configuration

Pour tout ce qui suit, ou presque, existe deux méthodes de paramétrages. La plus simple consiste à placer dans le dossier web à protéger un fichier .htaccess qui contiendra une configuration spécifique à ce dossier. Le contenu d'un tel dossier pourrait être :

Cette méthode a le mérite de la simplicité et protège autant le dossier lui-même que les sous-dossiers qu'il contient, sauf si un autre fichier .htaccess y contrevient.

L'autre méthode, sûrement plus pérenne, est de modifier directement un des fichiers de configuration Apache. Ces derniers se trouvent généralement en /etc/httpd et vous pouvez soit modifier /etc/httpd/httpd.conf, soit créer votre propre fichier .conf dans le dossier /etc/httpd/conf.d. A notez que les localisations peuvent changer d'une distribution à l'autre. Dans tous les cas la syntaxe est à peu près la même que pour un .htaccess:

La seule différence ici est donc la balise Directory qui encadre le code qui aurait été dans un fichier .htaccess et qui indique le chemin absolu à protéger, comme la position d'un .htacess l'aurait fait. Une autre différence cependant tient à la manière dont apache gère les deux types de fichier. En effet, un .htaccess est affectif tout de suite, dés que le fichier est créé et contient les données. En revanche un fichier de configuration nécessite le redémarrage du serveur Apache par un redémarrage du serveur apache.

Maintenant le choix .htaccess ou fichier de configuration vous appartient. Tout ce qui suit devrait fonctionner dans les deux cas.

Fichier de mots de passe

Si nous voulons qu'Apache protège notre dossier, il nous faut lui fournir une liste d'utilisateurs, voire de groupes d'utilisateurs. C'est ce que fait le code suivant en créant d'abord un répertoire et en changeant ses droits, puis en ajoutant avec la commande Apache htpasswd le premier utilisateur (le chemin du dossier et le nom du fichier n'ont aucune importance) :

Pour l'ajout des utilisateurs suivants, le fichier étant déjà créé, le paramètre -c n'est plus nécessaire :

Un utilisateur préalablement créé, pourra être retiré de la manière suivante :

Maintenant si nous vidons le contenu du fichier /var/secured/passwords, nous aurons ceci :

Nous avons donc maintenant les utilisateurs, leur mot de passe, il ne nous reste plus qu'à définir des groupes, même si c'est optionnel. Si nous voulons indiquer que l'utilisateur gaston appartient au groupe webmasters il suffit de créer un second fichier /var/secured/groups contenant les données suivantes :

La syntaxe est ici simple à comprendre. AuthName est le message qui sera affiché dans la boite de dialogue de saisie de l'identifiant et du mot de passe. Gardez cela en tête pour ne pas y mettre de chose trop explicites comme "Bienvenue dans le site contenant tous mes numéros de carte bleue" .

Le second paramètre, AuthType indique à Apache d'utiliser le protocole Basic pour authentifier l'utilisateur. Comme son nom le laisse présager, ce protocole est le plus simple, le plus compatibles avec tous les navigateurs, mais aussi le moins sécurisé comme nous le verrons un peu plus loin. D'autres type d'authentification existent sous Apache par l'intermédiaire de modules spécifiques, comme nous allons le voire aussi plus loin.

Ensuite nous avons AuthUserFile qui indique le chemin vers le fichier que nous avons créé dans le chapitre précédent, et contenant donc nos utilisateurs et leurs mots de passe.

Enfin, la règle d'authentification à proprement parler, require valid-user. Elle indique à Apache que tout utilisateur ayant réussi à rentrer son mot de passe est autorisé à rentrer dans le dossier. Si nous voulions spécifiquement autoriser Robert à rentrer, nous aurions mis require user robert, et pour Gaston et Martine, cela aurais été require user gaston martine.

Vu que nous avons créé un fichier de groupes d'utilisateur au chapitre précédent, autant en profiter. Et si voulions n'autoriser que le groupe webmaster à rentrer, nous aurions cette fois un fichier .htaccess comme ceci :

Plus complet, les deux chemins vers les deux fichiers mots de passe et groupes sont indiqués (apparition du mot clef AuthGroupFile).

Enfin il est possible de panacher tout cela avec des choses du genre : require user robert, group webmaster. Ceci indique à apache que seuls les membres du groupe webmaster sont autorisés, à l'exception de robert.

Utiliser un serveur LDAP

Comme je le disais plus haut, il y a de nombreux modules liés à l'authentification disponibles pour Apache sous la forme de modules. Par exemple si vous vouliez utiliser un protocole Digest au lien du simple Basic, vous utiliseriez le module mod_auth_digest.

De même différent modules permettent de vérifier les utilisateurs, groupes et mots de passe sur une base de donnée plutôt qu'un fichier texte, ou encore un serveur ldap par le biais du module mod_authnz_ldap. Il dépends du module Apache d'accès à LDAP, mod_ldap qu'il faut aussi installer. Ce module permet une authentification Basic adossée à un base LDAP. Un bloc de configuration pour un tel système se présente comme cela

Comme vous le voyez l'esprit est à peu prés le même que précédemment. La ligne AuthBasicProvider indique à apache de se baser sur un serveur LDAP plutôt qu'un fichier. Les coordonnées du serveur apparaissent avec la ligne AuthLDAPURL qui indique le nom de la machine, le port en écoute, ainsi que le domaine pris en charge.

Les deux attributs suivant permettent au module apache de se repérer dans les enregistrements LDAP et d'y trouver les utilisateurs. Le paramétrage que j'utilise ici se base sur la disposition standard d'une base LDAP sous Unix et est à adapter pour un ActiveDirectory sous Windows, par exemple.

Enfin la dernière ligne indique à apache de n'autoriser à rentrer que le group ldap spécifié (ici webmasters). L'utilisateur de ldap-user (ex. Require ldap-user Gaston) permettrait de n'autoriser qu'un utilisateur spécifique. Et ici aussi, le panachage est autorisé en séparant les éléments par des virgules.

A ce stade, nous avons déjà pas mal d'outils pour protéger nos données mais si nous nous arrêtions à cela, cela ne servirait à rien... En effet, ce type de sécurité est aussi valable qu'une porte blindée sur des murs en cartons. Car le gros inconvénient du mode basic est que les mots de passes circulent en clair. Protéger par mot de passe un dossier accessible avec le protocole HTTP est donc très dangereux. Une simple écoute active (mode Promisc) du réseau, si par exemple vous utilisez cela de votre bureau, dévoile aussi sûrement vos secrets que si vous les aviez envoyé à tout le monde par courriel. Pour parfaire notre protection il est donc obligatoire de mettre en œuvre le protocole HTTPS, ce que j'aborderais dans un autre article.

Empêcher le téléchargement des images à partir d'un autre site

Un problème classique est de se retrouver avec une bande passante "volée" parce qu'un Malotru a eu l'indélicatesse de mettre vos images en référence directe sur son site. Ici, pas question de mettre un mot de passe qui bloquerait les utilisateurs légitimes. Les techniques précédentes sont donc inutiles. A la place nous allons utiliser les variables dont nous disposons au sein d'Apache et particulièrement du Referer.

Pour ceux qui ne le savent pas, un navigateur WEB a pour obligation de transmettre au serveur l'adresse WEB de la page qui contient le lien qui a permis d'arriver sur notre site. Cette indiscrétion est déjà bien connu et c'est elle qui permet de savoir d'où viennent nos visiteurs. Cette adresse est le fameux Referer.

Ce qui est un peu moins connu c'est que chaque élément lié à une page de notre site (ex. une image ou une feuille de style), est demandée au serveur distant avec lui aussi un Referer. Sauf que cette fois, c'est l'adresse de notre propre site qui est passé par le navigateur, ce qui est somme toute très logique.

En d'autres termes, toute demande d'image n'ayant pas notre site pour Referer, est sûrement l'objet d'un vol de bande passante… C'est cette caractéristique que nous allons exploiter avec ce code qui peut aussi bien être, comme toujours, dans un .htaccess qu'un fichier de configuration Apache.

Ce qui se passe c'est que si le Referer est bien notre site, nous positionnons une variable acces_local à 1. Ensuite nous ajoutons une règle qui interdit le téléchargement des images (Deny from all) sauf pour les requêtes qui ont la variable acces_local définie. Voilà, c'est tout. La directive FilesMatch est elle là pour n'opérer cette sécurité que sur les fichiers images, feuilles de style, scripts, etc. Il serait en effet un peu idiot d'appliquer cette règles au fichier .php par exemple, cela interdirait systématique l'accès du site à tout le monde….

Empêcher certains navigateurs

Vous aurez remarqué dans l'exemple précédent la syntaxe un peu étrange du paramètre de la directive SetEnvIfNoCase. On appelle cela une expression régulière . Une expression régulière est une sorte de motif permettant de décrire une chaîne de caractère attendue. On peut ainsi créer des expressions régulières décrivant un numéro de téléphone ou une adresse courriel. Dans l'exemple précédent, elle signifiait "toute les URL qui commencent par (symbole ^) http://www.monsite.net/". Les \. étaient là pour indiquer que l'on voulait que le vrai caractère . soit utilisé, car sinon, ce symbole a un sens particulier dans une expression régulière.

Maintenant imaginons qu'un vilain spammeur qui me fasse des misères et que son adresse IP varie de 81.95.144.X à 81.95.147.X. Je peux le bloquer par la configuration suivante :

C'est à peu prés le même exemple que précédemment sauf que cette fois on utilise, non pas Referer mais Remote_Addr qui est l'adresse IP du navigateur client. Je ne vais pas faire ici un cours sur les expressions régulière, il y a de magnifique tutoriaux sur ce sujet.

Juste un dernier exemple, si cette fois c'est la chaîne d'identification ( User Agent ) d'un navigateur que je veux bloquer, par exemple un bot malveillant :

Là, j'utilise une directive un peu spéciale qui a le même rôle que les précédentes mais cette fois sur la variable User_Agent sans distinction de majuscules/minuscules.

Bien évidement, vous pouvez mettre une liste complète de définitions avant d'insérez votre directive Deny :

Cette méthode n'est pas aussi fiable que je le voudrais car les adresses change, et les chaînes d'identification de navigateur aussi. Mais au moins est-ce un moyen de contrer efficacement une attaque ponctuelle. Pour une liste complète des directives touchant à la définition de variables, je vous renvoie à la documentation d'Apache.

Protéger par adresse IP

Même si cela fonctionne, passer par les variables pour interdire une IP avec des expressions régulières est un peu sauvage pour un usage courrant. Si vous voulez pour votre dossier, ne soit accessible que pour une seule IP, ou un groupe d'IP, nous pouvons plus simplement utiliser la directive Deny From. Par exemple ici, pour n'autoriser que l'IP 192.168.0.10 nous utiliserons la configuration suivante :

Nous pouvons assouplir la règle en enlevant un group de chiffre à la fin de l'IP. Par exemple Allow from 192.168.0 autorise les adresses allant de 192.168.0.0 à 192.168.0.255, à se connecter.

Mixer les plaisirs

Pour finir, un petit mélange. Imaginons que nous protégions notre dossier par mot de passe via LDAP mais qu'en même temps nous ayons besoins que les clients se connectant d'un adresse IP spécifique, puise le faire sans mot de passe. Cela nous donnerais le code suivant :

Rien d'inconnu maintenant dans ces syntaxes, à l'exception de la dernière ligne, qui fait toute la différence. En effet, elle indique à Apache que l'une ou l'autre des conditions suffit à autoriser l'accès : soit l'IP, soit le mot de passe.

Conclusion

L'article est déjà long et nous sommes loin d'avoir totalement couvert le sujet. J'espère seulement que cela vous donnera assez de pistes pour trouver la solution qui convient le mieux à vos besoins. L'agressivité et l'automatisation des attaques comme en témoignent souvent les fichiers de traces, prouvent que ce genre de précaution est simplement obligatoire. Il n'y a à ma connaissance pas de moyens systématique de valider qu'un serveur est correctement fermé, et ce qui est réellement ouvert. Google permet par le biais d'une requête de type site:mon-site.com d'avoir la liste de ce qu'il voit mais cela se limite à ce qui a été lié, quelque part, sur le Web, ce qui est loin d'être suffisant.

Car croire que le seul fait de ne pas publier sur le web le lien vers un dossier le rend invisible est pure crédulité comme en témoigne cette ânerie là, , que j'avais trouvé par hasard, en bidouillant l'URL d'annulation d'un courriel de pub, sans l'aide google.

Un proxy ?

D'un point de vue général un proxy est un bout de logiciel qui va recevoir vos demandes réseau et les retransmettre, après un éventuel traitement, à qui de droit. Il existe de nombreux types de proxy mais en entreprise il s'agit très souvent d'un proxy type HTTP . Le principe est que chaque requête HTTP est envoyé par le navigateur au serveur Proxy qui va tout d'abord en examiner la légitimité et renvoyer une erreur si l'on cherche à atteindre une URL interdite. Ensuite le proxy va effectuer la vraie requête vers l'URL demandée et recevoir la page résultat. Généralement, et c'est le second rôle d'un tel proxy, cette page va être stockée en local sur le disque du serveur, avec tous les fichiers associés (feuilles de style, images, etc.). Le proxy va enfin renvoyer la page stockée en local au navigateur.

Ainsi un proxy permet à une entreprise de limiter l'utilisation d'Internet au seul WEB, de filtrer les accès pour ne pas autoriser les sites n'étant pas en rapport avec le travail (blog, sites de jeu et j'en passe), enfin réduire les besoins en bande passante stockant une copie des pages en local.

Maintenant, d'un point de vue "utilisateur" cette approche a l'inconvénient de ses avantages. On ne peut aller où l'on veut. On ne peut utiliser autre chose que le WEB (IRC, Messagerie instantanée, etc.), et surtout, l'ensemble des pages visitées, des mots de passe utilisés est tracé et stocké.

Accès sécurisé

Fort heureusement, il existe une parade à cette approche : l'accès au WEB sécurisé via HTTPS . En effet, il est rare que ce mode de connexion à la toile soit bloquée tant cela deviendrait contraignant pour l'utilisateur (aucun accès à une zone abonnée chez un éditeur, à une banque, etc.). Or le HTTPS est absolument impossible à filtrer par le proxy d'entreprise dans la mesure où toutes les données circulent d'un un tuyau crypté dont la clef de décodage n'est partagée qu'entre vous et votre serveur cible. Ceci dit il est toujours possible de créer un proxy qui vous fasse croire que vous êtes en communication sécurisée avec votre serveur mais je n'ai pas entendu parler d'une telle implémentation en standard.

Ainsi donc, dés que vous accédez à un site en HTTPS, le proxy devient aveugle, il ne stocke plus les pages en local, ne voit plus les mots de passe, mais il peut toujours voir les URL. De plus, tous les sites auquel nous voudrions accéder n'ont pas forcement un accès HTTPS de disponible. Pour exploiter cela nous avons plusieurs possibilités.

PhpProxy

Techniquement, une méthode qui permettrait de court-circuiter totalement un proxy serait de passer par un service type anonymizer. En effet, ce type de site est accessible en HTTPS et permet dans une zone de la page de rentrer l'URL "interdite". Ces sites fonctionnent comme notre proxy d'entreprise et vont chercher, eux-mêmes les données, pour les renvoyer sur leur propre page.

Si cette méthode marche pour vous, c'est parfait, d'autant plus qu'il existe de nombreux site du même genre, il suffit de demander cela à google. Cependant cette approche pose deux problèmes. Le premier est que les administrateurs de votre proxy d'entreprise ne sont pas idiots et ont sûrement la liste exhaustive des services publiques d’anonymisations indiquées comme URL interdites dans le proxy. Et si ce n'est pas le cas, l'autre soucis est que si ce n'est plus l'entreprise qui peut voir où vous aller, ce site dont vous ne savez rien, lui, le peux.

La solution ultime consiste donc à monter son propre service d'anonymisation. Pour cela deux pré requis : disposer d'un serveur WEB équipé de PHP accessible d'une IP publique et que ce serveur soit accessible en HTTPS. Le cas échéant, vous pouvez utiliser votre propre ligne Internet personnel en installant chez vous un serveur Apache/PHP et en utilisant un service du genre de celui que propose dynDNS. Pour ce qui suit, je pars du principe que vous avez la main sur un serveur unix avec apache, https (mod_ssl) et PHP correctement installés.

La marche à suivre est très simple. Tout d'abord télécharger phpProxy. Décompressez le dans le dossier de votre choix (ex. /documents/web/phpProxy). Ensuite, ajoutez à la configuration du vhost https quelque chose du genre : Alias /farfelu /documents/web/phpProxy SSLRequireSSL Options Indexes FollowSymLinks MultiViews IncludesNoExec AddOutputFilter Includes html AllowOverride All AuthType Basic AuthName "Accès à Farfelu" AuthUserFile /usr/local/apache/passwd/passwords Require valid user

Les points important ici sont que nous créons un alias /farfelu car il ne serait pas très malin que l'URL d'accès à votre proxy soit /mon_proxy . Ensuite le SSLRequireSSL qui oblige l'utilisateur de cette URL à passer par HTTPS. Enfin, trèèèèès important, ajoutez un identifiant/mot de passe sur cette URL si vous ne voulez pas que quelqu'un tombant dessus par hasard, puisse utiliser votre proxy à votre insu pour faire des choses répréhensibles. Si vous êtes un peu paumé avec ces options, vous pouvez faire un tour ici.

Une fois qu'apache a été redémarré, il ne reste plus qu'à tester notre URL https://mon_serveur_publique/farfelu. Si tout fonctionne correctement, vous devriez obtenir quelque chose conforme à l'illustration.

Après l'utilisation est relativement intuitive, plusieurs options permettent de modifier le comportement du proxy comme la possibilité de supprimer les JavaScript, gérer les coockies, etc.

Utilisez la commande CONNECT

HTTPS implique une connexion directe entre vous et le serveur cible. Pour que cela puisse fonctionner, existe une commande CONNECT dans la norme du protocole HTTP. Cette commande indique au proxy que l'on désire établir une connexion directe avec la cible, en se passant de ces services. Autant dire qu'il s'agit là d'un magnifique trou dans lequel il est possible de s'engouffrer.

Dans la norme HTTP, rien n'interdit de donner le port de son choix à la commande CONNECT. De fait il devrait donc être possible de se connecter, via cette "faille", à un serveur distant SSH, écoutant classiquement le port 22. Cependant ce n'est pas aussi simple. Pour limiter la casse, les proxy interdisent généralement une commande CONNECT qui chercherait à atteindre un port autre que le 443, qui est le port "officiel" d'HTTPS. La conséquence pour vous, est que pour exploiter cette "faille", il faut obligatoirement que votre serveur SSH soit en écoute du port 443, rendant du coup l'utilisation de cette astuce incompatible avec l'utilisation conjointe d'un Apache en HTTPS. Si vous n'avez pas ce problème, nous pouvons poursuivre.

Mettre un ssh en écoute sur le port 443 ne pose aucun problème en soit. Il suffit pour cela de modifier le fichier de configuration /etc/sshd_config et d'y placer ou modifier le paramètre Port 443. Après redémarrage, un netstat -anlo | grep 443 nous confirme bien que SSH est en écoute sur le port HTTPS.

Vous pouvez aussi doubler les ports en écoute par le serveur SSH en utilisation xinetd. Après l'avoir installé, il faut désactiver le service sshd (par un chkconfig -del sshd) . Ensuite vous allez modifier /etc/xinetd.d/sshd-xinetd de sorte à avoir un disabled=no. L'étape suivant consiste à simplement dupliquer ce fichier dans le même répertoire sous le nom sshd-xinetd-https et l'éditez pour changer la ligne service ssh en service ssh-https. Enfin, indiquez le port de connexion de ce nouveau service en éditant le fichier /etc/services et ajoutant à la fin ssh-https 443/tcp. Un petit redémarrage de xinetd cette fois et ssh devrait être accessible des deux ports 22 et 443.

Maintenant, pour se connecter à travers un proxy HTTP, sur un serveur Serveur SSH, nous avons besoin d'un client capable de causer avec le proxy et donc de générer cette fameuse commande CONNECT. Pour Windows, rien de plus simple, il suffit pour cela d'utiliser PuTTY. On prendra alors soin, dans le paramétrage de la connection, à la section proxy, de bien sélectionner HTTP, ainsi qu'indiquer l'adresse et le port du dit proxy.

Ensuite, dans les coordonnées du serveur cible, il faut bien sur renseigner le nom ou l'IP du serveur cible, et surtout changer le port pour utiliser le 443. Sauvegardez la connexion et cliquer ensuite sur Open. Si le proxy est suffisamment ouvert, il devrait vous laisser passer et vous aurez un login.

Pour faire la même chose d'un client Linux, il suffit d'installer le paquet corkscrew. Ensuite la commande est très simple :

Là aussi, si tout va bien, vous devriez pouvoir vous connecter. A partir de là vous pouvez faire à peu prés ce que vous voulez, y compris mettre en œuvre un proxy SOCKS.

Tunnel HTTP

Autre option, utiliser cette fois le vrai protocole HTTP, sans truquage. La magie est à mettre ici au compte de HttpTunnel. Sur le site vous trouverez les binaires pour Windows, et pour Linux, tout est généralement dans votre distribution à partir d'un urpmi ou apt-get httptunnel.

HttpTunnel se compose de deux parties. Un serveur et un client. Le client va se mettre en écoute d'un port local et rediriger toute demande vers le serveur, en prenant soin de tout encapsuler dans du HTTP classique. De l'autre côté, le serveur HttpTunnel va recevoir les demandes, décapsuler les données contenues dans les trames HTTP, et rediriger le tout vers le port de votre choix.

Par l'exemple, imaginons que sur la machine SERVEUR, nous ayons un service SSH qui tourne en écoute du port 22 (classique). Nous allons donc lancer notre serveur HttpTunnel :

Le serveur HttpTunnel est donc en écoute du port 80 (HTTP) et décapsulera tout ce qu'il recevra vers le serveur SSH en écoute du port 22. Maintenant du côté client :

Le client va ainsi utiliser le proxy HTTP de manière standard, pour contacter le serveur HttpTunnel qui se trouve à l'adresse IP indiqué et au port 80. J'utilise l'adresse IP car le nom de la machine semble ne pas toujours fonctionner chez moi.

Maintenant que notre tunnel est en place, reste à l'utiliser et à lancer un

Et là magie, avec un temps de réaction qui m'a clairement surpris, tout fonctionne. Ici aussi, disposant d'un SSH classique, il est possible de mettre en œuvre ensuite un mini proxy SOCKS.

Maintenant cette méthode a beau très fonctionnelle, elle présente de nombreux inconvénient. Tout d’abord elle squatte le port 80, ou au mieux le 8080 si votre Proxy l’autorise. Il semblerait qu’il n’y ait aucun moyen de changer cela, y compris en utilisant une combinaison Apache/VHOST/ReverseProxy.

Enfin, il n’y a aucune authentification. C’est un système ouvert aux quatre vents. Et ça c’est déjà plus sérieux.

AjaxTerm

Pour finir, personnellement ma méthode préférée, en conjonction avec phpProxy. Car si ce dernier me permet d'aller où je veux, AjaxTerm va me permettre de faire ce que je veux. Et le tout, comme PhpProxy, sans configuration compliquée et avec un simple navigateur WEB.

Cet outil est tout simplement un terminal totalement fonctionnel, colorisé, réactif qui fait presque oublier que l'on est en réalité dans un navigateur. Toutes les applications type nCurse fonctionnent, toutes les commandes sont disponibles, il n'y a tout marche comme à la maison, y compris la tabulation pour compléter les commandes. Que demander de mieux ?

Côté installation, AjaxTerm est un serveur écrit en pyton disponibles dans vos dépôts sans aucun doute via un urpmi/apt-get ajaxterm. Ensuite il n'y a plus qu'à lancer le service du même nom : /etc/init.d/ajaxterm start. Par défaut le serveur se met en écoute du port localhost:8022. Il n'est donc pas disponible directement à partir du réseau public, et c'est tant mieux. Car nous allons du coup pouvoir utiliser un reverse proxy apache pour le coller dans notre conteneur HTTPS, avec le cryptage et l'authentification qui va bien. Le tout au côté de nos autres applications WEB, sans conflit.

Une fois le serveur lancé, vous pouvez vérifier son fonctionnement avec un navigateur WEB en allant sur http://localhost:8022. Une fois que vous avez constaté son bon fonctionnement, il faut rajouter dans la configuration d'apache, de préférence dans le vhost en charge du port 443/HTTPS, les lignes suivantes. Pour les détails sur les paramètres d'authentification, se reporter à ce billet .

Maintenant pour que cela fonctionne, assurez vous que vous avez installé le module apache apache-mod_proxy. Après un petit redémarrage d'apache et l'on peut se connecter du monde extérieur, de manière sécurisée et authentifié, à l'adresse http://mon_server/mon_machin/. Remplacez mon_machin dans la configuration par quelque chose de plausible mais n'attirant pas l'attention. Evitez les choses du genre /je_vous_ai_bien_eu/, ça ne va pas le faire bien longtemps

Ne laissez pas non plus la console activée en permanence car étant de l'ajax, je soupçonne qu'il fasse sur le serveur des requêtes récurrentes qui pourraient attirer l'attention.

Conclusion

Voilà, c'est la fin de la seconde édition de ce tutoriel, avec mes remerciements aux gens en dessous (Dab & co ) qui m'ont donné suffisamment d'idée pour ne pas en rester à un simple proxy en php

openID, quoi qu'est-ce ?

Sans trop revenir sur les plus ou moins fumeux mythes de WEB 2.0, il est au moins clair que si la toile de l'après Wikipedia n’a rien de technologique, elle a intégré trois évolutions d'usages majeures :

• Le crowdsourcing qui délègue aux internautes le soin de fournir (gracieusement... ) des contenus.
• Les réseaux sociaux qui relient les internautes entre eux à travers de simples commentaires ou par des outils évolués de mise en relation (facebook, viadeo, etc.)
• Et enfin l' identité numérique , qui fait passer l'internaute du statut de simple visiteur à celui d'utilisateur, avec son profil, ses préférence, son pseudo, etc.

Or d'identité numérique nous sommes vite passé à la schizophrénie numérique tant sont multiples les comptes, les points d'intervention, les mots de passe à mémoriser, etc.

OpenID est donc l’une des réponses à cette schizophrénie et en tout cas la seule qui soit libre. Pour rapidement comprendre en quoi cela consiste, prenons un exemple classique, la saisie d'un commentaire sur un billet :

• Comme chaque matin, je vais faire un tour sur auBlogDuCoin.fr, et j'y découvre un très intéressant article.
• Je veux intervenir dans la conversation et donc saisir un commentaire.
• C'est cool le site utilise l'openID, je n'ai donc plus besoin de donner mon pseudo, l’adresse de mon site web et mon email, mais juste mon openID qui est une adresse WEB unique du genre http://ulhume.fr/monopenID.
• Je poursuis en rédigeant un commentaire éclairé et je valide.
• Sans rien me dire et de manière invisible, le site va aller faire un tour sur http://ulhume.fr/monopenID pour récupérer cette fois l'adresse de mon VRAI serveur openID. Cette adresse peut être quelque chose comme http://serveuropenID.fr/ulhume.
• Le site va alors me rediriger sur http://serveuropenID.fr/ulhume pour authentification.
• A partir de maintenant, ce n’est pas www.auBlogDuCoin.fr mais bien http://serveuropenID.fr/ulhume qui me demande mon login et mot de passe.
• Si le login et le mot de passe sont bon, http://serveuropenID.fr/ulhume me redirige sur auBlogDuCoin.fr qui va ainsi recevoir, de manière totalement invisible pour moi, les informations me concernant : psoeudo, site web, adresse eMail, avatar, etc.
• auBlogDuCoin.fr a maintenant toutes les informations nécessaires et peut donc enfin valider mon commentaire.

La question que l'on peut se poser c'est : pourquoi aller d'abord sur un première adresse pour ensuite aller sur le "vrai" serveur openID ? Pourquoi ne pas y aller directement ?. La réponse est assez simple. La première adresse, http://ulhume.fr/monopenID m'appartient. C'est généralement votre site web ou votre blog. En revanche le serveur openID, http://serveuropenID.fr/ulhume, ne m'appartient pas forcement. Du coup si je donne la seconde adresse comme étant mon adresse openID, je suis pieds et poings liés avec un fournisseur. Si je veux en changer je vais perdre mon openID. En terme technique, on dit que la première page délègue l'authentification à la seconde adresse.

De tout ceci nous pouvons retirer plusieurs choses sur l'openID :

• Jamais le site que je visite ne voit mon mot de passe. Il n'a qu'un identifiant unique, mon adresse openID.
• Mon adresse openID peut ne pas être la même que l'adresse du serveur openID. Il est ainsi possible de changer de fournisseur, sans pour autant changer d'identifiant.
• Je peux fournir au serveur openID que j'utilise des informations plus où moins complètes selon mes besoins. Certains serveurs permettent même de fournir des informations différentes en fonction du site qui y fait appel.
• Si je change mes informations, cela change celles de toutes mes interventions sur WEB. Par exemple si je change mon Avatar, ou mon pseudo, cela va être répercuté partout où l'openID a été utilisé. C'est en tout cas théoriquement le cas, car beaucoup de sites "copient" en local ces informations.

C'est bon je crois pour la théorie. Maintenant mettons cela en musique et commençons par nous créer un compte sur un serveur openID.

Création d'un compte

Le serveur openID est un logiciel sur lequel vous devez avoir un compte au sein duquel vous allez stocker vos informations personnelles (pseudo, avatar, etc.). C'est ce serveur qui va réaliser l'authentification réelle sur tous les sites WEB où vous utiliserez votre adresse openID.

A ce stade, vous avez deux options possibles : soit vous décidez d'utiliser un service publique, soit vous préférez fabriquer vous-même votre propre serveur openID.

Fabriquer son propre serveur openID

Choisir entre serveur publique et serveur perso revient à mettre en balance la toute relative difficulté de l'opération avec l'importance que vous accordez à votre vie privée. En effet, toute enthousiasmante soit cette technologie, cela ne doit pas vous faire perdre de vue que votre serveur openID est par définition au courant de toute votre vie sur le WEB. Comme le soulignait, à juste titre Tuxicoman (un peu plus bas dans les commentaires), mettez un serveur openID dans les main d'un Google, et je rajoute, avec le succès d'un Google Analytics, et vos balades sur le net vont vite devenir de la pâtée à fabriquer de l'AddSens...

Pour qui dispose d'un simple hébergement PHP, il existe plusieurs serveurs openID mais le plus simple est définitivement phpMyID. Constitué de seulement deux fichiers il a pour seuls inconvénients que de devoir être paramétré à la mano et d'être mono utilisateur. Si vous cherchez un serveur plus complet (et complexe), orientez vous plutôt pour PHP Standalone openID Server qui a juste l'inconvénient (pour moi) de fonctionner seulement avec MySql. Je vais pour l'instant donc me concentrer sur l'installation de phpMyID.

Pour l'installer vous pouvez soit télécharger et décompresser la dernière archive dans votre dossier web ou alors, ma solution préférée, utiliser subversion :

L'avantage de la solution subversion est que la mise à jour est simple comme un :

Dans un cas comme dans l'autre, vous devez avoir maintenant un dossier /var/www/phpMyID. Nous allons donc maintenant paramétrer le serveur en commençant par générer une clef d’identification qui va servir pour l'authentification. Imaginons que votre pseudo soit roberto et que le mot de passe soit secret. Pour fabriquer la clef d’identification il vous suffit alors de taper la commande :

Si vous n'avez pas accès à un shell, le code php suivant (à détruire après usage !!) fera l'affaire :

Une fois la clef en main, nous devons la coller, avec notre pseudo, dans le fichier MyID.config.php :

Maintenant il ne nous reste maintenant plus qu'à modifier la configuration d'apache (si c'est nécessaire) :

Et c'est fini !! Votre serveur openID est prêt à être publié grâce à ces coordonnées :

Serveurs openID publiques

Si pour des raisons d'hébergement ou de temps (ou simplement pour tester), vous préférez l'option serveur publique, il existe aujourd'hui de nombreux services gratuits et relativement fiable qui permettent l'authentification openID. La section Well Known & Simple Providers du site openID.net vous en fournit une liste.

Il est aussi possible de passer par openID France qui est une association 1901.

La création d’un compte y est aussi simple que classique. Une fois que vous l’avez activé, vous n'avez plus qu'à vous connecter pour paramétrer votre profil. Sur la page d'accueil vous sont fournis deux informations. Une adresse openID fonctionnelle :

Et un bout de code HTML pour que vous puissiez créer votre propre adresse openID :

Une fois de plus, je radote pour la bonne cause, il ne faut pas utiliser l'adresse openID fournit par ce site, car sinon, vous seriez définitivement liés à celui-ci. Il faut que vous utilisiez le code HTML comme nous allons le voir un peu plus loin pour créer votre propre adresse openID.

Votre adresse openID

Que vous ayez créé un compte sur un serveur publique, ou que vous ayez monté votre propre serveur, vous avez maintenant deux lignes de code HTML qui vont vous permettre de créer votre adresse openID.

Là, vous avez le choix. Si vous avez un site web ou un blog, il suffit de coller ces deux lignes dans la balise <HEAD> de la page d’accueil et l'adresse WEB de votre site ou blog est maintenant, votre adresse openID. Vous pouvez créer aussi une page spécifique comme http://monSite.com/roberto/index.html et y mettre le code suivant :

Il ne vous reste maintenant plus qu'à tester votre nouvelle adresse openID. Pour se faire vous pouvez aller sur cette application de test ou alors pour traquer les problèmes, utiliser cette page de validation très complète (et plus complexe...).

Conclusion

OpenID a un réel avenir et présente une véritable solution à l'épineux problèmes des identités numériques multiples. Reste maintenant à ce que de plus en plus de site utilise cet identifiant unique.

Syntaxe

etat

start|stop

Scripte

Deux mots sur PAM

L'authentification sous Linux est aujourd'hui quasi-universellement confiée à PAM pour Plugin Authentification Module. PAM est utilisé à chaque fois que vous vous connectez sur votre système. Son fonctionnement consiste à confier à une série de modules enfichables, des plugins, le soin de déterminer si votre accès est autorisé ou pas. Les plugins sont appelés les uns après les autres et chacun dit oui ou non. Le paramétrage de PAM permet alors de savoir si un OUI est nécessaire ou s'il suffisant pour vous accepter.

En standard, PAM utilise surtout un seule plugin, pam_unix, qui va vérifier votre mot de passe dans /etc/shadow. Mais il est possible d'ajouter toute sorte de plugins pour enrichir la politique d'authentification. Par exemple pam_ldap pour s'authentifier sur un serveur LDAP. Et dans notre cas pam_usb pour le faire via une simple clef USB.

Les modules PAM sont situés en /lib/security et leur configuration en /etc/pam.d. Dans le cas d'une Mandriva, ce dossier contient un fichier par application utilisant PAM (imap, sshd, etc..) qui contient généralement des directives include permettant d'avoir un comportement commun par défaut, via le fichier system-auth. Les lignes qui nous intéressent ici sont celles qui régissent l'authentification et qui commencent par le mot clef auth:

Dans ce fragment, on s'aperçoit que l'authentification va d'abord se faire via le système classique d'UNIX (fichier /etc/shadow), puis, le cas échéant, via LDAP. Si aucun des deux n'as fonctionné, c'est pam_deny qui prends le relais et vous envois balader.

Le mot clef sufficient indique que si le module a correctement authentifié l'utilisateur, les modules suivants ne sont pas interrogés. Le mot clef required indique quant à lui que l'on doit passer par lui obligatoirement. Ainsi dans l'exemple précédent si nous avions remplacé (ne le faite pas !) les sufficient par des required, il faudrait pour qu'un utilisateur qui s'autentifie, soit présent dans /etc/shadow ET sur LDAP.

Préparation de la clef USB

Première étape, préparer le clef usb. Soit vous utilisez une veille clef et vous la dédiez totalement, soit vous pouvez créer sur votre clef de travail une minuscule partition dédiée au stockage des clefs. Dans un cas comme dans l'autre la partition ne peut être formatté qu'en EXT3 ou REISER. Pas de FAT32 donc. C'est pour cela que sur ma clef de 1GO, j'ai formatté une première partition de 1GO-7Mo en FAT32 pour une utilisation classique, et une petite partition de 7Mo (j'ai pas réussi à faire moins) en EXT3 pour mes clefs. A 2ko la clef, cela en fait 3500, ce qui me semble suffisant

Pour créer et formatter la ou les partitions, je vous conseille d'utiliser drakdisk. Il vous faut donc supprimer les partitions existantes, en créez deux nouvelles en ne laissant que 1mo à la seconde. Puis enfin formatter la deuxième partition en EXT3 ou Reiser. La première partitions peut quant à elle être formattée selon vos goûts.

La clef formattée, nous allons donner un label à la seconde partition. Ce label va nous permettre de localiser la clef plus facilement par la suite et aussi, pour les unix modernes, va être utilisé lors d'une insertion comme nom pour le point de montage automatique. Pour changer le label d'une partition, allez voir par là. Tapez sync puis débranchez et rebranchez la clef pour être sur que tout va bien.

Pour la suite de ce tutorial, je part du principe que la partition a pour label usb-pass. Qu'elle est donc accessible via /dev/disk/by-label/usb-pass et qu'elle dispose d'un UUID proprement définit.

Installation de pam usb

La solution adoptée par pam_usb est d'écrire une série de nombre aléatoire sur notre partition de 1Mo. A la connexion, cette série de chiffre (nommée pad) est comparée à celle qui a été copie dans le dossier utilisateur. Si ça colle, l'utilisateur est validé et pam_usb générée une nouvelle série de chiffres qui stock à nouveau sur la clef et dans le dossier utilisateur. Et ainsi de suite. Cette méthode garantie que toute donnée copies deviendra vite caduque à un détail près. En effet, si je débranche ma clef, que quelqu'un la copie, et se reconnecte avant moi, je suis grillé... La solution a donc ses limites qu'il est important de connaître.

La version 0.4.1 incluse dans la Mandriva 2008.0 était un peu buggée, il est plus sage de compiler soit même la dernière version du module. Il faut pour cela aller sur le site de pam_usb pour télécharger le dernier tarball (pam_usb-0.4.2.tar.gz) et le compiler :

Ceci fait, branchez votre clef USB, et lancez la commande suivante. Il va vous être demandé de choisir parmi les partitions de clef usb présente sur le système celle qui contiendra les données d'authentification. Choisissez la petite partition pass-usb. Tapez enfin Y pour sauver ces informations dans le fichier de configuration /etc/pamusb.conf.

Ensuite nous allons ajouter un utilisateur authentifiable sur la clef. Pour cela utilisez la commande suivante en indiquant en paramètre l'utilisateur à rajouter.

Voilà, c'est terminé. Il suffit maintenant d'ajouter dans /etc/pam.d/system-auth la ligne indiquant à PAM que la clef USB est le premier moyen suffisant pour s'authentifier sur ce système :

Il ne reste maintenant plus qu'à tester. Une fois que tout est bon, vous pouvez rendre pam_usb moins bavard en modifiant /etc/pamusb.conf comme suite :

Qu'est-ce qu'un proxy ?

Pour faire simple, un proxy est une application qui va jouer le rôle d'intermédiaire entre un logiciel client (ici votre navigateur WEB) et un serveur (ici, le site WEB visité). Il existe toute sorte de proxy différents permettant de partager une connexion internet ou encore de cacher son identité. Privoxy, lui, est un proxy "filtrant". Son rôle est "simplement" de regarder tous les sites que vous visitez avant vous pour y traquer les publicités et autre spywebs. Pour cela, il dispose de deux stratégies. Soit il va interdire comme AdBlock l'accès à certains sites au navigateur, soit il va modifier, "à la volée" les pages que vous recevez (par exemple pour y modifier des scripts dangereux).

Privoxy est aussi capable de "désanimer" des images GIF, de nettoyer vos cookies pour qu'ils ne laissent pas passer d'information, de maquiller l'identité de votre navigateur. Bref, c'est un outil complet, simple d'utilisation, rapide à installer, prêt à l'emploi et complètement paramétrable pour filtrer encore plus loin.

Installation

L'objectif de ce tutoriel est de mettre en place Privoxy pour tout votre réseau. Il va donc falloir choisir une machine qui sera connue des autres sur laquelle sera installé l'application. Il n'est pas nécessaire que ce soit une machine dédiée. Privoxy prend peu de ressource mémoire et CPU, n'importe quelle machine sous n'importe quel système devrait convenir. Pour la suite j'appellerais cette machine machine_de_gaston. Cependant, vous pouvez aussi utiliser ce proxy sur une machine seule. Auquel cas, vous remplacerez simplement dans ce qui va suivre machine_gaston par localhost.

Quel que soit votre système, toutes les versions binaires pour tous les Systèmes sont téléchargeables ici. L'installation se fait, comme dit plus haut, sur la machine machine_de_gaston.

Installation sous Linux

Il y a fort à parier que Privoxy est déjà intégré dans votre distribution. Sous Mandriva, l'installation se fait par la plus que classique commande :

Une fois qu'URPMI a terminé son travail, il vous suffit de lancer le service :

Installation sous Windows

Pour les Windowsiens, téléchargez le fichier .exe d'installation et exécutez-le. Validez toutes les demandes qui vous sont faites et à la fin de l'assistant, privoxy devrait être installé, lancé et en plus vous avez droit une belle petite console vous indiquant que le proxy est actif. Il ne reste plus qu'à configurer votre navigateur.

Paramétrage du navigateur

L'avantage d'un proxy est qu'il n'existe pas à ma connaissance de navigateur qui ne sache pas l'utiliser. Pour l'exemple nous allons faire ici le paramétrage de FireFox, mais il pourrait tout aussi bien s'agir de Safari, Opéra et même Internet Explorer...

Il faut donc maintenant aller sur la machine cliente pour indiquer à son navigateur d'aller chercher ses pages web sur la machine_de_gaston. Dans FireFox allez dans les menus Edition/Préférence/Réseau/Paramétres. Sélectionnez configuration manuelle du proxy et entrez pour HTTP les valeurs machine_de_gaston et 8118. Cliquer ensuite sur OK et enfin Fermer.

C'est tout ! Pour vérifier que tout fonctionne, saisissez l'adresse http://config.privoxy.org/ et validez. Vous devez voir apparaître la page de configuration de privoxy. Tout est donc opérationnel.

Privoxy à l'oeuvre

Pour se convaincre que tout est en place, il suffit d'aller sur la "machine de gaston" et de regarder les traces. Pour les Windowsiens cela se fait dans la console que vous avez découverte à l'installation, pour les Linuxiens, les logs se trouvent en /var/log/privoxy/logfile.

Sur le poste client, allez faire un tout avec votre navigateur sur le site www.liberation.fr et regardez ce qu'affiche privoxy sur la machine de gaston :

A chaque fois que privoxy affiche crunch, il a bloquer le navigateur. Nous voyons ainsi qu'en standard, privoxy bloque efficacement les publicités, Google Analytics et Xiti. Cela fait déjà beaucoup de nuisance en moins. Mais nous allons pouvoir aller un peu plus loin.

Améliorer le filtrage

Les fichiers à modifier

Comme vous l'avez vu, Privoxy par défaut marche déjà très bien. Il est cependant possible de pousser encore et de l'adapter parfaitement à vos besoins. Pour changer les paramètres de Privoxy, vous avez deux solutions. Soit vous utilisez l'interface WEB (personnellement je ne la trouve pas très simple), Soit vous éditez directement les fichiers de configuration. Pour les Windowsiens, il suffit d'aller dans la console de Privoxy dans les menus Options/Edit User Actions. Pour les autres, il faut simplement éditer le fichier /etc/privoxy/user.actions. Notez que le simple fait de sauver le fichier reconfigure Privoxy. Pas besoin de donc de redémarrer.

Le fichier user.actions contient les règles que vous avez le "droit" de changer. Vous pouvez changer aussi les autres mais cela risque de vous créer plus de problèmes qu'autre chose. Par défaut il contient déjà plein d'exemple utiles.

Vous allez pouvoir ajouter ici, des règles et des Aliases. Une règle est la combinaison d'une ou plusieurs Actions à une ou plusieurs URL auxquelles ces actions s'appliquent. Pour la liste complète des actions que Privoxy propose, allez jeter un oeil ici.

Ajout de nouvelles règles

Prenons un exemple et imagions que nous voulions supprimer l'envoi de tous les cookies pour le site wwww.mauvais-site.fr. Ce besoin traduit donnerait :

Cette règle très simple va ajouter l'action "crunch-outgoing-cookies" (qui supprime les envois de cookies) à toutes les urls appartenant à .mauvais-site.fr. Le signe + indique que la directive doit être ajoutée. En effet, les règles s'additionnent. Par exemple si plus loin de le fichier user.action j'écris :

Toutes les pages du domaine mauvais-site.fr auront leur cookie mangé sauf bonne-page.mauvais-site.fr.

Vous pouvez des * dans les URL, par exemple ad*.site-de-pube.fr, ou même une expression régulière comme pour adBlock comme www[1-9a-ez].example.c*.

Vous pouvez aussi mettre plusieurs actions entre les accolades, soit sur une seule ligne en les séparant par des espaces, soit sur plusieurs lignes en ajoutant un \ à la fin de chaque ligne. Cela nous donne par exemple :

Ajout d'Alias

Comme nous l'avons vu, il est possible de mettre plusieurs actions entre accolade. Il peut être alors pratique de pouvoir regrouper un ensemble d'actions sous un seul alias. Par exemple, si nous voulons regrouper la suppression de tous les cookies, nous ajouterions dans le fichier user.actions :

Une règle pour ajouter, une autre pour enlever, je pense que l'exemple parle de lui-même. Ainsi la règle du chapitre précédent pourrait s'écrire :

Ajout de règles supplémentaires

Avec ces informations, il est possible donc d'améliorer encore privoxy pour ne plus rien laisser passer ou presque. Au début, comme moi, vous allez observer ce que les sites font exactement avec votre ligne en regardant les logs de Privoxy. C'est très instructif. Et à chaque fois que vous voyez quelque chose de louche, vous pouvez ajouter une règle comportant l'action { +block } suivi à la ligne suivante de chaque url posant problèmes. Voici ma liste que vous pouvez adapter à vos besoins :