Bien que tous les recoins du wiki ne soient pas forcément facilement découvrables, nous pensons avoir une bonne idée de l’architecture générale de Picasoft. Il nous faudra passer plus de temps au contact de celle-ci pour en saisir les détails, pour intégrer correctement quels hôtes hébergent les différents services proposés et pour nous familiariser avec certaines terminologies.s pensons avoir une bonne idée de l’architecture générale de Picasoft. Il nous faudra passer plus de temps au contact de celle-ci pour en saisir les détails, pour intégrer correctement quels hôtes hébergent les différents services proposés et pour nous familiariser avec certaines terminologies.

Cette section contient quelques pistes que nous jugeons bonnes à explorer lors de ce projet. Tout d’abord, il serait judicieux d’auditer la sécurité du service de DNS employé par Picasoft, qui est susceptible d’être vulnérable, ce qui pourrait compromettre tous les services s’appuyant dessus. Tous les hôtes exposent leurs services sur des ports standards. On peut s’interroger sur l’intérêt de changer le port de services comme ssh voire de mettre en place une stratégie de fail2ban ou de port-knocking. Certains scripts de boot semblent être placés directement dans /etc/init.d/, ce qui n’est possible que pour être compatible avec d’autres init que systemd. Étant donné la ferveur de ce projet à mettre en avant l’évolution, il serait judicieux d’employer des units systemd à la place, au cas où /etc/init.d/ ne serait un jour plus supporté. Le transit des journaux en clair entre les hôtes est une vulnérabilité de très haute priorité. Il serait judicieux de s’interroger sur le comportement des différents hôtes lorsqu’ils sont à cours de mémoire. Cela complémenterait le travail effectué lors de la TX précédente. S employé par Picasoft, qui est susceptible d’être vulnérable, ce qui pourrait compromettre tous les services s’appuyant dessus. Tous les hôtes exposent leurs services sur des ports standards. On peut s’interroger sur l’intérêt de changer le port de services comme ssh voire de mettre en place une stratégie de fail2ban ou de port-knocking. Certains scripts de boot semblent être placés directement dans /etc/init.d/, ce qui n’est possible que pour être compatible avec d’autres init que systemd. Étant donné la ferveur de ce projet à mettre en avant l’évolution, il serait judicieux d’employer des units systemd à la place, au cas où /etc/init.d/ ne serait un jour plus supporté. Le transit des journaux en clair entre les hôtes est une vulnérabilité de très haute priorité. Il serait judicieux de s’interroger sur le comportement des différents hôtes lorsqu’ils sont à cours de mémoire. Cela complémenterait le travail effectué lors de la TX précédente.

Il nous faut encore étudier les différentes politiques de sauvegarde employées au sein de Picasoft. De même, nous ne nous sommes pas encore attardés sur le travail précédemment effectué sur la CI.

Nous avons notamment pris le temps de lire les différents rapports rédigés pour la précédente TX sécurité. Nous avons notamment noté les avis sur certaines images (Mattermost et wiki) qui laissent apparaître des failles concrètes dans le système et qu’il faudra traiter assez rapidement, d’autant plus que ces rapports sont publics.

Nous avons commencé l’exploration des hôtes auxquels l’accès nous a été donné. Ce travail n’est pas encore achevé. L’apparent manque de traçabilité sur le système nous laisse croire qu’un système de contrôle d’accès à base de rôles (type SELinux) serait peut-être approprié.

Cédric - 2/3 : Je suis assez content de mon avancée mais il me reste du travail à effectuer, notamment au niveau des sauvegardes, de l’exploration des hôtes, de la CI et de l’utilisation de Docker à Picasoft.

Hugo - 2/3 : J’ai lu la plupart des pages du wiki (j’en ai sûrement loupées quelques unes, qui sont difficilement accessible), mais j’aurais aimé plus approfondir.

Evaluation du run : Cédric : 2/3 Hugo : 2/3

Les dégâts intérieurs, volontaires ou non, font partie des menaces importantes de l’architecture. Il est donc primordial de pouvoir limiter les droits des utilisateurs sur celle-ci, indépendamment de la confiance leur étant accordée.

Un utilisateur ayant le contrôle sur Docker peut facilement gagner un accès root sur l’hôte. C’est pourquoi cet accès est directement accordé à tous les utilisateurs ayant des droits d’administration de Docker. Nous nous opposons à cette pratique car elle favorise les erreurs humaines. En effet, bien qu’une commande erronnée préfixée d’un sudo puisse vite arriver, il est improbable que quelqu’un monte la racine de l’hôte et l’exploite par accident.

De plus, une fois que Docker sera mieux contenu (voir la section suivante pour plus d’informations), il sera d’autant plus pertinent de faire la distinction entre un sudoer et un administrateur Docker.

Nous préconisons ainsi que les utilisateurs soient ajoutés au groupe docker, leur permettant d’administrer les conteneurs sans être sudoers.

La section suivante explique cependant en quoi cette solution n’est pas infaillible.

Nous avons envisagé plusieurs solutions pour empêcher les administrateurs Docker de prendre le contrôle sur la machine hôte. Les solutions que nous avons envisagées comprennent l’utilisation de fonctionnalités natives à Docker, la mise en place de RBAC avec SELinux, la mise en place de politiques de sécurité AppArmor par conteneur, la restriction du démon avec systemd et l’isolation des conteneurs dans des machines virtuelles distinctes.

L’utilisation de fonctionnalités natives à Docker est inadéquate. La documentation officielle du projet stipule clairement qu’il ne s’agit pas d’une solution sécurisée et que l’accès à Docker, même via le groupe idoine, ne doit être fourni qu’à des utilisateurs de confiance.

Ainsi, Docker ne fournit pas de primitives permettant d’éviter à l’administrateur d’un conteneur d’accéder à l’hôte ou aux autres conteneurs.

Il est possible de restreindre les accès des utilisateurs avec le RBAC (Role Based Access Control) de SELinux. Cela dit, l’écriture, la maintenance et la mise en place d’une politique de sécurité personnalisée sont très lourdes et pourraient même gêner la partie applicative en cas d’imprévus. La mise en place pour un problème d’une telle envergure restreinte est donc déconseillée.

Docker propose également la mise en place d’AppArmor pour restreindre les accès des conteneurs. Il propose d’appliquer des profils de sécurités personnalisés pour chaque conteneur. Cependant, ces profils opèrent avec un principe de liste noire, ce qui engendre plus de maintenance et de risques d’erreurs de configuration. De plus, l’administrateur du conteneur est responsable du choix de profil appliqué. Ainsi, un administrateur mal intentionné pourrait simplement ne pas fournir de profil et ainsi avoir un moyen de gagner le contrôle de l’hôte.

systemd accepte plusieurs options de contrôle d’accès dans ses units. Par exemple, ProtectHome permet d’exposer /home/, /root/ et /run/user/ comme étant vides au service. Il est également possible de rendre certains chemins accessibles en lecture seule avec d’autres options.

Il n’est pas possible de restreindre tout le système de fichiers car le démon a besoin d’accéder notamment à /proc/ et /sys/. Cependant, on peut offrir des garanties de confidentialité sur certains répertoires en les rendant inaccessibles et d’intégrité en rendant d’autres accessible uniquement en lecture. Cette solution a cependant des limites : il n’est pas possible de ségréger les différents conteneurs. De plus, un administrateur Docker pourra techniquement obtenir un accès root sur le /proc de l’hôte, permettant indirectement de l’exploiter. Bien qu’incomplète, cette solution offre toutefois une mitigation importante des risques par rapport au système actuel.

La solution correcte, bien que plus lourde, est d’isoler les conteneurs dans des machines virtuelles distinctes. Ainsi, les accès seraient distribués aux utilisateurs par VM, leur rendant impossible l’exploitation d’autres conteneurs. Ils pourraient techniquement prendre le contrôle de l’hôte, mais cela n’aurait pas de gros impact, l’hôte n’étant qu’un wrapper autour du conteneur. S’il faisait tomber l’hôte, celui-ci pourrait simplement être restauré depuis une sauvegarde et l’accès à l’utilisateur mal intentionné serait retiré. Cette solution est préconisée dans notre cas d’usage.

L’exploration des hôtes nous a mené à observer des incohérences dans les profils LDAP. Hugo et Cédric partageaient ainsi le même répertoire dans /home et Cédric avait le même uid qu’un autre utilisateur.

Bien que ce problème ait été rapidement corrigé par Rémy, il met en exergue des failles dans la procédure de création de comptes (voir la section Procédures plus bas).

Beaucoup de conversations censées être confidentielles se font sur une instance ne supportant pas les pads privés. Il peut être intéressant d’utiliser le plugin mypads, développé et utilisé par Framasoft, pour ajouter le support de pads privés, qui permettrait d’éviter la fuite d’information sensible par simple énumération d’URL.

Il convient tout d’abord d’évaluer ce qui a été fait, ce qui est en cours et ce qui reste à faire au niveau de la TX A18, afin de déterminer ce qui nous reste à faire.

La TX sécu A18 a permis de mettre en avant un certain nombre de failles au niveau des images docker. Certaines d’entre elles ont été corrigées, mais d’autres semblent être toujours présentes. L’audit de l’image etherpad a été suivie d’une correction des vulnérabilités, documentée ici : https://gitlab.utc.fr/picasoft/wiki/blob/master/docker/audit-etherpad/correction-vulnerabilites-etherpad.md . Cependant, un tel document manque pour les deux autres images auditées (l’image pica-dokuwiki et l’image mattermost). Il est donc difficile de savoir ce qui a été fait en réponse à l’audit, et ce qui reste à faire. Il semble que certains des conseils aient été appliqués (limitation des ressources dans le docker-compose.yml de l’image dokuwiki), mais faute de document de suivi, nous n’avons pas de vision globale.

L’application de l’intégration continue aux images docker des principaux services semble être toujours en développement. En effet, une mise à jour du .gitlab-ci.yml du dépôt contenant les dockerfiles a été effectué la semaine dernière. Dans cette optique, il ne s’agirait donc pas d’une tâche que nous aurons à effectuer.

Nous nous sommes posé la question de l’intérêt d’une analyse statique des vulnérabilités de toutes les images docker. Par exemple, l’image docker de l’instance Mattermost utilisée actuellement est une copie de l’image proposée par Mattermost. Si, lors d’une mise à jour de Mattermost, une vulnérabilité est mise en lumière au niveau de l’analyse statique, on ne peut pas nécessairement y faire grand chose. De plus, les mises à jour d’un tel service permettent souvent de corriger des vulnérabilités détectées et avérées. De ce fait, repousser une mise à jour à cause d’une potentielle CVE détectée par l’outil de test statique ou dynamique peut sembler risqué.de toutes les images docker. Par exemple, l’image docker de l’instance Mattermost utilisée actuellement est une copie de l’image proposée par Mattermost. Si, lors d’une mise à jour de Mattermost, une vulnérabilité est mise en lumière au niveau de l’analyse statique, on ne peut pas nécessairement y faire grand chose. De plus, les mises à jour d’un tel service permettent souvent de corriger des vulnérabilités détectées et avérées. De ce fait, repousser une mise à jour à cause d’une potentielle CVE détectée par l’outil de test statique ou dynamique peut sembler risqué.de toutes les images docker. Par exemple, l’image docker de l’instance Mattermost utilisée actuellement est une copie de l’image proposée par Mattermost. Si, lors d’une mise à jour de Mattermost, une vulnérabilité est mise en lumière au niveau de l’analyse statique, on ne peut pas nécessairement y faire grand chose. De plus, les mises à jour d’un tel service permettent souvent de corriger des vulnérabilités détectées et avérées. De ce fait, repousser une mise à jour à cause d’une potentielle CVE détectée par l’outil de test statique ou dynamique peut sembler risqué.

Il faudrait tester le script de mise en place de mise à jour automatique, et notamment la mise en place des rapports automatiques par mail, afin de pouvoir le déployer en production. Cela permettrait d’alléger la procédure de mise à jour, en prenant en charge les mises à jour de sécurité. en place des rapports automatiques par mail, afin de pouvoir le déployer en production.

Des procédures ont été proposées lors de la TX d’automne 2018. Celles sont sont appliquées inégalement. La procédure de mise à jour n’est pas du tout appliquée par exemple, car jugée trop contraignante. La procédure d’arrivée et de départ d’utilisateur semble elle être appliquée (même si aucun départ n’a eu lieu depuis la mise en place de cette procédure). Cependant, elle n’est pas sans faille, car lors de la création de nos comptes utilisateurs, des erreurs se sont glissées.

Les utilisateurs sont gérés actuellement de manière centralisée, via un serveur LDAP. Cependant, il serait bon d’étudier les interfaces d’administration possible, afin d’éviter les erreurs lors de la création d’utilisateurs.actuellement de manière centralisée, via un serveur LDAP. Cependant, il serait bon d’étudier les interfaces d’administration possible, afin d’éviter les erreurs lors de la création d’utilisateurs.rés actuellement de manière centralisée, via un serveur LDAP. Cependant, il serait bon d’étudier les interfaces d’administration possible, afin d’éviter les erreurs lors de la création d’utilisateurs. Certains conteneurs ont une limite de ressources (etherpad et dokuwiki). Ces limites de ressources sont encore à mettre en place sur d’autres conteneurs (notamment mattermost).

D’autres moyens techniques pourraient êtres mis en place, tels que fail2ban, qui permet de bannir (par des règles de pare-feu par exemple) les IPs montrant des signes de malignité, et ainsi prévenir des attaques par force brute ou par déni de service.

Cédric : 3/3 : Les réunions avec Hugo ont été productives et j’ai pu explorer et tester les manières de restreindre les conteneurs Docker. De plus, nous avons des pistes de travail concrètes pour la semaine à venir.

Hugo : 3/3 : Comme l’a dit Cédric, nous avons été productif lors de nos réunion. J’ai pu faire l’inventaire des procédures et moyens techniques actuels, et analyser les résultats de la TX précédente.

Évaluation du jury : 3/3

Nous avons différencié les parties de l’infrastructure devant ou non être couvertes par l’audit. Seront compris dans l’audit :

• la configuration des pare-feux des différents conteneurs et machines virtuelles ;
• la configuration des applicatifs lorsque celle-ci concerne directement la sécurité de l’infrastructure ;
• la détermination des données critiques et la mise en place de leur protection.

Ne seront pas comprises dans l’audit :

• les failles applicatives venant directement d’upstream ;
• les machines et pratiques personnelles des utilisateurs ayant accès à l’infrastructure.

Nous ne savons pas encore si la machine virtuelle de Stéphane Crozat sera comprise dans l’audit. Cela sera déterminé lors d’une prochaine réunion.

Nous avons pour l’instant identifié les données personnelles suivantes, qui seront par la suite considérées ou non comme étant critiques :

• les mails envoyés et reçus via le serveur de Picasoft
• les conversations Mattermost
• les logs

• Traefik (sur chaque VM)
• DNS
• LDAP
• Mattermost
• Mattermost Giphy
• Base de données Mattermost
• Wekan
• Base de donnée du service Wekan
• Cloud CET
• Base de données CET
• Cloud CET collabora
• db-backup (pour chaque Docker)
• backup (pour chaque Docker)
• Outils de monitoring (grafana, picasoft-metrics-bot, influx-db)
• registry
• Nextcloud picasoft
• Base de données Nextcloud picasoft
• School
• Pica-mail (MTA et MDA)
• Wiki
• Rotation des sauvegardes

Nous avons découvert un binaire /DATA/docker/a.out sur pica01. Celui-ci a été téléchargé localement sur une de nos machines puis décompilé. Il s’agit d’un binaire Go en rapport avec Prometheus, une base de données servant au monitoring. Celui-ci ne semble pas être utilisé et aucun membre de Picasoft sur Mattermost ne semblait savoir pourquoi il se trouve là. Le wiki le mentionne simplement Prometheus comme étant une base de données de collecte de métrique à https://wiki.picasoft.net/doku.php?id=infrastructure:metrics&s[]=prometheus.

Nous avons également investigué la configuration du cloud de Compiègne en Transition. Il s’est avéré que les mots de passe d’administration du cloud et de sa base de données sont tous deux présents dans le fichier /DATA/docker/docker-compose.yml, accessible à tous les administrateurs docker. Cela leur donne un accès complet à des données n’appartenant pas à Picasoft. Nous suggérons que ces mots de passe soient stockés dans un fichier secret, accessible uniquement à root et pointé par la fichier de configuration docker-compose.yml. Ces mots de passe seront toujours disponibles dans l’environnement du conteneur, mais seront au moins cachés dans le fichier de configuration de Docker. Cela évitera de les afficher lors de la moindre consultation ou modification de la configuration, réduisant les risques de fuite d’information physiques de type “au-dessus de l’épaule”.

Par ailleurs, nous recommandons que les mots de passe soient changés car ceux-ci sont extrêment faibles. Corrections effectuées

Les recommandations d’accès au compte root de la semaine dernière ont été appliquées : Rémy a restreint les droits sudo à quelques utilisateurs et a ajouté les administrateurs au groupe docker à la place.

Par ailleurs, la politique de pare feux a été durcie. La configuration iptables a été rendue persistante aux redémarrages et elle a été corrigée pour refuser les paquets adressés aux ports LDAP et ne provenant pas de serveurs Picasoft.

Cédric : 3/3 : je pense que nous avons correctement évalué le perimètre de l’audit, comme convenu. Celui-ci sera peut-être légèrement modifié d’ici sa fin en fonction de l’avancement de l’audit. Je suis aussi satisfait des découvertes que nous avons accidentellement faites sur l’infrastruture.fonction de l’avancement de l’audit. Je suis aussi satisfait des découvertes que nous avons accidentellement faites sur l’infrastruture.

Hugo : 3/3 je suis également satisfait du travail effectué.

Evaluation de la semaine 3/3

Cette semaine, nous avons prioritarisé les unités du périmètre de l’audit. Un premier jet grossier a été effectué en fonction de ce que nous avions précédemment remarqué sur l’architecture.

Nous avons ensuite établi la table des menaces principales associées à chaque unité. Grâce à cette table, nous avons pu réorganiser plus finement les priorités.

Par ailleurs, nous avons relevé à Rémy que le Giphy de Mattermost devait être supprimé de l’infrastructure et de la documentation, ce qui est désormais sur sa todo-list. Nous avons aussi remarqué que le mot de passe d’administration LDAP est accessible en clair aux utilisateurs de monitoring.

Cédric a effectué une copie locale du gros binaire Go en rapport avec Prometheus sur pica01, au cas où, et l’a supprimé de pica01.

Hugo a trouvé un client web LDAP permettant notamment une gestion propre des utilisateurs Unix (e.g. génération incrémentale des UID). Il pourrait s’agir d’un bon outil pour réduire les risques d’erreur humaine lors de la création et de l’édition des comptes.

Par ailleurs, il s’est avéré que tous les fichiers et répertoires dans /DATA/docker sur pica01 et pica02 ont des droits d’exécution/traversée pour tout le monde. Nous préconisons que cela soit corrigé.

Cédric : 3/3 nous avons pu évaluer les menaces concernant toute l’infrastructure et avons relevé certaines anomalies.

Hugo: 3/3 Nous avons réalisé le travail qui était planifié pour la semaine (inventaire des menaces, première priorisation des tâches).

Nous avons constaté que certaines bonnes pratiques sont déjà mises en place sur tous les hôtes. Notamment, l’authentification par mots de passe est interdite, PAM est utilisée et les membres de chrootjail, groupe utilisé pour la récupération des snapshots sur alice et bob, sont automatiquement chrootés dans /SAVE/dump/public_snapshots.

Cependant, le forwarding X est explicitement permis sur tous les hôtes alors qu’il ne sert à rien. Xorg est une surface d’attaque importante. Bien qu’aucun serveur X ne soit installé pour le moment, cela pourrait changer, notamment en temps que dépendance pour d’autres paquets. Nous préconisons donc que la configuration soit changée pour interdire le forwarding X.

De plus, nous avons remarqué que les droits en lecture et exécution sur divers fichiers dans /etc/ssh/ pourraient être restreints. Il est débatable qu’on puisse vouloir laisser les droits de lecture sur la confguration ssh si on la considère sûre et qu’on souhaite éviter que les utilisateurs passent root juste pour la consulter. Cependant, nous recommandons formellement que les droits d’exécution soient retirés pour g et o sur /etc/ssh/ldapssh.sh.

Par ailleurs, nous remettons en cause l’emploi de nologin dans la configuration PAM associée à sshd. Bien que la plupart des utilisateurs ne puissent normalement pas toucher /etc/nologin, il serait bon d’éviter le risque de bloquer tous les accès ssh aux hôtes à part pour root dans le cas où ce fichier serait créé, volontairement ou accidentellement. Anomalies de permissions

La semaine dernière, nous avions trouvé un répertoire ressemblant à un home, directement à la racine de monitoring. Celui-ci était orphelin, vide (modulo le skel) et donc inutile. Il a depuis été supprimé.

Le script suivant permet de trouver certaines anomalies de permissions

#!/bin/sh

echo "root and setuid"
find / -user root -perm /u+s 2> /dev/null

echo "orphans"
find / -type f -nouser -o -nogroup 2> /dev/null

echo "writeable by others and executable"
find / -type f -perm /u+x -a -perm /o+w 2> /dev/null

echo "writeable by others"
find / -type f -perm /o+w 2> /dev/nullnd / -type f -perm /u+x -a -perm /o+w 2> /dev/null

echo "writeable by others"
find / -type f -perm /o+w 2> /dev/null

Résultats en vrac :

• Tellement de choses writeable par tout le monde dans sys et proc, dont init. Comportement par défaut, mais voir si on peut changer ça. Sinon il faudrait 1. passer par un sshfs ou qqchose de similaire 2. s’en moquer.
• Process sans users
• Tout le monde peut écraser les backups (/DATA/BACKUP2/etherpad/*) sur pica01-test (à vérifier ailleurs)
• Sur pica02, essentiellement tout le wiki writeable par tout le monde, ainsi que pas mal de la config pour CET (redis & co). Juste de la faute de Rémy ?
• Pas d’orphelins sur alice, bob, pica02. En revanche :
  • monitoring : pleins de process sans users, /DATA/docker/grafana/data/grafana.db sans user et rhtest (/home/user/rhtest) semble pété
  • pica01 : des choses sans user/groupe chez Quentin ainsi que dans /DATA/docker/mattermost/mattermost-app
• Pas de setuid louches sur les hôtes
• pica02 : wekan appartient à un user telegraf..?

Nous avons utilisé les commandes suivantes pour corriger les problèmes de permissions sur les données du cloud de CET :

# set directory rights
sudo find /DATA/docker/cet/nc/data -type d -exec chmod u=rwx,g=rx,o=rx {} \;
# set files rights
sudo find /DATA/docker/cet/nc/data -type f -mindepth 2 -exec chmod u=rw,g=r,o=r {} \;

Est-ce que l’on veut un umask plus restrictif pour root (026) ?

Nous avons principalement étudié deux solutions permettant de lister les commandes ayant été entrées sur les systèmes.

lastcomm est une solution légère, mais qui n’est pas un outil de traçabilité. Elle n’est pas suffisamment configurable pour nos besoins et ne permet pas d’afficher les arguments passés aux commandes.

auditd est un démon beaucoup plus lourd, mais qui permet un contrôle beaucoup plus fin des actions effectuées sur le système. Il utilise PAM (pour lequel une bibliothèque partagée pamttyaudit.so) et permet de journaliser toutes les touches pressées par les utilisateurs connectés à un TTY (tous dans notre cas, puisque les connections se font toutes pas SSH).

Il est possible d’utiliser rsyslog pour envoyer ses journaux sur un serveur dédié.

auditd peut aussi journaliser n’importe quel appel système. Pour des raisons de performances, il est n’est pas envisageable de tous les tracer. En revanche, on pourrait journaliser les appels à execve pour avoir une liste exhaustive des commandes appelées. Cela est beaucoup plus facile à analyser qu’une succession de touches.

On peut rajouter ces lignes à /etc/audit/audit.d/audit.rules pour journaliser tous les appels (32 et 64 bits) à execve (donc tout ce qui est appelé par un shell). L’option -k permet de labelliser ces événements, pour ensuite les retrouver quand on analyse les journaux.

-a exit,always -F arch=b64 -S execve -k execve_rule

-a exit,always -F arch=b32 -S execve -k execve_rule

aureport, le front-end de rapport d’auditd, permet également d’obtenir une liste de toutes les tentatives d’authentification, leur méthode (login, sudo, etc.) et si cette tentative a abouti ou échoué. Il recence également certaines anomalies sur le système (segfault, terminaisons de process anormales, etc.)

ch est un front-end plus bas niveau qui présente les événements formattés. On peut notamment les récupérer par clef avec l’option -k :

ausearch -k execve_rule

auditd semble donc une très bonne solution pour les problématiques de traçabilité de Picasoft.

Cédric : 3/3 Je suis très satisfait de l’avancement de cette semaine

Hugo : 3/3 Nous avançons convenablement.

Semaine des médians - pas de réunion

Nous avons étudié la configuration des serveurs DNS. Elle semble globalement correcte, DNSSEC étant notamment activé sur Alice et Bob. Nous n’avons cependant pas pu évaluer la configuration de Kyâne, donc un VPS sert de slave à Alice au même titre que Bob. Traefik

Nous avons étudié la configuration de Traefik. En effet, il s’agit d’un point crucial de l’infrastructure : il gère l’interface avec Let’s Encrypt pour les connexion https, et il est connecté sur le socket de docker. En cas de compromission, c’est donc toute l’infrastructure de picasoft qui est en danger.d’un point crucial de l’infrastructure : il gère l’interface avec Let’s Encrypt pour les connexion https, et il est connecté sur le socket de docker. En cas de compromission, c’est donc toute l’infrastructure de picasoft qui est en danger.

Traefik présente l’avantage d’être utilisable avec un minimum de configuration, ce qui limite les risque d’erreurs. La configuration actuelle semble correcte, et la redirection automatique vers l’https est activée.

Du fait de la place critique de traefik dans l’infrastructure, nous recommandons qu’un ou des membres de l’équipe technique suive le conseil donné ici : https://docs.traefik.io/#security-advisories et s’abonne à la mailing list sécurité de traefik où sont publiées les alertes de sécurité liées aux vulnérabilités connues, si ce n’est pas déjà le cas, afin de pouvoir mettre à jour rapidement. Registre

Le registre Docker présent sur monitoring ne présente rien de particulier à part que les certificats, clef et mot de passe sont inscriptibles par le groupe docker, ce qui n’est pas recommandé, puisqu’ils devraient être suffisamment rarement modifié pour que root puisse le faire. Cela éviterait que ces fichiers soient modifiés, accidentellement ou non, réduisant les risques sur leur intégrité.

Cédric : 2/3 Malgré les médians nous avons attaqué la liste des audits à effectuer sur l’infrastructure

Hugo : 2/3 Je suis content du travail réalisé, mais à cause des médians, celui-ci est de faible volume par rapport au temps écoulé depuis la dernière réunion.

Nous avons fini de corriger les permissions de pica01, excepté pour le (maintenant obsolète ?) site de CeT, que nous avons laissé tel quel, ne sachant pas si sa présence avait encore du sens.

Les commandes suivantes ont été utilisées pour corriger en masse les permissions de etherpad et de mattermost :

# Correction de mattermost-app
sudo find /DATA/docker/mattermost/mattermost-app/ -type f -exec chmod u=rw,g=r,o=r {} \;
sudo find /DATA/docker/mattermost/mattermost-app/ -type d -exec chmod u=rwx,g=rw,o=r {} \;

# Correction de mattermost-db
sudo find /DATA/docker/mattermost/mattermost-db/ -type f -exec chmod u=rw,g=,o= {} \;
sudo find /DATA/docker/mattermost/mattermost-db/ -type d -exec chmod u=rwx,g=,o= {} \;

# Correction de etherpad
sudo find /DATA/docker/etherpad/etherpad-db/data/ -type f -exec chmod u=rw,g=rw,o= {} \;\;

Il reste de nombreux problèmes de permissions sur pica02, notamment au niveau des sites statiques et de tout ce qui n’est pas les données utilisateur du cloud de cet, qui devront être corrigées. Cependant, il est difficile de connaitre les permissions originales. Celles ci devront être déterminées pour finir de corriger ces soucis de permissions.

Le 6 mai, de nouveaux problèmes de permissions ont été découverts, en tous cas sur pica01-test, mais ont rapidement été corrigés. Ceux-ci seraient venus d’une manipulation de la part de Rémy (pas certain, à vérifier/corriger lors de la réunion). Problèmes d’intégrité

Nous avons commencé à mettre en place la restriction de Docker avec systemd, ce qui n’a pas encore été terminé car nous n’avions pas accès aux identifiants d’authentification du registry.

Nous avons découvert avec Quentin que depuis la version 18.09 de Docker, containerd en géré par systemd plutôt que par docker. Il est devenu impossible de passer des options de restriction de montage à Docker. Les sources font référence à une notion de Masked Paths, mais celle-ci est très mal documentée. De plus, s’ils étaient configurables, ils le seraient notamment par les admin Docker, qui pourraient les contourner. Il s’agit donc d’une fausse solution puisqu’ils représentent la menace dans ce scénario.

Cédric : 1/3 Bien que nous ayons corrigé de nouveaux problèmes de permissions, je n’ai pas encore fini de mettre en place la restriction de Docker avec systemd.

Hugo : 1/3 J’ai peu avancé suite à une successions de deadlines d’autres uvs. Je n’ai pu faire que quelques recherches sur les permissions …

Nous avons écrit un compte rendu concernant la restriction de Docker avec systemd, de la motivation derrière cette démarche à la mise en place de la solution et l’explication des problèmes rencontrés. Il ne reste plus qu’à déterminer si ce compte rendu devra être publié dans notre section du wiki ou directement sur la page Docker, bien que la solution n’ait finalement pas été mise en place. Mise en place d’auditd

Nous avons effectué différents tests en rapport avec auditd sur pica01-test. Une configuration simple permet de journaliser tous les appels à execve sur le système, en discriminant ceux effectués par root, des utilisateurs du groupe docker et des autres utilisateurs. Bien qu’efficace, cette méthode génère beaucoup de journaux, notamment en relation avec runc et containerd. Puisque docker est exécuté en temps que root, on ne peut pas distinguer les appels système effectués depuis l’interieur et l’extérieur des conteneurs, ce qui handicape la journalisation. On pourrait facilement gagner en place en ajoutant des règles pour ne pas conserver certains événements, comme CWD ou PATH.

Des bonnes pratiques de configuration d’auditd sont disponibles à https://gist.github.com/Neo23x0/9fe88c0c5979e017a389b90fd19ddfee.

Les capacité d’externalisation de logs d’auditd méritent qu’on leur prête attention. En effet, en cas de compromission d’une machine, les logs pourraient ainsi être préservés, et servir à comprendre ce qui s’est passé. Auditd est capable de collecter des logs provenant d’autres démons auditd, ce qui pourrait permettre une centralisation. Il est visiblement capable de chiffrer ces transfert en utilisant kerberos 5, ce qui est un bon point.

Nous avons fini de corriger les permissions sur pica02.

La totalité de /DATA/docker n’est plus exécutable. Les commandes utilisées pour des modifications de droits de masse sont les suivantes :

sudo find /DATA/docker/website/html.old -type f -perm /u+x -exec chmod u=rw,g=r,o=r {} \;
sudo find /DATA/docker/school/ -type f -perm /u+x -exec chmod u=rw,g=rw,o= {} \;
sudo find /DATA/docker/school.bkp2/ -type f -perm /u+x -exec chmod u=rw,g=rw,o= {} \;
sudo find /DATA/docker/doc/ -type f -perm /u+x -exec chmod u=rw,g=rw,o= {} \;
sudo find /DATA/docker/wekan-db/ -type f -perm /u+x -exec chmod u=rw,g=rw,o=r {} \;
sudo find /DATA/docker/wiki/ -type f -perm /u+x -exec chmod u=rw,g=rw,o= {} \;
sudo find /DATA/docker/minetest/ -type f -perm /u+x -exec chmod u=rw,g=rw,o= {} \;
sudo find /DATA/docker/cet/ -type f -perm /u+x -exec chmod -x {} \;

Comme discuté lors de la dernière réunion, nous avons choisi rw-rw—- pour les fichiers des services pour lesquels nous n’avions aucune indication sur les droits d’origine, et notammet ceux des sites statiques. Pour le cloud de CeT, nous avons seulement retiré les droits d’exécution, afin de ne pas casser quelque chose sans nous en rendre compte.

Nous avons supprimé ce qu’il restait du conteneur Minetest sur pica02. De même, le site Wordpress de CeT avait déjà été supprimé lors de la précédente réunion.

Cédric : 2/3 Nous avons bien avancé cette semaine, bien que nous ne soyons pas encore sûrs de quelle politique mettre en place pour auditd.

Hugo : 2/3 La semaine a été plus productive que les précédentes, les permissions sont enfin nettoyées. Il faudra établir les prochains points à étudier lors de la prochaine réunion.

Étant donné que la plupart des services de l’infrastructure tournent dans des conteneurs, nous avons évalué la pertinence d’utiliser Docker pour auditd. Cependant, il s’agit d’une mauvaise idée puisque les utilisateurs du groupe docker pourraient alors modifier son comportement ou même l’arrêter, ce qui rendrait le démon inutile.

Nous avons décidé de mettre en place une politique basée sur la journalisation des appels systèmes et les utilisateurs/groupes ayant lancé les commandes.

On journalise et discrimine les appels à execve effectués par root, les membres du groupe docker et les autres utilisateurs. On remarquera que comme Docker tourne en temps que root, tous les appels systèmes effectués par les conteneurs sont journalisés en temps que root. On journalise ainsi notamment toutes les commandes exécutées.

Nous désirons également monitorer les “write” sur /etc/*, car ils permettent de modifier directement la configuration du système, et ne devraient pas être trop fréquents (et ne pollueront ainsi pas les logs).

Nous effectuerons un ajustement manuel pour runc afin de ne pas remplir inutilement le fichier de log. Restrictions des commandes accessibles avec sudo

Nous pensions n’avoir aucun moyen d’identifier les utilisateurs ayant effectué un “sudo su”. Cependant, nous avont découvert un champ “ses” dans les log d’auditd, contenant un identifiant de session qui est conservé lors d’un changement d’utilisateur. Il permettra d’avoir un historique continu même en cas de sudo su.

Il est préférable de centraliser les logs sur une machine de supervision, afin d’éviter la perte de ceux ci en cas de compromission de la machine étudiée. Le plugin d’auditd audisp-remote permet une telle centralisation. Comme indiqué la semaine dernière, il est capable d’utiliser kerberos 5 pour l’authentification et le chiffrement. Les pages de manuel d’auditd.conf et d’audisp-remote.conf donnent les informations nécessaires à la configuration du service.

La machine collectant les logs devra prévoir suffisament d’espace disque pour rassembler la totalité des journaux générés par toutes les VMs de Picasoft.

Il existe également un plugin permettant d’écrire les logs d’auditd dans syslog. Une manière relativement simple et sécurisée, si l’on désire utiliser syslog pour gérer la totalité des logs sur la machine centralisatrice, est de collecter les logs en utilisant audisp-remote, puis de les écrire dans syslog sur la machine de collecte à l’aide du plugin dédié. Une autre manière est d’utiliser TLS avec syslog, à l’aide de rsyslog (https://www.rsyslog.com/doc/master/tutorials/tls_cert_summary.html)log.com/doc/master/tutorials/tlscertsummary.html). Cela semble demander un peu plus de configuration, mais dans la mesure où on voudrait également centraliser les logs ne provenant pas d’auditd, il peut être intéressant de faire d’une pierre deux coups et de mettre en place ce système.

Cédric a commencé à documenter la procédure de mise en place d’auditd. Celle ci sera mise en ligne dès que possible, en raison d’un accès à internet précaire de son côté.

Cédric : 3/3 Les objectifs fixés ont été atteints, nous pouvons maintenant mettre en place la politique auditd élaborée et continuer de documenter la TX sur le wiki.

Hugo : 3/3 Nous avons avancé conformément aux objectifs.

Nous avons remarqué que /var/lib et /var/log se trouvent sur la même partition. Il est trivial de la remplir, particulièrement avec la nouvelle politique auditd journalisant les appels à execve, et donc d’obtenir un déni de service sur /var/lib, qui contient notamment des volumes Docker, qui contient notamment des volumes Docker., qui contient notamment des volumes Docker, qui contient notamment des volumes Docker.

Nous préconisons donc que ces deux répertoires soient à terme placés sur deux partitions différentes pour réduire les risques de déni de service.

Nous avons rajouté /lib à la liste des répertoires dans lesquels on journalise les écritures, notamment car beaucoup de unit files systemd s’y trouvent.

Les enregistrements CWD et AVC, qui sont pour l’instant inutiles, sont ignorés, ainsi que tous les événements concernant runc et containerd. Ils sont extrêments nombreux, ce qui consomme un espace non négligeable en journaux, et leur absence ne serait pas handicapante lors d’une analyse post-mortem de l’infrastructure.

Nous avons également commenté la configuration pour qu’elle reste simple à maintenir.

Rsyslog est déjà installé sur les machines. Cependant, afin de centraliser les logs de façon fiable, il faudrait installer le paquet librelp (présent dans les dépots Debian).

Pour mettre en place une centralisation, il faudra :

• Sur la machine centralisatrice, activer l’entrée RELP (Reliable Event Logging Protocol), en activant le module “imrelp” et en définissant celui ci comme une entrée.dule “imrelp” et en définissant celui ci comme une entrée.dule “imrelp” et en définissant celui ci comme une entrée.
• Sur les machines produisant les logs, activer la sortie RELP, à l’aide du module “omrelp”, et configurer rsyslog pour y rediriger tout ou une partie des logs.

Sur toutes les machines, TLS devra être configuré (génération des certificats …). Un tutoriel intéressant sur le processus complet peut être trouvé ici : https://www.rsyslog.com/using-tls-with-relp/og.com/using-tls-with-relp

Cette approche permettra de centraliser la totalité des logs produits par les machines, et gérés actuellement par rsyslog. Pour ajouter à ceux ci les logs produits par auditd, il faudra configurer le plugin audisp-syslog d’audisp (audit dispatcher).uits par les machines, et gérés actuellement par rsyslog. Pour ajouter à ceux ci les logs produits par auditd, il faudra configurer le plugin audisp-syslog d’audisp (audit dispatcher).a configurer le plugin audisp-syslog d’audisp (audit dispatcher).a configurer le plugin audisp-syslog d’audisp (audit dispatcher).

Côté serveur de centralisation, on peut stocker les logs de chaque machine dans des fichiers séparés, en discriminant par nom d’hôte par exemple. Cela permettra d’organiser les journaux, et de nous y retrouver si besoin. Avancement sur le wiki

Nous avons considérablement fourni le wiki en y ajoutant de la documentation sur auditd, à la fois générale et propre à l’infrastructure, en parlant de ses fonctionnalités, de ses règles et de la configuration du démon. Nous devons encore documenter la centralisation des logs et l’utilisation de ses outils.l’utilisation de ses outils.

Nous avons également corrigé le formattage de la page du wiki “sauvegarde unique”, qui était illisible. Nous avons remarqué que d’autres pages sont concernées dans une moindre mesure. Nous soupçonnons que l’installation du plugin Doku Wiki markdown ait causé ces problèmes.

Nous avons remarqué que les logs générés par syslog appartiennent au groupe adm, conformément à la configuration située à /etc/rsyslog.conf. Il serait pertinent de changer ce groupe à admin (nous voulons simplement en discuter avant de le faire).configuration située à /etc/rsyslog.conf. Il serait pertinent de changer ce groupe à admin (nous voulons simplement en discuter avant de le faire).configuration située à /etc/rsyslog.conf. Il serait pertinent de changer ce groupe à admin (nous voulons simplement en discuter avant de le faire).

Certains scripts healthcheck effectuent un nombre considérable d’appels à execve, toutes les 4 secondes pour l’image etherpad, ce qui pollue énormément les journaux d’auditd. Nous avons donc commencé à les répertorier afin d’en réduire la fréquence, pour laisser plus de place aux journaux véritablement utiles (et limiter l’activité inutile sur les serveurs).

Cédric : 3/3 Je suis très satisfait de l’avancement de cette semaine.

Hugo : 3/3 Je suis satisfait également, les tests de centralisation des logs pourront normalement commencer sous peu.

Une première configuration pour rsyslog est écrite. Des tests restent à effectuer, dans lesquels pica01-test jouera le rôle de serveur, et pica02 de client. La configuration (pour le client et le serveur), qui sera commentée dans le wiki une fois affinée, ressemblera à ça : Lien vers la configuration

Les logs provenants de serveurs différents seront stockés dans des fichiers différents. Il reste à déterminer si une distinction entre les types de logs est à effectuer, comme c’est le cas actuellement pour l’enregistrement des journaux locaux.

Par ailleurs, le groupe par défaut des logs de rsyslog a été passé à admin comme convenu. Cependant, ce paramètre n’a d’effet que sur les nouveaux fichiers créés. Comme par défaut, logrotate crée un nouveau fichier après la rotation avec les mêmes modes et propriétaires que les fichiers précédents, le changement de paramètre de syslog n’a pas encore eu d’effet…

La rotation des logs est gérée par logrotate, et configurée dans /etc/logrotate.conf. Il faudra rajouter à la fin de ce fichier, sur la machine centralisatrice, les instructions relatives à la rotation des logs provenant des autres vms, en s’inspirant de ce qui est fait pour les logs locaux.

La configuration ressemblera à ça : Lien vers la configuration pour logrotate

Nous avons entamé la présentation pour notre soutenance ainsi que le rapport, l’objectif étant de les terminer rapidement afin de consacrer un maximum de temps à la préparation du TP.

Le wiki comporte désormais presque toutes les actions et recherches que nous avons entreprises. Il reste encore à terminer la partie de centralisation des logs.

Cédric : 3/3 Nous approchons sereinement la fin de la TX et sommes dans les temps au niveau des mises en place techniques ainsi que des rendus.

Hugo : 2/3 J’aurais aimé pouvoir tester l’envoi de logs avant mercredi, mais je n’ai pas trop mal avancé sur le reste.

Nous avons fini la mise en place d’auditd sur tous les hôtes ainsi que la centralisation de ses journaux sur monitoring. Les journaux concernant chaque hôte se trouvent dans /var/log/<hostname>.

Certains journaux excessifs restent à réduire comme une requête mysql en tant que healthcheck pour Etherpad sur pica01 et de nombreux appels à udevadm sur monitoring (voir Rémy pour plus d’informations).

Les règles sont identiques pour tous les hôtes et sont documentées dans le wiki.

Comme indiqué la semaine dernière, la configuration de la centralisation se fait au moyen de fichiers client.conf présent chez les clients, et server.conf présent chez le serveur dans le dossier /etc/rsyslog.d. Les logs provenant d’auditd et d’audispd sont interceptés et envoyés à monitoring, qui les récupères et les met dans un fichier distinct par machine.

Il ne manque que les certificats pour mettre en place l’authentification TLS. La configuration est présente, et simplement commenté dans les fichiers de config susmentionnés.

Nous avons mis en place une politique de rotation des journaux des différents hôtes sur monitoring. Celle-ci les supprime après 30 jours, ce qui permet d’éviter d’en garder trop, tout en évitant les attaques par flooding et effectuant de nombreux execve jusqu’à ce que logrotate supprime les journaux les plus anciens.

Cette configuration est également documentée dans le wiki.

Afin de protéger le serveur, nous avons mis en place des règles de pare feu pour n’autoriser que les connexions depuis les machines de picasoft, en IPv4 et en IPv6, à la manière de ce qui avait été fait pour limiter l’accès au LDAP.

A cette occasion, nous nous sommes rendu compte que le port d’accès au LDAP n’étais pas filtré en IPv6. Nous n’avons pas eu le temps de le corriger, mais cela devra être fait.

Nous avons documenté toutes les configurations en rapport avec auditd dans le wiki, aussi bien pour les règles que pour la centralisation (clients et serveur).

Cédric : 3/3 Malgré d’autres projets prenant du temps, nous avons rempli notre contrat et Hugo a même trouvé une faille dans le pare-feu !

Hugo : 3/3 Tout ce que nous devions faire a été fait, malgré les deadlines diverses de cette semaine.

Bien que les objectifs de la TX aient évolué (nous n’avons ainsi pas effectué de tests d’intrusion) en raison des anomalies que nous avons rencontrées sur l’infrastructure, nous avons avons accompli ce qui nous a été demandé.

Les solutions techniques mises en place sont solides, maintenables et documentées et nous avons corrigé tous les problèmes que nous avons rencontré sur l’infrastructure.

Nous sommes également satisfaits des procédures mises en place. Elles sont à la fois juste et efficaces, bien qu’elles doivent encore être acceptées par l’ensemble de l’association.

Pour que notre installation du système de centralisation soit complète, il ne manque que les certificats nécessaire à l’authentification TLS, qui seront générés par un membre de l’association.

Auto-évaluation finale : 3/3