2012 Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archive for 2012

Niveau :      
Résumé : syslog | openssl dgst

Vous êtes vous déjà posé la question de la sécurisation de vos logs ? Sont-ils accessibles ? modifiables ? Peut-on détecter une falsification ?

Comment faire pour que les logs ne soient pas altérés par une personne de peu de principes ? Je vous propose une solution qui n'est pas une solution miracle, mais c'est une solution qui sera une brique de plus dans votre défense en profondeur.

Nous allons signer cryptographiquement les logs pour que tout altération devienne visible comme le nez au milieu de la figure.

Signature et validation des logs

Je vous au préparé pour cela deux programmes (lien en fin d'article), l'un pour signer les logs, l'autre pour les valider. Bien sûr, on ne va pas signer les fichiers de logs directement, ça laisserait tout le temps à un attaquant de les modifier avant la signature. Nous allons plutôt nous insérer dans le système syslog pour disposer des lignes au fur et à mesure. Mais nous n'allons pas non plus signer toutes les lignes, ce serait trop lourd. Nous allons plutôt signer des blocs de lignes, par exemple une signature toutes les 100 lignes, sans oublier un timeout pour éviter que 99 lignes restent en mémoire trop longtemps..

Enfin une des fonctionnalités importante de ces outil est le chaînage. Le chaînage est le fait d'utiliser la signature du bloc précédent comme faisant partie du bloc suivant. Ceci garanti qu'il ne peut y avoir suppression ou ajout d'un bloc eu milieu d'une chaîne de blocs. Et tant qu'on y est nous pouvons aussi chaîner les fichiers pour obtenir le même résultat au niveau fichier.

Au final toute modification, ajout ou suppression de ligne entraine l'invalidation de la signature. Toute modification, ajout ou suppression de bloc ou de fichier de log entraine l'invalidation de la signature.

Voici donc un exemple d'usage sous forme de pipe :

$ openssl genrsa -out key.pem 1024 # il nous fait une clé de signature
$ echo "Log important" | signlogger -k key.pem -f logfile

Notez que c'est utilisable avec syslog puisque celui-ci vous permet d'utiliser un pipe à la place d'un fichier. Je ne détaille pas cela ici car cela dépend du sylog que vous utilisez (syslogd, syslog-ng, rsyslog ...).

Et pour vérifier que votre fichier de log n'a pas été modifié ?

$ openssl rsa -in key.pem -pubout > pubkey.pem # on récupère la version publique de la clé
$ signvalidator -k pubkey.pem -f logfile

Si vous voulez utilisez cet outil avant logger ou avant l'envoi à un serveur centralisé, il faudra modifier signvalidator pour qu'il ignore les éléments ajoutés par syslog dans la vérification de la signature (date, pid, ...).

Usage

Dans la vraie vie quand on parle de sécurité, il faut se demander de quoi on veut se prémunir.

Signer les logs a pour but d'éviter qu'on puisse modifier les logs a posteriori, puisqu'on n'empêche personne de transformer les logs avant qu'ils ne soient envoyés à syslog. Mais toute personne qui a accès en écriture aux logs a posteriori, a les mêmes droits que le processus qui écrit les logs. Il a donc accès au système de signature.

Mais alors qu'a-t-on gagné ?

Tout d'abord, un difficulté légèrement accrue pour un attaquant, c'est pas grand chose, mais ça peut toujours servir. Ensuite, il nous suffit maintenant de séparer les droits du système de chiffrement de ceux du système d'écriture pour enfin détecter la modification par une personne possédant les droits d'écriture.

Pour cela vous avez plusieurs moyens à votre disposition :

  • utiliser des pipes et des des utilisateurs séparés pour la signature et pour l'écriture
  • utiliser l'attribut append only des fichiers de log pour interdire toute modification du fichier a posteriori (sauf par root qui peut retirer l'attribut)
  • utiliser un medium read only pour écrire les logs
  • utiliser un HSM pour interdire la réutilisation de la clé
  • déporter les logs vers un serveur syslog

Ou toute combinaison de ceux-ci.

Vous remarquerez que ces techniques ont déjà pour but d'empêcher la modification des logs a posteriori. La signature n'apporte qu'une preuve supplémentaire.

Mais prenez l'exemple du serveur syslog centralisé. On ne peut plus modifier les logs depuis le client, mais on le peut toujours depuis le serveur. La signature, si elle est effectuée côté client permet d'apporter une garantie supplémentaire puisqu'il faut cette fois un accès coté client ET côté serveur pour effecture la modification.

Si on y ajoute l'append only, il faut être root, si on y ajoute le HSM, il faut disposer d'une carte à puce ou d'un mot de passe, si on y ajoute un media read only, il faut disposer d'un accès physique pour le modifier. Et chacun de ces éléments peut être géré par une personne différente pour rendre impossible toute modification par une unique personne malintentionnée.

A vous de choisir votre niveau de sécurité !

En détail

Je vous colle ici l'usage complet des commandes (c'est du perl pour ceux qui veulent savoir)

$ signlogger --help
Usage:
    signlogger [options]

      Options
            --key|-k keyfile         Use private key for signing (PEM encoded)
            --file|-f file           Log to file instead of stdout
            --lastsig|-l line        Use line as last signature (used for chaining)
            --initfile|-i file       Use last line of file as last signature (used for chaining)
            --blocksize|-b lines     Insert signature each "lines" count (default 50)
            --timestamp|-t seconds   Insert signature each "seconds" seconds (default 30mn)
            --help|-h                This help

$ signvalidator --help
Usage:
    signvalidator [options]

      Options
            --key|-k keyfile        Use public key for validation (PEM encoded)
            --file|-f file          Read file instead of stdin
            --lastsig|-l line       Use line as last signature (used for chaining)
            --initfile|-i file      Use last line of file as last signature (used for chaining)
            --help|-h               This help

Et pour les télécharger :

Niveau :      
Résumé : trap DEBUG ; PROMPT_COMMAND

Voici comment loguer l'activité d'un utilisateur.

Mais tout d'abord, commençons par apprendre comment envoyer une ligne dans syslog. C'est simple, il suffit d'appeler logger avec les options qui vous intéressent (toutes optionnelles) et un message :

$ logger -i -p local5.info -t bash "$(tty): Bonjour syslog"

On enregistre le pid (option -i) pour permettre la corrélation avec d'autres lignes de logs.

On utilise la facility local5 qui est une sorte de tag utilisé par syslog pour savoir dans quelle catégorie mettre les logs. Les facilities servent essentiellement à faire des règles de tri des logs (par exemple il y a une facility authpriv pour tout ce qui est authentification). Il y a 8 facilities disponible pour les administrateur qui voudraient utiliser des valeurs qui ne sont pas standard. J'ai choisi local5.

On utilise le niveau de log info qui est quelque chose de standard parmi les systèmes de logs en général et permet de filtrer facilement.

On en profite pour loguer le tty en cours pour permettre une corrélation avec la commande last (on ne sait jamais).

Nous avons aussi besoin de la commande capable de nous donner la dernière commande tapée :

# lister la dernière commande sans son numéro
$ fc -ln -1

Il n'y a plus qu'à mettre l'une de ces lignes dans le fichier /etc/profile qui est lu par bash au lancement de sessions interactives :

# envoyer la commande dans syslog pour chaque commande AVANT exécution
$ trap 'logger -i -p local5.info -t bash "$USER $(tty): $(fc -ln -1)"' DEBUG

# envoyer la commande dans syslog pour chaque commande APRES exécution
$ PROMPT_COMMAND='logger -i -p local5.info -t bash "$USER $(tty): $(history 1)"'
# fc ne marche pas correctement dans PROMPT_COMMAND

Pourquoi

Enregistrer cette info peut être utile puisque les logs ne sont pas modifiables par un utilisateur simple. Et si vous avez un serveur syslog centralisé, ils ne le sont même pas par root depuis la machine d'origine.

Mais ceci ne doit pas vous faire oublier eux choses.

Tout d'abord le shell est un processus lancé par l'utilisateur, ce qui veut dire que l'enregistrement de cette information est nécessairement soumis à la bonne volonté de l'utilisateur. Un utilisateur peut supprimer le trap ou remplacer le PROMPT_COMMAND. Et supposons que vous trouviez un moyen pour l'en empêcher, l'utilisateur peut toujours tuer son propre shell, lui faire faire un exec vers un autre shell n'ayant pas de logs, tracer son shell pour modifier son activité etc.

Ensuite il faut être bien conscient de ce qu'on enregistre. On enregistre l'activité interactive d'un shell. Ceci exclue les transferts de fichiers (scp,...), les exécutions automatiques (cron, ...), les exécutions via un code (vi script; ./script). Et si on regarde bien ce dernier cas, on comprend qu'à moins de loguer tous les appels systèmes avec tous leurs paramètres, il est impossible de garantir qu'un utilisateur malveillant n'a pas exécuté une commande.

En conclusion ce système n'est pas là pour garantir l'enregistrement de toute activité d'un utilisateur plus ou moins malveillant, mais ça peut être une piste de recherche parmi d'autres lorsqu'un problème survient (qui a supprimé ma libc ?).

Niveau :      
Résumé : debsums ; dpkg -S ; apt-get install --reinstall

Si vous avez bidouillé une debian en installant un logiciel sans passer par dpkg par exemple, ou si quelqu'un vous a fait une mauvaise blague et qu'il y a des problèmes dans les logiciels installés, alors il y a un moyen pour vérifier si le problème vient d'un fichier modifié :

$ apt-get install debsums
$ debsums -c

Debsums est un outil debian qui fait un hash de tous les fichiers installés par des paquets debian et le compare au hash provenant du paquet original. L'option -c permet de lister tous les fichiers qui posent problème. Cela ne vous prémunit pas des attaquants qui pourraient aussi modifier la base des paquets, mais c'est utile pour toute manipulation plus ou moins volontaire du système.

Une fois la liste des fichiers modifiés récupérée, il nous reste à trouver dans quel paquet se trouvait le fichier en question :

$ dpkg -S /bin/ls # nous indique que ls est dans le paquet coreutils

Et maintenant passons à l'étape réparation :

# retélécharge et réinstalle tous les binaires d'un paquet déjà installé
$ apt-get install --reinstall lepaquet

Et pour ceux qui voudraient faire une réinstallation complète de leur distribution :

$ dpkg --get-selections | grep install | awk '{print $1}' | xargs  apt-get install --reinstall --yes

Mais comme dit le commentaire ci-dessous cela ne marche que si vous ne faite pas de pinning et si votre distribution est à jour. La commande suivante permet de ne pas changer les versions des paquets :

$ dpkg -l | grep ^ii | awk ‘{print $2″="$3}’ | xargs apt-get install -reinstall -s -t release-cible

Niveau :      
Résumé : atime, ctime, mtime, crtime

Je constate que je n'ai jamais fait d'article sur les dates de fichier, c'est bien dommage car on me pose souvent la question. Voila qui va régler ce malentendu.

ctime et mtime

Unix depuis très longtemps ne stocke pas la date de création d'un fichier (contrairement à windows). A la place il stocke 3 dates au format timestamp unix. Les plus difficiles à comprendre sont mtime et ctime. Mais en réalité c'est simple, il suffit d'apprendre leur nom :

  • mtime : modification time, date de dwœernière modification du contenu du fichier
  • ctime : change time, date de dernier changement des métadonnées du fichier (par exemple le propriétaire)

Rien que pour vous, j'ai un moyen antimnémotechnique : M comme Contenu et C comme Métadonnée. Je ne sais pas vous, mais moi ça marche.

Attention, la modification du contenu d'un fichier modifie sa date de modification, qui est une métadonnée ... Elle modifie donc aussi sa date de changement. En conséquence de quoi on a toujours ctime >= mtime.

atime

Historiquement unix a eu l'idée originale de stocker la date de dernier accès à un fichier, le atime (access time). Ça a l'air cool, mais en réalité c'est une fausse bonne idée car elle interfère avec la notion fondamentale de lecture. En effet, pour mettre à jour le atime, chaque lecture impliquera une écriture.

Plus le temps passe plus le atime est problématique. Ça a commencé avec les sites web qui avaient des problèmes de performance à cause de la mise à jour du atime lors de la lecture des fichiers. On a alors inventé la possibilité de désactiver le atime au montage (option noatime).

Puis ça continue avec le SSD, écrire le atime implique une écriture toute petite à chaque lecture de fichier, ce qui implique la modification d'un inode et donc d'un block disque. Et avec le fonctionnement du SSD cela implique la lecture et la réécriture d'un gros bloc de données, donc des problèmes de performances. Puisque le atime reste utilisé par quelques applications (aussi rares soient-elles), on a inventé l'option relatime, qui ne met a jour le atime que s'il était égal ou antérieur au ctime. Ça permet de détecter une lecture depuis la dernière modification tout en faisant sauter un grand nombre de mises à jour du atime (mais pas toutes).

Le problème suivant intervient avec les snapshots, lorsqu'on utilise des snapshots de disques (à travers LVM ou à travers un serveur de VM), on se retrouve à mettre à jour le disque de snapshot et donc occuper de l'espace disque rien qu'en le lisant. Le summum étant atteint avec btrfs. Si vous faites un snapshot avec btrfs il ne vous prendra quasiment aucune place sur le disque. Si vous faites un find sur ce snapshot, la mise à jour du atime va quasiment remplir l'espace disque du snapshot d'une copie complète des données originales.

Conclusion, oubliez le atime ...

crtime

Comme je vous l'ai dit, windows stocke la date de création, c'est donc tout naturellement que les linuxiens ont voulu la même fonctionnalité. C'est enfin chose faite avec ext4. En effet, ext4 a profité de l'agrandissement de la taille des inode (de 128 à 256) pour stocker plus d'informations, celles-ci incluent la date à la nanoseconde près et la date de création.

Cool, mais comment fait-on ?

Malheureusement, les outils habituels n'ont pas encore été mis à jour pour récupérer cette information. Il nous faut donc le faire à la main :

# d'abord on récupère le numéro d'inode du fichier
$ stat --format "%i" /chemin/vers/le/fichier
# puis on récupère la date de création
$ debugfs -R 'stat <123456>' /dev/partition | grep crtime

Notez que ça ne marche que sur des partitions ayant des inodes de 256 octets, ce qui exclue les systèmes de fichiers mis à jour depuis ext2 et ceux venant d'un ext3 avec des inodes de 128 octets.

Niveau :      
Résumé :

Petit problème pour le plaisir.

Problème

Nous voulons créer un algorithme, voire une formule arithmétique simple, nous permettant de générer des nombres entiers ayant la propriété suivante : pour tout x, l'ensemble des chiffres de l'ensemble des nombres générés inférieurs à x doit être distribués équitablement.

Équitablement signifie que chaque chiffre doit apparaître autant de fois que chaque autre plus ou moins le nombre de chiffres de x.

Prenons un exemple pour bien me faire comprendre :

  • Soit x = 100
  • Prenons l'ensemble des nombres entiers inférieurs à x : 0-99
  • Écrivons les sur 2 chiffres (1=01) et prenons tous les chiffres

Nous avons alors 20 fois le chiffre 0 (10 fois coté dizaines, 10 fois coté unités), 20 fois le 1 ...

Donc c'est équilibré, nous sommes contents.

Prenons x = 99, nous avons tous les nombres sauf 99, donc 20 chiffres de chaque sorte et seulement 18 fois le 9. Deux de moins que les autres or 2 est le nombre de chiffres de x.

Donc c'est équilibré, nous sommes contents.

Prenons x=90, nous n'avons que 9 fois le 9 et 19 fois le 0, ce n'est pas équilibré.

Par conséquent la formule que nous cherchons c'est pas f(x)=x mais quelque chose qui prend une suite logique de nombres mais pas dans l'ordre naturel, comme le fait le code de gray.

Mais pourquoi ?

Pendant que vous réfléchissez, je vais vous expliquer la raison du problème. Lorsque vous câblez une salle machine, vous utilisez de nombreux câbles. Pour une bonne gestion de ces câbles, qui vont rapidement être emmêlés avec d'autres une fois branchés, il faut les identifier pour repérer facilement les 2 bouts d'un même câble.

Une première solution est d'utiliser patchsee, sympa quand on a les moyens et qu'on n'a encore installé aucun câble, mais elle ne marche pas pour notre stock de câble existant.

Une autre solution est d'étiqueter les câbles, mais les étiquettes papier même plastifiées ont tendance à s’abîmer, s'effacer et sont difficilement repérables de loin. On les remplace donc parfois par des clips de repérage.

Malheureusement, nous sommes soumis à la terrible loi de Benford. Appliquée au clips, elle nous condamne a acheter beaucoup de 1, un peu moins de 2, encore moins de 3 etc ... Or ils sont vendu par lots ayant la même quantité de chaque chiffre, drame lorsque vous voulez étiqueter 200 ou 2000 câbles.

La solution : répartir les chiffres de façon à n'acheter que ce que vous consommez. C'est ce que que j'ai décrit d'une façon un peu plus formelle précédemment.

La réponse

Alors vous avez réfléchi ?

Évitez de vous précipiter sur la solution, elle est simple et vous pouvez la trouver.

J'ai dû faire plusieurs essais et quelques calculs pour trouver.

Il y a plusieurs solutions.

Mais très peu de solutions sont simples et faciles à expliquer à celui qui devra utiliser ce système après vous.

La solution que je propose ne nécessite pas de formule compliquée.

Vous avez trouvé ?

Voici ma solution :

  • 00, 11, 22, 33, 44, 55, 66, 77, 88, 99
  • 10, 21, 32, 43, 54, 65, 76, 87, 98, 09
  • 20, 31, 42, ...

Vous voyez le pattern ?

A un nombre à 2 chiffres N=(x)(y) j'associe le nombre M=(x+y)(y) en ne gardant qu'un seul chiffre à chaque opération bien sûr. A un nombre à 3 chiffres N=(x)(y)(z) j'associe le nombre M=(x+y+z)(y+z)(z) etc.

  • Pour faire le 35e nombre je prends le 5 (.5) j'ajoute 3 et je mets le résultat à gauche : 85
  • Pour faire le 125e nombre je prends le 5 (..5) j'ajoute 2 et je mets le résultat à gauche (.75) j'ajoute 1 et je mets le résultat à gauche : 875
  • Pour faire le 589e nombre je prends le 9 (..9) j'ajoute 8 et je mets le résultat à gauche (.79) j'ajoute 5 et je mets le résultat à gauche : 279

Les nombres sont équilibrés car pour chaque série de 10 on a 10 chiffres différents aux unités, 10 chiffres différents aux dizaines ...

De plus ça marche pour le nombre de chiffres que vous voulez, vous pouvez étiqueter 25000 câbles avec cette méthode. Et Vous pouvez même changer de nombre de chiffres en cours de route, coder les 100 premiers nombres sur 2 chiffres et les 900 suivants sur 3 chiffres comme avec les entiers naturels.

Conclusion

Il n'y a pas de petites économies !

D'ailleurs, à ceux qui utilise le codage des nombres naturels, je récupère gracieusement tous les 7, 8 et 9 dont vous n'avez plus usage ! Il me suffira d'adapter le codage en base 3 pour les réutiliser.

Les maths c'est utile parfois ...

Niveau :      
Résumé : ipset; IN A

Ceci n'est pas une amélioration de l'article précédent, mais un complément.

Un firewall basé sur le DNS

On veut être indépendant des ip utilisées par les gens que l'on filtre. On se propose cette fois de faire des règles de filtrage basées sur le forward DNS et non plus le reverse DNS.

Cette fois, on ne peut plus utiliser l'IP du paquet pour récupérer le nom de domaine, mais on peut mettre au jour automatiquement les règles de firewall en fonction d'un domaine défini et non plus avec des IP statiques.

Encore une fois, les précautions précédentes s'appliquent :

  • on base une règle sur quelque chose qu'on ne maitrise pas, voire qu'un attaquant pourrait maitriser : la base dns de la source
  • on devient dépendant du résolveur dns et donc de ses failles

Mais à la différence de la dernière fois, le dns est potentiellement sous contrôle d'un ami (si on parle de whitelist et non de blacklist). De plus on peut imaginer utiliser DNSSEC pour gagner en sécurité.

Changeons de technologie. Puisque nous ne faisons plus de reverse DNS, nous devons connaître à l'avance l'intégralité des domaines. Donc on ne peut plus avoir de regex ou de wildcard. Et puisque nous devons les connaître à l'avance, nous pouvons juste faire des requêtes, stocker les IP résultantes et les utiliser directement dans le firewall.

La technologie du jour s'appelle donc ipset. Elle permet d'utiliser un pool d'ip que l'on peut faire varier dynamiquement dans une règle iptables.

Iptables

Son usage est simple :

# on ne matche que sur l'ip source
iptables -A ... -m --match-set chezmoi.com src -j ...
# on matche sur un couple source/destination
iptables -A ... -m --match-set friendzone src -j ...

Ensuite il suffit de créer les set

ipset --create chezmoi.com iphash
# ip ipset create chezmoi.com hash:ip  (pour ceux qui ont une ancienne version d'ipset)
ipset --create friendzone iphash
# ip ipset create friendzone.com hash:ip  (pour ceux qui ont une ancienne version d'ipset)

Règles en live

Il ne nous reste plus qu'à mettre à jour les set dynamiquement, par exemple en interrogeant régulièrement les serveurs dns.

# on utilise un ipset temporaire pour que le firewall continue de fonctionner pendant nos opérations
ipset --create temp iphash

for rule in rules
do
    ipset --flush temp
    for i in domains[$rule]
    do
        host $rule | 
        xargs ipset --add $rule $ip
    done
    ipset --swap temp $rule
done

ipset --destroy temp

Il n'y a plus qu'a lancer ce script régulièrement grâce à notre ami cron.

Et voila !

Notez qu'il y a moyen avec ipset de matcher plusieurs adresses à la fois (ip, mac, source, destination), de matcher des réseaux et même de matcher des ports.

Niveau :      
Résumé : perl, libipq, IN PTR

Le problème

Les firewall ne proposent jamais de faire une règle qui couperait la connexion en fonction du domaine de l'appelant. C'est gênant car on aimerait bien pouvoir devenir indépendant de l'ip de notre partenaire.

Si on ouvre un accès à un ami, pourquoi devrait-il nous avertir lorsqu'il change d'ip alors qu'il a fait correctement son travail en mettant à jour son DNS.

En réalité il y a de bonnes raisons à cela, en effet le domaine ne se trouve pas dans le paquet il faut donc aller le chercher quelque part. Et cela implique :

  • qu'on base une règle sur quelque chose qu'on ne maîtrise pas, voire pire, qu'un attaquant pourrait maîtriser : la base dns de la source
  • qu'on devient dépendant du résolveur dns et donc de ses failles
  • qu'il est possible que le firewall empêche le firewall d'aller chercher l'info sur le serveur dns
  • qu'il faut attendre que le dns réponde et donc les performances d'un tel firewall risquent d'être catastrophiques

Les deux derniers problèmes sont purement techniques et ont donc une solution technique acceptable moyennant quelques compromis. Par contre les deux premiers problèmes concernent la sécurité et il faut donc garder en tête que si on met en place une telle règle, elle est là pour nettoyer les flux qui traversent notre firewall, mais qu'elle n'apporte que peu de sécurité par rapport à l'absence de règle.

La solution

Maintenant que nous savons qu'il ne faut pas le faire, voyons comment faire :-)

Tout d'abord il y a deux possibilités, se baser sur le forward DNS (IN A et IN AAAA) ou sur le reverse dns (IN PTR). Aujourd'hui je vous propose le pire des cas, le reverse DNS, puisque votre configuration est directement tributaire de la volonté de l'attaquant.

Commençons par un prototype, donc en perl, parce que je le veux bien.

Le point important ici est de faire la résolution dns en espace utilisateur. Pour cela il faut d'utiliser libipq, la bibliothèque permettant de communiquer entre l'espace utilisateur et netfilter la partie noyau du firewall linux.

Il nous faut donc :

  • libipq : IPTables::IPv4::IPQueue
  • parser les paquets ip : NetPacket::IP
  • faire des requêtes dns : Net::DNS

Et voici le script tout simple, le reste de l'article est en commentaire dans le script.


continue reading...