Analyse

3 août 2008

Neutre comme la Suisse

La neutralité des réseaux n'est pas un vain mot pour les défenseurs d'un Internet sans frontière ni péage. Chacun devrait d'ailleurs prendre conscience que cette neutralité est fragile, et que des lobbies d'opérateurs internet sont bien décidés à y mettre un terme. En mots de tous les jours, cela signifierait que si vous êtes abonnés à Internet chez le fournisseur X, vous pourriez bien avoir des problèmes pour accéder à Youtube, ou à des contenus hébergés par l'entreprise Y. Pire, vous pourriez vous voir interdir ou facturer l'usage de certains protocoles. En tant qu'entreprise, vous devriez payer plus cher pour que les abonnés de tel ou tel fournisseur d'accès puissent accéder à vos serveurs.

L'entreprise Proxad (Online, Free, Dedibox, ...) a déjà recours à ces procédés. Par exemple, une connexion vers un serveur Dedibox sera très lente si vous êtes aux États Unis, alors qu'elle sera rapide si vous êtes en France. Un téléchargement de fichier hébergé sur dl.free.fr sera très rapide si vous êtes sur une connexion ADSL Free, mais d'une lenteur dissuasive chez n'importe quel autre opérateur.
Dans un domaine similaire, on a constaté que le fournisseur d'accès américain Comcast a tenté de bloquer l'utilisation de Bittorrent par des procédés douteux.

Face à ces menaces, l'Electronic Frontier Foundation a commencé à travailler sur un logiciel client-serveur qui sera capable de déterminer si le traffic réseau émis par une machine a été modifié entre la source et la destination. Ce logiciel, Switzerland, est en version 0, donc encore largement inutilisable par le grand public. Néanmoins, son fonctionnement est prometteur, et j'ai déjà pu effectuer quelques tests avec l'aide d'autres utilisateurs.

Le principe de fonctionnement de Switzerland est le suivant :

Un serveur Switzerland tourne quelque part sur internet
Les utilisateurs (vous, moi, des serveurs web/mail/... sur internet) lancent le client Switzerland sur leur machine et se connectent au serveur Switzerland
Les utilisateurs se connectent les uns aux autres et échangent des données (vous relevez vos mails, nous partageons une ISO de FreeBSD via Bittorrent, ...)
Votre client Switzerland calcule un checksum des paquets que vous envoyez vers moi, ou vers un service en ligne qui utilise le client Switzerland
Chaque checksum est envoyé au serveur central Switzerland
Le client Switzerland du destinataire des paquets calcule à son tour le checksum du paquet, et les envoie au serveur Switzerland
Le serveur Switzerland compare les checksums des paquets, pour détecter les modifications

Dans le cas où une modification est détectée, le serveur Switzerland demande alors aux clients impliqués dans la connexion de lui envoyer les paquets complets, et non plus les checksums. Ainsi, il peut se livrer à une analyse détaillée de ce qui a été modifié. Donc tant qu'il n'y a pas de problème, vos échanges restent absolument privés. Mais dès l'instant où un opérateur modifie des informations dans vos échanges, certaines données seront transmises au serveur Switzerland.

switzerland diagram copyright EFF - under creative commons licence

Switzerland est encore loin d'être utilisable. C'est un logiciel en plein développement. Néanmoins, si vous souhaitez le tester voici quelques remarques :

Lisez bien tout ce qu'on vous dit sur http://www.eff.org/testyourisp/switzerland
Vous devez avoir une installation de Python pas trop ancienne
Vous devez avoir une horloge parfaitement synchronisée
Si vous utilisez open-ntpd comme moi, veillez à ce que ntpdc soit hors d'atteinte (renommez le)
Si comme moi vous n'utilisez pas ntpd (soit rien, soit autre chose), utiliser l'option -u 0
Actuellement, le serveur de test officiel est cassé, vous pourrez trouver d'autres adresses de serveur sur le wiki officiel
Vous devrez probablement désactiver votre firewall pour les tests, les NAT peuvent aussi poser quelques soucis
Sous Linux, si le client meure en disant "...Check for Large Segment Offloading on gigabit Ethernet cards...", essayez de régler le problème avec la commande `ethtool -K eth1 tso off` (à adapter en fonction de votre configuration)
C'est un logiciel connecté qui tourne en root, donc la prudence habituelle est de rigueur

6 février 2007

Spam un jour, spam toujours

Maintenant que ce blog est équipé d'un système anti-spambot façon Vauban, j'ai tout le loisir de voir ces pollueurs s'écraser contre mes murs. Il n'y a même plus de spam résiduel à modérer, un régal.
En pâture pour les chiens, voici les adresses IP des vilains pris dans mes lignes de défense depuis le 1er février :

121.134.43.80		208.101.5.141		64.72.127.155	
125.18.15.102		209.67.219.74		66.7.192.34
125.189.49.45		210.64.156.40		66.79.164.130	
163.28.33.226		210.87.251.107		67.128.2.9	
165.228.130.12		212.138.64.171		67.172.170.196
165.228.133.11		212.138.64.176		67.185.5.14
193.69.180.120		212.150.97.114		68.178.206.47
193.85.227.42		213.115.205.82		68.85.25.214
200.179.190.126		213.173.239.33		69.57.190.138
200.201.183.18		217.158.155.13		69.61.55.202
200.209.172.246		218.41.52.250		72.29.95.61
200.88.125.9		218.72.250.54		74.118.183.154
200.88.223.98		220.226.63.254		74.134.113.31
201.17.253.65		24.226.153.18		74.52.44.34
201.39.75.130		4.78.211.221		80.227.0.156
201.6.84.126		59.144.155.17		81.211.102.38
201.80.4.156		59.94.244.169		82.179.244.68
203.121.69.154		59.95.5.57		82.234.90.177
203.144.160.250		61.205.234.121		83.206.200.105
205.234.106.105		61.240.111.196		84.54.132.26
207.36.196.10		61.6.54.241		85.105.85.189
208.101.5.140		62.212.81.166		89.178.64.57

Et pour rire, le top 5 des URL sur lesquelles ils se sont acharnés :

40 …/index.php/2006/11/26/67-le-spam-sur-les-blogs-et-les-forums
11 …/index.php/2006/11/26/67-le-spam-sur-les-blogs-et-les-forums/register.php
 9 …/tb.php?id=60
 9 …/tb.php?id=49
 5 …/tb.php?id=30

26 novembre 2006

Le spam sur les blogs et les forums

Toute méthode de diffusion d'information qui peut être automatisée est un jour ou l'autre récupérée pour délivrer des messages publicitaires non sollicités : du spam. La multiplication des forums ou des blogs avec leurs commentaires et autres trackback est une bénédiction pour les pourris qui vendent du viagra chinois placébo ou des rollex en taule ondulée.

La première chose à comprendre c'est qu'aucune méthode automatique n'est infaillible. Seule une modération manuelle, par un humain en pleine possession de ses moyens, peut bloquer tout le spam qui serait posté à destination d'un forum ou d'un blog. Ceci posé, voilà quelques conseils pour filtrer un peu la crasse du monde.

Continue reading →

14 août 2006

Chapi-Chapo, toujours premier

Parfois, il est des chiffres qui vous forcent à relativiser votre travail. Les statistiques d'audience de ce site web en font partie.

Sur ce site, entre les (anciennes) archives dynamiques de la liste AppleScript Francophone, et les très anciennes archives statiques de la même liste, il y a 18 Mo de données, en dehors de tout enrobage html. Sur la semaine du 7 au 13 août, ces archives ont reçu 152 visites "humaines" à la suite d'une recherche dans un moteur comme Google ou Yahoo. Pendant cette période, ce blog recevait 70 visites ("humaines") pour seulement 140 Ko de données (hors html). Cette même semaine, la vieille page sur le jdr Chapi Chapo a été vue 66 fois à l'issue d'une recherche dans un moteur. Elle contient environ 3,7 Ko de données.
Pour résumer :

pages "applescript" : 152 visites après recherche, 18 Mo de données, soit 0,0082 hit/Ko
le blog :70 visites après une recherche, 140 Ko de données, soit 0,5 hit/Ko
Chapi Chapo : 66 vis. après une recherche, 3,7 Ko de données, soit 17,8 hits/Ko

Moralité, on peut passer ses soirées à mettre en place des mégaoctets de contenu "intéressant", c'est toujours la vieille blague statique en html 3 qui traîne dans un coin qui attire le plus de visiteurs. En 2008 je me promets de fêter dignement les 10 ans de cette page, qui est de loin la plus vieille et la plus rentable de tout le serveur...

1 juin 2006

Chronométrer l’acheminement du courrier électronique (bis)

Après plusieurs jours de fonctionnement, et quelques bugs sévères éradiqués, voici une nouvelle version de mes scripts de mesure des délais d'acheminement de courrier électronique.

email_delay_tracking.tgz

Au nombre des changements importants :

utilisation de sqlite 3 pour stocker les données
augmentation des précautions visants à limiter les accès concurrents aux données
correction d'un bug empêchant le traitement des dates du 1er au 9ème jour du mois

Ancienne version par ici

27 mai 2006

Chronométrer les étapes de l’acheminement du courrier électronique

Dans certains contextes, comme à l'Université Lyon 2, il peut être important de se faire une idée en temps réel des délais d'acheminement du courrier électronique étape par étape. Bien sûr, cela n'a de sens que sur une chaîne de serveurs internes et connus. Dans le cadre de l'audit et de la surveillance de l'infrastructure de courrier électronique de Lyon 2, j'ai développé un outil "quick & dirty" d'analyse des délais inter-serveur.

Entre l'extérieur du réseau, et la boîte email de l'utilisateur nous avons 5 étapes, donc 4 délais à calculer et surveiller. Chaque étape ajoute au courrier un entête "Received:" incluant le serveur "source", le serveur "destinataire", et surtout, la date et l'heure de la transaction. La différence de temps entre les date et heure de deux entêtes nous donne le délais subit par le courrier sur le serveur "source".
Pour avoir une vue de ce qu'il se passe sur cette chaîne de serveurs, il faut donc poster un courrier en entrée de site, le recevoir en bout de chaîne, et analyser ses entêtes. Comme il n'y a pas besoin de performances, j'ai choisi l'approche la plus simple pour moi : des scripts shell et awk. Si on se limite à une vue d'ensemble, on a ceci :

Une crontab (ou un agent Launchd) lance le script qui génère le courrier. Ce script se connecte sur le smtp d'entrée de site et crée le courrier. Au passage il enregistre la date d'émission du courrier dans deux fichiers (on pourrait faire plus simple).
Le mail vit sa vie dans le système d'acheminement et de filtrage. Il arrive enfin sur le serveur POP.
Une instance fetchmail lancée en mode "démon" se connecte au serveur POP, et ramène le ou les courriers reçus . Ces courriers sont injectés dans le Postfix local puis transmis au fichier .forward du compte utilisateur réglé dans le .fetchmailrc.
Le .forward envoie chaque courrier dans un script de filtrage pour convertir les entêtes en délais.
Ce script awk lance enfin un script shell qui met à jour les fichiers d'enregistrement.

Les scripts shell de l'étape 1 et 5 sont en fait un seul et même script, qui lance des instructions différentes suivant qu'il est invoqué avec ou sans arguments. Dans les deux cas il génère un graphique représentant le délai par étape en fonction de la date d'envoi.

Installation
Pour que l'installation fonctionne il faut que la machine hôte puisse se connecter en ssh sur le serveur de courrier d'entrée de site, et puisse faire du POP via fetchmail pour récupérer les courriers en fin de chaîne. Il faut que la machine dispose aussi de gnuplot si on veut tracer les graphiques, et gawk (awk n'est pas suffisant car il ne gère pas les conversions de date).

1. Télécharger les scripts email_delay_tracking.sh et filtrage.awk et les copier à l'endroit voulu sur la machine d'analyse. Ne pas oublier de les rendre exécutables.
Normalement, le script filtrage.awk n'a pas besoin d'être beaucoup modifié, il est aussi générique que possible. Néanmoins, la ligne 25 devra être éditée pour remplacer "by MACHINE-D-ANALYSE" par la mention adaptée à l'entête de réception de la machine locale. On vérifiera aussi la ligne 1 du fichier pour mettre le cas échéant le chemin exact de gawk.
La configuration de email_delay_tracking.sh est un peu plus longue. Il faut impérativement configurer les variables MY_SMTP, MY_ROOT, MY_SSHKEY et MY_ACCOUNT en début de script. Attention aussi au lignes 111 et 125, les chemins de gnuplot et gawk sont "en dur".

2. Créer la clé SSH de connexion au serveur MY_SMTP. Pour plus de sécurité il faut bien sûr opter pour une clé ssh limitée à l'envoi de courrier et à la commande date (option command).

$ ssh-keygen -f /chemin/de/la/cle/emailmonitor -t dsa
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):    # ici on ne met rien
Enter same passphrase again:                   # idem
Your identification has been saved in /chemin/de/la/cle/emailmonitor.
Your public key has been saved in /chemin/de/la/cle/emailmonitor.pub.
The key fingerprint is: ...

La clé est générée, on va la brider maintenant en ajoutant au début de fichier emailmonitor.pub les mentions suivantes sur une seule ligne (juste devant "ssh-dss ...") :

command="echo test | mail emailmonitor@VOTRE-DOMAINE & date +%s",
no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

Ensuite on transfert emailmonitor.pub dans le fichier .ssh/authorized_keys de l'utilisateur voulu, sur le serveur MY_SMTP.

3. Activer filtrage.awk et email_delay_tracking.sh. Pour activer filtrage.awk il faut éditer le fichier .forward du compte utilisateur que l'on va dédier à la réception des courriers de test. Les courriers pour cet utilisateur seront tous détruits, attention donc de bien utiliser un compte dédié, ou d'utiliser procmail à la place du .forward. Typiquement, ce fichier contiendra la ligne :

$ more ~/.forward 
"|/chemin/de/filtrage.awk"

L'activation de email_delay_tracking.sh se fait par crontab. Un lancement toutes les 5 minutes est un bon rythme :

*/5 * * * * /chemin/de/email_delay_tracking.sh

La suite des activations se fait au niveau de fetchmail. En fonction de ses préférences et de l'adresse du serveur POP, on configure le fichier .fetchmailrc du compte utilisateur qui recevra les courriers de test. Cela donne quelque chose comme ça :

$ more .fetchmailrc 
set postmaster "UTILISATEUR"
set nobouncemail
set no spambounce
set properties ""
set logfile /home/UTILISATEUR/.fetchmail_log
set daemon 113
poll SERVEUR_POP
  with proto POP3 and options uidl
   user 'emailmonitor' there with password '*******' is 'UTILISATEUR' here

'emailmonitor' est le login du compte email MY_ACCOUNT. J'ai choisi un intervalle de 113 secondes entre chaque relève POP pour éviter les "collisions" avec l'étape d'envoi de courriers.

À partir de là, tout devrait fonctionner. Si ce n'est pas le cas, un simple tail -f sur .fetchmail_log, emailmonitor.log, ou les log du postfix local devrait donner l'origine de la panne. Si on a plus (ou moins) de 4 délais à calculer, il faut modifier le script email_delay_tracking.sh aux lignes 96, 105, 126-130. Pour plus de cohérence on pourra aussi modifier les lignes 32-35, 72 et 80, mais c'est facultatif. Ensuite, on doit normalement obtenir un graphique mis à jour automatiquement en temps réel.

edit : lun. 29 mai, mise à jour du script email_delay_tracking.sh (correction de bugs, ajout d'un graphique de "zoom" sur les deux dernières heures.

18 mai 2006

Temps de traitement amavisd-new/clamav

En complément de mon précédent article sur les performances du filtrage antispam et antivirus sur une plateforme Mac OS X Server + amavisd-new/clamav, voilà un graphique de temps de traitement moyen des emails. Ce graphique représente donc la durée moyenne du filtrage d'un email dans la passerelle frontale de Lyon 2. La partie filtrage est gérée par amavisd-new, qui utilise clamav comme antivirus et les librairie Perl de spamassassin pour filtrer le spam.

timing amavis

Je ne trouve pas cela très bon comme performance...

20 avril 2006

Mac OS X + hostname mal encodé = bug

Je ne tombe pas souvent sur des bugs dans Mac OS X, mais quand c'est le cas ils sont en général assez gratinés. Celui là n'est pas très grave, même si il peut s'avérer tout à fait horripilant.

Avec l'internationalisation à venir des noms de domaine (rfc 3490 et 4185), les systèmes sont obligés de s'adapter côté client et côté serveur. Comme à chaque fois qu'on introduit, par exemple, des accents dans la vision anglosaxonne de l'informatique, on se retrouve avec des problèmes d'encodage. Pas d'exception ici.

Certains DHCP facétieux acceptent les noms de machine avec des accents. C'est ainsi qu'à un retour de vacances, j'ai hérité d'une nouvelle IP, à la quelle est associé un nom de machine contenant la chaîne "aurélia". Joli prénom, joli accent. Résultat, les applications Mail et NetInfo Manager se sont mises à marcher de travers. Voyons comment cela se produit.

Pour reproduire le bug il n'est pas nécessaire de se lancer dans l'installation d'un serveur DHCP, un bon éditeur de texte suffit.
La première étape consiste à s'octroyer un nom de machine avec un accent mal encodé (ie. encodé en autre chose que de l'UTF-8). On peut utiliser par exemple BBEdit ou SubEthaEdit pour créer un fichier ne contenant qu'un mot accentué, et sauvegardé en ISO Latin 1 ou Mac OS Roman. Probablement que n'importe quel encodage provoque le bug, sauf l'UTF-8.

Dans le terminal on peut alors charger notre nouveau nom de machine après être passé root :

$ sudo -s
# file nom_host 
nom_host: ISO-8859 text, with no line terminators
# hostname `cat nom_host`

Dans une autre fenêtre de terminal (non-root), on peut alors passer à la seconde étape : lancer les appli dont on sait qu'elles sont atteintes par le bug :

$ cd /Applications/Utilities/
$ ./NetInfo\ Manager.app/Contents/MacOS/NetInfo\ Manager -errorLogLevel 7
2006-04-16 16:41:36.686 NetInfo Manager[627] Exception raised during posting 
of notification. Ignored. exception: *** -[NSCFArray insertObject:atIndex:]: 
attempt to insert nil

Et paf. NetInfo Manager ne parvient pas à ouvrir la base NetInfo locale. Si on tente ensuite d'utiliser le menu "Domain/Open..." on constate une nouvelle erreur :

2006-04-16 16:42:55.813 NetInfo Manager[627] *** -[NSCFArray 
insertObject:atIndex:]: attempt to insert nil

Pour l'application Mail, le comportement est bien plus étrange :

Il est impossible de répondre à certains messages, la fonction de réponse ne fonctionne pas, quelque soit le mode d'invocation (clavier, menu, bouton).
Il est possible de répondre à d'autres messages, mais le contenu de la fenêtre de réponse est vierge de toute citation et signature. C'est le cas par exemple des messages avec pièce jointe.
D'autres messages ne sont pas du tout touchés par ce bug.

Voici ce que l'on peut observer dans le terminal :

$ /Applications/Mail.app/Contents/MacOS/Mail -errorLogLevel 7

Tentative de réponse à un mail, la fenêtre de réponse ne s'ouvre pas :

2006-04-16 16:46:16.249 Mail[664] *** -[NSCFArray insertObject:atIndex:]: 
attempt to insert nil

Tentative de réponse à un message avec pièce jointe, la fenêtre de réponse est vierge :

2006-04-16 16:46:25.398 Mail[664] Exception raised during monitored invocation 
of _generateWebArchiveFromOriginalMessagesSetupForViewAndContinue:continueFinalSetupTarget:, 
exception: *** -[NSCFArray insertObject:atIndex:]: attempt to insert nil

On pourrait se dire que le bug est facile à éviter : si un DHCP vous attribue une IP qui résout en un nom de domaine avec accent mal encodé, il suffit de régler la machine pour prendre un autre nom par la commande hostname. Il n'en est rien. Pour que le bug se manifeste, il suffit qu'une des IP de la machine soit associée à un nom de domaine mal encodé dans le DNS de référence. Même si ce nom n'est pas utilisé par la machine.

Cognitive Overhead

Archives