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 :
- signlogger pour la signatrue des logs
- signvalidator pour la validation des logs
Loading ...