En complément de son application "Bien-être numérique" sortie il y a plusieurs mois, Google continue de vouloir nous aider à décrocher de nos smartphones. Pour cela, nous avons le droit à trois nouvelles applications originales.
L'objectif de Google c'est que l'on prenne conscience du temps que l'on peut passer devant son smartphone. Pour cela, l'application Screen Stopwatch va tout simplement afficher le temps passé sur son smartphone chaque jour. Comment ? En devenant le fond d'écran interactif de votre appareil. A chaque déverrouillage, le chrono va tourner sur votre fond d'écran.
Dans le même esprit, l'application Activity Bubbles intervient également au niveau du fond d'écran. A chaque fois que vous déverrouillez l'écran de votre appareil, une bulle supplémentaire s'ajoute sur votre écran. A chaque fois, plus vous passez de temps sur l'appareil, plus la bulle ajoutée sera grosse. Ceux qui ont un smartphone avec un grand écran sont avantagés 😂
Enfin, la troisième application, nommée Envelope est la plus surprenante. L'objectif est de vous faire fabriquer une petite boite, à l'aide d'une simple feuille à imprimer, et cette boîte servira à glisser votre smartphone. Lorsqu'il est à l'intérieur, il redevient un simple téléphone, vous savez celui qui est fait pour passer des appels seulement.
Pour mieux comprendre, je vous invite à regarder cette vidéo :
Ces applications sont disponibles sur le Google Play Store.
Dans ce tutoriel, nous allons apprendre à utiliser la solution AIDE (Advanced Intrusion Detection Environment). Il s'agit d'une solution de détection des intrusions basée sur les modifications apportées au système surveillé. Ce type de solution est également appelée solution de contrôle d'intégrité ou de scellement, elle vise à s'assurer qu'un ensemble d'éléments de notre système n'ont pas été modifiés, ce qui pourrait être le fruit d'une intrusion. Par intrusion, on entends bien entendu une attaque informatique qui résulterait en la compromission d'un service ou d'un serveur, cela peut alors entraîner la compromission de données, la réalisation d'actes de sabotage, la propagation d'une compromission à d'autres actifs, l’implantation durable sur le serveur compromis, etc.
Note : Il existe bon nombre de façon de détecter des intrusions grâce aux IDS (Intrusion Detecte System), certaines solutions se basent sur les journaux d’événements (appelées Log-based IDS), d'autres sur l'analyse en directe du réseau (Network-based IDS). D'autres solutions permettent elles d'effectuer automatiquement des actions de blocage ou de correction (bloquer une IP, désactiver un utilisateur, etc.) ont appelle ces solutions des IPS (Intrusion Prevention System).
Bref, nous allons aujourd'hui installer la solution AIDE, étudier son fonctionnement basique et sa configuration. Nous irons jusqu'à adapter sa configuration pour prendre en compte un nouveau service et voir comment un attaquant pourrait se faire détecter. C'est loin d'être aussi compliqué que ça en à l'air 🙂
Pour décrire le fonctionnement de la solution AIDE en quelques mots, elle va prendre une signature (sous forme de hash) des fichiers et dossiers que nous souhaitons surveiller et ensuite, pour chaque nouvelle vérification, comparer cette signature modèle à celle des fichiers analysés.
II. Installation et première utilisation
Dans le cadre de ce tutoriel, j'installe la solution AIDE sur une machine CentOS 8.1 à jour. La version d'AIDE utilisée est la version 0.16. On commence naturellement par récupérer les dernières versions des listes de paquet dans les dépôts :
[root@localhost ~]# yum update
Puis on installe la solution AIDE avec la commande suivante :
[root@localhost ~]# yum install aide
La configuration principale de la solution AIDE se situe dans /etc/aide.conf. Y jeter un œil vous fera certainement renoncer à l'utiliser (à tord, encore une fois ce n'est pas si compliqué). Nous n'allons donc pour l'instant pas nous y intéresser. Comme indiqué précédemment, la solution AIDE se base sur l'utilisation d'une base de données (ou base de signature pour être plus exact) contenant toutes les signatures (les hash, permettant le contrôle d'intégrité) des fichiers et dossiers à surveiller. Il nous est donc nécessaire dans un premier temps d'initialiser cette base (d'en créer une première version). Assurez vous d'abord d'avoir un système proche de son état "final" :
Les applications métiers sont installées
Les utilisateurs principaux sont créés
Les durcissement et outils de sécurité, de sauvegarde, de supervision sont installés également
etc.
Bien sur, un système est vivant et bougera sans cesse, par exemple lors des mises à jour. Nous verrons comment traiter ces exceptions ou ces événements un peu plus tard. Donc, l'initialisation de cette première version de base de signature se fait grâce à la commande suivante :
[root@localhost ~]# aide --init
L'opération peut prendre quelques minutes (longues minutes si vous avez un système conséquent avec de nombreux fichiers) :
[root@localhost ~]# aide --init
Start timestamp: 2020-01-18 06:41:01 -0500 (AIDE 0.16)
AIDE initialized database at /var/lib/aide/aide.db.new.gz
Number of entries: 36025
---------------------------------------------------
The attributes of the (uncompressed) database(s):
---------------------------------------------------
/var/lib/aide/aide.db.new.gz
MD5 : eyc+BLDzD6Xu4N0OkQojqg==
SHA1 : BuC3W6z+Rthf5J7OXd7n03rKMUI=
RMD160 : DPDgQUNEbZQ8lX9qd1x+AYKWjJA=
TIGER : CxJ0hk3cjH5BIL9Qu34q25wNsfvRCTqr
SHA256 : q0gCBj+Gvwvq/AFQy4HV1Jk8g/VvufxzO4blRuhtark=
SHA512 : puNw9AWyDIHkizRVUQ5vPnT5ZNaei1fQR75ruxSFZy2OMaBLvErXt/+4JDYNHXflqE3PEGgktfqKzIQ3HzwiGg==
End timestamp: 2020-01-18 06:41:09 -0500 (run time: 0m 8s)
Bien, cet affichage nous donne plusieurs informations, notre base de signature est positionnée dans /var/lib/aide/aide.db.new.gz, ensuite, les hashs (ou empreintes) de cette base de signature nous sont fournis et calculés avec plusieurs algorithmes de hashage. Cela afin d'être certains qu'aucune collision de hash (avoir le même hash pour des données différentes), n'est exploitée. Dans sa configuration par défaut, la base de signature du fichier /var/lib/aide/aide.db.gz est utilisée, les bases de signature nouvellement générées sont nommées /var/lib/aide/aide.db.new.gz comme nous venons de le voir. Il nous faut donc renommer ce fichier pour qu'AIDE retrouve ses petits :
Dans l'utilisation courante, on peut comprendre ce fonctionnement, il serait périlleux de remplacer la base de signature en cours d'utilisation, avoir un fichier différents pour les nouvelles bases de signature (estampillé "new") permet également de faire des comparatifs entre bases de signature, voire de l'archivage.
A présent, nous pouvons effectuer une première comparaison entre l'état enregistré de nos fichiers dans la base de signature et leur état actuel grâce à la l'option --check :
[root@localhost ~]# aide --check
L'opération d'AIDE est ici simple, pour chaque fichier contenu dans les dossiers et liste de fichier à vérifier, il recalcule un hash, regarde si cet objet est présent dans la base de signature, et compare les signatures :
Si la signature de l'objet n'est pas présente dans la base de signature, il s'agit d'un nouvel objet (dossier ou fichier) : on lève une alerte
Si la signature de l'objet est présente dans la base de signature et que les signatures sont identiques: tout est OK, l'intégrité de l'objet est vérifiée
Si la signature de l'objet est présente dans la base de signature et que les signatures ne sont pas identiques : on lève une alerte, le fichier a été modifié
Voici le résultat que j’obtiens dans le cadre de mes tests :
[root@localhost ~]# aide --check
Start timestamp: 2020-01-18 06:48:33 -0500 (AIDE 0.16)
AIDE found NO differences between database and filesystem. Looks okay!!
Number of entries: 36025
Pour vous montrer les types d'alertes émises lorsqu'une modification est détectée, nous allons ajouter un nouvel utilisateur dans le fichier /etc/passwd, qui est par défaut surveillé par AIDE, puis nous rééxécutons notre vérification d'intégrité :
[root@localhost ~]# useradd john
[root@localhost ~]# aide --check
Start timestamp: 2020-01-18 06:49:28 -0500 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
Total number of entries: 36027
Added entries: 2
Removed entries: 0
Changed entries: 6
---------------------------------------------------
Added entries:
---------------------------------------------------
f++++++++++++++++: /etc/subgid-
f++++++++++++++++: /etc/subuid-
---------------------------------------------------
Changed entries:
---------------------------------------------------
f ... .C... : /etc/group
f ... .C... : /etc/gshadow
f ... .C... : /etc/passwd
f ... .C... : /etc/shadow
f ... .C... : /etc/subgid
f ... .C... : /etc/subuid
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /etc/group
SHA512 : /P+yN4HGkIvuo1DbsQgfjNwpS3pfe8h1 | 1+fVfheMQ3PhIebOxtyd6dICGkpBcMZT
pHWVLZPGdzhyIcjMUi6VpZFFrYsrUrHA | f3FFiUe3MxqXroYFuMlO54V06V+zMjFyb1Rcx9Aa6//3GKggOQJVWw== | fF69GpxbTiAzsWMXckAU8Q==
File: /etc/gshadow
SHA512 : 9Ii[...]27x3Omnwr9AA==
File: /etc/passwd
SHA512 : khP[...]2KYOE1A==
File: /etc/shadow
SHA512 : Bg[...]R0w==
File: /etc/subgid
SHA512 : z4PhNX[...]TNpCg==
File: /etc/subuid
SHA512 : z4PhN[...]NpCg==
J'ai volontairement tronqué les hash des fichiers par soucis de lisibilité dans l'article. Nous voyons ici que la réponse est différente, la section "Changed entries:" contient notamment une liste de fichiers. Si l'on s'intéresse au processus d'ajout d'un utilisateur, on remarquera que ce sont les fichiers concernés lorsque l'on créé un utilisateur :
/etc/passwd contient la liste des utilisateurs du système et d'autres informations (leur home, leur description);
/etc/shadow contient les hash de mots de passe des utilisateurs;
/etc/group contient la liste des groupes et leur membres, lorsque l’on créé un nouvel utilisateur, un groupe à son nom est automatiquement créé;
etc.
En étant un peu plus attentif, nous pouvons également savoir ce qui a vraiment changé dans le fichier, est-ce sa taille, son contenu, les permissions qui lui sont affectées, les liens symboliques le concernant ? Exemple avec la ligne suivante :
f ... .C... : /etc/group;
Ici, le f indique que l'objet concerné est un fichier. Si l'on jette un œil au manuel de configuration d'AIDE (ici : manpage AIDE), on trouve l'information suivante :
Extrait de la manpage de la configuration AIDE
C'est le checksum (le hash, ou empreinte) du fichier qui a changé. Le C indique donc que c'est son contenu qui a été modifié. Maintenant que nous avons une vue sur ce qui a été modifié, il faut en faire quelque chose : investiguer.
L'objectif du contrôle d'intégrité et de s'assurer que rien n'a été modifié se notre système, toute alerte doit donc être traitée :
C'est une modification légitime, aucun problème, je sais pourquoi AIDE me lève une alerte;
Ce n'est pas une modification légitime : cela peut trahir la présence d'un attaquant.
A présent, il faut que l'on prenne en compte cette nouvelle base de signature, nous en produisons donc une nouvelle version et remplaçons l'ancienne base avec la nouvelle :
Note : AIDE n'est pas logiciel de sauvegarde, il ne vous permettra pas d'effectuer une restauration en l'état des fichiers modifiés. Les alertes qu'il émet doivent donc être traitées, et les modifications de signature acceptées après avoir été évaluées (après avoir remis les objets modifiés dans un état maîtrisé si les modifications ne sont pas légitimes).
Faisons un nouveau test avec la modification d'un autre attribut, par exemple les permissions affectées à un fichier. Dans le cadre du test, je modifie les permissions du fichier /etc/passwd (à ne pas faire en conditions réelles bien entendu) :
[root@localhost ~]# ls -al /etc/passwd
-rw-r--r--. 1 root root 1119 18 janv. 06:49 /etc/passwd
[root@localhost ~]# chmod 777 /etc/passwd
[root@localhost ~]# ls -al /etc/passwd
-rwxrwxrwx. 1 root root 1119 18 janv. 06:49 /etc/passwd
# Pour revenir à l'état initial : chmod 644 /etc/passwd
[root@localhost ~]# aide --check
Start timestamp: 2020-01-18 07:15:23 -0500 (AIDE 0.16)
AIDE found differences between database and filesystem!!
Summary:
Total number of entries: 36027
Added entries: 0
Removed entries: 0
Changed entries: 1
---------------------------------------------------
Changed entries:
---------------------------------------------------
f p.. ..A.. : /etc/passwd
---------------------------------------------------
Detailed information about changes:
---------------------------------------------------
File: /etc/passwd
Perm : -rw-r--r-- | -rwxrwxrwx
ACL : A: user::rw- | A: user::rwx
A: group::r-- | A: group::rwx
A: other::r-- | A: other::rwx
Nous avons ici une alerte concernant le fichier /etc/passwd avec comme attribut ..A... Si l'on regarde dans l'extrait de la manpage de configuration AIDE exposé plus haut, on remarque que cette alerte concerne bien les permissions d'accès à l'objet qui ont été modifiées. La section "Detailed information about changes:" nous indique quel était l'état initial des permissions des fichiers, il peut retrouver cette information à partir de sa base de signature initiale avec laquelle il compare la base de signature produite.
Nous savons à présent réaliser les opérations nécessaires à l'utilisation d'AIDE et notamment comprendre ce qu'il peut bien nous raconter au travers différents types d'alertes.
III. Utilisation quotidienne
En conditions réelles, notamment en environnement professionnel, l'implémentation d'AIDE doit être un projet à part entière car il ne suffit pas de l'installer pour que vos serveurs deviennent invulnérables, plusieurs difficultés doivent être anticipées :
Allo serveur ?
Nous savons à présent de manière basique détecter certains changement non légitimes sur nos systèmes. Cependant, ces alertes ne restent émises qu'en local et dans un cas réel, plusieurs dizaines de serveurs peuvent chacun avoir leur solution AIDE et leur signatures propres. Je vous conseille donc de faire en sorte que les serveurs soient en capacité de vous envoyer des alertes plutôt que d'attendre que ce soit vous qui alliez les constater sur chaque serveur. La première chose à faire est la création de tâches planifiées régulières qui exécuterons une vérification de la base de signature, mais qui vous avertirons également en cas de détection. Les cas les plus courants étant l'envoi d'un mail ou l'envoi d'un trap SNMP à votre solution de supervision (avec un gros voyant rouge !).
Vos serveurs sont vivants !
Une quantité importante des fichiers par défaut contrôlés par AIDE vont être modifiés régulièrement et engendrer des alertes. Qu'il s'agisse de fichiers temporaires, de configurations, de journaux d’événements... Les mises à jour, tâches planifiées et maintenance régulières des sysadmin entraîneront des modifications très fréquentes. Il faut donc anticipé une importante charge de travail (proportionnelle à votre nombre de serveur) due aux alertes que remonterons vos contrôles d'intégrité.
C'est pourquoi je vous conseille de passer par une phase d'apprentissage une fois que vos configurations seront finalisées. Cette phase consistera à avoir, dans un premier temps, un grande attention sur les alertes émises par AIDE afin de qualifier chacune d'elles et de savoir s'il s'agit d'un comporte normal ou non. Si c'est le cas, il faudra prendre le temps d'adapter la configuration à votre contexte pour que cette alerte ne soit plus émise.
Alerte rouge, qu'est ce qu'on fait ?
Je vous recommande également de créer des procédures de traitement des alertes et former vos collaborateurs à l'utilisation d'AIDE et aux opérations de maintenance que l'on vient de voir (renouvellement de la base, identification des modifications remontées par AIDE, etc.). Il n'y a rien de pire que de voir une alerte passer trahissant une potentielle attaque de ne pas savoir quoi en faire ou comment la traiter.
L'enfant qui criait au loup
Il est important de ne pas s'habituer à recevoir une alerte (importance d'avoir une phase d'apprentissage rondement menée), il serait désolant de voir que les administrateurs d'une plateforme ne prêtent plus attention aux alertes émises par AIDE car celles-ci sont soit trop nombreuses, soit systématiquement identiques. La détection d'une attaque serait alors impossible.
Attention au timing
Nous l'avons vu, la génération d'une base de signature peut prendre quelques secondes.. sur un serveur vide. Sur les serveurs de production, contenant souvent un grand nombre de fichiers (métier, journaux, configuration, etc.) la génération de la base de signature peut prendre plusieurs minutes (j'ai déjà constaté des temps d'attente de 25 minutes). Souvenez vous que l'équivalent d'une nouvelle base de signature est généré à chaque fois que vous fait un --init, mais aussi un --update ou un --check. Dans le cadre d'une vérification régulière de la signature des objets d'un système, il faut veiller à ce que la tâche planifiée n’entraîne pas une surcharge côté serveur, notamment si on lance une nouvelle vérification alors que la précédente n'est pas terminée.
IV. Ajout d'un nouveau service et configuration AIDE
Nous allons à présent creuser un peu plus la configuration d'AIDE et voir comment nous pouvons lui faire prendre en compte de nouveaux objets (dossiers/fichiers) par exemple suite à l'ajout d'un nouveau service ou d'une nouvelle application sur notre serveur.
A. Découverte du fichier de configuration
Comme indiqué précédemment, la configuration AIDE est située dans le fichier /etc/aide.conf, en voici un aperçu :
[root@localhost ~]# cat /etc/aide.conf
# Example configuration file for AIDE.
###################### PARTIE 1 ######################
@@define DBDIR /var/lib/aide
@@define LOGDIR /var/log/aide
# The location of the database to be read.
database=file:@@{DBDIR}/aide.db.gz
# The location of the database to be written.
#database_out=sql:host:port:database:login_name:passwd:table
#database_out=file:aide.db.new
database_out=file:@@{DBDIR}/aide.db.new.gz
# Whether to gzip the output to database
gzip_dbout=yes
# Default.
verbose=5
###################### PARTIE 2 ######################
# Sane
# NORMAL = R+sha512
NORMAL = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha512
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs
# Access control only
PERMS = p+u+g+acl+selinux+xattrs
# Logfile are special, in that they often change
LOG = p+u+g+n+S+acl+selinux+xattrs
# Content + file type.
CONTENT = sha512+ftype
# Extended content + file type + access.
CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs
# Some files get updated automatically, so the inode/ctime/mtime change
# but we want to know when the data inside them changes
DATAONLY = p+n+u+g+s+acl+selinux+xattrs+sha512
###################### PARTIE 3 ######################
# Next decide what directories/files you want in the database.
/boot CONTENT_EX
/opt/ CONTENT
# Admins dot files constantly change, just check perms
/root/\..* PERMS
# Otherwise get all of /root.
/root/ CONTENT_EX
# These are too volatile
!/usr/src/
!/usr/tmp/
# Otherwise get all of /usr.
/usr/ CONTENT_EX
# trusted databases
/etc/hosts$ CONTENT_EX
/etc/host.conf$ CONTENT_EX
/etc/hostname$ CONTENT_EX
/etc/issue$ CONTENT_EX
/etc/issue.net$ CONTENT_EX
/etc/protocols$ CONTENT_EX
/etc/services$ CONTENT_EX
/etc/localtime$ CONTENT_EX
/etc/alternatives/ CONTENT_EX
/etc/sysconfig CONTENT_EX
/etc/mime.types$ CONTENT_EX
/etc/terminfo/ CONTENT_EX
/etc/exports$ CONTENT_EX
/etc/fstab$ CONTENT_EX
/etc/passwd$ CONTENT_EX
/etc/group$ CONTENT_EX
/etc/gshadow$ CONTENT_EX
Alors pas de panique, c'est loin d'être aussi complexe que ça en à l'air. J'ai notamment tronqué certains commentaires qui détaillent l'utilisation des différents symboles que l'on peu voir ("!", "sha512+ftype+p+u+g+n+acl+selinux+xattrs", etc.) pour des soucis de lisibilité dans l'article. Nous allons creuser cela ensemble. On peut déjà distinguer trois parties dans cette configuration, elles sont mises en avant par mes soins dans l'extrait ci-dessus.
La définition des paramètres de configuration AIDE
La première partie permet de définir quelques éléments tels que le nom et le répertoire de stockage des bases de signature et des nouvelles bases de signatures produites (les fameux aide.db.gz, et aide.new.db.gz). On apprend via les commentaires que les bases de données AIDE peuvent également être stockées en SQL (pourquoi pas sur un serveur distant qui centralise et archive toutes ces signatures pour plus de sécurité ?). On voit également que le répertoire de stockage par défaut de ces données est /var/lib/aide/ et que les journaux d’événements d'AIDE seront stockés dans /var/log/aide.
La définition des variables d'attributs
La seconde partie de la configuration par défaut contient la déclaration de sortes de variables ou "groupes" d'attributs, regardez par exemple celui-ci :
La variable CONTENT_EX est réutilisée dans la configuration par défaut, c'est pourquoi il est intéressant de se pencher dessus. Chaque attribut est séparé par un "+", ce qui rend la lecture un peu gênante, mais considérez qu'il s'agit simplement d'un séparateur (comme un virgule dans une phrase). On peut alors décrire simplement, grâce à la documentation en ligne, à quoi sert chaque attribut :
sha512 : permet de contrôler l'intégrité, on utilisera un hash calculé avec l'algorithme de hashage SHA512;
ftype : on surveille le type de fichier (non pas grâce à l’extension, mais grâce au "magic number");
p : on surveille les permissions attribuées à l'objet ciblé;
u : on surveille si l'objet ciblé change de propriétaire;
g : on surveille si l'objet ciblé change de groupe propriétaire;
n : on surveille le nombre de liens symboliques qui ciblent l'objet ciblé;
acl : on surveille les ACL affectés à cet objet (attentions ACL et permissions, ce n'est pas la même chose !);
selinux : on surveille les attributs SELinux de l'objet ciblé (le contexte de l'objet);
xattrs : on surveille les attributs étendus de l'objet ciblé.
La définition des objets et attributs à surveiller
On trouvera en troisième partie des couples objets - variables qui servent, comme vous vous en doutez, à indiquer pour un objet spécifique (fichier ou dossier), qu'est ce que l'on souhaite surveiller. On aperçoit alors que la variable CONTENT_EX est très utilisée par défaut. Par exemple :
On retrouve dans cet aperçu une partie des fichiers qui ont été ciblés par des alertes lors d'une création d'utilisateur (/etc/shadow, et /etc/passwd). On voit ici que par défaut, AIDE surveille les attributs contenus dans la variable CONTENT_EX (décrite plus haut) pour ces fichiers. On comprend dans ces quelques lignes clairement quels fichiers on regarde et qu'est-ce que l'on y surveille.
Autres particularités
Le $ à la fin est le même $ que dans une expression régulière, vous croiserez d'autres signes d'expression régulières (activement utilisées dans la configuration AIDE), par exemple :
!/etc/.*~
Il indique que le fichier doit finir par ce nom là. ce qui évite de prendre ne compte /etc/passwd.bak au lieu de /etc/passwd par exemple.
Le "!" de la commande ci-dessus signifie "ignore ces objets". Si je veux surveiller le contenu d'un répertoire, sauf un fichier bien précis, j'écris alors :
/etc/monappli/.*!
/etc/monappli/saufce.fichier
Le "=" indique que l'on contrôlera le dossier /tmp, mais pas ses objets enfants
B. Ajout d'un application et prise en compte dans AIDE
Nous allons maintenant installer une application web basique contenant quelques fichiers statiques et de configuration. Je simule cette application à la main avec les commandes suivantes :
yum install httpd
mkdir -p /var/www/html/site1/config /var/www/html/site1/user_upload /var/www/html/site1/html
echo "nomappli=monAppliweb" >> /var/www/html/site1/config/web.conf.php
echo "Hello, déposez vos fichiers sur ce formulaire" >>/var/www/html/site1/html/index.php
chown apache -R /var/www/html/
On simule donc une application web contenant un répertoire avec ses pages web statiques, un répertoire avec les dépôts des utilisateurs (fichiers uploadés) et un répertoire avec la configuration de l'application web. Dans ce contexte, on comprend rapidement ce qui ne devra jamais être modifié (les pages web, la configuration) et ce qui va être modifié quotidiennement (le contenu du répertoire d'upload).
Faites donc un aide --check à la suite de l'installation de HTTPD, vous verrez que le nombre d'alerte que cela lève est assez conséquent, d'où l'importance de la phase d'apprentissage décrite dans la section précédente :). Pensez alors à faire une update de votre base de signature (la procédure est décrire plus haut dans ce même article).
Je vais donc vouloir créer une règle qui me permet d'être certains que rien n'est ajouté dans le répertoire racine, le répertoire de configuration et de pages web statiques, mais également que mes fichiers statiques sont intègres en étant vigilant à ignorer les modifications du répertoire d'upload de fichier. On ouvre donc le fichier /etc/aide.conf et on y ajoute le contenu suivant :
Ici, je vais essayer d'être un attaquant très maladroit et effectuer une multitude de changements. J'ajoute une backdoor PHP dans les dossiers config, user_upload et html, je modifie les permissions du fichier de configuration web.conf.php et du répertoire site1 :
On voit donc ici que deux fichiers super.backdoor.php ont été ajoutés et que les permissions du fichier /var/www/html/site1/config/web.conf.php et du répertoire /var/www/html/site1 ont été modifiées, ce qui correspond aux actions de mon attaquant. La création d'un fichier dans /var/www/html/site1/user_upload/ a été ignorée comme demandé.
Pendant les phases d'apprentissage, je vous conseille de toujours tester vos règles. Ici, on peut par exemple être surpris de ne pas détecter de modification sur les permissions du répertoire si l'on écrit la règle suivante :
/var/www/html/site1/ DIR
Il faut en effet ne pas écrire le "/" après le répertoire à surveiller, comme ceci :
/var/www/html/site1 DIR
Egalement, on évitera de faire un contrôle de hash sur un répertoire, ce qui pourrait être très long (incluant tous les fichiers qu'il contient) et redondant, on utilisera donc la variable créée par défaut DIR plutôt que CONTENT_EX :
# For directories, don't bother doing hashes
DIR = p+i+n+u+g+acl+selinux+xattrs
[...]
# Extended content + file type + access.
CONTENT_EX = sha512+ftype+p+u+g+n+acl+selinux+xattrs
On voit que la directive sha512 n'y est pas présente, ce qui évite de calculer un hash pour un répertoire.
V. Quelques astuces supplémentaires
A. Utiliser des fichiers de configuration différents
On peut également utiliser des fichiers de configuration différents en fonction des besoins. Un contexte d'exemple :
On souhaite vérifier l'intégrité de nos répertoires de configuration toutes les 5 minutes mais notre serveur contient de très gros répertoires avec de nombreux fichiers, la réalisation du contrôle d'intégrité prend donc 20 minutes à s'exécuter. Ici, on peut créer une configuration /etc/aide_etc.conf qui contiendra les directives relatifs aux répertoires dans /etc, une tâche planifiera toutes les 10 minutes un contrôle d'intégrité. Puis on créera un autre fichier de configuration /etc/aide_autre.conf qui contiendra toutes les autres directives, notamment celles concernant nos répertoires contenant de très nombreux fichiers, celui-ci sera lancé par une autre tâche planifiée qui s'exécutera, elle, toutes les 3 heures. Pour cela, on utilisera l'option -c :
On peut s'intéresser à ce que contient une base de signature. Pour cela, on utilise l'utilitaire gunzip pour décompresser notre base de signature, puis on l'ouvre avec un simple éditeur de texte :
[root@localhost aide]# gunzip aide.db.gz
[root@localhost aide]# vim aide.db
On remarque ici plusieurs noms des fichiers contrôlés, suivis de différentes données, dont des hashs. Je n'ai évidemment pas le détails de chacun des champs mais on peut imaginer que AIDE distingue ici le hash du fichier, ses permissions, ses ACL, son propriétaire, etc. 🙂
Extrait du guide de l'ANSSI sur la sécurité des systèmes GNU/Linux
Au delà de l'aspect "réglementaire", il s'agit d'une très bonne solution lorsque celle-ci est correctement déployée et intégrée dans la vie quotidienne d'un parc de systèmes Linux. Elle peut permettre de trahir la présence d'une attaque en cours. J'espère que cet article vous sera utile et vous aura éclairci sur le fonctionnement d'AIDE et son intérêt en termes de sécurité.
Je rencontre un grand nombre de système d'information différents dans le cadre professionnel et ils sont trop rare à profiter des apports de ce type de solutions, je ne peux donc que vous conseiller d'expérimenter, de tester, d'apprendre et de déployer AIDE sur vos systèmes Linux.
Dans cet article, nous allons parler split-brain DNS et plus particulièrement sa configuration sur un serveur DNS sous Windows Server 2016. La configuration qui suit s'appuie essentiellement sur PowerShell.
II. Qu'est-ce que le split-brain DNS ?
Si l'on traduit tout bêtement split-brain, on obtient : cerveau divisé. Nous ne sommes pas si loin de la réalité, en fait. Grâce à la méthode du split-brain DNS, nous allons pouvoir demander à notre DNS de répondre différemment au client qui envoi la requête en fonction de son réseau source.
Prenons un exemple, nous avons le site internet www.it-connect.fr qui est accessible par tout le monde, sur un serveur web exposé sur Internet. Le serveur DNS connaît l'adresse IP associée à cet hôte, il s'agit d'une adresse IP publique diffusée partout.
Maintenant, imaginons que ce site soit accessible également par les utilisateurs connectés au réseau interne de la société IT-Connect. Sur le réseau local, nous avons un second serveur web, accessible uniquement en interne et l'on souhaite, à juste titre, qu'il soit utilisé lorsqu'une personne se connecte sur www.it-connect.fr à partir du réseau local. Pour parvenir à ce résultat, nous allons utiliser la méthode du split-brain DNS.
En résumé, avec un seul serveur DNS et une seule zone, vous pouvez retourner des réponses différentes (donc adresses IP différentes) à vos clients. Ce principe est notamment utilisé lorsque les serveurs sont répartis à différents endroits géographiques afin de permettre au client d'accéder au serveur le plus proche.
Je vous laisse admirer mon superbe dessin (il faut bien que je m'amuse avec le stylet de la Surface), où l'on voit bien un serveur DNS, au centre, et deux clients : l'un dans le réseau local et l'autre sur Internet. Dans le réseau local, nous avons également un serveur web avec une copie du site, et sur Internet, un second serveur avec lui aussi sa copie du site.
Principe du Split-brain DNS
III. Configurer le split-brain DNS sur Windows Server
Reprenons l'exemple du schéma, avec le site www.it-connect.fr et deux hôtes qui hébergent le site :
Depuis le réseau local, le premier hôte dispose de l'adresse IP : 192.168.1.100
Depuis Internet, le deuxième hôte dispose de l'adresse IP : 90.90.1.100
Au centre, un serveur DNS sous Windows Server 2016 (dans mon cas) qui contient et gère la zone "it-connect.fr".
Connectez-vous sur votre serveur et ouvrez une console PowerShell en tant qu'administrateur.
Premièrement, nous allons créer un scope nommé "LAN" dans la zone "it-connect.fr". Pour créer un scope, il est nécessaire d'utiliser le cmdlet Add-DnsServerZoneScope. Voici la commande :
Ensuite, nous allons créer un enregistrement DNS de type A (IPv4) pour l'hôte "www" avec l'adresse IP du serveur web interne. Cet enregistrement sera rattaché au scope "LAN" de notre zone.
Note : lorsque l'on crée un enregistrement DNS en PowerShell pour l'ajouter dans le scope par défaut (global), on utilise la même commande sauf qu'il n'est pas nécessaire d'utiliser le paramètre ZoneScope.
Ce qui donne :
Add-DnsServerResourceRecord -ZoneName "it-connect.fr" -A -Name "www" -IPv4Address "192.168.1.100" -ZoneScope "LAN"
Maintenant que l'on a notre scope et l'enregistrement qui lui est associé, il faut ajouter une dernière couche : la stratégie (policy). En fait, nous allons créer une politique pour indiquer que si une requête arrive sur l'interface 192.168.1.10 du serveur DNS, alors on affecte le scope "LAN" pour la zone "it-connect.fr".
La commande Add-DnsServerQueryResolutionPolicy s'utilise comme ceci :
Vous remarquerez la présence du paramètre -Action : il sert à indiquer si l'on autorise, refuse ou ignore les paquets qui vont matcher avec la politique que l'on crée. Pour le paramètre -ZoneScope, la valeur "1" qui suit le nom du scope sert à indiquer le poids car on pourrait indiquer plusieurs scopes. Enfin, pour le paramètre -ServerInterfaceIP on indique l'adresse IP du serveur DNS utilisée par les clients (interface d'écoute). Il est possible de remplacer le "eq" pour equal/égal par la négation "ne" pour not equal.
Note : à la place de l'adresse IP du serveur, on peut spécifier un subnet source grâce au paramètre -ClientSubnet. Pour créer le subnet, il faudra au préalable utiliser le cmdlet Add-DnsServerClientSubnet.
Voici le résultat de la commande nslookup avant et après la mise en place de la politique.
Précision : j'ai réalisé les tests directement depuis le serveur DNS, l'adresse IP utilisée est donc 127.0.0.1 : ce qui ne correspond pas à la politique, j'ai donc créer une autre politique pour indiquer l'adresse IP 127.0.0.1 mais j'aurais pu faire autrement. Par exemple, utiliser le "ne" pour exclure l'adresse IP externe du serveur DNS et ainsi conserver son IP sur le réseau local et l'adresse localhost.
IV. Afficher et gérer la configuration
La console DNS de Windows Server n'affiche pas les scopes et les stratégies donc il est nécessaire d'avoir recours à PowerShell pour consulter la configuration.
Pour lister les scopes associés à une zone, nous pouvons utiliser le cmdlet Get-DnsServerZoneScope, comme ceci :
Get-DnsServerZoneScope -ZoneName "it-connect.fr"
Cela va afficher les scopes associés à la zone "it-connect.fr" 😉
Note : par défaut une zone DNS dans Windows contient un scope qui englobe tout, afin de répondre aux clients avec l'enregistrement "principal" (associé à aucun scope).
Pour afficher les stratégies associées à une zone, on va rajouter une seconde commande à la suite de celle que l'on a vu précédemment. Cela donne la commande suivante :
Les stratégies vont s'afficher avec le nom, le poids de la règle, son état (actif/inactif) et l'action associée (accepter, bloquer ou refuser). Pour finir, voici les commandes qui servent à supprimer les objets :
Supprimer un scope : Remove-DnsServerZoneScope
Supprimer une stratégie : Remove-DnsServerQueryResolutionPolicy
Modifier une stratégie : Set-DnsServerQueryResolutionPolicy
V. Cas avec deux DNS différents
Pour finir, je tiens à partager une autre méthode d'utilisation de ce que l'on peut assimiler à du split-brain DNS dans le cas où l'on utilise deux DNS différents.
Imaginons un nom de domaine géré par un registrar (OVH, par exemple), avec un enregistrement DNS qui renvoi vers un serveur hébergé on-premise en DMZ, accessible par une adresse IP publique. Si l'on se situe sur Internet, on va y accéder grâce à l'adresse IP publique. Par contre, si l'on est sur le réseau local, il est préférable d'y accéder via l'adresse IP privée sauf que le DNS va répondre avec l'IP publique.
Dans ce cas, il existe une astuce : créer une zone sur votre serveur DNS on-premise, en indiquant comme nom de zone le nom complet de l'hôte, par exemple "www.it-connect.fr" pour faire un overload par rapport à l'enregistrement situé au niveau du registrar. Il suffit de créer un enregistrement par défaut dans la zone et d'y attribuer l'adresse IP privée ! 😉
Il est important de ne pas créer la zone "it-connect.fr" car sinon vous allez devoir gérer en doublon votre zone dans les deux serveurs DNS indépendant. En créant la zone sur un nom spécifique, le serveur DNS on-premise se limitera à utiliser sa zone pour ce nom, et pour les autres requêtes liées à ce domaine, il va solliciter le serveur DNS externe qui lui contient la zone publique.
A l'occasion des soldes de janvier, le site GoodOffer24 récidive et lance une nouvelle offre permettant d'obtenir 30% de réduction sur les licences Windows 10 et Office 2016 ou 2019.
De manière générale, le site GoodOffer24 offre la possibilité d'acheter des clés de licence pour certains jeux-vidéos, notamment en passant par les plateformes Steam et Origin, mais également des cartes Playstation Store. Des licences pour les solutions de protection Endpoint sont aussi proposées.
Pour en revenir à l'offre : elle s'applique sur les licences OEM de Windows 10, pour les éditions Famille et Professionnel. Concernant la suite Office, il s'agit d'une clé pour la version Pro Plus de la suite bureautique, que ce soit pour Office 2016 ou Office 2019. En temps normal, le prix des licences est déjà attractif, ce qui le devient encore plus avec une réduction de 30%. C'est aussi la raison pour laquelle les offres de GoodOffer24 sont généralement relayées par nos confrères francophone.
Cette semaine, un hacker a diffusé sur Internet une liste d'identifiants de connexion Telnet pour plus de 500 000 équipements, avec notamment des serveurs, des routeurs mais aussi des objets connectés IoT.
Ce fichier est bien construit puisque pour chaque appareil, nous retrouvons : son adresse IP, un nom d'utilisateur et le mot de passe associé, de quoi établir une connexion Telnet sur l'équipement sans difficultés.
Il s'agit d'une bot-list construite en balayant Internet à la recherche d'équipements accessibles via Telnet, pour ensuite essayer différentes combinaisons d'identifiants login/mot de passe. Cette technique est redoutable et surtout elle met en évidence un défaut de sécurité, déjà parce que le protocole Telnet est utilisé alors que le SSH est recommandé. Ensuite, parce que le mot de passe n'est pas suffisamment complexe pour résister aux combinaisons les plus répandues. Puisqu'il s'agit également de routeurs, on peut imaginer que les techniciens des FAI ont un peu déconné sur le coup...
Cette liste date d'octobre-novembre 2019 et il y aurait certains équipements qui auraient changés d'adresse IP désormais. Par contre, les identifiants sont peut-être (et même surement) toujours valides.
