Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
txs:secu:secu_p19:bilan [2020/11/08 22:39] – ↷ Liens modifiés en raison d'un déplacement. qduchemi | txs:secu:secu_p19:bilan [2021/11/24 23:42] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. qduchemi | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | # TX Sécu P19 | ||
+ | ## Objectifs de la TX | ||
+ | |||
+ | Cette TX fait directement suite à la [TX Sécu A18](https:// | ||
+ | Elle est basée sur une reamrque simple : Picasoft sait désormais construire des images docker sécurisées et fonctionelles, | ||
+ | Néanmois, cela n'a pas d' | ||
+ | |||
+ | Nous avons donc décidé de faire faire un audit des machines, menant à des préconisations et à la mise en place de solutions concrètes pour la sécurisation de l' | ||
+ | |||
+ | Notre journal de bord, rempli tout au long de la TX, est disponible [[jdb|ici]]. | ||
+ | |||
+ | |||
+ | |||
+ | ## Actions effectuées au cours de la TX : | ||
+ | Au cours de cette TX, nous avons effectuées les actions suivantes : | ||
+ | |||
+ | - Identification des points à étudier. | ||
+ | - Préconisation de limiter les accès root sur les machines. | ||
+ | - Correction de nombreuses permissions erronées au niveau des services. | ||
+ | - Étude des possibilités de restriction du démon docker (voir [[txs: | ||
+ | - Mise en place d'un démon d' | ||
+ | - Centralisation des logs du démon d' | ||
+ | - Initiation à `tmux` des membres présents lors de la soutenance et création d'une [[technique: | ||
+ | |||
+ | |||
+ | ## Périmètre | ||
+ | |||
+ | L' | ||
+ | Stéphane Crozat. Nous avons aussi bien traité les menaces venant de l' | ||
+ | que de l' | ||
+ | accidents, notamment en production, plutôt que de considérer que les membres de | ||
+ | Picasoft aient des intentions malveillantes. | ||
+ | |||
+ | L' | ||
+ | s' | ||
+ | |||
+ | Il a cependant été décidé que les machines appartenant aux membres de Picasoft | ||
+ | ne faisaient pas partie du périmètre de l' | ||
+ | clefs SSH et du `pass` relèvent exclusivement de leur responsabilité. | ||
+ | |||
+ | ## Permissions | ||
+ | |||
+ | Nous avons observé que tous les membres de l' | ||
+ | `root` sur l' | ||
+ | principe de moindre privilège et facilite les erreurs (`sudo` un peu trop léger, | ||
+ | `poweroff` dans le mauvais terminal, etc.). La raison de cette distribution | ||
+ | large des droits `root` était que n' | ||
+ | Docker a indirectement accès aux droits `root` puisqu' | ||
+ | librement le système de fichiers de l' | ||
+ | dans un conteneur. Cependant, un tel comportement est suspicieux et n' | ||
+ | par accident. | ||
+ | |||
+ | Les droits `root` ont donc été remplacés en production par un ajout au groupe | ||
+ | `docker`, qui est suffisant pour administrer les conteneurs. Certains membres | ||
+ | comme le président et le responsable technique conservent toutefois les droits | ||
+ | `root` pour les tâches d' | ||
+ | accordé aux membres en ayant besoin, qui endossent alors les responsabilités | ||
+ | associées. Cette politique n'est pas arrêtée et peut évoluer en fonction des | ||
+ | besoins de l' | ||
+ | éventuellement rencontrés après sa mise en place. | ||
+ | |||
+ | ## Corrections mineures | ||
+ | |||
+ | ### Permissions excessives | ||
+ | |||
+ | Les permissions de nombreux fichiers et répertoires sur tous les hôtes étaient | ||
+ | incorrects pour différentes raisons. Nous avons notamment trouvé des mots de | ||
+ | passe en clair lisible par tout le monde, des fichiers de configuration | ||
+ | inscriptibles par tout le monde et des fichiers exécutables modifiables par les | ||
+ | utilisateurs des services. | ||
+ | |||
+ | Nous les avons corrigées en les restreignant au maximum tout en laissant la | ||
+ | majorité des fichiers de configuration lisibles aux membres de l' | ||
+ | pour des raisons pédagogiques. | ||
+ | |||
+ | ### Suppression de services | ||
+ | |||
+ | Nous avons supprimé plusieurs services abandonnés : une instance n' | ||
+ | fonctionnelle de Giphy pour Mattermost, un serveur fantôme Minetest présent sur | ||
+ | le serveur de production, et le site inutilisé Wordpress de Compiègne en transition. | ||
+ | |||
+ | ### Modifications de configuration | ||
+ | |||
+ | Nous avons modifié les configuration SSH de tous les hôtes afin d' | ||
+ | forwarding X jusque là permis. Aucun des hôtes ne fait a priori tourner de | ||
+ | serveur X, mais Xorg pourrait éventuellement être un jour installé, | ||
+ | éventuellement en temps que dépendance pour un autre paquet. Xorg étant une | ||
+ | vaste surface d' | ||
+ | X. | ||
+ | Nous avons également modifié les droits des journaux générés par `rsyslog` à | ||
+ | `root: | ||
+ | groupe `sudo`. | ||
+ | |||
+ | |||
+ | ## Restriction de Docker avec systemd | ||
+ | |||
+ | ### Motivation | ||
+ | |||
+ | Le contrôle de Docker, accordé par exemple aux utilisateurs du groupe `docker`, | ||
+ | donne indirectement les droits `root` sur le système. Il permet notamment de | ||
+ | monter le système de fichiers de l' | ||
+ | le conteneur. | ||
+ | |||
+ | On souhaite donc restreindre au maximum les capacités du démon Docker afin de | ||
+ | réduire les menaces provenant des utilisateurs du groupe `docker`. La solution | ||
+ | doit également être suffisamment simple pour être facile à maintenir. | ||
+ | |||
+ | ### Principe | ||
+ | |||
+ | Une approche naturelle pour cela est d' | ||
+ | `systemd.exec(5)`, | ||
+ | certaines parties du système de fichiers. | ||
+ | |||
+ | On peut par exemple rajouter l' | ||
+ | `[Service]` de `/ | ||
+ | d' | ||
+ | |||
+ | ### Problème | ||
+ | |||
+ | Depuis la version 18.09 de Docker, containerd n'est plus géré par Docker mais | ||
+ | par systemd. Pour des raisons expliquées dans [cette | ||
+ | issue](https:// | ||
+ | n'est donc plus possible d' | ||
+ | qui rend la solution proposée impossible à mettre en place. | ||
+ | |||
+ | ### Conclusion | ||
+ | |||
+ | Il est impossible de restreindre Docker proprement et efficacement avec systemd. | ||
+ | Nous n' | ||
+ | lourdes et intrusives (comme SELinux). De plus, les recommandations officielles | ||
+ | de sécurité concernant Docker indiquent clairement que ce cas est volontairement | ||
+ | ignoré et que l' | ||
+ | utilisateurs auxquels on confierait aussi `root`. Il n'y a donc | ||
+ | vraisemblablement pas de solution officielle à notre besoin. | ||
+ | |||
+ | ## auditd | ||
+ | |||
+ | Nous avons mis en place `auditd` sur tous les hôtes de l' | ||
+ | |||
+ | |||
+ | |||
+ | ## tmux | ||
+ | |||
+ | Nous avons proposé une initiation à `tmux` lors de notre soutenance et avons crée une [[technique: | ||
+ | |||
+ | # Bilan de la TX | ||
+ | |||
+ | Bien que les objectifs de la TX aient évolué (nous n' | ||
+ | effectué de tests d' | ||
+ | rencontrées sur l' | ||
+ | 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' | ||
+ | |||
+ | Nous sommes également satisfaits des procédures mises en place. Elles | ||
+ | sont à la fois juste et efficaces, bien qu' | ||
+ | acceptées par l' | ||
+ | |||
+ | Pour que notre installation du système de centralisation soit complète, | ||
+ | il ne manque que les certificats nécessaire à l' | ||
+ | qui seront générés par un membre de l' |