Exploiter les résultats de l'audit

Dans le premier article j'ai mentionné très succinctement une commande qui permet de lire les logs d'audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n'a envie d'activer l'audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d'être : pouvoir ensuite (ou en temps réel) exploiter les logs d'auditd.
Comme précisé par défaut dans le fichier audit_control, la taille maximale d'un fichier de log d'audit est 2Mo, et les anciens fichiers sont supprimés pour que le volume total ne dépasse pas 10 Mo :

filesz:2M
expire-after:10M

Il existe plusieurs options intéressantes pour expire-after que je vous laisse découvrir dans le man audit_control. Sachez seulement qu'en fonction de ce que vous choisirez de surveiller, vous allez devoir modifier ces paramètres. Sur une machine assez sollicitée, 10 Mo de log peuvent représenter moins d'une heure d'audit. Si vous avez besoin d'enquêter sur un événement de la veille, il vous sera alors impossible d'en retrouver la trace.

Il y a deux moyens immédiats d'exploiter les logs d'audit. Vous pouvez soit les suivre en direct comme je l'ai montré dans le premier article via la commande praudit /dev/auditpipe, soit les étudier a posteriori. C'est sans doute cette option qui sera le plus souvent utilisée. Vous pouvez ainsi utiliser praudit pour lire les fichiers de logs enregistrés dans /var/audit/.
Comme les logs d'audit peuvent grossir très vite, et qu'on cherche souvent l'aiguille dans la meule de foin, il est bon de pouvoir réduire les logs à ce que l'on cherche avant de les afficher. C'est le rôle de la commande auditreduce. Cette commande permet de filtrer les logs selon une série de critères tels que la date, le ou les flags d'évènement (fc, ex, ...), l'UID, le ou les évènements précis (tels qu'ils sont répertoriés dans le fichier audit_event), et d'autres encore.
auditreduce s'utilise sous la forme générale suivante :

auditreduce paramètres fichiers_de_log | praudit

Comme les logs sont binaires, il est impératif de les traduire via praudit.
Sur Mac OS X, voici un exemple de ce que l'on peut obtenir avec la configuration par défaut d'auditd. Je cherche ici tous les événements pour l'UID réelle patpro ayant eu lieu après le 5 juin 2011 à 12h. Je fais cette recherche dans le fichier de log ouvert par auditd.

# auditreduce -a 2011060512 -r patpro /var/audit/current | praudit
header,68,11,logout - local,0,Sun Jun  5 15:47:35 2011, + 877 msec
subject,patpro,root,patpro,patpro,patpro,10485,10485,0,0.0.0.0
return,success,0
trailer,68
header,68,11,logout - local,0,Sun Jun  5 15:57:05 2011, + 718 msec
subject,patpro,root,patpro,patpro,patpro,10948,10948,0,0.0.0.0
return,success,0
trailer,68

Ces deux évènements correspondent à la fermeture d'une fenêtre de terminal. On voit que chacun d'eux commence par "header" et termine par "trailer". Je ne vais pas couvrir l'intégralité des champs d'un enregistrement de log d'audit, il y a beaucoup trop de possibilités. Reportez-vous au man audit.log pour le détail. Ceux qui ont un intérêt sinon universel, au moins relativement général, sont subject qui décrit le sujet qui a généré les évènements, path qui décrit le chemin du fichier concerné, et return qui indique si l'opération a réussi ou non.
Le champ subject contient les UID et GID (audit UID, effective UID et GID, real UID et GID), le PID, et le port et l'IP de la machine connectée.
Le champ path donne par exemple le chemin d'un exécutable lancé, ou le chemin d'un fichier créé/modifié/détruit.
Le champ return indique success ou failure.

Voici un second exemple, pour un serveur Apache sur Mac OS X, lancé via l'utilitaire setaudit :

header,127,11,execve(2),0,Wed Jun  1 14:50:44 2011, + 667 msec
exec arg,ls
path,/bin/ls
path,/bin/ls
attribute,100555,root,wheel,234881026,24767,0
subject,_www,_www,_www,_www,_www,26696,100031,0,0.0.0.0
return,success,0
trailer,127
header,131,11,open(2) - write,creat,trunc,0,Wed Jun  1 14:50:44 2011, + 735 msec
argument,3,0x1a4,mode
argument,2,0x601,flags
path,/Users/patpro/Sites/testFile.txt
subject,_www,_www,_www,_www,_www,26694,100031,0,0.0.0.0
return,failure : Permission denied,4294967295
trailer,131

La requête http s'est faite sur la machine locale (http://localhost/...) vers un fichier PHP dont le code exécute la commande system("ls"); puis tente d'écrire un fichier testFile.txt.
Le premier évènement enregistré montre le lancement de la commande ls, avec succès. Le second évènement montre la tentative d'écriture du fichier testFile.txt qui échoue.
Cet exemple montre donc clairement comment les logs d'audit peuvent permettre, par exemple, de remonter la trace d'une compromission d'un serveur web. Notez que si j'avais lancé le serveur web normalement, sans utiliser setaudit, la ligne subject aurait indiqué subject,patpro,_www,_www,_www,_www..., patpro étant l'UID suivi par auditd. Il aurait donc fallu que le fichier audit_user indique les flags ex et fc pour le login patpro, sans quoi les évènements pour le serveur web n'auraient pas été enregistrés.

auditreduce permet de filtrer les évènements selon un critère beaucoup plus fin que le simple flag (fc, fd, ex, ...). Il vous autorise à différencier chaque évènement avec la granularité du fichier audit_event. Si vous avez eu la curiosité d'ouvrir ce fichier, vous savez qu'il contient plus de 600 lignes de ce genre :

0:AUE_NULL:indir system call:no
1:AUE_EXIT:exit(2):pc
2:AUE_FORK:fork(2):pc
3:AUE_OPEN:open(2) - attr only:fa
4:AUE_CREAT:creat(2):fc
5:AUE_LINK:link(2):fc
6:AUE_UNLINK:unlink(2):fd
7:AUE_EXEC:exec(2):pc,ex
8:AUE_CHDIR:chdir(2):pc
9:AUE_MKNOD:mknod(2):fc

La nomenclature est simple. Chaque colonne est séparée des autres par ":". La première donne le numéro de référence d'un événement, la seconde donne son nom, la troisième le nom de la fonction correspondante, avec éventuellement un complément d'information, et la dernière indique le ou les flags correspondants.
Sur les 10 lignes citées au dessus, vous notez qu'il y a déjà 4 évènements correspondants au flag pc, et 3 au flag fc. Donc si on se contente de faire un filtrage sur pc ou fc, on peut remontrer beaucoup trop d'évènements par rapport à ce que l'on cherche vraiment. Par ailleurs, dans certains cas, un même évènement peut correspondre à plusieurs flags contradictoires. Par exemple :

75:AUE_OPEN_RTC:open(2) - read,creat,trunc:fc,fd,fr,fa,fm

Cet évènement peut être détecté si on souhaite suivre les flags fc, fd, fr, fa ou fm !
C'est ici qu'intervient le contenu de la ligne header des logs d'audit. En effet, l'entête indique clairement l'évènement qui est capturé. Par exemple open(2) - write,creat,trunc. Il suffit alors de chercher son nom dans le fichier audit_event pour pouvoir s'en servir de clé de filtrage :

grep 'open(2) - write,creat,trunc' /etc/security/audit_event
79:AUE_OPEN_WTC:open(2) - write,creat,trunc:fc,fd,fw,fa,fm

Il est alors possible d'utiliser AUE_OPEN_WTC comme ceci pour obtenir en sortie une sélection parfaite des évènements qu'on recherche :

auditreduce -m AUE_OPEN_WTC -r www -o file=".*/bd/.*" /var/audit/current | praudit

Cette commande permet de trouver tous les évènements AUE_OPEN_WTC pour l'utilisateur www qui ont eu pour cible des fichiers dont le chemin contient la chaîne "/bd/" dans le fichier de log d'audit courant.
Il ne vous reste plus qu'à essayer par vous même !

Bibliographie sommaire

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf
man auditreduce
man auditd
man audit_user
man audit_control
man audit_event
man audit.log
http://forums.freebsd.org/showthread.php?t=23716

Configuration : quid des utilisateurs comme www ?

J'expliquais précédemment que le système d'audit ne peut suivre un utilisateur que si ce dernier se connecte à la machine (par ssh par exemple), et que quelques soient les ruses utilisées (su, sudo...) c'est toujours l'UID réelle de l'utilisateur qui est suivie.

À cause de cela, il est totalement impossible de traquer des évènements appartenant à des utilisateurs qui ne peuvent pas se connecter au système. Ainsi, une ligne comme celle-ci dans audit_user ne permettra de traquer aucun évènement :

# pour freebsd remplacer _www par www
_www:fc,fd,ex:

Il serait pourtant très intéressant de savoir ce que fait Apache dans votre dos, parfois sous la direction de méchants pirates.
De nos jours, La plupart des serveurs utilisent des protocoles comme l'HTTP qui permettent aux utilisateurs d'accéder aux ressources sans être authentifiés au niveau du système. Les utilisateurs en question n'existent d'ailleurs pas au niveau du système. Néanmoins, les applications web permettent de faire énormément de choses via les langages comme le PHP, y compris d'interagir avec le système, en lançant des commandes, en créant des fichiers, etc.

Si on souhaite qu'auditd puisse contrôler les actions de www, il faut recourir à un artifice. Attention tout de même, ce qui suit est plus proche d'un hack que d'une méthode vraiment propre, et je ne peux pas garantir son fonctionnement correct dans un environnement de production.

En premier lieu il faut installer un programme spécifique, qui va permettre de forcer auditd à suivre les actions pour une UID donnée, sans que l'utilisateur correspondant ait besoin de se connecter à la machine.

curl -LO http://www.freebsd.org/~csjp/setaudit.c
cc -o setaudit -lbsm setaudit.c 

Cela vous donne, si tout se passe bien, le binaire setaudit, que l'on va utiliser sous cette forme :

setaudit -a UID_WWW -m FLAGS /programme/de/lancement/d/apache

Pour suivre les évènements d'exécution de commande sous respectivement FreeBSD et Mac OS X, cela donnera :

setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart
setaudit -a _www -m ex /usr/sbin/apachectl restart

Ainsi, toutes les commandes lancées par Apache (donc sous l'UID www) sont enregistrées par auditd.
Comme le masque des évènements (les flags de l'argument -m) décrit ce que l'on doit suivre, il est même inutile de renseigner le fichier audit_user.

Pour résumer :

• Si vous souhaitez que l'audit suive les utilisateurs qui se connectent à la machine, vous pouvez régler les classes d'évènements qui seront soumises à l'audit pour l'ensemble des utilisateurs dans le fichier audit_control, et gérer les cas particuliers dans audit_user.
• Si vous souhaitez que l'audit suive des UID "interne", pour traquer tout signe de compromission sur un serveur web, un serveur de mail, etc. il faudra recourir à setaudit pour activer l'audit au moment du lancement du service correspondant.
• Faites attention à la liste de flags que vous choisissez. Le volume des logs d'audit peut grossir très rapidement.

Troisième partie de l'article ->

Activation du système d'audit
Configuration
Configuration : quid des utilisateurs comme www ?
Exploiter les résultats de l'audit

Activation du système d'audit

Sous FreeBSD 7 et 8, le noyau est déjà compilé avec options AUDIT, il ne reste donc qu'à lancer le démon auditd en ajoutant la ligne suivante au fichier /etc/rc.conf :

auditd_enable="YES"

puis en lançant le démon à la main :

sudo /etc/rc.d/auditd start

Sous Mac OS X 10.6, auditd est lancé d'office par launchd, il n'y a rien à faire.

Configuration

Une fois lancé, le système d'audit va enregistrer très peu d'évènements par défaut. Il convient donc de faire quelques réglages en fonction de ce que l'on cherche à accomplir.
Les fichiers de configuration d'auditd se trouvent dans le répertoire /etc/security où seul root peut écrire.

• audit_class : décrit les différentes classes d'évènements qu'il est possible de surveiller. Il est sage de ne pas éditer ce fichier.
• audit_control : lisible seulement par root, ce fichier défini la politique d'audit par défaut.
• audit_event : le grand frère de audit_class, on ne le modifie pas.
• audit_user : le fichier de réglages par utilisateur. Il complète audit_control et n'est lisible que par root.
• audit_warn : un fichier exécutable qui est lancé quand auditd manque de place sur le disque pour écrire les logs.

Pour un usage courant, seuls les fichiers audit_control et audit_user sont intéressants. La première chose à faire est d'aller lire leur page man respective.

Par défaut, le contenu du fichier audit_control est le suivant :

dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

Avec ces valeurs, auditd ne va répertorier que les évènements des classes "lo" (login/logout) et "aa" (authentification/autorisation). Et il va le faire pour l'ensemble des utilisateurs.
Attention : après avoir lu le man audit_control, vous serez peut être tenté d'ajouter le champs "host" pour compléter la configuration. N'en faites rien. Cela peut perturber les outils utilisateur et rendre l'exploitation des résultats hasardeuse, voire impossible.
Le contenu de audit_user quant à lui nous permet de préciser des flags en se basant sur le login des utilisateurs. Par défaut, le fichier audit_user contient :

root:lo:no

C'est à dire que, quelque soit la liste des flags audit_control, les évènements de la classe "lo" seront suivis pour l'utilisateur root, et les évènements de la classe "no" (invalides) ne seront jamais suivis.
Vous pouvez immédiatement vérifier que votre système d'audit fonctionne en lisant en direct les évènements qu'il enregistre. Il suffit pour cela de taper la commande suivante en root (ou via sudo) :

# praudit /dev/auditpipe

Utilisez alors une autre fenêtre de terminal pour gérer des traces. Sous Mac OS X vous pouvez faire un sudo, ou simplement fermer la fenêtre de terminal, par exemple. Vous pourrez alors lire des choses comme cela :

header,104,11,user authentication,0,Wed Jun  1 14:53:39 2011, + 965 msec
subject,root,root,wheel,root,wheel,26712,0,0,0.0.0.0
text,Authentication for user <patpro>
return,success,0
trailer,104
header,68,11,logout - local,0,Wed Jun  1 15:36:12 2011, + 554 msec
subject,patpro,root,patpro,patpro,patpro,28079,28079,0,0.0.0.0
return,success,0
trailer,68

Nous en reparlerons dans le dernier article de la série.

Faites bien attention aux flags que vous allez régler. Dans certains cas, le nombre d'évènements enregistrés par le système d'audit peut être extrêmement élevé. Par défaut peu de choses sont soumises à l'audit, si bien qu'en 18 mois sur une station de travail, le contenu de /var/audit représente moins de 10 Mo. A contrario, sur un serveur web assez actif, où les classes d'audit sont "fd,^fc,ex:no,fc", on dépasse les 43 Mo en a peine 4 heures d'audit.

Il faut bien comprendre que l'activation de l'audit pour un utilisateur ne se produit qu'au moment de la première connexion de l'utilisateur au système. Prenons un exemple. Le fichier audit_user contient :

root:lo:no
patpro:fc,fd,ex:

Donc pour l'utilisateur patpro, les créations, ouvertures, suppression de fichier, ou exécutions de programmes doivent être suivis. Cet utilisateur a une crontab qui tourne toutes les nuits et télécharge un fichier. Pourtant, auditd ne capturera aucun de ces évènements tant que l'utilisateur patpro ne se sera pas connecté à la machine, alors même que de nombreux évènements correspondants aux critères de l'audit se produisent.
Dès que l'utilisateur patpro se sera connecté à la machine, auditd se mettra à enregistrer toutes les actions correspondant aux classes fc, fd et ex exécutées sous l'UID patpro. Cet audit se poursuivra même après la déconnexion de l'utilisateur.
Par ailleurs, l'UID qui est traquée par auditd n'est pas l'UID apparente, mais l'UID d'origine de l'utilisateur. Si je me connecte en tant que patpro, et que je fais un su - ou un sudo -Es, je deviens root dans le shell (UID apparente), mais je reste patpro aux yeux d'auditd.
Nous verrons dans un second article pourquoi ces deux contraintes sont importantes. D'ici là, vous pouvez approfondir les aspects simples de la configuration en lisant ces différents documents :

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html
https://ssl.apple.com/support/security/commoncriteria/CommonCriteriaAdminGuide.pdf

Deuxième partie ->

Ne faites pas comme Nick Denton, le fondateur de Gawker Media : n'utilisez pas le même mot de passe ridicule (24862486) partout. Ne partagez jamais un mot de passe par email, chat, ou autre, mais partez du principe que les autres le font. Pour finir, ne faites pas confiance aux dépositaires de vos mots de passe.

Joyeux Noël ;)

This weekend we discovered that Gawker Media's servers were compromised,
resulting in a security breach at Lifehacker, Gizmodo, Gawker, Jezebel,
io9, Jalopnik, Kotaku, Deadspin, and Fleshbot. As a result, the user name
and password associated with your comment account were released on the
internet. If you're a commenter on any of our sites, you probably have
several questions.

Outch.

Un aspect sympathique de ZFS (parmi tant d’autres !), est sa capacité à générer et gérer des snapshots. Un snapshot, c’est une sorte de photographie à un instant donné d’un système de fichiers. Cette photographie peut alors être montée comme n’importe quel autre système de fichiers, elle peut servir de base à une sauvegarde, elle peut servir à rechercher un fichier effacé après la création du snapshot…
Plus que l’utilité évidente en matière de sauvegarde de ces snapshots, j’aimerai revenir sur leur fonctionnement interne, car c’est là que réside toute la magie. En effet, au premier abord l’idée d’une photographie à un instant T de son disque dur semble séduisante, mais très rapidement des voix s’élèvent qui s’interrogent sur le temps que cela prend, la place que cela occupe… Imaginez votre disque dur de 250 Go, 500 Go, ou même 1 To, bien rempli. Vous concluez naturellement que pour faire un snapshot de votre volume, il vous faudra un disque dur externe, de grande capacité, et que cela prend un temps fou. Fort heureusement, c’est faux.

ZFS crée ses snapshots selon le mode copy on write, tout comme le système de fichiers par défaut de FreeBSD : UFS. C’est ce dernier que je vais utiliser pour présenter le fonctionnement des snapshots. Il est probable que l’implémentation des snapshots dans ZFS diffère légèrement, mais la logique reste la même, et de nombreux autres systèmes la partage.

Attention. Les explications suivantes sont parfois simplifiées outrageusement. D'une part car les informations techniques précises sont très dispersées et pas toujours très claires ni faciles à se procurer. D'autre part pour rendre compte de manière accessible des mécanismes généraux impliqués dans la création de snapshots.
Si vous êtes un as des systèmes de fichiers et des snapshot, n'hésitez pas à proposer des rectifications.

Sur un système de fichiers, les données sont organisées en blocs. Au début du système de fichiers, un index des blocs existe qui permet de retrouver les différents blocs appartenant à chaque fichier. On parle de block bitmaps. À l’instant T où je crée un snapshot d’un système de fichiers, je n’ai pas besoin de recopier l’intégralité du disque, car tous les fichiers s’y trouvent déjà. J’ai juste besoin de faire une image des block bitmaps.
Si on recopiait les block bitmaps à l’identique, on ne pourrait pas monter un snapshot comme on le fait avec une image disque classique. En effet, les block bitmaps du snapshot pointeraient vers des blocs que l’on n’a pas recopiés, sans que le système puisse le savoir. En réalité, à la création du snapshot, toutes les références contenues dans les block bitmaps sont traduites. Quand l’index d’origine référence un bloc vide, alors l’index du snapshot utilise le pointeur not used, et si l’index d’origine référence un bloc utilisé, alors l’index du snapshot utilise le pointeur not copied.
Finalement, juste au moment de sa création, le snapshot ne contient que des indexes remplis de pointeurs not used et not copied. Cela prend très peu de place, et la création est relativement rapide (instantanée sur ZFS, parfois longue sur UFS).

L’utilisateur se dit maintenant que si il modifie ou efface un fichier, son snapshot ne lui servira à rien puisque tous les blocs de données résident sur le système de fichiers et non pas sur le snapshot. C’est ici qu’intervient le mécanisme de copy on write. L’instant T est passé, le snapshot existe, système et utilisateurs écrivent sur le disque. Le système sait qu’un snapshot existe, il intercepte donc toute les demandes d’écriture, et les converti en “copie à l’écriture”.

Voici ce qui se passe lors de l’effacement d’un bloc sur le système de fichier (suppression ou réécriture d’un fichier, par exemple) :

1. Le système intercepte la demande d’écriture.
2. Il lit le pointeur correspondant dans l’index du snapshot.
3. Si le pointeur est à not copied, le système recopie le bloc dans le snapshot, et met à jour l’index du snapshot pour qu’il pointe vers ce nouveau bloc, et non plus vers not copied.
4. Si le pointeur est à not used ou si il contient déjà l’adresse d’un bloc du snapshot, rien n’est modifié dans le snapshot.
5. Enfin, le bloc est effacé sur le système de fichiers.

Pour ceux qui ont besoin d'un dessin, voici un schéma trop compliqué (et donc forcément faux) du mécanisme de copy on write appliqué au snapshot. En haut, l'étape T=0 : le snapshot est créé. Au milieu, la réécriture des blocs (suppression du fichier bleu marine) est interceptée : les blocs sont recopiés dans le snapshot, la block bitmap du snapshot est mise à jour. En bas, l'écriture est faite sur le système de fichier original : le fichier n'existe plus, les indexes correspondant sont vidés.

L’ajout de fichiers sur le système de fichiers ne fait pas grossir le snapshot, car ce dernier doit continuer de référencer les blocs not used correspondants, pour maintenir une image fidèle du système de fichiers à l’instant T. De même, les réécritures multiples de blocs n’ont pas d’impact sur la taille du snapshot, car ce dernier ne conserve qu’une version des blocs : celle qui date de l’instant T.

On peut donc dire que la taille d’un snapshot est approximativement égale à la taille des blocs utilisés à sa création et qui ont été modifiés depuis. Mais il faut surtout retenir que la taille d’un snapshot dépend beaucoup de l’utilisation que l’on fait de son système de fichiers, et de la durée de vie de ce snapshot. En effet, tant qu’il n’a pas été supprimé, un snapshot est toujours maintenu par le système. Sa taille maximum théorique est égale au volume de données stocké sur le système de fichier de départ.
On peut lire en divers endroits que la taille d’un snapshot est en général 10 à 15% de la taille du système de fichiers original. C’est une estimation tout à fait farfelue qui ne repose sur rien de concret. Seule l’expérience ou une analyse très fine de vos usages permet d’estimer la taille que vos snapshots pourraient atteindre. Par exemple, nous avons calculé que la taille d’un snapshot quotidien de la baie RAID qui stocke les emails de l’Université Lyon 2 occuperait moins de 1% du volume occupé par les messages eux-même (par jour d’existence).

Quand l’utilisateur lit le snapshot, le système lui présente une vue cohérente de son système de fichiers à l’instant T. Le système lit les block bitmaps du snapshot, et reconstitue les fichiers. Quand il tombe sur un pointeur not copied, il sait que le bloc n’a pas été modifié depuis la création du snapshot, et qu’il peut retrouver ce bloc sur le système de fichiers d’origine. Quand il tombe sur un pointeur qui désigne une adresse de bloc dans le snapshot il sait que le bloc a été modifié entre temps, et que son contenu à l’instant T est stocké dans le snapshot.
À cause de cette dépendance entre les block bitmaps et les blocs de données, un snapshot doit forcément résider sur le système de fichiers qu’il réplique. Il est donc malheureusement impossible d’avoir un snapshot d’un disque sur un second disque.

Un peu de lecture pour aller plus loin :
ZFS et snapshot

• http://en.wikipedia.org/wiki/ZFS
• http://en.wikipedia.org/wiki/Snapshot_(computer_storage)
• http://en.wikipedia.org/wiki/Copy-on-write

UFS et snapshot

• http://www.nycbug.org/files/FFS.pdf

En mai 2008, on note le pic (il dépasse 130 POST/jour) qui correspond à très peu de user agents différents (1 à 2, suivant le jour). Alors que dans le reste de la période la courbe du nombre de POST est très proche de la courbe du nombre d'UA différents.
À noter que, plutôt que de me limiter au seul User Agent, j'ai fait ma petite analyse sur la concaténation des variables HTTP_USER_AGENT, HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, et HTTP_ACCEPT_ENCODING. On obtient ainsi une meilleure discrimination entre les différents attaquants.

Voici un exemple abrégé de capture :

REQUEST_TIME : 2008-12-09 19:51:33
HTTP_HOST : www.patpro.net
REMOTE_ADDR : 88.198.53.43
HTTP_USER_AGENT : Mozilla/5.0 (Windows; U; Windows NT 5.0; ru; rv:1.8.1.6)
                  Gecko/20070725 Firefox/2.0.0.6
HTTP_ACCEPT : text/xml, application/xml, application/xhtml+xml,
              text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_LANGUAGE : ru
HTTP_ACCEPT_ENCODING : deflate

Si on s'intéresse particulièrement aux variables HTTP_ACCEPT* on voit qu'elles sont utilisées de manières très inégales en fonction du robot :

On peut supposer que ces caractéristiques permettent de différencier les différents botnets, et versions des scripts. Les spammers poussent donc le raffinement assez loin, dans le but, bien sûr, de passer au travers des protections antispam. Dans certaines tentatives que j'ai enregistrées, le client fourni même un cookie de session.

Je rappelle à toutes fins utiles que, si le cœur vous en dit, vous pouvez télécharger le "plug-in" signal-spam pour Mail, qui permet de déclarer votre spam à l'organisme paresseux nommé Signal Spam (c'est pas bien de se moquer, méchant patpro).

Voyons quelques cas d'utilisation concrets de ces deux commandes, avec pour commencer une boucle for classique. Note : toutes les commandes présentées ici ont été testées dans un shell bash. La syntaxe des différentes boucles peut varier dans d'autres shells.
Imaginons que j'ai besoin d'une boucle qui tourne sur une liste de chiffres de 1 à 10, je peux très simplement faire ceci, et obtenir à chaque fois le même résultat exactement :

# syntaxe basique
for i in 1 2 3 4 5 6 7 8 9 10; do
	# mon travail
	echo $i
done

# syntaxe avancée
for ((a=1; a<=10 ; a++)); do
	# mon travail
	echo $a
done

# autre syntaxe avancée
for a in {1..10}; do
	# mon travail
	echo $a
done

# syntaxe avec seq
for b in $(seq 1 10); do
	# mon travail
	echo $b
done

# syntaxe avec jot
for c in $(jot 10); do
	# mon travail
	echo $c
done

Pour ces cas simples, l'intérêt des commandes seq et jot n'est pas immédiat, d'autant que si la syntaxe basique est hors jeux pour les listes longues (1 à 1000 par exemple), les syntaxes avancées sauront en général s'en tirer.
Voyons comment faire maintenant si je souhaite faire une liste de 01 à 10 :

La syntaxe basique fonctionne toujours, mais je dois taper à la main 01, 02, ... C'est fastidieux. Les syntaxes avancées ne savent pas faire directement. Je peux par contre invoquer printf pour faire une réécriture de mes valeurs :

for a in {1..20}; do
	a=$(printf "%02d" $a)
	# mon travail
	echo $a
done

Pour faire ce type d'itération sans étapes intermédiaires il reste seq et jot.
L'ajout de l'option w à la commande seq permet de forcer le formatage de sorte que tous les nombres affichés aient la même largeur. En cas de besoin, un ou plusieurs 0 sont ajoutés devant le nombre pour compléter :

seq -w 1 10
# résultat :
01
02
...
09
10

Pour jot, le padding n'est pas complètement automatique, il faut en régler la largeur via le formatage de type printf. On obtient le même résultat qu'avec seq :

jot -w '%02d' 10

C'est plus délicat, mais cela nous permet de mettre le doigt sur une première limitation de seq : ce dernier ne sait pas utiliser d'autres options de printf que %e, %f et %g.
Ainsi, pour produire une liste de 00001 à 00010, je peux utiliser jot, mais pas seq :

jot -w '%05d' 10
# résultat :
00001
00002
...
00009
00010

Les deux commandes sont bien sûr capables de gérer une borne inférieure et une borne supérieure, mais leur gestion des incréments est une de leurs différences fondamentales. Vous pouvez indiquer à chacune de travailler de 1 à 1000 mais seq ne sait travailler que par incrément fixe :

# seq sait aller de 1 à *maximum* 1000 par saut de 250 :
seq 1 250 1000
# résultat :
1
251
501
751

Alors que jot travaille par défaut sur le nombre d'étapes :

# jot sait aller de 1 à 1000 strictement, en 5 étapes :
jot 5 1 1000
# résultat :
1
251
500
750
1000

jot fonctionne en fait en calculant l'incrément optimal. Ce dernier comporte parfois des décimales. Comme le format par défaut pour jot est l'entier, le résultat ci-dessus n'est qu'un arrondi des valeurs réelles de travail de jot. Si on force l'affichage des décimales, on obtient bien une série mathématiquement satisfaisante :

jot -w '%g' 5 1 1000
# résultat :
1
250.75
500.5
750.25
1000

Il sait aussi travailler sur un incrément explicite, comme seq :

# et jot donne alors le même résultat que seq :
jot 5 1 1000 250
# résultat :
1
251
501
751

Nous laissons définitivement seq derrière nous, car il ne sait travailler qu'avec des chiffres, alors que jot peut utiliser tout l'ASCII, générer des listes aléatoires, écrire une chaîne donnée x fois. Et si vous le jumelez avec son ami rs, il sait générer des matrices, des séries de mots de passe...
Voici quelques exemples tirés du man et d'ailleurs :

# les 128 caractères ASCII :
jot -c 128 0

# une ligne de 40 points :
jot -s "" -b . 40

# l'alphabet en majuscule :
jot -c 26 A

# créer 5 noms de fichiers partiellement aléatoires :
jot -r -w '/tmp/fichier-%05d' 5 0 10000

# 10 mots de passe de 12 caractères ASCII aléatoires entre ! et ~ :
jot -r -c 120 33 126 | rs -g0 -w12

# une matrice 10x10, de 100 nombres tirés au hasard entre 1 et 100
jot -r 100 | rs 10 10 

Un peu d'histoire pour finir. Le nom de la commande jot ne cesse de faire râler les linuxiens qui doivent un jour ou l'autre travailler sur un système BSD. Il est indéniable que seq est un nom qui tombe sous le sens, de sequence à seq, il n'y a qu'un pas. Pour jot, ce n'est pas aussi immédiat.
Le nom de jot signifie en anglais "très petite quantité", et vient du latin iota. John A. Kunze, qui a développé jot, mais aussi rs et lam, m'a expliqué qu'il a écrit ces trois commandes il y'a très longtemps, en s'inspirant des opérateurs iota, reshape, et laminate du langage APL. Il a alors décidé de donner à ses commandes des noms typiquement "unixiens". Ainsi sont nées jot, rs et lam.

edit 1 : ajout du résultat pour certains exemples, correction d'une typo dans une commande.
edit 2 : correction d'un exemple, suppression de certaines boucles for inutiles, ajout de précision sur les incréments décimaux.
edit 3 : ajout des séquences du type {1..10} gérées par bash.

• aide mobilité site:SuperJob.fr - Google Search
• Grosse Cochonne sans culotte - xXx

Inutile de vous faire un dessin. Dans votre navigateur vous êtes libre à tout moment d'effacer votre historique. Dans Slife, vous ne pouvez pas le faire. Si vous avez oublié d'activer le mode "Privé" avant de chercher un nouveau job, ou d'aller mater quelques paires de fesses au nez et à la barbe de votre employeur, vous êtes cuits.
Bien sûr, il y aura toujours un petit malin pour aller éditer la base de données de Slife à la main. Mais ce n'est pas le genre d'acrobatie à la portée du premier venu. Je vais néanmoins donner la marche à suivre. Notez bien : j'ai bien sûr testé cette manipulation, mais je ne peux pas garantir qu'elle est inoffensive sur le long terme. Il n'est pas complètement exclu que cela crée des problèmes de cohérence des données dans Slife.
Comme on s'y serait attendu, Slife stocke ses données dans une base de données SQLite (en tout cas sous Mac OS X). SQLite est un moteur de bases de données SQL, léger et rapide. Contrairement à MySQL ou autre, vous n'avez pas besoin qu'un serveur tourne en permanence pour accéder aux données. C'est aussi ce moteur qui est utilisé par Spotlight.
Il est possible de rentrer dans des bases de données SQLite directement avec les outils fournis dans Mac OS X. Il faut pour cela lancer l'application Terminal, et taper au prompt :

sqlite3 "Library/Application Support/Slife/db20.slife"

ce qui retourne :

SQLite version 3.4.0
Enter ".help" for instructions
sqlite>

On peut ensuite taper :

.databases

ce qui doit donner quelque chose de ce genre, modulo votre nom d'utilisateur :

seq  name             file
---  ---------------  ----------------------------------------------------------
0    main             /Users/patpro/Library/Application Support/Slife/db20.slife

Posons maintenant que vous souhaitiez supprimer tous les événements enregistrés dont le titre contient SuperJob.fr, car vous ne voulez pas que votre patron soupçonne que vous préparez votre départ.
La première étape pour ne pas faire de bêtise c'est de quitter Slife car être deux (Slife et vous) en train d'éditer la base de données au même instant pourrait être fâcheux. Après avoir quitté Slife, faites une copie de sauvegarde du fichier db20.slife.
La seconde étape consiste à afficher sans les détruire les événements ciblés. On utilise pour cela l'instruction SQL SELECT. Au prompt sqlite> tapez :

SELECT * FROM ZITEMRECORDED WHERE ZNAME LIKE "%SuperJob.fr%";

Après validation, vous allez obtenir un listing de tous les enregistrements qui contiennent "SuperJob.fr" dans le titre :

10|2478|1|2008|7|10|30|34.0|Safari||aide mobilité site:SuperJob.fr - Google Search
10|2479|2|2008|7|10|30|8.0|Safari||SuperJob.fr, numéro 1 de l’emploi en ligne
10|2480|1|2008|7|10|30|9.0|Safari||Bulletin Officiel de SuperJob.fr n° 2002-2

Lisez bien tous les titres pour vérifier que vous n'allez pas supprimer des événements qui ne devraient pas l'être.
Si c'est bon, vous pouvez lancer le DELETE :

DELETE FROM ZITEMRECORDED WHERE ZNAME LIKE "%SuperJob.fr%";

Vous pouvez, à l'issue de ce DELETE, refaire le SELECT pour vérifier qu'il ne reste rien. Mais il n'y a aucune raison qu'un enregistrement ait échappé au DELETE.

Ensuite, vous quittez SQLite en tapant au prompt .quit, puis vous pouvez relancer Slife et vérifier que les enregistrements incriminants ont disparu.

Pour ceux qui sont désespérément allergiques au terminal, il existe une paire de clients graphiques pour accéder à des bases SQLite. J'ai testé rapidement SQLite Database Browser 1.3, et à première vue il donne satisfaction. Néanmoins il est compilé pour PowerPC uniquement. Je ne saurai garantir son fonctionnement sur plateforme Intel.