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 ->

192.168.0.15 -> 54.42.0.48
192.168.0.20 -> 54.42.0.43
192.168.1.15 -> 54.42.1.56
192.168.1.20 -> 54.42.1.43

En me basant sur un exemple de script Perl utilisant IP::Anonymous, j'ai créé un script qui permet en plus de rendre anonyme les adresses email, les message-IDs, et les noms de machines. Ainsi, et à condition de rester en IPv4, le script final permet de rendre totalement anonyme des logs Postfix :

   1: #!/usr/bin/perl -wT
   2:
   3: # script brodé à partir d'un exemple
   4: # trouvé en ligne sur le forum CPAN
   5: # http://cpanforum.com/posts/1304
   6:
   7: # à utiliser sous la forme :
   8: # logs_anonymes.pl fichier.log > sortie_anonyme.log
   9:
  10: use strict;
  11: $|=1;
  12:
  13: use IP::Anonymous;
  14: use Digest::MD5;
  15:
  16: # 32 integers entre 0 et 255 (jot -r 32 0 255)
  17: my @key = (135,229,13,26,29,84,46,37,231,95,211,
  18:            196,243,11,87,5,23,217,173,214,66,241,
  19:            164,67,132,149,161,151,114,137,238,75);
  20:
  21: my $obj = new IP::Anonymous(@key);
  22: my $md5 = Digest::MD5->new;
  23:
  24: # seed pour le md5
  25: my $seed = '766326241f69b1244792587f556d02b8';
  26:
  27: while(defined(my $line=<>)) {
  28:     chomp $line;
  29:     # les IP
  30:     if($line =~ /\d{1,3}(?:\.\d{1,3}){3}/) {
  31:         $line =~
  32:             s/(\d{1,3}(?:\.\d{1,3}){3})/$obj->anonymize($1)/eg;
  33:     }
  34:     # les adresses email et messageID
  35:     if($line =~ /[=< ][^@ ]*@/) {
  36:         $line =~
  37:             s/([=< ])([^@=< ]*@)/$1.$md5->add($seed)->add($2)->hexdigest."@"/eg;
  38:     }
  39:     # les hostnames
  40:     if($line =~ /([=< @])(([a-zA-Z0-9]***TRONQUÉ***|ZW)/i ) {
  41:         $line =~
  42:             s/([=< @])((?:(?:[a-zA-Z0-9]***TRONQUÉ***|ZW)/$1.$md5->add($seed)->add($2)->hexdigest.".".$3.".".$4/egi;
  43:     }
  44:     # suppression des HELO
  45:     if($line =~ /(helo=<[^>]*>)/i ) {
  46:         $line =~
  47:             s/(helo=<[^>]*>)//gi;
  48:     }
  49:
  50:     print $line."\n";
  51: }

Attention : certaines lignes du script ci-dessus sont tronquées volontairement. Cliquez ici pour obtenir le code du script fonctionnel : logs_anonymes.pl.

Pour utiliser ce script, il vous faudra installer IP::Anonymous, comme ceci par exemple :

$ sudo cpan
cpan[1]> install IP::Anonymous

Il vous faudra aussi personnaliser le contenu de @key (lignes 17 à 19), en utilisant par exemple la commande jot pour générer une liste de 32 entiers aléatoires compris entre 0 et 255 :

$ jot -r -s , 32 0 255

@key doit être gardée secrète, donc votre script devra être lisible seulement par vous.
Pour finir il faudra personnaliser le contenu de $seed (ligne 25), en saisissant la chaîne de caractères qui vous plait.
Aux lignes 40 et 42 figure une liste quasi complète des TLD, obtenue auprès de l'IANA.

Pour utiliser le script, que vous aurez rendu exécutable, il suffit de l'invoquer comme cela :

$ /chemin/de/logs_anonymes.pl fichier.log > sortie_anonyme.log

Testé sous Mac OS X 10.6 et FreeBSD 8.

Enjoy.

La sauvegarde est une des briques de la sécurité informatique. En tant que telle, elle en hérite deux caractéristiques élémentaires : c'est un compromis, et c'est indispensable.

Les seules variables réelles pour l'utilisateur se trouvent donc au niveau de ce compromis. Sauvegarder des données, cela prend du temps, de la place, éventuellement de la bande passante, c'est contraignant, cela requière de l'attention. Il faut donc faire un compromis entre ce que l'on veut sauvegarder et les moyens qu'on est prêt à mettre en œuvre.

Par exemple, il est très facile de faire une sauvegarde de toutes ses données, mise à jour toutes les heures, avec possibilité de remonter dans le temps sur un an d'historique ou plus. Vous branchez un disque dur sur votre machine, et vous configurez Time Machine (si vous êtes sur Mac, pour les autres plateformes charge à vous de trouver le logiciel équivalent). Les sauvegardes sont alors totalement automatiques.
L'accès aux données est rapide, et très simple. Mais si votre logement est cambriolé, incendié, innondé, ou que votre machine est victime d'un pirate ou d'un gros virus, vous avez toutes les chances de perdre à la fois les données de votre machine et leurs sauvegardes.
Il faut donc éloigner la sauvegarde de l'ordinateur pour assurer la sécurité de vos données. Cela se complique. On peut mettre le disque externe en lieu sûr, mais alors cela oblige à des manipulations entre chaque sauvegarde : sortir le disque de sa cachette, le brancher, sauvegarder, le débrancher, le remettre en lieu sûr... Pénible !
La solution simple est alors de passer par internet, mais c'est lent. Allez donc sauvegarder 200 Go de données via votre ligne ADSL. Et puis d'abord, où allez vous trouver autant de place ? Il faut payer un hébergement spécialisé. On en trouve des pas trop chers, mais contrairement à un disque dur, la dépense est mensuelle.
Tel que je vois les choses, il faut utiliser la sauvegarde locale cumulée à la sauvegarde distante. Plus la sauvegarde est éloignée (et donc pénible d'accès), moins je sauvegarde de données. C'est aussi simple que ça.
La seule réflexion que doit mener l'utilisateur dans ce cas de figure, est la hiérarchisation de ses données. Il doit décider parmi ses données les quelles il est inutile de sauvegarder, les quelles il est utile de sauvegarder, les quelles il est important de sauvegarder, etc.
Pour la sauvegarde locale, on est sur du disque dur. L'accès est performant, c'est de la sauvegarde de confort. On peut y placer toutes les données, même les données peu importantes.
Pour une sauvegarde intermédiaire (sur une autre machine du réseau par exemple), on est en accès relativement rapide, mais moins que le disque local, et on a aussi sans doute un peu moins de place. On va donc omettre les données peu importantes (les gros logiciels installés dont on a le CDROM dans l'étagère, les fichiers volumineux qu'on peut retrouver facilement ailleurs...).
Pour la sauvegarde hors-site (sur un serveur accessible via internet), on sait que l'accès est lent, que l'espace est compté et facturé, on doit donc se limiter à l'essentiel (emails, documents personnels, photos de famille irremplaçables, factures électroniques...).

C'est un fonctionnement en entonoir. Plus la sauvegarde est contraignante (distance, temps d'accès, coût), plus vous la limitez en volume.

À titre d'illustration, voici comment mes sauvegardes "ceinture et bretelles" fonctionnent :

- Dans mon Mac, j'ai un second disque dur qui sert pour Time Machine, j'ai donc une sauvegarde incrémentale sur plus de 2 ans de toutes mes données. Toutes les heures, Time Machine fait une sauvegarde sur ce disque. L'accès est rapide, mais le disque de sauvegarde est dans la même machine que le disque sauvegardé. Le risque de perdre les deux en même temps est maximal.

- Sur mon réseau local, j'ai une seconde machine, avec un disque dur dédié aux sauvegardes. J'ai sur le Mac un script qui se lance tous les deux jours, et qui envoie sur cette seconde machine une partie de ma dernière sauvegarde Time Machine. Cette machine a peu à craindre d'un cambrioleur ou d'un pirate, rien à craindre des virus, mais un sinistre pourrait lui être fatal. L'accès est plus lent qu'un disque local, mais plus rapide que via internet.

- Ensuite, le même script envoie sur un serveur distant, au travers de ma liaison ADSL, un sous-ensemble encore plus petit de ces données. Et ce serveur distant garde l'historique des données une fois par semaine pendant 20 semaines. Je peux donc revenir en arrière de 5 mois sur les données sauvegardées.
Ce serveur est à 400 km, dans un datacenter sécurisé. La probabilité pour que mes deux sauvegardes "maison" et cette sauvegarde distante disparaissent en même temps est nulle.

L'intégralité des trois étapes est bien sûr entièrement automatisée, et tout fonctionne sans intervention humaine. C'est primordial. Si vous utilisez un système de sauvegarde manuelle, vous pouvez être sûr qu'un jour vous oublierez, ou vous vous lasserez.

Pour résumer tout ceci en une ligne : ayez toujours une sauvegarde locale pour votre confort, et une sauvegarde distante pour les données vraiment importantes. Si vous réfléchissez à cela sérieusement, cela vous forcera aussi à considérer l'ensemble de vos habitudes de stockage : qu'est ce que je stocke sur ma machine ? Est-ce vraiment utile de garder tout ça ? Qu'est ce que je peux supprimer ou perdre sans états d'âme ? etc.

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.

• Vous devez installer Wireshark sur votre machine (A)
• Vous devez aussi pouvoir vous connecter en root via SSH sur la machine que vous voulez utiliser pour la capture (B)

Dans un premier temps, il s'agit de créer un socket UNIX via mkfifo. C'est ce socket que votre Wireshark va lire en local sur la machine A.

mkfifo capture.fifo

Dans un deuxième temps, il faut ouvrir une connexion SSH de A vers B, lancer tcpdump dans cette connexion, et rediriger la sortie standard dans votre tout nouveau socket.

ssh root@machineB tcpdump -s 0 -U -n -w - -i ath0 >  capture.fifo

Remplacez ath0 par le nom de l'interface réseau qui vous intéresse, et éventuellement, ajoutez aux options de tcpdump les filtres adéquats pour affiner votre analyse.
Attention, pour une connexion avec mot de passe, ssh ne vous demandera le fameux sésame qu'au moment où Wireshark ouvrira le socket. C'est à dire à l'étape suivante.

Dans un troisième et dernier temps, vous pouvez lancer Wireshark sur la machine A si ce n'est déjà fait, et le configurer pour lire votre socket capture.fifo. Pour cela, ouvrez les options de capture, et saisissez le chemin de votre socket dans le champ "interface" :

Enfin, cliquez sur "Start" pour lancer la capture, et si nécessaire, tapez votre mot de passe pour la machine B dans la fenêtre de terminal où votre connexion SSH est établie.

Configurez votre serveur web en mode "production", de sorte qu'il n'affiche pas sa version ni la version des modules chargés. Sur Apache, cela se passe dans le httpd.conf sous la forme ServerTokens Prod.
Ainsi, votre serveur est identifié sous le nom Apache au lieu de Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.7l DAV/2 PHP/5.2.8 SVN/1.4.4

Si c'est possible, configurez votre firewall pour qu'il ne laisse pas sortir l'utilisateur "apache" (en général www, ou httpd), sur d'autres ports que les ports 80 et 443. Sous PF (freebsd/openbsd) cela peut se faire comme ceci :

pass out quick proto tcp from any port 80 to any user 80 keep state
pass out quick proto tcp from any port 443 to any user 80 keep state
block out log proto { tcp, udp } user 80

Si vous ne pouvez pas faire ce blocage dans le firewall, faites au moins en sorte que votre interpréteur ne puisse pas ouvrir de sockets, ni accéder à n'importe quel fichier du serveur.

Configurez votre interpréteur (souvent PHP) pour ne pas retourner les erreurs. Au pire, créez un virtual host de développement pour vous-seul, qui affiche les erreurs, et assurez vous que les erreurs ne s'affichent pour personne d'autre. Utilisez log_errors = On dans votre php.ini pour enregistrer les erreurs dans un fichier désigné par error_log = /var/log/php_error.log.

Ne faites jamais confiance à l'utilisateur. Il arrivera toujours un moment où il va tripoter l'URL pour changer un paramètre, il peut aller jusqu'à modifier un formulaire pour injecter du code SQL dans une variable postée.
Ne faites pas confiance à javascript pour contrôler la validité des données. Contrôlez toujours côté serveur que les nombres sont des nombres, les chaînes de caractères sont bien ce qu'elles doivent être…
Si vous devez transmettre des données importantes via cookie/url/autre, n'hésitez pas à les chiffrer, ou à les accompagner d'un hash pour détecter une altération éventuelle.
Le referer (l'URL de provenance) est une donnée fournie par l'utilisateur. Ne bâtissez aucun système de sécurité à partir du referer.

Ne vous méprenez pas, il est possible d'attaquer un serveur (par injection SQL notamment) en aveugle. Même si aucune erreur n'est retournée par PHP, la page sans injection sera différente de la page avec injection, et cela suffit en général pour savoir si le code injecté est bien interprété. Il est donc vraiment vital de contrôler les données envoyées par l'utilisateur.
Par essais successif, il peut être possible de lire des informations dans la base de données. Par exemple, on peut créer une injection SQL qui va juste comparer le Nième caractère d'un champ de la table avec un caractère qu'on propose. Il suffit de faire en sorte que la requête SQL échoue si le caractère est juste et ne fasse rien si le caractère n'est pas le bon (ou inversement). Suivant la page html obtenue, même sans affichage d'erreur, on saura quel caractère est en quelle position dans le champs de la table.
Imaginons que mon champ contienne un mot de passe en clair de 10 caractères (c'est MAL). Cela fait un maximum de 10x255 caractères à tester, si on s'en tient à l'ASCII. Via injection SQL, j'aurai donc au maximum 2550 tests à faire pour trouver le mot de passe de 10 caractères. Si je décide non pas de tester le caractère, mais plutôt les bits qui constituent ce caractère, je n'ai plus que 8 tests à faire. En 80 tentatives au maximum, je trouve le mot de passe. Rapide, efficace, et surtout sensiblement plus discret.

Pour plus de simplicité, je laisse periodic lancer le script chaque nuit vers 3h15. Je crée donc un fichier /usr/local/etc/periodic/daily/310.spamhaus_dropall exécutable, et en lecture uniquement (sauf pour root).

Je dois aussi créer une table spamhaus_dropall dans la configuration de PF en ajoutant les lignes suivantes à mon /etc/pf.conf :

Dans les définitions de tables :

table <spamhaus_dropall> persist { }

Dans les règles proprement dites :

block in log quick proto tcp from <spamhaus_dropall> to any

Cette table, vide par défaut, va stocker le contenu filtré de la liste DROP, et sera mise à jour toutes les nuits.
Ensuite je force pf à relire la configuration par la commande pfctl -vf pf.conf.

Voici le code du script, à écrire dans /usr/local/etc/periodic/daily/310.spamhaus_dropall :

#!/usr/local/bin/bash
echo  downloading/cleaning blacklist drop.lasso
TMPFILE=`mktemp /tmp/drop.XXXXXX` || exit 1

/usr/local/bin/curl -s http://www.spamhaus.org/drop/drop.lasso | \
    sed 's, ;.*,,' | \
    egrep '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}*$' > \
    ${TMPFILE}

echo  flushing the spamhaus_dropall table
egrep -v '^127|^WHITELIST' ${TMPFILE} | \
    pfctl -t spamhaus_dropall -vT replace -f -

La première étape consiste à télécharger la liste. Dans la foulée, les commandes sed et egrep me permettent de nettoyer et filtrer le contenu du fichier envoyé par Spamhaus.
Le fichier original ressemble à ceci :

; Spamhaus DROP List 11/24/08 - (c) 2008 The Spamhaus Project
116.199.128.0/19 ; SBL56563
116.50.8.0/21 ; SBL54501
128.199.0.0/16 ; SBL62478

Le fichier filtré et nettoyé, dont le contenu est écrit dans le fichier temporaire TMPFILE ressemble à cela :

116.199.128.0/19
116.50.8.0/21
128.199.0.0/16

L'étape suivante consiste à injecter les nouveaux blocs d'IP dans la table pour les faire prendre en compte par le firewall. Par mesure de précaution, j'ai choisi de filtrer ici les IP de la classe 127.0.0.0/8 ainsi que toutes les IP dont je ne veux absolument pas qu'elles figurent dans la blacklist. On n'est jamais à l'abri d'un dysfonctionnement de Spamhaus, ou du script, ou d'une malveillance locale sur la machine. Je remplace donc ^WHITELIST par tous les préfixes d'IP que je juge nécessaire (par exemple ^83.225. si mon IP résidentielle commence par "83.225"), et je les sépare par un |.
La commande egrep -v me permet donc d'exclure toutes les lignes que je veux sortir de la liste, et envoie le reste à pfctl pour remplacer le contenu de la table spamhaus_dropall par les nouvelles IP.

Voici un exemple de sortie, telle qu'elle apparaît dans le mail de daily :

downloading/cleaning blacklist drop.lasso
flushing the spamhaus_dropall table
8 addresses added.
1 addresses deleted.
A  192.43.153.0/24
A  192.43.154.0/23
A  192.43.156.0/22
A  192.43.160.0/24
A  192.86.85.0/24
A  78.157.128.0/19
A  91.209.14.0/24
A  94.176.96.0/20
D  94.176.96.0/21

Le script est bien sûr perfectible. Mais c'est une base de travail qui fonctionne.